TAU-HOME.COM
LOADING

에이전트가 일을 끝냈는지 확인하는 평가법: 말이 아닌 바뀐 상태를 채점하라

말이 아닌 바뀐 상태를 채점하는 에이전트 평가법: 동일한 DB에서 시작해 최종 상태·필수/금지 도구·스텝 예산·답변 순으로 검사하고, 답변만 보는 채점의 함정을 피하는 재현 가능한 실무 팁.

tau · 2026년 10월 12일

#AI에이전트 #에이전트평가 #LLM테스트

에이전트가 일을 끝냈는지 확인하는 평가법: 말이 아닌 바뀐 상태를 채점하라

원문 작성자는 Sergii Makarevych(@sermakarevich)이며, 2026년 10월 11일 X 게시물에서 에이전트 평가(agentic evals) 아티클을 공개했습니다. 핵심 주장은 하나입니다. 에이전트의 일처리는 답변 문장이 아니라 실행이 끝난 뒤 바뀐 상태로 채점해야 한다는 것입니다.

이 팁은 작성자 본인이 스레드에서 직접 밝힌 채점 순서를 옮긴 것입니다. 실행이 끝난 뒤 바뀐 상태가 답변보다 중요하다는 것이 요지입니다.

동일한 DB에서 시작해 다섯 가지를 순서대로 검사한다

작성자는 스레드에서 채점 순서를 이렇게 못 박았습니다. 상태가 답변보다 중요하다는 것이 요지입니다.

  1. 최종 상태가 기대 상태와 일치하는지 확인한다.
  2. 필수 도구가 호출됐는지 확인한다.
  3. 금지된 도구가 호출되지 않았는지 확인한다.
  4. 스텝 예산 안에 머물렀는지 확인한다.
  5. 그다음에야 답변을 본다.

아티클 예시에서는 매 실행이 동일하게 재구축된 데이터베이스에서 출발합니다. 실행이 끝난 뒤 채점기가 위 다섯 항목을 검사합니다. 순서를 바꿔 답변부터 보면 안 됩니다. 답변이 그럴듯해도 상태가 어긋나면 실패입니다.

답변만 보는 채점이 놓친 10건을 기억하라

작성자가 공개한 수치는 답변 채점의 함정을 그대로 보여줍니다. 답변만 보는 채점기는 60회 중 58회를 통과시켰습니다. 상태 검사를 적용하면 통과는 48회로 떨어집니다. 나머지 10회는 실제로는 환불 기록이 없는데도 "환불이 처리 중입니다"라는 취지의 답변을 내놓은 실행이었습니다.

말만 보면 통과, 상태를 보면 탈락입니다. 에이전트 평가를 도입할 때 첫 번째로 바꿀 점이 바로 이것입니다. 답변 문장의 자연스러움이 아니라 기록 변경 같은 외부 효과를 채점 단위로 삼아야 합니다.

이 방법이 다루지 않는 한계를 함께 적어둔다

스레드에서 나온 주의점도 원문과 함께 보존합니다. 이 다섯 가지 검사는 정상 경로(happy-path) 실행 결과를 다룹니다. 실행이 통과했더라도, 그 실행이 보유하고 있었던 권한의 범위(무엇까지 할 수 있었는지)는 점수에 들어 있지 않습니다. 결과 옆에 권한 점수도 매기라는 지적이 스레드 댓글에서 나왔습니다.

도달할 수 없는 상태를 요구하는 과제 명세도 별도 처리가 필요합니다. 스레드 댓글에 따르면, 도달할 수 없는 상태를 요구하는 명세 앞에서 에이전트를 며칠씩 고치는 것은 시간 낭비라는 지적이 있습니다. 채점기를 짜기 전에 과제 명세가 실제로 도달 가능한 상태인지부터 확인하십시오.

원문 출처