@uzysjung/agent-harness 26.148.1 → 26.149.0

package/templates/skills/north-star/SKILL.md

@@ -32,32 +32,88 @@ SPEC/PRD가 "무엇을 어떻게"를 다루면, North Star는 **왜·어디로**
 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.
 
+## 세 가지 lifecycle — 섞이면 전부 망가진다
+
+이 스킬이 다루는 것들은 **수명이 다르다.** 하나의 지표 체계에 몰아넣으면 일회성 완료
+목표가 영구 지표 자리를 차지하고, 반대로 계속 지켜야 할 조건이 "완료"로 닫힌다.
+
+| | 무엇 | 수명 | 소유 개념 |
+|---|---|---|---|
+| **DIRECTION** | 계속 향하는 사용자 가치와 전략 방향 | 서비스가 존재하는 동안 | North Star · NSM · Inputs · Pillars · Boundaries |
+| **CHANGE** | 현재 상태를 바꾸는 **유한한** 작업 | Finish Line 을 통과하면 끝 | Product Initiative · Enabler Initiative · Finish Line |
+| **RUN** | 완성된 서비스를 유지하는 영역 | 운영하는 동안 계속 | SLO · Guardrail · Operational Health · Operational Work |
+
+세 단어를 혼동하지 않는다:
+
+> **North Star** = 계속 향하는 방향. 도착해서 끝나지 않는다.
+> **Finish Line** = 이 Initiative 를 언제 종료할지 정하는 완료 조건. 통과하면 종료된다.
+> **Guardrail** = 운영하는 동안 계속 지켜야 하는 조건. 달성이 아니라 유지다.
+
+```
+      DIRECTION                 CHANGE                    RUN
+    North Star            Product Initiative        SLO / Guardrail
+        │                        │                        │
+   NSM ─┴─ Inputs          Enabler Initiative      Operational Health
+        │                        │                        │
+     Pillars                Finish Line            Operational Work
+                                 │                        │
+                               Done         구조적 문제 발견 ─┘
+                                                ↓
+                                        Enabler Initiative
+```
+
+### Lifecycle 판정 규칙 — 목표·지표를 정의할 때 **가장 먼저**
+
+> **이 목표를 달성하면 더 이상 추적할 필요가 없는가?**
+
+| 답 | 분류 | 어디에 적는가 |
+|---|---|---|
+| **YES** — 달성하면 끝 | **Finite** | Initiative Target · Finish Line · Exit Criterion |
+| **NO** — 달성 후에도 계속 재고 유지해야 한다 | **Persistent** | NSM · Input · SLO · Guardrail |
+
+**Finite 와 Persistent 를 한 지표 체계에 섞지 않는다.** "테스트 커버리지 80% 달성"은
+Finite 이고 "커버리지 80% 이상 유지"는 Persistent 다 — 문장은 비슷한데 사는 곳이 다르다.
+
 ## When to Invoke
 
 | 트리거 | 행동 |
 |--------|------|
 | 신규 프로젝트 시작 | 북극성 문서 부재 시 작성 제안 |
-| Major CR / scope 확대 의심 | 4-gate 통과 여부 점검 |
+| Major CR / scope 확대 의심 | 게이트 통과 여부 점검 |
 | 분기 1회 정기 리뷰 | NSM 변경, Pillar 변경, Won't 변경 검토 |
-| 신규 기능 요청 진입 시 | 4-gate 통과 시만 우선순위 진입 |
-| "앞으로 어디로 가야 하나" | 아래 로드맵 워크플로 (방향 → 순위 → 영속화) |
+| 신규 기능 요청 진입 시 | 게이트 통과 시만 우선순위 진입 |
+| "앞으로 어디로 가야 하나" | 아래 로드맵 워크플로 (분류 → 방향 → 순위 → 영속화) |
 
 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 작성
+# DIRECTION — 계속 향하는 것
+
+### 1. North Star Statement
 
 한 문장으로 프로젝트의 종착점을 표현. 5년 뒤 이 프로젝트가 무엇이 되어 있어야 하는가.
 
 **좋은 예**: 도메인 명사 + 사용자 + 측정 가능한 결과.
 **나쁜 예**: "최고의 X" / "사용자 만족" — 측정 불가.
 
-### 2. North Star Metric (NSM) 정의 — metric-as-proxy
+### 2. North Star Metric (NSM) — metric-as-proxy
+
+NSM 은 **하나**이고, 그것은 북극성이 실현되고 있는지를 대표하는 **지속 지표**다.
+일회성 완료 목표는 NSM 이 될 수 없다(위 lifecycle 판정을 먼저 통과시킨다).
+
+**Definition 과 Current Target 을 분리해서 적는다.**
 
