Firebase 실무 오류 해결 모음: Storage, Firestore, Auth 체크리스트

2026.05.11·수정 2026.07.19·약 7분

Firebase 실무 오류를 Storage, Auth, Firestore 기준으로 나눠 해결하기

이 글은 Firebase 실무 오류 해결의 대표 허브입니다. Storage, Firestore, Auth, Functions, Hosting 문제가 서로 섞여 보일 때 먼저 제품 영역, 권한 주체, 요청 경로, 배포 환경을 분리한 뒤 상세 해결 글과 공식 문서 기준으로 이동하면 됩니다.

Firebase 오류를 제품별로 나눠 해결하는 순서

아래 순서대로 Storage, Auth, Firestore 관련 상세 글을 이어서 확인합니다. 권한 문제는 Security Rules와 Firebase Authentication 상태를 함께 보고, 관리자 권한은 클라이언트 상태가 아니라 Custom Claims 또는 서버 검증 기준으로 분리합니다.

  1. 1단계 · 전체 학습·점검 순서 · Firebase 실무 로드맵
  2. 2단계 · Next.js 초기화 구조 · Firebase 초기화 구조
  3. 3단계 · Storage 이미지 403·404 · Firebase Storage 이미지 오류 해결
  4. 4단계 · Storage CORS · Firebase CORS 오류 해결
  5. 5단계 · Firestore·Storage Rules · Firebase 보안 규칙 설계
  6. 6단계 · Auth 상태 관리 · Firebase Auth Context 설계
  7. 7단계 · 권한·배포 확장 · Firebase Custom Claims 사용법

문제 상황 요약

Firebase Storage Auth Firestore 오류 분류 흐름

Firebase에서 문제가 생기면 먼저 어떤 제품에서 발생했는지 나눕니다. Storage 이미지는 403, 404, download URL, token, Storage Rules, CORS를 분리해서 보고, Auth 문제는 로그인 상태 유지와 권한 전달을 확인합니다. Firestore 문제는 Security Rules의 요청 경로, request.auth.uid, 문서 소유자 필드, 실제 쿼리 조건을 함께 봐야 합니다.

관련 오류 목록

문제 상황 먼저 확인할 위치 연결 글
Storage 이미지가 403 또는 404로 깨짐 download URL, token, Storage Rules, 파일 경로, 브라우저 직접 접근 여부 Firebase Storage 이미지 오류 해결
Next.js에서 Firebase 초기화가 중복되거나 환경변수가 헷갈림 firebase.ts, env 값, client/server 경계, 웹 config와 service account 구분 Firebase 초기화 구조
로그인 사용자 정보를 전역에서 관리해야 함 AuthContext, onAuthStateChanged, 라우팅 보호 Firebase Auth Context 설계
관리자 권한과 일반 사용자 권한을 나눠야 함 Custom Claims, Admin SDK, ID token 갱신, Rules 조건 Firebase Custom Claims 사용법

Firebase 오류 해결 순서

  1. Storage, Firestore, Auth, Hosting 중 어느 영역의 오류인지 먼저 분리합니다.
  2. 브라우저 콘솔, Network 탭, Firebase Console 로그에서 실제 에러 메시지를 확인합니다.
  3. 권한 문제라면 로그인 상태, request.auth.uid, Rules 조건, 파일/문서 경로를 함께 확인합니다.
  4. 환경변수 문제라면 로컬과 배포 환경의 Firebase config 값을 비교하되, 웹 API key와 Admin SDK service account를 같은 종류의 비밀값으로 취급하지 않습니다.
  5. Storage가 브라우저 다운로드에서만 실패하면 Rules와 URL 검증 후 CORS 설정을 별도로 확인합니다.
  6. 수정 후 공개 URL, 로그인 사용자, 비로그인 사용자 조건을 나눠 재검증합니다.
Firebase 실무 오류 제품별 해결 체크리스트

실무 체크리스트

  • Firebase config가 로컬과 배포 환경에 모두 등록되어 있는지 확인합니다.
  • Firebase 웹 API key는 프로젝트 식별용 공개 config로 볼 수 있지만, Security Rules와 App Check 같은 보호 장치가 실제 접근 제어를 맡는다는 점을 확인합니다.
  • Storage 공개 파일과 비공개 파일의 경로, download URL, token, Rules를 분리합니다.
  • Firestore Rules는 실제 요청 경로, request.auth.uid, 문서 소유자 필드, 쿼리 조건으로 테스트합니다.
  • Auth 상태는 새로고침, 로그아웃, 권한 변경 후에도 일관되는지 확인합니다.
  • 관리자 권한은 클라이언트 상태가 아니라 Custom Claims 또는 서버 검증으로 판단합니다.

자주 묻는 질문

Firebase Storage 403은 CORS 문제인가요?

대부분은 먼저 URL, token, Rules 문제를 봐야 합니다. 새 탭 직접 접속도 실패하면 CORS보다 권한과 URL 문제일 가능성이 큽니다. 공식 문서 기준으로 브라우저에서 직접 다운로드해야 하는 경우에는 Cloud Storage bucket의 CORS 설정도 별도로 필요할 수 있습니다.

Firebase config 값은 공개되어도 되나요?

Firebase 웹 config와 Firebase 서비스용 API key는 일반적인 서버 비밀키와 다르게 클라이언트 코드에 포함될 수 있습니다. 다만 보안은 Security Rules, Auth 조건, App Check, API key 제한으로 관리해야 하며, Admin SDK 키나 service account는 절대 클라이언트에 두면 안 됩니다.

Firestore permission-denied는 어디부터 보나요?

요청 경로, 로그인 uid, request.auth.uid, Rules 조건, 문서 소유자 필드를 순서대로 확인합니다. Firestore Rules는 단순한 필터가 아니므로, Rules가 허용하는 조건과 클라이언트 쿼리가 같은 범위를 요청하는지도 함께 확인해야 합니다.

공식 기준은 Firebase Storage download files, Cloud Storage Security Rules, Cloud Firestore Security Rules, Security Rules and Firebase Authentication, Custom Claims and Security Rules, Firebase API keys 문서에서 다시 확인할 수 있습니다.

함께 읽으면 좋은 글

이 글이 마음에 드세요?

RSS 피드를 구독하세요!

댓글 남기기