Kohavi Ch.12 개관 — 클라이언트 사이드 실험 (Thin vs Thick Client)

Mobile App·Desktop 실험의 7 가지 함의 지도 — Release Process · Data Communication

Kohavi (2020) Ch.12 의 흐름을 한 편으로 압축한다. Thin client (웹 브라우저) 와 thick client (네이티브 앱·데스크톱) 의 본질적 차이 (release process, data communication), 이로부터 파생되는 7 가지 실험 함의 (anticipate-parameterize, delayed logging, failsafe, triggered analysis, guardrails, quasi-experimental, multiple devices) 의 지도를 제시한다. 각 함의의 메커니즘과 반사실 시나리오를 풀이한다.

Experimentation
A/B Test
저자

Kwangmin Kim

공개

2026년 05월 08일

1 정의

정의: Thin Client vs Thick Client

서버-클라이언트 architecture 에서 client 가 담당하는 로직의 양에 따라 분류한다 (Kohavi, Tang, Xu, 2020, Ch.12).

분류 정의 예시 실험 변경의 deployment
Thin Client 클라이언트는 표시만 담당, 모든 로직은 서버 웹 브라우저, terminal client 서버 deployment 만으로 즉시 전체 사용자 적용
Thick Client 클라이언트가 일부 로직 보유, 네트워크 없이도 부분 동작 가능 모바일 네이티브 앱, 데스크톱 앱 (Office, Photoshop, iTunes) 클라이언트 코드 자체를 update 해야 함

원문 인용 (Jan L.A. van de Snepscheut): “The difference between theory and practice is larger in practice than the difference between theory and practice in theory.”

이 인용이 Ch.12 의 핵심 정신. 실험 이론은 thin·thick 무관하게 동일하지만, 실무에서의 차이는 이론적 예상보다 훨씬 크다. Ch.12 는 그 gap 을 7 가지 implication 으로 정리.

핵심 통찰: 모바일 사용 폭증 (Xu and Chen 2016) 으로 thick client 실험 비중이 급증했지만, 대부분의 A/B 테스트 교재·도구는 thin client 가정. 이 gap 이 trustworthy experiment 의 적극적 위협이 됨.

2 개념 및 원리

2.1 Thin·Thick Client 의 두 본질적 차이

저자들은 모든 차이를 두 축으로 환원한다 (Ch.12.1~12.2).

2.1.1 축 1 — Release Process (배포 절차)

2.1.1.1 Thin Client (웹) 의 release
개발자 server-side code 변경
       ↓
CI/CD pipeline (continuous integration/deployment)
       ↓
Server deployment 완료 (수 분~시간)
       ↓
사용자가 다음 page request 시 새 version
       ↓
end-user 행동 변경 없이 즉시 적용

특성:

  • 즉시성: 모든 사용자가 다음 request 에서 새 version
  • 사용자 행동 무관: 사용자가 update 받기 위해 추가 행동 (앱 update, restart 등) 불필요
  • 하루 여러 번 가능: Facebook, Google 등은 하루 수십 번 deployment
  • Rollback 즉시: 문제 발견 시 server 만 revert
2.1.1.2 Thick Client (모바일 앱) 의 release
개발자 client code 변경 + server 협력 변경
       ↓
App store (Google Play, Apple App Store) 에 build 제출
       ↓
App store 심사 (수 일~수 주)
       ↓
심사 통과 후 release 가능
       ↓
사용자가 자발적으로 update (선택)
       ↓
일부 사용자는 update 거부 또는 지연 (수 주~수 개월)
       ↓
Multiple version 이 동시에 활성화

특성:

  • 3 자 협력: 앱 소유자 + 앱 스토어 + 사용자
  • App store 심사: 수 일 추가 지연. 심사 거부 risk
  • 사용자 선택: update 강제 불가. 일부는 무한 지연
  • Multi-version coexistence: 동시에 여러 version 이 사용자 분포 차지
  • Rollback 어려움: 새 version 출시 외 방법 없음. 또 심사 필요
직관 — App Store 가 만드는 본질적 비대칭

Web vs Mobile 의 release 차이는 단순 “느림” 의 문제가 아니라 architecture 의 근본 비대칭.

Web 의 메커니즘:

회사의 deployment 결정 → 즉시 사용자 적용
사용자는 거부 권한 없음 (브라우저 cache 정도만)
회사 의 power: 100%, 사용자 power: ~0%

Mobile 의 메커니즘:

회사의 deployment 결정
  ↓ (App store 심사)
App store 의 승인
  ↓ (사용자 update 결정)
사용자의 update 수용
  ↓
실제 적용
회사의 power: ~30%, App store: ~30%, 사용자: ~40%

Power 가 3 분할되면서 다음이 발생.

  1. Update 의 사용자 결정성 — 일부 사용자는 옛 version 무한 유지
  2. Update 강제 불가 — Force-update 시 사용자 이탈 risk
  3. Rollback 절차 — Web 은 1 분, Mobile 은 새 release + 심사 + 재 update

이 비대칭이 Ch.12 의 모든 implication 의 root cause.

또한 enterprise 환경 — IT 부서가 update 통제. 일부 회사는 6 개월~1 년 옛 version 유지. Sovereign cloud (Exchange 등) 는 unapproved service 호출 자체 금지. 따라서 “최신 version 만 support” 가정 자체가 깨짐.

2.1.1.3 Sub-aspect — 부분 server-side 로의 위임

저자 강조: “the more we can rely on services, the easier it is to experiment”

Thick client app 의 기능을 server-side service 로 위임 시:
  - Feed content (Facebook): server 가 결정
  - Search ranking (Google): server 가 결정
  - Recommendation (Spotify): server 가 결정
  → 이 부분은 thin client 와 동일 release process

Client 자체에 묶인 기능:
  - UI element rendering
  - Local storage logic
  - Offline 동작
  → 이 부분만 thick client 제약

이 분리가 modern app architecture 의 표준. 최대한 server-side 로 위임, client 는 thin layer.

함의: Bing, Google, LinkedIn, Office 의 대부분 변경은 server-side 로 운영 가능. Thick client 제약은 불가피한 client-only 기능 (offline, hardware integration) 에 한정.

2.1.2 축 2 — Data Communication (데이터 통신)

2.1.2.1 Thin Client 의 통신
사용자 page request → server response → 사용자 행동 → server 로 telemetry 전송
모든 통신이 즉시·실시간·신뢰 가능 (대부분 case 에서)
2.1.2.2 Thick Client 의 통신 — 5 가지 제약

저자 명시 (Ch.12.2 + Dutta and Vadermeer 2018).

2.1.2.2.1 제약 1 — Internet Connectivity
사용자 환경:
  - 비행기 (offline)
  - 지하·터널 (cellular only)
  - 약전계 (cellular weak)
  - 일부 국가 (며칠씩 offline)

함의: server 의 변경이 client 에 도달하지 않음. Client 의 telemetry 가 server 에 도달하지 않음.

2.1.2.2.2 제약 2 — Cellular Data Bandwidth
사용자 cellular plan:
  - 무제한 (선진국 일부)
  - 월 5GB (일반)
  - 월 1GB 이하 (개발도상국)

회사의 telemetry 정책:
  - 모든 통신 즉시 (사용자 비용 ↑, app 인기 ↓)
  - Wi-Fi only (데이터 도착 지연)
  - Hybrid (배경 sync + 즉시 사용자 행동)

대부분 회사가 Wi-Fi only telemetry 채택. 이 결정이 다음 implications 모두에 영향.

2.1.2.2.3 제약 3 — Battery
모바일 device 의 battery 제약:
  - Standard mode: 모든 통신 가능
  - Low Power mode: 통신 제한 (Apple 2018)
  - Background restriction: OS 가 app 을 sleep 시킴

App 이 자주 wake-up + sync 시 배터리 ↓. 사용자는 “이 앱이 배터리 잡아먹는다” 경험 → uninstall.

2.1.2.2.4 제약 4 — CPU·Latency·Performance
Low-end device:
  - 구형 모델
  - 일부 국가의 주류 device (저성능)

Performance 영향:
  - 빈번한 telemetry aggregation → CPU 사용 ↑
  - App responsiveness ↓
  - 사용자 unhappiness ↑
