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

한 번의 국제 연결에서 벌어지는 일

한 번의 접속을 뜯어보면 데이터는 기기에서 목표 서비스까지 다섯 단계를 거칩니다. 기기의 클라이언트 → 로컬 네트워크(공유기, 모뎀, 무선 구간) → 통신사 출구 → 국제 구간 → 착지 노드 → 목표 서비스 순입니다. 앞의 두 단계는 사용자가 통제할 수 있고, 세 번째 단계는 통신사가 결정하며, 네 번째와 다섯 번째 단계가 바로 가속 서비스가 실제로 최적화할 수 있는 부분입니다.

이 문장을 이해하는 게 중요합니다. 국제 회선 가속 서비스는 집 인터넷 회선의 품질을 바꿀 수 없고, 목표 서비스 자체의 응답 속도도 바꿀 수 없습니다. 할 수 있는 일은 '통신사 출구 → 착지 노드' 구간을 더 통제 가능한 경로로 바꾸는 것뿐입니다. 그래서 느리다고 느껴질 때는 노드를 계속 바꾸는 것보다 문제가 어느 구간에서 생겼는지 먼저 가려내는 편이 훨씬 효과적입니다.

프로토콜과 회선은 서로 독립된 두 축

많은 설명이 이 둘을 뒤섞어 다루다 보니 읽을수록 더 헷갈리게 됩니다. 하지만 이들은 서로 다른 두 가지입니다.

• 프로토콜은 데이터를 어떻게 캡슐화하고, 어떻게 암호화하고, 어떻게 핸드셰이크할지를 결정합니다. 소프트웨어 계층의 약속이며, 같은 프로토콜을 여러 회선 위에서 돌릴 수 있습니다.
• 회선은 패킷이 실제로 어떤 물리 경로를 지나고, 어떤 데이터센터를 거치고, 어느 홉에서 해외로 빠져나가는지를 결정합니다. 네트워크 계층의 사실이며, 같은 회선 위에서 어떤 프로토콜이든 돌릴 수 있습니다.

비유하자면, 프로토콜은 택배를 보낼 때 고르는 봉투와 봉인 방식이고 회선은 택배가 실제로 지나는 운송 경로입니다. 봉투가 아무리 좋아도 경로가 막히면 느리고, 경로가 아무리 순조로워도 봉투가 규격에 맞지 않으면 반송될 수 있습니다. 둘은 따로 평가해야 하고, 조합했을 때 비로소 의미가 있습니다.

본 서비스의 클라이언트에서는 이 구분이 그대로 드러납니다. 지역 사이드바의 각 행에는 회선 유형 배지(전용선 / 중계 / 직결)가 붙어 있고, 프로토콜은 현재 회선 카드 아래에서 따로 선택합니다. 이렇게 하면 회선을 고정한 채 프로토콜만 바꾸거나, 프로토콜을 고정한 채 회선만 바꾸면서 변수를 하나씩 제거할 수 있습니다. 전체 회선 목록은 회선 페이지에서 확인할 수 있습니다.

지연은 네 가지 요소로 구성됩니다

사용자가 체감하는 '빠르고 느림'은 기술적으로는 주로 지연으로 나타납니다. 지연은 하나의 숫자가 아니라 최소 네 가지 요소가 겹쳐 만들어진 값입니다.

1. 물리적 전파 지연. 빛이 광섬유를 지나는 속도는 초당 약 20만 킬로미터로, 이는 넘을 수 없는 상한입니다. 중국 동부에서 일본 도쿄까지를 예로 들면 직선거리가 약 2000킬로미터이고, 편도 이론 하한은 약 10밀리초, 왕복으로는 약 20밀리초입니다. 즉 아시아 권역에서 왕복 20~40밀리초는 이미 물리적 한계에 가까워 더 줄일 여지가 거의 없습니다.
2. 경로 우회. 패킷이 반드시 직선으로 가는 것은 아닙니다. 공용 인터넷의 라우팅은 통신사 간 상호접속 관계로 정해지기 때문에 제3의 지역을 거치는 일이 흔합니다. 직선거리 2000킬로미터 구간이 실제로는 5000킬로미터를 지나기도 합니다.
3. 대기 지연. 공유기와 스위치의 출구 대역폭은 한정되어 있어 트래픽이 많으면 패킷이 줄을 서게 됩니다. 대기 지연은 링크 이용률이 70%를 넘으면 빠르게 치솟는데, 이것이 야간 시간대가 느려지는 주된 원인입니다.
4. 프로토콜 핸드셰이크 비용. 연결을 맺는 것 자체에 왕복이 필요합니다. TCP 3방향 핸드셰이크에 TLS 핸드셰이크까지 더하면 보통 1~2회의 왕복 시간이 추가로 듭니다. 이 부분은 회선 품질과 무관하지만, 프로토콜 선택과 연결 재사용으로 줄일 수 있습니다.

앞의 두 가지는 회선이 결정하고, 세 번째는 회선 품질과 시간대가 함께 결정하며, 네 번째는 프로토콜이 결정합니다. 그래서 '프로토콜 선택'과 '회선 선택'을 따로 해야 하는 것입니다. 둘이 최적화하는 구간이 서로 다르니까요.

평균 지연보다 체감에 더 큰 영향을 주는 지터와 패킷 손실

평균 지연은 세 가지 지표 중 하나일 뿐입니다. 나머지 둘도 똑같이 중요합니다.

• 지터: 지연이 흔들리는 폭입니다. 평균 60밀리초에 변동이 ±5밀리초인 회선이, 평균 50밀리초에 변동이 ±40밀리초인 회선보다 체감상 훨씬 낫습니다. 화상 회의와 실시간 음성 통화가 지터에 가장 민감합니다.
• 패킷 손실: 패킷이 상대방에 도달하지 못하는 것입니다. TCP 계열 프로토콜은 패킷 손실이 생기면 재전송하고 전송 속도를 낮춥니다. 1%의 패킷 손실이 롱팻 파이프(지연이 크고 대역폭이 넓은 링크)에서는 처리량을 절반 이상 떨어뜨릴 수 있습니다.

