정적·동적 라우팅 (관리 효율성, 성능, 보안)

정적 라우팅 vs 동적 라우팅 관리 효율성과 성능의 갈림길

"이 경로 왜 안 되지?" 장애 발생 후 라우팅 테이블을 뒤지다 보면, 문서에는 우회 경로가 분명히 존재하는데 트래픽은 어딘가에서 사라지고 있는 상황을 맞닥뜨린 적 있으신가요. 저도 그랬습니다. 그 경험을 계기로 정적 라우팅과 동적 라우팅이 단순히 설정 방식의 차이가 아니라는 걸 몸으로 배웠습니다.

우회 경로는 있었지만 트래픽은 블랙홀로 빠졌다

저는 중견 기업의 네트워크를 인수받았을 때 라우터 20여 대에 수백 개의 정적 경로(Static Route)가 촘촘하게 박혀 있는 환경을 마주했습니다. 정적 경로란 관리자가 목적지별로 다음 홉(Next Hop) 주소를 일일이 손으로 지정해두는 방식입니다. 물리적 경로가 존재해도 정적 경로가 설정되지 않으면 라우터는 그 길을 모르는 것과 같습니다.

어느 날 코어 라우터 한 대가 장애를 일으켰고, 트래픽 절반이 그대로 블랙홀에 빠져들었습니다. 우회할 물리적 링크는 멀쩡히 살아 있었지만, 그 경로에 대한 정적 경로가 아무데도 설정되어 있지 않았던 겁니다. 장애 원인을 찾는 데만 한 시간 넘게 걸렸고, 수동 경로를 밀어넣은 뒤에야 트래픽이 살아났습니다.

이 경험에서 저를 더 불편하게 만든 건 단순히 장애 자체가 아니었습니다. 그 환경을 설계한 사람이 분명히 존재했을 텐데, 우회 경로에 대한 정적 경로가 왜 없었을까 하는 의문입니다. 아마 처음 설계할 때 그 링크는 존재하지 않았고, 나중에 물리 링크를 추가하면서 라우팅 설정을 누락했을 가능성이 높습니다. 정적 라우팅의 본질적인 위험이 여기 있습니다. 인프라가 변할 때마다 사람이 직접 따라가서 설정을 맞춰줘야 하는데, 사람은 반드시 빠뜨립니다.

관리 효율성 측면에서 두 방식의 차이를 정리하면 다음과 같습니다. 정적 라우팅은 노드 수에 비례해 설정 작업이 폭발적으로 늘어나고, 장애 시 수동 개입 없이는 우회가 불가합니다. 동적 라우팅은 프로토콜이 토폴로지 변화를 자동으로 학습하고 전파하므로, 관리자는 프로토콜 설계에만 집중할 수 있습니다. 하이브리드 구성으로는 외부 연결은 BGP, 내부 코어는 OSPF, 특수 구간에만 정적을 혼용하는 방식이 실무 표준으로 통합니다.

"동적 라우팅이 무조건 우월하다"고 보는 시각도 있는데, 저는 이 경험 이후에도 그 말을 그대로 받아들이지 않습니다. 그 이유는 다음 섹션에서 설명하겠습니다.

3초 만에 복구된 경험, 그러나 프로토콜은 양날의 검이다

장애 복구 후 저는 전사 OSPF 전환 프로젝트를 직접 진행했습니다. OSPF(Open Shortest Path First)란 링크 상태 정보를 교환해 최적 경로를 계산하는 동적 라우팅 프로토콜로, 인터넷 표준 RFC 2328에 명세되어 있습니다. 네트워크 내 모든 라우터가 LSA(Link State Advertisement)라는 패킷을 주고받으며 전체 토폴로지를 파악하는 방식입니다.

전환 과정이 녹록지 않았습니다. 초기엔 OSPF Hello 패킷이 기존 정적 경로와 충돌하면서 일부 구간에서 라우팅 루프가 발생했고, Area 설계를 잘못 잡아 LSA Flooding이 과도하게 발생하는 문제도 겪었습니다. LSA Flooding이란 링크 상태 정보가 네트워크 전체로 무분별하게 퍼지는 현상으로, 설계가 부실하면 CPU와 대역폭을 잡아먹는 주범이 됩니다. Area 설계를 다시 잡는 데 예상보다 훨씬 많은 시간이 들었습니다. 동적 라우팅으로 전환하는 것 자체가 목표가 아니라, 잘 설계된 동적 라우팅으로 전환하는 것이 목표여야 한다는 걸 이때 절실하게 배웠습니다.

그런데 전환을 완료하고 동일한 장애 시나리오를 테스트했을 때, 라우터는 3초 만에 우회 경로로 전환했습니다. 이전에 한 시간이 넘었던 그 상황이 3초로 줄어드는 걸 직접 보니, 수렴 시간(Convergence Time)의 의미가 숫자 이상으로 와닿았습니다. 수렴 시간이란 네트워크 변화가 발생했을 때 모든 라우터가 일관된 경로 정보를 다시 공유하기까지 걸리는 시간을 말합니다.

