라우터는 전체 경로를 모른 채 다음 한 걸음만 고릅니다

낯선 도시에서 지도 없이 길을 찾는 방법이 있습니다. 아무나 붙잡고 목적지를 말한 뒤, 알려주는 방향으로 한 블록 가서 또 물어보는 것입니다.

인터넷의 길찾기(라우팅)도 이와 비슷합니다. 경로 선택 규칙이 각 라우터의 안내표를 만들고, 패킷은 그 표를 따라 한 장비씩 이동합니다.

라우터가 아는 것은 놀랄 만큼 적습니다

• 집 공유기의 규칙은 사실상 하나 — "우리 집 주소가 아니면 전부 ISP로." 이것이 기본 경로입니다.
• 중간 라우터는 "그 주소 대역은 이 방향"처럼 선택된 경로를 테이블에 저장합니다. 패킷을 보낼 때는 전체 경로를 새로 계산하지 않고, 표에서 다음 홉을 찾아 넘깁니다.
• 네트워크 7계층 랩에서 본 IP 헤더의 TTL은 홉을 지날 때마다 1씩 줄어듭니다. 0이 되면 버려지므로, 길 잃은 패킷이 인터넷을 영원히 떠도는 일은 없습니다.

길이 끊기면 걸음만 바꿉니다

라우터들은 이웃끼리 "이 길이 살아 있다"는 소식을 주고받습니다. 회선이 끊기면 근처 테이블이 갱신되고, 패킷은 자연스럽게 우회로로 흐릅니다. 인터넷이 한 곳의 고장으로 멈추지 않는 이유입니다.

회선을 끊어 보세요

1. 기본 경로에서 출발을 누르고, 홉마다 라우터의 테이블과 줄어드는 TTL을 확인합니다.
2. 회선 장애로 바꿔 다시 출발합니다.
3. ⚡ 끊긴 회선 앞에서 ISP 라우터가 백본 B로 우회하는 순간을 봅니다.

규칙이 겹치면 더 구체적인 쪽이 이깁니다

라우팅 테이블에는 같은 주소에 해당하는 규칙이 여러 개 들어 있는 경우가 많습니다. 그럼 어느 걸 쓸까요? 답은 간단합니다. 가장 구체적인 규칙이 이깁니다.

우편물 분류에 비유하면 이렇습니다.

• "대한민국 전체는 A 창구로" — 넓은 규칙
• "서울시는 B 창구로" — 더 좁은 규칙
• "서울시 종로구는 C 창구로" — 가장 좁은 규칙

종로구 주소가 오면 세 규칙에 모두 해당하지만, 가장 좁은 C 창구로 갑니다. 앞서 나온 "우리 집 주소가 아니면 전부 ISP로"라는 기본 경로는 이 목록에서 가장 넓은 규칙, 즉 다른 어떤 규칙에도 안 걸렸을 때 쓰는 마지막 선택지입니다.

이 방식 덕분에 라우터는 인터넷의 모든 주소를 알 필요가 없습니다. 대부분은 넓은 규칙 몇 개로 넘기고, 특별히 다르게 보내야 하는 곳만 좁은 규칙으로 예외를 두면 됩니다.

내 노트북의 진짜 라우팅 테이블

비유 말고 실물을 보겠습니다. 이 글을 쓰는 리눅스 노트북에서 ip route를 친 결과입니다. 규칙이 딱 네 줄입니다.

default        via 192.168.68.1  dev wlp2s0
172.17.0.0/16                    dev docker0
172.18.0.0/16                    dev br-de777f966536
192.168.68.0/24                  dev wlp2s0

주소 뒤의 /24, /16이 규칙의 좁기입니다. 숫자가 클수록 좁습니다. default는 /0, 즉 모든 주소에 해당하는 가장 넓은 규칙입니다.

이제 커널에게 직접 물어봤습니다. ip route get은 "이 주소로 보내면 어디로 나가는지"를 실제로 계산해 알려줍니다.

보내려는 주소	걸리는 규칙	커널이 고른 길
192.168.68.1	/24와 /0	/24 승 → wlp2s0로 직접
172.17.0.5	/16과 /0	/16 승 → docker0로
172.18.0.9	/16과 /0	/16 승 → br-de777f966536로
8.8.8.8	/0만	기본 경로 → 192.168.68.1을 거쳐

마지막 줄만 via가 붙습니다. 나머지 셋은 같은 망 안이라 바로 내보내면 되고, 8.8.8.8은 어디 있는지 모르니 공유기에게 떠넘기는 것입니다. 앞에서 말한 "우리 집 주소가 아니면 전부 ISP로"가 이 한 줄입니다.

