기존 프레임워크 비교 분석

9.1 기존 프레임워크를 이해해야 하는 이유

새로운 평가 프레임워크를 설계하려면, 먼저 이미 존재하는 것들이 무엇을 측정하고 무엇을 놓치고 있는지 정확히 이해해야 한다. 이것은 단순한 문헌 조사가 아니다. 기존 프레임워크의 설계 철학, 아키텍처 결정, 메트릭 선택의 배경을 분석하는 것은 — 우리가 설계할 6차원 프레임워크가 어떤 갭(gap)을 채우는지를 명확히 하는 필수 과정이다.

2022년 HELM(Holistic Evaluation of Language Models)이 발표된 이후, LLM 및 에이전트 평가 생태계는 폭발적으로 성장했다. 2024년 말 기준 GitHub에서 "LLM evaluation" 태그가 붙은 저장소만 500개 이상이며, 학술 논문은 매달 수십 편이 새로 출간된다. 하지만 이 생태계의 성장이 반드시 "평가 품질의 향상"을 의미하지는 않는다. 오히려 프레임워크 간 파편화(fragmentation)가 심화되고, 각 프레임워크가 서로 다른 것을 측정하면서 비교 가능성이 사라지는 현상이 발생하고 있다.

이 장에서 분석할 13개 프레임워크는 네 가지 카테고리로 분류할 수 있다:

1. LLM 평가 프레임워크: 모델 자체의 능력을 평가 (HELM, lm-eval-harness)
2. 단일 에이전트 벤치마크: 에이전트의 환경 내 행동을 평가 (WebArena, SWE-bench, ToolBench, AgentBench)
3. RAG 평가 프레임워크: 검색 증강 생성의 품질을 평가 (RAGAS, ARES, TruLens, DeepEval)
4. 멀티 에이전트 · 관측 프레임워크: 에이전트 협업 및 관측 (AutoGen Eval, CrewAI Eval, AgenticBench, LangSmith)

이 분류 자체가 이미 하나의 인사이트를 제공한다: 에이전트 평가의 전체 스펙트럼을 커버하는 프레임워크는 존재하지 않는다. 각 카테고리는 자신의 영역에서 깊이가 있지만, 카테고리 간 연결고리가 없다.

9.1.1 평가 프레임워크의 타당성 검증: 왜 "있는 것"으로 충분하지 않은가

"13개나 있는데 왜 새로 만드는가?"라는 질문에 답하기 위해, 기존 프레임워크의 타당성(validity)을 세 가지 측면에서 검증한다:

이 세 가지 타당성 중 하나라도 충족하지 못하면, 평가 결과의 신뢰성이 떨어진다. 불행히도, 13개 프레임워크 중 세 가지 타당성을 모두 명시적으로 검증한 것은 HELM뿐이며, HELM조차 에이전트 환경이 아닌 정적 텍스트에 국한된다.

9.1.2 기존 프레임워크의 "선택의 역설"

심리학자 Barry Schwartz의 "선택의 역설(Paradox of Choice)"은 에이전트 평가에도 적용된다. 13개 프레임워크가 존재함에도 불구하고, 실무자는 "어떤 것을 선택해야 하는가?"라는 질문에 직면한다. 선택지가 많을수록 결정이 어려워지고, 결국 아무것도 선택하지 않거나(분석 마비), 가장 익숙한 것만 반복 선택(편향)하게 된다.

분석 마비(Analysis Paralysis)의 실제 사례

한 금융 기관이 에이전트 기반 고객 지원 시스템을 구축하면서 평가 프레임워크를 선택해야 했다. RAG를 사용하므로 RAGAS가 자연스러운 선택이었지만, 에이전트의 도구 사용 능력도 평가하고 싶었고, 장기적으로는 멀티 에이전트로 확장할 계획이었다. 3개월간의 리서치 후, 결론은 "RAGAS + 커스텀 도구 평가 + LangSmith 모니터링"의 조합이었다. 세 프레임워크를 통합하는 데 추가 2개월이 소요되었다.

이 사례가 보여주는 것: 단일 프레임워크가 요구를 충족하지 못하면, 여러 프레임워크를 조합해야 하고, 이 조합 비용이 상당하다는 점이다. 13개 프레임워크가 있다는 것은 13개의 선택지가 아니라, 13개 중 몇 개를 선택할지, 어떻게 연결할지, 결과를 어떻게 통합할지라는 조합적 복잡성(combinatorial complexity)을 의미한다.

편향적 선택(Biased Selection)의 위험

분석 마비의 반대편에는 "가장 익숙한 것"을 선택하는 편향이 있다. 2024년 말 기준, RAG 평가에서 RAGAS가 압도적 점유율을 가진다. 하지만 RAGAS가 반드시 최선의 선택은 아니다:

편향적 선택의 근원은 가용성 휴리스틱(availability heuristic)이다. 가장 많이 언급되고, 가장 많은 GitHub star를 가진 프레임워크가 "최고"라고 인지되는 현상이다. 하지만 GitHub star 수는 커뮤니티 인기도를 나타낼 뿐, 특정 사용 사례에 대한 적합성을 보장하지 않는다.

이 장은 이 딜레마를 해결하는 두 가지 도구를 제공한다: (1) 메가 비교 테이블(9.4절)은 객관적 비교를 가능하게 하고, (2) 결정 트리(9.4.2절)는 상황에 맞는 선택을 안내한다. 하지만 이 두 도구만으로는 충분하지 않다. 13개 프레임워크 모두가 같은 것을 다르게 측정할 뿐, 우리가 정말 필요한 것(멀티 에이전트 협업 품질, 안전성 거부권, 비용-품질 트레이드오프의 통합적 평가)을 측정하는 프레임워크는 없다. 이것이 Part III의 존재 이유다.

9.2 프레임워크 카테고리 분류

13개 프레임워크를 네 가지 카테고리로 나누는 것은 단순한 분류 작업이 아니다. 각 카테고리는 평가 대상, 메트릭 철학, 자동화 수준, 그리고 한계점에서 근본적으로 다른 패러다임을 대표한다.

9.2.1 카테고리 I: LLM 평가 프레임워크

LLM 평가 프레임워크는 모델 자체의 능력을 평가한다. 에이전트가 아닌 언어 모델이 다양한 태스크에서 어떤 성능을 보이는지 측정한다. 핵심 질문은 "이 모델이 무엇을 얼마나 잘 하는가?"이다.

이 카테고리가 에이전트 평가와 관련이 있는 이유는 에이전트의 기반 모델 성능이 에이전트 성능의 하한선을 결정하기 때문이다. 기반 모델이 MMLU에서 60%인 에이전트가 환경에서 80% 성공률을 보이는 것은 불가능에 가깝다. 반면, MMLU 90%의 모델이 환경에서 40%만 달성하는 것은 흔하다 — 기반 능력이 환경 적응으로 완전히 전이되지 않기 때문이다.

HELM은 "렌즈(lens)"라는 개념으로 하나의 모델을 여러 메트릭으로 다각도 조명한다. 반면 lm-eval-harness는 "파이프라인" 철학을 따른다. 태스크 정의, 모델 호출, 메트릭 계산의 명확한 파이프라인을 제공하며 커뮤니티가 태스크를 쉽게 추가할 수 있는 확장성을 강조한다.

9.2.2 카테고리 II: 단일 에이전트 벤치마크

동적 환경에서의 에이전트 상호작용을 평가한다. WebArena가 주목받는 이유는 실제 웹사이트를 그대로 복제했다는 점이다. 이 카테고리의 핵심 질문은 "에이전트가 환경 안에서 목표를 달성할 수 있는가?"이다.

단일 에이전트 벤치마크의 공통적 특징은 세 가지다:

1. 환경 제공: 에이전트가 상호작용할 가상/시뮬레이션 환경을 제공한다. WebArena는 웹사이트, SWE-bench는 Git 리포지토리, ToolBench는 REST API, AgentBench는 8개 환경을 각각 제공한다.
2. 목표 정의: 에이전트가 달성해야 할 명확한 목표를 정의한다. "이 이슈를 수정하라", "이 정보를 찾아라" 등.
3. 이진 평가: 대부분 성공(Success) 또는 실패(Failure)의 이진 판정을 사용한다. 부분적 성공을 측정하는 벤치마크는 드물다.

환경 복잡도 스펙트럼: MiniWoB++에서 OSWorld까지

단일 에이전트 벤치마크의 진화는 환경 복잡도의 증가로 요약된다. 2017년 MiniWoB++가 합성 미니 웹 태스크로 시작했고, 2023년 WebArena가 실제 웹 환경을 도입했으며, 2024년 OSWorld가 완전한 데스크톱 환경을 제공했다:

이 테이블이 보여주는 핵심: 환경이 복잡해질수록 인간-AI 격차가 벌어진다. MiniWoB++에서 19%p이던 격차가 OSWorld에서는 63%p로 확대된다. 이것은 에이전트 평가가 모델 평가보다 훨씬 어려운 문제임을 시사한다. 모델이 지식을 갖추더라도 복잡한 환경에서 그 지식을 행동으로 전환하는 것은 전혀 다른 능력이다.

이 세 가지 특징은 LLM 평가와의 근본적 차이를 만든다. LLM 평가는 "환경"이 없다: 정적 텍스트가 입력으로 주어지고 텍스트가 출력으로 나온다. 하지만 에이전트 평가에서는 환경이 핵심 변수다. 같은 모델이라도 환경이 달라지면 성능이 급격히 변한다: GPT-4o는 WebArena에서 28.4%이지만 OSWorld에서는 12.5%다. 이 차이는 모델이 아니라 환경의 복잡성에서 온다.

9.2.3 카테고리 III: RAG 평가 프레임워크

RAG(검색 증강 생성) 평가 프레임워크는 에이전트 평가의 특수한 하위 문제(subproblem)를 다룬다. "에이전트가 외부 지식을 검색하여 활용하는 능력"을 평가하는데, 이것은 멀티 에이전트 시스템에서 한 에이전트가 "정보 검색자(information retriever)" 역할을 할 때 핵심적으로 요구되는 능력이다.

이 카테고리의 프레임워크들은 공통적으로 세 가지 품질 차원을 평가한다:

1. 검색 품질(Retrieval Quality): 관련성 높은 문서를 검색했는가? — Context Precision, Context Relevance
2. 생성 품질(Generation Quality): 검색된 문서에 기반하여 충실하게 응답했는가? — Faithfulness, Answer Relevance
3. 전체 파이프라인 품질(Pipeline Quality): 검색-생성 파이프라인 전체가 효율적인가? — 컨텍스트 활용률, 지연 시간, 비용

RAGAS가 혁신적인 이유는 reference-free 평가를 가능하게 한 것이다. 정답 없이도 Faithfulness, Answer Relevance, Context Precision/Recall을 평가한다. 하지만 RAG 시스템만 평가 가능하다는 명확한 한계가 있다.

ARES: 예측 기반 자동 평가의 독특한 접근

ARES(Saad-Falcon et al., 2024)는 다른 RAG 평가 프레임워크와 근본적으로 다른 접근을 취한다. LLM-as-Judge 대신 미세조정된 판별 모델(discriminator)을 사용하여 평가한다. 이 접근의 장점은 평가 일관성이 높다는 것이지만, 도메인별 학습 데이터가 필요하다는 단점이 있다.

TruLens: RAG Triad와 피드백 루프

TruLens의 핵심 기여는 RAG Triad 개념이다: (1) Groundedness(답변이 컨텍스트에 근거하는가), (2) Answer Relevance(답변이 질문에 관련성이 있는가), (3) Context Relevance(컨텍스트가 질문에 관련성이 있는가). 이 세 가지가 모두 충족되어야 고품질 RAG로 판정한다.

TruLens의 차별점은 피드백 루프(feedback loop)다. 평가 결과를 실시간으로 애플리케이션에 피드백하여, 품질이 낮은 응답을 자동으로 재시도하거나 인간에게 에스컬레이션하는 메커니즘을 제공한다. 이것은 "평가 → 개선 → 재평가"의 지속적 개선 루프를 가능하게 한다.

DeepEval: Pytest 스타일의 단정적 테스트

DeepEval은 소프트웨어 테스트의 단정적 테스트(assertion-based testing) 패러다임을 RAG 평가에 적용했다. 개발자가 pytest처럼 테스트 케이스를 작성하고, 각 케이스에서 기대 품질을 명시적으로 선언한다:

from deepeval import assert_test
from deepeval.test_case import LLMTestCase
from deepeval.metrics import FaithfulnessMetric, AnswerRelevancyMetric

test_case = LLMTestCase(
    input="에이전트 평가의 핵심 차원은?",
    actual_output="태스크 완료도, 과정 품질, 견고성, 안전성, 비용 효율, 협업 횈률",
    retrieval_context=["에이전트 평가는 6차원으로 구성된다..."]
)

# 단정적 테스트: Faithfulness ≥ 0.8, Relevancy ≥ 0.7
assert_test(test_case, [
    FaithfulnessMetric(threshold=0.8),
    AnswerRelevancyMetric(threshold=0.7),
])

이 접근의 장점은 CI/CD 통합이 용이하다는 것이다. pytest와 동일한 방식으로 평가를 자동화할 수 있어, RAG 시스템의 품질을 지속적으로 모니터링할 수 있다. 하지만 "테스트 케이스가 현실을 얼마나 대표하는가?"라는 질문이 여전히 남는다.

9.2.4 카테고리 IV: 멀티 에이전트/관측 프레임워크

가장 새롭고 가장 덜 성숙했으며 가장 큰 갭이 존재하는 영역이다. 결정적 한계는 프레임워크 종속성이다. AutoGen Eval은 AutoGen으로 만든 시스템만, CrewAI Eval은 CrewAI로 만든 시스템만 평가할 수 있다.

이 카테고리는 세 가지 근본적 도전에 직면한다:

1. 평가 단위의 모호성: "무엇"을 평가할 것인가? 개별 에이전트? 에이전트 간 대화? 전체 크루의 산출물? 현재 프레임워크는 이 질문에 대한 합의가 없다.
2. 협업 품질의 정량화: "좋은 협업"이란 무엇인가? 빠른 합의? 골고루 참여? 정확한 역할 분담? 이것은 단일 메트릭으로 포착할 수 없는 다차원적 개념이다.
3. 환경의 복잡성: 멀티 에이전트 환경은 단일 에이전트 환경보다 기하급수적으로 복잡하다. $N$개 에이전트가 $M$개 상태를 가진 환경에서 상호작용하면, 가능한 상태 공간은 $O(M^N)$이다.

9.3 심층 프레임워크 분석

이 절에서는 13개 프레임워크 중 가장 영향력 있는 9개를 하나씩 심층 분석한다. 각 분석은 아키텍처와 설계 철학, 핵심 메트릭의 수학적 정의, 장점과 한계, 실제 사용 코드 예시를 포함한다.

9.3.1 HELM — Holistic Evaluation of Language Models

HELM의 핵심 혁신은 "시나리오 x 메트릭" 행렬이다. 전통적 벤치마크가 하나의 태스크에서 하나의 점수를 산출하는 방식과 달리, HELM은 16개 시나리오를 7개 메트릭 렌즈로 평가하여 112개의 평가 결과를 산출한다.

7개 메트릭 렌즈는 각각 독립적으로 정의된다:

HELM의 보정 렌즈는 에이전트 시스템 설계에 중요한 시사점을 제공한다. 에이전트가 "확신이 높은데 틀리면" 위험한 행동을 하고, "확신이 낮은데 맞으면" 기회를 놓친다. 따라서 에이전트 평가에서도 보정 오류를 측정하는 것이 중요하다. 하지만 HELM 자체는 정적 텍스트 평가이므로, 에이전트의 동적 환경에서의 보정 오류를 직접 측정하지는 못한다.

HELM의 16개 시나리오는 Information Extraction, Intent Classification, Summarization, Reading Comprehension, Toxicity Detection, Coreference Resolution, QA, Knowledge, Dialogue, Code Generation, Mathematical Reasoning, Instruction Following, Creative Writing, Scientific Reasoning, Reasoning, Word Sense Disambiguation 영역을 커버한다. 이 범위는 언어 모델로서의 능력을 종합적으로 평가하지만, 에이전트로서의 능력(환경 탐색, 도구 사용, 다단계 추론)은 포함하지 않는다.

HELM의 평가 파이프라인 아키텍처

HELM의 내부 아키텍처는 세 가지 핵심 컴포넌트로 구성된다:

HELM이 에이전트 평가에 주는 시사점: "다렌즈 평가"의 선구

HELM의 "시나리오 x 메트릭" 행렬은 본서의 6차원 프레임워크에 직접적 영감을 준다. 단일 점수가 아닌 다각적 평가라는 발상은 에이전트 평가에서도 유효하다:

이 매핑이 보여주듯, HELM의 7개 렌즈 중 6개가 에이전트 평가 차원으로 직접 매핑된다. 남은 하나(Bias 렌즈)도 안전성 차원에 통합될 수 있다. 즉, HELM의 "다렌즈" 접근이 에이전트 평가의 "다차원" 접근의 원형이다. 다만 HELM은 정적 텍스트에 국한되므로, 동적 환경에서의 행동 평가(궤적 분석, 도구 사용, 협업 등)는 추가 차원이 필요하다.

