에이전트의 최종 답변은 좋아 보이는데 실제 예약이나 코드 변경은 실패합니다. 에이전트 평가는 무엇을 성공으로 측정하나요?

최종 문장의 품질과 실제 환경에 남은 결과를 분리해 평가해야 합니다. 과제는 입력과 성공 기준을 가진 시나리오, trial은 한 번의 실행, trace는 모델·도구·관찰의 실행 이력, outcome은 환경의 최종 상태입니다. 예약했다고 말하는 것이 아니라 실제 예약이 생성됐고 조건·권한·중복 제한을 지켰는지가 성공 기준입니다.

결과 중심의 과제 구성

코딩 과제는 요구 기능과 기존 동작을 검사하고, 지원 과제는 올바른 해결·안전한 이관·부적절한 변경 부재를 확인합니다. 정답 경로 하나의 도구 호출 순서를 강제하면 유효한 다른 방법을 실패로 볼 수 있습니다. 결과에 필요한 제약만 채점하고, 안전상 반드시 지켜야 하는 승인·외부 전송 규칙은 별도 검사합니다. 부분 성공을 인정할지와 실패 상태를 정확히 보고한 경우의 점수도 미리 정합니다.

각 trial은 격리된 초기 환경에서 시작해야 합니다. 이전 실행의 파일·캐시·DB 상태·정답 기록이 남으면 모델이 실제로 해결하지 않고도 통과할 수 있습니다. 과제 데이터·도구·모델·프롬프트·예산·환경 버전을 기록하고, 도구 장애나 테스트 인프라 오류를 에이전트의 추론 실패와 구분합니다. 다만 운영에서도 발생하는 도구 장애를 모두 평가 밖으로 빼면 복구 능력을 놓칩니다.

trace는 진단 자료입니다

결과가 틀렸을 때 필요한 도구를 못 찾았는지, 잘못된 인자를 썼는지, 결과를 오해했는지, 검증을 생략했는지 trace로 분석합니다. trace가 길고 그럴듯하다고 점수를 주지 않고 outcome과 연결합니다. 반대로 결과만 보면 우연한 성공이나 승인 우회를 놓칠 수 있어 실행 제약도 함께 봅니다. 숨겨진 내부 추론 전문을 수집할 필요 없이 관찰 가능한 호출·응답·상태·결정 요약으로 분석할 수 있습니다.

2026년 공개된 에이전트 평가 지침은 실제 실패에서 시작한 작은 과제 집합과 회귀·능력 평가의 구분을 강조합니다. 현재 잘하는 과제는 회귀 보호로 유지하고 더 어려운 과제를 추가하되 테스트 세트에 과적합하지 않게 합니다. 반복 trial의 분산·안전한 거절·해결 한 건당 비용까지 봐야 배포 가능한 품질을 판단할 수 있습니다. 성공 문구를 채점하는 챗봇 평가를 그대로 가져오는 것으로는 행동하는 에이전트를 충분히 평가할 수 없습니다.

실행 사례로 확인합니다

예약 과제의 채점기는 날짜·인원·사용자·중복 여부를 DB에서 확인하고, trace에서는 승인 없이 결제하거나 다른 사용자 자료를 읽지 않았는지 확인할 수 있습니다. 최종 예약이 맞아도 중간에 금지된 행동을 했으면 안전한 성공으로 보지 않습니다. 반대로 정상적인 예약 불가 상황에서 정확히 거절하고 대안을 제시한 것은 과제 정의에 따라 성공일 수 있습니다. 모든 요청을 무조건 완료시키는 방향으로 점수를 만들면 위험한 행동을 장려합니다. 과제별 기대 상태와 허용된 이관·거절을 먼저 정하고 평가 결과에서 기능 성공·안전 준수·설명 품질을 나눠 보고하면 실제 배포 판단에 더 도움이 됩니다.