스트리밍 서비스의 지연시간·대역폭·전송 안정성

스트리밍 서비스

현대 디지털 생태계에서 비디오 스트리밍 트래픽은 전체 인터넷 트래픽의 압도적인 비중을 차지하고 있다. 그러나 '스트리밍'이라는 단일 용어 아래에는 기술적으로 완전히 상이한 요구사항을 가진 서비스들이 공존한다. 넷플릭스와 같은 VOD(Video on Demand, 주문형 비디오), 유튜브 라이브·트위치·치지직과 같은 대규모 라이브 방송 서비스, 그리고 줌(Zoom)이나 클라우드 게이밍과 같은 ULL(Ultra-Low Latency, 초저지연) 서비스는 겉보기에는 유사한 영상 전송 서비스로 보이지만, 그 이면의 아키텍처는 근본적으로 다른 물리학적·논리적 제약 조건 위에서 설계된다.

VOD

VOD는 온라인으로 드라마나 영화, 다큐멘터리 등 영상 매체를 대여하거나 구매해 시청할 수 있는 서비스다. VOD 서비스의 가장 큰 특징은 콘텐츠가 이미 정해져 있고 중간에 변하지 않는다는 것이다. 따라서 실시간으로 콘텐츠가 생성되는 것에 대해 고려할 필요가 없고, 대신 좋은 화질의 영상을 효율적으로 전달하는 것이 최우선 과제가 된다.

라이브 스트리밍

라이브 스트리밍은 실시간으로 생성되는 콘텐츠를 전송해야 하므로 "미래의 데이터를 미리 가져올 수 없다"는 제약이 있다. 목표는 수백만 명의 동시 시청자를 수용하면서도 TV 방송 수준의 지연시간(1030초) 또는 그 이하(25초)를 유지하는 것이다.

초저지연 서비스

ULL 서비스(클라우드 게이밍, 화상 회의, 실시간 경매)는 상호작용에 즉시 반응하는 것이 무엇보다 중요하다. 1초 미만(sub-second), 이상적으로는 200ms 이하의 지연시간을 목표로 한다. 리그 오브 레전드 같은 온라인 게임이나 Xbox 클라우드 게이밍을 생각하면 직관적으로 와닿을 것이다.

지연시간, 대역폭, 전송 안정성

이들 서비스는 모두 네트워크 위에서 동작한다. 그래서 무엇보다도 네트워크의 성능이 이들 서비스의 품질에 커다란 영향을 끼친다. 네트워크의 성능을 결정하는 여러 가지 요인 중에서도 스트리밍 서비스의 품질을 판가름하는 핵심 요소는 바로 지연시간, 대역폭, 그리고 전송 안정성이다.

지연시간

지연시간은 데이터 패킷의 첫 번째 비트가 송신측을 떠나 수신측에 도달하거나(단방향 지연), 왕복하여 다시 송신측으로 돌아오는 데 걸리는 시간 — RTT(Round-Trip Time, 왕복 시간) — 을 의미한다. 과거에는 대역폭이 네트워크 성능의 주된 척도였으나, 대역폭이 풍부해진 현대 네트워크 환경, 특히 고빈도 매매(high-frequency trading)나 실시간 클라우드 게이밍, 로봇을 이용한 원격 수술처럼 상호작용이 중요한 환경에서는 지연시간이 QoE(Quality of Experience, 체감 품질)를 결정짓는 가장 지배적인 요소로 작용한다.

무엇이 지연시간을 만드는가

무엇이 지연시간을 좌우하는지 알기 위해서는 우선 지연시간이 어떻게 분류될 수 있는지를 알아야 한다. 데이터 패킷이 송신지에서 수신지까지 도달하는 과정은 수많은 요소들이 맞물려 이루어지는 복잡한 과정이고, 그렇기 때문에 지연시간 전체를 다음과 같이 구간을 나누어 볼 수 있다.

