사양 주도 개발(Spec-Driven Development) vs 비브 코딩(Vibe Coding): 워터폴(Waterfall)인가?

스펙을 진실의 원천으로, 아니면 느린 의식처럼?

Page content

2026년에 진입한 스펙 기반 개발(Spec-Driven Development, SDD)은 바이브 코딩(Vibe Coding)의 흐트러짐에 대한 진지한 개발자들의 해법으로 등장했습니다.

그 논리는 간단합니다. AI 에이전트가 즉흥적인 프롬프트가 아닌, 검토된 스펙(사양)에 따라 구현할 때 더 좋고 일관된 결과를 산출합니다. 이론적으로 반박하기 어렵습니다.

그러나 현실에서는 Hacker News에서 이를 “워터폴(Waterfall)의 부활"이라고 부르며 비판했습니다.

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

Spec-Driven Development versus Vibe Coding

바이브 코딩 세계에서 SDD를 지지하는 논리

Vibe coding – 즉, 느슨한 프롬프트를 작성하고 AI 에이전트가 생성한 결과물을 계속 반복 개선하는 방식 – 은 작고 탐색적이며 일회성인 작업에는 놀라울 정도로 잘 작동합니다. 2025년 상반기 동안 이는 지배적인 AI 코딩 패턴이었습니다. 개발자들은 스크립트, 프로토타입, 간단한 도구들을 그 어느 때보다 빠르게 배포했습니다.

그런 다음 프로젝트 규모가 커졌습니다. 다중 파일에 걸친 기능들이 점차 방향을 잃기 시작했습니다. 세션 1에서 확립된 제약 조건들은 세션 3에는 잊혀졌고, 보안 가정들도 소홀히 되었습니다. 에이전트가 의도에 대한 지속적인 기억을 갖고 있지 못했기 때문에, 기능 개발 중반에서 아키텍처 결정들이 변경되었습니다.

스펙 기반 개발(SDD)은 이러한 상황에 대한 규율 있는 대응으로 등장했습니다. 핵심 주장은 프롬프트가 아닌 스펙을 중심 아티팩트(산출물)로 삼는 것입니다. 먼저 요구사항, 설계, 그리고 작업 계획을 작성합니다. 에이전트에게 이 아티팩트들에 대해 한 번에 한 슬라이스씩 구현하도록 합니다. 스펙은 버전 관리되고 지속적으로 업데이트되어야 합니다.

GitHub Spec Kit, Kiro, Claude Code SDD 워크플로우, 그리고 BMAD 및 기타 커뮤니티 스캐폴딩 도구들은 모두 이 아이디어의 구현체입니다. 도구는 실재하며, 관심도도 실재합니다. 반발 역시 실재합니다.

바이브 코딩이 잘하는 분야

바이브 코딩을 일축하기 전에, 그것이 실제로 잘하는 부분들을 명확히 하는 것이 중요합니다.

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

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

일회성 자동화. 일회용 스크립트, 데이터 추출 작업, 마이그레이션 헬퍼 등은 거의 설계 문서가 필요하지 않습니다. 약간의 오류가 발생하는 비용은 낮지만, 느리고 의식적인 프로세스를 거치는 비용은 실제적입니다.

빠른 피드백. 무언가를 빠르게 학습해야 할 때 – 이 API가 내가 생각하는 대로 작동하는가? – 바이브 코딩은 학습 루프를 몇 분 단축시킵니다. SDD는 아무런 이득 없이 이를 지연시킬 것입니다.

오류는 이러한 문맥에서 성공 패턴을 가져와 실제 제약 조건, 실제 사용자, 그리고 오류 시 심각한 결과를 초래하는 프로덕션 기능에 적용하는 것입니다.

바이브 코딩이 실패하는 지점

바이브 코딩은 범위와 중요도가 증가함에 따라 예측 가능하게 성능이 저하됩니다.

다중 파일 변경. 기능이 다섯 개 이상의 파일을 건드릴 때, 에이전트의 컨텍스트 윈도우는 불변식(invariants)을 추적하는 데 실패하기 시작합니다. 설계 문서 없이 각 프롬프트는 이전 세션에서 확립되고 잊혀진 컨텍스트를 재확립해야 합니다.

