2025-09-23 20:43
-
TCP는 신뢰성 있는 연결을 통해 데이터의 순서와 정확성을 보장하는 반면, UDP는 속도를 우선시하여 데이터를 빠르게 전송하는 데 집중합니다. TCP IP
-
TCP는 3-way handshake로 연결을 설정하고 흐름 제어, 혼잡 제어 기능으로 안정성을 높이며, 파일 전송이나 이메일 등에 사용됩니다.
-
UDP는 연결 설정 없이 데이터를 전송하며, DNS, 실시간 스트리밍, 온라인 게임처럼 약간의 데이터 손실보다 속도가 중요한 서비스에 적합합니다.
TCP UDP 완벽 해부 개발자라면 반드시 알아야 할 핵심 프로토콜 가이드
인터넷이라는 거대한 정보의 바다에서 데이터는 어떻게 정확하고 빠르게 원하는 목적지까지 도달할 수 있을까요? 우리가 매일 사용하는 웹 브라우징, 이메일, 온라인 게임, 영상 스트리밍 이면에는 보이지 않는 약속, 즉 **프로토콜(Protocol)**이 존재합니다. 그중에서도 데이터 전송의 핵심을 담당하는 두 거인, TCP와 UDP는 모든 네트워크 개발자가 반드시 이해해야 할 필수 개념입니다.
이 핸드북은 TCP와 UDP가 왜 만들어졌는지 그 탄생 배경부터 시작하여, 각각의 내부 구조와 동작 방식, 그리고 어떤 상황에서 무엇을 선택해야 하는지에 대한 심도 있는 가이드라인을 제공합니다. 단순히 ‘TCP는 안정적이고 UDP는 빠르다’는 표면적인 이해를 넘어, 두 프로토콜의 철학과 기술적 장단점을 완벽하게 해부하여 여러분의 지식 기반을 단단하게 만들어 드릴 것입니다. 🧐
1. 태초에 약속이 있었다 TCP와 UDP의 탄생 배경
1960년대, 미 국방부의 ARPANET 프로젝트에서 시작된 인터넷의 초기 목표는 핵 공격과 같은 재앙 속에서도 살아남는 분산된 통신망을 구축하는 것이었습니다. 여러 컴퓨터가 서로 연결되고 데이터를 주고받기 위해서는 공통된 규칙, 즉 프로토콜이 필요했습니다.
이 과정에서 탄생한 것이 바로 **TCP/IP 프로토콜 스위트(Suite)**입니다. 이는 인터넷 통신을 4개의 추상화된 계층으로 나누어 설명합니다.
-
애플리케이션 계층 (Application Layer): HTTP, FTP, SMTP 등 사용자가 직접 접하는 서비스
-
전송 계층 (Transport Layer): TCP, UDP가 위치하며, 데이터의 종단 간(End-to-end) 전송을 책임짐
-
인터넷 계층 (Internet Layer): IP가 위치하며, 데이터 패킷의 경로를 설정(Routing)
-
네트워크 인터페이스 계층 (Network Interface Layer): 물리적인 네트워크(이더넷 등)와 연결
여기서 핵심은 전송 계층입니다. 인터넷 계층의 IP는 데이터를 목적지 컴퓨터까지 보내는 역할만 할 뿐, 그 데이터가 올바르게 도착했는지, 순서가 뒤섞이지는 않았는지, 중간에 사라지지는 않았는지에 대해서는 전혀 신경 쓰지 않습니다. 마치 택배 기사가 물건을 집 앞에 두고 갈 뿐, 집안의 누가 어떤 순서로 받는지는 관여하지 않는 것과 같습니다.
이 문제를 해결하기 위해 **TCP(Transmission Control Protocol)**와 **UDP(User Datagram Protocol)**가 등장했습니다. 이들은 IP가 전달한 데이터가 최종적으로 어떤 애플리케이션(프로세스)에, 어떤 방식으로 전달될지를 책임지는 역할을 맡습니다. 이들은 ‘포트(Port)‘라는 개념을 사용하여 한 컴퓨터 내에서 실행 중인 여러 애플리케이션 중 정확한 목적지를 찾아 데이터를 전달합니다.
결론적으로 TCP와 UDP는 신뢰성이 없는 IP 위에서, 애플리케이션의 요구사항에 따라 신뢰성 있는 통신을 할 것인가, 혹은 빠른 통신을 할 것인가라는 두 가지 선택지를 제공하기 위해 탄생했습니다.
2. 신뢰의 화신 TCP (Transmission Control Protocol) 꼼꼼한 우체부 이야기 📨
TCP는 **‘신뢰성’**이라는 단어로 요약할 수 있습니다. 데이터를 보내기 전에 상대방과 미리 연결을 설정하고, 데이터가 순서대로 정확하게 전달되었는지 일일이 확인하며, 네트워크 상황에 따라 전송 속도를 조절하는 매우 꼼꼼하고 책임감 있는 프로토콜입니다.
비유하자면, 중요한 계약 서류를 보내는 등기 우편 서비스와 같습니다. 보내기 전에 상대방에게 받을 준비가 되었는지 확인 전화를 하고(연결 설정), 각 페이지에 쪽 번호를 매겨 순서대로 보내며(순서 보장), 상대방이 잘 받았다는 확인 서명을 받을 때까지 기다리고(응답 확인), 만약 중간에 분실되면 즉시 재전송(재전송)해주는 서비스입니다.
TCP의 핵심 특징
-
연결 지향 (Connection-oriented): 데이터를 보내기 전에 반드시 상대방과 연결을 설정하는 3-Way Handshake 과정을 거칩니다.
-
신뢰성 있는 데이터 전송 (Reliable Data Transfer): ACK(응답)와 재전송 메커니즘을 통해 데이터의 손실을 감지하고 복구합니다.
-
순서 보장 (In-order Delivery): 데이터 조각(세그먼트)에 순서 번호(Sequence Number)를 부여하여 수신 측에서 순서대로 재조립할 수 있도록 보장합니다.
-
흐름 제어 (Flow Control): 수신 측이 감당할 수 있는 만큼만 데이터를 보내도록 송신 측의 전송량을 조절합니다.
-
혼잡 제어 (Congestion Control): 네트워크의 혼잡 상태를 파악하고, 혼잡이 발생했을 때 전송량을 줄여 네트워크 붕괴를 방지합니다.
TCP 헤더 구조 들여다보기
TCP의 신뢰성은 바로 이 복잡한 헤더 구조에서 나옵니다.
| 필드 (Field) | 크기 (Bits) | 설명 |
|---|---|---|
| Source Port | 16 | 출발지 애플리케이션의 포트 번호 |
| Destination Port | 16 | 목적지 애플리케이션의 포트 번호 |
| Sequence Number | 32 | 세그먼트의 순서 번호. 데이터의 첫 번째 바이트에 부여되는 고유 번호 |
| Acknowledgment Number | 32 | 수신을 기대하는 다음 시퀀스 번호. (받은 번호 + 1) |
| Header Length | 4 | TCP 헤더의 전체 길이 (32비트 워드 단위) |
| Reserved | 6 | 예약된 필드. 현재는 사용되지 않음 |
| Flags | 6 | URG, ACK, PSH, RST, SYN, FIN 등 제어 비트 |
| Window Size | 16 | 수신 버퍼의 남은 공간 크기. 흐름 제어에 사용 |
| Checksum | 16 | 헤더 및 데이터의 오류 검출을 위한 값 |
| Urgent Pointer | 16 | URG 플래그가 설정되었을 때, 긴급 데이터의 위치를 나타냄 |
| Options | 가변 | 추가적인 기능 (예: Maximum Segment Size) |
특히 Flags 필드의 SYN, ACK, FIN 비트는 TCP의 연결 설정 및 해제 과정에서 핵심적인 역할을 수행합니다.
TCP의 작동 방식
① 연결 설정: 3-Way Handshake
TCP 통신은 “안녕하세요, 통신 시작해도 될까요?”라고 묻는 정중한 인사로 시작됩니다.
-
[SYN] 클라이언트 → 서버: 클라이언트가 서버에게 접속을 요청하는
SYN패킷을 보냅니다. “통신하고 싶은데, 가능할까요? 제 시작 번호는 X입니다.” -
[SYN+ACK] 서버 → 클라이언트: 서버는 요청을 수락하며, 자신도 통신 준비가 되었음을 알리는
SYN과 클라이언트의 요청을 잘 받았다는ACK를 함께 보냅니다. “네, 좋아요. 요청 잘 받았어요(ACK=X+1). 제 시작 번호는 Y입니다.” -
[ACK] 클라이언트 → 서버: 클라이언트는 서버의 허락을 잘 받았다는
ACK를 보냅니다. 이로써 연결이 확립(Established)됩니다. “알겠습니다(ACK=Y+1). 이제 데이터 보낼게요.”
이 3단계 과정은 양쪽 모두 데이터를 보낼 준비가 되었고, 서로의 초기 순서 번호를 인지했음을 보장하여 신뢰성 있는 통신의 기반을 마련합니다.
② 데이터 전송 및 흐름/혼잡 제어
연결이 수립되면 데이터는 **세그먼트(Segment)**라는 단위로 잘려서 전송됩니다. 송신 측은 Sequence Number를 붙여 데이터를 보내고, 수신 측은 데이터를 받을 때마다 Acknowledgment Number를 통해 “여기까지 잘 받았으니 다음 것을 보내달라”고 응답합니다. 만약 일정 시간 동안 ACK가 오지 않으면 송신 측은 데이터가 유실되었다고 판단하고 해당 세그먼트를 재전송합니다.
-
흐름 제어: 수신 측은
Window Size필드에 자신의 버퍼 여유 공간 크기를 실어 보냅니다. 송신 측은 이 값을 보고 수신 측이 감당할 수 있을 만큼만 데이터를 보내 과부하를 막습니다. 이는 마치 물을 따를 때 상대방 컵의 크기를 보고 속도를 조절하는 것과 같습니다. -
혼잡 제어: 네트워크 전체가 막히는 상황을 방지하기 위해, TCP는 ACK가 늦게 오거나 패킷 손실이 감지되면 전송 속도를 스스로 줄이는 Slow Start, Congestion Avoidance 같은 알고리즘을 사용합니다.
③ 연결 해제: 4-Way Handshake
통신이 끝나면 “이제 그만 통신할게요”라는 작별 인사를 나눕니다.
-
[FIN] 클라이언트 → 서버: 클라이언트가 연결 종료를 알리는
FIN을 보냅니다. “저는 보낼 데이터가 다 끝났습니다.” -
[ACK] 서버 → 클라이언트: 서버는 일단 알겠다는
ACK를 보냅니다. -
[FIN] 서버 → 클라이언트: 서버도 보낼 데이터가 모두 끝났다면, 연결을 종료하겠다는
FIN을 보냅니다. -
[ACK] 클라이언트 → 서버: 클라이언트는 서버의 종료 요청을 확인했다는
ACK를 보낸 후, 혹시 모를 지연 패킷을 처리하기 위해 잠시 대기(TIME_WAIT상태)했다가 연결을 완전히 닫습니다.
TCP는 언제 사용할까?
데이터의 정확성과 순서가 서비스 품질에 결정적인 영향을 미치는 경우에 사용됩니다.
-
웹 브라우징 (HTTP/HTTPS): 웹 페이지의 HTML, CSS, 이미지 파일이 하나라도 깨지거나 순서가 바뀌면 페이지가 제대로 보이지 않습니다.
-
파일 전송 (FTP): 파일의 내용이 1비트라도 달라지면 파일이 손상됩니다.
-
이메일 (SMTP, POP3, IMAP): 이메일 내용이 중간에 사라지거나 뒤섞이면 안 됩니다.
-
데이터베이스 연결: 쿼리나 결과 데이터가 정확하게 전달되어야 합니다.
3. 속도의 제왕 UDP (User Datagram Protocol) 빠른 퀵서비스 이야기 🏍️
UDP는 TCP와 정반대의 철학을 가집니다. **‘속도’**와 **‘단순함’**을 최우선으로 여기며, 신뢰성을 보장하기 위한 복잡한 절차들을 과감히 생략했습니다.
비유하자면, 대량의 전단지를 뿌리는 퀵서비스와 같습니다. 상대방에게 받을 준비가 되었는지 묻지 않고(비연결성), 그냥 데이터를 ‘데이터그램(Datagram)‘이라는 덩어리로 만들어 던져버립니다(Best-effort). 도착 여부나 순서를 확인하지 않으며, 중간에 사라져도 신경 쓰지 않습니다. 그저 빠르고 효율적으로 보내는 것에만 집중합니다.
UDP의 핵심 특징
-
비연결성 (Connectionless): 데이터를 보내기 전에 연결을 설정하는 과정이 없습니다.
-
비신뢰성 (Unreliable): 데이터 전송을 보장하지 않습니다. 데이터가 유실될 수도, 순서가 바뀔 수도 있습니다.
-
순서 보장 안됨 (No Ordering): 먼저 보낸 데이터그램이 나중에 도착할 수 있습니다.
-
흐름 제어/혼잡 제어 없음: 네트워크 상황을 고려하지 않고 데이터를 최대한 빠르게 전송합니다.
-
최소한의 오버헤드: 헤더 구조가 매우 단순하여 처리 속도가 빠릅니다.
UDP 헤더 구조 들여다보기
TCP와 비교하면 놀라울 정도로 단순합니다.
| 필드 (Field) | 크기 (Bits) | 설명 |
|---|---|---|
| Source Port | 16 | 출발지 애플리케이션의 포트 번호 |
| Destination Port | 16 | 목적지 애플리케이션의 포트 번호 |
| Length | 16 | UDP 헤더와 데이터를 포함한 전체 길이 (바이트 단위) |
| Checksum | 16 | 오류 검출을 위한 값 (선택 사항) |
신뢰성을 위한 Sequence Number, Acknowledgment Number, Flags, Window Size 등이 모두 빠져있습니다. 단 4개의 필드로 구성되어 있어 헤더 처리 부담이 적고 그만큼 빠릅니다.
UDP는 왜 사용할까? ‘불안정함’의 가치
신뢰성이 없다는 것은 단점처럼 보이지만, 특정 상황에서는 오히려 큰 장점이 됩니다.
-
속도가 생명인 경우: 실시간 영상 스트리밍이나 온라인 게임에서는 0.1초의 지연이 치명적일 수 있습니다. TCP처럼 패킷 하나가 유실되었다고 재전송을 기다리다 보면 화면이 멈추거나 게임 캐릭터가 순간이동하는 현상이 발생합니다. 차라리 약간의 화질 저하(패킷 손실)를 감수하더라도 현재 시점의 데이터를 빠르게 받는 것이 훨씬 중요합니다.
-
애플리케이션 레벨에서 신뢰성 제어가 가능한 경우: UDP 자체는 신뢰성을 보장하지 않지만, 필요하다면 애플리케이션 단에서 직접 재전송이나 순서 제어 로직을 구현할 수 있습니다. 이를 통해 TCP의 무거운 기능은 빼고, 서비스에 꼭 필요한 만큼의 신뢰성만 선택적으로 추가하여 최적화할 수 있습니다. (예: Google의 QUIC 프로토콜)
-
브로드캐스팅/멀티캐스팅: 여러 대상에게 동시에 데이터를 전송해야 할 경우, 모든 수신자와 일일이 TCP 연결을 맺는 것은 비효율적입니다. UDP는 연결 없이 데이터를 뿌릴 수 있어 이런 상황에 적합합니다.
UDP는 언제 사용할까?
약간의 데이터 손실은 괜찮지만, 실시간성과 빠른 응답 속도가 중요한 서비스에 사용됩니다.
-
DNS (Domain Name System):
google.com같은 도메인 이름을 IP 주소로 변환하는 서비스. 단일 요청과 응답으로 끝나므로 빠르고 가벼운 UDP가 적합합니다. -
실시간 스트리밍 (VoIP, 비디오 스트리밍): 약간의 음질/화질 저하가 있더라도 끊김 없이 실시간으로 데이터를 받는 것이 중요합니다.
-
온라인 게임: 플레이어의 위치나 행동 데이터를 최대한 빠르게 서버와 주고받아야 합니다.
-
DHCP (Dynamic Host Configuration Protocol): 네트워크에 접속할 때 IP 주소를 할당받는 프로토콜.
4. TCP vs UDP 최종 비교 분석
두 프로토콜의 차이점을 한눈에 비교해 보겠습니다.
| 구분 | TCP (Transmission Control Protocol) | UDP (User Datagram Protocol) |
|---|---|---|
| 비유 | 꼼꼼한 등기 우편 📨 | 빠른 퀵서비스 🏍️ |
| 연결 방식 | 연결 지향 (Connection-Oriented) | 비연결성 (Connectionless) |
| 신뢰성 | 높음 (데이터 전송 보장) | 낮음 (Best-Effort, 전송 보장 안 함) |
| 순서 보장 | 보장 (O) | 보장 안 함 (X) |
| 흐름 제어 | 지원 (O, 슬라이딩 윈도우) | 지원 안 함 (X) |
| 혼잡 제어 | 지원 (O) | 지원 안 함 (X) |
| 속도 | 상대적으로 느림 | 상대적으로 빠름 |
| 헤더 크기 | 큼 (최소 20바이트) | 작음 (8바이트) |
| 데이터 전송 단위 | 세그먼트 (Segment), 스트림(Stream) 기반 | 데이터그램 (Datagram) 기반 |
| 주요 사용 사례 | 웹(HTTP), 파일 전송(FTP), 이메일(SMTP) | DNS, 실시간 스트리밍(VoIP), 온라인 게임 |
5. 미래의 프로토콜 QUIC 그리고 결론
지금까지 우리는 데이터 전송의 두 거인, TCP와 UDP에 대해 깊이 있게 탐구했습니다. TCP는 신뢰성을 위해, UDP는 속도를 위해 설계되었으며, 어떤 프로토콜을 선택할지는 전적으로 애플리케이션의 요구사항에 달려있습니다.
하지만 기술은 멈추지 않습니다. 최근에는 TCP의 신뢰성과 UDP의 속도라는 두 마리 토끼를 모두 잡으려는 시도가 등장했는데, 그 대표주자가 바로 **QUIC (Quick UDP Internet Connections)**입니다. 🚀
QUIC는 이름에서 알 수 있듯이 UDP를 기반으로 만들어졌습니다. UDP의 빠른 속성과 비연결성의 장점을 취하면서, 그 위에 TCP의 신뢰성 보장 기능(패킷 재전송, 혼잡 제어 등)을 애플리케이션 계층에서 직접 구현한 프로토콜입니다. 이를 통해 3-Way Handshake에 걸리는 시간을 단축하고, 모바일 환경에서 네트워크가 Wi-Fi에서 LTE로 바뀌어도 연결이 끊기지 않는 등 현대 인터넷 환경에 최적화된 성능을 보여줍니다. 우리가 사용하는 HTTP/3는 바로 이 QUIC 위에서 동작합니다.
결론적으로, TCP와 UDP를 이해하는 것은 단순히 오래된 기술을 배우는 것이 아닙니다. 이는 인터넷 통신의 가장 근본적인 원리를 이해하는 것이며, QUIC와 같은 최신 기술이 어떤 문제를 해결하기 위해 등장했는지 그 맥락을 파악하는 열쇠가 됩니다.
여러분이 개발하는 서비스가 데이터의 무결성을 최우선으로 해야 한다면 TCP를, 찰나의 지연도 허용할 수 없는 속도 경쟁을 하고 있다면 UDP를 선택해야 할 것입니다. 그리고 이 두 가지를 모두 고민하고 있다면, QUIC와 같은 차세대 프로토콜의 등장을 주목해야 합니다. 이 핸드북이 여러분의 기술적 선택에 깊이를 더해주는 든든한 길잡이가 되기를 바랍니다.