바이브코딩 3개월이면 망한다는 불편한 진실

주말에 만든 MVP가 3개월 만에 폐기됐다

플래시카드 앱을 만든다고 치자. AI에게 "편집 가능한 카드, 애니메이션, 로컬 저장소 지원하는 플래시카드 앱 만들어줘"라고 말하면 몇 분 안에 작동하는 프로토타입이 나온다. 이전 같으면 한 분기가 걸릴 작업이 주말이면 끝난다. Red Hat 개발자 Todd Wardzinski는 이 방식으로 5개 컨셉을 구현하고 3개의 MVP를 수개월 만에 완성했다고 밝혔다.

여기까지는 바이브 코딩의 장밋빛 면이다. 문제는 그 다음이다.

Wardzinski가 Red Hat Developer 블로그에 게재한 글의 제목은 "The Uncomfortable Truth About Vibe Coding"이다. 불편한 진실. 그가 직접 경험하고 관찰한 패턴은 이렇다. 바이브 코딩으로 만든 프로젝트는 약 3개월 후부터 무너지기 시작한다. 작은 변경 하나가 4개 이상의 기능을 깨뜨린다. AI에게 수정을 맡기면 2차 문제가 생긴다. 코드베이스가 인간의 인지 용량을 초과하는 시점이 오면, 더 이상 손댈 수 없는 상태가 된다.

Reddit에서 한 개발자가 남긴 말이 이 현상을 정확히 요약한다. "AI는 하나를 고치고 열 개를 망친다(AI will fix one thing but destroy 10 other things)." 바이브 코딩의 속도가 빠를수록, 이 임계점도 빨리 온다.

바이브 코딩이 실패하는 구조적 이유

바이브 코딩의 핵심은 자연어로 의도를 전달하고, AI가 코드를 생성하는 것이다. 개발자는 결과물의 "분위기(vibe)"만 확인하고 넘어간다. Andrej Karpathy가 2025년 초에 이 용어를 만들었을 때, 의도적으로 "코드를 깊이 읽지 않는다"는 전제를 포함시켰다.

이 전제가 프로토타입 단계에서는 합리적이다. 검증하려는 것은 아이디어의 가능성이지, 코드의 품질이 아니다. 하지만 프로젝트가 성장하면 상황이 달라진다. Wardzinski는 이 과정을 세 단계로 설명한다.

첫 번째 단계는 **탐색(exploration)**이다. 프롬프트를 던지고, AI가 생성한 결과를 빠르게 반복한다. 프로토타입이 나오고, 작동하는 것처럼 보인다. 이 단계에서 개발자의 만족도는 최고점이다.

두 번째 단계는 **축적(accumulation)**이다. 기능이 추가되고, 코드베이스가 커진다. 프롬프트는 생성 직후 의미를 잃는다. AI가 왜 특정 구조를 선택했는지, 어떤 엣지 케이스를 고려했는지 기록이 없다. 코드 자체가 유일한 문서인데, 그 코드를 깊이 읽지 않는 것이 바이브 코딩의 정의다.

세 번째 단계가 **붕괴(collapse)**다. 하나를 고치면 넷이 깨진다. AI에게 수정을 요청하면, AI는 이전 맥락을 완전히 기억하지 못한 채 새로운 해결책을 제시한다. 매번 다른 결과가 나오는 현상을 Wardzinski는 **"기능 플리커링(functionality flickering)"**이라 부른다. 같은 프롬프트를 줘도 다른 코드가 나오고, 이전에 작동하던 기능이 사라졌다 나타났다를 반복한다.

이 패턴이 왜 3개월 근처에서 발생하는지도 설명이 된다. 대부분의 사이드 프로젝트와 MVP가 3개월쯤 되면 "최초 설계에 없던 기능"을 추가하기 시작하기 때문이다. 최초 프롬프트의 범위를 넘어서는 순간, 사양 없는 코드는 방향을 잃는다.

두더지 잡기 게임이 된 코드베이스

