방탈출 예약 시스템은 데이터베이스 수업에서 만든 첫 웹 기반 예약 프로젝트입니다. 저는 가상의 KHU ESCAPE 서비스를 두고, 사용자가 화면에서 하는 행동이 실제 테이블 상태 변화로 이어지도록 HTML, PHP, SQL을 연결했습니다.
왜 방탈출이었는가
방탈출 예약은 데이터베이스를 배우기에 좋은 예제였습니다. 지점, 테마, 시간대, 예약자, 플레이 기록, 후기처럼 서로 연결된 정보가 많고, 사용자는 이를 하나의 흐름으로 경험합니다. 단순 CRUD 예제보다 실제 서비스에 가까운 관계를 만들 수 있었습니다. 저는 이 프로젝트에서 사용자의 예약 행동을 테이블 구조로 바꾸는 경험을 처음 했습니다.
방탈출 서비스는 작은 도메인이지만 상태가 많습니다. 같은 테마라도 지점에 따라 운영 여부가 다르고, 예약 가능 시간은 날짜와 기존 예약에 따라 바뀝니다. 사용자가 보는 화면은 간단해 보여도 뒤에서는 관계와 제약을 잘 나눠야 했습니다.
만든 데이터 구조
핵심은 지점과 테마의 관계였습니다. 하나의 지점에 여러 테마가 있고, 같은 종류의 테마가 다른 지점과 연결될 수도 있습니다. 그래서 저는 단순 컬럼으로 밀어 넣지 않고 junction table을 두어 다대다 관계를 표현했습니다. 예약, 게임 기록, 피드백도 각각 독립된 테이블로 나누고, 화면에서 선택한 값이 어떤 foreign key로 이어지는지 확인했습니다.
이때 처음으로 정규화가 화면 품질과 연결된다는 것을 느꼈습니다. 테이블 관계가 어색하면 사용자가 고르는 선택지도 어색해집니다. 반대로 상태를 잘 나누면 예약 가능 여부, 지점별 테마, 후기 연결 같은 기능을 훨씬 자연스럽게 만들 수 있습니다.
화면과 DB를 연결한 경험
HTML 화면에서 사용자가 날짜와 테마를 고르면, PHP가 SQL을 통해 가능한 예약 정보를 읽고 상태를 갱신했습니다. 지금 보면 보안, 인증, 동시성, 결제 같은 중요한 요소가 빠져 있습니다. 하지만 당시에는 화면 버튼 하나가 실제 데이터 변경으로 이어지는 감각 자체가 컸습니다. 저는 프론트엔드가 보여 주는 선택지가 데이터베이스 설계를 그대로 드러낸다는 점도 이때 알게 됐습니다.
특히 예약 시스템은 "보여 주는 것"과 "잠그는 것"이 다릅니다. 가능한 시간대를 보여 줄 수 있어도, 동시에 여러 사용자가 같은 시간대를 잡는 문제는 별도의 동시성 처리가 필요합니다. 이 프로젝트에서는 그 수준까지 구현하지 못했지만, 이후 시스템을 볼 때 상태 충돌과 트랜잭션을 의식하게 된 계기가 됐습니다.
이후에 남은 기준
이 프로젝트는 작은 수업 과제였지만, 제게는 데이터 모델링의 출발점이었습니다. 좋은 화면은 결국 좋은 상태 구조를 필요로 합니다. 반대로 관계가 어색한 DB는 화면에서도 어색한 선택지를 만듭니다. 이후 프로젝트에서 예약, 상태, 사용자 행동, 로그를 다룰 때도 저는 먼저 엔티티 관계와 상태 변화를 그려 보고 구현을 시작하게 됐습니다.
