스펙 주도 개발(SDD)은 워터폴의 귀환일까 | 1970년 원조 논문부터 spec-kit까지 8분 정리

한 줄 핵심

스펙 주도 개발은 워터폴의 단순한 부활이 아니라, AI 에이전트 시대에 스펙을 코드 옆에서 살아 있게 유지하며 반복 검증하는 개발 방식으로 재해석해야 한다.

시간별 요약

1. 0:00
   1970년 논문의 그림과 그 아래 문장 워터폴로 알려진 계단식 개발 그림의 원형은 1970년 논문에 등장하지만, 그 아래에는 이 방식이 위험하고 실패를 부른다는 경고가 함께 붙어 있다. 56년 뒤 코드보다 스펙을 먼저 쓰자는 도구가 큰 관심을 받으면서, 이 방식이 정말 돌아온 것인지가 논쟁의 출발점이 된다.
2. 0:38
   스펙 주도 개발이란 기능을 바로 코딩하기보다 먼저 명세를 써서 무엇을 어떻게 만들지 합의하고, 그 기준에 맞춰 구현하는 방식이 스펙 주도 개발이다. Amazon Kiro처럼 요구 사항, 설계, 작업 목록을 분리해 관리하는 도구도 나오며, 개발 순서를 코드보다 스펙에 두려는 흐름이 생겼다.
3. 1:22
   워터폴은 무엇이 문제였나 워터폴은 요구 사항, 설계, 구현, 테스트, 배포가 순차적으로 고정되어 있어 앞단의 오류를 뒤늦게 발견하면 되돌리기 비싸다는 문제가 있다. 반면 Agile은 큰 사전 명세보다 짧은 주기의 생성과 학습을 택하며, 변화에 맞춰 계속 수정하는 쪽으로 방향을 바꿨다.
4. 2:37
   워터폴의 역습이라는 비판 스펙을 먼저 쓰자는 주장에 대해 많은 개발자는 과거의 명세 중심 통제로 되돌아가는 것 아니냐고 반발했다. 명세를 모두 쓰고 나서 구현한다는 가정은 구현 과정에서 새로 배우는 것이 없다는 전제를 깔고 있으며, 실제로는 코드와 함께 스펙이 바뀌는 편이 더 현실적이라는 비판이 이어진다.
5. 3:40
   IBM 영상의 답: 계단이 아니라 고리 핵심 차이는 스펙을 한 번 쓰고 끝내는지, 아니면 구현하면서 계속 되돌아가 고치는지에 있다. 스펙 주도 개발은 계단식 하향이 아니라 스펙-구현-검증-수정이 반복되는 고리이며, 스펙 퍼스트, 스펙 앵커드, 스펙 에디트 소스 같은 방식 중 영상은 코드 옆에서 살아 있는 스펙에 가깝다고 본다.
6. 5:01
   예시: 스펙 세 줄이 네 줄이 되기까지 비밀번호 재설정 기능처럼 짧은 스펙도 구현과 테스트를 거치면 누락된 예외가 드러나고, 그때 가장 최근 링크만 유효하다는 규칙처럼 스펙이 더 정교해진다. 이렇게 스펙은 저장소에서 코드와 함께 버전 관리되고, 구현 기준이자 테스트 기준, 검증 기준으로 동시에 작동한다.
7. 6:06
   왜 하필 지금인가 AI 에이전트는 사람처럼 맥락을 눈치채지 못하므로, 좋은 스펙이 무엇을 만들고 어떤 제약과 성공 기준이 있는지 직접 제공해야 한다. 불명확한 요구 사항은 추가 프롬프트와 재검증 비용으로 이어지기 때문에, 스펙이 분명할수록 왕복 횟수와 비용이 줄어든다.
8. 7:03
   주의할 점: 전부 스펙으로 쓰지는 마라 스펙에는 기능뿐 아니라 보안, 규정 준수, 거버넌스 같은 요구도 들어가야 하지만, 완벽한 최종본을 한 번에 쓰려 하면 다시 워터폴이 된다. 앞으로 나아갈 만큼만 가볍게 쓰고, 코드로 빨리 검증하며, 현실이 바뀌면 스펙도 함께 고치는 방식이 더 적합하다.
9. 7:50
   다시 1970년 논문으로 로이스는 위험성을 지적하면서도 세 번째 단계를 두 번 하라는 식으로, 첫 결과를 최종본의 이른 시뮬레이션으로 삼아 다시 돌아보라고 제안했다. 결국 문제는 스펙을 쓰느냐가 아니라, 쓴 스펙을 코드 옆에 두고 계속 되돌아가며 고치느냐에 있다.

실무 인사이트

• AI 코딩 환경에서는 스펙을 한 번 쓰는 능력보다, 구현 결과를 반영해 스펙을 빠르게 갱신하는 능력이 더 중요하다.
• 실무에서는 요구 사항 문서를 길게 쓰는 대신, 성공 기준·제약·예외를 포함한 짧은 스펙을 코드와 같은 저장소에서 관리하는 방식이 효과적이다.
• 스펙 주도 개발을 도입할 때는 ‘문서화 강화’가 아니라 ‘검증 가능한 기준을 앞당기는 것’으로 정의해야 워터폴로 퇴행하지 않는다.