AI 에이전트 평가

LLM 평가는 오랫동안 문제를 맞히는 능력에 집중했다. 수학 문제를 풀 수 있는가, 코딩 문제를 통과하는가, 긴 문서를 읽고 답할 수 있는가가 주요 기준이었다. 이 기준은 여전히 중요하다. 하지만 AI 에이전트를 평가하기에는 부족하다.

에이전트는 답변만 생성하지 않는다. 파일을 읽고, API를 호출하고, 명령을 실행하고, 브라우저를 조작하고, 실패하면 복구한다. 따라서 에이전트의 품질은 모델이 얼마나 똑똑한지뿐 아니라, 도구를 얼마나 안정적으로 사용하는지에 달려 있다.

최근 Hugging Face에 올라온 EVA-Bench Data 2.0은 이런 변화를 잘 보여준다. 3개 도메인, 121개 도구, 213개 시나리오처럼 실제 도구 사용 상황을 평가하려는 흐름이 강해지고 있다. 앞으로 에이전트 평가는 단순 benchmark score보다 task completion과 tool-use reliability를 더 중요하게 보게 될 가능성이 크다.

정답률은 충분조건이 아니다

모델이 문제를 잘 푼다고 해서 에이전트가 일을 잘하는 것은 아니다. 실제 작업은 보통 다음처럼 진행된다.

  1. 사용자의 목표를 해석한다.
  2. 필요한 정보를 찾는다.
  3. 적절한 도구를 고른다.
  4. 도구 입력을 만든다.
  5. 결과를 해석한다.
  6. 실패하면 원인을 분류한다.
  7. 필요하면 다른 경로로 재시도한다.
  8. 최종 결과를 검증한다.

여기서 하나만 틀려도 작업은 실패한다. 모델이 좋은 답을 알고 있어도 잘못된 파일을 수정하면 실패다. API 응답을 오해하면 실패다. 권한 오류를 rate limit으로 착각하고 반복 호출하면 실패다. 테스트를 실행하지 않고 성공했다고 말하면 더 나쁜 실패다.

그래서 에이전트 평가는 “알고 있는가”가 아니라 “끝냈는가”를 봐야 한다.

도구 사용 평가에서 봐야 할 것

에이전트 평가를 설계할 때는 최소한 다음 항목을 분리해서 봐야 한다.

1. 도구 선택 능력

같은 문제도 여러 도구로 접근할 수 있다. 파일 내용을 확인해야 하는데 웹 검색을 하거나, 현재 시스템 상태를 봐야 하는데 기억에 의존하면 실패 가능성이 커진다. 좋은 에이전트는 목표에 맞는 도구를 고른다.

예를 들어 “테스트가 왜 실패하지?”라는 요청에는 다음 순서가 자연스럽다.

  • 현재 브랜치와 변경사항 확인
  • 실패 로그 확인
  • 관련 테스트만 재실행
  • 원인 파일 읽기
  • 최소 수정
  • 다시 테스트

반대로 처음부터 대규모 리팩터링을 시작하면 문제를 키울 수 있다.

2. 입력 구성 능력

도구를 고르는 것만으로는 부족하다. API 호출의 파라미터, CLI 옵션, 검색 쿼리, 파일 경로를 정확히 만들어야 한다. 특히 에이전트는 경로를 자주 틀린다. 비슷한 이름의 파일, 오래된 문서, 다른 프로젝트의 설정을 혼동하기 쉽다.

평가 시나리오에는 이런 함정을 넣어야 한다. 그래야 단순한 데모가 아니라 실제 운영 환경에 가까운 성능을 볼 수 있다.

3. 결과 해석 능력

도구 결과는 항상 깔끔하지 않다. 테스트 로그는 길고, API 응답은 부분 성공일 수 있으며, 명령은 exit code 0이어도 경고를 남길 수 있다. 좋은 에이전트는 결과를 그대로 요약하는 데서 끝나지 않고, 작업 목표와 연결해 판단해야 한다.

예를 들어 build가 성공했지만 asset validation이 실패했다면 배포 가능한 상태가 아니다. unit test는 통과했지만 migration test가 실패했다면 backend 변경은 아직 안전하지 않다.

4. 실패 복구 능력

현실적인 에이전트 평가는 실패를 포함해야 한다. 권한 부족, 네트워크 타임아웃, flaky test, 잘못된 문서, 누락된 환경변수 같은 상황에서 어떻게 행동하는지가 중요하다.

