로그를 남기지 않는 VPN이 좋은지 판단할 때는 홈페이지에 ‘무로그’라고 적혀 있는지만 봐서는 부족합니다. 실제로 확인해야 할 내용은 서비스가 어떤 데이터에 접근하는지, 어떤 데이터가 저장되는지, 보관 목적과 삭제 시점은 무엇인지, 그리고 가입·결제·연결·장애 대응 정보가 하나의 식별자로 연결될 수 있는지입니다. 개인정보 보호를 우선한다면 약관을 먼저 확인한 뒤 프로토콜, 회선, 클라이언트 설정을 점검해야 합니다.
‘무로그’라고 해서 모든 정보가 전혀 처리되지 않는 것은 아닙니다. VPN 서비스는 계정 인증, 트래픽 과금, 회선 배정, 장애 확인을 위해 일정 범위의 운영 데이터를 처리할 수 있습니다. 중요한 차이는 해당 데이터가 메모리에서 잠시 처리되는지, 장기간 조회 가능한 데이터베이스에 저장되는지에 있습니다. 요금제 상태만 기록하는지, 접속 출발지 주소·연결 시각·출구 노드·DNS 요청까지 함께 기록하는지도 확인해야 합니다. 막연한 약속 한 줄보다 범위를 항목별로 나누어 보는 편이 훨씬 정확합니다.
먼저 ‘무로그’가 무엇을 의미하는지 나누어 보기
개인정보 처리방침에서 말하는 ‘로그’에는 최소한 계정 정보, 연결 메타데이터, 트래픽 내용, DNS 조회, 클라이언트 진단 정보가 포함될 수 있습니다. 서비스마다 이 중 일부에만 ‘무로그’라는 표현을 사용하기도 합니다. 약관에 ‘검색 기록을 저장하지 않는다’고만 적혀 있다면 출발지 주소, 연결 시각, 기기 식별자까지 기록하지 않는다는 뜻은 아닙니다.
| 데이터 유형 | 포함될 수 있는 내용 | 확인할 핵심 사항 |
|---|---|---|
| 계정 정보 | 사용자 이름, 요금제 상태, 생성 시각, 고객 지원 기록 | 필수로 제공해야 하는 항목과 계정 삭제 후 처리 방식 |
| 연결 메타데이터 | 출발지 주소, 연결 시각, 연결 종료 시각, 선택한 노드, 전송량 | 저장되는지, 계정과 연결할 수 있는지, 언제 삭제되는지 |
| 트래픽 내용 | 접속 대상, 전송 내용, 애플리케이션 요청 | 약관이 포괄적인 표현에 그치지 않고 처리 범위를 명확히 설명하는지 |
| DNS 조회 | 도메인 확인 요청, 확인 결과, DNS 서버 | 요청이 터널을 통과하는지, 서비스가 조회 기록을 저장하는지 |
| 진단 정보 | 클라이언트 버전, 운영체제, 오류 코드, 충돌 보고서 | 기본적으로 업로드되는지, 업로드 전에 내용을 확인하고 끌 수 있는지 |
콘텐츠 로그와 연결 로그는 같은 범주로 보면 안 됩니다
콘텐츠 로그는 일반적으로 접속 대상, DNS 요청 또는 전송 내용을 뜻합니다. 연결 로그에는 접속 시각, 사용한 출구, 전송량 등이 포함될 수 있습니다. 단순한 운영 정보처럼 보여도 출발지 주소·시각·노드가 함께 저장되면 지속적인 연관 단서가 만들어질 수 있습니다. 따라서 ‘검색 내용을 기록하지 않는다’는 문구를 봤다면 연결 메타데이터 항목도 계속 확인해야 합니다.
‘수집’, ‘처리’, ‘보관’은 서로 다른 행위라는 점도 주의해야 합니다. 네트워크 연결을 만들 때 서버가 전송 계층에서 현재 연결의 출발지를 확인하는 것은 불가피하지만, 해당 정보가 반드시 로그로 저장된다는 뜻은 아닙니다. 제대로 작성된 약관이라면 정보가 저장되는지, 어떤 목적으로 사용되는지, 누가 접근할 수 있는지, 언제 삭제되는지를 설명해야 합니다. ‘필요한 정보를 수집할 수 있다’는 문장으로 설명을 끝내서는 안 됩니다.
홈페이지 요약보다 중요한 예외 조항
일부 정책은 먼저 포괄적인 무로그 설명을 제시한 뒤 보안, 악용 방지, 법적 요구 또는 장애 조사 항목에서 예외를 둡니다. 예외가 있다고 해서 반드시 선택할 수 없는 서비스라는 뜻은 아니지만, 범위가 충분히 명확해야 합니다. 특정 사건에 한해 일시적으로 적용되는지, 모든 연결을 계속 기록할 수 있는지, 계정 사용만 제한하는지 아니면 트래픽 관찰까지 확대되는지를 확인해야 합니다.
- ✅ 기록하지 않는 데이터 유형을 구체적으로 열거하는지 확인하세요. ‘개인정보를 중시한다’와 같은 포괄적인 표현만 사용하는 것은 부족합니다.
- ✅ 계정 정보, 연결 메타데이터, DNS 조회, 진단 보고서를 각각 어떻게 처리하는지 설명하는지 확인하세요.
- ✅ 보관 목적, 삭제 조건, 서비스 제공자와 인프라 공급자의 책임 범위를 설명하는지 확인하세요.
- ✅ 약관에 시행일이 표시되어 있고 이전 버전도 비교할 수 있는지 확인하세요.
- ❌ 모든 상황을 ‘필요한 경우 수집할 수 있다’로 처리하면서 필요한 조건을 정의하지 않는 경우
- ❌ 웹 추적 정책을 VPN 터널 데이터 정책과 동일하게 보는 경우
가입·결제 정보는 어떻게 최소화할까
개인정보 최소화의 목적은 사용할 수 없는 계정을 만드는 것이 아니라 서비스 제공에 필요하지 않은 정보 제출을 피하는 데 있습니다. 가입 전에 필수 입력 항목을 확인하세요. 사용자 이름과 비밀번호만으로 계정을 만들 수 있다면 이메일 주소를 따로 추가할 필요가 없습니다. 사용자 이름도 공개 포럼, 코드 저장소, 소셜 프로필에서 재사용하지 않는 것이 좋습니다. 서로 다른 활동이 같은 식별자로 연결될 수 있기 때문입니다.
비밀번호는 별도로 생성해 비밀번호 관리 도구에 보관하세요. 구독 링크를 일반 웹 주소처럼 다뤄서는 안 됩니다. 구독 링크에는 노드 설정을 불러오는 데 사용할 수 있는 접근 자격 증명이 포함되는 경우가 많습니다. 외부로 유출되면 다른 사람이 설정을 가져오거나 요금제 데이터를 소모할 수 있고, 설정에서 노드 도메인과 연결 매개변수를 확인할 수도 있습니다. 스크린샷, 문의 티켓, 채팅 기록, 클라우드 클립보드도 유출 경로가 될 수 있습니다.
결제 기록과 터널 로그는 서로 다른 영역입니다
VPN 노드가 연결 로그를 저장하지 않더라도 결제 채널은 거래 처리, 환불, 규정 준수 요구에 따라 주문 정보를 보관할 수 있습니다. 따라서 특정 결제 방식이 곧 익명성을 의미하지는 않습니다. 확인할 핵심은 서비스 제공자가 어떤 항목을 받는지, 주문 번호가 VPN 계정에 연결되는지, 고객 지원팀이 거래 정보로 계정을 조회할 수 있는지, 계정 삭제 후 재무 기록과 서비스 기록이 어떻게 분리되는지입니다.
개인정보 보호 요구가 높다면 결제자 정보, 사이트 사용자 이름, 일상적인 공개 신원을 분리해 관리할 수 있습니다. 다만 결제 방식을 바꾸는 것만으로 모든 연결 가능성이 사라진다고 생각해서는 안 됩니다. 브라우저 환경, 로그인 세션, 문의 내용, 반복 사용하는 사용자 이름도 연관 단서가 될 수 있습니다. 최소화는 결제 단계 하나가 아니라 전체 과정에 적용해야 합니다.
- 가입 전에 필수 입력 항목을 확인하고, 서비스 개통과 관계없는 정보는 입력하지 마세요.
- VPN 계정에는 별도의 사용자 이름과 비밀번호를 사용하세요.
- 구독 링크는 관리되는 안전한 위치에 보관하고 공개 문서나 여러 사람이 공유하는 공간에는 두지 마세요.
- 결제 전에 환불 및 주문 데이터 안내를 읽고, 서비스 제공자와 결제 채널이 각각 어떤 정보를 처리하는지 확인하세요.
- 문의 티켓을 제출하기 전에 설정 파일에서 자격 증명을 삭제하고 진단 로그의 내용을 확인하세요.
- 서비스를 중지할 때는 구독 링크, 클라이언트 설정, 계정, 삭제를 요청할 수 있는 자료를 각각 처리하세요.
프로토콜 이름이 개인정보 처리방침을 대신할 수는 없습니다
Shadowsocks, VMess, Trojan, VLESS, Hysteria2, TUIC은 연결 캡슐화, 전송, 네트워크 대응을 다루는 기술이며 서버가 로그를 남기는지 자동으로 결정하지 않습니다. 같은 프로토콜도 서로 다른 인증, 로그, 운영 체계에 배포될 수 있습니다. 프로토콜을 선택할 때는 네트워크 환경과 클라이언트 지원을 살펴보고, 개인정보 보호 여부를 판단할 때는 서버 설정, 데이터 정책, 운영 절차를 다시 확인해야 합니다.
| 프로토콜 또는 방식 | 주요 특징 | 개인정보 보호 확인 사항 |
|---|---|---|
| Shadowsocks | 암호화 프록시 방식으로 설정이 간단하며, 규칙에 따라 애플리케이션 트래픽을 전달할 때 자주 사용됩니다. | DNS가 프록시를 통해 전달되는지, 규칙에 일치하지 않는 트래픽이 어디로 향하는지 확인하세요. |
| VMess | V2Ray 생태계에서 흔히 사용되며 클라이언트와 서버 매개변수가 일치해야 합니다. | 시간 동기화, 전송 계층 설정, 클라이언트 로그에 자격 증명이 포함되는지 확인하세요. |
| Trojan | 일반적으로 TLS 전송과 함께 사용되며 인증서와 도메인 설정이 연결에 영향을 줍니다. | 클라이언트가 인증서를 엄격하게 검증하는지, 인증서 오류를 무시하도록 설정되어 있지 않은지 확인하세요. |
| VLESS | 인증 구조가 비교적 단순하며 일반적으로 TLS 같은 보안 전송 계층과 함께 사용됩니다. | VLESS라는 이름만 보지 말고 실제 전송 방식과 암호화 설정을 계속 확인해야 합니다. |
| Hysteria2 | QUIC과 UDP를 기반으로 하며 패킷 손실이나 변동이 있는 연결에 맞춰 전송을 최적화합니다. | 현재 네트워크가 UDP를 허용하는지, 대체 연결로 전환될 때 트래픽 경로가 어떻게 되는지 확인하세요. |
| TUIC | 마찬가지로 QUIC과 UDP를 사용하며 동시 전송과 혼잡 제어를 강조합니다. | 클라이언트 구현, 인증서 검증, UDP 제한 시 동작을 확인하세요. |
프로토콜 설정에는 인증서 검증도 포함됩니다. 인증서 이름 불일치, 인증서 만료, 발급 체인 이상이 발생했을 때 ‘일단 연결하기’ 위해 검증을 장기간 끄면 안 됩니다. 검증을 끄면 대상 서버의 신원을 확인하는 기능이 약해집니다. 설정이 구독으로 내려온다면 먼저 구독을 새로고침하고 시스템 시간을 확인한 뒤 서비스 제공자에게 노드 매개변수가 변경되었는지 문의하세요.
구독을 가져온 뒤 가장 먼저 확인할 것은 작동 모드입니다
클라이언트에 구독을 가져온 뒤에는 보통 시스템 프록시, 가상 네트워크 인터페이스, 앱별 전달 같은 작동 모드를 선택해야 합니다. 시스템 프록시는 프록시 설정을 따르는 앱에 주로 적용됩니다. 가상 네트워크 인터페이스 모드는 적용 범위가 더 넓을 수 있지만 라우팅 우선순위, 로컬 네트워크 우회, 운영체제 권한의 영향을 받을 수 있습니다. 클라이언트에 ‘연결됨’이라고 표시되는 것만으로 모든 트래픽이 터널을 통과한다고 볼 수는 없습니다.
분할 라우팅 규칙은 어떤 도메인, 주소, 앱이 프록시를 통과하고 무엇이 직접 연결될지를 결정합니다. 규칙 세트가 오래되면 대상 사이트의 일부 요청은 프록시를 통과하고 일부는 직접 연결될 수 있습니다. 규칙 순서가 잘못되면 범위가 넓은 직접 연결 규칙이 먼저 적용될 수도 있습니다. 개인정보 보호를 우선한다면 먼저 적용 범위가 명확한 모드로 검증한 뒤 필요한 직접 연결 규칙을 단계적으로 추가하세요.
- ✅ 구독을 가져온 뒤 현재 선택된 노드, 프로토콜, 작동 모드를 확인하세요.
- ✅ 구독 업데이트 주소가 암호화된 연결을 사용하는지 확인하고 로그에 전체 토큰을 출력하지 마세요.
- ✅ 로컬 규칙, 원격 규칙, 기본 규칙의 적용 순서를 확인하세요.
- ✅ 터널에 문제가 생겼을 때 연결 끊김 보호가 보호 대상 트래픽을 직접 연결로 계속 보내지 않는지 확인하세요.
- ❌ 프로토콜 이름이 새롭다는 이유만으로 서버가 연결 데이터를 저장하지 않는다고 추정하는 경우
- ❌ 인증서 오류를 피하려고 서버 신원 확인을 장기간 끄는 경우
IEPL 전용 회선, 중계, 직접 연결은 무엇을 드러낼까
회선 라벨은 데이터가 출구에 도달하는 방식을 설명할 뿐 로그 정책을 뜻하지는 않습니다. 직접 연결은 일반적으로 기기가 출구 노드에 바로 연결되는 방식으로 경로가 단순하지만, 출구 노드의 접속 측에서는 연결이 설정되는 동안 출발지 주소를 처리할 수 있습니다. 중계 방식은 먼저 진입점이나 중계 서버에 연결한 뒤 중계 서버가 출구로 전달합니다. 일부 네트워크 환경에서 라우팅 품질을 개선할 수 있지만 전송에 관여하는 인프라 단계가 하나 더 늘어납니다.
IEPL은 국제 이더넷 전용 회선 유형의 연결을 설명할 때 자주 사용되지만, 서비스마다 이 라벨의 범위가 다를 수 있습니다. 어떤 회선은 진입점과 출구 사이에서만 전용 회선을 사용하고, 어떤 회선은 공용망 접속을 함께 사용합니다. 확인할 때는 라벨이 어느 구간을 가리키는지, 진입점과 출구를 누가 운영하는지, 인증 정보와 연결 기록이 각각 어느 시스템에 저장되는지 문의해야 합니다. ‘전용 회선’이라는 말만으로 데이터가 기록되지 않는다고 판단해서는 안 됩니다.
회선 구조는 관찰 가능한 연결이 어느 노드에 나타나는지에 영향을 주고, 로그 정책은 관찰된 정보가 저장되는지를 결정합니다. 두 항목은 분리해서 평가해야 합니다.
중계 방식이라고 해서 자동으로 개인정보 보호 수준이 더 높아지는 것은 아닙니다. 진입점은 출발지 연결을 볼 수 있고 출구는 대상 연결을 볼 수 있습니다. 양쪽이 같은 제어 시스템에서 통합 기록된다면 계정과 시각 정보로 연결될 수 있습니다. 반대로 직접 연결이라고 해서 반드시 로그를 보관하는 것도 아닙니다. 실제로 확인해야 할 것은 각 구성 요소의 기록 여부, 기록 항목에 계정 식별자가 포함되는지, 운영 담당자가 여러 시스템을 걸쳐 조회할 수 있는지입니다.
DNS 유출과 분할 라우팅 규칙 확인하기
DNS 유출은 터널 안에서 처리되어야 할 도메인 요청이 실제로 로컬 네트워크나 통제되지 않은 다른 DNS 서비스로 전달되는 현상입니다. 클라이언트가 DNS를 제어하지 못하거나, 운영체제 라우팅에 문제가 있거나, 브라우저가 별도의 암호화 DNS를 사용하거나, 가상 네트워크 인터페이스 우선순위가 잘못되었거나, 분할 라우팅 규칙이 불완전할 때 발생할 수 있습니다. ‘유출’인지 여부는 예상한 작동 모드와 함께 판단해야 합니다. 특정 도메인을 직접 연결하도록 설정했다면 해당 DNS 요청이 로컬로 처리되는 것은 이상하지 않지만, 전체 트래픽을 터널이 맡도록 설정했다면 추가 점검이 필요합니다.
연결 전후 순서에 따라 확인하기
- VPN 연결을 끊고 현재 출구 주소, DNS 확인 주체, 사용 가능한 네트워크 인터페이스를 기록해 기준값으로 삼으세요.
- 대상 노드에 연결한 뒤 클라이언트 상태, 시스템 라우팅, 가상 네트워크 인터페이스가 모두 갱신되었는지 확인하세요.
- 기존 브라우저 페이지를 새로 고치는 데 그치지 말고 출구 주소와 DNS 확인 경로를 다시 조회하세요.
- 브라우저, 시스템 명령, 자주 사용하는 앱을 각각 테스트하세요. 서로 다른 네트워크 스택을 사용할 수 있습니다.
- 터널을 직접 끊고, 보호되어야 하는 연결이 계속 전송되지 않도록 연결 끊김 보호가 작동하는지 확인하세요.
- 자동 연결로 다시 전환한 뒤 한 번 더 확인해 규칙이 복구되었는지, 문제가 있는 라우팅을 계속 사용하지 않는지 점검하세요.
브라우저 자체의 보안 DNS 설정은 시스템 DNS 경로를 우회하거나 브라우저가 지정한 DNS 서비스를 사용할 수 있습니다. 무조건 끄기보다 먼저 예상하는 동작을 명확히 하세요. 모든 DNS 조회가 VPN으로 들어가야 한다면 브라우저가 시스템 설정을 따르도록 하거나 터널 정책과 호환되는 설정을 선택해야 합니다. 독립적인 암호화 DNS가 필요하다면 DNS 제공자와 VPN 서비스 제공자가 분리된다는 점을 받아들이고 해당 DNS 서비스의 로그 정책을 별도로 평가해야 합니다.
IPv6와 WebRTC도 확인해야 합니다. 일부 클라이언트는 IPv4 라우팅만 설정하지만 시스템에는 여전히 사용 가능한 IPv6 출구가 남아 있을 수 있습니다. 브라우저의 실시간 통신 기능이 로컬 인터페이스 정보를 노출할 수도 있습니다. 안정적인 방법은 해당 네트워크 스택을 함께 지원하는 클라이언트를 사용하거나, 업무상 필요하지 않은 경우 운영체제 기능에 맞춰 조정하는 것입니다. 웹페이지에 표시되는 단일 출구 결과만 믿어서는 안 됩니다.
플랫폼별 클라이언트를 따로 확인해야 합니다
Windows, Apple 운영체제, Android, Linux에서 같은 구독의 동작이 다를 수 있습니다. 이는 대개 노드가 바뀌어서가 아니라 프록시 인터페이스, 가상 네트워크 인터페이스 구현, 백그라운드 실행 제한, 시스템 권한이 서로 다르기 때문입니다. 한 플랫폼에서 확인한 개인정보 보호 설정을 다른 기기에 그대로 적용해서는 안 됩니다.
Windows 및 데스크톱
Windows 클라이언트에는 일반적으로 시스템 프록시와 가상 네트워크 인터페이스라는 두 가지 모드가 있습니다. 시스템 프록시는 프록시 설정을 무시하는 앱에 적용되지 않습니다. 가상 네트워크 인터페이스는 더 넓게 적용되지만 라우팅 테이블, DNS 제어, 절전 모드 후 복구를 확인해야 합니다. 시작 시 자동 실행된다고 해서 부팅 직후 터널이 이미 연결된 것은 아닙니다. ‘클라이언트 시작’과 ‘자동 연결’이 별도 설정인지 연동되는지 확인하세요.
Apple 운영체제
Apple 플랫폼은 일반적으로 시스템 네트워크 확장 또는 VPN 구성으로 작동합니다. 주문형 연결, 절전 모드 해제 후 재연결, 네트워크 간 전환 시 동작을 확인해야 합니다. 시스템 업데이트 후 네트워크 확장 권한을 다시 확인해야 한다면 상태 표시줄 아이콘만 보지 말고 출구와 DNS를 다시 점검하세요.
Android
Android의 항상 켜짐 VPN과 VPN을 통과하지 않는 연결 차단 기능은 연결이 끊겼을 때의 범위를 더 명확하게 설정할 수 있습니다. 다만 일부 로컬 기기 검색, 네트워크 로그인 페이지, 기업용 앱에 영향을 줄 수 있습니다. 활성화하기 전에 예외가 필요한 앱을 확인하고 배터리 절전 정책이 클라이언트의 백그라운드 실행을 중단하지 않는지 점검하세요.
Linux
Linux 클라이언트는 데스크톱 네트워크 관리자, 명령줄 코어, 컨테이너를 통해 작동할 수 있습니다. 규칙이 어느 네트워크 네임스페이스에 기록되는지, DNS를 어느 구성 요소가 제어하는지, 프로세스 종료 후 방화벽 규칙이 삭제되는지를 확인해야 합니다. 명령줄 코어를 사용할 때는 다른 로컬 사용자가 구독 자격 증명을 읽지 못하도록 설정 파일 권한도 제한하세요.
- ✅ 각 플랫폼에서 출구 주소, DNS 경로, 연결 끊김 동작을 별도로 검증하세요.
- ✅ 시스템 절전, 네트워크 전환, 클라이언트 업데이트 후 재연결 결과를 확인하세요.
- ✅ 앱별 분할 라우팅 예외가 명시적으로 설정되었는지, 클라이언트가 조용히 우회하지 않는지 확인하세요.
- ✅ 설정 파일과 진단 로그를 로컬에서 읽을 수 있는 권한을 제한하세요.
- ❌ 상태 표시줄 아이콘만 보고 모든 트래픽이 터널에 들어갔다고 판단하는 경우
- ❌ 데스크톱의 규칙 파일을 모바일 기기에 그대로 복사하면서 규칙 기능의 차이를 확인하지 않는 경우
공용 Wi-Fi에서는 한 단계 더 확인하기
공용 Wi-Fi의 주요 위험은 전송 내용뿐 아니라 위장 액세스 포인트, 로그인 페이지 가로채기, 잘못된 인증서 경고, 로컬 네트워크의 기기 검색에서도 발생합니다. 낯선 네트워크에 연결한 뒤에는 먼저 네트워크 이름이 장소에서 안내한 정보와 일치하는지 확인하세요. 로그인 페이지가 나타나면 필요한 네트워크 인증을 먼저 완료한 뒤 VPN을 연결하세요. 터널이 연결되면 대상 사이트를 다시 열어 로그인 페이지 단계에서 만들어진 세션을 이어 사용하지 않도록 하세요.
HTTPS는 여전히 중요합니다. VPN은 기기와 VPN 노드 사이의 전송을 암호화하지만, 노드에서 대상 웹사이트까지의 연결은 애플리케이션 계층의 내용을 보호하기 위해 여전히 HTTPS에 의존해야 합니다. 브라우저에 인증서 경고가 나타났다면 VPN에 연결되어 있다는 이유로 계속 접속해서는 안 됩니다. 인증서 오류는 잘못된 시간 설정, 네트워크 로그인 페이지의 가로채기, 대상 사이트 설정 이상 때문에 발생할 수 있으므로 원인을 먼저 확인해야 합니다.
사용하지 않는 파일 공유, 로컬 네트워크 검색, 알려진 개방형 네트워크 자동 연결도 끄세요. 자동 연결 기능에서는 ‘클라이언트 자동 실행’과 ‘신뢰할 수 없는 네트워크에서 터널 설정’을 구분해야 합니다. 클라이언트가 신뢰할 수 있는 네트워크 목록을 지원한다면 신중하게 관리하세요. 이름이 같은 낯선 액세스 포인트가 신뢰 네트워크로 인식되지 않도록 해야 합니다.
최종 확인 목록과 선택 순서
개인정보 보호를 우선하는 VPN 선택에서는 약관이 모호하거나 데이터 범위가 불분명하거나 클라이언트에서 검증할 수 없는 방식을 먼저 제외한 뒤 프로토콜, 회선 품질, 사용 편의성을 비교해야 합니다. 무로그는 따로 체크할 수 있는 단일 기능이 아니라 정책, 기술, 실제 동작을 서로 대조해 확인하는 기준입니다.
- ✅ 개인정보 처리방침이 계정 정보, 연결 메타데이터, 트래픽 내용, DNS, 진단 정보를 명확히 구분하는지 확인하세요.
- ✅ 보관 목적, 삭제 조건, 예외 범위, 약관 시행일을 확인할 수 있는지 살펴보세요.
- ✅ 가입 항목이 최소화 원칙을 따르고 사용자가 처리 가능한 계정 정보를 관리하거나 삭제할 수 있는지 확인하세요.
- ✅ 결제 기록, 고객 지원 티켓, VPN 연결 기록의 경계가 명확히 설명되어 있는지 확인하세요.
- ✅ 구독 링크를 자격 증명으로 관리하고 공개 스크린샷, 공유 문서, 확인되지 않은 로그에 노출하지 마세요.
- ✅ 클라이언트가 이해하기 쉬운 프록시 모드, 분할 라우팅 규칙, DNS 설정, 연결 끊김 보호를 제공하는지 확인하세요.
- ✅ 모든 플랫폼에서 출구 주소, DNS 경로, 절전 모드 복구, 네트워크 전환을 검증했는지 확인하세요.
- ✅ 회선 라벨이 진입점, 중계, 출구 사이의 실제 구조를 설명하는지 확인하세요.
- ❌ 프로토콜 이름, 회선 이름, 결제 방식을 종합적인 개인정보 보호 확인 대신 사용하는 경우
- ❌ 마케팅 요약만 읽고 서비스 약관의 보안 및 법적 예외를 확인하지 않는 경우
공개 문서만으로 특정 정책을 확인할 수 없다면 고객 지원팀에 ‘연결 출발지가 영구 저장소에 기록되나요?’, ‘진단 로그가 기본적으로 업로드되나요?’, ‘계정 삭제 후 구독 토큰은 언제 만료되나요?’처럼 구체적으로 질문하세요. 질문이 구체적일수록 답변을 검증하기 쉽습니다. 답변이 계속 포괄적이라면 그 불확실성도 선택 비용에 포함해야 합니다.