Executive Summary

주요 수치

출처: ParaRecover 논문 (arXiv:2609.12345, 2026-09-11)

에이전트를 평가하는 방식은 대체로 하나다. 과제를 줬더니 답을 맞혔는가, 끝까지 갔는가. 답이 맞으면 1, 틀리면 0을 준다. 이 방식이 편한 이유는 분명하다. 사람이 판단할 것이 없고 숫자가 하나로 떨어진다. 대신 그 숫자는 에이전트가 답까지 가는 동안 무슨 일을 했는지에 대해 아무 말도 하지 않는다.

논문 서론이 그 지점을 한 문장으로 짚는다.

“However, successful task completion does not necessarily imply reliable agent behavior. An agent may still complete the task through redundant calls, repeated trial and error, or incorrect recovery strategies, leading to high cost in real systems.”

중복 호출과 반복된 시행착오, 잘못된 복구 전략으로도 과제는 끝난다. 값은 실제 시스템에서 치른다. 토큰이 나가고 외부 API가 더 불리고 시간이 늘어난다. 완수율 지표는 그 비용을 어디에도 적지 않는다.

과정을 보려는 시도가 없었던 것은 아니다. 논문이 정리한 비교표를 보면 ToolSandbox와 TRAJECT-Bench는 구조화된 궤적과 병렬 호출을 이미 다루고, BFCL도 병렬 호출을 본다. 다만 그 벤치마크들은 도구 호출이 성공했는지, 형식이 맞는지를 보는 쪽에 머문다. 궤적 전체를 놓고 둘 중 어느 것이 더 나은지 고르게 하는 보상 모델용 벤치마크도 여럿 나와 있지만, 그런 평가는 잘 풀린 궤적들 사이에서 우열을 가리는 일이다. 이미 망가진 궤적을 손에 들려 주고 시작하는 시험은 없었다. 표에서 오류의 출처를 되짚는 능력과 계획을 다시 짜는 결정, 이 두 칸에 표시가 들어간 줄은 ParaRecover 하나다.

과제는 BUTTON 데이터셋에서 가져왔고, 도구 실행은 실제 API가 아니라 시뮬레이션 환경에서 돌렸다. 외부 API의 안정성이 아니라 중간 오류 상태에서의 판단을 재는 것이 목적이라 통제된 환경을 골랐다는 것이 저자들의 설명이다. 재현성과 오류 주입을 얻는 대신 실제 시스템의 지연과 상태 변화는 놓친다. 저자들도 이 점을 한계 첫 줄에 적어 뒀다.

벤치마크의 바닥에 깔린 것은 오류 분류체계다. 에이전트의 실행을 방향성 비순환 그래프로 놓고, 노드는 하위 과제와 도구 호출, 엣지는 그 사이의 의존관계로 본다. 그 위에서 무엇이 어긋날 수 있는지를 열네 칸으로 나눴다. 기존 연구가 다루던 도구 호출 수준의 실수에 더해, 여러 라운드에 걸친 병렬 실행에서만 생기는 실수를 대규모 실행 기록에서 뽑아 보탠 결과다.

이 열네 칸이 책상에서 지어낸 이름이 아니라는 근거도 함께 실렸다. 저자들은 GPT-4o-mini와 GPT-4o, GPT-5.1의 실제 실행 기록을 뜯어 오류 분포를 셌다. 가장 잦은 것은 잘못된 매개변수 타입과 무효한 값, 중복 호출, 그리고 꼭 필요한 호출을 빠뜨리는 쪽이었다. 열네 칸 전부가 실제 실행에서 자연스럽게 나타났고, 파라미터가 크고 추론이 강한 모델일수록 오류율이 낮았다.

사례는 1만 626건이다. 오류가 직전 라운드에만 머물러 아직 번지지 않은 LEVEL-1이 4,033건, 오류가 감지되지 않은 채 다음 라운드로 번지거나 새 오류가 겹쳐 쌓이는 LEVEL-2가 6,593건이다. 이 가운데 사람이 실제 실행 기록에서 골라낸 것은 2,812건으로 네 건에 한 건꼴이고, 나머지 7,814건은 정상 궤적에 열네 유형을 심어 만들었다.

열네 칸 가운데 LEVEL-1에서 가장 자주 나온 것은 잘못된 직렬화였다. 4,033건의 10.09%로 두 번째와도 차이가 뚜렷하다. 서로 기댈 필요가 없어 나란히 돌려도 되는 두 노드를 굳이 앞뒤로 세워 놓는 실수다. 규칙이 없어서 생긴 일은 아니다. 저자들이 모델에게 준 프롬프트에는 앞 과제의 반환값이 뒤 과제의 인자를 채워야 할 때에만 의존관계를 걸고 그렇지 않으면 뿌리 노드에 붙이라고 못 박혀 있다. 글로 받아 둔 규칙을 두고도 모델들은 필요 없는 줄을 그었다.

오류를 유형으로 나눠 놓아도 채점 기준이 없으면 점수가 나오지 않는다. 저자들이 만든 잣대는 세 축이고 축마다 다섯 항목씩, 모두 열다섯 항목이다. 머리글자를 따 SDE 루브릭이라 부른다.

• 구조 무결성(S)은 내놓은 계획이 형식으로 성립하는지 본다. 생각과 그래프가 어긋나지 않는지, 나란히 놓인 노드가 서로 기대고 있지는 않은지, 실행 엔진이 그 그래프를 읽을 수는 있는지.
• 진단 추론(D)은 실패를 얼마나 깊이 짚는지 본다. 겉으로 드러난 증상이 아니라 근본 원인을 잡았는지, 그 오류가 아래로 어디까지 번졌는지 알아봤는지, 근거 없이 넘겨짚지는 않았는지.
• 전략 수정(E)은 고쳐 쓴 계획이 쓸 만한지 본다. 고칠 데만 고쳤는지, 원래 목표에서 빗나가지 않았는지, 새로 넣은 단계에 이유가 있는지.

열다섯 항목 가운데 열셋은 1점과 0.5점, 0점 가운데 하나로만 매긴다. 잘게 쪼개고 선택지를 줄일수록 채점의 정확도와 일관성이 올라간다는 선행 연구를 근거로 든 설계다. 남은 둘은 채점하는 눈을 아예 거치지 않는다. 내놓은 그래프를 실행 엔진이 읽을 수 있는지는 스크립트가 통과 여부로만 찍고, 마지막 E5는 수식으로 계산한다. 정답이 요구하는 최적 라운드 수를 실제로 쓴 라운드 수로 나눠 1을 넘지 않게 자른 값에 성공 여부를 곱한 값이다. 같은 답에 이르러도 열 라운드를 돌아서 갔으면 점수가 깎인다.

판단이 들어가는 열세 항목은 사람이 일일이 채점할 수 없어 다른 언어 모델이 심판을 맡았다. 항목마다 400건씩 뽑아 사람이 붙인 답과 맞춰 본 결과, 정확 일치율은 0.8067, 평균 절대 오차는 0.1208이었다. 심판으로 쓴 모델이 순위표 상단에 오른 계열과 같은 집안이라, 저자들은 GPT-4o를 따로 보정해 다섯 모델을 다시 재는 교차검증도 붙였다. LEVEL-1 순위는 바뀌지 않았고, LEVEL-2에서는 상위 세 모델의 순서가 맞바뀌어 1위가 딥시크 모델로 넘어갔다. 그래도 심판이 모델이라는 사실 자체는 남는다. 저자들도 복잡하거나 모호한 사례에서는 편향이 끼어들 수 있다고 적었다.

일치도를 재려고 뽑은 그 표본에는 다른 것도 담겨 있다. 사람이 매긴 항목별 평균을 보면 열세 항목 중 제일 낮은 항목은 복구 완결성(E2)이다. 1점 만점에 0.2350이고, 가장 높은 항목의 절반도 되지 않는다. 터진 지점은 고치면서도 그 아래 딸려 있던 노드와 상태, 응답까지 닫아 주는 데는 거의 점수를 받지 못했다. 채점 프롬프트가 애초에 인색하게 매기라고 지시한 점은 감안해야 한다. 그렇다 해도 사람이 매긴 전체 평균은 0.4736으로 심판이 매긴 0.4813보다 오히려 조금 낮았다. 점수가 낮은 것을 심판의 박한 눈 탓으로만 돌리기는 어렵다.

오픈AI와 앤트로픽, 구글, 알리바바, 지푸, 딥시크 여섯 계열의 모델 열여섯 종을 같은 프롬프트로 돌렸다. 딥시크 플래시는 추론 모드를 따로 재서 표에는 열일곱 줄이 올라 있다. 평균이 가장 높은 것은 Claude Opus 4.6으로 LEVEL-1에서 69.23점, LEVEL-2에서 66.85점이었다. 100점 만점이고, 70점을 넘긴 줄은 한 줄도 없다.

점수가 어디서 깎였는지는 1위 모델의 네 수치를 나란히 놓으면 바로 보인다.

이 모양은 1위 모델만의 것이 아니다. 표에 오른 열일곱 줄 전부에서 전략 수정이 세 축 가운데 가장 낮다. 오류가 어디서 났는지는 그럭저럭 짚는데, 그 계획을 정확하고 효율적으로 고쳐 쓰는 일에서는 모두 무너진다. 그리고 모든 모델이 LEVEL-2에서 LEVEL-1보다 낮은 점수를 받았다. 오류가 한 라운드를 넘어 번지고 나면 되짚기가 훨씬 어려워진다는 뜻이다. 평균으로는 예외가 없지만 축별로 보면 네 모델은 전략 수정 점수만 LEVEL-2에서 오히려 조금 올랐다.

점수가 깎이는 장면 하나가 부록에 실렸다. 노드 3이 인자 타입이 틀려 빈 값을 돌려받은, 그다지 복잡하지 않은 과제였다. 에이전트는 그 호출을 고쳐 다시 부르는 대신 원인을 앞선 과제로 잘못 돌렸고, 노드 7을 새로 만들어 작업 전체를 다시 돌리기 시작했다. 뒤로 오류가 줄줄이 따라붙었다. 정답이 요구한 라운드는 여섯인데 실제로는 열여덟 라운드를 썼고, 라운드 효율(E5)은 0.33으로 떨어졌다. 그런데도 이 실행은 완수로 집계된다. 완수 판정의 조건은 라운드 상한 마흔 안에 응답 노드까지 닿는 것뿐이어서, 여섯 라운드짜리 과제를 열여덟 라운드에 끝내도 표에는 1점이 찍힌다.

이 괴리는 작은 모델에서 더 벌어진다. GPT-4o mini는 오류가 여러 라운드로 번지는 LEVEL-2에서 라운드 효율이 36.17에서 30.05로 내려앉는데, 완수율은 89.32%에서 88.84%로 거의 움직이지 않는다. 과정이 나빠진 만큼 결과 지표가 따라 내려오지 않는다.

오류 유형별로 갈리는 지점도 분명하다. 매개변수 쪽 실수처럼 실행이 눈에 띄게 깨지는 오류는 비교적 잘 잡는다. 어려운 쪽은 구조 관련과 도구 관련이고, 그중에서도 두 모델 모두에서 진단 점수가 가장 낮았던 항목은 불필요한 중복 호출이었다. 이유를 논문은 이렇게 적었다.

“Unlike other errors, it typically does not cause explicit execution failures but manifest as “plausible yet ineffective” implicit errors, making them difficult to detect—a common challenge for agents.”

중복 호출은 실패 신호를 남기지 않는다. 호출은 성공하고 값도 돌아온다. 그럴듯한데 소용이 없을 뿐이다. 딥시크 플래시가 중복 호출 과제에서 받은 구조 점수 83.44는 열네 유형 가운데 1위인데, 같은 과제의 진단 점수 69.31은 꼴찌다. 계획의 형식에는 흠이 없다. 흠이 없어서 짚어 내지 못한다. 오류 목록에 뜨지 않으니 사람도 모델도 그냥 지나간다. 완수율만 보는 평가가 가장 못 보는 종류의 실수가 정확히 이것이다.

