Kohavi Ch.4 개관 — 실험 플랫폼과 문화

성숙도 모델 · 리더십 · 인프라 4 컴포넌트 · 변종 배정 · 분석

Kohavi (2020) Ch.4 의 흐름을 한 편으로 압축한다. 4 단계 성숙도 모델 (Crawl/Walk/Run/Fly), 리더십과 프로세스, build vs buy 의사결정, 인프라 4 컴포넌트 (정의·배포·계측·분석), Single-Layer 와 Concurrent 변종 배정 방식까지 카테고리 진입점으로 지도화한다.

Experimentation
A/B Test
Platform
저자

Kwangmin Kim

공개

2026년 05월 08일

1 정의

정의: 실험 플랫폼 (Experimentation Platform)

실험 플랫폼은 가설 정의부터 무작위 배정, 데이터 수집, 통계적 분석까지 온라인 통제 실험의 전 과정을 셀프서비스화하고 신뢰성을 보장하는 사회·기술 시스템이다.

  • 사회적 측면: 성숙도 단계 (Crawl/Walk/Run/Fly), 리더십, 교육·리뷰 프로세스, 지적 정직성 문화
  • 기술적 측면: 4 컴포넌트 (정의·배포·계측·분석) + 변종 배정 방식 (Single-Layer / Concurrent)

플랫폼의 목표는 실험 1 건 추가의 한계 비용을 거의 0 에 가깝게 만드는 것이다 (Kohavi, Tang, Xu, 2020, Ch.4).

2 개념 및 원리

2.1 4 단계 성숙도 모델

Fabijan et al. (2017) 의 4 단계 모델은 조직이 데이터 기반으로 진화할 때 거치는 표준 경로를 정리한다. 각 단계는 그 단계가 해결하려는 문제가 다르고, 따라서 플랫폼이 제공해야 하는 기능도 다르다.

단계 연간 실험 핵심 목표 플랫폼 요구
Crawl ~10 계측 + 기본 통계 역량 + “성공 사례 몇 건” 가설 검정용 요약 통계 계산
Walk ~50 표준 지표 정의 + 실험 다수 실행 + 신뢰 확보 A/A 테스트, SRM 검사, 계측 검증
Run ~250 실험 대규모 운영 + OEC 코드화 + 트레이드오프 명시 자동 분석, 다중 검정, 세그먼트화
Fly ~수천 모든 변경의 기본값 = 실험 + 자동화 + 제도적 기억 자동 ramping, NRT alerting, 메타분석

다음 단계로 진입할 때마다 실험 빈도는 약 5 배씩 증가한다 (10 → 50 → 250 → 수천). 이는 단순한 양적 증가가 아니라 조직의 의사결정 단위 자체가 “기능 출시” 에서 “지표 변화” 로 바뀌는 질적 전환이다.

5 배라는 숫자의 직관

왜 하필 5 배일까? 이 숫자는 임의의 경험치가 아니라 인지 부담의 분수령 이다.

  • 1/주 (Walk) 는 실험자가 머릿속에 모든 실험을 기억할 수 있는 한계
  • 1/일 (Run) 은 데이터 사이언티스트 1 명이 hands-on 으로 분석할 수 있는 한계
  • 수/일 (Fly) 은 자동화 없이는 인간이 처리 못 하는 양

각 단계 전환은 “도구 부족 → 도구 도입” 의 모멘트다. 빈도가 5 배 늘어나도 인력이 5 배 늘어나는 것이 아니라, 자동화가 인지 부담을 흡수 한다. 단계 전환의 본질은 “더 많이 한다” 가 아니라 “같은 인력으로 5 배 효율” 의 자동화 도입 이다.

만약 자동화 없이 빈도만 늘리면 어떻게 될까? 신뢰 검증을 건너뛴 실험이 누적되고, 잘못된 결과 위에 출시 결정이 쌓이며, 최종적으로 “데이터 기반” 이라는 라벨만 남고 실질은 무작위 결정이 된다. 이것이 Walk → Run 전환에서 가장 흔한 실패 패턴이다.

