Firebase 실무 로드맵: Auth, Firestore, Storage, Functions

이 글은 Firebase 실무 오류 해결 모음: Storage, Firestore, Auth 체크리스트의 세부 항목입니다. 전체 설정 흐름과 관련 오류 해결 순서는 대표 허브 글에서 함께 확인할 수 있습니다.

Firebase는 기능이 많아서 각각 따로 보면 실제 프로젝트에서 어떤 순서로 붙여야 하는지 흐려집니다.

이 글에서 확인할 내용

아래 섹션 링크를 통해 필요한 내용을 바로 확인할 수 있습니다.

Firebase는 기능 목록보다 서비스 흐름으로 보는 게 낫습니다
Firebase Auth는 로그인 화면보다 권한 기준을 먼저 만듭니다
Firestore와 Storage는 데이터와 파일의 역할을 나눕니다
Functions는 클라이언트에 두면 불안한 일을 옮기는 곳입니다
Hosting은 마지막 배포 단계이지만 초기에 제약을 알아둬야 합니다
기능을 붙이는 순서는 오류를 줄이는 순서이기도 합니다
마지막에는 독자가 바로 적용할 기준을 남깁니다
읽는 순서를 정하면 글도 덜 흩어집니다

Firebase는 기능 목록보다 서비스 흐름으로 보는 게 낫습니다

Firebase를 처음 붙일 때, 문서를 각각 열어두면 금방 복잡해집니다. 작은 리뷰 서비스나 포트폴리오 관리자 화면을 만든다고 생각하면 순서는 훨씬 단순해집니다. 프로젝트를 초기화하고, 사용자가 로그인하고, 로그인한 사용자가 데이터를 읽고 쓰며, 필요한 파일을 올리고, 서버에서 처리해야 할 작업을 Functions로 나누고, 마지막에 Hosting으로 배포합니다.

Firebase Auth는 로그인 화면보다 권한 기준을 먼저 만듭니다

Firebase Auth는 로그인 버튼을 붙이는 기능처럼 보이지만 실제로는 권한 판단의 출발점입니다. 사용자가 누구인지 알아야 Firestore에서 어떤 문서를 읽고 쓸 수 있는지 결정할 수 있습니다. 그래서 Auth와 Security Rules를 함께 보는 것이 자연스럽습니다. 로그인 유지와 계정 흐름은 Firebase Authentication 흐름, 권한 설계는 Firebase 보안 규칙 설계와 같이 확인하면 연결이 잘 됩니다.

const user = auth.currentUser;

if (!user) {
  throw new Error('로그인이 필요합니다.');
}

await setDoc(doc(db, 'reviews', reviewId), {
  uid: user.uid, title, createdAt: serverTimestamp()});

Firestore와 Storage는 데이터와 파일의 역할을 나눕니다

Firestore에는 상품명, 설명, 작성자, 상태값처럼 일반 쿼리와 필터링으로 다룰 데이터를 둡니다. 이미지는 Storage에 올리고 문서에는 파일 URL이나 경로만 저장하는 식으로 나누면 관리가 편합니다. 다만 전문 검색이나 복잡한 텍스트 검색은 Firestore 기본 쿼리만으로 해결한다고 보기보다 별도 검색 기능이나 인덱스 전략을 함께 검토해야 합니다. 둘을 섞어서 생각하면 이미지 업로드 실패, 문서 저장 실패, 권한 오류가 한꺼번에 보입니다. 기능을 작게 나눠 CRUD를 먼저 확인한 뒤 업로드를 붙이는 순서가 좋습니다.

Functions는 클라이언트에 두면 불안한 일을 옮기는 곳입니다

모든 로직을 Functions로 옮길 필요는 없습니다. 하지만 결제 검증, 관리자 권한 처리, 외부 API 키가 필요한 작업처럼 클라이언트에 두면 위험한 로직은 서버 쪽으로 분리해야 합니다. Cloud Functions for Firebase 2nd gen이나 firebase-functions/v2를 쓰면 이벤트 트리거나 HTTPS 함수로 이런 경계를 만들 수 있습니다. 처음부터 복잡한 백엔드를 만들기보다 클라이언트에서 하면 안 되는 일만 옮긴다고 보면 부담이 줄어듭니다. 기본은 Firebase Functions v2 사용법과 이어집니다.

Hosting은 마지막 배포 단계이지만 초기에 제약을 알아둬야 합니다

