특명: 지연시간을 줄여라!

개발을 완료한 이후에도, 사용자는 여전히 서비스가 느리다고 느낄 수 있습니다. 이는 절대적인 처리 속도의 문제가 아니라, 지연 시간이 불안정하게 발생하기 때문입니다. 사용자 경험은 단순히 빠르다, 느리다로 결정되지 않습니다. 몇 ms의 지연 차이만으로도 사용자의 이탈률은 유의미하게 변화하며, 실제로 일부 대규모 서비스에서는 1ms의 지연이 수십만 원 단위의 비즈니스 손실로 이어지기도 합니다. 그렇다면 문제는 단순합니다. 속도를 무작정 높이는 것이 아니라, 지연이 어디에서 발생하고 있는지를 구분하고, 그에 맞는 전략을 선택해야 합니다. 이 글에서는 지연 시간을 Network, Server, Client 관점에서 나누어 살펴보고, 지연을 줄이기 위해 선택할 수 있는 설계 전략들을 정리해보려 합니다.

Latency vs Bandwidth vs Throughput

지연을 줄이기 위한 전략들을 살펴보기 이전에 용어 몇 가지를 잡고 가겠습니다.

Latency

클라이언트의 요청이 서버에 도달하고, 서버의 응답이 다시 클라이언트로 반환되기까지 걸리는 전체 시간입니다.

BandWidth

단위 시간당 네트워크를 통해 전송할 수 있는 최대 데이터 용량

최대 500mb까지만 전송할 수 있다.

Throughput

단위 시간 동안 시스템이 실제로 처리하여 전송한 데이터의 양을 의미합니다.

 

지연 시간 유형

지연 시간은 단일한 원인에서 발생하지 않습니다. 요청과 응답이 오가는 과정에서 지연은 네트워크, 서버, 클라이언트 등
서로 다른 계층에서 발생할 수 있습니다.

각 지연은 발생 위치와 원인이 다르며, 시스템 성능과 사용자 경험에 미치는 영향 또한 서로 다릅니다.
따라서 지연 시간을 효과적으로 줄이기 위해서는 어디에서 지연이 발생하고 있는지를 먼저 구분하는 것이 중요합니다.

지연은 데이터 처리 및 전달 파이프라인의 여러 단계에서 발생할 수 있습니다.
각 유형의 지연 시간은 서로 다른 원인에서 비롯되며 특정 방식으로 시스템 성능에 영향을 미칩니다.

네트워크 지연 시간

네트워크 지연 시간은 클라이언트와 서버 간에 데이터가 이동하는 과정에서 발생하는 지연을 의미합니다.
이는 서버의 처리 속도와 무관하게, 데이터가 물리적으로 이동하는 거리와 경로에 의해 크게 영향을 받습니다.

물리적 거리가 멀수록 지연 시간은 증가합니다. 예를 들어, 사용자의 위치가 서울이고 서버가 부산에 위치해 있다면,
동일한 요청이라도 서버가 동일한 지역에 위치한 경우보다 더 긴 시간이 소요됩니다.

이외에도 네트워크 지연은 다양한 요인에 의해 발생할 수 있습니다. 네트워크 트래픽이 과도하게 몰리는 경우 패킷 전달이 지연될 수 있으며,
데이터가 여러 중간 라우터를 거쳐야 할수록 지연 시간은 증가합니다. 또한 TCP와 같은 네트워크 프로토콜에서 발생하는 핸드셰이크 과정 역시 초기 연결 단계에서 추가적인 지연을 발생시킬 수 있습니다.

서버 지연 시간

서버 지연 시간은 서버가 클라이언트의 요청을 처리하고, 그 결과를 응답으로 반환하기까지 소요되는 시간을 의미합니다.

서버 지연은 주로 애플리케이션 내부 요인에 의해 발생합니다. 비효율적인 코드로 인한 불필요한 연산,
동기 블로킹 방식의 처리, 또는 잘못 설계된 백엔드 아키텍처는 요청 처리 시간을 증가시키는 주요 원인이 됩니다.

특히 데이터베이스 접근 과정에서의 비효율적인 쿼리나 적절한 인덱스가 없는 경우,
서버 지연은 급격히 증가할 수 있으며 이는 곧 사용자 경험 저하로 이어집니다.

클라이언트 측 지연 시간

클라이언트 측 지연 시간은 서버로부터 수신한 데이터를 렌더링하거나 처리하는 과정에서
사용자의 장치(예: 브라우저 또는 애플리케이션)에서 발생하는 지연을 의미합니다.

