에이전트는 어디서 틀렸나: 정답 평가에서 과정 평가로

정답을 맞힌 에이전트가 평가에서 꼴찌가 됐다.

TRACE라는 평가 프레임워크가 Deep Research Agent(심층 조사 에이전트, 이하 DR 에이전트)들을 줄세웠더니, DeepSeek-V3.1-671B는 한 번에 정답을 맞힌 비율(Pass@1)이 65.8%로 가장 높았는데 궤적 효용(trajectory utility) 점수에서는 0.65로 상위권 중 가장 낮았다. 반대로 정답률이 60.1%로 더 낮은 AgentFounder-30B가 효용 0.81로 1위에 올랐다. 정답을 더 잘 맞히는 모델이 평가에서는 더 낮은 점수를 받은 것이다.

이건 채점 실수가 아니라 채점 기준이 바뀐 결과다. 정답 한 칸만 보던 시절이 끝나가는 신호다. 2025년부터 2026년 사이 arXiv에 올라온 일곱 편의 논문이 같은 질문을 공유한다. 에이전트가 맞혔는가가 아니라, 어디서 어떻게 틀렸는가. 그리고 그 질문에 답하려고 계측 단위를 점점 잘게 쪼개고 있다. 정답 일치에서 궤적 효용으로, 다시 결정적 단계와 구간(span), 주장(claim) 단위로.

%%{init: {"look":"handDrawn","theme":"neutral"}}%%
flowchart TD
    O["정답 일치 (outcome)"] --> T["궤적 효용 (trajectory utility)"]
    T --> ST["결정적 단계 (critical step)"]
    ST --> SP["구간 (span)"]
    SP --> C["주장 (claim)"]

시기로 보면 순서가 있다. 2025년 3월 멀티에이전트 실패 분류(MAST)가 바닥을 깔았고, 같은 해 5월 단일 에이전트의 구간 평가(TRAIL), 2026년 초 DR 에이전트의 효용과 환각 평가(TRACE, DeepHalluBench), 그리고 2026년 6월 주장 단위 감사(DRIFT)가 차례로 올라왔다. 계측 단위가 잘게 쪼개지는 흐름과 시간 순서가 거의 나란히 간다.

이 글은 시리즈 ‘에이전트 실패를 찾는 법’의 1부다. 일곱 편을 한 편씩 깊이 파기 전에, 왜 정답 평가가 무너지는지와 전체 지형도를 먼저 깐다. 각 논문이 쓰는 방법은 2부부터 본다. 여기서는 벤치마크 점수가 아니라 그들이 왜 정답 한 칸을 버리기 시작했는지를 본다.

정답을 맞히고도 꼴찌가 되는 이유

TRACE의 효용 점수는 정답 하나로 끝나지 않는다. 세 가지를 함께 본다. 과정의 효율(process efficiency), 인지 품질(cognitive quality), 그리고 정확도다. 과정 효율은 같은 답에 도달하기까지 얼마나 적은 단계로 갔는지를, 인지 품질은 근거를 얼마나 댔는지(evidence grounding)와 추론이 도중에 흔들리지 않는지(reasoning robustness)를 본다. 세 가지가 다 받쳐줄 때 점수가 높다.

DeepSeek가 정답률 1등인데 효용 꼴찌가 된 건 과정 효율이 0.68로 낮았기 때문이다. 같은 답에 도달하기까지 더 많이 헤맸다는 뜻이다. 정답이라는 결과는 같아도, 거기까지 간 길이 비효율적이었다.

모델	정답률 (Pass@1)	궤적 효용	차이가 난 지점
DeepSeek-V3.1-671B	65.8%	0.65	과정 효율 0.68, 비효율 궤적
AgentFounder-30B	60.1%	0.81	효율과 근거의 균형

여기서 중요한 건 순위 뒤집기 자체가 아니다. 정답 매칭은 30번 헤매서 도달한 답과 5번에 도달한 답에 똑같이 100점을 준다. 사용자 입장에서는 같은 답일지 몰라도, 빌더 입장에서는 다르다. 토큰을 여섯 배 쓴 궤적은 비용이 여섯 배고, 운이 좋아 맞은 궤적은 다음에 같은 입력에서 또 맞으리라는 보장이 없다. 효용 점수는 정답 한 칸으로는 안 보이던 축, 그러니까 효율과 근거와 재현성을 점수로 끌어올린 것이다.

