MTU 최적화 4단계– 현장 엔지니어의 패킷 크기 조정 가이드

서버 본딩(Bonding) 완벽 가이드

몇 년을 굴러다니다 보면 네트워크 문제의 절반은 눈에 보이지 않는 곳에서 온다는 걸 몸으로 배우게 된다. MTU가 딱 그런 놈이다. 수치 하나, 숫자 하나인데 이걸 잘못 잡으면 현장이 조용히 망가진다. 속도도 애매하고, 끊기는 것도 아닌데 뭔가 이상한 그 느낌. 알고 보면 MTU였던 경우가 한두 번이 아니었다.

MTU가 뭔지 현장 언어로 풀어보면

MTU는 Maximum Transmission Unit, 한 번에 보낼 수 있는 패킷의 최대 크기다. 택배 박스에 비유하면 이해하기 쉽다. 트럭 하나에 박스를 몇 개나 실을 수 있냐가 아니라, 박스 하나의 최대 크기가 얼마냐의 문제다. 박스가 너무 크면 문을 못 통과하고(단편화 또는 드롭), 너무 작으면 왕복 횟수가 늘어나서 시간이 걸린다(오버헤드 증가). 이더넷 기본 MTU는 1500바이트다.

왜 1500바이트냐?
이더넷 표준에서 정해진 기본값이다. 기가비트, 10기가비트 환경에서도 기본값은 여전히 1500이다. 점보 프레임(Jumbo Frame)을 사용하면 9000바이트까지 늘릴 수 있지만, 경로 전체 장비가 지원해야 한다.

✅ 최적화 장점

단편화를 줄이고 헤더 오버헤드 비율을 낮춘다. 실질 처리량이 올라간다. VPN이나 터널 환경에서 효과가 특히 두드러진다.

⚠️ 주의사항

환경마다 적정값이 다르다. 혼합 환경(이더넷+PPPoE+VPN)에서 수치 하나를 잘못 건드리면 통신이 아예 안 될 수 있다. 섣불리 건드리면 독이 된다.

VPN 터널 위에서 파일을 전송하는 환경에서 속도가 이상하게 느렸다. ping은 살아있고, 파일 전송만 하면 중간에 뚝뚝 끊기는 느낌이었다. Wireshark를 열어보니 패킷 단편화가 끊임없이 일어나고 있었다. VPN 헤더가 붙으면서 실질적인 payload 공간이 줄었는데 MTU는 그대로 1500으로 설정돼 있었던 거다. 줄자로 재지 않고 큰 박스를 억지로 밀어넣다가 박스가 찌그러지는 꼴이었다. MTU 조정 하나로 파일 전송이 안정화됐다.

STEP 01

현재 MTU 확인하기

일단 지금 뭐로 설정되어 있는지 봐야 한다. 모르고 건드리는 건 지도 없이 산에 들어가는 것과 같다. 설정값 확인이 모든 작업의 출발점이다.

# 리눅스: 인터페이스 MTU 확인
ip link show eth0
# mtu 1500 으로 표시되면 기본값 사용 중

# Windows: 서브인터페이스 MTU 확인
netsh interface ipv4 show subinterfaces

# 모든 인터페이스 한 번에 확인 (리눅스)
ip link show | grep mtu

처음 이 명령어를 쳤을 때 1500이 아닌 값이 나왔을 때의 당혹감이 아직도 기억난다. 1476이었다. 누군가 예전에 바꿔놓고 인수인계를 안 한 거였다. 그 값이 왜 설정됐는지 이유를 모르는 채로 수개월 동안 운영이 됐던 것이다. 현장에서 제일 무서운 게 이런 경우다. 누군가 건드린 흔적은 있는데 이유를 모르는 상황. 그래서 새 서버를 인수받을 때는 항상 MTU 확인을 기본 체크리스트에 넣는다. 이상한 값이 나왔다면 변경 이력을 먼저 찾는 게 순서다.

Path MTU Discovery로 적정값 찾기

내 쪽 MTU만 바꾼다고 되는 게 아니다. 경로 전체에서 병목이 되는 지점의 MTU를 맞춰야 한다. 이걸 Path MTU Discovery라고 한다. 목적지까지 가는 길에서 제일 좁은 문이 어디냐를 찾는 과정이다. 가장 좁은 문 기준으로 박스 크기를 맞춰야 안 막힌다.

# 단편화 금지(-M do) + payload 1472바이트 ping
# 1472 + IP헤더 20 + ICMP헤더 8 = 1500(기본 MTU)
ping -c 4 -M do -s 1472 8.8.8.8

# 실패하면 숫자를 줄여가며 탐색
ping -c 4 -M do -s 1400 8.8.8.8
ping -c 4 -M do -s 1350 8.8.8.8
ping -c 4 -M do -s 1300 8.8.8.8

실제 MTU = 통과하는 최대 payload 크기 + 28 (IP헤더 20 + ICMP헤더 8)

이진 탐색처럼 줄여가면서 딱 통하는 최대 payload 크기를 찾고, 거기에 28을 더하면 실제 MTU 값이다. VPN 환경이라면 보통 1400~1450 사이에서 통과 여부가 갈린다.

# 스크립트로 자동 탐색 (bash)
#!/bin/bash
TARGET="8.8.8.8"
for SIZE in 1472 1450 1430 1400 1350 1300 1200; do
  if ping -c 2 -M do -s $SIZE $TARGET &>/dev/null; then
    echo "최대 payload 크기: $SIZE → MTU: $((SIZE + 28))"
    break
  else
    echo "$SIZE 바이트: 실패"
  fi
