onejaejae/plan-ceo-review

/plan-ceo-review — 비즈니스 가치 & 스코프 검증

기술적으로 "만들 수 있는가?"가 아니라 "만들어야 하는가?"를 검증한다. 10개 필수 질문으로 비즈니스 가치, 사용자 임팩트, 스코프 적절성, 기회비용을 체계적으로 평가하고 BUILD/PIVOT/KILL 판정을 내린다.

Why This Exists

좋은 엔지니어링 계획이라도 비즈니스 가치가 없으면 낭비다. 반대로, 가치 있는 아이디어라도 스코프가 너무 크면 영원히 출시되지 않는다. 이 스킬은 "CEO의 눈"으로 계획을 보고, 기술팀이 놓치기 쉬운 비즈니스 관점의 질문을 강제한다.

When to Use

| 상황 | 사용? | |------|------| | 새 기능/제품 기획 시작 전 | YES | | 대규모 리팩토링 전 (비즈니스 정당성 확인) | YES | | 우선순위 결정이 필요할 때 | YES | | 기술 스택 결정 | No — /tech-decision 사용 | | 기술적 실현가능성 검토 | No — /plan-eng-review 사용 | | 기획서 완성도 검증 | No — /spec-reviewer 사용 |

Step 0: Input 파싱

| Input | 처리 | |-------|------| | 파일 경로 (plan.md, spec.md 등) | Read로 읽기 | | 대화 맥락의 아이디어 | 컨텍스트에서 추출 | | URL (경쟁사, 참고자료) | WebFetch로 읽기 | | 없음 | 사용자에게 "어떤 계획/아이디어를 검증할까요?" 질문 |

---

