TCP 대신 UDP를 사용해야 할 때

TCP는 데이터가 도착하지 않을 수 있다는 문제를 전제로 설계되었습니다. 이를 방지하기 위해 정교한 장치를 구축합니다: 수신 확인, 재전송, 순서 보장. TCP는 패킷이 반드시 도착하도록 가능한 모든 수단을 동원합니다.

하지만 그 패킷이 더 이상 필요 없다면 어떻게 될까요?

실시간 애플리케이션에서는 늦게 도착한 패킷이 아예 도착하지 않은 패킷보다 더 나쁠 수 있습니다. TCP는 원하지도 않는 그 패킷을 굳이 재전송해 주고는, 당신이 기다리게 만듭니다. 전송을 보장하기 위해 설계된 프로토콜이 오히려 화상 통화를 끊기게 만드는 원인이 됩니다.

실시간 통신

음성 통화는 이 역설을 생생하게 보여줍니다. 대화 중에 20밀리초 분량의 오디오가 담긴 패킷이 손실되어도 거의 알아차리기 어렵습니다—뇌가 그 공백을 채워주기 때문입니다. 하지만 TCP가 재전송을 고집하는 바람에 같은 패킷이 200밀리초 늦게 도착한다면? 어색한 지연이 생기고 사람들이 서로 말을 겹치게 됩니다.

TCP의 보장이 오히려 독이 되어버린 것입니다.

UDP는 애플리케이션이 자체적인 복구 전략을 구현할 수 있게 해줍니다. 최신 오디오 코덱은 손실된 샘플을 보간하고, 비디오 코덱은 손상된 프레임을 건너뜁니다. 결과적으로 완벽함보다 타이밍이 더 중요한 자연스러운 대화가 가능해집니다. Zoom, Discord, WebRTC 모두 미디어 스트림에는 UDP를 사용하고, TCP는 채팅 메시지와 제어 신호에만 사용합니다.

패킷 손실이 발생하면, 화상 회의 애플리케이션은 재전송을 기다리는 대신 화질을 낮춥니다. 지연 시간은 낮게 유지되고, 대화는 원활하게 이어집니다.

게임

온라인 게임은 가능한 가장 낮은 지연 시간을 요구합니다. 1인칭 슈팅 게임에서 점프 버튼을 누르면, 그 동작은 수십 밀리초 안에 서버에 도달하고 모든 플레이어에게 반영되어야 합니다. TCP의 재전송 지연은 빠른 템포의 게임을 반응이 느리게 느껴지게 만들 것입니다.

UDP를 사용하는 게임 개발자들은 선택적 신뢰성을 구현합니다. 플레이어 위치 업데이트가 손실되었나요? 16밀리초 후 다음 업데이트가 어차피 이를 수정합니다. 하지만 "플레이어가 무기를 발사했다"는 정보는 어떨까요? 이것은 수신 확인과 잠재적인 재전송이 필요합니다—게임이 TCP의 획일적인 방식 대신 게임 방식에 맞게 애플리케이션 계층에서 직접 구현합니다.

위치 업데이트는 신뢰성보다 빈도를, 아이템 변경은 신뢰성을 우선합니다. 무엇이 중요한지는 게임이 결정합니다. Fortnite, Call of Duty, League of Legends—모두 UDP를 기반으로 구축되었습니다.

라이브 스트리밍

주문형 비디오는 버퍼링할 수 있습니다. 라이브 스트리밍은 그럴 수 없습니다.

스포츠 경기를 생중계할 때, 시청자들은 실시간으로 상황을 보길 기대합니다. UDP는 완전성보다 적시성을 우선시하는 저지연 스트리밍을 가능하게 합니다. GeForce NOW 같은 클라우드 게임 서비스, 원격 데스크톱 프로토콜, IP를 통한 방송 TV 모두 엔드-투-엔드 지연을 최소화하기 위해 UDP를 사용합니다.

이러한 애플리케이션들은 수신자가 재전송을 요청하지 않고도 손실된 패킷을 재구성할 수 있도록 중복 데이터(순방향 오류 수정)를 전송합니다. 수정이 실패하면 손상된 부분을 건너뜁니다. 짧은 결함이 라이브 이벤트에서 뒤처지는 것보다 낫습니다.

DNS와 요청-응답 프로토콜

DNS는 단순한 교환에서 UDP의 효율성을 잘 보여주는 예입니다. 컴퓨터가 "connected.app"을 조회할 때, UDP 패킷 하나를 보내고 패킷 하나를 돌려받기를 기대합니다. 전체 트랜잭션이 단 한 번의 왕복으로 완료됩니다.

