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

# 우선순위와 스코프

> 한 줄 정의
> 무엇을 먼저 하고 무엇을 자를지 정하는 선택 기준. 기본값은 **임팩트×노력 2×2 + 결정 기록**. 정교한 프레임워크는 이해관계자 설득이 필요할 때만 승격한다.

## 프레임워크 채택 기준

| 프레임워크 | 적합 상황 | 주의 |
|-----------|----------|------|
| **임팩트×노력 2×2** (기본값) | 개인·소규모 팀, 항목 ≤ 20 | 노력 과소평가 경향 — 노력엔 검증·운영 포함 |
| **RICE** (Reach·Impact·Confidence·Effort) | 백로그 정량 비교, 설득 자료 필요 | 숫자가 객관성을 위장한다 — Confidence 낮은 항목은 검증부터 |
| **MoSCoW** (Must/Should/Could/Won't) | 릴리즈 범위 협상, 마감 고정 | Must 비율 > 60%(경험칙)면 협상 실패 — 다시 자른다 |
| **Kano** (기본/성능/매력 품질) | 성숙 제품의 차별화 포인트 탐색 | 신규 제품엔 과함 — 기본 품질부터 |

- 어떤 프레임워크든 **점수는 토론의 시작점**이지 결정의 자동화가 아니다. 최종 결정과 이유를 한 줄로 기록한다 — 안 하면 같은 논쟁이 반복된다.

## 스코프 설계 원리

### 1. Walking Skeleton (Alistair Cockburn) — 가장 얇은 끝-대-끝 먼저
- 모든 레이어를 관통하는 최소 경로 1개(입력→처리→출력→배포)를 최우선으로 완성한다.
- 효과: 통합 리스크를 첫 주에 소진하고, 이후 모든 작업이 "동작하는 시스템에 살 붙이기"가 된다.
- [[PROJECT-SPEC-TEMPLATE]] 19절 Phase 1이 바로 이것이다.

### 2. 수직 슬라이스 — 레이어가 아니라 기능으로 자른다
- ✕ 수평: "DB 전체 → 백엔드 전체 → 프론트 전체" — 마지막까지 아무것도 동작하지 않는다.
- ○ 수직: "기능 A의 DB+API+UI" → "기능 B의 …" — 매 슬라이스가 배포·검증 가능하다.

### 3. Appetite (Shape Up, Basecamp) — 기간을 고정하고 스코프를 변수로
- "이 기능에 얼마나 걸릴까"(견적)를 뒤집어 **"이 문제에 얼마를 쓸 가치가 있나"**(예산)를 먼저 정한다.
- 예산 초과 조짐이 보이면 기간 연장이 아니라 스코프 컷이 기본 대응이다.
- 컷 순서: 코어 루프가 아닌 것 → 수동으로 대체 가능한 것 → 첫 사용자에게 안 보이는 것.

### 4. 되돌림 비용으로 실험 순서를 정한다
- two-way 결정(UI 배치·카피·기본값)은 우선순위 논쟁 대신 실험한다.
- one-way 결정만 우선순위 회의의 대상이다 → [[기획 원리]] 6절.

## 트레이드오프

- 우선순위 프레임워크의 비용은 **평가 시간**이다. 항목당 논의 비용이 만들어내는 가치보다 커지면 2×2로 내려온다.
- 스코프 컷의 비용은 **기대 관리**다. 자른 것은 OUT 목록에 이유와 함께 남긴다 → [[요구사항과 완료 조건]] 5절.

## 안티패턴

- **전부 P0** — 우선순위가 없다는 뜻이다. Must 비율로 강제 재협상한다.
- **수평 슬라이스 계획** — "인프라부터 다 깔고"는 통합 리스크를 마지막에 몰아넣는다.
- **견적 기반 무한 연장** — appetite 없이 시작한 작업은 끝나는 조건이 없다.
- **결정 기록 없는 재논의 루프** — 같은 항목이 3번째 회의에 오르면 그것은 기록의 문제다.
- **MVP = 대충 만든 전체 제품** — MVP는 범위가 좁은 완성품이지, 전 범위의 미완성품이 아니다.

## 관련 문서

- [[기획 원리]] · [[요구사항과 완료 조건]] · [[PRD-템플릿]] · [[TECHNOLOGY-DECISION-GUIDE]] 13축(트레이드오프 우선순위)