VPN 초보자 완전 가이드: 구독·노드·프로토콜·분할 터널링 한 번에 정리

처음 클라이언트를 열면 '구독, 노드, 프로토콜, 분할 터널링'이라는 단어 앞에서 대부분 잠시 멈춥니다. 각각 무엇을 담당하고, 연결이 안 될 때 무엇을 바꿔야 할까요? 이 VPN 초보자 완전 가이드는 바깥에서 안쪽으로 들어가는 순서로 각 용어를 제자리에 놓아 설명합니다. 구독은 어떤 노드를 받을지 정하고, 노드는 트래픽이 어디로 나갈지 정하며, 프로토콜은 그 트래픽이 어떤 형태로 네트워크를 통과할지, 분할 터널링은 어떤 트래픽이 프록시를 거치고 어떤 트래픽이 직접 연결될지를 정합니다.

아래 각 절은 '무엇인가 → 무엇에 영향을 주는가 → 초보자가 자주 하는 실수' 순서로 구성했습니다. 다 읽고 나면 클라이언트의 각 설정 항목을 이해하고, 문제가 생겼을 때 파라미터를 처음부터 끝까지 바꾸는 대신 어느 계층부터 확인해야 하는지 알 수 있습니다.

구독 링크: 노드 목록의 입구

구독 링크는 서비스 제공자가 발급하는 http/https 주소입니다. 클라이언트가 이 주소를 요청하면 설정 파일을 받게 되는데, 보통 두 가지 형태입니다. 하나는 base64로 인코딩된 노드 목록으로 각 줄이 ss://, vmess://, trojan:// 로 시작하는 URI이고, 다른 하나는 Clash, sing-box 같은 클라이언트가 바로 읽는 YAML 또는 JSON으로 노드 외에 규칙 세트와 정책 그룹도 함께 들어 있습니다.

구독이 해결하는 핵심 문제는 동기화입니다. 노드는 추가되거나 삭제되고, 주소가 바뀌고, 파라미터가 조정됩니다. 하나씩 직접 입력하는 방식은 느리고 오타가 나기 쉽습니다. 구독은 이 과정을 '업데이트' 한 번으로 줄여 줍니다. 클라이언트는 보통 시작할 때와 일정 주기로 자동으로 가져오며, 설정에서 수동으로 한 번 업데이트할 수도 있습니다.

# 구독 링크가 반환하는 설정 일부(예시)
proxies:
  - name: "홍콩-01"
    type: ss
    server: hk01.example.com
    port: 443
    cipher: chacha20-ietf-poly1305
    password: "******"
  - name: "일본-02"
    type: trojan
    server: jp02.example.com
    port: 443
    sni: jp02.example.com
    password: "******"

구분해야 할 점은 구독 링크 자체가 일종의 자격 증명이라는 것입니다. 링크를 얻은 사람은 여러분의 노드를 가져가고 트래픽을 소모할 수 있습니다. 따라서 구독 주소를 공개 그룹이나 포럼, 스크린샷에 올려서는 안 됩니다.

또 하나 흔한 오해: 구독 업데이트는 서버 쪽 노드 변경을 동기화하는 것이지, 로컬에서 수정한 규칙과 정책 그룹을 덮어쓰지 않습니다(클라이언트마다 동작이 조금씩 다릅니다). 설정을 직접 수정했다면 업데이트 전에 변경 사항이 덮어써질지 먼저 확인하세요.

노드와 회선: 직결·중계·전용선의 차이

노드는 설정 파일 안의 한 줄입니다. 서버 주소 하나, 포트 하나, 프로토콜 파라미터 한 세트로 이루어집니다. 노드를 고른다는 것은 곧 '트래픽이 어느 출구로 나갈지'를 고르는 일입니다. 출구 지역은 일부 서비스가 인식하는 위치를 결정하고, 출구 회선은 이 연결이 안정적인지를 결정합니다.

회선 유형이 설명하는 것은 출구가 어디인지가 아니라, 여러분에게서 출구까지 트래픽이 어떻게 이동하는지입니다. 초보자가 가장 쉽게 놓치면서도 체감에 가장 크게 영향을 주는 계층이며, 흔히 세 가지로 나뉩니다.

직결

클라이언트가 서버가 외부에 노출한 주소로 직접 연결하는 방식으로, 경로가 가장 짧고 비용이 가장 낮습니다. 대신 이 구간이 공용 국제 회선을 지나기 때문에 저녁 피크 시간대에는 다른 트래픽과 함께 대기열에 서게 되고, 혼잡과 지터가 그대로 체감 품질에 반영됩니다.