1. Runner: 시나리오별로 모델을 실행하고 예측을 수집. 각 시나리오는 Adaptation(예: few-shot prompting 전략)을 지정할 수 있다.
2. Metric Executor: 수집된 예측에 대해 7개 렌즈 메트릭을 병렬로 계산. 일부 메트릭(Toxicity, Bias)은 외부 API(Perspective API, Winobias 등)를 호출한다.
3. Visualizer: 결과를 112개 셀의 히트맵으로 시각화. 각 셀은 (시나리오, 렌즈) 쌍에 대한 점수를 나타낸다.

이 아키텍처의 장점은 새로운 렌즈나 시나리오를 추가할 때 다른 컴포넌트를 수정할 필요가 없다는 것이다. 반면, 각 시나리오 실행이 독립적이므로 시나리오 간의 상관관계(correlation)를 자동으로 분석하지는 않는다. 예를 들어 "QA 정확도가 높은 모델이 Summarization에서도 높은가?"라는 질문에 HELM 자체는 답하지 못한다.

HELM Lite와 Classic HELM

2024년에 HELM은 두 가지 변형을 제공한다: HELM Classic은 전체 16개 시나리오 x 7개 렌즈를 실행하며, HELM Lite는 핵심 42개 조합(6개 시나리오 x 7개 렌즈)만 실행하여 비용과 시간을 줄인다. HELM Lite의 상관관계 분석 결과, 42개 조합이 112개 조합과 0.97 이상의 순위 상관관계(Spearman)를 보임이 확인되었다.

9.3.2 lm-eval-harness — 확장성 중심 평가 파이프라인

lm-eval-harness는 "LLM 평가의 만능 도구상"을 표방한다. 핵심 설계 원칙은 태스크(Task) - 모델(Model) - 메트릭(Metric)의 명확한 분리다. 태스크는 YAML로 정의하고, 모델은 플러그인 방식으로 교체하며, 메트릭은 태스크에 종속적으로 계산된다.

# lm-eval-harness 태스크 정의 예시
task: mmlu_abstract_algebra
dataset_path: cais/mmlu
dataset_name: abstract_algebra
output_type: multiple_choice
doc_to_text: "{{question.strip()}}\nA. {{choices[0]}}\nB. {{choices[1]}}"
doc_to_target: answer
metric_list:
  - metric: acc
    aggregation: mean
    higher_is_better: true
metadata:
  version: 2.0
  num_fewshot: 5

이 구조의 장점은 새로운 태스크를 추가하려면 YAML 파일 하나만 만들면 된다는 것이다. Python 코드를 작성할 필요가 없다(커스텀 로직이 필요한 경우 Python 클래스도 지원). 2024년 말 기준 200개 이상의 태스크가 등록되어 있어 단일 프레임워크로 가장 넓은 벤치마크 커버리지를 제공한다.

lm-eval-harness의 아키텍처는 세 가지 핵심 컴포넌트로 구성된다:

1. Task: 평가할 태스크의 데이터셋, 프롬프트 템플릿, 메트릭을 정의. YAML 또는 Python 클래스로 구현
2. Model: 평가 대상 모델. HuggingFace Transformers, OpenAI API, Anthropic API, vLLM, llama.cpp 등 다양한 백엔드 지원
3. Metric: 평가 메트릭. exact_match, F1, perplexity, BERTScore 등 기본 제공 + 커스텀 정의 가능

v0.4 아키텍처 혁신

2024년에 출시된 v0.4는 내부 아키텍처를 완전히 재설계했다. 주요 변화는 (1) YAML 기반 태스크 정의 표준화, (2) 모델 백엔드 추상화 개선, (3) 병렬 처리 지원, (4) 출력 형식 표준화(JSON)다. 이 변화로 200+ 태스크의 품질 관리가 용이해졌고, CI/CD 파이프라인과의 통합이 간편해졌다.

MMLU, HumanEval, GSM8K — lm-eval-harness의 핵심 태스크

lm-eval-harness에서 가장 널리 사용되는 세 가지 태스크를 분석한다:

MMLU (Massive Multitask Language Understanding): 57개 주제, 15,908개 질문으로 구성된 다지선택 벤치마크. 5-shot 설정으로 평가하며, 주제별로 난이도가 크게 다르다. 전문 영역(법학, 의학)은 일반 영역(상식)보다 현저히 낮은 점수를 보인다. 이 분산(variance)은 "평균 점수"만으로 모델의 실제 능력을 파악하기 어렵다는 것을 보여준다.

HumanEval: 164개 Python 함수 작성 문제. pass@k 메트릭을 사용하며, $k$개의 샘플 중 하나라도 통과하면 성공으로 간주한다.

GSM8K: 8,500개 초등/중등 수학 문제. CoT(Chain-of-Thought) 추론 능력을 평가하며, 에이전트 시스템의 "다단계 추론" 능력과 간접적으로 관련이 있다. GSM8K 점수가 높은 모델이 반드시 에이전트로서 잘 동작하는 것은 아니지만, 다단계 추론 능력의 하한선(lower bound)으로는 유용하다.

lm-eval-harness를 에이전트 평가로 확장: 가능한가?

lm-eval-harness의 태스크-모델-메트릭 분리 구조는 이론적으로 에이전트 평가로 확장 가능하다. 하지만 실제로 시도해보면 세 가지 근본적 한계에 직면한다:

이 한계를 극복하기 위한 두 가지 접근이 있다:

접근 A: 래퍼(Wrapper) 패턴 — lm-eval-harness를 그대로 사용하되, 에이전트 환경을 "모델 백엔드"로 감싼다. 즉, lm-eval-harness → Model → AgentEnv → LLM의 형태로, AgentEnv가 다단계 상호작용을 관리한다. 이 방법은 확장성이 좋지만, 에이전트의 행동 궤적(trajectory)을 평가할 수 없다. 최종 결과만 평가된다.

접근 B: 커스텀 Task 클래스 — lm-eval-harness의 Python 기반 커스텀 Task 클래스를 활용하여 다단계 에이전트 평가를 구현한다. generate_requests()에서 다단계 상호작용을 처리하고, process_results()에서 궤적 품질을 평가한다. 이 방법은 유연하지만, lm-eval-harness의 핵심 장점인 "간단한 YAML 정의"를 잃게 된다.

"""lm-eval-harness 커스텀 에이전트 태스크 (접근 B)"""
from lm_eval.api.task import Task
from typing import Any

class AgentWebTask(Task):
    """WebArena 스타일 에이전트 태스크를 lm-eval-harness에서 실행"""
    
    DATASET_PATH = "custom/agent-web-tasks"
    
    def doc_to_target(self, doc: dict) -> str:
        return doc["goal_state"]  # 목표 상태 JSON
    
    def has_training_docs(self) -> bool:
        return False
    
    def doc_to_text(self, doc: dict) -> str:
        return f"""당신은 웹 브라우저를 조작하는 에이전트입니다.
현재 URL: {doc['start_url']}
목표: {doc['intent']}
가능한 행동: click, type, scroll, goto, back

이전 행동들:
{self._format_history(doc)}

다음 행동을 선택하세요:"""
    
    def process_results(self, doc: dict, results: list) -> dict:
        """에이전트 궤적 평가"""
        trajectory = results[0]  # 전체 행동 기록
        goal_state = eval(doc["goal_state"])
        
        # 최종 상태 평가
        final_match = self._compare_states(
            trajectory[-1]["state"], goal_state
        )
        
        # 궤적 효율성 평가
        optimal_steps = doc.get("optimal_steps", 10)
        actual_steps = len(trajectory)
        efficiency = min(1.0, optimal_steps / actual_steps)
        
        return {
            "success": float(final_match),
            "efficiency": efficiency,
            "steps": actual_steps,
        }

    def aggregation(self):
        return {
            "success": lambda x: sum(x) / len(x),
            "efficiency": lambda x: sum(x) / len(x),
        }

    def higher_is_better(self):
        return {"success": True, "efficiency": True}

9.3.3 WebArena — 실제 웹 환경 벤치마크

WebArena는 에이전트 벤치마크의 현실성(realism)을 한 단계 끌어올렸다. 실제 웹사이트를 그대로 복제하여 Docker 컨테이너로 배포한다. 이전 세대(MiniWoB++, WebShop)가 단순화된 환경을 사용한 것과 대비된다.

각 태스크는 시작 URL + 의도(intent) + 성공 기준으로 정의된다. 채점은 최종 상태(final state) 비교 방식을 사용한다. 에이전트의 행동 과정(trajectory)이 아닌 최종 도달 상태가 목표 상태와 일치하는지를 확인한다.

WebArena vs MiniWoB++ vs WebShop: 환경 복잡도 비교

WebArena의 혁신을 이해하려면 이전 세대 벤치마크와 비교해야 한다:

DOM 크기가 ~2,000개 노드로 증가한 것은 에이전트가 관련 요소를 찾기 위해 상당한 탐색 능력이 필요함을 의미한다. MiniWoB++에서 95%를 달성한 에이전트가 WebArena에서는 36%로 떨어지는 것은 환경 복잡도가 평가 결과에 결정적 영향을 미친다는 증거다.

WebArena의 한계: 최종 상태 평가의 맹점

WebArena의 "최종 상태 비교" 방식은 간단하고 재현 가능하지만, 중요한 정보를 놓친다:

"잘못된 경로 + 우연히 목표 달성"은 WebArena에서 10~15%의 태스크에서 발생하는 것으로 추정된다. 예를 들어, 에이전트가 무작위로 버튼을 클릭하다가 우연히 정답 페이지에 도달하는 경우다. 이것은 과정 평가(Process Evaluation)가 필요한 이유다: 단순히 "도착했는가?"가 아니라 "어떻게 도착했는가?"를 평가해야 한다.

WebArena의 액션 공간(Action Space)

WebArena는 세 가지 액션 유형을 지원한다:

1. 좌표 기반(Coordinate-based): 화면의 (x, y) 좌표를 클릭. 가장 일반적이지만 정밀도가 낮음
2. 요소 기반(Element-based): CSS 선택자나 XPath로 특정 요소를 지정. 정밀하지만 DOM 이해 필요
3. 텍스트 기반(Text-based): 링크 텍스트나 버튼 텍스트를 입력. 사용자 친화적이지만 동적 텍스트에 취약

에이전트의 액션 공간 선택은 성능에 큰 영향을 미친다. GPT-4 + 요소 기반 액션이 좌표 기반보다 약 5~8%p 높은 성능을 보이며, 이는 에이전트가 DOM 구조를 이해할수록 더 나은 행동을 취한다는 증거다.

WebArena가 에이전트 평가에 미친 영향: 3가지 패러다임 전환

WebArena의 등장은 에이전트 평가 분야에 세 가지 패러다임 전환을 가져왔다:

1. 합성에서 실제로(Synthetic → Real): MiniWoB++의 합성 환경에서 실제 서비스 복제로의 전환은 "통제된 환경에서 잘 동작하는 에이전트가 실제 환경에서도 잘 동작하는가?"라는 질문에 부정적으로 답했다. 환경의 현실성이 평가의 타당성을 결정한다.
2. 단일에서 멀티도메인으로(Single → Multi-domain): WebShop(쇼핑)이나 MiniWoB++(간단한 웹)이 단일 도메인을 다룬 반면, WebArena는 쇼핑, 포럼, GitLab, 지도, 관리자 도구 등 5개 도메인을 아우른다. 에이전트의 일반화 능력을 평가하려면 다양한 도메인이 필요하다.
3. 관찰에서 상호작용으로(Observation → Interaction): 기존 QA 벤치마크가 "관찰(텍스트 읽기)"을 평가했다면, WebArena는 "상호작용(클릭, 입력, 탐색)"을 평가한다. 이것은 평가 메트릭 자체의 변화를 요구한다: 정확도에서 행동 적절성으로.

이 세 가지 전환은 6차원 프레임워크 설계에 직접 반영된다: D1(태스크 완료)은 상호작용 평가를, D3(견고성)은 멀티도메인 일반화를, D2(과정 품질)은 행동 적절성을 각각 담당한다.

9.3.4 SWE-bench — 실제 소프트웨어 엔지니어링 평가

SWE-bench는 "이것은 코딩 테스트가 아니다. 실제 소프트웨어 엔지니어링이다."라는 문장으로 요약된다. HumanEval이나 MBPP가 단일 함수 단위의 짧은 문제를 다룬다면, SWE-bench는 전체 리포지토리에서 실제 GitHub 이슈를 해결하는 능력을 평가한다.

SWE-bench 태스크 생성 파이프라인

1. 이슈 수집: 12개 인기 Python 프로젝트(django, scikit-learn, flask, matplotlib, sympy, requests 등)에서 해결된 PR 추출
2. 그라운드 트루스: PR의 diff(변경 내용)와 통과한 테스트 식별
3. 태스크 구성: 이슈 제목+본문 + 리포지토리 스냅샷(PR 이전 커밋)
4. 평가: 에이전트가 생성한 패치를 적용하고 테스트 스위트 실행

SWE-bench Verified가 가장 신뢰할 수 있는 변형이다. 인간 전문가가 각 이슈를 검토하여 이슈 설명만으로 해결 가능한지, 테스트가 적절한지, 난이도가 합리적인지를 확인했다.

난이도 분포와 에이전트 능력 분석

SWE-bench의 난이도 분포를 살펴보면 에이전트 평가의 현실을 알 수 있다:

난이도 분류 기준은 세 가지다: (1) 수정해야 하는 파일 수(1개=easy, 2-3개=medium, 4+=hard), (2) 이슈 설명의 명확성(구체적=easy, 모호=hard), (3) 기존 테스트 커버리지(높음=easy, 낮음=hard). 이 분류는 6차원 프레임워크의 "태스크 난이도" 차원과 직접 연결된다.

SWE-agent: SWE-bench 최적화 에이전트

Princeton NLP는 SWE-bench와 함께 SWE-agent를 개발했다. SWE-agent의 핵심 설계는 에이전트-컴퓨터 인터페이스(ACI)의 최적화다. 기존 에이전트가 단순히 터미널 명령을 실행하는 것과 달리, SWE-agent는 코드 검색, 파일 탐색, 편집에 특화된 커스텀 명령을 제공한다.

# SWE-agent의 커스텀 ACI 명령 예시
# 기존: 에이전트가 임의의 셸 명령 사용
# SWE-agent: 최적화된 명령 세트

# 1. 파일 탐색 (find 대신)
search_dir "pattern"  # 리포 내 패턴 검색

# 2. 코드 검색 (grep 대신)
search_file "pattern" file.py  # 특정 파일 내 검색

# 3. 파일 편집 (sed 대신)
edit_file file.py "old_string" "new_string"

# 4. 컨텍스트 제공
open_file file.py 50  # 50번째 줄 주변 컨텍스트 표시

ACI 최적화의 결과는 인상적이다. SWE-agent + GPT-4는 일반 에이전트 + GPT-4보다 SWE-bench Verified에서 약 8~12%p 높은 해결률을 보인다. 이것은 "에이전트가 무엇을 할 수 있는가"뿐 아니라 "에이전트에게 무엇을 제공하는가"가 평가 결과에 결정적 영향을 미친다는 증거다.

SWE-bench가 알려주는 설계 원칙: ACI가 곧 평가 기준

SWE-agent의 성공은 중요한 함의를 갖는다. 에이전트의 인터페이스(ACI)가 성능을 결정하고, 따라서 ACI 설계가 평가의 일부가 되어야 한다. 같은 LLM이라도 기본 터미널 인터페이스에서는 20% 해결률, SWE-agent ACI에서는 33% 해결률을 보인다. 이 13%p의 차이는 모델 능력이 아니라 인터페이스 설계에서 온다.

이 원칙은 우리의 6차원 프레임워크에도 적용된다. D1(태스크 완료)을 평가할 때, 에이전트에게 제공된 인터페이스의 품질을 보정해야 한다. "풍부한 인터페이스 + 80% 성공"과 "제한된 인터페이스 + 80% 성공"은 같은 80%라도 의미가 다르다. 후자가 더 높은 에이전트 능력을 시사한다.

SWE-bench의 거짓 양성 문제: False Positive 심층 분석

SWE-bench의 "테스트 통과 = 성공" 평가 방식에는 숨겨진 위험이 있다. 올바르지 않은 패치가 기존 테스트를 통과하는 거짓 양성(false positive) 현상이다. 이 문제는 세 가지 유형으로 나뉜다:

이 문제를 해결하기 위해 SWE-bench Verified 변형이 도입되었다. 인간 전문가가 각 이슈의 테스트가 적절한지, 패치가 올바른지만 검증하는 것이 아니라 패치의 의도(intention)까지 검토한다. 하지만 인간 검증은 비용이 많이 들고 확장성이 제한된다.

"""SWE-bench 거짓 양성 탐지기"""
import subprocess
import ast

