인터넷에서 데이터가 목적지까지 찾아가는 과정은 우리가 낯선 도시에서 길을 찾는 것과 꽤 비슷합니다. 스마트폰 내비게이션 앱이 "다음 교차로에서 우회전"이라고 알려주듯, 네트워크 장비도 라우팅 테이블이라는 지도를 보고 데이터를 어디로 보낼지 결정합니다. 이 글에서는 라우팅 테이블이 무엇인지, 어떻게 생겼는지, 그리고 실제로 어떻게 읽고 해석하는지를 쉽게 풀어서 설명합니다.
1. 라우팅 테이블이란 무엇인가?
라우팅 테이블(Routing Table)은 라우터 또는 운영체제가 가지고 있는 "목적지별 경로 안내 지도"입니다. 쉽게 말해, "IP 주소 A로 가는 데이터는 B 방향으로 내보내라"는 규칙들을 모아 놓은 표입니다.
라우터는 데이터 패킷이 들어올 때마다 이 테이블을 참조하여 "다음 홉(Next Hop)", 즉 데이터를 넘겨줄 다음 장비의 주소를 결정합니다. 테이블에 맞는 경로가 없으면 패킷은 버려지거나, 기본 경로(Default Route)를 통해 상위 라우터로 전달됩니다.
라우팅 테이블에는 크게 세 가지 방식으로 경로가 등록됩니다. 첫째는 직접 연결(Connected)로, 라우터 자신의 인터페이스에 직접 연결된 네트워크입니다. 둘째는 정적 경로(Static Route)로, 관리자가 수동으로 입력한 경로입니다. 셋째는 동적 경로(Dynamic Route)로, OSPF, BGP 같은 라우팅 프로토콜이 자동으로 학습해 채워 넣은 경로입니다.
처음 네트워크를 공부할 때 라우팅 테이블이 왜 필요한지 와닿지 않았습니다. 그런데 실제로 회사 서버에 접근이 안 되는 장애가 발생했을 때, 원인이 라우팅 테이블에 경로가 없어서였습니다. ip route show 명령어로 테이블을 열어봤더니, 해당 대역 경로가 통째로 빠져 있었고, 정적 경로 한 줄을 추가하자마자 연결이 복구됐습니다. 그 순간 "아, 이게 바로 지도구나"라는 감각이 왔습니다. 라우팅 테이블은 단순한 이론이 아니라, 실제 장애 상황에서 가장 먼저 열어봐야 할 핵심 정보입니다.
라우팅 테이블 기본 출력 예시 (Linux)
$ ip route show
default via 192.168.1.1 dev eth0 proto static
10.0.0.0/8 via 10.10.10.1 dev eth1 proto ospf metric 110
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.100
- default via 192.168.1.1 : 목적지를 모르면 192.168.1.1(게이트웨이)로 보내라
- 10.0.0.0/8 via 10.10.10.1 : 10.x.x.x 대역은 10.10.10.1을 통해 가라
- 192.168.1.0/24 dev eth0 : 직접 연결된 네트워크
2. 라우팅 테이블의 구성 요소
라우팅 테이블을 제대로 읽으려면 각 컬럼이 무엇을 뜻하는지 알아야 합니다. 복잡해 보이지만, 사실 몇 가지 핵심 항목만 알면 됩니다.
| 항목 | 설명 | 예시 |
|---|---|---|
| 목적지 네트워크 (Destination) | 데이터를 보낼 목적지 IP 주소 또는 네트워크 대역 | 10.0.0.0/8 |
| 서브넷 마스크 (Prefix Length) | 목적지 네트워크의 범위를 나타냄 | /24, /16, /8 |
| 다음 홉 (Next Hop) | 패킷을 전달할 다음 라우터의 IP 주소 | 192.168.1.1 |
| 출력 인터페이스 (Interface) | 패킷을 내보낼 네트워크 포트 | eth0, GigabitEthernet0/1 |
| 메트릭 (Metric) | 경로의 우선순위(숫자가 낮을수록 우선) | 110, 20, 1 |
| 경로 출처 (Protocol) | 경로가 어떻게 등록됐는지 (static, ospf, bgp 등) | S, O, B, C |
라우팅 테이블에서 가장 중요한 개념 중 하나는 최장 접두사 일치(Longest Prefix Match)입니다. 여러 경로가 동시에 매칭될 때, 서브넷 마스크가 가장 긴(범위가 가장 좁은) 경로를 우선 선택합니다. 예를 들어 목적지가 10.1.1.5라면, 10.0.0.0/8보다 10.1.1.0/24 경로를 먼저 씁니다.
메트릭 개념을 처음 접했을 때, 왜 숫자가 낮은 게 좋은 건지 헷갈렸습니다. 도로로 치면 "거리가 짧을수록 좋다"는 것인데, OSPF의 기본 메트릭 110과 EIGRP의 90을 두고 같은 목적지에 두 경로가 경쟁하면 EIGRP 경로가 이긴다는 것을 장애 상황에서 직접 확인했습니다. 메트릭과 AD(Administrative Distance) 값은 단순히 숫자가 아니라 라우터가 "어떤 길을 믿을 것인가"를 결정하는 신뢰도 지표입니다. 이 두 가지를 혼동하면 예상치 못한 경로로 트래픽이 흐르는 문제가 생기므로 반드시 구분해서 이해해야 합니다.
Cisco IOS 라우팅 테이블 출력 예시
Router# show ip route
Codes: C - connected, S - static, O - OSPF, B - BGP
C 192.168.1.0/24 is directly connected, GigabitEthernet0/0
S 0.0.0.0/0 [1/0] via 203.0.113.1
O 10.10.0.0/16 [110/20] via 10.0.0.2, 00:05:12, GigabitEthernet0/1
B 172.16.0.0/12 [20/0] via 203.0.113.2
- [110/20] : AD(Administrative Distance) 110, 메트릭 20
- O : OSPF로 학습된 경로
- B : BGP로 학습된 경로
3. 라우팅 테이블은 어떻게 만들어지는가?
라우팅 테이블은 저절로 만들어지지 않습니다. 세 가지 방법으로 채워집니다.
첫 번째, 직접 연결(Connected Route)입니다. 라우터에 IP 주소가 설정된 인터페이스가 활성화되면, 해당 네트워크 대역이 자동으로 테이블에 등록됩니다. 아무 설정을 하지 않아도 생기는 기본 경로입니다.
두 번째, 정적 경로(Static Route)입니다. 관리자가 직접 ip route 목적지 마스크 게이트웨이 형식으로 입력합니다. 변경이 없는 소규모 환경에서 쓰기 좋고, 예측 가능한 경로를 보장합니다. 단, 경로가 많아지면 관리 부담이 급증합니다.
세 번째, 동적 라우팅 프로토콜입니다. OSPF, BGP, EIGRP 같은 프로토콜이 인접 라우터와 정보를 교환하면서 자동으로 경로를 학습하고 테이블에 넣습니다. 네트워크 변화가 생기면 자동으로 갱신되어 장애 복구도 빠릅니다.
소규모 사무실 네트워크를 처음 구성했을 때, 정적 경로만으로도 잘 돌아갔습니다. 그런데 지사를 하나 더 추가하면서 경로가 늘어나자, 설정 파일이 점점 길어지고 하나라도 틀리면 전체 통신이 끊겼습니다. 그때 OSPF로 전환하면서 비로소 동적 라우팅의 편리함을 체감했습니다. 처음에는 "그냥 수동으로 쓰면 되지 않나"라고 생각했지만, 네트워크 규모가 커지면 동적 프로토콜 없이는 운영이 사실상 불가능합니다. 작은 환경에서는 정적 경로가 명확하고 안전하지만, 규모가 커질수록 동적 라우팅의 투자 가치가 훨씬 높아집니다.
정적 경로 설정 예시 (Linux)
# 특정 네트워크로 가는 정적 경로 추가
$ sudo ip route add 10.20.0.0/16 via 192.168.1.254 dev eth0
# 기본 경로(Default Route) 설정
$ sudo ip route add default via 192.168.1.1
# 경로 삭제
$ sudo ip route del 10.20.0.0/16
4. 라우팅 테이블 실제로 읽기 — 실습
이제 실제 라우팅 테이블 출력을 보고 해석하는 연습을 해봅시다. 아래는 리눅스 서버의 라우팅 테이블입니다.
$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.1.1 0.0.0.0 UG 100 0 0 eth0
10.0.0.0 10.10.10.1 255.0.0.0 UG 110 0 0 eth1
192.168.1.0 0.0.0.0 255.255.255.0 U 100 0 0 eth0
172.16.0.0 172.16.0.254 255.255.0.0 UG 200 0 0 eth2
Flag 의미
- U : 경로가 활성 상태(Up)
- G : 게이트웨이를 통해 가는 경로
- H : 단일 호스트 경로
위 테이블을 해석하면 다음과 같습니다.
- 목적지를 알 수 없는 모든 패킷은 192.168.1.1(인터넷 게이트웨이)로 보냅니다.
- 10.x.x.x 대역 트래픽은 eth1 인터페이스를 통해 10.10.10.1로 보냅니다.
- 192.168.1.x는 직접 연결 네트워크로, eth0으로 바로 전달합니다.
- 172.16.x.x 대역은 eth2를 통해 172.16.0.254로 보냅니다.
처음에는 route -n과 ip route show가 다른 도구인지도 몰랐습니다. 두 명령어가 같은 정보를 다른 형식으로 보여준다는 것을 알게 된 뒤부터 장애 진단 속도가 눈에 띄게 빨라졌습니다. 특히 -n 옵션을 빼면 DNS 역조회 때문에 출력이 느려지는데, 급한 상황에서 이걸 모르고 기다린 적이 있어서 이제는 반사적으로 -n을 붙입니다. 라우팅 테이블을 읽는 연습을 자주 할수록, 네트워크 장애가 생겼을 때 "어디서 막혔는지"를 빠르게 파악할 수 있습니다. 이론만 배울 게 아니라, 직접 서버나 가상 환경에서 명령어를 쳐보는 것을 강력히 권장합니다.
5. 라우팅 테이블 문제 해결 — 트러블슈팅
라우팅 테이블 관련 문제는 크게 세 가지 패턴으로 나타납니다.
패턴 1 : 경로가 없다
목적지 네트워크로 가는 경로 자체가 없는 경우입니다. ping이나 traceroute로 특정 IP에 도달이 안 될 때 가장 먼저 확인해야 합니다. 해결책은 정적 경로를 추가하거나, 동적 라우팅 설정을 점검하는 것입니다.
패턴 2 : 잘못된 경로가 있다
경로는 있는데 잘못된 게이트웨이를 가리키는 경우입니다. 이 경우 ping은 나가지만 응답이 없거나, 엉뚱한 곳으로 트래픽이 흘러갑니다. traceroute로 경로를 추적하면 어느 홉에서 잘못됐는지 바로 보입니다.
패턴 3 : 경로가 충돌한다
같은 목적지로 여러 경로가 등록된 경우입니다. 메트릭과 AD 값에 따라 라우터가 선택하는 경로가 달라집니다. 예상과 다른 경로가 선택된다면 show ip route 목적지 명령으로 어느 경로가 선택됐는지 확인해야 합니다.
# 특정 목적지 경로 상세 확인 (Linux)
$ ip route get 8.8.8.8
8.8.8.8 via 192.168.1.1 dev eth0 src 192.168.1.100
# Cisco IOS에서 특정 목적지 경로 확인
Router# show ip route 10.10.10.5
Routing entry for 10.10.0.0/16
Known via "ospf 1", distance 110, metric 20
Last update from 10.0.0.2 on GigabitEthernet0/1
실무에서 가장 많이 만나는 라우팅 문제는 의외로 단순한 오타나 서브넷 계산 실수에서 비롯됩니다. /24인데 /25로 잘못 입력하거나, 게이트웨이 주소를 한 자리 틀리는 식입니다. 그래서 설정을 마친 뒤에는 반드시 ip route show나 show ip route로 실제 테이블을 눈으로 확인하는 습관이 중요합니다. 자동화 도구를 쓰더라도, 결국 결과를 검증하는 것은 사람의 몫입니다. 라우팅 테이블을 빠르고 정확하게 읽는 능력은 네트워크 엔지니어의 가장 기본적이면서도 가장 중요한 스킬입니다.
마무리
라우팅 테이블은 네트워크의 지도입니다. 목적지, 게이트웨이, 인터페이스, 메트릭이라는 네 가지 핵심 요소만 이해해도 대부분의 라우팅 문제를 스스로 진단할 수 있습니다. 이론으로만 배우지 말고, 직접 리눅스나 가상 라우터에서 ip route show를 쳐보고, 경로를 추가하고 삭제하면서 변화를 관찰해보세요. 그렇게 손으로 익힌 지식이 실제 장애 현장에서 빛을 발합니다.
출처
- Cisco IOS Routing Table — https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_pi/
- Linux ip-route man page — https://man7.org/linux/man-pages/man8/ip-route.8.html
- RFC 1812 — Requirements for IP Version 4 Routers — https://datatracker.ietf.org/doc/html/rfc1812
- Juniper Networks Routing Table Documentation — https://www.juniper.net/documentation/
- Computer Networking: A Top-Down Approach, Kurose & Ross (Pearson)
'IT적응기' 카테고리의 다른 글
| OSPF-BGP 내부망과 인터넷망을 연결하는 핵심 프로토콜 (0) | 2026.04.10 |
|---|---|
| "정적,동적 라우팅" 관리 효율성과 성능 - 3가지 기준 결론 낸다 (0) | 2026.04.10 |
| 서브넷 마스크 계산법 - CIDR 표기법,서브넷 마스크 계산법 (0) | 2026.04.08 |
| IPv4 고갈 IPv6 전환이 생각보다 느린 진짜 이유 (0) | 2026.04.08 |
| L2 스위치 가이드 매니지드-언매니지드 스위치 차이 (4) | 2026.04.07 |
