Agent 평가 벤치마크 실전: AgentBench부터 DeepEval까지 성능 테스트 가이드

고객지원 Agent 하나를 테스트했습니다. 테스트 케이스 100개를 돌렸더니 성공률이 78%였습니다. 나쁘지 않아 보였습니다. 그런데 같은 테스트를 한 번 더 돌리자 성공률이 65%로 떨어졌습니다.

Agent 평가는 예전에 하던 일반 질의응답 평가와 완전히 다른 종류의 일입니다. Q&A 모델에는 “프랑스의 수도는?”이라고 물었을 때 “파리”라고 답하면 맞고, “마르세유”라고 답하면 틀립니다. 흑백이 분명합니다. Agent는 다릅니다. 생각하고, 계획하고, 도구를 호출하고, 중간에 마음을 바꾸기도 합니다. 같은 작업이어도 오늘은 A 경로로 성공하고, 내일은 B 경로로 실패하고, 모레는 C 경로로 다시 성공할 수 있습니다.

논문도 많이 읽고 AgentBench, WebArena 같은 벤치마크 문서도 봤지만 볼수록 더 헷갈렸습니다. 나중에 실제 프로젝트에서 몇 번 넘어지고 나서야 조금씩 이해했습니다. Agent 평가는 종착점만 보면 안 됩니다. 궤적을 봐야 합니다.

1. 왜 Agent 평가는 일반 질의응답보다 어려운가?

Agent의 핵심 문제는 자율성입니다. 실행할 때마다 다른 경로를 선택할 수 있습니다.

구체적인 예를 들어보겠습니다. 예전에 여행 예약 Agent를 테스트한 적이 있습니다. 작업은 “내일 베이징에서 상하이로 가는 가장 싼 항공편을 예약해줘”였습니다. 첫 번째 실행에서는 먼저 Ctrip을 조회하고, 항공편 세 개를 비교하고, 가장 싼 항공편을 고른 뒤 예약까지 해줬습니다. 완벽했습니다. 두 번째로 같은 작업을 실행하자 Ctrip을 조회한 뒤 Fliggy까지 조회했고, 그다음 5분 동안 무한 루프에 빠졌다가 결국 타임아웃으로 실패했습니다.

같은 입력, 다른 실행 궤적. Agent 평가의 핵심 난점은 여기에 있습니다. 필요한 것은 단순한 “맞음/틀림” 라벨이 아니라 전체 실행 과정을 분석할 수 있는 프레임워크입니다.

3계층 평가 프레임워크

Anthropic 공식 설명을 빌리면 Agent 평가는 세 계층으로 나누어 봐야 합니다.

추론 계층(Reasoning Layer): Agent의 계획이 맞는가? 작업을 제대로 이해했는가? 합리적인 실행 계획을 세웠는가?

행동 계층(Action Layer): Agent가 고른 도구가 맞는가? 인자를 제대로 전달했는가? 도구 호출 순서는 합리적인가?

전체 실행(Overall Execution): 작업을 최종적으로 완료했는가? 몇 단계를 썼는가? 효율은 어떤가?

DeepEval 문서에서 본 데이터가 꽤 인상적이었습니다. Agent 문제 중 가장 흔한 것은 도구 호출 실패입니다. Agent 실패의 약 40%가 잘못된 도구 선택이나 잘못된 인자 전달 때문에 발생합니다. 이것이 의미하는 바는 분명합니다. 대부분의 Agent 문제는 추론 계층이 아니라 행동 계층에서 터집니다.

기존 지표의 한계

전통적인 질의응답 평가는 정확도, F1 점수 같은 지표면 충분합니다. Agent는 그렇지 않습니다.

예를 들어 Agent의 작업 성공률이 78%라고 해봅시다. 이 숫자는 무엇을 알려줄까요? 거의 아무것도 알려주지 않습니다.

이유는 78%가 다음 중 무엇이든 의미할 수 있기 때문입니다.

• 계획은 맞았지만 도구 호출이 실패했습니다. 행동 계층 문제입니다.
• 애초에 계획이 틀렸고, 뒤쪽 실행은 헛수고였습니다. 추론 계층 문제입니다.
• 계획도 맞고 도구도 제대로 호출했지만 마지막 단계에서 삐끗했습니다. 전체 실행 문제입니다.