TRACE가 이걸 재는 방식도 정답 평가와 다르다. 각 과제에 모범 궤적(oracle trajectory)을 붙여, 에이전트가 정답에 닿기까지 얼마나 적은 안내로 충분했는지를 잰다. 또 과제를 한 묶음으로 두지 않고, 전체 성능을 보는 묶음과 일부러 함정을 넣어 에이전트가 스스로 오류를 바로잡는지 보는 묶음, 최소한의 단서만 주고 잠재 능력을 끌어내는 묶음으로 나눠 본다. 정답률만 보면 첫 묶음 하나로 끝나지만, 효용으로 보면 함정 앞에서 무너지는 모델과 버티는 모델이 갈린다. 같은 정답률이라도 견고함이 다르다는 걸 점수로 드러내려는 설계다.

앞에서 한 번 틀리면 뒤가 줄줄이 무너진다

정답 평가가 놓치는 게 하나 더 있다. 어디서부터 틀렸는지다. DeepHalluBench는 DR 에이전트의 작업을 계획(plan), 검색(search), 정리(summarize)로 이어지는 긴 궤적으로 보고, 환각이 어느 단계에서 시작돼 어떻게 번지는지를 추적한다.

수치가 분명한 그림을 준다. proprietary 에이전트(Gemini, OpenAI)에서는 뿌리 오류의 57% 이상이 초반 단계에서 발생한다. 계획이나 검색 초입에서 잘못 짚은 전제 하나가 정리와 최종 답까지 그대로 실려 간다. 반면 오픈소스인 Salesforce 에이전트는 오류의 40% 이상이 후반, 결론을 쓰는 단계에서 맥락이 무너지며 생긴다. 같은 환각이라도 시작점이 다르고, 그래서 고쳐야 할 자리도 다르다.

%%{init: {"look":"handDrawn","theme":"neutral"}}%%
flowchart LR
    P["계획 (plan)"] --> S["검색 (search)"] --> M["정리 (summarize)"] --> A["최종 답 (answer)"]
    P -. "초반 오류 57%+" .-> S
    S -. "전파" .-> M
    M -. "전파" .-> A
    A --> J{"정답만 채점하면 전파가 안 보인다"}

이게 도미노다. 최종 답만 채점하면 답이 틀렸다는 건 알아도 어디서부터 틀렸는지는 모른다. 계획 단계의 잘못된 전제와, 정리 단계에서 우연히 끼어든 노이즈는 최종 답에서 똑같이 “틀린 답”으로 뭉뚱그려진다. DeepHalluBench가 환각을 네 갈래로 나눈 건 이 뭉뚱그림을 풀기 위해서다. 앞 단계 오류 위에 쌓인 전파(Propagation), 사용자 의도와 어긋난 계획(Intent), 관련 근거를 가려내지 못한 노이즈(Noise), 가져온 자료에 충실하지 못한 근거 결함(Grounding). 네 가지 이름의 앞 글자를 따 PING이라 부른다.

그리고 검증을 단계마다 따로 붙인다. 주장이 출처에 맞는지 보는 주장 검증, 근거 우선순위를 보는 노이즈 탐지, 계획이 의도에 맞는지 보는 행동 검증, 사용자가 건 제약을 지켰는지 보는 제약 점검이다. 최종 답 하나에 자 하나를 대는 게 아니라, 단계마다 다른 자를 들이대는 것이다. 그래야 “틀렸다”가 아니라 “계획 단계에서 의도를 잘못 잡았다”까지 짚을 수 있다.

나도 multi-agent로 작업을 나눠 정확도를 올리는 실험을 하면서 같은 걸 봤다. sub-agent 하나가 초반에 질문을 잘못 물어오면, 그 뒤에 붙은 단계들이 멀쩡해도 결과가 우르르 간다. 뒤 단계가 앞 단계의 출력을 입력으로 받기 때문이다. 도미노는 single agent든 multi-agent든 똑같이 생긴다. 다만 단계가 많아질수록 첫 패가 잘못 깔릴 확률도, 그걸 뒤늦게 되짚는 비용도 커진다.

잘 패키징된 에이전트와 커스텀 패키징

그러면 이 과정 평가가 모두에게 똑같이 급한 문제냐. 그건 아니다. 누가 에이전트를 패키징했느냐로 갈린다.

한쪽은 잘 패키징된 에이전트다. Claude Code 같은 코딩 에이전트, OpenAI나 Gemini의 Deep Research가 그렇다. 길게 도구를 호출하는 long-horizon 작업을 모델 회사가 범용으로 묶어 내보낸 것이다. 뒤가 잘 짜여 있어서 대부분 원하는 결과를 낸다. 회사가 안에서 궤적을 검증하고 다듬었고, 사용자는 결과만 받으면 된다. 평가의 책임은 패키징한 회사가 진다.

