시스템 프롬프트에 "절대 하지 마"라고 쓰는 일
에이전트에게 위험한 도구를 쥐여 줄 때 가장 먼저 떠오르는 방법은 프롬프트입니다. "환불은 200달러 미만만 처리하세요." 이렇게 적어 두는 거죠.
문제는 이게 부탁이라는 점입니다. 모델이 대부분 지키겠지만, 프롬프트 인젝션 한 번이나 애매한 대화 몇 턴이면 무너질 수 있습니다. 그리고 지켰는지 아닌지를 사후에 로그를 뒤져야 알 수 있습니다.
AgentCore Policy 발표를 읽으며 먼저 확인하고 싶었던 것은 이 지점이었습니다. 규칙이 모델의 추론 안에 있느냐, 밖에 있느냐.
답은 게이트웨이였다
AWS 글에 따르면 Policy는 AgentCore Gateway에서 동작합니다. 에이전트가 도구를 부르면 그 호출이 실제로 실행되기 전에 게이트웨이가 가로채 정책과 대조합니다. 에이전트의 추론 루프 바깥입니다.
이 구조가 중요한 이유는 단순합니다. 모델이 무슨 생각을 했든, 정책에 어긋나는 호출은 실행되지 않습니다. 부탁이 아니라 차단입니다.
정책은 두 가지 방식으로 씁니다.
- 자연어로 쓰면 Cedar 정책으로 바뀝니다.
- Cedar를 직접 써도 됩니다. Cedar는 AWS가 공개한 오픈소스 정책 언어입니다.
글에 나온 예시는 환불 도구입니다. OAuth 토큰에서 refund-agent 역할이 있는 사용자만, 그리고 도구 입력값의 금액이 200달러 미만일 때만 환불 도구 호출을 허용합니다. 사용자 신원과 도구 인자를 한 정책에서 같이 본다는 점이 눈에 띕니다.
바로 막지 않아도 된다
실무에서 반가운 기능은 따로 있었습니다. 정책 엔진을 게이트웨이에 붙일 때 실제로 막을지, 로그만 남길지 고를 수 있습니다.
새 규칙을 운영 중인 에이전트에 바로 적용하면 정상 요청까지 막을 위험이 있습니다. 로그 전용 모드로 며칠 돌려 보고, 걸렸을 요청을 확인한 뒤 차단으로 바꾸는 순서가 가능해집니다.
방화벽 규칙을 다뤄 본 사람에게는 익숙한 절차입니다. 에이전트 통제가 보안 장비와 같은 운영 방식으로 옮겨 오고 있다는 신호로 읽혔습니다.
Evaluations는 운영 중에 채점한다
Policy가 "하면 안 되는 일"을 다룬다면, Evaluations는 "잘하고 있는가"를 다룹니다.
글에 나온 기본 평가 항목은 정확성, 충실성, 유용성, 유해성, 고정관념, 도구 선택과 도구 인자의 정확도 등입니다. 직접 프롬프트와 모델을 골라 맞춤 평가기를 만들 수도 있습니다.
방식이 흥미롭습니다. 실제 운영 중인 대화를 표본으로 뽑아 계속 채점합니다. 데이터는 AgentCore 에이전트 엔드포인트나 CloudWatch 로그 그룹에서 가져오고, 결과는 CloudWatch에 쌓입니다. 점수에 경보를 걸 수 있습니다.
그러니까 "도구 선택 정확도가 지난주보다 떨어졌다"를 대시보드와 알림으로 받는 구조입니다. 모델 버전을 바꾸거나 프롬프트를 고친 뒤 품질이 조용히 내려가는 일을 잡는 데 쓸 수 있겠습니다.
한계로 보이는 지점
Policy는 게이트웨이를 거치는 도구 호출만 봅니다. 에이전트가 게이트웨이를 우회해 직접 부르는 API가 있다면 정책 밖입니다. 결국 모든 도구를 게이트웨이 뒤로 모으는 설계가 먼저 필요합니다.
Evaluations의 LLM 기반 채점도 그 자체로 비결정적입니다. 같은 대화를 두 번 채점하면 점수가 다를 수 있습니다. 점수의 절댓값보다 추세를 보는 용도가 맞을 것 같습니다.
함께 읽을 개념 정리
- Cedar 정책 언어 기초: permit·forbid와 기본 거부 규칙
영상으로 더 보기
AgentCore로 에이전트를 안전하게 운영하는 방법을 다룬 re:Invent 세션입니다.
그 뒤의 소식
발표 당시 두 기능은 프리뷰였습니다. 같은 글에 붙은 갱신 문구를 보면 Policy는 2026년 3월 3일, Evaluations는 3월 31일에 정식 출시됐습니다.
한 가지는 분명해 보입니다. 에이전트 통제의 무게중심이 프롬프트에서 실행 경로로 옮겨 가고 있습니다. 구글이 Next '26에서 Agent Gateway를 내놓은 것도 같은 흐름입니다. 어느 클라우드를 쓰든, 도구 호출이 한 지점을 지나가게 만드는 설계는 지금부터 준비해 둘 만합니다.