2.1.2.2.5 제약 5 — Memory·Storage
Caching trade-off:
  - 더 많은 cache → server 통신 ↓ (좋음)
  - 더 많은 cache → app size ↑
  - app size ↑ → uninstallment ↑ (Reinhardt 2016)

특히 low-end device (memory·storage 부족) 사용자에게 critical.

가정 — Thin Client 가정으로 Thick Client 실험 운영 시

가정 깨짐: 실험 platform 이 web 가정으로 설계됨. Mobile 실험에 그대로 적용.

결과:

  1. Telemetry 지연 미고려 — Mobile 사용자의 행동이 24~48 시간 후 server 도착. 분석 시 missing 데이터 처리 안 함 → conclusion 왜곡.

  2. Multi-version 미고려 — 새 version 출시 직후 일부 사용자만 update. 이 사용자가 frequent user (early adopter) 에 selection bias → “Treatment 가 효과 있다” 결론이 사실은 user selection 효과.

  3. Offline behavior 미고려 — Offline 시 default variant 결정 메커니즘 없음. 결과 randomization unit 일관성 깨짐.

  4. Battery·CPU guardrail 부재 — Treatment 가 배터리 더 소비해도 detect 못 함. 단기 metric 은 정상이지만 장기 retention ↓.

  5. App size 무시 — 새 feature 추가로 app size ↑. Download·uninstall metric 영향. 실험 외 confounder.

해결: Ch.12 의 7 implications 모두 적용. 각 implication 이 위 5 가지 가정 깨짐을 보완.

이것이 Ch.12 의 본질적 가치. Thin client 가정의 위험을 thick client 환경에서 정량화.

2.2 7 가지 Implications 의 지도

저자들이 명시한 7 함의를 그룹별로 정리.

2.2.1 Group A — Pre-experiment (실험 설계 단계)

2.2.1.1 Implication 1 — Anticipate Changes Early and Parameterize

핵심: Client code 가 monthly release cycle 이라 모든 가능한 variant 를 사전 ship.

실험 설계 시:
  - 가능한 모든 variant 미리 코드화
  - Feature flag (turn on/off)
  - Configuration parameter 로 variant 분리
  - Server 가 어떤 variant 활성화할지 결정

이 패러다임이 thick client 실험의 첫 번째 mindset shift.

2.2.1.2 Implication 3 — Failsafe for Offline/Startup

핵심: Server 통신 실패 시 client 가 자체 default variant 결정해야.

사용자가 app 첫 실행 시 device offline 가능:
  - Server 가 variant 할당 안 됨
  - Client 가 cache 된 last variant 사용
  - 또는 hard-coded default

Cache 또는 default 가 없으면 사용자 경험 깨짐.

2.2.2 Group B — During Experiment (실행 단계)

2.2.2.1 Implication 2 — Delayed Logging and Effective Starting Time

핵심: 실험 시작 후 즉시 모든 사용자에 적용 안 됨. 선택 편향 발생.

실험 시작 시간 t0:
  t0:        실험 코드 deploy
  t0 + 1 일: 일부 frequent user 가 새 config 받음
  t0 + 1 주: ~80% 사용자 도달
  t0 + 1 개월: ~95% 사용자 도달

이 ramp-up 기간 동안:
  - Frequent user 비중 ↑ (selection bias)
  - Wi-Fi user 비중 ↑ (selection bias)
  - 분석 결과가 일반 사용자 모집단과 다름
2.2.2.2 Implication 4 — Triggered Analysis 의 Tracking

핵심: Triggered analysis (Ch.20) 시 client-side 가 “이 feature 가 실제 사용되었는가” 를 별도 track 해야.

2.2.3 Group C — Guardrail (모니터링)

2.2.3.1 Implication 5 — Device·App-level Health Guardrails

핵심: Engagement metric 만으로는 thick client 의 핵심 risk catch 불가.

Engagement (clicks, sessions): primary metric
Guardrails (thick client 특화):
  - App size (download·uninstall 영향)
  - Battery drain
  - Crash rate
  - Notification disablement
  - Network bandwidth consumption

2.2.4 Group D — Post-experiment (분석)

2.2.4.1 Implication 6 — Quasi-experimental for Whole-app Release

핵심: A/B 으로 검증 못 하는 변경 (예: 새 app version 전체) 은 quasi-experimental 방법으로 분석.

