[Apple 로그인][이메일] relay forwarding이 끊겼을 때 mail forwarding 변경과 account deletion support copy를 어떤 incident row로 나누나

IT 리서치 노트

[Apple 로그인][이메일] relay forwarding이 끊겼을 때 mail forwarding 변경과 account deletion support copy를 어떤 incident row로 나누나

Sign in with Apple 운영에서 사용자가 '메일이 안 와요'라고 문의할 때 relay forwarding 변경과 account deletion 후속 조치를 같은 incident로 다루면 지원 문구가 쉽게 어긋난다. 2026년 9월 1일 KST 기준 Apple 공식 문서를 다시 보면 server-to-server notifications는 mail forwarding preference change, app account deletion, Apple Account 영구 삭제를 모두 다른 입력으로 다루고, account deletion 지원 문서는 토큰 revoke 후속 조치를 요구한다. 이 글은 relay forwarding이 끊겼을 때 mail forwarding 변경과 account deletion support copy를 어떤 incident row로 나눠야 하는지 정리한다.

목차

1. 개요
2. 어디서 실제로 막히는가
3. 실무에서 적용하는 순서
4. 공식 문서와 예시 화면으로 확인하기
5. 주의사항과 리스크
6. 결론
7. 참고 링크

1. 개요

결론부터 말하면 relay forwarding 문제와 account deletion support copy는 다른 incident row로 적어야 한다. 둘 다 사용자는 메일이 안 온다고 말할 수 있지만, backend 입력과 다음 조치가 완전히 다르다.

Apple 로그인 지원 운영에서는 notification_type, relay_delivery_state, account_deletion_requested, token_revoke_required, support_copy_variant를 같은 레코드에 두는 편이 좋다. 이미 relay 도메인 전환 글이 있다면, 이번 글은 그 다음 단계인 고객 지원 분기다.

2. 어디서 실제로 막히는가

현장에서 먼저 꼬이는 지점은 세 가지다. 첫째, relay 메일이 안 온다는 고객 문의를 모두 account deletion 후속 대응처럼 답한다. 둘째, server-to-server notification은 forwarding change였는데 지원 티켓에는 삭제 관련 문구가 들어간다. 셋째, 실제로는 deletion aftermath인데 forwarding 설정 안내만 보내고 token revoke나 세션 종료 확인을 놓친다.

Apple 도움말은 mail forwarding preference change와 app account deletion, Apple Account 영구 삭제를 같은 알림 체계 안에서 구분해 보라고 한다. processing changes 문서는 영구 삭제 시 token invalidation과 email forwarding 중단을 함께 설명하고, account deletion 지원 문서는 REST API revoke 후속 조치를 요구한다. 즉 고객이 보는 현상은 비슷해도 operator가 보는 evidence는 다르다.

문제는 실제 지원 템플릿이 너무 빨리 한 문구로 수렴한다는 점이다. 메일 전달이 끊겼다는 현상 하나만 보고 계정 삭제 안내를 보내면, 사용자는 삭제를 요청한 적이 없다고 답하게 된다. 반대로 삭제 요청 이후 forwarding이 끊긴 상황을 일반 forwarding 설정 문제처럼 처리하면 보안과 규정 준수 쪽이 비게 된다.

• 증상: 고객 문의 제목은 같지만 support copy가 자꾸 엇나간다.
• 실패: mail forwarding change와 account deletion 후속 안내를 같은 템플릿으로 처리한다.
• 막힘: notification type과 revoke 상태를 확인하지 않고 문구부터 보낸다.
• 누락: deletion aftermath에서 token revoke와 세션 종료 근거를 안 남긴다.

겉으로 보이는 현상	실제 확인할 곳	판단 기준
로그인 메일이 안 온다	notification_type, relay delivery 상태	mail forwarding change인지 먼저 본다
삭제 후 메일이 끊겼다	deletion request, revoke 상태	account deletion aftermath인지 본다
운영 문구와 backend 상태가 다르다	support_copy_variant, token_revoke_required	문구와 조치가 같은 사건을 가리키는지 본다

3. 실무에서 적용하는 순서

가장 실용적인 운영 순서는 다섯 단계다. 먼저 notification type과 app group을 저장한다. 다음으로 relay delivery state가 forwarding change인지 deletion aftermath인지 가른다. 세 번째로 account deletion 요청과 revoke 상태를 확인한다. 네 번째로 support copy variant를 선택한다. 마지막으로 사용자가 다시 문의했을 때 같은 incident row에서 backend state와 보낸 문구를 같이 읽을 수 있게 한다.

1. notification type과 app group을 먼저 저장한다.
2. relay forwarding change와 deletion aftermath를 나눈다.
3. token revoke 필요 여부를 확인한다.
4. support copy variant를 사건별로 선택한다.
5. 보낸 문구와 backend 상태를 같은 row에 남긴다.

이 구조를 잡아 두면 support copy가 backend truth와 맞는다. forwarding change면 사용자의 설정과 relay 경로를 확인하는 문구가 맞고, account deletion aftermath면 token revoke, 세션 종료, 삭제 검증 쪽 안내가 맞다. 현상은 둘 다 메일이 안 오는 것이지만, operator note는 반드시 갈라야 한다.

