git:20260718.185c1a1 to git:20260802.f93c659

96 added, 25 removed. Audit A to A.

---

name: north-star

- description: "Defines and enforces a project's long-term direction (North Star Statement, metric-as-proxy NSM, strategic Pillars with a module↔pillar map, Will/Won't, 4-gate + priority-order decision heuristics). Use when starting a new project, when scope creep is suspected, or when a non-obvious feature request needs prioritization. Sits one layer above SPEC/PRD — answers 'why and where to', not 'what and how'."

+ description: >-

+ Defines and enforces a project's long-term direction (North Star Statement,

+ metric-as-proxy NSM, strategic Pillars with a module↔pillar map, Will/Won't,

+ 4-gate + priority-order decision heuristics), then turns that direction into a

+ ranked, persisted roadmap so the plan survives /compact and new sessions. Use

+ when starting a new project, when scope creep is suspected, when a non-obvious

+ feature request needs prioritization, or when the user asks where the project

+ should go next. Sits one layer above SPEC/PRD — answers 'why and where to', not

+ 'what and how'. Fires on the user's real phrasings: "앞으로 어떤 방향으로

+ 개선·발전시킬지 고민해봐", "NORTH.md / NORTH_STAR 보고 나아갈 방향 + 기능 제안",

+ "나아갈 방향 + 기능제안 (수용 → 계획 수립하고 메모리에 기록)", "북극성 정렬 로드맵",

+ as well as the English equivalents "what direction should we take next", "propose

+ a roadmap / feature backlog from the north star", "plan the next milestones and

+ save it to memory". Do NOT use it to find what is broken right now — detecting

+ bugs, gaps, or quality regressions belongs to the audit/gap skills; this skill

+ consumes their findings and DIRECTS forward planning.

---

# North Star

## Purpose

SPEC/PRD가 "무엇을 어떻게"를 다루면, North Star는 **왜·어디로**를 다룬다.

- 의사결정이 모호할 때 우선순위 판정의 SSOT.

- 신규 요청·기능이 "범위 안인가?"를 검증 가능한 기준으로 거른다.

- Won't (의도적 비-방향)을 명시해 scope creep을 사전 차단.

+ - 그 방향을 **지속되는 로드맵**으로 바꿔 대화가 끝나도 살아남게 한다.

- CLAUDE.md의 P1(가정 금지) / P2(Simplicity First) / Decision Making 메타원칙의 **프로젝트 단위 인스턴스**.

+ The point is alignment, not idea generation: every proposal must trace upward to

+ the north star, and the result must outlive the conversation that produced it.

## When to Invoke

| 트리거 | 행동 |

|--------|------|

- | 신규 프로젝트 시작 | `docs/NORTH_STAR.md` 부재 시 작성 제안 |

+ | 신규 프로젝트 시작 | 북극성 문서 부재 시 작성 제안 |

| Major CR / scope 확대 의심 | 4-gate 통과 여부 점검 |

- | 분기 1회 정기 리뷰 | NSM 변경, Phase 정의 변경, Won't 변경 검토 |

+ | 분기 1회 정기 리뷰 | NSM 변경, Pillar 변경, Won't 변경 검토 |

| 신규 기능 요청 진입 시 | 4-gate 통과 시만 우선순위 진입 |

+ | "앞으로 어디로 가야 하나" | 아래 로드맵 워크플로 (방향 → 순위 → 영속화) |

- ## Process

+ Do **not** reach for it to find what's broken right now. Detecting defects, gaps,

+ or quality regressions is the sibling audit skills' job; this skill consumes their

+ findings and points forward.

+ ## 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")

+ - **Lagging (결과) vs Leading (원인) — Leading 권장.** 이미 끝난 결과로는 조타할 수 없다.

+ - **단일 행동만 측정 (composite 금지).**

+ - **목표값 명시** ("≥ 40% by 2026").

+ - **게임 가능성 점검** — 가치를 전달하지 않고도 직접 올릴 수 있으면 북극성이 아니다.

+ 그런 지표를 발견하면 조용히 그것을 향해 계획하지 말고 먼저 그 사실을 알린다.

### 3. Pillars (전략 축) + 모듈 ↔ 축 매핑

North Star 로 가는 길을 3-5개 **전략 축**으로 분해한다. 각 축은 4요소로 정의:

- **정의** — 이 축이 사용자에게 주는 것 1문장.

- **현재 위치** — 이 축에 속한 기존 모듈/기능.

- **전방 목표** — 다음에 쌓을 것.

- **가설** — 이 축이 NSM 을 올린다고 믿는 이유 1줄.

그리고 **모듈 ↔ 축 매핑 표**를 유지한다: 모든 모듈은 최소 1개 축에 속한다 (플랫폼 공통

인프라는 "공통"으로 명시). **어떤 신규 모듈이 어느 축에도 매핑되지 않으면 착수 전에 북극성

정렬을 재검토한다** — 매핑 실패 = scope creep 의 조기 신호. 로드맵 항목도 정기 리뷰 때 축에

- 매핑해 "새 축·방향 변경이 필요한가"를 점검한다. (Pillars = northstar-roadmap 스킬이 말하는

- *Inputs* 와 동일 개념 — 두 스킬은 같은 축 분해를 서로 다른 이름으로 가리킨다.)

+ 매핑해 "새 축·방향 변경이 필요한가"를 점검한다.

+ 축은 아래 로드맵 워크플로가 말하는 *Inputs* 와 같은 것이다 — 북극성이 목적지라면 축은 직접

+ 움직일 수 있는 레버다. 두 이름은 같은 분해를 가리킨다.

### 4. Will / Won't / Trade-offs

- **Will**: 집중 영역 4-6개. 동사로 시작 ("개인 사용 깊이 우선", "AI 친화 1급 시민").

- - **Won't**: 의도적 비-방향 5-8개. "X는 안 한다" 명시. 가장 중요한 섹션 — scope creep의 1차 방어선.

- - **Trade-offs**: "X 선택 → Y 포기 → 근거" 표. 의식적 결정의 추적 기록.

+ - **Won't**: 의도적 비-방향 **5-8개**. "X는 안 한다" 명시. 가장 중요한 섹션 — scope creep의

+ 1차 방어선. 비어 있으면 이 문서는 아무것도 막지 못한다.

+ - **Trade-offs**: "**선택 → 포기한 것 → 근거**" 3열 표. 의식적 결정의 추적 기록이며, 같은

+ 논쟁을 반년 뒤에 처음부터 다시 하지 않게 하는 유일한 장치다.

### 5. 4-Gate Decision Heuristic — "할 것인가"

신규 요청·제안이 들어왔을 때 다음 4개 게이트를 **모두** 통과해야 우선순위 진입:

| Gate | 질문 | 통과 기준 |

|------|------|----------|

| **Trend** | 프로젝트의 핵심 트렌드/원칙 중 1개 이상에 매핑되는가? | YES |

| **Persona** | Primary persona에게 직접 가치를 주는가? Anti-persona 위주는 거절 | YES |

| **Capability** | 현재 시스템이 이 기능을 동등하게 노출 가능한가? (UI 한정 기능은 -1) | YES |

- | **Lean** | 정의된 Phase 범위 내에 있는가? 외부면 Open Question으로 적재 후 분기 1회 재평가 | YES |

+ | **Lean** | 선언된 Will 범위 내에 있는가? 외부면 Open Question으로 적재 후 분기 1회 재평가 | YES |

게이트 명칭은 프로젝트마다 customize 가능하나 **4개 ALL True** 원칙은 유지.

### 6. 우선순위 순서 게이트 — "언제 할 것인가"

- (gates-taxonomy 룰의 검증 체크포인트 4유형과 무관 — 이것은 작업 **순서** 규칙이다.)

+ (검증 체크포인트 유형 분류와 무관 — 이것은 작업 **순서** 규칙이다.)

4-gate 는 "할 것인가"를 거른다. 통과한 것들 사이의 **순서**는 별도 규칙이다 — 무엇을 먼저

할지 모호하면 이 순서로 판정한다:

1. **기본 필수 기능** — 없으면 제품이 성립 안 되는 기본기 (예: 표준 로그인). "기본"이 빠진 채

화려함부터 쌓지 않는다.

2. **기능 완성도** — 이미 shipped 된 기능이 사용자 관점 end-to-end 로 진짜 완결인가.

**단순 존재 ≠ 완결** (버튼이 동작하나, 링크가 목적지까지 가나, 빈/에러 상태가 처리되나).

- UI 트랙 설치 시 benchmark-parity 룰의 "완결성 검토" 루프와 동일 기준.

+ UI 트랙이면 벤치마크 동등성 검토 루프와 동일 기준.

