에이전트는 어디서 처음 틀렸나: 평가가 주장 단위까지 내려가다

대표에게 신사업을 들고 가야 한다고 해보자. 기획을 짜려면 시장조사가 먼저고, 그건 사원에게 맡겼다. 그런데 사원이 조사를 잘못 가져왔다. 출발점이 어긋났으니 그 위에 쌓은 기획도 추정도 결론도 줄줄이 무너진다. 반대로 조사는 멀쩡한데 그걸 해석하거나 필요한 것만 추려 합치는 중간에서 틀어질 수도 있다. 어느 쪽이든 한 칸이 어긋나면 그 뒤가 다 같이 어긋난다. 도미노다.

에이전트가 일을 나눠서 한다는 건 결국 이 분업이다. 검색하고, 자료를 살피고, 추론하고, 답을 엮는 단계가 줄지어 있고 앞 단계의 결과가 뒤 단계의 입력이 된다. 그래서 “맞혔나”보다 “어느 단계에서 처음 어긋났나”가 전부를 가른다. 정답률만 보던 평가가 과정으로 내려온 이유가 여기 있다.

이 시리즈는 그 “어디서”를 점점 잘게 따라 내려왔다. 정답이 맞았나에서 궤적 전체의 효용으로, 다시 결정적인 한 단계와 구간(span)으로. 이제 한 칸이 남았다. 구간보다 작은 주장(claim) 단위다. 2026년 6월에 나온 DRIFT가 거기까지 내려간다. 에이전트가 내놓은 주장 하나하나를 근거에 맞춰 보고, 그게 틀렸을 때 답까지 어떻게 번졌는지 따라간다. 시리즈 마지막 편이자 가장 최근 작업이다.

먼저 말해 두면, 주장 단위까지 내려온 건 진보지만 도착점은 아니다. 분업이 깊어질수록 더 쪼개야 하는 긴 길의 초입에 가깝다. 왜 그렇게 보는지는 마지막에 정리한다.

%%{init: {"look":"handDrawn","theme":"neutral"}}%%
flowchart LR
    A["사원: 시장조사"] --> B["중간: 취합·해석"]
    B --> C["대표 보고: 결론"]
    A -. "여기서 틀리면" .-> X["뒤가 전부 어긋남"]
    B -. "여기서 틀려도" .-> X

긴 궤적에서 무엇이 ‘유해한’ 구간인가

딥리서치 에이전트(심층 조사 에이전트, 이하 DR 에이전트)의 궤적은 길다. 검색하고, 도구를 부르고, 자료를 살피고, 답을 엮는 과정이 수십 단계로 이어진다. 그런데 그 안에는 잘못이 아닌 게 훨씬 많다. 헛다리를 짚었다가 다시 찾는 검색, 일단 세워 보는 가설, 도구가 뱉은 자잘한 찌꺼기는 다 정상 과정이다. 사원이 조사하다 막다른 길을 한 번 가 보는 게 잘못이 아닌 것과 같다.

DRIFT가 먼저 한 일은 그 구분이다. 궤적의 구간을 다섯 가지로 나눈다.

구간 종류	성격
정상 탐색	답을 향한 정상적인 검색 활동
실패한 검색	소득 없이 끝난 검색 시도
잠정 가설	아직 확정하지 않은 탐색적 주장
무해한 노이즈	도구·프레임워크가 남긴 찌꺼기
유해 오류 구간	답을 망친 진짜 문제 (찾아야 할 대상)

유해 오류 구간을 논문은 이렇게 잡는다. 틀렸거나, 근거가 없거나, 자료와 어긋나거나, 너무 일찍 단정한 판단이 답으로 가는 길에 끼어든 구간. 그 판단을 처음 꺼냈든, 거기 기댔든, 부풀렸든, 결론에 박았든 다 들어간다. 기준은 하나다. 답에 영향을 줬는가. 틀린 말이라도 답으로 흘러들지 않았으면 잡을 대상이 아니다.

이 구분이 까다로운 게 분업의 현실과 닮았다. 사원이 막다른 검색을 한 번 한 것과, 잘못된 자료를 결론에 끌어 쓴 것은 겉보기엔 비슷해도 무게가 전혀 다르다. 정상적인 헛걸음과 답을 망친 오류를 가르는 것이 평가의 출발선이다.

데이터는 실제 궤적 2,790개에서 나왔다. 에이전트 프레임워크 두 개(MiroFlow, OAgent), 백본 모델 세 개(GPT-5, Gemini-2.5-Pro, Claude-Sonnet-4.5), 벤치마크 세 개(GAIA-val, XBench, BrowseComp)를 섞었다. 한 프레임워크나 한 모델에서만 통하는 진단법은 쓸모가 좁으니, 일부러 성격이 다른 출처를 골라 섞은 것이다. 이 중 검증을 거친 1,000건이 TELBench라는 벤치마크가 된다. 쉬운 것 600건, 어려운 것 400건이고, 궤적 하나에 평균 11.95개의 구간이 들어 있다.

