레이블이 푸시알림인 게시물을 표시합니다. 모든 게시물 표시
레이블이 푸시알림인 게시물을 표시합니다. 모든 게시물 표시

2026년 7월 17일 금요일

FCM 푸시 토큰의 갱신과 무효화를 관리하는 방법

발급된 토큰을 서버에 저장하고 갱신 시각과 실패 응답을 이용해 오래된 등록을 정리하는 수명 주기를 설명합니다. 이 주제를 이해할 때 첫 기준은 ‘현재 등록값’입니다. 앱 시작과 onNewToken에서 얻은 값을 서버에 올리되 사용자 계정 하나에 토큰 하나만 있다고 가정하지 않습니다. 한 사용자가 여러 설치를 가질 수 있습니다.

이 글의 범위
실제 경험이나 측정 결과를 가정하지 않고, 공식 문서로 확인 가능한 개념과 적용 순서를 일반 가이드로 설명합니다. 제품 버전과 서비스 정책은 바뀔 수 있으므로 적용 전 연결된 공식 문서를 다시 확인하세요.

먼저 구분할 핵심

FCM 등록 정보는 발급되는 순간보다 그 뒤의 갱신, 계정 연결, 실패 분류가 중요합니다. ‘현재 등록값’에서 시작해 ‘갱신 시각’와의 경계를 정하면 구현할 범위와 실패했을 때 확인할 지점을 구분하기 쉬워집니다.

FCM 푸시 토큰의 갱신과 무효화를 관리하는 방법 핵심 판단 흐름 설명용 개념도

그림 1. FCM 푸시 토큰의 갱신과 무효화를 관리하는 방법의 핵심 판단 순서를 정리한 설명용 개념도입니다. 실제 서비스 화면, 운영 로그 또는 측정 결과가 아닙니다.

토큰을 한 번 쓰는 값이 아닌 상태로 관리하기

현재 등록값

앱 시작과 onNewToken에서 얻은 값을 서버에 올리되 사용자 계정 하나에 토큰 하나만 있다고 가정하지 않습니다. 한 사용자가 여러 설치를 가질 수 있습니다.

갱신 시각

토큰 또는 설치 식별자를 저장할 때 마지막 확인 시각을 함께 기록합니다. 값이 같아도 앱이 정상적으로 다시 연결됐다는 신호가 됩니다.

계정 연결

로그인·로그아웃 시 설치 등록과 사용자 대상 발송의 관계를 갱신합니다. 로그아웃한 기기에 이전 사용자의 민감한 알림이 가지 않게 합니다.

실패 응답

서버 발송 결과에서 등록되지 않은 토큰으로 확인되면 비활성화하거나 삭제합니다. 모든 실패를 같은 재시도 큐로 보내지 않습니다.

장기 미사용

오래 확인되지 않은 등록은 별도 정책으로 정리하고 발송 대상과 성과 지표에서 분리합니다. 기준은 서비스의 사용 주기에 맞춥니다.

클라이언트와 서버를 연결하는 순서

  1. 설치 단위 등록 레코드에 사용자, 현재 값, 플랫폼, 갱신 시각을 둡니다.
  2. 앱 시작과 토큰 변경 콜백에서 최신 값을 멱등하게 업로드합니다.
  3. 로그인·로그아웃 때 사용자 연결만 안전하게 갱신합니다.
  4. 발송 결과를 성공·일시 실패·영구 무효로 분류합니다.
  5. 장기 미사용과 영구 무효 등록을 정기적으로 정리합니다.

푸시 누락을 키우는 운영 패턴

  • 최초 설치 때 받은 값만 영구 저장하기
  • 사용자 ID를 토큰의 유일한 키로 사용하기
  • 모든 발송 실패를 무제한 재시도하기
  • 디버그 로그에 전체 토큰과 사용자 정보를 그대로 남기기

적용 전 마지막 점검

확인 항목질문
첫 기준: 현재 등록값변경 전에 전제와 목적을 확인했는가?
분리 대상: 갱신 시각다른 책임과 섞이지 않게 경계를 정했는가?
피할 패턴: 최초 설치 때 받은 값만 영구 저장하기본문에서 경고한 패턴이 남아 있지 않은가?
오류와 복구정상 경로뿐 아니라 실패와 되돌리기도 확인했는가?

정리

FCM 등록 정보는 발급되는 순간보다 그 뒤의 갱신, 계정 연결, 실패 분류가 중요합니다. 설치 단위 레코드와 마지막 확인 시각을 관리하면 오래된 대상을 줄이고 실제 전달 상태를 더 정확히 해석할 수 있습니다.


참고한 공식 문서

딥링크와 푸시 라우팅을 함께 테스트해야 하는 이유

