모바일 시스템 즉, 모바일 앱을 만들면 늘 상 이슈가 되는 것이 푸시입니다. 앱 푸시의 장점은 비용이 들지 않는다 것입니다. 보통은 통신사 SMS를 쓰고, 비용을 좀 더 줄이려고 카카오톡 알림을 사용합니다. 하지만 이것도 비용이 나가기 마련입니다. 하지만 앱 푸시는 공짜입니다. 수만건을 보내도 공짜입니다. 이것이 아주 큰 장점입니다. 하지만 엄청난 단점도 있습니다. 오늘은 그 이야기를 해보려고 합니다.
어느 날 고객에게서 점심때 전화가 왔습니다. 영업을 하다보면 보통 9시 출근전 8시나, 저녁 6시퇴근 후 7시, 그리고 점심 시간대인 12시에 고객에 전화가 온다면 대부분 급한 일입니다.
아니나 다를까 고객의 목소릭 다급했습니다.
"푸시가 하나도 안 갑니다. 지금 며칠째예요."
저는 당황했습니다. 얼른 CS팀에 확인봤습니다. 그러나 시스템에 손댄 적이 없었습니다. 코드도, 서버도 그대로였습니다. 그런데 아이폰 사용자들에게만 푸시가 안 나간다는 겁니다.
원인을 찾아보니 iOS 푸시 인증서(APNs Certificate)가 만료된 거였습니다.
이럴수가!
구글과 애플은 원래 각자 다른 방식을 썼습니다
애플은 처음부터 지금까지 APNS(Apple Push Notification Service)라는 자체 방식을 씁니다. 애플 플랫폼 전용으로 설계된 방식입니다.
안드로이드는 원래 GCM(Google Cloud Messaging)이라는 방식을 썼습니다. 이후 구글이 이를 FCM(Firebase Cloud Messaging)으로 대체했습니다. FCM은 안드로이드, iOS, 웹까지 여러 플랫폼을 동시에 지원하는 방식으로 설계됐습니다.
즉 안드로이드 쪽 푸시 방식은 한 번 크게 바뀌었고, 애플 쪽은 지금까지도 APNS를 그대로 쓰고 있습니다. 저희가 겪은 사고는 바뀌지 않은 애플 쪽, 그중에서도 인증서 갱신을 놓친 경우였습니다.
왜 아무도 인증서를 챙기지 않았을까요
iOS 푸시 인증서는 보통 1년마다 만료됩니다. 매년 갱신해줘야 합니다.
그런데 이 갱신 작업이 일반적인 유상 유지보수 범위에 들어가 있지 않은 경우가 있습니다. 시스템에 오류가 생긴 게 아니라 인증서 유효기간이 끝나는 것뿐이라, 계약서상 "버그 수정"이나 "장애 대응"으로 분류되지 않는 경우가 많습니다.
그러다 보니 누구도 먼저 나서서 챙기지 않습니다. 저희는 새로 발주가 들어와야 작업을 하고, 고객사는 별다른 이상이 없으니 신경 쓰지 않습니다.
그렇게 1년이 지나고, 인증서는 조용히 만료됩니다. 담당자에게 안내 메일이 가지만 잘 열어보지 않습니다. 그러면 어느 날 푸시가 막히게 됩니다.
며칠이 지나야 알게 됩니다
인증서가 만료된 순간부터 아이폰 사용자들에게 푸시가 안 갑니다. 학생들에게 학교의 다양한 공지사항이 나가질 않습니다.
그런데 이게 바로 드러나지 않습니다. 며칠이 지나야 학생들 사이에서 "왜 알림이 안 오지"라는 말이 나오고, 그게 전산팀까지 올라가는 데 또 시간이 걸립니다. 그제야 저희에게 전화가 옵니다.
그 순간 저희도, 고객사도 같이 당황합니다. 누구도 인증서 만료 날짜를 챙기고 있지 않았던 겁니다.
이게 저희만의 특수한 경우는 아니었습니다
나중에 알게 됐는데, 구글 쪽에서도 비슷한 일이 업계 전체에 있었습니다. 구글은 2023년에 레거시 FCM API를 단계적으로 중단하겠다고 예고했고, 2024년에는 실제로 서비스를 완전히 종료했습니다. 여러 글로벌 서비스들이 그 시점까지 새로운 방식으로 전환하지 않으면 푸시가 끊긴다는 공지를 잇따라 냈습니다.
결국 저희가 겪은 인증서 만료 사건과 같은 종류의 문제입니다. 플랫폼(구글, 애플)이 정한 규칙이 어느 시점에 바뀌고, 그 변화에 대응하지 않으면 반드시 서비스가 끊긴다는 것. 누구의 잘못이라기보다는, 아무도 그 시점을 미리 챙기지 않았다는 게 진짜 원인입니다.
그래서 늘 이 지점이 고객사와 저희와 이슈가 발생되기도 합니다.
결국 푸시는 "보냈다"가 아니라 "갔는지 확인"이 핵심입니다
그 사건 이후로 확실해진 게 있습니다.
푸시는 보내는 기능보다 인증서나 키의 만료 시점을 미리 체크하는 체계가 더 중요하다는 것입니다. 구글과 애플의 정책 변화는 저희가 막을 수 없습니다. 하지만 인증서 만료일이 다가오는 걸 미리 알리고, 발송 실패율을 주기적으로 확인하는 구조는 만들 수 있습니다.
그래서 일부 고객사와는 이제 이 부분을 따로 협의합니다. 그래서 어떤 고객들은 매년 유상 유지보수를 갱신할때 아예 iOS계정비를 유지보수비에 포함시켜서 매년 저희 CS팀에서 점검을 합니다.
또한 담당자 메일에 저희 CS 고객 메일도 등록합니다. 만료일 알림과 발송 상태 모니터링을 자체적으로 관리하는 더블체크를 하는 것입니다.
지금 운영 중인 시스템이 있다면, 딱 세 가지만 확인해보십시오.
☐ iOS 푸시 인증서(또는 키)의 만료일을 누가 알고 있습니까?
☐ 만료일이 다가오면 누구에게, 어떻게 알림이 갑니까?
☐ 푸시 발송 실패율을 주기적으로 확인하는 사람이 있습니까?
함께 보면 좋은 글
OS 정책 변경이 시스템에 미치는 또 다른 영향이 궁금하다면. 앱 하나로 안드로이드·iOS 동시에 잡는 기업용 모바일 플랫폼, 왜 아직도 필요한가?