AWS AgentCore Optimization preview, AI 에이전트 운영이 ‘품질 루프’ 경쟁으로 넘어갔다

Amazon Bedrock AgentCore Optimization이 public preview로 나오면서 AI 에이전트 운영의 경쟁 축이 “만들 수 있는가”에서 “품질을 계속 개선할 수 있는가”로 옮겨가고 있다.

AWS가 에이전트 개선 루프를 제품 기능으로 묶었다

AWS는 2026년 5월 4일 Amazon Bedrock AgentCore Optimization public preview를 공개하며, 프로덕션 에이전트의 실행 흔적을 바탕으로 시스템 프롬프트와 도구 설명을 개선하는 흐름을 제안했다. 공식 블로그의 핵심 문장은 비교적 분명하다. 에이전트가 출시 시점에는 잘 작동해도 모델, 사용자 행동, 프롬프트 재사용 맥락이 바뀌면 품질이 조용히 떨어지고, 지금까지 많은 팀은 사용자의 불만이 나온 뒤 traces를 읽고 가설을 세워 수동으로 고치는 방식에 의존했다는 것이다.

AgentCore Optimization은 이 과정을 Recommendations, configuration bundles, A/B testing으로 나눠 제품화한다. Recommendations API는 CloudWatch Log group에 쌓인 에이전트 traces를 읽고, 목표 evaluator를 기준으로 시스템 프롬프트나 tool descriptions의 개선안을 만든다. Configuration bundles는 시스템 프롬프트, model IDs, tool descriptions를 버전이 고정된 설정 묶음으로 저장한다. A/B testing은 기존 설정과 새 설정을 나눠 적용해 goal success rate, tool selection accuracy, helpfulness, safety 같은 지표가 실제로 좋아졌는지 본다.

새 기능의 단위는 코드 수정이 아니라 설정 개선이다

흥미로운 점은 AWS가 이 기능을 “에이전트 코드를 다시 짜주는 기능”으로 설명하지 않는다는 점이다. 공식 문서는 tool description recommendation이 도구 구현을 건드리지 않고 설명을 선명하게 다듬는다고 밝힌다. 즉 이번 preview의 중심은 런타임 코드를 바꾸는 자동 개발자가 아니라, 이미 운영 중인 에이전트의 프롬프트와 도구 설명을 더 검증 가능한 설정 단위로 다루는 운영 도구다.

품질 저하를 전제로 한 발표다

AI 에이전트 시장은 지금까지 데모와 출시 속도에 집중해 왔다. 하지만 실제 서비스에서는 같은 프롬프트가 새로운 입력, 새로운 사용자, 새로운 모델 버전, 바뀐 외부 도구 앞에서 다르게 실패한다. AgentCore Optimization은 이 실패를 예외가 아니라 정상 운영 조건으로 본다. 그래서 “더 똑똑한 모델을 붙이면 된다”가 아니라 “traces, evaluator, 설정 버전, 실험군을 연결해야 한다”는 방향을 제시한다.

왜 지금 중요한가: 에이전트 운영의 병목이 평가로 이동한다

이번 발표가 중요한 이유는 생성형 AI 도입의 난제가 모델 호출 자체에서 운영 품질 관리로 옮겨가고 있음을 보여주기 때문이다. 기업은 이미 챗봇, 내부 검색, 고객 응대, 업무 자동화, 개발 보조 에이전트를 만들 수 있다. 문제는 그 에이전트가 어제보다 오늘 더 나빠졌는지, 특정 도구 선택을 잘못하는지, 안전하지 않은 응답을 늘렸는지, 사용자군별로 어떤 설정이 더 나은지 지속적으로 알아내는 일이다.

AgentCore Optimization은 평가와 개선을 별도 보고서가 아니라 런타임 운영 루프 안으로 끌어들인다. AgentCore Evaluations가 작업 수행, edge case 처리, 출력 안정성을 측정하는 품질 신호를 제공하고, Optimization은 그 신호를 reward signal처럼 사용해 개선 후보를 만든다. 여기에는 built-in evaluator, ground-truth comparison, custom LLM-as-judge scoring이 들어갈 수 있다.

LLM-as-judge는 편하지만 검증이 필요하다

