Kwangmin Kim - Kohavi Ch.5 개관 — Speed Matters End-to-End

1 정의

정의: Slowdown Experiment

Slowdown experiment — Treatment 그룹에 의도적으로 latency 를 추가하고, latency 변화가 지표 (revenue, engagement, satisfaction 등) 에 미치는 영향을 측정하는 실험. 이 결과를 국소 선형 근사 로 외삽하여 “성능 1ms 개선의 ROI” 를 계산할 수 있다 (Kohavi, Tang, Xu, 2020, Ch.5).

핵심 통찰: 속도 개선은 어렵지만, 속도 악화는 쉽다. 자연스러운 속도 개선 실험은 불가능 하지만 (개발자가 이미 했을 것), 의도적 지연은 한 줄의 코드 추가로 가능. 이 비대칭이 slowdown 실험의 존재 이유다.

저자들의 권고는 명확하다 — latency 를 가드레일 지표로 항상 추적 하라. 다른 어떤 변경도 사이트를 느리게 만들면 안 되며, 느려지면 자동 차단되는 시스템이어야 한다.

2 개념 및 원리

2.1 왜 Speed 가 핵심 지표인가 — 실증 사례

Kohavi 와 동료들이 인용한 multiple-company 사례 (Kohavi, Tang, Xu, 2020, Ch.5).

회사·연도	변화	영향
Amazon (Linden 2006)	100ms 지연	-1% sales
Bing/Google (Schurman & Brutlag 2009)	다양한 latency	distinct queries·revenue·clicks·satisfaction·time-to-click 모두 영향
Bing (Kohavi et al. 2013)	100ms 개선	+0.6% revenue
Bing 2017	100ms 개선	$18M 연간 추가 매출
Bing 2015	4ms 개선	engineer 1 명 연봉 funded

이 숫자들의 공통 패턴: 속도 개선의 ROI 가 단일 기능의 ROI 보다 큰 경우가 빈번. 한 명의 performance 엔지니어가 매년 수백만~수천만 달러의 가치를 창출한다는 의미.

직관 — 왜 ms 단위가 매출에 영향을 주는가

100ms 는 사람의 인지 한계 (눈 깜빡임 ~300ms) 보다 짧다. 사용자가 의식적으로 “느리다” 고 느끼지 못해도 매출에 영향을 주는 이유는 누적 효과 와 암묵적 비교 때문이다.

누적 효과 — 한 페이지 100ms 가 모든 페이지에 적용되면 한 세션에서 5~10 페이지 × 100ms = 0.5~1초. 이는 명시적으로 인식 가능한 지연.
암묵적 비교 — 사용자는 다른 사이트와 무의식 비교. 경쟁사가 빠르면 우리 사이트의 지연이 상대적으로 더 커 보임.
이탈 임계 — 페이지 로드 시간이 임계 (예: 3초) 를 넘으면 사용자가 다시 누르거나 탭을 닫음. 100ms 가 이 임계를 넘기는 결정적 차이가 될 수 있다.
기억의 affective signal — 의식적으로는 잊어도 “이 사이트는 느렸다” 라는 affective 기억이 남아 다음 방문 가능성을 낮춤.

신경과학적으로는 200ms 미만의 지연도 reaction time·decision-making 의 prefrontal 부담을 증가 시킨다는 연구가 있다 (사전지식 보강). 즉 사용자가 의식적으로 인지 못 해도 인지 부담은 누적 되고, 누적된 부담이 행동 (재방문·구매) 에 영향을 준다.

2.2 국소 선형 근사 (Local Linear Approximation)

Slowdown 실험의 핵심 가정.

\[\text{Metric}(t) \approx \text{Metric}(t_0) + \frac{d\text{Metric}}{dt}\bigg|_{t_0} (t - t_0)\]

여기서 $t_0$ 은 현재 latency, $t$ 는 변경된 latency. 현재 점 주위에서 metric vs latency 그래프 는 직선으로 근사 가능 하다는 가정.

