AI 에이전트에 대한 신뢰 구축: 아마존 Bedrock AgentCore를 활용한 생산적 평가 프레임워크

북쪽 별

AI 에이전트를 배포하려는 모든 조직은 같은 문제에 직면합니다. 아름답게 작동하는 에이전트가 실제 환경에서 점차 저하되면, 인간이 알아차릴 때쯤에는 신뢰가 이미 깨져 있습니다. 전통적인 소프트웨어는 큰 문제를 일으킬 때, 에이전트는 조용히 실패합니다. 그들은 자신감 있게 보이고 유창하게 읽히지만 틀린 답을 내놓습니다. 그런 답이 실제 비즈니스 결정에 영향을 미치면, 문제는 고장 난 기능이 아니라 사용자와의 관계가 깨진 것입니다.

그것이 바로 품질 문제의 핵심입니다. 따라서 과제는 단 한 번만 작동하는 에이전트를 만드는 것이 아니라, 모든 서브-에이전트, 모든 워크플로우, 모든 릴리스에서 대규모로 계속해서 작동할 수 있도록 증명하는 것입니다. 에이전트 시대에서 성공할 팀들은 품질을 최종 QA 단계가 아닌 에이전트 자체의 운영 시스템으로 취급할 것입니다. 즉, 지속적으로 측정되고, 자동으로 보호되며, 모든 상호작용과 함께 개선되는 것입니다. 이 글에서 우리는 Amazon Bedrock AgentCore를 사용하여 대규모로 생산에 적합한 에이전트형 솔루션을 구축하는 지속적인 품질 루프를 어떻게 만들었는지 보여줍니다.

비즈니스 문제

이 솔루션은 내부 사용을 위해 Amazon Bedrock AgentCore 및 기타 AWS 서비스를 활용합니다. 따라서 판매자와 영업 리더는 Amazon Quick을 통해 직접적인 영어로 비즈니스 질문을 할 수 있습니다. 이러한 단일 경험 뒤에는 여러 전문화된 하위 에이전트가 함께 작동합니다: 지역별 수익 및 성과를 위한 Performance Insights Agent, 고객 인텔리전스를 위한 Customer Insights Agent, 기본 데이터셋을 통한 텍스트에서 SQL로의 데이터 분석을 위한 Data Insights Agent, 그리고 직접적인 대시보드 접근도 포함됩니다. 답변은 각 사용자의 영역과 역할 수준의 보안에 따라 제한됩니다. 현장 팀은 이러한 답변을 활용하여 계정 전략을 계획하고 고객 회의를 준비하는 데 도움을 받습니다. 따라서 숫자들은 정확해야 합니다. 가장 해로운 실패는 시스템 붕괴가 아니라, 조용히 잘못된 답변입니다. 출시 전에 고객 인사이트 에이전트를 평가했을 때, 바로 그런 것을 발견했습니다.

• 고객의 3개월간 서비스 수익 중 410.08달러가 “410.08백만 달러”로 보고되었습니다.
• 조정 제외된 매출 수익으로 표시된 매출 수익이라고 보고되었습니다.
• 데이터에서 어디에도 나타나지 않는 연간 재규격 수익 추정치가 제시되었습니다.
• 그는 자체적인 계산 결과를 사실로 제시했다.

다양한 실행을 통해 모니터링이 정상 상태를 유지했습니다. 이는 시스템이 반응했다는 것을 보여주었지, 해답이 올바른지는 아닙니다.

이러한 오류가 발견되지 않은 채 배포된다면, 플랫폼은 그 비용을 부담해야 했을 것입니다. 과장된 수치를 반복하는 판매자는 고객의 신뢰를 잃게 됩니다. 바로 이 때문에 우리는 출시 전에 그 문제를 발견했습니다. 위험은 출시 때 끝나지 않고, 새로운 에이전트와 데이터, 프롬프트, 코드, 모델의 변경이 발생할 때마다 증가합니다. 또한 출시 없이도 위험이 증가하는데, 상류 파이프라인이 매주 데이터를 갱신하기 때문입니다. 조정된 배포는 관련된 위험을 초래합니다: 데이터 변경, 도구 변경, 그리고 연동된 프롬프트 업데이트가 함께 배포될 예정이지만 각각 따로 발생할 경우, 시스템은 모든 변경 사항이 일치할 때까지 불일치 상태로 작동합니다. 한 가지 준생산 테스트에서, 그 불일치 기간만으로도 통과율이 78%에서 38%로 떨어졌습니다. 이러한 실패를 포착하기 위해, 배포 전과 운영 중에 지속적으로, 답변이 정확하고 타당한지 확인할 수 있으며, 각 실패가 데이터, 프롬프트 또는 에이전트의 코드에서 근본 원인으로까지 추적될 수 있는 프레임워크가 필요합니다.

AWS에서 영업, 마케팅, 글로벌 서비스(SMGS) 운영 팀은 전 세계 AWS 현장 영업을 지원하는 생산적인 멀티 에이전트 시스템을 개발했습니다. 이 시스템은 두 가지 다른 대상 그룹을 지원합니다. 현장 영업 팀에게는 수시간에 걸리는 수동 데이터 분석 작업을 즉각적이고 대화형의 지능으로 대체하여, 영업자들이 자신의 비즈니스 상황을 파악하고 위험과 기회를 발견하며 더 빠르게 조치를 취할 수 있도록 도와줍니다. 리더십을 위해, 이 시스템은 주간 비즈니스 리뷰(WBR)를 포함한 비즈니스 관리 프로세스를 지원하며, 수동적인 보고서 작성 없이 포트폴리오 전반의 중요 신호를 제시합니다. 같은 에이전트 기반 시스템은 현장에서 서비스를 제공하는 직원과 규모로 성과를 검토하는 리더 모두에게 사용됩니다.

에이전트 시스템은 각각 독특한 역량 영역을 가진 다양한 전문 하위 에이전트 포트폴리오를 조직합니다. 그 중에는 성능 인사이트 에이전트가 복잡한 판매 데이터로부터 자연어 형태의 비즈니스 인텔리전스를 생성하여 원시 지표를 실제로 활용 가능한 판매자 인사이트로 변환합니다. 고객 인사이트 에이전트는 제품 사용, 지원 이력, 계약 상태, 참여 데이터 등을 종합하여 각 고객에 대한 360도 관점을 구축함으로써 판매자들이 고객의 여정에서 어느 단계에 있는지와 다음에 필요한 것이 무엇인지를 파악할 수 있도록 도와줍니다. 데이터 인사이트 에이전트는 텍스트에서 SQL로 변환하는 에이전트로, 계정 팀이 단 한 줄의 SQL도 작성하지 않고 구조화된 분석 데이터를 간단한 영어로 조회하는 데 사용합니다. 이 세 가지 에이전트가 이 글의 나머지 부분에서 언급되는 바입니다.