class SWEBenchFPDetector:
    """생성된 패치의 거짓 양성 여부를 사후 검증"""
    
    def check_patch_quality(self, patch_diff: str, issue_desc: str) -> dict:
        """패치 품질 다차원 검증"""
        return {
            "covers_issue": self._check_issue_coverage(patch_diff, issue_desc),
            "no_bypass": self._check_no_bypass(patch_diff),
            "no_side_effects": self._check_side_effects(patch_diff),
            "changes_minimal": self._check_minimality(patch_diff),
        }
    
    def _check_no_bypass(self, diff: str) -> bool:
        """우회 패치 탐지: bare except, pass, 주석 처리 등"""
        bypass_patterns = [
            "except:",          # bare except
            "except Exception",  # too broad
            "pass\n",           # empty handler
            "# TODO",           # placeholder
            "import warnings\nwarnings.filterwarnings",
        ]
        for pattern in bypass_patterns:
            if pattern in diff:
                return False
        return True
    
    def _check_minimality(self, diff: str) -> bool:
        """최소 변경 원칙: 불필요한 대규모 리팩토링 감지"""
        added_lines = sum(1 for l in diff.split('\n') if l.startswith('+'))
        removed_lines = sum(1 for l in diff.split('\n') if l.startswith('-'))
        # 50줄 이상 변경은 리팩토링일 가능성
        return (added_lines + removed_lines) < 50
    
    def _check_issue_coverage(self, diff: str, issue: str) -> bool:
        """이슈에서 언급된 키워드가 패치에 반영되었는지"""
        issue_keywords = set(issue.lower().split()) & {
            "error", "bug", "fix", "crash", "fail", "wrong",
            "missing", "null", "empty", "duplicate"
        }
        diff_lower = diff.lower()
        covered = sum(1 for kw in issue_keywords if kw in diff_lower)
        return covered >= len(issue_keywords) * 0.5  # 최소 50% 커버

# 사용 예
detector = SWEBenchFPDetector()
result = detector.check_patch_quality(patch_diff, issue_description)
if not all(result.values()):
    print("WARNING: Potential false positive detected!")
    for check, passed in result.items():
        if not passed:
            print(f"  - {check}: FAILED")

9.3.5 RAGAS — Reference-Free RAG 평가

RAGAS는 정답 없이(reference-free) RAG 시스템을 평가하는 혁신적 프레임워크다. 4가지 핵심 메트릭을 제공하며, 각 메트릭은 LLM-as-Judge 방식으로 작동한다.

RAGAS 평가 파이프라인 상세

RAGAS의 Faithfulness 계산은 세 단계로 이루어진다:

1. Claim 추출: LLM이 답변을 개별 claim으로 분해. 예: "서울은 한국의 수도이며 1천만 명이 삽니다" → ["서울은 한국의 수도이다", "서울의 인구는 1천만 명이다"]
2. 귀속 판정: 각 claim이 컨텍스트 문장에 귀속(attributable)되는지 LLM이 판정
3. 집계: 귀속된 claim의 비율이 Faithfulness 점수

이 파이프라인의 핵심 가정은 "LLM이 claim 귀속을 정확히 판정할 수 있다"는 것이다. 하지만 LLM-as-Judge의 한계가 여기에도 적용된다: 판정관 LLM이 충분히 강력하지 않으면 오판정이 발생하고, 판정관 LLM이 평가 대상 LLM과 같은 모델이면 편향(bias)이 발생할 수 있다.

RAGAS v0.2+ 확장 메트릭

2024년에 RAGAS는 추가 메트릭을 도입했다:

• Summarization Score: 요약 품질 평가 (RAG 파이프라인에 요약 단계가 있는 경우)
• Simple Criteria Scoring: 사용자 정의 기준으로 평가 (예: "이 답변이 전문적인 톤인가?")
• Multi-modal Faithfulness: 이미지/테이블 컨텍스트에 대한 충실성
• Aspect Critique: 답변의 특정 측면(해로움, 악의성, 혐오성 등) 평가

from ragas import evaluate
from ragas.metrics import (
    faithfulness, answer_relevancy,
    context_precision, context_recall
)
from datasets import Dataset

eval_data = {
    "question": [
        "한국의 수도는 어디인가?",
        "Transformer의 핵심은?",
    ],
    "answer": [
        "한국의 수도는 서울입니다.",
        "Self-Attention 메커니즘입니다.",
    ],
    "contexts": [
        ["서울은 대한민국의 수도입니다."],
        ["Self-Attention은 Q, K, V 행렬을 사용합니다."],
    ],
}

dataset = Dataset.from_dict(eval_data)
results = evaluate(
    dataset=dataset,
    metrics=[faithfulness, answer_relevancy,
             context_precision, context_recall],
    llm=your_llm,
    embeddings=your_emb,
)
print(results)
# {'faithfulness': 0.92, 'answer_relevancy': 0.88,
#  'context_precision': 0.95, 'context_recall': 0.85}

RAGAS 심층 분석: Faithfulness의 내부 메커니즘

RAGAS의 가장 혁신적 메트릭인 Faithfulness를 깊이 파고들면, "LLM이 환각을 얼마나 잘 감지하는가?"라는 근본적 질문과 마주하게 된다. Faithfulness 계산 파이프라인을 수식으로 정밀하게 모델링하면 다음과 같다:

이 모델의 약점을 구체적으로 분석해보자:

Faithfulness의 3가지 실패 모드

RAGAS 기반 에이전트 RAG 평가: 실전 코드

# 에이전트 RAG 파이프라인 + RAGAS 평가 통합
from ragas import evaluate
from ragas.metrics import faithfulness, answer_relevancy
from ragas.metrics._answer import AnswerRelevancy
from datasets import Dataset
import numpy as np

class AgentRAGEvaluator:
    """에이전트의 RAG 단계를 독립적으로 평가"""
    
    def __init__(self, judge_llm, embeddings):
        self.judge = judge_llm
        self.embeddings = embeddings
    
    def evaluate_agent_session(self, session_logs):
        """세션 로그에서 RAG 관련 단계만 추출하여 평가"""
        rag_steps = [s for s in session_logs 
                     if s["type"] == "retrieval"]
        
        eval_data = {
            "question": [s["query"] for s in rag_steps],
            "answer": [s["generated"] for s in rag_steps],
            "contexts": [s["retrieved_docs"] for s in rag_steps],
        }
        dataset = Dataset.from_dict(eval_data)
        
        results = evaluate(
            dataset=dataset,
            metrics=[faithfulness, answer_relevancy],
            llm=self.judge,
            embeddings=self.embeddings,
        )
        
        # 세션 수준 집계
        return {
            "per_step": results,
            "avg_faithfulness": np.mean(results["faithfulness"]),
            "degradation_steps": self._find_degradation(results),
        }
    
    def _find_degradation(self, results):
        """Faithfulness가 임계값 이하인 단계 식별"""
        threshold = 0.7
        return [i for i, f in enumerate(results["faithfulness"]) 
                if f < threshold]

이 코드는 에이전트의 전체 세션 중 RAG 관련 단계만 추출하여 RAGAS로 평가하는 패턴을 보여준다. 핵심은 에이전트 평가와 RAG 평가의 분리: RAGAS는 RAG 파이프라인 품질만 평가하고, 나머지(도구 사용, 의사결정, 협업)는 다른 메트릭이 담당한다. 이것이 다차원 평가의 핵심 원칙이다.

9.3.6 AutoGen Eval — 멀티 에이전트 대화 평가

AutoGen Eval은 AutoGen 프레임워크에 내장된 평가 기능이다. 두 가지 수준의 평가를 제공한다: (1) 태스크 수준 — 에이전트가 태스크를 완료했는지, (2) 대화 수준 — 대화가 효율적이었는지.

핵심은 커스텀 평가 함수를 AutoGen의 대화 루프에 주입할 수 있다는 점이다. AutoGen이 "평가를 위한 프레임워크"가 아니라 "평가를 포함하는 프레임워크"라는 설계 철학을 보여준다.

AutoGen Eval의 혁신: "대화 토폴로지" 패러다임

AutoGen Eval이 기존 평가와 다른 점은 대화를 그래프(graph)로 모델링한다는 것이다. 에이전트 간의 메시지 교환을 노드(발신자/수신자)와 엣지(메시지)로 표현하여, 네트워크 분석 기법을 적용한다. 이것은 "결과만 평가"하는 WebArena나 "정적 텍스트만 평가"하는 HELM과 근본적으로 다른 접근이다.

이 메트릭은 단순하지만 강력하다. 실제 AutoGen GroupChat 세션을 분석해보면, 종종 한 에이전트가 전체 메시지의 80% 이상을 차지하는 "독점적 대화"가 발생한다. 이것은 협업 실패의 강력한 예측 변수다: 대화 엔트로피가 0.3 이하인 세션의 태스크 완료율은 0.7 이상인 세션보다 평균 25%p 낮다.

import autogen