-1차 지표 1개 + 2차 보조 지표 2-4개. 모두 단일 사용자 환경에서 자가 수집 가능해야 한다.
+| | 무엇 | 언제 바뀌는가 |
+|---|---|---|
+| **NSM Definition** | 무엇을 어떻게 재는가 | 전략이 바뀔 때만. **Major CR** |
+| **Current Target** | 지금 겨냥하는 수치와 시점 | 도달하거나 근거가 바뀌면. 정기 리뷰 사안 |
+
+**Target 에 도달했다는 이유로 NSM 자체를 바꾸지 않는다.** 그때 하는 일은 다음 Target 을
+정하는 것이다. Definition 이 바뀐다는 것은 "이제 다른 것을 재기로 했다"는 뜻이고, 그건
+방향 변경이라 별도 결정을 받는다.
 
 **진짜 목표가 직접 측정 불가하면 프록시를 선언한다.** 많은 프로젝트의 실제 목표(사용자의
 투자 수익, 팀의 생산성, 학습 성과 등)는 외부적이거나 지연되어 직접 측정할 수 없다. 그때
@@ -65,21 +121,28 @@ findings and points forward.
 
 1. **프록시 지표를 명시적으로 선언** — "진짜 목표 X 는 직접 측정 불가하므로 Y 를 프록시로
    최적화한다"를 문서에 그대로 적는다. 왜 이 프록시인지 1줄 근거 필수.
-2. **양(1차) + 사후 품질(2차) 짝** — 프록시는 행동의 양(추적되는 의사결정 수 등)과 그 행동의
+2. **양(1차) + 사후 품질(짝)** — 프록시는 행동의 양(추적되는 의사결정 수 등)과 그 행동의
    사후 품질(성과 추적이 양(+)인 비율 등)을 짝으로 잡는다. 양만 재면 굿하트 법칙으로 프록시
    자체가 게임된다.
-3. **기능 평가 기준으로 사용** — "이 기능이 프록시 지표 둘 중 하나를 올리는가?" NO 면 북극성
-   이탈 신호.
 
 NSM 결정 기준:
 
 - **Lagging (결과) vs Leading (원인) — Leading 권장.** 이미 끝난 결과로는 조타할 수 없다.
 - **단일 행동만 측정 (composite 금지).**
-- **목표값 명시** ("≥ 40% by 2026").
+- **Current Target 명시** ("≥ 40% by 2026").
 - **게임 가능성 점검** — 가치를 전달하지 않고도 직접 올릴 수 있으면 북극성이 아니다.
   그런 지표를 발견하면 조용히 그것을 향해 계획하지 말고 먼저 그 사실을 알린다.
 
-### 3. Pillars (전략 축) + 모듈 ↔ 축 매핑
+### 3. Inputs — 직접 움직일 수 있는 레버 3–5개
+
+NSM 은 **결과**이고 Inputs 는 그것을 움직이는 **원인**이다. 둘의 역할이 다르므로 목록을
+따로 유지한다 — Input 은 "NSM 을 보조하는 작은 지표"가 아니라, 팀이 실제로 손댈 수 있는
+지속 지표이고 계획은 여기에 붙는다.
+
+각 Input 마다: **정의 · 현재 값 · 목표 방향 · NSM 을 움직인다고 믿는 이유 1줄.**
+측정되지 않는 Input 은 "미측정"이라고 적는다 — 빈칸으로 두면 없는 것과 구분되지 않는다.
+
+### 4. Pillars (전략 축) + 모듈 ↔ 축 매핑
 
 North Star 로 가는 길을 3-5개 **전략 축**으로 분해한다. 각 축은 4요소로 정의:
 
@@ -90,13 +153,9 @@ North Star 로 가는 길을 3-5개 **전략 축**으로 분해한다. 각 축
 
 그리고 **모듈 ↔ 축 매핑 표**를 유지한다: 모든 모듈은 최소 1개 축에 속한다 (플랫폼 공통
 인프라는 "공통"으로 명시). **어떤 신규 모듈이 어느 축에도 매핑되지 않으면 착수 전에 북극성
-정렬을 재검토한다** — 매핑 실패 = scope creep 의 조기 신호. 로드맵 항목도 정기 리뷰 때 축에
-매핑해 "새 축·방향 변경이 필요한가"를 점검한다.
+정렬을 재검토한다** — 매핑 실패 = scope creep 의 조기 신호.
 
-축은 아래 로드맵 워크플로가 말하는 *Inputs* 와 같은 것이다 — 북극성이 목적지라면 축은 직접
-움직일 수 있는 레버다. 두 이름은 같은 분해를 가리킨다.
-
-### 4. Will / Won't / Trade-offs
+### 5. Will / Won't / Trade-offs
 
 - **Will**: 집중 영역 4-6개. 동사로 시작 ("개인 사용 깊이 우선", "AI 친화 1급 시민").
 - **Won't**: 의도적 비-방향 **5-8개**. "X는 안 한다" 명시. 가장 중요한 섹션 — scope creep의
@@ -104,81 +163,161 @@ North Star 로 가는 길을 3-5개 **전략 축**으로 분해한다. 각 축
 - **Trade-offs**: "**선택 → 포기한 것 → 근거**" 3열 표. 의식적 결정의 추적 기록이며, 같은
   논쟁을 반년 뒤에 처음부터 다시 하지 않게 하는 유일한 장치다.
 
