소개
이 글에서는 최근 큰 주목을 받고 있는 방법론인 "스펙 주도 개발(SDD)"을 구현하는 두 가지 대표적인 접근 방식을 비교합니다.
- VSCode + GitHub Copilot + SpecKit: 기존 에디터에 SDD 툴킷을 추가하는 방식
- Kiro IDE: SDD 기능이 통합된 올인원 IDE
스펙 주도 개발(SDD)이란?
전통적인 개발 방식에서는 코드가 중심이고 스펙은 보조적인 역할을 합니다. SDD는 이를 뒤집어 스펙을 실행 가능한 산출물로 취급합니다.
SDD의 주요 이점
- 요구사항의 명확화 및 문서화
- AI 에이전트에 대한 정밀한 지시
- 팀 간 오해 감소
- 반복적 개선 프로세스 지원
환경 1: VSCode + GitHub Copilot + SpecKit
개요
SpecKit은 기존 개발 환경에서 SDD를 구현하기 위한 오픈소스 툴킷입니다. GitHub에서 제공하며, 슬래시 명령어를 통해 AI 에이전트와 상호작용할 수 있습니다.
설정
# Specify CLI 설치
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git
# 새 프로젝트 초기화
specify init my-project --ai copilot
# 또는 기존 프로젝트에서
specify init . --ai copilot
개발 흐름
1. 프로젝트 헌법(Constitution) 수립
/speckit.constitution Create principles focused on code quality,
testing standards, user experience consistency, and performance requirements
이 명령어는 .specify/memory/constitution.md를 생성하여 프로젝트 전반의 가이드라인을 정의합니다.
2. 스펙 작성
/speckit.specify Build an application that can help me organize my photos
in separate photo albums. Albums are grouped by date and can be re-organized
by dragging and dropping on the main page.
생성되는 파일:
.specify/specs/001-feature-name/spec.md: 기능 요구사항과 사용자 스토리
3. 기술 구현 계획 작성
/speckit.plan The application uses Vite with minimal number of libraries.
Use vanilla HTML, CSS, and JavaScript as much as possible.
생성되는 파일:
plan.md: 기술 아키텍처data-model.md: 데이터 모델 정의contracts/api-spec.json: API 사양research.md: 기술 조사 문서
4. 태스크 분해
/speckit.tasks
생성되는 파일:
tasks.md: 구현 태스크 목록 (의존성 및 병렬 실행 마커 포함)
5. 구현 실행
/speckit.implement
태스크 목록에 따라 순차적으로 구현이 진행됩니다.
SpecKit 프롬프트 파일 상세
SpecKit은 .github/prompts/ 디렉터리에 여러 프롬프트 파일을 생성합니다.
speckit.constitution.prompt.md
목적: 프로젝트의 기본 원칙과 개발 가이드라인 정의
구조:
---
description: Create or update project governing principles
---
# Project Constitution
Create a comprehensive constitution document that includes:
1. **Code Quality Standards**
- Naming conventions
- Documentation requirements
- Code review processes
2. **Testing Standards**
- Unit test coverage requirements
- Integration test strategies
- Test documentation
3. **Architecture Principles**
- Design patterns to follow
- Technology stack constraints
- Performance requirements
4. **User Experience Guidelines**
- Accessibility standards
- Responsive design requirements
- Internationalization considerations
특징:
- AI 에이전트가 이후 모든 단계에서 이 문서를 참조
- 프로젝트 고유의 모범 사례를 강제
- 팀 전체의 일관성 보장
speckit.specify.prompt.md
목적: 사용자 스토리 형식으로 기능 요구사항 구조화
구조:
---
description: Define requirements and user stories
---
# Specification Template
## User Stories
**As a** [user type]
**I want** [goal]
**So that** [benefit]
### Acceptance Criteria
- [ ] Criterion 1
- [ ] Criterion 2
## Functional Requirements
### FR-001: [Requirement Name]
**Priority**: High/Medium/Low
**Description**: Detailed requirement description
**Dependencies**: [Other requirements]
생성 과정:
- 사용자의 자연어 설명 파싱
- 사용자 스토리로 변환
- 인수 기준 명확화
- 기능 요구사항 ID 부여
speckit.plan.prompt.md
목적: 기술 구현 계획 상세화
구조:
---
description: Create technical implementation plans
---
# Implementation Plan
## Technology Stack
- Frontend: [Framework/Library]
- Backend: [Framework]
- Database: [Type]
- Deployment: [Platform]
## Architecture Overview
[System architecture diagrams, component diagrams]
## Data Model
[Entity relationship diagrams, table definitions]
## API Specifications
[Endpoint definitions, request/response formats]
## Implementation Phases
1. Phase 1: [Core features]
2. Phase 2: [Advanced features]
## Technical Considerations
- Security requirements
- Performance optimization
- Scalability concerns
특징:
- constitution.md의 원칙 준수
- spec.md 요구사항의 기술적 해결
- 여러 기술 선택지 비교
speckit.tasks.prompt.md
목적: 구체적이고 구현 가능한 태스크로 분해
구조:
---
description: Generate actionable task lists
---
# Task Breakdown
## User Story: [Story ID]
### Task 1: [Task Name]
**File**: `src/components/Feature.tsx`
**Type**: Implementation
**Dependencies**: None
**Parallel**: [P] (if parallelizable)
**Description**: Detailed task description
**Acceptance**: How to verify completion
### Task 2: [Task Name]
**File**: `tests/Feature.test.tsx`
**Type**: Testing
**Dependencies**: Task 1
생성 규칙:
- 의존성 명시적 관리
- 파일 경로 구체적으로 지정
- 테스트 주도 개발(TDD) 순서 고려
- 병렬 실행 가능한 태스크 표시
speckit.implement.prompt.md
목적: 태스크 목록에 따른 구현 실행
실행 흐름:
---
description: Execute implementation plan
---
# Implementation Execution
1. **Validate Prerequisites**
- Constitution exists
- Spec is complete
- Plan is approved
- Tasks are defined
2. **Parse Tasks**
- Read tasks.md
- Build dependency graph
- Identify parallel tasks
3. **Execute Tasks**
For each task in order:
- Create/modify specified files
- Run tests (if TDD)
- Validate against acceptance criteria
- Update task status
4. **Progress Reporting**
- Mark tasks as In Progress/Done
- Report errors with context
- Suggest next steps
speckit.clarify.prompt.md
목적: 질문을 통해 스펙의 모호한 부분 명확화
구조:
---
description: Clarify underspecified areas
---
# Clarification Questions
## Coverage Analysis
[Identify areas not covered in the specification]
## Sequential Questions
1. **Question**: [Specific question]
**Context**: [Why this is important]
**Options**: [Possible answers]
[Answers are added to Clarifications section when recorded]
특징:
- Plan 작성 전에 실행 권장
- 구조화된 질문으로 답변 유도
- 답변이 스펙에 통합됨
생성 문서 예시
실제 프로젝트에서의 디렉터리 구조:
my-project/
├── .specify/
│ ├── memory/
│ │ └── constitution.md # 프로젝트 원칙
│ ├── specs/
│ │ └── 001-photo-albums/
│ │ ├── spec.md # 기능 스펙
│ │ ├── plan.md # 구현 계획
│ │ ├── tasks.md # 태스크 목록
│ │ ├── data-model.md # 데이터 모델
│ │ ├── contracts/
│ │ │ └── api-spec.json # API 사양
│ │ └── research.md # 기술 조사
│ ├── scripts/
│ │ ├── create-new-feature.sh
│ │ └── setup-plan.sh
│ └── templates/
│ ├── spec-template.md
│ ├── plan-template.md
│ └── tasks-template.md
├── .github/
│ └── prompts/
│ ├── speckit.constitution.prompt.md
│ ├── speckit.specify.prompt.md
│ ├── speckit.plan.prompt.md
│ ├── speckit.tasks.prompt.md
│ ├── speckit.implement.prompt.md
│ ├── speckit.clarify.prompt.md
│ └── speckit.analyze.prompt.md
└── src/
└── [구현 파일들]
장점
✅ 오픈소스: MIT 라이선스로 무료 사용 가능
✅ 유연성: 여러 AI 에이전트 지원 (Claude, Gemini, Copilot 등)
✅ 점진적 도입: 필요한 기능부터 단계적으로 도입 가능
단점
❌ 수동 설정: 초기 구성에 여러 단계가 필요
❌ 연동 복잡성: 여러 도구의 조합이 필요
❌ UI 경험: 커맨드라인 중심으로 시각적 피드백이 제한적
❌ 학습 비용: 각 명령어의 역할과 순서를 이해해야 함
환경 2: Kiro IDE
개요
Kiro는 프로토타입부터 프로덕션까지 지원하는 Agentic IDE로, SDD 기능이 기본으로 통합되어 있습니다.
설정
- kiro.dev에서 IDE 다운로드
- 설치 및 실행
- VS Code 설정 및 플러그인 자동 가져오기 가능
개발 흐름
1. Steering Docs 생성
Kiro 패널에서 "Generate Steering Docs"를 선택하면 .kiro/steering/에 다음 파일들이 생성됩니다:
- 프로젝트 기술 스택 정보
- 코딩 규약
- 워크플로우 가이드라인
2. 스펙 작성의 세 단계
요구사항 단계
EARS(Easy Approach to Requirements Syntax) 형식으로 사용자 스토리와 인수 기준을 기술:
WHEN [condition/event]
THE SYSTEM SHALL [expected behavior]
생성 파일: .kiro/specs/feature-name/requirements.md
설계 단계
기술 아키텍처와 시퀀스 다이어그램 문서화:
생성 파일: .kiro/specs/feature-name/design.md
태스크 단계
구현 태스크의 상세 계획:
생성 파일: .kiro/specs/feature-name/tasks.md
3. Hooks를 이용한 자동화
파일 변경에 반응하여 태스크를 자동으로 실행하는 이벤트 주도 자동화:
예시: "React 컴포넌트를 저장하면 테스트 파일 자동 생성"
{
"hooks": [
{
"trigger": "onFileSave",
"pattern": "**/*.tsx",
"action": "generateTests"
}
]
}
Kiro 문서 구조
my-project/
├── .kiro/
│ ├── steering/
│ │ ├── tech-stack.md
│ │ ├── coding-standards.md
│ │ └── workflows.md
│ └── specs/
│ └── photo-albums/
│ ├── requirements.md # EARS 형식 요구사항
│ ├── design.md # 아키텍처 설계
│ └── tasks.md # 구현 태스크
└── src/
└── [구현 파일들]
장점
✅ 통합 경험: 모든 기능이 IDE에 기본 내장
✅ 시각적 UI: 스펙 목록과 태스크 상태를 시각적으로 관리
✅ 자동화: Hooks로 백그라운드 태스크 실행
단점
❌ 전용 IDE 필요: 기존 에디터에서 이전해야 함
❌ 벤더 종속: Kiro 전용 기능에 의존
상세 비교표
| 항목 | SpecKit | Kiro |
|---|---|---|
| 설정 | CLI로 수동 설정 | 다운로드 & 설치만으로 완료 |
| 학습 비용 | 명령어 학습 필요 | 직관적인 UI |
| 스펙 형식 | 템플릿이 있는 Markdown | EARS + Markdown |
| 태스크 관리 | tasks.md에서 텍스트 관리 | IDE에서 시각적 관리 |
| 자동화 | 스크립트 기반 | Hooks로 이벤트 주도 자동화 |
| Git 연동 | 자동 브랜치 기반 관리 | 수동 또는 IDE 기능 활용 |
| AI 에이전트 | 10개 이상 지원 | Kiro 통합 에이전트 |
| 확장성 | 템플릿 커스터마이징 | MCP + Powers |
| 비용 | 무료 (OSS) | 프리뷰 기간 무료 |
| 팀 공유 | Git으로 완전 공유 가능 | Git + Kiro 전용 기능 |
생성 문서 비교
Constitution/Steering
SpecKit:
.specify/memory/constitution.md: 단일 파일- 프로젝트 전체 원칙 기술
- 모든 명령어에서 참조
Kiro:
.kiro/steering/: 여러 파일- 기술 스택, 코딩 규약, 워크플로우를 분리
- 자동 생성 + 커스터마이징 가능
스펙(Specification)
SpecKit:
# spec.md
## User Stories
As a user, I want to...
## Functional Requirements
FR-001: Feature description
## Review Checklist
- [ ] Requirements are clear
- [ ] Acceptance criteria defined
Kiro:
# requirements.md (EARS format)
WHEN user clicks upload button
THE SYSTEM SHALL display file selection dialog
WHEN file size exceeds 10MB
THE SYSTEM SHALL display error message
구현 계획
SpecKit:
# plan.md
## Architecture
- Frontend: React
- Backend: Node.js
## Implementation Details
[Detailed implementation guide]
# data-model.md
[Database schema]
# contracts/api-spec.json
{OpenAPI specification}
Kiro:
# design.md
## Component Architecture
[System architecture diagram]
## Sequence Diagrams
[Flow diagrams]
## Technical Considerations
[Performance, security, etc.]
태스크(Tasks)
SpecKit:
# tasks.md
## User Story: US-001
### Task 1: Setup database schema
File: src/db/schema.sql
Dependencies: None
[P] Parallel: Yes
### Task 2: Create API endpoint
File: src/api/upload.ts
Dependencies: Task 1
Kiro:
# tasks.md
## Phase 1: Core Implementation
- [ ] Task 1: Database setup
Status: Not Started
Assignee: [Auto]
- [ ] Task 2: API development
Status: Not Started
Dependencies: Task 1
활용 가이드라인
SpecKit을 선택해야 할 때
-
기존 VSCode 환경을 유지하고 싶은 경우
- 방대한 플러그인과 설정을 그대로 활용
- 에디터 이전 비용 없음
-
팀 전체가 SDD 초보인 경우
- 명령어 기반으로 단계적 학습
- Git으로 문서 공유가 쉬움
-
여러 AI 에이전트를 시도하고 싶은 경우
- Claude, Gemini, Copilot 등으로 전환 가능
- 벤더 종속 회피
-
오픈소스를 우선시하는 경우
- 커뮤니티 주도 개발
- 커스터마이징 자유도
Kiro를 선택해야 할 때
-
생산성 극대화를 원하는 경우
- 통합 UI로 빠르게 작업
- Hooks로 반복 작업 자동화
-
시각적인 것을 선호하는 경우
- 스펙과 태스크를 시각적으로 관리
- 대시보드에서 진행 상황 확인
-
고급 자동화가 필요한 경우
- 이벤트 주도 워크플로우
- MCP로 외부 서비스 연동
-
신규 프로젝트인 경우
- 기존 환경에 얽매이지 않음
- 최신 SDD 경험 도전
SpecKit 프롬프트 파일 고급 활용
커스텀 프롬프트 작성
SpecKit 프롬프트 파일은 자유롭게 커스터마이징 가능합니다:
---
description: Custom quality checklist generator
---
# /speckit.custom-checklist
Generate a quality checklist for:
1. **Security Review**
- Authentication check
- Authorization verification
- Input validation
2. **Performance Review**
- Database query optimization
- Caching strategy
- Load testing results
[Output format: Markdown checklist in spec directory]
여러 스펙 관리
# Feature 1
specify init . --ai copilot
/speckit.specify Build user authentication system
# Feature 2 (새 브랜치에서)
git checkout -b feature/002-payment
/speckit.specify Integrate payment gateway
실전 워크플로우 예시
SpecKit을 활용한 팀 개발
graph TD
A[제품 매니저] -->|요구사항 정의| B["speckit.specify"]
B --> C["Generate spec.md"]
C --> D[Tech Lead]
D -->|기술 선택| E["speckit.plan"]
E --> F["Generate plan.md, data-model.md"]
F --> G[개발자]
G -->|태스크 검토| H["speckit.tasks"]
H --> I["Generate tasks.md"]
I --> J["speckit.implement"]
J --> K["코드 생성"]
K --> L[Pull Request]
L --> M[코드 리뷰]
M -->|승인| N[머지]SpecKit을 사용한 팀 개발 흐름: 역할에 따라 다른 명령어를 사용하며 Git으로 문서 공유
Kiro를 활용한 솔로 개발
graph TD
A[아이디어] --> B[Spec Chat]
B --> C[Requirements 생성]
C --> D[Design 생성]
D --> E[Tasks 생성]
E --> F[#spec 참조로 코드 작성]
F --> G[파일 저장]
G --> H[Hooks 트리거]
H --> I[테스트 자동 생성]
I --> J[백그라운드 실행]Kiro IDE를 사용한 솔로 개발 흐름: 통합 UI와 Hooks 자동화로 효율적인 개발 사이클
결론
SpecKit은 기존 개발 환경을 활용하면서 SDD를 도입하고 싶은 팀에 적합합니다. 오픈소스이며 높은 유연성을 갖추고, 점진적 도입이 가능합니다.
Kiro는 최신 Agentic IDE 경험을 원하는 개발자에게 적합합니다. 통합 UI, 자동화 기능, 시각적 피드백으로 생산성을 극대화할 수 있습니다.
두 환경 모두 전통적인 "вайб 코딩(vibe coding)"에서 벗어나 스펙 중심의 체계적인 개발 프로세스를 구현하는 것을 목표로 합니다. 프로젝트 특성, 팀 구성, 기존 개발 환경에 맞게 선택하세요.
- SpecKit 시도하기: GitHub 저장소
- Kiro 시도하기: 공식 사이트