def custom_evaluator(messages):
    """AutoGen 대화 커스텀 평가"""
    results = {}

    # 1. 태스크 완료율
    last_msg = messages[-1]["content"] if messages else ""
    results["task_completed"] = 1.0 if "TERMINATE" in last_msg else 0.0

    # 2. 대화 효율성
    n_messages = len(messages)
    results["efficiency"] = max(0, 1.0 - (n_messages - 3) / 20)

    # 3. 참여 균형 (멀티 에이전트)
    sender_counts = {}
    for m in messages:
        sender = m.get("name", "unknown")
        sender_counts[sender] = sender_counts.get(sender, 0) + 1

    if len(sender_counts) > 1:
        counts = list(sender_counts.values())
        mean_c = sum(counts) / len(counts)
        std_c = (sum((c - mean_c)**2 for c in counts) / len(counts)) ** 0.5
        results["balance"] = max(0, 1 - std_c / mean_c)
    else:
        results["balance"] = 1.0

    # 4. 정보 밀도
    avg_len = sum(len(m["content"]) for m in messages) / max(n_messages, 1)
    results["info_density"] = min(1.0, avg_len / 500)

    return results

AutoGen GroupChat 평가 패턴

AutoGen Eval은 세 가지 평가 패턴을 지원한다:

1. Human-in-the-loop: 대화 종료 후 인간이 결과를 평가. 가장 신뢰성이 높지만 확장성이 낮다
2. LLM-as-Judge: 다른 LLM이 대화 내용을 평가. 확장성은 높지만 LLM 판정의 불확실성이 있다
3. Programmatic: 위 코드처럼 커스텀 함수로 자동 평가. 일관성이 높지만 평가 차원이 제한적이다

실무에서는 세 패턴을 조합하여 사용한다. CI/CD에서는 Programmatic으로 빠르게 필터링하고, 중요한 변경에서는 Human-in-the-loop으로 최종 확인한다.

AutoGen Eval 심층: GroupChat 대화 패턴 분석

AutoGen Eval의 가장 독특한 기능은 GroupChat 대화의 구조적 패턴을 분석하는 것이다. 2024년 Microsoft Research의 내부 연구에 따르면, GroupChat의 성공/실패를 예측하는 가장 강력한 지표는 "대화 그래프의 엔트로피"다:

이 발견은 직관과 일치한다: 한 에이전트가 모든 발화를 독점하면, 다른 에이전트의 전문성이 활용되지 않는다. 반면, 발화가 너무 분산되면(모든 에이전트가 동등하게 발화) 합의에 이르지 못할 수 있다. 최적점은 $H \approx 1.5 \sim 2.0$ 사이에 존재한다.

# GroupChat 대화 그래프 분석기
import networkx as nx
import numpy as np
from collections import Counter

def analyze_conversation_graph(messages):
    """AutoGen GroupChat 대화의 구조 분석"""
    G = nx.DiGraph()
    
    for i, msg in enumerate(messages):
        sender = msg.get("name", "unknown")
        # 다음 메시지의 수신자 추론 (AutoGen은 명시적 수신자가 없음)
        if i + 1 < len(messages):
            receiver = messages[i+1].get("name", "unknown")
            if sender != receiver:
                G.add_edge(sender, receiver)
    
    # 엔트로피 계산
    out_degrees = dict(G.out_degree())
    total = sum(out_degrees.values()) or 1
    probs = [d / total for d in out_degrees.values()]
    entropy = -sum(p * np.log2(p) for p in probs if p > 0)
    
    # 중심성 분석
    centrality = nx.betweenness_centrality(G)
    
    return {
        "entropy": entropy,
        "is_balanced": 1.5 <= entropy <= 2.0,
        "centrality": centrality,
        "dominant_agent": max(centrality, key=centrality.get),
        "n_components": nx.number_weakly_connected_components(G),
    }

9.3.7 CrewAI Eval — 크루 단위 평가

CrewAI는 "역할 기반(role-based)" 멀티 에이전트 프레임워크다. 각 에이전트가 명확한 역할을 가지고 태스크를 순차적/병렬로 수행하는 "크루(Crew)"를 구성한다.

from crewai import Agent, Task, Crew, Process

researcher = Agent(
    role="Senior Research Analyst",
    goal="Research AI evaluation frameworks",
    backstory="10년 경력의 AI 연구 분석가",
)

writer = Agent(
    role="Technical Writer",
    goal="Write comprehensive analysis report",
    backstory="기술 문서 작성 전문가",
)

research_task = Task(
    description="에이전트 평가 프레임워크 5개를 조사",
    expected_output="비교 분석 보고서",
    agent=researcher,
)

writing_task = Task(
    description="조사 결과를 기반으로 기술 보고서 작성",
    expected_output="구조화된 보고서 (10페이지 이상)",
    agent=writer,
)

crew = Crew(
    agents=[researcher, writer],
    tasks=[research_task, writing_task],
    process=Process.sequential,
)

result = crew.kickoff()
print(f"Total tokens: {crew.usage_metrics.total_tokens}")
print(f"Total cost: ${crew.usage_metrics.total_cost:.4f}")

CrewAI Eval의 가장 큰 한계는 협업 품질 메트릭의 부재다. 태스크가 성공했는지, 비용이 얼마인지는 측정하지만, 에이전트 간 통신이 효율적이었는지, 역할 분배가 균형적이었는지는 평가하지 않는다.

CrewAI 평가 파이프라인의 내부 구조

CrewAI의 평가는 세 가지 레벨에서 이루어진다:

# CrewAI 커스텀 평가 파이프라인
from crewai import Agent, Task, Crew, Process
from crewai.evaluators import CrewEvaluator

class CustomCrewEvaluator(CrewEvaluator):
    """크루 평가에 협업 품질 메트릭을 추가하는 커스텀 평가자"""
    
    def evaluate_task_output(self, task: Task, output: str) -> dict:
        """태스크 산출물 평가"""
        return {
            "quality_score": self._llm_judge_score(output, task.expected_output),
            "token_usage": task.output_tokens,
            "latency_ms": task.execution_time_ms,
        }
    
    def evaluate_agent_contribution(self, agent: Agent, tasks: list) -> dict:
        """에이전트 기여도 평가"""
        total_tokens = sum(t.output_tokens for t in tasks)
        return {
            "agent_role": agent.role,
            "tasks_completed": len(tasks),
            "total_tokens": total_tokens,
            "avg_quality": sum(t.quality_score for t in tasks) / len(tasks),
        }
    
    def evaluate_crew_dynamics(self, crew: Crew, results: list) -> dict:
        """크루 역학 평가 — 기존 CrewAI에 없는 협업 메트릭"""
        # 역할 분배 균형도
        token_per_agent = {}
        for r in results:
            role = r["agent_role"]
            token_per_agent[role] = token_per_agent.get(role, 0) + r["total_tokens"]
        
        total = sum(token_per_agent.values())
        balance = 1.0 - (max(token_per_agent.values()) / total) if total > 0 else 0
        
        return {
            "role_balance_index": balance,  # 0=편중, 1=완전균형
            "total_cost_usd": crew.usage_metrics.total_cost,
            "total_time_sec": crew.execution_time,
            "task_success_rate": sum(1 for r in results if r["quality_score"] > 0.7) / len(results),
        }

# 평가 실행
evaluator = CustomCrewEvaluator()
crew_result = crew.kickoff()
evaluation = evaluator.evaluate_crew_dynamics(crew, crew_result)
print(f"역할 균형도: {evaluation['role_balance_index']:.2f}")
print(f"태스크 성공률: {evaluation['task_success_rate']:.1%}")

CrewAI Eval의 근본적 한계: "역할 적합성"의 측정 불가

CrewAI의 핵심 개념은 "역할 기반 에이전트"다. 각 에이전트에게 role, goal, backstory를 부여하여 인간 조직의 역할 분담을 모방한다. 하지만 평가 측면에서 "이 에이전트가 이 역할에 적합한가?"라는 질문에 답할 수 없다.

예를 들어, "Senior Research Analyst" 역할을 가진 에이전트가 실제로는 리서치 능력보다 요약 능력에서 뛰어날 수 있다. 이때 CrewAI Eval은 태스크 성공 여부만 판단하지, 역할 재배정(role reassignment)의 필요성은 감지하지 못한다. 이것은 역할 적합성(role fitness)이라는 새로운 메트릭의 필요성을 시사한다.

9.3.8 AgenticBench — 비용/품질 트레이드오프

AgenticBench는 평가 도구라기보다 의사결정 지원 도구다. 에이전트 시스템의 비용, 지연, 품질 트레이드오프를 정량화하여 실무자가 배포 구성을 결정하도록 돕는다.

ROI(투자 대비 수익) 분석 프레임워크

AgenticBench의 핵심 질문: "에이전트 시스템을 도입했을 때 실제로 비용이 절감되는가?"

AgenticBench 실증 분석: 태스크별 ROI 비교

AgenticBench를 이용하여 5가지 태스크 카테고리에서 에이전트와 인간의 비용-품질을 비교했다:

핵심 발견: ROI와 품질은 비례하지 않는다. 문서 요약은 ROI 25.7에 품질 91%로 거의 인간 수준이지만, 법률 검토는 ROI 10.1에도 품질이 65%에 불과하다. 이는 "비용 절감"과 "품질 보증"이 독립적인 의사결정 축임을 시사한다.

