FCM으로 직접 운영할까, OneSignal 같은 메시징 플랫폼을 도입할까

운영 방식의 판단 기준

주문 상태가 바뀌면 푸시를 보내는 앱을 생각해보자. 마케팅팀이 “가입 후 아직 구매하지 않은 고객에게만 보내고, 구매하면 후속 알림을 멈추자”고 요청합니다. 대상자를 추출하고 발송 조건을 고치고, 결과를 확인할 때마다 개발팀의 일정이 필요하다면 이제 검토할 것은 푸시 발송 API만이 아닙니다.

거래성 알림의 조건이 안정적이고 개발팀이 변경·관측·장애 대응을 감당할 수 있다면 FCM 중심의 직접 운영이 합리적입니다. 반대로 캠페인 담당자가 대상·시점·후속 행동을 자주 바꿔야 한다면 OneSignal 같은 플랫폼의 운영 도구를 검토할 이유가 커집니다. 기존 거래성 알림은 유지하고 마케팅 영역부터 도입하는 병행 방식도 선택지입니다. 이는 사용자 수로 정하는 기준이 아니라, 필요한 업무와 책임을 기준으로 한 판단입니다.

다만 “FCM은 개발자만 쓰고, 플랫폼은 개발 없이 쓴다”는 비교는 정확하지 않습니다. Firebase에는 비개발자가 메시지를 작성하는 Notifications composer와 Analytics 기반 타기팅·메시지 실험 기능이 있습니다. OneSignal에도 SDK 설정, 사용자 식별과 업무 데이터 연동 같은 구현 작업이 남습니다.^{[2][3][9][11]}

선택의 단위는 전송, 고객 데이터, 캠페인 변경, 관측, 통제, 이전까지 포함한 운영 방식입니다. 어느 기능이 더 많은지보다, 도입 뒤 누가 어떤 일을 반복할지를 먼저 적어야 합니다.

먼저 비교 대상을 같은 높이에 놓자

이 글에서 ‘직접 운영’은 Google의 전송 인프라까지 직접 만든다는 뜻이 아닙니다. FCM과 필요한 Firebase 구성 요소를 사용하되, 자사 백엔드와 운영 절차를 조합하는 방식입니다. FCM은 Android뿐 아니라 Apple 플랫폼과 웹 등을 지원하며 발송 서버와 수신 클라이언트가 함께 구성돼야 합니다.^[1][4]

Notifications composer를 쓰면 모든 발송을 코드로 작성할 필요는 없습니다. 다만 콘솔에서 가능한 타기팅과 서버 API로 구현할 수 있는 기능은 일대일로 같지 않습니다. Notifications composer의 메시지 A/B 테스트는 공식 안내상 Android·iOS 앱을 대상으로 하며 Google Analytics 연계가 필요합니다. Firebase가 웹 A/B 테스트도 지원한다는 사실을 곧바로 웹 푸시 메시지 실험의 동일 지원으로 해석해서는 안 됩니다.^[2][3][21]

OneSignal은 사용자·구독 정보, 세그먼트, 메시지 작성과 Journeys를 하나의 운영 환경에서 다루게 합니다. 하지만 전송망이 FCM과 완전히 분리되는 것은 아닙니다. Google Play 배포 Android 앱의 푸시는 FCM 인증 설정을 사용하고 Apple 플랫폼에는 APNs 연결을 설정합니다. FCM을 통한 Apple 푸시 역시 APNs를 거칩니다. FCM과 OneSignal을 함께 쓴다는 이유만으로 독립적인 푸시 전송망 두 개를 확보하는 것은 아닙니다.^{[9][10][4][13]}

OneSignal의 Journeys는 앱·웹 푸시, 이메일, SMS, 인앱 메시지를 연결하는 운영 도구입니다. 여러 채널이 필요하다면 이런 구성의 가치를 검토할 수 있지만 우리 서비스의 채널 설정과 데이터 연동이 생략되는 것은 아닙니다. 실제 대상 국가·채널·계정에서 필요한 발송이 가능한지도 별도로 확인해야 합니다.^[13]

