지연시간(Latency) vs 처리량(Throughput): 빠름과 많이 처리함은 왜 다른가

느린데도 "잘 돌아간다"는 말이 나오는 순간

지연시간(Latency)과 처리량(Throughput)은 웹·앱·서버가 "느리다/빠르다"를 말할 때 서로 다른 문제를 가리키는 지표다.

예를 들어 주문 버튼을 누르면 화면 반응은 2초씩 늦는데, 하루 처리 건수는 평소처럼 잘 나오는 경우가 있다.

반대로 화면 반응은 즉각적인데, 피크 시간에 사용자 수가 늘면 오류가 늘고 처리 건수가 급락하는 경우도 있다.

이 두 상황을 같은 "성능 문제"로 묶어 버리면, 개선 방향이 반대로 가서 시간이 낭비되기 쉽다.

핵심 개념 1: 지연시간은 '한 번 요청이 끝나기까지 걸리는 시간'이다

지연시간은 사용자가 요청을 보낸 뒤 결과를 받기까지 걸리는 시간(왕복 또는 처리 완료 시간)을 뜻한다.

핵심 특징은 "체감 속도"와 강하게 연결된다는 점이다. 버튼 클릭 후 화면이 늦게 바뀌면 지연시간이 길다고 느낀다.

지연시간은 평균값만 보면 착시가 생기므로, p95/p99 같은 상위 구간 지표가 함께 쓰인다.

주의점은 지연시간을 줄이려는 최적화가 항상 처리량을 늘리지는 않는다는 점이다.

예를 들어 캐시를 늘리면 특정 요청의 지연시간은 줄지만, 캐시 무효화·동기화 비용이 커지면 피크 처리량이 오히려 줄 수 있다.

또한 지연시간은 네트워크, 큐 대기, 락 경합, GC, 디스크 I/O, 외부 API 등 "대기"가 끼는 지점에서 급격히 늘어난다.

지연시간과 처리량이 다른 지표인 이유

핵심 개념 2: 처리량은 '단위 시간에 처리하는 양'이다

처리량은 초당 요청 수(RPS), 초당 트랜잭션(TPS), 초당 전송 바이트(MB/s)처럼 "시간당 얼마나 많이 처리하는가"를 뜻한다.

핵심 특징은 시스템이 버틸 수 있는 최대 부하와 연결된다는 점이다. 사용자가 늘어날수록 처리량 한계가 드러난다.

처리량을 올리는 대표 방법은 병렬성 확대(스레드/워크풀), 비동기화, 배치 처리, 수평 확장(서버 증설)이다.

주의점은 처리량을 높이려는 설정이 지연시간을 악화시킬 수 있다는 점이다.

예를 들어 큐에 더 많이 쌓아 한 번에 처리하면 평균 처리량은 올라가지만, 개별 요청은 큐에서 더 오래 기다려 지연시간이 늘 수 있다.

또한 처리량은 "측정 창"에 따라 다르게 보이므로, 같은 기간·같은 조건에서 비교하지 않으면 판단이 흔들린다.

둘이 헷갈리는 지점과 비교표

자주 나오는 오해는 "처리량이 높으면 빠르다"는 생각이다.

처리량이 높아도 지연시간이 길 수 있고, 지연시간이 짧아도 처리량이 낮아 금방 막힐 수 있다.

항목	설명
무엇을 뜻하나	지연시간은 한 요청이 끝나는 데 걸리는 시간, 처리량은 단위 시간에 처리되는 요청/데이터의 양이다.
사용자 체감	지연시간이 길면 "느리다"가 바로 체감된다. 처리량이 부족하면 "특정 시간대에만 터진다"로 체감된다.
나빠지는 신호	지연시간은 p95/p99 상승, 스파이크가 신호다. 처리량은 큐 적체, 오류율 상승, 타임아웃 증가가 신호다.
개선 방향	지연시간은 대기 제거(네트워크/락/IO/외부호출), 처리량은 병렬성·확장·배치·비동기화가 중심이다.

YES/NO로 먼저 갈라타는 체크리스트

• YES/NO: 사용자가 적을 때도 화면 반응이 일관되게 느린가?
• YES/NO: 사용자가 늘어날수록 갑자기 오류(429/503/504)가 늘어나는가?
• YES/NO: 평균은 괜찮은데 p95/p99 만 급격히 올라가는가?
• YES/NO: CPU는 여유인데 큐 길이(대기열)만 계속 늘어나는가?
• YES/NO: 같은 기능이 특정 네트워크 환경(사내망/VPN/모바일)에서만 느린가?

