프로토콜 및 회선 기술 참고

SELECTION MODEL

먼저 프로토콜 선택 모델을 세우세요

프로토콜·전송·회선은 서로 다른 계층입니다

사용자 인터페이스에는 보통 노드 이름 하나만 표시되므로 “프로토콜”, “서버”, “회선”을 같은 개념으로 이해하기 쉽습니다. 실제로는 세 계층으로 나누어 봐야 합니다. 프로토콜은 클라이언트와 진입점 사이에서 세션을 식별하고 데이터를 캡슐화하며 연결을 처리하는 방식을 담당합니다. 전송 계층은 이러한 데이터가 TCP, UDP, TLS 또는 QUIC 등의 방식으로 전달될 때의 처리 방식을 결정합니다. 회선 토폴로지는 진입점, 출구와 중간 링크의 구성 방식을 설명합니다. 연결 품질은 세 요소가 함께 만들며, 어느 하나만으로 최종 속도를 판단할 수 없습니다.

예를 들어 프로토콜 자체의 오버헤드가 낮다고 해서 피크 시간대에 반드시 안정적인 것은 아닙니다. 진입점이 위치한 네트워크와 사용자 측 사이에 혼잡이 발생하면 가벼운 캡슐화는 기기와 프로토콜 계층의 추가 부담만 줄일 뿐, 회선의 대기열을 없애지는 못합니다. 반대로 토폴로지가 좋은 회선도 단말 절전, 클라이언트 백그라운드 제한 또는 프로토콜과 네트워크 환경의 불일치로 자주 재연결될 수 있습니다. 선택할 때 계층을 먼저 나누면 모든 문제를 “노드가 느리다”거나 “프로토콜이 안 된다”고 단정하는 일을 피할 수 있습니다.

제약 조건을 먼저 정하고 이름을 비교하세요

프로토콜 이름은 순위표가 아닙니다. 더 효과적인 순서는 현재 작업의 제약 조건을 먼저 적는 것입니다. 앱이 짧은 연결 중심인지 지속 전송 중심인지, 무선 네트워크와 모바일 네트워크 사이를 자주 이동하는지, 패킷 손실이 뚜렷한지, 장시간 백그라운드 실행이 필요한지, 해당 프로토콜의 클라이언트 구현이 성숙했는지를 확인하세요. 조건을 정한 뒤 Shadowsocks, VMess, Trojan, VLESS, Hysteria2, TUIC 중 더 잘 맞는 방식을 고르는 것이 좋습니다. 이름이 새롭거나 설정 항목이 많다는 이유로 기본 선택해서는 안 됩니다.

상호작용 작업은 요청 후 첫 응답을, 지속 다운로드는 장시간 처리량과 복구 능력을, 음성이나 실시간 협업은 지터와 헤드 오브 라인 블로킹을 중시합니다. 모바일 기기에서는 깨우기 횟수, 불안정한 네트워크에서의 재연결과 시스템 백그라운드 정책도 고려해야 합니다. 같은 서비스를 이용하더라도 작업마다 네트워크 요구 사항은 다릅니다. 용도를 구체적인 한 문장으로 적는 편이 단순히 “속도 우선”이라고 쓰는 것보다 유용합니다. 속도에는 연결 설정, 응답, 안정적인 전송과 장애 복구 등 여러 요소가 포함되기 때문입니다.

되돌릴 수 있는 기본 구성을 마련하세요

실제 사용에서 매일 설정을 반복해서 조정할 필요는 없습니다. 일상용 기본 구성과 장애 발생 시 사용할 대체 구성을 하나씩 남겨 두는 편이 안정적입니다. 기본 구성은 현재 네트워크에서 연결 설정이 안정적이고 클라이언트 구현이 성숙한 프로토콜을 선택합니다. 대체 구성은 다른 전송 특성을 사용해 문제가 특정 프로토콜 경로에서 발생했는지 공통 회선에서 발생했는지 확인하는 데 활용합니다. 같은 회선에서 두 프로토콜 모두 문제가 생기면 회선과 로컬 접속을 먼저 확인하고, 하나만 문제가 생기면 해당 프로토콜의 클라이언트 구현과 전송 설정, 서버 진입점을 점검하세요.

이 방법은 불필요한 전환도 줄여 줍니다. 프로토콜, 지역과 클라이언트를 동시에 자주 바꾸면 여러 변수가 함께 달라져 무엇이 효과가 있었는지 알 수 없습니다. 한 번에 한 계층만 바꾸세요. 먼저 지역과 회선을 유지한 채 프로토콜을 바꾸고, 다음에는 프로토콜을 유지한 채 회선을 바꾸며, 마지막으로 접속 네트워크를 바꿉니다. 각 단계에서 관찰한 현상을 기록하면 자신의 기기와 사용 습관에 맞는 안정적인 조합을 만들 수 있습니다.

단말: Windows / macOS / iOS / Android / Linux
작업: 웹 상호작용 / 스트리밍 / 파일 전송 / 실시간 협업
접속: 유선 네트워크 / 무선 네트워크 / 모바일 네트워크
프로토콜: 현재 선택 항목 기록
회선: 지역과 직결·중계 또는 전용 회선 기록
현상: 연결 설정, 응답, 지속 전송, 네트워크 전환 후 복구

VPNDG는 110+개 국가 / 230+개 회선을 제공하므로 지역과 토폴로지를 비교하기에 적합합니다. 다만 지원 규모가 모든 접속 네트워크에서 모든 회선이 동일하게 작동한다는 뜻은 아닙니다. 지역 분포를 확인하려면 글로벌 노드로 이동하고, 요금제 트래픽과 사용 기간을 확인하려면 요금제 안내를 살펴보세요. 도시 이름만 보고 결정하기보다 용도와 조건을 먼저 정한 뒤 이용 가능한 범위에서 고르는 편이 더 정확합니다.

PROTOCOL TRADE-OFFS

6가지 프로토콜 비교

Shadowsocks: 단순한 구조, 구현 품질이 핵심

Shadowsocks의 핵심 방식은 간단합니다. 클라이언트가 앱 트래픽을 암호화해 캡슐화한 뒤 원격 측에서 처리합니다. 설정 개념이 비교적 단순해 가볍고 범용적인 연결 방식으로 자주 사용됩니다. 프로토콜 자체에 복잡한 계정 상태나 다층 제어 정보를 강제로 포함하지 않으므로, 성숙한 구현은 보통 처리 부담을 낮게 유지할 수 있습니다. 웹 브라우징, 개발 도구와 일반적인 지속 전송에서는 기본 후보로 적합한 경우가 많습니다.

