앱 푸시 직접 구현·도구 도입 판단 안내서

FCM과 APNs는 그 자체로 발송 인프라입니다. 앱에 SDK를 넣고 단말 토큰을 받아 서버에서 호출하면 알림은 그대로 나갑니다. 이 구조만으로 충분한 서비스가 적지 않습니다. 보내는 메시지가 주문 상태나 예약 확인처럼 거래에 붙어 있고 받는 사람이 그 거래의 당사자 한 명으로 이미 정해져 있으며 보내는 시점이 사건이 일어난 순간이라면 도구가 대신할 일이 거의 없습니다. 대상과 시점이 코드 안에서 결정되기 때문입니다. 전체 공지를 가끔 한 건 내보내는 수준도 같습니다. 이 구간에서 도구를 붙이면 값은 늘고 바뀌는 것은 없습니다. 판단은 기능 목록이 아니라 지금 보내는 메시지의 성격에서 출발합니다. 도구를 파는 자리에서는 이 구간이 잘 언급되지 않습니다. 직접 구현을 그대로 두라는 답이 상대의 이익과 어긋나기 때문입니다. 그래서 검토를 시작할 때 이 구간부터 스스로 그어 두는 편이 낫습니다.

판단은 세는 데서 시작합니다. 지난 석 달에 나간 알림을 세 갈래로 나눕니다. 거래에 붙은 알림, 서비스 공지, 마케팅 발송입니다. 갈래마다 월 몇 건이 나갔는지, 대상을 누가 정했는지, 실패했을 때 누가 알았는지를 같은 표에 적습니다. 마케팅 발송 칸이 비어 있고 앞의 두 갈래만 도는 서비스라면 지금 구조가 맞습니다. 세 칸이 다 차 있는데 대상을 정하는 자리가 전부 개발이면 그 표가 이미 답을 냅니다. 여기서 함께 적어 둘 것이 하나 더 있습니다. 나간 알림 가운데 사람이 골라 보낸 것과 사건이 자동으로 낸 것의 비율입니다. 앞쪽 비중이 커지는 중이라면 그 흐름은 되돌아가지 않습니다.

한계는 어느 날 기능이 모자라서 오지 않습니다. 일하는 방식에서 먼저 드러납니다. 신호는 대체로 다섯입니다. 첫째, 보낼 대상을 정할 때마다 개발자가 데이터베이스에 조건을 걸어 목록을 뽑습니다. 둘째, 보낸 뒤에 몇 명에게 닿았고 몇 명이 눌렀는지 답하지 못합니다. 셋째, 새벽에 나가지 않게 막거나 같은 사람에게 하루 몇 건까지만 보내는 규칙이 코드 곳곳에 흩어져 있습니다. 넷째, 실패한 토큰을 지우고 다시 보내는 처리를 직접 짜서 유지합니다. 다섯째, 푸시로 시작한 일이 웹 푸시와 이메일, 인앱 안내로 늘어납니다. 하나만 해당하면 아직 손볼 만합니다. 셋 이상이 겹치면 다음 분기에도 같은 요청이 같은 방식으로 반복됩니다.

토큰은 앱을 지우거나 오래 열지 않으면 무효가 되고 재설치하면 새로 발급됩니다. 무효 토큰을 그대로 두면 발송 성공률이 실제와 어긋나고 실패 응답을 읽어 정리하는 처리가 없으면 그 값은 계속 부풀어 있습니다. 한 사람이 기기를 두세 대 쓰면 같은 알림이 두세 번 갑니다. 사람 단위로 묶는 식별자를 두지 않으면 이 중복을 막을 자리가 아예 없습니다. 로그아웃과 탈퇴에서 구독을 어떻게 처리할지, 권한을 거절한 사용자를 어디에 표시할지도 같은 자리에서 정해야 합니다. 여기에 운영체제와 스토어의 알림 정책이 바뀔 때마다 따라가는 일이 더해집니다. 이 일들은 기능 요구로 올라오지 않아 일정표에도 잡히지 않습니다. 그래서 직접 구현의 실제 비용은 첫 구현 공수를 세는 자리에서 늘 빠집니다.

캠페인 하나를 내보내려고 대상 조건을 전달하고 목록을 받고 문구를 확인하고 발송을 요청하면 실제로 나가기까지 며칠이 걸립니다. 그 며칠 때문에 하려던 캠페인의 절반은 시작조차 못 합니다. 도구를 사는 판단의 진짜 근거가 기능이 아니라 여기에 있는 경우가 많습니다. 그런데 이 값은 아무도 세지 않아서 품의 문서에 오르지 못합니다. 지난 분기에 요청한 발송이 몇 건이었는지, 각각 요청부터 발송까지 며칠이 걸렸는지, 그중 취소되거나 시기를 놓친 건이 몇 건인지 적으면 그 표가 견적서보다 정확한 판단 재료가 됩니다. 반대로 그 표를 적어 봤더니 요청이 분기에 두세 건이라면 지금은 도구를 살 때가 아닙니다. 리드타임은 도구를 붙인다고 저절로 사라지지도 않습니다. 마케터가 직접 만들 세그먼트에 필요한 데이터가 들어와 있지 않으면 요청은 도구 화면 앞에서 다시 개발로 넘어갑니다. 그래서 이 표에는 요청마다 어떤 데이터가 없어서 밀렸는지도 함께 적습니다.