실패 원인이 다르면 최적화 방향도 완전히 달라집니다. 계획이 틀렸다면 Prompt를 고치거나 모델을 바꿔야 합니다. 도구 호출이 틀렸다면 도구 정의를 수정하거나 검증을 추가해야 합니다. 마지막 단계에서 틀렸다면 경계 조건 처리가 부족한 것일 수 있습니다.

그래서 Agent 평가의 핵심은 “성공했는가”가 아니라 “어디에서 실패했는가”입니다.

2. 5대 주류 평가 벤치마크 비교

시중에는 Agent 평가 벤치마크가 꽤 많습니다. 여기서는 제가 실제로 조사했거나 돌려본 5개 주류 벤치마크를 골라 이야기해보겠습니다.

AgentBench: 종합 능력 벤치마크

AgentBench는 칭화대가 ICLR’24에 발표한 벤치마크로, LLM-as-Agent를 위해 만들어진 첫 번째 종합 벤치마크라고 볼 수 있습니다. 데이터베이스 질의, 웹 브라우징, API 호출, 코드 실행 등 8개 환경을 포함합니다.

직접 돌려본 느낌은 이렇습니다. 커버리지는 확실히 넓고, 범용 Agent의 모델 선택 평가에 적합합니다. 다만 환경 구축이 꽤 번거롭습니다. Docker 환경이 필요하고, Dev 세트만 해도 LLM 호출이 4,000번 넘게 발생해 비용도 낮지 않습니다.

적합한 시나리오: 여러 모델 중 하나를 Agent backbone으로 골라야 한다면 AgentBench가 종합 점수를 제공해줄 수 있습니다.

Vultr - 고성능 NVMe 클라우드 서버, 전 세계 32개 노드, Docker 원클릭 배포

요금 보기 →광고

WebArena: Web 내비게이션 전용

WebArena는 Web 환경에 집중합니다. 전자상거래, 포럼, 지도 같은 실제 웹사이트 환경을 구성해 Agent가 그 안에서 내비게이션 작업을 수행하도록 합니다.

예를 들어 “Reddit에서 게시물을 찾아 댓글을 남겨라” 같은 작업입니다. 테스트 대상은 Agent가 실제 Web 환경에서 얼마나 잘 조작할 수 있는지입니다.

적합한 시나리오: 브라우저 Agent나 Web 자동화를 만들고 있다면 WebArena가 가장 맞는 벤치마크입니다.

τ-Bench: 멀티턴 대화 테스트

τ-Bench, 즉 tau-bench는 Anthropic이 개발에 참여한 벤치마크로, 멀티턴 상호작용 시나리오에 집중합니다. 소매 고객지원, 항공 예약 같은 실제 서비스 시나리오를 시뮬레이션하고, 사용자 역할까지 시뮬레이션해 Agent와 대화합니다.

이 벤치마크의 특징은 단일 턴 작업 완료만 보는 것이 아니라 멀티턴 대화에서 Agent가 어떻게 행동하는지를 테스트한다는 점입니다.

적합한 시나리오: 고객지원 Agent, 예약 Agent처럼 대화형 서비스 Agent를 만들고 있다면 잘 맞습니다.

SWE-Bench: 코드 능력 벤치마크

SWE-Bench는 코딩 능력을 전문적으로 평가합니다. GitHub의 실제 issue와 PR을 가져와 Agent가 코드를 수정하도록 합니다.

이 벤치마크는 꽤 빡빡합니다. Agent는 코드 작성 능력뿐 아니라 프로젝트 구조를 이해하고, 문제 위치를 찾고, 테스트를 통과하는 코드를 작성할 수 있어야 합니다.

적합한 시나리오: 코딩 어시스턴트 Agent나 코드 수정 Agent를 만들고 있다면 적합합니다.

Claw-Eval / ACE-Bench: 2026년 신규 벤치마크

Claw-Eval, 이후 이름이 ACE-Bench로 바뀐 벤치마크는 2026년에 나온 새 기준입니다. 특징은 난이도를 설정할 수 있다는 점입니다. 자신의 Agent 수준에 맞춰 작업 난이도를 조정할 수 있습니다.

