애플이 릴레이 이메일 도메인을 변경합니다 — 그리고 절반은 철회했습니다

Sign in with Apple 주소는 올해 하반기 private.icloud.com으로 이전됩니다. Hide My Email은 애플이 방침을 철회하면서 icloud.com에 그대로 남습니다. 그 이유를 설명합니다.

2026년 8월 24일, 애플은 "Sign in with Apple의 새 도메인 안내"라는 평범한 제목의 개발자 노트를 게시했습니다. 이 노트에는 진짜로 흥미로운 문장이 하나 담겨 있는데, 새 도메인에 관한 내용은 아닙니다.

충분한 검토와 커뮤니티 피드백 반영을 거친 결과, iCloud+ Hide My Email 주소는 icloud.com에 그대로 유지됩니다.

이는 애플이 10주 전에 발표했던 결정을 뒤집은 것입니다. 그리고 이 번복의 이유는 대부분의 사람들이 이런 프라이버시 기능의 실제 작동 방식에 대해 잘못 알고 있는 부분을 잘 보여줍니다. 이메일 별칭에게는 식별 가능해지는 것 자체가 실패 조건입니다.

핵심 요약

Sign in with Apple 릴레이 주소가 이전됩니다. privaterelay.appleid.com에서 private.icloud.com으로, 올해 하반기부터 적용됩니다.
iCloud+ Hide My Email 주소는 그대로 유지됩니다. icloud.com에 남습니다. 애플은 6월에 이전을 계획했다가 8월에 이를 취소했습니다.
이미 쓰고 있는 것은 아무것도 깨지지 않습니다. 기존 도메인의 주소는 계속 작동하고 계속 전달됩니다.
번복의 이유는 전용 도메인이 곧 차단 목록 항목이 되기 때문입니다. 사이트는 도메인 전체를 거부할 수 있습니다. 하지만 icloud.com을 거부하려면 실제 iCloud 사용자 전체를 거부해야 합니다.
이 변화를 노린 피싱을 예상하십시오. 받은편지함에 낯선 새 애플 도메인이 나타나는 것은 공격자들이 캠페인을 벌이기 딱 좋은 종류의 변화입니다.

"Private"라는 이름을 공유하는 서로 다른 세 가지

먼저 이 세 가지를 풀어서 정리할 필요가 있습니다. 6월 계획이 직관적으로 타당해 보였던 것은 이 중 두 가지를 혼동했을 때뿐이며, 그 계획이 잘못됐던 이유는 바로 이 둘이 같은 제품이 아니기 때문입니다.

앱이나 웹사이트에서 "Sign in with Apple"을 탭하고 주소 숨기기를 선택하면, 애플은 해당 개발자 전용의 릴레이 주소를 생성하여 그 개발자가 보낸 메일을 여러분에게 전달합니다. 모든 Apple 계정에서 무료로 제공됩니다.

현재 도메인: @privaterelay.appleid.com
새 도메인: @private.icloud.com, 올해 하반기부터 새로 발급되는 주소에 적용
Mac에서 관리 위치: 시스템 설정 → [이름] → Sign in with Apple

2. iCloud+ Hide My Email

유료 iCloud+ 기능입니다. 뉴스레터, 양식, 쇼핑몰 등 무엇에든 자유롭게 사용할 별칭을 직접 생성하며, 라벨과 메모를 붙여 각 별칭을 무엇에 썼는지 기억할 수 있습니다. 어떤 로그인 흐름에도 묶여 있지 않습니다.

도메인: @icloud.com — 변경 없음
Mac에서 관리 위치: 시스템 설정 → [이름] → iCloud → Hide My Email
Safari와 메일 앱에서도 주소 입력란을 클릭하고 Hide My Email을 선택하면 바로 사용 가능

3. iCloud Private Relay

이메일과는 전혀 무관합니다. Safari 브라우징과 일부 암호화되지 않은 트래픽을 위한 2홉 릴레이로, 어느 한쪽도 "누가" "무엇을" 보고 있는지를 동시에 알 수 없도록 설계됐습니다. "릴레이"라는 단어만 공유할 뿐 그 외에는 아무 공통점이 없습니다. 이 기능의 실제 실패 사례는 iCloud Private Relay가 실제 IP 주소를 유출하는 문제에서 다룬 바 있습니다.

