테넌트별 요금제와 기능 제한 설계

 

예약 시스템을 업장마다 따로 쓰는 구조(테넌트)로 기획하다 보면, 어느 시점엔 반드시 "그럼 요금제는 어떻게 나누죠?"라는 질문을 만나게 됩니다.
요금제는 가격표만의 문제가 아니라서, 어떤 기능을 누구에게 열어줄지, 한도를 넘으면 어떻게 할지가 함께 정해져야 해요.
창업을 정리하던 시기에 가격과 수익 모델을 공부했던 기억이 있는데, 실제 테넌트 구조에 얹어서 생각해 보니 훨씬 구체적인 설계 문제가 되더라고요.
이번 글은 요금제를 어떤 단위로 쪼갤지, 변경과 해지 때는 어떤 정책이 필요한지 정리한 기록입니다.
금액이나 수치는 모두 설명을 위한 가정입니다.

 

요금제를 설계할 때 저는 제한을 두 종류로 구분하면 훨씬 정리가 쉬웠어요.
첫째는 기능 플래그입니다.
어떤 기능을 쓸 수 있는지 없는지를 켜고 끄는 성격이에요.
예를 들어 "알림 문자 발송", "통계 리포트", "여러 지점 관리" 같은 항목이 여기에 속합니다.
둘째는 한도입니다.
기능은 쓸 수 있되 얼마나 쓸 수 있는지를 정하는 성격이에요.
"한 달 예약 건수 200건까지", "등록 가능한 직원 5명까지", "알림 발송 월 300건까지" 같은 것들이죠.

이렇게 나누면 요금제 표가 한눈에 정리됩니다.
가상의 요금제를 예로 들어볼게요.
무료 요금제는 기본 예약 받기만 되고 월 예약 50건, 직원 1명까지입니다.
기본 요금제는 월 예약 300건, 직원 5명, 알림 발송이 열립니다.
확장 요금제는 예약 건수 무제한에 가깝고, 여러 지점 관리와 통계 리포트가 추가됩니다.
각 요금제를 "켜진 기능 목록 + 한도 숫자들"로 표현할 수 있다는 점이 중요해요.
이렇게 데이터로 표현해 두면, 나중에 요금제를 바꾸거나 새로 추가할 때 화면을 고치는 게 아니라 설정을 고치는 일이 됩니다.

 

한도 설계에서 가장 고민했던 부분은 "넘었을 때의 동작"이었습니다.
선택지를 크게 세 가지로 생각해 봤어요.
하나는 막는 방식입니다.
월 50건이 차면 그 달에는 새 예약을 받지 않는 거죠.
다른 하나는 경고만 하는 방식으로, 한도를 넘어도 일단 받되 운영자에게 "곧 업그레이드가 필요해요"라고 알립니다.
마지막은 초과분 과금 방식이에요.

예약 시스템에서는 막는 방식이 위험할 수 있다고 생각했어요.
한도 때문에 고객의 예약이 거부되면 운영자의 매출 손실로 바로 이어지고, 불만도 가장 크게 나옵니다.
그래서 제가 정리한 원칙은 "고객이 보는 곳은 막지 말고, 운영자가 설정하는 곳을 막자"였습니다.
예를 들어 직원 등록 수는 설정 화면에서 막아도 문제가 크지 않지만, 예약 건수는 한도 근처부터 운영자에게 미리 알려주고 넘더라도 일정 범위까지는 유예하는 쪽이 낫다고 봤습니다.
이건 어디까지나 제 기준이고, 사업 모델에 따라 달라질 수 있어요.

 

요금제를 올릴 때는 비교적 단순합니다.
결제가 되면 바로 기능과 한도가 열리면 되니까요.
다만 한 달 중간에 올리면 요금을 일할 계산할지, 다음 결제일부터 적용할지는 정해야 합니다.

