Firestore on monkshark.dev

#9 - 1:1 채팅, 실시간의 무게

Mon, 13 Apr 2026 00:00:00 +0000

채팅이 필요한 이유

게시판만으로는 부족한 순간이 있다. 분실물 게시판에서 “제 카드키 찾으신 분 연락주세요"라고 올리면, 찾은 사람이 연락할 방법이 없다. 댓글로 개인 정보를 주고받을 수도 없고. 1:1 채팅이 필요해진 순간이다.

채팅방 ID: 정렬의 힘

A가 B에게 채팅을 걸든, B가 A에게 걸든 같은 채팅방이어야 한다. 중복 채팅방이 생기면 대화가 갈린다.

1
2
3
4


String _getChatId(String uid1, String uid2) {
 final sorted = [uid1, uid2]..sort();
 return '${sorted[0]}_${sorted[1]}';
}

두 uid를 알파벳 순서로 정렬하고 _로 연결한다. abc123과 xyz789의 조합은 항상 abc123_xyz789가 된다. 누가 먼저 시작했는지와 관계없이 같은 ID.

채팅방을 생성할 때는 이 ID로 문서가 이미 있는지 확인하고, 없으면 만든다:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


Future<void> startChat(String otherUid, String otherName) async {
 final chatId = _getChatId(myUid, otherUid);
 final doc = await FirebaseFirestore.instance.collection('chats').doc(chatId).get();

 if (!doc.exists) {
 await FirebaseFirestore.instance.collection('chats').doc(chatId).set({
 'participants': [myUid, otherUid],
 'participantNames': {myUid: myName, otherUid: otherName},
 'lastMessage': '',
 'lastMessageAt': FieldValue.serverTimestamp(),
 'unreadCount': {myUid: 0, otherUid: 0},
 });
 }

 // 채팅방 화면으로 이동
}

메시지 전송

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


Future<void> _sendMessage() async {
 final text = _controller.text.trim();
 if (text.isEmpty) return;
 _controller.clear();

 await FirebaseFirestore.instance
 .collection('chats').doc(chatId)
 .collection('messages').add({
 'content': text,
 'senderUid': myUid,
 'senderName': myName,
 'createdAt': FieldValue.serverTimestamp(),
 'deletedFor': [],
 });

 await FirebaseFirestore.instance.collection('chats').doc(chatId).update({
 'lastMessage': text,
 'lastMessageAt': FieldValue.serverTimestamp(),
 'unreadCount.${widget.otherUid}': FieldValue.increment(1),
 });
}

메시지를 보내면 두 가지 업데이트가 일어난다:

messages 서브컬렉션에 메시지 문서 추가
부모 chats 문서의 lastMessage, lastMessageAt, 상대방의 unreadCount 업데이트

unreadCount.${widget.otherUid} — dot notation으로 상대방의 읽지 않은 메시지 수만 증가시킨다. 내 카운트는 건드리지 않는다.

입력 필드를 먼저 비우고(_controller.clear()) 나서 네트워크 요청을 보낸다. 전송이 완료될 때까지 입력 필드가 남아있으면 사용자가 답답해하니까.

이미지 전송

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


Future<void> _sendImage() async {
 final picked = await ImagePicker().pickImage(source: ImageSource.gallery, imageQuality: 85);
 if (picked == null) return;

 // 압축
 final compressed = await FlutterImageCompress.compressWithFile(
 picked.path, quality: 80, minWidth: 1280, minHeight: 1280,
 );

 // Firebase Storage 업로드
 final path = 'chats/$chatId/${DateTime.now().millisecondsSinceEpoch}_$myUid.jpg';
 final ref = FirebaseStorage.instance.ref(path);
 await ref.putData(compressed);
 final url = await ref.getDownloadURL();

 // 이미지 URL을 메시지로 전송
 await _addMessage(imageUrl: url);
}

이미지는 선택 → 압축 → Storage 업로드 → URL을 메시지에 저장하는 순서다. 원본 대신 1280px, 80% 품질로 압축하여 용량을 줄인다. 채팅방마다 Storage 경로를 분리해서 정리도 쉽다.

“나만 삭제"와 “모두에게서 삭제”

카카오톡처럼 두 가지 삭제 옵션이 있다.

