사양 기반 개발 vs 바이브 코딩: 워터폴 방식인가요?

명세서를 사실의 근원으로, 아니면 느린 의례로?

Page content

스펙 주도 개발(Spec-Driven Development)은 2026년, 뱅 코딩(vibe coding)의 방향성 이탈에 대한 진지한 개발자들의 해답으로 등장했습니다.

논리는 간단합니다. AI 에이전트는 즉흥적인 프롬프트보다 검토된 명세(specification)에 기반하여 구현할 때 더 좋고 일관된 출력을 생성합니다. 이론적으로 반박하기 어렵습니다.

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

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

스펙 주도 개발 대 뱅 코딩

뱅 코딩 세상에서의 SDD 타당성

뱅 코딩은 느슨한 프롬프트를 작성하고 AI 에이전트가 생성한 결과물을 반복적으로 개선해 나가는 실천 방법입니다. 이는 소규모, 탐색적, 그리고 일회성 작업에 놀라울 정도로 잘 작동합니다. 2025년 상반기까지 이는 지배적인 AI 코딩 패턴이었습니다. 개발자들은 스크립트, 프로토타입, 간단한 도구들을 그 어느 때보다 빠르게 출시했습니다.

그런 다음 프로젝트 규모가 커졌습니다. 다중 파일 기능들은 점점 일관성을 잃기 시작했습니다. 첫 세션에서 설정된 제약 조건들은 세 번째 세션에는 잊혀졌습니다. 보안 가정들이 누락되었습니다. 에이전트가 의도에 대한 내구성이 있는 기억을 갖고 있지 못했기 때문에, 기능 개발 중간에 아키텍처 결정들이 변경되었습니다.

스펙 주도 개발(SDD)은 이러한 상황에 대한 규율 있는 대응으로 등장했습니다. 핵심 주장은 다음과 같습니다: 프롬프트가 아닌 명세를 중앙 아티팩트(artifact)로 만드십시오. 먼저 요구사항, 설계, 그리고 작업 계획을 작성하십시오. 에이전트에게 그 아티팩트들을 한 슬라이스(slice)씩 구현하게 하십시오. 명세의 버전을 관리하고 업데이트하십시오.

AI 코딩 도구인 GitHub Spec Kit, Kiro, BMAD, 그리고 증가하는 Claude Code 커스텀 워크플로우 세트는 모두 이 아이디어의 구현체들입니다. 도구는 실재합니다. 관심도 실재합니다. 반발심도 실재합니다.

뱅 코딩이 뛰어난 분야

뱅 코딩을 경시하기 전에, 그것이 무엇에서 잘하는지 정확히 아는 것이 중요합니다.

탐색적 프로토타입. 무엇을 구축할지 확신이 없을 때, 가장 빠른 경로는 거친 무언가를 구축하고 그에 반응하는 것입니다. SDD는 무엇을 명세해야 할지 알고 있어야 합니다. 아직 모르다면 명세는 시기상조입니다.

UI 실험. 시각적 레이아웃과 상호작용 느낌은 사전에 명세하기 어렵습니다. 뱅 코딩은 옵션들을 빠르게 보여주며, 그 대부분을 버리고 실제로Feel이 맞는 것에 수렴하게 해줍니다. 여기서 요구사항 문서가 도움이 되지 않습니다.

일회성 자동화. 원샷 스크립트, 데이터 추출 작업, 마이그레이션 헬퍼 – 이들은 드물게 설계 문서가 필요합니다. 약간의 실수가 발생하는 비용은 낮습니다. 하지만 느리고 의식적인 프로세스를 따르는 비용은 현실적입니다.

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

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

뱅 코딩이 붕괴되는 지점

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

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

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

잊혀진 제약. “인증된 사용자만 이를 트리거할 수 있다"는 요구사항 문서의 한 문장입니다. 뱅 코딩 세션에서는, 이는 첫 세션에서 한 번 언급되었고, 새로운 엔드포인트를 작성하는 네 번째 세션에서 에이전트가 기억하지 못하는 것입니다.

숨겨진 보안 가정. 권한 부여 규칙, 입력 유효성 검사 경계, 시크릿 처리 – 이들은 에이전트가 정확하고 제약된 코드가 아니라 그럴듯하게 작동하는 코드를 최적화할 때 놓치는 전형적인 암묵적 요구사항입니다.

팀 인계. 반복적인 프롬팅을 통해 구축했다면, 무엇을 결정했는지와 왜 결정했는지를 기록하는 아티팩트는… git 로그입니다. 그걸로 운 좋기를 바랍니다.

