metric-tracker

name	metric-tracker
version	1
description	지표 설계·추적·리뷰 엔진. OKR·KPI·핵심지표를 구조화하고 주기적 리뷰를 프로토콜화. Plan-Do-Check-Act 사이클의 Check 담당. 트리거: 메트릭트래커, metric tracker, 지표설계, 지표추적, KPI, OKR, 핵심지표, 대시보드, 주간리뷰, 월간리뷰, 지표분석, 성과측정, 지표 설계해줘, KPI 만들어줘, 리뷰해줘, track metrics, design KPIs. NOT: 재무모델링(→financial-model), 조직 OKR설계 전반(→management-skill M3), 사업전략(→biz-skill), 리서치(→research-frame).

Metric Tracker — 지표 설계·추적 엔진

planning-skill이 "무엇을 할 것인가", ceo-pipeline이 "어떤 순서로 할 것인가"라면, 이 스킬은 "한 것이 제대로 되고 있는가"를 측정하고 판단하는 것. 측정하지 않으면 관리할 수 없고, 잘못 측정하면 잘못된 방향으로 달린다(Drucker, Goodhart).

Skill Boundaries

• 하는 것 — 지표 설계·추적·리뷰 엔진.
• 안 하는 것 — 재무모델링(→financial-model), 조직 OKR설계 전반(→management-skill M3), 사업전략(→biz-skill), 리서치(→research-frame).

---

When to Use

• 사용자가 "지표 설계해줘", "KPI 만들어줘", "리뷰해줘", "track metrics", "design KPIs." 같은 표현으로 발동
• 분기 시작할 때, 주간리뷰 할 때, 성과 점검할 때.
• 안 쓸 때 — 재무모델링(→financial-model), 조직 OKR설계 전반(→management-skill M3), 사업전략(→biz-skill), 리서치(→research-frame).

Prerequisites

#	체크	미충족 시
1	대상·입력 명확 (스킬 발동 의도 확인)	1줄 확인 후 진입
2	references/ 폴더 접근 가능	inline fallback
3	scripts/ 실행 권한	권한 보정 후 재시도

⛔ 절대 규칙

#	규칙	이유
1	측정병리 선별 필수 — 모든 지표 설계 시 Goodhart·Campbell·McNamara·Surrogation·Cobra 위험도 평가	잘못된 지표는 시스템을 역방향으로 최적화함
2	변동유형 진단 필수 — 리뷰 시 공통원인 vs 특수원인 구분 (→ references/variation-theory.md)	공통원인에 대한 반응은 변동 증대 (Deming)
3	선행/후행 지표 쌍 필수 — 후행 지표만으로 대시보드 구성 금지	후행 지표는 거울(결과 확인). 선행 지표는 창문(미래 예측)
4	맥락 없는 숫자 금지 — 기준선·목표·추세·벤치마크 중 최소 2개 병기	숫자 단독=판단 불가
5	리뷰 주기 명시 필수 — 설계 시 리뷰 주기 + 판단 기준 사전 정의	지표 설계하고 안 보면 무의미

위험도 사전분류: 지표를 고위험(의사결정 직결·금액·법적 의무)/저위험(참고·추적)으로 분류. 고위험 지표만 절대규칙 5개 전수 적용. 저위험 지표는 #1(측정병리)+#5(리뷰주기) 2개만 적용.

---

§1. 모드 자동 판별

입력 유형	모드	예시
목표·전략 있음, 지표 없음	설계	"이 프로젝트 KPI 잡아줘"
지표 데이터 있음	리뷰	"이번 달 지표 리뷰해줘"
기존 지표 체계 재검토	재설계	"지금 KPI가 맞는 건지 모르겠어"

---

§2. 4층 지표 프레임 (이론적 근거 → references/metric-frameworks-deep.md)

층	명칭	질문	특성	선행/후행
L1	북극성 지표	사업/프로젝트의 궁극적 성공을 나타내는 단일 지표는?	변화 느림, 강한 신호	후행
L2	드라이버 지표	북극성을 움직이는 입력 변수는?	변화 빠름, 조작 가능	선행
L3	건강 지표	성장하면서 깨지면 안 되는 것은?	위험신호, 제약조건	양쪽
L4	카운터 지표	드라이버를 밀어붙일 때 역효과를 잡아내는 것은?	역효과탐지, 코나비안 방어	후행