나만 삭제

1
2
3
4
5
6
7
8


Future<void> _deleteForMe(String messageId) async {
 await FirebaseFirestore.instance
 .collection('chats').doc(chatId)
 .collection('messages').doc(messageId)
 .update({
 'deletedFor': FieldValue.arrayUnion([myUid]),
 });
}

메시지를 실제로 삭제하지 않고, deletedFor 배열에 내 uid를 추가한다. 메시지를 표시할 때 이 배열을 확인:

1
2


final deletedFor = List<String>.from(data['deletedFor'] ?? []);
if (deletedFor.contains(uid)) return const SizedBox.shrink();

내 uid가 deletedFor에 있으면 렌더링하지 않는다. 상대방에게는 여전히 보인다.

모두에게서 삭제

1
2
3
4
5
6
7
8
9


Future<void> _deleteForAll(String messageId) async {
 await FirebaseFirestore.instance
 .collection('chats').doc(chatId)
 .collection('messages').doc(messageId)
 .update({
 'deleted': true,
 'content': AppLocalizations.of(context)!.chat_deletedMessage,
 });
}

deleted: true로 표시하고 내용을 “삭제된 메시지"로 바꾼다. 양쪽 모두에게 “삭제된 메시지"가 보인다.

단, 조건이 있다: 보낸 지 1시간 이내이고 상대방이 아직 읽지 않았을 때만 가능하다.

1

canDeleteForAll = isWithinOneHour && (otherUnread > 0);

이미 읽은 메시지를 삭제하는 건 의미가 없으니까.

읽음 표시

unreadCount를 활용하여 읽음 표시를 구현한다.

채팅방에 들어가면 내 unreadCount를 0으로 초기화:

1
2
3
4
5
6
7


@override
void initState() {
 super.initState();
 FirebaseFirestore.instance.collection('chats').doc(chatId).update({
 'unreadCount.$myUid': 0,
 });
}

메시지 옆에 “읽음” 표시를 보여주는 로직은 상대방의 unreadCount를 역산하는 방식이다. 상대방이 3개를 안 읽었으면, 내가 보낸 최근 3개 메시지에는 “읽음"이 표시되지 않고 나머지에는 표시된다.

채팅 목록

1
2
3
4
5


FirebaseFirestore.instance
 .collection('chats')
 .where('participants', arrayContains: myUid)
 .orderBy('lastMessageAt', descending: true)
 .snapshots()

내가 참여한 채팅방을 최근 메시지 순으로 실시간 스트리밍한다. 새 메시지가 오면 목록이 자동으로 재정렬된다.

각 채팅방 아이템에는 상대 이름, 마지막 메시지, 시간, 읽지 않은 메시지 수가 표시된다. 읽지 않은 메시지가 있으면 빨간 뱃지가 뜬다.

채팅방 나가기

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


Future<void> _leaveChat() async {
 // 시스템 메시지 추가
 await messagesRef.add({
 'type': 'system',
 'content': '$myName님이 나갔습니다',
 'createdAt': FieldValue.serverTimestamp(),
 });

 // 참가자 목록에서 제거
 await chatRef.update({
 'participants': FieldValue.arrayRemove([myUid]),
 'lastMessage': '$myName님이 나갔습니다',
 });
}

채팅방을 나가면 시스템 메시지를 남기고 참가자 목록에서 제거된다. 상대방에게는 “○○님이 나갔습니다"가 표시된다.

돌아보면

채팅의 핵심은 “실시간"이라기보다 “상태 동기화"였다. 읽음/안읽음, 삭제됨/안삭제됨, 참가 중/나감 — 양쪽의 상태가 항상 일치해야 한다. Firestore의 실시간 스트리밍이 이 동기화를 거의 공짜로 해주지만, 구조를 잘 잡아야 그 혜택을 받을 수 있다.

uid 정렬로 채팅방 ID를 만드는 건 작은 결정이지만, 이 한 줄이 “중복 채팅방” 문제를 원천 차단했다. 작은 결정이 큰 버그를 예방하는 경험이었다.

#8 - 익명 게시판, 생각보다 복잡한 '익명'

Sun, 12 Apr 2026 00:00:00 +0000

“익명"이면 그냥 이름 숨기면 되는 거 아닌가

