바이브코딩을 하다가 수정이 점점 느려지고, AI가 엉뚱한 방향으로 달려가기 시작한 적이 있는가. 이 글은 그 상황에서 빠져나오는 구체적 방법을 설명한다.
처음에는 잘 된다. AI에게 "이런 기능을 만들어줘"라고 말하면 코드가 나오고, 돌려보면 작동한다. 수정이 필요하면 "이 부분을 이렇게 바꿔"라고 말한다. 또 작동한다. 세 번째 수정도 괜찮다.
네 번째쯤부터 이상해진다. 수정 시간이 점점 길어진다. 다섯 번째 수정에서 이전에 고쳤던 버그가 다시 나타난다. 여섯 번째 수정에서 AI가 전혀 의도하지 않은 구조를 만들어놓는다. "왜 이렇게 했어?"라고 물으면 그럴듯한 설명을 하지만, 그 설명대로 다시 고치면 또 다른 곳이 깨진다.
이 시점에서 대부분의 개발자는 소스 코드 전체를 AI에게 다시 넣고 수정을 지시한다. “이 코드 전체를 보고, 여기를 이렇게 고쳐줘.” 이것이 구렁텅이의 시작이다.
AI가 생성한 코드를 다시 AI에게 입력으로 넣는 것은 자기 출력을 자기 입력으로 되먹이는 것이다. 학술적으로는 MAD(Model Autophagy Disorder, 모델 자가포식 장애)라 불리는 현상의 축소판이다.
구체적으로 무슨 일이 벌어지는가.
① AI의 코드가 '단일 진실원(Single Source of Truth)'이 된다. 원래 단일 진실원은 요구사항이어야 한다. "이 앱은 무엇을 해야 하는가"가 진실이고, 코드는 그 진실의 구현이다. 그런데 소스 코드를 통째로 넣는 순간, AI는 코드를 진실로 취급한다. "이 코드가 이렇게 되어 있으니, 이것이 의도인 것이다"라고 추론한다. 원래 의도와 다르더라도, 코드가 헌법처럼 가동된다.
② 내부에 쌓인 모순을 AI가 보존한다. 수정을 거듭하면서 코드 안에는 서로 다른 시점의 결정이 뒤섞여 있다. 첫 번째 수정의 로직과 세 번째 수정의 로직이 충돌하지만, 각각이 “작동은 한다.” AI는 이 충돌을 해결하지 않고 보존한다. 왜냐하면 코드가 진실이고, 진실은 보존해야 하니까. 결과: 수정할수록 코드는 기형적으로 비틀린다. 내부에 로봇300원칙같은게 생성되어 있어서 서로 충돌한다.
③ 요구사항이 사라진다. "원래 뭘 만들려고 했는지"가 어디에도 기록되어 있지 않다. 코드 안에 암묵적으로 묻혀 있을 뿐이다. 암묵적으로 묻혀 있는 요구사항은 AI가 멋대로 해석한다. 해석이 틀려도 비교할 원본이 없다.
이것은 AI만의 특징이 아니다. 자연계에서도 같은 구조가 관찰된다. 소의 뇌 단백질을 소에게 먹이면 광우병이 발생한다. 출판 시장에서 독자 반응 데이터로 소설을 편집하면 양산형 쓰레기가 나온다. 결과물로 입력을 만드는 행위는 어디에서든 품질을 붕괴시킨다.
구렁텅이에서 빠져나오는 방법은 하나다. 코드를 더 수정하지 말고, 코드에서 두 장의 문서를 뽑아낸다.
“이 결과물을 다시 만들려면 어떤 절차를 거쳐야 하는가”를 기록한 문서다. 시행착오를 걸러내고, 성공한 절차만 남긴다. 이 문서가 있으면 다른 AI에게 넘겨도 같은 결과를 재현할 수 있다.
“이 결과물이 실제로 만족시키고 있는 요구사항이 무엇인가”를 역산해서 뽑아낸 문서다. AI에게 "이 코드를 처음 보는 기획자가 요구사항을 작성한다고 가정하고, 빠짐없이 나열하라"고 지시하면 나온다. 이 목록에는 당신이 의도하지 않은 항목이 반드시 섞여 있다. 그것을 찾아내 제거하는 것이 핵심이다.
회차 — 초안 생성:
지금까지 우리가 작업한 전 과정을 역산해, 동일한 결과가 다른 AI에게도 재현될 수 있도록 스킬 문서(Skill.md)로 정리하라. 포함해야 할 6개 구성 요소: 1. 작업 개요와 목적 2. 전제 조건 (필요 입력물, 도구, 모델 요구 조건) 3. 단계별 절차 (논리적 의존 순서로 재배열. 병렬 실행도 직렬로 기록) 4. 금지 사항 (시행착오와 실패한 접근. "왜 안 되는가"를 반드시 명시) 5. 판정 기준 (이 스킬이 성공했는지 판정하는 조건) 6. 변경 이력 시행착오와 중간에 폐기된 접근은 최종 절차에서 제외하되, 왜 제외되었는지는 금지 사항 섹션에 기록하라.
2회차 — 누락 확인:
방금 작성한 스킬 문서를 다시 읽고, 다음을 확인하라. 1. 6개 구성 요소 중 빠진 것이 있는가 2. 단계별 절차에서 "이 단계의 출력이 다음 단계의 입력이 되는" 연결이 끊어진 곳이 있는가 3. 금지 사항에 "왜 안 되는가"의 이유가 빠진 항목이 있는가 4. 이 스킬 문서만으로 다른 AI가 동일 결과를 재현할 수 있는가 — 재현이 불가능한 지점이 있다면 명시하라 누락이 있으면 수정본을 출력하라. 없으면 "누락 없음"이라고 답하라.
3회차 — 최종 검증:
이 스킬 문서를 처음 보는 AI가 읽는다고 가정하라. 그 AI가 이 문서만으로 작업을 재현하려 할 때: 1. "이게 무슨 뜻이지?"라고 의문을 가질 부분이 있는가 2. 암묵적으로 전제하고 있지만 명시하지 않은 조건이 있는가 3. 전제 조건에 빠진 도구나 설정이 있는가 있으면 해당 부분을 수정하라. 없으면 "최종 확인 완료"라고 답하라.
1회차 — 역기획서 생성:
현재 소스 코드와 위의 스킬 문서를 기반으로, 요구사항 명세(역기획서)를 작성하라. 규칙: - 완성된 결과물을 처음 보는 기획자가 역으로 요구사항 문서를 작성한다고 가정하라 - 이 결과물을 만들기 위해 "원래 무엇이 요구되었어야 하는가"를 빠짐없이 목록화하라 - 결과물에 있지만 사소하거나 자동 생성된 요소도 모두 포함하라 - 추상화하지 말고 구체적으로 써라. "외부 API와 통신한다"가 아니라 "`requests` 2.31 라이브러리로 HTTPS GET 요청을 전송한다"라고 쓰라 - 결과물에 없으면 목록에서 제외하라
2회차 — 숨은 요구 탐지:
방금 작성한 요구사항 명세를 다시 읽고, 다음을 확인하라. 1. 사용자가 명시적으로 요청하지 않았을 가능성이 높은 항목을 별도로 표시하라 (★ 표시) 2. 추상적으로 쓰인 항목이 있으면 구체적으로 다시 써라 3. 스킬 문서의 단계별 절차와 이 요구사항 목록을 대조하라 — 스킬 문서에는 있지만 요구사항에는 없는 것, 또는 그 반대인 것을 명시하라 ★ 표시된 항목이 있으면 해당 목록을 출력하라. 이 항목들이 "의도하지 않은 요구"의 후보다.
두 문서가 손에 있으면, 다음 순서를 따른다.
현재 코드를 _reference/ 디렉터리로 이동한다. 폐기가 아니라 보관이다. 단, AI의 정규 입력에서는 제외한다. 사람은 필요할 때 열어 참조할 수 있지만, AI 컨텍스트에는 들어가지 않는다. Git 브랜치 분리도 병행하면 더 안전하다.
요구사항 명세를 사람이 검토한다. 각 항목에 대해 유지·수정·삭제를 결정한다. ★ 표시된 "의도하지 않은 요구"를 여기서 잡아낸다.
정제된 요구사항과 스킬 문서를 가지고 새 세션을 연다. 이전 세션의 코드를 그대로 붙여넣지 않는다.
새 세션에서 스킬 문서와 정제된 요구사항을 컨텍스트로 주고 작업을 다시 시작한다.
결과물을 요구사항 명세와 대조해 검수한다.
핵심은 3번이다. 이전 세션의 코드를 새 세션에 통째로 넣지 않는다. 넣는 순간 다시 구렁텅이가 시작된다. 코드 대신 두 장의 문서가 다음 작업의 입력이 된다.
"그냥 코드를 잘 수정하면 안 되나?"라는 질문이 자연스럽다. 답은 안 된다이다. 이유는 간단하다.
AI가 생성하는 코드를 읽는 시간이 생산성을 훼손하는 결과로 오인된다. 그걸 하고 있을 시간에 새 코드를 짤 수 있다거나, 바이브 코딩은 무용하다는 회의론에 도달한다. 어떤 원인이든 결과든, 어쨌든 아무리 주석첨삭을 요구한다고 해도 사람이 AI가 출력하고 있는 모든 코드를 읽고 검수하는 것은 물리적으로 불가능하다. 그래서 코드를 검수하는 대신, 코드를 재현할 수 있는 문서를 검수한다. 사람은 코드를 못 읽어도 문서는 읽을 수 있다.
그리고 이 두 문서는 단독으로 쓰이지 않는다. 두 문서를 교차 검증하는 AI 위원회라는 구조가 있고, 이 위원회가 "다른 모듈의 권리를 침해하지 않는가"라는 단 하나의 기준으로 검수한다.
더 깊이 알고 싶다면, 이 글의 원전인 『두 장의 문서 — AI 시대 프로그램 팀장의 개발 방법론』(AICBOK) 을 참조한다. 아래는 이 글에서 다룬 주제가 원전의 어디에 있는지의 안내다.
https://brunch.co.kr/brunchbook/aicbok
수정이 느려지는 구렁텅이 현상 -> 5부 5.3 바이브코딩의 함정
왜 소스 코드를 통째로 넣으면 안 되는가->7부 7.2~7.4 MAD와 미니 MAD, MAD 가드
AI 출력을 AI 입력으로 되먹이는 문제->AICBOK P.5 자기참조 금지 원칙 (10부)
스킬 문서(Skill.md)의 정의와 구조->3부 3.2~3.3 스킬 문서, 역산 작성
요구사항 명세(역기획서)의 정의와 작성법->3부 3.4~3.5 역기획서, 숨은 요구 발견
두 문서의 교차 검증->3부 3.6 이중 검토 구조
AI 위원회의 구성과 운영->4부 전체 AI 위원회
5단계 재시작 절차->5부 5.3 재시작의 구체적 절차
“코드가 아니라 문서를 검수한다”->3부 3.1 + AICBOK P.1 자연어 우선 원칙 (10부)
두 장의 문서가 왜 두 장인가->3부 3.1 최소 충분 조건
코딩은 개발의 극히 일부->1부 1.4 +0.철학
사람의 결정 지점과 서명->4부 4.5 + 0.철학 §3~4
엔터프라이즈 플랫폼과 멀티 에이전트->9부 9.1~9.2 AI 오피스의 현재와 지평
AICBOK 6원칙 요약->10부 AICBOK I
AICBOK 7수행 영역 요약->11부 AICBOK II
지식 체계와 학습 로드맵->12부 AICBOK 지식 체인
© 2026. Kim Dongeun(WhtDrgon) at MEJE Works Corp. All rights reserved.