따라서 회선을 평가할 때는 지연 숫자만 볼 게 아니라, 야간 혼잡 시간대에 지터와 패킷 손실이 안정적인지도 봐야 합니다. 회선 페이지에는 각 회선의 유형이 표시되어 있는데, 유형 자체가 그 회선의 안정성 특성을 암시합니다. 이 부분은 아래 회선 토폴로지 섹션에서 자세히 다룹니다.

6종 주요 프로토콜의 설계상 장단점

프로토콜에 절대적인 우열은 없고 설계 목표의 차이만 있을 뿐입니다. 아래 여섯 가지는 현재 클라이언트에서 가장 흔히 쓰이는 선택지입니다. 이들 사이에는 다른 어떤 차이보다 중요한 경계선이 하나 있습니다. 앞의 네 가지는 TCP 기반이고, 뒤의 두 가지는 QUIC 기반(즉 UDP 위에서 동작)이라는 점입니다. 이 경계선이 열악한 네트워크 환경에서의 동작 방식을 완전히 갈라놓습니다.

• Shadowsocks TCP / AEAD

  가벼운 암호화 프록시로 자원 사용량이 가장 낮고 구형 기기에도 부담이 없습니다.

• VMess TCP / 다중 전송 계층

  기능이 완전하고 복잡한 분기 라우팅을 지원하지만 핸드셰이크 비용이 큰 편입니다.

• Trojan TLS / 443

  프록시 트래픽을 표준 HTTPS로 위장해 흔적이 잘 드러나지 않습니다.

• VLESS TLS / 간소화

  내장 암호화 계층을 제거해 핸드셰이크가 가볍고 처리량이 앞서는 편입니다.

• Hysteria2 QUIC / UDP

  패킷 손실이 많은 링크에 맞춰 튜닝되어 대역폭 유지 능력이 가장 뛰어납니다.

• TUIC QUIC / UDP

  0-RTT 복구를 지원해 모바일에서 네트워크를 바꾼 뒤 빠르게 되돌아옵니다.

Shadowsocks: 충분하면 되는 가벼운 선택

Shadowsocks의 설계 목표는 '충분하면 된다'입니다. 로컬 트래픽을 암호화해 원격 노드로 전달하는 가벼운 암호화 프록시입니다. 복잡한 핸드셰이크 프로토콜이 없고 AEAD 계열 암호화 알고리즘을 사용하며, 연결마다 붙는 헤더 오버헤드가 매우 작습니다.

장점은 분명합니다. 구현이 단순하고 CPU와 메모리 사용량이 낮으며, 구형 기기와 공유기에서도 돌아가고 클라이언트 생태계가 매우 성숙합니다. 단점도 같은 지점에서 나옵니다. 기능을 절제했기 때문입니다. 기본 제공되는 다중화가 없어 연결마다 따로 맺어야 하고, 위장 능력은 플러그인이나 전송 계층의 도움에 의존하므로 그대로 쓸 때는 트래픽 특성이 비교적 일정합니다.

누구에게 맞나: 공유기, 구형 스마트폰, 구형 PC, 그리고 웹 브라우징과 가벼운 업무만 하는 환경입니다. 기기 성능이 제한적이라면 Shadowsocks가 문제가 가장 적게 생기는 선택인 경우가 많습니다.

VMess: 기능은 완전하지만 더 무거운 쪽

VMess는 V2Ray 프로젝트가 자체 개발한 프로토콜로, 설계가 Shadowsocks보다 훨씬 완전합니다. 여러 전송 계층(TCP, WebSocket, gRPC, HTTP/2)을 지원하고, 도메인·IP·포트에 따라 어느 회선으로 보낼지 정하는 완전한 라우팅 분기 규칙을 지원합니다.

타임스탬프가 포함된 인증 핸드셰이크를 사용한다는 점이 가장 주의할 부분입니다. 클라이언트와 서버의 시계가 거의 일치해야 하며, 차이가 크면 인증 자체가 실패합니다. '어제까지 잘 되다가 오늘은 연결이 안 된다'는 사례의 상당수는 기기 시간이 어긋난 것이 원인입니다.

핸드셰이크 비용이 Shadowsocks보다 조금 크고, 연결을 맺는 데 필요한 왕복 횟수도 더 많습니다. 복잡한 분기 규칙이 필요한 환경이라면 이 비용은 충분히 값어치가 있지만, 단순한 프록시 용도라면 다소 무겁습니다. 누구에게 맞나: 도메인별 분기, 여러 개의 아웃바운드 규칙이 필요하고 설정에 시간을 들일 의향이 있는 사용자입니다.

Trojan: 프록시를 표준 HTTPS로 위장

Trojan은 접근이 완전히 다릅니다. 새로운 암호화 방식을 만들지 않고, 프록시 트래픽을 표준 HTTPS 트래픽으로 위장해 TLS를 그대로 사용합니다. 밖에서 보면 평범한 TLS 연결과 다를 바 없는데, 프로토콜 수준에서 실제로 그렇기 때문입니다.

이 설계의 이점은 흔적이 잘 드러나지 않는다는 점입니다. 트래픽 형태가 실제 웹사이트에 접속할 때와 거의 구분되지 않습니다. 대가는 배포상의 결합입니다. 443 포트를 점유하고 유효한 인증서를 설정해야 하며, 다른 서비스가 443을 가져가면 충돌합니다.

성능 면에서 Trojan의 비용은 주로 TLS 자체에서 나옵니다. 최신 클라이언트의 TLS 1.3 핸드셰이크는 이미 상당히 빨라서 실제 체감은 VLESS와 비슷합니다. 누구에게 맞나: 프록시 트래픽을 일반 HTTPS와 구분하기 어렵게 만들고 싶은 환경, 그리고 인증서를 갖출 수 있는 배포 환경입니다.

VLESS: 군더더기를 덜어낸 고처리량 노선