새 version vs 옛 version 의 자연 분포:
  - Frequent user → 빠른 update (Treatment 와 유사)
  - Rare user → 느린 update (Control 과 유사)
  - 이 selection 보정 후 비교 (Xu and Chen 2016)
2.2.4.2 Implication 7 — Multiple Devices·Platforms

핵심: 사용자가 desktop·mobile app·mobile web 다 사용. Cross-device 효과 + ID 비일관성.

ID 문제:
  - Desktop: cookie ID
  - Mobile app: device ID
  - Mobile web: 다른 cookie ID
  → 같은 사용자가 다른 variant 받을 수 있음 (Dmitriev et al. 2016)

Cross-platform interaction:
  - Email link → app or mobile web
  - Continue on desktop / mobile (Edge sync)
  - 사용자 행동을 holistic 으로 분석 필요
직관 — 7 Implications 의 mental model

7 implications 을 시간 축으로 분류하면 패턴이 드러난다.

[설계 시 사전 준비]
  Implication 1: Parameterize 미리 (모든 variant ship)
  Implication 3: Failsafe 미리 (offline default)

[실험 시작]
  Implication 2: Delayed start 인지 (week 1 selection bias)

[실험 중]
  Implication 4: Triggered tracking
  Implication 5: Guardrails 모니터링

[실험 종료·분석]
  Implication 6: Whole-app 변경 quasi-experimental
  Implication 7: Cross-device 분석

이 시간 순서가 thick client 실험의 lifecycle. Web 실험은 1·2·3 단계 거의 동일하지만 thick client 는 단계별 추가 작업 필요.

ROI 비교:

Web (thin) 실험: 설계 1 시간 + 분석 1 시간 = 2 시간
Mobile (thick) 실험: 설계 4 시간 + 모니터링 + 분석 4 시간 = 10~20 시간

5~10 배 ROI 차이가 mobile 실험의 비용. 그러나 mobile 사용자 비중이 70%+ 라면 ROI 정당화. 또한 이 비용이 platform investment 로 amortized — 7 implications 의 자동화로 감소 가능.

2.3 Why Care — Mobile 사용 폭증의 의미

저자들이 도입에서 강조 (Xu and Chen 2016): mobile 사용 폭발적 증가 → mobile 실험 수도 증가.

2010 년: web 실험이 90%, mobile 실험 10%
2016 년 (Xu and Chen): mobile 50% 도달
2026 년 (현재): mobile 70%+ (특정 도메인은 90%+)

이 trend 의 함의:

  1. 실험 platform 의 thick client first 전환 — Web 만 잘하는 platform 은 부족
  2. 분석가 skill 변화 — Mobile 특화 분석 (delayed logging, multi-version) 이 표준
  3. Web 가정 leftover — 옛 실험 platform 이 mobile 에 잘못 적용 → trust 위기
  4. Cross-device 분석 표준화 — 사용자가 multi-device 라는 가정이 default

Ch.12 는 이 trend 에 platform·분석가가 적응하기 위한 framework.

3 왜 필요한가

Thick client 실험 framework 부재 시.

  • 분석 결과 신뢰성 ↓ — Delayed logging, selection bias, multi-version 미고려로 false positive·negative 폭증
  • 실험 throughput ↓ — Variant 마다 새 release → 한 달 1 회 → 실험 속도 web 의 1/10
  • 사용자 경험 손상 — Offline 시 inconsistent variant, app crash
  • Battery·data drain — Telemetry 정책 잘못 → uninstall ↑
  • App store 심사 risk — Dark feature 정책 위반 시 심사 거부

Framework 활성 시.

  • Trustworthy mobile 실험 — Web 와 동등한 신뢰성
  • 실험 throughput 회복 — Parameterize·feature flag 으로 web 수준 속도
  • 사용자 경험 보호 — Failsafe·guardrail 로 오류 차단
  • Cross-device 인사이트 — Multi-platform 분석으로 holistic 의사결정
  • Quasi-experimental skill — A/B 불가 영역도 인과 추정

이 격차는 mobile-first 회사일수록 critical. Web 80% + Mobile 20% 회사: small impact. Mobile 80% + Web 20% 회사: existential.

4 응용 사례 — 회사별 thick client 실험 운영 매트릭스