한계 역시 “단순함”에서 비롯됩니다. 실제 성능은 암호화 방식, 클라이언트 구현, 전송 경로와 서버 설정에 크게 좌우됩니다. 같은 이름의 프로토콜이라도 클라이언트마다 메모리 관리, 연결 재사용과 장애 복구 방식이 완전히 같지는 않습니다. 네트워크 전환 후 연결이 멈추거나 절전 모드에서 깨어난 뒤 이어지지 않는다면 노드만 확인하지 말고 클라이언트가 세션을 다시 설정했는지, 시스템이 백그라운드 네트워크 활동을 제한하는지도 살펴야 합니다.

VMess와 VLESS: 기능 확장성과 가벼운 인증 계층

VMess는 인증, 세션 정보와 데이터 처리를 프로토콜 흐름 안에 구성하므로 클라이언트 생태계에서 여러 전송 조합을 지원해야 하는 상황에 적합합니다. 장점은 단순히 “더 빠르다”는 것이 아니라 설정 표현력이 충분하고 다양한 하위 전송 방식과 결합할 수 있다는 점입니다. 대신 구현 경로가 길어 클라이언트와 서버 옵션을 일치시켜야 합니다. 여러 필드가 함께 결과를 결정하는 설정에서는 문제 해결에도 전체 맥락이 더 중요합니다.

VLESS는 신원 확인과 데이터 암호화의 역할을 더욱 분리해 자체적으로는 가벼운 인증·전달 계층에 가깝고, 보통 TLS 또는 다른 보안 전송과 함께 사용합니다. 중복 처리를 줄이는 방식은 프로토콜 계층의 부담을 낮추는 데 도움이 되지만, “프로토콜 자체가 가볍다”는 사실을 “전체 경로의 오버헤드가 가장 낮다”는 뜻으로 볼 수는 없습니다. 하위 전송, 인증서 핸드셰이크, 연결 재사용과 클라이언트 스케줄링 방식도 결과에 영향을 줍니다. VLESS는 단독 이름이 아니라 조합의 일부로 평가해야 합니다.

Trojan: 표준 TLS 세션 활용

Trojan은 TLS로 연결을 전달하며, 설정의 핵심은 보통 서버 이름, 인증서 검증과 연결 진입점에 있습니다. 성숙한 TLS 스택을 활용할 수 있고 앱과 운영체제도 관련 연결 방식을 익숙하게 처리한다는 점이 장점입니다. 고정 네트워크, 일반적인 웹 이용과 지속 세션에서는 올바르게 설정했을 때 동작을 이해하기 쉽습니다. 문제를 해결할 때는 도메인 확인, 시스템 시간, 인증서 검증, TLS 핸드셰이크와 이후 회선을 함께 살펴야 합니다. 어느 한 계층에서 실패해도 “노드에 연결할 수 없음”으로 나타날 수 있습니다.

TLS가 항상 성능상 이점만 제공하는 것은 아닙니다. 처음 연결할 때 핸드셰이크를 완료해야 하며, 연결 재사용 여부와 클라이언트가 세션을 자주 다시 만드는지에 따라 상호작용 품질과 배터리 사용량이 달라집니다. 클라이언트가 짧은 요청마다 새 연결을 만들면 프로토콜과 전송 계층의 고정 비용이 커집니다. 반대로 연결을 적절히 유지하면 이후 요청에서 반복 작업을 줄일 수 있습니다. 따라서 Trojan은 노드에 막 연결된 순간만 보지 말고 실제 앱 세션을 기준으로 비교해야 합니다.

Hysteria2와 TUIC: 손실이 있는 네트워크를 위한 QUIC 경로

Hysteria2와 TUIC는 모두 QUIC 관련 기능을 기반으로 하며, UDP 전송, 스트림 다중화와 연결 마이그레이션 등을 활용해 패킷 손실이 있는 네트워크에서 전송 동작을 개선하는 데 초점을 둡니다. 패킷 손실과 지터가 있거나 접속 네트워크 전환이 잦을 때 후보로 고려할 수 있습니다. TCP 위에 다시 TCP 트래픽을 전달하는 방식과 비교하면 QUIC의 독립 스트림 처리는 한 스트림의 패킷 손실이 다른 스트림의 대기까지 이어지는 현상을 줄일 수 있습니다. 다만 최종 결과는 UDP 지원 상태, 클라이언트 스케줄링과 서버 매개변수의 영향을 받습니다.

두 프로토콜이 “불안정한 네트워크에서 반드시 선택해야 하는 답”은 아닙니다. 일부 접속 네트워크는 UDP에 다른 대기열이나 더 엄격한 세션 유지 정책을 적용하며, 백그라운드 실행 중에는 시스템이 더 쉽게 회수할 수도 있습니다. UDP 경로 자체가 불안정하면 QUIC의 복구 기능도 일정 범위의 손실만 처리할 수 있고, 정상적으로 작동하는 하위 회선을 대신할 수는 없습니다. 모바일에서 선택할 때는 지속 연결이 깨우기 횟수를 늘리는지, 네트워크 전환 후 세션이 자연스럽게 복구되는지도 확인해야 합니다.

프로토콜 표는 선택 범위를 좁히는 데만 사용할 수 있으며, 모든 기기에서 통하는 최적의 답을 바로 제시하지는 않습니다. 유효한 결론에는 클라이언트, 접속 네트워크, 회선 유형과 앱 용도가 함께 포함되어야 합니다. 어떤 구성이 한 기기나 특정 시간대, 단일 네트워크에서만 잘 작동한다면 모든 환경에 적용되는 고정 답이 아니라 제한적인 결론으로 기록해야 합니다.

CONNECTION PATH

연결 설정과 응답 경로

버튼 클릭부터 앱 사용 가능 상태까지

사용자가 연결 버튼을 눌렀다고 클라이언트가 즉시 앱 데이터를 전달하는 것은 아닙니다. 일반적으로 먼저 구독에서 노드 정보를 읽고, 도메인을 확인하고, 사용 가능한 주소를 선택한 뒤 하위 TCP 또는 UDP 세션을 설정합니다. 이후 프로토콜 인증과 필요한 TLS 또는 QUIC 핸드셰이크를 진행합니다. 클라이언트는 로컬 프록시 진입점이나 가상 네트워크 인터페이스를 만들고 시스템 트래픽이 해당 진입점으로 들어가게 합니다. 화면에 “연결됨”이 표시되었다는 것은 핵심 흐름이 완료되었다는 뜻일 뿐, 모든 앱이 새 경로를 사용한다는 의미는 아닙니다.

