# Alice는 기다림을 싫어합니다

> Clean Markdown view of GeekNews topic #30691. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=30691](https://news.hada.io/topic?id=30691)
- GeekNews Markdown: [https://news.hada.io/topic/30691.md](https://news.hada.io/topic/30691.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-06-22T01:01:35+09:00
- Updated: 2026-06-22T01:01:35+09:00
- Original source: [brooker.co.za](https://brooker.co.za/blog/2026/06/19/waiting.html)
- Points: 1
- Comments: 1

## Topic Body

- 서비스 평균 요청 시간이 100ms이고 MTTR이 1분 미만이어도, 사용자는 긴 요청과 긴 장애에 더 오래 갇히기 때문에 **평균 대기 시간**을 훨씬 길게 느낌
- 운영자는 요청·장애를 사건 단위로 집계하지만, Alice와 Alex 같은 사용자는 **초·분 단위의 체감 시간**으로 기다림을 계산함
- 이 차이는 **검사 역설(inspection paradox)** 때문이며, 사용자가 경험하는 분포는 원래 지연 분포 `f(t)`가 아니라 `t`로 가중된 분포가 됨
- 복구 시간 중앙값이 30분, p99가 600분인 로그정규 분포에서는 MTTR이 1시간을 조금 넘는 수준이어도 고객 체감 평균 복구 시간은 약 **6시간**까지 늘어남
- 꼬리 지연과 긴 복구 시간은 고객 경험을 지배할 수 있으며, 절단 평균(trimmed mean)은 오른쪽 꼬리의 중요한 정보를 버릴 위험이 있음

---

### 요청 단위 평균과 사용자 체감 평균의 간극
- Alice는 웹 서비스를 사용하며, 대부분의 사람처럼 시간을 초와 분으로 느낌
- 운영자는 평균 요청이 **100ms**에 완료된다고 보지만, Alice의 평균 대기 시간은 **1초**가 될 수 있음
- 장애에서도 같은 차이가 생김
  - 운영자는 MTTR이 **1분 미만**이라고 말할 수 있음
  - Alex가 체감하는 평균 장애 시간은 **1시간**일 수 있음
- 두 측정은 동시에 맞을 수 있음
  - 긴 요청이나 긴 장애는 운영자 집계에서는 하나의 사건임
  - 사용자의 시간에서는 지속된 길이만큼 더 큰 비중을 차지함

### 검사 역설이 만드는 t-가중 분포
- 이 현상은 **검사 역설**로 볼 수 있음
- 사용자는 지연 분포 `f(t)` 자체가 아니라, `t`로 가중된 버전을 경험함
- MTTR 또는 평균 요청 시간이 `E[X]`일 때 사용자가 경험하는 평균은 다음과 같음
  - `E_a[X] = E[X²] / E[X]`
  - `E_a[X] = E[X] + Var(X) / E[X]`
- 분산이 클수록 사용자가 체감하는 평균은 운영 지표의 평균보다 더 크게 벌어짐

### 30분 중앙값과 600분 p99 예시
- 중앙값 지연 또는 복구 시간과 **99퍼센타일** 값을 넣으면 로그정규 분포를 맞추고, 서비스 지표와 고객 체감 값을 비교할 수 있음
- 예시 값은 다음과 같음
  - 중앙값 TTR: **30분**
  - p99 TTR: **600분**, 즉 100개 이벤트 중 1개는 복구에 10시간 걸림
- 이 경우 MTTR은 1시간을 조금 넘지만, 고객이 경험하는 평균 복구 시간은 약 **6시간**이 됨

### 꼬리 지연과 절단 평균의 함정
- 꼬리 지연과 긴 복구 시간을 이해해야 하는 이유는 여러 가지가 있으며, [multiple samples](https://brooker.co.za/blog/2021/04/19/latency.html)도 그중 하나임
- 서비스 시간에서는 **타임아웃 후 재시도(timeout-and-retry)** 가 일부 지연을 숨길 수 있음
  - 단, 실행 중인 요청이 락이나 다른 독점 리소스를 잡고 있지 않아야 함
- 복구 시간에는 이런 숨김이 불가능해 **꼬리의 두꺼움**이 고객 경험에 더 직접적으로 드러남
- trimmed mean 같은 절단 측정값은 고객 경험을 지배하는 오른쪽 꼬리의 형태를 가리는 문제가 있음
- 절단 측정값을 선호하지 않는 또 다른 이유는 Little’s Law와 용량 사용량과 관련되며, 관련 글은 [이전에 다룬 글](https://brooker.co.za/blog/2017/12/28/mean.html)에 있음

### 로그정규 분포 사용에 대한 주의
- 로그정규 분포는 수치 계산 편의를 위해 선택됨
- `lognormal(μ, σ²)`가 `lognormal(μ + σ², σ²)`가 되는 성질이 있고, 0 근처에서 잘 동작함
- 지연이나 복구 시간 지표에 로그정규 분포가 특히 좋은 선택이라고 보기는 어려움
- 이런 문제는 일반적으로 **비모수적 방식**으로 접근하는 편이 낫다고 봄

## Comments



### Comment 60074

- Author: neo
- Created: 2026-06-22T01:01:36+09:00
- Points: 1

###### [Lobste.rs 의견들](https://lobste.rs/s/dswkwr/meet_alice_alice_is_impatient) 
- 제목을 **Latency and the inspection paradox**처럼 더 정보가 있는 쪽으로 바꾸는 게 나을 듯함  
  지금 제목은 사실상 전달하는 정보가 0에 가깝다 😅
  - 저자 입장에서는 약간 모호한 제목이 꽤 유용함  
    제목만 읽고 본문은 안 읽은 사람들의 답글을 줄여주기 때문임

- 흥미롭지만, 저자가 왜 이게 참인지 **t-weighted**라는 용어와 수식 말고는 설명하지 않아서 잘 이해가 안 됨  
  대학 통계 수업을 오래전에 잊어버린 사람도 이해할 수 있게 더 명확히 설명해줬으면 좋겠음
  - 모니터링 대시보드가 있다고 해보면, 보통은 모든 요청을 동일하게 취급해서 평균 지연 시간을 계산함  
    ```  
    mean = (sum of all latencies) / (number of requests)  
    ```  
    이게 `E[X]`이고, 각 요청의 가중치는 `1/N`임  
    Alice가 체감하는 지연 시간은 시간 기준이라서, 아마 여기서 **시간 가중(t-weighted)** 이 나온 것 같음  
    Alice가 지연 시간이 `x_1, x_2, ..., x_M`인 M개의 요청을 보냈다고 하면, “Alice의 전체 대기 시간 중 임의의 1초를 골랐을 때, 그 순간 기다리고 있는 요청의 지연 시간은 얼마인가?”라고 물을 수 있음  
    이때 요청 i는 `x_i / (Σ_j x_j)`만큼 기여하므로 긴 요청일수록 더 많이 반영됨  
    그래서 시간 가중 평균은 다음과 같음  
    ```  
    E_a[X] = Σ_i x_i (x_i / Σ_j x_j) = Σ_i x_i^2 / Σ_j x_j  
    = (Σ_i x_i^2 / N) / (Σ_j x_j / N)  
    = E[X^2] / E[X]  
    ```  
    간단한 예로, 지연 시간이 1초인 요청 하나와 10초인 요청 하나가 있으면 일반 평균은 5.5초지만, 시간 가중 평균은 `1 * (1 / 11) + 10 * 10 / 11 = 9.18s`가 됨

- 관련해서 [The Inspection Paradox is Everywhere ](https://allendowney.blogspot.com/2015/08/the-inspection-paradox-is-everywhere.html)도 볼 만함

- 나도 실제로 비슷한 생각을 해본 적이 있음  
  이 문제를 이해하기 가장 쉬운 예는 버스 승객에게 버스에 몇 명이 타고 있는지 묻는 조사라고 봄  
  그러면 “버스가 꽉 찼다”는 답은 훨씬 많이 얻지만, 버스가 비어 있을 때는 누구에게도 물을 수 없음  
  모든 버스가 비어 있고 딱 한 대만 붐빌 수도 있음  
  목표가 **사용자 관점**에서 상황을 분석하는 것이라면 이 통계가 맞다고 생각함
  - 그래프 이론에도 비슷한 결과가 있는데, 거의 모든 사람의 친구들은 자기보다 친구가 더 많다는 것임  
    연결이 많은 노드는 연결이 적은 노드보다 다른 노드의 **인접 리스트**에 더 자주 등장하기 때문임

- 이 주제가 와닿는다면 [Gil Tene's "How not to measure latency"](https://www.youtube.com/watch?v=lJ8ydIuPFeU)를 강력히 추천함