Cedar의 한계와 Dogwood의 등장
AWS의 Cedar는 정책 기반 접근 제어(PBAC)를 구현하는 데 널리 쓰이는 언어다. 단일 요청 단위로 "이 사용자가 이 리소스에 접근할 수 있는가?"를 판단하는 데 최적화되어 있다. 그러나 현대 시스템에서는 단순한 단발성 요청이 아니라, 여러 단계의 작업이 연속적으로 이어지는 흐름이 점점 더 일반화되고 있다. 특히 자율적으로 툴을 호출하며 목표를 달성하는 에이전트 아키텍처에서는 이전 호출 이력을 고려하지 않고는 제대로 된 권한 제어가 어렵다.
AWS가 오픈소스로 공개한 Dogwood는 바로 이 문제를 해결하기 위해 Cedar를 확장한 정책 언어다. 핵심은 시간적 조건(temporal conditions) 의 도입이다. 단순히 현재 요청만 보는 것이 아니라, 에이전트가 이전에 어떤 툴을 얼마나 호출했는지, 누적된 상태는 어떤지를 정책 평가에 반영할 수 있다.
실무에서 Dogwood가 다루는 시나리오
Dogwood가 지원하는 제어 유형을 살펴보면 실무 적용 가능성이 구체적으로 드러난다.
- 승인 흐름(Approvals): 특정 단계가 완료되었을 때만 다음 툴 호출을 허용. 예를 들어 결제 툴 호출 전에 확인 툴이 먼저 실행되었는지 검증할 수 있다.
- 요청 빈도 제한(Rate Limit): 일정 시간 내 동일 툴 호출 횟수를 제한하여 남용을 방지한다.
- 누적 합산(Running Totals): 여러 호출에 걸쳐 누적된 값(예: 총 전송 금액, 조회 건수)이 임계치를 초과하면 이후 호출을 거부한다.
// 개념적 예시 (Dogwood 스타일)
permit(
principal,
action == Action::"transfer",
resource
)
when {
context.prior_calls.count("confirm") >= 1 &&
context.running_total("amount") <= 1000000
};
이처럼 이전 호출 이력과 누적 상태를 정책 조건으로 표현할 수 있다는 점이 기존 Cedar와의 결정적인 차이다. 복잡한 비즈니스 규칙을 애플리케이션 코드 안에 흩어서 구현하는 대신, 정책 언어 수준에서 선언적으로 정의할 수 있게 된다.
백엔드 개발자 관점에서의 의미
기존에는 이런 시퀀셜 제어 로직을 구현하려면 상태를 별도로 저장하고, 서비스 레이어나 인터셉터 코드 안에 조건 분기를 직접 작성해야 했다. 이는 비즈니스 로직과 보안 정책이 뒤섞이는 문제를 낳고, 감사(audit)나 정책 변경 시 코드 전반을 수정해야 하는 부담으로 이어진다.
Dogwood는 이 책임을 정책 레이어로 분리한다. Java 백엔드 입장에서는 Spring Security나 커스텀 인터셉터에서 처리하던 복잡한 상태 기반 인가 로직을 외부 정책 엔진에 위임하는 구조를 상상할 수 있다. 물론 현재 레퍼런스 인터프리터는 프로덕션 적용 수준이 아님을 AWS 스스로 명시하고 있으므로, 지금 당장 운영 환경에 도입하기보다는 아키텍처 설계 관점에서 이 방향성을 이해하고 준비하는 것이 적절하다. Apache 2.0 라이선스로 공개되어 있어 내부 PoC나 연구 목적으로 활용하기에는 충분한 상황이다.
정리
- Dogwood는 Cedar를 확장해 이전 툴 호출 이력과 누적 상태를 정책 조건으로 표현할 수 있게 한 정책 언어다.
- 승인 흐름, 빈도 제한, 누적 합산 등 시퀀셜 시나리오의 인가 로직을 선언적으로 분리할 수 있어 코드 복잡도를 낮추는 데 기여한다.
- 현재 레퍼런스 인터프리터는 프로덕션 미적용 수준이므로, 즉시 도입보다는 아키텍처 방향성 파악과 PoC 수준의 탐색이 현실적인 접근이다.