직관 — 왜 단계별로 플랫폼 요구가 달라지는가

Crawl 단계는 “실험 1 건이 동작한다” 가 목표이므로 hard-coded 분석 스크립트로도 충분하다. Walk 단계는 “결과를 믿을 수 있는가” 가 핵심이라 A/A·SRM 같은 진단 도구가 필요해진다. Run 단계는 “여러 지표·세그먼트를 동시에 본다” 가 일상이라 다중 검정 보정과 자동 분석이 없으면 실험자 1 인당 분석 시간이 비례 폭증한다. Fly 단계는 “실험 자체가 의식되지 않을 만큼 자연스럽다” 가 목표라 자동 ramping·alerting 으로 인지 부담을 줄여야 한다.

플랫폼을 단계별 진단 없이 한 번에 짓겠다고 하면, Crawl 인 조직이 Fly 용 자동화에 자원을 쏟는 비대칭 투자가 발생한다. Kohavi 가 “단계별 기능 우선순위” 를 강조하는 이유다.

2.2 리더십 — HiPPO 에서 측정 문화로

저자들은 조직이 실험을 도입할 때 거치는 인식론적 단계를 다음과 같이 정리한다.

  1. Hubris (자만) — HiPPO (Highest Paid Person’s Opinion) 에 의존. 측정 불필요론.
  2. Measurement and Control (측정·통제) — 핵심 지표를 추적하기 시작. 그러나 여전히 Semmelweis Reflex (검증된 사실도 기존 패러다임과 충돌하면 거부) 의 영향이 강하다.
  3. Fundamental Understanding (근본 이해) — 인과 모형이 실제로 작동하고, 조직이 “데이터가 직관을 이긴다” 는 사실을 학습한다.

3 단계로 진입하려면 리더십이 다음을 실천해야 한다.

  • 목표 지표·가드레일·OEC 합의 — 트레이드오프를 코드화 (Ch.7)
  • “기능 X·Y 출시” 가 아니라 “지표 P 개선” 이 목표가 되도록 KPI 재설계
  • 권한 위임 + 가드레일 — 팀이 핵심 지표를 자유롭게 개선하되, 가드레일을 위반하면 자동 차단
  • 실험 결과 리뷰 의무화 — p-hacking 방지, 해석 표준화
  • 실패에 대한 humility — 대부분의 아이디어는 실패한다는 것을 받아들인다
  • 고위험·고보상 vs 점진 개선의 포트폴리오 균형
  • 장기 학습 — 출시 결정뿐 아니라 ROI·전략 수립에도 실험을 사용한다 (예: Bing-Facebook 통합을 2 년 실험 후 무가치하다고 판단해 폐기)
  • 짧은 릴리즈 주기 — 빠른 피드백 루프를 위한 민감 surrogate 지표 (Ch.7) 와 결합
왜 리더십이 결정적인가

플랫폼·도구만 제공하고 인센티브 구조를 바꾸지 않으면, 실험은 “출시 결재용 도장” 으로 전락한다. 실험자가 결과를 cherry-pick 해서 출시 승인을 받으면, 조직 전체가 통계적 유의성을 학습하기보다 유의해 보이게 만드는 기술을 학습한다 (Goodhart 법칙의 메타 적용). 리더십의 의미 있는 commitment 가 없으면 Crawl 에서 Walk 로 넘어가지 못한다.

2.3 프로세스 — Just-in-Time 교육과 리뷰

저자들은 모든 실험자에게 통계 교육을 강제하는 대신 체크리스트와 리뷰 미팅을 통한 점진적 학습을 권장한다. Google Search 의 사례:

  • 설계 시 체크리스트 — “가설은? 측정하려는 효과 크기는?” 같은 기본 질문부터 검정력 분석까지 포함. 검정력 계산은 자동화 도구 링크로 위임.
  • 분석 리뷰 미팅 — 전문가가 결과를 확인하기 전에 신뢰성 검증 (계측 오류·SRM) 을 먼저 본다. 그 후 출시 권고로 진입.
  • 메타 학습 — 유사 실험들의 패턴을 모아 메타 분석 (Ch.8) → 지표 정의 업데이트.

