잘 만든 에이전트를 평가하는 세 가지 방식

1부에서 평가의 계측 단위가 정답에서 과정으로 내려가는 흐름을 깔았다. 그리고 그 흐름이 가장 급한 곳은 빌더가 직접 짠 에이전트라고 적었다. 그런데 잘 패키징된 에이전트, 그러니까 Claude Code나 Deep Research처럼 회사가 다듬어 내보낸 쪽도 들여다보면 생각보다 많이 틀린다. 그 사실을 보여주는 세 편이 TRACE, DeepHalluBench, TRAIL이다.

이 셋을 나란히 놓으면 한 가지가 드러난다. 같은 대상을 평가하는데 개입하는 고도가 다르다. TRACE는 채점 방식을 바꾸고, DeepHalluBench는 답이 나오기 전에 주장을 하나씩 검증하고, TRAIL은 애초에 무엇 위에서 재는지를 바꾼다. 출력, 주장, 측정 바탕. 2부는 이 세 고도를 방법 중심으로 본다. 어떤 점수를 받았는지가 아니라 어떻게 접근했는지가 핵심이다.

세 편이 하필 잘 만든 에이전트를 대상으로 삼은 건 우연이 아니다. 가장 잘 다듬어진 것조차 이렇게 들여다보면 새는 자리가 보인다는 게, 평가를 과정으로 내려야 하는 이유 자체다.

%%{init: {"look":"handDrawn","theme":"neutral"}}%%
flowchart TD
    Q["잘 패키징된 에이전트 (Claude Code, Deep Research)"]
    Q --> A1["TRACE: 채점 방식을 바꾼다 (output 고도)"]
    Q --> A2["DeepHalluBench: 주장을 검증한다 (claim 고도)"]
    Q --> A3["TRAIL: 측정 바탕을 바꾼다 (span 고도)"]

TRACE: 채점 방식을 바꾼다

TRACE의 방법은 채점 공식 하나로 압축된다. 정답 매칭 대신, 정답 여부에 과정 효율과 인지 품질을 곱한다. 구조를 풀면 이렇다. 최종 답이 맞으면 1, 틀리면 0인 정답 지표에, 효율 점수와 인지 품질 점수를 각각 가중 거듭제곱해 곱한다. 곱셈이라는 게 핵심이다. 세 요소 중 하나라도 낮으면 전체가 끌려 내려간다. 논문 표현으로 “연구 과정은 가장 약한 고리만큼만 강하다.”

효율은 복잡도 보상을 궤적 비용으로 나눈 값이다. 어려운 과제일수록 보상을 키우고, 비슷한 행동을 정보 없이 연속으로 반복하면 코사인 유사도 기반 페널티로 비용을 키운다. 인지 품질은 두 가지를 섞는다. 근거(evidence grounding)는 각 주장이 인용 근거에 붙는지를 자연어 추론(NLI, Natural Language Inference) 확률의 기하평균으로 잰다. 기하평균이라 근거 없는 주장 하나만 있어도 점수가 급락한다. 견고함(reasoning robustness)은 일부러 심은 함정에서 얼마나 빨리 회복하는지를 지수 감쇠로 잰다.

곱셈 구조가 주는 효과는 직관적이다. 정답을 맞혀도 효율이 0에 가까우면 효용도 0으로 수렴하고, 효율과 정확도가 높아도 근거가 비면 인지 품질이 끌어내린다. 덧셈이었다면 한 축의 높은 점수가 다른 축의 빈 곳을 가렸겠지만, 곱셈은 그걸 허용하지 않는다.

이 공식을 1부의 high-score illusion 사례에 대보면 숫자가 맞아떨어진다.

구성요소	무엇을 보나	DeepSeek-V3.1-671B
정답 여부	맞으면 1, 틀리면 0 (전체를 0으로 만듦)	1 (Pass@1 65.8%)
효율 (E)	복잡도 대비 궤적 비용, 중복 탐색 페널티	0.68
근거	주장이 근거에 붙는가 (NLI 확률 기하평균)	0.90
견고함	함정에서 회복하는가	0.80
인지 품질 (C)	근거와 견고함을 결합	0.85
최종 효용 (U)	위를 곱한 값	0.65

정답률 65.8%로 1등인 모델이 효용 0.65로 내려앉은 범인은 효율 0.68이다. 근거도 견고함도 높은데, 곱셈 구조에서 효율 하나가 발목을 잡았다.

