Tor와 VPN 차이점: 나에게 필요한 도구는?
Tor와 VPN은 개인정보를 보호하는 방식이 완전히 다릅니다. ISP와 VPN 운영자가 각각 어떤 데이터를 수집하는지, 익명성을 위해 왜 VPS를 사용하면 안 되는지 구체적인 기술적 차이를 분석합니다. 사용 목적에 맞는 올바른 보안 도구를 선택하는 기준을 확인하십시오.
Tor와 VPN: 실제로 무엇이 필요한가
Tor와 VPN은 모두 사용자의 트래픽을 사용자의 것이 아닌 다른 장비로 전송하지만, 해결하는 문제는 서로 다릅니다. VPN(virtual private network)은 인터넷 서비스 제공업체에 대한 신뢰를 특정 기업으로 옮기는 방식이며, 해당 기업은 사용자의 실제 주소와 방문하는 모든 목적지를 파악할 수 있습니다. 반면 Tor는 서로 다른 운영자가 관리하는 3개의 릴레이에 신뢰를 분산하므로, 어떤 단일 릴레이도 사용자가 누구인지와 어디로 향하는지를 동시에 알 수 없습니다. 누구로부터 정보를 숨길 것인지에 따라 선택하십시오.
숨기려는 대상이 현재 접속 중인 네트워크라면 VPN이 적절한 도구입니다. 만약 웹사이트 자체이거나 특정 기업의 기록을 강제로 열람할 수 있는 주체라면 Tor가 적절한 도구입니다. 이 가이드의 나머지 부분은 앞서 언급한 두 문장에 대한 상세한 설명입니다.
두 가지 설계에서 하나의 요청이 처리되는 과정
일반적인 요청 하나를 예로 들어보겠습니다. 브라우저가 https://news.example.com를 엽니다. TLS(transport layer security)는 어떤 방식을 사용하든 페이지 콘텐츠를 보호하므로, 중간에 있는 누구도 기사 내용을 읽을 수 없습니다. 흥미로운 부분은 메타데이터입니다. 누가 사용자의 IP 주소를 알게 되는지, 누가 목적지를 알게 되는지, 그리고 누가 이 두 가지 사실을 결합할 수 있는지에 대한 문제입니다. 개인정보 보호 도구는 이 두 정보를 분리하는 기계와 같습니다. VPN은 이 쌍을 다른 관리자에게 옮기고, Tor는 이를 분리합니다.
VPN 사용 시 각 주체가 확인하는 정보
클라이언트는 모든 패킷을 암호화하여 하나의 엔드포인트로 전송합니다. 해당 엔드포인트부터는 다시 일반적인 트래픽으로 처리됩니다.
- ISP(인터넷 서비스 제공업체)는 사용자의 회선과 VPN 서버 주소 사이를 오가는 암호화된 패킷을 확인합니다. 트래픽의 양과 발생 시점은 알 수 있습니다. DNS(도메인 네임 시스템) 쿼리까지 터널을 통과한다면, ISP는 목적지 호스트 이름을 확인할 수 없습니다.
- VPN 운영자는 한쪽 끝에서 사용자의 실제 IP 주소를, 다른 쪽 끝에서 모든 목적지 주소를 시간 및 데이터 크기와 함께 확인합니다. 이 두 정보는 동일한 장비에서 처리됩니다.
- 목적지 사이트는 VPN의 출구 주소와 브라우저가 전송하는 모든 식별 정보를 확인합니다.
따라서 VPN은 익명성을 보장하지 않습니다. 관찰자의 위치를 ISP에서 VPN 제공업체로 옮길 뿐입니다. 로컬 네트워크가 문제이거나 ISP가 트래픽을 필터링 또는 판매하는 상황이라면 이는 실질적인 이득이 됩니다. 하지만 방문하는 사이트 입장에서는 아무런 이득이 없습니다. 사용자의 트래픽은 여전히 사용자가 누구인지 정확히 알고 결제 기록까지 보유한 단일 기업을 통해 전달되기 때문입니다.
"로그 없음(no logs)" 정책은 VPN 서비스의 핵심이지만, 사용자가 직접 검증할 수 없는 유일한 부분이기도 합니다. 터널이 정상적으로 연결되었는지, DNS 유출이 없는지는 확인할 수 있습니다. 하지만 운영자가 디스크에 무엇을 기록하는지는 확인할 방법이 없습니다. 이것이 사용자가 감수해야 할 거래입니다. 즉, 사용자가 선택한 단일 기업이 전체 정보를 보유하게 됩니다.
터널을 무력화하는 유출을 확인하십시오:
resolvectl status
curl -s https://ifconfig.me; echoifconfig.me가 출력하는 주소는 VPN의 출구 주소여야 합니다. 기본 경로를 담당하는 링크에 나열된 DNS 서버는 터널의 리졸버여야 합니다. 만약 192.168.1.1에 여전히 로컬 라우터가 표시된다면, 도메인 이름 조회 요청이 로컬 링크를 통해 평문으로 유출되고 있는 것입니다. 해당 라우터로 향하는 경로가 터널의 기본 경로보다 더 구체적인 온링크(on-link) 경로로 설정되어 있기 때문입니다. 이 경우 트래픽은 암호화되더라도 방문 사이트 목록은 노출됩니다. WireGuard 터널에서 DNS 쿼리가 유출되는 문제에서 해결 방법을 확인할 수 있습니다.
Tor 사용 시 각 주체가 확인하는 정보
Tor는 소수의 디렉터리 권한 기관이 게시한 서명된 목록인 consensus에서 선택한 3개의 릴레이로 회로를 구성합니다. 클라이언트는 릴레이당 하나씩, 데이터를 여러 겹으로 암호화합니다. 각 릴레이는 한 겹의 암호화를 제거하고 다음 홉만 확인한 뒤 나머지를 전달합니다. 이러한 계층 구조 덕분에 경로상의 누구도 전체 정보를 알 수 없습니다.
- ISP는 가드 릴레이로 향하는 암호화된 트래픽만 확인합니다. 릴레이 주소는 공개되어 있으므로 ISP는 사용자가 Tor를 사용 중이라는 사실은 알 수 있지만, 어떤 사이트에 접속하는지는 알 수 없습니다.
- 가드 릴레이는 사용자의 실제 IP 주소를 확인합니다. 하지만 목적지는 알 수 없습니다. 사이트 정보가 포함된 메시지 부분은 뒤에 올 릴레이들을 위해 여전히 암호화되어 있기 때문입니다.
- 중간 릴레이는 한쪽의 가드와 다른 쪽의 출구 릴레이만 확인합니다. 사용자나 목적지는 알 수 없습니다. 가드와 출구가 직접 통신하지 않도록 중간에서 연결하는 역할을 합니다.
- 출구 릴레이는 네트워크를 떠나는 목적지와 트래픽을 확인합니다. 사용자의 주소가 아닌 중간 릴레이의 주소를 확인합니다. HTTPS를 사용하는 경우 호스트 이름과 연결 메타데이터는 알 수 있지만, 구체적인 페이지 내용은 알 수 없습니다.
- 목적지는 공개된 출구 목록에 있는 출구 릴레이의 주소와 브라우저가 전달하는 정보를 확인합니다.
사용자와 사이트를 연결하려면 가드와 출구 릴레이를 동시에 장악해야 합니다. 이것이 Tor 설계의 핵심입니다. 클라이언트가 매번 새로운 가드를 선택하지 않고 수개월 동안 동일한 가드를 유지하는 이유이기도 합니다. 가드를 계속 교체하면 악의적인 릴레이가 사용자의 가드가 될 기회가 반복적으로 주어지기 때문입니다.
회로는 영구적이지 않습니다. 새로운 연결은 대략 10분마다 새로운 회로로 이동하지만, 이미 열려 있는 스트림은 시작된 회로를 유지합니다. 긴 다운로드와 15분 뒤에 여는 탭은 일반적으로 서로 다른 출구를 통해 나갑니다.
릴레이가 다른 릴레이 정보를 알지 못한 채 3개의 홉이 구성되는 방식
클라이언트는 가드에게 릴레이 전체 목록을 전달하지 않습니다. 먼저 가드와 키를 협상한 뒤, 가드를 통해 중간 릴레이로 회로를 확장하도록 요청하고, 다시 그 홉을 통해 출구 릴레이로 확장하도록 요청합니다. 각 릴레이는 다음에 통신해야 할 이웃 정보만 전달받으며, 각 홉은 다른 홉이 알 수 없는 고유한 키를 가집니다. 이것이 중간 릴레이가 출구 릴레이의 역할을 알 수 없는 이유이며, 모든 처리 과정을 기록하는 릴레이라도 전체 경로 중 일부만 기록할 수 있는 이유입니다.
설치 후 경로를 확인하십시오:
sudo apt update && sudo apt install -y tor
systemctl status tor@default
journalctl -u tor@default -n 20
curl --socks5-hostname 127.0.0.1:9050 https://check.torproject.org/api/ip로그는 Bootstrapped 100% (done): Done에 도달해야 합니다. curl은 본인이 알지 못하는 주소를 {"IsTor":true,"IP":"..."}로 출력해야 하며, 이것이 현재 사용 중인 출구 주소입니다. IsTor이 false라면 요청이 프록시를 통하지 않은 것입니다. Ubuntu의 패키지된 Tor는 최신 릴리스보다 버전이 낮을 수 있습니다. 업스트림 버전을 추적해야 한다면 Tor Project에서 제공하는 자체 apt 저장소를 사용하십시오.
해당 명령어에는 주의할 점이 하나 있습니다. --socks5은 curl이 호스트 이름을 직접 해석한 뒤 결과 주소를 프록시로 보내게 하므로, 일반적인 DNS 해석기가 사용자가 방문하는 모든 이름을 알게 됩니다. --socks5-hostname은 이름을 Tor로 보내 출구 릴레이가 해석하게 합니다. 터널은 같지만 정보 유출 여부는 완전히 다릅니다. Tor Browser와 torsocks는 이를 올바르게 처리하지만, 수동으로 설정한 도구들은 그렇지 않은 경우가 많습니다.
Tor는 TCP 스트림만 전송합니다. UDP는 전송할 수 없으므로 ping 1.1.1.1은 Tor를 통해 전달되지 않으며, UDP 기반 VPN 프로토콜도 내부에서 실행할 수 없습니다. 프록시 설정을 무시하는 프로그램은 일반적인 경로와 주소를 그대로 사용하며, 이 과정에서 어떠한 경고도 표시되지 않습니다. 이것이 시스템 전체의 Tor를 환경 변수가 아닌 별도의 장비에서 투명 프록시로 구성하는 이유입니다.
신뢰가 실제로 향하는 곳
VPN은 신뢰를 한곳으로 집중시킵니다. 단일 기업이 사용자의 신원, 결제 기록, 전체 트래픽 패턴을 모두 보유하며, 사용자의 보호는 로그를 저장하지 않겠다는 해당 기업의 약속에 의존합니다. 그 약속이 유효한 동안에는 설계가 깔끔하고 빠르며 논리적으로 이해하기 쉽습니다. 하지만 소환장, 보안 침해, 혹은 거짓말로 인해 그 약속이 깨지는 순간, 사용자의 모든 트래픽은 즉시 완전히 노출됩니다.
Tor는 신뢰를 분산시킵니다. 서로를 거의 알지 못하는 세 주체가 각각 파편화된 정보를 보유하며, 파편 하나만으로는 가치가 거의 없습니다. 설계가 작동하기 위해 누군가가 정직할 필요는 없습니다. 단지 그들이 서로 독립적이기만 하면 됩니다. 그 대가로 속도 저하, TCP 전용이라는 제약, 그리고 사용자를 감시하려는 이들이 운영하는 릴레이가 분명히 존재하는 네트워크를 감수해야 합니다. 적대적인 릴레이에 대한 Tor의 대응은 하나의 릴레이만으로는 결코 충분하지 않다는 것입니다.
VPN이 적합한 경우
- 로컬 네트워크(호텔, 공항, 컨퍼런스 홀, 임대인의 라우터 등)를 신뢰할 수 없는 경우입니다. 네트워크 운영자는 암호화된 터널만 볼 수 있을 뿐 그 내용은 알 수 없습니다.
- 본인의 장비에 접근해야 하거나, 직접 제어하는 고정 IP 주소에서 통신을 시작해야 하는 경우입니다.
- 속도와 UDP가 필요한 경우입니다(화상 통화, 게임, 대용량 전송, 백업 등).
- 웹사이트에서 차단하지 않는 안정적인 주소가 필요한 경우입니다. Tor exit node는 웹 전반에서 차단되거나 CAPTCHA를 요구하는 경우가 많습니다.
위 목록은 구독형 서비스를 구매하는 대신 VPS에서 직접 VPN을 운영해야 하는 이유를 설명하며, 직접 구축한 WireGuard 서버는 사용자가 직접 소유한 설정 파일에 따라 로깅 정책이 결정되는 터널을 제공합니다. 장치 간 키 관리 기능이 포함된 동일한 터널을 원한다면 일반 WireGuard와 Tailscale의 차이점을 비교해 보아야 합니다. 이들 각각은 위 목록의 작업을 수행하는 데 탁월하지만, 다음 목록에 해당하는 작업은 수행하지 않습니다.
Tor가 적합한 도구인 경우
- 상대방이 목적지 사이트이거나, 단일 기업에 기록 제출을 요구할 수 있는 주체인 경우.
- 추적될 경우 본인에게 해가 될 수 있는 내용을 읽거나 게시하는 경우.
- onion 서비스를 원하는 경우: 트래픽이 네트워크를 벗어나지 않고, exit relay를 거치지 않으며, 서버 주소가 숨겨진 상태로 유지됩니다.
- 느린 페이지 로딩, CAPTCHA, 간헐적인
403 Forbidden를 감수할 수 있는 경우.
일상적으로 사용하는 브라우저를 9050 포트로 연결하지 말고 Tor Browser를 사용하십시오. 브라우저는 보호의 절반을 담당하며, 다음 다음 섹션에서 그 이유를 설명합니다.
임대한 VPS가 익명성 측면에서 상용 VPN보다 못한 이유
사람들이 흔히 잘못 알고 있는 부분입니다. 임대한 VPS는 귀하의 이름으로 계약된 임대 자산입니다. 가입 시 사용한 이메일, 결제 카드, 청구서, 고객 지원 티켓 등이 해당 IP 주소와 함께 한 회사의 데이터베이스에 저장됩니다. 누군가 귀하와 해당 주소를 연결하기 위해 시스템을 해킹할 필요가 없습니다. 이미 기록되어 있고, 일반적인 회계 목적으로 보관되며, 법적 효력이 있는 요청을 통해 제공업체에 문의할 수 있는 사람이라면 누구든 접근할 수 있기 때문입니다.
두 번째 문제는 사용자 군집의 부재입니다. 상용 VPN의 출구 주소는 수많은 고객이 동시에 공유하므로, 해당 주소만으로는 특정 개인을 지목할 수 없습니다. 반면 VPS 주소는 오직 귀하만이 사용합니다. 해당 주소에서 발생하는 모든 요청은 오늘이든 다음 달이든 귀하의 것이며, 주소가 변경되지 않으므로 목적지 서버는 쿠키 없이도 수개월에 걸쳐 귀하의 프로필을 구축할 수 있습니다.
물론 그렇다고 해서 직접 호스팅하는 VPN이 나쁘다는 의미는 아닙니다. 신뢰할 수 없는 네트워크에서 트래픽을 암호화하거나, 어디서든 자신의 서비스에 접근하는 용도로는 매우 훌륭합니다. 단지 익명성을 위한 도구는 아니며, 이를 익명성 도구로 사용하는 것이 오류입니다. 제공업체가 서버 내부에서 무엇을 볼 수 있고 무엇을 볼 수 없는지에 대한 명확한 설명은 VPS 호스팅의 실제 안전성에서 확인하십시오.
Tor와 VPN이 해결하지 못하는 문제
- 브라우저 핑거프린팅. 사용자 에이전트, 화면 크기, 시간대, 설치된 글꼴, 언어, 캔버스 렌더링 정보가 결합하면 종종 고유한 값이 생성되며, 이는 사용자가 사용하는 모든 IP 주소를 따라다닙니다. Tor Browser는 모든 사용자가 동일하게 보이도록 만들고 창 크기를 고정된 단계로 조절하여 이에 대응합니다. SOCKS 프록시 뒤에서 일반 브라우저를 사용하면 기존의 핑거프린트와 쿠키가 그대로 유지됩니다.
- 로그인. 본인의 이름을 알고 있는 계정에 로그인하는 순간, 네트워크 계층의 보호는 의미가 없어집니다. 집에서 한 번, Tor를 통해 한 번 동일한 계정에 로그인하면 두 세션은 서로 연결됩니다.
- 엔드포인트가 기록하는 모든 정보: 입력한 내용, 구매한 내역, 검색한 기록 등은 보호되지 않습니다.
- 종단 간 상관관계 분석. 사용자의 회선과 출구 노드를 동시에 감시하는 공격자는 타이밍과 패킷 용량을 대조하여 양쪽 끝을 연결할 수 있습니다. Tor는 양쪽을 모두 볼 수 있는 공격자에 대해서는 방어할 수 없음을 명확히 밝히고 있습니다.
Tor와 VPN을 함께 사용할 수 있습니까?
Tor over VPN은 VPN에 먼저 연결한 뒤 그 안에서 Tor를 실행하는 방식입니다. 이 경우 ISP는 VPN 연결만 확인하며, 가드 릴레이는 사용자의 실제 주소 대신 VPN의 주소를 보게 됩니다. 하지만 이는 사용자의 이름과 카드 정보를 보유한 기업을, 바로 그러한 추적을 피하기 위해 설계된 시스템 앞에 배치하는 결과를 낳습니다. 이 방식이 유효한 경우는 단 하나뿐입니다. 사용자의 회선에서 Tor를 사용하는 것 자체가 위험하며, 다른 더 나은 선택지가 없을 때입니다.
VPN over Tor는 트래픽이 Tor 네트워크를 빠져나온 뒤 VPN 계정으로 들어가는 방식인데, 설정이 더 어렵고 대개 성능도 좋지 않습니다. 해당 VPN 계정에는 사용자의 결제 기록이 연결되어 있으므로, 방금 전까지 익명이었던 트래픽에 고정된 신원을 부여하는 꼴이 됩니다.
ISP로부터 Tor 사용 사실을 숨기는 것이 목적이라면, 공식적으로 권장하는 방법은 브리지(bridge)를 사용하는 것입니다. 브리지는 공개된 consensus 목록에 포함되지 않은 진입점이며, 여기에 obfs4나 Snowflake 같은 플러그형 전송(pluggable transport)을 결합하면 트래픽을 분류하기 어렵게 만들 수 있습니다. Tor Browser는 이 두 가지를 모두 포함하여 배포하며, 제3의 기업에 사용자의 이름을 제공할 필요도 없습니다.
FAQ
Tor는 단순한 무료 VPN입니까?
아닙니다. VPN은 사용자의 실제 주소와 모든 목적지를 파악할 수 있는 단일 기업이 운영하는 서버 하나를 거쳐 트래픽을 전송하므로, ISP를 사용자가 선택한 제공업체로 교체하는 것에 불과합니다. 반면 Tor는 서로 다른 운영자가 관리하는 3개의 릴레이를 거쳐 트래픽을 전송합니다. 이 과정에서 가드 릴레이는 사용자를 식별할 수 있지만 목적지 사이트를 알 수 없으며, 출구 릴레이는 목적지 사이트를 알 수 있지만 사용자를 식별할 수 없습니다. 또한 Tor는 TCP 전용이며 속도가 눈에 띄게 느리고 많은 웹사이트에서 차단하거나 인증을 요구하므로, VPN의 일상적인 용도를 완벽하게 대체할 수는 없습니다.
ISP가 제가 Tor를 사용 중이라는 사실을 알 수 있습니까?
기본적으로는 알 수 있습니다. 릴레이 주소는 공개된 컨센서스에 게시되므로, ISP는 사용자가 알려진 가드 릴레이에 연결하는 것을 확인할 수 있습니다. 다만 사용자가 어떤 사이트에 접속하는지는 알 수 없습니다. Tor 사용 사실 자체를 숨기려면 Tor Browser에서 제공하는 obfs4나 Snowflake 같은 플러그형 전송(pluggable transport) 브리지를 사용해야 합니다. 이는 공개 목록에 없는 진입점을 통해 연결됩니다. Tor 앞에 VPN을 두면 ISP로부터 Tor 사용 사실을 숨길 수 있지만, 대신 VPN 운영자가 해당 사실을 알게 됩니다.
개인 VPS에서 VPN을 운영하면 익명성이 보장됩니까?
아닙니다. 서버는 사용자의 이름과 신용카드로 임대되므로, 제공업체의 결제 기록이 해당 IP 주소와 사용자를 연결합니다. 제공업체에 요청이 들어오면 이 기록은 즉시 노출됩니다. 또한 해당 주소는 사용자 혼자만 사용하므로, 서버를 유지하는 동안 발생하는 모든 트래픽은 한 사람의 것으로 간주되어 추적 가능합니다. 직접 호스팅하는 VPN은 로컬 네트워크에 대해서는 강력한 개인정보 보호 도구이지만, 제공업체에 정보를 요구할 수 있는 대상에 대해서는 익명성 도구로서의 기능이 매우 약합니다.
Tor를 사용하면 왜 웹사이트가 저를 차단하거나 CAPTCHA를 요구합니까?
출구 릴레이 주소는 공개되어 있으며 매우 많은 사람이 공유하기 때문에, 그중 한 명이라도 악용 사례를 만들면 해당 주소를 사용하는 모든 사용자에게 그 책임이 돌아가기 때문입니다. 콘텐츠 전송 네트워크(CDN)는 이러한 주소의 평판을 낮게 평가하며, 인증 요구, 403 Forbidden, 또는 제출이 거부되는 가입 양식으로 응답합니다. 사용자가 직접 해결할 수 있는 방법은 없습니다. 새로운 회로를 생성하면 다른 출구 릴레이를 할당받게 되며, 때로는 더 나은 평판을 가진 주소를 얻을 수도 있습니다.
VPN을 사용해도 DNS 쿼리가 유출될 수 있습니까?
네, 가능하며 흔히 발생하는 문제입니다. 전체 터널을 구성했더라도 터널 인터페이스에 리졸버가 설정되어 있지 않으면, 클라이언트는 로컬 네트워크에서 학습한 리졸버를 계속 사용합니다. 해당 리졸버로 향하는 경로는 온링크(on-link) 상태이므로 터널의 기본 경로보다 우선순위가 높습니다. 결과적으로 다른 모든 트래픽은 암호화되더라도 DNS 쿼리는 평문으로 전송됩니다. resolvectl status을 실행하여 기본 경로를 담당하는 링크의 DNS 서버가 로컬 라우터가 아닌 터널의 리졸버로 설정되어 있는지 확인하십시오.