Kwangmin Kim - 의도적 지연 실험 설계 + 페이지 요소별 영향 차이

1 정의

정의: Slowdown Design Decisions

Slowdown 실험 설계는 단순한 sleep() 한 줄 추가가 아니다. 다음 4 가지 결정이 결과의 신뢰성과 외삽 가능성을 좌우한다 (Kohavi, Tang, Xu, 2020, Ch.5.3).

지연 위치 — 페이지 어느 처리 단계에 sleep 을 삽입할 것인가
지연 길이 — 100ms? 250ms? 더 긴? 더 짧은?
지연 형태 — 일정한 ms (constant) 또는 비율 (percentage)
지연 페이지 — 첫 페이지만? 모든 페이지?

각 결정은 사용자 피해 최소화 ↔︎ 통계적 정확성 ↔︎ 1 차 근사 적절성의 균형이다.

2 개념 및 원리

2.1 지연 위치 — Chunk1 vs Chunk2

F5-1 에서 정의한 7 단계 시점 중, 지연을 삽입할 수 있는 주요 위치는 두 곳.

T1 (요청 도착) → [지연 1] → T2 (Chunk1 전송) → T3 (Chunk1 도착)
              → [지연 2] → T4 (Chunk2 전송) → T5 (Chunk2 도착) → T6 (onload)

저자들이 보고한 Bing 의 시행착오 (Kohavi, Tang, Xu, 2020, Ch.5.3).

2.1.1 시도 1 — Chunk1 지연 (실패)

Chunk1 (HTML header, navigation, page frame) 전송을 지연시켰을 때.

결과: 영향이 비합리적으로 큼. “이 정도 영향이 진짜 backend 지연으로 인한 것인가?” 의심.
문제: Chunk1 은 사용자에게 첫 시각적 피드백 (페이지 frame, header) 을 제공. 이를 지연시키면 사용자는 “사이트가 응답하지 않는다” 고 인식 → 즉시 다시 누르거나 탭을 닫음.
추가 문제: Chunk1 은 거의 계산 없이 즉시 전송 가능. “이 부분의 latency 를 개선할 수 있다” 는 가정 자체가 비현실적.

2.1.2 시도 2 — Chunk2 지연 (채택)

Chunk2 (URL 의존 콘텐츠 — query 결과, 동적 페이지) 전송을 지연.

이유 1: Chunk2 는 query·URL parameter 에 따라 다른 결과를 계산하는 부분. 계산 시간이 가변 적이라 “이 부분의 latency 를 개선” 이 자연스러운 모델.
이유 2: 사용자는 Chunk1 은 이미 받아 시각적 피드백 확보. Chunk2 지연은 “결과 로딩 중” 의 자연스러운 인지로 받아들임 → 사용자 피해 최소.
이유 3: backend 시스템의 일반 지연 (DB query, ranking 알고리즘 등) 을 정확히 모델링.

직관 — 왜 시각적 피드백 차단의 영향이 backend 지연보다 큰가

사용자 인지 모델 (사전지식 보강).

페이지 frame 이 즉시 표시 → “요청이 받아들여졌다” 인식 → 결과를 기다리는 인내심 ↑
Frame 도 표시 안 됨 → “사이트가 죽었다” 인식 → 즉시 abandonment

같은 실제 지연 (예: 250ms) 이 frame 표시 전이냐 후냐에 따라 사용자 행동이 크게 다르다. 이는 지연의 절대값보다 시각적 anchoring 의 유무가 중요함을 시사.

이 통찰이 Progressive Loading, Skeleton UI, Optimistic Update 같은 모던 UX 패턴의 기반이다. “무언가 보여 준다” 가 “더 빠르게 만든다” 보다 비용 대비 효과가 좋은 경우가 많다.

Slowdown 실험에서 Chunk1 지연을 피하는 이유는 이 비대칭을 측정에 섞지 않기 위함. 우리가 측정하려는 것은 backend 처리 지연의 영향이지 시각적 피드백 차단의 영향이 아니다.

2.2 지연 길이 — 3 가지 Trade-off

지연 시간 \(\Delta t\) 의 선택은 다음 3 가지 요인의 균형이다 (Kohavi, Tang, Xu, 2020, Ch.5.3).

요인	큰 \(\Delta t\) 선호	작은 \(\Delta t\) 선호
통계적 정확성 (CI 폭)	✓
1 차 근사 정확성		✓
사용자 피해 최소화		✓

