TCP와 UDP는 무엇이 다를까?

앞선 글에서는 인터넷에서 사진과 문서, 영상이 하나의 거대한 덩어리로 이동하지 않는 이유를 살펴보았다. 데이터는 작은 패킷으로 나뉘었고, 각각의 패킷은 라우터를 거쳐 목적지를 향해 이동하였다. 목적지에 도착한 패킷은 다시 원래의 데이터로 조립되었다.

그런데 패킷을 목적지 방향으로 보냈다고 해서 언제나 통신이 성공하는 것은 아니었다. 여러 패킷이 같은 네트워크를 이용하다 보면 일부가 늦게 도착할 수 있고, 순서가 뒤바뀌거나 이동 중에 사라지는 일도 생길 수 있었다. 네트워크가 혼잡하면 라우터가 처리하지 못한 패킷을 버리기도 하였다.

파일을 내려받는 중에 데이터 일부가 사라진다면 원본 파일이 손상될 수 있다. 반면 영상통화 중 짧은 음성 한 조각이 빠졌다고 해서 과거 시점으로 돌아가 그 소리를 다시 재생하는 것은 오히려 대화를 방해할 수 있다. 같은 인터넷을 사용하더라도 어떤 통신은 정확성이 중요하고, 어떤 통신은 조금의 손실보다 지연을 줄이는 일이 더 중요하였다.

인터넷은 이처럼 서로 다른 요구를 하나의 방식으로 해결하려 하지 않았다. 대신 전송의 신뢰성을 중요하게 다루는 TCP와 빠르고 단순한 전달에 집중하는 UDP라는 서로 다른 선택지를 마련하였다. 두 방식의 차이는 단순히 빠른 것과 느린 것으로만 나뉘지 않는다. 무엇을 확인하고, 무엇을 생략할 것인지에 대한 설계 철학의 차이에 가까웠다.

한줄 요약

TCP는 데이터의 도착과 순서를 확인하며 신뢰성 있는 전송을 제공하고, UDP는 확인과 재전송 절차를 줄여 지연이 적은 전송에 집중한다.

인터넷은 패킷의 도착을 어떻게 확인할까?

택배를 보냈다고 생각해 보자. 발송인은 물건을 택배회사에 넘겼지만, 그것만으로 수취인이 물건을 받았다고 확신할 수는 없다. 배송 조회를 통해 이동 상태를 확인하거나 수취 완료 기록을 받아야 전달이 끝났다는 사실을 알 수 있다. 네트워크에서도 패킷을 보냈다는 사실과 상대방이 실제로 받았다는 사실은 서로 달랐다.

인터넷의 중간 구간에서는 다양한 문제가 생길 수 있었다. 통신 회선의 품질이 좋지 않아 데이터가 손상될 수도 있고, 특정 라우터에 패킷이 몰려 대기 공간이 부족해질 수도 있었다. 더 짧은 경로를 선택한 패킷이 나중에 출발했음에도 먼저 도착하는 일도 가능하였다. 인터넷은 처음부터 모든 패킷이 같은 시간에 같은 순서로 도착하는 환경이 아니었다.

이 문제를 해결하려면 송신자와 수신자가 몇 가지 정보를 주고받아야 한다. 수신자는 어떤 데이터가 도착했는지 알려야 하고, 송신자는 일정 시간이 지나도록 확인 응답이 오지 않으면 데이터를 다시 보내야 한다. 순서가 뒤바뀐 데이터는 올바르게 정렬해야 하며, 상대방이 처리할 수 있는 양보다 너무 빠르게 보내지 않도록 속도도 조절해야 한다.

이러한 역할을 대표적으로 담당하는 프로토콜이 TCP(Transmission Control Protocol)였다. TCP는 패킷을 무조건 빠르게 밀어 넣는 것보다, 상대방이 데이터를 제대로 받았는지를 확인하는 데 무게를 두었다. 인터넷에서 웹문서와 파일, 이메일처럼 내용이 정확히 전달되어야 하는 통신이 가능했던 것은 이러한 확인 절차가 있었기 때문이다.

