C-1: 계층 모델과 TCP/UDP

안녕하세요, 홍순구 튜터입니다. CS 기초 일곱 번째 시간이에요.

지난 여섯 시간 동안 우리는 줄곧 한 대의 컴퓨터 안을 들여다봤어요. CPU가 명령을 어떻게 처리하는지(A), 운영체제가 프로세스와 스레드를 만들어 메모리를 나눠주고 자원을 안전하게 공유하게 하는지(B)를 봤죠. 그런데 오늘 우리가 쓰는 컴퓨터는 혼자 일하지 않습니다. 여러분이 브라우저에 주소를 치는 순간, 신호는 책상 위 컴퓨터를 떠나 저 멀리 어딘가의 서버까지 갔다가 다시 돌아와요. 오늘부터는 시야를 컴퓨터 바깥으로 넓혀, 여러 컴퓨터가 서로 대화하는 네트워크의 세계로 들어갑니다.

그런데 컴퓨터끼리 대화하는 일은 생각보다 까다로워요. 신호를 전선에 어떻게 실을지, 그 신호가 수많은 컴퓨터 중 어느 컴퓨터로 가야 할지, 도중에 손실되면 어떻게 다시 보낼지, 받은 쪽 어느 프로그램에 전달할지 — 따져야 할 게 한둘이 아니죠. 이걸 한 덩어리로 묶어 처리하면, 그중 하나만 바꿔도 전부가 흔들립니다. 그래서 네트워크는 일을 계층(layer)으로 층층이 나눠요. 각 층은 자기 일만 책임지고 아래위 층과는 정해진 방식으로만 주고받죠. 이 "왜 계층으로 나누나"가 오늘의 첫 단추이자, 네트워크 전체를 꿰는 열쇠입니다.

계층의 지도를 손에 쥐면, 그 위에서 데이터가 어떻게 포장되어(캡슐화) 어떤 주소(IP·포트·MAC)를 보고 길을 찾는지가 보여요. 그리고 마지막엔 오늘의 주인공인 TCP와 UDP를 만납니다. 하나는 전화처럼 먼저 연결을 맺고 확실하게 주고받는 쪽, 다른 하나는 엽서처럼 일단 던지고 보는 빠른 쪽이에요. 둘 중 무엇을 고르느냐가 신뢰성과 속도의 맞바꿈이고, 이 과목 핵심 그림 셋 중 마지막인 3-way handshake(연결을 세 번 인사로 맺는 과정)가 바로 여기서 나옵니다.

네트워크는 기술 면접의 단골 무대예요. "TCP와 UDP의 차이가 뭔가요"·"3-way handshake를 설명해보세요"·"OSI 7계층이 뭔가요"·"연결 종료는 왜 4번인가요" — 이 넷은 거의 반드시 나옵니다. 오늘 원리부터 잡아서, 외운 한 줄이 아니라 풀어서 답할 수 있게 만들어요.

오늘 우리가 걸을 길은 이렇습니다.

   오늘의 여정 — 계층 모델과 TCP/UDP

   ① 네트워크와 계층 — 왜 일을 층층이 나누나
   ② OSI 7계층 vs TCP/IP 4계층 — 두 개의 지도 (면접 빈출)
   ③ 캡슐화 — 데이터를 봉투에 또 봉투에 넣기
   ④ 주소 삼총사 — MAC·IP·포트, 누가 누구인가
   ⑤ TCP vs UDP — 신뢰성과 속도의 맞바꿈 (면접 1순위)
   ⑥ 3-way handshake — 시작 전 세 번 인사 (핵심 그림)
   ⑦ 4-way handshake — 끝낼 땐 왜 네 번
   ⑧ 흐름 제어·혼잡 제어 — TCP가 신뢰성을 지키는 법

①~④는 "여러 컴퓨터가 대화하는 큰 그림"이에요. 일을 계층으로 나누고, 데이터를 포장하고, 주소로 길을 찾는 이야기죠. ⑤~⑧은 "그 길 위에서 실제로 어떻게 믿을 만하게 주고받나"입니다. TCP와 UDP를 고르고, 연결을 맺고 끊고, 신뢰성을 지키는 장치들을 봐요. 큰 지도를 먼저 펼친 뒤 그 위를 실제로 달려보는 흐름입니다.

💡 오늘 수업의 핵심 — "여러 컴퓨터가 대화하려면 일을 계층으로 나누고(OSI 7계층·TCP/IP 4계층), 데이터를 캡슐화해 IP·포트·MAC 주소로 길을 찾으며, 신뢰성이 필요하면 TCP로 3-way handshake를 맺고 속도가 우선이면 UDP를 고른다" 🎯

🎯 학습 목표

• 네트워크를 왜 계층으로 나누는지 설명하고, OSI 7계층과 TCP/IP 4계층을 대조하며 데이터가 층을 내려가며 포장되는 캡슐화 과정을 이해합니다.
• IP·포트·MAC 세 주소가 각각 무엇을 가리키는지 구분하고, 면접 1순위인 TCP vs UDP를 신뢰성·순서·속도의 트레이드오프로 막힘 없이 답합니다.
• 3-way handshake와 4-way handshake로 연결의 시작과 끝을 설명하고, TCP가 신뢰성을 지키는 흐름 제어·혼잡 제어의 직관을 잡습니다.