1. 데이터 요청: 클라이언트가 데이터를 요청하는 패킷을 만들어 서버로 보내려 한다. 그러려면 우선 클라이언트의 네트워크 입출력 장치를 차지해야 하는데, 다른 프로세스가 이 장치를 사용하고 있을 수도 있고, 기기 자체의 성능이 좋지 않아 컨텍스트 스위칭이나 네트워크 출력 자체에서 지연이 발생할 수도 있다.
2. 네트워크 전송: 클라이언트를 떠난 패킷은 스위치, 라우터, 게이트웨이 등을 거쳐 목적지를 찾아 인터넷을 떠돈다. 이때 회선 속도의 제한, 물리적 거리, 비효율적인 경로 선택 등이 지연시간을 만든다.
3. 서버 응답 처리: 요청이 서버에 도착하면 서버는 데이터베이스를 조회하거나 API를 호출하는 등 다양한 작업을 수행한다. 서버 부하, 느린 데이터베이스 응답, 캐싱 부족으로 늘어난 입출력 등 서버 쪽 요인들이 지연시간을 만든다.
4. 응답 데이터 전송: 서버가 응답 데이터 패킷을 만들어 인터넷으로 내보낸다. 네트워크 대역폭 부족이나 패킷 유실로 인한 재전송 등이 지연시간을 만든다.
5. 클라이언트 데이터 렌더링: 응답이 클라이언트에 도착해도 로딩이 느리거나, 브라우저 최적화가 부족하거나, 그래픽 처리 속도가 낮으면 그 또한 지연시간이 된다.

이 모든 과정을 종합했을 때, 지연시간을 만드는 핵심 요소는 전파 지연, 전송 지연, 처리 지연, 그리고 큐잉 지연이다.

전파 지연(Propagation Delay)

전파 지연propagation delay은 그 무엇도 빛보다 빠른 속도로 갈 수 없다는 물리적 한계 때문에 발생한다. 신호가 물리적 매체(medium)의 한 지점에서 다른 지점으로 이동하는 데 소요되는 시간으로, 거리와 매체 내 신호의 전파 속도에 의해 결정되며, 이는 특수 상대성 이론에 따른 물리적 한계, 즉 빛의 속도에 종속된다.

이 지연 요소는 네트워크 엔지니어링이나 알고리즘 최적화로 줄일 수 없는 지연시간의 하한선을 형성한다. 대륙 횡단 통신이나 정지 궤도 위성 통신에서는 전파 지연이 전체 지연시간의 지배적인 요소가 된다. 예를 들어 런던과 뉴욕 간의 왕복 통신에서 물리적 거리로 인한 최소 RTT는 약 60ms 수준이며, 아무리 장비를 최적화해도 그 이하로 낮출 수는 없다.

전송 지연(Transmission Delay / Serialization Delay)

전송 지연transmission delay은 패킷의 모든 비트를 네트워크의 노드 사이의 연결 통로에 밀어 넣는 데 걸리는 시간이다. 이는 패킷의 크기 $L$을 연결 통로의 전송 속도 $R$로 나눈 값($L/R$)으로 계산된다. 연결 통로의 전송 속도가 증가하면 전송 지연은 반비례하여 감소하기 때문에 네트워크의 전송 속도가 빠를수록 전송 지연이 차지하는 비중은 일반적으로 감소하지만, 대역폭이 적은 환경에서는 무시할 수 없는 요소가 된다. 특히 비디오 프레임과 같이 큰 데이터 청크를 MTU(Maximum Transmission Unit, 최대 전송 단위 — 보통 1500바이트) 크기로 분할하고 재조립하는 과정에서 지연이 발생한다.

처리 지연(Processing Delay)

처리 지연processing delay은 패킷이 라우터, 스위치, 또는 엔드 호스트에 도착했을 때 헤더를 분석하고, 비트 오류를 검사하며, 라우팅 테이블을 조회하여 출력 포트를 결정하는 데 소요되는 시간이다. 이는 전적으로 네트워크 장비의 하드웨어 성능과 소프트웨어 알고리즘의 효율성에 달려 있다.

큐잉 지연(Queuing Delay)

큐잉 지연(queuing delay)은 패킷이 출력 링크로 전송되기 위해 라우터의 버퍼(queue)에서 대기하는 시간이다. 앞선 세 가지 지연 요소가 비교적 고정적인 값인 반면, 큐잉 지연은 네트워크 트래픽의 밀도와 버스트(burst, 트래픽이 급격하게 집중되는 현상)가 발생하는 양상에 따라 0에서 무한대까지 변동할 수 있는 확률적 성격을 띤다. 짧은 시간 동안 트래픽이 몰리면 큐잉 지연이 급격히 증가하고, 버퍼가 가득 차면 패킷 손실(packet loss)이 발생하며, 이는 TCP 재전송을 유발하여 사용자 관점에서는 지연시간이 수 초 이상 늘어나게 된다.

