윈도우 VPN 분할 터널링은 모든 프로그램의 트래픽을 한 번에 VPN으로 보내는 대신, 지정한 앱이나 도메인만 터널을 통과하도록 구성하는 방식입니다. 업무용 브라우저, 원격 협업 도구, 특정 해외 서비스는 VPN으로 연결하고, 온라인 뱅킹이나 사내 시스템처럼 기존 네트워크에서 접속해야 하는 서비스는 일반 인터넷으로 남겨둘 수 있습니다.

다만 분할 터널링은 단순히 “VPN을 켜고 끄는 기능”과 다릅니다. 클라이언트가 애플리케이션별 규칙을 해석하는지, Windows 시스템 프록시를 사용하는지, 자체 가상 네트워크 어댑터로 트래픽을 처리하는지에 따라 결과가 달라집니다. 따라서 설정 전에 사용할 클라이언트와 트래픽 범위를 먼저 정하고, 연결 후에는 IP 주소뿐 아니라 DNS와 실제 애플리케이션 동작까지 확인해야 합니다.

분할 터널링의 작동 방식 이해하기

전체 터널 모드에서는 Windows에서 발생하는 대부분의 네트워크 요청이 VPN 인터페이스를 향합니다. 반면 분할 터널링에서는 라우팅 규칙에 따라 트래픽의 경로가 달라집니다. 특정 실행 파일을 VPN으로 보낼 수도 있고, 특정 도메인이나 IP 대역만 VPN에 포함할 수도 있으며, 반대로 VPN을 사용하지 않을 앱을 예외 목록으로 지정할 수도 있습니다.

애플리케이션 기반 규칙은 보통 실행 파일 이름을 기준으로 적용됩니다. 예를 들어 웹 브라우저의 실행 파일을 VPN 대상으로 지정하면 해당 브라우저의 연결은 터널로 이동할 수 있습니다. 그러나 브라우저가 별도의 업데이트 프로세스, 백그라운드 서비스 또는 샌드박스 프로세스를 사용하는 경우에는 메인 실행 파일만 등록해도 모든 요청이 같은 경로를 따르지 않을 수 있습니다.

도메인 기반 규칙은 서비스 주소를 기준으로 판단합니다. 한 서비스가 여러 도메인과 콘텐츠 전송 네트워크를 사용하면 대표 도메인 하나만 추가해서는 로그인, 이미지, API 또는 파일 다운로드가 정상적으로 처리되지 않을 수 있습니다. 반대로 너무 넓은 도메인 규칙을 만들면 원하지 않는 트래픽까지 VPN으로 넘어가 데이터 사용량과 연결 복잡성이 커질 수 있습니다.

90+

국가 커버리지

200+

회선 수

무제한

동시 온라인 기기

5

지원 플랫폼

VPN 서비스의 회선 수가 많아도 분할 규칙이 자동으로 완성되는 것은 아닙니다. 출구 지역 선택은 어느 서버로 나갈지를 결정하고, 분할 터널링은 어떤 트래픽을 그 서버로 보낼지를 결정합니다. 두 설정은 서로 다른 단계이므로 원하는 앱이 VPN으로 연결되지 않을 때는 먼저 규칙 대상과 출구 회선을 각각 확인해야 합니다.

한 줄 결론: 분할 터널링은 VPN 회선을 선택하는 기능이 아니라 트래픽의 이동 경로를 나누는 기능입니다. 출구 지역과 앱 규칙을 따로 점검해야 원인을 정확히 찾을 수 있습니다.

Windows 클라이언트 선택과 규칙 지원 범위

Windows에서 사용할 수 있는 클라이언트는 크게 공식 클라이언트, Clash Verge와 같은 규칙형 클라이언트, sing-box 기반 클라이언트로 나누어 생각할 수 있습니다. 공식 클라이언트는 설치와 구독 가져오기가 비교적 간단하고 기본 연결을 빠르게 확인하기 좋습니다. 하지만 버전에 따라 앱별 우회 또는 포함 규칙의 세부 조작 범위가 다를 수 있으므로, 설정 화면에 실제로 어떤 모드가 제공되는지 확인해야 합니다.

Clash Verge 계열은 도메인, IP, 프로세스와 규칙 그룹을 조합하는 방식에 적합합니다. 다만 Windows에서 앱 이름을 규칙에 넣는 방법은 사용 중인 코어와 모드에 따라 달라질 수 있습니다. sing-box는 라우팅 규칙을 더 세밀하게 구성할 수 있지만, JSON 형식과 DNS, 인터페이스 설정을 함께 이해해야 하므로 처음부터 복잡한 구성을 복사하는 것은 권장하지 않습니다.

