AI 에이전트의 실력은 같은 일을 다시 맡길 때 드러난다

τ-bench의 pass@k와 pass^k를 구분하고, 반복 실행·완료 상태·승인 절차·평가 버전을 함께 기록해 AI 에이전트의 업무 신뢰성을 검증하는 방법을 살펴본다.

표지는 GPT Image 2로 생성한 개념 일러스트다. 실제 제품 화면이나 벤치마크의 측정 결과를 그린 도표가 아니다.

팀의 주간 보고서를 정리하는 에이전트가 시연에서 일을 끝냈다고 하자. 자료를 읽고, 지정한 양식으로 문서를 만들고, 정해진 폴더에 저장했다. 이제 같은 일을 다음 주에도 맡길 수 있을까. 시연 영상을 다시 보는 것으로는 답하기 어렵다. 담당자가 바뀌거나 요청의 순서가 달라졌을 때도 필요한 확인을 거쳐 같은 완료 조건에 도달하는지 살펴야 한다.

이때 재실행의 목적을 먼저 정해야 한다. 여러 후보를 만들어 그중 좋은 결과 하나를 고르는 일과, 매번 들어오는 업무를 안정적으로 처리하는 일은 서로 다른 평가가 필요하다. 초안 작성에서는 후보를 더 만드는 것이 유용할 수 있다. 이미 공유 폴더에 파일을 올리는 업무에서는 실패한 실행의 흔적과 중복 산출물까지 사람의 일이 된다.

에이전트 도입을 검토하는 팀에 필요한 것은 성공 사례를 더 모으는 일만이 아니다. 같은 업무를 다시 맡겼을 때 무엇이 달라지고, 그 차이를 누가 감당하는지 확인할 자료다. 반복 실행을 평가하는 pass^k는 이 질문을 구체화하는 출발점이 된다.

성공한 결과를 찾는 능력과 매번 성공하는 능력

2024년 발표된 τ-bench는 사용자와 대화하고 업무용 도구를 쓰는 에이전트를 평가하면서 pass^k를 제안했다. pass@k는 같은 과제를 독립적으로 k번 시도했을 때 적어도 한 번 성공할 확률을, pass^k는 k번 모두 성공할 확률을 과제별로 구한 뒤 평균한다. 두 지표는 묻는 질문부터 다르다. τ-bench 원 논문, 평가 지표 정의

차이를 보기 위해 하나의 과제를 5번 실행해 4번 성공한 가상의 기록을 생각해 보자. 아래 숫자는 특정 모델의 성적이 아니라, 이 기록에서 두 번의 실행을 뽑는 조합을 직접 센 설명용 예시다.

실패가 하나뿐이므로 어떤 두 실행을 골라도 성공은 포함된다. 하지만 두 실행이 모두 성공하려면 실패한 실행을 피해야 한다. 같은 기록에서도 ‘좋은 결과 하나를 얻을 가능성’은 높게 보이고 ‘두 번 모두 제대로 끝낼 가능성’은 낮게 보인다. 이 100% 역시 다음 실행의 성공을 보장하는 값이 아니다. 작은 표본에서 계산한 추정치이며, 관측하지 않은 실패는 남아 있다.

τ-bench의 추정식도 이 조합을 이용한다. 한 과제를 n번 실행해 c번 성공했다면 pass^k는 C(c,k)/C(n,k), pass@k는 1-C(n-c,k)/C(n,k)로 추정하고 과제별 값을 평균한다. 여기서 C(n,k)는 n개 중 k개를 고르는 조합의 수다. n >= k여야 하며 성공 횟수가 k보다 적으면 모두 성공하는 조합은 없다. τ-bench 원 논문의 추정식

실무에서는 과제별 기록을 보존하는 일이 중요하다. 전체 실행의 성공률을 먼저 합친 뒤 그 수를 거듭제곱하면, 어떤 과제는 항상 성공하고 어떤 과제는 계속 흔들리는 차이가 가려진다. 쉬운 업무에서 얻은 많은 성공이 자주 틀리는 업무를 가려서는 안 된다. 검토 대상은 평균 점수와 함께 남겨 둔 과제별 실패 분포다.

무엇을 성공으로 셀지 먼저 정한다

반복 횟수를 늘리기 전에 통과 기준부터 확인해야 한다. 보고서가 생성됐다는 것만 성공으로 세면, 잘못된 기간의 자료를 읽거나 다른 팀 폴더에 저장한 실행도 통과할 수 있다. 글의 문장이 자연스러운지, 필요한 자료를 빠뜨리지 않았는지, 저장 위치가 맞는지, 공유 승인을 받았는지는 각각 확인할 대상이다.

τ-bench는 대화가 끝난 뒤의 데이터베이스 상태를 정답 상태와 비교하고, 필요한 응답 정보도 평가한다. 다만 원 논문은 이 보상이 모든 절차 준수를 보장하지 않는다고 명시한다. 예를 들어 최종 상태가 맞더라도 사용자의 확인 없이 변경했다면 정책을 어겼을 수 있다. τ-bench 원 논문, 보상과 한계

이를 팀의 문서 업무에 적용한다면 결과 검사와 절차 검사를 나란히 두는 편이 낫다. 문서의 날짜·대상·근거 링크와 실제 저장된 파일을 확인하면서, 공유 전에 필요한 승인이 있었는지도 따로 본다. 결과는 맞고 승인 절차는 틀린 실행을 평균 점수 하나로 덮으면, 이후 자동화 범위를 결정할 때 필요한 정보가 사라진다. 이는 벤치마크의 공식 평가 규칙을 옮긴 것이 아니라, 그 한계를 고려한 업무 설계 제안이다.

