요구사항 먼저 (Requirements-first)

"무엇을 만들 것인가"를 먼저 확정한 뒤 "어떻게 만들 것인가"로 넘어가는, Feature Spec의 가장 전통적인 접근 방식입니다.

이 방식이 어울리는 경우

Requirements-first 워크플로는 사용자 행동과 비즈니스 규칙이 비교적 명확하고, 기술적인 선택지를 요구사항에 맞춰 유연하게 결정할 수 있을 때 가장 잘 작동합니다. 다음과 같은 상황에서 권장됩니다.

• 명확한 사용자 스토리 — 누가, 무엇을, 왜 하는지가 자연어로 정리되는 기능
• 유연한 아키텍처 — 요구사항이 확정된 뒤에 구현 방식을 자유롭게 고를 수 있는 환경
• 그린필드 프로젝트 — 기존 시스템 제약이 적은 신규 개발

전체 흐름

1. Feature Spec 생성 — Kiro 패널이나 command palette에서 새 spec을 만들고, 안내 화면이 나오면 Requirements-First를 선택합니다.
2. 요구사항 단계 — Kiro가 requirements.md를 생성합니다. 사용자 스토리와 수용 기준, EARS 형식의 시스템 동작 규칙, 기능 요구사항, 예외 케이스가 함께 작성됩니다. 검토하면서 누락된 시나리오를 보완합니다.
3. 설계 단계 — 요구사항을 확정하면 Kiro가 design.md를 만듭니다. 아키텍처 개요, 시퀀스 다이어그램, 데이터 모델, 인터페이스 정의, 기술 스택 제안, 오류 처리 전략, 테스트 전략이 포함됩니다.
4. 작업 단계 — 설계가 확정되면 tasks.md가 생성됩니다. 구현 단위 task에는 설명, 기대 결과, 의존 관계, 필수/선택 표시가 들어 있습니다.
5. 구현 — task를 하나씩 실행하거나, Autopilot에 맡겨 한 번에 처리할 수 있습니다.

EARS 형식 요구사항 예시

요구사항은 모호함을 줄이기 위해 EARS("WHEN ... THE SYSTEM SHALL ...") 패턴으로 작성합니다. 다음은 사용자 등록 시나리오의 일부 예시입니다.

## User Authentication
### User Registration
WHEN a user submits valid registration data
THE SYSTEM SHALL create a new user account
WHEN a user submits an email that already exists
THE SYSTEM SHALL display "Email already registered" error
WHEN a user submits invalid email format
THE SYSTEM SHALL display email validation error

모범 사례

• 먼저 사용자 스토리부터 — 사용자, 목표, 동기, 성공 기준을 한 줄씩 분명하게 적습니다.
• 설계 전에 요구사항을 충분히 다듬기 — 시나리오의 테스트 가능성을 확인하고 이해관계자 합의를 먼저 받습니다.
• EARS로 작성 — 모든 항목이 검증 가능하고 추적 가능한 단위가 됩니다.
• 설계 검토 — 요구사항을 빠짐없이 다루는지, 비기능 요구사항과 유지보수성까지 고려되었는지 확인합니다.

Build a user authentication system. Users should be able to register with
email/password, login securely, reset forgotten passwords, and logout.
The system must prevent brute force attacks and validate email formats.

자주 만나는 패턴

1. 제품 기능 개발 — PM이 정리한 사용자 스토리를 EARS로 정형화한 뒤 설계와 구현으로 이어가는 경우.
2. 고객 주도형 기능 — 고객 인터뷰나 요청을 요구사항으로 옮기고, 검증한 뒤 설계·구현 단계로 넘기는 경우.
3. 그린필드 애플리케이션 — 사용자 여정을 정의해 전체 요구사항을 도출하고, MVP task를 한 번에 실행하는 경우.

문제 해결

• 설계가 요구사항을 만족하지 못할 때 — 요구사항을 더 구체적으로 다듬고, 누락된 수용 기준을 추가한 뒤 설계를 다시 생성합니다.
• 요구사항이 너무 모호할 때 — 시나리오와 예외, 성공 기준을 보충하고 EARS 형식으로 다시 정리합니다.
• 설계 이후 요구사항이 바뀐 경우 — requirements.md를 수정한 뒤 design.md에서 Refine 버튼을 누르면 Kiro가 설계와 task를 함께 갱신합니다.