ICMP 완전 이해 (Ping, Traceroute, MTR)

ICMP의 역할 Ping과 Traceroute가 네트워크

Ping이 안 된다고 서버가 죽은 건 아닙니다. 저는 이걸 보고서에 적었다가 망신을 당한 뒤에야 제대로 이해했습니다. ICMP(Internet Control Message Protocol)는 단순한 연결 확인 도구가 아니라 네트워크 전체 상태를 읽어내는 진단 프로토콜입니다. 이 글은 실무에서 ICMP를 잘못 해석했던 경험과 함께, Ping부터 Traceroute, MTR까지 제대로 쓰는 방법을 정리한 것입니다.

Ping이 실패해도 서버가 살아있을 수 있다

Ping 하나면 서버 상태를 알 수 있다고 생각하지 않으십니까? 저도 그렇게 생각했습니다. 그러다 한 번 크게 틀렸습니다.

특정 서버에 Ping이 응답하지 않자 "서버 다운"이라고 보고했는데, 알고 보니 서버는 멀쩡히 서비스 중이었고 방화벽에서 ICMP Echo Request 패킷을 통째로 차단하고 있었을 뿐이었습니다. 보고를 받은 팀장의 표정을 아직도 기억합니다. 그 이후로 저는 절대로 "Ping 실패 = 호스트 장애"라는 등식을 쓰지 않습니다.

이 실수가 가르쳐준 건 단순히 "방화벽 확인도 하자"가 아니었습니다. 어떤 도구든 그 도구가 측정하는 것이 정확히 무엇인지를 먼저 알아야 한다는 것이었습니다. Ping은 ICMP Echo Reply가 돌아오는지를 확인하는 것이지, 서버가 살아있는지를 직접 확인하는 것이 아닙니다. 이 두 가지는 다릅니다. 그 차이를 명확히 인식하지 않으면 도구를 쓰는 게 아니라 도구에 속는 것입니다.

Ping은 ICMP의 Type 8(Echo Request)을 목적지로 보내고 Type 0(Echo Reply)이 돌아오는 시간을 측정하는 방식으로 동작합니다. RTT(Round Trip Time)란 패킷이 출발지에서 목적지까지 갔다가 돌아오는 데 걸리는 총 시간을 의미합니다. 이 수치로 레이턴시와 패킷 손실률을 확인하는 것이 Ping의 핵심 용도입니다.

Ping이 실패할 수 있는 상황은 실제로 꽤 다양합니다. 방화벽이 ICMP 패킷 자체를 차단하는 경우, 목적지 호스트가 ICMP 응답을 비활성화해둔 경우, 경로 중간의 라우터가 ICMP를 필터링하는 경우, 실제로 호스트나 네트워크에 장애가 발생한 경우 모두 동일하게 Ping 실패로 나타납니다. 결국 Ping 실패는 "뭔가 막혀 있거나 장애가 있다"는 신호일 뿐이고, 그게 서버 문제인지 네트워크 문제인지 방화벽 정책인지는 추가 확인이 필요합니다. 이걸 처음부터 구분했더라면 그날의 망신은 없었겠죠.

Traceroute로 경로와 지연 구간을 찾는 법

네트워크가 느리다는 민원이 들어왔을 때, 어디서 문제가 생긴 건지 바로 감이 잡히지 않을 때 Traceroute를 먼저 돌립니다. 이 도구 하나가 수십만 원짜리 모니터링 소프트웨어보다 더 빠르게 원인을 집어낸 적이 있습니다.

Traceroute는 TTL(Time To Live)을 1부터 하나씩 늘려가며 패킷을 전송하는 방식으로 동작합니다. TTL이란 패킷이 라우터를 거칠 때마다 1씩 줄어드는 값으로, 0이 되는 순간 해당 라우터가 ICMP Type 11(Time Exceeded) 메시지를 반환합니다. 이 메시지를 수집해 경로상의 각 라우터, 즉 홉(hop)을 순서대로 파악하는 것이 Traceroute의 원리입니다.

실제로 어떤 회선에서 특정 홉의 RTT가 30ms에서 150ms로 갑자기 튀는 현상을 발견한 적이 있습니다. 그 앞뒤 홉의 응답은 정상이었는데 딱 한 구간만 이상했습니다. 이 Traceroute 결과를 ISP에 들이밀었더니 해당 구간 링크 품질 문제를 인정하고 회선을 교체해줬습니다. Traceroute 결과 스크린샷이 가장 강력한 증거였습니다. 이 경험 이후로 ISP와 이야기할 때는 반드시 Traceroute 데이터를 들고 갑니다. 증거 없는 민원은 ISP가 "저희 쪽은 정상입니다"로 끝낼 수 있지만, 수치가 있으면 이야기가 달라집니다.

한 가지 주의할 점은 Traceroute 방식이 OS마다 다르다는 것입니다. Linux는 기본적으로 UDP 패킷을 사용하고, Windows는 ICMP를 사용하며, hping3 같은 도구를 쓰면 TCP로도 경로를 추적할 수 있습니다. 방화벽이 UDP는 막고 TCP는 허용하는 환경이라면 Linux에서 기본 Traceroute를 쓸 경우 경로가 제대로 보이지 않을 수 있으니, 막힌 홉이 보이면 방식을 바꿔보는 것이 맞습니다. 이 차이를 모르면 "Traceroute 결과가 이상하다"는 현상을 엉뚱한 방향으로 해석하게 됩니다.

ICMP Type 3 세부 코드, 왜 그냥 넘기면 안 되는가