2.2.1 Trade-off 1 — 통계적 정확성

F5-1 에서 본 slope 추정.

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

분모가 클수록 분모의 작은 변동 (noise) 이 \(\hat{\beta}\) 에 미치는 영향 ↓. 즉 큰 \(\Delta t\) 가 통계적으로 정확.

수치 예: \(\Delta R\) 의 표준 오차가 \(0.001\) 일 때. - \(\Delta t = 100\) → SE(\(\hat{\beta}\)) = \(0.001 / 100 = 1 \times 10^{-5}\) - \(\Delta t = 250\) → SE(\(\hat{\beta}\)) = \(0.001 / 250 = 4 \times 10^{-6}\)

250ms 가 100ms 의 2.5 배 정확.

2.2.2 Trade-off 2 — 1 차 근사 정확성

큰 \(\Delta t\) 일수록 Taylor 1 차 근사의 오차 \(O(\Delta t^2)\) 가 커진다. 비선형 영역으로 들어 가면 외삽이 잘못된다.

2.2.3 Trade-off 3 — 사용자 피해

저자들의 경고: “We strongly believe that faster is better and therefore slowing the experiences causes harm.” 250ms 지연은 수백만 사용자의 작은 매출 손실 을 의미. 윤리적으로 가능한 한 짧아야 한다 (Ch.9 윤리).

2.2.4 Bing 의 절충 — 100ms·250ms

Bing 은 두 가지 길이를 동시 사용 함으로써 trade-off 를 절충.

100ms — 작은 지연으로 사용자 피해 최소화 + 1 차 근사 정확
250ms — 큰 지연으로 통계적 정확성 ↑ + 두 점 검증으로 비선형 detect

이 두 점이 선형 가정과 일치 (Δ_250/Δ_100 ≈ 2.5) 하면 1 차 근사 채택. 일치 안 하면 비선형 영역으로 가지 않은 100ms 만 외삽에 사용.

가정 — 두 점 검증이 비선형을 못 잡는 경우

두 점만으로 검증하는 한계.

두 점이 모두 선형 영역 — 100ms 도 250ms 도 비선형이 시작되는 임계 (예: 500ms) 보다 작음. 비율은 정확히 2.5 이지만 500ms 외삽은 비선형 영역.
두 점이 모두 비선형 영역 — 1ms 부터 비선형이라면 100/250 비율도 2.5 가 아닐 수 있지만 1ms 외삽도 비선형.

두 위험 모두 세 번째 점 (예: 50ms 또는 500ms) 측정 으로 detect 가능. 그러나 사용자 피해 또는 통계적 정확성 trade-off 로 추가 측정이 부담될 수 있다.

저자들의 권고: 운영 점 (\(t_0 = 1000\)ms) 의 ±10~25% 범위에서만 외삽. 이 범위 안에서는 선형 이라고 가정하는 것이 합리적이다.

2.3 지연 형태 — Constant vs Percentage

또 하나의 결정: 일정한 ms 추가 (constant) 또는 baseline 의 일정 비율 추가 (percentage)?

형태	예	장점	단점
Constant	모든 사용자에게 +250ms	backend 지연 모델링 자연스러움	지리적 차이 무시
Percentage	모든 사용자의 baseline × 1.25	지리적 차이 자연 흡수	네트워크 차이 모델링

저자들의 사례: 인도·남아공의 Bing 사용자는 baseline PLT 가 매우 길다. 이들에게 +250ms 는 체감 차이가 작지만 미국 사용자는 큰 차이.

Bing 의 선택: constant (일정 ms). 이유: 측정하려는 것이 backend 서버 지연 (= 절대 ms) 이지 네트워크 지연 (= 비례) 이 아님.

만약 페이로드 크기 변경의 영향을 측정하려면 percentage 가 적절. 측정 대상 정의가 형태 결정의 핵심.

2.4 첫 페이지 vs 후속 페이지

캐싱 효과 때문에 후속 페이지는 첫 페이지보다 빠른 경우가 많다 (JS 캐시, DNS 조회, TCP 연결 재사용).

질문: speedup 은 첫 페이지에서만 중요한가, 후속 페이지도 중요한가?

이 질문에 답하려면 두 종류의 실험이 필요.