아키텍처 드리프트. 명시적인 비목표(non-goals)가 없으면, 에이전트는 무언가를 구현합니다. 에이전트는 합리적이라고 생각하여 캐싱 레이어를 추가합니다. 세션이 세 번 더 진행된 후, 캐싱 가정은 데이터 모델에 고정되어 제거하는 데 비용이 많이 듭니다.

잊혀진 제약 조건. “인증된 사용자만 이를 트리거할 수 있음"은 요구사항 문서의 한 문장입니다. 바이브 코딩 세션에서는 세션 1에서 한 번 언급된 것일 뿐이며, 새로운 엔드포인트를 작성하는 세션 4의 에이전트는 이를 기억하지 못합니다.

숨겨진 보안 가정. 인가 규칙, 입력 유효성 검사 경계, 시크릿 처리 등은 에이전트가 올바르고 제약된 코드보다는 그럴듯하게 작동하는 코드를 최적화할 때 놓치기 쉬운 암묵적 요구사항의 전형적인 예입니다.

팀 간의 인수인계. 반복적인 프롬팅을 통해 구축했다면, 결정된 내용과 그 이유를 기록하는 아티팩트는… git 로그입니다. 이를 활용하기는 힘듭니다.

스펙 기반 개발이 변경하는 부분

SDD는 이터레이션(반복)을 제거한다고 주장하지 않습니다. 좋은 버전의 SDD는 명시적으로 이터레이티브합니다. 변경되는 것은 이터레이션이 일어나는 위치입니다. SDD가 TDD, BDD, 그리고 형식적 방법론과 어떻게 다른지를 포함한 전체 정의는 What Is Spec-Driven Development?를 참조하십시오.

코드에서 이터레이션하고 diff에서 의도를 추론하는 대신, 스펙에서 이터레이션한 후 구현합니다. 스펙은 결정된 내용, 이유, 그리고 범위 밖 사항을 기록하는 아티팩트가 되어 Architecture Decision Records와 유사한 기능을 수행하지만, 시스템 수준의 선택이 아닌 기능 의도(feature intent)에 초점을 맞춥니다. 코드는 그 의도를 구현합니다.

SDD는 5개의 단계 – 지정(specify), 계획(plan), 작업(tasks), 구현(implement), 검증(validate) – 을 거치며 각 단계마다 인간 검토 게이트가 존재합니다. 전체 프로세스, 템플릿, 그리고 체크포인트는 Spec-Driven Development Workflow From Requirements to Code를 참조하십시오. 에이전트는 대부분의 단계에 참여하지만, 인간은 구현 시작 전에 아티팩트를 검토합니다. 이 검토 단계가 SDD와 바이브 코딩의 핵심 차이입니다.

왜 개발자들은 이를 워터폴이라고 부르는가

워터폴 비판은 틀리지 않았습니다. 다만 이는 SDD 자체보다 나쁜 SDD를 겨냥한 것입니다.

특정 실패 모드는 긴 사전 계획입니다. 워터폴의 정의적인 특징은 피드백 루프가 몇 주 또는 몇 달로 늘어납니다: 요구사항 단계, 설계 단계, 빌드 단계, 테스트 단계, 배포. 피드백은 늦게 도착합니다. 설계 가정이 잘못되었다는 것을 발견할 때쯤이면, 이미 그 위에서 몇 주 동안 구축을 해왔던 것입니다.

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

한 HN 댓글 작성자는 작은 CLI 도구를 위해 Spec Kit를 사용했다며 “코드를 보기 전에 너무 느리고, 너무 많은 조정이 필요하다"고 묘사했습니다. 이것이 나쁜 버전입니다. 해당 사용자는 그 작업에 대해 이를 거부하는 것이 옳았습니다.

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

유용한 중간 지점

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

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

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

