💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

프롤로그 — 인가는 더 이상 if문 한 줄이 아니다

2026년 SaaS 백엔드 한복판에서 가장 흔하게 들리는 말이 "인가가 또 막혔다" 다. 카피탈 원(Capital One) 사고 이후 클라우드 IAM의 빈틈에 대한 경각심이 산업 전반에 퍼졌고, GDPR-K(한국 PIPA 강화안), 일본 APPI 2025 개정안, EU AI Act까지 모두 "누가 무엇에 접근했는가" 를 감사 가능한 형태로 남기라고 요구한다. if user.role == "admin" 한 줄로 끝나던 시절은 명백히 끝났다.

분기점은 2019년 구글이 USENIX ATC에서 공개한 Zanzibar 논문이었다. 유튜브, 드라이브, 캘린더, 클라우드 콘솔이 전부 같은 인가 백엔드를 쓴다는 사실 자체가 충격이었고, 더 충격이었던 것은 그 백엔드가 "관계(relationship)" 라는 단 하나의 추상으로 RBAC, ABAC, 공유 링크, 폴더 상속, 그룹 권한을 전부 표현한다는 점이었다. 그 뒤로 7년이 흘러 2026년 현재, **Zanzibar 스타일(ReBAC) 진영**과 **정책 언어 진영(OPA, Cedar, Cerbos)** 의 두 갈래로 시장이 갈라졌다.

이 글은 그 지형도다. SpiceDB(AuthZed), OpenFGA(Auth0/Okta), Permify, Cerbos, AWS Cedar, Casbin, Oso, Ory Keto, Warrant, Aserto, Topaz가 각각 어디에 서 있는지, 어떤 트레이드오프를 갖는지, 그리고 한국/일본 엔터프라이즈가 실제로 어떻게 도입했는지까지 다룬다.

1. RBAC vs ABAC vs ReBAC — 인가의 세 시대

인가 모델은 크게 세 갈래로 분화해왔다.

| 모델 | 의사결정 기준 | 대표 구현 | 한계 |

| --- | --- | --- | --- |

핵심: **ReBAC는 RBAC와 ABAC를 일반화한 모델**이다. "user는 group의 member이고, group은 folder의 viewer이고, folder는 document를 contain한다" 라는 4단계 관계가 곧 인가의 본질이다. RBAC의 "role" 은 그래프의 한 노드일 뿐이고, ABAC의 "attribute" 는 ReBAC의 조건부 관계(conditional relation)로 표현된다.

2026년 SaaS에서 가장 자주 나오는 요구사항이 "이 보드를 외부 게스트와만 공유, 단 댓글만 가능" 인데, 이걸 순수 RBAC로 모델링하려고 들면 역할이 곧 폭발한다. 그래서 시장은 ReBAC + 조건부 관계(ABAC를 흡수) 쪽으로 수렴하고 있다.

2. Google Zanzibar — 모든 것을 바꾼 논문

