개념
에이전트 평가가 단일 응답 평가와 다른 점
모듈 18b가 LLM 애플리케이션 평가를 다뤘고, 모듈 38이 그 평가를 파이프라인과 배포 게이트로 운영하는 법을 다뤘다. 에이전트는 거기에 세 가지를 더한다.
| 추가되는 것 | 평가에서 생기는 문제 |
|---|---|
| 다단계 | 10단계 중 3단계에서 틀렸는데 최종 실패 한 줄로만 보고된다 |
| 도구 호출 | 외부 상태를 바꾸므로 실패가 되돌릴 수 없고, 재실행이 같은 조건이 아니다 |
| 상태 | 앞 단계의 결과가 뒤 단계의 입력이라 오류가 누적·증폭된다 |
세 번째가 특히 성질이 다르다. 단일 응답에서 정확도 90%는 "10번 중 1번 틀림"이지만, 10단계 에이전트에서 단계별 90%는 전체 성공률이 약 35% 가 된다. 단계 수가 성공률을 기하급수적으로 깎는다는 사실이 에이전트 평가의 출발점이다. 그래서 "모델이 좋으니 에이전트도 좋을 것"이라는 추론이 깨진다.
트레이스 기반 평가 — 채점 단위를 단계로 내린다
최종 결과만 보는 평가(end-to-end)는 "되는가"를 알려주고, 트레이스 평가는 "어디서 깨지는가"를 알려준다. 둘 다 필요하지만 결함을 고치는 데 쓰이는 것은 후자 다.
트레이스에서 기록해야 하는 최소 항목은 이렇다.
단계마다
의도 이 단계에서 무엇을 하려 했는가 (계획·추론 요약)
행동 호출한 도구 이름과 인자
관측 도구가 반환한 것 (요약·해시·길이)
상태 변화 외부 시스템에 생긴 변화 (있으면 되돌림 가능성 표시)
판정 이 단계가 올바른 진행이었는가
비용·지연 토큰·호출 수·소요 시간판정 칸이 핵심이다. 단계 판정을 다섯 가지 실패 유형 으로 분류해 두면 보고가 바로 행동으로 이어진다.
| 실패 유형 | 전형 | 고치는 쪽 |
|---|---|---|
| 계획 실패 | 필요한 단계를 건너뛰거나 순서를 뒤집음 | 프롬프트·계획 구조 |
| 도구 선택 실패 | 맞는 도구가 있는데 다른 도구를 부름 | 도구 설명·이름·개수 |
| 인자 실패 | 도구는 맞는데 인자 형식·값이 틀림 | 스키마·검증·예시 |
| 관측 해석 실패 | 도구 응답을 잘못 읽고 다음 단계로 감 | 응답 형식·오류 메시지 |
| 종료 실패 | 다 했는데 안 멈추거나, 덜 했는데 멈춤 | 종료 조건·완료 판정 |
이 분류가 있으면 "에이전트 정확도 62%"가 "인자 실패가 전체 실패의 절반, 도구 스키마 검증을 넣으면 줄어들 것"으로 바뀐다. 전자는 보고서에 쓰이고 후자는 백로그에 쓰인다.
실패 지점 특정 규칙 을 하나 정해 두는 것이 좋다. 트레이스에서 처음으로 올바른 진행에서 벗어난 단계 를 그 실행의 실패 지점으로 기록한다. 그 뒤 단계의 오류는 파생이므로 따로 세지 않는다. 이 규칙이 없으면 한 번의 실패가 여러 건으로 부풀어 통계가 왜곡된다.
과업 성공률 — 판정 기준을 먼저 정한다
에이전트의 "성공"은 정의하기 전까지 존재하지 않는다. 세 종류를 구분해 쓴다.
결과 기준 최종 상태가 기대와 같은가 (DB 레코드, 파일, 티켓 상태)
→ 가장 믿을 만하다. 가능하면 이걸 쓴다
경로 기준 필수 단계를 모두 거쳤는가, 금지 행동을 하지 않았는가
→ 되돌릴 수 없는 작업·규정 준수에 필요
응답 기준 사용자에게 준 답이 맞는가
→ 판정자 필요. 모듈 38 레슨 3 으로 보정한 뒤 쓴다실무에서는 결과 기준과 경로 기준을 AND로 묶는 것 이 맞다. 결과가 맞아도 금지된 경로를 지났으면 통과가 아니다. 환불 처리를 성공했지만 승인 단계를 건너뛴 실행은 실패로 세야 한다.
pass@k 와 pass^k — 기호 하나가 뜻을 뒤집는다
둘 다 같은 과업을 k 번 독립 실행하고 결과를 묶는 지표인데, 묶는 방식이 반대다.
| 지표 | 정의 | 무엇을 재는가 |
|---|---|---|
pass@k | k 번 중 적어도 한 번 성공할 확률 | 탐색 능력. 여러 번 시도할 여유가 있을 때의 상한 |
pass^k | k 번이 모두 성공할 확률 | 신뢰성. 매번 같은 결과를 내는가 |
pass@k는 코드 생성 평가에서 널리 쓰였다(HumanEval 계열). 사람이 후보를 보고 고를 수 있는 상황이라면 타당한 지표다. 반면 사용자 요청을 자동
처리하는 에이전트에서는 pass^k가 제품 지표 다. 고객 응대 에이전트가 10번 중 한 번 잘못된 환불을 처리하면, "9번은 맞았다"는 위안이 되지 않는다.
단일 성공률이 같아도 결론이 갈린다
과업 A pass@1 = 0.92 pass^5 = 0.66
과업 B pass@1 = 0.92 pass^5 = 0.88
A 는 실행마다 흔들린다 → 자동화 범위를 좁히고 사람 확인을 넣는다
B 는 안정적이다 → 자동 처리 대상으로 올릴 수 있다도구-사용자 상호작용 벤치마크 연구에서 보고된 것이 바로 이 격차다. 단일 시행 성공률이 상당히 높은 모델도 같은 과업을 여러 번 반복시키면 전부 성공하는 비율이 크게 떨어졌다. 수치는 모델·판마다 다르니 그대로 인용하지 말고 우리 과업에서 직접 재는 것 이 이 지표를 쓰는 법이다.
모듈 38 레슨 4가 참고 자료에서 이 두 지표를 소개했고, 모듈 18b 레슨 5가 반복 실행과 통과율 개념을 다뤘다. 이 레슨이 보태는 각도는 지표를
자동화 범위 결정에 연결하는 것 이다. pass^k는 보고용 숫자가 아니라 "이 과업을 사람 확인 없이 돌릴 수 있는가"의 판정 입력이다.
자동화 범위 결정 규칙 예시
pass^5 `≥ 0.95` 자동 처리
0.80 ~ 0.95 자동 처리 + 사후 표본 검토
0.80 미만 사람 승인 필수 또는 범위에서 제외
되돌릴 수 없는 작업 pass^k 와 무관하게 사람 승인마지막 줄이 중요하다. 되돌릴 수 없는 작업은 신뢰성 숫자로 면제되지 않는다. 레슨 3의 권한 경계 논의와 같은 결론이다.
도구 호출 정확성 — 네 층으로 쪼갠다
"도구를 잘 쓰는가"를 한 숫자로 재면 개선 지점이 안 보인다.
| 층 | 재는 것 | 전형적 결함 |
|---|---|---|
| 선택 | 필요한 도구를 골랐는가 | 도구 수가 많아질 때 급격히 나빠진다 |
| 인자 | 인자 이름·타입·필수값이 맞는가 | 날짜 형식, 단위, 식별자 혼용 |
| 순서 | 선행 조건이 있는 호출의 순서 | 조회 없이 수정, 승인 없이 실행 |
| 과호출 | 불필요한 호출·중복 호출 | 같은 조회를 반복해 비용·지연 증가 |
선택 정확도는 도구 개수의 함수 다. 도구를 20개 붙인 에이전트의 선택 실패는 모델 문제가 아니라 설계 문제일 가능성이 크다. QA가 제기할 질문은 "이 도구 설명이 다른 도구와 구별되는가"와 "역할별로 도구 집합을 쪼갤 수 있는가"다.
과호출을 지표에 넣는 이유는 비용과 지연이 품질이기 때문이다.
비용·지연을 같은 보고에 올린다
에이전트는 성공률을 올리는 방법이 하나 더 있다 — 더 많이 시도하는 것 이다. 그래서 성공률만 보면 반드시 비용이 새어 나간다.
한 과업당 함께 보고할 것
성공률(결과+경로) / pass^k
평균·p95 단계 수 / 평균·p95 도구 호출 수
평균·p95 토큰 / 평균·p95 소요 시간
실패 유형 분포 / 되돌릴 수 없는 작업 발생 건수p95를 보는 이유는 평균이 꼬리를 감추기 때문이다. 평균 8단계인 에이전트가 p95에서 40단계를 쓰고 있으면, 일부 요청이 루프에 빠진 것이다. 루프는 성공률 지표에 거의 안 나타나고 비용 청구서에 먼저 나타난다. 단계 수 상한과 상한 도달 시의 행동(중단·사람 전달)을 요구사항으로 적고, 그 동작을 시험한다.
벤치마크를 쓸 때의 함정
공개 벤치마크는 모델을 비교 하는 데 쓰는 도구이고, 우리 제품이 쓸 만한지 판정 하는 도구가 아니다. 세 가지 함정이 있다.
1) 오염(contamination) — 벤치마크 과업과 정답이 학습 데이터에 들어갔을 가능성이다. 오염된 벤치마크 점수는 능력이 아니라 기억을 재고, 외부에서 확인할 방법이 제한적이다. 신호는 이런 것들이다.
오염 의심 신호
과업을 살짝 변형(이름·숫자·순서 변경)하면 점수가 크게 떨어진다
최신 과업보다 오래된 과업에서 유독 잘한다
풀이 과정 없이 정답 형태만 정확하다변형 검사는 레슨 3의 메타모픽 관계와 같은 도구다. 의미를 바꾸지 않는 변형에 점수가 크게 흔들리면 그 점수를 신뢰하지 않는다.
2) 과적합 — 공개 리더보드가 목표가 되면 그 벤치마크에 맞춘 조정이 쌓인다. 벤치마크 점수는 오르고 우리 과업 성능은 그대로인 상태가 실제로 일어난다. 그래서 우리 과업으로 만든 비공개 평가 세트 가 반드시 함께 있어야 한다.
3) 과업 분포 불일치 — 벤치마크의 과업 길이·도구 종류·오류 상황 비율이 우리 제품과 다르다. 특히 실패 경로의 비율 이 다르다. 벤치마크는 대개 정상 경로 중심인데, 운영에서는 권한 없음·데이터 없음·외부 장애가 상당 비율이다.
벤치마크의 올바른 쓸모는 셋이다. (1) 모델 후보를 줄이는 1차 필터, (2) 평가 설계의 참고(과업 구성·판정 방식), (3) 우리 지표의 기준선. 최종 판정은 언제나 자사 과업 세트로 한다.
평가 세트를 운영 가능하게 만들기
에이전트 평가는 비싸다. 한 과업을 k 번 돌리면 비용이 k 배다. 그래서 층을 나눈다 — 모듈 38 레슨 4의 세 층 파이프라인과 같은 구조다.
PR 단위 핵심 과업 10~20개, k=1, 결과+경로 판정
주기 회귀 전체 과업 세트, k=3~5, pass^k 와 실패 유형 분포
릴리스 전 전체 + 되돌릴 수 없는 작업 시나리오, k=5 이상, 비용·지연 포함과업 세트는 운영 로그에서 자란다. 실패한 실제 요청을 익명화해 과업으로 승격하고, 실패 유형 분포가 치우치지 않도록 정상·경계·실패 경로를
의도적으로 섞는다. 환경은 되돌릴 수 있어야 한다 — 샌드박스 도구와 초기화 가능한 상태가 없으면 k 번 반복이 불가능하다. 평가 환경 설계가 평가
설계의 절반이다.
실무에서 왜 필요한가
에이전트를 제품에 넣을 때 실제로 결정해야 하는 것은 "쓸까 말까"가 아니라 "어디까지 자동으로 하게 둘까" 다. 그 결정에는 숫자가 필요하고, 단일
실행 성공률은 그 숫자가 되지 못한다. pass^k와 실패 유형 분포, 되돌릴 수 없는 작업의 발생 건수가 범위를 정하는 입력이다.
디버깅 비용도 다르다. 트레이스 판정이 없는 팀은 에이전트 실패를 "프롬프트를 고쳐 보자"로 대응하고, 같은 실패가 반복된다. 실패 유형 분포가 있으면 인자 실패는 스키마 검증으로, 도구 선택 실패는 도구 집합 분리로, 종료 실패는 완료 판정으로 간다. 고치는 쪽이 지표에서 바로 나온다.
그리고 이것이 QA의 영역인 이유는 분명하다. 모델을 고르는 것은 ML 쪽이지만, 과업을 정의하고 성공을 판정하고 범위를 제한하는 것 은 테스트 설계 그 자체다. 모듈 39 레슨 8이 에이전트 실행 플랫폼 쪽을 다뤘고, 이 레슨은 그 위에서 돌아가는 에이전트의 품질을 판정한다.