TCP는 확인하며 데이터를 전달하였다

TCP의 가장 중요한 특징은 신뢰성 있는 전송이었다. 여기에서 신뢰성이란 인터넷 회선에 장애가 전혀 없다는 뜻이 아니다. 오히려 패킷 손실과 순서 변경이 생길 수 있다는 사실을 인정하고, 문제가 생겼을 때 이를 확인하고 복구하는 기능을 제공한다는 의미였다.

TCP로 전송되는 데이터에는 순서를 구분하기 위한 정보가 붙는다. 수신 측은 이 정보를 이용하여 먼저 도착한 데이터와 나중에 도착한 데이터를 올바른 위치에 배열할 수 있다. 중간의 일부 데이터가 빠져 있다면 완성된 내용으로 처리하지 않고 누락된 부분을 기다린다.

데이터를 정상적으로 받은 수신 측은 송신 측에 확인 응답을 보낸다. 이를 흔히 ACK(Acknowledgement)라고 부른다. 송신 측은 ACK를 통해 상대방이 어느 지점까지 데이터를 받았는지 판단할 수 있다. 일정 시간 동안 필요한 ACK가 도착하지 않거나 손실이 의심되면 해당 데이터를 다시 전송하였다.

이러한 재전송 기능 덕분에 파일을 내려받다가 패킷 하나가 사라져도 파일 전체를 처음부터 다시 받을 필요가 없었다. 누락된 부분을 확인하여 필요한 데이터만 다시 전달할 수 있었다. 사용자는 복잡한 확인 과정을 직접 보지 못하지만, 웹페이지를 열고 문서를 내려받는 동안 TCP는 여러 차례 데이터의 도착 상태를 점검하고 있었다.

TCP는 상대방이 감당할 수 있는 처리 속도도 고려하였다. 수신 측의 저장 공간이나 처리 능력이 부족한데 송신 측이 계속 데이터를 보낸다면 패킷이 쌓이고 결국 손실이 발생할 수 있다. TCP는 수신자가 받을 수 있는 범위를 확인하며 전송량을 조절하는데, 이를 흐름 제어(Flow Control)라고 한다.

네트워크 전체의 혼잡 상태도 무시할 수 없었다. 여러 송신자가 동시에 많은 데이터를 보내면 특정 구간에 패킷이 몰릴 수 있다. TCP는 손실과 응답 지연 등을 관찰하여 네트워크가 혼잡하다고 판단되면 전송 속도를 줄이고, 상황이 나아지면 다시 전송량을 늘렸다. 이러한 과정을 혼잡 제어(Congestion Control)라고 한다.

짧은 생각

TCP의 신뢰성은 문제가 생기지 않도록 모든 것을 통제한 결과가 아니었다. 문제가 생길 수 있다는 전제에서 출발하여 누락된 데이터를 찾고, 다시 보내고, 상대방과 네트워크의 상태에 맞추어 속도를 조절하였다. 견고한 체계는 장애를 완전히 없애는 것보다 장애가 생겼을 때 어떻게 회복할 것인지까지 준비한 구조에 가까웠다.

TCP 연결은 왜 세 번의 확인으로 시작할까?

TCP는 본격적으로 데이터를 보내기 전에 상대방과 통신할 준비가 되었는지 확인한다. 전화를 걸자마자 상대방의 응답 여부를 확인하지 않고 혼자 말을 시작하지 않는 것과 비슷하다. 송신 측과 수신 측은 서로 통신이 가능한 상태인지 확인한 뒤 데이터 전송을 시작하였다.

이때 사용되는 대표적인 절차가 3-way Handshake이다. 이름 그대로 세 단계의 메시지가 오간다. 먼저 연결을 원하는 쪽이 상대방에게 통신을 시작하고 싶다는 신호를 보낸다. 상대방은 그 신호를 받았으며 자신도 통신할 준비가 되었다는 응답을 보낸다. 마지막으로 처음 요청한 쪽이 상대방의 응답을 확인했다는 메시지를 보내면 연결이 성립된다.

