Android·iOS FCM 푸시 알림 인프라 기반 구축 완료

Firebase 연결 작업을 마무리했다. Android/iOS 양쪽 client config를 모두 세팅하면서 FCM 푸시 기반을 잡은 것.

왜 이 시점에 Firebase 연결이었나

푸시 알림은 앱에서 사용자 재접촉 수단 중 거의 유일하게 즉각적인 채널이다. 기능 개발을 먼저 쫙 뽑고 나중에 붙이면 된다는 생각도 있었지만, 팀 내에서 이야기하다 보니 FCM 연결 자체가 예상보다 설정 지뢰가 많고, 특히 iOS 쪽 APNs 연동까지 가면 시간이 더 걸린다는 결론이 났다. 늦게 붙이면 늦게 터지는 문제가 되고, 그게 릴리즈 직전에 터지면 팀 전체가 압박받는 상황이 된다. 그래서 기능 완성도보다 인프라 기반을 먼저 잡는 쪽으로 우선순위를 당겼다.

변경된 파일 구성

파일 수 자체는 적다. 하지만 이 네 파일이 정확히 맞아떨어져야 앱이 Firebase 프로젝트와 연결되기 때문에, 단 하나만 빠지거나 패키지명이 틀리면 런타임에서 아무 에러 없이 푸시가 조용히 안 오는 상황이 발생한다. 그게 이 작업의 까다로운 부분이다.

Android 쪽 설정 포인트

build.gradle.kts에서 주의할 부분은 플러그인 적용 순서다. com.google.gms.google-services는 apply plugin 위치가 잘못되면 빌드 자체는 되는데 Firebase 초기화가 제대로 안 되는 케이스가 있다.

// app/android/app/build.gradle.kts
plugins {
    id("com.android.application")
    id("com.google.gms.google-services") // 반드시 android application 뒤에
}

dependencies {
    implementation(platform("com.google.firebase:firebase-bom:33.x.x"))
    implementation("com.google.firebase:firebase-messaging")
}

settings.gradle.kts에는 플러그인 classpath를 등록해야 하는데, 프로젝트 레벨 build.gradle 방식에서 settings.gradle.kts 방식으로 마이그레이션된 구조라면 등록 위치가 다르다. 이걸 헷갈려서 이전 방식대로 넣으면 역시 빌드는 되고 런타임에 문제가 생긴다.

iOS 쪽 - GoogleService-Info.plist 배치

iOS는 Runner/GoogleService-Info.plist 경로에 파일을 두는 것 자체는 단순하지만, Xcode 프로젝트에 실제로 추가(Copy Bundle Resources) 되어 있어야 빌드 시 포함된다. 파일을 폴더에 그냥 복사해두면 Xcode가 인식 못 하고, 결과적으로 Firebase 초기화 시 파일을 찾지 못한다는 크래시가 난다.

Flutter 프로젝트 기준으로는 Runner 타겟에 파일이 연결되어 있는지 확인하는 게 필수다.

Xcode > Runner target > Build Phases
> Copy Bundle Resources > GoogleService-Info.plist 존재 여부 확인

이 부분이 팀원 중 처음 iOS 빌드 환경 잡는 분들이 자주 빠뜨리는 포인트라 PR 코멘트에 명시해뒀다.

보안 관련 — config 파일을 어떻게 관리할 것인가

google-services.json과 GoogleService-Info.plist는 API 키와 프로젝트 식별 정보를 담고 있다. 이걸 그대로 레포에 커밋해도 되냐는 팀 내에서 꽤 자주 나오는 질문이다.

• Firebase 공식 입장: 이 파일들은 클라이언트 식별용이므로 앱 번들에 포함되는 정보. 즉 앱을 배포하면 어차피 노출된다.
• 다만 레포가 퍼블릭이거나, Firebase Security Rules가 허술하면 문제가 될 수 있다.
• 우리 케이스는 프라이빗 레포이고 Security Rules를 별도로 관리하므로 커밋하는 쪽으로 정리했다.
• CI/CD에서 시크릿으로 주입하는 방식도 있는데, 그쪽은 빌드 파이프라인 복잡도가 올라가서 현재 팀 규모에선 오버엔지니어링이라는 판단이었다.

회고

config 파일 네 개짜리 작업이지만, 이걸 잘못 놓으면 나중에 "푸시가 왜 안 와요?" 이슈가 QA 막바지에 터지는 전형적인 패턴이 된다. 그 비용이 훨씬 크기 때문에, 작은 설정 작업일수록 PR 설명을 꼼꼼하게 적어두는 편이다. 나중에 온보딩하는 팀원이나 로컬 환경 다시 세팅하는 상황에서 그게 실질적인 도움이 된다.

다음 작업은 실제 FCM 토큰 수신 로직과 foreground/background 핸들링 분기를 붙이는 단계다.

🛒 이 글과 어울리는 추천 상품

• 노트북 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →
• 모니터 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.