Step 1: "네트워크와 계층 — 왜 일을 층층이 나누나"

네트워크(network)는 둘 이상의 컴퓨터가 케이블이나 무선으로 이어져 데이터를 주고받는 것을 말해요. 여러분 컴퓨터와 인스타그램 서버, 그 사이를 잇는 수많은 장비가 모두 거대한 네트워크의 일부죠. 그런데 컴퓨터끼리 대화하는 일은 한 가지 동작이 아니라 여러 일이 한꺼번에 얽혀 있어요.

생각해볼까요. 신호를 전선에 어떻게 전기로 실을지, 그 신호가 세상의 수많은 컴퓨터 중 정확히 어느 한 대로 가야 할지, 가는 길에 일부가 사라지면 어떻게 다시 보낼지, 무사히 도착하면 그 컴퓨터 안 어느 프로그램에 건넬지. 이 모든 걸 하나의 거대한 프로그램으로 뭉쳐서 처리한다고 해봐요. 그중 한 가지 방식만 바뀌어도(예를 들어 유선에서 Wi-Fi로) 전체를 다시 짜야 합니다.

그래서 네트워크는 일을 계층(layer)으로 층층이 나눠요. 각 층은 자기 일만 책임지고, 아래위 층과는 정해진 방식으로만 주고받습니다. 우편 시스템을 떠올리면 딱 맞아요.

   편지를 부치는 과정 — 각 단계는 자기 일만 한다

   나 (편지 작성)       "안녕" 이라는 내용을 적는다
        │
   봉투에 주소 쓰기     받는 사람·보내는 사람 주소를 적는다
        │
   우체국 (분류)        주소를 보고 어느 지역으로 보낼지 정한다
        │
   운송 (트럭·비행기)   실제로 물리적으로 실어 나른다
        │
   받는 동네 우체국     도착한 편지를 집배원에게 넘긴다
        │
   집배원 (배달)        받는 사람 우편함에 넣는다

편지를 쓰는 나는 트럭이 어떤 길로 가는지 몰라도 되고, 트럭 기사는 편지 내용이 뭔지 몰라도 됩니다. 각 단계가 자기 일만 하고 다음 단계로 넘기죠. 네트워크의 계층도 똑같아요. 계층으로 나누면 세 가지 이득이 생깁니다.

• 관심사 분리: 각 층은 자기 책임만 신경 쓰면 됩니다. 윗층은 아랫층이 어떻게 일하는지 몰라도 돼요.
• 교체 자유: 한 층만 바꿔도 나머지는 그대로입니다. 유선을 Wi-Fi로 갈아도, 그 위에서 도는 웹브라우저는 코드 한 줄 안 바꿔요.
• 표준화: 층과 층 사이 주고받는 방식만 약속해두면, 서로 다른 회사가 만든 장비끼리도 통신합니다.

인터넷이 수십 년간 끊임없이 바뀌면서도 멈추지 않고 진화해온 비결이 바로 이 계층 구조예요. 다음 Step부터 그 층들이 구체적으로 어떻게 생겼는지 두 개의 지도로 살펴봅니다.

🎯 면접에서는 이렇게 답하세요

"네트워크를 계층으로 나누는 이유는 복잡한 통신을 책임 단위로 쪼개기 위해서입니다. 각 층이 자기 일만 맡으니 관심사가 분리되고, 한 층의 기술이 바뀌어도(유선 → Wi-Fi) 다른 층은 그대로 둘 수 있어 교체가 자유롭습니다. 또 층 사이 인터페이스만 표준으로 약속하면 서로 다른 제조사의 장비끼리도 통신할 수 있고요. 한 덩어리로 만들면 한 곳만 바꿔도 전체를 다시 짜야 하지만, 계층으로 나누면 각 층이 독립적으로 발전할 수 있습니다."

Step 2: "OSI 7계층 vs TCP/IP 4계층 — 두 개의 지도"

계층으로 나눈다는 건 알았어요. 그럼 몇 개 층으로, 어떻게 나눌까요? 여기서 두 개의 지도가 등장합니다. 하나는 교과서와 면접의 표준인 OSI 7계층, 다른 하나는 실제 인터넷이 돌아가는 TCP/IP 4계층이에요.

OSI 7계층은 국제표준화기구(ISO)가 "네트워크는 이렇게 일곱 층으로 나눠 생각하자"고 정리한 참조 모델입니다. 통신을 가장 잘게 쪼개 개념을 설명하기 좋아서, 교과서와 면접에서 기준으로 삼아요. TCP/IP 4계층은 실제 인터넷을 만들면서 자리 잡은 모델로, OSI의 위쪽 세 층을 하나로 합쳐 더 단순합니다. 둘을 나란히 놓으면 이렇게 대응돼요.

표가 길어 보이지만, 아래에서 위로 한 줄씩 읽으면 통신의 한살이가 그대로 그려져요. 맨 아래 물리 계층이 0과 1을 전기 신호로 전선에 싣고, 데이터링크가 바로 옆 장비로 그걸 넘기고, 네트워크가 여러 망을 건너 목적지까지 길을 찾고, 전송이 그 끝에서 어느 프로그램에 신뢰성 있게 꽂아주고, 맨 위 응용이 사람이 쓰는 서비스(웹·메일)를 올립니다.

