UDP

화상 통화 중 상대 목소리가 300ms 늦게 들려오면 대화 리듬이 무너지고, 온라인 게임에서 입력이 몇 프레임 뒤에 반영되면 조작이 엉망이 됩니다. 이런 상황에서 빠진 패킷을 되찾으려 재전송을 기다리면 지연은 더 쌓이고, 뒤늦게 복구된 데이터는 이미 새 데이터에 밀려 쓸모가 없어집니다. 문제는 신뢰성을 보장하는 TCP의 구조 자체가 이런 실시간 워크로드에서는 오히려 경험을 깨뜨린다는 점입니다. 손실 없이 정확하게 전달하는 것이 목표인 통신과, 조금 빠지더라도 지금 도착하는 것이 중요한 통신은 근본적으로 다른 전제를 가지고 있습니다. UDP는 후자를 위해 재전송과 순서 보장을 전송 계층에서 걷어낸 방식입니다.

인터넷 전송 계층은 TCP 중심으로 설계됐고, 파일 전송·이메일·원격 접속처럼 데이터가 빠짐없이 도착해야 하는 초기 워크로드에는 이 구조가 잘 맞았습니다. 하지만 인터넷 전화, 실시간 영상, 네트워크 게임이 등장하면서 연결 수립과 재전송에 드는 시간이 오히려 서비스 품질을 해치는 영역이 생겼습니다. 200ms만 늦어도 대화가 어긋나는 통화에서 손실 패킷을 되돌려 받는 비용은 실질적인 이득이 없었습니다. 이 압력이 커지면서 전송 계층에서 신뢰성 절차를 걷어내고, 손실 허용 여부를 애플리케이션이 직접 결정하게 하는 UDP가 실시간 워크로드의 기반으로 자리잡았습니다. 이후 RTP, WebRTC, QUIC 등 많은 프로토콜이 UDP 위에 각자의 손실·순서 처리를 올리는 방향으로 발전해 왔습니다.

UDP는 연결을 먼저 맺지 않고 datagram을 바로 보냅니다. TCP의 3-way 핸드셰이크가 없으므로 첫 패킷이 나가기까지의 지연이 없고, 받는 쪽이 확인 응답을 보내지 않아도 됩니다. 중간에 패킷이 사라지거나 순서가 바뀌어도 전송 계층은 자동으로 다시 보내지 않습니다. 헤더 크기는 8바이트로 TCP의 20바이트에 비해 작고, 절차가 단순해 처리 오버헤드도 낮습니다. 대신 손실 감지, 재전송 여부, 순서 복원 등 신뢰성에 관한 모든 판단을 애플리케이션이 워크로드에 맞게 직접 결정해야 합니다.

TCP와 UDP는 둘 다 전송 계층 프로토콜이지만 우선순위가 다릅니다. TCP는 3-way 핸드셰이크로 연결을 수립하고, ACK와 재전송으로 모든 데이터가 순서대로 도착하도록 보장합니다. UDP는 그 절차를 전부 생략해 지연과 오버헤드를 낮추는 대신 손실과 순서 뒤바뀜을 애플리케이션에 떠넘깁니다. 데이터가 한 바이트도 빠지면 안 되는 파일 전송이나 결제 처리에는 TCP가 맞고, 30fps로 상태를 전송하는 게임처럼 최신 패킷만 있으면 되는 상황에는 UDP가 맞습니다. UDP를 쓴다고 무조건 빠른 것도 아닙니다. 손실을 애플리케이션에서 다시 처리하면 TCP보다 느려질 수도 있습니다.

화상 통화(WebRTC), 실시간 게임 상태 동기화, DNS 질의, 모니터링 이벤트 수집처럼 즉시성이 정확성보다 우선하거나 요청이 짧고 반복적인 상황에서 UDP가 자주 쓰입니다. 실제로 이런 시스템에서 UDP는 순수한 전송 바닥으로만 남고, 손실 감내 범위·재전송 전략·순서 복원은 그 위의 프로토콜이 워크로드에 맞게 따로 설계합니다. 반면 데이터가 한 바이트라도 빠지면 결과가 달라지는 파일 전송, 결제, 데이터베이스 쿼리에는 적합하지 않습니다. UDP를 쓸지 결정할 때는 '빠른가'보다 '일부 손실이나 순서 뒤바뀜을 감수할 수 있는가, 그리고 그 처리를 직접 만들 준비가 됐는가'를 먼저 따져야 합니다.