Spec Driven Development: AI 시대, 코드보다 스펙이 먼저다

개요

AI 코딩 도구가 점점 강력해지면서 새로운 개발 방법론이 등장했습니다. Spec Driven Development(SDD)는 코드를 먼저 작성하는 대신, 명확한 스펙(사양서)을 먼저 정의하고 AI가 그 스펙에 맞춰 코드를 생성하도록 하는 접근법입니다. 2025년 Thoughtworks 기술 레이더에서 핵심 신규 프랙티스로 선정된 이후, 2026년 현재 엔터프라이즈 개발의 주요 흐름으로 자리 잡고 있 습니다.

바이브 코딩의 한계, 왜 스펙이 필요한가

AI에게 자유롭게 코드를 생성하게 하는 바이브 코딩(Vibe Coding)은 프로토타입에는 효과적이지만, 프로덕션 환경에서는 심각한 문제를 일으킵니다.

바이브 코딩의 대표적인 문제점은 다음과 같습니다.

아키텍처 드리프트: AI가 일관성 없는 패턴으로 코드를 생성하면서 시스템 구조가 점점 무너짐
3개월의 벽: 코드베이스가 개발자의 인지 범위와 AI의 컨텍스트 윈도우를 동시에 초과하는 시점에서 유지보수가 사실상 불가능해짐
취약성 문제: 학술 연구에 따르면 LLM이 생성한 코드의 9.8~42.1%가 보안 취약점을 포함
협업 부재: 바이브 코딩은 본질적으로 1인 개발자에 최적화되어 있어, 팀원이 프로젝트를 이어받으려면 소스 코드를 처음부터 분석해야 함

SDD는 이런 문제를 해결합니다. 스펙이 곧 문서이자 검증 기준이 되므로, AI가 생성한 코드가 스펙에서 벗어나면 빌드가 자동으로 실패합니다.

Spec Driven Development의 핵심 원칙

SDD의 기본 철학은 단순합니다. 스펙이 코드를 지배한다. 전통적인 개발에서 요구사항 문서는 코드 작성을 안내하는 참고 자료였지만, SDD에서는 스펙 자체가 코드를 생성하는 소스가 됩니다.

세 가지 구현 패턴

1. Spec-First (스펙 우선)
스펙을 먼저 작성하고 AI가 코드를 생성하지만, 코드가 최종 산출물입니다. SDD 입문 단계에 적합합니다.

2. Spec-Anchored (스펙 고정)
스펙이 프로젝트 전체 수명 주기에 걸쳐 유지되며, 거버넌스 레이어와 승인 체크포인트가 추가됩니다. 엔터프라이즈 환경에 적합합니다.

3. Spec-as-Source (스펙이 곧 소스)
스펙 자체에서 코드가 자동 생성되며, 개발자는 생성된 코드를 직접 수정하지 않습니다. API 우선 도메인에서 성숙한 도구와 함께 사용할 때 효과적입니다.

5단계 워크플로우

SDD의 실무 워크플로우는 다섯 단계로 구성됩니다.

1단계: 실행 가능한 스펙 정의
비즈니스 컨텍스트와 성공 기준을 기계가 읽을 수 있는 규칙으로 작성합니다. 단순한 요구사항 목록이 아니라, 빌드 시 자동으로 검증할 수 있는 형태여야 합니다.

2단계: 구현 계획 생성
스펙을 아키텍처 결정으로 변환합니다. OpenAPI나 유사 포맷을 활용해 시스템 설계를 문서화합니다.

3단계: 테스트 가능한 태스크로 분해
계획을 독립적으로 구현하고 검증할 수 있는 작은 단위로 나눕니다.

4단계: AI 에이전트로 실행
각 태스크를 스펙 제약 조건 내에서 AI 코딩 에이전트가 구현합니다.

5단계: 코드가 아닌 스펙을 디버깅
생성된 코드에 문제가 있으면 코드를 수정하는 것이 아니라, 스펙의 빈틈을 찾아 보완합니다. 이것이 SDD의 가장 혁신적인 관점입니다.

주요 도구 비교

GitHub Spec Kit

