Amazon Bedrock AgentCore로 다중 에이전트 시스템의 설명 가능성과 유용성 평가하기

멀티 에이전트 시스템이 실험 단계에서 프로덕션 단계로 이동하면서 대두되는 중요한 과제는 이러한 시스템이 실제 시나리오에서 일관되게 유용하고 정확하며 설명 가능하도록 보장하는 것입니다. 기업들은 데이터 소스, 도구, 비즈니스 제약 조건 전반에 걸친 추론이 필요한 복잡한 실제 문제를 해결하기 위해 멀티 에이전트 시스템을 점점 더 많이 채택하고 있습니다. 공급망 계획부터 금융 분석, 고객 운영에 이르기까지 이러한 시스템은 단순한 질의응답을 넘어섭니다. 여러 전문화된 에이전트들을 조율하여 의사결정을 내리고, 워크플로를 실행하며, 실행 가능한 권고 사항을 생성합니다.

대규모 언어 모델은 유창한 응답을 생성할 수 있지만, 엔터프라이즈 애플리케이션에는 훨씬 더 깊은 수준의 보장이 요구됩니다. 에이전트는 지시를 안정적으로 따르고, 올바른 도구를 선택하고, 제약 조건을 준수하며, 출력 결과에 대한 명확한 추론 근거를 제공해야 합니다.

Amazon Bedrock AgentCore 어떤 프레임워크나 모델이든 사용하여 대규모로 에이전트를 구축, 연결 및 최적화할 수 있는 플랫폼입니다. Amazon Bedrock AgentCore Evaluations, Amazon Bedrock AgentCore의 기능 중 하나로, 개발 및 프로덕션 전반에서 에이전트 성능을 평가하는 완전 관리형 기능으로서 이러한 과제를 해결하기 위해 설계되었으며, 팀이 여러 품질 차원에 걸쳐 정확도, 작업 성공률 및 동작을 측정할 수 있도록 지원합니다. 모델 응답 품질에만 초점을 맞추는 기존의 평가 방식은 올바름이 도구 선택, 워크플로 실행 및 비즈니스 제약 준수에 달려 있는 에이전틱 시스템에는 충분하지 않습니다. 평가 외에도 에이전틱 시스템의 프로덕션 배포에는 책임 있는 AI 통제가 필요합니다. Amazon Bedrock Guardrails 콘텐츠 필터링, 금지 주제 탐지, 근거 검증과 같은 구성 가능한 세이프가드를 제공하여 평가 프레임워크를 보완합니다. 평가가 실행 후 에이전트 품질을 평가하는 반면, Guardrails는 실행 중에 안전 제약 조건을 강제합니다. 이 게시물에서는 기본 제공 평가기와 사용자 지정 평가기 모두에 대한 Amazon Bedrock AgentCore Evaluations 지원으로 이 평가 프레임워크를 운영화하는 방법에 중점을 둡니다. 기본 제공 평가기는 유용성, 작업 성공, 지시 사항 준수와 같은 일반적인 품질 차원에 대해 사전 정의된 평가를 제공하므로, 팀은 추가 설정 없이도 신속하게 에이전트 성능의 기준선을 확보할 수 있습니다. 그러나 엔터프라이즈 사용 사례는 더 깊은 수준의 도메인 특화 검증이 필요합니다. 사용자 지정 평가기는 이를 해결하여 비즈니스 인지형 검사를 정의할 수 있게 해줍니다.

우리는 또한 설명 가능성을 일급 평가 차원으로 특별히 다룹니다. 내장 평가기가 일반적인 응답 명확성을 평가할 수 있는 방법을 시연합니다. 사용자 지정 평가기를 사용하여 에이전트가 의사 결정 근거를 명시적으로 설명하고, 뒷받침하는 데이터나 도구 출력을 참조하며, 비용 대비 서비스 수준과 같은 트레이드오프를 설명하는지 검증하는 방법을 보여줍니다. 이러한 평가기들을 결합함으로써 AgentCore Evaluations가 표면적인 응답 품질을 넘어 에이전트가 어떻게, 왜 그러한 결정에 도달했는지에 대한 구조화되고 측정 가능한 인사이트를 제공할 수 있음을 보여줍니다.

이러한 개념을 구체화하기 위해, 다음 절에서는 참조 아키텍처와 구현을 살펴보며 이 구성 요소들이 실제로 어떻게 함께 작동하는지 보여줍니다.

