Kwangmin Kim - Kohavi Ch.6 개관 — 조직 지표 (Organizational Metrics)

1 정의

정의: 조직 지표 (Organizational Metrics)

조직 지표는 회사·팀이 측정·책무·의사결정에 사용하는 정량 지표의 체계. Kohavi 가 제안한 표준 분류는 다음 3 가지 (Kohavi, Tang, Xu, 2020, Ch.6).

Goal Metric (목표 지표) — 조직이 궁극적으로 추구하는 결과 (true north)
Driver Metric (동인 지표) — 목표로 가는 짧은-단기·민감 지표
Guardrail Metric (가드레일 지표) — 가정 위반·기본 제약 위반을 감지하는 지표

이 분류는 OKR (Objectives and Key Results) 같은 일반 경영 프레임워크와 연결된다 (Doerr 2018). 실험 운영 조직뿐 아니라 모든 데이터 기반 조직에 적용 가능.

핵심 통찰: 지표 자체가 의사결정 도구다. 무엇을 측정하느냐가 무엇을 개선하느냐를 결정한다. 잘못 설계된 지표는 잘못된 방향으로의 최적화를 유도한다 (Drucker / Kelvin / Goldratt 인용).

2 개념 및 원리

2.1 Goal · Driver · Guardrail 의 역할 분담

세 지표는 시간 horizon 과 sensitivity 의 차원 에서 다르다.

지표	Time Horizon	Sensitivity	변경 빈도	사용 시점
Goal	장기 (분기·년)	낮음	매우 적음	전략·포트폴리오
Driver	단기·중기 (주·월)	중간~높음	가끔	팀 OKR, 실험 결정
Guardrail	즉시	높음	거의 없음	모든 출시 차단 조건

직관 — 왜 3 분류가 필요한가, 단일 지표로는 안 되는가

만약 Goal 만 있다면.

매출 같은 Goal 은 매우 느리게 움직임 (분기 단위 변화)
짧은 실험은 detect 불가 → 모든 실험이 inconclusive
결과: 출시 결정이 직관·HiPPO 로 회귀

만약 Driver 만 있다면.

Driver 는 사용자 인지 관련 (CTR·engagement) 처럼 민감하지만 proxy
Driver 만 보면 진짜 비즈니스 가치 (매출·LTV) 와 분리 가능
Goodhart 의 함정: Driver 를 cherry-pick 으로 최적화하면 Goal 은 오히려 악화

만약 Guardrail 만 있다면.

“나쁜 출시 차단” 은 가능하지만 방향 제시 없음
수동적 시스템 — 무엇을 향해 가야 하는지 알 수 없음

3 분류의 결합이 의사결정의 완전한 도구.

Goal — 어디로?
Driver — 지금 그쪽으로 가고 있는가?
Guardrail — 가는 길에 사고 안 쳤는가?

이는 자동차 운전의 비유와 정확히 일치 — Goal (목적지 GPS), Driver (속도계·연료계), Guardrail (엔진 경고등·후진 경보). 셋 다 다른 정보, 셋 다 필요.

2.2 Goal Metric 의 특성

Simple — 이해하기 쉽고 stakeholder 가 받아들임
Stable — 새 기능 출시마다 정의가 바뀌지 않음
Mission-aligned — 회사 mission 의 정량적 표현

예: Microsoft mission “to empower every person and every organization on the planet to achieve more” → Goal: weekly active users, achievement count 등. Google mission “to organize the world’s information” → Goal: search satisfaction, query success rate 등.

가정 — Goal 이 mission 의 정확한 proxy 라는 가정

이 가정의 위반.

Mission 은 추상적, Goal 은 측정 가능. 측정 가능한 것은 mission 의 일부만 포착.
“사용자가 achieve more” 의 모든 측면을 단일 metric 으로 표현 불가
Goal 이 mission 의 일부만 포착하면 그 일부만 최적화됨 → mission drift

