윈도우에서 VPN을 사용할 때 모든 프로그램을 같은 터널로 보내야 하는 것은 아닙니다. 분할 터널링을 사용하면 특정 앱만 VPN을 통과시키고, 나머지 앱은 일반 인터넷 연결을 유지하도록 나눌 수 있습니다. 예를 들어 브라우저의 업무용 창은 VPN으로 연결하면서 로컬 메신저, 프린터 관리 도구 또는 사내 장치 검색은 일반 네트워크에 남겨 둘 수 있습니다.

다만 분할 터널링은 단순히 “앱 이름을 선택하는 기능”만을 뜻하지 않습니다. 클라이언트가 어떤 방식으로 트래픽을 가르는지에 따라 결과가 달라집니다. 공식 윈도우 클라이언트는 앱 제외 또는 앱 포함 목록을 제공할 수 있고, Clash Verge나 sing-box는 규칙과 TUN 모드, 프로세스 식별자를 조합하는 경우가 많습니다. 따라서 메뉴 이름보다 현재 모드, DNS 처리 방식, IPv6 동작과 실제 연결 경로를 함께 확인해야 합니다.

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

일반적인 전체 터널 모드에서는 윈도우의 기본 경로가 VPN 가상 어댑터를 향하도록 변경됩니다. 앱이 직접 지정한 경로가 없다면 대부분의 외부 연결이 VPN을 거치게 됩니다. 반대로 분할 터널링은 특정 앱의 프로세스, 목적지 주소, 포트 또는 도메인을 기준으로 일부 트래픽만 VPN 인터페이스로 보냅니다.

앱 기준 분할에는 보통 두 가지 방향이 있습니다. 첫째는 “선택한 앱만 VPN 사용” 방식입니다. 업무 브라우저나 특정 개발 도구처럼 VPN이 필요한 프로그램만 목록에 추가하고 나머지는 일반 연결로 둡니다. 둘째는 “선택한 앱은 VPN 제외” 방식입니다. 기본적으로 모든 트래픽을 VPN으로 보내되, 로컬 서비스나 호환성 문제가 있는 프로그램만 제외합니다. 같은 앱 목록이라도 클라이언트의 기본 정책이 무엇인지에 따라 결과가 정반대가 될 수 있습니다.

2

대표적인 앱 정책

5

지원 운영체제

100+

국가 커버리지

160+

회선 수

또 하나 중요한 구분은 라우팅과 DNS입니다. 앱의 IP 연결은 일반 네트워크로 빠졌는데 도메인 조회만 VPN DNS를 사용하는 구성도 있고, 그 반대도 가능합니다. 이런 불일치는 지역 기반 서비스, 사내 도메인, 로컬 장치 검색에서 예상하지 못한 결과를 만들 수 있습니다. 특히 TUN 모드에서는 클라이언트가 시스템 네트워크 계층에서 트래픽을 가로채므로 시스템 프록시만 설정했을 때와 동작 범위가 다릅니다.

  • ✅ 먼저 현재 모드가 전체 터널인지 선택 앱 전용인지 확인합니다.
  • ✅ 앱 이름이 아니라 실제 실행 파일과 하위 프로세스를 확인합니다.
  • ✅ VPN 대상 앱과 일반 연결 앱을 각각 하나씩 정해 테스트합니다.
  • ✅ DNS와 IPv6가 앱 규칙과 같은 방향으로 처리되는지 점검합니다.
  • ❌ 분할 터널링을 켰다는 표시만 보고 실제 트래픽 경로가 바뀌었다고 단정하지 않습니다.
  • ❌ 두 개의 VPN 클라이언트와 여러 TUN 모드를 동시에 활성화하지 않습니다.
핵심 결론: 분할 터널링은 앱 목록보다 “어떤 정책이 우선 적용되는가”가 중요합니다. 포함 모드인지 제외 모드인지 확인한 뒤 DNS와 TUN 동작까지 함께 검증해야 합니다.

공식 윈도우 클라이언트에서 앱 규칙 설정하기

공식 윈도우 클라이언트를 사용하는 경우 먼저 로그인하고 서버 또는 구독 설정을 정상적으로 불러온 뒤 연결을 종료한 상태에서 분할 터널링 메뉴를 찾는 편이 안전합니다. 메뉴는 클라이언트 버전에 따라 “Split tunneling”, “앱별 라우팅”, “애플리케이션 예외”, “VPN에서 제외할 앱”처럼 다르게 표시될 수 있습니다. 같은 윈도우라도 클라이언트가 제공하는 기능이 다르므로 메뉴 이름만으로 지원 여부를 판단하지 마세요.

