Android FCM 토큰 관리 운영 가이드: 서버 동기화 및 만료 처리 방법
앱에 FCM 푸시 기능을 붙일 때, 처음에는 그냥 발급받은 토큰을 서버에 보내서 저장하면 끝나는 줄 알았습니다. 하지만 서비스를 이래저래 직접 운영하다 보니 이게 생각보다 손이 많이 가더군요. 사용자가 앱을 지웠다 다시 깔거나, 기기를 바꾸거나, 혹은 오랫동안 앱을 안 쓰면 토큰이 계속 바뀝니다. 이걸 제대로 관리 안 하면 유효하지 않은 토큰에 계속 푸시를 쏴서 서버 리소스만 낭비되고 발송 성공률 통계도 엉망이 됩니다. 자꾸 놓치는 부분이 생겨서, 실무 운영 중에 막히지 않도록 클라이언트와 서버 측의 FCM 토큰 관리 기준을 메모 형태로 정리해 둡니다. 1. 운영하다 보면 꼭 마주치는 토큰 문제들 처음 구현할 때 대충 넘어가면 나중에 운영계 데이터베이스를 보고 한숨을 쉬게 되는 상황들입니다. 한 번만 저장하고 방치: 최초 실행 때만 토큰을 서버에 보내고 이후 갱신을 안 함. 보안 불감증: 디버깅 편하게 하려고 onNewToken() 에서 받은 토큰을 무심코 로그에 그대로 출력함. 갱신 시각 누락: 서버 DB에 토큰만 딸랑 저장하고, 이 토큰이 언제 업데이트되었는지( updated_at 등) 기록하지 않음. 예외 상황 기준 없음: 로그아웃, 회원 탈퇴, 기기 변경 시 토큰을 어떻게 처리할지 정책이 없음. 실패 응답 방치: FCM 서버가 UNREGISTERED 같은 실패 응답을 주는데도 DB에서 안 지우고 계속 발송함. 재시도 로직 부재: 네트워크 불안정으로 서버 동기화가 실패했을 때, 재시도 없이 그냥 조용히 묻힘. 다기능 기기 미고려: 사용자 한 명이 폰과 태블릿을 동시에 쓸 수 있다는 점(1:N 관계)을 고려하지 않고 DB를 설계함. 운영 관점에서 FCM 토큰은 단순한 문자열이 아닙니다. 사용자, 기기, 앱 설치 인스턴스, 그리고 갱신 시각이 묶인 유기적인 데이터 로 접근해야 합니다. 2. 핵심 개념: FCM 토큰은 '앱 설치 인스턴스' 단위입니다 FCM 등록 토큰은 서버가 특정 사용자가 아니라 특정 기기에 설치된 앱 인스턴스 ...