권한 모델 기획, 테넌트 관리자·직원·고객의 역할 나누기

 

예약 시스템에는 생각보다 다양한 종류의 사람이 들어옵니다.
업장을 운영하는 사장님, 현장에서 일하는 직원, 예약하는 고객, 그리고 서비스 전체를 관리하는 플랫폼 운영자까지요.
이들이 한 시스템을 같이 쓰기 때문에 "누가 무엇을 볼 수 있고, 무엇을 바꿀 수 있는가"를 정리하는 권한 모델이 꼭 필요해집니다.
기획 초반에는 "사장님은 다 되고 직원은 일부만 되고"처럼 감으로 정리하기 쉬운데, 막상 화면과 데이터를 하나씩 따져보면 이야기가 복잡해져요.
이번 글은 권한 모델을 기획하면서 제가 정리해 본 순서를 기록한 것입니다.

 

권한을 사람마다 하나하나 부여하면 관리가 금방 무너집니다.
그래서 많은 서비스가 쓰는 방식이 역할 기반 접근 제어, 줄여서 RBAC예요.
사람에게 직접 권한을 주는 대신 "역할"을 만들고, 역할에 권한을 묶고, 사람에게는 역할을 부여합니다.

가상의 예시로 업장 안의 역할을 이렇게 나눠 보겠습니다.
관리자는 업장 설정, 요금제, 직원 관리, 모든 예약을 다룹니다.
매니저는 예약과 고객 정보는 볼 수 있지만 요금제나 결제 설정은 건드리지 못합니다.
직원은 본인에게 배정된 예약만 보고, 방문 처리를 할 수 있습니다.
고객은 본인의 예약만 보고 변경하거나 취소할 수 있습니다.
이렇게 말로 써 보면 단순한데, 이걸 기능과 데이터로 풀어내는 단계가 진짜 작업이었어요.

 

권한을 "관리자냐 아니냐"로만 나누면 금방 한계에 부딪혀서, 저는 세 층으로 나눠 따져봤습니다.

 

첫째는 화면 권한입니다.
이 메뉴가 보이는가, 이 화면에 들어갈 수 있는가의 문제예요.
직원에게는 요금제 설정 메뉴 자체가 보이지 않아야 합니다.

둘째는 기능 권한입니다.
화면이 보여도 버튼을 누를 수 있는지는 다른 문제입니다.
예를 들어 직원이 예약 목록은 볼 수 있어도 예약 삭제나 환불은 못 하게 막는 경우가 그렇습니다.
화면을 숨기는 것만으로는 부족하고, 서버에서도 같은 규칙을 검사해야 한다는 점을 개발자와 꼭 맞춰 둬야 해요.
메뉴만 숨겨 두면 주소를 직접 입력해서 들어올 수 있기 때문입니다.

셋째는 데이터 범위 권한입니다.
가장 놓치기 쉬운 층이에요.
같은 "예약 조회" 기능이라도 관리자는 업장 전체 예약을, 직원은 본인 예약만, 고객은 본인이 만든 예약만 봐야 합니다.
기능은 같고 범위가 다른 것이죠.

기획서에서 "예약 조회: 관리자 전체, 직원 본인 담당, 고객 본인"처럼 범위를 같이 적는 습관을 들이니 오해가 많이 줄었습니다.

 

테넌트 구조에서 특히 까다로웠던 건 한 사람이 여러 곳에 속하는 상황이에요.
가상의 예를 들어볼게요.
한 디자이너가 월·화·수는 A 미용실에서, 목·금은 B 미용실에서 일한다고 해보겠습니다.
이 사람은 같은 계정으로 두 업장에 들어갈 수 있어야 할까요.

저는 "사람(계정)"과 "업장 내 역할(멤버십)"을 분리하는 구조가 자연스럽다고 생각했습니다.
계정은 하나이고, 업장마다 멤버십이 따로 있어서 A에서는 직원, B에서는 매니저일 수도 있습니다.
로그인 후 "어느 업장으로 들어갈까요?"를 고르는 단계가 필요해지고, 화면 위쪽에 현재 업장을 항상 표시해야 혼동이 없어요.

이때 중요한 원칙은 테넌트 경계입니다.
A 업장의 역할로 B 업장의 데이터를 보는 일은 절대 없어야 해요.
A의 예약 정보를 B에서 볼 수 있다면 업장 입장에서는 심각한 정보 유출이니까요.
그래서 모든 데이터 조회에는 "어느 업장의 맥락인가"가 따라붙어야 한다고 개발자와 확인했습니다.

고객도 마찬가지입니다.
한 고객이 여러 업장에서 예약하면, 업장은 서로의 고객 정보를 공유하지 않아야 합니다.
고객 계정이 하나여도 업장 입장에서 보이는 정보는 "우리 업장에서의 이력"으로 한정하는 것이 안전하다고 봤어요.

 

권한을 정리할 때 가장 도움이 됐던 도구는 표입니다.
가로에는 역할(관리자, 매니저, 직원, 고객)을, 세로에는 기능(예약 조회, 예약 생성, 예약 취소, 고객 정보 보기, 매출 보기, 직원 초대, 요금제 변경 등)을 놓아요.
각 칸에는 "가능", "불가", "본인 것만", "배정된 것만"처럼 범위가 드러나는 말을 적습니다.

표를 만들다 보면 흥미로운 일이 생깁니다.
빈칸이나 애매한 칸이 곧 아직 결정하지 않은 정책이라는 점이에요.
예를 들어 "직원이 고객의 연락처를 볼 수 있는가"를 적으려다 멈추게 되고, 이건 개인정보 노출 범위의 결정이라 운영자와 이야기해 봐야 할 사안이 됩니다.
표를 채우는 과정 자체가 질문 목록을 만들어주는 셈이에요.

표에 적을 때 몇 가지 규칙을 정했습니다.
기능은 사용자가 이해하는 이름이 아니라 "동작 단위"로 적습니다.
역할은 처음엔 적게 시작하고, 필요가 분명해질 때 늘립니다.
마지막으로, 관리자가 한 명도 없는 상태를 만들지 않는 규칙을 둡니다.
업장의 유일한 관리자가 스스로 역할을 낮추거나 탈퇴하면 아무도 설정을 못 바꾸는 상태가 되니까요.

 

운영하시는 분들은 가끔 "우리 매장은 이 직원만 매출을 보게 해주세요"처럼 세세한 요구를 합니다.
처음부터 권한을 하나하나 조합해 새 역할을 만들 수 있게 하면 자유롭지만, 설정이 어려워지고 실수가 늘어요.
저는 처음에는 미리 정의한 역할 서너 개로 시작하고, 요구가 반복해서 나오는 부분만 선택 항목으로 열어주는 쪽이 좋다고 정리했습니다.
권한 설계는 한번 열면 닫기 어려워서, 좁게 시작해서 넓히는 방향이 안전하다고 생각해요.

 

권한 모델은 화려한 기능은 아니지만, 빠뜨리면 사고로 이어지는 영역이라고 느꼈습니다.
특히 화면, 기능, 데이터 범위를 나눠서 생각하는 것, 계정과 업장 내 역할을 분리하는 것, 테넌트 경계를 항상 의식하는 것 세 가지가 가장 큰 수확이었어요.
아직 정리하지 못한 질문은, 직원이 퇴사했을 때 그 사람이 담당하던 예약과 기록을 어떻게 이어받을지입니다.
계정은 비활성화하되 기록은 남겨야 하는데, 담당자를 누구로 바꿀지까지 정하려면 운영 흐름을 더 들어봐야 할 것 같아요.