이 접근은 꽤 좋습니다. 평가는 한 번 하고 끝나는 일이 아니라 지속되는 과정입니다. Agent 능력이 올라가면 작업 난이도도 함께 올라가야 합니다.

적합한 시나리오: 기업 내부 맞춤 평가를 만들거나, 계속 반복 개선할 수 있는 평가 체계를 세우고 싶을 때 적합합니다.

벤치마크 선택 기준

말하자면 벤치마크 선택에는 표준 답안이 없습니다. 결국 자신의 시나리오를 봐야 합니다.

제 제안은 이렇습니다. 먼저 AgentBench로 기준선을 세워 Agent의 종합 능력을 확인합니다. 그다음 구체적인 시나리오에 맞춰 전용 벤치마크로 깊게 테스트합니다.

3. Agent 평가 지표 체계

벤치마크를 이야기했으니 이제 Agent 성능을 어떤 지표로 측정할지 보겠습니다. 저는 Agent 평가의 여러 계층을 거의 커버하는 6가지 핵심 지표를 정리했습니다.

1. 작업 성공률(Success Rate)

가장 직접적인 지표입니다. 작업을 완료했는가?

하지만 이 지표에는 함정이 있습니다. 무엇을 “완료”라고 볼 것인가? Agent가 스스로 완료했다고 말하면 완료인가, 아니면 객관적인 기준이 있어야 하는가?

저는 지금 명확한 검수 조건을 정의하는 방식으로 처리합니다. 예를 들어 “항공편 예약” 작업의 검수 조건은 다음과 같습니다.

• 주문 번호가 존재합니다.
• 항공편 정보가 정확합니다.
• 가격이 예상 범위 안에 있습니다.

검수 조건이 명확할수록 성공률 지표도 의미가 생깁니다.

2. 도구 호출 정확도

이 지표는 두 부분으로 나뉩니다. 올바른 도구를 선택했는지, 올바른 인자를 전달했는지입니다.

올바른 도구 선택은 Agent가 도구를 호출해야 할 때 정확한 도구를 골랐는지를 뜻합니다. 올바른 인자 전달은 도구 인자의 형식과 내용이 모두 맞는지를 뜻합니다.

실제 프로젝트에서는 이 지표가 Agent의 약점을 특히 잘 드러낸다는 것을 발견했습니다. 어떤 Agent는 작업 성공률이 82%였지만 도구 호출 정확도는 68%에 불과했습니다. 자세히 보니 “조회”와 “예약” 두 작업에서 도구를 자주 잘못 선택하고 있었습니다.

3. 진행률(Progress Rate)

멀티스텝 작업에서는 진행률이 Agent가 어느 단계까지 갔는지를 보여줍니다.

예를 들어 작업이 5단계이고 Agent가 4단계에서 실패했다고 해봅시다. 성공률은 0%지만 진행률은 80%입니다. 두 숫자를 함께 보면 이 Agent가 성공에 아주 멀지는 않고, 마지막 단계 최적화만 남았을 수 있다는 것을 알 수 있습니다.

4. 추론 품질 지표

이 지표들은 Agent의 계획 능력을 평가합니다.

PlanQuality(계획 합리성): Agent가 세운 계획이 합리적인가? 단계 간 논리 관계가 맞는가?

PlanAdherence(계획 일관성): Agent가 실제 실행할 때 원래 계획에서 벗어나지 않았는가?

이 두 지표는 LLM으로 평가해야 합니다. DeepEval의 PlanQualityMetric도 이렇게 동작합니다. 다른 LLM을 사용해 Agent의 계획 품질을 판단합니다.

5. 효율 지표

StepEfficiency(단계 효율): Agent가 작업을 완료하는 데 몇 단계를 썼는가? 이론적으로 최소 몇 단계가 필요한가?

Railway - 현대적인 배포 플랫폼, 번거로운 운영 없이 몇 분 만에 라이브

지금 시작 →광고

어떤 작업이 최소 3단계로 끝날 수 있는데 Agent가 10단계를 썼다면 StepEfficiency는 30%입니다.