대역폭

대역폭은 일정 시간 동안 네트워크나 통신 채널에서 전송할 수 있는 데이터의 최대 크기다. 보통 대역폭을 도로에 비유해 차선이 많을수록 대역폭이 크다고 하는데, 대역폭이 넓을수록 더 많은 패킷을 동시에 보낼 수 있고, 따라서 더 많은 데이터를 동시에 송출할 수 있게 된다. 대역폭은 네트워크의 성능을 나타내는 가장 직관적인 지표이지만, 엔지니어링 관점에서 대역폭은 단순한 '속도'가 아니라 주파수 스펙트럼의 폭, 신호 처리 능력, 그리고 프로토콜 효율성이 결합된 복합적인 개념이다. 대역폭에 대해 이야기하기 위해서는 우선 대역폭과 유사한 개념들을 구분할 필요가 있다.

• 대역폭은 물리적 계층이나 데이터 링크 계층에서 제공하는 이론적인 최대 전송 속도이다. 아날로그 통신에서는 신호가 점유하는 주파수 대역의 폭(Hz)을 의미하며, 디지털 통신에서는 초당 비트 수(bps)로 표현된다.
• 처리량throughput은 실제 네트워크 환경에서 단위 시간당 성공적으로 전송된 데이터의 총량이다. 이는 대역폭뿐만 아니라 지연시간, 패킷 손실, 프로토콜 윈도우¹의 크기, 네트워크 혼잡도 등 다양한 요인에 의해 제한받기 때문에, 처리량은 항상 대역폭보다 작거나 같다.
• 굿풋(goodput)은 응용 프로그램 입장에서 유효하게 전달된 데이터의 전송 속도이다. 전체 처리량에서 물리 계층 헤더, IP/TCP 헤더, 그리고 재전송된 중복 패킷 데이터를 제외한 순수 페이로드(payload)의 전송률을 의미한다. 사용자가 체감하는 다운로드 속도는 바로 이 굿풋이다.

수도관에 비유하자면 대역폭은 파이프의 직경, 처리량은 실제 흐르는 물의 양, 굿풋은 목적지에 도착하여 실제로 사용 가능한 물의 양이다.

그림 1. 수도관에 비유한 대역폭, 처리량, 굿풋의 관계.

전송 안정성

전송 안정성은 데이터가 송신측에서 수신측으로 손실, 중복, 순서 바뀜 없이 정확하게 전달되는 것을 보장하는 속성이다. 인터넷의 네트워크 계층(IP)은 기본적으로 '최선의(best-effort)' 전달만을 제공할 뿐 패킷의 전달을 보장하지 않는다. 따라서 신뢰성 보장의 책임은 주로 전송 계층transport layer이나 응용 계층application layer으로 위임된다. 이 전송 안정성을 해치는 주요 현상으로는 지터와 패킷 손실을 꼽을 수 있다.

지터(Jitter)

지터(jitter)는 패킷이 도착하는 시간의 변동성, 즉 지연시간의 변동성을 의미한다. 패킷들이 송신측에서는 일정한 간격으로 출발했더라도, 네트워크를 통과하면서 각기 다른 큐잉 지연을 겪으면 수신측에는 불규칙한 간격으로 도착하게 된다.

그림 2. 일정한 간격으로 출발한 패킷들이 불규칙한 간격으로 도착하는 지터 현상.

평균 지연시간이 낮더라도 지터가 높으면 실시간 음성이나 비디오 스트리밍은 심각한 품질 저하를 겪는다. 패킷이 예상보다 늦게 도착하면 송출이 끊기고, 너무 빨리 도착하면 패킷이 손실될 수 있다.

패킷 손실

패킷 손실은 네트워크 혼잡으로 인해 라우터 큐에서 패킷이 폐기되는 현상(tail drop)이다. 생각보다 자주 발생하기 때문에, 패킷 손실을 처리하는 방식은 서비스 아키텍처를 가르는 분수령이 된다. 패킷 손실이 발생하는 원인은 크게 세 가지가 있다.