스펙 주도 개발이 변경하는 것

SDD는 반복을 제거한다고 주장하지 않습니다. 좋은 버전의 SDD는 명시적으로 반복적입니다. SDD가 변경하는 것은 반복이 일어나는 위치입니다. 전체 정의 – SDD가 TDD, BDD, 그리고 형식적 방법(formal methods)과 어떻게 다른지 포함 –에 대해서는 스펙 주도 개발이란 무엇인가?를 참조하십시오.

코드에서 반복하고 diffs에서 의도를 추론하는 대신, 당신은 스펙에서 반복한 다음 구현합니다. 스펙은 무엇을 결정했는지, 왜 결정했는지, 그리고 무엇이 범위 밖인지 기록하는 아티팩트가 되어 – 시스템 수준의 선택이 아닌 기능 의도 주위에 초점을 맞춘 아키텍처 결정 기록과 유사한 기능을 수행합니다. 코드는 그 의도를 구현합니다.

전형적인 SDD 워크플로우의 5단계는 다음과 같습니다:

명세(Specify). 문제 진술, 사용자, 목표, 비목표, 수용 기준, 열린 질문들.

계획(Plan). 아키텍처 결정, 영향받는 모듈, 데이터 모델, API 계약, 보안 고려사항, 테스트 전략.

작업 분해(Task breakdown). 명시적인 검증 기준과 인간 검토 체크포인트가 있는 작은 구현 슬라이스들.

구현(Implement). 작업 사이에 컨텍스트 리셋을 하며 한 번에 하나의 작업, 스펙에서의 제약 적용, 그리고 현실이 설계와 다를 때 계획 업데이트.

검증(Validate). 테스트, 린트, 타입 체크, 수용 기준, 스펙-대-코드 diff.

에이전트는 대부분의 단계 – 스펙 초안 작성, 설계 생성, 작업 제안 – 에 참여하지만, 인간은 구현이 시작되기 전에 아티팩트를 검토합니다. 그 검토 단계가 SDD와 뱅 코딩의 핵심 차이입니다.

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

워터폴 비판은 틀리지 않았습니다. 다만 그것은 SDD 자체가 아닌 나쁜 SDD를 겨냥한 것입니다.

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

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

한 HN 댓글 작성자는 작은 CLI 도구를 위해 Spec Kit를 사용하고 “코드를 보기 전에 너무 느리고, 너무 많은 조정"이라고 발견했다고 설명했습니다. 그것이 나쁜 버전입니다. 그 사용자는 그 작업을 위해 이를 거부하는 것이 맞았습니다.

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

유용한 중간 지점

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

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

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

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

살아있는 스펙(Living spec). 현실이 설계와 다를 때 – 그리고 그럴 것입니다 – 코드뿐만 아니라 스펙을 업데이트하십시오. 스펙은 실제로 구축된 것을 반영할 때만 유용합니다.

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

이 하이브리드 – 작은 스펙, 짧은 작업, 조기 구현, 살아있는 문서 – 가 실제로 작동하는 것입니다. 이는 뱅 코딩도 아니고 워터폴도 아닙니다. 내구성이 있는 아티팩트를 갖춘 제어된 반복입니다.

뱅 코딩을 이기는 SDD

실제 비용이 있는 경우, SDD – 심지어 경량 SDD – 를 사용하십시오.

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

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

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

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

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

뱅 코딩이 여전히 더 나은 경우

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

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

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

UI 스케치. 상호작용 설계는 명세하는 것보다 보는 것에서 이득을 봅니다. 여러 거친 변형을 빠르게 구축하고, 본 것에 반응하고, 실제로 출시할 것만 명세하십시오.

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

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

간단한 결정 프레임워크

실질적인 질문은 “SDD인가 뱅 코딩인가?“가 아닙니다. “이 특정 작업을 위해 얼마나 많은 스펙이 필요한가?“입니다.

뱅 코딩을 사용하십시오:

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

경량 SDD를 사용하십시오:

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

완전한 SDD를 사용하십시오:

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

가장 흔한 실수는 경량 SDD만 필요한 작업에 완전한 SDD를 적용하고, 최소한 경량 SDD가 필요한 작업에는 아예 스펙을 적용하지 않는 것입니다.

나쁜 SDD는 마크다운으로 된 워터폴입니다. 좋은 SDD는 내구성이 있는 아티팩트를 갖춘 제어된 반복입니다. 뱅 코딩은 적절한 작업에 대한 적절한 도구 – 그리고 부적절한 작업에 대한 부적절한 도구입니다. 차이를 아는 것이 기술입니다.

유용한 링크

구독하기

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