눈길이 가는 대목은 순위표가 아니라 논문의 마지막 실험이다. 저자들은 점수 차가 5점을 넘는 궤적 쌍만 골라 선호 학습용 데이터 3,187쌍을 만들었고, 그것으로 Qwen3-8B를 학습시켰다.

프롬프트만 손본 비교군도 함께 뒀다. 잘 된 시범 답안 세 개를 프롬프트에 붙인 모델은 평균이 43.86점에서 44.47점으로 올랐다. 0.61점이다. 같은 모델을 유형 라벨로 학습시킨 쪽은 49.10점이 되어 5.24점이 올랐다. 학습에 들어간 장비는 RTX 3090 여덟 장을 꽂은 서버 한 대이고, 방식은 LoRA, 선호 학습 구간은 1에포크가 전부였다.

여기에는 당연한 의심이 따라붙는다. 자기네 루브릭으로 만든 데이터로 학습했으니 그 루브릭 점수가 오르는 것은 순환이 아닌가. 저자들도 같은 우려를 적고, 심판 모델이 관여하지 않는 지표로 다시 쟀다. 실행 기록과 환경 결과에서 곧바로 계산되는 네 가지다.

실행 불가능한 계획을 내놓는 비율이 절반 가까이 줄었고, 완수율까지 함께 올랐다. 심판이 관여하지 않는 잣대로 쟀는데도 올랐다는 것이 이 표의 요점이다. 표를 열별로 뜯어 보면 어느 단계가 무엇을 바꿨는지도 보인다. 실행 불가 비율은 지도 학습 단계에서 이미 6.71%까지 내려왔고, 선호 학습이 크게 벌린 쪽은 도구 사용 효율이다. 21.29에서 26.20으로 뛴다. 실패에 이름표를 붙이는 일이 진단에서 그치지 않고 모델을 실제로 고쳤다. 다만 모델 하나에서 한 번 확인된 결과이고, 라벨을 붙이는 쪽에는 사람 손이 여러 번 들어갔다.

페블러스가 오래 붙들어 온 물음은 데이터가 어디서 와서 무엇을 거쳐 지금 값이 됐는가다. 에이전트의 실패 기록도 같은 물음 앞에 놓인다. 이 논문에서 값을 만든 것은 더 큰 모델도, 더 긴 프롬프트도 아니었다. 실패 하나하나에 어떤 종류인지를 적어 둔 1만 626개의 줄이었다. 라벨 설계가 곧 성능이었던 셈이다.

그래서 이 연구를 벤치마크 하나가 더 나온 소식으로만 읽으면 절반만 읽은 것이 된다. 우리 팀의 에이전트 파이프라인을 두고 다음 네 가지를 확인해 볼 만하다.

• 지난주에 실패한 작업들이 지금 어떤 모양으로 쌓여 있는가. "실패" 한 칸으로만 남아 있다면 세어 볼 수는 있어도 고칠 수는 없다.
• 실패 유형을 나눈다면 몇 갈래가 필요한가. 도구 이름과 매개변수만 보는 분류는 병렬 실행에서 생기는 의존관계 실수를 하나도 담지 못한다.
• 성공으로 분류된 작업 중에 중복 호출로 돌아간 것이 얼마나 되는가. 이 실수는 오류 로그에 뜨지 않으므로 따로 세지 않으면 영영 보이지 않는다.
• 그 라벨을 누가 붙이는가. 사람이 한 번 붙여 두면 다음에는 학습 데이터가 되고, 아무도 붙이지 않으면 기록은 용량만 차지한다.

여기까지 읽어 주셔서 감사하다. 이 글이 인용한 수치와 문장은 arXiv에 공개된 논문과 저자들이 연 저장소에서 누구나 원문으로 확인할 수 있다. 여러분의 조직에서는 에이전트의 실패를 몇 칸으로 나눠 적고 계신지 나눠 주시면 좋겠다.