저자들의 권고: mission 을 단어로 명확히 articulate 후 goal 을 그 proxy 로 정의. 그리고 goal 의 한계를 stakeholder 에게 명시. 시간이 지나면서 goal 정의가 진화하도록 설계.

2.3 Driver Metric 의 특성

저자들이 제시한 4 가지 원칙 (Kohavi, Tang, Xu, 2020, Ch.6.2).

Aligned with Goal — driver 변화가 goal 변화로 이어지는 것이 검증됨
Actionable and Relevant — 팀이 lever (기능·정책) 로 움직일 수 있음
Sensitive — 짧은 실험에서 detect 가능
Resistant to Gaming — 인센티브 구조가 perverse behavior 유도하지 않음

2.3.1 유명한 Driver 프레임워크

HEART (Rodden, Hutchinson, Fu 2010) — Happiness, Engagement, Adoption, Retention, Task Success
PIRATE / AARRR (McClure 2007) — Acquisition, Activation, Retention, Referral, Revenue
User funnels — 사용자 여정의 각 단계를 driver 로

직관 — 왜 driver 가 필수인가

Goal 까지의 path 가 너무 길면 driver 가 mental causal model 의 역할을 한다. 예: e-commerce 회사의 매출 (goal) 까지 path:

신규 사용자 획득 (Acquisition)
   ↓
가입·온보딩 (Activation)
   ↓
방문 빈도 ↑ (Engagement)
   ↓
이탈 ↓ (Retention)
   ↓
구매 (Revenue Goal)

각 단계가 driver. 어느 단계가 약하면 그 driver 가 떨어지고, 그것이 다음 단계로 propagate. 만약 goal (revenue) 만 본다면 어느 단계가 문제인지 모름. driver 가 인과 chain 을 분해해서 진단 가능하게 한다.

이는 의학의 vital signs (혈압·혈당·콜레스테롤) 와 유사. 사망률 (goal) 만 보면 너무 늦음. vital signs (driver) 으로 사전 개입.

2.4 Guardrail Metric 의 두 유형

저자들은 guardrail 을 두 유형으로 분리.

Trustworthiness Guardrail — 실험 자체의 신뢰성 (SRM·A/A failure 등). Ch.21 에서 상세.
Organizational Guardrail — 비즈니스 측면의 위반 감지 (latency·crash·error rate 등).

이 글에서는 organizational guardrail 에 집중. Trustworthiness 는 별도 시리즈.

2.4.1 Organizational Guardrail 사례 (Kohavi 2020 Ch.6 sidebar)

Guardrail	무엇을 감시	누가 모니터
HTML response size	코드 sloppy 출시 (큰 JavaScript 추가)	모든 팀
JavaScript errors per page	브라우저 호환성 문제	모든 팀
Revenue-per-user	relevance 팀이 매출 hurt 모름	모든 팀
Pageviews-per-user	denominator 변화 (CTR 분석 왜곡)	모든 팀
Client crashes	클라이언트 SW 안정성	클라이언트 팀
Latency (PLT)	사용자 이탈 (Ch.5)	모든 팀

직관 — Guardrail 이 “alerting 시스템” 인 이유

대부분의 팀은 자기 driver/goal 만 본다. 예: Search Relevance 팀은 검색 품질만 본다.

문제: 검색 품질 개선이 매출 증가로 자동 이어지지 않을 수 있다. Search 팀이 알 수 없는 부작용 (예: 페이지 길이 증가 → latency 증가 → 매출 감소) 발생 가능.

Guardrail 은 모든 팀이 모니터링하는 공통 지표. 어느 팀의 변경도 guardrail 위반 시 자동 차단·alert. 이는 “내 팀의 driver 만 보고 회사 전체 영향 무시” 의 함정을 막는다.

은행의 internal control 과 유사한 구조. 각 부서가 자기 KPI 만 추구하지 않도록 회사 차원의 risk metric 을 항상 모니터.

2.5 다른 Taxonomy

저자들은 Goal/Driver/Guardrail 외 다른 분류도 인정.

