앱 MVP 푸시 토큰: 계정 전환·재설치·실패 응답을 나누는 5가지 기준
앱 MVP 푸시 토큰: 계정 전환·재설치·실패 응답을 나누는 5가지 기준
푸시 알림을 도입한 MVP에서 가장 빨리 엉키는 지점은 ‘이 사용자의 토큰’을 하나의 값으로 생각하는 순간입니다. 실제 전송 대상은 사용자 자체가 아니라 특정 앱 설치·기기 상태에 가깝고, 그 값은 바뀌거나 더 이상 유효하지 않을 수 있습니다. 따라서 알림 권한 화면, 메시지 발송 결과, 사용자 계정 연결을 한 표로 뭉뚱그리기보다 각각의 상태와 책임을 먼저 나누는 편이 안전합니다.
이 글은 Firebase Cloud Messaging(FCM)을 사용하는 Android MVP를 전제로 합니다. FCM의 현재 안내는 앱 인스턴스를 위한 Firebase Installation ID(FID)와 서버의 최신 등록 정보를 관리하는 흐름을 권장합니다. 아래 기준은 특정 서비스의 정답이나 수신 보장을 뜻하지 않습니다. 제품의 로그인 구조와 개인정보 처리 방침에 맞춰 결정해야 할 운영 항목입니다.
먼저 답: 사용자 1명과 전송 대상 1개를 같은 것으로 두지 않습니다
하나의 사용자는 새 휴대폰, 태블릿, 재설치된 앱처럼 여러 앱 인스턴스를 가질 수 있습니다. 반대로 한 기기에서 계정을 바꾸는 경우도 있습니다. 그래서 서버에는 최소한 ‘앱 인스턴스를 식별하는 값’, ‘마지막으로 서버에 동기화한 시각’, ‘현재 연결한 계정 상태’를 별도로 두는 설계가 읽기 쉽습니다.
FCM은 앱 시작 시 앱 인스턴스를 등록하고 FID를 돌려주며, 서버에 FID와 업로드 시각을 저장하라고 안내합니다. 이는 개인을 식별하는 프로필 필드를 늘리라는 뜻이 아닙니다. 푸시 전송을 위해 필요한 기기별 등록 상태를 계정 프로필·알림 동의·마케팅 수신 동의와 구분하자는 뜻입니다. 어떤 항목을 얼마 동안 보관하는지는 서비스의 개인정보 처리 기준에서 별도로 정해야 합니다.
알림 권한이 허용됐다고 최신 전송 대상이 서버에 있다는 뜻도 아닙니다. 반대로 등록 정보가 있다고 화면에 알림이 표시됐다는 뜻도 아닙니다. 권한과 표시를 점검하려면 알림 수신 확인 기준처럼 발송·기기 표시 흐름을 따로 확인하세요.
기준 1: 등록 정보는 ‘계정’이 아니라 ‘앱 인스턴스’에서 시작합니다
첫 설계 질문은 ‘누구에게 보낼까’가 아니라 ‘어떤 앱 인스턴스가 현재 등록됐나’입니다. FCM 문서는 최신 FID를 앱 서버로 보내고 업로드 시각을 함께 저장하는 방식을 권장합니다. 따라서 MVP의 최소 레코드는 사용자 ID만 키로 삼아 마지막 값을 덮어쓰기보다, 앱 인스턴스별 레코드와 계정 연결 상태를 나누는 편이 이후의 재설치·다기기·계정 전환을 설명하기 쉽습니다.
다만 기기 식별자나 전송 등록 정보도 서비스가 다루는 데이터입니다. 개발 편의를 이유로 기기 모델, 위치, 연락처 같은 불필요한 속성을 함께 붙이지 마세요. 전송 대상 관리에 필요한 최소 필드만 정의하고, 접근 권한·보관 기간·삭제 조건을 문서화하는 것이 출발점입니다.
기준 2: 최초 등록과 갱신은 같은 동기화 경로로 처리합니다
Android의 FCM 안내에 따르면 새 등록 값은 초기 생성 때뿐 아니라 새 기기 복원, 앱 삭제 후 재설치, 앱 데이터 삭제 같은 경우에도 바뀔 수 있습니다. `onNewToken` 같은 갱신 콜백에서 최신 값을 서버로 보내는 이유가 여기에 있습니다. 서버는 이 요청을 받을 때마다 ‘새 토큰인지’만 비교하지 말고 마지막 동기화 시각도 갱신해야 합니다.
중요한 점은 네트워크 실패입니다. 앱이 최신 값을 얻었더라도 서버 업로드가 실패할 수 있습니다. 이때 화면에서 ‘알림 설정 완료’라고 단정하기보다, 업로드 재시도와 서버 반영 여부를 구분해 기록하세요. 네트워크 문제의 사용자 안내는 연결·요청·재시도 상태를 나누는 기준을 참고할 수 있습니다.
기준 3: 로그인·로그아웃·계정 전환 때 연결 규칙을 명시합니다
푸시 등록 값이 바뀌었는지와 현재 어떤 계정에 연결할지는 별개의 제품 결정입니다. 예를 들어 로그아웃 뒤에도 서비스 공지 알림을 보낼지, 계정별 알림만 끊을지, 기기에서 다른 계정으로 로그인하면 기존 연결을 언제 해제할지를 정해야 합니다. 이 결정은 자동 로그아웃이나 모든 기기 종료 정책과도 다릅니다.
MVP 문서에는 다음처럼 상태를 적어 두면 충분합니다. 로그인 전 등록 정보는 익명 상태로 둘지, 로그인 성공 뒤에만 계정과 연결할지, 로그아웃에서 계정 연결만 제거할지, 사용자 탈퇴에서 어떤 관련 레코드를 삭제할지입니다. 다른 기기의 로그인 상태를 끊는 기능은 원격 세션 종료 점검표처럼 별도 인증·세션 정책으로 다루어야 합니다. 푸시 등록 정리는 그 기능을 대신하지 않습니다.
기준 4: 전송 실패 응답을 ‘다시 보내기’ 신호로만 해석하지 않습니다
서버가 FCM HTTP v1 API에서 유효하지 않거나 만료된 등록을 가리키는 응답을 받으면, 해당 등록 레코드를 정리해야 합니다. Firebase는 `UNREGISTERED`와, 유효한 메시지 본문인데도 나온 `INVALID_ARGUMENT`을 무효 등록 판단에 활용할 수 있다고 설명합니다. 모든 실패가 등록 정보 문제는 아니므로, 메시지 형식 오류와 등록 무효를 같은 처리로 묶으면 안 됩니다.
정리 대상도 사용자 계정 전체가 아니라 그 등록 레코드입니다. ‘전송 실패 → 계정 삭제’ 같은 연쇄 처리는 피하고, 실패 응답 코드·발생 시각·대상 등록 레코드·후속 처리 결과를 남기세요. 이 기록은 발송 실패를 숨기지 않으면서도 과도한 사용자 정보를 쌓지 않는 데 도움이 됩니다.
기준 5: 신선도 기준과 QA 관찰값을 별도로 둡니다
Firebase는 한 달 넘게 FCM에 연결되지 않은 등록을 오래된 상태로 볼 수 있다고 안내하며, Android에서는 270일 비활성 등록을 만료로 처리합니다. 이 수치는 모든 서비스의 삭제 기한이 아닙니다. 우리 서비스가 ‘최근 동기화 없음’을 언제부터 정리 후보로 볼지 정하고, 실제 삭제 전 재접속·재등록 가능성과 운영상 필요한 보관 기준을 함께 검토해야 합니다.
QA에서는 최소 네 장면을 확인하세요. 새 설치 후 등록 업로드, 로그인 계정 전환, 재설치 또는 앱 데이터 삭제 뒤 갱신, 무효 응답 뒤 레코드 정리입니다. 각 장면에서 앱 화면, 서버 수신, 전송 요청, 기기 표시를 하나의 성공 수치로 합치지 마세요. 특히 기기 표시까지 확인하려면 권한과 OS 상태의 영향도 따로 남겨야 합니다.
판단 항목 | 최소 기록 | 확인 질문 |
|---|---|---|
앱 인스턴스 등록 | 인스턴스 식별값, 동기화 시각 | 새 설치에서 서버가 최신 상태를 받았나? |
계정 연결 | 연결 상태와 변경 시각 | 로그아웃·계정 전환 때 이전 연결을 어떻게 처리하나? |
전송 실패 | 응답 코드, 등록 레코드, 처리 결과 | 무효 등록만 정리했나? |
신선도 | 마지막 동기화 시각, 서비스 기준 | 오래된 레코드의 재등록 경로가 있나? |
구현 전에 남길 한 장의 결정 기록
기능 명세에는 ‘푸시 발송’ 한 줄 대신 다음 다섯 줄을 남기면 됩니다. 첫째, 앱 인스턴스 등록값과 계정 연결값을 어떻게 구분하는지. 둘째, 최초 등록·갱신·업로드 실패의 처리 주체가 누구인지. 셋째, 로그인·로그아웃·계정 전환에서 어떤 연결을 변경하는지. 넷째, 무효 응답에서 삭제하는 레코드와 재시도하는 오류를 어떻게 가르는지. 다섯째, 신선도 판단과 QA 증거를 어디에 남기는지입니다.
이 기록이 있으면 나중에 ‘알림이 안 왔다’는 문의가 생겼을 때 권한 문제, 등록 동기화 문제, 전송 실패, 기기 표시 문제를 분리해 살필 수 있습니다. MVP의 목적은 복잡한 전송 인프라를 한 번에 완성하는 것이 아니라, 각 상태의 소유자와 복구 경로를 확인 가능하게 만드는 데 있습니다.
자주 묻는 질문(FAQ)
푸시 등록값 하나를 사용자 ID에 저장하면 안 되나요?
단일 기기·단일 계정만 지원하는 초기 단계라면 구현은 단순할 수 있습니다. 다만 재설치·다기기·계정 전환을 설명하기 어려워질 수 있으므로, 적어도 앱 인스턴스 등록 상태와 계정 연결 상태를 구분할지 명세에 남기는 편이 좋습니다.
알림 권한을 허용하면 서버의 전송 대상도 최신인가요?
아닙니다. 권한은 OS가 알림 표시에 관여하도록 허용하는 상태이고, 최신 등록 정보가 서버에 업로드됐는지는 별도 동기화 결과로 확인해야 합니다.
`UNREGISTERED` 응답이 오면 사용자 계정을 삭제해야 하나요?
아닙니다. Firebase 안내는 유효하지 않거나 만료된 등록 정보를 서버에서 제거하는 흐름을 설명합니다. 사용자 계정·구독·세션을 어떻게 처리할지는 별도의 제품 정책입니다.
오래된 등록은 언제 삭제해야 하나요?
Firebase의 오래된 등록 안내를 참고하되, 서비스의 재접속 주기·보관 기준·재등록 흐름에 맞는 자체 기준을 정해야 합니다. FCM의 플랫폼별 만료 처리를 모든 서비스의 보관 기간으로 그대로 복사하면 안 됩니다.
확인한 공식 출처
• Firebase Cloud Messaging: Best practices for FCM registration management