SaaS 권한 관리, 어디까지 복잡하게 만들어야 할까?

B2B SaaS 만들다 보면 꼭 나오는 질문이 있다.

"관리자 권한 어떻게 나눌 거예요?"

처음엔 그냥 "관리자 / 일반 사용자" 이렇게 단순하게 가는데, 고객이 늘어나면 요구사항도 같이 복잡해진다. 이번에 권한 관리 쪽을 정리하면서 배운 내용을 기록해둔다.

---

권한 관리 복잡도 레벨

정리하다 보니 대충 4단계로 나눌 수 있었다.

레벨	방식	복잡도	유연성
1	고정 역할 (2-3개)	⭐	낮음
2	역할 확장 (5-6개)	⭐⭐	중간
3	커스텀 권한 조합	⭐⭐⭐	높음
4	리소스 기반 접근	⭐⭐⭐⭐	매우 높음

레벨 1-2: 그냥 역할 몇 개 정해두는 거

Admin, Manager, Viewer

MVP나 초기 제품은 이걸로 충분하다. 굳이 복잡하게 갈 필요 없음.

레벨 3: 권한을 조합하는 방식

여기서부터 본격적인 RBAC라고 부를 수 있다.

영업팀장 = [라이선스_조회, 라이선스_발급, 리포트_조회]

역할마다 권한을 다르게 조합할 수 있어서 고객별 커스터마이징이 가능해진다. 대부분의 B2B SaaS는 여기까지면 충분한 것 같다.

레벨 4: 리소스 단위로 제어

"영업팀 A는 고객사 X, Y, Z의 데이터만 접근 가능"

이건 진짜 복잡한 조직 구조가 있을 때만 필요하다. 관리 비용이 확 올라가니까 신중하게 결정해야 함.

---

용어 정리

공부하면서 헷갈렸던 용어들.

RBAC - 역할 기반. 제일 흔한 방식. 사용자한테 역할 주고, 역할에 권한 매핑.

ABAC - 속성 기반. "영업부서이고 + 근무시간이면 + 접근 허용" 이런 식으로 조건 조합.

ReBAC - 관계 기반. Google이 Zanzibar 논문에서 제안한 방식. GitHub이나 Google Docs가 이런 식으로 돌아간다고 함.

---

실제로 어떻게 쓰이나

• Jira: 프로젝트별로 역할이 다름
• GitHub: 레포지토리마다 Read/Write/Admin
• Salesforce: 영업 담당자별로 고객 할당

결국 다 비슷한 고민을 하고 있는 거다.

---

결론

솔직히 레벨 3까지만 해도 웬만한 요구사항은 다 커버된다.

레벨 4는 "우리 회사 영업팀이 지역별로 나뉘어 있고, 각 팀은 담당 고객만 봐야 해요" 같은 구체적인 요구가 있을 때 고민해도 늦지 않다.

YAGNI 원칙 - 필요 없는 거 미리 만들지 말자. 권한 시스템도 마찬가지.