처음에는 그렇게 생각했다. isAnonymous: true면 이름 대신 “익명"을 표시하면 끝. 하지만 실제로 만들어보니 익명 게시판에는 생각보다 많은 설계 결정이 필요했다.

익명 번호: “익명1"과 “익명2"는 같은 사람인가

익명 게시판에서 댓글이 달리면 이런 상황이 생긴다:

1
2
3
4


익명 — 오늘 급식 맛있었나요?
 └ 익명 — 네 괜찮았어요
 └ 익명 — 별로였는데
 └ 익명 — 저도 괜찮았어요

“괜찮았어요"를 쓴 첫 번째 사람과 세 번째 사람이 같은 사람인지 알 수 없다. 대화 맥락이 끊긴다. 에브리타임 같은 서비스에서는 이걸 익명 번호로 해결한다: “익명1”, “익명2"처럼.

1
2
3
4


익명 — 오늘 급식 맛있었나요?
 └ 익명1 — 네 괜찮았어요
 └ 익명2 — 별로였는데
 └ 익명1 — 저도 괜찮았어요

이제 “익명1"이 같은 사람이라는 걸 알 수 있다.

anonymousMapping

이 기능을 구현하려면 “이 게시글에서 이 사용자가 몇 번 익명인지"를 추적해야 한다. Firestore 문서에 anonymousMapping과 anonymousCount 필드를 뒀다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31


Future<String> resolveAnonymousName(
 String postId, String uid,
 String authorLabel,
 String Function(int) anonymousNumLabel,
) async {
 final ref = postRef(postId);
 final postSnap = await ref.get();
 final postAuthorUid = postSnap.data()?['authorUid'];

 // 글 작성자는 "작성자"로 표시
 if (uid == postAuthorUid) return authorLabel;

 return _db.runTransaction<String>((transaction) async {
 final postDoc = await transaction.get(ref);
 final data = postDoc.data() ?? {};
 final mapping = Map<String, dynamic>.from(data['anonymousMapping'] ?? {});
 final count = (data['anonymousCount'] as int?) ?? 0;

 if (mapping.containsKey(uid)) {
 return anonymousNumLabel(mapping[uid]); // 기존 번호 반환
 } else {
 final newNum = count + 1;
 mapping[uid] = newNum;
 transaction.update(ref, {
 'anonymousMapping': mapping,
 'anonymousCount': newNum,
 });
 return anonymousNumLabel(newNum); // 새 번호 부여
 }
 });
}

Firestore 트랜잭션을 쓰는 이유는 동시성 문제 때문이다. 두 사람이 동시에 댓글을 달면 같은 번호를 받을 수 있다. 트랜잭션으로 읽기-확인-쓰기를 원자적으로 처리해야 번호가 중복되지 않는다.

글 작성자는 “익명1"이 아니라 “작성자"로 표시된다. 자기 글의 댓글에서 글쓴이를 구분할 수 있어야 하니까.

댓글 렌더링

댓글을 화면에 표시할 때는 anonymousMapping을 미리 로드해두고, 각 댓글의 authorUid로 번호를 조회한다:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


if (c['isAnonymous'] == true && c['authorUid'] != null) {
 final uid = c['authorUid'] as String;
 if (uid == _currentPostAuthorUid) {
 c['authorName'] = AppLocalizations.of(context)!.post_anonymousAuthor;
 } else if (_anonymousMapping.containsKey(uid)) {
 c['authorName'] = AppLocalizations.of(context)!.post_anonymousNum(
 _anonymousMapping[uid]
 );
 }
}

i18n도 적용되어 있다. 한국어에서는 “익명1”, 영어에서는 “Anonymous 1”.

좋아요: 배열에서 Map으로

처음: 배열

1

likes: ["uid1", "uid2", "uid3"]

단순하다. arrayContains로 내가 좋아요를 눌렀는지 확인하고, arrayUnion/arrayRemove로 추가/삭제. 하지만 문제가 있었다:

두 명이 동시에 좋아요를 누르면 한쪽이 씹힐 수 있다
“인기글” 정렬을 하려면 배열 크기로 정렬해야 하는데, Firestore에서는 배열 크기 기준 정렬이 불가능하다

지금: Map + 비정규화 카운터