정답지는 기계와 사람을 나눠 만들었다. LLM 두 개에게 궤적을 읽혀 틀린 듯한 구간을 최대한 많이 뽑게 한 뒤, 전문가 일곱 명 중 두 명이 한 궤적씩 맡아 그 후보가 진짜 오류인지 자료에 비춰 가렸다. 판단이 갈리면 맞췄고, 여기 들어간 전문가 시간만 300시간이 넘는다. 정답지 1,000건에 그만큼 사람 손이 들었다는 뜻인데, 이 부담은 뒤에서 빌더 이야기를 할 때 다시 나온다.

라벨은 “여기가 틀렸다”에서 그치지 않는다. 오류마다 어느 단계에서 났는지, 어떤 종류인지까지 붙는다. 단계는 계획·검색·출처 검증·추출·계산·판단·복구·마무리의 여덟 가지, 오류 종류는 열여덟 개를 여섯 묶음으로 정리했다. 제약 조건 처리, 검색, 근거 확인, 대상 식별, 정보 가공, 절차 통제다. 미리 정해 놓고 끼워 맞춘 분류가 아니라, 라벨러들이 적어 둔 사유를 모아 묶어 올린 것이다. 3부에서 MAST가 멀티에이전트 실패를 열네 가지로 정리했던 것과 같은 방식인데, 이번엔 혼자 도는 DR 에이전트의 긴 기록 위에서 다시 만들었다.

짚고 넘어갈 게 있다. 이 정답지는 LLM이 후보를 먼저 뽑고 사람이 거르는 순서로 만들어졌다. 그러면 애초에 기계가 안 뽑은 오류는 사람 눈에도 잘 안 들어온다. 잡히는 오류의 범위가 기계의 1차 선별에 어느 정도 묶인다는 뜻이다. 게다가 논문은 전문가가 몇 시간 썼는지는 밝히면서, 두 사람의 판단이 얼마나 일치했는지는 수치로 내놓지 않는다. 평가 도구를 평가하는 자리에서도 “이 정답지 자체를 얼마나 믿나”라는 질문이 한 겹 더 남는다.

DRIFT: 주장을 따라가는 세 단계

2부에서 본 TRAIL이 궤적을 구간 단위로 끊어 봤다면, DRIFT는 그 구간 안으로 한 칸 더 들어간다. 한 구간에는 여러 주장이 섞여 있을 수 있다. 사원이 한 문단에서 맞는 말과 틀린 말을 같이 하는 것처럼. 구간 단위로는 “이 문단이 좀 이상하다”까지가 끝이지만, 주장 단위로 내려가면 “이 문단의 이 한 줄이 근거가 없다”까지 짚인다. 시리즈가 따라온 내려감의 마지막 칸이 여기다.

DRIFT는 주장을 중심에 둔 감사 방식이다. 답이 맞았는지가 아니라, 답을 떠받친 주장들이 근거에 실제로 붙는지를 본다. 세 단계로 돈다.

%%{init: {"look":"handDrawn","theme":"neutral"}}%%
flowchart TD
    CK["Claim Keeper: 주장 원장"] --> SS["Support Seeker: 근거 대조"]
    SS --> DT["Dependency Tracer: 전파 추적"]
    DT --> M["답에 영향 준 구간 표시"]

첫째, Claim Keeper가 주장 원장을 만든다. 에이전트가 내놓은 주장마다 언제 처음 나왔는지, 어디서 결정적으로 쓰였는지, 뒤의 무엇이 거기 기대고 있는지, 아직 떠보는 말인지 확정한 말인지를 적어 둔다. 사원이 보고하면서 한 말들을 한 줄씩 장부에 옮겨 적는 셈이다.

둘째, Support Seeker가 그 주장들의 근거를 따진다. 결정적으로 쓰인 주장마다 근거를 네 등급으로 가른다. 직접 뒷받침됨, 약하게 뒷받침됨, 근거 없음, 근거와 모순됨. 사원이 “이 시장은 매년 20% 큰다”고 적었으면, 그 숫자가 실제로 가져온 자료에 있는지 한 줄씩 대조하는 일이다.

셋째, Dependency Tracer가 전파를 따라간다. 근거가 약한 주장이 뒤의 추론으로 흘러들어 간 길을 짚어, 그 주장을 끌어 쓰거나 부풀려 결론에 박은 구간을 오류로 표시한다. 잘못된 한 줄이 보고서 끝까지 어떻게 굴러갔는지를 되짚는 일이다.

