MIRAENEC/Insights/CRASH

Firebase Crashlytics를 설치해도 장애 원인을 못 찾는 이유

Crashlytics 대시보드가 비어 있다고 안정적인 앱이라는 뜻은 아닙니다. 실제 운영에서는 앱이 죽지 않았지만 사용자가 이탈하는 실패, WebView 프로세스만 종료되는 실패, Bridge 응답이 사라지는 실패가 더 자주 문제를 만듭니다.

1. 심볼 불일치 · 난독화 파일 누락

iOS dSYM과 Android mapping.txt가 빌드 산출물과 정확히 연결되지 않으면 stack trace는 의미를 잃습니다. 같은 Crash라도 실제 소스 라인, 릴리즈 버전, 빌드 넘버를 확인할 수 없기 때문에 담당자는 추측으로 수정 범위를 정하게 됩니다. CI/CD에서 빌드 직후 심볼 파일을 자동 업로드하고, 릴리즈 태그와 Crashlytics release 값을 맞추는 절차가 필요합니다.

2. 앱은 죽지 않았지만 사용자는 실패한 경우

무한 로딩, 결제 완료 후 화면 멈춤, 로그인 성공 후 빈 화면, 버튼을 눌러도 반응이 없는 상태는 Crash가 아닙니다. 사용자는 장애를 경험하지만 앱 프로세스가 종료되지 않기 때문에 Crashlytics fatal 이벤트에는 남지 않습니다. 이런 경우에는 screen_view, action_start, action_success, action_timeout처럼 성공과 실패를 짝으로 기록해야 합니다.

3. WebView 프로세스만 종료되는 경우

하이브리드 앱에서는 iOS WKWebView의 WebContent process가 종료되거나 Android WebView renderer가 죽어도 네이티브 앱 자체는 살아 있을 수 있습니다. 사용자는 흰 화면을 보지만 Crashlytics에는 앱 크래시가 남지 않습니다. iOS의 webViewWebContentProcessDidTerminate, Android의 onRenderProcessGone 이벤트를 별도 로그로 보내야 운영 대시보드에서 감지할 수 있습니다.

4. Native Bridge timeout은 별도 장애로 다뤄야 합니다

Native와 Web 사이의 호출은 REST API처럼 항상 응답이 보장되지 않습니다. handler 등록 시점, 앱 lifecycle, 화면 전환, 네트워크 상태, SDK callback 순서가 어긋나면 요청은 보냈지만 응답이 사라집니다. bridge_call, bridge_ack, bridge_timeout에 correlation id를 붙여야 어느 단계에서 끊겼는지 확인할 수 있습니다.

5. 사용자 정의 키가 없으면 우선순위를 못 정합니다

장애 원인보다 먼저 필요한 것은 운영 판단 기준입니다. app_build, os_version, device_model, screen_name, user_segment, network_type, payment_provider 같은 custom key가 없으면 특정 단말 문제인지, 최신 배포 문제인지, 결제 고객에게만 발생하는 문제인지 분류할 수 없습니다.

6. 빈도순이 아니라 비즈니스 영향도로 정렬해야 합니다

Crash 수가 많은 항목이 항상 먼저 고칠 항목은 아닙니다. 회원가입, 로그인, 결제, 쿠폰·포인트 사용, 주문 완료처럼 매출과 직접 연결되는 구간은 발생 건수가 적어도 우선순위가 높습니다. 운영 리포트는 Crash 수, 재현 가능성, 영향 사용자군, 비즈니스 영향도, 수정 난이도를 함께 봐야 합니다.

운영팀이 봐야 할 최종 리포트 형태

좋은 Crash 리포트는 “무슨 에러가 났다”에서 끝나지 않습니다. 어떤 사용자에게, 어떤 버전에서, 어떤 화면 이후 발생했고, 재현 가능성은 어느 정도이며, 수정은 핫픽스인지 구조 개선인지까지 정리되어야 합니다. 이 수준까지 내려가야 개발팀, 운영팀, CS팀이 같은 우선순위로 움직일 수 있습니다.