분할 터널링이란 무엇인가 — VPN 앱별 라우팅의 실제 작동 방식

요약: 표준 VPN은 기기의 트래픽 100%를 암호화된 터널을 통해 라우팅합니다. 분할 터널링은 이 규칙을 의도적으로 깨뜨립니다. 터널을 우회하여 일반 연결로 직접 나가는 앱 또는 목적지를 직접 선택할 수 있습니다. 개념적으로는 단순해 보이지만, 실제 구현 방식은 운영 체제마다 상당히 다르며 프라이버시 트레이드오프를 놓치기 쉽습니다. 터널 밖으로 라우팅된 스트리밍 앱에는 여전히 실제 IP가 노출됩니다. 터널 밖으로 라우팅된 뱅킹 앱은 홈 네트워크를 통해 은행과 통신합니다 — 이 자체는 괜찮지만, 같은 앱이 우회 경로를 통해 DNS 쿼리를 보내어 의도치 않게 다른 도메인을 노출할 수 있습니다.

VPN 터널링이 실제로 하는 일 (기준선)

분할되는 것이 무엇인지 이해하려면 먼저 전체 터널이 무엇을 하는지 명확히 알아야 합니다. 기기에서 실행 중인 VPN 클라이언트는 가상 네트워크 인터페이스를 생성합니다 — Linux에서는 일반적으로 tun0 또는 wg0라고 불리며, macOS에서는 utun이고, iOS와 Android에서는 운영 체제가 앱별 확장 API를 통해 관리합니다. 그런 다음 운영 체제의 라우팅 테이블이 수정되어 기본 경로 — "다른 일치하는 경로가 없는 패킷을 이 게이트웨이로 보내라"는 규칙 — 가 물리적 Wi-Fi 또는 셀룰러 인터페이스 대신 해당 가상 인터페이스를 가리키게 됩니다.

그 시점부터 기기에서 생성되는 모든 패킷은 VPN 클라이언트에 의해 암호화되고, VPN 서버를 대상으로 하는 새 IP 헤더로 감싸진 후 물리적 인터페이스를 통해 단일 균일한 스트림으로 전송됩니다. VPN 서버는 패킷을 복호화하고 공용 인터넷의 실제 목적지로 전달하며, 응답을 받아 다시 암호화하여 되돌려 보냅니다. ISP에는 단일 IP로 향하는 암호화된 스트림만 보입니다. 목적지 웹사이트에는 사용자의 IP가 아닌 VPN 서버의 IP가 보입니다.

이것이 기본값입니다. 분할 터널링은 라우팅 테이블에 더 구체적인 경로를 추가함으로써 이 모델에 개입합니다 — "이 목적지로 가는 트래픽" 또는 "이 앱에서 생성된 트래픽에 대해서는 기본 터널 경로를 무시하고 물리적 인터페이스를 직접 사용하라"는 규칙입니다.

분할 터널링이 변경하는 것

개념적으로 분할 터널링은 네트워크 흐름에 분기점을 도입합니다. 일부 패킷은 암호화된 터널을 통과하고, 일부는 일반 인터페이스로 나갑니다. 결정은 사용자가 구성한 규칙에 따라 VPN 클라이언트가 내립니다. 분할 규칙에는 세 가지 일반적인 범주가 있습니다:

앱 기반 — "Netflix의 모든 트래픽은 터널 밖으로 보내고 나머지는 터널링한다." 발신 프로세스의 UID 또는 PID로 패킷에 태그를 붙인 후 태그별로 라우팅 결정을 내려 구현합니다.
목적지 기반 — "10.0.0.0/8로 가는 트래픽은 터널 밖으로 보내 홈 NAS에 접근하고 나머지는 터널링한다." 라우팅 테이블 항목만으로 구현하는 가장 단순한 방식입니다.
URL 또는 도메인 기반 — "*.bank.com으로 가는 트래픽은 터널 밖으로 보낸다." OS 라우팅 레이어는 기본적으로 도메인을 알지 못하기 때문에 취약합니다. VPN 클라이언트가 DNS를 가로채서 응답을 재작성하거나 DNS 해석을 따르는 동적 IP 허용 목록을 유지해야 합니다. 벤더마다 구현이 일관되지 않습니다.

아키텍처 구조를 단순화하면 다음과 같습니다:

전체 터널 (분할 없음):
  [앱 A] -> [앱 B] -> [앱 C]
        \        |        /
         [가상 VPN 인터페이스]
                 |
         [암호화된 터널]
                 |
         [VPN 서버] -> 인터넷

