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