이 혼란은 독자의 잘못이 아닙니다. 앞의 두 가지 모두 "Hide My Email"이라는 이름의 버튼을 내세우기 때문입니다. 하나는 privaterelay.appleid.com 주소를, 다른 하나는 icloud.com 주소를 주는데, 애플은 이 둘의 구분을 크게 강조한 적이 없습니다. 이 공유된 이름표야말로 6월에 도메인 통합이 깔끔한 아이디어처럼 보였던 거의 확실한 이유입니다.

애플이 두 발표에서 각각 밝힌 내용

두 발표를 나란히 놓고 읽어볼 가치가 있습니다. 변경 내용이 정확하기 때문입니다.

2026년 6월 15일:

올여름 하반기, 애플은 Sign in with Apple과 iCloud+ Hide My Email에서 사용하는 이메일 도메인을 하나의 공유 도메인, private.icloud.com으로 통합할 예정입니다.

두 기능에서 새로 생성되는 주소는 모두 새 도메인으로 발급됩니다. 예를 들면:

기존에 privaterelay.appleid.com으로 발급되던 Sign in with Apple 주소는 private.icloud.com으로 발급됩니다.

기존에 icloud.com으로 발급되던 iCloud+ Hide My Email 주소는 private.icloud.com으로 발급됩니다.

기존 도메인의 기존 주소는 중단 없이 계속 작동하며 사용자에게 메일을 계속 전달합니다.

2026년 8월 24일:

올해 하반기부터, 기존에 privaterelay.appleid.com으로 발급되던 새로운 Sign in with Apple 주소는 private.icloud.com으로 발급됩니다. privaterelay.appleid.com의 기존 주소는 중단 없이 계속 작동하며 사용자에게 메일을 계속 전달합니다.

충분한 검토와 커뮤니티 피드백 반영을 거친 결과, iCloud+ Hide My Email 주소는 icloud.com에 그대로 유지됩니다.

두 발표 사이에는 두 가지 변화가 있습니다. Hide My Email이 이전 대상에서 빠졌다는 점, 그리고 일정이 "올여름 하반기"에서 "올해 하반기부터"로 바뀌었다는 점입니다 — 원래 일정은 이미 지나버렸으므로, 이를 기준으로 계획을 세우고 있다면 참고할 필요가 있습니다.

Hide My Email을 icloud.com에 남긴 것이 옳은 판단인 이유

여기 그 메커니즘이 있으며, 이는 모든 별칭 서비스에 일반적으로 적용되는 원리이므로 이해해둘 가치가 있습니다.

이메일 별칭은 수신 측이 그것을 별칭이라고 저렴하게 판별할 수 없을 때만 여러분을 보호합니다. 어떤 서비스가 별칭 주소를 식별할 수 있게 되는 순간, 그 서비스는 이를 거부할 수 있습니다 — 그리고 서비스 입장에서는 거부할 강한 동기가 있습니다. 별칭 사용자는 재식별할 수 없고, 데이터 브로커의 기록과 대조할 수 없으며, 주소를 폐기해버리면 계속 연락할 수도 없는 고객이기 때문입니다.

존 그루버는 이 번복이 발표됐을 때 사용자 입장을 직설적으로 표현했습니다.

우리는 이런 식으로 숨겨진 이메일 주소를, 정작 그 주소를 차단하고 싶어 하고 "진짜" 주소를 쓰도록 강요하려는 사이트에서 종종 사용하고 싶어 합니다

전용 private.icloud.com 도메인은 하나의 문자열에 불과합니다. 어떤 가입 양식이든 검증 코드 한 줄로 이를 거부할 수 있습니다. 그 한 줄을 추가한 사이트에서는 애플이 그동안 발급한 모든 별칭이 한꺼번에 무용지물이 될 것입니다.

icloud.com은 그런 식으로 다룰 수 없습니다. 수억 명이 일상적인 개인 이메일에 사용하는 도메인이기 때문입니다. 별칭을 막기 위해 icloud.com을 차단하는 서비스는 실제 고객 상당수를 함께 차단하게 됩니다. Hide My Email의 보호력은 암호화에서 나오는 것이 아니라, 별칭이 진짜 주소들 사이에 숨어 있다는 사실에서 나옵니다. 별도 도메인으로 옮기는 것은 그 숨을 곳을 없애버리는 일이었을 것입니다.

