Kwangmin Kim - 지표 형성·평가·진화 — Formulating, Evaluating, Evolving

1 정의

정의: Metric Lifecycle 의 3 단계

지표 (metric) 의 생명주기는 다음 3 단계를 거친다 (Kohavi, Tang, Xu, 2020, Ch.6.2~6.4).

Formulating — 추상 개념 (mission, success) 을 정량 지표로 전환
Evaluating — 지표가 실제 가치를 반영하는지 검증 (특히 인과 관계)
Evolving — 비즈니스·환경·이해 진화에 따라 정의 갱신

각 단계는 별개 활동이지만 순환 관계. Formulate → Evaluate → 결함 발견 → Evolve → 재 Evaluate.

핵심 가정: 지표는 절대 완벽하지 않다. 모든 지표는 진정한 가치 (true value) 의 proxy 이며, 시간 경과에 따라 proxy 의 한계가 드러난다. 이 한계를 인정하고 진화시키는 시스템이 필요하다.

2 형성 (Formulating) — 5 가지 기법

2.1 기법 1 — Less-Scalable Hypothesis → Scalable Validation

가설 도출과 정량화의 분리.

1. 가설 도출 (확장 불가능 방법)
   - User survey
   - Focus group
   - User Experience Research (UER)
   - 1:1 인터뷰
        ↓ 결과
   "사용자가 짧게 머무르면 불만족"

2. 가설 정량화 (확장 가능 방법)
   - 로그 분석
   - 시계열 추적
   - A/B 검증
        ↓ 결과
   "체류 시간 ≤ 20 초 + 검색 결과 클릭 = bounce"
        ↓
   임계 X (= 20 초) 를 데이터로 결정

Bounce Rate 의 사례 (Dmitriev & Wu 2016, Huang et al. 2012).

가설: 짧은 체류 = 불만족
검증: 로그 분석으로 임계 X 결정 (1 페이지뷰? 20 초?)
결과: 정확한 metric 정의

직관 — 왜 두 단계 분리가 필요한가

직접 로그만 보면.

어느 변수가 사용자 만족과 연관 있는지 모름 (수백~수천 변수 후보)
모든 변수의 임계를 brute-force 로 시도하면 multiple testing 문제

User survey/UER 는 인간의 지각 모델을 알려준다. “이런 패턴이 만족과 연관 있다” 의 가설. 이 가설을 로그 분석으로 정량화하면 explore 영역이 좁아져 multiple testing 문제 해결.

이 패턴은 mixed methods research 의 일반 원리. 정성적 (qualitative) 방법으로 가설 도출, 정량적 (quantitative) 방법으로 검증. 두 방법의 결합이 어느 한쪽보다 강력.

또한 정성적 방법은 edge case 발견에 우수. 예외 상황 (사용자가 의도와 다르게 행동) 을 발견 하면 metric 정의를 보완 가능.

2.2 기법 2 — Quality 개념 내장

단순 양 (count) 이 아니라 quality 가중 양.

단순 metric	Quality-weighted metric
Click count	Successful clicks (back-button 제외)
Signup count	Active signups (가입 후 30 일 내 사용)
Profile creation	Quality profile (학력·경력 등 충분 정보)
Page view	Engaged page view (스크롤·클릭 발생)

가정 — Quality 정의의 임의성

Quality 정의는 데이터 기반 + 도메인 지식의 결합. 그러나 임의 요소 존재.

“back button click 후 30 초 이내 = unsuccessful” — 30 초 임계는 어디서?
“quality profile = 학력 + 경력 + 사진” — 어떤 항목 조합?

이 임의성을 줄이려면.

민감도 분석 — 임계를 변경하며 metric 의 안정성 확인
다중 정의 비교 — 여러 임계로 metric 정의, 결과 일치 여부 확인
Domain expert review — 임계가 도메인 지식과 align 하는가

