AgentCore Evaluation 팀의 김무현 SA(데이터 사이언티스트)가 직접 만들고 있는 서비스를 발표. 핵심 메시지: "에이전트는 소리 없이 실패한다. LLM·Tool·프롬프트의 비결정성 때문에 지속적·자동화된 평가 루프(Inner / Outer / Production) 가 없으면 운영 환경에서 무너진다." 다루는 두 서비스: AgentCore Evaluation (완전관리형, 운영용) + Strands Evaluations (OSS, 개발용) + 새 출시 Strands Evaluations Detector.

Part 1. AI 에이전트로의 진화 + 신뢰 문제

1. 에이전트 AI로의 3단계 진화

→ 자율성 및 비즈니스 영향력 증가.

"인간의 논리·추론을 모방하는 에이전트로 진화하기 때문에 비즈니스 영향력이 점점 커진다. 그런데 우리는 이 에이전트를 신뢰할 수 있을까?" — 김무현

신뢰를 보장하지 못하면 고객 경험 보장 불가 → 프로젝트 실패.

---

2. 에이전트 개발자들이 밤잠을 설치게 하는 것 — 4가지

"에이전트를 구성하는 요소들의 특징 때문에 우리의 밤잠을 설치게 됩니다."

→ 모델 업데이트 · 에이전트 새 버전 · 소스 프롬프트 수정 · Tool 추가/제거 — 이런 변경 때마다 지속 평가 필요.

---

3. 에이전트는 지속적으로 평가·개선되어야 — 4가지 질문

개발자가 끊임없이 확인해야 하는 4가지.

1. 에이전트가 목표를 달성했나요?
2. 에이전트가 올바른 결정을 내리고 있나요?
3. 작업에 가장 적합한 도구를 사용하고 있나요?
4. 답변이 정확한가요?

→ 이 네 가지를 지속적으로 평가하지 않으면 운영 환경에서 안정적으로 사용 불가.

---

4. 에이전트 평가 라이프사이클의 과제 — "프로세스는 몇 달이 걸릴 수 있습니다"

평가 파이프라인을 처음부터 구축하면 수개월 소요.

Mermaid스크롤로 확대 · 드래그로 이동
Copy

→ 이 모든 단계를 매번 직접 구축해야 한다는 게 페인 포인트.

---

Part 2. AgentCore Evaluation — 완전관리형 평가 서비스

5. 3가지 핵심 가치

→ 핵심 차별점: Trace 기반 동작 → 운영 중인 에이전트에 영향 없음.

---

6. AgentCore Evaluations — 동작 방식

Mermaid스크롤로 확대 · 드래그로 이동
Copy

핵심 메커니즘.

1. AgentCore Observability로 에이전트 trace 자동 저장
2. Agent owner 가 Evaluator 선택 (예: Correctness, Helpfulness)
3. AgentCore Evaluation 이 trace 기반으로 평가 실행
4. 결과: score + 평가 설명 함께 저장 (점수가 3점일 때 "왜 3점인지" 가 같이 옴 → 별도 디버깅 불필요)

---

7. 두 가지 평가 방법 — On-Demand + Online

On-Demand 동작 흐름.

Mermaid스크롤로 확대 · 드래그로 이동
Copy

---

8. User Simulator — "데이터가 없을 때 어떻게 시작하나요?" 페인 포인트 해결 (Preview)

"어제오늘 여러 고객 미팅을 해봤는데 가장 큰 페인 포인트는 '데이터가 없는데 어떻게 Evaluation 을 시작하냐' 입니다." — 김무현

작은 에이전트 유닛 테스트는 프롬프트 5–10개로 시작 가능. 하지만 프로덕션에는 대용량·다양한 데이터셋이 필요.

User Simulator가 설정할 수 있는 것.

• 사용자 context (상황, 배경 등)
• Goal (대화의 목적)
• 사용자 특성 (전문성, 대화 스타일, 인내심 등 — "굉장히 까칠한 성격" 도 설정 가능)

활용 가치 4가지.

→ "운영 환경에서 사용자는 굉장히 창의적이다. 엣지 케이스를 테스트셋에 포함시키는 게 중요하다."

---

9. 지원하는 Evaluator 들

핵심 인사이트.

• 3가지 LEVEL — SESSION (전체 대화) / TRACE (단일 턴) / TOOL (도구 호출)
• 대부분 LLM judge 이지만, Programmatic (TrajectoryExactOrderMatch 등) 과 신규 코드 기반 (Lambda)도 지원
• Ground Truth 지원 여부가 NEW 컬럼

→ 비즈니스 로직·정형 형식 검증이 필요한 경우 비싼 LLM 안 쓰고 코드 기반으로 가능.

---

10. 코드 기반 Evaluator — 4가지 시나리오

"LLM judge Evaluator가 아닌 여러분이 만든 파이썬 코드 기반으로 Evaluation 을 수행 → 저렴한 비용 + 동일 입력에 동일 결과 (100% 확신)."

→ "SQL 유효성, JSON 필수 필드 같은 건 LLM 안 쓰는 게 맞다."

---

11. Ground Truth 를 표현하는 3가지 형태

참조 입력: 이 세 필드의 임의 조합을 평가자 호출에 전달.

코드 예시 (슬라이드).

Python
Copy
assertions = [
    "가격이 존재함",
    "어조가 공감적임"
]

expected_response = "환불 금액 $120이 처리되었으며 영업일 기준 3–5일 이내에 완료됩니다."

expected_trajectory = [
    "check_warranty",
    "create_rma"
]

"시스템 프롬프트에 인스트럭션을 열심히 줘도 인스트럭션은 인스트럭션일 뿐, 에이전트가 그걸 따른다는 보장은 어렵다. 따라서 Expected Trajectory 기반 평가가 반드시 필요." — 김무현

---

12. 평가 후 → 에이전트 최적화 + A/B 테스트 (Preview)

평가만 하고 끝나면 안 되고 고쳐야한다. 시스템 프롬프트? 도구 디스크립션? 어느 부분?

AgentCore Optimization의 흐름.

Mermaid스크롤로 확대 · 드래그로 이동
Copy

"최적화된 프롬프트를 바로 운영에 적용하시는 분 있으신가요? 저는 그렇게 용감하지 않습니다." — 김무현 → A/B 테스트 기능이 AgentCore에 추가되어 구버전 vs 신버전 50:50 트래픽으로 운영하면서 Evaluation 으로 관찰 후 이관 가능.

---

Part 3. Strands Evaluations — 개발 단계 OSS

13. AgentCore Eval vs Strands Eval — 단계별 분담

"개발 단계에서 AgentCore Evaluation 을 항상 호출해서 하라고 하면 거부감 또는 자유도가 낮다는 피드백이 있다." → 개발은 Strands, 운영은 AgentCore로 역할 분담.

→ Strands Evaluations 는 에이전트 설정을 통한 실험 + Ground Truth 시뮬레이션 비교 가능. AgentCore Evaluation 이 할 수 있는 거의 모든 기능을 자체 처리 가능하지만, 파이프라인 구성은 직접 해야 함 → 운영 환경으로 넘어가면 AgentCore 권장.

---

14. Strands Evaluations — Detector (신규, 며칠 전 출시)

"에이전트는 소리 없이 실패합니다. 실패한 것도 감춰집니다. 왜냐하면 스스로 교정하기 때문에." — 김무현

문제: 실패를 고치려면 어떤 실패가 있는지 알아야 함. → 길고 복잡한 trace 를 1–2개는 분석 가능, 하지만 100개·1000개를 동시에 분석하려면 자동화 필수.

Strands Evaluations Detector의 흐름.

Mermaid스크롤로 확대 · 드래그로 이동
Copy

→ 에이전트가 왜 실패했는지, 어떤 이유 때문에, 어떻게 개선해야 하는지 팁 제공.

---

Part 4. 3가지 Evaluation Loop — Production Flywheel

15. Inner Loop / Outer Loop / Production Loop

세 가지 루프로 에이전트 성공 플라이휠 구성.

Mermaid스크롤로 확대 · 드래그로 이동
Copy

핵심 메커니즘 — 실패가 다시 반복되지 않도록.

1. 운영 환경에서 페일러 탐지
2. 탐지된 페일러를 개발자에게 넘겨 수정
3. 수정 후 그 페일러 타입을 Golden Dataset에 추가
4. Golden Dataset 이 CI/CD Gate가 됨 → 다음 배포에서 같은 페일러 재발 방지

"중요한 페일러는 Golden Dataset 에 추가되어 미래에 회귀로 다시 발생하지 않게 보장하는 플라이휠을 만들면, 여러분의 에이전트는 지속적으로 성능이 좋아지는 경험을 하시게 됩니다." — 김무현

