테넌트 구조 예약 시스템, 기획을 시작하며 정리한 용어들

 

예약 시스템 기획을 시작하고 가장 먼저 한 일은 화면을 그리는 게 아니라 용어 사전을 만드는 것이었습니다.
같은 단어를 쓰는데 사람마다 떠올리는 대상이 다르면, 회의는 길어지는데 결론은 나지 않아요.
특히 여러 업장이 함께 쓰는 테넌트 구조에서는 "누구의 것인가"를 구분해야 해서 용어가 더 중요합니다.
오늘은 제가 정리해둔 용어들을 하나씩 풀어보려고 해요.
업종마다 다르게 부르는 말이 있으니, 이건 정답이 아니라 "이렇게 맞춰두면 편하더라"에 가까운 기록입니다.

 

가장 먼저 헷갈린 단어가 테넌트였습니다.
테넌트는 서비스를 빌려 쓰는 "단위"를 말합니다.
쉽게 말하면 이 서비스에 가입해서 자기 데이터와 설정을 갖는 하나의 주체예요.
반면 업장(점포)은 실제로 손님이 찾아가는 물리적 장소입니다.

둘이 항상 1대 1이면 문제가 없지만, 그렇지 않은 경우가 있습니다.
예를 들어 미용실 사장님 한 분이 강남과 성수에 매장을 두 곳 운영한다고 해볼게요.
이분이 가입한 단위는 하나, 즉 테넌트는 하나인데 업장은 두 개입니다.
이때 "테넌트 설정"과 "업장 설정"을 구분하지 않으면 영업시간을 바꿀 때 어느 매장에 적용되는지 모호해져요.
저는 이렇게 정했습니다.
테넌트는 계약과 결제의 단위, 업장은 영업시간과 위치의 단위.

 

다음은 예약의 재료가 되는 세 가지입니다.

서비스(상품)는 고객이 고르는 메뉴예요.
미용실이라면 커트, 염색, 펌 같은 것들이고, 각각 걸리는 시간과 가격이 있습니다.

자원은 그 서비스를 제공하는 데 필요한 사람이나 공간입니다.
디자이너, 룸, 장비가 여기에 들어가요.
"직원"이라고 부르면 룸이나 장비를 설명하기 어려워서, 저는 처음부터 자원이라는 넓은 이름을 쓰기로 했습니다.

슬롯은 예약 가능한 시간 칸입니다.
예를 들어 30분 간격으로 칸을 나누면 10시, 10시 30분, 11시 같은 칸이 생기죠.
한 서비스가 60분 걸리면 슬롯 두 칸을 차지하게 되고, 이때 "시작 슬롯"과 "차지하는 슬롯"을 구분해서 이야기해야 합니다.
이 부분은 다음에 시간 계산 로직을 다룰 때 자세히 풀어볼게요.

여기에 고객이라는 말도 한 번 짚어둘 필요가 있었습니다.
예약하는 사람과 서비스를 받는 사람이 다른 경우가 있기 때문이에요.
부모님 대신 자녀가 예약하거나, 지인에게 선물로 예약해주는 상황이 대표적입니다.
그래서 예약자와 이용자를 구분할지 여부를 일찍 정해두었고, 알림은 예약자에게 보낼지 이용자에게 보낼지도 별도 규칙이 되었어요.
이용자 정보를 꼭 받아야 하는 업종과 아닌 업종이 있어서, 이 항목은 업장 설정으로 열어두는 방향을 생각하고 있습니다.

 

예약은 고객이 특정 서비스를 특정 시간에 받겠다고 한 기록입니다.
단순해 보이지만 상태가 있어요.
요청됨, 확정됨, 취소됨, 방문 완료, 노쇼 같은 상태들입니다.
어느 업장은 고객이 누르면 바로 확정이고, 어느 업장은 사장님이 승인해야 확정이어서 같은 "예약"이라도 흐름이 달라집니다.
그래서 저는 "예약 요청"과 "예약 확정"을 처음부터 다른 단어로 구분해서 쓰기로 했어요.

정책은 업장마다 다르게 정할 수 있는 규칙의 묶음입니다.
취소 가능 시간, 예약 가능한 최대 일수, 당일 예약 허용 여부, 보증금 같은 것들이죠.
정책이 테넌트 단위인지 업장 단위인지, 서비스 단위인지에 따라 설정 화면의 구조가 완전히 달라지기 때문에, "이 정책은 어느 층에서 정하는가"를 항상 같이 적어둡니다.

 

흔히 일어날 법한 상황을 가정해서 예를 하나 들어볼게요.
기획 초기에 "예약 취소는 하루 전까지만 가능하게 해주세요"라는 요구가 나왔다고 해봅니다.
개발자는 이걸 "예약 시작 시각 기준 24시간 전"으로 이해했고, 운영을 하시는 분은 "전날 영업 종료 시각까지"를 말한 거였어요.
오후 3시 예약이라면 개발자 기준으로는 전날 오후 3시까지, 운영자 기준으로는 전날 저녁 영업 종료 때까지입니다.
몇 시간 차이처럼 보이지만, 늦게 취소한 고객이 수수료를 내야 하는지 말아야 하는지가 이 차이로 갈려요.

이런 일을 줄이려고 저는 용어 사전에 정의뿐 아니라 "아닌 것"도 같이 적어둡니다.
예를 들어 이런 식이에요.

"취소 마감 시간: 예약 시작 시각을 기준으로 계산하는 시간. 영업 종료 시각이나 달력 날짜 기준이 아님."

이렇게 한 줄만 적어도 나중에 같은 논쟁을 반복하지 않게 되더라고요.

 

만들고 나서 가장 어려운 건 유지하는 일입니다.
제가 쓰는 방식은 단순해요.
새 용어가 회의에서 처음 나오면 그 자리에서 정의를 한 줄 쓰고, 다른 말과 혼동될 수 있으면 "이 말이 아닌 것"을 덧붙입니다.
이름이 둘 이상 쓰이고 있으면 하나를 대표 이름으로 정하고 나머지는 별칭으로 기록해요.
화면에 보이는 말과 내부에서 쓰는 말이 다를 수도 있어서, 고객에게 보이는 이름을 따로 적어두기도 합니다.
예를 들어 내부에서는 "자원"이지만 고객 화면에서는 "디자이너 선택"으로 보이는 식이에요.

처음 정리할 때는 용어를 서른 개 가까이 적고 싶은 욕심이 났는데, 지금은 반대로 생각합니다.
자주 오해가 생기는 열 개 안팎만 정확히 적어두는 게 더 쓸모 있었어요.
모든 단어를 정의하려고 하면 사전이 두꺼워져서 아무도 열어보지 않게 되니까요.
회의 중에 "그 단어 사전에 있나요?" 하고 바로 찾아볼 수 있을 정도의 분량이 적당한 것 같습니다.

 

용어 정리는 눈에 띄는 산출물이 아니라서 건너뛰기 쉽습니다.
하지만 지난 몇 달 동안 느낀 건, 용어가 맞아야 질문이 정확해지고 질문이 정확해야 답이 빨리 나온다는 점이에요.
아직 정리하지 못한 단어도 많습니다.

예를 들어 대기(웨이팅)와 예약의 경계, 그룹 예약에서 "인원"의 의미 같은 건 계속 고민 중이에요.
다음 글에서는 이 용어들을 바탕으로 멀티테넌트 구조 자체를 기획자 눈높이에서 정리해볼게요.