바이브코딩으로 서버를 만들 때 결과를 가르는 건 Docker를 아느냐가 아니다. “Docker Compose 기반으로 구성해줘”라는 한 문장을 요구할 줄 아느냐다. AI는 시키지 않은 구조를 알아서 갖춰주지 않는다. 요구되지 않은 품질은 그냥 생략된다.
이건 코딩 지식이 무의미해졌다는 뜻이 아니다. 지식의 쓰임새가 바뀌었다. 예전에는 지식이 ‘실행 능력’이었다면 지금은 ‘발주 어휘’다. docker-compose.yml을 손으로 쓸 줄 아는 능력의 가치는 급락했지만, 그런 것이 존재한다는 걸 알고 그것을 요구할 줄 아는 능력의 가치는 오히려 올랐다. 문제는 이 어휘가 검색으로 채워지지 않는다는 점이다. 모르는 것은 질문조차 되지 않는다.
그래서 바이브코딩의 실패는 대개 코드가 틀려서가 아니라, 요구하지 않아서 생긴 구조적 공백에서 온다. AI는 동작하는 것을 만들고, 사람이 명시하지 않은 운영 요건은 조용히 빠진다.
근거
바이브코딩에서는 Docker 문법을 공부하는 것보다 “프론트, 백엔드, DB를 각각 컨테이너로 분리하고 Docker Compose로 한 번에 실행할 수 있게 만들어줘.” 라고 AI에게 시킬 줄 아는 게 더 중요합니다.
원문이 강조하는 것은 도구가 아니라 요구의 형식이다. 동일한 서비스를 만들어도 이 한 문장이 있느냐 없느냐가 6개월 뒤 유지보수 가능 여부를 가른다.
연결된 생각
- 20260612-developer-shift-to-orchestrator — 코드 작성자에서 의도 조율자로의 이동이 실무 프롬프트 층위에서 구체화된 사례
- 20260526-workflow-orchestration-is-the-real-ai-era-skill — 레버리지가 프롬프팅 기교가 아니라 무엇을 지시할지 정하는 판단에 있다는 같은 결론
- 20260809-vibe-coding-container-baseline — 이 어휘의 최소 구성 목록