캐스케이드 문제: 멀티 에이전트 시스템이 운영 환경에서 무너지는 이유 (그리고 실제로 살아남는 5가지 패턴)

문서 처리 에이전트(document-processing agent)가 개발 단계에서는 완벽하게 작동합니다. 파일을 읽고, 데이터를 추출하고, 결과를 데이터베이스에 기록하며, 확인 웹훅(webhook)을 보냅니다. 50개의 테스트 케이스를 통과합니다. 하지만 배포 2주 후, 100개의 인스턴스가 동시에 실행되자 데이터베이스에는 40,000개의 중복 레코드가 쌓이고, 3개의 다운스트림 서비스(downstream services)는 수천 개의 잘못된 웹훅을 수신하며, 공유 설정 파일은 동시에 실행된 두 에이전트에 의해 절반이 덮어씌워집니다.

에이전트가 고장 난 것이 아닙니다. 시스템이 고장 난 것입니다. 왜냐하면 개별 에이전트 테스트 중 그 어떤 것도 다른 에이전트와 세상을 공유해야 할 필요가 없었기 때문입니다.

이것이 바로 캐스케이드 문제(cascade problem)이며, 대부분의 멀티 에이전트 시스템(multi-agent systems)이 운영 환경에서 실패하는 단 하나의 이유입니다. 모델 품질(model quality) 때문이 아닙니다. 프롬프트 엔지니어링(prompt engineering) 때문도 아닙니다. 오케스트레이션 로직(orchestration logic) 때문도 아닙니다. 실패의 원인은 인프라(infrastructural)에 있습니다. 이는 여러 에이전트가 공유 리소스(shared resources)에서 동시에 작동할 때만 나타나며, 설계상 격리되어 실행되는 단위 테스트(unit tests)로는 잡아낼 수 없습니다.

Turion, Anthropic의 자체 멀티 에이전트 연구 시스템, 그리고 LangGraph에서 Claude Agent SDK에 이르는 오케스트레이션 프레임워크(orchestration frameworks)의 운영 환경 배포 사례를 분석한 결과, 명확한 그림이 그려집니다. 5가지 패턴은 실제로 운영 환경에서 살아남고, 3가지 패턴은 데모에서는 훌륭해 보이지만 규모가 커지면 붕괴하며, 이들의 차이는 캐스케이드 문제를 어떻게 처리하느냐에 달려 있습니다.

캐스케이드 문제: 멀티 에이전트 시스템이 사멸하는 곳

1,200개 이상의 운영 환경 배포 사례에 대한 ZenML의 분석에 따르면, 운영 환경 실패의 가장 흔한 원인은 모델 품질이 아니라 인프라 및 통합 실패(infrastructure and integration failure)였습니다. 모델은 올바르게 동작했습니다. 시스템이 동작하지 않았을 뿐입니다.

세 가지 캐스케이드 모드(cascade modes)가 반복적으로 나타납니다:

재시도 증폭 (Retry amplification). 대부분의 에이전트 아키텍처는 여러 독립적인 계층에 재시도 로직 (retry logic)을 가지고 있습니다. HTTP 클라이언트는 네트워크 오류를 재시도하고, 도구 래퍼 (tool wrapper)는 실패한 도구 호출을 재시도하며, 에이전트 루프 (agent loop)는 실패한 단계를 재시도합니다. 만약 세 계층이 각각 실패 시 세 번씩 재시도한다면, 단 하나의 상위 오류가 27개의 하위 호출을 발생시킵니다. 단 한 번의 네트워크 타임아웃이 결제 제공업체에 대한 27번의 API 호출로 이어지는 것입니다.

동시 변이 (Concurrent mutation). JSON 설정 파일을 읽고, 항목을 추가한 뒤, 다시 쓰는 두 개의 에이전트는 한 에이전트의 항목을 조용히 유실하게 됩니다. 두 번째 쓰기 작업이 오류 없이 첫 번째 작업을 덮어쓰기 때문입니다. 이것은 모델의 실패가 아닙니다. 에이전트는 지시받은 대로 정확히 수행했을 뿐입니다. 이는 분산 데이터베이스 엔지니어들이 수십 년 동안 해결해 온 것과 동일한 전형적인 검사 시점과 사용 시점 사이의 차이 (TOCTOU, time-of-check to time-of-use) 레이스 컨디션 (race condition)입니다.

