이 글은 프라이버시 VPN 추천 순위를 매기는 글이 아니라, '무로그'라는 세 글자를 직접 확인할 수 있는 항목으로 쪼개는 글입니다. 약관의 약속은 문서상 표현일 뿐이고, 사용자가 내릴 수 있는 판단은 세 곳에 모입니다. 얼마나 구체적으로 쓰여 있는지, 가입할 때 어떤 정보를 요구받는지, 결제할 때 어떤 기록이 남는지입니다.
순서가 중요합니다. 회선과 속도는 연결이 되는지를 결정하고, 위의 세 가지는 연결된 뒤에 내가 누구인지를 결정합니다. 프라이버시 비용을 먼저 따져보고 노드 수와 지연 시간을 보면 선택이 훨씬 쉬워집니다.
무로그 정책을 왜 직접 확인해야 할까
'무로그'는 입장을 밝히는 문장이지, 벽에 걸어둘 수 있는 인증서가 아닙니다. 어떤 서비스든 약관에 이 문장을 써넣을 수 있습니다. 차이는 그 뒤에 세부 조항이 있는지, 그 조항이 제품 자체와 맞아떨어지는지에 있습니다.
흔히 남는 기록을 나눠 보면 크게 세 가지입니다.
- 연결 로그: 로그인 시간, 할당된 노드, 출구 IP, 세션 시간.
- 사용 로그: 방문한 도메인, DNS 조회 기록, 전송 내용.
- 과금 데이터: 계정 식별자, 요금제 등급, 사용한 트래픽 총량, 만료 시각.
세 번째는 완전히 피하기 어렵습니다. 과금, 환불, 장애 대응에 모두 필요하기 때문입니다. 그래서 진짜 물어야 할 것은 '기록이 있느냐'가 아니라 '어떤 종류를, 얼마나 오래, 어떤 조건에서 제3자에게 넘기는가'입니다. 이 세 가지를 확인해야 약속이 구호에서 범위로 바뀝니다.
반대로 '프라이버시를 중시합니다', '암호화를 적용합니다'만 적어두고 기록 범위를 쓰지 않은 약관은 아직 홍보 문구 단계라 확인할 방법이 없습니다.
첫 번째: 약관 문구를 문장 단위로 읽기
약관을 처음부터 끝까지 읽을 필요는 없습니다. 먼저 세 종류의 문장을 찾으세요. 무엇을 기록하는지, 얼마나 보관하는지, 누구에게 제공하는지입니다. 아래 표는 흔한 표현을 확인 가능한 정도에 따라 높은 순서에서 낮은 순서로 정리한 것입니다.
| 약관의 표현 | 확인 가능 정도 | 판단 근거 |
|---|---|---|
| 열람 내용을 기록하지 않음, 방문 도메인을 기록하지 않음, DNS 조회를 저장하지 않음 | 높음 | 기록 범위가 항목 단위로 구체적이어서 클라이언트 동작과 하나씩 대조 가능 |
| 과금에 필요한 데이터만 보관: 요금제, 트래픽 총량, 만료 시각 | 높음 | 보관 범위가 제한적이고 업무와 직접 관련됨 |
| 전송 구간을 암호화 기술로 보호 | 중간 | 암호화는 전송 구간만 덮을 뿐 기록 범위와는 무관 |
| 데이터를 익명화 처리 | 중간 | 익명화가 어느 단계에서 일어나는지, 되돌릴 수 있는지 설명 없음 |
| 어떤 데이터도 절대 기록하지 않음 | 낮음 | 과금·환불 절차와 모순되며 보통 세부 조항이 없음 |
| 적법한 요청을 받으면 데이터를 제공할 수 있음 | 추가 확인 필요 | 무엇을 제공할 수 있는지 밝히지 않으면 범위가 정해지지 않은 것과 같음 |
표에서 가장 눈여겨볼 줄은 마지막입니다. 핵심은 서비스에 어떤 요청에도 절대 응답하지 않겠다고 요구하는 것이 아니라, 손에 무엇이 있는지 분명히 적으라고 요구하는 것입니다. 보관하는 데이터가 요금제와 트래픽 총량뿐이라면 넘겨줄 수 있는 것 자체가 제한적입니다.
또 하나의 세부 사항은 보관 기간입니다. '필요한 경우에만 보관'은 쓰지 않은 것과 같습니다. '과금 데이터는 계정 해지 후 며칠 내 삭제'처럼 적어야 확인 가능한 표현이 됩니다.
약관에 나온 약속 문구를 한쪽에 적어두고, 가입 양식과 사용자 패널, 클라이언트 설정에서 대응 항목을 찾아보세요. 약속과 제품이 어긋나는 것이 가장 흔한 불일치 원인입니다.
두 번째: 가입 항목과 계정 식별자
가입 양식은 프라이버시 비용이 가장 직관적으로 드러나는 곳입니다. 필수 입력란 하나하나가 계정과 다른 곳에 남긴 기록을 이어주는 실마리가 됩니다.
이메일이 가장 흔한 항목입니다. 단순한 수신 주소가 아니라 오래 존재하고 여러 서비스에서 재사용되는 신원 식별자입니다. 비밀번호 재설정, 알림 수신, 청구서 수신이 모두 이메일을 거칩니다. 가입할 때 입력란이 하나 줄면 나중에 연결 경로도 하나 줄어듭니다.
본 서비스의 경우 사용자 이름 + 비밀번호만으로 가입할 수 있고 이메일 주소가 필요하지 않습니다. 양식에 필수 이메일이 없으니 '이메일—계정' 대응 관계를 유지할 필요도 없습니다.
- ✅ 가입 양식은 사용자 이름과 비밀번호만 요구하며 필수 이메일 입력란이 없음
- ✅ 사용자 이름을 평소 쓰는 닉네임이나 이메일 앞부분과 겹치지 않게 설정
- ✅ 비밀번호는 비밀번호 관리자로 생성하고 서비스마다 다르게 사용
- ✅ 연락이 필요할 때는 이메일 알림을 계속 구독하는 대신 사용자 패널 내 문의로 처리
- ❌ 평소 주로 쓰는 이메일로 가입하고 이메일 알림까지 켜두기
- ❌ 기억하기 편하다는 이유로 다른 서비스와 같은 비밀번호 사용
마지막 두 가지는 자주 간과되지만 익명 계정을 실제 신원으로 되돌리기 가장 쉽습니다. 여러 해 재사용한 닉네임 하나, 여기저기 쓰는 비밀번호 하나면 서로 다른 플랫폼의 기록이 한 줄로 이어질 수 있습니다.
세 번째: 결제 수단이 남기는 정보
결제는 전체 경로에서 현실 세계와 반드시 연결되는 유일한 지점입니다. 그래서 수단을 고르기 전에 어느 쪽 기록을 줄이려는지 먼저 정해야 합니다. 가맹점 쪽인지, 결제 플랫폼 쪽인지, 아니면 같은 기기를 쓰는 다른 사용자인지입니다.
알리페이 / 위챗
두 채널 모두 제3자 결제 플랫폼을 거칩니다. 가맹점 쪽은 보통 주문 번호, 금액, 결제 상태만 보게 되고, 전체 거래 기록은 결제 플랫폼에 남아 본인 계정과 연결됩니다. 이 방식이 줄여주는 것은 가맹점과의 직접적인 연관이며, 결제 플랫폼 쪽 기록은 그대로 남습니다.
USDT
USDT는 전통적인 결제 채널을 거치지 않아 가맹점 쪽과 결제 플랫폼 쪽의 연관이 동시에 약해집니다. 하지만 흔적이 전혀 없는 것은 아닙니다. 온체인 전송은 공개 원장이라 금액, 시간, 주소를 누구나 볼 수 있고, 중앙화 거래소에서 출금했다면 거래소 쪽에는 실명 기록이 남습니다. 이 방식이 끊는 것은 가맹점과 결제 플랫폼 사이의 연결선이지, 전송 자체가 사라지는 것이 아닙니다.
세 가지 방식에 절대적인 우열은 없고 줄이려는 대상만 다릅니다. 가맹점과의 연관이 신경 쓰이면 암호화폐 채널을, 조작 편의성과 환불 절차가 중요하면 제3자 결제를 보면 됩니다.
어떤 방식으로 결제하든 주문 번호와 구독 링크는 공개 채팅방에 올리지 마세요. 구독 링크는 계정 자격 증명과 같아서 유출되면 주문 번호보다 훨씬 직접적인 결과로 이어집니다.
공용 Wi-Fi 환경 점검표
약관과 가입 항목은 정적인 반면, 공용 Wi-Fi는 상황에 따라 달라지는 환경입니다. 같은 기기, 같은 계정이라도 네트워크가 바뀌면 위험 계층이 하나 늘어납니다. 아래 점검표는 '연결 전—연결 후' 순서로 되어 있으며, 하나씩 확인하는 데 약 2분이면 충분합니다.
- ✅ 연결 전 핫스팟 이름의 철자를 정확히 확인 — 같은 이름의 핫스팟은 흔한 위장 수법
- ✅ 시스템의 '알려진 네트워크 자동 연결'을 꺼서 같은 이름의 핫스팟에 모르는 사이 접속하지 않도록 설정
- ✅ 연결 후에는 어떤 계정에 로그인하기 전에 출구 IP의 위치가 선택한 회선과 일치하는지 먼저 확인
- ✅ 클라이언트에 연결 끊김 보호(킬 스위치) 옵션이 있으면 켜서 회선이 끊겼을 때 트래픽이 직결로 새지 않도록 설정
- ✅ 겸사겸사 DNS 유출 검사도 한 번: 리졸버 소속이 로컬 네트워크가 아니라 출구 지역과 일치해야 함
- ❌ 트래픽 경로를 확인하기 전에 이메일, 클라우드 저장소 같은 중요 계정에 로그인
- ❌ 브라우저의 인증서 경고를 무시하고 '계속 진행' 버튼을 습관적으로 누르기
- ❌ 공용 네트워크에서 파일 공유나 AirDrop을 모든 사람에게 공개해 두기
이 중 가장 자주 빠뜨리는 것이 DNS 유출입니다. 트래픽이 회선을 타더라도 도메인 조회가 로컬 네트워크의 리졸버로 넘어가면, 어떤 사이트에 접속했는지가 도메인 형태로 로컬 구간에 그대로 노출됩니다. 확인 방법은 간단합니다. 연결 후 DNS 유출 검사 페이지를 열어 리졸버 소속을 보면 됩니다. 로컬 통신사로 표시된다면 조회가 회선을 따라가지 않았다는 뜻입니다.
네 가지 흔한 오해
아래 네 가지는 선택할 때 가장 흔한 판단 오류로, 각각이 앞서 확인한 내용을 헛수고로 만들 수 있습니다.
- 연결하면 익명이 된다. 회선이 보호하는 것은 전송 구간입니다. 같은 브라우저에서 로그인한 계정, 쿠키, 기기 지문은 출구를 바꿔도 사라지지 않습니다.
- '무로그'라는 말만 믿는다. 보관 범위와 보관 기간을 쓰지 않은 약속은 쓰지 않은 것과 크게 다르지 않습니다.
- 암호화 강도가 높을수록 프라이버시도 좋아진다고 생각한다. 프로토콜과 암호화가 결정하는 것은 링크 특성과 성능입니다. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, TUIC 사이의 차이는 주로 여기에 있으며, 계정 쪽에 어떤 데이터가 남는지는 바꾸지 않습니다.
- 분할 터널링 규칙을 속도 스위치로 여긴다. 분할 터널링은 어떤 도메인이 회선을 타고 어떤 도메인이 직결되는지를 정합니다. 민감한 도메인을 직결 규칙에 넣으면 그 트래픽은 회선을 거치지 않은 것과 같아서 노드가 아무리 빨라도 소용이 없습니다.
판단 기준은 하나입니다. 약속이 구체적인 항목으로 내려올 수 있는가. 구체적일수록 대조하기 쉽고, 두루뭉술할수록 신뢰에만 기대야 합니다.
이 방법을 실제 서비스에 적용하기
세 가지를 대조해 보면 본 서비스가 공개적으로 확인해 줄 수 있는 항목은 많지 않지만, 모두 구체적인 항목으로 내려옵니다.
가입에 이메일 주소가 필요 없고 사용자 이름 + 비밀번호로 시작할 수 있습니다. 결제는 알리페이, 위챗, USDT를 지원합니다. 구독 하나로 기기 수 제한 없이 가지고 있는 어떤 기기에든 연결할 수 있습니다. 프라이버시 입장은 익명·무로그로 통일해 표기합니다. 클라이언트는 Windows, macOS, iOS, Android, Linux 다섯 플랫폼을 지원합니다.
이 모든 것은 직접 검증할 수 있습니다. 가입할 때는 양식 필드를, 결제할 때는 수단 옵션을, 연결 후에는 출구 IP와 DNS 소속을 확인하면 됩니다.
네 단계 확인 절차
전체 내용을 그대로 따라 할 수 있는 절차로 압축했습니다. 순서를 바꾸지 마세요. 각 단계의 결론이 다음 단계의 판단에 영향을 줍니다.
- 약관을 읽고 세 종류의 문장을 찾는다. 무엇을 기록하는지, 얼마나 보관하는지, 누구에게 제공하는지. 세 가지 중 두 가지 이상 빠져 있으면 일단 적어두고 성급히 결론 내리지 않습니다.
- 가입 양식의 입력란을 센다. 필수 이메일이 있는지, 이름이나 회사 같은 정보를 요구하는지 봅니다. 입력하지 않아도 되는 것은 입력하지 않고, 줄일 수 있으면 줄입니다.
- 결제 수단을 고르기 전에 목표를 정한다. 가맹점과의 연관을 줄일 것인가, 결제 플랫폼과의 연관을 줄일 것인가? 목표가 다르면 선택도 달라집니다.
- 연결 후 세 가지를 검증한다. 출구 IP의 위치, DNS 리졸버의 소속, 분할 터널링 규칙에 민감한 도메인이 직결로 들어가 있지 않은지.
네 번째 단계까지 마쳐야 '연결됐다'와 '의도한 대로 흐른다'를 구분할 수 있습니다.
구독 링크가 유출된 것이 의심되면 먼저 사용자 패널에서 구독 재설정 메뉴를 찾아 다시 가져오세요. 해당 메뉴가 없으면 패널 내 문의로 지원팀에 연락해 처리하면 됩니다.
프라이버시는 한 번의 설정이 아니라 반복해서 확인할 수 있는 선택의 묶음입니다. 약관을 구체적으로 읽고, 가입 정보는 적게 넣고, 결제는 목적을 분명히 하고, 연결 후 한 번 검증하기 — 네 단계를 마치면 '무로그'가 홍보 문구에서 스스로 확인할 수 있는 범위로 바뀝니다.