프로토콜과 회선 기술 레퍼런스

선택 가이드

이 페이지는 NZVPN의 프로토콜 및 회선 기술 레퍼런스로, 구독 요금제를 고르는 중이거나 이미 구독했지만 원리를 알고 싶은 사용자를 위한 것입니다. 튜토리얼 페이지 setup.html의 "따라 하면 완료" 방식과 달리, 이 페이지는 체계적인 참고 자료에 가깝습니다. 각 장은 독립적으로 읽을 수 있고, 목차를 통해 원하는 주제로 바로 이동할 수도 있습니다.

시작하기 전에 두 가지 기본 개념을 먼저 짚고 넘어가겠습니다. 프로토콜(Protocol)은 데이터가 어떻게 캡슐화되고 암호화되며 전송되는지를 결정합니다. 회선 토폴로지(Topology)는 데이터가 물리적으로 어떤 경로를 거치는지를 결정합니다. 이 둘이 함께 연결 수립 속도, 전송 속도, 안정성, 모바일 배터리 소모량을 결정합니다. 많은 사용자가 "연결이 안 된다" "속도가 느리다" "4K가 버벅인다"는 문제를 겪지만, 그 원인은 서비스 자체가 아니라 현재 네트워크 환경에 맞게 프로토콜과 회선 조합을 최적화하지 않았기 때문인 경우가 많습니다.

프로토콜 계층은 "데이터가 어떤 형태로 네트워크를 통과하는가"의 문제를 해결합니다. 기존 TCP 프록시는 약한 네트워크에서 핸드셰이크와 재전송 때문에 속도가 느려질 수 있지만, UDP 기반 프로토콜은 높은 패킷 손실 환경에서도 더 안정적인 전송을 유지할 수 있습니다. 회선 계층은 "데이터가 어떤 경로로 가는가"의 문제를 해결합니다. 같은 싱가포르 노드라도 직접 연결, 중계, IEPL 전용선 중 무엇을 쓰느냐에 따라 지연 시간과 안정성이 몇 배 차이날 수 있습니다. 이 두 계층을 이해해야 회선 목록을 볼 때 효과적으로 판단할 수 있습니다.

NZVPN의 구독 서비스는 120개 이상 국가 / 220개 이상 회선을 지원하며 Windows, macOS, iOS, Android, Linux 5대 플랫폼에서 사용할 수 있고, 기기 수 제한이 없습니다. 구독은 월 ₩9.9부터(60GB 트래픽) 시작하는 3단계 요금제가 있으며, 영구적으로 만료되지 않는 트래픽 팩도 선택할 수 있고 30일 무조건 환불이 제공됩니다. 이 글의 모든 서비스 관련 설명은 위 사실과 일치하며, 확인되지 않은 데이터는 포함하지 않습니다.

참고로 이 페이지에서는 네트워크 규제에 관한 논의를 다루지 않으며, 구체적인 노드 설정 명령도 제공하지 않습니다. 프로토콜과 회선은 서비스 제공자가 이미 백엔드에서 구성해 둔 인프라로, 사용자가 선택할 수 있는 부분은 구독 요금제와 클라이언트 설정에 집중되어 있습니다. 하지만 원리를 이해하면 특정 네트워크 환경에서 어떤 프로토콜이 더 빠른지, 전용선이 더 높은 월 요금을 받을 만한 가치가 있는지, 연결에 문제가 생겼을 때 어느 부분을 점검해야 하는지 판단하는 데 도움이 됩니다.

이 페이지는 "프로토콜 → 비교 → 토폴로지 → 시나리오" 순서로 구성되어 있습니다. 1장부터 5장까지는 6가지 프로토콜을 하나씩 소개하고, 6장에서는 비교표를, 7장에서는 회선 토폴로지를, 8장에서는 패킷 손실과 혼잡의 원인을, 9장에서는 사용 시나리오별 선택 제안을 다룹니다. 처음부터 끝까지 읽어도 되고, 가장 관심 있는 장으로 바로 건너뛰어도 됩니다.

Shadowsocks: 경량 프록시 프로토콜의 트레이드오프