notification_type=mail-forwarding-changed|account-deleted
relay_delivery_state=changed|disabled
account_deletion_requested=true|false
token_revoke_required=true|false
support_copy_variant=forwarding-guide|deletion-follow-up

4. 공식 문서와 예시 화면으로 확인하기

첫 자료는 Apple의 server-to-server notifications 도움말이다. 사용자가 mail forwarding preference를 바꾸는 사건과 app account deletion, Apple Account 영구 삭제가 모두 알림으로 올 수 있다고 적는다.

mail forwarding preference change와 account deletion은 같은 알림 체계 안에 있지만 다른 incident row로 나눠야 한다.

즉 relay forwarding이 끊겼다고 해서 바로 account deletion 문구부터 보내면 안 된다. 먼저 어떤 notification type이 들어왔는지와 app group 맥락을 봐야 support copy가 엇나가지 않는다.

두 번째 자료는 processing changes 문서다. Apple Account 영구 삭제는 user token 무효화와 email forwarding 중단까지 동반하는 다른 사건이라고 설명한다.

Apple Account 영구 삭제는 단순 mail forwarding change가 아니라 token invalidation과 forwarding 중단을 함께 만든다.

그래서 forwarding이 멈췄다는 현상만 같아도, 사용자가 forwarding 설정만 바꾼 것인지 영구 삭제 aftermath인지 support row를 따로 둬야 한다. support copy와 복구 조치가 완전히 달라지기 때문이다.

세 번째 자료는 account deletion 지원 문서다. Sign in with Apple을 쓰는 앱은 계정 삭제 지원 시 REST API로 사용자 토큰을 revoke해야 한다고 안내한다.

account deletion support copy는 단순 메일 안내가 아니라 token revoke 후속 조치와 같이 움직여야 한다.

즉 account deletion 관련 지원 문구는 forwarding preference change와 다른 evidence를 요구한다. 사용자가 메일을 못 받는다고 해서 같은 템플릿 답변을 쓰면 운영 문구와 실제 백엔드 상태가 어긋난다.

실무에서는 고객 문의 제목이 모두 'Apple 로그인 메일이 안 와요'로 들어오는 경우가 많다. 아래 표는 어떤 incident row로 먼저 자를지 정리한 예시다.

relay forwarding 문제와 account deletion 후속 지원 문구는 다른 incident row로 분리해야 한다.

이미 private.icloud.com 전환 글이 도메인·allowlist 축을 다뤘다면 이번 글은 support incident 분기다. 또 credential revoked vs account deletion 비교 글과 이어 보면 user-facing copy와 backend state를 같은 vocabulary로 맞출 수 있다.

마지막 자료는 support incident log 예시다. 핵심은 forwarding change와 account deletion 관련 copy를 다른 상태값으로 남기는 것이다.

support incident log는 relay forwarding change와 account deletion copy를 다른 상태값으로 분리해야 한다.

이 구조가 있으면 post 447의 server notification, post 450의 incident split, post 438의 relay 운영 글이 실제 지원 메모로 닫힌다.

5. 주의사항과 리스크

첫 번째 리스크는 forwarding change 문의에 deletion follow-up 문구를 보내 사용자를 불필요하게 혼란시키는 것이다. 두 번째 리스크는 deletion aftermath인데도 relay 설정 안내만 보내 token revoke와 세션 종료 확인을 놓치는 것이다. 세 번째 리스크는 support copy를 남기지 않아 나중에 왜 그 안내를 보냈는지 복기하지 못하는 것이다.

운영 전에는 notification_type, relay_delivery_state, account_deletion_requested, token_revoke_required, support_copy_variant 다섯 칸을 같은 support incident note에 두는 편이 좋다. 그래야 support ticket과 auth incident가 같은 vocabulary를 쓴다.

• 메일 미수신 현상 하나로 deletion 문구를 바로 보내지 않는다.
• notification type과 revoke 상태 없이 support copy를 확정하지 않는다.
• 보낸 문구와 backend 상태를 같은 incident row에 남긴다.

6. 결론

Sign in with Apple relay forwarding이 끊겼을 때는 mail forwarding change와 account deletion support copy를 다른 incident row로 나눠야 한다. notification type과 revoke 상태를 먼저 보고 문구를 고르면 support 운영과 backend 상태가 같은 말을 하게 된다.

account deletion 이후 token revoke 완료 여부와 실제 후속 지원 문구 버전까지 한 줄로 닫아야 한다면 후속 글인 deletion-aftercare support log 정리를 이어서 보면 된다. 그 글은 forwarding change 분기 다음 단계에서 revoke evidence와 support copy version을 어떻게 같이 남길지 다룬다.

• forwarding change와 deletion aftermath를 다른 row로 둔다.
• support copy는 notification type과 revoke 상태 뒤에 고른다.
• 메일 운영 글과 auth incident 글을 같은 vocabulary로 묶는다.

7. 참고 링크

1. https://developer.apple.com/documentation/signinwithapple/processing-changes-for-sign-in-with-apple-accounts
2. https://developer.apple.com/help/account/capabilities/enabling-server-to-server-notifications/
3. https://developer.apple.com/support/offering-account-deletion-in-your-app/
4. https://developer.apple.com/documentation/signinwithapplerestapi/revoke-tokens