역할 기반 접근 통제 (RBAC)

무엇인가

회사 건물에 들어갈 때 사원증을 댄다고 해보자. 인턴은 1층 카페에만, 직원은 자기 부서 사무실에, 임원은 모든 층에 들어갈 수 있다. 사원증 한 장에 권한이 모조리 박혀 있는 게 아니라, 그 사람이 맡은 역할에 따라 갈 수 있는 곳이 정해진다. 이렇게 "사람 → 역할 → 권한"의 순서로 접근을 통제하는 방식이 바로 역할 기반 접근 통제, 줄여서 RBAC다.

왜 필요한가

권한을 사람마다 따로 부여하면 관리가 금방 엉망이 된다. 100명에게 각자 다른 권한 조합을 일일이 설정한다고 생각해보라. 누가 입사하거나 퇴사할 때마다, 부서를 옮길 때마다, 모든 시스템에서 권한을 다시 만져야 한다. RBAC는 사람을 역할에 묶고 역할에 권한을 묶기 때문에, 새 직원이 들어오면 "마케팅 매니저" 역할만 부여하면 끝난다. 누군가 팀을 옮기면 역할만 갈아 끼우면 된다.

어떻게 작동하는가

세 가지 요소만 기억하면 된다.

• 사용자(User): 실제 사람 또는 시스템 계정.
• 역할(Role): "관리자", "편집자", "조회자" 같은 직무 단위.
• 권한(Permission): "문서 삭제", "결제 승인" 같은 구체 액션.

사용자는 하나 이상의 역할을 가질 수 있고, 역할은 여러 권한을 묶어 가진다. 누군가 어떤 작업을 시도하면 시스템은 "이 사람의 역할들이 이 권한을 포함하는가"만 확인한다.

AI 에이전트에서의 RBAC

[[workspace-agents]] 같은 팀용 AI 에이전트가 등장하면서 RBAC는 새로운 무게를 얻었다. 이제는 사람뿐 아니라 에이전트도 "무엇을 할 수 있는지"가 정해져야 한다. 누가 에이전트를 만들 수 있는지, 그 에이전트가 회사 메일을 읽거나 결제를 승인할 수 있는지, 다른 사람과 공유할 수 있는지가 모두 RBAC로 통제된다. 보안팀은 사람에게 권한을 주는 것보다 에이전트에 권한을 주는 일에 더 신중해야 한다 — 에이전트는 24시간 일하고, 실수해도 멈추지 않기 때문이다.

핵심 모델

RBAC는 세 개의 핵심 엔티티로 이루어진다.

• Users: 인증된 주체.
• Roles: 권한 묶음의 명명된 집합.
• Permissions: (객체, 작업) 쌍.

매핑은 보통 다대다다. 한 사용자가 여러 역할을 가질 수 있고, 한 역할이 여러 권한을 가질 수 있다. 권한 평가는 "사용자가 가진 역할들의 권한 합집합"으로 결정된다.

구현 패턴

대부분의 IAM 시스템(AWS IAM, Azure RBAC, Kubernetes RBAC, Google Cloud IAM)이 RBAC를 기본으로 채택한다. 실무에서는 다음 패턴을 자주 본다.

• 역할 계층(Role hierarchy): "관리자"가 "편집자"의 모든 권한을 자동 상속.
• 최소 권한 원칙(Least privilege): 기본 역할은 가장 좁은 권한만 갖고, 필요할 때 임시 권한을 부여.
• 역할 분리(Separation of duties): 결제 요청자와 승인자가 같은 역할이 될 수 없게 강제.
• 속성 기반 보강(ABAC hybrid): 역할에 더해 시간·위치·리소스 태그 같은 속성으로 추가 조건 적용.

워크스페이스 에이전트에서의 적용

[[workspace-agents]] 같은 팀 단위 AI 에이전트 시스템에서는 RBAC가 두 축으로 작동한다.

• 사용자 측: 누가 에이전트를 만들고, 수정하고, 조직 내에서 공유할 수 있는가.
• 에이전트 측: 그 에이전트가 어떤 도구(메일, 캘린더, 코드 저장소)에 접근할 수 있고, 어떤 액션을 자동 수행할 수 있는가.

OpenAI는 이를 위해 어드민 콘솔에서 에이전트 생성 권한, 도구 사용 범위, 외부 API 호출 권한을 분리해 관리하게 한다. 결제·CRM 같은 민감 도구에 닿는 에이전트는 [[guardian-agent]]나 [[chronicle]] 같은 추가 감사 계층과 결합해 운영하는 것이 일반적이다.