외우는 요령을 하나 드릴게요. 면접에서는 OSI 7계층을 아래부터 "물리-데이터링크-네트워크-전송-세션-표현-응용" 순으로 말하면 됩니다. 그리고 실제 인터넷은 위쪽 세 층(세션·표현·응용)이 사실상 한 덩어리로 동작해서, TCP/IP 4계층으로 돈다고 덧붙이면 깔끔해요. OSI는 개념을 설명하는 이론 지도, TCP/IP는 실제로 구현된 지도라고 기억하세요.

🎯 면접에서는 이렇게 답하세요

"OSI 7계층은 아래부터 물리 - 데이터링크 - 네트워크 - 전송 - 세션 - 표현 - 응용입니다. 물리는 신호를 전선에 싣고, 데이터링크는 같은 망의 이웃 장비로(MAC), 네트워크는 여러 망을 건너 목적지까지(IP), 전송은 그 끝에서 프로세스 간 신뢰성·순서를(TCP/UDP·포트), 응용은 사람이 쓰는 서비스를(HTTP) 담당합니다. 실제 인터넷은 위쪽 세 층을 하나로 묶은 TCP/IP 4계층(응용·전송·인터넷·네트워크 접근)으로 동작하고요. OSI는 개념을 설명하는 참조 모델, TCP/IP는 실제 구현이라는 점이 핵심입니다."

Step 3: "캡슐화 — 데이터를 봉투에 또 봉투에 넣기"

계층이라는 지도를 손에 쥐었으니, 이제 실제 데이터가 그 층들을 어떻게 통과하는지 봅시다. 보내는 쪽에서 데이터는 맨 위 응용 계층에서 출발해 한 층씩 내려갑니다. 그런데 한 층을 내려갈 때마다 그 층이 자기 헤더(header, 머리말)를 데이터 앞에 척 붙여요. 이렇게 층을 내려가며 헤더를 덧씌우는 과정을 캡슐화(encapsulation)라고 합니다.

받는 쪽에서는 정반대예요. 맨 아래에서 신호를 받아 한 층씩 올라가며 그 헤더를 하나씩 떼어냅니다. 이걸 역캡슐화(decapsulation)라고 해요. 편지를 봉투에 넣고, 그 봉투를 더 큰 택배 상자에 담고, 그 상자를 컨테이너에 싣는 것과 같아요. 받는 쪽은 컨테이너를 열고, 상자를 열고, 봉투를 열어 마침내 편지를 꺼냅니다.

   보내는 쪽 — 계층을 내려가며 각 층이 자기 헤더를 덧붙인다 (캡슐화)

   [ Data ]                            ← 응용 : 보낼 데이터 그 자체
       │
   [ TCP | Data ]                      ← 전송 : TCP 헤더(포트) 붙임 = 세그먼트(Segment)
       │
   [ IP | TCP | Data ]                 ← 네트워크 : IP 헤더(IP 주소) 붙임 = 패킷(Packet)
       │
   [ Eth | IP | TCP | Data | FCS ]     ← 링크 : MAC 헤더+꼬리 붙임 = 프레임(Frame)
       │
   0 1 0 1 1 1 0 1 0 0 ...             ← 물리 : 비트(Bit) 신호로 전송

재밌는 건 데이터를 부르는 이름이 층마다 바뀐다는 거예요. 전송 계층에서 TCP 헤더가 붙으면 세그먼트, 네트워크 계층에서 IP 헤더가 붙으면 패킷, 데이터링크 계층에서 MAC 헤더가 붙으면 프레임, 물리 계층에선 그냥 비트입니다. 면접에서 "패킷"과 "프레임"을 정확히 구분해 쓰면 기본기가 있다는 신호예요.

핵심은 각 층이 윗층에서 받은 걸 그냥 '내용물'로만 본다는 점입니다. 네트워크 계층은 안에 든 TCP 헤더나 실제 데이터가 뭔지 들여다보지 않고, 그저 자기 IP 헤더를 앞에 붙일 뿐이에요. 이렇게 서로의 속을 안 봐도 되니까 각 층이 독립적으로 일할 수 있는 거죠. Step 1에서 말한 계층 분리의 힘이 캡슐화로 실제로 동작합니다.

🎯 면접에서는 이렇게 답하세요

"캡슐화는 데이터가 계층을 내려갈 때 각 층이 자기 헤더를 앞에 덧붙이는 과정입니다. 전송 계층에서 TCP 헤더가 붙어 세그먼트, 네트워크 계층에서 IP 헤더가 붙어 패킷, 데이터링크 계층에서 MAC 헤더가 붙어 프레임이 되고, 물리 계층에서 비트 신호로 나갑니다. 받는 쪽은 반대로 한 층씩 올라가며 헤더를 떼는 역캡슐화를 하고요. 각 층이 윗층 데이터를 그냥 내용물로만 보고 자기 헤더만 붙이기 때문에, 층끼리 서로의 속을 몰라도 독립적으로 동작할 수 있다는 게 계층 구조의 힘입니다."

Step 4: "주소 삼총사 — MAC·IP·포트, 누가 누구인가"

데이터가 길을 찾으려면 "어디로?"가 있어야 해요. 그런데 네트워크의 주소는 하나가 아니라 셋입니다. 각각 다른 계층에서, 다른 질문에 답해요. MAC은 "바로 옆 어느 장비", IP는 "전 세계 어느 컴퓨터", 포트는 "그 컴퓨터 안 어느 프로그램"을 가리킵니다.

