에이전트 시연을 보면 대개 한 번에 잘 끝납니다. 주문을 조회하고, 환불 규정을 확인하고, 처리 결과를 알려 줍니다. 박수가 나올 만한 장면입니다.
그런데 그 장면은 몇 번째 시도였을까요. 시연자가 말하지 않으면 알 수 없습니다. 말해 주었다 해도, 같은 입력을 열 번 넣었을 때 열 번 모두 같은 결과가 나왔는지는 별개의 문제입니다.
이번 장은 이 간격을 다룹니다. 에이전트가 한 번 해냈다는 사실과 맡겨도 된다는 판단 사이에는 반복이라는 단계가 비어 있습니다. 그 단계를 어떻게 채울 수 있는지, 공개된 연구와 엔지니어링 글 몇 편을 읽으며 따라가 보겠습니다.
한 번의 성공은 무엇을 말해 주는가
사람에게 일을 맡길 때는 한 번의 성공이 꽤 많은 정보를 줍니다. 신입이 보고서를 제대로 써 왔다면 다음에도 비슷하게 쓸 가능성이 높다고 봅니다. 사람의 실력은 날마다 크게 흔들리지 않기 때문입니다.
언어 모델 기반 에이전트는 사정이 다릅니다. 같은 지시를 줘도 매번 다른 경로로 일을 풀어 갑니다. 어떤 도구를 먼저 부를지, 어느 문장을 근거로 삼을지가 시도마다 달라질 수 있습니다. Anthropic의 엔지니어링 글도 모델 출력이 실행마다 달라지기 때문에 한 과제를 여러 번 시도해 결과를 보라고 설명합니다. 이 글에서는 과제 하나에 대한 각각의 시도를 trial, 즉 시행이라고 부릅니다.
그러면 한 번의 성공은 "이 에이전트가 이 과제를 풀 수 있는 경우가 있다"는 정도만 말해 줍니다. 풀 수 있다는 것과 믿고 맡길 수 있다는 것 사이에는 거리가 있습니다. 고객 응대처럼 같은 일이 하루에 수백 번 반복되는 자리에서는 그 거리가 곧 사고 건수가 됩니다.
같은 일을 여러 번 시켜 보면 숫자가 달라집니다
이 거리를 숫자로 보여 준 연구가 있습니다. Shunyu Yao 등이 2024년 6월에 공개한 τ-bench(타우 벤치) 논문입니다. 이 벤치마크는 사용자 역할을 하는 언어 모델과 도메인별 API 도구, 정책 지침을 가진 에이전트가 대화를 주고받게 합니다. 채점은 대화가 끝났을 때의 데이터베이스 상태를 미리 정해 둔 목표 상태와 비교하는 방식입니다.
논문은 여기에 pass^k라는 지표를 새로 제안합니다. 같은 과제를 k번 시도해서 k번 모두 성공할 확률을 보는 지표입니다. 초록에 따르면 당시 최신 함수 호출 에이전트인 gpt-4o도 과제의 50퍼센트 미만에서만 성공했고, 소매 도메인에서 pass^8은 25퍼센트 미만이었습니다. 저자들은 이 결과가 에이전트가 일관되게 행동하고 규칙을 안정적으로 따르게 하는 방법이 필요하다는 뜻이라고 정리합니다. 이 수치는 2024년의 특정 모델과 벤치마크에 대한 것이므로 지금의 모델에 그대로 옮겨서는 안 됩니다. 다만 한 번 성공하는 것과 여덟 번 연달아 성공하는 것이 이렇게 다른 숫자로 나온다는 사실은 남습니다.
Anthropic이 에이전트 평가를 설명한 글에는 이 차이를 직관적으로 보여 주는 계산이 있습니다. 시행당 성공률이 75퍼센트인 에이전트에게 세 번 시켜서 세 번 모두 통과할 확률은 0.75의 세제곱으로 약 42퍼센트입니다. 시행이 서로 독립이라고 가정한 계산이지만, 감을 잡기에는 충분합니다.
종이 위에 손으로 그린 격자에 연필 체크 표시가 줄지어 있고 몇 칸에 가위표가 섞여 있는 가상 장면원본 전체 보기
같은 가정으로 몇 가지를 더 계산해 보겠습니다. 시행당 90퍼센트 성공이면 다섯 번 연속은 약 59퍼센트입니다. 95퍼센트라도 열 번 연속이면 약 60퍼센트입니다. 99퍼센트여야 열 번 연속이 약 90퍼센트에 닿습니다. 한 번 시험해서 "거의 다 된다"고 느끼는 에이전트와 하루에 열 번 맡길 수 있는 에이전트 사이에 이만큼의 간격이 있습니다.
pass@k와 pass^k는 다른 질문에 답합니다
Anthropic의 글은 두 지표를 나란히 놓습니다. pass@k는 k번 시도 중 적어도 한 번 맞을 가능성이고, pass^k는 k번이 모두 맞을 확률입니다. k가 1이면 둘은 같습니다. k가 커지면 pass@k는 100퍼센트로 올라가고 pass^k는 0퍼센트로 내려가, 정반대 이야기를 합니다.
어느 쪽이 맞는지는 일의 성격이 정합니다. 코드 후보를 여러 개 뽑아 그중 하나만 통과하면 되는 도구라면 pass@k가 질문에 맞습니다. 고객이 직접 마주하는 에이전트처럼 매번 안정적으로 움직여야 하는 자리에서는 pass^k가 맞는 질문입니다. 같은 에이전트라도 어디에 놓느냐에 따라 봐야 할 숫자가 바뀝니다.
실무에서는 이 구분이 도입 회의의 문장을 바꿉니다. "열 번 중 한 번이라도 맞았다"는 말과 "열 번 모두 맞았다"는 말은 서로 다른 보고입니다. 평가 보고서에 어느 쪽 지표인지 적혀 있지 않다면, 그 숫자가 어떤 질문에 답하는지부터 물어봐야 합니다.
말이 아니라 결과 상태를 봅니다
반복 횟수만큼 중요한 것이 무엇을 채점하느냐입니다. Anthropic은 transcript, 즉 시행의 전체 기록과 outcome, 즉 시행이 끝난 뒤 환경의 최종 상태를 구분합니다. 항공권 예약 에이전트가 마지막에 "예약되었습니다"라고 말했더라도, 실제로 중요한 것은 환경의 데이터베이스에 예약이 존재하느냐입니다.
τ-bench가 대화 중의 말씨가 아니라 대화 끝의 데이터베이스 상태를 목표 상태와 비교하는 것도 같은 이유입니다. 에이전트의 말은 그럴듯하게 나올 수 있지만, 상태는 바뀌었거나 바뀌지 않았거나 둘 중 하나입니다.
이 구분을 업무에 옮기면 질문이 구체적으로 바뀝니다. 견적서를 만든 에이전트라면 "견적서를 만들었다고 답했는가"가 아니라 "파일이 지정한 폴더에 생겼고, 합계가 원본 단가표와 맞는가"를 봅니다. 일정 조율 에이전트라면 "일정을 잡았다고 말했는가"가 아니라 "캘린더에 해당 시간의 초대가 있고 참석자가 맞는가"를 봅니다. 결과 상태를 기계가 확인할 수 있게 만들 수 있으면, 반복 시행도 사람이 지켜보지 않고 돌릴 수 있습니다.
채점기가 틀릴 때도 있습니다
결과 상태만 보면 안심이 될 것 같지만, 채점기도 틀립니다. Anthropic의 글에는 흥미로운 사례가 하나 나옵니다. Opus 4.5가 τ2-bench의 항공권 예약 문제에서 정책의 허점을 찾아 더 나은 해법을 냈는데, 작성된 그대로의 평가에서는 실패로 처리되었다는 이야기입니다. 에이전트가 틀린 것이 아니라 채점 기준이 사용자에게 더 좋은 해법을 담지 못한 경우입니다.
그래서 이 글이 가장 힘주어 권하는 것은 transcript를 직접 읽는 일입니다. 실패한 과제가 있으면 기록을 열어 에이전트가 실제로 실수한 것인지, 채점기가 올바른 풀이를 거부한 것인지 가려 봅니다. Anthropic은 누군가 평가의 세부를 파고들어 기록을 읽어 보기 전에는 평가 점수를 액면 그대로 받아들이지 않는다고 적습니다. 점수가 오르지 않을 때 그 원인이 에이전트의 성능에 있는지 평가 자체에 있는지 확신할 수 있어야 한다는 취지입니다.
이 대목은 반복 평가를 도입하려는 팀에 현실적인 경고가 됩니다. 시행 횟수를 늘리면 숫자는 많아지지만, 채점 기준이 잘못되어 있으면 틀린 숫자가 더 많아질 뿐입니다. 반복은 신뢰도를 높이는 도구이고, 무엇을 채점하는지는 사람이 계속 점검해야 합니다.
현장에서 쓸 수 있는 작은 반복 평가
그렇다면 작은 팀이 당장 할 수 있는 형태는 무엇일까요. 공개된 글에서 읽은 원칙을 이어 붙이면 다음과 같은 절차가 됩니다. 이것은 제가 특정 고객이나 현장에서 검증한 방법이 아니라, 앞서 인용한 자료의 원칙을 하나의 순서로 정리한 제안입니다.
먼저 과제 목록을 만듭니다. 처음부터 완벽할 필요는 없습니다. Anthropic도 완벽한 평가 모음을 기다리지 말고 일찍 시작하며, 실제로 본 실패에서 과제를 가져오라고 권합니다. 이미 에이전트가 실수한 사례가 있다면 그것이 가장 좋은 첫 과제입니다.
다음으로 각 과제의 성공 기준을 결과 상태로 적습니다. "친절하게 답변한다" 같은 기준은 사람이 읽어야 판정되므로 뒤로 미루고, 먼저 파일, 레코드, 전송 여부처럼 확인 가능한 것부터 정합니다. 모호한 기준은 같은 에이전트의 같은 행동을 어떤 날은 성공으로, 어떤 날은 실패로 만듭니다.
그 위에 같은 과제를 여러 번 돌립니다. 몇 번이 적당한지는 일의 무게가 정합니다. 오류가 싼 일이라면 다섯 번으로도 경향이 보이고, 돈이나 개인정보가 걸린 일이라면 더 많이 돌려야 합니다. 이 횟수에 정답은 없지만, 한 번만 돌리는 것보다는 분명히 많은 것을 알려 줍니다.
가지런히 놓인 흰 컵 다섯 개 중 하나만 기울어 물이 조금 번진 창가 선반의 가상 장면원본 전체 보기
마지막으로 실패한 시행을 직접 읽습니다. 모든 기록을 읽을 수는 없으므로 실패한 것과 성공했지만 경로가 이상한 것을 골라 봅니다. 여기서 찾아낸 것은 에이전트의 지시문이나 도구 설명을 고치는 단서가 되고, 가끔은 채점기를 고치는 단서가 됩니다.
평가는 운영 안전장치와 함께 있어야 합니다
반복 평가가 위험을 없애 주지는 않습니다. Anthropic의 "Building effective agents"는 에이전트가 자율적으로 움직이는 만큼 비용이 늘고 오류가 누적될 수 있다고 말하며, 샌드박스 환경에서 충분히 시험하고 적절한 가드레일을 두라고 권합니다. 또 실행 중에는 도구 호출 결과나 코드 실행 결과처럼 환경에서 얻는 ground truth로 진행 상황을 판단하고, 최대 반복 횟수 같은 종료 조건을 두어 통제를 유지하라고 합니다.
평가는 배포 전에 위험을 줄이는 단계이고, 종료 조건과 사람의 확인 지점은 배포 후에도 계속 작동하는 장치입니다. 둘을 같은 말로 섞으면 안 됩니다. 평가에서 pass^10이 높게 나왔다고 해서 사람의 승인 단계를 없애도 된다는 결론이 나오지는 않습니다. 이 연재 앞부분에서 다룬 실패 예산과 핸드오프 설계는 평가가 놓친 부분을 받아 주는 자리입니다.
같은 글은 에이전트를 아예 만들지 않는 선택까지 열어 둡니다. 가장 단순한 해법을 먼저 찾고 필요할 때만 복잡도를 올리라는 것이 그 글의 권고입니다. 에이전트가 필요한지 따져 보는 일도 평가의 한 부분이라고 생각합니다. 고정된 절차로 충분한 일에 에이전트를 붙이면, 시행마다 흔들리는 변수를 스스로 들여오는 셈이기 때문입니다.
숫자를 읽는 법
정리해 보겠습니다. 누군가 "우리 에이전트는 성공률이 90퍼센트입니다"라고 말하면, 몇 가지를 되물을 수 있습니다.
그 90퍼센트는 시행당 성공률인가요, 아니면 같은 과제를 여러 번 돌려 모두 통과한 비율인가요. 성공은 에이전트의 마지막 말로 판정했나요, 환경의 결과 상태로 판정했나요. 실패한 기록을 누가 읽어 보았나요. 과제는 실제로 본 실패에서 나왔나요, 잘 풀릴 만한 예시로 채웠나요.
이 질문에 막힘없이 답할 수 있다면 그 숫자는 믿을 근거가 생긴 것입니다. 답이 없다면 숫자가 틀렸다는 뜻이 아니라 아직 모른다는 뜻입니다. 모르는 상태에서 권한을 넓히면 알게 되는 시점이 사고 이후가 됩니다.
처음의 장면으로 돌아가 보겠습니다. 시연에서 한 번 잘 끝난 에이전트에게 박수를 보내는 것은 자연스럽습니다. 그다음 할 일은 같은 입력을 한 번 더 넣어 보는 것입니다. 두 번째에도, 세 번째에도 같은 상태가 남는지 보는 그 지루한 반복이 신뢰라는 말에 실제 내용을 채웁니다.
참고 자료
- Shunyu Yao, Noah Shinn, Pedram Razavi, Karthik Narasimhan, "τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains," arXiv:2406.12045, 2024. https://arxiv.org/abs/2406.12045
- Anthropic Engineering, "Demystifying evals for AI agents." https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents
- Anthropic Engineering, "Building effective agents," 2024. https://www.anthropic.com/engineering/building-effective-agents
