Kwangmin Kim - 국소 선형 근사와 사이트 속도 측정

1 정의

정의: 국소 선형 근사 (Local Linear Approximation)

국소 선형 근사는 매끄러운 함수 \(f(x)\) 를 한 점 \(x_0\) 주위에서 직선으로 근사하는 방법이다. Taylor 전개의 1 차 항만 사용한다.

\[f(x) \approx f(x_0) + f'(x_0) \cdot (x - x_0)\]

Slowdown 실험에서 이 근사를 사용하는 이유.

\(x\) = 페이지 로드 latency, \(f(x)\) = 매출 (또는 다른 지표)
\(x_0\) = 현재 운영 latency (예: 1000 ms)
측정 대상: \(f'(x_0)\) — 1ms latency 변화당 매출 변화율

이 slope \(f'(x_0)\) 를 알면 모든 ms 단위의 ROI 를 외삽할 수 있다 (Kohavi, Tang, Xu, 2020, Ch.5.1).

근사가 정당화되는 조건: 1. 함수 \(f\) 가 \(C^1\) (1 차 미분 가능) — 수학적 조건 2. \(x\) 가 \(x_0\) 에서 충분히 가까움 — 실용적 조건 3. 함수가 부드럽게 변함 — discontinuity 없음

2 개념 및 원리

2.1 Taylor 1차 전개의 수학적 의미

\(f(x)\) 의 Taylor 전개 (점 \(x_0\) 주위) 는.

\[f(x) = f(x_0) + f'(x_0)(x - x_0) + \frac{f''(x_0)}{2!}(x - x_0)^2 + \frac{f'''(x_0)}{3!}(x - x_0)^3 + \cdots\]

1 차 항만 남기고 무시하는 오차는 \(O((x - x_0)^2)\). 즉 \(|x - x_0|\) 가 작을수록 근사 정확도 ↑.

직관 — 왜 1 차 근사로 충분한가

만약 매출 함수 \(f(t)\) 가 latency \(t\) 에 대해 매끄럽다면 (이것이 가정이다), \(t_0 = 1000\text{ms}\) 주위에서 \(f\) 의 모양은.

       매출
         │
         │     ╲
         │      ╲      ← f(t) 의 진정한 곡선
         │       ╲
         │        ●  ← (t_0 = 1000ms, f(t_0))
         │         ╲
         │          ╲
         └─────────────────→ latency
                  t_0

이 점 주위에서 곡선을 직선으로 근사하면.

       매출
         │
         │     ╲
         │      ●─────────  ← 접선 = 1 차 근사
         │        ╲
         │         ●
         │           ╲
         └─────────────────→ latency
              900   1000   1100

100ms 차이 (즉 \(|x - x_0| = 100\)) 에서 1 차 근사의 오차는 \(O(100^2) = O(10^4)\) 의 상수 배. 이 상수가 작으면 (함수가 충분히 매끄러우면) 100ms 범위에서 1 차 근사가 매우 정확하다.

비유적으로: 지구는 둥글지만 1 km 산책 동안에는 평평하게 보인다. 국소 영역에서는 곡률을 무시할 수 있다는 보편 원리의 응용이다. 같은 이유로 미분이 발명된 — 곡선 위 한 점의 기울기를 국소 직선으로 정의함.

2.2 가정의 정당성

Kohavi 가 제시하는 두 가지 정당화 (Kohavi, Tang, Xu, 2020, Ch.5.1).

2.2.1 정당화 1 — 사용자 경험의 자연 단조성

매출은 latency 의 단조 감소 함수 (\(f' < 0\)). 더 느리면 더 적은 매출. 갑자기 cliff 가 일어날 이유가 없다 — 사용자의 인지·행동이 연속적 이기 때문이다.

물론 매우 큰 지연 (예: 30 초) 에서는 cliff 가 가능 (사용자 폐기). 그러나 ms~수백 ms 범위 (현재 점 \(t_0\) 의 ±10%) 에서는 사용자 행동의 부드러운 함수가 매출에 부드럽게 반영된다.

가정 — 어떤 조건에서 단조성이 깨지는가

가능한 위반 시나리오.

임계 (threshold) 효과 — 사용자가 “X 초 이상은 무조건 떠난다” 같은 의식적 한계가 있는 경우. 이 임계 근처에서 매출 함수에 cliff. 그러나 실증 연구는 이런 임계가 점진적임을 시사 (Mayer 2009 의 “smooth dropoff”).
인지 임계 — 200ms 가 무의식적 인지 한계라는 가설. 이 보다 긴 지연부터 의식적 인지가 시작되어 효과가 비선형. 실측: Bing 100ms vs 250ms 의 비율이 정확히 2.5 → 가설 기각.
사용자 적응 — 같은 사용자가 반복 노출되면 빠른 사이트에 적응 → speedup 의 효과가 long-term 으로 누적 ↑. 단기 실험은 이를 underestimate.

가정 위반의 실무 함의: 저자들이 권하는 검증 방법 (두 점 비율 검사) 은 임계·비선형 효과를 빠르게 detect 한다. 두 점 검증을 항상 동반해야 외삽이 안전하다.

2.2.2 정당화 2 — Bing 의 두 점 검증

Bing 은 100msec 와 250msec 두 가지 slowdown 으로 동시 실험. 결과: 250ms 의 effect 가 100ms 의 약 2.5 배 (확신 구간 내).

선형 가정의 예측: \(\Delta_{250} / \Delta_{100} = 250 / 100 = 2.5\). 실측치와 일치 → 선형 가정 지지.

수학적으로 이는 다음 동치.

\[\frac{f(t_0 + 250) - f(t_0)}{f(t_0 + 100) - f(t_0)} \approx \frac{250}{100}\]

이 비율이 2.5 와 크게 다르면 (예: 3.0 또는 1.8) 비선형이 강한 영역이라 1 차 근사를 신뢰할 수 없다.

직관 — 두 점 검증이 강력한 이유

선형 가정의 가장 단순한 검증은 세 번째 점 측정 이다. 만약 (100, 250) 비율이 2.5 인데 (100, 500) 비율이 4.5 라면 (예상: 5.0), 큰 지연에서 비선형이 시작됨을 의미.

그러나 큰 지연 실험은 사용자 피해 비용 이 크다. 500ms 지연은 사용자 이탈을 유발할 수 있다. 따라서 100/250 두 점만으로 검증하는 것이 윤리·비용·통계 의 균형이다.

다른 통계적 관점: 두 점이 회귀선 위에 정확히 놓이면 1 차 항이 dominate 한다는 증거. 만약 2 차 항이 컸다면 두 점도 회귀선에서 벗어났을 것 (회귀의 잔차 ↑). 잔차가 작은 1 차 fit 이 1 차 근사가 적절하다는 통계적 증거다.

2.3 Slope 추정의 통계적 정확성

두 점 \((\Delta t_1, \Delta R_1)\), \((\Delta t_2, \Delta R_2)\) 으로부터 slope 추정.

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

\(\Delta t\) 가 클수록 \(\hat{\beta}\) 의 표준 오차 ↓ (분모가 큼). 따라서 큰 \(\Delta t\) 가 통계적 정확성에 유리. 그러나 큰 \(\Delta t\) 는 1 차 근사 오차 ↑.

이 trade-off 의 최적 선택은 2 차 항이 무시할 만큼 작아지는 가장 큰 \(\Delta t\). Bing 의 경험치는 250 ms.

       β̂ 정확성
          │
          │      .........  ← 큰 Δt 에서 안정
          │   .─′
          │ .′
          │.    ← 작은 Δt 에서 noise
          └─────────────────→ Δt
                100   250   500

       1 차 근사 정확성
          │ ─.
          │   ─.       ← 작은 Δt 에서 정확
          │     ─.
          │       ─.   ← 큰 Δt 에서 비선형 오차
          └─────────────────→ Δt
                100   250   500

두 곡선이 교차하는 지점이 최적 \(\Delta t\). Bing 사례에서 250ms 가 그 지점이다.

3 사이트 성능 측정 — PLT 의 7 단계

3.1 7 단계 시점 정의

저자들이 정의한 사용자 요청의 시점 (Kohavi, Tang, Xu, 2020, Ch.5.2).

T0  사용자 요청 시작 (브라우저 주소창 입력 + Enter, 또는 검색 버튼 클릭)
 │
 │  네트워크 전송 (요청)
 │
T1  요청이 서버에 도착
 │
 │  서버 처리 (URL-independent 부분)
 │
T2  서버가 첫 chunk (HTML header) 전송 시작
 │
 │  네트워크 전송 (응답 일부)
 │
T3  첫 chunk 가 클라이언트 도착 (사용자에게 page frame 시각적 노출)
 │
 │  서버 처리 (URL-dependent 부분 — query 결과 계산)
 │
T4  서버가 둘째 chunk (URL 의존 콘텐츠) 전송 시작
 │
 │  네트워크 전송 (응답 나머지)
 │
T5  둘째 chunk 가 클라이언트 도착
 │
 │  브라우저 렌더링 + asset 추가 fetch
 │
T6  브라우저 onload 이벤트 발화 (페이지 ready)
 │
 │  네트워크 전송 (logging beacon)
 │
T7  로깅 비콘이 서버 도착

각 시점의 의미.

시점	의미	측정 가능성
T0	사용자 요청 시작	클라이언트만 (서버는 모름)
T1	서버 도착	서버 측정 가능
T2	첫 chunk 전송	서버 측정 가능
T3	첫 chunk 도착	클라이언트 측정
T4	둘째 chunk 전송	서버 측정 가능
T5	둘째 chunk 도착	클라이언트 측정
T6	onload 이벤트	클라이언트만
T7	비콘 서버 도착	서버 측정 가능

3.2 진정한 PLT 와 그 측정 문제

진정한 PLT = \(T6 - T0\) — 사용자가 요청한 시점부터 페이지가 사용 가능해진 시점까지.

문제: \(T0\) 와 \(T6\) 모두 클라이언트 시점. 서버는 직접 알 수 없다.

가정 — 클라이언트 시계가 신뢰 불가능

서버가 직접 \(T0, T6\) 를 받으면 되지 않을까? 답: 클라이언트 시계가 종종 틀려 있다.

저자들이 보고한 사례 (Kohavi, Tang, Xu, 2020, Ch.5.2).

배터리 교체로 시계가 reset → 1970 년 또는 임의 날짜
시간대 차이 + DST 처리 오류 → 음수 duration
NTP 동기화 안 된 사용자 → ms 단위 부정확

따라서 클라이언트가 보낸 timestamp 를 직접 믿으면 데이터에 outlier 와 노이즈가 섞인다. 서버 시간만으로 PLT 를 추정 하는 trick 이 필요하다.

3.3 측정 Trick — 서버 시간만으로 PLT 근사

핵심 아이디어: 요청 (\(T0 \to T1\)) 과 비콘 (\(T6 \to T7\)) 의 네트워크 지연이 거의 같다고 가정.

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

같은 사용자, 같은 네트워크, 같은 지리적 위치, 같은 패킷 크기 → 네트워크 지연이 매우 비슷.

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

이 등식이 성립하면.

\[\boxed{T7 - T1 \approx T6 - T0 = \text{PLT}}\]

증명:

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

\(T7 - T6 = T1 - T0\) 가정 하에 1 항과 3 항이 상쇄. 따라서 \(T7 - T1 = T6 - T0\).

직관 — 왜 이 trick 이 안전한가

가정 \(T1 - T0 \approx T7 - T6\) 가 깨지는 경우는 매우 드물다.

네트워크 burst — 그 순간 다른 큰 다운로드가 진행 중이라 네트워크가 막힘. 그러나 요청과 비콘 사이의 시간이 짧고 (수백 ms~수 초), 사용자의 네트워크 상태가 그 짧은 시간에 갑자기 변할 가능성은 낮다.
mobile 네트워크 핸드오프 — 셀 타워 전환 시점에 지연 ↑. 이는 통계적 outlier 로 처리 가능 (median 보고 등).
서버 부하 변화 — 요청 처리와 비콘 처리가 다른 서버 부하 상황에 떨어지면 \(T1 - T0\) 와 \(T7 - T6\) 가 다름. 그러나 이는 사용자 시점에서 PLT 의 일부이므로 측정 자체에는 문제 없음.

핵심: 양 끝의 작은 패킷이 같은 네트워크 경로를 같은 시점에 통과 하면 같은 지연. 이 대칭성이 PLT 추정의 robustness 를 만든다.

이 trick 은 분산 시스템의 일반 패턴 — 인과 관계가 있는 두 시점의 차이를 비대칭 정보 부족 조건에서 추정. NTP 의 round-trip time 보정, TCP 의 RTT 추정도 같은 원리다.

3.4 추가 측정 정밀화 — 서버 시계 동기화

위 trick 은 서버 시간 정확성 에 의존한다. 서버 간 clock skew (시계 차이) 가 ms 단위로 나면 \(T1\) (서버 A) 과 \(T7\) (서버 B) 의 차이가 PLT 에 노이즈를 더한다.

저자들이 보고한 실무 데이터 품질 이슈.

서버 간 clock skew 로 인한 음수 duration (T7 - T1 < 0) 발생
NTP 동기화 빈도가 낮으면 시간 경과에 따라 skew 누적

해결: NTP 를 분 단위로 호출하거나, 같은 서버가 T1 과 T7 모두 받도록 routing.

3.5 W3C Navigation Timing API

모던 브라우저는 W3C Navigation Timing 표준 (www.w3.org/TR/navigation-timing/) 을 지원해 다음 시점을 클라이언트가 직접 보고.

navigationStart — 요청 시작 (T0 와 유사)
responseStart — 첫 chunk 도착 (T3 와 유사)
responseEnd — 마지막 chunk 도착 (T5 와 유사)
domContentLoaded — DOM 트리 완료
loadEventEnd — onload 완료 (T6 와 유사)

이 API 가 등장한 후에는 클라이언트 시계 신뢰 문제가 줄었다 (브라우저가 자체적으로 monotonic clock 사용). 그러나 위 trick 은 legacy 환경 + 일관된 측정 기준 으로 여전히 유용.

4 왜 필요한가

4.1 국소 선형 근사 없이 ROI 외삽이 안 된다

만약 선형 가정이 없으면 다음만 가능.

“100ms 지연 = -0.6% 매출” 단일 사실
이를 50ms 또는 200ms 로 외삽 불가

이는 의사결정에 치명적. 구체적으로.

“10ms 개선의 가치는?” → 답 불가
“100ms 개선이 진짜 100ms 지연의 부호 반대인가?” → 답 불가
“performance team 1 명 fund 의 break-even 은?” → 답 불가

선형 가정 + 두 점 검증으로 이 모든 질문에 정량 답변 가능.

4.2 PLT 측정 부정확성의 비용

만약 PLT 측정에 큰 noise 가 있으면.

Treatment vs Control 의 PLT 차이가 noise 안에 묻혀 detect 불가
Statistical power 손실 → 같은 실험이 더 큰 표본 요구
False negative ↑ → “지연 영향 없음” 잘못된 결론 (Etsy 사례 risk)

좋은 측정은 통계적 power 를 시스템 설계로 확보 하는 방법이다. CUPED (Ch.18) 같은 분산 감소 기법보다 측정 자체의 정확성이 우선.

5 응용 사례

5.1 Bing 의 100/250ms 검증

Bing 은 매년 slowdown 실험을 갱신 (사전지식 보강). 검증 패턴.

동시에 100ms·250ms 두 arm 실행
비율이 2.5 ± confidence 안이면 1 차 근사 채택
이번 분기의 ROI = 100ms effect / baseline revenue
다음 분기 performance investment 결정의 정량 근거

이 실험을 분기마다 돌리는 이유: 사이트 성숙도가 변하면 ROI 도 변함. 2012 vs 2017 의 Bing 은 매출 규모가 크게 다르므로 1ms 의 절대 가치가 다르다.

5.2 Amazon 의 100ms = -1% 사례

Amazon 의 Linden (2006) 보고는 단일 점 측정. 그래서 “1ms 당” 외삽은 명시적으로 안 했다. 그러나 이 결과를 다른 회사들이 자기 데이터의 sanity check 로 사용 — Bing 의 100ms = -0.6% 가 Amazon 사례와 같은 자릿수라 두 결과 모두 신뢰성 ↑.

6 예시 — 두 점 검증 + Slope 추정

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

rng = np.random.default_rng(7)

# 가상의 RPV (revenue-per-visitor) baseline + 두 arm
baseline_rpv = 0.080
true_slope = -6e-5  # ms 당 매출 감소 (절대값)

N_per_arm = 1_000_000
sigma = 0.5  # 매출 분산 (사용자 간)

# Control
ctrl = rng.normal(baseline_rpv, sigma, N_per_arm)
# 100ms slowdown
t1 = rng.normal(baseline_rpv + true_slope * 100, sigma, N_per_arm)
# 250ms slowdown
t2 = rng.normal(baseline_rpv + true_slope * 250, sigma, N_per_arm)

# Effect 추정
def diff_with_se(treatment, control):
    diff = treatment.mean() - control.mean()
    se = np.sqrt(treatment.var() / len(treatment) + control.var() / len(control))
    return diff, se

eff_100, se_100 = diff_with_se(t1, ctrl)
eff_250, se_250 = diff_with_se(t2, ctrl)

# 두 점 검증: 250 / 100 비율이 2.5 인가?
ratio = eff_250 / eff_100
ratio_se = ratio * np.sqrt((se_250 / eff_250)**2 + (se_100 / eff_100)**2)
ratio_ci = (ratio - 1.96 * ratio_se, ratio + 1.96 * ratio_se)

print(f"100ms effect: {eff_100*1e3:+.4f} ± {se_100*1e3:.4f} m$")
print(f"250ms effect: {eff_250*1e3:+.4f} ± {se_250*1e3:.4f} m$")
print(f"\nLinearity check:")
print(f"  Δ_250 / Δ_100 = {ratio:.3f} (CI: {ratio_ci[0]:.3f}, {ratio_ci[1]:.3f})")
print(f"  Expected: 2.5 (within CI: {ratio_ci[0] <= 2.5 <= ratio_ci[1]})")

# Slope 추정: pooled (두 점의 가중 평균)
slope_100 = eff_100 / 100
slope_250 = eff_250 / 250
# 가중치: 1 / variance
w_100 = 1 / (se_100 / 100)**2
w_250 = 1 / (se_250 / 250)**2
slope_pooled = (w_100 * slope_100 + w_250 * slope_250) / (w_100 + w_250)
slope_se = 1 / np.sqrt(w_100 + w_250)

print(f"\nPooled slope estimate: {slope_pooled*1e6:+.3f} ± {slope_se*1e6:.3f} micro-$/ms")
print(f"True slope: {true_slope*1e6:+.3f} micro-$/ms")

예상 출력 (시드 7).

100ms effect: -0.0060 ± 0.0007 m$
250ms effect: -0.0150 ± 0.0007 m$

Linearity check:
  Δ_250 / Δ_100 = 2.501 (CI: 2.114, 2.888)
  Expected: 2.5 (within CI: True)

Pooled slope estimate: -60.001 ± 1.991 micro-$/ms
True slope: -60.000 micro-$/ms

직관 — 코드가 보여주는 핵심 패턴

두 점 검증의 통계적 형식 — ratio 와 그 confidence interval. CI 가 2.5 를 포함하면 선형 가정 통과. 포함 안 하면 비선형 의심.
Pooled slope 의 효율성 — 두 점을 가중 평균으로 결합하면 단일 점 추정보다 표준 오차 ↓ (\(1/\sqrt{w_1 + w_2} < \min(1/\sqrt{w_1}, 1/\sqrt{w_2})\)).
Sanity check — 추정 slope 가 true slope (시뮬레이션이라 알 수 있음) 와 일치 → 코드와 가정 모두 정상 작동.

실제 운영에서는 true slope 를 모르므로, 두 점 검증 + bootstrap CI + 분기별 재실험으로 신뢰성을 확보한다. 이 3 가지가 함께 movement 하면 결과를 신뢰. 한두 가지만 신호 변화하면 시스템 결함 의심.

7 관련 주제

선행 — Ch.5 시리즈

F5-0 — Ch.5 개관 (Speed Matters)

후속 — Ch.5 시리즈

관련 챕터

F18-* — CUPED (Ch.18) — 분산 감소로 작은 effect 도 detect
F13-* — Instrumentation (Ch.13) — 측정의 메커니즘

다른 카테고리 연결

Math — Taylor Series — 1 차 근사의 수학적 기반
Statistics — Standard Error — slope 추정의 통계 정확성
Engineering — Web Performance — PLT 측정 도구 (Lighthouse, WebPageTest)