Section 1평가 주도 개발
에이전트나 다중 에이전트 시스템을 구축하는 팀들이 흔히 저지르는 실수는 평가를 개발 과정의 너무 늦은 시점까지 미루는 것이다.
평가 주도 개발(evaluation-driven development) — 시스템을 구축하기 전에 성공을 어떻게 측정할 것인지 먼저 정의한다. 테스트 주도 개발(TDD)이 코드보다 테스트를 먼저 작성하듯, 에이전트 행동을 구현하기 전에 성공 기준·지표·평가 인프라를 미리 확립한다.
추론 효율성을 측정할 것이라면 첫날부터 토큰 추적을 구축하고, 툴 호출 시퀀스를 비교할 것이라면 관측 가능성을 프레임워크에 설계해 넣게 된다. 평가의 제약 조건이 곧 설계의 요구사항이 된다. Eugene Yan이 관찰했듯, 평가·실험 하네스를 한 번 세팅해 원클릭 실행이 가능해지면 팀은 실험을 즐기게 되고 진보는 빠르게 찾아온다.
5단계 평가 계획 프레임워크 — 에이전트 코드를 작성하기 전에 다섯 가지 핵심 계획 질문에 답하라. 무엇을 평가하는가, 어떻게 채점하는가, 어떤 데이터로, 어떤 임계값으로, 어떻게 반복하는가.
Section 2평가 대상 — 다중 에이전트 트래젝토리
에이전트를 실행할 때마다 트래젝토리가 생성된다 — 과업을 처리하기 위해 수행된 추론과 행동의 완전한 기록.
class RunTrajectory: task: Task # 해결하고자 하는 것 messages: Sequence[Message] # 완전한 대화 이력 success: bool # 과업을 완료했는가 error: Optional[str] # 실패 시 오류 상세 usage: Optional[Usage] # 자원 소비 지표 metadata: Dict[str, Any] # 추가 실행 컨텍스트
"그것을 계산해 보겠습니다: 2+2" → "계산기 결과: 4" → "계산이 완료되었습니다." 어느 메시지가 답변인가? 마지막 메시지를 취하면 "계산이 완료되었습니다"를 얻어 실제 결과를 놓친다. 평가 시스템은 답변 추출 전략(last_non_empty, last_assistant, all_assistant)으로 이를 다룬다.
관측 가능성이 평가를 가능하게 한다 — 에이전트가 구조화된 이벤트(OpenTelemetry)를 방출하면, 별도의 평가 전용 실행 없이도 완전한 트래젝토리를 재구성할 수 있다. 모든 프로덕션 실행이 잠재적 평가 데이터 포인트가 된다.
Section 3지표와 저지
트래젝토리를 손에 넣었다면 어떻게 점수를 매기나? 두 구성 요소 — 어떤 차원을 측정할지 정하는 지표(metric), 그 차원을 어떻게 채점할지 정하는 저지(judge).
| 지표 유형 | 설명 | 저지 예 |
|---|---|---|
| 참조 기반 | 출력을 알려진 정답과 비교. 결정론적 답은 LLM 호출 없이 평가 | ExactMatch, Contains, FuzzyMatch |
| 참조 없는 | 정답 없이 품질 평가 — 유용성·소통 명료성·자원 효율성 | LLMEvalJudge |
| 에이전트 특화 | 해법에 도달하는 과정 평가 — 올바른 툴을 올바른 순서로 선택했는가 | ToolMessage 검사 |
참조 없는 평가에는 강력한 언어 모델을 저지로 활용한다 — 전통적 지표가 놓치는 미묘한 품질까지 평가한다. LLMEvalJudge는 과업·기대 출력·전체 대화를 포함한 평가 프롬프트를 구성해 각 기준(정확성·유용성·효율성)에 0–10점과 추론을 제시한다.
채점 전략
- 단일 답안 채점 — 전체 트래젝토리를 통합적으로 채점. 과정 세부를 놓칠 수 있다.
- 쌍대 비교 — 두 출력을 직접 비교해 어느 쪽이 더 나은지 가린다. 상대적 판단은 더 신뢰할 만하다 — 반복 개발 단계에 가치 있다.
- 차원별 채점 — 여러 측면을 독립적으로 채점. 세부 피드백·약점 식별에 좋다.
Section 4실용적 평가 하니스 구축
근본 질문 — 다중 에이전트 시스템이 그 오버헤드를 정당화하는 순간은 언제인가? 네 가지 접근을 비교한다 — 베이스라인(직접 모델 호출)에서 출발해 점진적으로 능력을 더한다(툴, 라운드 로빈, AI 주도). 공정한 비교를 위해 모두 GPT-4.1-mini를 쓴다.
Section 5다중 에이전트는 언제 정당화되나
| 과업 유형 | 최적 접근 | 핵심 발견 |
|---|---|---|
| 단순 추론 | 직접 모델 호출 (9.7/10) | 다중 에이전트 대비 24배 토큰 효율. 오버헤드가 무가치 |
| 웹 검색 리서치 | 툴 에이전트 (9.0/10) | 직접 모델은 3.2/10 — 툴 조율이 결정적 |
| 다중 도메인 협업 | 다중 에이전트 | 전문화 역량이 오버헤드를 정당화 |
다중 에이전트 시스템은 작업이 툴 조율이나 전문화된 역량을 요구할 때에만 그 오버헤드를 정당화한다. 단순 추론 과제에서 Direct-Model(9.7/10)이 Multi-Agent-AI(9.3/10)를 이겼고 토큰 비용은 43배 낮았다. 평가가 명확한 이점을 입증할 때에만 복잡성을 추가하라.