Wardzinski가 사용한 비유는 "두더지 잡기(whack-a-mole)"다. 하나를 누르면 다른 데서 튀어나온다. 바이브 코딩에서 이 현상이 특히 심각한 이유는, 코드의 의존성 구조를 개발자가 파악하지 못하는 상태에서 변경이 이루어지기 때문이다.

전통적인 개발에서도 스파게티 코드는 발생한다. 하지만 전통적 개발에서는 최소한 코드를 작성한 사람이 구조를 이해하고 있다. 바이브 코딩에서는 그 전제가 사라진다. AI가 생성한 코드의 내부 로직을 개발자가 모르는 상태에서, 다시 AI에게 수정을 맡긴다. AI도 이전 생성물의 전체 맥락을 유지하지 못한다. 결과적으로 아무도 코드를 온전히 이해하지 못하는 상태가 된다.

이 문제를 가장 잘 드러내는 지표가 있다. GitHub의 2023년 연구에서 문서화된 "기능 플리커링" 현상이다. AI가 코드를 재생성할 때마다 구현 방식이 미세하게 달라진다. 변수 이름이 바뀌고, 함수 구조가 변하고, 에러 처리 방식이 달라진다. 한 번의 변경은 사소하지만, 누적되면 코드베이스 전체의 일관성이 무너진다.

Wardzinski는 이 상태를 **"디지털 모래성(digital sandcastle)"**이라 표현했다. 다음 프롬프트가 쓸어갈 모래성. 멋지게 보이지만, 구조적으로 취약하다.

이건 AI의 능력 문제가 아니다. 사양의 부재 문제다. 건축에서 설계도 없이 집을 짓는 건 불가능하다. 소프트웨어에서는 가능하다. 바이브 코딩이 그 가능성을 극대화했다. 하지만 설계도 없이 지은 집이 3개월 후에 어떻게 되는지는 건축 전공이 아니어도 알 수 있다.

더 근본적인 문제가 있다. 바이브 코딩으로 만든 코드베이스는 리팩토링이 거의 불가능하다. 리팩토링의 전제는 기존 코드의 동작을 정확히 이해하고, 구조만 바꾸는 것이다. 동작을 이해하지 못하는 코드는 구조를 바꿀 수 없다. AI에게 "이 코드를 리팩토링해줘"라고 요청하면, AI는 기존 구조를 유지하는 대신 자신이 선호하는 새로운 구조로 재작성한다. 겉보기에는 깔끔해지지만, 기존 코드가 암묵적으로 처리하던 엣지 케이스가 사라진다. 리팩토링이 아니라 재작성이다. 그리고 재작성은 새로운 버그를 만든다.

사양이 코드의 단일 진실 공급원이 되어야 한다

Wardzinski가 제시하는 해법은 **사양 기반 개발(spec-driven development)**이다. 프롬프트 대신 명확한 사양 문서를 코드의 단일 진실 공급원(single source of truth)으로 삼는 방식이다.

핵심 원칙은 네 가지다.

첫째, 사양을 권위 있는 청사진으로 취급한다. 코드가 아니라 사양이 "정답"이다. 코드에 버그가 있으면 사양에 맞게 코드를 재생성하면 된다. 프롬프트와 달리, 사양은 생성 후에도 유효하다.

둘째, 코드를 디버깅하는 대신 사양을 수정한다. 기능에 문제가 있으면 코드를 직접 고치는 대신, 사양의 해당 부분을 수정하고 AI에게 재생성을 요청한다. 이렇게 하면 변경의 의도가 문서에 남는다.

셋째, 사양을 버전 관리한다. Git에 코드만 커밋하는 대신, 사양 문서도 함께 관리한다. 코드의 변경 이력뿐 아니라 의사결정의 변경 이력까지 추적할 수 있다.

넷째, AI의 역할을 실행자로 한정한다. AI는 사양을 구현하는 도구이지, 설계를 결정하는 주체가 아니다. 아키텍처, 엣지 케이스, 제약 조건은 인간이 사양에 명시하고, AI는 그대로 구현한다.