따라서 연결 설정 속도는 여러 단계로 나누어 관찰해야 합니다. 연결 전 단계에서 오래 멈추면 도메인 확인, 하위 네트워크 또는 진입점 도달 가능성을 의심할 수 있습니다. 연결 성공이 빠르게 표시되지만 웹 응답이 늦다면 시스템 프록시, 라우팅 인계, DNS와 출구 회선을 추가로 확인하세요. 첫 접속만 느리고 이후 정상이라면 최초 도메인 확인, TLS 핸드셰이크 또는 연결 풀 준비 과정일 가능성이 큽니다. 단순히 계속 재연결하는 것보다 단계를 나누는 편이 원인을 찾기 쉽습니다.

짧은 연결과 연결 재사용

현대 앱은 페이지 문서, API, 이미지와 미디어 리소스를 동시에 요청하는 경우가 많습니다. 모든 요청이 완전한 경로를 독립적으로 설정하면 고정된 핸드셰이크 비용이 반복됩니다. 클라이언트, 프로토콜 구현과 앱 전송 계층이 연결을 유지하고 세션을 재사용하면 이후 요청은 기존 채널로 바로 들어가 상호작용이 더 자연스러워집니다. VMess, VLESS, Trojan 등의 최종 성능은 프로토콜 형식만이 아니라 하위 계층이 연결을 적절히 재사용하는지, 장애 후 어떻게 다시 설정하는지에도 좌우됩니다.

재사용이 많을수록 항상 좋은 것은 아닙니다. 성격이 다른 데이터를 하나의 하위 연결에 많이 몰아넣으면 혼잡이나 재전송 한 번으로 여러 앱이 함께 기다릴 수 있습니다. 연결을 너무 오래 유지하면 라우터 세션 만료, 무선 네트워크 전환 또는 시스템 백그라운드 정리도 발생할 수 있습니다. 성숙한 구현은 반복 핸드셰이크를 줄이는 것과 장애를 격리하는 것 사이에서 균형을 잡아야 합니다. 사용자는 최대 재사용 값을 직접 추구하기보다 서비스의 기본 설정을 우선 사용하고, 실제 앱에서 “한 곳이 멈추면 모두 기다리는” 현상이 나타나는지 확인하는 편이 좋습니다.

TCP 헤드 오브 라인 블로킹과 QUIC 다중 스트림

TCP는 바이트를 순서대로 전달합니다. 중간 데이터 일부가 손실되면 이미 도착한 후속 데이터도 누락 부분이 채워질 때까지 기다려야 하며, 이를 흔히 헤드 오브 라인 블로킹이라고 합니다. 상위 계층에서 여러 논리 요청을 하나의 TCP 연결로 재사용하면 패킷 손실 한 번이 여러 요청을 동시에 늦출 수 있습니다. 지속 다운로드에서는 처리량 변동으로, 웹 상호작용이나 실시간 협업에서는 짧은 멈춤으로 나타나기 쉽습니다.

QUIC는 UDP 위에서 신뢰성 있는 전송을 구현하고 서로 다른 논리 스트림을 따로 관리합니다. 한 스트림에서 데이터가 누락되어도 의존하지 않는 다른 스트림은 계속 전달될 수 있습니다. 이것이 Hysteria2와 TUIC를 복잡한 네트워크에서 테스트할 만한 이유입니다. 하지만 다중 스트림이 물리적 회선의 패킷 손실을 없애거나 대역폭을 늘려 주는 것은 아닙니다. 진입점 앞 네트워크가 이미 심하게 대기 중이면 모든 스트림이 같은 병목을 공유하며, UDP 경로 품질이 나쁘면 복구와 혼잡 제어에 추가 리소스를 사용해야 합니다.

연결 설정 경로에서 DNS의 위치

도메인 확인은 로컬에서 진행될 수도 있고 연결 후 원격 경로를 통해 진행될 수도 있습니다. 두 방식에는 각각 한계가 있습니다. 로컬 확인은 보통 시작이 빠르지만 결과가 현지 네트워크에 더 가까울 수 있습니다. 원격 확인은 출구 지역에 맞는 대상 주소를 선택하는 데 유리하지만 프록시 경로가 먼저 정상 작동해야 합니다. 확인 경로와 실제 출구가 일치하지 않으면 일부 콘텐츠 전송 서비스가 현재 출구에 적합하지 않은 주소를 반환해 연결은 성공했지만 우회 경로로 로드될 수 있습니다.

문제를 확인할 때는 도메인과 이미 접근 가능한 것으로 알려진 IP의 동작을 비교할 수 있습니다. IP 연결은 정상이고 도메인만 실패하면 먼저 DNS를 확인하세요. 둘 다 실패하면 하위 연결이나 회선에 문제가 있을 가능성이 큽니다. 프로토콜, 회선과 DNS 방식을 동시에 바꾸지 마세요. 무엇이 결과를 바꿨는지 판단하기 어렵습니다. 구독 가져오기와 클라이언트 기본 조작은 VPN 초보자 완벽 가이드를 참고할 수 있으며, 이 페이지에서는 계층별 판단 방법에 집중합니다.

RESOURCE PROFILE

리소스 사용량과 모바일 배터리

CPU, 메모리와 깨우기는 서로 다른 지표입니다

프로토콜의 리소스 사용량은 특정 순간의 CPU 비율만으로 판단할 수 없습니다. 암호화 계산, 데이터 복사, 연결 테이블 유지, 로그 출력, 네트워크 인터페이스 인계와 그래픽 인터페이스 갱신이 모두 리소스를 사용하며 운영체제마다 통계 기준도 다릅니다. 짧은 시간의 높은 CPU 사용량은 연결 설정이나 순간적인 트래픽 처리 때문일 수 있습니다. 장시간 백그라운드 깨우기는 모바일 기기 배터리에 더 직접적인 영향을 줍니다. 지속 계산, 메모리 상주와 깨우기 빈도를 나누어 관찰해야 합니다.

