[Network] 27. 편지 한 통의 여정을 혼자 설명할 수 있을까?

목차: [Network] TCP/IP를 우편 시스템으로 이해하기
TCP/IP를 우편 시스템으로 이해하기 — 에필로그. 우리는 인터넷이 아니라 물류 시스템을 이해했다

ㅁ 들어가며

Browser의 주소창에 URL 하나를 입력했다.

https://server.example/orders

잠시 뒤 주문 목록이 화면에 나타났다.

우리는 흔히 이 짧은 사건을 이렇게 말한다.

Client가 Server에 접속했다.

 

그러나 그 한 문장 안에서는 수많은 결정이 일어났다.

• 이름을 어느 IP 주소로 바꿀지 정했다.
• 목적지가 같은 동네인지 다른 동네인지 판단했다.
• 다음 전달자의 MAC 주소를 알아냈다.
• Switch와 Router가 각자의 표를 보고 다음 길을 골랐다.
• 사설 주소를 공인 주소와 Port의 조합으로 바꾸었다.
• 상대와 연결을 만들고, 암호화할 상대가 맞는지 확인했다.
• 사라진 Data를 다시 보내고, 받는 쪽과 길의 형편에 맞춰 속도를 조절했다.
• 돌아온 응답을 원래 요청한 Process와 Browser Tab에 전달했다.

이 가운데 어느 하나만 빠져도 화면에는 그저 timeout이나 연결 오류가 나타날 수 있다.

 

그렇다면 지금까지 배운 용어를 외우지 않고도, 이 편지 한 통의 여정을 처음부터 끝까지 자기 언어로 설명할 수 있을까?

이번 글에서는 새로운 Protocol을 배우지 않는다.

지금까지 흩어져 있던 DNS, ARP, Switch, Routing, TTL, MTU, NAT, Firewall, TCP, TLS, HTTP를 하나의 시간 순서로 다시 잇는다.

 

이 연재의 마지막 질문은 무엇이 동작했는가가 아니다.

각 기술이 왜 그 자리에 있어야 했는가다.

---

ㅁ 한 통의 편지를 끝까지 따라가기 위한 약속

하나의 흐름을 놓치지 않도록 다음 환경을 사용한다.

역할	값
Client	192.168.10.20
Client가 선택한 Source Port	51514
DNS Resolver	192.168.10.53
Default Gateway	192.168.10.1
NAT 장비의 공인 IP	203.0.113.5
NAT가 바꾼 Source Port	40001
Web Server	198.51.100.20
Web Service Port	443/TCP
URL	https://server.example/orders

 

192.168.10.0/24는 사설 주소 대역이고,

198.51.100.0/24와 203.0.113.0/24는 문서 예시를 위해 예약된 주소 대역이다.

실제 인터넷 Service를 뜻하지 않는다.

 

설명을 단순하게 만들기 위해 IPv4를 중심으로 따라간다.

IPv6에서는 Broadcast 기반 ARP 대신 ICMPv6의 Neighbor Discovery Protocol,

  즉 NDP가 이웃과 Router를 찾고,

  일반적으로 IPv4 주소 공유를 위한 NAT와는 다른 방식으로 주소를 사용한다.

 

또 하나 기억할 점이 있다.

Application은 처음부터 완성된 "편지 한 통"을 Network에 던지지 않는다.

각 계층은 자기 역할에 필요한 Header를 붙이고, 반대편은 이를 차례로 해석한다.

HTTP Message
  ↓ TLS로 보호
TLS Record
  ↓ TCP가 순서와 신뢰성 정보 추가
TCP Segment
  ↓ IP가 출발지와 최종 목적지 정보 추가
IP Packet
  ↓ Ethernet이 현재 Link의 전달자 정보 추가
Ethernet Frame
  ↓
Bit와 Signal

 

우편 비유의 편지는 하나처럼 보이지만,

  실제 Network에는 계층별 Header와 여러 Packet이 있다.

DNS Query, ARP Request, TCP Handshake, TLS Handshake까지 포함하면

HTTP Request 하나를 보내기 전에도 이미 여러 번의 통신이 오간다.

---

ㅁ 1단계: Browser는 URL에서 먼저 무엇을 꺼낼까?

Browser가 받은 것은 IP 주소가 아니라 URL이다.

https://server.example/orders

 

Browser는 이 문자열을 적어도 다음 요소로 나눈다.

URL 요소	값	의미
Scheme	https	어떤 방식으로 통신할지
Host	server.example	어느 Host를 찾을지
Port	생략됨, 기본값 443	어느 Service와 대화할지
Path	/orders	Service 안의 어느 Resource를 요청할지

 

우편 주소로 보면 나라와 도시, 건물, 부서를 나누는 일과 비슷하다.

 

하지만 실제 기술에서 이 값들은 서로 다른 계층의 결정에 쓰인다.

• Host 이름은 DNS 조회의 입력이 된다.
• 443은 TCP Destination Port가 된다.
• /orders는 TCP 연결이 만들어지고 TLS가 준비된 뒤 HTTP Request에 담긴다.

즉 /orders를 Router가 보고 길을 고르는 것이 아니다.

Router는 일반적으로 URL Path를 알지 못하며 IP Header를 중심으로 전달을 결정한다.

첫 번째로 필요한 것은 server.example이라는 이름을 숫자 주소로 바꾸는 일이다.

---

ㅁ 2단계: 이름은 어떻게 198.51.100.20이 될까?

사람은 이름을 기억하기 쉽지만, IP 계층은 Destination IP 주소가 있어야 Packet을 보낼 수 있다.

그래서 Host는 먼저 가까운 기억을 확인한다.

Browser DNS Cache
    ↓ 없으면
Operating System Cache와 Hosts 설정
    ↓ 없으면
설정된 DNS Resolver

 

Cache에 유효한 Answer가 없다면 Client는 설정된 Resolver 192.168.10.53에 질문한다.

server.example의 A Record는 무엇입니까?

 

Resolver는 자신의 Cache를 확인하고, 필요하다면 DNS 계층을 따라 권한 있는 Name Server의 Answer를 찾아 다음과 같이 돌려준다.

server.example.  300  IN  A  198.51.100.20

 

여기서 300은 이 Answer를 무조건 영원히 기억하라는 뜻이 아니다.

TTL 300초 동안 Cache할 수 있다는 뜻이다. DNS의 TTL은 IP Header의 TTL과 이름은 같지만 역할이 다르다.