문제는 다운그레이드예요.
확장 요금제에서 기본 요금제로 내렸는데, 이미 직원이 8명 등록돼 있다면 어떻게 될까요.
기본 요금제의 한도는 5명입니다.
이때 선택지는 몇 가지가 있어요.
초과분을 즉시 비활성화하는 방법, 현재 상태는 유지하되 새로 추가는 못 하게 하는 방법, 다음 결제 주기에 적용하면서 그 사이에 운영자가 직접 정리하도록 안내하는 방법입니다.
저는 세 번째가 가장 부드럽다고 느꼈어요.
"다음 결제일부터 직원은 5명까지 쓸 수 있어요. 그 전에 사용할 직원을 선택해 주세요"라고 미리 안내하면, 갑자기 직원 계정이 막히는 사고를 줄일 수 있습니다.

다운그레이드 시에는 꺼지는 기능에 연결된 데이터도 생각해야 해요.
예를 들어 통계 리포트 기능이 꺼져도 그동안 쌓인 데이터는 그대로 두어야, 다시 올렸을 때 이어서 볼 수 있습니다.
"기능은 닫히지만 데이터는 지우지 않는다"를 원칙으로 두면 판단이 쉬워졌어요.

 

해지는 가장 조심스러운 영역입니다.
해지하자마자 모든 데이터를 지우면 실수로 해지한 운영자는 복구할 방법이 없고, 반대로 무기한 보관하면 비용과 개인정보 관리 부담이 생겨요.
그래서 해지 이후를 단계로 나눠 생각해 봤습니다.
해지 직후 일정 기간은 읽기 전용 상태로 두고 내려받기를 안내합니다.
그다음 일정 기간은 서비스는 닫되 데이터는 보관해서, 마음이 바뀐 운영자가 다시 돌아올 수 있게 합니다.
마지막으로 정해진 기간이 지나면 삭제하되, 삭제 전에 미리 알려줍니다.

예를 들어 "해지 후 30일은 읽기 전용, 이후 90일은 보관, 그 뒤 삭제" 같은 식입니다.
이 숫자들은 가정일 뿐이고, 실제로는 개인정보 관련 법령과 약관을 확인해서 정해야 하는 부분이라 기획자 혼자 정할 수 없습니다.
다만 "단계가 있어야 한다"는 구조까지는 기획에서 제안할 수 있다고 생각해요.
고객의 예약 정보처럼 고객의 개인정보가 담긴 데이터는 업장의 데이터이기도 하고 고객의 데이터이기도 해서, 어느 범위까지 보관하는지는 별도로 점검해야 합니다.

 

요금제 기획을 정리하면서 스스로에게 던진 질문 목록입니다.

• 요금제 한 줄 요약은 무엇인가(누구를 위한 요금제인가).
• 기능 플래그와 한도가 각각 몇 개인가, 코드에 박지 않고 설정으로 둘 수 있는가.
• 한도에 가까워졌을 때, 도달했을 때, 넘었을 때 각각 누구에게 어떤 안내가 가는가.
• 업그레이드 시점과 다운그레이드 시점은 언제 적용되는가.
• 다운그레이드로 한도를 넘는 데이터가 생기면 어떻게 처리하는가.
• 해지 후 단계별로 무엇이 보이고 무엇이 막히는가.
• 시범 기간(체험)이 있다면 끝났을 때 무엇이 달라지는가.

이 목록을 채우다 보면 "가격은 이 정도"보다 "상황별 동작"을 적는 일이 훨씬 많다는 걸 알게 됩니다.

 

요금제 설계를 해보면서, 가격 숫자는 가장 마지막에 정해도 된다는 생각이 들었어요.
먼저 어떤 가치를 어떤 단위로 쪼갤지, 한도를 넘을 때와 떠날 때의 경험을 어떻게 만들지가 구조의 핵심이었습니다.
아직 고민이 남아 있는 건, 운영자 입장에서 "내가 낸 돈의 값어치"를 어떤 지표로 보여줄 것인가입니다.

예약이 얼마나 들어왔고 노쇼가 얼마나 줄었는지를 보여줘야 요금제가 납득될 텐데, 그 지표를 무엇으로 잡을지는 계속 생각해 보려고 합니다.