설계 원칙: L1은 1개. L2는 35개. L3·L4는 각 23개. 총 지표 수 15개 이내.

---

§3. 설계 모드 파이프라인 (6단계)

①목표 확인 → ②4층 지표 설계 → ③지표 명세 작성 → ④측정병리 선별 → ⑤시스템 다이내믹스 체크 → ⑥리뷰 프로토콜 설계

①목표 확인

사업/프로젝트 목표·전략·단계 추출. planning-skill, ceo-pipeline 산출물이 있으면 연동.

②4층 지표 설계

§2 프레임으로 4층 구조화. 각 지표에:

지표명: [구체적 명칭]
층: [L1/L2/L3/L4]
정의: [정확한 계산식 또는 측정 방법]
유형: [선행/후행]
기준선: [현재값 또는 "측정 필요"]
목표: [구체적 숫자 + 기간]
리뷰주기: [일간/주간/월간/분기]
데이터소스: [어디서 이 숫자를 얻는가]

③지표 명세

위 양식으로 전체 지표 카드 작성.

④측정병리 선별 (→ references/measurement-pathology.md)

MANDATORY: 각 L2 드라이버 지표에 대해:

병리	확인질문	위험도	방어
Goodhart	이 지표만 최적화하면 어떤 역효과가 생기는가?	약/강	L4 카운터 지표로 포착 가능?
Campbell	이 지표를 리더십 평가에 쓰면 조작 압력이 생기는가?	약/강	측정과 결과 분리 필요?
McNamara	쉬운 것만 측정하고 어려운 것을 무시하지 않는가?	약/강	정성적 감시 필수?
Surrogation	지표가 진정한 구성개념을 대표하는가? (계산식 vs 의도)	약/강	프록시 검증 주기 필요? (→ references/proxy-metrics.md)
Cobra	지표 최적화 시 유인구조상 자기기만의 여지가 있는가?	약/강	인센티브 재설계? 불가능하면 감시 강화?

출력: 위험도 등급(Green/Yellow/Red) + 대응 방안 명시.

⑤시스템 다이내믹스 체크 (→ references/systems-metrics.md)

• L2 지표 간 피드백 루프 확인: 한 드라이버 최적화가 다른 드라이버를 훼손하지 않는가?
• 시간 지연(time delay) 확인: 이 지표 변화가 L1에 반영되는 데 얼마나 걸리는가?
• 시스템 레버리지 포인트 확인: 이 지표가 시스템의 몇 번 레버리지(Meadows 12-point scale)에 해당하는가?

⑥리뷰 프로토콜 설계

리뷰 유형	주기	참석	어젠다	판단 기준
일간 스탠드업	매일	실행팀	L2 드라이버	어제 대비 방향(↑↓→)
주간 리뷰	매주	리더	L1+L2+L3	주간 추세 + 이상치
월간 리뷰	매월	경영진	전층	목표 대비 진척 + 전략 조정
분기 리뷰	분기	전체	전층 + 전략	지표 체계 자체 유효성 재검토

---

§4. 리뷰 모드 파이프라인 (5단계)

①데이터 입력 → ②변동유형 진단 → ③추세 분석 → ④인과 추론 → ⑤액션 분류

①데이터 입력

기간, 지표값, 기준선, 목표, 맥락정보 수집.

②변동유형 진단 (→ references/variation-theory.md) MANDATORY

진단	신호	대응
공통원인 변동	변동이 통계적 관리한계(UCL/LCL) 내	시스템 재설계 필수. 단기 조치 불가
특수원인 변동	변동이 한계 밖 또는 명확한 단절점	근본원인 분석 후 표적 개입

함정: 공통원인으로 대응하면 변동 증대 (Deming의 깔때기 실험).

③추세 분석

• 방향: ↑ 개선 / ↓ 악화 / → 정체
• 속도: 가속 / 감속 / 일정
• 목표 대비 진척률: xx% 달성

④인과 추론

L2 변동 → L1에 미치는 영향 추정. L3·L4 이상 → 경고. 주의: 상관 ≠ 인과. "확인필요" 태그 적극 사용.

⑤액션 분류