조직이 충분히 성숙하면 (Late Walk ~ Run) 명시적 체크리스트는 사라지고 문화로 흡수된다.

2.4 Build vs Buy — Walk 단계의 ROI 의사결정

외부 솔루션 vs 자체 구축은 단순 비용 비교가 아니라 궤적과 통합 요건의 함수다.

평가 항목 외부 솔루션이 약한 경우 자체 구축이 필요한 신호
실험 유형 JS 기반 → 백엔드/모바일 미지원 서버·클라이언트 양면 필요
사이트 속도 추가 JS 로딩으로 지연 발생 지연 자체가 핵심 지표 (Ch.5)
지표 자유도 세션화·percentile 미지원 복합 지표·tail latency 필요
무작위 단위 사용자 식별자 외부 전송 제약 프라이버시 (Ch.9) 강제
데이터 통합 외부 데이터 join 불가 구매·반품·인구통계 통합 필요
실시간성 일 단위 결과 NRT 로 bad experiment 조기 차단
제도적 기억 미지원 메타 분석·재실험 기능 필요
최종 구현 WYSIWYG 으로 임시 구현 실험 코드 = 프로덕션 코드

저자들의 권고는 궤적 (anticipated growth) 이 외부 솔루션 한계를 넘어설 가능성 이 있고 configuration·deployment 시스템과의 깊은 통합 (Ch.15) 이 필요하면 self-build 로 간다. 그렇지 않으면 외부 솔루션으로 ROI 를 검증한 후 build 결정을 미룬다.

2.5 Infrastructure — 4 컴포넌트

Bing (Kohavi et al. 2009), LinkedIn (Xu et al. 2015), Google (Tang et al. 2010) 의 플랫폼은 모두 다음 4 컴포넌트로 분해된다.

        ┌──────────────────────────────────┐
        │ 1. Definition / Set-up / Mgmt    │  ← UI/API + 실험 사양 저장
        │    (소유자·기간·지표·iteration) │
        └────────────────┬─────────────────┘
                         │
                         ▼
        ┌──────────────────────────────────┐
        │ 2. Deployment                    │  ← Variant Assignment Service
        │    (서버/클라이언트 양쪽)        │     + 프로덕션 코드 변경
        └────────────────┬─────────────────┘
                         │
                         ▼
        ┌──────────────────────────────────┐
        │ 3. Instrumentation               │  ← 사용자 행동 + variant·iteration
        │    (counterfactual 포함)         │     + 시스템 성능 로깅
        └────────────────┬─────────────────┘
                         │
                         ▼
        ┌──────────────────────────────────┐
        │ 4. Analytics                     │  ← processing → computation
        │    (자동 분석 + 신뢰성 검증)     │     → visualization
        └──────────────────────────────────┘

