테마
Analyze Requirements
목표
requirements에서 design으로 넘어가기 전에 요구사항의 모순과 빈틈을 찾는 방법을 익힙니다.
개념
Analyze Requirements는 요구사항을 하나씩 보지 않고 전체 집합을 함께 추론해, 읽어서는 잡기 어려운 문제를 찾습니다.
| 찾는 문제 | 예 |
|---|---|
| 논리적 모순 | 각각은 말이 되지만 함께는 불가능한 두 요구사항 |
| 모호함 | "큰 파일", "빠른 응답"처럼 구현이 갈릴 표현 |
| 충돌하는 제약 | 동시에 만족할 수 없는 기능·비기능 요구사항 |
| 드러나지 않은 가정 | 정의되지 않은 개념이나 동작을 참조 |
| 누락된 엣지 케이스 | 실패 모드, 경계 조건, 동시 접근 |
실행 방법
| 환경 | 방법 |
|---|---|
| IDE | requirements가 생성되면 두 곳에 Analyze Requirements가 나타납니다. 채팅의 진행 선택지, 그리고 에디터의 Continue 드롭다운(Proceed to Design 옆)입니다. |
| CLI | /spec analyze_requirements를 실행합니다. 인자가 없으면 requirements.md가 있는 Spec을 고르는 목록이 뜨고, /spec analyze_requirements my-feature처럼 이름을 주면 바로 시작합니다. 요구사항이 있는 Spec이 없으면 /spec new <name>으로 먼저 만듭니다. |
| Web | 아직 지원하지 않습니다. |
결과
- 분석은 몇 초가 아니라 몇 분 걸립니다.
- 발견 사항이 준비되는 대로 명확화 질문이 채팅에 올라옵니다. 질문마다 관련 요구사항, 문제 설명, 고를 수 있는 수정안이 붙습니다.
- 수정안을 고르거나, 직접 답을 쓰거나, 의도된 모호함이면 질문을 닫습니다.
- 질문을 해결할 때마다 Kiro가 에디터의
requirements.md를 갱신합니다. - 요구사항을 손으로 고친 뒤 다시 실행하면, 바뀐 요구사항과 그 상호작용을 다시 분석합니다.
언제 쓰나
- 요구사항이 많은 복잡한 기능
- 금융·의료·컴플라이언스처럼 도메인 민감도가 높은 프로젝트
- 요구사항을 사람이 검토하지 않고 자동 생성한 Quick Spec 세션
작고 잘 이해된 Spec이라면 건너뛰고 design으로 가도 됩니다.
해볼 것
- 일부러 "목록은 최대 10개" 요구사항과 "사용자는 무제한으로 항목을 추가할 수 있다" 요구사항을 함께 둔 Spec을 만듭니다.
- Analyze Requirements를 실행하고, 이 모순이 질문으로 올라오는지 확인합니다.
- 수정안을 하나 골라
requirements.md가 바뀌는 것을 봅니다.
더 알아보기
- Spec 세션
- Property-based 테스트: 요구사항을 테스트 가능한 속성으로 바꾸는 다음 단계
출처: Analyze Requirements (2026-10-26 확인)