지표 분류 체계 — Goal · Driver · Guardrail

3 분류의 역할 분담 + HEART · AARRR · Funnel 프레임워크 + 같은 metric 다른 role

Kohavi (2020) Ch.6.1 의 핵심 분류 체계를 깊게 다룬다. Goal · Driver · Guardrail 의 정의·역할· 사용 시점을 비교하고, HEART · AARRR · 사용자 funnel 같은 driver 프레임워크의 구조를 분석한다. Asset vs Engagement, Business vs Operational 같은 다른 taxonomy 와의 관계, 그리고 같은 metric 이 팀마다 다른 분류일 수 있는 이유를 정리한다.

Experimentation
A/B Test
저자

Kwangmin Kim

공개

2026년 05월 08일

1 정의

정의: G/D/G 분류 (Goal · Driver · Guardrail)

Kohavi (2020) 가 표준화한 조직 지표 3 분류.

Goal Metric (목표 지표) — 조직이 궁극적으로 추구하는 결과. mission 의 정량적 표현. 예: revenue, MAU, user satisfaction.

Driver Metric (동인 지표) — Goal 로 가는 단기·민감 지표. mental causal model 의 노드. 예: page views, signup rate, retention.

Guardrail Metric (가드레일 지표) — 가정 위반·기본 제약 위반을 감지. 출시 차단 조건. 예: latency, crash rate, error rate.

이 3 분류는 시간 horizon · sensitivity · 사용 목적 의 직교 차원을 포착한다 (Kohavi, Tang, Xu, 2020, Ch.6.1).

2 개념 및 원리

2.1 분류의 직교성

3 분류는 독립 차원이라 같은 metric 이 다양한 분류로 분류 가능.

차원 Goal Driver Guardrail
시간 horizon 장기 단기·중기 즉시
Sensitivity 낮음 높음 매우 높음
사용 빈도 분기·년 주·월 매 출시
변경 빈도 거의 없음 가끔 진화 거의 없음
의사결정 역할 방향 제시 진척 측정 부작용 차단
유효성 검증 mission 일치 causal alignment 인과 영향
직관 — 왜 한 metric 으로 모든 차원 충족 못 하는가

이상적 metric: 장기 + 민감 + 즉시 + 변경 안 됨 + 모든 결정 지원. 그러나 이 모두를 만족하는 metric 은 존재하지 않는다.

수학적 관점: 신호 (signal) 와 노이즈 (noise) 의 trade-off.

  • 장기 metric 은 누적 신호. 노이즈가 평균화되어 안정 ↑. 그러나 단기 변화 detect 불가.
  • 단기 metric 은 즉시 신호. 변화 detect ↑. 그러나 노이즈도 큼.

따라서 분리 측정이 필수. 자동차의 속도계 (즉시) + 주행거리 (누적) 가 별도인 이유와 같다.

또한 인지 부담 분리 차원도 있다. 의사결정자는 한 번에 한 차원만 효과적으로 처리 가능 (George Miller 의 7±2). Goal 만 보는 시간, Driver 만 보는 시간, Guardrail 만 보는 시간을 분리 하면 각 차원에 적절한 인지 자원 할당 가능.

2.2 Goal Metric 의 깊은 특성

2.2.1 Simple

  • 설명 1 분 안에 가능해야 함
  • 매출 (revenue) — 단순. 누적 LTV 의 risk-adjusted present value — 복잡.
  • Stakeholder 가 이해 못 하면 buy-in 부족 → 의사결정 영향 ↓

2.2.2 Stable

  • 새 기능 출시마다 정의 변경하면 안 됨
  • 시계열 비교 가능성 보존 (오늘과 1 년 전을 비교 가능해야)
  • 변경 시 명시적 announcement + migration plan 필요

2.2.3 Mission-Aligned

  • 회사 mission 의 정량적 proxy
  • Mission ↔︎ Goal 의 gap 을 인지하고 명시
  • Gap 이 너무 크면 다른 goal 후보 검토
가정 — Goal 이 mission 의 충분한 proxy 라는 가정

이 가정의 한계.

예시 1 — Microsoft “empower every person”

  • Goal 후보: MAU, achievement count, productivity score
  • Mission 의 “empower” 는 사용자가 자신의 목표를 달성 하는 것
  • MAU 는 사용 빈도 만 측정 — empower 의 일부만 capture

예시 2 — Google “organize world’s information”

  • Goal 후보: query count, search satisfaction, time-on-task
  • Mission 의 “organize” 는 정보 접근성·발견 가능성 의 시스템적 향상
  • 사용자 metric 은 시스템 측면 일부만 capture

