스펙 기반 개발과 바이브 코딩: 워터폴?

사실의 원천으로서의 스펙, 아니면 느린 의식인가?

Page content

스펙 기반 개발(Spec-Driven Development)은 2026년에 바이브 코딩의 방향성 상실(drift)에 대한 진지한 개발자의 해답으로 등장했습니다.

그 논리는 단순합니다: AI 에이전트가 즉흥적인 프롬프트가 아니라 검토된 스펙을 기반으로 구현할 때 더 나은, 그리고 더 일관된 출력을 생성합니다. 이론적으로는 반박하기 어렵습니다.

하지만 현실에서는 Hacker News에서는 이를 “워터폴의 부활(Waterfall Strikes Back)“이라고 불렀습니다.

양쪽 모두 일리가 있습니다.

Spec-Driven Development versus Vibe Coding

바이브 코딩 시대의 스펙 기반 개발(SDD)의 필요성

바이브 코딩 – 느슨한 프롬프트를 작성하고 AI 에이전트가 생성한 결과를 바탕으로 반복적으로 개선하는 방식 – 은 작고 탐색적인, 그리고 일회용 작업에서 놀라운 효과를 발휘합니다. 2025년 상반기 동안 이것이 지배적인 AI 코딩 패턴이었습니다. 개발자들은 스크립트, 프로토타입, 그리고 단순한 도구들을 그 어느 때보다 빠르게 출시했습니다.

그러나 프로젝트가 커졌습니다. 멀티 파일 기능들이 방향을 잃기 시작했습니다. 1세션에서 확립된 제약 조건들은 3세션이 되자 잊혀졌습니다. 보안 가정이 빠졌습니다. 에이전트가 의도의 지속적인 기억이 없었기 때문에 기능 개발 도중 아키텍처 결정이 변경되었습니다.

스펙 기반 개발(SDD)은 이러한 문제에 대한 규율 있는 대응으로 등장했습니다. 핵심 주장은 다음과 같습니다: 스펙을 프롬프트가 아닌 중심 산출물로 만드세요. 먼저 요구사항, 설계, 그리고 작업 계획을 작성하세요. 그리고 에이전트가 이러한 산출물을 기반으로 한 조각씩 구현하도록 하세요. 스펙은 버전 관리되고 업데이트되어야 합니다.

GitHub Spec Kit, Kiro, Claude Code SDD 워크플로우, 그리고 BMAD를 포함한 Superpowers와 같은 다른 커뮤니티 스캐폴드들은 모두 이 아이디어의 구현입니다. 툴링은 실재합니다. 관심도 실재합니다. 반발도 실재합니다.

바이브 코딩이 잘하는 것

바이브 코딩을 무시하기 전에, 그것이 잘하는 것이 무엇인지 정확히 파악하는 것이 중요합니다.

탐색적 프로토타입. 무엇을 구축할지 확신이 없을 때, 가장 빠른 경로는 거친 무언가를 만들어보고 그에 반응하는 것입니다. SDD는 무엇을 스펙으로 작성해야 하는지 아는 것을 요구합니다. 아직 모른다면, 스펙은 시기상조입니다.

UI 실험. 시각적 레이아웃과 상호작용 느낌은 사전에 스펙으로 정의하기 어렵습니다. 바이브 코딩은 옵션들을 빠르게 보고, 대부분을 폐기하고, 실제로 맞는 것으로 수렴할 수 있게 해줍니다. 요구사항 문서가 여기에서는 도움이 되지 않습니다.

일회용 자동화. 일회용 스크립트, 데이터 추출 작업, 마이그레이션 헬퍼 – 이러한 것들은 거의 설계 문서가 필요하지 않습니다. 약간 틀리는 비용은 낮습니다. 느리고 의식적인 프로세스의 비용은 실재합니다.

빠른 피드백. 무언가를 빠르게 배워야 할 때 – 이 API가 내가 생각하는 대로 작동하는가? – 바이브 코딩은 학습 루프를 분 단위로 줄여줍니다. SDD는 아무런 이득 없이 그 속도를 늦출 것입니다.

