Firebase iOS 앱 크래시: 실행 직후 꺼질 때 되돌리는 순서

Firebase SDK 업데이트 뒤 iOS 앱이 켜자마자 종료된다면 공식 상태 페이지와 릴리스 노트를 먼저 확인합니다. 원인이 업데이트로 좁혀지면 직전 버전으로 고정하는 방법을 SPM·CocoaPods별로 정리했습니다.

Firebase iOS 앱 크래시는 두 갈래로 나눠 대응합니다. SDK를 올린 직후에 생겼다면 직전 버전으로 되돌리는 게 1순위입니다. 아무것도 바꾸지 않았는데 이미 설치된 앱까지 꺼진다면 Firebase 공식 공지부터 확인합니다.

이 글을 쓰는 시점에는 확인된 공식 자료가 없었습니다. 그래서 원인 버전이나 Firebase의 공식 권장 조치는 확정해 드리지 않습니다. 대신 원인이 무엇이든 안전하게 적용할 수 있는 점검과 되돌리기 순서를 다룹니다.

목차

1. 먼저 가를 것: 내가 바꾼 게 있는가
2. Firebase 쪽 공지부터 확인하기
3. 직전 버전 번호부터 찾기
4. SPM으로 설치했을 때 되돌리기
5. CocoaPods로 설치했을 때 되돌리기
6. 되돌린 뒤 확인하는 법
7. 그래도 꺼지면 크래시 로그를 봅니다

먼저 가를 것: 내가 바꾼 게 있는가

대응 방향은 "언제부터 꺼졌는지"로 갈립니다. 증상만으로 원인을 확정할 수는 없어도, 어디부터 볼지는 정할 수 있습니다.

상황	먼저 할 일
오늘 SDK를 업데이트한 뒤 내 빌드만 꺼짐	직전 버전으로 되돌리기
코드를 안 건드렸는데 설치된 앱도 꺼짐	Firebase 공식 공지 확인
둘 다 해당	공지 확인 후 되돌리기

SDK(Software Development Kit)는 앱에 Firebase 기능을 붙여주는 부품 묶음입니다. 로그인, 분석, 크래시 보고 같은 기능이 이 부품으로 들어옵니다.

💡 SDK 버전을 되돌리면 새로 만드는 빌드만 바뀝니다. 이미 사용자 폰에 깔린 앱은 새 빌드를 배포해야 바뀝니다.

Firebase 쪽 공지부터 확인하기

외부 원인일 가능성이 있다면 내 코드를 뜯기 전에 공지부터 봅니다. 확인할 곳은 두 군데입니다.

• ☐Firebase 상태 페이지: 검색창에 "Firebase Status"를 입력해 공식 페이지를 엽니다. 진행 중인 장애가 있는지 확인합니다.
• ☐Firebase iOS 릴리스 노트: "Firebase iOS release notes"로 찾습니다. 최근 버전 항목에 크래시 관련 수정이 있는지 봅니다.

공지에 문제 버전과 권장 조치가 명시돼 있다면 그 안내가 이 글보다 우선입니다. 특정 버전으로 올리라는 안내라면 되돌리기보다 업데이트가 정답일 수 있습니다.

커뮤니티 글이나 뉴스에서 본 버전 번호는 공식 공지와 대조한 뒤에 적용하세요. 2차 출처의 숫자를 그대로 믿고 고정했다가는 엉뚱한 버전에 묶일 수 있습니다.

직전 버전 번호부터 찾기

되돌리려면 "어제까지 잘 돌던 버전"을 알아야 합니다. 프로젝트를 git(파일 변경 이력을 저장하는 도구)으로 관리했다면 기록에 남아 있습니다.

Firebase를 어떻게 설치했느냐에 따라 볼 파일이 다릅니다.

설치 방식	버전이 적힌 파일
Swift Package Manager	Package.resolved
CocoaPods	Podfile.lock

Swift Package Manager(SPM)는 Xcode에 내장된 부품 관리 도구입니다. CocoaPods는 같은 역할을 하지만 따로 설치해 씁니다. 프로젝트 폴더에 Podfile이 있으면 CocoaPods를 쓰는 겁니다.

터미널(명령어를 입력하는 프로그램)에서 프로젝트 폴더로 이동해 입력합니다.

git log -p -- "*Package.resolved" "Podfile.lock"

두 파일이 언제 어떻게 바뀌었는지 보여주는 명령입니다. - 표시가 붙은 줄이 이전 버전, + 줄이 새 버전입니다. Firebase 관련 줄에서 - 쪽 번호를 적어 둡니다.

git을 안 썼다면 Xcode 메뉴에서는 현재 버전만 확인할 수 있습니다. 이때는 릴리스 노트에서 바로 이전 버전을 찾아야 합니다.

