AI 에이전트의 성공률이 80%에서 87%로 올랐다. 그런데 한 종류의 작업에서는 오히려 더 자주 실패했다면, 새 버전이 좋아졌다고 보고해도 될까? 전체 점수만 보면 놓치기 쉬운 변화가 있다. 에이전트가 달라진 것과 에이전트에게 들어온 일이 달라진 것을 나눠야 한다.
앞선 무실패 표본 글에서는 시험 횟수와 불확실성을 다뤘다. 이번 AI Agent Fast Learning은 시험한 작업의 구성으로 질문을 옮긴다. 전체 관측값, 작업군별 결과, 같은 구성비로 다시 계산한 점수가 각각 무엇을 말하는지 살펴본다. 아래 A·B와 모든 실행 건수는 학습용으로 만든 합성 데이터다.
80%에서 87%로 오른 결과표의 안쪽
가상의 공개 문서 답변 에이전트를 생각해 보자. 요청을 입력 조건에 따라 두 작업군으로 미리 나눈다. 한 문서의 명시된 근거로 답할 수 있는 단일 근거 작업과, 두 문서의 내용을 대조해야 하는 근거 대조 작업이다. 이 예시에서는 모든 요청이 정확히 한 작업군에만 속한다.
성공 기준도 먼저 정했다고 가정한다. 필요한 답과 근거가 맞아야 통과하고, 자료가 충돌해 결론을 낼 수 없는 경우에는 충돌을 밝히고 단정을 보류해야 통과한다. 두 버전은 같은 채점 기준을 썼으며, 예정된 실행은 모두 판정되어 미실행·시간초과·판정 불가가 없다고 둔다. 실제 운영에서는 이 상태들을 따로 기록해야 한다.
| 작업군 | 기준 A: 성공/전체 | 후보 B: 성공/전체 |
|---|---|---|
| 단일 근거 | 72/80 = 90% | 855/950 = 90% |
| 근거 대조 | 8/20 = 40% | 15/50 = 30% |
| 전체 | 80/100 = 80% | 870/1,000 = 87% |
A는 100건 중 80건, B는 1,000건 중 870건에 성공했다. 그러나 단일 근거 작업의 성공률은 90%로 같고, 근거 대조 작업은 40%에서 30%로 10%포인트 낮아졌다. 전체 7%포인트 상승만 보고 두 작업이 모두 좋아졌다고 읽으면 틀린다.
차이는 구성비에 있다. A에서는 단일 근거 작업이 전체의 80%였고, B에서는 95%였다. 이 합성 예시에서 더 높은 성공률을 보이는 작업군이 B의 결과표를 훨씬 많이 차지한다. 따라서 전체 점수 상승에는 무슨 일을 얼마나 받았는가가 섞여 있다.
전체 평균은 두 가지 변화에 함께 움직인다
전체 성공률은 각 작업군의 성공률에 그 작업군의 비중을 곱해 더한 값이다. 서로 겹치지 않고 전체를 빠짐없이 나눈 두 작업군이라면 다음처럼 계산할 수 있다.
전체 성공률 = 단일 근거 비중 × 그 성공률 + 근거 대조 비중 × 그 성공률
- A: 0.80 × 90% + 0.20 × 40% = 80%
- B: 0.95 × 90% + 0.05 × 30% = 87%
작업군 안의 성공률이 달라져도 전체 값이 바뀌고, 작업군의 비중만 달라져도 전체 값이 바뀐다. Google의 Good Data Analysis는 데이터를 하위 집단으로 나누어 지표를 보고, 실험군이나 시점을 비교할 때 구성비 변화인 mix shift를 확인하라고 설명한다. 이 글의 예시는 그 원리를 에이전트 평가에 적용한 것이다.
전체 87%가 잘못 계산된 숫자는 아니다. 이 합성 예시에서 설정한 1,000건 가운데 성공한 비율을 정확히 말한다. 다만 다른 구성을 가진 A의 80%와 비교해 시스템 개선의 증거라고 바로 쓰기에는 정보가 부족하다. 운영 현황과 버전 비교는 서로 다른 질문이다.
같은 80:20 구성비로 다시 계산해 보자
버전을 비교할 기준으로 단일 근거 80%, 근거 대조 20%를 결과를 보기 전에 정했다고 가정하자. 이제 두 버전의 작업군별 관측 성공률에 동일한 가중치를 적용한다.
- 기준 A: 0.80 × 90% + 0.20 × 40% = 80%
- 후보 B: 0.80 × 90% + 0.20 × 30% = 78%
같은 구성을 기준으로 계산하면 후보는 78%로 낮다. 이 계산은 B의 1,000건을 다시 실행한 결과가 아니다. 이미 주어진 작업군별 비율을 공통 기준으로 재집계한 값이다. 원래 관측값 87%를 지우고 78%로 바꿔 써서도 안 된다. 두 값의 질문과 계산 방식을 함께 표시한다.
80:20이 올바른 평가의 표준 비율이라는 뜻은 아니다. 실제로 맡길 업무의 분포, 이전에 합의한 비교 기준, 평가 목적에 따라 정하고 근거를 남긴다. 새 결과가 좋아 보이도록 비율을 고르면 또 다른 선택 편향이 된다. 기준을 변경할 필요가 생겼다면 변경 이유와 버전을 적고, 비교할 양쪽 결과를 같은 기준으로 다시 계산한다.
가중치를 맞춰도 아직 남는 차이
작업군 이름이 같다고 내부 조건까지 같은 것은 아니다. A의 근거 대조 작업은 짧은 두 문서를 읽고, B는 긴 문서 열 개를 검색한 뒤 두 개를 골라야 했다면 비중을 맞추는 것만으로 공정한 비교가 되지 않는다. 문서 길이, 검색 범위, 도구 권한, 실행 예산, 채점기 버전도 확인해야 한다.
또한 표의 40%와 30%는 각각 20건과 50건에서 나온 관측값이다. 이 차이만으로 실제 성공확률이 확실히 낮아졌거나 코드 수정이 하락의 원인이라고 단정하지 않는다. 표본 선택과 불확실성, 반복 실행 간 관계를 확인해야 한다. 고정 가중치는 정의한 작업군의 구성비를 맞출 뿐, 불확실성과 모든 조건 차이를 제거하지 않는다.
새 버전의 개선을 검증하려면 가능하면 같은 고정 사례에 두 버전을 적용하고, 원문·도구 조건·채점 기준·예산을 맞춘다. 어떤 사례가 성공에서 실패로 바뀌었는지는 수정 전후 결과표로 확인한다. 이번 집계는 그 검사를 시작할 위치를 보여 주는 진단이다.
평가 세트에는 서로 다른 목적이 있다
실사용에서 자주 오는 작업을 대표하려는 표본과, 드물지만 위험한 실패를 집중적으로 찾으려는 도전 세트는 목적이 다르다. 위험 사례를 많이 넣은 도전 세트의 평균을 실제 운영 성공률처럼 소개하면 안 된다. 반대로 운영 비중이 낮다는 이유로 중요한 작업의 실패를 전체 평균 속에 묻어도 안 된다.
Anthropic의 에이전트 평가 안내는 행동해야 할 경우와 하지 말아야 할 경우를 함께 담는 균형 잡힌 문제 구성을 설명하며, 평가가 실제 사용 패턴에서 멀어질 수 있다는 점도 짚는다. 여기서 균형은 모든 작업군을 무조건 같은 수로 넣으라는 뜻이 아니다. 무엇을 확인하려고 구성한 세트인지 드러내는 것이 먼저다.
- 운영 관측값: 그 기간에 들어온 전체 요청 수와 작업군 비중을 함께 적는다.
- 고정 비교 점수: 공통 사례나 공통 가중치, 기준 버전을 명시한다.
- 위험 사례 결과: 별도 작업군의 성공·실패·판정 불가와 구체적 실패를 보여 준다. 평균으로 통과 여부를 대신하지 않는다.
여러 축으로 작업을 나눌 때는 중복도 주의한다. “긴 문서”와 “근거 충돌”에 동시에 속하는 요청은 각 진단 화면에서 볼 수 있지만, 두 집단의 성공 건수를 그냥 더해 전체 성공으로 세면 이중 집계가 된다. 전체 재집계용 분할과 원인 탐색용 필터를 구분한다.
보고서에 함께 놓을 세 줄
다음은 위 합성 데이터만으로 쓴 가상의 보고 문장이다.
- 관측: 기준 A는 80/100건, 후보 B는 870/1,000건에 성공했다. 전체 성공률은 80%에서 87%로 올랐다.
- 구성: 단일 근거 작업의 비중이 80%에서 95%로 늘었고, 근거 대조 작업의 관측 성공률은 40%에서 30%로 낮아졌다.
- 같은 기준: 사전에 정한 80:20 가중치를 적용한 점수는 A 80%, B 78%다. 조건을 맞춘 사례 비교와 표본 불확실성 확인 전에는 개선·악화를 확정하지 않는다.
이 보고를 받은 사람은 “점수가 올랐다”는 인상과 함께, 근거 대조 작업을 다시 확인해야 한다는 다음 행동도 얻는다. 다음 평가표에는 전체 성공률 옆에 작업군별 성공 수/전체 수, 구성비, 공통 비교 기준을 놓자. 더 많은 성공이 어떤 일에서 나왔는지 보여야, 맡길 범위를 판단할 수 있다.
자료와 검증 범위
자료 확인일: 2026년 10월 10일. Google for Developers의 Good Data Analysis 중 Slice your data와 비율·불확실성 지침, Anthropic의 Demystifying evals for AI agents(2026년 1월 9일)를 참조했다. 작업군·수치·보고 문장·80:20 비교 기준·도식은 이 글의 교육용 합성 예시와 설계 제안이다. 로컬 Python 표준 라이브러리로 합계·구성비·가중평균을 정확 분수 계산으로 검산했다. 실제 에이전트 실행, 운영 성능 측정, 유료 API 사용, 고객 데이터 활용, 통계적 유의성 검정은 하지 않았다.