VLESS는 VMess의 간소화 버전으로 이해하면 됩니다. 내장 암호화 계층을 없애고 암호화를 전적으로 전송 계층(보통 TLS)에 맡깁니다. 암호화 계층이 하나 줄면 데이터 처리도 한 번 줄어 CPU 비용과 핸드셰이크 크기가 모두 작아집니다.

XTLS 계열 흐름 제어와 함께 쓰면 VLESS는 전달 과정에서 '복호화 후 재암호화' 단계를 한 번 줄일 수 있어 처리량이 여섯 가지 중 상위권에 듭니다. 대가는 TLS와 반드시 함께 써야 한다는 점입니다. 암호화 없는 순수 VLESS는 단독으로 쓰기에 적합하지 않습니다. 설정 형태는 VMess와 비슷해서 V2Ray 계열 클라이언트에 익숙한 사용자라면 어렵지 않게 적응합니다.

누구에게 맞나: 최신 클라이언트, 처리량을 중시하는 환경, TLS 조건을 갖춘 환경입니다. 일상적인 브라우징과 AI 도구의 장기 연결에서는 VLESS가 안정적인 기본 선택입니다.

Hysteria2: 패킷 손실이 많은 링크를 위한 선택

Hysteria2는 QUIC 기반으로 UDP 위에서 동작합니다. 가장 눈여겨볼 점은 암호화가 아니라 혼잡 제어입니다. 패킷 손실이 많은 링크에 맞춰 튜닝된 혼잡 제어 알고리즘(BBR 계열)을 사용해, 국제 구간처럼 거리가 길고 손실이 있는 링크에서 처리량 유지 능력이 전통적인 TCP 계열 프로토콜보다 확실히 낫습니다.

이유는 TCP가 패킷 손실을 무조건 '네트워크 혼잡'으로 해석해 속도를 낮추고 재전송하기 때문입니다. 반면 국제 구간의 패킷 손실은 혼잡과 무관한 경우가 많아, 속도를 낮추는 것은 대역폭을 그냥 버리는 셈입니다. QUIC 계열 프로토콜은 사용자 공간에서 더 똑똑한 판단을 구현해 '진짜 혼잡'과 '무작위 손실'을 구분할 수 있습니다.

대가는 두 가지입니다. 첫째, UDP를 사용하기 때문에 일부 네트워크 환경에서는 UDP에 추가 제한이나 속도 제한이 걸려 실제 성능이 떨어질 수 있습니다. 둘째, 암호화와 혼잡 제어를 모두 사용자 공간에서 처리하므로 CPU 사용량과 배터리 소모가 TCP 계열 프로토콜보다 조금 높습니다. 누구에게 맞나: 국제 구간 장거리, 야간 혼잡 시간대에 패킷 손실이 뚜렷한 경우, 안정적인 대역폭이 필요한 환경, 예를 들어 4K 스트리밍과 대용량 파일 다운로드입니다.

TUIC: 연결 수립을 0-RTT로 압축

TUIC도 QUIC 기반이지만 설계 방향이 '속도'에 더 치우쳐 있습니다. 연결 수립을 0-RTT로 압축해, 세션을 복구할 때 완전한 핸드셰이크 없이 바로 데이터를 보낼 수 있습니다.

이 특성은 모바일에서 특히 값어치가 있습니다. 스마트폰이 Wi-Fi와 셀룰러를 오갈 때 연결이 끊겼다가 다시 맺어지는데, TUIC는 재연결 속도가 더 빨라 체감상 '네트워크를 바꿔도 영상이 끊기지 않는' 수준입니다. 다만 생태계 규모는 앞의 몇 가지보다 작고 일부 클라이언트의 지원이 제한적이므로, 선택하기 전에 자주 쓰는 클라이언트가 지원하는지 먼저 확인하세요.

누구에게 맞나: 스마트폰, 태블릿처럼 네트워크를 자주 바꾸는 기기, 그리고 연결 복구가 빨라야 하는 환경입니다.

6종 프로토콜 비교표

연결 수립 속도와 자원 사용량

'연결에 1~2초 걸린다'와 '연결한 뒤 속도가 느리다'는 서로 다른 문제입니다. 전자는 핸드셰이크 비용, 후자는 회선 품질에 속합니다. 이 섹션에서는 전자와, 그것이 모바일 기기에서 드러나는 또 다른 얼굴인 배터리를 다룹니다.

첫 연결에는 몇 번의 왕복이 필요할까

착지 노드까지 연결을 맺을 때 패킷 하나를 보낸다고 바로 데이터 전송이 시작되지는 않습니다. TCP 계열 프로토콜을 예로 들면 다음과 같습니다.

1. TCP 3방향 핸드셰이크로 왕복 시간 1회가 소모됩니다.
2. TLS 핸드셰이크(TLS 1.3)로 왕복 시간 1회가 추가로 소모됩니다.
3. 프로토콜 자체의 인증은 보통 TLS 핸드셰이크에 얹어 함께 끝낼 수 있습니다.

따라서 왕복 60밀리초인 회선에서 첫 연결의 '만남 비용'은 약 120밀리초입니다. 웹페이지 하나를 열 때는 이 숫자가 느껴지지 않지만, 클라이언트가 요청마다 새 연결을 맺으면 누적되면서 확연히 드러납니다.

세션 복구는 비용을 왕복 1회 이내로 줄입니다

TLS 1.3은 세션 복구를 지원합니다. 클라이언트와 서버가 첫 연결 뒤에 '티켓'을 주고받고, 이후 연결은 그 티켓으로 곧바로 암호화 전송에 들어가 핸드셰이크가 왕복 0회로 줄어듭니다. QUIC 계열 프로토콜(Hysteria2, TUIC)은 이를 기본 지원하며, TUIC는 0-RTT를 핵심 강점으로 내세웁니다.

실제 영향은 이렇습니다. 같은 클라이언트가 몇 분 안에 같은 노드에 다시 접속하면 두 번째부터는 핸드셰이크 비용이 거의 없습니다. 그래서 '연결한 뒤에는 쾌적한데 재연결할 때마다 1~2초를 기다려야 한다'는 상황은 대개 회선 자체의 문제가 아니라 핸드셰이크 경로의 어느 단계가 느려졌기 때문입니다. 예를 들어 클라이언트가 지연 측정을 하거나 회선 목록을 동기화하는 경우입니다.