애플이 내린 결론도 바로 이것으로 보이며, 이는 옳은 결론입니다. 또한 이미 발표된 계획이 기술적인 이유가 아니라 프라이버시 논리로 철회된 흔치 않은 사례이기도 합니다.

여기까지 논리를 따라가면 애플이 Sign in with Apple 사용자를 노출된 상태로 방치했다고 결론짓기 쉽습니다. 그러나 이는 정확하지 않으며, 그 이유를 정확히 짚어볼 가치가 있습니다.

Sign in with Apple의 릴레이 주소는 애초부터 명백히 식별 가능한 전용 도메인 위에 있었습니다. privaterelay.appleid.com은 스스로를 드러냅니다. 이를 거부하고 싶은 서비스라면 2019년부터 이미 그럴 수 있었습니다. private.icloud.com으로의 이전은 이 축에서는 수평 이동일 뿐입니다 — 식별 가능한 도메인이 새롭게 식별 가능해진 것이 아니라, 그저 다른 식별 가능한 도메인으로 바뀐 것입니다.

이 노출이 상대적으로 덜 중요한 구조적인 이유도 있습니다. Sign in with Apple 릴레이 주소는 양식에 직접 입력하는 것이 아닙니다. 사이트가 스스로 제공하기로 선택한 인증 흐름의 일부로 발급됩니다. 릴레이 주소를 원하지 않는 사이트는 애초에 Sign in with Apple을 도입하지 않습니다. Hide My Email을 취약하게 만드는 차단 시나리오가 여기서는 사실상 발생하지 않습니다.

그러니 솔직하게 정리하면 이렇습니다. 애플은 보호가 필요했던 기능은 지키고, 그렇지 않은 기능은 이전시켰습니다. 6월 계획은 둘 중 하나에 해를 끼쳤을 것이고, 애플은 그것을 알아챘습니다.

애플의 프라이빗 이메일 시스템 비교

실제로 여러분에게 달라지는 것

대부분의 사람들에게는 거의 달라지는 것이 없습니다 — 다만 놀라지 않으려면 세부 사항을 미리 알아두는 것이 좋습니다.

기존 주소는 바뀌지 않습니다. 이미 갖고 있는 모든 privaterelay.appleid.com 주소는 계속 작동하고 계속 전달됩니다. 애플은 두 발표 모두에서 이를 명시적으로 밝혔습니다. 어디서도 업데이트하거나, 재등록하거나, 계정을 이전할 필요가 없습니다.

새로운 로그인에는 처음 보는 도메인이 붙습니다. 변경 이후 새로운 서비스에서 Sign in with Apple을 사용하면 private.icloud.com으로 주소가 발급됩니다. 어떤 별칭을 어떤 서비스에 썼는지 기록해두고 있다면, 앞으로는 그 목록에 두 개의 도메인이 함께 등장하게 될 것입니다.

일부 사이트는 새 도메인을 거부할 것입니다. 가입 검증, 허용 목록, 남용 방지 규칙에 privaterelay.appleid.com을 하드코딩해 둔 서비스는 업데이트하기 전까지 private.icloud.com을 인식하지 못합니다. 애플의 노트는 개발자들에게 두 도메인을 모두 허용하라고 명시적으로 요청하고 있지만, 모두가 이를 읽지는 않을 것입니다.

회사 메일 필터링이 메시지를 보류할 수 있습니다. 업무와 관련된 곳에서 Sign in with Apple을 사용하고 있고, 조직에서 발신자 또는 수신자 도메인 기준으로 필터링한다면, 완전히 새로운 도메인이 격리함으로 분류될 수 있습니다.

피싱의 틈새

이 부분이야말로 실질적인 보안 결과를 낳는 대목이며, 아무도 다루지 않는 부분이기도 합니다.

애플은 이 내용을 개발자 대상으로 발표했습니다. 일반 사용자를 향한 공지도, 설정 앱 내 알림도, 사용자에게 보내는 이메일도 없습니다. 대부분의 사람들은 private.icloud.com을 발신자 란에서, 계정 설정 페이지에서, 또는 비밀번호 관리자 항목에서 아무 예고 없이 처음 마주하게 될 것입니다.