Token 소모량도 있습니다. 이 지표는 비용과 바로 연결됩니다. 같은 작업을 완료하는 데 어떤 Agent는 1,000 token을 쓰고 다른 Agent는 5,000 token을 쓴다면 비용 차이는 5배입니다.

6. 안정성 지표

Agent의 성능은 안정적인가? 같은 작업을 10번 실행했을 때 성공률의 표준편차는 얼마나 큰가?

저도 예전에는 이 지표를 크게 신경 쓰지 않았습니다. 그러다 한 번 배포 후에 알게 됐습니다. 테스트 환경에서는 잘 돌던 Agent가 프로덕션에서는 성공률 변동이 유난히 컸습니다. 나중에 확인해보니 프로덕션의 요청 타임아웃 설정이 테스트 환경보다 짧아 일부 작업이 중간에 잘리고 있었습니다.

지표와 3계층 프레임워크의 대응

이 지표들을 앞에서 말한 3계층 평가 프레임워크와 대응시키면 다음과 같습니다.

이렇게 보면 어떤 지표가 낮을 때 문제가 어느 계층에 있는지 알 수 있고, 최적화 방향도 분명해집니다.

4. 오픈소스 평가 도구 비교: DeepEval vs LangSmith vs Arize Phoenix

지표를 정의했다면 이제 무엇으로 측정할지 정해야 합니다. 저는 세 가지 주류 오픈소스 평가 도구를 비교해봤습니다.

DeepEval: 컴포넌트 수준 평가의 첫 선택

DeepEval은 Confident AI가 개발한 오픈소스 Python 프레임워크로, LLM과 Agent 평가에 특화되어 있습니다.

핵심 특징은 컴포넌트 수준 평가입니다. 최종 결과만 보는 대신 Agent의 어느 노드에든 평가를 삽입할 수 있습니다.

내장 지표는 6가지입니다.

• TaskCompletionMetric(작업 완료)
• StepEfficiencyMetric(단계 효율)
• ToolCorrectnessMetric(도구 정확성)
• ArgumentCorrectnessMetric(인자 정확성)
• PlanQualityMetric(계획 품질)
• PlanAdherenceMetric(계획 일관성)

저는 한 여행 예약 Agent 프로젝트에서 DeepEval로 평가를 해봤고, 효과가 꽤 좋았습니다. @observe 데코레이터가 있어서 Agent 실행 중 추론, 도구 호출 같은 컴포넌트를 자동으로 추적하고 계층별로 평가할 수 있습니다.

DeepEval에는 Confident AI 클라우드 플랫폼도 함께 있어 평가 결과 시각화와 데이터셋 관리를 할 수 있습니다. 다만 오픈소스 부분만으로도 이미 충분히 쓸 만합니다.

LangSmith: LangChain 공식 도구

LangChain으로 Agent를 개발하고 있다면 LangSmith가 가장 편합니다. LangChain과 매끄럽게 통합되고, 전체 실행 체인을 자동으로 추적할 수 있습니다.

LangSmith의 강점은 전체 체인 추적입니다. Agent의 모든 LLM 호출, 모든 도구 실행을 볼 수 있고, 전체 실행 궤적이 남습니다.

다만 상용 제품이라 가격 제한이 있습니다. 소규모 테스트에는 괜찮지만 대규모 평가로 가면 비용이 올라갑니다.

Arize Phoenix: 관측성 우선

Arize Phoenix는 OpenTelemetry 아키텍처 기반이며 관측성에 집중합니다.

접근 방식은 Agent 실행 과정을 분산 시스템처럼 모니터링하는 것입니다. LLM 호출과 도구 호출은 Span이고, 전체 실행 궤적은 Trace입니다.

Phoenix는 프로덕션 모니터링에 특히 친화적입니다. 이상 탐지와 성능 분석 기능이 있어 배포 후 지속 모니터링에 적합합니다.

도구 선택 기준

도구 선택도 결국 상황에 따라 달라집니다.

LangChain을 사용하고 있는가?
  → 예: LangSmith 우선(매끄러운 통합)
  → 아니오: 프로덕션 모니터링이 필요한가?
       → 예: Arize Phoenix + DeepEval
       → 아니오: 순수 개발 평가 → DeepEval

제가 실제로 쓰는 조합은 DeepEval로 개발 단계 평가를 하고, Arize Phoenix로 프로덕션 모니터링을 하는 것입니다. 두 도구가 서로 보완되어 꽤 잘 맞습니다.

5. 코드 실전: DeepEval로 여행 예약 Agent 평가하기

이론은 이쯤 하고 실제 예시를 보겠습니다. 아래는 완전한 DeepEval 평가 코드 예시입니다. 제가 여행 예약 Agent 프로젝트에서 실제로 써본 형태입니다.

Agent 구현

먼저 간단한 여행 예약 Agent를 정의하고 @observe 데코레이터로 각 컴포넌트를 추적합니다.

from deepeval.tracing import observe
from deepeval.metrics import (
    PlanQualityMetric,
    PlanAdherenceMetric,
    ToolCorrectnessMetric,
    ArgumentCorrectnessMetric,
    TaskCompletionMetric,
    StepEfficiencyMetric
)

# 도구 정의
@observe(type="tool")
def search_flights(origin: str, destination: str, date: str):
    """항공편 검색"""
    # 실제 프로젝트에서는 여기에서 실제 API를 호출합니다
    # 예시는 모의 데이터를 반환합니다
    return [
        {"flight": "CA1234", "price": 500, "time": "08:00"},
        {"flight": "MU5678", "price": 450, "time": "10:30"},
        {"flight": "CZ9012", "price": 520, "time": "14:00"}
    ]

@observe(type="tool")
def book_flight(flight_number: str, passenger_info: dict):
    """항공편 예약"""
    # 실제 프로젝트에서는 여기에서 실제 예약 API를 호출합니다
    return {"order_id": "ORD123456", "status": "confirmed"}

# Agent 본체
@observe(type="agent")
def travel_agent(user_input: str):
    """
    여행 예약 Agent
    입력: 사용자의 예약 요청
    출력: 예약 결과 또는 실패 정보
    """
    # 추론 계층: 작업을 파싱하고 계획을 세웁니다
    @observe(type="reasoning")
    def parse_and_plan(input_text):
        # 여기에서는 원래 LLM을 호출해 파싱하고 계획해야 합니다
        # 예시는 간단한 규칙 기반 파싱을 사용합니다
        plan = {
            "task": "book_flight",
            "origin": "베이징",
            "destination": "상하이",
            "date": "내일",
            "steps": ["search", "compare", "book"]
        }
        return plan

    plan = parse_and_plan(user_input)

    # 행동 계층: 도구 호출 실행
    # 1단계: 항공편 검색
    flights = search_flights(
        plan["origin"],
        plan["destination"],
        plan["date"]
    )

    # 2단계: 가장 싼 항공편 선택
    cheapest = min(flights, key=lambda x: x["price"])

    # 3단계: 예약
    result = book_flight(
        cheapest["flight"],
        {"name": "테스트 사용자"}
    )

    return result

평가 지표 설정

from deepeval import evaluate
from deepeval.test_case import LLMTestCase

# 테스트 데이터 정의
test_cases = [
    LLMTestCase(
        input="내일 베이징에서 상하이로 가는 가장 싼 항공편을 예약해줘",
        expected_output={"order_id": "ORD123456", "status": "confirmed"}
    ),
    LLMTestCase(
        input="다음 주 수요일 광저우에서 선전으로 가는 항공편을 찾아줘",
        expected_output={"flights": [...]}
    )
]

# 평가 지표 설정
metrics = [
    TaskCompletionMetric(
        threshold=0.7,
        evaluation_model="gpt-4o"
    ),
    StepEfficiencyMetric(
        threshold=0.5,  # 최소 50% 효율을 기대합니다
        minimum_steps=3  # 최소 3단계가 필요합니다
    ),
    ToolCorrectnessMetric(
        threshold=0.8
    ),
    ArgumentCorrectnessMetric(
        threshold=0.8
    ),
    PlanQualityMetric(
        threshold=0.7,
        evaluation_model="gpt-4o"
    )
]

평가 실행

# 방법 1: 단일 평가
for test_case in test_cases:
    result = travel_agent(test_case.input)
    test_case.actual_output = result

evaluate(test_cases, metrics)

# 방법 2: 데이터셋 배치 평가
from deepeval.dataset import EvaluationDataset, Golden