1
2


likes: {"uid1": true, "uid2": true}
likeCount: 2

Map으로 바꾸면서 동시 업데이트 문제가 해결되었다. 각 uid가 독립적인 필드이기 때문에, 두 사람이 동시에 눌러도 충돌하지 않는다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


Future<void> toggleLike(String postId, String uid, {
 required bool hasLiked,
 required bool hasDisliked,
}) async {
 if (hasLiked) {
 await postRef(postId).update({
 'likes.$uid': FieldValue.delete(),
 'likeCount': FieldValue.increment(-1),
 });
 } else {
 final updates = <String, dynamic>{
 'likes.$uid': true,
 'likeCount': FieldValue.increment(1),
 };
 if (hasDisliked) {
 updates['dislikes.$uid'] = FieldValue.delete();
 updates['dislikeCount'] = FieldValue.increment(-1);
 }
 await postRef(postId).update(updates);
 }
}

likes.$uid — Firestore의 dot notation으로 Map의 특정 키만 업데이트한다. FieldValue.increment(-1)로 카운터를 원자적으로 감소시킨다. 좋아요를 누르면서 동시에 싫어요를 취소하는 것도 한 번의 업데이트로 처리한다.

likeCount는 비정규화된 필드다. likes Map의 크기와 항상 같아야 한다. 이걸 별도로 유지하는 이유는 오직 정렬 때문이다. “인기글” 탭에서 likeCount 내림차순으로 정렬하려면 이 필드가 필요하다.

검색: Firestore에서 “급식"을 찾으려면

Firestore에는 LIKE '%급식%' 같은 전문 검색이 없다. 공식적으로는 Algolia나 Typesense 같은 외부 검색 엔진을 붙이라고 권장한다. 하지만 학생 프로젝트에서 외부 서비스 비용과 관리 부담은 크다.

n-gram 토큰

대안으로 2-gram 토큰 방식을 썼다. 게시글을 저장할 때 제목과 내용에서 2글자 단위로 토큰을 추출한다:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


static List<String> forDocument(String title, String content, {int maxTokens = 200}) {
 final combined = '$title $content';
 final tokens = _ngrams(combined);
 if (tokens.length <= maxTokens) return tokens.toList();
 return tokens.take(maxTokens).toList();
}

static Set<String> _ngrams(String text) {
 final cleaned = _normalize(text);
 final out = <String>{};
 for (int i = 0; i + 2 <= cleaned.length; i++) {
 out.add(cleaned.substring(i, i + 2));
 }
 return out;
}

“오늘 급식 맛있었다” → ["오늘", "늘급", "급식", "식맛", "맛있", "있었", "었다"]

정규화 과정에서 특수문자와 공백을 제거하고, 영어는 소문자로 통일한다. 한글, 영어, 숫자만 남긴다.

검색 시에는 쿼리도 같은 방식으로 토큰화한 후 arrayContainsAny로 Firestore에 쿼리한다:

1
2
3
4
5
6


static List<String> forQuery(String query, {int maxTokens = 10}) {
 final cleaned = _normalize(query);
 if (cleaned.length == 1) return [cleaned];
 final tokens = _ngrams(query);
 return tokens.take(maxTokens).toList();
}

완벽한 검색은 아니다. “급"만 검색하면 2-gram이 안 만들어지므로 1글자 검색은 정확도가 떨어진다. 문서당 토큰은 200개로 제한하여 Firestore 문서 크기가 과도하게 커지는 걸 방지한다. 하지만 학교 게시판에서 “급식”, “시간표”, “동아리” 같은 2글자 이상 키워드 검색에는 잘 동작한다.

카테고리 시스템

게시판은 6개 카테고리로 나뉜다:

카테고리	FCM 토픽	색상
자유	free	기본
질문	question	보조
정보공유	info	3차
분실물	lost	주황
학생회	council	초록
동아리	club	보라

여기에 “전체"와 “인기글” 탭이 추가된다. “전체"는 모든 카테고리를 보여주고, “인기글"은 likeCount 기준으로 정렬한다.

FCM 토픽은 카테고리별 알림 구독을 위해 영어 키로 매핑한다. 사용자가 “자유” 카테고리만 구독하면 해당 토픽의 알림만 받는다.

