Dogwood로 Cedar 시간적 간극 메워보기
- 2일 전
- 4분 분량
Dogwood로 Cedar 시간적 간극 메워보기
Written by Minhyeok Cha
목차
시작하며
AI 에이전트를 프로덕션까지 배포하고 나서가 골치 아프기 시작합니다.
개발단계에서는 각 툴의 호출만 작동하면 넘어가지만, 실제 서비스에서는 에이전트가 승인 절차도 없이 툴을 불러오고, 파일을 백업하기 전에 삭제 툴을 호출하는 일이 생깁니다.
기존 정책 언어들은 매 요청을 개별적으로 판단하는 구조라, 에이전트 운용하는 데 있어 작동에는 불편함이 없으나 프로덕션 에이전트의 보안 설계, 특히 승인 영역에서 문제로 남던 부분입니다.
AWS가 최근 이 문제를 타파할 오픈소스 Dogwood를 공개했습니다.
AgentCore Policy는 Dogwood를 지원하지만 GitHub의 참조 인터프리터는 프로덕션 집행용 단계가 아니라고 합니다.
Dogwood는 AWS의 Cedar 정책 언어를 확장해 만든 시간적 정책 언어로서, 관리자와 개발자는 사용자가 애플리케이션 리소스를 사용하도록 허용하거나 금지하는 정책을 정의할 수 있습니다.
Cedar 란?
Cedar는 AWS가 만든 오픈소스 인가 정책 언어로, AgentCore Policy가 Cedar를 사용하는 데 있어 중요 포인트는 다음과 같습니다.
① 빠르다 : 반복문이나 상태 저장 연산을 배제해 처리가 빠르며, 에이전트의 매 호출마다 지연 없이 판정할 수 있습니다.
② 읽기 쉽다 : Cedar를 사용하는 AgentCore Policy는 자연어로 정책을 작성하면 LLM이 Cedar로 번역합니다.
// 플래티넘 등급 고객이 50개 이상 주문할 때만 대량 할인 허용
permit (
principal is AgentCore::OAuthUser,
action == AgentCore::Action::"ApplyBulkDiscount",
resource
)
when {
principal.hasTag("customer_tier") &&
principal.getTag("customer_tier") == "Platinum" &&
context.input.orderQuantity >= 50
}
unless {
context.input.productTypes.containsAny(["limited_edition", "seasonal_specials"])
};
③ 자동 추론으로 분석 가능하다 : 예를 들어 "고객 등급이 Gold이면서 동시에 Platinum이어야 한다" 처럼 애초에 동시에 참일 수 없는 조건을 실수로 넣으면, 그 정책은 어떤 요청도 허용하지 못하는 정책이 됩니다.
Cedar의 한계
Cedar에는 사용해보시면 문제점을 하나 찾을 수 있을 겁니다. Cedar는 각 요청을 이전 요청과 무관하게, 그 순간의 정보로만 판단하며 이것이 바로 "동일한 요청은 언제 평가하든 동일한 결정을 낸다"의 근거가 됩니다.
그러나 문제는 에이전트가 실제로 문제를 일으키는 지점은 종종 단일 행동이 아니라 행동의 시퀀스라는 것에 있습니다.
이 송금은 이미 승인을 받은 건인가?
최근 1시간 동안 몇 번 송금했는가?
이런 규칙은 "지금 이 요청"만 보는 Cedar의 point-in-time 모델로는 한계가 있었습니다.
Dogwood
Dogwood는 Cedar를 대체하는 언어가 아니라, Cedar가 원래 다루지 않던 영역, 즉 행동 시퀀스에 대한 시간적(temporal) 정책을 다루기 위해 Cedar 위에 얹은 형태입니다.
구문적 하위 호환성: 문법적으로 유효한 모든 Cedar 정책은 그대로 유효한 Dogwood 정책이다. 즉 기존 Cedar 정책 세트를 마이그레이션 없이 그대로 사용할 수 있다.
의미론 유지: Dogwood도 Cedar와 동일하게 기본 거부(default deny), forbid가 permit을 이긴다는 규칙을 그대로 따른다. 감사·집행이 의존하던 보장이 깨지지 않는다.
Dogwood가 새로 도입하는 것은 when { ... } 절 옆에 놓이는 when temporal { ... } 절이며 이 절은 현재 요청뿐 아니라 과거 이벤트의 기록을 참조합니다.
예시
Cedar 조건과의 결합
"지금 이 요청에 대한 단순 조건"과 "과거 이력 조건"을 동시에 요구할 때 Dogwood는 temporal를 하나의 표현식으로 취급해 기존 Cedar의 when 절 안에 그대로 끼워 넣을 수 있습니다.
permit ( principal, action == AgentCore::Action::"SellShares", resource )
when {
context.input.shares <= 100
&& temporal {
formerly within 1h AgentCore::Action::"ApproveSale"::response{
input.stock: context.input.stock,
input.shares: context.input.shares,
output.approved: true
}
}
};
횟수 제한
count_within은 단순 이벤트 개수를, count_distinct_within은 특정 필드의 서로 다른 값의 개수를 세며 같은 수취인에게 여러 번 보내는 것과 새로운 수취인이 늘어나는 것을 구분해서 제어할 수 있습니다.
// 1시간 내 5회 초과 송금 금지 (금액과 무관)
forbid ( principal, action == AgentCore::Action::"Transfer", resource )
when temporal {
count_within(1h, AgentCore::Action::"Transfer"::request{ input.amount: _ }) > 5
};
// 1시간 내 서로 다른 수취인 3명 초과 금지
forbid ( principal, action == AgentCore::Action::"Transfer", resource )
when temporal {
count_distinct_within(u, 1h, AgentCore::Action::"Transfer"::request{ input.user: u }) > 3
};
Cedar vs. Dogwood
구분 | Cedar | Dogwood |
성격 | AgentCore Policy의 기본 인가 언어 | Cedar를 확장한 시간적(temporal) 정책 언어 |
판단 기준 | 현재 요청만 (point-in-time) | 현재 요청 + 과거 이벤트 이력(trace) |
대표 절 | when { ... } | when temporal { ... } (Cedar when 안에도 삽입 가능) |
표현 가능한 것 | 단일 행동의 허용/거부 | 시퀀스, 순서, 횟수, 누적값, 비율 제한 |
상태 저장 여부 | 상태 없음(stateless) | 이벤트 로그를 상태로 추적(stateful) |
자동 추론(Cedar Analysis) | 지원 — 정책 충돌·모순·논리 오류를 수학적으로 검증 | 아직 미지원 (temporal 조건은 자동 추론 대상 밖) |
Dogwood로 표현할 수 없는 것들
① 특정 행동에 대한 규칙이 아닌 경우
어떤 행동(action), 어떤 필드, 어떤 조건도 명시돼 있지 않을 경우 실질적으로는 행동 강령이나 교육 지침이지, 인가 규칙이 아닙니다. 정책 엔진은 에이전트 호출을 허용할지 판단하는 도구입니다.
② 판정이 아니라 조치를 요구하는 경우
정책 엔진이 할 수 있는 일은 허용(allow) 또는 거부(deny), 두 가지뿐입니다. "사회보장번호가 포함된 제출은 거부한다"는 인접한 규칙은 물론 명시적으로 표현할 수 있지만, "번호를 지우고 저장은 계속 진행한다"는 건 다른 방식입니다.
③ 언어 표현의 범위를 벗어나는 경우
Dogwood의 시간 관련 기능은 특정 시점, 시간 오프셋, 시간 차이를 다룰 수 있지만, 요일을 판별하는 접근자나 공휴일 달력 같은 개념은 없습니다.
④ 세션 범위를 벗어나는 경우
Dogwood는 세션 단위로 이벤트 흐름을 평가합니다. temporal 연산자가 "과거에 무슨 일이 있었는지" 조회할 때, 그 조회 범위는 정확히 이 세션 ID로 태그된 이벤트로 한정되며 다른 세션에서 일어난 이벤트는 애초에 이 조회 대상에 들어오지 않습니다.
마무리
AgentCore 기반 빌링 챗봇이나 비용 관련 에이전트를 다뤄본 입장에서 보면, Dogwood가 메우는 영역은 꽤 유익하다고 생각됩니다.
빌링 에이전트: "하루 환불 누적 한도 초과 시 차단" — 지금까지는 애플리케이션 코드나 Lambda 안에서 직접 카운터를 관리해야 했던 로직을, Gateway 계층의 정책으로 끌어올릴 수 있다.
지원 케이스/티켓 처리 에이전트: "동일 고객에 대해 짧은 시간 내 반복 처리 방지"류의 레이트리밋을 에이전트 코드 수정 없이 Gateway 설정만으로 적용 가능.
승인 워크플로: "승인 없이는 실행 금지" 같은 선행 조건 정책을 코드가 아니라 감사 가능한 정책으로 명시.
아직 프로덕션 집행용 단계가 아니라서 콘솔 사용해보니 자연어로 정책문을 변환하는 기능은 미흡한 영역이 있어서 CLI나 콘솔에서 직접 Cedar 문을 사용하여 작성하는 방법으로 진행하였습니다.
