Tor와 VPN 차이점: 나에게 필요한 보안 도구는?
Tor와 VPN은 트래픽을 처리하는 방식과 정보 보호 범위가 다릅니다. ISP와 웹사이트 운영자 등 각 주체가 사용자의 어떤 정보를 확인할 수 있는지 상세히 분석합니다. 본인의 익명성 요구 수준에 맞는 최적의 도구를 선택하는 방법을 확인하십시오.
Tor와 VPN: 실제로 무엇이 필요한가
Tor와 VPN은 모두 사용자의 트래픽을 본인의 것이 아닌 다른 기기를 거쳐 전송하지만, 해결하는 문제는 서로 다릅니다. VPN(Virtual Private Network)은 인터넷 서비스 제공업체(ISP)에 대한 신뢰를 특정 기업으로 옮기는 방식이며, 해당 기업은 사용자의 실제 IP 주소와 방문하는 모든 목적지를 파악할 수 있습니다. 반면 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개의 릴레이로 회로를 구성합니다. 클라이언트는 릴레이당 하나씩, 데이터를 여러 겹으로 암호화합니다. 각 릴레이는 한 겹의 암호화를 제거하고 다음 홉(hop) 정보만 확인한 뒤 나머지를 전달합니다. 이러한 계층 구조 덕분에 경로상의 누구도 출발지와 목적지 정보를 동시에 알 수 없습니다.
- 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 출구 노드는 웹 전반에서 차단되거나 CAPTCHA를 요구받는 경우가 많습니다.
위 목록은 구독형 서비스를 구매하는 대신 VPS에서 직접 VPN을 운영해야 하는 이유를 설명하며, 직접 구축한 WireGuard 서버는 사용자가 소유한 설정 파일에 따라 로깅 정책이 결정되는 터널을 제공합니다. 기기 간 키 관리 기능이 포함된 동일한 터널을 원한다면 일반 WireGuard와 Tailscale의 차이점을 비교해 보아야 합니다. 일단 tailnet에 연결되면 자신의 서비스에 접근하는 것과 그중 하나를 공개 인터넷에 게시하는 것은 별개의 결정 사항이며, serve는 서비스를 tailnet 내부에 비공개로 유지하고 funnel은 이를 외부로 노출합니다. 이 도구들은 각각 위 목록의 작업을 수행하는 데 탁월하지만, 다음 목록의 작업에는 적합하지 않습니다.
Tor가 적합한 도구인 경우
- 공격자가 목적지 사이트이거나, 단일 기업에 기록 제출을 요구할 수 있는 주체인 경우.
- 추적되었을 때 본인에게 해가 될 수 있는 내용을 읽거나 게시하는 경우.
- onion 서비스를 원하는 경우: 트래픽이 네트워크를 벗어나지 않고, exit relay를 거치지 않으며, 서버 주소가 숨겨진 상태로 유지됩니다.
- 느린 페이지 로딩, CAPTCHA, 간헐적인
403 Forbidden를 감수할 수 있는 경우.
세 번째 항목의 서버 측 운영에 관심이 있다면, VPS에서 v3 onion 서비스 운영하기를 통해 경로상에 exit relay 없이 사이트에 접속하는 방법과, 여전히 기기를 공용 주소와 연결할 수 있는 일반적인 정보 유출 경로를 확인할 수 있습니다.
포트 9050을 가리키는 일상적인 브라우저 대신 Tor Browser를 사용하십시오. 브라우저는 보호 기능의 절반을 담당하며, 다음 다음 섹션에서 그 이유를 설명합니다.
임대한 VPS가 익명성 측면에서 상용 VPN보다 불리한 이유
많은 사람이 이 부분을 반대로 생각합니다. 임대한 VPS는 귀하의 이름이 명시된 계약입니다. 가입 시 사용한 이메일, 결제 카드, 청구서, 고객 지원 티켓 등 모든 정보가 해당 IP 주소와 함께 한 회사의 데이터베이스에 저장됩니다. 누군가 귀하와 해당 주소를 연결하기 위해 시스템을 해킹할 필요가 없습니다. 이미 일반적인 회계 목적으로 기록되어 보관 중이며, 법적 효력이 있는 질문을 할 수 있는 기관이라면 누구든 이 정보에 접근할 수 있습니다.
두 번째 문제는 사용자 군집입니다. 상용 VPN의 출구 주소는 수많은 고객이 동시에 공유하므로, 해당 주소만으로는 특정 개인을 지목할 수 없습니다. 반면 VPS 주소는 오직 귀하만이 사용합니다. 해당 주소에서 발생하는 모든 요청은 오늘이든 다음 달이든 귀하의 활동이며, 주소가 바뀌지 않기 때문에 목적지 서버는 쿠키 없이도 수개월에 걸쳐 귀하의 프로필을 구축할 수 있습니다.
그렇다고 해서 직접 호스팅하는 VPN이 나쁘다는 의미는 아닙니다. 신뢰할 수 없는 네트워크에서 트래픽을 암호화하거나 어디서든 자신의 서비스에 접속하는 용도로는 매우 훌륭합니다. 다만 익명성을 위한 도구는 아니며, 이를 익명성 도구로 사용하는 것이 오류입니다. VPS 제공업체가 서버 내부에서 무엇을 볼 수 있고 무엇을 볼 수 없는지에 대한 명확한 설명은 VPS 호스팅의 실제 안전성에서 확인하십시오.
Tor와 VPN으로 해결할 수 없는 문제
- 브라우저 핑거프린팅. 사용자 에이전트, 화면 크기, 시간대, 설치된 글꼴, 언어, 캔버스 렌더링 정보가 결합하면 고유한 식별 값이 생성되며, 이는 사용하는 IP 주소가 바뀌어도 계속 따라다닙니다. Tor Browser는 모든 사용자의 환경을 동일하게 보이게 하고 창 크기를 고정된 단계로 조절하여 이에 대응합니다. SOCKS 프록시를 사용하는 일반 브라우저는 기존의 핑거프린트와 쿠키를 그대로 유지합니다.
- 로그인. 본인의 이름이 알려진 계정에 로그인하는 순간, 네트워크 계층의 익명성은 의미가 없어집니다. 집에서 한 번, Tor를 통해 한 번 동일한 계정에 로그인하면 두 세션은 서로 연결됩니다.
- 엔드포인트가 기록하는 모든 정보: 입력한 내용, 구매 내역, 검색어 등은 보호되지 않습니다.
- 종단 간 상관관계 분석. 사용자의 회선과 출구 노드를 동시에 감시하는 공격자는 패킷의 타이밍과 전송량을 대조하여 양쪽 끝을 연결할 수 있습니다. Tor는 양쪽을 모두 볼 수 있는 공격자에 대해서는 방어할 수 없음을 명시하고 있습니다.
Tor와 VPN을 함께 사용할 수 있습니까?
Tor over VPN은 VPN에 먼저 연결한 뒤 그 안에서 Tor를 실행하는 방식입니다. 이 경우 ISP는 VPN 연결만 확인할 수 있고, Tor의 가드 릴레이는 사용자의 실제 IP 대신 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를 사용 중이라는 사실을 알 수 있나요?
기본적으로는 알 수 있습니다. 릴레이 주소는 공개된 consensus에 게시되므로, ISP는 사용자가 알려진 가드 릴레이에 연결하고 있음을 확인할 수 있습니다. 다만 사용자가 어떤 사이트에 접속하는지는 알 수 없습니다. Tor 사용 사실 자체를 숨기려면 Tor Browser에서 제공하는 obfs4나 Snowflake 같은 pluggable transport가 적용된 브릿지를 사용해야 합니다. 이는 공개 목록에 없는 진입점을 통해 연결됩니다. Tor 앞에 VPN을 배치하면 ISP로부터 Tor 사용 사실을 숨길 수 있지만, 대신 VPN 운영자가 해당 사실을 알게 됩니다.
개인 VPS에서 VPN을 운영하면 익명성이 보장되나요?
아닙니다. 서버는 사용자의 이름과 신용카드로 임대되므로, 제공업체의 결제 기록이 해당 주소와 사용자를 연결합니다. 제공업체에 대한 요청만으로도 이 기록을 확인할 수 있습니다. 또한 해당 주소는 사용자 혼자만 사용하므로, 서버를 유지하는 동안 발생하는 모든 트래픽은 한 사람의 것으로 간주되어 추적 가능합니다. 직접 호스팅하는 VPN은 로컬 네트워크에 대해서는 강력한 개인정보 보호 도구이지만, 제공업체에 정보를 요구할 수 있는 대상에 대해서는 익명성 도구로서의 기능이 약합니다.
Tor를 사용하면 왜 웹사이트가 차단되거나 CAPTCHA를 요구하나요?
엑시트 릴레이 주소는 공개되어 있으며 매우 많은 사람이 공유하기 때문에, 그중 한 명이라도 악용 사례를 만들면 해당 주소를 사용하는 모든 사용자에게 그 책임이 돌아갑니다. 콘텐츠 전송 네트워크(CDN)는 이러한 주소의 평판을 낮게 평가하며, 검증 요청, 403 Forbidden, 또는 제출이 거부되는 가입 양식으로 응답합니다. 사용자 측에서 이를 해결할 방법은 없습니다. 새로운 회로를 생성하여 다른 엑시트 릴레이를 할당받으면 평판이 더 나은 주소를 얻을 수도 있습니다.
VPN을 사용해도 DNS 쿼리가 유출될 수 있나요?
네, 가능하며 흔히 발생하는 문제입니다. 전체 터널을 구성했더라도 터널 인터페이스에 리졸버가 설정되지 않으면, 클라이언트는 로컬 네트워크에서 학습한 리졸버를 계속 사용합니다. 해당 리졸버로 향하는 경로는 on-link 상태이므로 터널의 기본 경로보다 우선순위가 높습니다. 결과적으로 다른 모든 트래픽은 암호화되더라도 DNS 쿼리는 평문으로 전송됩니다. resolvectl status을 실행하여 기본 경로를 담당하는 링크의 DNS 서버가 로컬 라우터가 아닌 터널의 리졸버로 설정되어 있는지 확인하십시오.