추가 기능들

북마크: bookmarkedBy 배열에 uid를 넣어서 내가 북마크한 글을 모아볼 수 있다
고정글: isPinned과 pinnedAt으로 관리자가 글을 상단 고정
투표: pollOptions와 pollVoters로 글 안에서 투표 가능. pollVoters는 {uid: optionIndex} Map
이미지: imageUrls 배열로 다중 이미지 첨부. Firebase Storage에 업로드 후 URL 저장
해결됨: 질문 카테고리에서 isResolved로 해결된 질문 표시

돌아보면

익명 게시판은 “이름을 숨긴다"가 아니라 “이름을 숨기면서도 대화 맥락을 유지한다"가 핵심이었다. anonymousMapping 하나를 추가하는 것이 사소해 보이지만, 트랜잭션으로 동시성을 처리하고, 글 작성자를 별도로 표시하고, i18n을 적용하는 과정이 필요했다.

좋아요도 검색도 마찬가지다. Firestore의 제약 안에서 “그럴듯하게 동작하는” 것을 만드는 게 NoSQL 설계의 핵심인 것 같다.

#7 - Firestore 스키마, 처음부터 다시 설계한다면

Sat, 11 Apr 2026 00:00:00 +0000

학교 앱에 Firestore가 필요한 이유

급식과 시간표는 NEIS API로 충분하다. 하지만 학교 앱이 단순 정보 조회를 넘어서려면 — 게시판, 채팅, 사용자 인증 — 자체 데이터베이스가 필요하다.

Firebase의 Firestore를 선택한 이유는 단순했다. 서버를 직접 운영할 필요가 없고, 실시간 동기화가 기본이고, Flutter와의 통합이 잘 되어 있다. 무엇보다 학생 혼자 운영하는 앱에서 서버 관리까지 할 여유는 없었다.

현재 앱에는 8개의 Firestore 컬렉션이 있다. 각각의 구조와 설계 과정에서 배운 것들을 정리한다.

users: 사용자 프로필

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


users/{uid}
├── uid, name, email
├── studentId, grade, classNum
├── role: "user" | "manager" | "admin"
├── userType: "student" | "graduate" | "teacher" | "parent"
├── approved: true/false
├── blockedUsers: [uid, uid, ...]
├── fcmToken: "..."
├── profilePhotoUrl, graduationYear, teacherSubject
├── lastProfileUpdate, updatedAt
│
├── /sync/schedules → 개인 시간표
├── /sync/ddays → D-day 목록
└── /notifications → 알림 내역

role 필드가 3단계(user, manager, admin)인 건 나중에 추가한 것이다. 처음에는 isAdmin: true/false로 시작했다가, 학생회 임원에게 일부 권한만 주고 싶어서 manager 역할을 중간에 넣었다.

approved 필드는 가입 승인 시스템이다. 아무나 학교 앱에 글을 쓸 수 없도록, 가입 후 관리자가 승인해야 게시판 접근이 가능하다. 학교 앱이라는 특성상 필수적인 기능이었다.

blockedUsers 배열은 사용자 차단 기능이다. 차단한 사용자의 게시글과 댓글이 보이지 않는다. 이걸 서버 쿼리로 처리하면 Firestore not-in 쿼리 제한(10개)에 걸리기 때문에, 클라이언트에서 필터링한다.

서브컬렉션: sync

users/{uid}/sync/schedules와 users/{uid}/sync/ddays는 개인 데이터의 기기 간 동기화를 위한 구조다. 로컬 SQLite에 저장하되, Firestore에도 백업하여 기기를 바꿔도 데이터가 유지된다.

처음에는 Firestore만 사용했다. 하지만 시간표를 볼 때마다 네트워크 요청이 발생하는 게 급식 API와 같은 문제였다. 결국 로컬 SQLite + Firestore 동기화 구조로 바꿨다.

posts: 게시판

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


