내가 짠 에이전트는 평가가 딸려 오지 않는다

1부와 2부는 잘 만든 에이전트, 그러니까 회사가 다듬어 내보낸 것을 바깥에서 평가하는 방법들을 봤다. 3부는 반대편이다. 내가 직접 소스를 섞고 sub-agent를 엮어 짠 에이전트.

여기서 빌더는 LLM 위에 자기 목적의 에이전트를 직접 조립하는 쪽을 말한다. 모델 회사가 아니라 그 아래에서 자기 데이터와 자기 흐름으로 커스텀 에이전트를 짜는 개발자, 팀, 창업가다. 1부에 나온 “사내 데이터로 규제 위반 점검 에이전트를 짜는 팀”이 전형이다. 이런 팀이 에이전트를 띄우고 나면 곧장 벽에 부딪힌다. 답이 틀린 것 같긴 한데, 무엇이 틀렸다고 불러야 할지, 어느 단계에서 샜는지, 고친 뒤에 나아졌는지를 어떻게 재는지가 막막하다. 벤더 제품이라면 만든 회사가 안에서 풀어 줬을 문제들이다.

벤더 에이전트와 커스텀 에이전트의 결정적 차이는 평가가 딸려 오느냐다. Claude Code를 쓰면 품질 검증은 만든 회사가 안에서 끝내고 내보낸다. 그런데 내가 사내 데이터로 직접 짠 에이전트에는 그런 게 없다. 정답지도, 실패를 부를 이름도, 시험해 볼 환경도 처음부터 없다. 이 빈자리를 채우는 세 편이 MAST, AgentRx, DRBench다. 각자 다른 조각을 만든다. 실패를 부를 어휘, 틀린 자리를 자동으로 짚는 법, 내 데이터를 닮은 시험대.

%%{init: {"look":"handDrawn","theme":"neutral"}}%%
flowchart TD
    Q["내가 직접 짠 에이전트 (커스텀 패키징)"]
    Q --> M["MAST: 실패를 부를 어휘"]
    Q --> A["AgentRx: 틀린 자리를 자동으로 짚는 법"]
    Q --> D["DRBench: 내 데이터를 닮은 시험대"]

미리 짚어둘 게 있다. 이 셋을 만든 건 빌더가 아니라 연구자다. UC Berkeley와 ServiceNow를 비롯한 연구팀이 큰 규모로 만들었다. 1인 빌더가 이걸 그대로 재현할 일은 없다. 그래서 각 논문이 무엇을 어떻게 만들었는지와 함께, 그중 빌더가 자기 규모에서 빌려 쓸 수 있는 게 무엇인지를 같이 본다.

세 조각은 따로 노는 게 아니라 한 줄로 이어진다. 어휘가 있어야 무엇이 잘못됐는지 부를 수 있고(MAST), 부를 수 있어야 어느 단계에서 그 일이 났는지 짚고(AgentRx), 짚을 수 있어야 고친 게 나아졌는지 시험대에서 잴 수 있다(DRBench). 이름, 위치, 측정. 커스텀 에이전트를 평가한다는 건 결국 이 세 가지를 손수 갖추는 일이다.

MAST: 실패를 부를 어휘

처음 부딪히는 건 단어가 없다는 문제다. 멀티 에이전트가 틀렸을 때 “뭐가 잘못된 거냐”를 물으면, 그동안은 답할 공통 언어가 없었다. MAST는 그 언어를 데이터에서 끌어올렸다.

방법은 귀납이다. 분류를 먼저 정해 놓고 trace를 끼워 맞추는 게 아니라 거꾸로 갔다. 전문가 여섯 명이 다섯 개 프레임워크의 실행 기록 150건을 열어, 눈에 보이는 실패 행동에 일일이 이름을 붙였다. 비슷한 것끼리 묶고 쪼개기를 반복하며, 새로운 실패 유형이 더 안 나올 때까지 갔다. 1인당 스무 시간이 넘게 걸렸다. 그렇게 합의된 분류를 다른 세 명이 따로 라벨링해 일치도를 쟀더니 κ 0.88, 강한 합의가 나왔다.

