크래시 관리 — Crashlytics로 체계화
약 90초
영향 사용자 수 기준 → 난독화 매핑 → 커스텀 키 로깅
서비스에 Firebase Crashlytics를 붙이면서 크래시 관리를 체계적으로 시작했습니다. 처음에는 crash-free rate 수치만 봤는데, 크래시 빈도보다 영향받은 사용자 수가 우선순위를 잡는 데 더 유용하다는 걸 선배에게 배웠습니다. 스택 트레이스에 난독화된 클래스 이름이 그대로 올라오는 경우가 있어, Proguard 매핑 파일을 Crashlytics에 업로드하는 설정을 추가했습니다. 특정 기기·OS 버전에서만 재현되는 크래시는 재현 환경 확보가 가장 어려웠고, 로그에 커스텀 키를 추가해 크래시 시점의 앱 상태를 같이 기록하는 방식으로 해결했습니다.
테스트 없이 핫픽스를 배포하고 싶은 충동이 생겼던 적 있는데, 그게 두 번째 크래시를 만든 경험 이후 최소한의 스모크 테스트 루틴은 지키게 됐습니다.
이 결의 특징
크래시 관리를 영향받은 사용자 수라는 우선순위 기준으로 풀어낸 흔적이 있습니다.
이 결이 통하는 자리
Proguard 매핑 업로드와 커스텀 키 로깅이라는 구체 조치가 답에 담겨 있을 때 면접관의 신뢰가 쌓이는 자리를 자주 봅니다.