RBAC와 ABAC란 무엇인가
서비스가 커지면 ‘누가 무엇을 할 수 있는가’를 관리하는 일이 점점 복잡해진다. 이를 체계적으로 다루는 대표적인 두 가지 모델이 RBAC(Role-Based Access Control)와 ABAC(Attribute-Based Access Control)다.
RBAC는 사용자에게 ‘역할(Role)’을 부여하고, 그 역할에 권한을 매핑하는 방식이다. 예를 들어 ‘관리자’ 역할에는 ‘게시글 삭제’ 권한을, ‘일반회원’ 역할에는 ‘게시글 작성’ 권한만 부여하는 식이다. 회사 조직도를 떠올리면 이해하기 쉽다. 팀장, 사원, 인턴처럼 직급(역할)에 따라 결재 권한이 정해지는 것과 같은 구조다.
ABAC는 역할이 아니라 ‘속성(Attribute)’을 기준으로 권한을 판단한다. 사용자의 부서, 접속 시간, IP 위치, 요청 자원의 종류 등 다양한 속성을 조합해 실시간으로 접근 허용 여부를 결정한다. 예를 들어 ‘재무팀 소속이면서 사내 IP로 접속했고, 근무시간 내라면 급여 자료 열람 허용’과 같은 조건식이 ABAC의 전형적인 예다.
동작 원리와 예시로 보는 차이
RBAC는 구조가 단순하다. 사용자-역할-권한이라는 3단계 매핑만 있으면 된다. 코드로 표현하면 대략 아래와 같다.
if (user.role == 'admin') { allow('delete_post') }
반면 ABAC는 조건을 동적으로 평가한다.
if (user.department == 'finance' && request.time.isBusinessHours() && request.ip.isInternal()) { allow('view_salary') }
RBAC는 역할 개수가 적을 때는 관리가 쉽지만, 예외 상황이 많아지면 역할을 세분화해야 해서 ‘역할 폭발(Role Explosion)’ 문제가 생길 수 있다. ABAC는 세밀한 제어가 가능하지만, 정책 로직이 많아지면 어떤 조건에서 접근이 허용되는지 추적하기 어려워질 수 있다.
실무에서는 왜, 그리고 어떻게 쓰는가
대부분의 서비스는 RBAC로 시작한다. 구현이 단순하고 ‘관리자/일반회원’ 같은 기본 구조에 잘 맞기 때문이다. 스프링 시큐리티의 hasRole('ADMIN')이나 대부분의 CMS 권한 체계가 RBAC 기반이다.
하지만 서비스가 커지고 ‘같은 역할이라도 상황에 따라 다른 권한이 필요한’ 요구가 늘어나면 ABAC를 도입하거나 혼합 모델을 쓴다. 예를 들어 클라우드 서비스의 IAM 정책은 역할 기반이면서도 리소스 태그, 요청 시간, 소스 IP 같은 속성 조건을 함께 검사하는 경우가 많다.
- RBAC: 조직 구조가 명확하고 역할 수가 제한적인 경우에 적합
- ABAC: 세밀하고 동적인 접근 제어, 규제 준수(컴플라이언스)가 중요한 경우에 적합
결국 선택 기준은 ‘얼마나 세밀한 제어가 필요한가’와 ‘관리 복잡도를 감당할 수 있는가’의 균형이다. 작은 서비스라면 RBAC로 충분하지만, 금융이나 의료처럼 접근 조건이 복잡한 도메인이라면 ABAC 혹은 둘을 결합한 하이브리드 모델을 고려하는 것이 현실적이다.