custom LLM-as-judge는 에이전트 품질 평가를 빠르게 만들 수 있지만, 그 자체가 완전한 정답지는 아니다. judge prompt가 모호하면 보상 신호가 흔들리고, 특정 문체나 장황한 답변을 과대평가할 수 있으며, 안전성 점수와 업무 성공 점수가 충돌할 수도 있다. 따라서 팀은 “judge가 좋아한다고 출시한다”가 아니라 holdout set, 실패 사례 샘플링, 사람 리뷰, 실제 업무 지표를 함께 묶어야 한다.

A/B 테스트는 에이전트 변경의 안전장치가 된다

AI 에이전트 설정 변경은 일반 웹 버튼 색상 실험보다 위험할 수 있다. 새 시스템 프롬프트가 성공률을 올리면서도 비용을 키우거나, 특정 도구를 덜 호출해 중요한 확인 절차를 생략할 수 있기 때문이다. AgentCore의 A/B testing 접근은 이런 변경을 한 번에 전면 배포하지 않고, 설정 묶음을 비교하면서 효과와 부작용을 보게 만든다는 점에서 의미가 있다.

실제로 쓰려면 traces부터 설계해야 한다

이 기능을 실무에 적용하려면 먼저 에이전트가 어떤 traces를 남기는지부터 정리해야 한다. Recommendations API가 CloudWatch Log group을 바라본다는 것은 로그가 단순한 오류 문자열 저장소가 아니라 품질 개선의 입력 데이터가 된다는 뜻이다. 어떤 사용자 요청이 들어왔는지, 어떤 도구 후보가 있었는지, 실제 선택한 도구는 무엇인지, 중간 판단이 어디에서 흔들렸는지, 최종 결과가 성공인지 실패인지가 적절히 남아야 한다.

팀은 최소한 네 가지를 분리해 봐야 한다. 첫째, 성공 기준이다. 예를 들어 환불 안내 에이전트라면 올바른 정책 링크 제시, 고객 유형 판별, 승인 필요 상황의 escalation, 금지 문구 회피 같은 기준을 명시해야 한다. 둘째, 평가 데이터다. 실제 운영 로그만 보면 자주 들어오는 쉬운 질문에 과적합될 수 있으므로 edge case와 실패 사례를 별도로 보관해야 한다. 셋째, 설정 버전이다. 어떤 prompt와 tool description 조합이 어느 기간에 쓰였는지 모르면 결과 비교가 불가능하다. 넷째, 배포 기준이다. 성공률, 안전성, 지연 시간, 비용, escalation 비율 중 무엇이 일정 기준 이상 나빠지면 중단할지 정해야 한다.

VIBE 코딩에서는 검증 계약을 먼저 써야 한다

VIBE 코딩 팀이 이 흐름을 활용한다면 “에이전트를 개선해줘”라고 맡기는 것보다 “이 평가 기준과 이 실패 사례에서 tool selection accuracy를 개선하되 안전성 점수와 평균 지연 시간은 악화시키지 말라”는 식으로 검증 계약을 먼저 써야 한다. 자연어 지시는 여전히 중요하지만, 운영 가능한 자연어 지시는 평가 가능한 조건을 포함해야 한다.

CloudWatch와 설정 묶음의 역할

CloudWatch Logs는 단순 모니터링 화면이 아니라 추천 생성의 입력 위치가 된다. Configuration bundles는 프롬프트와 모델, 도구 설명을 코드 배포와 느슨하게 분리한다. 이 조합은 빠른 설정 실험을 가능하게 하지만, 동시에 변경 승인과 감사 기록의 기준을 더 엄격하게 만든다. 누가 어떤 evaluator를 선택했고, 어떤 recommendation을 받아들였으며, 어떤 실험 결과로 배포했는지 남겨야 한다.

위험은 자동 최적화의 착시에서 온다

AgentCore Optimization은 에이전트 운영을 성숙하게 만드는 방향이지만, 자동 개선이라는 표현은 쉽게 과신을 부른다. 추천이 만들어졌다는 사실은 품질 향상을 의미하지 않는다. 특정 reward signal을 높이기 위해 응답이 짧아지거나, 도구 호출을 피하거나, 안전한 fallback을 남용하거나, 테스트 데이터에만 맞는 표현으로 수렴할 수 있다. 이는 전통적인 reward hacking 문제가 에이전트 설정 운영에도 들어오는 모습이다.