여기서 한 가지가 눈에 들어옵니다. 이 컴퓨터는 인터넷 주소를 하나도 모릅니다. 아는 것은 자기 동네 세 개(/24, /16 둘)와 "나머지는 저리로"뿐입니다. 그런데도 전 세계 어디로든 패킷을 보낼 수 있습니다. 라우팅이 각자 조금씩만 알고도 굴러가는 구조라는 게 이 네 줄에 다 들어 있습니다.

직접 확인하려면 이렇게 하면 됩니다.

ip route                    # 규칙 목록
ip route get 8.8.8.8        # 이 주소는 어디로 나가는지

인터넷은 최단 경로를 고르지 않습니다

여기서 오해하기 쉬운 점이 하나 있습니다. 라우팅이라고 하면 지도 앱처럼 가장 빠른 길을 찾아줄 것 같지만, 인터넷의 큰 줄기에서는 그렇지 않습니다.

통신사끼리 경로 정보를 주고받을 때는 거리보다 관계가 우선합니다. 어느 회선에 비용을 지불하는지, 어느 상대와 무상으로 교환하기로 했는지, 어느 쪽으로 트래픽을 보내고 싶은지 같은 사정이 경로 선택에 반영됩니다.

그래서 물리적으로 더 가까운 길을 두고 멀리 돌아가는 경로가 생길 수 있습니다. traceroute 결과가 예상과 다르다고 곧바로 고장이라고 단정할 수 없는 이유입니다. 다만 보이는 홉이 실제 경로 전체와 정확히 같다고 단정해서도 안 됩니다. 중간 장비가 TTL 만료 응답을 보내지 않거나 MPLS 같은 내부 경로를 숨길 수 있고, 응답이 돌아오는 길은 요청이 가는 길과 다를 수 있습니다.

traceroute는 목적지까지의 지도를 완성하는 도구라기보다 어느 구간부터 응답이 달라지는지 비교하는 도구로 쓰는 편이 안전합니다. 정상일 때의 결과와 장애가 있을 때의 결과를 같은 출발지에서 비교해야 의미가 커집니다.

라우터가 실제로 아는 것

라우터는 목적지까지의 전체 경로를 들고 있지 않습니다. 테이블을 보고 "다음 홉" 하나만 고릅니다. 그 판단이 홉마다 반복되면서 경로가 만들어지죠. 길이 끊기면 이웃이 알려 준 소식으로 테이블이 갱신되고, 다음 패킷부터 우회로를 탑니다.

그래서 TTL이 필요합니다. 아무도 전체 그림을 보지 못하는 구조라서 잘못된 테이블이 서로를 가리키면 패킷이 영원히 돌 수 있거든요. 홉마다 1씩 깎아 0이 되면 버립니다.

경로가 바뀌는 동안에는 잠깐 어긋납니다

회선이 끊겼을 때 우회로가 생긴다는 설명에는 생략된 구간이 있습니다. 안내표가 새 경로로 바뀌는 데 시간이 걸린다는 점입니다.

라우터들은 서로 소식을 주고받아 표를 고칩니다. 그런데 그 소식이 모든 장비에 동시에 닿지 않기 때문에, 어떤 라우터는 이미 새 경로를 알고 있고 옆의 라우터는 아직 옛 경로를 들고 있는 구간이 생깁니다. 이 시간을 수렴 시간이라고 부릅니다.

그동안 무슨 일이 생기냐면, 두 라우터가 서로에게 패킷을 떠넘길 수 있습니다. A 는 "이건 B 로"라고 알고 있고 B 는 아직 "이건 A 로"라고 알고 있으면, 패킷이 둘 사이를 왕복합니다. 이때 패킷을 살려 주는 것이 앞에서 본 TTL 입니다. 한 바퀴 돌 때마다 줄어들다가 0 이 되면 버려지므로, 잘못된 표가 잠깐 있어도 그 패킷들이 회선에 영원히 쌓이지는 않습니다.

그래서 회선 장애 직후에는 접속이 아예 안 되는 것이 아니라 일부만 실패하거나 느려지는 상태가 잠깐 이어집니다. 원인을 찾다가 아무것도 안 고쳤는데 저절로 돌아오는 경우가 있다면 이 구간을 지난 것일 수 있습니다.

더 읽을 것

데모의 지형은 라우터 5개로 줄인 것이고, 실제 인터넷은 수십만 개의 네트워크가 BGP·OSPF 같은 프로토콜로 경로 정보를 교환합니다. 내 컴퓨터의 실제 경로는 traceroute(윈도우는 tracert) 명령으로 지금 바로 볼 수 있습니다.