지연 vs 처리량 vs 대역폭

차선 1개와 3개인 두 링크에 같은 패킷 6개를 흘려, 대역폭이 처리량을 올리지만 지연은 그대로임을 경주로 보여준다.

1 / 16지연·대역폭·처리량은 서로 다른 질문에 답합니다. 같은 거리에 폭만 다른 두 링크를 준비했습니다 — 위는 한 번에 1개, 아래는 3개를 싣습니다.

좁은 링크 — 대역폭 1첫 도착 —처리량 —

0도착

넓은 링크 — 대역폭 3첫 도착 —처리량 —

0도착

단계 목록 · 키보드 ←/→ 이동, Space 재생

지연은 '한 개가 도착하는 데 걸리는 시간', 대역폭은 '동시에 실을 수 있는 양', 처리량은 '실제로 단위시간에 도착한 양'이다.

왜 헷갈리는가

회선을 10배 늘렸는데 API가 여전히 느리다는 항의는 셋을 섞어 쓰기 때문에 나온다. 대역폭 증설은 처리량의 상한을 올릴 뿐, 패킷 하나가 서울에서 미국까지 다녀오는 시간(지연)은 1ms도 줄이지 못한다.

애니메이션이 보여주는 것

두 링크는 길이(거리)가 같고 폭(대역폭)만 다르다. 1단계에서 첫 패킷을 하나씩 보내 보면 두 링크 모두 정확히 같은 틱에 도착한다 — 지연은 거리·매체·홉 수가 정하지, 폭이 정하지 않는다.

이어지는 경주에서 위 링크는 틱마다 1개, 아래 링크는 3개씩 실어 나른다. 6개를 다 보내는 데 걸린 시간이 달라지고, 그래서 처리량(도착 수 ÷ 경과 시간)이 달라진다. 처리량은 어느 순간에도 대역폭을 넘지 못한다.

실무에서의 판별법

무엇이 문제인지에 따라 처방이 완전히 다르다. 셋을 재는 방법부터 다르다.

지연이 문제: ping·RTT가 크다. 처방은 거리 단축(엣지/CDN, 리전 이전), 홉 축소, 프로토콜 왕복 줄이기(HTTP/2, TLS 1.3, 커넥션 재사용).
처리량이 문제: 대역폭은 남는데 초당 처리 건수가 안 나온다. 처방은 병렬화(동시 연결·파이프라이닝), 병목 구간(서버 CPU, 디스크, 윈도 크기) 해소.
대역폭이 문제: 링크 사용률이 상시 90%를 넘고 큐잉 지연이 함께 는다. 이때만 증설이 답이다.
함정: 대역폭 사용률이 낮은데 느리면 그것은 거의 항상 지연 문제다. '회선 증설'은 돈만 쓰고 아무것도 바꾸지 못한다.

숫자 감각

1Gbps 링크에서 1KB 응답을 보내는 직렬화 시간은 8µs지만, 서울–버지니아 왕복 지연은 약 180ms다. 작은 응답의 체감 속도는 사실상 지연이 전부다. 반대로 10GB 백업 전송은 대역폭이 전부고 지연은 무시된다. 페이로드 크기가 어느 쪽이 지배하는지를 정한다.

기억할 것

지연 = 시간(한 개 도착), 대역폭 = 용량(상한), 처리량 = 실측(실제 도착률).
대역폭을 늘려도 지연은 줄지 않는다 — 첫 패킷 도착 시각은 두 링크가 같았다.
처리량 ≤ 대역폭. 처리량이 대역폭에 한참 못 미치면 병목은 링크 밖에 있다.
작은 페이로드는 지연이, 큰 페이로드는 대역폭이 체감 속도를 지배한다.