규모가 큰 환경에서 이러한 에이전트들을 신뢰할 수 있게 조정하는 것은 한 가지를 명확하게 했습니다. 즉, 에이전트의 품질은 나중에 관리해야 할 운영적 문제가 아니었습니다. 그것은 작동하기 위한 전제 조건이었습니다. 하나의 저하된 서브-에이전트는 모든 응답을 조용히 손상시킬 수 있으며, 기존의 모니터링 방식으로는 이를 감지할 수 없습니다. 이러한 현실로 인해 전체 생명주기 평가 프레임워크는 선택적이 아닌 필수적인 것이 되었습니다. AgentCore Evaluations는 Amazon Bedrock AgentCore의 기능 중 하나로, Amazon Bedrock Guardrails(보안), Amazon CloudWatch(메트릭, 알림, 추적), Amazon Simple Storage Service(Amazon S3), Amazon Redshift(평가의 지속성), Amazon Quick(대시보드), 그리고 AWS Lambda(사용자 정의 평가자)과 함께 이를 작동시키는 연결 조직입니다.

이 글에서 우리는 기업 규모에서 AI 에이전트를 운영하는 데 있어 가장 어려운 운영 과제를 어떻게 해결했는지, 그리고 Amazon Bedrock AgentCore Evaluations이 에이전트 품질의 기반이 되는 방법에 대해 공유합니다. 구체적으로는 다음과 같은 내용을 다룹니다:

• 엔티티는 다른 규칙을 따릅니다 – 왜 엔티티들은 다른 운영 규율을 요구하는지, 그리고 왜 전통적인 모니터링(지연 시간, 오류율, 가동 시간)이 가장 중요한 장애를 놓치게 만드는지.
• 전체 여정을 위한 지도 – 에이전트코어 평가를 기반으로 구축된 9단계 평가 프레임워크는 초기 커밋부터 상용화까지 에이전트 개발 라이프사이클의 모든 단계를 포함합니다.
• 이론에서 실제로 – 구체적인 패턴들(연속 통합 및 연속 배포(CI/CD) 회귀 게이트, 캐너리 점수 산출, 이동 감지, 자동화된 피드백 루프)과 AgentCore 평가가 각각의 패턴을 어떻게 지원하는지 정확히.
• 실제로 중요한 지표 – 우리 에이전트 포트폴리오의 배포 신뢰도 향상, 회귀 방지, 반복 속도에 대한 측정 가능한 영향.

왜 에이전트들은 체계적인 평가 프레임워크가 필요한가요?

전통적인 소프트웨어는 결정적입니다. 같은 입력이 같은 출력을 생성합니다. 머신러닝 모델은 확률적 출력을 도입했으며, MLOps는 그 모델의 훈련, 버전 관리, 모니터링 및 재훈련을 관리하기 위해 등장했습니다. AI 에이전트는 세 번째 수준의 운영 복잡성을 추가합니다. 즉, 자율적인 다단계 추론으로, 질문은 “무언가가 고장 났나?”에서 “에이전트가 전체 추론 과정 전반에 걸쳐 적절한 결정을 내리고 있는가?”로 바뀝니다.

에이전트들은 이전 에이전트들의 어려운 문제들을 계승하며, 새로운 문제들도 추가합니다. 이들은 비결정적이며, 동일한 입력에 대해 서로 다른 추론 경로를 따릅니다. 라우팅, 도구 선택, 합성 과정에서 연쇄적인 결정이 이루어지는데, 단 하나의 단계가 실패하면 모든 하위 과정이 손상될 수 있습니다. 가장 중요한 것은, 이들이 조용히 저하된다는 점입니다. 지연 시간은 낮고 오류율은 일정하지만, 에이전트의 응답 품질은 악화됩니다. 왜냐하면 에이전트는 여전히 응답하고 있기 때문입니다. 단지 잘못된 응답을 하고 있을 뿐입니다.

에이전트 평가는 바로 그 것을 포착하는 방법입니다. 이는 다섯 가지 측면을 포함합니다: 안전성(정의된 범위 내에서 작동하는가?), 품질(에이전트가 올바르고 일관되며 타당한 응답을 제공하는가?), 성능(빠르고 신뢰할 수 있는가?), 비용(크기에서 효율적으로 작동하는가?), 그리고 운영 제어(문제를 빠르게 감지하고 진단하며 해결할 수 있는가?). 성숙한 평가 방식은 에이전트의 전체 생명주기 동안 지속적으로 다섯 가지 측면을 다룹니다.

이 글에서는 생산용 다중 에이전트 시스템에서 다섯 가지 평가 기준을 어떻게 실제로 적용하는지 공유합니다. 안전과 보안이 우리의 최우선 과제입니다. 안전 기준을 충족하지 못하면 어떤 에이전트도 출하되거나 계속 작동하지 않습니다. 품질은 이 글에서 가장 많은 부분을 차지하는데, 다섯 가지 기준 중 가장 제어하기 어렵고 전용 프레임워크의 혜택을 가장 많이 받기 때문입니다. 하지만 품질이 안전보다 더 중요하지는 않습니다. 성능, 비용, 운영 제어도 이와 함께 생명주기의 모든 단계에 통합되어 있습니다. 특히 이 프레임워크는 에이전트 계층의 모든 수준에서 적용됩니다. 툴 수준에서는 각 기능(고객 식별 도구, 그래프 검색 도구)마다 별도의 평가 계약이 존재합니다. 에이전트 수준에서는 각 하위 에이전트가 전체적으로 평가됩니다. 다중 에이전트 수준에서는 오케스트레이션 경로가 에이전트 간의 일관성, 올바른 라우팅, 합성 정확도 측면에서 평가됩니다.

아홉 단계는 세 가지 수준에서 동시에 적용되며, 이 계층 구조는 이 제품에만 특화된 것은 아닙니다. 새로운 생산 에이전트를 구축하거나 통합할 때 이 정신 모델이 적합합니다. 대부분의 팀은 에이전트 수준에서 평가를 시작하고 그곳에서 멈추지만, 에이전트 수준의 품질은 사용하는 도구에 따라 달라집니다. 다중 에이전트 시스템은 두 수준만으로는 볼 수 없는 세 번째 실패 지점을 만들어냅니다. 강력한 평가 관행은 세 단계로 구성되며, 각 단계마다 고유한 황금 세트, 고유한 평가자, 그리고 9단계를 거치는 고유한 승진 기준이 존재합니다.

에이전트 평가 프레임워크: 9단계, 하나의 폐쇄 루프

이 아홉 단계는 에이전트의 생명주기를 첫 번째 커밋부터 실제 운영까지 추적하며, 각 단계는 팀이 에이전트를 성숙시킬 때 직면하는 문제에 대한 답을 제공합니다.

에이전트 생명주기와 9가지 일반적인 질문들

각 팀의 생산 에이전트를 개발할 때, 에이전트가 성숙해질수록 다음과 같은 문제들이 발생합니다:

1단계: 기반 구축: “좋은 것이 어떻게 보일까?”

2단계: 실험: “어느 버전이 더 좋나요?”

3단계: 병합(CI): “무언가를 깨뜨렸나요?”

4단계: 게이트 (CD): “제작에 안전한가요?”

5단계: 카나리아: “무언가 조용히 부서졌나요?”

6단계: 적: “누군가 그것을 깨려고 한다면 어떻게 할까?”

7단계: 드리프트: “품질이 라이브에서 드리프트되고 있는가?”

8단계: 펄스: “지금 그것이 제대로 작동하고 있는지 어떻게 알 수 있나요?”

9단계: 피드백 루프: “어떻게 자동으로 더 좋아지는가?”