설정 순서는 다음과 같이 진행하면 됩니다. 첫째, 분할 터널링 기능을 활성화합니다. 둘째, 선택한 앱만 VPN을 사용할지 또는 선택한 앱을 VPN에서 제외할지 정책을 정합니다. 셋째, 앱 추가 버튼을 눌러 실행 파일을 지정합니다. 넷째, 저장 또는 적용을 누른 뒤 VPN 연결을 새로 시작합니다. 일부 클라이언트는 연결 중 규칙 변경을 허용하지만, 기존 소켓이 이전 경로를 유지할 수 있으므로 연결을 끊었다가 다시 연결하는 것이 결과를 확인하기 쉽습니다.

앱을 추가할 때 바로 가기 아이콘의 이름만 보지 말고 실행 파일의 실제 경로를 확인하세요. 브라우저는 업데이트 후 실행 파일 위치가 바뀌거나, 본체와 업데이트 프로세스가 별도로 동작할 수 있습니다. 게임 런처, 메신저, 개발 도구도 하나의 프로그램처럼 보이지만 로그인, 업데이트, 콘텐츠 요청을 서로 다른 하위 프로세스가 처리할 수 있습니다. 클라이언트가 하위 프로세스를 자동으로 포함하지 않는다면 관련 실행 파일을 별도로 등록해야 합니다.

설정 방식 적합한 상황 주의할 점
선택 앱만 VPN 업무 브라우저나 특정 도구만 보호된 경로가 필요할 때 목록에 빠진 하위 프로세스는 일반 연결을 사용함
선택 앱 VPN 제외 대부분의 트래픽은 VPN으로 보내고 일부 로컬 앱만 우회할 때 새로 실행한 앱이 의도치 않게 VPN을 사용할 수 있음
도메인 또는 IP 규칙 특정 서비스 주소만 경로를 나누고 싶을 때 주소 변경, CDN, DNS 응답에 따라 결과가 달라질 수 있음
TUN 기반 규칙 시스템 프록시를 사용하지 않는 앱까지 라우팅해야 할 때 가상 어댑터, DNS, 관리자 권한 충돌을 점검해야 함

공식 클라이언트에서 앱을 선택할 수 없거나 분할 터널링 항목이 보이지 않는다면 해당 버전이 기능을 제공하지 않는 것일 수 있습니다. 이때 윈도우 방화벽 규칙을 무작정 추가해 대체하려고 하면 연결 차단과 DNS 누수가 섞여 원인 파악이 어려워질 수 있습니다. 필요한 기능이 클라이언트에 없다면 규칙 기반 클라이언트의 사용 가능 여부와 조직의 보안 정책을 먼저 확인하세요.

Clash Verge와 sing-box에서 프로세스 규칙 다루기

Clash Verge 계열 클라이언트는 일반적으로 글로벌, 규칙, 직접 연결과 같은 모드를 제공하며, TUN을 켜면 시스템 전체의 IP 트래픽을 가상 인터페이스에서 처리할 수 있습니다. 이때 “앱별 분할”은 공식 VPN 앱의 단순 예외 목록과 다르게 작동합니다. 도메인, IP 대역, 국가 데이터베이스, 프로세스 이름 등 여러 조건을 순서대로 평가해 프록시 또는 DIRECT를 선택하는 구조입니다.

Clash 규칙에서는 먼저 처리되는 규칙이 우선될 수 있으므로 구체적인 프로세스 규칙을 넓은 최종 규칙보다 앞에 두어야 합니다. 예를 들어 특정 메신저를 직접 연결하려면 해당 프로세스 또는 도메인 규칙을 추가한 뒤, 마지막에 남은 트래픽을 프록시로 보내는 정책을 배치합니다. 반대로 특정 브라우저만 프록시로 보내려면 브라우저의 프로세스 이름을 지정하고 나머지를 DIRECT로 처리하는 구성이 더 명확합니다.

sing-box도 TUN과 라우팅 규칙을 기반으로 프로세스 이름, 목적지 도메인, IP, 포트 등을 조합할 수 있습니다. 설정 파일을 직접 수정하는 경우 JSON 구조의 쉼표와 중괄호, 규칙 순서를 먼저 확인하고 한 번에 많은 조건을 바꾸지 마세요. GUI가 제공하는 편집 기능이 있다면 작은 변경을 저장한 뒤 연결을 재시작하고 결과를 확인하는 방식이 안전합니다.