같은 이름	실제 역할
DNS TTL	Record를 Cache할 수 있는 시간
IP TTL	Packet이 통과할 수 있는 Router 수의 한계

 

A Record는 IPv4 주소를, AAAA Record는 IPv6 주소를 제공한다.

여러 주소가 돌아오면 Client는 주소 Family, 도달 가능성, 정책과 구현에 따라 연결 후보와 시도 순서를 정할 수 있다.

DNS는 공용 주소록과 닮았지만, 종이 주소록처럼 단순한 한 권의 책은 아니다.

분산된 권한과 Cache로 규모를 감당하는 이름 체계다.

그리고 DNS Query 자체도 Network Packet이다.

Resolver가 같은 Subnet에 있다면 곧 살펴볼 Route 판단과 ARP가 DNS Query를 보낼 때도 먼저 필요하다.

 

여정은 완전히 일직선인 목록이 아니라, 작은 여정이 큰 여정 안에 중첩된 구조다.

이 단계가 해결한 문제는 사람이 숫자 주소를 모두 기억하지 않고도 목적지를 찾는 확장성이다.

---

ㅁ 3단계: 목적지를 알았으면 어느 문으로 내보낼까?

이제 Operating System은 목적지 198.51.100.20을 안다.

하지만 IP 주소만 안다고 바로 Signal을 보낼 수 있는 것은 아니다. 먼저 자신의 Routing Table을 조회해야 한다.

간단한 Table이 다음과 같다고 해 보자.

192.168.10.0/24 dev eth0  src 192.168.10.20
default via 192.168.10.1 dev eth0

Operating System은 Destination과 가장 길게 일치하는 Prefix를 고른다.

이것이 Longest Prefix Match, 최장 접두사 일치다.

198.51.100.20은 192.168.10.0/24에 속하지 않는다.

더 구체적인 Route도 없으므로 default Route가 선택된다.

 

그 결과는 다음과 같다.

Source IP    192.168.10.20
Destination  198.51.100.20
Egress       eth0
Next Hop     192.168.10.1

 

여기서 중요한 구분이 생긴다.

• 최종 목적지 IP는 198.51.100.20이다.
• 지금 Link에서 건넬 상대는 Gateway 192.168.10.1이다.

먼 지역으로 가는 편지에도 봉투에는 최종 수신인의 주소를 쓴다.

다만 집 앞에서는 그 편지를 가까운 우체국에 맡긴다.

Default Gateway는 모든 목적지를 직접 아는 마법의 장비가 아니다.

더 구체적인 Route가 없을 때 선택한 다음 전달자다.

이 단계가 해결한 문제는 모든 Host가 인터넷의 모든 길을 기억하지 않고도 먼 목적지로 출발할 수 있게 하는 확장성이다.

---

ㅁ 4단계: Gateway의 IP만 알면 Frame을 보낼 수 있을까?

Ethernet Link에서 Frame을 보내려면 Destination MAC 주소가 필요하다.

Client는 자신의 Neighbor Table에서 192.168.10.1에 대응하는 MAC 주소를 찾는다.

유효한 항목이 없다면 ARP Request를 Broadcast한다.

누가 192.168.10.1을 사용하고 있습니까?
192.168.10.20에게 알려 주십시오.

 

같은 Broadcast Domain의 장비들은 Request를 받을 수 있지만, 192.168.10.1을 가진 Gateway가 Reply한다.

192.168.10.1은 02:00:00:00:10:01입니다.

 

Client는 이 대응 관계를 Neighbor Table에 일정 시간 저장한다.

192.168.10.1 → 02:00:00:00:10:01

이제 첫 Ethernet Frame의 주소를 채울 수 있다.

Header	출발지	목적지
Ethernet	Client MAC	Gateway MAC
IPv4	192.168.10.20	198.51.100.20
TCP	51514	443

 

Client는 먼 Server의 MAC 주소를 ARP로 묻지 않는다.

ARP는 같은 L2 범위에서 지금 직접 건넬 이웃을 찾기 때문이다.

우편 비유에서 ARP는 같은 동네의 실제 집을 찾는 주소 조회와 비슷하다.

그러나 실제 ARP는 사람의 이름을 IP로 바꾸는 DNS가 아니라,

같은 Link에서 Next-Hop IPv4 주소를 MAC 주소에 대응시키는 Protocol이다.

이 단계가 해결한 문제는 논리적 IP 목적지를 실제 Local Link 전달에 필요한 주소와 연결하는 일이다.

---

ㅁ 5단계: Switch는 Server까지의 길을 알고 있을까?

Client가 Frame을 내보내면 Switch가 받는다.

Switch는 Frame의 Source MAC을 보고 다음 사실을 학습한다.

Client MAC은 이 Port 뒤에 있다.

 

그리고 Destination MAC, 즉 Gateway MAC을 MAC Address Table에서 조회한다.

• Entry가 있으면 해당 Port로 전달한다.
• Entry가 없으면 같은 VLAN의 다른 Port로 Unknown Unicast Flooding한다.
• Broadcast인 ARP Request는 같은 VLAN의 Broadcast Domain에 Flooding한다.

Switch는 198.51.100.20으로 가는 인터넷 Route를 고르는 장비가 아니다.

이 시점의 Switch가 관심을 갖는 주소는 현재 Ethernet Frame의 Destination MAC이다.

 

VLAN이 있다면 하나의 물리 Switch도 여러 Broadcast Domain으로 나뉜다.

서로 다른 VLAN 사이의 통신에는 L3 Routing이 필요하다.

 

또한 이중화 Link가 Layer 2에서 원을 만들면 Broadcast와 Unknown Unicast가 끝없이 복제될 수 있다.

STP 계열 Protocol은 일부 Link를 논리적으로 차단해 Loop 없는 전달 구조를 만든다.

Switch, VLAN, STP가 함께 해결한 문제는

하나의 가까운 길을 많은 장비가 공유하면서도 Frame을 필요한 방향으로 보내고 Loop를 막는 일이다.

---

ㅁ 6단계: Router는 봉투를 그대로 다음 우체국에 넘길까?

Gateway는 자신의 MAC 주소로 온 Frame을 받고 Ethernet Header를 벗겨 IP Packet을 확인한다.

Destination IP는 여전히 198.51.100.20이다.

Router는 자신의 Routing Table에서 다시 Longest Prefix Match를 수행해 다음 Hop과 Egress Interface를 선택한다.

