amazon-sixpager-reviewer

# Amazon Sixpager Reviewer (Markdown)

## Overview

제공된 6pager 마크다운 문서를 읽고, (1) Context에 “왜 이 목표가 필요한가”가 수치로 드러나는지, (2) Goal이 측정 가능한 지표/기준선/기한으로 정의되는지, (3) Tasks가 완료되면 Goal 달성으로 이어지는 인과 사슬이 성립하는지, (4) 실험/서브태스크의 가설·검증·결정 규칙이 재현 가능하게 정의되는지, (5) 문서로 소통할 때 싱크가 어긋날 수 있는 정의/범위/의사결정 공백이 없는지, (6) 5 Whys 관점에서 모호한 문장이 남아있지 않은지, (7) 추후 검색/추적이 가능한 앵커(지표명/ID/링크)가 있는지를 리뷰한다.

## Workflow

### Step 0: Inputs 확인

1) 사용자가 준 파일 경로(들)를 확인한다. 파일이 없거나 내용이 대화에 포함되지 않았다면, “리뷰할 `.md` 파일 경로를 알려달라”고 요청한다.  
2) 파일이 여러 개라면 각 파일별로 리뷰를 별도 생성한다(파일명 기반).

### Step 1: 문서 구조 파악(섹션 매핑)

문서의 섹션 헤더가 정확히 `Context/Goal/Tasks`가 아니어도 의미적으로 매핑한다.

- Context 후보: Background, Problem, 현황, Why now, 고객/시장 문제, 데이터 현황
- Goal 후보: 목표, Objective, Success Metrics, North Star, KPI
- Tasks 후보: Plan, Execution, Actions, Roadmap, Initiatives, To-do

### Step 2: Context 점검(수치로 “왜 필요한가”가 보이는가)

Context는 “현상”과 “중요도”를 수치로 보여야 한다. 아래 질문에 숫자/기간/범위로 답이 나오는지 점검하고, 없으면 “추정치/측정 계획/필요 데이터”를 명시한다.

- 무엇이(어떤 지표가) 얼마나 변했는가? (기준선→현재, 변화율, 기간)
- 어디서/누가 영향받는가? (세그먼트, 채널, 제품/지역, 신규/기존 등)
- 왜 지금인가? (추세, 임계점, 기회비용, 리스크)
- 데이터 정의/출처/산식이 있는가? (측정 신뢰도)

Context에서 흔히 실패하는 문장 유형:
- “상황이 좋지 않다/문제가 있다/개선이 필요하다”처럼 재질문(왜?)을 유발하는 일반론
- “매출이 줄었다”만 있고 기준선/기간/세그먼트/정의가 없는 주장
- “고객이 불만이다”만 있고 NPS/CS/리뷰/이탈/전환 등 측정치가 없는 주장

### Step 3: Goal 점검(측정 가능한가, Context로부터 정당화되는가)

Goal은 최소한 다음을 포함해야 한다(하나라도 빠지면 “작성 보완 포인트”로 지적한다).

- Metric(지표명) / Baseline(기준선) / Target(목표치) / Timeframe(기한) / Scope(범위)
- Leading vs Lagging: 선행지표(활동/품질/전환 등)와 결과지표(매출/유지 등) 연결
- Guardrail(부작용 방지): 목표 달성 과정에서 지키면 좋은 제약(품질/비용/CS 등)

Goal 문장 작성 체크(5 Whys 방지):
- “~을 개선한다” 대신 “지표 X를 Y에서 Z로(기간 T 내) 개선한다”
- “성공한다/정상화한다” 대신 “성공 기준(컷라인)”을 명시한다

### Step 4: Tasks 점검(완료되면 Goal 달성으로 이어지는가)

Tasks는 “할 일 목록”이 아니라 “목표 달성 메커니즘”이어야 한다. 다음을 검토한다.

- 각 Task가 어떤 driver(전환율/재구매/가격/노출/품질 등)를 어떻게 바꿔 Goal 지표에 영향을 주는가?
- 각 Task에 Deliverable / Owner / Due date / 성공 기준(측정 방법)이 있는가?
- Task들 전체가 “충분 조건”에 가까운가? (측정·실험·출시·운영·리스크 관리가 누락되지 않았는가)
- 전제(Assumption)가 Task로 검증되는가? (가정 검증 계획이 있는가)

