권한 모델을 그래프 위로 옮긴 결정 — 그리고 왜 그게 결정적이었나

작년 5월, 한 고객사 CISO 가 우리에게 한 줄을 물었다.

"릴리스 매니저가 production 배포 직전 에만 이슈를 close 할 수 있게 하려면, 어디서 정책을 박나요?"

답이 세 곳 이었다 — 우리 권한 시스템, 이슈 트래커, 배포 도구. 세 곳이 각자 다른 모델 로 답한다. 그날 우리는 권한 모델을 처음부터 다시 설계하기로 결정했다. 4개월 후 끝났다.

무엇이 부족했나 — RBAC

처음 우리 시스템은 RBAC (Role-Based Access Control) 였다. role 이 permission 의 묶음이고, user 가 role 을 갖는다. Linux 의 user/group/permission 과 같은 모델.

이게 무너지는 첫 지점 — 조건부 권한. "릴리스 매니저는 production 배포 직전 에만 이슈를 close 할 수 있다." RBAC 에는 직전 이라는 시간·상황 조건을 표현할 곳이 없다.

두 번째 무너짐 — 위임 (delegation). "내가 휴가 가 있는 동안 내 배포 권한을 잠깐 X 에게 넘긴다." RBAC 의 user-role 매핑은 영구적 이다. 임시 위임을 표현할 1급 시민이 없다.

ABAC 가 답이 아닌 이유

다음으로 ABAC (Attribute-Based Access Control) 를 검토했다. 주체·자원·환경의 속성으로 정책을 표현한다. AWS IAM 이나 OPA Rego 가 ABAC 패턴.

ABAC 는 조건부 권한 을 잘 표현한다. 그런데 위임 / 추적 / 회수 가 약하다. 정책이 선언적 이라, 누가 누구의 권한으로 무엇을 했는지 의 그래프 가 자동으로 만들어지지 않는다.

큰 문제는 디버깅 이었다. 정책이 100 개를 넘어가면 왜 이 사용자가 거부됐는가 를 답하는 데 분 단위 가 걸린다. 엔터프라이즈 고객의 보안 검토에서 정책 시뮬레이션 요청이 자주 오는데, ABAC 로는 그것이 코드 분석 이 된다.

우리의 답 — 그래프 위에서의 위임 모델

4개월 작업의 결과는 다음 한 줄로 정리된다.

권한 은 그래프의 노드 가 아니라 간선 이다.

User (alice) ─────[role: release-manager]────▶ Project (X)
                  │
                  ├─ scope: env=prod
                  ├─ window: deploy-pending state
                  └─ granted-by: bob (CTO), 2025-05-12

User (alice) ─────[delegated-to: charlie]────▶ Project (X)
                  │
                  ├─ for: 2025-08-01 ~ 2025-08-15
                  ├─ scope: same as original
                  └─ revocable: alice, bob

각 권한 이 그래프 간선 이다. 간선마다 scope, window, granted-by, revocable 같은 속성이 있다. 위임 은 원래 간선이 일시적으로 다른 user 를 가리키는 두 번째 간선 이다.

이게 RBAC 와 ABAC 의 동시 만족 을 가능하게 했다.

• RBAC 가 잘했던 것 — 단순 매핑. role-as-edge 로 그대로 표현.
• ABAC 가 잘했던 것 — 조건. edge attribute (scope, window) 로 표현.
• 둘 다 못했던 것 — 위임·회수·감사. 그래프 traversal 로 자연스럽게 답해짐.

"릴리스 매니저는 production 배포 직전에만 이슈를 close" — 다시

CISO 의 첫 질문에 대한 답이 한 곳 으로 줄었다. 우리 권한 그래프에서:

User (release-manager-X)
   ─[permission: close]→ Issue
       scope: project=ProjectX
       window: deploy-pending state of ProjectX

이슈 close 요청 →
  그래프 traversal →
  edge 발견 → window 조건 평가 →
  현재 state 가 "deploy-pending" 인지 확인 →
  허용 / 거부

이슈 트래커도, 배포 도구도, 우리 권한 시스템도 같은 그래프 를 본다. 정책 한 곳에 박으면 셋이 모두 그것을 따른다.

4개월의 진짜 비싼 부분

코드 작성은 6주 였다. 나머지 10주 는 기존 RBAC 정책의 그래프 마이그레이션 + 각 고객사의 위임 워크플로우 인터뷰 였다.

기존 RBAC 정책 723 개를 그래프로 옮기는 데 자동 변환은 60%. 나머지 40% 는 원래 의도가 모호 했다 — "이 role 은 왜 이 permission 을 가졌는가" 의 답이 원래 만든 사람과 함께 사라진 정책. 우리는 모르는 채로 옮길 수 없었다. 각 정책의 원래 의도를 재구성 하는 게 가장 비싼 일.

무엇이 가능해졌나

이 한 모델 위에서 다음이 추가 인프라 없이 가능해졌다.

• AI 에이전트 권한 — 에이전트가 사람과 같은 종류의 edge 를 갖는다. 사람의 권한과 같은 그래프 위에서 traverse·감사됨.
• Just-in-Time elevation — 평소엔 권한 없음, PR 리뷰 시점에만 잠깐 elevation. window 조건으로 자연스럽게 표현.
• 위임 체인 — A → B 위임, B → C 재위임. 그래프 traversal 한 번에 추적.
• 시뮬레이션 — 만약 alice 가 bob 의 권한을 갖는다면 무엇을 할 수 있나 를 그래프 query 로 답함. 이건 ABAC 에서는 정책 시뮬레이션 엔진 을 별도로 짜야 하는 일.

그래서 그래프 권한 모델은 언제 도입해야 하나

RBAC 정책이 100 개 를 넘어가면서 "왜 이 사용자가 거부됐는가" 에 분 단위가 걸리기 시작하는 시점 — 그게 그래프 권한 모델의 임계점이다. 그래프가 처음부터 옳은 답 은 아니다. 시작은 RBAC 으로 충분하고, 임계점을 넘긴 뒤에는 RBAC + ABAC 의 합집합 을 끌고 가는 것보다 그래프 하나의 유지비용이 낮다. 지금 권한 시스템의 거부 사유를 답하는 데 분 단위가 걸리기 시작한 설계자라면, 그 신호는 이미 온 것.