정의
바이브코딩으로 서버까지 생성할 때, AI에게 “Docker Compose 기반으로 구성해줘”를 명시적으로 요구해 서비스 구성 자체를 선언적 파일로 남기는 최소 운영 기준선이다. 목적은 기술 과시가 아니라 AI가 만든 서비스를 사후에 사람이 관리·재현할 수 있게 만드는 것이다.
핵심 속성
- 컨테이너 분리 단위: 프론트엔드 · 백엔드 · PostgreSQL · Redis를 각각 독립 컨테이너로 격리
- Compose의 역할: 분리된 컨테이너들을 하나의 세트로 묶고 서비스 간 연결, 포트, 환경변수, 볼륨을 한 번에 정의
- 이식성: 서버가 바뀌어도 구성 파일만 옮기면 전체 서비스를 재기동 가능
- 요구 문장 (프롬프트 기본형): “프론트, 백엔드, DB를 각각 컨테이너로 분리하고 Docker Compose로 한 번에 실행할 수 있게 만들어줘”
- 금지 패턴: DB 데이터·사용자 업로드 파일 등 영속 데이터를 컨테이너 내부에만 저장
- 설계 원칙: 컨테이너는 언제든 폐기·재생성 가능(disposable), 데이터는 컨테이너가 사라져도 잔존(persistent)
- 역량 전환: Docker 문법 숙달 < AI에게 구성 요구사항을 지시할 수 있는 어휘
관계
- 20260809-docker-compose — 이 기본선을 실행하는 도구
- 20260809-stateful-boundary-cannot-be-delegated — 하위원칙: stateless/stateful 경계 판단
- 20260809-declared-infrastructure-is-readable-context — 연장: 선언된 구성이 후속 AI 세션의 컨텍스트가 됨
- 20260612-developer-shift-to-orchestrator — 연장: 코드 작성자에서 의도 조율자로의 역할 이동
- 20260510-agent-hosting-is-where-they-live — 상위 맥락: 실행 환경이 곧 경쟁 우위
- 20260605-hermes-agent-vps-setup — 대조: 개인 에이전트 서버의 실제 구성 사례
인용
바이브코딩에서는 Docker 문법을 공부하는 것보다 “프론트, 백엔드, DB를 각각 컨테이너로 분리하고 Docker Compose로 한 번에 실행할 수 있게 만들어줘.” 라고 AI에게 시킬 줄 아는 게 더 중요합니다.
컨테이너는 언제든 버리고 다시 만들 수 있게. 데이터는 컨테이너가 사라져도 살아남게.
결국 바이브코딩에서 Docker를 쓰는 이유는 기술 자랑이 아니라, AI가 만든 서비스를 나중에 내가 관리하기 쉽게 만드는 것.