GitHub이 오픈소스로 공개한 SDD 툴킷입니다. MIT 라이선스로 배포되며, 22개 이상의 AI 에이전트 플랫폼을 지원합니다.

핵심 특징은 다음과 같습니다.

4단계 워크플로우: Constitution → Specify → Plan → Tasks 순환 구조
슬래시 명령어: /speckit.specify, /speckit.plan, /speckit.tasks, /speckit.implement
에이전트 무관: GitHub Copilot, Claude Code, Gemini CLI 등 도구를 자유롭게 전환하면서 스펙 컨텍스트를 유지
Constitution 파일: 변경 불가능한 아키텍처 원칙을 정의하는 고유 기능

Kiro (AWS)

Amazon이 출시한 VS Code 기반 AI IDE로, SDD를 기본 워크플로우로 내장했습니다.

핵심 특징은 다음과 같습니다.

3단계 워크플로우: Requirements → Design → Tasks (마크다운 문서 3개)
유저 스토리 형식: GIVEN…WHEN…THEN 수용 기준을 자동 생성
스티어링 메모리: product.md, structure.md, tech.md로 프로젝트 컨텍스트를 지속 유지
Hooks 시스템: 파일 변경 시 자동 실행되는 프롬프트로 일관성과 품질을 강제

Tessl

SDD를 가장 적극적으로 추구하는 프레임워크로, Spec-as-Source 접근법을 실험 중입니다.

핵심 특징은 다음과 같습니다.

CLI + MCP 서버 형태로 배포
생성된 코드 파일에 "DO NOT EDIT" 마킹
기존 코드에서 스펙을 역으로 추출하는 기능 제공
현재 프라이빗 베타 단계

cc-sdd

Claude Code, Cursor, Gemini CLI 등 다양한 AI 코딩 도구에서 사용할 수 있는 오픈소스 SDD 프레임워크입니다. Kiro 스타일의 명령어로 Requirements → Design → Tasks 워크플로우를 지원합니다.

Claude Code에서 SDD 실전 적용

Claude Code는 별도 도구 없이도 SDD를 적용할 수 있습니다. Memory(CLAUDE.md), Subagents, Tasks, Hooks 등 기본 기능만으로 충분합니다.

CLAUDE.md를 스펙 허브로 활용

프로젝트 루트의 CLAUDE.md 파일이 SDD의 Constitution 역할을 합니다. 아키텍처 원칙, 코딩 표준, 금지 사항을 명시하면 Claude Code가 모든 대화에서 이를 참조합니다.

# Architecture Principles
- API 응답은 반드시 표준 응답 포맷을 따를 것
- 데이터베이스 쿼리는 Repository 패턴으로 추상화
- 에러 처리는 커스텀 에러 클래스를 통해 일관되게

# Forbidden
- ORM 직접 호출 금지 (Repository 계층을 거칠 것)
- any 타입 사용 금지
- console.log를 프로덕션 코드에 남기지 말 것

서브에이전트로 태스크 분해

Claude Code의 서브에이전트를 활용하면 SDD의 태스크 분해를 자연스럽게 구현할 수 있습니다. 각 서브에이전트가 독립적인 태스크를 병렬로 처리하므로 생산성이 크게 향상됩니다.

Hooks로 스펙 준수 강제

Claude Code Hooks를 설정하면 파일 저장 시 스펙 위반 여부를 자동으로 검사할 수 있습니다. 린터처럼 작동하지만, 아키텍처 수준의 규칙까지 강제할 수 있다는 점이 차별화됩니다.

실제 사례: 레거시 모더나이제이션

한 실무 테스트에서 Claude Code에 40페이지 분량의 스펙 문서 전체를 제공한 사례가 보고되었습니다. 대형 컨텍스트 윈도우를 활용해 스펙부터 최종 구현까지 일관성을 유지하며 레거시 시스템을 현대화했습니다.

이 사례가 보여주는 핵심은 다음과 같습니다.

스펙 문서가 충분히 상세하면 AI의 결과물 품질이 비례해서 올라감
컨텍스트가 크더라도 명확한 스펙이 있으면 AI가 일관된 패턴을 유지
스펙 변경 시 영향 범위를 추적하고 관련 코드를 일괄 업데이트 가능