중계

트래픽이 먼저 중계 서버로 가고, 그 서버가 출구 노드로 다시 전달하는 2홉 구조입니다. 홉이 하나 늘면 오버헤드가 생기지만, 중계는 보통 최적화된 국제 라우팅을 사용해 경로가 더 예측 가능하고 전반적으로 직결보다 안정적입니다. 대부분의 구독에서 주력으로 쓰이는 회선입니다.

IEPL 전용선

전용선은 트래픽을 지점 간 사설 회선에 태워 다른 공용 인터넷 트래픽과 대역폭을 공유하지 않는 방식입니다. 장점은 지터와 패킷 손실이 더 예측 가능하고, 저녁 피크에도 평상시와 비슷한 성능을 낸다는 점입니다. 대신 비용이 높아 안정성이 중요한 상황에 주로 쓰입니다.

또한 클라이언트의 '정책 그룹'은 여러 노드를 하나의 그룹으로 묶고 속도 측정 결과에 따라 자동 선택, 수동 지정, 순환 방식으로 고를 수 있게 해 줍니다. 노드는 자원이고, 정책 그룹은 그 자원을 사용하는 방식입니다. 둘을 같은 것으로 보면 안 됩니다.

자주 쓰는 프로토콜: Shadowsocks부터 Hysteria2까지

프로토콜은 클라이언트와 서버가 어떻게 핸드셰이크하고 어떻게 암호화하는지, 그리고 이 트래픽이 네트워크에서 어떻게 보이는지를 결정합니다. 출구 위치에는 영향을 주지 않지만 연결성과 속도에는 직접 영향을 줍니다. 같은 서버에서 여러 프로토콜 입구를 동시에 열 수 있으며, 구독에는 각각 따로 표시됩니다.

분할 터널링과 세 가지 모드: 규칙·전역·직결

분할 터널링(라우팅이라고도 합니다)은 특정 트래픽이 프록시를 거칠지 직접 연결될지를 결정합니다. 클라이언트는 규칙 목록을 한 줄씩 대조하는데, 흔한 매칭 기준은 도메인과 도메인 접미사, IP 대역과 GeoIP 소속, 프로세스 이름, 포트입니다. 규칙 목록은 보통 세 묶음으로 나뉩니다. 프록시를 거쳐야 하는 것, 직접 연결해야 하는 것, 차단해야 하는 것입니다.

클라이언트는 보통 세 가지 모드를 제공하며, 차이는 '기본값을 어떻게 처리하는가'뿐입니다.

1. 규칙 모드: 규칙 목록대로 매칭해 프록시 대상은 프록시로, 직접 연결 대상은 직접 연결로 보내고 나머지는 기본 출구로 보냅니다. 일상 사용에는 이 모드를 선택하세요.
2. 전역 모드: 모든 트래픽을 프록시 출구로 보냅니다. 규칙 목록의 직접 연결 항목이 여전히 적용되는지는 클라이언트마다 다릅니다. '문제가 분할 터널링 규칙 때문인가'를 임시로 확인할 때 적합합니다.
3. 직결 모드: 모든 트래픽이 프록시를 거치지 않으며, 클라이언트는 로컬 DNS와 규칙 엔진만 유지합니다. 프록시가 필요 없는 네트워크에서 잠시 꺼 둘 때 적합합니다.

분할 터널링을 잘못 설정했을 때 나타나는 대표적인 증상은 세 가지입니다. 국내 사이트가 오히려 느려지고(트래픽이 해외로 돌아 나갔다가 다시 들어옴), 같은 네트워크의 기기(프린터, 화면 미러링, NAS)가 보이지 않으며, 일부 앱의 로그인이나 결제가 실패합니다. 이런 경우 모드가 전역으로 바뀌지 않았는지 먼저 확인하세요.

DNS와 분할 터널링의 관계

분할 터널링이 '이 도메인이 프록시를 거쳐야 하는가'를 판단하려면 먼저 도메인을 해석해야 합니다. 해석이 로컬에서 이루어지면 쿼리 내용이 로컬 네트워크에 노출되는데, 이를 흔히 DNS 유출이라고 합니다. 더 흔한 결과는 해석 결과가 회선과 맞지 않는 것입니다. 해외 출구를 쓰는데 로컬 CDN 주소를 받아오면 속도가 나올 리 없습니다.