왜 분류를 미리 정하지 않고 데이터에서 끌어올렸을까. 멀티 에이전트 실패는 아직 누구도 전체 지도를 그려 본 적 없는 영역이었다. 위에서 “이런 실패들이 있을 것”이라고 정해 놓고 trace를 끼워 맞추면, 정한 사람의 머릿속 밖에 있는 실패는 영영 안 보인다. 그래서 거꾸로, 실제 기록에서 올라오는 것만 이름 붙여 쌓았다. 이렇게 만든 분류가 이후 나온 거의 모든 실패 진단 연구의 공통 기준점이 됐다.

결과는 14개 실패 유형, 세 범주다. 모은 1,642개 trace에서 분포를 보면 절반 가까이가 설계 문제다.

범주	비중	대표 유형
설계 문제 (System Design)	약 44%	같은 단계 반복 15.7%, 종료 조건 모름 12.4%, 과제 명세 위반 11.8%
에이전트 간 어긋남 (Inter-Agent Misalignment)	약 31%	추론과 행동 불일치 13.2%, 과제 이탈 7.4%
검증 부실 (Task Verification)	약 24%	잘못된 검증 9.1%, 검증 누락 8.2%

분포 자체가 메시지를 준다. 멀티 에이전트 실패의 다수는 모델이 멍청해서가 아니라 구조가 어긋나서 생긴다. 같은 단계를 무한 반복하거나(15.7%) 언제 멈춰야 할지 몰라 맴도는(12.4%) 건 더 똑똑한 모델로 안 풀린다. 오케스트레이터와 메모리 설계의 문제다.

두 번째로 큰 범주인 에이전트 간 어긋남(약 31%)은 조정의 문제다. 한 에이전트가 추론해 놓고 행동은 딴판으로 하거나(13.2%), 대화가 길어지며 원래 과제에서 벗어나거나(7.4%), 막혔을 때 되묻지 않고 혼자 헤맨다. 단일 에이전트엔 없던 실패가 여럿을 엮으면서 새로 생긴 것이다. 멀티 에이전트가 더 똑똑할 거라는 기대와 달리, 늘어난 건 능력보다 어긋날 자리였다는 게 이 분포가 말하는 바다.

1,642개를 사람이 다 라벨링한 건 아니다. 150개로 분류를 세운 뒤, o1을 LLM 심판으로 써서 나머지를 자동 라벨링했다. 사람과의 일치도가 94%, κ 0.77로 나와 규모를 감당했다. 이 자동 라벨러는 학습에 쓰지 않은 다른 프레임워크와 벤치마크에서도 κ 0.79를 유지했다. 분류가 특정 프레임워크에만 맞춰진 게 아니라는 확인이다.

빌더가 가져갈 것

빌더가 여섯 명을 모아 1,642개를 다시 라벨링할 일은 없다. 가져갈 건 분류표 자체다. 14개 유형은 내 멀티 에이전트가 틀렸을 때 “뭐가 잘못됐나”를 부를 체크리스트가 된다. 내 trace를 이 열네 칸에 떨어뜨려 보면 어느 칸이 자주 차는지가 보인다. 같은 단계 반복과 종료 조건 문제가 trace의 20%를 넘으면, 프롬프트를 손볼 게 아니라 오케스트레이터를 다시 설계하라는 신호다.

예를 들어 sub-agent 셋을 엮은 리서치 봇이 자꾸 엉뚱한 답을 낸다고 하자. 14칸에 대보면 그게 추론과 행동 불일치인지(계획은 맞게 세우고 엉뚱한 도구를 부름), 과제 이탈인지(중간에 주제가 새는 것), 검증 누락인지(틀린 중간 결과를 거르지 않고 넘김)가 갈린다. 셋은 손볼 자리가 다르다. 이름이 있으면 어디를 의심할지가 좁혀진다. 분류표는 연구실에서 만들었지만, 그걸 내 로그에 대보는 건 빌더가 당장 할 수 있다.