done

이 탐색을 수동으로 처음 했을 때 숫자를 하나씩 바꿔가며 치는 게 너무 번거로워서 스크립트로 만들었다. 현장에서 반복 작업은 자동화가 답이다. VPN 환경 5개를 같은 날 점검할 일이 있었는데, 스크립트 덕분에 각 환경당 30초도 안 걸렸다. 처음에 수동으로 했다면 한 환경당 5분은 걸렸을 작업이다. 작은 자동화가 하루의 생산성을 바꾼다.

MTU 값 변경 적용하기

적정값을 찾았으면 이제 적용이다. 즉시 적용과 영구 적용 두 가지를 구분해서 처리해야 한다. 즉시 적용만 하면 재부팅 시 원래대로 돌아간다.

# 리눅스 즉시 적용 (재부팅 시 초기화됨)
ip link set dev eth0 mtu 1400

# Ubuntu/Debian netplan 영구 적용
# /etc/netplan/01-netcfg.yaml 수정
network:
  ethernets:
    eth0:
      mtu: 1400
  version: 2

# netplan 적용
netplan apply

# 적용 확인
ip link show eth0

# RHEL/CentOS nmcli 영구 적용
nmcli con mod "System eth0" ethernet.mtu 1400
nmcli con up "System eth0"

# Windows Server 영구 적용
netsh interface ipv4 set subinterface "이더넷" \
  mtu=1400 store=persistent

✅ 적용 후 확인 필수

ip link show eth0로 mtu 값이 변경됐는지 반드시 확인한다. 적용 명령이 성공했어도 실제로 바뀌었는지 눈으로 확인하는 게 원칙이다.

⚠️ 원격 작업 주의

원격 SSH로 작업할 때 MTU 변경이 연결을 끊을 수 있다. 반드시 콘솔 접근(iDRAC, iLO, 시리얼)을 확보한 뒤 작업해야 한다.

원격 서버에서 MTU 값을 변경하다가 SSH 연결이 끊긴 적이 있다. MTU가 낮아지면서 기존 TCP 세션의 패킷이 경로에서 드롭됐던 거였다. iDRAC 콘솔을 미리 열어두지 않았다면 그 서버에는 재부팅 전까지 접근이 불가능했을 것이다. 다행히 iDRAC을 열어둬서 콘솔로 들어가서 수습할 수 있었다. 그날 이후로 MTU 작업 전에 "콘솔 백도어 확보"가 첫 번째 체크리스트가 됐다. 원격 작업에서 잘리면 복구가 제일 힘들다.

적용 후 검증하고 모니터링하기

바꿨다고 끝이 아니다. 실제로 나아졌는지 확인해야 한다. 단편화가 줄었는지 Wireshark로 보고, 처리량이 개선됐는지 iperf3으로 측정한다. 수치로 확인되지 않은 개선은 개선이 아니다.

# iperf3 서버 (수신 측)
iperf3 -s

# iperf3 클라이언트 (30초 테스트)
iperf3 -c 서버IP -t 30

# Wireshark 단편화 패킷 필터
ip.flags.mf == 1 || ip.frag_offset > 0

# 커맨드라인에서 단편화 패킷 통계 확인
netstat -s | grep -i fragment

# 리눅스 IP 통계에서 단편화 확인
cat /proc/net/snmp | grep -i frag

검증 기준: Wireshark에서 ip.flags.mf == 1 필터로 걸리는 패킷이 현저히 줄어들면 MTU 최적화가 제대로 된 것이다. iperf3 Bandwidth 수치가 이전보다 올라갔는지도 함께 확인한다.

MTU를 1500에서 1400으로 조정한 뒤 Wireshark로 확인했을 때, 단편화 패킷이 눈에 띄게 줄어드는 걸 보면서 묘한 쾌감이 있었다. 숫자 하나 바꿨는데 그래프가 달라지는 그 느낌. iperf3 수치도 올라갔다. 이후 네트워크 장비가 교체되면서 환경이 바뀌었고, 6개월 뒤에 다시 성능 저하 증상이 나타났다. 새 장비의 MTU가 달랐던 거였다. 한 번 세팅하고 영원히 잊으면 언젠가 원인 모를 성능 저하로 돌아온다. MTU는 환경이 바뀔 때마다 재점검해야 한다.

마무리 생각

MTU라는 주제를 처음 접했을 때는 그냥 수치 하나 조정하는 거 아닌가 싶었다. 실제로 현장에서 이것 때문에 반나절 넘게 원인을 못 찾고 헤맨 경험이 있고 나서야 비로소 만만한 게 아니라는 걸 알았다.

네트워크는 보이지 않는 곳에서 조용히 어긋나고, 그 어긋남의 원인이 패킷 크기 설정 하나일 수 있다는 게 아이러니하면서도 재미있다. 박스 크기 하나 맞추는 문제인데 그 파급력이 생각보다 훨씬 크다. 현장은 항상 디테일에서 갈린다.

출처 및 참고

• RFC 791 - Internet Protocol (IP Fragmentation): https://www.rfc-editor.org/rfc/rfc791
• RFC 1191 - Path MTU Discovery: https://www.rfc-editor.org/rfc/rfc1191
• Linux ip command man page: https://man7.org/linux/man-pages/man8/ip.8.html