north-starlisted

# North Star ## Purpose SPEC/PRD가 "무엇을 어떻게"를 다루면, North Star는 **왜·어디로**를 다룬다. - 의사결정이 모호할 때 우선순위 판정의 SSOT. - 신규 요청·기능이 "범위 안인가?"를 검증 가능한 기준으로 거른다. - Won't (의도적 비-방향)을 명시해 scope creep을 사전 차단. CLAUDE.md의 P1(가정 금지) / P2(Simplicity First) / Decision Making 메타원칙의 **프로젝트 단위 인스턴스**. ## When to Invoke | 트리거 | 행동 | |--------|------| | 신규 프로젝트 시작 | `docs/NORTH_STAR.md` 부재 시 작성 제안 | | Major CR / scope 확대 의심 | 4-gate 통과 여부 점검 | | 분기 1회 정기 리뷰 | NSM 변경, Phase 정의 변경, Won't 변경 검토 | | 신규 기능 요청 진입 시 | 4-gate 통과 시만 우선순위 진입 | ## Process ### 1. North Star Statement 작성 한 문장으로 프로젝트의 종착점을 표현. 5년 뒤 이 프로젝트가 무엇이 되어 있어야 하는가. **좋은 예**: 도메인 명사 + 사용자 + 측정 가능한 결과. **나쁜 예**: "최고의 X" / "사용자 만족" — 측정 불가. ### 2. North Star Metric (NSM) 정의 — metric-as-proxy 1차 지표 1개 + 2차 보조 지표 2-4개. 모두 단일 사용자 환경에서 자가 수집 가능해야 한다. **진짜 목표가 직접 측정 불가하면 프록시를 선언한다.** 많은 프로젝트의 실제 목표(사용���의 투자 수익, 팀의 생산성, 학습 성과 등)는 외부적이거나 지연되어 직접 측정할 수 없다. 그때 "측정 불가"로 방치하지 말고: 1. **프록시 지표를 명시적으로 선언** — "진짜 목표 X 는 직접 측정 불가하므로 Y 를 프록시로 최적화한다"를 문서에 그대로 적는다. 왜 이 프록시인지 1줄 근거 필수. 2. **양(1차) + 사후 품질(2차) 짝** — 프록시는 행동의 양(추적되는 의사결정 수 등)과 그 행동의 사후 품질(성과 추적이 양(+)인 비율 등)을 짝으로 잡는다. 양만 재면 굿하트 법칙으로 프록시 자체가 게임된다. 3. **기능 평가 기준으로 사용** — "이 기능이 프록시 지표 둘 중 하나를 올리는가?" NO 면 북극성 이탈 신호. NSM 결정 기준: - Lagging (결과) vs Leading (원인) — Leading 권장 - 단일 행동만 측정 (composite 금지) - 목표값 명시 ("≥ 40% by 2026") ### 3. Pillars (전략 축) + 모듈 ↔ 축 매핑 North Star 로 가는 길을 3-5개 **전략 축**으로 분해한다. 각 축은 4요소로 정의: - **정의** — 이 축이 사용자에게 주는 것 1문장. - **현재 위치** — 이 축에 속한 기존 모듈/기능. - *