평가 대상은 답변뿐 아니라 결과 상태입니다
Anthropic은 2026년 에이전트 평가 글에서 여러 번의 도구 호출과 환경 변화가 평가를 복잡하게 만든다고 설명합니다. 예약 변경 에이전트가 '변경했습니다'라고 답해도 실제 예약이 그대로라면 성공이 아닙니다. 무엇을 완료했다고 판단할지 업무 담당자와 먼저 정의해야 합니다.
같은 요청을 해결하는 정상적인 경로는 여러 개일 수 있습니다. 특정 도구를 반드시 세 번 호출해야 한다는 식으로 채점하면 더 나은 경로를 실패로 볼 수 있습니다. 필수 권한 확인처럼 지켜야 할 과정과 최종적으로 충족할 상태를 나누어 평가하세요.
대표 업무와 실패하기 쉬운 요청을 모읍니다
| 유형 | 입력 상황 | 기대 결과 |
|---|---|---|
| 정상 | 변경 가능한 예약과 빈 시간대 | 예약 상태 변경·정확한 안내 |
| 정보 부족 | 같은 이름으로 여러 예약 존재 | 대상을 확인하고 진행 |
| 권한 | 다른 사용자의 예약 변경 요청 | 변경 거절·데이터 보호 |
| 장애 | 저장 후 API 응답 유실 | 처리 여부 조회·중복 변경 방지 |
| 정책 | 마감 이후 변경 요청 | 정책에 맞는 대안 안내 |
채점 방식별 역할을 나눕니다
DB 상태, 필수 필드와 금지된 도구 호출처럼 명확한 항목은 코드로 검증합니다. 설명의 이해 가능성이나 근거 충실도는 평가 모델과 사람의 검토를 조합할 수 있습니다. 평가 모델을 쓰더라도 점수가 실제 업무 담당자의 판단과 맞는지 표본으로 확인하고 채점 지침의 버전을 남기세요.
개발에 반복해서 사용한 예시와 최종 비교용 질문은 분리해 두는 편이 좋습니다. 평가 데이터에 맞춰 프롬프트를 계속 고치면 특정 문구에만 강한 시스템이 될 수 있습니다. 운영에서 새로 발견한 실패를 추가하되 실제 사용자 정보를 제거하고 재현에 필요한 조건을 보존합니다.
모델 변경은 같은 조건에서 비교합니다
모델, 프롬프트와 도구를 동시에 바꾸면 개선 원인을 구분하기 어렵습니다. 변경 단위를 나누고 동일한 데이터·권한·실행 예산으로 비교하세요. 결과가 들쭉날쭉한 업무는 반복 실행의 변동도 확인합니다. 성공률이 올라가도 특정 권한 오류나 중복 처리가 늘었다면 별도의 출시 차단 기준이 필요합니다.
평가 환경의 원상 복구도 중요합니다. 첫 실행이 예약을 바꾼 상태에서 두 번째 모델을 평가하면 입력 조건이 달라집니다. 각 실행 전에 같은 데이터로 초기화하거나 독립된 시험 계정을 사용하고, 도구 장애를 재현할 때도 같은 실패 조건을 적용하세요.
배포 전에 남겨야 할 평가 기록
- 평가 데이터와 채점 기준의 버전
- 정상·모호한 입력·권한·장애별 결과
- 작업당 시간·호출 비용·재시도 횟수
- 사람이 확인한 오류와 자동 채점의 불일치
- 변경을 되돌릴 조건과 운영 담당자
참고 자료
자료 확인일: 2026.10.07 · 본문의 적용 예시와 체크리스트는 참고 자료를 바탕으로 정리한 실무 제안입니다.
기술 동작은 아래 공식 문서를 참고했습니다. 적용 조건과 지원 버전은 프로젝트 환경에 맞게 확인하세요.
작성팀 소개
TOPPING 기술팀 · 개발 · 아키텍처 · QA
웹·앱·백엔드·IoT·데이터 연동을 수행하는 TOPPING의 개발·아키텍처 담당 팀입니다. 시스템 구조 설계, 기술 검수, 인수인계와 운영 안정화를 담당합니다.