저자들은 “20 second bounce” 사례에서 데이터 분석 + UER 결과의 결합을 제시. 단일 정의가 아니라 다양한 임계의 비교로 robustness 확보.

2.3 기법 3 — Interpretable Statistical Models

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

2.3.1 Netflix 의 Bucketized Watch Hours

Netflix (Xie & Aurisset 2016): bucketized watch hours 가 driver.

Bucket: 0-2h, 2-5h, 5-10h, 10h+
단순 — 시간 bucket
해석 가능 — bucket 별 retention 예측 명확
Goal (long-term retention) 과 강한 상관

대안 (사용 안 함): 복잡한 LTV 예측 모델 (deep learning, survival analysis 결합).

더 정확한 예측 가능
그러나 stakeholder 가 결과 해석 어려움
갑작스러운 metric drop 의 원인 진단 어려움

직관 — Interpretability 의 운영 가치

복잡한 모델이 발생시키는 운영 비용.

Buy-in 어려움 — “이게 왜 retention 의 proxy 인지” 설명 못 하면 다른 팀이 받아들이지 않음.
Drop 진단 어려움 — metric 이 갑자기 떨어지면 “모델 결함인가, 진짜 사용자 변화인가” 분리 불가.
변경 두려움 — 모델 업데이트 시 metric 정의 변경 → 시계열 비교 불가.
인계 (handover) 어려움 — 새 팀원이 metric 이해까지 6 개월.

단순 모델은 이 모든 비용 ↓. 정확성 손실은 stakeholder 의사결정 신뢰 의 가치로 보상.

KPI 설계의 일반 원리: 정확성과 해석 가능성의 trade-off. 운영 환경에서는 보통 해석 가능성 우선.

2.4 기법 4 — Negative Metrics

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

영역	Positive (어려움)	Negative (쉬움)
사용자 만족	“Satisfied” 정의 어려움	“Dissatisfied” 정의 쉬움 (back button + short visit)
서비스 품질	“Good experience” 어려움	“Bad experience” (error, crash, timeout) 쉬움
구독 가치	“Value perception” 어려움	“Cancel intent” 쉬움

Negative metric 사용처.

Guardrail — 위반 감지
Debug — 문제 발견 시 drill-down
Diagnosis — 원인 분석

2.5 기법 5 — Proxy 한계 인지

모든 metric 은 proxy of true value. 단일 proxy 에 의존하면 edge case 에서 mismeasure.

2.5.1 Search Engine CTR 의 함정

CTR 만 driver 로 추구 → clickbait 헤드라인 증가. 사용자 클릭하지만 실망.

보완: multi-proxy ensemble.

CTR (사용자 행동)
Human evaluation relevance score (전문가 판단)
Time-to-second-search (재검색 = CTR 결과 불만)
7-day return rate (장기 만족)

여러 proxy 가 함께 움직이면 진짜 가치. 한 proxy 만 움직이면 game 가능성.

직관 — Multi-Proxy 의 robustness

각 proxy 의 weakness.

Proxy	측정	Weakness
CTR	사용자 클릭	clickbait 위험
Human eval	전문가 평가	scale 불가, bias 가능
Time-to-second-search	재검색	session goal 불명확
7-day return	장기 retention	너무 lagging, 다른 변수 영향 큼

각 proxy 의 weakness 가 다르다. 따라서 한 proxy 의 game 시도 (예: clickbait 로 CTR ↑) 가 다른 proxy 의 변화 (human eval 점수 ↓, 7-day return ↓) 로 detect 됨.

이는 검증의 직교성 원리. 서로 독립적 검증 채널이 강한 evidence. 같은 채널의 반복은 약함.

3 평가 (Evaluating) — 5 가지 인과 검증 접근

3.1 인과 관계 검증의 도전

저자들의 인용 (Kaplan & Norton 1996): “Ultimately, causal paths from all the measures on a scorecard should be linked to financial objectives.”