규모가 부담되면 MAST가 쓴 절차를 그대로 빌리면 된다. 내 trace 몇 개만 손으로 분류해 본을 만든 뒤, 나머지는 LLM 심판에게 맡겨 열네 칸에 자동으로 떨어뜨리는 것이다. 연구실이 1,642개에 한 일을, 빌더는 수십 개 규모로 줄여 똑같은 절차로 할 수 있다. 분류 체계가 공개돼 있으니 본을 처음부터 만들 필요도 없다.

AgentRx: 틀린 자리를 자동으로 짚는 법

분류표가 있어도 “이 trajectory의 몇 번째 단계가 결정적으로 틀렸나”는 다른 문제다. 긴 궤적을 사람이 일일이 읽어 짚는 건 비싸다. AgentRx는 그 짚는 일을 자동화한다.

핵심은 LLM 심판에게 곧장 “어디가 틀렸어?”라고 묻지 않는다는 점이다. 대신 중간에 검증 레이어를 끼운다. 먼저 제각각인 로그를 공통 형식으로 정규화하고, 도구 명세와 도메인 정책, 그리고 지금까지의 실행 내용에서 실행 가능한 검증식을 합성한다. 이 검증식을 단계마다 돌려 위반을 잡고, “어느 단계가 어떤 규칙을 어겼다”는 근거 로그를 남긴다. LLM 심판은 마지막에 이 근거 로그를 받아 결정적 실패 단계와 유형을 짚는다.

검증식이라는 게 거창한 건 아니다. 도구 명세에서 “이 도구는 이런 인자를 요구한다”, 정책에서 “이 작업은 이 순서를 지켜야 한다” 같은 규칙을 기계가 확인할 수 있는 형태로 뽑아낸 것이다. 단계마다 이 규칙들을 대보면 명세를 어긴 호출이나 순서를 건너뛴 행동이 걸린다. 제각각인 로그를 먼저 공통 형식으로 정규화하는 것도 같은 이유다. 도메인마다 기록 모양이 달라도 같은 잣대를 댈 수 있어야 하기 때문이다.

짚는 대상이 모든 실패가 아니라 결정적 단계 하나라는 점도 중요하다. 긴 궤적에는 사소한 헛디딤이 여럿 섞이는데, 그중 회복 불가능하게 만든 첫 단계가 진짜 고칠 자리다. 모든 오류에 빨간 줄을 긋는 건 디버깅에 도움이 안 된다. 어디부터 손대야 하는지를 하나로 좁히는 게 핵심이다.

이 중간 단계가 차이를 만든다. 심판이 통째로 “느낌상 여기”라고 찍는 게 아니라, 규칙 위반이라는 증거 위에서 판단한다. 그래서 결과를 되짚을 수 있다. 왜 이 단계가 결정적이라고 봤는지가 근거 로그에 남기 때문이다. 2부의 TRAIL이나 그 후속 작업이 trace를 LLM 심판에게 통째로 넘겼다면, AgentRx는 그 사이에 규칙 검증이라는 한 겹을 더 둔다. 심판의 판단을 직관이 아니라 위반 목록 위에 세우는 것이다.

데이터는 세 도메인의 실패 궤적 115건이다. API 워크플로, 장애 대응, 열린 웹·파일 작업으로, 일부러 성격이 다른 셋을 골랐다. 정해진 절차를 따르는 작업, 시간 압박 속에 대응하는 작업, 끝이 열린 탐색 작업은 실패하는 방식이 서로 다르다. 한 도메인에서만 통하는 진단법은 쓸모가 좁으니, 셋에 두루 통하는지를 본 것이다. 이 위에서 AgentRx는 결정적 단계 위치추정과 근본 원인 진단을 모두 기존 baseline보다 끌어올렸다.

빌더가 가져갈 것

가져갈 건 검증식 합성이라는 발상이다. 이미 내 에이전트는 도구 명세와 정책을 갖고 있다. 그걸로 “이 단계가 이 규칙을 어겼나”를 묻는 값싼 자동 점검을 만들 수 있다. 모든 trace를 손으로 읽는 대신, 규칙 위반이 뜨는 곳을 먼저 보는 것이다. 그리고 “왜 여기를 의심하나”를 근거로 남기는 패턴은, 나중에 같은 실패를 다시 만났을 때 바로 쓸 자산이 된다. 풀스케일 프레임워크를 그대로 들이지 않아도 이 두 가지는 작게 시작할 수 있다. 거창한 진단 엔진 없이 도구 호출 로그에 “이 호출이 스키마를 어겼나”를 묻는 단정 몇 개만 걸어도 절반은 잡힌다. 심판에게 모든 판단을 떠넘기지 않고, 기계가 확실히 아는 규칙 위반부터 먼저 거르는 순서가 요점이다.

DRBench: 내 데이터를 닮은 시험대

어휘가 있고 진단법이 있어도, 정작 시험해 볼 환경이 없으면 평가가 시작되지 않는다. 공개 벤치마크는 대개 깔끔한 웹 검색을 가정하는데, 빌더의 현실은 사내 위키와 PDF, 이메일, 채팅이 뒤섞인 지저분한 검색 공간이다. DRBench는 그 환경을 통째로 만든다.

기업 검색이 어려운 건 정답이 한 곳에 없기 때문이다. 단서가 위키 한 줄, 이메일 한 통, 스프레드시트 한 칸에 흩어져 있고, 그 사이사이에 그럴듯하지만 틀린 함정이 끼어 있다. DRBench의 함정은 무작위 노이즈가 아니라 정답과 헷갈리게 설계된 미끼다. 그래서 일단 많이 긁어 오고 보는 에이전트는 함정까지 같이 주워 점수가 깎인다. 정답을 모으는 능력과 함정을 거르는 능력을 한꺼번에 시험하는 셈이다.

방법의 핵심은 정답을 심는 것이다. 100개 과제, 10개 도메인(영업, 보안, 컴플라이언스 등)에 걸쳐 Nextcloud 파일과 Mattermost 채팅, 이메일, 각종 문서, 그리고 공개 웹에 정답 단서(injected insight)와 함정(distractor)을 흩뿌려 둔다. 정답이 어디 숨어 있는지를 출제자가 알고 있으니, 에이전트가 그걸 얼마나 건졌는지(insight recall)와 함정을 얼마나 피했는지를 잴 수 있다. 거기에 인용이 출처에 맞는지(factuality)와 보고서 품질(여섯 항목)을 더한다. 세 잣대가 각기 다른 실패를 잡는다. 회수율은 “필요한 걸 다 찾았나”, 사실성은 “쓴 내용이 출처에 실제로 붙나”(검색 기반 검증으로 따로 확인한다), 보고서 품질은 “읽을 만하게 엮었나”를 본다. 정답을 다 찾고도 출처를 엉터리로 달거나, 사실은 맞는데 보고서가 엉망일 수 있으니 한 숫자로 뭉치지 않고 셋을 따로 둔다. 에이전트 쪽은 조사 계획, 행동 계획, 검색 루프, 적응 실행, 보고서 작성의 다섯 단계로 돈다.