솔루션 개요

이 게시물에서는 AnyCompany Retail이라는 가상의 글로벌 소매 기업을 사용합니다. AnyCompany Retail은 전자상거래 채널, 지역 단위 물류센터, 배송 센터 및 수천 개의 오프라인 매장을 운영하는 다국적 소매업체입니다. AnyCompany는 잦은 재고 불균형을 겪고 있습니다. 일부 지역은 프로모션 기간 동안 품절 사태를 겪는 반면, 다른 지역은 과잉 재고를 보유하고 있습니다. 운송 팀 역시 배송 속도, 운송사 수용 능력, 비용 간의 균형을 맞춰야 합니다. 이 회사는 계획 담당자가 재고 배분을 최적화하고, 물류 조정을 추천하고, 재고 건강 상태를 분석하고, 경로 배정 또는 주문 처리 시나리오를 시뮬레이션하는 데 도움을 줄 수 있는 에이전트형 어시스턴트를 원하고 있습니다.

다음을 사용하여 멀티 에이전트 공급망 의사결정 시스템을 구축하고 평가하게 됩니다. Strands Agents SDK, Amazon Bedrock AgentCore MCP 서버 그리고 Amazon Bedrock AgentCore Evaluations입니다. 이 솔루션은 오케스트레이터 에이전트와 4개의 전문 서브 에이전트, 즉 최적화 에이전트, 물류 배분 에이전트, 라우팅 에이전트, 분석 에이전트와 함께 Strands Agents를 사용합니다. 각 에이전트는 Amazon Bedrock AgentCore 런타임 함께 Amazon Bedrock AgentCore 메모리 그리고 Amazon Bedrock AgentCore Observability 활성화되었습니다.

오케스트레이터 에이전트는 플래너의 요청을 받아 도구로 노출된 전문 에이전트들에게 작업을 위임합니다. 최적화 에이전트는 목업(mock)으로 구현된 Amazon API Gateway REST 인터페이스를 백엔드로 사용하는 MCP 도구를 호출하여 최적화 결정을 반환받습니다. 배포(distribution) 에이전트는 추천 API를 호출하여 물류센터, 매장, 디지털 채널 전반에 걸친 재고 재조정을 제안합니다. 라우팅 에이전트는 물류(logistics) API를 호출하여 운송사 및 경로 옵션을 추천하고, 분석 에이전트는 공급망 진단 질문에 답변합니다. 이 솔루션은 에이전트 루프에 Amazon Bedrock의 파운데이션 모델을 사용합니다. 리전별 모델 가용성은 Supported models by AWS Region in Amazon Bedrock.

을 참조하십시오. 이 솔루션은 유용성 및 작업 완료와 같은 일반 품질 차원을 평가하는 내장 평가기를 사용합니다. 또한 제약 조건 충족, 경로 실현 가능성, SQL 정확성, 재고 근거화, 설명 품질과 같은 공급망 특정 동작을 평가하는 사용자 지정 평가기를 제공합니다. AnyCompany는 응답의 언어 품질과 에이전트 결정의 비즈니스 타당성을 모두 평가할 수 있습니다.

이 솔루션은 Amazon Bedrock AgentCore Evaluations로 온디맨드 모드와 온라인 모드를 모두 지원합니다. 온디맨드 모드는 개발 벤치마킹, 회귀 테스트, 지속적 통합 및 지속적 전달(CI/CD) 게이트를 위한 것입니다. 온라인 모드는 지속적인 프로덕션 모니터링 및 알림을 위한 것입니다. 두 모드 모두 사용자 피드백을 반영하고 조치를 취할 수 있도록 루프를 닫는 데 도움이 됩니다. 온디맨드 평가에 사용되는 동일한 사용자 지정 평가기(공급망 솔루션의 제약 조건 충족, 경로 실현 가능성, SQL 정확성, 설명 가능성 평가기 등)는 평가기의 Amazon Resource Names(ARN)을 참조하고 샘플링 비율(예: 프로덕션 트레이스의 1~10%)과 선택적 세션 필터를 지정하는 OnlineEvaluationConfig 객체와 함께 재활용됩니다. 이후 서비스가 AgentCore Observability에서 트레이스를 자동으로 읽고 점수를 매기며 결과를 Amazon CloudWatch 대시보드 및 알람으로 스트리밍합니다. 이 게시물에서는 온디맨드 모드를 사용하여 솔루션을 테스트합니다.