각 컴포넌트의 핵심 의무.

  • Definition — 실험 사양 작성·편집·draft 비교, ID 자동 할당, 타겟팅 검증, 권한 분리 (시작은 owner, 중지는 누구나). Fly 단계에서는 자동 ramping, NRT alerting, bad experiment 자동 차단까지 확장.

  • Deployment — variant assignment service. 사용자 ID 의 의사난수 해시 \(f(\text{ID})\) 로 결정적·독립적 배정 (Ch.14). atomicity 보장 (parent service 가 한 번 배정 후 child 에 전파). 배포 아키텍처는 3 가지로 분류된다 (다음 절).

    직관 — 왜 hash 함수인가, 그냥 random() 으로는 안 되는가

    \(f(\text{ID})\) 의 핵심 속성은 결정성 (deterministic) + 균등성 (uniform) 의 동시 보장이다.

    • 결정성: 같은 사용자가 같은 실험에 항상 같은 variant 로 배정된다. 일반 random() 은 호출 때마다 다른 값을 반환하므로, 사용자가 페이지를 새로고침할 때마다 처치가 바뀌어 버린다. 이러면 인과 효과 추정 자체가 불가능하다 (사용자별 처치가 정의되지 않음).
    • 균등성: hash 결과가 0~999 buckets 에 거의 동일한 확률로 분포한다. 분포가 편향되면 Treatment / Control 그룹 크기 자체가 달라져 SRM 이 발생한다.

    MD5·SHA-1 같은 cryptographic hash 는 두 속성을 모두 보장한다. 단순 user_id % 1000 은 결정적 이지만 균등성이 깨질 수 있다 (예: user_id 가 짝수만 발급되면 홀수 bucket 은 비어 버린다). 현실의 ID 분포는 종종 sequential·clustered 이므로 hash 가 필수다.

    이 메커니즘은 인과 식별 가정 (SUTVA, ignorability) 을 시스템 차원에서 강제 하는 도구다. 통계적 가정을 사람의 의지가 아닌 코드로 보장한다.

  • Instrumentation — variant·iteration 함께 로깅. counterfactual logging (예: Treatment 사용자에게 Control 의 검색 결과는 무엇이었을지 함께 기록) 은 Ch.20 triggering 분석에 필수이지만 비용이 크다.

  • Analytics — data cooking → metric/p-value 계산 → visualization. 신뢰성 검증을 가장 먼저 본다. 그 후 OEC → 세그먼트 → 메타 분석.

2.6 배포 아키텍처 3 종

variant 가 결정된 후 코드가 어떻게 분기하느냐에 따라 3 가지 패턴.

아키텍처 코드 형태 장점 단점
1. Code Fork if (variant == T) ... else ... variant 결정이 코드 변경 지점에 가까움 → triggering 자연스러움 분기 코드 부채 누적
2. Parameterized buttonColor = variant.getParam(...) 코드 부채 ↓, triggering 여전히 쉬움 모든 변경을 파라미터로 추상화해야 함
3. Early Assignment + Config buttonColor = config.getParam(...) 성능 (캐시 가능), 파라미터 천 개 규모 확장 triggering 어려움 (assignment 가 멀리 떨어짐)

Google 은 1 → 3 으로 전환했고, Bing 은 3 을 사용. Microsoft Office 는 2 의 변형 (bug ID 를 파라미터로 전달, 3 개월 후 제거 alert) 을 사용한다 (Kohavi, Tang, Xu, 2020, Ch.4).

2.7 변종 배정 — Single-Layer vs Concurrent

플랫폼 확장의 본질은 한 사용자가 동시에 몇 개의 실험에 참여할 수 있는가 이다.

2.7.1 Single-Layer (Numberline)

전체 트래픽을 1000 개 disjoint bucket 으로 나누고 각 실험에 bucket 범위를 할당. 한 사용자는 한 실험에만 참여한다.

사용자 UID → f(UID) % 1000 = m_i

| Control | T1   | T2   | Control | T   |
| 노랑    | 파랑 | 초록 | 추천 on | off |
| m1-200  |201-400|401-600|601-800 |801-1000|
  • 장점: 단순, 구현 쉽다. Walk 단계 적합.
  • 단점: 동시 실험 수가 트래픽으로 제한된다 (예: 1000 buckets, 각 실험 200 buckets 필요 → 최대 5 개). carryover effect (이전 실험의 잔재) 를 막으려면 매 실험마다 bucket 재셔플 필요.

2.7.2 Concurrent (Overlapping)

여러 layer 를 두고 각 layer 가 Single-Layer 처럼 작동. variant assignment 시 layer ID 를 해시 입력에 포함시켜 layer 간 직교성 보장. 한 사용자가 layer 수만큼의 실험에 동시 참여.