저자들의 권고: mission 을 단어로 articulate, goal 의 한계 명시, 시간 경과 진화. Goal 자체가 완벽하지 않음을 인정하고 stakeholder 와 공유.

이는 단일 metric 의 근본 한계 — 어떤 metric 도 진정한 가치의 일부만 capture. 따라서 G/D/G 분류 + 다중 metric ensemble 이 필요.

2.3 Driver Metric 의 4 가지 원칙

2.3.1 1. Aligned with Goal

Driver 변화 → Goal 변화의 인과 관계 검증.

검증 방법. - 상관 분석 — driver ↑ 시 historical goal ↑ ? - Driver-only 실험 — driver 를 직접 조작하는 실험에서 goal 변화 측정 - Time-lagged 분석 — driver 변화가 N 개월 후 goal 에 반영되는가

2.3.2 2. Actionable and Relevant

팀이 lever 로 움직일 수 있어야 함.

  • 검색 팀이 “검색 결과 품질” 을 개선할 수 있는가? → Yes (lever: ranking 알고리즘)
  • 검색 팀이 “회사 매출” 을 직접 개선할 수 있는가? → No (lever 없음)

따라서 검색 팀의 driver 는 검색 결과 품질. 매출은 회사 goal 이지만 검색 팀의 driver 아님.

2.3.3 3. Sensitive

짧은 실험 (1~2 주) 에서 변화 detect 가능.

  • 매출 (Goal) — 변동성 큼. 1% 효과 detect 에 수십만 표본 필요.
  • CTR (Driver) — 변동성 작음. 1% 효과 detect 에 수만 표본.

Driver 가 Goal 보다 민감하다는 것이 lever 로서 가치를 부여.

2.3.4 4. Resistant to Gaming

인센티브 구조와 metric 정의가 perverse behavior 를 유도하지 않아야 함.

예 (Kohavi, Tang, Xu, 2020, Ch.6 sidebar):

  • “신기록 횟수” — 1g 단위 신기록 증가로 game 가능. 횟수가 아니라 절대 신기록 으로 변경 필요.
  • “chicken efficiency” — 주문 후 조리로 game. wait time 추가 로 보완.

Driver 설계 시 “이걸 어떻게 game 할까?” 를 사전 brainstorm 해야 한다.

직관 — 4 원칙의 동시 충족 어려움

4 원칙이 종종 trade-off 를 만든다.

  • Sensitive 한 metric 은 종종 game 가능 — CTR 이 sensitive 하지만 clickbait 로 game.
  • Game-resistant metric 은 종종 sensitive 하지 않음 — 7-day retention 은 game 어렵지만 단기 실험에서 detect 어려움.
  • Aligned 한 metric 은 종종 actionable 하지 않음 — 매출이 가장 aligned 이지만 대부분 팀의 lever 와 거리 있음.

따라서 하나의 driver 가 4 원칙 모두 만족 어려움. 해결: driver portfolio. 여러 driver 를 조합해 4 원칙 collectively 만족.

예: 검색 품질 driver portfolio. - CTR (sensitive, partial alignment, game 위험) - Successful clicks (sensitive, alignment, game 어려움) - Time-to-click (sensitive, alignment, game 위험) - 7-day return rate (long-term alignment, less sensitive)

4 driver 를 함께 보면 한 driver 의 game 시도가 다른 driver 의 변화로 자동 detect.

2.4 Driver 프레임워크 비교

2.4.1 HEART (Rodden, Hutchinson, Fu 2010)

Driver 정의 측정
Happiness 사용자 만족 NPS, survey, rating
Engagement 활동 강도 session length, frequency
Adoption 신규 사용자 획득 new accounts, first-time use
Retention 재방문 7-day, 30-day return
Task Success 작업 완료 task completion rate

장점: 사용자 perspective 의 5 차원 망라. 단점: 짧은 단기 실험에서 모두 측정 어려움 (특히 Retention).

2.4.2 AARRR (PIRATE, McClure 2007)

Driver 정의
Acquisition 사용자 획득
Activation 첫 의미 있는 사용
Retention 재방문
Referral 다른 사람에게 추천
Revenue 매출

장점: 사용자 funnel 의 시간순 분해. 각 단계의 conversion rate 측정. 단점: 5 단계 funnel 이 모든 비즈니스 모델에 적합하지 않음 (예: SaaS 와 e-commerce 가 다름).

2.4.3 User Funnel

비즈니스 모델 특화 funnel.

방문 (Awareness)
  ↓
가입 (Activation)
  ↓
첫 사용 (First Use)
  ↓
습관 형성 (Habit)
  ↓
