WebRTC 누수란? 테스트 방법과 해결 가이드 (2026)

Share this guide

ShareCopy linkShare on FacebookShare on XShare on LinkedInPin on PinterestShare on WhatsAppShare by email

VPN을 켜고 초록색 "연결됨" 표시가 뜨면, 우리는 보통 실제 IP가 숨겨졌다고 믿습니다. 하지만 그렇지 않은 경우가 많습니다. WebRTC 누수는 모든 최신 브라우저에 존재하는 은밀한 우회 경로로, 묻기만 하면 어떤 웹사이트든 ISP가 부여한 실제 IP — 때로는 로컬 네트워크 주소까지 — 를 알아낼 수 있게 합니다. 이 일은 VPN 터널과 무관하게 일어나기 때문에 많은 사람이 방심하다 당하게 됩니다.

이 가이드에서는 WebRTC 누수가 실제로 무엇인지, 1분 안에 누수를 테스트하는 방법, 그리고 2026년 기준 크롬, 파이어폭스, 브레이브, 사파리에서의 정확한 해결책을 설명합니다. 또한 매일 누수로 오해받지만 사실은 누수가 아닌 두 가지, 즉 .local mDNS 주소와 최신 브라우저의 로컬 LAN IP에 대해서도 알아봅니다.

WebRTC 누수란 무엇인가?

WebRTC(Web Real-Time Communication)는 플러그인 없이 브라우저 안에서 직접 영상 통화, 음성 채팅, 화면 공유, 개인 간(P2P) 파일 전송을 가능하게 하는 브라우저 API입니다. Google Meet, 디스코드 웹, WhatsApp 웹 통화, 브라우저 줌, 그리고 대부분의 고객 지원 채팅 위젯이 이 기술을 사용합니다.

P2P 연결을 맺으려면 WebRTC는 사용자의 IP 주소를 알아내야 합니다. 이를 위해 STUN 서버 — 접속자가 어떤 IP로 들어오는지 알려 주는 공개 인터넷 서버 — 에 질의합니다. 함정은 여기에 있습니다. 이 STUN 질의는 UDP로 나가며, 기본적으로 브라우저에 설정된 SOCKS나 HTTP 프록시를 우회합니다. 즉, VPN 터널이 지켜 주고 있다고 생각하는 와중에도 STUN 응답이 실제 공용 IP를 노출할 수 있다는 뜻입니다.

WebRTC 누수는 웹사이트가 몇 줄짜리 WebRTC 자바스크립트를 실행해 브라우저가 알아낸 IP를 수집한 뒤 자기 서버로 되돌려 보낼 때 발생합니다. 권한 요청 창은 뜨지 않습니다. 아무런 경고도 없습니다. 익명이라고 믿는 사이에 사이트는 그냥 실제 IP를 알아냅니다.

WebRTC 누수는 어떻게 테스트하나?

WebRTC 누수 테스트는 약 30초면 끝납니다. 설치할 소프트웨어도 없습니다. 테스트는 브라우저 안에서 실행되며 악의적인 사이트가 사용할 바로 그 WebRTC API를 그대로 씁니다 — 따라서 테스트가 보는 것이 곧 어떤 웹사이트든 볼 수 있는 것입니다.

이 사이트의 무료 WebRTC 누수 테스트를 사용하세요. 절차는 다음과 같습니다.

1. 먼저 VPN에 연결하세요. VPN 대시보드에 선택한 국가와 서버가 표시되는지 확인합니다.
2. 평소 쓰는 바로 그 브라우저에서 WebRTC 누수 테스트 페이지를 엽니다.
3. 스캔 시작을 클릭하세요. 페이지가 구글의 공개 STUN 서버에 질의해 브라우저가 반환하는 모든 IP를 나열합니다.
4. 공용 IP 항목을 VPN 대시보드와 비교하세요. 모두 실제 ISP IP가 아니라 VPN의 출구 IP와 일치해야 합니다.
5. VPN을 끊은 상태로 테스트를 한 번 더 하세요. 이는 기준값이 됩니다 — 보호받지 않을 때 WebRTC가 노출하는 IP들입니다.

사용하는 모든 브라우저에서 테스트를 돌리세요. 크롬에서 통과한 VPN이 파이어폭스에서는 누수될 수 있습니다. 두 브라우저가 WebRTC를 조금 다르게 구현하기 때문입니다. 모바일에서도 돌려 보세요 — WebRTC는 안드로이드 크롬과 iOS 사파리에서도 똑같이 작동합니다.

