멀티 에이전트 아키텍처: 단일 Claude로는 부족할 때

한 제약회사가 일탈(deviation) 조사를 위해 멀티 에이전트 시스템을 구축했습니다. 사실 추출, 문서 검색, 근본 원인 분석, 규제 준수 검토, 보고서 생성 등 5개의 특화된 에이전트가 Claude Opus 기반의 코디네이터(coordinator)에 의해 오케스트레이션되는 구조였습니다.

데모에서는 환상적으로 작동했습니다. 하지만 실제 프로덕션 환경에서는 조사 1건당 4달러의 비용과 90초의 시간이 소요되었으며, 문서 검색 에이전트가 배치 기록(batch record) 번호를 환각(hallucination)해냈을 때 조용히 실패(silent failure)했습니다. 반면, 잘 구조화된 프롬프트와 결정론적(deterministic) 검색 파이프라인을 갖춘 단일 에이전트 버전은 0.30달러의 비용으로 20초 만에 완료되었고, 배치 기록이 존재하지 않을 때는 명확하게 에러를 발생시키며 실패(fail loudly)했습니다.

멀티 에이전트 시스템 자체가 원칙적으로 틀렸던 것은 아닙니다. 그 문제에 맞지 않았을 뿐입니다. 이 차이를 아는 것이 바로 수많은 프레임워크의 README만 읽은 사람과 진정한 아키텍트를 구분 짓는 기준입니다.

진짜 질문 (The Real Question)

질문은 결코 “멀티 에이전트 시스템을 어떻게 구축할 것인가”가 아닙니다. 질문은 멀티 에이전트를 구축해야 하는가입니다.

Anthropic의 공식 가이던스는 직설적입니다. 가장 성공적인 구현체들은 복잡한 프레임워크 대신 단순하고 조합 가능한(composable) 패턴을 사용합니다. 대부분의 프로덕션 유스케이스에는 완전 자율적인 멀티 에이전트 시스템이 필요하지 않습니다. 명확한 경계를 가진 잘 구조화된 오케스트레이션이 필요할 뿐입니다.

멀티 에이전트 시스템은 상당한 오버헤드를 수반합니다. 에이전트가 하나 추가될 때마다 또 다른 장애 지점(failure point)과 유지보수해야 할 프롬프트가 늘어납니다. 또한 테스트 결과, 동일한 작업에 대해 멀티 에이전트 구현체는 단일 에이전트보다 일반적으로 3배에서 10배 더 많은 토큰을 사용합니다. 이러한 비용은 컨텍스트 복제, 조율을 위한 메시지, 그리고 인계(handoff)를 위한 요약 과정에서 발생합니다.

다음의 세 가지 검증된 제약 조건 중 하나에 해당할 때에만 멀티 에이전트를 사용하십시오:

컨텍스트 오염(Context pollution): 하위 작업이 메인 작업과 무관한 1,000개 이상의 토큰을 생성하는 경우입니다. 예: 기술적 문제를 진단하는 과정에서 고객의 전체 주문 내역(2,000개 이상의 토큰)을 가져오는 경우입니다. 해결책: 50개 토큰 분량의 요약본만 반환하는 격리된 에이전트를 생성하는 것입니다.

병렬화(Parallelization): 속도가 아니라 탐색의 폭(breadth)이 필요한 경우입니다. 리드(lead) 에이전트가 질문을 여러 측면으로 분해하고, 서브에이전트들을 동시에 실행한 뒤 결과를 종합합니다. 이때 얻는 이점은 철저함(thoroughness)입니다. 동일한 시간 안에 단일 에이전트가 처리할 수 있는 것보다 훨씬 더 넓은 범위를 다룰 수 있습니다.

도구 과부하(Tool overload): 사용할 도구가 15~20개를 넘어가거나 서로 무관한 도메인에 걸쳐 있어 모델이 도구를 올바르게 선택하지 못하는 경우입니다. 특화 에이전트로 분리하기 전에, 모델이 필요할 때 도구를 탐색할 수 있게 해주는 ‘도구 검색(Tool Search)’ 도구를 먼저 시도해 보십시오. 이것만으로도 토큰 사용량을 최대 85%까지 줄일 수 있습니다.

