프라이빗 릴레이는 애플조차 다 못 보게 설계됐습니다 — «이중 중계»가 하는 일

iCloud+에 가입하면 «프라이빗 릴레이»라는 기능이 딸려 옵니다. 사파리로 인터넷을 쓸 때 내 IP 주소를 숨겨 준다는 설명은 많이 봤을 텐데, 정확히 «누구로부터» 숨겨 주는지는 잘 알려져 있지 않습니다. 답은 놀랍게도 애플 자신도 포함됩니다.

중계를 «한 번»이 아니라 «두 번» 거칩니다

프라이빗 릴레이를 켜면, 인터넷 요청은 곧장 목적지로 가지 않고 서로 다른 두 개의 중계 서버를 순서대로 거칩니다. 애플 공식 설명에 따르면 이 두 중계는 서로 다른 조직이 운영합니다 — 첫 번째는 애플이, 두 번째는 애플과 무관한 제3자 콘텐츠 제공업체가 맡습니다.

⇒ ★한 회사가 전 과정을 처리하면, 그 회사는 «누가»(사용자의 IP) «어디로»(방문 사이트) 가는지를 둘 다 알 수 있습니다. 프라이빗 릴레이는 이 둘을 애초에 한 조직이 동시에 볼 수 없도록 중계 지점 자체를 쪼갠 것입니다.

1차 중계(애플) — «누구인지는 알지만 어디 가는지는 모른다»

첫 번째 중계 서버는 애플이 운영합니다. 여기서는 사용자의 실제 IP 주소가 통신사와 이 중계 서버에는 보입니다. 다만 이 단계에서 목적지 주소(DNS 기록)는 암호화돼 있어, 애플의 1차 중계도 «이 사람이 어느 사이트로 가려는지»는 읽을 수 없습니다.

⇒ ★즉 애플의 1차 중계가 아는 것은 «이 IP를 가진 사람이 어딘가로 가려 한다»까지입니다. 목적지가 뉴스 사이트인지, 병원 예약 사이트인지는 이 단계에서 가려집니다.

2차 중계(제3자) — «어디로 가는지는 알지만 누구인지는 모른다»

두 번째 중계는 애플이 아닌 별도 회사가 운영합니다. 이 단계에서는 반대로 목적지 사이트 주소가 복호화돼 실제 접속이 이뤄지지만, 그 대신 임시 IP 주소가 새로 발급됩니다 — 사용자의 진짜 IP는 이 두 번째 중계에 아예 전달되지 않습니다.

⇒ ★그 결과 목적지 사이트 입장에서 보이는 접속자는 «임시 IP를 가진 누군가»일 뿐, 실제 사용자가 누구인지는 알 수 없습니다. 애플의 공식 설명을 그대로 옮기면 “no single party — not even Apple — can see both who you are and what sites you’re visiting(어느 한쪽도 — 애플조차도 — 당신이 누구인지와 어느 사이트에 가는지를 동시에 알 수 없다)”는 것이 이 구조의 목표입니다.

⇒ ⚠️2차 중계를 실제로 맡는 구체적인 회사 이름까지는 이번 조사에서 애플 공식 문서로 확인하지 못했습니다. 업계에는 여러 대형 콘텐츠 전송망(CDN) 사업자가 이 역할을 나눠 맡는 것으로 알려져 있지만, 이 부분은 애플이 특정해 공개하지 않아 본문에서 회사명을 단정하지 않았습니다.

사파리만의 이야기가 아닙니다

이중 홉 구조는 사실 프라이빗 릴레이에서만 쓰는 방식이 아닙니다. 애플의 공식 개인정보 보호 문서에 따르면, 메일 앱의 «메일 개인정보 보호» 기능도 발신자가 내 IP나 메일 열람 여부를 추적하지 못하도록 같은 이중 중계 구조를 씁니다. 문서 원문은 “The first knows your IP address, but not any third-party Mail content you receive. The second knows the remote Mail content you receive, but not your IP address(첫 번째 중계는 당신의 IP 주소는 알지만 제3자 메일 콘텐츠는 모르고, 두 번째 중계는 수신한 메일 콘텐츠는 알지만 IP 주소는 모른다)”라고 명시합니다.