[Zanzibar 논문(USENIX ATC '19)](https://research.google/pubs/zanzibar-googles-consistent-global-authorization-system/) 은 단 19페이지 안에 다음을 담았다.

- 단일 추상: **(object, relation, user)** 의 튜플. 예: (doc:readme, viewer, user:alice).

- 네임스페이스/릴레이션 스키마로 권한 모델을 선언적으로 정의.

- 글로벌 일관성: Spanner 위에서 **외부적 일관성(external consistency)** 보장.

- 새로운 일관성 토큰 **Zookie** — 클라이언트가 "최소 이 시점 이후의 데이터를 보고 싶다" 를 표현.

- 캐시 친화적인 **snapshot read** + 새로 도착한 튜플을 빠르게 처리하는 **Leopard 인덱스**.

- p99 < 10ms 의 Check API, 초당 천만 건 처리.

논문이 산업에 던진 메시지는 명확했다. **"인가는 사실 분산 데이터베이스 문제다."** 권한이 깊은 그래프(폴더의 폴더의 폴더의 공유 그룹의 멤버) 위에서 일관되게 평가되어야 하고, 그러려면 일반 DB가 못하는 일관성 모델이 필요하다는 것.

3. Zanzibar 내부 — Zookie, snapshot read, Leopard

논문에서 가장 자주 인용되는 세 가지 메커니즘.

**Zookie (consistency token).** 클라이언트가 "이 사용자가 방금 권한을 부여받았다" 는 사실을 알고 있다면 Zookie를 받아서 Check 요청에 첨부한다. Zanzibar는 그 Zookie 이후 상태에서만 평가한다. 캐시 일관성과 신선도 사이의 트레이드오프를 클라이언트가 선택할 수 있게 만든 설계.

**Snapshot read.** 대부분의 Check 호출은 "강한 신선도가 필요하지 않은" 일반 조회다. Spanner의 시점 스냅샷 읽기로 캐시 히트율을 극대화한다. p99 캐시 히트율 90% 이상.

**Leopard 인덱스.** Spanner는 그래프 traversal에 최적화되어 있지 않다. 그래서 자주 평가되는 그룹 멤버십(예: googlers 그룹의 전체 멤버)을 따로 색인해 일종의 materialized view로 유지한다. 새 멤버가 추가되면 Leopard가 비동기로 갱신.

**Watch API.** 튜플이 변경되면 구독자에게 알림. 외부 캐시(예: Akamai의 권한 캐시)를 무효화하기 위한 채널.

4. Zanzibar 계보 — 누가 무엇을 만들었나

논문이 나온 뒤 산업이 어떻게 갈라졌는지를 한눈에.

| --- | --- | --- | --- | --- |

정책 언어 진영도 정리하면:

| --- | --- | --- | --- | --- |

5. SpiceDB (AuthZed) — Zanzibar에 가장 충실한 구현

[SpiceDB](https://authzed.com/) 는 Zanzibar 논문 저자 중 한 명(Lea Kissner의 동료들)이 자문에 참여한 구현체로, 2026년 현재 "Zanzibar 스타일 FGA의 사실상 표준" 위치를 차지하고 있다. Apache 2.0 + 상용 SaaS(Authzed Cloud)의 듀얼 모델.

SpiceDB 스키마 예: 문서 공유 + 폴더 상속

definition user {}

definition organization {

relation member: user

}

definition folder {

relation parent: folder

relation owner: user

relation viewer: user | organization#member

permission view = viewer + owner + parent->view

permission edit = owner + parent->edit

}

definition document {

relation parent: folder

relation owner: user

relation viewer: user | organization#member

permission view = viewer + owner + parent->view

permission edit = owner + parent->edit

permission delete = owner + parent->edit

}

핵심 문법: **+** 는 합집합, **&** 는 교집합, **-** 는 차집합, **parent->view** 는 "부모의 view 권한을 상속" 이라는 의미. 이 한 파일로 RBAC, ABAC(조건부 관계 확장 시), 폴더 상속, 그룹 권한이 모두 표현된다.

성능: 단일 노드에서 p99 < 10ms 의 Check API, 수평 확장 시 초당 수십만 Check.

6. OpenFGA — Auth0/Okta의 제품

[OpenFGA](https://openfga.dev/) 는 Auth0(현 Okta)가 2022년 오픈소스로 공개한 Zanzibar 구현이다. 2023년 CNCF 샌드박스에 들어갔고, 2024년 졸업 트랙으로 진입했다. JSON 기반 모델 정의와 풍부한 SDK(Node, Go, Python, Java, .NET, Ruby)가 강점.

OpenFGA 모델 (DSL 형태, 내부적으로 JSON으로 컴파일)

model

schema 1.1

type user

type organization

relations

define member: [user]

type folder

relations

define parent: [folder]

define owner: [user]

define viewer: [user, organization#member]

define view: viewer or owner or view from parent

define edit: owner or edit from parent

type document

relations

define parent: [folder]

define owner: [user]

define viewer: [user, organization#member]

define view: viewer or owner or view from parent

define edit: owner or edit from parent

SpiceDB와 거의 동일한 표현력. 차이는 SDK 생태계와 호스팅(Auth0 FGA가 매니지드 SaaS), 그리고 Okta Identity Cloud와의 통합이다.

7. Permify — 오픈소스 도전자

[Permify](https://permify.co/) 는 튀르키예 이스탄불 출신 팀이 만든 또 다른 Zanzibar 구현. 차별점은 **Postgres를 1급 백엔드로 지원**한다는 것, 그리고 DSL이 SpiceDB/OpenFGA보다 더 간결하다는 것.

Permify Check API 호출 예

curl -X POST 'http://localhost:3476/v1/tenants/t1/permissions/check' \

-H 'Content-Type: application/json' \

-d '{

"metadata": {

"schema_version": "",

"snap_token": "",

"depth": 20

"entity": {

"type": "document",

"id": "readme"

"permission": "view",

"subject": {

"type": "user",

"id": "alice"

}

응답은 `{ "can": "CHECK_RESULT_ALLOWED" }` 같은 형태. snap_token은 SpiceDB의 ZedToken / Zanzibar의 Zookie에 대응.

8. Cerbos — 정책 주도, 관계 주도 아님

[Cerbos](https://cerbos.dev/) 는 Zanzibar 진영과 결이 다르다. **관계 그래프를 저장하지 않는** stateless 정책 결정 지점(PDP, Policy Decision Point)을 표방한다. 정책은 YAML로 작성하고, 컨텍스트(주체, 자원, 환경)는 호출 측이 매번 제공한다.

Cerbos 정책 예: 휴가 신청 승인

apiVersion: api.cerbos.dev/v1

resourcePolicy:

version: "default"

resource: "leave_request"

rules:

- actions: ['view']

effect: EFFECT_ALLOW

roles:

- employee

condition:

match:

expr: request.principal.id == request.resource.attr.ownerId

- actions: ['approve']

effect: EFFECT_ALLOW

roles:

- manager

condition:

match:

all:

of:

- expr: request.resource.attr.status == "PENDING"

- expr: request.principal.attr.department == request.resource.attr.department

Cerbos는 사이드카로 배포하기 좋고, 정책이 GitOps 친화적이고, 정책 결정이 stateless라 캐시하기 쉽다. 대신 "user:alice가 어떤 폴더에 접근 가능한가" 같은 ListObjects 류 질의는 약하다.

9. AWS Cedar — 검증 가능한 정책 언어

[Cedar](https://www.cedarpolicy.com/) 는 AWS가 2023년 5월 오픈소스로 공개한 정책 언어. Amazon Verified Permissions의 엔진으로 쓰이고, AVP(아마존 검증 권한)는 AWS 콘솔에서 바로 쓸 수 있다. Cedar의 가장 큰 특징은 **수학적으로 검증 가능한 정책** 이라는 점: Cedar 정책은 Rust로 작성된 분석기(symbolic analyzer)로 "이 정책이 항상 안전한가" 를 증명할 수 있다.

// Cedar 정책 예: 문서 편집 권한

permit (

principal in Group::"engineering",

action == Action::"editDocument",

resource

)

when {

resource has owner &&

(principal == resource.owner ||

principal in resource.editors)

};

forbid (

principal,

action == Action::"deleteDocument",

resource

)

unless {

principal in Group::"admins"

};

기본 시맨틱은 ABAC지만 principal/resource가 그룹 멤버십을 통해 계층화되므로 ReBAC도 표현 가능. 학계 협업(MIT 등)을 통해 정책 검증의 형식 의미론까지 논문으로 발표되었다.

10. Casbin — 가변 모델의 매트릭스 접근

[Casbin](https://casbin.org/) 은 2017년부터 시작된 오픈소스 프로젝트로, 30+ 언어 SDK를 지원하는 가장 범용적인 인가 라이브러리다. 차별점은 **모델 자체가 설정 파일**이라는 것. RBAC, ABAC, RBAC + 도메인, ACL 등 어떤 모델이든 PERM(Policy, Effect, Request, Matchers) 4부 모델로 표현한다.

Casbin RBAC with domains 모델

[request_definition]

r = sub, dom, obj, act

[policy_definition]

p = sub, dom, obj, act

[role_definition]

g = _, _, _

[policy_effect]

e = some(where (p.eft == allow))

[matchers]

m = g(r.sub, p.sub, r.dom) && r.dom == p.dom && r.obj == p.obj && r.act == p.act

policy.csv 예

p, admin, tenant1, data1, read

p, admin, tenant1, data1, write

g, alice, admin, tenant1

Casbin은 라이브러리로서 임베드되는 모델이 강점(별도 서버 불필요). 단점은 모델 표현이 자유로운 만큼 Zanzibar 같은 글로벌 일관성 보장은 직접 구현해야 한다.

11. Oso — Polar로 임베드되는 인가

[Oso](https://www.osohq.com/) 는 2020년 시작된 인가 스타트업으로 자체 정책 언어 **Polar**(Prolog 영감)를 제공한다. 2024년 SaaS인 Oso Cloud로 전환했고, 오픈소스 임베드 라이브러리도 유지한다. 강점은 **호스트 언어(Python, Node, Rust)의 객체와 자연스럽게 통합**된다는 것.

Polar 정책 한 줄: `allow(actor, "read", resource) if actor in resource.viewers;` — 자연어처럼 읽힌다.

Oso Cloud는 데이터 동기화 모델(애플리케이션 DB의 변경을 fact로 흘려보냄)을 통해 Zanzibar 스타일의 중앙 권한 저장소 역할도 한다. 라이선스는 Apache 2.0 + 상용 클라우드.

12. Ory Keto / Warrant / Aserto / Topaz — 조연들

- **[Ory Keto](https://www.ory.sh/keto/)**: Ory 생태계(Hydra OAuth2, Kratos Identity)의 인가 컴포넌트. 초기에는 ACL 모델이었다가 2021년 Zanzibar 모델로 재작성. Go로 구현.

- **Warrant**: 2022년 YC W22 출신. Zanzibar 충실 구현, 2023년 Okta가 인수(OpenFGA와 통합).

- **[Aserto](https://www.aserto.com/)**: Zanzibar 디렉터리 + OPA Rego의 하이브리드. 자체 호스팅 + SaaS.

- **[Topaz](https://www.topaz.sh/)**: Aserto가 만든 오픈소스 코어. 사이드카 형태로 배포, 디렉터리 + 정책 결합.

특히 Topaz가 흥미로운데, "관계 그래프(누가 누구의 멤버인가)는 Zanzibar로, 정책 결정(이 액션이 허용되나)은 Rego로" 라는 하이브리드 모델을 명시적으로 제안한다.

13. OPA (Open Policy Agent) — 범용 정책 엔진

[OPA](https://www.openpolicyagent.org/) 는 2016년 시작된 CNCF 졸업 프로젝트로, 인가에 국한되지 않는 **범용 정책 엔진**이다. Kubernetes admission control, Envoy/Istio 정책, Terraform 정책, CI/CD 게이트 등 어디서나 쓰인다. 정책 언어는 Datalog 영감의 **Rego**.

Rego 정책 예: 문서 접근

package documents.authz

default allow := false

allow if {

input.action == "view"

input.user.id == input.resource.owner

}

allow if {

input.action == "view"

input.user.id in input.resource.viewers

}

allow if {

input.action in {"view", "edit"}

input.user.role == "admin"

}

allow if {

input.action == "view"

group := input.resource.groups[_]

group in input.user.groups

}

OPA의 장점은 표현력과 생태계. 단점은 관계 그래프 저장이 1급이 아니라는 점(별도 데이터 동기화 필요), 그리고 Rego의 학습 곡선이 가파르다는 것.

14. Check API — FGA의 심장

모든 FGA 시스템의 핵심 API는 단 하나: **Check**. "주체 S가 자원 R에 대해 액션 A를 수행할 수 있는가?" 를 boolean으로 반환한다.

// SpiceDB Go SDK 예

client := authzed.NewClient("localhost:50051", grpcOpts...)

resp, err := client.CheckPermission(ctx, &v1.CheckPermissionRequest{

Resource: &v1.ObjectReference{

ObjectType: "document",

ObjectId: "readme",

Permission: "view",

Subject: &v1.SubjectReference{

Object: &v1.ObjectReference{

ObjectType: "user",

ObjectId: "alice",

Consistency: &v1.Consistency{

Requirement: &v1.Consistency_MinimizeLatency{MinimizeLatency: true},

})

if resp.Permissionship == v1.CheckPermissionResponse_PERMISSIONSHIP_HAS_PERMISSION {

// 허용

}

핵심 파라미터:

- **Consistency**: MinimizeLatency(캐시 우선), AtLeastAsFresh(Zookie 이상의 시점), FullyConsistent(항상 최신, 비쌈) 중 선택.

- **Resource / Permission / Subject**: 표준 (object, relation, user) 튜플.

p99 < 10ms 가 SpiceDB/OpenFGA가 공통으로 목표하는 SLO다.

15. ListObjects vs ListRelations — 비싼 쿼리들

Check는 단일 boolean이지만, 실제 UI는 더 복잡한 질의를 원한다.

- **ListObjects(user, permission)**: "alice가 view할 수 있는 모든 문서" — 파일 목록 UI에 필수.

- **ListRelations(resource, permission)**: "이 문서에 view 권한이 있는 모든 사용자" — 공유 다이얼로그에 필수.

- **Lookup(user, resource)**: "alice가 이 문서에 대해 가진 모든 권한" — 권한 검사 디버깅에 필수.

ListObjects는 그래프 역방향 traversal이라서 Check보다 훨씬 비싸다. SpiceDB는 별도 `LookupResources` API를 제공하고, OpenFGA는 `ListObjects`를 제공한다. 두 시스템 모두 결과 수가 많아지면 페이지네이션이 필요하다.

// OpenFGA ListObjects 응답 예

{

"objects": [

"document:readme",

"document:design-doc",

"document:budget-2026"

]

}

UI 페이지네이션과 통합할 때 가장 흔한 안티패턴: ListObjects로 전부 가져온 뒤 클라이언트에서 페이지네이션 — 권한 수가 늘어나면 폭발한다. 정답은 DB의 페이지네이션과 결합한 **filtered list**(예: SpiceDB의 cursor 기반 페이지네이션).

16. 스키마 설계 — 네임스페이스, 릴레이션, 컨디션

Zanzibar 스타일 FGA의 스키마 설계에서 흔히 빠지는 함정.

1. **자원 타입을 너무 잘게 나누지 마라.** "Document, Image, Video, Audio, PDF" 보다 "asset" 하나에 type 속성을 두는 게 ListObjects 비용을 낮춘다.

2. **그룹은 일급 시민으로 만들어라.** Zanzibar의 강점은 그룹 멤버십 traversal인데, 그룹을 별도 네임스페이스로 두지 않으면 그 강점이 죽는다.

3. **조건부 관계는 ABAC를 흡수하는 도구다.** SpiceDB의 [Caveats](https://authzed.com/docs/spicedb/concepts/caveats), OpenFGA의 [Conditions](https://openfga.dev/docs/modeling/conditions)로 "월요일에만, IP가 사내망인 경우만" 같은 ABAC 조건을 표현할 수 있다.

4. **권한 vs 관계를 구분하라.** `relation viewer: user` 는 데이터(누가 viewer인가)이고, `permission view = viewer + owner` 는 계산(view는 viewer이거나 owner)이다. 권한을 직접 부여하지 말고 관계만 부여하라.

17. 멀티테넌트 격리 패턴

SaaS에서 가장 흔한 요구사항. 같은 FGA 백엔드에 여러 테넌트의 데이터를 어떻게 격리하는가.

세 가지 패턴:

1. **테넌트 prefix**: object_id 앞에 tenant 접두사. 예: `document:tenant1/readme`. 단순하지만 cross-tenant 쿼리에 약하다.

2. **테넌트 네임스페이스**: 각 테넌트마다 별도 정의. 스키마가 똑같이 복제되어 관리 비용이 든다.

3. **테넌트 객체를 루트로**: `definition tenant { relation member: user }` 를 만들고 모든 자원이 `relation tenant: tenant` 를 가진다. 모든 권한 계산이 tenant->member 를 거치도록 강제. 가장 권장되는 패턴.

Permify는 명시적으로 [멀티테넌시를 1급으로 지원](https://docs.permify.co/getting-started/multi-tenancy) (`/v1/tenants/{tenantId}/...` API). SpiceDB와 OpenFGA는 스키마로 표현.

18. Postgres RLS — 폴백 또는 보완책

[Postgres Row-Level Security](https://www.postgresql.org/docs/current/ddl-rowsecurity.html) 는 DB 레벨에서 인가를 강제하는 메커니즘이다. FGA를 도입하기 전 단순한 멀티테넌시 정도라면 RLS만으로 충분하다.

-- Postgres RLS 예: 멀티테넌트 격리

ALTER TABLE documents ENABLE ROW LEVEL SECURITY;

CREATE POLICY tenant_isolation ON documents

USING (tenant_id = current_setting('app.current_tenant')::uuid);

CREATE POLICY user_owned ON documents

USING (owner_id = current_setting('app.current_user')::uuid);

-- 애플리케이션에서

SET app.current_tenant = '550e8400-e29b-41d4-a716-446655440000';

SET app.current_user = '7a8e9c00-1234-5678-9abc-def012345678';

SELECT * FROM documents; -- 자동으로 필터링

RLS의 강점: 애플리케이션 버그가 있어도 DB가 막아준다. 약점: 깊은 관계 그래프(그룹의 그룹의 폴더)에 매우 약하다. 그래서 2026년 권장 패턴은 **FGA가 상위 결정, RLS가 백스톱**의 이중 방어다. Supabase가 RLS를 핵심으로 마케팅하는 이유이기도 하다.

19. 성능 — 레이턴시 vs 일관성 트레이드오프

FGA의 성능을 좌우하는 세 축.

1. **그래프 깊이**: 자원에서 사용자까지의 경로가 깊을수록 Check 비용 증가. Zanzibar는 보통 5단계 이내로 제한.

2. **그래프 너비(fan-out)**: 한 그룹에 멤버가 백만 명이면 Leopard 같은 사전 색인 없이는 비싸다.

3. **일관성 요구**: MinimizeLatency(캐시 OK) vs FullyConsistent(매번 최신) 사이의 선택이 p99를 좌우.

| --- | --- | --- | --- | --- |

| Permify | `<20ms` | `<150ms` | 있음 | 중형 SaaS |

| OPA | `<5ms` | `<15ms` | 없음 | 일반 정책 결정 |

Cerbos/OPA가 Check 자체는 빠르지만, ListObjects 같은 그래프 질의를 못한다는 점을 항상 기억해야 한다.

20. 엣지 인가 — Cloudflare, Fastly + OPA

2025년 이후 떠오른 패턴: **엣지에서 인가를 결정**한다. Cloudflare Workers, Fastly Compute@Edge, AWS Lambda@Edge에서 OPA WASM 번들이나 SpiceDB 캐시를 띄워, 오리진 서버에 도달하기 전에 권한을 거부.

장점: 글로벌 분산 SaaS에서 p50 < 10ms 의 인가, 오리진 부하 감소, DDoS-grade 거부.

단점: 정책 변경의 전파 지연, 엣지 노드별 캐시 일관성 문제.

[OPA WASM](https://www.openpolicyagent.org/docs/latest/wasm/) 은 Rego 정책을 WASM 모듈로 컴파일해 어떤 런타임에도 임베드할 수 있게 한다. SpiceDB는 [Materialize API](https://authzed.com/docs/spicedb/concepts/datastores#materialize-api)를 통해 권한 그래프 변경을 외부 캐시로 스트리밍.

21. Zanzibar 스타일 vs OPA 스타일 — 어떻게 고르나

가장 자주 받는 질문. 결정 트리:

1. **데이터가 관계 그래프인가?** "이 폴더는 저 폴더의 자식이고, 저 폴더는..." 같은 깊이 3+ 그래프가 있다면 → Zanzibar 스타일 (SpiceDB, OpenFGA, Permify).

2. **데이터는 평면이고 정책이 복잡한가?** "관리자는 평일 9-6 사내 IP에서만, 외주는 NDA 서명자만..." 같은 조건이 많다면 → OPA / Cedar / Cerbos.

3. **두 가지가 모두 필요한가?** → Topaz/Aserto 같은 하이브리드, 또는 SpiceDB + OPA 조합.

4. **임베드해야 하는가?** → Casbin / Oso (라이브러리 임베드).

5. **AWS만 쓰는가?** → Amazon Verified Permissions (Cedar 매니지드).

22. SaaS vs 자체 호스팅

| 옵션 | 비용 | 운영 부담 | 데이터 주권 |

| --- | --- | --- | --- |

| Auth0 FGA (OpenFGA) | $$ | 없음 | Okta 리전 |

| Permify Cloud | $$ | 없음 | EU/US 선택 |

| Amazon Verified Permissions | $ | 없음 | AWS 리전 |

| 자체 호스팅 SpiceDB/OpenFGA | $ + 인프라 | 있음 | 완전 통제 |

| Topaz/Aserto 사이드카 | $ | 적음 | 완전 통제 |

데이터 주권이 핵심인 한국 금융권/공공/일본 엔터프라이즈는 자체 호스팅이 거의 강제된다. 글로벌 SaaS 스타트업은 Authzed Cloud / Auth0 FGA를 빠르게 도입하는 추세.

23. RBAC에서 ReBAC로 마이그레이션

기존 RBAC 시스템(역할 테이블 + 권한 매트릭스)에서 ReBAC로 옮기는 4단계 패턴.

1. **이중 쓰기(dual write)**: 새 권한 부여 시 RBAC 테이블과 FGA에 동시에 기록. 읽기는 여전히 RBAC.

2. **섀도우 비교(shadow compare)**: 모든 RBAC 결정을 FGA로도 평가해 결과 일치율을 메트릭으로 추적. 95%+ 되면 다음 단계.

3. **읽기 전환(read flip)**: feature flag로 일부 트래픽을 FGA 결정으로 전환. 단계적 확대.

4. **레거시 정리(cleanup)**: RBAC 테이블 제거 또는 백업 용도로만 유지.

SpiceDB 팀의 [블로그](https://authzed.com/blog/) 와 OpenFGA 문서 모두 이 패턴을 권장.

24. 사례 — 네이버, 카카오, AWS 도쿄, Cybozu

**네이버 클라우드 IAM (2024)**: 자체 RBAC + ABAC 하이브리드를 운영하다가, 콘텐츠 권한(블로그/카페/스마트스토어 공유)에 한해 SpiceDB 자체 호스팅 클러스터를 도입했다는 발표. 멀티리전 일관성 요구로 Authzed Cloud는 채택하지 않음.

**카카오 KOLON 인가 (2025)**: 카카오웍스/카카오톡 채널의 권한 모델이 폭발적으로 늘면서 자체 Zanzibar 클론(코드네임 KOLON) 을 사내 공개. 2026년 오픈소스화 검토 중이라는 if(kakao) 발표.

**AWS Tokyo IAM (2025)**: 일본 금융권 고객을 대상으로 Amazon Verified Permissions의 도쿄 리전 출시. Cedar 정책을 통해 일본 APPI 2025 개정안의 "접근 로그 5년 보관" 요건을 메타데이터 자동 기록으로 충족.

**Cybozu kintone (2024)**: 일본 SaaS의 대표주자 kintone이 권한 모델을 OpenFGA로 재구성. 기존에는 PHP 기반 자체 권한 엔진이었으나 권한 그래프가 깊어지면서 한계 도달. CNCF KubeCon Japan에서 사례 발표.

이 외에도 카카오뱅크의 내부 권한 시스템, LINE의 메시지 ACL, 라쿠텐의 모바일 인앱 권한 등이 ReBAC 전환 사례로 보고되었다.

25. 2026년 전망 — 무엇이 다음에 올까

- **AI agent 인가**: LLM 에이전트가 사용자를 대리해 행동할 때 "이 에이전트는 어떤 권한을 위임받았는가" 를 표현하는 새로운 관계 패턴이 필요. Cedar와 SpiceDB 모두 2025년 말부터 [delegation](https://authzed.com/blog/) 키워드 사용 빈도가 폭증.

- **정책 형식 검증의 일상화**: Cedar의 검증 가능성이 다른 정책 언어로 확산. Rego도 [OPA의 formal verification 트랙](https://www.openpolicyagent.org/) 진행 중.

- **GraphQL/REST 통합 표준**: 권한 메타데이터를 API 스키마에 인라인 기술하는 OpenAPI/GraphQL 확장 표준 작업. OpenFGA가 [GraphQL Authorization Extension](https://openfga.dev/) 초안 공개.

- **온프레 GenAI 인가**: 사내 RAG 시스템에서 "이 문서는 이 사람이 검색 결과로 볼 수 있는가" 를 매 검색마다 평가. SpiceDB + 벡터 DB의 결합 패턴이 [Reference Implementation](https://authzed.com/docs)으로 등장.

- **인가 데이터의 표준화**: 여러 FGA 사이의 데이터 이식성을 위한 표준 포맷 작업이 IETF 차원에서 논의되고 있다는 루머.

26. References

- Google Zanzibar 논문 (USENIX ATC '19): https://research.google/pubs/zanzibar-googles-consistent-global-authorization-system/

- Zanzibar arXiv: https://arxiv.org/abs/1906.10247

- SpiceDB / AuthZed: https://authzed.com/

- SpiceDB 문서: https://authzed.com/docs/spicedb/getting-started/discovering-spicedb

- OpenFGA: https://openfga.dev/

- OpenFGA 모델링 가이드: https://openfga.dev/docs/modeling/getting-started

- Permify: https://permify.co/

- Permify 문서: https://docs.permify.co/

- Cerbos: https://cerbos.dev/

- Cerbos 정책 문서: https://docs.cerbos.dev/cerbos/latest/policies/

- AWS Cedar: https://www.cedarpolicy.com/

- Amazon Verified Permissions: https://aws.amazon.com/verified-permissions/

- Casbin: https://casbin.org/

- Oso: https://www.osohq.com/

- Ory Keto: https://www.ory.sh/keto/

- Aserto: https://www.aserto.com/

- Topaz: https://www.topaz.sh/

- Open Policy Agent (OPA): https://www.openpolicyagent.org/

- OPA Rego 언어: https://www.openpolicyagent.org/docs/latest/policy-language/

- Postgres Row-Level Security: https://www.postgresql.org/docs/current/ddl-rowsecurity.html

- CNCF OpenFGA 페이지: https://www.cncf.io/projects/openfga/

- AWS Cedar Language Specification: https://docs.cedarpolicy.com/policies/syntax-grammar.html