293. PMTU (Path MTU Discovery)

핵심 인사이트 (3줄 요약)

본질: PMTU는 네트워크 계층과 IP에서 핵심 동작과 제약을 이해하게 해 주는 개념이다.

가치: PMTU를 이해하면 주소 효율과 도달성 사이의 균형을 더 정확히 볼 수 있다.

판단 포인트: 설계 시에는 개념 자체보다 적용 조건, 운영 복잡도, 인접 기술과의 경계를 함께 판단해야 한다.

Ⅰ. 개요 및 필요성

개념: 출발지 호스트와 목적지 호스트 사이의 전체 라우팅 경로 중, 가장 작은 MTU 값을 알아내는 프로토콜 및 매커니즘 (RFC 1191).
필요성: 내 PC와 공유기는 MTU가 1500이다. 미국 구글 서버도 1500이다. 그런데 태평양 해저를 건너는 중간 라우터 하나가 구형이라 MTU가 1400이라고 치자. 내가 1500으로 던지면 중간 라우터가 땀을 뻘뻘 흘리며 패킷을 1400과 100으로 찢는다. 전 세계 수천만 명이 패킷을 던지는데 라우터가 일일이 찢고 있으면 CPU가 터져 인터넷이 마비된다. "라우터 고생시키지 말고, 내 PC에서 보낼 때 아예 1400으로 미리 맞춰서 보내면 어떨까?"라는 착한 배려심에서 출발했다.
💡 비유: 서울에서 부산까지 화물차를 몰고 가는데, 중간에 **"높이 제한 3m"**짜리 오래된 굴다리가 있습니다. 4m짜리 화물을 싣고 출발했다가 굴다리 앞에서 짐을 끄집어내려 쪼개고 있으면(단편화) 뒤차들이 다 밀립니다. PMTU는 출발 전 굴다리 높이를 미리 알아보고, 처음부터 서울에서 짐을 3m 규격으로 맞춰서 화물차 2대에 나눠 싣고 출발하는 똑똑한 운송 전술입니다.

[패킷 캡슐화, MTU]
    │
    ▼
[PMTU]
    │
    └──▶ [TTL]

📢 섹션 요약 비유: ** PMTU Discovery는 동굴 탐험대가 사람이 통과할 수 있는 가장 좁은 구멍의 크기를 미리 레이저(DF 패킷)로 쏴서 측정한 뒤, 가방 크기를 그 구멍에 딱 맞게 줄여 매고 들어가는 치밀한 사전 탐사 작업입니다.

Ⅱ. 아키텍처 및 핵심 원리

1. 탐색 프로세스 (Trial and Error)

현재 거의 모든 OS(윈도우, 리눅스)는 기본적으로 PMTU 알고리즘을 켜놓고 통신을 시작한다.

