12번 실행해 6번 성공한 두 에이전트가 있다고 하자. 성공률은 둘 다 50%지만, 맡길 수 있는 일까지 같지는 않다. 한쪽은 특정 과업에서만 세 번 모두 성공하고, 다른 쪽은 모든 과업에서 한두 번씩 성공했다면 다음에 고칠 곳부터 달라진다.
오늘 AI Agent Fast Learning은 검증된 완료 1건의 비용, 완료까지 걸린 시간에 이어 반복 실행의 신뢰성을 다룬다. 목표는 “여러 번 중 한 번 성공”과 “정한 횟수 모두 성공”을 구분하고, 과업별 결과표에서 다음 점검 대상을 찾는 것이다. 아래 A·B와 숫자는 모두 학습용 합성 데이터다.
과업 하나와 실행 한 번을 나눠 세자
가상의 업무는 공개 제품 문서를 읽고 질문에 답하며 근거 위치를 제시하는 것이다. 질문과 기준 문서, 통과 조건을 묶은 것을 과업(task)이라 하고, 그 과업을 처음부터 끝까지 수행한 한 번을 실행(trial)이라 하자. 한 실행 안에서 검색을 세 번 했다고 세 번의 독립 실행이 되는 것은 아니다.
이번 표는 같은 네 과업을 A와 B에 각각 세 번씩 배정한 상황이다. 실행마다 대화 이력과 임시 산출물을 초기화하고 같은 문서 버전·도구 조건·예산을 제공했다고 가정한다. 검증 기준은 필수 답변 항목과 근거 일치다. 성공 뒤에도 남은 평가 실행을 모두 진행한 완전한 표이며, 미실행·판정 불가·환경 오류는 없다고 둔다. 이는 계산을 단순하게 만든 가정이지 실제 환경을 시험한 결과가 아니다.
같은 50% 안에 다른 실패가 들어 있다
| 과업 | A: 1·2·3회 | B: 1·2·3회 |
|---|---|---|
| 문서 질문 1 | 성공 · 성공 · 성공 | 성공 · 성공 · 실패 |
| 문서 질문 2 | 성공 · 성공 · 성공 | 실패 · 성공 · 성공 |
| 문서 질문 3 | 실패 · 실패 · 실패 | 성공 · 실패 · 실패 |
| 문서 질문 4 | 실패 · 실패 · 실패 | 실패 · 성공 · 실패 |
A는 3 + 3 + 0 + 0 = 6회, B는 2 + 2 + 1 + 1 = 6회 성공했다. 두 방식 모두 전체 12회 중 6회이므로 실행 단위 성공률은 50%다. 이제 같은 표를 과업 단위로 다시 읽어 보자.
| 이 표에서 세는 것 | A | B |
|---|---|---|
| 전체 실행 중 성공 | 6/12 = 50% | 6/12 = 50% |
| 3회 중 한 번 이상 성공한 과업 | 2/4 = 50% | 4/4 = 100% |
| 3회 모두 성공한 과업 | 2/4 = 50% | 0/4 = 0% |
A에서는 질문 3·4의 입력, 필요한 도구, 채점 조건부터 살펴볼 이유가 생긴다. B에서는 같은 질문에서 성공과 실패가 갈린 실행 기록을 비교할 수 있다. 다만 이 표만으로 A가 두 과업을 영원히 못 푼다거나 B의 오류가 무작위라고 결론 내릴 수는 없다. 세 번의 결과가 알려 주는 것은 이번에 관찰한 패턴뿐이다.
pass@k와 pass^k는 서로 다른 질문이다
pass@k는 같은 과업을 k번 시도했을 때 적어도 한 번 성공할 확률을 묻는다. pass^k는 k번 모두 성공할 확률을 묻는다. τ-bench 원 논문은 과업 안의 실행이 독립이고 같은 분포를 따른다는 조건에서 이 확률을 정의하고, 과업들에 걸쳐 평균 낸다. 여기서 “같은 분포”는 서로 다른 모든 과업의 성공 확률이 같다는 뜻이 아니다. τ-bench 원 논문, 3절
위 표는 과업마다 정확히 3회의 합성 결과만 두었다. 따라서 “한 번 이상 성공한 과업 비율”과 “모두 성공한 과업 비율”을 직접 셌다. 각각 pass@3·pass^3가 묻는 사건에 대응하는 이 표의 관측 비율이다. 실제 확률을 알아낸 값이나 다음 실행의 보장으로 쓰면 안 된다. 과업마다 3회보다 많은 표본을 모아 3회 성공 확률을 추정하는 계산과도 구분해야 한다.
HumanEval 연구는 과업마다 n개의 결과 중 성공 c개를 얻었을 때, k개를 고르는 조합을 이용해 pass@k를 추정한다. 관측 성공률을 확률처럼 대입한 간단한 계산에는 추정 편향이 생길 수 있음을 설명한다. 실험 도구의 pass@k를 비교할 때는 k만 보지 말고 과업별 표본 수 n과 추정 방식도 확인하자. Evaluating Large Language Models Trained on Code, 2.1절·부록 A
평균 성공률을 세제곱하면 왜 안 될까
한 과업의 진짜 성공 확률이 매번 p이고, 세 실행이 서로 독립이라고 가정할 때는 세 번 모두 성공할 확률이 p × p × p다. 한 번 이상 성공할 확률은 1 − (1 − p)³이다. 설명용으로 p = 0.8을 넣으면 각각 51.2%와 99.2%다. 이것은 가정한 확률 모형의 계산이지 위 A·B에서 측정한 수치가 아니다.
A·B의 전체 관측 성공률 50%를 p로 넣어 “모두 성공할 확률은 12.5%”라고 쓰면 두 문제를 건너뛴다. 우선 표본에서 얻은 비율은 알려진 참확률이 아니다. 또한 과업마다 난이도와 성공 확률이 다를 수 있다. 과업별 확률을 세제곱한 뒤 평균 내는 것과, 전체 평균을 먼저 세제곱하는 것은 일반적으로 같지 않다.
독립성도 기록 양식 하나로 생기지 않는다. 첫 실패 뒤 고친 프롬프트를 다음 실행에 넘겼다면 같은 조건의 반복이 아니다. 이전 답을 캐시에서 가져오거나 같은 도구 장애가 여러 실행에 걸쳐 지속됐다면 결과가 서로 연결될 수 있다. 초기화는 이런 영향을 줄이는 방법이지 독립성을 증명하는 절차는 아니다. 반복 간격·실행 순서·공유 서비스 장애도 함께 기록해야 한다.
성공한 답이 있다는 것과 골라 쓴다는 것
B의 “3회 중 한 번 이상 성공”이 100%여도 사용자에게 나간 답변이 100% 정확했다는 뜻은 아니다. 세 후보 가운데 성공한 답이 있다는 사실은 사후 채점으로 확인할 수 있다. 실제 서비스에서는 어느 후보가 맞는지 골라내는 장치가 필요하다. 선택기가 오답을 고르거나 실패한 후보를 먼저 노출하면, 후보 집합의 성적과 사용자가 받은 결과가 달라진다.
여러 코드 후보를 테스트해 통과한 하나를 고르는 업무라면 한 번 이상 성공이라는 질문이 유용하다. 매번 답변 하나를 바로 전달하는 업무라면 반복했을 때 계속 성공하는지도 중요하다. Anthropic의 평가 안내 역시 두 지표를 제품 요구에 맞춰 해석하도록 설명한다. Anthropic: Demystifying evals for AI agents
이 글의 반복 평가는 격리된 시험이다. 실패한 실제 발송이나 주문을 무조건 세 번 재시도하라는 운영 규칙이 아니다. 쓰기 작업은 실제 결과 확인과 중복 방지, 승인 범위를 따로 지켜야 한다. 재시도 정책을 평가하려면 첫 시도·재시도·선택·검증을 포함한 전체 절차를 하나의 시스템으로 두고, 사용자에게 전달된 최종 결과의 성공률과 총비용·시간을 다시 측정한다.
다음 평가에서 남길 작은 결과표
- 과업: 과업 ID, 질문·근거 문서 버전, 기대 결과와 필수 통과 조건. 서로 다른 과업 수를 적는다.
- 실행: 과업별 실행 ID와 순서, 시작 시각, 모델·프롬프트·도구·채점 기준 버전, 예산과 초기화 조건을 적는다.
- 판정: 성공·실패와 근거, 환경 오류·판정 불가·미실행을 구분한다. 성공한 사례만 남기지 않는다.
- 집계: 전체 실행 성공 수와 분모, 과업별 성공 횟수, 한 번 이상 성공한 과업 수, 모두 성공한 과업 수를 함께 둔다.
- 판단: 같은 과업에서 반복되는 실패인지, 특정 실행 조건에서 함께 생긴 실패인지 읽고 다음 수정 한 가지를 정한다.
판정 불가나 미실행이 끼면 세 번을 모두 관찰했다는 전제가 깨진다. 그런 과업을 몰래 지우거나 성공으로 채우지 않는다. 예정 실행 수·판정 가능한 실행 수·제외 이유를 함께 보고하고, 어떤 과업 집합을 분모로 썼는지 밝힌다. “모두 성공”은 k회 모두 성공 증거가 있어야 인정할 수 있다. 반면 이미 한 번의 성공을 확인한 과업은 나머지가 미확인이어도 “한 번 이상 성공” 사건 자체는 확인된 것이므로 두 집계의 증거 조건을 구분한다.
표본을 늘릴 때도 같은 네 과업을 더 반복하는 일과 새로운 과업을 추가하는 일을 나눠 결정하자. 전자는 그 과업에서 결과가 얼마나 흔들리는지 살피고, 후자는 다루는 문제의 폭을 넓힌다. 네 과업의 합성 표는 계산을 익히는 용도다. 작은 표의 100%를 운영 신뢰성으로 옮길 수는 없다.
다음 보고서에는 “성공률 50%” 뒤에 한 줄을 더 붙여 보자. “네 과업을 세 번씩 평가했고, A는 두 과업에서 세 번 모두 성공했다. B는 네 과업 모두에서 한 번 이상 성공했지만 세 번 모두 성공한 과업은 없었다.” 비용과 기다린 시간이 같더라도, 이 한 줄에 따라 먼저 고칠 부분이 달라진다.
자료와 검증 범위
자료 확인일: 2026년 10월 9일. τ-bench는 arXiv:2406.12045의 v1(2024년 6월) 3절, HumanEval은 arXiv:2107.03374(2021년) 2.1절과 부록 A, Anthropic 글은 2026년 1월 9일 공개본을 참조했다. 특정 최신 모델·SDK의 성능이나 지원 기능을 비교한 글이 아니다. 결과표·도식·기록 양식은 이 글의 합성 예시와 설계 제안이다. 로컬 Python 표준 라이브러리로 표의 건수·비율과 가정한 확률 계산을 확인했으며 실제 에이전트 실행, 유료 API 호출, 고객 데이터 사용은 하지 않았다.