🗒 [성장을 위한 데일리 아티클] '워크 프로세스' SaaS를 위한 권한체계 디자인하기 (feat.RBAC) SaaS 서비스에서는 다양한 유저가 하나의 프로젝트를 진행합니다. 따라서 프로덕트 디자이너는 다양한 유저가 효율적이고 연관성 있게 앱을 사용할 수 있도록 권한 시스템을 디자인해야 합니다. 1. 구조잡기: 유저와 역할 관리 권한관리에서 가장 유명한 모델은 Role-Based Access Control 입니다. '유저'를 '역할'단위로 묶고, '역할'의 권한을 매니징하는 모델입니다. 개별 유저가 가질 수 있는 옵션을 모두 나열(a.k.a Access-Control List)하지 않기 때문에, RBAC모델은 어드민의 시간을 매우 세이브할 수 있습니다. 그런데 제품이 점차 복잡해지고 하나의 고객사(회사 혹은 그룹)내의 유저가 많아지게 되면서, 각각의 유저에게 '역할'을 직접 부여하는 것은 시간이 많이 걸릴 뿐 아니라 관리하기 어려운 일이 됩니다. 여기서 '유저 그룹'이라는 개념이 생겼습니다. 기본적인 RBAC 모델에서 더 나아가, 유저를 '유저 그룹'으로 카테고라이즈하고 '유저 그룹'에 '역할'을 부여합니다. 2. 세분화하기: 권한 구조화하기 RBAC모델을 사용하여 '유저'와 '역할'의 권한 구조를 잡았다면, 그 다음으로 어떤 권한을 어디까지 세분화할 것인지를 결정해야 합니다. 권한은 보편적으로 3 단계로 나눌 수 있습니다. 1) 페이지 권한: 페이지나 기능에 접근하는 권한 2) 작업 권한: 페이지/기능 하위의 특정 액션에 접근하는 권한 3) 데이터 권한: 특정 데이터에 접근하는 권한 *데이터 권한은 작업 권한과 별개로, 독립적임. 대부분의 경우 페이지 권한과 작업 권한은 Yes/No이며, 데이터 권한의 옵션은 Add, Edit, Delete, Hide(권한없음) 입니다. 3. 사용편의성과 세분화의 밸런스 잡기 SaaS 솔루션이 성장함에 따라 필요한 권한이 세분화되면, 권한관리의 사용편의성도 하나의 과제가 됩니다. 사용자 온보딩을 긍정적 경험으로 만들기 위해 고려할 사항들이 있습니다. 1) 변경 불가 권한: 몇몇 권한은 백엔드에서 정의되어야 하며 유저가 변경할 수 없어야 합니다. 2) 기본 역할과 기본 권한: 기본 역할과 권한을 프리셋으로 지정하는 것은 유저의 시간을 많이 세이브할 수 있으며, 충분히 발생 가능한 주요 사고를 막을 수 있습니다. 3) 간결한 옵션: 유저 케이스를 고려하여 권한 옵션들을 간결하게 제공해야 합니다. 예를들어서 Add, Edit, Delete 권한은 Edit으로 묶일 수 있습니다. (백엔드에서는 모든 옵션을 그대로 유지하는게 확장성 측면에서 좋습니다.) 마치며. SaaS를 위한 권한을 디자인하는 것이 쉬운 일은 아니지만 솔루션의 사용사례를 분류하고, 솔루션 관리와 확장성에 대해 고민하는 것은 꼭 필요한 작업입니다. 이 아티클이 유저, 그룹, 역할, 다양한 레벨의 권한간의 관계를 이해하는데 도움이 되었기를 바랍니다. 권한이 사용자와 어떻게 연결되는지를 이해한 후에는 더 효과적이고 우아한 방식으로 권한을 디자인할 수 있습니다. --- 🔊 B2B 디자이너들의 모임 소개 B2B 프로덕트를 만들고 있는 B2B 디자이너들은 B2C 디자이너보다 더 어려운 문제를 풀고 있는 경우가 많은 데 비해 자료, 지식, 피드백을 찾는데도 어려움을 겪고 있습니다. 더 많은 B2B 프로덕트 디자이너들이 한자리에서 어려운 점, 배운 점을 공유하고 서로 도움이 되기 위해 커뮤니티를 운영중입니다. 🔗 B2B 디자이너들의 모임 노션 링크: https://www.b2b-designers.space