이러한 제약 조건 중 어느 것에도 해당하지 않는다면, 더 나은 프롬프트 작성, 컨텍스트 압축, 또는 정교한 검색 파이프라인을 갖춘 단일 에이전트가 멀티 에이전트 시스템보다 훨씬 저렴한 비용으로 더 뛰어난 성능을 발휘할 것입니다.

허브 앤 스포크 패턴 (The Hub-and-Spoke Pattern)

멀티 에이전트를 구축할 때 가장 지배적인 아키텍처는 허브 앤 스포크(hub-and-spoke) 패턴입니다. 코디네이터(coordinator) 에이전트가 중앙에 위치하고, 특화된 서브에이전트들이 그 주변을 바퀴살처럼 둘러쌉니다. 모든 커뮤니케이션은 허브를 통해서만 흐릅니다.

             ┌──────────────┐
             │  Coordinator │
             └──────┬───────┘
           ┌────────┼────────┐
           ▼        ▼        ▼
     [Research]  [Analysis] [Synthesis]
      subagent    subagent   subagent

이 패턴을 지배하는 세 가지 규칙이 있습니다:

규칙 1: 모든 커뮤니케이션은 코디네이터를 통과해야 합니다. 서브에이전트끼리 직접 대화해서는 안 됩니다. 이는 멀티 에이전트 설계에서 가장 흔하게 오해되는 개념입니다. 자격 시험에서도 이를 집중적으로 파고듭니다. 서브에이전트 A의 출력을 서브에이전트 B로 직접 전달하라는 함정 보기가 자주 등장합니다. 코디네이터를 거쳐야 하는 이유는 관측 가능성(모든 메시지를 한곳에 로깅할 수 있음), 일관된 오류 처리, 그리고 통제된 정보 흐름 때문입니다.

규칙 2: 서브에이전트는 격리된 컨텍스트를 가집니다. 코디네이터가 서브에이전트를 생성할 때, 해당 서브에이전트는 코디네이터가 프롬프트에 명시적으로 포함한 정보만을 가지고 시작합니다. 사용자가 의도적으로 전달하지 않는 한 시스템 프롬프트도, 이전 메시지 기록도 전혀 공유되지 않습니다. 이러한 격리가 바로 깔끔한 병렬 처리를 가능하게 합니다. 서브에이전트들이 공통 컨텍스트를 공유하거나 변경하지 않기 때문에 완벽한 동시 실행이 가능해지는 것입니다.

규칙 3: 작업의 분해와 종합은 코디네이터의 몫입니다. 무엇을 누구에게 위임할지, 그리고 결과를 어떻게 조합할지는 코디네이터가 결정합니다. 최종 결과물이 미흡하다면, 이는 워커(worker)의 문제가 아니라 코디네이터의 분해(decomposition) 과정에서 발생한 실패입니다.

Anthropic의 실제 구축 방식 (How Anthropic Built Theirs)

Anthropic의 리서치(Research) 기능은 대표적인 프로덕션 구현 사례입니다. 사용자가 질문을 제출하면 리드(lead) 에이전트가 이를 분석하여 전략을 수립하고, 다양한 측면을 동시에 탐색하기 위해 서브에이전트들을 생성합니다. 각 서브에이전트는 독립적으로 웹 검색을 수행하고, 인터리브드 씽킹(interleaved thinking)을 통해 결과를 평가한 뒤 조사 결과를 리드 에이전트에 반환합니다. 리드는 이 결과들을 종합하여 추가 조사가 필요한지 판단하고, 추가 서브에이전트를 실행하거나 취합된 조사 결과를 인용 에이전트(citation agent)로 전달하여 모든 주장의 출처를 명확히 매핑하도록 합니다.

수치는 매우 인상적입니다. Claude Opus 4를 리드로 두고 Claude Sonnet 4를 워커로 활용한 멀티 에이전트 시스템은 내부 리서치 벤치마크에서 단일 에이전트 Opus 4보다 90.2% 더 뛰어난 성능을 보였습니다. 성능 편차의 95%는 세 가지 요인으로 설명되었습니다: 토큰 사용량(단독으로 80% 차지), 도구 호출 횟수, 그리고 모델 선택이었습니다.