요즘 클라이언트는 대부분 fake-ip 또는 원격 해석으로 이 문제를 처리합니다. 프록시가 필요한 도메인은 원격 DNS로 해석하고, 직접 연결 도메인은 로컬 DNS를 그대로 씁니다. 대부분은 기본값을 유지하면 되고, '열리긴 하는데 너무 느리다', '특정 사이트가 안 열린다' 같은 상황에서만 DNS 설정을 다시 확인하면 됩니다.

클라이언트와 플랫폼 차이: 시스템 프록시, TUN, 앱별 분할

같은 구독이라도 플랫폼마다 사용 방식이 다릅니다. 차이는 주로 두 가지에서 비롯됩니다. 트래픽을 어떻게 가로채는가, 그리고 앱별로 분할할 수 있는가입니다.

가로채는 방식: 시스템 프록시와 TUN

시스템 프록시는 '시스템 프록시 설정을 따르는' 앱에만 적용됩니다. 브라우저와 대부분의 데스크톱 소프트웨어는 따르지만, 일부 게임과 터미널 도구, 자체 네트워크 스택을 쓰는 앱은 적용되지 않습니다. TUN 모드는 가상 네트워크 어댑터를 만들어 네트워크 계층에서 트래픽을 가로채므로 적용 범위가 더 완전합니다. 대신 더 높은 시스템 권한이 필요하고 다른 가상 어댑터와 충돌하기 쉽습니다.

플랫폼별 차이

• Windows: 클라이언트 선택지가 가장 많고, 주요 클라이언트가 시스템 프록시와 TUN을 모두 지원합니다. TUN이 일부 보안 소프트웨어의 가상 어댑터 드라이버와 충돌할 수 있으니 주의하세요.
• macOS: 시스템 프록시와 TUN(utun)을 모두 지원하며 설정이 비교적 깔끔합니다. TUN을 처음 켤 때 권한 확인 창이 나타납니다.
• Android: 시스템 VpnService로 가로채며, 어떤 앱을 프록시로 보낼지 앱별로 선택할 수 있어 여러 플랫폼 중 분할 단위가 가장 세밀합니다.
• iOS: VPN 프로파일로 전체를 가로채며, 일반적으로 앱별 분할을 제공하지 않아 규칙 목록에만 의존해야 합니다. iOS에서 규칙 품질이 더 중요한 이유입니다.

점검 순서와 다섯 가지 흔한 오해

연결에 문제가 생겼을 때 시간을 가장 아끼는 방법은 파라미터를 무작위로 바꾸는 것이 아니라 계층별로 점검하는 것입니다. 권장 순서는 기기 시간이 동기화되어 있는지 확인 → 클라이언트가 규칙 모드인지 확인 → 다른 노드로 교체 → 마지막으로 프로토콜 교체입니다. 이 순서는 '가장 검증하기 쉬운 계층부터'라는 원칙에 따른 것입니다.

• ✅ 구독 링크는 본인 기기에만 가져오고, 공개 그룹에 공유하거나 스크린샷으로 남기지 않는다
• ✅ 연결이 안 되면 '시간 동기화 → 모드 확인 → 노드 교체 → 프로토콜 교체' 순서로 점검하고, 각 단계에서 변수는 하나만 바꾼다
• ✅ 구독을 업데이트하기 전에 로컬에서 수정한 규칙과 정책 그룹이 덮어써지지 않는지 먼저 확인한다
• ❌ 노드 주소, 포트, 비밀번호를 직접 적어 하나씩 입력한다. 구독을 업데이트해도 이 설정은 따라 바뀌지 않는다
• ❌ 전역 모드를 장기간 켜 두면 로컬 서비스와 내부 네트워크 기기까지 프록시를 거치게 되어 문제 범위가 커진다
• ❌ 시스템 시간이 정확하지 않은 기기에서 VMess를 사용하면 핸드셰이크가 서버에서 바로 거부된다

이 용어들을 실제 선택에 적용해 보기

앞의 내용을 종합하면, 구독 서비스를 고를 때 실제로 확인해야 할 것은 몇 가지뿐입니다. 회선 유형이 내 사용 환경을 커버하는가, 프로토콜이 내 클라이언트에서 지원되는가, 구독 업데이트가 편한가, 그리고 만족스럽지 않을 때 환불이 가능한가입니다.

VPNWY를 예로 들면 지원 국가 및 지역 110+, 회선 150+개, 구독 기기 수 무제한, 이메일 주소 없이 가입, 첫 결제 후 30일 이내 이유 불문 전액 환불을 신청할 수 있습니다. 월 구독과 트래픽 패키지 가격은 요금제 페이지에 정리되어 있으니 여기서는 반복하지 않습니다.

자주 묻는 질문 세 가지