AI는 코드를 생성하지만 환경은 생성해주지 않는다. 터미널에서 하나씩 설치하고 포트를 열고 환경변수를 export하며 만든 서버는, 그 과정이 끝나는 순간 아무 데도 기록되지 않은 암묵지가 된다. 동작은 하는데 아무도 재현할 수 없는 상태다.
Docker Compose가 실제로 하는 일은 컨테이너 격리가 아니라 상태의 문서화다. 서비스 간 연결, 포트, 환경변수, 볼륨이 한 파일에 텍스트로 선언되는 순간, 그것은 서버가 바뀌어도 옮길 수 있는 자산이 되고 동시에 다음 대화에서 AI에게 통째로 붙여넣을 수 있는 컨텍스트가 된다. 이게 결정적이다. AI와 계속 협업하려면 시스템의 현재 상태가 AI가 읽을 수 있는 형태여야 한다.
바꿔 말하면 인프라를 선언형으로 남기는 이유가 하나 늘었다. 예전에는 재현성과 협업이었고, 지금은 거기에 ‘다음 세션의 컨텍스트 주입’이 붙었다. 선언되지 않은 것은 AI에게 존재하지 않는 것과 같다.
근거
그래서 서버가 바뀌어도 이 구성만 가져가면 전체 서비스를 비교적 쉽게 다시 띄울 수 있습니다.
결국 바이브코딩에서 Docker를 쓰는 이유는 기술 자랑이 아니라, AI가 만든 서비스를 나중에 내가 관리하기 쉽게 만드는 것.
원문의 결론이 ‘성능’이나 ‘격리’가 아니라 ‘나중에 내가 관리하기 쉽게’라는 점이 중요하다. 목적함수가 실행 시점이 아니라 유지보수 시점에 놓여 있다.
연결된 생각
- 20260809-docker-compose — 선언의 구체적 형식
- 20260809-vibe-coding-container-baseline — 이 원칙을 최소 실행 기준으로 옮긴 것
- 20260611-engineering-as-loop-orchestration — 반복 가능한 루프를 돌리려면 상태가 읽을 수 있는 형태여야 한다는 같은 전제