Shadowsocks는 프로토콜 흐름이 비교적 집중되어 있어 성숙한 구현에서 상시 부담을 관리하기 쉽습니다. VLESS 자체는 가볍지만 복잡한 전송과 결합하면 전체 리소스는 완전한 조합에 의해 결정됩니다. VMess는 더 많은 세션 정보를 처리하며, 실제 차이는 클라이언트 언어, 버퍼 관리와 연결 재사용에 따라 달라집니다. Trojan은 TLS 스택을 활용하므로 핸드셰이크 단계와 세션 유지 단계의 리소스 특성이 다릅니다. Hysteria2와 TUIC는 QUIC 상태, 혼잡 제어와 스트림 스케줄링을 유지하며 손실이 있는 경로에서는 복구 처리도 수행합니다.

모바일 배터리 소모는 지속적인 활동에서 발생합니다

모바일 기기가 대기 상태에 들어가면 시스템은 앱의 백그라운드 실행을 제한합니다. 클라이언트가 연결을 유지하기 위해 네트워크를 자주 깨우거나 신호 변동 중 계속 재연결하면 한 번의 암호화 계산보다 배터리 소모가 더 커질 수 있습니다. 무선 신호가 약하면 기기 자체도 통신 활동을 늘리므로 프로토콜 재전송과 시스템 네트워크 비용이 겹칩니다. 배터리 사용량이 증가했다고 특정 프로토콜이 “원래 배터리를 많이 쓴다”고 바로 판단하지 말고 당시 신호, 네트워크 전환 횟수, 트래픽 유형과 백그라운드 앱을 함께 확인해야 합니다.

장시간 음성·영상 이용, 파일 동기화와 클라우드 백업은 네트워크를 계속 활성화하므로 원래 더 많은 배터리를 사용합니다. 프로토콜 선택의 목표는 추가 부담을 줄이는 것이지 지속 전송을 비용 없이 만드는 것이 아닙니다. 모바일에서는 먼저 연결이 안정적이고 클라이언트 호환성이 성숙한 방식을 선택한 뒤 화면을 잠근 후에도 유지되는지, 깨어난 뒤 재연결이 필요한지, 무선 네트워크와 모바일 네트워크 전환 중 끊기는지 확인하세요. 안정성이 좋다면 이론적으로 더 가벼운 캡슐화를 위해 프로토콜을 자주 바꿀 필요는 없습니다.

프로토콜 라벨보다 구체적인 플랫폼 구현 차이

같은 프로토콜도 클라이언트에 따라 다른 네트워크 라이브러리, 버퍼 정책과 시스템 인터페이스를 사용할 수 있습니다. 데스크톱에서 안정적으로 작동한다고 해서 모바일 이식 버전의 백그라운드 동작이 완전히 같다는 뜻은 아닙니다. 반대로 모바일에서 배터리 절약을 위해 적용한 연결 정책은 지속 전송을 데스크톱과 다르게 만들 수 있습니다. 프로토콜을 비교할 때는 클라이언트를 고정하고, 클라이언트를 비교할 때는 프로토콜과 회선을 고정해야 구현 차이를 프로토콜 차이로 오해하지 않습니다.

가상의 점수 없이 배터리 사용량을 관찰하는 방법

배터리 사용량을 평가하기 위해 프로토콜에 정밀해 보이는 점수를 매길 필요는 없습니다. 비슷한 배터리 상태와 신호, 같은 앱 작업 조건에서 시스템 배터리 화면의 전면 사용 시간, 백그라운드 활동, 네트워크 사용량과 비정상 재연결 현상을 각각 기록해 보세요. 핵심은 추세입니다. 업무 트래픽이 없을 때도 클라이언트가 계속 활성 상태인지, 네트워크 전환 후 재연결을 반복하는지, 화면을 잠근 뒤 시스템이 회수하는지, 복구 후 앱이 요청을 다시 시작해야 하는지를 확인하세요.

특정 구성이 신호가 약할 때만 배터리를 많이 쓴다면 회선과 접속 품질을 먼저 개선하세요. 어떤 네트워크에서도 백그라운드 활동이 높다면 클라이언트 설정과 프로토콜 구현을 확인해야 합니다. Android에서는 시스템 절전 정책이 클라이언트를 제한하는지 확인하고, iOS에서는 시스템 네트워크 확장이 정상적으로 유지되는지 살펴보세요. VPNDG는 Windows / macOS / iOS / Android / Linux를 지원하며 클라이언트 다운로드는 사용자 패널에서 제공합니다. 설치와 구독 정보는 클라이언트 페이지에서 진행하고 출처가 불분명한 설정이나 설치 파일은 사용하지 마세요.

ROUTE TOPOLOGY

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

직결: 경로는 단순하지만 공용 인터넷 라우팅 의존도가 높습니다

직결은 사용자 측에서 목표 지역의 서비스 진입점에 직접 접속하고, 서비스가 구성한 추가 중계 진입점을 거치지 않는 방식입니다. 구조가 명확하고 통제되는 중간 요소가 적다는 장점이 있습니다. 사용자 네트워크와 목표 지역 사이의 공용 인터넷 라우팅 품질이 좋다면 추가 전달과 처리도 줄일 수 있습니다. 하지만 통신사 간, 지역 간 공용 경로는 라우팅 정책과 혼잡 상태에 따라 변하므로 낮 시간에 원활했던 경로가 피크 시간대에도 같은 성능을 보인다는 보장은 없습니다.

직결에 문제가 생기면 진입점에 도달할 수 없는지, 경로가 우회하는지, 출구 대상에 문제가 있는지를 구분해야 합니다. 같은 지역의 모든 프로토콜이 동시에 느려지고 접속 네트워크를 바꾸면 회복된다면 사용자 측과 진입점 사이 공용 경로에 문제가 집중되었을 가능성이 큽니다. 단일 대상 서비스만 이상하고 다른 웹사이트는 정상이라면 대상 서비스 자체, 지역별 콘텐츠 전송과 출구 주소의 적합성도 확인해야 합니다. 직결이 품질이 낮다는 뜻은 아니며, 현재 공용 라우팅의 영향을 더 많이 받는다는 의미입니다.

중계: 가까운 진입점을 거쳐 지역 간 경로를 구성합니다