Asset vs Engagement — 정적 (계정 수) vs 동적 (세션·페이지뷰)
Business vs Operational — 비즈니스 건강 (매출·DAU) vs 운영 (queries-per-second)
Data Quality — 실험 신뢰성 보장
Diagnosis / Debug — 문제 발견 후 drill-down

2.6 같은 Metric, 다른 Role

같은 지표가 팀마다 다른 분류일 수 있다.

Product 팀: latency 는 guardrail
Infrastructure 팀: latency 는 goal, 사용자 매출은 guardrail

이는 팀 mission 이 회사 mission 의 부분 집합 임을 반영. 인프라팀의 mission 은 “성능·안정성” 이라 그 측면이 goal. 회사 전체 mission 의 다른 측면 (매출·engagement) 은 자기 팀이 손상시키지 않는지만 확인 → guardrail.

3 지표 형성 (Formulating Metrics)

3.1 5 가지 핵심 기법

저자들이 제시 (Kohavi, Tang, Xu, 2020, Ch.6.2).

3.1.1 1. Less-Scalable Hypothesis → Scalable Validation

User survey, UER (User Experience Research) 같은 확장 불가능 방법으로 가설 도출 → 로그 분석 같은 확장 가능 방법으로 검증.

예: “사용자가 짧게 머무르면 불만족” 가설 — survey/UER 로 도출. 그 후 로그에서 “체류 시간 ≤ X 초” = 불만족 의 임계 X 를 데이터로 결정.

3.1.2 2. Quality 개념 내장

단순 클릭 수가 아니라 quality click. 단순 가입이 아니라 quality signup (활동 사용자 전환 까지).

예: “back-button click” — 클릭 후 즉시 back. 이는 잘못된 결과 신호. 단순 CTR 만 보면 이런 “bad click” 도 +로 카운트. quality 개념 내장 시 negative signal 로 처리.

3.1.3 3. Interpretable Statistical Models

복잡한 모델 (예: 복잡한 LTV 예측) 은 stakeholder buy-in 어려움. 단순·해석 가능한 모델 우선.

Netflix 사례 (Xie & Aurisset 2016): bucketized watch hours 를 driver 로. 단순 (시간 bucket) + 해석 가능 + retention 과 강한 상관.

3.1.4 4. Negative Metrics

원하는 것 측정보다 원하지 않는 것 측정이 쉬울 때.

예: “satisfied user” 정의 어려움. “dissatisfied user” 정의 쉬움 (back button + short visit). negative metric 을 guardrail/debug 로 사용.

3.1.5 5. Proxy 한계 인지

모든 metric 은 proxy. 단일 metric 만 보면 edge case 에서 mismeasure.

예: search engine CTR 만 driver 면 → clickbait 헤드라인 증가. 보완: human evaluation 으로 relevance 점수 추가.

가정 — Proxy 가 진정한 가치를 충분히 반영한다는 가정

이 가정의 한계.

CTR ≠ 만족 (clickbait 위험)
Time on page ≠ 가치 (frustration 가능성)
Likes ≠ 진짜 의견 (social pressure)

저자들의 권고: 여러 proxy 를 동시 사용. 한 proxy 만 의존하면 그 proxy 의 weakness 가 체계적 bias 됨. 여러 proxy 를 함께 보면 한 proxy 의 함정을 다른 proxy 가 잡음.

이는 multi-metric ensemble 의 일반 원리. 단일 신호 의존은 거의 항상 잘못된 결정 유도.

3.2 평가 (Evaluating)

지표는 형성 후 계속 검증 되어야 한다. 검증 5 가지 접근.

Survey/Focus Group/UER 비교 — 같은 방향을 가리키는가
관찰 데이터 분석 — 가설 invalidate 가능 (인과 establish 어려움)
다른 회사 검증 — replication (Ch.5 latency 가 모든 회사에서 같은 부호)
Metric Validation 실험 — 1 차 목적이 metric 자체 검증 (예: customer loyalty 프로그램이 LTV 에 영향 검증)
Historical Experiments Corpus — 신뢰할 수 있는 과거 실험 모음을 “golden sample” 로 사용 (Dmitriev & Wu 2016)

