[Apple 로그인][iOS] Sign in with Apple에서 fullName은 첫 로그인만 오고 이후 nil일 때 어떤 가입 저장 기준을 먼저 잡나

IT 리서치 노트

[Apple 로그인][iOS] Sign in with Apple에서 fullName은 첫 로그인만 오고 이후 nil일 때 어떤 가입 저장 기준을 먼저 잡나

iOS에서 Sign in with Apple을 붙일 때 가장 자주 막히는 지점 중 하나가 fullName이다. 첫 로그인 때는 이름과 메일이 잘 오는데, 앱을 다시 실행하고 재로그인하면 fullName은 nil이고 토큰에는 email claim만 남아 보일 때가 많다. 2026년 8월 30일 KST 기준 Apple 공식 문서를 다시 보면, Apple은 사용자 정보를 첫 로그인 응답에서만 수집하고 이름은 이후 토큰에 포함하지 않을 수 있으며, 사용자 식별은 email이 아니라 user identifier로 잡으라고 설명한다. 이 글은 Sign in with Apple에서 fullName이 두 번째부터 nil일 때 어떤 가입 저장 기준과 검증 순서를 먼저 고정해야 하는지 정리한다.

목차

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

1. 개요

결론부터 말하면 Sign in with Apple 가입 저장의 기준점은 첫 로그인 응답이다. fullName은 첫 응답에서만 받고 이후 nil일 수 있으므로, 이름을 다시 받아 오겠다고 기대하지 말고 첫 응답에서 즉시 저장해야 한다. 이후 로그인에서는 userIdentifier로 기존 계정을 조회하고, identity token의 email claim은 보조 검증 신호로만 보는 편이 안전하다.

실무 메모를 짧게 적으면 first response 저장, userIdentifier 기반 조회, repeat login fullName nil 허용 세 줄로 정리된다. 가입 API가 성공했는지, 프로필 DB가 채워졌는지, 재로그인에서 이름이 nil이어도 사용자 화면이 깨지지 않는지까지 같은 체크리스트에 넣어야 한다.

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

현장에서 가장 흔한 실패는 세 갈래다. 첫째, 프론트가 첫 로그인 응답에서 받은 이름을 화면에만 넣고 서버 저장을 미룬다. 둘째, 백엔드가 email을 유일 키처럼 다뤄서 relay 주소나 빈 email 예외를 같이 삼키지 못한다. 셋째, QA가 재로그인 테스트를 하지 않아 fullName nil 문제가 출시 후에야 터진다. 이 세 가지가 겹치면 사용자는 버튼을 탭하고 로그인까지 끝냈는데도 닉네임이 비거나 가입이 반쯤만 끝난 상태가 된다.

Apple 문서는 첫 로그인에서만 사용자 정보가 공유될 수 있고, 이후에는 이름이 다시 오지 않을 수 있다고 직접 적고 있다. 그런데 구현 쪽에서는 종종 Apple 응답을 받은 화면과 서버 회원 저장 사이에 한 번 더 API를 호출하거나, 앱 재실행 뒤 프로필 화면이 Apple 응답 캐시를 기대하는 구조를 넣는다. 그러면 네트워크 재시도, 앱 백그라운드 전환, 회원가입 중간 종료 같은 흔한 시나리오에서 이름 필드가 바로 비게 된다.

또 identity token에 email claim이 보인다는 이유로 이메일이 있으니 이름도 다시 받을 수 있겠지라고 오해하는 경우가 많다. Apple은 오히려 email과 name을 다르게 취급한다. email은 토큰에 남아도 name은 raw user payload나 첫 응답 JSON을 저장해 두지 않으면 복구 근거가 사라진다. 그래서 로그를 조회하고, 응답을 저장하고, DB 필드를 확인하고, 재로그인에서 같은 계정이 조회되는지 검증하는 절차가 필요하다.

• 증상: 첫 로그인 직후만 이름이 보이고 재로그인 뒤 프로필 이름이 비어 있다.
• 실패: first response를 화면 상태로만 두고 서버 DB에 즉시 저장하지 않는다.
• 원인: user identifier 대신 email을 회원 고유 키처럼 사용한다.
• 재발: repeat login에서 fullName nil 시나리오를 QA와 로그 검증에 넣지 않는다.