세션 간 상태 오염 (State corruption across sessions). 중간 결과물을 공유 캐시 (shared cache)에 쓰는 에이전트는 상호 작용하도록 설계되지 않은 세션들 사이에 암시적인 의존성을 생성합니다. 다음 요청에서 해당 캐시를 로드하면, 다른 사용자의 세션에서 발생한 오래된 데이터 (stale data)를 바탕으로 추론하게 됩니다.

공통점은 다음과 같습니다: 이러한 실패들은 단일 에이전트 테스트에서는 보이지 않으며, 멀티 에이전트 운영 환경에서는 불가피합니다. 이는 부수적인 문제가 아니라 구조적인 문제입니다.

운영 환경에서 살아남는 5가지 패턴

패턴 1: 관리자 + 전문가 (Supervisor + Specialists)

하나의 관리자 에이전트 (supervisor agent)가 작업을 분해하고 하위 작업을 전문가 에이전트 (specialist agents)에게 라우팅합니다. 전문가들은 이를 실행하고 결과를 반환합니다. 관리자는 이를 통합합니다.

이것은 2026년의 기본 운영 패턴이며, 그럴만한 충분한 이유가 있습니다. Abemon의 운영 데이터에 따르면, 4개의 하위 에이전트를 사용하는 관리자 패턴은 인간의 개입 없이 요청의 96.3%를 처리했으며, 요청당 평균 비용은 $0.08, p95 지연 시간 (latency)은 12초를 기록했습니다.

핵심 통찰: Supervisor (감독관) 패턴이 작동하는 이유는 결함 격리 (fault containment)가 내장되어 있기 때문입니다. 문서 추출 서브 에이전트 (sub-agent)가 실패하더라도, 감독관은 이미 작업을 완료한 다른 서브 에이전트들의 상태를 잃지 않으면서 재시도하거나, 폴백 (fallback)을 사용하거나, 인간의 검토로 에스컬레이션 (escalate)할 수 있습니다.

Claude Agent SDK를 사용하면 다음과 같은 모습이 됩니다:

import asyncio
from claude_agent_sdk import query, ClaudeAgentOptions, AgentDefinition

...

라우팅 레이어 (routing layer, 어떤 전문가가 무엇을 처리할지 결정하는 단계)는 분류당 $0.0003–0.001 수준인 Haiku와 같은 작은 모델을 사용하거나, 간단한 규칙 기반 로직 (rule-based logic)을 사용할 수 있습니다. 라우팅에 Opus 토큰을 낭비하지 마세요.

실패하는 경우: 감독관은 단일 장애점 (single point of failure)입니다. 감독관이 다운되면 모든 것이 다운됩니다. 중복성 (redundancy), 상태 확인 (health checks), 서킷 브레이커 (circuit breakers)를 통해 완화할 수 있지만, 이것이 운영 복잡성을 증가시킨다는 점을 인지해야 합니다.

사용 시점: 대부분의 멀티 에이전트 유스케이스 (use cases). 서브 에이전트가 6개 미만이라면 이것이 귀하의 패턴입니다.

패턴 2: 파이프라인 (Pipeline, 순차적 전문가)

작업이 에이전트의 고정된 시퀀스(sequence)를 통해 흐릅니다: 연구자 (researcher) → 작성자 (writer) → 편집자 (editor). 각 에이전트는 명확한 계약 (contract)을 가집니다.

비용 예측이 가능하고, 각 단계를 평가 (eval)하기 쉬우며, 지연 시간 (latency) 오버헤드가 낮습니다. 실패 모드는 캐스케이드 (cascade, 연쇄 반응)입니다. 중간 단계의 오류가 그 이후의 모든 것을 오염시킵니다. 만약 연구자가 출처를 환각 (hallucinate)하면, 작성자는 이를 증폭시키고, 편집자는 이를 권위 있는 오정보 (misinformation)로 다듬어 버립니다.

# 명시적 단계 계약을 포함한 파이프라인 패턴
from typing import TypedDict

...