Step 1: 10개 필수 질문 (CEO's Questions)

모든 질문에 반드시 답한다. 스킵 불가.

가치 (Value) — Q1-Q3

Q1. 이걸 왜 만드는가? (Problem Statement)

• 어떤 문제를 해결하는가?
• 이 문제를 겪는 사용자가 실제로 존재하는가?
• 현재 사용자들은 이 문제를 어떻게 해결하고 있는가? (대안 분석)

Q2. 누가 얼마나 혜택을 받는가? (Impact Sizing)

• 영향받는 사용자 수 (또는 비율)
• 사용 빈도 (매일? 월 1회?)
• 개선 정도 (시간 절약, 비용 절감, 매출 증가 — 정량화)

Q3. 경쟁 우위가 있는가? (Competitive Edge)

• 이 기능이 없으면 사용자가 떠나는가?
• 경쟁사 대비 차별점이 있는가?
• 이것이 "있으면 좋은 것"인가, "없으면 안 되는 것"인가?

스코프 (Scope) — Q4-Q6

Q4. MVP는 무엇인가? (Minimum Viable)

• 핵심 가치를 전달하는 최소 기능은?
• 현재 계획에서 빼도 가치가 유지되는 것은?
• "v1에서 안 해도 되는 것" 목록

Q5. 스코프가 적절한가? (Scope Fit)

• 예상 개발 기간 vs 비즈니스 가치
• 이 기간 동안 다른 우선순위를 포기할 가치가 있는가?
• 80/20 원칙: 20% 노력으로 80% 가치를 전달할 수 있는가?

Q6. 기술 부채를 만드는가? (Tech Debt Impact)

• 이 결정이 6개월 후에 발목을 잡을 수 있는가?
• "빠르게 만들기" vs "제대로 만들기" 트레이드오프가 있는가?
• 되돌리기 비용이 만들기 비용보다 큰가?

타이밍 & 리소스 (Timing) — Q7-Q8

Q7. 왜 지금인가? (Timing Justification)

• 이걸 지금 안 하면 무슨 일이 생기는가?
• 3개월 후에 하면 안 되는 이유가 있는가?
• 외부 요인 (규제, 시장, 고객 요구)이 있는가?

Q8. 기회비용은 무엇인가? (Opportunity Cost)

• 이걸 하면 못 하는 다른 것은?
• 그 "다른 것"과 비교했을 때 이게 더 중요한가?
• 팀의 현재 역량/가용성을 고려했는가?

리스크 & 성공 (Risk & Success) — Q9-Q10

Q9. 실패하면 어떻게 되는가? (Downside Risk)

• 최악의 경우 무엇을 잃는가? (시간, 돈, 신뢰)
• 실패를 빨리 감지할 수 있는가?
• 중간에 멈추는 것이 가능한가? (sunk cost 주의)

Q10. 성공은 어떻게 측정하는가? (Success Metrics)

• 출시 후 N주 안에 어떤 숫자가 변해야 성공인가?
• 그 숫자를 지금 측정할 수 있는가?
• "성공하면 다음 단계는?" (roadmap 연결)

---

Step 2: Verdict 판정

판정 기준

| 조건 | Verdict | |------|---------| | Q1-Q3 가치 명확 + Q4-Q5 스코프 적절 + Q7 타이밍 정당 | BUILD | | 가치는 있지만 스코프/타이밍/접근법 조정 필요 | PIVOT | | 가치 불분명, 기회비용이 높음, 타이밍 부적절 | KILL |

Verdict 세부

BUILD = "이대로 진행하라. 비즈니스 관점에서 문제없다."

• 단, 주의사항/조건이 있으면 함께 명시

PIVOT = "방향은 맞지만 조정이 필요하다."

• 무엇을 조정해야 하는지 구체적으로 제시
• 예: "스코프를 50% 줄여라", "MVP부터 시작하라", "타이밍을 Q3로 미뤄라"

KILL = "지금은 하지 마라."

• 왜 하지 말아야 하는지 근거 제시
• 대안 제안 (다른 기능, 다른 시기, 다른 접근법)

---

Step 3: 출력

# CEO Review: {계획/아이디어 이름}

**Date**: {YYYY-MM-DD}
**Verdict**: {BUILD / PIVOT / KILL}

## 한줄 요약
{이 계획에 대한 비즈니스 관점의 한줄 판단}

## 10 Questions

### Value
**Q1. 왜 만드는가?**
{답변}

**Q2. 누가 혜택을 받는가?**
{답변}

**Q3. 경쟁 우위가 있는가?**
{답변}

### Scope
**Q4. MVP는?**
{답변}

**Q5. 스코프 적절한가?**
{답변}

**Q6. 기술 부채?**
{답변}

### Timing
**Q7. 왜 지금?**
{답변}

**Q8. 기회비용?**
{답변}

### Risk & Success
**Q9. 실패하면?**
{답변}

**Q10. 성공 측정?**
{답변}

## Verdict: {BUILD / PIVOT / KILL}

{판정 근거 2-3문장}

{PIVOT인 경우}
### 조정 제안
1. {구체적 조정 사항}
2. {구체적 조정 사항}

{KILL인 경우}
### 대안
1. {대안 제안}

---

/plan-eng-review vs /plan-ceo-review

| 관점 | /plan-eng-review | /plan-ceo-review | |------|-----------------|-----------------| | 질문 | "만들 수 있는가?" | "만들어야 하는가?" | | 체크 | 기술 위험, 데이터 안전, 테스트 | 비즈니스 가치, ROI, 기회비용 | | 판정 | READY / NEEDS_WORK / NOT_READY | BUILD / PIVOT / KILL | | 언제 | 구현 직전 | 기획 시작 시 |

이상적 순서: /plan-ceo-review → (BUILD면) → 기획 → /plan-eng-review → 구현

---

Checklist Before Stopping

• [ ] 10개 질문 모두 답변했는가 (스킵 없음)
• [ ] 각 답변이 구체적인가 (예/아니오가 아닌 근거 포함)
• [ ] BUILD/PIVOT/KILL 판정이 10개 답변과 일치하는가
• [ ] PIVOT이면 조정 사항이 구체적인가
• [ ] KILL이면 대안이 제시되었는가
• [ ] 한줄 요약이 판정과 일치하는가