겉으로 보면 두 번의 메시지만으로도 충분할 것처럼 보인다. 요청을 보내고 상대방이 응답하면 연결된 것으로 생각할 수 있기 때문이다. 그러나 두 번째 응답이 처음 요청한 쪽에 실제로 도착했는지는 상대방이 알 수 없다. 세 번째 확인이 있어야 양쪽 모두 자신의 송신과 수신 경로가 정상적으로 작동한다는 사실을 확인할 수 있다.

이 과정은 데이터 전송 전에 추가 시간을 필요로 한다. 처음 연결할 때 주고받는 메시지가 늘어나기 때문이다. 하지만 정확한 연결 상태와 데이터 순서를 관리해야 하는 TCP에서는 필요한 절차였다. 웹사이트에 접속하거나 파일 서버와 연결할 때 TCP는 이러한 사전 확인을 거친 뒤 데이터를 전달하였다.

TCP의 3-way Handshake는 데이터를 세 번 전송한다는 뜻이 아니다. 실제 내용을 보내기 전에 양쪽의 통신 준비 상태와 초기 순서 정보를 세 단계로 확인하는 연결 설정 절차를 의미한다.

UDP는 왜 도착 여부를 확인하지 않을까?

UDP(User Datagram Protocol)는 TCP와 다른 선택을 하였다. 데이터를 보내기 전에 상대방과 연결 상태를 세밀하게 확인하지 않으며, 전송한 데이터가 정상적으로 도착했는지 기본적으로 응답을 기다리지 않는다. 순서가 뒤바뀌거나 일부 데이터가 사라져도 UDP 자체가 이를 다시 보내도록 요구하지 않는다.

이 설명만 보면 UDP는 불완전하고 위험한 방식처럼 느껴질 수 있다. 그러나 UDP가 확인 절차를 줄인 것은 기능이 부족해서만은 아니었다. 모든 통신에서 재전송과 순서 복원이 필요한 것은 아니기 때문이다. 늦게 도착한 데이터가 아무 가치가 없는 상황도 존재하였다.

영상통화를 예로 들어 보자. 상대방이 지금 말하고 있는 음성이 실시간으로 전달되어야 자연스러운 대화가 가능하다. 2초 전에 손실된 음성 조각을 다시 받아 현재 음성 사이에 끼워 넣는다면 대화는 더 이상 자연스럽지 않다. 작은 손실을 감수하더라도 현재 시점의 데이터를 계속 전달하는 편이 낫다.

온라인 게임에서도 비슷한 상황이 나타난다. 다른 이용자의 위치 정보가 매우 짧은 간격으로 계속 갱신된다면 오래된 위치 정보를 다시 받는 것보다 최신 위치를 빠르게 받는 것이 중요하다. 이전 패킷이 사라졌다고 게임 전체를 멈추고 재전송을 기다리면 화면과 조작 사이의 지연이 커질 수 있다.

UDP는 연결 설정과 확인 응답, 기본적인 재전송 절차를 줄였기 때문에 헤더 구조가 비교적 단순하고 처리 부담도 적었다. 전송 속도가 언제나 TCP보다 빠르다고 단정할 수는 없지만, 지연을 줄이고 응용프로그램이 필요한 방식으로 직접 통신을 설계하기에 유리하였다.

중요한 점은 UDP가 패킷 손실을 반드시 방치한다는 의미는 아니라는 것이다. 필요하다면 응용프로그램이 자체적으로 순서 확인이나 재전송 기능을 구현할 수 있다. 다만 TCP처럼 모든 통신에 동일한 신뢰성 절차를 기본 적용하지 않고, 서비스의 목적에 맞게 필요한 기능을 선택할 수 있도록 남겨 두었다.

TCP와 UDP는 어디에 사용될까?

TCP와 UDP의 차이를 가장 쉽게 이해하는 방법은 어떤 서비스에서 무엇이 더 중요한지를 생각해 보는 것이다. 파일을 내려받을 때는 조금 늦어지더라도 모든 데이터가 정확해야 한다. 파일의 일부가 빠지거나 순서가 바뀌면 문서가 열리지 않거나 프로그램이 손상될 수 있다. 이러한 통신에는 TCP가 잘 어울렸다.