또 하나의 제약은 preview 상태다. 공식 문서는 AgentCore Optimization이 public preview이며 기능과 API가 general availability 전에 바뀔 수 있다고 밝힌다. 또한 preview 기간에는 이 기능의 API calls가 CloudTrail event history나 configured trails에 나타나지 않고, 추후 지원될 예정이라고 설명한다. 규제 산업이나 감사 요건이 강한 조직은 이 점을 특히 조심해야 한다.

비용은 없지만 사용량은 생긴다

문서상 AgentCore Optimization 자체에는 별도 요금이 없고 underlying AgentCore capabilities 사용분에 비용을 낸다. 하지만 추천 생성, 평가, 실험, 로그 저장, 모델 호출은 모두 운영 비용과 시간을 만든다. “무료 preview 기능”으로만 볼 것이 아니라 품질 루프를 돌리는 데 필요한 데이터 정리, 평가 설계, 실험 승인, 모니터링 비용을 함께 계산해야 한다.

사람의 승인 지점은 사라지지 않는다

프롬프트와 도구 설명이 자동으로 개선 후보를 받더라도, 실제 배포는 사람이 승인해야 한다. 특히 결제, 의료, 법률, 인사, 보안처럼 에이전트 실수가 곧 사용자 피해로 이어지는 영역에서는 recommendation을 바로 적용하는 방식이 위험하다. 추천은 가설이고, batch evaluation과 A/B testing은 증거이며, 운영 승인 기준은 별도로 남아야 한다.

개발팀이 확인할 체크리스트

AI 에이전트를 이미 운영 중인 팀이라면 이번 preview를 보며 세 가지 질문을 던져야 한다. 첫째, 현재 에이전트 실패를 사용자가 알려주기 전에도 감지할 수 있는가. 둘째, 프롬프트와 도구 설명 변경이 코드 변경처럼 버전과 근거를 남기는가. 셋째, 평가 지표가 실제 사용자 가치와 안전성을 동시에 반영하는가.

바로 도입하지 않더라도 준비할 일은 분명하다. 운영 로그에서 개인정보나 민감 업무 정보를 줄이면서도 품질 판단에 필요한 구조적 신호를 남기는 방법을 정해야 한다. 에이전트 작업별 success rubric을 만들고, 실패 사례를 보관하며, evaluator prompt를 리뷰 대상으로 올려야 한다. 변경 전후 비교를 위해 설정 ID, 모델 ID, tool description 버전을 결과와 함께 저장하는 습관도 필요하다.

작은 파일럿부터 시작해야 한다

가장 안전한 시작점은 고객 영향이 낮고 평가 기준이 분명한 내부 에이전트다. 예를 들어 문서 검색 에이전트의 “올바른 내부 정책 문서 찾기”, 개발 보조 에이전트의 “정확한 테스트 파일 추천”, 운영 보조 에이전트의 “장애 런북 단계 분류”처럼 성공과 실패를 사람이 확인하기 쉬운 작업부터 실험하는 편이 낫다. 여기서 추천 품질, judge 안정성, 비용, 지연 시간, rollback 기준을 검증한 뒤 더 중요한 업무로 넓히는 순서가 현실적이다.

다음 관전 포인트는 표준화와 감사 가능성이다

AgentCore Optimization의 방향은 AWS만의 제품 기능을 넘어 에이전트 운영 표준 경쟁을 보여준다. 앞으로 기업은 모델 선택만 비교하지 않고, traces를 어떻게 수집하는지, evaluator를 어떻게 구성하는지, 설정을 어떻게 버전 관리하는지, 실험과 배포 승인 로그가 남는지까지 플랫폼 선택 기준으로 보게 될 가능성이 크다.

특히 에이전트가 외부 도구를 호출하고 장기 작업을 수행하는 흐름에서는 “품질 개선 루프”가 보안과 비용 통제의 일부가 된다. 잘못된 도구 설명 하나가 잘못된 호출로 이어질 수 있고, 과도하게 낙관적인 judge가 실제 위험을 낮게 평가할 수 있다. 따라서 이번 발표의 핵심은 새 버튼 하나가 아니라 에이전트 운영을 소프트웨어 릴리스처럼 다루는 사고방식이다. VIBE 코딩 관점에서도 중요한 결론은 같다. 자연어로 만들고, traces로 관찰하고, evaluator로 측정하고, 실험으로 검증한 뒤에만 배포하는 팀이 더 오래 살아남는다.

짧은 출처

• AWS ML Blog
• AgentCore Optimization
• AgentCore Overview
• AgentCore Product