posts/{postId}
├── title, content, authorUid, authorName
├── category: "자유" | "질문" | "정보공유" | "분실물" | "학생회" | "동아리"
├── isAnonymous, isPinned, isResolved
├── likes: {uid: true, uid: true, ...}
├── dislikes: {uid: true, uid: true, ...}
├── likeCount, dislikeCount ← 비정규화된 카운터
├── commentCount
├── bookmarkedBy: [uid, uid, ...]
├── searchTokens: ["급식", "식메", "메뉴", ...] ← n-gram
├── pollOptions, pollVoters
├── imageUrls: [...]
├── createdAt, pinnedAt
│
└── /comments/{commentId}
 ├── content, authorUid, authorName
 ├── isAnonymous, likes, dislikes
 ├── imageUrl, mentions
 └── createdAt

이 컬렉션에서 가장 많이 고민한 것이 좋아요 구조다.

좋아요: 배열 vs Map

처음에는 likes: [uid1, uid2, uid3] 배열이었다. 누가 좋아요를 눌렀는지 확인하려면 arrayContains로 쿼리하면 된다. 하지만 문제가 있었다:

좋아요/취소가 동시에 발생하면 배열이 꼬일 수 있다
Firestore의 arrayUnion/arrayRemove가 있지만, 트랜잭션 없이는 race condition에 취약하다

Map 구조(likes: {uid: true})로 바꾸면서 해결했다. 특정 uid의 좋아요 여부를 확인하는 것도, 추가/삭제하는 것도 간단하다.

likeCount: 비정규화의 필요성

“인기글” 정렬이 필요했다. Firestore에서 Map의 크기로 정렬하는 건 불가능하다. likes Map의 키 개수를 실시간으로 세는 것도 비효율적이다.

결국 likeCount, dislikeCount 필드를 별도로 두고, 좋아요를 누를 때마다 트랜잭션으로 함께 업데이트한다. NoSQL에서는 이런 비정규화가 일상이다. RDB의 COUNT(*) 대신 미리 계산해두는 것.

검색: n-gram 토큰

Firestore는 전문 검색(full-text search)을 지원하지 않는다. “급식 메뉴"를 검색하려면 별도 검색 엔진(Algolia, Typesense 등)이 필요한데, 학생 프로젝트에서 외부 서비스를 붙이기는 부담스러웠다.

대안으로 n-gram 토큰을 사용했다. 게시글을 저장할 때 제목과 내용에서 2글자 단위로 토큰을 추출하여 searchTokens 배열에 저장한다.

1

"급식 메뉴 변경" → ["급식", "식 ", " 메", "메뉴", "뉴 ", " 변", "변경"]

검색 시 arrayContainsAny로 쿼리한다. 완벽한 전문 검색은 아니지만, 학교 게시판 규모에서는 충분히 동작한다.

익명 게시판

isAnonymous 필드와 함께 anonymousMapping, anonymousCount가 있다. 같은 게시글에 같은 익명 사용자가 여러 댓글을 달면 “익명1”, “익명1"로 일관되게 표시해야 한다. anonymousMapping은 {uid: 1, uid: 2} 형태로 익명 번호를 추적한다.

chats: 1:1 채팅

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


chats/{chatId} ← chatId = 정렬된 두 uid 조합
├── participants: [uid, uid]
├── participantNames: {uid: "이름", uid: "이름"}
├── lastMessage, lastMessageAt
├── unreadCount: {uid: 3, uid: 0}
│
└── /messages/{messageId}
 ├── type: "text" | "system"
 ├── content, imageUrl
 ├── senderUid, senderName
 ├── deletedFor: [uid, ...]
 └── createdAt

chatId를 두 사용자의 uid를 정렬하여 합친 값으로 쓴다. A와 B의 채팅방은 항상 같은 ID를 가지므로, 중복 채팅방이 생기지 않는다.

unreadCount를 Map으로 관리하는 것은 각 사용자가 읽지 않은 메시지 수를 독립적으로 추적하기 위해서다. A가 메시지를 보내면 B의 카운트가 올라가고, B가 채팅방을 열면 B의 카운트가 0으로 초기화된다.

deletedFor 배열은 “나만 삭제” 기능이다. 메시지를 실제로 삭제하지 않고, 삭제를 요청한 사용자의 uid를 배열에 추가한다. 클라이언트에서 자신의 uid가 deletedFor에 있으면 해당 메시지를 표시하지 않는다.

나머지 컬렉션들

reports — 신고

게시글 신고 시 postId, reporterUid, reason, detail을 저장한다. 관리자 화면에서 목록을 보고 조치한다.