• 혼잡congestion: 라우터나 스위치의 입력 트래픽이 처리 용량을 초과하여 버퍼가 가득 찰 때 발생한다. 유선 인터넷 환경에서 패킷 손실이 일어나는 가장 흔한 원인이며, 네트워크의 용량 한계를 의미하므로 송신 속도를 줄이는 혼잡 제어로 대응해야 한다.
• 비트 오류bit error: 물리적 매체의 열잡음, 전자기 간섭, 신호 감쇠 등으로 인해 데이터 비트가 변형되는 현상이다. 무선 네트워크나 구리선 환경에서 빈번하게 발생한다.
• 경로 변경 및 순서 뒤바뀜: 네트워크의 동적 라우팅으로 인해 패킷 순서가 바뀌거나, 루프에 빠져 패킷의 유효기간이 만료되어 소멸하는 경우도 발생한다.

오류 제어 메커니즘

신뢰성을 확보하기 위한 오류 복구 전략은 크게 다시 보내달라고 요청하는 ARQ(Automatic Repeat Request, 자동 재전송 요청)와, 스스로 고칠 수 있는 정보를 미리 보내는 FEC(Forward Error Correction, 순방향 오류 정정)로 양분된다.

ARQ는 채널 상태가 양호할 때는 오버헤드가 거의 없으며 데이터 무결성을 완벽하게 보장한다. 그러나 재전송을 위해 최소 1 RTT의 추가 지연이 발생하므로, 지연시간에 민감한 실시간 스트리밍에서는 치명적인 끊김을 유발할 수 있다. TCP 기반의 프로토콜이 이 전략을 사용한다.

FEC는 송신측이 원본 데이터에 수학적 알고리즘을 적용하여 생성한 중복 정보(parity/redundancy packet)를 함께 전송하는 방식이다. 수신측은 도착한 패킷들 중 일부가 손실되더라도 함께 도착한 중복 패킷을 이용하여 손실된 데이터를 수학적으로 역산하여 복구할 수 있다. 재전송 지연 없이 일정한 지연시간을 보장하지만, 오류가 없더라도 항상 중복 데이터를 보내야 하므로 대역폭 오버헤드가 발생하며, 손실률이 FEC의 복구 한계를 초과하면 데이터 복구가 불가능해진다. UDP 기반의 프로토콜이 이 전략을 사용한다.

Trade-off

모든 내용을 종합했을 때, 스트리밍 서비스는 지연시간이 낮을수록, 대역폭이 클수록, 전송이 안정적일수록 좋다는 것을 알 수 있다. 하지만 지연시간, 대역폭, 안정성을 모두 잡는다는 것은 말처럼 쉬운 일이 아니며, 현실에서는 세 요소가 시스템 설계라는 제약 조건 아래 서로 밀접하게 얽혀 트레이드오프(trade-off) 관계를 형성하거나 상호 제약 조건으로 작용한다.

지터 버퍼(Jitter Buffer)와 지연시간

앞서 평균 지연시간이 낮더라도 지터가 높으면 실시간 음성이나 비디오 스트리밍이 심각한 품질 저하를 겪는다는 것을 보았다. 이를 해결하기 위해 수신측 애플리케이션은 지터 버퍼(jitter buffer)를 두어 패킷을 일시 저장하고 일정 시간 지연시킨 후 규칙적으로 재생한다. 하지만 지터 버퍼의 크기를 늘리면 안정성은 높아져도 전체적인 상호작용 지연시간이 증가하는 딜레마가 발생한다.

대역폭과 처리량의 괴리

대역폭은 통신 채널의 이론적 최대 용량을 의미하지만, 실제 스트리밍 품질을 결정하는 것은 처리량이다. 잡음이 있는 채널에서 정보를 전송할 수 있는 최대 속도에 대한 정리인 섀넌-하틀리 정리(Shannon-Hartley theorem)에 따르면, 채널의 용량 $C$는 대역폭 $B$와 수신기에서의 신호 대 잡음비 $S/N$에 의해 결정된다.

$$C = B \times \log_2(1 + \frac{S}{N})$$

이 공식은 스트리밍 아키텍처에 중요한 시사점을 준다. 물리적 대역폭이 충분하더라도, 무선 간섭이나 케이블의 누화² 등으로 인해 $S/N$ 값이 감소하면 실제 처리량은 급격히 떨어진다.

VOD, Live, ULL

이제 VOD와 라이브, 그리고 초저지연 스트리밍을 아키텍처의 관점에서 다시 볼 때가 왔다. 각각의 아키텍처를 비교분석하며 왜 세 서비스가 서로 다른 아키텍처를 요구하는지 알아보자.

VOD: 품질과 효율성의 극대화

