02. 방법론 — SDD, TDD, 그리고 결합

방법론은 “선택지 A vs B”가 아니라 레이어다. 무엇을 만들지(SDD), 옳게 만들었는지(TDD), 누가 결정하는지(04)를 각각 다른 레이어가 담당한다.

Spec-Driven Development (SDD)

한 줄 정의: 코드를 쓰기 전에 무엇을·왜 만들지를 구조화된 명세로 먼저 쓰고, 그 명세를 agent의 입력(프롬프트)으로 삼아 구현한다.

SDD의 표준 흐름은 4단계다:

Spec  →  Plan  →  Tasks  →  Implement
무엇을    어떻게    순서대로   실행

• Spec(명세): 요구사항, 사용자 스토리, 수용 기준(acceptance criteria). 기술 용어 없이 “무엇을, 왜”만.
• Plan(계획): 기술 스택, 아키텍처, 데이터 모델, API 계약. “어떻게”.
• Tasks(작업): 계획을 의존성 순서가 반영된 실행 가능한 작업 목록으로 분해.
• Implement(구현): 각 작업을 코드로. 여기서 agent가 가장 자율적으로 일한다.

핵심 규칙: 결과가 틀리면 코드를 직접 고치지 말고 위 단계(spec/plan)를 고치고 다시 생성한다. 명세가 단일 진실 공급원(source of truth)이다.

SDD가 빛나는 곳 / 아닌 곳

쓴다	안 쓴다
오래 유지보수할 프로덕션 코드	버릴 프로토타입
여러 사람/agent가 협업	5분짜리 일회성 스크립트
요구사항이 복잡하거나 모호	요구사항이 자명함
규제·보안·데이터가 걸린 기능	순수 탐색·실험

Test-Driven Development (TDD)

한 줄 정의: 코드를 쓰기 전에 실패하는 테스트를 먼저 쓰고(Red), 통과시키고(Green), 정리한다(Refactor).

agent 시대에 TDD의 의미가 더 커졌다. 테스트는 agent에게 “완료”와 “정확함”을 기계적으로 검증해 주는 계약이기 때문이다.

• 사람이 테스트(또는 수용 기준)를 정의 = “옳음의 정의”를 사람이 쥔다.
• agent는 그 테스트를 통과시키는 구현을 자유롭게 만든다.
• 테스트가 통과하면 사람은 모든 줄을 읽지 않고도 동작을 신뢰할 근거가 생긴다.

agent에게 자율성을 더 주고 싶다면, 더 좋은 테스트를 써라. 검증이 자동화될수록 사람은 “in-the-loop(매 단계 승인)“에서 “on-the-loop(감독·개입)“으로 물러날 수 있다. → 04 경계 기준 참고.

agent와 TDD의 함정

• agent는 테스트를 통과시키려고 테스트 자체를 약화시키거나, 구현이 아니라 테스트를 고치는 지름길을 택할 수 있다. → 사람은 “테스트가 올바른 것을 검증하는지”를 리뷰해야 한다. 통과 여부보다 테스트의 내용이 중요하다.
• 따라서 TDD에서 사람이 끝까지 쥐어야 할 것은 수용 기준과 테스트의 의도다.

SDD + TDD 결합

둘은 서로 다른 질문에 답하므로 함께 쓴다:

	답하는 질문	산출물	누가 주도
SDD	무엇을, 왜 만드나?	spec / plan / tasks	사람
TDD	옳게 만들었나?	테스트, 수용 기준	사람이 정의, agent가 구현

결합 흐름:

1. Spec에 수용 기준을 측정 가능하게 적는다. (“3초 안에 응답”, “잘못된 입력은 400을 반환”)
2. Plan에서 그 기준을 검증할 테스트 전략을 정한다.
3. Tasks의 각 작업을 “테스트 작성 → 구현” 쌍으로 분해한다.
4. Implement에서 agent가 Red-Green-Refactor를 돌린다. 테스트가 가드레일이 된다.

비교 요약

	Vibe coding	SDD	TDD
출발점	즉흥 프롬프트	명세 문서	실패하는 테스트
진실 공급원	사람의 머릿속	spec 문서	테스트 스위트
agent 자율성	높음(통제 약함)	중간(명세가 통제)	높음(테스트가 통제)
적합	탐색·프로토타입	유지보수할 제품	정확성이 중요한 로직
위험	유지보수 부채	초기 오버헤드	나쁜 테스트=거짓 안심

다음: SDD를 도구로 자동화하는 03-speckit.md.