어드민을 만든다면,
권한부터 설계하자
RBAC와 ABAC, 초기에 결정해야 하는 구조
이전에 브런치에서 어드민 설계를 위한 2차 인증과 권한에 대한 글을 작성한 적 있다. (링크 : https://brunch.co.kr/@144ce42dff304dd/29)
그때 상세하게 설명하지 않았던 '권한'에 초점을 맞추어 상세하게 작성해보려 한다.
초기에 잘못 잡히면 평생 빚이 되는 영역
서비스를 만들다 보면 생각보다 빨리 ‘어드민(백오피스, 파트너스)’이 필요해진다.
그리고 어드민을 만들면 반드시 따라오는 고민이 있다. 바로 계정별 권한을 어디까지 허용할 것인가다.
처음엔 간단히 생각한다. “마스터, 에디터, 뷰어 정도만 구분하면 되지 않을까?”
하지만 서비스가 조금만 커지면, 이 단순한 3단계 역할로는 더 이상 해결이 되지 않는다.
그 이유는 어드민의 기능이 단순 조회를 넘어 설정, 정책, 콘텐츠, 병원별 커스터마이징, 로그 확인, 사용자 정보 접근까지 확장되기 때문이다. 서비스가 성장할수록 권한 체계는 기하급수적으로 복잡해진다.
그래서 어드민 기획은 기능 기획보다 “권한 설계”가 먼저다. 그리고 이 선택은 한 번 정하면 수정을 거의 못 한다. (수정할 수 있어도 개발/QA/운영 비용이 상상 이상으로 커진다.)
RBAC와 ABAC, 기획자가 꼭 구분해야 하는 두 가지 방식
어드민 권한 설계는 크게 RBAC과 ABAC 방식으로 나뉜다.
처음엔 비슷해 보이지만, 실제로는 완전히 다른 세계다.
1) RBAC(Role-Based Access Control)
“역할 중심 권한 제어”
RBAC는 우리가 흔히 말하는
마스터 / 매니저 / 뷰어 같은 역할별로 권한을 묶어두는 방식이다.
마스터 → 모든 메뉴 접근 가능
매니저 → 특정 메뉴 편집 가능
뷰어 → 조회만 가능
심플하고 빠르다.
MVP에서 많이 쓰는 이유도 그래서다.
하지만 문제는 이거다.
서비스가 커질수록 ‘역할(Role)’이 끝없이 추가된다.
기관 A는 “계약금액은 못 보지만 콘텐츠는 편집 가능한 ‘특별 매니저’”가 필요하고,
쇼핑몰 B는 “고객 정보 열람은 되지만 정책 수정은 불가한 ‘조회+부분편집 매니저’”를 원하고,
제조업 C는 “API키만 관리하는 전용 계정”을 요구한다.
결국 역할이 마스터 / 매니저 / 뷰어
→ 마스터 / 콘텐츠-매니저 / 정책-매니저 / 시스템-전용-매니저 / …
이런 식으로 눈덩이처럼 늘어난다.
역할이 늘어날수록 개발·QA·운영은 끝없이 복잡해진다.
2) ABAC(Attribute-Based Access Control)
“속성 중심 권한 제어”
→ 리소스, 액션, 속성을 조합해 ‘허용 규칙’을 만드는 구조
ABAC는 역할을 고정적으로 정의하지 않는다.
대신 주체(Actor)/ 리소스(Resource)/ 액션(Action)/ 조건(Condition)을 조합해 권한을 만든다.
예를 들면 이런 식이다.
Actor: 병원 A의 콘텐츠 담당자
Resource: 콘텐츠 관리 메뉴
Action: 수정
Condition: 병원 A 소속이며, 콘텐츠 리소스 타입 = 병원전용
이렇게 조합하면 “병원 A의 콘텐츠 담당자는 자기 병원의 콘텐츠만 수정 가능”이라는 규칙이 자연스럽게 만들어진다. 이 방식의 장점은…
무한한 경우의 수를 ‘규칙(Policy)’로 해결할 수 있다.
그래서 서비스가 커져도 역할 개수는 늘어나지 않는다.
하지만 단점도 확실하다.
기획·개발 난이도가 RBAC보다 훨씬 높다.
초기에 구조를 명확히 잡아야 한다.
정책 UI를 어떻게 보여줄지까지 기획자가 설계해야 한다.
즉, 장기적으로는 ABAC가 유리하지만, 초기에 설계 시간을 반드시 투자해야 한다.
어드민 기획자라면, 이 질문부터 해야 한다
어드민 권한은 ‘지금 어떻게 만들지?’보다
‘나중에 어떤 세계까지 가야 하는가?’가 더 중요하다.
기획 단계에서 아래 6가지만 정리해도 방향성이 명확해진다.
1. 사용 주체 타입이 몇 가지인가?
(예: 병원 마스터, 병원 직원, 파트너 운영자, 내부 운영자 등)
2. 메뉴/리소스 구조는 얼마나 세분화되는가?
(정책/ 콘텐츠 /알림톡 /데이터 /API키 /사용자 정보 등)
3. 권한이 기능 단위인가, 액션 단위인가?
- 기능 단위: 콘텐츠 메뉴 접근 가능
- 액션 단위: 콘텐츠 보기/쓰기/삭제/배포 권한 각각 구분
4. 병원마다 다른 정책을 적용해야 하는가?
(파트너스는 병원 단위 커스터마이징이 많음)
5. 미래에 외부 파트너가 들어올 가능성이 있는가?
6. MVP에서 어디까지 허용하고, 확장 시 어떤 구조로 갈 것인가?
이걸 선명하게 정의하지 않으면,
MVP 이후에 반드시 “권한 다시 뜯어고치기”라는 지옥을 경험한다.
실제 실무에서 느낀 핵심 팁
1) MVP라도 최종 목표 권한 구조는 먼저 정해라
구현은 간단하게 하더라도,
‘결국 어떤 방식(RBAC → ABAC)으로 갈지’는 미리 결정해두어야 한다.
2) 메뉴 구조를 먼저 설계하고 권한을 붙여라
권한만 먼저 설계하면 나중에 메뉴/리소스 변경 때마다 구조가 흔들린다.
3) “조회 권한”은 생각보다 위험하다
조회만 된다고 해서 안전한 것이 아니다.
금융, 병원 등 민감한 데이터가 많은 경우, 조회가 가장 큰 리스크다.
4) 기관·파트너마다 다른 권한 요구가 반드시 들어온다
“한 파트너의 요구”는 곧 “모든 파트너의 요구”가 된다.
5) UI에서 ‘권한 편집’은 절대 단순하게 보이지 않는다
권한 자체는 데이터 구조 문제이지만,
직접 편집하고 설정하도록 만들면 UI/UX 난이도가 폭발한다.
(MVP에서는 운영자가 직접 지정하는 방식을 추천)
Genspark가 만들어준 이미지어드민 권한 기획은 '기능 중 하나'가 아니다.
어드민의 뼈대라고 할 수 있기 때문에 안정적으로 설계하는 것이 중요하다.
많은 기획자들이 “일단 간단하게 만들어보고 나중에 정교하게 바꾸자”라고 생각하지만,
어드민 권한만큼은 처음에 어떻게 설계하느냐가 이후 1~2년의 운영 비용을 결정한다.
그래서 나는 어드민 기획을 시작할 때 누구에게 어떤 권한이 필요한 서비스인지 메모하고 O, X 표기하며 스케치를 시작하게 되는 것 같다.
* 오늘 글을 쓰는데 참고한 잘 정리된 글 : https://blog.logto.io/ko/rbac-and-abac