3 가지 설계 변형.

  • Full Factorial — 모든 실험이 직교 layer. 단순·확장 쉬움. 단점: 충돌 가능 (Exp1: 텍스트 파랑 + Exp2: 배경 파랑 → 가독성 0). Microsoft 는 자동 상호작용 탐지 (Kohavi et al. 2013) 로 보완.
  • Nested — 시스템 파라미터를 layer 로 분할. UI 헤더 / 본문 / 백엔드 / ranking 등. 같은 layer 내 실험은 같은 사용자에 동시 노출 안 됨.
  • Constraints-Based — 실험자가 충돌 제약을 선언, 시스템이 graph-coloring 으로 해결. Google·LinkedIn·Microsoft·Facebook 이 nested 또는 constraints-based 의 변형 사용 (Tang et al. 2010, Bakshy et al. 2014).
직관 — 왜 layered overlapping 이 필수인가

조직이 일주일에 100 개 실험을 돌리는 Run 단계라면, Single-Layer 로는 트래픽이 부족하다. 사용자 1 명에게 동시에 5~10 개 실험을 노출시켜야 한다. 이때 핵심 위험은 상호작용 (interaction effect) 이다. 실험 A 에서 측정한 효과가 실험 B 에 의해 오염되면, 두 실험 모두 결과를 잘못 해석하게 된다.

Nested·Constraints-Based 설계의 본질은 “사용자에게 동시 노출하면 안 되는 실험들을 미리 선언” 하는 것이다. 이는 실험 설계의 통계학적 문제 (직교성·교란) 를 시스템 설계의 자료 구조 문제 로 번역한 결과이다.

3 왜 필요한가

플랫폼·문화 인프라 없이 개별 실험만 잘 돌리면 다음 함정에 빠진다.

  • 분석 자체가 비싸다 — 매 실험마다 ad-hoc 분석. 결국 실험 빈도가 제한된다.
  • 신뢰성 검증 누락 — A/A·SRM 을 매번 수동 실행하면 검증 비율이 시간 경과에 따라 떨어진다. 잘못된 결과 위에 의사결정이 누적된다.
  • 인스티튜셔널 메모리 부재 — 같은 가설을 여러 팀이 독립적으로 다시 검증한다 (낭비). 실패한 실험에서 학습이 쌓이지 않는다.
  • HiPPO 회귀 — 데이터가 모호한 영역 (저신뢰·작은 표본·논쟁적 결과) 에서 결정자는 결국 자신의 직관으로 회귀한다. 표면적으로는 데이터 기반, 실제로는 자만 단계.

플랫폼은 이 모든 비용을 반복 가능한 자동화 로 변환한다. Bing·Google·LinkedIn 의 사례 (Figure 4.1) 는 “플랫폼 성숙 후 4 년간 실험 빈도가 한 자릿수 → 다섯 자릿수 (수만/년)” 로 증가했음을 보여준다.

4 응용 분야

도메인 Maturity 단계 플랫폼 핵심 기능
검색 엔진 (Bing, Google) Fly nested overlapping, NRT alerting, counterfactual logging
소셜·전문 네트워크 (LinkedIn, Facebook) Fly constraints-based, edge-level interference 분석
Office Suite (Microsoft Office 2017~) Run → Fly 안전 배포 메커니즘으로 controlled experiment 사용
스타트업·중견 기업 Crawl → Walk 외부 솔루션 (Optimizely, AB Tasty 등) + 자체 분석
의료·임상 (RCT) 단발 실험 플랫폼보다 SOP·CONSORT 표준화 우선 (Ch.9 윤리·Ch.21 SRM 의 임상 변형)

플랫폼 도입의 진입점은 Walk 단계의 신뢰 도구 (A/A·SRM) 다. 이 도구를 외부 솔루션에서 자체 구현으로 옮기는 시점이 build 결정의 분기점이 된다.

5 예시 — Single-Layer 무작위 배정 + SRM 검사