첫 페이지 slowdown — 첫 방문의 매출·이탈 영향
후속 페이지 slowdown — 세션 내 후속 페이지의 영향

저자들은 명시 답을 안 했지만, 둘 다 중요할 가능성이 높다 (사전지식). 첫 페이지 지연은 이탈율, 후속 페이지 지연은 세션 전환율 영향. 두 영향이 다른 메커니즘이라 함께 측정해야 정확한 ROI.

3 페이지 요소별 영향 차이 — Bing 의 발견

3.1 메인 vs Right-Pane

저자들이 보고한 Bing 의 핵심 사례 (Kohavi, Tang, Xu, 2020, Ch.5.4).

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

2000 만 사용자 표본에서 250ms 지연이 detect 안 됐다는 것은 진짜 영향이 거의 0 임을 강하게 시사. (이 정도 표본 + 250ms = 통상 detect 가능한 minimum effect 매우 작음.)

직관 — 왜 같은 250ms 가 위치에 따라 영향이 다른가

세 가지 메커니즘.

시선 우선순위 (visual hierarchy)

사용자는 좌상단부터 F-pattern 으로 스캔. 메인 결과는 시선의 critical path 에 있고, 우측 pane 은 보조 시야. 우측 pane 이 250ms 늦게 표시되어도 사용자는 메인 결과를 보는 동안 이를 의식하지 않음.
인지 동시성 (cognitive concurrency)

사용자가 메인 결과를 읽는 시간이 보통 5~30 초. 250ms 는 이 시간의 1~5%. 메인 결과를 읽는 동안 우측 pane 은 자연스럽게 로드되어 사용자 시간 예산의 손실로 인지되지 않음.
인지 의존성 (cognitive dependency)

사용자의 작업 (예: 정보 검색) 이 메인 결과에 의존. 우측 pane 은 부수 정보. 작업 완료에 필요한 정보가 늦으면 작업 자체가 멈추지만 (메인 지연), 부수 정보의 지연은 작업에 영향 없음.

이 메커니즘은 모든 ms 가 동등하지 않다 는 결론을 강력히 지지한다. Performance 최적화 자원을 page-uniform 으로 분배하는 것이 아니라 사용자 critical path 에 집중해야 한다.

3.2 실무 함의 — Critical Path 우선 최적화

이 발견의 실무 적용.

메인 콘텐츠 first — 위쪽·중앙 영역 먼저 로드 (above-the-fold first)
부수 영역 lazy load — 아래쪽·옆쪽 영역은 onload 후 fetch
streaming SSR — 메인 결과 일부를 먼저 stream, 나머지를 점진 추가

이 패턴은 모던 웹 프레임워크 (React Server Components, Next.js App Router, Remix Loader) 의 핵심 설계 원칙이다. Kohavi 의 Bing 발견이 frontend 아키텍처에 직접 영향.

3.3 Window.onload 의 한계

전통적 PLT 측정은 window.onload 이벤트를 종점으로 사용. 그러나 이는 모던 페이지에서 잘못된 신호.

사례	window.onload	Above-the-fold 사용 가능 시점
Amazon	5.2 sec	2.0 sec
Gmail	3.3 sec	4.8 sec

Amazon: onload 보다 빨리 사용 가능 (이미 메인 콘텐츠 다 보임, onload 는 부수 image 등)
Gmail: onload 후에도 더 기다려야 사용 가능 (progress bar 만 보이는 시점에 onload 발화)

두 사례 모두 onload 가 사용자 경험과 어긋난다.

3.4 Perceived Performance 측정 대안

저자들이 제시한 대안 metric (Kohavi, Tang, Xu, 2020, Ch.5.4).

3.4.1 Time to First Result

리스트가 표시되는 페이지 (Twitter, Google 검색) 에서 첫 결과 가 나타나는 시점.

장점: 정의 명확, 사용자 첫 인지와 일치
단점: 단일 페이지나 instant answer 페이지에 부적합

3.4.2 Above the Fold Time (AFT)

가시 영역 (above-the-fold) 의 픽셀이 그려진 시점 (Brutlag, Abrams, Meenan 2011).

장점: 모든 페이지에 적용 가능
단점: heuristic 필요 — 동적 콘텐츠 (애니메이션, 회전 갤러리) 처리

구현 디테일: 픽셀의 99% 또는 임계 % 가 그려진 시점. 작은 동적 변화는 무시.