겉으로 보이는 현상	실제 확인할 곳	판단 기준
가입은 됐는데 이름이 빈다	회원가입 API 응답 로그, DB 저장 필드	first response에서 fullName 저장 여부를 본다
다른 계정으로 중복 가입된다	고유 키 설계	email이 아니라 userIdentifier 기준인지 본다
재로그인 때 이름이 nil이다	프로필 조회 로직	Apple 응답이 아니라 DB 값을 읽는지 본다

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

가장 실용적인 순서는 여섯 단계다. 1단계에서 첫 로그인 응답의 userIdentifier, email, fullName, raw user JSON을 바로 확인한다. 2단계에서 서버 회원가입 API에 이 값을 전달하고 저장 성공 응답을 로그로 남긴다. 3단계에서 회원 테이블의 고유 키를 userIdentifier로 잡는다. 4단계에서 프로필 화면은 Apple 응답이 아니라 DB 조회 결과를 읽도록 바꾼다. 5단계에서 앱을 다시 실행해 재로그인하고 fullName nil 시나리오를 검증한다. 6단계에서 릴레이 메일, 빈 email 예외, 이름 누락 복구 정책을 운영 문서에 분리한다.

1. 첫 로그인 응답에서 name, email, userIdentifier, user JSON을 확인한다.
2. 회원가입 API에서 저장 성공과 실패 필드를 로그로 남긴다.
3. 회원 식별 기준을 userIdentifier로 고정한다.
4. 프로필 화면은 DB 조회 결과를 표시한다.
5. 재로그인에서 fullName nil이어도 가입 상태가 유지되는지 검증한다.
6. relay 메일과 이름 누락 복구 정책을 운영 문서로 분리한다.

이 절차의 핵심은 Apple 응답을 다시 기대하지 않는 구조다. 버튼을 탭하고, 응답을 받고, 서버에 전달하고, DB에 저장하고, 프로필 API로 다시 조회하고, 앱 재실행 뒤에도 같은 결과가 보이는지 확인해야 한다. 구현 시점에는 간단해 보여도 이 순서를 건너뛰면 가입이 성공한 것처럼 보이는 유령 상태가 생긴다.

백엔드 쪽에서는 저장과 검증 필드를 분리해 두는 편이 좋다. 예를 들어 apple_user_identifier, apple_email_last_seen, apple_full_name_first_seen, apple_raw_user_payload_saved 정도만 있어도 운영자가 로그를 조회할 때 훨씬 짧게 판단할 수 있다. 문제를 재현할 때도 어떤 값이 응답에서 왔고 어떤 값이 DB에 남았는지 바로 비교할 수 있다.

회원가입 저장 메모

apple_user_identifier=saved
email_claim_saved=true
full_name_saved_from_first_response=true
raw_user_json_saved=true
repeat_login_profile_reads_db=true
qa_repeat_login_full_name_nil_pass=true

또 UI와 서버 책임을 확실히 나누는 편이 좋다. UI는 이름이 다시 오지 않는다는 사실을 전제로 하고, 서버는 첫 응답 저장과 중복 계정 방지를 책임진다. 이렇게 저장하고, 조회하고, 비교하고, 검증하는 구조를 먼저 고정하면 Apple 로그인 특유의 nil 문제를 이후 토큰 해석 문제와 섞지 않게 된다.

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

첫 자료는 Apple 공식 문서의 가장 중요한 전제다. 같은 개발자 계정 안에서 Sign in with Apple을 묶어 쓰더라도 앱이 사용자 정보를 다시 요청하는 시점은 첫 로그인 기준으로 설계해야 한다.

Apple은 사용자 정보를 앱이 처음 로그인할 때만 요청하도록 설명한다.

즉 가입 플로우는 첫 로그인 응답이 왔을 때 이름과 메일을 서버에 저장하는 쪽으로 짜야 한다. 이후 로그인에서 동일 값이 다시 오길 기대하면 가입 완료 직후 앱 재시작, 네트워크 지연, 화면 재진입에서 바로 구멍이 생긴다.

두 번째 자료도 같은 문서다. Apple은 첫 로그인 응답에서 받은 사용자 정보를 즉시 로컬과 서버에 저장하라고 적고 있다.

첫 로그인 응답에서 받은 이름과 메일은 즉시 저장해야 한다.

이 문장을 놓치면 UI는 가입 완료처럼 보이는데 DB에는 이름이 비는 문제가 생긴다. 서버가 201을 반환하기 전에 어떤 필드를 저장했고 어떤 필드가 비었는지 로그와 응답을 같이 남겨야 하는 이유도 여기 있다.

