Spec-driven development(SDD)의 정의 및 구현 수준
SDD의 정의는 아직 유동적이지만, AI 코딩 에이전트에게 지침을 제공하기 위해 자연어로 작성된 구조화되고 행동 지향적인 아티팩트인 ‘스펙’을 먼저 작성하는 것을 의미합니다. SDD는 구현 수준에 따라 다음과 같이 분류됩니다:
-
Spec-first: 잘 고안된 스펙을 먼저 작성하고 AI 지원 개발 워크플로우에 활용합니다.
-
Spec-anchored: 작업 완료 후에도 스펙을 유지하여 기능의 진화 및 유지보수에 지속적으로 활용합니다.
-
Spec-as-source: 스펙이 주요 소스 파일이며, 인간은 스펙만 편집하고 코드는 AI가 생성합니다.
주요 SDD 도구 분석
-
Kiro: 가장 경량화된 도구로, 주로 Spec-first 접근 방식을 따릅니다. ‘요구사항 → 설계 → 작업’의 3단계 워크플로우를 가지며, 각 단계는 마크다운 문서로 표현됩니다. ‘steering’이라는 메모리 뱅크 개념을 포함합니다.
-
Spec-kit (GitHub): CLI 형태로 제공되며, 다양한 코딩 어시스턴트 워크스페이스를 설정할 수 있습니다. ‘Constitution → Specify → Plan → Tasks’의 반복적인 워크플로우를 가지며, ‘constitution’이라는 강력한 규칙 파일(메모리 뱅크)을 전제로 합니다. 각 단계에서 많은 마크다운 파일을 생성하고 체크리스트를 활용하지만, Spec-anchored를 지향하는 듯 보여도 실제로는 변경 요청 수명 동안의 Spec-first에 가깝습니다.
-
Tessl Framework: CLI 및 MCP 서버로 제공되며, 이 세 도구 중 유일하게 명시적으로 Spec-anchored를 지향하고 Spec-as-source 수준을 탐색합니다.
// GENERATED FROM SPEC - DO NOT EDIT주석으로 스펙이 코드의 주요 아티팩트임을 강조하며, 낮은 추상화 수준(코드 파일당 스펙)에서 작동하고@generate,@test태그로 코드 생성을 지시합니다.
관찰 및 의문점
-
유연성 부족: Kiro와 Spec-kit은 단일 워크플로우를 제공하여 다양한 문제 크기와 유형에 적용하기 어렵습니다. 작은 버그 수정에도 과도한 절차와 문서가 필요하여 비효율적입니다.
-
문서 검토의 부담: Spec-kit은 반복적이고 장황한 마크다운 파일을 다수 생성하여 코드 검토보다 더 많은 피로감을 유발하며, 이는 개발자의 생산성을 저해할 수 있습니다.
-
통제감 상실: AI 에이전트가 모든 지시를 따르지 않거나, 반대로 과도하게 따르는 경우가 빈번하여, 많은 사전 스펙 설계가 오히려 통제감을 떨어뜨리고 예상치 못한 결과를 초래할 수 있습니다.
-
기능/기술 스펙 분리 모호성: 기능적 스펙과 기술적 구현 세부사항을 명확히 분리하는 것이 이상적이지만, 실제 작업에서는 그 경계가 모호하여 혼란을 야기합니다.
-
타겟 사용자 불분명: 개발자가 제품 목표 정의, 사용자 스토리 작성 등 요구사항 분석에 깊이 관여하는 것을 전제로 하지만, 대규모 기능 개발에는 전문적인 제품 및 요구사항 분석 기술이 필요합니다.
-
과거 MDD와의 유사점: Spec-as-source는 모델 기반 개발(MDD)과 유사하며, LLM의 비결정론적 특성이 MDD의 비유연성과 결합될 경우 오히려 단점을 증폭시킬 수 있다는 우려가 제기됩니다. 과거 MDD의 실패 사례를 통해 SDD의 실용성에 대한 교훈을 얻을 필요가 있습니다.