구매 (Conversion)
  ↓
재구매 (Retention)

각 단계가 driver. 이전 단계를 통과한 사용자만 다음 단계의 분모.

직관 — 왜 funnel 이 driver 분해의 자연스러운 도구인가

Funnel 은 인과 chain 을 시각화. 각 단계가 다음 단계의 prerequisite. 따라서.

  • 단계 N 의 conversion 이 ↓ → 단계 N+1, N+2, … 모두 ↓
  • 단계 N 을 개선하면 후속 모든 단계가 자동 개선

이는 bottleneck 분석의 자연스러운 frame. 가장 ↓ 인 conversion 단계가 우선 개선 대상.

만약 funnel 분해 없이 매출 (마지막 단계) 만 본다면, 어느 단계가 bottleneck 인지 모름. 모든 단계를 동등하게 노력 → 자원 분산.

이는 화학 공정의 rate-limiting step 분석과 동일. 가장 느린 step 이 전체 throughput 결정. 다른 step 을 빠르게 만들어도 의미 없음.

2.5 Guardrail Metric 의 두 유형

2.5.1 1. Trustworthiness Guardrail

실험 자체의 신뢰성 보장.

  • SRM (Sample Ratio Mismatch) — 50/50 인데 49/51 → 배정·로깅 결함 (Ch.21)
  • A/A failure — Treatment 와 Control 에 같은 코드인데 차이 → 시스템 결함 (Ch.19)
  • Data freshness — 데이터가 어제까지 도착했는가
  • Instrumentation 누락 — 새 이벤트 schema 정의됨

이 유형은 Ch.21 시리즈 에서 상세.

2.5.2 2. Organizational Guardrail

비즈니스 측면의 위반 감지.

  • Latency / PLT — 사용자 이탈 (Ch.5)
  • HTML response size — 코드 sloppy 출시 신호
  • JavaScript errors per page — 브라우저 호환성 문제
  • Revenue-per-user — 다른 팀이 모르고 매출 hurt
  • Pageviews-per-user — denominator 변화 (CTR 분석 왜곡)
  • Client crashes — 안정성 (특히 모바일·desktop SW)
가정 — Guardrail 이 잘 정의되었다는 가정

Guardrail 의 깨짐 패턴.

  1. Threshold 가 너무 느슨 — 실제 위반을 catch 못 함 (예: latency +50ms 까지 허용)
  2. Threshold 가 너무 엄격 — 정상 변동도 차단 (false positive ↑)
  3. Coverage 부족 — 새로운 위반 유형 (예: GDPR 준수) 미감지
  4. 변경 자체가 의도적 — 일부 출시는 guardrail 위반이 의도 (예: 새 기능이 latency 증가 필연)

저자들의 권고: threshold 정기 갱신. 비즈니스 진화에 따라 guardrail 도 진화. 또한 guardrail 위반이 의도적인 경우 명시적 override + 책임자 시스템 필요.

Guardrail 이 자동 차단만 하면 의도적 위반 불가능. 차단 + override 의 균형이 중요.

3 다른 Taxonomy 와의 관계

3.1 Asset vs Engagement

  • Asset metric — 정적 누적 (Facebook 계정 수, 친구 connection 수)
  • Engagement metric — 동적 활동 (세션, 페이지뷰)

G/D/G 와의 매핑.

  • Asset metric → 보통 Goal 또는 long-term Driver
  • Engagement metric → 보통 short-term Driver

3.2 Business vs Operational

  • Business metric — 비즈니스 건강 (revenue per user, DAU)
  • Operational metric — 시스템 운영 (queries per second, server load)

G/D/G 와의 매핑.

  • Business metric → Goal 또는 Driver (회사 차원)
  • Operational metric → Guardrail 또는 Driver (팀 차원)

3.3 Data Quality / Diagnosis / Debug

분류 사용 시점 예시
Data Quality 모든 실험 SRM, instrumentation completeness
Diagnosis 문제 발견 후 drill-down 영역별 CTR, segment 별 retention
Debug 개발자가 사용 server response time per endpoint

이들은 G/D/G 와 직교. 같은 metric 이 G/D/G 분류 + Diagnosis 분류 동시 가능.

3.4 비교 표

Taxonomy 차원 G/D/G 와의 관계
G/D/G 의사결정 역할 base 분류
Asset / Engagement 정적 / 동적 Goal·Driver 의 sub-분류
Business / Operational 비즈니스 / 시스템 팀 perspective 분류
Data Quality / Debug 분석 단계 직교, 추가 attribute

