지연 시간 (Latency)

Diki 검색중...

#개념

일반적으로 지연 시간(latency)은 어떤 작업이 시작된 시점부터 결과가 나타날 때까지 걸리는 시간을 의미한지만, IT 분야에서는 데이터가 송수신되는 전체 경로에서 발생하는 시간이라고 볼 수 있다. 지연 시간은 단순한 ‘느림’이라는 감각적 표현을 넘어서, 기술적으로 측정 가능하고 개선 가능한 성능 지표로 간주된다. 특히 네트워크나 시스템 설계에서는 지연이 발생하는 원인을 세분화해 파악하고, 이를 최적화의 대상으로 삼는 것이 중요하다. IT 환경에서는 측정 방식이나 맥락에 따라 지연 시간을 여러 유형으로 나누어 정의하며, 대표적으로 단방향 지연 시간과 종단 간 지연 시간이 있다.

지연 시간 종류

단방향 지연 시간 (One-way latency): 하나의 데이터 패킷이 출발지에서 목적지까지 도달하는 데 걸리는 시간으로, 전송 지연(transmission latency)이라 불리기도 한다.
종단 간 지연 시간 (End-to-End latency): 사용자가 요청을 보낸 시점부터 응답을 완전히 수신할 때까지의 전체 소요 시간으로, 왕복 지연(Round Trip Time, RTT)이라 불리기도 한다.

지연 시간은 네트워크 및 통신 시스템의 성능을 평가하는 핵심 지표이며, 나아가 데이터의 수집, 처리, 분석 등 전반적인 시스템 응답 속도에 직접적인 영향을 미친다. 데이터 직무자는 단순히 네트워크 전송 속도보다는, 데이터를 요청하고 처리한 뒤 응답을 받기까지의 전체 흐름, 즉 실제 사용자가 결과를 얻기까지의 종단 간 지연 시간에 주목한다.

지연 시간은 단일 단계에서 발생하는 것이 아니라, 여러 단계에서 발생하는 지연이 누적된 결과다. 따라서 시스템의 성능을 효과적으로 진단하고 최적화하기 위해서는, 각 단계에서 어떤 지연 요소가 발생하는지를 정밀하게 분석할 필요가 있다. 이는 단순히 네트워크 속도나 서버 처리 능력만으로는 파악할 수 없는, 복합적인 병목 지점을 식별하는 데 핵심적인 단서가 된다. 특히 대규모 분산 시스템이나 실시간 데이터 분석 환경에서는, 이와 같은 세분화된 지연 분석이 사용자 경험 개선과 시스템 효율화의 출발점이 된다.

종단 간 지연을 구성하는 단계별 요소

DNS 조회(DNS Resolution): 도메인 이름을 IP 주소로 변환하는 데 걸리는 시간
TCP 연결 수립(TCP Handshake): 클라이언트와 서버 간의 연결을 설정하는 데 걸리는 시간
TLS 보안 협상(TLS Handshake): 보안 연결을 위한 인증 및 암호화 협상 과정에 걸리는 시간
대기 지연(Queuing Delay): 서버 또는 네트워크 장비가 이전 요청을 처리 중이라 요청이 큐에 대기하는 시간
전송 지연(Transmission Delay): 요청 데이터를 네트워크를 통해 서버로 전송하는 데 걸리는 시간
전파 지연(Propagation Delay): 전기적 신호 또는 광 신호가 전송 매체를 통해 이동하는 데 걸리는 시간
서버 처리 시간(Processing Delay): 서버가 요청을 파싱하고, 비즈니스 로직을 실행하는 시간
데이터베이스 접근 지연: 쿼리 실행, 인덱싱, 조인, I/O 작업 등에 걸리는 시간
응답 전송 및 수신(Response Transmission & Receiving): 서버가 응답을 전송하고 클라이언트가 수신하는 데 걸리는 시간

특히 데이터 애플리케이션에서는 수많은 요청이 동시에 발생하거나, 복수의 데이터 소스에서 데이터를 수집해야 하는 경우가 많다. 이때 개별 요청의 지연이 누적되면 전체 파이프라인 처리 시간, 쿼리 응답 시간, 또는 사용자-facing 대시보드의 로딩 속도에 큰 영향을 미친다. 따라서 지연 시간을 측정하고 줄이는 작업은 데이터 플랫폼의 성능 최적화에서 핵심적인 요소로, 지연 시간을 줄이기 위해 다음과 같은 전략들이 활용된다.

지연 시간을 줄이는 전략

캐싱(Caching): 자주 조회되는 API 응답이나 쿼리 결과를 애플리케이션 또는 게이트웨이 계층에서 캐싱하여 지연을 단축
사전 연산(Pre-computation): 실시간 계산이 오래 걸리는 처리 결과나 추천 결과 등을 미리 계산해 저장
비동기 처리/병렬 처리: 요청을 블로킹하지 않고 백그라운드에서 처리하거나, 여러 작업을 병렬로 처리하여 응답 속도를 향상
데이터 근접성(Data Locality): 데이터가 사용자 또는 엣지(Edge)에 가까울수록 지연이 짧아지기 때문에 CDN, 엣지 컴퓨팅, 지역별 캐시 서버 등을 활용

이 외에도 로드 밸런싱(Load Balancing), 샤딩(Sharding), 리플리케이션(Replication)등의 전략도 함께 사용된다. 이러한 전략들은 직접적으로 지연 시간을 줄이기도 하지만, 시스템의 부하를 분산하고 병목을 예방함으로써 간접적으로 전체적인 응답 속도와 안정성을 향상시킨다. 따라서 데이터 플랫폼을 설계하거나 운영할 때는 애플리케이션의 특성과 데이터 흐름을 기반으로 적절한 전략을 조합해 적용하는 것이 중요하다.

한편, 특정 데이터 시스템에서는 일반적인 수준의 지연 시간도 허용되지 않는 경우가 있다. 주식과 같은 금융 거래 시스템이나 온라인 게임, 실시간 추천 시스템 등에서는 밀리초(ms) 단위의 지연도 치명적인 결과를 초래할 수 있기 때문에 초저지연이 요구된다. 초저지연(Ultra-Low Latency)은 보통 1밀리초 이하의 응답(지연) 시간을 목표로 하며, 실시간성이 중요한 시스템에서 필수적인 요구 사항이다. 이러한 요구를 충족하기 위해 Apache Flink, Redpanda와 같은 실시간 데이터 처리 플랫폼이 등장하게 되었다. Java 기반의 스트리밍 프레임워크인 Apache Flink는 가비지 컬렉션(Garbage Collection, GC)으로 인한 지연이 발생할 수 있으므로, RocksDB와 같은 외부 상태 저장소를 활용하거나 객체 재사용, 메모리 사용 최적화 등을 고려해야 한다.