이 접근법이 바이브 코딩의 장점을 완전히 포기하는 것은 아니다. Wardzinski는 테스트로 검증 가능한 단위(unit) 수준에서는 바이브 코딩이 여전히 유효하다고 말한다. 함수 하나, 컴포넌트 하나를 AI에게 맡기고 테스트로 확인하는 것은 합리적이다. 문제는 이 단위들이 모여 시스템을 이루는 과정이다. 시스템 수준의 설계는 프롬프트가 아니라 사양이 담당해야 한다.

Amazon, GitHub, Tessl이 움직이는 이유

바이브 코딩의 한계가 명확해지면서, 사양 기반 도구들이 빠르게 등장하고 있다. 이 흐름은 단순한 트렌드가 아니라, 산업이 바이브 코딩의 실패에서 교훈을 얻고 있다는 신호다.

Amazon Kiro는 2025년 말에 발표된 AI 코딩 도구다. 기존 AI 코딩 도구와 달리, 프롬프트가 아닌 구조화된 사양을 입력으로 받는다. 개발자가 기능의 요구사항, 제약 조건, 테스트 기준을 사양 문서로 작성하면, AI가 해당 사양에 맞춰 코드를 생성한다. 사양이 변경되면 코드도 자동으로 재생성된다.

GitHub Spec Kit는 GitHub가 내놓은 사양 관리 프레임워크다. 코드 저장소에 사양 문서를 함께 관리하고, PR 단위로 사양 변경과 코드 변경을 연결한다. 2023년에 GitHub가 SpecLang이라는 실험적 프로젝트를 진행한 적 있는데, Spec Kit는 그 연장선이다. 아직 상용화 단계는 아니지만, GitHub가 이 방향에 투자하고 있다는 것 자체가 의미 있다.

Codeplain은 사양을 평문(plain text)으로 작성하되, AI가 파싱할 수 있는 구조를 갖춘 형식을 제공한다. 개발자와 AI 사이의 중간 언어 역할을 한다. 사양을 작성하면 코드가 나오고, 코드에 문제가 있으면 사양을 수정하는 순환 구조를 지원한다.

Tessl은 더 급진적인 접근이다. 아예 "사양이 곧 코드"라는 철학을 표방한다. 사양 문서를 작성하면 실행 가능한 코드가 자동으로 도출되는 시스템을 구축하고 있다. 전통적인 코드 에디터 대신 사양 에디터를 중심으로 개발 워크플로우를 재설계한다.

이 도구들의 공통점은 하나다. 비구조적 프롬프트만으로는 유지보수 가능한 소프트웨어를 만들 수 없다는 인식이다. 프롬프트는 일회성이다. 사양은 영구적이다. 이 차이가 3개월 벽을 만든다.

흥미로운 건 이 흐름이 소프트웨어 엔지니어링의 오래된 교훈과 정확히 일치한다는 점이다. 1990년대에 "코드가 곧 문서다"라는 주장이 유행했다. 결과는 문서 없는 레거시 시스템의 난립이었다. 2000년대 애자일 운동이 "작동하는 소프트웨어가 포괄적인 문서보다 중요하다"고 선언했을 때도, "문서가 불필요하다"는 뜻은 아니었다. 바이브 코딩은 "코드가 곧 문서다"의 AI 버전이다. 30년 전의 실수를 새로운 도구로 반복하고 있는 셈이다.

기술력 없는 바이브 코딩은 통하지 않는다

바이브 코딩 열풍과 함께 "이제 비전공자도 코딩할 수 있다"는 이야기가 넘쳐났다. Wardzinski는 이 서사에 명확한 선을 긋는다. 기술적 역량은 **여전히 협상 불가(non-negotiable)**라고.

AI가 코드를 생성해도, 그 코드가 올바른지 판단하려면 아키텍처를 이해해야 한다. 의존성 구조를 파악해야 한다. 제약 조건과 트레이드오프를 알아야 한다. 바이브 코딩이 진입 장벽을 낮춘 건 사실이지만, 장벽이 사라진 건 아니다.