좋은 실패 복구는 무한 재시도가 아니다. 실패 종류를 분류하고, 재시도 가능한 경우와 사용자 개입이 필요한 경우를 나눠야 한다. 그리고 실패를 숨기지 말아야 한다. 에이전트가 실제로 실행하지 않은 테스트를 실행했다고 말하는 순간 신뢰는 깨진다.

에이전트 평가 지표

단순 점수 하나로는 부족하다. 최소한 다음 지표를 함께 봐야 한다.

  • 작업 완료율: 최종 목표를 실제로 달성했는가
  • 검증률: 결과를 테스트나 조회로 확인했는가
  • 도구 호출 효율: 불필요한 호출을 남발하지 않았는가
  • 비용: 토큰과 외부 API 비용이 과도하지 않은가
  • 지연시간: 사용자가 기다릴 수 있는 수준인가
  • 실패 복구: 오류를 분류하고 적절히 대응했는가
  • 안전성: 권한 범위를 넘거나 위험 명령을 실행하지 않았는가
  • 설명 가능성: 어떤 근거로 완료 판단을 했는지 남겼는가

여기서 가장 중요한 것은 작업 완료율과 검증률이다. 에이전트는 말로 그럴듯하게 마무리하기 쉽다. 하지만 실제 개발 업무에서는 파일이 수정되었는지, 테스트가 통과했는지, 배포가 되었는지가 중요하다.

벤치마크가 놓치기 쉬운 것

도구 사용 벤치마크도 조심해야 한다. 시나리오가 너무 깨끗하면 실제 품질을 과대평가한다. 현실에는 다음 문제가 섞인다.

  • 문서와 코드가 다르다.
  • README가 오래되었다.
  • 로컬 환경과 CI 환경이 다르다.
  • 테스트가 가끔 실패한다.
  • 권한이 일부만 있다.
  • API 응답이 pagination 되어 있다.
  • 같은 이름의 리소스가 여러 개 있다.
  • 사용자의 요구사항이 중간에 바뀐다.

좋은 평가는 이런 지저분함을 어느 정도 포함해야 한다. 그래야 데모용 에이전트와 운영 가능한 에이전트를 구분할 수 있다.

개발팀에 필요한 내부 평가셋

외부 벤치마크만으로는 부족하다. 각 팀은 자기 코드베이스와 운영 방식에 맞는 내부 평가셋을 만들어야 한다. 거창할 필요는 없다. 반복적으로 발생하는 실제 업무를 작은 시나리오로 정리하면 된다.

예시는 다음과 같다.

  • 실패한 테스트 로그를 보고 최소 수정하기
  • 특정 API endpoint에 validation 추가하기
  • 오래된 dependency 업데이트 후 회귀 테스트하기
  • Kubernetes manifest의 잘못된 설정 찾기
  • CI 실패 원인을 분류하고 PR 코멘트 작성하기
  • 장애 로그에서 원인 후보와 추가 확인 명령 제안하기

각 시나리오에는 성공 조건이 있어야 한다. “좋은 답변”이 아니라 “테스트 통과”, “정확한 파일 수정”, “잘못된 명령 미실행”, “근거 로그 첨부”처럼 확인 가능한 조건이 필요하다.

결론

AI 에이전트 시대의 평가는 모델 지능만 보는 방식에서 벗어나야 한다. 중요한 질문은 “이 모델이 아는가”가 아니라 “이 에이전트가 실제 도구를 사용해 일을 끝낼 수 있는가”다.

앞으로는 tool-use benchmark, 내부 작업 평가셋, 실패 복구 테스트, 비용 측정이 함께 중요해질 것이다. 개발팀이 에이전트를 도입한다면 먼저 작은 평가셋부터 만들어야 한다. 에이전트에게 일을 맡기기 전에, 그 에이전트가 어떤 조건에서 실패하는지 알아야 하기 때문이다.

좋은 에이전트는 정답을 말하는 시스템이 아니다. 검증 가능한 결과를 남기고, 실패하면 정직하게 멈출 줄 아는 작업자에 가깝다.

참고

  • Hugging Face Blog: EVA-Bench Data 2.0
  • GitHub Blog: agentic workflow와 token efficiency 관련 글
  • OpenAI News: GPT-Rosalind 및 Codex 관련 업데이트