TimeSlot 아키텍처 — Firebase를 선택한 이유와 실전 검증

무엇을 만들었나

행사 예약 운영 시스템. 주최자가 슬롯을 만들면 참가자가 예약하고, 현장에서 QR로 체크인하는 전 사이클.

기존에는 구글 폼 + 스프레드시트 + 카카오 단체방으로 수동 운영했다. 실시간 현황 파악이 안 되고, 주최자 리소스가 많이 들었다.

핵심 기술 선택과 이유

Firebase RTDB + Firestore (혼합 사용)

• RTDB: 슬롯 잔여석 카운터 — 여러 사용자가 동시에 예약할 때 onSnapshot으로 즉시 동기화 필요
• Firestore: 예약자 데이터 — 구조화된 문서 형태로 어드민 쿼리에 유리
• 이유: 단순 카운터는 RTDB atomic increment가 Firestore보다 빠르고 충돌이 없다

Next.js 15 App Router

• 이유: SSR로 초기 로딩을 빠르게, 파일 기반 라우팅으로 어드민/참가자 권한 분기
• 트레이드오프: useSearchParams가 Suspense 필수 → 처음에 이 규칙을 몰라서 빌드 오류 겪음

Cloud Functions (서버리스 알림)

• 이유: 별도 서버 없이 카카오 알림톡 발송 로직을 처리, 스타트업에서 인프라 비용 최소화
• 실제 문제: Solapi IP 화이트리스트 + Cloud Run egress IP 미등록으로 배포 후 알림 실패 → egress IP 등록으로 해결

시스템 흐름

참가자 → 예약 → Firestore 저장 + RTDB 카운터 감소
                        ↓
              Cloud Function 트리거
                        ↓
              Solapi 카카오 알림톡 발송
                        ↓
현장 QR 스캔 → 체크인 상태 업데이트 → 어드민 대시보드 실시간 반영

실전 검증에서 터진 것들

아주대 전공멘토링 행사 당일에 3가지 버그가 현장에서 터졌다.

1. iOS 카카오 인앱 브라우저: JS로 외부 브라우저 전환 불가 → Cloud Function HTTP 302 redirect로 즉석 패치
2. 새로고침 시 슬롯 선택 초기화: localStorage persist로 해결
3. 카운터 재계산 오류: atomic increment 보완

코드는 PR 통과 후에도 완성이 아니다. 실제 사람들이 쓸 때 드러나는 버그가 있다.