landing_page/multi-agent-orchestration/chapters/3_multi_agent.md

marp

marp
true

3. 멀티 에이전트 협업 체계 및 오케스트레이션 인프라

싱글 에이전트의 한계

단일 에이전트는 대규모 컨텍스트를 처리할 때 정보 누락(Lost in the middle) 현상이 발생하기 쉽고, 여러 도구를 한꺼번에 다루어야 할 때 환각(Hallucination)율이 증가하는 문제가 있습니다. 또한 역할 집중으로 인한 프롬프트의 장황화, 멀티태스킹 오류 및 컨텍스트 인지 한계 등의 명확한 한계를 가집니다.

멀티 에이전트란: 역할 세분화와 교차 검증

멀티 에이전트(Multi-Agent) 시스템은 단일 에이전트(Single Agent)의 한계를 극복하기 위해, 서로 다른 페르소나와 전문 도구(Skills)를 갖춘 여러 개의 에이전트들이 협력 네트워크를 형성하여 복잡한 목표를 조율(Orchestration)하고 분할 해결하는 구조입니다.

• 역할 세분화 (Role Specialization): 에이전트별로 한정된 역할(PM, Developer, QA, Researcher 등)과 도구만을 부여하여 프롬프트 노이즈를 억제하고 추론 정확도 향상
• 교차 검증: 서로 다른 이종 모델(Gemini 작성 ➡️ Claude 검토 등) 간의 상호 비평 및 검증 루프를 통해 결과물의 정합성을 교차 검증하고 결과 신뢰성 극대화
• 분할 정복 (Divide and Conquer): 하나의 거대한 프로젝트를 독립된 세부 태스크로 쪼개어 다수의 에이전트가 병렬적으로 해결함으로써 복잡성 분산

Subagent / Team agent

• Subagent란

  Subagent는 부모 에이전트(Parent Agent 또는 Orchestrator)에 의해 동적으로 생성되어 특정 국소적이고 독립적인 태스크를 대행한 뒤, 결과를 상위로 반환하고 소멸하는 종속형 에이전트입니다.

  • 컨텍스트 격리: 하위 작업의 맥락만을 분기(Branch)하여 처리함으로써 상위 대화의 컨텍스트 오염을 막고 토큰 소모량 최적화 및 속도 개선
  • 예시: 메인 에이전트가 리팩토링 중 특정 모듈 에러 복구 작업만을 subagent에 위임하여 처리하는 독립적인 문제 해결 기법

  

  

• Team agent란

  Team agent는 단일 계층적인 수직 구조를 넘어, 수평적이고 다양한 역할을 맡은 여러 독립 에이전트가 협의체(Crew/Team)를 구성하여 대화형 협력(Multi-agent Debate) 및 협상을 통해 목표를 완수하는 협동형 에이전트 구성 방식입니다.

  • 의견 충돌 및 합의: 특정 설계안에 대해 서로 다른 관점의 에이전트들이 논쟁(Debate)을 벌이고, 최종적으로 조율된 결과를 PM 에이전트가 도출하는 식의 협력 모델
  • 협력적 의사결정: 복잡한 문제에 대해 실시간으로 의견과 피드백을 교환하여 점진적으로 결과물의 품질 고도화

  

  

구성 기술: TMUX · crewAI · LangGraph

• TMUX

  TMUX는 에이전트들의 독립적인 작업 공간을 제공하는 가상 터미널 관리 도구로, 백그라운드 내 장기 작업(Long-running task) 세션을 안정적으로 유지하고 AI 에이전트의 동작을 TUI로 실시간 모니터링 및 제어할 수 있도록 도와주는 소프트웨어입니다.

  • 에이전트별 독립 작업 공간 제공: 각 에이전트 세션을 독립적인 tmux 윈도우나 패널에 격리하여 병렬로 실행할 수 있는 물리적 격리막 형성
  • 장기 실행 작업의 백그라운드 세션 유지: SSH 연결이 끊어지거나 브라우저 세션이 끊겨도 tmux 세션 내부에서 구동되는 에이전트 작업은 유실 없이 백그라운드에서 계속 유지
  • TUI 실시간 모니터링 및 제어: CLI 코딩 에이전트나 멀티 에이전트들의 실행 과정을 사람이 TUI를 통해 실시간으로 관측(observe)하고 필요시 입력을 제공할 수 있도록 실시간 관측 및 제어 지원
  • 실제로 앞서 소개한 multi-agent-mux 스킬 데모가 이러한 TMUX 세션 관리 기능을 활용하여 설계된 멀티 에이전트 오케스트레이션 사례임

• crewAI

  역할 기반(Role-based) 협업을 설계하는 데 특화된 프레임워크입니다. 각 에이전트에게 명확한 역할(Role), 목표(Goal), 배경 설명(Backstory)을 부여하고, 이들을 업무 프로세스(Sequential 또는 Hierarchical)에 따라 배치해 '크루(Crew)' 단위로 조율합니다.