한 장면으로 이어 보면 이렇다. 에이전트가 검색 중에 “이 시장의 작년 규모는 5조 원”이라는 주장을 내놓는다. Claim Keeper가 이걸 원장에 올리고, 뒤의 성장률 추정과 결론에 쓰였다고 적는다. Support Seeker가 근거를 따져 보니 정작 가져온 자료에는 5조 원이 아니라 3조 원이라고 적혀 있다. 근거와 모순됨으로 분류된다. Dependency Tracer가 그 5조 원이 어디까지 흘러갔는지 따라가면, 성장률 계산도 최종 결론도 그 위에 서 있다. 그래서 그 한 줄과 거기 기댄 뒤 구간들이 유해 오류로 묶인다. 사원이 숫자 하나를 잘못 옮겨 적었고, 그게 보고서 끝까지 굴러간 경로가 그대로 드러나는 것이다.

세 단계를 묶으면 사람 조직의 감사와 구조가 똑같다. 누가 무슨 말을 했는지 적고(원장), 그 말이 자료에 붙는지 보고(근거), 틀린 말이 결론까지 번졌는지 따라간다(전파). DRIFT가 한 일은 이 절차를 DR 에이전트의 긴 로그 위에서 자동으로 돌린 것이다.

절반은 잡고, 첫 칸은 못 잡는다

성능은 두 잣대로 본다. 유해 구간을 얼마나 잘 골라냈는지(F1)와, 가장 먼저 틀어진 지점을 맞혔는지(first-error accuracy, 이하 FEA)다. 아래는 감사를 맡은 모델별로 맨바닥 프롬프트(Bare)와 DRIFT를 비교한 값이다. 여기 쓰인 감사자 모델은 데이터를 만든 백본과 별개다.

감사 모델	F1 (Bare → DRIFT)	FEA (Bare → DRIFT)
DeepSeek-V3.2	22.46% → 50.51%	10.30% → 23.70%
GPT-5.4	33.93% → 52.48%	14.90% → 20.80%
Claude-Sonnet-4.6	21.89% → 54.91%	11.30% → 24.10%
Gemini-2.5-Pro	31.01% → 48.41%	15.70% → 19.90%

DRIFT를 끼우면 유해 구간 찾기가 맨바닥 대비 최대 30%포인트까지 오른다. 제일 잘하는 조합(Claude-Sonnet-4.6)이 F1 54.91%로, 절반을 조금 넘긴다. 주장을 근거에 대조하는 한 겹을 더한 것만으로 이만큼 올라온다는 게 이 방법의 성과다.

문제는 두 번째 칸이다. FEA, 그러니까 “어디서 처음 틀렸나”는 20%대에서 막혀 있다. 어려운 궤적에서는 더 떨어진다. DeepSeek 기준 쉬운 쪽이 34.5%, 어려운 쪽이 7.5%다. 유해 구간을 두루 짚는 것과, 그중 맨 처음 어긋난 한 칸을 집어내는 건 다른 일이고, 논문도 후자를 풀리지 않은 숙제로 남겨 둔다.

이유는 짐작할 만하다. 한 칸이 어긋나면 그 뒤가 줄줄이 어긋나 보이니, 감사자 눈에는 이상한 구간이 잔뜩 깔린다. 그중 무엇이 원인이고 무엇이 그 결과인지 가리기가 어렵다. 증상은 많은데 발병 지점은 하나인 셈이다. 사람이 보고서를 거꾸로 짚어 올라가며 “그래서 이게 어디서 시작됐지”를 찾는 일이 품 드는 것과 같다.

쉬운 일과 어려운 일의 간극도 크다. 같은 DeepSeek로 유해 구간 F1을 보면 쉬운 궤적에서 57.81%까지 오르지만 어려운 궤적에서는 39.57%로 내려간다. DRIFT는 어느 쪽에서도 맨바닥보다 앞서지만, 일이 길고 복잡해질수록 두 방식이 같이 무너진다. 정작 진단이 필요한 건 사원이 며칠씩 매달린 복잡한 조사인데, 평가가 약해지는 곳도 바로 거기다.

논문이 적은 한계도 같은 방향을 가리킨다. 모델만 키운다고 진단이 좋아지지는 않는다. 같은 계열에서 더 큰 모델이 궤적 진단을 꼭 더 잘하지는 않았고, 모델 크기보다 감사 구조가 더 크게 작용했다. 궤적이 길어질수록 두 방식 다 성능이 떨어지고, 오류 유형별로 잡는 정도도 고르지 않다. 근거 없이 성급하게 단정한 판단 같은 미묘한 유형은 여전히 약하다.

한 가지 짚을 점

