| name | plan-ceo-review |
| description | 비즈니스 관점에서 아이디어/계획을 검증하는 스킬. 기술적 타당성이 아니라
"이걸 왜 만드는가?", "ROI는?", "스코프가 적절한가?" 관점에서 10개 필수 질문을
답하고 BUILD/PIVOT/KILL 판정을 내린다.
/plan-eng-review가 기술 리뷰라면, /plan-ceo-review는 비즈니스 리뷰.
Use when: "/plan-ceo-review", "CEO 리뷰", "비즈니스 리뷰", "이거 만들 가치가 있어?",
"ROI 분석", "스코프 적절해?", "business review", "idea validation",
"이거 해야 해?", "비즈니스 검증", "가치 검증", "만들어야 하나",
"scope review", "priority check", "우선순위 맞아?".
|
| allowed-tools | ["Read","Grep","Glob","Bash","WebSearch","WebFetch"] |
/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