다음 아키텍처 다이어그램은 이 솔루션의 다양한 구성 요소를 보여줍니다.

그림 1: 멀티 에이전트 공급망 의사 결정 솔루션의 아키텍처

평가 프레임워크

이 게시물에서는 엔터프라이즈 신뢰를 점진적으로 구축하는 멀티 에이전트 시스템용 3계층 평가 접근 방식을 사용합니다. 이 접근 방식은 일반 품질을 위한 내장 평가기로 시작하고, 비즈니스 정확성을 위한 사용자 지정 평가기를 추가하며, 마지막으로 신뢰성과 감사 가능성을 위한 설명 가능성 평가기를 계층화하는 명확한 진행 구조를 따릅니다.

첫 번째 계층은 설정이 필요 없는 내장 평가기를 사용합니다. 보편적인 기준선으로 Helpfulness를 적용하고, 각 에이전트의 주요 실패 양상을 겨냥한 두 번째 에이전트별 평가기로 오케스트레이터에는 Tool Selection Accuracy, 최적화 및 배포에는 Response Relevance, 라우팅에는 Instruction Following, 분석에는 Faithfulness를 적용합니다.

두 번째 계층은 도메인별 비즈니스 규칙을 인코딩하는 사용자 지정 평가기를 추가합니다: 최적화를 위한 제약 조건 충족, 배포를 위한 데이터 근거화, 라우팅을 위한 경로 실현 가능성, 분석을 위한 SQL 정확성, 오케스트레이션을 위한 계획 일관성입니다. 이들은 비즈니스 타당성을 검증합니다: 추천이 예산 한도를 준수했는지, 실제 재고 데이터를 사용했는지, 운영상 올바른 결과를 산출했는지 여부입니다.

다음 표는 여기서 구현할 각 에이전트에 대해 선택된 두 가지 내장 평가기와 사용자 지정 평가기를 매핑한 것입니다. 두 번째 내장 평가기는 각 에이전트의 주요 실패 양상을 겨냥하며, 사용자 지정 평가기는 운영상의 정확성을 검증하는 도메인별 비즈니스 규칙을 인코딩합니다.

설명 가능성

평가 방식의 세 번째 계층은 설명 가능성(explainability) 평가기를 에이전트 전반에 걸쳐 적용되는 별도의 교차적(cross-cutting) 점검으로 적용합니다. 이는 에이전트가 결정 근거를 설명하는지, 도구 출력에서 뒷받침하는 증거를 인용하는지, 어떤 제약 조건이 응답을 형성했는지 설명하는지, 상충하는 목표 간의 트레이드오프를 설명하는지, 특정 하위 에이전트가 호출된 이유를 명확히 하는지, 그리고 데이터가 불완전할 때 가정을 명시하는지를 독립적으로 평가합니다. 설명 가능성을 별도의 평가 계층으로 분리함으로써 투명성을 독립적으로 측정할 수 있습니다. 추천이 정확하더라도 설명되지 않을 수 있으며(사용자 지정 평가기는 통과하지만 설명 가능성 평가는 실패), 이를 통해 팀은 더 나은 의사 결정 논리가 아니라 더 나은 추론 설명이 필요한지에 대한 실행 가능한 신호를 얻을 수 있습니다.

다음 표는 여기서 구현하고 교차 계층으로 에이전트 전반에 적용되는 6개의 독립적인 설명 가능성 평가기를 정의합니다. 이들은 에이전트가 추론을 설명하고, 증거를 인용하고, 제약 조건과 트레이드오프를 설명하고, 가정을 명시하는지 평가합니다. 정확도와 별도로 측정되므로 팀은 설명되지 않았지만 올바른 응답과 잘 설명되었지만 틀린 응답을 구별할 수 있습니다.

사전 요구 사항

이 솔루션을 배포하기 전에 다음 도구로 개발 환경을 설정하십시오.

1. 다음을 설치합니다: AWS Command Line Interface (AWS CLI)
2. 다음을 설치합니다: AWS Serverless Application Model (AWS SAM) CLI v1.100.0+
3. 다음을 설치합니다: Docker v20.x+
4. 설치 Node.js v18.x+
5. 설치 Python v3.11+