-### 5. 4-Gate Decision Heuristic — "할 것인가"
+### 6. Versioning
+
+- 분기 1회 또는 NSM Current Target 도달/미달 시 갱신.
+- **Major CR**: NSM Definition 변경 / Pillar 변경 / Won't 변경.
+- **Clarification**: Current Target 갱신, Trade-off 추가, 매핑 보강.
+- 갱신 사유는 커밋 메시지에 남긴다 — 문서 본문에 이력을 쌓지 않는다.
+- 북극성이 바뀌면 그 아래 로드맵·계획 문서는 자동으로 최신이 아니다. 같은 갱신 단위에서
+  재검토 대상으로 표시한다.
+
+---
+
+# CHANGE — 유한한 작업
+
+### Work Type — 실행 작업은 셋 중 하나다
+
+| Work Type | 의미 | 게이트 | 순위 결정 |
+|---|---|---|---|
+| **Product Initiative** | 사용자 가치·제품 경험을 바꾸는 유한한 작업 | 아래 4-gate | RICE/ICE + 판단 |
+| **Enabler Initiative** | 기술·운영 capability 를 바꾸는 유한한 작업 | 아래 4-gate (Value 게이트는 간접 경로 허용) | RICE/ICE + 판단 |
+| **Operational Work** | 현재 서비스를 유지하는 반복적·사건 기반 업무 | **게이트를 기계적으로 적용하지 않는다** | severity·위험·기한 |
 
-신규 요청·제안이 들어왔을 때 다음 4개 게이트를 **모두** 통과해야 우선순위 진입:
+**Operational Work 를 전부 Enabler Initiative 로 만들지 않는다.** 백업 검증, 인시던트 대응,
+정기 점검은 그냥 운영이다. 그 운영에서 **구조적 문제**가 반복해 드러날 때에만 별도의
+Enabler Initiative 로 승격하고, 그때 Finish Line 을 붙인다.
+
+### 4-Gate Decision Heuristic — "할 것인가"
+
+신규 Initiative 는 4개 게이트를 **모두** 통과해야 우선순위에 진입한다.
 
 | Gate | 질문 | 통과 기준 |
 |------|------|----------|
 | **Trend** | 프로젝트의 핵심 트렌드/원칙 중 1개 이상에 매핑되는가? | YES |
-| **Persona** | Primary persona에게 직접 가치를 주는가? Anti-persona 위주는 거절 | YES |
-| **Capability** | 현재 시스템이 이 기능을 동등하게 노출 가능한가? (UI 한정 기능은 -1) | YES |
-| **Lean** | 선언된 Will 범위 내에 있는가? 외부면 Open Question으로 적재 후 분기 1회 재평가 | YES |
+| **Value** | 사용자 가치에 닿는 경로가 있는가? | 아래 두 형태 중 하나 |
+| **Capability** | 현재 시스템이 이것을 동등하게 노출 가능한가? (UI 한정 기능은 -1) | YES |
+| **Lean** | 선언된 Will 범위 내에 있는가? 외부면 Open Question 으로 적재 후 분기 1회 재평가 | YES |
+
+**Value 게이트의 두 형태** — 이 갈래가 Enabler 를 억지로 사용자 지표에 묶지 않게 한다:
+
+- **직접(Product)** — Primary persona 에게 직접 가치를 준다. Anti-persona 위주면 거절.
+- **간접(Enabler)** — 자기가 **막아 주는 Guardrail/SLO** 또는 **가능하게 하는 Initiative·
+  Pillar capability** 를 이름으로 지목한다. 지목된 그것이 사용자 가치를 나른다.
+  Security · Reliability · Observability · Migration 이 여기 산다. **NSM 을 직접 움직이지
+  않아도 정당한 Initiative 다** — 다만 "무엇을 위해서인지"를 이름으로 못 대면 탈락이다.
 
 게이트 명칭은 프로젝트마다 customize 가능하나 **4개 ALL True** 원칙은 유지.
 
-### 6. 우선순위 순서 게이트 — "언제 할 것인가"
+### Finish Line — 유한함을 증명하는 것
 
-(검증 체크포인트 유형 분류와 무관 — 이것은 작업 **순서** 규칙이다.)
-4-gate 는 "할 것인가"를 거른다. 통과한 것들 사이의 **순서**는 별도 규칙이다 — 무엇을 먼저
-할지 모호하면 이 순서로 판정한다:
+모든 Initiative 는 **Exit Criterion** 을 갖는다. 없으면 그건 Initiative 가 아니라 방향이거나
+운영이다. 좋은 Finish Line 은 관측 가능하고, 통과 여부를 두고 논쟁이 안 생긴다.
 
