Hacker News 2026.04.09 29

traceroute는 어떻게 패킷의 여행 경로를 추적할까?

네트워크의 GPS, traceroute

터미널에서 traceroute google.com을 한 번쯤 쳐본 적 있으시죠? 내 컴퓨터에서 구글 서버까지 패킷이 어떤 경로로 이동하는지를 보여주는 도구인데요. 서버 장애가 났을 때 "어디서 막히는 거지?"를 파악하는 가장 기본적인 네트워크 디버깅 도구이기도 해요. 그런데 이 traceroute가 정확히 어떤 원리로 동작하는지 아는 분은 의외로 많지 않거든요. 오늘은 그 속을 한번 들여다볼게요.

TTL이라는 똑똑한 트릭

traceroute의 핵심은 IP 패킷 헤더에 있는 TTL(Time To Live) 이라는 필드예요. 이게 뭐냐면, 패킷이 네트워크를 돌아다닐 때 "이 패킷은 최대 몇 개의 라우터를 거칠 수 있다"고 정해두는 숫자인데요. 라우터를 하나 지날 때마다 이 숫자가 1씩 줄어들어요. 그러다 TTL이 0이 되면? 그 라우터는 패킷을 더 이상 전달하지 않고, 대신 "이 패킷 여기서 수명이 다했어요"라는 의미의 ICMP Time Exceeded 메시지를 보낸 사람에게 돌려보내요.

traceroute는 바로 이 성질을 이용해요. 처음에 TTL을 1로 설정한 패킷을 보내면, 첫 번째 라우터에서 바로 만료되면서 그 라우터의 IP 주소가 담긴 ICMP 응답이 돌아와요. 그다음엔 TTL을 2로 올려서 보내면 두 번째 라우터에서 만료되고, 그 라우터 정보가 돌아오죠. 이런 식으로 TTL을 하나씩 올려가면서 목적지에 도달할 때까지 반복하면, 경유하는 모든 라우터의 주소와 응답 시간을 알 수 있는 거예요.

비유하자면 이런 거예요. 택배를 보내는데 "1번째 중간 거점에서 멈춰!"라고 적어서 보내면 그 거점이 "나 여기인데요"하고 답장을 해주는 거죠. 그다음엔 "2번째 거점에서 멈춰!"하고 보내고... 이걸 반복하면 택배가 지나가는 모든 중간 거점의 위치를 알 수 있는 셈이에요.

세 가지 맛: UDP, ICMP, TCP

재미있는 건 traceroute 구현이 하나가 아니라는 점이에요. 운영체제마다 기본 방식이 달라요.

리눅스의 기본 traceroute는 UDP 패킷을 사용해요. 목적지 포트를 일부러 아무도 안 쓸 법한 높은 번호(보통 33434부터 시작)로 보내요. 중간 라우터들은 TTL 만료로 ICMP 응답을 보내고, 최종 목적지에 도달하면 해당 포트가 열려있지 않으니까 ICMP Port Unreachable 메시지가 돌아와요. 이걸로 "아, 목적지에 도착했구나"를 판단하는 거예요.

윈도우의 tracert는 처음부터 ICMP Echo Request(ping과 같은 패킷)를 보내요. 좀 더 단순한 방식이죠. 목적지에 도달하면 ICMP Echo Reply가 돌아오니까 도착을 알 수 있어요.

TCP 기반 traceroute(tcptraceroute 같은 도구)도 있어요. TCP SYN 패킷을 보내는 방식인데, 방화벽이 UDP나 ICMP를 차단하는 환경에서 유용해요. 웹 서버의 80번 포트로 TCP traceroute를 하면 방화벽을 통과할 확률이 훨씬 높거든요.

실제 출력 읽는 법

traceroute 결과를 보면 각 줄(hop)마다 보통 세 개의 시간 값이 찍히는데요, 이건 각 hop에 패킷을 세 번 보내서 측정한 왕복 시간(RTT)이에요. 가끔 *로 나오는 줄이 있는데, 이건 해당 라우터가 ICMP 응답을 보내지 않도록 설정되어 있거나, 방화벽이 막고 있는 경우예요. 패킷이 거기서 멈췄다는 뜻이 아니라 그냥 "대답을 안 하는" 라우터인 거죠.

또 하나 주의할 점은, 각 hop의 응답 시간이 비대칭 라우팅 때문에 들쭉날쭉할 수 있다는 거예요. 갈 때와 올 때의 경로가 다를 수 있기 때문에, hop 3이 hop 4보다 응답이 느리다고 해서 반드시 hop 3에 병목이 있다는 의미는 아니에요. 전체적인 추세를 보는 게 중요해요.

업계에서의 위치와 대안 도구들

traceroute는 1988년에 만들어진 아주 오래된 도구인데, 지금도 네트워크 디버깅의 첫 번째 도구로 쓰이고 있어요. 하지만 현대 네트워크는 MPLS 터널이나 ECMP(Equal-Cost Multi-Path) 같은 기술 때문에 traceroute 결과가 실제 경로를 정확히 반영하지 못하는 경우도 많아요.

그래서 더 발전된 도구들도 나왔는데요. mtr은 traceroute와 ping을 합친 것처럼 실시간으로 각 hop의 패킷 손실률과 지연을 계속 모니터링해줘요. Paris Traceroute는 ECMP 환경에서도 일관된 경로를 추적할 수 있도록 플로우 식별자를 고정하는 방식을 써요. 클라우드 환경에서는 AWS VPC Flow Logs나 GCP의 Network Intelligence Center 같은 서비스를 통해 더 정밀한 네트워크 분석이 가능하기도 하고요.

한국 개발자에게 주는 시사점

"저는 백엔드/프론트엔드 개발자인데 네트워크까지 알아야 하나요?"라고 생각하실 수 있는데, 실무에서 의외로 자주 마주치는 상황이에요. 배포한 서비스가 특정 지역에서만 느리다거나, CDN 설정 후 이상하게 응답이 느려졌다거나 할 때, traceroute 한 번이면 문제의 범위를 확 좁힐 수 있거든요. 특히 한국에서 해외 서버(AWS us-east-1 같은)를 쓰는 경우, 패킷이 어떤 해저 케이블 경로를 타는지에 따라 지연이 크게 달라질 수 있어서 traceroute로 확인해보면 흥미로운 결과를 볼 수 있어요.

터미널을 열고 mtr google.com 한번 실행해보세요. 내 패킷이 어떤 여정을 거치는지 보면 네트워크에 대한 감이 확 달라질 거예요.