이 지연은 서버 성능과 무관하게 발생할 수 있으며, 주로 렌더링 과정의 복잡성, 메인 스레드를 차단하는 비효율적인 코드 실행,
또는 과도한 리소스 처리로 인해 발생합니다.

또한 사용자의 기기 성능에 따라 동일한 데이터라도 처리 속도에는 차이가 발생할 수 있으며,
이는 곧 사용자 경험의 편차로 이어집니다.

지연 발생이 어디에서 되는지 알았으니 어떻게 해결 할 수 있을까?

인기있는 8가지 방법을 살펴봅시다.

 

 

캐싱

- 서버 지연시간 감소
- 읽기 속도 감소
- Latency, Throughput

캐싱은 자주 사용되는 데이터를 임시 저장소에 보관하여, 매 요청마다 동일한 연산이나 데이터 조회를 반복하지 않도록 하는 기술입니다.

서버는 요청을 처리할 때 먼저 캐시를 확인하고, 캐시에 데이터가 존재하는 경우 데이터베이스 접근이나
복잡한 연산을 수행하지 않고 즉시 응답할 수 있습니다. 이로 인해 서버의 처리 부담이 감소하며,
결과적으로 서버 지연 시간이 크게 줄어들게 됩니다.

2026.01.09 - [개발] - 캐시를 이용하는 방법들

콘텐츠 전송 네트워크(CDN)

- 네트워크 지연시간 감소
- Latency
- Bandwidth

콘텐츠 전송 네트워크(CDN)는 이미지, 동영상, 웹 페이지와 같은 정적 콘텐츠를
사용자와 가까운 위치에 분산 배치된 서버에서 제공하는 네트워크 구조입니다.

네트워크 지연이 발생하는 주요 원인 중 하나는 서버와 사용자 간의 물리적 거리입니다.
사용자의 요청이 먼 지역에 위치한 서버까지 이동해야 할 경우, 요청과 응답의 왕복 시간(RTT)은 자연스럽게 증가하게 됩니다.

CDN은 이러한 문제를 해결하기 위해 콘텐츠를 여러 지역의 엣지 서버에 미리 캐싱하고,
사용자의 요청을 가장 가까운 서버로 라우팅합니다.
이를 통해 데이터 이동 거리를 줄이고, 결과적으로 네트워크 지연 시간을 직접적으로 감소시킵니다.

로드 벨런싱

- 서버 지연 시간 감소
- Latency
- Throughput

로드 밸런싱은 들어오는 트래픽이나 작업 부하를 여러 서버에 분산시켜 단일 서버에 요청이 집중되는 것을 방지하는 구조입니다.

단일 서버가 모든 요청을 처리할 경우, 요청 대기 시간이 증가하며 서버 지연 시간이 급격히 늘어날 수 있습니다.
반면 여러 서버로 요청을 분산하면 각 서버가 처리해야 하는 부하가 줄어들고,
결과적으로 요청 처리 지연을 안정적으로 낮출 수 있습니다.

로드 밸런서는 서버의 상태에 따라 요청을 분산하며, 라운드 로빈, 최소 연결 수와 같은 알고리즘을 통해
트래픽을 효율적으로 분배합니다. 이를 통해 서버 과부하를 방지하고, 전체 시스템의 응답 안정성과 가용성을 향상시킬 수 있습니다.

비동기 처리

- 클라이언트, 서버 지연 시간 감소
- Latency

비동기 처리는 작업을 독립적으로 실행하여 메인 스레드나 프로세스를 차단하지 않는 처리 방식입니다.

동기 방식에서는 하나의 작업이 완료될 때까지
다음 작업이 대기해야 하지만, 비동기 시스템에서는 작업을 요청한 이후 결과를 기다리지 않고 다른 작업을 계속 수행할 수 있습니다.

이로 인해 서버는 블로킹 상태에 빠지지 않고 동시에 더 많은 요청을 처리할 수 있으며,
사용자는 처리 완료를 기다리지 않아도 되기 때문에 체감 지연 시간이 크게 감소하게 됩니다.

데이터베이스 인덱싱

- 서버 지연시간 감소
- 읽기 속도 감소

데이터베이스 인덱싱은 인덱스라는 특수한 데이터 구조를 사용하여 쿼리 수행 시 필요한 데이터의 탐색 범위를 줄이는 기술입니다.

