핵심 인사이트 (3줄 요약)

  1. 본질: Policy-Based Routing / R…는 라우팅과 경로 제어에서 핵심 동작과 제약을 이해하게 해 주는 개념이다.
  2. 가치: Policy-Based Routing / R…를 이해하면 수렴 속도과 확장성 사이의 균형을 더 정확히 볼 수 있다.
  3. 판단 포인트: 설계 시에는 개념 자체보다 적용 조건, 운영 복잡도, 인접 기술과의 경계를 함께 판단해야 한다.

Ⅰ. 개요 및 필요성

  • 개념: 표준 라우팅 프로토콜이 결정한 최적 경로(Destination-based)를 무시하고, 관리자가 정의한 정책(Route Map)에 따라 트래픽의 포워딩 경로를 임의로 조작하는 기술.

  • 필요성: 서울 본사에서 부산 지사로 가는 길이 2개 있다 (1번 광랜, 2번 일반선). OSPF를 돌리면 무조건 1번 광랜만 탄다. 근데 사장님이 지시했다. "야, 임원진 PC 10대가 보내는 데이터만 1번 광랜 태우고, 나머지 1000명 일반 직원이 보내는 건 다 2번 일반선으로 몰아!" OSPF(목적지 기반 라우팅)로는 이 지시를 절대 구현할 수 없다(부산이라는 목적지는 같으니까). 결국 패킷의 **'출발지(Source)'**나 **'어플리케이션 종류'**를 뜯어보고 길을 갈라치는 깡패 같은 룰이 필요했다.

  • 💡 비유: 일반 라우팅이 **"지하철 노선도"**라면, PBR은 클럽 앞의 **"기도(가드) 아저씨"**입니다.

    • 지하철: 승객이 부자든 거지든(출발지 무관) "강남역(목적지)" 간다고 하면 똑같은 2호선 열차에 태웁니다.
    • PBR 가드: 클럽(목적지)에 들어가려는 사람들을 붙잡고, **"어? 너 VIP(특정 출발지 IP)네? 넌 하이패스 정문으로 가! 어? 넌 일반인이네? 저쪽 좁은 뒷문으로 돌아가!"**라며 사람의 신분을 보고 강제로 길을 꺾어버립니다.
[VRF]
    │
    ▼
[Policy-Based Routing / R…]
    │
    └──▶ [MPLS]
  • 📢 섹션 요약 비유: ** PBR은 공정한 법(라우팅 테이블) 위에 군림하는 **"관리자의 독재(사면권)"**입니다. 내비게이션이 아무리 빠른 길을 알려줘도, 조수석에 앉은 회장님이 "저쪽 골목으로 들어가!" 하면 운전사(라우터)는 찍소리 못하고 핸들을 꺾어야 합니다.

Ⅱ. 아키텍처 및 핵심 원리

1. Route Map (루트 맵)의 뼈대: Match & Set

PBR을 구현하려면 시스코 장비 기준 **route-map**이라는 프로그래밍 함수 같은 구조체를 짜야 한다. 루트 맵은 철저하게 "If ~ Then" 구조로 되어 있다.

  • match (If 조건문): "누구를 잡아낼 것인가?"
    • 예: match ip address 10 (ACL 10번에 적힌 사장님 IP 192.168.1.99를 잡아라!)
    • 예: match length 1000 1500 (패킷 크기가 1000바이트 이상인 무거운 놈만 잡아라!)
  • set (Then 실행문): "잡아낸 놈을 어떻게 요리할 것인가?"
    • 예: set ip next-hop 10.1.1.1 (원래 길 무시하고 10.1.1.1 라우터 쪽으로 냅다 던져버려라!)

2. 패킷 처리 시퀀스 (PBR vs 일반 라우팅)

포트로 패킷이 들어올 때 라우터의 뇌구조는 다음과 같다.

  1. 이 포트에 PBR(정책)이 걸려 있나 확인.
  2. 걸려있네? 패킷을 뜯어서 match 조건에 맞는지 본다.
  3. 조건에 맞으면(예: 사장님 IP) ──▶ 라우팅 테이블 무시하고, set 명령에 따라 강제로 1번 길로 날려버림!
  4. 조건에 안 맞으면(예: 일반 직원) ──▶ PBR 룰을 통과하여, 비로소 일반 라우팅 테이블(OSPF 등)을 보고 2번 길로 정상 배달됨.
 ┌─────────────────────────────────────────────────────────────┐
 │                PBR (Policy-Based Routing) 트래픽 갈라치기 도식    │
 ├─────────────────────────────────────────────────────────────┤
 │                                                             │
 │   [ 사장님 PC (192.168.1.99) ] ────┐                          │
 │                                  ▼ [라우터]                     │
 │   [ 직원들 PC (192.168.1.x)  ] ────┤ 1) PBR 검사              │
 │                                    │ - 99번 IP인가? (Match)   │
 │                                    │ - Yes ──▶ 광랜으로 쏴! (Set)│
 │                                    │ - No  ──▶ 라우팅테이블 봐!  │
 │                                    │                        │
 │   * 라우터의 행동:                      ▼                        │
 │     사장님 패킷 ════════════════════▶ [ 광랜 (비싼 전용선) ]      │
 │     직원들 패킷 ────────────────────▶ [ 일반망 (ADSL선) ]       │
 │                                                             │
 │   ▶ "목적지가 같아도 출발지 신분에 따라 다른 길로 던지는 마법!"         │
 └─────────────────────────────────────────────────────────────┘

3. PBR의 치명적 단점 (CPU 갉아먹기)

