[Apple 로그인][비교] Sign in with Apple credential revoked, server-to-server revoked notification, account deletion을 언제 다른 incident로 나누나

IT 리서치 노트

[Apple 로그인][비교] Sign in with Apple credential revoked, server-to-server revoked notification, account deletion을 언제 다른 incident로 나누나

Sign in with Apple 운영에서 credential revoked, server-to-server revoked notification, account deletion을 같은 사건처럼 적기 시작하면 세션, 토큰, 이메일 전달, 삭제 완료 상태가 한꺼번에 섞인다. 2026년 9월 1일 KST 기준 Apple 공식 문서를 다시 보면 Apple Account 영구 삭제는 모든 user token 무효화와 email forwarding 중단을 동반하고, account deletion을 제공하는 앱은 REST API로 사용자 토큰 revoke를 수행해야 한다. 이 글은 credential revoked, server-to-server revoked notification, account deletion을 언제 다른 incident로 나눠야 하는지 정리한다.

목차

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

1. 개요

결론부터 말하면 Sign in with Apple 운영에서는 credential revoked, server-to-server revoked notification, account deletion aftermath를 다른 incident row로 나눠야 한다. 셋 다 로그인 문제처럼 보이지만 입력 신호와 후속 조치가 다르다.

credential revoked는 relink와 재인증 경계를 다루고, server-to-server notification은 세션 무효화와 서버 기록을 다루며, account deletion은 token revoke와 email forwarding 중단, 삭제 완료 상태를 다룬다. 이 셋을 한 줄로 합치면 복구 경로가 흐트러진다.

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

실무에서 가장 흔한 실패는 세 사건을 모두 Apple 로그인 revoke 같은 하나의 incident 이름으로 적는 것이다. 그러면 사용자가 동의를 철회한 상황과, 서버가 알림을 받은 상황과, 사용자가 계정을 실제로 삭제한 상황이 같은 체크리스트를 타게 된다.

Apple의 processing changes 문서는 Apple Account 영구 삭제 시 모든 token invalidation과 email forwarding 중단을 설명하고, revoke tokens 문서는 유효한 refresh token 또는 access token이 필요하다고 적는다. 또 account deletion 지원 문서는 Sign in with Apple 사용 앱이 REST API로 토큰 revoke를 해야 한다고 안내한다. 이 셋은 서로 다른 운영 입력이다.

문제는 현장의 메모가 보통 세션 종료 여부 하나로만 끝난다는 점이다. 하지만 credential revoked는 사용자가 다시 인증하면 relink로 복구될 수 있고, account deletion aftermath는 토큰 철회와 삭제 절차를 이미 거친 상태일 수 있다. 같은 세션 종료라도 의미가 다르다.

• 증상: 서로 다른 Apple 로그인 사건이 같은 ticket 이름으로 섞인다.
• 실패: 세션 무효화와 account deletion 완료를 같은 상태값으로 적는다.
• 막힘: token revoke 수행 여부가 빠져 후속 검증이 길어진다.
• 누락: email forwarding 중단 여부를 account deletion row에 안 남긴다.

겉으로 보이는 현상	먼저 볼 값	판단 기준
사용자가 다시 로그인하라는 메시지를 본다	credential revoked 여부	relink 가능 상태인지 본다
서버에서 revoke 알림을 받았다	notification id, session invalidated_at	서버 기준 사건인지 본다
사용자가 계정 삭제를 요청했다	token revoke 완료 여부, deletion 완료 시각	복구보다 삭제 완료 검증이 우선인지 본다

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

가장 짧은 운영 순서는 네 단계다. 먼저 입력 신호가 무엇인지 분류한다. 다음으로 해당 신호에 필요한 값만 같은 row에 적는다. 세 번째로 후속 조치를 relink, session invalidation, token revoke, deletion verification으로 나눈다. 마지막으로 서로 다른 신호가 같은 날 들어오면 최초 발생 시각 기준으로 row를 분리한다.

1. signal_type을 먼저 고정한다.
2. credential revoked와 server notification을 다른 상태값으로 둔다.
3. account deletion row에는 token revoke와 deletion verification을 꼭 남긴다.
4. 같은 사용자라도 신호가 다르면 다른 incident row로 적는다.

이 구조를 잡아 두면 복구와 삭제가 섞이지 않는다. 사용자가 다시 로그인하면 해결될 사건인지, 이미 토큰을 철회하고 삭제 확인까지 해야 하는 사건인지가 한 줄에서 갈린다. 특히 account deletion aftermath는 세션 재인증 문제보다 규정 준수와 사용자 데이터 정리 쪽에 더 가깝다.

