앱 MVP Android 품질 신호: Vitals·Crashlytics·수정 검증을 나누는 5가지 기준
앱 MVP Android 품질 신호: Vitals·Crashlytics·수정 검증을 나누는 5가지 기준
앱이 비정상 종료됐다는 알림을 받으면 팀은 종종 숫자가 더 큰 화면부터 열어 봅니다. 하지만 Android Vitals, Firebase Crashlytics, 개발자가 재현한 오류는 같은 사건을 같은 방식으로 세는 기록이 아닐 수 있습니다. 한쪽 수치가 다른 쪽보다 크거나 작다는 사실만으로 SDK 설정 실패, 배포 실패, 특정 기기 문제를 단정하기 어렵습니다.
먼저 답하면, Android MVP 팀은 관찰 출처, 대상 앱 버전·기기, 사건 묶음, 재현 가설, 수정 후 검증을 별도 기록으로 다루는 편이 좋습니다.
Android Developers는 App Quality Insights에서 Crashlytics와 Android Vitals 정보를 볼 수 있다고 설명합니다. 두 출처는 포착 시점·대상 사용자·산정 방식이 달라 같은 crash의 사용자·이벤트 수가 다를 수 있습니다. 이 글은 특정 앱의 품질, 스토어 심사, 장애 해결 또는 성과를 보장하지 않습니다.
Android의 정적 코드 경고를 별도로 관리하는 기준은 Android Lint baseline 점검에서 다룹니다. 여기서는 실제 사용자 환경에서 관찰된 안정성 신호를 의사결정 기록으로 바꾸는 범위에 집중합니다.
1. ‘오류 수치’보다 먼저 관찰 출처를 적습니다
Android Vitals는 Google Play에서 배포된 앱과 인증된 기기, 데이터 공유에 동의한 사용자 등 자체 범위에서 품질 정보를 다룹니다. 반면 Crashlytics는 앱에 추가한 SDK가 초기화된 뒤 앱의 개인정보 처리 정책에 따라 기록하는 보고 흐름입니다. Android Developers는 Play가 부팅 시점부터 crash를 포착할 수 있는 반면 Crashlytics는 SDK 초기화 뒤의 crash를 포착한다고 설명합니다.
따라서 하나의 crash를 검토할 때 ‘어느 도구에 잡혔는가’를 정답 판정으로 쓰지 마세요. 아래처럼 출처 자체를 첫 칸으로 남기면, 숫자의 차이를 결함의 원인으로 오해하는 일을 줄일 수 있습니다.
기록 칸 | 확인할 질문 | 기록 예시 |
|---|---|---|
관찰 출처 | Play Vitals, Crashlytics, 내부 재현 중 어디서 보였는가? | 출처 이름과 확인 시각 |
대상 범위 | 어떤 app ID·배포 버전·기기 조건인가? | production variant, OS·제조사 조건 |
사건 묶음 | 같은 stack trace 계열인가, 다른 현상인가? | 이슈 식별과 관찰한 variant |
사용자 영향 | 수치의 분모·산정 방식을 확인했는가? | 도구별 정의를 원문에 연결 |
다음 판단 | 재현·수정·관찰 중 무엇을 할 차례인가? | 책임자와 확인 조건 |
이 표는 Android 또는 Firebase의 필수 양식이 아니라, 서로 다른 신호를 하나의 ‘장애 건수’로 합치지 않기 위한 작업용 틀입니다. 실사용자 데이터와 내부 식별값은 티켓이나 공유 문서에 불필요하게 복사하지 마세요.
2. 앱 버전과 코드 상태를 같은 시점으로 맞춥니다
App Quality Insights는 이슈 패널의 event를 보고, 선택한 event의 stack trace에서 관련 코드로 이동할 수 있도록 안내합니다. 또한 현재 코드가 crash가 발생한 코드와 달라졌다면, stack trace 옆 diff를 통해 당시 코드와 현재 코드의 차이를 볼 수 있다고 설명합니다. 이 기능은 현재 브랜치가 이미 고쳐진 상태인지, 실제로는 다른 릴리스에서 발생한 문제인지 가늠하는 데 쓰일 수 있습니다.
여기서 중요한 것은 ‘코드 줄을 열었다’와 ‘원인을 확인했다’를 구분하는 일입니다. MVP 팀은 최소한 다음 다섯 가지를 묶어 남기세요.
관찰한 앱 ID와 배포 버전, variant를 적습니다.
stack trace가 가리키는 파일·함수와 당시 코드 버전을 구분합니다.
같은 기기 제조사·Android 버전·화면 진입 순서에서 반복되는지 관찰합니다.
재현하지 못했으면 재현 실패를 삭제하지 말고 조건 부족으로 남깁니다.
수정 후보는 원인 가설, 변경 범위, 새 빌드 식별자와 함께 리뷰합니다.
R8 적용 릴리스에서 난 stack trace라면 매핑 파일의 보관·해석과 제품 동작 검증을 같은 단계로 보지 않는 것이 좋습니다. 이 경계는 Android R8 매핑 파일 점검에서 이어서 확인할 수 있습니다.
3. Crashlytics와 Vitals의 차이는 ‘충돌’이 아니라 조건 차이일 수 있습니다
Android Developers는 Android Vitals와 Crashlytics가 같은 crash에 대해서도 서로 다른 사용자·이벤트 수를 보일 수 있다고 명시합니다. 예로 Play는 새 휴대폰에서 사용자가 crash reporting을 거부한 경우 그 crash를 보고하지 않을 수 있습니다. Crashlytics는 앱 자체의 개인정보 처리 정책을 기준으로 포착할 수 있습니다.
Vitals의 issue rate는 일일 활성 사용자 기준으로 계산될 수 있는 반면, Crashlytics는 session 기준으로 볼 수 있다는 설명도 제공합니다. 같은 이름의 지표라도 분모가 다르면 같은 비율로 읽을 수 없습니다.
그래서 ‘Vitals는 0인데 Crashlytics가 있다’ 또는 ‘Crashlytics보다 Vitals가 많다’만으로 보고 누락이나 실제 영향도를 확정하지 마세요. 먼저 각 화면의 기간·필터·버전·분모와 수집 조건을 확인한 뒤, 같은 사건을 비교 가능한 조건으로 좁히는 편이 낫습니다. 숫자를 경영 보고에 옮길 때도 도구명과 기간, 원래 정의를 함께 적고 서로 다른 비율을 합산하지 않습니다.
4. 수정 제안은 배포 결정이 아니라 검토 대상입니다
App Quality Insights에는 crash의 요약이나 다음 단계 제안을 돕는 기능이 있을 수 있습니다. Android Developers는 Gemini 기반 Insight가 요약, 원인 이해 보조, 가능한 다음 단계와 코드 제안을 제공할 수 있다고 설명합니다. 그러나 제안된 diff나 설명은 해당 앱의 실제 재현·권한·서버 계약·테스트 결과를 대신하지 않습니다.
따라서 자동·반자동 제안이 나왔을 때는 아래 순서로 범위를 닫아 보세요.
제안이 참조한 이슈와 app version을 기록합니다.
변경 전후에 어떤 가설을 시험하는지 한 문장으로 씁니다.
코드 리뷰와 단위·통합·실기기 검수의 책임을 분리합니다.
새 빌드를 배포했다면 배포 완료와 사용자 환경에서의 안정성 관찰을 같은 완료 표시로 합치지 않습니다.
더 이상 재현되지 않는다는 관찰도 기간·조건이 있는 관찰값으로 남깁니다.
이 과정을 거치면 도구의 요약을 무시하지 않으면서도, 도구의 문구를 근거 없는 원인 확정이나 즉시 배포 권한으로 바꾸지 않게 됩니다.
5. ‘수정 완료’ 대신 검증 질문을 남깁니다
작은 MVP에서는 모든 기기와 상태를 한 번에 시험하기 어렵습니다. 그래서 품질 이슈를 닫을 때는 해결 문구만 남기기보다, 이번에 확인한 범위와 아직 모르는 범위를 분리하는 편이 유용합니다. 예를 들어 테스트 기기·OS·앱 버전·계정 상태·네트워크 조건·화면 진입 순서·실제 관찰·남은 예외를 각각 기록할 수 있습니다.
Android Vitals는 사용자 경험 개선을 위해 문제를 다루는 출처이지만, 특정 이슈가 어떤 제품 변경으로 반드시 사라진다는 보장은 아닙니다. Crashlytics와 Vitals의 관찰값, 재현 결과, 수정 빌드의 검수 결과를 분리해 보관하면 다음 출시에서 같은 판단을 다시 확인하기 쉬워집니다.
유인어스는 민간 사업 지원 서비스입니다. 실제 앱 출시 전에는 현재 공식 문서, 사용 중인 Android Studio·Firebase·Play 환경, 앱의 개인정보 처리와 실제 기기 결과를 함께 검토하세요.
자주 묻는 질문
Android Vitals와 Crashlytics의 crash 수가 다르면 무엇이 잘못된 건가요?
수치 차이만으로 설정 오류를 단정할 수 없습니다. Android Developers는 두 출처가 crash를 포착하는 시점·대상 사용자·산정 방식이 다를 수 있다고 설명합니다. 먼저 기간, app version, 필터, 분모와 수집 조건을 각각 확인하세요.
App Quality Insights에서 코드로 이동하면 원인이 확정되나요?
아닙니다. App Quality Insights는 stack trace와 관련 코드 탐색을 돕지만, 현재 코드와 crash 당시 코드가 다를 수 있습니다. 재현 조건, 코드 버전, 변경 가설, 테스트 결과를 별도로 확인해야 합니다.
AI가 제안한 수정 diff를 바로 배포해도 되나요?
바로 배포 결정으로 보기는 어렵습니다. 공식 문서가 설명하는 Insight와 코드 제안은 원인 이해와 다음 단계의 보조 수단입니다. 실제 앱의 계약·권한·테스트와 리뷰를 거쳐 변경 범위를 판단하세요.
수정 빌드를 올린 뒤 관찰할 것은 무엇인가요?
배포 버전, 수정한 가설, 테스트한 기기·OS·진입 흐름, Vitals와 Crashlytics에서 본 기간·필터·관찰 결과를 나누어 기록하세요. 짧은 기간의 관찰을 장기 안정성이나 모든 사용자 환경의 결과로 일반화하지 않는 것이 좋습니다.
확인한 공식 출처
Android Developers · Analyze issues from Firebase Crashlytics and Android Vitals with App Quality Insights — Crashlytics·Vitals의 IDE 표시, 이벤트·variant·stack trace 탐색, 출처별 차이와 Offline Mode를 2026-09-22 KST에 확인했습니다.
Android Developers · Android vitals — Vitals의 수집 범위, 다른 도구와 수치가 다를 수 있는 이유, issue rate의 기준을 2026-09-22 KST에 확인했습니다.
Android Developers · Analyze crashes with App Quality Insights and Gemini — Insight·crash summary·code suggestion이 보조 기능이라는 범위를 2026-09-22 KST에 확인했습니다.