모바일 개발에서의 크래시 리포트 — 개념, 서비스 및 설정

크래시 리포트란?

크래시 리포트는 앱 크래시에 대한 기술 정보를 자동으로 수집하고 분석을 위해 서버에 중앙 전송하는 프로세스입니다. 로깅과 달리, 크래시 리포트는 긴급 상황, 즉 앱이 시스템 또는 OS에 의해 강제 종료된 순간을 특히 캡처합니다.

각 크래시 리포트에는 세 가지 주요 구성 요소가 포함됩니다: 예외 유형(NullPointerException, SIGSEGV, NSInternalInconsistencyException), 라인 번호가 포함된 전체 호출 스택, 환경 정보(OS 버전, 장치 모델, 사용 가능한 메모리 크기). Sentry Engineering, 2024에 따르면, 이 세 가지 요소의 조합을 통해 중요 오류의 85%를 재현하고 수정할 수 있습니다.

현대적인 크래시 리포트 시스템은 일반적인 크래시를 넘어 기능을 확장합니다. Firebase Crashlytics는 반복되는 크래시를 자동으로 이슈로 그룹화하고, Sentry는 릴리스 간의 회귀를 추적하며, Bugsnag는 오류까지의 사용자 경로를 보여줍니다. 세 서비스 모두 iOS, Android, React Native 및 Flutter를 지원합니다.

Google I/O 2024에 따르면, 크래시 리포트가 없는 앱은 단일 중요 오류 진단에 평균 3~5영업일이 소요되는 반면, Crashlytics를 사용하면 15~30분이 소요됩니다. 각 인시던트당 시간 절약은 90%를 초과합니다.

크래시 리포트 수집 시스템 작동 방식

아키텍처 크래시 리포트 시스템은 세 계층으로 구성됩니다: 앱에 설치된 클라이언트 SDK, 리포트를 수신하고 처리하는 서버 API, 분석을 위한 웹 대시보드. 클라이언트 SDK는 처리되지 않은 예외를 가로채서 JSON으로 직렬화하고 다음 앱 실행 시 서버로 전송합니다.

크래시 리포트 제출은 앱 재시작 후 비동기적으로 이루어집니다. 이것은 근본적인 포인트입니다: 크래시 순간에 앱은 네트워크를 통한 성공적인 데이터 전송을 보장할 수 없습니다. SDK는 리포트를 로컬 스토리지에 기록하고 다음 실행 시 백그라운드 스레드를 통해 전송합니다. Firebase Engineering, 2024에 따르면, 이 접근 방식은 99.7%의 크래시 리포트 전달을 보장합니다.

비치명적 예외(try-catch 내에서 처리된 예외)의 경우, 앱이 계속 작동하므로 SDK는 리포트를 즉시 전송합니다. 비치명적 리포트에는 크래시와 동일한 데이터가 포함되지만 사용자 세션을 중단하지 않습니다. 이는 API 요청 오류, 데이터 검증 및 비즈니스 로직을 추적하는 데 특히 유용합니다.

크래시 그룹화 — 마지막 5~10개 스택 프레임의 해시를 기반으로 동일한 크래시를 병합하는 서버 알고리즘입니다. 이를 통해 개발자는 1000개의 개별 리포트가 아니라 다양한 장치 및 OS 버전에 걸쳐 1000개의 발생을 가진 하나의 이슈를 볼 수 있습니다.

Firebase Crashlytics: 통합 및 기능

Firebase Crashlytics는 모바일 앱을 위한 가장 인기 있는 크래시 리포트 서비스로, 전 세계 300만 개 이상의 프로젝트에서 사용됩니다. 무료 요금제에는 무제한 리포트, Google Analytics 통합 및 자동 크래시 그룹화가 포함됩니다.

Android에서 Crashlytics 통합

설정 Android에서 Crashlytics는 최소한으로: build.gradle에 종속성을 추가하고 Application.onCreate에서 SDK를 초기화합니다. Crashlytics는 자동으로 자체 Thread.setDefaultUncaughtExceptionHandler를 설정하여 모든 처리되지 않은 예외를 가로챕니다.

// build.gradle.kts
id("com.google.firebase.crashlytics") version "3.0.2"

// Application.kt
class App : Application() {
    override fun onCreate() {
        super.onCreate()
        FirebaseCrashlytics.getInstance()
            .setCustomKey("environment", "production")
    }

    fun logNonFatal(error: Throwable) {
        FirebaseCrashlytics.getInstance()
            .recordException(error)
    }
}

핵심 기능 Crashlytics의 — 사용자 정의 키 및 로그. 개발자는 각 크래시 리포트에 최대 64개의 키-값 쌍을 추가할 수 있습니다: 화면 상태, 선택한 요금제, 사용자 수준 등. 사용자 정의 로그 메시지도 사용 가능하며, 시간순으로 리포트에 표시됩니다.

Velocity Alert — 자동 회귀 감지

Velocity Alert는 특정 이슈에 대한 크래시 수의 급격한 증가를 모니터링하는 Crashlytics 기능입니다. 새 릴리스 후 크래시 수가 임계값을 초과하면 팀은 대규모 사용자 불만이 발생하기 5~15분 전에 푸시 알림과 이메일을 받습니다.