흔한 실수

• 역할 폭발(Role explosion): "마케팅매니저_A팀_북미_프리미엄" 식으로 세분화하다 보면 역할 수가 사용자 수를 넘는다. 속성 기반 모델로 부분 위임하는 편이 낫다.
• 권한 회수 누락: 역할에서 사용자를 빼는 절차가 없으면 퇴사자 권한이 살아남는다.
• 에이전트 권한을 사람 권한과 동일시: 에이전트는 24/7 작동하므로 같은 권한이라도 사람보다 더 좁게 줘야 한다.

모델의 기원

RBAC는 1992년 Ferraiolo와 Kuhn(NIST)이 제안한 모델로, 이후 NIST RBAC 표준(ANSI INCITS 359-2004)으로 정형화됐다. Sandhu 등의 RBAC96 프레임워크와 합쳐 오늘날 학술·산업 양쪽의 표준 어휘를 제공한다.

표준은 네 단계로 나뉜다.

• Core RBAC (RBAC0): Users, Roles, Permissions, Sessions의 기본 관계.
• Hierarchical RBAC (RBAC1): 역할 간 일반화/특수화 관계 추가.
• Constrained RBAC (RBAC2): 정적·동적 직무 분리(SoD) 제약.
• Symmetric RBAC (RBAC3): RBAC1 + RBAC2 결합.

형식적 정의

핵심 관계는 다음과 같이 표현된다.

• UA ⊆ Users × Roles (사용자-역할 할당)
• PA ⊆ Permissions × Roles (권한-역할 할당)
• assigned_users(r) = { u | (u, r) ∈ UA }
• authorized_permissions(r) = { p | (p, r) ∈ PA }

세션 s는 한 사용자와 그 사용자의 역할 부분집합 roles(s) ⊆ assigned_roles(user(s))을 연결한다. 권한 검사는 authorized_permissions(roles(s))의 합집합 멤버십 판정으로 환원된다.

ABAC, ReBAC와의 관계

RBAC의 본질적 한계는 컨텍스트 표현력이다. 시간, 위치, 리소스 속성 같은 동적 조건을 다루려면 별도 정책 언어가 필요하다. 이를 보완하는 것이 ABAC(Attribute-Based Access Control)와 ReBAC(Relationship-Based Access Control, 예: Google Zanzibar)다. 실제 시스템은 보통 RBAC를 골격으로 두고 ABAC 정책을 덧대는 하이브리드 형태를 취한다.

에이전트 시스템에서의 확장

LLM 기반 [[workspace-agents]] 같은 자율 에이전트가 등장하면서 RBAC 모델은 두 가지 새로운 도전에 직면한다.

첫째, 에이전트 정체성의 분리다. 에이전트는 사용자의 위임된 권한으로 작동하지만, 에이전트 자체도 독립된 주체로 볼 필요가 있다. 같은 사용자가 만든 두 에이전트가 서로 다른 권한 풀을 가져야 하기 때문이다. 이는 OAuth의 위임 모델, Google Cloud의 service account impersonation과 유사한 구조로 다뤄진다.

둘째, 액션 공간의 비결정성이다. 전통적 RBAC는 (객체, 작업) 쌍이 유한하고 사전 정의된다고 가정한다. 그러나 LLM 에이전트는 도구 조합을 통해 원래 권한 모델이 예측하지 못한 행동을 생성할 수 있다. 이 때문에 [[constitutional-ai]] 같은 행동 제약 계층, [[guardian-agent]] 같은 런타임 검증 계층, [[chronicle]] 같은 감사 로그 계층이 RBAC와 결합돼 다층 방어를 구성한다.

한계와 연구 방향

• 역할 폭발(Role explosion): 조직 규모가 커지면 역할 수가 비선형으로 증가한다. Role mining 기법으로 사후 정규화를 시도하지만 근본 해결은 아니다.
• 권한 변화의 동적성: 정적 매핑은 빠르게 변하는 프로젝트 단위 권한에 부적합하다. 임시 권한 위임 모델(Just-In-Time access)이 활발히 연구된다.
• 에이전트 행동 검증: 에이전트가 권한 내에서도 의도와 다른 행동을 할 수 있다는 점에서, RBAC만으로는 안전성을 보장할 수 없다. 정책 모델(policy model)과 행동 모니터링(behavioral monitoring)의 결합이 향후 표준이 될 가능성이 높다.

이 용어를 언급한 기사

• 워크스페이스 에이전트와 Codex 업데이트, 컴퓨터 작업의 새 인터페이스로