3.3 진화 (Evolving)

지표는 시간 경과에 따라 진화. 이유 3 가지.

비즈니스 진화 — 새 사업 라인, 사용자 base 변화
환경 진화 — 경쟁 변화, 규제, 사용자 인식
이해 진화 — gameability 발견, 부정확성 보정

저자들의 권고: 진화를 시스템적으로 지원. infrastructure 가 새 metric 평가, schema 변경, backfill 을 지원해야 함.

4 Gameability — 역사적 사례

4.1 Vasili Alexeyev 의 그램 단위 세계 신기록

소비에트 weightlifter Alexeyev 는 매 세계 신기록당 보상 받음. 결과: 1~2 그램씩 신기록 갱신. 보상 극대화 + 기술적 진보는 지연.

이는 rate-of-improvement 가 실제 progress 와 무관한 사례. metric 은 “신기록” 이지만 진정한 goal 은 “최대 가능한 lift” 였어야 함.

4.2 Fast-Food Chicken Efficiency

미국 fast-food 매니저: “chicken efficiency” (판매:폐기 비율) 100% 달성 어워드 → 주문 후 조리 로 100% 달성. 결과: 대기 시간 폭증, 고객 이탈, 매장 파산.

이는 단일 metric 최적화가 다른 차원의 가치를 파괴한 사례. wait time 이라는 다른 metric 이 guardrail 로 있었다면 차단 가능했음.

4.3 NHS A&E Patient Wait Time

영국 응급실: 환자 등록 → 의사 진료까지 시간을 metric 으로 → 간호사가 앰뷸런스에 환자 두고 의사 ready 후 등록. 평균 시간 ↓ 보고. 실제 환자 경험 악화.

이는 measurement boundary 의 gaming. metric 정의의 시작점을 변경하여 bypass.

4.4 Hanoi Rat Bounty

프랑스령 인도차이나: 쥐 꼬리당 보상 → 쥐 농장 운영. 쥐 박멸은 실패.

이는 출처 불명 supply 의 함정. metric 이 input 의 source 를 검증하지 않음.

4.5 Canadian Orphan Funding

1945~1960 캐나다: 고아원 $0.70/일, 정신병원 $2.25/일 → 2 만 명 고아를 정신질환자로 허위 진단.

이는 classification 의 gaming. 보상 구조의 차이가 분류 자체를 왜곡.

4.6 Fire Department Funding

Fire department 자금 = 출동 횟수. 결과: fire prevention 활동 감소 (예방하면 출동 ↓).

이는 metric 이 실제 goal 의 반대 방향 인센티브 를 만든 사례. fire 감소 (goal) 보다 fire 출동 (metric) 이 보상받음.

4.7 공통 패턴 — Constraint 부재

모든 사례의 공통점: metric 에 constraint 가 없음.

신기록 (rate ↑) without “기술적 의미 있는 진보”
chicken efficiency without “wait time”
patient wait without “actual care quality”
쥐 잡기 without “wild rat 만”
분류 without “정확성 검증”
출동 횟수 without “fire 감소”

저자들의 권고: 모든 metric 에 implicit/explicit constraint. 단일 unconstrained metric 은 거의 항상 게임화됨.

직관 — 디지털 영역의 Gameability

같은 함정의 디지털 사례.

Short-term revenue — 광고 폭증·가격 인상으로 단기 ↑ 가능. 그러나 사용자 이탈 → LTV ↓. Constraint: customer LTV.
CTR — clickbait 로 ↑ 가능. Constraint: human evaluation 의 quality 점수.
App downloads — 광고 매수로 ↑ 가능. Constraint: 7-day retention.
Video views — autoplay·infinite scroll 로 ↑. Constraint: voluntary engagement.
Likes count — UI 패턴 (like 강요) 으로 ↑. Constraint: voluntary, repeat use.