admin_logs — 관리 기록

사용자 정지, 게시글 삭제 등 관리자 행동을 기록한다. action, targetUid, details, timestamp. 누가 무엇을 했는지 추적할 수 있어야 관리자가 여러 명이어도 문제를 파악할 수 있다.

app_feedbacks / council_feedbacks — 피드백

사용자가 앱이나 학생회에 보내는 피드백. content, imageUrls, status(pending/addressed). 이미지 첨부가 가능하고, 처리 상태를 관리자가 업데이트한다.

crash_logs — 오류 기록

1
2
3
4
5
6
7
8
9


// main.dart
FlutterError.onError = (details) {
 FirebaseFirestore.instance.collection('crash_logs').add({
 'error': details.exceptionAsString().substring(0, 500),
 'stack': details.stack.toString().substring(0, 1000),
 'uid': currentUser?.uid,
 'createdAt': FieldValue.serverTimestamp(),
 });
};

Crashlytics 대신 간단하게 만든 오류 수집기. error와 stack을 각각 500자, 1000자로 잘라서 저장한다. 문서 크기 폭발을 방지하기 위한 장치다.

app_config — 앱 설정

app_config/popup 문서 하나로 팝업 공지를 관리한다. 앱을 열 때 이 문서를 확인하고, 활성화된 팝업이 있으면 표시한다. 관리자 화면에서 실시간으로 팝업을 켜고 끌 수 있다.

설계하면서 배운 것

1. Firestore는 쿼리부터 설계한다

RDB에서는 데이터를 정규화하고, 필요할 때 JOIN한다. Firestore에서는 어떤 쿼리를 할 것인지 먼저 정하고, 그 쿼리에 맞게 데이터를 배치한다. likeCount 같은 비정규화가 그 예다.

2. 배열의 한계를 알아야 한다

Firestore에서 배열은 편리하지만 제약이 많다. arrayContainsAny는 최대 30개 값만 비교할 수 있고, not-in은 10개까지다. blockedUsers를 서버 쿼리로 필터링하지 못하고 클라이언트에서 처리하는 것도 이 제약 때문이다.

3. 문서 크기를 의식해야 한다

Firestore 문서 최대 크기는 1MB다. likes Map에 사용자가 수천 명 좋아요를 누르면 문서가 커진다. 학교 앱 규모에서는 문제가 안 되지만, 설계 단계에서 “이 필드가 무한히 커질 수 있는가"를 항상 생각해야 한다.

crash_logs에서 error와 stack을 잘라서 저장하는 것도 같은 이유다. 스택 트레이스 전체를 저장하면 문서 하나가 수십 KB가 될 수 있다.

4. 보안 규칙은 스키마의 일부다

Firestore Security Rules로 “자기 게시글만 수정 가능”, “승인된 사용자만 글 작성 가능”, “관리자만 사용자 정지 가능” 같은 규칙을 강제한다. 스키마를 설계할 때 보안 규칙에서 검증 가능한 구조인지도 함께 고려해야 한다.

돌아보면

8개 컬렉션은 한 번에 설계한 게 아니다. users와 posts로 시작해서, 채팅이 필요해지면 chats를, 신고가 필요해지면 reports를 추가했다. 기능이 늘어날 때마다 컬렉션이 하나씩 생겼다.

처음부터 다시 설계한다면 크게 바꿀 것은 없다. 다만 searchTokens의 n-gram 방식은 게시글이 많아지면 한계가 있으니, Algolia 같은 외부 검색 서비스를 처음부터 고려했을 것이다. 그리고 crash_logs는 Crashlytics로 대체하는 게 더 나았을 것이다.

하지만 학생이 혼자 만드는 앱에서 “완벽한 설계"를 추구하면 아무것도 못 만든다. 일단 동작하게 만들고, 문제가 생기면 고치는 것. NEIS API가 80줄에서 320줄로 진화한 것처럼, Firestore 스키마도 사용하면서 계속 진화하고 있다.

아직 배포를 하진 않았지만, 배포 후 사용자가 많아져서 Firebase에 요금이 청구되기 시작하면 Firestore를 걷어내고 직접 백엔드를 구축할 생각도 있다. 내 첫 메인 프로젝트지만 돈이 아깝다.