다중화: 연결 하나로 모든 요청을 처리

다중화란 이미 맺어진 연결 하나에서 여러 요청을 동시에 처리하는 것입니다. 장점은 핸드셰이크가 한 번이면 되고 이후 요청은 그대로 재사용한다는 점이고, 단점은 이 연결에 문제가 생기면 모든 요청이 함께 영향을 받는다는 점입니다.

Shadowsocks에는 기본 다중화가 없고, VMess와 VLESS는 지원하며, QUIC 계열 프로토콜은 전송 계층에서 자연스럽게 지원합니다. 일상적인 사용에서 다중화가 주로 개선하는 것은 '작은 요청이 많은 웹페이지를 열 때'입니다. 첫 화면에 수십 개의 리소스를 불러와야 하는 페이지에서는 연결을 재사용할 때 체감이 확실히 매끄럽습니다.

모바일 배터리: 실제 소모 원인 세 가지

스마트폰의 배터리 소모는 주로 세 곳에서 발생하며, 프로토콜 선택과의 연관성은 순서대로 낮아집니다.

1. 하트비트와 연결 유지. 연결을 살아 있게 유지하려고 클라이언트가 주기적으로 작은 패킷을 보냅니다. 주기가 짧을수록 배터리를 더 먹습니다. 적절한 간격은 수십 초에 한 번이며, 지나치게 잦으면(예: 1초에 한 번) 대기 시간에 확실히 영향을 줍니다.
2. UDP와 무선 모듈 깨우기. QUIC 계열 프로토콜은 UDP를 사용하는데, 일부 모바일 운영체제는 UDP에 대해 전원 관리를 더 적극적으로 적용해 무선 모듈을 더 자주 깨울 수 있습니다. Hysteria2와 TUIC가 모바일 기기에서 TCP 계열 프로토콜보다 배터리를 조금 더 쓰는 주된 이유입니다.
3. 암복호화와 혼잡 제어 연산. 이 두 가지는 모두 사용자 공간에서 처리되므로 CPU 사용량이 조금 높아지면 배터리도 조금 더 듭니다. 최신 모바일 칩은 이런 부하를 가볍게 처리하기 때문에 실제 영향은 가장 작습니다.

실전 조언: 기기가 대기 상태로 있다가 가끔 메시지만 주고받는다면 TCP 계열 프로토콜을 고르고, 오래 영상을 보거나 다운로드한다면 QUIC 계열 프로토콜의 대역폭 이점이 배터리 비용을 웃도는 경우가 대부분입니다.

자원 사용량 비교

표의 왕복 횟수는 프로토콜 원리 수준의 상대적 설명이며 실측 결과가 아닙니다. 실제 체감은 클라이언트 구현 품질, 회선의 왕복 시간, 기기 자체의 성능에도 좌우됩니다. 프로토콜을 바꾸기 전에 쓰는 클라이언트가 정말 지원하는지 먼저 확인하세요. 지원이 불완전하면 '더 나쁜 프로토콜로 바꾸는 것'이 '바꾸지 않는 것'보다 못합니다.

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

회선 토폴로지란 패킷이 클라이언트에서 착지 노드까지 어떤 노드를 거치고 어떤 링크를 지나는지를 말합니다. 이것이 야간 혼잡 시간대의 안정성을 결정하며, '낮에는 잘 되는데 밤에는 쓰기 어렵다'는 문제의 진짜 답인 경우가 많습니다.

직결: 경로는 가장 짧지만 품질은 가장 예측하기 어려움

직결은 가장 단순한 토폴로지입니다. 클라이언트가 해외 착지 노드에 바로 연결되고, 중간에 거치는 모든 홉이 공용 인터넷 라우팅으로 결정됩니다.

장점은 경로가 짧고 비용이 낮으며 배포가 유연하다는 것입니다. 단점도 분명합니다. 국제 구간이 공용 인터넷의 혼잡과 라우팅 변동에 그대로 노출됩니다. 같은 직결 회선이라도 새벽에는 잘 나오다가 저녁 8시 이후에는 쓰기 어려울 정도로 떨어질 수 있습니다. 성능은 통신사 간 상호접속 품질과 그 시간대에 같은 경로를 쓰는 사람 수에 달려 있습니다. 직결 회선은 안정성을 추구하는 선택이 아니라 '충분하면 되는' 선택으로 보는 게 맞습니다.

중계: 통제 가능한 구간 하나로 안정성을 얻는다

중계의 발상은 클라이언트와 착지 노드 사이에 입구 노드를 하나 두는 것입니다. 클라이언트가 먼저 가까운 입구에 연결하고, 입구 노드가 최적화된 경로를 따라 트래픽을 착지 노드로 보냅니다.

이 방식의 장점은 클라이언트에서 입구까지의 구간이 보통 같은 권역이나 같은 통신사 네트워크 안에 있어 경로가 짧고 품질이 좋다는 점입니다. 입구에서 착지까지의 구간은 서비스 제공자가 직접 설계하므로 공용 인터넷에서 혼잡이 심한 상호접속 지점을 피할 수 있습니다. 사용자가 느끼는 지연 = 클라이언트→입구 + 입구→착지이며, 두 구간 모두 통제 불가능했던 직결 경로보다 예측하기 쉽습니다.

대가는 홉이 하나 늘어 이론적으로 지연이 조금 더 생긴다는 점입니다. 하지만 야간 혼잡 시간대에는 이 '늘어난 홉'이 혼잡 지점을 피해 가기 때문에 오히려 총 지연을 낮추는 경우가 많습니다. 중계 회선의 또 다른 장점은 입구를 가까운 곳에서 고를 수 있다는 것입니다. 같은 중계 회선이라도 지역마다 사용자가 다른 입구를 선택할 수 있어, 서비스 제공자가 지역마다 착지 노드를 따로 배치할 필요가 없습니다.