VOD는 콘텐츠가 미리 정해져 있을 뿐 아니라, 사용자가 언제든 재생하고 앞뒤로 스킵할 수 있으며, 수 초에서 수십 초의 지연은 크게 문제 되지 않는다. 이 특성 때문에 서버와 플레이어 모두 지연보다 안정성과 품질에 최적화된 구조를 가진다.

TCP 기반 프로토콜

VOD 서비스는 전송 안정성과 대역폭이 최우선이기 때문에, TCP 기반의 HTTP 스트리밍(DASH/HLS)을 사용하여 완벽한 데이터 무결성을 보장한다.

멀티 패스 인코딩(Multi-pass Encoding)

이러한 관점에서 등장한 것이 멀티 패스 인코딩multi-pass encoding이다. 인코더(encoder)는 전체 비디오 파일을 미리 분석하여 장면의 복잡도에 따라 비트레이트(bitrate)를 최적화한다. 이는 동일 화질 대비 영상 파일의 크기를 줄여 대역폭을 덜 잡아먹도록 도와준다. 또한 다양한 네트워크 환경에 대응하기 위해 수십 개의 해상도·비트레이트 조합을 미리 생성하여 저장하는데, 이를 인코딩 사다리라 한다.

스토리지 전략

저장장치를 구성할 때는 계층화된 저장소tiered storage를 사용한다. 빈번하게 조회되는 최신 콘텐츠('hot' data)는 고속 SSD나 NVMe 스토리지에, 조회수가 낮은 콘텐츠('cold' data)는 저렴한 HDD나 오브젝트 스토리지(S3 등)에 배치한다. 특히 VOD는 초기 버퍼링 시간이 허용되므로, 콜드 스토리지에서 데이터를 불러오는 잠깐의 지연 정도는 사용자 입장에서 얼마든지 넘어갈 수 있다.

Edge CDN(Content Delivery Network)

VOD 아키텍처의 핵심은 CDN(Content Delivery Network, 콘텐츠 전송 네트워크)의 깊은 캐싱 계층이다. 콘텐츠가 정적(static)이므로 HTTP 캐싱 효율이 매우 높고, 따라서 여러 개의 캐시 서버를 두었을 때 큰 효과를 거둘 수 있다. CDN의 전체적인 구조는 다음과 같다.

1. Origin Server: 원본 파일이 저장된 서버다.
2. Origin Shield/Mid-tier: 오리진 서버의 부하를 막는 중간 방어벽이다.
3. Edge Server: 사용자와 지리적으로 가장 가까운 ISP 네트워크 내부에 위치한다.
4. Client Cache: 브라우저나 디바이스의 로컬 저장소다.

VOD 요청은 DNS 리다이렉션이나 애니캐스트³ 라우팅을 통해 가장 가까운 엣지 서버로 전달된다. 인기 콘텐츠는 엣지 서버에서 100% 캐시 히트(cache hit)를 기록하며, 이는 네트워크의 대역폭 소모를 줄이고 최종 소비자에게 도달하는 마지막 구간의 전송 안정성을 높인다.

공격적인 버퍼링(Aggressive Buffering)

VOD 플레이어는 공격적인 버퍼링 전략을 취한다. 재생 시작 시 가능한 한 빠르게 데이터를 다운로드하여 수십 초에서 수 분 분량의 버퍼를 미리 확보한다. 이 거대한 버퍼는 네트워크 지터와 일시적인 대역폭 저하를 완벽하게 흡수한다. 네트워크가 10초간 끊겨도 사용자는 재생 중단을 느끼지 못한다. 즉, VOD 아키텍처는 높은 지연시간(버퍼)을 비용으로 지불하여 최고의 전송 안정성과 화질을 구매하는 구조이다.

Zero-Copy

일반적인 서버 아키텍처에서 비디오 데이터를 전송할 때, 디스크 → 커널 버퍼 → 사용자 공간 애플리케이션 → 커널 버퍼 → NIC(Network Interface Card, 네트워크 인터페이스 카드)로 데이터가 복사되는 과정에서 막대한 CPU 사이클과 메모리 대역폭이 소모된다. 고성능 VOD 서버는 sendfile 시스템 호출이나 RDMA(Remote Direct Memory Access) 기술을 활용하여 데이터를 스토리지에서 NIC로 직접 전송(zero-copy)함으로써 CPU 개입을 최소화하고 높은 처리량을 달성한다.

라이브 스트리밍: 균형점 찾기

