두 프로토콜은 무엇이 다른가
TCP와 UDP는 모두 전송 계층(4계층)에서 동작하는 프로토콜이지만, 추구하는 철학이 정반대입니다. TCP는 단 한 패킷도 잃지 않고 순서대로 정확히 전달하는 것을 목표로 삼는 신뢰성 중심 프로토콜입니다. UDP는 조금 잃더라도 최대한 빠르게 보내는 것을 우선하는 속도 중심 프로토콜입니다. 이 근본적인 차이가 연결 방식, 오류 처리, 순서 보장, 속도까지 모든 특성을 가릅니다.
둘 중 무엇이 더 우월하다고 말할 수는 없습니다. 서로 다른 문제를 풀기 위해 설계됐기 때문입니다. 어떤 통신은 느려도 완벽해야 하고, 어떤 통신은 조금 깨져도 빨라야 합니다. 그래서 프로토콜 선택은 곧 그 서비스가 무엇을 더 두려워하는지를 정하는 일입니다. 두 프로토콜이 어느 계층 위에서 동작하는지는 앞선 네트워크 토폴로지 구조와도 맞닿아 있습니다.
TCP: 연결 지향과 신뢰성
TCP는 데이터를 보내기 전에 먼저 양쪽이 통신할 준비가 됐는지 확인하고, 보낸 데이터가 제대로 도착했는지 끝까지 책임집니다. 이 과정에서 여러 안전장치가 작동합니다.
3-way 핸드셰이크
TCP는 본 데이터를 보내기 전에 세 번의 신호를 주고받아 연결을 수립합니다. 먼저 클라이언트가 연결을 요청하는 SYN을 보내고, 서버가 이를 받아들이며 자신도 준비됐다는 SYN과 ACK를 함께 보내며, 마지막으로 클라이언트가 확인의 ACK를 보냅니다. 이 세 단계를 거쳐야 비로소 양쪽이 서로의 수신 준비를 확신하고 데이터를 주고받기 시작합니다. 이후 모든 패킷에는 순서 번호가 붙어 추적됩니다.
재전송과 흐름 제어
패킷이 도착하면 받은 쪽이 ACK로 잘 받았다고 알립니다. 보낸 쪽은 일정 시간 안에 ACK가 오지 않으면 패킷이 사라졌다고 판단하고 다시 보냅니다. 덕분에 중간에 일부가 유실돼도 결국 모든 데이터가 도착합니다. 여기에 더해 받는 쪽의 처리 여유를 살펴 보내는 속도를 조절하는 흐름 제어, 네트워크 혼잡을 감지해 전송량을 줄이는 혼잡 제어까지 작동합니다. 이 모든 확인과 조절이 신뢰성을 만들지만, 그만큼 지연과 오버헤드도 함께 따라옵니다.
UDP: 비연결과 속도
UDP는 이런 절차를 거의 모두 생략합니다. 연결을 수립하는 핸드셰이크도 없고, 받았는지 확인하는 ACK도 없으며, 사라진 패킷을 다시 보내지도 않습니다. 보낼 데이터가 있으면 그냥 보냅니다. 패킷이 사라지거나 순서가 뒤바뀌어도 UDP 자체는 신경 쓰지 않으며, 그 처리가 필요하다면 애플리케이션이 직접 해야 합니다.
이렇게 책임을 덜어낸 대가로 UDP는 매우 가볍고 빠릅니다. 헤더 크기도 TCP보다 훨씬 작아 같은 데이터를 더 적은 부담으로 실어 나릅니다. 연결을 맺고 끊는 과정이 없으니 첫 패킷을 곧바로 보낼 수 있어, 짧고 빈번한 통신에서 특히 유리합니다.
헤더에서 드러나는 설계 차이
두 프로토콜의 성격 차이는 헤더 구조에서 그대로 드러납니다. TCP 헤더에는 순서 번호, 확인 번호, 각종 제어 플래그, 윈도 크기처럼 신뢰성과 흐름 제어를 위한 필드가 빼곡히 들어 있습니다. 이 정보들이 있어야 어떤 패킷이 빠졌는지, 다음에 무엇을 보내야 하는지, 얼마나 빠르게 보내도 되는지를 판단할 수 있습니다. 그만큼 헤더가 무거워집니다.
반면 UDP 헤더는 출발지 포트, 목적지 포트, 길이, 체크섬 네 가지뿐입니다. 추적할 것도, 조절할 것도 없으니 헤더가 단출합니다. 이 작은 차이가 대량의 짧은 패킷을 주고받을 때는 무시할 수 없는 성능 격차로 나타납니다. 헤더가 가벼우면 같은 회선으로 더 많은 실제 데이터를 보낼 수 있기 때문입니다.
무엇을 언제 쓰는가
선택의 기준은 명확합니다. 데이터가 한 바이트라도 틀리면 안 되는 서비스는 TCP를 씁니다. 웹 페이지, 파일 전송, 이메일이 대표적입니다. 문서의 글자 하나가 빠지거나 파일의 일부가 깨지면 쓸모가 없어지므로, 느려지더라도 정
확함을 택합니다.
반대로 지연이 손실보다 치명적인 서비스는 UDP를 씁니다. 실시간 음성과 영상 통화, 온라인 게임, DNS 조회가 여기에 해당합니다. 영상 통화에서는 0.1초 늦게 도착한 완벽한 프레임보다 약간 깨졌어도 제때 도착한 프레임이 낫습니다. 지나간 순간을 다시 받아봐야 의미가 없기 때문입니다. 게임에서도 마찬가지로, 0.5초 전의 정확한 위치보다 지금의 대략적인 위치가 더 쓸모 있습니다. 전송 계층의 기본 동작은 MDN Web Docs에서도 폭넓게 다룹니다.
핸드셰이크 비용이라는 트레이드오프
TCP의 신뢰성은 공짜가 아닙니다. 연결을 맺는 세 번의 왕복, 매 패킷의 확인 응답, 유실 시 재전송은 모두 시간과 자원을 씁니다. 짧은 데이터 하나를 주고받는 데도 연결 수립 절차를 거쳐야 하므로, 아주 짧고 빈번한 통신에서는 이 고정 비용이 상대적으로 크게 느껴집니다. 반대로 큰 데이터를 길게 주고받을 때는 이 초기 비용이 전체에서 차지하는 비중이 작아 신뢰성의 이점이 분명해집니다.
그래서 같은 서비스 안에서도 통신의 성격에 따라 프로토콜을 나눠 쓰기도 합니다. 반드시 정확해야 하는 핵심 데이터는 TCP로, 자주 갱신되며 일부 손실을 감내할 수 있는 데이터는 UDP로 보내는 식입니다. 프로토콜 선택이 서비스 전체에 하나로 고정되는 것이 아니라, 데이터마다 다르게 적용될 수 있다는 점을 이해하면 설계의 폭이 넓어집니다.
경계를 허무는 시도들
최근에는 두 프로토콜의 장점을 합치려는 흐름이 뚜렷합니다. 대표적인 것이 UDP 위에 신뢰성과 보안을 얹은 QUIC입니다. UDP의 빠른 전송을 토대로 삼되, 손실 복구와 순서 보장은 애플리케이션 수준에서 직접 구현해 TCP에 가까운 안정성을 확보합니다. 동시에 연결 수립과 암호화 협상을 하나로 묶어 처음 연결할 때의 왕복을 줄였습니다. 이런 접근은 DNS가 도메인을 IP로 바꾸는 과정이나 최신 웹 전송 흐름에서 점점 비중이 커지고 있습니다. 결국 TCP냐 UDP냐의 단순한 선택을 넘어, 필요한 특성만 골라 조합하는 방향으로 나아가고 있는 셈입니다.