따라서 ‘FCM API 하나’와 ‘플랫폼 전체’를 비교해서도, Firebase 생태계 전체를 FCM이라는 이름에 포함해 모든 운영 기능이 이미 준비됐다고 가정해서도 안 됩니다.

기능표 대신 운영 책임표를 채워보자

아래 표는 공식 기능의 제공 조건을 바탕으로 구성한 운영 책임 배분 예시다. ‘직접 개발’에는 기존 시스템 재사용과 설정·통합 작업도 포함합니다. ‘제공됨’은 해당 도구가 있다는 뜻이지, 우리 서비스의 업무 규칙과 운영 책임까지 자동으로 완성된다는 뜻은 아닙니다.

특히 권한은 계정 수만 확인해서 끝낼 항목이 아닙니다. OneSignal의 현재 역할 문서는 작성은 가능하지만 운영 메시지의 발송·활성화는 못 하는 Composer와 발송까지 맡는 Editor를 구분하며 두 역할을 Professional·Enterprise 플랜에서 제공한다고 안내합니다. 이 역할 분리가 내부 승인 절차 전체를 대신하는 것은 아니며, 다운그레이드 시 권한이 어떻게 바뀌는지도 확인해야 합니다.^[15]

관측에서도 명칭을 그대로 같은 지표로 취급하지 말자. OneSignal의 Confirmed receipt는 기기 SDK가 돌려주는 수신 확인으로, 전송 서비스가 요청을 받아들였다는 의미의 Delivered와 다릅니다. 유료 플랜·SDK 등의 조건이 있고 iOS에는 추가 설정이 필요합니다. FCM도 보고서와 데이터 내보내기 수단이 있으므로 ‘직접 운영은 관측 불가’로 분류할 수 없습니다. 어느 쪽이든 전송 접수, 기기 수신, 사용자 반응, 구매 같은 업무 결과를 구분해 봐야 합니다.^[16][7]

세 가지 상황에서는 무엇이 달라질까

거래성 알림 위주의 작은 앱: 직접 운영이 충분할 수 있다

설계 예시. 예약 확정과 일정 변경 알림을 보내며, 조건 변경이 드물고 기존 백엔드에 필요한 업무 데이터가 있습니다. 개발팀이 발송 결과 확인과 장애 대응을 맡을 수 있다면 FCM 중심 운영을 유지하는 편이 단순할 수 있습니다. 필요하지 않은 다단계 캠페인을 위해 새로운 사용자 데이터 체계와 운영 도구를 추가할 이유는 약합니다.

반대 조건도 있습니다. 앱은 작아도 비개발 담당자가 문구·대상·시점을 자주 바꾸고, 매번 개발 요청을 기다려야 한다면 플랫폼 도입을 먼저 검토할 수 있습니다. 다만 먼저 Composer로 충분한지 확인합니다. ‘작은 앱이므로 직접 개발’도, ‘마케팅 담당자가 있으므로 별도 플랫폼’도 자동으로 성립하지 않습니다.

마케팅팀이 캠페인을 자주 바꾸는 서비스: 변경 업무를 얼마나 넘길지가 핵심이다

설계 예시. 가입 후 미구매 고객, 갱신 시점을 앞둔 고객, 최근 활동이 줄어든 고객을 나눠 후속 메시지를 바꿉니다. 데이터가 준비돼 있고 CRM 담당자가 실제로 시나리오를 운영한다면, 세그먼트와 Journeys에서 변경할 수 있는 범위가 도입 가치가 됩니다.^[12][13]

그러나 구매 여부가 전달되지 않는데 플랫폼만 도입하면 담당자는 여전히 개발팀을 기다립니다. OneSignal의 Custom Events는 앱·웹·외부 시스템이 보내는 데이터입니다. 이벤트 수집, Journey 트리거, 이벤트 기반 세그먼트 필터는 서로 다른 기능입니다. 이벤트 기반 세그먼트는 저장 기능 활성화가 필요하며, 공식 문서는 저장 기능을 앱별로 순차 제공한다고 안내합니다. 필수 캠페인 조건과 저장 기능을 실제 계정에서 사용할 수 있는지 확인해야 합니다.^[14][12][22]