하지만 비용 역시 놀라울 정도로 큽니다. 멀티 에이전트 시스템은 일반 챗 인터랙션보다 약 15배 더 많은 토큰을 소모합니다. 단일 에이전트는 약 4배를 사용합니다. 이러한 경제성은 해당 작업이 창출하는 가치가 지출 비용을 정당화할 수 있을 때에만 성립합니다.

그들이 얻은 교훈 (What They Learned)

오케스트레이터가 정밀하게 위임하도록 훈련하십시오. 초기 버전에서는 리드 에이전트가 “반도체 공급 부족에 대해 조사하라”와 같이 모호한 지시를 내릴 수 있었습니다. 그 결과 서브에이전트 간 작업 중복이 발생했습니다. 한 에이전트가 2021년 자동차 반도체 위기를 조사하는 동안, 다른 두 에이전트는 아무런 분업 체계 없이 독립적으로 2025년 공급망을 조사했습니다. 해결책: 명확한 목표, 기대하는 출력 형식, 사용할 도구에 대한 가이드라인, 그리고 명시적인 작업 경계를 담은 상세한 작업 명세서를 전달하는 것이었습니다.

질문의 복잡도에 맞게 리소스를 조절하십시오. 에이전트는 스스로 적절한 노력의 수준을 판단하는 데 어려움을 겪습니다. 명시적인 스케일링 규칙이 없었던 초기 버전에서는 단순한 사실 확인 질문에도 10개의 서브에이전트를 생성하곤 했습니다. 해결책: 프롬프트에 명확한 규칙을 내장하는 것입니다. 단순 사실 확인에는 1개의 에이전트와 3~~10회의 도구 호출을 배정합니다. 직접적인 비교 분석에는 각각 10~~15회의 도구 호출을 수행하는 2~4개의 서브에이전트를 할당합니다. 복잡한 심층 연구에는 명확히 역할이 분담된 10개 이상의 서브에이전트를 배치합니다.

넓게 시작하여 점진적으로 좁혀가십시오. 에이전트는 기본적으로 지나치게 구체적인 검색 쿼리를 생성하여 검색 결과가 거의 나오지 않게 만드는 경향이 있습니다. 해결책은 실제 전문가들이 리서치를 수행하는 방식을 모방하는 것입니다. 짧고 포괄적인 검색어로 시작하여 어떤 정보가 있는지 파악한 다음, 초점을 점진적으로 좁혀 나가는 것입니다.

서브에이전트의 결과물은 코디네이터뿐 아니라 파일시스템에도 출력해야 합니다. 보고서나 데이터와 같은 구조화된 산출물의 경우, 서브에이전트가 영구 스토리지에 아티팩트를 직접 작성하고 코디네이터에게는 경량화된 참조(reference)만 전달하도록 구성하십시오. 이렇게 하면 다단계 처리 과정에서 정보가 유실되는 것을 방지하고, 대규모 출력을 대화 기록(conversation history)을 통해 복사하면서 발생하는 토큰 오버헤드를 대폭 줄일 수 있습니다.

컨텍스트 격리는 선택이 아닌 필수입니다 (Context Isolation Is Not Optional)

이 내용은 실제 실무 설계에서 가장 많은 실패가 발생하는 지점이므로 별도의 섹션으로 다룰 가치가 있습니다.

코디네이터가 3개의 리서치 에이전트가 조사한 결과를 종합하기 위해 합성(synthesis) 서브에이전트를 생성할 때, 합성 에이전트는 리서치 에이전트들이 무엇을 발견했는지 자동으로 알지 못합니다. 코디네이터가 조사 결과를 명시적으로 전달해야 하며, 이때 단순 텍스트 덩어리를 이어 붙인 형태가 아니라 반드시 구조화된 형식으로 전달해야 합니다.

구조화된 형식 (Structured):

{
  "findings": [
    {
      "content": "Market grew 23% in 2025",
      "source_url": "https://...",
      "source_title": "Industry Report 2025",
      "retrieved_at": "2026-07-12"
    }
  ]
}