Wardzinski는 역사적 비유를 든다. 어셈블리에서 고급 언어(C, Python 등)로의 전환이 개발을 대중화했지만, 프로그래밍의 기본 원리를 이해하는 요구는 사라지지 않았다. 포인터를 직접 다루지 않아도 메모리 관리 개념은 알아야 한다. SQL을 직접 쓰지 않아도 데이터베이스 설계 원칙은 이해해야 한다.

AI 코딩도 마찬가지다. 프롬프트를 잘 쓰는 능력은 코딩 능력을 대체하지 않는다. 보완할 뿐이다. Wardzinski의 표현을 빌리면, "마법은 바이브의 강도에 있지 않다. 자신이 무엇을 원하는지 정확히 알고, AI조차 오해할 수 없을 만큼 명확하게 표현하는 데 있다."

이 말은 뒤집으면 이렇게 된다. 자신이 무엇을 원하는지 모르는 사람은 아무리 좋은 AI를 써도 원하는 결과를 얻을 수 없다. 프로토타입은 만들 수 있다. 데모는 보여줄 수 있다. 하지만 3개월 후에도 작동하는 소프트웨어를 만들려면, 소프트웨어가 어떻게 작동하는지 이해하는 사람이 필요하다.

이건 AI 비관론이 아니다. 현실론이다. AI가 코드를 쓰는 속도는 인간을 압도한다. 하지만 코드를 쓰는 것과 소프트웨어를 만드는 것은 다른 일이다. 코드는 소프트웨어의 재료이지, 소프트웨어 자체가 아니다. 재료를 빠르게 생산하는 도구가 생겼다고 해서, 설계 없이 건물을 올릴 수 있게 된 건 아니다.

2024년 Uplevel 연구가 이를 뒷받침한다. GitHub Copilot 사용자는 코드를 55% 빠르게 작성했지만, 버그는 41% 더 많았다. 속도와 품질 사이의 트레이드오프가 데이터로 확인된 것이다. 바이브 코딩은 이 트레이드오프를 극단으로 밀어붙인다. 코드 작성 속도는 수십 배 빨라지지만, 코드를 이해하는 사람은 0명이 될 수 있다. Copilot의 41%가 바이브 코딩에서는 어떤 숫자가 될지, 아직 대규모 연구는 없다. 하지만 3개월 후 프로젝트가 폐기되는 비율이 그 답의 일부일 것이다.

바이브 코딩의 올바른 사용 범위

Wardzinski의 주장을 정리하면, 바이브 코딩이 "쓸모없다"는 것이 아니다. "만능이 아니다"는 것이다. 그가 제시하는 가이드라인은 명확하다.

바이브 코딩이 유효한 영역은 다음과 같다.

프로토타이핑과 컨셉 검증. 아이디어가 가능한지 빠르게 확인하는 단계에서는 사양 작성이 오히려 과잉이다. 프롬프트로 빠르게 만들고, 빠르게 버리는 것이 합리적이다. MVP의 목적은 학습이지 배포가 아니다.

테스트 가능한 단위 개발. 함수 하나, API 엔드포인트 하나처럼 입력과 출력이 명확한 단위에서는 AI에게 구현을 맡기고 테스트로 검증하면 된다. 단위가 작을수록 AI의 "기능 플리커링"이 미치는 영향도 작다.

학습과 탐색. 새로운 라이브러리나 프레임워크를 배울 때, AI에게 예제 코드를 요청하고 실행하면서 이해하는 과정은 효과적이다. 공식 문서를 읽는 것보다 AI가 생성한 실행 가능한 예제를 직접 돌려보는 것이 학습 속도를 높일 수 있다.

반면, 바이브 코딩이 위험한 영역은 이렇다.

유지보수가 필요한 프로덕션 코드. 3개월 이상 운영할 소프트웨어는 사양이 필요하다. 사양 없이 시작하면, 나중에 사양을 역공학하는 비용이 처음부터 작성하는 비용을 초과한다.