의존성

Strands Agents 구현에는 DockerFile에 패키지되어 있는 다음 의존성들도 필요합니다:

1. strands-agents # Strands Agents 멀티 에이전트 프레임워크
2. strands-agents-tools # Strands 에이전트 도구 및 유틸리티
3. requests # API 호출을 위한 HTTP 라이브러리
4. bedrock-agentcore # Amazon Bedrock 에이전트 코어 기능
5. boto3 # Python용 AWS SDK (Boto3)

솔루션 배포 및 실행

이 솔루션은 저희의 GitHub 리포지토리 에서 다운로드할 수 있으며, 단일 단계 배포를 통해 AWS 환경에 솔루션을 배포하고 액세스할 수 있습니다:

# Edit terraform.tfvars: set vpc_id and runtime_subnet_azs
cd terraform
cp terraform.tfvars.example terraform.tfvars
terraform init
terraform apply

출력에는 런타임 ARN, AnyCompany Retail API URL, 평가자(evaluator) API URL 및 메모리 ARN이 포함됩니다.

솔루션 실행

다음 단계에 따라 솔루션을 실행합니다:

test_client/ 폴더에는 엔드 투 엔드 기능을 검증하기 위해 배포된 Supply Chain 에이전트를 20개의 샘플 쿼리(서브 에이전트당 5개)로 호출하는 Python 스크립트가 들어 있습니다. 각 카테고리는 멀티 턴 세션으로 실행되며, 세션 ID는 마지막에 출력되어 평가자 API와 함께 사용할 수 있습니다.

cd test_client
pip install -r requirements.txt
cd terraform
terraform output supply_chain_arn

모든 쿼리 실행 (총 20개, 4개 세션)

cd test_client
python test_agent.py --runtime-arn "<supply_chain_arn>" --region <your_region>

특정 서브 에이전트 카테고리 실행

#Only optimization queries (1 session, 5 turns)
python test_agent.py --runtime-arn "<supply_chain_arn>" --category optimization
#Only routing and analytics (2 sessions, 5 turns each)
python test_agent.py --runtime-arn "<supply_chain_arn>" --category routing analytics

테스트 클라이언트는 각 쿼리와 전체 에이전트 응답을 출력합니다. 마지막에는 평가자와 함께 사용할 세션 ID를 출력합니다.

평가 생성 및 실행

test_evaluators/ 폴더에는 에이전트 세션에 대해 평가를 실행하는 스크립트가 들어 있습니다. 이 평가는 비동기적으로 실행되며 결과는 S3에 마크다운 파일로 저장됩니다.

먼저 앞서 설명한 대로 supply chain decisioning 멀티 에이전트 솔루션을 호출하여 트레이스가 포함된 에이전트 세션을 생성하고, 테스트 클라이언트 실행 마지막에 출력된 세션 ID를 기록해 두어야 합니다. 마지막으로 솔루션 실행 후 트레이스가 CloudWatch에 전파되기까지 3-5분 정도 기다립니다.

cd test_evaluators
pip install -r requirements.txt
cd terraform
terraform output evaluators_api_url

사용자 지정 평가자 생성

python test_evaluator.py --api-url "https://<evaluators-api-url>" create

이 명령은 사용자 지정 평가자를 등록하고 해당 ID를 출력합니다. run 명령과 함께 사용할 수 있도록 이 ID들을 저장해 둡니다.

평가 실행

평가자 ID(사용자 지정 또는 내장)의 쉼표로 구분된 목록을 전달합니다. 최소 1개는 필수입니다:

# Run custom + built-in evaluators
python test_evaluator.py --api-url "https://<evaluators-api-url>" run \
--agent-id "supply_chain_orchestrator_agent-<id>" \
--session-id "<session-id-from-test-client>" \
--evaluators " sc_optimization_constraint-<id>,sc_distribution_groundedness-<id>,Builtin.Correctness,Builtin.GoalSuccessRate"

API는 즉시 202를 반환합니다. 결과는 다음 위치의 S3에 비동기적으로 저장됩니다:

s3://<amzn-s3-demo-agent-source-bucket>/evaluations/<session-id>/<timestamp>/EvaluationResults.md

평가자 삭제

python test_evaluator.py --api-url "https://<evaluators-api-url>" delete \
--evaluator-ids "sc_optimization_constraint-<id>,sc_distribution_groundedness-<id>"