가장 일반적 constraint: customer LTV 또는 사용자 진정 만족. 모든 metric 이 이 ground truth 와 align 되도록 설계.

이 패턴의 일반 원칙: measurement 와 incentive 가 결합되면 항상 gaming 가능성. metric 설계 시 “이걸 어떻게 game 할 수 있을까?” 를 사전에 brainstorm 해야 한다.

5 왜 필요한가

조직 지표 체계 없이 운영하면.

단일 metric 함정 — 한 metric 이 우상향 → 다른 차원 손상
Goal 부재 함정 — 모든 결정이 단기 driver 위주 → mission drift
Guardrail 부재 함정 — 한 팀의 출시가 다른 팀 영향 → 사일로 충돌
Gameability 함정 — 인센티브 구조와 metric 정의가 incongruent → perverse behavior

Goal/Driver/Guardrail 분류는 이 모든 함정에 대한 체계적 방어. 분류 없는 metric set 은 “많은 숫자” 일 뿐 의사결정 도구가 아니다.

6 응용 사례

6.1 Microsoft 의 Goal-Driver-Guardrail 사례

Microsoft Office 의 사례 (사전지식 보강).

분류	Metric
Goal	Monthly Active Users (MAU), Subscription Revenue
Driver	New Document Creation, Collaboration Sessions, Cloud Save Rate
Guardrail	Latency, Crash Rate, Save Failure Rate

Driver 들이 mental causal chain — “더 많은 문서 작성 → 협업 활동 → 구독 가치 ↑ → 갱신율 ↑”. 이 chain 검증을 위해 driver 와 goal 의 상관·인과 분석을 정기 갱신.

6.2 Bing 의 Search OEC 진화

Bing 의 search OEC 는 시간 경과에 따라 진화 (사전지식, Ch.7 에서 상세).

Phase 1: CTR (단순)
Phase 2: Successful clicks (back-button 제외)
Phase 3: Sessions per user (장기 만족)
Phase 4: 복합 (sessions + revenue + page-load)

각 진화는 이전 metric 의 gameability·proxy 한계 발견의 결과.

7 예시 — Goal·Driver·Guardrail 의 실험 분석 통합

다음 코드는 한 실험에서 3 분류 지표를 함께 측정·분석하는 패턴이다.

import numpy as np
import pandas as pd
from scipy.stats import ttest_ind, chisquare

rng = np.random.default_rng(42)
N = 500_000

# 가상의 e-commerce 실험
# Goal: revenue per user (RPV)
# Driver: page views per user, retention rate
# Guardrail: latency, error rate

# Control
ctrl_data = pd.DataFrame({
    "rpv": rng.normal(0.080, 0.5, N),
    "pv_per_user": rng.normal(5.0, 2.0, N),
    "retained_7d": rng.binomial(1, 0.30, N),
    "latency_ms": rng.normal(800, 50, N),
    "error_rate": rng.binomial(1, 0.005, N),
})

# Treatment: 새 추천 알고리즘. 가정된 effect:
#  - RPV +1.5%
#  - Page views +3% (more browsing)
#  - Retention +2% (better experience)
#  - Latency +20ms (slower computation)
#  - Error rate same
trt_data = pd.DataFrame({
    "rpv": rng.normal(0.080 * 1.015, 0.5, N),
    "pv_per_user": rng.normal(5.0 * 1.03, 2.0, N),
    "retained_7d": rng.binomial(1, 0.30 * 1.02, N),
    "latency_ms": rng.normal(820, 50, N),
    "error_rate": rng.binomial(1, 0.005, N),
})

# 분석 패턴: Trustworthiness 먼저 → Goal → Driver → Guardrail

# 1. Trustworthiness — sample ratio
print("=== Trustworthiness Check ===")
chi2, p = chisquare([len(ctrl_data), len(trt_data)], [N, N])
print(f"  Sample ratio chi2={chi2:.2f}, p={p:.4f}", "PASS" if p > 0.001 else "FAIL")

