당신의 코드는 병목이 아니다. 당신의 환경이 병목이다.
대부분의 개발자는 몇 시간씩 이런 논쟁을 벌인다.
- React냐 Vue냐
- Docker냐 Podman이냐
- Claude Code냐 Cursor냐
- PostgreSQL이냐 MySQL이냐
그런데 정작 매일매일 상호작용하는 그것에는 거의 관심을 두지 않는다.
자신의 개발 워크스페이스.
몇 달 전, 거의 1년 동안 손대지 않은 프로젝트를 다시 들여다봐야 했다.
몇 가지는 기억났다.
- PostgreSQL을 썼다.
- Redis도 어딘가 관여했다.
- 애플리케이션은 Docker에서 돌았다.
- 워크플로에 AI 도구가 있었다.
기억나지 않았던 건 그것들이 다 어디에 있는지였다.
코드가 문제가 아니었다. 아키텍처가 문제가 아니었다.
내 개발 환경이 문제였다.
스타트업에서 일하고, 사이드 프로젝트를 만들고, AI 툴링을 실험하고, 클라이언트 작업을 관리하는 사이 어디쯤에서, 내 머신은 서로 연결되지 않은 프로젝트들, 중복된 환경들, 잊힌 인프라의 집합체가 되어버렸다.
새 프로젝트 하나하나는 눈앞의 문제를 풀었다. 그중 어느 것도 장기적인 문제는 풀지 못했다.
커리어와 함께 확장되는 개발 환경을 어떻게 조직할 것인가?
그 질문이 내 워크스페이스 구조를 완전히 재설계하게 만들었다.
🚨 대부분의 개발자가 무시하는 문제
커리어 초반에는 프로젝트 정리가 보통 이렇게 생겼다.
처음엔 이걸로 잘 굴러간다.
그러다 삶이 끼어든다.
회사에 합류한다. 프리랜스를 시작한다. 스타트업을 시작한다. 오픈소스 프로젝트를 만든다. AI 툴링을 실험하기 시작한다. PostgreSQL, Redis, Docker 컨테이너, 로컬 서비스를 돌리기 시작한다.
프로젝트 개수가 문제가 아니다. 구조의 부재가 문제다.
저장소가 늘어날수록 정신적 부담도 함께 늘어난다.
- 그 저장소 어디 있더라?
- 어느 PostgreSQL 인스턴스가 어느 프로젝트 거지?
- Docker 설정은 어디 있지?
- 이 폴더 지워도 안전한가?
- 왜 Node.js 버전이 세 개나 설치돼 있지?
이런 질문들은 사소해 보인다. 하지만 몇 년에 걸쳐 쌓이면 엄청난 생산성 낭비가 된다.
🧠 시스템 엔지니어처럼 사고하기
전환점은 내 워크스테이션을 프로젝트 모음으로 다루는 걸 멈추고, 소프트웨어 시스템으로 다루기 시작했을 때 왔다.
나 자신에게 질문 하나를 던졌다.
앞으로 10년 동안 수백 개의 저장소를 관리해야 한다면, 내 개발 환경은 어떤 모습이어야 할까?
그 질문이 내 접근 방식을 완전히 바꿨다.
오늘의 프로젝트에 맞춰 최적화하는 대신, 이런 것들에 맞춰 최적화했다.
- 여러 고용주
- 스타트업 벤처
- 클라이언트 작업
- 오픈소스 기여
- Docker 우선 개발
- AI 지원 개발
- 쉬운 머신 이전
- 장기적인 유지보수성
그 결과는 이렇게 됐다.
단순하다. 예측 가능하다. 확장 가능하다.
🧱 소스 코드는 인프라가 아니다
개발자들이 저지르는 가장 큰 실수 중 하나는 소스 코드와 인프라를 섞는 것이다.
저장소는 다음을 담아야 한다.
- 비즈니스 로직
- 애플리케이션 코드
- 테스트
- 문서
저장소가 다음을 위한 쓰레기장이 되어서는 안 된다.
- 로컬 스크립트
- Docker 실험
- 데이터베이스 저장소
- AI 툴링
- 머신별 설정
그래서 나는 전용 인프라 계층을 도입했다.
infra/
├── docker/
├── ai/
├── scripts/
└── templates/인프라는 애플리케이션과 독립적으로 진화한다. 이 둘을 분리하면 저장소가 깔끔하고 집중된 상태를 유지한다.
🐳 모든 걸 단순하게 만든 Docker 규칙
Docker 우선 개발 환경을 원했다. 하지만 모든 저장소를 똑같이 취급해선 안 됐다.
내가 도달한 규칙은 놀랍도록 간단하다.
✅ 내가 저장소를 수정할 수 있다면
프로젝트 1개 = 컨테이너화된 개발 환경 1개
모든 프로젝트가 자기만의 격리된 환경을 갖는다.
이점은 다음과 같다.
- 의존성 격리
- 재현 가능성
- 더 쉬운 온보딩
- CI/CD 정렬
- 더 나은 AI 툴링 지원
프로젝트가 자기 완결적이 된다. 누군가 내일 이걸 클론하면, 정확히 같은 환경을 얻는다.
🔒 내가 저장소를 수정할 수 없다면
조직 1개 = 워크스페이스 컨테이너 1개특히 회사 저장소에 유용하다.
내가 통제할 수 없는 저장소에 Docker 파일을 추가하는 대신, 외부 워크스페이스 컨테이너를 만든다.
infra/docker/workspaces/acme/이 워크스페이스는 그 조직에 속한 모든 저장소를 마운트한다.
volumes:
- ~/Developer/company/acme:/workspace이렇게 하면 회사 소유 코드를 건드리지 않고도 Docker 우선 워크플로를 유지할 수 있다.
작은 구분이지만, 많은 마찰을 없애준다.
💾 데이터를 나머지와 분리하는 이유
이건 아마 가장 중요한 아키텍처 결정이었을 것이다.
대부분의 개발자는 둘 중 하나다.
- 저장소 안에 데이터를 저장하거나,
- Docker가 관리하는 볼륨에 전적으로 의존하거나.
나는 둘 다 마음에 들지 않았다. 대신 전용 데이터 계층을 만들었다.
이 구조는 소유권을 명확하게 만든다. 나는 즉시 다음을 안다.
- 어느 프로젝트가 이 데이터를 소유하는지
- 어느 데이터베이스가 어느 애플리케이션 것인지
- 무엇을 아카이브할 수 있는지
- 무엇을 백업해야 하는지
이점은 상당하다.
- 더 깔끔한 저장소
- 더 쉬운 백업
- 더 단순한 마이그레이션
- 더 빠른 Git 작업
- 저장 용량 사용에 대한 더 나은 가시성
가장 중요한 건 이거다.
내 데이터가 어디 있는지 항상 안다.
🤖 AI 네이티브 미래를 위한 설계
우리가 소프트웨어를 작성하는 방식이 바뀌고 있다. AI 도구들은 개발 환경 자체의 일부가 되어가고 있다.
- Claude Code
- Codex
- Gemini CLI
- 로컬 모델
- 미래의 자율 에이전트
대부분의 개발자는 여전히 이것들을 프로젝트 단위 도구로 취급한다.
나는 이것들을 인프라로 취급하기로 했다.
이건 모든 프로젝트에서 작동하는 재사용 가능한 AI 계층을 만든다.
툴링이 진화해도 내 저장소는 깔끔하게 유지된다. AI 스택은 애플리케이션 자체와 독립적으로 변화한다.
그 분리는 앞으로 몇 년간 점점 더 가치가 커질 것이다.
⚡ 가장 큰 생산성 향상은 Docker가 아니었다
AI도 아니었다. 자동화도 아니었다.
인지 부하를 줄인 것이었다.
모든 프로젝트가 예측 가능한 구조를 따를 때.
company/
startup/
clients/
personal/나는 더 이상 이런 질문을 하지 않는다.
- 이 저장소 어디에 클론했더라?
- 어느 데이터베이스가 이 프로젝트 것이지?
- 어느 회사가 이 코드베이스를 소유하지?
- Docker 설정은 어디 있지?
- 이거 안전하게 아카이브할 수 있나?
답은 명백하다.
그리고 그 일관성은 쌓인다. 모든 컨텍스트 전환이 더 빨라진다. 모든 새 프로젝트의 온보딩이 더 쉬워진다. 모든 미래의 결정이 더 단순해진다.
📦 머신 이전이 지루해진다
대부분의 개발자는 새 노트북을 사기 전까지 이전에 대해 생각하지 않는다.
그러고 나면 고통이 시작된다. Docker 볼륨. 설정 파일. 스크립트. 데이터베이스. 환경 변수. 아무것도 어디 있는지 아무도 기억 못 한다.
내 목표는 단순했다.
오늘 내 머신이 죽는다면, 디렉토리 하나에서 모든 걸 재구축할 수 있어야 한다.
중요한 모든 것은 다음 아래에 산다.
Developer/저장소. 인프라. 영구 데이터. 그게 전부다.
개발 환경이 이식 가능해진다.
그리고 이식성은 투자할 만한, 가장 저평가된 생산성 기능 중 하나다.
🎯 진짜 교훈
폴더 구조 자체가 중요한 게 아니다. 그 뒤의 마인드셋이 중요하다.
좋은 엔지니어는 애플리케이션만 설계하지 않는다. 시스템을 설계한다.
당신의 워크스테이션은 시스템이다. 당신의 개발 워크플로는 시스템이다. 당신의 생산성은 시스템이다.
이 시스템들을 설계하는 데 얼마나 의도적인가에 따라, 그것들과 싸우는 데 쓰는 에너지가 줄어들고, 실제 엔지니어링 문제를 푸는 데 쓸 에너지가 늘어난다.
잘 설계된 개발 환경이 하루아침에 당신을 더 나은 개발자로 만들어주지는 않는다.
하지만 수천 시간의 작업에 걸쳐, 당신이 손대는 모든 프로젝트에서 조용히 마찰을 없애준다.
그게 진짜 생산성 향상이 나오는 지점이다.
💬 당신의 개발 워크스페이스는 어떻게 생겼나
다른 엔지니어들이 자신의 환경을 어떻게 조직하는지 항상 궁금하다, 특히 Docker, Dev Container, AI 지원 개발이 표준 워크플로의 일부가 되어가는 지금은 더더욱.
툴링 지형은 매년 바뀐다.
좋은 워크스페이스 아키텍처는 그 모든 변화에서 살아남아야 한다.