분할 터널 (앱 기반, 앱 C 제외):
  [앱 A] -> [앱 B]        [앱 C]
        \        /               \
   [가상 VPN 인터페이스]   [물리적 Wi-Fi]
              |                    |
       [암호화된 터널]    [일반 인터넷]
              |                    |
        [VPN 서버]         목적지에 직접 연결

"분할"은 운영 체제 내부의 분기점입니다 — 가상 인터페이스와 물리적 인터페이스 사이의 선택은 암호화가 이루어지기 전에 결정됩니다. 따라서 터널을 우회하는 패킷은 처음부터 암호화되지 않은 것입니다. 복호화 단계는 없으며, 그냥 기기에서 그대로 나갑니다.

역방향 분할 터널링 — 허용 목록 vs 차단 목록

분할 터널링 구성에는 대칭적으로 보이지만 기본 실패 동작이 매우 다른 두 가지 방식이 있습니다:

차단 목록 모드 (일반적인 기본값) — "이 목록에 있는 앱/목적지를 제외한 모든 것을 터널링한다." 기본값은 보호되며, 특정 예외만 유출됩니다. 앱을 목록에 추가하는 것을 잊어버리더라도 보호 상태를 유지합니다.
허용 목록 모드 (역방향 분할 터널링이라고도 함) — "이 목록에 있는 앱/목적지만 터널링하고 나머지는 직접 연결한다." 기본값은 보호되지 않으며, 특정 앱만 터널링됩니다. 앱을 목록에 추가하는 것을 잊어버리면 유출됩니다.

허용 목록 모드는 "브라우저만 VPN을 사용하고 나머지는 일반 연결을 쓰겠다"는 경우에 적합한 선택입니다. 차단 목록 모드는 "대부분의 것을 보호하되 특정 앱에는 실제 네트워크가 필요하다"는 경우에 적합합니다. 대부분의 소비자는 차단 목록 모드를 원합니다. 운영 및 DevOps 팀은 시스템의 나머지 부분을 방해하지 않고 터널을 통해 특정 서비스를 노출하려 하기 때문에 허용 목록 모드를 선호하는 경우도 있습니다.

허용 목록 모드의 실패 모드는 심각합니다: 새 앱을 추가하고 허용 목록에 넣는 것을 잊으면 해당 앱의 트래픽이 유출됩니다. 차단 목록 모드의 실패 모드는 더 온화합니다: 잊어버린 앱은 보호 상태를 유지합니다 — 스트리밍이나 뱅킹 앱이 VPN IP를 감지하고 실패할 때 불편한 호환성 문제가 생길 뿐입니다.

분할 터널링을 사용할 때 — 다섯 가지 구체적인 시나리오

분할 터널링에는 진정한 합법적 용도가 있습니다. 적절한 도구가 되는 상황은 다음과 같습니다:

1. VPN 엔드포인트를 감지하고 차단하는 스트리밍 서비스

Netflix, Disney+, Hulu 및 대부분의 지역 방송사는 알려진 VPN 데이터센터 IP의 대규모 허용 목록을 유지하며 감지되면 스트리밍을 거부합니다. VPN을 끄거나(모든 보호를 잃음) 스트리밍 앱을 분할 터널링하여 실제 IP를 보이게 하면서 나머지는 보호 상태를 유지할 수 있습니다.

2. 위치 기반 사기 감지가 있는 뱅킹 및 금융 앱

은행들은 VPN 데이터센터로의 갑작스러운 IP 변경을 사기 신호로 처리하는 경우가 많아 — 추가 인증을 요구하거나, 거래를 보류하거나, 계정을 일시적으로 잠글 수 있습니다. 은행 앱을 터널 밖으로 분할하면 은행과의 실제 IP 관계를 일관되게 유지할 수 있습니다. 이는 보안 업그레이드가 아닌 사용성 수정입니다 — 은행 연결은 이미 TLS 암호화가 되어 있어 VPN이 해당 특정 세션에 보안을 크게 추가하지 않았습니다.

3. 로컬 네트워크 리소스 (NAS, 프린터, 스마트 홈)

VPN이 모든 트래픽을 캡처하면 192.168.1.50의 프린터에 더 이상 접근할 수 없게 됩니다. 해당 IP가 VPN 터널을 통해 도달할 수 없기 때문입니다. 목적지 기반 분할 터널링(192.168.0.0/16 및 10.0.0.0/8 제외)은 공용 인터넷에 대한 VPN을 비활성화하지 않고 로컬 접근을 복원합니다. 많은 VPN 클라이언트는 이를 기본값으로 자동으로 수행하지만 일부는 그렇지 않습니다.

