멀티 에이전트 시스템(Multi-Agent Systems)이 함정인 이유 (그리고 내가 고생하며 배운 것)

모든 야심 찬 AI 엔지니어링 프로젝트에는 더 많은 에이전트가 더 큰 힘을 의미한다고 스스로를 설득하게 되는 순간이 있습니다. 저 역시 Python 오케스트레이션 프레임워크 (orchestration framework)를 구축하는 초기 단계에서 그 순간을 맞이했고, 왜 그러한 직관이 틀렸는지를 정확히 배우기 위해 고통스러운 몇 주를 보냈습니다.

유혹적인 제안은 이렇습니다. 복잡한 작업을 전문화된 서브 에이전트 (sub-agents)로 분해하고, 이를 병렬로 실행하며, 서로 조정하게 만드는 것입니다. 하지만 실제로 일어난 일은 신뢰성 측면의 악몽이었으며, 이는 그 어떤 프레임워크 문서보다도 에이전트 아키텍처 (agentic architecture)에 대해 더 많은 것을 가르쳐 주었습니다.

내가 실제로 구축했던 문제

저의 Python 오케스트레이션 시스템은 계획, 조사, 코드 생성 및 검증이 일관된 순서로 이루어져야 하는 복잡하고 다단계적인 워크플로 (workflows)를 자동화하도록 설계되었습니다. 초기에는 이를 병렬 에이전트들의 네트워크로 구조화했습니다. 플래너 (planner), 여러 명의 워커 (workers), 검증기 (validator), 그리고 합성기 (synthesizer)가 모두 구조화된 메시지를 교환하는 방식이었습니다.

서류상으로는 우아했습니다. 하지만 실제로는 제가 엔지니어링적으로 해결할 수 없는 세 가지 실패 모드 (failure modes)가 있었습니다.

컨텍스트 드리프트 (Context drift). 각 에이전트는 자신에게 전달된 정보의 조각만을 보았습니다. 하나의 모듈을 작성하는 워커는 다른 모듈을 작성하는 워커가 무엇을 결정했는지 볼 수 없었습니다. 합성기가 출력을 결합하려고 시도할 때쯤이면, 결과물에는 충돌하는 가정들이 이미 박혀 있었습니다. 충돌하는 변수 이름, 서로 모순되는 패턴, 일치하지 않는 인터페이스(interfaces) 등이 그것입니다.

연쇄적인 부분적 실패 (Cascading partial failures). 한 에이전트가 모호한 출력을 생성하면, 모든 하위 에이전트 (downstream agents)가 그 모호함을 증폭시켰습니다. 약간 불충분하게 명시된 작업 설명을 반환하는 플래너는, 각기 다르게 이를 해석하는 워커들을 만들어냈습니다. 무엇도 크게 실패하며 신호를 보내지 않았습니다. 모든 것이 조용히 표류하다가, 결국 최종 출력이 일관성을 잃게 되었습니다.

디버깅의 불투명성 (Debugging opacity). 병렬 멀티 에이전트 시스템 (parallel multi-agent system)에서 무언가 잘못되었을 때, 실패의 흔적을 추적하는 것은 비참할 정도였습니다. 플래너 (planner)의 문제였을까요? 워커 (worker) 중 하나였을까요? 아니면 메시지 전달 계층 (message-passing layer)의 문제였을까요? 저는 단일 Python 프로세스 내부에서 분산 시스템 (distributed systems) 디버깅의 가장 최악인 부분들을 재현하고 있었습니다.

문제를 해결한 아키텍처의 전환

해결책은 영리한 것이 아니었습니다. 겸허해지는 경험이었습니다. 저는 아키텍처를 평탄화 (flattened)했습니다.

에이전트들이 메시지를 주고받는 병렬 방식 대신, 각 단계가 이전의 모든 내용이 누적된 전체 컨텍스트 (full accumulated context)를 전달받는 단일 선형 실행 체인 (single linear execution chain)을 중심으로 시스템을 재구조화했습니다. 그 패턴은 다음과 같습니다:

import anthropic

client = anthropic.Anthropic()
...

이 단 한 번의 변화로 컨텍스트 드리프트 (context drift)를 완전히 제거했습니다. 구현자 (implementer)는 플래너의 전체 추론 과정을 볼 수 있습니다. 검증자 (validator)는 구현자가 내린 모든 결정을 볼 수 있습니다. 아무것도 숨겨지지 않으며, 아무것도 처음부터 다시 재해석되지 않습니다.

병렬성이 대개 잘못된 선택인 이유

병렬 에이전트의 매력은 속도입니다. 하지만 대부분의 에이전트 워크플로우 (agentic workflows)에서 병목 현상 (bottleneck)은 연산량이 아니라 정확성입니다. 당신은 CPU 사이클을 기다리는 것이 아니라, 일관되고 정합성 있는 출력을 생성해야 하는 언어 모델 (language model) 호출을 기다리고 있는 것입니다.

병렬성은 속도를 위해 일관성 (coherence)을 맞바꿉니다. 일관성이 중요한 작업에서 — 그리고 제 경험상 거의 모든 프로덕션 작업은 일관성을 요구합니다 — 이는 나쁜 거래입니다.

제가 병렬성이 진정으로 유용하다고 느낀 사례는 매우 제한적입니다. 공유 상태 (shared state)가 없는 독립적인 하위 작업 (sub-tasks), 명확하게 경계가 지어진 범위 (clearly-bounded scope), 그리고 결과물이 자동으로 합성되는 것이 아니라 인간 검토자에 의해 결합되는 경우입니다. 예를 들어, 10개의 별도 문서에 대해 동일한 분석을 수행하고 10개의 별도 보고서를 반환하는 경우를 생각해보세요. 10개의 병렬 기여자로부터 하나의 일관된 시스템을 구축하는 것이 아닙니다.

컨텍스트 엔지니어링의 통찰

제 사고 모델을 바꾼 것은 문제를 재정의하는 것이었습니다. 저는 에이전트 아키텍처를 병렬성의 문제로 생각하고 있었습니다. 하지만 그것은 사실 컨텍스트 (context)의 문제입니다.

질문은 "얼마나 많은 에이전트가 동시에 작동할 수 있는가?"가 아닙니다. "각 에이전트가 올바른 결정을 내리기 위해 무엇을 알아야 하는가?"입니다.

이 질문을 우선순위에 두고 설계를 시작했을 때, 아키텍처는 명확해졌습니다. 모든 에이전트는 자신보다 앞서 결정된 사항들의 전체 이력 (full history)을 필요로 합니다. 이러한 요구 사항은 자연스럽게 순차적 실행 (sequential execution)으로 이어집니다. 이는 병렬성 (parallelism)이 불가능해서가 아니라, 정보 의존성 (information dependencies) 때문에 비실용적이기 때문입니다.

제가 오케스트레이션 프레임워크 (orchestration framework)를 위해 정착한 패턴은 다음과 같습니다:

import anthropic
from dataclasses import dataclass, field
from typing import Any
...

핵심 요소는 to_prompt_context()입니다. 모든 에이전트의 시스템 프롬프트 (system prompt)는 전체 결정 이력으로부터 다시 구축됩니다. 그 어떤 것도 숨겨지지 않습니다.

과거의 나에게 해주고 싶은 말

만약 제가 오케스트레이션 프레임워크를 다시 시작한다면, 처음부터 다음과 같은 제약 사항들을 설정할 것입니다:

한 번에 한 명의 작성자만. 특정 시점에 오직 하나의 에이전트만이 공유된 아티팩트 (shared artifacts)를 작성하거나 수정할 수 있습니다. 연구 에이전트 (research agents), 계획 에이전트 (planning agents), 분석 에이전트 (analysis agents)는 그 출력값이 진정으로 독립적이라면 병렬로 실행될 수 있습니다. 하지만 공유된 아티팩트에 손을 대는 모든 작업은 순차적으로 실행됩니다.