VPN을 켜도 WebRTC가 내 IP를 흘리는 이유

짧게 답하면 이렇습니다. WebRTC는 STUN 요청을 순수 UDP로 보내는데, 많은 VPN 클라이언트는 브라우저가 시작한 TCP/HTTP 트래픽만 터널로 보냅니다. UDP STUN 패킷은 물리적 네트워크 인터페이스로 나가 구글의 STUN 서버에 닿고, STUN 응답은 실제 IP를 그대로 실어 돌아옵니다 — 그 서버 입장에서는 요청이 실제 IP에서 온 것이기 때문입니다.

VPN이 누수되는지 여부는 다음 세 가지에 달려 있습니다.

• VPN 클라이언트가 UDP를 터널로 보내는가? 저렴하거나 무료인 VPN은 비용을 줄이려고 UDP 라우팅을 건너뛰는 경우가 많습니다. TCP 형태는 다 터널을 거치지만 UDP STUN 패킷은 그렇지 않습니다.
• IPv6를 처리하는가? 상당수 VPN이 IPv4만 터널링합니다. ISP가 IPv6를 제공한다면 v6 주소는 터널을 통째로 우회합니다. 이것이 "VPN을 켰는데도 실제 IP가 새어 나간다"는 문제의 1순위 원인입니다.
• 커널 방화벽 레벨에서 프록시를 거치지 않는 UDP를 차단하는가? 보안에 철저한 곳은 그렇게 합니다(Mullvad, ProtonVPN, NordVPN). 터널을 빠져나가는 것은 아예 기기 밖으로 나가지조차 못합니다.

WebRTC 누수 보호에 좋은 VPN

2026년 각 업체가 공식 문서로 밝힌 WebRTC 처리 방식을 기준으로, 별도 설정 없이도 누수 테스트를 꾸준히 통과하는 VPN은 다음과 같습니다.

• Mullvad — 방화벽 레벨에서 프록시를 거치지 않는 UDP를 차단합니다. 명시적으로 허용하지 않는 한 아무것도 빠져나가지 못합니다.
• ProtonVPN — IPv6를 네이티브로 처리하거나(서버가 지원하지 않으면 깔끔하게 차단), 기본적으로 UDP를 터널링합니다.
• NordVPN — 킬 스위치 동작의 일부로 WebRTC 누수를 명시적으로 테스트합니다.
• ExpressVPN — "네트워크 락" 킬 스위치로 WebRTC STUN을 포함해 터널을 빠져나갈 모든 트래픽을 차단합니다.

무료 VPN, 브라우저 VPN 확장 프로그램, 그리고 백신에 끼워 파는 VPN 대부분은 WebRTC에서 신뢰하기 어렵습니다. 마케팅을 믿지 말고 WebRTC 누수 테스트로 본인의 환경을 직접 확인하세요.

크롬(과 엣지)에서 WebRTC 누수 막기

2026년에도 크롬에는 WebRTC를 끄는 자체 토글이 없습니다. 구글은 오래전에 옛 chrome://flags 옵션을 제거했습니다. 그래서 실질적인 해결책은 세 가지가 남습니다.

방법 1: 구글 공식 WebRTC Network Limiter 설치

구글은 크롬 웹 스토어에 WebRTC Network Limiter라는 공식 크롬 확장 프로그램을 제공합니다. 이것은 WebRTC를 완전히 끄지는 않고, 프록시를 거치는 UDP만 사용하고 기본이 아닌 경로에는 연결하지 말라고 크롬에 지시합니다. 실제로는 영상 통화 기능을 유지하면서 대부분의 누수를 막아 줍니다.

1. 크롬 웹 스토어에서 WebRTC Network Limiter 페이지를 엽니다.
2. Chrome에 추가를 클릭하세요. 별도 설정 없이 즉시 적용됩니다.
3. WebRTC 누수 테스트로 다시 확인하세요.

방법 2: uBlock Origin의 WebRTC 설정 사용

이미 uBlock Origin을 쓰고 있다면, 영상 통화를 막지 않으면서 로컬 IP WebRTC 누수를 차단하는 내장 토글이 있습니다.

