Firebase Crashlytics 크래시 로그 확인하는 방법 (Swift / iOS)

Firebase Crashlytics 크래시 로그 확인하는 방법 (Swift / iOS)

iOS 앱을 운영하다 보면 테스트에서는 보이지 않던 문제가 실제 사용자 환경에서 발생하는 경우가 많다. 특히 특정 기기, 특정 iOS 버전, 특정 화면 흐름에서만 발생하는 크래시는 재현이 쉽지 않다. 이럴 때 가장 먼저 확인하게 되는 도구가 Firebase Crashlytics다.

Firebase Crashlytics를 사용하면 앱에서 발생한 크래시와 non-fatal 오류를 Firebase 콘솔에서 모아볼 수 있다. 단순히 종료 여부만 보는 것이 아니라, 어떤 버전에서 많이 발생했는지, 어떤 기기와 운영체제에서 집중적으로 발생했는지, 어떤 로그가 직전에 남았는지까지 함께 볼 수 있어서 실제 운영 앱에서 매우 유용하다.

Firebase Crashlytics에서 무엇을 볼 수 있나

Crashlytics에서는 크게 두 가지 흐름으로 로그를 확인하게 된다. 첫 번째는 전체 이슈 목록에서 어떤 문제가 많이 발생하는지 보는 것이고, 두 번째는 특정 이슈 안으로 들어가서 실제 이벤트와 스택 트레이스, 기기 정보, 커스텀 로그를 확인하는 것이다.

• 크래시 이슈 목록
• non-fatal 이슈 목록
• 앱 버전별 발생 현황
• 기기 / OS 버전 정보
• 스택 트레이스
• 로그 메시지
• Custom Keys
• 사용자 식별 정보(설정한 경우)

Crashlytics 로그를 보기 전에 확인할 것

Crashlytics 로그가 제대로 보이려면 기본 설정이 먼저 되어 있어야 한다. Firebase SDK가 앱에 연결되어 있어야 하고, 앱 시작 시 FirebaseApp.configure()가 호출되어야 하며, 테스트 크래시를 한 번 발생시켜 첫 데이터가 콘솔에 올라오는지 확인하는 것이 좋다. 또 iOS에서는 dSYM이 제대로 업로드되어야 함수명과 코드 위치가 사람이 읽을 수 있는 형태로 보인다.

기본 초기화 예시

import SwiftUI
import FirebaseCore

@main
struct MyApp: App {
    init() {
        FirebaseApp.configure()
    }

    var body: some Scene {
        WindowGroup {
            ContentView()
        }
    }
}

테스트 크래시 예시

Button("Crash Test") {
    fatalError("Crashlytics test crash")
}

Crashlytics는 설정 후 테스트 크래시를 강제로 발생시켜 대시보드에 첫 보고서가 들어오는지 확인하는 절차를 권장한다. 또 Apple 플랫폼에서는 dSYM이 처리되어야 읽기 쉬운 크래시 리포트를 볼 수 있다.

1. Firebase 콘솔에서 Crashlytics 메뉴로 이동하기

가장 먼저 Firebase 콘솔에 접속한 뒤, 해당 프로젝트를 선택하고 왼쪽 메뉴에서 Crashlytics로 이동한다. 정상적으로 데이터가 수집되고 있다면 이 화면에서 현재 열려 있는 이슈와 최근 발생 이슈를 볼 수 있다.

처음 보는 화면에서는 보통 어떤 문제가 많이 발생하는지부터 파악하는 것이 좋다. 특히 최근 릴리즈 이후 새로 증가한 이슈가 있는지 먼저 확인하면 대응 우선순위를 정하기 쉽다.

2. Issue 목록에서 많이 발생한 크래시 찾기

Crashlytics의 기본 화면에서는 비슷한 유형의 크래시를 하나의 이슈로 묶어서 보여준다. 이렇게 묶인 이슈를 기준으로 보면, 단일 사용자 문제인지 아니면 특정 버전에서 반복되는 문제인지 빠르게 파악할 수 있다.

이 단계에서 먼저 보는 항목은 보통 다음과 같다.

• 문제가 발생한 앱 버전
• 영향을 받은 사용자 수
• 이벤트 수
• 최근 발생 시점
• 문제 심각도

사용자 수가 많고 최신 릴리즈에서 발생한 문제라면 우선순위를 높게 잡는 것이 일반적이다.

3. 특정 이슈를 열고 상세 로그 확인하기

목록에서 원하는 이슈를 클릭하면 상세 화면으로 들어갈 수 있다. 이 화면이 실제로 가장 많이 보게 되는 곳이다. 여기에서는 단순한 에러 이름보다 훨씬 더 중요한 정보가 보인다.