다른 쪽은 내가 직접 패키징하는 에이전트다. 개인이든 회사든 뾰족한 목적이 생기면, 범용 패키지로는 안 되니까 자기 데이터와 자기 흐름을 섞어 직접 짠다. 사내 파일과 공개 웹을 같이 뒤지게 하거나, 특정 순서로 sub-agent를 부르거나, 자기만의 소스 mix를 끼운다. 잘 패키징된 long-horizon 에이전트가 다 채워주지 못하는 지점이다. 그리고 그 순간, 궤적과 비용과 실패 추적이 전부 빌더 본인 몫이 된다.

구분	잘 패키징된 에이전트	커스텀 패키징
누가 패키징하나	모델 회사 (Anthropic, OpenAI 등)	빌더 본인 (개인, 회사)
대표 예	Claude Code, Deep Research	custom multi-agent, 사내 소스 mix
평가를 누가 소유	패키징한 회사	빌더 본인
비용 통제	회사가 내부에서	빌더가 직접
실패 추적	대체로 불필요	직접 해야 함

예를 들어 보자. 한 팀이 사내 위키와 공개 규제 문서, 자체 제품 DB를 함께 뒤져 “우리 제품이 새 규제를 어디서 위반하는지” 답하는 에이전트를 짠다고 하자. 검색 sub-agent가 규제 문서에서 엉뚱한 조항을 물어오면, 분석 sub-agent는 그 위에서 그럴듯하게 추론하고, 최종 보고서는 자신 있게 틀린다. 이 팀에게 필요한 건 “보고서가 틀렸다”가 아니라 “검색 단계의 세 번째 호출에서 엉뚱한 조항을 잡았다”는 정보다. 그래야 그 단계만 고친다. 보고서 전체를 다시 돌리는 건 비용이고, 어디가 문제인지 모른 채 프롬프트를 통째로 바꾸는 건 도박이다.

DRBench가 기업 환경에서 관찰한 것도 같은 방향이다. 공개 웹용으로 만든 일반 에이전트를 사내 파일과 이메일, 채팅이 섞인 데이터에 그대로 붙이면, 흩어진 정답 단서를 거의 건지지 못한다. 범용으로 패키징된 에이전트가 커스텀 환경에서 곧장 통하지는 않는다는 뜻이다. 빌더는 그 간극을 자기 손으로 메워야 하고, 메우는 동안 어디서 새는지를 봐야 한다.

과정 평가가 필요해지는 건 바로 이 커스텀 패키징 쪽이다. 도구 호출과 sub-agent 부름이 늘수록 비용은 빠르게 붇고 실패 지점은 흐려진다. 비용 통제(cost control)와 품질 통제(quality control)를 빌더가 직접 해야 하는데, 정답률 한 줄로는 어느 단계에서 토큰을 태우고 어디서 틀렸는지 알 수가 없다. 평가가 과정으로 내려간 건 학계 유행이 아니라, 직접 패키징하는 빌더가 떠안은 실무 문제에 가깝다.

어디서 틀렸나를 잡는 일곱 가지 방법

일곱 편은 같은 질문에 서로 다른 방법으로 답한다. 점수를 얼마 받았느냐보다, 어떻게 접근했느냐가 이 시리즈가 보려는 것이다. 방법을 늘어놓으면 다섯 결로 갈린다.

논문 (arXiv)	방법론 한 줄	결
MAST (2503.13657)	사람 여섯이 실행 기록을 귀납적으로 코딩해 14개 실패 유형 분류를 합의로 만듦	귀납 분류
TRAIL (2505.08638)	평가를 텍스트가 아니라 OpenTelemetry 구간(span) 위에 올림	계측 인프라
AgentRx (2602.02475)	사양과 정책에서 검증식을 합성해 단계별로 위반을 잡고 감사 로그를 남김	검증 레이어
DeepHalluBench (2601.22984)	궤적을 주장 단위로 쪼개 자연어 추론(NLI)과 LLM 검증을 단계별로 적용	검증 레이어
TRACE (2602.21230)	정답 매칭을 버리고 효율과 근거와 정확도를 곱한 효용 함수로 수식화	메트릭 수식
DRBench (2510.00172)	기업 데이터에 정답 단서와 함정을 심어 평가 환경 자체를 설계	환경 설계
DRIFT (2606.02060)	에이전트의 주장을 궤적 근거에 대조해 답에 영향 준 구간을 표시	검증 레이어

이렇게 보면 “에이전트가 어디서 틀렸나”를 잡는 일은 다섯 갈래로 접근된다. 데이터에서 분류를 올리는 쪽(MAST), 평가를 production 텔레메트리 위에 세우는 쪽(TRAIL), 답을 내기 전에 검증 레이어를 끼우는 쪽(AgentRx, DeepHalluBench, DRIFT), 평가 환경 자체를 만드는 쪽(DRBench), 그리고 점수의 정의를 다시 쓰는 쪽(TRACE). 같은 문제를 두고 누구는 분류표를, 누구는 계측 파이프라인을, 누구는 검증식을 만든다.

이 다섯이 서로 경쟁하는 대안은 아니다. 에이전트를 직접 패키징해 운영하는 입장에서 보면, 실은 층층이 쌓는 것에 가깝다. 실패에 이름을 붙이는 분류가 있어야 무엇을 찾을지 정해지고, 그걸 잡으려면 궤적을 구간 단위로 남기는 계측이 깔려야 하고, 답이 나가기 전에 걸러내려면 검증 레이어가 필요하고, 그걸 시험하려면 정답과 함정이 심긴 환경이 있어야 하고, 마지막으로 그 결과를 한 숫자로 비교하려면 점수의 정의가 다시 쓰여야 한다. 한 빌더가 다섯을 다 만들 일은 없지만, 자기 파이프라인에 이 다섯 중 어디가 비었는지를 묻는 체크리스트로는 쓸 수 있다.

이 일곱은 앞서 말한 패키징 구분과도 겹친다. TRACE와 DeepHalluBench, TRAIL은 잘 패키징된 DR 에이전트와 코딩 에이전트도 이만큼 틀린다는 걸 보여주는 쪽에 가깝고, MAST와 DRBench, AgentRx는 빌더가 직접 패키징한 multi-agent와 기업 소스 환경을 진단하는 쪽이다. DRIFT는 그 위에서 계측 단위를 구간에서 주장까지 끌고 내려간 가장 최신 작업이다.

이 시리즈는 수치보다 방법에 무게를 둔다. 2부에서는 잘 패키징된 에이전트를 평가하는 세 편(TRACE, DeepHalluBench, TRAIL)이 각각 효용을 어떻게 수식화하고, 주장을 어떻게 검증하고, 구간을 어떻게 계측하는지를 본다. 3부에서는 커스텀 패키징 쪽을 다루는 세 편(MAST, AgentRx, DRBench)의 접근을, 4부에서는 구간에서 주장으로 내려간 DRIFT를 본다.

마무리

짚고 넘어갈 게 있다. 이 흐름을 미는 곳 상당수가 관측 도구(observability)를 파는 회사다. TRAIL은 Patronus AI, 관련 후속 작업은 Deepchecks, DRBench는 ServiceNow에서 나왔다. 그러니 “과정 평가가 필수”라는 말은 동시에 그들의 제품 피치이기도 하다. 이걸 모르고 받아들이면 안 된다.

그런데 제품 피치인 것과 진짜 수요인 것은 같이 갈 수 있다. 둘을 가르는 기준은 피치와 무관하게 수요가 존재하느냐 하나다. 그리고 직접 패키징하는 빌더가 늘면, 수요는 누가 팔지 않아도 생긴다. 도구 회사가 광고를 멈춰도 sub-agent를 fan-out한 빌더는 실패 지점을 누군가 추적해야 한다.

그 빌더는 늘어날 것이다. 사람들이 점점 더 복잡한 태스크를 시키려 하기 때문이다. 태스크가 복잡해질수록 범용 패키지의 경계를 넘게 되고, 자기 흐름을 짜게 되고, 그 순간 비용과 품질을 직접 재야 한다. 그래서 나는 이 시장이 커진다고 본다.

다만 솔직히 남는 의문이 하나 있다. 이 채점자들 자체가 아직 약하다. TRAIL에서 가장 강한 Gemini-2.5-Pro조차 구간 단위로 실패를 짚는 정확도가 GAIA 18.3%, SWE-bench 5.0%에 그친다. 실패하는 에이전트를, 비슷하게 실패하는 에이전트로 채점하는 셈이다. 과정 평가가 신뢰할 도구가 되려면 채점자부터 나아져야 한다. 그게 어떻게 가능한지, 일곱 편이 각자 어떤 방법으로 이 문제를 풀고 있는지를 다음 글부터 하나씩 본다.

---

출처

• MAST, Why Do Multi-Agent LLM Systems Fail? (arXiv:2503.13657)
• TRAIL, Trace Reasoning and Agentic Issue Localization (arXiv:2505.08638)
• AgentRx, Diagnosing AI Agent Failures from Execution Trajectories (arXiv:2602.02475)
• TRACE, Trajectory-Aware Comprehensive Evaluation for Deep Research Agents (arXiv:2602.21230)
• DeepHalluBench, Why Your Deep Research Agent Fails? (arXiv:2601.22984)
• DRBench, A Realistic Benchmark for Enterprise Deep Research (arXiv:2510.00172)
• DRIFT / TELBench, Where Do Deep-Research Agents Go Wrong? Span-Level Error Localization in Agent Trajectories (arXiv:2606.02060)