Crashlytics 문제 해결 및 FAQ


이 페이지에서는 Crashlytics 사용과 관련된 자주 묻는 질문(FAQ)에 대한 답변과 문제 해결 도움말을 제공합니다. 원하는 내용을 찾을 수 없거나 추가 지원이 필요하면 Firebase 지원팀에 문의하세요.

일반적인 문제 해결 및 FAQ

Firebase Console의 문제 표에 두 가지 다른 문제 형식이 표시될 수 있습니다. 또한 일부 문제에는 '변형'이라는 특징이 있을 수 있습니다. 이유는 다음과 같습니다.

2023년 초, Google에서는 이벤트 그룹화를 위한 향상된 분석 엔진, 업데이트된 디자인, 새로운 문제(예: 변형)에 대한 일부 고급 기능을 출시했습니다. 자세한 내용은 최근 블로그 게시물을 참조하세요. 아래에서 주요 내용을 확인할 수 있습니다.

Crashlytics는 앱의 모든 이벤트(예: 비정상 종료, 심각하지 않은 문제, ANR)를 분석하고 문제라는 이벤트 그룹을 만듭니다. 한 문제의 모든 이벤트에는 공통적인 장애점이 있습니다.

이벤트를 이러한 문제로 그룹화하기 위해 이제 향상된 분석 엔진이 스택 트레이스의 프레임, 예외 메시지, 오류 코드, 기타 플랫폼 또는 오류 유형 특성 등 이벤트의 여러 측면을 살펴봅니다.

그러나 이 이벤트 그룹 내에서 장애로 이어지는 스택 트레이스가 다를 수 있습니다. 스택 트레이스가 다르면 근본 원인이 달라질 수 있습니다. 문제 내에서 발생할 수 있는 이러한 차이를 나타내기 위해 이제 문제 내에 변형을 만듭니다. 각 변형은 문제에서 동일한 장애점 및 유사한 스택 트레이스가 있는 이벤트의 하위 그룹입니다. 변형을 사용하면 문제 내에서 가장 일반적인 스택 트레이스를 디버깅하고 서로 다른 근본 원인으로 인해 장애가 발생했는지 파악할 수 있습니다.

개선된 기능은 다음과 같습니다.

  • 문제 행에 개선된 메타데이터 표시
    이제 앱의 문제를 더 쉽게 파악하고 분류할 수 있습니다.

  • 중복 문제 감소
    줄 번호를 변경해도 새 문제가 발생하지 않습니다.

  • 다양한 근본 원인이 있는 복잡한 문제를 더 손쉽게 디버깅
    변형을 사용하여 문제 내에서 가장 일반적인 스택 트레이스를 디버깅합니다.

  • 더 의미 있는 알림과 신호
    새로운 문제가 실제로는 새로운 버그를 나타냅니다.

  • 더욱 강력한 검색
    각 문제에 예외 유형 및 패키지 이름과 같이 검색 가능성이 더 높은 메타데이터가 포함됩니다.

개선된 기능이 적용되는 방식은 다음과 같습니다.

  • 앱에서 새로운 이벤트가 수신되면 기존 문제와 일치하는지 확인합니다.

  • 일치하는 항목이 없으면 이벤트에 더 스마트한 이벤트 그룹화 알고리즘을 자동으로 적용하고 개선된 메타데이터 설계로 새로운 문제를 만듭니다.

Google에서 진행 중인 이벤트 그룹화에 대한 첫 번째 대규모 업데이트입니다. 의견이 있거나 문제가 발생하면 신고를 제출하여 알려주시기 바랍니다.

비정상 종료가 발생하지 않은 측정항목(예: 비정상 종료가 발생하지 않은 사용자 및 세션)이나 신속 알림이 표시되지 않으면 다음을 사용 중인지 확인하세요. Crashlytics SDK 11.7.0 이상

탐색경로 로그가 표시되지 않는 경우 Google Analytics의 앱 구성을 확인하는 것이 좋습니다. 다음 요건을 충족해야 합니다.

Unity IL2CPP를 사용 중인데 기호화되지 않은 스택 트레이스가 표시되면 다음을 시도해 보세요.

  1. Crashlytics Unity SDK v8.6.1 이상을 사용 중인지 확인합니다.

  2. 기호 파일을 생성하여 업로드하려면 Firebase CLI crashlytics:symbols:upload 명령어를 설정하고 실행해야 합니다.

    Firebase Console에서 출시 빌드 또는 기호화된 스택 트레이스를 보려는 빌드를 만들 때마다 이 CLI 명령어를 실행해야 합니다. 읽을 수 있는 비정상 종료 보고서 받기 페이지에서 자세히 알아보세요.