한 가지 유의할 점은 중계 노드의 품질이 회선 전체의 상한을 정한다는 것입니다. 입구 자체가 과부하라면 뒤쪽 경로를 아무리 최적화해도 소용없습니다. 서비스 제공자를 평가할 때 눈여겨볼 부분이기도 합니다. 회선 목록에서 중계로 표시된 항목은 개수가 많은지보다 입구가 얼마나 분산되어 있는지가 중요합니다.

전용선: 국제 구간을 고정한다

전용선(IEPL, 국제 이더넷 전용선)은 세 가지 토폴로지 중 가장 '무거운' 방식입니다. 국제 구간이 공용 인터넷을 지나지 않고, 서비스 제공자가 통신사에서 임차한 전용 링크를 지납니다. 이 링크는 약정된 대역폭과 품질 지표를 가지며, 다른 사용자의 트래픽과 같은 출구를 두고 경쟁하지 않습니다.

그 결과는 안정성입니다. 지연 변동이 작고, 야간 혼잡 시간대에도 거의 영향을 받지 않으며, 패킷 손실률이 장기간 매우 낮은 수준을 유지합니다. 연결을 오래 유지해야 하는 애플리케이션(화상 회의, 원격 데스크톱, AI 도구의 긴 세션, 대용량 파일 전송)에서 전용선의 가치는 '갑자기 떨어지지 않는다'는 데 있고, '최고 속도가 얼마나 빠른가'에 있지 않습니다.

대가는 비용과 커버리지입니다. 전용선은 단위 대역폭 비용이 공용 인터넷보다 훨씬 높아 보통 수요가 가장 큰 지역과 도시에만 배치되며, 직결처럼 넓게 깔리지는 않습니다. 본 서비스의 회선 목록에서 IEPL 전용선으로 표시된 항목은 일본, 싱가포르, 미국, 홍콩, 이탈리아 등 자주 쓰이는 착지 지역에 집중되어 있는데, 이는 사용자가 가장 많이 찾는 곳에 우선 배치한다는 전용선의 배치 논리와도 맞습니다.

세 가지 토폴로지, 어떻게 고를까

선택 순서에 관한 실용적인 방법은 이렇습니다. 기본은 중계로 두고, 안정성이 중요한 작업에는 전용선으로 바꾸며, 직결은 지연에 민감하지 않은 가벼운 용도로 남겨 둡니다. 본 서비스의 클라이언트는 지역 사이드바에서 회선 유형을 바로 바꿀 수 있어 구독을 다시 가져올 필요가 없습니다. 전체 회선 목록을 먼저 보고 싶다면 회선 페이지를 열어 지역별로 살펴보세요.

패킷 손실과 야간 혼잡의 원인

야간 혼잡 시간대의 속도 저하는 국제 접속에서 가장 흔한 불만이자 가장 오해받기 쉬운 현상입니다. 대개 '서비스 제공자의 속도 제한'이 아니라 설명 가능한 몇 가지 메커니즘이 겹친 결과입니다. 이 메커니즘을 이해하면 회선을 바꿔야 할지, 프로토콜을 바꿔야 할지, 아니면 시간대를 옮겨야 할지 판단할 수 있습니다.

출구 대역폭은 공유 자원입니다

통신사 간 상호접속 대역폭은 한정되어 있고 모든 사용자가 공유합니다. 저녁 8시부터 11시까지는 가정용 인터넷 사용이 몰리는 시간으로, 같은 시간에 많은 사용자가 영상을 보고 다운로드하고 게임을 하면서 국제 방향 트래픽도 함께 늘어납니다. 특정 상호접속 링크의 이용률이 70%를 넘으면 대기 지연이 눈에 띄게 올라가고, 90%를 넘으면 패킷 손실이 나타나기 시작합니다.

이것은 흔한 현상을 설명해 줍니다. 같은 회선인데 낮에는 지연이 안정적이고 밤에는 몇 배로 치솟는 이유입니다. 회선 자체는 변하지 않았고, 다른 사용자와 공유하는 그 구간이 얼마나 붐비는지가 변한 것입니다.

패킷 손실이 생각보다 속도를 크게 떨어뜨리는 이유

TCP 설계에서는 패킷 손실을 혼잡 신호로 봅니다. 손실이 감지되면 송신 측이 전송 윈도를 절반으로 줄이고 다시 천천히 올립니다. 이 메커니즘은 근거리 네트워크에서는 효과적이지만, 국제 구간처럼 지연이 큰 링크에서는 문제를 키웁니다.

원인은 '롱팻 파이프' 효과입니다. 왕복 지연이 크고 대역폭이 넓은 링크에서는 송신 측이 많은 양의 데이터를 계속 띄워 두어야 대역폭을 가득 채울 수 있습니다. 패킷 손실 한 번에 윈도가 절반으로 줄고, 다시 올라오는 데 걸리는 시간은 왕복 지연에 비례합니다. 왕복 200밀리초인 회선에서는 윈도 복구에 몇 초가 걸릴 수 있고, 그 몇 초 동안 처리량은 최고치의 절반 또는 그 이하로 떨어집니다.

그래서 1%의 패킷 손실이 지연이 큰 링크에서는 30% 이상의 처리량 손실을 부를 수 있습니다. QUIC 계열 프로토콜(Hysteria2, TUIC)이 국제 구간에서 더 나은 성능을 내는 근본 이유도 여기에 있습니다. 사용자 공간에서 더 정교한 혼잡 판단을 구현해 무작위 손실과 진짜 혼잡을 구분하므로, 손실이 생겼다고 곧바로 크게 감속하지 않습니다.

무선 구간도 패킷 손실에 한몫합니다

모든 패킷 손실이 국제 구간에서 생기는 것은 아닙니다. 무선 구간은 가장 놓치기 쉬운 부분입니다.

