Note

에이전트 테스팅

테스트 케이스 설계, 결정론적 평가자, 3단계 전략, CI/CD 게이트

⏱ 30분 146 / 189

에이전트 테스팅 심화

테스트 케이스 설계, 결정론적 평가자, 3단계 전략, CI/CD 게이트

비결정성도 측정할 수 있다

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

테스트 vs 평가

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

PART 2 · 테스트 vs 평가

4요소 구조

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

1
Case (입력)
프롬프트 + 기대 결과(선택) + 판정 기준을 묶은 단위
2
Agent (실행)
동일 에이전트에 입력 전달, 응답 + 트레이스 수집
3
Evaluator (판정)
결정론적(키워드) 또는 LLM-as-Judge(품질 점수)
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, ToolCalled	Correctness, 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
Code Push
개발자가 에이전트 코드/프롬프트 변경
2
CI 테스트
결정론적 평가자로 기본 동작 검증 (30초)
3
LLM 평가
OutputEvaluator로 품질 점수 산출 (5분)
4
회귀 판정
이전 점수 대비 하락 시 PR 차단
5
배포
모든 게이트 통과 시에만 프로덕션 배포

takeaway

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

에이전트 테스팅 실습

⏱ 30분

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

학습 목표

에이전트 테스트 케이스 설계 (Case + Evaluator)
결정론적 평가자 vs LLM-as-Judge 비교
4축 메트릭으로 품질 측정
Trajectory 검증 패턴 구현

테스트는 확인, 평가는 개선 — 둘 다 필요합니다.

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