AgentCore Evaluations를 사용하여 에이전트 생명주기의 각 단계에 맞는 프레임워크를 구축합니다. 이 아홉 단계는 별도의 도구들이 나중에 결합된 것이 아닙니다. 이들은 그림 1에서 보듯, 첫 번째 커밋부터 생산적 응답까지의 전 과정에 걸쳐 AgentCore Evaluations에 의해 평가되는 단일한 연속적인 평가 표면上的 아홉 지점입니다.

그림 1: Define부터 Improve까지의 9단계 AgentCore 평가 여정

이것은 어떻게 처리하는지에 대한 내용입니다: 효과적인 패턴, 그 뒤에 있는 AgentCore 서비스, 그리고 시스템 설계의 그림 2에서 보여지는 실제 운영 모습입니다.

그림 2: AgentCore 평가 프레임워크의 시스템 설계

1단계: 기반 구축. 품질을 정의합니다.

에이전트를 평가하는 기반은 올바른 도구를 선택하는 것이 아닙니다. 중요한 것은 올바른 질문을 하는 것입니다: 이 에이전트에게 성공이란 무엇인가, 그리고 에이전트가 실패했는지 어떻게 알 수 있는가? 답은 모델이 아니라 고객으로부터 나와야 합니다. 이는 반복적인 과정입니다. 에이전트가 실제로 운영 중에 어떤 행동을 하는지를 관찰함에 따라 성공에 대한 우리의 정의가 더욱 명확해졌습니다. 여기에 정의된 모든 내용(실패 임계값, 평가기 스택, 골든 세트, 안전 규칙, 지연 예산, 비용 목표)은 이후 각 단계가 준수해야 하는 약정입니다. 1단계가 모호하다면, 모든 후단 게이트는 추측에 의존해야 합니다.

단계 1.1: 먼저 비즈니스 지표를 정의하세요. 에이전트가 제공해야 할 내용을 파악하는 것부터 시작하세요. 두 최종 사용자 페르소나는 성공을 다르게 정의합니다:

• 판매자에게 성공이란, 적절한 세부 수준과 적절한 시점에 정확하고 최신 정보를 바탕으로 고객과의 대화에 참여하는 것을 의미합니다.
• 리더십에 있어 성공이란 긴 수동적 준비 과정 없이 신뢰할 수 있는 주간 및 업계 간 리뷰 데이터를 제공하는 것을 의미합니다. 이는 모델 속성이 아닌 비즈니스 결과입니다.

1.2단계: 해당 비즈니스 지표를 평가 지표로 번역합니다. 각 결과에 대해 에이전트가 그것을 전달했음을 확인하는 신호를 식별합니다. 각 신호는 명시적인 임계값과 경보 조건이 있는 추적 지표가 됩니다. 정확한 계정 정보는 실체 해결 정확도와 기반률에 해당합니다. 판매자 신뢰는 충실도와 환각률에 해당합니다. 판매자 행동은 유용성과 범위 준수에 해당합니다. 리더십 검토의 신뢰성은 정확도 통과율과 응답 커버리지에 해당합니다. 이 번역은 다섯 가지 차원을 포함해야 합니다: 품질 임계값과 함께 안전 보호 규정 정책을 정의하고, 각 도구와 에이전트별로 p50, p90, p99 지연 목표를 설정하며, 쿼리당 비용 예산을 책정하고, 경보가 발생하는 시점과 어떤 운영 매뉴얼을 트리거하는지 결정하는 서비스 수준 협약(SLA)을 정의합니다.

정확성 면에서, 해결책이 수익 결정, 갱신 전략, 경영진 검토에 직접적으로 영향을 미치기 때문에 기준은 높습니다. 자신감 있게 잘못된 답변은 판매자의 시간을 낭비할 뿐만 아니라 실제 비즈니스 상황에서 잘못된 결정을 초래합니다. 우리는 실제 생산 오류로부터 파생된 여섯 가지 실패 유형을 정의하며, 이 중 어느 하나라도 응답이 부정확하다고 판단됩니다.

• 지표 교체: 올바른 고객 및 기간이지만, 잘못된 지표가 반환되었습니다. 100개의 응답당 발생 횟수로 집계됩니다.
• 잘못된 기간 표시: 한 시간 창의 데이터가 다른 것으로 표시되는 경우가 있습니다. 예를 들어, 연도별 비교(YoY) 수치를 월별 비교(MoM)로, 또는 그 반대의 방식으로 판매자에게 제시됩니다. 올바른 기간을 명시하여 %로 추적합니다.
• 잘못된 엔티티: 계정 이름이나 자회사들을 혼동시킨 것. 엔티티 해결 정확도 %로 추적됨.
• 순수한 환상: 근거가 없는 형체로, 출처를 찾을 수 없음. 기반률 %.으로 추적됨.
• 잘못된 기호: 올바른 측정 단위, 잘못된 통화 또는 단위 기호. 범위 준수율 %로 추적됨.
• 승인되지 않은 계산: 원본 데이터에 없는 허가되지 않은 추출된 수치. 100개의 응답당 발생 횟수로 기록됨.

전체 정확도 통과율이 주요 지표입니다. 각 차원별 추적이 이를 실제로 적용 가능하게 만듭니다. 정확도 외에도 응답 관련성, 신뢰성, 유용성, 지시사항 따르기, 도구 선택 정확도도 추적됩니다. 세 개의 단락에 걸쳐 올바른 답을 포함하거나 너무 늦게 도착하는 경우도 판매자가 실패로 간주됩니다.

단계 1.3: 해당 지표를 반영하는 평가기 스택을 구축합니다. 단일 평가기 유형만으로는 가능한 다양한 장애 모드를 모두 커버할 수 없습니다. 우리는 네 가지 유형을 결합합니다.

• AgentCore 내장 평가기는 광범위한 기본적인 커버리지를 제공합니다. 관련성, 정확성, 유용성은 AgentCore 평가에 natively 제공되는 평가 템플릿과 직접 연관됩니다.
• 사용자 정의 평가기, 우리 분류 체계에서 각 실패 유형마다 하나씩: 지표 교체 평가기, 잘못된 기간 평가기, 잘못된 고객 평가기, 순수한 착각 평가기, 잘못된 기호 평가기, 그리고 무단 계산 평가기. 이 여섯 가지 중 어떤 것도 기본 템플릿으로 처리되지 않습니다. 이들은 에이전트코어 프레임워크 위에 구축된 특정 도메인에 맞는 신호입니다. 기본 템플릿이 이미 처리하는 지표와 사용자 정의 평가기가 필요한 지표를 미리 알고 있는 것도 설계 결정의 일부입니다.
• 제3자 평가자들에 대해서는, DeepEval과 AutoEval이라는 제3자 오픈소스 라이브러리에서 제공하는 관리형 평가자를 배포했습니다.
• 결정론적 평가자은 정확한 답이 알려져 있는 경우에 사용되며, 예로는 수익, 갱신일, 계약 상태 등이 있습니다.