• Wi-Fi 신호 약함. 내력벽 하나를 사이에 두거나 공유기에서 멀어지면 무선 재전송이 눈에 띄게 늘어납니다. 증상은 지연이 오르내리는 것이지, 꾸준히 느린 것이 아닙니다.
• 2.4GHz 대역 혼잡. 같은 대역을 쓰는 기기가 많으면 채널 경쟁으로 무작위 패킷 손실이 생깁니다. 5GHz 대역으로 바꾸면 보통 효과가 바로 나타납니다.
• 이동통신망 전환. 스마트폰이 기지국 사이를 이동할 때 짧은 연결 끊김이 생기는데, QUIC 계열 프로토콜이 더 빠르게 복구합니다.
• 공유기 성능 부족. 구형 공유기는 암호화 트래픽을 처리할 때 CPU가 포화되어 그 자체가 병목이 되고, '연결한 뒤 전반적으로 느려진다'는 증상으로 나타납니다.

확인 방법은 간단합니다. 같은 기기, 같은 회선으로 유선과 Wi-Fi를 각각 테스트해 보세요. 유선에서 확실히 낫다면 문제는 무선 구간에 있으므로 회선을 바꿔도 해결되지 않습니다.

바로 따라 할 수 있는 점검 순서

1. 범위 확인. 모든 사이트가 느린지, 하나만 느린지 봅니다. 하나만 느리다면 문제는 대개 목표 서비스나 그쪽 접속 경로에 있고, 내 회선에 있지 않습니다.
2. 회선 유형 변경. 중계에서 IEPL 전용선으로 바꿔 봅니다. 확실히 나아지면 원래 회선이 야간 혼잡의 영향을 받고 있었다는 뜻입니다.
3. 프로토콜 변경. TCP 계열에서 QUIC 계열(Hysteria2 / TUIC)로 바꿔 봅니다. 개선이 뚜렷하면 병목이 패킷 손실로 인한 감속에 있고 링크 자체에는 없다는 뜻입니다.
4. 접속 방식 변경. Wi-Fi를 유선으로 바꾸거나 5GHz 대역으로 옮깁니다. 이 단계에서 로컬 무선 구간의 간섭을 배제합니다.
5. 시간대 변경. 위의 방법이 모두 효과가 없다면 해당 시간대 전체가 혼잡한 것일 수 있습니다. 사람이 적은 시간대로 옮겨 테스트하면 이 판단을 확인할 수 있습니다.

이 다섯 단계의 순서에는 이유가 있습니다. 영향 범위가 가장 크고 조작이 가장 간단한 단계부터 시작해 범위를 좁혀 갑니다. 대부분의 경우 세 번째 단계 안에서 문제를 찾을 수 있습니다. 점검 중에 구독을 다시 가져와야 한다면 절차는 사용 가이드 페이지를 참고하세요.

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

앞의 섹션들에서 메커니즘을 설명했으니, 이번 섹션에서는 이를 바로 쓸 수 있는 대조표로 정리합니다. 선택의 핵심 원칙은 시나리오가 '지연 / 대역폭 / 안정성' 중 무엇에 가장 민감한지 먼저 보고, 그다음에 프로토콜과 회선의 조합을 정하는 것입니다.

웹 브라우징과 문서 업무

이런 환경은 요청이 많고 개별 요청이 작으며 첫 바이트 시간에 민감합니다. 프로토콜은 VLESS나 Trojan을 권합니다. TCP 기반이라 핸드셰이크 비용을 통제할 수 있고, 세션 복구와 함께 쓰면 반복 접속이 거의 느껴지지 않습니다. 회선은 중계로 충분하며, 다만 거주 지역의 중계 입구가 야간 혼잡 시간대에도 빠듯하다면 예외입니다.

공동 문서나 온라인 스프레드시트처럼 연결을 계속 유지하는 앱을 쓴다면 IEPL 전용선으로 바꾸는 편이 좋습니다. 이런 앱의 체감 병목은 최고 속도가 아니라 '편집할 때 한 번씩 멈추는지'인데, 전용선의 낮은 지터가 바로 여기에 맞습니다.

AI 도구와 개발 환경

AI 대화 도구와 코드 자동 완성 도구의 공통점은 세션 하나가 몇 분에서 수십 분까지 이어지고, 그 사이에 작은 요청이 많이 오가며, 연결이 끊기면 세션의 맥락을 처음부터 다시 쌓아야 할 수도 있다는 점입니다. 이런 환경에서는 최고 속도보다 안정성이 우선입니다.

권장 조합은 VLESS + IEPL 전용선입니다. VLESS는 장기 연결에서 자원 사용량이 낮고, 전용선은 세션이 끊기지 않게 해 줍니다. 사용 중인 네트워크가 UDP에 우호적이라면 Hysteria2도 시도해 볼 만한데, 장거리 링크에서 처리량 유지가 더 좋습니다. 명령줄 도구와 개발 환경의 프록시 설정은 개발자 시나리오를 다룬 글에 더 자세히 정리되어 있습니다.

4K 스트리밍

스트리밍의 대역폭 요구는 지속적입니다. 4K 재생은 보통 25 Mbps 이상이 안정적으로 유지되어야 하고, 재생 내내 그 대역폭이 오르내리지 않고 지켜져야 합니다. 프로토콜은 Hysteria2를 우선 권합니다. 혼잡 제어가 장거리 링크에서 대역폭을 더 잘 지켜 줍니다. 회선은 IEPL 전용선이나 품질 좋은 중계를 쓰세요.

또 하나 놓치기 쉬운 점은 착지 지역 선택입니다. 스트리밍 플랫폼의 지역 라이브러리는 출구 IP의 소속 지역에 묶여 있어, 지역을 잘못 고르면 '연결은 되는데 콘텐츠가 다른' 상황이 생깁니다. 지역을 고를 때는 해당 플랫폼이 어느 지역에 콘텐츠를 갖고 있는지를 먼저 보고, 그다음 그 지역에 전용선 노드가 있는지 확인하세요. 지역과 회선의 대응 관계는 회선 페이지에서 하나씩 확인할 수 있습니다.

모바일 기기와 잦은 네트워크 전환