이때 Router는 IP TTL을 1 줄인다.

TTL 64 → TTL 63

IPv4 Header가 바뀌었으므로 Header Checksum도 다시 계산한다.

TTL이 0이 되면 Router는 Packet을 폐기하고, 일반적으로 출발지에 ICMP Time Exceeded 메시지를 보낸다.

이것은 잘못된 Route가 원을 그릴 때 Packet이 Network 자원을 영원히 소비하지 않게 하는 안전장치다.

다음 Link로 내보낼 때 Router는 이전 Ethernet Frame을 그대로 재사용하지 않는다.

 

다음 Hop의 MAC 주소를 ARP로 확인한 뒤 새 Ethernet Header를 만든다.

첫 번째 Link
Client MAC → Gateway LAN MAC

두 번째 Link
Gateway WAN MAC → ISP Next-Hop MAC

우편 봉투를 통째로 새 봉투에 넣는다고 상상할 수 있지만, 비유의 경계를 분명히 해야 한다.

실제로는 각 L2 Link에 맞는 Frame Header가 매 Hop 새로 만들어지고, 그 안의 IP Packet은 Route를 따라 전달된다.

Router가 해결한 문제는 각 장비가 전체 경로가 아니라 다음 길만 골라도 멀리 확장할 수 있게 하는 일이다.

---

ㅁ 7단계: 소포가 다음 길보다 크다면 어떻게 될까?

Route가 있다고 모든 크기의 Packet이 그대로 지나갈 수 있는 것은 아니다.

각 Link에는 한 Frame이 실을 수 있는 IP Packet 크기의 한계인 MTU가 있다.

Ethernet에서 흔히 보는 값은 1500 bytes지만, Tunnel이나 다른 Link를 지나면 더 작을 수 있다.

IPv4 Packet이 Egress MTU보다 크면 조건에 따라 다음 중 하나가 일어난다.

• Fragmentation이 허용되면 Router 또는 출발지가 Packet을 여러 Fragment로 나눈다.
• DF, Don't Fragment가 설정되어 있으면 Router는 Packet을 버리고 ICMP Fragmentation Needed를 보낸다.

출발지는 이 정보를 이용해 경로에서 통과 가능한 크기를 알아내고 Packet 크기를 조절할 수 있다.

이것이 Path MTU Discovery, PMTUD다.

 

TCP는 보통 Interface MTU와 협상한 MSS를 고려해 Segment의 Payload 크기를 정한다.

MSS는 TCP Payload의 최대 크기에 관한 값이고, MTU는 Link가 실을 수 있는 IP Packet 전체 크기에 관한 값이다.

ICMP가 무조건 불필요한 Traffic이라며 중간에서 사라지면 작은 Request는 성공하지만

큰 TLS Record나 Response만 멈추는 PMTUD Black Hole이 생길 수 있다.

이 단계가 해결하려는 문제는 서로 다른 크기의 길을 지나는 동안 자원을 낭비하지 않고 전달 가능한 크기를 찾는 효율이다.

---

ㅁ 8단계: 사설 주소는 인터넷에서 어떻게 돌아올 주소가 될까?

Client의 Source IP 192.168.10.20은 사설 주소다.

Public Internet의 Router가 이 주소를 전 세계의 고유 목적지로 전달하지 않는다.

경계의 NAT 장비는 Packet이 밖으로 나갈 때 Source를 바꾼다.

변환 전
192.168.10.20:51514 → 198.51.100.20:443

변환 후
203.0.113.5:40001 → 198.51.100.20:443

주소뿐 아니라 Port까지 바꾸어 여러 내부 연결을 구분하는 동작을 흔히 NAPT 또는 PAT라고 부른다.

일상적으로는 이를 포함해 NAT라고 말하는 경우가 많다.

 

NAT 장비는 다음과 같은 Mapping State를 기억한다.

TCP 203.0.113.5:40001 ↔ 192.168.10.20:51514
Remote Peer: 198.51.100.20:443

IP 주소나 TCP Port가 바뀌면 해당 값을 포함해 계산한 Checksum도 맞게 갱신해야 한다.

Server의 Reply는 다음 주소로 돌아온다.

198.51.100.20:443 → 203.0.113.5:40001

 

NAT 장비는 저장한 State를 찾아 Destination을 원래 Client로 되돌린다.

198.51.100.20:443 → 192.168.10.20:51514

NAT는 여러 집이 하나의 공인 주소를 함께 쓰게 해 IPv4 주소 부족을 견디는 데 큰 역할을 했다. 이것은 공유의 해법이다.

그러나 NAT가 보안을 자동으로 완성하는 것은 아니다. State에 없는 외부 연결이 안쪽으로 들어오기 어려운 현상과 명시적인 Security Policy는 구분해야 한다.

또한 NAT가 있는 구간에서는 IP 주소와 Port가 End-to-End로 완전히 동일하게 유지되지 않는다. 장애를 분석할 때 안쪽 Capture와 바깥쪽 Capture의 5-Tuple이 달라지는 이유다.

---

ㅁ 9단계: Firewall은 주소만 보고 문을 열까?

경계에는 NAT와 별개로 Firewall Policy가 적용될 수 있다.

기본적인 Rule은 다음 정보를 기준으로 허용하거나 차단할 수 있다.

• Source와 Destination IP
• Protocol
• Source와 Destination Port
• Ingress와 Egress Interface 또는 Zone
• 연결 상태

Stateful Firewall은 TCP Packet 하나만 고립해서 보지 않고,

이 Packet이 새 연결을 시작하는지 이미 허용된 연결의 일부인지 추적한다.

Linux 환경에서는 이 상태 추적을 Conntrack과 연결해 관찰할 수 있다.

NEW → ESTABLISHED → FIN/종료 또는 Timeout

 

우편 보안실이 발신지와 수신 부서, 현재 진행 중인 방문인지 확인하는 모습과 닮았다.

하지만 Firewall이 443/TCP를 허용했다는 사실은 다음을 보장하지 않는다.

• Server Process가 실제로 Listen 중인지
• TLS Certificate가 올바른지
• HTTP 요청 권한이 있는지
• 응답이 정상인지

Firewall은 통신을 허용할지 결정한다.

TLS는 상대와 내용의 신뢰를 다루고, Application 인증은 사용자가 무엇을 할 수 있는지 결정한다.

서로 다른 문이다.

---

ㅁ 10단계: TCP는 왜 Data부터 보내지 않을까?