논리적 품질과 유용성에 대해 단일한 정확한 답이 없는 경우, 우리는 관련성, 신뢰성, 유용성에 대한 내장된 기준을 사용하는 LLM-as-judge 기준을 채택하며, 전체적으로 맞춤화된 기준도 지원합니다. AgentCore Evaluations는 기본적인 사실에 대한 평가와 LLM-as-judge 평가를 모두 natively 제공하므로, 저희는 스스로 점수 산출 엔진을 구축하지 않고도 두 가지 평가 방식을 모두 적용할 수 있습니다. Deterministic는 사실에 대한 정확성을 제공하며, LLM-as-judge는 논리적 범위를 제공합니다.

단계 1.4: 평가 지표를 테스트하기 위한 골드 세트를 구축합니다. 도구 수준에서는 각 중요한 도구마다 고정된 기반 진실 쌍이 존재합니다. 고객 식별은 정확한 기준 객체로 해석되어야 하며 그렇지 않으면 실패합니다. 엔티티 수준에서는 실제 사용자 질문에 대한 주제 분석을 통해 네 가지 유형의 질문(종합적, 보고, 추론, 모호함)에 대한 데이터셋을 생성하며, 각 유형은 서로 다른 평가 전략이 필요합니다. 이는 매월 재검토됩니다. 멀티엔티티 수준에서는 엔드투엔드 오케스트레이션 시나리오에서 엔티티들이 상호작용할 때만 나타나는 오류를 포착합니다. 골드 세트는 단순한 품질 데이터셋이 아닙니다. 안전 테스트 케이스, 지연 벤치마크 케이스, 비용 참조 케이스도 포함되어 있어, 단계 3과 4에서는 동일한 큐레이션된 데이터셋을 기준으로 다섯 가지 차원을 검토할 수 있습니다.

골든 세트는 세 가지 출처로부터 만들어진 생명체와 같은 문서입니다. 생산 환경에서 발생한 경우들은 실제 판매자 및 리더십 관련 질문들로부터 샘플링된 것이며, 이 중에는 단계 7에서 추천된 낮은 점수를 받은 실제 세션도 포함됩니다. 실패로 인한 경우들은 스테이징이나 생산 환경에서 발견된 모든 회귀 현상으로부터 온 것이며, 이 중에는 단계 3에서 추천된 시나리오와 단계 9에서 추천된 영구적인 회귀 보호 장치도 포함됩니다. 합성 edge case들은 우리가 알고 있지만 실제 환경에서 마주하게 될 것 같지 않은 시나리오들을 포괄할 수 있도록 의도적으로 만들어졌습니다. 예를 들어 위에 언급된 네 가지 질문 유형과 4단계에서의 부모-하위 관계 및 틱스크립트 기호 구분 사례 등이 있습니다. 이 집합은 버전 관리가 되며, 검토를 거쳐 세 개의 소스를 통해 지속적으로 확장됩니다.

2단계: 실험. 어떤 버전이 승리하는지 알아내기

모든 변경 사항(프롬프트 업데이트, 새로운 도구, 모델 업그레이드, 데이터셋 갱신)은 같은 질문을 제기합니다: 이 버전이 실제로 더 나은가? 글로벌 규모로 AWS 분야를 지원하는 시스템에서는 직감으로 답할 수 없습니다.

변경 사항이 통합되기 전에, 우리는 AgentCore On-Demand Evaluation을 실행하여 동일한 황금 세트와 동일한 평가자 스위트를 사용하여 점수를 매깁니다. 개발 팀은 품질, 지연 시간, 비용 지표 및 컨텍스트 토큰을 활용하여 하위 수준 비교를 선정하며, 이는 그림 3에서 보듯 다섯 가지 차원에 걸쳐 동시에 평가됩니다. 정확도는 5% 향상되지만 지연 시간은 두 배가 되고 비용은 세 배가 되는 모델은 자동으로 승자가 아닙니다.

그림 3: AgentCore On-Demand 평가에서 두 가지 후보 에이전트 응답의 품질, 지연 시간, 비용 측면의 맞춤형 비교. 그림에 나타난 숫자와 값은 예시적입니다.

우리는 품질을 종합적인 점수로 추적합니다. 단일 숫자로는 부족합니다. 통과율만으로는 충분하지 않습니다. 각 평가 실행 시에는 우리의 분류 체계 내 모든 실패 범주에 대한 상세한 분석이 제공됩니다. 품질이 개선되었는지뿐만 아니라, 어디서, 왜 그런지도 점수표 4번에서 확인할 수 있습니다. 모든 평가 결과도 완전히 기록됩니다: 입력 데이터, 출력 결과, 검색된 컨텍스트, 점수 및 평가 이유가 S3와 우리의 데이터 리포지토리에 저장되어, 실패 원인을 추적할 수 있는 지속적인 관찰층을 제공합니다. 에이전트가 무엇을 보았는지, 무엇을 생성했는지, 왜 실패했는지를 알 수 있습니다. 3개월간의 집중적인 반복 작업을 통해 이 점수표 덕분에 통과율은 93%에서 안정적인 96%로 향했습니다. 순수한 환각은 10,000개의 응답 중 138개에서 52개 미만으로 감소했으며, 무단 계산은 59개에서 44개 미만으로 감소하여 검색이 정확했으며, 개선은 생성 과정의 수정을 통해 이루어졌음을 확인했습니다. 각 범주별 상세 분석과 그 뒤에 있는 자세한 추적 데이터가 없었다면, 우리는 무작위로 반복 작업을 진행했을 것입니다.

그림 4: 각 카테고리별 실패 비율 및 통과율 추세가 표시된 평가 점수표. 그림에 있는 숫자와 값은 예시용입니다.

3단계: 병합 (CI). 병합 시 재발을 방지하기

3단계는 제작 전 단계입니다. 이 단계는 스테이징 환경에서 실행되며, 코드와 설정 변경에 의해 트리거됩니다. 그 임무는 실제 생산 환경에 도달하기 전에 나쁜 변경을 차단하는 것입니다. 3단계가 문제가 발생한 경우, 아무것도 배포되지 않습니다.

엔지니어나 과학자들은 시스템을 여러 가지 방식으로 변경합니다: 프롬프트, 기반 데이터, 도구 또는 모델입니다. 이러한 변화는 지역적으로 깔끔해 보이지만, 기술 계정에 대한 응답을 개선하는 프롬프트는 금융 서비스 계정에 대한 응답을 조용히 악화시킬 수 있습니다. 자동화된 게이트가 없으면 이런 일이 발생합니다.

우리의 CI 평가는 AgentCore On-Demand Evaluation을 사용하여 매번 스테이짓 배포 시 자동으로 실행됩니다. 엔지니어들은 평가를 수행하도록 기억할 필요가 없습니다. 어떤 배포도 무시로 게이트를 통과할 수 없습니다. 평가는 전체 golden set이 아닌 sentinel set만을 검토하므로 몇 분 안에 완료됩니다. 속도는 의도적인 것입니다: sentinel은 모든 배포에서 실행될 수 있을 만큼 좁지만 가장 중요한 문제를 발견할 수 있을 만큼 충분히代表性이 있습니다.