암시적 메시지 전달 (implicit message passing) 대신 명시적 상태 (explicit state). 에이전트들이 메시지를 교환하는 대신, 에이전트들은 명시적인 실행 컨텍스트 (execution context)를 읽고 씁니다. 상태 (state)가 곧 계약 (contract)입니다. 다음 에이전트가 무엇을 알고 있는지에 대해 모호함이 존재하지 않습니다.

크게 실패하거나, 아예 실패하지 않거나. 만약 에이전트가 가진 컨텍스트만으로 단계를 완료할 수 없다면, 모호한 출력을 내놓기보다는 예외 (exception)를 발생시켜야 합니다. 조용한 성능 저하 (silent degradation)는 디버깅 가능한 시스템의 적입니다.

순차적 방식은 느리지 않다. 10단계의 에이전트 체인에 대한 처리 시간은 오케스트레이션 오버헤드 (orchestration overhead)가 아니라 LLM 호출 지연 시간 (latency)에 의해 좌우됩니다. 병렬성은 사용자가 체감할 수 있는 방식으로 큰 차이를 만드는 경우가 드뭅니다.

신뢰성의 보상

아키텍처를 평탄화(flattening)한 후, 시스템은 가장 좋은 의미에서 지루해졌습니다. 실패는 드물었고, 실패가 발생하더라도 추적 가능했습니다. 플래너(planner)의 출력값이 로그에 남았습니다. 구현자(implementer)의 추론 과정이 로그에 남았습니다. 검증자(validator)의 비판 내용이 로그에 남았습니다. 저는 실행 기록을 마치 대본처럼 읽으며 어디서 문제가 발생했는지 즉시 확인할 수 있었습니다.

그러한 디버깅 경험 자체가 이 아키텍처의 증거입니다. 만약 에이전트들이 무엇을 했는지 읽을 수 없고 왜 그렇게 했는지 이해할 수 없다면, 당신은 유지보수하기에 너무 복잡한 무언가를 만든 것입니다.

실질적인 다음 단계 (Practical Next Steps)

만약 에이전트 시스템(agentic systems)을 구축하고 있는데 신뢰성을 확보하기 어렵다면:

확장하기 전에 평탄화하세요. 병렬성(parallelism)을 추가하기 전에 단일 체인(single-chain) 아키텍처가 안정적으로 작동하도록 만드세요.
컨텍스트(context)를 명시적으로 직렬화(serialize)하세요. to_prompt_context() 함수를 작성하고, 모든 에이전트가 실제로 알아야 하는 것이 무엇인지 신중하게 고민하세요.
출력값뿐만 아니라 결정 과정(decisions)을 로그로 남기세요. 각 결정 뒤에 숨겨진 근거(rationale)가 시스템을 디버깅 가능하게 만드는 핵심입니다.
실패 모드(failure modes)를 의도적으로 테스트하세요. 에이전트에게 모호한 입력을 주고 어떤 연쇄 반응(cascade)이 일어나는지 관찰하세요. 그곳에 당신의 아키텍처가 가진 가정이 숨어 있습니다.

멀티 에이전트(multi-agent)의 꿈은 실재하지만, 프레임워크들이 암시하는 것보다 훨씬 더 멀리 있습니다. 그곳으로 가는 길은 인상적으로 보이기만 할 뿐 실제로는 작동하지 않는 분산된 복잡성(distributed complexity)을 통하는 것이 아니라, 당신이 실제로 이해할 수 있는 신뢰할 수 있는 단일 체인 아키텍처를 통하는 길입니다.

이 내용이 유익했다면, 저는 learn-agentic-ai.com에서 프로덕션용 AI 및 에이전트 시스템 구축에 대해 글을 쓰고 있습니다. 여기에는 영어와 브라질 포르투갈어로 제공되는 실습 학습 경로가 포함되어 있습니다. 진짜 무언가를 함께 만들어 봅시다.