1. 도구 모음에서 uBlock Origin 아이콘을 클릭한 뒤 톱니바퀴 아이콘을 눌러 대시보드를 엽니다.
2. 설정 탭(버전에 따라 개인정보라고도 함)으로 이동합니다.
3. WebRTC가 로컬 IP 주소를 누수하지 못하도록 방지를 켭니다.
4. 변경 사항 적용을 클릭합니다.

방법 3: 누수 차단이 내장된 VPN으로 전환

가장 깔끔한 해결책은 커널 레벨입니다. 어떤 UDP 패킷도 터널 밖으로 보내지 않는 VPN을 쓰는 것이죠. 이러면 STUN 질의가 애초에 구글 서버에 도달하지 못하므로 새어 나갈 것 자체가 없습니다. Mullvad, NordVPN, ProtonVPN은 모두 킬 스위치를 켜면 이렇게 동작합니다.

똑같은 세 가지 방법이 마이크로소프트 엣지에서도 통합니다 — 엣지는 크로미움 기반이라 확장 프로그램 생태계와 동작이 동일합니다.

파이어폭스에서 WebRTC 누수 막기 (about:config)

파이어폭스는 확장 프로그램 없이 설정 하나로 WebRTC를 완전히 끌 수 있는 유일한 주요 브라우저입니다.

WebRTC 누수 테스트로 다시 확인하세요 — 모든 항목이 이제 "WebRTC 비활성화됨"으로 표시되거나 IP를 반환하지 않아야 합니다.

브레이브에서 WebRTC 누수 막기

브레이브는 설정 UI에 WebRTC 누수 토글을 기본 내장한 유일한 주요 브라우저입니다. 확장 프로그램이나 about:config 꼼수가 필요 없습니다.

1. 새 탭을 열고 brave://settings/privacy로 이동합니다.
2. WebRTC IP 처리 정책까지 스크롤합니다.
3. 드롭다운을 프록시를 거치지 않는 UDP 비활성화로 바꿉니다.
4. 브레이브를 닫았다 다시 연 뒤 WebRTC 누수 테스트로 확인하세요.

"프록시를 거치지 않는 UDP 비활성화"는 가장 이상적인 절충점입니다. VPN 프록시를 거치는 통화에는 WebRTC가 계속 작동하지만, 직접(프록시를 거치지 않는) UDP 연결로는 STUN 질의를 보내기를 거부합니다. 누수도 없고 통화도 정상입니다.

사파리에서 WebRTC 누수 막기 (macOS + iOS)

사파리의 WebRTC 동작은 기본적으로 더 엄격합니다 — 로컬 IP는 기본으로 숨겨지고 공용 IP는 시스템에 설정된 프록시를 거칩니다. 다만 한 단계 더 통제하고 싶다면 다음과 같이 하세요.

macOS의 사파리

1. 사파리를 열고 사파리 → 설정 → 고급을 클릭합니다.
2. 맨 아래의 웹 개발자용 기능 보기를 체크합니다.
3. 새로운 기능 플래그(또는 "개발자용" 메뉴 항목)가 나타납니다.
4. 이를 열어 WebRTC가 포함된 항목을 검색합니다.
5. 더 강하게 잠그고 싶다면 mDNS ICE 후보나 구형 WebRTC API와 관련된 항목을 비활성화하세요. 단, 이 플래그는 사파리 버전마다 달라집니다. 사파리 17 이상의 기본값은 이미 대부분의 사용자에게 충분히 개인정보를 존중합니다.

iOS / iPadOS의 사파리

1. iOS 설정 앱을 열고 Safari까지 스크롤합니다.
2. 고급 → 실험적 기능까지 내려갑니다.
3. WebRTC 항목을 찾아 특정 동작을 끄고 싶다면 토글을 비활성화합니다.

iOS에서는 VPN 자체가 가장 큰 역할을 합니다. 데스크톱 VPN과 달리 iOS는 VPN이 연결되면 모든 트래픽(UDP 포함)을 설정된 VPN 프로필로 강제로 보냅니다 — 그래서 iOS의 VPN 누수는 데스크톱보다 드물지만, 그렇다고 불가능한 것은 아닙니다.

WebRTC를 완전히 꺼야 할까?

대개는 아닙니다. WebRTC를 완전히 끄는 것은 무딘 도구입니다 — 누수는 막지만 브라우저 안의 WebRTC 의존 앱도 전부 함께 멈추게 됩니다.

