이 개발을 시작하게 된 계기는 학원 선생님께서 만들어보면 어떻겠냐고 말씀해주신 것이었습니다. 처음에는 그냥 카페 좌석 예약 페이지 정도를 만들어보면 되겠다고 생각했습니다. 사용자가 자리를 고르고 예약하면 관리자가 확인하는 정도의 간단한 시스템을 떠올렸습니다.
그런데 실제 운영 방식을 보니까 생각보다 불편한 부분이 많았습니다. 직원분들이 매번 직접 층을 올라가서 어떤 자리가 비어 있는지 하나씩 확인해야 했고, 이용권도 1일권, 7일권, 30일권처럼 종류별로 따로 수기로 기록하고 있었습니다. 돈 관리도 따로 수기로 정리하고 있었고, 예약 상태나 결제 여부를 한눈에 볼 수 있는 화면도 없었습니다.
그래서 단순한 예약 페이지가 아니라, 카페 운영에서 수기로 하던 일을 온라인으로 정리하는 시스템을 만들어보기로 했습니다.
먼저 좌석을 온라인에서 확인할 수 있게 만들어봤습니다. 처음에는 “빈 자리인지, 사용 중인지 정도만 표시하면 되겠지”라고 생각했는데, 막상 해보니까 그것만으로는 부족했습니다. 예약 신청만 들어온 상태인지, 관리자가 승인한 예약인지, 취소된 예약인지, 이용 기간이 끝난 예약인지가 다 구분되어야 했습니다. 그래서 예약 상태를 대기, 승인, 거절, 취소, 완료처럼 나누고, 관리자 화면에서 바로 확인할 수 있게 정리했습니다.
이용권 관리도 생각보다 까다로웠습니다. 3층과 4층은 좌석을 며칠 동안 쓰는 방식이라 1일권, 7일권, 30일권처럼 기간 중심으로 처리하면 됐습니다. 그런데 M층은 시간 단위로 예약하는 공간이라 날짜뿐만 아니라 시작 시간과 이용 시간까지 계산해야 했습니다. 처음에는 단순하게 처리해봤는데, 같은 시간대에 중복 예약이 생길 수 있어서 시간 충돌을 따로 검사하도록 수정했습니다.
관리자 페이지도 계속 바꿔봤습니다. 처음에는 예약 목록만 보여주면 될 줄 알았는데, 실제로는 관리자가 보고 싶은 정보가 훨씬 많았습니다. 지금 어떤 좌석이 사용 중인지, 누가 언제까지 이용하는지, 결제가 확인됐는지, 매출에 반영해도 되는 예약인지가 중요했습니다. 그래서 좌석 모니터, 예약 승인, 회원 관리, 매출 정리, 환불 처리 같은 기능을 하나씩 추가했습니다.
만들면서 가장 크게 느낀 점은, 실제 운영 시스템은 기능 하나하나보다 예외 처리가 더 중요하다는 것이었습니다. 예약이 겹치면 안 되고, 결제 증빙이 있어야 하고, 관리자가 실수로 잘못 승인하지 않게 해야 하고, 모바일에서도 제대로 동작해야 했습니다. 처음에는 간단한 예약 앱으로 시작했지만, 결국 카페에서 수기로 하던 운영 흐름을 온라인으로 옮기는 프로젝트가 되었습니다.
다음 글에서는 이 시스템에서 가장 중요했던 예약 구조를 정리해보려고 합니다. 특히 3층/4층 좌석권과 M층 시간권을 왜 다르게 설계했는지, 그리고 중복 예약 문제를 어떻게 해결했는지를 다뤄보겠습니다.