실패하는 경우: 단계들이 결합 (coupled)되어 있습니다. 연구자가 쓰레기 데이터를 생성하면, 모든 다운스트림 (downstream) 단계가 이를 상속받습니다. 해결책은 단계 사이에 검증 게이트 (validation gates)를 두는 것입니다. 즉, 다음 단계가 시작되기 전에 각 단계는 반드시 스키마 체크 (schema check)를 통과해야 합니다.

사용 시점: 자연스럽게 선형적인 단계로 분해되는 작업. 연구, 콘텐츠 파이프라인, 데이터 처리. 병렬 탐색 (parallel exploration)이 필요한 작업에는 적합하지 않습니다.

패턴 3: 팬아웃 (Fan-Out, 병렬 브랜치, 집계된 결과)

코디네이터(Coordinator)가 N개의 특화된 하위 작업(subtasks)을 여러 에이전트에게 동시에 배정(dispatch)한 다음, 모든 브랜치(branch)가 반환되면 결과를 집계(aggregate)합니다. 실제 경과 시간(Wall-clock latency)은 모든 작업 시간의 합이 아니라, 가장 느린 브랜치에 의해 제한됩니다.

import asyncio
from claude_agent_sdk import ClaudeAgent, ClaudeAgentOptions

...

대부분의 구현체가 놓치는 결정적인 실패 모드(failure mode)는 바로 **부분 실패 집계 (partial-failure aggregation)**입니다. 만약 하나의 브랜치에서 오류가 발생하면 어떻게 될까요? 전체 요청을 실패 처리할까요? 부분적인 결과만 반환할까요? 아니면 실패한 브랜치만 재시도할까요? 대부분의 구현체는 마치 완전한 답변처럼 보이는 부분적인 결과들을 조용히 반환해 버립니다.

사용 시점: 여러 소스에 걸친 병렬 조사(Parallel research). 여러 파일에 대한 병렬 코드 리뷰(Parallel code review). 서로의 중간 결과(intermediate results)를 볼 필요가 없는 독립적인 하위 작업들로 구성된 모든 작업.

패턴 4: 디베이트 (Debate, 다각도 검증)

여러 에이전트가 동일한 문제를 독립적으로 분석한 다음, 판사(judge)가 상충하는 답변들 사이에서 판결을 내립니다.

이것은 Microsoft의 Copilot Council과 Anthropic의 멀티 에이전트 연구 시스템의 기반이 되는 패턴입니다. 비용 구조는 감독자(supervisor) 패턴과 근본적으로 다릅니다. 디베이트는 판사를 추가하기 전에도 본질적으로 단일 모델 비용의 최소 2.5배에 달합니다. 하지만 법률 분류(legal classification), 금융 검증(financial validation), 의료 진단(medical diagnosis)과 같이 정확도가 결정적인 작업의 경우, 이러한 비용은 오류 감소를 통해 정당화됩니다.

# 합의(Consensus) 패턴: 3개의 에이전트, 분류를 위한 다수결 투표
async def debate_classify(document: str, candidates: list[str]) -> str:
    """동일한 작업에 대해 3개의 에이전트를 실행하고, 다수결을 따릅니다."""
...

Abemon의 운영 데이터에 따르면, 합의(consensus) 패턴은 단일 에이전트 비용의 3.2배로 실행되지만, 동일한 작업에 대해 단일 에이전트의 정확도가 94.7%인 것에 비해 문서 분류에서 99.1%의 정확도를 달성했습니다.

사용 시점: 오류의 비용이 중복 비용보다 큰 작업. 법률, 금융, 의료 분야. 확실성보다 속도가 더 중요한 작업에는 적합하지 않습니다.

패턴 5: 스웜 (Swarm, 대규모 병렬 조정)

여러 에이전트가 동일한 작업의 중첩되는 측면들을 처리하며, 공유 상태 (Shared State) 또는 메시지 버스 (Message Bus)를 통해 조정합니다. Kimi K2.6은 복잡한 연구 작업을 위해 300개의 에이전트까지 확장되는 스웜 (Swarm) 성능을 입증했습니다.

스웜은 가장 복잡한 패턴이며 디버깅하기 가장 어렵습니다. 또한 다양한 관점이 필요한 작업에서 진정으로 성능을 향상시키는 유일한 패턴이기도 하지만, 조정 오버헤드 (Coordination Overhead)가 상당합니다.

