성공지표 · North Star · KPI 트리

04-measurement/success-metrics-kpi.html · LogiNippon · PRD · 2026-06-13 · 신뢰도 라벨 확인/추정/설계

이 페이지는 제품이 "잘 되고 있는가"를 한 눈에 보는 측정 체계다. 단 하나의 North Star = Tracking Rate(트래킹 정확도) 아래에, 그것을 끌어올리는 입력 지표, 화주·受取人이 실제로 지불하는 가치 지표, 그리고 무료 운영을 깨지 않게 막는 가드레일을 트리로 묶는다. 모든 수치는 진입 단계 초기 설계 목표이며 달성치가 아니다. 공식 정의(분모/분자·창·집계 윈도)는 TRD KPI/SLO 카탈로그가 소유하고, 여기서는 제품 의미와 목표만 다루며 정의는 링크한다. 결정적으로, 현재 우리는 이 지표들을 아직 측정하지 못한다 — 측정 파이프라인의 단일 선결 과제가 OBS-METRICS-001(METRICS.writeDataPoint TODO)이다.

확인 시장·법령 사실 추정 외부 근거 기반 추정 설계 우리 목표·결정(달성치 아님) PARTIAL 구현 상태(§14)

1. North Star Metric — Tracking Rate

North Star Metric(NSM) = Tracking Rate 설계 PARTIAL · 현재 미측정. 정의: 28일 윈도 동안 received_pings / expected_pings — 화물이 추적되리라 기대된 시간 중 실제로 위치 신호를 받은 비율. 공식 정의·집계 창은 TRD KPI-TRACK-001 / SLO-S4가 소유한다.

≥ 85%
MVP exit floor — GATE-P1 통과 최저선 설계
≥ 92%
정상 운영 지향치 설계
< 100%
100%는 비현실 — 터널·오프라인·고령 단말은 실재. 정직 노출이 원칙
28일
롤링 측정 윈도

왜 Tracking Rate가 North Star인가

정직성 경고 — 현재 미측정. Tracking Rate를 포함한 모든 SLI는 아직 산출되지 않는다. 서버의 METRICS.writeDataPoint가 TODO 상태(OBS-METRICS-001)라 Analytics Engine으로 데이터 포인트가 기록되지 않는다. 따라서 위 85%/92%는 달성치가 아니라 진입 단계 초기 설계 목표이며, 베이스라인은 post-launch에 처음 측정된다(미해결 질문). 드라이버 앱이 STUB(최대 갭, PR-02)인 동안에는 기대 핑 자체가 ShipmentFactory 시뮬레이션 위주임도 함께 명시한다.

2. KPI 트리 — NSM → 입력 · 가치 · 가드레일

North Star 아래로 측정 체계를 4갈래로 묶는다: 입력(NSM을 만드는 데이터 수집·파이프라인) → 가치(화주·受取人이 지불하는 결과) → 가드레일(무료 운영·SLA를 깨지 않게). 각 노드의 수치는 모두 설계 목표이고, 옆 링크가 그 지표의 공식 정의를 소유한 TRD KPI/SLO다.

측정 차단 해소 = OBS-METRICS-001. 위 트리의 어떤 노드도 writeDataPoint 배선 전에는 산출되지 않는다. 따라서 "목표 미설정 · post-launch 베이스라인"으로 표기한 노드들은 의도적으로 비워둔 것이며, 임의의 숫자를 채우지 않는다(달성치 날조 금지).

3. OKR — 분기 목표 (가설, 설계 라벨)

아래 OKR은 가설이며 모두 설계 라벨이다 설계. 핵심 결과(KR)의 정량 목표 다수는 OBS-METRICS-001 해소 후 첫 베이스라인이 나와야 확정된다. 먼저 "측정할 수 있게 만든다"가 선행 KR인 이유다.