signal_type=server-revoke-notification
credential_revoked_seen=false
session_invalidated_at=2026-09-01T11:02:00+09:00
token_revoke_required=false
account_deletion_verification_required=false

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

첫 자료는 Apple의 processing changes 문서다. 사용자가 Apple Account를 영구 삭제하면 모든 user token이 무효화되고 email forwarding도 비활성화된다고 설명한다.

Apple Account 영구 삭제는 단순 재로그인 이슈가 아니라 token invalidation과 email forwarding 중단까지 포함한 다른 incident다.

즉 account deletion은 credential revoked와 같은 한 줄 상태로 묶으면 안 된다. 세션 문제를 넘어 토큰과 메일 전달 경계까지 같이 바뀐다.

두 번째 자료는 revoke tokens 문서다. Apple은 사용자 authorization을 revoke하려면 유효한 refresh token 또는 access token이 필요하다고 적는다.

token revocation은 서버가 수행하는 명시적 작업이므로 credential revoked 알림과 같은 계층으로 보면 안 된다.

이 문장은 운영 기준을 바꾼다. 사용자가 동의를 철회한 사건과, 서버가 토큰을 직접 철회하는 절차는 서로 다른 입력과 로그를 가진다.

세 번째 자료는 Apple 지원 문서다. 앱이 account deletion을 제공한다면 Sign in with Apple REST API로 사용자 토큰을 revoke해야 한다고 설명한다.

account deletion flow는 단순 UI 삭제가 아니라 token revoke 절차와 이어지는 별도 운영 경로다.

따라서 account deletion aftermath는 credential revoked나 server notification incident의 후속 메모가 아니라, 사용자 삭제 흐름과 복구 불가 상태를 다루는 별도 row가 필요하다.

실무에서 가장 필요한 것은 세 사건을 다른 row로 자르는 기준이다. 아래 표는 어떤 입력이 들어왔을 때 어떤 incident 이름으로 나눌지 정리한 예시다.

credential revoked, server-to-server revoked notification, account deletion은 같은 Apple 로그인 문제처럼 보여도 다른 incident row로 나눠야 한다.

이미 credential revoked 경계 글과 server-to-server revoke 글을 읽었다면, 이번 표는 두 글과 account deletion 흐름을 한 허브로 묶는 기준표다.

마지막 자료는 incident note JSON 예시다. 핵심은 세 사건을 하나의 boolean으로 접지 않고, 입력 경로와 후속 조치를 명시적으로 나누는 것이다.

Apple 로그인 incident note는 revoke 신호 종류와 account deletion 여부를 분리된 상태값으로 저장해야 한다.

이 구조가 있으면 post 440의 userIdentifier relink, post 444의 credential revoked, post 447의 server notification이 account deletion 이후에도 같은 vocabulary로 이어진다. relay forwarding 중단과 account deletion 지원 문구를 실제 운영 row로 더 잘게 나누는 후속편은 relay forwarding과 deletion support copy 분리 글에서 이어진다.

5. 주의사항과 리스크

첫 번째 리스크는 account deletion aftermath를 credential revoked 후속편처럼 적는 것이다. 두 번째 리스크는 token revoke 완료 여부가 빠져, 사용자 삭제 요청을 받고도 Apple 토큰이 남는 상태를 놓치는 것이다. 세 번째 리스크는 server notification을 사용자 UI 사건처럼만 적어 session invalidation 근거가 약해지는 것이다.

운영 전에는 signal_type, session invalidated_at, relink state, token revoke 완료 시각, deletion verification 상태 다섯 칸을 분리해 두는 편이 좋다. 그래야 사용자 문의와 감사 로그가 같은 vocabulary를 쓴다.

• credential revoked는 재인증 경계다.
• server notification은 서버 기록과 세션 무효화 경계다.
• account deletion aftermath는 token revoke와 삭제 검증 경계다.

6. 결론

Sign in with Apple incident를 짧게 운영하려면 revoke라는 단어 하나로 묶지 말아야 한다. credential revoked, server-to-server revoked notification, account deletion aftermath를 다른 row로 나누면 세션, 토큰, 삭제 검증이 각각 제자리를 찾는다.

• 입력 신호가 다르면 incident 이름도 다르게 둔다.
• token revoke와 deletion verification은 account deletion row에 남긴다.
• 세션 무효화와 relink 차단을 같은 값으로 합치지 않는다.

7. 참고 링크

1. https://developer.apple.com/documentation/signinwithapple/processing-changes-for-sign-in-with-apple-accounts
2. https://developer.apple.com/documentation/signinwithapplerestapi/revoke-tokens
3. https://developer.apple.com/support/offering-account-deletion-in-your-app/
4. https://developer.apple.com/documentation/technotes/tn3194-handling-account-deletions-and-revoking-tokens-for-sign-in-with-apple