중계 회선은 사용자가 더 가깝거나 접속 품질이 좋은 진입점에 연결한 뒤, 중계 진입점이 트래픽을 목표 출구로 전달합니다. 통제하기 어려운 장거리 공용 구간을 나누고 서비스가 관리할 수 있는 범위에서 이후 경로를 선택할 수 있다는 점이 가치입니다. 접속 네트워크가 다르면 출구 도시 이름보다 중계 진입점의 위치와 상호 연결 품질이 더 중요할 수 있습니다. 지리적으로 멀어도 접속 경로가 원활한 진입점이 명목상 가까우나 계속 우회하는 진입점보다 안정적일 수 있습니다.

중계는 처리 지점도 늘립니다. 진입점 용량, 진입점과 출구 사이의 전송 품질, 전달 스케줄링이 결과에 영향을 줍니다. 중계 진입점 자체가 혼잡하면 이후 회선이 좋아도 앞단의 대기열을 보완할 수 없습니다. 문제를 확인할 때 같은 출구 지역의 직결과 중계를 비교해 보세요. 직결은 이상하지만 중계가 정상이라면 중계가 문제가 있는 공용 구간을 피했을 가능성이 큽니다. 둘 다 이상하면 공통 출구, 대상 서비스 또는 로컬 접속을 계속 확인해야 합니다.

전용 회선: 통제 가능한 전송 구간을 강조하지만 모든 변수를 없애지는 않습니다

전용 회선은 일반적으로 진입점과 출구 사이에 더 통제 가능한 전송 자원이나 고정된 구성 방식을 사용하는 것을 뜻합니다. 목표는 공용 라우팅 변화가 중간 구간에 미치는 영향을 줄이는 것입니다. 안정성, 지속 전송과 피크 시간대 성능에 민감한 작업에 더 적합합니다. 전용 회선의 가치는 통제되는 전송 구간에 있으며, 사용자와 진입점 사이, 출구와 대상 서비스 사이는 여전히 각자의 네트워크를 거칠 수 있습니다. 따라서 “전용 회선”을 기기에서 모든 대상까지 외부 네트워크의 영향을 받지 않는다는 뜻으로 이해해서는 안 됩니다.

전용 회선을 선택할 때도 진입점이 현재 접속 네트워크에 적합한지, 출구 지역이 앱 요구 사항에 맞는지, 대상 서비스가 해당 출구를 허용하는지를 확인해야 합니다. 진입점 앞 무선 네트워크에서 패킷 손실이 심하면 전용 회선은 이후 경로만 개선할 수 있습니다. 대상 서비스 자체의 응답이 느리다면 상대방의 처리 시간도 바꿀 수 없습니다. 이러한 범위를 정확히 이해해야 높은 수준의 회선 라벨로 로컬 문제를 가리는 일을 피할 수 있습니다.

지연·지터·처리량은 각각 따로 이해해야 합니다

지연은 데이터 왕복에 필요한 대기 시간을, 지터는 연속된 패킷의 대기 시간 변화량을, 처리량은 지속 전송 중 단위 시간에 처리할 수 있는 데이터 양을 의미합니다. 웹 클릭과 원격 상호작용은 보통 지연과 지터를, 스트리밍 버퍼링과 파일 전송은 지속 처리량을 더 중요하게 봅니다. 어떤 회선은 첫 응답은 빠르지만 장시간 전송에서 흔들릴 수 있고, 반대로 첫 응답은 다소 느려도 지속 전송은 안정적일 수 있습니다.

따라서 회선 선택은 단일 동적 수치만 보고 결정할 수 없습니다. 회선 상태의 지연 시간은 적합하지 않은 지역을 빠르게 제외하는 데 유용하지만, 최종 판단은 실제 앱에서 내려야 합니다. 스트리밍은 시작, 재생 위치 이동과 지속 재생을 확인하고, 개발 도구는 로그인, API 호출과 장기 연결을 관찰하며, 파일 작업은 전송이 반복적으로 멈추는지 살펴보세요. VPNDG의 지역과 회선 유형을 확인하려면 글로벌 노드 페이지로 이동한 뒤 실제 용도에 따라 직결·중계·전용 회선을 선택하세요.

LOSS · JITTER · QUEUE

패킷 손실과 피크 시간대 혼잡

패킷 손실은 전체 경로 어디에서나 발생할 수 있습니다

패킷 손실은 원격 서버에서만 발생하지 않습니다. 무선 신호 간섭, 로컬 라우터 대기열, 접속 네트워크 간 연결, 지역 간 전송, 중계 진입점 용량과 출구 네트워크에서도 데이터가 버려질 수 있습니다. 앱에서 보이는 현상은 대체로 비슷합니다. 웹페이지 일부 리소스가 늦게 나타나거나, 영상이 버퍼링되고, 음성이 끊기며, 다운로드 속도가 주기적으로 낮아집니다. 표면 증상만으로 위치를 바로 판단하기는 어려우므로 구간별 비교를 통해 범위를 좁혀야 합니다.

먼저 로컬 네트워크를 비교하세요. 유선 연결은 정상이고 무선 연결만 이상하면 무선 신호와 라우터를 우선 점검합니다. 고정 네트워크는 이상하지만 다른 접속 네트워크가 정상이면 접속 측과 진입점 사이를 의심할 수 있습니다. 이후 프로토콜을 고정한 채 같은 지역의 회선을 바꾸어 단일 진입점만 문제인지 확인하세요. 마지막으로 회선을 고정하고 프로토콜을 바꾸어 TCP와 QUIC 경로의 차이를 관찰합니다. 이 순서라야 매 단계에서 한 변수만 바꿀 수 있습니다.

혼잡은 용량 부족만이 아니라 대기열의 문제입니다

링크로 들어오는 데이터가 현재 처리 능력을 초과하면 장비 대기열에서 기다리게 됩니다. 대기열이 길어지면 데이터가 즉시 손실되지 않더라도 지연과 지터가 뚜렷하게 증가하고, 대기열이 가득 찬 뒤에야 패킷 손실이 시작됩니다. 사용자는 “속도 측정이나 전송은 되는데 클릭이 느리다”고 느낄 수 있으며, 이는 연결이 완전히 끊긴 것이 아니라 대기열 지연 때문일 가능성이 큽니다. 가정용 네트워크의 업로드 작업이 업로드 대기열을 가득 채워 다운로드 확인과 상호작용 요청까지 늦출 수도 있습니다.

