예약 데이터에서 놓치기 쉬운 것, 시간대·중복 예약·동시성

 

예약 시스템 기획서를 쓰다 보면 정상 흐름은 꽤 매끈하게 정리됩니다.
고객이 시간을 고르고, 예약이 생성되고, 알림이 나가고, 방문하면 끝나는 흐름이에요.
그런데 개발자와 이야기를 하다 보면 "그럼 두 명이 동시에 같은 시간을 누르면요?" 같은 질문이 나오고, 그제야 기획서에 비어 있던 부분이 보이곤 합니다.
이 글은 제가 예약 데이터를 기획하면서 놓치기 쉽다고 느낀 세 가지인 동시성, 시간대, 이력 보관을 정리한 기록입니다.

 

가장 먼저 만나는 문제가 동시성입니다.
가정 예시를 들어볼게요.
미용실 디자이너 한 분의 오후 3시 슬롯이 하나 남아 있습니다.
고객 A와 B가 거의 같은 순간에 이 슬롯을 보고 예약 버튼을 누릅니다.
두 사람 모두 화면에서는 "예약 가능"으로 보였기 때문에, 시스템이 아무 장치 없이 둘 다 받아주면 같은 시간에 예약이 두 건 생깁니다.

이 문제를 기획자가 직접 풀 수는 없지만, 어떻게 동작해야 하는지는 기획서가 정해줘야 합니다.
둘 중 먼저 처리된 요청만 성공하고, 나중 요청은 "방금 다른 분이 예약하셨어요, 다른 시간을 선택해 주세요"라고 안내하는 것이 기본 방향입니다.
이때 실패한 고객에게 가장 가까운 대안 시간을 함께 보여주면 경험이 훨씬 나아지고요.

또 하나는 선택 중인 시간을 잠깐 잡아두는 방식을 쓸지입니다.
결제나 정보 입력에 몇 분이 걸린다면, 그 사이 슬롯을 임시로 점유해두고 일정 시간이 지나면 풀어주는 방식이 있어요.
편리하지만 점유만 하고 이탈하는 고객 때문에 빈 시간이 막히는 부작용이 있어서, 점유 시간을 몇 분으로 둘지가 정책 질문이 됩니다.
이런 선택은 기술이 아니라 서비스 경험과 운영 방식의 문제라서 기획자와 개발자가 같이 정해야 해요.

 

두 번째는 시간대입니다.
국내 서비스만 생각하면 시간대 문제가 없는 것처럼 느껴지지만, 데이터를 저장하는 방식에서 바로 영향을 받습니다.
일반적으로 시스템은 시각을 표준 시각 기준으로 저장하고, 화면에 보여줄 때 업장의 현지 시간으로 바꿔 보여주는 방식을 많이 쓴다고 알고 있어요.
저는 이 정도 원리만 알고, 실제 구현 방식은 개발자와 확인하는 편입니다.

기획자가 챙길 것은 "업장의 시간대"가 데이터로 존재해야 한다는 점입니다.
테넌트 구조라면 업장마다 시간대 정보를 가질 수 있어야, 나중에 해외 업장을 지원하거나 여행객이 예약하는 상황에서도 시간이 어긋나지 않아요.
해외 사용자가 자기 시간 기준으로 "오후 3시"를 이해하고 예약하는데 업장은 현지 시간으로 받는 경우를 상상해보면 이 문제가 어렵다는 게 와닿습니다.

일광절약시간 같은 제도가 있는 지역에서는 하루가 23시간이거나 25시간이 되는 날이 생길 수 있다는 것도 알게 됐습니다.
국내 서비스에서는 해당이 없지만, 확장 가능성을 열어둘지 여부는 초기에 정해두는 것이 좋아요.
더 일상적인 문제는 날짜 경계입니다.
밤 11시 30분에 시작해서 자정을 넘기는 예약이 어느 날짜의 예약인지, 영업시간이 새벽 2시까지인 업장의 "오늘"은 언제까지인지 같은 질문이에요.
저는 "영업일"이라는 개념을 달력 날짜와 분리해서 정의해두는 방향으로 정리했습니다.

 

세 번째는 이력입니다.
예약을 취소하거나 변경할 때 기존 데이터를 그냥 덮어써버리면, 나중에 분쟁이 생겼을 때 확인할 방법이 사라져요.
고객은 "분명 어제 취소했어요"라고 하는데 시스템에는 예약의 최종 상태만 남아 있다면, 운영자도 고객도 곤란해집니다.

그래서 예약 상태를 바꿀 때마다 변경 이력을 남기는 것을 기본 원칙으로 적어두었습니다.
누가, 언제, 무엇을, 어떤 값에서 어떤 값으로 바꿨는지가 남아야 하고, 고객이 한 변경인지 운영자가 한 변경인지 시스템이 자동으로 한 변경인지도 구분되면 좋습니다.
예를 들어 노쇼 처리나 자동 취소 같은 시스템 동작이 있다면, 나중에 "왜 이 예약이 취소됐지?"에 바로 답할 수 있어야 해요.
이력을 얼마나 오래 보관할지는 개인정보와 관련된 정책이라 법적 기준과 서비스 정책을 함께 확인해야 하는 부분입니다.

삭제도 같은 맥락입니다.
예약 건을 화면에서 지우는 기능이 필요하더라도, 실제 데이터는 삭제 상태로만 표시하고 남겨두는 방식이 있는지 개발자에게 물어보는 편이에요.
다만 이 역시 개인정보 삭제 요구와 부딪힐 수 있어서, 보관과 삭제 사이의 기준은 따로 정리해야 합니다.

 

이 과정을 거치면서 제가 기획서 끝에 붙여두는 질문 목록은 이렇게 정리됐습니다.
같은 슬롯에 동시에 요청이 오면 누구를 성공시키고 실패한 사람에게 무엇을 보여주는지.
임시 점유를 쓴다면 몇 분 동안 유지하고, 만료되면 화면은 어떻게 되는지.
시각은 어떤 기준으로 저장하고 업장의 시간대는 어디에 두는지.
자정을 넘기는 예약과 영업일은 어떻게 정의하는지.
예약 상태가 바뀔 때 어떤 이력을 남기고 얼마나 보관하는지.
삭제된 예약은 실제로 지워지는지, 숨겨지는지.

이 질문들은 정답을 아는 것보다, 질문을 해두었다는 사실이 중요하다고 생각해요.
기획서에 질문이 적혀 있으면 개발 중에 "이건 정해진 게 없네요" 하고 멈추는 일이 줄어듭니다.

 

정상 흐름은 누구나 그릴 수 있지만, 서비스의 신뢰는 비정상 흐름에서 결정되는 것 같습니다.
예약처럼 "약속"을 다루는 서비스는 특히 그렇고요.
아직 정하지 못한 부분도 있어요.

점유 시간을 몇 분으로 두는 게 적절한지, 네트워크 지연으로 요청이 중복 전송되었을 때를 어떻게 구분할지 같은 것들입니다.
이 부분은 개발자와 시나리오를 하나씩 돌려보면서 보완해 나갈 계획입니다.