TRACE는 측정 환경도 셋으로 나눈다. 전체 성능을 보는 Core(500개, 함정 20%), 함정을 100% 넣어 자기 교정을 보는 Robustness(100개), 최소 단서로 잠재 능력을 끌어내는 Scaffolding(50개)이다. 특히 잠재 능력은 모범 궤적(oracle trajectory)의 앞부분 일부만 힌트로 주고, 안정적으로 성공하는 데 필요한 최소 힌트 비율을 잰다. 즉, 이 비율이 낮을수록 스스로 문제를 풀어가는 능력이 크다는 뜻이다. AgentFounder-30B는 0.22, DeepSeek-V3.1은 0.35였다. 정답률에서는 DeepSeek가 앞섰지만, 적은 힌트로 문제를 풀어가는 능력은 AgentFounder가 더 컸다.

여기서 한 발 더 나간다. TRACE는 같은 과제를 여러 번 돌려 전략이 일관되는지(재현성)와, 정보를 얻을 때마다 불확실성을 얼마나 효율적으로 줄이는지(적응성)를 따로 잰다. 두 값을 엮으면 점수가 아니라 에이전트의 성향이 나온다. AgentFounder-30B는 재현성 0.89, 적응성 0.82로 ‘체계적이고 효율적인’ 유형으로 분류됐다. 채점 방식을 바꾼다는 건 순위를 바꾸는 데 그치지 않고, 같은 정답 뒤에 숨은 전략의 결까지 숫자로 드러낸다는 뜻이다.

이 방법이 건드리는 지점

TRACE는 trajectory를 들여다보지만 “몇 번째 단계가 틀렸다”를 짚지는 않는다. 대신 과정 전체를 한 숫자로 압축하는 정의를 바꾼다. 그래서 가장 높은 고도, 즉 출력 점수에서 작동한다. Pass@1 한 줄로 줄세우던 leaderboard를 그대로 두고도, 효율과 근거와 재현성을 점수 안으로 끌어들이는 게 이 방법의 개입이다. 이게 장점이자 한계다. 기존 leaderboard 운영을 거의 안 바꾸고 얹을 수 있어 가볍지만, 정작 어느 단계가 비효율의 원인인지는 따로 알려주지 않는다. 그건 다음 두 방법의 몫이다.

DeepHalluBench: 답이 나오기 전에 주장을 검증한다

DeepHalluBench는 고도를 한 칸 내린다. 최종 답이 아니라 그 답을 이루는 주장 하나하나를 근거에 대본다. 그러려면 먼저 궤적을 잘게 쪼개야 한다. 정리 단계의 출력은 인용을 보존한 채 원자 단위 주장(atomic claim)으로, 계획 단계의 출력은 개별 검색 행동으로, 사용자 질문은 원자 단위 제약(sub-query)으로 나눈다.

핵심은 검증을 두 단계 cascade로 거는 방식이다. 먼저 주장마다 근거를 좁혀 가져온다. 임베딩 유사도로 1차 거른 뒤(컷 0.4) 재정렬해 상위 다섯 덩어리를 뽑고, 15문장 단위로 끊어 맥락과 효율을 맞춘다. 그다음 NLI 모델(DeBERTa 계열)이 1차 판정을 내리는데, 확신이 0.99를 넘으면 그대로 확정하고, 애매하면 LLM(DeepSeek 계열)으로 넘겨 최종 판정한다. 싼 모델로 거르고 비싼 모델로 마무리하는 구조라, 수천 개 주장을 검증하면서도 비용이 터지지 않는다.

1차에서 근거가 없다고 나오면 2차에서 갈래를 탄다. 인용이 붙은 주장은 전체 문서로 범위를 넓혀 다시 본다. 거기서 근거가 잡히면 인용을 잘못 단 오귀속이고, 그래도 없으면 지어낸 날조다. 인용이 없는 중간 주장은 앞선 발견과 비교해(반영 체크) 앞뒤가 안 맞으면 날조로 본다. 오귀속과 날조를 굳이 가르는 건 고치는 방법이 다르기 때문이다. 오귀속은 인용 연결만 손보면 되지만, 날조는 그 주장을 통째로 들어내야 한다. 같은 “근거 없음”이라도 처방이 갈린다.

%%{init: {"look":"handDrawn","theme":"neutral"}}%%
flowchart LR
    C["주장 1개 (atomic claim)"] --> R["근거 검색 (유사도 0.4 컷, 상위 5개 재정렬)"]
    R --> N["NLI 모델 1차 판정"]
    N --> V["확신 0.99 초과: 확정"]
    N --> L["애매: LLM 재판정"]
    L --> V

