ABAC이랑 RBAC은 접근제어를 설계할 때 많이 고민하게 되는 방식인데, 실제로는 둘 중 하나만 쓰기보다는 상황에 맞게 섞어서 사용하는 경우가 많습니다. RBAC은 역할 기반이라 개념이 단순해서 처음 설계할 때 이해하기 쉽고 운영도 비교적 편한 편입니다. 사용자에게 역할만 잘 붙여주면 권한이 자동으로 따라오니까 관리자, 일반 사용자, 운영자처럼 역할이 명확한 시스템에서는 꽤 효율적입니다. 다만 서비스가 커지고 조건이 복잡해질수록 역할이 계속 늘어나서 관리가 어려워지는 문제가 생길 수 있습니다. 예를 들어 같은 관리자라도 부서나 지역에 따라 접근 가능한 데이터가 달라지면 역할을 계속 쪼개야 하는 상황이 생깁니다.
ABAC은 이런 부분을 해결하기 위해 나온 방식이라고 보면 됩니다. 사용자, 리소스, 요청 환경 같은 다양한 속성을 기준으로 권한을 판단하기 때문에 훨씬 유연합니다. 나이, 부서, 직급, 소속 조직, 접속 시간, IP 같은 조건들을 조합해서 정책을 만들 수 있어서 복잡한 비즈니스 요구사항을 반영하기 좋습니다. 대신 처음 설계할 때 생각해야 할 게 많고, 정책이 늘어나면 어떤 조건에서 접근이 허용되는지 한눈에 파악하기 어려워질 수 있습니다. 잘못 설계하면 디버깅도 쉽지 않고 성능 이슈가 생길 수도 있습니다.
그래서 현실적인 접근은 RBAC을 기본 뼈대로 두고, RBAC으로 해결이 안 되는 부분만 ABAC으로 보완하는 방식입니다. 예를 들면 기본 메뉴나 기능 접근은 역할로 제어하고, 데이터 단위 접근이나 특정 조건이 붙는 경우만 속성 기반으로 처리하는 식입니다. 이렇게 하면 전체 구조는 단순하게 유지하면서도 필요한 만큼의 유연성을 확보할 수 있습니다. 실제로 많은 서비스들이 내부적으로는 역할 기반 구조를 쓰면서, 정책 엔진이나 조건 체크 로직을 추가해서 ABAC처럼 동작하게 만듭니다.
설계할 때 가장 중요한 건 이 시스템이 얼마나 복잡해질 가능성이 있는지를 미리 생각해보는 겁니다. 사용자 수가 적고 권한 구조가 단순하다면 RBAC만으로도 충분한 경우가 많고, 반대로 조직 구조가 자주 바뀌거나 조건에 따라 접근 범위가 달라지는 서비스라면 처음부터 ABAC을 염두에 두는 게 좋습니다. 무조건 최신 방식이나 복잡한 구조를 도입하기보다는, 운영하면서 관리할 수 있는 수준인지도 같이 고려하는 게 중요합니다. 접근제어는 한 번 복잡해지면 나중에 고치기 정말 힘들기 때문에, 처음부터 너무 과하게 설계하지 않는 것도 하나의 전략이라고 볼 수 있습니다.
ABAC(Attribute-Based Access Control)와 RBAC(Role-Based Access Control)는 접근제어를 구현할 때 가장 널리 사용되는 두 가지 모델이며, 시스템의 규모와 정책 복잡도에 따라 적절한 선택 또는 혼합 설계가 필요합니다. 본 문서는 두 모델의 개념적 차이와 설계 시 고려사항, 그리고 실무에서 적용 가능한 구조를 기술적인 관점에서 정리한 내용입니다.
RBAC은 사용자(User)에게 역할(Role)을 부여하고, 역할에 권한(Permission)을 매핑하는 구조를 가집니다. 일반적으로 User → Role → Permission 형태의 단순한 관계로 표현되며, 권한 판단 로직이 명확하고 성능상 이점이 큽니다. 구현 관점에서는 사용자 테이블, 역할 테이블, 권한 테이블과 이들 간의 매핑 테이블만으로도 충분히 구성할 수 있어 초기 구축 비용이 낮습니다. 또한 관리자가 권한을 운영할 때도 역할 단위로 제어가 가능해 운영 편의성이 높습니다.
하지만 RBAC은 역할 수가 증가할수록 관리 복잡도가 급격히 증가하는 한계를 가지고 있습니다. 부서, 지역, 프로젝트, 상태 값 등 다양한 조건이 권한에 영향을 미치기 시작하면 역할이 세분화되고, 결국 역할 폭발(Role Explosion) 문제가 발생할 수 있습니다. 이 경우 역할 변경이나 정책 수정이 전체 시스템에 영향을 미칠 가능성이 커지며, 유연한 정책 적용이 어려워집니다.
ABAC은 이러한 한계를 보완하기 위한 접근제어 모델로, 권한 판단 시 역할이 아닌 속성(Attribute)을 기반으로 정책을 평가합니다. 주요 속성은 사용자 속성(User Attributes), 리소스 속성(Resource Attributes), 환경 속성(Environment Attributes)으로 구분되며, 정책은 이 속성들의 조건식을 통해 정의됩니다. 예를 들어 “부서가 A이고, 근무 시간 내 접속이며, 요청 리소스의 소유 부서가 동일한 경우 허용”과 같은 정책이 가능합니다.
기술적으로 ABAC은 정책 엔진(Policy Engine)과 정책 저장소(Policy Store)를 중심으로 설계됩니다. 요청이 들어오면 PDP(Policy Decision Point)가 정책을 평가하고, PEP(Policy Enforcement Point)가 해당 결과를 실제 접근제어에 적용하는 구조를 가집니다. 이 방식은 매우 유연하지만, 정책 수가 많아질수록 관리 난이도가 높아지고 정책 충돌이나 우선순위 문제를 명확히 정의하지 않으면 예기치 않은 접근 허용 또는 차단이 발생할 수 있습니다.
실무에서는 RBAC과 ABAC을 완전히 분리해서 사용하기보다는 혼합 모델(Hybrid Model)을 채택하는 경우가 많습니다. 기본적인 기능 접근은 RBAC으로 처리하고, 데이터 단위 접근이나 조건부 제어가 필요한 경우에만 ABAC 정책을 적용하는 방식입니다. 예를 들어 “관리자” 역할을 가진 사용자만 특정 API에 접근할 수 있도록 RBAC으로 제한하고, 그 관리자 중에서도 “자신이 소속된 조직의 데이터만 조회 가능”과 같은 조건은 ABAC으로 처리하는 구조입니다.
이러한 혼합 설계를 적용할 경우, 권한 판단 흐름을 명확히 정의하는 것이 중요합니다. 일반적으로 1차적으로 RBAC 체크를 수행한 후, 통과한 요청에