도미노로 돌아오면, 제일 아픈 곳이 이 두 번째 칸이다. 사원의 조사가 처음부터 틀렸을 때가 손해가 제일 크다. 그 위에 쌓은 게 다 헛것이 되니까. 그런데 DRIFT가 제일 못 찾는 게 바로 그 첫 어긋남이다. 답을 망친 구간들을 사후에 두루 표시하는 데는 절반쯤 왔지만, 손대면 그 뒤가 전부 살아나는 단 한 칸을 짚는 데는 아직 멀었다. 평가가 “어디가 이상한지 보여 주는” 데서 “어디를 고치면 되는지 짚어 주는” 데로 넘어가려면 이 칸을 넘어야 한다.

빌더가 가져갈 것

1인 빌더가 1,000건짜리 벤치마크와 300시간 라벨링을 복제할 일은 없다. 가져갈 건 주장 원장이라는 발상이다. 내 에이전트가 중간에 내놓는 주장을, 어디서 처음 나와 어디로 흘러가는지와 함께 적어 두는 것이다. 그 위에서 “이 주장이 가져온 자료에 실제로 붙나”를 묻는 값싼 점검을 걸면, 모든 로그를 손으로 읽지 않고도 근거가 빈 곳부터 먼저 볼 수 있다. 규모는 작아도 원리는 같다.

채점을 LLM이 한다는 점은 짚고 넘어갈 만하다. 그 자체는 자연스러운 방향이다. 실패를 찾는 것도 결국 하나의 작업이고, 작업이면 가이드를 얼마나 잘 주느냐로 품질이 올라간다. 다만 예시 몇 개 붙이는 식의 간단한 기법처럼 풀리진 않을 것이다. 채점하는 LLM 자신도 결국 긴 궤적을 읽고 추론하는 에이전트다. 짧은 입력에 답을 붙이는 분류와 달리, 갈래 많은 과정을 따라가며 어디가 틀어졌는지 판단해야 한다. 채점기의 실패 양상이 채점 대상의 실패 양상을 닮아 간다. 가이드를 잘 줘서 풀릴 부분과, 분업이 깊어질수록 채점 자체가 같이 어려워지는 부분이 섞여 있다. FEA가 20%대에 묶여 있는 게 그 증거다.

그래서 빌더가 당장 할 수 있는 건 분업의 이음매에 사람 눈을 한 번 더 두는 것이다. 서브에이전트가 결과를 다음 단계로 넘기는 경계, 사원이 조사를 보고로 넘기는 그 지점마다 “여기까지 들어온 주장의 근거가 붙나”를 확인하는 체크포인트를 둔다. 조사 담당 에이전트가 요약을 넘길 때, 그 요약의 숫자와 인용이 원본에 실제로 있는지만 기계로 한 번 훑어도 된다. 궤적 전체를 감사하는 것보다 훨씬 싸고, 가장 손해가 큰 첫 단계의 어긋남을 거기서 거른다. 도구가 첫 어긋남을 못 잡는 동안에는, 손해가 제일 큰 그 자리를 사람이 지키는 편이 싸게 먹힌다.

마무리

네 편을 지나왔다. 1부가 정답 평가가 무너지는 지형도였고, 2부가 잘 패키징된 에이전트를 평가하는 세 고도, 3부가 내가 직접 짠 에이전트를 평가할 도구였다. 그리고 4부의 DRIFT가 계측 단위를 주장까지 끌고 내려왔다. 정답에서 궤적으로, 구간으로, 주장으로 한 칸씩 내려온 길이다.

왜 이렇게까지 내려왔나. 에이전트가 일을 나눠서 하기 때문이다. 사람 조직처럼 분업이면 어느 단계가 처음 어긋났는지가 전부를 가르고, 그 한 칸을 찾으려면 단계를 더 잘게 쪼개 들여다보는 수밖에 없다. 이 시리즈의 논문 일곱 편이 공유한 방향이 그것이다. 평가가 자꾸 잘게 내려가는 건 학술적 취향이 아니라, 분업이 만드는 도미노를 따라가려는 움직임이다.

그렇다면 DRIFT는 도착점이 아니다. “에이전트가 나눠서 일한다”는 한 문장에 세상의 모든 업무가 담길 수는 없다. 분업이 더 복잡해지면 평가는 또 다른 단위로 쪼개질 것이고, 어디까지 갈지는 지금 아무도 모른다. 주장 단위는 현재의 맨 끝일 뿐, 끝이 아니라 이제 막 갈라져 나온 줄기다.

그래서 1부의 결론이 다시 선다. 벤더가 평가까지 끼워 주는 영역 밖으로 한 발 나가는 순간, 평가는 사 오는 물건이 아니라 손수 챙기는 일이 된다. 도구가 아직 첫 어긋남도 못 잡는 초기라서, 빌더가 평가를 떠안아야 하는 이유는 오히려 더 또렷해진다.

---

출처

• DRIFT / TELBench, Where Do Deep-Research Agents Go Wrong? Span-Level Error Localization in Agent Trajectories (arXiv:2606.02060)