검증은 네 모듈로 나뉘고, 각 모듈이 환각 한 갈래씩을 맡는다. 주장 검증은 근거 결함(정리 단계, 명시), 노이즈 탐지는 관련 근거를 못 가려낸 노이즈(정리 단계, 암묵), 행동 검증은 앞선 환각 위에 쌓인 전파와 의도 이탈(계획 단계, 명시), 제약 점검은 사용자 제약을 빠뜨린 누락(계획 단계, 암묵)이다. 네 갈래의 앞 글자를 따 PING(Propagation, Intent, Noise, Grounding)이라 부른다.

모듈	잡는 환각	단계
주장 검증	근거 결함 (날조·오귀속)	정리, 명시
노이즈 탐지	관련 근거를 못 가려냄	정리, 암묵
행동 검증	앞 오류 위에 쌓인 전파	계획, 명시
제약 점검	사용자 제약 누락	계획, 암묵

네 모듈 중 노이즈 탐지는 방식이 특히 다르다. 가져온 근거 덩어리를 의미별로 묶고 서브쿼리 관련도로 순위를 매긴 뒤, 높은 값의 덩어리를 무시했을 때 페널티를 매긴다. 가장 중요한 근거를 체계적으로 흘렸을 때를 최악으로 두고 그 대비로 정규화한다. 여기에 검색 자체의 품질을 따로 재는 지표를 둔다. 그래서 환각이 검색이 애초에 관련 없는 걸 가져온 탓인지, 가져왔는데 정리 단계가 우선순위를 못 잡은 탓인지를 가른다. 같은 틀린 답이라도 검색을 고칠 일과 정리를 고칠 일은 자리가 다르기 때문이다.

네 모듈 점수를 같은 무게로 평균해 종합 환각 점수를 낸다. 이렇게 단계별로 쪼개 보니 1부에서 인용한 그림이 나온다. proprietary 에이전트는 뿌리 오류의 57% 이상이 계획과 검색 초입에서 발생해 뒤로 전파되고, Salesforce는 40% 이상이 결론 단계에서 터진다. 최종 답만 봤다면 둘 다 그냥 “환각 있는 답”이었을 텐데, 주장 단위로 내려가니 시작점이 갈린다.

이 방법이 믿을 만한가

검증자 자체가 약하면 이 모든 게 무의미하다. DeepHalluBench는 그래서 주장 검증기를 공개 사실검증 데이터셋에 먼저 돌려봤다. FEVER에서 약 95%, SciFact-Open에서 85% 이상의 정확도를 확인한 뒤에야 실제 에이전트 궤적에 붙였다. 검증 레이어를 끼우는 방법은 그 레이어의 신뢰도를 먼저 증명해야 성립한다.

이 신뢰도가 NLI 모델 단독이 아니라 NLI와 LLM의 cascade에서 나온다는 점도 짚어둘 만하다. 확신이 높은 다수 주장은 싼 모델이 처리하고, 진짜 애매한 소수만 비싼 모델이 본다. 정확도와 비용을 한꺼번에 잡는 이 구조가 없었다면, 궤적 하나에 수백 개씩 쏟아지는 주장을 전부 LLM으로 검증하는 건 현실적으로 무리였을 것이다.

TRAIL: 무엇 위에서 재느냐를 바꾼다

세 번째 고도는 가장 아래, 측정 바탕이다. TRAIL의 출발점은 한 줄이다. 그동안의 trace 분석은 텍스트로 풀어 쓴 기록을 가정했는데, 실제 에이전트 프레임워크는 OpenTelemetry 같은 표준 형식의 구조화된 기록을 뱉는다. 그런데 LLM은 이런 구조화 데이터에 약하다. 그래서 텍스트 파싱 방식은 진짜 production 관측 환경과 어긋난다. TRAIL은 평가를 아예 OpenTelemetry 구간(span) 위에 올려, 문서 단위가 아니라 구간 단위로 오류를 라벨링한다. 이 선택은 빌더에게 실용적 함의가 있다. 이미 production에서 OpenTelemetry로 에이전트를 관측하고 있다면, 평가가 따로 노는 별도 장치가 아니라 지금 쌓이는 그 trace 위에 그대로 얹힌다. 관측과 평가가 같은 바탕을 쓰는 셈이다.

그 위에 세 범주의 오류 분류를 얹는다. 추론, 시스템 실행, 계획과 조정이다.

범주	세부 유형 (일부)
추론 (reasoning)	환각(텍스트형·도구형), 정보 처리 실패, 도구 선택 오류, 포맷·지시 불이행
시스템 실행 (execution)	도구 설정 오류, API 오류(429·401·500·404), 자원 고갈·타임아웃
계획·조정 (planning)	맥락 관리 실패, 목표 이탈, 작업 오케스트레이션 오류

눈에 띄는 건 시스템 실행 범주다. API 오류 코드나 작업 오케스트레이션 같은 항목은 모델 연구자보다 운영 엔지니어가 디버깅할 카테고리다. 평가를 production 관측과 같은 단위에 올렸기 때문에 자연히 들어온 항목이다.