Route와 Policy를 통과할 수 있게 되었지만, Client는 곧바로 HTTP Request부터 보내지 않는다.

Server의 443/TCP와 신뢰성 있는 Byte Stream을 만들기 위해 TCP Three-Way Handshake를 수행한다.

설명을 위해 Client의 초기 Sequence Number를 1000, Server의 초기 Sequence Number를 7000이라고 하자.

Client → Server  SYN      Seq=1000
Server → Client  SYN-ACK  Seq=7000 Ack=1001
Client → Server  ACK      Seq=1001 Ack=7001

세 번의 교환에는 각각 이유가 있다.

1. Client가 Server에 도달할 수 있고 연결 의사가 있음을 알린다.
2. Server가 Client의 요청을 받았고, 반대 방향으로도 도달할 수 있음을 알린다.
3. Client가 Server의 응답까지 받았음을 확인한다.

SYN과 FIN은 Sequence Number 공간에서 1을 소비한다. 그래서 SYN Seq=1000에 대한 확인은 Ack=1001이다.

TCP 연결은 단순히 "두 IP가 연결되었다"고만 구분하지 않는다. 일반적으로 다음 5-Tuple로 흐름을 식별한다.

Protocol, Source IP, Source Port, Destination IP, Destination Port

 

NAT 안쪽에서 보면 다음 흐름이다.

TCP, 192.168.10.20, 51514, 198.51.100.20, 443

NAT 바깥에서는 다음처럼 보인다.

TCP, 203.0.113.5, 40001, 198.51.100.20, 443

Port 덕분에 한 Host의 여러 Process와 여러 연결이 같은 IP 주소를 함께 쓸 수 있다.

이것도 제한된 주소와 경로를 함께 쓰는 공유의 장치다.

---

ㅁ 11단계: Handshake 뒤에는 무엇이 신뢰를 만들까?

TCP Handshake가 끝났다고 이후 Data가 사라지지 않는 것은 아니다.

IP Network는 Packet의 전달, 순서와 중복 제거를 완전히 보장하지 않는다.

TCP는 여러 약속을 조합해 Application에 순서 있는 Byte Stream을 제공한다.

 

ㅇ Sequence Number

각 Byte의 위치를 나타낸다. Segment가 순서가 바뀌어 도착해도 어느 자리에 놓을지 판단할 수 있다.

 

ㅇ Acknowledgment

수신자가 다음에 기대하는 Byte를 알린다. Ack=2501은 일반적으로 2500까지 연속해서 받았고 다음은 2501이라는 뜻이다.

ㅇ Retransmission

ACK가 정해진 시간 안에 오지 않거나 중복 ACK 같은 손실 단서가 생기면 필요한 Data를 다시 보낸다.

 

ㅇ Receive Window와 Flow Control

수신자가 감당할 수 있는 Buffer 범위를 광고한다. 빠른 Sender가 느린 Receiver를 압도하지 않게 한다.

 

ㅇ Congestion Control

Network 길 자체가 감당할 수 있는 양을 추정해 전송량을 조절한다.

Receiver의 여유와 Network의 여유는 다른 문제다.

 

실제 전송 가능량은 대략 다음 두 한계 가운데 더 작은 쪽의 영향을 받는다.

min(Receiver Window, Congestion Window)

TCP의 신뢰성은 Packet 하나에 붙은 특별한 도장 하나가 아니다.

순서 번호, ACK, Timer, 재전송, 흐름 제어와 혼잡 제어가 함께 만든 결과다.

이 단계가 해결한 문제는 손실과 지연이 있는 공유 길 위에서도 대화를 이어 가는 신뢰와 효율이다.

---

ㅁ 12단계: TCP 연결이 되면 상대를 믿어도 될까?

아직 아니다.

TCP 연결 성공은 198.51.100.20:443까지 Byte를 주고받을 수 있다는 뜻이다.

그 상대가 정말 server.example인지, 중간 누군가가 내용을 읽거나 바꾸지 않았는지는 말해 주지 않는다.

 

HTTPS에서는 TCP 위에서 TLS Handshake가 이어진다.

TLS 1.3의 세부 Message와 선택 사항은 상황에 따라 달라지지만, 큰 흐름은 다음과 같다.

ClientHello
  - 지원하는 TLS Version과 Cipher Suite
  - Key Share
  - SNI: server.example

ServerHello와 Server 인증 정보
  - 선택한 Parameter
  - Key Share
  - Certificate Chain
  - Certificate로 증명한 서명

양쪽의 Finished 검증
  - Handshake가 변조되지 않았는지 확인

 

Client는 Certificate를 받을 뿐 아니라 다음을 검증해야 한다.

• 신뢰하는 CA로 이어지는 Chain인가?
• Certificate의 유효 기간 안인가?
• 접속한 Host 이름 server.example과 일치하는가?
• 필요한 사용 목적과 정책을 만족하는가?

그리고 Key Exchange 결과로 공유한 Secret에서 Traffic Key를 만들어 이후 TLS Record를 암호화하고 무결성을 보호한다.

우편 비유로는 봉투를 잠그고 수신인의 신분증을 확인하는 일과 닮았다.

그러나 실제 TLS는 모든 중간 Router를 신뢰해서 내용을 맡기는 방식이 아니다.

Endpoint끼리 암호학적으로 상대와 Message를 검증한다.

 

SNI나 IP·Port 같은 일부 Metadata는 구성과 TLS Version, 추가 보호 기술에 따라 여전히 관찰될 수 있다.

암호화는 Packet의 존재와 모든 Header를 사라지게 하지 않는다.

이 단계가 해결하는 문제는 믿을 수 없는 중간 경로에서도 상대와 내용에 대한 신뢰를 만드는 일이다.

---

ㅁ 13단계: 드디어 HTTP Request가 출발한다

TCP와 TLS가 준비된 뒤에야 Browser는 보호된 연결 안으로 HTTP 의미를 보낸다.

개념적으로는 다음과 같은 Request다.

GET /orders HTTP/1.1
Host: server.example
Accept: application/json

실제 Service는 HTTP/2나 HTTP/3를 사용할 수도 있다.

이 예시는 지금까지 따라온 TCP와 TLS의 연결을 분명하게 보기 위해 TCP 기반 HTTPS 흐름으로 단순화했다.

HTTP/3는 TCP 대신 QUIC을 UDP 위에서 사용하므로 Transport의 세부 여정이 달라진다.