Shadowsocks(약칭 SS)는 현재 가장 널리 사용되는 경량 프록시 프로토콜 중 하나입니다. 설계 목표는 매우 명확합니다. 신뢰할 수 없는 네트워크 환경에서 가능한 한 낮은 리소스 오버헤드로 암호화 터널을 구축하는 것입니다. SS의 암호화 방식은 AEAD(인증 암호화) 스트림 암호를 기반으로 하며, 일반적인 조합으로는 AES-256-GCM과 ChaCha20-Poly1305가 있습니다. 전자는 주류 CPU에서 하드웨어 가속을 지원하고, 후자는 모바일 ARM 프로세서에서 더 나은 성능을 보입니다.

SS의 전송 계층은 기본적으로 TCP를 사용하며, 데이터는 표준 SOCKS5 프록시 트래픽으로 캡슐화됩니다. 프로토콜 수준에서 "일반 프록시처럼 보이기" 때문에 배포가 매우 가볍고, 추가적인 핸드셰이크나 인증 오버헤드가 필요 없습니다. 연결 수립 시 클라이언트와 서버 사이에 TCP 핸드셰이크 한 번과 암호화 핸드셰이크 한 번만 필요하며, 전체 과정은 보통 수십에서 수백 밀리초 안에 완료됩니다. 웹 브라우징, 인스턴트 메시징 같은 짧은 연결 시나리오에서 SS의 응답 속도는 매우 이상적입니다.

SS의 한계도 분명합니다. 첫째, 단일 포트 다중 사용자 지원이 약합니다. 초기 SS는 하나의 포트가 한 사용자만 서비스할 수 있었지만, 이후 구현은 다중 사용자를 지원하지만 서버에서 사용자 테이블을 유지해야 하므로 대규모 동시 접속 시 관리 복잡성이 증가합니다. 둘째, 프로토콜 특성이 비교적 고정되어 있어 일부 심층 패킷 검사(DPI) 시스템이 트래픽 통계 특성을 분석해 SS 트래픽을 식별할 수 있습니다. 다만 이는 어느 정도의 계산 리소스가 필요합니다. 일반 사용자에게 SS는 여전히 가장 "부드러운" 선택입니다. 클라이언트 생태계가 성숙하고, 설정이 간단하며, 리소스 사용량이 낮기 때문입니다.

모바일에서 SS의 배터리 성능은 따로 설명할 가치가 있습니다. SS는 TCP 기반이므로 시스템이 저전력 모드에 들어갈 수 있어 UDP 프로토콜처럼 무선 모듈을 자주 깨울 필요가 없습니다. iOS와 Android에서 SS의 백그라운드 유지는 상대적으로 쉬우며, 오래 켜두어도 배터리 소모가 크게 늘지 않습니다. 주로 모바일 기기로 소셜 미디어를 보거나 웹을 보는 사용자에게 SS는 배터리 절약에 유리한 선택입니다.

실제 사용에서 SS는 다음과 같은 시나리오에 적합합니다. 가벼운 크로스보더 액세스, 모바일에서 장시간 유지, 연결 수립 속도에 민감한 애플리케이션(예: 인스턴트 메시징), 그리고 비교적 안정적인 네트워크 환경. 네트워크 패킷 손실률이 높으면 SS의 TCP 재전송 메커니즘으로 인해 속도가 눈에 띄게 떨어질 수 있으며, 이 경우 뒤에서 설명할 QUIC 기반 프로토콜이 더 권장됩니다.

NZVPN의 회선 목록에서 대부분의 일반 회선은 기본적으로 SS 또는 SS 호환 전송 방식을 사용합니다. 이 회선들은 일상적인 사용에 적합하며, 중계 토폴로지와 함께 사용하면 피크 시간대에도 기본적인 안정성을 유지할 수 있습니다. 더 극적인 속도 성능을 원한다면 클라이언트에서 다른 프로토콜로 전환하거나, 요금제 페이지에서 전용선 회선이 포함된 플랜을 선택할 수 있습니다.

VMess와 VLESS: 완전한 프로토콜 프레임워크의 진화