웹페이지 전송과 이메일도 기본적으로 내용의 정확성이 중요하였다. 문장 일부가 사라지거나 결제 금액의 숫자가 누락되어서는 안 된다. 전통적인 웹 통신에 사용된 HTTP/1.1과 HTTP/2는 TCP 위에서 동작하였고, 이메일 전송과 파일 전송에 사용되는 여러 프로토콜도 TCP를 활용하였다.

반면 실시간 음성통화와 영상회의에서는 데이터가 조금 손실되는 것보다 화면과 음성이 늦게 도착하는 문제가 더 크게 느껴질 수 있다. 온라인 게임에서도 현재 상태를 빠르게 반영하는 일이 중요하다. 이러한 서비스에서는 UDP를 이용하거나 UDP를 기반으로 별도의 전송 기능을 구성할 수 있었다.

DNS 질의에도 UDP가 널리 사용되었다. 사용자가 도메인 이름을 입력하면 DNS 서버에 해당 이름의 IP 주소를 묻는데, 일반적인 질의와 응답은 비교적 크기가 작고 빠르게 처리할 필요가 있었다. 응답이 오지 않으면 다시 질의할 수 있었기 때문에 매번 TCP 연결을 설정하는 것보다 UDP가 효율적인 경우가 많았다. 다만 응답 크기나 통신 상황에 따라 DNS에서도 TCP가 사용될 수 있다.

구분	TCP	UDP
연결 설정	데이터 전송 전에 연결 상태를 확인한다.	별도의 연결 설정 없이 데이터를 보낼 수 있다.
도착 확인	확인 응답을 통해 데이터 도착 상태를 관리한다.	UDP 자체는 도착 확인을 기본으로 제공하지 않는다.
순서 관리	데이터의 순서를 확인하고 올바르게 정렬한다.	도착 순서를 기본적으로 보장하지 않는다.
손실 대응	손실된 데이터의 재전송을 수행할 수 있다.	필요하면 응용프로그램이 별도로 처리한다.
적합한 통신	파일, 문서, 이메일, 정확성이 중요한 데이터	영상통화, 게임, 실시간 스트리밍, 빠른 질의

다만 특정 서비스가 언제나 하나의 프로토콜만 사용하는 것은 아니다. 온라인 게임에서도 로그인과 결제, 채팅 기록처럼 정확성이 중요한 기능은 TCP를 사용할 수 있다. 실제 전투 화면의 위치 정보나 실시간 상태 갱신에는 UDP가 사용될 수 있다. 하나의 서비스 안에서도 데이터의 성격에 따라 서로 다른 전송 방식을 선택하는 것이다.

짧은 생각

TCP와 UDP를 정확한 방식과 부정확한 방식으로만 구분하면 UDP의 의미를 놓치기 쉽다. 통신에서 중요한 것은 모든 데이터를 똑같이 다루는 일이 아니었다. 은행 거래의 숫자와 영상통화의 한순간은 같은 무게를 갖지 않는다. 무엇을 반드시 지켜야 하고, 무엇을 일정 부분 감수할 수 있는지를 정하는 일이 기술 선택의 출발점이었다.

UDP 위에서도 신뢰성 있는 통신이 가능할까?

TCP가 신뢰성을 제공하고 UDP가 속도에 집중한다는 설명은 기본 원리를 이해하는 데 도움이 된다. 그러나 오늘날 인터넷 통신은 이보다 조금 더 복잡해졌다. UDP를 사용하면서도 필요한 부분에 한해 연결 관리와 손실 복구, 암호화 기능을 추가하는 새로운 방식이 등장하였기 때문이다.

대표적인 사례가 구글이 2012년에 개발하 QUIC(Quick UDP Internet Connections)이다. QUIC는 UDP를 기반으로 동작하지만 단순히 데이터를 확인 없이 보내는 데 그치지 않는다. 연결 설정과 암호화, 손실 복구, 혼잡 제어와 같은 기능을 자체적으로 구현하였다. 웹 통신에 사용되는 HTTP/3는 QUIC 위에서 동작한다.