Shadowrocket은 주로 모바일 환경에서 사용되는 클라이언트이므로 윈도우 앱별 규칙을 직접 설정하는 도구로 보기는 어렵습니다. 윈도우에서는 공식 클라이언트, Clash Verge, sing-box 등 현재 운영체제에서 TUN 또는 앱별 라우팅을 지원하는 클라이언트를 선택해야 합니다. 여러 클라이언트를 동시에 켜면 가상 어댑터와 기본 경로가 서로 경쟁할 수 있으므로 테스트할 때는 하나만 활성화하세요.

설정 후 실제 적용 상태 확인하기

규칙을 저장한 뒤에는 앱을 닫고 다시 실행해야 합니다. 이미 열린 브라우저 탭이나 메신저 연결은 기존 소켓을 계속 사용할 수 있기 때문입니다. 먼저 VPN 대상 앱을 실행하고 외부 주소 확인 페이지나 서비스의 연결 상태 화면에서 출구 지역과 연결 상태를 확인합니다. 그다음 VPN 제외 앱에서도 같은 검사를 하되, 결과가 달라지는 것이 의도한 구성인지 판단해야 합니다. 모든 앱이 같은 결과를 보여야 정상인 것은 아닙니다.

라우팅 확인은 한 가지 방법만으로 끝내지 않는 것이 좋습니다. 브라우저 요청은 프록시를 사용하지만 다른 앱은 직접 UDP 연결을 할 수 있고, DNS 요청은 별도의 경로를 사용할 수 있습니다. 따라서 웹페이지 접속, 앱 로그인, 파일 요청, 로컬 장치 접근처럼 실제 사용 동작을 나누어 확인하세요. 업무용 브라우저만 VPN으로 보내고 프린터 관리 도구는 직접 연결하는 구성이라면 두 기능을 각각 실행해야 합니다.

  • ✅ VPN 대상 앱을 완전히 종료한 뒤 다시 실행합니다.
  • ✅ VPN 대상 앱과 제외 앱의 공인 출구 또는 서비스 응답을 각각 비교합니다.
  • ✅ DNS 조회가 어느 경로를 사용하는지 클라이언트 로그에서 확인합니다.
  • ✅ 웹 요청뿐 아니라 로그인, 다운로드, 로컬 장치 접근도 시험합니다.
  • ❌ 연결 아이콘만 보고 앱별 규칙이 실제로 적용되었다고 판단하지 않습니다.
  • ❌ 회사 내부 주소나 개인 계정 정보를 공개 진단 사이트에 입력하지 않습니다.

윈도우의 작업 관리자에서 프로세스가 여러 개로 나뉘는지도 확인할 수 있습니다. 브라우저 본체가 프록시를 사용하더라도 업데이트 서비스나 확장 프로그램의 별도 요청은 다른 경로로 나갈 수 있습니다. 또한 IPv6를 지원하는 네트워크에서는 IPv4만 VPN으로 보내고 IPv6는 일반 연결에 남는 구성이 생길 수 있습니다. 클라이언트가 IPv6를 처리하지 못한다면 비활성화 여부나 누수 방지 옵션을 확인하되, 네트워크 환경에 맞지 않는 설정을 무리하게 변경하지 마세요.

검증 기준: 연결 성공 여부보다 “어떤 앱의 어떤 요청이 어느 경로로 나갔는가”를 확인해야 합니다. 앱 재실행, DNS, IPv4·IPv6와 하위 프로세스를 함께 점검하면 오판을 줄일 수 있습니다.

문제가 생겼을 때 원인을 좁히고 되돌리는 방법

분할 터널링을 적용한 뒤 인터넷이 끊기면 먼저 모든 규칙을 삭제하기보다 최근에 추가한 앱 하나를 비활성화해 보세요. 문제가 사라지면 규칙 대상이나 정책 방향이 원인일 가능성이 큽니다. 그다음 VPN 연결을 끊고 클라이언트를 종료한 뒤 다시 시작합니다. 윈도우의 네트워크 어댑터 목록에 남은 TUN 가상 어댑터가 있다면 클라이언트가 안내하는 정상적인 복구 절차를 따르고, 임의로 시스템 파일이나 레지스트리를 수정하지 않는 편이 안전합니다.