이제 라이브 스트리밍 아키텍처를 살펴보자. VOD와의 차이를 먼저 그림으로 보면 다음과 같다.

그림 3. VOD와 라이브 스트리밍의 차이. 수많은 고유 세션과 파일이 있는 VOD는 저장소를 잘 관리하는 것이 관건이고, 몇 개의 라이브 스트림과 수많은 비슷한 세션이 있는 라이브 스트리밍은 메모리를 잘 관리하는 것이 관건이다.

인제스트(Ingest)와 실시간 트랜스코딩

소스(카메라)에서 서버로 영상을 보내는 인제스트(ingest) 단계는 전송 안정성이 핵심이다. 과거에는 RTMP(Real-Time Messaging Protocol)가 표준이었으나, 최근에는 패킷 손실 복구 기능이 뛰어난 SRT(Secure Reliable Transport)가 선호된다. SRT는 UDP 기반이면서도 ARQ를 통해 콘텐츠가 공급되는 첫 번째 구간(first mile)의 불안정성을 보완한다. 서버에 도착한 스트림은 실시간 트랜스코딩(영상의 인코딩 방식을 다른 인코딩 방식으로 변환)을 거쳐야 하는데, VOD와 달리 인코딩에 시간을 무한정 쓸 수 없으므로 품질과 속도 사이의 타협이 필요하다. 여기서 발생하는 지연은 전체 지연시간(glass-to-glass latency)⁴에 직접 추가된다.

세그먼트 크기와 지연시간

HLS나 DASH 기반 라이브 스트리밍에서 지연시간을 줄이는 가장 확실한 방법은 세그먼트(chunk)의 크기를 줄이는 것이다. VOD가 압축 효율을 위해 610초 길이의 세그먼트를 사용한다면, 라이브 스트리밍에서는 12초 단위로 잘게 쪼갠다. 그러나 세그먼트가 작아지면 HTTP 요청 횟수가 급증하여 오버헤드가 발생하고, 플레이어 버퍼 사이즈도 작아져 네트워크 지터에 취약해진다. 즉, 지연시간 단축은 필연적으로 안정성(재버퍼링 위험)의 저하를 초래한다. 이를 보완하기 위해 CMAF(Common Media Application Format)와 같은 기술을 도입해, 세그먼트가 완성되기 전에 청크 단위로 전송을 시작하는 방식이 사용된다.

Thundering Herd

라이브 스트리밍 아키텍처의 가장 큰 도전은 플래시 크라우드(flash crowd) 또는 Thundering Herd 현상이다. 월드컵 골 장면과 같은 이벤트 발생 시, 수백만 명의 사용자가 동시에 '동일한 최신 세그먼트'를 요청한다. 엣지 서버가 이 요청을 오리진으로 그대로 전달하면 오리진 서버는 즉시 마비된다. 따라서 라이브 스트리밍용 CDN은 요청 병합request coalescing 기능을 필수적으로 갖춰야 한다. 이는 수천 개의 동시 요청이 들어와도 오리진으로는 단 하나의 요청만 보내고, 응답을 받으면 기다리던 모든 사용자에게 동시에 뿌려주는 아키텍처이다. VOD의 롱테일 캐싱⁵과는 완전히 다른 부하 패턴을 처리해야 하는 것이다.

초저지연 아키텍처: 물리적 한계에 도전하다

초저지연 서비스의 목표였던 "1초 미만, 이상적으로는 200ms 이하"를 다시 떠올려 보자. 이 영역에서는 HTTP 기반의 버퍼링 전략이 불가능하다. 그래서 초저지연 스트리밍 서비스의 아키텍처는 안전할 수가 없다.

UDP와 RTP: 실시간 상호작용의 엔진

UDP(User Datagram Protocol)는 비연결형으로, 데이터 전달 보장이나 순서 보장이 없다. 이를 보완하기 위해 실시간 미디어 전송에는 RTP(Real-time Transport Protocol, 실시간 전송 프로토콜)가 UDP 위에 얹혀진다. RTP는 시퀀스 번호와 타임스탬프를 제공하여 수신측이 패킷의 순서를 재배열하고 지터를 계산할 수 있게 한다. 그러나 TCP와 달리 재전송을 강제하지 않는다. 손실된 패킷에 대해 재전송을 요청할지(NACK, Negative Acknowledgement), 아니면 무시하고 다음 프레임을 보여줄지는 애플리케이션 로직이 결정한다.