구독 링크를 가져올 때는 클라이언트가 해당 구독 형식을 지원하는지 먼저 확인하세요. 같은 구독이라도 공식 클라이언트, Clash Verge, sing-box에서 표시되는 노드 이름과 규칙 구조가 다를 수 있습니다. Shadowsocks, VMess, Trojan, Hysteria2 같은 프로토콜은 연결 방식의 차이를 나타내며, 이 이름만으로 앱별 라우팅이 자동으로 제공된다고 볼 수는 없습니다.

  • ✅ 공식 클라이언트는 먼저 기본 연결과 구독 갱신이 정상인지 확인합니다.
  • ✅ Clash Verge는 규칙 모드와 글로벌 모드를 구분한 뒤 앱 또는 도메인 규칙을 추가합니다.
  • ✅ sing-box는 라우팅 대상, DNS 경로와 최종 출구를 함께 확인합니다.
  • ❌ 서로 다른 VPN 클라이언트를 동시에 실행해 가상 어댑터를 겹치게 하지 않습니다.
  • ❌ 실행 파일 이름만 보고 자식 프로세스까지 모두 VPN에 포함된다고 가정하지 않습니다.

Windows에서 앱별 규칙 설정하기

설정 전에는 테스트할 앱을 하나 정하세요. 일반적으로 브라우저처럼 결과를 확인하기 쉬운 프로그램이 좋습니다. 업무용 메신저나 파일 동기화 프로그램부터 적용하면 백그라운드 연결이 많아 문제 범위를 파악하기 어려울 수 있습니다. 또한 현재 Windows 프록시 설정, 다른 VPN, 보안 프로그램의 네트워크 보호 기능이 켜져 있는지도 확인하세요.

1단계: 기본 상태 기록하기

VPN을 연결하기 전에 테스트 앱을 실행하고 접속 상태를 확인합니다. 웹 브라우저라면 IP 확인 페이지와 일반 웹사이트를 각각 열어보고, 업무 프로그램이라면 로그인과 주요 기능이 정상인지 기록하세요. 이 과정은 빠른 속도를 측정하려는 것이 아니라 VPN 적용 전과 후의 경로 차이를 비교하기 위한 기준을 만드는 단계입니다.

2단계: 분할 모드와 앱 규칙 선택하기

클라이언트에서 분할 터널링, 규칙 모드, 앱 우회 또는 선택적 연결과 비슷한 메뉴를 찾습니다. 표현은 클라이언트마다 다르지만 기본 원리는 두 가지입니다. 지정한 앱만 VPN으로 보내는 포함 방식과, 전체를 VPN으로 보낸 뒤 지정한 앱을 제외하는 우회 방식입니다. 처음 구성할 때는 대상이 명확한 포함 방식을 우선하는 편이 실수를 줄일 수 있습니다.

앱을 등록할 때는 바로 가기 아이콘이 아니라 실제 실행 파일 경로를 확인하세요. 동일한 프로그램이 일반 실행 파일과 업데이트 실행 파일을 별도로 사용하는 경우도 있습니다. 규칙을 저장한 뒤 앱을 완전히 종료하고 다시 실행해야 새 경로가 적용되는 클라이언트도 있으므로, 트레이 영역에 남은 프로세스까지 종료한 후 재시작하는 것이 안전합니다.

3단계: 출구 회선과 규칙 적용

앱 규칙이 연결될 프록시 그룹이나 출구 회선을 선택합니다. 특정 국가나 지역이 필요한 서비스라면 노드 이름만 믿지 말고 연결 후 실제 출구 IP의 지역을 확인해야 합니다. 회선 이름은 예상 위치와 유형을 설명할 수 있지만, 프로토콜이나 이름만으로 현재 경로가 확정되는 것은 아닙니다.

규칙을 적용한 후에는 대상 앱만 VPN 경로를 사용하고, 다른 앱은 기존 네트워크를 유지하는지 비교합니다. 브라우저를 두 개 사용한다면 한쪽만 규칙에 넣어 차이를 확인할 수 있습니다. 단, 브라우저가 운영체제 프록시 설정을 공유하는 경우에는 앱별 구분이 기대와 다르게 나타날 수 있습니다.

4단계: DNS와 시스템 프록시 점검

웹페이지가 열리는 것만으로 분할 설정이 완성되었다고 판단하면 안 됩니다. DNS 요청은 VPN으로 보내면서 실제 연결은 일반 회선을 사용할 수도 있고, 그 반대도 가능합니다. 클라이언트가 DNS를 별도로 처리하는지, Windows의 시스템 프록시를 변경하는지, 브라우저가 자체 보안 DNS를 사용하는지 확인해야 합니다.

