멀티에이전트의 두 숙제 — 토큰 비용과 안정성, 그리고 평가라는 해법

지난 글까지는 한 그래프 위에서 흐름을 그리고, 위험한 순간에 사람을 끼워 넣는 이야기를 했습니다. 그 그래프에 에이전트를 여러 개 올리면 혼자서는 못 열던 폭이 열립니다. Anthropic은 리드 에이전트(Claude Opus 4)와 병렬 서브에이전트(Claude Sonnet 4)로 구성한 리서치 시스템이, 내부 리서치 평가에서 단일 에이전트(Opus 4) 대비 90.2% 더 나은 성능을 냈다고 밝혔습니다.

하지만 이 힘에는 대가가 따릅니다. 이 글에서는 멀티에이전트의 두 가지 근본 문제 — 토큰 비용과 안정성 — 을 짚고, 그 해법으로서의 평가 설계를 정리합니다. Anthropic의 멀티에이전트 리서치 시스템 사례를 출발점으로 삼되, 앞서 본 도구 평가와 하네스를 실무 질문으로 이어 보려 합니다.

Why — 토큰과 안정성이라는 두 숙제

멀티에이전트가 강력한 이유는 사실 단순합니다. 토큰을 충분히 쓰기 때문입니다. Anthropic이 BrowseComp(찾기 어려운 정보를 웹에서 찾는 평가) 성능 분산을 분석했더니, 토큰 사용량 하나만으로 80%를 설명할 수 있었습니다. 나머지 설명력은 도구 호출 수와 모델 선택에 있었고, 세 요인을 합치면 95%까지 갔습니다. 에이전트마다 별도의 컨텍스트 윈도우를 갖고 병렬로 추론하니, 그만큼 사고 용량이 늘어나는 것이죠.

그런데 바로 이 지점이 첫 번째 숙제를 낳습니다.

토큰 비용. 에이전트마다 컨텍스트를 쌓기 때문에 토큰 소비가 커집니다. Anthropic 데이터에서 에이전트는 일반 챗 대비 약 4배, 멀티에이전트 시스템은 약 15배의 토큰을 씁니다. 그래서 멀티에이전트는 아무 데나 쓰는 구조가 아닙니다. 작업의 가치가 늘어난 비용을 정당화할 만큼 높을 때만 경제적으로 성립합니다. 모든 에이전트가 같은 컨텍스트를 공유해야 하거나, 단계 사이 의존이 많은 일(많은 코딩 작업이 여기에 가깝습니다)은 지금 구조와 잘 맞지 않는다고 Anthropic도 말합니다. 토큰을 어디에 얼마나 쓸지가 곧 설계의 핵심이 됩니다.

안정성. 두 번째 숙제는 더 까다롭습니다. 에이전트가 늘수록 실패 지점도 늘어납니다. 원문의 표현이 핵심을 찌릅니다. 에이전트는 상태를 갖고 있고(stateful), 오류가 누적됩니다(errors compound). 전통적인 소프트웨어에서는 작은 버그가 기능 하나를 망가뜨리는 데 그치지만, 에이전트 시스템에서는 사소한 변화가 연쇄적으로 큰 행동 변화로 번집니다. 한 단계가 어긋나면 에이전트가 완전히 다른 경로로 빠져 예측하기 어려운 결과에 도달합니다.

이 두 숙제 앞에서 필요한 것은 “에이전트가 제대로 하고 있는지”를 판단하는 장치 — 평가(evaluation)입니다. 평가는 품질만 재는 일이 아닙니다. 노력(토큰·도구 호출)을 어디에 쓸지, 위험한 행동을 실행 전에 막을지를 정하는 하네스의 측정면이기도 합니다.

How 1 — 평가는 작업의 성격에 따라 두 층으로

여기서부터가 실무의 핵심입니다. Anthropic 원문은 자유 형식 리서치 결과를 LLM-as-judge로 채점하는 쪽을 주로 다룹니다. 저는 그걸 한 층 더 밀어, 작업이 되돌릴 수 있는가를 기준으로 평가를 두 층으로 나누는 편이 유용하다고 봅니다.