여러 taxonomy 를 동시 사용 가능. 한 metric 이 “Engagement Driver, 모든 팀의 Operational Guardrail” 처럼 multi-tag.

4 같은 Metric, 다른 Role — 팀별 분류

4.1 Product Team vs Infrastructure Team

같은 latency 지표.

팀 latency 의 역할
Product (검색·추천) Guardrail (출시 차단 조건)
Infrastructure Goal (자기 팀 mission)
Marketing 무관 (관심 없음)

이는 팀 mission 이 회사 mission 의 부분임을 반영. Infra 팀의 mission 은 “성능·안정성” 이라 latency 가 goal. Product 팀의 mission 은 “사용자 가치” 라 latency 는 그 가치를 해치지 않게 하는 guardrail.

직관 — 팀별 분류의 비유

회사 = 오케스트라.

  • 지휘자 (CEO) — 전체 음악 (회사 mission) 의 quality 가 goal
  • 바이올린 섹션 (Product 팀) — 멜로디 (사용자 가치) 가 goal, 박자 (latency) 는 guardrail
  • 타악기 섹션 (Infrastructure 팀) — 박자 (latency) 가 goal, 멜로디 위반은 guardrail

각 섹션은 자기 mission 에 집중하되, 다른 섹션의 mission 을 violate 하지 않게 guardrail. 이렇게 하면 전체 음악이 조화롭다. 각 섹션이 자기 goal 만 추구하고 다른 섹션을 무시하면 cacophony.

이 패턴은 계층적 metric 정렬 (hierarchical metric alignment) 이라 부른다 (Kaplan & Norton 1996 Balanced Scorecard 의 일반화).

4.2 계층적 정렬

저자들의 권고 (Parmenter 2015 인용): 모든 팀의 metric 이 회사 strategy 와 align 되어야 함.

회사 Goal: long-term revenue
    ↓ break down
Driver: user engagement, retention
    ↓ break down per team
Search Team Goal: search satisfaction
  Driver: CTR on satisfied clicks
  Guardrail: latency, query count

Recommendation Team Goal: relevance score
  Driver: predicted CTR
  Guardrail: diversity, coverage

Infrastructure Team Goal: latency P95
  Driver: cache hit rate, query plan efficiency
  Guardrail: search team metrics, recommendation team metrics

각 팀의 goal·driver 가 다음 layer 의 driver 또는 guardrail 로 작동. 정렬이 깨지면 localized optimization → global degradation.

5 왜 필요한가

5.1 분류 없는 metric set 의 함정

분류 없이 100 개 metric 을 추적하면.

  • 모든 metric 동등 무게 — 어느 게 중요한지 모름. 이상 동시 발견 시 우선순위 모호.
  • 단기·장기 혼동 — 이번 주 변화로 출시 결정. long-term Goal drift 무시.
  • Cherry-picking — 한 metric 이 좋은 방향이면 그것만 highlight. Guardrail 위반 무시.
  • Gameability — 모든 metric 이 인센티브 source. game 가능성 사전 평가 안 됨.

5.2 분류로 얻는 이익

  • 의사결정 frame — Goal 우선, Driver 메커니즘, Guardrail 차단 조건
  • 인지 부담 분리 — 각 분류를 다른 시점·다른 사람이 처리
  • 계층적 정렬 — 팀 metric 이 회사 metric 의 sub-set
  • Game 사전 분석 — 각 분류의 인센티브 시나리오 brainstorm

6 응용 사례

6.1 Microsoft Office 의 G/D/G

분류 Metric
Company Goal Subscription Revenue, MAU
Product Driver Document Created, Collaboration Sessions, Cloud Save Rate
Product Guardrail Latency, Crash Rate, Error Rate
Infrastructure Goal API P95 Latency, Service Availability
Infrastructure Guardrail Product Driver Metrics

이 매핑은 계층적 정렬을 보여준다. Infrastructure 팀의 Guardrail 이 Product 팀의 Driver. 즉 인프라 출시가 product driver 를 hurt 하면 자동 차단.

6.2 Bing 의 사례 — Latency 의 변화하는 분류

Bing 의 latency 는 회사 진화에 따라 분류 변화 (사전지식).

  • 2009 이전: latency = Operational metric (관심 적음)
  • 2010~2015: Slowdown 실험 후 → Guardrail (모든 출시 차단)
  • 2015~: 매출에 큰 영향 검증 → 일부 팀에는 Goal-aligned Driver

이는 분류가 고정 아님을 보여준다. 비즈니스 이해 진화 → metric 의 의미 진화 → 분류 진화.

6.3 Netflix 의 Bucketized Watch Hours

