Home / 에이전트 평가 / 에이전트 평가
Module

에이전트 평가

에이전트 품질을 체계적으로 측정하고 개선하는 평가 체계

⏱ 60분 147 / 189

에이전트 평가

비결정성 · 테스트 vs 평가 · 4축 메트릭 · Trajectory · 적용 시점

비결정성도 측정할 수 있다

비결정적 시스템을 어떻게 검증하고 어떤 기준으로 평가하는가

에이전트 테스팅이 어려운 이유

비결정성 · 다중 정답 · 긴 경로 · 외부 의존성

PART 1 · 난제

테스팅 난제

전통 테스트 방법론이 에이전트 앞에서 멈추는 이유의 조감

assert equals가 통하지 않는 시스템

비결정성·다중 정답·긴 경로·외부 의존성 — 네 가지 근본 차이가 검증 접근 전체를 바꿉니다.

  • 비결정적 출력 — 같은 입력, 다른 답변
  • 다중 정답 — 정답은 범위(spectrum)
  • 긴 실행 경로 — Trajectory 추적 필수
  • 외부 의존성 — Mock/Stub 격리
takeaway

정확 매칭 대신 N회 실행의 점수 분포로 판단합니다 — 비결정성은 통계로 다룹니다.

PART 1 · 난제

전통 소프트웨어 vs 에이전트

기존 테스트 방법론으로는 검증할 수 없는 4가지 근본 차이

전통 소프트웨어

  • 결정적 — 같은 입력 = 같은 출력
  • 단일 경로 — 분기가 명확
  • 빠른 실행 — ms 단위
  • 비용 없음 — 실행 자체는 무료

AI 에이전트

  • 비결정적 — 같은 입력에 다른 출력
  • 멀티스텝 — 도구 호출 순서가 동적
  • 느린 실행 — 수초~수분
  • 실행 비용 — 모델 호출마다 과금
takeaway

결정성·경로·속도·비용 네 축이 모두 뒤집힙니다 — 기존 테스트 자산을 그대로 옮길 수 없는 이유입니다.

PART 1 · 난제

에이전트 테스팅의 4대 난제

assert equals가 불가능한 4가지 근본 이유

비결정적 출력

같은 프롬프트에 매번 다른 답변 — 정확한 문자열 매칭 불가. 동일 케이스 N회 실행 → 점수 분포로 판단

다중 정답

"정답"이 하나가 아님 — 다른 도구 순서로도 같은 결과 가능. 정답 = 범위(spectrum)

긴 실행 경로

도구 5회 호출 중 3번째에서 잘못된 판단 → 최종 결과만 보면 원인 모름. Trajectory 추적 필수

외부 의존성

외부 API 다운, 모델 업데이트로 기존 테스트 깨짐. Mock/Stub으로 격리 필요

takeaway

네 난제에는 각각 대응책이 있습니다 — 분포 판정 · 범위 정답 · Trajectory 추적 · Mock 격리가 짝을 이룹니다.

PART 1 · 난제

테스트 전략 피라미드

에이전트에도 계층적 테스트 접근이 필요 — 아래가 빠르고 위가 현실적

E2E 통합 테스트

전체 에이전트 대화 시나리오 — 느리지만 현실적, 비결정성 포함

컴포넌트 테스트

도구·프롬프트·모델 개별 검증 — 중간 속도, Mock 활용

유닛 테스트

함수·파서·유틸리티 — 빠르고 결정적, LLM 호출 없음

PART 1 · 난제

핵심 전환 — 정확 매칭에서 분포 분석으로

비결정적 시스템은 1회 실행이 아닌 N회 실행의 점수 분포로 판단

판정 방식 assert equals(정확 매칭) 점수 분포 (평균/P95)
정답 정의 "정확히 이것인가?" "충분히 좋은가?"
실행 횟수 케이스당 1회 케이스당 5~10회 (통계적 신뢰도)

테스트 vs 평가

4요소 구조 · pass/fail vs 0~1 점수 · 결정론적 vs LLM-as-Judge

PART 2 · 테스트 vs 평가

4요소 구조

테스트 케이스 → 에이전트 실행 → 판정 → 결과 분석의 파이프라인

  1. 1
    Case (입력)

    프롬프트 + 기대 결과(선택) + 판정 기준을 묶은 단위

  2. 2
    Agent (실행)

    동일 에이전트에 입력 전달, 응답 + 트레이스 수집

  3. 3
    Evaluator (판정)

    결정론적(키워드) 또는 LLM-as-Judge(품질 점수)

  4. 4
    Experiment (집계)

    점수 분포, 이전 대비 회귀 탐지, 개선 방향 도출

takeaway

Case가 입력을, Evaluator가 판정을, Experiment가 집계를 맡습니다 — 테스트든 평가든 이 파이프라인 하나로 돌아갑니다.

PART 2 · 테스트 vs 평가

테스트와 평가는 다른 목적

같은 프레임워크에서 관점만 다르게 — 동시 적용 가능

테스트 (Testing)

  • 목적: Pass/Fail 게이트
  • 결과: ✓ 통과 / ✗ 실패
  • 시점: 배포 전 (CI/CD)
  • 속도: 밀리초, 자주 실행
  • 예: "도구를 올바르게 호출하는가?"

배포 여부를 결정하는 관문. LLM 호출 0 — 무료이고 빠름.

평가 (Evaluation)

  • 목적: 품질 점수 추적
  • 결과: 0.0 ~ 1.0 스코어
  • 시점: 배포 전후 모두
  • 속도: 수 초, 배치 실행
  • 예: "답변이 얼마나 도움이 되는가?"

품질 추이를 추적하고 개선 방향을 도출. 평가자당 판정 호출 1회 — 케이스 실행 시 에이전트 자체 호출 비용은 별도.

takeaway

테스트는 배포를 막는 관문이고 평가는 품질 추이를 그리는 계기판입니다 — 같은 4요소 구조에서 관점만 다릅니다.

PART 2 · 테스트 vs 평가

평가자 트레이드오프 축

판정 비용과 판단 유연성의 1축 — 빌트인 평가자 6종의 위치

PART 2 · 테스트 vs 평가

평가자 유형 선택

결정론적(무료·일관) vs LLM-as-Judge(유연·비용) — 트레이드오프

유형결정론적LLM-as-Judge
동작규칙 기반 문자열/패턴 매칭LLM이 채점 (프롬프트 기반)
비용✓ 판정 무료 (LLM 호출 0)평가자당 판정 호출 1회 (에이전트 실행 비용 별도)
일관성✓ 항상 동일 결과약간의 변동 (temperature 영향)
유연성단순 패턴만 가능✓ 복잡한 품질 판단 가능
예시Contains, Equals, ToolCalledCorrectness, Faithfulness, Helpfulness
takeaway

단순 패턴은 무료·일관적인 결정론적 평가자로 처리하고, 복잡한 품질 판단만 LLM-as-Judge로 감당합니다.

PART 2 · 테스트 vs 평가

개념에서 구현으로 — Strands Evals

Case·Evaluator·Experiment의 원리를 코드로 구현하는 Strands Evals SDK

구현 상세는 Strands Evals 모듈에서

지금까지의 원리(4요소 파이프라인, 테스트 vs 평가, 평가자 유형)를 Strands Evals SDK가 코드로 구현합니다.

  • Case · Experiment 구성
  • 빌트인 평가자 20종+ · Custom Evaluator
  • ToolSimulator mock 테스트
  • Chaos · Red Team
takeaway

이 모듈은 "무엇을 왜 측정하는가"까지 — 코드 작성법은 Strands Evals 모듈에서 이어집니다.

평가 메트릭 체계

4축 메트릭 · Trajectory · 운영 메트릭

PART 3 · 메트릭

메트릭 체계

결과 품질·수행 과정·운영 효율을 함께 재는 측정 체계의 조감

결과 · 과정 · 운영을 함께 측정

4축 품질 메트릭에 Trajectory 과정 검증과 비용·지연 운영 메트릭을 더합니다.

  • 4축 — 정확성 · 충실성 · 관련성 · 안전성
  • Trajectory — 도구 호출 경로 검증
  • 매칭 3전략 — Exact · In order · Any order
  • 운영 — 도구 호출 수 · P95 · 호출당 비용
takeaway

최종 답변 점수만으로는 부족합니다 — 과정과 운영 효율까지 측정 대상에 넣습니다.

PART 3 · 메트릭

4축 메트릭 프레임워크

에이전트 품질을 다각도로 측정하는 표준 체계

PART 3 · 메트릭

Trajectory 평가 — 과정을 검증

최종 답변뿐 아니라 도구 호출 순서가 올바른지 확인 (AgentCore Evaluations 빌트인)

3가지 매칭 전략

  • Exact order match — 도구 호출 순서가 정확히 일치
  • In order match — 순서는 맞되 중간에 추가 호출 허용
  • Any order match — 호출된 도구 집합만 일치하면 통과

언제 어떤 전략을 쓰나

  • Exact — 호출 순서 자체가 요구사항일 때 (승인 → 실행 절차 등)
  • In order — 중간에 부가 호출이 끼어도 핵심 순서만 지키면 될 때
  • Any order — 독립적 조회처럼 순서가 결과에 영향 없을 때
yaml
Expected: [search, calculate, respond]

Exact order: [search, calculate, respond] ✓
In order:    [search, think, calculate, respond] ✓
Any order:   [calculate, search, respond] ✓
PART 3 · 메트릭

운영 메트릭 — 비용과 지연

기능 품질뿐 아니라 운영 효율도 평가에 포함 — 게이지 수치는 예시

30 평균 도구 호출 수 — 적을수록 효율적
50 P95 응답 시간 — SLA 기준
15 호출당 토큰 비용 — 예산 준수 여부

적용 시점

Dev · Pre-deploy · Prod — 단계별 비중 · CI/CD 게이트

PART 4 · 적용 시점

적용 시점

개발 단계에 따라 테스팅과 평가의 비중을 옮기는 전략의 조감

Dev → Pre-deploy → Prod

단계가 뒤로 갈수록 케이스는 많아지고 평가의 비중이 커집니다.

  • Dev — 10~20 케이스 · 결정론적 · 30초
  • Pre-deploy — 100+ 케이스 · 회귀 게이트
  • Prod — 실 트래픽 샘플링 · Chaos Testing
  • CI/CD — 회귀 시 PR 자동 차단
takeaway

모든 단계에 같은 강도를 쓰지 않습니다 — 속도가 필요한 곳은 테스트, 깊이가 필요한 곳은 평가로 비중을 옮깁니다.

PART 4 · 적용 시점

단계별 테스팅·평가 비중

개발 단계에 따라 달라지는 속도와 깊이의 균형

PART 4 · 적용 시점

CI/CD 통합 패턴

테스트를 배포 파이프라인에 게이트로 삽입 — 회귀 시 자동 차단

  1. 1
    Code Push

    개발자가 에이전트 코드/프롬프트 변경

  2. 2
    CI 테스트

    결정론적 평가자로 기본 동작 검증 (30초)

  3. 3
    LLM 평가

    OutputEvaluator로 품질 점수 산출 (5분)

  4. 4
    회귀 판정

    이전 점수 대비 하락 시 PR 차단

  5. 5
    배포

    모든 게이트 통과 시에만 프로덕션 배포

takeaway

다섯 단계 중 사람이 개입하는 것은 Code Push뿐입니다 — 회귀 판정까지 파이프라인이 자동으로 막아줍니다.

에이전트 테스팅 실습

⏱ 30분

테스트와 평가 프레임워크를 직접 설계합니다

학습 목표

  • 에이전트 테스트 케이스 설계 (Case + Evaluator)
  • 결정론적 평가자 vs LLM-as-Judge 비교
  • 4축 메트릭으로 품질 측정
  • Trajectory 검증 패턴 구현
테스트는 확인, 평가는 개선 — 둘 다 필요합니다.

비결정성 · 4요소 구조 · 테스트 vs 평가 · 4축 메트릭 · 적용 시점