에이전트를 늘릴수록 왜 실패할까: 앤트로픽이 멀티 에이전트를 단일 루프로 합치라고 권고한 이유

복잡한 비즈니스 문제를 해결하려는 AI 개발팀은 자연스럽게 멀티 에이전트 아키텍처를 떠올린다. 주문 처리 에이전트, 배송 조회 에이전트, 취소 환불 에이전트처럼 역할을 잘게 쪼개고 라우터가 이들을 조율하는 구조다. 인간 조직의 분업 모델을 닮았기에 직관적이며 모듈화도 깔끔해 보인다.

프로덕션 환경에 배포하는 순간 기대는 무너진다. 에이전트 사이를 오가는 인수인계 과정에서 핵심 제약 조건이 유실된다. 팀마다 제각각 덧붙인 프롬프트 규칙이 충돌하며, 요청 하나를 처리하는 데 드는 지연 시간과 토큰 비용이 폭증한다. 각 하위 에이전트는 독립 테스트를 만점으로 통과해도 고객이 마주하는 최종 결과물은 실패로 끝난다.

Claude 3.5 Sonnet과 Claude Code를 만드는 앤트로픽(Anthropic)의 응용 AI(Applied AI) 팀은 공식 아키텍처 가이드(When to fold subagents into your main agent loop)를 통해 정반대의 처방을 내놓았다. 복잡한 멀티 에이전트 계층을 걷어내고, 점진적 공개(Progressive Disclosure) 기반의 단일 에이전트 루프로 하위 에이전트들을 다시 통합하라는 권고다.

🔍 클릭하여 확대

flowchart TD
    subgraph MultiAgent["기존: 부서별 멀티 에이전트 계층 구조 (맥락 유실과 지연 발생)"]
        direction TB
        Router["라우터 / 오케스트레이터"]
        A1["주문 담당 서브에이전트"]
        A2["배송 담당 서브에이전트"]
        A3["취소/환불 서브에이전트"]
        Router -->|"요약 전달 (제약 유실)"| A1
        A1 -->|"중간 결과 요약"| A2
        A2 -->|"재요약 전달"| A3
    end

    subgraph SingleLoop["앤트로픽 권고: 단일 에이전트 루프 + 점진적 공개"]
        direction TB
        MainAgent["단일 에이전트 메인 루프<br/>(원문 질문, 대화 맥락, 중간 결과 단일 보존)"]
        SkillRegistry[("스킬 카탈로그 (SOP)")]
        ToolRegistry[("도구 실행기 (API/DB)")]

        MainAgent <-->|"요약 목록 확인 후 필요 시 전문 로드"| SkillRegistry
        MainAgent <-->|"결정론적 데이터 조회 및 작업 병렬 실행"| ToolRegistry
    end
  

---

1. 멀티 에이전트가 빠지는 4가지 함정

하위 에이전트를 무분별하게 늘릴 때 시스템이 무너지는 구조적 원인은 명확하다.

말전달 게임(The Telephone Game)과 맥락 유실

고객이 다음과 같이 문의한다.

"목요일 전에 받아야 하는데 제 주문 도착하나요? 늦으면 취소할게요."

이 요청에는 주문 번호, 배송 기한(목요일 전), 조건부 행동(기한 초과 시 취소)이라는 세 가지 핵심 제약이 얽혔다.

멀티 에이전트 시스템에서는 라우터가 주문 담당에게 질문을 넘기고, 주문 담당은 배송 담당에게 배송일 조회를 넘긴다. 이 인수인계 경계에서 요약 프롬프트가 동작한다. "배송 일정 확인 요망"이라는 평이한 문장으로 축약되는 순간, '목요일 전'이라는 시간 제약과 '지연 시 취소'라는 고객 의도가 증발한다.

배송 담당은 예정일을 정상 조회했고, 취소 담당은 취소 규정을 올바르게 안내했다. 각 서브에이전트는 제 역할을 완수했으나 최종 응답은 고객이 원한 핵심 판단을 놓친다.

프롬프트 비대화와 지시 충돌

엔터프라이즈 환경에서는 여러 팀이 각자 담당하는 서브에이전트의 시스템 프롬프트를 독립적으로 수정한다. 결제팀은 환불 제한 규정을 강화하고, CS팀은 예외 승인 지침을 추가한다.

하위 에이전트 프롬프트마다 서로 상충하는 규칙이 쌓이면 오케스트레이터는 의사결정 루프에 갇힌다. 에이전트끼리 책임을 떠넘기거나 무한 핑퐁 호출을 반복한다.

고립된 평가(Isolated Evals)의 착시

서브에이전트 단위 유닛 테스트는 문제를 감춘다. 배송 에이전트 자체의 평가 지표는 99%를 기록한다. 전체 작업 흐름을 묶은 엔드투엔드(End-to-End) 성공률은 바닥을 친다. 하위 컴포넌트의 국소 최적화가 시스템 전체의 기능 부전으로 이어진다.

직렬 호출에 따른 지연과 비용 폭증

에이전트 간 핸드오프는 모델 왕복 호출(Round-trip)을 강제한다. 라우터 호출, 서브에이전트 A 호출, 결과 요약, 서브에이전트 B 호출이 직렬로 이어진다.

토큰 소비량은 계단식으로 늘어나며 P99 응답 시간은 수십 초 단위로 밀린다. 앤트로픽의 실제 엔터프라이즈 배포 비교에 따르면, 단일 루프로 통합한 에이전트는 하위 에이전트 분할 설계 대비 실행 속도가 약 2배 빨랐다.

---

2. 대안: 점진적 공개(Progressive Disclosure) 기반 단일 루프

하위 에이전트를 접어 메인 루프에 합친다는 뜻은 모든 프롬프트와 문서를 하나의 거대한 텍스트로 합쳐 넣는다는 의미가 아니다. 전문성을 버리는 일도 아니다.

핵심은 전문성의 형태 변환과 지식의 온디맨드 로딩이다.

구분	멀티 에이전트 설계	단일 에이전트 통합 설계
역할 정의	독립 서브에이전트 (별도 컨텍스트)	스킬 (업무 절차/매뉴얼 마크다운)
기능 실행	하위 에이전트 내부 함수	도구 (단일 루프에서 직접 호출)
맥락 유지	인수인계 시 요약 전달 (유실 위험)	단일 작업 공간에 원문/결과 보존
지식 주입	에이전트 프롬프트에 정적 사전 배치	메인 루프가 필요 시점에 동적 로드
다중 작업	에이전트 복수 생성	병렬 도구 호출 (Parallel Tool Calling)

🔍 클릭하여 확대

sequenceDiagram
    autonumber
    actor User as 사용자
    participant Agent as 단일 메인 루프
    participant Registry as 스킬/도구 레지스트리
    participant Tool as 백엔드 서비스 (API/DB)

    User->>Agent: "목요일 전 도착 가능한가요? 늦으면 취소해주세요."
    Note over Agent: 원문 질문과 제약 조건을 컨텍스트에 온전히 유지
    Agent->>Registry: 경량 스킬 카탈로그 탐색 (요약 목록만 확인)
    Registry-->>Agent: [배송 확인 절차], [주문 취소 규정] 반환
    Agent->>Registry: [배송 확인 절차] 전문 로드 (Progressive Disclosure)
    Agent->>Tool: get_order_status(), get_shipping_eta() 병렬 호출
    Tool-->>Agent: 주문 상태: 발송 준비, 도착 예정일: 금요일
    Note over Agent: 원문의 "목요일 전" 조건과 금요일 비교 -> 지연 판단
    Agent->>Registry: [주문 취소 규정] 전문 로드
    Agent->>Tool: cancel_order(order_id) 취소 요청
    Tool-->>Agent: 취소 접수 완료
    Agent-->>User: "도착 예정일이 금요일로 확인되어 요청하신 대로 취소 접수했습니다."
  

업무 매뉴얼은 '스킬', 실행은 '도구'로 격하

배송 담당 에이전트에게 쥐여주었던 업무 순서는 shipping_sop.md라는 스킬 매뉴얼로 변환한다. 취소 담당 에이전트의 판단 규칙은 cancellation_policy.md 스킬로 바꾼다. 실제 주문 데이터를 조회하거나 DB 상태를 갱신하는 기능은 결정론적 도구(Tools)로 등록한다.

점진적 공개(Progressive Disclosure)

수십 개의 매뉴얼 전문을 시스템 프롬프트에 처음부터 밀어 넣으면 모델 주의력(Attention)이 분산된다.

단일 에이전트는 시작 시점에 스킬과 도구의 한 줄 요약 목록만 본다. 요청을 해석한 뒤 지금 당장 필요한 매뉴얼만 파일시스템이나 레지스트리에서 읽어온다. 컨텍스트 윈도우를 깨끗하게 유지하면서 방대한 도메인 지식을 다룬다.

도구 병렬 호출은 멀티 에이전트가 아니다

서로 의존성이 없는 세 가지 조회를 수행할 때 별도의 에이전트 3개를 띄울 이유는 없다. 최신 LLM은 단일 턴에서 복수의 도구를 병렬로 호출(Tool Parallelism)한다. 불필요한 에이전트 컨텍스트 스위칭 없이 네트워크 I/O 병렬성만 확보한다.

---

3. 서브에이전트가 반드시 필요한 4가지 영역

단일 루프가 항상 만능은 아니다. 앤트로픽은 다음 네 가지 명확한 기술적 이유가 존재할 때만 하위 에이전트를 분리하라고 명시한다.

🔍 클릭하여 확대

flowchart TD
    Q1{"작업 간 맥락 공유가<br/>깊게 필요한가?"}
    Q1 -- 예 --> Fold["단일 에이전트 루프로 통합<br/>(스킬 + 도구 온디맨드 로드)"]
    Q1 -- 아니오 --> Q2{"독립 병렬 실행이나<br/>컨텍스트 격리가 필수인가?"}

    Q2 -- 아니오 --> Fold
    Q2 -- 예 --> CheckCriteria["서브에이전트 분리 정당화"]

    CheckCriteria --> C1["1. 순수 독립 병렬화<br/>(경쟁사 10곳 재무제표 독립 조사)"]
    CheckCriteria --> C2["2. 노이즈 격리 및 컨텍스트 보호<br/>(수만 토큰 파싱 중간 산출물 폐기)"]
    CheckCriteria --> C3["3. 적대적 독립 검증<br/>(실행 편향 없는 정책/보안 게이트)"]
    CheckCriteria --> C4["4. 도구 선택 공간 축소<br/>(수백 개 도구 중 도메인 특화 서브셋)"]
  

