크래시로 세션이 끝나면 사용자 신뢰만 잃는 것이 아닙니다. 남은 세션에서 발생했을 모든 광고 노출, 세션 종료 시 전송됐을 모든 포스트백, 그리고 다음 날 리텐션의 상당 부분까지 잃게 됩니다. 수치로 계산해 보면 무시하기 어려운 손실입니다.
연쇄적으로 발생하는 손실
안정적으로 운영되는 모바일 앱의 평균 세션 길이는 6~9분입니다. 광고 노출 빈도 제한을 적용한 뒤 세션당 평균 광고 노출 수는 2.4회입니다. 세션 시작 2분 만에 크래시가 발생하면 평균 약 1.6회의 광고 노출을 잃습니다. 되돌릴 수 없는 손실입니다.
크래시율 1%, DAU 500만인 앱에 이를 적용하면 하루에 사라지는 광고 노출이 8만 회에 달합니다. eCPM이 7달러라면 매일 560달러의 수익 손실이 발생합니다. 안정성 단 1%포인트에 달린 금액입니다.
전체 수익 손실 계산 모델
공식은 간단합니다. 일일 수익 손실 = DAU × 크래시율 × (세션당 광고 노출 수 – 크래시 발생 전 광고 노출 수) × eCPM / 1000입니다. 현실적인 수치를 대입하면 그 심각성이 와닿습니다.
- DAU 100만 × 크래시율 1.5% × 손실 광고 노출 1.6회 × eCPM 6달러 ≈ 하루 144달러, 연간 5만 2천 달러
- DAU 500만 × 크래시율 1.0% × 손실 광고 노출 1.6회 × eCPM 7달러 ≈ 하루 560달러, 연간 20만 4천 달러
- DAU 2,500만 × 크래시율 0.6% × 손실 광고 노출 1.6회 × eCPM 8달러 ≈ 하루 1,920달러, 연간 70만 달러
- 이 수치에는 손실된 광고 노출만 반영되어 있습니다. 대개 이보다 더 큰 리텐션 하락의 영향은 포함되지 않았습니다.
ANR은 크래시보다 수익화에 더 치명적입니다
Android의 ANR(애플리케이션 응답 없음)은 눈에 잘 띄지 않는 치명적인 문제입니다. 사용자는 멈춘 UI를 보고 앱을 강제 종료한 뒤 삭제합니다. 하지만 크래시 보고서는 생성되지 않으므로 Crashlytics만 모니터링하는 팀은 이 문제를 놓칩니다. 메인 스레드에서 광고 SDK를 초기화하는 앱에서는 ANR 발생률이 0.5%를 넘는 경우가 흔합니다.
iOS에서 이에 해당하는 것은 워치독에 의한 강제 종료입니다. 종료 코드는 0x8badf00d이며, 대개 근본 원인도 같습니다. 앱 실행 시 메인 스레드에서 동기 작업을 수행하기 때문입니다. 두 문제 모두 크래시와 동일하게 다뤄야 합니다. 알림을 설정하고, 같은 방식으로 수익 손실을 계산하며, 매 릴리스의 배포 승인 기준에 포함하세요.
플랫폼별 안정성 확보 패턴
다음은 저희가 모든 Apps Kit SDK 연동에 기본으로 적용하는 패턴입니다. 특별한 기법은 하나도 없습니다. 하지만 저희가 점검하는 일반적인 코드베이스에는 이런 패턴이 모두 빠져 있습니다.
- Android: Application.onCreate가 아닌 WorkManager 작업에서 SDK를 초기화하세요.
- Android: 광고 뷰는 WeakReference로 참조하고 onDestroyView에서 null로 설정하세요.
- iOS: didFinishLaunching에서 SDK 초기화를 utility QoS 큐로 디스패치하고, 메인 스레드를 블로킹하지 마세요.
- iOS: deinit이 아닌 viewWillDisappear에서 광고 델리게이트를 해제하고 순환 참조를 끊으세요.
- 공통: 동의 여부, 네트워크 상태, SDK 준비 상태를 파악하는 상태 머신을 통해 모든 광고 요청의 실행 여부를 제어하세요.
크래시는 어디서 발생할까요?
- 메인 스레드에서의 SDK 초기화 — 저희가 가장 자주 발견하는 원인입니다.
- onCreate / didFinishLaunching에서의 동기식 광고 로딩
- 더 이상 필요하지 않은 광고 뷰를 계속 참조해 발생하는 메모리 부담
- 동의 상태와 광고 요청 사이의 경쟁 상태
수익에 영향을 주는 크래시에 알림 설정하기
크래시율 알림은 대개 고정된 비율 임계값을 기준으로 설정되며, 알림이 울려도 무시되곤 합니다. 대신 수익 영향을 기준으로 설정하세요. 특정 크래시 시그니처로 인한 예상 일일 수익 손실이 X달러를 넘을 때 알림을 보내면, 온콜 엔지니어도 잠에서 깨어 대응할 만한 알림이 됩니다. 저희는 BigQuery로 내보낸 데이터를 기반으로 바로 이 기능을 수행하는 Cloud Function 템플릿을 제공합니다.
안정성을 지키는 기본 패턴
백그라운드 디스패처에서 SDK를 초기화하고, 동의 상태 머신으로 모든 광고 요청을 제어하며, 광고 지면이 닫히는 즉시 광고 뷰 참조를 해제하세요. 새로운 기법은 하나도 없습니다. 하지만 저희가 점검하는 일반적인 연동 구현에는 이런 처리가 모두 빠져 있습니다.
크래시율을 단순한 코드 품질 지표가 아닌 수익 개선 수단으로 바라보세요. 안정성 개선 작업의 우선순위를 둘러싼 논의가 훨씬 짧아집니다.
이번 주에 할 일
크래시 대시보드를 열어 상위 3개 크래시 시그니처에 위 모델을 적용하고, 각각의 손실액을 달러로 표시하세요. 가장 큰 손실을 일으키는 문제를 해결한 릴리스는 다음 App Store 심사 기간이 끝나기도 전에 투입 비용을 회수할 것입니다.