피크 시간대의 변화는 사용자 접속, 네트워크 간 연결과 인기 출구에서 동시에 나타날 수 있습니다. 어떤 회선이 한가한 시간에는 좋지만 특정 시간대에 느려진다면 공유 자원의 대기열을 겪고 있을 가능성이 있습니다. 이때 프로토콜만 바꾸는 효과는 제한적입니다. 같은 병목을 계속 통과하기 때문입니다. 더 효과적인 방법은 진입점, 회선 토폴로지 또는 출구 지역을 바꾸어 트래픽이 혼잡 구간을 벗어나게 한 뒤 문제가 사라지는지 확인하는 것입니다.

손실 상황에서 TCP와 QUIC의 차이

TCP는 패킷 손실을 감지하면 재전송하고 혼잡 제어에 따라 전송 속도를 조정합니다. 하위 계층에서 손실이 계속되면 전송 속도를 줄였다가 회복 후 서서히 높입니다. TCP에서 여러 상위 요청이 하나의 연결을 공유하면 바이트 순서 요구로 대기 범위가 커질 수 있습니다. QUIC 역시 신뢰성과 혼잡 제어가 필요하지만 앱 데이터를 독립 스트림으로 구성하고 서로 다른 확인·복구 방식을 지원하므로 여러 요청이 동시에 진행되거나 네트워크가 전환될 때 다른 사용감을 보일 수 있습니다.

그렇다고 QUIC가 혼잡을 무시할 수 있다는 뜻은 아닙니다. 책임 있는 전송 방식은 네트워크 압력을 감지하면 전송량을 조절해야 하며, 그렇지 않으면 더 많은 패킷 손실을 만들 뿐입니다. Hysteria2와 TUIC의 가치는 UDP와 QUIC 경로에 맞춰 전송을 구성하는 데 있으며 네트워크 용량을 우회하는 데 있지 않습니다. UDP에 친화적이지 않은 네트워크에서는 핸드셰이크 실패, 이른 세션 종료 또는 지속적인 지터가 발생할 수 있습니다. 이때는 성숙한 TCP와 TLS 구성으로 되돌리는 편이 원인을 확인하기 쉽습니다.

앱 계층 버퍼는 네트워크 문제를 가리거나 확대할 수 있습니다

스트리밍은 보통 콘텐츠를 미리 버퍼링하므로 짧은 패킷 손실이 곧바로 화면 끊김으로 나타나지 않을 수 있습니다. 버퍼가 점차 소진되면 문제가 갑자기 드러납니다. 웹과 AI 도구는 요청과 응답 중심이라 짧은 멈춤도 쉽게 느껴집니다. 파일 다운로드는 지속 전송으로 일부 변동을 완화할 수 있지만 장시간 처리량 저하는 완료 시간을 늘립니다. 같은 회선도 앱마다 체감 평가가 완전히 다를 수 있으며, 이는 버퍼링 전략과 상호작용 방식의 차이 때문입니다.

따라서 문제를 확인할 때는 한 가지 도구만 실행하지 말고 목표 용도를 대표하는 테스트를 선택하세요. 스트리밍이라면 시작, 화질 전환과 재생 위치 이동을 테스트합니다. Claude나 Gemini 같은 AI 도구는 세션 설정, 지속 출력과 첨부 파일 처리를 관찰하세요. 원격 협업은 음성, 화면과 제어 동작이 동기화되는지 확인합니다. 안정성 자체 점검 방식은 연결 성공률과 끊김률을 실제로 비교하는 방법에서 더 확인할 수 있습니다. 해당 글은 한 번의 결과보다 연속 기록을 강조합니다.

로컬 대기열과 백그라운드 작업도 확인해야 합니다

클라우드 드라이브 동기화, 시스템 업데이트, 사진 백업과 대용량 파일 업로드는 백그라운드에서 회선을 계속 사용할 수 있습니다. 업로드 방향은 다운로드 확인 정보도 전달하므로 업로드 혼잡이 웹과 다운로드를 동시에 느리게 만들 수 있습니다. 백그라운드 작업을 일시 중지했을 때 상호작용이 바로 회복된다면 문제는 주로 로컬 공유 대기열에 있으므로 원격 노드를 서둘러 바꿀 필요가 없습니다. 라우터 부하, 무선 채널 간섭과 기기 거리도 이 계층에 해당합니다.

완전한 결론에는 “언제 발생했는지, 어떤 앱이 영향을 받았는지, 네트워크를 바꾸면 회복되는지, 회선을 바꾸면 회복되는지, 프로토콜을 바꾸면 회복되는지”가 포함되어야 합니다. 피크 시간대에만 발생하고 같은 진입점에서 여러 프로토콜이 동시에 이상하면 공유 경로를 먼저 의심하세요. 하루 종일 특정 단말에서만 발생하면 클라이언트와 시스템을 먼저 확인합니다. 한 앱만 이상하면 목표 지역, DNS와 앱 계정 상태를 계속 점검하세요. 계층별로 설명하면 이후 지원도 더 직접적으로 처리할 수 있습니다.

SCENARIO MATRIX

사용 시나리오에 맞춰 조합 선택

웹, 개발과 AI 도구

웹 브라우징, 코드 저장소, 문서 협업과 Claude·Gemini 같은 AI 도구는 대량의 짧은 요청, TLS 세션과 지속 출력을 주로 사용합니다. 이러한 작업은 첫 응답, DNS 일관성과 장기 연결 안정성을 중시하며 최고 수준의 지속 처리량이 반드시 필요한 것은 아닙니다. 먼저 클라이언트 지원이 성숙한 Shadowsocks, Trojan 또는 VLESS 조합을 선택하고 같은 출구 지역에서 로그인, 페이지 리소스 로딩과 지속 출력이 원활한지 확인해 보세요.

처음 열 때만 느리고 이후 정상이라면 도메인 확인과 연결 재사용을 중점적으로 확인하세요. 출력 중 자주 멈추지만 다른 웹페이지는 정상이라면 대상 서비스 응답과 회선의 장기 연결을 구분해야 합니다. 모든 앱이 동시에 멈추면 진입점과 접속 네트워크를 점검하세요. AI 도구는 출구 지역과 계정 이용 범위에 자체 요구 사항이 있을 수 있습니다. 회선은 네트워크 경로만 담당하며 앱 서비스 규칙을 바꾸지는 않습니다. 지역은 지리적으로 가장 가까운 도시가 아니라 대상 서비스가 실제로 지원하는 범위를 기준으로 선택해야 합니다.

스트리밍과 지속 재생

