바이브코딩 다음 단계 — 스펙 기반 개발(SDD)이 뜨는 이유
2주 만에 뚝딱 만든 프로토타입이 3개월째부터 손댈 때마다 무너진다면, 문제는 실력이 아니라 방식입니다. "되는대로 짜기"에서 "스펙 먼저 쓰고 짜기"로 넘어가는 선을 어디에 그어야 하는지, 프로젝트 규모를 기준으로 정리했습니다.
먼저 용어부터. 바이브코딩(vibe coding)은 AI에게 "이런 거 만들어줘"라고 던지고, 결과를 보며 느낌대로 계속 고쳐 나가는 방식입니다. 2025년 2월 안드레이 카르파티가 이름 붙인 뒤, 이 흐름은 눈 깜짝할 새 개발 문화를 통째로 바꿨습니다. 스펙 기반 개발(Spec-Driven Development, SDD)은 반대로 갑니다. 코드를 짜기 전에 "무엇을, 왜 만드는지"를 문서(스펙)로 먼저 확정하고, 그 스펙을 진실의 원천으로 삼아 AI가 코드를 뽑게 하죠.
둘은 라이벌처럼 보이지만, 이 글의 결론을 먼저 말하면 그렇지 않습니다. 문제는 "어느 쪽이 옳은가"가 아니라 "지금 내 프로젝트가 어느 단계에 있는가"입니다.
바이브코딩이 3개월 벽에 부딪히는 이유
현장에서 반복되는 패턴이 하나 있습니다. 업계에서 3개월 벽(three-month wall), 혹은 90일 청구서라고 부르는 현상이죠. 처음 몇 주는 마법 같습니다. 기능이 쏟아지고, 데모가 돌아가고, "이제 개발자 필요 없겠는데?" 소리가 나옵니다. 그러다 대략 3개월째, 분위기가 뒤집힙니다. AI가 만든 코드가 낯설게 느껴지고, 사소한 수정 하나가 디버깅 대장정이 되며, 새 기능을 만드는 시간보다 AI가 고친 걸 다시 고치는 시간이 더 길어집니다.
느낌이 아니라 숫자로도 잡힙니다. 800만 건 넘는 풀 리퀘스트를 분석한 대규모 연구에서, AI 코딩 도구를 도입한 뒤 기술 부채가 30~41% 증가하는 것으로 나타났습니다. 흥미로운 건 부채가 쌓이는 위치입니다. 개별 함수가 아니라 코드베이스 전체 수준에서 뭉칩니다. AI는 "국소적으로는 맞지만 전체 구조는 모르는" 코드를 만들기 때문이죠.
보안은 더 아픕니다. 한 업계 조사에 따르면 바이브코딩 도입률이 84%까지 오르는 동안, 그렇게 생성된 코드의 약 45%에서 취약점이 발견됐습니다. 프로토타입은 2주면 나오지만, 그걸 실서비스로 굳히는 데(에러 처리, 보안, 테스트, 아키텍처 정리) 원래 개발 시간의 2~4배가 든다는 것이 여러 팀의 공통된 증언입니다. 2주짜리 프로토타입이 4~8주짜리 리팩터링 프로젝트로 돌변하는 셈이죠. 참고로 이 3개월 벽이라는 표현 자체가, 카르파티가 바이브코딩을 명명한 지 1년여 만인 2026년 세쿼이아 어센트 발표에서 "그 시대가 저물고 있다"고 말한 시점과 겹칩니다.
스펙 기반 개발(SDD)은 무엇을 바꾸나
SDD의 핵심은 딱 한 가지, 스펙과 구현을 분리하는 것입니다. 곧장 코드로 뛰어드는 대신, 아키텍처를 결정하고 요구사항을 정의해 저장소 안 마크다운 문서로 남깁니다. 이 스펙은 코드와 함께 계속 갱신됩니다. "무엇을 왜 만드는가(스펙)"와 "실제 코드(구현)"가 떨어지면, 팀에게 아주 중요한 변화가 생깁니다.
바로 리뷰의 대상이 바뀐다는 점입니다. 코드가 생성되기 전에 팀원들이 스펙과 계획을 검토합니다. 도메인 리드, PM, 아키텍트가 방향을 미리 교정할 수 있죠. 수천 줄의 AI 생성 코드를 사후에 뜯어보는 게 아니라, 몇 문단의 설계 결정을 먼저 합의하는 방식입니다.
이게 추상적인 이야기가 아니라는 증거가 깃허브 스펙 킷(GitHub Spec Kit)입니다. 2025년 9월 오픈소스(MIT)로 공개된 이 툴킷은 스펙 → 기술 계획 → 작고 테스트 가능한 작업으로 쪼개는 과정을 템플릿과 CLI로 제공합니다. Specify CLI 하나로 프로젝트에 SDD 뼈대를 깔 수 있고, 클로드 코드·커서·코파일럿·제미나이 CLI 등 29종 이상의 AI 코딩 에이전트와 물립니다.
"바이브코딩은 끝났다"는 오해
여기서 흔한 함정 하나. 요즘 "바이브코딩은 죽었다"는 제목이 넘쳐납니다. 그런데 정작 그 표현을 만든 카르파티 본인의 2026년 세쿼이아 발표를 보면 뉘앙스가 다릅니다. 그는 바이브코딩을 버리라고 하지 않았습니다. 대신 이렇게 선을 그었죠.
바이브코딩은 바닥을 끌어올리고(raises the floor), 에이전틱 엔지니어링은 천장을 끌어올린다(raises the ceiling).
— 안드레이 카르파티, 세쿼이아 어센트 2026
바닥을 올린다는 건, 코딩을 배운 적 없는 사람도 일단 뭔가 만들 수 있게 됐다는 뜻입니다. 천장을 올린다는 건, 프로페셔널이 스펙 설계·diff 리뷰·평가 루프로 더 크고 안정적인 것을 만들 수 있다는 뜻이고요. 둘은 다른 층위입니다. 그러니 "무엇이 이겼는가"라는 질문 자체가 틀렸습니다. 실제로 여러 실무 가이드가 입을 모읍니다. 탐색·발견에는 바이브코딩, 굳히기·출시에는 SDD. 경쟁이 아니라 분업입니다.
카르파티가 덧붙인 한 문장이 이 분업의 선을 가장 잘 보여줍니다. "바이브코딩을 했다는 이유로 취약점을 집어넣어선 안 된다. 소프트웨어에 대한 책임은 예전과 똑같이 당신에게 있다." 즉, 결과물에 책임을 져야 하는 순간, 당신은 이미 바이브의 영역을 벗어난 겁니다.
언제 넘어가야 하나 — 프로젝트 규모 기준
그래서 실전 기준입니다. "죽었나 살았나"를 따지지 말고, 내 프로젝트가 어느 칸에 있는지를 보세요. 세 가지 축이 결정합니다. 코드의 수명, 함께 만지는 사람 수, 그리고 책임의 무게입니다.
| 상황 | 수명·팀 | 권장 방식 |
|---|---|---|
| 주말 해커톤·아이디어 검증 | 며칠 · 혼자 | 바이브코딩 (스펙은 오히려 방해) |
| 버려질 프로토타입·데모 | 몇 주 · 혼자~2인 | 바이브코딩 |
| 계속 고쳐 쓸 사이드 프로젝트 | 몇 달 · 1~2인 | 경계선 — 핵심만 스펙 |
| 여러 명이 만지는 실서비스 | 분기~년 · 3인+ | SDD |
| 규제·감사·보안 민감 시스템 | 장기 · 팀 | SDD (감사 증적 필수) |
| 레거시 현대화·재구축 | 장기 · 팀 | SDD (숨은 가정 표면화) |
기억하기 쉬운 신호 세 개로 압축하면 이렇습니다. 첫째, 같은 프로젝트를 몇 주 이상 이어서 고칠 것 같다. 둘째, 나 말고 다른 사람이 이 코드를 읽어야 한다. 셋째, 이게 터지면 내가 책임진다. 셋 중 하나라도 "그렇다"면, 슬슬 스펙을 쓸 때입니다. 반대로 셋 다 "아니다"라면, 스펙 쓰느라 시간 버리지 말고 그냥 바이브로 달리세요. 판단이 뭘 만들지 아직 모르는 단계에서는 스펙이 속도를 갉아먹습니다.
오늘 바이브에서 SDD로 넘어가는 3단계
거창한 도구 도입부터 하지 마세요. 지금 손에 있는 AI 에이전트로 오늘 바로 시작할 수 있습니다.
있는 걸 먼저 스펙으로 역산한다
이미 바이브로 짠 코드가 있다면, AI에게 "이 코드가 무엇을 하는지 스펙 문서로 정리해줘"라고 시키세요. 레거시 현대화가 SDD의 대표 유스케이스인 이유가 여기 있습니다. 숨어 있던 가정이 문서 위로 올라옵니다.
다음 기능은 코드가 아니라 스펙부터
새 기능을 만들 때 곧장 "만들어줘" 하지 말고, "무엇을·왜·성공 기준은"을 마크다운 한 장으로 먼저 쓰고 리뷰합니다. 이 한 장을 저장소에 spec.md로 커밋해 두면, 나중에 모델이 좋아졌을 때 다시 프롬프트를 짤 필요 없이 재생성만 하면 됩니다.
스펙 → 계획 → 작은 작업으로 쪼갠다
스펙을 곧바로 코드로 던지지 말고, 기술 계획을 세운 뒤 테스트 가능한 작은 작업 단위로 나눠 에이전트에게 넘깁니다. 스펙 킷 같은 툴킷은 이 흐름을 자동화하지만, 없어도 원리는 같습니다. 큰 덩어리 대신 검증 가능한 조각으로.
질문을 바꾸면 답이 보인다
바이브코딩은 끝나지 않았습니다. 다만 자기 자리를 찾았을 뿐입니다. 무엇을 만들지 탐색할 때는 바이브로 빠르게, 오래 쓸 것을 견고하게 만들 때는 스펙으로 단단하게. 그 사이 어디에 선을 그을지는 트렌드가 아니라 당신 프로젝트의 수명·팀·책임이 정합니다.
그러니 "바이브코딩 이제 하면 안 되나요?"라고 묻는 대신, 이렇게 물어보세요. 이 코드, 3개월 뒤에도 내가 고치고 있을까? 답이 "그렇다"에 가까울수록, 스펙을 쓸 시간이 다가온 겁니다.