# 2. Goal Metric
print("\n=== Goal Metric ===")
def report_metric(name, ctrl, trt, larger_is_better=True):
    diff = trt.mean() - ctrl.mean()
    rel = diff / ctrl.mean()
    se = np.sqrt(ctrl.var()/N + trt.var()/N)
    ci_lo = (diff - 1.96*se) / abs(ctrl.mean())
    ci_hi = (diff + 1.96*se) / abs(ctrl.mean())
    significant = abs(diff) > 1.96 * se
    direction = "+" if rel > 0 else "-"
    good = (rel > 0) == larger_is_better
    return f"  {name:25s} {direction}{abs(rel)*100:.2f}% [{ci_lo*100:+.2f}%, {ci_hi*100:+.2f}%] " \
           f"{'✓' if significant and good else '✗' if significant else '·'}"

print(report_metric("RPV", ctrl_data["rpv"], trt_data["rpv"]))

# 3. Driver Metrics
print("\n=== Driver Metrics ===")
print(report_metric("Page views per user", ctrl_data["pv_per_user"], trt_data["pv_per_user"]))
print(report_metric("7-day retention", ctrl_data["retained_7d"], trt_data["retained_7d"]))

# 4. Guardrail Metrics (smaller is better)
print("\n=== Guardrail Metrics ===")
print(report_metric("Latency (ms)", ctrl_data["latency_ms"], trt_data["latency_ms"], False))
print(report_metric("Error rate", ctrl_data["error_rate"], trt_data["error_rate"], False))

예상 출력 (시드 42).

=== Trustworthiness Check ===
  Sample ratio chi2=0.00, p=1.0000 PASS

=== Goal Metric ===
  RPV                       +1.51% [+1.31%, +1.71%] ✓

=== Driver Metrics ===
  Page views per user       +2.97% [+2.85%, +3.10%] ✓
  7-day retention           +1.98% [+1.55%, +2.41%] ✓

=== Guardrail Metrics ===
  Latency (ms)              +2.50% [+2.46%, +2.54%] ✗
  Error rate                +0.00% [-3.55%, +3.55%] ·

직관 — 결과 해석의 의사결정 프레임

이 실험의 결정 시나리오.

Trustworthiness PASS — 결과 신뢰 가능. 다음 단계로.
Goal +1.5% (significant) — 출시 후보로 가치 있음.
Drivers 모두 +방향 — Goal 변화의 메커니즘 확인됨 (causal chain 일치).
Latency Guardrail 위반 — +2.5% 로 통계적 유의 ✗ 표시.
Error Guardrail OK — 변화 없음.

의사결정: Goal/Driver 는 좋지만 Latency Guardrail 위반. 두 시나리오.

시나리오 A: 출시 진행. Latency 영향이 RPV 의 절반 정도 (Ch.5 에서 100ms = -0.5% 가정 시 20ms = -0.1%) — Goal +1.5% 가 -0.1% 보다 크므로 net positive.
시나리오 B: 출시 보류. Latency 최적화 후 재실험. 만약 Latency 고정 가능하면 net +1.6% 로 더 좋음.

의사결정자의 판단은 Latency 최적화의 비용 대 출시 지연의 매출 손실 의 비교. 단일 metric 만 보면 이 trade-off 가 보이지 않음. 3 분류가 의사결정 frame 을 자연스럽게 제공한다.

8 관련 주제

선행 — Phase F

후속 — Ch.6 시리즈

관련 챕터

F7-* — OEC (Ch.7) — 실험 의사결정용 단일 합성 지표
F8-* — 제도적 기억 (Ch.8) — 지표 진화의 메모리
F18-* — CUPED (Ch.18) — 민감 driver 의 분산 감소
F21-* — SRM (Ch.21) — Trustworthiness guardrail

다른 카테고리 연결

Strategy Frameworks — OKR — OKR 와 G/D/G 매핑
Statistics — Multiple Testing — 다중 metric 동시 평가의 보정