TCP는 연결을 수립하는 데만 패킷 세 개가 필요하고, 그다음 쿼리와 응답, 그리고 연결 해제—단순한 질문과 답에 오버헤드가 몇 배로 늘어납니다. DNS는 자체적인 재시도 로직을 구현합니다: 몇 초 안에 응답이 없으면? 쿼리를 다시 보냅니다, 경우에 따라 다른 서버로.

NTP(시각 동기화), SNMP(장비 모니터링), DHCP(네트워크 구성)도 동일한 패턴을 따릅니다. 단순한 교환에는 TCP의 연결 상태와 순서 보장이 필요하지 않습니다.

QUIC를 활용한 맞춤형 신뢰성

때로는 애플리케이션이 TCP 모델과 다른 신뢰성 보장을 필요로 합니다. 파일 동기화 서비스는 안정적인 전송을 원하지만 파일 간 순서에는 신경 쓰지 않을 수 있습니다. TCP는 손실된 패킷 하나를 기다리며 모든 전송을 차단합니다. UDP 기반 프로토콜은 기다리는 동안 다른 파일을 계속 전송할 수 있습니다.

QUIC(HTTP/3를 구동하는 프로토콜)는 UDP를 기반으로 연결 단위가 아닌 스트림 단위의 신뢰성을 구현합니다. 이는 하나의 연결로 여러 리소스를 다운로드할 때 TCP를 괴롭히는 HOL 블로킹(head-of-line blocking)—손실된 패킷 하나가 그 뒤의 모든 것을 멈추게 하는 현상—을 방지합니다.

멀티캐스트

UDP는 TCP가 근본적으로 지원할 수 없는 일대다 통신을 지원합니다. 서비스 탐색 프로토콜은 UDP 멀티캐스트를 사용하여 장치가 로컬 네트워크의 모든 수신자에게 자신의 존재를 알릴 수 있게 합니다. 패킷 하나가 여러 수신자에게 전달됩니다.

IPTV 시스템은 UDP 멀티캐스트를 사용하여 여러 수신자가 참여할 수 있는 하나의 비디오 스트림을 전송합니다. 이는 각 시청자에게 별도의 TCP 연결을 수립하는 것보다 훨씬 효율적으로 확장됩니다.

선택

다음 상황에서는 UDP가 더 적합합니다:

• 완전성보다 타이밍이 중요할 때 — 실시간 통신, 게임, 라이브 스트리밍
• 교환이 단순할 때 — DNS, NTP, DHCP
• 맞춤형 신뢰성이 필요할 때 — QUIC, 게임 프로토콜, 데이터센터 애플리케이션
• 일대다 통신이 필요할 때 — 멀티캐스트, 서비스 탐색

필요한 경우 신뢰성은 애플리케이션 계층에서 구현할 수 있습니다. TCP의 지연 시간과 오버헤드는 제거할 수 없습니다. 애플리케이션이 지연보다 패킷 손실을 더 잘 처리할 수 있다면 UDP를 선택하세요.

UDP vs TCP 자주 묻는 질문

UDP가 더 빠르다면 왜 모든 애플리케이션이 UDP를 사용하지 않나요?

UDP가 본질적으로 더 빠른 것은 아닙니다—더 단순할 뿐입니다. 책임을 애플리케이션으로 이전합니다. 대부분의 애플리케이션(웹 브라우징, 파일 다운로드, 이메일)에서는 TCP의 보장이 정확히 필요한 것이며, 신뢰성을 다시 구현하는 것은 낭비입니다. UDP는 TCP의 보장이 문제를 해결하는 것이 아니라 오히려 문제를 일으킬 때 진가를 발휘합니다.

UDP 패킷은 순서가 바뀌어 도착할 수 있나요?

그렇습니다. UDP는 순서를 보장하지 않습니다. 패킷은 전송된 순서와 다르게 도착하거나, 아예 도착하지 않을 수도 있습니다. UDP를 사용하는 애플리케이션은 이를 처리해야 합니다—또는 신경 쓰지 않기로 결정할 수 있습니다. 최신 상태만 중요한 실시간 데이터의 경우가 종종 그렇습니다.

QUIC는 왜 새로운 전송 프로토콜이 되는 대신 UDP를 사용하나요?

현실적인 이유 때문입니다. 새로운 전송 프로토콜을 만들려면 전 세계의 운영 체제, 방화벽, 네트워크 장비를 변경해야 합니다—수십 년이 걸리는 과정입니다. UDP를 기반으로 구축하면 QUIC는 기존 인프라를 통해 지금 당장 작동할 수 있으며, HTTP/3에 필요한 맞춤형 신뢰성과 다중화를 제공합니다.