에이전트가 일을 끝냈는지 확인하는 평가법: 말이 아닌 바뀐 상태를 채점하라
말이 아닌 바뀐 상태를 채점하는 에이전트 평가법: 동일한 DB에서 시작해 최종 상태·필수/금지 도구·스텝 예산·답변 순으로 검사하고, 답변만 보는 채점의 함정을 피하는 재현 가능한 실무 팁.
원문 작성자는 Sergii Makarevych(@sermakarevich)이며, 2026년 10월 11일 X 게시물에서 에이전트 평가(agentic evals) 아티클을 공개했습니다. 핵심 주장은 하나입니다. 에이전트의 일처리는 답변 문장이 아니라 실행이 끝난 뒤 바뀐 상태로 채점해야 한다는 것입니다.
이 팁은 작성자 본인이 스레드에서 직접 밝힌 채점 순서를 옮긴 것입니다. 실행이 끝난 뒤 바뀐 상태가 답변보다 중요하다는 것이 요지입니다.
동일한 DB에서 시작해 다섯 가지를 순서대로 검사한다
작성자는 스레드에서 채점 순서를 이렇게 못 박았습니다. 상태가 답변보다 중요하다는 것이 요지입니다.
- 최종 상태가 기대 상태와 일치하는지 확인한다.
- 필수 도구가 호출됐는지 확인한다.
- 금지된 도구가 호출되지 않았는지 확인한다.
- 스텝 예산 안에 머물렀는지 확인한다.
- 그다음에야 답변을 본다.
아티클 예시에서는 매 실행이 동일하게 재구축된 데이터베이스에서 출발합니다. 실행이 끝난 뒤 채점기가 위 다섯 항목을 검사합니다. 순서를 바꿔 답변부터 보면 안 됩니다. 답변이 그럴듯해도 상태가 어긋나면 실패입니다.
답변만 보는 채점이 놓친 10건을 기억하라
작성자가 공개한 수치는 답변 채점의 함정을 그대로 보여줍니다. 답변만 보는 채점기는 60회 중 58회를 통과시켰습니다. 상태 검사를 적용하면 통과는 48회로 떨어집니다. 나머지 10회는 실제로는 환불 기록이 없는데도 "환불이 처리 중입니다"라는 취지의 답변을 내놓은 실행이었습니다.
말만 보면 통과, 상태를 보면 탈락입니다. 에이전트 평가를 도입할 때 첫 번째로 바꿀 점이 바로 이것입니다. 답변 문장의 자연스러움이 아니라 기록 변경 같은 외부 효과를 채점 단위로 삼아야 합니다.
이 방법이 다루지 않는 한계를 함께 적어둔다
스레드에서 나온 주의점도 원문과 함께 보존합니다. 이 다섯 가지 검사는 정상 경로(happy-path) 실행 결과를 다룹니다. 실행이 통과했더라도, 그 실행이 보유하고 있었던 권한의 범위(무엇까지 할 수 있었는지)는 점수에 들어 있지 않습니다. 결과 옆에 권한 점수도 매기라는 지적이 스레드 댓글에서 나왔습니다.
도달할 수 없는 상태를 요구하는 과제 명세도 별도 처리가 필요합니다. 스레드 댓글에 따르면, 도달할 수 없는 상태를 요구하는 명세 앞에서 에이전트를 며칠씩 고치는 것은 시간 낭비라는 지적이 있습니다. 채점기를 짜기 전에 과제 명세가 실제로 도달 가능한 상태인지부터 확인하십시오.
원문 출처
- Sergii Makarevych(@sermakarevich) 원문 게시물 (2026-10-11): Agentic evals: how to know whether an AI agent did the job, and will do it again
- 원문 아티클: Agentic evals (X Article)
- 작성자의 채점 순서 직접 설명 (Leo Oliemans 질문에 대한 답변): 상태가 답변보다 중요하다는 스레드 답변