WebRTC를 끄면 멈추는 것	그래도 작동하는 것
Google Meet (브라우저)	Google Meet (설치형 앱)
브라우저 디스코드 — 음성과 영상	디스코드 데스크톱 앱
WhatsApp 웹 음성/영상 통화	WhatsApp 웹 메시지(통화 제외)
브라우저 마이크로소프트 팀즈	마이크로소프트 팀즈 데스크톱 앱
줌 웹 클라이언트	줌 설치형 앱
Jitsi Meet, Whereby 등 대부분의 브라우저 통화 도구	네이티브 앱 경로를 쓰는 모든 도구
브라우저 내 화면 공유	설치형 앱의 화면 공유

대부분의 사람에게 올바른 선택은 완전한 비활성화가 아닙니다 — 네트워크 계층에서 WebRTC 누수를 차단하는 VPN을 고르거나, WebRTC를 쓸 수 있게 두면서도 누수에 안전하게 만들어 주는 브레이브의 "프록시를 거치지 않는 UDP 비활성화" 모드를 켜는 것입니다.

기자, 활동가, 보안 연구자처럼 웹페이지에 의해 신원이 노출되는 것이 위협 모델에 포함되는 사람이라면 완전한 비활성화가 옳은 선택입니다. 끊긴 영상 통화는 감수하고 그런 용도에는 설치형 앱을 쓰세요. 개인정보에 신경 쓰는 일반 사용자라면 좋은 VPN에 브레이브를 더하는 것이 더 나은 균형입니다.

mDNS란 무엇이고 왜 누수 테스트에 .local 주소가 보이나?

2026년 크롬에서 WebRTC 누수 테스트를 돌렸을 때 a1b2c3d4-5678-90ab-cdef-1234567890ab.local 같은 이상한 로컬 IP 행이 보인다면, 해킹당한 것이 아닙니다. 그것은 mDNS(멀티캐스트 DNS)입니다 — 크롬이 버전 76(2019년 8월 출시)에서 도입한 개인정보 보호 기능으로, 이후 모든 크로미움 브라우저가 사용해 왔습니다.

실제로 일어나는 일은 다음과 같습니다.

• mDNS 이전에는 크롬이 WebRTC를 쓰는 어떤 웹사이트에든 실제 LAN IP(예: 192.168.1.42)를 노출했습니다. 이는 네트워크 구조를 파악하거나 공유기 취약점을 노리는 데 악용될 수 있었습니다.
• mDNS를 쓰면 크롬은 .local로 끝나는 무작위 해시 이름을 생성해 실제 LAN IP 대신 그것을 노출합니다.
• 이 해시는 브라우저 세션마다 고유하고, 실제 IP로 되돌릴 수 없으며, 내 LAN 밖에서는 아무 의미가 없습니다.

따라서 누수 테스트에서 .local 주소가 보이는 것은 누수가 아니라 보호 기능이 작동하는 것입니다. 누수는 그 대신 실제 192.168.x.x 주소가 보일 때입니다.

영상으로 보기: 3분 WebRTC 누수 따라하기

영상으로 따라 하는 편이 좋다면, 이 짧은 영상이 파이어폭스의 WebRTC 비활성화 과정과 크롬의 확장 프로그램 방식을 다룹니다.

자주 묻는 질문 — 빠른 답변

시크릿 모드를 쓰면 WebRTC 누수가 막히나요?

아닙니다. 시크릿 모드는 방문 기록, 쿠키, 입력 데이터를 로컬에 저장하지 않게 막을 뿐입니다. 네트워크 레벨의 동작은 전혀 바꾸지 않습니다. WebRTC는 시크릿 창에서도 일반 창과 똑같은 IP를 노출합니다. 한쪽에서 누수된다면 다른 쪽에서도 누수됩니다.

웹사이트가 WebRTC로 내 로컬 IP를 볼 수 있나요?

최신 크롬, 엣지, 브레이브, 파이어폭스에서는 — 볼 수 없습니다. 로컬 LAN IP는 사이트가 카메라나 마이크 권한을 받지 않는 한 mDNS 해시(.local 이름) 뒤에 숨겨집니다. 오래된 브라우저(2019년 이전)나 mDNS가 없는 일부 기업용 잠금 브라우저는 여전히 원본 192.168.x.x 주소를 노출할 수 있습니다.

IPv6를 끄면 WebRTC 누수가 막히나요?