실수란 이러한 컨텍스트에서의 성공 패턴을 실제 제약 조건, 실제 사용자, 그리고 틀렸을 때의 실제 결과가 있는 프로덕션 기능에 적용하는 것입니다.

바이브 코딩이 무너지는 지점

바이브 코딩은 범위와 중요도가 증가할 때 예측 가능하게 열화됩니다.

멀티 파일 변경. 기능이 5개 이상의 파일을 건드리기 시작하면, 에이전트의 컨텍스트 윈도우는 불변 조건(invariants)을 추적하는 것을 멈추기 시작합니다. 설계 문서가 없다면, 각 프롬프트는 이전 세션에서 확립되고 잊혀진 컨텍스트를 재확립해야 합니다.

아키텍처 드리프트. 명시적인 비목표(non-goals)가 없으면, 에이전트는 무언가를 구현합니다. 에이전트는 합리적으로 보인다는 이유로 캐싱 레이어를 추가합니다. 세션이 3개 지난 후, 캐싱 가정은 데이터 모델에 고착되어 제거하는 데 비용이 듭니다.

잊힌 제약 조건. “인증된 사용자만 이 작업을 트리거할 수 있다"는 것은 요구사항 문서에 있는 문장입니다. 바이브 코딩 세션에서는, 1세션에서 한 번 언급했고 에이전트가 4세션에서 새로운 엔드포인트를 작성할 때 기억하지 못하는 것이 됩니다.

숨겨진 보안 가정. 인증 규칙, 입력 검증 경계, 시크릿 처리 – 이들은 에이전트가 정확한 제약이 있는 코드가 아닌, 그럴듯하게 작동하는 코드를 최적화할 때 놓치기 쉬운 암묵적 요구사항의 정확히 그런 종류입니다.

팀 핸드오프. 반복적인 프롬프팅을 통해 구축했다면, 무엇이 결정되고 왜 결정되었는지를 기록하는 산출물은… git 로그입니다. 그걸로 행운을 빕니다.

스펙 기반 개발이 변화시키는 것

SDD는 반복을 제거한다고 주장하지 않습니다. 좋은 버전의 SDD는 명시적으로 반복적입니다. 그들이 변화시키는 것은 반복이 일어나는 장소입니다. 전체 정의 – SDD가 TDD, BDD, 그리고 형식적 방법론과 어떻게 다른지 포함 – 에 대해서는 What Is Spec-Driven Development?를 참조하세요.

코드에서 반복하고 diff에서 의도를 추론하는 대신, 스펙에서 반복하고 그 다음에 구현합니다. 스펙은 무엇이 결정되었는지, 왜 결정되었는지, 그리고 무엇이 범위 밖인지 기록하는 산출물이 됩니다 – 이는 Architecture Decision Records 와 유사한 기능을 수행하지만, 시스템 수준의 선택이 아닌 기능 의도를 중심으로 합니다. 코드는 그 의도를 구현합니다.

SDD는 5단계 – 스펙 작성, 계획, 작업, 구현, 검증 – 를 통해 진행되며, 각 단계마다 인간 리뷰 게이트가 있습니다. 전체 프로세스, 템플릿, 그리고 체크포인트에 대해서는 Spec-Driven Development Workflow From Requirements to Code를 참조하세요. 에이전트는 대부분의 단계에 참여하지만, 구현이 시작되기 전에 인간이 산출물을 검토합니다. 그 검토 단계가 SDD와 바이브 코딩의 핵심적인 차이입니다.

개발자들이 이를 워터폴이라고 부르는 이유

워터폴 비판은 틀리지 않았습니다. 그것은 단지 나쁜 SDD를 겨냥한 것이지, SDD 자체를 겨냥한 것이 아닙니다.

구체적인 실패 모드는 긴 사전 계획입니다. 워터폴의 정의적인 특징은 주나 달까지 늘어지는 피드백 루프입니다: 요구사항 단계, 설계 단계, 구축 단계, 테스트 단계, 출시. 피드백은 늦게 도착합니다. 설계 가정이 틀렸다는 것을 발견할 때쯤이면, 이미 그 위에 몇 주 동안 구축해 왔습니다.