⇒ ⚠️다만 이 두 기능(프라이빗 릴레이·메일 개인정보 보호)이 «같은 회사의 서버 인프라를 그대로 공유하는지»는 이번에 대조한 문서들에서 명시적으로 확인하지 못했습니다. 다만 애플이 «이중 홉으로 신원과 콘텐츠·목적지를 분리한다»는 같은 설계 원칙을 사파리와 메일 두 기능에 똑같이 적용하고 있다는 것 자체는 각 기능의 공식 문서로 확인됩니다. 하나의 설계 원칙이 여러 기능에 재사용될 수 있다는 사례로 볼 수 있습니다.

켜져 있다고 다 되는 건 아닙니다

이 기능은 아무 애플 계정에서나 자동으로 작동하지 않습니다. 애플 공식 문서는 프라이빗 릴레이가 iCloud+ 구독의 일부로 제공되며, 모든 국가·지역에서 이용 가능한 것은 아니다라고 명시합니다.

⇒ ⚠️어느 지역에서 지원되고 어느 지역에서 지원되지 않는지 구체적인 목록까지는 이 문서에서 확인하지 못했습니다. 다만 이 조건은 실무적으로 중요합니다 — 이중 홉 구조가 아무리 정교해도, 구독 중이 아니거나 지원되지 않는 지역이라면 이 글에서 설명한 보호는 애초에 작동하지 않습니다. 기능의 «원리»를 아는 것과 «지금 내게 켜져 있는가»를 확인하는 것은 별개의 문제입니다.

실무 적용 — 「한 곳이 전부 안다」는 구조 자체를 바꾸는 법

• ★★신뢰를 «한 조직»에 몰아주지 않고, 필요한 정보를 «쪼개서» 각기 다른 조직에 나눠 주는 설계를 검토하십시오. 프라이빗 릴레이는 감시를 막는 데 «암호화»뿐 아니라 «누가 무엇을 아는지를 구조적으로 분리»하는 방식을 함께 씁니다.
• ★”암호화돼 있다”와 “아무도 못 본다”는 다른 주장입니다. 1차 중계는 IP를 보고, 2차 중계는 목적지를 봅니다 — 각 단계가 «일부만» 알도록 설계된 것이지, 어느 쪽도 아무것도 모르는 것은 아닙니다.
• 확인하지 못한 세부사항(2차 중계 운영사)은 추측으로 채우지 말고 그대로 밝히십시오. 구조의 «원리»를 정확히 설명하는 것과, 모든 세부사항을 알아내는 것은 다른 문제입니다.

정리하면

• 프라이빗 릴레이는 인터넷 요청을 애플이 운영하는 1차 중계와 제3자가 운영하는 2차 중계, 두 단계로 나눠 보냅니다.
• 1차 중계는 사용자의 IP는 보지만 목적지는 암호화돼 못 보고, 2차 중계는 목적지는 보지만 임시 IP만 받아 사용자가 누구인지는 모릅니다.
• ⇒ 이렇게 정보를 쪼갠 결과, 애플조차도 «누가 어디로 가는지»를 동시에 파악할 수 없도록 설계돼 있습니다.

본 콘텐츠는 애플 공식 지원 문서(About iCloud Private Relay)와 애플 공식 법무/개인정보 문서(Mail Privacy Protection & Privacy)를 정리한 해설입니다. 2차 중계를 실제로 운영하는 구체적 협력사명, DNS 암호화의 세부 프로토콜, 국가·지역별 제한 사항까지는 이번 조사 범위 밖이라 다루지 않았습니다. 최종 확인일: 2026-09-22.

작성: Inkpipes 편집팀 — 「감추는 방법」보다 「누가 무엇을 알 수 있는가를 애초에 나누는 방법」에 주목해 읽었습니다.

참고

• Apple Support, 「About iCloud Private Relay」
• Apple, 「Mail Privacy Protection & Privacy」