dataset = EvaluationDataset(goldens=[
    Golden(input="내일 베이징에서 상하이로 가는 가장 싼 항공편을 예약해줘"),
    Golden(input="다음 주 청두에서 쿤밍으로 가는 항공편 정보를 찾아줘")
])

for golden in dataset.evals_iterator(metrics=metrics):
    output = travel_agent(golden.input)
    # 평가는 자동으로 기록되고 계산됩니다

평가 결과 해석

DeepEval은 각 지표의 점수와 통과 여부를 출력합니다. 예를 들어 이런 결과를 얻었다고 해봅시다.

이 결과에서 무엇을 볼 수 있을까요?

• 작업 완료율은 꽤 높습니다(85%). 대부분의 작업은 성공합니다.
• 단계 효율이 낮습니다(45%). Agent가 불필요한 단계를 거쳤을 수 있습니다.
• 도구 선택 정확도는 높지만(90%), 인자 정확도는 부족합니다(72%).

최적화 방향은 분명합니다. 인자 구성 로직을 집중적으로 고치고, 불필요한 단계를 줄여야 합니다.

6. 프로덕션 환경 평가 실전

개발 단계 평가를 끝내고 Agent를 배포하면 평가도 끝날까요? 전혀 그렇지 않습니다.

Alibaba Cloud - 개발자 클라우드 1순위, Lighthouse 서버 15% 할인

15% 할인 받기 →광고

Agent의 프로덕션 성능은 개발 환경과 자주 다릅니다. 사용자 입력은 더 무작위적이고, 경계 조건은 더 많고, 동시성 압력도 더 큽니다. 개발부터 프로덕션까지 이어지는 완전한 평가 루프가 필요합니다.

개발 단계: 기준선 만들기

개발 단계의 목표는 Agent의 기본 능력 기준선을 만드는 것입니다.

먼저 AgentBench 같은 종합 벤치마크로 한 번 측정해 Agent의 범용 능력 수준을 봅니다. 그다음 사용자 정의 데이터셋으로 구체적인 시나리오를 테스트합니다. 데이터셋은 대표 작업, 경계 조건, 실패 사례를 포함해야 합니다.

개발 단계 평가에서 해야 할 일은 다음과 같습니다.

• 테스트 데이터셋이 사용자 시나리오의 80% 이상을 커버합니다.
• 각 지표에 명확한 기준값이 있습니다.
• 실패 사례를 기록하고 실패 원인 분포를 분석합니다.

배포 단계: 카나리와 A/B 테스트

Agent를 배포할 때 바로 전체 공개하지 마세요. 먼저 카나리로 내보냅니다.

카나리 평가의 핵심은 비교입니다. 카나리 그룹과 대조군의 성능 차이를 봅니다.

# 카나리 평가 예시
def ab_test_evaluation():
    # 대조군: 이전 버전 Agent
    control_results = evaluate_agent(old_agent, test_cases)

    # 카나리 그룹: 새 버전 Agent
    treatment_results = evaluate_agent(new_agent, test_cases)

    # 핵심 지표 비교
    comparison = {
        "success_rate": {
            "control": control_results.success_rate,
            "treatment": treatment_results.success_rate,
            "delta": treatment_results.success_rate - control_results.success_rate
        },
        "step_efficiency": {
            "control": control_results.step_efficiency,
            "treatment": treatment_results.step_efficiency,
            "delta": treatment_results.step_efficiency - control_results.step_efficiency
        }
    }

    return comparison

카나리 비율은 먼저 1%로 시작하는 것을 권장합니다. 24시간 동안 문제가 없으면 5%, 그다음 10%, 20%, 50%, 100%로 올립니다. 각 단계마다 핵심 지표의 변화를 확인해야 합니다.

프로덕션 단계: 지속 모니터링

Agent가 배포된 뒤 평가는 모니터링이 됩니다.

모니터링의 초점은 이상 탐지입니다. 성공률이 갑자기 떨어지거나, 응답 시간이 갑자기 길어지거나, 특정 도구 호출이 갑자기 실패하는 상황을 잡아야 합니다. 이런 이상은 제때 알림으로 이어져야 하고, 사용자 피드백이 대규모로 쌓이기 전에 문제를 발견할 수 있어야 합니다.

