AI 에이전트 평가(agent evaluation) 는 모델이 단일 질문에 답을 잘하는지보다, 장시간 도구를 사용하며 환경을 바꾸는 시스템이 실제 목표를 달성했는지 측정하는 문제다. 에이전트는 추론, 도구 호출, 상태 관리, 오류 복구, 최종 검증이 한 루프 안에 묶이기 때문에 기존 LLM 벤치마크만으로는 품질을 판단하기 어렵다.
왜 기존 평가로 부족한가
정적 벤치마크는 입력과 정답이 고정돼 있다. 하지만 에이전트는 실행 중 다음 요소가 계속 변한다.
- 도구 호출 결과
- 파일시스템, 브라우저, API 같은 외부 환경
- 중간 실패와 재시도
- 장기 컨텍스트와 메모리
- 사용자 승인 또는 정책 제한
따라서 에이전트 평가는 “정답 문자열 일치”보다 “환경 안에서 목표 상태를 만들었는가”를 봐야 한다.
평가 하네스의 구성 요소
| 구성 요소 | 설명 |
|---|---|
| 태스크 명세 | 목표, 허용 도구, 금지 행동, 완료 조건을 정의한다 |
| 실행 환경 | 브라우저, 코드 저장소, API, 샌드박스 등 상호작용 대상 |
| 관찰 로그 | 프롬프트, 도구 호출, 결과, 비용, 지연 시간을 기록한다 |
| 채점기 | 최종 상태를 테스트, 규칙, 휴먼 리뷰, LLM judge 등으로 판정한다 |
| 실패 분석 | 어디서 계획·도구·컨텍스트·검증이 무너졌는지 분류한다 |
좋은 평가 하네스는 에이전트가 스스로 성공했다고 말하는지보다, 외부에서 관찰 가능한 상태가 실제로 성공 조건을 만족하는지 확인한다.
대표 평가 축
| 평가 축 | 질문 |
|---|---|
| 목표 달성 | 최종 산출물이 요구사항을 충족했는가? |
| 도구 사용 | 필요한 도구를 적절한 순서와 인자로 호출했는가? |
| 오류 복구 | 실패한 명령, 잘못된 API 응답, 누락된 파일을 회복했는가? |
| 효율 | 토큰, 시간, 비용, 도구 호출 수가 과하지 않은가? |
| 안전성 | 권한, 개인정보, 파괴적 명령, 정책 위반을 피했는가? |
| 일반화 | 한 벤치마크에 과적합하지 않고 새 환경에서도 작동하는가? |
실무 평가 패턴
코딩 에이전트라면 채점기는 자연어 평가보다 실행 가능한 검증에 가까워야 한다.
npm test
npm run build
git diff --check웹 에이전트라면 브라우저 상태, DOM, API 응답, 스크린샷 기반 검사가 필요하다. 업무 자동화 에이전트라면 실제 캘린더·이메일·티켓 시스템을 건드리기 전에 mock 또는 sandbox 환경에서 상태 변화를 확인해야 한다.
LLM judge는 보조 수단이다
LLM judge는 긴 로그를 요약하고 정성적 결함을 찾는 데 유용하지만, 단독 최종 판정기로 쓰면 위험하다. 가능하면 테스트, 스키마 검증, 파일 diff, API 상태 확인 같은 결정적 신호를 먼저 쓰고, LLM judge는 원인 분석과 리뷰 보조에 배치하는 편이 안전하다.
관련 문서
- agent-harness — AI 에이전트 성능을 결정하는 하네스 설계
- future-agi — AI 에이전트 평가·관찰·개선을 위한 오픈소스 플랫폼
- agentops — AI 에이전트 프로덕션 운영을 위한 관찰·제어 레이어
- codex-tips-goal-command —
/goal명령을 작업 계약으로 쓰는 방법
참고 자료
- Agent Evaluation: A Detailed Guide — Deep (Learning) Focus (2026-05-18)