SDD - Spec Driven Development

조민수·2025년 10월 20일

Computer Science

목록 보기

13/13

들어가기에 앞서

AI를 활용한 AI 코딩, 일명 바이브 코딩이 도입되고
Claude Code, Codex등 강력한 성능의 AI 개발툴에 대한 의존도가 올라가며
개발 환경의 생태계가 변화하고 있다.

이제 단순히 코드를 작성하는 영역은 개발자에게 있어 프로덕트 완성의 걸림돌이 아니며,
AI를 활용하는 과정에서 "무엇을", "어떻게", "왜" 만들건지에 대한 깊은 이해가 필요해지고 있다.

이는 Codex, Copliot 등 활용하는 에이전트의 능력에
개인의 접근 방식을 효과적으로 융합하는 방식의 필요성을 대두시키고 있고,
단순히 검색 엔진이 아니라, Pair Programmer로서 에이전트를 다뤄야하는 방향을 제시한다.

SDD란?

이때, 새롭게 대두되는 것이 바로 SDD(Spec Driven Development)이다.
AI 에이전트에게 명확한 지시를 내리기 위한 방법이며
코드가 어떻게 동작할 것인지, 어떻게 테스트, 검증할 것인지에 대한 지침을 정의하는 것으로부터
구현이 시작되는 것을 의미한다.

쉽게 말해 코드 작성 전, 명세서(specification)을 먼저 작성하는 접근 방식으로,
명세서는 개발자와 AI 모두에게 단일 진실 공급원(single source of truth) 역할을 수행한다.
즉, documentation first의 접근 방식으로서 명세서의 진화로 SW 유지보수가 진행되며
코드는 최종 단계 접근 방식으로 변모하는 것이다.

핵심 개념

SDD는 프로젝트의 고수준 설명에서 시작해, 명세 작성, 기술 계획 수립, 작업 분해의 단계를 거쳐 구현으로 이어지는 구조화된 프로세스로 구성된다.

기존 바이브 코딩의 한계로 평가받는
"무엇을 왜 만들었는지"가 흐려지는 단점을 해결하고 복잡하고, 큰 프로젝트에서 AI 에이전트를 효과적으로 활용할 수 있는 관점을 제시한다.

기존 바이브 코딩의 단점
1. 성급한 코드 생성: AI는 개발자의 요구사항을 완전히 이해하기 전에 즉시 코드를 작성
2. 수정 사이클의 반복: 개발자는 실제 의도에 맞추기 위해 반복적으로 코드 수정 요청
3. Context Window 낭비: 호출하는 에이전트의 Context는 요구사항을 정의하기 위한 불필요한 대화로 낭비
4. 품질저하: 낭비되는 Context 공간으로 인해 최종 결과물의 품질이 기대보다 하락

SDD의 해결책

SDD는 이러한 단점을 해결하고자 다음과 같은 접근법을 사용한다.

프로젝트의 모든 요구사항과 설계를 문서(spec)로 명확히 정리
AI는 해당 문서(산출물)을 지속적으로 참고해 일관성있는 개발 진행
프로젝트 변경 사항을 문서에 반영, AI는 변경된 문서를 바탕으로 코드 업데이트

명세서 : Spec

그럼 SDD의 핵심인 Spec, 명세서란 무엇일까

자연어로 작성된 구조화되고 행동 지향적인 산출물
소프트웨어 기능을 명시하고, AI 에이전트의 가이드 역할을 수행
일반적인 Context documentation과 구분되어야 함
- 일반 Context: 규칙 파일, 제품 및 코드베이스의 고수준 설명(Memory bank)
- 메모리 뱅크 파일은 코드베이스의 모든 AI 코딩 세션에 관련, Spec은 특정 기능을 생성/변경 작업에만 관련

SDD 구현 수준

SDD는 세 가지 구현 수준으로 구분된다.

Spec-first: 잘 구성된 명세서를 먼저 작성하고 AI 지원 개발 워크플로우에 사용
Spec-around: 작업 완료 후에도 명세서를 유지해 해당 기능의 진화, 유지보수에 활용
Spec-as-source: 명세서가 시간이 지난후에도 주요 소스 파일로 유지, 개발자는 명세서만 편집하고 소스코드는 직접 수정하지 않음

SDD의 맹점과 유의사항

과도한 프로세스 오버헤드
작은 버그를 수정할 때도 요구사항, 설계, 작업의 전체 워크플로우를 거쳐야 해서 "호두를 깨기 위해 대형 해머를 쓰는 격"이 되는 경우가 있다.
마크다운 파일 검토의 번거로움
spec-kit은 검토해야 할 많은 마크다운 파일을 생성하는데, 서로 반복적이고 이미 존재하는 코드와도 중복되며, 전체적으로 매우 장황하고 검토하기 지루한 워크플로우가 발생할 수 있다.
AI의 지시사항 미준수
모든 파일, 템플릿, 프롬프트, 워크플로우, 체크리스트에도 불구하고 AI 에이전트가 궁극적으로 모든 지시사항을 따르지 않는 경우가 있으며, 컨텍스트 윈도우가 크다고 해서 AI가 그 안의 모든 것을 제대로 파악하진 않는다.
Spec 품질에 대한 의존성
Spec 문서 품질이 기준 수준에 미치지 못하는 경우 도구가 제대로 동작하지 않을 수 있으며
완성도 높은 TDD가 SDD의 성과에 큰 영향을 끼친다.
실제 프로젝트 검증 부족
실제 코드베이스에서 일정 기간 동안 사용한 사람들의 사용 보고서를 듣기 전까지는 실제 작동 방식에 대한 많은 미해결 질문이 존재할 수 있다.

마치며...

SDD는 AI 시대의 개발 패러다임 전환을 대표하는 방법론이지만, 아직은 초기 단계이다.
MDD(Model Driven Development)의 실패처럼 새로운 개발 방법론은 주의깊게 봐야한다.

다만, "누가 코드를 잘 짜는가"에서 "누가 명확하고 실행 가능한 스펙을 잘 작성하는가"로 경쟁력의 기준이 변화하고 있으며 AI를 개발 프로세스에서 배제할 것이 아니라면 SDD가 아니더라도
어떻게 AI를 효과적으로 개발 프로세스에 통합할 것인지에 대한 다양한 관점이 필요한 것은 사실이다.

특히 PM, 기획자, 개발자 모두는 SDD의 실제 적용 시,
과도한 프로세스 오버헤드, AI의 불완전성, 문서 유지보수 부담 등을 신중히 고려해야 한다.

[참고자료]

조민수

Being a Modern Project Manager

이전 포스트