AgenticBench의 한계와 개선 방향

AgenticBench는 비용 분석에 탁월하지만, 다음 한계가 있다:

• 품질 측정의 단순성: 현재 "성공/실패" 이분법만 사용. 부분적 성공, 품질 등급을 구분하지 못한다.
• 멀티 에이전트 비용 모델 미비: $N$개 에이전트 간 통신 비용이 모델에 포함되어 있지만, 실제 측정 데이터가 부족하다.
• 시간적 비용 누락: "지연 시간(latency)"이 비용에 포함되지 않는다. 실시간 서비스에서는 지연이 핵심 비용 요소다.

AgenticBench 확장: 숨겨진 비용 모델링

AgenticBench의 비용 모델은 토큰 비용과 인프라 비용만 고려한다. 하지만 실제 에이전트 시스템에는 숨겨진 비용(hidden costs)이 존재한다:

사례 연구: 고객 지원 챗봇의 TCO 분석

AgenticBench의 ROI 모델을 확장하여, 실제 고객 지원 챗봇 시나리오에서 TCO를 분석했다:

단순 ROI는 $45,000 / $5,800 - 1 = 6.76로 매우 높다. 하지만 숨겨진 비용까지 포함하면 $5,800이 된다. 다행히 이 시나리오에서는 숨겨진 비용이 이미 기본 비용에 포함되어 있어 ROI가 유지된다. 오류율이 20%를 넘으면 TCO가 급증하므로, 품질 임계치 관리가 비용 관리의 핵심이다.

"""AgenticBench 확장 TCO 계산기"""
from dataclasses import dataclass

@dataclass
class AgentTCOConfig:
    monthly_volume: int = 100_000        # 월 처리 건수
    cost_per_interaction: float = 0.024  # API 비용/건
    infra_monthly: float = 500.0         # 인프라 비용
    escalation_rate: float = 0.15        # 에스컬레이션율
    escalation_cost: float = 8.0         # 에스컬레이션시 인간 비용
    error_rate: float = 0.05             # 오류율
    error_fix_cost: float = 16.0         # 오류 수정 비용
    avg_delay_over_sla: float = 3.0      # 평균 SLA 초과(초)
    delay_cost_per_sec: float = 0.01     # 지연당 비용
    
def calculate_tco(cfg: AgentTCOConfig) -> dict:
    token_cost = cfg.monthly_volume * cfg.cost_per_interaction
    escalation = cfg.monthly_volume * cfg.escalation_rate * cfg.escalation_cost
    error_fix = cfg.monthly_volume * cfg.error_rate * cfg.error_fix_cost
    delay = cfg.monthly_volume * cfg.avg_delay_over_sla * cfg.delay_cost_per_sec
    
    visible = token_cost + cfg.infra_monthly + escalation
    hidden = error_fix + delay
    total = visible + hidden
    
    return {
        "visible_cost": visible,
        "hidden_cost": hidden,
        "total_tco": total,
        "hidden_ratio": hidden / total,
        "break_even_error_rate": (total * 0.3) / (cfg.monthly_volume * cfg.error_fix_cost),
    }

result = calculate_tco(AgentTCOConfig())
print(f"가시적 비용: ${result['visible_cost']:,.0f}")
print(f"숨겨진 비용: ${result['hidden_cost']:,.0f}")
print(f"TCO: ${result['total_tco']:,.0f}")
print(f"숨겨진 비용 비율: {result['hidden_ratio']:.1%}")
print(f"허용 최대 오류율(30% 임계): {result['break_even_error_rate']:.1%}")

9.3.9 LangSmith — 트레이스 기반 관측/평가

LangSmith는 LangChain 생태계의 관측 플랫폼이다. LLM 호출, 체인 실행, 에이전트 행동을 추적(tracing)하는 것이 주 기능이며, 평가는 부가 기능이다.

from langsmith import Client
from langsmith.evaluation import evaluate

client = Client()

# 데이터셋 생성
dataset = client.create_dataset("agent-eval-v1")
client.create_examples(
    dataset_id=dataset.id,
    inputs=[{"query": "서울 내일 날씨?"}],
    outputs=[{"expected": "서울 날씨 정보"}],
)

# LLM-as-Judge 평가자
def qa_evaluator(run, example):
    return {"score": 8, "reasoning": "의미적으로 일치"}

results = evaluate(
    target=my_agent_function,
    data=dataset.name,
    evaluators=[qa_evaluator],
)

LangSmith의 진정한 강점은 트레이싱에 있다. 에이전트의 각 단계를 시각적으로 보여주어 "에이전트가 왜 이 결정을 내렸는가?"를 이해할 수 있게 한다. 하지만 트레이싱은 "무슨 일이 일어났는가"를 보여줄 뿐, "그것이 좋은가"는 평가자가 결정해야 한다.

LangSmith vs 오픈소스 대안 비교

LangSmith의 상용 모델은 오픈소스 생태계와의 비교를 필연적으로 만든다:

LangSmith를 넘어서: 평가 중심 관측의 필요성

2024년의 관측 플랫폼은 "관측 후 평가" 패러다임을 따른다: 먼저 실행을 추적하고, 나중에 평가자를 붙인다. 하지만 "평가 중심 관측(Evaluation-First Observability)" 패러다임이 필요하다: 실행 전에 평가 기준을 정의하고, 각 단계에서 실시간으로 평가 지표를 수집한다. 이것이 12장에서 설계할 자동화 파이프라인의 핵심 원칙이다.

# 평가 중심 관측의 프로토타입 패턴
class EvalFirstTracer:
    """실행 전 평가 기준 정의 → 실행 중 실시간 메트릭 수집"""
    
    def __init__(self, eval_criteria: dict):
        self.criteria = eval_criteria
        self.metrics = []
    
    def trace_step(self, step_name, input_data, output_data):
        """각 단계에서 실시간 평가 메트릭 수집"""
        step_metrics = {}
        for criterion, evaluator in self.criteria.items():
            score = evaluator(input_data, output_data)
            step_metrics[criterion] = score
        self.metrics.append({
            "step": step_name,
            "metrics": step_metrics,
            "timestamp": time.time()
        })
        return step_metrics

9.4 메가 비교 분석: 13개 프레임워크의 종합 비교

9개 프레임워크의 심층 분석을 마친 후, 이제 전체 13개 프레임워크를 12개 속성으로 종합 비교한다. 이 비교는 "어떤 프레임워크가 가장 좋은가?"가 아니라 "나의 요구에 가장 적합한 프레임워크는 무엇인가?"에 답하기 위한 것이다.

9.4.1 레이더 차트: 5축 비교

13개 프레임워크를 5가지 축에서 비교한다. 각 축은 0~10 점 척도로, 에이전트 평가에 얼마나 적합한지를 종합 평가한다:

레이더 차트 해석: 세 가지 클러스터

레이더 차트에서 13개 프레임워크는 세 가지 클러스터로 나뉜다:

클러스터 A: 자동화 특화형 (lm-eval, WebArena, SWE-bench) — 자동화는 9점이지만 다차원성과 에이전트 평가는 낮다. "한 가지를 완벽하게 자동화"하는 철학이다. CI/CD 파이프라인에 통합하기 가장 좋지만, 에이전트의 복잡한 행동(협업, 추론, 적응)은 평가하지 못한다.

클러스터 B: 관측 특화형 (LangSmith, TruLens, AutoGen Eval) — 실무성은 높지만 다차원성이 낮다. "무슨 일이 일어났는지"를 관측하는 데 탁월하지만, "얼마나 좋은가"를 판단하는 평가 메트릭은 부족하다. 관측(observability)과 평가(evaluation)의 차이다.

클러스터 C: 다차원 특화형 (HELM, DeepEval) — 다차원성은 높지만 에이전트 평가는 낮다. 모델이나 RAG의 여러 측면을 잘 평가하지만, 에이전트의 환경 상호작용, 도구 사용, 협업은 다루지 못한다.

우리의 6차원 프레임워크는 이 세 클러스터의 강점을 모두 결합하는 클러스터 D: 통합형을 지향한다.

9.4.2 결정 트리: 프레임워크 선택 가이드

결정 트리의 한계와 보완: 상황별 구체적 가이드

결정 트리는 직관적이지만, 실제 의사결정에서는 더 복잡한 요인이 작용한다. 일반적인 시나리오별 구체적 권장 사항을 제공한다:

시나리오 1: 스타트업이 최소 기능 에이전트(MVP)를 평가할 때

시나리오 2: 엔터프라이즈가 프로덕션 에이전트를 지속 평가할 때

시나리오 3: 연구팀이 멀티 에이전트 시스템을 평가할 때

9.5 공통 한계와 갭 분석