4. 지연 시간에 민감한 애플리케이션

경쟁 온라인 게임, 실시간 화상 회의, 음성 통화는 먼 지역의 VPN 서버를 통한 라우팅으로 추가 지연 시간이 발생할 때 성능이 저하됩니다. 특정 앱들을 분할하면 지연 시간을 회복하면서 나머지는 암호화된 상태를 유지할 수 있습니다. 트레이드오프: 이제 ISP와 네트워크 관찰자에게 해당 앱들이 식별 가능하게 됩니다.

5. 개인 VPN과 함께 사용하는 업무 VPN

고용주가 내부 리소스 접근을 위해 기업 VPN을 요구하고, 개인 트래픽은 다른 (프라이버시 중심의) VPN을 통하게 하고 싶다면, 기업 VPN에서 분할 터널링 — 기업 IP 범위만 통과시키는 방식 — 을 사용하면 나머지 트래픽을 개인 VPN에서 사용할 수 있습니다. 파워 유저 설정이지만 업무와 개인 트래픽을 깔끔하게 분리하는 방법입니다.

분할 터널링을 사용하지 말아야 할 때 — 프라이버시 함정

분할 터널링은 네트워크 동작을 더 복잡하게 만들며, 복잡한 네트워크 동작은 예상치 못한 방식으로 유출됩니다. 가장 일반적인 실패 모드:

우회 경로를 통한 DNS 유출

앱의 TCP 트래픽이 터널 밖으로 라우팅되더라도, DNS 쿼리는 여전히 VPN의 DNS 리졸버를 사용하도록 구성되어 있거나 — 더 나쁜 경우 — VPN 클라이언트가 시스템 DNS를 신중하게 관리하지 않으면 ISP의 DNS 리졸버로 폴백될 수 있습니다. 결과적으로 ISP에서 보이지 않아야 할 앱이 부분적으로 노출됩니다. ISP는 후속 TCP 연결이 다른 경로를 통해 이루어졌더라도 banking.example.com에 대한 DNS 쿼리를 볼 수 있습니다. DNS 암호화가 어떻게 작동하는지에 대한 더 자세한 내용은 DNS-over-HTTPS 가이드를 참고하세요.

앱 대 도메인 혼동

앱 기반 분할 터널링은 프로세스 ID로 라우팅하지만, 현대 앱은 많은 도메인에 연결합니다. "스트리밍 앱"은 아마도 광고, 원격 분석, 추천 API, 분석 엔드포인트를 수십 개의 서로 다른 도메인에서 로드할 것입니다 — 일부는 터널링하려는 앱과 공유됩니다. 전체 앱을 제외하면 해당 연결들도 모두 제외됩니다. 도메인 기반 분할 터널링은 반대 문제가 있습니다: 단일 앱이 스트리밍 비디오(보호 해제를 원하는 것)와 노출하고 싶지 않은 콘텐츠 모두에 동일한 CDN 도메인을 사용할 수 있습니다.

IPv6 유출

많은 분할 터널 구현은 IPv4가 유일한 라우팅 관심사였을 때 설계되었습니다. 네트워크에 IPv6 연결이 있고 분할 터널 규칙이 IPv6 경로를 명시적으로 포함하지 않으면, 터널링되어야 할 패킷이 터널 밖으로 IPv6를 통해 나갈 수 있습니다. 이는 2026년에 가장 일반적인 VPN 유출 중 하나이며 거의 항상 불완전한 분할 터널 규칙 구성으로 인해 발생합니다. 분할 터널링을 활성화한 후 IPv6 유출 테스트로 확인하세요.

킬 스위치 상호작용

킬 스위치는 VPN이 끊어질 경우 모든 트래픽을 차단하여 아무것도 보호 없이 유출되지 않도록 설계되었습니다. 분할 터널링이 활성화되면 킬 스위치 로직이 더 복잡해집니다 — 킬 스위치는 여전히 분할 터널링된 앱의 통신을 허용해야 하지만, 해당 앱들만, 그리고 VPN 자체가 다운된 경우에만 허용해야 합니다. 많은 VPN 클라이언트에서 킬 스위치가 VPN이 끊어졌을 때 터널링된 앱을 차단하지 못하거나, 계속 작동해야 하는 분할 터널링된 앱을 잘못 차단하는 버그가 있습니다. 두 기능을 함께 명시적으로 테스트하세요.

분할 터널링 모드 비교