특히 일반 인터넷으로 남겨야 하는 업무 시스템이 간헐적으로 연결되지 않는다면 DNS 규칙과 로컬 네트워크 경로를 먼저 살펴보세요. 사내 주소가 내부 DNS에서만 해석되는 환경에서는 모든 DNS 요청을 외부로 보내는 구성이 오히려 접속을 방해할 수 있습니다.

  1. VPN을 연결하고 대상 앱을 완전히 다시 시작합니다.
  2. 대상 앱에서 IP 또는 지역 확인 결과를 확인합니다.
  3. VPN 제외 앱에서 같은 확인을 반복합니다.
  4. 대상 앱의 로그인, 파일 요청과 주요 기능을 실제로 실행합니다.
  5. VPN을 끈 뒤 두 앱이 원래 경로로 돌아오는지 확인합니다.

설정 후 검증과 오류 복구

검증은 “연결됨”이라는 상태 표시보다 실제 요청 단위로 진행해야 합니다. 대상 앱의 웹페이지 하나만 열지 말고 로그인, 이미지 표시, API 요청, 파일 업로드처럼 서로 다른 연결을 사용하는 기능을 확인하세요. 특정 기능만 실패한다면 해당 기능이 별도 도메인이나 자식 프로세스를 사용하는지 확인할 수 있습니다.

VPN 대상 앱이 일반 회선으로 나가는 경우에는 규칙 모드가 실제로 활성화되었는지, 규칙 우선순위가 다른 기본 규칙에 밀리지 않았는지, 실행 파일 경로가 정확한지 순서대로 점검하세요. 도메인 규칙을 사용했다면 도메인 앞에 불필요한 오타나 잘못된 와일드카드가 없는지도 확인해야 합니다.

반대로 모든 Windows 트래픽이 VPN으로 이동한다면 글로벌 모드가 남아 있거나, 클라이언트가 시스템 전체 터널을 우선 적용하는 것일 수 있습니다. 공식 클라이언트가 앱별 규칙을 제공하지 않는다면 해당 클라이언트 안에서 무리하게 설정을 찾기보다 규칙형 클라이언트를 검토하는 편이 현실적입니다.

연결이 끊긴 뒤에도 인터넷이 복구되지 않을 때는 먼저 VPN을 정상 종료하고 클라이언트의 시스템 프록시 해제 기능을 실행합니다. 그래도 문제가 남으면 Windows 네트워크 설정에서 수동 프록시, 가상 어댑터와 사용자 지정 DNS가 남아 있는지 확인하세요. 여러 네트워크 설정을 한꺼번에 초기화하면 원인을 추적하기 어려우므로 변경한 항목부터 되돌리는 것이 좋습니다.

복구 순서: 클라이언트 규칙 해제 → 시스템 프록시 확인 → 앱 재시작 → DNS 확인 → 가상 어댑터 상태 점검 순서로 진행하면 불필요한 초기화를 줄일 수 있습니다.

규칙을 안정적으로 유지하는 방법

분할 터널링 규칙은 한 번 만들고 끝나는 설정이 아닙니다. 프로그램 업데이트로 실행 파일 경로가 바뀌거나, 서비스가 새로운 API 도메인을 추가하거나, 클라이언트의 코어가 변경되면 기존 규칙이 일부만 작동할 수 있습니다. 규칙 이름에 용도를 적고, 어떤 앱과 도메인을 대상으로 했는지 별도로 기록해두면 나중에 수정하기 쉽습니다.

규칙을 추가할 때는 반드시 한 항목씩 변경하세요. 여러 앱과 도메인을 한 번에 등록하면 어느 규칙이 연결을 개선했거나 방해했는지 알기 어렵습니다. 변경 후에는 VPN 대상 앱, 제외 앱, DNS 응답과 VPN 종료 후 복구 상태를 차례로 확인하는 것이 좋습니다.

  • ✅ 업무 서비스와 일반 인터넷을 서로 다른 테스트 항목으로 나눕니다.
  • ✅ 규칙 변경 후 앱을 완전히 재시작하고 결과를 기록합니다.
  • ✅ 출구 지역이 필요한 경우 실제 IP와 서비스 접속 결과를 함께 확인합니다.
  • ✅ 구독 갱신 후 노드 이름과 규칙 그룹이 바뀌지 않았는지 살펴봅니다.
  • ❌ 문제가 생겼을 때 모든 규칙과 네트워크 설정을 동시에 삭제하지 않습니다.

결국 좋은 분할 터널링 구성은 가장 복잡한 설정이 아니라 목적이 분명하고 되돌리기 쉬운 설정입니다. Windows 공식 클라이언트로 기본 연결을 확인한 뒤 필요한 경우 Clash Verge 또는 sing-box에서 세부 라우팅을 구성할 수 있습니다. 앱별 접속 규칙, DNS 처리 방식, 출구 회선과 Windows 프록시 상태를 함께 확인하면 업무 서비스와 일반 인터넷을 보다 예측 가능하게 나눌 수 있습니다.