iCloud Private Relay가 실제 IP 주소를 유출하고 있다

macOSTahoe ·
iCloud Private Relay가 실제 IP 주소를 유출하고 있다

연구진이 iCloud Private Relay를 켜 둔 상태에서도 웹사이트가 실제 IP를 볼 수 있는 세 가지 경로를 찾아냈습니다. 유출 원리와 테스트 방법, 지금 해야 할 일을 정리했습니다.

iCloud Private Relay를 켠 이유는 하나입니다. 방문하는 사이트가 내가 어디에서 접속하는지 더 이상 보지 못하게 하려는 것이죠. 그게 이 기능의 전부입니다. Apple은 Safari 트래픽을 두 단계 경유지로 중계해서, 어느 한쪽도 — 인터넷 사업자도, 웹사이트도 — 사용자의 신원과 목적지를 하나로 묶지 못하게 만듭니다. 그런데 특정 유형의 요청에 대해서는 이 약속이 지켜지지 않습니다.

2026년 8월 4일, 보안 연구자 Tommy Mysk와 Talal Haj Bakry는 Private Relay가 켜져 있고 정상 동작하는 상태에서도 웹사이트가 실제 IP 주소를 얻어낼 수 있다는 조사 결과를 공개했습니다. 8월 5일에는 MacRumors, 9to5Mac, TechCrunch, The Hacker News 등이 이를 보도했습니다. 유출 경로는 서로 무관한 세 갈래이고, 그중 가장 날카로운 것은 패스키와 얽혀 있습니다. 패스키는 Apple이 몇 년 동안 비밀번호를 대체할 더 안전한 방식이라고 홍보해 온 로그인 기술입니다.

이 글에서는 Private Relay가 실제로 무엇을 약속하는지, 연구진이 무엇을 시연했는지, 세 가지 유출이 각각 어떻게 작동하는지, 자신의 Mac에서 어떻게 테스트하는지, 그리고 정말 해 볼 만한 조치가 무엇인지 짚어 봅니다. 무엇보다 먼저 범위를 분명히 해 둡니다. 이것은 네트워크 신원의 유출이지, 브라우징 내용이나 계정의 유출이 아닙니다. 암호화된 트래픽을 누가 읽고 있는 것이 아닙니다. iCloud에 침입당한 것도 아닙니다. 유출되는 것은 IP 주소이며, 그것이 얼마나 중요한지는 전적으로 사용자가 누구이고 누가 그것을 들여다보는지에 달려 있습니다.

핵심 요약

  • 세 갈래 경로, 하나의 결과. Mysk와 Haj Bakry는 WebAuthn/패스키 세리머니, DNS 프리페치, WebTransport가 각각 Private Relay가 켜진 상태에서도 실제 IP 주소를 웹사이트에 노출시킬 수 있음을 시연했습니다. 서로 독립적인 버그들이 같은 실패 지점으로 수렴한 것입니다.
  • 패스키 유출은 패스키를 갖고 있지 않아도 발생합니다. 연구진에 따르면 사이트는 세리머니를 시작하기만 하면 됩니다. 패스키를 실제로 쓰는 사이트든, 쓰는 척만 하는 사이트든 요청을 유발할 수 있습니다. 사용자가 무언가를 클릭하거나 로그인을 완료할 필요가 전혀 없습니다.
  • 이것은 IP 유출이지 침해가 아닙니다. 브라우징의 암호화된 내용은 노출되지 않고, 계정이 탈취된 것도 아니며, CVE도 부여되지 않았습니다. 노출되는 것은 네트워크 신원, 즉 실제 주소와 (DNS 경로의 경우) 실제 리졸버입니다.
  • Apple은 조사 중이며 현재로서는 수정이 없습니다. Apple은 404 Media에 해당 보고를 검토 중이라고 밝혔습니다. 9to5Mac은 Apple이 연구진에게 보낸 상태 메시지에서 이 문제를 해결할 계획이며 2026년 가을을 목표로 하고 있음을 시사했다고 보도했습니다. MacRumors는 이 문제가 WebKit의 동작 방식 자체에 뿌리내려 있다고 표현했습니다.
  • Private Relay를 끄는 것은 잘못된 대응입니다. 이 기능은 여전히 네트워크상의 수동적 관찰자에 대해 실질적인 역할을 합니다. 진짜 위협 모델을 가진 사람에게 합리적인 상위 대안은 진짜 VPN이며, 다만 신뢰의 대상을 Apple에서 VPN 업체로 옮기는 것이라는 정직한 대가가 따릅니다.

iCloud Private Relay는 정확히 무엇이고, Apple은 무엇을 약속하는가

유출을 평가하기 전에, 무엇이 유출되고 있는지 그 주장을 정확히 짚는 편이 좋습니다. 이 사안을 둘러싼 혼란의 상당 부분은 Private Relay를 애초에 광고된 적 없는 무언가로 기대한 데서 나오기 때문입니다.

iCloud Private Relay는 iCloud+ 기능입니다. 즉 운영체제에 기본 탑재되는 것이 아니라 유료 iCloud 저장 공간 요금제에 딸려 옵니다. Apple의 설명은 일관되고 꽤 좁습니다. IP 주소와 브라우징 활동을 네트워크 사업자와 방문하는 웹사이트로부터 감추도록 설계되었다는 것입니다. 그것이 약속의 전부입니다. 「Mac의 모든 것을 암호화해 준다」도 아니고 「익명이 되게 해 준다」도 아닙니다.

2단계 홉 설계

구조가 흥미로운 부분이고, 실제로 잘 설계되어 있습니다. Private Relay가 동작 중일 때 Safari의 요청은 목적지 서버로 곧장 가지 않습니다. 두 개의 프록시를 순서대로 거칩니다.

첫 번째 홉인 인그레스 프록시는 Apple이 운영합니다. Apple은 사용자가 누구인지 압니다. iCloud 계정에 로그인되어 있고, 기기가 특정 네트워크에서 접속했으니까요. 대신 Apple이 알지 못하는 것은 목적지입니다. 방문하려는 사이트의 주소는 인그레스 프록시가 읽을 수 없도록 암호화되어 있습니다.

두 번째 홉인 이그레스 프록시는 Apple이 아니라 제3자 콘텐츠 전송 파트너가 운영합니다. 실제로 목적지 웹사이트와 통신하는 것은 이 프록시입니다. 어디로 가는지는 알지만 누구인지는 모릅니다. 원래의 IP 주소도 iCloud 신원도 본 적이 없고, 요청을 Apple의 인그레스 프록시로부터 받았기 때문입니다.

그 결과는 의도적인 지식의 분할입니다. 어느 쪽도 민감한 한 쌍의 정보를 모두 갖지 못합니다. Apple은 누구인지는 알지만 어디인지는 모릅니다. 파트너는 어디인지는 알지만 누구인지는 모릅니다. 체인 끝의 웹사이트는 사용자 주소가 아니라 이그레스 프록시의 주소를 봅니다. 여기에 더해 Apple은 대략적인 위치 설정을 제공해서, 사이트가 보는 주소가 여전히 사용자의 지역과 대체로 맞아떨어지게 합니다. 사용자를 특정하지 않으면서 지역 검색 결과나 뉴스가 정상 동작하게 하는 장치입니다.

이 기능은 사람들이 평가하는 것보다 잘 만들어진 설계이고, 이미 iCloud 저장 공간 요금을 내고 있다면 사실상 추가 비용이 들지 않습니다. 이것이 플랫폼의 다른 보호 장치들과 어떻게 맞물리는지 더 넓게 보고 싶다면, macOS Tahoe 보안 및 개인정보 보호 완벽 가이드에서 주변 기능들을 다루고 있습니다.

결정적인 전제: 이것은 VPN이 아니다

유출을 이해하는 데 가장 중요한 지점이 여기입니다. Private Relay는 VPN이 아니며, Apple도 그렇게 설명한 적이 없습니다.

