바이브 코딩의 핵심은 감이 아니라 스펙이었다: 내가 요구사항 문서부터 다시 쓰게 된 이유
처음에는 “잘 말하면 AI가 알아서 잘 만든다"는 기대가 있었다. 하지만 실제로 서비스를 붙여보면 결과는 정반대였다. AI는 빈칸을 채우는 데 능하지만, 그 빈칸이 비즈니스 의도와 맞는지는 보장하지 않는다.
내가 가장 크게 데인 지점도 여기였다. 익명 사용자 세션, 로그인 전환, MVP 범위 같은 기본 정책을 명확히 적지 않자 에이전트가 그럴듯하지만 우리 서비스와 맞지 않는 결정을 반복했다.
내가 겪은 실패: 요구사항 공백은 곧 임의 구현이었다
실제로 문제가 났던 흐름은 단순했다.
- 익명 사용자 세션은 체험 후 종료가 기본이어야 한다.
- 다만 사용자가 가입/로그인을 선택하면 기존 세션을 보존해야 한다.
- 사용자당 프로젝트는 하나만 지원하는 MVP였다.
이 세 줄이 명세에 없던 시점에는, 에이전트가 다중 프로젝트를 전제로 코드를 만들거나 세션 정책을 중간에 바꾸는 일이 반복됐다.
겉으로는 “기능 구현 완료"였지만, 운영 관점에서는 재작업 예약 상태였다.
참고: Martin Fowler는 AI 협업 개발에서 프롬프트 중심 접근만으로는 유지보수가 어려워지기 쉽다고 지적한다. Spec-Driven Development: Tools
바꾼 방식: 프롬프트가 아니라 아티팩트로 고정
그 뒤부터 나는 요구사항을 말로 전달하지 않고, 문서로 고정했다. 바이브 코딩 입력값을 아래 4개 아티팩트로 제한했다.
- 제품 요구사항(PRD): 사용자/문제/범위/비범위
- 도메인 규칙: 상태 전이, 권한, 예외 정책
- 아키텍처 규칙: 계층 분리, 의존성 방향, 금지 규칙
- 완료 조건(DoD): 테스트, 로그, 실패 복구 기준
핵심은 “모델이 잘 코딩하느냐"가 아니라 “모델이 무엇을 참조해야 하는가"를 고정하는 것이었다.
참고: GitHub Spec Kit 역시 AI 시대 개발자의 역할을 “지시"보다 “명세와 검증"에 두고 설명한다. Beyond Prompting: Introducing GitHub Spec Kit
실제 운영에서 유효했던 규칙
- 한 번의 작업 단위를 모듈 단위로 쪼갠다.
- 각 작업마다 입력/출력 계약을 먼저 적는다.
- 명세 변경은 코드 변경보다 먼저 반영한다.
- 에이전트 출력은 바로 머지하지 않고, 계약 위반 검사부터 한다.
이 방식으로 바꾸고 나서부터는 “코드가 돌아간다"와 “제품이 맞다” 사이의 간극이 크게 줄었다.
참고: Karpathy의 Software 2.0은 모델 기반 개발일수록 데이터/검증 체계가 핵심이 된다는 관점을 제시한다. Software 2.0
한계도 분명하다
스펙을 과하게 고정하면 탐색 속도가 느려질 수 있다. 특히 0에서 1을 찾는 초기 단계에서는 명세의 정교함보다 빠른 실험이 더 중요할 때도 있다.
그래서 나는 다음처럼 구분한다.
- 탐색 단계: 얇은 명세 + 빠른 실험
- 수렴 단계: 명세 강화 + 변경 통제
- 운영 단계: 명세 우선 + 자동 검증
정리
바이브 코딩의 핵심은 감각이 아니라 해석 가능한 기준이다. 결국 개발자는 프롬프트 장인이 아니라 요구사항과 설계 의도를 명확히 표현하는 사람이어야 한다.
내가 얻은 가장 현실적인 결론은 하나다. 에이전트의 품질은 모델보다 스펙 품질에 더 크게 좌우된다.