되돌릴 수 있는 작업 → 백그라운드 사후 평가. 챗봇 답변, 문서 초안, 리서치 보고서처럼 틀려도 고칠 수 있는 작업은 답을 먼저 내보내고 뒤에서 평가하는 방식이 맞습니다. 사용자에게 결과를 빠르게 주고, 품질 검증은 백그라운드에서 비동기로 돌립니다. Anthropic도 자유 형식의 리서치 결과물을 LLM-as-judge로 채점합니다. 사실 정확성, 인용 정확성, 완결성, 출처 품질, 도구 효율 같은 기준을 담은 루브릭으로 0.0~1.0 점수와 합격·불합격을 매기는 방식입니다. 이 층의 트레이드오프는 분명합니다. 속도를 얻는 대신, 가끔 틀린 걸 사용자에게 보여줄 수 있습니다. 되돌릴 수 있으니 감당 가능한 리스크입니다.

되돌릴 수 없는 작업 → 실행 전 사전 평가 게이트. 반면 제어 명령, 결제, 삭제처럼 한번 실행하면 되돌리기 어려운 작업은 이야기가 다릅니다. 이런 작업은 실행 전에 평가 게이트를 통과해야 합니다. 게이트를 통과한 것만 실행되게 하는 것이죠. 지난 글의 human-in-the-loop, 시리즈에서 말한 신호등이 바로 이 층입니다. 트레이드오프는 반대입니다. 안전을 얻는 대신, 속도를 잃습니다. 되돌릴 수 없는 작업에서 속도를 위해 안전을 포기하는 거래는 보통 성립하지 않습니다.

핵심은 이 둘을 구분하는 것입니다. 되돌릴 수 있는 작업에 무거운 사전 게이트를 달면 불필요하게 느려지고, 되돌릴 수 없는 작업을 사후 평가로 처리하면 이미 벌어진 일을 뒤늦게 발견할 뿐입니다. 작업의 성격을 먼저 판단하고, 거기에 맞는 평가 층을 붙여야 합니다.

도구 평가의 세 층과 겹쳐 보면 더 선명합니다. 선택·실행·결과는 “무엇을 재는가”이고, 사후 평가와 사전 게이트는 “언제 재고 막을 것인가”입니다.

How 2 — 자기 개선의 함정, 그리고 단단한 바닥

평가 이야기를 하다 보면 매력적인 아이디어에 도달합니다. 에이전트가 스스로를 개선하게 하면 어떨까? Anthropic도 이 가능성을 활용합니다. Claude에게 프롬프트와 실패 사례를 주면 왜 실패했는지 진단하고 개선안을 내놓습니다. 결함 있는 도구를 수십 번 테스트해 설명을 다시 쓰게 했더니, 이후 에이전트의 작업 완료 시간이 40% 줄었다고 합니다.

강력합니다. 그런데 여기에 함정이 있습니다.

“평가가 나쁨 → 프롬프트 자동 수정”이라는 루프는 폭주할 수 있습니다. 수정이 항상 옳다는 보장이 없기 때문입니다. 잘못된 수정이 또 다른 잘못된 평가를 낳고, 그걸 근거로 다시 수정하는 — 자기가 자기를 망치는 되먹임이 생길 수 있습니다. 자동화된 개선은 방향이 맞을 때는 빠르게 좋아지지만, 방향이 틀리면 그만큼 빠르게 나빠집니다.

그래서 자기 개선에는 안전장치가 필요합니다.

• A/B 검증 후에만 채택. 자동 생성된 수정을 곧바로 반영하지 않고, 기존 버전과 비교해 실제로 나아졌는지 확인한 뒤에만 적용합니다.
• 롤백 가능성. 수정이 나쁜 것으로 드러나면 이전 상태로 되돌릴 수 있어야 합니다.
• 중요한 변경은 사람이 승인. 파급이 큰 변경은 human-in-the-loop으로, 사람이 최종 판단을 합니다.

