왜 「가이드대로 클릭하기」만으로는 자주 문제가 생길까요
스크린샷 가이드의 문제점은 「이 버전, 이 화면에서는 여기를 클릭하라」는 것만 알려준다는 것입니다. 화면이 리뉴얼되거나, 클라이언트를 바꾸거나, 여러분의 상황이 스크린샷과 완전히 일치하지 않으면, 어떻게 해야 할지 판단할 근거가 전혀 없어집니다. 반면 그 배경 논리를 이해하고 있다면, 화면이 바뀌었을 때도 「이 새 버튼은 아마 이 기능에 해당하겠구나」라고 스스로 판단할 수 있어, 누군가 새 스크린샷을 다시 찍어주기를 마냥 기다릴 필요가 없습니다.
솔직히 말하면, 이런 클라이언트에서 계속 반복해서 등장하는 핵심 개념은 사실 딱 4가지뿐이며, 각각 일상생활 속에서 대응하는 비유를 찾을 수 있습니다. 몇 분만 투자해 이를 정리하는 것이, 스크린샷 10장을 무작정 외우는 것보다 훨씬 효율적입니다. 그럼 순서대로 살펴보겠습니다.
나눠서 보면 사실 4가지 개념뿐입니다
먼저 노드부터 살펴보겠습니다. 노드는 구체적인 서버 주소이며, 클라이언트는 이를 통해 여러분의 네트워크 요청을 전달합니다. 구체적인 「길」이라고 생각하면 이해하기 쉽습니다. 길 상태가 좋으면(지연 시간이 낮으면) 빠르게 갈 수 있고, 상태가 나쁘면(지연 시간이 높거나 타임아웃되면) 지나갈 수 없거나 매우 막힙니다. 소프트웨어 안의 「서버 목록」은 본질적으로 여러분이 모은 후보 경로들의 모음이며, 속도 테스트는 어떤 길이 지금 뚫려 있는지 확인하는 작업입니다.
길이 하나 있는 것만으로는 부족합니다. 길을 바꿀 때마다 직접 알아봐야 한다면(즉 수동으로 노드를 추가한다면) 너무 번거롭습니다. 이때 필요한 것이 구독입니다. 클라이언트가 정기적으로 「지금 사용 가능한 길이 무엇인지」를 물어보게 하고, 결과를 자동으로 여러분의 목록에 반영하게 합니다. 대다수 가이드가 구독 사용을 권장하는 이유도, 수동으로 노드를 추가하는 것이 안 되기 때문이 아니라, 스스로 유지관리 비용을 늘릴 필요가 없기 때문입니다.
노드와 구독이 해결하는 것은 「갈 수 있는 길이 있는지」이고, 다음으로 봐야 할 것은 「누가 이 길을 지나가는지」, 즉 시스템 프록시입니다. 클라이언트에서 연결에 성공했다고 해서 스마트폰이나 컴퓨터의 모든 소프트웨어가 자동으로 노드를 거치게 되는 것은 아닙니다. 시스템 프록시라는 스위치가 어떻게 설정되어 있는지에 달려 있습니다. 클라이언트는 길을 정비하는 역할을, 시스템 프록시는 어떤 차(앱의 트래픽)가 이 길을 타는지 결정하는 역할을 합니다. 좋은 소식은 대다수 클라이언트가 설치 후 기본값으로 이 단계를 자동으로 처리해 주기 때문에 수동으로 설정할 필요가 없다는 것입니다.
마지막으로, 초보자를 가장 헷갈리게 하는 개념은 라우팅 모드입니다. 아무런 구분 없이 모든 트래픽(원래 프록시가 필요 없던 사이트 접속까지 포함)이 하나의 노드 경로에 몰리면 느려지고 낭비도 생깁니다. 그래서 클라이언트에는 판단 규칙 세트(흔히 말하는 PAC 스마트 라우팅)가 내장되어 있어 「이 사이트가 노드를 거쳐야 하는지」 「직접 연결해도 되는지」를 자동으로 구분합니다. 목적지가 다른 차량을 서로 다른 차선으로 나누는 것과 비슷해서 서로 방해하지 않습니다. 일상적인 사용에서는 기본 스마트 라우팅 모드만으로 충분하며, 직접 규칙 작성법을 연구할 필요가 없습니다.
흔한 오해 두 가지, 하나의 예시로 명확히 정리
이 4가지 개념을 이해한 뒤 가장 흔히 저지르는 실수는 「노드」와 「구독」을 혼동하는 것입니다. 흔히 「제 구독이 왜 연결이 안 되나요」라고 묻는데, 사실 구독 자체는 직접 연결할 수 있는 것이 아니라 노드 목록을 가져오기 위한 주소일 뿐입니다. 실제로 연결을 맺는 것은 구독에 포함된 특정 노드 하나입니다. 구독이 실효되었다는 것은 「이 주소에서 최신 노드 목록을 가져올 수 없게 되었다」는 뜻이고, 노드가 실효되었다는 것은 「특정 하나의 길이 통하지 않게 되었다」는 뜻입니다. 이는 서로 다른 두 차원의 문제이며, 이를 섞어서 생각하면 원래 간단했을 문제 해결이 복잡해집니다. 이 차이를 구분해 두면 문제가 생겼을 때 최소한 「구독의 문제인지 노드의 문제인지」를 먼저 판단할 수 있어 확인 범위를 절반으로 줄일 수 있습니다. 문제가 생길 때마다 모든 설정을 다시 뒤질 필요가 없습니다.
전체 흐름을 이어서 보면 더 직관적으로 이해할 수 있습니다. 방금 구독 주소를 하나 받았다고 가정해 봅시다. 클라이언트가 이 주소에 접속하고(구독이 적용됨), 노드 목록을 가져오고(노드가 서버 목록에 나타남), 그중 하나를 선택해 연결을 클릭하고(노드가 작동 시작), 시스템 프록시가 자동으로 여러분의 브라우저 트래픽을 처리하고(어떤 차가 이 길을 지날지 결정), PAC 스마트 분기가 어떤 사이트는 노드를 거치고 어떤 사이트는 직접 연결할지 판단합니다(차선 배정). 각 단계가 앞서 설명한 개념에 대응하므로, 어느 단계에서 문제가 생기더라도 이제 대략 어느 부분의 문제인지 판단할 수 있을 것입니다. 처음부터 무작정 모든 설정을 다 눌러볼 필요가 없습니다.
이 논리는 v2rayN / v2rayNG에만 국한되지 않습니다
노드, 구독, 시스템 프록시, 라우팅 모드 같은 개념은 특정 클라이언트만의 독자적인 설계가 아닙니다. 거의 모든 주요 프록시 도구가 동일한 구조를 채택하고 있으며, 다른 것은 화면 문구와 조작의 세부사항뿐입니다. 즉, 이 논리를 한번 이해하면 어떤 클라이언트로 바꾸더라도 금방 익숙해질 수 있어, 소프트웨어를 바꿀 때마다 조작 방법을 처음부터 다시 배울 필요가 없어집니다. 이것이 바로 몇 분을 투자해 개념을 이해하는 것이 스크린샷을 무작정 외우는 것보다 효율적인 이유입니다.
「노드는 길, 구독은 자동으로 업데이트되는 노선도, 라우팅 모드는 차선 배정」이라는 것을 알고 나서 클라이언트 화면을 열어보면, 모든 메뉴 항목이 이미 이해한 개념에 대응한다는 것을 알게 될 것입니다. 더 이상 스크린샷의 화살표 방향을 무작정 외울 필요가 없습니다. 완전한 조작 단계를 바로 보고 싶다면 완전 사용 가이드를 계속 읽어보세요. 노드 추가, 모드 선택, 속도 테스트, 문제 해결의 구체적인 조작 방법을 모두 자세히 설명하고 있습니다.