MAC 주소는 랜카드(NIC)마다 공장에서 새겨 나오는 고유 번호예요. 48비트라 사실상 전 세계에서 겹치지 않고, 한 번 정해지면 안 바뀝니다. 같은 네트워크 안에서 "바로 옆 어느 장비냐"를 가리키죠. IP 주소는 네트워크상의 논리적 주소로, 전 세계에서 "어느 컴퓨터냐"를 가리킵니다. 논리적이라 상황에 따라 바뀔 수 있어요(공유기에서 새로 받거나, 다른 망으로 옮기면 달라집니다).

포트는 한 컴퓨터 안에서 "어느 프로그램이냐"를 가리키는 번호예요. 여기서 지난 시간 운영체제 이야기가 이어집니다. B-1에서 한 컴퓨터엔 여러 프로세스가 동시에 돈다고 했죠(브라우저·메신저·게임이 함께). IP 주소를 따라 컴퓨터까지는 왔는데, 그 안 어느 프로세스에 데이터를 건넬지는 포트가 정합니다. 포트는 곧 프로세스로 들어가는 문 번호예요. 웹 서버는 보통 80이나 443 포트에서 기다립니다.

   택배가 집까지 가서 주인을 찾는 길

   IP 주소    ──▶  어느 "건물(컴퓨터)" 인가          예) 192.168.0.5
   포트       ──▶  그 건물 안 "몇 호(프로그램)" 인가   예) :443  (웹 서버)
   MAC 주소   ──▶  바로 옆 장비로 넘길 때의 꼬리표      홉마다 바뀜

아파트 택배로 비유하면 깔끔해요. IP는 아파트 동 주소(어느 건물), 포트는 호수(몇 호 사는 누구), MAC은 그 집 현관에 각인된 절대 안 바뀌는 시리얼 번호입니다. 셋 다 필요한 이유가 여기 있어요. IP로 건물까지 가고, 포트로 그 안 사람을 찾고, 가는 길 한 구간 한 구간에서는 MAC으로 "바로 다음 장비"에게 넘깁니다.

🎯 면접에서는 이렇게 답하세요

"MAC 주소는 데이터링크 계층의 물리 주소로, 랜카드에 공장에서 박혀 바뀌지 않고 같은 네트워크 안 이웃 장비를 가리킵니다. IP 주소는 네트워크 계층의 논리 주소로, 전 세계 어느 호스트인지를 가리키며 상황에 따라 바뀔 수 있습니다. 포트는 전송 계층에서 그 호스트 안 어느 프로세스인지를 가리키는 번호고요. 그래서 IP로 컴퓨터까지, 포트로 프로그램까지, MAC으로 바로 다음 장비까지 찾아갑니다. IP는 최종 목적지라 끝까지 그대로지만, MAC은 한 구간(홉)을 지날 때마다 다음 장비 것으로 바뀝니다."

Step 5: "TCP vs UDP — 신뢰성과 속도의 맞바꿈"

드디어 오늘의 주인공입니다. TCP와 UDP는 둘 다 전송 계층의 프로토콜이에요. 응용 계층이 데이터를 보낼 때, 이 둘 중 하나를 골라 그 위에 얹습니다. 그리고 이 선택이 신뢰성과 속도를 맞바꾸는 결정이에요.

TCP(Transmission Control Protocol)는 연결형입니다. 데이터를 보내기 전에 먼저 연결을 맺고(다음 Step의 3-way handshake), 그 뒤로는 신뢰성을 꼼꼼히 챙겨요. 빠진 데이터는 다시 보내고, 순서가 뒤바뀌면 번호를 보고 바로잡고, 받는 쪽이 감당할 만큼만 속도를 조절합니다. 대신 이 모든 챙김이 시간 비용이라 상대적으로 느리고 무거워요. 전화 통화와 같습니다. "여보세요" 하고 연결을 확인한 뒤, 잘 들리는지 확인해가며 대화하죠.

UDP(User Datagram Protocol)는 비연결형이에요. 연결 맺는 절차 없이 데이터를 그냥 던집니다. 도착했는지 확인하지 않고, 순서도 보장하지 않아요. 대신 군더더기가 없어 빠르고 가볍습니다. 엽서와 같아요. 우체통에 넣으면 끝이고, 도착 확인은 하지 않죠.

어디에 무엇을 쓰는지가 둘의 성격을 잘 보여줘요. 한 바이트만 틀려도 큰일 나는 웹·파일 전송·이메일·결제는 TCP를 씁니다. 반대로 실시간 스트리밍·온라인 게임·화상통화는 UDP예요. 영상 한 프레임이 빠졌다고 멈춰 서서 재전송을 기다리면 오히려 더 끊기니까, 빠진 건 버리고 지금 도착한 걸 바로 보여주는 게 자연스럽거든요. 짧은 질의 한 번이면 끝나는 DNS도 가볍게 UDP로 갑니다. 신뢰성은 공짜가 아니라 속도와 맞바꾸는 것이라는 게 핵심이에요.

