일반적인 SaaS 광고 미디에이션 SDK를 연동하면 모든 광고 요청, 광고 노출, 사용자 식별자가 담긴 이벤트 스트림이 먼저 공급업체 서버로 전송됩니다. 공급업체는 이 데이터를 처리하고 보강한 뒤, 경우에 따라 민감 정보를 가린 사본을 개발사의 데이터 웨어하우스로 보내줍니다. 개발사가 데이터를 확인할 때쯤이면 이미 직접 통제할 수 없는 시스템을 거친 상태입니다.
Firebase 네이티브 SDK는 반대로 작동합니다. 이벤트는 먼저 개발사 소유의 Firestore와 BigQuery에 기록됩니다. 개발사가 공급업체의 데이터를 가져오는 것이 아니라, 공급업체가 개발사의 프로젝트에서 데이터를 읽습니다. 처음 GDPR 감사를 받기 전까지는 이 차이가 이론적인 이야기처럼 들릴 수 있습니다.
자체 프로젝트에서 데이터를 소유하면 달라지는 점
- 삭제 요청은 Firestore 쿼리 하나로 처리 — 공급업체에 지원 티켓을 제출하거나 SLA에 따른 처리를 기다릴 필요 없음
- 내보내기 스키마를 직접 관리하므로 BigQuery 비용 예측 가능
- 공급업체의 릴리스 일정이 아닌 자체 일정에 맞춰 스키마 마이그레이션 진행
- 공개해야 할 개인정보 재수탁자 목록이 줄어들며, 대폭 축소되는 경우도 많음
영업 미팅에서는 아무도 말해주지 않는 트레이드오프
Firebase 네이티브 방식에도 비용은 듭니다. 기존에는 공급업체에 맡겼을 데이터 저장과 쿼리 처리 비용을 Google에 직접 지불하게 됩니다. DAU 500만 앱의 BigQuery 요금은 월 400~1,200달러 수준입니다. 무시할 금액은 아니지만, 이를 통해 지켜내는 광고 수익에 비하면 미미한 비용입니다.
할당량도 고려해야 합니다. Firestore의 초당 쓰기, BigQuery 스트리밍 삽입, Cloud Function 콜드 스타트는 실제 운영상의 제약입니다. SaaS SDK에서는 공급업체가 이를 뒤에서 처리합니다. Apps Kit SDK는 쓰기를 배치 처리하는 백프레셔 계층을 기본 제공해, DAU 100만 미만인 대부분의 앱이 무료 등급 할당량 안에서 작동하도록 합니다.
Google에 실제로 지불하는 비용
비용 구조는 단순합니다. 바로 그 점이 핵심입니다. 모든 비용 항목을 자체 결제 콘솔에서 확인할 수 있습니다. 아래는 2026년 실제 운영 중인 Apps Kit SDK 환경에서 관측한 비용 범위입니다. 기본 제공되는 백프레셔 계층과 BigQuery 파티션의 90일 만료 설정을 적용한 기준입니다.
- DAU 100만: Firestore 40~90달러, BigQuery 저장 공간 20~50달러, BigQuery 쿼리 30~80달러, Cloud Functions 10~30달러 — 월 합계 250달러 미만
- DAU 500만: Firestore 180~350달러, BigQuery 저장 공간 100~220달러, BigQuery 쿼리 120~400달러, Cloud Functions 40~110달러 — 월 합계 400~1,200달러
- DAU 2,500만: Firestore 700~1,400달러, BigQuery 저장 공간 450~900달러, BigQuery 쿼리 500~1,800달러, Cloud Functions 150~400달러 — 월 합계 1,800~4,800달러
실제 청구액을 줄이는 비용 최적화 설정
위 비용 범위의 차이는 대부분 세 가지 결정에서 나옵니다. 첫째, BigQuery에 스트리밍 방식으로 삽입할지, GCS를 통해 배치 처리할지입니다. 배치 처리를 선택하면 보고서 반영이 30분 늦어지는 대신 데이터 수집 비용을 80% 이상 줄일 수 있습니다. 둘째는 파티션 만료 기간입니다. 지금까지 운영에 필요했던 모든 쿼리는 90일치 데이터로 충분했습니다. 그보다 오래된 원시 데이터는 콜드 스토리지에 보관하는 것이 적절합니다. 셋째는 쿼리 관리입니다. 대시보드 하나에서 1년치 광고 노출 데이터를 범위 제한 없이 SELECT *로 조회하면, 나머지 비용을 모두 합친 것보다 더 많은 비용이 발생할 수 있습니다.
2026년에 이 문제가 더 중요해진 이유
올해 두 가지 규제 변화로 판단 기준이 달라졌습니다. DMA의 데이터 이동성 요건이 이제 EU 최종 사용자 데이터를 처리하는 모든 공급업체에 적용되며, 인도 DPDP의 시행 유예 기간은 3월에 종료됐습니다. 두 규제 모두 요청이 들어오면 특정 사용자와 연결된 모든 이벤트를 빠짐없이 내보낼 수 있어야 한다는 것을 전제로 합니다.
SDK 공급업체의 시스템이 기준 원장이라면 해당 업체의 내보내기 도구에 의존해야 합니다. 자체 Firebase 프로젝트가 기준 원장이라면 이미 작성할 줄 아는 쿼리로 데이터를 내보내면 됩니다.
GDPR / DPDP 감사는 실제로 어떻게 진행될까?
규제기관이나 대기업 고객이 감사를 요청할 때 요구하는 자료는 네 가지입니다. 최종 사용자 데이터를 취급하는 모든 개인정보 재수탁자 목록, 지정된 사용자의 전체 데이터 내보내기 파일, 삭제 증빙, 데이터 보관 일정에 대한 설명입니다. SaaS SDK를 사용한다면 첫 번째는 공급업체의 공개 문서를 읽고 작성하고, 다음 두 가지는 지원 티켓을 제출해 확보하며, 네 번째는 추정에 의존하게 됩니다.
Firebase 네이티브 환경에서는 네 가지 모두 직접 관리하는 쿼리로 확인할 수 있습니다. 재수탁자는 프로젝트에서 사용하는 GCP 서비스 목록으로 확인합니다. 사용자 데이터 내보내기는 Firestore 쿼리 하나와 BigQuery 쿼리 하나로 처리하며, 둘 다 SDK에 템플릿으로 포함되어 있습니다. 삭제 증빙은 처리된 행 수를 반환하는 Cloud Function으로 확보합니다. 보관 기간은 콘솔에 표시되는 파티션 만료 정책으로 확인합니다. 2주 동안 허둥대며 준비하던 감사가 반나절 작업으로 바뀝니다.
어트리뷰션을 유지하면서 SaaS SDK에서 마이그레이션하기
팀들이 마이그레이션을 두려워하는 이유는 한 번의 릴리스로 모든 것을 바꿔야 한다고 생각하기 때문입니다. 저희는 그렇게 진행하지 않습니다. Firebase 네이티브 SDK를 기존 SaaS SDK와 함께 2~4주간 운영합니다. 새 SDK가 새 파이프라인에 데이터를 기록하는 동안 기존 SDK는 모든 기존 대시보드와 MMP에 계속 데이터를 공급합니다.
- 1주 차: Firebase 네이티브 SDK를 섀도 모드로 연동하고, 사용자에게 보이는 변경 없이 BigQuery에서 이벤트 데이터 일치 여부 검증
- 2주 차: 어트리뷰션 포스트백을 Firebase 네이티브 경로로 전환하되, 광고 미디에이션은 기존 SDK로 유지
- 3주 차: 광고 미디에이션을 전환하고, 데이터 불일치 시 판단 기준으로 삼을 수 있도록 SaaS SDK는 읽기 전용 이벤트를 계속 전송
- 4주 차: 다음 앱 업데이트에서 SaaS SDK를 제거해 의존성 완전히 해소
여전히 SaaS가 유리한 경우
현재 Firebase를 사용하지 않고 도입 계획도 없는 팀이라면 Firebase 네이티브 SDK의 운영 부담은 분명히 존재합니다. 출시 후 SDK 운영에 신경 쓰고 싶지 않은 스튜디오나 데이터 소유권이 아직 전략적 자산이 아닌 프로토타입에는 SaaS 광고 미디에이션이 적합합니다. 이는 기술적인 선택이 아닙니다. 감사 추적 기록을 누가 소유하게 할 것인지에 대한 선택입니다.
이벤트 스트림을 소유한다는 것은 단순히 개인정보 보호에 대한 입장을 밝히는 일이 아닙니다. 다음 공급업체 계약에서 주도권을 쥐고 협상할지, 스크린샷 한 장에 의존해 협상할지를 가르는 차이입니다.
이번 분기에 해야 할 일
이미 Firebase Analytics를 사용하고 있다면, 스스로 인식하지 못했을 뿐 Firebase 네이티브 광고 SDK 도입 준비의 60%는 끝난 셈입니다. 한 번의 스프린트를 투자해 위에서 설명한 섀도 모드 연동을 배포하고, 영업 자료가 아닌 데이터 일치 검증 보고서를 바탕으로 결정하세요. 섀도 모드 단계를 완료한 팀 대부분은 90일 안에 전환을 결정합니다.