결과가 환경의 난이도를 보여준다. 공개 웹용으로 만든 일반 web agent(GPT-4.1)를 이 환경에 붙이면 insight recall이 1.11%에 그쳤다. 사실성 6.67%, 보고서 품질 33.07%. 브라우저만으로는 기업 검색이 거의 불가능하다는 뜻이다. 전용으로 설계한 DRBA(GPT-4o 백본)조차 정답 회수는 13.18에 머물렀다. 함정은 95.76%로 잘 피했지만, 흩어진 정답을 모으는 데서 약했다. 함정을 피하는 것과 흩어진 정답을 모으는 것은 다른 능력이고, 기업 데이터에서 정작 어려운 건 후자라는 뜻이다. 벤치마크 자체의 품질은 사람 평가로 확인했다. 과제의 적절성과 근거에 대해 75표 중 72표, 96%가 승인했다.

빌더가 가져갈 것

빌더가 100개 기업 과제를 합성할 필요는 없다. 가져갈 건 정답과 함정을 심어 답안지를 만든다는 설계다. 내 테스트 데이터에 내가 아는 사실 몇 개와 그럴듯한 함정 몇 개를 직접 심어 두면, 정답지가 없던 내 에이전트에도 회수율이라는 잴 수 있는 숫자가 생긴다. 규모는 작아도 원리는 같다. 구체적으로는, 내 에이전트가 답해야 할 질문 열 개를 정하고 각 질문의 정답을 내가 미리 내 데이터 어딘가에 심는다. 정답과 비슷하지만 틀린 함정도 몇 개 끼워 둔다. 그러면 에이전트가 정답 몇 개를 건졌고 함정 몇 개에 걸렸는지가 그대로 점수가 된다. 출제자가 답을 아는 순간 채점이 가능해진다. 평가 환경이 없으면 없는 채로 두지 말고, 작게라도 만들어 두는 것이다.

마무리

벤더가 다듬어 내보낸 에이전트는 평가가 딸려 온다. 내가 짠 에이전트는 안 딸려 온다. 그래서 평가는 벤더가 끼워 주는 부품이 아니라 내가 챙겨야 하는 일이 된다. 이 세 편은 그 일을 맨바닥에서 시작하지 않도록 조각을 떠 준다. 무엇이 잘못될 수 있는지의 어휘(MAST), 어디서 틀렸는지를 자동으로 짚는 법(AgentRx), 내 데이터를 닮은 시험대(DRBench).

다만 셋 다 연구실 규모로 만들어졌다. 여섯 명의 라벨링, 세 도메인의 진단 프레임워크, 100개 기업 과제는 1인 빌더가 복제할 물건이 아니다. 그래서 빌더는 통째로 베끼기보다 골라 빌린다. 분류표는 체크리스트로, 검증식 합성은 값싼 자동 점검으로, 환경 설계는 내 데이터에 심는 작은 답안지로. 큰 도구를 작게 잘라 쓰는 셈이다.

이게 1부에서 말한 “빌더가 평가를 떠안는다”의 실제 모습이다. 벤더가 평가까지 끼워 주는 영역 밖으로 한 발 나가는 순간, 평가는 사 오는 물건이 아니라 손수 챙기는 일이 된다. 다행히 맨손은 아니다. 무엇을 부르고, 어디를 짚고, 어떻게 잴지를 연구가 먼저 닦아 놨고, 빌더는 자기 크기에 맞게 가져다 쓰면 된다.

1부가 지형도였고, 2부가 잘 만든 것을 평가하는 세 고도, 3부가 내가 만든 것을 평가할 도구였다. 그런데 이 도구들이 공통으로 의지하던 채점기 자체에는 아직 빈틈이 있다. 계측 단위를 한 칸 더 내려, 구간(span)보다 작은 주장(claim) 단위에서 오류가 어디서 시작돼 답까지 번졌는지를 따라가면 그 빈틈이 보인다. 시리즈의 마지막, 가장 최근 작업인 DRIFT를 4부에서 본다.

---

출처

• MAST, Why Do Multi-Agent LLM Systems Fail? (arXiv:2503.13657)
• AgentRx, Diagnosing AI Agent Failures from Execution Trajectories (arXiv:2602.02475)
• DRBench, A Realistic Benchmark for Enterprise Deep Research (arXiv:2510.00172)