WebRTC 유출: 실제 IP 주소가 노출되는 방식
VPN이 켜져 있고, 종료 노드는 당신이 취리히에 있다고 알려줍니다. 지갑도 익명으로 느껴집니다. 그런데 브라우저에 내장된 한 가지 기능이 당신의 실제 IP 주소 , 즉 집 주소와 이름이 연결된 주소를 웹사이트에 슬쩍 알려줍니다. 이 기능이 바로 WebRTC이며, 이로 인해 발생하는 허점을 WebRTC 유출이라고 합니다.
대부분의 사람들에게 웹RTC 유출은 개인정보 침해 정도의 불편함일 뿐입니다. 하지만 암호화폐를 보유한 사람들에게는, 어떤 지갑이 어느 집의 소유인지 제3자가 알게 되는 일련의 과정의 첫 번째 고리가 됩니다. 이 가이드에서는 웹RTC 유출이 무엇인지, VPN을 어떻게 우회하는지, 유출 여부를 어떻게 확인하고 모든 브라우저에서 차단하는지, 그리고 브라우저가 지갑에 접근하는 순간 왜 이 문제가 더욱 심각해지는지 자세히 살펴봅니다.
WebRTC 누출이란 무엇이며 왜 발생하는가?
WebRTC는 웹 실시간 통신(Web Real-Time Communication)의 약자입니다. 간단히 말해, 웹 브라우저에서 플러그인 없이 영상 통화, 음성 채팅, 파일 전송을 가능하게 하는 핵심 기술이며, 2011년경부터 모든 주요 브라우저에 기본 탑재되어 있습니다. 여기서 문제가 발생합니다. 두 사람을 직접 연결하려면 양쪽 모두 상대방의 IP 주소를 알아야 합니다. 이는 버그가 아니라, WebRTC의 핵심적인 기능입니다.
문제는 어떤 웹사이트든 이 취약점을 악용할 수 있다는 점입니다. 웹페이지가 백그라운드에서 WebRTC 연결을 열고 사용자의 브라우저가 제공하는 IP 주소를 읽어옵니다. 이때 권한 요청이나 눈에 띄는 표시도 없습니다. VPN 뒤에서라도 실제 주소가 노출되면 WebRTC 정보 유출이 발생합니다. 이는 새로운 기술이 아닙니다. 개발자 다니엘 뢰슬러는 2015년 1월 VPN 사용자의 브라우저에서 실제 IP 주소를 직접 추출하는 작동 증명(proof of concept)을 공개한 바 있습니다 . 10년이 지난 지금도 이 메커니즘은 거의 변하지 않았습니다.
이 공격이 더욱 골치 아픈 이유는 바로 그 은밀함 때문입니다. 팝업창도 없고, 권한 요청 메시지도 없고, 주소 표시줄에도 아무것도 나타나지 않습니다. 일반적인 사용자가 확인할 만한 네트워크 로그에도 요청이 기록되지 않으며, 광고 차단 프로그램도 이를 무시합니다. 브라우저 입장에서는 일반적인 WebRTC 설정으로 인식되어 추적 프로그램으로 간주하지 않기 때문입니다. 따라서 유료 VPN, 안전한 브라우저, 광고 차단 프로그램을 모두 사용하더라도 실제 주소를 요구하는 첫 번째 페이지에 그대로 넘겨줄 수 있습니다. 보이지 않고 일상적인 행위라는 점, 바로 이 때문에 이 정보 유출이 10년 동안이나 지속될 수 있었던 것입니다.
정보 유출의 작동 원리: STUN, NAT 및 IP 주소
VPN이 WebRTC 유출을 자동으로 막아주지 못하는 이유를 이해하려면 브라우저가 내부적으로 실제로 어떤 작업을 수행하는지 살펴보는 것이 도움이 됩니다.
STUN과 ICE, 메커니즘
대부분의 장치는 NAT(네트워크 주소 변환)를 수행하는 라우터 뒤에 있기 때문에 컴퓨터는 자신의 공용 IP 주소를 알지 못합니다. WebRTC는 공용 IP 주소를 찾기 위해 STUN 서버라는 도우미를 사용합니다. 브라우저는 STUN 서버에 간단한 질문을 합니다. "서버가 있는 위치에서 제가 어떤 주소로 접속하는 것으로 보이나요?" 서버는 사용자의 공용 IP 주소를 반환합니다. WebRTC는 ICE 후보라고 불리는 이러한 답변들을 여러 개 수집하여 목록을 만들고, 이를 통해 피어는 적절한 경로를 선택할 수 있습니다. 스누핑 웹사이트는 이 목록을 읽기만 하면 됩니다. 그러면 모든 것이 끝납니다.
왜 그게 중요할까요? STUN 교환 과정 전체가 어떤 웹페이지에서든 실행할 수 있는 자바스크립트로 이루어지기 때문입니다. 카메라나 위치 정보 입력처럼 대화 상자가 나타나지도 않습니다. 스크립트가 피어 연결을 열고, 브라우저가 생성하는 ICE 후보들을 수집하고, 목록에서 주소를 읽어옵니다. 이 모든 과정이 순식간에 이루어지며, 브라우저는 아무런 문제도 발견하지 못합니다. 마치 웹RTC가 설계된 목적대로 작동하는 것처럼 보입니다.
공용 IP와 로컬 IP의 차이점
WebRTC는 두 가지 종류의 주소를 제공하며, 이 주소들은 서로 다른 정보를 전달합니다. 공용 IP 주소는 사용자의 대략적인 위치와 인터넷 서비스 제공업체를 나타냅니다. 로컬 IP 주소(예: 192.168.1.7)는 집이나 사무실 내부의 네트워크를 나타냅니다. 이 두 주소 모두 임의의 웹사이트가 사용할 수 있는 것은 아닙니다. 하지만 공용 IP 주소는 실제 세계, 즉 도시, 서비스 제공업체, 그리고 궁극적으로는 특정 장소의 위치를 나타내기 때문에 주의해야 합니다.
VPN이 이를 막지 못하는 이유
VPN은 일반 트래픽을 우회합니다. 문제는 STUN 요청이 이 터널을 빠져나와 STUN 서버에 직접 도달한 후 실제 공용 IP 주소를 가지고 돌아올 수 있다는 것입니다. 브라우저는 2019년과 2020년에 이 문제를 부분적으로 해결하기 위해 로컬 IP 주소를 암호화된 mDNS 호스트 이름으로 바꾸는 패치를 적용했습니다. 이는 도움이 되지만, 로컬 IP 주소만 숨길 뿐입니다. STUN을 통해 전달되는 공용 IP 주소는 여전히 노출될 수 있습니다. 더 심각한 문제는 웹사이트가 마이크나 카메라 접근 권한을 요청하는 순간 IP 주소 마스킹이 해제되는 경우가 많다는 것입니다. 따라서 대부분의 사용자가 안전하다고 생각하는 바로 그곳에서 정보 유출이 발생합니다.
WebRTC 누출 테스트를 제대로 실행하는 방법
확인하는 데 약 1분 정도 소요되며, 다른 사람의 말을 그대로 믿을 필요는 없습니다.
VPN을 끄고 연결된 공용 IP 주소를 기록해 두세요. 이제 VPN을 켜고 WebRTC 유출 테스트 페이지(예: browserleaks.com/webrtc 또는 ipleak.net)를 엽니다. 결과를 비교해 보세요. VPN이 제대로 작동하고 IP 주소 유출이 없다면 VPN 주소만 표시될 것입니다. 만약 1단계에서 기록해 둔 IP 주소가 페이지 어디에든 나타난다면, 유출 지점을 찾은 것입니다. 브라우저에서 노출되는 모든 정보를 더 자세히 확인하려면, BrowserLeaks 가이드에 설명된 더 광범위한 검사에도 동일한 논리를 적용할 수 있습니다.
WebRTC 유출 여부를 확인할 때 몇 가지 혼동되는 부분이 있습니다. 로컬 IP 주소가 .local로 끝나는 알아보기 힘든 문자열처럼 보일 수 있습니다. 당황하지 마세요. 이는 mDNS 마스킹이 작동하는 것일 뿐 유출이 아닙니다. 중요한 주소는 공용 IP 주소입니다. 민감한 정보를 저장하는 데 사용하는 것과 동일한 브라우저와 프로필에서 테스트하세요. 설정과 확장 프로그램은 브라우저와 프로필에 따라 적용되지 않습니다. 또한 브라우저 업데이트 후에는 패치로 인해 설정이 조용히 이전 상태로 돌아갈 수 있으므로 매번 다시 테스트해야 합니다.
어떤 브라우저가 IP 주소를 유출하고, 어떤 브라우저는 유출하지 않는지 알아보세요.
모든 브라우저가 WebRTC 누출을 처리하는 방식이 동일하지는 않으며, 시장 분할 방식 때문에 이러한 차이점은 중요합니다.
| 브라우저 | WebRTC 유출 위험 | 내장형 보호 기능 |
|---|---|---|
| 크롬 | 높은 | 기본 기능이 아니므로 확장 프로그램이 필요합니다. |
| 파이어폭스 | 중상 | 기본적으로 공용 IP 주소가 노출되지만, 쉽게 비활성화할 수 있습니다. |
| 용감한 | 낮은 | 지문 및 WebRTC 보호 기능이 기본적으로 활성화되어 있습니다. |
| Tor 브라우저 | 없음 | RTCPeerConnection이 완전히 비활성화되었습니다. |
크롬은 그 압도적인 점유율 때문에 문제의 핵심에 놓여 있습니다. 2026년 5월 기준으로 전 세계 브라우저 시장의 약 70%를 차지하고 있지만, WebRTC를 통해 사용자의 IP 주소를 노출하지 않도록 하는 기본 설정 옵션이 없습니다. 약 2%의 점유율을 보이는 파이어폭스 역시 기본적으로 공용 IP 주소를 노출하지만, 적어도 설정에서 이 기능을 끌 수 있다는 점은 다행입니다. 브레이브는 그나마 희망적인 존재입니다. 2025년 9월 월간 활성 사용자 수가 1억 100만 명을 돌파했으며, WebRTC 보호 기능을 기본적으로 활성화하는 유일한 주류 크로미움 브라우저입니다. 그렇다면 토르는 어떨까요? 토르는 피어 연결을 완전히 차단함으로써 이 문제를 회피하는데, 바로 이 점 때문에 개인정보 보호 연구자들이 신규 사용자들에게 토르를 추천하는 것입니다.
WebRTC를 비활성화하고 정보 유출을 방지하는 방법
이를 차단하는 방법은 두 가지입니다. WebRTC를 완전히 비활성화하거나, 사용자가 지정한 주소만 사용하도록 제한하는 것입니다. 어떤 방법을 선택할지는 브라우저에서 화상 통화를 실제로 사용하는지 여부에 따라 다릅니다. 다음은 브라우저별로 실용적인 방법을 설명합니다.
| 브라우저 | 비활성화 또는 제한 방법 | 효과 |
|---|---|---|
| 파이어폭스 | about:config에서 media.peerconnection.enabled를 false로 설정하세요. | 완전 비활성화 |
| 크롬 | WebRTC Network Limiter 또는 WebRTC Control을 설치하세요. | 노출을 제한합니다 |
| 가장자리 | edge://flags에서 "로컬 IP 익명화"를 활성화하세요. | 부분적 |
| 원정 여행 | 메뉴 개발, 실험적 기능, WebRTC 제한 | 부분적 |
크롬 및 엣지
크롬은 좀 애매한 브라우저입니다. 메뉴에 WebRTC 차단 옵션이 따로 없어서 확장 프로그램을 사용해야 합니다. 구글은 자체 확장 프로그램인 WebRTC Network Limiter를 제공하는데, 이는 통화를 차단하지 않고 위험한 IP 주소만 차단합니다. 더 강력한 방법을 원한다면 WebRTC Control을 사용하면 클릭 한 번으로 WebRTC를 완전히 끌 수 있습니다. 마이크로소프트 엣지도 같은 크로뮴 엔진을 사용하기 때문에 이러한 확장 프로그램이 엣지에서도 작동하지만, 엣지 주소(edge://flags)에서 로컬 IP 주소를 익명화하는 편리한 기능도 제공합니다.
파이어폭스
Firefox에서는 간단하게 설정할 수 있습니다. 주소창에 about:config를 입력하고, 경고 메시지를 무시한 다음 media.peerconnection.enabled를 찾아 값을 false로 변경하면 됩니다. 이렇게 하면 WebRTC가 비활성화됩니다. 단, 주의할 점은 WebRTC를 다시 활성화하기 전까지 브라우저 내 영상 및 음성 통화가 불가능하다는 것입니다.
사파리와 오페라
Safari는 기본적으로 더 안전한 방식을 사용하며, 개발자 메뉴의 실험적 기능에서 WebRTC 보안을 더욱 강화할 수 있습니다. Opera는 Chromium 기반이므로 Chrome에서 작동하는 확장 프로그램을 그대로 사용할 수 있습니다.
VPN 사용과 그에 따른 장단점
그다음은 VPN을 사용하는 방법입니다. 진정한 정보 유출 방지 기능을 갖춘 VPN을 사용하면 WebRTC 트래픽이 VPN 자체 터널을 통해 전송되므로 STUN 서버는 VPN 주소만 보게 됩니다. 통화가 계속 유지되고 신뢰할 수 있는 프록시 서버를 사용하면 IP 유출을 방지할 수 있으므로 가장 깔끔한 방법입니다. 하지만 문제는 신뢰입니다. 모든 VPN이 실제로 이러한 기능을 제공하는 것은 아닙니다. VoidSec이 2018년에 70개의 VPN 제공업체를 테스트했을 때 16개 업체(약 23%)에서 WebRTC를 통해 실제 IP 주소가 유출되었습니다. 우수한 업체들은 이후 이 문제를 해결했지만, 중요한 교훈은 여전히 유효합니다. 테스트하고, 섣불리 판단하지 마십시오. 더 확실한 방법을 원한다면 WebRTC를 아예 비활성화하는 방법이 있습니다. 하지만 WebRTC에 의존하는 모든 기능이 제대로 작동하지 않게 된다는 점을 명심해야 합니다.
WebRTC 유출이 암호화폐 보유자에게 위협이 되는 이유는 무엇일까요?
암호화폐 사용자에게 노출된 IP 주소는 단순한 개인정보 보호 문제가 아닙니다. 그것은 온체인상의 삶과 현실 세계를 가르는 경계선입니다. 그리고 최근 들어 그 경계선이 위험해지고 있습니다.
IP-to-wallet 킬 체인
블록체인 주소는 익명성이 아닌 가명입니다. 여러분이 지금까지 했던 모든 거래 내역은 공개적으로 확인할 수 있습니다. 거래 내역이 여러분을 직접적으로 가리키지 않는 유일한 이유는 이름이나 위치와 같은 식별 정보가 없기 때문입니다. IP 주소가 바로 그 식별 정보입니다. 그리고 연구자들은 10년도 더 전에 이러한 연결이 실제로 가능하다는 것을 증명했습니다. 2014년 연구 에서 알렉산드르 비류코프와 그의 동료들은 몇몇 잘 배치된 노드를 이용하여 비트코인 가명을 해당 거래를 처음 전송한 IP 주소와 연결했습니다. 웹RTC 유출은 공격자에게 이와 동일한 연결 고리를 무료로 제공합니다. 실제 IP 주소가 노출된 상태에서 블록 탐색기나 탈중앙화 거래소(DEX)를 열면, 단 한 페이지에서 여러분이 보고 있는 지갑을 여러분의 집과 인터넷 서비스 제공업체에 연결할 수 있습니다.
게다가 위험은 더욱 커집니다. 해킹은 거래 도중에 발생할 필요가 없습니다. 잔액을 확인하거나 마켓플레이스를 둘러보는 동안 악성 스크립트가 실행되는 페이지에서 단 한 번만 해킹이 발생해도 됩니다. 그 후에는 어떻게 될까요? 해당 IP 주소는 ISP 기록, 데이터 브로커 프로필, 과거 해킹 사례와 대조됩니다. 결국에는 특정 IP 주소가 드러나게 됩니다. 이 지갑은 처음부터 공개되어 있었고, 해킹으로 인해 그 사실이 밝혀진 것뿐입니다.
익명성 해제부터 문을 두드리는 소리까지
과거에는 막연한 걱정거리였지만, 이제는 그렇지 않습니다. 업계 통계에 따르면 , 키 보유자를 강탈하거나 납치하여 키를 탈취하는 이른바 '렌치 공격'이 2025년에 약 75% 증가했으며, 72건의 사건이 확인되어 최소 4,100만 달러의 피해가 발생했습니다. 공격 패턴은 거의 변하지 않습니다. 공격자는 공개된 온체인 자산과 오프체인 신원을 연결하여 실제 인물을 실제 주소에 등록합니다. IP 주소는 이러한 신원 정보를 확보하는 가장 확실한 방법 중 하나입니다.
관점을 바꿔 공격자의 입장에서 생각해 보세요. 그들은 이미 어떤 지갑에 실제 돈이 들어 있는지 알 수 있습니다. 그 부분은 공개되어 있으니까요. 하지만 그들에게 부족한 것은 큰 주소에서 실제 현금이 있는 곳까지의 경로입니다. IP 주소는 검색 범위를 인터넷 전체에서 도시, ISP, 심지어는 특정 지역으로 좁혀줍니다. 나머지는 일반적인 조사 작업입니다. 일반 사용자에게는 이런 정보 유출이 대수롭지 않게 여겨질 수 있습니다. 하지만 수백만 달러 상당의 자산을 보유한 사람에게는 익명과 표적 사이의 경계선이 됩니다. 바로 이 차이 때문에 암호화폐 사용자들은 웹RTC 정보 유출을 온라인 개인정보 보호 문제가 아닌 보안 문제로 인식해야 합니다.
귀하의 IP 주소는 개인 정보입니다.
법적인 측면도 있습니다. 2016년 유럽사법재판소는 브레이어 사건에서 누군가가 합리적으로 이를 이용해 사용자를 재식별할 수 있다면 동적 IP 주소조차도 개인 데이터에 해당한다고 판결했습니다. 이 논리에 따르면, 웹RTC를 통해 사용자의 IP 주소를 몰래 수집하는 웹사이트는 동의 없이 개인 데이터를 처리하는 것입니다. 물론 이 판결이 정보 유출을 완전히 막지는 못하지만, 규제 당국이 브라우저가 무료로 제공하는 정보를 얼마나 심각하게 받아들이는지 보여줍니다.
누수가 발생하기 전에 막으세요
WebRTC 유출은 조용히 발생하며, 허가를 요구하지도 않습니다. VPN만으로는 이러한 유출을 막을 수 없습니다. 따라서 보안을 강화해야 합니다. 기본적으로 WebRTC 보호 기능을 제공하는 브라우저를 선택하거나, 해당 기능이 없는 경우 WebRTC를 비활성화하세요. IP 주소 유출 테스트를 통과하여 IP 주소를 숨겨주는 VPN을 사용하고, 업데이트 후에는 반드시 다시 확인하세요. 자금을 이체하는 사람이라면 목표는 명확합니다. 지갑과 IP 주소 간의 연결이 애초에 형성되지 않도록 해야 합니다. 일단 연결이 형성되면 되돌릴 수 없기 때문입니다. 그렇다면 여러분은 마지막으로 언제 브라우저에서 실제로 어떤 정보가 유출되는지 테스트해 보셨나요?