개발자가 Spec Kit을 사용하여 코드를 한 줄도 작성하기 전에 200줄짜리 작업 목록을 생성하고, 에이전트가 무언가에 손을 대기 전에 요구사항 문서를 다듬는 데 이틀을 보내는 경우, 그것이 워터폴입니다. UML 대신 마크다운을 사용한 워터폴이지만, 실패 모드는 동일합니다.

한 HN 댓글 작성자는 작은 CLI 툴에 Spec Kit을 사용하여 “코드를 보기 전에 너무 느리고, 조정(tweaking)이 너무 많다"고 발견했습니다. 그것이 나쁜 버전입니다. 그 사용자는 그 작업을 위해 그것을 거부할 권리가 있었습니다.

유용한 비판은 “스펙은 나쁘다"가 아닙니다. 그것은 “피드백 전에 긴 사전 계획은 나쁘다"입니다. 그것은 다른 주장입니다.

유용한 중간 지점

좋은 SDD는 스펙을 작게 유지하고 구현을 일찍 시작함으로써 워터폴 함정을 피합니다.

작은 스펙. 단일 기능에 대한 요구사항 문서는 한 화면에 맞아야 합니다. 스펙이 10페이지라면, 그것은 플랫폼 설계이거나 더 작은 기능으로 분할해야 합니다. 너무 큰 스펙은 검토에 너무 오래 걸리고 빠르게 구식이 됩니다.

짧은 작업 조각. 각 작업은 단일 에이전트 세션에서 구현 가능하고, 작은 diff로 리뷰 가능하며, 격리되어 테스트 가능해야 합니다. 작업이 너무 크면, 구현 루프가 늘어지고 스펙-코드 매핑을 검증하기 어려워집니다.

조기 구현. 첫 번째 작업을 스펙으로 작성하고, 구현하고, 검증한 후 다음 작업으로 넘어가세요. 무언가를 구현하기 전에 모든 것을 스펙으로 작성하지 마세요. 첫 번째 구현은 스펙에서 틀린 것들을 드러낼 것입니다. 계속하기 전에 스펙을 업데이트하세요.

살아있는 스펙. 현실이 설계와 다르면 – 그리고 그것은 그럴 것입니다 – 스펙을 업데이트하세요, 코드만 업데이트하는 것이 아니라. 스펙은 실제로 구축된 것을 반영할 때만 유용합니다.

테스트로서의 실행 가능한 피드백. 모든 수용 기준은 최소 하나의 테스트에 매핑되어야 합니다. 테스트 스위트는 스펙의 기계 가독 버전입니다. 스펙에 “인증된 사용자만 이 작업을 트리거할 수 있다"고 적혀 있다면, 인증되지 않은 요청이 거부되는지 확인하는 테스트가 있어야 합니다.

이 하이브리드 – 작은 스펙, 짧은 작업, 조기 구현, 살아있는 문서 – 가 실제로 작동하는 것입니다. 그것은 바이브 코딩도 아니고 워터폴도 아닙니다. 그것은 지속 가능한 산출물을 가진 통제된 반복입니다.

SDD가 바이브 코딩보다 나은 경우

틀리는 비용이 실재할 때 SDD를 사용하세요 – 경량 SDD라도.

위험한 비즈니스 로직. 청구, 권한, 데이터 마이그레이션, 멱등성 – 잘못된 동작이 비용이 크거나 되돌리기 어려운 모든 로직. 바이브 코딩은 이러한 종류의 요구사항을 암묵적으로 남깁니다. SDD는 구현 전에 그것들을 명시적이고 리뷰 가능하게 만듭니다.

프로덕션 API 변경. 공개 또는 내부 API 계약에 대한 모든 변경은 설계 문서가 있어야 합니다. 설계 문서는 에이전트가 호출자를 깨뜨리는 코드를 작성하기 전에 리뷰하는 것입니다.

멀티 에이전트 워크플로우. 여러 에이전트가 기능의 다른 부분을 구현할 때, 스펙은 공유된 진실의 원천입니다. 없다면, 각 에이전트는 로컬적으로 최적화하고 조각들이 맞지 않을 수 있습니다.