Server 쪽에서는 역순으로 계층을 해석한다.

NIC가 Frame 수신
→ IP가 Local Destination 확인
→ TCP가 443 Port의 Socket과 연결 식별
→ TLS가 Record 복호화와 무결성 검증
→ HTTP Server가 Method, Host, Path 해석
→ Application이 주문 목록 처리

 

Server가 Request를 받았다는 사실과 업무가 성공했다는 사실도 다르다.

• TCP ACK는 Byte 수신을 확인한다.
• TLS는 보호된 Record의 무결성을 확인한다.
• HTTP Status는 Request 처리 결과를 표현한다.
• 업무 Transaction과 Log는 Application 내부 결과를 보여준다.

예를 들어 HTTP 500은 Network 연결 실패가 아니라, Network와 TLS를 지나 Application이 오류 응답을 돌려준 증거다.

Server는 처리 결과를 HTTP Response로 만들고 TLS로 보호한 뒤 TCP Byte Stream에 실어 보낸다.

HTTP/1.1 200 OK
Content-Type: application/json

[{"orderId": 42, "status": "ready"}]

---

ㅁ 14단계: 응답은 왔던 길을 그대로 되돌아올까?

반드시 그렇지는 않다.

Internet Routing은 방향마다 독립적으로 결정될 수 있다.

요청이 A → B → C를 지났더라도 응답이 C → D → A로 돌아올 수 있다. 이를 Asymmetric Routing, 비대칭 경로라고 한다.

 

Server의 Reply는 Server 쪽 Routing Table부터 다시 조회한다.

NAT 바깥에서 Reply의 주소는 다음과 같다.

198.51.100.20:443 → 203.0.113.5:40001

 

경계 NAT 장비에 도착하면 기존 Mapping에 따라 다음처럼 복원된다.

198.51.100.20:443 → 192.168.10.20:51514

 

그 뒤 내부 Route와 Neighbor Table을 사용해 Client에 전달한다.

Stateful Firewall이나 NAT가 연결 상태를 기억한다면 Reply가 그 State를 볼 수 있는 경로로 돌아와야 한다.

비대칭 경로 자체는 IP Routing에서 가능하지만,

한 방향의 상태만 아는 장비를 우회하거나 다른 장비로 들어오면 정상 Reply도 새롭거나 알 수 없는 Traffic으로 판단될 수 있다.

 

Client에 도착한 TCP Segment는 5-Tuple과 Socket 상태를 바탕으로 원래 연결에 Demultiplexing된다.

TCP는 Sequence Number를 보고 Byte를 순서대로 조립하고, TLS는 Record를 검증해 복호화한다.

Browser는 HTTP Response를 원래 요청과 연결해 화면을 갱신한다.

 

돌아오는 길은 단순한 후일담이 아니다.

요청이 목적지에 도착했는데도 사용자가 실패를 보는 이유는 응답 Route, NAT State, Firewall Policy와 Client Socket까지 모두 이어져야 하기 때문이다.

---

ㅁ 한눈에 보면 무엇이 바뀌고 무엇이 남을까?

Packet을 분석할 때 모든 주소가 처음부터 끝까지 그대로라고 생각하면 NAT와 Router의 동작을 혼동한다.

반대로 Router가 모든 주소를 바꾼다고 생각해도 틀린다.

정보	일반적인 변화	이유
Ethernet Source/Destination MAC	L2 Link를 지날 때마다 바뀜	현재 Link의 Sender와 Next Hop을 가리킴
IP Source/Destination	Router를 지나도 보통 유지	최종 Endpoint를 표현함
IP Source/Destination의 예외	NAT 구간에서 변환될 수 있음	주소 공유 또는 주소 영역 연결
IP TTL	Router마다 1씩 감소	무한 Routing Loop 방지
IPv4 Header Checksum	TTL이나 주소가 바뀌면 갱신	변경된 Header의 오류 검출
TCP Source/Destination Port	보통 연결 동안 유지	Endpoint의 Socket과 Service 식별
TCP Port의 예외	NAPT에서 변환될 수 있음	하나의 공인 IP에서 연결 구분
TCP Sequence/Acknowledgment	Data 교환에 따라 계속 진행	Byte의 순서와 수신 범위 표현
TLS Application Payload	중간 구간에서 암호문으로 보임	내용의 기밀성과 무결성 보호

 

예시의 첫 Link에서는 다음과 같다.

Ethernet  Client MAC → Gateway MAC
IP        192.168.10.20 → 198.51.100.20, TTL=64
TCP       51514 → 443

 

NAT 바깥쪽 Link에서는 다음과 같이 보일 수 있다.

Ethernet  NAT WAN MAC → ISP Next-Hop MAC
IP        203.0.113.5 → 198.51.100.20, TTL=63
TCP       40001 → 443

 

Server 근처의 마지막 Link에서는 MAC 주소가 다시 달라지고 TTL은 더 줄어든다.

NAT가 추가로 없다면 IP와 TCP의 변환된 값은 유지된다.

Ethernet  Last Router MAC → Server MAC
IP        203.0.113.5 → 198.51.100.20, TTL=여러 Hop만큼 감소
TCP       40001 → 443

이 구분만 명확해도 Capture 지점에 따라 같은 연결이 왜 다른 모습으로 보이는지 설명할 수 있다.

---

ㅁ 우편 비유를 실제 용어로 되돌려 놓기

비유는 출발점이지 기술 정의가 아니다.

마지막에는 각 장면을 실제 용어로 다시 말할 수 있어야 한다.

