Skip to main content
우리가 보는 실시간 축구 중계는, 사실 가끔 몇 조각쯤 놓쳐도 그냥 계속 흘러가요.
IP 주소와 라우팅 - 패킷은 어떻게 길을 찾을까?에서 우리는 패킷이 IP 주소를 따라 길을 찾아간다는 걸 봤어요. 근데 거기서 또 이런 궁금증이 생겼죠.
“그럼 도착했다는 건 어떻게 알아? 중간에 패킷이 사라지면?”
좋은 질문이에요. 인터넷은 이 문제를 해결하려고 성격이 다른 두 방식을 써요. 하나는 엄청 꼼꼼하고, 하나는 엄청 빠르죠. 바로 TCPUDP 예요. 이름만 들으면 벌써 머리 아플 것 같죠? 근데요, 사실 일상 비유로 보면 그렇게 어렵지 않아요.

중요한 서류를 보낼 때 방식이 갈려요

여러분이 친구한테 중요한 서류를 보낸다고 상상해볼까요? 보내는 방법은 두 가지예요.
  1. 등기 우편으로 보내기
  2. 확인 없이 그냥 전단지처럼 뿌리기
등기 우편은 이런 식이에요.
  • 보냈다는 기록이 남아요
  • 상대가 받았는지 확인해요
  • 중간에 빠지면 다시 보내요
  • 순서가 중요하면 순서도 맞춰요
반대로 전단지는 어때요?
  • 일단 빨리 뿌려요
  • 누가 몇 장을 못 받았는지는 신경 안 써요
  • 대신 절차가 거의 없어서 훨씬 가벼워요
짠! TCP는 등기 우편 쪽이고, UDP는 전단지나 방송 쪽에 가까워요.

TCP와 UDP는 뭐가 다를까요?

둘 다 데이터를 보내는 방식이긴 해요. 근데 성격이 완전히 달라요. 이 차이를 한 문장으로 줄이면 이거예요.
TCP는 정확성이 중요할 때, UDP는 속도가 더 중요할 때 써요.

TCP는 먼저 인사부터 해요

TCP는 그냥 던지고 시작하지 않아요. 먼저 상대가 준비됐는지 확인해요. 다만 여기서는 “TCP는 먼저 확인하고 시작하는 성격이구나” 정도만 잡고 갈게요. SYN, ACK, sequence 번호처럼 그 인사 안에서 실제로 무슨 숫자와 신호가 오가는지는 뒤의 TCP 3-way handshake 글에서 본격적으로 열어볼 거예요. 이런 식으로 보냈다 → 받았다 를 계속 확인하면서 가요. 그래서 믿음직하죠.

UDP는 확인보다 속도를 택해요

UDP는 달라요. “잘 받았어?” 를 일일이 묻지 않아요. 그냥 이렇게 가요.
  1. 데이터 보냄
  2. 또 보냄
  3. 또 보냄
  4. 계속 보냄
중간에 하나가 빠질 수도 있어요. 근데요, 실시간 상황에서는 그게 오히려 더 나을 때가 많아요. 예를 들어 축구 생중계를 보는데 2초 전 장면을 완벽하게 다시 받느라 화면이 멈춘다면 어떨까요?
아예 끊기는 게 더 답답하잖아요.
그래서 이런 경우엔 조금 놓치더라도 계속 앞으로 가는 방식이 더 잘 맞아요. 그게 UDP예요.

근데 왜 굳이 두 가지나 있어요?

하나로 통일하면 편할 것 같죠? 사실은 아니에요. 인터넷에서는 상황마다 중요한 게 다르거든요.

1. 어떤 데이터는 절대 틀리면 안 돼요

여러분이 인터넷 뱅킹에서 송금 버튼을 눌렀다고 해볼게요. 이때 데이터가 하나라도 빠지면 어떨까요? 금액이 틀리거나, 요청이 중복되거나, 로그인 정보가 꼬일 수도 있어요. 무섭죠. 이럴 땐 느려도 괜찮으니 정확하게, 순서대로, 빠짐없이 가는 게 중요해요. 그래서 TCP를 써요.

2. 어떤 데이터는 지금 이 순간이 더 중요해요