1. 순수 독립 병렬화(Real Parallelism)

경쟁 기업 5곳의 공시 자료를 각각 분석해 요약본을 비교하는 작업이다. 각 기업 분석은 상호 대화 맥락을 알 필요가 없다. 규격화된 입력과 출력을 정의하고 독립된 하위 에이전트를 띄워 병렬 처리하는 방식이 훨씬 빠르다.

2. 노이즈 격리와 컨텍스트 보호(Context Window Protection)

웹 브라우징, 긴 로그 파싱, 대형 소스코드 정적 분석처럼 수만 토큰의 중간 쓰레기 텍스트가 발생하는 작업이다. 이 데이터가 메인 루프에 그대로 쏟아져 들어오면 컨텍스트가 오염되어 메인 판단력이 급격히 떨어진다. 일회성 샌드박스 서브에이전트에게 작업을 맡긴 뒤 최종 요약 JSON만 메인 루프로 회수한다.

3. 적대적/독립적 검증 게이트(Adversarial Verification)

코드를 작성한 에이전트가 스스로 보안과 기능을 검증하면 확증 편향에 빠진다. 메인 루프의 추론 히스토리를 모르는 백지 상태의 독립 검증 에이전트가 코드와 테스트 명세만 보고 냉정하게 결함을 판정해야 한다.

4. 도구 선택 공간 축소(Tool Space Partitioning)

단일 모델이 다루어야 할 도구가 수백 개를 넘어가면 도구 선택 정확도가 떨어진다. 도메인 경계가 명확한 하위 에이전트에 필요한 도구 5~10개만 쥐여주어 오작동을 차단한다.

---

4. 안전한 통합 마이그레이션 전략

이미 복잡하게 얽힌 멀티 에이전트 시스템을 단번에 뒤엎으면 장애가 난다. 앤트로픽이 제안하는 점진적 접기(Folding) 절차는 데이터 기반으로 전개된다.

🔍 클릭하여 확대

flowchart LR
    E["1. Golden Eval 구축<br/>(대표 복합 사례 10~20개)"] --> B["2. 베이스라인 측정<br/>(성공률, 토큰, 지연시간)"]
    B --> F["3. 맥락 공유 큰 서브 접기<br/>(에이전트 -> 스킬/도구)"]
    F --> T["4. 동일 평가 재실행<br/>(A/B 비교 검증)"]
    T --> D{"지표 개선 확인"}
    D -- 통과 --> Next["다음 서브에이전트 접기"]
    D -- 하락 --> Rollback["경계 유지 및 튜닝"]
  

1. 엔드투엔드 골든 케이스(Golden Eval) 수립: 실제 고객 질문 중 복합 제약 조건이 걸린 대표 사례 10~20개를 선별한다. 입수 조건, 실패 판정 기준을 고정한다.
2. 현행 아키텍처 기준선 측정: 현재 멀티 에이전트 파이프라인에서 작업 완료율, 제약 조건 누락 빈도, P99 지연 시간, 호출당 총 토큰을 측정한다.
3. 결합도가 가장 높은 서브에이전트 하나 선택: 라우터와 대화를 가장 많이 주고받는 하위 에이전트 1개를 지목한다. 에이전트 인스턴스를 삭제하고 프롬프트를 스킬 마크다운 파일로, 기능을 도구로 바꾼다.
4. 골든 케이스 재실행과 A/B 대조: 단일 루프로 접은 상태에서 동일한 20개 사례를 실행한다. 제약 조건 보존율이 올라갔는지, 지연 시간과 비용이 감소했는지 지표로 검증한다.
5. 데이터 기반 반복: 지표가 개선되었을 때만 통합을 확정하고, 다음 하위 에이전트를 차례로 메인 루프에 흡수한다.

---

5. 아키텍처 설계 3대 판별 기준

새로운 에이전트 시스템을 설계하거나 기존 구조를 정리할 때 다음 세 가지 질문을 던진다.

1. 두 작업이 같은 대화 맥락과 중간 결과를 공유하는가?
   - 그렇다면 분리하지 말고 단일 루프의 스킬과 도구로 통합한다.
2. 다른 에이전트의 이전 맥락을 전혀 몰라도 독립 실행이 가능한가?
   - 그렇다면 명확한 입출력 스키마를 정의하고 독립 서브에이전트로 분리한다.
3. 구조 변경 전후의 엔드투엔드 지표를 숫자로 확인했는가?
   - 역할 분할의 우아함에 현혹되지 않고 골든 데이터셋의 성공률, 응답 시간, 비용으로 아키텍처를 증명한다.