우편 이야기	실제 핵심 용어	정확한 역할
이름을 숫자 주소로 찾는 주소록	DNS, A, AAAA, Resolver, Cache TTL	Domain Name을 IP 주소 정보로 해석
같은 동네인지 판단	Subnet Mask, Prefix, Routing Table	Destination과 Route Prefix를 비교
가까운 우체국에 맡김	Default Gateway, Next Hop	직접 연결되지 않은 목적지의 다음 L3 전달자
같은 동네의 실제 집 찾기	ARP, Neighbor Table, IPv6 NDP	Next-Hop IP와 Link-Layer 주소 연결
동네 안의 분류소	Switch, MAC Address Table	L2 Frame을 적절한 Port로 전달
동네 경계 나누기	VLAN, Broadcast Domain	하나의 L2 기반을 논리적으로 분리
순환 도로 일부를 닫기	STP	L2 Loop와 Frame 증폭 방지
지역 간 중계소	Router, Routing Table, Longest Prefix Match	Destination Prefix에 맞는 Next Hop 선택
최대 중계 횟수	IP TTL, Hop Limit	Routing Loop의 자원 낭비 제한
좁은 길에 맞는 소포 크기	MTU, MSS, PMTUD, ICMP	경로가 전달 가능한 Packet 크기 조절
한 공인 주소를 여러 집이 사용	NAT, NAPT/PAT, Mapping	IPv4 주소와 Port를 변환하고 연결 State 유지
출입 정책을 확인하는 보안실	Firewall, Stateful Inspection, Conntrack	정해진 통신 Policy와 연결 상태 적용
건물 안의 담당 창구	Port, Socket, Demultiplexing	한 Host의 올바른 Process와 연결 식별
접수와 수령 확인	TCP SYN, ACK, Sequence Number	연결 의사와 Byte 수신 범위 확인
분실물 재발송	Retransmission, RTO, Duplicate ACK	손실로 추정한 Data를 다시 전송
수신 창고의 남은 공간	Receive Window, Flow Control	Receiver 처리 능력에 Sender 속도 조절
도로 전체의 혼잡	Congestion Window, Congestion Control	Network가 감당할 수 있는 전송량 추정
봉인을 하고 수신인을 확인	TLS, Certificate, Hostname Verification, Traffic Key	상대 인증과 Data 기밀성·무결성 보호
편지 안의 업무 요청	HTTP Method, Host, Path, Status	Application 요청과 처리 결과 표현

 

우편 비유로 설명한 뒤 이 표의 오른쪽 문장으로 돌아올 수 있다면, 비유가 개념을 가린 것이 아니라 이해를 도운 것이다.

---

ㅁ 화면에 timeout 하나만 보인다면 어디부터 볼까?

같은 오류 문구도 멈춘 단계는 다를 수 있다. 그래서 도구부터 고르는 대신 여정의 순서대로 질문한다.

단계	먼저 물을 질문	남을 수 있는 증거와 도구
Local Link	Interface가 올라와 있고 주소가 있는가?	ip link, ip addr, Interface Counter
이름	Host 이름은 어떤 주소와 RCODE를 받는가?	dig, Resolver Log, DNS Cache
Route	어떤 Source, Interface, Next Hop이 선택되는가?	ip route get
Neighbor	Next Hop의 MAC을 알아냈는가?	ip neigh, ARP/NDP Capture
L2 전달	Frame이 올바른 VLAN과 Port로 가는가?	Switch MAC Table, VLAN/STP 상태, tcpdump -e
L3 경로	Packet이 어느 구간까지 가는가?	ping, traceroute, Router Route와 Counter
MTU	작은 Data는 되고 큰 Data만 멈추는가?	tracepath, 크기를 바꾼 ping, ICMP Capture
NAT/Firewall	변환 State와 허용 Rule에 일치하는가?	NAT/Conntrack Table, Rule Counter와 Log
TCP Port	SYN과 SYN-ACK가 오가는가?	nc, ss, tcpdump의 TCP Flag
TLS	Certificate와 Hostname 검증이 성공하는가?	openssl s_client, TLS Alert, Server Log
HTTP/Application	어떤 Status와 처리 결과가 돌아오는가?	curl -v, Access/Error Log, Trace와 Metric

 

관찰 결과의 의미도 넘겨짚지 않아야 한다.

 

ㅇ dig가 성공했다

이름을 주소로 바꿨다는 뜻이다. 해당 Web Port가 열려 있거나 Application이 정상이라는 뜻은 아니다.

 

ㅇ ping이 실패했다

ICMP Echo Reply를 받지 못했다는 뜻이다. 정책상 ICMP만 차단했을 수 있으므로 HTTPS도 실패했다고 단정할 수 없다.

 

ㅇ traceroute에 *가 보인다

해당 Probe의 응답을 받지 못했다는 뜻이다. 그 Router가 모든 Transit Traffic을 버렸다는 직접 증거는 아니다.

 

ㅇ SYN은 나가는데 SYN-ACK가 없다

Client가 응답을 받지 못했다는 뜻이다. SYN의 전방 손실, Server/Port 문제, SYN-ACK의 역방향 손실 가운데 어디인지 한 지점의 Capture만으로 구분할 수 없다.

 

ㅇ TCP Handshake가 성공했다

Transport 연결이 되었다는 뜻이다. TLS 검증이나 HTTP 업무 성공은 아직 별개의 단계다.

 

ㅇ Server NIC에서 Request가 보인다

Frame 또는 Packet이 Capture 지점까지 왔다는 뜻이다. Process가 read()했고 업무 Transaction을 완료했다는 뜻은 아니므로 Socket과 Application Log를 함께 봐야 한다.

 

진단은 "무엇이 고장 났을까?"라는 추측 대회가 아니다.

마지막으로 확인된 정상 사건과 처음 사라진 실패 사건 사이로 범위를 줄이는 일이다.

---

ㅁ 직접 관찰하기: URL 한 번의 여정 기록표 만들기

새로운 복잡한 Lab을 만들지 않아도 한 번의 접속을 단계별로 관찰할 수 있다.

자신이 관리하거나 점검 허가를 받은 HTTPS Host를 하나 선택한다.

 

아래 명령은 Linux 기준이며 운영체제에 따라 Option과 출력 형식이 다를 수 있다.

 

먼저 변수에 Host 이름을 넣는다.

HOST=your-authorized-host.example

 

ㅇ 1. DNS Answer를 기록한다

dig "$HOST" A
dig "$HOST" AAAA

 

status, ANSWER SECTION, Record Type과 DNS TTL을 적는다.

여러 IP가 있다면 이번에 관찰할 IPv4 주소 하나를 선택한다.

IP=$(dig +short A "$HOST" | awk '/^[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+$/ { print; exit }')
printf 'selected_ip=%s\n' "$IP"

빈 값이라면 다음 단계로 넘어가지 말고 DNS Answer와 입력한 Host부터 확인한다.

 

ㅇ 2. Kernel의 Route 결정을 묻는다

ip route get "$IP"

출력에서 다음 값을 기록한다.

• 선택한 Source IP
• Egress Interface
• via가 있다면 Next Hop
• 일치한 Route에 관한 정보

문서에 적힌 Route를 추측하지 말고 실제 Kernel이 내린 결정을 기준으로 삼는다.

 

ㅇ 3. Neighbor State를 확인한다