부분적으로요. VPN이 IPv4만 터널링한다면, OS 네트워크 설정에서 IPv6를 끄면 WebRTC가 실제 IPv6 주소를 보고하지 못하게 됩니다. 다만 이것으로 IPv4 누수가 해결되지는 않고, v6 연결을 기대하는 일부 최신 앱이 깨질 수 있습니다. 더 나은 해결책은 IPv6를 네이티브로 처리하거나 방화벽 레벨에서 차단하는 VPN을 쓰는 것입니다.

브라우저 확장 프로그램이 정말 모든 WebRTC 누수를 막나요?

로컬 IP 누수의 경우 — 막습니다. uBlock Origin의 토글과 구글의 Network Limiter 모두 로컬 IP 열거를 막습니다. 하지만 진짜 개인정보 문제인 공용 IP 누수에 대해서는, 확장 프로그램이 VPN의 네트워크 계층 차단보다 덜 믿음직합니다. 확장 프로그램을 설치한 뒤에는 항상 다시 테스트하세요.

테스트에서 공용 IP 항목에 "VPN IP"가 보이는데 — 안전한가요?

네. WebRTC 누수 테스트에 표시된 공용 IP가 VPN 대시보드의 값과 일치한다면 WebRTC가 터널을 제대로 거치고 있고 누수는 일어나지 않는 것입니다. 이것이 기대하는 좋은 결과입니다.

테스트를 돌렸는데 아무것도 안 나옵니다 — 좋은 건가요?

스캔이 IP를 하나도 반환하지 않거나(또는 명시적으로 "WebRTC 비활성화됨"이라고 표시하면), 파이어폭스에서 WebRTC를 껐거나 WebRTC Control 같은 확장 프로그램이 API를 완전히 막고 있는 것입니다. 가장 사생활이 보호되는 상태이지만 — 의존하던 브라우저 영상 통화 앱은 전부 멈춘다는 점만 기억하세요.

Canvas Defender 같은 브라우저 지문 방지 도구가 WebRTC 누수를 막나요?

아닙니다. 지문 방지 도구는 canvas, WebGL, 폰트 열거를 대상으로 합니다. WebRTC는 별개의 API라 자체적인 해결책(Network Limiter 확장, uBlock의 토글, 파이어폭스의 about:config, 브레이브의 WebRTC IP 처리 정책)이 필요합니다.

---

관련 도구 & 가이드

• WebRTC 누수 테스트 — IPv4, IPv6, 로컬 IP 누수를 잡는 무료 브라우저 기반 스캔.
• 입력 지연 체커 — 키보드, 마우스, 연결 지연을 위한 네트워크 진단 허브의 나머지 도구.
• 웹캠 테스트와 마이크 테스트 — 통화 전 카메라와 마이크가 잘 되는지 확인할 때 쓰는 동일한 getUserMedia / WebRTC API.
• 헤드폰 & 스피커 테스트 — 역시 브라우저의 WebRTC 오디오 스택을 기반으로 합니다.
• 안전한 비밀번호 생성기 — 모든 생성이 로컬에서 이뤄지며 어떤 서버로도 전송되지 않습니다.
• 입력 지연 체커 가이드 — 키보드/마우스 지연을 측정하고 줄이는 법.
• 온라인 마이크 테스트 방법 — WebRTC 기반 마이크 테스트를 다루는 형제 글.
• 웹캠 테스트 가이드 — 통화 전 카메라를 점검하세요.

지금 바로 테스트하세요: 브라우저의 WebRTC 누수 확인하기 — 30초면 끝, 가입 불필요.

빠른 체크리스트

• 작업에 맞는 가장 간단한 브라우저 테스트부터 시작하세요.
• 결과를 해석하기 쉽도록 한 번에 한 가지 설정만 바꾸세요.
• 청소하거나 재시작하거나 기기를 바꾼 뒤에는 다시 테스트하세요.
• 결정을 내리기 전에 관련 도구로 첫 결과를 한 번 더 확인하세요.

관련 도구

전체 도구KeyboardTester.click의 전체 도구 모음을 둘러봅니다.키보드 테스터키와 입력 동작을 빠르게 점검합니다.마우스 테스터마우스 버튼과 스크롤 동작을 확인합니다.반응 속도 테스트브라우저에서 반응 속도를 측정합니다.

Share this guide

ShareCopy linkShare on FacebookShare on XShare on LinkedInPin on PinterestShare on WhatsAppShare by email