Amazon Bedrock AgentCore 평가, 에이전트 회귀를 실패한 Pull Request로 전환
Amazon은 Amazon Bedrock AgentCore 평가를 실제 동작하는 GitHub Actions 품질 게이트로 전환해, 주관적인 에이전트 점검을 점수가 산정되는 4가지 테스트로 대체했다.
이 참조 파이프라인은 AI 에이전트와 OAuth로 보호되는 Model Context Protocol 서버를 배포한 뒤, 대표 프롬프트로 에이전트를 호출한다. 이어 생성된 트레이스를 평가하고, 필수 지표가 구성된 기준치 아래로 떨어지면 Pull Request를 실패 처리한다.
이는 에이전트 테스트를 둘러싼 논쟁의 구도를 바꾼다. 당장의 경쟁은 AWS와 다른 클라우드 제공업체 간의 대결이 아니다. 많은 개발팀이 여전히 에이전트 변경사항을 병합하기 전에 사용하는 수동 표본 점검에 맞서는 자동화되고 반복 가능한 평가다.
Amazon은 2026년 9월 8일 이 구현을 공개했다. 평가 파이프라인은 AgentCore Runtime, AgentCore Evaluations, Amazon Cognito, CloudWatch, AWS CDK, GitHub Actions를 연결한다.
핵심 결과는 또 하나의 테스트 대시보드가 아니다. 변경된 에이전트 동작이 공유 환경이나 프로덕션에 도달하기 전에, 실패한 응답이 실패한 소프트웨어 빌드로 이어질 수 있게 됐다.
Amazon Bedrock AgentCore 평가가 병합 게이트가 되다
AWS는 에이전트 품질을 검토 시점의 의견에서 Pull Request 조건으로 바꿨다.
참조 워크플로는 main 브랜치를 대상으로 하는 Pull Request에서 에이전트 코드, MCP 서버 코드, 인프라 또는 평가 스크립트가 변경될 때 실행된다. 이 워크플로는 두 개의 AgentCore 런타임을 포함하는 임시 개발 스택을 생성한다.
한 런타임은 Strands 기반 에이전트를 호스팅한다. 다른 런타임은 AI 애플리케이션을 외부 기능과 연결하는 표준 프로토콜을 통해 도구를 노출하는 MCP 서버를 호스팅한다.
공유 Amazon Cognito 사용자 풀은 두 런타임을 모두 보호한다. 워크플로는 AWS Cloud Development Kit를 통해 이 인프라를 배포한 다음, 배포 출력에서 런타임 식별자와 인증 엔드포인트를 읽는다.
GitHub Actions는 OpenID Connect 페더레이션을 통해 임시 AWS 자격 증명을 획득한다. OIDC는 GitHub가 짧은 수명의 ID 토큰을 AWS 역할과 교환할 수 있게 해, 리포지터리 시크릿에 영구 AWS 액세스 키를 둘 필요가 없도록 한다.
워크플로는 여전히 AWS 역할 ARN을 GitHub 시크릿으로 저장한다. 그러나 생성되는 AWS 자격 증명은 임시적이며 역할의 신뢰 및 권한 정책으로 제한된다. GitHub는 이 OIDC 보안 모델을 문서화하고 있다.
배포 후 파이프라인은 두 런타임이 준비 상태가 될 때까지 기다린다. 새로 생성된 런타임은 즉시 요청을 받을 수 없기 때문에 이 대기 과정은 운영상 중요하다.
AWS에 따르면 너무 이른 호출은 424 Failed Dependency 응답을 반환한다. 제공된 워크플로는 AgentCore 제어 서비스를 폴링하고, 테스트 실행을 시작하기 전에 MCP 서버를 워밍업한다.
그런 다음 파이프라인은 OAuth 액세스 토큰을 가져와 에이전트의 HTTPS 엔드포인트로 테스트 프롬프트를 보낸다. 각 프롬프트에는 고유한 세션 식별자가 부여되므로, 평가 프로세스는 생성된 트레이스를 올바른 상호작용과 연결할 수 있다.
샘플 데이터셋은 여러 종류의 동작을 포괄한다. 에이전트에게 간단한 합계를 계산하고, 현재 UTC 시간을 반환하며, Apple 주가를 찾고, 직원 수를 조회하도록 요청한다.
이 예시는 답변 문구 이상을 검증한다. 내장 기능, 공개 MCP 도구, 보호된 비즈니스 도구, 도구 선택, 그리고 선택된 각 도구에 전달되는 매개변수를 테스트한다.
평가 스크립트는 다음 네 가지 내장 평가기를 적용한다.
GoalSuccessRate는 세션이 사용자의 목표를 달성했는지 묻는다.
Correctness는 응답을 이용 가능한 기대값 또는 컨텍스트와 비교한다.
ToolSelectionAccuracy는 에이전트가 적절한 도구를 선택했는지 확인한다.
ToolParameterAccuracy는 에이전트가 적절한 인수를 제공했는지 확인한다.
참조 구성은 0에서 1까지의 척도에서 0.8을 허용 기준치로 사용한다. 필수 점수가 이 기준 아래로 떨어지면 스크립트는 실패로 종료되고 GitHub는 작업을 실패로 표시한다.
워크플로는 평가 결과를 Pull Request에 게시할 수도 있다. 검토자는 로그나 로컬 대화에서 에이전트 동작을 재구성하는 대신, 코드 변경과 함께 측정된 실패를 확인한다.
마지막으로, 정리 단계는 평가가 실패한 경우에도 실행된다. 실패한 Pull Request가 개발 런타임을 무기한 실행 상태로 남기지 않도록 임시 CDK 스택을 삭제한다.
이 과정은 핵심적인 긴장을 만들어낸다. 수동 테스트는 명백한 문제를 발견할 수 있지만, 관련된 모든 Pull Request가 충족해야 하는 재현 가능한 규칙을 제공하는 경우는 드물다.
수동 에이전트 테스트가 압박을 받는 이유
이 파이프라인은 에이전트 응답을 소프트웨어 제공 과정에서 검증해야 할 산출물이 아니라 단순히 검토할 대상으로 여기는 팀에 압박을 가한다.
전통적인 애플리케이션 테스트는 명확한 결과를 가진다. 함수는 기대값을 반환하고, API는 스키마에 맞으며, 데이터베이스 작업은 불변 조건을 유지한다.
AI 에이전트는 이 모델을 복잡하게 만든다. 응답은 달라질 수 있으며, 최종 문장이 올바르다고 해서 에이전트가 허용 가능한 경로를 따랐다는 증거는 아니다.
도구를 사용하는 에이전트는 잘못된 서비스를 선택하거나, 권한 없는 결과를 노출하거나, 잘못된 형식의 매개변수를 보낼 수 있다. 또한 비용이 많이 들거나 안전하지 않은 호출 순서를 통해 그럴듯한 답변에 도달할 수도 있다.
프롬프트 변경도 또 다른 문제를 만든다. 시스템 지침을 조금만 조정해도 관련 없는 시나리오 전반에서 도구 선택, 거부 동작, 응답 상세도 또는 작업 완료 여부가 바뀔 수 있다.
모델 업데이트와 종속성 변경도 유사한 위험을 초래한다. 기존 단위 테스트는 애플리케이션이 실행되는 것은 확인할 수 있지만, 동작의 의미 있는 저하를 놓칠 수 있다.
팀은 종종 수동 프롬프트 세트로 이를 보완한다. 개발자가 익숙한 질문을 여러 개 입력하고 답변을 읽은 뒤, 명백히 잘못된 점이 없어 보이면 병합한다.
이 방법은 적용 범위가 좁고 판단도 일관되지 않다. 또한 두 개의 리비전 사이에서 어떤 동작이 바뀌었는지에 대한 증거도 거의 남기지 않는다.
AWS 파이프라인은 관련된 모든 Pull Request에 공통 평가 경로를 추가한다. 제안된 코드를 배포하고, 해당 코드를 실행하며, 텔레메트리를 수집하고, 동일한 평가기를 적용한다.
AgentCore는 모델 호출, 도구 활동 및 상호작용 내 기타 작업을 구조화한 기록인 OpenTelemetry 스팬과 함께 작동한다. AgentCore Observability는 이러한 트레이스를 CloudWatch로 전송한다.
온디맨드 평가를 위해 파이프라인은 특정 세션의 스팬을 선택해 평가 서비스에 전달한다. 평가 모드에는 온라인 모니터링과 비동기 배치 분석도 포함된다.
이 구분은 제공 팀에 중요하다. 온디맨드 평가는 작고 통제된 상호작용 집합을 대상으로 하고 상세 점수를 반환하므로 Pull Request에 적합하다.
온라인 평가는 다른 목적에 사용된다. 배포된 트래픽을 샘플링하고, 테스트 데이터셋이 예상하지 못한 요청을 실제 사용자가 생성하는 출시 후의 동작을 추적한다.
배치 평가는 더 큰 세션 모음을 처리한다. 기준선 비교, 정기 감사, 변경 전후 분석에 더 적합하다.
Pull Request 게이트는 이러한 모드를 대체하지 않는다. 코드 변경에 가장 가까운 초기의 측정 가능한 검사 지점을 앞당긴다.
이 접근 방식은 회귀에 대응해야 하는 주체도 바꾼다. 게이트가 없으면 품질 팀이나 사용자가 배포 후 문제를 발견하는 경우가 많다.
필수 GitHub 검사가 있으면 작성자는 병합 전에 실패한 동작을 해결해야 한다. 관련 코드와 프롬프트 결정이 아직 생생한 상태에서 피드백을 받게 된다.
이는 공유 에이전트를 유지하는 팀에 특히 유용하다. 한 개발자에게는 수용 가능해 보이는 응답 변경이 다른 그룹이 소유한 도구 워크플로를 망가뜨릴 수 있다.
엄선된 평가 데이터셋은 이러한 기대를 보존할 수 있다. 에이전트가 계속 수행해야 하는 작업의 실행 가능한 기록이 된다.
개발자는 여전히 그러한 기대의 근거가 되는 지원 컨텍스트에 접근할 수 있어야 한다. 엔지니어링 지식 기반은 팀이 평가 사례를 사양, 인시던트, 설계 결정과 연결하는 데 도움이 될 수 있다.
더 큰 변화는 조직적이다. 에이전트 품질은 누군가 충분한 시간이 있을 때 수행하는 선택적 검토가 아니라, 병합 가능한 변경의 정의 일부가 된다.
OAuth는 엔드투엔드 테스트를 점수 산정보다 어렵게 만든다
어려운 부분은 평가 점수를 요청하는 것이 아니다. 보호된 에이전트의 전체 도구 경로를 헤드리스 CI 러너 안에서 재현하는 일이다.
참조 아키텍처는 에이전트와 MCP 서버 모두를 Cognito 뒤에 배치한다. 대화형 사용자는 authorization-code 흐름을 통해 인증하고, 범위와 사용자 지정 역할 클레임을 포함한 토큰을 받는다.
이 역할은 사용자가 접근할 수 있는 MCP 도구를 결정한다. 재무 사용자와 HR 사용자가 자동으로 동일한 비즈니스 기능을 받아서는 안 된다.
GitHub Actions에는 대화형 사용자가 없다. 동의 화면을 열거나, 브라우저 로그인을 완료하거나, 테스트 전반에 걸쳐 개인의 역할 컨텍스트를 유지할 수 없다.
AWS는 이 불일치를 처리하는 세 가지 방법을 제시한다. 각각은 시스템의 다른 부분을 검증한다.
첫 번째 접근 방식은 저장된 트레이스를 평가한다. 스테이징 프로세스가 사전에 에이전트를 호출하고, 대표적인 텔레메트리를 캡처하며, 해당 트레이스를 테스트 픽스처로 저장한다.
Pull Request 작업은 라이브 에이전트나 MCP 서버를 호출하지 않고 픽스처를 평가한다. 이 접근 방식은 예측 가능하며 CI 인증 문제를 피할 수 있다.
하지만 심각한 한계도 있다. 점수는 현재 Pull Request의 에이전트 코드가 아니라, 이전에 캡처된 동작을 설명한다.
저장된 트레이스는 평가기 변경을 검증하거나 과거 기준선을 보존할 수 있다. 새로 변경된 런타임 코드가 여전히 기대한 궤적을 생성한다는 사실은 증명할 수 없다.
두 번째 접근 방식은 전용 서비스 계정을 사용한다. 운영자가 대화형 인증을 한 번 완료하고 해당 refresh token을 시크릿 관리자에 저장한다.
이후 CI는 정의된 역할을 가진 알려진 사용자로 동작할 수 있다. 이를 통해 특정 ID에 대한 권한 경계와 도구 접근을 테스트할 수 있다.
refresh token은 만료되거나 유효하지 않게 될 수 있다. 팀에는 순환, 재인증, 그리고 계정 권한에 대한 신중한 통제가 필요하다.
AWS 구현은 세 번째 경로인 머신 간 인증을 선택한다. Cognito는 OAuth client_credentials grant를 통해 토큰을 발급한다.
평가 스크립트는 클라이언트 ID, 클라이언트 시크릿, 요청된 범위를 Cognito의 토큰 엔드포인트로 보낸다. 이어 반환된 bearer token을 사용해 HTTPS를 통해 AgentCore Runtime을 호출한다.
MCP 미들웨어는 이러한 토큰을 사용자 토큰과 구분한다. 머신 토큰에는 범위는 있지만 사용자 지정 역할 클레임이 없으므로, 샘플은 이 토큰이 모든 도구에 도달하도록 허용한다.
대화형 토큰은 계속 역할을 포함하며, MCP 서버는 이러한 사용자에게 도구 수준 제한을 적용한다. 따라서 동일한 Cognito 풀은 CI 접근과 사람의 권한 부여를 모두 지원한다.
이 설계는 Pull Request의 코드에 대한 라이브 엔드투엔드 테스트를 가능하게 한다. 에이전트는 배포된 MCP 서버를 호출하고 평가를 위한 새 트레이스를 생성할 수 있다.
그러나 역할 적용을 테스트하지는 않는다. CI ID는 설계상 이러한 역할 검사를 우회한다.
그 경계는 이 아키텍처에서 가장 중요한 주의 사항이다. 파이프라인 통과는 머신 ID가 평가된 작업을 완료할 수 있음을 보여 준다. FinanceUser와 HRUser가 서로 다른 권한의 결과를 받는다는 사실까지 보여 주지는 않는다.
두 형태의 보증이 모두 필요한 팀은 별도의 권한 부여 테스트를 추가해야 한다. 특정 역할을 가진 서비스 계정이나 MCP 미들웨어를 직접 테스트하는 방식을 사용할 수 있다.
머신 자격 증명도 민감한 자산이 된다. AWS는 CI 파이프라인과 에이전트 런타임만 이를 획득할 수 있어야 한다고 말한다.
이 주장은 구현 세부 사항에 따라 달라진다. 리포지토리 권한, 워크플로 승인, IAM 정책, 시크릿 노출, 포크 동작, 로그 마스킹이 모두 실제 보안 경계에 영향을 준다.
GitHub의 OIDC 연결은 장기 리포지토리 자격 증명으로부터 AWS 측을 보호한다. 다만 OAuth 클라이언트가 여전히 클라이언트 시크릿을 사용하므로 모든 시크릿을 제거하지는 못한다.
IAM 역할 역시 최소 권한 원칙을 따라야 한다. Cognito, ECR, CDK 리소스, Bedrock, AgentCore에 대한 광범위한 배포 권한은 일반적인 풀 리퀘스트 작업에 필요한 수준보다 더 큰 권한을 만들 수 있다.
환경 보호 기능은 위험을 줄일 수 있다. 팀은 어떤 브랜치와 워크플로가 역할을 인수할 수 있는지 제한하고, 신뢰할 수 없는 변경에는 승인을 요구하며, 배포 역할을 평가 ID와 분리할 수 있다.
따라서 이 아키텍처는 에이전트 동작과 CI 통합을 함께 테스트한다. 권한 부여의 정확성은 여전히 별도의 승인 목표로 남는다.
품질 게이트는 답변뿐 아니라 트레이스도 점수화한다
Amazon Bedrock AgentCore 평가는 에이전트의 최종 텍스트뿐 아니라 작업을 수행하는 경로까지 판단할 수 있기 때문에 중요하다.
평가 스크립트는 AgentCore 스타터 툴킷을 사용해 관련 CloudWatch 트레이스를 수집한다. 그런 다음 선택한 세션에 평가기를 적용한다.
원시 Evaluate API는 하나의 세션에 속한 텔레메트리 스팬 모음인 sessionSpans를 받는다. AWS는 여러 세션의 스팬을 섞으면 검증 오류가 발생한다고 경고한다.
이 세션 경계를 통해 평가기는 상호작용을 재구성할 수 있다. 사용자 입력, 모델 출력, 선택한 도구, 도구 파라미터, 그리고 결과 응답을 검사할 수 있다.
GoalSuccessRate는 세션 수준에서 작동한다. 전체 상호작용이 사용자가 요청한 일을 달성했는지 묻는다.
Correctness는 트레이스 수준에서 응답을 검토한다. 테스트가 제공하는 경우 기대 응답을 사용할 수 있다.
ToolSelectionAccuracy와 ToolParameterAccuracy는 도구 호출 수준에서 작동한다. 올바른 작업을 선택하는 것과 그 작업을 올바르게 호출하는 것을 구분한다.
이 분리는 AWS의 의도적인 회귀 테스트에서 시사적인 결과를 냈다. 작성자들은 에이전트가 항상 도움이 되지 않는 거부 응답을 반환하도록 시스템 프롬프트를 변경했다.
GoalSuccessRate는 0.0으로 떨어졌다. Correctness도 0.0을 기록했고, ToolParameterAccuracy 역시 0.0을 기록했다.
ToolSelectionAccuracy는 여전히 1.0을 기록했다. 에이전트는 전체 요청에는 실패했지만 적절한 도구를 식별할 수 있었던 것으로 보인다.
이 때문에 단일 집계 지표는 문제를 숨길 수 있다. 서로 다른 평가기는 독립적인 차원을 포착하며, 하나의 통과 점수가 모든 실패 동작을 상쇄할 수는 없다.
작성자들이 의도한 시스템 프롬프트를 복원한 뒤 GoalSuccessRate는 1.0으로 돌아왔다. Correctness는 0.9에 도달했고, 두 도구 지표는 모두 1.0에 도달했다.
네 가지 지표는 모두 샘플 임계값인 0.8을 넘었다. GitHub는 풀 리퀘스트 차단을 해제했다.
AgentCore는 기대 동작이 필요한 테스트를 위한 참조 입력도 받는다. 이러한 입력에는 기대 응답, 자연어 단언문, 또는 기대 도구 궤적이 포함될 수 있다.
궤적은 에이전트가 호출해야 하는 도구의 순서를 설명한다. AWS는 다양한 워크플로 제약을 위해 정확한 순서, 순서 준수, 임의 순서 평가기를 제공한다.
정확한 순서 테스트는 각 단계가 이전 단계에 의존하는 프로세스에 적합하다. 임의 순서 테스트는 순서가 정확성에 영향을 주지 않는 독립적인 검색 작업에 적합하다.
이 서비스는 사용자 지정 평가기도 지원한다. 팀은 도메인별 요구 사항을 위해 자체 지침, 심사 모델, 점수 척도를 정의할 수 있다.
코드 기반 평가는 더 결정론적인 선택지를 제공한다. 스키마, 패턴, 키워드, 또는 비즈니스 규칙을 확인할 수 있는 AWS Lambda 함수를 호출한다.
이 조합이 중요한 이유는 모든 요구 사항에 모델 심사자가 필요한 것은 아니기 때문이다. JSON 유효성, 금지된 필드, 최대 호출 횟수, 정확한 식별자는 종종 일반 코드로 처리할 수 있다.
사용자 지정 평가기 가이드에 따르면 평가기는 세션, 트레이스 또는 도구 호출 수준에서 작동할 수 있다. 사용자 지정 로직은 모델이나 Lambda 함수를 사용할 수 있다.
실용적인 게이트는 평가기 유형을 요구 사항에 맞춰야 한다. 모델 기반 점수화는 관련성, 작업 성공, 충실성과 같은 의미적 품질에 적합하다.
결정론적 코드는 이진 제약 조건에 적합하다. 도구 궤적 검사는 기대되는 워크플로 구조에 적합하다.
가장 좋은 신호는 이러한 방법을 결합할 때 나온다. 응답은 의미적으로 올바르면서도 스키마를 위반할 수 있고, 유효한 스키마도 관련 없는 답변을 담을 수 있다.
정답 데이터 역시 신중하게 사용해야 한다. 특히 요약이나 개방형 분석에서는 모든 허용 가능한 답변이 하나의 정확한 표현을 갖는 것은 아니다.
단언문은 하나의 응답을 강제하지 않고도 반드시 포함되어야 할 사실이나 동작을 표현할 수 있다. 기대 궤적은 문체와 독립적으로 도구 동작을 명시할 수 있다.
이로써 테스트 세트는 단순한 프롬프트 모음 이상의 것이 된다. 각 시나리오는 응답, 작업, 도구 수준에서 성공의 의미를 정의할 수 있다.
통과 점수에도 사각지대는 있다
이 게이트는 정의된 회귀를 포착하지만, 신뢰성은 테스트 범위, 점수 안정성, ID 설계, 운영 타이밍에 달려 있다.
AWS는 전체 파이프라인에 약 10분이 걸린다고 말한다. 배포, 런타임 시작, 트레이스 전파, 모델 기반 평가가 이 시간을 차지한다.
이 정도 시간은 많은 풀 리퀘스트에 허용 가능하다. 그러나 로컬 pre-commit 검사로는 너무 느리고, 업데이트가 잦은 리포지토리에서는 비용이 커질 수 있다.
트레이스 가용성은 불확실성을 더한다. AWS는 에이전트 호출 후 30~90초의 전파 지연을 관찰했다.
참조 스크립트는 최대 10분 동안 30초마다 재시도한다. 따라서 CloudWatch를 즉시 쿼리하면 트레이스가 존재하기 전에 실패한 것처럼 보일 수 있다.
런타임 아키텍처는 또 다른 구현 난관을 만든다. AgentCore Runtime은 ARM64 컨테이너 이미지를 요구하는 반면, 표준 GitHub 호스팅 러너는 x86-64 프로세서를 사용한다.
워크플로는 크로스 플랫폼 이미지 빌드를 위해 QEMU와 Docker Buildx를 사용한다. 이 요구 사항은 빌드 시간을 늘리고 에이전트 품질과 무관한 또 다른 실패 지점을 도입한다.
가장 중요한 한계는 모델 기반 판단에서 나온다. LLM 평가기는 같은 트레이스를 여러 번 평가할 때 조금씩 다른 점수를 부여할 수 있다.
따라서 엄격한 컷오프는 임계값 근처에서 불안정한 풀 리퀘스트를 만들 수 있다. 의미 있는 코드 차이 없이도 한 실행은 0.81로 통과하고 다른 실행은 0.79로 실패할 수 있다.
AWS는 승인 임계값과 원하는 신뢰성 목표 사이에 여유를 둘 것을 권장한다. 또한 팀은 검사를 필수로 만들기 전에 평가기 분산을 측정해야 한다.
반복 실행은 그 분산을 추정할 수 있지만 평가 사용량도 늘린다. 참조 예제는 다섯 개 프롬프트에 네 개 평가기를 사용하므로, 하나의 풀 리퀘스트에서 심사 모델 호출 20회를 생성한다.
출처는 이러한 호출의 가격을 제시하지 않는다. 다만 리포지토리와 데이터셋이 커짐에 따라 팀이 Bedrock 사용량을 모니터링할 것을 권고한다.
테스트 범위는 익숙하지만 더 날카로운 문제를 제시한다. 품질 게이트는 데이터셋에 포함된 시나리오만 측정한다.
편리한 네다섯 개의 프롬프트로는 모든 프로덕션 요청, 권한 상태, 실패 모드, 언어, 적대적 입력을 대표할 수 없다.
샘플의 머신 토큰은 모든 도구에 접근할 수 있다. 그 결과 엔드투엔드 실행은 역할 제한 도구가 일반 사용자로부터 계속 보호된다는 사실을 증명하지 못한다.
광범위한 점수는 불균일한 성능도 감출 수 있다. 전체 평균은 통과하더라도 하나의 중요한 시나리오가 실패할 수 있다.
고위험 작업에는 시나리오 수준의 요구 사항이 있어야 한다. 급여 작업, 계정 삭제, 개인정보 조회는 여러 쉬운 산술 프롬프트의 성공으로 통과해서는 안 된다.
지표에도 소유자가 필요하다. 개발자는 누가 임계값 변경을 승인하고, 새 시나리오를 추가하며, 평가기 간 불일치를 조사하는지 알아야 한다.
그렇지 않으면 실패한 게이트는 임계값을 낮추라는 압력으로 이어질 수 있다. 그러면 조직은 측정을 약화해 배포 속도를 유지하게 된다.
잘못된 확신도 또 다른 위험이다. 녹색 체크 표시는 테스트된 버전이 특정 시점에 명시된 기준을 통과했음을 보여 준다.
모든 응답을 인증하거나, 프롬프트 인젝션을 제거하거나, 배포된 테스트 스택 밖의 인프라를 검증하지는 않는다. 또한 보안 검토를 대체하지도 않는다.
사용자는 큐레이션된 데이터셋이 놓친 조합을 찾아낼 것이므로 프로덕션 텔레메트리는 여전히 필수다. AgentCore의 온라인 평가는 실시간 세션을 샘플링하고 결과를 CloudWatch에 게시할 수 있다.
결과 문서에 따르면 온라인 점수는 CloudWatch 지표로 표시된다. 상세 평가 이벤트는 전용 로그 그룹에 저장된다.
그런 다음 배치 평가는 모델, 프롬프트 또는 도구 변경 전후의 더 큰 기간을 비교할 수 있다. 이러한 비교는 하나의 풀 리퀘스트 실행보다 더 강력한 기준선을 제공한다.
성숙한 시스템은 이러한 단계를 연결해야 한다. 프로덕션 실패는 새로운 평가 시나리오가 되어야 하며, 반복되는 CI 실패는 에이전트 설계에 반영되어야 한다.
품질 게이트는 데이터셋이 사고와 함께 진화할 때 가장 신뢰할 만하다. 정적인 벤치마크는 결국 신뢰할 수 있는 동작보다 테스트에 대한 익숙함을 보상하게 된다.
첫 GitHub Actions 게이트 이후 주목할 점
다음 시험대는 팀이 이러한 게이트를 필수 검사로 만들 만큼 안정적이고, 보안을 고려하며, 충분히 대표성 있게 만들 수 있는지 여부다.
첫 번째 신호는 풀 리퀘스트 워크플로에서 정답 데이터와 결정론적 평가를 도입하는 것이다. 네 가지 기본 제공 지표는 유용한 출발점이지만, 모든 비즈니스 규칙을 표현하지는 못한다.
팀이 고가치 시나리오에 기대 응답, 단언문, 도구 궤적을 추가하는지 지켜봐야 한다. Lambda 기반 검사의 사용 증가는 에이전트 평가가 일반적인 소프트웨어 검증으로 자리 잡고 있음을 보여 줄 것이다.
이러한 발전은 Amazon Bedrock AgentCore 평가의 근거를 강화할 것이다. 하나의 모델 심사자에 대한 의존을 줄이고 일부 실패를 더 쉽게 재현할 수 있게 한다.
두 번째 신호는 역할 인식 CI 범위다. AWS는 선택한 흐름이 사용자 역할 검사를 우회하기 때문에 머신 토큰의 한계를 공개적으로 지적한다.
팀은 불안정한 리프레시 토큰 작업을 만들지 않으면서 서로 다른 사용자 ID를 테스트하는 패턴을 공개해야 한다. 서비스 계정, 직접 권한 부여 테스트, 격리된 테스트 테넌트가 가능한 경로다.
역할별 검사가 일반화되면 이 아키텍처는 완전한 엔드투엔드 보증에 더 가까워질 것이다. 분리된 상태로 남거나 부재한다면, 녹색 에이전트 점수는 권한 부여 정확성에 대해 거의 말해 주지 못한다.
세 번째 신호는 풀 리퀘스트 게이트와 프로덕션 결과의 연결이다. 작은 개발 데이터셋은 실제 세션의 피드백 없이는 대표성을 유지할 수 없다.
낮은 점수의 프로덕션 트레이스를 검토된 회귀 사례로 승격하는 워크플로를 지켜봐야 한다. 온라인 모니터링은 실패를 발견하고, 큐레이션된 CI 테스트는 그러한 실패의 재발을 막아야 한다.
AWS의 데이터셋 평가 도구도 관련된 발전이다. 데이터셋 러너는 에이전트를 호출하고, 텔레메트리를 기다린 뒤, 조정된 프로세스를 통해 시나리오를 평가할 수 있다.
더 폭넓은 도입은 현재 참조 워크플로에서 보이는 사용자 지정 오케스트레이션을 줄일 것이다. 또한 더 크고 버전 관리되는 평가 세트를 더 쉽게 유지할 수 있게 할 것이다.
개발자들에게 실질적인 질문은 더 이상 에이전트 응답을 테스트해야 하는지 여부가 아닙니다. 어떤 동작이 병합을 차단해야 하는지, 어떤 동작은 모니터링이 필요한지, 그리고 어떤 동작은 결정론적으로 강제해야 하는지가 핵심입니다.
롤백, 보안 사고 또는 비즈니스 워크플로 중단을 초래할 수 있는 실패부터 시작하세요. 각 실패에 명확한 시나리오와 위험 수준에 맞는 평가 방법을 부여해야 합니다.
그다음 의도적으로 에이전트를 망가뜨리고, 예상한 이유로 게이트가 실패하는지 확인하세요. 검증 항목은 알려진 회귀를 포착한 뒤에야 신뢰할 수 있게 됩니다.
Amazon은 프롬프트 테스트에서 필수 GitHub 상태 검사로 나아갈 수 있는 신뢰할 만한 경로를 제시했습니다. 이제 다음 단계는 엔지니어링 팀의 몫입니다. 배포를 거부할 동작을 정의하고, 이를 코드로 구현하며, 그 정의를 최신 상태로 유지해야 합니다.
