AgentCore A/B 테스트 공개, 프롬프트 수정도 배포 실험으로

AI 요약

• 무슨 일: AWS가 Amazon Bedrock AgentCore Optimization preview를 공개했습니다.
  • production trace와 evaluation output으로 system prompt 또는 tool description 추천안을 만들고, batch eval과 A/B test로 검증합니다.
• 개발자 영향: 프롬프트 수정이 문장 편집이 아니라 versioned configuration과 release experiment가 됩니다.
• 주의점: preview 문서는 Optimization API가 아직 CloudTrail을 지원하지 않는다고 경고합니다.
  • audit trail이 필요한 production workload는 기능 범위와 승인 절차를 먼저 확인해야 합니다.

AWS가 2026년 5월 4일 AI Blog에서 Amazon Bedrock AgentCore Optimization preview를 소개했습니다. 발표의 중심은 새 모델이 아니라 에이전트 품질을 고치는 방식입니다. AWS는 production trace와 evaluation output을 읽어 system prompt 또는 tool description 개선안을 만들고, 그 후보를 batch evaluation과 AgentCore Gateway의 A/B test로 검증하는 루프를 공개했습니다. AWS What's New 공지는 이 기능을 2026년 4월 30일 preview launch로 먼저 정리했습니다.

이 발표가 개발자에게 직접 닿는 이유는 prompt tuning의 위치가 바뀌기 때문입니다. 지금까지 많은 팀은 agent가 실패하면 trace를 열고, 사람이 prompt를 고치고, 몇 개 테스트 대화로 확인한 뒤 배포했습니다. AWS 블로그는 이 과정을 "developer가 performance engine이 되는" 상태로 설명합니다. AgentCore Optimization은 같은 일을 API와 Gateway, evaluation dataset, configuration bundle로 나눕니다. 에이전트 품질 수정이 문장 편집에서 release candidate 관리로 이동합니다.

AWS 문서의 첫 구성 요소는 Recommendations입니다. 개발자는 CloudWatch Logs에 쌓인 agent trace와 target evaluator를 지정합니다. AgentCore는 failure pattern을 분석하고, 선택한 reward signal을 기준으로 system prompt 또는 tool description 개선안을 생성합니다. docs는 recommendation이 LLM으로 생성되므로 적용 전에 review와 test가 필요하다고 적습니다. 즉 AWS가 "자동 수정"을 판매하는 것이 아니라 "검토할 후보를 만든다"는 경계를 둔 셈입니다.

tool description recommendation은 특히 에이전트 운영에서 자주 보이는 실패를 겨냥합니다. agent가 비슷한 tool 사이에서 잘못 고르거나, 사용자의 요청이 여러 sector를 걸칠 때 엉뚱한 tool을 호출하는 문제가 생깁니다. AWS 블로그의 Market Trends Agent 예시는 투자 브로커의 risk profile, sector interest, conversation style을 다루는 agent입니다. 이 agent가 personalization에 실패하거나 sector query에서 tool 선택을 틀리면, Optimization은 trace와 evaluator를 기준으로 tool description을 더 선명하게 다듬는 후보를 냅니다.

둘째 구성 요소는 configuration bundle입니다. AWS docs는 bundle을 runtime ARN에 연결된 model ID, system prompt, tool description의 versioned immutable snapshot으로 설명합니다. 같은 agent runtime에서 prompt만 바꾸는 경우에는 새 code deploy 없이 bundle version을 바꿔 실험할 수 있습니다. 반대로 framework upgrade나 tool implementation 변경처럼 code가 바뀌는 실험은 별도 runtime endpoint를 만들어 비교해야 합니다. 이 구분은 작지만 실무적입니다. "prompt만 바꿨다"와 "agent code를 바꿨다"가 같은 배포 단위로 섞이면 rollback과 원인 분석이 어려워집니다.

셋째 구성 요소는 batch evaluation입니다. AWS는 curated dataset으로 새 configuration을 baseline과 비교하라고 안내합니다. 여기에 들어가는 test case는 이미 알고 있는 실패 유형, compliance 요구 조건, 자주 쓰이는 workflow, 과거 incident에서 뽑은 사용자 요청이 될 수 있습니다. 이 단계는 production traffic을 건드리기 전에 regression을 잡는 역할을 합니다. 코딩 에이전트 팀이라면 "같은 issue를 받고 같은 repository에서 같은 test를 통과하는가"처럼 반복 가능한 fixture를 만들 수 있습니다.

넷째 구성 요소는 A/B testing입니다. AgentCore Gateway가 live traffic을 control과 treatment로 나누고, online evaluation이 각 session을 채점합니다. AWS docs는 결과에 confidence interval과 p-value가 포함된다고 설명합니다. variant는 두 가지 방식입니다. configuration-only change라면 같은 runtime에 다른 bundle version을 넣습니다. code change, framework upgrade, 완전히 다른 agent implementation 비교라면 서로 다른 gateway target을 둡니다. 이 구조는 agent 실험을 일반 웹 A/B test와 비슷하게 보이게 만들지만, score가 click이나 conversion이 아니라 evaluator output이라는 점이 다릅니다.

AWS가 이번 preview에서 강조한 단어는 improvement loop입니다. trace가 평가로 들어가고, evaluation이 quality drop을 드러내며, recommendation이 수정안을 만들고, batch evaluation과 A/B test가 검증한 후보만 promote됩니다. 이 루프가 작동하면 agent 팀의 대화가 바뀝니다. "이번 prompt가 더 좋아 보인다"가 아니라 "어떤 evaluator에서 몇 점이 올랐고, 어떤 fixture에서 regression이 없었으며, live traffic test가 어떤 신뢰구간을 보였는가"를 물을 수 있습니다.