3. **차별화 깊이** — 핵심 경쟁력의 advanced 구현. **research/ADR 선행 필수** — advanced 부터

코드로 뛰어들지 않는다.

**상위 순위에 미완이 있으면 하위로 건너뛰지 않는다** (긴급 hotfix·사용자 명시 지시 예외).

Plan/Define 단계에서 "이 작업이 ①/②/③ 중 어디이고, 앞 순위가 남아있지 않나"를 먼저 점검.

### 7. Versioning

- 분기 1회 또는 NSM 도달/미달 시 갱신.

- - 주요 갱신: NSM 변경 / Phase 정의 변경 / Won't 변경 → Major CR 분류.

- - 가벼운 갱신: Trade-off 추가, 트렌드 매핑 보강 → Clarification.

- - 갱신 시 Changelog 1줄 (날짜 + 사유).

+ - 주요 갱신: NSM 변경 / Pillar 변경 / Won't 변경 → **Major CR** 분류.

+ - 가벼운 갱신: Trade-off 추가, 트렌드 매핑 보강 → **Clarification**.

+ - 갱신 사유는 커밋 메시지에 남긴다 — 문서 본문에 이력을 쌓지 않는다.

+ - 북극성이 바뀌면 그 아래 로드맵·계획 문서는 자동으로 최신이 아니다. 같은 갱신 단위에서

+ 재검토 대상으로 표시한다.

## Output Template

- `docs/NORTH_STAR.md`에 다음 구조로 저장. 본 skill 디렉토리의 `NORTH_STAR.template.md`를 복사해 채운다.

+ `docs/NORTH_STAR.md`에 저장. 본 skill 디렉토리의 `NORTH_STAR.template.md`를 복사해 채운다.

- 8 섹션:

+ 6 섹션 (번호는 템플릿에 맞춘다 — **§5 로드맵과 §8 이력은 비워 둔 자리다. 시간축은

+ TODO/로드맵 문서가, 이력은 버전 관리 이력이 소유한다**):

1. North Star Statement (1문장)

2. North Star Metric (1차 + 2차, metric-as-proxy 선언)

3. Pillars (전략 축) + 모듈 ↔ 축 매핑

