예약 시스템의 핵심 도메인 모델, 업장, 서비스, 자원, 슬롯

 

예약 시스템은 겉으로 보면 "날짜와 시간을 고르는 화면"이지만, 그 뒤에는 몇 가지 개념이 서로 연결된 구조가 있습니다.
이 연결을 처음부터 제대로 잡아두지 않으면, 나중에 요구사항이 하나 추가될 때마다 구조 전체를 흔들게 돼요.
오늘은 제가 정리한 핵심 도메인 모델을 미용실 예시로 줄글로 풀어보려고 합니다.
엔티티 관계도를 그릴 수도 있지만, 먼저 말로 설명할 수 있는지 확인하는 편이 이해가 빨랐어요.

 

가상의 미용실을 하나 떠올려볼게요.
이름은 그냥 "A 미용실"이라고 하고, 디자이너 두 분과 샴푸실 하나가 있다고 합니다.
메뉴는 커트, 염색, 펌 세 가지예요.
손님이 앱에서 "토요일 오후 2시 커트"를 예약하려고 합니다.

이 한 문장 안에 개념이 줄줄이 들어 있어요.
미용실이라는 장소, 커트라는 메뉴, 담당 디자이너, 2시라는 시간, 그리고 그 결과로 생기는 예약 한 건.
이걸 하나씩 구분하는 게 도메인 모델링의 출발입니다.

 

업장은 예약이 이루어지는 장소이자 영업의 단위입니다.
영업시간, 휴무일, 위치 같은 정보는 업장에 붙어요.
여러 업장이 같은 서비스를 쓰는 테넌트 구조에서는 업장이 하나의 테넌트 아래 여러 개 있을 수 있습니다.

서비스는 업장이 파는 메뉴입니다.
커트, 염색, 펌이 여기에 해당하고, 각 서비스에는 소요 시간과 가격이 있어요.
같은 이름의 서비스라도 업장마다 가격이 다를 수 있다는 점에 주의해야 합니다.

자원은 서비스를 제공하는 데 필요한 사람이나 공간입니다.
A 미용실의 디자이너 두 분과 샴푸실이 자원이에요.
자원도 각자 근무 시간이 있고, 쉬는 날이 있습니다.

슬롯은 시간을 일정한 간격으로 쪼갠 칸입니다.
30분 간격이라면 오후 2시, 2시 30분, 3시 같은 칸이 생기고, 어떤 자원의 어떤 슬롯이 비어 있는지가 예약 가능 여부를 결정합니다.

그리고 예약은 이 모든 걸 연결하는 기록입니다.
"어떤 고객이, 어떤 업장에서, 어떤 서비스를, 어떤 자원으로, 어느 시간대에 받는다"를 담는 한 건이에요.

 

서비스와 자원을 어떻게 연결할지는 설계에서 가장 먼저 갈리는 지점입니다.
제가 정리한 방식은 두 가지예요.

 

첫 번째는 서비스마다 가능한 자원을 미리 지정하는 방식입니다.
"커트는 디자이너 '가'와 '나'가 할 수 있고, 염색은 디자이너 '나'만 할 수 있다"처럼 목록으로 연결해두는 거예요.
규칙이 명확하고 예약 가능 시간을 계산하기 쉽습니다.
대신 새 자원이 생기거나 서비스가 늘어날 때마다 연결을 일일이 관리해야 해요.

 

두 번째는 자원에 능력을 붙이고 서비스가 요구하는 능력과 맞추는 방식입니다.
예를 들어 "염색 가능"이라는 능력을 자원에 붙이고, 염색 서비스는 그 능력을 가진 자원을 요구하는 식이에요.
유연하고 확장하기 좋지만 처음 설명하고 이해시키는 데 시간이 더 듭니다.
운영하는 분들이 설정 화면에서 헷갈리기 쉽다는 단점도 있어요.

 

