---
type: knowledge
domain: product
status: active
last-reviewed: 2026-07-27
---

# 요구사항과 완료 조건

> 한 줄 정의
> 의도를 "실행하면 PASS/FAIL이 나오는 문장"으로 바꾸는 규칙. **"완료"는 주장이 아니라 완료 조건 충족의 결과다** ([[AI-DEVELOPMENT-RULES]] E절).

## 해결하는 문제

- 형용사 요구사항("빠르게", "직관적으로")은 구현자마다 다르게 해석되고, 끝났는지 아무도 판정하지 못한다.
- AI에게 일을 맡길수록 치명적이다: 검증 기준이 없으면 AI의 "완료 주장"을 믿는 것 외에 방법이 없다.

## 핵심 원리

### 1. 요구사항은 관찰 가능한 행동으로 쓴다
- 형식(사용자 스토리): **{역할}로서 {목표}를 원한다. 그래야 {가치}.**
- 각 스토리에 수용 기준을 붙인다: Given {전제 상태} / When {행동} / Then {관찰 가능한 결과}.
- 요구사항은 what, 설계는 how. 요구사항 문서에 구현 방식이 적혀 있으면 설계 결정을 몰래 내린 것이다.

### 2. 완료 조건은 기계 검증 가능하게

| 나쁜 조건 (판단 필요) | 좋은 조건 (실행 가능) |
|----------------------|----------------------|
| 빠르게 로드된다 | LCP < 2.5s (Lighthouse CI 3회 중앙값) — 실사용 기준이면 LCP p75 < 2.5s (RUM/CrUX) |
| 검색이 정확하다 | 평가셋 50건에서 recall@5 ≥ 90% |
| 에러가 잘 처리된다 | 외부 API 타임아웃 주입 시 3상태 UI 노출 (E2E 통과) |
| 보안이 강화됐다 | [[보안-체크리스트]] 전 항목 + 시크릿 스캔 0건 |

- 변환 질문: **"이 조건을 스크립트/테스트/체크리스트로 실행하면 PASS/FAIL이 나오는가?"** 아니면 다시 쓴다.
- 도저히 기계화 안 되는 조건(디자인 톤 등)은 **판정자와 판정 방법**을 명시한다: "사람 {누가} {기준표}로 판정".

### 3. 완료 조건 3종 세트
1. **기능**: 핵심 유스케이스 시나리오 통과 (spec 3절의 표와 1:1)
2. **품질**: 성능·보안·비용 임계값 (NFR에서 도출)
3. **회귀**: 기존 테스트 전부 그린 — 새 기능이 옛 기능을 깨지 않았다는 증거

### 4. 비기능 요구사항(NFR)은 처음부터 행으로
- 성능·가용성·보안·비용·규제는 "나중에 챙길 것"이 아니라 요구사항 표의 행이다.
- 각 NFR도 임계값으로: "가용성 높게" ✕ → "월 다운타임 ≤ 43분(99.9%)" ○.
- 임계값을 모르겠으면 현재 값을 측정해 기준선으로 삼는다.

### 5. 스코프 아웃 목록이 스코프 목록만큼 중요하다
- "하지 않는 것"(OUT-n)을 명시해야 구현자(특히 AI)의 선의의 확장을 막는다 ([[AI-실수패턴]] #1).
- 스코프 아웃 항목엔 이유를 한 줄 붙인다 — 다음 사이클에 재검토 가능하게.

## 검증자 독립성

- 완료 판정은 **구현자의 자기 평가가 아니라** 요구사항 원본 + 실제 산출물의 대조로 한다.
- AI 파이프라인이면 구현 에이전트와 검증 에이전트를 분리한다 → [[개발 파이프라인 분업]].

## 안티패턴

- **완료 조건 없는 태스크 착수** — 끝을 정의하지 못했으면 시작을 미룬다.
- **요구사항에 섞인 구현 지시** ("Redis로 캐싱해서 빠르게") — 요구는 임계값으로, 수단은 설계로.
- **수용 기준의 사후 완화** — 통과 못 하면 기준을 고치는 게 아니라 미달 사실을 기록하고 결정한다.
- **전부 P0 완료 조건** — 조건이 15개(경험칙)를 넘으면 그것은 조건이 아니라 백로그다.

## 관련 문서

- [[기획 원리]] · [[PRD-템플릿]] · [[PROJECT-SPEC-TEMPLATE]] 20절 · [[Agent Evaluation]] · [[평가-계획-템플릿]]