기존 Composer와 사내 운영 화면만으로 필요한 변경을 이미 처리한다면, 캠페인 수가 늘었다는 이유만으로 즉시 이전할 필요는 없습니다. 새 플랫폼이 제거하는 반복 업무와 새로 생기는 연동·교육 업무를 비교하자.

데이터·권한 통제가 복잡한 조직: 규모보다 필수 조건을 먼저 확인하자

설계 예시. 여러 사업부가 같은 고객을 다루고, 작성자와 발송자를 분리하며 어떤 데이터가 외부로 전달되는지 통제해야 합니다. 이 경우에는 캠페인 기능보다 데이터 경로·접근 범위·감사와 내보내기 요건부터 검토하는 편이 낫습니다.

플랫폼이 필요한 역할과 관리 기능을 충족하면 자체 도구의 개발 부담을 줄일 수 있습니다. 반대로 기존 내부 통제 체계가 잘 구축돼 있고 필수 조건을 외부 플랫폼에서 충족하기 어렵다면, 직접 운영의 범위를 유지할 이유가 있습니다. 다만 FCM 직접 운영도 외부 클라우드 전송 서비스를 사용하는 구조다. ‘자체 백엔드에서 발송한다’와 ‘데이터가 조직 밖으로 전혀 나가지 않는다’를 혼동해서는 안 됩니다.^[4]

이 조직에 필요한 결론은 ‘엔터프라이즈 플랜’이라는 이름이 아니라, 어떤 데이터·권한·기록 요건을 누가 검증하고 책임질지에 대한 합의입니다.

월 구독료 대신 같은 범위의 TCO를 계산하자

Firebase 가격표는 FCM을 별도 이용료가 없는 제품으로 안내합니다. 그러나 백엔드 실행, 데이터 저장·분석, 운영 인력까지 무료라는 뜻은 아닙니다. OneSignal 역시 플랜 이름만으로 총비용이 정해지지 않으며, 사용 채널·과금 단위·기능·지원 범위를 함께 확인해야 합니다.^[5][19][20]

아래는 비용 검토용 설계 예시다. 두 방식에 같은 비교 기간과 같은 서비스 범위를 적용하고 기존 시스템을 재사용할 수 있는 부분은 별도로 표시합니다.

비교 기간을 H개월로 두면 다음처럼 정리합니다.

총비용(H개월) = 초기 구현·전환비 + H개월 동안의 플랫폼·인프라·운영 인력·별도 지원비 합계 + 비교 범위에 포함한 종료·이전비

인력 비용은 ‘업무별 소요 시간 × 조직이 정한 시간당 비용’으로 계산하되, 같은 작업을 초기 구현과 월 유지보수 양쪽에 중복해서 넣지 않습니다. 아직 발생하지 않은 장애 손실이나 미래 이전비는 확정 지출과 분리해 시나리오 항목으로 표시합니다. 플랫폼 도입으로 확보한 시간을 금액으로 환산하더라도 그것이 곧 현금 지출 감소를 뜻하지는 않습니다.

OneSignal 비용을 검토할 때는 모바일 MAU와 웹 푸시 구독자, 이메일 발송량을 같은 단위로 취급하지 않습니다. 특히 MAU는 단순한 회원 수나 푸시 수신 동의자 수와 같지 않으며, 현재 과금 문서는 모바일 Subscription을 기준으로 설명합니다. 실제 계정의 과금 모델·측정 기간과 필요한 이벤트 저장·내보내기 비용까지 맞춰 확인해야 합니다.^[20]

