latency, bandwidth, throughput의 차이는 무엇인가?

Question

IT Interview Practice · Accepted Answer

이 셋은 서로 다른 것을 기술하는데 끊임없이 혼동된다. **Latency**(지연)는 *딜레이*다 — 하나의 데이터 단위가 A에서 B로 이동하는 데 걸리는 시간(시간으로 측정, 예: ms). **Bandwidth**(대역폭)는 *용량*이다 — 링크가 나를 수 있는 최대 데이터 속도(예: Gbps). **Throughput**(처리량)은 실제로 달성하는 *실제* 속도이며, 보통 bandwidth보다 낮다. 파이프 비유가 이해를 돕는다:

```text
   ├────────────── length of pipe = LATENCY (how long to traverse) ─────────────┤
   ╔══════════════════════════════════════════════════════════════════════════╗
   ║  width of pipe = BANDWIDTH (max capacity)                                  ║
   ║  water actually flowing = THROUGHPUT (real achieved rate ≤ bandwidth)      ║
   ╚══════════════════════════════════════════════════════════════════════════╝
```

결정적으로, **더 넓은 파이프가 파이프를 더 짧게 만들지는 않는다**: bandwidth를 더한다고 latency가 줄지 않는다. 굵은 대서양 횡단 링크도 거리와 빛의 속도가 좌우하는 ~80ms의 왕복 latency를 여전히 가진다 — 돈으로 그 아래로 내려갈 수 없다. 이것이 bandwidth가 아니라 latency가 인터랙티브 앱의 체감을 지배하는 이유다: 각 round trip(DNS, TCP handshake, TLS, 그다음 request)이 latency 통행료를 내고, 그것들이 쌓인다.

Latency와 throughput은 **Bandwidth-Delay Product**(BDP = bandwidth × round-trip time)를 통해 상호작용하는데, 이는 파이프를 채우기 위해 "전송 중"이어야 하는 데이터 양이다. 고대역폭, 고지연의 "긴 뚱뚱한 네트워크(long fat network)"에서는 ACK를 기다리는 TCP 같은 프로토콜이 window가 최소 BDP는 되지 않으면 파이프를 채울 수 없다 — 그래서 throughput이 결국 bandwidth가 아니라 *latency에 의해 제한된다*. 이것이 긴 거리를 지나는 하나의 TCP 스트림이 빠른 링크에서조차 종종 저조한 이유이고, 병렬성, 더 큰 window, 그리고 CDN(거리를, 따라서 latency를 줄이는)이 도움이 되는 이유다.

## 왜 중요한가

이 셋을 뒤섞는 것은 가장 흔하고 — 가장 결과가 큰 — 성능 실수 중 하나다: 팀이 사실은 latency 문제인 것을 고치려고 bandwidth를 더 사고는 아무 개선도 못 본다. 시니어의 통찰은 **latency가 물리학(거리)이 정한 바닥**이며 이를 아키텍처적으로 공략한다는 것이다 — 서버/CDN을 사용자에 더 가까이 두고, round trip을 줄이고(연결 재사용, HTTP/3, 캐싱), request를 배칭한다 — 반면 bandwidth는 종종 그냥 프로비저닝할 수 있는 것이다. BDP를 이해하면 "빠른" 링크가 느린 단일 스트림 전송을 내는 것 같은 반직관적 결과가 설명되는데, 이는 고성능의 지리적으로 분산된 시스템을 설계하거나 디버깅할 때 기대되는 바로 그런 추론이다.

왜 중요한가

관련 질문