앱은 열리지만 특정 기능만 실패한다면 도메인과 하위 도메인, UDP 사용 여부, DNS 응답을 확인해야 합니다. 로그인 페이지와 API 주소가 서로 다르거나, 본체는 TCP를 사용하면서 통화 기능은 UDP를 사용하는 서비스도 있습니다. 이 경우 앱 전체를 DIRECT 또는 프록시로 바꾸기 전에 필요한 도메인과 프로토콜 범위를 파악하세요. 규칙을 넓게 만들수록 편리하지만 예외가 많아지고 보안 경계가 흐려집니다.

가장 안전한 되돌리기 순서는 분할 터널링을 끄고, VPN 연결을 종료한 다음, 클라이언트를 재시작하는 것입니다. 이후에도 문제가 남으면 시스템 프록시가 켜져 있는지, 윈도우 기본 프록시 설정이 남아 있는지, 다른 VPN이나 방화벽 프로그램이 실행 중인지 확인합니다. 마지막으로 네트워크를 재연결하고 일반 인터넷이 정상인지 확인한 뒤 규칙을 하나씩 다시 추가하세요.

증상 가능한 원인 우선 조치
모든 앱이 연결되지 않음 TUN 충돌, 잘못된 기본 규칙 또는 가상 어댑터 문제 VPN을 끄고 클라이언트를 재시작한 뒤 규칙을 최소화함
한 앱만 로그인 실패 하위 프로세스, DNS 또는 필요한 도메인 누락 앱의 모든 프로세스와 관련 도메인을 확인함
로컬 프린터가 보이지 않음 로컬 대역이 VPN으로 전달되거나 직접 연결 규칙이 없음 로컬 주소 대역을 직접 연결 정책으로 점검함
설정 후에도 결과가 같음 기존 세션, 잘못된 프로세스 이름 또는 규칙 순서 문제 앱을 완전히 종료하고 로그와 규칙 우선순위를 확인함

안전한 운영을 위한 FAQ

분할 터널링을 켜면 모든 앱이 자동으로 빨라지나요?

그렇지는 않습니다. VPN에서 제외한 앱은 일반 네트워크를 사용하므로 해당 경로가 더 적합할 때 응답이 개선될 수 있지만, 네트워크 품질이나 서버 상태가 자동으로 좋아지는 것은 아닙니다. VPN이 필요한 앱만 선택하고, 실제 기능별로 결과를 비교해야 합니다.

브라우저 하나만 등록하면 모든 브라우저 요청이 VPN으로 가나요?

클라이언트가 프로세스와 하위 프로세스를 함께 처리하는지에 따라 다릅니다. 브라우저 본체, 업데이트 서비스, 별도 런처가 나뉘어 있을 수 있으므로 클라이언트 로그와 작업 관리자에서 실제 프로세스를 확인하세요. 확장 프로그램의 요청도 브라우저 본체와 같은 경로를 사용한다고 단정해서는 안 됩니다.

TUN 모드를 꼭 사용해야 하나요?

시스템 프록시를 따르지 않는 앱까지 규칙을 적용해야 한다면 TUN이 필요할 수 있습니다. 반면 브라우저처럼 프록시 설정을 잘 따르는 앱만 대상으로 한다면 시스템 프록시 기반 구성이 더 단순할 수 있습니다. TUN은 편리하지만 관리자 권한, 가상 어댑터, DNS와 IPv6까지 함께 관리해야 하므로 필요한 경우에만 사용하세요.

설정을 잘못했을 때 가장 빠른 복구 방법은 무엇인가요?

최근 규칙을 먼저 비활성화하고 분할 터널링을 끈 다음 VPN 연결을 종료합니다. 클라이언트를 재시작하고 일반 네트워크가 복구되었는지 확인한 뒤, 필요한 앱 하나만 다시 등록하세요. 여러 규칙과 클라이언트를 동시에 변경하면 원인을 찾기 어려우므로 한 번에 한 항목만 바꾸는 것이 좋습니다.

최종 정리: 윈도우 분할 터널링은 선택 앱, 예외 앱, TUN 규칙 중 현재 클라이언트가 어떤 방식을 사용하는지 파악하는 데서 시작합니다. 규칙을 작게 만들고 앱을 재실행한 뒤 DNS와 실제 출구를 확인하면 안정적으로 운영할 수 있습니다.