실제로는 애플 소유이지만 낯선 도메인이, 공개적으로 알려진 전환 기간 중에 아무 예고도 없이 나타나는 상황은 피싱 캠페인에 거의 이상적인 조건입니다. 그런 메시지는 저절로 써집니다. "귀하의 애플 릴레이 주소가 이전 중입니다. 로그인했던 서비스에 대한 접근 권한을 잃지 않으려면 계정을 확인하세요."

이번 변화와 무관하게 항상 유효한 원칙 몇 가지:

애플은 이번 이전을 위해 여러분에게 아무것도 요구하지 않습니다. 릴레이 주소를 확인, 검증, 이전, 재인증하라고 요청하는 메시지는 모두 사기입니다. 사용자가 해야 할 단계는 없습니다. 애초에 그런 단계 자체가 존재하지 않기 때문입니다.
Apple 계정 관련 이메일의 링크는 절대 클릭하지 마십시오. 직접 시스템 설정을 열어 확인하십시오. 변경이 실제로 있었다면 그곳에서 확인할 수 있습니다.
링크가 실제로 어디로 연결되는지 확인하십시오. private.icloud.com은 애플이 맞습니다. private-icloud.com, privateicloud.com, private.icloud.com.example.net, icloud-private.com은 애플이 아닙니다. 공격자들은 정확히 이런 순간을 노려 유사 도메인을 등록해둡니다.
본인이 직접 시작하지 않은 비밀번호 입력창이야말로 경고 신호입니다. 정상적인 macOS 비밀번호 입력창은 방금 취한 행동에 뒤이어 나타납니다. 이것이 얼마나 그럴듯하게 위조될 수 있는지는 가짜 Mac 충돌 보고서 비밀번호 입력창에서 다룬 바 있습니다.

더 폭넓은 보안 강화를 원한다면, Mac 보안 및 개인정보 보호 가이드에서 관련 설정들을 다루고 있습니다.

실제로 무엇을 갖고 있는지 점검하기

지금이 확인해보기 좋은 시점입니다. 대부분의 사람들이 한 번도 확인해본 적이 없기 때문입니다.

Sign in with Apple을 사용 중인 앱 확인:

Mac에서 시스템 설정을 열고, 사이드바 상단의 이름을 클릭한 다음 Sign in with Apple을 선택하십시오. 이를 사용한 모든 앱과 사이트 목록이 표시되며, 각각에 대해 개별적으로 Sign in with Apple 사용을 중단할 수 있습니다.

무언가를 해제하기 전에 이 목록을 꼼꼼히 읽으십시오. 특정 서비스에 대해 Sign in with Apple을 끄면 릴레이 주소가 끊어지며, 이는 곧 그 서비스가 더 이상 여러분에게 연락할 수 없게 된다는 뜻입니다 — 비밀번호 재설정도 포함됩니다. 해당 서비스에 다른 로그인 수단을 등록해두지 않았다면 스스로 계정에서 잠길 수 있습니다. 먼저 대체 로그인 방법을 설정해두십시오.

존재하는 Hide My Email 별칭 확인:

시스템 설정 → [이름] → iCloud → Hide My Email. 각 항목에는 라벨, 메모, 전달 대상 주소가 표시됩니다. 더 이상 원하지 않는 별칭은 비활성화할 수 있으며, 이렇게 하면 전달은 중단되지만 그 별칭이 무엇을 위한 것이었는지에 대한 기록은 삭제되지 않습니다.

메일이 전달되는 위치:

같은 화면입니다. Apple 계정에 여러 개인 주소가 등록되어 있다면, 그중 하나가 모든 별칭의 전달 대상으로 지정되어 있습니다. 그 주소를 여전히 확인하고 있는지 점검하십시오 — 더 이상 확인하지 않는 전달 주소는 계정 복구 메시지가 필요한 순간에야 드러나는 조용한 실패 지점입니다.

점검하는 김에 해두면 좋은 두 가지

별칭에 라벨을 제대로 붙이십시오. 메모 필드가 존재하는 이유는 2년 뒤에도 그 별칭이 무엇을 위한 것이었는지 알 수 있게 하기 위함입니다. 라벨이 없는 별칭은 비활성화하기가 두려워지는 주소가 됩니다.

복구 경로가 릴레이에 의존하지 않는지 확인하십시오. 중요한 계정의 유일한 연락처 주소가 Sign in with Apple 릴레이이고, 이후 그 앱의 접근 권한을 해제하면 해당 계정의 복구 수단도 함께 사라집니다. 나중에 끌 수도 있는 릴레이를 거치지 않는 경로를 최소 하나는 남겨두십시오.

개발자와 관리자를 위한 안내

이메일 주소를 다루는 무언가를 운영하고 있다면, 여기 구체적으로 해야 할 일이 있습니다. 애플의 요청은 다음과 같습니다.

Sign in with Apple을 사용하는 앱이나 웹사이트를 운영하는 개발자는 자신의 계정 시스템, 이메일 검증 로직, 허용 목록이 기존 privaterelay.appleid.com 도메인뿐 아니라 새로운 private.icloud.com 도메인의 주소도 함께 허용하도록 해야 합니다.

구체적으로는 다음과 같습니다.

두 도메인을 모두 허용하십시오. 대체가 아니라 병행입니다. privaterelay.appleid.com의 기존 주소는 계속 무기한 유효합니다.
하드코딩된 문자열을 찾으십시오. 코드베이스와 설정 파일에서 privaterelay.appleid.com을 검색하십시오. 검증 정규식, 부정 방지 규칙, 분석 세그먼트, 전달성 허용 목록, 지원 도구 등에서 발견될 수 있습니다.
이메일 서비스 제공업체의 규칙을 확인하십시오. 도메인 기반 라우팅, 억제 목록, 평판 규칙은 여러분의 저장소 밖에 존재하며 가장 놓치기 쉬운 부분입니다.
private.icloud.com에 새로운 차단 규칙을 만들지 마십시오. 자사 사용자에게 적대적일 뿐 아니라, 가입 단계에서 거부한 주소는 곧 확보하지 못한 고객이며, Sign in with Apple은 여러분의 앱이 스스로 채택하기로 한 인증 수단입니다.
전체 흐름을 테스트하십시오. 가입, 인증 메일, 비밀번호 재설정, 계정 복구까지 모두 포함됩니다. 가입 시점에는 주소를 허용하면서 비밀번호 재설정 시점에는 거부하는 검증 규칙은 정말 골치 아픈 버그이며, 이런 실패는 흔히 이런 형태로 나타납니다.

관리자를 위한 안내: 수신 메일을 도메인 기준으로 필터링하고 있다면, 사용자들이 메시지 누락을 신고하기 시작한 다음이 아니라 그 전에, privaterelay.appleid.com이 이미 올라가 있는 목록에 private.icloud.com도 추가해두십시오.

릴레이가 실제로 숨기는 것

정확히 짚어볼 가치가 있습니다. 사람들이 이 기능들에 대한 신뢰를, 실제 기능이 미치는 범위보다 더 멀리까지 확장하는 경향이 있기 때문입니다.

개발자가 얻지 못하는 것: 여러분의 실제 이메일 주소입니다. 그들은 릴레이 주소를 받고 그 주소로 메일을 보낼 수 있으며, 애플이 이를 전달합니다. 접근 권한을 해제하면 릴레이가 중단되고, 개발자가 갖고 있던 여러분의 주소는 죽은 주소가 됩니다.

개발자가 얻는 것:

해당 앱 내에서 여러분을 나타내는 고정된 식별자. Sign in with Apple은 세션과 기기를 넘나들며 유지되는 개발자별 사용자 식별자를 발급하며, 이 덕분에 개발자는 여러분을 재방문 사용자로 인식할 수 있습니다. 이 식별자는 해당 개발자에게만 한정됩니다 — 같은 Apple 계정이라도 다른 개발자에게는 다른 식별자가 생성되므로, 두 앱이 이를 근거로 기록을 결합할 수 없습니다.
이름 — 공유하기로 선택한 경우에 한하며, 로그인 시점에 직접 수정할 수 있습니다.
이후 여러분이 직접 알려주는 모든 정보. 릴레이는 주소만 가려줄 뿐 행동은 가려주지 않습니다. 프로필 입력란에 실명을 입력하면 그 즉시 넘겨준 것입니다.
해당 앱의 분석 도구가 수집하는 모든 것. 기기 핑거프린팅, IP 주소, 광고 식별자는 이 기능의 범위를 완전히 벗어납니다.

애플이 얻는 것: 전달을 위해 메일이 애플의 서버를 거쳐 갑니다. 애플은 전달에 필요한 범위를 넘어 내용을 읽거나 보관하지 않는다고 밝히고 있지만, 이 릴레이는 구조상 애플을 우회하는 경로가 아니라 애플을 거치는 경로입니다.

가장 깔끔한 이해 방식은 이렇습니다. 릴레이 주소는 익명성이 아니라 해지 가능한 통로입니다. "이 회사가 내 주소를 데이터 브로커에 팔아넘겨서 이제 메일을 막을 수 없다"는 문제는 해결해줍니다. "이 회사가 내가 누구인지 알고 있다"는 문제는 해결해주지 않습니다.

이는 정말로 해결할 가치가 있는 문제이며, 해지 가능성이야말로 저평가된 절반입니다 — 다른 어디에서도 주소를 바꾸지 않은 채 특정 회사 하나만 연락 수단을 끊어버릴 수 있다는 것은, 일반적인 메일함이 한 번도 제공한 적 없는 능력입니다.

타사 별칭 서비스와의 비교

애플만이 유일한 선택지는 아니며, 비교해보면 차단 가능성이라는 논점이 더 선명해집니다.

전용 별칭 서비스인 SimpleLogin, AnonAddy 등은 대개 다른 모든 사용자와 공유하는 도메인 위에서 무제한 별칭을 제공합니다. 그 공유 도메인이야말로 6월 계획이 Hide My Email에 만들어냈을 차단 목록의 표적 그 자체이며, 이런 서비스들이 가입 양식에서 널리 거부되는 이유이기도 합니다. 더 나은 서비스는 자체 도메인을 연결할 수 있게 해주는데, 이는 차단 불가능성을 되찾아주는 대신 도메인을 직접 등록하고 비용을 지불해야 하며, 누군가 그 도메인을 상관관계로 추적하면 오롯이 여러분만의 것으로 드러난다는 대가가 따릅니다.

Fastmail을 비롯한 비슷한 제공업체들은 여러분 자신의 도메인 또는 자사 도메인 위에서 마스킹된 주소를 제공하며, 같은 트레이드오프를 안고 있습니다.

애플의 iCloud+ Hide My Email이 특이한 이유는 정확히 이번에 지켜낸 그 부분 때문입니다. 이 별칭들은 수억 명의 일반 사용자와 함께 icloud.com 위에서 살아갑니다. 자신의 주소가 진짜 주소와 구분되지 않는 유일한 주요 별칭 서비스입니다. 이는 어떤 경쟁자도 그만한 규모의 소비자용 메일 도메인을 운영하지 않기 때문에 복제할 수 없는 구조적 우위입니다.

한계도 분명 존재합니다. 애플의 별칭은 하나의 주소로만 전달되고, Apple 기기의 Apple 메일 앱 밖에서는 별칭으로 보내기 기능이 없으며, 자체 도메인을 사용할 수 없습니다. 세밀한 라우팅과 임의의 클라이언트에서 답장을 원한다면 전용 서비스가 더 많은 기능을 제공합니다. 그러나 어디서든 그냥 받아들여지는 별칭을 원한다면, 애플의 선택지가 가장 강력하며 — 이번 일로 그 지위는 그대로 유지됐습니다.

짧은 역사, 그리고 기존 도메인이 늘 어색했던 이유

Sign in with Apple은 2019년에 출시됐으며, 애플의 App Store 심사 가이드라인은 타사 로그인 옵션을 제공하는 앱이라면 이것도 함께 제공하도록 요구했습니다 — 그래서 점진적이 아니라 거의 동시에 모든 곳에서 등장했습니다. 프라이빗 이메일 릴레이는 이 기능의 가장 두드러진 특징이었습니다. 다른 로그인 제공업체들은 개발자에게 여러분의 주소를 넘겨주는 반면, 애플은 그렇게 하지 않겠다고 나선 것입니다.

대신 발급된 주소는 @privaterelay.appleid.com이었습니다. 발음하기도 번거롭고, 대부분의 사용자가 다른 곳에서는 접해본 적 없는 도메인 위에 있으며, 스스로 자신의 정체를 드러냅니다. 애플 입장에서는 나름 타당했습니다 — appleid.com은 계정 인프라가 자리한 곳이었기 때문입니다 — 하지만 사용자 입장에서는 늘 피싱 키트가 지어낼 법한 무언가처럼 살짝 보였습니다.

private.icloud.com으로 통합하면 이 문제가 해결됩니다. icloud.com은 일반 사람들도 알아보는 도메인이며, 그 하위 도메인은 privaterelay.appleid.com이 결코 해내지 못했던 방식으로 정당해 보입니다. 로그인 릴레이 입장에서는 명백한 개선이며, 이번 작업 전체의 근거도 아마 여기에 있을 것입니다.

그런데 6월 계획은 이 논리를 지나치게 넓게 적용했습니다. 통합은 이미 눈에 띄던 주소에는 유익했지만, 눈에 띄지 않는다는 데서 가치가 나오는 주소에는 명백히 해로웠습니다. 이 수정이 10주가 걸렸고 공개적인 반발까지 필요했다는 사실은, 한 제품을 개선하는 변화가 이름과 버튼을 공유하는 다른 제품을 조용히 훼손할 수 있다는 것을 보여주는 작은 사례 연구입니다.

자주 발생하는 문제 해결

웹사이트가 새 Apple 릴레이 주소를 유효하지 않다며 거부합니다

문제: 해당 사이트의 이메일 검증 로직이 아직 private.icloud.com을 인식하지 못합니다.

해결 방법: 해당 사이트에 신고하십시오 — 이는 그쪽의 버그이며 애플은 이미 해결책을 공개했습니다. 그동안은 icloud.com 위의 iCloud+ Hide My Email 별칭을 사용하면 됩니다. 이 도메인은 변경되지 않으며 일반 iCloud 주소와 구분되지 않기 때문입니다. 이것이 바로 애플이 지켜낸 그 특성입니다.

Apple로 로그인한 서비스에서 메일이 더 이상 오지 않습니다

문제: 여러 가능성이 있습니다. Apple 계정의 전달 주소를 더 이상 확인하지 않고 있거나, 해당 앱에 대해 Sign in with Apple을 해제했거나, 메일 제공업체가 낯선 도메인을 필터링하고 있을 수 있습니다.

해결 방법: 시스템 설정 → [이름] → Sign in with Apple에서 해당 앱이 여전히 활성 상태인지 확인한 다음, Hide My Email에서 전달 주소를 확인하십시오. 이어서 스팸함과 격리함에서 새 도메인이 있는지 확인하십시오.

문제: 접근 권한을 해제하면 릴레이 주소가 무효화되며, 그 주소가 계정의 유일한 연락 수단이었다면 비밀번호 재설정 메일을 보낼 곳이 없어집니다.

해결 방법: 해당 서비스의 지원팀에 직접 연락해 상황을 설명하십시오 — 이는 이미 알려진 상황이며 대부분 수동 처리 경로를 갖고 있습니다. 이런 상황을 피하려면 무언가를 해제하기 전에 대체 로그인 방법을 먼저 등록해두십시오.

Apple 릴레이 주소 변경에 관한 이메일을 받았습니다

문제: 애플은 이 건에 대해 사용자에게 이메일을 보내지 않습니다. 이번 이전은 여러분에게 아무것도 요구하지 않습니다.

해결 방법: 피싱으로 간주하십시오. 클릭하지 마십시오. 걱정되는 부분이 있다면 직접 시스템 설정을 열어 확인하십시오.

설정에서 Hide My Email을 찾을 수 없습니다

문제: 이는 iCloud+ 기능이며 유료 iCloud+ 또는 Apple One 구독이 필요합니다. 구독이 없다면 무료인 Sign in with Apple 릴레이만 이용할 수 있습니다.

해결 방법: 시스템 설정 → [이름] → iCloud에서 구독 상태를 확인하십시오. 구독하지 않았더라도 Sign in with Apple의 주소 숨기기 옵션은 여전히 무료로 작동합니다 — 다만 어디서나 쓸 수 있는 것이 아니라 로그인 흐름에만 한정될 뿐입니다.

자주 묻는 질문

제가 뭔가 해야 하나요?

아니요. 기존 주소는 계속 작동하며, 이번 변경은 새로 발급되는 Sign in with Apple 주소에만 적용됩니다. 사용자가 거쳐야 할 이전 단계는 없으며, 바로 그렇기 때문에 그렇지 않다고 주장하는 메시지는 모두 사기입니다.

기존 privaterelay.appleid.com 주소는 작동을 멈추나요?

아니요. 애플은 두 발표 모두에서 기존 주소가 중단 없이 계속 작동하고 전달된다고 밝히고 있습니다. 애플은 이 주소들에 대한 종료 시점을 밝힌 적이 없습니다.

애플은 왜 Hide My Email에 대한 방침을 바꿨나요?

애플 자신의 표현은 "충분한 검토와 커뮤니티 피드백 반영을 거친 결과"입니다. 그 피드백의 핵심 내용은 전용 도메인이 별칭 주소를 손쉽게 차단 가능하게 만들어 기능 자체를 무력화한다는 것이었습니다. 이를 icloud.com에 유지하면 일반 iCloud 주소와 구분되지 않게 됩니다.

아닙니다. 다만 둘 다 같은 이름의 버튼을 내세웁니다. Hide My Email은 원하는 어떤 목적으로든 직접 만들 수 있는 icloud.com 별칭을 제공하는 유료 iCloud+ 기능입니다. Sign in with Apple의 릴레이는 무료이며 특정 앱에 묶여 있고, private.icloud.com으로 이전되는 대상은 바로 이쪽입니다.

정확히 언제 변경되나요?

애플은 "올해 하반기부터"라고 밝히고 있습니다. 6월 발표에서는 "올여름 하반기"라고 했었으니, 일정은 이미 한 차례 밀린 셈입니다. 구체적인 날짜는 공개되지 않았습니다.

이 변경이 iCloud Private Relay에도 영향을 미치나요?

아니요. iCloud Private Relay는 Safari 브라우징을 위한 네트워크 프라이버시 기능이며, 이름에 같은 단어가 들어가긴 하지만 이메일 주소와는 아무 관련이 없습니다.

중요한 계정은 대신 Hide My Email로 전환해야 하나요?

중요한 계정이라면, 더 유용한 질문은 별칭을 껐을 때도 복구 경로가 살아남는지 여부입니다. 두 시스템 모두 견고합니다. 위험은 둘 다 동일합니다. 별칭이 계정의 유일한 연락 수단이고 나중에 이를 비활성화하면 복구가 어려워집니다. 잃어서는 안 될 계정이라면 반드시 두 번째 경로를 마련해두십시오.

결론

핵심적인 변화는 작으며 여러분에게 아무것도 요구하지 않습니다. 새로운 Sign in with Apple 주소는 private.icloud.com으로 도착하고, 기존 주소는 계속 작동하며, 실제로 해야 할 일이 있는 사람은 어딘가에 도메인 문자열을 하드코딩해둔 개발자들뿐입니다.

기억해둘 가치가 있는 부분은 애플이 철회한 그 부분입니다. 누구나 식별할 수 있는 프라이버시 기능은 프라이버시 기능이 아닙니다 — 그리고 겉보기에는 합리적인 통합처럼 보였던 애플의 6월 계획은, 보호력의 전부가 일반 메일 사이에 섞여 드는 데서 나오는 별칭 시스템에 누구나 걸러낼 수 있는 이름표를 붙이는 결과를 낳았을 것입니다. 그 사실이 공개적으로 발견됐고, 10주 만에 번복됐습니다. 이는 좋은 결과인 동시에, "버튼을 공유하는 이 두 가지를 통합하자"는 설계 본능이 그중 하나가 눈에 띄지 않는 데 의존하고 있을 때는 다시 한번 살펴볼 가치가 있다는 것을 일깨워줍니다.

한편: 애플은 이 건에 대해 여러분에게 이메일을 보내지 않습니다. 이메일을 보내는 사람이 있다면 그는 애플이 아닙니다.