VPN은 제대로 구성되어 있다면 네트워크 계층에서 트래픽을 붙잡습니다. 기기의 모든 애플리케이션, 모든 프로토콜, 모든 소켓이 터널을 통과합니다. 운영체제의 라우팅 테이블이 그쪽으로 보내기 때문입니다. VPN이 무겁고, 이것저것 망가뜨리고, 때로는 커널 확장이나 시스템 네트워크 확장을 요구하는 이유가 바로 그것입니다.

Private Relay는 훨씬 좁은 범위에서 동작합니다. 다루는 것은 다음과 같습니다.

  • Safari 브라우징 트래픽. 대표적인 사용 사례입니다.
  • DNS 해석. DNS 질의도 릴레이를 거치도록 되어 있어서, 리졸버가 사용자의 방문 기록 로그가 되지 않게 합니다.
  • 암호화되지 않은 앱 트래픽 일부. 앱이 보내는 안전하지 않은 HTTP 요청은 보안 강화 차원에서 릴레이로 끌어들입니다.

여기까지가 경계선입니다. Chrome의 트래픽은 통과하지 않습니다. 메일 클라이언트의 트래픽도 통과하지 않습니다. 서드파티 앱의 암호화된 트래픽도 통과하지 않습니다. 애플리케이션이 자체 네트워킹 스택으로 자신의 연결을 열면 Private Relay는 그 경로에 없고, 애초에 있겠다고 주장한 적도 없습니다.

이 구분은 사소한 기술적 세부사항이 아니라, 이번 조사 결과를 평가하는 틀 전체입니다. 연구진이 찾은 세 가지 유출 중 둘은 어떤 수준에서 보면 Private Relay가 그은 경계 밖으로 요청이 빠져나간 사례입니다. 버그는 경계가 존재한다는 사실이 아닙니다. 버그는 사용자가 「Safari 브라우징」이라고 인식하는 행위에서 비롯된 요청이 아무런 신호도 없이, 보이지 않게 그 경계 바깥으로 나간다는 점입니다.

연구진이 발견한 것

Tommy Mysk와 Talal Haj Bakry는 이 분야에 처음이 아닙니다. 이들은 오랫동안 Apple 플랫폼의 프라이버시 주장을 뜯어보며, 마케팅 문구와 실제 구현 사이의 간극이 예상보다 훨씬 넓다는 것을 여러 차례 밝혀 왔습니다. 방식도 일관됩니다. 실증 데모를 만들고, 공개하고, 보도자료가 아니라 결과물 자체가 말하게 하는 것입니다.

Private Relay에 대한 이들의 조사 결과는 2026년 8월 4일 자입니다. 다음 날인 8월 5일에 MacRumors, 9to5Mac, TechCrunch, The Hacker News를 비롯한 여러 매체가 이를 보도했습니다.

핵심 주장을 쉬운 말로 옮기면 이렇습니다. iCloud Private Relay가 켜져 있어도 웹사이트가 실제 IP 주소를 얻어낼 수 있다. 먼저 공격을 당해야 하는 특수한 사이드 채널을 통한 것도 아니고, 사용자 쪽 설정 오류를 악용하는 것도 아닙니다. 어떤 사이트든 호출할 수 있는 평범한 웹 플랫폼 기능을 통해서입니다.

세 가지 경로는 다음과 같습니다.

  1. WebAuthn / 패스키. 패스키 로그인이 발생시키는 네트워크 요청은 Safari가 아니라 운영체제의 자격 증명 서비스가 발행하므로, 프록시 경로에 아예 들어가지 않습니다.
  2. DNS 프리페치. OS 26 세대에서 추가된 성능 기능으로, 사용자의 실제 DNS 리졸버를 드러냅니다.
  3. WebTransport. 26.4 세대에서 추가된 최신 전송 API로, 프록시를 우회하는 직접 HTTP/3 연결을 열 수 있습니다.

노출 대상은 Safari와 WebKit 기반 브라우징입니다. 대부분의 관할권에서 여전히 모든 브라우저가 내부적으로 WebKit을 쓰도록 요구하는 iOS에서는 대체 브라우저도 영향을 받습니다. Safari에서 다른 iPhone 브라우저로 바꿔도 실제로 일하는 엔진은 바뀌지 않기 때문입니다. Mac에서는 상황이 다릅니다. 노출은 Safari와 인앱 브라우징을 위해 WebKit을 임베드한 앱에 집중되며, Chrome이나 Firefox 같은 비WebKit 브라우저는 자체 엔진과 자체 네트워크 스택을 씁니다. 이는 Mac 사용자에게 의미 있는 차이이고, 그것이 무엇을 보장하고 무엇은 보장하지 않는지는 뒤에서 다시 다룹니다.

보도된 Apple의 대응은 이렇습니다. 회사는 404 Media에 해당 보고를 조사 중이라고 밝혔습니다. 9to5Mac은 Apple이 연구진에게 보낸 상태 메시지에서 보고된 문제를 해결할 계획이며 2026년 가을을 목표로 하고 있음을 시사했다고 보도했습니다. Apple에 공개적으로 귀속된 내용은 그것이 전부입니다. 특정 릴리스가 지목된 적도, Apple이 공개적으로 출시일을 확정한 적도 없으며, 세 경로 중 어느 것에도 CVE가 부여되지 않았습니다.

현재로서는 수정이 없습니다. MacRumors는 이 문제가 WebKit의 동작 방식 자체에 뿌리내려 있다고 표현했는데, 수정이 함수 하나에 대한 패치가 아니라 어느 서브시스템이 네트워크 요청을 소유하는지에 대한 재설계여야 하는 유형의 버그를 설명하는 방식으로는 타당합니다.

패스키 경로, 제대로 뜯어보기

셋 중에서 자세히 이해할 가치가 있는 것이 이것입니다. 가장 뜻밖이고, 가장 피하기 어렵고, 가장 불편한 함의를 갖습니다.

WebAuthn 세리머니란 실제로 무엇인가

패스키는 공개 키 인증을 위한 웹 표준인 WebAuthn 위에 만들어졌습니다. 대부분의 사람이 갖고 있는 개념 모형은 대체로 맞습니다. 서버에 비밀번호를 보내는 대신, 기기가 개인 키를 보유하고 서버가 그에 대응하는 공개 키를 보유하며, 로그인은 챌린지에 서명해 개인 키를 통제하고 있음을 증명하는 일입니다. 재사용 가능한 정보는 네트워크를 건너지 않습니다. 서명이 출처(origin)에 묶여 있으므로, 패스키에 대한 피싱은 비밀번호 피싱처럼 작동하지 않습니다.

이 과정을 완성하는 일련의 단계를 **세리머니(ceremony)**라고 부릅니다. 사이트의 JavaScript가 브라우저를 호출하고, 브라우저는 플랫폼에 자격 증명의 생성이나 검증을 요청하며, 사용자는 Touch ID나 기기 암호로 로컬에서 인증하고, 서명된 어서션이 돌아옵니다. Apple 플랫폼에서 자격 증명 자체는 암호 앱에 저장되고 iCloud 키체인을 통해 동기화됩니다. Apple이 이 영역을 어떻게 확장해 왔는지 더 넓은 맥락이 궁금하다면 암호 앱과 자동 비밀번호 변경에 관한 글에서 다룬 바 있습니다.

거의 아무도 생각하지 않는 부분은, 세리머니가 순수하게 로컬에서만 이뤄지지 않는다는 점입니다. 일부는 네트워크로 데이터를 가져오는 과정을 포함합니다. 신뢰 당사자(relying party)의 설정, 그리고 사이트의 도메인과 그 도메인에서 사용할 수 있는 자격 증명을 연결하는 연관 데이터가 그것입니다. 이걸 가져오려면 무언가가 HTTPS 요청을 보내야 합니다.

누가 요청을 보내는가