예, Crashlytics는 IL2CPP를 사용하는 앱에 대한 기호화된 스택 트레이스를 표시할 수 있습니다. 이 기능은 Android 또는 Apple 플랫폼에서 출시된 앱에서 사용할 수 있습니다. 필요한 작업은 다음과 같습니다.

  1. Crashlytics Unity SDK v8.6.0 이상을 사용 중인지 확인합니다.

  2. 플랫폼에 필요한 작업을 완료합니다.

    • Apple 플랫폼 앱: 특별한 작업이 필요하지 않습니다. Apple 플랫폼 앱의 경우 Firebase Unity 편집기 플러그인이 기호를 업로드하도록 Xcode 프로젝트를 자동으로 구성해 줍니다.

    • Android 앱: 기호 파일을 생성하여 업로드하려면 Firebase CLI crashlytics:symbols:upload 명령어를 설정하고 실행해야 합니다.

      Firebase Console에서 출시 빌드 또는 기호화된 스택 트레이스를 보려는 빌드를 만들 때마다 이 CLI 명령어를 실행해야 합니다. 읽을 수 있는 비정상 종료 보고서 받기 페이지에서 자세히 알아보세요.

비정상 종료가 발생하지 않은 값은 앱을 사용했지만 특정 기간 동안 비정상 종료가 발생하지 않은 사용자의 비율을 나타냅니다.

비정상 종료가 발생하지 않은 사용자 비율을 계산하는 수식은 다음과 같습니다. 입력 값은 Google Analytics에서 제공합니다.

CRASH_FREE_USERS_PERCENTAGE = 1 - (CRASHED_USERS / ALL_USERS) x 100

  • 비정상 종료가 발생하면 Google Analytics는 app_exception 이벤트 유형을 전송하고 CRASHED_USERS는 해당 이벤트 유형과 연결된 사용자 수를 나타냅니다.

  • ALL_USERS는 Crashlytics 대시보드의 오른쪽 상단에 있는 드롭다운 메뉴에서 선택한 기간 동안 앱에 참여한 총 사용자 수를 나타냅니다.

비정상 종료가 발생하지 않은 사용자 비율은 평균이 아닌 시간 경과에 따라 집계된 값입니다.

예를 들어 앱에 사용자 A, 사용자 B, 사용자 C라는 3명의 사용자가 있다고 가정해 보겠습니다. 다음 표는 매일 앱에 참여하는 사용자와 이날 비정상 종료가 발생한 사용자를 보여줍니다.

월요일 화요일 수요일
앱에 참여한 사용자 A, B, C A, B, C A, B
비정상 종료가 발생한 사용자 C B A

  • 수요일에 비정상 종료가 발생하지 않은 사용자 비율은 50%입니다(사용자 2명 중 1명에게 비정상 종료가 발생하지 않음).
    수요일에 사용자 2명이 앱에 참여했지만 2명 중 1명(사용자 B)에게만 비정상 종료가 발생하지 않았습니다.

  • 지난 2일 동안 비정상 종료가 발생하지 않은 사용자 비율은 33.3%입니다(사용자 3명 중 1명에게 비정상 종료가 발생하지 않음).
    지난 2일 동안 사용자 3명이 앱에 참여했지만 3명 중 1명(사용자 C)에게만 비정상 종료가 발생하지 않았습니다.

  • 지난 3일 동안 비정상 종료가 발생하지 않은 사용자 비율은 0%입니다(사용자 3명 중 0명에게 비정상 종료가 발생하지 않음).
    지난 3일 동안 사용자 3명이 앱에 참여했지만 3명 중 0명에게 비정상 종료가 발생하지 않았습니다.

비정상 종료가 발생하지 않은 사용자 값을 서로 다른 기간에 걸쳐 비교해서는 안 됩니다. 한 명의 사용자가 앱을 더 많이 사용할수록 비정상 종료가 발생할 가능성은 증가하므로 비정상 종료가 발생하지 않은 사용자 값은 기간이 길어지면 더 낮아질 수 있습니다.

프로젝트 구성원은 메모를 통해 질문, 상태 업데이트 등의 특정 문제에 대한 의견을 남길 수 있습니다.