기존의 TCP 기반 웹 통신에서는 하나의 연결 안에서 특정 데이터가 손실되면 뒤따르는 데이터가 준비되어 있어도 처리가 지연되는 상황이 생길 수 있었다. QUIC는 여러 데이터 흐름을 보다 독립적으로 관리하여 한 흐름에서 손실이 발생하더라도 다른 흐름에 미치는 영향을 줄이고자 하였다.

이 사례는 TCP가 낡았고 UDP가 새롭다는 뜻이 아니다. TCP는 여전히 수많은 서비스에서 안정적으로 사용되고 있으며 오랜 시간에 걸쳐 검증된 전송 방식이다. QUIC는 UDP라는 비교적 단순한 기반 위에 현대 웹 환경에 필요한 기능을 새롭게 구성한 선택이었다.

결국 UDP의 장점은 무조건 빠르다는 데만 있지 않았다. 운영체제에 구현된 고정된 TCP 동작에 전적으로 의존하지 않고, 응용프로그램과 새로운 프로토콜이 목적에 맞는 전송 구조를 설계할 수 있도록 유연한 출발점을 제공한다는 데 의미가 있었다.

인터넷은 하나의 정답 대신 두 가지 선택을 남겼다

TCP는 데이터를 보내기 전 연결 상태를 확인하고, 전송 과정에서는 순서와 도착 여부를 관리하였다. 패킷이 사라지면 필요한 데이터를 다시 보냈고, 수신 측과 네트워크가 처리할 수 있는 상태에 맞추어 전송량을 조절하였다. 정확성이 중요한 파일과 문서, 웹 데이터가 안정적으로 전달될 수 있었던 배경에는 이러한 절차가 있었다.

UDP는 이 과정의 많은 부분을 기본 기능에서 덜어냈다. 연결 설정과 확인 응답을 기다리지 않고 데이터를 보낼 수 있었으며, 순서 관리와 재전송이 필요하다면 응용프로그램이 직접 결정하도록 하였다. 실시간 영상과 음성, 게임처럼 오래된 데이터의 재전송보다 현재의 정보를 빠르게 전달하는 일이 중요한 통신에 적합하였다.

인터넷은 정확성과 속도 가운데 하나만을 선택하지 않았다. 모든 통신을 TCP로 처리하면 신뢰성은 높일 수 있지만 불필요한 확인과 지연이 생길 수 있었다. 반대로 모든 통신을 UDP로 처리하면 응용프로그램마다 신뢰성 기능을 다시 만들어야 했다. 서로 다른 목적을 가진 두 방식을 함께 사용함으로써 다양한 서비스를 수용할 수 있었다.

우리가 웹사이트에 접속하고, 파일을 내려받고, 게임을 하고, 영상통화를 하는 동안 TCP와 UDP는 눈에 보이지 않는 곳에서 서로 다른 역할을 수행하고 있다. 어느 하나가 더 우수해서 살아남은 것이 아니라, 통신이 요구하는 조건이 서로 달랐기 때문에 두 방식 모두 필요하였다.

패킷이 어떤 규칙으로 전달되는지는 알게 되었다. 그러나 웹브라우저가 서버에 연결된 뒤에는 또 다른 질문이 남는다. 사용자가 주소를 입력하면 서버는 어떤 자료를 보내야 하는지 어떻게 이해하고, 화면에 보이는 웹페이지는 어떤 방식으로 요청되고 전달되는 것일까? 다음 글에서는 웹의 대화를 가능하게 한 규칙인 HTTP와 HTTPS의 원리를 살펴본다.

짧은 생각

좋은 기술은 모든 상황에서 가장 많은 기능을 제공하는 기술만을 뜻하지 않았다. 때로는 확인 절차를 더하는 것이 필요했고, 때로는 과감히 줄이는 편이 나았다. TCP와 UDP가 함께 사용된다는 사실은 인터넷이 하나의 정답으로 만들어진 체계가 아니라 목적에 따라 서로 다른 선택을 허용한 체계라는 점을 보여준다.