스트리밍은 안정적인 처리량, 출구 지역과 지속 세션을 더 중요하게 봅니다. 재생 시작이 빠르다고 장시간 재생이 안정적인 것은 아니며, 콘텐츠 페이지가 열린다고 출구 지역에 같은 콘텐츠 목록이 있다는 뜻도 아닙니다. 회선을 선택할 때 먼저 콘텐츠 지역을 정한 뒤 같은 지역의 직결·중계·전용 회선을 비교하세요. 재생 시작은 정상인데 계속 버퍼링되면 처리량 변동과 피크 시간대 경로를 우선 확인합니다. 콘텐츠 페이지에서 바로 지역 문제가 표시되면 출구 위치와 플랫폼 규칙을 확인하세요.

프로토콜 측면에서는 성숙한 TCP 경로가 대부분의 고정 네트워크에 적합합니다. 패킷 손실이 뚜렷하면 Hysteria2 또는 TUIC와 비교해 버퍼 복구가 개선되는지 확인할 수 있습니다. 출구 지역을 동시에 바꾸면 콘텐츠 차이가 판단을 방해하므로 피하세요. Disney+의 지역과 회선 판단은 지역별 콘텐츠 차이와 이용 안정성 실제 비교를 참고하세요. Netflix 같은 플랫폼도 실제 출구와 지속 재생 결과를 기준으로 판단해야 하며 노드 이름만으로 추측할 수 없습니다.

파일 전송, 동기화와 장시간 작업

파일 전송에서는 지속 처리량, 연결 끊김 복구와 장시간 안정성이 중요합니다. 짧은 초기 지연은 보통 핵심 문제가 아니며, 지속적인 대기, 주기적인 패킷 손실과 세션 중단이 더 큰 영향을 줍니다. 고정 네트워크에서는 안정적인 직결 또는 중계부터 사용하고, 피크 시간대 변동이 뚜렷하면 전용 회선을 테스트하세요. 프로토콜은 초기 연결 속도만 비교하기보다 클라이언트의 장기 연결 구현, 장애 복구와 메모리 관리를 우선 고려해야 합니다.

업로드 작업은 로컬 네트워크의 다른 상호작용에도 영향을 줍니다. 동기화 중 웹페이지도 느려지면 먼저 로컬 업로드 대기열을 확인하세요. 여러 기기가 동시에 전송하면 전체 병목은 공유 접속이 결정합니다. VPNDG는 기기 수 제한이 없지만 이는 접속 가능한 기기 범위를 뜻할 뿐, 각 기기가 서로 독립적인 로컬 대역폭을 가진다는 의미는 아닙니다. 가정이나 팀에서 기기가 많다면 백그라운드 동기화 시간을 조정하고 한 기기의 결과를 모든 단말에 일반화하지 마세요.

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

통근, 로밍과 무선 네트워크 전환 상황에서는 세션 마이그레이션, 재연결 속도와 백그라운드 유지가 더 중요합니다. Hysteria2와 TUIC의 QUIC 경로를 후보로 삼아 네트워크 전환 후 더 빠르게 복구되는지 비교할 수 있습니다. 현재 네트워크의 UDP 지원이 불안정하다면 Trojan, VLESS 또는 Shadowsocks 같은 성숙한 조합으로 되돌리세요. 모바일에 항상 맞는 단일 프로토콜은 없으며 안정성은 접속 네트워크, 시스템 백그라운드 정책과 클라이언트 구현에 달려 있습니다.

모바일 환경을 테스트할 때 화면이 켜져 있고 앱이 전면에 있을 때만 관찰하지 마세요. 화면을 잠근 뒤 복귀하기, 무선 네트워크에서 모바일 네트워크로 전환하기, 신호가 약한 지역에 들어갔다가 돌아오기, 앱이 올바른 출구를 계속 사용하는지도 확인해야 합니다. 시스템 절전 정책이 클라이언트를 회수하면 프로토콜 자체로 세션을 유지할 수 없습니다. 네트워크 전환 후 연결 상태는 정상으로 표시되지만 앱이 응답하지 않으면 먼저 연결을 끊었다가 다시 연결한 뒤 클라이언트가 네트워크 변화를 올바르게 처리했는지 판단하세요.

일반 사용자는 복잡한 매개변수를 좇을 필요가 없습니다

프로토콜 매개변수가 많다고 실제 사용감이 좋아지는 것은 아닙니다. 대부분의 사용자는 구독에서 제공하는 기본 노드부터 시작해 목표 앱이 작동하는지 확인한 뒤 제한적으로 비교하는 편이 적합합니다. 문제가 안정적으로 재현될 때만 프로토콜이나 토폴로지를 바꾸세요. 이렇게 하면 설정 오류를 줄이고 지원이 필요할 때 환경을 정확히 설명할 수 있습니다. 사용자 이름과 비밀번호만으로 이용을 시작할 수 있으며 이메일 주소는 필요하지 않습니다. 구독과 클라이언트는 사용자 패널에서 받아야 합니다.

요금제 선택과 프로토콜 성능은 별개의 문제입니다. 월간 구독 트래픽은 개통일을 기준으로 매월 재설정되며, 중도 업그레이드 차액은 남은 일수에 따라 계산됩니다. 데이터 패키지는 소진될 때까지 사용할 수 있고 영구적으로 만료되지 않습니다. 구체적인 등급과 가격은 요금제 페이지에 표시된 ¥9.9/월 60GB, ¥18/월 250GB, ¥28/월 500GB, 그리고 ¥158/300GB, ¥358/1000GB, ¥658/3000GB를 기준으로 확인하세요. 프로토콜 선택은 요금제의 트래픽 규칙을 바꾸지 않습니다.

DIAGNOSTIC WORKFLOW

연결 진단과 장기 유지 관리

먼저 로컬 네트워크와 클라이언트 상태를 확인하세요

진단은 기기에 가장 가까운 계층에서 시작해야 합니다. 연결을 사용하지 않은 상태에서 로컬 네트워크가 자주 이용하는 서비스에 정상적으로 접근하는지 먼저 확인하고, 시스템 시간, 네트워크 권한, 클라이언트의 구독 업데이트 완료 여부와 현재 노드 설정의 완전성을 점검하세요. 기본 네트워크 자체가 끊겼다면 원격 프로토콜을 확인할 의미가 없습니다. 구독이 제대로 로드되지 않았다면 노드를 반복해서 바꾸어도 결과는 달라지지 않습니다.

