라우팅

서브넷 하나에 장비 몇 대를 둘 때는 패킷이 어디로 가야 할지 고민할 일이 없습니다. 같은 네트워크 안에 있으면 스위치가 MAC 주소로 직접 전달하면 끝입니다. 문제는 내부망, 인터넷, VPN, 원격 지사가 한꺼번에 붙기 시작할 때입니다. 10.1.0.0/16 대역으로 가는 패킷은 VPN 게이트웨이로 보내야 하고, 172.16.0.0/12는 지사 회선으로, 나머지는 인터넷 출구로 보내야 합니다. 이 기준이 없으면 패킷은 잘못된 경로로 가거나 도착하지 못합니다. 기준을 잘못 잡으면 특정 목적지로만 통신이 안 되거나, 의도하지 않은 경로를 타서 보안 정책을 우회하기도 합니다.

초기 인터넷은 규모가 작아서 목적지마다 경로를 수동으로 관리하는 정적 라우팅으로도 충분했습니다. 하지만 1980년대 후반부터 연결 조직이 폭발적으로 늘면서 수백만 개의 경로를 사람이 직접 관리하는 것은 불가능해졌습니다. 라우터끼리 경로 정보를 자동으로 교환하는 동적 라우팅 프로토콜이 등장한 것도 이 때입니다. 오늘날 클라우드 환경도 같은 원리입니다. VPC 안에서 서브넷 간 통신, 인터넷 게이트웨이 연결, VPN이나 전용선 연결은 모두 라우팅 테이블로 제어되며, 클라우드 콘솔에서 '경로 추가'를 클릭하는 행위가 곧 라우팅 테이블 항목을 추가하는 것입니다.

라우터는 패킷의 목적지 IP를 라우팅 테이블과 대조합니다. 테이블에는 '목적지 CIDR → 다음 홉' 형태의 항목이 쌓여 있습니다. 여러 항목이 목적지와 겹칠 때는 Longest Prefix Match 원칙을 따릅니다. 예를 들어 10.0.0.5로 가는 패킷에 10.0.0.0/24와 10.0.0.0/8 두 항목이 있다면 더 구체적인 /24가 선택됩니다. 테이블에 맞는 항목이 없으면 0.0.0.0/0, 즉 기본 경로가 적용됩니다. 인터넷 출구로 가는 트래픽이 기본 경로를 타는 이유가 여기 있습니다. 결국 라우팅 테이블은 '이 대역은 여기로, 저 대역은 저기로, 나머지는 인터넷으로'라는 의사결정표입니다.

라우팅과 로드 밸런싱은 둘 다 트래픽을 어딘가로 보내지만 판단 기준이 다릅니다. 라우팅은 목적지 네트워크 대역을 보고 어느 경로로 보낼지 정합니다. 로드 밸런싱은 같은 서비스 뒤에 있는 여러 서버 중 어느 인스턴스로 보낼지 정합니다. 전자는 네트워크 간 길찾기, 후자는 서비스 단위 분산입니다. 둘을 혼동하는 경우는 '트래픽을 분산하고 싶다'는 요구를 라우팅 테이블로 해결하려 할 때입니다. 라우팅은 목적지 대역이 다를 때만 경로를 나눌 수 있고, 같은 서비스로의 트래픽을 여러 서버에 나누는 것은 라우팅만으로 할 수 없습니다.

라우팅 테이블을 직접 다루는 순간은 생각보다 자주 옵니다. VPN을 연결할 때 특정 사설 대역으로 가는 경로를 추가하거나, 클라우드에서 퍼블릭 서브넷과 프라이빗 서브넷의 인터넷 출구를 다르게 설정하거나, 지사와 본사를 전용선으로 잇고 서로의 대역이 겹치지 않는지 확인하는 것 모두 라우팅 문제입니다. 경로 설정이 잘못됐을 때 증상은 대체로 '특정 대역으로만 연결이 안 된다'는 형태로 나타납니다. 이 경우 traceroute나 route print로 패킷이 어느 경로를 타고 있는지 확인하면 원인을 빠르게 좁힐 수 있습니다. HTTP 헤더를 보고 분기하거나 요청 내용에 따라 다른 서버로 보내는 것은 라우팅의 영역이 아닙니다.