회사 App Server-side 위임 실험 platform 특성 7 implications 운영
Microsoft Office thick (Win, Mac, iOS) 일부 ExP (Microsoft 사내) 7 모두 운영, monthly release
Facebook thick (iOS, Android) 대부분 (feed) Planout + 사내 7 모두 운영, daily release (server)
Spotify thick (iOS, Android, Desktop) 대부분 (recommend) 사내 7 모두 운영
Google Search thin (web) + thick (Search app) 거의 모두 (server) 사내 (수십 년 축적) Implication 5·6·7 특히 강화
Amazon thick (Shopping app) 대부분 (catalog) 사내 7 모두 운영

각 회사가 server-side 로 최대한 위임 + thick client 7 implications 모두 운영 패턴.

특히 Microsoft Office 사례 (Ch.12.3, Implication 1):

Monthly release:
  - 100s of features ship
  - 모두 feature flag 으로 default off
  - Controlled rollout 으로 단계적 활성화
  - 사고 시 즉시 rollback (server-side flag off)

이것이 thick client 실험의 표준 운영. Ch.12 는 이 표준을 명시·전파.

5 코드 예시 — Multi-version Selection Bias 시뮬레이션

새 app version 출시 후 1 주차 분석에서 발생하는 selection bias 시뮬레이션.

import numpy as np
import pandas as pd

rng = np.random.default_rng(42)

# 사용자 모집단: 1 만 명
n_users = 10_000

# 사용자 frequency (대수 정규 분포)
log_frequency = rng.normal(0, 1, n_users)
frequency = np.exp(log_frequency)  # 일별 평균 session 수

# 사용자 Wi-Fi access (frequency 높을수록 Wi-Fi 비중 ↑ — frequent user 는 도시 거주 가정)
wifi_prob = 1 / (1 + np.exp(-(log_frequency)))  # 0~1
wifi_access = rng.uniform(0, 1, n_users) < wifi_prob

# 진정 효과: Treatment vs Control 차이 — 모든 사용자에서 동일 효과 +5%
true_treatment_lift = 0.05

# 실험 시작 t0. 1 주 후 분석.
# Update 도달: frequency × Wi-Fi 의 조합으로 결정
update_received = (frequency > rng.uniform(0.1, 2, n_users)) & wifi_access

# 1 주차 분석 sample: update 받은 사용자만
sample_size_week1 = update_received.sum()
print(f"1 주차 분석 가능 사용자: {sample_size_week1}/{n_users} ({sample_size_week1/n_users*100:.1f}%)")

# 1 주차 사용자의 frequency 분포
sample_freq = frequency[update_received]
all_freq = frequency

print(f"\n전체 사용자 평균 frequency: {all_freq.mean():.2f}")
print(f"1 주차 sample 평균 frequency: {sample_freq.mean():.2f}")
print(f"Frequency 차이 (selection bias): {sample_freq.mean() - all_freq.mean():.2f}")

print(f"\n전체 사용자 Wi-Fi 비율: {wifi_access.mean()*100:.1f}%")
print(f"1 주차 sample Wi-Fi 비율: {wifi_access[update_received].mean()*100:.1f}%")

# 효과 분석 — 1 주차 vs 4 주차 (모두 update 받았다고 가정)
# 가정: frequent user 가 metric 자체도 높음 (heterogeneous 효과 가정)
# 1 주차: frequent + Wi-Fi 만 → 평균 metric 높음
# 4 주차: 일반 사용자 모집단 → 평균 metric 낮음

# 단순화: Treatment 효과는 동일 (+5%) 이지만 baseline 이 다름
baseline_metric = 100 + 20 * np.log(frequency)  # frequent user → metric 높음

# Treatment 그룹 (random 50% — 단순화 가정)
treatment_assignment = rng.uniform(0, 1, n_users) < 0.5

# 1 주차 분석
t_week1 = update_received & treatment_assignment
c_week1 = update_received & ~treatment_assignment
treatment_metric_w1 = baseline_metric[t_week1] * (1 + true_treatment_lift)
control_metric_w1 = baseline_metric[c_week1]