ICMP를 어느 정도 써봤다는 분들도 Type 3(Destination Unreachable) 메시지를 그냥 "연결 안 됨"으로 뭉뚱그려 처리하는 경우가 많습니다. 저도 초반에 그랬고, 그게 얼마나 위험한지 트러블슈팅을 잘못 잡고 나서야 알았습니다.

ICMP가 RFC 792에 정의되어 있는 표준 프로토콜인 만큼, Type 3 아래에는 세부 코드(Code)가 명확히 구분되어 있습니다. Code 0은 Network Unreachable, Code 3은 Port Unreachable입니다. Network Unreachable은 목적지 네트워크 자체에 경로가 없다는 뜻이고, Port Unreachable은 호스트에는 도달했지만 해당 포트에서 서비스가 열려 있지 않다는 뜻입니다. 이 둘을 같은 맥락으로 처리하면 라우팅 테이블을 들여다봐야 할 상황에서 엉뚱하게 애플리케이션 설정만 만지는 꼴이 됩니다.

그게 정확히 제가 한 실수였습니다. Port Unreachable 메시지를 Network Unreachable로 착각하고 라우팅 설정을 한참 뒤졌습니다. 서비스가 단순히 내려가 있었을 뿐인 상황에서 라우팅 테이블을 손댈 뻔 했습니다. ICMP 코드 하나가 트러블슈팅의 방향을 완전히 바꿉니다. 이걸 무시하는 건 단순히 세부 정보를 놓치는 게 아니라, 진단의 출발점을 틀리는 겁니다.

실무에서 이 코드를 제대로 읽는 것만으로도 트러블슈팅 시간이 절반 이하로 줄어든다고 느낀 경험이 있습니다. ICMP 메시지가 왔을 때 Type과 Code를 함께 확인하는 습관, 생각보다 중요합니다.

MTR을 쓰고 나서 Traceroute만 단독으로 쓰는 일이 없어졌다

Traceroute가 강력하다고 했는데, 그보다 한 단계 더 나아간 도구가 있다면 어떨까요? MTR(My Traceroute)을 처음 써봤을 때 솔직히 이건 예상 밖이었습니다. Traceroute는 그 순간의 경로를 한 번 찍어주는 도구지만, MTR은 각 홉에 대해 패킷 손실률과 레이턴시를 지속적으로 모니터링하면서 실시간으로 업데이트해줍니다.

간헐적으로 패킷이 튀는 현상은 Traceroute 한 번으로 잡기가 거의 불가능합니다. 증상이 나타나는 순간에 딱 돌려야 하는데, 그게 마음대로 되지 않습니다. MTR은 계속 돌아가기 때문에 찰나에 발생하는 패킷 손실도 누적해서 보여줍니다. 어느 홉에서 손실이 2%, 5%, 10% 쌓이는지 눈으로 확인하면 문제 구간이 명확하게 드러납니다.

처음 MTR을 보여줬을 때 동료 엔지니어가 "이게 왜 이제야 알게 된 거냐"라고 했는데, 저도 같은 생각이었습니다. 사실 MTR은 그렇게 새로운 도구가 아닙니다. 문제는 많은 엔지니어가 Ping과 Traceroute로 이미 "충분하다"고 생각하기 때문에 추가 도구를 찾아보지 않는다는 겁니다. 쓰던 것에 익숙해지면 더 나은 도구가 있다는 사실 자체를 탐색하지 않게 됩니다. 저도 그랬습니다.

MTR에서 주의할 점도 하나 있습니다. 중간 홉에서 패킷 손실이 100%로 나와도 그 이후 홉이 정상 응답한다면, 해당 라우터가 ICMP 응답을 낮은 우선순위로 처리하거나 의도적으로 무시하는 것일 가능성이 높습니다. 손실이 뒤 홉까지 이어지지 않는다면 실제 서비스 영향은 없을 수 있습니다. 이런 맥락 없이 숫자만 보고 "여기가 문제"라고 단정하면 또 삽질을 하게 됩니다. MTR도 결국 숫자를 해석하는 능력이 필요합니다. 도구가 아무리 좋아도 데이터를 읽는 사람이 잘못 읽으면 결론이 틀립니다.

결국 MTR은 Traceroute의 일회성 단점을 보완하는 도구이고, 현장에서 MTR과 Ping을 함께 쓰는 것이 가장 현실적인 진단 조합이라는 게 지금 저의 판단입니다.

ICMP를 그냥 Ping 확인용으로만 쓰는 건 이 도구의 절반도 활용 못 하는 겁니다. Ping 실패의 의미를 정확히 해석하고, Traceroute로 구간별 지연을 추적하고, MTR로 간헐적 손실을 잡아내는 흐름이 네트워크 장애 대응의 기본입니다. 방화벽에서 ICMP를 전면 차단하는 정책도 다시 생각해볼 필요가 있습니다. Type 3, Type 11처럼 진단에 필수적인 메시지 타입은 선별적으로 허용하되, Echo Request만 제한적으로 관리하는 세분화된 접근이 보안과 운영 가시성을 모두 챙기는 방법입니다. 다음에 네트워크 이상 징후가 생기면 Ping 하나만 쏘지 말고, MTR을 먼저 켜보시기 바랍니다.

---

참고 자료: RFC 792 – ICMP: https://www.rfc-editor.org/rfc/rfc792 / Cisco – Understanding the Ping and Traceroute Commands / Cloudflare – What is ICMP?: https://www.cloudflare.com/learning/ddos/glossary/internet-control-message-protocol-icmp/ / NetworkLessons.com – ICMP / Linux man page – traceroute(8)

---

참고 출처

• 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