센티넬 세트는 다섯 가지 차원에 걸친 가장 위험한 시나리오들로 구성된 선별된 목록입니다. 허용 범위를 초과하는 품질 저하는 배포를 방해합니다. 안전 한계 위반도 마찬가지로 심각한 문제입니다. p90 지연 시간을 두 배로 증가시키는 변경 사항은 의도적인 결정 없이는 진행되지 않습니다. 토큰 비용의 급증은 규모가 커질 때 발생하기 전에 경고됩니다. 각 센티넬 실행 시, 품질 점수, 지연 시간, 쿼리당 비용, 안전 통과율과 함께 커스터마이즈 메트릭으로 CloudWatch에 점수가 게시됩니다. 또한 모든 실행 후에 이러한 메트릭들이 발행되며, CloudWatch 알람은 어떤 메트릭이 Stage 1 임계값을 초과할 경우 작동하도록 설정되어 있습니다. 각 실행은 로그에도 기록되고 저장되며, 이를 통해 Stage 8 및 Stage 9에 의존하는 감사 트래일이 구성됩니다. 우리는 각 레벨마다 별도의 센티넬을 유지합니다: 도구, 에이전트, 멀티-에이전트. 에이전트 수준의 품질을 향상시키지만 중요한 도구의 성능을 저하시키는 변화는 여전히 차단됩니다. 센티널은 매월 검토되며, 프로덕션에 도달하는 문제가 발생하면 즉시 영구적인 사례로 승격되어 사용자에게 두 번째로 전달되지 않게 됩니다.

이것이 감지하는 사례의 한 예입니다. 데이터 정규화 업데이트 후, 명명 분리 도구가 일부 계정 이름 형식에 대해 해결되지 않은 엔티티를 반환하기 시작했습니다. 에이전트는 해결되지 않은 엔티티를 받고 최선의 추측을 통해 응답했으며, 잘못된 고객에게 실제 데이터를 제공했습니다. 우리의 도구 수준 센티널에는 바로 이런 종류의 예외 상황이 포함되어 있습니다: 영향을 받는 계정 이름 형식에 대한 엔티티 해결 기반 진실 검사가 실패했으며, 배포는 자동으로 차단되었습니다. 이 변경은 생산 환경에 도달하지 않았습니다.

4단계: 게이트 (CD). 양적 신뢰를 바탕으로 선박을 운용하라

센티널은 15가지 경우를 커버합니다. 생산은 수만 가지의 쿼리 패턴을 수백 가지의 계정 유형, 지역, 판매자 세그먼트에 걸쳐 처리합니다. 센티널을 제거하는 것이 필요합니다. 그러나 그것만으로는 충분하지 않습니다.

후보자가 배포되기 전에, 우리는 평가자 각 요소에 걸쳐 전체 골든 세트에 대해 AgentCore On-Demand Evaluation을 실행합니다. 이를 Quality Gate라고 합니다. 이는 “잘 되는 것 같다”는 판단 대신 정량적인 배포 결정으로 대체됩니다.

샌드박스 실행 및 도구 모음링. 이는 실시간 호출이 아닌 재생 과정으로 생각해야 합니다. 사전에 정확한 도구 동작 방식을 나타내는 버전화된 데이터셋을 고정합니다. 게이트 과정에서 후보자가 실행하는 모든 도구 호출은 실제 시스템 대신 그 고정된 데이터셋으로 가로막혀 응답됩니다. 이 고정된 데이터셋은 두 단계로 만들어집니다. 첫째, 각 도구를 개별적으로 테스트합니다: 정확한 답이 이미 알려진 황금 세트의 입력 데이터를 전달하여 실제 반응과 비교해 점수를 산출합니다. 이를 통해 에이전트가 참여하기 전에 도구 자체가 제대로 작동하는지(엔티티 해결, 검색, SQL 생성 등) 알 수 있습니다. 둘째, 도구의 응답이 정확하다고 확인된 후, 그 검증된 답을 에이전트가 게이트 평가 중에 보는 재생 데이터셋으로 고정합니다. 이로써 에이전트는 도구의 속도나 가용성이 아닌 단순히 자신의 추론 능력만으로 테스트되며, 모든 후보자가 같은 고정된 데이터셋을 사용하므로 상대방과의 점수 차이는 도구의 차이가 아닌 에이전트의 성능에 의한 것입니다.

종합적인 종단간 점수 평가. 게이트는 또한 전체적인 통합 점수를 부여합니다: 후보자 에이전트는 200개의 문제를 종단간에 완벽하게 답해야 하며, 모든 평가 기준을 아우르는 LLM-기반 판정 체계에 의해 점수가 매겨집니다. 세 가지 조건 중 하나라도 발생하면 게이트가 자동으로 닫히게 됩니다: 종합 점수가 후보자 자신의 이전 성과와 비교하여 하락하거나, 현재 생산 기준을 초과하지 못하거나, 200개의 문제 중 지정된 백분율 이상이 각 문제당 임계값 이하로 떨어집니다. 후보자는 세 가지 조건 모두를 통과해야 합니다. 이는 단순한 평균으로는 드러나지 않는 것을 포착합니다: 평균은 향상되지만 개별 문제의 대부분에서 실패하는 모델은 통과할 수 없습니다.

이것이 포착하는 내용의 한 예시입니다. 여기서는 에이전트의 자체 추론을 시험하는 것이며, 그 아래에 있는 도구만을 시험하는 것이 아닙니다. 우리의 골드 세트에는 계층 구조 불일치 사례가 포함됩니다: 고객 인사이트 에이전트와 데이터 인사이트 에이전트는 같은 고객에 대해 서로 다른, 각각 올바른 수익 수치를 반환합니다. 하나는 부모 계정으로, 다른 하나는 자회사로 범위가 지정됩니다. 어느 숫자도 잘못된 것은 아닙니다. 이 사례는 에이전트가 쿼리의 의미론과 요청자의 성격을 바탕으로 올바른 범위를 추론하는지, 아니면 기본값을 사용하거나 평균을 내거나 판매자에게 명확성을 요구하는지 테스트합니다. 후보자는 실패했으며, 자회사 범위의 질문에 부모 레벨 수치를 반환했습니다. 이 사례의 골드 세트의 기본 사실은 질문이 어떤 범위를 기대하는지를 명시하므로, 품질 게이트는 즉시 불일치를 알렸습니다: 잘못된 숫자는 아니지만, 잘못된 범위에 맞는 올바른 숫자입니다.

5단계: 카나리아. 배포 후에 발생하는 사각지대를 찾아내기

5단계는 후가공 모니터링입니다. 이 시스템은 생성 환경에서 실시간 트래픽과 합성 평가 케이스에 대해 지속적으로 작동하며, 코드 변경이 유발되지 않아 3단계에서 발견되지 않았던 문제를 찾는 역할을 합니다. 3단계는 엔지니어들이 변경하는 내용을 방지하는 역할을 합니다. 5단계에서는 업스트림 데이터의 변화, 모델의 변화하는 동작, 제3자 의존성의 변경, 또는 실제 환경에서의 부하 하에서만 나타나는 지연 시간 증가나 트래픽 패턴의 변화와 같은 다른 요소들로부터 보호됩니다.

