이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
서비스에 Firebase Crashlytics를 붙이면서 크래시 관리를 체계적으로 시작했습니다. 처음에는 crash-free rate 수치만 봤는데, 크래시 빈도보다 영향받은 사용자 수가 우선순위를 잡는 데 더 유용하다는 걸 선배에게 배웠습니다. 스택 트레이스에 난독화된 클래스 이름이 그대로 올라오는 경우가 있어, Proguard 매핑 파일을 Crashlytics에 업로드하는 설정을 추가했습니다. 특정 기기·OS 버전에서만 재현되는 크래시는 재현 환경 확보가 가장 어려웠고, 로그에 커스텀 키를 추가해 크래시 시점의 앱 상태를 같이 기록하는 방식으로 해결했습니다.
테스트 없이 핫픽스를 배포하고 싶은 충동이 생겼던 적 있는데, 그게 두 번째 크래시를 만든 경험 이후 최소한의 스모크 테스트 루틴은 지키게 됐습니다.
앱 크래시를 관리할 때 수집만 해두고 분류 기준이 없어서 어떤 크래시부터 잡아야 할지 모르는 상태가 됐습니다. Firebase Crashlytics에 수십 개의 크래시가 쌓였는데, 어느 것이 더 급한지를 판단하는 기준이 없었습니다.
이후엔 "영향 사용자 수"를 기준 1순위로, 재현율을 2순위로 두는 분류 방식을 정했습니다. 영향 사용자가 많은 크래시부터 대응하니 실제 서비스 안정성에 가장 빠르게 영향을 줄 수 있었습니다.
이 경험으로 크래시 관리는 수집 도구보다 분류 기준이 먼저라는 걸 배웠습니다. 기준이 없으면 크래시가 아무리 잘 수집돼도 대응 순서를 잡기 어렵습니다. 분류 기준 하나가 대응 시간을 절반으로 줄였습니다.
크래시를 수정하고 배포한 뒤 같은 위치에서 비슷한 크래시가 다시 올라오는 경험을 했습니다. 핫픽스를 빠르게 냈지만 근본 원인을 제대로 기록하지 않아서 재발 위험이 남아 있었습니다.
이후엔 크래시 수정 후에 "왜 이 크래시가 발생했는가, 어떤 조건이 겹쳤는가"를 한 문단으로 기록하는 방식을 만들었습니다. 크래시 리포트에 원인·수정 내용·재발 방지 조치를 함께 남겼습니다. 이 기록이 다음 크래시 대응 시 맥락을 찾는 데 도움이 됐습니다.
이 경험으로 크래시 관리에서 수정 못지않게 기록이 중요하다는 걸 배웠습니다. 재발 방지는 수정 이후에 남기는 한 문단에서 시작되고, 그 한 줄이 다음 대응을 빠르게 만들었습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 넛지헬스케어 모바일 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.