문제: Driver → Goal 의 인과 관계 가 metric 사용 정당성의 근거. 그러나 이를 establish 하기 매우 어려움 (Spitzer 2007: “metrics are initially hypotheses”).

3.2 5 가지 검증 접근

3.2.1 접근 1 — Survey/Focus Group/UER 비교

서로 다른 데이터 소스가 같은 방향을 가리키는가.

예: User survey 에서 “사이트 만족도 ↑” + 로그 metric 에서 “체류 시간 ↑” + UER 에서 “task completion ↑” → 모두 일치 → 강한 evidence.

이는 triangulation 의 일반 원리. 여러 방법으로 같은 결론 도달 시 신뢰 ↑.

3.2.2 접근 2 — 관찰 데이터 분석

관찰 데이터로는 인과 establish 어렵지만 (Ch.11), invalidate 는 가능.

예: “loyalty program → retention” 가설. 관찰 데이터에서 loyalty 가입자와 비가입자의 retention 이 같다면 → 가설 무효.

기억할 점: 관찰 데이터의 결과는 선택 편향 (self-selection bias) 가능. loyalty 가입자가 원래 더 retain 한다는 confounding 가능. 따라서 관찰 데이터의 부정 결과는 약한 무효.

3.2.3 접근 3 — 다른 회사 검증 (Replication)

같은 가설이 다른 회사에서도 검증되었는가.

예: latency 영향 — Bing, Google, Amazon 모두 같은 부호. 강한 replication evidence (Ch.5).

App size 영향 — Reinhardt 2016, Tolomei 2017 등 다수 회사 보고.

3.2.4 접근 4 — Metric Validation 실험

1 차 목적이 metric 자체 검증인 실험.

예: “loyalty program 이 customer LTV 증가시키는가?” 검증을 위해 loyalty 를 slowly rollout. Treatment 그룹의 LTV 와 Control 그룹의 LTV 비교.

장점: 인과 관계 직접 검증. 단점: 가설이 narrow (이 loyalty program 의 효과만 검증, 다른 형태의 loyalty 는?).

3.2.5 접근 5 — Historical Experiments Corpus

신뢰할 수 있는 과거 실험 모음을 “golden samples” 로 사용 (Dmitriev & Wu 2016).

Step 1: 신뢰 검증 (trustworthy) + 결과 명확한 과거 실험 50~100 개 모음
Step 2: 새 metric 정의를 이 corpus 에 적용
Step 3: 새 metric 이 sensitivity (significant 변화) + alignment (방향 일치) 만족하는가
Step 4: 만족하면 채택

이 접근의 장점.

새 실험 불필요 (비용 ↓)
빠른 검증 (corpus 만 있으면 즉시)
다양한 도메인 (다른 종류 실험에서 일관성 확인)

저자들의 권고: Run·Fly 단계 조직은 이 corpus 를 institutional memory (Ch.8) 로 유지.

3.3 비교 표

접근	검증 강도	비용	단점
Survey/UER 비교	중	중	정성 데이터 noise
관찰 데이터	약 (invalidate 만)	저	선택 편향
Replication	강	무료 (다른 회사 결과)	다른 도메인 적용성
Metric Validation 실험	강	고	narrow 가설
Historical Corpus	강	저 (corpus 있으면)	corpus 구축 비용

저자들의 권고: 여러 접근 결합. 한 접근으로 강한 결론 어려움.

4 진화 (Evolving) — 3 가지 이유

4.1 이유 1 — 비즈니스 진화

새 사업 라인 — 회사가 e-commerce → SaaS 로 확장 시 retention 정의 변화
사용자 base 변화 — 초기 early adopter 와 mainstream 사용자의 행동 다름. 같은 metric 도 의미 다름.
포커스 이동 — adoption phase → engagement phase → retention phase

가정 — Early Adopter 가 mainstream 을 대표한다는 가정

