신뢰할 만한 프라이버시 VPN 추천을 찾을 때 걸림돌은 가격표가 아니라 눈에 보이지 않는 두 가지입니다. 무로그 정책을 실제로 어떻게 검증할 것인가, 그리고 가입할 때 개인정보를 얼마나 줄일 수 있는가입니다. 이 두 가지는 느낌이 아니라 조항 대 조항으로 대조하고 직접 확인할 수 있는 절차에 달려 있습니다. 아래에서는 순서대로 풀어 봅니다. 먼저 서비스가 말하는 '로그'가 어느 범주를 가리키는지 구분하고, 다음으로 가입과 결제를 최소화하는 방법, 이어서 공용 Wi-Fi에서의 이용 기준, 마지막으로 자체 점검표를 붙입니다.
결론부터 말하면 무로그는 정책 선언이지 기술적 보장이 아닙니다. 어떤 서비스도 상위 데이터센터, 결제 채널, 그리고 사용자의 로컬 네트워크에 남는 흔적을 대신 지워 줄 수는 없습니다. 검증할 수 있는 부분은 '무엇을 기록하지 않는지, 얼마나 보관하는지, 어떤 경우에 예외가 있는지'를 명확히 적어 두었는가입니다.
무로그 정책은 무엇을 약속하는가
'로그를 기록하지 않는다'는 문장은 그 자체로는 정보량이 없습니다. 로그에는 여러 종류가 있고, 종류에 따라 민감도가 한 자릿수 이상 차이 나기 때문입니다.
- 연결 로그: 계정, 접속 시각, 접속 시간, 사용한 출구 노드, 할당된 IP, 누적 트래픽. 무엇을 방문했는지는 드러나지 않지만, 행동 타임라인을 재구성하기에는 충분합니다.
- 사용 로그: 방문한 도메인과 IP, DNS 쿼리, 세션 내용. 가장 민감한 범주이며, '브라우징 내용을 기록하지 않는다'는 문장이 실제로 가리키는 대상입니다.
- 진단 로그: 클라이언트 버전, 운영체제 버전, 크래시 스택. 장애 대응에 쓰이며 보통 계정과 약하게만 연결됩니다.
그래서 물어야 할 질문은 아주 구체적입니다. 어느 범주를 기록하지 않는가? 기록하는 부분은 계정과 연결되는가? 얼마나 보관하고 언제 삭제하는가? 남용 방지와 과금 과정에서 일시적으로 기록되는 항목은 없는가? 이 몇 가지에 답이 나와야 비로소 한 줄짜리 슬로건이 판단 가능한 조항이 됩니다.
| 표현 수준 | 흔한 문구 | 검증 가능한 범위 | 판단 기준 |
|---|---|---|---|
| 포괄적 약속 | "어떤 로그도 기록하지 않습니다" | 선언 한 줄뿐, 정의도 예외도 없음 | 조항을 더 찾아보고, 없으면 '미설명'으로 처리 |
| 범주별 설명 | 연결·사용·진단 세 범주의 로그 처리 방식을 각각 명시 | 어떤 범주를 얼마나 보관하는지 확인 가능 | '사용 로그 미보관'을 기본값으로 명시한 쪽을 우선 선택 |
| 예외 조항 | 남용 방지, 과금 정산, 법적 요청 대응 시 일시 기록 | 약속의 경계가 어디인지 확인 가능 | 예외가 있다고 해서 무조건 단점은 아님. 숨기는 것보다 명시하는 편이 낫다 |
| 대조 가능한 자료 | 제3자 감사 보고서, 투명성 보고서, 약관 변경 이력 | 외부 자료로 교차 검증 가능 | 감사가 다룬 기간, 노드 범위, 수행 기관을 먼저 확인 |
한 번의 제3자 감사는 특정 시점, 특정 데이터센터, 특정 프로세스를 다룬 것이며 모든 노드와 모든 시간대를 검사했다는 뜻은 아닙니다. 감사를 볼 때는 범위와 날짜를 먼저 보고, 그다음 결론을 보세요.
검증 경로: 조항에서 대조 가능한 자료까지
'검증'을 다섯 단계로 나눕니다. 순서를 바꾸지 마세요. 앞의 네 단계는 어떤 서비스에서도 할 수 있고, 다섯 번째는 상대가 공개 자료를 두었는지에 달려 있습니다.
- 정의 문단을 읽고, 홈페이지 슬로건은 읽지 마세요. 개인정보 처리방침에는 보통 '로그'를 정의하는 문단이 따로 있고, 연결·사용·진단을 구분해 설명합니다. 이 문단이 없는 서비스는 사실상 바로 걸러도 됩니다.
- 예외 조항을 찾으세요. 남용 방지, 과금 정산, 법적 요청이 가장 흔한 세 가지 예외입니다. 예외 자체는 정상이며, 핵심은 발동 조건과 보관 기한이 적혀 있는지입니다.
- 보관 기한과 삭제 방식을 보세요. '30일 보관'과 '보관하지 않음'은 전혀 다른 입장이며, 전자라면 적어도 예측은 가능합니다.
- 구독과 결제 단계에서 어떤 항목을 요구하는지 보세요. 조항이 아무리 깔끔해도 가입 시 긴 정보 목록을 요구한다면 그 가치는 대부분 상쇄됩니다.
- 대조할 외부 자료가 있는지 보세요. 제3자 감사, 투명성 보고서, 공개된 약관 변경 이력 — 자료가 있다고 해서 반드시 믿을 수 있는 것은 아니지만, 적어도 검증은 가능합니다.
가입 정보 최소화: 필요한 항목만 남기기
가입은 정보가 노출되는 첫 관문이며, 판단 기준은 하나입니다. 입력하지 않아도 되는 항목은 입력하지 않는 것. 항목이 적을수록 플랫폼 간 연결 고리도 줄어듭니다.
본 서비스는 이메일 주소가 필요 없으며, 사용자 이름과 비밀번호만으로 가입이 끝납니다. 이메일을 따로 언급하는 이유는 그것이 거의 모든 플랫폼의 범용 기본 키이기 때문입니다. 이메일이 서비스에 묶이는 순간, 이 한 항목만으로 서로 다른 플랫폼의 계정이 이어집니다. 이 항목이 빠지면 연결 비용은 눈에 띄게 올라갑니다.
사용자 이름도 마찬가지입니다. 커뮤니티, SNS, 다른 서비스에서 쓰던 ID를 재사용하지 말고, 실명·생년월일·거주 도시를 넣지 마세요. 비밀번호는 비밀번호 관리자로 생성해 이 사이트 전용으로 하나만 쓰고, 다른 사이트와 공유하지 않습니다. 기기를 여러 대 쓰기 위해 같은 계정으로 계속 로그인할 필요도 없습니다. 본 서비스는 대수 제한 없이 동시 접속할 수 있으므로, 계정을 외부로 퍼뜨릴 유인 자체가 줄어듭니다.
결제 단계는 두 번째 관문입니다. 알리페이, 위챗, USDT 세 채널이 남기는 기록은 서로 다릅니다. 앞의 둘은 실명 계정에 연결되어 청구서 쪽에서 사람을 특정할 수 있고, USDT는 온체인으로 기록이 공개되지만 실제 신원과는 거리를 둘 수 있습니다. 어느 쪽을 택할지는 누구로부터 보호하고 싶은지에 달려 있습니다.
클라이언트에 가져온 구독 링크에는 보통 사용자 식별자가 들어 있습니다. 단체 채팅방에 붙여 넣지 말고, 공개 저장소에 올리지 말고, 문의 티켓에 통째로 적지 마세요. 스크린샷도 뒷부분을 가려야 합니다. 제3자 '구독 변환' 페이지를 거치는 것도 권하지 않습니다. 변환 서비스는 그 링크를 전부 보게 됩니다. 유출이 의심되면 새로 발급받으면 됩니다.
공용 Wi-Fi에서의 이용 기준
공용 Wi-Fi의 위험 목록은 길지 않지만 하나하나 실제로 일어납니다. 같은 대역의 스니핑, 캡티브 포털 하이재킹, 동일 이름의 가짜 핫스팟, 변조된 DNS. HTTPS가 콘텐츠 수준의 위험 대부분을 막아 주고, 남는 것은 메타데이터와 연결 수립 단계입니다.
터널이 덮는 범위는 기기에서 출구 노드까지입니다. 콘텐츠는 암호화되고, 클라이언트가 DNS를 넘겨받으면 도메인 조회도 함께 터널을 탑니다. 덮지 못하는 것은 이미 로그인한 계정, 앱 자체의 텔레메트리와 푸시, 브라우저 지문, 그리고 기기에 설치된 루트 인증서입니다. 기업 기기 관리나 수동 설치로 인증서가 들어간 기기라면 중간자 공격은 여전히 가능합니다.
- 연결 후에는 출구부터 확인하세요. IP 조회 페이지에 접속해 표시되는 위치가 선택한 회선과 일치하는지 봅니다.
- 다음은 DNS입니다. 리졸버 소속이 출구 지역과 일치해야 하며, 다르다면 조회가 여전히 로컬로 나가고 있다는 뜻입니다.
- 킬 스위치를 켜 두세요. 터널이 끊긴 뒤 트래픽이 조용히 직접 연결로 되돌아가는 것을 막습니다.
- '개방형 핫스팟 자동 연결'을 꺼 두세요. 기기가 모르는 사이에 낯선 네트워크에 붙지 않도록 합니다.
- 인터넷 뱅킹이나 사내 관리자 페이지 같은 작업은 가능하면 신뢰할 수 있는 네트워크에서 하세요.
흔한 오해 중 하나가 '연결하면 전부 터널로 간다'는 생각입니다. 분할 라우팅 모드에서는 그렇지 않습니다. 규칙에 따라 일부 도메인은 직접 연결되고, 해당 DNS 조회도 로컬 리졸버로 넘어갈 수 있습니다. 프라이버시가 중요한 상황이라면 전역 모드가 더 편합니다.
프로토콜과 클라이언트의 개인정보 디테일
프로토콜은 트래픽이 어떤 모습인지를 정할 뿐, 서버가 로그를 남기는지 여부를 정하지는 않습니다. 이 둘은 자주 뒤섞이는데, 나눠 보면 훨씬 명확해집니다.
- WireGuard: UDP 기반에 핸드셰이크가 간결하고 구현이 가벼워 모바일에서 전력 효율이 좋습니다. 트래픽 난독화는 하지 않으므로 특징이 비교적 뚜렷합니다.
- OpenVPN: 성숙하고 안정적이며 TCP 443을 사용할 수 있어 호환성이 좋습니다. 대신 핸드셰이크와 암호화 오버헤드가 더 큽니다.
- Shadowsocks: 본질적으로는 VPN이 아니라 프록시 프로토콜이라, 클라이언트가 라우팅 처리와 DNS 처리를 따로 해 줘야 합니다.
- VMess / VLESS: VMess는 클라이언트와 서버의 시간 동기화에 의존하고, VLESS는 자체 암호화를 하지 않아 보안을 외부 TLS에 맡깁니다.
- Trojan: 트래픽을 평범한 HTTPS 세션으로 위장하며 실제 인증서에 의존하므로 설정 비용이 조금 더 듭니다.
- Hysteria2 / TUIC: QUIC 기반이라 약전계·고손실 환경에서 더 안정적이지만, UDP 품질에 민감합니다.
클라이언트 차이도 중요합니다. 데스크톱은 보통 시스템 DNS와 전역 라우팅을 넘겨받을 수 있고, 모바일은 시스템 제약이 더 많습니다. iOS에서는 시스템 수준 네트워크 확장으로 트래픽을 넘겨받고 DNS는 대개 터널 안에서 해석됩니다. 동작 차이는 추측하지 말고 자기 기기에서 한 번 확인하면 됩니다. 연결 후 출구 IP, DNS 리졸버 소속, IPv6가 터널을 우회하는지를 보세요. 터널이 IPv4만 처리할 때 IPv6 트래픽은 그대로 나갈 수 있습니다. 브라우저지에는 WebRTC도 있어 로컬 주소를 노출할 수 있으므로, 브라우저 설정에서 제한하거나 끌 수 있습니다.
분할 라우팅 규칙도 놓치기 쉬운 지점입니다. 도메인 기준, GeoIP 기준으로 분할이 세분화될수록 터널을 우회하는 트래픽이 늘고 DNS도 로컬 리졸버로 돌아갈 수 있습니다. 규칙 자체에 정답은 없지만, 내가 어떤 모드를 켜 두었는지는 알아야 합니다.
실행 가능한 자체 점검 목록
아래 여덟 항목은 조항·가입·연결 세 층을 다룹니다. 하나씩 대조해 보세요.
- ✅ 개인정보 처리방침의 로그 정의 문단을 읽고, '어떤 범주를 기록하지 않으며 얼마나 보관하는지'를 말할 수 있다.
- ✅ 가입할 때 별도의 사용자 이름과 별도의 비밀번호를 썼고, 다른 플랫폼의 ID를 재사용하지 않았다.
- ✅ 구독 링크는 공식 클라이언트에만 가져왔고, 제3자 변환 페이지를 거치지 않았다.
- ✅ 연결 후 출구 IP와 DNS 리졸버를 확인했고, 두 곳의 소속이 일치한다.
- ✅ IPv6와 WebRTC가 터널을 우회하지 않는 것을 확인했다.
- ✅ 킬 스위치를 켜 두어, 연결이 끊겨도 조용히 직접 연결로 되돌아가지 않는다.
- ❌ 공용 Wi-Fi에서 인터넷 뱅킹이나 관리자 페이지에 로그인하지 않았다.
- ❌ 구독 링크를 단체 채팅방, 공개 저장소, 문의 본문에 붙여 넣지 않았다.
결론: 기준을 검증 가능한 항목으로
프라이버시에는 한 번에 끝나는 해법이 없고, 확인 가능한 항목만 있습니다. 조항을 읽을 수 있는가, 가입에 몇 개 항목을 요구하는가, 구독 링크가 아무렇게나 밖으로 나가지 않는가, 클라이언트가 말한 대로 동작하는가 — 이 네 가지를 한 번 훑는 편이 리뷰 열 편을 읽는 것보다 유용합니다.
기준을 특정 서비스에 적용할 때는 현장에서 바로 확인할 수 있는 사실부터 보세요.
마지막으로 한 가지. 무로그는 정책이지 부적이 아닙니다. 서버 쪽 보관에서 오는 위험을 낮출 뿐, 계정·결제·기기에서 남는 흔적을 바꾸지는 않습니다. 이 두 층을 나눠 보면 선택이 훨씬 명확해집니다.