이 제품은 수천 개의 상위 스키마와 데이터 파이프라인으로부터 공급되는 데이터를 처리합니다. 특정 날에 수십 개의 파이프라인이 갱신되지만, 배포나 CI 게이트는 트리거되지 않습니다. 에이전트 코드는 변하지 않고, 모델도 변하지 않지만, 그가 처리하는 데이터는 변했으며, 그 결과 품질이 조용히 저하될 수 있습니다. 우리는 힘든 방식으로 이를 배웠습니다: 스키마 변경으로 인해 상류 파이프라인이 업데이트되었고, 에이전트는 잘못된 시간 창의 데이터를 인용하기 시작했으며, 첫 번째 신호는 자동 알림이 아닌 판매자 문의로 전달되었습니다. 5단계에서는 30분 평가 기간 내에 이를 발견하는 방법을 사용합니다.

우리는 두 가지 상호보완적인 일정에 AgentCore Batch Evaluation을 실행하며, 이 일정의 선택은 의도적으로 이루어졌습니다.

양쪽 방향에서 배우고 난 후 30분 단위의 주기로 결정했습니다: 15분은 너무 많은 잘못된 경보를 생성했으며; 60분은 실제 저하가 감지되기까지 2시간이 지나야 했습니다. 우리는 각 30분 단위의 주기를 평가 창이라고 부릅니다. 30분 동안 90분 내에 실제 트렌드를 포착하며, 단일 쿼리의 노이즈는 필터링됩니다. 각 창은 골든 세트 전체에서 라운드로빈 선택을 평가하여 24시간 내에 완전한 커버리지를 제공합니다.

임계값은 CI/CD 게이트보다 일부러 낮게 설정됩니다. 단일 윈도우 실패는 이슈가 아니라 운영 신호입니다. 연속 3번의 윈도우 임계값 초과 후에만 온콜을 요청합니다. 우리는 이 규칙을 고통스럽게 배웠습니다: 첫 달에는 단일 윈도우 임계값을 사용했고, 온콜은 시스템을 전적으로 신뢰하지 않게 되었습니다. 하루에 한 번, 전체 골든 세트가 게이트 임계값에 따라 권위 있는 일일 점수카드로 작동합니다. 30분 윈도우는 추세를 드러냅니다. 일일 실행은 이를 확인하고 티켓을 삭제합니다.

각 실행은 CloudWatch에 출력되며(정확도, 허위 정보 생성률, 기반 설정률, 지연 시간, 비용), 두 가지 패턴을 구분하는 알람 로직이 적용됩니다. 카나리 실험은 세 단계로 진행됩니다: 도구 수준의 점수는 에이전트 수준의 응답이 손상되기 전에 검색 도구의 저하를 나타냅니다.

이것이 발견된 또 다른 예시입니다. 업스트림 인덱스가 갱신된 후, 검색 도구는 쿼리를 답변하는 데 필요한 정확한 맥락 대신 부적절한 정보만을 반환하기 시작했습니다. 지연 시간은 적당했으며 오류율은 zero였습니다. 에이전트는 약한 근거를 바탕으로 논리적으로 응답을 생성했고, 올바른 것처럼 보이는 답변을 내놓았지만 잘못된 수치를 언급했습니다. 어떤 인프라 경보도 발생하지 않았습니다. 카나리이가 처음 30분 내에 이를 발견했으며, 도구 수준의 지표가 떨어졌고, 판매자들이 저하된 답변에 반응하기 전에 CloudWatch 경보가 발생했습니다. 낮은 평가 점수는 정확한 트레이스를 표시했으며, 그 후 대기 엔지니어는 AgentCore에서 그 트레이스를 열어 몇 분 만에 저하된 맥락을 검색 도구까지 추적할 수 있었습니다.

6단계: 적. 남용으로부터 보호하기

모든 나쁜 결과가 저하된 모델에서 비롯되는 것은 아닙니다. 무단 계정 데이터를 추출하기 위한 질문과, 수집된 문서에 삽입된 프롬프트 주입은 민감한 비즈니스 데이터를 제공하는 시스템에서 예측 가능한 패턴입니다.

안전은 단 하나의 단계가 아닙니다. 모든 9단계를 거칩니다. 우리는 모든 상호작용에서 두 지점에서 Amazon Bedrock Guardrails을 적용합니다. 입력 단계에서는 쿼리 범위를 검증하고 프롬프트 인젝션을 방지합니다. 출력 단계에서는 민감한 데이터가 무단 사용자에게 노출되지 않고, 에이전트가 정책 위반으로 조작되지 않았는지 확인합니다. 이러한 검사는 응답이 사용자에게 도달하기 전에 동시에 100%의 트래픽에 대해 실행됩니다.

두 개의 가드레일 레이어를 설정합니다. 각 레이어는 서로 다른 위협 클래스를 커버합니다.

콘텐츠 필터은 입력 및 출력되는 모든 콘텐츠에서 해로운 또는 부적절한 내용을 감지하고 차단합니다. 우리는 VIOLENCE, HATE, SEXUAL, MISCONDUCT, INSULTS 등의 범주를 포함한 모든 카테고리에 대해 필터를 적용합니다. 이러한 필터를 트리거하는 요청이나 응답은 판매자에게 도달되거나 사용자에게 표시되기 전에 차단됩니다.

프롬프트 보안 필터은 단일 PROMPT_ATTACK 가드레일 범주 하에서 에이전트를 적대적 조작으로부터 보호하며, JAILBREAK(에이전트의 시스템 지시를 무력화하거나 운영 경계를 우회하는 시도), PROMPT_INJECTION(수집된 문서, 도구 출력물 또는 사용자 질문에 의도하지 않은 지시가 삽입되는 것), PROMPT_LEAKAGE(시스템 프롬프트나 내부 설정을 추출하려는 시도) 등 세 가지 하위 유형을 포함합니다. 검색 증강 생성(RAG)을 사용하는 다에이전트 시스템에서는 수집된 콘텐츠를 통한 프롬프트 삽입이 실제 위험입니다. 판매자의 계정 데이터에 있는 의도하지 않은 문서가 에이전트의 행동을 중간 단계에서 전환시키려 할 수 있습니다.

안전 규칙은 1단계에서 정의되며, 3단계와 4단계에서 재발을 점검하고, 생산 과정에서 지속적으로 시행됩니다.

7단계: 드리프트. 품질을 유지하고 실제 트래픽으로 검증하기

품질은 여러 방향에서 저하됩니다: 상류 데이터가 변경되더라도 배포가 이루어지지 않고, 모델이 낡아지며, 사용자들은 황금 세트가 완전히 예측할 수 없는 쿼리로 한계를 넘습니다. 7단계에서는 판매자들이 감지하기 전에 이를 발견하고, 전체 배포 전에 실제 사용자 트래픽을 기준으로 후보들을 검증합니다.

드리프트 감지. AgentCore Online Evaluation을 사용하여, 스테이지 1에서 정의된 다양한 평가자를 통해 실시간 트래픽의 10퍼센트를 지속적으로 샘플링합니다. 따라서 드리프트는 오프라인에서 설정된 기준치와의 차이로 즉시 확인됩니다. 점수는 동일한 창 내에서 품질, 지연 시간, 비용을 모니터링하는 Quality-State Calculator에 전달됩니다.