먼 Host라면 Neighbor는 Server IP가 아니라 Route가 선택한 Gateway다.

ip neigh show

Gateway 항목의 MAC 주소와 REACHABLE, STALE, DELAY, INCOMPLETE, FAILED 같은 State를 확인한다. Entry가 없으면 실제 Traffic을 한 번 발생시킨 뒤 다시 비교할 수 있다.

 

ㅇ 4. TCP와 TLS를 분리해 확인한다

TCP Port 도달 여부를 먼저 살펴본다.

nc -vz -w 3 "$HOST" 443

그다음 TLS에서 SNI와 Hostname 검증을 명시한다.

openssl s_client \
  -connect "$HOST:443" \
  -servername "$HOST" \
  -verify_hostname "$HOST" \
  -brief </dev/null

TCP 성공과 Certificate 검증 성공을 한 칸에 뭉뚱그리지 않고 따로 기록한다.

 

ㅇ 5. HTTP 결과를 확인한다

curl -v --connect-timeout 5 "https://$HOST/" -o /dev/null

Verbose 출력에는 DNS 후보, 연결한 IP와 Port, TLS 정보, HTTP Status 같은 단서가 나타날 수 있다. Version과 Build Option에 따라 표현은 달라질 수 있다.

 

ㅇ 6. 필요한 범위에서 Packet을 함께 본다

자신에게 Capture 권한이 있는 Host와 Interface에서만 수행한다.

인증 정보와 개인정보가 포함될 수 있으므로 수집 범위를 최소화한다.

sudo tcpdump -ni any "host $IP and tcp port 443"

다른 Terminal에서 curl을 한 번 실행하고 Capture를 종료한다. 다음 사건이 실제로 보이는지 확인한다.

SYN → SYN-ACK → ACK
TLS Handshake Data
Application Data
FIN 또는 다른 종료 방식

TLS가 적용되었다면 HTTP Path와 Body가 평문으로 보이지 않는 것이 정상이다. 또한 any Capture와 NIC Offload 때문에 중복처럼 보이는 Packet, Wire와 다른 크기, 잘못된 것처럼 보이는 Checksum이 나타날 수 있다.

 

ㅇ 7. 자기 언어로 한 문단을 완성한다

다음 빈칸을 실제 관찰값으로 채운다.

나는 ______라는 이름을 DNS Resolver ______에 물어 ______를 받았다.
Kernel은 Source ______, Interface ______, Next Hop ______를 선택했다.
Local Link에서는 Next Hop의 MAC ______를 사용했다.
TCP는 Local Port ______에서 Remote Port 443으로 Handshake를 만들었다.
TLS는 Hostname ______와 Certificate Chain을 검증했다.
HTTP는 Status ______를 돌려주었다.
내가 직접 확인하지 못한 중간 단계는 ______이며, 이를 단정하지 않는다.

마지막 문장이 특히 중요하다.

Client 한 대의 명령으로 ISP Router의 NAT Table이나 Server Process 내부 처리를 직접 보았다고 말할 수는 없다.

관찰한 사실, 다른 증거로 추론한 내용, 아직 모르는 영역을 나누는 것이 Network를 정확히 설명하는 방법이다.

---

ㅁ 네 가지 질문으로 다시 보면 기술은 따로 떨어져 있지 않다

긴 여정을 용어 목록으로 다시 흩뜨리지 않으려면 각 기술이 해결한 제약을 묻는다.

 

ㅇ 공유: 제한된 것을 어떻게 함께 쓸까?

• Switch는 하나의 L2 기반을 여러 장비가 함께 사용하게 한다.
• Port는 하나의 IP 주소에서 여러 Process와 연결을 구분한다.
• NAT/NAPT는 하나의 공인 IPv4 주소를 여러 내부 연결이 함께 쓰게 한다.

 

ㅇ 확장: 모두가 모든 것을 알지 않고도 어떻게 커질까?

• VLAN과 Subnet은 가까운 전달 범위를 나눈다.
• Default Gateway와 Routing은 각 Node가 다음 길 중심으로 판단하게 한다.
• DNS는 분산된 권한과 Cache로 이름 체계를 확장한다.

 

ㅇ 효율: 한정된 길과 처리 능력을 어떻게 낭비하지 않을까?

• Switch의 학습은 불필요한 Flooding을 줄인다.
• TTL은 Loop Packet이 자원을 영원히 소비하지 않게 한다.
• MTU, MSS와 PMTUD는 경로에 맞는 크기를 찾는다.
• TCP Flow Control과 Congestion Control은 Receiver와 Network 상태에 맞춰 속도를 조절한다.

 

ㅇ 신뢰: 손실과 믿을 수 없는 길에서도 어떻게 대화할까?

• TCP의 Sequence, ACK와 Retransmission은 순서 있는 Byte Stream을 만든다.
• Firewall은 허용한 통신의 경계를 세운다.
• TLS는 상대를 검증하고 내용의 기밀성과 무결성을 보호한다.
• 계층별 관찰과 Log는 문제가 생겼을 때 추측을 증거로 바꾼다.

새로운 Network 기술을 만났을 때도 이름부터 외울 필요는 없다.

먼저 물으면 된다.

이 기술은 무엇을 함께 쓰게 하는가?

어디까지 확장하기 위해 생겼는가?

어떤 낭비를 줄이는가?

누구와 무엇을 신뢰하게 만드는가?

---

ㅁ 이제 혼자 설명할 수 있을까?

처음의 URL로 돌아가 보자.

https://server.example/orders

이제 "Client가 Server에 접속했다"라는 한 문장을 더 정확하게 펼칠 수 있다.

