앱에서 전체 사용자에게 푸시 알림을 발송했습니다.
대부분의 사용자에게는 정상적으로 알림이 도착했는데 몇몇 사용자는 알림을 받지 못했다고 문의합니다.
운영자는 관리자 페이지에서 분명히 발송 버튼을 눌렀고 시스템에서도 발송 완료로 표시되고 있습니다.
그렇다면 왜 일부 사용자에게만 알림이 도착하지 않는 걸까요?
앱 푸시 알림은 단순히 서버에서 메시지를 발송하는 기능만 연결한다고 끝나는 기능이 아닙니다.
사용자가 알림 권한을 허용했는지, 현재 사용하고 있는 기기의 푸시 토큰이 정상적인지, 로그인 계정이 변경되지는 않았는지 등 여러 조건이 함께 맞아야 실제 기기까지 알림이 전달될 수 있습니다.
그리고 알림 전달에 실패했을 때 어떤 사용자에게 어떤 이유로 전달되지 않았는지 확인할 수 없다면 운영 과정에서 문제를 파악하기도 어렵습니다.
따라서 앱 푸시 알림을 개발할 때는 알림 발송뿐 아니라 기기 등록, 권한, 토큰 관리, 계정 연결, 실패 기록, 클릭 후 화면 이동까지 전체 흐름을 함께 설계하는 것이 중요합니다.
1. ‘발송 완료’가 모든 사용자에게 전달됐다는 의미는 아닙니다
관리자 페이지에서 푸시 알림을 발송하면 보통 ‘발송 완료’와 같은 결과를 보여줍니다.
이 표현 때문에 운영자는 알림이 모든 사용자 스마트폰에 정상적으로 표시됐다고 생각하기 쉽습니다.
하지만 시스템에서 발송 요청을 정상적으로 처리했다는 것과 실제 사용자의 기기에서 알림이 표시됐다는 것은 서로 다른 단계입니다.
푸시 알림은 일반적으로 다음과 같은 흐름을 거칩니다.
서비스 서버 → 푸시 발송 서비스 → 사용자 기기 → 운영체제 → 앱 알림 표시
이 과정 중 특정 단계에서 문제가 발생하면 일부 사용자에게는 알림이 전달되지 않을 수 있습니다.
따라서 운영 화면의 ‘발송 완료’도 실제 의미를 명확하게 정의할 필요가 있습니다.
단순히 발송 요청을 생성했다는 의미인지, 외부 푸시 서비스가 정상적으로 요청을 받았다는 의미인지, 개별 기기에 대한 처리 결과까지 확인한 것인지에 따라 의미가 달라질 수 있습니다.
2. 사용자가 알림 권한을 거부했을 수 있습니다
푸시 알림이 도착하지 않는 가장 기본적인 이유 중 하나는 사용자가 알림 권한을 허용하지 않은 경우입니다.
앱을 설치했다고 해서 모든 사용자가 자동으로 푸시 알림을 받을 수 있는 것은 아닙니다.
사용자가 처음 앱을 실행했을 때 알림 권한 요청을 거부했거나, 처음에는 허용했지만 이후 스마트폰 설정에서 알림을 꺼놓았을 수도 있습니다.
이런 상황에서는 서버에서 아무리 정상적으로 푸시를 발송하더라도 사용자가 실제 알림을 보지 못할 수 있습니다.
따라서 앱에서는 단순히 권한 요청 팝업을 보여주는 것뿐 아니라 왜 알림 권한이 필요한지 사용자가 이해할 수 있도록 안내하는 것도 중요합니다.
예를 들어 예약 서비스라면 다음과 같이 설명할 수 있습니다.
“예약 확정 및 일정 변경 안내를 받으려면 알림을 허용해주세요.”
단순히 앱 실행 직후 알림 권한부터 요청하는 것보다 실제 알림이 필요한 시점과 목적을 알려주는 것이 사용자에게 더 자연스러울 수 있습니다.
3. 사용자가 알림을 꺼놓은 상태도 고려해야 합니다
사용자가 처음에는 알림을 허용했더라도 이후 스마트폰 설정에서 앱 알림을 비활성화할 수 있습니다.
이 경우 서비스 입장에서는 해당 사용자가 정상 가입 상태이고 푸시 토큰도 저장되어 있기 때문에 알림을 받을 수 있는 사용자처럼 보일 수 있습니다.
하지만 실제 기기에서는 알림이 표시되지 않을 수 있습니다.
서비스 성격에 따라 중요한 알림이 필요한 경우 앱 내부에서 알림 설정 상태를 확인하도록 안내하거나 설정 화면으로 이동할 수 있는 기능을 제공하는 것도 고려할 수 있습니다.
다만 사용자가 알림을 거부한 선택 자체는 존중되어야 하므로 알림을 강제로 활성화시키는 방식이 아니라 필요한 이유와 설정 방법을 안내하는 구조가 적절합니다.
4. 푸시 토큰은 영구적으로 사용할 수 있는 값이 아닙니다
푸시 알림을 보내기 위해서는 일반적으로 사용자 기기를 식별할 수 있는 푸시 토큰을 사용합니다.
서버에서는 이 값을 저장해두고 특정 사용자에게 알림을 보낼 때 사용합니다.
여기서 흔히 놓치는 부분이 있습니다.
한 번 저장한 푸시 토큰을 계속 사용할 수 있다고 가정하면 안 된다는 점입니다.
앱 재설치, 기기 환경 변경, 푸시 서비스 정책 등에 따라 토큰이 변경되거나 더 이상 사용할 수 없는 상태가 될 수 있습니다.
그런데 서버에는 오래된 토큰이 계속 저장되어 있다면 해당 토큰으로 알림을 발송해도 사용자의 현재 기기에는 도착하지 않을 수 있습니다.
따라서 앱 실행이나 로그인 등 적절한 시점에 현재 토큰을 확인하고 서버 정보와 동기화하는 구조를 고려하는 것이 좋습니다.
5. 만료되거나 사용할 수 없는 토큰은 정리해야 합니다
오랫동안 서비스를 운영하면 데이터베이스에 푸시 토큰이 계속 쌓일 수 있습니다.
그중에는 이미 앱을 삭제한 사용자의 토큰이나 더 이상 사용할 수 없는 토큰도 포함될 수 있습니다.
이런 값을 계속 발송 대상으로 유지하면 매번 불필요한 발송 요청이 발생할 수 있습니다.
따라서 푸시 발송 결과에서 더 이상 유효하지 않은 토큰이라고 판단할 수 있는 경우 해당 토큰을 비활성화하거나 제거하는 정책을 고려할 수 있습니다.
예를 들어 다음과 같은 정보를 관리할 수 있습니다.
- 푸시 토큰
- 연결된 사용자
- 기기 종류
- 등록 시각
- 최근 갱신 시각
- 활성 여부
- 최근 발송 실패 여부
이렇게 관리하면 운영 기간이 길어져도 발송 대상을 조금 더 정확하게 유지할 수 있습니다.
6. 한 명의 사용자가 여러 기기를 사용할 수도 있습니다
사용자 한 명에게 푸시 토큰이 하나만 있다고 가정하면 문제가 생길 수 있습니다.
사용자는 스마트폰을 교체할 수도 있고 휴대폰과 태블릿에서 같은 계정으로 로그인할 수도 있습니다.
예를 들어 한 사용자가 기존 스마트폰 A에서 서비스를 이용하다가 새로운 스마트폰 B로 변경했다고 생각해보겠습니다.
서버에서 사용자당 푸시 토큰 하나만 저장하고 있는데 갱신 처리가 제대로 되지 않았다면 알림이 계속 예전 스마트폰 A로 전달될 수 있습니다.
반대로 여러 기기 사용을 지원한다면 사용자 하나에 여러 기기 정보를 연결하는 구조가 필요할 수 있습니다.
서비스 정책에 따라 현재 로그인한 모든 기기에 알림을 보낼지, 마지막으로 사용한 기기에만 보낼지 정할 수 있습니다.
중요한 것은 사용자와 푸시 토큰을 단순히 1:1 관계라고 가정하지 않고 서비스의 실제 로그인 정책에 맞춰 설계하는 것입니다.
7. 로그아웃 후에도 이전 계정의 알림이 도착하면 안 됩니다
하나의 스마트폰을 여러 계정이 사용하는 상황도 생각해야 합니다.
예를 들어 사용자 A가 앱에 로그인하면서 자신의 계정과 현재 기기의 푸시 토큰이 연결됐다고 생각해보겠습니다.
이후 A가 로그아웃하고 사용자 B가 같은 기기에서 로그인했습니다.
그런데 서버에서 푸시 토큰과 계정 연결을 변경하지 않았다면 사용자 A에게 보내야 할 알림이 사용자 B가 사용하고 있는 스마트폰으로 계속 전달될 수 있습니다.
단순한 이벤트 알림이라면 불편한 문제로 끝날 수 있지만 주문, 예약, 메시지 등 개인 정보가 포함된 알림이라면 더 중요한 문제가 될 수 있습니다.
따라서 로그인과 로그아웃 시점에 현재 푸시 토큰이 어떤 사용자 계정과 연결되어 있는지 정확하게 관리해야 합니다.
8. 회원 탈퇴 후 알림도 중단되어야 합니다
회원이 탈퇴했는데도 계속 알림을 받는 상황 역시 피해야 합니다.
서버에 기존 푸시 토큰이 남아 있고 알림 대상 선정 시 탈퇴 상태를 확인하지 않는다면 이런 문제가 발생할 수 있습니다.
따라서 회원 탈퇴나 계정 비활성화 시 알림 대상에서도 제외되도록 처리하는 것이 좋습니다.
서비스에 따라 푸시 토큰 자체를 삭제하거나 계정과의 연결만 해제하는 방식으로 관리할 수 있습니다.
중요한 것은 사용자 계정 상태와 알림 발송 대상이 서로 따로 움직이지 않도록 하는 것입니다.
9. 전체 발송과 특정 사용자 발송은 관리 방식이 다를 수 있습니다
앱에서는 여러 종류의 푸시 알림을 사용할 수 있습니다.
전체 회원에게 보내는 공지 알림도 있고 특정 주문이나 예약과 연결된 개인 알림도 있습니다.
예를 들어 다음과 같이 구분할 수 있습니다.
- 전체 공지 알림
- 특정 그룹 대상 알림
- 개인 사용자 알림
- 주문·예약 상태 변경 알림
- 채팅 메시지 알림
- 마케팅 알림
알림의 성격에 따라 대상자를 선정하는 기준도 달라질 수 있습니다.
전체 알림이라면 현재 활성화된 푸시 토큰을 기준으로 발송할 수 있고, 주문 알림이라면 해당 주문의 사용자와 현재 기기를 정확하게 연결해야 합니다.
마케팅 알림이라면 별도의 수신 동의 여부까지 확인해야 할 수 있습니다.
따라서 푸시 기능을 기획할 때는 단순히 ‘전체 발송’, ‘개별 발송’이라고만 나누기보다 각 알림 유형의 대상 선정 기준을 정하는 것이 좋습니다.
10. 알림 발송 실패 기록을 남겨야 원인을 찾을 수 있습니다
사용자가 “저는 알림이 안 왔어요”라고 문의했을 때 운영자는 어떤 정보를 확인할 수 있을까요?
시스템에 발송 기록이 전혀 없다면 개발자가 서버 로그를 직접 확인해야 할 수도 있습니다.
로그에도 충분한 정보가 없다면 실제로 발송을 시도했는지부터 확인하기 어려워집니다.
따라서 서비스 특성에 따라 푸시 발송 이력을 관리하는 것이 좋습니다.
예를 들어 다음과 같은 정보를 남길 수 있습니다.
- 알림 유형
- 발송 대상 사용자
- 사용한 기기 또는 토큰
- 발송 요청 시각
- 발송 결과
- 실패 코드 또는 실패 사유
이렇게 기록해두면 특정 사용자의 알림이 전달되지 않았을 때 원인을 추적하기 쉬워집니다.
11. 단순히 ‘성공/실패’만 저장하는 것보다 실패 이유가 중요합니다
푸시 발송 결과를 기록하더라도 성공과 실패 두 가지 상태만 저장하면 운영에 충분하지 않을 수 있습니다.
실패에도 여러 원인이 있기 때문입니다.
예를 들어 토큰이 더 이상 유효하지 않은 경우라면 해당 토큰을 정리해야 합니다.
반면 외부 푸시 서비스의 일시적인 문제라면 일정 시간이 지난 뒤 다시 시도할 수 있습니다.
애초에 사용자에게 활성화된 기기 정보가 없는 경우라면 재시도해도 해결되지 않을 수 있습니다.
따라서 실패 결과를 운영 정책과 연결하는 것이 좋습니다.
실패를 기록하는 목적은 단순히 오류 목록을 쌓는 것이 아니라 이후 어떤 조치를 해야 하는지 판단할 수 있게 만드는 것입니다.
12. 일시적인 실패와 영구적인 실패를 구분하면 운영이 쉬워집니다
모든 실패에 같은 방식으로 대응할 필요는 없습니다.
네트워크나 외부 서비스의 일시적인 문제라면 재시도로 해결될 수 있습니다.
반대로 더 이상 존재하지 않는 토큰이라면 몇 번을 다시 보내도 성공하지 않습니다.
따라서 서비스 규모가 커진다면 실패 유형에 따라 다음 행동을 다르게 처리하는 구조도 검토할 수 있습니다.
- 일시적인 실패 → 재시도
- 만료된 토큰 → 토큰 비활성화
- 대상 정보 없음 → 발송 제외
- 외부 서비스 장애 → 별도 실패 기록 후 재처리
이런 구조를 만들어두면 실패한 모든 알림을 운영자가 직접 확인해야 하는 부담을 줄일 수 있습니다.
13. 중요한 알림이라면 푸시 한 가지 채널에만 의존하지 않을 수도 있습니다
푸시 알림은 편리하지만 사용자가 알림 권한을 꺼놓으면 전달할 수 없습니다.
따라서 서비스에서 반드시 전달되어야 하는 중요한 정보라면 푸시 외의 다른 채널을 함께 검토할 수도 있습니다.
예를 들어 예약 취소, 결제 관련 안내, 중요한 일정 변경 등은 서비스 정책에 따라 문자, 알림톡, 이메일 등 다른 방법을 함께 사용할 수 있습니다.
모든 알림을 여러 채널로 보내야 한다는 의미는 아닙니다.
단순 이벤트 안내와 사용자가 반드시 알아야 하는 업무 알림의 중요도를 구분하는 것이 좋습니다.
알림의 목적에 따라 적절한 채널을 선택하면 푸시 알림을 받지 않는 사용자에게도 필요한 정보를 전달할 수 있습니다.
14. 알림을 눌렀을 때 어디로 이동할지도 함께 정해야 합니다
알림이 정상적으로 도착했다고 해서 사용자 흐름이 완성된 것은 아닙니다.
사용자가 알림을 누른 이유는 대부분 해당 내용을 자세히 확인하기 위해서입니다.
예를 들어 다음과 같은 연결이 자연스러울 수 있습니다.
- 주문 배송 알림 → 해당 주문 상세
- 예약 확정 알림 → 해당 예약 상세
- 문의 답변 알림 → 해당 문의 내용
- 새로운 메시지 알림 → 해당 채팅방
- 공지 알림 → 해당 공지사항
모든 알림이 앱 홈 화면으로 연결되면 사용자는 다시 메뉴를 찾아 원하는 정보를 찾아야 합니다.
따라서 푸시 알림 기획에서는 누구에게 보낼지와 함께 사용자가 눌렀을 때 어디로 이동할지도 하나의 흐름으로 설계하는 것이 좋습니다.
15. 로그아웃 상태에서 알림을 누르는 경우도 고려해야 합니다
사용자가 알림을 받았지만 현재 앱에서는 로그아웃 상태일 수도 있습니다.
예를 들어 주문 배송 알림을 눌렀는데 해당 주문 상세는 로그인이 필요한 화면이라고 생각해보겠습니다.
이때 단순히 로그인 화면을 보여준 뒤 로그인이 끝나면 홈으로 보내면 사용자는 다시 주문을 찾아야 합니다.
다음과 같은 흐름을 고려할 수 있습니다.
알림 클릭 → 로그인 필요 확인 → 로그인 → 원래 알림이 가리키던 주문 상세로 이동
이렇게 하면 사용자가 왜 앱을 실행했는지가 로그인 과정에서 사라지지 않습니다.
16. 이미 삭제되거나 접근할 수 없는 콘텐츠도 있습니다
알림을 보낸 시점과 사용자가 알림을 확인하는 시점 사이에는 시간이 있을 수 있습니다.
그 사이 주문이 취소되거나 게시물이 삭제되거나 사용자의 접근 권한이 변경될 수도 있습니다.
예를 들어 며칠 전에 받은 알림을 사용자가 오늘 눌렀는데 해당 이벤트가 이미 종료됐을 수도 있습니다.
이때 존재하지 않는 화면을 무조건 열려고 하면 빈 화면이나 오류가 발생할 수 있습니다.
따라서 콘텐츠가 더 이상 존재하지 않는 경우 “현재 확인할 수 없는 내용입니다”와 같은 안내를 제공하고 안전한 목록 화면으로 이동시키는 등의 예외 처리도 필요합니다.
17. 앱이 켜져 있을 때와 꺼져 있을 때도 테스트해야 합니다
푸시 알림 테스트는 한 가지 상황에서만 하면 충분하지 않을 수 있습니다.
앱의 실행 상태에 따라 알림 처리 과정이 달라질 수 있기 때문입니다.
최소한 다음과 같은 상태를 확인해볼 수 있습니다.
- 앱이 완전히 종료된 상태
- 앱이 백그라운드에 있는 상태
- 앱을 현재 사용하고 있는 상태
앱이 종료된 상태에서 알림을 누르면 앱을 새로 실행하면서 목적지 정보를 처리해야 합니다.
반대로 앱을 이미 사용하고 있다면 현재 화면 위에서 적절한 화면으로 이동해야 합니다.
한 가지 상태에서만 정상 동작하는지 확인하고 출시하면 실제 사용자 환경에서 예상하지 못한 문제가 발생할 수 있습니다.
18. 관리자 페이지의 ‘발송 대상 수’도 정확하게 정의해야 합니다
운영자가 전체 알림을 발송할 때 관리자 페이지에서 “10,000명 발송”이라고 표시한다고 생각해보겠습니다.
그런데 실제 회원 수가 10,000명이라는 이유만으로 발송 대상이 10,000명인 것은 아닐 수 있습니다.
탈퇴 회원, 활성 푸시 토큰이 없는 회원, 마케팅 수신에 동의하지 않은 회원 등이 제외될 수 있기 때문입니다.
따라서 서비스에 따라 다음 숫자를 구분해서 보여주는 방법을 고려할 수 있습니다.
- 전체 대상 사용자
- 실제 발송 대상 기기
- 발송 요청 성공
- 발송 실패
이렇게 하면 운영자가 ‘회원 수’와 ‘실제 푸시 발송 가능 대상’을 혼동하는 상황을 줄일 수 있습니다.
19. 예약 발송이라면 발송 시점의 사용자 상태를 다시 확인해야 할 수 있습니다
관리자 페이지에서 오늘 알림을 등록하고 내일 오전 10시에 발송하도록 예약하는 기능이 있을 수 있습니다.
예약을 생성한 시점과 실제 발송 시점 사이에 사용자 정보가 변경될 수 있습니다.
사용자가 탈퇴하거나 알림 수신 동의를 철회할 수도 있고 새로운 기기로 로그인할 수도 있습니다.
따라서 예약을 생성할 때 발송 대상을 완전히 고정할지, 실제 발송 시점에 최신 사용자와 기기 정보를 기준으로 다시 대상을 선정할지도 정책으로 정할 필요가 있습니다.
서비스 성격에 따라 적절한 방식은 달라질 수 있습니다.
20. 푸시 알림 개발 범위를 정할 때 확인하면 좋은 항목
앱 개발 견적서에 ‘푸시 알림’이라는 항목이 한 줄 들어 있다고 해서 모든 알림 기능의 범위가 동일한 것은 아닙니다.
전체 사용자에게 간단한 공지를 보내는 기능과 사용자별 기기 및 계정 상태를 관리하면서 주문·예약 이벤트에 따라 자동 알림을 발송하는 기능은 개발 범위가 다릅니다.
푸시 알림 기능을 검토할 때는 다음 항목을 함께 확인해보는 것이 좋습니다.
- 권한: 알림 권한을 거부한 사용자를 어떻게 안내할 것인가?
- 토큰: 푸시 토큰을 언제 등록하고 갱신할 것인가?
- 기기 변경: 오래된 기기와 새 기기를 어떻게 구분할 것인가?
- 다중 기기: 한 사용자가 여러 기기를 사용하는가?
- 로그인: 계정이 변경되면 토큰 연결도 변경되는가?
- 로그아웃: 이전 사용자의 개인 알림이 계속 도착하지 않는가?
- 탈퇴: 탈퇴 회원은 발송 대상에서 제외되는가?
- 발송 결과: 성공과 실패를 기록할 것인가?
- 실패 원인: 만료된 토큰과 일시적인 오류를 구분할 수 있는가?
- 화면 이동: 알림 클릭 후 어떤 화면으로 이동하는가?
- 예외 처리: 삭제된 콘텐츠나 권한이 없는 화면은 어떻게 처리하는가?
- 관리자: 운영자가 발송 결과를 확인할 수 있는가?
이런 내용을 미리 정리하면 단순한 발송 기능을 넘어 실제 운영 과정에서 문제의 원인을 확인할 수 있는 알림 시스템의 범위를 정의하기 쉬워집니다.
21. 푸시 알림에서 중요한 것은 ‘보냈다’가 아니라 ‘전체 흐름이 관리되는가’입니다
앱 푸시 알림은 사용자에게 메시지를 보내는 간단한 기능처럼 보입니다.
하지만 실제로는 사용자 계정, 기기, 알림 권한, 푸시 토큰, 발송 서버, 알림 클릭 후 화면 이동까지 여러 요소가 연결되어 있습니다.
따라서 일부 사용자에게 알림이 도착하지 않는 문제가 발생했을 때 단순히 “푸시 서비스가 이상하다”고 판단하기보다 어느 단계에서 문제가 발생했는지 확인할 수 있어야 합니다.
사용자가 알림 권한을 거부했는지, 현재 기기의 토큰이 정상적인지, 다른 계정으로 전환됐는지, 발송 과정에서 실패가 발생했는지 구분할 수 있어야 운영 대응도 쉬워집니다.
결국 안정적인 푸시 알림 기능의 핵심은 알림을 보낼 수 있다는 것보다 발송 대상과 결과를 지속적으로 관리하고 문제가 생겼을 때 추적할 수 있는가입니다.
앱 푸시 알림을 개발하고 있다면
푸시 알림은 발송 API를 연결하는 것만으로 끝나는 기능이 아닙니다.
실제 앱에서는 사용자가 알림 권한을 거부할 수도 있고, 스마트폰을 변경하면서 기존 푸시 토큰이 더 이상 유효하지 않을 수도 있습니다.
하나의 기기에서 로그인 계정을 변경하거나 한 사용자가 여러 기기를 사용하는 상황도 발생할 수 있습니다.
따라서 다음과 같은 전체 흐름을 함께 고려하는 것이 좋습니다.
사용자 로그인 → 기기·푸시 토큰 등록 → 알림 대상 선정 → 알림 발송 → 성공·실패 결과 기록 → 만료 토큰 정리 → 사용자 알림 클릭 → 로그인·권한 확인 → 대상 화면 이동
중요한 알림이라면 실패했을 때 재처리나 다른 알림 채널이 필요한지도 함께 검토할 수 있습니다.
이렇게 발송 전후의 흐름을 함께 설계하면 일부 사용자에게 알림이 도착하지 않았을 때 원인을 찾기 쉬워지고, 운영 과정에서 지속적으로 알림 품질을 관리하기도 수월해집니다.
앱 알림의 발송·이동 흐름이 고민이라면 OneSoft와 기능 범위를 점검해보세요.
개발 문의와 자세한 내용은 OneSoft 홈페이지 에서 확인해보세요.
#앱개발 #푸시알림 #모바일서비스 #서비스운영 #앱푸시 #푸시알림개발 #FCM #모바일앱개발 #앱기획 #외주개발 #OneSoft