PBR은 마약과 같다. 쓰면 좋지만 남발하면 라우터가 죽는다. 하드웨어(FIB)가 기계적으로 처리하던 걸, CPU가 일일이 "이거 사장님 IP 맞나? 크기는 맞나?" 하고 match 구문을 검사(소프트웨어 처리)해야 하므로 트래픽 병목과 딜레마(CPU 100%)를 유발한다. 따라서 꼭 필요한 구간에 최소한으로만 걸어두는 것이 실무의 정석이다.

  • 📢 섹션 요약 비유: ** Route Map 설정(match와 set)은 컨베이어 벨트 위의 **"불량품 선별기"**입니다. 벨트 위를 지나가는 수만 개의 택배(패킷) 중, "빨간색 스티커가 붙은 박스(match 조건)"만 귀신같이 탁 쳐서 "VIP 배송 트럭(set 조건)"으로 튕겨내는 무자비한 분류 시스템입니다.

Ⅲ. 비교 및 연결

Policy-Based Routing / R…를 볼 때는 앞뒤 개념과의 경계를 함께 봐야 전체 흐름이 선명해진다. VRF가 기반 조건을 만든다면, Policy-Based Routing / R…는 그 위에서 핵심 메커니즘을 구현하고, MPLS는 이를 더 확장된 적용 단계로 연결한다. 따라서 단일 정의보다 수렴 속도과 확장성에 어떤 차이를 만드는지 비교하는 것이 중요하다.

관점선행 개념현재 개념확장 개념
초점VRF의 기반 정리Policy-Based Routing / R…의 핵심 동작MPLS의 확장 적용
자원 관점기본 조건 확보수렴 속도 최적화규모와 범위 확대
판단 포인트도입 가능성 확인현재 메커니즘의 적합성 판단운영·확장 전략 연결
  • 📢 섹션 요약 비유: Policy-Based Routing / R…는 비슷한 기술들 사이의 차선을 구분하는 분기점과 같다. 어디서 갈라지는지 알아야 헷갈리지 않는다.

Ⅳ. 실무 적용 및 기술사 판단

실무에서는 Policy-Based Routing / R…를 단독 개념으로 외우기보다 어떤 병목을 줄이기 위한 선택인지 먼저 따져야 한다. 특히 VRF 수준의 기본 대책으로 충분한지, 아니면 Policy-Based Routing / R…가 제공하는 메커니즘이 실제로 필요한지 구분해야 한다. 이후 확장 단계에서는 MPLS와 같은 후속 기술, 자동화 체계, 표준 호환성까지 함께 검토해야 한다.

실무 체크리스트

  1. 현재 문제의 핵심이 수렴 속도 부족인지, 확장성 악화인지 먼저 분리한다.
  2. Policy-Based Routing / R…가 추가하는 복잡도와 운영 이득이 균형을 이루는지 확인한다.
  3. 도입 후에는 인접 기술인 MPLS와의 연계 방식을 함께 검증한다.

안티패턴

  • Policy-Based Routing / R…의 장점만 보고 트래픽 패턴이나 운영 비용을 무시한 채 과도 도입하는 설계

  • VRF와의 경계를 정리하지 않아 중복 투자나 정책 충돌을 만드는 설계

  • 📢 섹션 요약 비유: Policy-Based Routing / R…를 실제로 쓰는 판단은 도구 상자를 고르는 일과 비슷하다. 좋아 보이는 도구보다 지금 문제에 맞는 도구가 중요하다.

Ⅴ. 기대효과 및 결론

Policy-Based Routing / R…는 라우팅과 경로 제어를 이해할 때 핵심 축을 잡아 주는 개념이다. 올바르게 적용하면 수렴 속도 개선과 구조적 단순화에 기여하지만, 조건을 잘못 잡으면 오히려 복잡도와 운영 부담이 커질 수 있다. 앞으로는 MPLS, 의도 기반 라우팅, 자동화 운영과의 결합을 통해 더 정교하게 발전할 가능성이 크다. 따라서 이 개념은 정의 자체보다 “언제 쓰고 언제 다른 방법으로 넘길 것인가”의 관점으로 기억하는 것이 좋다. 향후에는 의도 기반 라우팅 같은 자동화 흐름과 결합되어 더 정교한 형태로 확장될 가능성이 크다.

  • 📢 섹션 요약 비유: Policy-Based Routing / R…는 큰 흐름 속에서 기억해야 오래 남는다. 지금의 장점과 다음 확장 방향을 같이 보면 전체 그림이 선명해진다.

📌 관련 개념 맵

개념연결 포인트
VRF현재 개념이 등장하기 전에 갖춰야 할 배경이나 인접 선행 개념이다.
라우팅 테이블 (Routing Table)패킷 전달 의사결정의 기준이 된다.
메트릭 (Metric)최적 경로를 선택하는 비교 척도다.
MPLS현재 개념이 확장되거나 적용 단계로 이어질 때 자주 함께 언급된다.

📈 관련 키워드 및 발전 흐름도

[선행 개념: VRF]
    │
    ▼
[현재 개념: Policy-Based Routing / R…]
    │
    ├──▶ [확장 A: MPLS]
    └──▶ [확장 B: 의도 기반 라우팅]

Policy-Based Routing / R…는 VRF에서 출발해 현재 메커니즘을 정교화하고, 이후 MPLS와 의도 기반 라우팅 같은 확장 흐름으로 이어진다고 보면 기억이 오래간다.

👶 어린이를 위한 3줄 비유 설명

  1. 여러 갈림길이 있는 미로에서 가장 좋은 길을 고르는 게임과 같아요.
  2. 이 개념은 길이 막히면 다른 길로 빨리 바꾸는 규칙도 알려줘요.
  3. 그래서 인터넷 길찾기가 덜 헤매고 더 똑똑해져요.