4. Strategic Boundaries (Will / Won't / Trade-offs)

- 5. Phase Roadmap (장기 진화 단계)

6. Decision Heuristics (4-gate + 우선순위 순서)

7. Versioning & Review

- 8. Changelog

+ 시간축을 이 문서에 끌어들이는 순간 방향 문서와 일정 문서가 서로를 덮어쓴다. 로드맵은 아래

+ 워크플로가 **별도 문서**로 만든다.

+ ## Roadmap Workflow — 방향에서 백로그로

+ 방향이 정해진 뒤 "그래서 다음에 뭘 하나"를 답하는 5단계. 각 단계의 근거 방법론과 계산 예시는

+ [references/roadmap-method.md](references/roadmap-method.md).

+ 1. **READ** — 북극성 문서를 읽고 **NSM 1개 + 직접 움직일 수 있는 Inputs 3–5개**로 다시

+ 진술한다. 문서에 이미 있으면 그대로 들어 올리고, 산문 비전만 있으면 후보를 만들어

+ 확인받는다. 그 지표가 leading 인지, 가치 없이도 움직일 수 있는지를 먼저 점검한다.

+ 2. **ASSESS** — Input 별로 "지금 어디 / 목표 어디"를 실제 증거(기존 계획·감사 산출물·지표·

+ 코드 상태)로 적는다. 산출물은 **갭**이다. 측정되지 않은 Input 도 갭으로 센다.

+ 3. **PROPOSE** — 가장 큰 갭을 닫는 **방향**을 한두 문장으로 먼저 명명한다. 각 제안마다

+ ⓐ 한 줄 mini-PR(출시 후 누가 무슨 가치를 받는가) ⓑ 그것을 실현하는 구체 기능

+ 난립을 막는 정렬 게이트가 이 줄이다.

+ 4. **PRIORITIZE** — RICE `(Reach × Impact × Confidence) / Effort` 로 점수를 매긴다(데이터가

+ 얇으면 ICE). 숫자를 적어 순위를 감사 가능하게 만든 뒤 판단을 얹는다 — 의존성·전략적

+ table-stakes·북극성 적합도가 점수를 뒤집을 수 있고, 뒤집을 때는 **이유를 남긴다.**

+ 점수는 결정의 입력이지 자동조종이 아니다.

+ 5. **PERSIST** — 결과를 **Now / Next / Later** 로 묶어 지속되는 산출물에 쓴다: 기존 로드맵

+ SSOT 를 제자리에서 갱신하고(날짜 약속이 아니라 성과 테마로), 세션 시작 시 다시 읽히는

+ 앵커 한 줄을 메모리에 남기고, 진짜 아키텍처 결정이 있었으면 ADR 로 기록한다.

+ 로드맵이 둘이 되면 반드시 갈라진다 — 새 날짜 문서를 만들지 말고 살아 있는 문서를 고친다.

+ 그리고 보고한다: 방향 · 순위 표 · 기록한 파일 경로. **living document** 로 표시한다 —

+ 지표도 우선순위도 전략이 바뀌면 개정될 것을 전제한다.

## Integration with Workflow

- - **신규 프로젝트 시작 시**: `docs/NORTH_STAR.md` 존재 확인. 없으면 본 skill 호출 권유.

+ - **신규 프로젝트 시작 시**: 북극성 문서 존재 확인. 없으면 본 skill 호출 권유.

- **신규 task 진입 전**: 4-gate 체크. 1개 이상 게이트 fail 시 사용자에게 보고 후 결정 대기.

- **자동 hook 없음** — 의식적 결정을 강제하지 않음. 게이트는 가이드 도구.

## Anti-Patterns

- **NSM이 vanity metric** ("downloads", "stars") — 사용자 행동 측정 X

- **측정 불가 목표를 프록시 선언 없이 방치** — "좋은 제품"류 목표만 있고 최적화 대상이 없음

- **프록시가 양(量)만 측정** — 사후 품질 짝 없이는 굿하트 법칙으로 지표 자체가 게임됨

- **축에 매핑되지 않는 모듈 방치** — 매핑 실패는 scope creep 의 조기 신호인데 무시

- **기본 미완인데 advanced 착수** — 우선순위 순서 게이트 위반 (기본→완성도→차별화)

- **Won't가 비어있음** — scope creep 방어선 부재

- - **4-gate 검증 없이 "유용해 보이니까" 추가** — Decision Making 메타원칙 위반

- - **NORTH_STAR.md를 작성만 하고 한 번도 참조 안 함** — 죽은 문서. 분기 리뷰로 살림

+ - **4-gate 검증 없이 "유용해 보이니까" 추가** — 의사결정 원칙 위반

+ - **북극성 문서를 작성만 하고 한 번도 참조 안 함** — 죽은 문서. 분기 리뷰로 살림

+ 로드맵 단계 고유의 실패 6종(허수/후행/게임 가능한 지표 · RICE 허위정밀도 · 점수 자동추종 ·

+ 날짜형 로드맵 · bottom-up 아이디어 덤프 · 미영속화)은

+ [references/roadmap-method.md](references/roadmap-method.md) 의 Pitfalls 절이 소유한다.

+ ## References (progressive disclosure)

+ - [references/roadmap-method.md](references/roadmap-method.md) — 로드맵 5단계의 근거

+ 방법론(출처 URL 포함) · RICE 워크드 계산 예제와 override 로그 · Pitfalls 6종 ·

+ 자매 스킬과의 역할 분담.

## Examples

참고 사례 (도메인 종속 — 실운영 프로젝트 2종):

- 프로젝트 A (목표 추적 SaaS): NSM = WAGI (Weekly AI-Initiated Goal Items) ≥ 40% ·

Won't: 팀 협업 도구 / 모바일 우선 / 게이미피케이션 / 외부 통합 폭발 / CRDT ·

4-gate: Trend × Persona × MCP × Lean · 우선순위 순서(기본→완성도→차별화) 실운영.

- 프로젝트 B (투자 분석 서비스): 진짜 목표(사용자 투자 수익)가 외부·지연이라 직접 측정 불가 →

**프록시 선언** "추적되는 근거 기반 의사결정 수(양) + 사후 성과 양(+) 비율(품질)" ·

5 Pillars(각 정의/현재 위치/전방 목표/가설) + 전 모듈 ↔ 축 매핑 표 · 로드맵 항목의 축 매핑

정기 점검("새 축 불필요" 판정 기록).

본 skill은 그 패턴들을 도메인 비종속으로 일반화한 것.