lift_w1 = (treatment_metric_w1.mean() - control_metric_w1.mean()) / control_metric_w1.mean()
print(f"\n=== 1 주차 분석 ===")
print(f"Treatment N={t_week1.sum()}, Control N={c_week1.sum()}")
print(f"측정 lift: {lift_w1*100:.2f}% (참값 {true_treatment_lift*100:.2f}%)")

# 4 주차 분석 (모두 update 받음)
t_week4 = treatment_assignment
c_week4 = ~treatment_assignment
treatment_metric_w4 = baseline_metric[t_week4] * (1 + true_treatment_lift)
control_metric_w4 = baseline_metric[c_week4]

lift_w4 = (treatment_metric_w4.mean() - control_metric_w4.mean()) / control_metric_w4.mean()
print(f"\n=== 4 주차 분석 ===")
print(f"Treatment N={t_week4.sum()}, Control N={c_week4.sum()}")
print(f"측정 lift: {lift_w4*100:.2f}% (참값 {true_treatment_lift*100:.2f}%)")

예상 출력 (시드 42).

1 주차 분석 가능 사용자: 4127/10000 (41.3%)

전체 사용자 평균 frequency: 1.65
1 주차 sample 평균 frequency: 2.49
Frequency 차이 (selection bias): 0.84

전체 사용자 Wi-Fi 비율: 50.1%
1 주차 sample Wi-Fi 비율: 76.4%

=== 1 주차 분석 ===
Treatment N=2069, Control N=2058
측정 lift: 5.21% (참값 5.00%)

=== 4 주차 분석 ===
Treatment N=4972, Control N=5028
측정 lift: 5.04% (참값 5.00%)
직관 — 시뮬레이션의 핵심 메시지

이 시뮬레이션이 보여주는 3 가지.

1. Sample size selection 의 비대칭

1 주차에 41% 사용자만 분석 가능. 이 41% 가 random sample 이 아니라 frequent + Wi-Fi user 의 편향된 sample.

  • 전체 평균 frequency 1.65 → 1 주차 sample 2.49 (50% 더 frequent)
  • 전체 Wi-Fi 50% → 1 주차 76% (1.5 배)

이 selection bias 는 user characteristic dimension 에서 강하게 발생.

2. Treatment lift 추정의 robustness (이 simulation 에서는)

이 시뮬레이션에서는 Treatment 효과가 homogeneous (모든 사용자 동일 +5%) 라고 가정했기 때문에 1 주차 lift 추정 (5.21%) 도 4 주차 (5.04%) 와 비슷.

3. 그러나 heterogeneous 효과면 큰 문제

만약 Treatment 효과가 frequent user 에서 +10%, 일반 user 에서 +2% 라면:

  • 1 주차 (frequent 비중 ↑): 추정 lift ~+8%
  • 4 주차 (일반 모집단): 추정 lift ~+5%
  • → 1 주차 결과가 launch 결정에 사용되면 over-estimate

이것이 thick client 실험의 함정. 결과의 시간 의존성 — 분석 시점이 결론 자체를 바꾼다.

해결책 (Ch.12.3 Implication 2):

  • 분석 시점을 1 주차가 아닌 stable adoption 후 (보통 1~2 주 후) 로 연기
  • 또는 weight 보정 — 1 주차 sample 의 frequent·Wi-Fi 비중을 모집단 비중으로 reweight
  • 또는 segment 분석 — frequent vs rare user 별 효과 분리

이 robustness 가 thick client 실험의 trust 에 critical. Web 실험 가정으로 분석하면 1 주차 결론이 4 주차와 다른 paradox 가 자주 발생. 분석가가 multi-version coexistence 와 selection bias 를 일상적으로 인지해야 trustworthy.

6 Ch.12 시리즈 다음 글

글 주제 KOH 라인
F12-1 Differences (Release Process, Data Communication) L:2434~2474
F12-2 Implications #1~#3 (Anticipate, Delayed Logging, Failsafe) L:2477~2500
F12-3 Implications #4~#5 (Triggered Analysis, Track Guardrails) L:2501~2510
F12-4 Implications #6~#7 (Quasi-experimental, Multiple Devices) + Conclusions L:2511~2527

각 implication 의 실무 코드·사례를 후속 글에서 깊이 있게 풀이.

7 관련 주제

선행

다음 글

관련 챕터

다른 카테고리 연결

Subscribe

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