정적 사이트라면 Firebase Hosting만으로 충분할 수 있고, 서버 실행이 필요한 Next.js나 Angular 앱이라면 Firebase App Hosting이나 다른 배포 선택지를 같이 봐야 합니다. 기존 Firebase Hosting의 framework-aware Next.js 통합은 실험 기능 이력이 있으므로, 새 프로젝트에서는 App Hosting 쪽 기준도 함께 확인하는 편이 안전합니다. 배포는 마지막 단계지만 프로젝트 구조에 영향을 줍니다. 이미지 경로, 환경변수, 빌드 결과물, rewrite 설정은 초기에 기준을 알고 가는 편이 덜 흔들립니다. 선택은 Firebase Hosting App Hosting 차이에서 확장해 보면 됩니다.

공식 문서 기준으로 Firebase Auth의 현재 사용자는 초기화 상태에 따라 달라질 수 있어 인증 상태 변경 흐름을 함께 봐야 하고, Firestore 쿼리와 텍스트 검색은 같은 문제로 다루면 안 됩니다. Functions는 Cloud Functions for Firebase 세대별 차이가 있고, 동적 웹 앱 배포는 Firebase App Hosting 기준도 확인해야 합니다. 자세한 기준은 Firebase Auth 사용자 관리 문서, Firestore 쿼리 문서, Cloud Functions 버전 비교 문서, Firebase App Hosting 문서를 함께 확인하면 좋습니다.

기능을 붙이는 순서는 오류를 줄이는 순서이기도 합니다

Firebase 프로젝트에서 가장 흔한 실수는 화면부터 만들고 나중에 권한을 붙이는 것입니다. 처음에는 빠르게 동작하지만, 로그인한 사용자만 수정해야 하는 데이터나 본인 파일만 볼 수 있는 규칙이 뒤늦게 들어오면 구조를 다시 바꾸게 됩니다.

Auth와 Security Rules를 먼저 설계하고, Firestore에는 검색하고 필터링할 데이터를, Storage에는 실제 파일을, Functions에는 클라이언트에 두면 안 되는 로직을 둡니다. 이 구분이 흐려지면 권한 오류가 났을 때 Firestore 문제인지 Storage Rules 문제인지 Functions 문제인지 찾기 어려워집니다.

배포 단계에서는 Hosting만 보는 것이 아니라 환경변수, 보안 규칙 배포 여부, 배포 순서까지 같이 확인합니다. Firebase는 작은 서비스에 빠르게 붙이기 좋은 도구지만, 기능이 서로 연결되어 있기 때문에 순서를 정해두는 편이 유지보수에 훨씬 유리합니다.

마지막에는 독자가 바로 적용할 기준을 남깁니다

Firebase를 실제 프로젝트에 붙일 때는 기능 이름보다 책임 범위를 먼저 나눕니다. 사용자는 Auth로 식별하고, 데이터는 Firestore에 저장하며, 파일은 Storage에 올리고, 클라이언트에 두면 안 되는 로직은 Functions로 보냅니다.

로그인 사용자를 기준으로 읽기와 쓰기 권한을 나눴는가?
Firestore 문서와 Storage 파일 경로를 서로 연결할 기준이 있는가?
Security Rules가 실제 화면 흐름과 맞는가?
Functions로 옮길 서버 작업과 클라이언트에 남길 작업을 구분했는가?
Hosting 또는 App Hosting 배포 방식이 프로젝트 구조와 맞는가?

이 기준을 먼저 정하면 Firebase 문서를 따로따로 읽어도 길을 잃기 어렵습니다. 세부 구현은 각 기능 글에서 확인하되, 현재 프로젝트에서 어느 기능을 먼저 붙여야 하는지부터 결정하는 편이 좋습니다.

읽는 순서를 정하면 글도 덜 흩어집니다

Firebase 실무 로드맵의 핵심은 모든 개념을 한 번에 외우는 것이 아니라, 실제 작업에서 마주치는 순서대로 판단 기준을 세우는 데 있습니다. 먼저 작은 화면이나 문제 하나를 기준으로 시작하고, 필요한 순간에 다음 글로 넘어가면 학습 흐름이 끊기지 않습니다.

함께 확인하면 좋은 기준

이 글과 관련해 실제 작업에서 같이 확인하면 좋은 기준입니다.

Firebase Documentation: 적용 전 현재 문서의 권장 API, 설정 옵션, 제한 사항이 글의 설명과 맞는지 확인합니다.
비슷한 오류를 구분할 때는 발생 위치, 실행 환경, 재현 조건을 먼저 분리해 확인합니다.
프로젝트에 적용할 때는 기존 코드 구조, 의존성 버전, 배포 환경에서 같은 기준이 유지되는지 확인합니다.

이 글이 마음에 드세요?

RSS 피드를 구독하세요!