Netflix 의 driver: bucketized watch hours (시간 bucket: 0-2h, 2-5h, 5-10h, 10h+).

  • Driver 로 사용 가능 (Xie & Aurisset 2016)
  • Goal (long-term retention) 과 인과 관계 검증
  • 단순·해석 가능 (복잡한 LTV 모델 대신)

이는 interpretability 우선의 사례. 복잡한 모델로 더 정확한 retention 예측 가능하지만 stakeholder buy-in 어려움.

7 예시 — G/D/G 의 계층적 정렬 시뮬레이션

import pandas as pd

# 회사·팀별 G/D/G 매핑
metrics_hierarchy = pd.DataFrame([
    # Layer 1: Company
    {"Layer": "Company", "Team": "-",        "Role": "Goal",      "Metric": "Long-term Revenue"},
    {"Layer": "Company", "Team": "-",        "Role": "Driver",    "Metric": "MAU, Retention"},
    {"Layer": "Company", "Team": "-",        "Role": "Guardrail", "Metric": "User Trust, Compliance"},

    # Layer 2: Product Team
    {"Layer": "Product", "Team": "Search",   "Role": "Goal",      "Metric": "Search Satisfaction"},
    {"Layer": "Product", "Team": "Search",   "Role": "Driver",    "Metric": "Successful CTR"},
    {"Layer": "Product", "Team": "Search",   "Role": "Guardrail", "Metric": "Latency, Revenue"},

    {"Layer": "Product", "Team": "Recom",    "Role": "Goal",      "Metric": "Recommendation Relevance"},
    {"Layer": "Product", "Team": "Recom",    "Role": "Driver",    "Metric": "Predicted CTR, Diversity"},
    {"Layer": "Product", "Team": "Recom",    "Role": "Guardrail", "Metric": "Coverage, Latency"},

    # Layer 3: Infrastructure Team
    {"Layer": "Infra",   "Team": "Backend",  "Role": "Goal",      "Metric": "API P95 Latency, Availability"},
    {"Layer": "Infra",   "Team": "Backend",  "Role": "Driver",    "Metric": "Cache Hit Rate, Query Plan Eff."},
    {"Layer": "Infra",   "Team": "Backend",  "Role": "Guardrail", "Metric": "Search/Recom Team Metrics"},
])

# 같은 metric 이 다른 팀에 다른 role
print("=== Same Metric, Different Role ===")
for metric in ["Latency", "Revenue"]:
    matches = metrics_hierarchy[metrics_hierarchy["Metric"].str.contains(metric, case=False)]
    print(f"\n{metric}:")
    print(matches[["Team", "Role", "Metric"]].to_string(index=False))

# 정렬 검증: 팀 Goal/Driver 가 회사 Driver 의 component 가 되는가?
print("\n\n=== Hierarchical Alignment ===")
for layer in ["Company", "Product", "Infra"]:
    layer_metrics = metrics_hierarchy[metrics_hierarchy["Layer"] == layer]
    print(f"\n{layer} Layer:")
    print(layer_metrics[["Team", "Role", "Metric"]].to_string(index=False))

예상 출력 (개념 시뮬레이션).

=== Same Metric, Different Role ===

Latency:
   Team       Role                          Metric
 Search  Guardrail                Latency, Revenue
  Recom  Guardrail                Coverage, Latency
Backend       Goal API P95 Latency, Availability

Revenue:
   Team       Role                Metric
      -       Goal     Long-term Revenue
 Search  Guardrail      Latency, Revenue
직관 — 코드가 보여주는 정렬 패턴
  1. Latency 가 Search·Recom 의 Guardrail, Backend 의 Goal — 팀 mission 차이 반영.
  2. Revenue 가 Company Goal, Search 의 Guardrail — Search 팀이 자기 driver 만 추구하다 매출 hurt 못 하게.
  3. Backend 의 Guardrail = 다른 팀의 Driver — 인프라 출시가 product 팀의 metric 손상 방지.

이 정렬 패턴이 회사 차원의 자기 점검 시스템. 한 팀이 자기 metric 만 추구하면 다른 팀의 guardrail 가 위반되어 자동 차단. 모든 팀이 다른 팀의 영향을 모니터링.

분류 + 정렬이 없으면 각 팀이 silos 에서 자기 KPI 만 추구. 회사 전체로 보면 zero-sum game 또는 negative-sum game 가능. 정렬 시스템이 이를 positive-sum 으로 유도.

8 관련 주제

선행 — Ch.6 시리즈

후속 — Ch.6 시리즈

관련 챕터

다른 카테고리 연결

Subscribe

Enjoy this blog? Get notified of new posts by email: