로그인 자체는 성공했지만 새 중계 주소가 계정 생성 단계에서 거부되거나 인증 메일이 사라질 수 있습니다.
이번 주에는 private.icloud.com을 기존 privaterelay.appleid.com과 함께 허용하고, 서버만 바뀌었다면 앱을 무조건 다시 출시하지 마십시오. 클라이언트에 도메인이 하드코딩된 경우에만 수정 후 Xcode 빌드와 TestFlight 회귀를 진행하면 됩니다.
마지막 업데이트: 2026년 8월 30일. Apple Developer News와 Sign in with Apple, Private Email Relay 공식 문서를 기준으로 확인했습니다. Apple은 2026년 8월 24일 업데이트에서 새로 생성되는 중계 주소가 2026년 중 private.icloud.com으로 바뀔 예정이라고 밝혔지만, 전체 적용일은 아직 발표하지 않았습니다. 기존 privaterelay.appleid.com 주소는 계속 전달됩니다. Apple의 최신 공지에서 변경 상태를 다시 확인해야 합니다.
이 글은 Sign in with Apple을 사용하고 데이터베이스나 서버에서 사용자 이메일 도메인을 검사하는 독립 개발자를 위한 글입니다. 인증 코드, 주문 알림, 구독 메일을 중계 주소로 보내는 운영자도 대상입니다. 앱 수정 여부와 원격 Mac 빌드, TestFlight 검증 범위를 정해야 하는 소규모 팀에도 맞습니다.
01먼저 구분해야 할 네 가지 주소와 상태
이번 변경은 이메일 주소 전체를 바꾸는 작업이 아닙니다. 로그인 식별자, 로그인 응답에 포함된 이메일, 받는 주소의 도메인, 메일을 보내는 출처가 서로 다릅니다. 이 구분을 놓치면 정규 표현식 하나를 고친 뒤에도 메일과 계정 복구가 실패합니다.
| 확인 대상 | 이번 변경과의 관계 | 확인할 위치 |
|---|---|---|
| Apple 사용자 식별자 | 계정의 우선 키입니다 | 토큰 검증, 사용자 테이블 |
| 로그인 응답 이메일 | 새 주소 또는 이전 주소가 될 수 있습니다 | 로그인 API, 가입 API |
| 중계 수신 도메인 | private.icloud.com과 privaterelay.appleid.com을 함께 지원해야 합니다 | 정규 표현식, 허용 목록, 위험 제어 |
| 등록된 발신 출처 | Apple에 등록한 발신 주소와 도메인입니다 | 메일 설정, SPF, DKIM |
Apple의 사용자 토큰 검증 문서는 토큰 안의 사용자 정보를 검증하는 절차를 설명합니다. 계정 주 키를 중계 이메일 하나로 정하면 주소 형식이나 반환 값 변화가 계정 중복과 복구 실패로 이어질 수 있습니다. 안정적인 Apple 사용자 식별자를 우선 저장하고 이메일은 연락 수단과 표시 정보로 다루는 편이 안전합니다.
02백엔드 담당자는 두 주소를 동시에 허용해야 합니다
private.icloud.com을 추가할 곳은 가입 API 하나가 아닙니다. 다음 항목을 각각 검색하십시오.
- 이메일 정규 표현식과 도메인 허용 목록
- 데이터베이스의 이메일 형식 제약
- 중복 가입 방지와 계정 병합 규칙
- 위험 제어, 관리자 검색, 고객 지원 도구
- 사용자 정보 수정과 로그인 복구 API
- 데이터 가져오기와 배치 작업
@private.icloud.com만 허용하면 기존 사용자가 막힙니다. 반대로 모든 문자열을 이메일로 받아들이면 오탈자와 공격성 입력이 늘어납니다. 두 중계 도메인과 일반 메일 주소를 분리해 검사하되, Apple 사용자 식별자를 계정 연결의 기준으로 유지해야 합니다.
Sign in with Apple 인증 흐름 공식 문서도 함께 확인하십시오. 로그인 성공, 사용자 저장 성공, 메일 발송 성공은 하나의 성공 상태가 아닙니다. 서버 로그에서는 세 상태를 별도 이벤트로 남기고, 이메일과 사용자 식별자는 반드시 일부를 가려 기록해야 합니다.
private.icloud.com 허용 목록 점검
| 규칙 | 통과 기준 | 실패할 때 생기는 문제 |
|---|---|---|
| 새 중계 주소 | private.icloud.com 허용 | 신규 가입 거부 |
| 이전 중계 주소 | privaterelay.appleid.com 유지 | 기존 사용자 로그인 또는 메일 실패 |
| 일반 이메일 | 기존 정책 유지 | 일반 사용자의 가입 차단 |
| 사용자 연결 | Apple 식별자 우선 | 중복 계정과 잘못된 병합 |
메일 담당자는 받는 주소와 보내는 출처를 나눠서 확인합니다
Private Email Relay는 수신 주소의 도메인만 바꾸는 설정이 아닙니다. 거래 메일, 인증 코드, 결제 알림, 구독 만료 안내, 고객 지원 답변을 실제로 중계 주소로 보내 보십시오. Apple의 Private Email Relay 작동 방식은 등록된 발신 출처와 전달 흐름을 따로 설명합니다.
Apple에 등록한 발신 주소와 도메인, SPF, DKIM 상태도 확인해야 합니다. 여기서 중요한 점은 private.icloud.com을 발신 도메인으로 추가하라는 뜻이 아니라는 점입니다. 이 도메인은 사용자가 받는 중계 주소의 영역입니다. 발신 설정은 Apple에 등록한 출처와 메일 서비스의 인증 상태를 기준으로 검토해야 합니다. Private Email Relay 설정 도움말과 현재 개발자 계정 설정을 대조하십시오.
반송이 발생하면 세 가지를 분리해 기록하십시오.
- 메일 서비스가 발송을 거부했는지
- Apple 중계에서 전달하지 않았는지
- 수신 측 필터가 차단했는지
반송 전문에는 주소와 토큰이 섞일 수 있습니다. 저장 전 주소 일부, 사용자 식별자, 주문 번호를 가리십시오.
04웹과 앱의 규칙을 같은 판정으로 맞춥니다
iOS, macOS, 웹 로그인, 관리자 화면, 고객 지원 도구가 서로 다른 이메일 검사를 쓰는 경우가 많습니다. 새 사용자가 웹에서는 통과하지만 앱에서 다시 가입되거나, 앱에서는 로그인되지만 계정 수정 화면에서 거부되는 식입니다.
다음처럼 공통 판정 모듈을 두는 편이 낫습니다.
- 서버가 Apple 토큰의 서명과 필수 값을 검증합니다.
- Apple 사용자 식별자로 기존 계정을 먼저 찾습니다.
- 이메일은 새 중계 도메인, 이전 중계 도메인, 일반 주소로 분류합니다.
- 기존 계정이 없을 때만 계정 생성 규칙을 적용합니다.
- 화면 표시용 이메일과 연락용 상태를 별도로 저장합니다.
웹 구성이나 서비스 식별자를 함께 수정해야 한다면 웹용 Sign in with Apple 설정 문서를 확인하십시오. 도메인 등록 문제와 이메일 수신 문제를 하나의 원인으로 묶으면 안 됩니다.
05앱을 다시 출시해야 하는 경우와 아닌 경우
서버의 허용 목록, 데이터베이스 제약, 메일 발송 설정만 바뀐다면 보통 앱 재출시는 필요하지 않습니다. 원격 설정으로 도메인을 관리하는 앱도 먼저 서버 배포와 회귀 테스트를 진행하십시오.
다음 조건이면 클라이언트 수정이 필요합니다.
- 앱 번들 안에 이전 도메인이 문자열로 고정되어 있습니다.
- 이메일 도메인에 따라 계정 종류를 로컬에서 판정합니다.
- 계정 병합이나 복구 로직이 앱 안에 있습니다.
- 허용 목록을 앱 업데이트 없이 바꿀 수 없습니다.
Xcode에서 Sign in with Apple 기능을 확인할 때는 Xcode 구성 문서를 기준으로 Bundle ID와 연결 상태를 점검하십시오. 클라이언트 수정이 없다면 형식적인 새 빌드를 만들 이유가 없습니다. 수정이 있다면 격리된 브랜치에서 빌드하고 TestFlight에서 로그인과 계정 연결을 확인해야 합니다.
역할별 작업 경계
| 담당자 | 반드시 검증할 것 | 완료 조건 |
|---|---|---|
| 백엔드 | 두 도메인, 사용자 식별자, 중복 계정 | 기존 계정에 다시 연결됨 |
| 메일 운영 | 인증 코드, 주문 메일, 반송, 발신 출처 | 새 주소와 이전 주소에 전달됨 |
| 앱 개발 | 하드코딩 문자열, 로컬 분류, 병합 | 새 빌드에서 같은 계정으로 로그인됨 |
| 배포 담당 | 빌드, TestFlight 설치, 로그 가림, 되돌리기 | 실패 시 이전 규칙으로 복구 가능 |
새 주소와 이전 주소를 함께 테스트하는 순서
테스트 데이터에는 실제 사용자 메일을 넣지 마십시오. 새 중계 주소를 흉내 낸 데이터, 기존 중계 주소를 흉내 낸 데이터, 일반 메일 주소를 각각 준비합니다. 계정 식별자와 Bundle ID도 테스트용 값으로 바꿉니다.
- [ ] 가입 API가 두 중계 도메인과 일반 주소를 각각 처리하는지 확인합니다.
- [ ] 같은 Apple 사용자 식별자로 다시 로그인했을 때 새 계정을 만들지 확인합니다.
- [ ] 이전 주소를 가진 기존 사용자의 로그인과 계정 복구를 확인합니다.
- [ ] 새 주소로 인증 코드와 거래 메일을 발송하고 반송 결과를 저장합니다.
- [ ] 구독 알림, 고객 지원 회신, 억제 목록 처리를 각각 확인합니다.
- [ ] 웹과 iOS, macOS가 같은 허용 목록과 계정 연결 결과를 내는지 확인합니다.
- [ ] 클라이언트 수정이 있으면 Xcode 빌드와 TestFlight 설치를 완료합니다.
- [ ] 로그인 성공, 계정 저장, 메일 전달, 앱 제출 성공을 각각 로그에서 확인합니다.
- [ ] 규칙을 이전 상태로 되돌리는 스위치와 배포 절차를 시험합니다.
- [ ] 로그와 테스트 산출물에서 이메일, 토큰, 사용자 식별자를 가렸는지 검토합니다.
정규식 통과만으로는 부족합니다. 실제 메일의 전달 결과와 계정 연결 결과가 함께 맞아야 합니다. 특히 기존 사용자에게 새 계정을 만드는 오류는 로그인 화면보다 데이터베이스에서 먼저 발견됩니다.
07이번 주 배포 판단은 이렇게 정리합니다
먼저 서버 검색으로 privaterelay.appleid.com이 등장하는 위치를 찾으십시오. 서버와 설정 파일에서만 발견되면 두 도메인을 허용한 뒤 회귀하고 배포합니다. 앱 바이너리나 로컬 계정 코드에서 발견되면 Xcode 수정 빌드를 준비합니다.
현재 선택지는 세 가지입니다.
- 서버만 수정: 가장 빠릅니다. 앱 심사와 TestFlight 대기 없이 백엔드 회귀를 진행할 수 있습니다.
- 앱까지 수정: 도메인 분류와 병합 로직이 들어간 경우 필요합니다. 빌드, 설치, 로그인, 계정 중복을 모두 확인해야 합니다.
- 배포를 보류: Apple이 전체 적용일이나 규칙을 추가로 발표하면 먼저 변경 내용을 다시 대조합니다. 확인되지 않은 날짜를 기준으로 강제 출시하지 마십시오.
장기간 안정적인 빌드와 서명 작업을 이미 운영 중이라면 기존 Mac 환경을 유지하는 편이 맞습니다. 반대로 이번처럼 클라이언트 수정 여부를 확인하려고 일시적인 Xcode 빌드가 필요한데 현재 방식이 Windows나 Linux 개발 컴퓨터에 의존한다면, 로컬 Mac 구매보다 원격 Mac으로 iOS 빌드 환경을 준비하는 방법을 먼저 비교할 수 있습니다. Mac mini 렌탈을 검토한다면 Mac mini 원격 사용 조건에서 연결 방식과 운영 범위를 확인하십시오.
08현재 방식과 원격 Mac을 비교한 뒤 선택합니다
현재 방식이 로컬 Mac이라면 장비를 직접 관리해야 하고, 디스크와 Xcode 버전 충돌이 생길 때 다른 작업이 멈출 수 있습니다. Windows나 Linux에서 비공식 우회 환경을 쓰면 서명 키체인, 시뮬레이터, TestFlight 검증이 불안정해집니다. 일반 클라우드 빌드는 환경 접근 권한과 디버깅 범위가 제한될 수 있습니다.
이 글의 변경처럼 짧은 기간에 Xcode 수정 빌드와 TestFlight 회귀만 필요하다면 VpsMesh의 원격 Mac이 더 단순한 선택이 될 수 있습니다. 실제 Mac에서 서명 환경을 확인하고, 작업이 끝난 뒤 사용을 멈출 수 있기 때문입니다. 다만 매일 장시간 빌드하거나 물리 기기 연결이 필수라면 직접 소유한 Mac이 더 적합합니다. 이번 작업이 서버 규칙만 바꾸는 수준이라면 Mac을 새로 임대할 필요도 없습니다.