첫째는 과금 단위입니다. 활성 사용자 수를 세는 방식과 발송량을 세는 방식은 같은 규모에서 전혀 다른 값을 냅니다. 앱 설치가 늘어나는 서비스와 이메일 발송이 늘어나는 서비스는 봐야 할 축 자체가 다릅니다. 둘째는 세그먼트가 설 수 있는지입니다. 도구가 아무리 좋아도 사용자 속성과 행동 이벤트가 들어오지 않으면 조건이 서지 않습니다. 도입 공수의 절반은 도구가 아니라 이 데이터를 보내는 앱과 서버 쪽에 있습니다. 셋째는 자동화의 깊이입니다. 진입 조건과 대기, 분기, 종료 조건을 화면에서 정하지 못하면 마케터는 결국 개발자를 다시 부릅니다. 넷째는 계정과 데이터의 소유입니다. 계정이 우리 명의로 열리는지, 설정과 실험 결과가 계약이 끝난 뒤에도 남는지를 계약 전에 확인합니다.

FCM과 APNs는 도구를 붙여도 사라지지 않습니다. 도구는 그 위에 앉는 계층이고 실제 전달은 그대로 플랫폼이 맡습니다. 그래서 스토어 인증서와 발송 자격 증명 관리, 앱에서 권한을 언제 어떤 화면으로 묻는가, 토큰을 사람과 잇는 식별자 설계는 도구를 사도 우리 일로 남습니다. 도구가 대신하는 것은 대상 추출과 발송 이력, 빈도와 시간대 제어, 채널 확장입니다. 이 경계를 도입 전에 그어 두지 않으면 도구가 해 줄 줄 알았던 일이 몇 주 뒤 개발 백로그로 돌아옵니다. 견적을 받을 때 경계선을 문장으로 적어 확인받는 편이 빠릅니다. 앱 업데이트가 필요한 항목이 무엇인지도 같은 자리에서 갈라 둡니다. 스토어 심사를 기다려야 하는 항목이 섞여 있으면 도입 일정이 그 주기에 묶입니다.

첫째는 토큰과 수신 동의입니다. 기존 SDK가 쥔 구독 정보를 보존해 옮길 수 있는지, 옮기지 못해 사용자에게 권한을 다시 물어야 하는지에 따라 전환 비용이 몇 배로 갈립니다. 둘째는 지금 돌아가는 발송 조건입니다. 코드에 흩어진 조건을 세그먼트와 트리거로 다시 적는 일은 이전이 아니라 재구축입니다. 무엇이 어떤 조건으로 나가고 있는지 아무도 전부 알지 못하는 상태에서 이 작업이 시작되는 일이 흔합니다. 셋째는 딥링크입니다. 알림을 눌렀을 때 앱이 설치된 단말과 설치되지 않은 단말이 각각 어디로 떨어지는지 규격이 바뀝니다. 넷째는 스토어 인증서와 발송 자격 증명입니다. 이것을 새 도구에 등록할 권한이 누구에게 있는지 확인해 두지 않으면 전환 주간에 발송이 멈춥니다.

직접 구현과 도구는 양자택일이 아닙니다. 거래에 붙은 알림은 서버가 직접 보내고 마케팅 성격의 발송만 도구로 옮기는 구성이 실제로 자주 나옵니다. 이때 정할 것은 하나입니다. 수신 동의와 빈도 제한을 어느 쪽이 최종적으로 판정하는지입니다. 두 경로가 각자 판단하면 거부한 사용자에게 알림이 나가고 하루 한 건 규칙이 두 배로 깨집니다. 판정하는 자리를 한 곳으로 정하고 다른 쪽은 그 결과를 물어 보내게 하면 이 구성은 오래 갑니다. 나눌 때는 채널도 함께 나눕니다. 같은 채널을 두 경로가 함께 쓰면 성과 지표가 어느 쪽 것인지 읽히지 않습니다.

셋을 봅니다. 첫째, 도구 계약과 구현을 같은 곳이 맡는지 봅니다. 라이선스만 파는 곳은 SDK 연동과 이벤트 설계에서 손을 떼고 구현만 하는 곳은 플랜과 계약 조건에 답하지 못합니다. 둘째, 우리 앱과 서버 코드에 어디까지 손대는지가 범위로 적혀 있는지 확인합니다. 이벤트를 심는 일이 견적에 없으면 그 일은 내부 개발 일정으로 돌아옵니다. 셋째, 끝난 뒤 무엇이 남는지 묻습니다. 이벤트와 속성 정의서, 채널 셋업 기록, 실제로 발송을 마친 캠페인이 우리 계정 안에 남아야 담당자가 바뀌어도 같은 일을 다시 사지 않습니다. IXC는 원시그널 한 도구로 이 구간을 맡습니다. FCM 직접 운영에서 넘어오는 전환이 취급 범위에 들어 있고 국내 계약과 원화 결제, 세금계산서 발행도 같은 창구에서 처리합니다.