→ AgentCore Evaluation 의 On-Demand 평가 (Outer Loop) + Online 평가 (Production Loop)를 적절히 조합하면 이 플라이휠 구현 가능.

---

정리 — 듣고 남은 인상

이번 세션을 다 듣고 나서 내 머릿속에 가장 강렬하게 남은 키프레이즈는 단연 "에이전트는 소리 없이 실패한다"는 한 줄이었다. 단순히 실패를 감지하지 못하는 게 문제가 아니다. 에이전트가 지 혼자 어떻게든 답을 내려고 스스로 교정하다 보니 '실패 자체가 은닉된다'는 게 진짜 문제라는 거다. 그래서 운영 모니터링과 Detector가 필수일 수밖에 없구나 싶었다.

무엇보다 발표의 디테일이 달랐다. AgentCore 팀의 김무현 SA님이 본인이 직접 만들고 있는 서비스(AgentCore Evaluation/Observability)를 발표하는 자리라 그런지, "어제오늘 고객 미팅에서 들은 이야기"라며 꺼내는 발화들에서 현장의 리얼한 피드백과 페인 포인트가 슬라이드 곳곳에 녹아있었다.

발표의 빌드업도 참 영리했다. 개발자의 4가지 도전 과제(비결정성, 잘못된 도구, "더 나음" 측정 불가, 자동 회귀)를 먼저 던지면서 프레이밍을 하니, '아, 이걸 풀려면 결국 제대로 된 평가가 필요하구나'라는 논리로 아주 자연스럽게 납득이 갔다.

기술적으로 깔끔하다고 느낀 포인트들은 대략 이렇다.

• 3가지 LEVEL의 Evaluator (SESSION / TRACE / TOOL): 보통 LLM 평가는 최종 응답 한 줄만 보는데, 에이전트는 생각의 흐름과 궤적(Trajectory) 전체를 봐야 하니까 이렇게 나눈 모델이 참 깔끔했다.

• 코드 기반 Evaluator (Lambda)의 등장: SQL 유효성이나 JSON 포맷 같은 결정적인 검증을 굳이 비싼 LLM 태우면 비용이 폭주하는데, "LLM 필요 없음"이라고 명시하며 코드로 분리한 게 아주 실용적이고 인상 깊었다.

• Ground Truth의 3가지 형태: 단순한 정답 매칭을 넘어, 자유 형식의 팩트 체크(Assertion)는 물론이고 도구 호출 순서(Expected Trajectory)까지 강제할 수 있다는 점이 운영 관점에서는 정말 결정적인 무기 같다.

• User Simulator: 데이터가 텅 빈 상태에서 평가를 어떻게 시작해야 할지 막막한 그 페인 포인트를 정확히 긁어줬다. "굉장히 까칠한 성격" 같은 페르소나까지 설정해서 없는 데이터로 엣지 케이스를 만들어 시뮬레이션할 수 있다는 게 참 흥미로웠다. (Preview 단계이긴 하지만 기대가 크다.)

그리고 평가만 하고 끝내는 게 아니라 "어디를 고쳐라"까지 추천해 주고, 그걸 바로 프로덕션에 올리기에는 부담감이 있으니 50:50 트래픽으로 안전하게 A/B 테스트를 지원한다는 점도 훌륭했다. 발표자분이 "저는 (바로 100% 배포할 만큼) 그렇게 용감하지 않습니다"라고 솔직하게 발화한 게 확 와닿았다.

개발은 오픈소스인 Strands로 가볍게 치고, 운영은 매니지드 서비스인 AgentCore로 태우는 분업화 메시지도 좋았다. 두 개가 서로 파이를 깎아먹는 경쟁이 아니라, 단계별로 역할을 나눈 건데 양쪽 다 같은 팀에서 개발하니까 낼 수 있는 자신감 있는 메시지였다.

마지막 결론으로 제시된 '3가지 Loop + Golden Dataset Flywheel' 구조가 이 세션의 포인트었다. Inner → Outer → Production으로 갈수록 자동화와 매니지드 비중이 커지고, 운영에서 발생한 실패 케이스가 다시 Golden Dataset으로 돌아와 Outer Gate(CI/CD)를 막아주는 구조다. 회귀 방지를 운영 데이터로 자동 학습하게 만든다는 게, 정말 아키텍처적으로 진화된 부분인 것 같다.