개인 블로그나 문서 사이트를 운영하는 실무자라면 도메인, DNS, 인증서 발급이라는 익숙한 삼단 구성이 몸에 배어 있다. 그런데 이 세 가지를 모두 걷어내고도 웹 사이트를 공개할 수 있는 방법이 있다. Tor 네트워크의 히든 서비스(hidden service)를 이용해 .onion 주소로 사이트를 노출하는 방식이다. 한 개발자가 자신의 정적 사이트를 clearnet(일반 인터넷)과 Tor 양쪽에서 동시에 제공하도록 구성한 사례는, 이 방식이 단순한 실험이 아니라 배포 파이프라인에 녹여 넣을 수 있는 실무 구성임을 보여준다.
.onion 주소가 다른 이유
일반 웹 주소와 달리 .onion 주소는 Tor 네트워크 안에서만 해석되며, Tor 브라우저로만 접근할 수 있다. 여기에는 인증 기관(CA)도, DNS도, 외부에 노출된 IP도 없다. 주소 자체가 공개 키에서 직접 파생되고, 연결은 Tor가 자체적으로 종단 간 암호화한다. 즉 우리가 HTTPS를 위해 매번 신경 쓰던 인증서 발급과 갱신, 도메인 등록 절차가 통째로 사라진다. Tor는 트래픽을 전 세계 자원봉사자들이 운영하는 수천 대의 릴레이를 거쳐 중계·암호화하기 때문에, 어느 한 주체도 '누가' '무엇을' 하는지 연결 지을 수 없다. 히든 서비스는 이 익명성을 클라이언트뿐 아니라 서버 쪽까지 확장한다는 점이 핵심이다. 이 기술은 비영리 단체인 Tor Project가 개발하며, 자유 소프트웨어와 개방형 네트워크를 통해 추적·감시·검열로부터 자유로운 인터넷을 지향한다.
서버 구성은 의외로 단순하다
설정 자체는 복잡하지 않다. Tor를 설치한 뒤 /etc/tor/torrc를 편집해 히든 서비스가 로컬 포트를 가리키도록 지정하면 된다. 다만 실무에서 자주 걸려 넘어지는 지점이 있다. 히든 서비스 디렉터리는 반드시 Tor 전용 경로여야 하며, 웹 루트를 그대로 지정해서는 안 된다. Tor는 이 디렉터리에 서비스의 개인 키와 호스트네임 파일을 저장하고, 해당 경로의 소유권을 요구한다(chmod 700, debian-tor 사용자). 만약 사이트 파일이 놓인 경로를 그대로 가리키면 Tor는 아예 기동을 거부한다. 설정 후 Tor를 재시작하면 생성된 .onion 주소를 확인할 수 있다.
웹 서버 쪽 설정은 오히려 더 가볍다. Tor가 onion의 80번 포트를 127.0.0.1:8080으로 포워딩하므로, 웹 서버는 그 로컬 주소만 리슨하면 된다. nginx라면 이를 위한 server 블록을 하나 추가하되 TLS, HTTP/2, QUIC는 모두 빼야 한다. Tor는 평문 TCP로 통신하며 암호화를 스스로 제공하기 때문에, 웹 서버 계층에서 다시 암호화를 얹을 이유가 없다. nginx를 리로드하면 사이트가 Tor 위에서 바로 서비스된다.
정적 사이트 특유의 함정: 절대 경로
정작 까다로운 부분은 서버가 아니라 빌드 결과물에 있다. 정적 사이트 생성기는 보통 절대 링크에 기준 URL(base URL)을 그대로 구워 넣는다. 그래서 clearnet용으로 빌드한 결과물을 Tor로 서비스하면, 방문자가 Tor로 들어왔더라도 링크를 클릭하는 순간 다시 clearnet 도메인으로 튕겨 나가 버린다. 익명성을 지키려고 들어온 사용자를 설정 미스 하나가 노출 경로로 되돌리는 셈이다. 해결책은 onion 주소를 기준 URL로 삼은 두 번째 사본을 별도로 빌드하는 것이다.
이 사례의 배포 파이프라인은 이 작업을 자동화했다. 코드가 푸시될 때마다 clearnet과 Tor 두 타깃에 대해 사이트를 각각 한 번씩 빌드하고, 각 결과물을 자기 웹 루트로 rsync한다. 덕분에 두 버전이 수작업 없이 동기화 상태를 유지한다. 서버 초기 구성과 전체 설정은 저자의 homelab 저장소에, Tor 사본을 빌드·배포하는 GitHub Actions 워크플로는 사이트 자체 저장소에 공개돼 있다.
실무자가 짚어야 할 지점
이 구성이 매력적인 이유는 명확하다. 인증서와 도메인 비용, 갱신 실패 위험이 없고, 서버 IP를 감출 수 있으며, 검열이 심한 환경의 독자에게 도달할 통로가 열린다. 반대로 한계도 분명하다. 접근에 Tor 브라우저가 필요해 일반 방문자 유입은 제한적이고, Tor 경유 특성상 응답 지연이 크며, 캐시나 CDN 같은 통상적인 성능 최적화 기법을 그대로 쓰기 어렵다. 결국 이 방식은 clearnet을 대체한다기보다, 익명 접근이 필요한 독자를 위한 병렬 채널로 두는 편이 현실적이다. 개인 블로그·문서·소규모 자료 사이트처럼 상태가 없는 정적 콘텐츠에 특히 잘 맞으며, 로그인이나 결제처럼 상태를 다루는 서비스라면 익명성 보장과 세션 관리 사이의 상충을 별도로 설계해야 한다.