프로젝트 구성원이 메모를 게시하면 Google 계정의 이메일로 라벨이 지정됩니다. 이 이메일 주소는 메모를 확인할 권한이 있는 모든 프로젝트 구성원에게 메모와 함께 표시됩니다.

다음은 메모를 보고 작성하고 삭제하는 데 필요한 액세스 권한입니다.

비정상 종료가 발생하지 않은 측정항목 이해하기를 참조하세요.

프로젝트 구성원은 메모를 통해 질문, 상태 업데이트 등의 특정 문제에 대한 의견을 남길 수 있습니다.

프로젝트 구성원이 메모를 게시하면 Google 계정의 이메일로 라벨이 지정됩니다. 이 이메일 주소는 메모를 확인할 권한이 있는 모든 프로젝트 구성원에게 메모와 함께 표시됩니다.

다음은 메모를 보고 작성하고 삭제하는 데 필요한 액세스 권한입니다.

통합

프로젝트에서 Google Mobile Ads SDK와 함께 Crashlytics를 사용하는 경우 예외 핸들러를 등록할 때 비정상 종료 보고 도구가 간섭할 가능성이 있습니다. 이 문제를 해결하려면 disableSDKCrashReporting을 호출하여 Mobile Ads SDK에서 비정상 종료 보고를 사용 중지하세요.

Crashlytics를 BigQuery에 연결하면 Firebase 프로젝트의 위치에 관계없이, 생성한 새 데이터 세트가 자동으로 미국에 위치합니다.

회귀된 문제

이전에 문제를 종료했지만 Crashlytics에서 해당 문제가 다시 발생했다는 새로운 보고를 받으면 문제가 회귀된 것입니다. 앱에 맞게 문제를 해결할 수 있도록 Crashlytics에서 이러한 회귀된 문제를 자동으로 다시 엽니다.

다음은 Crashlytics에서 문제를 회귀로 분류하는 방식을 설명하는 예시 시나리오입니다.

  1. Crashlytics에서 처음으로 비정상 종료 'A'에 관한 비정상 종료 보고서를 받습니다. Crashlytics에서 이 비정상 종료에 해당하는 문제(문제 'A')를 엽니다.
  2. 개발자가 이 버그를 신속하게 수정하고 문제 'A'를 종료한 후 앱의 새 버전을 출시합니다.
  3. 개발자가 문제를 종료한 후 Crashlytics에서 문제 'A'에 관한 다른 보고서를 받습니다.
    • 문제가 종료되었을 때 Crashlytics에서 알고 있는 앱 버전에서 보고서를 보낸 경우(즉, 해당 버전에서 모든 비정상 종료에 대해 비정상 종료 보고서를 보낸 경우) Crashlytics에서는 문제가 회귀된 것으로 간주하지 않습니다. 문제가 종료된 상태로 유지됩니다.
    • 문제가 종료되었을 때 Crashlytics에서 모르는 앱 버전에서 보고서를 보낸 경우(즉, 해당 버전에서 비정상 종료에 대해 어떠한 비정상 종료 보고서도 보내지 않은 경우) Crashlytics에서 문제가 회귀된 것으로 간주하고 문제를 다시 엽니다.

문제가 회귀되면 Crashlytics에서 문제를 다시 열었음을 알 수 있도록 회귀 감지 알림이 전송되고 문제에 회귀 신호가 추가됩니다. 회귀 알고리즘으로 인해 문제가 다시 열리지 않도록 하려면 문제를 종료하는 대신 '숨기세요'.

문제가 종료되었을 때 비정상 종료 보고서를 보낸 적이 없는 이전 앱 버전에서 보고서를 보내면 Crashlytics에서 문제가 회귀된 것으로 간주하고 문제를 다시 엽니다.

이러한 상황은 다음과 같은 경우에 발생할 수 있습니다. 개발자가 버그를 수정하고 앱의 새 버전을 출시했지만 버그가 수정되지 않은 이전 버전에 아직 사용자가 있습니다. 만약 문제가 종료되었을 때 이전 버전 중 하나에서 비정상 종료 보고서를 보낸 적이 없는 경우 해당 사용자에게 버그가 발생하기 시작하면 비정상 종료 보고서가 회귀된 문제를 트리거합니다.

회귀 알고리즘으로 인해 문제가 다시 열리지 않도록 하려면 문제를 종료하는 대신 '숨기세요'.

포착되지 않은 예외를 심각한 예외로 보고

