Compare commits
10 Commits
be28849d25
...
main
| Author | SHA1 | Date | |
|---|---|---|---|
 Godopu
|
403793cbb9 | ||
|
Godopu
|
643b7490fa | ||
|
Godopu
|
7de457d614 | ||
|
Godopu
|
e48e85abf3 | ||
|
Godopu
|
ed998cb556 | ||
|
Godopu
|
5e03a6b239 | ||
|
Godopu
|
7d38306116 | ||
|
Godopu
|
69bd33fc07 | ||
|
Godopu
|
d70d6deecb | ||
|
Godopu
|
128d57af92 |
+368
@@ -0,0 +1,368 @@
|
||||
---
|
||||
marp: true
|
||||
theme: gaia
|
||||
_class: lead
|
||||
paginate: true
|
||||
backgroundColor: #0f172a
|
||||
color: #f8fafc
|
||||
style: |
|
||||
section {
|
||||
font-family: 'Noto Sans KR', 'Inter', sans-serif;
|
||||
padding: 40px;
|
||||
background: radial-gradient(circle at 50% 50%, #1e1b4b 0%, #0f0c29 50%, #03001e 100%);
|
||||
}
|
||||
h1 {
|
||||
color: #818cf8;
|
||||
background: linear-gradient(to right, #ffffff, #818cf8);
|
||||
-webkit-background-clip: text;
|
||||
-webkit-text-fill-color: transparent;
|
||||
}
|
||||
h2 {
|
||||
color: #818cf8;
|
||||
border-bottom: 2px solid rgba(129, 140, 248, 0.2);
|
||||
padding-bottom: 8px;
|
||||
}
|
||||
footer {
|
||||
color: #64748b;
|
||||
}
|
||||
a {
|
||||
color: #a78bfa;
|
||||
}
|
||||
code {
|
||||
background: #0d0e15;
|
||||
color: #a78bfa;
|
||||
}
|
||||
blockquote {
|
||||
background: rgba(129, 140, 248, 0.08);
|
||||
border-left: 4px solid #818cf8;
|
||||
padding: 12px 20px;
|
||||
margin: 10px 0;
|
||||
font-style: italic;
|
||||
color: #e2e8f0;
|
||||
}
|
||||
blockquote cite {
|
||||
display: block;
|
||||
font-size: 0.8rem;
|
||||
color: #94a3b8;
|
||||
margin-top: 5px;
|
||||
font-style: normal;
|
||||
}
|
||||
.grid-2 {
|
||||
display: grid;
|
||||
grid-template-columns: 1.2fr 1fr;
|
||||
gap: 30px;
|
||||
align-items: center;
|
||||
}
|
||||
.grid-equal {
|
||||
display: grid;
|
||||
grid-template-columns: 1fr 1fr;
|
||||
gap: 20px;
|
||||
align-items: center;
|
||||
}
|
||||
.badge {
|
||||
display: inline-block;
|
||||
padding: 4px 12px;
|
||||
background: #818cf8;
|
||||
color: #0f0c29;
|
||||
font-weight: 800;
|
||||
border-radius: 50px;
|
||||
font-size: 0.8rem;
|
||||
margin-bottom: 15px;
|
||||
}
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
<!-- _paginate: false -->
|
||||
<div class="badge">세미나 발표자료</div>
|
||||
|
||||
# 멀티 에이전트란
|
||||
### 개념 설명, 장점, 실제 구축 경험 공유
|
||||
|
||||
발표 스크립트 및 발표자료 (Marp 버전)
|
||||
|
||||
---
|
||||
|
||||
## 1. AI Agent 란?
|
||||
|
||||
<div class="grid-2">
|
||||
<div>
|
||||
|
||||
- **자율 LLM 시스템**: 사용자의 단순 응답을 넘어 스스로 계획하고 도구를 사용해 목표를 완수합니다.
|
||||
- **Planning (계획)**: 작업 분해(Decomposition) 및 자기 성찰(Self-Reflection).
|
||||
- **Memory (기억)**: 컨텍스트 내 단기 기억과 벡터 DB 기반 장기 기억(RAG).
|
||||
- **Tool Use (도구)**: 코드 샌드박스, 브라우저, 외부 API 호출.
|
||||
|
||||
</div>
|
||||
<div>
|
||||
|
||||
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
## 2. AI 에이전트를 확장하는 Skills
|
||||
|
||||
- **Skills (기술 모듈)**: 에이전트가 외부 환경과 동적으로 상호작용하도록 결합하는 기능 패키지.
|
||||
- **프롬프트 그 이상**: 단순 텍스트 프롬프트를 넘어 실행용 코드, 스키마 명세, 예시(Few-shot)를 결합한 모듈입니다.
|
||||
- **동적 모듈화**: 필요한 상황에 기술을 실시간 로드 및 해제.
|
||||
- **한계 돌파**: 언어 모델의 한계를 넘어 서버 배포, 파일 제어, 데이터 수집 등의 실무 대행력을 부여합니다.
|
||||
|
||||
---
|
||||
|
||||
## 3. Claude Cowork vs Claude Code
|
||||
|
||||
<div class="grid-2">
|
||||
<div>
|
||||
|
||||
- **인프라와 목적의 차이**: 최상위 모델을 공유하지만 작동 방식이 상이함.
|
||||
- **Claude Cowork**:
|
||||
- 클라우드 샌드박스 구동
|
||||
- PPT, Excel, PDF 등 범용 사무 업무 대행
|
||||
- **Claude Code**:
|
||||
- 로컬 기기에 직접 모듈을 설치해 구동
|
||||
- 터미널 개발 코딩 작업에 최적화
|
||||
|
||||
</div>
|
||||
<div>
|
||||
|
||||
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
## 4. 대표적인 Skills 활용 사례
|
||||
|
||||
<div class="grid-equal">
|
||||
<div>
|
||||
|
||||
### 💻 개발 및 분석 (Dev Skill)
|
||||
- Grep 탐색 및 File replace
|
||||
- Linting 및 에러 자동 검증
|
||||
- Git Auto Commit & Push
|
||||
|
||||
### 🌐 브라우저 자동화 (QA Skill)
|
||||
- Playwright/Puppeteer 연동
|
||||
- 실시간 웹 데이터 크롤링
|
||||
- 웹 UI 자동 QA 시나리오 기동
|
||||
|
||||
</div>
|
||||
<div>
|
||||
|
||||
### ⚙️ DevOps 및 인프라 (DevOps)
|
||||
- Firebase Hosting 정적 파일 배포
|
||||
- Cloud DB 보안 규칙 수정
|
||||
- 클라우드 자원 모니터링 및 라우팅
|
||||
|
||||
### 🧪 학술 및 도메인 특화 (Research)
|
||||
- ChEMBL 화학물 정보 탐색
|
||||
- PubMed / arXiv 학술 조사
|
||||
- dbSNP 유전체 데이터 체크
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
## 5. Github 트렌드 & Understand Skill
|
||||
|
||||
- **Understand Skill**: 코드베이스나 문서를 인터랙티브 지식 그래프로 변환해 자율 분석합니다.
|
||||
|
||||
<div class="grid-equal">
|
||||
<div>
|
||||
|
||||
|
||||
|
||||
</div>
|
||||
<div>
|
||||
|
||||
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
## 6. 개발 사례: multi-agent-mux 스킬
|
||||
|
||||
- **multi-agent-mux**: 다양한 에이전트 프레임워크와 이종 모델을 통합해 다중화 연산 처리를 수행하는 스킬.
|
||||
|
||||
<div class="grid-equal">
|
||||
<div>
|
||||
|
||||
|
||||
|
||||
</div>
|
||||
<div>
|
||||
|
||||
<video src="assets/images/Recording%20Jun%2025,%202026%20-%2011_56%20AM.mp4" controls autoplay muted loop width="400"></video>
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
## 7. Multi-Agent 란?
|
||||
|
||||
- **협력 네트워크**: 단일 모델의 정보 누락과 대형 태스크 시의 환각율 한계를 극복하기 위해 에이전트들이 조율(Orchestration)하고 분업하는 구조.
|
||||
- **분할 정복 (Divide and Conquer)**: 설계, 구현, 검증 등 독립적인 태스크로 쪼개 병렬 정밀 처리 지원.
|
||||
- **역할 정의 (Role Specialization)**: 전담 역할과 도구만 쥐여주어 입력 프롬프트 노이즈를 극소화.
|
||||
- **이종 모델 융합**: 역할별 최적 모델 매치 및 교차 피드백으로 결과 신뢰도 극대화.
|
||||
|
||||
---
|
||||
|
||||
## 8. Multi Agent 예시: Subagent
|
||||
|
||||
<div class="grid-2">
|
||||
<div>
|
||||
|
||||
- **하위 작업 동적 위임**: 부모 에이전트의 오더를 받아 임시 기동, 과업 대행 후 소멸.
|
||||
- **컨텍스트 격리 (Context Isolation)**:
|
||||
- 상위 맥락 오염을 방지하기 위해 하위 리팩토링/검색 작업만 독립 분기(Branch) 처리.
|
||||
- 토큰 소모량을 파격적으로 최적화하고 병렬 속도를 개선.
|
||||
|
||||
</div>
|
||||
<div>
|
||||
|
||||
<div style="display: flex; flex-direction: column; gap: 10px;">
|
||||
<img src="assets/images/Pasted%20image%2020260625224821.png" width="80%" />
|
||||
<img src="assets/images/Pasted%20image%2020260625224849.png" width="80%" />
|
||||
</div>
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
## 9. Multi Agent 예시: Team Agent
|
||||
|
||||
<div class="grid-2">
|
||||
<div>
|
||||
|
||||
- **수평적 대화 조율 (Debate)**: 수직 계층을 넘어 독립적인 에이전트들이 의결하고 협상하는 토론형 구조.
|
||||
- **의견 충돌 및 타협 시뮬레이션**:
|
||||
- 아키텍트와 보안 에이전트가 충돌하며 최적의 절충안을 도출하는 워크플로우.
|
||||
- **비선형적 점진 고도화**: 피드백 루프를 반복해 고품질 산출물 확보.
|
||||
|
||||
</div>
|
||||
<div>
|
||||
|
||||
<div style="display: flex; flex-direction: column; gap: 10px;">
|
||||
<img src="assets/images/Pasted%20image%2020260625230135.png" width="80%" />
|
||||
<img src="assets/images/Pasted%20image%2020260625224919.png" width="80%" />
|
||||
</div>
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
## 10. Context Engineering & LangGraph
|
||||
|
||||
- **Context Engineering**: 에이전트 간의 흐름, 중앙 공유 상태(State), 조건부 루프를 설계하는 방법론.
|
||||
- **상태 보존 및 순환 제어 (Cyclic Control)**:
|
||||
- 반복 루프(반복 검증), 실패 시 롤백 등을 순환형 그래프(Cyclic Graph) 구조로 설계 관리.
|
||||
- **영속적 상태 관리**:
|
||||
- 중앙 저장소에서 상태 변화를 추적하므로 오케스트레이션 도중 실패 시 안전한 재시작 지원.
|
||||
|
||||
---
|
||||
|
||||
## 11. 오케스트레이션 소프트웨어
|
||||
|
||||
<div class="grid-2">
|
||||
<div>
|
||||
|
||||
- **CrewAI**: 역할(Role), 목표(Goal), 백스토리(Backstory) 기반의 크루(Crew) 단위 순차/계층 조율.
|
||||
- **MS AutoGen**: 에이전트 간 자율 대화(Conversational Design) 및 코드 피드백, 인간의 개입에 최적화.
|
||||
- **BeeAI**: 오픈소스 분산 에이전트 공유 배포 플랫폼.
|
||||
|
||||
</div>
|
||||
<div>
|
||||
|
||||
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
## 12. 에이전트 통신 프로토콜 표준
|
||||
|
||||
- **MCP (Model Context Protocol)**:
|
||||
- Anthropic 제안. AI 호스트와 클라이언트 간의 로컬/원격 도구 및 리소스 연결 공통 인터페이스.
|
||||
- **ACP (Agent Communication Protocol)**:
|
||||
- IBM 제안. 서비스 발견, 태스크 위임 규격 표준 (A2A로 공식 통합).
|
||||
- **A2A (Agent-to-Agent)**:
|
||||
- Google 및 50여 파트너사 공동 제안. 이종 에이전트 간 결합 코드(Glue code) 없는 통합 통신 오픈 표준.
|
||||
- **Agent Card (에이전트 카드)**:
|
||||
- 에이전트 기능 명세서 JSON 사양 (`/.well-known/agent-card.json`).
|
||||
|
||||
---
|
||||
|
||||
## 13. 실제 오케스트레이션 구현 시 문제점들
|
||||
|
||||
<div class="grid-2">
|
||||
<div>
|
||||
|
||||
- **세션 및 생명주기 관리**: 동적 subagent들의 UUID 동기화 및 세션 상태 영속성 관리의 어려움.
|
||||
- **상호 탐색과 SPOF**: 마스터-슬레이브(SPOF 위협) vs P2P(네트워크 자원 비용 급증).
|
||||
- **메시지 유실 및 Silent Death**:
|
||||
- 송/수신 주체 다운 시 비동기 알림 유실.
|
||||
- subagent 무통보 고사(Silent Death)로 인한 교착 상태(Deadlock) 및 리소스 누수.
|
||||
|
||||
</div>
|
||||
<div>
|
||||
|
||||
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
## 14. 멀티 에이전트 구축의 장점
|
||||
|
||||
- **제어 루프 아키텍처의 진화**:
|
||||
> "코딩 에이전트에 프롬프트를 더 욱여넣지 마세요. 에이전트를 자율 제어하는 루프 아키텍처를 설계하십시오."
|
||||
> <cite>- 페터 슈타인베르거 (OpenClaw 크리에이터, OpenAI)</cite>
|
||||
- **컨텍스트 설명 불필요**: 공유 작업 공간(Shared Workspaces)과 Git 공유로 불필요한 맥락 분석 토큰 소모 최소화.
|
||||
- **이종 가중치 피드백**: 상호 맹점 보완 및 Gemini Flash 등 저비용 모델 위주 분산 라우팅을 통한 비용 최적화.
|
||||
|
||||
---
|
||||
|
||||
## 15. 신뢰도 확보를 위한 기본 필수 요소
|
||||
|
||||
<div class="grid-2">
|
||||
<div>
|
||||
|
||||
- **A2A Agent Card 기반 작업 환경 공유**: 신뢰성 있는 역할/보안인증 규격 동기화.
|
||||
- **동적 작동 인프라**: 서비스 발견(Discovery)과 가상 포트 맵 라우팅 내재.
|
||||
- **이슈 & 워크플로우 트래커**: 일관성 있는 재현 및 장애 롤백 인터페이스.
|
||||
- **고성능 양방향 메시징**: 대용량 멀티모달 푸시/스트리밍 지원 (HTTP/3).
|
||||
|
||||
</div>
|
||||
<div>
|
||||
|
||||
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
## 16. 왜 gRPC가 해답인가?
|
||||
|
||||
- **A2A 호환성 및 스마트 팩토리/팜 최적화**: 디바이스 계층(MQTT)과 게이트웨이/엣지 노드(gRPC)의 하이브리드 설계에 적합.
|
||||
- **멀티모달 바이너리 스트리밍**: HTTP/2, HTTP/3 백본 기반 양방향 스트리밍 단일 포트 통합.
|
||||
- **Protobuf 직렬화 및 감시 체계**: JSON 문자열 파싱 대비 수배 빠르며, Envoy 및 Kubernetes 생명주기 검증 도구(liveness probe) 재활용 용이.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
<!-- _paginate: false -->
|
||||
|
||||
# 감사합니다
|
||||
### Q&A 및 토론
|
||||
@@ -17,11 +17,25 @@ LLM 기반 에이전트 시스템 아키텍처는 크게 다음 3가지 핵심
|
||||
3. **Tool Use (도구 활용)**
|
||||
- 에이전트가 학습되지 않은 외부 정보에 접근하거나 외부 시스템에 영향을 미치기 위해 계산기, 코드 실행용 샌드박스, 웹 브라우저, 외부 API 등을 주도적으로 호출하는 능력입니다.
|
||||
|
||||
|
||||
|
||||
## AI Agent를 더욱 강력하게 만드는 Skills
|
||||
Skills(기술/도구 패키지)는 AI 에이전트가 외부 환경과 동적으로 상호작용할 수 있도록 결합하는 기능적 실행 모듈입니다. 단순히 LLM에게 행동 지침을 주는 프롬프트 엔지니어링 수준을 넘어, 에이전트가 특정 목표를 위해 직접 실행할 수 있는 코드, 도구의 명세 스키마(Tool Schema), 사용 설명 및 예시(Few-shot Examples) 등이 하나의 단위로 패키징된 자율적 확장 도구 모음입니다.
|
||||
- **동적 모듈화**: 에이전트는 상황에 따라 특정 기술을 필요할 때 로드하여 사용하고 완료 후 반환합니다.
|
||||
- **작업 수행 한계 돌파**: 텍스트 생성이라는 언어 모델 자체의 한계를 넘어, 시스템 레벨의 파일 제어, 서버 배포, 물리 데이터 수집 등의 적극적인 업무 대행 능력을 에이전트에 제공합니다.
|
||||
|
||||
## Claude cowork와 code
|
||||
- AI Agent의 대표 주자인 Claude는 Claude desktop 이라는 프로그램으로 자신들의 뛰어난 모델을 서비스하고 있으며, Claude Desktop App에서 우리는 Claude Cowork와 Claude Code라는 다른 서비스를 사용할 수 있음
|
||||
- Claude Cowork와 Claude Code는 같은 모델을 사용하지만 작동하는 방식이 완전히 다름. Claude Cowork의 경우 사무 작업 등 일상적인 업무의 비서 역할을 수행하며, Claude Code는 Coding 작업에 특화된 Coding Agent라고 소개함
|
||||
- 두 서비스는 동일하게 내부 컴퓨터의 특정 디렉터리에서 작업을 수행하지만 내부적인 작동 절차를 확인해보면 Claude Cowork는 Cloud에서 모델이 필요한 기능을 제공하여 pdf, word, excel, ppt 등 다양한 파일을 읽고 쓸 수 있도록 AI 모델의 기능을 확장한 서비스임
|
||||
- 반면에 Claude Code는 필요한 모듈, 소프트웨어가 있다면 Local Computer에 설치해서 사용한다는 차이점이 있음.
|
||||
|
||||
|
||||
|
||||
- Claude Cowork와 Claude Code를 비교하면 Claude Cowork가 더 좋아보일 수 있지만 Claude Code를 잘 조련하면 Claude Cowork 보다 훨씬 좋은 결과를 기대할 수 있음.
|
||||
|
||||
|
||||
|
||||
## Skills 사례 소개
|
||||
에이전트가 업무 현장에서 유용하게 사용하는 대표적인 Skills 사례들은 다음과 같습니다:
|
||||
1. **코드베이스 분석 및 관리 Skill**
|
||||
@@ -33,6 +47,21 @@ Skills(기술/도구 패키지)는 AI 에이전트가 외부 환경과 동적으
|
||||
4. **학술/도메인 특화 API Skill**
|
||||
- 생화학 데이터베이스(ChEMBL), 의학 학술 논문(PubMed, arXiv), 유전학 정보(dbSNP, ClinVar) 등 전문 영역의 연구용 OpenAPI와 연동하여 자율 연구원(Researcher) 역할을 돕는 조사용 Skill입니다.
|
||||
|
||||
### Github를 점령한 Skills
|
||||
|
||||
|
||||
### Understand skill
|
||||
Turn any codebase, knowledge base, or docs into an interactive knowledge graph you can explore, search, and ask questions about.
|
||||
|
||||
|
||||
### 유행이라 개발해본 multi-agent-mux skill
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
# Multi-Agent란
|
||||
|
||||
## General
|
||||
@@ -50,23 +79,33 @@ Subagent는 부모 에이전트(Parent Agent 또는 Orchestrator)에 의해 동
|
||||
- **컨텍스트 격리**: 상위 에이전트의 전체 대화 컨텍스트를 오염시키지 않기 위해 하위 작업의 맥락만을 분기(Branch)하여 처리함으로써, 에이전트 실행 도중 누적되는 토큰 소모량을 최적화하고 속도를 개선합니다.
|
||||
- **예시**: 메인 에이전트가 "전체 코드 리팩토링"을 수행하면서, 특정 모듈에 대한 에러 복구 작업만을 subagent에게 위임하여 독립적으로 문제를 해결하게 하는 경우입니다.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Team agent란
|
||||
Team agent는 단일 계층적인 수직 구조를 넘어, 수평적이고 다양한 역할을 맡은 여러 독립 에이전트가 협의체(Crew/Team)를 구성하여 대화형 협력(Multi-agent Debate) 및 협상을 통해 목표를 완수하는 협동형 에이전트 구성 방식입니다.
|
||||
- **의견 충돌 및 합의**: 특정 설계안에 대해 아키텍트 에이전트와 보안 담당 에이전트가 서로의 입장에서 논쟁(Debate)을 벌이고, 최종적으로 합의된 결과를 PM 에이전트가 도출하는 식의 인간 워크플로우 모사가 가능합니다.
|
||||
- **협력적 의사결정**: 복잡한 비선형적 문제 해결에 있어 각 에이전트가 피드백을 실시간으로 주고받으며 점진적으로 답을 고도화합니다.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Context Engineering (Lang Graph)란
|
||||
컨텍스트 엔지니어링(Context Engineering)은 다중 에이전트 시스템에서 에이전트들 간의 대화 흐름, 전달되는 컨텍스트(State), 복잡한 제어 루프를 효율적으로 설계하고 유지하는 방법론적 학문입니다. 이를 구현하는 대표적인 상태 보존형 프레임워크가 LangGraph입니다.
|
||||
- **상태 보존 및 순환 제어(Stateful & Cyclic Control)**: 단순 선형적 체인 구조를 탈피하여, 에이전트 간의 루프(반복 검증), 조건부 분기(Conditional branching), 실패 시 롤백 등을 순환형 그래프(Cyclic Graph) 구조로 관리합니다.
|
||||
- **영속적 상태 관리**: 협업 과정에서 축적되는 다양한 상태 변화(State)를 중앙 저장소에서 추적 및 동기화하므로, 대형 워크플로우 도중 특정 노드가 실패하더라도 이전 상태부터 안전하게 재시작할 수 있습니다.
|
||||
|
||||
### CrewAI, Sana 등 Multi agent orchestration을 지원하기 위한 소프트웨어
|
||||
|
||||
|
||||
1. **CrewAI**
|
||||
- 역할 기반(Role-based) 협업을 설계하는 데 특화된 프레임워크입니다. 각 에이전트에게 명확한 역할(Role), 목표(Goal), 배경 설명(Backstory)을 부여하고, 이들을 업무 프로세스(Sequential 또는 Hierarchical)에 따라 배치해 '크루(Crew)' 단위로 조율합니다.
|
||||
2. **Sana**
|
||||
- 최근 Workday가 약 11억 달러에 인수한(2025년 9월 발표, 11월 인수 완료) Sana(스웨덴의 Sana Labs)는 기업 내부 정보 검색 및 다단계 워크플로우를 자동화하는 대표적인 통합 AI 플랫폼이자 비즈니스 오케스트레이션 레이어입니다. 여러 LLM을 모델 비종속적으로 결합해 검색·추론·실행을 수행하는 에이전트 플랫폼인 Sana Agents와 AI 기반 학습 관리 시스템인 Sana Learning을 통해 사내 데이터베이스 및 Slack, Salesforce, Jira 등 서드파티 도구와 연동하여 복잡한 비선형적 업무 프로세스를 자율적으로 조율(Orchestration)합니다.
|
||||
3. **Microsoft AutoGen**
|
||||
- 다중 에이전트 간 대화(Conversational Agentic Design)에 중점을 둔 프레임워크입니다. 다양한 LLM과 도구(Tools)가 연결된 여러 에이전트가 서로 대화를 주고받으며 코드 실행 및 피드백을 처리할 수 있으며, 동적 워크플로우 및 인간의 개입(Human-in-the-loop)을 풍부하게 지원합니다.
|
||||
- 역할 기반(Role-based) 협업을 설계하는 데 특화된 프레임워크입니다. 각 에이전트에게 명확한 역할(Role), 목표(Goal), 배경 설명(Backstory)을 부여하고, 이들을 업무 프로세스(Sequential 또는 Hierarchical)에 따라 배치해 '크루(Crew)' 단위로 조율합니다.
|
||||
1. **Microsoft AutoGen**
|
||||
- 대중 에이전트 간 대화(Conversational Agentic Design)에 중점을 둔 프레임워크입니다. 다양한 LLM과 도구(Tools)가 연결된 여러 에이전트가 서로 대화를 주고받으며 코드 실행 및 피드백을 처리할 수 있으며, 동적 워크플로우 및 인간의 개입(Human-in-the-loop)을 풍부하게 지원합니다.
|
||||
1. **BeeAI**
|
||||
- BeeAI는 프레임워크 전반에서 [AI 에이전트](https://www.ibm.com/kr-ko/think/topics/ai-agents)를 탐색, 실행 및 공유할 수 있는 중앙 집중형 환경을 제공하는 [오픈소스](https://www.ibm.com/kr-ko/think/topics/open-source) 플랫폼입니다. IBM이 개발한 BeeAI는 에이전트 통신 프로토콜(ACP)을 기반으로 구축되었으며 Linux Foundation에서 호스팅됩니다. 팀은 BeeAI 프레임워크를 사용하여 사일로화된 에코시스템 외부에 에이전트를 배포할 수 있습니다.
|
||||
|
||||
## Multi Agent 환경 구성을 위한 Protocols
|
||||
|
||||
@@ -80,6 +119,8 @@ Team agent는 단일 계층적인 수직 구조를 넘어, 수평적이고 다
|
||||
- **Agent Card (에이전트 카드)**: A2A 생태계에서 에이전트의 기능 명세서 역할을 하는 JSON 포맷의 표준 규격서입니다. 에이전트 카드에는 해당 에이전트의 명칭, 제공 가능한 역량(Capabilities), 호출 엔드포인트 정보, 요청 시 통과해야 하는 보안 인증 사양(Authentication) 등이 명시되어 있어 서비스 검색 시스템(Service Discovery)이 에이전트의 역할을 실시간으로 탐색할 수 있도록 돕습니다. 주로 `/.well-known/agent-card.json` 경로에서 탐색 가능하도록 배포됩니다.
|
||||
|
||||
# 실제 Multi Agent Orchestration을 구현하며 겪은 문제점들
|
||||
|
||||
|
||||
1. **Agent들과 각 Agent들의 세션 관리**
|
||||
- 다수의 에이전트와 그 아래에 동적으로 생성되는 subagent들의 생명주기(Lifecycle) 및 고유 식별자(UUID)를 동기화하고 상태를 지속적으로 보존하는 일관된 세션 관리 시스템이 필요합니다.
|
||||
2. **에이전트 상호 탐색(Service Discovery)과 역할 식별**
|
||||
@@ -92,6 +133,7 @@ Team agent는 단일 계층적인 수직 구조를 넘어, 수평적이고 다
|
||||
- **무한 대기 및 리소스 누수(Deadlock & Resource Leak)**: 작업을 전달받은 subagent가 아무런 예외 통보(Timeout 또는 Error Event) 없이 갑자기 고사(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)고 강조한 바 있습니다.*
|
||||
@@ -111,6 +153,9 @@ Team agent는 단일 계층적인 수직 구조를 넘어, 수평적이고 다
|
||||
- 에이전트들이 통신에 사용할 서비스 주소와 포트를 동적으로 조회할 수 있는 서비스 디스커버리(Service Discovery) 기능 및 자동 라우팅 체계가 내재되어야 합니다.
|
||||
3. **일관성 있는 워크플로우 추적 및 공유 (Issue & Workflow Tracking)**
|
||||
- 서로 다른 에이전트가 동일한 작업을 재수행할 때 동일한 프로세스와 출력을 일관되게 얻을 수 있도록 워크플로우 사양이 제어되어야 합니다. 또한 에러나 중간 정지가 일어났을 때 복구 및 추적이 용이하도록 규격화된 이슈 추적 인터페이스(Issue Tracking Interface)를 마련해야 합니다.
|
||||
|
||||
|
||||
|
||||
4. **고성능 양방향 메시징 시스템 (Advanced Messaging System)**
|
||||
- 고용량의 코드 블록, 이미지 및 멀티모달 센서 데이터 등을 대량으로 빠르고 정확하게 공유하기 위해서는 기존의 MQTT나 단순 메시지 큐(MQ) 방식은 토픽 세분화와 페이로드 크기 한계로 인해 통신 병목을 겪을 수밖에 없습니다.
|
||||
- 단편적인 이벤트 알림만 전송하는 구조에서 탈피하여 상세 에러 트레이스, 상태 구조체, 이미지 바이너리 등을 한꺼번에 담을 수 있는 풍부한 페이로드 지원 메시징 규격이 필수적입니다. 나아가 대용량 멀티모달 푸시(Push)와 양방향 스트리밍을 지원하기 위해 HTTP/3의 멀티 스트리밍 등 고성능 통신이 수반되어야 합니다.
|
||||
|
||||
@@ -1,133 +1,174 @@
|
||||
# 학술 논문 관점의 README.md 내용 냉정평가 및 리뷰서 (Review Report)
|
||||
|
||||
본 평가는 `canary-projects-multi-agent-creator-claude` 및 `canary-projects-multi-agent-creator-hermes` 두 에이전트와 함께 웹 서칭, 관련 표준 문서 대조, 분산 시스템 고전 이론 검토를 거쳐 교차 검증한 후 Antigravity가 최종적으로 통합 및 정리한 내용입니다.
|
||||
|
||||
---
|
||||
|
||||
## ⚖️ 종합 판정 (Overall Verdict)
|
||||
> **"현재 문서는 학술 논문(Research Paper)이 아니라, 실무자 관점의 '세미나 발표 스크립트' 또는 '기술 블로그' 수준입니다."**
|
||||
>
|
||||
> 실무적인 구현 과정에서 겪은 에러 패턴과 인프라의 필요성을 명확히 지적하여 현업에서의 통찰력은 매우 뛰어납니다. 하지만 학술적 엄밀함(Formality), 관련 연구(Related Work)와의 차별성 분석, 제안 아키텍처의 논리적 완결성, 그리고 가설을 뒷받침할 정량적 평가 데이터(Evaluation) 등 **연구 논문이 갖추어야 할 핵심 기둥이 모두 부재한 상태**입니다.
|
||||
>
|
||||
> 다만, 본문에서 다루고 있는 **'비동기 에이전트 위임 시의 소리 없는 고사(Silent Death) 문제'**와 **'엣지 AIoT 환경에서의 gRPC 기반 경량화 백본 설계'**라는 주제는 분산 시스템 이론과 결합하여 실증 실험 데이터를 보완한다면 충분히 **우수한 컴퓨터공학/시스템 분야 논문(IEEE, ACM 또는 관련 학회)으로 발전할 잠재력**을 가지고 있습니다.
|
||||
|
||||
title: 멀티 에이전트란
|
||||
description: 멀티에이전트의 개념 설명, 장점, 실제 구축을 통한 경험 공유를 세미나에서 발표하기 위한 발표 스크립트 및 발표자료 작성용 문서입니다.
|
||||
---
|
||||
# AI Agent란?
|
||||
|
||||
## 1. 🌟 주요 장점 (Strengths)
|
||||
## General
|
||||
AI 에이전트(AI Agent)는 단순히 사용자의 텍스트 입력을 받아 응답을 생성하는 대화형 인터페이스(Chatbot)를 넘어, 주어진 최종 목표(Goal)를 자율적으로 달성하기 위해 환경을 인식(Perceive)하고, 스스로 계획(Planning) 및 추론(Reasoning)하며, 도구를 사용해 물리적/디지털적 행동(Action)을 수행하는 LLM 기반 소프트웨어 시스템입니다.
|
||||
|
||||
* **[S1] 실무 경험에서 도출된 정교한 분산 에러 모델 분류 (Problem Taxonomy)**
|
||||
* 에이전트 조율을 실제 구현해보지 않으면 알 수 없는 핵심 병목인 ① 세션 생명주기 및 UUID 동기화 복잡성, ② 마스터-슬레이브와 P2P 탐색 토폴로지의 트레이드오프, ③ 비동기 에이전트 위임 시 발생하는 **"소리 없는 고사(Silent Death)로 인한 무한 대기(Deadlock)"** 현상을 명확하게 시스템 에러 모델로 발굴했습니다. 이 부분은 단순 LLM 프로그래밍을 넘어 시스템 엔지니어링 관점에서 매우 가치 있는 문제 정의입니다.
|
||||
* **[S2] AIoT 엣지 환경에 특화된 Resumable/Stateful gRPC 스트리밍 아키텍처 설계**
|
||||
* 단순히 에이전트 통신에 gRPC를 적용하는 일반적 설계를 넘어, 네트워크 연결 유실이 빈번한 AIoT 엣지 연산 제약 환경을 타겟으로 'Resume Token' 기반의 스트림 재개 및 분산 상태 보존 설계를 강점으로 내세우고 있습니다. 기존 연구들이 단순 HTTP/REST나 비영속 웹소켓 통신에 의존한 반면, 본 아키텍처는 가용성을 극대화하기 위한 전송-오케스트레이션 결합 설계를 구체적으로 제안했다는 점에서 차별성을 갖습니다.
|
||||
* **[S3] 검증 가능한 구체적 연구 가설 (Cross-Model Review)**
|
||||
* 자가 검토(Same-Model Review)와 이종 모델 교차 검토(Cross-Model Review, 예: Gemini Flash ↔ Claude Sonnet)의 결과물 신뢰도 향상 및 오류 감지율에 관한 가설은 독립적인 실증 논문으로 구성하기에 충분할 정도로 구체적이고 검증 가능한(Falsifiable) 훌륭한 연구 주제입니다.
|
||||
* **[S4] 현실적인 3계층 하이브리드 네트워크 설계**
|
||||
* 모든 인프라를 gRPC로 획일화하지 않고, 대역폭 및 성능 제약이 극심한 초경량 센서 디바이스는 MQTT/CoAP을 보완적으로 쓰고, 상위 게이트웨이 및 엣지 연산 계층에 gRPC를 배치한 완충 설계(Hedge)는 네트워크 실무와 아키텍처의 트레이드오프를 훌륭히 방어해 냅니다.
|
||||
* **[S5] 최신 프로토콜 표준 동향 반영**
|
||||
* Model Context Protocol (MCP), Agent Communication Protocol (ACP) 및 이들의 Linux Foundation A2A(Agent-to-Agent) 표준 프로토콜로의 통합 타임라인(2025년 8월 통합)을 정확하게 파악하여 최신 표준화 생태계에 부합하게 작성되었습니다.
|
||||
LLM 기반 에이전트 시스템 아키텍처는 크게 다음 3가지 핵심 요소로 구성됩니다:
|
||||
1. **Planning (계획 및 추론)**
|
||||
- **Task Decomposition (작업 분해)**: 거대하고 복잡한 목표를 실행 가능한 작은 단위의 세부 태스크로 쪼갭니다. (예: Chain of Thought, Tree of Thoughts 등)
|
||||
- **Self-Reflection (자기 성찰 및 피드백)**: 행동의 결과를 스스로 분석하고 실수를 교정하여 향후 계획을 실시간으로 수정합니다. (예: ReAct, Reflexion 프레임워크)
|
||||
2. **Memory (기억 장치)**
|
||||
- **Short-term Memory (단기 기억)**: 현재 대화나 컨텍스트 윈도우 내에서 실시간으로 유지되는 즉각적인 대화 맥락 정보입니다.
|
||||
- **Long-term Memory (장기 기억)**: 외부 데이터베이스나 벡터 DB(Vector DB) 등을 활용하여 과거 대화 기록, 대량의 지식을 인덱싱하고 필요시 RAG(검색 증강 생성) 기법으로 다시 불러오는 정보 보존 공간입니다.
|
||||
3. **Tool Use (도구 활용)**
|
||||
- 에이전트가 학습되지 않은 외부 정보에 접근하거나 외부 시스템에 영향을 미치기 위해 계산기, 코드 실행용 샌드박스, 웹 브라우저, 외부 API 등을 주도적으로 호출하는 능력입니다.
|
||||
|
||||
---
|
||||
|
||||
|
||||
## 2. ⚠️ 치명적 약점 및 Limitations (Weaknesses)
|
||||
## AI Agent를 더욱 강력하게 만드는 Skills
|
||||
Skills(기술/도구 패키지)는 AI 에이전트가 외부 환경과 동적으로 상호작용할 수 있도록 결합하는 기능적 실행 모듈입니다. 단순히 LLM에게 행동 지침을 주는 프롬프트 엔지니어링 수준을 넘어, 에이전트가 특정 목표를 위해 직접 실행할 수 있는 코드, 도구의 명세 스키마(Tool Schema), 사용 설명 및 예시(Few-shot Examples) 등이 하나의 단위로 패키징된 자율적 확장 도구 모음입니다.
|
||||
- **동적 모듈화**: 에이전트는 상황에 따라 특정 기술을 필요할 때 로드하여 사용하고 완료 후 반환합니다.
|
||||
- **작업 수행 한계 돌파**: 텍스트 생성이라는 언어 모델 자체의 한계를 넘어, 시스템 레벨의 파일 제어, 서버 배포, 물리 데이터 수집 등의 적극적인 업무 대행 능력을 에이전트에 제공합니다.
|
||||
|
||||
* **[W1] 연구 질문(Research Question) 및 구체적 가설의 결여 (Critical)**
|
||||
* 문서의 구성이 교과서식 나열("A란 무엇인가? → B란 무엇인가?")로 진행되어 연구로서 무엇을 규명하고자 하는지가 불분명합니다. 논문으로 발전시키기 위해서는 반드시 다음과 같은 형식의 연구 질문이 명시되어야 합니다.
|
||||
* *예: "엣지 AIoT 연산 제약 환경에서 gRPC 기반 경량 메시징 인터페이스가 LLM 에이전트 오케스트레이션의 신뢰성과 응답 지연에 미치는 영향은 무엇인가?"*
|
||||
* **[W2] 문제 정의와 기술적 해결책 간의 논리적 단절 (Non-sequitur) (Critical)**
|
||||
* **본 논문 드래프트의 가장 치명적인 검토 탈락 요인(Review-killer)입니다.**
|
||||
* 본문에서 제기한 주요 문제점들(알람 누락, 소리 없는 고사로 인한 데드락 등)은 **상태 관리 및 시스템 안정성 아키텍처(Orchestration/Supervision Layer)** 영역의 이슈입니다. 그러나 결론부에서는 **전송 및 직렬화 계층(gRPC/Protobuf)**을 해결책으로 지시하고 있습니다. 이는 레이어의 혼동에서 비롯된 논리적 오류입니다.
|
||||
* gRPC는 연결 지향형(Connection-oriented) 프로토콜입니다. 작업을 위임한 상위 에이전트가 돌발 종료 후 재시작하면, 진행 중이던 gRPC 연결 및 인플라이트(In-flight) 스트림은 완전히 유실됩니다. 본문에서 해결하고자 했던 "재시작 후 유실 없는 알림 수신"은 gRPC가 아니라, 기존 시스템의 **MQTT Persistent Session/Retained Message나 영속적 메시지 큐(Message Queueing)**를 통해서 구현된 특성이었습니다. gRPC로 단순 전환하게 되면 오히려 이 안정성 구조가 깨지게 됩니다.
|
||||
* 따라서 날카로운 심사위원은 *"진짜 해결책은 Durability(지속성) 및 Supervision Tree(감독 트리) 설계이며, gRPC로의 교체는 엉뚱한 레이어를 공략한 것이다"*라고 비판할 것입니다.
|
||||
* **[W3] 기술적 오류 및 표준 프로토콜 성숙도 과장 (Major)**
|
||||
* **gRPC의 Pub/Sub 네이티브 지원 주장**: gRPC는 단일 연결 상에서의 양방향 스트리밍(Streaming RPC)을 지원할 뿐, 자체적인 메시지 브로커, N대N 팬아웃(Fan-out), 혹은 보존(Retention) 메커니즘을 내장하고 있지 않습니다. 이를 'Pub/Sub 네이티브 지원'이라고 묘사하는 것은 명백한 오해입니다.
|
||||
* **gRPC-over-HTTP/3 성숙도**: gRPC-over-HTTP/3는 대다수의 상용 프레임워크 스택에서 아직 실험적이거나 일부만 지원되는 단계입니다. 이를 '검증된 성능'으로 과장되게 서술해서는 안 됩니다.
|
||||
* **계층 구조의 혼재**: 전송(gRPC/MQTT/CoAP/QUIC), 직렬화(Protobuf/JSON), 시맨틱 규약(MCP/A2A/ACP), 오케스트레이션 프레임워크(CrewAI/AutoGen/LangGraph)를 혼동하여 서술하고 있습니다. 학술 논문은 이 네 가지 레이어를 확실히 구분하고, 제안 시스템이 각 레이어에서 어떤 구성을 취하는지 아키텍처 다이어그램으로 증명해야 합니다.
|
||||
* **[W4] 정량적 평가 데이터 및 실증(Evaluation)의 전무 (Critical)**
|
||||
* 학술 연구에서는 "극적으로 향상", "독보적으로 빠름", "비용을 효율적으로 제어" 등의 추상적/주관적 수식어를 증거 없이 사용하는 것을 철저히 배제합니다.
|
||||
* **치명적인 병목(Bottleneck) 오류**: LLM 에이전트 오케스트레이션에서 총 지연 시간(End-to-End Latency)의 대다수(예시적 수치 기준 95% 이상; 실제 디바이스 사양 및 LLM 워크로드에 따른 실측 필요)는 LLM의 토큰 생성 시간(초 단위)입니다. 메시지 직렬화 및 파싱 시간(마이크로초~밀리초 단위)은 전체 지연의 극히 일부(1% 미만)에 불과합니다. 따라서 "JSON 파싱 속도가 느려서 Protobuf를 도입해 성능 향상을 도모한다"는 주장은 실제 LLM 지연 시간에 묻혀 설득력을 잃게 되므로, 가용 무선 대역폭이 극히 제약되거나 대용량 멀티모달 센서 데이터 스트리밍이 빈번한 AIoT 엣지 환경으로 컨텍스트를 제한하여 논리를 전개해야 합니다.
|
||||
* **[W5] 정립되지 않은 학계 유용어의 남용 ("Context Engineering") (Moderate)**
|
||||
* "컨텍스트 엔지니어링(Context Engineering)"은 프랙티셔너 및 오픈소스 업계(LangChain 등)에서 널리 쓰이지만, 엄밀한 학술 논문에서 공인된 이론적 용어가 아닙니다. 이 용어를 핵심 키워드로 사용하려면 명확한 정의를 제시하고 출처를 밝히거나, 학술적으로 공인된 'Context Management' 또는 'State Synchronization in Multi-Agent Systems' 등의 표준 컴퓨터공학 용어로 대체해야 합니다.
|
||||
* **[W6] 문헌 인용(Citations) 및 포지셔닝 부재 (Major)**
|
||||
* 본문은 AutoGen(Wu et al. 2023), CrewAI, LangGraph 등 기성 학술적/산업적 논문을 나열하고만 있을 뿐, 본 연구가 이들 대비 이론적으로 어떤 갭(Research Gap)을 극복했는지 포지셔닝하지 않았습니다. Peter Steinberger의 인용구 역시 정식 논문 인용(Academic Citation)으로 변환되어야 합니다.
|
||||
* **[W7] 제안 아키텍처(gRPC 백본)의 핵심 신규성이 A2A 표준에 의해 선점됨 (Critical)**
|
||||
* 본 연구가 독창성을 인정받으려면 A2A 표준 사양을 넘어서는 지점, 즉 (i) 네트워크 유실 대응을 위한 Resume Token 기반의 Resumable Stream 및 exactly-once 작업 완료 보장 시맨틱, (ii) 에이전트 작업 생명주기 유한상태기계(FSM) 설계, (iii) AIoT 엣지 환경에 최적화된 경량 스키마와 2계층 거버넌스 등을 논문의 핵심 기여로 정교하게 포지셔닝해야 합니다.
|
||||
* **[W8] 연구 스코프(Scope)의 불일치 및 불명확성 (Minor)**
|
||||
* 현재 문서는 일반적인 소프트웨어 에이전트 오케스트레이션(PM-Worker-Reviewer 역할 분담, API 비용 라우팅)과 저전력 AIoT 엣지 디바이스 통신이라는 서로 다른 성격의 도메인을 명확한 경계 없이 혼재하여 다루고 있습니다. 학술적으로 명확한 설득력을 갖기 위해선 "엣지 AIoT 연산/대역폭 제약 환경"으로 연구 타겟 스코프를 명확히 고정하고 논지를 전개해야 합니다.
|
||||
## Claude cowork와 code
|
||||
- AI Agent의 대표 주자인 Claude는 Claude desktop 이라는 프로그램으로 자신들의 뛰어난 모델을 서비스하고 있으며, Claude Desktop App에서 우리는 Claude Cowork와 Claude Code라는 다른 서비스를 사용할 수 있음
|
||||
- Claude Cowork와 Claude Code는 같은 모델을 사용하지만 작동하는 방식이 완전히 다름. Claude Cowork의 경우 사무 작업 등 일상적인 업무의 비서 역할을 수행하며, Claude Code는 Coding 작업에 특화된 Coding Agent라고 소개함
|
||||
- 두 서비스는 동일하게 내부 컴퓨터의 특정 디렉터리에서 작업을 수행하지만 내부적인 작동 절차를 확인해보면 Claude Cowork는 Cloud에서 모델이 필요한 기능을 제공하여 pdf, word, excel, ppt 등 다양한 파일을 읽고 쓸 수 있도록 AI 모델의 기능을 확장한 서비스임
|
||||
- 반면에 Claude Code는 필요한 모듈, 소프트웨어가 있다면 Local Computer에 설치해서 사용한다는 차이점이 있음.
|
||||
|
||||
---
|
||||
|
||||
|
||||
## 3. 🔍 기회 요인 및 핵심 Research Gaps (학술적 기여 가능성)
|
||||
- Claude Cowork와 Claude Code를 비교하면 Claude Cowork가 더 좋아보일 수 있지만 Claude Code를 잘 조련하면 Claude Cowork 보다 훨씬 좋은 결과를 기대할 수 있음.
|
||||
|
||||
논문으로 성공하기 위해 본 드래프트에서 반드시 확보하고 논증해야 하는 학술적 갭(Gaps)들입니다:
|
||||
|
||||
* **[G1] 에이전트 "Silent Death" 현상에 대한 분산 고장 탐지 이론 (Failure Detector) 공식화**
|
||||
* 에이전트가 모니터링 노티 없이 죽는 현상은 분산 시스템의 고전적인 **'Crash-stop failure'** 및 **'Liveness vs Safety'** 문제와 완벽히 궤를 같이합니다. Chandra와 Toueg의 고전 논문 *'Unreliable Failure Detectors for Reliable Distributed Systems' (1996)* 이론을 끌고 들어와, 비동기 LLM 에이전트 환경에 맞춘 '약한 고장 탐지기(Weak Failure Detector)'를 공식 정의하고, 이를 해결하기 위한 'Dual-timeout & Heartbeat' 복구 메커니즘을 수학적/논리적으로 공식화(Formalization)한다면 매우 강력한 시스템 논문이 될 것입니다.
|
||||
* **[G2] 이종 LLM 에이전트 교차 검증에 대한 체계적 실증 비교 실험**
|
||||
* Gemini Flash 세대와 Claude Sonnet 등 다양한 모델의 단일 모델 자가 리뷰 vs 이종 모델 교차 리뷰 조건에서 코드 생성 결함(Defect Rate) 발견 성능, 비용 대비 정확도 향상 비율을 실제로 실험하고 그 데이터를 테이블(Table)과 그래프(Graph)로 완벽히 입증해 보여주어야 합니다.
|
||||
* **[G3] 에이전트 통신 환경 하에서의 gRPC vs JSON-RPC/REST 정량 마이크로 벤치마크**
|
||||
* 에이전트 메시지의 페이로드 크기별(1KB 이벤트 알림, 100KB 복잡 태스크 데이터, 10MB 이미지 바이너리) 직렬화 속도와 CPU 점유율, 가용 무선 네트워크 대역폭 대비 전송 성공률을 비교 측정하여 gRPC가 스마트 팜/팩토리 엣지 계층에서 실제로 왜 필요한지 정량 지표로 입증해야 합니다.
|
||||
* **[G4] 보안 위협 모델링 (Byzantine / Adversarial 에이전트)**
|
||||
* A2A나 ACP 환경처럼 조직의 경계를 넘나드는 멀티 에이전트 환경에서는 악의적인 에이전트가 잘못된 정보를 주입하거나(Byzantine Fault), 데이터를 탈취하는 위협이 발생합니다. 프로젝트의 `DESIGN.md`가 제시한 SPIFFE 식별자 기반 mTLS 및 HMAC 서명이 이 적대적 보안 위협을 어떻게 수학적/논리적으로 해결하는지 기술해야 합니다.
|
||||
* **[G5] 확장성 한계 및 조정 오버헤드 (Scalability Bounds & Coordination Overhead)**
|
||||
* 동적 세션 관리의 한계, 동시 메시지 처리량(Throughput) 임계치, 에이전트 수 증가에 따른 지연 시간의 변화(Latency degradation)를 정량 분석해야 합니다. 단일 오케스트레이터가 지원 가능한 최대 에이전트 수의 임계치와 병목 요인을 벤치마크하여, 조정 오버헤드를 줄이기 위한 토폴로지 분할 기법을 다루어야 합니다.
|
||||
* **[G6] 에이전트 워크플로우의 재현성 및 결정론(Determinism) 확보 방안**
|
||||
* 드래프트에서 "동일 작업에 대해 항상 동일한 출력 보장"을 요구하는 것은 LLM 자체의 확률적 특성(Stochasticity)과 정면으로 충돌하는 지점이 있습니다. 이를 해결하기 위해 에이전트 오케스트레이션 상에서 에이전트 상태 복구 시 LLM 비결정론적 응답으로 인한 정합성 유실 문제를 제어하는 기법이나 시드 제어, 캐싱 사양을 '재현성 갭(Reproducibility Gap)'으로 정의하고 탐구해야 합니다.
|
||||
|
||||
---
|
||||
## Skills 사례 소개
|
||||
에이전트가 업무 현장에서 유용하게 사용하는 대표적인 Skills 사례들은 다음과 같습니다:
|
||||
1. **코드베이스 분석 및 관리 Skill**
|
||||
- 프로젝트 소스코드를 탐색(Grep), 특정 코드 조각을 치환(File replace), 변경 사항 검증(Linting), 최종 커밋 및 푸시 등을 처리하는 개발 자동화 Skill입니다.
|
||||
2. **브라우저 자동화 및 스크래핑 Skill**
|
||||
- 헤드리스 브라우저(Playwright, Puppeteer 등)를 기동하여 실시간 웹 트렌드 조사, 경쟁사 데이터 수집, 웹 UI에 대한 QA 테스트를 자율적으로 수행하는 Skill입니다.
|
||||
3. **인프라스트럭처 제어 및 DevOps Skill**
|
||||
- 클라우드 환경(AWS, GCP 등)이나 Firebase Hosting, Cloud Firestore 등과 같은 서버리스 백엔드 서비스의 배포 및 데이터베이스 규칙 수정을 지원하는 시스템 운영용 Skill입니다.
|
||||
4. **학술/도메인 특화 API Skill**
|
||||
- 생화학 데이터베이스(ChEMBL), 의학 학술 논문(PubMed, arXiv), 유전학 정보(dbSNP, ClinVar) 등 전문 영역의 연구용 OpenAPI와 연동하여 자율 연구원(Researcher) 역할을 돕는 조사용 Skill입니다.
|
||||
|
||||
## 4. 📐 추천하는 논문 구조 개정안 (Proposed Restructuring)
|
||||
### Github를 점령한 Skills
|
||||
|
||||
|
||||
학술 저널/학회 제출을 목표로 할 경우, 현재 스크립트 형태의 문서를 다음과 같이 리스트럭처링할 것을 권장합니다:
|
||||
### Understand skill
|
||||
Turn any codebase, knowledge base, or docs into an interactive knowledge graph you can explore, search, and ask questions about.
|
||||
|
||||
|
||||
1. **초록 (Abstract)**: 엣지 AIoT 에이전트 협업 시 발생하는 무선 대역폭 낭비 및 비동기 데드락(Silent Death) 문제를 정의하고, 본 논문이 제안하는 3계층 하이브리드 gRPC 아키텍처와 분산 고장 탐지 기법 및 그로 인한 성능 향상 성과를 요약합니다.
|
||||
2. **서론 (Introduction)**: 단일 에이전트의 한계 및 멀티 에이전트 협업의 중요성을 강조하고, 기존의 HTTP/JSON 기반 프레임워크가 엣지 AIoT 실시간 제어 환경에 부적합한 이유(대역폭, 지연, 신뢰성 유실)를 제시하여 연구 동기를 유도합니다.
|
||||
3. **관련 연구 (Related Work)**:
|
||||
* *오케스트레이션 프레임워크*: AutoGen, CrewAI, LangGraph의 한계 분석
|
||||
* *통신 프로토콜 표준*: FIPA ACL, Model Context Protocol (MCP), Agent-to-Agent (A2A) 현황
|
||||
* *분산 고장 탐지 이론*: Distributed Failure Detectors
|
||||
4. **문제 정의 및 고장 모델 정의 (System Model & Failure Formulation)**:
|
||||
* 에이전트 간 비동기 위임 시 "소리 없는 고사(Silent Death)" 상태를 수학적으로 공식화하고, 왜 연결 지향형 gRPC 자체만으로는 이를 해결할 수 없는지 증명합니다.
|
||||
5. **제안 아키텍처 (Proposed Architecture)**:
|
||||
* 본문 및 `DESIGN.md` 기반의 3계층(디바이스-게이트웨이-클라우드) 에이전트 협업 구조 제시
|
||||
* 오케스트레이션 계층의 상태 지속성(Durability)과 감독 트리(Supervision Tree) 설계 메커니즘 상세 설명
|
||||
* gRPC와 MQTT의 하이브리드 메시징 라우팅 사양 및 Agent Card를 활용한 Service Discovery 메커니즘
|
||||
6. **구현 (Implementation)**:
|
||||
* 레포지토리에 구현된 실무 모듈(`mqtt_common.py`, `registry.py`, `job_subscriber.py`)의 아키텍처와 프로토콜 버퍼 스키마 설계 내용 서술
|
||||
7. **성능 평가 및 분석 (Evaluation)**:
|
||||
* *실험 1*: 이종 모델 교차 검증의 오류 감지 정확성 및 비용 분석 데이터
|
||||
* *실험 2*: 메시지 크기별 gRPC vs JSON-RPC 마이크로 벤치마크 (지연 시간, CPU, 대역폭)
|
||||
* *실험 3*: Silent Death 발생 시 감지 시간 및 시스템 복구 성공률 (MQTT vs Proposed Stateful gRPC)
|
||||
8. **토론 및 한계점 (Discussion & Limitations)**: 비잔틴 보안 모델 및 일반화 가능성의 위협 요소 고찰
|
||||
9. **결론 (Conclusion)**: 요약 및 향후 연구 방향 제시
|
||||
### 유행이라 개발해본 multi-agent-mux skill
|
||||
|
||||
---
|
||||
|
||||
|
||||
## 5. 👥 서브 에이전트 교차 메타 리뷰 (Sub-Agent Meta-Review)
|
||||
|
||||
|
||||
에이전트 `claude` 및 `hermes`가 본 논문 주제의 독창성(Novelty)과 학술지/학회 게재 타당성을 추가 교차 검증한 결과입니다.
|
||||
|
||||
### 5.1. 학술적 가치 및 독창성 (Academic Novelty Analysis)
|
||||
* **핵심 연구 질문으로의 전환 필요 (G6 확장 - 필수)**
|
||||
* 기존 분산 시스템 관점에서 에이전트의 crash-stop, blocked caller, lost notification 등은 이미 Erlang/OTP 감독 트리(1990s), Chandra-Toueg Failure Detector(1996) 등으로 해결된 영역입니다. 따라서 단순 시스템 구현 나열은 *"Erlang OTP의 액터 모델을 에이전트 도메인에 재발명했다"*라는 심사위원의 비판을 피하기 어렵습니다.
|
||||
* 이를 극복할 **진짜 독창성은 [G6] 비결정론적 복구 문제(Recovery under non-determinism)**에 있습니다. 고전적인 분산 복구 기법은 결정론적 재플레이(Deterministic Replay)를 전제로 하지만, LLM 에이전트의 연산은 확률적(Stochastic)이고 비멱등적(Non-idempotent)입니다. **"단위 작업이 비결정론적일 때, 어떻게 exactly-once 실행 완료와 정합성 있는 상태 복구를 분산 오케스트레이션 상에서 제공할 것인가?"**라는 질문은 학계에서 아직 답해지지 않은 깊고 강력한 연구 질문이 됩니다.
|
||||
* **LLM 에이전트 고사 탐지의 모호성 (G1 확장)**
|
||||
* 전통적인 분산 고장 모델은 프로세스가 살아있거나(Heartbeat 응답), 죽었거나(응답 없음) 둘 중 하나입니다.
|
||||
* 하지만 LLM 에이전트는 프로세스가 살아있음에도 **토큰을 추론하는 중(Thinking)이라 하트비트를 보내지 못하는 '제3의 모호한 상태'**를 가집니다. 이를 '제한된 추론 시간(Bounded Thinking Time)을 갖는 반동기식 고장 탐지기' 모델로 수학적으로 정의하고 공식화(Formalization)하는 방향은 매우 훌륭한 분산 시스템 기여가 됩니다.
|
||||
|
||||
### 5.2. 실험 설계의 교란 변수 통제 (Experimental Rigor & Confounder Control)
|
||||
* **실험 1 (Microbenchmarks - gRPC vs JSON-RPC)**: W4에서 지적했듯 직렬화 성능은 전체 LLM 지연 시간의 1% 미만이므로, 본 실험은 메인 주장이 아닌 **'대용량 멀티모달 센서 데이터 전송이 빈번한 연산 제약 AIoT 엣지 환경'**이라는 특정 상황을 방어하기 위한 보조 데이터로 격하시켜 배치해야 합니다.
|
||||
* **실험 2 (Resilience/Recovery - Confounder Control)**: 복구 속도 단축 등 성능 이득은 gRPC 자체의 효율성보다는 오케스트레이션 계층(Durability + Supervision)의 기여가 큽니다. 따라서 단순 Naive MQTT vs Proposed Stateful gRPC의 비교는 변수가 통제되지 않은 Confounded(교란된) 실험으로 거절 요인이 됩니다.
|
||||
* 반드시 **$2 \times 2$ 매트릭스** 대조군 구조(`{MQTT, gRPC}` $\times$ `{Naive(미감독), Supervised(감독 트리)}`)로 실험을 설계하여 각 계층의 기여도를 분리 증명해야 합니다.
|
||||
# Multi-Agent란
|
||||
|
||||
### 5.3. 투고 전략 및 게재 확률 (Venues & Probability Estimates)
|
||||
연구의 초점(Focus)을 잃지 않기 위해, 하나의 논문으로 통합하기보다 다음의 방향으로 분할(Splitting)하는 투고 전략을 강력히 권장합니다.
|
||||
## General
|
||||
멀티 에이전트(Multi-Agent) 시스템은 단일 에이전트(Single Agent)의 한계를 극복하기 위해, 서로 다른 페르소나와 전문 도구(Skills)를 갖춘 여러 개의 에이전트들이 협력 네트워크를 형성하여 복잡한 목표를 조율(Orchestration)하고 분할 해결하는 구조입니다.
|
||||
|
||||
1. **논문 A: 시스템/이론 중심 (Failure Detection & Recovery in Stochastic Agents)**
|
||||
* *타겟*: **IEEE Internet of Things Journal (Q1, IF~10)**, **IEEE EDGE (Conf)**, **ACM EdgeSys (Workshop)**
|
||||
* *예상 합격률*: **30~40%** (이론 공식화 및 $2 \times 2$ 대조 실험 보완 시)
|
||||
2. **논문 B: 실증 소프트웨어 공학 중심 (Cross-Model Review Empirical Study)**
|
||||
* *타겟*: **ASE (Top Conf)**, **ICSE (Empirical Track)**, **IEEE TSE (Journal)**
|
||||
* *예상 합격률*: **25~35%** (최소 4개 이상 모델 페어 테스트 및 통계적 유의성 검정 보완 시)
|
||||
3. **하나로 통합된 단일 논문 (Combined Single Paper)**
|
||||
* *예상 합격률*: **15~25% (폭락)**
|
||||
* *이유*: 시스템 심사위원은 SE 연구의 엄밀함을, SE 심사위원은 시스템 연구의 깊이를 동시에 의심하게 되어 게재가 거절될 위험이 극대화됩니다.
|
||||
단일 에이전트는 대규모 컨텍스트를 처리할 때 정보 누락(Lost in the middle) 현상이 발생하기 쉽고, 여러 도구를 한꺼번에 다루어야 할 때 환각(Hallucination)율이 증가하는 문제가 있습니다. 멀티 에이전트의 필요성은 다음과 같습니다:
|
||||
1. **분할 정복 (Divide and Conquer)**: 하나의 거대한 프로젝트를 설계, 구현, 검증, 연구 등의 독립적인 세부 태스크로 분산시켜 병렬 및 정밀 처리를 지원합니다.
|
||||
2. **역할 정의 및 노이즈 최소화 (Role Specialization)**: 각 에이전트에게 한정된 역할(예: PM, Developer, QA, Researcher)과 타겟 도구만 부여하므로, 불필요한 프롬프트 노이즈를 제어하고 추론 정확도를 극대화할 수 있습니다.
|
||||
3. **이종 모델 융합 및 교차 검증**: 서로 다른 LLM을 각 역할에 최적화하여 융합 배치하고, 상호 비평 및 검토 루프를 구현함으로써 최종 결과물의 신뢰성을 극대화합니다.
|
||||
|
||||
## Multi Agent의 예시
|
||||
|
||||
### Subagent란
|
||||
Subagent는 부모 에이전트(Parent Agent 또는 Orchestrator)에 의해 동적으로 생성되어 특정 국소적이고 독립적인 태스크를 대행한 뒤, 결과를 상위로 반환하고 소멸하는 종속형 에이전트입니다.
|
||||
- **컨텍스트 격리**: 상위 에이전트의 전체 대화 컨텍스트를 오염시키지 않기 위해 하위 작업의 맥락만을 분기(Branch)하여 처리함으로써, 에이전트 실행 도중 누적되는 토큰 소모량을 최적화하고 속도를 개선합니다.
|
||||
- **예시**: 메인 에이전트가 "전체 코드 리팩토링"을 수행하면서, 특정 모듈에 대한 에러 복구 작업만을 subagent에게 위임하여 독립적으로 문제를 해결하게 하는 경우입니다.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Team agent란
|
||||
Team agent는 단일 계층적인 수직 구조를 넘어, 수평적이고 다양한 역할을 맡은 여러 독립 에이전트가 협의체(Crew/Team)를 구성하여 대화형 협력(Multi-agent Debate) 및 협상을 통해 목표를 완수하는 협동형 에이전트 구성 방식입니다.
|
||||
- **의견 충돌 및 합의**: 특정 설계안에 대해 아키텍트 에이전트와 보안 담당 에이전트가 서로의 입장에서 논쟁(Debate)을 벌이고, 최종적으로 합의된 결과를 PM 에이전트가 도출하는 식의 인간 워크플로우 모사가 가능합니다.
|
||||
- **협력적 의사결정**: 복잡한 비선형적 문제 해결에 있어 각 에이전트가 피드백을 실시간으로 주고받으며 점진적으로 답을 고도화합니다.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Context Engineering (Lang Graph)란
|
||||
컨텍스트 엔지니어링(Context Engineering)은 다중 에이전트 시스템에서 에이전트들 간의 대화 흐름, 전달되는 컨텍스트(State), 복잡한 제어 루프를 효율적으로 설계하고 유지하는 방법론적 학문입니다. 이를 구현하는 대표적인 상태 보존형 프레임워크가 LangGraph입니다.
|
||||
- **상태 보존 및 순환 제어(Stateful & Cyclic Control)**: 단순 선형적 체인 구조를 탈피하여, 에이전트 간의 루프(반복 검증), 조건부 분기(Conditional branching), 실패 시 롤백 등을 순환형 그래프(Cyclic Graph) 구조로 관리합니다.
|
||||
- **영속적 상태 관리**: 협업 과정에서 축적되는 다양한 상태 변화(State)를 중앙 저장소에서 추적 및 동기화하므로, 대형 워크플로우 도중 특정 노드가 실패하더라도 이전 상태부터 안전하게 재시작할 수 있습니다.
|
||||
|
||||
### CrewAI, Sana 등 Multi agent orchestration을 지원하기 위한 소프트웨어
|
||||
|
||||
|
||||
1. **CrewAI**
|
||||
- 역할 기반(Role-based) 협업을 설계하는 데 특화된 프레임워크입니다. 각 에이전트에게 명확한 역할(Role), 목표(Goal), 배경 설명(Backstory)을 부여하고, 이들을 업무 프로세스(Sequential 또는 Hierarchical)에 따라 배치해 '크루(Crew)' 단위로 조율합니다.
|
||||
1. **Microsoft AutoGen**
|
||||
- 대중 에이전트 간 대화(Conversational Agentic Design)에 중점을 둔 프레임워크입니다. 다양한 LLM과 도구(Tools)가 연결된 여러 에이전트가 서로 대화를 주고받으며 코드 실행 및 피드백을 처리할 수 있으며, 동적 워크플로우 및 인간의 개입(Human-in-the-loop)을 풍부하게 지원합니다.
|
||||
1. **BeeAI**
|
||||
- BeeAI는 프레임워크 전반에서 [AI 에이전트](https://www.ibm.com/kr-ko/think/topics/ai-agents)를 탐색, 실행 및 공유할 수 있는 중앙 집중형 환경을 제공하는 [오픈소스](https://www.ibm.com/kr-ko/think/topics/open-source) 플랫폼입니다. IBM이 개발한 BeeAI는 에이전트 통신 프로토콜(ACP)을 기반으로 구축되었으며 Linux Foundation에서 호스팅됩니다. 팀은 BeeAI 프레임워크를 사용하여 사일로화된 에코시스템 외부에 에이전트를 배포할 수 있습니다.
|
||||
|
||||
## Multi Agent 환경 구성을 위한 Protocols
|
||||
|
||||
### MCP/ACP
|
||||
다양한 서비스와 이종 에이전트들이 상호 작용하기 위해 필요한 개방형 표준 통신 프로토콜입니다.
|
||||
- **Model Context Protocol (MCP)**: Anthropic이 2024년 11월 발표한 오픈 소스 프로토콜로, AI 애플리케이션(Host) 내부의 클라이언트(Client)가 로컬/원격의 도구(Tools), 데이터 소스(Resources), 그리고 컨텍스트 템플릿(Prompts)을 통일된 규격으로 안전하게 호출할 수 있는 공통 인터페이스입니다.
|
||||
- **Agent Communication Protocol (ACP)**: IBM Research가 BeeAI 프레임워크 구동을 지원하기 위해 2025년 3월 발표했던 오픈 표준 에이전트 통신 인터페이스입니다. 이종 에이전트 간의 서비스 발견(Service Discovery), 상호작용 방법 협상, 태스크 위임 프로세스를 규격화하였으며, 이후 2025년 8월 27일 공식 깃허브 저장소가 아카이빙되며 Linux Foundation AI & Data 하위의 A2A(Agent-to-Agent) 프로토콜로 공식 통합 및 병합되었습니다.
|
||||
|
||||
### A2A
|
||||
- **A2A (Agent-to-Agent) 프로토콜**: Google이 2025년 4월에 50여 파트너사들과 공동 발표하고 2025년 6월 Linux Foundation에 기증한 이종 에이전트 간 통합 통신 오픈 표준입니다. 서로 다른 벤더가 구현한 에이전트나 다양한 아키텍처 기반의 에이전트가 복잡한 결합 코드(Glue code) 없이도 협업 메시지를 교환하고 상태를 추적할 수 있습니다.
|
||||
- **Agent Card (에이전트 카드)**: A2A 생태계에서 에이전트의 기능 명세서 역할을 하는 JSON 포맷의 표준 규격서입니다. 에이전트 카드에는 해당 에이전트의 명칭, 제공 가능한 역량(Capabilities), 호출 엔드포인트 정보, 요청 시 통과해야 하는 보안 인증 사양(Authentication) 등이 명시되어 있어 서비스 검색 시스템(Service Discovery)이 에이전트의 역할을 실시간으로 탐색할 수 있도록 돕습니다. 주로 `/.well-known/agent-card.json` 경로에서 탐색 가능하도록 배포됩니다.
|
||||
|
||||
# 실제 Multi Agent Orchestration을 구현하며 겪은 문제점들
|
||||
|
||||
|
||||
1. **Agent들과 각 Agent들의 세션 관리**
|
||||
- 다수의 에이전트와 그 아래에 동적으로 생성되는 subagent들의 생명주기(Lifecycle) 및 고유 식별자(UUID)를 동기화하고 상태를 지속적으로 보존하는 일관된 세션 관리 시스템이 필요합니다.
|
||||
2. **에이전트 상호 탐색(Service Discovery)과 역할 식별**
|
||||
- 새로운 에이전트가 네트워크에 진입했을 때 어떤 에이전트가 어떤 과업을 처리할 수 있는지 동적으로 파악해야 합니다.
|
||||
- **마스터 - 슬레이브(Master-Slave) 방식**: 중앙 오케스트레이터가 전권을 쥐고 세션을 직접 관리 및 명령하므로 통제는 쉬우나, 오케스트레이터의 에러가 시스템 전체의 단일 실패점(SPOF)이 될 위험이 있습니다.
|
||||
- **P2P 및 보고(P2P and Report) 방식**: 에이전트들이 동등한 위치에서 협상하며 자율적으로 탐색하고, 작업 결과를 동기적으로 혹은 비동기적으로 기록 보관소에 보고하는 방식이지만 네트워크 관리 비용이 큽니다.
|
||||
3. **실시간 메시징과 이벤트 예외 처리의 복잡성**
|
||||
- 태스크 위임 완료 후, 작업 결과와 성공/실패 여부를 교환하는 통신 채널이 중단되거나 유실될 수 있습니다.
|
||||
- **송신/수신 주체의 돌발 종료**: A 에이전트가 작업을 위임한 후 예상치 못하게 다운되었다가 재가동(Restart)된다면, B 에이전트가 작업을 완료한 뒤 발송한 비동기식 실시간 알람이 허공으로 날아가 결국 전체 협업 루프가 끊어집니다.
|
||||
- **무한 대기 및 리소스 누수(Deadlock & Resource Leak)**: 작업을 전달받은 subagent가 아무런 예외 통보(Timeout 또는 Error Event) 없이 갑자기 고사(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 기반 에이전트에게 피드백받음) 간에 상호 보완하도록 할 때 결과물의 신뢰성이 극적으로 향상됩니다. 이종 모델들이 세상을 바라보는 가중치와 강점이 다르기 때문에 보이지 않는 맹점(Blind spot)을 상호 보완해 줍니다.
|
||||
4. **비용 효율적인 토큰 분배 (Cost Optimization)**
|
||||
- 모든 에이전트가 값비싼 최상위 프론티어 LLM 모델만을 사용할 필요가 없습니다. 작업의 요구 난이도와 속도, 정확성을 저울질하여 쉬운 코드 생성이나 정보 검색은 경량화된 저비용 모델(예: Gemini Flash 세대)을 탑재한 에이전트에 분산 위임하고, 고난도의 논리적 추론이 필요한 부분에만 최상위 고비용 모델을 탑재한 에이전트를 적절히 매칭함으로써 종합적인 API 비용을 효율적으로 제어할 수 있습니다.
|
||||
|
||||
# What We Need?
|
||||
성공적인 Multi-Agent Orchestration 구현을 위해 갖추어야 할 기본 필수 구성요소들입니다:
|
||||
1. **Agent 간 작업 환경 공유 (A2A의 Agent Card 기반)**
|
||||
- 특정 에이전트에게 태스크를 안전하게 위임하고 위임받기 위해선, 각 에이전트 카드를 통해 서로의 역할, 엔드포인트, 입력 명세 스키마를 신뢰할 수 있는 방식으로 확인하고 동기화할 수 있어야 합니다.
|
||||
2. **에이전트 작동 인프라스트럭처 (Agent Working Infrastructure)**
|
||||
- 에이전트들이 통신에 사용할 서비스 주소와 포트를 동적으로 조회할 수 있는 서비스 디스커버리(Service Discovery) 기능 및 자동 라우팅 체계가 내재되어야 합니다.
|
||||
3. **일관성 있는 워크플로우 추적 및 공유 (Issue & Workflow Tracking)**
|
||||
- 서로 다른 에이전트가 동일한 작업을 재수행할 때 동일한 프로세스와 출력을 일관되게 얻을 수 있도록 워크플로우 사양이 제어되어야 합니다. 또한 에러나 중간 정지가 일어났을 때 복구 및 추적이 용이하도록 규격화된 이슈 추적 인터페이스(Issue Tracking Interface)를 마련해야 합니다.
|
||||
|
||||
|
||||
|
||||
4. **고성능 양방향 메시징 시스템 (Advanced Messaging System)**
|
||||
- 고용량의 코드 블록, 이미지 및 멀티모달 센서 데이터 등을 대량으로 빠르고 정확하게 공유하기 위해서는 기존의 MQTT나 단순 메시지 큐(MQ) 방식은 토픽 세분화와 페이로드 크기 한계로 인해 통신 병목을 겪을 수밖에 없습니다.
|
||||
- 단편적인 이벤트 알림만 전송하는 구조에서 탈피하여 상세 에러 트레이스, 상태 구조체, 이미지 바이너리 등을 한꺼번에 담을 수 있는 풍부한 페이로드 지원 메시징 규격이 필수적입니다. 나아가 대용량 멀티모달 푸시(Push)와 양방향 스트리밍을 지원하기 위해 HTTP/3의 멀티 스트리밍 등 고성능 통신이 수반되어야 합니다.
|
||||
5. **작업 및 태스크 관리 시스템 (Job & Task Lifecycle Controller)**
|
||||
- 하나의 부모 작업을 하위 스크럼(Scrum) 단위로 쪼개어 서브에이전트들에게 뿌려주는 라이프사이클 관리 기능이 있어야 합니다. 각 서브에이전트의 생성부터 소멸까지의 메시징 토픽과 임시 토큰을 정리해야 하며, 이 과정에서 부하를 고르게 배분하고 실력 있는 에이전트를 매칭하기 위한 로드 밸런싱(Load Balancing) 기법이 병행되어야 합니다.
|
||||
|
||||
## Why we need gRPC?
|
||||
이러한 해결 과제와 인프라 요구사항 속에서 **gRPC (Google Remote Procedure Call)** 프로토콜은 멀티 에이전트 인프라의 핵심 백본으로 기능합니다.
|
||||
1. **A2A 프로토콜과의 높은 호환성 및 스마트 팩토리/팜 최적화**
|
||||
- 개발 인터페이스 모듈은 스마트 팜, 스마트 팩토리와 같은 AIoT 서비스를 주요 타겟으로 개발되고 있습니다. 대역폭 및 성능 제약이 극심한 초경량 센서 디바이스 계층에서는 MQTT/CoAP 등을 보완적으로 혼용할 수 있으나, 상위의 데이터 수집 게이트웨이 및 엣지 연산 계층에서는 gRPC가 자율 통합 제어를 위한 강력하고 최적의 통신 프로토콜이 됩니다.
|
||||
2. **고성능 멀티 모달 바이너리 스트리밍 및 Pub/Sub 네이티브 지원**
|
||||
- AIoT나 지능형 에이전트 시스템은 텍스트뿐만 아니라 고해상도 이미지, 소리 주파수 등 대량의 멀티모달 데이터를 처리합니다. HTTP/2 또는 HTTP/3 기반으로 작동하는 gRPC는 양방향 스트리밍(Bidirectional Streaming)과 Request/Response, Pub/Sub 통신 스타일을 단일 포트에서 완벽히 소화하여, 복잡한 네트워크 요구사항을 단숨에 통합시킵니다.
|
||||
- 마이크로서비스 아키텍처(MSA)에서 메인 인터페이스로 gRPC가 통용되고 있으므로, 현업 시스템으로의 이식 및 확장 속도가 독보적으로 빠릅니다.
|
||||
3. **구조화된 직렬화 기반의 효율적 태스크 생명주기 및 부하 분산**
|
||||
- Protobuf(Protocol Buffers)를 통한 강력한 스키마 정의는 대량의 동적 서브에이전트들과 오케스트레이터 간에 쏟아지는 통신 메시지를 JSON 문자열 파싱 대비 수배 이상 빠르고 메모리 효율적으로 처리할 수 있게 합니다.
|
||||
- 이미 검증된 수많은 gRPC 기반 로드 밸런싱 및 이슈 트래킹 도구(예: Envoy, Kubernetes gRPC liveness probe 등)를 적극 도입함으로써, 에이전트 라이프사이클 감시 체계를 커스텀 빌드할 필요 없이 기성 인프라로 손쉽게 구축할 수 있습니다.
|
||||
|
||||
@@ -0,0 +1,175 @@
|
||||
---
|
||||
title: 멀티 에이전트란
|
||||
description: 멀티에이전트의 개념 설명, 장점, 실제 구축을 통한 경험 공유를 세미나에서 발표하기 위한 발표 스크립트 및 발표자료 작성용 문서입니다.
|
||||
marp: true
|
||||
---
|
||||
# AI Agent란?
|
||||
|
||||
## General
|
||||
AI 에이전트(AI Agent)는 단순히 사용자의 텍스트 입력을 받아 응답을 생성하는 대화형 인터페이스(Chatbot)를 넘어, 주어진 최종 목표(Goal)를 자율적으로 달성하기 위해 환경을 인식(Perceive)하고, 스스로 계획(Planning) 및 추론(Reasoning)하며, 도구를 사용해 물리적/디지털적 행동(Action)을 수행하는 LLM 기반 소프트웨어 시스템입니다.
|
||||
|
||||
LLM 기반 에이전트 시스템 아키텍처는 크게 다음 3가지 핵심 요소로 구성됩니다:
|
||||
1. **Planning (계획 및 추론)**
|
||||
- **Task Decomposition (작업 분해)**: 거대하고 복잡한 목표를 실행 가능한 작은 단위의 세부 태스크로 쪼갭니다. (예: Chain of Thought, Tree of Thoughts 등)
|
||||
- **Self-Reflection (자기 성찰 및 피드백)**: 행동의 결과를 스스로 분석하고 실수를 교정하여 향후 계획을 실시간으로 수정합니다. (예: ReAct, Reflexion 프레임워크)
|
||||
2. **Memory (기억 장치)**
|
||||
- **Short-term Memory (단기 기억)**: 현재 대화나 컨텍스트 윈도우 내에서 실시간으로 유지되는 즉각적인 대화 맥락 정보입니다.
|
||||
- **Long-term Memory (장기 기억)**: 외부 데이터베이스나 벡터 DB(Vector DB) 등을 활용하여 과거 대화 기록, 대량의 지식을 인덱싱하고 필요시 RAG(검색 증강 생성) 기법으로 다시 불러오는 정보 보존 공간입니다.
|
||||
3. **Tool Use (도구 활용)**
|
||||
- 에이전트가 학습되지 않은 외부 정보에 접근하거나 외부 시스템에 영향을 미치기 위해 계산기, 코드 실행용 샌드박스, 웹 브라우저, 외부 API 등을 주도적으로 호출하는 능력입니다.
|
||||
|
||||
|
||||
|
||||
## AI Agent를 더욱 강력하게 만드는 Skills
|
||||
Skills(기술/도구 패키지)는 AI 에이전트가 외부 환경과 동적으로 상호작용할 수 있도록 결합하는 기능적 실행 모듈입니다. 단순히 LLM에게 행동 지침을 주는 프롬프트 엔지니어링 수준을 넘어, 에이전트가 특정 목표를 위해 직접 실행할 수 있는 코드, 도구의 명세 스키마(Tool Schema), 사용 설명 및 예시(Few-shot Examples) 등이 하나의 단위로 패키징된 자율적 확장 도구 모음입니다.
|
||||
- **동적 모듈화**: 에이전트는 상황에 따라 특정 기술을 필요할 때 로드하여 사용하고 완료 후 반환합니다.
|
||||
- **작업 수행 한계 돌파**: 텍스트 생성이라는 언어 모델 자체의 한계를 넘어, 시스템 레벨의 파일 제어, 서버 배포, 물리 데이터 수집 등의 적극적인 업무 대행 능력을 에이전트에 제공합니다.
|
||||
|
||||
## Claude cowork와 code
|
||||
- AI Agent의 대표 주자인 Claude는 Claude desktop 이라는 프로그램으로 자신들의 뛰어난 모델을 서비스하고 있으며, Claude Desktop App에서 우리는 Claude Cowork와 Claude Code라는 다른 서비스를 사용할 수 있음
|
||||
- Claude Cowork와 Claude Code는 같은 모델을 사용하지만 작동하는 방식이 완전히 다름. Claude Cowork의 경우 사무 작업 등 일상적인 업무의 비서 역할을 수행하며, Claude Code는 Coding 작업에 특화된 Coding Agent라고 소개함
|
||||
- 두 서비스는 동일하게 내부 컴퓨터의 특정 디렉터리에서 작업을 수행하지만 내부적인 작동 절차를 확인해보면 Claude Cowork는 Cloud에서 모델이 필요한 기능을 제공하여 pdf, word, excel, ppt 등 다양한 파일을 읽고 쓸 수 있도록 AI 모델의 기능을 확장한 서비스임
|
||||
- 반면에 Claude Code는 필요한 모듈, 소프트웨어가 있다면 Local Computer에 설치해서 사용한다는 차이점이 있음.
|
||||
|
||||
|
||||
|
||||
- Claude Cowork와 Claude Code를 비교하면 Claude Cowork가 더 좋아보일 수 있지만 Claude Code를 잘 조련하면 Claude Cowork 보다 훨씬 좋은 결과를 기대할 수 있음.
|
||||
|
||||
|
||||
|
||||
## Skills 사례 소개
|
||||
에이전트가 업무 현장에서 유용하게 사용하는 대표적인 Skills 사례들은 다음과 같습니다:
|
||||
1. **코드베이스 분석 및 관리 Skill**
|
||||
- 프로젝트 소스코드를 탐색(Grep), 특정 코드 조각을 치환(File replace), 변경 사항 검증(Linting), 최종 커밋 및 푸시 등을 처리하는 개발 자동화 Skill입니다.
|
||||
2. **브라우저 자동화 및 스크래핑 Skill**
|
||||
- 헤드리스 브라우저(Playwright, Puppeteer 등)를 기동하여 실시간 웹 트렌드 조사, 경쟁사 데이터 수집, 웹 UI에 대한 QA 테스트를 자율적으로 수행하는 Skill입니다.
|
||||
3. **인프라스트럭처 제어 및 DevOps Skill**
|
||||
- 클라우드 환경(AWS, GCP 등)이나 Firebase Hosting, Cloud Firestore 등과 같은 서버리스 백엔드 서비스의 배포 및 데이터베이스 규칙 수정을 지원하는 시스템 운영용 Skill입니다.
|
||||
4. **학술/도메인 특화 API Skill**
|
||||
- 생화학 데이터베이스(ChEMBL), 의학 학술 논문(PubMed, arXiv), 유전학 정보(dbSNP, ClinVar) 등 전문 영역의 연구용 OpenAPI와 연동하여 자율 연구원(Researcher) 역할을 돕는 조사용 Skill입니다.
|
||||
|
||||
### Github를 점령한 Skills
|
||||
|
||||
|
||||
### Understand skill
|
||||
Turn any codebase, knowledge base, or docs into an interactive knowledge graph you can explore, search, and ask questions about.
|
||||
|
||||
|
||||
### 유행이라 개발해본 multi-agent-mux skill
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
# Multi-Agent란
|
||||
|
||||
## General
|
||||
멀티 에이전트(Multi-Agent) 시스템은 단일 에이전트(Single Agent)의 한계를 극복하기 위해, 서로 다른 페르소나와 전문 도구(Skills)를 갖춘 여러 개의 에이전트들이 협력 네트워크를 형성하여 복잡한 목표를 조율(Orchestration)하고 분할 해결하는 구조입니다.
|
||||
|
||||
단일 에이전트는 대규모 컨텍스트를 처리할 때 정보 누락(Lost in the middle) 현상이 발생하기 쉽고, 여러 도구를 한꺼번에 다루어야 할 때 환각(Hallucination)율이 증가하는 문제가 있습니다. 멀티 에이전트의 필요성은 다음과 같습니다:
|
||||
1. **분할 정복 (Divide and Conquer)**: 하나의 거대한 프로젝트를 설계, 구현, 검증, 연구 등의 독립적인 세부 태스크로 분산시켜 병렬 및 정밀 처리를 지원합니다.
|
||||
2. **역할 정의 및 노이즈 최소화 (Role Specialization)**: 각 에이전트에게 한정된 역할(예: PM, Developer, QA, Researcher)과 타겟 도구만 부여하므로, 불필요한 프롬프트 노이즈를 제어하고 추론 정확도를 극대화할 수 있습니다.
|
||||
3. **이종 모델 융합 및 교차 검증**: 서로 다른 LLM을 각 역할에 최적화하여 융합 배치하고, 상호 비평 및 검토 루프를 구현함으로써 최종 결과물의 신뢰성을 극대화합니다.
|
||||
|
||||
## Multi Agent의 예시
|
||||
|
||||
### Subagent란
|
||||
Subagent는 부모 에이전트(Parent Agent 또는 Orchestrator)에 의해 동적으로 생성되어 특정 국소적이고 독립적인 태스크를 대행한 뒤, 결과를 상위로 반환하고 소멸하는 종속형 에이전트입니다.
|
||||
- **컨텍스트 격리**: 상위 에이전트의 전체 대화 컨텍스트를 오염시키지 않기 위해 하위 작업의 맥락만을 분기(Branch)하여 처리함으로써, 에이전트 실행 도중 누적되는 토큰 소모량을 최적화하고 속도를 개선합니다.
|
||||
- **예시**: 메인 에이전트가 "전체 코드 리팩토링"을 수행하면서, 특정 모듈에 대한 에러 복구 작업만을 subagent에게 위임하여 독립적으로 문제를 해결하게 하는 경우입니다.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Team agent란
|
||||
Team agent는 단일 계층적인 수직 구조를 넘어, 수평적이고 다양한 역할을 맡은 여러 독립 에이전트가 협의체(Crew/Team)를 구성하여 대화형 협력(Multi-agent Debate) 및 협상을 통해 목표를 완수하는 협동형 에이전트 구성 방식입니다.
|
||||
- **의견 충돌 및 합의**: 특정 설계안에 대해 아키텍트 에이전트와 보안 담당 에이전트가 서로의 입장에서 논쟁(Debate)을 벌이고, 최종적으로 합의된 결과를 PM 에이전트가 도출하는 식의 인간 워크플로우 모사가 가능합니다.
|
||||
- **협력적 의사결정**: 복잡한 비선형적 문제 해결에 있어 각 에이전트가 피드백을 실시간으로 주고받으며 점진적으로 답을 고도화합니다.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Context Engineering (Lang Graph)란
|
||||
컨텍스트 엔지니어링(Context Engineering)은 다중 에이전트 시스템에서 에이전트들 간의 대화 흐름, 전달되는 컨텍스트(State), 복잡한 제어 루프를 효율적으로 설계하고 유지하는 방법론적 학문입니다. 이를 구현하는 대표적인 상태 보존형 프레임워크가 LangGraph입니다.
|
||||
- **상태 보존 및 순환 제어(Stateful & Cyclic Control)**: 단순 선형적 체인 구조를 탈피하여, 에이전트 간의 루프(반복 검증), 조건부 분기(Conditional branching), 실패 시 롤백 등을 순환형 그래프(Cyclic Graph) 구조로 관리합니다.
|
||||
- **영속적 상태 관리**: 협업 과정에서 축적되는 다양한 상태 변화(State)를 중앙 저장소에서 추적 및 동기화하므로, 대형 워크플로우 도중 특정 노드가 실패하더라도 이전 상태부터 안전하게 재시작할 수 있습니다.
|
||||
|
||||
### CrewAI, Sana 등 Multi agent orchestration을 지원하기 위한 소프트웨어
|
||||
|
||||
|
||||
1. **CrewAI**
|
||||
- 역할 기반(Role-based) 협업을 설계하는 데 특화된 프레임워크입니다. 각 에이전트에게 명확한 역할(Role), 목표(Goal), 배경 설명(Backstory)을 부여하고, 이들을 업무 프로세스(Sequential 또는 Hierarchical)에 따라 배치해 '크루(Crew)' 단위로 조율합니다.
|
||||
1. **Microsoft AutoGen**
|
||||
- 대중 에이전트 간 대화(Conversational Agentic Design)에 중점을 둔 프레임워크입니다. 다양한 LLM과 도구(Tools)가 연결된 여러 에이전트가 서로 대화를 주고받으며 코드 실행 및 피드백을 처리할 수 있으며, 동적 워크플로우 및 인간의 개입(Human-in-the-loop)을 풍부하게 지원합니다.
|
||||
1. **BeeAI**
|
||||
- BeeAI는 프레임워크 전반에서 [AI 에이전트](https://www.ibm.com/kr-ko/think/topics/ai-agents)를 탐색, 실행 및 공유할 수 있는 중앙 집중형 환경을 제공하는 [오픈소스](https://www.ibm.com/kr-ko/think/topics/open-source) 플랫폼입니다. IBM이 개발한 BeeAI는 에이전트 통신 프로토콜(ACP)을 기반으로 구축되었으며 Linux Foundation에서 호스팅됩니다. 팀은 BeeAI 프레임워크를 사용하여 사일로화된 에코시스템 외부에 에이전트를 배포할 수 있습니다.
|
||||
|
||||
## Multi Agent 환경 구성을 위한 Protocols
|
||||
|
||||
### MCP/ACP
|
||||
다양한 서비스와 이종 에이전트들이 상호 작용하기 위해 필요한 개방형 표준 통신 프로토콜입니다.
|
||||
- **Model Context Protocol (MCP)**: Anthropic이 2024년 11월 발표한 오픈 소스 프로토콜로, AI 애플리케이션(Host) 내부의 클라이언트(Client)가 로컬/원격의 도구(Tools), 데이터 소스(Resources), 그리고 컨텍스트 템플릿(Prompts)을 통일된 규격으로 안전하게 호출할 수 있는 공통 인터페이스입니다.
|
||||
- **Agent Communication Protocol (ACP)**: IBM Research가 BeeAI 프레임워크 구동을 지원하기 위해 2025년 3월 발표했던 오픈 표준 에이전트 통신 인터페이스입니다. 이종 에이전트 간의 서비스 발견(Service Discovery), 상호작용 방법 협상, 태스크 위임 프로세스를 규격화하였으며, 이후 2025년 8월 27일 공식 깃허브 저장소가 아카이빙되며 Linux Foundation AI & Data 하위의 A2A(Agent-to-Agent) 프로토콜로 공식 통합 및 병합되었습니다.
|
||||
|
||||
### A2A
|
||||
- **A2A (Agent-to-Agent) 프로토콜**: Google이 2025년 4월에 50여 파트너사들과 공동 발표하고 2025년 6월 Linux Foundation에 기증한 이종 에이전트 간 통합 통신 오픈 표준입니다. 서로 다른 벤더가 구현한 에이전트나 다양한 아키텍처 기반의 에이전트가 복잡한 결합 코드(Glue code) 없이도 협업 메시지를 교환하고 상태를 추적할 수 있습니다.
|
||||
- **Agent Card (에이전트 카드)**: A2A 생태계에서 에이전트의 기능 명세서 역할을 하는 JSON 포맷의 표준 규격서입니다. 에이전트 카드에는 해당 에이전트의 명칭, 제공 가능한 역량(Capabilities), 호출 엔드포인트 정보, 요청 시 통과해야 하는 보안 인증 사양(Authentication) 등이 명시되어 있어 서비스 검색 시스템(Service Discovery)이 에이전트의 역할을 실시간으로 탐색할 수 있도록 돕습니다. 주로 `/.well-known/agent-card.json` 경로에서 탐색 가능하도록 배포됩니다.
|
||||
|
||||
# 실제 Multi Agent Orchestration을 구현하며 겪은 문제점들
|
||||
|
||||
|
||||
1. **Agent들과 각 Agent들의 세션 관리**
|
||||
- 다수의 에이전트와 그 아래에 동적으로 생성되는 subagent들의 생명주기(Lifecycle) 및 고유 식별자(UUID)를 동기화하고 상태를 지속적으로 보존하는 일관된 세션 관리 시스템이 필요합니다.
|
||||
2. **에이전트 상호 탐색(Service Discovery)과 역할 식별**
|
||||
- 새로운 에이전트가 네트워크에 진입했을 때 어떤 에이전트가 어떤 과업을 처리할 수 있는지 동적으로 파악해야 합니다.
|
||||
- **마스터 - 슬레이브(Master-Slave) 방식**: 중앙 오케스트레이터가 전권을 쥐고 세션을 직접 관리 및 명령하므로 통제는 쉬우나, 오케스트레이터의 에러가 시스템 전체의 단일 실패점(SPOF)이 될 위험이 있습니다.
|
||||
- **P2P 및 보고(P2P and Report) 방식**: 에이전트들이 동등한 위치에서 협상하며 자율적으로 탐색하고, 작업 결과를 동기적으로 혹은 비동기적으로 기록 보관소에 보고하는 방식이지만 네트워크 관리 비용이 큽니다.
|
||||
3. **실시간 메시징과 이벤트 예외 처리의 복잡성**
|
||||
- 태스크 위임 완료 후, 작업 결과와 성공/실패 여부를 교환하는 통신 채널이 중단되거나 유실될 수 있습니다.
|
||||
- **송신/수신 주체의 돌발 종료**: A 에이전트가 작업을 위임한 후 예상치 못하게 다운되었다가 재가동(Restart)된다면, B 에이전트가 작업을 완료한 뒤 발송한 비동기식 실시간 알람이 허공으로 날아가 결국 전체 협업 루프가 끊어집니다.
|
||||
- **무한 대기 및 리소스 누수(Deadlock & Resource Leak)**: 작업을 전달받은 subagent가 아무런 예외 통보(Timeout 또는 Error Event) 없이 갑자기 고사(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 기반 에이전트에게 피드백받음) 간에 상호 보완하도록 할 때 결과물의 신뢰성이 극적으로 향상됩니다. 이종 모델들이 세상을 바라보는 가중치와 강점이 다르기 때문에 보이지 않는 맹점(Blind spot)을 상호 보완해 줍니다.
|
||||
4. **비용 효율적인 토큰 분배 (Cost Optimization)**
|
||||
- 모든 에이전트가 값비싼 최상위 프론티어 LLM 모델만을 사용할 필요가 없습니다. 작업의 요구 난이도와 속도, 정확성을 저울질하여 쉬운 코드 생성이나 정보 검색은 경량화된 저비용 모델(예: Gemini Flash 세대)을 탑재한 에이전트에 분산 위임하고, 고난도의 논리적 추론이 필요한 부분에만 최상위 고비용 모델을 탑재한 에이전트를 적절히 매칭함으로써 종합적인 API 비용을 효율적으로 제어할 수 있습니다.
|
||||
|
||||
# What We Need?
|
||||
성공적인 Multi-Agent Orchestration 구현을 위해 갖추어야 할 기본 필수 구성요소들입니다:
|
||||
1. **Agent 간 작업 환경 공유 (A2A의 Agent Card 기반)**
|
||||
- 특정 에이전트에게 태스크를 안전하게 위임하고 위임받기 위해선, 각 에이전트 카드를 통해 서로의 역할, 엔드포인트, 입력 명세 스키마를 신뢰할 수 있는 방식으로 확인하고 동기화할 수 있어야 합니다.
|
||||
2. **에이전트 작동 인프라스트럭처 (Agent Working Infrastructure)**
|
||||
- 에이전트들이 통신에 사용할 서비스 주소와 포트를 동적으로 조회할 수 있는 서비스 디스커버리(Service Discovery) 기능 및 자동 라우팅 체계가 내재되어야 합니다.
|
||||
3. **일관성 있는 워크플로우 추적 및 공유 (Issue & Workflow Tracking)**
|
||||
- 서로 다른 에이전트가 동일한 작업을 재수행할 때 동일한 프로세스와 출력을 일관되게 얻을 수 있도록 워크플로우 사양이 제어되어야 합니다. 또한 에러나 중간 정지가 일어났을 때 복구 및 추적이 용이하도록 규격화된 이슈 추적 인터페이스(Issue Tracking Interface)를 마련해야 합니다.
|
||||
|
||||
|
||||
|
||||
4. **고성능 양방향 메시징 시스템 (Advanced Messaging System)**
|
||||
- 고용량의 코드 블록, 이미지 및 멀티모달 센서 데이터 등을 대량으로 빠르고 정확하게 공유하기 위해서는 기존의 MQTT나 단순 메시지 큐(MQ) 방식은 토픽 세분화와 페이로드 크기 한계로 인해 통신 병목을 겪을 수밖에 없습니다.
|
||||
- 단편적인 이벤트 알림만 전송하는 구조에서 탈피하여 상세 에러 트레이스, 상태 구조체, 이미지 바이너리 등을 한꺼번에 담을 수 있는 풍부한 페이로드 지원 메시징 규격이 필수적입니다. 나아가 대용량 멀티모달 푸시(Push)와 양방향 스트리밍을 지원하기 위해 HTTP/3의 멀티 스트리밍 등 고성능 통신이 수반되어야 합니다.
|
||||
5. **작업 및 태스크 관리 시스템 (Job & Task Lifecycle Controller)**
|
||||
- 하나의 부모 작업을 하위 스크럼(Scrum) 단위로 쪼개어 서브에이전트들에게 뿌려주는 라이프사이클 관리 기능이 있어야 합니다. 각 서브에이전트의 생성부터 소멸까지의 메시징 토픽과 임시 토큰을 정리해야 하며, 이 과정에서 부하를 고르게 배분하고 실력 있는 에이전트를 매칭하기 위한 로드 밸런싱(Load Balancing) 기법이 병행되어야 합니다.
|
||||
|
||||
## Why we need gRPC?
|
||||
이러한 해결 과제와 인프라 요구사항 속에서 **gRPC (Google Remote Procedure Call)** 프로토콜은 멀티 에이전트 인프라의 핵심 백본으로 기능합니다.
|
||||
1. **A2A 프로토콜과의 높은 호환성 및 스마트 팩토리/팜 최적화**
|
||||
- 개발 인터페이스 모듈은 스마트 팜, 스마트 팩토리와 같은 AIoT 서비스를 주요 타겟으로 개발되고 있습니다. 대역폭 및 성능 제약이 극심한 초경량 센서 디바이스 계층에서는 MQTT/CoAP 등을 보완적으로 혼용할 수 있으나, 상위의 데이터 수집 게이트웨이 및 엣지 연산 계층에서는 gRPC가 자율 통합 제어를 위한 강력하고 최적의 통신 프로토콜이 됩니다.
|
||||
2. **고성능 멀티 모달 바이너리 스트리밍 및 Pub/Sub 네이티브 지원**
|
||||
- AIoT나 지능형 에이전트 시스템은 텍스트뿐만 아니라 고해상도 이미지, 소리 주파수 등 대량의 멀티모달 데이터를 처리합니다. HTTP/2 또는 HTTP/3 기반으로 작동하는 gRPC는 양방향 스트리밍(Bidirectional Streaming)과 Request/Response, Pub/Sub 통신 스타일을 단일 포트에서 완벽히 소화하여, 복잡한 네트워크 요구사항을 단숨에 통합시킵니다.
|
||||
- 마이크로서비스 아키텍처(MSA)에서 메인 인터페이스로 gRPC가 통용되고 있으므로, 현업 시스템으로의 이식 및 확장 속도가 독보적으로 빠릅니다.
|
||||
3. **구조화된 직렬화 기반의 효율적 태스크 생명주기 및 부하 분산**
|
||||
- Protobuf(Protocol Buffers)를 통한 강력한 스키마 정의는 대량의 동적 서브에이전트들과 오케스트레이터 간에 쏟아지는 통신 메시지를 JSON 문자열 파싱 대비 수배 이상 빠르고 메모리 효율적으로 처리할 수 있게 합니다.
|
||||
- 이미 검증된 수많은 gRPC 기반 로드 밸런싱 및 이슈 트래킹 도구(예: Envoy, Kubernetes gRPC liveness probe 등)를 적극 도입함으로써, 에이전트 라이프사이클 감시 체계를 커스텀 빌드할 필요 없이 기성 인프라로 손쉽게 구축할 수 있습니다.
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 371 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 99 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 324 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 370 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 159 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 99 KiB |
Binary file not shown.
Binary file not shown.
|
After Width: | Height: | Size: 416 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 647 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 197 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 680 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 584 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 611 KiB |
@@ -0,0 +1,174 @@
|
||||
---
|
||||
title: 멀티 에이전트란
|
||||
description: 멀티에이전트의 개념 설명, 장점, 실제 구축을 통한 경험 공유를 세미나에서 발표하기 위한 발표 스크립트 및 발표자료 작성용 문서입니다.
|
||||
---
|
||||
# AI Agent란?
|
||||
|
||||
## General
|
||||
AI 에이전트(AI Agent)는 단순히 사용자의 텍스트 입력을 받아 응답을 생성하는 대화형 인터페이스(Chatbot)를 넘어, 주어진 최종 목표(Goal)를 자율적으로 달성하기 위해 환경을 인식(Perceive)하고, 스스로 계획(Planning) 및 추론(Reasoning)하며, 도구를 사용해 물리적/디지털적 행동(Action)을 수행하는 LLM 기반 소프트웨어 시스템입니다.
|
||||
|
||||
LLM 기반 에이전트 시스템 아키텍처는 크게 다음 3가지 핵심 요소로 구성됩니다:
|
||||
1. **Planning (계획 및 추론)**
|
||||
- **Task Decomposition (작업 분해)**: 거대하고 복잡한 목표를 실행 가능한 작은 단위의 세부 태스크로 쪼갭니다. (예: Chain of Thought, Tree of Thoughts 등)
|
||||
- **Self-Reflection (자기 성찰 및 피드백)**: 행동의 결과를 스스로 분석하고 실수를 교정하여 향후 계획을 실시간으로 수정합니다. (예: ReAct, Reflexion 프레임워크)
|
||||
2. **Memory (기억 장치)**
|
||||
- **Short-term Memory (단기 기억)**: 현재 대화나 컨텍스트 윈도우 내에서 실시간으로 유지되는 즉각적인 대화 맥락 정보입니다.
|
||||
- **Long-term Memory (장기 기억)**: 외부 데이터베이스나 벡터 DB(Vector DB) 등을 활용하여 과거 대화 기록, 대량의 지식을 인덱싱하고 필요시 RAG(검색 증강 생성) 기법으로 다시 불러오는 정보 보존 공간입니다.
|
||||
3. **Tool Use (도구 활용)**
|
||||
- 에이전트가 학습되지 않은 외부 정보에 접근하거나 외부 시스템에 영향을 미치기 위해 계산기, 코드 실행용 샌드박스, 웹 브라우저, 외부 API 등을 주도적으로 호출하는 능력입니다.
|
||||
|
||||
|
||||
|
||||
## AI Agent를 더욱 강력하게 만드는 Skills
|
||||
Skills(기술/도구 패키지)는 AI 에이전트가 외부 환경과 동적으로 상호작용할 수 있도록 결합하는 기능적 실행 모듈입니다. 단순히 LLM에게 행동 지침을 주는 프롬프트 엔지니어링 수준을 넘어, 에이전트가 특정 목표를 위해 직접 실행할 수 있는 코드, 도구의 명세 스키마(Tool Schema), 사용 설명 및 예시(Few-shot Examples) 등이 하나의 단위로 패키징된 자율적 확장 도구 모음입니다.
|
||||
- **동적 모듈화**: 에이전트는 상황에 따라 특정 기술을 필요할 때 로드하여 사용하고 완료 후 반환합니다.
|
||||
- **작업 수행 한계 돌파**: 텍스트 생성이라는 언어 모델 자체의 한계를 넘어, 시스템 레벨의 파일 제어, 서버 배포, 물리 데이터 수집 등의 적극적인 업무 대행 능력을 에이전트에 제공합니다.
|
||||
|
||||
## Claude cowork와 code
|
||||
- AI Agent의 대표 주자인 Claude는 Claude desktop 이라는 프로그램으로 자신들의 뛰어난 모델을 서비스하고 있으며, Claude Desktop App에서 우리는 Claude Cowork와 Claude Code라는 다른 서비스를 사용할 수 있음
|
||||
- Claude Cowork와 Claude Code는 같은 모델을 사용하지만 작동하는 방식이 완전히 다름. Claude Cowork의 경우 사무 작업 등 일상적인 업무의 비서 역할을 수행하며, Claude Code는 Coding 작업에 특화된 Coding Agent라고 소개함
|
||||
- 두 서비스는 동일하게 내부 컴퓨터의 특정 디렉터리에서 작업을 수행하지만 내부적인 작동 절차를 확인해보면 Claude Cowork는 Cloud에서 모델이 필요한 기능을 제공하여 pdf, word, excel, ppt 등 다양한 파일을 읽고 쓸 수 있도록 AI 모델의 기능을 확장한 서비스임
|
||||
- 반면에 Claude Code는 필요한 모듈, 소프트웨어가 있다면 Local Computer에 설치해서 사용한다는 차이점이 있음.
|
||||
|
||||
|
||||
|
||||
- Claude Cowork와 Claude Code를 비교하면 Claude Cowork가 더 좋아보일 수 있지만 Claude Code를 잘 조련하면 Claude Cowork 보다 훨씬 좋은 결과를 기대할 수 있음.
|
||||
|
||||
|
||||
|
||||
## Skills 사례 소개
|
||||
에이전트가 업무 현장에서 유용하게 사용하는 대표적인 Skills 사례들은 다음과 같습니다:
|
||||
1. **코드베이스 분석 및 관리 Skill**
|
||||
- 프로젝트 소스코드를 탐색(Grep), 특정 코드 조각을 치환(File replace), 변경 사항 검증(Linting), 최종 커밋 및 푸시 등을 처리하는 개발 자동화 Skill입니다.
|
||||
2. **브라우저 자동화 및 스크래핑 Skill**
|
||||
- 헤드리스 브라우저(Playwright, Puppeteer 등)를 기동하여 실시간 웹 트렌드 조사, 경쟁사 데이터 수집, 웹 UI에 대한 QA 테스트를 자율적으로 수행하는 Skill입니다.
|
||||
3. **인프라스트럭처 제어 및 DevOps Skill**
|
||||
- 클라우드 환경(AWS, GCP 등)이나 Firebase Hosting, Cloud Firestore 등과 같은 서버리스 백엔드 서비스의 배포 및 데이터베이스 규칙 수정을 지원하는 시스템 운영용 Skill입니다.
|
||||
4. **학술/도메인 특화 API Skill**
|
||||
- 생화학 데이터베이스(ChEMBL), 의학 학술 논문(PubMed, arXiv), 유전학 정보(dbSNP, ClinVar) 등 전문 영역의 연구용 OpenAPI와 연동하여 자율 연구원(Researcher) 역할을 돕는 조사용 Skill입니다.
|
||||
|
||||
### Github를 점령한 Skills
|
||||
|
||||
|
||||
### Understand skill
|
||||
Turn any codebase, knowledge base, or docs into an interactive knowledge graph you can explore, search, and ask questions about.
|
||||
|
||||
|
||||
### 유행이라 개발해본 multi-agent-mux skill
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
# Multi-Agent란
|
||||
|
||||
## General
|
||||
멀티 에이전트(Multi-Agent) 시스템은 단일 에이전트(Single Agent)의 한계를 극복하기 위해, 서로 다른 페르소나와 전문 도구(Skills)를 갖춘 여러 개의 에이전트들이 협력 네트워크를 형성하여 복잡한 목표를 조율(Orchestration)하고 분할 해결하는 구조입니다.
|
||||
|
||||
단일 에이전트는 대규모 컨텍스트를 처리할 때 정보 누락(Lost in the middle) 현상이 발생하기 쉽고, 여러 도구를 한꺼번에 다루어야 할 때 환각(Hallucination)율이 증가하는 문제가 있습니다. 멀티 에이전트의 필요성은 다음과 같습니다:
|
||||
1. **분할 정복 (Divide and Conquer)**: 하나의 거대한 프로젝트를 설계, 구현, 검증, 연구 등의 독립적인 세부 태스크로 분산시켜 병렬 및 정밀 처리를 지원합니다.
|
||||
2. **역할 정의 및 노이즈 최소화 (Role Specialization)**: 각 에이전트에게 한정된 역할(예: PM, Developer, QA, Researcher)과 타겟 도구만 부여하므로, 불필요한 프롬프트 노이즈를 제어하고 추론 정확도를 극대화할 수 있습니다.
|
||||
3. **이종 모델 융합 및 교차 검증**: 서로 다른 LLM을 각 역할에 최적화하여 융합 배치하고, 상호 비평 및 검토 루프를 구현함으로써 최종 결과물의 신뢰성을 극대화합니다.
|
||||
|
||||
## Multi Agent의 예시
|
||||
|
||||
### Subagent란
|
||||
Subagent는 부모 에이전트(Parent Agent 또는 Orchestrator)에 의해 동적으로 생성되어 특정 국소적이고 독립적인 태스크를 대행한 뒤, 결과를 상위로 반환하고 소멸하는 종속형 에이전트입니다.
|
||||
- **컨텍스트 격리**: 상위 에이전트의 전체 대화 컨텍스트를 오염시키지 않기 위해 하위 작업의 맥락만을 분기(Branch)하여 처리함으로써, 에이전트 실행 도중 누적되는 토큰 소모량을 최적화하고 속도를 개선합니다.
|
||||
- **예시**: 메인 에이전트가 "전체 코드 리팩토링"을 수행하면서, 특정 모듈에 대한 에러 복구 작업만을 subagent에게 위임하여 독립적으로 문제를 해결하게 하는 경우입니다.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Team agent란
|
||||
Team agent는 단일 계층적인 수직 구조를 넘어, 수평적이고 다양한 역할을 맡은 여러 독립 에이전트가 협의체(Crew/Team)를 구성하여 대화형 협력(Multi-agent Debate) 및 협상을 통해 목표를 완수하는 협동형 에이전트 구성 방식입니다.
|
||||
- **의견 충돌 및 합의**: 특정 설계안에 대해 아키텍트 에이전트와 보안 담당 에이전트가 서로의 입장에서 논쟁(Debate)을 벌이고, 최종적으로 합의된 결과를 PM 에이전트가 도출하는 식의 인간 워크플로우 모사가 가능합니다.
|
||||
- **협력적 의사결정**: 복잡한 비선형적 문제 해결에 있어 각 에이전트가 피드백을 실시간으로 주고받으며 점진적으로 답을 고도화합니다.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Context Engineering (Lang Graph)란
|
||||
컨텍스트 엔지니어링(Context Engineering)은 다중 에이전트 시스템에서 에이전트들 간의 대화 흐름, 전달되는 컨텍스트(State), 복잡한 제어 루프를 효율적으로 설계하고 유지하는 방법론적 학문입니다. 이를 구현하는 대표적인 상태 보존형 프레임워크가 LangGraph입니다.
|
||||
- **상태 보존 및 순환 제어(Stateful & Cyclic Control)**: 단순 선형적 체인 구조를 탈피하여, 에이전트 간의 루프(반복 검증), 조건부 분기(Conditional branching), 실패 시 롤백 등을 순환형 그래프(Cyclic Graph) 구조로 관리합니다.
|
||||
- **영속적 상태 관리**: 협업 과정에서 축적되는 다양한 상태 변화(State)를 중앙 저장소에서 추적 및 동기화하므로, 대형 워크플로우 도중 특정 노드가 실패하더라도 이전 상태부터 안전하게 재시작할 수 있습니다.
|
||||
|
||||
### CrewAI, Sana 등 Multi agent orchestration을 지원하기 위한 소프트웨어
|
||||
|
||||
|
||||
1. **CrewAI**
|
||||
- 역할 기반(Role-based) 협업을 설계하는 데 특화된 프레임워크입니다. 각 에이전트에게 명확한 역할(Role), 목표(Goal), 배경 설명(Backstory)을 부여하고, 이들을 업무 프로세스(Sequential 또는 Hierarchical)에 따라 배치해 '크루(Crew)' 단위로 조율합니다.
|
||||
1. **Microsoft AutoGen**
|
||||
- 대중 에이전트 간 대화(Conversational Agentic Design)에 중점을 둔 프레임워크입니다. 다양한 LLM과 도구(Tools)가 연결된 여러 에이전트가 서로 대화를 주고받으며 코드 실행 및 피드백을 처리할 수 있으며, 동적 워크플로우 및 인간의 개입(Human-in-the-loop)을 풍부하게 지원합니다.
|
||||
1. **BeeAI**
|
||||
- BeeAI는 프레임워크 전반에서 [AI 에이전트](https://www.ibm.com/kr-ko/think/topics/ai-agents)를 탐색, 실행 및 공유할 수 있는 중앙 집중형 환경을 제공하는 [오픈소스](https://www.ibm.com/kr-ko/think/topics/open-source) 플랫폼입니다. IBM이 개발한 BeeAI는 에이전트 통신 프로토콜(ACP)을 기반으로 구축되었으며 Linux Foundation에서 호스팅됩니다. 팀은 BeeAI 프레임워크를 사용하여 사일로화된 에코시스템 외부에 에이전트를 배포할 수 있습니다.
|
||||
|
||||
## Multi Agent 환경 구성을 위한 Protocols
|
||||
|
||||
### MCP/ACP
|
||||
다양한 서비스와 이종 에이전트들이 상호 작용하기 위해 필요한 개방형 표준 통신 프로토콜입니다.
|
||||
- **Model Context Protocol (MCP)**: Anthropic이 2024년 11월 발표한 오픈 소스 프로토콜로, AI 애플리케이션(Host) 내부의 클라이언트(Client)가 로컬/원격의 도구(Tools), 데이터 소스(Resources), 그리고 컨텍스트 템플릿(Prompts)을 통일된 규격으로 안전하게 호출할 수 있는 공통 인터페이스입니다.
|
||||
- **Agent Communication Protocol (ACP)**: IBM Research가 BeeAI 프레임워크 구동을 지원하기 위해 2025년 3월 발표했던 오픈 표준 에이전트 통신 인터페이스입니다. 이종 에이전트 간의 서비스 발견(Service Discovery), 상호작용 방법 협상, 태스크 위임 프로세스를 규격화하였으며, 이후 2025년 8월 27일 공식 깃허브 저장소가 아카이빙되며 Linux Foundation AI & Data 하위의 A2A(Agent-to-Agent) 프로토콜로 공식 통합 및 병합되었습니다.
|
||||
|
||||
### A2A
|
||||
- **A2A (Agent-to-Agent) 프로토콜**: Google이 2025년 4월에 50여 파트너사들과 공동 발표하고 2025년 6월 Linux Foundation에 기증한 이종 에이전트 간 통합 통신 오픈 표준입니다. 서로 다른 벤더가 구현한 에이전트나 다양한 아키텍처 기반의 에이전트가 복잡한 결합 코드(Glue code) 없이도 협업 메시지를 교환하고 상태를 추적할 수 있습니다.
|
||||
- **Agent Card (에이전트 카드)**: A2A 생태계에서 에이전트의 기능 명세서 역할을 하는 JSON 포맷의 표준 규격서입니다. 에이전트 카드에는 해당 에이전트의 명칭, 제공 가능한 역량(Capabilities), 호출 엔드포인트 정보, 요청 시 통과해야 하는 보안 인증 사양(Authentication) 등이 명시되어 있어 서비스 검색 시스템(Service Discovery)이 에이전트의 역할을 실시간으로 탐색할 수 있도록 돕습니다. 주로 `/.well-known/agent-card.json` 경로에서 탐색 가능하도록 배포됩니다.
|
||||
|
||||
# 실제 Multi Agent Orchestration을 구현하며 겪은 문제점들
|
||||
|
||||
|
||||
1. **Agent들과 각 Agent들의 세션 관리**
|
||||
- 다수의 에이전트와 그 아래에 동적으로 생성되는 subagent들의 생명주기(Lifecycle) 및 고유 식별자(UUID)를 동기화하고 상태를 지속적으로 보존하는 일관된 세션 관리 시스템이 필요합니다.
|
||||
2. **에이전트 상호 탐색(Service Discovery)과 역할 식별**
|
||||
- 새로운 에이전트가 네트워크에 진입했을 때 어떤 에이전트가 어떤 과업을 처리할 수 있는지 동적으로 파악해야 합니다.
|
||||
- **마스터 - 슬레이브(Master-Slave) 방식**: 중앙 오케스트레이터가 전권을 쥐고 세션을 직접 관리 및 명령하므로 통제는 쉬우나, 오케스트레이터의 에러가 시스템 전체의 단일 실패점(SPOF)이 될 위험이 있습니다.
|
||||
- **P2P 및 보고(P2P and Report) 방식**: 에이전트들이 동등한 위치에서 협상하며 자율적으로 탐색하고, 작업 결과를 동기적으로 혹은 비동기적으로 기록 보관소에 보고하는 방식이지만 네트워크 관리 비용이 큽니다.
|
||||
3. **실시간 메시징과 이벤트 예외 처리의 복잡성**
|
||||
- 태스크 위임 완료 후, 작업 결과와 성공/실패 여부를 교환하는 통신 채널이 중단되거나 유실될 수 있습니다.
|
||||
- **송신/수신 주체의 돌발 종료**: A 에이전트가 작업을 위임한 후 예상치 못하게 다운되었다가 재가동(Restart)된다면, B 에이전트가 작업을 완료한 뒤 발송한 비동기식 실시간 알람이 허공으로 날아가 결국 전체 협업 루프가 끊어집니다.
|
||||
- **무한 대기 및 리소스 누수(Deadlock & Resource Leak)**: 작업을 전달받은 subagent가 아무런 예외 통보(Timeout 또는 Error Event) 없이 갑자기 고사(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 기반 에이전트에게 피드백받음) 간에 상호 보완하도록 할 때 결과물의 신뢰성이 극적으로 향상됩니다. 이종 모델들이 세상을 바라보는 가중치와 강점이 다르기 때문에 보이지 않는 맹점(Blind spot)을 상호 보완해 줍니다.
|
||||
4. **비용 효율적인 토큰 분배 (Cost Optimization)**
|
||||
- 모든 에이전트가 값비싼 최상위 프론티어 LLM 모델만을 사용할 필요가 없습니다. 작업의 요구 난이도와 속도, 정확성을 저울질하여 쉬운 코드 생성이나 정보 검색은 경량화된 저비용 모델(예: Gemini Flash 세대)을 탑재한 에이전트에 분산 위임하고, 고난도의 논리적 추론이 필요한 부분에만 최상위 고비용 모델을 탑재한 에이전트를 적절히 매칭함으로써 종합적인 API 비용을 효율적으로 제어할 수 있습니다.
|
||||
|
||||
# What We Need?
|
||||
성공적인 Multi-Agent Orchestration 구현을 위해 갖추어야 할 기본 필수 구성요소들입니다:
|
||||
1. **Agent 간 작업 환경 공유 (A2A의 Agent Card 기반)**
|
||||
- 특정 에이전트에게 태스크를 안전하게 위임하고 위임받기 위해선, 각 에이전트 카드를 통해 서로의 역할, 엔드포인트, 입력 명세 스키마를 신뢰할 수 있는 방식으로 확인하고 동기화할 수 있어야 합니다.
|
||||
2. **에이전트 작동 인프라스트럭처 (Agent Working Infrastructure)**
|
||||
- 에이전트들이 통신에 사용할 서비스 주소와 포트를 동적으로 조회할 수 있는 서비스 디스커버리(Service Discovery) 기능 및 자동 라우팅 체계가 내재되어야 합니다.
|
||||
3. **일관성 있는 워크플로우 추적 및 공유 (Issue & Workflow Tracking)**
|
||||
- 서로 다른 에이전트가 동일한 작업을 재수행할 때 동일한 프로세스와 출력을 일관되게 얻을 수 있도록 워크플로우 사양이 제어되어야 합니다. 또한 에러나 중간 정지가 일어났을 때 복구 및 추적이 용이하도록 규격화된 이슈 추적 인터페이스(Issue Tracking Interface)를 마련해야 합니다.
|
||||
|
||||
|
||||
|
||||
4. **고성능 양방향 메시징 시스템 (Advanced Messaging System)**
|
||||
- 고용량의 코드 블록, 이미지 및 멀티모달 센서 데이터 등을 대량으로 빠르고 정확하게 공유하기 위해서는 기존의 MQTT나 단순 메시지 큐(MQ) 방식은 토픽 세분화와 페이로드 크기 한계로 인해 통신 병목을 겪을 수밖에 없습니다.
|
||||
- 단편적인 이벤트 알림만 전송하는 구조에서 탈피하여 상세 에러 트레이스, 상태 구조체, 이미지 바이너리 등을 한꺼번에 담을 수 있는 풍부한 페이로드 지원 메시징 규격이 필수적입니다. 나아가 대용량 멀티모달 푸시(Push)와 양방향 스트리밍을 지원하기 위해 HTTP/3의 멀티 스트리밍 등 고성능 통신이 수반되어야 합니다.
|
||||
5. **작업 및 태스크 관리 시스템 (Job & Task Lifecycle Controller)**
|
||||
- 하나의 부모 작업을 하위 스크럼(Scrum) 단위로 쪼개어 서브에이전트들에게 뿌려주는 라이프사이클 관리 기능이 있어야 합니다. 각 서브에이전트의 생성부터 소멸까지의 메시징 토픽과 임시 토큰을 정리해야 하며, 이 과정에서 부하를 고르게 배분하고 실력 있는 에이전트를 매칭하기 위한 로드 밸런싱(Load Balancing) 기법이 병행되어야 합니다.
|
||||
|
||||
## Why we need gRPC?
|
||||
이러한 해결 과제와 인프라 요구사항 속에서 **gRPC (Google Remote Procedure Call)** 프로토콜은 멀티 에이전트 인프라의 핵심 백본으로 기능합니다.
|
||||
1. **A2A 프로토콜과의 높은 호환성 및 스마트 팩토리/팜 최적화**
|
||||
- 개발 인터페이스 모듈은 스마트 팜, 스마트 팩토리와 같은 AIoT 서비스를 주요 타겟으로 개발되고 있습니다. 대역폭 및 성능 제약이 극심한 초경량 센서 디바이스 계층에서는 MQTT/CoAP 등을 보완적으로 혼용할 수 있으나, 상위의 데이터 수집 게이트웨이 및 엣지 연산 계층에서는 gRPC가 자율 통합 제어를 위한 강력하고 최적의 통신 프로토콜이 됩니다.
|
||||
2. **고성능 멀티 모달 바이너리 스트리밍 및 Pub/Sub 네이티브 지원**
|
||||
- AIoT나 지능형 에이전트 시스템은 텍스트뿐만 아니라 고해상도 이미지, 소리 주파수 등 대량의 멀티모달 데이터를 처리합니다. HTTP/2 또는 HTTP/3 기반으로 작동하는 gRPC는 양방향 스트리밍(Bidirectional Streaming)과 Request/Response, Pub/Sub 통신 스타일을 단일 포트에서 완벽히 소화하여, 복잡한 네트워크 요구사항을 단숨에 통합시킵니다.
|
||||
- 마이크로서비스 아키텍처(MSA)에서 메인 인터페이스로 gRPC가 통용되고 있으므로, 현업 시스템으로의 이식 및 확장 속도가 독보적으로 빠릅니다.
|
||||
3. **구조화된 직렬화 기반의 효율적 태스크 생명주기 및 부하 분산**
|
||||
- Protobuf(Protocol Buffers)를 통한 강력한 스키마 정의는 대량의 동적 서브에이전트들과 오케스트레이터 간에 쏟아지는 통신 메시지를 JSON 문자열 파싱 대비 수배 이상 빠르고 메모리 효율적으로 처리할 수 있게 합니다.
|
||||
- 이미 검증된 수많은 gRPC 기반 로드 밸런싱 및 이슈 트래킹 도구(예: Envoy, Kubernetes gRPC liveness probe 등)를 적극 도입함으로써, 에이전트 라이프사이클 감시 체계를 커스텀 빌드할 필요 없이 기성 인프라로 손쉽게 구축할 수 있습니다.
|
||||
@@ -0,0 +1,133 @@
|
||||
# 학술 논문 관점의 README.md 내용 냉정평가 및 리뷰서 (Review Report)
|
||||
|
||||
본 평가는 `canary-projects-multi-agent-creator-claude` 및 `canary-projects-multi-agent-creator-hermes` 두 에이전트와 함께 웹 서칭, 관련 표준 문서 대조, 분산 시스템 고전 이론 검토를 거쳐 교차 검증한 후 Antigravity가 최종적으로 통합 및 정리한 내용입니다.
|
||||
|
||||
---
|
||||
|
||||
## ⚖️ 종합 판정 (Overall Verdict)
|
||||
> **"현재 문서는 학술 논문(Research Paper)이 아니라, 실무자 관점의 '세미나 발표 스크립트' 또는 '기술 블로그' 수준입니다."**
|
||||
>
|
||||
> 실무적인 구현 과정에서 겪은 에러 패턴과 인프라의 필요성을 명확히 지적하여 현업에서의 통찰력은 매우 뛰어납니다. 하지만 학술적 엄밀함(Formality), 관련 연구(Related Work)와의 차별성 분석, 제안 아키텍처의 논리적 완결성, 그리고 가설을 뒷받침할 정량적 평가 데이터(Evaluation) 등 **연구 논문이 갖추어야 할 핵심 기둥이 모두 부재한 상태**입니다.
|
||||
>
|
||||
> 다만, 본문에서 다루고 있는 **'비동기 에이전트 위임 시의 소리 없는 고사(Silent Death) 문제'**와 **'엣지 AIoT 환경에서의 gRPC 기반 경량화 백본 설계'**라는 주제는 분산 시스템 이론과 결합하여 실증 실험 데이터를 보완한다면 충분히 **우수한 컴퓨터공학/시스템 분야 논문(IEEE, ACM 또는 관련 학회)으로 발전할 잠재력**을 가지고 있습니다.
|
||||
|
||||
---
|
||||
|
||||
## 1. 🌟 주요 장점 (Strengths)
|
||||
|
||||
* **[S1] 실무 경험에서 도출된 정교한 분산 에러 모델 분류 (Problem Taxonomy)**
|
||||
* 에이전트 조율을 실제 구현해보지 않으면 알 수 없는 핵심 병목인 ① 세션 생명주기 및 UUID 동기화 복잡성, ② 마스터-슬레이브와 P2P 탐색 토폴로지의 트레이드오프, ③ 비동기 에이전트 위임 시 발생하는 **"소리 없는 고사(Silent Death)로 인한 무한 대기(Deadlock)"** 현상을 명확하게 시스템 에러 모델로 발굴했습니다. 이 부분은 단순 LLM 프로그래밍을 넘어 시스템 엔지니어링 관점에서 매우 가치 있는 문제 정의입니다.
|
||||
* **[S2] AIoT 엣지 환경에 특화된 Resumable/Stateful gRPC 스트리밍 아키텍처 설계**
|
||||
* 단순히 에이전트 통신에 gRPC를 적용하는 일반적 설계를 넘어, 네트워크 연결 유실이 빈번한 AIoT 엣지 연산 제약 환경을 타겟으로 'Resume Token' 기반의 스트림 재개 및 분산 상태 보존 설계를 강점으로 내세우고 있습니다. 기존 연구들이 단순 HTTP/REST나 비영속 웹소켓 통신에 의존한 반면, 본 아키텍처는 가용성을 극대화하기 위한 전송-오케스트레이션 결합 설계를 구체적으로 제안했다는 점에서 차별성을 갖습니다.
|
||||
* **[S3] 검증 가능한 구체적 연구 가설 (Cross-Model Review)**
|
||||
* 자가 검토(Same-Model Review)와 이종 모델 교차 검토(Cross-Model Review, 예: Gemini Flash ↔ Claude Sonnet)의 결과물 신뢰도 향상 및 오류 감지율에 관한 가설은 독립적인 실증 논문으로 구성하기에 충분할 정도로 구체적이고 검증 가능한(Falsifiable) 훌륭한 연구 주제입니다.
|
||||
* **[S4] 현실적인 3계층 하이브리드 네트워크 설계**
|
||||
* 모든 인프라를 gRPC로 획일화하지 않고, 대역폭 및 성능 제약이 극심한 초경량 센서 디바이스는 MQTT/CoAP을 보완적으로 쓰고, 상위 게이트웨이 및 엣지 연산 계층에 gRPC를 배치한 완충 설계(Hedge)는 네트워크 실무와 아키텍처의 트레이드오프를 훌륭히 방어해 냅니다.
|
||||
* **[S5] 최신 프로토콜 표준 동향 반영**
|
||||
* Model Context Protocol (MCP), Agent Communication Protocol (ACP) 및 이들의 Linux Foundation A2A(Agent-to-Agent) 표준 프로토콜로의 통합 타임라인(2025년 8월 통합)을 정확하게 파악하여 최신 표준화 생태계에 부합하게 작성되었습니다.
|
||||
|
||||
---
|
||||
|
||||
## 2. ⚠️ 치명적 약점 및 Limitations (Weaknesses)
|
||||
|
||||
* **[W1] 연구 질문(Research Question) 및 구체적 가설의 결여 (Critical)**
|
||||
* 문서의 구성이 교과서식 나열("A란 무엇인가? → B란 무엇인가?")로 진행되어 연구로서 무엇을 규명하고자 하는지가 불분명합니다. 논문으로 발전시키기 위해서는 반드시 다음과 같은 형식의 연구 질문이 명시되어야 합니다.
|
||||
* *예: "엣지 AIoT 연산 제약 환경에서 gRPC 기반 경량 메시징 인터페이스가 LLM 에이전트 오케스트레이션의 신뢰성과 응답 지연에 미치는 영향은 무엇인가?"*
|
||||
* **[W2] 문제 정의와 기술적 해결책 간의 논리적 단절 (Non-sequitur) (Critical)**
|
||||
* **본 논문 드래프트의 가장 치명적인 검토 탈락 요인(Review-killer)입니다.**
|
||||
* 본문에서 제기한 주요 문제점들(알람 누락, 소리 없는 고사로 인한 데드락 등)은 **상태 관리 및 시스템 안정성 아키텍처(Orchestration/Supervision Layer)** 영역의 이슈입니다. 그러나 결론부에서는 **전송 및 직렬화 계층(gRPC/Protobuf)**을 해결책으로 지시하고 있습니다. 이는 레이어의 혼동에서 비롯된 논리적 오류입니다.
|
||||
* gRPC는 연결 지향형(Connection-oriented) 프로토콜입니다. 작업을 위임한 상위 에이전트가 돌발 종료 후 재시작하면, 진행 중이던 gRPC 연결 및 인플라이트(In-flight) 스트림은 완전히 유실됩니다. 본문에서 해결하고자 했던 "재시작 후 유실 없는 알림 수신"은 gRPC가 아니라, 기존 시스템의 **MQTT Persistent Session/Retained Message나 영속적 메시지 큐(Message Queueing)**를 통해서 구현된 특성이었습니다. gRPC로 단순 전환하게 되면 오히려 이 안정성 구조가 깨지게 됩니다.
|
||||
* 따라서 날카로운 심사위원은 *"진짜 해결책은 Durability(지속성) 및 Supervision Tree(감독 트리) 설계이며, gRPC로의 교체는 엉뚱한 레이어를 공략한 것이다"*라고 비판할 것입니다.
|
||||
* **[W3] 기술적 오류 및 표준 프로토콜 성숙도 과장 (Major)**
|
||||
* **gRPC의 Pub/Sub 네이티브 지원 주장**: gRPC는 단일 연결 상에서의 양방향 스트리밍(Streaming RPC)을 지원할 뿐, 자체적인 메시지 브로커, N대N 팬아웃(Fan-out), 혹은 보존(Retention) 메커니즘을 내장하고 있지 않습니다. 이를 'Pub/Sub 네이티브 지원'이라고 묘사하는 것은 명백한 오해입니다.
|
||||
* **gRPC-over-HTTP/3 성숙도**: gRPC-over-HTTP/3는 대다수의 상용 프레임워크 스택에서 아직 실험적이거나 일부만 지원되는 단계입니다. 이를 '검증된 성능'으로 과장되게 서술해서는 안 됩니다.
|
||||
* **계층 구조의 혼재**: 전송(gRPC/MQTT/CoAP/QUIC), 직렬화(Protobuf/JSON), 시맨틱 규약(MCP/A2A/ACP), 오케스트레이션 프레임워크(CrewAI/AutoGen/LangGraph)를 혼동하여 서술하고 있습니다. 학술 논문은 이 네 가지 레이어를 확실히 구분하고, 제안 시스템이 각 레이어에서 어떤 구성을 취하는지 아키텍처 다이어그램으로 증명해야 합니다.
|
||||
* **[W4] 정량적 평가 데이터 및 실증(Evaluation)의 전무 (Critical)**
|
||||
* 학술 연구에서는 "극적으로 향상", "독보적으로 빠름", "비용을 효율적으로 제어" 등의 추상적/주관적 수식어를 증거 없이 사용하는 것을 철저히 배제합니다.
|
||||
* **치명적인 병목(Bottleneck) 오류**: LLM 에이전트 오케스트레이션에서 총 지연 시간(End-to-End Latency)의 대다수(예시적 수치 기준 95% 이상; 실제 디바이스 사양 및 LLM 워크로드에 따른 실측 필요)는 LLM의 토큰 생성 시간(초 단위)입니다. 메시지 직렬화 및 파싱 시간(마이크로초~밀리초 단위)은 전체 지연의 극히 일부(1% 미만)에 불과합니다. 따라서 "JSON 파싱 속도가 느려서 Protobuf를 도입해 성능 향상을 도모한다"는 주장은 실제 LLM 지연 시간에 묻혀 설득력을 잃게 되므로, 가용 무선 대역폭이 극히 제약되거나 대용량 멀티모달 센서 데이터 스트리밍이 빈번한 AIoT 엣지 환경으로 컨텍스트를 제한하여 논리를 전개해야 합니다.
|
||||
* **[W5] 정립되지 않은 학계 유용어의 남용 ("Context Engineering") (Moderate)**
|
||||
* "컨텍스트 엔지니어링(Context Engineering)"은 프랙티셔너 및 오픈소스 업계(LangChain 등)에서 널리 쓰이지만, 엄밀한 학술 논문에서 공인된 이론적 용어가 아닙니다. 이 용어를 핵심 키워드로 사용하려면 명확한 정의를 제시하고 출처를 밝히거나, 학술적으로 공인된 'Context Management' 또는 'State Synchronization in Multi-Agent Systems' 등의 표준 컴퓨터공학 용어로 대체해야 합니다.
|
||||
* **[W6] 문헌 인용(Citations) 및 포지셔닝 부재 (Major)**
|
||||
* 본문은 AutoGen(Wu et al. 2023), CrewAI, LangGraph 등 기성 학술적/산업적 논문을 나열하고만 있을 뿐, 본 연구가 이들 대비 이론적으로 어떤 갭(Research Gap)을 극복했는지 포지셔닝하지 않았습니다. Peter Steinberger의 인용구 역시 정식 논문 인용(Academic Citation)으로 변환되어야 합니다.
|
||||
* **[W7] 제안 아키텍처(gRPC 백본)의 핵심 신규성이 A2A 표준에 의해 선점됨 (Critical)**
|
||||
* 본 연구가 독창성을 인정받으려면 A2A 표준 사양을 넘어서는 지점, 즉 (i) 네트워크 유실 대응을 위한 Resume Token 기반의 Resumable Stream 및 exactly-once 작업 완료 보장 시맨틱, (ii) 에이전트 작업 생명주기 유한상태기계(FSM) 설계, (iii) AIoT 엣지 환경에 최적화된 경량 스키마와 2계층 거버넌스 등을 논문의 핵심 기여로 정교하게 포지셔닝해야 합니다.
|
||||
* **[W8] 연구 스코프(Scope)의 불일치 및 불명확성 (Minor)**
|
||||
* 현재 문서는 일반적인 소프트웨어 에이전트 오케스트레이션(PM-Worker-Reviewer 역할 분담, API 비용 라우팅)과 저전력 AIoT 엣지 디바이스 통신이라는 서로 다른 성격의 도메인을 명확한 경계 없이 혼재하여 다루고 있습니다. 학술적으로 명확한 설득력을 갖기 위해선 "엣지 AIoT 연산/대역폭 제약 환경"으로 연구 타겟 스코프를 명확히 고정하고 논지를 전개해야 합니다.
|
||||
|
||||
---
|
||||
|
||||
## 3. 🔍 기회 요인 및 핵심 Research Gaps (학술적 기여 가능성)
|
||||
|
||||
논문으로 성공하기 위해 본 드래프트에서 반드시 확보하고 논증해야 하는 학술적 갭(Gaps)들입니다:
|
||||
|
||||
* **[G1] 에이전트 "Silent Death" 현상에 대한 분산 고장 탐지 이론 (Failure Detector) 공식화**
|
||||
* 에이전트가 모니터링 노티 없이 죽는 현상은 분산 시스템의 고전적인 **'Crash-stop failure'** 및 **'Liveness vs Safety'** 문제와 완벽히 궤를 같이합니다. Chandra와 Toueg의 고전 논문 *'Unreliable Failure Detectors for Reliable Distributed Systems' (1996)* 이론을 끌고 들어와, 비동기 LLM 에이전트 환경에 맞춘 '약한 고장 탐지기(Weak Failure Detector)'를 공식 정의하고, 이를 해결하기 위한 'Dual-timeout & Heartbeat' 복구 메커니즘을 수학적/논리적으로 공식화(Formalization)한다면 매우 강력한 시스템 논문이 될 것입니다.
|
||||
* **[G2] 이종 LLM 에이전트 교차 검증에 대한 체계적 실증 비교 실험**
|
||||
* Gemini Flash 세대와 Claude Sonnet 등 다양한 모델의 단일 모델 자가 리뷰 vs 이종 모델 교차 리뷰 조건에서 코드 생성 결함(Defect Rate) 발견 성능, 비용 대비 정확도 향상 비율을 실제로 실험하고 그 데이터를 테이블(Table)과 그래프(Graph)로 완벽히 입증해 보여주어야 합니다.
|
||||
* **[G3] 에이전트 통신 환경 하에서의 gRPC vs JSON-RPC/REST 정량 마이크로 벤치마크**
|
||||
* 에이전트 메시지의 페이로드 크기별(1KB 이벤트 알림, 100KB 복잡 태스크 데이터, 10MB 이미지 바이너리) 직렬화 속도와 CPU 점유율, 가용 무선 네트워크 대역폭 대비 전송 성공률을 비교 측정하여 gRPC가 스마트 팜/팩토리 엣지 계층에서 실제로 왜 필요한지 정량 지표로 입증해야 합니다.
|
||||
* **[G4] 보안 위협 모델링 (Byzantine / Adversarial 에이전트)**
|
||||
* A2A나 ACP 환경처럼 조직의 경계를 넘나드는 멀티 에이전트 환경에서는 악의적인 에이전트가 잘못된 정보를 주입하거나(Byzantine Fault), 데이터를 탈취하는 위협이 발생합니다. 프로젝트의 `DESIGN.md`가 제시한 SPIFFE 식별자 기반 mTLS 및 HMAC 서명이 이 적대적 보안 위협을 어떻게 수학적/논리적으로 해결하는지 기술해야 합니다.
|
||||
* **[G5] 확장성 한계 및 조정 오버헤드 (Scalability Bounds & Coordination Overhead)**
|
||||
* 동적 세션 관리의 한계, 동시 메시지 처리량(Throughput) 임계치, 에이전트 수 증가에 따른 지연 시간의 변화(Latency degradation)를 정량 분석해야 합니다. 단일 오케스트레이터가 지원 가능한 최대 에이전트 수의 임계치와 병목 요인을 벤치마크하여, 조정 오버헤드를 줄이기 위한 토폴로지 분할 기법을 다루어야 합니다.
|
||||
* **[G6] 에이전트 워크플로우의 재현성 및 결정론(Determinism) 확보 방안**
|
||||
* 드래프트에서 "동일 작업에 대해 항상 동일한 출력 보장"을 요구하는 것은 LLM 자체의 확률적 특성(Stochasticity)과 정면으로 충돌하는 지점이 있습니다. 이를 해결하기 위해 에이전트 오케스트레이션 상에서 에이전트 상태 복구 시 LLM 비결정론적 응답으로 인한 정합성 유실 문제를 제어하는 기법이나 시드 제어, 캐싱 사양을 '재현성 갭(Reproducibility Gap)'으로 정의하고 탐구해야 합니다.
|
||||
|
||||
---
|
||||
|
||||
## 4. 📐 추천하는 논문 구조 개정안 (Proposed Restructuring)
|
||||
|
||||
학술 저널/학회 제출을 목표로 할 경우, 현재 스크립트 형태의 문서를 다음과 같이 리스트럭처링할 것을 권장합니다:
|
||||
|
||||
1. **초록 (Abstract)**: 엣지 AIoT 에이전트 협업 시 발생하는 무선 대역폭 낭비 및 비동기 데드락(Silent Death) 문제를 정의하고, 본 논문이 제안하는 3계층 하이브리드 gRPC 아키텍처와 분산 고장 탐지 기법 및 그로 인한 성능 향상 성과를 요약합니다.
|
||||
2. **서론 (Introduction)**: 단일 에이전트의 한계 및 멀티 에이전트 협업의 중요성을 강조하고, 기존의 HTTP/JSON 기반 프레임워크가 엣지 AIoT 실시간 제어 환경에 부적합한 이유(대역폭, 지연, 신뢰성 유실)를 제시하여 연구 동기를 유도합니다.
|
||||
3. **관련 연구 (Related Work)**:
|
||||
* *오케스트레이션 프레임워크*: AutoGen, CrewAI, LangGraph의 한계 분석
|
||||
* *통신 프로토콜 표준*: FIPA ACL, Model Context Protocol (MCP), Agent-to-Agent (A2A) 현황
|
||||
* *분산 고장 탐지 이론*: Distributed Failure Detectors
|
||||
4. **문제 정의 및 고장 모델 정의 (System Model & Failure Formulation)**:
|
||||
* 에이전트 간 비동기 위임 시 "소리 없는 고사(Silent Death)" 상태를 수학적으로 공식화하고, 왜 연결 지향형 gRPC 자체만으로는 이를 해결할 수 없는지 증명합니다.
|
||||
5. **제안 아키텍처 (Proposed Architecture)**:
|
||||
* 본문 및 `DESIGN.md` 기반의 3계층(디바이스-게이트웨이-클라우드) 에이전트 협업 구조 제시
|
||||
* 오케스트레이션 계층의 상태 지속성(Durability)과 감독 트리(Supervision Tree) 설계 메커니즘 상세 설명
|
||||
* gRPC와 MQTT의 하이브리드 메시징 라우팅 사양 및 Agent Card를 활용한 Service Discovery 메커니즘
|
||||
6. **구현 (Implementation)**:
|
||||
* 레포지토리에 구현된 실무 모듈(`mqtt_common.py`, `registry.py`, `job_subscriber.py`)의 아키텍처와 프로토콜 버퍼 스키마 설계 내용 서술
|
||||
7. **성능 평가 및 분석 (Evaluation)**:
|
||||
* *실험 1*: 이종 모델 교차 검증의 오류 감지 정확성 및 비용 분석 데이터
|
||||
* *실험 2*: 메시지 크기별 gRPC vs JSON-RPC 마이크로 벤치마크 (지연 시간, CPU, 대역폭)
|
||||
* *실험 3*: Silent Death 발생 시 감지 시간 및 시스템 복구 성공률 (MQTT vs Proposed Stateful gRPC)
|
||||
8. **토론 및 한계점 (Discussion & Limitations)**: 비잔틴 보안 모델 및 일반화 가능성의 위협 요소 고찰
|
||||
9. **결론 (Conclusion)**: 요약 및 향후 연구 방향 제시
|
||||
|
||||
---
|
||||
|
||||
## 5. 👥 서브 에이전트 교차 메타 리뷰 (Sub-Agent Meta-Review)
|
||||
|
||||
에이전트 `claude` 및 `hermes`가 본 논문 주제의 독창성(Novelty)과 학술지/학회 게재 타당성을 추가 교차 검증한 결과입니다.
|
||||
|
||||
### 5.1. 학술적 가치 및 독창성 (Academic Novelty Analysis)
|
||||
* **핵심 연구 질문으로의 전환 필요 (G6 확장 - 필수)**
|
||||
* 기존 분산 시스템 관점에서 에이전트의 crash-stop, blocked caller, lost notification 등은 이미 Erlang/OTP 감독 트리(1990s), Chandra-Toueg Failure Detector(1996) 등으로 해결된 영역입니다. 따라서 단순 시스템 구현 나열은 *"Erlang OTP의 액터 모델을 에이전트 도메인에 재발명했다"*라는 심사위원의 비판을 피하기 어렵습니다.
|
||||
* 이를 극복할 **진짜 독창성은 [G6] 비결정론적 복구 문제(Recovery under non-determinism)**에 있습니다. 고전적인 분산 복구 기법은 결정론적 재플레이(Deterministic Replay)를 전제로 하지만, LLM 에이전트의 연산은 확률적(Stochastic)이고 비멱등적(Non-idempotent)입니다. **"단위 작업이 비결정론적일 때, 어떻게 exactly-once 실행 완료와 정합성 있는 상태 복구를 분산 오케스트레이션 상에서 제공할 것인가?"**라는 질문은 학계에서 아직 답해지지 않은 깊고 강력한 연구 질문이 됩니다.
|
||||
* **LLM 에이전트 고사 탐지의 모호성 (G1 확장)**
|
||||
* 전통적인 분산 고장 모델은 프로세스가 살아있거나(Heartbeat 응답), 죽었거나(응답 없음) 둘 중 하나입니다.
|
||||
* 하지만 LLM 에이전트는 프로세스가 살아있음에도 **토큰을 추론하는 중(Thinking)이라 하트비트를 보내지 못하는 '제3의 모호한 상태'**를 가집니다. 이를 '제한된 추론 시간(Bounded Thinking Time)을 갖는 반동기식 고장 탐지기' 모델로 수학적으로 정의하고 공식화(Formalization)하는 방향은 매우 훌륭한 분산 시스템 기여가 됩니다.
|
||||
|
||||
### 5.2. 실험 설계의 교란 변수 통제 (Experimental Rigor & Confounder Control)
|
||||
* **실험 1 (Microbenchmarks - gRPC vs JSON-RPC)**: W4에서 지적했듯 직렬화 성능은 전체 LLM 지연 시간의 1% 미만이므로, 본 실험은 메인 주장이 아닌 **'대용량 멀티모달 센서 데이터 전송이 빈번한 연산 제약 AIoT 엣지 환경'**이라는 특정 상황을 방어하기 위한 보조 데이터로 격하시켜 배치해야 합니다.
|
||||
* **실험 2 (Resilience/Recovery - Confounder Control)**: 복구 속도 단축 등 성능 이득은 gRPC 자체의 효율성보다는 오케스트레이션 계층(Durability + Supervision)의 기여가 큽니다. 따라서 단순 Naive MQTT vs Proposed Stateful gRPC의 비교는 변수가 통제되지 않은 Confounded(교란된) 실험으로 거절 요인이 됩니다.
|
||||
* 반드시 **$2 \times 2$ 매트릭스** 대조군 구조(`{MQTT, gRPC}` $\times$ `{Naive(미감독), Supervised(감독 트리)}`)로 실험을 설계하여 각 계층의 기여도를 분리 증명해야 합니다.
|
||||
|
||||
### 5.3. 투고 전략 및 게재 확률 (Venues & Probability Estimates)
|
||||
연구의 초점(Focus)을 잃지 않기 위해, 하나의 논문으로 통합하기보다 다음의 방향으로 분할(Splitting)하는 투고 전략을 강력히 권장합니다.
|
||||
|
||||
1. **논문 A: 시스템/이론 중심 (Failure Detection & Recovery in Stochastic Agents)**
|
||||
* *타겟*: **IEEE Internet of Things Journal (Q1, IF~10)**, **IEEE EDGE (Conf)**, **ACM EdgeSys (Workshop)**
|
||||
* *예상 합격률*: **30~40%** (이론 공식화 및 $2 \times 2$ 대조 실험 보완 시)
|
||||
2. **논문 B: 실증 소프트웨어 공학 중심 (Cross-Model Review Empirical Study)**
|
||||
* *타겟*: **ASE (Top Conf)**, **ICSE (Empirical Track)**, **IEEE TSE (Journal)**
|
||||
* *예상 합격률*: **25~35%** (최소 4개 이상 모델 페어 테스트 및 통계적 유의성 검정 보완 시)
|
||||
3. **하나로 통합된 단일 논문 (Combined Single Paper)**
|
||||
* *예상 합격률*: **15~25% (폭락)**
|
||||
* *이유*: 시스템 심사위원은 SE 연구의 엄밀함을, SE 심사위원은 시스템 연구의 깊이를 동시에 의심하게 되어 게재가 거절될 위험이 극대화됩니다.
|
||||
@@ -0,0 +1,175 @@
|
||||
---
|
||||
title: 멀티 에이전트란
|
||||
description: 멀티에이전트의 개념 설명, 장점, 실제 구축을 통한 경험 공유를 세미나에서 발표하기 위한 발표 스크립트 및 발표자료 작성용 문서입니다.
|
||||
marp: true
|
||||
---
|
||||
# AI Agent란?
|
||||
|
||||
## General
|
||||
AI 에이전트(AI Agent)는 단순히 사용자의 텍스트 입력을 받아 응답을 생성하는 대화형 인터페이스(Chatbot)를 넘어, 주어진 최종 목표(Goal)를 자율적으로 달성하기 위해 환경을 인식(Perceive)하고, 스스로 계획(Planning) 및 추론(Reasoning)하며, 도구를 사용해 물리적/디지털적 행동(Action)을 수행하는 LLM 기반 소프트웨어 시스템입니다.
|
||||
|
||||
LLM 기반 에이전트 시스템 아키텍처는 크게 다음 3가지 핵심 요소로 구성됩니다:
|
||||
1. **Planning (계획 및 추론)**
|
||||
- **Task Decomposition (작업 분해)**: 거대하고 복잡한 목표를 실행 가능한 작은 단위의 세부 태스크로 쪼갭니다. (예: Chain of Thought, Tree of Thoughts 등)
|
||||
- **Self-Reflection (자기 성찰 및 피드백)**: 행동의 결과를 스스로 분석하고 실수를 교정하여 향후 계획을 실시간으로 수정합니다. (예: ReAct, Reflexion 프레임워크)
|
||||
2. **Memory (기억 장치)**
|
||||
- **Short-term Memory (단기 기억)**: 현재 대화나 컨텍스트 윈도우 내에서 실시간으로 유지되는 즉각적인 대화 맥락 정보입니다.
|
||||
- **Long-term Memory (장기 기억)**: 외부 데이터베이스나 벡터 DB(Vector DB) 등을 활용하여 과거 대화 기록, 대량의 지식을 인덱싱하고 필요시 RAG(검색 증강 생성) 기법으로 다시 불러오는 정보 보존 공간입니다.
|
||||
3. **Tool Use (도구 활용)**
|
||||
- 에이전트가 학습되지 않은 외부 정보에 접근하거나 외부 시스템에 영향을 미치기 위해 계산기, 코드 실행용 샌드박스, 웹 브라우저, 외부 API 등을 주도적으로 호출하는 능력입니다.
|
||||
|
||||
|
||||
|
||||
## AI Agent를 더욱 강력하게 만드는 Skills
|
||||
Skills(기술/도구 패키지)는 AI 에이전트가 외부 환경과 동적으로 상호작용할 수 있도록 결합하는 기능적 실행 모듈입니다. 단순히 LLM에게 행동 지침을 주는 프롬프트 엔지니어링 수준을 넘어, 에이전트가 특정 목표를 위해 직접 실행할 수 있는 코드, 도구의 명세 스키마(Tool Schema), 사용 설명 및 예시(Few-shot Examples) 등이 하나의 단위로 패키징된 자율적 확장 도구 모음입니다.
|
||||
- **동적 모듈화**: 에이전트는 상황에 따라 특정 기술을 필요할 때 로드하여 사용하고 완료 후 반환합니다.
|
||||
- **작업 수행 한계 돌파**: 텍스트 생성이라는 언어 모델 자체의 한계를 넘어, 시스템 레벨의 파일 제어, 서버 배포, 물리 데이터 수집 등의 적극적인 업무 대행 능력을 에이전트에 제공합니다.
|
||||
|
||||
## Claude cowork와 code
|
||||
- AI Agent의 대표 주자인 Claude는 Claude desktop 이라는 프로그램으로 자신들의 뛰어난 모델을 서비스하고 있으며, Claude Desktop App에서 우리는 Claude Cowork와 Claude Code라는 다른 서비스를 사용할 수 있음
|
||||
- Claude Cowork와 Claude Code는 같은 모델을 사용하지만 작동하는 방식이 완전히 다름. Claude Cowork의 경우 사무 작업 등 일상적인 업무의 비서 역할을 수행하며, Claude Code는 Coding 작업에 특화된 Coding Agent라고 소개함
|
||||
- 두 서비스는 동일하게 내부 컴퓨터의 특정 디렉터리에서 작업을 수행하지만 내부적인 작동 절차를 확인해보면 Claude Cowork는 Cloud에서 모델이 필요한 기능을 제공하여 pdf, word, excel, ppt 등 다양한 파일을 읽고 쓸 수 있도록 AI 모델의 기능을 확장한 서비스임
|
||||
- 반면에 Claude Code는 필요한 모듈, 소프트웨어가 있다면 Local Computer에 설치해서 사용한다는 차이점이 있음.
|
||||
|
||||
|
||||
|
||||
- Claude Cowork와 Claude Code를 비교하면 Claude Cowork가 더 좋아보일 수 있지만 Claude Code를 잘 조련하면 Claude Cowork 보다 훨씬 좋은 결과를 기대할 수 있음.
|
||||
|
||||
|
||||
|
||||
## Skills 사례 소개
|
||||
에이전트가 업무 현장에서 유용하게 사용하는 대표적인 Skills 사례들은 다음과 같습니다:
|
||||
1. **코드베이스 분석 및 관리 Skill**
|
||||
- 프로젝트 소스코드를 탐색(Grep), 특정 코드 조각을 치환(File replace), 변경 사항 검증(Linting), 최종 커밋 및 푸시 등을 처리하는 개발 자동화 Skill입니다.
|
||||
2. **브라우저 자동화 및 스크래핑 Skill**
|
||||
- 헤드리스 브라우저(Playwright, Puppeteer 등)를 기동하여 실시간 웹 트렌드 조사, 경쟁사 데이터 수집, 웹 UI에 대한 QA 테스트를 자율적으로 수행하는 Skill입니다.
|
||||
3. **인프라스트럭처 제어 및 DevOps Skill**
|
||||
- 클라우드 환경(AWS, GCP 등)이나 Firebase Hosting, Cloud Firestore 등과 같은 서버리스 백엔드 서비스의 배포 및 데이터베이스 규칙 수정을 지원하는 시스템 운영용 Skill입니다.
|
||||
4. **학술/도메인 특화 API Skill**
|
||||
- 생화학 데이터베이스(ChEMBL), 의학 학술 논문(PubMed, arXiv), 유전학 정보(dbSNP, ClinVar) 등 전문 영역의 연구용 OpenAPI와 연동하여 자율 연구원(Researcher) 역할을 돕는 조사용 Skill입니다.
|
||||
|
||||
### Github를 점령한 Skills
|
||||
|
||||
|
||||
### Understand skill
|
||||
Turn any codebase, knowledge base, or docs into an interactive knowledge graph you can explore, search, and ask questions about.
|
||||
|
||||
|
||||
### 유행이라 개발해본 multi-agent-mux skill
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
# Multi-Agent란
|
||||
|
||||
## General
|
||||
멀티 에이전트(Multi-Agent) 시스템은 단일 에이전트(Single Agent)의 한계를 극복하기 위해, 서로 다른 페르소나와 전문 도구(Skills)를 갖춘 여러 개의 에이전트들이 협력 네트워크를 형성하여 복잡한 목표를 조율(Orchestration)하고 분할 해결하는 구조입니다.
|
||||
|
||||
단일 에이전트는 대규모 컨텍스트를 처리할 때 정보 누락(Lost in the middle) 현상이 발생하기 쉽고, 여러 도구를 한꺼번에 다루어야 할 때 환각(Hallucination)율이 증가하는 문제가 있습니다. 멀티 에이전트의 필요성은 다음과 같습니다:
|
||||
1. **분할 정복 (Divide and Conquer)**: 하나의 거대한 프로젝트를 설계, 구현, 검증, 연구 등의 독립적인 세부 태스크로 분산시켜 병렬 및 정밀 처리를 지원합니다.
|
||||
2. **역할 정의 및 노이즈 최소화 (Role Specialization)**: 각 에이전트에게 한정된 역할(예: PM, Developer, QA, Researcher)과 타겟 도구만 부여하므로, 불필요한 프롬프트 노이즈를 제어하고 추론 정확도를 극대화할 수 있습니다.
|
||||
3. **이종 모델 융합 및 교차 검증**: 서로 다른 LLM을 각 역할에 최적화하여 융합 배치하고, 상호 비평 및 검토 루프를 구현함으로써 최종 결과물의 신뢰성을 극대화합니다.
|
||||
|
||||
## Multi Agent의 예시
|
||||
|
||||
### Subagent란
|
||||
Subagent는 부모 에이전트(Parent Agent 또는 Orchestrator)에 의해 동적으로 생성되어 특정 국소적이고 독립적인 태스크를 대행한 뒤, 결과를 상위로 반환하고 소멸하는 종속형 에이전트입니다.
|
||||
- **컨텍스트 격리**: 상위 에이전트의 전체 대화 컨텍스트를 오염시키지 않기 위해 하위 작업의 맥락만을 분기(Branch)하여 처리함으로써, 에이전트 실행 도중 누적되는 토큰 소모량을 최적화하고 속도를 개선합니다.
|
||||
- **예시**: 메인 에이전트가 "전체 코드 리팩토링"을 수행하면서, 특정 모듈에 대한 에러 복구 작업만을 subagent에게 위임하여 독립적으로 문제를 해결하게 하는 경우입니다.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Team agent란
|
||||
Team agent는 단일 계층적인 수직 구조를 넘어, 수평적이고 다양한 역할을 맡은 여러 독립 에이전트가 협의체(Crew/Team)를 구성하여 대화형 협력(Multi-agent Debate) 및 협상을 통해 목표를 완수하는 협동형 에이전트 구성 방식입니다.
|
||||
- **의견 충돌 및 합의**: 특정 설계안에 대해 아키텍트 에이전트와 보안 담당 에이전트가 서로의 입장에서 논쟁(Debate)을 벌이고, 최종적으로 합의된 결과를 PM 에이전트가 도출하는 식의 인간 워크플로우 모사가 가능합니다.
|
||||
- **협력적 의사결정**: 복잡한 비선형적 문제 해결에 있어 각 에이전트가 피드백을 실시간으로 주고받으며 점진적으로 답을 고도화합니다.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Context Engineering (Lang Graph)란
|
||||
컨텍스트 엔지니어링(Context Engineering)은 다중 에이전트 시스템에서 에이전트들 간의 대화 흐름, 전달되는 컨텍스트(State), 복잡한 제어 루프를 효율적으로 설계하고 유지하는 방법론적 학문입니다. 이를 구현하는 대표적인 상태 보존형 프레임워크가 LangGraph입니다.
|
||||
- **상태 보존 및 순환 제어(Stateful & Cyclic Control)**: 단순 선형적 체인 구조를 탈피하여, 에이전트 간의 루프(반복 검증), 조건부 분기(Conditional branching), 실패 시 롤백 등을 순환형 그래프(Cyclic Graph) 구조로 관리합니다.
|
||||
- **영속적 상태 관리**: 협업 과정에서 축적되는 다양한 상태 변화(State)를 중앙 저장소에서 추적 및 동기화하므로, 대형 워크플로우 도중 특정 노드가 실패하더라도 이전 상태부터 안전하게 재시작할 수 있습니다.
|
||||
|
||||
### CrewAI, Sana 등 Multi agent orchestration을 지원하기 위한 소프트웨어
|
||||
|
||||
|
||||
1. **CrewAI**
|
||||
- 역할 기반(Role-based) 협업을 설계하는 데 특화된 프레임워크입니다. 각 에이전트에게 명확한 역할(Role), 목표(Goal), 배경 설명(Backstory)을 부여하고, 이들을 업무 프로세스(Sequential 또는 Hierarchical)에 따라 배치해 '크루(Crew)' 단위로 조율합니다.
|
||||
1. **Microsoft AutoGen**
|
||||
- 대중 에이전트 간 대화(Conversational Agentic Design)에 중점을 둔 프레임워크입니다. 다양한 LLM과 도구(Tools)가 연결된 여러 에이전트가 서로 대화를 주고받으며 코드 실행 및 피드백을 처리할 수 있으며, 동적 워크플로우 및 인간의 개입(Human-in-the-loop)을 풍부하게 지원합니다.
|
||||
1. **BeeAI**
|
||||
- BeeAI는 프레임워크 전반에서 [AI 에이전트](https://www.ibm.com/kr-ko/think/topics/ai-agents)를 탐색, 실행 및 공유할 수 있는 중앙 집중형 환경을 제공하는 [오픈소스](https://www.ibm.com/kr-ko/think/topics/open-source) 플랫폼입니다. IBM이 개발한 BeeAI는 에이전트 통신 프로토콜(ACP)을 기반으로 구축되었으며 Linux Foundation에서 호스팅됩니다. 팀은 BeeAI 프레임워크를 사용하여 사일로화된 에코시스템 외부에 에이전트를 배포할 수 있습니다.
|
||||
|
||||
## Multi Agent 환경 구성을 위한 Protocols
|
||||
|
||||
### MCP/ACP
|
||||
다양한 서비스와 이종 에이전트들이 상호 작용하기 위해 필요한 개방형 표준 통신 프로토콜입니다.
|
||||
- **Model Context Protocol (MCP)**: Anthropic이 2024년 11월 발표한 오픈 소스 프로토콜로, AI 애플리케이션(Host) 내부의 클라이언트(Client)가 로컬/원격의 도구(Tools), 데이터 소스(Resources), 그리고 컨텍스트 템플릿(Prompts)을 통일된 규격으로 안전하게 호출할 수 있는 공통 인터페이스입니다.
|
||||
- **Agent Communication Protocol (ACP)**: IBM Research가 BeeAI 프레임워크 구동을 지원하기 위해 2025년 3월 발표했던 오픈 표준 에이전트 통신 인터페이스입니다. 이종 에이전트 간의 서비스 발견(Service Discovery), 상호작용 방법 협상, 태스크 위임 프로세스를 규격화하였으며, 이후 2025년 8월 27일 공식 깃허브 저장소가 아카이빙되며 Linux Foundation AI & Data 하위의 A2A(Agent-to-Agent) 프로토콜로 공식 통합 및 병합되었습니다.
|
||||
|
||||
### A2A
|
||||
- **A2A (Agent-to-Agent) 프로토콜**: Google이 2025년 4월에 50여 파트너사들과 공동 발표하고 2025년 6월 Linux Foundation에 기증한 이종 에이전트 간 통합 통신 오픈 표준입니다. 서로 다른 벤더가 구현한 에이전트나 다양한 아키텍처 기반의 에이전트가 복잡한 결합 코드(Glue code) 없이도 협업 메시지를 교환하고 상태를 추적할 수 있습니다.
|
||||
- **Agent Card (에이전트 카드)**: A2A 생태계에서 에이전트의 기능 명세서 역할을 하는 JSON 포맷의 표준 규격서입니다. 에이전트 카드에는 해당 에이전트의 명칭, 제공 가능한 역량(Capabilities), 호출 엔드포인트 정보, 요청 시 통과해야 하는 보안 인증 사양(Authentication) 등이 명시되어 있어 서비스 검색 시스템(Service Discovery)이 에이전트의 역할을 실시간으로 탐색할 수 있도록 돕습니다. 주로 `/.well-known/agent-card.json` 경로에서 탐색 가능하도록 배포됩니다.
|
||||
|
||||
# 실제 Multi Agent Orchestration을 구현하며 겪은 문제점들
|
||||
|
||||
|
||||
1. **Agent들과 각 Agent들의 세션 관리**
|
||||
- 다수의 에이전트와 그 아래에 동적으로 생성되는 subagent들의 생명주기(Lifecycle) 및 고유 식별자(UUID)를 동기화하고 상태를 지속적으로 보존하는 일관된 세션 관리 시스템이 필요합니다.
|
||||
2. **에이전트 상호 탐색(Service Discovery)과 역할 식별**
|
||||
- 새로운 에이전트가 네트워크에 진입했을 때 어떤 에이전트가 어떤 과업을 처리할 수 있는지 동적으로 파악해야 합니다.
|
||||
- **마스터 - 슬레이브(Master-Slave) 방식**: 중앙 오케스트레이터가 전권을 쥐고 세션을 직접 관리 및 명령하므로 통제는 쉬우나, 오케스트레이터의 에러가 시스템 전체의 단일 실패점(SPOF)이 될 위험이 있습니다.
|
||||
- **P2P 및 보고(P2P and Report) 방식**: 에이전트들이 동등한 위치에서 협상하며 자율적으로 탐색하고, 작업 결과를 동기적으로 혹은 비동기적으로 기록 보관소에 보고하는 방식이지만 네트워크 관리 비용이 큽니다.
|
||||
3. **실시간 메시징과 이벤트 예외 처리의 복잡성**
|
||||
- 태스크 위임 완료 후, 작업 결과와 성공/실패 여부를 교환하는 통신 채널이 중단되거나 유실될 수 있습니다.
|
||||
- **송신/수신 주체의 돌발 종료**: A 에이전트가 작업을 위임한 후 예상치 못하게 다운되었다가 재가동(Restart)된다면, B 에이전트가 작업을 완료한 뒤 발송한 비동기식 실시간 알람이 허공으로 날아가 결국 전체 협업 루프가 끊어집니다.
|
||||
- **무한 대기 및 리소스 누수(Deadlock & Resource Leak)**: 작업을 전달받은 subagent가 아무런 예외 통보(Timeout 또는 Error Event) 없이 갑자기 고사(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 기반 에이전트에게 피드백받음) 간에 상호 보완하도록 할 때 결과물의 신뢰성이 극적으로 향상됩니다. 이종 모델들이 세상을 바라보는 가중치와 강점이 다르기 때문에 보이지 않는 맹점(Blind spot)을 상호 보완해 줍니다.
|
||||
4. **비용 효율적인 토큰 분배 (Cost Optimization)**
|
||||
- 모든 에이전트가 값비싼 최상위 프론티어 LLM 모델만을 사용할 필요가 없습니다. 작업의 요구 난이도와 속도, 정확성을 저울질하여 쉬운 코드 생성이나 정보 검색은 경량화된 저비용 모델(예: Gemini Flash 세대)을 탑재한 에이전트에 분산 위임하고, 고난도의 논리적 추론이 필요한 부분에만 최상위 고비용 모델을 탑재한 에이전트를 적절히 매칭함으로써 종합적인 API 비용을 효율적으로 제어할 수 있습니다.
|
||||
|
||||
# What We Need?
|
||||
성공적인 Multi-Agent Orchestration 구현을 위해 갖추어야 할 기본 필수 구성요소들입니다:
|
||||
1. **Agent 간 작업 환경 공유 (A2A의 Agent Card 기반)**
|
||||
- 특정 에이전트에게 태스크를 안전하게 위임하고 위임받기 위해선, 각 에이전트 카드를 통해 서로의 역할, 엔드포인트, 입력 명세 스키마를 신뢰할 수 있는 방식으로 확인하고 동기화할 수 있어야 합니다.
|
||||
2. **에이전트 작동 인프라스트럭처 (Agent Working Infrastructure)**
|
||||
- 에이전트들이 통신에 사용할 서비스 주소와 포트를 동적으로 조회할 수 있는 서비스 디스커버리(Service Discovery) 기능 및 자동 라우팅 체계가 내재되어야 합니다.
|
||||
3. **일관성 있는 워크플로우 추적 및 공유 (Issue & Workflow Tracking)**
|
||||
- 서로 다른 에이전트가 동일한 작업을 재수행할 때 동일한 프로세스와 출력을 일관되게 얻을 수 있도록 워크플로우 사양이 제어되어야 합니다. 또한 에러나 중간 정지가 일어났을 때 복구 및 추적이 용이하도록 규격화된 이슈 추적 인터페이스(Issue Tracking Interface)를 마련해야 합니다.
|
||||
|
||||
|
||||
|
||||
4. **고성능 양방향 메시징 시스템 (Advanced Messaging System)**
|
||||
- 고용량의 코드 블록, 이미지 및 멀티모달 센서 데이터 등을 대량으로 빠르고 정확하게 공유하기 위해서는 기존의 MQTT나 단순 메시지 큐(MQ) 방식은 토픽 세분화와 페이로드 크기 한계로 인해 통신 병목을 겪을 수밖에 없습니다.
|
||||
- 단편적인 이벤트 알림만 전송하는 구조에서 탈피하여 상세 에러 트레이스, 상태 구조체, 이미지 바이너리 등을 한꺼번에 담을 수 있는 풍부한 페이로드 지원 메시징 규격이 필수적입니다. 나아가 대용량 멀티모달 푸시(Push)와 양방향 스트리밍을 지원하기 위해 HTTP/3의 멀티 스트리밍 등 고성능 통신이 수반되어야 합니다.
|
||||
5. **작업 및 태스크 관리 시스템 (Job & Task Lifecycle Controller)**
|
||||
- 하나의 부모 작업을 하위 스크럼(Scrum) 단위로 쪼개어 서브에이전트들에게 뿌려주는 라이프사이클 관리 기능이 있어야 합니다. 각 서브에이전트의 생성부터 소멸까지의 메시징 토픽과 임시 토큰을 정리해야 하며, 이 과정에서 부하를 고르게 배분하고 실력 있는 에이전트를 매칭하기 위한 로드 밸런싱(Load Balancing) 기법이 병행되어야 합니다.
|
||||
|
||||
## Why we need gRPC?
|
||||
이러한 해결 과제와 인프라 요구사항 속에서 **gRPC (Google Remote Procedure Call)** 프로토콜은 멀티 에이전트 인프라의 핵심 백본으로 기능합니다.
|
||||
1. **A2A 프로토콜과의 높은 호환성 및 스마트 팩토리/팜 최적화**
|
||||
- 개발 인터페이스 모듈은 스마트 팜, 스마트 팩토리와 같은 AIoT 서비스를 주요 타겟으로 개발되고 있습니다. 대역폭 및 성능 제약이 극심한 초경량 센서 디바이스 계층에서는 MQTT/CoAP 등을 보완적으로 혼용할 수 있으나, 상위의 데이터 수집 게이트웨이 및 엣지 연산 계층에서는 gRPC가 자율 통합 제어를 위한 강력하고 최적의 통신 프로토콜이 됩니다.
|
||||
2. **고성능 멀티 모달 바이너리 스트리밍 및 Pub/Sub 네이티브 지원**
|
||||
- AIoT나 지능형 에이전트 시스템은 텍스트뿐만 아니라 고해상도 이미지, 소리 주파수 등 대량의 멀티모달 데이터를 처리합니다. HTTP/2 또는 HTTP/3 기반으로 작동하는 gRPC는 양방향 스트리밍(Bidirectional Streaming)과 Request/Response, Pub/Sub 통신 스타일을 단일 포트에서 완벽히 소화하여, 복잡한 네트워크 요구사항을 단숨에 통합시킵니다.
|
||||
- 마이크로서비스 아키텍처(MSA)에서 메인 인터페이스로 gRPC가 통용되고 있으므로, 현업 시스템으로의 이식 및 확장 속도가 독보적으로 빠릅니다.
|
||||
3. **구조화된 직렬화 기반의 효율적 태스크 생명주기 및 부하 분산**
|
||||
- Protobuf(Protocol Buffers)를 통한 강력한 스키마 정의는 대량의 동적 서브에이전트들과 오케스트레이터 간에 쏟아지는 통신 메시지를 JSON 문자열 파싱 대비 수배 이상 빠르고 메모리 효율적으로 처리할 수 있게 합니다.
|
||||
- 이미 검증된 수많은 gRPC 기반 로드 밸런싱 및 이슈 트래킹 도구(예: Envoy, Kubernetes gRPC liveness probe 등)를 적극 도입함으로써, 에이전트 라이프사이클 감시 체계를 커스텀 빌드할 필요 없이 기성 인프라로 손쉽게 구축할 수 있습니다.
|
||||
+1031
File diff suppressed because it is too large
Load Diff
Reference in New Issue
Block a user