모드	암호화되는 것	유출되는 것	적합한 용도
전체 터널 (분할 없음)	모든 트래픽, 모든 앱, 모든 목적지	애플리케이션 측에서 아무것도 유출되지 않음; ISP에는 VPN을 사용한다는 사실만 보임	적대적 네트워크, 여행, ISP가 위협 모델에 포함된 모든 사용자
앱 기반 차단 목록	특별히 제외된 앱을 제외한 모든 앱	제외된 앱은 실제 IP를 보게 됨; DNS는 구현에 따라 유출될 수도 그렇지 않을 수도 있음	스트리밍, 뱅킹, VPN을 감지하는 지역 제한 앱
앱 기반 허용 목록 (역방향)	목록에 있는 앱만	OS 백그라운드 서비스, 업데이트, 원격 분석 포함 나머지 모두	특정 사용 사례: "브라우저만 터널링", 개발자 설정
목적지 기반 (LAN 제외)	공용 인터넷으로 가는 모든 것	로컬 네트워크 트래픽 (프린터, NAS, 스마트 홈)	거의 항상 바람직함; 많은 클라이언트가 기본적으로 활성화
도메인 기반 (URL 규칙)	DNS 가로채기 로직에 따라 다름	가변적; 공유 CDN과 동적 DNS로 인해 취약함	특정 허용 목록 사이트; 소비자에게는 복잡성 대비 가치가 거의 없음

운영 체제별 분할 터널링 작동 방식

iOS — 제한적이고 간접적

iOS는 타사 VPN 앱에 진정한 분할 터널링 API를 노출하지 않습니다. NetworkExtension 프레임워크를 사용하면 VPN을 시스템 전체(모든 트래픽) 또는 앱별(MDM 프로필로 명시적으로 등록된 앱만)로 구성할 수 있습니다. 진정한 앱별 분할 라우팅에는 MDM 배포 구성 프로필과 함께 Apple의 NEAppProxyProvider가 필요합니다 — 즉 관리형 기기 시나리오를 의미합니다. "분할 터널링"을 광고하는 iOS 소비자 VPN 앱은 일반적으로 목적지 기반 제외(예: 터널에서 특정 IP 범위 제외)를 구현하거나, Wi-Fi SSID 또는 도메인 일치를 기반으로 VPN을 조건부로 활성화하는 온디맨드 규칙 API를 사용합니다. 소비자 iOS 사용자를 위한 앱 기반 분할 터널링은 실제로 지원되지 않습니다.

Android — 기본 지원

Android의 VpnService API는 앱별 라우팅을 기본적으로 지원합니다. VPN 클라이언트는 addAllowedApplication() 또는 addDisallowedApplication()을 호출하여 터널을 통과하는 앱을 지정할 수 있습니다. OS가 앱별 라우팅을 투명하게 처리하므로 VPN 클라이언트는 패킷 수준 태깅을 수행할 필요가 없습니다. Android는 또한 "VPN 없이 연결 차단" 옵션이 있는 "항상 켜져 있는 VPN" 시스템 설정을 지원하여, 앱별 구성과 킬 스위치 동작을 결합합니다: 터널링된 앱은 통과하고, 터널링되지 않은 앱은 직접 연결하며, VPN이 끊어지면 터널링된 앱은 차단됩니다.

macOS — 구현에 따라 다름

macOS는 여러 메커니즘을 통해 분할 터널링을 지원합니다: NetworkExtension 프레임워크(iOS와 유사하지만 더 유연성 있음), pf 규칙을 통해 구성된 패킷 필터, 또는 높은 권한으로 실행되는 VPN 클라이언트의 라우팅 테이블 조작. macOS에서 앱 기반 분할 터널링은 가능하지만 VPN 클라이언트가 소켓-프로세스 매핑에 대해 커널을 쿼리해야 합니다. 목적지 기반 분할은 간단하고 안정적입니다.

Windows — 분할 터널링을 위한 가장 일반적인 플랫폼

Windows VPN 클라이언트는 10년 이상 분할 터널링을 사용해 왔습니다. Windows 필터링 플랫폼(WFP)은 VPN 클라이언트가 연결하는 커널 수준 패킷 검사 및 라우팅 결정 API를 제공합니다. Windows에서 앱별 분할 터널링은 잘 지원되며 광범위하게 배포됩니다. 대부분의 엔터프라이즈 VPN 배포는 Windows 분할 터널링을 사용하여 기업 트래픽은 기업 터널을 통하고 일반 인터넷 트래픽은 직접 연결되도록 합니다 — 부분적으로는 성능을 위해, 부분적으로는 기업 VPN 집중기의 부하를 줄이기 위해서입니다.