최적화 평가 실행

이제 평가 프레임워크를 이해하고 솔루션을 배포했으므로, 최적화 에이전트에 대한 집중적인 엔드 투 엔드 평가를 살펴보겠습니다. 이 워크스루에서는 사용자 지정 비즈니스 정확도 평가자(Layer 2)와 설명 가능성(explainability) 평가자(Layer 3)를 결합하여 최적화 결정의 정확성과 투명성을 모두 평가하는 방법을 보여줍니다.

1단계: 최적화 쿼리 실행

먼저 최적화 카테고리만으로 테스트 클라이언트를 호출하여 집중적인 세션을 생성합니다:

cd test_client
python test_agent.py --runtime-arn "<supply_chain_arn>" \
--category optimization \
--region <your_region>

이렇게 하면 5개의 최적화 쿼리가 멀티 턴 세션으로 실행됩니다. 에이전트는 "향후 30일 동안 prod-001의 최적 재고 수준은 얼마입니까?"와 같은 요청을 처리합니다. 각 쿼리는 최적화 에이전트가 MCP 도구를 호출하고, 수요 예측을 검색하며, 예산, 재고 커버리지 및 창고 용량 제약 조건을 준수하는 재고 권장 사항을 생성하도록 요구합니다. 실행이 끝나면 테스트 클라이언트가 최적화 세션 ID를 출력합니다.

2단계: Constraint Satisfaction 평가자 실행 (Layer 2: 비즈니스 정확도)

최적화 세션이 생성되면 사용자 지정 Constraint Satisfaction 평가자를 실행하여 에이전트의 재고 권장 사항이 비즈니스 규칙을 준수하는지 검증합니다. 이 평가자는 다음 세 가지 제약 조건을 동시에 확인합니다:

• 예산: 증분 보유 비용이 남은 예산(budget_limit − budget_used) 범위 내에 들어가는가?
• 재고 커버리지: 권장 수준이 수요 예측 이상(품절 방지)이고 2× 수요 이하(과잉 방지)인가?
• 창고 용량: 권장 수준이 가용 창고 공간 안에 들어가는가?

내장된 Helpfulness 및 Response Relevance 평가기와 함께 평가기를 실행합니다:

cd test_evaluators
python test_evaluator.py --api-url "https://<evaluators-api-url>" run \
--agent-id "supply_chain_orchestrator_agent-<id>" \
--session-id "<optimization-session-id>" \
--evaluators "sc_optimization_constraint-<id>,Builtin.Helpfulness,Builtin.ResponseRelevance"

API는 즉시 HTTP 202를 반환합니다. 평가는 비동기적으로 실행됩니다. 결과는 S3에 저장됩니다:

s3://<amzn-s3-demo-agent-source-bucket>/evaluations/<optimization-session-id>/<timestamp>/EvaluationResults.md

3단계: 설명 가능성 평가기 실행 (Layer 3: 신뢰성 및 감사 가능성)

최적화 에이전트가 제약 조건을 충족하는 권장 사항을 생성하는지 확인한 후, 다음 질문은: 에이전트가 자신의 추론을 설명하는가? 권장 사항은 정확하지만 불투명할 수 있습니다. 이러한 권장 사항은 제약 조건 평가기는 통과하지만 특정 재고 수준을 선택한 이유를 설명하지 못합니다.

1단계의 동일한 최적화 세션 ID를 사용하여, 이제 최적화 에이전트에 적용되는 두 가지 설명 가능성 평가기를 실행합니다:

• Decision Rationale Quality — 에이전트가 권장 사항을 만든 이유를 설명했는가? (예: “수요 예측이 1,200이고 목표 안전 계수가 1.25배이므로 1,500단위를 권장합니다”)
• Constraint Reasoning — 에이전트가 어떤 제약 조건이 최종 응답을 형성했는지 설명했는가? (예: “예산은 최대 1,800단위까지 허용하지만 창고 용량이 1,600으로 제한하므로 1,500을 권장합니다”)

python test_evaluator.py --api-url "https://<evaluators-api-url>" run \
--agent-id "supply_chain_orchestrator_agent-<id>" \
--session-id "<optimization-session-id>" \
--evaluators "sc_decision_rationale-<id>,sc_constraint_reasoning-<id>"