팀 프로젝트. 혼자 바이브 코딩하면 최소한 자신의 머릿속에 맥락이 있다. 여러 명이 바이브 코딩하면 각자의 프롬프트가 다르고, 생성된 코드의 스타일이 달라, 코드베이스가 빠르게 일관성을 잃는다. 팀원 A가 만든 함수를 팀원 B의 AI가 다른 방식으로 재작성하는 일이 일상이 된다.

금융, 의료, 인프라처럼 오류 비용이 높은 영역. 앞서 다룬 Moonwell 사건이 대표적이다. 178만 달러가 증발한 버그는 곱셈 하나를 빠뜨린 것이었다. 바이브 코딩의 "깊이 읽지 않는다"는 전제가 가장 치명적으로 작동하는 곳이다. 의료 소프트웨어에서 투약량 계산이 틀리거나, 인프라 코드에서 방화벽 규칙이 누락되면, 그 결과는 금전적 손실을 넘어선다.

모래성을 짓는 속도가 아니라 설계도의 정밀도

바이브 코딩이 소프트웨어 개발의 진입 장벽을 낮춘 건 부정할 수 없다. 몇 분 만에 작동하는 앱이 나오는 경험은 강력하다. 그 경험이 "나도 개발자가 될 수 있다"는 기대를 만들었고, 그 기대가 수많은 사이드 프로젝트와 스타트업의 시작점이 됐다.

하지만 Wardzinski가 던지는 질문은 시작이 아니라 그 이후에 대한 것이다. 3개월 후에도 작동하는가. 6개월 후에 기능을 추가할 수 있는가. 1년 후에 팀원이 바뀌어도 유지할 수 있는가. 이 질문에 "예"라고 답하려면, 프롬프트 이상의 것이 필요하다.

물론 사양 기반 개발이 만능 정답인지는 아직 검증 중이다. Amazon Kiro, GitHub Spec Kit, Codeplain, Tessl 같은 도구들이 시장에 나오고 있지만, 아직 대규모로 채택된 사례는 제한적이다. 사양을 작성하는 데 드는 시간이 바이브 코딩의 속도 이점을 상쇄할 수 있다는 비판도 있다.

그러나 방향은 분명하다. 산업은 "빠르게 만들기"에서 **"지속 가능하게 만들기"**로 무게 중심을 옮기고 있다. 바이브 코딩의 열풍이 가라앉고 있다는 뜻이 아니다. 바이브 코딩의 한계가 인식되면서, 그 한계를 보완하는 방향으로 도구와 방법론이 진화하고 있다는 뜻이다.

Wardzinski의 마지막 문장이 핵심을 찌른다. "지속 가능한 소프트웨어는 규율을 요구한다. 그것 없이는, 프로젝트는 다음 프롬프트가 쓸어갈 디지털 모래성이 된다."

결국 바이브 코딩의 3개월 벽은 AI의 한계가 아니라 방법론의 한계다. AI는 점점 더 똑똑해질 것이다. 컨텍스트 윈도우는 넓어지고, 코드 생성의 정확도는 올라갈 것이다. 하지만 그것이 사양의 필요성을 제거하지는 않는다. 오히려 AI가 강력해질수록, 명확한 사양의 가치는 더 커진다. 더 강력한 도구에는 더 정밀한 지시가 필요하기 때문이다.

바이브 코딩의 마법은 모래성을 빠르게 짓는 데 있다. 하지만 소프트웨어 엔지니어링의 본질은 모래성을 짓는 속도가 아니라, 콘크리트 건물의 설계도를 그리는 정밀도에 있다. AI가 아무리 빠르게 코드를 생성해도, 그 코드가 어디를 향하는지 모르면 속도는 의미를 잃는다. 3개월이라는 시간은 그 사실을 깨닫기에 충분하고, 깨달은 뒤에 돌이키기에는 부족하다.

출처:

• The Uncomfortable Truth About Vibe Coding — Red Hat Developer
• How Vibe Coding Is Killing Open Source — Hackaday
• Vibe-Coded Oracle in $1.8M Blowup — Protos
• Amazon Kiro: Spec-Driven AI Development — Amazon
• GitHub Spec Kit — GitHub Blog