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

# 기획 원리

> 한 줄 정의
> 구현 전에 "누구의 어떤 문제를, 왜 지금, 무엇으로" 풀지 결정하는 원리. 산출물은 코드가 아니라 **검증 가능한 문제 정의와 성공 기준**이다 → [[PRD-템플릿]].

## 해결하는 문제

- 잘 만든 잘못된 제품: 실행 품질이 아무리 높아도 문제 선정이 틀리면 0이 된다.
- AI 시대에 구현 비용은 급락했다 — 병목은 "무엇을 만들지"로 이동했다. 기획 품질이 전체 품질의 상한이다.

## 핵심 원리

### 1. 솔루션이 아니라 문제에서 출발한다
- 요구가 솔루션 형태로 오면("챗봇 만들어줘") 문제로 되돌린다: "그게 되면 누가 무엇을 안 해도 되나?"
- 문제 문장 형식: **{누가} {상황}에서 {목표}를 하려는데 {장애물} 때문에 {비용}을 치르고 있다.**
- 장애물·비용을 현재의 실제 사례로 확인하지 못하면 그것은 문제가 아니라 가정이다.

### 2. JTBD — 기능이 아니라 "고용되는 일"
- 사용자는 제품을 사는 게 아니라 어떤 일(Job)을 시키려고 고용한다.
- 기능 목록 대신: "어떤 상황에서 무엇을 이루려고 무엇을 기대하며 이 제품을 고용하나."
- 경쟁자는 동종 제품이 아니라 **그 일을 지금 처리하는 방식**(엑셀·수작업·외주)이다.

### 3. Working Backwards — 결과에서 역산한다
- 완성 시점의 발표문(보도자료/데모 시나리오)을 먼저 쓴다. 고객 언어로, 수치로.
- 쓰다 막히는 지점(누가 왜 기뻐하는지 설명 안 되는 부분)이 기획의 구멍이다.
- FAQ에 반박을 미리 쓴다: "이미 X가 있는데 왜?", "왜 지금?", "안 쓰면 뭘 잃나?"

### 4. 기획은 가설이다 — 반증 조건을 함께 적는다
- 형식: **{X}라고 믿는다. {Y}를 만들면 {지표 Z}가 {기간} 안에 {폭}만큼 움직인다. 아니면 {폐기/피벗}한다.**
- 반증 조건 없는 기획은 검증이 아니라 신념이다.

### 5. 가장 싼 검증부터

- 검증은 비용이 싼 수단부터: 시간 단위(인터뷰·관찰) → 일 단위(목업·랜딩) → 주 단위(수동 운영·프로토타입) → 월 단위(MVP).
- 아래 단계로 내려가기 전에 위 단계가 통과했는지 확인한다. MVP는 "학습의 최소 단위"지 조잡한 반쪽 제품이 아니다.
- 단계 구성과 순서(검증 사다리)·질문법의 **정본은 [[유저 리서치 실전]]** — 여기서는 비용 순서 원칙만 다룬다.

### 6. 결정의 되돌림 비용으로 속도를 정한다
- **Two-way door** (되돌리기 쉬움): 분석하지 말고 실행한다. 빨리 하고 빨리 되돌린다.
- **One-way door** (되돌리기 비쌈: 데이터 모델·가격 구조·공개 API·브랜드): 여기에만 분석과 [[설계 결정과 리뷰|ADR]]을 쓴다.
- 대부분의 결정은 two-way다. one-way로 착각한 신중함이 속도를 죽인다.

## 안티패턴

- **솔루션 확정 후 역산 기획** — 결론이 정해진 PRD. FAQ의 반박을 못 견딘다.
- **"모두를 위한" 제품** — 주 사용자 1명(구체 인물 수준)을 못 고르면 아무도 못 만족시킨다.
- **검증 불가 목표** — "UX 개선", "더 스마트하게". 지표·기간·폭이 없으면 목표가 아니다.
- **경쟁 기능 체크리스트 기획** — 따라잡기 목록은 Job 관점이 없다는 자백이다.

## 관련 문서

- [[요구사항과 완료 조건]] · [[우선순위와 스코프]] · [[PRD-템플릿]] · [[PROJECT-SPEC-TEMPLATE]]
- [[유저 리서치 실전]] · [[지표와 실험]]