그런데 재밌는 이야기가 하나 있어요. "빠르지만 못 믿을" UDP 위에, 신뢰성을 다시 직접 얹은 프로토콜이 등장했습니다. 그게 QUIC이고, 이걸 쓰는 게 최신 웹 프로토콜인 HTTP/3예요. "TCP는 굼뜨고 UDP는 못 믿으니, UDP의 속도를 빌리고 그 위에 신뢰성을 새로 입히자"는 발상이죠. 이 흥미로운 뒤집기는 다음 시간(C-2)에 HTTP를 다룰 때 제대로 이어가겠습니다.

🎯 면접에서는 이렇게 답하세요

"TCP는 연결형이라 3-way handshake로 연결을 맺고, 시퀀스 번호로 순서를 보장하며 빠진 데이터를 재전송해 신뢰성을 보장합니다. 대신 그만큼 느리고 무겁죠. UDP는 비연결형이라 연결 없이 그냥 보내 빠르고 가볍지만 손실과 순서를 보장하지 않습니다. 그래서 정확성이 중요한 웹·파일·결제는 TCP, 실시간 속도가 중요한 스트리밍·게임·DNS는 UDP를 씁니다. 핵심은 신뢰성이 공짜가 아니라 속도와 맞바꾸는 것이라는 점이고, 실시간 분야에선 '늦게 정확히'보다 '지금 빠르게'가 나을 때가 많다는 겁니다."

Step 6: "3-way handshake — 시작 전 세 번 인사"

TCP는 데이터를 보내기 전에 연결부터 맺는다고 했죠. 그 연결을 맺는 절차가 이 과목 핵심 그림 셋 중 마지막인 3-way handshake예요. 이름 그대로 세 번 패킷을 주고받으며 서로 준비됐는지 확인하는 과정입니다. 전화로 치면 "여보세요" / "네, 들려요" / "네, 저도 들려요" 하고 통화를 시작하는 것과 같아요.

   3-way handshake — 데이터를 보내기 전 세 번의 인사

   클라이언트(Client)                               서버(Server)
       │                                                     │
       │  ① SYN (seq=x) ───────────────────────────────────▶│   "연결할래요"
       │                                                     │
       │  ◀──  ② SYN + ACK (seq=y, ack=x+1) ─────────────── │   "좋아요, 저도 준비됐어요"
       │                                                     │
       │  ③ ACK (ack=y+1) ─────────────────────────────────▶│   "확인, 이제 시작합니다"
       │                                                     │
       ▼                                                     ▼
     연결 수립 완료 (ESTABLISHED) — 이제 실제 데이터를 주고받는다

단계를 하나씩 볼게요. ① 클라이언트가 SYN(Synchronize, "연결하자")을 보내며 자기 시작 번호 x를 알립니다. ② 서버가 SYN + ACK로 답해요. "네 SYN 잘 받았어요(ACK)"와 "저도 연결 준비됐어요(SYN)"를 한 패킷에 합쳐 보내며, 자기 시작 번호 y도 알립니다. ③ 클라이언트가 마지막 ACK로 "네 응답 받았어요" 하면 연결이 섭니다.

여기서 시퀀스 번호(seq)가 등장하는데, 데이터에 순서를 매기는 번호예요. handshake에서 양쪽이 시작 번호를 교환하고, ACK 번호는 "상대 번호 + 1"로 "여기까지 잘 받았어"를 뜻합니다. 이 번호 덕분에 나중에 데이터가 뒤섞여 도착해도 순서를 바로잡을 수 있어요.

왜 하필 세 번일까요? 양쪽이 서로 보내고 받는 능력이 둘 다 정상인지 확인해야 하기 때문이에요. ①로 클라이언트→서버 방향이 되는 걸 확인하고, ②로 서버→클라이언트 방향이 되는 것과 서버가 ①을 받았음을 확인하고, ③으로 클라이언트가 ②를 받았음을 확인합니다. 두 번만 하면 서버는 자기 응답(②)이 클라이언트에 잘 닿았는지 끝내 알 수 없어요. 그래서 두 번으로는 부족하고 세 번이 필요합니다.

🎯 면접에서는 이렇게 답하세요

"3-way handshake는 TCP가 데이터를 보내기 전 연결을 맺는 세 단계입니다. ① 클라이언트가 SYN으로 연결을 요청하고, ② 서버가 SYN+ACK로 '받았고 나도 준비됐다'를 한 번에 답하고, ③ 클라이언트가 ACK로 확인하면 연결이 섭니다. 왜 세 번이냐면, 양방향 통신이 둘 다 가능한지 확인해야 하기 때문입니다. 두 번이면 서버가 자기 응답이 클라이언트에 닿았는지 모르거든요. 세 번째 ACK가 있어야 양쪽 모두 상대의 송신·수신이 정상임을 확신할 수 있습니다. 이때 교환하는 시퀀스 번호로 이후 데이터의 순서도 보장하고요."

Step 7: "4-way handshake — 끝낼 땐 왜 네 번"

연결을 맺을 땐 세 번이었는데, 끝낼 땐 네 번입니다. 이걸 4-way handshake라고 해요. 면접에서 "연결 시작은 3번인데 종료는 왜 4번이냐"를 자주 묻는데, 답은 서버 쪽 사정 때문이에요.

   4-way handshake — 연결을 끝내는 네 번의 인사

   클라이언트(Client)                               서버(Server)
       │                                                    │
       │  ① FIN ──────────────────────────────────────────▶ │   "저는 보낼 거 다 보냈어요"
       │                                                    │
       │  ◀──  ② ACK ─────────────────────────────────────  │   "알겠어요 (저는 아직 남았어요)"
       │                                                    │
       │  ◀──  ③ FIN ─────────────────────────────────────  │   "저도 이제 다 보냈어요"
       │                                                    │
       │  ④ ACK ──────────────────────────────────────────▶ │   "확인, 연결을 끊습니다"
       │                                                    │
       ▼                                                    ▼
     연결 종료 완료 (CLOSED)