다음 코드는 Single-Layer 방식으로 1000 buckets 에 사용자를 배정하고, 결과 SRM (Sample Ratio Mismatch) 을 검사하는 최소 구현이다. 실제 플랫폼은 carryover 방지를 위해 실험 ID 를 해시 입력에 포함시키고 매 실험마다 bucket 재셔플한다.

import hashlib
import numpy as np
import pandas as pd
from scipy.stats import chisquare

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

# 사용자 ID 와 실험 ID 결합 → bucket 결정성·재셔플 동시 달성
def assign_bucket(user_id: int, exp_id: str, n_buckets: int = 1000) -> int:
    key = f"{exp_id}:{user_id}".encode()
    h = hashlib.md5(key).digest()
    return int.from_bytes(h[:8], "big") % n_buckets

# 가상의 사용자 트래픽
users = pd.DataFrame({"user_id": rng.integers(0, 10**9, N)})
users["bucket"] = users["user_id"].map(lambda u: assign_bucket(u, exp_id="exp_001"))

# 실험 사양: Control 0~199 (20%), T1 200~399 (20%), 나머지는 다른 실험
def variant_of(b: int) -> str:
    if b < 200:
        return "Control"
    if b < 400:
        return "Treatment"
    return "Other"

users["variant"] = users["bucket"].map(variant_of)
ab_users = users[users["variant"].isin(["Control", "Treatment"])]
counts = ab_users["variant"].value_counts()
print(counts)

# SRM 검사: 기대 비율 50/50 (둘 다 200 buckets) vs 관측
expected = np.array([len(ab_users) / 2, len(ab_users) / 2])
observed = np.array([counts["Control"], counts["Treatment"]])
chi2, p = chisquare(observed, expected)
print(f"Chi-square = {chi2:.3f}, p = {p:.4f}")
# p < 0.001 이면 SRM. 배정 알고리즘 또는 트리거링 로직에 결함 의심.

이 코드는 Walk 단계 플랫폼이 매 실험에 자동 적용해야 하는 최소 진단의 골격이다. SRM 가 탐지되면 effect size 추정 자체가 신뢰할 수 없다 (Ch.21 에서 상세).

직관 — chi-square 통계량은 무엇을 측정하는가

위 코드의 chi-square 통계량은 다음과 같이 정의된다.

\[\chi^2 = \sum_{i} \frac{(O_i - E_i)^2}{E_i}\]

여기서 \(O_i\) 는 관측 빈도 (Control·Treatment 각 그룹의 실제 사용자 수), \(E_i\) 는 기대 빈도 (설계상 50/50 이면 전체의 절반) 다. 직관적으로 “관측이 기대에서 얼마나 멀리 떨어졌는지” 를 \(E_i\) 로 정규화한 거리다.

  • \(\chi^2 \approx 0\) — 관측이 기대와 거의 같다 → 배정 정상
  • \(\chi^2\) 큼 — 관측이 기대에서 멀다 → 50/50 가정 위반 (SRM)

왜 단순 차이 \(|O_i - E_i|\) 가 아니라 \(E_i\) 로 나누는가? 표본 크기에 따른 자연 변동을 보정 하기 위함이다. 100 만 사용자 실험에서 49.99% / 50.01% 의 분할은 정상 변동 안이지만, 100 명 실험에서 같은 비율은 측정 오차일 수 있다. \(E_i\) 분모가 표본 크기 효과를 흡수한다.

p < 0.001 이면 “이 정도 불균형이 우연일 확률 0.1% 미만” 을 의미. 즉 시스템 결함이 거의 확실. 구체적 원인 — bot traffic, redirect 시 데이터 누락, hash 함수 결함, 트리거링 로직 비대칭 — 은 Ch.21 에서 다룬다.

6 관련 주제

선행 지식

Ch.4 후속 (이 시리즈)

다음 챕터 (Phase F)

다른 카테고리 연결

Subscribe

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