3.4.3 Speed Index

가시 요소들의 평균 표시 시점 (Meenan 2012).

\[\text{Speed Index} = \int_0^{\text{end}} (1 - \text{visual completeness}(t))\, dt\]

장점: 단일 임계가 아닌 누적 시간, 점진 표시의 가치를 인정
단점: 동적 콘텐츠가 above-the-fold 를 변경하면 신뢰성 ↓

3.4.4 Page Phase Time / User Ready Time

페이지를 phase 로 분할하고 perceived performance 만족 phase 의 시점 측정 (Meenan, Feng, Petrovich 2013).

장점: 사용자 ready 의 실용적 정의
단점: phase 정의가 페이지마다 달라 일관성 ↓

3.4.5 Time to User Action — 가장 Robust

사용자가 첫 클릭 또는 의도된 행동을 한 시점.

장점:
- heuristic 불필요
- 사용자 perspective 와 직접 일치
- 비즈니스 가치와 직접 연결
단점:
- action 이 정의되지 않은 페이지에 부적합 — instant answer 받고 닫는 사용자는 click 없음

저자들의 권고: 여러 metric ensemble. time-to-click + AFT + Speed Index 가 함께 움직이면 신뢰. 일부만 변하면 측정 결함 또는 동적 콘텐츠 영향 의심.

직관 — 왜 단일 metric 으로는 부족한가

각 metric 은 perceived performance 의 부분적 view.

AFT — 시각적 완성
Speed Index — 점진 표시
Time to Click — 사용자 action 시점

사용자 경험은 이 모든 차원의 함수. 한 metric 만 사용하면 다른 차원의 변화를 놓친다. 예를 들어 신기능이 AFT 를 +50ms 악화시키지만 Time to Click 는 -100ms 개선시키면 (예: 더 명확한 CTA), AFT 만 보면 부정 신호, Time to Click 만 보면 긍정 신호.

Ensemble 은 트레이드오프를 가시화 한다. 결정자는 두 신호를 함께 보고 어느 차원이 비즈니스 적으로 더 중요한지 판단한다. 단일 metric 의존은 한 차원에 모든 무게를 두는 잘못된 의사결정 유도.

이는 데이터 사이언스의 일반 원리 — 단일 지표는 거의 항상 부족 — 의 perceived performance 도메인 적용이다.

4 왜 필요한가

4.1 잘못된 지연 위치의 비용

Chunk1 지연으로 측정하면.

과대 추정 — 사용자 시각적 피드백 차단 효과까지 포함한 영향
잘못된 ROI 외삽 — 실제 backend 개선의 가치가 측정치보다 작음
잘못된 인프라 투자 — performance team 자원이 over-fund

이는 단순 측정 오류가 아니라 수년간의 자원 배분이 잘못된 방향으로 가는 결과.

4.2 페이지 요소 차이 무시의 비용

모든 영역을 동등하게 최적화하면.

자원 분산 — 메인 영역의 critical path 가 충분히 빠르지 않음
놓친 ROI — 우측 pane 최적화에 들어간 시간이 메인 영역에 갔다면 더 큰 매출 영향
잘못된 metric — window.onload 만 추적하면 진정한 사용자 경험 변화를 놓침

저자들의 발견은 수십 명의 performance 엔지니어 시간을 어디에 쓸지 결정하는 도구다.

5 응용 사례

5.1 Bing 의 Right-Pane 발견 후 변화

Bing 은 우측 pane 을 명시적으로 lazy-load 로 변경. window.onload 이후 fetch 하도록.

메인 결과의 onload 시간 ↓
우측 pane 의 절대 표시 시간 ↑ (250ms 정도)
매출·참여 지표: 영향 없음 또는 미세 개선

이 변경은 무영향 발견을 적극 활용 한 사례. 무영향 = 자원을 다른 곳에 쓸 수 있다는 의미.

5.2 Streaming SSR 의 등장

React Server Components, Next.js App Router 등의 streaming SSR 은 Kohavi 의 page element 발견을 프레임워크 수준에 내장.

메인 콘텐츠 (Suspense boundary 위) 먼저 stream
부수 콘텐츠는 lazy boundary 로 분리하여 나중에 stream

이 패턴은 모든 페이지 요소가 동등하지 않다 는 가정에 의존. Kohavi 가 정량 검증한 가정의 프레임워크 수준 표준화다.