조기 구현. 첫 번째 작업을 스펙으로 정의하고, 구현하고, 검증한 다음 다음 작업으로 이동합니다. 무언가를 구현하기 전에 모든 것을 스펙으로 정의하지 마십시오. 첫 번째 구현은 스펙이 잘못한 것을 드러낼 것입니다. 계속하기 전에 스펙을 업데이트하십시오.

생생한 스펙(Living Spec). 현실이 설계와 다를 때 – 그것은 반드시 일어날 것입니다 – 코드뿐만 아니라 스펙을 업데이트하십시오. 스펙은 실제로 구축된 것을 반영할 때만 유용합니다.

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

이 하이브리드 – 작은 슐, 짧은 작업, 조기 구현, 생생한 문서 – 가 실제로 작동하는 방식입니다. 이는 바이브 코딩도 아니고 워터폴도 아닙니다. 이는 내구성 있는 아티팩트를 갖춘 통제된 이터레이션입니다.

SDD가 바이브 코딩을 이기는 경우

실제적인 오류 비용이 있을 때 SDD – 심지어 경량 SDD – 를 사용하십시오.

위험한 비즈니스 로직. 청구, 권한, 데이터 마이그레이션, 멱등성 – 불正确的 행동이 비용이 많이 들거나 되돌리기 어려운 모든 로직. 바이브 코딩은 이러한 요구사항을 암묵적으로 남깁니다. SDD는 구현 전에 이를 명시적이고 검토 가능하게 만듭니다.

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

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

팀 간의 인수인계. 다른 개발자 또는 다른 에이전트가 이 작업을 계속할 경우, 슐은 인수인계 아티팩트입니다. git 로그와 README만으로는 충분하지 않습니다.

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

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

SDD는 오버헤드입니다. 때때로 오버헤드는 가치가 없을 수 있습니다.

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

실험. 접근 방식이 실행 가능한지 학습 중이라면 – API 탐색, 라이브러리 테스트, 가설 검증 – 구조가 아닌 속도가 필요합니다. 먼저 실험하고, 실험이 성공하면 스펙을 정의하십시오.

UI 스케치. 상호작용 설계는 규정하는 것보다 보는 것을 통해 혜택을 받습니다. 여러 거친 변형을 빠르게 구축하고, 본 것에 반응하며, 실제로 배포할 것만 스펙으로 정의하십시오.

일회성 자동화. 일회용 스크립트, 데이터 가져오기, 마이그레이션 헬퍼 – 약간의 잘못된 결과에 대한 비용은 보통 낮으며, 아티팩트는 사용 후 어쨌든 삭제됩니다.

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

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

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

바이브 코딩을 사용할 때:

  • 작업이 하루 미만으로 걸릴 때
  • 탐색 중이거나 학습 중일 때
  • 아티팩트가 일회성이거나 중요도가 낮을 때
  • 당신이 이를 건드릴 유일한 사람일 때
  • 정확성보다 피드백 속도가 더 중요할 때

경량 SDD를 사용할 때:

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

전면 SDD를 사용할 때:

  • 기능이 공개 인터페이스 또는 데이터 계약을 건드릴 때
  • 여러 에이전트 또는 팀 구성원이 관여할 때
  • 조직이 구현 전에 설계 검토를 요구할 때
  • 규정 준수 또는 감사 추적이 필요할 때

가장 흔한 실수는 경량 SDD만 필요한 작업에 전면 SDD를 적용하고, 최소한 경량 슐이 필요한 작업에는 아예 슐을 적용하지 않는 것입니다. 선택한 수준에 상관없이, 슐은 무언가가 코드를 지속적으로 확인하는 한에만 유용하게 유지됩니다. Keeping Specs, Tests, And Code In Sync In AI Development는 조용히陳舊해지는 슐을 잡아내는 추적성 검사를 다룹니다.

나쁜 SDD는 마크다운을 사용한 워터폴입니다. 좋은 SDD는 내구성 있는 아티팩트를 갖춘 통제된 이터레이션입니다. 바이브 코딩은 올바른 작업에 대한 올바른 도구 – 그리고 잘못된 작업에 대한 잘못된 도구입니다. 차이를 아는 것이 기술입니다.

유용한 링크

구독하기

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