① 클라이언트가 FIN("나는 보낼 거 다 보냈어")을 보냅니다. ② 서버가 일단 ACK("알겠어")로 받았다고 답해요. 그런데 여기서 끝이 아닙니다. 서버는 아직 클라이언트에게 보낼 데이터가 남아 있을 수 있거든요. 그래서 ②에서는 받음 확인만 하고, 자기 데이터를 마저 다 보낸 뒤에야 ③ FIN("이제 나도 다 보냈어")을 따로 보냅니다. ④ 클라이언트가 마지막 ACK로 확인하면 연결이 완전히 닫혀요.

이게 시작(3번)과 종료(4번)가 갈리는 이유예요. 시작할 땐 서버가 "받았어(ACK)"와 "나도 준비됐어(SYN)"를 동시에 할 수 있어서 SYN+ACK 한 패킷으로 합쳤습니다. 하지만 종료할 땐 클라이언트가 끝내자고 해도 서버는 보낼 게 남았을 수 있어서, "받았어(ACK)"를 먼저 보내고 자기 일을 마친 뒤 "나도 끝(FIN)"을 따로 보내야 해요. 합칠 수 없으니 하나가 더 늘어 네 번이 됩니다. 한쪽은 끝냈는데 다른 쪽은 아직 보내는, 연결이 절반만 닫힌 상태를 half-close라고 불러요. 참고로 마지막 ACK를 보낸 클라이언트는 잠깐 기다렸다가(TIME_WAIT) 완전히 닫는데, 혹시 그 ACK가 유실돼 서버가 FIN을 다시 보낼 경우에 대비하기 위해서입니다.

🎯 면접에서는 이렇게 답하세요

"연결 종료가 4-way인 이유는 서버의 ACK와 FIN을 하나로 합칠 수 없기 때문입니다. 시작할 때 서버는 '받았다(ACK)'와 '나도 준비됐다(SYN)'를 동시에 할 수 있어 SYN+ACK 한 패킷으로 묶지만, 종료할 땐 클라이언트가 FIN을 보내도 서버는 보낼 데이터가 남아 있을 수 있습니다. 그래서 일단 ACK로 받음만 확인하고, 남은 데이터를 다 보낸 뒤에야 자기 FIN을 따로 보냅니다. 이 ACK와 FIN의 시점이 달라 합칠 수 없으니 단계가 하나 더 늘어 네 번이 됩니다. 한쪽만 닫힌 상태를 half-close라고 합니다."

Step 8: "흐름 제어·혼잡 제어 — TCP가 신뢰성을 지키는 법"

TCP가 신뢰성을 보장한다고 여러 번 말했는데, 빠진 데이터를 재전송하는 것만으로는 부족해요. 데이터를 얼마나 빠르게 보낼지 조절하는 두 가지 장치가 더 있습니다. 흐름 제어와 혼잡 제어인데, 둘 다 일종의 브레이크지만 누구를 위한 브레이크인지가 달라요.

   두 개의 브레이크 — 누구를 위한 속도 조절인가

   흐름 제어 (flow control)    받는 쪽이 넘치지 않게
     보내는 쪽  ──▶  [ 받는 쪽 버퍼 ]
     "나 지금 이만큼 받을 수 있어" 만큼만 보냄  (슬라이딩 윈도우)

   혼잡 제어 (congestion control)    길이 막히지 않게
     보내는 쪽  ──▶  [ 중간 네트워크 ]  ──▶  받는 쪽
     조금씩 시작해 늘리다, 손실이 보이면 확 줄임  (slow start)

흐름 제어는 받는 쪽을 보호합니다. 보내는 쪽이 받는 쪽이 처리할 수 있는 속도보다 빨리 쏟아부으면, 받는 쪽 저장 공간(버퍼)이 넘쳐 데이터가 버려져요. 그래서 받는 쪽이 "나 지금 이만큼 받을 수 있어"(수신 윈도우 크기)를 알려주고, 보내는 쪽은 딱 그만큼만 보냅니다. 이 방식을 슬라이딩 윈도우라고 해요. 물컵에 물을 따를 때 받는 사람이 "그만!" 하고 손짓하면 멈추는 것과 같죠.

혼잡 제어는 네트워크 전체를 보호합니다. 받는 쪽은 멀쩡한데 중간 길(라우터)이 막히면 패킷이 버려져요. 그래서 보내는 쪽이 네트워크 상태를 살피며 전송량을 조절합니다. 처음엔 조금씩만 보내다가 잘 도착하면 점점 늘리고(slow start, 천천히 시작하기), 손실이 감지되면 길이 막혔다는 신호로 보고 전송량을 확 줄여요. 고속도로 진입과 같습니다. 길이 막히면 천천히, 뚫리면 점점 속도를 올리죠.

