도구 호출이 유효해도 틀릴 수 있다 — AWS Dogwood의 정책 기반 거버넌스
백엔드 시스템에서 외부 API나 내부 서비스를 호출할 때, 우리는 보통 "이 요청이 문법적으로 올바른가?"를 먼저 따진다. 하지만 실무에서 진짜 문제는 그다음에 온다. 요청이 유효하더라도, 그 동작이 비즈니스 규칙 관점에서 허용 가능한가? AWS가 오픈소스로 공개한 Dogwood는 바로 이 질문에 답하기 위한 정책 언어이자 참조 인터프리터다.
왜 도구 호출 시퀀스 제어가 필요한가
기존의 입력 유효성 검사나 인증/인가 레이어는 단일 요청 수준에서 동작한다. 요청 파라미터가 올바른지, 토큰이 유효한지를 본다. 그러나 여러 도구 호출이 연속으로 이어지는 시나리오에서는 각각의 호출이 모두 유효하더라도, 호출의 순서나 조합이 비즈니스 규칙을 위반할 수 있다.
예를 들어, 주문 취소 API를 호출하기 전에 반드시 환불 가능 여부 확인 API가 선행되어야 한다는 규칙이 있다고 하자. 기존 방식으로는 이를 강제하려면 각 서비스 로직 안에 상태 체크 코드를 직접 심어야 한다. 이는 도메인 로직과 거버넌스 규칙이 뒤섞이는 결과를 낳고, 규칙이 바뀔 때마다 코드 전체를 수정해야 하는 부담으로 이어진다.
Dogwood의 접근 방식 — 정책을 코드 밖으로 분리
Dogwood는 이 문제를 정책을 별도 레이어로 외부화함으로써 해결한다. 개발자는 어떤 도구 호출 시퀀스가 허용되는지를 정책 언어로 선언적으로 기술하고, 참조 인터프리터가 런타임에 이를 평가한다.
// 예시: 환불 확인 없이 주문 취소 불가 정책 (의사 코드)
policy OrderCancellation {
require: checkRefundEligibility called before cancelOrder
deny: cancelOrder if refundEligibility == false
}
이 구조는 Java 백엔드 관점에서 매우 익숙한 패턴이다. Spring Security의 인가 설정이나 OPA(Open Policy Agent)처럼, 비즈니스 로직과 정책 평가를 분리해 각각 독립적으로 변경할 수 있게 한다. 서비스 코드는 "무엇을 해야 하는가"에만 집중하고, 정책 레이어는 "어떤 조건에서 허용되는가"를 담당한다.
오픈소스 참조 구현체이기 때문에, 자체 인프라나 기존 배포 파이프라인에 통합하는 것도 가능하다. AWS 종속 없이 정책 엔진을 직접 운영할 수 있다는 점은 엔터프라이즈 환경에서 특히 의미 있다.
실무 적용 관점에서의 시사점
4년차 이상의 백엔드 개발자라면, 비즈니스 규칙이 코드 곳곳에 흩어지면서 생기는 유지보수 비용을 잘 안다. Dogwood가 제시하는 방향은 다음 세 가지 실무 원칙과 맞닿아 있다.
- 관심사 분리(Separation of Concerns): 정책 평가를 서비스 레이어에서 분리해 독립적으로 관리
- 감사 가능성(Auditability): 어떤 정책이 적용됐고 왜 허용/거부됐는지 추적 가능한 구조 확보
- 유연한 규칙 변경: 코드 배포 없이 정책만 업데이트해 거버넌스 규칙을 즉시 반영
특히 마이크로서비스 아키텍처에서 서비스 간 호출 흐름이 복잡해질수록, 이런 중앙화된 정책 레이어의 필요성은 커진다. Dogwood는 그 구현 방법에 대한 하나의 구체적인 레퍼런스가 된다.
정리
- 도구 호출의 유효성과 비즈니스 허용 가능성은 다른 문제이며, Dogwood는 후자를 정책 언어로 선언적으로 제어한다
- 정책을 서비스 로직 밖으로 외부화하면 코드 변경 없이 거버넌스 규칙을 독립적으로 관리할 수 있다
- 오픈소스 참조 구현체로 제공되어 자체 인프라에 통합 가능하며, 마이크로서비스 환경의 호출 시퀀스 거버넌스에 실질적인 적용 가치가 있다