VMess는 V2Ray 계열의 핵심 프로토콜로, 설계상 SS보다 "알려진 프로토콜처럼 보이지 않는 것"에 더 중점을 둡니다. VMess는 애플리케이션 계층에서 UUID를 사용자 식별자로 도입하고 요청 헤더에 타임스탬프를 추가하며, 선택적인 재생 방지 메커니즘을 함께 제공하여 동일한 요청이 네트워크에서 쉽게 재생되거나 식별되지 않도록 합니다. VMess의 암호화도 AEAD 기반이지만, 메타데이터(대상 주소, 포트 등)도 암호화하여 SS처럼 대상 주소를 평문 헤더에 노출하지 않습니다.

VMess의 대가는 연결 수립 속도가 상대적으로 느리다는 점입니다. 매 연결마다 "클라이언트 시작 → 서버가 UUID 검증 → 응답 반환" 핸드셰이크 과정을 완료해야 하며, 약한 네트워크에서는 이 과정이 재전송으로 길어질 수 있습니다. 또한 VMess의 헤더에는 고정 접두사가 있어 DPI 시스템에서 이 특성을 식별할 수 있습니다. 이를 피하기 위해 이후 구현에서는 mKCP, WebSocket, gRPC 같은 전송 계층 변형을 도입하여 VMess 트래픽을 WebSocket 또는 gRPC 트래픽으로 위장합니다.

VLESS는 VMess의 후속 프로토콜로, 핵심 개선점은 VMess의 중복 암호화 계층을 제거한 것입니다. VLESS 자체는 데이터를 암호화하지 않고 메타데이터 전송만 담당하며, 실제 암호화는 전송 계층(예: TLS)에서 수행됩니다. 이렇게 하면 연결 수립 속도가 눈에 띄게 빨라집니다. 애플리케이션 계층 암호화 핸드셰이크를 먼저 할 필요 없이 TLS를 통해 보안 채널을 바로 설정하면 됩니다. VLESS는 UUID 사용자 식별자와 재생 방지 기능을 유지하며, XTLS 같은 새로운 전송 기능에 대한 지원도 추가되었습니다.

리소스 사용량 측면에서 VLESS는 VMess보다 가볍습니다. 애플리케이션 계층 암호화 한 겹이 줄어들면서 CPU 사용률이 낮아지며, 이는 저사양 기기나 모바일에서 특히 두드러집니다. VLESS를 TLS + WebSocket 또는 gRPC 전송과 함께 사용하면 트래픽 특성이 정상적인 HTTPS 웹사이트 접속과 거의 구분되지 않아, 트래픽 특성에 민감한 환경에 적합합니다.

참고로 VLESS 자체는 데이터를 암호화하지 않으므로 반드시 TLS와 함께 사용해야 안전합니다. NZVPN 클라이언트는 VLESS 회선을 구성할 때 기본적으로 TLS 암호화를 활성화하므로 사용자가 직접 조작할 필요가 없습니다. VLESS는 CDN과의 연동도 더 좋습니다. VLESS의 핸드셰이크 과정이 간결하기 때문에 CDN 오리진 요청 시 타임아웃으로 연결이 끊길 가능성이 낮습니다.

선택 관점에서 VMess는 호환성 요구가 높은 구형 클라이언트나 mKCP 같은 특수 전송이 필요한 시나리오에 적합합니다. VLESS는 연결 속도와 현대적인 전송 기능을 중시하는 사용자에게 더 적합합니다. 둘 다 NZVPN의 회선에 배포되어 있으며, 클라이언트가 회선 구성에 따라 적절한 프로토콜을 자동으로 선택하므로 일반 사용자가 직접 구분할 필요는 없습니다.

Trojan: 위장된 정상 HTTPS 트래픽

Trojan의 설계 방식은 SS, VMess와 모두 다릅니다. 핵심 아이디어는 "트래픽이 일반 HTTPS 웹사이트 접속과 완전히 동일하게 보이게 하는 것"입니다. Trojan은 TLS 터널 위에 사용자 정의 프로토콜 한 겹을 더하며, 클라이언트와 서버가 먼저 완전한 TLS 핸드셰이크를 수행한 다음 HTTP와 유사한 헤더를 통해 실제 요청을 전달합니다. 네트워크 트래픽만 보면 Trojan 연결은 HTTPS가 활성화된 웹사이트를 브라우저로 방문하는 것과 거의 구분할 수 없습니다.