Crashlytics는 포착되지 않은 예외를 심각한 예외로 보고할 수 있습니다(Unity SDK v10.4.0부터). 다음 FAQ는 이 기능을 사용하는 근거와 권장사항을 설명하는 데 도움이 됩니다.

포착되지 않은 예외를 심각한 예외로 보고하면 앱이 계속 실행되어도 어떤 예외로 인해 게임을 플레이할 수 없게 되는지 보다 현실적으로 파악할 수 있습니다.

심각한 오류 보고를 시작하면 비정상 종료가 발생하지 않은 사용자(CFU) 비율이 감소할 수 있지만, CFU 측정항목이 최종 사용자의 앱 경험을 더 잘 나타냅니다.

Crashlytics가 포착되지 않은 예외를 심각한 오류로 보고하려면 다음 두 조건을 모두 충족해야 합니다.

포착되지 않은 예외가 심각한 예외로 보고되기 시작하면 다음과 같은 방법으로 이러한 포착되지 않은 예외를 처리할 수 있습니다.

발생한 예외 포착 및 처리

예상치 못한 상태나 예외 상태를 반영하기 위해 예외가 생성되고 발생합니다. 발생한 예외가 반영된 문제를 해결하려면 프로그램을 알려진 상태(예외 처리라고 하는 프로세스)로 되돌려야 합니다.

프로그램을 알려진 상태로 되돌릴 수 없는 경우가 아니라면 예상되는 모든 예외를 포착하여 처리하는 것이 좋습니다.

어떤 종류의 예외를 포착하고 어떤 코드로 처리할지를 제어하려면 try-catch 블록에서 예외를 생성할 수 있는 코드를 래핑합니다. 특정 예외를 적절하게 처리하려면 catch문의 조건 범위가 최대한 좁아야 합니다.

Unity 또는 Crashlytics에서 예외 로깅

문제를 디버그하는 데 도움이 되도록 Unity 또는 Crashlytics에서 예외를 기록하는 방법은 여러 가지가 있습니다.

Crashlytics 사용 시 권장되는 가장 일반적인 두 가지 옵션은 다음과 같습니다.

  • 옵션 1: Unity 콘솔에서 출력하되 개발 또는 문제 해결 중에 Crashlytics에 보고하지 않습니다.

    • Unity 콘솔에 예외 콘텐츠를 출력하고 예외를 다시 발생시키지 않는 Debug.Log(exception), Debug.LogWarning(exception), Debug.LogError(exception)를 사용하여 Unity 콘솔에 출력합니다.

  • 옵션 2: 다음 상황에 대해 Crashlytics 대시보드에서 통합 보고를 하려면 Crashlytics에 업로드합니다.

    • 발생 가능한 후속 Crashlytics 이벤트를 디버깅하기 위해 예외를 로깅할 필요가 있는 경우에는 Crashlytics.Log(exception.ToString())를 사용합니다.
    • 포착 및 처리되더라도 예외를 Crashlytics에 계속 보고해야 하는 경우 Crashlytics.LogException(exception)을 사용하여 심각하지 않은 이벤트로 로깅합니다.

그러나 심각한 이벤트를 Unity 클라우드 진단에 수동으로 보고하려면 Debug.LogException을 사용하면 됩니다. 이 옵션은 옵션 1과 같이 Unity 콘솔에 예외를 출력하지만 발생 및 포착 여부와 관계없이 예외가 발생합니다. 비로컬에서 오류가 발생합니다. 즉, try-catch 블록이 있는 주변 Debug.LogException(exception)도 여전히 포착되지 않은 예외를 발생시킵니다.

따라서 다음 모든 작업을 실행하려는 경우에만 Debug.LogException을 호출합니다.

  • Unity 콘솔에 예외를 출력하려면 다음 안내를 따르세요.
  • Crashlytics에 예외를 심각한 이벤트로 업로드합니다.
  • 예외를 발생시키려면 포착되지 않은 예외로 처리하고 Unity 클라우드 진단에 보고해야 합니다.

포착된 예외를 Unity 콘솔에 출력하고 또한 심각하지 않은 이벤트로 Crashlytics에 업로드하려면 다음 단계를 따르세요.

try
{
    methodThatThrowsMyCustomExceptionType();
}
catch(MyCustomExceptionType exception)
{
    // Print the exception to the Unity console at the error level.
    Debug.LogError(exception);
    // Upload the exception to Crashlytics as a non-fatal event.
    Crashlytics.LogException(exception); // not Debug.LogException
    //
    // Code that handles the exception
    //
}