• LangGraph

  컨텍스트 엔지니어링(Context Engineering)은 다중 에이전트 시스템에서 에이전트들 간의 대화 흐름, 전달되는 컨텍스트(State), 복잡한 제어 루프를 효율적으로 설계하고 유지하는 방법론적 학문입니다. 이를 구현하는 대표적인 상태 보존형 프레임워크가 LangGraph입니다.

  • 상태 보존 및 순환 제어: 단순 선형적 체인 구조를 탈피하여, 에이전트 간의 루프(반복 검증), 조건부 분기(Conditional branching), 실패 시 롤백 등을 순환형 그래프(Cyclic Graph) 구조로 제어
  • 영속적 상태 관리: 협업 과정에서 축적되는 다양한 상태 변화(State)를 중앙 저장소에서 추적 및 동기화하여 특정 노드가 실패하더라도 이전 상태부터 복구 및 재시작할 수 있는 환경 제공

• (참고) AutoGen, BeeAI

  Microsoft AutoGen과 IBM의 BeeAI도 멀티 에이전트 오케스트레이션을 지원하는 주요 프레임워크입니다.

  • Microsoft AutoGen: 대화형 에이전트 설계(Conversational Agentic Design)에 중점을 둔 프레임워크로, 에이전트 간 대화를 통해 코드를 실행하고 피드백을 주고받는 풍부한 동적 워크플로우 제공

  • BeeAI: 에이전트를 탐색, 실행, 공유할 수 있는 중앙 집중형 오픈소스 플랫폼으로 리눅스 재단(LF) 하위에서 ACP 표준 프로토콜을 백본으로 구축

    

[사례] 실제 구현하며 겪은 문제점들

1. Agent들과 각 Agent들의 세션 관리
   • 다수의 에이전트와 그 아래에 동적으로 생성되는 subagent들의 생명주기(Lifecycle) 및 고유 식별자(UUID)를 동기화하고 상태를 지속적으로 보존하는 일관된 세션 관리 시스템 요구
2. 에이전트 상호 탐색(Service Discovery)과 역할 식별
   • 새로운 에이전트가 네트워크에 진입했을 때 어떤 에이전트가 어떤 과업을 처리할 수 있는지 동적으로 파악하는 기능 요구
     • 마스터 - 슬레이브(Master-Slave) 방식: 중앙 오케스트레이터가 전권을 쥐고 세션을 직접 관리 및 명령하므로 통제는 쉬우나, 오케스트레이터의 에러가 시스템 전체의 단일 실패점(SPOF)이 될 위험 존재
     • P2P 및 보고(P2P and Report) 방식: 에이전트들이 동등한 위치에서 협상하며 자율적으로 탐색하고, 작업 결과를 기록 보관소에 보고하는 방식이나 네트워크 관리 비용 상승 우려
3. 실시간 메시징과 이벤트 예외 처리의 복잡성
   • 태스크 위임 완료 후, 작업 결과와 성공/실패 여부를 교환하는 통신 채널이 중단되거나 유실될 수 있는 위험성 대두
     • 송신/수신 주체의 돌발 종료: 위임 후 송신 주체가 다운되었다가 재가동(Restart)되는 경우, 비동기 알람이 공중분해되어 전체 협업 루프 중단
     • 무한 대기 및 리소스 누수(Deadlock & Resource Leak): 작업을 위임받은 서브에이전트가 예외 이벤트 없이 비정상 종료(Silent death)할 경우 부모 에이전트가 무한 대기(Blocking) 상태에 빠지는 문제 발생

[사례] Multi Agent Orchestration의 장점

1. 프롬프트의 간소화 및 루프 엔진의 진화
   • 기존의 길고 장황한 단일 "Super Prompt" 엔지니어링 시대에서 벗어나, 에이전트를 구동하고 제어하는 자율 루프(Loop Architecture) 설계 중심으로 패러다임 이동
   • PSPDFKit 창업자이자 오픈소스 AI 에이전트 프로젝트인 OpenClaw의 크리에이터인 페터 슈타인베르거(Peter Steinberger, 2026년 초 OpenAI 합류)는 "코딩 에이전트에 프롬프트를 더 넣지 말고, 에이전트를 구동하는 루프를 설계하라"(Stop prompting your coding agents; start designing loops that prompt your agents)고 강조한 바 있음
   • 멀티 에이전트 구조에서는 작업 지시 PM 에이전트, 작업 수행 Worker 에이전트, 유효성 검증 Reviewer 에이전트로 나뉨으로써 프롬프트가 단편적이고 명료해지는 이점 확보