Task가 Goal과 분리되어 흔히 실패하는 패턴:
- “현황 분석/회의/커뮤니케이션”만 있고 실제 지표 변화를 만드는 실행이 없는 경우
- “기능 개발”만 있고 출시/측정/롤백/운영/CS 대응이 없는 경우
- “마케팅 집행”만 있고 타겟/채널/예산/크리에이티브/실험 설계가 없는 경우

### Step 5: Hypothesis / Experiment 점검(가설-검증-결정)

실험이나 “분석으로 검증한다”는 표현이 등장하면, 아래가 문서에 드러나는지 점검한다. 없으면 “추가해야 할 명시 항목”으로 리뷰에 포함한다.

- 가설 문장에 **세그먼트/메커니즘/지표/방향/기간**이 포함되는가?
- 검증 계획에 **primary metric / baseline / target / guardrails**가 포함되는가?
- 실험(또는 분석) 방법이 구체적인가? (대조/비교, 기간, 표본, 계측/대시보드)
- 결과 해석과 다음 액션이 합의되는가? (launch/iterate/rollback의 결정 규칙)

### Step 6: Communication / Alignment / Searchability 점검

문서만 보고 일할 때, 추후에 “정의가 달라서” 또는 “의사결정 공백” 때문에 싱크가 안 맞을 지점을 찾는다.

- 정의: 지표/세그먼트/퍼널 단계/용어가 팀별로 다르게 해석될 여지가 있는가?
- 범위: Scope/Non-goals/제약/트레이드오프가 빠져 있지는 않은가?
- 의사결정: Owner/Approver/릴리즈 게이트가 불명확하지 않은가?
- 검색: 지표명(정확한 표기), 정의/산식, 대시보드/링크, `HYP-###`/`EXP-###` 같은 ID가 있는가?

### Step 7: 5 Whys 기반 문장/논리 취약점 탐지

아래 방식으로 문장들을 점검한다.

1) Context/Goal/Tasks의 핵심 주장 문장들을 뽑는다(각 섹션 3~8개).  
2) 각 문장에 대해 “왜?”를 최소 2~4번 반복한다.  
3) 답이 “좋지 않다/필요하다/중요하다/문제가 있다”류의 추상어로 끝나면, 수치·기간·범위·정의·원인 사슬(원인→메커니즘→결과)로 문장을 다시 쓰도록 제안한다.  
4) 인과가 불명확하면 “확인해야 할 데이터/실험”을 Task로 추가 제안한다.

### Step 8: 출력물 생성 규칙(`{filename}_reivew.md`)

각 입력 파일 `X.md`에 대해, 같은 폴더에 `X_reivew.md`를 생성한다(여기서 `X`는 확장자를 제외한 파일명; 사용자가 다른 규칙을 요구하면 그 요구를 따른다).

리뷰 문서는 `assets/review-template.md`를 기반으로 작성하되, 반드시 아래를 포함한다.

- Executive summary: 가장 치명적인 3가지 결함 + 가장 효과적인 3가지 개선
- Context/Goal/Tasks 평가: 무엇이 부족한지, 어떤 추가 정보/재작성/재구성이 필요한지
- Hypothesis/Experiment 평가: 가설·검증·결정 규칙의 구체성/재현성 부족분과 보강안
- Alignment/Searchability 평가: 싱크 불일치 리스크와 검색/추적 앵커 보강안
- “Task 완료 ⇒ Goal 달성” 논리 체크: 부족하면 어떤 Task가 추가되어야 하는지
- 5 Whys 결과: 모호한 문장 목록 + 구체화된 대체 문장 제안
- 멘탈모델/프레임: 재작성에 도움이 되는 모델(예: metrics tree, working backwards, theory of change)

## References / Assets

- Rubric & 체크리스트: `references/sixpager-review-checklist.md`
- 리뷰 출력 템플릿: `assets/review-template.md`