샘플링 전략: 프로덕션에서는 모든 요청을 평가할 수 없으므로 샘플링이 필요합니다. 제 제안은 다음과 같습니다.

• 일반 작업: 1%-5% 샘플링
• 핵심 작업(예: 결제, 예약): 100% 평가
• 이상 요청(실패, 타임아웃): 100% 평가 큐에 넣기

비용 제어: 평가 자체에도 비용이 듭니다. 특히 LLM으로 추론 품질을 평가할 때 그렇습니다. 몇 가지 요령이 있습니다.

• 작은 모델로 평가합니다. 예: gpt-4o-mini
• 비동기 평가를 사용해 메인 흐름을 막지 않습니다.
• 평가 서킷 브레이커를 설정하고 최대 샘플 수를 100-1000으로 제한합니다.

수동 검토의 필요성

자동 평가가 아무리 좋아도 사람이 봐야 하는 경계 사례는 있습니다.

제가 지금 쓰는 방식은 자동 평가에서 “불확실”로 표시된 사례를 수동 검토 큐에 넣는 것입니다. 매주 10-20개 사례를 사람이 직접 보고 자동 평가가 정확한지 판단합니다.

수동 검토에는 또 하나의 가치가 있습니다. 자동 평가가 커버하지 못한 문제를 발견할 수 있습니다. 예를 들어 Agent의 답변 톤이 좋지 않거나 사용자에게 혼란을 주는 경우입니다. 이런 문제는 자동 평가가 잡기 어렵지만 사용자 경험에는 큰 영향을 줍니다.

완전한 평가 루프

전체 흐름을 연결하면 다음과 같습니다.

개발 단계
├── AgentBench 벤치마크 테스트
├── 사용자 정의 데이터셋 평가
└── 실패 사례 분석
    ↓
배포 단계
├── 카나리 테스트(1% → 5% → 10% → ...)
├── A/B 비교 평가
└── 롤백 메커니즘
    ↓
프로덕션 단계
├── 샘플링 모니터링(1%-5%)
├── 이상 탐지 알림
├── 수동 검토 큐
    ↓
최적화 반복
├── 실패 사례 원인 분석
├── Prompt/도구 조정
└── 재평가
    ↓ (반복)

이것은 한 번 하고 끝나는 작업이 아니라 지속적으로 반복되는 과정입니다. Agent의 능력은 퇴화할 수 있고, 사용자 시나리오는 바뀌며, 새로운 문제가 계속 나옵니다. 평가도 함께 진화해야 합니다.

결론

Agent 평가는 결국 이렇게 말할 수 있습니다. 종착점만 보지 말고 궤적을 보세요.

제가 밟았던 함정은 이랬습니다. 성공률 78%면 충분하다고 생각했는데, 배포 후 같은 작업의 성공률이 30%씩 흔들렸습니다. 도구 호출은 괜찮다고 생각했는데 실패의 40%가 인자 전달 오류였습니다. 개발 단계 평가면 충분하다고 생각했는데 프로덕션 문제는 완전히 달랐습니다.

3계층 평가 프레임워크는 생각을 정리하는 데 도움이 됐습니다. 추론 계층은 계획을 보고, 행동 계층은 도구를 보고, 전체 실행은 결과를 봅니다. 5대 벤치마크는 기준선을 세우는 데 도움이 됐습니다. AgentBench는 종합 평가, τ-Bench는 멀티턴 평가, SWE-Bench는 코드 평가에 맞습니다. DeepEval은 코드화된 평가를 구현하는 데 도움이 됐습니다. @observe 데코레이터로 컴포넌트를 추적하고, 6대 지표를 계층별로 분석할 수 있습니다.

다음 단계로 할 수 있는 일은 다음과 같습니다.

1. AgentBench로 자신의 Agent를 측정해 기준선을 만듭니다.
2. DeepEval로 컴포넌트 수준 평가를 수행해 약한 지점을 찾습니다.
3. 프로덕션 모니터링 체계를 만들고, 이상 탐지와 수동 검토를 함께 운영합니다.

평가는 종착점이 아니라 출발점입니다. Agent 능력이 진화하면 평가도 함께 진화해야 합니다.