108 lines
14 KiB
Markdown
108 lines
14 KiB
Markdown
---
|
|
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 및 트레이싱 도구) 양대 측면에 모두 걸쳐 상호 보완적 제어
|
|
|
|
---
|