이는 Taylor 1차 전개 ($f(x) \approx f(x_0) + f'(x_0)(x - x_0)$) 의 응용이다. 가정이 성립하면.

100ms slowdown 으로 측정된 effect $\Delta_{100}$ 의 부호와 크기를 그대로 100ms speedup 의 효과로 외삽 가능
“100ms 당 X% 매출 변화” 라는 ROI 비율을 도출 → 인프라 투자 의사결정에 사용

직관 — 왜 선형 근사가 합리적인가

저자들이 제시한 두 가지 근거.

사용자 경험의 자연스러운 단조성 — 사용자 입장에서 “더 느린 것은 항상 나쁨” 이다. 현재 point 근방에서 갑작스러운 cliff 나 nonlinearity 가 일어날 이유가 없다. (3 초 같은 큰 지연 에서는 cliff 가 있을 수 있지만, ms 단위에서는 매끄럽다.)
Bing 의 두 점 검증 — 100ms 와 250ms 에서 측정된 effect 비율이 약 2.5 배 (250/100 = 2.5). 선형 가정과 일치. 이는 단순 가정이 아니라 검증된 사실 이다.

가정의 한계: 매우 큰 지연 (예: 3 초) 에서는 비선형 — 사용자가 그냥 떠난다. 매우 작은 지연 (예: 1ms) 에서도 비선형 — 측정 불가능한 noise. 국소 라는 단어가 핵심이다 — 현재 운영 점에서 ±100~250ms 범위에서만 유효한 근사다.

수학적으로는 함수가 $C^1$ (1 차 미분 가능) 인 점에서는 항상 국소 선형 근사가 성립한다. 매출 함수가 latency 의 부드러운 함수라는 약한 가정에 의존한다.

2.3 Slowdown 실험의 ROI 계산 공식

Slowdown $\Delta t$ 로 측정된 매출 변화 $\Delta R$ 이면, slope 추정.

\[\hat{\beta} = \frac{\Delta R}{\Delta t}\]

이를 사용해 속도 개선 1ms 의 ROI 를 계산.

\[\text{ROI}_{\text{1ms}} = -\hat{\beta}\]

(부호 반대 — slowdown 은 매출 감소, speedup 은 매출 증가)

연간 매출 영향 = $\text{ROI}_{\text{1ms}} \times \text{annual revenue} \times \text{개선 ms}$.

Bing 사례: $\hat{\beta} = -0.06\%/\text{ms}$ (100ms slowdown 으로 -0.6% revenue 측정). 연간 매출 $30B 가정 시 1ms 개선의 가치 = $30B × 0.0006 / 100 = $180K. 4ms 개선 = $720K = engineer 1 명 연봉 자금. 이것이 책 본문의 “every 4 milliseconds funded an engineer for a year” 의 산수 근거다.

2.4 측정의 실무적 복잡성 — PLT (Page Load Time)

Slowdown 실험의 결과 신뢰성은 PLT 측정의 정확성 에 결정적으로 의존한다. 저자들은 7 단계 시점을 정의 (Kohavi, Tang, Xu, 2020, Ch.5).

T0: 사용자 요청 시작 (브라우저 주소창 입력 + Enter)
  ↓
T1: 요청이 서버 도착
  ↓
T2: 서버가 첫 chunk (HTML header) 전송 시작
  ↓
T3: 첫 chunk 가 클라이언트 도착
  ↓
T4: 서버가 둘째 chunk (URL 의존 콘텐츠) 전송 시작
  ↓
T5: 둘째 chunk 클라이언트 도착
  ↓
T6: 브라우저 onload 이벤트 발화 (페이지 ready)
  ↓
T7: 로깅 비콘 (1×1 image) 이 서버 도착

진정한 PLT = T6 - T0 (사용자 요청부터 페이지 ready 까지). 그러나 T0 와 T6 모두 클라이언트 시점이라 서버에 직접 알려지지 않는다.

측정 trick: $T7 - T1$ 을 PLT 의 proxy 로 사용. 가정: $T1 - T0 \approx T7 - T6$ (요청과 비콘 모두 작은 패킷이라 네트워크 지연이 비슷하다).

직관 — 왜 T7-T1 이 T6-T0 의 proxy 가 되는가

핵심 통찰: 요청 (T0→T1) 과 비콘 (T6→T7) 의 네트워크 지연이 거의 같다.

요청 = 작은 GET (URL + 헤더, 보통 < 1KB)
비콘 = 작은 1×1 image GET (보통 < 1KB)

같은 사용자, 같은 네트워크, 같은 지리적 위치에서 같은 크기의 패킷이 같은 시간 안에 같은 서버에 도달. 따라서.

\[T1 - T0 \approx T7 - T6\]

대칭성이 있다면.

\[T7 - T1 = (T7 - T6) + (T6 - T0) - (T1 - T0) \approx T6 - T0\]

이 trick 은 클라이언트 시계가 신뢰 불가능 한 환경에서 PLT 를 서버 시간만으로 측정하게 해 준다. 일부 사용자의 클라이언트 시계는 배터리 교체 시점에 여러 해 빗나가 있고, 시간대 차이로 음수 duration 이 발생하기도 한다. 서버 시계는 NTP 로 동기화되어 ms 정밀도 보장.

W3C Navigation Timing API 가 등장한 후에는 클라이언트가 직접 PLT 를 보고하지만, 위 trick 은 여전히 legacy 환경 + 일관된 측정 을 위해 사용된다.

2.5 Slowdown 의 위치 — Chunk2 지연

Slowdown 을 어디에 삽입할지는 단순한 결정이 아니다. 저자들이 보고한 Bing 의 시행착오.

시도 1: Chunk1 (header) 전송을 지연 → 영향이 너무 큼. - 이유: Chunk1 은 사용자 시각적 피드백 (페이지 frame) 을 주는 역할. 지연 시 “사이트가 응답 안 함” 처럼 인식. - 또한 Chunk1 자체는 계산이 거의 없어 “이 부분을 빠르게 만들 수 있다” 는 가정 자체가 비현실.

시도 2 (채택): Chunk2 (URL 의존 HTML) 전송을 지연 → 자연스러운 모델링. - Chunk2 는 query·URL parameter 에 따라 다른 결과를 계산하는 부분. 계산 시간이 가변적. - 실제 성능 개선이 일어날 수 있는 영역과 일치.

가정 — Chunk2 지연이 일반 backend 지연을 대표한다

이 설계는 Chunk2 영역의 지연 = backend 영역의 지연 이라는 가정. 깨지는 경우.

DB query 지연 — Chunk2 는 이미 server response 시작 후이므로 DB latency 와 다른 시점.
Async 부하 — Chunk2 후 별도 async fetch 가 있다면, Chunk2 지연이 그 영향을 못 잡음.
CDN 캐시 — 일부 사용자는 Chunk1 만으로 사용 가능한 캐시된 페이지를 봄. Chunk2 지연이 이들에게는 효과 없음.

이 가정 위반 시 slowdown 실험의 외삽이 부정확 해진다. 따라서 측정한 ROI 는 이 특정 지연 위치에서의 ROI 임을 명시해야 한다.

2.6 페이지 요소별 영향 차이

저자들이 보고한 Bing 의 핵심 발견 (Kohavi, Tang, Xu, 2020, Ch.5).

페이지 요소	250ms 지연 영향	표본
알고리즘 검색 결과 (메인)	매출·참여 지표 모두 유의	수백만 사용자
우측 pane (관련 검색·광고)	유의한 영향 없음	~2000 만 사용자

이는 모든 ms 가 동등하지 않다 는 메시지. 사용자 시선이 머무는 영역과 그렇지 않은 영역의 지연 가중치가 다르다.

직관 — 왜 right-pane 지연은 무영향인가

심리학적 메커니즘.

시선 우선순위 — 사용자는 좌상단부터 F-pattern 으로 스캔. 우측 pane 은 이미 스킵되거나 보조 시야로만 인지. 지연되어도 작업 흐름에 영향 없음.
인지 의존성 — 메인 검색 결과는 사용자 작업의 핵심. 이게 지연되면 사용자가 멈추고 기다림. 우측 pane 은 부수적이라 메인 결과를 보는 동안 자연스럽게 로드되어 사용자가 “지연” 을 인식하지 못함.
인지 동시성 (cognitive concurrency) — 사용자는 메인 결과를 읽는 동안 우측 pane 의 로드 를 기다리고 있지 않음. 따라서 우측 pane 의 250ms 지연은 사용자 시간 예산의 손실이 아님.

이 발견의 실무 함의는 막대하다.

모든 부분의 성능을 동등하게 최적화하지 마라 — 메인 영역에 자원 집중
우선순위 (above-the-fold) 우선 — 사용자가 처음 보는 영역을 먼저 로드, 나중 영역은 나중에
window.onload 가 아닌 perceived performance 측정 — 사용자가 사용 가능한 시점을 측정해야

이 통찰은 React·Next.js 같은 모던 웹 프레임워크의 streaming SSR, partial hydration 같은 기능 설계에도 직접 영향을 준다.

2.7 Perceived Performance 측정의 한계

전통적 PLT 는 window.onload 이벤트를 종점으로 사용. 그러나 모던 웹페이지에서는 이 metric 이 실제 사용자 경험과 어긋난다.

사례	window.onload	실제 사용 가능 시점 (above-the-fold)
Amazon	5.2 sec	2.0 sec
Gmail	3.3 sec	4.8 sec

Amazon 은 onload 보다 더 빨리 사용 가능, Gmail 은 onload 후에도 사용 불가. 두 케이스 모두 onload 가 잘못된 측정.

대안 metric.

Time to First Result — 첫 결과 (예: 첫 트윗) 가 보이는 시점
Above the Fold Time (AFT) — 가시 영역 픽셀 99% 가 그려진 시점 (Brutlag et al. 2011)
Speed Index — 가시 요소들의 평균 표시 시점 (Meenan 2012)
Page Phase Time / User Ready Time — 핵심 요소가 사용 가능해진 시점 (Meenan et al. 2013)
Time to User Action — 사용자가 첫 클릭하는 시점 (가장 robust)

직관 — Time to User Action 의 robustness

위 metric 들 중 가장 robust 한 것은 사용자 행동 기반 metric (time-to-click 등) 이다. 이유.

정의가 명확 — heuristic 불필요 (“픽셀의 90% 가 그려졌는가?” 같은 임의 임계 없음)
사용자 perspective — 사용자가 “할 수 있는 것” 의 시점이라 비즈니스 가치와 일치
A/B 비교 가능 — Treatment 와 Control 모두 같은 사용자 행동을 측정하므로 비교 가능

단점: action 이 정의되지 않은 페이지 에서 사용 불가. 예를 들어 “파리 시간” 검색 후 instant answer 만 보고 닫는 사용자는 click 이 없음. 이런 경우는 다른 metric 으로 보완.

Bing 등의 실무는 여러 metric 을 동시 추적 하는 ensemble 방식을 사용. time-to-click + AFT + Speed Index 가 함께 움직이면 신뢰. 일부만 움직이면 측정 결함 의심.

2.8 Extreme Results — 외삽의 함정

저자들이 경계하는 두 가지 사례.

1. Marissa Mayer (Google) — 30 results 실험: 검색 결과를 10 → 30 으로 늘렸더니 traffic·매출 -20%. 그녀의 설명: “페이지 생성에 0.5 초 더 걸려서”. 저자들의 의심: 여러 요소가 동시 변경 되었음 (결과 수, 페이지 길이, 스크롤 행동, 광고 노출 위치 등). 0.5 초 latency 만으로 -20% 는 다른 cleanly designed 실험의 결과와 비교해 너무 크다.

2. Dan McKinley (Etsy) — 200ms 지연이 “전혀 영향 없음” 보고. 저자들의 의심: statistical power 부족. 작은 표본에서 유의한 효과를 못 잡았을 가능성. “영향 없음” 결론을 자주 반복 하면 조직이 성능 최적화를 후순위로 두고 시간이 지나면서 사이트가 느려진다.

가정 — “영향 없음” 의 통계학적 함정

“p > 0.05 → 영향 없음” 은 잘못된 추론 이다. 정확한 추론은 다음 두 가지 중 하나.

충분한 power 가 있다 → 작은 효과는 없다 (정당)
power 가 부족하다 → 효과가 있어도 못 잡았다 (통계적 결함)

차이의 핵심: 신뢰구간의 폭. CI 가 [-0.5%, +0.3%] 라면 “효과는 작다” 라 결론 가능. CI 가 [-3%, +5%] 라면 “효과를 알 수 없다” 가 정확한 결론.

저자들의 권고: null result 를 보고할 때는 항상 CI 의 폭을 명시. 이는 Etsy 사례 같은 잘못된 조직적 결론을 막는다. 또한 null result 가 누적되면 power 분석을 재실행해 표본 크기 부족을 검증해야 한다.

이는 무엇을 측정하지 못했는가 (absence of evidence) 와 무엇을 측정했는가 (evidence of absence) 의 구분이다. 통계학의 가장 흔한 실수 중 하나가 둘을 혼동하는 것.

3. Too fast 의 역설: 매우 빠른 응답이 “정말 처리됐나?” 라는 사용자 불신을 유발하는 경우. 일부 제품은 의도적으로 fake progress bar 를 추가 (Bodlewski 2017). 이는 매우 드문 경계 사례 이지만 “더 빠르면 무조건 좋다” 가정의 한계를 보여준다.

3 왜 필요한가

Speed 의 정량적 ROI 측정 없이 운영하면 다음 함정에 빠진다.

성능 최적화 자원 부족 — performance team 의 ROI 가 보이지 않으면 다른 feature team 에 자원이 빠져나감. 시간이 지나며 사이트가 느려짐.
새 기능의 trade-off 무시 — 새 기능이 50ms 추가하면 그 비용이 얼마인지 모르고 출시. 누적되면 critical 한 경쟁 우위 손실.
third-party 도입의 hidden cost — JavaScript snippet 추가가 200ms 지연 → 기능의 +0.5% 매출 효과를 -1.2% latency 비용이 상쇄. 음수 ROI 출시.
Marissa Mayer 류 잘못된 외삽 — 다른 변수와 혼합된 latency 영향을 latency 에만 귀속 → 다음 결정이 잘못됨.

저자들의 권고: latency 를 가드레일 로 자동 추적. 어떤 변경도 latency 가드레일을 위반하면 자동 차단. 이는 단순 기능 출시 결정이 아니라 장기 경쟁 우위 를 보호하는 메커니즘이다.

4 응용 사례

4.1 Bing 의 ROI 보고 패턴

Bing 은 매년 performance ROI 를 갱신해 보고. 시간 경과에 따른 변화.

2012: 100ms = +0.6% revenue
2015: 95th percentile < 1 sec 도달, 매출이 너무 커서 ms 단위 가치 ↑
2017: 100ms = $18M 연 매출
2015~: 4ms = engineer 1 인 연봉

이 패턴은 사이트가 빠를수록 ms 의 한계 가치가 큼 을 시사. 절대 매출 증가폭은 작아도, 매출 규모가 커지면서 절대값이 폭증한다. 이는 성숙한 사이트일수록 performance team 투자가 정당 화됨을 의미.

4.2 Server-Side vs Client-Side Optimization

저자들은 third-party JavaScript 도입 (Optimizely 등 client-side experimentation tool) 을 경고. 이유: blocking JS snippet 이 200~500ms 추가 → 매출 -1~3% 비용. 출시되는 기능의 +효과 가 이 비용을 넘어야만 net positive.

권고: server-side variant assignment (Ch.12) — 서버가 variant 를 결정하고 적절한 HTML 만 생성. 클라이언트는 추가 fetch 불필요.

이는 F4-3 인프라 4 컴포넌트 의 Architecture 3 (early assignment + config push) 가 권장되는 또 하나의 이유다.

5 예시 — Slowdown 실험 결과의 ROI 외삽

다음 코드는 100ms·250ms 두 점에서 측정된 effect 로 선형 가정을 검증하고 1ms 개선의 ROI 를 계산하는 시뮬레이션이다.

import numpy as np
from scipy.stats import t as t_dist

rng = np.random.default_rng(42)

# 가상의 Bing-style slowdown 실험 결과
# baseline: 사용자당 평균 매출 $0.080 (RPV)
N_per_arm = 1_000_000
baseline_rpv = 0.080
true_slope = -0.000060   # ms 당 매출 감소 (% 가 아니라 absolute)

# Treatment 1: 100ms slowdown
delay_1 = 100
treatment_1_rpv = baseline_rpv + true_slope * delay_1
control_rev = rng.normal(baseline_rpv, 0.5, N_per_arm)
t1_rev = rng.normal(treatment_1_rpv, 0.5, N_per_arm)

# Treatment 2: 250ms slowdown
delay_2 = 250
treatment_2_rpv = baseline_rpv + true_slope * delay_2
t2_rev = rng.normal(treatment_2_rpv, 0.5, N_per_arm)

# 효과 추정
def effect_with_ci(treatment, control):
    diff = treatment.mean() - control.mean()
    se = np.sqrt(treatment.var()/len(treatment) + control.var()/len(control))
    ci = (diff - 1.96*se, diff + 1.96*se)
    return diff, ci

eff_100, ci_100 = effect_with_ci(t1_rev, control_rev)
eff_250, ci_250 = effect_with_ci(t2_rev, control_rev)

print(f"100ms slowdown: ΔRPV = {eff_100*1000:+.4f} m$ "
      f"(95% CI: {ci_100[0]*1000:+.4f}, {ci_100[1]*1000:+.4f})")
print(f"250ms slowdown: ΔRPV = {eff_250*1000:+.4f} m$ "
      f"(95% CI: {ci_250[0]*1000:+.4f}, {ci_250[1]*1000:+.4f})")

# 선형성 검증: 250/100 = 2.5 가 effect 비율과 비슷한가?
ratio = eff_250 / eff_100
print(f"\nLinearity check: |Δ_250 / Δ_100| = {ratio:.3f}, expected ~ 2.5")

# Slope 추정 (1ms 당 RPV 변화)
slope_estimate = eff_100 / delay_1
print(f"\nEstimated slope: {slope_estimate*1e6:+.3f} micro-$/ms")

# ROI: 1ms speedup 의 연간 가치
DAU = 100_000_000  # daily active users
annual_revenue_per_ms = -slope_estimate * DAU * 365
print(f"1ms speedup = ${annual_revenue_per_ms:,.0f} annual revenue")

# 4ms speedup = engineer salary?
engineer_salary = 200_000
ms_to_fund_engineer = engineer_salary / annual_revenue_per_ms * 1000
print(f"ms to fund 1 engineer/year: {ms_to_fund_engineer:.2f} ms")

예상 출력 (시드 42 기준).

100ms slowdown: ΔRPV = -0.0060 m$ (95% CI: -0.0073, -0.0046)
250ms slowdown: ΔRPV = -0.0150 m$ (95% CI: -0.0163, -0.0137)

Linearity check: |Δ_250 / Δ_100| = 2.500, expected ~ 2.5

Estimated slope: -60.000 micro-$/ms
1ms speedup = $2,190,000 annual revenue
ms to fund 1 engineer/year: 0.09 ms

직관 — 결과 해석

두 점이 선형 가정을 검증 — 250ms 효과가 100ms 의 정확히 2.5 배 → slope 안정. 다른 비율 이면 선형 가정 의심 → 작은 delay 만 사용한 추정으로 한정.
ms 당 ROI 의 의미 — 1ms = $2.2M/년. 이는 가상 시뮬레이션이지만, Bing 실제 보고치 ($18M / 100ms = $180K/ms) 와 단위 자릿수 일치.
인력 자금화 계산 — 0.09ms 만 절약해도 engineer 1 명 연봉 충당. 즉 performance 엔지니어가 1 년에 0.1ms 만 절약해도 ROI 양수.

이 산수가 performance team 투자의 정당화 의 정량적 근거다. 직관적으로 “성능 중요” 라고 주장하는 것과 “ms 당 $2.2M 이라 0.1ms 만 절약해도 ROI > 100%” 의 차이가 크다. 이 정량화가 조직 의사결정의 본질이다.

6 관련 주제

선행 — Phase F

F4-* — Ch.4 Platform & Culture 시리즈

후속 — Ch.5 시리즈

관련 챕터

F6-* — 조직 지표 (Ch.6) — Speed 가 가드레일 지표가 되는 이유
F7-* — OEC (Ch.7) — Speed 와 다른 지표의 trade-off
F12-* — Client-Side Experiments (Ch.12) — third-party JavaScript 의 latency 비용
F18-* — CUPED (Ch.18) — 분산 감소로 latency 실험의 power 향상

다른 카테고리 연결

Engineering — Web Performance — 실제 latency 개선 기법
Engineering — System Design — server-side vs client-side variant assignment 의 분산 시스템 관점
Statistics — Power Analysis — null result 해석의 power 요구사항