또한 매번 처음부터 실행하는 시험과 실패한 상태에서 이어가는 시험을 구분해야 한다. pass^k의 독립 반복을 살피려면 각 실행의 초기 자료와 환경을 복원해야 한다. 앞선 실행에서 생성한 파일이나 바뀐 데이터가 남아 있다면 다음 실행은 다른 과제를 수행한다. 반대로 복구 능력을 시험하려면 그런 중간 상태를 의도적으로 남기고, 어디에서 재개해 무엇을 보존했는지 평가해야 한다.

첫 실행이 실패하자 사람이 경로를 고쳐 주고 다시 실행해 성공했다면, 그것은 사람의 지원을 포함한 복구 결과다. 최초 실행의 실패와 사람의 개입을 함께 기록해야 실제 운영 비용을 알 수 있다. 최종 성공만 남겨 두면 담당자가 지켜봐야 하는 시간을 빠뜨리게 된다.

사람과 평가 환경도 결과를 바꾼다

같은 모델을 썼다는 사실만으로 같은 시험이 되지는 않는다. 프롬프트, 도구 정의, 업무 정책, 초기 데이터와 실행 예산이 바뀌면 평가 대상도 달라진다. 사용자와 대화하는 업무에서는 상대가 어떤 정보를 언제 알려 주는지도 결과에 영향을 줄 수 있다.

2025년의 τ²-bench는 이 문제를 사용자가 환경을 바꾸는 상황으로 넓혔다. 통신 지원 영역에서 에이전트와 사용자 모두 도구를 사용하며, 에이전트는 사용자의 행동을 안내하고 조율해야 한다. 연구는 추론 오류와 의사소통·협업 오류를 나눠 살핀다. τ²-bench 논문

조직에서도 비슷한 구분이 필요하다. 담당자가 빠진 자료를 업로드해야 끝나는 업무라면, 에이전트의 결과에는 요청의 명료함과 인계 방식이 함께 작용한다. 파일을 올려 달라는 말을 했는지뿐 아니라 어떤 파일이 필요한지 정확히 안내했고, 도착한 자료를 다시 확인했는지 살펴야 한다. 사람의 반응이 들어가는 전체 과정을 하나의 업무로 평가하는 것이다.

평가 도구의 버전도 남겨야 한다. 2026년 10월 15일 확인한 τ-bench 공식 저장소의 기본 브랜치 README는 banking_knowledge 영역의 채점 오류를 고친 v1.0.1 전후 결과를 직접 비교할 수 없다고 안내한다. 이 변경은 해당 영역에 관한 것이며 다른 영역까지 같은 영향을 받는다고 확대할 수는 없다. 공식 README의 채점 변경 안내

점수가 오른 이유가 모델 개선인지, 과제 수정인지, 채점기 변경인지 구분할 수 있어야 한다. 팀의 평가 사례집도 예외가 아니다. 정답을 고쳤다면 수정 전후 결과를 나눠 두고, 비교하려는 실행들을 같은 기준으로 다시 채점해야 한다. 성공률의 변화가 무엇을 뜻하는지 설명할 수 있을 때 그 숫자가 의사결정에 쓰인다.

작은 반복 시험을 업무 인수 자료로 남기기

다음은 연구 결과를 바탕으로 제안하는 팀 실험이다. 실제 사내 시스템에 곧바로 반복 쓰기를 시키지 말고, 복원 가능한 시험 환경에서 대표 업무를 고른다. 정상 입력만 모으지 말고 자료 누락, 서로 충돌하는 요청, 사람의 확인이 필요한 경우도 포함한다. 각 사례에 초기 상태와 기대 결과, 반드시 지킬 절차를 적는다.

같은 사례를 여러 번 실행할 때에는 모델과 도구 설정, 정책·자료 버전, 초기 상태를 고정하고 실제 차이가 난 부분을 남긴다. 공식 τ-bench 제출 가이드도 모델·사용자 시뮬레이터 설정의 일치와 전체 과제 실행을 요구하며, 반복 시험을 권장한다. 다만 이 지침을 사내 업무의 충분한 표본 수나 배포 허가 기준으로 받아들여서는 안 된다. 공식 제출 가이드

팀의 인수 자료에는 과제별 성공·실패와 함께 실패 원인, 사람의 개입, 처리 시간을 기록하면 좋다. 독립 반복의 결과와 중간 상태에서 재개한 결과는 별도로 집계한다. 작은 시험은 어떤 조건에서 문제가 생기는지 찾는 데 쓸 수 있지만, 드문 실패가 없다는 증거가 되지는 못한다. 되돌리기 어려운 업무일수록 시험 범위와 사람의 검토 범위를 더 신중하게 정해야 한다.

이 자료를 지식관리 시스템에 남길 때도 성공한 프롬프트만 보관하지 않는다. 평가에 사용한 입력과 기대 결과, 정책 버전, 실패 조건을 함께 묶어 두어야 다음 사람이 같은 기준으로 재검사할 수 있다. 프롬프트를 개선했다면 원래 실패 사례가 통과하는지 확인하고, 이미 잘되던 사례도 유지되는지 본다. 그렇게 쌓인 기록은 도구를 바꾸거나 업무를 다른 담당자에게 넘길 때 사용할 인수 자료가 된다.

에이전트의 실력은 다시 맡긴 일에서도 드러난다. 무엇을 성공으로 셌는지, 어떤 조건에서 반복했는지, 실패 뒤 누구의 손이 필요했는지가 남아 있어야 팀은 맡길 업무의 범위를 넓힐 수 있다. 좋은 시연 다음에 필요한 것은 그 판단을 뒷받침할 반복 기록이다.