분류	조건	행동
계속 밀어붙이기	목표 방향, 정상 속도, 카운터 지표 안정	현전략 유지
방향 전환	목표 방향이나 속도 미달, 또는 카운터 지표 이상	전략 조정, L2 재가중치화, 자원배분 변경
긴급 대응	L3 건강지표 붕괴, L4 카운터 급증, 특수원인 규모 크면	계획 중단 가능, 즉시 근본원인 분석

---

§5. 재설계 모드 파이프라인 (5단계)

①현행 지표 목록 입력 → ②4층 매핑 → ③갭 분석 → ④개선안 제안 → ⑤전환 로드맵

①현행 지표 목록 입력: 기존 지표 20~30개 나열.

②4층 매핑: 각 지표가 L1~L4 중 어디에 해당하는지 분류.

③갭 분석:

• 빠진 층 (예: L2만 10개, L3 0개)
• 허영 지표 (행동을 유도하지 않는 것)
• 과잉 지표 (너무 많음)
• 측정병리 위험도 높은 것

④개선안 제안: 추가·폐기·재정의 지표 목록 + 이유.

⑤전환 로드맵: 월별 전환 계획. 급격한 변경 피하기.

---

§6. 허영 지표 vs 행동 지표 판별

기준	허영 지표	행동 지표
행동 변경 유발	숫자 보고 뭘 해야 할지 모름	숫자 보고 즉시 행동 판단 가능
조작 가능성	정의 변경으로 쉽게 조작	조작 어렵고 조작해도 실제 결과에 영향
맥락 의존성	맥락 없이도 "좋아 보임"	기준선·목표 대비로만 의미
예시	총 가입자 수, 페이지뷰, 다운로드 수	활성사용자비율, 리텐션, 유료전환율

---

§7. 프록시 지표 설계 (→ references/proxy-metrics.md)

중요하지만 직접 측정 불가능한 것(장기 고객 만족, 혁신 능력, 신뢰도)을 프록시로 측정할 때:

필수 3단계:

1. 명시: "우리는 ~~를 측정하려고 하는데, ~~가 그것의 프록시라고 가정한다"
2. 검증: 프록시와 실제 구성개념의 상관도 + 검증 주기
3. 실패 신호: "이 프록시를 언제 폐기할 것인가"를 미리 정의

---

§8. 스킬 연동 맵

연동 스킬	연동 방식
management-skill M3	OKR 설계의 "측정" 부분. M3이 목표정렬, metric-tracker가 측정·추적
ceo-pipeline	로드맵의 마일스톤별 성공 지표 부착
planning-skill	P0~P1에서 성공기준 → 지표로 변환
risk-radar	L3 건강지표 이상 → 리스크 트리거로 연동
biz-skill	전략 축별 핵심 지표 매핑

---

📄 표준 리포트 템플릿

리뷰 모드 완료 후 아래 템플릿을 채워 출력한다. 빈칸 그대로 출력 금지.

주간/월간 리뷰 보고서 (Google OKR 리뷰 구조)

# [프로젝트/사업명] 지표 리뷰
기간: YYYY-MM-DD ~ YYYY-MM-DD | 작성:

## 한줄 요약
> [이번 주/월의 핵심 신호 — "L1 [N]% 달성. L2 [지표]가 [방향]으로 주목"]

## L1 북극성 지표
| 지표 | 목표 | 실제 | 달성률 | 전주(월) 대비 | 판정 |
|------|------|------|--------|-------------|------|
| [지표명] | | | xx% | ±xx% | 🟢정상/🟡주의/🔴위험 |

## L2 드라이버 지표
| 지표 | 목표 | 실제 | 달성률 | 방향 | 이상신호 |
|------|------|------|--------|------|---------|
| [드라이버1] | | | | ↑↓→ | Y/N |
| [드라이버2] | | | | ↑↓→ | Y/N |

## L3 건강 지표
| 지표 | 기준선 | 실제 | 상태 |
|------|--------|------|------|
| [건강지표1] | | | 🟢/🔴 |

## 변동유형 판정
- L1: [공통원인/특수원인] — 근거: [1줄]
- 이상 드라이버: [특수원인이면 — 근본원인 추정]

## 인사이트 (2~3문장)
[숫자에서 보이는 패턴 + 인과 추정 + 불확실성 표기]

