UDP

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

UDP는 연결을 먼저 맺지 않고 datagram을 바로 보냅니다. 받는 쪽이 확인 응답을 보내지 않아도 되고, 중간에 패킷이 사라져도 전송 계층이 자동으로 다시 보내지 않습니다. 그래서 헤더와 절차가 단순해 지연은 줄어들지만, 손실과 순서 뒤바뀜은 애플리케이션이 감당해야 합니다.

TCP와 UDP는 둘 다 전송 계층 프로토콜이지만 기준이 다릅니다. TCP는 연결, 재전송, 순서 보장으로 정확성을 높이고, UDP는 그런 절차를 줄여 지연과 오버헤드를 낮춥니다. 데이터가 빠짐없이 도착해야 하면 TCP가 맞고, 조금 빠져도 즉시성이 더 중요하면 UDP가 맞습니다.

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

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

다음에 볼 개념

함께 보면 좋은 개념