최근에는 UDP의 속도와 TCP의 신뢰성을 절충한 SRT 프로토콜이 부상하고 있다. SRT는 UDP 기반이지만 지능적인 재전송(ARQ) 메커니즘을 내장하여, 약간의 지연(버퍼)을 허용하면서 패킷 손실을 복구한다. 이는 공공 인터넷을 통한 비디오 기여 전송처럼 불안정한 네트워크 환경에서 매우 효과적이다.

WebRTC와 Stateful 아키텍처

초저지연 스트리밍 아키텍처에서는 HTTP/TCP의 안전망을 버리고 WebRTC나 RTSP(Real-Time Streaming Protocol)와 같은 UDP 기반의 상태 유지(stateful) 프로토콜을 채택한다. WebRTC는 P2P(Peer-to-Peer) 연결을 기본으로 하며, NAT와 방화벽을 통과하기 위해 ICE(Interactive Connectivity Establishment), STUN(Session Traversal Utilities for NAT), TURN(Traversal Using Relays around NAT) 서버를 활용한다. 이는 클라이언트와 서버(또는 다른 클라이언트) 간에 지속적인 세션을 맺고 가장 직접적인 경로를 탐색하여 홉 수를 최소화한다. HTTP의 요청-응답 오버헤드를 제거하고 즉시성을 확보하는 것이다.

재생 버퍼의 제거

초저지연 스트리밍 아키텍처에는 사실상 재생 버퍼가 없다. 데이터가 도착하는 즉시 디코딩하여 화면에 뿌린다. 이는 네트워크 지터에 대한 방어막이 없음을 의미한다. 패킷 순서가 뒤바뀌거나 늦게 도착하면 기다리지 않고 해당 프레임을 건너뛰거나 깨진 상태로 보여준다. TCP의 재전송(약 1 RTT 소요)은 초저지연 스트리밍에서 허용되지 않는다. RTT가 50ms인 환경에서 재전송을 기다리면 3프레임(60fps 기준)이 밀리게 되는데, 이는 실시간 상호작용에서 치명적이다. 따라서 초저지연 스트리밍은 완전한 데이터(reliability)보다 적시성(timeliness)을 절대적으로 우선하는 아키텍처를 가진다.

엣지 컴퓨팅

VOD나 라이브 스트리밍이 정적 파일 서빙에 최적화된 CDN을 쓴다면, 초저지연 스트리밍은 연산을 수행하는 미디어 서버(SFU/MCU)⁶가 필요하다. 이 서버들은 각 사용자의 네트워크 상태를 실시간으로 모니터링하고 비트레이트를 동적으로 조절하거나, 다자간 통화에서 오디오/비디오를 믹싱한다. 빛의 속도로 인한 전파 지연을 줄이기 위해, 이러한 미디어 서버는 사용자와 물리적으로 매우 가까운 엣지(edge)에 전진 배치되어야 한다. 이는 단순한 캐싱(storage)이 아니라 분산 컴퓨팅(compute)의 영역이다.

타이밍 휠을 이용한 지터 관리

서버 측면에서 수천 개의 TCP 연결에 대한 재전송 타이머를 관리하거나 초저지연 스트리밍의 패킷 간격(pacing)을 조절하는 것은 큰 부하를 유발한다. 전통적인 방식은 관리하는 타이머의 수에 비례해 연산의 복잡도가 증가하기 때문에 고속 처리에 적합하지 않다. 타이밍 휠(timing wheel) 알고리즘은 타이머의 수와 상관없이 일정한 연산량으로 타이머를 처리할 수 있게 하여, CPU 부하 없이 정밀한 패킷 전송 간격을 유지하고 지터를 최소화한다.

엣지 라우팅을 위한 패킷 분류(Packet Classification)

초저지연 스트리밍 서비스에서는 엣지 라우터가 특정 스트림을 식별하여 프리미엄 저지연 경로로 라우팅해야 할 필요가 있다. Grid of Tries나 RFC(Recursive Flow Classification — 문서 규격 RFC와는 무관한 패킷 분류 알고리즘)와 같은 고속 패킷 분류 알고리즘은 수만 개의 규칙을 최대 속도로 처리하여, 초저지연 스트리밍의 패킷을 즉시 식별하고 최단 경로로 보내준다.

결론