# 공유 상태(Redis)를 통한 단순화된 스웜 조정
import redis
import json
...

실패하는 경우: 통신 오버헤드가 지배적입니다. 작업이 원래 걸려야 할 시간보다 10배 더 오래 걸립니다. 에이전트들이 서로를 기다리며 루프 (Loop)에 빠집니다. 원자적 연산 (Atomic Operations) 없이는 공유 상태 오염이 만연하게 됩니다.

사용해야 하는 경우: 진정으로 다양한 관점이 필요한 복잡한 연구. 여러 검토자가 참여하는 코드 리뷰. 적대적 설정 (Adversarial setups, 한 에이전트는 생성하고 다른 에이전트는 비판함). 대부분의 운영 환경 (Production) 사례에서는 감독자 (Supervisor) 또는 토론 (Debate) 패턴이 더 적합할 것입니다.

보기에는 좋지만 작동하지 않는 3가지 패턴

❌ 완전 창발적 크루 (Fully-Emergent Crews)

"서로 다른 역할을 가진 다섯 명의 에이전트가 알아서 해결하게 한다." 실제로는: 무한히 회전하거나, 작업을 서로 주고받기만 하거나, 쓰레기 데이터를 생성하거나, 혹은 한 명의 에이전트가 모든 것을 처리하도록 조용히 합쳐져 버립니다.

명시적인 제어 흐름 (Explicit Control Flow)이 창발적 조정 (Emergent Coordination)보다 10번 중 9번은 더 낫습니다. 어떤 에이전트가 어떤 에이전트와 대화하는지 다이어그램을 그릴 수 없다면, 배포하지 마십시오.

❌ 피어 투 피어 동등 에이전트 (Peer-to-Peer Equal Agents)

"감독자 없이 동등한 에이전트들이 조정한다." 통신 오버헤드가 지배적입니다. 작업이 원래 걸려야 할 시간보다 10배 더 오래 걸립니다. 감독자, 즉 아주 얇은 라우팅 계층 (Routing Layer)이라도 추가하십시오.

❌ 무제한 도구 체이닝 (Unbounded Tool Chaining)

"에이전트가 끝날 때까지 도구를 호출하게 둔다." 실제로는: 200번의 LLM 호출, 40달러의 토큰 비용이 발생하며, 에이전트는 40번째 턴에서 혼란에 빠져 루프를 돕니다. 엄격한 예산 (Hard Budgets)은 타협 불가능한 요소입니다: 최대 턴 수, 최대 토큰, 최대 호출 횟수. 항상 적용하십시오.

실제로 중요한 인프라

멀티 에이전트 시스템은 에이전트 수의 차수(Order)만큼 단일 에이전트보다 운영하기가 더 어렵습니다. 살아남는 운영 환경 인프라의 형태는 다음과 같습니다:

1. Agent pool (에이전트 풀) — 어떤 전문 에이전트(specialist agent)든 실행할 수 있는 워커(workers)들로 구성되며, 독립적으로 확장 가능함
2. Shared state (공유 상태) — 빠른 휘발성 상태를 위한 Redis, 영구적인 상태를 위한 Postgres 사용
3. Tool registry (도구 레지스트리) — 에이전트 간 공유되며, 발견 가능성(discoverability)을 위해 이상적으로는 MCP(Model Context Protocol)가 활성화되어 있어야 함
4. LLM gateway (LLM 게이트웨이) — 모델 간 라우팅 및 속도 제한(rate limiting)을 위해 LiteLLM 또는 Portkey 사용
5. Observability (관측성) — 에이전트 호출 전반에 걸쳐 Trace ID가 전파되는 멀티 스팬(multi-span) 트레이스

모든 스팬(span)에는 user_task_id, agent_id, agent_role, parent_agent_id 태그가 지정되어야 합니다. Langfuse와 Phoenix 모두 멀티 에이전트 트레이스를 잘 시각화합니다. Datadog은 세심한 OpenTelemetry 시맨틱 컨벤션(semantic conventions)을 통해 이를 수행합니다.

비용 제어는 선택이 아닌 필수입니다