둘의 차이를 한 줄로 정리하면, 흐름 제어는 1:1 상대(받는 쪽)를 위한 브레이크, 혼잡 제어는 여럿이 함께 쓰는 네트워크(길)를 위한 브레이크예요. 그리고 이 모든 속도 조절을 TCP는 하고 UDP는 하지 않습니다. 이래서 TCP가 무겁고 느린 대신 믿을 만하고, UDP가 가볍고 빠른 대신 못 미더운 거예요. 더 구체적인 알고리즘(혼잡 제어 방식의 종류 등)은 더 깊은 네트워크 과목과 실무의 몫이고, 우리는 "왜 있고 둘이 어떻게 다른가"의 직관까지만 잡습니다.

🎯 면접에서는 이렇게 답하세요

"흐름 제어는 받는 쪽 버퍼가 넘치지 않게 하는 장치입니다. 수신자가 알려준 윈도우 크기만큼만 보내는 슬라이딩 윈도우 방식으로, 1:1 상대를 보호합니다. 혼잡 제어는 중간 네트워크가 막히지 않게 하는 장치고요. 보내는 쪽이 처음엔 조금씩 보내다 늘리고(slow start) 손실이 보이면 급히 줄이는 식으로, 여럿이 공유하는 네트워크 전체를 보호합니다. 한마디로 흐름 제어는 받는 사람을 위한 브레이크, 혼잡 제어는 도로를 위한 브레이크입니다. 둘 다 TCP가 하고 UDP는 하지 않기에, TCP의 신뢰성과 UDP의 속도가 갈립니다."

마무리

오늘 배운 핵심 세 가지

🎯 하나, 여러 컴퓨터가 대화하는 일은 복잡해서 계층으로 나눕니다. 그래야 각 층이 자기 일만 맡고(관심사 분리), 한 층을 바꿔도 나머지는 그대로 두며(교체 자유), 서로 다른 장비끼리도 통신할 수 있어요(표준화). 개념 지도는 OSI 7계층, 실제 인터넷은 TCP/IP 4계층입니다. 데이터는 층을 내려가며 각 층의 헤더를 덧입는 캡슐화를 거쳐 세그먼트→패킷→프레임이 되고, MAC(이웃 장비)·IP(어느 컴퓨터)·포트(어느 프로그램) 세 주소로 길을 찾습니다.

🎯 둘, 전송 계층의 두 프로토콜 TCP와 UDP는 신뢰성과 속도를 맞바꾸는 선택입니다. TCP는 연결을 맺고 재전송·순서 보장으로 믿을 만하지만 느리고(웹·파일·결제), UDP는 연결 없이 그냥 던져 빠르지만 보장이 없습니다(스트리밍·게임·DNS). 신뢰성은 공짜가 아니라 속도를 내주고 얻는 것이고, 실시간 분야에선 '늦게 정확히'보다 '지금 빠르게'가 나을 때가 많다는 게 핵심이에요.

🎯 셋, TCP는 데이터 전에 3-way handshake(SYN → SYN+ACK → ACK)로 연결을 맺습니다. 양방향 통신이 둘 다 되는지 확인하려면 세 번이 필요하죠. 끝낼 땐 서버의 ACK와 FIN을 합칠 수 없어 4-way handshake(FIN → ACK → FIN → ACK)로 한 번 더 주고받습니다. 그리고 받는 쪽 버퍼를 지키는 흐름 제어(슬라이딩 윈도우)와 네트워크를 지키는 혼잡 제어(slow start)로 속도까지 조절해 신뢰성을 완성합니다.

다음 시간 예고

오늘 우리는 네트워크를 계층으로 펼치고, 그 위에서 TCP와 UDP로 데이터를 주고받는 토대를 깔았어요. 다음 시간(C-2)에는 이 토대 위에서 도는 가장 유명한 약속인 HTTP(HyperText Transfer Protocol)를 다룹니다. 여러분이 웹사이트를 열 때마다 브라우저와 서버가 주고받는 그 요청과 응답이요. 어떤 메서드로 요청하는지(GET·POST), 응답에 붙는 상태 코드가 무엇을 뜻하는지(200·404·500), 로그인 상태를 어떻게 기억하는지(쿠키·세션), 그리고 그 통신을 안전하게 암호화하는 HTTPS와 TLS까지 봅니다.

오늘 끝에 흘린 이야기도 다음 시간에 회수해요. "빠르지만 못 믿을 UDP 위에 신뢰성을 다시 얹은 QUIC, 그걸 쓰는 HTTP/3"의 정체 말이에요. HTTP가 1.1에서 2로, 다시 3으로 진화하며 왜 굳이 TCP를 버리고 UDP 위로 옮겨갔는지, 오늘 배운 TCP vs UDP의 트레이드오프가 그 답의 열쇠가 됩니다. 단단히 깔아둔 오늘의 토대 위에서 만나요.

과제

[기초] 좋아요 한 번이 계층을 타고 내려가는 길 그려보기

연필과 종이만 있으면 됩니다. 여러분이 SNS에서 좋아요 버튼을 눌렀다고 합시다. 이 작은 신호가 응용 계층에서 출발해 물리 계층까지 내려가는 과정을 따라가 봅니다.

