TCP vs UDP 전송 프로토콜 비교 | 신뢰성·지연·QUIC까지 선택 가이드

2026년 3월 30일 · 19분 읽기 · 수정 2026년 3월 30일 중급

이 글의 핵심

TCP vs UDP — 신뢰성·순서·지연·멀티플렉싱을 비교하고 QUIC·HTTP/3 맥락까지 연결합니다.

들어가며

전송 계층에서 TCP와 UDP는 거의 모든 애플리케이션이 밟는 두 갈래입니다. TCP는 신뢰성과 순서를 보장하고, UDP는 경량·지연 최소를 지향합니다. 최근에는 UDP 위에 구축된 QUIC이 HTTP/3의 기반이 되어 “둘 중 하나만 고른다”는 틀도 넓어졌습니다.

비유로 이해하기

TCP는 전화에 가깝습니다. 연결을 맺고, 순서대로 말한 내용이 도착했는지까지 맞추는 대화에 가깝습니다.
UDP는 우편에 가깝습니다. 주소(포트)만 적어 보내고, 도착 확인·순서는 기본적으로 별도 약속이 없습니다. 빠르게 한 방향으로 보내기 좋습니다.

이 비유는 정확한 프로토콜 동작을 대체하지는 않지만, 팀 설명·온보딩에서 “왜 DNS·게임은 UDP가 많은가”를 감각적으로 잡는 데 도움이 됩니다.

왜 선택이 서비스 품질을 가르나요?

같은 대역폭이라도 손실 시 재전송(TCP)과 손실을 무시(UDP)는 지연 분포가 달라집니다. REST·파일은 보통 TCP(또는 QUIC) 계열이 안전하고, 실시간·짧은 쿼리는 UDP 또는 그 위의 QUIC/RTP가 후보가 됩니다.

비유로 말씀드리면, TCP는 등기 우편(도착 확인·순서 맞춤·재발송)에 가깝고, UDP는 전단지 살포(빠르게 던지지만 도착·순서는 보장하지 않음)에 가깝습니다. 실시간 음성처럼 조금 빠져도 되지만 늦으면 안 되는 경우에는 UDP 계열이 선택되기도 합니다.

언제 TCP를, 언제 UDP를 쓰나요?

관점	TCP	UDP
성능(신뢰·지연)	손실 시 재전송으로 지연·지터가 커질 수 있음	헤드라인 지연은 작을 수 있으나 손실·순서 뒤바뀜을 앱이 감당해야 함
사용성	스트림 추상화로 앱이 재전송 로직을 안 써도 됨	짧은 질의·응답(DNS 등)에 단순
적용 시나리오	HTTP, API, 파일 전송	DNS, VoIP, 일부 게임, QUIC의 하단 전송

이 글을 읽으면

TCP와 UDP의 헤더·연결·흐름 제어 차이를 이해하실 수 있습니다
지연(jitter)·손실에 대응하는 전형적인 애플리케이션 패턴을 학습하실 수 있습니다
Python 등으로 소켓 차이를 체감할 수 있는 예제를 살펴보실 수 있습니다
QUIC/HTTP/3가 왜 등장했는지 TCP 한계 맥락에서 파악하실 수 있습니다

1. 빠른 비교표

특성	TCP	UDP
연결	연결 지향 (3-way handshake)	비연결형
신뢰성	재전송·순서 보장	보장하지 않음 (애플리케이션이 처리)
혼잡 제어	내장 (전송 속도 조절)	없음
헤더 오버헤드	상대적으로 큼	8바이트로 고정(페이로드 제외)
전송 단위	바이트 스트림	데이터그램(경계 유지)
멀티플렉싱	단일 스트림(전통적 소켓)	앱이 별도 채널 설계
대표 용도	HTTP/1.1·2, HTTPS, SMTP, SSH	DNS, VoIP, 일부 게임, QUIC의 UDP 기반

2. 각 프로토콜 상세

TCP (Transmission Control Protocol)

특징: 바이트 스트림으로 추상화되며, 손실 시 재전송하고 순서대로 애플리케이션에 전달합니다. 혼잡 제어로 네트워크를 보호하지만, 그만큼 지연·지터가 생길 수 있습니다.

장점

애플리케이션이 재전송·순서 로직을 짜지 않아도 됨
파일 전송·API 호출 등 정확성이 최우선인 워크로에 적합

단점

헤드 오브 라인 블로킹(특히 HTTP/1.1 단일 연결)
손실이 있는 링크에서 지연 급증 가능

Python 예제 (에코 클라이언트 개념)

import socket

sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.connect(("example.com", 443))
# TLS는 ssl.wrap_socket 등으로 별도 적용
sock.sendall(b"GET / HTTP/1.1\r\nHost: example.com\r\n\r\n")
print(sock.recv(4096))
sock.close()

UDP (User Datagram Protocol)

특징: 데이터그램을 보내고 끝입니다. 도착 여부·순서는 보장하지 않습니다. 실시간·브로드캐스트·DNS처럼 짧은 질의·응답이나 손실 허용 영역에 쓰입니다.

장점

핸드셰이크 부담이 적어 지연이 상대적으로 예측 가능한 경우가 많음
멀티캐스트·브로드캐스트와 궁합

단점

애플리케이션이 재전송·순서·중복 제거를 필요할 때 직접 구현
대용량·신뢰 전송만으로는 부적합

Python 예제

import socket

sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.sendto(b"query", ("8.8.8.8", 53))
data, addr = sock.recvfrom(512)
print(data)
sock.close()

QUIC (TCP의 “대체 축”으로 이해하기)

QUIC은 UDP 위에 신뢰성·암호화·멀티플렉싱을 올린 프로토콜입니다. HTTP/3는 QUIC 위에서 동작합니다. TCP + TLS 핸드셰이크 병합, 스트림 단위 블로킹 완화 등이 목표였습니다.