첫 항목이 YES면 지연시간 중심, 둘째 항목이 YES면 처리량 한계 중심으로 진단 방향을 잡는 편이 빠르다.

병목을 찾는 순서와 실전 예시

지연시간과 처리량을 구분한 뒤에는 "어디서 시간이 쓰이는가"와 "어디서 막히는가"를 분리해 확인하는 절차가 필요하다.

1. 지연시간 분해: 지연시간 분해부터 한다(경로: 크롬 개발자도구 - Network - 요청 선택 - Timing / 체크 포인트: Waiting(TTFB)과 Content Download 중 어디가 긴지).
2. 처리량 한계: 처리량 한계를 본다(경로: APM/모니터링 대시보드 - RPS/TPS / 체크 포인트: 트래픽이 늘 때 응답시간과 오류율이 함께 오르는지).
3. 큐 대기: 큐 대기를 확인한다(경로: 서버 지표 - 작업 큐 길이, 스레드풀 대기 / 체크 포인트: 큐가 늘면서 p95가 상승하는지).
4. 공유 자원: 공유 자원 경합을 점검한다(경로: DB 커넥션 풀, 락 대기, 파일 I/O / 체크 포인트: "대기 시간" 로그가 증가하는지).
5. 네트워크 분리: 네트워크 영향 구간을 분리한다(경로: 동일 요청을 다른 회선/VPN OFF로 재시도 / 체크 포인트: RTT 변화가 지연시간 변화와 같이 움직이는지).
6. 개선 적용: 개선안을 지연시간용/처리량용으로 나눠 적용한다(경로: 캐시·쿼리·락 개선 vs 확장·비동기·배치 / 체크 포인트: 지표가 목표 방향으로만 움직이는지).

실전에서 흔한 장면으로 "반응은 느린데 처리 건수는 높은" 상황을 가정한다.

모니터링 화면에 다음처럼 보일 수 있다.

관측 예시(민감정보 제거)
- Throughput: 1,200 req/s (피크에서도 유지)
- Latency: p50=120ms, p95=980ms, p99=2,400ms
- Error rate: 0.2%
화면 문구 예시: "요청 처리 중..."이 1초 이상 지속

처리량은 충분한데 p95/p99 지연시간만 튀는 패턴이므로 "대기"가 끼는 지점을 찾는 편이 맞다.

이때 선택이 잘 맞는 접근은 요청 경로를 쪼개서 "어느 단계에서 기다리는가"를 계측하는 것이다.

잘못된 접근은 서버를 무작정 증설해 처리량만 늘리는 것이다. 처리량은 이미 충분하므로 체감 개선이 작을 수 있다.

확인/해결은 DB 커넥션 풀 대기, 특정 락 경합, 외부 API 호출 지연 같은 후보를 한 번에 하나씩 제거하면서 p95/p99가 내려가는지 보는 방식이 재현성이 높다.

지연시간과 처리량을 구분해 진단하는 6단계

결론

지연시간은 "한 번 요청이 끝나는 데 걸리는 시간"이고, 처리량은 "단위 시간에 처리하는 양"이라서 같은 빠름을 의미하지 않는다.

체감이 느리면 지연시간 분해(대기 제거)부터, 피크에 터지면 처리량 한계(적체/오류)부터 보는 순서가 효율적이다.

평균만 보지 말고 p95/p99와 큐 적체·오류율을 같이 보면, 빠름 문제와 많이 처리 문제를 혼동할 가능성이 줄어든다.

연계 주제로는 p95/p99 해석 방법, 큐잉(Queueing)과 적체 제어, 백프레셔(Backpressure) 설계가 이어진다.

FAQ

Q1. 처리량이 높으면 지연시간도 자동으로 짧아지는가

그렇지 않다. 처리량이 높아도 큐 대기나 외부 호출 지연이 있으면 지연시간이 길어질 수 있다.

처리량은 "버티는 힘"이고 지연시간은 "한 번에 얼마나 빨리 끝나는가"라서 분리해 봐야 한다.

Q2. 지연시간을 줄이려다 처리량이 떨어지는 경우는 언제인가

동기 처리로 바꾸거나, 과도한 검증·락으로 "대기"를 늘리면 처리량이 떨어질 수 있다.

반대로 배치·큐로 처리량을 높이면 개별 요청은 더 오래 기다려 지연시간이 늘 수 있다.

Q3. 현장에서 가장 먼저 확인할 지표 조합은 무엇인가

지연시간은 p95/p99, 처리량은 RPS/TPS, 그리고 함께 오류율과 큐 길이를 보는 조합이 안정적이다.

이 네 가지를 같은 시간축에서 보면 "느림"과 "막힘"이 다른 문제인지 빠르게 갈라진다.