분기(가설)ObjectiveKey Result (설계)근거 지표 / TRD
Q+1
(측정 기반)		 측정 가능한 제품으로 만든다 — 모든 NSM/SLI를 실제로 본다 KR1: writeDataPoint 배선 완료, Tracking Rate 첫 베이스라인 산출
KR2: 드라이버 앱 STUB 해소로 실 GPS 핑 ≥ 1개 라이브 거점 발생
KR3: 5개 STUB 중 ingest consentGate·룰 ETA 우선 해소 		OBS-METRICS-001 · FR-ACQ-GPS-001 · GATE-P1
Q+1
(cold-start)		 Phase 0 제휴 하드 게이트를 통과한다 KR1: 2트랙 루브릭 통과 파트너 ≥ 1개사 PoC 서명(GATE-P0)
KR2: ShipmentFactory 데모로 픽업→도착→대시보드 전 과정 실증 		PR-01 · JRN-COLDSTART · JRN-FACTORY
Q+2
(가치 증명)		 킬러 페인을 측정된 ROI로 전환한다 KR1: 荷待ち 리포트가 ≥ 1건 납품처 개선 협상에 실제 사용
KR2: 규제 출력이 수기 작성을 대체(監督官庁 제출 워크플로)
KR3: Tracking Rate ≥ 85% (MVP exit floor) 달성 		KPI-DWELL-001 · KPI-TRACK-001 · JRN-NIMACHI
Q+2
(컨사이니 확장)		 컨사이니 주도 land-and-expand를 작동시킨다 KR1: Inbound 큐를 보는 활성 컨사이니 거점 확보
KR2: 캐리어 비교 Dashboard로 inbound 캐리어 ≥ 1개사 끌어옴 		JTBD-04 · JTBD-05 · JRN-CONSIGNEE

OKR 정직성 노트. Tracking Rate ≥85% 같은 정량 KR은 가설적 목표다. 베이스라인이 85%보다 한참 낮게 나올 수 있으며, 그 경우 목표를 재설정하되 측정 결과를 미화하거나 날조하지 않는다. 목표 미설정 지표(OTD·OTP·예외율 등)는 미해결 질문으로 추적한다.

4. 측정 계획 — 전부 Analytics Engine, OBS-METRICS-001이 선결

모든 SLI/KPI는 Cloudflare Analytics Engine에 writeDataPoint로 기록되어 집계된다(서버 0대·무료티어 가드레일과 양립하는 측정 수단). 별도 관측 인프라를 도입하지 않는다. 공식 SLI 정의·집계 윈도·소진 예산은 TRD SLO 카탈로그가 소유한다.

선결 과제 — OBS-METRICS-001(METRICS.writeDataPoint TODO). 현재 코드에서 이 호출이 TODO 상태라 어떤 데이터 포인트도 기록되지 않는다. 즉 위의 모든 SLO/KPI는 정의는 있으나 관측치가 없다. 이 한 가지가 측정 체계 전체의 단일 병목이다(PR-09).

원칙: 측정 불가능한 SLO는 요구사항이 아니다. 우리가 산출·관측할 수 없는 목표는 GATE-P1의 합격 기준으로 쓰지 않는다. 따라서 측정 배선(OBS-METRICS-001)과 드라이버 앱 실 GPS(PR-02)가 들어와야 비로소 Tracking Rate·dwell·ETA MAPE를 게이트 기준으로 인정한다.

측정 대상수단선결 / 상태정의 소유(TRD)
Tracking Rate (NSM)Analytics Engine 집계(received/expected 핑)PARTIAL · OBS-METRICS-001 + 드라이버 앱 GPSKPI-TRACK-001 · SLO-S4
인제스트·지오펜스 지연(p95)writeDataPoint 타이밍엔진 DONE · 기록 STUBSLO-S1 · SLO-S2
정규화율매핑 성공/실패 카운터측정 미배선KPI-NORM-001 · SLO-S8
荷待ち / OTD / OTP / 예외율지오펜스 dwell·이벤트 집계(컨사이니 Dashboard 병렬 뷰)dwell DONE · 집계 측정 미배선KPI-DWELL-001 · KPI-OTD-001 · KPI-OTP-001 · KPI-EXC-001
ETA 정확도(MAPE)예측 vs 실측 비교(룰 ETA 산출 후)룰 ETA STUB(ack-only)KPI-ETA-001 · SLO-S7
가용성 / 웹훅 / WS 지연(가드레일)요청 성공·전달·전파 카운터웹훅 전달 STUB · 측정 미배선SLO-S5 · SLO-S3 · SLO-S6

5. 정직성 원칙 — 달성치 날조 금지

측정은 영업 자료가 아니라 진실원이다. 다음을 강제한다(가시성 정직 = 포지셔닝):

근거·상호참조