송신 (DF=1): PC가 1500바이트 패킷 헤더에 DF(Don't Fragment) = 1을 세팅해서 쏜다.
병목 조우: 가다가 MTU가 1400인 라우터 R2를 만난다. 라우터는 찢어야 하는데 DF 딱지를 보고 "찢지 말라네? 그럼 버린다!"라며 패킷을 쓰레기통에 폐기(Drop)한다.
에러 반송 (ICMP): R2는 PC에게 ICMP 메시지(Type 3, Code 4: Fragmentation Needed but DF set)를 반송하며, 친절하게 "Next-Hop MTU is 1400"이라고 좁은 문의 크기를 알려준다.
크기 조절: PC는 ICMP를 받고 "아! 1400이 한계구나" 깨닫고, 패킷을 1400바이트로 줄여서 DF=1을 붙여 다시 쏜다. 목적지까지 거절당하지 않고 도달하면, 1400을 Path MTU로 확정 짓고 계속 그 크기로 통신한다.

 ┌─────────────────────────────────────────────────────────────┐
 │                PMTU Discovery 메커니즘 (ICMP 핑퐁)             │
 ├─────────────────────────────────────────────────────────────┤
 │                                                             │
 │   [ 내 PC ] ── 1500B (DF=1) ──▶ [ R1 (1500) ] ──▶ [ R2 (1400) ] │
 │                                                          │  │
 │   "에잇 1500으로 줄여!" ◀──── ICMP Error (MTU 1400) ───────┘  │
 │   (PC가 패킷 크기 조절)                                          │
 │                                                             │
 │   [ 내 PC ] ── 1400B (DF=1) ──▶ [ R1 (1500) ] ──▶ [ R2 (1400) ] │
 │                                                       통과! │
 │                                                          ▼  │
 │                                                 [ 구글 서버 ] │
 │                                                             │
 └─────────────────────────────────────────────────────────────┘

2. 치명적 오류: PMTU 블랙홀 (Black Hole) 현상

PMTU는 중간 라우터가 돌려보내 주는 ICMP 에러 메시지에 100% 의존한다. 그런데 회사의 보안 방화벽 장비들이 "ICMP는 해커들이 핑(Ping) 때릴 때 쓰는 위험한 프로토콜이다!"라며 무조건 차단(Drop)해 버리는 경우가 많다.

라우터 R2는 1500바이트 패킷을 버리고 ICMP를 쏘았는데, 방화벽이 이걸 막아버렸다.
내 PC는 ICMP 에러를 못 받았으니 "왜 대답이 없지?"라며 1500바이트 패킷을 영원히 계속 쏜다.
영원히 버려진다. 접속이 안 되고 뱅글뱅글 무한 로딩만 돈다. 이 끔찍한 단절 현상을 PMTU 블랙홀이라고 부른다.
해결책: 방화벽에서 ICMP Type 3 Code 4 메시지만큼은 예외로 허용(Allow)해 주거나, 중간 라우터에서 아예 TCP 헤더의 MSS 값을 강제로 변조해 버리는 꼼수(MSS Clamping)를 쓴다.
📢 섹션 요약 비유: ** PMTU는 앞차(ICMP)가 좁은 길을 만나면 클락션을 울려 뒤차에게 알려주는 훌륭한 시스템이지만, 방음벽(방화벽) 때문에 클락션 소리가 막혀버리면 뒤차들이 좁은 길에 계속 들이박고 터져 죽는(블랙홀) 치명적 맹점을 가지고 있습니다.

Ⅲ. 비교 및 연결

PMTU를 볼 때는 앞뒤 개념과의 경계를 함께 봐야 전체 흐름이 선명해진다. 패킷 캡슐화, MTU가 기반 조건을 만든다면, PMTU는 그 위에서 핵심 메커니즘을 구현하고, TTL는 이를 더 확장된 적용 단계로 연결한다. 따라서 단일 정의보다 주소 효율과 도달성에 어떤 차이를 만드는지 비교하는 것이 중요하다.

관점	선행 개념	현재 개념	확장 개념
초점	패킷 캡슐화, MTU의 기반 정리	PMTU의 핵심 동작	TTL의 확장 적용
자원 관점	기본 조건 확보	주소 효율 최적화	규모와 범위 확대
판단 포인트	도입 가능성 확인	현재 메커니즘의 적합성 판단	운영·확장 전략 연결

📢 섹션 요약 비유: PMTU는 비슷한 기술들 사이의 차선을 구분하는 분기점과 같다. 어디서 갈라지는지 알아야 헷갈리지 않는다.

Ⅳ. 실무 적용 및 기술사 판단

실무에서는 PMTU를 단독 개념으로 외우기보다 어떤 병목을 줄이기 위한 선택인지 먼저 따져야 한다. 특히 패킷 캡슐화, MTU 수준의 기본 대책으로 충분한지, 아니면 PMTU가 제공하는 메커니즘이 실제로 필요한지 구분해야 한다. 이후 확장 단계에서는 TTL와 같은 후속 기술, 자동화 체계, 표준 호환성까지 함께 검토해야 한다.

실무 체크리스트

현재 문제의 핵심이 주소 효율 부족인지, 도달성 악화인지 먼저 분리한다.
PMTU가 추가하는 복잡도와 운영 이득이 균형을 이루는지 확인한다.
도입 후에는 인접 기술인 TTL와의 연계 방식을 함께 검증한다.

안티패턴

PMTU의 장점만 보고 트래픽 패턴이나 운영 비용을 무시한 채 과도 도입하는 설계
패킷 캡슐화, MTU와의 경계를 정리하지 않아 중복 투자나 정책 충돌을 만드는 설계
📢 섹션 요약 비유: PMTU를 실제로 쓰는 판단은 도구 상자를 고르는 일과 비슷하다. 좋아 보이는 도구보다 지금 문제에 맞는 도구가 중요하다.

Ⅴ. 기대효과 및 결론

PMTU는 네트워크 계층과 IP를 이해할 때 핵심 축을 잡아 주는 개념이다. 올바르게 적용하면 주소 효율 개선과 구조적 단순화에 기여하지만, 조건을 잘못 잡으면 오히려 복잡도와 운영 부담이 커질 수 있다. 앞으로는 TTL, 대규모 주소 자동화, 자동화 운영과의 결합을 통해 더 정교하게 발전할 가능성이 크다. 따라서 이 개념은 정의 자체보다 “언제 쓰고 언제 다른 방법으로 넘길 것인가”의 관점으로 기억하는 것이 좋다. 향후에는 대규모 주소 자동화 같은 자동화 흐름과 결합되어 더 정교한 형태로 확장될 가능성이 크다.

📢 섹션 요약 비유: PMTU는 큰 흐름 속에서 기억해야 오래 남는다. 지금의 장점과 다음 확장 방향을 같이 보면 전체 그림이 선명해진다.

📌 관련 개념 맵

개념	연결 포인트
패킷 캡슐화, MTU	현재 개념이 등장하기 전에 갖춰야 할 배경이나 인접 선행 개념이다.
IP 주소 (Internet Protocol Address)	종단 위치를 논리적으로 식별한다.
서브넷 (Subnet)	주소 공간을 쪼개 관리 단위를 만든다.
TTL	현재 개념이 확장되거나 적용 단계로 이어질 때 자주 함께 언급된다.

📈 관련 키워드 및 발전 흐름도

[선행 개념: 패킷 캡슐화, MTU]
    │
    ▼
[현재 개념: PMTU]
    │
    ├──▶ [확장 A: TTL]
    └──▶ [확장 B: 대규모 주소 자동화]

PMTU는 패킷 캡슐화, MTU에서 출발해 현재 메커니즘을 정교화하고, 이후 TTL와 대규모 주소 자동화 같은 확장 흐름으로 이어진다고 보면 기억이 오래간다.

👶 어린이를 위한 3줄 비유 설명

택배를 보내려면 집 주소가 정확해야 길을 잃지 않아요.
이 개념은 인터넷 세상에서 주소를 정하고 다음 길을 찾는 지도와 같아요.
그래서 멀리 있는 친구 컴퓨터까지도 편지가 도착할 수 있어요.