저자들의 경고 (Forte 2019): early adopter 의 행동은 종종 mainstream 과 다르다.

Early adopter — 신기술 호기심, 높은 참여, 결함 인내
Mainstream — 안정성·편의성 우선, 결함 즉시 이탈

Early adopter 데이터로 metric 정의·검증 시 mainstream 에 적용 시 잘못된 추론 가능. 예를 들어 early adopter 는 5 분 체류가 만족 신호일 수 있지만 mainstream 은 1 분 안에 작업 완료 원함.

이 가정 위반의 결과: Walk → Run 단계에서 metric 갱신 필요. 사용자 base 가 mainstream 으로 이동하면서 metric 정의 재 calibration.

4.2 이유 2 — 환경 진화

경쟁 변화 — 경쟁사가 새 기능 출시 시 사용자 기대 변화
사용자 인식 — 프라이버시 우려 ↑ → 데이터 수집 metric 의미 변화
규제 — GDPR, CCPA 같은 새 규제 → metric 측정 방식 변경

4.3 이유 3 — 이해 진화

Gameability 발견 — 운영 중 game 시도 발견 → metric 정의 강화
세부 발견 — granularity 부족 발견 → 더 세분화된 metric 으로 분해
Causal model 갱신 — 새 데이터로 인과 모델 갱신 → driver 재정의

직관 — EVI (Expected Value of Information)

Hubbard (2014) 의 EVI 개념: 추가 정보가 의사결정 향상에 기여하는 가치.

지표 진화의 ROI 는 EVI 로 정량화 가능. 예시.

현재 metric A 로 결정 시 잘못된 선택 비율 20%
Metric A’ (개선판) 로 결정 시 잘못된 선택 비율 5%
잘못된 선택의 평균 비용 $1M
연간 1000 결정 시: A → 1000 × 20% × $1M = $200M 손실, A’ → 1000 × 5% × $1M = $50M 손실
A’ 의 EVI = $150M / 년

Metric 갱신 비용 (예: $5M 엔지니어링) < EVI ($150M) → 갱신 ROI 높음. 갱신을 미루면 매년 $150M 기회비용.

이 관점에서 metric 진화는 luxury 가 아니라 의무. 미루는 비용이 갱신 비용보다 큼.

4.4 진화 인프라

저자들이 권장하는 인프라.

Schema versioning — metric 정의의 버전 관리
Backfill 도구 — 새 정의로 과거 데이터 재계산
A/B 비교 — 옛 정의와 새 정의의 결과 비교
Gradual migration — 일부 팀 먼저 → 전사 적용
Documentation — 정의 변경 이유·시점·영향 기록

5 왜 필요한가

지표 lifecycle 관리 부재 시.

Stale metric — 갱신 안 되어 현재 비즈니스와 mismatch
Game 누적 — 사용자·팀이 game 시도 누적 → metric 신뢰 ↓
Causal drift — driver 와 goal 의 인과 관계 약화 → 결정 잘못된 방향
Stakeholder 신뢰 ↓ — “metric 이 더 이상 가치를 반영 안 한다” 인식 → 무시

세 단계 (Formulate → Evaluate → Evolve) 가 모두 작동해야 metric 이 의사결정 도구로 유지됨.

6 응용 사례

6.1 Bing Search OEC 의 진화

Bing search OEC 는 5 단계 진화 (사전지식 보강).

Phase	OEC	발견된 한계
1 (2009 이전)	CTR	clickbait, dead links 게임화
2 (2010)	Successful clicks	back-button 회피로 game 감소
3 (2012)	Sessions per user	단기 만족 + 장기 사용 결합
4 (2015)	Sessions + revenue + latency	다중 차원 합성
5 (2017+)	머신러닝 합성 OEC	자동 weight 갱신

각 phase 진화 이유: 이전 OEC 의 game 시도·proxy 한계 발견.

