News중급원문 2025년 12월 9일

Anthropic가 공개한 멀티에이전트 리서치 시스템의 토큰 경제학

Anthropic이 자사 Research 기능의 오케스트레이터-서브에이전트 구조를 공개했다. 리드 에이전트가 질의를 분해해 병렬 서브에이전트에 위임하고 결과를 종합하는 구조인데, 핵심은 성능이 아니라 비용 곡선이다. 단일 에이전트 대비 토큰을 약 15배 더 쓰며, 내부 평가에서 성능 분산의 80%가 토큰 총량으로 설명됐다. 즉 멀티에이전트는 '많이 읽고 많이 쓰는' 워크로드(넓은 탐색·병렬 검색)에서만 비용을 정당화하고, 의존성이 강하거나 공유 컨텍스트가 필수인 작업에선 오히려 손해다. 프롬프트에 위임 범위와 종료 조건을 명시하지 않으면 서브에이전트가 중복 검색을 폭주시킨다는 운영 교훈도 함께 실렸다.

한국 개발자에게는 '멀티에이전트=무조건 더 좋음'이라는 가정을 깨는 기준점이다. 토큰 15배를 감당할 가치가 있는 워크로드인지부터 따지고, 위임 경계와 종료 조건을 프롬프트에 못박는 것이 비용 폭주를 막는 실무 핵심이다.

원문 출처

Anthropic Engineering

원문 보기 ↗

← Today

Multi-agent 더 보기

Multi-agent 관련 브리핑

NewsMulti-agent실전·2026년 4월 22일

Maker-Critic 루프를 코드 리뷰 파이프라인에 박아 넣기

생성 에이전트(Maker)와 별도의 검증 에이전트(Critic)를 분리하는 패턴이 코드·문서 워크플로의 표준 구조로 정착하고 있다. 같은 모델에 '스스로 검토하라'고 시키면 자기 출력에 관대해지는 self-evaluation 편향이 생기지만, Critic을 별도 프롬프트·별도 호출로 떼어내면 결함 검출률이 눈에 띄게 오른다. 관건은 Critic의 출력을 자연어 코멘트가 아니라 구조화된 판정(PASS/REVISION_NEEDED + 사유 + 수정 지점)으로 강제하는 것. 그래야 Maker가 다음 반복에서 기계적으로 반영하고, 2~3회 반복 후 수렴 여부를 라우터가 판단할 수 있다. 다만 Critic이 Maker와 동일한 맥락 오류를 공유하면 둘 다 같은 버그를 놓치므로, Critic에는 의도적으로 다른 관점(보안·과설계·비즈니스)을 주입해야 한다.

한국 개발자에게는 LLM PR 리뷰 자동화의 현실적 레시피다. 핵심은 생성과 검증을 같은 호출에 섞지 말 것, Critic 판정을 구조화해 반복 가능하게 만들 것, 그리고 Critic에 별도 관점을 심어 동일 맹점을 깨는 것이다.

LangChain Blog원문 ↗

NewsMulti-agent고급·2026년 2월 18일

[분석] swarm은 왜 자꾸 무너지는가: 에러 누적과 조정 비용의 수학

다수 에이전트를 느슨하게 풀어놓는 swarm 패턴이 실무에서 깨지는 이유를 정량적으로 짚은 논의가 늘었다. 핵심은 두 가지다. 첫째, 단계마다 에이전트 성공률이 95%여도 직렬 10단계면 전체 성공률은 0.95^10≈60%로 주저앉는다. 에이전트를 늘릴수록 핸드오프 경계가 늘고 오류는 곱해진다. 둘째, 에이전트 수 N이 늘면 조정·합의에 드는 통신 비용은 대략 N^2로 증가하지만 실제 유효 작업량은 그만큼 늘지 않는다. 결국 검증 가능한 중간 산출물과 명시적 핸드오프 계약(스키마·완료 정의)이 없는 swarm은 토큰만 태우고 발산한다. 대안으로 떠오른 건 자유 방임 swarm이 아니라 라우터가 단계를 통제하는 supervised 그래프 구조다.

실무에선 에이전트 수를 늘리기 전에 '단계별 성공률 × 단계 수'를 먼저 계산해야 한다. 검증 게이트 없는 핸드오프가 3단계만 넘어가도 체감 신뢰도가 무너지므로, 각 경계에 스키마 검증과 명시적 완료 조건을 두는 설계가 선결이다.

arXiv원문 ↗

Anthropic가 공개한 멀티에이전트 리서치 시스템의 토큰 경제학

Maker-Critic 루프를 코드 리뷰 파이프라인에 박아 넣기

[분석] swarm은 왜 자꾸 무너지는가: 에러 누적과 조정 비용의 수학

이 브리핑에 대한 Q&A

매주 화요일, 한 주의 AI를 정리해 드립니다

댓글