이미 OneSignal을 사용 중이고 무료·유료 경계와 플랜 변경을 검토하고 있다면, OneSignal 유료 플랜 전환 안내서에서 별도의 판단 항목을 확인합니다. 이 글의 직접 운영·플랫폼 도입 결정과, 특정 플랫폼 안의 플랜 선택은 서로 다른 결정입니다.

도입 판단은 이 순서로 진행하면 된다

다음 흐름은 제품의 공식 도입 기준이 아니라, 앞의 책임표를 실제 결정으로 연결하기 위한 편집자의 판단 절차다.

첫째, 필수 조건에서 탈락하는 선택지를 먼저 제외합니다. 필요한 채널과 기기 환경, 데이터 경로, 권한 분리, 기록과 내보내기 요건을 적습니다. 반드시 필요한 기능이 지원되지 않거나 제공 조건을 확인하지 못했다면, 가격 비교보다 그 확인이 먼저입니다.

둘째, 현재 운영에서 막히는 일을 찾습니다. 발송 기능의 부재인지, 업무 데이터의 부재인지, 캠페인 변경 대기인지, 장애 대응 담당자의 부재인지 구분합니다. 직접 운영의 기존 도구로 해결할 수 있고 담당자도 있다면 유지·보완안을 남깁니다. 플랫폼 도입이 모든 종류의 병목을 해결한다고 가정하지 않습니다.

셋째, 플랫폼이 실제로 없애는 반복 업무를 확인합니다. 대표 시나리오를 하나 골라 대상 변경부터 검수, 발송, 결과 확인까지 재현합니다. 비개발 담당자가 독립적으로 처리한 범위, 여전히 개발이 필요한 범위, 요구한 통제가 작동하지 않은 부분을 기록합니다. 이미 운영 중인 시스템이 있다면 재구축 비용이 아니라 앞으로 발생할 추가 비용과 개선 효과를 비교합니다.

넷째, 직접 운영·플랫폼 도입·병행 중 책임이 명확한 안을 고릅니다. 직접 운영은 변경과 장애를 맡을 담당자가 있어야 합니다. 플랫폼 도입은 데이터 공급과 캠페인 운영의 담당자가 있어야 합니다. 담당자가 없는 일을 도구 이름으로 덮지 않는 것이 공통 조건입니다.

병행을 택한다면, 거래성 알림은 기존 백엔드에 두고 마케팅 캠페인부터 플랫폼으로 옮기는 식으로 범위를 나눌 수 있습니다. 이때 두 경로가 같은 업무 알림을 중복 발송하지 않도록 이벤트별 발송 주체, 공통 식별 기준, 수신 거부 반영, 통합 관측과 종료 조건을 먼저 정합니다. 이는 병행 운영의 설계 조건이지, 두 SDK를 함께 설치하면 자동으로 보장되는 기능이 아닙니다.

결정 전에 ‘남는 일’까지 합의하자

메시징 업무가 좁고 안정적이거나, 복잡하더라도 기존 시스템과 담당자가 그 범위를 감당하는 팀은 직접 운영을 유지할 이유가 있습니다. 플랫폼이 과한 팀은 사용할 운영 기능보다 도입·연동·학습 부담이 더 큽니다. 반대로 플랫폼이 적합한 팀은 준비된 데이터를 바탕으로 담당자가 캠페인을 반복 개선하며 그 변경 업무를 플랫폼 안으로 옮길 수 있습니다.

가장 싼 전송 수단이나 가장 긴 기능 목록을 고르는 것으로는 결정이 끝나지 않습니다. 우리 팀이 계속 책임질 일과 외부 도구에 맡길 일을 나눈 뒤, 같은 범위의 비용과 통제 조건을 비교하는 것이 FCM 직접 운영과 메시징 플랫폼 도입을 가르는 판단의 출발점입니다.

플랫폼 도입을 결정했지만 SDK·데이터 연동, 핵심 캠페인 검증과 운영 인계의 범위를 정하지 못했다면, IXC의 앱 푸시 도입·온보딩 서비스에서 협의할 항목을 검토합니다.