Google 로그인이 무응답이던 원인은 설정 파일의 웹 클라이언트 누락

google-services.json에 web client 항목이 빠져 있어서 Google 로그인이 조용히 죽고 있었다.

왜 이게 문제가 됐나

Firebase 기반 Google 로그인을 Android 앱에 붙일 때, 대부분의 팀이 한 번쯤 이 함정에 빠진다. google-services.json은 단순히 "Firebase 프로젝트 연결 설정 파일" 정도로 인식하기 쉬운데, 실제로 이 파일 안에는 여러 OAuth client 항목이 중첩 구조로 들어간다. Android client, Web client, 경우에 따라 iOS client까지. Google Sign-In SDK가 서버 측 인증(ID 토큰 발급)을 처리할 때 web client의 client_id를 참조하는데, 이 항목이 json에 없으면 토큰 발급 단계에서 조용히 실패한다.

에러 메시지도 친절하지 않다. 런타임에서 명확한 예외를 던지기보다는 GoogleSignInAccount가 null로 떨어지거나, ID 토큰이 null인 채로 백엔드 인증 요청까지 넘어가서 서버 쪽 로그를 파야 원인이 보이는 경우가 많다. 팀원이 "로그인 버튼 눌렀는데 아무 반응이 없어요" 라고 올렸을 때, 처음엔 네트워크 문제나 SHA-1 지문 이슈로 의심했다. 결국 google-services.json 내부 구조를 직접 들여다보고 나서야 web_client 블록 자체가 없다는 걸 발견했다.

무엇을 수정했나

Firebase 콘솔 → 프로젝트 설정 → "내 앱" 섹션에서 google-services.json을 재다운로드하는 게 전부다. 단, 재다운로드 전에 Firebase 콘솔의 OAuth 클라이언트 설정에 Web 클라이언트가 실제로 등록되어 있어야 한다. 이게 없으면 새로 받은 json에도 web client 항목은 빠진다.

수정 후 json 내부에서 확인해야 할 핵심 구조는 대략 이렇다.

{
  "client": [
    {
      "client_info": { ... },
      "oauth_client": [
        {
          "client_id": "xxxx.apps.googleusercontent.com",
          "client_type": 3
        },
        {
          "client_id": "yyyy.apps.googleusercontent.com",
          "client_type": 1
        }
      ]
    }
  ]
}

client_type: 3이 Web client, client_type: 1이 Android client다. 기존 파일엔 client_type: 1만 있었고, client_type: 3 블록이 통째로 없었던 것.

회고

이 작업 자체는 파일 하나 교체라 diff는 작다. 그런데 이런 류의 수정이 팀 입장에서 은근히 까다로운 이유가 있다.

• 재현이 환경마다 다르다. 개발 빌드에서 쓰는 Firebase 프로젝트와 스테이징/프로덕션 프로젝트가 분리된 경우, 한 환경에서만 web client가 등록되어 있으면 특정 빌드에서만 터진다. "내 로컬에선 되는데요" 패턴의 전형.
• google-services.json을 .gitignore에 넣는 팀도 있다. 보안상 이유로 VCS에서 제외하면, 신규 입사자나 환경 세팅 시 누락이 잦다. 비밀 값이 포함된 파일이라 완전 공개도 곤란하고, 그렇다고 누락을 방치하기도 곤란한 트레이드오프. 우리 팀은 내부 비밀 관리 도구를 통해 배포 시점에 주입하는 방식으로 타협하고 있다.
• 코드리뷰에서 잘 안 걸린다. json 파일 변경은 리뷰어가 내부 구조까지 꼼꼼히 보지 않는 경향이 있다. "json 갱신했겠거니" 하고 approve 누르기 쉬운데, 이번처럼 항목 누락 여부가 핵심인 경우엔 리뷰 체크리스트에 "web client 항목 존재 여부 확인"을 명시적으로 넣는 게 맞다는 걸 다시 느꼈다.

Google 로그인 관련 설정은 Firebase 콘솔, Google Cloud Console, 앱 코드, json 파일 이 네 곳이 전부 맞물려야 한다. 어느 하나가 틀어지면 증상이 겉으로 잘 안 드러난다. 그래서 초기 세팅이나 Firebase 프로젝트 마이그레이션 때 이 파일 구조를 한 번은 직접 열어보고 항목을 육안으로 확인하는 습관이 필요하다. 자동화 검증 스크립트를 CI에 붙여두는 것도 나쁘지 않은 선택이다.

끝.