구조화되지 않은 형식 (Not structured):

Agent 1 found: Market grew 23% in 2025 (source: Industry Report).
Agent 2 found: Competitor X launched product Y.
Agent 3 found: Regulatory changes expected Q4.

구조화된 형식은 출처 표기(attribution)를 온전히 보존하여 합성 에이전트가 소스를 정확히 인용할 수 있도록 하며, 단계별 인계 과정에서 정보가 왜곡되고 누락되는 ‘말전달 게임(game of telephone)’ 현상을 방지합니다.

컨텍스트 중심 분해 (Context-Centric Decomposition)

대부분의 팀은 문제의 유형에 따라 분해합니다. 한 에이전트는 기능을 작성하고, 다른 에이전트는 테스트를 작성하며, 세 번째 에이전트는 리뷰를 수행하는 방식입니다. 이는 끊임없는 조율 오버헤드를 유발하며, 핸드오프가 일어날 때마다 정확도가 떨어지는 말전달 게임을 초래합니다.

Anthropic의 원칙은 다음과 같습니다: 문제의 단계가 아니라 **컨텍스트의 경계(context boundaries)**를 기준으로 분해하십시오. 효과적인 경계의 예로는 독립적인 리서치 경로(‘아시아 시장 트렌드’ 대 ‘유럽 시장 트렌드’), 깔끔한 API 계약을 가진 분리된 컴포넌트, 블랙박스 검증 작업 등이 있습니다. 반면 문제가 되는 경계는 동일한 작업의 순차적 단계, 강하게 결합된 컴포넌트, 공유 상태(shared state)가 필요한 작업 등입니다.

Claude Agent SDK: 실무에서의 작동 방식 (The Claude Agent SDK: How It Works in Practice)

Claude를 기반으로 구축하는 경우, Agent SDK가 핵심 프리미티브(primitives)를 제공합니다.

Task 도구 (The Task Tool)

Task 도구는 서브에이전트를 생성합니다. 코디네이터의 allowedTools 목록에는 반드시 "Task"가 포함되어야 합니다. 이것이 없으면 코디네이터는 서브에이전트를 호출할 수 없습니다.

options = ClaudeAgentOptions(
    allowed_tools=["Read", "Grep", "Glob", "Task"],
    system_prompt="You are a research coordinator...",
)

각 서브에이전트는 이름, 설명, 시스템 프롬프트, 제한된 도구 목록, 모델 선택이 포함된 고유한 AgentDefinition을 가집니다. 빠른 분류 작업에는 Haiku를, 균형 잡힌 실행에는 Sonnet을, 복잡한 추론이나 종합 작업에는 Opus를 사용하십시오.

에이전틱 루프 (The Agentic Loop)

루프는 단순합니다:

도구 정의 및 대화 기록과 함께 Claude에 요청 전송
응답 수신
stop_reason 확인: "tool_use"는 도구를 실행하고 루프를 계속함을 의미, "end_turn"은 작업 완료를 의미
결과를 대화 기록에 추가
1단계로 이동

여기서 가장 중요한 핵심: stop_reason이 루프 종료를 판단할 수 있는 유일하게 신뢰할 수 있는 신호라는 점입니다. 작업을 계속할지 여부를 결정하기 위해 어시스턴트의 텍스트 본문을 파싱하지 마십시오. “작업 완료(task complete)” 같은 특정 문구가 있는지 검사해서는 절대 안 됩니다. 구조화된 API 필드는 결정론적(deterministic)이지만, 자연어 파싱은 그렇지 않습니다.

훅(Hooks): 결정론이 살아 숨쉬는 곳 (Hooks: Where Determinism Lives)

훅(Hook)은 에이전트 라이프사이클의 특정 시점(도구가 실행되기 전(PreToolUse), 도구 실행 결과가 반환된 후(PostToolUse), 서브에이전트가 시작되거나 종료될 때 등)에 SDK가 호출하는 함수입니다.

100% 보장된 규정 준수(compliance)가 필요한 모든 작업에는 훅을 사용하십시오:

PreToolUse: 정책을 위반하는 작업을 차단합니다. 500달러를 초과하는 환불을 방지하는 훅은 100%의 확률로 항상 실행되는 코드입니다. 반면 모델에게 “500달러를 초과하여 환불하지 말라”고 프롬프트로 지시하는 것은 확률적인 권고일 뿐이며 약 1%의 확률로 실패합니다. 규제 대상 산업에서 1%의 실패율은 절대 용납될 수 없습니다.
PostToolUse: 모델이 데이터를 확인하기 전에 데이터를 정규화합니다. 세 개의 서로 다른 MCP 도구가 각각 Unix epoch, ISO 8601, 숫자 상태 코드로 타임스탬프를 반환한다면, PostToolUse 훅이 이를 모두 일관된 형식으로 변환합니다. 이를 통해 모델이 제각각인 형식을 파싱하느라 불필요하게 토큰을 낭비하지 않도록 합니다.
SubagentStart / SubagentStop: 병렬 작업 생성을 추적하고 완료된 워커들로부터 결과를 취합합니다.

원칙은 분명합니다: 오케스트레이션 계층은 결정론(determinism)을 제공하고, LLM은 추론(reasoning)을 제공합니다. 이 경계를 결코 모호하게 만들지 마십시오.

허브 앤 스포크를 넘어선 오케스트레이션 패턴 (Orchestration Patterns Beyond Hub-and-Spoke)

허브 앤 스포크가 기본 패턴이지만, 항상 최선의 선택인 것은 아닙니다.

순차적 파이프라인 (Sequential Pipeline)

에이전트들이 고정된 순서로 실행됩니다. 각 에이전트는 이전 에이전트의 출력을 변환합니다.

Extract → Classify → Analyze → Format → Output

단계들이 예측 가능하고 각 단계가 이전 단계의 결과에 종속될 때 사용합니다. 위험 요인: 명시적인 에러 처리 분기를 설계해두지 않으면 2단계가 실패했을 때 전체 파이프라인이 중단됩니다. 인계 지점에서의 컨텍스트 유실이 가장 주요한 실패 모드입니다.

라우터 (Router)

경량 분류기(classifier) 에이전트가 들어오는 요청을 검토하고 이를 적절한 전문가 에이전트로 라우팅합니다. 라우터는 실질적인 작업을 전혀 수행하지 않으며, 오직 분류만 담당합니다.

Customer Request → Router → [Billing | Technical | Sales]

모든 도구와 시스템 프롬프트를 단일 컨텍스트에 로드할 경우 성능이 저하되는 다중 도메인 지원 환경에 사용합니다. 비용 최적화 관점: 쉬운 질문은 Haiku로, 어려운 질문은 Sonnet이나 Opus로 라우팅합니다.

평가자-최적화자 루프 (Evaluator-Optimizer Loop)

한 에이전트가 결과를 생성하고, 다른 에이전트가 명확한 기준에 따라 이를 평가하며, 출력이 통과 기준을 만족할 때까지 반복(iterate)합니다.

Generator → Evaluator → Pass? → Output
    ↑                   │
    └── Feedback ───────┘

명확히 정의된 품질 기준이 있고 반복적인 개선을 통해 산출물이 측정 가능할 정도로 향상될 때 사용합니다. 함정: 무한 루프입니다. 항상 최대 반복 횟수를 설정하십시오. 더 미묘한 함정: 평가자가 단 하나의 항목만 대충 확인하고 ’통과(PASS)’로 처리해버리는 ‘조기 성공(early victory)’ 문제입니다. 완화책: “제대로 작동하는지 확인하라”가 아니라 “전체 테스트 스위트를 실행하고 모든 실패 사항을 보고하라”와 같이 구체적인 검증 기준을 요구하십시오.

검증 서브에이전트 (Verification Subagent)

