기술 구성
백엔드 선택 · React 프로토타입 활용 · 확장 대비 DB 구조
1
백엔드 기술 비교
| 항목 | Node.js (NestJS) + PostgreSQL | Firebase (Firestore) |
|---|---|---|
| 동시성 제어 | 우위DB 유일 조건 + 트랜잭션. 같은 자원·시간에 확정/대기 예약은 하나만 저장되고, 두 번째 INSERT는 DB가 거절. | 문서 트랜잭션으로 가능하나, 유일성은 규칙·보안규칙으로 직접 보장해야 하고 경쟁 조건 설계 부담이 큼. |
| 결제 통지(웹훅) 처리 | 우위서버에서 서명 검증·멱등 키 저장·상태 전이를 트랜잭션으로 묶기 쉬움. | Functions로 처리 가능하나 멱등·재시도·상태 일관성을 직접 구현해야 함. |
| 관리자 집계 | 우위SQL 집계·조인·리포트가 강력. 기간/자원별 통계가 쿼리 한 번. | 집계는 사전 계산·별도 컬렉션이 필요해 운영 복잡도 상승. |
| 확장(외부 플랫폼 연동) | 외부 채널 예약도 같은 예약 표로 흡수, 일관된 스키마 유지. | 빠른 실시간 동기화·모바일 SDK는 강점이나 스키마 통제가 느슨. |
| 비용 구조 | 예측 가능한 인스턴스·DB 비용. 트래픽 급증 시 수평 확장 설계 필요. | 초기 무료·사용량 과금이 간편하나, 읽기/쓰기량 증가 시 비용 변동성 큼. |
권장: Node.js (NestJS) + PostgreSQL
- · 중복 예약 방지의 핵심인 유일 조건·트랜잭션을 DB가 직접 보장합니다.
- · 결제 통지의 서명 검증·멱등 처리·상태 전이를 한 트랜잭션으로 안전하게 묶습니다.
- · 관리자 집계와 외부 채널 통합까지 하나의 관계형 스키마로 일관되게 확장합니다.
2
React 프로토타입 활용 판단
화면은 100% 동일, 속은 정리
그대로 살리는 것
- · 화면 구성과 레이아웃
- · 디자인·컴포넌트 스타일
- · 사용자 흐름(예약 → 결제 → 확정)
정리하는 것
- · 데이터 연결(목 → 실제 API)
- · 상태 관리 구조
- · 라우팅·인증·에러 처리
AI로 만든 화면을 버리지 않습니다. 보이는 부분은 유지하고 데이터·상태·라우팅만 제품 수준으로 정리합니다.
3
확장 대비 DB 구조
| 표 | 주요 컬럼 | 메모 |
|---|---|---|
| resource (자원) | id · 파트너 · 이름 · 위치 · 운영시간 · 단가 | Studio Mint A |
| slot (시간대) | id · resource_id · 시작 · 종료 · 상태(empty/held/confirmed) | 11/12 15:00–16:00 |
| booking (예약) | id · slot_id · 고객 · 상태 · 홀드 만료 · channel_id | 유일 조건: (resource_id, 시작시각) 당 활성 예약 1건 |
| payment (결제) | id · booking_id · 금액 · 통화 · 고유 키 · 통지 상태 | 확인 통지 수신 시 confirmed |
| channel (외부 채널) | id · 종류 · 외부 예약 식별자 · 매핑 | 외부 플랫폼 예약도 같은 booking 표로 |
외부 플랫폼에서 들어오는 예약도 channel을 통해 같은 booking 표로 흡수됩니다. 어느 경로로 들어오든 중복 예약 방지 규칙(자원·시간당 활성 예약 1건)은 동일하게 적용됩니다.