SPM으로 설치했을 때 되돌리기

Xcode에서 버전을 고정합니다.

1. 왼쪽 목록 맨 위의 프로젝트 파일을 클릭합니다.
2. Package Dependencies 탭에서 firebase-ios-sdk를 찾습니다.
3. 규칙(Dependency Rule)을 Exact Version으로 바꾸고 적어 둔 번호를 입력합니다.
4. 메뉴 File → Packages → Reset Package Caches를 실행합니다.
5. 이어서 File → Packages → Resolve Package Versions를 실행합니다.

Exact Version은 "이 번호만 쓰라"는 고정입니다. 다른 규칙(Up to Next Major 등)은 범위 안에서 새 버전을 자동으로 받을 수 있어서, 같은 문제가 다시 들어올 수 있습니다.

CocoaPods로 설치했을 때 되돌리기

Podfile을 텍스트 편집기로 열고 Firebase 줄에 버전을 붙입니다. 아래 X.Y.Z는 앞에서 적어 둔 번호로 바꾸세요.

pod 'FirebaseAnalytics', 'X.Y.Z'

FirebaseAnalytics를 X.Y.Z 버전으로만 설치하라는 줄입니다. 쓰고 있는 Firebase 모듈마다 같은 번호로 맞춥니다.

저장한 뒤 터미널에서 실행합니다.

pod install

Podfile.lock에 남은 새 버전과 충돌한다는 메시지가 뜨면 해당 이름을 지정해 다시 받습니다.

pod update FirebaseAnalytics

지정한 부품만 Podfile 조건에 맞춰 다시 받는 명령입니다. 이후 Xcode는 .xcworkspace 파일로 열어야 합니다.

되돌린 뒤 확인하는 법

버전만 바꾸고 바로 실행하면 이전 빌드 찌꺼기가 남아 있을 수 있으니 먼저 정리합니다.

• ☐Product → Clean Build Folder 실행 (단축키 Shift+Cmd+K)
• ☐시뮬레이터와 실제 기기 양쪽에서 앱을 지운 뒤 새로 설치
• ☐앱을 완전히 종료했다가 다시 켜서 시작 화면을 넘어가는지 확인
• ☐Package.resolved 또는 Podfile.lock에 의도한 번호가 들어갔는지 확인

쇼핑몰 재고 앱을 직접 만들어 쓰는 분이라면 로그인 화면이 뜨고 목록까지 넘어가는지 봐야 합니다. Firebase는 시작 시점에 초기화되므로, 첫 화면을 통과하는지가 중요한 확인 지점입니다.

이미 App Store에 올라간 앱이라면 고친 빌드를 App Store Connect에 새로 제출해야 사용자에게 반영됩니다. 급할 때 쓸 수 있는 신속 심사 요청 절차도 있으니 App Store Connect 도움말에서 조건을 확인하세요.

그래도 꺼지면 크래시 로그를 봅니다

되돌려도 꺼진다면 원인이 SDK 버전이 아닐 수 있습니다. 앱이 꺼질 때 남긴 기록을 읽어 범위를 좁힙니다.

어디서 꺼지나	로그 보는 곳
Xcode로 실행 중	하단 콘솔 창의 마지막 빨간 메시지
TestFlight·App Store 빌드	Xcode 메뉴 Window → Organizer → Crashes
실제 기기 단독	설정 → 개인정보 보호 및 보안 → 분석 및 향상 → 분석 데이터

로그에 Firebase나 FIR로 시작하는 이름이 보이면 Firebase 내부에서 멈춘 단서입니다. 그렇다고 Firebase가 원인이라고 단정할 수는 없습니다. 설정 파일이 빠졌을 때도 같은 위치에서 멈추거든요.

같이 점검할 항목입니다.

• ☐GoogleService-Info.plist(Firebase 연결 정보 파일)가 프로젝트에 포함돼 있는지
• ☐여러 Firebase 모듈의 버전 번호가 서로 같은지
• ☐앱 시작 코드에서 FirebaseApp.configure()가 한 번만 호출되는지

로그의 마지막 몇 줄을 복사해 Claude나 ChatGPT에 붙이고 "이 iOS 크래시 로그에서 원인 후보를 알려줘"라고 물으면 읽는 데 도움이 됩니다. 단, 답변은 후보로만 보고 공식 릴리스 노트와 대조하세요.

Firebase 공지가 올라오면 그 안내대로 버전을 다시 맞추고, 고정해 둔 Exact Version은 문제가 해결된 버전으로 갱신해 두면 됩니다.

함께 보면 좋은 글

• Claude 로그인 안됨 — 인증 메일·리다이렉트 멈춤 점검 순서
• claude command not found, 설치 경로부터 확인하는 순서
• 502 Bad Gateway 원인, 어디부터 확인할까