한 가지 생산 사례입니다. 고객 식별을 위한 우리의 골드 세트는 합성 시나리오로 구성되었습니다: 이름의 변형, 자회사 검색, 약어 등입니다. 오프라인 환경에서는 잘 작동했습니다. 하지만 실제 트래픽에서는 판매자들이 주식 기호("AMZN은 어떻게 되나요?")와 간단한 이름, 오타를 입력했으며, 합성된 시나리오는 이러한 상황을 대처하지 못했습니다. Quality-State Calculator는 3개의 연속된 30분 구간에서 틱점수가 변동되는 것을 보여주었습니다: 1시 30분에 98%, 2시 00분에 81%, 2시 30분에 80%였습니다. CloudWatch는 이 한계치를 넘었을 때 on-call 작업을 시작했습니다. on-call 엔지니어는 에이전트에게 “1시부터 3시까지 고객 식별 정확도가 어떻게 변했나요?”라고 질문했고, 틱점수 검색과 간단한 이름이 문제 원인임을 나타내는 트렌드 요약 결과를 받았습니다. 에이전트의 로그는 근본 원인을 즉시 드러냈습니다. 해결 방법은 골드 세트에 낮은 점수를 기록한 실제 세션들을 추가하고, 해결하기 전에 입력 형식을 정규화하는 디스암비게이션 도구를 업데이트하는 것이었습니다. 다음 평가 주기 내에 정확도는 기준치로 회복되었습니다.

실시간 트래픽 피드는 지속적인 개선 루프를 두는 역할을 합니다. 낮은 점수를 받은 세션들은 새로운 에지 케이스로 황금 집합으로 전환되며, 낮은 점수를 받은 트레일들의 클러스터는 프롬프트 수정, 도구 업데이트 및 라우팅 조정에 대한 정보를 제공합니다.

A/B 테스트: 후보 모델이 품질 게이트를 통과한 후, Amazon Bedrock AgentCore의 기능인 AgentCore Gateway는 현재 모델과 후보 모델 간의 실제 트래픽을 전달합니다. 온디멘드 검증을 통해 알려진 경우에 대한 재현 문제가 없는지 확인하며, 온라인 검증에서는 장기적인 입력값과 새로운 표현 방식에 대한 성능이 여전히 양호한지 확인합니다. 전체 배포 전에 후보 모델이 모든 평가 기준에서 승리하거나 동점을 이겨야 합니다.

8단계: 펄스. 실시간 품질 가시성

에이전트에 대한 단일 호출은 세 개의 서브 에이전트, 다섯 개의 도구, 그리고 두 개의 검색 경로에 영향을 미칠 수 있습니다. 품질 알람이 발생하면 “에이전트 파이프라인의 어떤 것”은 실행 가이드가 아닙니다. 8단계는 5단계, 6단계, 7단계에서 오는 신호가 관찰 가능성 레이어로 집중되어 행동할 수 있는 충분한 해상도를 갖게 되는 곳입니다.

AgentCore 관찰성은 Amazon Bedrock AgentCore의 기능 중 하나로, 이는 기반이 됩니다. AgentCore 런타임에 호스팅된 에이전트의 경우, Amazon Bedrock AgentCore의 한 기능으로, 모든 실행 과정이 OpenTelemetry를 통해 자동으로 장치화되며, 각 추론 단계에 대한 구조화된 텔레메리티가 생성됩니다: 도구 호출, 주문, 입력 및 출력 값, 지연 시간, 토큰 소비량 등이 있으며, CloudWatch Transaction Search가 활성화된 후(일회성 설정 단계) 이 정보는 커스터마이즈 메트릭과 로그로 직접 CloudWatch에 게시됩니다. 평가 점수는 별도의 파이프라인입니다. 이 점수는 실행 기록 정보가 아닌 평가 설정에서 나오며, 자체적인 CloudWatch 로그 그룹에 저장됩니다. 각 평가 실행은 전체 출력 결과를 S3 및 우리의 데이터 리포지토리에 저장하며, 두 개의 대시보드로 전달됩니다.

• 평가 및 관찰성 결과를 조회할 수 있는 대화형 대시보드.
• 전체 기간에 걸친 트렌드 분석, 스코어카드 추적, 그리고 여러 에이전트 간 비교를 위한 아마존 퀵 대시보드.

역할에 적합한 뷰가 위에 나타납니다. Oncall 엔지니어들은 트레이스 먼저의 뷰를 얻습니다: CloudWatch 알람에서 AgentCore Observability 트레이스로 이어지는 클릭 한 번으로 해당 알림이 발생합니다. 이 트레이스는 각 도구가 호출된 순서, 단계별 지연 시간, 토큰 소비량, 비용, 그리고 전체 추론 맥락을 보여줍니다. 이 모든 정보를 통해 "알람이 발동됨"에서 "근본 원인이 확인됨"까지의 과정을 두 번째 도구를 열지 않고도 진행할 수 있습니다. 이는 그림 5에 나타난 바와 같습니다.

그림 5: 고객 인사이트 에이전트의 AgentCore 실행 트레이스로, 스펜 트리, 경로, 그리고 스펜 수준 지표가 표시됩니다. 그림에 있는 숫자와 값은 예시용입니다.

제품 관리자들은 아마존 퀵 트렌드 대시보드를 받습니다: 하위 에이전트와 기능별 품질 점수, 릴리스 대비 릴리스 기준으로 제공됩니다. 리더십 팀은 주간 및 전사적 검토와 연동된 단일 페이지의 건강 상태 요약을 받으며, 1분 내에 “우리 에이전트들의 성과는 어떠한가?”라는 질문에 답할 수 있습니다.

그림 6은 우리의 주간 평가 대시보드의 상단 표시입니다: 커스터마이즈된 평가자와 AgentCore 내장 평가자 모두로부터 얻은 통합 통과율과 함께 주간 실행 시의 지연 시간이 나타납니다. 그림에 있는 숫자와 값은 예시용입니다.

그림 6: 통합 합격률과 지연 시간이 포함된 주간 평가 대시보드. 그림에 나타난 숫자와 값은 예시용입니다.

그림 7은 커스터마이즈 에퀴테이터의 실패 카테고리 수준에서 동일한 루프를 분석하며, 어떤 오류 유형(미터법 교체, 환각, 고객 ID 누락 등)이 간극을 만들고 각 오류가 얼마나 많은 질문에 영향을 미치는지 정확히 설명합니다. 그림에 나타난 숫자와 값은 예시용입니다.

그림 7: 카테고리별 장애를 분석하는 주간 오류 보고 대시보드. 그림에 있는 숫자와 값은 예시용입니다.

8단계 이전에는 감지에 걸리는 시간(MTTD)이 며칠에서 몇 주였습니다. 8단계 이후에는 4시간 이하가 되며, 첫 번째 신호는 AgentCore 트레이스를 포함한 CloudWatch 알람입니다.

9단계: 피드백 루프. 지속적인 개선

이 단계는 관찰 결과를 실제 행동으로 전환합니다. 시스템은 시간이 지날수록 품질을 향상시킵니다. 우리는 Amazon Bedrock AgentCore의 기능인 AgentCore 최적화를 사용하여 순환을 완성합니다.

• 시스템 프롬프트 권장: 에이전트 추적을 분석하여 목표 평가기에서 성능을 향상시키는 데이터 기반의 최적화된 시스템 프롬프트를 생성합니다. 이 솔루션은 실패 패턴을 활용하고 특정 행동 지침을 추가합니다.
• 도구 설명 권장 방식: 에이전트 추적을 분석하여 더 명확한 도구 설명을 생성함으로써 도구 선택의 혼란이 줄어듭니다. 특히 에이전트가 모호한 요청에 잘못된 도구를 선택할 때 그렇습니다.