스마트폰과 태블릿은 Wi-Fi와 셀룰러를 오가고 기지국 사이를 이동합니다. 이런 환경에서는 '연결 복구 속도'가 무엇보다 중요합니다. 프로토콜은 TUIC가 첫 번째 선택입니다. 0-RTT 복구 덕분에 전환 후 재연결이 거의 느껴지지 않습니다. 클라이언트가 TUIC를 지원하지 않으면 VLESS로 대신하세요.

회선은 중계로 충분합니다. 이동통신망 자체의 품질 변동이 이미 커서 전용선의 안정성 이점이 모바일 환경에서는 그렇게 두드러지지 않습니다. 배터리에 민감한 사용자는 대기 상태에서 하트비트 비용이 더 낮은 TCP 계열 프로토콜을 우선하면 됩니다.

공유기와 여러 기기 공유

공유기에서 프록시를 돌릴 때는 CPU와 메모리가 절대적인 제약이라 프로토콜이 가벼울수록 좋습니다. Shadowsocks가 이런 환경에서 가장 무난한 선택입니다. 구현이 단순하고 자원 사용량이 낮으며 클라이언트 지원이 넓습니다. 공유기 성능이 괜찮다면 VLESS도 고려할 만합니다.

본 서비스의 요금제는 기기 대수를 제한하지 않으므로 공유기, 스마트폰, PC를 동시에 연결할 수 있고 기기마다 따로 결제할 필요가 없습니다. 트래픽은 공유되며 개통일 기준으로 매월 초기화됩니다. 공유기에 연결된 모든 기기를 끌어들이면 트래픽 소모가 단일 기기 사용보다 훨씬 빠르다는 점은 미리 감안하세요.

시나리오별 빠른 대조표

클라이언트의 회선과 프로토콜 설정

본 서비스의 클라이언트는 위의 선택들을 몇 개의 스위치로 만들어 두어 설정 파일을 직접 쓸 필요가 없습니다. 이 섹션에서는 각 스위치가 어느 계층에 해당하는지, 언제 건드려야 하는지 설명합니다.

지역 사이드바와 회선 유형 배지

클라이언트 왼쪽에는 지역 목록이 있고, 각 행에 지역과 도시, 그리고 회선 유형 배지가 표시됩니다.

• IEPL 전용선 국제 구간이 전용 링크를 지나 안정성이 가장 좋고, 장기 연결과 스트리밍에 적합합니다.
• 중계 가까운 입구를 거쳐 전달되며, 일상 사용의 기본 선택입니다.
• 직결 착지 노드에 바로 연결되며 경로가 가장 짧지만 품질은 공용망 상황에 따라 달라집니다.

같은 지역에 여러 회선 유형이 함께 제공될 수 있는데, 이때는 앞 섹션의 시나리오 대조표를 보고 고르면 됩니다. 회선을 바꿀 때 구독을 다시 가져올 필요는 없고 클라이언트가 곧바로 연결을 다시 맺습니다.

현재 회선 카드와 자동 선택

메인 영역 위쪽의 현재 회선 카드에는 착지 도시, 회선 유형, 현재 사용 중인 프로토콜 세 가지가 표시됩니다. 카드 오른쪽의 '자동 선택' 스위치를 켜면 클라이언트가 선택한 지역 범위 안에서 현재 상태가 좋은 회선을 자동으로 골라 줍니다.

자동 선택은 '매번 직접 고르고 싶지 않을 때'에 맞고, '출구 IP를 고정해야 할 때'에는 맞지 않습니다. 일부 서비스는 로그인 지역을 기억하므로 자주 바뀌면 추가 인증이 걸릴 수 있습니다. 고정이 필요하면 자동 선택을 끄고 회선을 직접 지정하세요.

프로토콜 전환

현재 회선 카드 아래에는 해당 회선이 지원하는 프로토콜이 칩 형태로 나열됩니다. 한 번 누르면 전환됩니다. 프로토콜을 바꾸면 연결이 다시 맺어지고 이미 열려 있던 세션이 잠시 끊기므로, 회의 중이거나 다운로드 중일 때는 가볍게 바꾸지 마세요.

특정 프로토콜이 쓰는 네트워크 환경에서 연결되지 않는다면 보통 두 가지 이유가 있습니다. 첫째, 그 프로토콜이 의존하는 전송 계층이 로컬 네트워크에서 막힌 경우입니다(예: UDP가 제한되면 QUIC 계열 프로토콜이 실패합니다). 둘째, 클라이언트 버전이 오래되어 지원하지 않는 경우입니다. 두 번째는 클라이언트를 업그레이드하면 되고, 클라이언트는 패널의 다운로드 페이지에서 로그인 후 받을 수 있습니다.

기기 목록과 구독 동기화

창 아래쪽의 기기 목록에는 같은 구독을 사용 중인 기기가 표시되고, 각 행에 플랫폼 아이콘과 동기화 상태가 붙습니다. 본 서비스는 기기 대수를 제한하지 않으므로 목록 길이에 상한이 없고, 어떤 기기가 쓰고 있는지 알려 주는 역할만 합니다.

구독 동기화는 자동입니다. 회선이 조정되면 클라이언트가 다음 동기화 때 새 목록을 받아 가므로 직접 업데이트할 필요가 없습니다. 맨 아래 고정폭 글꼴로 된 줄에는 구독 상태와 트래픽 초기화 규칙이 표시됩니다. 트래픽은 자연월이 아니라 개통일 기준으로 매월 초기화됩니다. 이 내용은 요금제 페이지에도 안내되어 있습니다.

수동 설정 시 주의할 점

서드파티 클라이언트를 쓴다면 구독 링크를 직접 가져와야 합니다. 구독 링크는 패널에서 로그인 후 확인할 수 있으며, 계정 자격 증명과 같은 것이므로 공개된 곳에 붙여 넣지 마세요. 예시 형식은 다음과 같습니다(형식 설명용이며 실제로 사용할 수 있는 주소가 아닙니다).

https://example.com/sub?token=YOUR_TOKEN&flag=clash

가져올 때 자주 생기는 문제 몇 가지:

1. 가져온 뒤 노드가 없습니다. 대개 구독 링크가 완전히 복사되지 않아 끝부분이 잘린 경우입니다. 처음부터 끝까지 다시 복사하세요.
2. 노드는 있는데 연결이 안 됩니다. 클라이언트의 프로토콜 지원 여부를 확인하세요. 가져온 설정에 Hysteria2나 TUIC 노드가 들어 있는데 클라이언트 버전이 지원하지 않으면, 그 노드는 표시되지만 연결되지 않습니다.
3. 연결은 되는데 속도가 매우 느립니다. 어느 회선을 타고 있는지 먼저 확인하고, 앞 섹션의 점검 순서대로 처리하세요.
4. 구독을 업데이트한 뒤 노드가 줄었습니다. 구독 링크가 만료되지 않았는지, 서로 다른 요금제의 구독을 섞어 쓰고 있지는 않은지 확인하세요.

용어 정리와 추가 자료

마지막으로 이 페이지에서 쓴 용어를 한데 모아 설명합니다. 나중에 다시 찾아보기 편하도록 정리했습니다.

자주 쓰는 용어

왕복 시간(RTT)

데이터가 클라이언트에서 상대방까지 갔다가 돌아오는 데 걸리는 시간으로, 단위는 밀리초입니다. 지연을 이루는 가장 큰 부분입니다.

지터

왕복 시간이 흔들리는 폭입니다. 지터가 큰 회선은 평균 지연이 조금 더 높아도 안정적인 회선보다 체감이 나쁩니다.

패킷 손실

보낸 패킷이 상대방에 도달하지 못하는 것입니다. TCP 계열 프로토콜은 손실이 생기면 속도를 낮춰 재전송하고, QUIC 계열 프로토콜은 사용자 공간에서 더 정교한 판단을 할 수 있습니다.

롱팻 파이프

왕복 지연이 크고 대역폭이 넓은 링크입니다. 이런 링크에서는 TCP의 윈도 복구가 느려 패킷 손실로 인한 처리량 손실이 커집니다.

다중화

이미 맺어진 연결 하나에서 여러 요청을 동시에 처리해 반복되는 핸드셰이크를 없앱니다. 단점은 연결 하나에 문제가 생겼을 때 영향 범위가 커진다는 점입니다.

0-RTT

세션을 복구할 때 완전한 핸드셰이크 없이 바로 데이터를 보내 연결 수립 비용을 최소로 줄입니다. TUIC가 이를 핵심 특성으로 삼습니다.

혼잡 제어

송신 측이 네트워크 피드백에 따라 전송 속도를 조정하는 알고리즘입니다. 알고리즘마다 패킷 손실을 해석하는 방식이 달라, 손실이 많은 링크의 실제 처리량을 좌우합니다.

IEPL 전용선

국제 이더넷 전용선입니다. 국제 구간이 전용 링크를 지나 공용 인터넷 트래픽과 출구를 다투지 않으며, 안정성과 지터 면에서 가장 좋습니다.

중계

클라이언트가 먼저 가까운 입구 노드에 연결하고, 입구가 최적화된 경로를 따라 착지 노드로 보냅니다. 통제 가능한 구간 하나로 안정성을 얻는 방식입니다.

직결

클라이언트가 착지 노드에 바로 연결되고 전 구간이 공용 인터넷 라우팅을 지납니다. 경로가 가장 짧지만 품질은 공용망 상황에 따라 달라집니다.

착지 노드

트래픽이 최종적으로 나가는 서버 위치로, 목표 서비스가 보게 되는 IP의 소속 지역을 결정합니다.

트래픽 초기화일

본 서비스의 트래픽은 자연월이 아니라 개통일 기준으로 매월 초기화됩니다. 개통일이 8일이면 다음 주기의 시작도 다음 달 8일입니다.

추가 자료

이 페이지는 체계적인 참고 매뉴얼입니다. 다른 각도로 더 깊이 들어가고 싶다면 사이트 안에 이런 자료도 있습니다.

• 사용 가이드 페이지 — 가입부터 클라이언트 가져오기까지의 전체 흐름을 다루며, 처음 사용한다면 여기서 시작하는 것을 권합니다.
• 회선 페이지 — 전체 지역과 회선 목록을 권역별로 묶어 회선 유형과 스트리밍 지원 여부를 표시합니다.
• 요금제 페이지 — 세 가지 월 구독과 트래픽 패키지에 대한 전체 설명, 그리고 모든 요금제에 공통으로 포함되는 내용을 다룹니다.
• 회선 고르는 법 — 지역, 회선 유형, 용도 세 단계로 노드를 고르는 입문 글입니다.
• 초보자 열 가지 질문 — 여러 기기, 트래픽 계산, 속도 제한, 구독 링크 등 가장 자주 묻는 질문을 모았습니다.
• VPN 구매 시 피해야 할 함정 — 결제 전에 확인해야 할 사항과 환불 약속, 결제 수단 같은 세부 사항을 판단하는 기준을 정리했습니다.
• ChatGPT 가속 — AI 도구의 접속과 안정성을 다룬 특집으로, 장기 연결 설정 조언도 포함합니다.

이 페이지에 대한 안내

이 페이지는 프로토콜과 회선의 일반 원리를 다룹니다. 본문에 나오는 왕복 횟수, 핸드셰이크 비용 같은 설명은 프로토콜 원리 수준의 상대적 비교이며, 특정 네트워크 환경에서 측정한 결론이 아닙니다. 실제 체감은 인터넷 회선 품질, 거주 지역, 목표 서비스의 위치, 사용 시간대에 따라 달라집니다.

본 서비스에 관한 구체적인 숫자는 다음뿐입니다. 110+ 국가 / 150+ 회선, 기기 대수 제한 없음, 월 구독 ¥9.9부터, 트래픽 패키지 영구 만료 없음, 7일 무조건 환불, 알리페이 / 위챗 / USDT 지원, 이메일 주소 없이 가입 가능. 그 밖의 어떤 숫자도 본 서비스의 약속을 의미하지 않습니다.