코드보다 스펙이 중심이 되는 시대의 도래
AI 코딩 도구가 빠르게 발전하면서 개발자들의 워크플로우에도 변화가 일어나고 있다.
그중 최근 주목받는 개념이 바로 Spec-Driven Development(SDD), 즉 스펙 중심 개발이다.
표면적으로는 “문서 먼저, 코드 나중”이라는 접근처럼 보이지만, 실제로는 AI가 개발 프로세스에 참여하는 방식을 근본적으로 바꾸는 새로운 패러다임에 가깝다.
이 글에서는 Thoughtworks의 엔지니어 Birgitta Böckeler가 직접 실험한 세 가지 SDD 툴—Kiro, Spec-kit, Tessl—을 중심으로,
SDD가 무엇이며, 실제 개발 환경에서 얼마나 현실적인 접근인지 구체적으로 살펴본다.
1. Spec-Driven Development란 무엇인가
문서(스펙)가 코드보다 먼저 오는 개발 방식
SDD의 기본 개념은 간단하다.
코드를 바로 작성하는 대신, “스펙(Specification)”이라는 문서를 먼저 작성한다.
이 문서에는 소프트웨어가 어떤 기능을 수행해야 하는지, 어떤 조건과 기대 결과를 가져야 하는지가 기술된다.
AI 코딩 에이전트는 이 스펙을 기반으로 코드를 생성하며, 스펙은 인간과 AI 모두가 이해할 수 있는 공통 언어이자 진실의 원천(Source of Truth) 역할을 한다.
즉, 사람이 요구사항을 정의하고, AI가 이를 코드로 번역한다.
이로써 개발자는 코드 작성보다 설계와 검증에 집중할 수 있게 된다.
2. 세 가지 단계로 나뉘는 SDD의 수준
현재 SDD는 아직 명확하게 정립된 개념이 아니며, 여러 도구와 접근 방식에서 약간씩 다른 형태로 발전 중이다.
Birgitta는 이를 **세 가지 수준(Level)**으로 구분했다.
1) Spec-first
: 기능 구현 전에 스펙을 먼저 작성하고, 그 스펙을 기반으로 AI와 함께 개발하는 단계.
스펙은 작업이 끝나면 삭제되거나 보관되지 않는다.
가장 단순하고 일반적인 형태다.
2) Spec-anchored
: 기능 개발 이후에도 스펙이 유지되며, 해당 기능의 유지보수나 개선 시 다시 참조된다.
즉, 스펙이 단발성 문서가 아닌 지속적인 관리 대상으로 작동한다.
3) Spec-as-source
: 스펙이 코드의 근본적인 원본이 된다.
개발자는 코드를 수정하지 않고, 오직 스펙만 수정한다.
AI가 스펙을 해석해 코드를 자동으로 재생성한다.
이 방식은 높은 일관성과 자동화를 가능하게 하지만, 실제 적용에는 상당한 구조적 제약이 따른다.
3. 스펙이란 무엇인가
스펙은 단순한 요구사항 문서나 설계서와 다르다.
AI가 이해할 수 있도록 구조화된 자연어로 작성된, 행동 중심적 문서다.
Birgitta는 스펙을 다음과 같이 정의한다.
“스펙은 소프트웨어의 의도와 동작을 표현하는 구조화된 산출물로, AI 코딩 에이전트의 행동을 유도하는 가이드 역할을 한다.”
스펙은 프로젝트 전체의 문맥을 설명하는 “메모리 뱅크(memory bank)” 문서들과 구분된다.
메모리 뱅크에는 시스템 아키텍처, 기술 스택, 제품 방향성 같은 정보가 포함되고,
스펙은 특정 기능이나 변경 작업에 대한 행동 지침서 역할을 한다.
4. 세 가지 대표 SDD 도구 비교
4-1. Kiro – 가장 가벼운 스펙 중심 워크플로우
Kiro는 VS Code 환경에서 작동하는 가벼운 SDD 도구다.
“요구사항 → 설계 → 작업(Task)”의 세 단계로 구성되며, 각 단계는 하나의 Markdown 문서로 표현된다.
- 요구사항(Requirements): “As a…” 형식의 사용자 스토리와 “GIVEN–WHEN–THEN” 형태의 수용 기준이 포함된다.
- 설계(Design): 데이터 모델, 오류 처리, 테스트 전략 등 기술적 설계 요소를 담는다.
- 작업(Tasks): 구현해야 할 작업 목록을 추적한다.
Kiro는 단순성과 명확성을 장점으로 하지만, 작은 수정이나 버그 해결 같은 작업에는 다소 과도한 절차가 필요하다는 단점이 있다.
4-2. Spec-kit (GitHub) – 체계적이지만 복잡한 SDD 접근
Spec-kit은 GitHub이 제안하는 CLI 기반 SDD 프레임워크로,
AI 코딩 어시스턴트(Copilot 등)와 긴밀히 연동된다.
Spec-kit의 핵심 구조는 다음과 같다.
- Constitution(헌장): 모든 변경에 적용되는 불변의 원칙과 규칙을 정의한 문서.
- Spec / Plan / Task 파일들: 각 기능 개발 단계를 분리하여 관리하며, 체크리스트 기반으로 검증 과정을 거친다.
- Templates: 프로젝트 전체의 스펙 구조를 통일하기 위한 템플릿 파일.
이 방식은 매우 정교하고 커스터마이즈 가능하지만,
각 기능마다 수많은 Markdown 파일이 생성되며 리뷰 과정이 지나치게 장황해지는 문제가 있다.
Birgitta는 이를 “코드를 리뷰하는 것보다 문서를 리뷰하는 것이 더 피곤한 경험”이라고 평가했다.
4-3. Tessl – 스펙과 코드의 완전 동기화 실험
Tessl Framework는 아직 비공개 베타 단계이지만,
세 가지 도구 중 가장 진보된 형태의 SDD 구현을 목표로 한다.
Tessl에서는 스펙이 코드의 원본으로 간주된다.
개발자가 스펙을 수정하면 AI가 자동으로 코드를 재생성하며,
코드 상단에는 “// GENERATED FROM SPEC - DO NOT EDIT” 주석이 추가된다.
예를 들어 dynamic-data-renderer.spec.md 파일이 있다면,
AI는 이를 기반으로 dynamic-data-renderer.js 파일을 생성한다.
즉, 스펙 한 개 = 코드 한 개의 매핑 구조다.
이 방식은 높은 일관성과 자동화를 제공하지만,
AI의 비결정성(Non-determinism) 때문에 매번 동일한 결과를 보장하지 않는다는 한계도 존재한다.
5. 실사용에서 드러난 문제점과 한계
Birgitta는 실제로 이 세 가지 도구를 사용해본 후, 다음과 같은 공통적인 문제를 지적했다.
- 워크플로우의 과도한 복잡성
작은 기능 수정조차도 수많은 문서를 작성해야 하며, 이는 생산성을 저하시킬 수 있다. - 문서 검토 피로도
AI가 생성한 Markdown 파일이 많아질수록 검토 부담이 커진다.
때로는 “코드를 직접 보는 게 더 낫다”는 생각이 들 정도였다. - AI의 불완전한 해석 능력
모든 명시된 지침이 항상 정확히 반영되지 않는다.
때로는 기존 클래스를 중복 생성하거나, 반대로 과도하게 세부사항을 추가하는 등 불안정한 결과를 보였다.
결국 SDD는 “문서 중심 사고”를 강화하지만,
그 자체로는 인간의 검증과 반복적 피드백을 완전히 대체하지 못한다.
6. 과거의 교훈: Model-Driven Development(MDD)와의 유사성
Spec-as-source 접근은 과거 모델 기반 개발(Model-Driven Development, MDD) 을 떠올리게 한다.
MDD에서도 모델(=스펙)을 정의하면, 그 모델을 기반으로 코드를 자동 생성했다.
그러나 당시에는 모델 관리의 복잡성과 코드 생성 제약으로 인해 실무에서 널리 채택되지 못했다.
현재의 SDD는 LLM을 통해 이 한계를 극복하려 하지만,
AI의 비결정성과 명확성 부족이라는 새로운 문제가 추가되었다.
결국 SDD는 “MDD의 제약과 AI의 불확실성”이라는 양쪽의 한계를 동시에 맞이할 가능성이 있다.
정의 중인 개념, 그러나 방향성은 명확하다
현재 SDD는 아직 명확히 정의되지 않은 개념이다.
각 도구마다 접근 방식이 다르고, “스펙”이라는 용어조차 서로 다른 의미로 사용된다.
일부는 단순히 “정교한 프롬프트 작성”을 스펙으로 간주하기도 한다.
그럼에도 불구하고, Birgitta는 다음과 같은 점을 분명히 한다.
“AI와 협업하기 위해 명확하고 구조화된 스펙을 작성하는 습관은, 그 어떤 형태로든 앞으로의 개발 방식에서 필수적인 역량이 될 것이다.”
즉, 스펙 중심 사고(Documentation-first mindset) 자체는 앞으로의 AI 시대 개발에서 중요한 기본기가 될 것이다.
다만, 이를 어떻게 효율적으로 유지하고 발전시킬지에 대한 논의는 이제 막 시작된 단계다.
SDD가 던지는 진짜 질문
스펙 중심 개발은 단순히 새로운 개발 트렌드가 아니다.
그것은 우리가 **“코드보다 더 높은 수준의 사고로 소프트웨어를 설계할 수 있는가”**를 묻는 질문이다.
AI는 코드를 대신 작성할 수 있지만,
“무엇을 만들 것인가”와 “왜 그렇게 만들어야 하는가”를 정의하는 일은 여전히 인간의 몫이다.
결국 SDD의 본질은 기술이 아니라 사고의 전환에 있다.
그리고 이 전환을 주도하는 것은 스펙이 아니라,
스펙을 통해 사고의 깊이를 확장하려는 개발자 자신이다.
Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl
Notes from my Thoughtworks colleagues on AI-assisted software delivery
martinfowler.com
'인공지능' 카테고리의 다른 글
| Claude Skills: MCP를 넘어선 단순함 속의 혁신 (0) | 2025.10.20 |
|---|---|
| AI도 인간처럼 ‘뇌가 썩는다’? - 거대 언어모델(LLM)에서 발견된 인지 퇴행 현상 (0) | 2025.10.20 |
| Claude Agent Skills: AI 에이전트를 ‘현실 업무형’으로 진화시키는 새로운 방법 (0) | 2025.10.18 |
| Dexter: 자율적으로 생각하고 검증하는 금융 리서치 에이전트 (0) | 2025.10.18 |
| Vite+ : 자바스크립트 툴링 파편화를 끝내기 위한 새로운 도전 (0) | 2025.10.18 |