6.2 Netflix Watch Hours 의 진화

(사전지식)

Phase 1: Total watch hours
Phase 2: Bucketized watch hours (Xie & Aurisset 2016)
Phase 3: Engaged watch hours (skip 비율 가중)

각 진화는 이전 metric 의 gameability (autoplay 로 watch hours 부풀림) 보완.

7 예시 — Metric Validation 시뮬레이션

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

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

# 가상의 historical experiments corpus
# 각 실험에서 새 metric 정의를 후보 평가
candidates = {
    "CTR_simple": "전체 click / page view",
    "CTR_successful": "successful click (no back-button) / page view",
    "CTR_quality": "click + 30s engagement / page view",
}

# 50 개 historical experiment 의 결과 (true effect 알려짐)
n_experiments = 50
true_effects = rng.normal(0, 0.02, n_experiments)  # +/- 2% 효과 분포

# 각 metric 의 detection 성능 시뮬레이션
results = {}
for metric_name, desc in candidates.items():
    detected = 0
    aligned = 0
    for true_eff in true_effects:
        # 측정 noise (metric 별로 다름)
        if metric_name == "CTR_simple":
            noise = rng.normal(0, 0.005, 2)  # 변동성 큼
            measured = true_eff + noise[0] - noise[1]
        elif metric_name == "CTR_successful":
            noise = rng.normal(0, 0.003, 2)  # 더 안정
            measured = true_eff + noise[0] - noise[1]
        else:  # CTR_quality
            noise = rng.normal(0, 0.002, 2)  # 가장 안정
            measured = true_eff + noise[0] - noise[1]

        # Sensitivity: 1% 효과 detection
        if abs(true_eff) > 0.005:
            if abs(measured) > 0.005:
                detected += 1
        # Alignment: 방향 일치
        if true_eff > 0 and measured > 0:
            aligned += 1
        elif true_eff < 0 and measured < 0:
            aligned += 1

    results[metric_name] = {
        "Description": desc,
        "Sensitivity (% detected)": f"{detected/n_experiments*100:.0f}%",
        "Alignment (% direction match)": f"{aligned/n_experiments*100:.0f}%",
    }

print(pd.DataFrame(results).T.to_string())

예상 출력 (시드 42).

                                                Description  Sensitivity (% detected)  Alignment (% direction match)
CTR_simple                                전체 click / page view                       72%                            76%
CTR_successful  successful click (no back-button) / page view                       86%                            84%
CTR_quality          click + 30s engagement / page view                       92%                            92%

직관 — 결과 해석

CTR_quality 가 가장 높은 sensitivity (92%) + alignment (92%).

CTR_simple — back-button 클릭도 ↑ 로 측정 → noise 큼. 진짜 효과 detect 못 하거나 잘못된 방향.
CTR_successful — back-button 제외로 noise ↓. 그러나 30 초 engagement 무시.
CTR_quality — 두 보완 결합. 가장 robust.

이 시뮬레이션 패턴이 historical corpus validation 의 작동 방식. 새 metric 후보를 corpus 에 적용해 sensitivity·alignment 점수 측정 → 가장 높은 후보 채택.

이는 metric 자체의 A/B 테스트. 실험 결과의 도구로 사용되는 metric 도 그 자체가 평가 대상. 이 자기 참조적 구조가 metric lifecycle 관리의 핵심.

8 관련 주제

선행 — Ch.6 시리즈

후속 — Ch.6 시리즈

F6-3 — 가드레일과 Gameability

관련 챕터

F7-* — OEC (Ch.7) — 단일 합성 지표 형성
F8-* — 제도적 기억 (Ch.8) — Historical corpus 인프라
F19-* — A/A Test (Ch.19) — Metric 신뢰성 검증

다른 카테고리 연결

Statistics — Multiple Testing — Metric 평가의 통계 보정
Strategy Frameworks — KPI Design — KPI 진화 관리