바이브 코딩의 핵심은 코드가 아니라 하네스였다
바로 구현 지시를 하지 않기로 했다
오늘 Commit Hero를 만들기 전에, 한 가지를 먼저 결정했다.
바로 구현 지시를 하지 않기로 했다.
아이디어는 있었다. GitHub username을 넣으면 RPG 스타일 개발자 카드를 만들어주는 웹앱. 충분히 구체적으로 느껴졌다. 하지만 그대로 Codex에 넘기지 않았다.
대신 질문을 먼저 했다.
이 서비스는 정확한 평가 도구인가, 재미있는 해석인가. MVP에서 반드시 있어야 하는 기능은 무엇인가. 카드의 톤은 어떻게 할 것인가.
세 가지 질문이 방향을 잡았다. 이후 다섯 차례 인터뷰를 거치면서 아이디어는 제품의 형태로 좁혀졌다. 그 다음에 Plan 문서가 나왔고, Design 문서가 나왔고, AGENTS.md가 만들어졌다. AGENTS.md는 Codex에게 “이 프로젝트에서는 이렇게 일하라”고 알려주는 역할을 했다.
사람과 AI의 역할 분리
이후 Codex가 구현을 진행했다. 직접 구현 코드를 손으로 작성하지는 않았다. 대신 방향, 범위, 품질 기준, 검증 과정을 계속 판단했다. 브라우저를 열고, username을 입력하고, 카드가 제대로 생성되는지 확인하고, 이미지 다운로드가 되는지 보는 것이 사람의 역할이었다.
역할을 정리하면 이렇다.
사람은 방향을 정하고, 범위를 좁히고, 품질 기준을 잡고, 결과를 판단하고, 다음을 결정한다. AI는 질문하고, 정리하고, 계획하고, 구현하고, 보고한다.
이 구분이 무너지면 AI는 금방 길을 잃는다. 처음부터 “GitHub RPG 카드 앱 만들어줘”라고 했다면 구현은 나왔겠지만, 방향이 없는 결과물이 나왔을 것이다. 범위를 사람이 먼저 잡지 않으면, AI는 스스로 가장 그럴듯한 방향으로 채워버린다.
배포 URL이 아니라 운영 자산으로
결과물은 배포 URL로 끝나지 않았다. GitHub에 남겼고, Cloudflare로 배포했고, chulbuji.com 바이브코딩 실험실에 Codex 001 사례로 연결했다. 오늘 만든 앱은 실습 기록이 아니라 운영 자산이 되었다.
오늘 만든 것은 단순한 웹앱 하나가 아니었다. AI에게 일을 맡기기 전에 무엇을 정해야 하는지 확인한 하루였다.
바이브 코딩의 핵심은 코드 생성이 아니라 하네스 설계였다. 하네스를 먼저 만드는 사람이 AI와 더 멀리 갈 수 있다.
독자 질문: AI에게 구현을 넘기기 전에, 여러분은 어디까지 먼저 좁히고 시작하시나요?