그리고 더 근본적인 질문이 있습니다. 평가하는 에이전트도 결국 LLM이라 틀립니다. 그렇다면 그 평가를 또 다른 에이전트에게 검증받아야 할까요? 그 에이전트도 LLM입니다. 평가를 무한히 다른 에이전트에게 위임하는 건 답이 될 수 없습니다. 어딘가에서는 LLM이 아닌 단단한 바닥에 발을 딛어야 합니다.

그 바닥은 세 층으로 존재합니다. 코드와 테스트로 결정적으로 검증할 수 있는 것, 사람이 라벨링한 ground truth, 그리고 최종적으로는 사람의 판단입니다. Anthropic도 이 점을 분명히 합니다. 자동 평가의 세계에서도 사람의 테스트는 여전히 필수이며, 사람은 자동 평가가 놓치는 엣지 케이스 — 이상한 쿼리에서의 환각, 미묘한 출처 편향 — 를 잡아냅니다. 실제로 초기 에이전트가 권위 있는 학술 자료 대신 SEO에 최적화된 콘텐츠를 고르는 편향을, 사람 테스터가 발견해 고쳤다고 합니다.

정리하면, 자기 개선은 강력하지만 그 자체를 신뢰의 최종 근거로 삼을 수는 없습니다. 검증 가능한 코드, 사람이 만든 정답, 사람의 눈 — 이 단단한 바닥이 있어야 자기 개선의 루프가 폭주하지 않고 올바른 방향으로 수렴합니다.

정리

멀티에이전트 시스템을 한 장면으로 묶으면 이렇습니다.

• Why: 멀티에이전트는 토큰을 많이 써서 강력하지만, 그만큼 토큰 비용(챗의 약 15배)과 안정성(오류 누적)이라는 두 숙제를 안는다. 값이 비용을 정당화하는 병렬 탐색에 맞다.
• How 1: 평가를 작업의 되돌림 가능성으로 나눈다. 되돌릴 수 있는 작업은 사후 평가로 속도를, 되돌릴 수 없는 작업은 사전 게이트로 안전을 택한다.
• How 2: 자기 개선은 강력하지만 폭주할 수 있으므로 A/B·롤백·사람 승인으로 감싸고, 평가의 최종 근거는 LLM이 아닌 단단한 바닥(코드·테스트·ground truth·사람)에 둔다.

Anthropic이 글 말미에 남긴 문장이 이 모든 걸 관통합니다. AI 에이전트를 만들 때 “마지막 1마일이 여정의 대부분이 된다”는 것. 프로토타입은 쉽지만, 토큰을 통제하고 실패를 견디는 프로덕션 시스템으로 만드는 일은 전혀 다른 난이도입니다. 그리고 그 마지막 1마일의 핵심에, 어떤 작업을 언제·어떻게 평가할 것인가라는 질문이 놓여 있습니다.

---

📚 시리즈: AI 에이전트, 만들고 평가하기

1. Workflow와 Agent, 그리고 하네스 — LLM에게 얼마만큼의 자유를 줄 것인가
2. 에이전트의 도구(Tool)와 세 층의 평가 — 선택·실행·결과
3. 멀티에이전트의 두 숙제 — 토큰 비용과 안정성, 그리고 평가라는 해법 ← 지금 글
4. ReAct와 Plan-and-Execute를 LangGraph로 직접 구현하며 배운 것
5. 그래서 Agent에 데이터를 어떻게 입히나요? — 데이터가 작을 때의 온톨로지 설계
6. 제조업 AI 에이전트 프로젝트 1차 회고 — 평가, 저장소, 코드 정리에 대한 세 가지 교훈
7. AI 에이전트의 예시 데이터는 어떻게 다룰까 — 컨텍스트 엔지니어링부터 파인튜닝 준비까지