1. 좋아요 데이터가 전송 → 네트워크 → 데이터링크 계층을 내려갈 때, 각 층에서 데이터를 부르는 이름(세그먼트·패킷·프레임)이 어떻게 바뀌는지 순서대로 적어보세요. 그리고 이 과정 전체를 한 단어로 뭐라고 부르는지도 쓰세요.
2. 위 세 계층에서 각각 어떤 주소(MAC·IP·포트)가 헤더에 담기는지 짝지어 적어보세요. "전송 계층 → ○○ 주소" 형식으로요.
3. OSI 7계층을 아래(물리)부터 위(응용)까지 순서대로 나열하고, 그중 전송 계층과 네트워크 계층이 각각 한 줄로 무슨 일을 하는지 적어보세요.

[응용] 시나리오마다 TCP와 UDP 중 무엇을 고를까

아래 다섯 가지 상황에서 TCP와 UDP 중 무엇이 더 어울리는지 고르고, 그 이유를 신뢰성·순서·속도 중 어디에 무게를 뒀는지로 한 줄씩 설명해보세요.

1. ① 100MB짜리 설치 파일 다운로드 ② 실시간 라이브 방송 시청 ③ 도메인 주소를 IP로 바꾸는 DNS 조회 ④ 1:1 화상 면접 ⑤ 온라인 송금. 각각 TCP/UDP를 고르고 이유를 적으세요.
2. ②번 라이브 방송에서 영상 한 조각이 중간에 빠졌습니다. TCP라면 어떻게 동작하고 그게 왜 시청에 불리한지, UDP라면 어떻게 동작하고 왜 그게 나은지 비교해 설명하세요.
3. ③번 DNS는 보통 UDP를 쓰지만, 응답 데이터가 커지면 TCP로 바꿔 쓰기도 합니다. 왜 평소엔 UDP이고 클 때만 TCP인지, 오늘 배운 두 프로토콜의 성격으로 설명해보세요.

[심화] "시작은 3번, 종료는 4번" 면접 답변과 꼬리 질문 대비하기

조사하고 정리하는 과제입니다.

1. "TCP 연결을 시작할 땐 3번, 끝낼 땐 4번 주고받는데 왜 다른가요?"에 대한 자기만의 답변을, 서버의 ACK와 SYN/FIN을 합칠 수 있느냐 없느냐를 축으로 정리해 적어보세요.
2. 이어질 법한 꼬리 질문에 대비해보세요. "half-close가 무엇인가요?"에 대한 답을, 종료 과정에서 한쪽만 먼저 닫히는 상황으로 두세 문장 준비하세요. 그리고 "마지막 ACK를 보낸 쪽이 바로 닫지 않고 잠깐 기다리는(TIME_WAIT) 이유는요?"에 대한 답도 한두 문장으로 준비하세요.
3. (선택) "3-way handshake에서 두 번만 주고받으면 안 되나요?"라는 질문에, 서버가 자기 응답이 닿았는지 확인할 수 없다는 점을 들어 한두 문장으로 반박해보세요.

생각해볼 주제

1. 신뢰성은 정말 항상 좋은 걸까?

TCP는 빠진 데이터를 반드시 다시 보내고 순서를 끝까지 맞춰줍니다. 안전하게 들리죠. 그런데 화상통화나 실시간 게임에서는 이 '꼼꼼함'이 오히려 독이 됩니다. 0.1초 전 영상 조각을 다시 받겠다고 멈춰 기다리는 사이, 대화는 뚝뚝 끊기니까요. 그렇다면 "데이터를 하나도 잃지 않는 것"이 언제나 최선일까요? '늦더라도 정확히'와 '지금 당장 대충이라도' 사이에서, 무엇을 기준으로 둘 중 하나를 골라야 할지 생각해보세요. 잃어도 되는 데이터와 한 비트도 잃으면 안 되는 데이터를 가르는 선이 어디일지도요.

2. 계층으로 나누면 항상 이득이기만 할까?

계층 구조 덕에 인터넷은 한 층만 바꿔도 나머지가 멀쩡한 유연함을 얻었습니다. 하지만 공짜는 아니에요. 데이터마다 층층이 헤더가 붙어 포장이 무거워지고, 데이터가 여러 층을 오르내리는 과정 자체도 시간을 씁니다. 실제로 최신 프로토콜인 QUIC은 전송과 보안 계층의 경계를 일부러 흐려 속도를 끌어올렸죠. 그렇다면 "깔끔하게 나누는 것"과 "빠르게 동작하는 것"이 부딪칠 때, 우리는 어디까지 계층의 경계를 지키고 어디서부터 무너뜨려야 할까요? 추상화가 주는 유연함과 그것이 숨기는 비용을 함께 저울에 올려 생각해보세요.

3. UDP 위에 신뢰성을 다시 얹는 건 모순 아닐까?

TCP는 신뢰성을 보장하려고 만든 프로토콜이고, UDP는 그걸 포기한 대신 빠른 프로토콜입니다. 그런데 최신 웹은 굳이 못 믿을 UDP 위에 신뢰성을 새로 얹은 QUIC을 씁니다. 이미 TCP가 있는데 왜 TCP를 고치지 않고, 하필 UDP 위에서 다시 만들었을까요? 수십 년간 모두가 쓰며 굳어버린 프로토콜을 바꾸는 일의 어려움과, 차라리 가벼운 토대 위에 새로 짓는 자유로움을 견주어 생각해보세요. 오래된 표준을 개선하는 것과 새 표준을 세우는 것 사이의 트레이드오프가, 기술의 세계에서 어떻게 반복되는지도요.