이 평가기들은 투명성을 독립적으로 평가합니다. 정확성과 별도로 측정됩니다.

종합 결과 해석

동일한 최적화 세션에 대해 세 가지 평가기를 모두 실행하면 두 가지 차원에 걸쳐 에이전트 품질에 대한 완전한 그림을 얻을 수 있습니다:

표 3: 품질 차원에 걸친 평가 범위

이 계층화된 접근 방식은 목표화된 개선을 가능하게 합니다. 제약 조건 충족 점수는 높지만 설명 가능성 점수가 낮다면, 에이전트의 의사 결정 로직은 타당하지만 커뮤니케이션에 개선이 필요합니다. 반대로 설명 가능성은 높지만 제약 조건이 위반된다면, 에이전트는 추론을 잘 설명하지만 잘못된 로직을 적용하는 것입니다. 각 실패 모드에는 서로 다른 개선 경로가 있으며, 평가 프레임워크는 이러한 구분을 측정 가능하게 만듭니다.

정리

반복 요금이 청구되지 않도록, 솔루션을 사용해 본 후 한 단계로 AWS 계정을 정리합니다.

terraform destroy

결론

이 게시물에서는 Amazon Bedrock AgentCore Evaluations를 사용하여 멀티 에이전트 공급망 의사 결정 시스템을 구축하고 평가하는 방법을 시연했습니다. 여기서는 에이전트 동작이 기능적일 뿐만 아니라 유용하고, 정확하며, 설명 가능한지 검증하는 데 중점을 두었습니다. AnyCompany Retail Group 시나리오를 사용하여, 오케스트레이터 에이전트와 전문 서브 에이전트가 엔터프라이즈 데이터 소스 및 API와 통합하면서 재고 할당, 배포 계획, 라우팅 최적화, 공급망 진단과 같은 복잡한 문제를 해결하기 위해 협력하는 방법을 보여주었습니다. 아키텍처 전반에 걸쳐 설명된 것처럼, 에이전트 시스템의 정확성은 응답 품질 그 이상입니다. 올바른 도구 선택, 올바른 워크플로 실행, 비즈니스 제약 조건 준수, 그리고 출력의 데이터 기반 근거 확보에 달려 있습니다.

내장 평가기와 사용자 지정 평가기를 결합함으로써, 팀은 일반 응답 품질과 도메인별 의사 결정 정확성을 모두 체계적으로 검증할 수 있습니다. 설명 가능성 중심의 평가기를 통합하면 에이전트가 자신의 추론을 명확하게 설명하고, 뒷받침하는 데이터를 참조하며, 비즈니스 사용자가 신뢰하고 행동할 수 있는 방식으로 트레이드오프를 설명하는지 더욱 확실히 보장할 수 있습니다. 이러한 평가 기반 접근 방식은 실제 실행 데이터를 사용한 지속적인 개선을 가능하게 하고, 프로덕션 배포 전 품질 게이트를 설정하며, 일관되고 투명하며 비즈니스에 부합하는 멀티 에이전트 시스템을 제공하기 위한 확장 가능한 프레임워크를 제공합니다.

시작하려면 다음을 살펴보세요 Amazon Bedrock AgentCore Evaluations 그리고 이러한 패턴을 여러분의 멀티 에이전트 애플리케이션에 적용해 보세요. 전체 소스 코드는 다음에서 확인할 수 있습니다. GitHub의 Amazon Bedrock AgentCore 샘플 저장소입니다. 먼저 관측 가능성(observability)을 활성화하고, 사용 사례에 대한 핵심 평가 차원을 정의한 후, 가장 중요한 사항을 측정할 수 있도록 내장 평가기와 사용자 지정 평가기를 점진적으로 도입하세요.

자세히 알아보려면 다음을 방문하세요: Amazon Bedrock AgentCore 서비스 페이지를 방문하거나 바로 시작하세요. Amazon Bedrock 콘솔.

관련 게시물:

• Amazon Bedrock AgentCore Evaluations로 신뢰할 수 있는 AI 에이전트 구축
• AWS에서 Amazon Bedrock AgentCore를 활용해 고확장성 서버리스 LangGraph 멀티 에이전트 시스템 구축
• AI 에이전트 평가하기: Amazon에서 에이전틱 시스템을 구축하며 얻은 실무 교훈

저자 소개