SDD(Spec-Driven Development): AI 시대의 스펙 중심 개발 방법론
서론
AI 코딩 도구가 보편화되면서 “프롬프트만 던지면 코드가 나오는” 시대가 됐다. 이른바 Vibe Coding — 대략적인 의도만 전달하고 AI가 알아서 구현하는 방식이다.
문제는 이게 프로토타입까지는 빠르지만, 프로덕션 수준에서는 무너진다는 것이다. 요구사항이 모호하면 AI는 추측하고, 추측은 버그가 되고, 버그는 기술 부채가 된다.
SDD(Spec-Driven Development)는 이 문제에 대한 답이다. “코드를 작성하기 전에 스펙을 먼저 작성하라.” 새로운 아이디어는 아니다. 하지만 AI가 코드를 생성하는 시대에 스펙의 가치가 완전히 달라졌다.
1. SDD란?
SDD는 스펙(Specification)을 개발의 단일 진실 공급원(Single Source of Truth)으로 삼는 방법론이다. 코드, 테스트, 문서 모두 스펙에서 파생된다.
기존 개발: 요구사항 → 코드 작성 → 테스트 → 문서화 (각각 따로 관리)
SDD: 스펙 작성 → 코드 생성 → 테스트 생성 → 문서 생성 (스펙이 모든 것의 원천)핵심 원칙은 단순하다:
“코드는 스펙의 구현 세부사항이다. 스펙이 바뀌면 코드가 따라가고, 코드가 스펙을 벗어나면 코드가 틀린 것이다.”
SDD는 2004년 학술적으로 처음 정의됐지만(TDD와 Design by Contract의 결합), 2025년 AI 코딩 도구의 부상과 함께 업계에서 본격적으로 주목받기 시작했다. Thoughtworks가 2025 Technology Radar에 포함시켰고, Amazon이 Kiro라는 SDD 전용 IDE를 출시했다.
2. TDD, BDD와 뭐가 다른가?
| 항목 | TDD | BDD | SDD |
|---|---|---|---|
| 핵심 산출물 | 실패하는 테스트 | Given/When/Then 시나리오 | 스펙 문서 (MD, OpenAPI 등) |
| 작성 시점 | 코드 단위마다 | 기능 단위마다 | 시스템 설계 단계에서 |
| 범위 | 유닛 수준 | 기능/행위 수준 | 시스템/아키텍처 수준 |
| 주 대상 | 개발자 | 개발자 + PO + QA | 개발자 + AI 에이전트 + 이해관계자 |
| AI 시대 역할 | 코드 검증 | 행위 검증 | AI 코드 생성의 입력 |
관계를 정리하면:
- TDD는 마이크로 수준의 SDD다. 실패하는 테스트는 “이 함수가 이렇게 동작해야 한다”는 마이크로 스펙이다.
- BDD는 SDD의 직계 조상이다. Given/When/Then 시나리오는 실행 가능한 스펙이다.
- SDD는 이 둘 위에 앉는다. 시스템 수준에서 의도를 정의하고, TDD/BDD는 하위 검증 레이어로 활용한다.
SDD (시스템 수준 스펙)
├── BDD (기능 수준 시나리오)
│ └── TDD (유닛 수준 테스트)
└── AI 코드 생성3. SDD 워크플로우
SDD의 표준 워크플로우는 4단계로 구성된다.
3.1 SPECIFY — 스펙 작성
무엇을 만들 것인지 정의한다. 구현 방법은 아직 적지 않는다.
## 기능: 재고 차감
### 요구사항
- 사용자가 상품을 주문하면 재고가 1 감소한다
- 재고가 0이면 주문이 거부된다
- 동시에 100명이 주문해도 재고가 음수가 되지 않는다
### 입력
- productId: Long (상품 ID)
- userId: Long (사용자 ID)
### 출력
- 성공: 주문 ID 반환
- 실패: SoldOutException
### 제약 조건
- 응답 시간: 200ms 이내
- 동시성: 초당 1,000건 처리 가능좋은 스펙의 조건:
- 입출력이 명확하다 — 무엇이 들어가고 무엇이 나오는지
- 경계 조건이 정의돼있다 — 재고 0, 동시 요청, 타임아웃
- 구현을 강제하지 않는다 — “Redis를 써라”가 아니라 “초당 1,000건을 처리하라”
3.2 PLAN — 설계
스펙을 바탕으로 어떻게 만들 것인지 결정한다.
## 설계: 재고 차감
### 아키텍처
- Spring Boot + PostgreSQL
- 비관적 락 (FOR UPDATE) 사용
- HikariCP 커넥션 풀: 20
### 인터페이스
- POST /api/orders
- Request Body: { "productId": 1, "userId": 1 }
- Response: { "orderId": 123 }
### 데이터 모델
- products (id, name, stock, version)
- orders (id, product_id, user_id, created_at)3.3 IMPLEMENT — 구현
설계를 바탕으로 코드를 작성한다. AI 에이전트를 사용하면 스펙과 설계 문서를 컨텍스트로 전달해서 코드를 생성한다.
스펙 문서 + 설계 문서 → AI 에이전트 → 코드 생성
→ 테스트 생성
→ API 문서 생성3.4 VALIDATE — 검증
생성된 코드가 스펙을 충족하는지 검증한다.
- 스펙의 요구사항이 모두 테스트로 커버되는가?
- 경계 조건(재고 0, 동시 요청)이 테스트에 포함되는가?
- 성능 제약(200ms, 1,000 TPS)을 만족하는가?
4. SDD의 세 가지 수준
SDD는 도입 깊이에 따라 세 단계로 나뉜다.
| 수준 | 설명 | 스펙과 코드의 관계 |
|---|---|---|
| Spec-First | 스펙을 먼저 쓰고 개발 시작 | 스펙 선행, 이후 코드가 독립적으로 진화 가능 |
| Spec-Anchored | 스펙과 코드를 함께 유지 | 기능 변경 시 스펙도 함께 업데이트 |
| Spec-as-Source | 스펙만 수정, 코드는 항상 생성 | 코드를 직접 수정하지 않음 (가장 급진적) |
대부분의 팀은 Spec-First에서 시작한다. 스펙을 먼저 쓰는 습관만으로도 AI 코드 생성의 품질이 크게 올라간다.
Spec-Anchored는 OpenAPI 기반 API 개발에서 이미 많이 쓰이는 방식이다. API 스펙을 수정하면 클라이언트 SDK, 서버 스텁, 문서가 자동 생성된다.
Spec-as-Source는 아직 실험 단계다. 사람이 코드를 직접 건드리지 않고 스펙만 수정하는 방식인데, 현재 AI의 코드 생성 능력으로는 복잡한 시스템에서 한계가 있다.
5. SDD 도구
5.1 AI 시대 SDD 도구 (2025~)
| 도구 | 유형 | 접근 방식 | 특징 |
|---|---|---|---|
| Amazon Kiro | IDE (VS Code 포크) | Spec-First | 요구사항 → 설계 → 태스크 3단계 워크플로우 |
| GitHub Spec-Kit | CLI (오픈소스) | Spec-First | Constitution → Specify → Plan → Tasks |
| Tessl | 플랫폼 (비공개 베타) | Spec-as-Source | 스펙↔코드 양방향 동기화 |
| Claude Code | CLI | Spec-First | CLAUDE.md를 스펙/컨텍스트로 활용 |
| Cursor | IDE | Spec-First | AGENTS.md + MCP 서버로 컨텍스트 주입 |
5.2 API 스펙 기반 도구 (기존)
| 도구 | 용도 |
|---|---|
| OpenAPI / Swagger | REST API 스펙 정의 (JSON/YAML) |
| Spectral | OpenAPI 스펙 린팅/검증 |
| Redocly | 스펙 기반 API 문서 자동 생성 |
OpenAPI는 SDD의 가장 성숙한 사례다. API 스펙 하나로 문서, 클라이언트 SDK, 서버 스텁, 계약 테스트를 모두 생성할 수 있다.
6. 실제 효과
학술 논문과 실무 사례에서 보고된 수치:
| 사례 | 효과 |
|---|---|
| 금융 마이크로서비스 (OpenAPI + 계약 테스트) | 통합 사이클 시간 75% 감소 |
| AI 코드 생성 (스펙 정제 후) | 코드 오류 최대 50% 감소 |
| Delta Airlines (Kiro 도입) | AI 개발 도구 사용량 6개월간 1,948% 증가 |
수치보다 중요한 건 질적 변화다:
- 요구사항 모호성 제거 — “이거 이렇게 동작하는 거 맞아?”라는 질문이 줄어든다
- AI 환각 감소 — 구체적인 스펙이 있으면 AI가 추측할 여지가 줄어든다
- 병렬 작업 가능 — 스펙이 명확하면 여러 AI 에이전트가 동시에 다른 부분을 구현할 수 있다
7. SDD의 한계와 비판
SDD가 만능은 아니다. 2025년 현재 꽤 날카로운 비판들이 있다.
7.1 “이건 워터폴의 부활이다”
가장 핵심적인 비판이다. SDD의 “스펙 → 설계 → 구현” 흐름이 워터폴의 “분석 → 설계 → 구현”과 구조적으로 같다는 지적이다.
“소프트웨어 개발은 본질적으로 비결정적 과정이다. 스펙을 아무리 잘 써도 예측하지 못한 문제가 나온다.”
이 비판은 Spec-as-Source 수준에서 특히 유효하다. 하지만 Spec-First 수준에서는 “일단 방향을 잡고 시작하자”에 가깝기 때문에 워터폴과는 다르다.
7.2 문서 과부하
Kiro나 Spec-Kit 같은 도구는 대량의 마크다운 파일을 생성한다. 간단한 기능에도 요구사항 문서, 설계 문서, 태스크 목록이 만들어진다.
“못을 하나 박는 데 슬레지해머를 쓰는 격이다.” — Martin Fowler
7.3 AI가 스펙을 무시한다
아이러니하지만, AI가 스펙을 줘도 그대로 따르지 않는 경우가 많다. 스펙이 있다는 사실이 “통제하고 있다”는 착각을 줄 수 있다.
7.4 스펙은 현실을 따라가지 못한다
엣지 케이스는 프로덕션에서 발견되고, 성능 이슈는 부하 테스트에서 나타나고, 사용자 행동은 출시 후에야 알 수 있다. 스펙이 이 모든 것을 사전에 담을 수는 없다.
시스템이 복잡해질수록 스펙과 코드의 동기화 비용이 커진다. 이건 SDD의 구조적 한계다.
7.5 탐색적 개발과는 맞지 않는다
프로토타입, 연구, 실험적 개발에서는 SDD가 오히려 방해가 된다. “뭘 만들지 아직 모르는” 상황에서 스펙을 먼저 쓸 수는 없다.
8. 그래서 언제 쓰면 좋은가?
| 상황 | SDD 적합도 | 이유 |
|---|---|---|
| API 우선 개발 | ✅ | OpenAPI 스펙 → 코드/문서/테스트 자동 생성 |
| 요구사항이 명확한 기능 | ✅ | 스펙 작성이 쉽고, AI 코드 생성 품질이 높아짐 |
| 규제 산업 (금융, 의료) | ✅ | 감사 추적, 컴플라이언스에 스펙 문서가 필수 |
| 팀 간 협업 (프론트-백엔드) | ✅ | 스펙이 계약 역할, 병렬 개발 가능 |
| 프로토타입 / 탐색적 개발 | ❌ | 스펙 작성 오버헤드가 속도를 늦춤 |
| 빠르게 변하는 요구사항 | ⚠️ | 스펙 동기화 비용이 커질 수 있음 |
| 간단한 기능 추가 | ❌ | 과한 문서화가 오히려 비효율 |
정리
| 핵심 포인트 | 내용 |
|---|---|
| SDD란 | 스펙을 단일 진실 공급원으로 삼고, 코드/테스트/문서를 스펙에서 파생하는 방법론 |
| 핵심 워크플로우 | Specify → Plan → Implement → Validate |
| vs TDD/BDD | TDD는 유닛 수준, BDD는 기능 수준, SDD는 시스템 수준 |
| 세 가지 수준 | Spec-First → Spec-Anchored → Spec-as-Source (점진적 도입 가능) |
| 실제 효과 | 통합 시간 75% 감소, AI 코드 오류 50% 감소 |
| 핵심 한계 | 워터폴 우려, 문서 과부하, AI의 스펙 무시, 스펙-코드 동기화 비용 |
| 적합한 경우 | API 우선 개발, 요구사항 명확, 규제 산업, 팀 간 협업 |
SDD는 AI 코딩의 “Vibe”를 “Engineering”으로 바꾸는 도구다. 모든 상황에 맞는 건 아니지만, 스펙을 먼저 쓰는 습관 하나만으로도 AI와의 협업 품질이 확연히 달라진다. 완벽한 스펙을 쓸 필요는 없다. “내가 뭘 원하는지”를 AI에게 명확히 전달하는 것이 SDD의 본질이다.