다만 preview 범위는 좁게 읽어야 합니다. AWS docs는 Optimization이 public preview이고 API가 일반 출시 전 바뀔 수 있다고 적습니다. 별도 Optimization 과금은 없지만, underlying AgentCore capability 비용은 계속 발생합니다. 더 중요한 단서는 CloudTrail입니다. AWS 문서는 Optimization preview API call이 아직 CloudTrail event history나 configured trail에 나타나지 않으며, support가 추가될 예정이라고 경고합니다. CloudTrail audit trail이 필수인 workload에는 이 기능을 쓰지 말라고 명시합니다.

이 CloudTrail 단서는 enterprise agent 운영에서 작지 않습니다. Agent prompt와 tool description은 코드보다 가벼워 보이지만, 실제로는 agent 행동을 바꾸는 control surface입니다. "refund tool을 언제 호출하는가", "database query tool을 어떤 조건에서 쓰는가", "고객에게 어떤 disclaimer를 붙이는가"가 prompt와 tool description에 들어갈 수 있습니다. 이런 변경이 preview API로 생성되고 bundle로 배포된다면, 승인 기록과 감사 로그가 제품 외부에서라도 남아야 합니다.

Recommendation도 과신하면 안 됩니다. AWS docs가 review와 test를 요구하는 이유는 LLM-generated configuration이 새로운 실패를 만들 수 있기 때문입니다. system prompt는 한 evaluator를 올리면서 다른 evaluator를 낮출 수 있습니다. 예를 들어 helpfulness를 높이는 문장이 safety evaluator에는 불리할 수 있고, tool description을 자세히 쓰면 latency와 token cost가 늘어날 수 있습니다. AWS가 향후 multiple evaluator trade-off를 다루겠다고 적은 부분은 이 문제가 이미 제품 설계에 들어와 있다는 뜻입니다.

AgentCore Optimization은 기존 LLMOps 도구와도 겹칩니다. LangSmith, Braintrust, Langfuse, Honeycomb, Datadog 같은 도구는 trace, evaluation, observability를 이미 다룹니다. Promptfoo나 OpenAI Evals 같은 프로젝트는 prompt와 agent behavior test를 CI에 넣는 방식을 제공합니다. AWS의 차별점은 이 루프를 AgentCore Runtime, Gateway, CloudWatch, configuration bundle 안에 묶는다는 점입니다. AWS 계정 안에서 agent를 운영하는 팀에는 통합이 장점입니다. 여러 cloud와 framework를 섞는 팀에는 vendor boundary가 검토 대상입니다.

커뮤니티 반응은 아직 조용합니다. Reddit r/aws에서는 AgentCore eval integration을 공유하는 글과 Bedrock prompt caching 질문이 보입니다. 대형 model release처럼 Hacker News 상단을 오래 차지한 발표는 아닙니다. 조용한 이유는 기능의 성격 때문입니다. AgentCore Optimization은 데모 영상에서 화려한 "agent가 앱을 만든다" 장면을 보여주는 제품이 아니라, production agent가 틀렸을 때 누가 trace를 읽고 어떤 후보를 배포할지 정하는 운영 도구입니다.

그래서 이 발표는 AI agent 시장의 다음 질문을 보여줍니다. 2025년과 2026년 초의 경쟁은 agent가 code를 읽고 browser를 열고 tool을 호출할 수 있는지에 집중했습니다. 이제 production 팀은 agent가 시간이 지나며 나빠질 때 어떤 signal로 감지하고, 어떤 수정안을 만들며, 그 수정안이 실제 traffic에서 나아졌는지 어떻게 증명할지 묻습니다. AgentCore Optimization은 이 질문을 AWS식 control plane으로 묶은 답입니다.

개발팀이 지금 확인할 항목은 분명합니다. 첫째, agent trace가 CloudWatch와 OpenTelemetry-compatible shape로 충분히 남는지 봐야 합니다. 둘째, evaluator가 실제 business risk를 반영하는지 점검해야 합니다. 셋째, prompt와 tool description 변경을 code review와 같은 승인 절차에 넣어야 합니다. 넷째, preview 단계의 CloudTrail 미지원 때문에 audit requirement가 있는 환경에서는 별도 change log를 마련해야 합니다.

이 기능이 성공하려면 좋은 추천안보다 좋은 실패 데이터가 먼저 필요합니다. AgentCore는 trace에서 failure pattern을 읽지만, trace가 빈약하면 추천도 빈약합니다. evaluation dataset이 대표성을 잃으면 batch evaluation은 false confidence를 줍니다. live A/B test의 online evaluator가 실제 사용자 피해를 늦게 잡으면 p-value는 운영 안전을 대신하지 못합니다. AWS가 제공한 루프는 도구이고, 루프 안에 들어가는 데이터와 승인 기준은 여전히 팀의 책임입니다.

그럼에도 방향은 중요합니다. 에이전트가 production 업무를 맡는 순간, prompt는 문서가 아니라 배포물입니다. tool description은 설명문이 아니라 routing policy입니다. model ID는 성능 옵션이 아니라 비용과 latency, compliance의 변수입니다. AgentCore Optimization preview는 이 세 가지를 configuration으로 versioning하고, trace와 evaluator로 고치며, Gateway traffic split으로 검증하는 제품 언어를 제시했습니다. 에이전트 운영의 기준은 이제 "잘 대답했나"에서 "변경을 어떻게 검증하고 되돌릴 수 있나"로 옮겨가고 있습니다.