VPN 회선을 고를 때 중요한 것은 모든 상황에서 가장 빠른 노드를 찾는 것이 아니라 지역, 전송 경로와 실제 용도를 맞추는 일입니다. 가까운 곳이 항상 안정적인 것은 아니며, 이름에 ‘전용 회선’이 들어갔다고 모든 네트워크 환경에서 더 빠른 것도 아닙니다. 웹 브라우징에 적합한 회선이 장시간 동영상 재생이나 지속적인 세션이 필요한 AI 도구에도 적합하다는 보장은 없습니다.
더 신뢰할 수 있는 방법은 먼저 대상 서비스가 제공되는 지역을 정한 뒤, 현지 네트워크에서 진입 노드까지의 경로 품질을 확인하고 실제 작업으로 안정성을 점검하는 것입니다. 회선 이름은 단순한 분류 기준일 뿐이며, 최종 결과는 현지 접속망, 통신사 라우팅, 저녁 시간대 혼잡, 클라이언트 구현, 프로토콜 설정과 대상 웹사이트의 제한에도 영향을 받습니다.
선택 순서: 지역, 경로, 용도
회선 목록이 길어도 판단 과정을 세 가지 기준으로 단순화할 수 있습니다. 지역은 물리적 거리와 콘텐츠 권역을 결정하고, 회선 유형은 데이터가 출구에 도달하는 방식을 정하며, 용도는 지연 시간·지속 처리량·세션 안정성 중 무엇을 우선할지 결정합니다. 이 순서는 모든 회선을 하나씩 측정하는 것보다 효율적입니다. 먼저 적합하지 않은 후보를 걸러낼 수 있기 때문입니다.
| 판단 기준 | 핵심 질문 | 우선 확인할 항목 | 흔한 오해 |
|---|---|---|---|
| 지역 | 출구는 어디에 있어야 하는가 | 대상 서비스 권역, 물리적 거리, 계정의 주 사용 지역 | 먼 지역을 기본 선택으로 삼기 |
| 회선 유형 | 트래픽은 어떤 경로를 지나는가 | 직결, 중계, IEPL 및 진입 지점 품질 | 회선 이름만 보고 속도를 판단하기 |
| 용도 | 이번 연결로 무엇을 할 것인가 | 웹 응답, 동영상 지속 처리량, 장시간 연결 안정성 | 한 번의 지연 시간 측정으로 실제 사용을 대신하기 |
- ✅ 먼저 목표를 구체적으로 적으세요: 웹 브라우징, 동영상 시청, AI 도구 사용, 파일 다운로드 중 무엇인지 정합니다.
- ✅ 다음으로 지역을 선택하세요: 익숙한 노드 이름보다 대상 서비스와 계정의 주 사용 지역을 기준으로 삼습니다.
- ✅ 경로를 비교하세요: 같은 출구 지역 안에서 직결, 중계, 전용 회선 진입 경로의 실제 성능을 비교합니다.
- ✅ 실제 작업으로 다시 테스트하세요: 대상 웹사이트를 열고 콘텐츠를 계속 재생하거나 하나의 세션을 처음부터 끝까지 완료합니다.
- ❌ 클라이언트에 표시되는 순간적인 지연 시간만 보지 말고, 출구 지역도 지나치게 자주 바꾸지 마세요.
지역 선택: 거리는 출발점일 뿐
다른 조건이 비슷하다면 물리적 거리가 짧을수록 전파 시간이 줄어드는 경우가 많으므로 가까운 지역을 첫 번째 후보군으로 삼기 좋습니다. 하지만 인터넷 라우팅이 항상 지리적으로 가장 짧은 경로를 따르는 것은 아닙니다. 인접 지역도 통신사 연동 방식에 따라 우회할 수 있고, 먼 지역도 품질이 좋은 중계 진입 지점을 통해 더 안정적인 경로를 제공할 수 있습니다.
일상 브라우징: 가까운 출구부터 시작하기
웹 브라우징에는 짧은 연결, 도메인 조회, 작은 파일 요청이 많이 포함되므로 최고 대역폭보다 응답 속도가 더 쉽게 체감됩니다. 선택할 때는 가까운 지역부터 시작해 페이지 최초 로딩, 이미지 로딩, 여러 탭 전환이 원활한지 확인하세요. 노드 속도 측정 결과는 빠른데 웹페이지가 연결 단계에서 자주 멈춘다면 더 높은 대역폭을 찾기보다 패킷 손실, DNS 조회와 경로 변동을 점검해야 합니다.
지역 콘텐츠: 출구는 서비스 권역과 일치해야 합니다
스트리밍, 뉴스 사이트와 일부 온라인 서비스는 출구 IP를 기준으로 콘텐츠 권역을 판단합니다. 이때는 물리적 거리보다 지역 일치가 우선입니다. 특정 지역의 콘텐츠에 접근하려면 먼저 해당 지역의 출구를 선택한 뒤 같은 지역의 회선끼리 안정성을 비교하세요. 진입 지점은 가까운 곳이어도 되지만 출구는 대상 권역과 일치해야 합니다. 따라서 클라이언트의 회선 이름만 믿지 말고 IP 조회 페이지에서 실제 출구를 확인해야 합니다.
계정 기반 서비스: 지역 변경을 줄이기
로그인이 필요한 AI 도구, 협업 플랫폼과 온라인 계정은 일반적으로 세션, 기기 환경과 네트워크 위치를 함께 확인합니다. 서로 멀리 떨어진 출구를 자주 전환하면 추가 인증이 발생하거나 진행 중인 세션이 종료될 수 있습니다. 더 안정적인 방법은 장기간 사용할 지역을 하나 정하고 같은 지역의 예비 회선을 준비하는 것입니다. 주 회선에 문제가 생겨도 출구 지역은 쉽게 바꾸지 말고 경로만 전환하세요.
‘가장 가까운 노드’는 초기 후보로는 적합하지만 최종 답은 아닙니다. 일관되게 유지해야 할 것은 대상 서비스에 표시되는 출구 지역과 현지 네트워크에서 해당 출구까지의 전체 경로입니다.
회선 유형: 직결, 중계와 IEPL
회선 유형은 클라이언트와 출구 사이의 구성 방식을 설명합니다. Shadowsocks, VMess, Trojan, VLESS, Hysteria2, TUIC 등의 프로토콜과는 다른 개념입니다. 회선은 트래픽이 지나가는 곳을 결정하고, 프로토콜은 클라이언트와 서버가 연결을 설정하고 전송하는 방식을 결정합니다. 같은 프로토콜도 여러 경로에서 실행될 수 있고, 같은 경로도 서로 다른 프로토콜로 접속할 수 있습니다.
직결 회선
직결은 클라이언트가 서비스에서 별도로 구성한 중계 진입 지점을 거치지 않고 원격 노드에 직접 연결하는 방식입니다. 구조가 단순하고 추가 전달 단계가 적어, 현지 통신사에서 대상 지역까지의 라우팅 자체가 양호한 환경에 적합합니다. 단점은 지역 간 공용망 라우팅에 더 크게 의존한다는 점입니다. 연동 혼잡, 우회 또는 일시적인 경로 변경이 사용 경험에 바로 반영될 수 있습니다.
직결이라고 반드시 지연 시간이 낮은 것도 아니고 회선 품질이 낮은 것도 아닙니다. 적합성은 현지 네트워크에서 해당 노드까지의 실제 경로로 판단해야 합니다. 접속 네트워크를 바꾸면 같은 직결 회선의 성능이 크게 달라질 수 있습니다.
중계 회선
중계 회선은 먼저 가까운 진입 지점이나 연동 품질이 좋은 입구에 연결한 뒤, 해당 입구에서 원격 출구로 트래픽을 전달합니다. 이를 통해 불안정한 공용망 경로를 일부 피하고, 서비스가 진입 지점과 출구 사이의 전송을 더 집중적으로 관리할 수 있습니다. 전달 단계가 늘어나지만 진입 품질과 후반부 라우팅이 더 좋다면 전체 사용 경험은 직결보다 나을 수 있습니다.
중계 회선을 선택할 때는 진입 지점과 출구를 함께 확인해야 합니다. 진입 지점은 현지 연결의 원활함을 결정하고, 출구는 대상 서비스에 표시되는 지역을 결정합니다. 한 지역만 표시된 회선 이름으로는 두 위치를 모두 알기 어려울 수 있으므로, 의문이 있으면 회선 설명을 확인하거나 출구 IP로 검증하세요.
IEPL 전용 회선
IEPL은 일반적으로 통신사가 제공하는 국제 이더넷 전용 회선 상품을 의미합니다. 구독 서비스에서 ‘IEPL 회선’은 서비스가 일부 지역 간 전송을 일반 공용망 연동에만 의존하지 않고 전용 전송망이나 관리되는 네트워크 경로에 배치한다는 뜻으로 사용됩니다. 주요 가치는 경로 제어와 혼잡 관리에 있으며, 기기에서 대상 웹사이트까지 모든 구간이 공용 인터넷과 분리된다는 의미는 아닙니다.
사용자 기기에서 진입 지점까지는 여전히 현지 접속망을 거치며, 출구에서 대상 서비스까지도 일반 인터넷을 통과할 수 있습니다. 따라서 불안정한 현지 무선 네트워크, 진입 지점 혼잡, 대상 사이트의 속도 제한이나 클라이언트 설정 오류는 중간에 IEPL을 사용한다고 자동으로 해결되지 않습니다. 전용 회선이라는 표시는 실제 테스트와 분리된 속도 결론이 아니라 경로 유형 정보로 이해해야 합니다.
| 회선 유형 | 경로 특징 | 우선 시도하기 좋은 상황 | 중점 확인 항목 |
|---|---|---|---|
| 직결 | 현지에서 원격 출구로 직접 연결 | 현지에서 대상 지역까지의 공용망 라우팅이 안정적인 경우 | 우회, 패킷 손실, 통신사 연동 품질 |
| 중계 | 먼저 진입 지점에 연결한 뒤 출구로 전달 | 직결이 자주 흔들리거나 원격 라우팅이 좋지 않은 경우 | 진입 위치, 출구 위치, 전달 안정성 |
| IEPL | 지역 간 구간에 전용 또는 관리되는 전송망 사용 | 경로 제어와 지속 연결을 중요하게 보는 경우 | 현지에서 진입 지점까지, 출구에서 대상 서비스까지 남은 공용망 구간 |
용도별 회선 선택: 동영상, AI와 일상 브라우징
작업마다 네트워크 품질에 민감한 지점이 다릅니다. 회선 테스트는 실제 용도에 최대한 가까워야 하며, 그렇지 않으면 결과가 쉽게 왜곡됩니다. 웹페이지가 빠르게 열렸다고 동영상이 계속 원활하다는 뜻은 아니며, 다운로드 속도가 높다고 장시간 연결이 안정적이라는 뜻도 아닙니다.
동영상 재생: 지역 일치와 지속 처리량
동영상 플랫폼은 먼저 출구 지역과 콘텐츠 권역의 일치를 요구하고, 그다음으로 지속 처리량을 봅니다. 재생 시작은 빠르지만 중간에 화질이 반복해서 낮아진다면 지속 전송, 혼잡 제어 또는 저녁 시간대 부하가 충분히 안정적이지 않을 수 있습니다. 테스트할 때는 실제 플랫폼에서 시청할 콘텐츠를 재생하고 재생 위치를 이동해 다시 버퍼링이 원활한지 확인하세요.
동영상 용도에서는 지연 시간이 가장 낮은 회선만 고르면 안 됩니다. 지연 시간은 재생 시작과 조작 반응에 영향을 주고, 지속 처리량은 높은 화질을 유지할 수 있는지를 결정합니다. 같은 지역에 후보가 여러 개라면 시작이 빠른 회선 하나와 지속 재생이 더 안정적인 회선 하나를 남겨 당시 네트워크 상태에 따라 전환하세요.
AI 도구: 일관된 출구와 안정적인 장시간 연결
AI 도구는 일반 웹 요청, 스트리밍 응답과 지속 세션을 동시에 사용하는 경우가 많습니다. 일부 서비스는 WebSocket이나 이와 유사한 장시간 연결 방식에도 의존합니다. 이런 용도에 적합한 회선은 잦은 연결 끊김, 출구 변경과 DNS 지역 불일치를 줄여야 합니다. 한 번의 질의응답 성공은 기본 연결만 확인할 뿐입니다. 로그인, 대화 시작, 긴 답변 수신과 허용된 파일 업로드를 연속으로 완료해야 실제 사용에 더 가까운 테스트가 됩니다.
주 회선을 사용할 수 없다면 같은 출구 지역의 예비 회선으로 먼저 전환하세요. 이렇게 하면 하위 경로를 바꾸면서도 계정의 네트워크 위치가 갑자기 변하는 것을 줄일 수 있습니다. 대상 서비스가 특정 지역을 명확히 제한한다면 먼저 서비스 규정을 확인해야 합니다. 회선 자체로 계정 자격이나 플랫폼 약관을 바꿀 수는 없습니다.
일상 브라우징: 응답 속도와 정확한 분할 라우팅
일상 브라우징에서는 현지 웹사이트와 해외 웹사이트에 동시에 접속하는 경우가 많습니다. 모든 트래픽을 원격 출구로 보내면 직접 연결할 수 있는 현지 서비스도 우회하게 되고, 규칙이 지나치게 공격적이면 프록시가 필요한 도메인이 직결로 잘못 연결될 수 있습니다. 이때는 ‘가장 빠른 회선’ 하나를 고르는 것보다 분할 라우팅의 정확성이 더 중요합니다.
먼저 안정적으로 관리되는 규칙 세트를 사용한 뒤 실제 웹사이트에 맞춰 도메인 규칙을 추가하는 것이 좋습니다. 규칙을 수정한 후에는 연결을 다시 만들고 기존 조회 결과를 보관할 수 있는 애플리케이션 상태를 정리하세요. 브라우저는 정상인데 특정 독립 앱만 연결되지 않는다면 해당 앱이 시스템 프록시를 따르는지, 또는 가상 네트워크 인터페이스 모드로 인계해야 하는지 확인해야 합니다.
프로토콜과 회선은 같은 계층이 아닙니다
클라이언트에 구독을 가져온 뒤, 흔히 사용하는 노드는 Shadowsocks, VMess, Trojan, VLESS, Hysteria2 또는 TUIC 프로토콜을 사용할 수 있습니다. 프로토콜 차이는 전송 방식, 인증 구조, TCP·UDP 사용 여부와 클라이언트 호환성에 영향을 주지만, 프로토콜 이름만으로 노드가 직결·중계·전용 회선 중 어떤 경로를 사용하는지는 알 수 없습니다.
Shadowsocks는 비교적 간결한 암호화 프록시 프로토콜로 클라이언트 지원 범위가 넓습니다. VMess와 VLESS는 관련 프록시 생태계에서 흔히 사용되며, VLESS는 인증과 전송 조합에 중점을 둡니다. 실제 보안 연결은 함께 사용하는 전송 계층과 암호화 설정에 따라 달라집니다. Trojan은 일반적으로 TLS를 통해 연결을 전송합니다. Hysteria2와 TUIC는 QUIC 방식에 기반하고 주로 UDP를 사용하므로 패킷 손실이나 대역폭 변화가 있는 환경에서 기존 TCP 전송과 다른 성능을 보일 수 있지만, 현지 네트워크가 UDP를 정상적으로 지원하는지에 더 크게 의존합니다.
따라서 Hysteria2나 TUIC 노드라고 해서 반드시 더 빠르다고 단정할 수 없습니다. 접속 네트워크가 UDP를 제한하면 연결이 실패하거나 불안정해질 수 있습니다. 이때는 같은 노드의 설정을 반복해서 조정하기보다 정상적으로 작동하는 TCP 계열 전송으로 바꾸는 편이 효과적일 수 있습니다. 반대로 UDP 경로가 양호한 환경에서는 이러한 프로토콜이 변동에 민감한 작업에 더 적합할 수 있습니다. 최종 판단은 대상 애플리케이션의 실제 성능을 기준으로 해야 합니다.
구독 가져오기와 업데이트
일반적인 과정은 사용자 패널에서 구독 링크를 복사한 뒤 클라이언트에서 ‘URL에서 가져오기’ 또는 유사한 메뉴를 선택하고 저장한 다음 업데이트를 실행하는 것입니다. 가져오기가 성공했다는 것은 클라이언트가 설정을 읽었다는 뜻일 뿐, 현재 네트워크에서 모든 노드를 사용할 수 있다는 의미는 아닙니다. 업데이트에 실패하면 먼저 링크가 완전한지, 클라이언트가 해당 구독 형식을 지원하는지, 시스템 시간이 정확한지 확인하세요.
- 사용자 패널에서 구독 링크를 가져오고 공개 페이지를 통한 중계는 피하세요.
- 클라이언트에 원격 구독을 추가한 뒤 한 번 업데이트하세요.
- 용도에 맞는 지역과 회선 유형을 선택하세요.
- 시스템 프록시 또는 가상 네트워크 인터페이스 모드를 활성화하고 대상 애플리케이션이 인계되었는지 확인하세요.
- 출구 IP, DNS 결과와 실제 작업 성능을 점검하세요.
플랫폼별 클라이언트 차이
같은 구독도 플랫폼에 따라 성능이 달라질 수 있습니다. 보통 노드가 바뀐 것이 아니라 시스템 네트워크 인터페이스, 백그라운드 제한과 클라이언트 기능이 다르기 때문입니다. 회선을 선택할 때는 클라이언트의 작동 모드도 함께 확인해야 합니다.
Windows와 macOS
데스크톱 클라이언트는 일반적으로 시스템 프록시와 가상 네트워크 인터페이스라는 두 가지 트래픽 인계 방식을 제공합니다. 시스템 프록시는 시스템 설정을 따르는 애플리케이션에 주로 영향을 줍니다. 일부 게임, 명령줄 프로그램이나 자체 네트워크 스택을 사용하는 소프트웨어는 이를 거치지 않을 수 있습니다. 가상 네트워크 인터페이스 모드는 더 많은 트래픽을 인계할 수 있지만 라우팅, DNS와 현지 네트워크 접근을 올바르게 처리해야 합니다.
macOS에서는 시스템 확장과 네트워크 권한이 가상 네트워크 인터페이스 생성에 영향을 줄 수 있으며, Windows에서는 방화벽, 오래된 프록시 설정이나 다른 네트워크 도구가 충돌을 일으킬 수 있습니다. ‘브라우저는 되는데 다른 앱은 안 되는’ 경우에는 원격 회선을 바로 바꾸기보다 먼저 해당 앱이 프록시를 사용하는지 판단하세요.
iOS와 Android
모바일 운영체제는 일반적으로 시스템 VPN 인터페이스를 통해 트래픽을 인계합니다. 절전 정책, 백그라운드 활동 제한과 무선 네트워크·모바일 네트워크 간 전환으로 터널이 다시 연결될 수 있습니다. Android는 클라이언트마다 앱별 프록시, 로컬 네트워크 우회와 비공개 DNS 처리 방식이 다르며, iOS 클라이언트는 시스템 네트워크 확장 기능의 제약을 받습니다.
모바일에서 회선을 테스트할 때는 대상 앱 안에서 전체 작업을 완료하고, 백그라운드로 전환했다가 돌아온 뒤에도 연결이 유효한지 확인하세요. 클라이언트 화면에 ‘연결됨’이라고 표시되는 것만으로 대상 앱의 요청이 예상한 출구를 사용한다고 볼 수는 없습니다.
DNS 누출과 분할 라우팅 규칙 점검
DNS는 도메인 이름을 네트워크 주소로 변환합니다. 업무 트래픽은 프록시를 통과하는데 DNS 조회는 현지 네트워크가 계속 처리하면 DNS 누출이나 지역 판정 불일치가 발생할 수 있습니다. 누출이 항상 페이지 접속 불가로 이어지는 것은 아니지만 콘텐츠 권역 오류, 현재 출구에 맞지 않는 서버로의 해석 또는 분할 라우팅 규칙이 예상대로 적용되지 않는 문제가 생길 수 있습니다.
처리 방법은 클라이언트에 따라 다릅니다. 가상 네트워크 인터페이스 모드는 일반적으로 DNS를 한곳에서 인계할 수 있지만, 클라이언트가 사용하는 조회 방식을 여전히 확인해야 합니다. 시스템 프록시 모드에서는 브라우저의 보안 DNS 설정, 운영체제 확인자와 클라이언트의 원격 조회 옵션이 동시에 작동할 수 있습니다. 여러 DNS 방식을 무작정 겹쳐 사용하면 문제를 찾기 더 어려워집니다.
- ✅ 연결 후 출구 IP의 국가 또는 지역이 선택한 회선과 일치하는지 확인하세요.
- ✅ DNS 테스트 결과에 현지 접속망과 맞지 않는 예상 밖의 조회 서버가 나타나는지 확인하세요.
- ✅ 현지 웹사이트는 규칙에 따라 직결되고 대상 국제 서비스는 예상한 출구를 통과하는지 검증하세요.
- ✅ 규칙을 수정한 후 다시 연결하고 대상 애플리케이션이 세션을 새로 만들도록 하세요.
- ❌ 시스템 프록시, 라우팅 또는 DNS를 변경하는 클라이언트를 여러 개 동시에 실행하지 마세요.
분할 라우팅 규칙은 일반적으로 도메인, IP 범위, 애플리케이션 또는 규칙 모음에 따라 트래픽의 방향을 결정합니다. 도메인 규칙은 직관적이지만 일부 앱은 IP에 직접 연결합니다. IP 규칙은 적용 범위가 넓지만 지속적인 관리가 필요합니다. 앱별 분할은 모바일과 특정 데스크톱 클라이언트에 적합하지만 모든 플랫폼이 지원하는 것은 아닙니다. 규칙은 이해하고 재현할 수 있는지를 기준으로 선택해야 하며, 복잡할수록 반드시 정확한 것은 아닙니다.
반복 가능한 회선 테스트 방법
회선 테스트의 목표는 일회성 속도 순위를 만드는 것이 아니라 현재 접속 네트워크와 대상 작업에서 반복적으로 사용할 수 있는 주 회선과 예비 회선을 찾는 것입니다. 테스트할 때는 기기, 네트워크와 대상 서비스를 최대한 동일하게 유지하고 한 번에 하나의 변수만 바꾸세요.
- 먼저 대상 서비스에 맞춰 출구 지역을 정하고 지역이 맞지 않는 노드를 제외하세요.
- 같은 지역에서 직결, 중계 또는 IEPL 후보를 각각 선택하고 서로 다른 출구를 섞어 비교하지 마세요.
- 클라이언트 작동 모드를 동일하게 유지하세요. 한 번은 시스템 프록시를, 다음에는 가상 네트워크 인터페이스를 사용하는 일이 없도록 합니다.
- 대상 웹사이트를 열고 실제 작업을 완료하면서 연결 설정, 지속 전송과 세션 복구를 관찰하세요.
- 출구 IP와 DNS를 확인해 트래픽이 예상한 경로를 실제로 사용했는지 검증하세요.
- 안정적으로 작동하는 주 회선을 남기고, 같은 지역에서 진입 지점이나 경로가 다른 예비 회선을 선택하세요.
모든 후보 회선에 동시에 문제가 생겼다면 노드를 하나씩 끝없이 바꾸기보다 현지 네트워크, 클라이언트 상태와 구독 업데이트를 먼저 확인하세요. 특정 지역만 문제가 있다면 해당 지역의 다른 진입 지점을 비교하고, 특정 앱만 문제가 있다면 분할 라우팅, DNS와 앱의 시스템 프록시 준수 여부를 중점적으로 확인하세요.
최종 선택 규칙
회선 선택은 고정된 절차로 정리할 수 있습니다. 먼저 용도로 출구 지역을 정하고, 현지 네트워크에 따라 경로 유형을 선택한 다음, 클라이언트·DNS와 실제 작업으로 검증합니다. 지역은 ‘어디에서 접속하는가’를, 회선 유형은 ‘어떻게 도달하는가’를, 프로토콜과 클라이언트는 ‘연결을 어떻게 전달하는가’를 해결하며, 분할 라우팅 규칙은 ‘어떤 트래픽이 이 회선을 거치는가’를 결정합니다.
동영상을 볼 때는 먼저 콘텐츠 지역을 맞춘 뒤 지속 재생을 테스트하세요. AI 도구를 사용할 때는 자주 쓰는 출구 지역을 고정하고 같은 지역의 예비 회선을 남겨 두세요. 일상 브라우징에서는 가까우면서 라우팅이 안정적인 출구를 우선 선택하고 분할 라우팅을 간단하게 유지하세요. 직결은 공용망 경로가 양호한 환경에, 중계는 진입 지점과 원격 출구 사이의 라우팅 개선에, IEPL은 지역 간 경로 제어를 중시하는 상황에 적합할 수 있지만 세 방식 모두 실제 검증이 필요합니다.
실제로 유효한 회선 선택 결과는 영원히 변하지 않는 순위표가 아니라 명확한 대응 관계의 집합입니다. 특정 지역은 특정 서비스에 사용하고, 특정 경로는 주 회선으로, 같은 지역의 다른 경로는 예비 회선으로 정하는 방식입니다. 네트워크 환경이 바뀌면 이 관계만 다시 확인하면 되며, 모든 노드에서 처음부터 다시 시작할 필요는 없습니다.