-1. **기본 필수 기능** — 없으면 제품이 성립 안 되는 기본기 (예: 표준 로그인). "기본"이 빠진 채
-   화려함부터 쌓지 않는다.
-2. **기능 완성도** — 이미 shipped 된 기능이 사용자 관점 end-to-end 로 진짜 완결인가.
-   **단순 존재 ≠ 완결** (버튼이 동작하나, 링크가 목적지까지 가나, 빈/에러 상태가 처리되나).
-   UI 트랙이면 벤치마크 동등성 검토 루프와 동일 기준.
-3. **차별화 깊이** — 핵심 경쟁력의 advanced 구현. **research/ADR 선행 필수** — advanced 부터
-   코드로 뛰어들지 않는다.
+**완료 시 전환 규칙** — 여기가 빠지면 완료된 목표가 영구 KPI 로 남아 계속 감시 비용을 문다:
 
-**상위 순위에 미완이 있으면 하위로 건너뛰지 않는다** (긴급 hotfix·사용자 명시 지시 예외).
-Plan/Define 단계에서 "이 작업이 ①/②/③ 중 어디이고, 앞 순위가 남아있지 않나"를 먼저 점검.
+1. **Finish Line 은 종료한다.** 이미 통과한 완료 조건을 지속 KPI 처럼 계속 추적하지 않는다.
+2. **Initiative Metric 은 자동으로 Persistent Metric 이 되지 않는다.** 승격은 **결정**이지
+   기본값이 아니다.
+3. **계속 유지해야 하는 성질만** 명시적으로 넘긴다 — 사용자 가치의 지속 개선이면
+   **NSM/Input** 으로, 운영 중 계속 지켜야 하는 조건이면 **SLO/Guardrail** 로. 넘길 때
+   "무엇을 왜 넘기는가"를 한 줄 남긴다.
+4. 넘길 것이 없으면 **아무것도 안 남기고 닫는다.** 그게 정상이다.
 
-### 7. Versioning
+### Initiative Sequencing Heuristic — 유한한 작업의 순서
 
-- 분기 1회 또는 NSM 도달/미달 시 갱신.
-- 주요 갱신: NSM 변경 / Pillar 변경 / Won't 변경 → **Major CR** 분류.
-- 가벼운 갱신: Trade-off 추가, 트렌드 매핑 보강 → **Clarification**.
-- 갱신 사유는 커밋 메시지에 남긴다 — 문서 본문에 이력을 쌓지 않는다.
-- 북극성이 바뀌면 그 아래 로드맵·계획 문서는 자동으로 최신이 아니다. 같은 갱신 단위에서
-  재검토 대상으로 표시한다.
+**적용 범위: 신규 서비스 구축 · 신규 Feature Initiative · 아직 Finish Line 을 통과하지 못한
+기능.** 운영 중인 제품 backlog 전체의 절대 우선순위 규칙으로 쓰지 않는다.
+
+1. **Foundation (기본 필수 기능)** — 없으면 제품이 성립 안 되는 기본기 (예: 표준 로그인).
+   "기본"이 빠진 채 화려함부터 쌓지 않는다.
+2. **End-to-End Completeness (기능 완성도)** — 이미 shipped 된 기능이 사용자 관점
+   end-to-end 로 진짜 완결인가. **단순 존재 ≠ 완결** (버튼이 동작하나, 링크가 목적지까지
+   가나, 빈/에러 상태가 처리되나).
+3. **Differentiation (차별화 깊이)** — 핵심 경쟁력의 advanced 구현. **research/ADR 선행
+   필수** — advanced 부터 코드로 뛰어들지 않는다.
+
+**한 Initiative 안에서 상위 단계에 미완이 있으면 하위로 건너뛰지 않는다** (긴급 hotfix·
+사용자 명시 지시 예외).
+
+### 우선순위 — RICE/ICE 를 쓰는 자리와 안 쓰는 자리
+
+**RICE/ICE 는 모든 작업을 한 Pool 에서 비교하는 기준이 아니다.** 아래는 optional feature 와
+점수로 경쟁시키지 않는다 — 경쟁시키는 순간 "점수가 낮아서 안 했다"가 사고 보고서에 남는다:
+
+> Security violation · Data integrity risk · Critical incident · SLO/Guardrail breach ·
+> Required migration · Release blocker · Regulatory / Mandatory requirement
+
+이런 작업은 **severity · 위험 · 기한 · 의존성 · 저장소 정책**으로 먼저 판정한다.
+
+RICE/ICE 는 **비교 가능한 discretionary Initiative 후보끼리** 순서를 정할 때 쓴다. 그때도
+점수는 **의사결정의 입력이지 자동 결정 기준이 아니다** — 뒤집을 때는 이유를 남긴다.
+
+---
+
+# RUN — 운영하는 동안 지켜지는 것
+
+이 스킬은 **RUN 의 존재와 경계만 정의한다.** SLO 체계·인시던트 절차·런북의 설계는 여기서
+하지 않고, 저장소의 운영 SSOT 가 소유한다. 북극성 문서는 그것을 **가리킨다.**
+
+- **SLO / Guardrail** — 운영하는 동안 계속 지켜야 하는 조건. 달성이 아니라 유지다.
+  Finite 로 적혀 있으면 잘못 분류된 것이다.
+- **Operational Health** — 그 조건이 지금 지켜지고 있는지의 현재 상태.
+- **Operational Work** — 유지를 위한 반복적·사건 기반 업무. Initiative 가 아니다.
+
+운영에서 **같은 문제가 반복**되면 그때가 Enabler Initiative 를 만들 시점이다 — 반복 업무를
+없애는 구조 변경에 Finish Line 을 붙여 유한한 작업으로 만든다.
+
+---
 
 ## Output Template
 
 `docs/NORTH_STAR.md`에 저장. 본 skill 디렉토리의 `NORTH_STAR.template.md`를 복사해 채운다.
 