바로 이 위장 특성 때문에 Trojan은 "평범한 접속처럼 보여야" 하는 시나리오에서 매우 효과적입니다. 연결 수립 과정은 일반 HTTPS와 동일합니다. TCP 핸드셰이크 한 번과 TLS 핸드셰이크 한 번을 거친 뒤 데이터 전송이 시작됩니다. 이 과정은 VMess보다 애플리케이션 계층 핸드셰이크 한 겹이 적으므로 연결 수립 속도는 VLESS와 비슷하지만, SS보다는 약간 느립니다(TLS 핸드셰이크 자체에 1~2 RTT가 필요하기 때문).

Trojan의 암호화는 전적으로 TLS에 의존하므로 인증서 관리에 대한 요구 사항이 높습니다. 서버는 유효한 TLS 인증서를 보유해야 하며, 그렇지 않으면 연결이 핸드셰이크 단계에서 실패합니다. NZVPN 클라이언트에는 인증서 검증 로직이 내장되어 있어, 회선에 Trojan 프로토콜이 구성된 경우 인증서 검증을 자동으로 완료합니다. 사용자는 구독 가져오기 시 해당 회선을 선택하기만 하면 됩니다. 인증서가 만료되거나 도메인이 변경되면 클라이언트가 연결 실패를 알리며, 이때 구독 링크를 다시 가져오면 업데이트됩니다.

리소스 사용량 측면에서 Trojan의 오버헤드는 주로 TLS 암호화/복호화에서 발생합니다. 현대 CPU에는 AES-NI 같은 하드웨어 가속 명령이 있으므로 TLS 암호화/복호화의 CPU 사용률은 높지 않습니다. 모바일에서 Trojan의 배터리 성능은 VLESS와 비슷합니다. 둘 다 전송 계층이 TCP이므로 시스템이 정상적으로 저전력 모드에 들어갈 수 있기 때문입니다. 다만 네트워크 패킷 손실이 심하면 Trojan의 TCP 재전송도 속도를 떨어뜨릴 수 있다는 점을 기억해야 합니다. 이는 모든 TCP 프로토콜의 공통된 특성입니다.

Trojan의 적용 시나리오: 복잡한 네트워크 환경을 안정적으로 통과해야 하고, 트래픽 특성이 최대한 눈에 띄지 않기를 바라며, CDN과 연동해 도메인 분기를 하고 싶은 사용자. Trojan과 TLS + WebSocket 조합은 CDN과 잘 호환되어 트래픽이 CDN 노드에서 실제 서버로 오리진 요청되도록 하여 백엔드 위치를 더욱 숨길 수 있습니다.

NZVPN의 회선 체계에서 Trojan은 일반적으로 전용선이나 고품질 중계 회선에 배포됩니다. Trojan의 위장 특성은 안정적인 TLS 연결을 필요로 하기 때문에, 회선 품질 자체가 낮으면 잦은 TLS 재연결이 오히려 경험을 떨어뜨릴 수 있습니다. "연결되면 바로 쓰고, 추가 설정이 필요 없는" 사용자에게 Trojan 회선은 편리한 선택입니다.

Hysteria2와 TUIC: QUIC 기반 차세대 프로토콜

Hysteria2와 TUIC는 모두 QUIC(Quick UDP Internet Connections) 기반 프록시 프로토콜입니다. QUIC는 Google이 주도적으로 개발한 전송 계층 프로토콜로, 하위 계층에서 UDP를 사용하지만 TCP의 신뢰성 있는 전송, 혼잡 제어, 다중화 기능을 내장하고 있습니다. TCP와 비교했을 때 QUIC의 가장 큰 장점은 연결 수립이 빠르다는 점입니다. TLS 핸드셰이크를 전송 핸드셰이크에 통합하여 보통 1 RTT만으로 암호화 연결을 수립할 수 있습니다.

Hysteria2의 독특한 점은 Brutal이라는 혼잡 제어 알고리즘을 사용한다는 것입니다. 기존 TCP 혼잡 제어(CUBIC, BBR 등)는 패킷 손실을 감지하면 전송 속도를 자발적으로 낮추는데, 이는 패킷 손실이 있는 네트워크에서 대역폭 활용률을 떨어뜨립니다. Brutal은 반대입니다. 사용자가 목표 속도를 설정하면 패킷 손실에도 불구하고 그 속도로 지속적으로 데이터를 전송합니다. 이는 높은 패킷 손실과 높은 지연 시간을 가진 링크에서 매우 효과적이며, 비디오 스트리밍이나 대용량 파일 다운로드가 안정적인 속도를 유지하도록 해줍니다.

TUIC의 설계는 "간결함"에 더 중점을 둡니다. 역시 QUIC 기반이지만 서버의 사용자 테이블을 없애고 VLESS와 유사한 UUID 식별자를 사용합니다. TUIC의 연결 수립 속도는 Hysteria2와 비슷하지만, 혼잡 제어 알고리즘은 표준 QUIC 기본 구현에 더 가깝습니다. 따라서 극단적으로 높은 패킷 손실 환경에서는 속도 성능이 Hysteria2만큼 공격적이지 않습니다. 다만 TUIC는 리소스 사용량이 더 낮아 저사양 기기에서 더 부드럽게 실행됩니다.

모바일 배터리는 QUIC 프로토콜을 선택할 때 가장 신중히 저울질해야 할 요소입니다. QUIC는 UDP 기반이며, UDP는 모바일 네트워크에서 NAT 매핑과 연결 상태를 유지하기 위해 무선 모듈을 더 자주 깨워야 합니다. 이는 같은 사용 시간 동안 QUIC 프로토콜의 배터리 소모량이 일반적으로 TCP 프로토콜보다 10%~20% 높다는 것을 의미합니다. 다만 QUIC의 빠른 재연결 능력은 네트워크 전환 시 더 빨리 복구되어 "다시 연결"로 인한 추가 배터리 소모를 줄여줍니다.

Hysteria2와 TUIC는 다음 시나리오에 적합합니다. 모바일 네트워크(4G/5G)에서 패킷 손실이 높은 환경, 4K 스트리밍이나 화상 회의를 봐야 하는 경우, 그리고 지하철이나 고속철처럼 네트워크가 자주 전환되는 상황. 패킷 손실률이 5%를 초과하는 링크에서는 QUIC 기반 프로토콜이 TCP 프로토콜보다 2~3배 빠른 경우가 많습니다.

NZVPN 클라이언트는 Hysteria2와 TUIC를 완벽하게 지원합니다. 구독 가져오기 시 QUIC를 지원하는 회선을 선택하면 클라이언트가 해당 포트와 전송 파라미터를 자동으로 구성합니다. 일부 구형 네트워크 장비(예: 일부 기업 방화벽)는 UDP 트래픽을 차단할 수 있다는 점에 유의해야 합니다. 이 경우 QUIC 프로토콜이 작동하지 않으므로 TCP 프로토콜로 되돌려야 합니다.

연결 수립 속도와 리소스 사용량 비교

6가지 프로토콜을 한 표에 놓으면 설계 트레이드오프를 더 직관적으로 볼 수 있습니다. 아래 표의 데이터는 일반적인 네트워크 환경(패킷 손실률 1%~3%, RTT 40~80ms)을 기준으로 한 경험값이며, 실제 성능은 회선 품질, 기기 성능, 네트워크 혼잡도에 따라 달라질 수 있습니다.

표에서 몇 가지 선택 규칙을 도출할 수 있습니다. 첫째, 네트워크 환경이 안정적이라면(가정용 광대역, 사무실 네트워크) TCP 프로토콜(SS, VLESS, Trojan)로 충분합니다. 배터리를 절약할 수 있고 호환성도 좋습니다. 둘째, 모바일 네트워크에서 자주 사용하거나 네트워크 패킷 손실률이 높다면 QUIC 기반 프로토콜(특히 Hysteria2)이 속도 경험을 크게 향상시킬 수 있습니다. 셋째, 트래픽 특성에 대한 우려가 있다면 Trojan과 VLESS가 더 안전한 선택입니다.

리소스 사용량 측면에서 SS와 VLESS의 CPU 사용률이 가장 낮습니다. 추가 암호화 계층이 없기 때문입니다. VMess는 애플리케이션 계층 암호화 한 겹이 더 있어 CPU 사용률이 약간 높습니다. Hysteria2와 TUIC의 CPU 사용률은 QUIC 구현 품질에 따라 달라집니다. TUIC는 코드가 더 간결하여 저사양 기기에서 더 유리합니다.

연결 수립 속도는 많은 사람이 간과하는 지표입니다. 짧은 연결 시나리오(웹 브라우징, API 호출)는 연결 수립 지연 시간에 매우 민감하며, RTT가 한 번 늘어날 때마다 사용자가 "버벅임"을 느낄 수 있습니다. QUIC 프로토콜은 TLS 핸드셰이크를 전송 핸드셰이크에 통합하여 연결 수립을 1 RTT로 줄입니다. 이는 모바일 경험에서 큰 장점입니다. 반면 VMess는 추가적인 애플리케이션 계층 핸드셰이크가 필요하므로 약한 네트워크에서는 연결 수립이 1초를 넘을 수 있습니다.

유의할 점은 프로토콜의 비교를 회선 품질과 분리해서 볼 수 없다는 것입니다. 고품질 IEPL 전용선과 일반 TCP 프로토콜의 조합이 저품질 중계 회선과 QUIC 프로토콜의 조합보다 더 안정적일 수 있습니다. 프로토콜은 "데이터를 어떻게 전송할지"를 해결하고, 회선은 "데이터가 어느 경로로 갈지"를 해결하므로 둘을 함께 평가해야 합니다.

회선 토폴로지: 직접 연결, 중계, 전용선

회선 토폴로지는 사용자 기기에서 대상 서버까지 데이터가 몇 개의 홉을 거치고 어떤 물리적 경로를 타는지를 결정합니다. 일반적인 토폴로지는 직접 연결, 중계, 전용선 세 가지입니다. 이 차이를 이해하는 것이 회선이 "가치 있는지"를 판단하는 핵심입니다.

직접 연결(Direct)

직접 연결은 사용자 기기와 대상 노드 사이에 중간 전달 서버가 없이 데이터가 공중망 라우팅을 통해 직접 노드에 도달하는 방식입니다. 직접 연결의 장점은 지연 시간이 낮다는 점입니다. 경로가 가장 짧고 추가 홉 오버헤드가 없기 때문입니다. 하지만 단점은 안정성이 전적으로 공중망 라우팅 품질에 달려 있다는 것입니다. 피크 시간대에는 공중망 국제 출구 대역폭이 부족해져 직접 연결 회선에서 눈에 띄는 패킷 손실과 지터가 발생할 수 있습니다. 또한 직접 연결 회선은 통신사 간(예: 모바일에서 다른 통신사 출구로 접속) 라우팅이 우회할 수 있어 실제 지연 시간이 이론값보다 훨씬 높아질 수 있습니다.

중계(Relay)

중계 회선은 사용자와 대상 노드 사이에 한 대 이상의 전달 서버를 삽입합니다. 이 전달 서버들은 보통 백본망이나 국제 출구의 핵심 위치에 배포되어 라우팅 경로를 최적화하고 혼잡 구간을 우회할 수 있습니다. 중계의 장점은 안정성이 좋다는 점입니다. 공중망 일부 구간이 혼잡해도 중계 서버가 예비 라우팅으로 우회하여 연결을 유지할 수 있습니다. 대가는 지연 시간 증가입니다. 홉을 하나 거칠 때마다 물리적 거리에 따라 약 5~15ms의 지연 시간이 추가됩니다.

중계는 다시 "일반 중계"와 "스마트 중계"로 나뉩니다. 일반 중계는 특정 전달 서버를 고정적으로 사용하므로 경로가 상대적으로 고정적입니다. 스마트 중계는 실시간 네트워크 상태에 따라 최적 경로를 동적으로 선택하며, BGP 경로 선택과 유사합니다. NZVPN의 중계 회선은 대부분 스마트 경로 선택을 사용하며, 피크 시간대에는 자동으로 지연 시간이 더 낮은 경로로 전환됩니다.

전용선(IEPL)

IEPL(International Ethernet Private Line)은 통신사가 제공하는 점대점 전용선 서비스로, 물리적으로 대역폭을 독점하며 공중망을 거치지 않습니다. 전용선의 지연 시간은 매우 낮고(보통 공중망 직접 연결보다 20~40% 낮음) 패킷 손실이 거의 없습니다. 전체 링크가 독점되어 다른 사용자의 트래픽 영향을 받지 않기 때문입니다. 전용선의 단점은 가격이 비싸다는 점이며, 따라서 소수의 인기 노드에만 배포되는 경우가 일반적입니다.

세 가지 토폴로지의 선택 논리는 다음과 같이 요약할 수 있습니다. 극한의 속도를 원하면 전용선, 안정성을 원하면 중계, 낮은 지연 시간과 좋은 네트워크 환경을 원하면 직접 연결. NZVPN의 회선 목록에는 각 회선에 유형 태그가 표시됩니다. IEPL 전용선, 중계, 직접 연결. 클라이언트에서도 회선 유형별로 필터링할 수 있습니다.

NZVPN의 220개 이상 회선은 전용선, 중계, 직접 연결이 비율에 맞게 구성되어 120개 이상 국가를 커버합니다. 인기 지역(홍콩, 싱가포르, 미국)은 보통 세 가지 토폴로지를 모두 제공하므로 사용자가 사용 시나리오에 따라 선택할 수 있습니다. 예를 들어 Netflix를 볼 때는 전용선, 일상적인 브라우징은 중계, 게임은 직접 연결을 추천합니다.

패킷 손실과 피크 시간대 혼잡의 원인과 대응

패킷 손실은 크로스보더 네트워크에서 가장 흔한 성능 저하 요인입니다. 패킷 손실의 원인을 이해해야 회선이 장기적으로 사용할 가치가 있는지 판단할 수 있습니다. 패킷 손실의 원인은 크게 물리적 링크 손실, 라우터 큐 오버플로, 라우팅 우회 세 가지로 나눌 수 있습니다.

물리적 링크 손실

해저 광케이블과 육상 광케이블은 장거리 전송에서 신호 감쇠가 발생하며, 전기 신호나 광 신호가 중계기를 거칠 때 오류가 발생할 수 있습니다. 오류율이 정상 범위 내에 있으면 링크 계층의 오류 수정 메커니즘이 처리하므로 상위 프로토콜에 영향을 주지 않습니다. 하지만 링크가 노후화되거나 날씨의 영향을 받으면 오류율이 상승하여 오류 수정 능력을 초과한 데이터 패킷이 직접 폐기됩니다. 이런 유형의 패킷 손실은 보통 지속적이며, 특정 회선이 장기간 불안정한 형태로 나타납니다.

라우터 큐 오버플로

이것이 피크 시간대 패킷 손실의 가장 큰 원인입니다. 인터넷상의 라우터에는 버퍼(큐)가 있으며, 특정 방향의 트래픽이 링크 대역폭을 초과하면 데이터 패킷이 큐에서 대기하며 전달을 기다립니다. 큐가 가득 차면 새로 도착한 데이터 패킷이 폐기됩니다. 피크 시간대에는 국제 출구 대역폭을 많은 사용자가 공유하므로 큐 오버플로 확률이 크게 상승하여 패킷 손실률이 평시 0.1%에서 3%~10%로 치솟을 수 있습니다.

혼잡 제어 알고리즘의 역할은 송신 측이 네트워크 혼잡을 감지하고 전송 속도를 자발적으로 낮춰 지속적인 패킷 손실을 피하도록 하는 것입니다. TCP의 CUBIC 알고리즘은 패킷 손실 후 혼잡 윈도우를 절반으로 줄이는데, 이는 혼잡을 완화하지만 처리량이 급감하는 원인이 됩니다. BBR 알고리즘은 병목 대역폭과 최소 RTT를 측정하여 동적으로 속도를 조절하므로 패킷 손실 환경에서 더 높은 처리량을 유지할 수 있습니다. QUIC는 기본적으로 BBR과 유사한 혼잡 제어를 사용하므로 높은 패킷 손실 환경에서 더 나은 성능을 보입니다.

라우팅 우회

라우팅 우회는 패킷 손실 자체는 아니지만 간접적으로 패킷 손실을 유발할 수 있습니다. 공중망 라우팅이 장애나 혼잡으로 인해 더 긴 경로로 전환되면 RTT가 크게 증가하고 데이터 패킷이 큐에 머무는 시간이 길어져 타임아웃 재전송이 발생하기 쉬워집니다. 타임아웃 재전송은 혼잡을 더욱 악화시켜 악순환을 만듭니다. 중계 회선의 핵심 가치 중 하나는 우회를 피하는 것입니다. 백본망의 전달 노드를 통해 경로를 "곧게" 만들어 불필요한 홉을 줄입니다.

피크 시간대 혼잡에 대응하기 위해 사용자 측에서 할 수 있는 선택은 제한적이지만 몇 가지 효과적인 전략이 있습니다. 첫째, IEPL 전용선 회선을 우선 선택하세요. 전용선은 대역폭을 독점하므로 공중망 혼잡의 영향을 받지 않습니다. 둘째, 클라이언트에서 QUIC 기반 프로토콜(Hysteria2/TUIC)을 활성화하세요. 이들은 패킷 손실에 대한 허용 범위가 더 높습니다. 셋째, 가장 혼잡한 시간대(보통 현지 저녁 20:00~23:00)를 피하거나 부하가 낮은 노드로 전환하세요.

NZVPN의 회선 목록은 각 회선의 지연 시간과 대역폭을 실시간으로 표시합니다. 특정 회선이 피크 시간대에 지속적으로 높은 지연 시간이나 낮은 대역폭을 보이면 같은 지역의 다른 회선으로 전환해 볼 수 있습니다. 클라이언트에 내장된 자동 회선 선택 기능도 연결 품질이 저하되면 사용자에게 전환을 안내합니다.

사용 시나리오별 프로토콜과 회선 선택

마지막으로 프로토콜과 토폴로지에 대한 논의를 구체적인 시나리오에 적용해 보겠습니다. 용도에 따라 네트워크 특성에 대한 중점이 다르므로, 선택할 때 가장 핵심적인 요구를 우선 충족해야 합니다.

위 표의 추천은 절대적이지 않으며, 실제 사용에서는 특정 회선의 실시간 상태를 함께 고려해야 합니다. 예를 들어 직접 연결 회선이 피크 시간대에 중계 회선보다 느릴 수 있으며, 이 경우 일시적으로 중계 회선으로 전환해야 합니다. NZVPN 클라이언트는 프로토콜과 회선 유형별 필터링을 지원하므로 사용자가 당시 네트워크 상황에 맞게 유연하게 조정할 수 있습니다.

대부분의 사용자에게 실용적인 전략은 기본적으로 VLESS + 중계 회선을 사용하는 것입니다. 이 조합은 안정성과 속도 사이에서 좋은 균형을 제공합니다. 특정 회선이 피크 시간대에 속도가 눈에 띄게 떨어지면 Hysteria2나 전용선 회선으로 전환하세요. 기기 배터리 수명이 부족하면 Shadowsocks로 바꿔 배터리를 절약하세요.

구독 요금제에 대해 말하자면, 4K 스트리밍을 자주 보거나 AI 도구를 사용한다면 250GB 또는 500GB 월 구독 요금제를 선택하는 것이 좋습니다. 트래픽이 더 넉넉하기 때문입니다. 일상적인 브라우징만 한다면 60GB 기본 요금제로 충분합니다. 트래픽 팩은 사용량 변동이 큰 사용자에게 적합하며, 구매 후 영구적으로 만료되지 않으므로 필요에 따라 추가할 수 있습니다.

마지막으로 어떤 프로토콜과 회선을 선택하든 30일 무조건 환불이 시행착오의 여지를 제공합니다. 먼저 한 달을 구독하고 실제 네트워크 환경에서 다양한 회선의 성능을 테스트한 뒤 장기적으로 어떤 요금제를 사용할지 결정할 수 있습니다.