세 번째 자료는 실무에서 가장 많이 헷갈리는 대목이다. Apple은 이후 응답의 identity token에는 이메일이 남을 수 있지만 이름 같은 다른 정보는 포함되지 않는다고 설명한다.

이후 응답에서는 email 토큰은 남을 수 있어도 fullName은 다시 기대하면 안 된다.

그래서 fullName은 userIdentifier와 같은 안정 식별자에 묶어서 첫 가입 시점에만 저장하고, 이후 로그인에서는 프로필 보정이나 갱신 검증을 따로 분리하는 편이 안전하다.

네 번째 자료는 identity token 문서다. Apple은 사용자를 이메일이 아니라 고정된 user identifier로 식별하라고 적고 있다.

회원 식별 키는 email이 아니라 user identifier 기준으로 잡아야 한다.

익명 릴레이 주소, 학교 계정, 메일 변경, relay 해제 같은 변수가 있어도 user identifier는 팀 단위로 고정된다. 가입 저장 기준을 email unique 하나에만 묶으면 나중에 병합과 복구가 훨씬 어려워진다.

실제 운영에서는 첫 로그인과 재로그인 응답을 표로 먼저 갈라 두는 편이 빠르다. 아래 표는 어떤 필드를 언제 저장하고 언제 조회만 할지 정리한 기준이다.

첫 로그인 응답과 이후 로그인 응답에서 다르게 다뤄야 할 필드다.

같은 문제를 겪는 팀이라면 이 표를 API 명세와 QA 시트에 같이 붙여 두면 좋다. 버튼을 탭하고, 응답을 확인하고, DB 필드를 저장하고, 다음 로그인에서 조회만 하는 경계가 분명해진다.

마지막 자료는 가입 저장 체크리스트 예시다. 핵심은 첫 응답을 받은 직후 서버가 어떤 필드를 저장했고 어떤 검증 로그를 남겼는지 재현 가능하게 쓰는 것이다.

가입 저장 체크리스트는 first response 저장 여부를 바로 확인할 수 있어야 한다.

앱에서 버튼을 누르고, Apple 응답을 받고, 서버에 전달하고, DB에 저장하고, 프로필 화면에서 조회하고, 재로그인에서 nil을 받아도 가입이 유지되는지까지 한 번에 검증해야 한다.

5. 주의사항과 리스크

첫 번째 리스크는 first response 저장을 미루는 것이다. 두 번째는 userIdentifier 대신 email만으로 계정을 묶는 것이다. 세 번째는 프로필 화면이 Apple 응답 캐시를 직접 읽어 repeat login nil 시나리오에서 깨지는 것이다.

운영 전에 최소한 first response 저장 여부, userIdentifier unique 여부, repeat login nil 허용 여부, profile API DB 조회 여부는 체크리스트로 남겨 두는 편이 좋다. 그래야 같은 로그인 오류가 나도 버튼, 응답, DB, 프로필 중 어디를 먼저 볼지 분명해진다.

• fullName은 첫 로그인 응답에서 저장하지 않으면 다시 얻기 어렵다.
• 사용자 식별 키는 email보다 userIdentifier가 안전하다.
• repeat login nil 시나리오는 실패가 아니라 정상 흐름으로 QA해야 한다.

6. 결론

Sign in with Apple에서 fullName이 두 번째 로그인부터 nil일 때 기준점은 명확하다. 첫 로그인 응답에서 이름과 메일을 저장하고, userIdentifier로 계정을 조회하며, 재로그인에서는 nil을 허용한 채 DB 기반 프로필을 보여줘야 한다. 이 세 줄이 잡히면 가입 누락, 중복 계정, 프로필 빈 값 문제를 훨씬 짧게 줄일 수 있다.

다음 단계에서는 같은 Apple 로그인 분기에서 relay 메일 도메인 전환과 allowlist 점검 기준을 별도 문서로 붙여 두면 운영 책임이 더 선명해진다.

7. 참고 링크

1. https://developer.apple.com/documentation/signinwithapple/authenticating-users-with-sign-in-with-apple
2. https://developer.apple.com/documentation/signinwithapple/receiving-a-users-identity-token
3. https://developer.apple.com/documentation/signinwithapple/incorporating-sign-in-with-apple-into-other-platforms