반대로 영상 통화나 온라인 게임은 어때요? 여기서는 패킷 하나를 완벽하게 복구하느라 멈추는 것보다, 조금 거칠어도 지금 바로 도착하는 것이 더 중요해요. 목소리가 아주 잠깐 끊기는 건 참을 수 있어도, 3초 뒤에 밀려서 들리면 대화가 안 되잖아요.

3. 확인 절차도 공짜는 아니에요

TCP가 꼼꼼한 건 좋은데, 그 꼼꼼함에는 비용이 들어요.
  • 연결 시작할 때 인사해야 하고
  • 받았는지 계속 확인해야 하고
  • 빠지면 다시 보내야 하고
  • 순서가 꼬이면 다시 정렬해야 해요
이 과정이 다 시간이고, 이에요. 그래서 필요 없을 땐 UDP처럼 가볍게 보내는 편이 더 효율적이죠.

그럼 진짜 TCP와 UDP는 어떻게 생겼을까요?

실제로는 둘 다 패킷 앞부분에 자기만의 정보표를 붙여요. 근데 TCP 쪽이 훨씬 더 꼼꼼해서 정보가 많아요.

TCP는 적을 게 많아요

51515
443
1201
← 몇 번째 데이터인지
1301
← 어디까지 받았는지
SYN / ACK
← 연결, 확인 같은 신호
이걸 보면 왜 TCP가 꼼꼼한지 감이 와요. 순서 번호, 확인 번호, 연결 신호 같은 게 다 들어 있거든요. 여기서는 큰 그림만 잡고 넘어갈게요. 만약 “저 SYN / ACK, 순서 번호, 확인 번호가 진짜 TCP 헤더 몇 번째 칸에 들어가는데요?” 가 궁금해졌다면, 심화편 TCP 헤더는 왜 이렇게 칸이 많을까요? 에서 32비트 격자 위로 실제 위치를 바로 펼쳐볼 수 있어요.

UDP는 훨씬 단순해요

51515
5004
128 bytes
0x2A91
보다시피 UDP는 “어디서 왔고, 어디로 가고, 길이가 얼마인지” 정도만 빠르게 적고 지나가요. 훨씬 가볍죠. 더 깊게 보고 싶다면 UDP 헤더는 왜 딱 8바이트일까요?에서 LengthChecksum의 실제 위치를 확인할 수 있어요. UDP 위에서 신뢰성과 보안을 다시 설계한 이유가 궁금할 때는 QUIC은 왜 UDP 위에서 돌아갈까요?로 이어가면 돼요.
UDP가 “대충 보내는 방식”이라는 뜻은 아니에요. 일부러 확인 절차를 줄인 방식에 더 가까워요. 그래서 실시간 서비스에서는 오히려 아주 똑똑한 선택일 때가 많아요.

자, 정리해볼까요?

  • TCP 는 도착 확인, 재전송, 순서 보장을 해주는 꼼꼼한 방식이에요.
  • UDP 는 확인 절차를 줄이고 빠르게 보내는 가벼운 방식이에요.
  • 로그인, 결제, 파일 전송처럼 정확성이 중요하면 TCP 가 잘 맞아요.
  • 게임, 음성 통화, 생중계처럼 실시간성이 중요하면 UDP 가 잘 맞아요.
  • 둘 중 뭐가 더 좋다기보다, 상황에 맞는 도구가 다를 뿐이에요.
어때요? 이제 “TCP가 더 좋고 UDP는 안 좋은 거 아니야?” 같은 느낌은 조금 사라지죠? 사실은 둘 다 인터넷에 꼭 필요한 친구예요. 한 명은 꼼꼼해서 좋고, 한 명은 가벼워서 좋아요.

다음 글 예고

근데 여기서 또 이런 생각이 들지 않으세요?
“우리는 google.com만 쳤는데, 그걸 어떻게 IP 주소로 바꿔서 찾아가죠?”
다음 글에서는 “DNS” 이야기를 해볼게요. 사람은 이름을 기억하고, 컴퓨터는 숫자를 좋아하잖아요. 그 둘 사이를 누가 통역해주는지 같이 살펴봐요.