BE
[Firebase] Cloud Firestore 시작하기
| 서론
안녕하세요 팡일입니다!
Firebase 프로젝트 시작, 그리고 Firebase Hosting에 이어,
오늘은 Fireabase Cloud Firestore에 대해서 정리해보려고 합니다.
데이터를 어떤 식으로 생성하고, 어떤 식으로 관리하게 되는지 살펴봅시다!
| 데이터베이스 만들기
1) Cloud Firestore로 이동하기
- Firebase Console에 접속한 뒤, 좌측의 '빌드' 탭에서 Firestore Database 메뉴를 클릭합니다.
- '데이터 베이스 만들기' 버튼을 클릭합니다.
2) 버전 선택하기
Standard 버전은 자동 인덱싱이 포함된 간단한 쿼리 엔진으로, 1MiB 이하의 문서를 다루는 일반적인 Firestore 용도에 적합합니다.
Enterprise 버전은 MongoDB 호환 고급 쿼리 엔진으로, 최대 4MiB 문서를 지원하며 MongoDB 드라이버와 도구 전용 환경에서 사용됩니다.
-> 현재 프로젝트는 일반적인 Firestore 용도에 가깝기에, Standard 버전으로 선택했습니다.
3) 데이터베이스 ID 및 위치 선택하기
데이터베이스 ID (default) : 기본 데이터베이스로 자동 지정되며, 대부분의 프로젝트에서는 그대로 사용합니다.
위치 asia-northeast3 (Seoul) : 실제 데이터가 저장될 물리적 서버 지역을 의미하며, 서울 리전을 선택하면 한국 사용자에게 지연(latency) 이 최소화됩니다.-> 단, 이 위치는 한 번 설정하면 변경할 수 없으므로 반드시 최종 배포 지역(한국 등)에 맞게 신중히 선택해야 합니다.
-> 주 대상이 한국에 거주하는 경우이기에, asia-northeas3 (Seoul)을 선택했습니다.
4) 보안 규칙(Security Rules) 설정 방식을 선택
프로덕션 모드에서 시작
기본적으로 데이터 접근이 비공개로 설정됩니다.
인증된 사용자만 읽기/쓰기 권한을 가질 수 있으며, 실제 서비스 환경에서 사용하기에 적합합니다.
테스트 모드에서 시작
빠른 개발 및 테스트를 위해 모든 사용자에게 읽기/쓰기 권한을 허용하지만,
30일 후 자동 만료되며, 이후에는 반드시 보안 규칙을 다시 설정해야 합니다.
개발 초기에는 테스트 모드, 실제 배포 시에는 반드시 프로덕션 모드로 변경하는 것이 권장됩니다.
-> 배포를 전제로 한 서비스이므로, 데이터 접근 보안을 유지하기 위해 프로덕션 모드를 선택했습니다.
| 컬렉션 생성하기
자, 이제 데이터베이스를 생성했으니, 관계형 데이터베이스에서 릴레이션 또는 테이블이라고 말하는 '컬렉션'을 생성해보겠습니다.
1) 컬렉션이란?
: 컬렉션(Collection)은 Firestore에서 데이터를 저장하는 가장 기본 단위로, 여러 개의 문서(Document)를 모아놓은 폴더 같은 개념입니다.
예를 들어 users 컬렉션 안에는 각 사용자의 정보를 담은 여러 문서들이 들어가며, 각 문서는 고유한 ID를 가지고 있습니다.
즉, 컬렉션은 관련된 데이터를 구조적으로 묶어 관리하기 위한 “데이터의 그룹”이라고 할 수 있습니다.
2) 생성하는 방법
(1) '컬렉션 시작' 버튼을 클릭합니다.
(2) 컬렉션 ID를 지정한 후 '다음' 버튼을 클릭합니다.
: 예를 들어서, users와 같이 지정 가능합니다.
컬렉션 ID는 데이터를 저장할 그룹의 이름(예: retrospects2)이며, 같은 주제나 성격의 문서들을 묶는 역할을 합니다.
(3) 첫 번째 데이터에 대한 내용을 작성 후 '저장' 버튼을 클릭합니다.
: 컬렉션의 이름을 정하고, 그 안에 첫 번째 데이터를 어떤 구조로 넣을지 결정합니다.
문서 ID는 컬렉션 안에서 각 데이터를 구분하기 위한 고유 식별자입니다.
직접 입력하거나 ‘자동 ID’를 선택해 Firestore가 자동으로 생성하게 할 수 있습니다.
아래의 필드(Field) 영역은 실제로 저장할 데이터의 키(key)와 값(value)을 정의하는 부분으로,
예를 들어 "title": "오늘의 회고"처럼 입력하면 됩니다.
이 단계를 거치면 컬렉션과 새로운 문서를 생성하게 됩니다. 우리의 첫 데이터를 확인할 수 있습니다!
| Firestore의 규칙
1) Firestore이란?
: Firestore의 보안 규칙(Security Rules) 은 사용자가 데이터베이스의 문서(document)나 컬렉션(collection)에 읽기/쓰기 접근을 할 수 있는지를 제어하는 설정입니다.
-> 즉, “누가 데이터를 읽고 쓸 수 있는가?”를 결정하는 데이터 보호 시스템이에요.
service cloud.firestore {
match /databases/{database}/documents {
// 여기에 규칙이 들어감
}
}2) 규칙의 기본 구조
: Firestore의 규칙은 match → allow → 조건 구조로 이루어져 있습니다.
service cloud.firestore {
match /databases/{database}/documents {
match /users/{userId} {
allow read, write: if request.auth != null && request.auth.uid == userId;
}
}
}match /users/{userId} : /users 컬렉션 아래의 모든 문서(userId)를 대상으로 함
allow read, write : 읽기와 쓰기를 허용
if request.auth != null && request.auth.uid == userId : 로그인된 사용자이면서, 자신의 데이터에만 접근 가능
3) 예시로 보기
: Firestore 규칙은 프로젝트 단계(개발용 / 프로덕션용 / 고급형)에 따라 다르게 설정할 수 있습니다.
(1) 개발용 — 테스트 중일 때
: 로그인 기능이 아직 없거나, 개인용 테스트 환경에서 사용하는 경우 모든 사용자에게 CRUD(읽기, 생성, 수정, 삭제) 권한을 허용합니다.
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
// 모든 컬렉션 및 문서 접근 허용
match /{document=**} {
allow read, write: if true;
}
}
}Firestore Console, Svelte 앱, Firebase SDK 등 어디서든 접근 가능
로그인 없이도 데이터 읽기/쓰기 가능
단, 외부 사용자도 접근 가능하므로 실제 배포 전에는 반드시 보안 강화 필요
(2) 프로덕션용 — 로그인 사용자만 허용
: Firebase Authentication(예: Google 로그인)을 사용하는 서비스라면, 로그인된 사용자(request.auth != null) 만 접근하도록 설정합니다.
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
// retrospects 컬렉션 접근 규칙
match /retrospects/{docId} {
allow read, create, update, delete: if request.auth != null;
}
}
}로그인된 사용자만 Firestore에 접근 가능
로그아웃 상태에서는 Firestore CRUD 전부 불가
Firebase SDK에서 로그인하면 자동으로 인증 토큰(request.auth)이 전달됨
(3) 고급형 — 본인 데이터만 수정 가능
: 회고 서비스나 SNS 앱처럼, “본인만 자신의 문서를 수정/삭제 가능” 하게 만들고 싶을 때 사용합니다.
// firestore.ts 예시
addDoc(collection(db, 'retrospects'), {
title,
answers,
userId: auth.currentUser.uid,
createdAt: serverTimestamp(),
});rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
match /retrospects/{docId} {
// 전체 사용자 조회(read)는 허용
allow read: if true;
// 로그인된 사용자만 작성 가능
allow create: if request.auth != null;
// 작성자 본인만 수정 및 삭제 가능
allow update, delete: if request.auth != null
&& request.auth.uid == resource.data.userId;
}
}
}읽기(조회): 모든 사용자 허용
작성(create): 로그인 사용자만 가능
수정/삭제(update, delete): 문서의 userId와 로그인한 uid가 동일할 때만 가능
| 결론
이번 과정을 통해 Firestore가 단순히 데이터를 저장하는 공간이 아니라, 데이터 접근 권한과 보안을 직접 설계해야 하는 서버리스 데이터베이스라는 점을 배웠습니다.
Firestore의 규칙(Security Rules)을 배우면서 “데이터를 잘 저장하는 것”만큼이나 “누가 언제 어떻게 접근할 수 있는지 제어하는 것”이 중요하다는 걸 실감했습니다.
특히 개발 단계에서는 편리함을 위해 테스트 모드를 사용할 수 있지만,배포 단계에서는 반드시 인증 기반 규칙을 설정해야 함을 깨달았습니다.
즉, Firestore는 단순한 NoSQL 데이터베이스가 아니라,
보안 정책과 구조 설계를 함께 고민해야 하는 완성형 데이터 관리 플랫폼이었습니다.
앞으로는 데이터베이스를 설계할 때, 기능뿐 아니라 보안 흐름까지 함께 고려하는 습관을 들이려 합니다.