Spec 세션

목표

Spec 세션의 3단계 프로세스(Requirements → Design → Tasks)를 이해하고, EARS 형식의 요구사항 작성법을 익힙니다.

Spec 세션이란?

Spec 세션은 Kiro의 구조화된 개발 방식입니다. 프롬프트를 체계적으로 분해하여 요구사항 → 설계 → 구현 작업으로 진행합니다.

먼저 보는 3단계 프로세스

Requirements (요구사항 또는 버그 분석)
  → Design (시스템 설계)
    → Tasks (구현 작업 분해)
      → 코드 생성·구현

기본 흐름에서는 새 기능은 요구사항을, 버그 수정은 현재·예상 동작 분석을 출발점으로 삼습니다. 요구사항이 이미 명확한 새 기능은 Technical Design 경로로 설계부터 시작할 수 있습니다. 각 경로는 실행 가능한 작업으로 이어집니다.

Spec 세션 시작 — 유형·경로 선택

Spec 세션을 시작하면 Kiro가 먼저 두 가지를 확인합니다.

① Spec 유형

옵션	사용 시기
Build a Feature	새 기능 추가·확장, 새 컴포넌트 또는 서비스 생성
Fix a Bug	결함 재현·조사, 근본원인 진단, 구조화된 분석을 통한 타깃 수정

② 시작 경로 (Build a Feature 선택 시)

옵션	사용 시기
Requirements	상위 아이디어에서 시작해 무엇을 만들지 먼저 정의하고 범위를 명확화
Technical Design	티켓·브리프·사전 논의로 요구사항이 명확해 아키텍처와 구현 계획으로 직행

선택 후 기존 Requirements → Design → Tasks 흐름으로 이어집니다. Fix a Bug 경로는 결함 재현, 근본원인 분석, 타깃 수정 과정을 구조화합니다. 자세한 내용은 Bugfix Spec을 보세요.

Tasks 검토

tasks.md의 각 항목에는 결과와 의존성을 적고, 제품 완료에 반드시 필요한 작업은 required, 있으면 좋은 확장 작업은 optional로 구분합니다. optional 작업이 required 작업의 완료 조건을 가리지 않게 하세요.

tasks.md 화면에서 Run all Tasks를 실행하면 미완료 required 작업만 대상으로 의존성을 분석해 독립 작업을 같은 wave에서 병렬 실행합니다. optional 작업은 자동 실행 대상에서 제외됩니다. 범위·Requirements·Design이 바뀌면 구현을 계속하기 전에 Kiro에게 tasks.md의 작업 목록과 의존성을 갱신하도록 요청합니다.

범위와 Spec 크기 정하기

Requirements 첫머리에 In scope와 Out of scope를 짧게 적어 이번 구현의 경계를 먼저 합의합니다. 예를 들어 To-Do 앱의 이번 Spec에는 생성·편집·삭제를 포함하고, 로그인·서버 동기화·알림 전송은 Out of scope로 둡니다.

한 Spec에는 검증 가능한 기능 하나를 담습니다. 서로 다른 기능이 독립적으로 변경될 수 있다면 하나의 거대한 Spec으로 합치지 말고 기능별 Spec으로 나눕니다. 이렇게 하면 영향 범위, 승인, 완료 기준을 더 명확히 추적할 수 있습니다.

EARS 형식

요구사항은 EARS(Easy Approach to Requirements Syntax) 형식으로 작성됩니다:

WHEN 사용자가 새로운 할 일을 입력하고 추가 버튼을 클릭할 때
THE SYSTEM SHALL 입력된 내용으로 새로운 할 일 항목을 생성하고 목록에 표시한다

특징

• 🟢 체계적 — 요구사항부터 구현까지 일관된 흐름
• 🟢 추적 가능 — 모든 코드가 요구사항에 매핑
• 🟢 협업 최적 — 팀이 동일 명세를 공유
• 🟡 초기 시간 — 명세 작성에 시간 필요
• 🟢 유지보수 — 변경 시 영향 범위 명확

적합한 상황

• 팀 프로젝트·협업
• 복잡한 기능·시스템 구현
• 장기 유지보수가 필요한 프로덕션 코드
• 명확한 요구사항·일정이 있는 경우
• 품질·일관성이 중요한 경우

사전 준비

• Kiro IDE 로그인 완료
• 프로젝트 폴더 열어둔 상태

해볼 것

1단계: Spec 생성

Kiro 패널 → Specs 섹션 → Create Spec 버튼 클릭 후 아래 프롬프트 입력:

"Task Management System"이라는 이름으로 할 일 관리 애플리케이션 spec을 만들어주세요.
핵심 기능:
- 할 일 생성, 편집, 삭제
- 우선순위 설정 (높음/보통/낮음)
- 상태 관리 (todo, in-progress, completed)
- 마감일 설정 및 알림
- 로컬 스토리지를 통한 데이터 영속성
기술 요구사항:
- HTML5, CSS3, ES6+ JavaScript
- 반응형 웹 디자인 (모바일 우선)
- 웹 접근성 지침(WCAG) 준수
- 브라우저 호환성 (최신 Chrome·Edge·Firefox·Safari 지원)

2단계: Requirements 검토

생성된 Requirements 문서를 확인합니다:

• 각 요구사항이 EARS 형식인지
• 기능/비기능 요구사항이 구체적인지
• 우선순위가 명확한지

검토 프롬프트:

Requirements를 검토해주세요. 각 사용자 스토리가 EARS 형식으로 작성되었는지 확인하고, 부족한 부분이 있다면 보완해주세요.

3단계: Design 검토

Design 문서를 검토해주세요. 기술 아키텍처와 컴포넌트 구조가 명확한지 확인하고, 데이터 모델과 API 설계가 포함되었는지 검토해주세요.

4단계: Tasks 검토

Tasks를 검토해주세요. 각 작업이 구체적이고 실행 가능한지, Requirements와 Design 문서의 내용이 Task로 적절히 분해되었는지 확인해주세요.

5단계: 구현 시작

#spec:task-management-system tasks.md의 첫 번째 작업을 구현해주세요. requirements와 design 문서를 참조하여 명세에 맞는 코드를 생성해주세요.

📝 #spec: 뒤의 이름은 자동 생성된 실제 Spec 이름으로 바꿔주세요.

Spec 파일 구조

.kiro/
└── specs/
    └── task-management-system/
        ├── requirements.md   (EARS 형식 요구사항)
        ├── design.md         (아키텍처·데이터 모델)
        └── tasks.md          (구현 작업 분해)

기대 결과

• Spec 3단계 문서가 .kiro/specs/ 에 자동 생성
• 요구사항 → 설계 → 작업으로 체계적 분해
• Task 단위로 코드 구현 가능

💡 알아두면 좋은 것

요구사항이 명확한 기능은 Quick Spec으로 Requirements, Design, Tasks를 승인 단계 없이 한 번에 생성할 수 있습니다. tasks.md의 모든 Task를 한 번에 실행하면 Kiro가 의존성을 분석하고, 서로 독립적인 Task를 동시에 실행합니다.

Design으로 넘어가기 전에 Analyze Requirements로 요구사항의 모순과 누락을 점검하고, 구현 뒤에는 Property-based 테스트로 요구사항대로 동작하는지 확인할 수 있습니다.

✅ 핵심 요약

• Spec = Requirements → Design → Tasks 3단계
• EARS 형식으로 측정 가능한 요구사항 작성
• 모든 코드가 요구사항에 매핑 → 추적 가능
• 실습 Scene C에서 전체 앱을 Spec으로 만드는 실습 진행