다양한 도메인에서 일관되게 뛰어난 성능을 보이는 패턴입니다. 메인 에이전트가 작업을 완료한 후, 완성된 아티팩트와 명확한 성공 기준, 검증용 도구를 갖춘 검증자(verifier) 서브에이전트를 생성합니다. 검증자는 전체 작업 빌드 이력을 알 필요가 없으며 오직 블랙박스 검증만 수행합니다. 검증자가 결과물이 어떻게 생성되었는지에 대한 요약본이 아니라 최종 결과물 자체를 직접 검사하므로 말전달 게임 문제를 우회할 수 있습니다.

프로덕션 환경의 제약 사항 (Production Constraints)

서킷 브레이커 (Circuit Breakers)

멀티 에이전트 루프는 서브에이전트를 재귀적으로 호출하거나 자가 교정(self-correction)을 반복하여 무한 실행에 빠질 수 있습니다. 최대 턴 수, 실행당 토큰 상한선, 시간 기반 타임아웃과 같은 엄격한 한계선(hard boundaries)을 구현하십시오. 이는 프롬프트 지시문이 아니라 결정론적인 코드 제어여야 합니다.

비용의 현실 (The Cost Reality)

단일 Claude 호출 비용은 몇 센트에 불과합니다. 그러나 5개의 에이전트가 각각 3회의 도구 호출을 수행하고 종합 및 검증까지 거치는 멀티 에이전트 오케스트레이션 루프는 1회 실행당 2~5달러의 비용이 쉽게 발생할 수 있습니다. 하루 수천 건의 요청에 이를 곱해보면 경제성이 급격히 악화됩니다. 모델 티어링(tiering)은 필수입니다. 각 역할에 대해 요구 역량을 충족하는 가장 저렴한 모델을 배치하십시오.

휴먼 인 더 루프 (Human-in-the-Loop)

코드 병합, 결제 실행, CAPA 승인 등 상태를 변경하는(state-mutating) 작업에는 사람의 승인 게이트(human approval gate)를 배치하십시오. 하지만 신중하게 설계해야 합니다. 프로덕션 데이터에 따르면 모든 작업에 승인을 요구할 경우 사용자의 약 93%가 내용을 읽지도 않고 승인해버립니다. 파급력이 큰 결정에만 승인 게이트를 적용하고, 나머지는 모델 기반 가드레일로 자동화하십시오.

관측 가능성 (Observability)

멀티 에이전트 시스템은 기본적으로 불투명합니다. 다음 항목들이 반드시 필요합니다:

모든 에이전트 호출에 걸쳐 전파되는 추적 ID(Trace ID)
결정과 추론 과정에 대한 에이전트별 로깅
병목 지점을 파악하기 위한 지연 시간 분석(Latency breakdown)
요청당 에이전트별 비용 추적(Cost attribution)
규제 준수를 위한 의사결정 감사 추적(Audit trail)

규제 대상 산업에서 이는 선택 사항이 아닙니다. 어떤 에이전트가 어떤 결정을 왜 내렸는지 설명할 수 없다면, 해당 시스템은 밸리데이션(검증)을 통과할 수 없습니다.

규제 대상 산업에 멀티 에이전트가 부합하는 이유 (When Multi-Agent Maps to Regulated Industries)

멀티 에이전트 아키텍처는 규제 대상 조직이 일하는 기존 방식과 자연스럽게 맞아떨어집니다. QA(품질보증), 제조(Manufacturing), 밸리데이션(Validation), RA(규제업무)는 각각 명확히 정의된 책임과 문서화된 인계 절차를 가지고 있습니다. 각 에이전트가 감사 가능한 단 하나의 역할만을 전담할 때, AI 시스템은 훨씬 더 거버넌스를 갖추기 쉬워집니다.

일탈 조사 시스템을 예로 들어보겠습니다:

에이전트 (Agent)	역할 (Role)	도구 (Tools)	모델 (Model)
Fact Extractor (사실 추출기)	일탈 보고서에서 구조화된 사실 추출	Document parser	Haiku
Document Retriever (문서 검색기)	관련 SOP, 배치 기록, 과거 일탈 내역 검색	Vector DB, SQL	Sonnet
Root Cause Analyzer (근본 원인 분석기)	증거로부터 개연성 있는 원인 도출	없음 (추론 전용)	Opus
Compliance Checker (컴플라이언스 점검기)	21 CFR Part 211, ICH Q10 기준 적합성 검증	Regulation database	Sonnet
Report Generator (보고서 생성기)	출처 인용이 포함된 조사 보고서 생성	Template engine	Sonnet
Verification Agent (검증 에이전트)	원천 증거와 보고서 주장 간 일치 여부 검증	Document comparison	Sonnet