팀 핸드오프. 다른 개발자나 다른 에이전트가 이 작업을 계속할 경우, 스펙은 핸드오프 산출물입니다. git 로그와 README만으로는 충분하지 않습니다.

중요한 리팩터링. 핵심 추상화를 건드리는 리팩터링은 무엇이 동일하게 유지되어야 하는지(동작)와 무엇이 변경될 수 있는지를(구조) 명시적으로 선언해야 합니다. 없다면, 에이전트는 보존된 것으로 생각했던 계약을 깨뜨릴 수 있습니다.

바이브 코딩이 여전히 더 나은 경우

SDD는 오버헤드입니다. 때로는 오버헤드가 그 값을 하지 않습니다.

빠른 스크립트. 파일을 이름 변경하거나 JSON을 변환하는 50줄짜리 스크립트는 요구사항 문서가 필요하지 않습니다. 프롬프트를 작성하고, 출력을 확인하고, 출시하세요.

실험. 접근법이 실행 가능한지 배우는 중이라면 – API 탐색, 라이브러리 테스트, 가설 검증 – 구조가 아닌 속도가 필요합니다. 먼저 실험하고, 실험이 성공하면 스펙으로 작성하세요.

UI 스케치. 상호작용 설계는 스펙으로 작성하는 것보다 보는 것이 좋습니다. 거친 변형들을 빠르게 여러 개 구축하고, 보는 것에 반응하고, 실제로 출시할 것만 스펙으로 작성하세요.

일회용 자동화. 일회용 스크립트, 데이터 가져오기, 마이그레이션 헬퍼 – 약간 틀린 결과의 비용은 보통 낮고, 산출물은 사용 후 결국 삭제될 것입니다.

솔로 프로토타입. 이 코드를 볼 유일한 사람이 당신이고 목표가 프로덕션이 아닌 학습이라면, 바이브 코딩이 더 빠르고 단점이 제한적입니다.

간단한 의사결정 프레임워크

실용적인 질문은 “SDD 또는 바이브 코딩인가?“가 아닙니다. 그것은 “이 특정 작업에 얼마나 많은 스펙이 필요한가?“입니다.

바이브 코딩을 사용하는 경우:

  • 작업이 하루 미만
  • 탐색하거나 학습 중
  • 산출물이 일회용이거나 낮은 중요도
  • 이 작업에 손을 대는 유일한 사람
  • 정확성보다 피드백 속도가 중요

경량 SDD를 사용하는 경우:

  • 작업이 2일 이상
  • 여러 파일이 영향 받음
  • 명시적인 보안 또는 정확성 요구사항이 있음
  • 다른 사람이나 에이전트가 작업을 계속함
  • 요구사항에 매핑되는 테스트를 작성해야 함

완전한 SDD를 사용하는 경우:

  • 기능이 공개 인터페이스 또는 데이터 계약에 영향
  • 여러 에이전트 또는 팀 멤버가 관여
  • 조직이 구현 전에 설계 리뷰를 요구
  • 규정 준수 또는 감사 추적이 필요

가장 흔한 실수는 경량 SDD만 필요한 작업에 완전한 SDD를 적용하고, 최소한 경량 SDD가 필요한 작업에 스펙을 전혀 적용하지 않는 것입니다. 어느 수준을 선택하든, 코드를 계속 검사하는 무언가가 없다면 스펙은 유용성을 유지하지 못합니다; Keeping Specs, Tests, And Code In Sync In AI Development는 스펙이 조용히 구식이 되는 것을 잡아내는 추적성(checks)을 다룹니다.

나쁜 SDD는 마크다운으로 된 워터폴입니다. 좋은 SDD는 지속 가능한 산출물을 가진 통제된 반복입니다. 바이브 코딩은 맞는 작업에는 맞는 도구 – 그리고 틀린 작업에는 틀린 도구입니다. 차이를 아는 것이 그 기술입니다.

유용한 링크

구독하기

시스템, 인프라, AI 엔지니어링에 관한 새 글을 받아보세요.