앱 종료·백그라운드·인증 상태에 따라 달라지는 외부 진입 경로를 하나의 테스트 표로 검증하는 방법을 정리합니다. 여러 선택지를 한 번에 적용하기보다 ‘앱 생명주기’부터 확인합니다. 종료 상태의 initial URL과 실행 중 url 이벤트는 들어오는 경로가 다릅니다. 백그라운드 복귀까지 따로 확인해야 합니다.

이 글의 범위
실제 경험이나 측정 결과를 가정하지 않고, 공식 문서로 확인 가능한 개념과 적용 순서를 일반 가이드로 설명합니다. 제품 버전과 서비스 정책은 바뀔 수 있으므로 적용 전 연결된 공식 문서를 다시 확인하세요.

처음 확인할 경계

딥링크와 푸시는 입력 형식만 다를 뿐 외부에서 앱 상태를 바꾸는 같은 종류의 진입입니다. ‘앱 생명주기’에서 시작해 ‘인증 상태’와의 경계를 정하면 구현할 범위와 실패했을 때 확인할 지점을 구분하기 쉬워집니다.

각 기능을 따로 테스트할 때 놓치는 것

  • 종료 상태에서만 발생하는 초기화 순서 문제
  • 로그인 뒤 원래 목적지를 잃는 문제
  • 푸시 탭과 URL 이벤트가 동시에 처리되는 문제
  • 지원하지 않는 외부 URL을 내부 WebView로 여는 문제

딥링크와 푸시 라우팅을 함께 테스트해야 하는 이유 핵심 판단 흐름 설명용 개념도

그림 1. 딥링크와 푸시 라우팅을 함께 테스트해야 하는 이유의 핵심 판단 순서를 정리한 설명용 개념도입니다. 실제 서비스 화면, 운영 로그 또는 측정 결과가 아닙니다.

최소 시나리오 표를 만드는 순서

  1. 딥링크와 푸시 payload를 동일한 RouteIntent로 변환합니다.
  2. 앱 종료·백그라운드·포그라운드 상태를 행으로 둡니다.
  3. 로그인·로그아웃·세션 만료를 열로 추가합니다.
  4. 각 조합에서 최종 화면과 중간 안내, 이벤트 소비 여부를 기록합니다.
  5. 지원하지 않는 링크와 중복 탭도 회귀 테스트에 포함합니다.

외부 진입 테스트의 네 가지 축

앱 생명주기

종료 상태의 initial URL과 실행 중 url 이벤트는 들어오는 경로가 다릅니다. 백그라운드 복귀까지 따로 확인해야 합니다.

인증 상태

로그아웃 사용자는 로그인 후 원래 목적지로 돌아가야 하고, 만료 세션은 복구 실패 시 안전한 화면으로 이동해야 합니다.

데이터 준비 상태

원격 설정과 프로필 Registry가 준비되기 전에 라우팅하면 없는 화면이나 잘못된 브랜드가 열릴 수 있습니다.

중복 이벤트

사용자가 알림을 두 번 누르거나 같은 URL 이벤트가 재전달돼도 화면이 중복 쌓이지 않게 이벤트 ID와 소비 상태를 관리합니다.

잘못된 입력

허용하지 않는 scheme, host, route, 파라미터는 거절하고 로그에 민감한 전체 토큰이나 개인정보를 남기지 않습니다.

실제 적용과 설명을 대조하기

확인 항목질문
첫 기준: 앱 생명주기변경 전에 전제와 목적을 확인했는가?
분리 대상: 인증 상태다른 책임과 섞이지 않게 경계를 정했는가?
피할 패턴: 종료 상태에서만 발생하는 초기화 순서 문제본문에서 경고한 패턴이 남아 있지 않은가?
오류와 복구정상 경로뿐 아니라 실패와 되돌리기도 확인했는가?

적용 순서 요약

딥링크와 푸시는 입력 형식만 다를 뿐 외부에서 앱 상태를 바꾸는 같은 종류의 진입입니다. 생명주기, 인증, 초기화, 중복 입력을 한 테스트 표에서 다루면 릴리스 직전에 나타나는 라우팅 오류를 줄일 수 있습니다.


참고한 공식 문서

데이터 디렉터리 페이지를 저가치 콘텐츠로 만들지 않는 법

시설명과 주소 나열을 넘어 선택 기준과 비교, 데이터 한계와 확인일을 제공하는 리포트형 편집 방법을 설명합니다. 설정부터 시작하기 전에 ‘명확한 질문’을 분리해서 봐야 합니다. 지역 시설 전체를 보여 주는 이유를 사용자의 질문으로 바꿉니다. 예를...