"예약 사이트 만들고 싶은데요" 문의를 받을 때마다 제가 먼저 묻는 질문은 "하나의 샵인가요, 여러 업체를 연결하나요?"입니다. 이 한 줄 차이로 난이도가 3배 이상 달라집니다. 예약 플랫폼은 겉보기엔 단순해도 설계에 신경 써야 할 지점이 많습니다. 실제 프로젝트에서 정리한 7가지 포인트를 공유합니다.
1. 자원(Resource) 모델링 — 가장 먼저
예약할 "대상"이 무엇인지 정의부터. 시간대인가, 좌석인가, 강사인가, 방인가. 한 자원에 여러 속성(예: 강사 + 장소 + 장비)이 동시에 묶이는 구조라면 그 결합이 예약 단위의 핵심이 됩니다. 여기서 모호하면 이후 모든 기능이 흔들립니다.
2. 캘린더 슬롯 — "빈 자리"의 정의
슬롯을 고정 시간 단위(30분·1시간)로 분할하는 구조와 가변 길이 예약을 허용하는 구조는 전혀 다른 제품입니다. 전자는 구현이 단순하나 유연성이 낮고, 후자는 유연하지만 충돌 검증·가용성 표시 로직이 복잡.
실무 권고: 초기엔 고정 슬롯으로 시작, 필요 시 확장. 처음부터 가변 슬롯을 목표하면 착수가 느려집니다.
3. 동시 예약 충돌 방지 — 가장 쉽게 실수하는 부분
두 명이 동시에 같은 슬롯을 누르면 어떻게 되는가. 답: DB 레벨에서 잠그거나, 유니크 제약으로 막거나. "먼저 체크 후 insert" 패턴은 레이스 컨디션으로 이중 예약을 허용합니다. 예약이 돈과 연결되는 순간 이 한 줄이 큰 분쟁을 만듭니다.
4. 취소·변경 정책
취소·변경이 가능한 기한, 환불율, 변경 가능 횟수. 정책이 문서만 있고 코드엔 없으면 운영자가 매번 수동 판단해야 합니다. 코드에 정책을 "정책 객체"로 분리해 두면 향후 변경이 안전합니다.
5. 결제·정산 구조 (멀티 샵이면 난이도 폭증)
단일 샵은 단순(결제 → 바로 샵 수익). 멀티 샵은 (a) 선결제를 플랫폼이 수령, (b) 정산일에 수수료 제외 후 샵 지급. 이 구조는 단순 계산 같아도 세금계산서·환불·부분 환불·분쟁 처리까지 얽히면 별도 정산 시스템이 필요해집니다. MVP에선 단일 샵부터 시작하고 멀티샵 확장은 단계적으로 권장.
6. 알림 3단 구조
- 예약 직후: 확인 메일·카톡. 즉시 발송.
- 사전 리마인더: D-1 또는 3시간 전. 노쇼율을 유의미하게 낮춤.
- 사후 피드백: 이용 종료 후 평가·재방문 유도. CRM의 시작점.
세 알림 중 사전 리마인더가 가장 효과가 크고, 가장 자주 빠집니다.
7. 관리자 화면 — 운영자가 매일 쓰는 공간
예약 플랫폼의 실사용자는 최종 고객이 아니라 운영자입니다. 운영자가 하루에 수십 번 여닫는 화면이므로 한 화면에서 모든 예약이 보이고, 클릭 한 번에 취소·변경이 되는 구조가 핵심. 예쁘기보다 빠른 UI가 우선입니다.
비용·일정 현실 범위
- 단일 샵 단순 예약: 3~5주, 500~1,200만 원.
- 단일 샵 복합 예약(여러 자원·옵션): 5~8주, 1,200~2,500만 원.
- 멀티 샵 플랫폼: 10~16주, 3,000~6,000만 원 (정산·심사·약관 포함).
마무리
예약 플랫폼의 난이도는 "화면 수"가 아니라 "자원 × 시간 × 정책"의 곱에서 나옵니다. 처음부터 거대한 플랫폼을 노리기보다 한 샵에서 완성도 있게 운영한 뒤 확장하는 편이 지속 가능합니다. 이 순서로 만든 제품들이 3년 뒤에도 살아남는 것을 여러 번 봤습니다.