그다음 클라이언트가 실제로 트래픽을 인계하는지 확인합니다. 시스템 프록시 모드는 프록시 설정을 따르는 앱에만 영향을 줄 수 있고, 가상 네트워크 인터페이스 모드는 보통 적용 범위가 더 넓지만 시스템 권한과 라우팅에 더 의존합니다. “브라우저는 되는데 다른 앱은 안 된다”면 바로 회선을 바꾸기보다 인계 모드를 먼저 확인하세요. Windows 사용자는 Windows 처음부터 설정하는 방법을 참고해 설치, 구독 가져오기와 시작 시 실행을 점검할 수 있습니다.

도메인 확인·연결 설정·출구·대상을 순서대로 검증하세요

로컬 상태가 정상이라면 도메인 확인이 가능한지, 프로토콜 진입점과 연결할 수 있는지, 출구가 바뀌었는지, 목표 앱을 사용할 수 있는지를 순서대로 확인합니다. 각 단계에서는 질문 하나만 답하세요. 도메인은 실패하지만 IP는 정상이면 DNS가 핵심입니다. 진입점 연결에 실패하면 접속 경로, 프로토콜 또는 서버 진입점을 확인해야 합니다. 출구는 바뀌었지만 앱이 실패하면 출구 지역, 대상 규칙과 앱 자체 상태를 계속 점검하세요.

출구를 확인할 때는 사이트의 IP 조회를 사용해 연결 전후 결과를 비교할 수 있습니다. 경로가 전환되었는지 확인하는 목적이라면 구독 링크, 계정 정보 또는 전체 진단 로그를 공개할 필요가 없습니다. 로그에 노드 주소, 신원 필드나 구독 내용이 포함되어 있다면 지원을 요청하기 전에 필요한 부분을 가리세요. 구독 링크는 계정 정보이므로 공개 포럼이나 공개 문서에 보내서는 안 됩니다.

변수를 고정하고 프로토콜과 회선을 비교하세요

연결은 설정되지만 사용감이 이상하다면 먼저 출구 지역을 유지한 채 같은 회선에서 다른 프로토콜과 비교하세요. 단일 프로토콜만 이상하면 해당 프로토콜의 전송, 인증서, UDP 도달 가능성과 클라이언트 구현을 확인합니다. 여러 프로토콜이 동시에 이상하면 프로토콜을 유지한 채 직결·중계·전용 회선으로 바꿔 보세요. 새 회선에서 회복되면 원래 진입점이나 토폴로지에 문제가 있을 가능성이 큽니다. 여전히 이상하면 접속 네트워크와 대상 서비스를 계속 비교하세요.

전환할 때는 이전 세션이 종료될 때까지 기다린 뒤 영향을 받은 앱을 다시 열어 앱이 기존 연결을 계속 재사용하지 않게 하세요. 브라우저, 스트리밍 클라이언트와 개발 도구는 연결 풀을 유지할 수 있으므로 노드만 바꾸고 즉시 새로 고침해도 완전히 새로운 경로가 설정되지 않을 수 있습니다. 필요하면 앱을 완전히 종료한 뒤 다시 시작하고, 출구를 재확인한 다음 원래 작업을 반복하세요. 이 단계는 “회선을 바꿨지만 실제 요청은 여전히 이전 세션을 사용한다”는 오판을 줄여 줍니다.

일반적인 증상을 구분하세요

지원 요청에 제출할 정보를 정리하세요

직접 점검한 뒤에도 원인을 확인할 수 없다면 지원 정보에 플랫폼 이름, 클라이언트 출처, 선택한 프로토콜, 회선 지역과 유형, 접속 네트워크 종류, 문제가 발생한 앱, 발생 시간대, 재현 가능 여부와 이미 진행한 단일 변수 비교 결과를 포함하세요. “사용할 수 없다”는 설명은 원인을 찾기 어렵지만, “같은 접속 네트워크에서 직결과 중계는 모두 연결되며 특정 프로토콜만 네트워크 전환 후 복구되지 않는다”라고 쓰면 세션 복구와 클라이언트 구현을 바로 확인할 수 있습니다.

실제 구독 주소나 비밀번호는 제출하지 마세요. 구독 형식을 보여줘야 한다면 명확한 가짜 값을 사용할 수 있습니다:

https://example.com/sub?token=YOUR_TOKEN

지원이 필요하면 사용자 패널의 문의 티켓을 통해 제출하세요. VPNDG는 사용자 이름과 비밀번호만으로 이용을 시작할 수 있으며 이메일 주소는 필요하지 않습니다. 결제 방식은 Alipay / WeChat Pay / USDT이며, 서비스는 30일 무조건 환불을 제공합니다. 위 계정 및 결제 정보는 프로토콜 진단과 직접 관련이 없지만, 티켓에 요금제가 아직 유효한지 적으면 구독 상태 문제를 먼저 제외하는 데 도움이 됩니다.

안정적인 기본값을 중심으로 장기 유지 관리하세요

네트워크 환경은 변하므로 장기 유지 관리의 목표는 특정 프로토콜을 영원히 고정하는 것이 아니라 검증된 기본 조합과 대체 조합을 남겨 두는 것입니다. 클라이언트 업데이트나 시스템 업그레이드 후에는 기존 기본 회선으로 출구, 웹, 지속 연결과 네트워크 전환을 한 번씩 확인하세요. 동작이 달라졌다면 이 페이지의 흐름에 따라 계층별로 비교합니다. 한 번의 우발적인 지터 때문에 전체 설정을 다시 만들지 말고, 기존 설정이 더 이상 유효하지 않은데 임시 매개변수를 계속 덧붙이지도 마세요.

구독을 업데이트한 뒤에는 회선 이름과 유형의 맥락을 남겨 두고 목록 순서만 기억하지 마세요. 같은 지역의 노드라도 서로 다른 토폴로지를 사용할 수 있으며 목록 위치가 바뀌었다고 기존 회선이 같은 위치에 있다는 뜻은 아닙니다. 자주 사용하는 작업은 “일상 상호작용”, “지속 전송”, “모바일 대체”처럼 용도별로 기록할 수 있지만 계정 정보까지 공개적으로 저장할 필요는 없습니다. 간결하고 재현 가능하며 되돌릴 수 있는 설정이 검증되지 않은 옵션을 많이 쌓는 것보다 장기 사용에 적합합니다.