명세 주도 개발(SDD)의 회귀
6.1 들어가며 — 청구서가 도착한 자리에서 산업이 다시 잡은 닻
Chapter 4 의 마법 이 Chapter 5 의 5 종 청구서 로 무너지면서 산업은 90 일 안에 답을 찾아야 했다. 그 답이 본 장의 주제 — 명세 주도 개발(Spec-Driven Development, SDD) concept/spec-driven-development — 이다. 코드를 짜기 전에 무엇을, 왜 만드는지 명세서(Specification, Spec) 로 박고, 그 명세서 위에서만 AI 가 코드를 쌓도록 강제하는 워크플로다. 본 책은 영어 spec 의 한국어로 명세서 를 쓴다 — SRS · PRD · API 명세 같은 SW 표준 어휘와 정확히 정렬된다. 책 표어 "설계 없이는 코딩이 안 된다" 의 설계 는 추상적 자세 (designing) 를 가리키며, 명세서 는 그 자세의 산출물 (specification) 로 분리된다. 이후 본문에서는 약어 SDD 와 한국어 명세서 를 자유롭게 호명한다.
본 장의 결론을 미리 박자 — SDD 의 회귀는 시대 역행 이 아니라 AI 시대에 맞춘 명세서의 재정의 다. 1970 년대 워터폴(Waterfall) 의 사양서가 인간 개발자가 읽고 따르던 문서였다면, 2026 년 SDD 의 명세서는 AI 가 읽고 따르는 문서다. 같은 단어 명세서 지만 독자가 다르고, 단위가 다르고, 검증 방법이 다르다. 그래서 Spec Kit 의 4 단계 는 워터폴의 V 모델과 닮아 보이지만, 실제로는 완전히 다른 동물 이다.
본 장은 5 절로 흐른다. 첫째, SDD 의 정의와 마법사 → 명세 실행기 재정의. 둘째, GitHub Spec Kit 의 4 단계 (헌장 → 명세 → 계획 → 작업) 와 그 작동 원리. 셋째, 실증 통계 — PR 리뷰 주기 31.8% 단축, 프로그래밍 시간 56% 단축, 토큰 효율 5.5 배. 넷째, 5 종 청구서가 SDD 의 4 단계로 어떻게 각각 막히는가의 매핑. 다섯째, 2 시간짜리 PRD(Product Requirements Document, 제품 요구사항 정의서) 한 페이지를 기록하는 실무 워크플로.
6.2 핵심 개념 — 마법사 → 명세 실행기 의 재정의
6.2.1 정의 — 코드 전에 명세서, 명세서 위에서만 코드
SDD 는 한 줄로 정의된다 — 코드를 짜기 전에 명시적 명세서(Spec)와 아키텍처 제약을 먼저 박고, 그 명세서 위에서만 AI 에 코드 작성을 위임하는 워크플로다. 핵심은 순서 다. 명세서 → 코드 가 아니라 코드 → (회귀적으로) 명세서 의 자세는 SDD 가 아니다. 명세서가 코드보다 먼저 박히고, 코드가 명세서를 위반하면 코드가 틀린 자리. 이 자리가 바이브 코딩의 의도 중심 개발 과 정확히 반대편이다.
이 정의가 재정의 인 이유는 단순하다. 바이브 코딩의 시대에 AI 는 주문 한 줄에 결과를 불확정적으로 내놓는 마법사 로 인식되었다. SDD 는 이 인식을 바꾼다 — AI 는 명세 실행기 (Spec Executor) 다. Claude Code 같은 도구가 CLAUDE.md + 명세서(PRD) + Plan + Tasks 를 입력받아 결정론에 가까운 코드 를 출력하는 자리다. 마법사는 상상력 이 자유롭지만 결과 가 매번 다르다. 명세 실행기는 상상력 이 제한되지만 같은 명세에 같은 출력 구조 가 보장된다. 결정론 측면에서는 컴파일러 (소스 → 바이너리) 와 같은 결 — 엔지니어가 gcc 나 tsc 를 신뢰하는 이유와 정확히 같은 자리다.
이 차이가 추상으로 들리지 않도록 같은 입력에 두 모드가 어떻게 다른 결과를 내는지 를 구체로 박자. 가정 — 사용자가 한 줄로 의뢰한다: "결제 모듈 만들어줘." 같은 입력이지만 도착하는 자리가 완전히 다르다.
마법사 모드 (바이브 코딩) — AI 는 그냥 짠다. 자기가 아는 가장 흔한 결제 게이트웨이를 골라(Stripe 일 수도, PayPal 일 수도) 코드를 박고, DB 스키마는 임의로 Payment 테이블 한 개를 만들며, 카드번호 필드를 그대로 평문으로 저장하기도 한다. 환불 로직은 물어보지 않았으니 빠지거나 한 함수에 섞이고, 응답 시간 보장도 없다. 30 분 만에 작동하는 코드가 나오지만, 이 결과가 우리 회사의 헌장과 맞는가 는 아무도 모른다. 같은 의뢰를 다시 던지면 다른 코드가 나올 가능성이 크다 — 결정론 부재.
명세 실행기 모드 (SDD) — AI 는 의뢰 전에 헌장 + 명세서 + 계획 을 입력받는다 (Claude Code 의 CLAUDE.md + PRD + Plan 워크플로 그대로). "Stripe API 만 사용 / 평문 저장 ❌ / 환불은 별도 모듈 / 응답 < 500 ms / Invoice·Payment·RefundLog 3 테이블 / POST /invoices·POST /payments/webhook 등 6 개 엔드포인트." 이 명세 위에서만 코드를 출력하므로 결과가 명세와 일치할 수밖에 없다. AI 가 상상력을 발휘할 자리 는 명세 안에서의 구현 디테일 (변수명·내부 로직 분기) 뿐이다. 같은 의뢰를 다시 던져도 같은 명세를 입력으로 받으면 같은 출력 구조 가 나온다 — 이게 명세 실행기처럼 작동한다 의 핵심 의미다.
| 축 | 마법사 모드 | 명세 실행기 모드 |
|---|---|---|
| 입력 | "결제 모듈 만들어줘" (자연어 한 줄) | CLAUDE.md + 명세서(PRD) + Plan + Tasks (2 시간 기록된 명세) |
| 게이트웨이 선택 | AI 임의 (Stripe? PayPal? Toss?) | Stripe 고정 (헌장) |
| 카드번호 저장 | 평문 가능 (AI 가 모름) | ❌ 헌장 위반 — AI 가 자동 거부 |
| 환불 로직 | 빠지거나 섞임 | 별도 모듈로 분리 (헌장) |
| 응답 시간 | 보장 없음 | < 500 ms (헌장) |
| DB 스키마 | 임의 1~2 테이블 | 3 테이블 + 인덱스 (계획) |
| 결과 검증 | "작동하면 OK" | DoD(Definition of Done, 완료 정의) 통과 시 OK |
| 재현성 | 같은 의뢰 → 매번 다른 코드 | 같은 명세 → 같은 출력 구조 |
| 디버깅 비용 | 90 일 후 5 종 청구서 도착 | 명세와 비교하면 즉시 원인 추적 |
같은 30 분 작업이라도 마법사 모드의 30 분 은 3 개월 뒤 청구서를 부르고, 명세 실행기 모드의 30 분 (= 2 시간 명세 후 30 분) 은 3 개월 뒤에도 그 자리 에 있다. 5 종 청구서 (Chapter 5) 는 마법사를 명세 실행기처럼 다룬 결과이며, SDD 는 애초에 명세 실행기로 다루는 자세다.
6.2.2 SDD ≠ 워터폴 — 같은 단어, 다른 동물
SDD 를 처음 들으면 워터폴(Waterfall) 의 부활 처럼 들린다. 명세서를 먼저, 코드를 나중에 라는 자세가 표면적으로 같다. 그러나 셋이 다르다.
| 축 | 워터폴 (1970~) | 애자일 (2001~) | SDD (2025~) |
|---|---|---|---|
| 명세서의 독자 | 인간 개발자 | 사람·도구 혼용 | AI 에이전트 |
| 명세서의 단위 | 수백~수천 페이지 | 사용자 스토리 카드 | PRD 1~3 페이지 + ADR |
| 명세서의 수정 주기 | 분기·년 단위 | 스프린트 단위 | 세션 단위 (실시간) |
| 명세서의 검증 | 사람 리뷰 회의 | 사용자 테스트 | AI 가 명세서 위반 시 자동 거부 |
워터폴은 인간이 읽고 따르는 명세서였고, 그래서 너무 자세하면 누가 안 읽고 너무 짧으면 의미 없는 딜레마가 있었다. SDD 의 명세서는 AI 가 읽고 따르는 문서다. AI 는 100 페이지 PRD 를 읽기 싫어하지 않는다 (컨텍스트 윈도우만 충분하면). 그러나 너무 길면 컨텍스트 부패가 일어난다 (Chapter 2). 그래서 SDD 의 명세서는 1~3 페이지의 핵심 + 깊은 내용은 wikilink 분기 로 기록한다 — 워터폴과는 글의 형태 자체 가 다르다.
6.2.3 더 깊은 원인 — 토큰 경제와 명세서의 ROI
SDD 가 단순한 방법론 추천 이 아니라 경제적 강제 가 된 이유는 그 ROI(Return on Investment, 투자 수익률) 의 크기다. 명세서를 기록하는 비용 과 명세서가 절약하는 비용 의 비대칭이 결정적이다.
한 벤치마크는 PRD(Product Requirements Document) 를 선제적으로 제공한 작업이 그렇지 않은 작업 대비 토큰 소비 효율 5.5 배 를 기록한다고 보고한다. 같은 결과를 5.5 배 적은 토큰 으로 얻는다는 의미다. Claude API 의 토큰 가격이 백만 토큰에 수 달러 인 시대에 5.5 배 효율은 경제적 강제 다. 프로젝트 한 개 토큰 비용 이 1,000 달러였다면 SDD 로 박은 같은 프로젝트는 180 달러 가 된다. 이 격차가 누적되면 회사 단위에서 연 단위 수십~수백만 달러 의 차이를 만든다.
추가로 인간 비용도 있다. MIT/Microsoft 공동 연구는 프로그래밍 소요 시간 56% 단축, PR 리뷰 주기 31.8% 단축 을 보고했다 lesson/hrn-sdd-evidence. 명세 작성 20 분 이 디버깅 2 시간 을 절약한다는 ROI 데이터다. 이 두 통계 — 토큰 5.5 배 + 시간 56% — 가 SDD 가 시대 역행이 아닌 경제적 진보 라는 점의 결정적 근거다.
6.3 역사적 · 기술적 맥락 — Spec Kit 4 단계와 그 작동 원리
6.3.1 GitHub Spec Kit (2025) — 4 단계의 구체화
GitHub 가 2025 년 후반 발표한 Spec Kit 프레임워크가 SDD 를 실무 도구 로 박은 결정적 사건이다. Spec Kit 은 작업을 AI 에 위임하기 전에 4 단계의 명확한 구조화 과정을 강제 한다.
1 단계 — 헌장(Constitution). 시스템이 타협할 수 없는 비기능적 절대 원칙 을 선언한다. 보안 규정, 성능 임계치, 에러 처리 정책, 사용 금지 패턴. 헌장은 프로젝트의 헌법 이며 한 번 박히면 모든 후속 결정의 상위 제약 이 된다. 길이는 보통 반 페이지 — 너무 짧지도 너무 길지도 않게.
2 단계 — 명세(Specify). 특정 기술 스택에 얽매이지 않고 비즈니스 의도와 무엇을·왜 만드는지 의 본질적 요구사항을 기술한다. 사용자, 사용자의 목표, 성공 지표, 거절된 대안. 이 단계가 워터폴의 사양서 와 가장 가까워 보이지만, 길이가 1~3 페이지 에 그친다는 점이 결정적으로 다르다.
3 단계 — 계획(Plan). 데이터베이스 스키마 모델링, API 인터페이스, 컴포넌트 분해, 의존성 그래프, 리스크 항목. 아키텍처 결정 을 기록해 구조적 붕괴 를 방지한다. ADR(Architecture Decision Records, 아키텍처 결정 기록) 의 형식이 일반적으로 채택된다.
4 단계 — 작업(Tasks). 위 3 단계의 명세를 기반으로, 자율형 AI 에이전트가 단독으로 실행하고 검증할 수 있는 가장 작은 원자적 단위(atomic units) 로 이슈를 분할한다. 각 작업은 입력 / 출력 / 검증 기준 이 명확해야 하며, 이상적으로 AI 가 한 세션 안에 완수할 수 있는 크기 다.
6.3.2 4 단계가 5 종 청구서 를 어떻게 막는가
이 4 단계가 단순한 추천이 아니라는 점은 Chapter 5 의 5 종 청구서와의 1:1 매핑 으로 드러난다.
| Spec Kit 단계 | 막는 청구서 | 메커니즘 |
|---|---|---|
| 1 헌장 | ② 보안 + ④ 운영 | 타협 불가 원칙으로 기본값 을 안전한 쪽으로 값 |
| 2 명세 | ① 기술 부채 + ⑤ 인간 역량 | 왜 만드는지가 기록되어 있어 코드 중복 + 멘탈 모델 외재화 |
| 3 계획 | ③ 데이터 모델 | 스키마와 의존성을 코드 전에 결정 — 30 분 직관 ❌ |
| 4 작업 | 5 종 모두 | 원자적 단위로 분해되어 각 작업이 검증 가능 |
5 종 청구서의 단일 원인 = 명세 부재 (Chapter 5 §5.7) 가 4 단계의 단일 처방 = 명세 박기 로 정확히 매핑된다. 다이어그램 6-2 가 이 매핑을 한 컷에 담는다.
6.3.3 명세 작성 20 분 = 디버깅 2 시간 절약 의 메커니즘
ROI 의 작동 원리를 한 단계 더 들어가 보자. 디버깅이 오래 걸리는 이유는 시스템이 어떤 결정 위에서 짜였는지 를 추적하는 데 시간이 들기 때문이다. 명세서가 없으면 디버거는 코드를 읽고 결정을 역추론 해야 한다. 100 줄짜리 함수의 왜 이렇게 짜졌는가 를 파악하는 데만 30 분이 걸리기도 한다. 명세서가 기록되어 있으면 결정의 근거 가 코드 옆에 기록되어 있어 디버거는 역추론 단계 를 건너뛴다. 20 분 명세 작성이 2 시간 디버깅 의 역추론 단계 전체 를 미리 박아두는 것이다.
이 점이 Chapter 5 §5.6 의 인간 역량 청구서 처방의 핵심이기도 하다. 명세서는 인간의 멘탈 모델을 외재화 하는 장치다. 사용자의 머리 속에 기록되어 있던 왜 가 코드 옆 파일로 외재화되면, 그 멘탈 모델은 3 개월 뒤에도 그 자리 에 있다. 외재화된 모델은 부패하지 않는다.
6.3.4 산업의 빠른 흡수 — Anthropic · Microsoft · Cursor · GitHub
Spec Kit 발표 후 6 개월 안에 4 대 도구가 모두 같은 패턴을 흡수했다. Claude Code 는 "Explore first, then plan, then code" 를 공식 Best Practice 로 박았다. GitHub Copilot 은 Plan Mode + AGENTS.md + custom instructions 를 결합해 "higher quality pull requests" 를 측정 결과로 발표했다. Cursor 는 Rules + Plan Mode 를 UX 로 강제했다. Microsoft 는 Spec → Plan → Implement → Verify 4 단계 워크플로를 자체 사내 표준으로 박았다 lesson/hrn-sdd-evidence.
세 도구가 서로 다른 회사에서 만들어졌지만 같은 결론에 수렴 한 점이 결정적이다. 이는 한 회사의 전략 이 아니라 산업적 사실 이라는 신호다. Chapter 1 §1.3.3 의 4 거인의 같은 결론 이 그대로 다시 박힌다 — 바로 생성보다 먼저 구조화가 통계적으로 더 성공적 이다.
6.4 도구의 관점 — 2 시간짜리 PRD 한 페이지 워크플로
[[DIAGRAM:6-1]]
[[DIAGRAM:6-2]]
다이어그램 6-1 은 Spec Kit 4 단계의 흐름을, 6-2 는 5 종 청구서 ↔ 4 단계 매핑 을 한 컷에 담는다.
6.4.1 실무 워크플로 — 새 기능 한 개의 2 시간짜리 PRD
추상 정의만으로는 어디까지 박아야 충분한가 가 손에 잡히지 않는다. 팀 3 명, 새 기능 1 개 (예: 미니 CRM 의 결제 모듈), 2 시간 안에 기록하는 PRD 의 7 단계를 기록한다.
1 단계 — 1 줄 의도 (5 분). "무엇을, 왜, 누구를 위해" 를 한 줄로 기록한다. 예: "프리랜서 디자이너가 클라이언트에게 청구서를 보내고 결제 상태를 추적할 수 있는 결제 모듈." 이 한 줄이 모든 후속 결정의 정렬축이다.
2 단계 — 헌장 (15 분). 이 기능의 타협 불가 5 항목 — (1) PCI DSS(Payment Card Industry Data Security Standard, 결제카드 산업 데이터 보안 표준) 준수, (2) 결제 정보 평문 저장 ❌, (3) Stripe API 만 사용, (4) 환불 정책은 별도 모듈, (5) 응답 시간 < 500 ms. 헌장은 반 페이지 를 넘기지 않는다.
3 단계 — 명세 (40 분). 왜·무엇 의 1~3 페이지. 사용자 시나리오 3 개 (정상 결제 / 결제 실패 / 환불), 각 시나리오의 입력·출력·UI 변화. 거절된 대안 2 개 (Toss 연동 — 비용으로 거절 / 자체 결제 — 라이선스로 거절) 와 그 이유. 성공 지표 (월 100 건 결제 / 실패율 1% 이하).
4 단계 — 계획 (30 분). 데이터 모델 (Invoice / Payment / RefundLog 3 테이블 + 인덱스), API 인터페이스 (POST /invoices, POST /payments/webhook 등 6 개 엔드포인트), 의존성 (Stripe SDK + 기존 Client 모듈), 리스크 (Stripe webhook 재시도 처리 / 환불 동시성).
5 단계 — 작업 분해 (20 분). 4 단계를 원자적 작업 으로 분해. 예: (a) Invoice 모델 생성 + 마이그레이션, (b) Stripe API 클라이언트 wrapper, (c) POST /invoices 엔드포인트, (d) 결제 webhook 핸들러, (e) UI: 청구서 생성 폼, (f) UI: 결제 상태 표시. 각 작업이 AI 한 세션 분량 (보통 30~60 분).
6 단계 — 검증 기준 (10 분). 각 작업의 완료 정의(Definition of Done). 통합 테스트 시나리오, 성능 측정 (500 ms 이내), 보안 체크리스트 (평문 저장 검증). 이 기준이 박혀야 AI 가 어디까지 만들어야 끝 인지를 안다.
7 단계 — 첫 작업 위임 (0 분 — 위임 한 줄). "위 명세서를 기반으로 (a) Invoice 모델부터 시작. CLAUDE.md 의 헌장과 본 PRD 를 우선 참조." 이 한 줄로 AI 에 위임하면, AI 는 2 시간짜리 PRD 위에서 첫 벽돌을 쌓는다.
이 2 시간 + 위임 한 줄 이 바이브 코딩 30 분 + 90 일 디버깅 의 대안이다. ROI 데이터 (시간 56% 단축, 토큰 5.5 배) 의 실무 자리.
6.5 닫으며 — 회귀의 자리에서 다음 도약을 본다
본 장의 핵심을 한 줄로 정리하면 — SDD 의 회귀는 시대 역행 이 아니라 AI 시대에 맞춘 명세서의 재정의 이며, PRD → 토큰 5.5 배 / 시간 56% / PR 리뷰 31.8% 의 ROI 데이터로 뒷받침된 경제적 강제 다. 마법은 끝났고, 청구서는 도착했고, 산업은 명세서 라는 닻을 다시 잡았다. 이것이 Part 2 의 마무리 자리다.
그러나 SDD 자체로는 충분하지 않다. SDD 는 작업 단위가 정의된 후 의 자세를 다룬다. 그 작업들 사이의 흐름 — AI 에이전트가 어떻게 자율적으로 계획하고, 코드를 수정하고, 테스트를 돌리고, 결과를 검증하는가 — 는 SDD 너머의 영역이다. 그 영역이 다음 Part 3 의 주제다.
다음 Chapter 7 (Part 3 의 시작) 은 그 도약 — 에이전틱 엔지니어링(Agentic Engineering) — 으로 들어간다. 코드 자동 완성 수준의 단일 모델 호출을 넘어, 스스로 계획하고 코드를 수정하며 컴파일 오류를 수정하는 에이전트들의 협력 팀을 편성하고 조율하는 자세. 그리고 그 자세가 인간 개발자의 역할을 코드 저자(Author) 에서 아키텍트이자 리뷰어(Architect and Reviewer) 로 어떻게 재정의했는지를 본다.
6.6 용어 정리
- SDD (Spec-Driven Development, 명세 주도 개발): 코드 전에 명시적 명세서와 아키텍처 제약을 박고 그 위에서만 AI 에 위임하는 워크플로
- 명세서 (Specification, Spec): 무엇을, 왜 만드는지를 코드 전에 박은 문서. SRS · PRD · API 명세 등 SW 표준 어휘. 본 책 표어의 설계 는 추상적 자세(designing), 명세서 는 그 자세의 산출물(specification) 로 분리
- Spec Kit: GitHub 2025 발표 — 헌장 → 명세 → 계획 → 작업의 4 단계 SDD 프레임워크
- 헌장 (Constitution, Spec Kit 1 단계): 시스템의 타협 불가 비기능적 절대 원칙 (보안 / 성능 / 사용 금지 패턴)
- 명세 (Specify, Spec Kit 2 단계): 무엇을, 왜 만드는지의 본질적 요구사항 — 1~3 페이지의 PRD
- 계획 (Plan, Spec Kit 3 단계): 데이터 모델 · API · 의존성 · 리스크 같은 아키텍처 결정 기록
- 작업 (Tasks, Spec Kit 4 단계): AI 에이전트가 단독으로 완수·검증 가능한 원자적 단위
- PRD (Product Requirements Document, 제품 요구사항 정의서): 제품의 왜·무엇 을 정리한 문서. 본 책에서는 명세서 의 대표 형식
- ADR (Architecture Decision Records, 아키텍처 결정 기록): 어떤 결정을, 왜, 어떤 대안을 거절하고 채택했는지 박아두는 형식
- 워터폴 (Waterfall): 1970 년대 표준 — 사양서 → 설계 → 구현 → 테스트의 일방향 흐름. 인간이 읽는 사양서
- 애자일 (Agile): 2001 년 선언 — 스프린트 단위 반복. 사용자 스토리 카드
- 명세 실행기 (Spec Executor, 비유): SDD 가 AI 에 부여한 새 정체성 — Claude Code 같은 도구가
CLAUDE.md+ 명세서 + Plan 을 입력받아 결정론에 가까운 코드 를 출력. 마법사 의 반대편. 결정론 측면에서는 컴파일러 (소스 → 바이너리) 와 같은 결 - ROI (Return on Investment, 투자 수익률): 투입 대비 회수의 비율 — 명세 작성 20 분 / 디버깅 2 시간 절약
- 완료 정의 (Definition of Done, DoD): 작업이 어디까지 만들어져야 끝 인지를 미리 박은 기준
6.7 더 읽을거리
위키 카드:
- concept/spec-driven-development — SDD 정의 + MIT/MS 56% 통계 + 5 대 검증 체크리스트
- lesson/hrn-sdd-evidence — SDD 실증 벤치마크 단원 (LangChain · Microsoft · Klarna · Podium 사례)
- concept/vibe-coding — 카파시 시작점이지 목적지가 아님 한정
- entity/karpathy — Things get better in plan mode 인용
1차 출처:
- GitHub Spec Kit 발표 — 2025 후반
- MIT × Microsoft 공동 연구 — 프로그래밍 시간 56% 단축, PR 리뷰 주기 31.8% 단축
- DeputyDev 대규모 실증 벤치마크
- Anthropic Best Practices: Explore-Plan-Code — Claude Code 공식 문서
Diagram 명세 블록
[[DIAGRAM:6-1]] Spec Kit 4 단계의 흐름
┌────────────────────────────────────────────────────────────────────┐
│ [Diagram 6-1] GitHub Spec Kit — 4 단계 SDD 흐름 │
├────────────────────────────────────────────────────────────────────┤
│ │
│ 1 단계 헌장 (Constitution) │
│ ───── │
│ 타협 불가 비기능적 절대 원칙 │
│ - 보안 규정 (PCI DSS 준수, 평문 저장 ❌) │
│ - 성능 임계치 (응답 < 500 ms) │
│ - 사용 금지 패턴 (raw SQL ❌, print 디버깅 ❌) │
│ 분량: 반 페이지 │
│ │ │
│ ▼ │
│ │
│ 2 단계 명세 (Specify) │
│ ───── │
│ *무엇을, 왜* 의 본질적 요구사항 │
│ - 사용자 시나리오 3 개 (정상 / 실패 / 환불) │
│ - 거절된 대안 + 그 이유 │
│ - 성공 지표 (월 100 건 / 실패율 1% 이하) │
│ 분량: 1~3 페이지 │
│ │ │
│ ▼ │
│ │
│ 3 단계 계획 (Plan) │
│ ───── │
│ 아키텍처 결정 기록 (ADR) │
│ - 데이터 모델 (3 테이블 + 인덱스) │
│ - API 인터페이스 (6 엔드포인트) │
│ - 의존성 + 리스크 │
│ │ │
│ ▼ │
│ │
│ 4 단계 작업 (Tasks) │
│ ───── │
│ 원자적 단위로 분해 (AI 한 세션 분량 30~60 분) │
│ (a) 모델 + 마이그레이션 │
│ (b) Stripe wrapper │
│ (c) POST /invoices │
│ (d) webhook 핸들러 │
│ ... │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────┐ │
│ │ AI 에 위임 — 위 4 단계 위에서만 벽돌 쌓기 │ │
│ │ 명세 실행기 = 마법사 ❌ │ │
│ └────────────────────────────