설계·타입·관계·보안규칙 기본 개념 ✦ Firestore 셋업 #1

안녕하세요! ARCOA 지안입니다. 👋 

Firebase 셋업을 끝내고 Firestore를 열면, 이런 생각이 떠오를 수 있어요.

 

“이제 뭘 만들어야 하지?”

 

Firestore는 UI가 눈에 보이지 않아서 더 막막할 수 있어요.

실습은 생각보다 쉽습니다. 정말 어려운 건 개발적인 개념이 없어서 혼란스럽다는 것이예요. 
그래서 본격적으로 데이터를 넣기 전에, Firestore에 핵심 설계 개념 6가지를 정리했습니다. 이 글을 읽어두면 다음 실습(#2~#5)을 훨씬 편하게 진행할 수 있어요.

 

 

 

1/ Static과 Dynamic 데이터 구분

데이터 설계의 첫 번째 기준은 ‘변하는가, 변하지 않는가’입니다.

꼭 구분하고 기억해야 합니다.

 

Static Data

• 잘 안 바뀌는 데이터
• 예) 카테고리, 등급/레벨, 안내문 등

 

Dynamic Data

• 사용자의 행동으로 계속 쌓이는 데이터
• 예) 회원정보, 로그, 기록 등

이 구분만 정확하게 하면 컬렉션 구조, 관계, 보안 규칙까지 모두 정리가 됩니다.

 

 

 

2/ 필드 타입: Firestore 기준으로 정리

엑셀 기준으로 만들면 Firestore에서 충돌이 자주 나요.
그래서 업로드 전에 타입을 Firestore 기준으로 정리해야 합니다.

 

Firestore 핵심 타입

• string (텍스트)
• number (정수/실수)
• boolean (true/false)
• array (리스트)
• timestamp (날짜/시간)
• map (JSON 구조)
• null (빈 값)
• reference (문서 연결)

✔ 체크 포인트

• 숫자는 텍스트가 아니라 number
• 빈 셀은 “-” 대신 null
• 날짜는 string이 아니라 timestamp
• 리스트는 array
• 깊은 구조는 map(JSON)

TIP 자주하는 실수: (예) 숫자 25 입력

❌ "25" 
→ Firestore에서 string(텍스트)으로 인식
→ 검색/필터링 시 오류 발생

⭕ 25
→ Firestore에서 number(정수)로 인식
→ 정상적으로 비교·정렬 가능

 

 

 

3/ 관계 설계: Reference과 Subcollection

데이터 간 관계는 Firestore에서 딱 두 가지입니다.

 

Reference (문서 → 문서 링크)

/user_requests/{req_id}
  ├─ user_id → /users/{uid}  (링크)
  ├─ card_id → /card_master/{card_id}  (링크)
  └─ situation: "점심 메뉴 고민"

→ A가 B를 가리키는 링크

→ 가볍고 단순, UI에서 join 느낌으로 활용 가능

 

Subcollection (문서 안에 또 다른 컬렉션)

/users/{uid}
  └─ /requests/{req_id}
      ├─ card_id → /card_master/{card_id}
      └─ situation: "점심 메뉴 고민"

→ 문서 안쪽에 있는 작은 데이터베이스

→ 사용자 단위로 기록 쌓는 구조에 알맞음, 무한 확장성, 권한 제어 편함

 

TIP 선택 기준
“특정 유저 아래에 쌓이는 데이터인가?” → Subcollection
“독립적으로 존재하는 데이터인가?” → Reference

 

 

 

4/ seed 데이터: 초기 데이터 준비

⚠️ Firestore는 “화면 먼저 만들고 나중에 데이터 넣기”가 잘 안 돼요.

그래서 Static Data는 미리 ‘조금이라도’ 넣어두는 게 좋아요.

 

Static Data는 반드시 먼저 업로드

→ Static이 없으면 Dynamic 구조도 테스트 불가

→ UI 연결 테스트도 어려움

→ OOO_master라는 이름으로 만들어지는 기본 데이터

 

ID 규칙 정하기

→ 일정한 규칙 기반 ID는 Firestore 검색 효율 향상

 

 

 

5/ 보안 규칙 

보안 규칙은 Firestore에서 가장 많이 막히는 구간이지만, 이제는 내장된 Gemini를 이용하여 쉽게 만들 수 있습니다.

 

핵심 개념

• 누가 읽을 수 있나? (read)
• 누가 쓸 수 있나? (write)
• 어떤 조건에서? (if문)

예를 들어 이렇게 말하면 됩니다: "로그인한 사용자만 자기 데이터를 읽고 쓸 수 있게 해줘"

자세한 실습은 #4에서 함께 만들어보겠습니다.

rules_version = '2';
service cloud.firestore {
  match /databases/{db}/documents {

    // users
    match /users/{uid} {
      allow read, write: if request.auth != null
                         && request.auth.uid == uid;
    }

    // master data (static)
    match /category_master/{doc} {
      allow read: if true;
      allow write: if false;
    }
  }
}

 

 

 

6/ 데이터 업로드

Firestore에 데이터를 넣는 방법은 3개가 있습니다.

방법	난이도	특징
Firebase Console	쉬움	소량 테스트용
Firebase Extensions (csv import)	어려움	대량 데이터 자동화
FlutterFlow Content Manager ⭐	가장 쉬움	CSV → 즉시 업로드

노코드 개발을 베이스로 하기 때문에 실습은 가장 쉬운  FlutterFlow의 Content Manager 방법으로 진행할 예정입니다.

 

 

 

✅ Firestore 준비 체크리스트

[  ] Static / Dynamic 데이터를 구분한다

[  ] 내 서비스에 필요한 필드 타입을 파악했다

[  ] Reference / Subcollection의 차이를 안다

[  ] seed 데이터(초기 데이터)를 준비했다

[  ] 데이터 ID 규칙을 정했다

[  ] 보안 규칙이 필요한 것을 안다

[  ] 데이터 업로드 방법은 3개가 있다

 

 

 

디자이너를 위한 요약

Firestore는 데이터의 정보 설계(IA)다.
어떻게 연결하고 나눌지가 곧 성능과 UX를 결정한다.

 

 

 

다음 글

✦ 디자이너(비개발자)를 위한 Firestore 셋업

├ 1 ✦ 설계·타입·관계·보안규칙 기본 개념 완료

├ 2 ✦ Database 만들기와 버전/위치/모드 선택

├ 3 ✦ 첫 데이터 넣기: Static 컬렉션 실습

├ 4 ✦ DB의 문지기, 보안 규칙 작성
└ 5 ✦ 한 번에 채우는 데이터 + FlutterFlow 활용

 

다음 글은 NoSQL 개념부터 실제 Firestore 첫 데이터베이스 생성까지, 실제로 앱이 숨을 쉬기 시작하는 순간을 함께 만들어봅니다 ✦

Database 만들기와 버전/위치/모드 선택 ✦ Firestore 셋업 #2