상세 화면에서 주로 보는 정보

• 오류가 발생한 스레드
• 크래시 시점의 스택 트레이스
• 앱 버전 / 빌드 번호
• 기기 모델
• iOS 버전
• 발생 빈도
• 최근 이벤트
• 사용자 지정 로그
• Custom Keys

여기서 핵심은 단순히 마지막 함수 이름만 보는 것이 아니라, 어떤 화면 흐름에서 문제가 시작되었는지 위아래 호출 스택을 함께 읽는 것이다.

4. 스택 트레이스 읽는 방법

iOS 개발자가 Crashlytics에서 가장 먼저 확인하는 부분은 보통 스택 트레이스다. 스택 트레이스는 크래시가 발생하기 전 어떤 함수 호출이 이어졌는지를 보여준다. 이 정보가 제대로 보이면 실제 원인 추적 속도가 크게 빨라진다.

예시로 볼 수 있는 형태

Thread 0 Crashed:
0   MyApp             0x0000000101234567 closure #1 in HomeViewController.loadData()
1   MyApp             0x0000000101234000 HomeViewController.loadData()
2   UIKitCore         0x0000000187654321 ...

이때 가장 먼저 볼 포인트는 다음과 같다.

1. 내 앱 모듈에서 시작되는 첫 번째 프레임
2. 메인 스레드에서 난 문제인지 여부
3. 클로저 내부인지, 비동기 작업 중인지 여부
4. 배열 인덱스, nil 처리, 강제 언래핑, UI 업데이트 타이밍 문제 가능성

스택 트레이스가 주소값만 보이거나 함수명이 이상하게 보인다면 dSYM 업로드 문제를 먼저 의심하는 것이 좋다.

5. dSYM이 중요한 이유

Crashlytics에서 로그가 보여도, dSYM이 없으면 사람이 읽기 어려운 형태로 남을 수 있다. 즉, 크래시가 났다는 사실은 보여도 어떤 함수에서 났는지 정확하게 보기가 어려워진다. 그래서 iOS 프로젝트에서는 dSYM 업로드 상태를 항상 같이 점검해야 한다.

dSYM 누락 시 보일 수 있는 형태

0   MyApp   0x00000001034f2a84 0x1034e0000 + 76420

dSYM이 정상 처리된 경우

0   MyApp   0x00000001034f2a84 HomeViewController.loadData() + 120

만약 함수명 대신 주소값 위주로 보인다면, Archive 빌드 기준 dSYM 생성과 Crashlytics 업로드 스크립트를 먼저 확인하는 편이 좋다.

6. Event 탭에서 실제 발생 사례 보기

하나의 Issue 안에서도 실제 발생 이벤트는 여러 개일 수 있다. 같은 원인으로 묶였더라도, 발생한 기기나 OS 버전, 직전 로그 메시지는 조금씩 다를 수 있다. 그래서 특정 이벤트를 직접 열어보면 문제를 더 구체적으로 이해할 수 있다.

예를 들어 어떤 이벤트는 iOS 18에서만 발생하고, 다른 이벤트는 특정 iPhone 모델에서만 유독 많이 발생할 수 있다. 이 차이를 보면 재현 범위를 좁히는 데 도움이 된다.

Event에서 체크할 포인트

• 문제가 발생한 정확한 시간
• OS 버전
• 기기 모델
• 앱 버전
• 직전 로그
• 사용자 지정 값

7. 커스텀 로그를 함께 남기면 분석이 쉬워진다

Crashlytics를 더 잘 활용하려면 단순 크래시 수집만 하지 말고, 중요한 흐름에 로그를 남기는 것이 좋다. 예를 들어 네트워크 응답 직전, 특정 화면 진입 직후, 결제 단계, 로그인 성공 직후 같은 포인트에 로그를 남기면 크래시 직전 상황을 훨씬 쉽게 파악할 수 있다.

로그 남기기 예시

import FirebaseCrashlytics

Crashlytics.crashlytics().log("Home API request started")
Crashlytics.crashlytics().log("Home API response parsed")

이런 로그는 크래시 직전 흐름을 보는 데 꽤 도움이 된다. 특히 비동기 네트워크 코드나 복잡한 화면 전환에서 유용하다.

8. Custom Key를 설정하면 상태 추적이 쉬워진다

단순 문자열 로그만으로는 부족할 때가 많다. 이럴 때는 Custom Key를 이용해서 현재 앱 상태를 key-value 형태로 남길 수 있다. 예를 들면 현재 로그인 여부, 선택된 탭, 서버 응답 코드, 특정 feature flag 상태 등을 남길 수 있다.

