네트워크 공부를 처음 시작하면 "인터넷이 안 된다"는 상황을 마주쳤을 때 무엇부터 해야 할지 막막합니다. 그때 가장 먼저 꺼내 드는 도구가 바로 Ping과 Traceroute입니다. 이 두 도구는 모두 ICMP(Internet Control Message Protocol)를 기반으로 동작하며, 네트워크 엔지니어가 매일 사용하는 기본 진단 명령어입니다.
1. ICMP란 무엇인가? – 네트워크의 "신호등" 역할
ICMP는 인터넷 프로토콜(IP) 계층에서 동작하는 제어 메시지 프로토콜입니다. 쉽게 말하면, 택배 기사님이 집 문 앞에 도착했을 때 "아무도 없음"이라는 쪽지를 남기는 것처럼, 네트워크 장비들이 서로 "이 패킷 전달이 안 됩니다", "목적지가 없습니다" 같은 상태 메시지를 주고받을 때 사용하는 프로토콜입니다. 데이터를 직접 전달하지는 않고, 네트워크 상태를 알려주는 역할만 합니다.
ICMP는 RFC 792에 정의되어 있으며, 주요 메시지 유형은 다음과 같습니다.
- Echo Request / Echo Reply (Type 8 / Type 0) → Ping이 바로 이것을 사용합니다.
- Destination Unreachable (Type 3) → 목적지에 도달할 수 없을 때
- Time Exceeded (Type 11) → TTL이 0이 되었을 때 → Traceroute가 이것을 활용합니다.
- Redirect (Type 5) → 더 좋은 경로를 알려줄 때
처음 ICMP를 공부할 때 "왜 이게 필요하지?"라고 생각했는데, 실제 현장에서 장애가 발생했을 때 ICMP 메시지 하나가 문제 원인을 수십 분 안에 찾아주는 경험을 하고 나서 그 중요성을 깨달았습니다. 한번은 사무실 인터넷이 갑자기 느려졌는데, Ping 결과에서 "Destination Unreachable" 메시지가 반복되는 것을 보고 라우터 설정 문제라는 것을 바로 파악한 적이 있습니다. ICMP가 없었다면 원인을 찾는 데 훨씬 오랜 시간이 걸렸을 것입니다. 다만 ICMP는 보안 측면에서 양날의 검이기도 합니다. 공격자들이 ICMP를 이용해 네트워크 구조를 탐색(ICMP Sweep)하거나 서비스 거부 공격(Ping Flood)을 하는 사례가 있어서, 많은 방화벽이 ICMP를 아예 차단하기도 합니다. 이렇게 되면 진단 도구 자체를 못 쓰게 되는데, 이는 보안과 운영 편의성 사이의 균형 문제입니다. ICMP를 무조건 차단하기보다는 Rate Limiting 등으로 관리하는 것이 더 현명한 접근이라고 생각합니다.
# ICMP 메시지 타입 확인 예시 (Wireshark 캡처 요약)
Frame 1: ICMP Echo Request (Type 8, Code 0)
Source: 192.168.1.10
Destination: 8.8.8.8
TTL: 128
Frame 2: ICMP Echo Reply (Type 0, Code 0)
Source: 8.8.8.8
Destination: 192.168.1.10
TTL: 117
2. Ping – "살아있니?" 한 줄로 확인하는 연결 테스트
Ping은 가장 기본적인 네트워크 진단 명령어입니다. 특정 IP 주소 또는 도메인으로 ICMP Echo Request 패킷을 보내고, 대상에서 ICMP Echo Reply가 돌아오는지 확인합니다. 응답 시간(RTT, Round-Trip Time)을 측정하고, 패킷 손실 여부를 알 수 있어서 "네트워크가 연결되어 있는가", "응답 속도는 얼마나 빠른가"를 한눈에 파악할 수 있습니다.
Ping 결과에서 주목해야 할 수치는 세 가지입니다. 첫째, RTT(응답 시간): 수십 ms 이하면 정상, 수백 ms를 넘으면 느린 것입니다. 둘째, 패킷 손실률: 0%가 정상이며, 손실이 있으면 네트워크 품질이 좋지 않다는 신호입니다. 셋째, TTL 값: 운영체제나 장비마다 기본 TTL이 다르기 때문에 대략적인 홉 수를 유추할 수 있습니다.
# Windows에서 Ping 실행 예시
C:\> ping google.com
google.com [142.250.196.110]에 Ping 보내는 중 32바이트 데이터 사용:
142.250.196.110의 응답: 바이트=32 시간=12ms TTL=117
142.250.196.110의 응답: 바이트=32 시간=11ms TTL=117
142.250.196.110의 응답: 바이트=32 시간=13ms TTL=117
142.250.196.110의 응답: 바이트=32 시간=12ms TTL=117
142.250.196.110에 대한 Ping 통계:
패킷: 보냄 = 4, 받음 = 4, 손실 = 0 (0% 손실)
왕복 시간(밀리초):
최소 = 11ms, 최대 = 13ms, 평균 = 12ms
# Linux에서 Ping 실행 예시
$ ping -c 4 google.com
PING google.com (142.250.196.110) 56(84) bytes of data.
64 bytes from 142.250.196.110: icmp_seq=1 ttl=117 time=12.3 ms
64 bytes from 142.250.196.110: icmp_seq=2 ttl=117 time=11.8 ms
64 bytes from 142.250.196.110: icmp_seq=3 ttl=117 time=13.1 ms
64 bytes from 142.250.196.110: icmp_seq=4 ttl=117 time=12.0 ms
--- google.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 11.800/12.300/13.100/0.476 ms
# 패킷 손실이 있는 경우
$ ping -c 10 192.168.1.100
10 packets transmitted, 7 received, 30% packet loss, time 9008ms
rtt min/avg/max/mdev = 1.2/45.3/120.5/33.2 ms
Ping이 "Request timed out"을 반환한다고 무조건 대상 장비가 꺼진 것은 아닙니다. 방화벽이 ICMP를 차단하고 있어도 똑같이 응답이 없습니다. 이 부분을 모르고 처음에 "서버가 다운됐다"고 잘못 판단해서 불필요하게 재부팅을 요청한 경험이 있습니다. 알고 보니 서버는 잘 동작하고 있었고, 방화벽 정책에서 ICMP를 막고 있었던 것이었습니다. 그 일 이후로 Ping 결과 하나만 보고 섣불리 판단하지 않는 습관이 생겼습니다. Ping은 강력하지만 완전하지 않습니다. TCP 포트 연결이나 애플리케이션 레벨 응답까지는 확인할 수 없기 때문에, Ping 성공이 곧 서비스 정상을 의미하지는 않는다는 점을 항상 염두에 두어야 합니다.
3. Traceroute – 패킷이 어떤 길로 가는지 발자국 추적하기
Traceroute(윈도우에서는 tracert)는 패킷이 출발지에서 목적지까지 거쳐가는 모든 라우터(홉)를 순서대로 보여주는 도구입니다. 마치 택배 조회 화면에서 "집하 → 분류 → 배송 출발 → 배달 완료"처럼 경로를 단계별로 보여주는 것과 같습니다. TTL(Time To Live) 값을 1부터 시작해 점점 늘려가면서 패킷을 보내고, TTL이 0이 되는 순간 라우터가 보내오는 ICMP Time Exceeded 메시지를 수집해서 경로를 역추적하는 방식입니다.
# Windows에서 tracert 실행
C:\> tracert google.com
google.com [142.250.196.110]에 대한 경로 추적
최대 30홉 사용:
1 1 ms 1 ms 1 ms 192.168.1.1 [내 공유기]
2 5 ms 4 ms 5 ms 10.10.10.1 [ISP 첫 번째 라우터]
3 8 ms 7 ms 8 ms 203.xxx.xxx.1 [ISP 코어 라우터]
4 10 ms 9 ms 10 ms 1.xxx.xxx.xxx [백본 라우터]
5 11 ms 12 ms 11 ms 74.125.xxx.xxx [Google 라우터]
6 12 ms 11 ms 12 ms 142.250.196.110 [목적지]
추적을 완료했습니다.
# Linux에서 traceroute 실행 (UDP 방식이 기본)
$ traceroute google.com
traceroute to google.com (142.250.196.110), 30 hops max, 60 byte packets
1 192.168.1.1 (192.168.1.1) 0.543 ms 0.512 ms 0.499 ms
2 10.10.10.1 (10.10.10.1) 4.123 ms 4.089 ms 4.201 ms
3 * * * [ICMP 차단된 홉]
4 203.xxx.xxx.1 8.321 ms 8.290 ms 8.311 ms
5 142.250.196.110 12.100 ms 11.980 ms 12.050 ms
# ICMP 방식으로 traceroute 실행 (Linux)
$ traceroute -I google.com
# MTR로 실시간 경로 모니터링 (Ping + Traceroute 결합)
$ mtr google.com
Host Loss% Snt Last Avg Best Wrst StDev
1. 192.168.1.1 0.0% 10 0.5 0.5 0.4 0.6 0.0
2. 10.10.10.1 0.0% 10 4.1 4.2 4.0 4.5 0.1
3. ??? 100.0% 10 0.0 0.0 0.0 0.0 0.0
4. 142.250.196.110 0.0% 10 12.0 12.1 11.9 12.5 0.2
Traceroute 결과에서 특정 홉이 "* * *"으로 표시된다고 해서 그 지점에서 경로가 끊긴 것은 아닙니다. 단순히 해당 라우터가 ICMP Time Exceeded 응답을 보내지 않도록 설정된 것일 수 있습니다. 회사 네트워크 장애를 분석하던 중 중간 홉이 전부 * * *로 표시돼서 당황한 적이 있었는데, 목적지까지의 연결 자체는 정상이었습니다. 이 경험을 통해 Traceroute 결과를 전체적인 흐름으로 해석하는 것이 중요하다는 것을 배웠습니다. 또한 Traceroute는 경로가 비대칭일 수 있다는 점도 놓치기 쉽습니다. 출발지에서 목적지로 가는 경로와 돌아오는 경로가 다를 수 있기 때문에, Traceroute만으로 전체 네트워크 경로를 완벽히 파악하는 데는 한계가 있습니다.
4. Ping과 Traceroute 실전 활용 – 장애 상황별 진단법
실무에서 네트워크 장애가 발생했을 때 Ping과 Traceroute를 어떤 순서로 활용하는지 알아봅시다. 체계적인 순서로 진단하면 문제 원인을 훨씬 빠르게 찾을 수 있습니다.
Step 1. 먼저 자기 자신에게 Ping(루프백 테스트)으로 TCP/IP 스택이 살아있는지 확인합니다.
Step 2. 기본 게이트웨이(공유기)에 Ping을 보내 로컬 네트워크가 정상인지 확인합니다.
Step 3. 외부 IP(예: 8.8.8.8)에 Ping을 보내 인터넷 연결 자체를 확인합니다.
Step 4. 도메인명으로 Ping을 보내 DNS 해석이 되는지 확인합니다.
Step 5. 목적지까지 Traceroute로 경로 전체를 확인합니다.
# Step별 진단 명령어 예시
# Step 1: 루프백 테스트
$ ping 127.0.0.1
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.034 ms
→ 성공하면 TCP/IP 스택은 정상
# Step 2: 게이트웨이 테스트
$ ping 192.168.1.1
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.543 ms
→ 성공하면 로컬 네트워크 연결 정상
# Step 3: 외부 IP 테스트 (Google DNS)
$ ping 8.8.8.8
64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=12.3 ms
→ 성공하면 인터넷 연결 정상
# Step 4: 도메인 테스트
$ ping google.com
64 bytes from 142.250.196.110: icmp_seq=1 ttl=117 time=12.5 ms
→ 성공하면 DNS 해석도 정상
# Step 3 성공, Step 4 실패 = DNS 문제
# Step 5: 경로 추적
$ traceroute 8.8.8.8
# 어느 홉에서 지연이 발생하는지, 어디서 끊기는지 확인
이 진단 순서는 네트워크 공부를 시작한 이후 가장 많이 써먹은 방법입니다. 처음에는 무작정 "인터넷이 안 된다"며 공유기를 재시작하기 바빴는데, 이 방법을 익힌 뒤로는 5분 안에 원인을 파악할 수 있게 되었습니다. 실제로 회사에서 특정 PC만 인터넷이 안 된다는 신고를 받았을 때, Step 2에서 게이트웨이 Ping이 실패하는 것을 보고 케이블 문제임을 바로 확인한 적도 있습니다. Ping과 Traceroute는 단순해 보이지만 사용자가 결과를 제대로 해석하지 못하면 아무 쓸모가 없습니다. 도구의 강력함은 도구를 쓰는 사람의 이해도에 비례한다는 것을 경험을 통해 배웠습니다.
5. ICMP 보안 이슈 – 도구인가, 위험인가
ICMP는 편리한 진단 도구이지만, 동시에 보안 위협의 경로가 되기도 합니다. 대표적인 ICMP 관련 공격 유형을 알아두면 보안 설정을 이해하는 데 도움이 됩니다.
- Ping Flood (ICMP Flood): 대량의 Echo Request를 보내 대상을 과부하시키는 DDoS 공격
- Smurf Attack: 브로드캐스트 주소로 Ping을 보내 수많은 장비가 피해자에게 동시에 응답하게 만드는 증폭 공격
- Ping of Death: 비정상적으로 큰 ICMP 패킷을 보내 시스템을 충돌시키는 공격 (현재 대부분 패치됨)
- ICMP Redirect 공격: 가짜 ICMP Redirect 메시지로 라우팅 경로를 조작하는 공격
# 방화벽에서 ICMP를 제한하는 iptables 예시 (Linux)
# Ping 허용하되 Rate Limiting 적용 (초당 1개만 허용)
$ iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 1/s --limit-burst 4 -j ACCEPT
$ iptables -A INPUT -p icmp --icmp-type echo-request -j DROP
# ICMP 전체 허용 (테스트 환경)
$ iptables -A INPUT -p icmp -j ACCEPT
# Windows 방화벽에서 Ping 허용
> netsh advfirewall firewall add rule name="Allow ICMPv4" protocol=icmpv4:8,any dir=in action=allow
보안 강화를 이유로 ICMP를 전부 차단하는 정책을 쓰는 곳을 종종 봤는데, 이는 지나친 조치라고 생각합니다. ICMP를 차단하면 "Destination Unreachable" 같은 필수 메시지도 막혀버려서 오히려 TCP 연결이 정상적으로 종료되지 않고 타임아웃을 기다리는 상황이 발생합니다. 특히 PMTUD(Path MTU Discovery)가 ICMP에 의존하기 때문에, ICMP를 무분별하게 차단하면 특정 크기 이상의 패킷이 전달되지 않는 "Black Hole" 문제가 생길 수 있습니다. Rate Limiting과 필요한 메시지 타입만 선별적으로 허용하는 정책이 훨씬 현명한 접근법입니다. 도구를 무서워서 없애기보다 제대로 통제하는 방법을 배우는 것이 진짜 실력입니다.
참고 출처
- RFC 792 – Internet Control Message Protocol: https://www.rfc-editor.org/rfc/rfc792
- Cisco – Understanding the Ping and Traceroute Commands: https://www.cisco.com/c/en/us/support/docs/ios-nx-os-software/ios-software-releases-121-mainline/12778-ping-traceroute.html
- Cloudflare – What is ICMP?: https://www.cloudflare.com/learning/ddos/glossary/internet-control-message-protocol-icmp/
- NetworkLessons.com – ICMP: https://networklessons.com/cisco/ccna-routing-switching-icnd1-100-105/icmp-internet-control-message-protocol
- Linux man page – traceroute(8): https://linux.die.net/man/8/traceroute
- Microsoft Docs – Test-Connection (Ping) PowerShell: https://learn.microsoft.com/ko-kr/powershell/module/microsoft.powershell.management/test-connection
'IT적응기' 카테고리의 다른 글
| Inter-VLAN 라우팅 네트워크끼리 통신하게 만드는 3가지 방법 (0) | 2026.04.13 |
|---|---|
| L2 스위치-L3 스위치(하드웨어 구조와 성능 차이) (0) | 2026.04.13 |
| OSPF-BGP 내부망과 인터넷망을 연결하는 핵심 프로토콜 (0) | 2026.04.10 |
| "정적,동적 라우팅" 관리 효율성과 성능 - 3가지 기준 결론 낸다 (0) | 2026.04.10 |
| 라우팅 테이블 읽는 방법 어떻게 길을 찾는가? (0) | 2026.04.09 |