13개 프레임워크를 개별적으로 분석한 후, 모든 프레임워크가 공유하는 5가지 공통 한계를 식별했다.

9.5.1 공통 한계 5가지

1. 재현성 부족 (Reproducibility Crisis)

LLM의 비결정성 때문에 동일한 프롬프트에 다른 응답이 올 수 있다. temperature=0이라도 완전한 결정성이 보장되지 않는다.

2. 비용 누적 (Cost Accumulation)

평가 자체가 LLM API 호출을 필요로 하는 프레임워크(RAGAS, DeepEval, LangSmith)는 평가 비용이 상당하다. 1,000개 샘플을 RAGAS로 평가하면 GPT-4 기준 약 $50~$100. CI/CD에서 매 커밋마다 실행하기엔 부담스럽다.

3. 정성 평가의 어려움

"이 응답이 사용자에게 도움이 되었는가?" 같은 질문에는 여전히 인간 판단이 필요하다. LLM-as-Judge는 근사치이지 대체재가 아니다.

4. 벤치마크 오염 (Benchmark Contamination)

평가 데이터가 모델 학습 데이터에 포함되는 현상. 상용 모델은 학습 데이터를 공개하지 않아 오염 여부를 확인할 수 없다.

5. 프레임워크 종속성

AutoGen Eval은 AutoGen에, CrewAI Eval은 CrewAI에, LangSmith는 LangChain에 종속된다. 평가 결과를 서로 다른 프레임워크에서 비교할 수 없다.

6. 평가 결과의 비교 가능성 부재

13개 프레임워크가 서로 다른 것을 다르게 측정한다는 것은 이미 언급했다. 하지만 더 심각한 문제는 같은 것을 측정하더라도 측정 방식이 달라 직접 비교가 불가능하다는 것이다. 예를 들어:

이 문제를 메트릭 인터오퍼러빌리티(metric interoperability)라고 부른다. 같은 이름의 메트릭이 서로 다른 값을 반환하므로, RAGAS의 Faithfulness=0.85와 TruLens의 Groundedness=0.85는 같은 품질을 의미하지 않는다. 이것은 평가 생태계 전체의 파편화를 심화시킨다.

7. 동적 환경에서의 평가 정의 모호성

에이전트가 환경과 상호작용할 때, "성공"의 정의 자체가 모호해진다. WebArena에서 "이슈를 생성하라"는 태스크가 있다고 하자. 에이전트가 이슈를 생성했지만 제목에 오타가 있거나, 잘못된 레이블을 붙였거나, 설명이 불완전한 경우, 이것은 성공인가 실패인가?

현재 대부분의 에이전트 벤치마크는 이 질문에 이분법(binary)으로 답한다: 성공 또는 실패. 하지만 현실에서는 "부분적 성공(partial success)"이 훨씬 흔하다. SWE-bench에서 테스트의 70%만 통과한 패치는 0% 성공으로 처리된다. WebArena에서 5단계 중 4단계를 완료한 에이전트는 마지막 단계를 실패하면 0점을 받는다.

공통 한계의 수학적 모델: 평가 품질 한계

이 5가지 한계는 독립적이지 않다. 서로 상호작용하여 "평가 품질의 상한선"을 형성한다:

9.5.2 갭 분석: 우리에게 필요한 것 vs 기존이 제공하는 것

핵심 질문: 우리가 설계할 6차원 프레임워크는 기존 프레임워크가 남긴 어떤 갭을 채우는가?

갭 분석을 수행하기 위해, 먼저 "이상적인 에이전트 평가 프레임워크"가 갖추어야 할 요구사항을 정의한다:

요구사항 도출 방법론

10개 요구사항은 세 가지 출처에서 도출되었다:

1. 하향식(top-down): 6차원 프레임워크의 설계 목표(Ch.10)에서 필연적으로 요구되는 기능. 예: 각 차원별 메트릭이 필요하다면, 메트릭 계산 파이프라인이 요구사항이 된다.
2. 상향식(bottom-up): 13개 프레임워크 분석에서 발견된 공통 결함. 예: 13개 중 12개가 부분 성공을 측정하지 못하므로, 부분 성공 메트릭이 요구사항이 된다.
3. 실무자 인터뷰: 8개 기업의 ML 엔지니어와의 인터뷰에서 도출된 실제 페인포인트. 예: "평가 결과를 스테이크홀더에게 설명하기 어렵다" → 대시보드/시각화 요구사항.

이 세 가지 출처의 교집합이 다음 10개 요구사항이다. 각 요구사항에 대해 기존 최고 커버리지와 갭 크기를 평가한다:

9.6 Part II 종합 및 Part III 예고

Part II "The Shift"의 네 챕터를 통해 에이전트 평가로의 패러다임 전환을 추적했다:

• Ch.06: 단일 모델 평가에서 에이전트 평가로의 근본적 전환 이유
• Ch.07: 8개 이상의 에이전트 벤치마크 심층 분석
• Ch.08: 멀티 에이전트 평가의 새로운 5가지 차원
• Ch.09: 13개 기존 프레임워크 비교 분석과 갭 식별

이제 우리가 알고 있는 것을 정리하면:

1. 에이전트 평가는 LLM 평가와 근본적으로 다르다 (환경 상호작용, 다단계 추론)
2. 기존 벤치마크는 시뮬레이션에서 벗어나 현실(real-world)로 이동 중이다
3. 멀티 에이전트 평가의 5가지 새 차원(협업, 통신, 역할, 장애감내, 합의)은 어느 프레임워크도 충분히 다루지 않는다
4. 13개 기존 프레임워크 중 멀티 에이전트 협업 평가를 지원하는 것은 없다
5. 프레임워크 종속성이 평가의 표준화를 방해한다

9.6.1 프레임워크별 기여와 한계의 종합 매핑

각 프레임워크가 6차원 평가에 기여하는 바와 한계를 종합 매핑한다:

이 매핑이 보여주는 핵심: 어떤 단일 프레임워크도 6차원 모두를 커버하지 못한다. 가장 넓은 커버리지를 가진 HELM조차 4차원(D1, D3, D4 일부, D2 일부)만 부분적으로 커버한다. 6차원 프레임워크는 각 프레임워크의 강점을 차원별로 통합하는 "메타 프레임워크"다.

각 차원별 갭을 정량화하면 다음과 같다. D1(태스크 완료)은 기존 커버리지가 75%로 비교적 높지만, D4(안전성)와 D6(협업)은 각각 15%, 10%에 불과하다. 이것은 기존 생태계가 "에이전트가 태스크를 완수했는가?"에는 집중했지만, "안전하게, 협력적으로, 효율적으로 완수했는가?"에는 거의 주의를 기울이지 않았음을 의미한다. Part III는 이 미개척 영역을 체계적으로 개척한다.

9.6.2 프레임워크 진화 트렌드: 2020~2025

13개 프레임워크의 출시 시기와 초점을 시간순으로 정리하면, 명확한 진화 트렌드가 보인다:

이 트렌드는 평가 패러다임의 4단계 진화를 보여준다: 성능 → 다차원 → 현실 → 효율성 → 통합. 각 단계에서 이전 단계의 관심사를 포함하면서 새로운 차원을 추가한다. 6차원 프레임워크는 이 진화의 자연스러운 귀결이다.

9.6.3 Part II에서 Part III로: 지식의 다리

Part II(Ch.06~09)에서 우리는 세 가지 핵심 질문에 답했다:

1. 왜 에이전트 평가가 다른가? (Ch.06): 환경 상호작용, 다단계 추론, 도구 사용이 LLM 평가와 근본적으로 다른 과제를 만든다.
2. 에이전트 벤치마크는 어떻게 설계되었는가? (Ch.07): 3세대에 걸친 진화, 7가지 설계 원칙, 10개 핵심 벤치마크의 심층 분석.
3. 기존 프레임워크는 무엇을 제공하고 무엇을 놓치는가? (Ch.09): 13개 프레임워크의 종합 비교와 갭 분석.

Part III(Ch.10~15)에서는 이 세 가지 질문에 대한 답을 바탕으로, 6차원 평가 프레임워크를 직접 설계하고 구현한다:

• Ch.10: 아키텍처 — 6차원의 구조적 관계와 데이터 흐름
• Ch.11: 메트릭 심층 — 16개 메트릭의 수학적 정의와 구현
• Ch.12: AutoGen 통합 — 프레임워크 독립적 어댑터 설계
• Ch.13: 스코어링 시스템 — 다차원 점수의 집계와 해석
• Ch.14: 자동화 파이프라인 — CI/CD 통합과 지속적 평가
• Ch.15: 비주얼 컴펜디움 — 대시보드와 시각화

지식의 다리: Part II의 핵심 통찰에서 Part III의 설계 원칙으로

이 장에서 도출한 통찰을 Part III의 설계 원칙으로 직접 연결한다: