“이 정도면 실무에서도 되겠는데?”
TreeLearn 앱을 처음 Claude Code로 짜기 시작했을 때, 꽤 자신만만했다. 바이브 코딩 30일 후기도 썼고, 간단한 자동화 스크립트는 척척 만들었다. 그런데 프로덕션 수준의 앱을 처음부터 끝까지 AI와 함께 만들어보니 — 완전히 달랐다.
코드는 어느 정도 나왔다. 그런데 버그가 생기면 AI가 고치고, 고치면 다른 데서 터지고. 컨텍스트가 쌓일수록 AI는 점점 멍청해졌고, 나는 점점 지쳤다. 결국 “이게 바이브코딩인가, 디버깅 지옥인가”를 반복했다. 바이브코딩 실패의 원인은 도구가 아니었다. 프로세스가 없었던 것이다.
바이브코딩 실패, 원인은 도구가 아니라 프로세스다
바이브코딩 관련 강연이나 글에서 단골로 나오는 불만이 있다. “간단한 건 되는데 복잡해지면 망가진다.” 나도 정확히 이 함정에 빠졌다. 바이브코딩 실패 원인은 세 가지로 정리된다.
이유 1. 레벨에 맞지 않는 도구와 프로세스
바이브코딩에도 척도가 있다.
| 레벨 | 범위 |
|---|---|
| 레벨 1 | 함수 자동완성 |
| 레벨 2 | 스크립트 한 개 생성 |
| 레벨 3 | AI가 설계에 관여 |
| 레벨 4 | 설계·리팩토링·테스트·배포·프로젝트 관리까지 AI가 수행 |
프로덕션 수준 개발은 레벨4를 목표로 해야 한다. 대부분의 바이브코딩 실패는 레벨2~3 방식으로 레벨4짜리 프로젝트를 짜려다 생긴다.
이유 2. AI에게만 일을 넘기면 결과가 엇나간다
AI 혼자 생산성을 만들어내는 구조는 없다. 방향을 잡는 사람, 그 방향을 실행할 도구와 프로세스, 그리고 AI — 이 세 축이 맞물릴 때 결과가 나온다.
개발 지식 없이 AI에게만 맡기면 답답한 상황이 반복되는 이유가 여기에 있다. AI가 열심히 달리는데 방향이 엉뚱하다. 반대로 실력이 있어도 구조 없이 진행하면 그 역량이 증폭되지 않는다. TreeLearn 초반이 정확히 그 상황이었다. 능력의 문제가 아니라 흐름의 문제였다.
이유 3. 처음 코드의 각을 잘못 잡는다
AI는 기존에 짜여진 코드를 참고하면서 다음 코드를 작성한다. 처음 만들어진 코드가 하드코딩 덩어리거나 이름도 대충이면, AI는 그걸 패턴으로 인식하고 비슷하게 따라간다. “깨진 창문 이론”이 AI에게도 그대로 적용된다. TreeLearn에서도 초반 설계를 허술하게 잡은 탓에 후반부 코드가 일관성 없이 뭉텅뭉텅 붙었다.
AI와 함께하는 프로덕션 개발 5단계 워크플로우
바이브코딩 실패를 몇 번 겪고 나서 정착한 워크플로우가 있다. 핵심은 코딩을 시작하기 전에 AI와 함께 구조를 먼저 잡는 것이다.
Step 1 — 규칙(CLAUDE.md) 먼저 생성한다
Claude Code에는 규칙 파일이 있다. 이 파일은 매 프롬프트 히스토리와 함께 AI의 입력으로 들어간다. AI의 행동 지침을 코드처럼 명문화하는 것이다.
직접 작성할 필요도 없다. Claude Code한테 “이 프로젝트에서 네가 지킬 규칙을 먼저 생성해줘”라고 하면 알아서 만든다. 규칙에는 기술 스택, 코드 스타일, 테스트 방식, 커밋 메시지 포맷까지 들어간다. 이게 없으면 AI가 프로젝트마다 다른 스타일로 코드를 짠다. TreeLearn 초반의 실수가 바로 이것이었다.
Step 2 — 요건 정의(PRD)를 AI와 함께 작성한다
“이거 만들어줘”가 아니라, “이걸 만들기 위해 내가 무엇을 알려줘야 해?”를 먼저 물어본다. AI한테 육하원칙이 담긴 PRD를 작성하게 한다. 누가 쓰는지, 무엇을 만드는지, 왜 만드는지, 어디서 돌아가는지. 이 맥락이 명확할수록 이후 코딩 단계에서 AI의 판단 오류가 줄어든다.
TreeLearn 앱에서는 이 단계를 건너뛰었다가 중간에 아키텍처를 두 번 갈아엎었다. 설계 한 번 제대로 하는 데 드는 토큰이, 다시 짜는 데 드는 토큰의 10분의 1도 안 된다.
Step 3 — 설계 문서를 작성하고 아키텍처를 잡는다
PRD가 나오면 설계 문서를 작성한다. 하나의 파일에 모든 걸 다 넣으면 나중에 컨텍스트 초과가 발생하니, 파일을 적절히 분리하는 게 중요하다. Claude Code한테 아키텍처 다이어그램 초안도 함께 뽑을 수 있다.
마이크로서비스 아키텍처가 프로덕션 바이브코딩과 상성이 좋은 이유도 여기서 나온다. 서비스를 잘게 쪼갤수록 AI가 처리하는 컨텍스트 단위가 작아지고, 그만큼 정확도가 올라간다.
Step 4 — 태스크를 쪼개고 인수조건을 명시한다
설계가 끝나면 태스크를 작성한다. Claude Code는 이 작업도 잘 해준다. 태스크를 작성한 뒤 “의존성이 없는 것끼리 병렬로 묶어줘”라고 하면, 어떤 걸 동시에 진행할 수 있는지까지 파악해준다.
각 태스크에는 완료 기준을 반드시 명시해야 한다. “어떤 상태가 됐을 때 이 작업이 끝난 것인가” — 이 기준이 없으면 AI는 실행은 했지만 실제로는 동작하지 않는 코드를 만들어놓고 완료라고 보고하는 경우가 생긴다. 검증 가능한 조건을 태스크 안에 함께 써두는 것이 핵심이다.
Step 5 — TDD로 구현하고 디버깅도 자동화한다
이 단계부터는 AI가 대부분의 작업을 수행한다. 여기서 중요한 원칙 하나 — AI가 만든 코드는 곧이곧대로 믿으면 안 된다. 실행해서 검증하는 구조 위에서 개발해야 한다. 그 방법이 TDD다.
테스트를 먼저 작성하고, 실행 코드는 나중에 만든다. Husky를 사용해 커밋 직전에 lint·build·test가 자동으로 돌도록 설정해두면, 기준을 통과하지 못한 코드는 커밋 자체가 안 된다.
디버깅도 구조적으로 접근해야 한다. 에러 로그 전체를 AI에 붙여넣으면 정작 중요한 정보가 묻혀버린다. 먼저 관련 정보만 추출하는 필터 스크립트를 만들게 하고, 그 결과를 바탕으로 원인을 좁혀가는 방식이 훨씬 효율적이다.
프로덕션 바이브코딩에서 Claude Code를 선택한 이유
지금 시점에서 도구를 하나만 골라야 한다면, Claude Code다.
단순히 코드를 잘 짜서가 아니다. 개발 전 과정(요건 정의, 설계, 태스크 관리, 테스트, 배포)을 이해하고 움직이는 도구라는 점이 결정적이다.
| 구분 | GPT 계열 | Claude Code |
|---|---|---|
| 학습 방향 | 다음 코드가 어떻게 이어질지 예측 | 개발자가 다음에 어떤 행동을 할지 예측 |
| 강점 | 코드 자동완성, 단편 생성 | 전체 개발 흐름 이해, 프로세스 설계 |
| 프로덕션 적합성 | 레벨2~3 | 레벨4 |
헤드리스 모드로 백그라운드 실행, 플래닝 모드로 계획 먼저 검증, 부모 인스턴스가 자식 인스턴스에게 병렬 태스크를 발주하는 구조 — 이 모든 기능이 레벨4 바이브코딩을 위해 설계된 것들이다.
핵심 요약
바이브코딩 실패의 원인은 대부분 도구가 아니라 프로세스 부재다.
| 단계 | 핵심 |
|---|---|
| Step 1. 규칙 생성 | AI 행동 지침을 코드처럼 명문화 |
| Step 2. PRD 작성 | 맥락이 명확할수록 AI 판단 오류가 줄어든다 |
| Step 3. 설계·아키텍처 | 파일 분리, 마이크로서비스로 컨텍스트 단위 축소 |
| Step 4. 태스크·인수조건 | “완료의 증거”를 요구하는 구조 |
| Step 5. TDD·디버깅 자동화 | AI 코드는 의심하는 구조로 검증 |
바이브코딩이 장난감처럼 느껴졌다면, 이제 프로세스를 갖춰서 다시 시작해볼 만하다.
[링크 제안]
프로세스를 갖췄다면, 다음은 AI에게 정확한 지시를 내리는 프롬프트 구조가 필요하다.
바이브코딩을 처음 시작하는 단계라면 이 글이 출발점이 된다.
아이언맨으로 Agentic Engineering을 이해하다