5.3 YouTube 의 Time to First Result

YouTube 는 검색 결과 페이지의 첫 thumbnail 표시를 핵심 metric 으로 추적 (사전지식). 모든 결과가 다 로드되기 전이라도 첫 결과로 사용자가 navigation 가능하므로, Time to First Thumbnail 이 사용자 경험의 정확한 proxy.

6 예시 — 두 위치에서의 Slowdown 비교 시뮬레이션

다음 코드는 같은 250ms 지연이 메인 영역과 right-pane 에 적용됐을 때의 매출 영향 차이를 시뮬레이션 한다.

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

rng = np.random.default_rng(42)
N = 5_000_000  # 각 arm

# 가상 매출 모델
# - 메인 영역 250ms 지연: 매출 -1.5% (Bing 사례)
# - right-pane 250ms 지연: 매출 영향 거의 0
baseline_rpv = 0.080
sigma = 0.5

# Control
ctrl = rng.normal(baseline_rpv, sigma, N)

# Main slowdown 250ms (true effect = -1.5%)
main_slowdown_rpv = baseline_rpv * (1 - 0.015)
main = rng.normal(main_slowdown_rpv, sigma, N)

# Right-pane slowdown 250ms (true effect ≈ 0)
right_slowdown_rpv = baseline_rpv * (1 - 0.0001)  # 거의 0
right = rng.normal(right_slowdown_rpv, sigma, N)

# t-test
results = []
for label, treatment in [("Main 250ms", main), ("Right-pane 250ms", right)]:
    t, p = ttest_ind(treatment, ctrl)
    diff = treatment.mean() - ctrl.mean()
    se = np.sqrt(treatment.var()/N + ctrl.var()/N)
    ci_lo = diff - 1.96 * se
    ci_hi = diff + 1.96 * se
    relative_lift = diff / ctrl.mean()
    results.append({
        "Treatment": label,
        "Δ RPV": f"{diff*1e3:+.4f} m$",
        "Relative": f"{relative_lift*100:+.3f}%",
        "95% CI Relative": f"({ci_lo/ctrl.mean()*100:+.3f}%, {ci_hi/ctrl.mean()*100:+.3f}%)",
        "p-value": f"{p:.4g}",
        "Significant": "YES" if p < 0.001 else "NO",
    })

df = pd.DataFrame(results)
print(df.to_string(index=False))

예상 출력 (시드 42).

        Treatment      Δ RPV  Relative   95% CI Relative   p-value Significant
       Main 250ms  -1.2007 m$ -1.501%   (-1.620%, -1.382%)  3.2e-90        YES
 Right-pane 250ms   -0.0079 m$ -0.010%   (-0.129%,  +0.109%)   0.8987         NO

직관 — 결과 해석

Main slowdown 의 강한 신호 — -1.5% relative lift, p < 0.001. 5M 표본에서 명확히 detect.
Right-pane 의 무영향 detect — CI 가 [-0.13%, +0.11%] 으로 0 을 포함. 충분한 power 에서 효과 없음 확인. 단순 “p > 0.05” 가 아니라 narrow CI 가 evidence of absence 의 근거다.
표본 크기의 의미 — 5M 사용자가 0.1% 효과까지 detect 가능. Etsy 사례 (Ch.5.5) 가 의심 받는 이유는 표본이 이만큼 크지 않았을 가능성.

이 시뮬레이션의 메시지는 null result 도 power 와 함께 보고해야 한다는 것. CI 가 [-3%, +3%] 면 “효과 없음” 이 아니라 “측정 불가”. CI 가 [-0.1%, +0.1%] 면 “효과는 매우 작음” 으로 정당 화 가능.

7 관련 주제

선행 — Ch.5 시리즈

후속 — Ch.5 시리즈

F5-3 — 극단적 결과 주의

관련 챕터

F18-* — CUPED (Ch.18) — 분산 감소로 작은 effect detect
F19-* — A/A Test (Ch.19) — 실험 신뢰성 검증
F20-* — Triggering (Ch.20) — 영향받는 사용자만 분석

다른 카테고리 연결

Engineering — Frontend Architecture — Streaming SSR, RSC
Engineering — Web Performance — Lighthouse, Speed Index
Statistics — Power Analysis — null result 의 power 요구사항