## 액션
| 구분 | 액션 | 담당 | 기한 |
|------|------|------|------|
| 즉시 | | | D+7 |
| 다음 리뷰까지 | | | |

지표 설계 산출물 (OKR 카드 구조)

# [프로젝트명] 지표 체계
설계일: | 다음 재검토:

## 북극성 지표 (L1 — 1개)
**[지표명]**
- 정의: [계산식]
- 현재값: / 목표: / 기간:
- 데이터소스: / 리뷰주기: 월간

## 드라이버 지표 (L2 — 3~5개)
| 지표명 | 정의 | 현재값 | 목표 | 리뷰주기 | 측정병리 위험 |
|--------|------|--------|------|---------|------------|
| [드라이버1] | | | | 주간 | Green/Yellow/Red |

## 건강 지표 (L3)
| 지표명 | 정상 범위 | 경고 기준 | 위험 기준 |
|--------|----------|----------|----------|
| [건강1] | | | |

## 카운터 지표 (L4)
| 지표명 | 감시 대상 드라이버 | 이상 기준 |
|--------|-----------------|---------|
| [카운터1] | [드라이버명] | |

## 측정병리 위험 요약
| 지표 | 병리 | 위험도 | 방어 |
|------|------|--------|------|
| | Goodhart | | |

---

References (심화)

• → references/measurement-pathology.md — Goodhart, Campbell, McNamara, Surrogation, Cobra Effect.
• → references/variation-theory.md — Shewhart, Deming, Common Cause vs Special Cause.
• → references/systems-metrics.md — Donella Meadows 12 Leverage Points.
• → references/metric-frameworks-deep.md — Balanced Scorecard, OKR 구현, AARRR, North Star.
• → references/proxy-metrics.md — 프록시 이론, 5가지 실패 패턴.

---

§INV NO_WORK_LABEL

산출물·대화 작업 라벨 ZERO. → shaper-skill/references/no-work-label.md

Output Path

산출물	경로
주 산출물	mnt/outputs/metric-tracker_{topic}_{YYYY-MM-DD}.md
형식	대시보드로, 리뷰보고서로, .md로.
리서치 결과 (해당 시)	{VAULT}/_skills research/metric-tracker/{YYYY-MM-DD}_{topic}.md

Reference Index

파일	내용	언제
references/measurement-pathology.md	measurement pathology	해당 단계 진입 시
references/metric-frameworks-deep.md	metric frameworks deep	해당 단계 진입 시
references/post-doctor-notes.md	post doctor notes	해당 단계 진입 시
references/proxy-metrics.md	proxy metrics	해당 단계 진입 시
references/systems-metrics.md	systems metrics	해당 단계 진입 시
references/variation-theory.md	variation theory	해당 단계 진입 시

Next Phase

본 스킬 작업 후 자연스럽게 이어지는 흐름:

• 후속 작업 → financial-model
• 후속 작업 → management-skill
• 후속 작업 → biz-skill
• 후속 작업 → research-frame

Failure Modes (Gotchas)

함정	대응
측정병리 무시	§4 ④ 선별 필수. 특히 Goodhart + Campbell 이중 확인
공통원인에 대한 반응	리뷰 시 변동유형 진단 필수 (§4 ②). 공통원인 → 시스템 재설계만 가능
지표 20개+ 과잉	총 15개 이내. "무엇을 안 볼 것인가"가 설계의 핵심
후행 지표만	선행/후행 쌍 필수(절대규칙 #3)
지표 설계 후 방치	리뷰 프로토콜(§3 ⑥) 필수. 안 보면 안 만든 것과 동일
상관→인과 비약	리뷰 모드 §4 ④에서 "확인필요" 태그 적극 사용
프록시의 약화	프록시 검증 주기 (§7 단계 2) 없으면 해마다 신뢰도 하락. 정기 재검증 필수
시스템 설정 오류	§5 시스템 다이내믹스 체크로 피드백 루프 게임화 방지

❌ WRONG vs ✅ CORRECT

❌ WRONG: 트리거 단어만 보고 발동 — 본질·범위 확인 ✗ → 오발동·범위 이탈
✅ CORRECT: Skill Boundaries·When to Use 확인 후 발동 → 본질 작업만 수행