AI 에이전트 평가(eval) 활용법: 벤치마크 해석부터 에이전트 개선까지 3단계

핵심 메시지

• 모델 연구소가 발표하는 벤치마크 점수는 근사치일 뿐이며, 점수가 비슷하다고 모델 성능이 같다는 뜻은 아니다.
• 반대로 '감으로 판단하면 된다'는 태도도 위험하다. 발표자는 두 극단 모두 틀렸고 진실은 중간에 있다고 말한다.
• 남의 평가를 해석하는 단계, 평가로 내 에이전트를 개선하는 단계, 직접 평가를 만드는 단계로 나눠 접근하라.
• 에이전트 평가에서는 정답 여부뿐 아니라 소요 턴 수, 도구 호출 수, 토큰 사용량, 전체 실행 시간을 함께 추적해야 한다.
• 평가로 드러나는 실패는 모델, 에이전트 스캐폴딩(하네스), 문제 설정 세 가지 중 어디서 왔는지 구분해야 한다.

쉽게 이해하기

AI 개발자 컨퍼런스 무대에 오른 발표자 아라 칸(Ara Khan)은 코딩 에이전트를 만들며 몇 년간 평가(eval)를 다뤄온 경험을 풀어놓았다. 그의 출발점은 도발적이다. "사람들은 평가에 대해 틀렸다"는 것이다. 그는 틀리는 방식이 두 가지라고 정리했다. 하나는 벤치마크 숫자를 액면 그대로 믿는 쪽이고, 다른 하나는 숫자는 전부 무의미하니 써보고 느낌으로 판단하면 된다는 쪽이다.

숫자를 믿는 쪽의 문제는 순위표에서 점수가 몇 점 차이로 붙어 있는 모델들이 실제로는 전혀 대등하지 않다는 점이다. 발표자는 30분만 직접 써봐도 그 차이를 알게 된다고 말한다. 게다가 일부 연구소는 순위표 점수를 올리는 것 자체를 목표로 삼는 '벤치마크 맥싱'을 한다는 지적도 소개했다. 반대로 감에만 기대는 쪽은 모델을 사람처럼 이야기하며 "대화가 편하다" 같은 근거로 선택을 정당화한다.

그가 제시한 첫 번째 해법은 남이 만든 평가를 읽는 요령이다. 연구소가 내놓은 점수는 신의 말씀이 아니라 근사치로 취급할 것, 최신 흐름은 따라가되 새 모델이 나올 때마다 갈아타는 소모전은 피하고 며칠 지나 먼지가 가라앉은 뒤 직접 시험할 것, 그리고 범용 벤치마크보다 자기 문제에 가까운 평가를 찾을 것. 실제로 오랫동안 표준이던 코딩 벤치마크 하나는 점수가 포화되어 이제 모델 발표 자료에서 언급조차 되지 않는다.

두 번째는 평가로 자기 에이전트를 개선하는 단계다. 에이전트는 한 번의 질의응답과 달리 웹 검색, 라이브러리 설치, 파일 읽기와 편집을 오가며 수십 분씩 돌아간다. 그래서 발표자 팀은 실제 소프트웨어 문제 89개로 구성된 터미널 벤치(Terminal-Bench)를 채택했다. 데이터베이스 문제, 경쟁 상태(race condition), 프런트엔드 버그처럼 현업에서 마주치는 과제를 에이전트가 오래 붙잡고 풀게 한 뒤, 결정적인 단위 테스트로 성공 여부를 채점하는 방식이다.

평가를 대규모로 돌리면 개별 세션에서는 잘 안 보이던 실패가 뭉텅이로 드러난다. 파일을 못 읽어 같은 오류를 무한 반복하거나 설치에 계속 실패하는 식이다. 발표자는 이렇게 얻은 '실패 포트폴리오'를 보고 파일 편집 도구나 웹 브라우저 도구를 고쳐 점수를 끌어올렸다고 밝혔다. 다만 마지막으로 경고를 덧붙인다. 숫자가 주어지면 사람은 숫자만 최적화하려 들기 때문에, 특정 과제에만 통하는 과적합을 경계하고 마지막에는 여전히 '이 에이전트가 말이 되는가'라는 감각적 점검을 통과해야 한다는 것이다.

주요 인사이트

• 평가는 순수한 공학 문제가 아니라 '무엇을 잘한다고 볼 것인가'를 정하는 철학적 선택이 섞인 문제다. 에이전트의 행동 공간이 사실상 무한하기 때문이다.
• 피보나치 수열 구현 같은 교과서형 과제로는 실무 능력을 가늠할 수 없다. 평가 과제가 현업과 닮을수록 개선 방향도 실무에 가까워진다.
• 같은 모델이 어떤 에이전트에서는 잘 돌고 다른 에이전트에서는 헤맨다면, 그것은 모델이 아니라 하네스(스캐폴딩) 설계의 문제일 가능성이 크다.
• 평가 과제를 컨테이너로 격리해 병렬 실행하면 서로의 환경을 오염시키지 않고 수 시간 걸리던 순차 실행을 크게 단축할 수 있다.
• 가장 비싼 최신 모델을 늘 쓸 수는 없다. 비용·지연 지표를 함께 측정해야 '이 품질에 이 정도 비용까지는 낸다'는 판단 기준이 생긴다.

자주 묻는 질문

관련 AI 소식