여기서 문제가 발생합니다. 연구진의 설명에 대한 보도를 인용하면 이렇습니다.

WebKit은 WebAuthn 세리머니를 운영체제의 자격 증명 서비스에 넘기고, 이 서비스는 호스트 앱이 구성한 프록시를 인지하지 못한 채 기기에서 직접 HTTPS 요청을 스스로 발행한다.

한 절 한 절이 모두 의미를 갖고 있으니 주의 깊게 읽어야 합니다. WebKit은 세리머니를 직접 수행하지 않고, 자격 증명을 소유한 시스템 서비스에 위임합니다. 그 서비스는 자신의 아웃바운드 HTTPS 요청을 스스로 만듭니다. 그리고 결정적으로 호스트 앱이 구성한 프록시를 인지하지 못합니다. 자격 증명 서비스는 Safari가 트래픽을 Private Relay의 2단계 경로로 보내도록 설정되어 있다는 사실을 알지도, 신경 쓰지도 않습니다. 네트워킹 구성이 다른 별개의 프로세스가 설계된 대로 동작하고 있을 뿐입니다.

결과는 역시 보도된 표현대로입니다.

해당 페치가 Safari가 아니라 운영체제의 자격 증명 서비스에 의해 발행되기 때문에, Private Relay의 프록시 경로에 아예 진입하지 않는다.

그래서 요청은 기기에서 실제 IP 주소를 달고 곧장 나가, 웹사이트가 통제하는 서버에 도달합니다. 웹사이트는 그 연결을 봅니다. 주소를 기록합니다. Private Relay는 그동안 내내 돌아가고 있었지만, 단지 그 경로에 없었던 것입니다.

구조적 관점에서 보면 누구의 부주의도 없이 어떻게 이런 일이 벌어졌는지 이해할 수 있습니다. 자격 증명 처리는 브라우저로부터 격리되어야 마땅합니다. 그 분리는 실수가 아니라 보안 속성입니다. 임의의 웹사이트에서 온 신뢰할 수 없는 JavaScript를 실행하는 프로세스에서 키 자료를 떼어놓는 것은 정확히 옳은 판단입니다. 문제는 이 격리가 보안을 위해 그어졌고, 프라이버시 경계를 거기에 맞춰 다시 그은 사람이 없었다는 점입니다. 자격 증명 서비스는 프로세스 격리는 물려받았지만 프록시 구성은 물려받지 못했습니다.

가장 날카로운 지점: 패스키가 없어도 된다

이 대목이 흥미로운 아키텍처 이야기를 실제 프라이버시 문제로 바꿔 놓습니다.

연구진은 이것이 패스키를 사용하거나, 단지 사용하는 척하는 사이트에서 발동한다고 지적합니다. 사이트는 사용자가 어떤 로그인도 완료하지 않아도 세리머니를 유발할 수 있습니다. 그 사이트의 패스키를 갖고 있을 필요가 없습니다. 계정이 아예 없어도 됩니다. 로그인 버튼을 누르거나, Touch ID 프롬프트를 승인하거나, 무언가와 상호작용할 필요도 없습니다.

페이지가 API를 호출하면 네트워크 요청이 발생합니다. 세리머니가 결국 성공하든, 실패하든, 중단되든 유출과는 무관합니다. 유출은 인증 로직이 문제가 되기 이전 단계인 페치 시점에 이미 일어나기 때문입니다.

이는 기능의 의미를 뒤집습니다. WebAuthn은 인증을 더 안전하게 만들기 위해 존재합니다. 그런데 이 구성에서는 인증 장치를 호출한다는 사실 자체가, 어떤 페이지든 로드되는 순간 조용히 당길 수 있는 익명성 해제 트리거가 됩니다. 트래커는 무엇도 침해할 필요가 없습니다. 아무도 끝내지 않을 세리머니를 시작하는 코드 조각 하나만 넣으면, 그 페이지를 여는 모든 Private Relay 사용자의 실제 IP를 수집할 수 있습니다.

이 일이 벌어질 때 사용자에게 보이는 신호는 없습니다. 프롬프트도, 권한 시트도, 툴바의 표시도 없습니다. 자격 증명 세리머니를 시작하는 것은 무해한 행위라는 설계상의 가정이 있었고, 통상적인 상황에서는 실제로 그렇습니다.

패스키 인증 흐름 일러스트

DNS 프리페치 경로

두 번째 유출은 파급력은 더 작지만 시사적입니다. 완전히 다른 서브시스템에서 동일한 근본 패턴이 반복되는 것을 보여 주기 때문입니다.

프리페치는 무엇을 위한 것인가

웹 페이지를 불러오는 일은 서로 의존하는 조회의 연쇄입니다. 브라우저가 HTML을 받고 나면, 어떤 도메인의 스타일시트, 다른 도메인의 폰트, 또 다른 도메인의 분석 스크립트, 네 번째 도메인의 이미지를 참조한다는 사실을 발견합니다. 이 도메인들은 연결을 시작하기도 전에 각각 DNS 해석이 필요하고, DNS 해석에는 시간이 걸립니다. 잘 풀리면 수십 밀리초, 상태가 나쁜 모바일 연결에서는 그보다 훨씬 오래 걸립니다.

DNS 프리페치는 이에 대한 단순한 최적화입니다. 브라우저는 페이지를 아직 파싱하는 동안 참조된 링크와 리소스를 미리 살펴 해당 호스트명을 앞당겨 해석해 둡니다. 파서가 실제로 연결이 필요한 지점에 도달할 무렵이면 주소는 이미 캐시되어 있어 연결이 즉시 시작됩니다. 페이지 로드 지표에서 실제 개선으로 나타나는 종류의 변경이고, 브라우저 엔지니어들이 이런 기능을 계속 추가하는 이유이기도 합니다.

이 구현은 OS 26 세대, 즉 Apple 플랫폼 전반의 Tahoe 시기 릴리스에서 도입되었습니다.

무엇이 노출되는가

연구진은 이 프리페치 질의가 사용자의 실제 DNS 리졸버를 드러낸다는 것을 발견했습니다.

정상적인 Private Relay 동작에서 DNS는 릴레이가 감싸야 할 대상에 포함됩니다. 이는 의도적이고 중요한 부분입니다. 질의가 평문으로 ISP의 리졸버로 간다면, ISP는 조회한 모든 도메인의 타임스탬프 목록을 보유하게 되고, 실제 트래픽이 아무리 잘 암호화되어 있어도 그것은 사실상 완전한 브라우징 기록입니다. Private Relay가 존재하는 이유의 상당 부분은 바로 그 연결 고리를 끊는 데 있습니다.

프리페치 질의가 그 경로를 벗어나면, 기기가 실제로 사용하도록 설정된 리졸버로 갑니다. 보통은 현재 네트워크에서 DHCP로 받은 리졸버이고, 대개 ISP나 회사, 또는 지금 접속한 Wi-Fi의 운영 주체를 뜻합니다.

여기서 유출되는 것은 원시 IP 주소보다는 좁습니다. 관찰자는 사용자가 어떤 리졸버를 쓰는지 알게 되는데, 이는 어떤 네트워크에 있는지, 종종 어느 사업자의 서비스를 받는지에 대한 강한 신호입니다. 다른 신호와 결합되면 핑거프린트에 기여합니다. 또한 원래 그 리졸버 운영자로부터 가려져야 했던 조회를 그가 보게 된다는 뜻이기도 합니다.

패스키 경로보다는 작은 문제이고 더 거친 신호를 만들어 냅니다. 그렇다고 아무것도 아닌 건 아닙니다. 터널을 켠 상태에서 macOS의 DNS 동작과 씨름해 본 적이 있다면 익숙하게 느껴질 것입니다. 시스템 리졸버와 프록시된 트래픽의 상호작용은 늘 혼란의 원천이고, macOS VPN 문제 해결 가이드에서 그런 문제들의 일반적인 형태를 다룹니다.

WebTransport 경로

세 번째 유출은 셋 중 가장 새로운 기술과 관련되어 있고, 구조적 문제를 가장 깔끔하게 보여 줍니다.

WebTransport는 무엇을 위한 것인가

WebTransport는 브라우저와 서버 사이의 저지연 양방향 통신을 위한 현대적 웹 API입니다. TCP가 아니라 HTTP/3와 QUIC 위에 만들어진 WebSocket의 후계자라고 보면 됩니다.

이것이 존재하는 이유는, 요청/응답 모델보다 더 나은 것이 필요한 웹 애플리케이션이 상당수 있기 때문입니다. 멀티플레이어 게임은 상태를 끊임없이 밀어내야 하고, 지연보다는 가끔의 업데이트 유실을 더 잘 견딥니다. 라이브 비디오와 오디오 애플리케이션도 마찬가지입니다. 공동 편집기, 원격 데스크톱 도구, 실시간 텔레메트리 대시보드까지, 모두 오버헤드가 낮은 지속 채널과 신뢰성이 지연 비용만큼의 가치가 없을 때 비신뢰 데이터그램을 보낼 수 있는 능력을 원합니다.

WebTransport는 QUIC 위에서 동작함으로써 이를 제공합니다. QUIC는 암호화가 내장된 UDP 기반 전송이며 스트림 간 헤드 오브 라인 블로킹이 없습니다. 해결하려는 문제에 대해 정말 잘된 엔지니어링입니다.

Apple의 구현은 26.4 세대에서 도입되었습니다.

직접 HTTP/3 연결이 프록시를 무력화하는 이유

Private Relay의 프록싱은 통상적인 웹 트래픽, 즉 Safari의 일반적인 네트워킹 경로가 만들어 내는 요청 패턴을 중심으로 설계되었습니다. 그런 요청들은 인그레스/이그레스 2단계 체인을 통과합니다.

연구진은 WebTransport가 프록시를 우회하는 직접 HTTP/3 연결을 열 수 있다는 것을 발견했습니다. 그 연결이 기기에서 목적지 서버로 직접 수립되고 나면, 서버는 프록시되지 않은 모든 연결과 마찬가지로 기기의 실제 주소를 봅니다.

여기서의 패턴은 관련 코드가 전혀 다름에도 패스키 사례와 동일합니다. 플랫폼에 새로운 기능이 추가되었습니다. 그 기능은 네트워크 연결을 엽니다. 프록싱 계층은 그 새 기능이 나오기 전의 「네트워크 연결」 모형을 전제로 만들어져 있습니다. 둘을 잇는 것이 없고, 새 기능은 조용히 경계 바깥에서 동작합니다.

MacRumors의 표현, 즉 이 문제가 WebKit의 동작 방식 자체에 뿌리내려 있다는 말이 단순한 수사 이상인 이유가 여기 있습니다. 엔진이 진화하면서 네트워크와 통신할 수 있는 서브시스템이 계속 늘어납니다. 프록시 경계가 그 모두가 반드시 통과해야 하는 계층에서 강제되지 않는 한, 새로 추가되는 서브시스템은 매번 같은 버그의 후보가 됩니다. 특정한 세 가지 유출을 고치는 것만으로는 네 번째를 막을 수 없습니다.

내 Mac에서 테스트하는 방법

연구진은 공개 테스트 도구를 만들었고, 독자 입장에서는 이번 공개에서 가장 유용한 부분입니다. 누구의 말도 그냥 믿을 필요가 없습니다.

도구 주소는 https://leaks.psylo.app/ 입니다.

테스트 실행하기

  1. 먼저 Private Relay가 켜져 있는지 확인합니다. 릴레이가 돌아가지 않는다면 유출을 테스트할 이유가 없습니다. 시스템 설정을 열고 사이드바 상단의 Apple 계정을 클릭한 뒤 iCloud, 그다음 Private Relay를 선택해 활성화 상태인지 확인합니다. 확신이 서지 않는다면 Private Relay 상태 확인을 다룬 섹션을 먼저 보세요. 사람들이 생각하는 것보다 훨씬 자주 스스로 꺼집니다.
  2. 릴레이된 IP가 어떤 모습이어야 하는지 확인해 둡니다. 릴레이가 켜진 상태로 Safari에서 어떤 「내 IP 확인」 서비스를 열든, 자신의 주소가 아니라 Apple 이그레스 파트너의 주소가 표시됩니다. 그것이 기준선, 즉 사이트가 보게 되어 있는 주소입니다.
  3. Safari로 테스트 페이지를 방문합니다. macOS에서 이 경로들은 WebKit 고유의 문제이므로 반드시 Safari를 써야 합니다. 도구가 검사를 수행하고 연결에 대해 관찰한 내용을 보고합니다.
  4. 결과를 비교합니다. 깨끗한 결과란 도구가 각 경로에서 관찰한 주소가 릴레이된 주소와 일치한다는 뜻이고, 프록시가 유지된 것입니다. 유출 결과란 최소 한 경로에서 릴레이의 것이 아닌 주소가 드러났다는 뜻이며, 그 주소는 사용자 본인의 것입니다.
  5. 신경 쓰이는 네트워크마다 테스트합니다. 집 네트워크, 회사 네트워크, 공용 Wi-Fi에서 결과가 다를 수 있습니다. Private Relay 자체의 가용성이 네트워크마다 다르다는 점도 한몫합니다.

솔직히 짚어 둘 단서

테스트 도구는 자신이 구현한 경로에 대해서만 알려 줍니다. 가능한 모든 경로에 대해 알려 주지는 않습니다.

이는 흔한 면책 문구 이상의 의미를 갖는데, 앞서 말한 구조적 문제 때문입니다. 근본 원인이 새로운 WebKit 서브시스템이 프록시 경계 바깥에서 네트워크 연결을 열 수 있다는 데 있다면, 경로의 집합은 고정된 것이 아니라 지금까지 발견된 것에 불과합니다. 세 가지를 검사하는 도구에서 깨끗한 결과가 나왔다는 건, 그 테스트에서 그 네트워크에서 그 시점에 그 세 가지가 유출되지 않았다는 뜻입니다. 모르는 것보다는 확실히 낫습니다. 익명성 보증서는 아닙니다.

부정적인 보안 결과를 대할 때와 똑같이 다루세요. 특정한 문제들에 대한 증거가 없다는 것이지, 전반적으로 문제가 없다는 증거는 아닙니다.

지금 실제로 할 수 있는 일

설치할 수정판은 없습니다. 아래는 실효성 순으로 대략 정렬한 목록이고, 각 항목에는 그에 따르는 대가도 함께 적었습니다. 대가를 말하지 않는 완화책은 조언이 아니라 영업이기 때문입니다.

1. 위협 모델이 정당화한다면 진짜 VPN을 쓰세요

보도에서 언급된 완화책이며, 이 목록에서 문제를 올바른 계층에서 다루는 유일한 선택지입니다. 제대로 구성된 VPN은 네트워크 계층에서 트래픽을 붙잡는데, 이는 세 경로가 동작하는 지점보다 아래입니다. 자격 증명 서비스의 HTTPS 요청, 프리페치 DNS 질의, WebTransport의 QUIC 연결은 모두 운영체제의 네트워킹 스택을 지나고, 시스템 수준 VPN은 그 전부의 아래에 자리합니다.

대가는 실재하며, 실행에 옮기기 전에 소리 내어 말해 두어야 합니다. 신뢰의 대상을 Apple에서 VPN 업체로 옮기는 것입니다. Private Relay의 2단계 설계는 어느 한쪽도 신원과 목적지를 동시에 보지 못하도록 특별히 구성되어 있습니다. 통상적인 단일 홉 VPN에는 그런 성질이 없습니다. VPN 사업자는 둘 다 봅니다. 사용자는 그들의 로깅 정책, 관할권, 운영 보안, 그리고 정직성에 베팅하는 것이며, Apple의 아키텍처와 달리 그 베팅은 설계로 강제되지 않고 개인정보 처리방침의 약속으로 강제됩니다.

이는 VPN에 반대하는 논거가 아닙니다. VPN을 신중하게 고르라는 논거입니다. 독립적으로 감사받았고, 관할권을 명확히 밝히며, 사용자 데이터에 의존하지 않는 수익 모델을 가진 곳으로요. 이 길을 택한다면 설정상의 자잘한 문제에 시간을 좀 쓸 각오를 하세요. macOS VPN 문제 해결 가이드에서 macOS 특유의 함정들을 다룹니다.

2. Private Relay를 끄지 마세요

가장 흔한 본능이지만 방향이 반대입니다.

Private Relay는 수동적 관찰자에 대해 여전히 실질적인 역할을 합니다. ISP는 여전히 릴레이를 통과하는 모든 것에 대해 DNS 질의로 브라우징 로그를 만들 수 없습니다. 카페 Wi-Fi 운영자도 여전히 어떤 사이트를 방문하는지 지켜볼 수 없습니다. Safari 트래픽의 절대다수는 여전히 프록시되고 방문 사이트로부터 주소를 감춥니다. 유출은 빠져나가는 특정 경로들이고, 사이트가 능동적으로 시도해야 합니다. 페이지가 패스키 세리머니를 호출하거나, WebTransport를 쓰거나, 프리페치 동작을 유발해야 합니다.

릴레이를 끈다고 이 유출 중 어느 하나도 막히지 않습니다. 릴레이가 성공적으로 막아 주던 노출만 전부 되돌아올 뿐입니다. 아무것도 얻지 못한 채 이전보다 프라이버시가 엄격히 줄어드는 결과가 됩니다.

3. 어떤 사이트가 세리머니를 시작하게 둘지 의식하세요

들리는 것보다 약한 조언이고, 그 이유를 정직하게 말할 필요가 있습니다.

패스키 경로는 상호작용 없이 발동합니다. 물어본 적도 없는 세리머니를 거절할 수는 없습니다. 그러니 토글할 설정도, 거부할 프롬프트도 없습니다.

남는 것은 애초에 어떤 페이지를 여느냐에 대한 통제권입니다. IP 노출이 정말 문제가 되는 일을 하고 있다면, 링크를 눌러 도달한 페이지든 임베드된 인앱 브라우저 뷰든, 여는 모든 페이지가 이 경로를 호출할 수 있는 페이지라는 점을 의식하세요. 이는 구획화를 지지하는 논거입니다. 민감한 브라우징은 다른 모든 것과 같은 세션이 아니라 의도적으로 선택한 환경에서 하세요. 피해야 할 사이트 목록을 만들라는 뜻은 아닙니다. 이를 악용할 사이트는 스스로를 드러내지 않기 때문입니다.

4. 잠금 모드가 여기서 무엇을 하고 무엇을 하지 않는지 이해하세요

잠금 모드는 표적 공격 위험이 있는 사용자를 위한 Apple의 극단적 보호 설정입니다. JIT JavaScript 컴파일을 포함한 다양한 복잡한 기능 등 긴 목록의 웹 기술을 비활성화합니다. 존재하지 않는 공격 표면은 악용될 수 없다는 논리입니다.

잠금 모드가 겨냥한 집단에 속한다면 고려해 볼 만합니다. 특정 버그를 패치하는 대신 기능 자체를 제거하는 접근이고, 제거된 기능은 유출될 수 없기 때문입니다. 다만 추론에는 주의하세요. 잠금 모드는 보안 강화 태세이지 이 세 경로에 대한 표적 수정이 아니며, 어떤 보도도 이를 이 문제의 해법으로 제시하지 않습니다. 이미 잠금 모드의 대상에 해당한다면 검토해 볼 만한 선택지로 여기되, 이 특정 문제에 대한 답으로 여기지는 마세요. 또한 평범한 웹 브라우징을 상당 부분 망가뜨리는데, 이는 의도된 설계이며 Apple이 일반 사용자에게 권하지 않는 이유이기도 합니다.

5. 브라우저를 바꾸면 무엇이 달라지고, 어디서는 아무 소용이 없는지 알아 두세요

여기서는 플랫폼이 중요합니다.

iOS에서는 브라우저를 바꿔도 소용이 없습니다. 대부분의 관할권이 여전히 모든 브라우저에 WebKit 엔진 사용을 요구하므로, 설치한 대체 브라우저는 같은 엔진 위에 다른 인터페이스를 씌운 것일 뿐이고 경로도 동일합니다. iPhone의 Chrome은 Chrome의 엔진이 아닙니다.

Mac에서는 상황이 실제로 다릅니다. 비WebKit 브라우저는 자체 엔진과 자체 네트워크 스택을 쓰므로, 이 WebKit에서 비롯된 특정 경로들에 대해 다르게 동작합니다. 다만 그것이 무엇을 보장하고 무엇은 보장하지 않는지 주의 깊게 보세요. Private Relay는 애초에 Safari 이외 브라우저의 트래픽을 프록시하지 않습니다. macOS에서 Chrome이나 Firefox로 옮기는 것은 릴레이 뒤로 들어가는 것이 아니라 릴레이 밖으로 완전히 나가는 것입니다. 유출을 고친 게 아니라 보호를 스스로 포기한 것입니다. 이는 모든 것을 아우르는 VPN과 함께 쓸 때만 개선입니다. Safari에서 대부분의 시간을 보내고 그것을 더 잘 쓰고 싶다면, 잘못된 이유로 시도하는 브라우저 이주보다 Safari 파워 유저 가이드에 시간을 쓰는 편이 낫습니다.

이 중 어느 것도 스스로에게 과장하지 마세요. 2번부터 5번까지는 노출을 줄이거나 상황을 악화시키지 않는 정도입니다. 이 경로들이 동작하는 계층에서 문제를 다루는 것은 1번뿐이고, 그마저도 하나의 신뢰 관계를 다른 신뢰 관계로 바꾸는 방식입니다.

네트워크 프라이버시 계층 일러스트

누가 실제로 신경 써야 하는가

프라이버시 이슈는 호들갑에 보상을 주고 균형 감각에 벌을 줍니다. 그러니 누가 얼마나 영향을 받는지 정확히 짚어 봅시다.

대부분의 사람에게 이것은 응급 상황이 아니라 침식이다

평범한 위협 모델을 가진 일반 사용자라면 솔직한 평가는 이렇습니다. 돈을 내고 쓰는 기능이 특정 상황에서 광고보다 못한 일을 하고 있고, 이는 짜증나며 Apple이 고칠 만한 사안이지만, 실질적인 영향은 거의 0에 가깝습니다.

무엇이 실제로 유출되는지 생각해 보세요. IP 주소가, 그것을 일부러 찾아 나선 사이트에게 넘어갑니다. 대부분의 사이트는 이미 훨씬 나은 식별자를 갖고 있습니다. 로그인되어 있고, 쿠키가 있으며, 네트워크를 옮길 때마다 바뀌는 IP 주소보다 훨씬 변별력 있는 브라우저 핑거프린트가 있습니다. 광고 생태계에서 IP 주소는 보조 신호이지 핵심 자산이 아닙니다. 이를 악용하는 회사가 있다면, 그건 이미 Private Relay가 애초에 막을 수 없는 수단으로 사용자를 전방위로 추적하고 있는 곳입니다.

잃는 것은 있으리라고 믿을 만한 이유가 있었던 다층 방어의 한 겹입니다. 그건 정당한 불만입니다. 삶의 방식을 바꿀 이유는 아닙니다.

행동해야 할 사람들

이를 진지하게 다뤄야 할 사람은 위협 모델에 IP 기반 익명성 해제가 실제로 포함되는 이들입니다. 구체적으로는 다음과 같습니다.

  • 취재원과 일하는 기자. 기자와 특정 장소 또는 네트워크의 연결 자체가 민감한 정보인 경우입니다.
  • 활동가와 조직가. 네트워크 주소가 위험을 수반하는 실제 신원으로 이어지는 환경에 있는 경우입니다.
  • 특정 개인을 피하고 있는 사람. 스토커, 폭력적인 전 배우자, 사이트나 링크를 운영해 접속 기록을 읽어낼 기술적 수단과 동기를 가진 사람 등입니다. IP 주소가 정말로 위험해지는 경우인데, 대략적인 위치를 추정할 수 있고 특정 인물이 특정 링크를 방문했음을 확인시켜 주기 때문입니다.
  • 고용주나 소속 기관이 자신의 검색 내용을 알아서는 안 되는 사람, 특히 그 기관이 통제하는 네트워크를 쓰는 경우입니다.

이 중 하나에 해당한다면, 애초에 올바른 태세는 Private Relay 단독이 아니었습니다. 잘 고른 VPN이나 Tor, 적절한 구획화, 그리고 어떤 편의 기능이든 실패할 수 있다는 전제였습니다. 이번 공개는 그 원칙을 바꾸는 것이 아니라 상기시키는 사건입니다. Mac 보안 및 개인정보 보호 가이드에서 다층 구성을 만드는 방법을 더 깊이 다루고 있고, 노출을 더 폭넓게 줄이는 것을 고민하고 있다면 AI 도구를 클라우드가 아닌 로컬에서 실행하기가 같은 논리를 스택의 다른 부분에 적용한 사례입니다.

중간 지대

「나와 무관함」과 「내 안전이 여기 달려 있음」 사이에 나머지 모두가 있고, 그곳에서 합리적인 태세는 행동보다는 조정입니다. Private Relay의 적용 범위가 사람들이 갖고 있는 개념 모형보다 좁다는 사실을 이해하세요. 이를 VPN처럼 여기는 것을 멈추세요. VPN이 아니고, 이제 그 차이를 보여 주는 구체적인 실증이 있습니다. 계속 켜 두세요. 설계 목적인 관찰자들에 대해서는 여전히 도움이 됩니다. 그리고 신원이 드러나면 실제로 곤란해지는 일을 하게 된다면, 이미 켜져 있다는 이유로 그 기능에 기대지 말고 그 일을 위해 만들어진 도구를 집으세요.

Private Relay가 켜져 있기는 한지 확인하는 방법

지금 사용하는 네트워크 중 최소 하나에서 Private Relay가 꺼져 있는데 그 사실을 모르고 있을 가능성이 상당히 높습니다. 여러 상황에서 별다른 예고 없이 스스로 비활성화되므로, 유출을 걱정하기 전에 릴레이가 돌아가고 있는지부터 확인해 볼 가치가 있습니다.

기본 설정

Mac에서:

  1. 시스템 설정을 엽니다.
  2. 사이드바 상단의 Apple 계정을 클릭합니다.
  3. iCloud를 선택합니다.
  4. 목록에서 Private Relay를 찾아 엽니다.
  5. 토글이 켜져 있는지 확인합니다. 온 김에 IP 주소 위치 설정도 확인하세요. 「대략적인 위치 유지」는 지역 콘텐츠가 정상 동작하게 하고, 「국가 및 시간대 사용」은 표시되는 위치를 더 넓게 잡습니다.

Private Relay가 아예 보이지 않는다면, 보통은 유료 iCloud+ 요금제가 아니기 때문입니다. iCloud+ 기능이라서 무료 저장 공간 등급에는 나타나지 않습니다.

거의 아무도 모르는 네트워크별 토글

이것 때문에 사람들이 계속 걸립니다. Private Relay는 전역 설정과 별개로 Wi-Fi 네트워크마다 별도의 켜짐/꺼짐 상태를 갖습니다.

확인 방법은 이렇습니다. 시스템 설정을 열고 Wi-Fi로 이동해 연결된 네트워크 옆의 세부사항을 클릭한 뒤 그 안에서 Private Relay 옵션을 찾습니다. 전역 설정이 켜져 있어도 그 특정 네트워크에서는 꺼져 있을 수 있습니다.

이는 실제로 유용한 동작입니다. 릴레이 없이는 작동하지 않는 회사 네트워크 하나만 예외로 두면서 전반적으로는 릴레이를 켜 두는 방법이니까요. 하지만 그렇기 때문에 「Private Relay를 켜 뒀다」와 「Private Relay가 지금 돌아가고 있다」는 서로 다른 진술이 됩니다. 테스트에서 예상 밖의 결과가 나오는 네트워크에서는 네트워크별 설정을 확인하세요.

조용히 꺼지는 경로들

두 개의 토글 외에도, 눈에 띄는 경고 없이 릴레이를 비활성화하는 조건이 여럿 있습니다.

  • 지원되지 않는 네트워크. 일부 네트워크는 Private Relay가 의존하는 프로토콜이나 엔드포인트를 차단합니다. 그럴 때 macOS는 보통 릴레이 없이 네트워크를 쓸지 아니면 연결하지 않을지 선택하게 하고, 그때 고른 선택이 계속 유지됩니다.
  • 회사 및 관리 네트워크. 기업은 Private Relay를 의도적으로 비활성화하는 경우가 많습니다. 목적지 주소를 감추는 프록시는 네트워크 수준의 콘텐츠 필터링 및 모니터링과 근본적으로 양립할 수 없기 때문입니다. 관리 대상 기기에서는 구성 프로파일로 비활성화되어 사용자에게 보이는 토글 자체가 없을 수도 있습니다.
  • 국가 및 지역 제한. Private Relay는 모든 곳에서 제공되지 않습니다. Apple은 여러 관할권에서 사용할 수 없다고 확인했으며, 해당 지역에서는 설정과 무관하게 기능이 아예 동작하지 않습니다.
  • 이동통신사 구성. 일부 통신사는 자사 네트워크에서 이를 비활성화하는 구성을 배포했습니다.
  • 충돌하는 VPN 또는 DNS 구성. 시스템 VPN을 사용하면 대체로 Private Relay는 물러납니다. VPN이 트래픽을 먼저 가져가기 때문입니다. 사용자 지정 DNS 설정이나 특정 DNS 필터링 프로파일도 이를 비활성화할 수 있습니다.

공통점은 Private Relay가 요란하게 실패하는 대신 조용히 열린 채로 실패한다는 것입니다. 동작을 멈춰도 브라우징은 계속됩니다. 편의 기능으로서는 옹호할 만한 설계 선택이고, 대안은 사람들의 인터넷을 끊는 것이니까요. 다만 그렇기 때문에 자신의 실제 상태를 아는 유일한 방법은 주기적인 확인뿐입니다.

제대로 된 수정은 어떤 모습이어야 하는가

Apple이 여기서 실제로 무엇을 만들어야 하는지 생각해 볼 가치가 있습니다. 보도된 일정이 포인트 릴리스가 아니라 개월 단위인 이유를 설명해 주기 때문입니다.

얕은 수정은 각 경로를 개별적으로 패치하는 것입니다. 자격 증명 서비스가 호스트 애플리케이션의 프록시 구성을 인지하게 만들어 세리머니 페치를 그에 맞게 라우팅하기. 프리페치 DNS 질의를 릴레이의 DNS 경로 안으로 되돌리기. WebTransport의 QUIC 연결을 프록시 체인으로 보내거나, 릴레이가 활성화되어 있을 때는 직접 수립을 거부하기. 표적 변경 세 개, 구멍 세 개 봉합입니다.

이렇게 하면 보고된 문제는 고쳐지지만 근본 조건은 고쳐지지 않습니다. 세 가지 모두의 패턴은 동일합니다. 네트워크에 접근할 수 있는 서브시스템이 프록시 경계를 물려받지 않은 채로 만들어졌다는 것입니다. 경계가 모든 서브시스템 아래에서 강제되는 것이 아니라 각 서브시스템이 스스로 채택해야 하는 것으로 남아 있는 한, 같은 일이 계속 반복됩니다.

깊은 수정은 구조적입니다. WebKit에 인접한 모든 네트워크 경로가 반드시 지나야 하는 계층에서 릴레이를 강제해서, 새 기능이 릴레이의 존재를 몰라 우회하는 일이 불가능하게 만드는 것입니다. 이는 무언가를 망가뜨릴 실질적 위험이 있는 큰 변경이고, 보안 업데이트가 아니라 메이저 릴리스에 실리는 종류의 작업입니다. 또한 진짜로 릴레이할 수 없는 요청을 어떻게 처리할지에 대한 명확한 정책도 필요합니다. 닫힌 채로 실패해 기능을 망가뜨릴 것인가, 열린 채로 실패해 유출을 허용할 것인가. 어느 쪽도 편치 않고, 하나를 고르는 일은 엔지니어링 결정만큼이나 제품 결정입니다.

세 번째 요소이자 어쩌면 가장 가치 있는 것은 사용자에게 보이는 부분입니다. 요청이 릴레이를 벗어날 때 어떤 신호를 주는 것이죠. 지금 이 기능은 자신의 적용 범위에 대해 완전히 침묵합니다. 지금 보고 있는 페이지가 완전히 프록시되었는지, 부분적으로만 되었는지, 전혀 안 되었는지 알 길이 없습니다. 세 건의 구현 누락을 「깨진 약속」에 관한 이야기로 만든 것이 바로 그 불투명성입니다. 사용자에게는 동작 중인 상태와 아닌 상태를 구분할 방법이 없었기 때문입니다.

2026년 가을 릴리스에서 주목할 점

9to5Mac이 보도한 Apple의 상태 메시지에 따르면, 수정은 2026년 가을을 목표로 합니다. 보도된 내용이 그것뿐입니다. Apple은 특정 릴리스나 날짜를 공개적으로 약속하지 않았고, 이를 보증으로 받아들여서는 안 됩니다.

무언가가 출시된다면, 확인할 만한 것들은 다음과 같습니다.

  • 세 경로 모두가 해결되는지, 아니면 패스키 경로만인지. 헤드라인을 가져간 것은 패스키 경로입니다. 나머지 둘은 더 조용하고 미뤄질 가능성도 충분합니다.
  • 수정이 표적형인지 구조적인지. 릴리스 노트가 이를 직접 밝히는 일은 드물지만, 연구진이 재검증해 보고할 가능성이 높고, 이들의 테스트 도구는 나머지 모두에게도 독립적으로 확인할 방법을 줍니다.
  • 사용자에게 보이는 무언가가 등장하는지. 페이지 단위로 릴레이 적용 여부를 알려 주는 표시가 생긴다면 현재의 침묵보다 의미 있는 개선일 것입니다.
  • Private Relay의 범위 설명이 바뀌는지. Apple이 이 기능이 무엇을 다루는지에 대한 표현을 조인다면 그 자체로도 시사적입니다. 해결이 전적으로 코드의 문제가 아니라 부분적으로는 기대치의 문제였다는 뜻이 되니까요.

그때까지 상황은 그대로입니다. 유출은 실재하고, 릴레이는 여전히 수동적 관찰자에 대해 유용한 일을 하며, 그 둘 사이의 간극에서 각자의 판단을 내려야 합니다.

자주 발생하는 문제 해결

Private Relay가 회색으로 비활성화되어 있거나 아예 없음

문제: 시스템 설정 → Apple 계정 → iCloud로 들어갔는데 Private Relay가 목록에 없거나 토글이 반응하지 않습니다.

해결: 원인을 순서대로 짚어 보세요. 첫째, 유료 iCloud+ 요금제인지 확인합니다. Private Relay는 무료 등급에 존재하지 않으며, 항목이 아예 없는 가장 흔한 이유입니다. 둘째, 지역을 확인합니다. 이 기능은 여러 국가에서 제공되지 않으며, 제공되지 않는 곳에서는 표시되지 않습니다. 셋째, Mac이 회사나 학교에 의해 관리되고 있다면 시스템 설정의 일반 → 기기 관리에서 구성 프로파일을 확인하세요. 조직은 네트워크 필터링을 무력화한다는 이유로 Private Relay를 일상적으로 비활성화하며, 프로파일 수준의 제한은 로컬에서 덮어쓸 수 없습니다. 넷째, iCloud+ 구독이 걸린 계정으로 로그인되어 있는지, 보조 계정이 아닌지 확인합니다. 네 가지가 모두 정상인데도 토글이 여전히 반응하지 않는다면, iCloud에서 로그아웃했다가 다시 로그인한 뒤 재시동하세요.

특정 네트워크에서만 Private Relay가 계속 꺼짐

문제: 집에서는 릴레이가 작동하는데 사무실, 특정 카페, 또는 어떤 호텔 Wi-Fi에서는 일관되게 꺼져 있습니다.

해결: 네트워크별 토글부터 확인하세요. 거의 항상 이것이 원인입니다. 시스템 설정을 열고 Wi-Fi로 이동해 해당 네트워크 옆의 세부사항을 클릭한 뒤 그 안의 Private Relay 설정을 봅니다. 전역 스위치와 독립적이며, 언젠가 「이 네트워크는 Private Relay를 차단합니다」라는 프롬프트에서 릴레이 없이 계속하기를 선택했다면 그 선택이 해당 네트워크에 기억되어 있습니다. 다시 켜고 연결이 여전히 정상인지 보세요. 네트워크가 정말로 릴레이를 차단한다면 프롬프트가 다시 뜰 것이고, 그 시점에 차단이 오래된 설정 탓이 아니라 상위에서 이뤄지고 있음을 알게 됩니다. 특히 회사 네트워크는 방화벽에서 의도적으로 차단하는 경향이 있고, 클라이언트 쪽 우회책은 없습니다. 그런 네트워크에서 주소 프라이버시가 필요하다면 VPN이 유일한 경로이며, 그마저도 네트워크가 허용해야 가능합니다.

테스트 도구가 유출을 보고했고 무엇을 해야 할지 알고 싶을 때

문제: 연구진의 도구를 방문했더니 하나 이상의 경로에서 실제 주소가 보인다고 보고했고, 다음 단계를 알고 싶습니다.

해결: 첫째, 이를 침해로 해석하지 마세요. 유출 결과는 사이트가 IP 주소를 알아낼 수 있다는 뜻이지, 무언가가 탈취되거나 접근되거나 침해되었다는 뜻이 아닙니다. 보호해야 할 계정도, 변경해야 할 비밀번호도 없습니다. 둘째, 결과가 경로 때문인지 아니면 릴레이가 꺼져 있어서인지 확인하세요. 전역 및 네트워크별 Private Relay 설정을 점검하고 다시 테스트합니다. 릴레이가 꺼져 있으면 모든 경로에서 실제 주소가 나타나며, 이는 손쉬운 해결책이 있는 완전히 다른 문제입니다. 셋째, 릴레이가 켜져 있음을 확인했는데도 유출이 지속된다면 보고된 동작을 재현한 것이고, 사용자 쪽에서 할 수 있는 수정은 없습니다. 위협 모델에 따라 판단하세요. 대부분의 사람에게 올바른 대응은 이를 기억해 두고 하던 대로 하는 것이며, 주소 프라이버시가 정말 필요한 사람에게는 앞서 설명한 신뢰의 대가를 감수한 VPN이 사용 가능한 완화책입니다. 2026년 가을 업데이트가 나오면 다시 테스트하세요.

Private Relay를 쓴다는 이유로 사이트가 차단하거나 오작동함

문제: 은행 사이트가 열리지 않거나, 스트리밍 서비스가 엉뚱한 국가에 있다고 주장하거나, 쇼핑몰 결제가 실패하거나, 사이트가 CAPTCHA를 반복해서 띄웁니다.

해결: 사이트가 사용자 주소가 아니라 이그레스 프록시의 주소를 보기 때문인데, 그 주소를 가정용 회선으로 인식하지 못하거나, 지오로케이션이 예상 밖의 위치로 잡히거나, 이미 플래그된 공유 대역에 속하기 때문입니다. 위치 설정부터 시작하세요. Private Relay 패널에서 IP 주소 위치가 더 넓은 국가 단위 옵션으로 되어 있다면 「대략적인 위치 유지」로 바꾸면 대부분의 지리적 불일치가 해소됩니다. 그것으로 부족하면 전역이 아니라 해당 네트워크에서만 네트워크별 토글로 릴레이를 끄거나, 그 사이트에만 다른 브라우저를 쓰세요. 단, macOS에서 Safari 이외 브라우저는 어차피 릴레이 밖에 있다는 점을 기억하세요. 고집스러운 사이트 하나 때문에 릴레이를 전역으로 끄는 것은 과잉 대응이고, 되돌리는 것을 잊게 됩니다.

VPN과 Private Relay가 서로 충돌함

문제: VPN을 연결했더니 Private Relay가 비활성 상태로 표시되거나, 둘을 함께 쓰니 DNS가 깨지고 연결이 실패하거나 브라우징이 못 쓸 만큼 느려집니다.

해결: 먼저 이것이 대체로 예상된 동작임을 이해하세요. 시스템 VPN은 Private Relay가 보기 전에 네트워크 계층에서 트래픽을 붙잡으므로, macOS는 VPN이 활성화되면 대체로 릴레이를 물러나게 합니다. 버그가 아니며 보호받지 못하는 상태가 되는 것도 아닙니다. 이제 VPN이 릴레이보다 엄격히 더 많은 트래픽을 담당하고 있기 때문입니다. 실무적인 지침은 하나를 골라 그 경로를 맡기라는 것입니다. 이 글에서 논의한 이유로 VPN을 쓰고 있다면 릴레이가 물러나는 것이 올바른 결과입니다. 릴레이가 비활성으로 표시되는 정도가 아니라 실제로 무언가 깨지고 있다면, 흔한 원인은 충돌하는 DNS 구성, 트래픽을 부분적으로만 붙잡는 VPN 클라이언트, 또는 이전에 설치했던 VPN이 남긴 네트워크 확장입니다. 더 파고들기 전에 시스템 설정에서 오래된 VPN 구성 프로파일을 먼저 제거하세요. 남아 있는 프로파일이 이런 문제의 상당수를 차지합니다.

자주 묻는 질문

이 문제로 내 브라우징 기록이 노출된 건가요?

아닙니다. 유출되는 것은 IP 주소, 즉 콘텐츠가 아니라 네트워크 신원입니다. 브라우징의 암호화된 내용은 그대로 암호화된 상태이고, 이미 사용자를 식별하려 시도하던 사이트에 접속했다는 사실 이상으로 어떤 페이지를 읽었는지는 이 경로들로 드러나지 않습니다. 계정 자격 증명은 관련이 없고, 침해된 계정도 없습니다.

이 문제 때문에 패스키 사용을 중단해야 하나요?

아닙니다. 패스키는 여전히 비밀번호보다 상당히 안전합니다. 피싱에 강하고 재사용 가능한 정보가 네트워크를 건너지 않습니다. 이 유출은 패스키 인증 자체의 약점이 아니라, 세리머니를 뒷받침하는 네트워크 요청이 Private Relay를 우회한다는 문제입니다. 패스키를 포기하는 것은 실질적인 보안 이득을 미미한 프라이버시 이득과 맞바꾸는 일입니다.

이 문제에 CVE가 부여되었나요?

세 경로 중 어느 것에도 CVE가 보고된 바 없습니다. 조사 결과는 2026년 8월 4일 Mysk와 Haj Bakry가 공개했고 다음 날 언론이 보도했습니다. Apple은 404 Media에 조사 중이라고 밝혔습니다. 이 문제에 특정 CVE 식별자를 인용하는 자료가 있다면 경계하세요. 공개된 것이 없기 때문입니다.

Mac에서 Chrome이나 Firefox를 쓰면 해결되나요?

사람들이 생각하는 방식으로는 아닙니다. 그 브라우저들은 자체 엔진을 쓰므로 이 WebKit 고유의 경로들에 영향을 받지 않지만, Private Relay는 애초에 그들의 트래픽을 프록시한 적이 없습니다. 브라우저를 바꾸는 것은 릴레이 뒤로 들어가는 것이 아니라 릴레이에서 완전히 빠져나오는 것입니다. 모든 것을 아우르는 VPN과 함께 쓸 때만 도움이 됩니다.

iPhone과 Mac에서 상황이 다른가요?

네. iOS에서는 대부분의 관할권이 모든 브라우저에 WebKit 사용을 요구하므로, 기기의 모든 브라우저가 동일한 노출을 공유하고 앱을 바꿔도 달라지는 게 없습니다. Mac에서는 다른 브라우저들이 자체 엔진을 탑재하므로 Safari와 WebKit을 임베드한 앱만 영향을 받습니다. 경로 자체는 두 플랫폼에서 동일하게 동작합니다.

Apple은 언제 이를 수정하나요?

9to5Mac은 Apple이 연구진에게 보낸 상태 메시지에서 회사가 이 문제를 해결할 계획이며 2026년 가을을 목표로 하고 있음을 시사했다고 보도했습니다. Apple은 404 Media에 조사 중임을 확인한 것 외에 특정 릴리스나 날짜를 공개적으로 약속하지 않았습니다. 현재 사용할 수 있는 수정은 없으며, MacRumors는 이 문제를 WebKit의 동작 방식 자체에 뿌리내린 것으로 설명했습니다.

결론

Mysk와 Haj Bakry의 조사 결과는 실재하고, 잘 문서화되어 있으며, Apple이 좁게 땜질하는 대신 제대로 고칠 가치가 있습니다. 세 개의 별개 WebKit 서브시스템 — 패스키 세리머니를 처리하는 자격 증명 서비스, DNS 프리페치, 그리고 WebTransport — 이 각각 실제 IP 주소를 그것을 찾아 나선 웹사이트 앞에 내놓을 수 있으며, 그동안 Private Relay는 활성화되었다고 표시하며 그 자리에 있습니다. 패스키 경로가 셋 중 가장 날카로운 이유는 사이트가 세리머니를 완료할 필요 없이 시작하기만 하면 되고, 사용자에게서는 아무것도 필요하지 않기 때문입니다.

이것이 아닌 것: 침해도, 계정 탈취도, 경보를 울릴 이유도 아닙니다. Private Relay는 애초에 VPN이 아니었고 그렇다고 주장한 적도 없으며, 막으려던 관찰자들 — ISP, 지금 앉아 있는 네트워크, 사이트가 능동적으로 탐지하도록 만들 능력 없이 트래픽만 지켜보는 수동적 감시자 — 에 대해서는 여전히 제 역할을 합니다. 그 보호는 온전하며, 기능을 끄는 것은 아무런 대가 없이 그것을 내주는 일일 뿐입니다.

이것인 것: 이 기능의 적용 범위가 대부분의 사람이 가진 개념 모형보다 좁으며, 새로운 플랫폼 기능이 반드시 존중해야 하는 어느 지점에서도 그 경계가 강제되지 않는다는 명확한 실증입니다. 위협 모델에 누군가가 내 IP 주소를 알아내는 상황이 실제로 포함된다면, 답은 언제나 그 일을 위해 만들어진 도구였고 그에 따르는 신뢰의 대가를 이해하고 받아들이는 것이었습니다. 그렇지 않다면 이 사실을 기억해 두고, 릴레이는 켜 두고, 궁금하다면 테스트를 돌려 보고, 가을에 무엇이 나오는지 지켜보세요.

관련 읽을거리: Mac 보안 및 개인정보 보호 가이드 2026