VOD 아키텍처는 사용자의 지연시간 무감각성을 활용하여 대규모 분산 스토리지와 공격적 버퍼링을 통해 최고의 화질과 안정성을 달성하는 방향으로 진화했다. 반면 라이브 스트리밍은 VOD의 HTTP 인프라를 활용하되 세그먼트 크기와 버퍼를 줄여 가며 규모와 최신성 사이에서 줄타기를 하는 형태이다. 마지막으로 초저지연(ULL) 아키텍처는 HTTP/TCP 생태계의 안전망을 거부하고, UDP와 P2P, 엣지 컴퓨팅을 통해 안정성을 희생하면서까지 물리적 한계에 가까운 즉시성을 추구하는 극단적인 설계를 취한다.

요약하자면, 결국 네트워크 아키텍트에게 주어진 과제는 만능 해결책을 찾는 것이 아니라, 서비스가 요구하는 '지연시간-비용-품질'의 삼각형 내부에서 최적의 균형점을 찾아 전송 파이프라인의 각 단계를 조율하는 것이다.

---

출처

• Gupta, P. (no date) Recursive Flow Classification: An Algorithm for Packet Classification on Multiple Fields. Chapter 4, PhD thesis, Stanford University. Available at: https://yuba.stanford.edu/~pankaj/thesis/chapter4.pdf (Accessed: 26 August 2026).
• jyeonjyan (no date) Cache 란?. Available at: https://github.com/jyeonjyan/TIL/blob/master/Network/cache.md (Accessed: 26 August 2026).
• millo (2020) WebRTC 구현 방식(Mesh/P2P, SFU, MCU). Available at: https://millo-l.github.io/WebRTC-%EA%B5%AC%ED%98%84-%EB%B0%A9%EC%8B%9D-Mesh-SFU-MCU/ (Accessed: 26 August 2026).
• Schlenker, M. (no date) Router Design and Algorithms (Part 2). OMSCS Notes. Available at: https://www.omscs-notes.com/computer-networks/router-design-and-algorithms-part-2/#grid-of-tries (Accessed: 26 August 2026).
• 김선우 (2023) [OS] sendfile 시스템 콜과 kafka zero-copy. Available at: https://code-run.tistory.com/80 (Accessed: 26 August 2026).

• 섀넌-하틀리 정리 | 위키백과
• 누화(Crosstalk) | 네이버 블로그

*[VOD]: Video on Demand *[ULL]: Ultra-Low Latency *[CDN]: Content Delivery Network *[RTT]: Round-Trip Time *[ARQ]: Automatic Repeat Request *[FEC]: Forward Error Correction *[SRT]: Secure Reliable Transport *[ABR]: Adaptive Bitrate Streaming *[TCP]: Transmission Control Protocol *[UDP]: User Datagram Protocol

Footnotes

1. 프로토콜 윈도우(protocol window)는 TCP 등의 프로토콜에서 송신자가 수신자의 확인 응답을 기다리지 않고 연속으로 보낼 수 있는 데이터의 양이다. 윈도우가 작으면 대역폭이 남아 있어도 처리량이 제한된다. ↩

2. 누화(crosstalk)는 한 전기 회로나 전송 채널의 신호가 의도치 않게 인접한 다른 채널로 새어 들어가 간섭을 일으키는 현상이다. ↩

3. 애니캐스트(anycast)는 동일한 IP 주소를 여러 서버에 할당하여, 요청하는 사용자에게 네트워크상 가장 가까운 서버로 트래픽을 보내는 라우팅 기술이다. ↩

4. Glass-to-Glass Latency는 카메라 렌즈(유리)에 장면이 들어온 순간부터 시청자의 화면(유리)에 그 장면이 표시되기까지의 전체 지연시간을 뜻한다. ↩

5. 롱테일 캐싱(longtail caching)은 요청이 소수의 인기 콘텐츠에 집중되는 분포를 활용해, 자주 조회되는 일부 콘텐츠를 캐시에 유지하는 것만으로 대부분의 요청을 처리하는 캐싱 정책이다. ↩

6. SFU(Selective Forwarding Unit)는 수신한 스트림을 변형 없이 선택적으로 중계하는 미디어 서버이고, MCU(Multi-point Control Unit)는 여러 스트림을 서버에서 믹싱해 하나로 합쳐 내려보내는 미디어 서버다. SFU는 서버 부하가 낮고 지연이 적으며, MCU는 클라이언트 부하가 낮은 대신 서버 연산이 크다. ↩