아침에 일어났더니 우리 앱이 안 켜진다
모바일 개발자에게 가장 무서운 알림은 아마 '앱이 실행하자마자 꺼져요'라는 사용자 문의일 거예요. 그런데 이번에는 한두 앱이 아니라 Firebase SDK를 쓰는 여러 iOS 앱에서 크래시가 났다는 제보가 나왔어요. 개발자 뉴스레터 The Pragmatic Engineer를 운영하는 Gergely Orosz가 이 상황을 공유하면서 알려졌는데요, 이 글을 쓰는 시점에는 정확한 원인이나 영향 범위에 대한 공식 분석이 충분히 나오지 않았어요. 그러니 최신 상황은 Firebase 상태 대시보드와 firebase-ios-sdk GitHub 이슈를 직접 확인하시는 게 가장 정확해요.
원인이 무엇이었든, 이번 일은 모바일 개발자라면 꼭 한 번 생각해 봐야 할 질문을 던져요. 내가 짠 코드가 아닌 SDK 하나가 내 앱 전체를 죽일 수 있다면, 나는 뭘 대비해야 할까?
왜 SDK 하나가 앱 전체를 죽일 수 있을까
Firebase는 구글의 모바일 백엔드 플랫폼이에요. 푸시 알림(FCM), 분석(Analytics), 크래시 리포트(Crashlytics), 원격 설정(Remote Config), 인증 같은 기능을 SDK 형태로 앱에 넣어서 쓰죠. 그런데 이 SDK들은 여러분 앱과 같은 프로세스 안에서 돌아가요. 이게 뭐냐면, 같은 집에 사는 룸메이트 같은 거예요. 룸메이트가 부엌에서 불을 내면 여러분 방도 무사할 수 없잖아요. SDK 코드에서 처리되지 않은 예외가 터지면 iOS는 앱 전체를 종료시켜요.
특히 위험한 게 앱 시작 시점의 초기화예요. 보통 AppDelegate의 didFinishLaunching에서 FirebaseApp.configure()를 호출하는데요, 여기서 문제가 생기면 사용자는 화면을 보기도 전에 앱이 꺼지는 걸 경험해요. 앱을 켤 때마다 꺼지니까 사용자가 할 수 있는 게 없고, 심지어 앱 업데이트로 고치려 해도 심사를 통과해 배포되기까지 시간이 걸리죠.
이미 한 번 겪었던 일: 2020년 Facebook SDK 사태
이런 일이 처음은 아니에요. 2020년 5월과 7월, Facebook iOS SDK 때문에 Spotify, TikTok, Pinterest 같은 유명 앱들이 실행 직후 크래시 나는 사고가 있었어요. 당시 원인은 Facebook 서버 쪽에서 내려보낸 설정 값의 형식이 SDK가 기대한 것과 달랐고, SDK가 그걸 안전하게 처리하지 못했던 거였어요.
여기서 중요한 교훈은 이거예요. 앱을 새로 배포하지 않았는데도, 서버 쪽 변경만으로 이미 설치된 앱이 망가질 수 있다는 것. SDK 버전을 고정(pinning)해 두는 것만으로는 이런 문제를 막을 수 없어요. SDK가 실행 중에 원격에서 설정을 받아오는 구조라면, 그 설정이 곧 새로운 코드 경로가 되는 셈이거든요. 이번 Firebase 건이 정확히 같은 원인인지는 공식 발표를 봐야 알겠지만, 구조적으로 같은 위험을 안고 있다는 점은 분명해요.
우리 앱을 지키기 위한 실전 대비책
그렇다고 Firebase를 안 쓸 수는 없잖아요. 대신 피해 범위를 줄이는 방법은 있어요.
1. 초기화를 꼭 필요한 시점으로 미루기 모든 SDK를 앱 시작과 동시에 켤 필요는 없어요. 분석이나 광고 SDK는 첫 화면이 뜬 뒤에 초기화해도 대부분 문제없어요. 이렇게 하면 적어도 앱이 켜지지도 않는 최악의 상황은 피할 수 있어요.
2. 서드파티 SDK를 감싸는 래퍼 두기 SDK를 앱 코드 곳곳에서 직접 호출하지 말고, 내가 만든 얇은 래퍼 클래스를 거치게 하세요. 나중에 SDK를 끄거나 교체할 때 수정할 곳이 한 군데로 줄어들어요.
3. 우리만의 킬 스위치 준비하기 특정 SDK 초기화를 원격으로 끌 수 있는 스위치를 두는 거예요. 다만 그 스위치를 Firebase Remote Config로만 만들면, Firebase가 문제일 때 스위치도 같이 죽을 수 있다는 점은 기억해 두세요. 자체 서버의 간단한 설정 엔드포인트가 더 안전할 수 있어요.
4. 크래시 감지 채널을 이중화하기 Crashlytics로 크래시를 모니터링하는데 크래시 원인이 Firebase라면, 제일 필요할 때 리포트가 제대로 안 들어올 수도 있어요. App Store Connect의 크래시 통계나 MetricKit 같은 OS 수준의 데이터도 함께 보는 습관을 들이면 좋아요.
한국 개발자에게 주는 시사점
국내 앱도 푸시 알림은 FCM, 크래시 수집은 Crashlytics로 처리하는 경우가 정말 많아요. 사실상 필수 인프라처럼 쓰고 있죠. 이번 기회에 우리 앱의 AppDelegate를 한번 열어보세요. 앱 시작 시점에 초기화되는 서드파티 SDK가 몇 개인지, 그중 하나가 터지면 앱이 어떻게 되는지, 원격으로 끌 방법이 있는지 점검해 보는 것만으로도 큰 의미가 있어요. 장애 대응 문서에 '서드파티 SDK 장애' 시나리오를 추가해 두는 것도 추천해요.
마무리
한 줄 정리: 내 코드가 완벽해도 앱 안에 들어간 SDK 하나가 앱 전체를 멈출 수 있으니, 의존성은 곧 리스크라는 걸 설계에 반영해야 해요.
여러분 팀은 서드파티 SDK 장애에 대비한 킬 스위치나 대응 절차를 갖추고 있나요? 실제로 SDK 때문에 장애를 겪어 본 경험이 있다면 어떻게 해결하셨는지 궁금해요.
🔗 출처: Hacker News