SDD가 적합한 경우와 그렇지 않은 경우

적합한 상황

그린필드 프로젝트: 처음부터 스펙을 정의하면 AI가 의도한 대로 구축
팀 프로젝트: 스펙이 팀의 공통 언어가 되어 코드 리뷰 대신 스펙 수준에서 협업
장기 운영 시스템: 스펙이 버전 관리되는 살아있는 문서로 기능해 기술 부채 방지
규제 준수가 필요한 프로젝트: SOC 2, GDPR, EU AI Act 등 감사 증빙에 활용

적합하지 않은 상황

탐색적 프로토타이핑: 방향이 자주 바뀌는 초기 실험 단계
소규모 단발성 작업: 스펙 작성 오버헤드가 실제 구현 시간을 초과
레거시 유지보수: 기존 코드 이해 도구가 SDD보다 효과적

마무리

SDD는 AI 시대의 소프트웨어 개발에서 근본적인 패러다임 전환을 제안합니다. 핵심 메시지는 명확합니다. 코드를 디버깅하지 말고, 스펙을 디버깅하라.

바이브 코딩이 속도와 유연성을 제공한다면, SDD는 의도의 명확성과 검증 가능한 결과물을 제공합니다. 둘은 대립 관계가 아니라 보완 관계입니다. 프로토타입은 바이브 코딩으로, 프로덕션은 SDD로 전환하는 것이 현실적인 전략입니다.

시작하기 가장 쉬운 방법은 GitHub Spec Kit을 설치하고 작은 기능 하나에 스펙을 작성해보는 것입니다. 스펙의 품질이 AI 결과물의 품질을 결정한다는 사실을 직접 체감하게 될 것입니다.

참고 자료

이 글은 Claude Code를 활용하여 작성되었습니다.

'IT일반' 카테고리의 다른 글

MimikaStudio — 맥에서 돌리는 로컬 음성 합성·복제 스튜디오 (0)	2026.03.24
Defuddle - 웹 페이지에서 본문만 깔끔하게 추출하는 오픈소스 라이브러리 (0)	2026.03.24
Trino 완벽 가이드: 분산 SQL 쿼리 엔진의 모든 것 (0)	2026.03.17
CodeSpeak — Kotlin 창시자가 만든 LLM 시대의 새로운 프로그래밍 언어 (0)	2026.03.15
리워드 캠페인부터 추천 마케팅까지, 고객이 알아서 홍보하게 만드는 법 (0)	2026.03.10

생각하고 기록하고

Spec Driven Development: AI 시대, 코드보다 스펙이 먼저다

개요

바이브 코딩의 한계, 왜 스펙이 필요한가

Spec Driven Development의 핵심 원칙

세 가지 구현 패턴

5단계 워크플로우

주요 도구 비교

GitHub Spec Kit

Kiro (AWS)

Tessl

cc-sdd

Claude Code에서 SDD 실전 적용

CLAUDE.md를 스펙 허브로 활용

서브에이전트로 태스크 분해

Hooks로 스펙 준수 강제

실제 사례: 레거시 모더나이제이션

SDD가 적합한 경우와 그렇지 않은 경우

적합한 상황

적합하지 않은 상황

마무리

참고 자료

'IT일반' 카테고리의 다른 글

티스토리툴바

Spec Driven Development: AI 시대, 코드보다 스펙이 먼저다

개요

바이브 코딩의 한계, 왜 스펙이 필요한가

Spec Driven Development의 핵심 원칙

세 가지 구현 패턴

5단계 워크플로우

주요 도구 비교

GitHub Spec Kit

Kiro (AWS)

Tessl

cc-sdd

Claude Code에서 SDD 실전 적용

CLAUDE.md를 스펙 허브로 활용

서브에이전트로 태스크 분해

Hooks로 스펙 준수 강제

실제 사례: 레거시 모더나이제이션

SDD가 적합한 경우와 그렇지 않은 경우

적합한 상황

적합하지 않은 상황

마무리

참고 자료

'IT일반' 카테고리의 다른 글

'IT일반' Related Articles

티스토리툴바