Firestore 매핑으로 프로덕트 신경망 구축 ✦ 노코드 DB #4

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

 

지난 글에서 우리는 정적 데이터(Static Data)로 ‘세계관’을 만들고, 동적 데이터(Dynamic Data)로 ‘사용자의 흔적’을 설계했습니다. 이제 두 세계가 실제로 앱 안에서 살아 움직이기 위해서는 Firestore 구조 설계가 필요합니다.

 

Firestore은 프로덕트의 신경망

 

엑셀 시트에서 만든 표는 ‘설계도’일 뿐이고, Firestore는 그 설계도가 프로덕트의 신경망으로 연결되는 순간입니다.  Firestore는 단순한 DB가 아니라, 노코드 프로덕트의 신경망인 것이죠.

 

 

 

1/ Firestore 매핑의 핵심은 “엑셀 → 구조”

디자이너는 보통 엑셀이나 구글 시트에서 데이터를 정리합니다. 하지만 Firestore는 시트처럼 2차원 구조가 아니라 계층적(Hierarchical) 구조입니다. 

즉, Firestore로 옮기기 위해서는 아래 기본 규칙을 이해하고, 그 위에 관계(Reference) 설계가 필요합니다.

• 행(Row) = 문서(Document)
• 열(Column) = 필드(Field)

 

⭐ Firestore로 옮기는 가장 단순한 매핑 규칙

엑셀	Firestore
시트(Sheet)	collection
행(Row)	document
열(Column)	field
반복되는 값	subcollection

이 규칙만 이해하면, 디자이너도 Firestore 전체 구조를 짤 수 있습니다.

 

 

 

2/ 필드 타입 매핑: FF ↔ Firebase에서 특히 주의할 항목들

Firestore는 “유연하지만, 엄격한 DB”입니다. 특히, FlutterFlow와 함께 사용할 때 타입 불일치는 가장 흔한 문제입니다.

아래는 실전에서 가장 자주 발생하는 오류들입니다.

 

📌 Array (리스트) — 세미콜론(;)로 구분시키는 이유

coffee;bakery;convenience

엑셀은 배열이라는 개념이 없습니다. 따라서 아래처럼 하나의 셀에 값을 합쳐야 합니다.

그러면 FlutterFlow의 Content Manager나 CSV importer가 자동으로 Array 타입으로 변환합니다.

 

📌 Boolean — true/false만 가능 (대문자 X)

TRUE ×
True ×
true ○

디자이너가 가장 많이 실수하는 타입 1위!

Boolean은 소문자! 기억합시다.

 

📌 Null 값 — 비워두어야 진짜 null

"-"
"null"
"없음"

모두 문자열로 취급됩니다.

진짜 null로 넣으려면 셀을 비워야 합니다.

 

📌 Timestamp — 날짜만 넣어도 자동 인식됨

2025-11-28
2025-11-28 23:00:00

둘 다 Timestamp로 변환됩니다.

디자이너가 직접 포맷팅할 필요 없습니다.

 

 

 

3/ Firestore 구조 설계: “프로덕트 신경망”을 만드는 단계

Firestore는 단순히 데이터를 저장하는 장소가 아니라 전역 State, 페이지, 사용자 행동을 연결하는 ‘프로덕트 신경망’의 중심입니다. 따라서 Firestore 구조는 아래 3단계로 설계하는 것을 추천합니다.

 

3-1. Global Collections (앱 전체가 참조하는 데이터)

category_master
card_master
emotion_master
score_logic
settings

→ 모든 사용자에게 동일하게 적용되는 정적 데이터(Static) 저장소

 

3-2. User Root Collections (사용자별 루트)

users/{uid}

예시
users/{uid}/cards/{card_id}
users/{uid}/history/{log_id}
users/{uid}/requests/{req_id}

→ 기본 사용자 정보 + 커스텀 데이터를 저장

 

3-3. Mixed Collections (전역 + 사용자 기반 데이터 혼합)

search_log
action_log
recommend_snapshot

→ 많은 데이터가 생기지만, 사용자별로 분리하는 것보다 제3자 분석 도구와 연동하기 쉬운 구조

 

 

 

4/ ID 설계 철학: LOG_ / REQ_ / ACT_ 를 왜 쓰는가

Firestore에서 Document ID는 단순히 “식별자”가 아닙니다. 데이터를 찾아가기 위한 네비게이션 키입니다.

그래서 Document ID는 짧고 명확해야 합니다.

LOG_20251120_001
REQ_20251120_CARD
ACT_CLICK_FILTER_M

 

이런 명명 규칙은 다음을 가능하게 합니다:

• 검색 속도 향상
• 개발 중 디버깅 속도 증가
• 비개발자의 데이터 파악 속도 증가
• 도구 간 일관성 유지 (엑셀 ⇄ FF ⇄ Firebase)

 

 

 

5/ Subcollection 구조 예시: Firestore가 좋은 이유

디자이너가 Firestore를 이해하는 순간 가장 감탄하는 개념이 Subcollection입니다.

users/{uid}/cards/{card_id}
users/{uid}/requests/{req_id}
users/{uid}/history/{log_id}

 

 

사용자별 카드, 히스토리, 요청을 “자동 폴더 구조”처럼 정리해 줍니다.

이는 곧:

• 사용자별 데이터 분리
• 분석 단위 확실
• 관계 구조 명확
• 확장성 매우 높음

정적·동적 데이터가 Firestore 안에서 ‘한 눈에 보이는 형태’로 정리됩니다.

 

 

 

✦ 디자이너를 위한 요약

정적 데이터가 세계관을 만들었다면,
Firestore는 그 세계를 살아 움직이게 하는 신경망이다.

 

 

 

다음 글

✦ 비개발자를 위한 노코드 DB 설계

├ 1 ✦ DB 설계는 UX 설계의 뒷면이다 완료

├ 2 ✦ 정적 데이터는 제품의 룰북이다 완료

├ 3 ✦ 동적 데이터로 사용자의 흔적을 설계하다 완료

├ 4 ✦ Firestore 매핑으로 프로덕트 신경망 구축 완료

└ 5 ✦ 디자이너가 데이터로 말하는 법

 

다음 글에서는 Firestore에 쌓인 데이터를 어떻게 “디자인 언어”로 설명할 것인지, 디자이너가 데이터를 읽는 법, 숫자를 이야기로 바꾸는 법, 스키마 중심의 사고로 UX 개선하는 법, 로그/히스토리를 “설계 근거”로 변환하는 법을 다룹니다 ✦

디자이너가 데이터로 말하는 법 ✦ 노코드 DB #5