1. Browser는 URL에서 Scheme, Host, Port와 Path를 구분했다.
2. DNS Cache와 Resolver를 통해 Host 이름의 A 또는 AAAA 주소를 얻었다.
3. Kernel은 Routing Table에서 Longest Prefix Match로 Source, Interface와 Next Hop을 골랐다.
4. 같은 Link의 Next Hop MAC을 ARP 또는 NDP와 Neighbor Table로 알아냈다.
5. Switch는 MAC Table과 VLAN 범위 안에서 Frame을 Gateway 방향으로 전달했다.
6. Router들은 Destination Prefix에 맞는 다음 Hop을 선택하고 TTL을 줄이며 새 L2 Frame을 만들었다.
7. 출발지는 MTU와 PMTUD의 단서를 바탕으로 경로가 감당할 크기에 맞췄다.
8. 경계 NAT/NAPT는 사설 Source IP와 Port를 공인 IP와 Port로 Mapping했다.
9. Firewall은 주소, Port, 방향과 연결 상태를 Policy에 따라 판단했다.
10. TCP는 5-Tuple로 연결을 구분하고 Three-Way Handshake를 만들었다.
11. Sequence, ACK, 재전송, Flow Control과 Congestion Control이 Byte Stream의 신뢰와 효율을 지켰다.
12. TLS는 Certificate와 Hostname을 검증하고 이후 Data를 암호화해 보호했다.
13. HTTP Server와 Application이 /orders를 처리해 Status와 Body를 만들었다.
14. 응답은 독립적인 Return Route를 따라와 NAT State를 거쳐 원래 Socket과 Browser 요청에 전달되었다.

그리고 문제가 생겼다면 이렇게 말할 수 있다.

DNS Answer까지는 확인했다.
Route와 Neighbor도 정상이다.
Client의 SYN은 Router Ingress에서 보이지만 Egress에서는 보이지 않는다.
따라서 Server가 죽었다고 단정하지 않고, 두 Capture 지점 사이의 Forwarding,
Firewall Rule과 Counter를 확인하겠다.

이 문장에는 모든 장비의 모든 정보를 안다는 허세가 없다.

대신 어디까지 확인했고, 어느 구간이 아직 설명되지 않았으며, 다음에 어떤 증거를 볼지가 있다.

그것이 이 연재에서 만들고 싶었던 Network 이해다.

---

ㅁ 핵심 정리

• URL 접속은 DNS, Route 선택, Neighbor 확인, L2 전달, Routing, NAT, TCP, TLS와 HTTP가 시간 순서로 이어진 결과다.
• DNS Query 자체도 Route와 ARP/NDP가 필요한 작은 Packet Journey이며, 단계들은 상황에 따라 Cache되거나 중첩된다.
• Destination이 다른 Subnet이면 Host는 최종 Server IP를 유지한 채 Ethernet Frame을 Default Gateway MAC으로 보낸다.
• Switch는 현재 L2 Frame의 MAC을 보고, Router는 IP Destination의 Longest Prefix Match로 다음 Hop을 고른다.
• Ethernet MAC 주소는 Link마다 바뀌고, IP 주소는 보통 End-to-End로 유지되지만 NAT에서 바뀔 수 있으며 TTL은 Router마다 감소한다.
• NAPT는 공인 IP와 Port의 Mapping State를 기억해 Reply를 원래 사설 Client 연결로 돌려보낸다.
• Firewall의 통신 허용, TLS의 상대·내용 보호, Application의 사용자 권한은 서로 다른 문제다.
• TCP 신뢰성은 Handshake 하나가 아니라 Sequence, ACK, Timer, 재전송, Flow Control과 Congestion Control의 조합이다.
• MTU와 PMTUD가 깨지면 작은 통신은 되는데 큰 Data만 멈출 수 있다.
• Request Route와 Return Route는 다를 수 있으며, Stateful 장비가 있다면 Reply가 필요한 State를 만날 수 있어야 한다.
• TCP ACK, TLS 성공, HTTP Status와 업무 Transaction은 각각 다른 단계의 성공을 뜻한다.
• 진단은 마지막으로 확인한 정상 사건과 처음 사라진 기대 사건 사이를 Route, Capture, Counter와 Log로 좁히는 일이다.
• 하나의 관찰 지점에서 보이지 않았다는 사실을 Network 전체에 존재하지 않았다는 뜻으로 확대하지 않는다.
• 새 기술은 공유, 확장, 효율, 신뢰 가운데 어떤 제약을 해결하려는지 물을 때 기존 기술과 연결된다.

핵심 용어: URL, DNS, A, AAAA, Resolver, DNS Cache, Subnet, Routing Table, Longest Prefix Match, Default Gateway, Next Hop, ARP, NDP, Neighbor Table, Ethernet Frame, MAC Address Table, VLAN, STP, Router, TTL, MTU, MSS, PMTUD, ICMP, NAT, NAPT, PAT, 5-Tuple, Firewall, Stateful Inspection, Conntrack, TCP Three-Way Handshake, Sequence Number, Acknowledgment, Retransmission, Receive Window, Congestion Window, TLS, Certificate, Hostname Verification, HTTP, Asymmetric Routing, Socket, Demultiplexing, Evidence-Based Troubleshooting

인터넷은 편지를 한 번에 목적지로 보내는 거대한 장치가 아니다.
제한된 길과 주소를 함께 쓰면서,
각 지점이 자신이 맡은 작은 결정을 이어 붙여 결과적으로 한 통의 편지를 도착시키는 물류 시스템이다.

---

ㅁ 연재를 마치며

처음에는 ARP, Switch, Router, TTL, NAT, DNS와 TCP가 서로 떨어진 용어처럼 보였다.

이제는 하나가 빠질 때 다음 질문이 생긴다.

• DNS가 주소를 알려 주어도 누가 같은 Link의 Next Hop을 찾을까?
• ARP가 Gateway MAC을 알려 주어도 누가 먼 지역의 다음 길을 고를까?
• Route가 있어도 주소가 부족하면 여러 사용자가 어떻게 Public Internet을 함께 쓸까?
• Packet이 도착해도 손실과 순서 뒤바뀜 속에서 어떻게 대화를 이어 갈까?
• TCP가 Byte를 전달해도 믿을 수 없는 중간 길에서 상대와 내용을 어떻게 지킬까?
• 모든 계층을 거쳤어도 업무가 실패하면 어느 증거부터 거꾸로 따라갈까?

기술은 앞선 기술이 틀려서 생긴 것이 아니다.

더 많은 사람이

  길을 공유하고,

  더 먼 곳까지 확장하고,

  한정된 자원을 효율적으로 쓰며,

  불완전한 길 위에서도 신뢰를

만들기 위해 필요한 선택이 하나씩 더해졌다.

 

이제 Packet을 볼 때 Header의 숫자만 보지 않았으면 한다.

그 숫자가 어떤 문제를 해결하기 위해 그 자리에 놓였는지,

왜 그 다음 길을 선택했는지, 어디에서 처음 기대한 사건이 사라졌는지를 이야기할 수 있다면 충분하다.

우리는 인터넷의 용어를 모두 외운 것이 아니다.

 

편지 한 통이 목적지까지 가는 이유를 이해했다.