다만 솔직히 말씀드리면, 동적 라우팅으로 넘어가면서 오히려 더 공부해야 할 것들이 생겼습니다. BGP(Border Gateway Protocol) 설정 실수는 자칫 인터넷 레벨의 장애로 번질 수 있고, 실제로 그런 사례는 전 세계적으로 기록이 남아 있습니다. BGP란 서로 다른 자율 시스템(AS, Autonomous System) 간에 경로를 교환하는 프로토콜로, 사실상 인터넷의 뼈대를 이루는 핵심 프로토콜입니다. 프로토콜이 복잡성을 대신 관리해주는 대신, 그 프로토콜 자체를 이해하고 운영하는 역량이 전제되어야 한다는 점은 간과하기 쉽습니다. 이건 진입 장벽이 낮아진 게 아니라, 장벽이 이동한 것입니다.

보안이 최우선인 환경에서 동적 라우팅은 오히려 리스크였다

ICS/SCADA 환경의 OT(Operational Technology) 네트워크 컨설팅을 진행할 때, 저는 정적 라우팅에 대한 생각을 다시 한번 뒤집었습니다. OT 네트워크란 발전소, 제조 공장, 수처리 시설처럼 물리적 설비를 제어하는 산업용 통신망을 말합니다. 여기서는 가용성과 예측 가능성이 무엇보다 중요하고, 허용되지 않은 변화 자체가 리스크입니다.

동적 라우팅 프로토콜을 도입하면 BGP 하이재킹이나 OSPF 스푸핑 같은 공격 표면이 새로 생깁니다. OSPF 스푸핑이란 공격자가 가짜 라우팅 정보를 주입해 트래픽을 의도치 않은 경로로 유도하는 공격으로, 인증이 없는 환경에서는 막기가 쉽지 않습니다. NIST SP 800-189는 인터넷 경계에서의 라우팅 보안을 강조하며, 필터링과 인증을 병행하지 않은 동적 라우팅 환경의 취약성을 지적하고 있습니다.

제가 컨설팅한 해당 OT 환경은 토폴로지가 몇 년째 바뀌지 않았고, 경로 변경이 예측 가능한 방식으로만 이루어져야 했습니다. 동적 프로토콜이 자동으로 경로를 바꿔버리는 상황 자체가 이 환경에서는 장애나 다름없었습니다. MD5 인증이나 BFD(Bidirectional Forwarding Detection) 같은 보안 수단을 얹는다 해도, 복잡성을 추가하는 것 자체가 OT 환경의 철학과 맞지 않았습니다.

이 경험이 저에게 남긴 인식 변화는 꽤 컸습니다. IT 네트워크에서 당연하다고 생각한 원칙들이 OT 환경에서는 전혀 다른 의미를 가집니다. "자동화는 효율"이라는 IT의 가정이 OT에서는 "예측 불가능한 변화"로 해석됩니다. 같은 기술을 다른 맥락에 적용할 때 얼마나 다른 판단 기준이 필요한지를 몸으로 배운 경험이었습니다.

일반적으로 동적 라우팅이 더 안전하다고 알려져 있지만, 실제로 환경에 따라서는 정적 라우팅의 예측 가능성이 더 강력한 보안 수단이 될 수 있습니다. 어떤 기술이 더 낫냐가 아니라, 어떤 환경에 어떤 기술이 맞느냐의 문제입니다.

정적과 동적 라우팅 중 어느 쪽을 선택하든, 결국 그 판단 기준은 규모와 변화율 그리고 운영 역량이 되어야 합니다. 저는 두 방식을 모두 실패와 성공을 섞어가며 경험한 뒤에야, "이건 기술의 우열이 아니라 환경에 대한 적합성의 문제"라는 결론에 도달했습니다. 현재 운영 중인 네트워크가 변화가 적고 소규모라면 굳이 복잡한 프로토콜을 도입할 필요는 없습니다. 반대로 노드가 늘어나고 토폴로지가 자주 바뀐다면, 그때는 동적 라우팅 설계에 시간을 투자하는 것이 훨씬 현명한 선택입니다.

---

출처

• Cisco — Static vs Dynamic Routing — https://www.cisco.com/c/en/us/support/docs/ip/
• RFC 2328 — OSPF Version 2 — https://datatracker.ietf.org/doc/html/rfc2328
• RFC 4271 — BGP-4 — https://datatracker.ietf.org/doc/html/rfc4271
• Juniper Networks — Routing Fundamentals — https://www.juniper.net/documentation/
• Network Warrior, Gary A. Donahue (O'Reilly Media)