해결하려던 문제
공연을 준비하는 팀이 예약을 전화·메신저로 받고 있었습니다. 예약자 명단은 여러 곳에 흩어지고, 회차별 인원과 입금 상태는 담당자가 매번 수기로 맞춰야 했습니다. 공연 직전에 확인 연락이 몰리면 누락이 생기고, 그 부담이 그대로 운영진에게 쌓였습니다.
사용자와 환경
공연을 예약하는 관객과, 공연을 운영하는 담당자 두 종류의 사용자가 있습니다. 관객은 대부분 모바일로 접속하고, 운영 담당자는 공연 당일 현장에서도 예약 현황을 확인합니다.
구축 범위
- 공연·회차·예약 데이터 구조 설계
- 고객용 예매 화면
- 관리자 콘솔
- 입금·부분 결제 상태 관리
- 배포와 운영 이관
핵심 기능
- 공연 일정·회차 조회와 온라인 예약
- 공연 생성·수정·삭제 관리자 기능
- 회차별 예약 현황과 입금·부분 결제 상태 관리
- 출연진 정보 관리
- 삭제 이력을 남기는 소프트 삭제 처리
- 모바일·데스크톱 반응형
시스템 구조
React 기반 프론트엔드가 Supabase(PostgreSQL)를 백엔드로 사용합니다. 공연·회차·예약·결제 상태를 관계형으로 설계하고, 관리자 화면은 별도 라우트와 권한으로 분리했습니다. 예약 취소·공연 삭제는 기록을 지우지 않고 상태로 남겨 운영 이력을 추적할 수 있게 했습니다.
결과와 현재 상태
실제 서비스로 운영 중입니다. 전화·메신저로 흩어져 있던 예약을 한 화면에서 관리하게 되었습니다. 구체적인 예약 건수·운영 효율 수치는 발주처 자료라 공개하지 않습니다.
고객 프로젝트로, 발주처명은 공개 동의 전이라 표기하지 않습니다. 화면은 공개 가능한 범위만 게시합니다.
화면
이 사례에서 보여드리는 것
작은 규모라도 실제로 운영되는 서비스는 “예쁜 화면”만으로 굴러가지 않습니다. 누가 무엇을 볼 수 있는지, 취소된 예약을 어떻게 남길지, 입금이 일부만 들어왔을 때 어떻게 표시할지 같은 운영 규칙이 데이터 구조에 들어가 있어야 합니다.
이 사례는 고객용 화면과 관리자 화면을 함께 설계해 배포·이관까지 마친 프로젝트입니다.