각 에이전트는 좁은 범위의 역할, 제한된 도구 세트, 그리고 명확히 정의된 출력 계약(contract)을 가집니다. 코디네이터는 에이전트들 사이에 구조화된 컨텍스트를 전달합니다. 훅(Hook)은 검증을 거치지 않은 보고서가 최종 확정되지 않도록 강제합니다. 그리고 인간 QA 검토자가 최종 산출물 패키지를 승인합니다.

이러한 책임의 분리는 추론 품질을 높이고 컨텍스트 오염을 줄이며, 시스템을 밸리데이션하고 테스트하며 감사관(auditor)에게 설명하기 훨씬 쉽게 만듭니다.

의사결정 체크리스트 (The Decision Checklist)

멀티 에이전트를 구축하기 전에 다음 항목을 점검하십시오:

더 나은 프롬프트, 정교한 검색(retrieval), 또는 도구 검색(tool search)을 갖춘 단일 에이전트로 해결할 수 있는가? 그렇다면 여기서 멈추십시오.
컨텍스트 오염, 명확한 병렬화 잠재력, 또는 도구 과부하가 존재하는가? 그렇지 않다면 여기서 멈추십시오.
코디네이터의 역할을 정의하십시오: 분해, 위임, 종합. 워커가 또 다른 워커를 생성해서는 안 됩니다.
각 서브에이전트의 도구와 모델을 제한하십시오. 단순한 것이 더 강력합니다.
명시적이고 포괄적인 검증 항목을 갖춘 검증 서브에이전트를 추가하십시오.
실패를 염두에 두고 설계하십시오: 3~10배의 토큰 비용 예산을 책정하고, 워커의 부분적 실패에 대비하며, 첫날부터 관측 가능성을 구축하십시오.
서킷 브레이커를 추가하십시오: 최대 턴 수, 비용 상한선, 시간제한.
오케스트레이션 계층을 결정론적으로 만드십시오. LLM에게 추론을 맡기되, 규칙의 강제는 코드가 담당하게 하십시오.

핵심 요약 (The Bottom Line)

멀티 에이전트 시스템은 강력한 아키텍처 도구입니다. 동시에 AI 엔지니어링에서 가장 과잉 처방되는 해결책이기도 합니다. 멀티 에이전트로 성공하는 팀들은 이를 마지못해 구축하는 팀들입니다. 즉, 단일 에이전트 접근 방식으로는 도저히 해당 작업을 처리할 수 없음이 명백히 입증된 후에야 비로소 멀티 에이전트를 도입합니다.

멀티 에이전트를 구축해야 한다면 아키텍처를 최대한 단순하게 유지하십시오: 허브 앤 스포크 코디네이터, 집중된 도구 세트를 갖춘 격리된 서브에이전트, 구조화된 컨텍스트 전달, 훅을 통한 결정론적 규칙 강제, 그리고 프로덕션에 배포되기 전 필수적인 검증 단계를 갖추는 것입니다.

지능은 개별 에이전트가 아니라 바로 ’조율(coordination)’에 있습니다. 각 에이전트가 하나의 일을 아주 잘 해내고, 코디네이터가 무엇을 위임할지 정보에 입각한 판단을 내리며, 문제가 발생했을 때 전체 파이프라인이 즉각 명확하게 에러를 알리고 복구 가능하도록(fail loudly and recoverably) 시스템을 설계하십시오.

이것이 바로 멀티 에이전트 시스템을 ’아키텍처링’한다는 것의 진정한 의미입니다. 단순히 5개의 Claude 인스턴스가 서로 대화하게 만드는 것이 아니라, 단일 에이전트가 혼자 모든 것을 처리하는 것보다 더 저렴하고, 빠르며, 안정적인 방식으로 협업하도록 만드는 것입니다.

GxPChat