SDD 개발 도구 비교 분석

 

Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl

 

🎯 SDD란?

Spec-Driven Development: 코드보다 명세(Spec)를 먼저 작성하고, AI가 명세를 기반으로 코드를 생성하는 방법론

3단계 접근법

• Spec-First: 명세를 먼저 작성
• Spec-Anchored: 명세를 계속 유지·관리
• Spec-as-Source: 명세만 편집, 코드는 건드리지 않음

---

📊 3가지 도구 비교

항목 Kiro Spec-kit (GitHub) Tessl

복잡도	⭐ 가장 단순	⭐⭐⭐ 매우 복잡	⭐⭐ 중간
접근법	Spec-First만	Spec-First (Anchored 지향)	Spec-Anchored + Spec-as-Source
배포 형태	VS Code 확장	CLI 도구	CLI + MCP 서버
워크플로우	Requirements → Design → Tasks	Constitution → Specify → Plan → Tasks	Spec ↔ Code 1:1 매핑
파일 수	3개 (적음)	매우 많음 (과도함)	파일당 1개 Spec
커스터마이징	낮음	⭐⭐⭐ 매우 높음	중간
상태	출시	오픈소스	Private Beta

---

🔍 세부 비교

Kiro (단순·경량)

장점:

• 가장 직관적 (Requirements → Design → Tasks)
• 파일 3개로 간단
• 빠른 학습 곡선

단점:

• 작은 버그에도 과도한 명세 생성
• 장기 유지보수 전략 불명확
• 큰 프로젝트에는 부족

적합한 경우: 중소규모 기능 개발, SDD 입문

---

Spec-kit (GitHub의 완전체)

장점:

• Constitution(프로젝트 헌법) 개념
• 매우 상세한 워크플로우
• 높은 커스터마이징 가능
• 체크리스트로 품질 관리

단점:

• 💥 가장 큰 문제: 마크다운 파일 과다 생성
• 검토 부담이 코드 리뷰보다 큼
• 중형 기능에도 과도한 절차
• AI가 명세를 무시하거나 중복 생성

적합한 경우: 대규모 프로젝트, 팀 단위 개발 (하지만 오버헤드 주의)

---

Tessl (미래 지향)

장점:

• Spec ↔ Code 1:1 매핑 (파일당 명세 1개)
• // GENERATED FROM SPEC - DO NOT EDIT
• 진정한 Spec-as-Source 지향
• 추상화 레벨이 낮아 오류 감소

단점:

• 아직 Private Beta
• LLM 비결정성 문제 (같은 명세 → 다른 코드)
• MDD의 실패 역사 반복 가능성

적합한 경우: 실험적 프로젝트, 장기 유지보수 중시

---

⚠️ 공통 문제점

1. 크기 문제 (One Size Doesn't Fit All)

• 작은 버그 수정에 4개 유저 스토리는 과함
• 중형 기능에 수십 개 마크다운도 과함
• 유연한 워크플로우 필요

2. 마크다운 지옥

"코드 리뷰보다 명세 리뷰가 더 힘들다"

• spec-kit: 반복적이고 장황한 문서들
• Kiro: 작은 작업에도 과도한 문서화

3. AI가 명세를 무시

• 큰 컨텍스트 ≠ 완벽한 이해
• 기존 코드 무시하고 중복 생성
• 헛점을 너무 열심히 따라서 오버엔지니어링

4. 기능·기술 명세 분리의 어려움

• 이론: "기능 명세만 쓰면 AI가 기술 구현"
• 현실: 어디까지가 기능? 언제 기술 디테일 추가?
• 개발자들도 제대로 못 함

5. MDD의 악몽 재현?

"Model-Driven Development가 실패한 이유를 기억하라"

MDD 문제:

• 어정쩡한 추상화 레벨
• 과도한 오버헤드
• 경직성

SDD 위험:

• MDD의 경직성 + LLM의 비결정성
• 최악의 조합 가능성

---

💡 실용적 결론

✅ SDD가 유용한 경우

1. 복잡한 요구사항 명확화
2. 팀 커뮤니케이션 도구
3. AI에게 주는 상세 프롬프트
4. 프로젝트 문서화

❌ SDD의 한계

1. 작은 버그/기능: 오버킬
2. 빠른 프로토타입: 느림
3. 명세 유지보수 부담: 코드와 싱크 맞추기
4. 도구의 미성숙: 모두 초기 단계

🎯 추천 접근법

"Spec-First는 좋다, 나머지는 신중하게"

✓ 복잡한 기능: 명세 먼저 작성
✓ 팀 논의용: 명세 활용
✓ AI 프롬프트: 구조화된 명세

✗ 모든 코드에 명세 유지 (Spec-Anchored): 부담
✗ 코드 편집 금지 (Spec-as-Source): 위험
✗ 작은 작업에 정식 워크플로우: 낭비

---

📌 핵심 인사이트

"SDD는 이미 '의미적 확산(Semantic Diffusion)' 중이다"

• 어떤 사람은 '상세 프롬프트'를 SDD라고 부름

저자의 우려:

• 도구들이 기존 개발 프로세스를 너무 문자 그대로 AI에 주입
• 오히려 문제 증폭: 리뷰 오버로드, 환각
• 독일어 'Verschlimmbesserung': "개선하려다 더 나빠지게 만듦"

실용적 조언:

1. Spec-First는 채택 (이미 많이 함)
2. 도구는 신중하게 선택
3. 작은 단계로 반복 (애자일 정신 유지)
4. 명세보다 코드가 더 중요할 때도 있음

---

🏁 최종 선택 가이드

상황 추천 도구 이유

SDD 입문	Kiro	가장 간단, 3단계만
팀 프로젝트	Spec-kit	Constitution + 협업
장기 유지보수	Tessl	Spec-as-Source 실험
실무 프로젝트	🤔 직접 작성	도구 없이 명세 먼저 쓰기