-6 섹션 (번호는 템플릿에 맞춘다 — **§5 로드맵과 §8 이력은 비워 둔 자리다. 시간축은
-TODO/로드맵 문서가, 이력은 버전 관리 이력이 소유한다**):
+북극성 문서는 **DIRECTION 의 SSOT** 다. 7 섹션:
+
+1. Product North Star
+2. North Star Metric (Definition + Current Target)
+3. Inputs
+4. Strategic Pillars (+ 모듈 ↔ 축 매핑)
+5. Strategic Boundaries (Will / Won't / Trade-offs)
+6. Alignment Rules (게이트 · Work Type · lifecycle 판정)
+7. Review & Versioning
+
+**북극성 문서가 소유하지 않는 것** — 필요하면 해당 SSOT 를 가리킨다:
 
-1. North Star Statement (1문장)
-2. North Star Metric (1차 + 2차, metric-as-proxy 선언)
-3. Pillars (전략 축) + 모듈 ↔ 축 매핑
-4. Strategic Boundaries (Will / Won't / Trade-offs)
-6. Decision Heuristics (4-gate + 우선순위 순서)
-7. Versioning & Review
+| 소유하지 않는 것 | 어디가 소유하나 |
+|---|---|
+| Initiative Finish Line · Initiative KPI · Release 완료 조건 · Feature checklist | 계획 문서 (`docs/plans/` 등) |
+| Now / Next / Later 상세 backlog | 로드맵 SSOT |
+| 상세 SLO · Runbook · Incident procedure | 저장소의 운영 SSOT |
+| 갱신 이력 | 버전 관리 이력 |
 
-시간축을 이 문서에 끌어들이는 순간 방향 문서와 일정 문서가 서로를 덮어쓴다. 로드맵은 아래
-워크플로가 **별도 문서**로 만든다.
+시간축을 이 문서에 끌어들이는 순간 방향 문서와 일정 문서가 서로를 덮어쓴다.
 
 ## Roadmap Workflow — 방향에서 백로그로
 
-방향이 정해진 뒤 "그래서 다음에 뭘 하나"를 답하는 5단계. 각 단계의 근거 방법론과 계산 예시는
+방향이 정해진 뒤 "그래서 다음에 뭘 하나"를 답하는 6단계. 각 단계의 근거 방법론과 계산 예시는
 [references/roadmap-method.md](references/roadmap-method.md).
 
 1. **READ** — 북극성 문서를 읽고 **NSM 1개 + 직접 움직일 수 있는 Inputs 3–5개**로 다시
    진술한다. 문서에 이미 있으면 그대로 들어 올리고, 산문 비전만 있으면 후보를 만들어
    확인받는다. 그 지표가 leading 인지, 가치 없이도 움직일 수 있는지를 먼저 점검한다.
-2. **ASSESS** — Input 별로 "지금 어디 / 목표 어디"를 실제 증거(기존 계획·감사 산출물·지표·
+2. **CLASSIFY** — 손에 든 항목마다 두 축을 먼저 정한다: **Work Type**(Product / Enabler /
+   Operational)과 **lifecycle**(Finite → Finish Line / Persistent → NSM·Input·SLO·Guardrail).
+   이 단계를 건너뛰면 뒤의 모든 단계가 잘못된 Pool 에서 돌아간다.
+3. **ASSESS** — Input 별로 "지금 어디 / 목표 어디"를 실제 증거(기존 계획·감사 산출물·지표·
    코드 상태)로 적는다. 산출물은 **갭**이다. 측정되지 않은 Input 도 갭으로 센다.
-3. **PROPOSE** — 가장 큰 갭을 닫는 **방향**을 한두 문장으로 먼저 명명한다. 각 제안마다
+4. **PROPOSE** — 가장 큰 갭을 닫는 **방향**을 한두 문장으로 먼저 명명한다. 각 제안마다
    ⓐ 한 줄 mini-PR(출시 후 누가 무슨 가치를 받는가) ⓑ 그것을 실현하는 구체 기능
-   ⓒ **부모** — 어느 Input/축을 지지하는가. **부모가 없으면 잘라낸다.** bottom-up 기능
-   난립을 막는 정렬 게이트가 이 줄이다.
-4. **PRIORITIZE** — RICE `(Reach × Impact × Confidence) / Effort` 로 점수를 매긴다(데이터가
-   얇으면 ICE). 숫자를 적어 순위를 감사 가능하게 만든 뒤 판단을 얹는다 — 의존성·전략적
-   table-stakes·북극성 적합도가 점수를 뒤집을 수 있고, 뒤집을 때는 **이유를 남긴다.**
-   점수는 결정의 입력이지 자동조종이 아니다.
-5. **PERSIST** — 결과를 **Now / Next / Later** 로 묶어 지속되는 산출물에 쓴다: 기존 로드맵
+   ⓒ **부모** — 어느 Input·Pillar·Guardrail·Exit Criterion 을 지지하는가. **부모가 없으면
+   잘라낸다.** 부모가 NSM Input 하나로 제한되지 않는다는 것이 Enabler 를 살리는 지점이다.
+5. **PRIORITIZE** — 먼저 **mandatory · incident · guardrail breach** 를 골라낸다(위 규칙).
+   남은 discretionary 후보끼리 RICE `(Reach × Impact × Confidence) / Effort` 로 점수를
+   매긴다(데이터가 얇으면 ICE). 숫자를 적어 순위를 감사 가능하게 만든 뒤 판단을 얹는다 —
+   의존성·전략적 table-stakes·북극성 적합도가 점수를 뒤집을 수 있고, 뒤집을 때는 **이유를
+   남긴다.**
+6. **PERSIST** — 결과를 **Now / Next / Later** 로 묶어 지속되는 산출물에 쓴다: 기존 로드맵
    SSOT 를 제자리에서 갱신하고(날짜 약속이 아니라 성과 테마로), 세션 시작 시 다시 읽히는
    앵커 한 줄을 메모리에 남기고, 진짜 아키텍처 결정이 있었으면 ADR 로 기록한다.
    로드맵이 둘이 되면 반드시 갈라진다 — 새 날짜 문서를 만들지 말고 살아 있는 문서를 고친다.
@@ -189,18 +328,35 @@ TODO/로드맵 문서가, 이력은 버전 관리 이력이 소유한다**):
 ## Integration with Workflow
 
 - **신규 프로젝트 시작 시**: 북극성 문서 존재 확인. 없으면 본 skill 호출 권유.
-- **신규 task 진입 전**: 4-gate 체크. 1개 이상 게이트 fail 시 사용자에게 보고 후 결정 대기.
+- **신규 task 진입 전**: Work Type 분류 → Initiative 면 4-gate 체크. 1개 이상 게이트 fail 시
+  사용자에게 보고 후 결정 대기. Operational Work 는 게이트 대상이 아니다.
 - **자동 hook 없음** — 의식적 결정을 강제하지 않음. 게이트는 가이드 도구.
 
 ## Anti-Patterns
 
+lifecycle 을 섞어서 생기는 것들:
+
+- **Initiative-as-NSM** — 일회성 완료 목표를 NSM 으로 정의. 달성하는 순간 북극성이 사라진다.
+- **Temporary North Star** — Current Target 에 도달했다는 이유로 NSM Definition 을 교체.
+  할 일은 다음 Target 을 정하는 것이지 재는 대상을 바꾸는 것이 아니다.
+- **Enabler-forced-into-NSM** — Security/Reliability/Observability/Migration 을 억지로 사용자
+  지표에 연결. 연결이 안 되면 그 Enabler 가 조용히 탈락한다.
+- **Operation-as-Enabler-Initiative** — 반복 운영 업무를 전부 Initiative 로 만들어 끝나지 않는
+  Finish Line 을 양산.
+- **Permanent Finish Line** — 완료된 Initiative 의 완료 조건을 지속 KPI 로 유지.
+- **SLO-vs-Feature RICE** — mandatory/guardrail/incident 를 optional feature 와 같은 점수
+  Pool 에서 경쟁.
+- **Feature Sequence Everywhere** — `Foundation → E2E Completeness → Differentiation` 을
+  운영 중인 backlog 전체의 절대 규칙으로 사용.
+
+방향 자체가 부실해서 생기는 것들:
+
 - **NSM이 vanity metric** ("downloads", "stars") — 사용자 행동 측정 X
 - **측정 불가 목표를 프록시 선언 없이 방치** — "좋은 제품"류 목표만 있고 최적화 대상이 없음
 - **프록시가 양(量)만 측정** — 사후 품질 짝 없이는 굿하트 법칙으로 지표 자체가 게임됨
 - **축에 매핑되지 않는 모듈 방치** — 매핑 실패는 scope creep 의 조기 신호인데 무시
-- **기본 미완인데 advanced 착수** — 우선순위 순서 게이트 위반 (기본→완성도→차별화)
 - **Won't가 비어있음** — scope creep 방어선 부재
-- **4-gate 검증 없이 "유용해 보이니까" 추가** — 의사결정 원칙 위반
+- **게이트 검증 없이 "유용해 보이니까" 추가** — 의사결정 원칙 위반
 - **북극성 문서를 작성만 하고 한 번도 참조 안 함** — 죽은 문서. 분기 리뷰로 살림
 
 로드맵 단계 고유의 실패 6종(허수/후행/게임 가능한 지표 · RICE 허위정밀도 · 점수 자동추종 ·
@@ -209,20 +365,20 @@ TODO/로드맵 문서가, 이력은 버전 관리 이력이 소유한다**):
 
 ## References (progressive disclosure)
 
-- [references/roadmap-method.md](references/roadmap-method.md) — 로드맵 5단계의 근거
-  방법론(출처 URL 포함) · RICE 워크드 계산 예제와 override 로그 · Pitfalls 6종 ·
-  자매 스킬과의 역할 분담.
+- [references/roadmap-method.md](references/roadmap-method.md) — 로드맵 6단계의 근거
+  방법론(출처 URL 포함) · CLASSIFY 와 부모 계보 예시 · 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 · 우선순위 순서(기본→완성도→차별화) 실운영.
+- 프로젝트 A (목표 추적 SaaS): NSM = WAGI (Weekly AI-Initiated Goal Items), Current Target
+  ≥ 40% · Won't: 팀 협업 도구 / 모바일 우선 / 게이미피케이션 / 외부 통합 폭발 / CRDT ·
+  4-gate: Trend × Value × MCP × Lean · sequencing heuristic 을 신규 기능 Initiative 에 한정 적용.
 - 프로젝트 B (투자 분석 서비스): 진짜 목표(사용자 투자 수익)가 외부·지연이라 직접 측정 불가 →
   **프록시 선언** "추적되는 근거 기반 의사결정 수(양) + 사후 성과 양(+) 비율(품질)" ·
-  5 Pillars(각 정의/현재 위치/전방 목표/가설) + 전 모듈 ↔ 축 매핑 표 · 로드맵 항목의 축 매핑
-  정기 점검("새 축 불필요" 판정 기록).
+  5 Pillars(각 정의/현재 위치/전방 목표/가설) + 전 모듈 ↔ 축 매핑 표 · 스키마 마이그레이션은
+  Enabler Initiative 로, 부모는 Pillar capability 로 기록(사용자 지표에 억지로 붙이지 않음).
 
 본 skill은 그 패턴들을 도메인 비종속으로 일반화한 것.

package/templates/skills/north-star/references/roadmap-method.md

@@ -1,12 +1,14 @@
 # Roadmap method — 근거 · 워크드 예제 · 함정
 
-SKILL.md 의 5단계 워크플로가 왜 그 순서인지, 실제 계산이 어떻게 생겼는지, 그리고 그 단계에서
-반복되는 실패가 무엇인지. 로드맵을 실제로 만들 때 읽는다.
+SKILL.md 의 6단계 워크플로(READ → CLASSIFY → ASSESS → PROPOSE → PRIORITIZE → PERSIST)가 왜
+그 순서인지, 실제 계산이 어떻게 생겼는지, 그리고 그 단계에서 반복되는 실패가 무엇인지.
+로드맵을 실제로 만들 때 읽는다.
 
 ## Why these steps (the frameworks underneath)
 
 The workflow chains four established product-strategy methods so the output is defensible rather
-than vibes. Reason with each — don't just cite it:
+than vibes — and puts a classification step in front of them, because each method only works inside
+one lifecycle. Reason with each — don't just cite it:
 
 - **North Star Framework** (Amplitude) — a single North Star Metric is the destination; 3–5
   directly-influenceable *Inputs* are the levers. You assess "current vs goal" against the inputs
@@ -28,13 +30,55 @@ than vibes. Reason with each — don't just cite it:
 - **Theme-based Now / Next / Later** — organize the roadmap by outcome themes and horizons, not
   dated feature promises, so it ages gracefully and the why/what stays above the how/when.
 
+## CLASSIFY — 왜 이 단계가 맨 앞에 붙었나
+
+분류 없이 시작하면 뒤의 네 방법론이 전부 **엉뚱한 Pool 에서** 돌아간다. RICE 는 서로 비교
+가능한 후보끼리에서만 뜻이 있고, OKR lineage 는 부모가 존재할 때만 성립하며, Now/Next/Later
+는 끝나는 일과 계속되는 일을 같은 칸에 넣으면 곧바로 썩는다.
+
+항목마다 두 축을 먼저 정한다.
+
+**① Work Type**
+
+```
+사용자 workflow 개선          → Product Initiative
+Schema migration              → Enabler Initiative
+SLO 모니터링·정기 백업 검증    → Operational Work
+```
+
+**② Lifecycle** — "달성하면 추적을 그만두는가?"
+
+```
+YES → Finite       → Finish Line / Exit Criterion
+NO  → Persistent   → NSM · Input · SLO · Guardrail
+```
+
+두 축은 독립이다. Enabler 이면서 Finite 인 것(마이그레이션)도, Operational 이면서
+Persistent 인 것(백업 성공률 Guardrail)도 정상이다.
+
+### Parent lineage — 부모는 NSM Input 하나가 아니다
+
+OKR lineage 의 요구는 "부모가 있어야 한다"이지 "부모가 사용자 지표여야 한다"가 아니다.
+부모 자리에 올 수 있는 것:
+
+```
+Critical user flow 개선     → Parent: NSM Input
+Observability 구축          → Parent: Reliability Guardrail
+Schema migration            → Parent: Strategic capability / 의존성
+Release 완성 작업            → Parent: Initiative Exit Criterion
+정기 백업 검증               → Operational basis: Run policy / Guardrail (Initiative 아님)
+```
+
+부모 종류를 하나로 좁히면 Enabler 가 억지로 사용자 지표에 매달리거나 조용히 탈락한다 —
+그 둘 다 정렬이 아니라 정렬의 실패다.
+
 ## Worked example
 
 **Input (user):** `NORTH_STAR 보고 나아갈 방향 + 기능 제안 → 계획 세워서 메모리에 기록`
 
 **Output (abridged):**
 
-> **1. Metric + Inputs** (from the north-star doc)
+> **1. READ — Metric + Inputs** (from the north-star doc)
 > North Star Metric: GitHub stars as the adoption signal that the tool delivers real value.
 > Inputs: (a) context cost per install (resident + fired tokens), (b) Promise = Implementation
 > (advertised assets 100% work), (c) first-run install success, (d) justified-asset ratio,
@@ -42,23 +86,26 @@ than vibes. Reason with each — don't just cite it:
 > *Leading-indicator check:* stars alone are gameable, so we plan against inputs (a)–(e), the value
 > the stars reward — not the raw count.
 >
-> **2. Gap** — (a) fired-body tokens unmeasured · (b) closed after the false-ship work · (c)
+> **2. CLASSIFY** — P1·P3 은 Enabler Initiative(Finite), P2 는 Product Initiative(Finite).
+> 어느 것도 NSM 후보가 아니다 — 셋 다 끝나는 일이다.
+>
+> **3. ASSESS — Gap** — (a) fired-body tokens unmeasured · (b) closed after the false-ship work · (c)
 > install matrix green but no post-publish telemetry · (e) plugins don't yet reach non-default CLIs.
 >
-> **3. Direction** — "Make the *first 60 seconds* prove the value before asking for a star."
+> **4. PROPOSE — Direction** — "Make the *first 60 seconds* prove the value before asking for a star."
 > Proposals: P1 first-run telemetry (parent: Input c); P2 plugin→other-CLI equivalence
 > (parent: Input e); P3 public, continuously-tested compat+security matrix artifact (parent: Input d).
 > Each carries a one-line mini-PR.
 >
-> **4. RICE** — P1 (R 5·I 2·C .8·E 2 = 4.0) · P3 (R 4·I 3·C .7·E 3 = 2.8) · P2 (R 2·I 3·C .6·E 5 = 0.7).
+> **5. PRIORITIZE — RICE** (mandatory·incident 없음을 먼저 확인) — P1 (R 5·I 2·C .8·E 2 = 4.0) · P3 (R 4·I 3·C .7·E 3 = 2.8) · P2 (R 2·I 3·C .6·E 5 = 0.7).
 > *Override:* P3 promoted above its score — it's the repo's defensibility wedge (table-stakes for
 > a 0-star cold start). Logged here and in the ADR.
 >
-> **5. Persisted** — updated the roadmap SSOT under `docs/plans/` in place (Now: P1 · Next: P3 ·
+> **6. PERSIST** — updated the roadmap SSOT under `docs/plans/` in place (Now: P1 · Next: P3 ·
 > Later: P2), added the anchor line to the memory file, opened the next free ADR
 > (`docs/decisions/ADR-0NN-p3-override.md`) for the strategic override.
 
-읽는 법: 4단계의 override 한 줄이 이 예제의 핵심이다. P3 는 점수가 2위인데 1위로 올라갔고,
+읽는 법: PRIORITIZE 의 override 한 줄이 이 예제의 핵심이다. P3 는 점수가 2위인데 1위로 올라갔고,
 **그 사실과 이유가 산출물에 남아 있다.** 점수만 남기고 판단을 감추면 다음 사람이 순위를
 근거로 착각한다.
 
@@ -70,10 +117,13 @@ than vibes. Reason with each — don't just cite it:
   exists to discount shaky estimates; skipping it yields authoritative-looking wrong rankings.
 - **Score on autopilot** — shipping the top-RICE item while ignoring dependencies or strategic fit.
 - **Dated feature-list roadmap** — timeline promises rot; outcome themes in Now/Next/Later age better.
-- **Bottom-up idea dump** — proposals that don't ladder up to an Input. The alignment gate (step 3)
-  is the cure.
+- **Bottom-up idea dump** — proposals that don't ladder up to *any* parent (Input · Pillar
+  capability · Guardrail · Exit Criterion). The alignment gate in PROPOSE is the cure — but it
+  checks for a named parent, not specifically an NSM Input.
 - **Plan that doesn't persist** — a great assessment that lives only in the chat and is lost at
-  `/compact`. The artifact in step 5 is the whole point.
+  `/compact`. The artifact in the final step is the whole point.
+- **Finite 와 Persistent 를 한 표에** — 끝나는 목표와 계속 지킬 조건이 같은 지표 목록에 있으면,
+  완료된 것이 영구 감시 비용을 물거나 계속 지킬 것이 "완료"로 닫힌다. CLASSIFY 가 그 방어선이다.
 
 ## Cross-references (siblings — do not duplicate)