에이전트 한 개가 10번의 LLM 호출을 사용하는 작업은 에이전트 다섯 개를 사용하면 쉽게 100번의 호출을 사용하게 됩니다. 하룻밤 사이에 1만 달러의 청구서가 날아오는 것을 방지하는 제어 장치는 다음과 같습니다:

• 태스크당 예산 상한 (Per-task budget cap): 사용자 태스크당 최대 $X로 제한. 상한 도달 시 → 사람에게 에스컬레이션(escalate)
• 에이전트당 턴 상한 (Per-agent turn cap): 각 에이전트는 태스크당 최대 N번까지만 LLM을 호출할 수 있음
• 총 턴 상한 (Total-turn cap): 전체 멀티 에이전트 태스크를 총 M번의 턴으로 제한
• 도구 호출 예산 (Tool-call budget): 외부 API는 비용이 발생함. 이를 제한할 것
• 루프 탐지 (Loop detection): 동일한 상태가 3회 연속 발생하면 루프로 간주. 에스컬레이션 수행

이러한 장치가 없다면 버그 하나가 1만 달러의 청구서를 만들어냅니다. 이러한 장치가 있다면 버그는 429 에러처럼 포착됩니다.

장애 처리: 멀티 에이전트의 차이점

단일 에이전트 장애: 재시도(retry), 우아한 실패(fail gracefully), 로그 기록. 멀티 에이전트 장애는 복합적으로 발생합니다:

• 전문 에이전트 실패 → 관리자(supervisor)가 재시도(무한 루프 위험)하거나 포기(태스크 실패)
• 두 전문 에이전트의 의견 불일치 → 결정권자(tiebreaker)가 없으면 교착 상태(deadlock) 발생
• 공유 상태 오염 → 모든 에이전트가 잘못된 데이터를 보게 됨
• 부분적 실패 (5명 중 3명의 전문 에이전트만 성공) → 관리자에게 정책이 필요함

운영 환경의 기본 패턴: 에이전트 단계별 체크포인트를 포함한 Temporal 워크플로우 + 전문 에이전트 수준의 재시도 + 실패 예산 초과 시 태스크 수준의 사람 에스컬레이션. 비용이 적게 드는 작업은 빠르게 실패(fail fast)하고 태스크 전체를 재시도하십시오. 비용이 많이 드는 작업은 마지막으로 확인된 정상 체크포인트(last known-good checkpoint)로부터 무상태(stateless) 재시작을 수행하십시오.

의사결정 프레임워크: 실제로 어떤 패턴이 필요한가?

작업이 선형적인가? ──────── 예 ──→ 파이프라인 (Pipeline)
│
아니오
...

대부분의 팀은 관리자(supervisor) + 전문가(specialists) 패턴으로 시작해야 합니다. 이는 프로덕션 환경의 멀티 에이전트(multi-agent) 유스케이스 80%를 처리할 수 있는 가장 단순한 패턴이며, 가장 뛰어난 관측성(observability)을 제공하고 디버깅이 가장 쉽습니다. 정확도가 요구될 때는 토론(debate) 패턴으로, 지연 시간(latency)이 문제가 될 때는 팬아웃(fan-out) 패턴으로, 규모(scale)가 커질 때는 계층 구조(hierarchy) 패턴으로 발전시키십시오.

관리자(supervisor) 패턴을 최소 3개월 동안 대규모로 운영해 보고, 병렬 조정(parallel coordination)이 귀하의 특정 작업에서 왜 더 단순한 패턴보다 성능이 뛰어난지 정확하게 설명할 수 있을 때까지는 스웜(swarm) 패턴은 건너뛰십시오.

캐스케이드(cascade) 문제는 귀하의 아키텍처 다이어그램에는 관심이 없습니다. 이 문제는 에이전트들이 상태(state)를 공유하는지, 실패를 어떻게 처리하는지, 그리고 단일 에이전트 단위 테스트(unit test)뿐만 아니라 동시 인스턴스(concurrent instances)로 테스트를 수행했는지에만 관심을 가집니다. 그러한 현실에 맞춰 시스템을 구축해야만 귀하의 멀티 에이전트 시스템이 실제로 프로덕션 환경에서 살아남을 수 있을 것입니다.