Custom Key 예시

import FirebaseCrashlytics

Crashlytics.crashlytics().setCustomValue("home", forKey: "screen_name")
Crashlytics.crashlytics().setCustomValue(3, forKey: "selected_tab_index")
Crashlytics.crashlytics().setCustomValue(true, forKey: "is_logged_in")

이렇게 남긴 값은 이슈 상세 화면에서 함께 볼 수 있어서, 왜 특정 조건에서만 크래시가 나는지 파악하는 데 유리하다.

9. non-fatal 로그도 같이 확인하기

Crashlytics는 앱이 실제로 죽는 크래시뿐 아니라 non-fatal 오류도 함께 관리할 수 있다. 앱이 종료되지는 않았지만, 내부적으로 처리된 오류가 반복되는 경우 나중에 더 큰 문제로 이어질 수 있으므로 미리 보는 것이 좋다.

예를 들어 JSON 파싱 실패, 서버 응답 형식 이상, 내부 상태 불일치 같은 문제는 당장 앱을 종료시키지 않더라도 사용자 경험을 해칠 수 있다. 그래서 크래시만 보는 것보다 non-fatal 이슈까지 함께 보는 운영 습관이 중요하다.

10. 실제로 크래시 로그를 확인할 때 추천하는 순서

운영 중인 앱에서 새 크래시가 올라왔을 때는 아래 순서로 보면 정리가 잘 된다.

1. Issue 목록에서 최신 버전 영향 여부 확인
2. 영향 사용자 수와 이벤트 수 확인
3. 상세 이슈에서 스택 트레이스 확인
4. 내 앱 코드 프레임부터 원인 후보 좁히기
5. Event별 기기 / OS 차이 확인
6. 로그와 Custom Key 확인
7. dSYM 누락 여부 확인
8. 재현 가능한 조건 정리

11. 자주 놓치는 포인트

스택 트레이스 마지막 줄만 보고 판단하는 경우

실제 원인은 마지막 프레임보다 그 위쪽 호출 흐름에 있는 경우가 많다. 특히 비동기 처리에서는 트리거가 다른 함수에 있을 수 있다.

특정 기기 또는 특정 iOS 버전 차이를 안 보는 경우

같은 이슈라도 특정 조합에서만 두드러지는 경우가 있어서, 재현 환경을 좁히는 데 이 정보가 매우 중요하다.

dSYM 문제를 놓치는 경우

함수명이 제대로 보이지 않는다면 코드 문제를 보기 전에 dSYM 업로드 상태를 먼저 확인하는 편이 빠르다.

12. 마무리

Firebase Crashlytics 크래시 로그를 확인하는 핵심은 단순히 에러 메시지를 보는 것이 아니라, 이슈 목록에서 우선순위를 정하고, 상세 화면에서 스택 트레이스와 이벤트 정보, 기기 정보, 커스텀 로그를 함께 읽는 것이다.

특히 iOS 앱에서는 dSYM이 제대로 업로드되어 있어야 로그가 읽기 쉬워지고, Custom Key와 로그를 잘 남겨두면 분석 시간이 크게 줄어든다. 실제 운영에서는 크래시가 난 사실보다 왜 이 사용자 환경에서 이 흐름으로 문제가 발생했는지를 파악하는 것이 더 중요하다.

정리

• Crashlytics 메뉴에서 Issue 목록부터 확인한다.
• 사용자 수와 이벤트 수를 보고 우선순위를 정한다.
• 상세 이슈에서 스택 트레이스를 읽는다.
• Event별 기기 / OS / 버전 차이를 본다.
• Custom Key와 로그를 적극적으로 활용한다.
• 함수명이 이상하면 dSYM 업로드 상태를 먼저 확인한다.

같이 보면 좋은 글

• Firebase Crashlytics 설정 방법 (Swift / iOS)
• Firebase Crashlytics dSYM Missing 오류 해결 방법
• iOS dSYM 파일 위치 확인 방법
• Xcode Archive와 Release 빌드 차이 정리

Firebase Crashlytics 관련 글

• Firebase Crashlytics SPM 설치 방법 (Swift / iOS)
• Firebase Crashlytics 설정 방법 (Swift / iOS)
• Firebase Crashlytics 크래시 로그 확인하는 방법 (Swift / iOS)
• Firebase Crashlytics dSYM Missing 오류 해결 방법 (SPM 환경 포함)
• Firebase Crashlytics에서 UUID Missing 해결 방법 (iOS / Swift)