trace는 일부러 오류가 나도록 만들었다. GAIA 과제는 Hugging Face OpenDeepResearch의 매니저와 검색 에이전트 계층(백본 o3-mini)으로, SWE-bench 과제는 단일 에이전트 CodeAct(백본 Claude 3.7 Sonnet)로 돌리되 출력 길이 제한이나 탐색 강제 같은 제약을 걸어 오류를 유도했다. 그렇게 모은 148개 trace, 1,987개 구간에 575개의 오류 구간을 라벨링했다.

구간 단위라는 게 왜 중요한가. 텍스트 기록을 통째로 놓고 “여기 어딘가 틀렸다”고 하는 것과, 수백 개 구간 중 몇 번째 구간에 어떤 오류가 있다고 라벨을 붙이는 건 디버깅 해상도가 다르다. 앞은 문서 단위라 사람이 다시 읽어야 하고, 뒤는 구간 단위라 곧장 그 자리로 간다. 두 trace 출처를 일부러 다르게 잡은 것도 같은 맥락이다. GAIA는 매니저가 검색 에이전트를 부리는 다중 에이전트 구조라 조정과 오케스트레이션 오류가 생기고, SWE-bench는 단일 에이전트가 코드를 고치는 구조라 도구 호출과 실행 오류가 생긴다. 한 종류의 에이전트만 봤다면 분류표의 절반은 비었을 것이다.

이 방법이 드러낸 한계

결과는 1부에서 적은 그대로다. 가장 강한 Gemini-2.5-Pro조차 구간 단위로 오류를 짚는 정확도가 GAIA 18.3%, SWE-bench 5.0%에 그쳤다. 측정 바탕을 바꿔 production 관측과 평가를 같은 단위에서 만나게 했지만, 정작 그 위에서 채점하는 LLM은 아직 구간을 제대로 못 짚는다. 측정 바탕을 내리는 일과 그 위에서 제대로 채점하는 일은 다른 문제라는 걸 TRAIL이 보여준다.

마무리

세 편은 같은 대상을 평가하는데 손대는 자리가 달랐다. TRACE는 채점 방식을 바꿔 효율과 근거를 끌어들였고, DeepHalluBench는 답이 나오기 전에 주장을 단계별로 검증했고, TRAIL은 무엇 위에서 재는지를 텍스트에서 구간으로 내렸다. 출력, 주장, 측정 바탕. 셋 중 무엇이 옳다기보다, 내 문제의 실패가 어디서 새는지에 따라 고도를 고르는 쪽에 가깝다.

한 가지 더 짚을 게 있다. 세 방법은 고도가 다른데도 같은 자리에서 발을 헛디딘다. TRACE의 근거 점수도, DeepHalluBench의 주장 검증도, TRAIL의 구간 채점도 결국 LLM이 판정한다. DeepHalluBench가 검증기를 공개 데이터셋에서 95%까지 확인하고서야 실제 궤적에 붙인 것도, TRAIL에서 가장 강한 모델조차 구간 채점이 18.3%에 그친 것도 같은 불안을 가리킨다. 어느 고도를 고르든, 그 고도에서 채점하는 도구의 신뢰도를 먼저 따져야 한다. 1부에서 적은 ‘채점자가 아직 약하다’는 문제가 2부 세 편에 그대로 흐른다. 빌더가 평가 도구를 고를 때 먼저 물어야 할 것도 점수의 화려함이 아니라 채점기의 검증 이력이다.

점수가 운에 휘둘리는 게 문제라면 채점 방식부터 손봐야 하고, 환각이 어느 단계에서 시드되는지가 궁금하면 주장 단위 검증이 필요하고, 이미 production에 텔레메트리가 쌓이고 있다면 그 구간 위에 평가를 올리는 게 맞다. 다만 이 셋은 모두 잘 패키징된 에이전트를 향한다. 회사가 다듬어 내보낸 것을 바깥에서 채점하는 방법들이다. 내가 직접 소스를 섞고 sub-agent를 엮어 짠 에이전트는 결이 다르다. 평가 환경 자체가 없어서 만들어야 하고, 실패의 책임 소재가 흐려서 따로 짚어야 한다. 그 쪽을 다루는 세 편은 3부에서 본다.

---

출처

• TRACE, Trajectory-Aware Comprehensive Evaluation for Deep Research Agents (arXiv:2602.21230)
• DeepHalluBench, Why Your Deep Research Agent Fails? (arXiv:2601.22984)
• TRAIL, Trace Reasoning and Agentic Issue Localization (arXiv:2505.08638)