관계 기반 접근제어(ReBAC)와 Google Zanzibar
1. 개요
정의: 관계 기반 접근제어(ReBAC, Relationship-Based Access Control)는 주체(사용자)와 객체(자원) 사이에 존재하는 "관계(relation)"를 권한 판단의 1차 근거로 삼는 인가 모델이며, Google Zanzibar는 이 모델을 전역 규모에서 일관되게 구현한 인가 시스템의 대표 설계다.
초기의 접근제어는 자원에 권한 목록을 직접 붙이는 ACL(Access Control List)에서 출발했고, 조직이 커지면서 역할에 권한을 묶는 RBAC(Role-Based Access Control)로 발전했다. RBAC는 "같은 일을 하는 사람은 같은 권한을 가진다"는 가정에서 잘 작동하지만, 현대의 협업 서비스는 "이 문서를 만든 사람", "이 폴더를 공유받은 사람", "이 조직의 구성원이면서 특정 프로젝트에 초대된 사람"처럼 자원과 사용자 사이의 구체적 관계로 권한이 정해지는 경우가 지배적이다. 이런 요구를 RBAC의 역할 수를 늘려서 표현하면 역할이 자원 수에 비례해 폭발하는 "역할 폭발(role explosion)" 문제가 발생한다.
ReBAC는 권한을 "사용자 U가 자원 R에 대해 관계 Rel을 가지는가?"라는 그래프 질의로 환원한다. 예컨대 "Alice가 문서 doc:readme 를 볼 수 있는가?"는 "Alice가 doc:readme 의 viewer 인가, 혹은 editor·owner 이거나, doc:readme 가 속한 폴더의 viewer 인가?"라는 관계 탐색으로 바뀐다. 이 관점은 Google Drive·GitHub·Slack처럼 수억 사용자와 수십억 객체를 다루는 서비스에서 세밀한 권한(fine-grained authorization)을 자연스럽게 모델링한다.
ReBAC가 주목받는 또 다른 이유는 인가 로직의 외부화·중앙화 흐름과 맞닿아 있기 때문이다. 과거에는 각 애플리케이션이 권한 판단을 내부에 흩뿌려 구현했으나, 마이크로서비스가 늘면서 동일한 권한 질문을 서비스마다 중복 구현하고 서로 다르게 해석하는 불일치가 커졌다. 권한 모델과 데이터를 하나의 전용 서비스로 모으고 각 서비스가 Check API만 호출하게 하면, 정책의 일관성·감사·변경 관리가 한곳으로 수렴한다. ReBAC는 이 중앙 인가 서비스가 다루기에 적합한 통일된 데이터 모델(관계 튜플)을 제공한다는 점에서 구조적 이점이 있다.
Google은 2019년 USENIX ATC 논문에서 Zanzibar를 공개했다. Zanzibar는 Google Drive, Calendar, Cloud, YouTube, Photos 등 다수 서비스의 인가를 담당하며, 논문 기준 수조(trillions) 개의 관계 튜플과 초당 수백만 건의 권한 검사를 다루면서도 95퍼센타일 지연 10ms 미만, 가용성 99.999% 이상을 달성했다고 보고한다. 이 주제의 핵심은 단순히 "관계로 권한을 본다"는 개념이 아니라, 전역 분산 환경에서 정확성(특히 권한 회수의 일관성)과 저지연을 동시에 만족시키는 설계 기법에 있다. 기술사 답안에서는 모델·데이터 구조·일관성 메커니즘·운영 트레이드오프를 함께 다루어야 한다.
2. 접근제어 모델의 진화와 ReBAC의 위치
2.1 ACL → RBAC → ABAC → ReBAC
접근제어 모델은 "권한을 무엇에 결합하는가"에 따라 구분된다. ACL은 자원마다 (주체, 허용동작) 쌍을 나열한다. 표현은 직관적이지만 사용자가 늘면 관리가 어렵고, "이 사용자가 접근 가능한 모든 자원"을 묻는 역방향 질의가 비싸다. RBAC는 사용자-역할-권한의 3계층으로 관리 부담을 줄였으나, 자원별로 달라지는 세밀한 공유를 표현하기 어렵다.
ABAC(Attribute-Based Access Control)는 사용자·자원·환경의 속성과 정책 규칙(예: "부서=재무 AND 시간=업무시간")으로 유연성을 확보하지만, 정책이 복잡해지면 "왜 이 권한이 허용/거부되었는가"를 추적하기 어렵고 대규모 질의 성능을 보장하기 까다롭다. ReBAC는 권한을 관계 그래프의 도달 가능성(reachability) 문제로 환원하여, 세밀함과 설명가능성을 함께 얻는다. 실무에서는 ReBAC를 기본 골격으로 두고 ABAC식 조건(contextual tuple, caveat)을 보강하는 하이브리드가 늘고 있다.
| 모델 | 권한 결합 대상 | 강점 | 한계 |
|---|---|---|---|
| ACL | 자원별 주체 목록 | 직관적, 세밀 | 역방향 질의·대규모 관리 난이도 |
| RBAC | 역할 | 관리 단순, 조직 매핑 용이 | 역할 폭발, 자원별 공유 표현 곤란 |
| ABAC | 속성·정책식 | 유연, 동적 조건 | 디버깅·성능·일관성 보장 난이도 |
| ReBAC | 객체 간 관계 그래프 | 세밀+설명가능, 계층 상속 | 그래프 탐색 비용, 구현 복잡 |
이 비교에서 중요한 것은 모델의 우열이 아니라 적용 맥락이다. 조직 구조 중심의 전사 권한은 RBAC가, 규제 기반의 동적 판단은 ABAC가, 공유·협업 중심의 제품 권한은 ReBAC가 유리하다. Zanzibar는 ReBAC를 중심에 두되 그룹 멤버십으로 RBAC를, 조건부 튜플로 ABAC 요소를 흡수한 설계로 볼 수 있다.
2.2 관계 튜플이라는 데이터 모델
Zanzibar의 모든 권한은 관계 튜플(relation tuple) 하나의 형태로 저장된다. 표기는 ⟨object⟩#⟨relation⟩@⟨user⟩ 이며, 예를 들어 doc:readme#viewer@user:alice 는 "readme 문서의 viewer 는 alice"를 뜻한다. 사용자 자리에는 개별 사용자뿐 아니라 다른 집합을 가리키는 userset이 올 수 있다. doc:readme#viewer@group:eng#member 는 "eng 그룹의 member 전원이 readme 의 viewer"라는 관계를 하나의 튜플로 표현한다.
이 "userset rewrite" 능력이 ReBAC의 표현력을 만든다. 그룹 멤버십, 폴더 상속, 역할 계층이 모두 "관계가 다른 관계를 참조"하는 형태로 통일되기 때문이다. 권한 검사는 결국 이 튜플들이 이루는 유향 그래프에서 "사용자 노드가 (객체, 관계) 노드에 도달 가능한가"를 탐색하는 문제가 된다. 튜플은 단순한 행(row)이므로 수평 확장이 쉽고, 관계의 추가·삭제가 곧 권한의 부여·회수가 된다는 점에서 감사(audit)에도 유리하다.
2.3 역할 폭발의 구체적 예시
역할 폭발이 왜 치명적인지는 수치로 보면 분명하다. 1만 개의 프로젝트가 있고 각 프로젝트마다 viewer·editor·admin 세 수준의 접근이 필요한 협업 도구를 가정하자. RBAC로 이를 표현하려면 project-1-viewer, project-1-editor … 처럼 프로젝트 수 × 권한 수 = 3만 개의 역할이 필요하고, 프로젝트가 10만 개로 늘면 역할은 30만 개가 된다. 역할 자체가 자원 수에 비례해 증가하므로 역할 디렉터리의 관리·검색·감사가 모두 붕괴한다.
ReBAC는 같은 요구를 project:123#editor@user:alice 같은 튜플 하나로 표현한다. 역할이라는 중간 개념을 자원별로 복제하지 않고, 자원과 사용자의 관계를 직접 기술하기 때문이다. 상속이 필요하면 project:123#viewer: editor or admin 처럼 네임스페이스 규칙으로 한 번만 선언하면 모든 프로젝트에 적용된다. 이처럼 "선언은 한 번, 데이터는 관계로"라는 분리가 대규모 세밀 인가에서 ReBAC가 선택되는 가장 실질적인 이유다.
3. Zanzibar 아키텍처와 동작 원리
flowchart LR
App["클라이언트 서비스(Drive 등)"] -->|"Check/Read/Write/Expand"| ACL["aclserver(권한 검사)"]
ACL -->|"관계 튜플 조회"| SP["Spanner(전역 분산 DB)"]
ACL -->|"캐시 조회"| LH["Leopard(집합 인덱스)"]
SP -->|"변경 로그 스트림"| LH
App -->|"읽기 시 content version"| ACL
ACL -->|"zookie(일관성 토큰) 반환"| App
SP -->|"TrueTime 타임스탬프"| ACL
위 구조에서 클라이언트 서비스는 자신의 권한 정책을 Zanzibar에 네임스페이스 구성(namespace config)으로 등록하고, 실제 권한 변경은 Write로 튜플을 넣거나 빼며, 권한 판단은 Check API로 질의한다. 핵심 API는 네 가지다. Check("U가 R에 대해 관계를 갖는가")는 허용/거부를 돌려주고, Read는 저장된 튜플을 그대로 조회하며, Expand는 특정 (객체, 관계)의 전체 사용자 집합을 트리로 펼쳐 디버깅·권한 열람에 쓰이고, Write는 튜플을 변경한다.
저장 계층은 Google Spanner다. Spanner의 외부 일관성(external consistency)과 TrueTime 전역 시계 덕분에 모든 튜플 변경에 전역적으로 비교 가능한 타임스탬프를 붙일 수 있다. 이 타임스탬프가 뒤에서 설명할 일관성 토큰(zookie)의 토대가 된다. 권한 검사는 읽기 부하가 압도적이므로, 자주 묻는 (객체, 관계) 집합은 Leopard라는 별도 집합 인덱스 시스템이 비동기로 구체화(materialize)해 깊은 그룹 중첩의 탐색 비용을 낮춘다.
3.1 권한 검사 평가 과정
sequenceDiagram
participant C as 클라이언트
participant A as aclserver
participant S as Spanner
C->>A: "Check(doc:readme#viewer@alice, zookie)"
A->>A: "네임스페이스 규칙 해석(viewer = viewer ∪ editor ∪ parent.viewer)"
A->>S: "doc:readme#viewer 튜플 조회"
S-->>A: "editor@alice 없음, parent=folder:eng"
A->>S: "folder:eng#viewer 조회(재귀)"
S-->>A: "group:eng#member@alice 매칭"
A-->>C: "허용(allowed), 평가 결과 캐시"
권한 검사는 네임스페이스 구성에 정의된 규칙을 따라 관계를 전개한다. 예를 들어 "viewer 는 editor 를 포함하고, 상위 폴더의 viewer 를 상속한다"는 규칙이 있으면, doc:readme#viewer 검사는 직접 튜플 → editor 튜플 → 상위 폴더 viewer 로 이어지는 유향 그래프 탐색으로 수행된다. 이 과정은 깊이가 깊어질 수 있으므로 Zanzibar는 하위 질의를 병렬화하고, 자주 쓰는 중간 결과를 캐시하며, 인기 있는 객체로 몰리는 "핫스팟"을 완화하기 위해 요청 중복 제거와 캐시 키 샤딩을 적용한다.
평가 결과의 정확성을 해치지 않으면서 깊은 중첩을 빠르게 처리하기 위해, Zanzibar는 각 하위 문제를 독립적으로 캐시 가능한 단위로 쪼갠다. 예컨대 group:eng#member 의 구성원 집합은 여러 문서 검사에서 반복 참조되므로 한 번 계산해 재사용한다. 또한 동일한 (객체, 관계, 사용자) 질의가 짧은 시간에 쏟아지면(예: 인기 공개 문서) 중복 요청을 한 번만 평가하도록 합치는 "request hedging·deduplication"으로 백엔드 부하를 줄인다.
3.3 Leopard 인덱스와 깊은 그룹 중첩
그룹이 그룹을 포함하는 깊은 중첩(예: "전사 그룹 ⊃ 부문 그룹 ⊃ 팀 그룹 ⊃ 개인")은 매 검사마다 재귀 탐색을 유발해 지연의 원인이 된다. Zanzibar는 이런 집합 관계를 Leopard라는 별도 인덱싱 시스템으로 비동기 구체화한다. Leopard는 Spanner의 변경 로그를 구독해 "특정 그룹의 전이적(transitive) 구성원 집합"을 미리 펼쳐 저장하고, 이를 압축된 skip-list 형태로 제공하여 깊은 멤버십 질의를 상수에 가까운 비용으로 응답한다.
이 설계의 교훈은 "읽기와 쓰기의 데이터 구조를 분리"하는 전형적 CQRS식 접근이다. 권한 쓰기는 정규화된 튜플로 단순하게 유지하되, 읽기 성능이 중요한 집합 질의는 별도의 구체화 뷰(materialized view)로 가속한다. 다만 구체화는 비동기이므로 짧은 전파 지연이 생길 수 있고, 이 지연이 정확성에 영향을 주지 않도록 앞서 설명한 zookie 기반 스냅샷 하한과 결합해 운영한다.
3.2 일관성과 zookie — "신규 권한 적용"과 "회수 즉시성"의 균형
인가 시스템에서 가장 위험한 오류는 권한 회수가 늦게 반영되는 것이다. 캐시 때문에 이미 공유를 해제한 문서를 여전히 볼 수 있다면 심각한 정보 유출이다. 반대로 모든 검사를 항상 최신 데이터로 강한 일관성으로 수행하면 지연과 비용이 폭증한다. Zanzibar는 이 긴장을 zookie라는 일관성 토큰으로 해결한다.
클라이언트가 콘텐츠를 저장할 때 Zanzibar가 발급한 zookie(내부적으로 Spanner 타임스탬프)를 함께 보관한다. 이후 그 콘텐츠에 대한 Check는 zookie가 가리키는 시점 이상의 스냅샷에서 평가하도록 보장한다. 이로써 "콘텐츠 변경보다 오래된 ACL로 판단하는" 역전을 막아 new-enemy 문제(권한 회수 뒤 새로 추가된 콘텐츠가 옛 권한으로 노출되거나, 공유가 바뀌었는데 옛 순서로 판단되는 오류)를 방지한다. 평상시 Check는 약간 과거의 일관된 스냅샷을 사용해 캐시 적중률을 높이고 지연을 낮추되, 정확성이 필요한 지점은 zookie로 하한을 건다. 이는 "항상 최신"이 아니라 "필요한 만큼의 최신"을 설계로 보장하는 전형적 사례다.
new-enemy 문제를 구체적으로 보면 두 가지 시나리오가 있다. 첫째, Alice가 Bob을 문서에서 제거한 직후 비밀 내용을 추가했는데, 권한 검사가 제거 이전 스냅샷으로 평가되면 Bob이 새 내용을 보게 된다. 둘째, Alice가 Bob의 권한을 올리고 곧바로 민감 문서를 그 폴더로 옮겼는데, 두 변경의 순서가 뒤바뀌어 평가되면 의도와 다른 노출이 생긴다. zookie는 "콘텐츠의 현재 상태를 만든 ACL 시점 이상"을 강제함으로써 이런 순서 역전을 원천 차단한다. 즉 성능을 위한 캐시·스냅샷 최적화가 권한 회수의 안전성을 결코 희생하지 않도록 하는 것이 핵심이다.
4. 구현 생태계와 비교
Zanzibar는 논문으로만 공개되었으므로 오픈소스·상용 구현이 생태계를 이룬다. 대표적으로 CNCF 샌드박스의 OpenFGA(Auth0/Okta 주도), SpiceDB(AuthZed), Ory Keto, 그리고 Auth0 FGA·AuthZed Cloud 같은 매니지드 서비스가 있다. 각 구현은 Zanzibar의 튜플·네임스페이스·Check/Expand 개념을 공유하되 일관성 모델과 운영 편의에서 차이가 있다.
| 구현 | 주도 | 특징 | 비고 |
|---|---|---|---|
| OpenFGA | Okta(Auth0) | DSL 기반 모델, CNCF 샌드박스 | 커뮤니티 활발, 다중 언어 SDK |
| SpiceDB | AuthZed | zookie 유사 ZedToken, caveat(조건부) 지원 | Zanzibar에 가장 충실, Postgres/Spanner 백엔드 |
| Ory Keto | Ory | Go 기반, Ory 생태계 통합 | 경량, 자체 호스팅 |
| Google Zanzibar | Google 내부 | 원본, Spanner+Leopard | 비공개(논문만 공개) |
구현 간 가장 중요한 실무 차이는 일관성 제어 방식이다. SpiceDB의 ZedToken, OpenFGA의 consistency 옵션처럼 zookie에 해당하는 메커니즘을 어떻게 노출하느냐가 애플리케이션 정확성을 좌우한다. 예컨대 금융 서비스의 결재선 변경처럼 회수 즉시성이 중요한 경우 "완전 일관(fully consistent)" 질의를, 공개 게시물 노출처럼 약간의 지연이 허용되는 경우 "최소 지연(minimize latency)" 질의를 선택하는 식으로 자원마다 일관성 등급을 설계한다.
4.1 레거시 권한의 ReBAC 이관 예시
가상의 문서 협업 서비스가 기존에 관계형 테이블(doc_permissions(doc_id, user_id, role))로 권한을 관리했다고 하자. 이관의 첫 단계는 이 행들을 그대로 관계 튜플로 사상(mapping)하는 것이다. doc_permissions(42, alice, editor) 한 행은 doc:42#editor@user:alice 튜플 하나가 된다. 수천만 행이라면 배치로 일괄 Write 하되, 이관 중에도 신규 권한 변경이 계속 발생하므로 변경 캡처(CDC)로 이관 이후의 델타를 동기화한다.
두 번째 단계는 애플리케이션 코드의 분산된 권한 판단 로직(여러 서비스에 흩어진 if user.role in (...))을 단일 Check 호출로 치환하는 작업이다. 이때 곧바로 전환하지 않고, 기존 로직과 ReBAC 판단을 동시에 실행해 결과를 비교(shadow mode)한다. 예컨대 하루 1억 건의 권한 판단에서 불일치가 0.001% 미만으로 수렴하면 비로소 ReBAC를 권위 있는 결정점으로 승격한다. 이 점진 전환이 생략되면 모델링 오류가 운영 사고로 직결되므로, 실제 대규모 이관에서 가장 많은 시간이 이 검증 단계에 투입된다.
또 하나의 실무 고려는 스키마(모델) 설계다.
또 하나의 실무 고려는 스키마(모델) 설계다. OpenFGA DSL로 define viewer: [user] or editor or viewer from parent 처럼 관계와 상속을 선언하는데, 이 모델링이 잘못되면 그래프가 과도하게 깊어져 지연이 커지거나, 의도치 않은 권한 누수가 생긴다. 실제 도입 사례에서 가장 흔한 실패는 모델링 오류와 튜플 동기화 누락이며, 기존 시스템의 권한 데이터를 튜플로 이관하는 마이그레이션 설계가 프로젝트 성패를 가른다.
5. 심화 — 도입 패턴과 최신 동향
현장 도입은 대개 세 단계로 진행된다. 첫째는 중앙 권한 모델 정의로, 흩어진 if 문 기반 권한 로직을 OpenFGA/SpiceDB 모델로 수렴한다. 둘째는 이중 운영(shadow) 검증으로, 기존 권한 판단과 ReBAC 판단을 동시에 실행해 불일치를 로그로 비교하며 안전하게 전환한다. 셋째는 완전 전환으로, 애플리케이션은 Check API만 호출하고 권한 변경은 Write로 일원화한다. 이 과정에서 데이터 변경(공유/회수)과 튜플 쓰기를 같은 트랜잭션 경계로 묶어 불일치를 막는 것이 중요하다.
최신 동향으로는 첫째, 조건부 권한(caveat/contextual tuple)의 확산이다. "근무 시간에만", "특정 IP 대역에서만"처럼 ABAC식 조건을 튜플에 결합해 ReBAC와 ABAC를 융합한다. 둘째, AI 에이전트·비정형 워크로드의 인가다. 에이전트가 사용자를 대신해 자원에 접근할 때 "사용자-에이전트-자원"의 위임 관계를 튜플로 표현하려는 시도가 늘고 있다. 셋째, 표준화 논의로, 세밀한 인가(Fine-Grained Authorization)를 외부화·중앙화하는 흐름이 제로 트러스트의 정책 결정점(PDP) 개념과 맞물려 확산되고 있다. 넷째, OpenFGA의 CNCF 승격과 각 클라우드의 매니지드 FGA 출시로 "인가를 서비스로 소비"하는 모델이 자리 잡고 있다.
특히 국내에서는 공공·금융 분야의 세밀한 접근통제 요구와 개인정보보호법상 접근권한 관리·접근기록 보존 의무가 맞물려, 권한 부여·회수의 추적성과 증빙이 중요해지고 있다. 관계 튜플 기반 모델은 "누가 언제 어떤 관계를 통해 접근 권한을 얻었는가"를 데이터로 남기므로, 감사 로그·접근통제 증적과 자연스럽게 결합된다. 반대로 ABAC식 복잡한 정책식만으로는 사후 설명이 어렵다는 점이 대비된다.
예상 출제 방향으로는 ① ReBAC와 RBAC/ABAC 비교 및 적용 기준, ② Zanzibar의 zookie와 일관성 보장 메커니즘 설명, ③ 관계 튜플·userset rewrite 개념과 권한 그래프 탐색, ④ 세밀한 인가 외부화가 제로 트러스트·마이크로서비스 아키텍처에 주는 함의 등이 유력하다. 답안에서는 반드시 "왜 대규모에서 ReBAC가 필요한가(역할 폭발)"와 "정확성-지연 트레이드오프를 어떻게 설계로 해결했는가(zookie)"를 핵심 축으로 서술하는 것이 좋다.
6. 고려사항 및 시사점
첫째, 정확성과 지연의 트레이드오프를 자원 등급별로 설계해야 한다. 모든 Check를 완전 일관으로 하면 지연·비용이 과도하고, 모두 캐시 우선으로 하면 회수 누락 위험이 있다. 자원의 민감도에 따라 일관성 등급(완전 일관 vs 최소 지연)을 분리하고, 회수가 치명적인 자원은 zookie 하한을 명시적으로 걸어야 한다.
둘째, 권한 데이터와 비즈니스 데이터의 동기화를 트랜잭션으로 보장해야 한다. 공유 해제는 성공했는데 튜플 삭제가 실패하면 유령 권한이 남는다. 변경 이벤트 기반(outbox 패턴)이나 2단계 쓰기 전략으로 "데이터-튜플 불일치"를 구조적으로 제거하고, 주기적 정합성 감사와 Expand 기반 검증을 운영에 포함해야 한다.
셋째, 모델 설계와 거버넌스가 성능과 보안을 동시에 결정한다. 관계 그래프가 과도하게 깊거나 순환하면 지연이 커지고, 상속 규칙이 모호하면 과대 권한이 생긴다. 모델 변경에 대한 리뷰·버전 관리·영향도 분석(이 변경이 어떤 사용자의 권한을 바꾸는가)을 정책 코드화(Policy as Code)와 결합해 운영해야 한다.
넷째, 인가 외부화는 조직·아키텍처 전략과 함께 가야 한다. 세밀한 인가를 중앙 서비스로 분리하면 일관성과 감사가 쉬워지지만, 모든 서비스가 Check에 의존하므로 가용성·지연의 단일 요충지가 된다. 지역 복제, 캐시 계층, 장애 시 fail-safe(기본 거부) 정책, 그리고 권한 서비스 자체의 SLO 관리가 전제되어야 하며, 제로 트러스트의 PDP/PEP 분리 원칙과 정합되게 설계해야 한다.
다섯째, 벤더·구현 종속성과 이식성을 고려해야 한다. Zanzibar 모델은 공통적이지만 일관성 토큰·조건부 튜플·스키마 DSL은 구현마다 다르다. 모델을 추상화 계층 뒤에 두고, 핵심 권한 로직이 특정 제품 API에 과도하게 결합되지 않도록 설계하면 향후 전환 비용을 줄일 수 있다.
여섯째, 성능·비용 관측성을 운영 지표로 관리해야 한다. 세밀 인가는 요청 경로마다 Check를 호출하므로 호출 수·p95/p99 지연·캐시 적중률·그래프 탐색 깊이가 서비스 품질을 좌우한다. 이들을 대시보드로 상시 관측하고, 깊이가 과도한 모델은 리팩터링하며, 집합 질의가 많은 자원은 구체화 인덱스로 선제 대응해야 한다. 인가가 모든 요청의 임계 경로에 들어가는 만큼, 인가 서비스의 용량 계획과 비용(FinOps) 관리를 별도 과제로 삼는 것이 바람직하다.
참고자료
- Google, "Zanzibar: Google's Consistent, Global Authorization System", USENIX ATC 2019: https://research.google/pubs/pub48190/
- USENIX ATC '19 발표 자료(Zanzibar): https://www.usenix.org/conference/atc19/presentation/pang
- OpenFGA(공식 문서): https://openfga.dev/docs
- AuthZed SpiceDB(공식 문서): https://authzed.com/docs
- Ory Keto: https://www.ory.sh/keto/
한 줄 요약: ReBAC는 사용자와 자원의 "관계"를 권한 판단의 축으로 삼아 대규모 세밀 인가의 역할 폭발을 해결하는 모델이며, Google Zanzibar는 관계 튜플·userset rewrite·zookie 일관성 토큰으로 전역 규모에서 저지연과 회수 정확성을 동시에 달성한 대표 설계다.