예를 보겠습니다:

AgentCore 최적화가 작동 중

개선해야 할 점:
목표 평가자: 환상 현상: 몇 개의 샘플 예시로부터 하드코딩된 값을 관련 없는 맥락에서 그대로 복제하는 모델.

이런 일이 발생한 이유: 소량 예시에는 실제 달러 금액과 고객 이름(예: “$4.2M”, “Acme Corp”)이 포함되어 있어 모델이 기억하고 관련 없는 질문에 그 정보를 노출합니다.

수정 방법: 단일 샘플 예제에 포함된 고정된 값을 일반적인 플레이스홀더로 대체하세요(예: $[AMOUNT], [CUSTOMER_NAME]). 이를 통해 모델이 특정 데이터 포인트를 기억하지 않고도 응답 구조를 학습할 수 있습니다.

영향과 결과: 수정이 적용되었습니다. 순수한 환상 발생 횟수는 10,000개의 응답당 138회에서 52회 미만으로 감소했으며, 전체 기반율은 93%에서 96%로 향상되었습니다.

AgentCore 최적화는 권장 사항을 활용하여 데이터 기반 시스템 프롬프트와 도구 설명을 생성하며, 이는 실제 에이전트 트레이스와 목표 평가기에 따라 변경됩니다. AgentCore 최적화는 AgentCore 평가를 기반으로 합니다. 점수가 낮은 트레이스는 영구적인 회귀 보호 장치로 황금 세트에 포함되어, 각각의 실패가 사용자에게 두 번 이상 전달되는 것을 방지합니다.

에이전트 평가의 주요 지표 한눈에

평가 지표는 1단계에서 정의되며, 9단계 전체에 걸쳐 적용되고 생산 환경에서 지속적으로 모니터링됩니다. 이 집합은 고정된 것이 아닙니다. 생산 환경에서 에이전트로부터 학습하면서 새로운 장애 패턴이 나타나고 새로운 측면이 측정 가능해지며, 지표도 그에 맞게 발전합니다. 다음은 우리가 시작한 곳과 오늘 추적하는 내용입니다.

결론

9단계 에이전트 평가 프레임워크의 영향은 구체적이고 측정 가능했습니다. 이전에는 며칠이나 몇 주가 걸려서 나타나고, 보통 판매자 불만을 통해 발생했던 품질 저하 현상이 이제는 자동화된 평가를 통해 4시간 이내에 발견됩니다. 과거에는 주관적인 판단에 의존되었던 배포 결정이 이제는 모든 평가자가 양적 기준을 통과해야 합니다. 신속한 반복 주기가 며칠에서 몇 분으로 줄었습니다. 안전 관리는 정기적인 감사에서 모든 요청에 대해 100%의 보호 장치 적용으로 전환되었습니다. 지연 문제는 생산 환경에 도달하기 전에 CI 게이트에서 발견됩니다. 몇 주 후에 결제에서 발생하는 비용 예상치와 같은 문제는 이제 두 번째 단계에서 평가되고, 변경 사항이 배포되기 전에 품질 게이트를 통해 강제 적용됩니다. 또한 “에이전트 파이프라인에 있는 무언가”는 CloudWatch 알람부터 완전한 에이전트 실행 트레이스까지 단 한 번의 클릭으로 이루어지며, 모든 추론 단계가 명확하게 표시됩니다.

더 넓은 교훈은 업계가 이미 배웠던 것입니다. DevOps는 자동화된 테스트 없이 코드를 배포하는 것이 위험하다고 가르쳤습니다. MLOps는 모델을 모니터링 없이 배포하는 것이 위험하다고 가르쳤습니다. AgentOps도 AI 에이전트에 대해 마찬가지로, 지속적이고 다층적인 평가 없이 운용하는 것은 무모한 일이라고 가르칩니다.

여기서 설명된 9단계 프레임워크는 판매 정보 에이전트에만 특화된 것이 아닙니다. 추론, 하위 에이전트 호출, 도구 사용 및 응답 합성 등을 수행하는 다중 에이전트 시스템을 운용하는 팀은 동일한 라이프사이클 내에서 같은 문제들을 직면하게 됩니다. 귀하의 실패 분류 체계는 달라질 것입니다. 귀하의 핵심 요소들은 귀하의 분야를 반영할 것입니다. 평가 스택은 사용자에 맞게 조정될 것입니다. 변하지 않는 것은 한 가지 원칙입니다. 즉, 평가는 최종 QA 단계가 아닙니다. 이는 에이전트 자체의 운영 체제로, 지속적으로 측정되고 자동으로 보호되며 모든 상호작용과 함께 개선됩니다.

생산적인 에이전트를 구축하고 이러한 평가 방식을 시스템에 도입하고자 한다면, Amazon Bedrock AgentCore Evaluations가 그를 위한 플랫폼을 제공합니다. 실험을 위한 즉시 평가, 지속적인 모니터링을 위한 배치 평가, 실시간 트래픽을 위한 온라인 평가, 내장 및 맞춤형 평가기, 공개 미리보기 형태의 데이터셋 평가, CloudWatch와의 통합, AgentCore 최적화 기능 권장 및 A/B 테스트를 통해 피드백 루프를 완성할 수 있습니다. 1단계부터 시작하여, 당신의 에이전트에게 좋은 모습이 무엇인지 정의하고, 프레임워크가 나머지를 처리하도록 하세요.

시작할 준비가 되셨나요? Amazon Bedrock AgentCore 문서의 에이전트 성능 평가를 참조하세요. 또한, 생산 환경의 에이전트를 구축하고 이 프레임워크를 시스템에 적용하는 방법에 대해 논의하고 싶다면, 저희가 도와드리겠습니다. 직접 연락하거나 AWS 계정 팀을 통해 연락해 주세요.

Amazon Bedrock AgentCore 평가에 대해 더 알고 싶다면, AWS 문서의 agent 성능 평가를 참조하세요. 기술적 소개를 원한다면, AgentCore 평가로 신뢰할 수 있는 AI 에이전트를 구축하기를 읽어보세요. Performance Insights Agent의 구조에 대해 알고 싶다면, AWS SMGS가 Amazon Bedrock AgentCore로 비즈니스 관리를 변환하기 위해 AI 기반 대화형 도우미를 사용하는 방법를 읽어보세요. AgentCore 추천 및 최적화에 대해 알고 싶다면, AgentCore 최적화: 추천 및 A/B 테스트를 통한 에이전트 품질 향상 루프를 읽어보세요.

감사의 말

우리는 이 프로젝트를 가능하게 해준 비전과 지도를 제공한 경영 스폰서 및 멘토들에게 진심으로 감사를 드립니다: Damien Forthomme, 응용과학 관리자 III; Akhand Singh, 데이터 엔지니어링 책임자; Sujit Narapareddy, AWS Insights 디렉터; Monica Jain, 수석 제품 관리자 – 기술 및 Norman Braddock, AWS의 AI 제품 관리 수석 관리자; Muhammad Umar Javed, 응용과학자 III, L6.

저자들에 대해