2. 컨텍스트 설명 불필요 (Context-Free Sharing)
   • 공유 작업 환경(Shared Workspaces)과 Git 같은 버전 관리 시스템을 에이전트들이 공유하므로, 새로 합류한 에이전트에게 변경 이력이나 현재 맥락을 다시 텍스트로 설명하느라 불필요한 토큰과 대기 시간 낭비 방지
3. 이종 모델 피드백을 통한 고품질 산출물 교차 검증
   • 특정 한 모델 계열만으로 결과물을 짜고 동일한 계열에 검토를 시키는 것보다, 서로 다른 아키텍처와 특징을 지닌 이종 모델(Gemini 작성 ➡️ Claude 검토 등) 간 상호 보완할 때 결과물의 신뢰성 극대화 및 보이지 않는 맹점 상호 보완
4. 비용 효율적인 토큰 분배 (Cost Optimization)
   • 쉬운 코드 생성이나 정보 검색은 경량화된 저비용 모델(예: Gemini Flash 세대)을 탑재한 에이전트에 분산 위임하고, 고난도의 논리적 추론이 필요한 부분에만 최상위 고비용 모델을 탑재한 에이전트를 적절히 매칭함으로써 종합적인 API 비용 효율적 제어

[요구사항] 성공적인 구현을 위해 필요한 것들 (What We Need?)

앞의 문제점과 장점을 종합하면, 성공적인 멀티 에이전트 오케스트레이션 구현을 위해서는 다음 5가지 구성요소가 필수적이며, 이 요구사항들이 4장(표준)과 5장(인프라)에서 소개할 솔루션의 선정 기준이 됩니다.

1. Agent 간 작업 환경 공유 (A2A의 Agent Card 기반)

   • 특정 에이전트에게 태스크를 안전하게 위임하고 위임받기 위해선, 각 에이전트 카드를 통해 서로의 역할, 엔드포인트, 입력 명세 스키마를 신뢰성 있는 방식으로 동기화

2. 에이전트 작동 인프라스트럭처 (Agent Working Infrastructure)

   • 에이전트들이 통신에 사용할 서비스 주소와 포트를 동적으로 조회할 수 있는 서비스 디스커버리 기능 및 자동 라우팅 체계 내재

3. 일관성 있는 워크플로우 추적 및 공유 (Issue & Workflow Tracking)

   • 서로 다른 에이전트가 동일한 작업을 재수행할 때 동일한 프로세스와 출력을 일관되게 얻을 수 있도록 워크플로우 사양이 제어되어야 함. 또한 에러나 중간 정지가 일어났을 때 복구 및 추적이 용이하도록 규격화된 이슈 추적 인터페이스 마련

4. 고성능 양방향 메시징 시스템 (Advanced Messaging System)

   • 고용량의 코드 블록, 이미지 및 멀티모달 센서 데이터 등을 대량으로 빠르고 정확하게 공유하기 위해서는 기존의 MQTT나 단순 메시지 큐(MQ) 방식은 토픽 세분화와 페이로드 크기 한계로 인해 통신 병목을 겪을 수밖에 없음
   • 단편적인 이벤트 알림만 전송하는 구조에서 탈피하여 상세 에러 트레이스, 상태 구조체, 이미지 바이너리 등을 한꺼번에 담을 수 있는 풍부한 페이로드 지원 메시징 규격이 필수적임. 나아가 대용량 멀티모달 푸시(Push)와 양방향 스트리밍을 지원하기 위해 HTTP/3의 멀티 스트리밍 등 고성능 통신 수반

5. 작업 및 태스크 관리 시스템 (Job & Task Lifecycle Controller)

   • 하나의 부모 작업을 하위 스크럼(Scrum) 단위로 쪼개어 서브에이전트들에게 뿌려주는 라이프사이클 관리 기능이 있어야 함. 각 서브에이전트의 생성부터 소멸까지의 메시징 토픽과 임시 토큰을 정리해야 하며, 이 과정에서 부하를 고르게 배분하고 실력 있는 에이전트를 매칭하기 위한 로드 밸런싱 기법 병행

   

🔗 요구사항과 기술 솔루션 매핑 (Bridge Mapping)

• 요구사항 1(작업 환경 공유) 및 **요구사항 2(서비스 디스커버리)**는 상호 연동 장벽을 허물기 위해 **§4 에이전트 상호운용성 표준(ACP/A2A)**을 통해 규격화된 표준 명세로 제공
• 요구사항 4(고성능 양방향 메시징) 및 **요구사항 5(태스크 라이프사이클/로드밸런싱)**는 고부하 대규모 실시간 분산 환경에서 물리적 네트워크 및 런타임 최적화를 실현하는 §5 gRPC 백본 인프라를 통해 해결
• **요구사항 3(워크플로우 추적)**은 표준 명세(Agent Card)의 추적 스키마와 물리 인프라(gRPC liveness probe 및 트레이싱 도구) 양대 측면에 모두 걸쳐 상호 보완적 제어

---