3. 성능 비교

아래는 정성적 경향입니다. 실제 RTT·버퍼·NIC offload에 따라 달라집니다.

상황	TCP	UDP
깨끗한 LAN	처리량 높음, 지연 안정	처리량 높음, 패킷 순서 이슈 적음
무선·손실 링크	재전송으로 지연 변동 큼	손실 시 데이터 그대로 유실
짧은 요청 다수	연결 설정 비용(특히 TLS 전)	요청당 오버헤드는 작을 수 있음

시각화: 스택 관점

flowchart TB
  subgraph app[애플리케이션]
    H3[HTTP/3]
    H2[HTTP/2]
  end
  subgraph trans[전송]
    Q[QUIC over UDP]
    T[TCP]
    U[UDP]
  end
  H3 --> Q
  H2 --> T
  Q --> U

벤치마크: iperf3로 TCP/UDP 처리량을 측정할 때, UDP는 -u 옵션으로 손실률을 별도 해석해야 합니다. “UDP가 더 빠르다”는 말은 손실을 무시할 수 있을 때만 성립합니다.

4. 사용 시나리오별 추천

시나리오	추천	이유
REST/GraphQL API	TCP (TLS)	신뢰성·표준 스택
웹 최적화(2026)	HTTP/3(QUIC) 검토	핸드셰이크·멀티플렉싱 이점
DNS	UDP(짧은 쿼리), 실패 시 TCP	전통적 패턴
VoIP/게임 입력	UDP(+앱 레벨 보정)	지연 민감
대용량 파일	TCP	재전송·흐름 제어 내장

실무 의사결정: (1) 손실을 허용할 수 있는가, (2) 순서가 반드시 필요한가, (3) 방화벽·중간장비가 UDP를 막지 않는가를 순서로 확인합니다.

5. 마이그레이션 가이드

TCP 기반 HTTP/2 → HTTP/3 (QUIC)

CDN·리버스 프록시가 QUIC을 지원하는지 확인 (Nginx, Envoy, 클라우드 LB 등).
UDP 443 방화벽 규칙 허용.
폴백: HTTP/2·HTTP/1.1 유지 (Alt-Svc 헤더 등).

TCP 전용 앱 → UDP + 커스텀 신뢰 계층

재전송·순서·중복을 설계(실질적으로 QUIC을 재발명하는 수준일 수 있음).
대부분의 팀에는 기존 TCP 또는 QUIC 라이브러리 사용을 권장.

주의: NAT·방화벽에서 UDP는 TCP보다 차단/제한되는 경우가 많습니다.

6. 실전 팁

혼합 사용

데이터 플레인: UDP(실시간) + 제어 플레인: TCP(신뢰) 패턴(일부 게임·미디어).
DNS over TCP/TLS/HTTPS: 프라이버시·신뢰 요구가 증가한 영역은 TCP 또는 TLS 위로 올라갑니다.

폴백 전략

웹: HTTP/3 → HTTP/2 → HTTP/1.1 자동 협상.
실시간: UDP 실패 시 TCP 트랜스포트 또는 비트레이트 감소.

# curl로 HTTP/3 시도 (빌드에 따라 --http3)
curl --http3 -I https://cloudflare.com

7. 흔한 질문

Q1. UDP가 항상 더 빠른가요?

아니요. 손실이 없고 앱이 재전송을 안 해도 될 때만 “빠르게 느껴질” 수 있습니다. 손실 링크에서는 오히려 불안정해집니다.

Q2. TCP는 보안이 더 좋나요?

전송 계층 자체의 “보안”이 아니라 TLS가 보안을 담당합니다. TCP든 UDP(QUIC)든 암호화 계층을 별도로 봐야 합니다.

Q3. HTTP/3를 쓰면 TCP가 필요 없나요?

클라이언트·서버·캐시가 QUIC을 지원해야 하며, 여전히 TCP 기반 서비스는 공존합니다.

Q4. 왜 DNS는 UDP가 기본인가요?

짧은 질의·응답에 오버헤드가 적고, 전통적으로 그렇게 설계되었습니다. 큰 응답은 TCP로 넘어가는 경우가 있습니다.

Q5. 게임은 왜 UDP를 쓰나요?

최신 위치 정보는 손실되면 다음 프레임으로 대체하기 쉽고, 지연 민감도가 높기 때문입니다. 중요 이벤트는 별도 신뢰 채널을 두기도 합니다.

마무리

정확한 바이트 전달이면 TCP(또는 QUIC) 계열이 기본입니다.
실시간·손실 허용이면 UDP를 검토하고, 그 위에 신뢰 계층이 필요하면 QUIC을 고려합니다.
2026년 웹에서는 HTTP/3가 TCP의 한계를 보완하는 실전 옵션입니다.

한 줄 정리: 신뢰·순서가 필요하면 TCP(또는 QUIC), 지연·손실 허용이면 UDP—애플리케이션 요구를 먼저 적고 고릅니다.

프로덕션에서 흔한 실수

실수	결과	점검
“UDP가 더 빠르다”만 기억	손실 링크에서 품질 붕괴	손실 허용 여부를 먼저 합의
HTTP/3만 켜고 UDP 방화벽 미확인	일부 사용자 폴백·지연	UDP 443 정책·관측
UDP에 재전송을 안 넣음	앱이 무결성을 못 맞춤	요청-응답이면 타임아웃·재시도 설계 또는 QUIC 검토

TCP 완벽 가이드
UDP 실전 가이드

키워드

TCP, UDP, QUIC, HTTP/3, 네트워크, 신뢰성, 지연, 소켓, 비교