활성화 임계값 설정: 중요 이슈의 경우 1시간에 2배. Google, 2024에 따르면, Velocity Alert을 활성화한 팀은 수동 대시보드 모니터링에 의존하는 팀보다 평균 40% 더 빠르게 핫픽스 릴리스를 배포합니다.

iOS에서 Crashlytics 통합

iOS에서 Crashlytics SDK는 CocoaPods 또는 Swift Package Manager를 통해 통합됩니다. SDK는 자체 mach 예외 핸들러를 통해 Objective-C 예외(NSSetUncaughtExceptionHandler経由)와 OS 신호(SIGSEGV, SIGABRT)를 모두 가로챕니다.

Apple Developer, 2024에 따르면, iOS용 Crashlytics는 표준 도구로 포착되지 않는 저수준 메모리 오류를 포함하여 전체 크래시 유형의 최대 98%를 처리합니다. 이로 인해 Crashlytics는 iOS 개발의 사실상 표준이 되었습니다.

Sentry 및 Bugsnag: 대체 플랫폼

Sentry는 80개 이상의 언어 및 프레임워크를 지원하는 오픈소스 오류 모니터링 플랫폼입니다. Crashlytics와 달리 Sentry는 백엔드 개발자를 대상으로 하지만 iOS, Android, React Native 및 Flutter를 위한 완전한 기능의 SDK를 제공합니다.

Sentry의 주요 장점은 단일 대시보드에서의 성능 모니터링입니다. 개발자는 크래시뿐만 아니라 이로 이어지는 트랜잭션(느린 네트워크 요청, UI 정지, 긴 데이터베이스 작업)도 볼 수 있습니다. Sentry, 2024에 따르면, 크래시의 40%는 선행하는 성능 문제가 있으며 이 접근 방식 없이는 발견되지 않은 상태로 남습니다.

Bugsnag는 오류 그룹화 방식이 다릅니다 — 호출 스택 대신 사용자 여정을 분석합니다. 각 크래시 리포트에는 오류로 이어진 화면 및 사용자 작업의 순서가 포함됩니다. 이는 주문 처리, 등록, 결제와 같은 복잡한 비즈니스 프로세스에 특히 유용합니다.

서비스 비용은 다양합니다: Crashlytics는 Firebase 내에서 무료, Sentry는 월 5000개 이벤트에 대한 무료 요금제 제공, Bugsnag는 월 29달러부터 시작합니다. 세 플랫폼 모두 오픈소스 SDK를 제공합니다. 서비스 선택은 팀 규모, 예산 및 데이터 보안 요구 사항에 따라 달라집니다.

iOS의 크래시 리포트: 특징 및 NSException

iOS 특성 — 다계층 오류 처리 아키텍처입니다. 크래시 리포트 SDK는 Objective-C 예외(NSException), Swift 오류(Error), POSIX 신호(SIGSEGV, SIGBUS) 및 mach 예외를 가로채야 합니다. 각 유형마다 별도의 가로채기 메커니즘이 필요합니다.

NSException은 NSSetUncaughtExceptionHandler를 통해 가로채는 가장 간단한 유형입니다. 그러나 Apple, 2024에 따르면, 최신 Swift 앱의 크래시 중 NSException은 30%에 불과합니다. 나머지 70%는 OS 신호 및 Swift 런타임 오류로, mach 예외 핸들러 메커니즘이 필요합니다.

iOS 개발자는 다양한 유형의 로컬 크래시 생성을 통해 크래시 리포트를 테스트해야 합니다: 신호용 __builtin_trap(), 예외용 [NSException raise:...], Swift용 fatalError(). 이렇게 해야만 SDK가 모든 크래시 유형을 커버하는지 확인할 수 있습니다.

Android의 크래시 리포트: ANR 및 네이티브 크래시

Android는 iOS에는 없는 두 가지 특정 크래시 유형을 추가합니다: ANR(Application Not Responding) 및 C/C++ 코드의 네이티브 크래시. ANR은 UI 스레드가 5초 이상 차단될 때 발생합니다 — 시스템이 "앱이 응답하지 않습니다" 대화상자를 표시하고 종료를 제안합니다.

표준 Thread.setDefaultUncaughtExceptionHandler는 ANR을 가로채지 않습니다. 이는 예외가 아니라 ActivityManager의 신호이기 때문입니다. ANR을 추적하기 위해 Crashlytics와 Sentry는 백그라운드 워치독 스레드를 사용하여 5초마다 UI 스레드 응답성을 확인합니다. Firebase, 2024에 따르면, Android 모든 문제의 15%는 크래시가 아닌 ANR입니다.

네이티브 크래시는 JNI(Java Native Interface)를 통해 실행되는 C/C++ 코드에서 발생합니다. 이러한 크래시는 Java 예외가 아니며 Thread.setDefaultUncaughtExceptionHandler에 의해 가로채지지 않습니다. 이를 처리하기 위해 SIGSEGV, SIGABRT, SIGBUS 신호에 대한 sigaction 핸들러를 설치하는 Google Breakpad 또는 Crashpad가 사용됩니다.

Google I/O 2024에 따르면, 게임 엔진(Unity, Unreal Engine) 및 컴퓨터 비전 라이브러리(ML Kit, OpenCV)의 확산으로 네이티브 크래시 수가 증가하고 있습니다. 하이브리드 앱 개발자는 항상 네이티브 크래시 리포트를 활성화하는 것이 좋습니다.