작게 시작한다면 첫 번째 방식이 무난하고, 업종이 다양해지거나 자원이 많아지면 두 번째로 옮겨가는 길을 열어두는 정도가 현실적이라고 생각했습니다.
다만 어느 쪽을 택하든 "이 서비스는 어떤 자원이 필요한가"를 데이터가 아니라 규칙으로 기획서에 적어두어야 해요.

 

앞의 예시에서 염색은 디자이너와 샴푸실이 함께 필요하다고 해볼게요.
그러면 한 예약이 여러 자원을 동시에 점유합니다.
이때 디자이너는 비어 있는데 샴푸실이 차 있다면 예약이 불가능해져요.
이런 경우를 처음부터 고려하지 않고 "예약 하나에 자원 하나"로 모델링해버리면, 나중에 고쳐야 할 범위가 상당히 커집니다.
시간 구간도 서비스 안에서 단계가 나뉠 수 있어요.
처음 30분은 디자이너, 중간 20분은 대기, 마지막 30분은 다시 디자이너가 필요한 식입니다.
이런 복잡한 경우는 초기에 다 지원하지 않더라도, "지원하지 않는다"는 결정을 문서에 남겨둬야 해요.

고객이 자원을 직접 고르는 경우와 "아무나"를 고르는 경우도 구분해야 합니다.
디자이너를 지정하는 예약은 그 사람의 슬롯만 확인하면 되지만, 지정하지 않는 예약은 가능한 자원 중 하나를 시스템이 배정해야 해요.
이때 배정 기준이 필요합니다.
먼저 비어 있는 사람에게 넣을지, 예약이 적은 사람에게 고르게 나눌지, 지정 요청이 많은 사람은 아껴둘지에 따라 운영하는 분들의 체감이 크게 달라집니다.
저는 이 규칙을 업장 설정으로 열어둘지, 서비스 기본값으로 둘지 아직 고민 중이에요.

 

제가 겪었거나 겪을 뻔했던 실수들입니다.

 

첫째는 업장과 테넌트를 같은 걸로 보는 것입니다.
한 사장님이 매장을 둘 운영하는 순간 모든 설정이 어긋나기 시작해요.

둘째는 서비스에 자원을 직접 박아두는 것입니다.
"커트 서비스는 디자이너 '가'가 한다"를 서비스 정보 안에 적어버리면, 디자이너가 그만두거나 늘어날 때 서비스를 고쳐야 합니다.
서비스와 자원은 따로 두고 연결 관계를 별도로 관리하는 편이 낫습니다.

셋째는 소요 시간과 슬롯 간격을 같은 값으로 취급하는 것입니다.
슬롯은 30분 간격인데 서비스가 45분이라면 어떻게 칸을 차지하는지 규칙이 필요해요.
이 문제는 예약 가능 시간 계산을 다루는 글에서 더 자세히 풀어보려고 합니다.

넷째는 예약과 예약 가능 여부를 한 덩어리로 보는 것입니다.
예약은 이미 일어난 기록이고, 예약 가능 여부는 업장의 규칙과 기존 예약을 합쳐서 계산한 결과예요.
저장하는 값과 계산하는 값을 구분해야 변경이 생겨도 일관성을 지킬 수 있습니다.

 

도메인 모델은 한 번에 완성되지 않고, 요구가 들어올 때마다 조금씩 다듬어집니다.
그래도 업장, 서비스, 자원, 슬롯, 예약이라는 다섯 개념을 말로 설명할 수 있으면 대부분의 대화가 훨씬 수월해졌어요.
저는 아직 업종마다 다른 변형을 다 알지 못합니다.
네일숍, 스튜디오, 운동 수업처럼 업종이 바뀌면 어떤 개념이 새로 필요해질지가 앞으로의 공부거리예요.
다음 글에서는 이 모델 위에서 실제로 예약 가능한 시간을 계산할 때 고려해야 할 영업시간, 휴무, 버퍼타임을 이어서 정리해보겠습니다.