분할 터널링 구성 시 일반적인 실수

실제로 분할 터널링을 잘못 구성하는 방식을 살펴보면 몇 가지 반복적인 패턴이 나타납니다. 설정한다면 이 목록과 대조해서 확인하세요:

활성화 후 DNS 유출 테스트를 하지 않는 것. 모든 구성 변경 후 유출 테스트(dnsleaktest.com 또는 유사한 사이트)를 실행하세요. 터널링되어야 할 앱에서 ISP의 DNS 리졸버가 표시된다면 우회가 DNS를 유출하고 있는 것입니다.
브라우저가 특별하다는 것을 잊는 것. 스트리밍 웹 앱을 실행하는 브라우저는 스트리밍 비디오와 다른 탭 모두를 같은 프로세스를 통해 라우팅합니다. 브라우저를 제외하면 모든 브라우징이 제외됩니다. 스트리밍 사례에는 별도의 브라우저 프로필이나 다른 앱을 사용하세요.
IPv6를 처리하지 않는 것. VPN 클라이언트가 IPv6를 명시적으로 처리하지 않는다면 IPv6를 완전히 비활성화하세요. 잊어버린 IPv6 분할 터널 규칙으로 인한 유출률이 높습니다.
보안에 중요한 결정에 도메인 기반 규칙을 사용하는 것. 도메인 기반 분할 터널링은 사용성 조정에는 괜찮습니다. "이 민감한 앱은 항상 VPN을 통해야 한다"를 강제하기에는 충분히 신뢰할 수 없습니다 — 그런 경우에는 앱을 명시적으로 터널링하는 앱 기반 규칙을 사용하세요. 가급적 허용 목록 모드로 설정하세요.
분기별로 규칙을 검토하지 않는 것. 앱이 추가되고 제거됩니다; 같은 게시자의 새 앱은 이전 앱의 설정을 상속하지 않습니다. 주기적으로 분할 터널 규칙 세트를 감사하세요.

분할 터널링에 대한 솔직한 평가

분할 터널링은 특정 문제에 진정으로 유용합니다 — VPN을 감지하는 스트리밍 앱, VPN 로그인에 플래그를 표시하는 뱅킹 앱, 로컬 네트워크 접근 — 그리고 엔터프라이즈 환경에서 합법적인 배포의 긴 역사를 가지고 있습니다. 소비자에게 솔직한 표현은 이것이 프라이버시 도구보다 먼저 사용성 도구라는 것입니다. 모든 분할 터널 규칙은 어떤 특정 방식으로 보호 모델을 약화시키며, 해당 트래픽에 어차피 보호가 도움이 되지 않았을 때만 (예: 이미 TLS 암호화가 되어 있고 단일하고 잘 알려진 목적지로 가는 은행 세션) 보안 트레이드오프가 가치 있습니다.

위협 모델이 "적대적인 공용 Wi-Fi 네트워크에서 VPN을 사용하여 로컬 네트워크 운영자가 트래픽을 관찰하지 못하게 하고 싶다"라면 전체 터널이 올바른 답입니다. VPN 클라이언트가 제공한다고 해서 분할 터널링을 활성화하지 마세요 — 모든 제외는 구멍입니다. 위협 모델이 "대부분의 트래픽을 보호하되 특정 앱에는 실제 네트워크가 필요하다"라면 분할 터널링이 적합한 도구이지만, 신중하게 구성하고, 이후 DNS 및 IPv6 유출을 테스트하며, 주기적으로 규칙을 검토하세요. WireGuard 퀵스타트 문서의 기술 참조는 프로토콜 레이어에서 기본 라우팅 결정이 어떻게 작동하는지 보여줍니다.

Casper's Cloak은 기본적으로 전체 터널 아키텍처를 사용합니다. 우리가 보호하려는 위협 모델 — 적대적 네트워크, ISP 감시, 광고 기술 추적 — 은 더 단순한 "모든 것을 터널링" 모델의 혜택을 받기 때문입니다. 우리는 여기에 DNS 레이어의 트래커 필터링과 알려진 악성 목적지에 대한 AI 위협 감지를 결합하여, 전체 터널이 단순 라우팅만이 아닌 능동적인 필터링도 수행합니다. 스트리밍 및 뱅킹 예외 사례의 경우, 나중에 잊어버릴 영구적인 분할 터널 제외 목록을 유지하는 것보다 일시적으로 연결을 끊는 것이 대개 더 나은 선택입니다.