인덱스는 책의 색인과 유사하게 동작하며, 데이터베이스가 전체 테이블을 스캔하지 않고도
필요한 데이터의 위치를 빠르게 찾을 수 있도록 도와줍니다.

이를 통해 불필요한 디스크 I/O와 연산을 줄일 수 있으며, 결과적으로 쿼리 처리 시간이 단축되어 서버 지연 시간이 크게 감소하게 됩니다.

데이터 압축

- 클라이언트 지연 시간 감소
- Latency
- Bandwidth

데이터 압축은 네트워크를 통해 전송되는 데이터의 크기를 줄여, 전송에 필요한 시간과 대역폭 사용량을 최소화하는 기술입니다.

클라이언트와 서버 간에 전달되는 데이터의 양이 줄어들면 네트워크를 통해 데이터를 주고받는 데 걸리는 시간이 단축되며,
그 결과 사용자는 더 빠르게 응답을 받아볼 수 있습니다.

이러한 특성으로 인해 데이터 압축은 리소스 크기가 큰 웹 애플리케이션이나비디오 스트리밍과
같은 대역폭 집약적인 시스템에서 클라이언트 체감 지연 시간을 줄이는 데 중요한 역할을 합니다.

연결 재사용

- 네트워크 지연시간 감소
- Latency
- Bandwidth

2025.10.21 - [네트워크] - HTTP에 대해 최대한 조사해보자 - 1   
2025.10.22 - [네트워크] - HTTP에 대해 최대한 조사해보자 - 2

연결 재사용은 클라이언트와 서버 간의 연결을 매 요청마다 새로 생성하지 않고,
하나의 연결을 유지하여 여러 요청에 재사용하는 방식입니다.

HTTP는 TCP를 기반으로 동작하며, 새로운 TCP 연결을 생성할 때마다 3-way 핸드셰이크 과정이 필요합니다.
이 과정은 한 번만 발생하면 큰 문제가 되지 않지만, 요청마다 반복될 경우 네트워크 지연을 크게 증가시키는 원인이 됩니다.

초기 HTTP에서는 요청마다 새로운 연결을 생성하는 방식이 일반적이었으며,
이는 불필요한 연결 설정 비용으로 인해 성능 저하를 유발했습니다.

이후 HTTP/1.1에서는 Keep-Alive를 통해 연결 재사용이 가능해졌고, HTTP/2에 이르러서는 **다중화(multiplexing)**가 도입되어
하나의 TCP 연결 위에서 여러 요청과 응답을 동시에 처리할 수 있게 되었습니다. 이를 통해 연결 설정 비용을 최소화하고,
결과적으로 네트워크 지연 시간을 효과적으로 줄일 수 있게 되었습니다.

프리캐싱

- 클라이언트 지연 시간 감소
- 서버 지연 시간 감소
- Latency

프리캐싱은 사용자가 특정 데이터나 리소스를 명시적으로 요청하기 전에, 접근 가능성이 높은 데이터를 미리 캐시에 적재하는 전략입니다.

자주 사용될 것으로 예상되는 데이터를 사전에 준비해두면 사용자의 요청 시점에는
추가적인 계산이나 데이터 조회 없이 즉시 응답을 제공할 수 있습니다.

이로 인해 사용자는 더 빠른 응답을 경험하게 되며, 서버 역시 요청 시점의 부하가 줄어들어
처리 지연을 효과적으로 완화할 수 있습니다.

 

마무리

지연 시간을 줄인다는 것은 단순히 속도를 높이는 문제가 아닙니다. 어떤 경우에는 지연 시간을 줄이는 것이 중요하고,
어떤 경우에는 대역폭을 확장하거나 시스템의 처리량을 늘리는 것이 더 효과적인 선택이 될 수 있습니다.
또한 지연이 발생하는 주체가 서버인지, 네트워크인지, 클라이언트인지에 따라 적용해야 할 전략 역시 달라집니다.

흥미로운 점은 많은 최적화 전략이 네트워크나 클라이언트보다 서버의 처리 지연을 줄이는 방향에 집중되어 있다는 사실입니다.
이는 대부분의 성능 문제가 결국 서버의 설계와 처리 방식에서 발생하기 때문일 것입니다.
결국 성능 개선이란 무작정 빠르게 만드는 것이 아니라,
어디에서 지연이 발생하는지를 구분하고 그에 맞는 전략을 선택하는 과정이라고 생각합니다.

 

출처
https://blog.bytebytego.com/p/top-strategies-to-reduce-latency?utm_source=publication-search