docs: add multi-agent orchestration slides, scripts, chapters, and assets
This commit is contained in:
@@ -0,0 +1,175 @@
|
||||
# MAM demo
|
||||
|
||||
https://git.godopu.com/tmpl/multi-agent-mux
|
||||
|
||||
- resume
|
||||
```bash
|
||||
/multi-agent-mux-resume
|
||||
```
|
||||
|
||||
- stop
|
||||
```bash
|
||||
/multi-agent-mux-resume
|
||||
```
|
||||
|
||||
- create
|
||||
```
|
||||
/multi-agent-mux-create --no-isolate --onboard 다음 새로운 에이전트를 생성해줘.
|
||||
```
|
||||
|
||||
- delegate-job
|
||||
```bash
|
||||
/multi-agent-mux-delegate-job agy creator에게 파이썬 초급자를 대상으로 정렬 학습을 위한 예시 코드 작성을 지시해줘.
|
||||
```
|
||||
|
||||
- loop
|
||||
```bash
|
||||
/multi-agent-mux-loop --plan --all-reviewer /goal 생성된 예시를 바탕으로 수업에 사용할 학습 자료를 만들어줘. 다음 조건을 충족하여야해.
|
||||
|
||||
- 파이썬 초급자가 보더라도 이해하기 쉽도록 실생활 예시를 통해 상세한 설명이 수록되어야 함
|
||||
- 모든 예시의 주요 코드에 대한 line 별 코드 설명이 있어야 함
|
||||
```
|
||||
|
||||
# herdr 사용법
|
||||
|
||||
실습: 세션 생성 → Claude 실행 → 소켓으로 프롬프트 전달 → 결과 확인
|
||||
|
||||
### 1. 현재 디렉터리를 cwd로 하는 새 세션 `new_session` 생성
|
||||
|
||||
```bash
|
||||
cd <현재 작업 디렉터리>
|
||||
herdr --session new_session
|
||||
```
|
||||
|
||||
Herdr의 세션은 launch-or-attach 모델이라 이 한 줄로 세션이 없으면 생성하고 동시에 attach까지 됩니다.
|
||||
|
||||
### 2. 생성된 세션에서 Claude 실행
|
||||
|
||||
attach된 pane 안에서:
|
||||
|
||||
```bash
|
||||
claude --dangerously-skip-permissions
|
||||
```
|
||||
|
||||
(테스트용으로 권한 프롬프트를 건너뛰려면 `claude --dangerously-skip-permissions`. 신뢰된 환경에서만 사용 권장.)
|
||||
|
||||
### 3. 다른 터미널에서 herdr 명령으로 프롬프트 전달 (직접 타이핑 아님)
|
||||
|
||||
새 터미널에서 에이전트 목록과 pane_id 확인:
|
||||
|
||||
```bash
|
||||
herdr --session new_session agent list
|
||||
herdr --session new_session agent get claude
|
||||
```
|
||||
|
||||
텍스트 입력 + Enter 제출을 원자적으로 수행:
|
||||
|
||||
```bash
|
||||
herdr --session new_session pane run <pane_id> "파이썬으로 정렬 프로그램을 작성해줘"
|
||||
```
|
||||
|
||||
### 4. Claude의 결과 화면 출력
|
||||
|
||||
완료될 때까지 기다렸다가 읽기:
|
||||
|
||||
```bash
|
||||
herdr --session new_session wait agent-status <pane_id> --status idle
|
||||
herdr --session new_session pane read <pane_id> --source recent --lines 150
|
||||
```
|
||||
|
||||
현재 화면만 바로 보기:
|
||||
|
||||
```bash
|
||||
herdr --session new_session pane read <pane_id> --source visible --lines 80
|
||||
```
|
||||
|
||||
`--session new_session`을 매번 붙이는 대신 `export HERDR_SESSION=new_session`으로 환경변수를 설정하면 이후 명령에서 생략 가능합니다.
|
||||
|
||||
# a2a 실습
|
||||
## 🗺️ 5단계 학습 로드맵 (Learning Roadmap)
|
||||
|
||||
### [Step 01] crewai를 통한 multi-agent 시작하기
|
||||
* **디렉토리**: [lib/crewai-example/](crewai-example/)
|
||||
* **학습 목표**: CrewAI 프레임워크와 로컬 Ollama 모델을 활용해 두 개 이상의 에이전트(기술 연구원, 작가)가 순차적으로 협업하여 분석 보고서를 도출하는 기초 워크플로우를 이해합니다.
|
||||
* **실행**:
|
||||
```bash
|
||||
./lib/crewai-example/run.sh
|
||||
```
|
||||
|
||||
- https://docs.crewai.com/v1.15.1/ko/tools/overview
|
||||
### [Step 02] a2a 기초 알아보기 (FastAPI 기반 직접 구현)
|
||||
* **디렉토리**: [lib/a2a-echo-example/](a2a-echo-example/)
|
||||
* **학습 목표**: SDK 도움 없이 원시 FastAPI를 사용해 JSON-RPC 2.0 프로토콜, 탐색 엔드포인트(`/.well-known/agent-card.json`), 메시지 수발신 규약을 직접 작성해보며 A2A 프로토콜의 밑바닥 동작 원리를 이해합니다.
|
||||
* **실행**:
|
||||
```bash
|
||||
# 터미널 1: 에코 에이전트 서버 구동
|
||||
./lib/a2a-echo-example/run.sh server
|
||||
# 터미널 2: 테스트 메시지 클라이언트 실행
|
||||
./lib/a2a-echo-example/run.sh client
|
||||
```
|
||||
|
||||
### [Step 03] a2a sdk 알아보기 (공식 SDK 전환)
|
||||
* **디렉토리**: [lib/a2a_sdk/](a2a_sdk/)
|
||||
* **학습 목표**: 정식 `a2a-sdk`를 적용하여 `AgentExecutor` 기반으로 비즈니스 에코 로직을 구현합니다. 복잡한 소통 인프라(FastAPI 라우트 마운트, 에러 처리, 큐 통신 등)가 SDK에 의해 얼마나 깔끔하게 자동화되는지 비교 체험합니다.
|
||||
* **실행**:
|
||||
```bash
|
||||
# 터미널 1: SDK 기반 에코 서버 구동
|
||||
./lib/a2a_sdk/run.sh server
|
||||
# 터미널 2: SDK 규격 호환 클라이언트 실행
|
||||
./lib/a2a_sdk/run.sh client
|
||||
```
|
||||
|
||||
### [Step 04] a2a를 이용하여 multi agent 구현해보기
|
||||
* **디렉토리**: [lib/a2a-ollama-example/](a2a-ollama-example/)
|
||||
* **학습 목표**: 앞선 SDK 뼈대에 실제 로컬 생성형 AI 모델인 `gemma4:31b-cloud`를 이식하여, 들어오는 질문에 지능적으로 답하는 실질적인 AI 비서 에이전트를 조립합니다.
|
||||
* **실행**:
|
||||
```bash
|
||||
# 터미널 1: Ollama 연동 AI 에이전트 서버 구동
|
||||
./lib/a2a-ollama-example/run.sh server
|
||||
# 터미널 2: 질문 전송 테스트
|
||||
./lib/a2a-ollama-example/run.sh client "프랑스의 수도는 어디야?"
|
||||
```
|
||||
|
||||
### [Step 05] 작업 할당은 어떻게 이루어질까? (오케스트레이션)
|
||||
* **디렉토리**: [lib/advanced-a2a-ollama-example/](advanced-a2a-ollama-example/)
|
||||
* **학습 목표**: 사용자의 복잡한 질의를 받으면 LLM을 통해 어떤 에이전트가 적합한지 동적으로 판별(분류)하고, 대상 전문 에이전트(Chat Agent 또는 Coder Agent)를 호출하여 답변을 취합하는 고급 오케스트레이션 설계 패턴을 습득합니다.
|
||||
* **실행**:
|
||||
```bash
|
||||
# 터미널 1: 두 독립 에이전트(Chat:8001, Coder:8002) 서버 동시 구동
|
||||
./lib/advanced-a2a-ollama-example/run.sh server
|
||||
|
||||
# (선택) 개별 터미널에서 서버를 분리 구동하고 싶을 때
|
||||
# 터미널 1A: Chat 에이전트만 구동 (Port 8001)
|
||||
./lib/advanced-a2a-ollama-example/run.sh server chat
|
||||
# 터미널 1B: Coder 에이전트만 구동 (Port 8002)
|
||||
./lib/advanced-a2a-ollama-example/run.sh server coding
|
||||
|
||||
# 터미널 2: 오케스트레이터 작동 및 분류 인터랙션 실행
|
||||
./lib/advanced-a2a-ollama-example/run.sh client "프랑스의 수도는 어디야?"
|
||||
```
|
||||
|
||||
### [Step 06] 동적 라우팅과 서비스 탐색 (Dynamic Binding)
|
||||
* **디렉토리**: [lib/advanced-dynamic-a2a-ollama-example/](advanced-dynamic-a2a-ollama-example/)
|
||||
* **학습 목표**: 하드코딩 라우팅의 한계를 이해하고, 런타임에 분산된 에이전트들의 명세 카드(`agent-card.json`)를 동적으로 검색(Discovery)해 스킬 목록을 추출하고, 최적 매칭 노드에 실시간으로 메시지를 라우팅 및 바인딩하는 기법을 실증합니다.
|
||||
|
||||
* **터미널 A (Chat 에이전트 - Port 9501)**:
|
||||
```bash
|
||||
OLLAMA_MODEL="gemma4:31b-cloud" ./lib/advanced-dynamic-a2a-ollama-example/run.sh server chat
|
||||
```
|
||||
|
||||
* **터미널 B (Coder 에이전트 - Port 9502)**:
|
||||
```bash
|
||||
OLLAMA_MODEL="gemma4:31b-cloud" ./lib/advanced-dynamic-a2a-ollama-example/run.sh server coding
|
||||
```
|
||||
|
||||
* **터미널 C (Translator 에이전트 - Port 9503)**:
|
||||
```bash
|
||||
OLLAMA_MODEL="gemma4:31b-cloud" ./lib/advanced-dynamic-a2a-ollama-example/run.sh server translate
|
||||
```
|
||||
|
||||
* **클라이언트 질의 터미널 (오케스트레이터 클라이언트로 번역 질문)**:
|
||||
```bash
|
||||
# 오케스트레이터가 번역에 맞는 스킬을 찾아 Translator(9503 포트)로 매칭하는 것을 확인
|
||||
OLLAMA_MODEL="gemma4:31b-cloud" ./lib/advanced-dynamic-a2a-ollama-example/run.sh client "안녕하세요를 영어로 번역해줘."
|
||||
```
|
||||
|
||||
@@ -0,0 +1,409 @@
|
||||
---
|
||||
title: AI Multi-Agents 오케스트레이션 기술 동향 및 사례
|
||||
description: AI 에이전트의 핵심 기법부터 MCP/SKILL 확장, TMUX/crewAI/LangGraph 오케스트레이션 인프라, ACP/A2A 상호운용성 표준, AIoT/gRPC 동향까지 다루는 특강 발표자료용 문서입니다.
|
||||
marp: true
|
||||
---
|
||||
<!-- NOTE: 이 문서의 동기화 사본이 paper_draft/SLIDE.md에 존재합니다. 이미지 상대경로는 루트 기준이므로 렌더링은 루트 SLIDE.md로 수행하세요. -->
|
||||
|
||||
# AI Multi-Agents 오케스트레이션 기술 동향 및 사례
|
||||
### 정적 AI 모델에서 자율적 AI 에이전트로의 패러다임 전환
|
||||
|
||||
---
|
||||
|
||||
## 🔍 이 발표에서 다루고 싶은 핵심 화두
|
||||
|
||||
최근 AI 분야에서 가장 뜨거운 화두는, 단순히 사용자의 질문에 답을 하는 **정적 AI 모델(LLM)**을 넘어 스스로 목적을 가지고 움직이는 **자율형 AI 에이전트(AI Agent)**로의 패러다임 전환입니다.
|
||||
|
||||
우리가 흔히 쓰는 AI 모델이 똑똑하게 생각하고 답변을 생성하는 '지능 엔진'이라면, AI 에이전트는 그 지능에 자율성과 행동력, 그리고 다른 에이전트와의 협업 능력까지 결합한 실제 '행동의 주체'라고 볼 수 있습니다.
|
||||
|
||||
오늘 발표에서는 단순한 AI 모델을 자율적인 에이전트로 업그레이드하는 구체적인 엔지니어링 방법론부터 시작하여, 여러 에이전트들이 유기적으로 협업하는 오케스트레이션 인프라와 산업 표준 기술 동향을 아주 쉽게 풀어보려 합니다.
|
||||
|
||||
---
|
||||
|
||||
### 💡 구체적 사례 비교: "멀티 에이전트 관련 연구를 조사해줘"
|
||||
|
||||
사용자가 **"멀티 에이전트 관련 최신 연구 동향을 조사하고 보고서로 저장해줘"**라는 명령을 내렸을 때, 두 시스템은 완전히 다르게 움직입니다.
|
||||
|
||||
먼저 **AI 모델(LLM)**은 머릿속(학습된 데이터)에 있는 지식만을 꺼내서 기존 연구 목록을 말로 친절하게 설명해 줍니다. 겉보기에는 똑똑해 보이지만, 실시간으로 최신 논문을 인터넷에서 검색해 오거나 보고서 파일을 디스크에 직접 저장하는 '행동'은 수행하지 못합니다.
|
||||
|
||||
반면 **AI 에이전트(Agent)**는 명령을 받자마자 실제 행동을 개시합니다. 학술 API에 접속해 최신 논문을 검색해 오고, PDF 파일을 직접 다운로드해서 그 내용을 파싱한 다음, 최종 결과물을 마크다운 형태의 파일로 사용자의 컴퓨터 폴더에 실제로 만들고 저장해 줍니다.
|
||||
|
||||
---
|
||||
|
||||
### 📊 역할과 작동 방식의 결정적 차이
|
||||
|
||||
이 두 개념의 차이는 다음과 같이 쉽게 풀어볼 수 있습니다.
|
||||
|
||||
- **생각(Thinking)과 행동(Doing)의 차이**
|
||||
AI 모델은 질문을 던지면 이에 부합하는 지식이나 코드를 화면에 '답변'해 주는 똑똑한 뇌 역할을 합니다. 반면 AI 에이전트는 최종 목적지에 도달하기 위해 스스로 세부 계획을 세우고 실제 컴퓨터 환경에서 발로 뛰는 손과 발 역할을 함께 수행합니다.
|
||||
- **조언(Advise)과 실행(Execution)의 차이**
|
||||
모델은 "이 스크립트를 이렇게 실행해서 저장하세요"라고 텍스트로 가이드라인만 알려줍니다. 하지만 에이전트는 운영체제나 파일 시스템에 직접 들어가서 스크립트를 실제로 실행하고 그 결과물을 직접 파일로 구체화합니다.
|
||||
- **오류를 마주했을 때의 대처 능력**
|
||||
모델은 실행 중 오류가 났을 때 사람이 에러 로그를 다시 복사해서 붙여넣어 주기 전까지는 대기할 수밖에 없습니다. 반면 에이전트는 오류가 나면 스스로 로그를 해석하고, 성찰(Reflection) 과정을 거쳐 계획을 수정해 다시 시도합니다.
|
||||
|
||||
---
|
||||
|
||||
### 🚗 아주 쉬운 비유: "운전자"와 "자율주행 차량"
|
||||
|
||||
그렇다면 에이전트는 모델이 시키는 대로만 움직이는 수동적인 존재일까요? 결코 그렇지 않습니다.
|
||||
|
||||
- **AI 모델(LLM)은 '운전자(뇌)' 입니다.**
|
||||
"여기서 우회전하고 다음에서 멈추자"라는 인지적 판단과 주행 경로(추론)를 수립합니다.
|
||||
- **AI 에이전트(Agent)는 '자율주행 차량 시스템 전체' 입니다.**
|
||||
운전자의 판단을 가속 페달과 바퀴 회전(도구 실행)으로 바꾸며, 다음과 같은 독자적인 **시스템 수준의 판단**을 수행합니다:
|
||||
- **안전 가드레일**: 운전자가 실수로 시스템을 파괴하는 명령과 같이 위험한 길로 가려 할 때 비상 제동을 걸어 이를 원천 차단합니다.
|
||||
- **예외 복구 및 통제**: 네트워크 연결이 끊기거나 무한 루프에 빠지는 상황이 발생하면 스스로 판단하여 실행을 중단하고 우회 경로를 수립합니다.
|
||||
- **합의 형성(Consensus)**: 멀티 에이전트 환경에서 각 에이전트들의 교차 검증 결과를 수집하여 통과나 반려 여부를 결정하고 최종 집행을 판정합니다.
|
||||
|
||||
---
|
||||
|
||||
## 🛠️ AI 에이전트가 갖춰야 할 4대 필수 기능
|
||||
|
||||
단순히 대화만 나누는 챗봇이 아니라, 진짜 제 역할을 하는 **자율형 AI 에이전트**가 되기 위해 소프트웨어 시스템 차원에서 반드시 제공해야 하는 4가지 핵심 기능입니다.
|
||||
|
||||
1. **계획 및 추론 능력 (Planning)**
|
||||
2. **기억 및 상태 관리 능력 (Memory)**
|
||||
3. **도구 활용 및 실행 능력 (Tool Use & Action)**
|
||||
4. **상호 통신 및 협업 능력 (Collaboration)**
|
||||
|
||||
---
|
||||
|
||||
### 1. 계획 및 추론 능력 (Planning)
|
||||
|
||||
사용자가 최종 목표만 주면 스스로 실행 가능한 단계별 세부 태스크를 설계하고, 진행 과정에서 문제가 생기면 계획을 유연하게 수정하는 능력입니다.
|
||||
|
||||
- **Task Decomposition (작업 분해)**: 복잡한 목표를 실행 가능한 작은 단위의 세부 태스크로 분할 (예: Chain of Thought, Tree of Thoughts 등)
|
||||
- **Self-Reflection (자기 성찰 및 피드백)**: 행동 결과를 스스로 분석하고 실수를 교정하여 향후 계획을 실시간으로 수정 (예: ReAct, Reflexion 프레임워크)
|
||||
|
||||
* **실제 예시**:
|
||||
에이전트에게 "블로그 기사 작성"을 요청하면, 스스로 **'키워드 조사 ➡️ 개요 작성 ➡️ 본문 집필 ➡️ 오탈자 검사'** 순으로 계획을 세웁니다. 만약 맞춤법 검사 도중 치명적인 논리 오류를 발견하면, 본문 작성 단계로 스스로 되돌아가 계획을 수정하고 다시 쓰는 자가 성찰(Self-Reflection)을 거칩니다.
|
||||
|
||||
---
|
||||
|
||||
### 2. 기억 및 상태 관리 능력 (Memory)
|
||||
|
||||
현재 나누는 대화의 즉각적인 흐름(단기 기억)뿐만 아니라, 과거의 경험과 누적된 지식(장기 기억)을 필요할 때마다 영속적으로 꺼내어 쓰는 능력입니다.
|
||||
|
||||
- **Short-term Memory (단기 기억)**: 현재 대화나 컨텍스트 윈도우 내에서 실시간으로 유지되는 즉각적인 맥락 정보
|
||||
- **Long-term Memory (장기 기억)**: 외부 데이터베이스나 벡터 DB를 활용하여 과거 대화 기록 및 지식을 RAG 기법으로 바인딩하는 정보 보존 공간
|
||||
|
||||
* **실제 예시**:
|
||||
에이전트에게 "어제 작업하던 파이썬 소스코드의 오류를 이어서 수정해줘"라고 요청하는 경우입니다. 에이전트는 데이터베이스에 누적된 과거 대화 히스토리와, 벡터 DB에 저장되어 있는 소스코드의 예전 상태 정보를 동적으로 인출(Retrieval)해 와 대화 맥락을 끊김 없이 이어갑니다.
|
||||
|
||||
---
|
||||
|
||||
### 3. 도구 활용 및 실행 능력 (Tool Use & Action)
|
||||
|
||||
인터넷 검색, 외부 API 호출, 파일 시스템 접근, 코드 실행 등 컴퓨터 세상의 다양한 소프트웨어를 직접 연결하고 작동시키는 손과 발 역할을 의미합니다.
|
||||
|
||||
* **실제 예시**:
|
||||
복잡한 나눗셈 연산을 해야 할 때 직접 계산기 도구를 호출해 오차 없이 연산하고, 최신 주식 시세를 알기 위해 증권사 API를 호출하며, 작성한 코드가 잘 돌아가는지 검증하기 위해 격리된 샌드박스 컴퓨터 환경(Docker)을 구동해 스크립트를 직접 실행합니다.
|
||||
|
||||
---
|
||||
|
||||
### 4. 상호 통신 및 협업 능력 (Collaboration)
|
||||
|
||||
혼자서 모든 일을 처리하는 것이 아니라, 다른 역할을 가진 전문 에이전트나 사용자 시스템과 표준 규격으로 메시지를 주고받으며 큰 작업을 분산 처리하는 능력입니다.
|
||||
|
||||
* **실제 예시**:
|
||||
"이 프로젝트의 보안 취약점 보고서를 작성해줘"라는 명령을 내렸을 때의 상황입니다. 보안 에이전트가 소스코드를 스캔해 취약점을 나열하면, 인프라 에이전트가 가상 머신 설정을 검토하고, 최종적으로 리뷰어 에이전트들이 보고서의 신뢰성을 상호 검증하여 하나의 완성된 산출물을 합작해 냅니다.
|
||||
|
||||
---
|
||||
|
||||
## 🚀 패러다임 전환: Model eats the Scaffolding (모델이 외부 시스템을 흡수하다)
|
||||
|
||||
현재 에이전트 기술에서 가장 중요한 변화 중 하나는, 과거에 에이전트 제어 시스템(Scaffolding, 에이전트의 구동을 돕는 외부 뼈대 구조)이 수동으로 제어하던 기능들이 점점 AI 모델 내부로 흡수되고 있는 현상입니다.
|
||||
|
||||
- https://arca.live/b/characterai/174977057?category=%EB%89%B4%EC%8A%A42&p=1
|
||||
|
||||
- **스스로 생각하는 모델의 등장 (Test-time Compute, 추론 시점 추가 연산)**
|
||||
최근 출시된 Gemini Thinking이나 OpenAI o1/o3 같은 모델들은 외부 시스템이 루프를 돌려주지 않아도, 모델 스스로 출력을 내보내기 전에 내부적으로 계획을 세우고(Planning) 스스로 오류를 성찰(Reflection)하는 과정을 완료합니다.
|
||||
- **인지와 집행의 명확한 역할 분담**
|
||||
이에 따라 고차원적인 논리 설계와 계획(Planning)은 **AI 모델** 내부로 빠르게 넘어가고 있습니다. 반면 외부의 **에이전트 인프라(Harness, 에이전트 실행 및 도구 제어 장치)**는 안전한 실행 환경(Sandboxing, 격리 환경 실행), 권한 통제, 상태 관리처럼 모델이 직접 수행하기 어려운 물리적 보호막 역할을 담당하는 방향으로 진화하고 있습니다.
|
||||
- **차별화 요소(Alpha)의 이동**
|
||||
단순히 계획을 짜는 흐름을 코드로 구현하는 것의 가치는 점차 줄어들고 있습니다. 이제는 복잡한 인프라를 실시간으로 제어하고, 서로 다른 규격을 가진 다양한 에이전트들을 표준 프로토콜로 유기적으로 엮어내는 기술이 핵심 경쟁력으로 부상하고 있습니다.
|
||||
|
||||
---
|
||||
|
||||
# 1. AI 에이전트 구현을 위한 3대 핵심 엔지니어링 기법
|
||||
|
||||
성공적인 AI 에이전트 시스템을 구현하기 위해서는 단순히 모델에게 프롬프트를 입력하는 것을 넘어, **모델 제어**, **정보 연동**, **물리적 환경 연결**을 유기적으로 엮어내는 3가지 핵심 엔지니어링 기법이 필요합니다.
|
||||
|
||||
1. **프롬프트 엔지니어링 (Prompt Engineering)**: 에이전트의 페르소나와 사고 방식(추론 가이드라인)을 규정하는 작업입니다.
|
||||
2. **컨텍스트 엔지니어링 (Context Engineering)**: 대화 흐름을 끊김 없이 보존하고 관련 데이터를 적시에 제공하는 정보 정리 작업입니다.
|
||||
3. **하네스 엔지니어링 (Harness Engineering)**: 격리된 환경에서 다양한 소프트웨어 도구를 안전하게 조작할 수 있는 물리적 손발을 달아주는 작업입니다.
|
||||
|
||||
---
|
||||
|
||||
### 1️⃣ 프롬프트 엔지니어링 (Prompt Engineering)
|
||||
|
||||
모델의 발전과 자체 추론 기능의 향상으로 예전만큼 미시적인 프롬프트 트릭에 집착할 필요는 줄어들고 있습니다. 하지만 프롬프트는 여전히 **AI 에이전트 활용의 시작점이자 뼈대**입니다. 구체적이고 명확한 작동 지침을 만들기 위해 프롬프트 작성 시 반드시 반영해야 할 3대 핵심 고려사항입니다.
|
||||
|
||||
- **역할 및 페르소나 지시 (Role)**
|
||||
에이전트에게 전문 도메인 지식과 행동 경계를 지정해 줍니다. (예: *"너는 주니어 개발자를 코칭하는 꼼꼼한 테크리더 에이전트다. 직접 고치지 말고 가이드라인만 제공해라."*)
|
||||
- **구체적인 작업 예시 제공 (Few-shot)**
|
||||
원하는 출력 형식이나 중간 추론 과정의 모범 예시를 제공하여, 에이전트의 답변 일관성과 가독성을 극대화합니다.
|
||||
- **자가 검증 방법 제시 (Verification)**
|
||||
에이전트 스스로 작업의 무결성을 점검하게 하거나, 외부 시스템이 실행 결과를 확인 및 통제할 수 있도록 정형화된 출력 규격(예: 최종 통과 시 `[VERDICT: PASS]` 명시 요구)을 정의해 줍니다.
|
||||
|
||||
---
|
||||
|
||||
### 💡 실제 프롬프트 구조 예시 (ReAct 사고 방식)
|
||||
|
||||
에이전트가 단번에 대답하지 않고 단계별로 계획을 세워 도구를 사용하도록 프롬프트 구조를 강제하는 기법입니다.
|
||||
|
||||
```text
|
||||
[System Prompt]
|
||||
너는 복잡한 수식을 계산하는 수학 에이전트다. 다음 형식으로 사고해라:
|
||||
- Thought: 문제 해결을 위한 다음 행동 계획을 작성해라.
|
||||
- Action: 호출할 도구 이름과 인자값을 JSON으로 적어라. (예: Calculator)
|
||||
- Observation: 도구 실행 결과가 여기에 채워질 것이다.
|
||||
- Thought: 실행 결과를 바탕으로 성찰하고, 필요하면 다음 Action을 설계해라.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 2️⃣ 컨텍스트 엔지니어링 (Context Engineering)
|
||||
|
||||
에이전트가 다루는 대화 맥락과 작업 상태(State)를 효율적으로 정제하고, 수많은 외부 정보 중 **지금 꼭 필요한 관련 데이터(RAG)**만을 선별하여 제한된 AI의 기억 공간(컨텍스트 윈도우)에 밀도 높게 채워 넣는 기술입니다.
|
||||
|
||||
* **핵심 설계 요소**:
|
||||
- **대화 상태 보존**: 이전 턴의 작업 결과를 유실 없이 보존
|
||||
- **동적 바인딩**: 외부 RAG 검색기에서 관련도 높은 중요 데이터만 적시에 필터링하여 공급
|
||||
- **메모리 압축**: 불필요한 과거 로그는 요약하고, 핵심 현재 상태 구조체만 유지해 토큰 낭비 방지
|
||||
* **에이전트 상태 보존 예시 (State JSON)**:
|
||||
```json
|
||||
{
|
||||
"task_id": "job_10294",
|
||||
"current_working_directory": "/workspace/src",
|
||||
"error_logs": ["SyntaxError: unexpected EOF while parsing at line 14"],
|
||||
"completed_subtasks": ["1. 소스코드 로드 완료", "2. 오류 라인 식별"],
|
||||
"next_action_required": "오류 라인 14의 괄호 닫힘 확인 및 수정 스크립트 작성"
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 3️⃣ 하네스 엔지니어링 (Harness Engineering)
|
||||
|
||||
에이전트가 파일 시스템 제어, 브라우저 조작, 외부 API 호출 등 컴퓨터 세상의 다양한 도구들을 안전하게 가동할 수 있도록 **물리적 인터페이스(연결 고리)**를 구성하는 기술입니다.
|
||||
|
||||
* **핵심 설계 요소**:
|
||||
- **도구 호출 가로채기(Intercepting)**: 모델이 내놓은 도구 호출 의도(JSON 등)를 감지하고, 실제 터미널이나 프로그램의 함수로 전달해 구동함
|
||||
- **보안 샌드박싱 (Sandboxing)**: 에이전트가 악성 코드나 파괴적인 명령어를 무단 실행하지 않도록 격리된 가상 환경을 구축하고 권한을 통제함
|
||||
* **물리 인터페이스 도구 결합 예시**:
|
||||
```
|
||||
[LLM의 출력] ──> "Action: execute_command, args: { cmd: 'ls -la' }"
|
||||
│ (하네스가 이를 가로챔)
|
||||
▼
|
||||
[하네스 제어기] ──> 격리된 Docker 샌드박스 내부에서 'ls -la' 실제 실행
|
||||
│ (실행 결과 가로챔)
|
||||
▼
|
||||
[LLM의 입력] <── "Observation: total 12\ndrwxr-xr-x 3 user..." (모델에 반환)
|
||||
```
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
# 2. AI Agent 기능 확장: MCP & SKILL
|
||||
|
||||
## MCP (Model Context Protocol)
|
||||
Model Context Protocol(MCP)은 Anthropic이 2024년 11월 발표한 오픈 소스 프로토콜로, AI 애플리케이션(Host) 내부의 클라이언트(Client)가 로컬/원격의 도구(Tools), 데이터 소스(Resources), 그리고 컨텍스트 템플릿(Prompts)을 통일된 규격으로 안전하게 호출할 수 있는 공통 인터페이스입니다.
|
||||
- **Host-Client-Server 구조**: 에이전트 플랫폼(Host) 내 클라이언트가 표준화된 MCP 프로토콜을 통해 외부의 다양한 MCP 서버들과 통신하여 기능을 동적으로 확장하는 형태
|
||||
- **3대 제공 요소**:
|
||||
- **Tools**: 에이전트가 실행할 수 있는 실행형 기능(계산기, 파일 제어, API 호출 등)을 명세하고 호출 처리
|
||||
- **Resources**: 에이전트가 읽을 수 있는 데이터 소스, 파일, 컨텍스트 상태 정보를 노출
|
||||
- **Prompts**: 자주 사용되는 프롬프트 템플릿과 실행 지침을 표준 규격으로 제공
|
||||
|
||||
## CLI 코딩 에이전트: Claude Code vs Cowork
|
||||
AI 에이전트의 대표 주자인 Claude는 Claude Desktop App에서 Claude Cowork와 Claude Code라는 두 가지 상이한 서비스를 제공합니다.
|
||||
- **작동 방식의 차이**: Claude Cowork는 일상적인 사무 비서 역할로 Cloud 상에서 필요한 파일(pdf, word, excel 등)을 읽고 쓰는 방식을 사용하며, Claude Code는 Coding 작업에 특화되어 Local Computer에 필요한 모듈과 소프트웨어를 설치하여 직접 파일 수정 및 실행을 수행
|
||||
- **환경적 이점**: Claude Code는 터미널에서 로컬 컴퓨터의 필요한 모듈/소프트웨어를 바탕으로 작업 디렉터리 내 파일을 직접 제어하여 개발 업무에 고도화된 성능 발휘
|
||||
|
||||
|
||||
|
||||
- **생산성 극대화**: Claude Code를 프로젝트에 알맞게 조련하여 사용할 경우 단순 Cloud 비서 환경 대비 월등히 높은 결과물 기대 가능
|
||||
|
||||
## SKILL이란
|
||||
Skills(기술/도구 패키지)는 AI 에이전트가 외부 환경과 동적으로 상호작용할 수 있도록 결합하는 기능적 실행 모듈입니다. 단순히 LLM에게 단순 프롬프트 지시를 하는 프롬프트 엔지니어링 수준을 넘어, 에이전트가 특정 목표를 위해 직접 실행할 수 있는 실행 코드, 도구의 명세 스키마(Tool Schema), 사용 설명 및 예시(Few-shot) 등이 하나로 패키징된 자율 확장 도구 모음입니다.
|
||||
- **동적 모듈화 및 모듈화 방식**: 상황에 따라 필요한 기술을 동적으로 로드해 사용하고, 완료 후 반환하는 독립 모듈화 형태 채택
|
||||
- **작업 수행 한계 돌파**: 텍스트 생성이라는 언어 모델의 한계를 넘어 파일 제어, 서버 배포, 물리 데이터 수집 등 실질적인 업무 대행 능력을 에이전트에 부여
|
||||
|
||||
## 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
|
||||
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
# 3. 멀티 에이전트 협업 체계 및 오케스트레이션 인프라
|
||||
|
||||
## 싱글 에이전트의 한계
|
||||
단일 에이전트는 대규모 컨텍스트를 처리할 때 정보 누락(Lost in the middle) 현상이 발생하기 쉽고, 여러 도구를 한꺼번에 다루어야 할 때 환각(Hallucination)율이 증가하는 문제가 있습니다. 또한 역할 집중으로 인한 프롬프트의 장황화, 멀티태스킹 오류 및 컨텍스트 인지 한계 등의 명확한 한계를 가집니다.
|
||||
|
||||
## 멀티 에이전트란: 역할 세분화와 교차 검증
|
||||
멀티 에이전트(Multi-Agent) 시스템은 단일 에이전트(Single Agent)의 한계를 극복하기 위해, 서로 다른 페르소나와 전문 도구(Skills)를 갖춘 여러 개의 에이전트들이 협력 네트워크를 형성하여 복잡한 목표를 조율(Orchestration)하고 분할 해결하는 구조입니다.
|
||||
- **역할 세분화 (Role Specialization)**: 에이전트별로 한정된 역할(PM, Developer, QA, Researcher 등)과 도구만을 부여하여 프롬프트 노이즈를 억제하고 추론 정확도 향상
|
||||
- **교차 검증**: 서로 다른 이종 모델(Gemini 작성 ➡️ Claude 검토 등) 간의 상호 비평 및 검증 루프를 통해 결과물의 정합성을 교차 검증하고 결과 신뢰성 극대화
|
||||
- **분할 정복 (Divide and Conquer)**: 하나의 거대한 프로젝트를 독립된 세부 태스크로 쪼개어 다수의 에이전트가 병렬적으로 해결함으로써 복잡성 분산
|
||||
|
||||
## Subagent / Team agent
|
||||
|
||||
- ### Subagent란
|
||||
Subagent는 부모 에이전트(Parent Agent 또는 Orchestrator)에 의해 동적으로 생성되어 특정 국소적이고 독립적인 태스크를 대행한 뒤, 결과를 상위로 반환하고 소멸하는 종속형 에이전트입니다.
|
||||
- **컨텍스트 격리**: 하위 작업의 맥락만을 분기(Branch)하여 처리함으로써 상위 대화의 컨텍스트 오염을 막고 토큰 소모량 최적화 및 속도 개선
|
||||
- **예시**: 메인 에이전트가 리팩토링 중 특정 모듈 에러 복구 작업만을 subagent에 위임하여 처리하는 독립적인 문제 해결 기법
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
- ### Team agent란
|
||||
Team agent는 단일 계층적인 수직 구조를 넘어, 수평적이고 다양한 역할을 맡은 여러 독립 에이전트가 협의체(Crew/Team)를 구성하여 대화형 협력(Multi-agent Debate) 및 협상을 통해 목표를 완수하는 협동형 에이전트 구성 방식입니다.
|
||||
- **의견 충돌 및 합의**: 특정 설계안에 대해 서로 다른 관점의 에이전트들이 논쟁(Debate)을 벌이고, 최종적으로 조율된 결과를 PM 에이전트가 도출하는 식의 협력 모델
|
||||
- **협력적 의사결정**: 복잡한 문제에 대해 실시간으로 의견과 피드백을 교환하여 점진적으로 결과물의 품질 고도화
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## 구성 기술: TMUX · crewAI · LangGraph
|
||||
|
||||
- ### TMUX
|
||||
TMUX는 에이전트들의 독립적인 작업 공간을 제공하는 가상 터미널 관리 도구로, 백그라운드 내 장기 작업(Long-running task) 세션을 안정적으로 유지하고 AI 에이전트의 동작을 TUI로 실시간 모니터링 및 제어할 수 있도록 도와주는 소프트웨어입니다.
|
||||
- **에이전트별 독립 작업 공간 제공**: 각 에이전트 세션을 독립적인 tmux 윈도우나 패널에 격리하여 병렬로 실행할 수 있는 물리적 격리막 형성
|
||||
- **장기 실행 작업의 백그라운드 세션 유지**: SSH 연결이 끊어지거나 브라우저 세션이 끊겨도 tmux 세션 내부에서 구동되는 에이전트 작업은 유실 없이 백그라운드에서 계속 유지
|
||||
- **TUI 실시간 모니터링 및 제어**: CLI 코딩 에이전트나 멀티 에이전트들의 실행 과정을 사람이 TUI를 통해 실시간으로 관측(observe)하고 필요시 입력을 제공할 수 있도록 실시간 관측 및 제어 지원
|
||||
- *실제로 앞서 소개한 `multi-agent-mux` 스킬 데모가 이러한 TMUX 세션 관리 기능을 활용하여 설계된 멀티 에이전트 오케스트레이션 사례임*
|
||||
|
||||
- ### crewAI
|
||||
역할 기반(Role-based) 협업을 설계하는 데 특화된 프레임워크입니다. 각 에이전트에게 명확한 역할(Role), 목표(Goal), 배경 설명(Backstory)을 부여하고, 이들을 업무 프로세스(Sequential 또는 Hierarchical)에 따라 배치해 '크루(Crew)' 단위로 조율합니다.
|
||||
|
||||
- ### LangGraph
|
||||
컨텍스트 엔지니어링(Context Engineering)은 다중 에이전트 시스템에서 에이전트들 간의 대화 흐름, 전달되는 컨텍스트(State), 복잡한 제어 루프를 효율적으로 설계하고 유지하는 방법론적 학문입니다. 이를 구현하는 대표적인 상태 보존형 프레임워크가 LangGraph입니다.
|
||||
- **상태 보존 및 순환 제어**: 단순 선형적 체인 구조를 탈피하여, 에이전트 간의 루프(반복 검증), 조건부 분기(Conditional branching), 실패 시 롤백 등을 순환형 그래프(Cyclic Graph) 구조로 제어
|
||||
- **영속적 상태 관리**: 협업 과정에서 축적되는 다양한 상태 변화(State)를 중앙 저장소에서 추적 및 동기화하여 특정 노드가 실패하더라도 이전 상태부터 복구 및 재시작할 수 있는 환경 제공
|
||||
|
||||
- ### (참고) AutoGen, BeeAI
|
||||
Microsoft AutoGen과 IBM의 BeeAI도 멀티 에이전트 오케스트레이션을 지원하는 주요 프레임워크입니다.
|
||||
- **Microsoft AutoGen**: 대화형 에이전트 설계(Conversational Agentic Design)에 중점을 둔 프레임워크로, 에이전트 간 대화를 통해 코드를 실행하고 피드백을 주고받는 풍부한 동적 워크플로우 제공
|
||||
- **BeeAI**: 에이전트를 탐색, 실행, 공유할 수 있는 중앙 집중형 오픈소스 플랫폼으로 리눅스 재단(LF) 하위에서 ACP 표준 프로토콜을 백본으로 구축
|
||||
|
||||
|
||||
|
||||
## [사례] 실제 구현하며 겪은 문제점들
|
||||
|
||||
1. **Agent들과 각 Agent들의 세션 관리**
|
||||
- 다수의 에이전트와 그 아래에 동적으로 생성되는 subagent들의 생명주기(Lifecycle) 및 고유 식별자(UUID)를 동기화하고 상태를 지속적으로 보존하는 일관된 세션 관리 시스템 요구
|
||||
2. **에이전트 상호 탐색(Service Discovery)과 역할 식별**
|
||||
- 새로운 에이전트가 네트워크에 진입했을 때 어떤 에이전트가 어떤 과업을 처리할 수 있는지 동적으로 파악하는 기능 요구
|
||||
- **마스터 - 슬레이브(Master-Slave) 방식**: 중앙 오케스트레이터가 전권을 쥐고 세션을 직접 관리 및 명령하므로 통제는 쉬우나, 오케스트레이터의 에러가 시스템 전체의 단일 실패점(SPOF)이 될 위험 존재
|
||||
- **P2P 및 보고(P2P and Report) 방식**: 에이전트들이 동등한 위치에서 협상하며 자율적으로 탐색하고, 작업 결과를 기록 보관소에 보고하는 방식이나 네트워크 관리 비용 상승 우려
|
||||
3. **실시간 메시징과 이벤트 예외 처리의 복잡성**
|
||||
- 태스크 위임 완료 후, 작업 결과와 성공/실패 여부를 교환하는 통신 채널이 중단되거나 유실될 수 있는 위험성 대두
|
||||
- **송신/수신 주체의 돌발 종료**: 위임 후 송신 주체가 다운되었다가 재가동(Restart)되는 경우, 비동기 알람이 공중분해되어 전체 협업 루프 중단
|
||||
- **무한 대기 및 리소스 누수(Deadlock & Resource Leak)**: 작업을 위임받은 서브에이전트가 예외 이벤트 없이 비정상 종료(Silent death)할 경우 부모 에이전트가 무한 대기(Blocking) 상태에 빠지는 문제 발생
|
||||
|
||||
## [사례] Multi Agent Orchestration의 장점
|
||||
1. **프롬프트의 간소화 및 루프 엔진의 진화**
|
||||
- 기존의 길고 장황한 단일 "Super Prompt" 엔지니어링 시대에서 벗어나, 에이전트를 구동하고 제어하는 자율 루프(Loop Architecture) 설계 중심으로 패러다임 이동
|
||||
- *PSPDFKit 창업자이자 오픈소스 AI 에이전트 프로젝트인 OpenClaw의 크리에이터인 페터 슈타인베르거(Peter Steinberger, 2026년 초 OpenAI 합류)는 **"코딩 에이전트에 프롬프트를 더 넣지 말고, 에이전트를 구동하는 루프를 설계하라"**(Stop prompting your coding agents; start designing loops that prompt your agents)고 강조한 바 있음*
|
||||
- 멀티 에이전트 구조에서는 작업 지시 PM 에이전트, 작업 수행 Worker 에이전트, 유효성 검증 Reviewer 에이전트로 나뉨으로써 프롬프트가 단편적이고 명료해지는 이점 확보
|
||||
2. **컨텍스트 설명 불필요 (Context-Free Sharing)**
|
||||
- 공유 작업 환경(Shared Workspaces)과 Git 같은 버전 관리 시스템을 에이전트들이 공유하므로, 새로 합류한 에이전트에게 변경 이력이나 현재 맥락을 다시 텍스트로 설명하느라 불필요한 토큰과 대기 시간 낭비 방지
|
||||
3. **이종 모델 피드백을 통한 고품질 산출물 교차 검증**
|
||||
- 특정 한 모델 계열만으로 결과물을 짜고 동일한 계열에 검토를 시키는 것보다, 서로 다른 아키텍처와 특징을 지닌 이종 모델(Gemini 작성 ➡️ Claude 검토 등) 간 상호 보완할 때 결과물의 신뢰성 극대화 및 보이지 않는 맹점 상호 보완
|
||||
4. **비용 효율적인 토큰 분배 (Cost Optimization)**
|
||||
- 쉬운 코드 생성이나 정보 검색은 경량화된 저비용 모델(예: Gemini Flash 세대)을 탑재한 에이전트에 분산 위임하고, 고난도의 논리적 추론이 필요한 부분에만 최상위 고비용 모델을 탑재한 에이전트를 적절히 매칭함으로써 종합적인 API 비용 효율적 제어
|
||||
|
||||
## [요구사항] 성공적인 구현을 위해 필요한 것들 (What We Need?)
|
||||
앞의 문제점과 장점을 종합하면, 성공적인 멀티 에이전트 오케스트레이션 구현을 위해서는 다음 5가지 구성요소가 필수적이며, 이 요구사항들이 4장(표준)과 5장(인프라)에서 소개할 솔루션의 선정 기준이 됩니다.
|
||||
|
||||
1. **Agent 간 작업 환경 공유 (A2A의 Agent Card 기반)**
|
||||
- 특정 에이전트에게 태스크를 안전하게 위임하고 위임받기 위해선, 각 에이전트 카드를 통해 서로의 역할, 엔드포인트, 입력 명세 스키마를 신뢰성 있는 방식으로 동기화
|
||||
2. **에이전트 작동 인프라스트럭처 (Agent Working Infrastructure)**
|
||||
- 에이전트들이 통신에 사용할 서비스 주소와 포트를 동적으로 조회할 수 있는 서비스 디스커버리 기능 및 자동 라우팅 체계 내재
|
||||
3. **일관성 있는 워크플로우 추적 및 공유 (Issue & Workflow Tracking)**
|
||||
- 서로 다른 에이전트가 동일한 작업을 재수행할 때 동일한 프로세스와 출력을 일관되게 얻을 수 있도록 워크플로우 사양이 제어되어야 함. 또한 에러나 중간 정지가 일어났을 때 복구 및 추적이 용이하도록 규격화된 이슈 추적 인터페이스 마련
|
||||
4. **고성능 양방향 메시징 시스템 (Advanced Messaging System)**
|
||||
- 고용량의 코드 블록, 이미지 및 멀티모달 센서 데이터 등을 대량으로 빠르고 정확하게 공유하기 위해서는 기존의 MQTT나 단순 메시지 큐(MQ) 방식은 토픽 세분화와 페이로드 크기 한계로 인해 통신 병목을 겪을 수밖에 없음
|
||||
- 단편적인 이벤트 알림만 전송하는 구조에서 탈피하여 상세 에러 트레이스, 상태 구조체, 이미지 바이너리 등을 한꺼번에 담을 수 있는 풍부한 페이로드 지원 메시징 규격이 필수적임. 나아가 대용량 멀티모달 푸시(Push)와 양방향 스트리밍을 지원하기 위해 HTTP/3의 멀티 스트리밍 등 고성능 통신 수반
|
||||
5. **작업 및 태스크 관리 시스템 (Job & Task Lifecycle Controller)**
|
||||
- 하나의 부모 작업을 하위 스크럼(Scrum) 단위로 쪼개어 서브에이전트들에게 뿌려주는 라이프사이클 관리 기능이 있어야 함. 각 서브에이전트의 생성부터 소멸까지의 메시징 토픽과 임시 토큰을 정리해야 하며, 이 과정에서 부하를 고르게 배분하고 실력 있는 에이전트를 매칭하기 위한 로드 밸런싱 기법 병행
|
||||
|
||||
|
||||
|
||||
### 🔗 요구사항과 기술 솔루션 매핑 (Bridge Mapping)
|
||||
- **요구사항 1(작업 환경 공유)** 및 **요구사항 2(서비스 디스커버리)**는 상호 연동 장벽을 허물기 위해 **§4 에이전트 상호운용성 표준(ACP/A2A)**을 통해 규격화된 표준 명세로 제공
|
||||
- **요구사항 4(고성능 양방향 메시징)** 및 **요구사항 5(태스크 라이프사이클/로드밸런싱)**는 고부하 대규모 실시간 분산 환경에서 물리적 네트워크 및 런타임 최적화를 실현하는 **§5 gRPC 백본 인프라**를 통해 해결
|
||||
- **요구사항 3(워크플로우 추적)**은 표준 명세(Agent Card)의 추적 스키마와 물리 인프라(gRPC liveness probe 및 트레이싱 도구) 양대 측면에 모두 걸쳐 상호 보완적 제어
|
||||
|
||||
---
|
||||
|
||||
# 4. 에이전트 상호운용성 확보를 위한 표준: ACP, A2A
|
||||
|
||||
## 왜 이종 에이전트 연동 표준이 필요한가
|
||||
3장에서 정의한 요구사항 중 **'Agent 간 작업 환경 공유'(요구사항 1)**와 **'서비스 디스커버리'(요구사항 2)**는 특정 벤더의 독점적 구현이 아닌 개방형 표준 규격을 통해 해결되어야 합니다. 그 핵심 해답이 되는 오픈 규격 표준이 바로 ACP와 A2A입니다.
|
||||
|
||||
서로 다른 벤더가 제작하고 각기 다른 아키텍처로 설계된 이종 에이전트들이 복잡한 맞춤형 결합 코드(Glue code) 없이도 서비스 검색, 역할 전파 및 태스크 위임을 유연하게 수행하려면 통일된 오픈 통신 규약이 필수적입니다. 표준 규격을 통하면 에이전트 생태계의 결합도가 낮아져 이종 에이전트 간의 동적 협업 네트워크 구축 속도가 비약적으로 향상됩니다.
|
||||
|
||||
## ACP (Agent Communication Protocol)
|
||||
IBM Research가 자사의 BeeAI 프레임워크 연동을 지원하기 위해 **2025년 3월** 발표했던 오픈 표준 에이전트 통신 인터페이스입니다. 이종 에이전트 간의 서비스 발견(Service Discovery), 상호작용 방법 협상, 태스크 위임 프로세스를 최초로 규격화하였습니다. 이후 **2025년 8월 27일** 공식 깃허브 저장소가 아카이빙되며 Linux Foundation AI & Data 하위의 A2A(Agent-to-Agent) 프로토콜로 공식 통합 및 병합되어 단일 연합 생태계를 형성하였습니다.
|
||||
|
||||
## A2A와 Agent Card
|
||||
- ### A2A (Agent-to-Agent) 프로토콜
|
||||
Google과 50여 개 파트너사들이 **2025년 4월** 공동 발표하고 **2025년 6월** Linux Foundation에 기증한 이종 에이전트 간 표준 메시지 교환 및 상태 추적용 통합 통신 오픈 표준입니다. 서로 다른 벤더가 구현한 에이전트나 다양한 아키텍처 기반의 에이전트가 복잡한 결합 코드 없이도 협업 메시지를 교환하고 상태 추적 지원
|
||||
- ### Agent Card (에이전트 카드)
|
||||
A2A 생태계에서 에이전트의 기능 명세서 역할을 하는 JSON 포맷의 표준 규격서입니다. 이는 **요구사항 1(작업 환경 공유)**을 물리적 파일 수준에서 구체화하는 핵심 메커니즘으로 기능함. 에이전트 카드에는 해당 에이전트의 명칭, 제공 가능한 역량(Capabilities), 호출 엔드포인트 정보, 요청 시 통과해야 하는 보안 인증 사양(Authentication) 등이 명시되어 있어 서비스 검색 시스템(Service Discovery)이 에이전트의 역할을 실시간으로 탐색할 수 있도록 보장. 주로 `/.well-known/agent-card.json` 경로에 배포
|
||||
|
||||
---
|
||||
|
||||
# 5. 지능형 사물인터넷(AIoT) 및 gRPC 기술 동향
|
||||
|
||||
## AIoT 환경에서 멀티 에이전트가 유용한 이유
|
||||
스마트 팩토리, 스마트 팜 등 다수의 물리 디바이스로 구성된 Physical 계층과 엣지 연산 계층이 복잡하게 혼재하는 AIoT 환경에서는 단일 클라우드 에이전트만으로 지연 시간 제어와 로컬 예외 상황 대처를 감당하기 어렵습니다. 따라서 센서 수집, 이상 탐지, 자율 제어 등의 고유 역할을 여러 에이전트에 자율 분산 배치하여 협업 기반의 로컬 제어를 실현해야 합니다. 이를 통해 네트워크 연결 차단 시에도 독립 제어가 가능하며, 컴퓨팅 자원이 극도로 제한된 엣지 인프라 하에서도 실시간 협업 자율 제어를 달성할 수 있습니다.
|
||||
|
||||
## Why we need gRPC?
|
||||
3장 요구사항 중 **'고성능 양방향 메시징'(요구사항 4)**과 **'태스크 라이프사이클 관리'(요구사항 5)**를 물리적 인프라 수준에서 충족하는 강력한 통신 백본이 gRPC (Google Remote Procedure Call) 프로토콜입니다.
|
||||
|
||||
1. **A2A 프로토콜과의 높은 호환성 및 스마트 팩토리/팜 최적화**
|
||||
- 스마트 팜, 스마트 팩토리와 같은 AIoT 서비스를 타겟으로 하는 개발 단계에서 대역폭이 극단적으로 제약되는 센서 디바이스는 MQTT/CoAP 등을 혼용하되, 상위 게이트웨이 및 연산 계층에서는 gRPC가 강력하고 최적의 제어 프로토콜로 작동
|
||||
2. **고성능 멀티 모달 바이너리 스트리밍 및 Pub/Sub 네이티브 지원**
|
||||
- HTTP/2 또는 HTTP/3 기반으로 작동하여 양방향 스트리밍, Request/Response, Pub/Sub 통신 방식을 단일 포트에서 완벽히 수행하며 대용량 멀티모달 바이너리를 고속으로 처리
|
||||
- 마이크로서비스 아키텍처(MSA)에서 메인 통신 규격으로 활용되므로 타 시스템으로의 이식 및 연동 성능 탁월
|
||||
3. **구조화된 직렬화 기반의 효율적 태스크 생명주기 및 부하 분산**
|
||||
- Protobuf를 통한 강력한 스키마 기반 직렬화로 통신 메시지 처리 효율을 JSON 파싱 대비 수배 이상 향상하고 메모리 오버헤드 극소화
|
||||
- 이미 검증된 Envoy, Kubernetes gRPC liveness probe 등의 기성 인프라를 활용하여 에이전트 라이프사이클 감시 체계를 최소한의 공수로 구축 가능
|
||||
|
||||
## 기술 동향 요약
|
||||
최근 AIoT 에이전트 인프라 환경은 물리적 센서 단말에서 대역폭을 극단적으로 아끼기 위해 경량 프로토콜(MQTT/CoAP)을 사용하고, 상위 연산 및 오케스트레이터 게이트웨이 계층에서는 고성능 프로토콜(gRPC)을 사용하여 계층별 완충 혼용을 유도하는 설계가 주류 트렌드로 자리잡고 있습니다. 이러한 하이브리드 프로토콜 아키텍처는 마이크로서비스 아키텍처(MSA)에 뛰어난 이식 및 확장 성능을 보장합니다.
|
||||
|
||||
---
|
||||
|
||||
# 특강 최종 요약
|
||||
|
||||
## AI Multi-Agents 오케스트레이션 기술 동향 및 사례
|
||||
- **AI 에이전트 구현을 위한 3대 핵심 엔지니어링 기법**: 프롬프트 엔지니어링, 컨텍스트 엔지니어링, 하네스 엔지니어링을 통하여 단일 에이전트 설계 및 도구 연동 제어
|
||||
- **AI Agent 기능 확장**: MCP(Model Context Protocol) 및 SKILL 프레임워크를 기반으로 클라이언트-서버 구조로 동적인 도구(Tools) 및 데이터(Resources) 호출 인터페이스 확장
|
||||
- **멀티 에이전트 협업 체계 및 오케스트레이션 인프라**: 싱글 에이전트의 한계(Lost in the middle, 환각)를 극복하기 위해 TMUX 세션 관리 TUI, crewAI 역할 협업, LangGraph 상태 보존 그래프를 결합한 분산 협업 구조 구축
|
||||
- **에이전트 상호운용성 확보를 위한 표준**: 벤더 종속 없이 협업 위임을 실현하기 위해 ACP와 A2A 프로토콜 표준 규격 및 Agent Card 기반의 상호 탐색 환경 통일
|
||||
- **지능형 사물인터넷 (AIoT) 및 gRPC 기술 동향**: 물리 및 엣지 단말 자원 한계를 보완하기 위한 경량 프로토콜(MQTT/CoAP)과 고성능 양방향 메시징 gRPC를 계층별 완충 혼용하여 MSA 기반의 실시간 자율 분산 제어망 완성
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 438 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 106 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 140 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 228 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 208 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 694 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 255 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 1.1 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 108 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 1.1 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 780 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 486 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 486 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 518 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 515 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 436 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 515 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 367 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 367 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 486 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 360 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 420 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 360 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 416 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 459 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 426 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 472 KiB |
@@ -0,0 +1,123 @@
|
||||
---
|
||||
marp: true
|
||||
---
|
||||
|
||||
# AI Multi-Agents 오케스트레이션 기술 동향 및 사례
|
||||
### 정적 AI 모델에서 자율적 AI 에이전트로의 패러다임 전환
|
||||
|
||||
---
|
||||
|
||||
## 🔍 이 발표에서 다루고 싶은 핵심 화두
|
||||
|
||||
최근 AI 분야에서 가장 뜨거운 화두는, 단순히 사용자의 질문에 답을 하는 **정적 AI 모델(LLM)**을 넘어 스스로 목적을 가지고 움직이는 **자율형 AI 에이전트(AI Agent)**로의 패러다임 전환입니다.
|
||||
|
||||
우리가 흔히 쓰는 AI 모델이 똑똑하게 생각하고 답변을 생성하는 '지능 엔진'이라면, AI 에이전트는 그 지능에 자율성과 행동력, 그리고 다른 에이전트와의 협업 능력까지 결합한 실제 '행동의 주체'라고 볼 수 있습니다.
|
||||
|
||||
오늘 발표에서는 단순한 AI 모델을 자율적인 에이전트로 업그레이드하는 구체적인 엔지니어링 방법론부터 시작하여, 여러 에이전트들이 유기적으로 협업하는 오케스트레이션 인프라와 산업 표준 기술 동향을 아주 쉽게 풀어보려 합니다.
|
||||
|
||||
---
|
||||
|
||||
### 💡 구체적 사례 비교: "멀티 에이전트 관련 연구를 조사해줘"
|
||||
|
||||
사용자가 **"멀티 에이전트 관련 최신 연구 동향을 조사하고 보고서로 저장해줘"**라는 명령을 내렸을 때, 두 시스템은 완전히 다르게 움직입니다.
|
||||
|
||||
먼저 **AI 모델(LLM)**은 머릿속(학습된 데이터)에 있는 지식만을 꺼내서 기존 연구 목록을 말로 친절하게 설명해 줍니다. 겉보기에는 똑똑해 보이지만, 실시간으로 최신 논문을 인터넷에서 검색해 오거나 보고서 파일을 디스크에 직접 저장하는 '행동'은 수행하지 못합니다.
|
||||
|
||||
반면 **AI 에이전트(Agent)**는 명령을 받자마자 실제 행동을 개시합니다. 학술 API에 접속해 최신 논문을 검색해 오고, PDF 파일을 직접 다운로드해서 그 내용을 파싱한 다음, 최종 결과물을 마크다운 형태의 파일로 사용자의 컴퓨터 폴더에 실제로 만들고 저장해 줍니다.
|
||||
|
||||
---
|
||||
|
||||
### 📊 역할과 작동 방식의 결정적 차이
|
||||
|
||||
이 두 개념의 차이는 다음과 같이 쉽게 풀어볼 수 있습니다.
|
||||
|
||||
- **생각(Thinking)과 행동(Doing)의 차이**
|
||||
AI 모델은 질문을 던지면 이에 부합하는 지식이나 코드를 화면에 '답변'해 주는 똑똑한 뇌 역할을 합니다. 반면 AI 에이전트는 최종 목적지에 도달하기 위해 스스로 세부 계획을 세우고 실제 컴퓨터 환경에서 발로 뛰는 손과 발 역할을 함께 수행합니다.
|
||||
- **조언(Advise)과 실행(Execution)의 차이**
|
||||
모델은 "이 스크립트를 이렇게 실행해서 저장하세요"라고 텍스트로 가이드라인만 알려줍니다. 하지만 에이전트는 운영체제나 파일 시스템에 직접 들어가서 스크립트를 실제로 실행하고 그 결과물을 직접 파일로 구체화합니다.
|
||||
- **오류를 마주했을 때의 대처 능력**
|
||||
모델은 실행 중 오류가 났을 때 사람이 에러 로그를 다시 복사해서 붙여넣어 주기 전까지는 대기할 수밖에 없습니다. 반면 에이전트는 오류가 나면 스스로 로그를 해석하고, 성찰(Reflection) 과정을 거쳐 계획을 수정해 다시 시도합니다.
|
||||
|
||||
---
|
||||
|
||||
### 🚗 아주 쉬운 비유: "운전자"와 "자율주행 차량"
|
||||
|
||||
그렇다면 에이전트는 모델이 시키는 대로만 움직이는 수동적인 존재일까요? 결코 그렇지 않습니다.
|
||||
|
||||
- **AI 모델(LLM)은 '운전자(뇌)' 입니다.**
|
||||
"여기서 우회전하고 다음에서 멈추자"라는 인지적 판단과 주행 경로(추론)를 수립합니다.
|
||||
- **AI 에이전트(Agent)는 '자율주행 차량 시스템 전체' 입니다.**
|
||||
운전자의 판단을 가속 페달과 바퀴 회전(도구 실행)으로 바꾸며, 다음과 같은 독자적인 **시스템 수준의 판단**을 수행합니다:
|
||||
- **안전 가드레일**: 운전자가 실수로 시스템을 파괴하는 명령과 같이 위험한 길로 가려 할 때 비상 제동을 걸어 이를 원천 차단합니다.
|
||||
- **예외 복구 및 통제**: 네트워크 연결이 끊기거나 무한 루프에 빠지는 상황이 발생하면 스스로 판단하여 실행을 중단하고 우회 경로를 수립합니다.
|
||||
- **합의 형성(Consensus)**: 멀티 에이전트 환경에서 각 에이전트들의 교차 검증 결과를 수집하여 통과나 반려 여부를 결정하고 최종 집행을 판정합니다.
|
||||
|
||||
---
|
||||
|
||||
## 🛠️ AI 에이전트가 갖춰야 할 4대 필수 기능
|
||||
|
||||
단순히 대화만 나누는 챗봇이 아니라, 진짜 제 역할을 하는 **자율형 AI 에이전트**가 되기 위해 소프트웨어 시스템 차원에서 반드시 제공해야 하는 4가지 핵심 기능입니다.
|
||||
|
||||
1. **계획 및 추론 능력 (Planning)**
|
||||
2. **기억 및 상태 관리 능력 (Memory)**
|
||||
3. **도구 활용 및 실행 능력 (Tool Use & Action)**
|
||||
4. **상호 통신 및 협업 능력 (Collaboration)**
|
||||
|
||||
---
|
||||
|
||||
### 1. 계획 및 추론 능력 (Planning)
|
||||
|
||||
사용자가 최종 목표만 주면 스스로 실행 가능한 단계별 세부 태스크를 설계하고, 진행 과정에서 문제가 생기면 계획을 유연하게 수정하는 능력입니다.
|
||||
|
||||
- **Task Decomposition (작업 분해)**: 복잡한 목표를 실행 가능한 작은 단위의 세부 태스크로 분할 (예: Chain of Thought, Tree of Thoughts 등)
|
||||
- **Self-Reflection (자기 성찰 및 피드백)**: 행동 결과를 스스로 분석하고 실수를 교정하여 향후 계획을 실시간으로 수정 (예: ReAct, Reflexion 프레임워크)
|
||||
|
||||
* **실제 예시**:
|
||||
에이전트에게 "블로그 기사 작성"을 요청하면, 스스로 **'키워드 조사 ➡️ 개요 작성 ➡️ 본문 집필 ➡️ 오탈자 검사'** 순으로 계획을 세웁니다. 만약 맞춤법 검사 도중 치명적인 논리 오류를 발견하면, 본문 작성 단계로 스스로 되돌아가 계획을 수정하고 다시 쓰는 자가 성찰(Self-Reflection)을 거칩니다.
|
||||
|
||||
---
|
||||
|
||||
### 2. 기억 및 상태 관리 능력 (Memory)
|
||||
|
||||
현재 나누는 대화의 즉각적인 흐름(단기 기억)뿐만 아니라, 과거의 경험과 누적된 지식(장기 기억)을 필요할 때마다 영속적으로 꺼내어 쓰는 능력입니다.
|
||||
|
||||
- **Short-term Memory (단기 기억)**: 현재 대화나 컨텍스트 윈도우 내에서 실시간으로 유지되는 즉각적인 맥락 정보
|
||||
- **Long-term Memory (장기 기억)**: 외부 데이터베이스나 벡터 DB를 활용하여 과거 대화 기록 및 지식을 RAG 기법으로 바인딩하는 정보 보존 공간
|
||||
|
||||
* **실제 예시**:
|
||||
에이전트에게 "어제 작업하던 파이썬 소스코드의 오류를 이어서 수정해줘"라고 요청하는 경우입니다. 에이전트는 데이터베이스에 누적된 과거 대화 히스토리와, 벡터 DB에 저장되어 있는 소스코드의 예전 상태 정보를 동적으로 인출(Retrieval)해 와 대화 맥락을 끊김 없이 이어갑니다.
|
||||
|
||||
---
|
||||
|
||||
### 3. 도구 활용 및 실행 능력 (Tool Use & Action)
|
||||
|
||||
인터넷 검색, 외부 API 호출, 파일 시스템 접근, 코드 실행 등 컴퓨터 세상의 다양한 소프트웨어를 직접 연결하고 작동시키는 손과 발 역할을 의미합니다.
|
||||
|
||||
* **실제 예시**:
|
||||
복잡한 나눗셈 연산을 해야 할 때 직접 계산기 도구를 호출해 오차 없이 연산하고, 최신 주식 시세를 알기 위해 증권사 API를 호출하며, 작성한 코드가 잘 돌아가는지 검증하기 위해 격리된 샌드박스 컴퓨터 환경(Docker)을 구동해 스크립트를 직접 실행합니다.
|
||||
|
||||
---
|
||||
|
||||
### 4. 상호 통신 및 협업 능력 (Collaboration)
|
||||
|
||||
혼자서 모든 일을 처리하는 것이 아니라, 다른 역할을 가진 전문 에이전트나 사용자 시스템과 표준 규격으로 메시지를 주고받으며 큰 작업을 분산 처리하는 능력입니다.
|
||||
|
||||
* **실제 예시**:
|
||||
"이 프로젝트의 보안 취약점 보고서를 작성해줘"라는 명령을 내렸을 때의 상황입니다. 보안 에이전트가 소스코드를 스캔해 취약점을 나열하면, 인프라 에이전트가 가상 머신 설정을 검토하고, 최종적으로 리뷰어 에이전트들이 보고서의 신뢰성을 상호 검증하여 하나의 완성된 산출물을 합작해 냅니다.
|
||||
|
||||
---
|
||||
|
||||
## 🚀 패러다임 전환: Model eats the Scaffolding (모델이 외부 시스템을 흡수하다)
|
||||
|
||||
현재 에이전트 기술에서 가장 중요한 변화 중 하나는, 과거에 에이전트 제어 시스템(Scaffolding, 에이전트의 구동을 돕는 외부 뼈대 구조)이 수동으로 제어하던 기능들이 점점 AI 모델 내부로 흡수되고 있는 현상입니다.
|
||||
|
||||
- https://arca.live/b/characterai/174977057?category=%EB%89%B4%EC%8A%A42&p=1
|
||||
|
||||
- **스스로 생각하는 모델의 등장 (Test-time Compute, 추론 시점 추가 연산)**
|
||||
최근 출시된 Gemini Thinking이나 OpenAI o1/o3 같은 모델들은 외부 시스템이 루프를 돌려주지 않아도, 모델 스스로 출력을 내보내기 전에 내부적으로 계획을 세우고(Planning) 스스로 오류를 성찰(Reflection)하는 과정을 완료합니다.
|
||||
- **인지와 집행의 명확한 역할 분담**
|
||||
이에 따라 고차원적인 논리 설계와 계획(Planning)은 **AI 모델** 내부로 빠르게 넘어가고 있습니다. 반면 외부의 **에이전트 인프라(Harness, 에이전트 실행 및 도구 제어 장치)**는 안전한 실행 환경(Sandboxing, 격리 환경 실행), 권한 통제, 상태 관리처럼 모델이 직접 수행하기 어려운 물리적 보호막 역할을 담당하는 방향으로 진화하고 있습니다.
|
||||
- **차별화 요소(Alpha)의 이동**
|
||||
단순히 계획을 짜는 흐름을 코드로 구현하는 것의 가치는 점차 줄어들고 있습니다. 이제는 복잡한 인프라를 실시간으로 제어하고, 서로 다른 규격을 가진 다양한 에이전트들을 표준 프로토콜로 유기적으로 엮어내는 기술이 핵심 경쟁력으로 부상하고 있습니다.
|
||||
|
||||
---
|
||||
@@ -0,0 +1,115 @@
|
||||
# 🎙️ 특강 발표 대본 스크립트 — 0. Intro
|
||||
|
||||
본 문서는 `0_intro.md` 슬라이드에 대응하는 발표용 대본 스크립트입니다. 청중의 흥미와 이해를 돕기 위해 친절한 구어체 존댓말로 작성되었습니다.
|
||||
|
||||
---
|
||||
|
||||
### 🎴 Slide 1: 타이틀 (표지)
|
||||
* **슬라이드 제목**: AI Multi-Agents 오케스트레이션 기술 동향 및 사례 — 정적 AI 모델에서 자율적 AI 에이전트로의 패러다임 전환
|
||||
* **대본**:
|
||||
> "안녕하세요, 여러분. 오늘 특강을 진행하게 된 ○○○입니다.
|
||||
> 오늘 우리가 함께 나눌 주제는 **'AI Multi-Agents 오케스트레이션 기술 동향 및 사례'**입니다.
|
||||
> 최근 AI 시장은 매우 빠르게 변하고 있습니다. 그중에서도 가장 눈에 띄는 변화가 바로, 단순히 대답만 하던 정적인 AI 모델이 스스로 알아서 일을 처리하는 '자율형 AI 에이전트'로 바뀌고 있다는 점입니다.
|
||||
> 오늘 이 세미나를 통해 AI 에이전트가 무엇이고, 여러 에이전트가 어떻게 협업하는지 그 인프라와 최신 트렌드를 함께 살펴보겠습니다."
|
||||
|
||||
---
|
||||
|
||||
### 🎴 Slide 2: 🔍 이 발표에서 다루고 싶은 핵심 화두
|
||||
* **슬라이드 제목**: 이 발표에서 다루고 싶은 핵심 화두
|
||||
* **대본**:
|
||||
> "본론으로 들어가기 전에, 이번 특강 전체를 관통하는 핵심 화두를 먼저 짚어보려 합니다.
|
||||
> 최근 AI 업계의 가장 큰 흐름은 **'정적 AI 모델(LLM)'에서 '자율형 AI 에이전트(AI Agent)'로의 전환**입니다.
|
||||
> 우리가 흔히 쓰는 챗GPT나 제미나이 같은 AI 모델은 똑똑하게 생각하고 답변을 만들어내는 훌륭한 '지능 엔진'입니다. 하지만 지능만으로는 실제 업무를 완수하기 어렵습니다.
|
||||
> 반면 AI 에이전트는 그 똑똑한 지능에 '자율성'과 실제 컴퓨터를 조작하는 '행동력', 그리고 다른 에이전트와 손을 잡는 '협업 능력'까지 결합한 진짜 '행동의 주체'입니다.
|
||||
> 오늘 발표에서는 바로 이 모델을 어떻게 자율적인 에이전트로 확장할 수 있는지, 그리고 이들이 유기적으로 협업하는 인프라의 표준을 조망해 보고자 합니다."
|
||||
|
||||
---
|
||||
|
||||
### 🎴 Slide 3: 💡 구체적 사례 비교: "멀티 에이전트 관련 연구를 조사해줘"
|
||||
* **슬라이드 제목**: 구체적 사례 비교: "멀티 에이전트 관련 연구를 조사해줘"
|
||||
* **대본**:
|
||||
> "말로만 들으면 두 개념이 잘 와닿지 않으실 텐데요. 쉬운 예시를 하나 들어보겠습니다.
|
||||
> 청중 여러분 중 한 분이 AI에게 **'멀티 에이전트 관련 최신 연구 동향을 조사하고 보고서로 저장해줘'**라는 명령을 내렸다고 해봅시다.
|
||||
> 이때 **AI 모델(LLM)**은 자신의 머릿속, 즉 이미 학습된 데이터에 들어있는 기존 연구 목록을 꺼내 텍스트로 설명해 줍니다. 설명 자체는 훌륭하지만, 실시간으로 최신 논문을 인터넷에서 찾아오는 행동은 하지 못합니다. 당연히 보고서 파일을 여러분의 디스크에 직접 저장하는 물리적인 작업도 수행할 수 없습니다.
|
||||
> 반면 **AI 에이전트(Agent)**는 명령을 받자마자 스스로 필요한 행동 단계들을 계획합니다. 이어서 학술 API에 접속해 최신 논문을 실시간으로 검색하고 관련 PDF 파일을 직접 다운로드합니다. 마지막으로 그 본문을 요약한 보고서 파일을 여러분의 컴퓨터 폴더에 실제로 만들고 저장까지 완수합니다."
|
||||
|
||||
---
|
||||
|
||||
### 🎴 Slide 4: 📊 역할과 작동 방식의 결정적 차이
|
||||
* **슬라이드 제목**: 역할과 작동 방식의 결정적 차이
|
||||
* **대본**:
|
||||
> "이 두 시스템의 결정적 차이를 세 가지 포인트로 더 쉽게 요약해 보겠습니다.
|
||||
> 첫째는 **생각과 행동의 차이**입니다. AI 모델이 질문에 알맞은 답을 보여주는 똑똑한 '뇌'라면, 에이전트는 계획을 세우고 실제 컴퓨터 환경에서 움직이는 '손과 발' 역할을 같이 합니다.
|
||||
> 둘째는 **조언과 실행의 차이**입니다. 모델은 '이렇게 코드를 짜서 실행해서 저장해 보세요'라고 화면에 글씨로 조언만 하지만, 에이전트는 파일 시스템에 직접 들어가 코드를 실제로 실행하고 결과를 수집합니다.
|
||||
> 셋째는 **오류를 마주했을 때의 대처 능력**입니다. 모델은 에러가 나면 사람이 다시 에러 메시지를 복사해서 붙여넣어 주기 전까지는 멍하니 대기하지만, 에이전트는 스스로 로그를 읽고 자가 성찰(Reflection)을 거쳐 계획을 알아서 수정한 뒤 다시 도전합니다."
|
||||
|
||||
---
|
||||
|
||||
### 🎴 Slide 5: 🚗 아주 쉬운 비유: "운전자"와 "자율주행 차량"
|
||||
* **슬라이드 제목**: 아주 쉬운 비유: "운전자"와 "자율주행 차량"
|
||||
* **대본**:
|
||||
> "여전히 '그래도 결국 모델이 판단해서 코드를 짜는 건데 에이전트가 주체적이라고 볼 수 있나?'라는 의문이 생기실 수 있습니다.
|
||||
> 그래서 저는 이 둘을 **'운전자'와 '자율주행 차량'**으로 비유하곤 합니다.
|
||||
> 여기서 **AI 모델**은 차에 타고 있는 **운전자(뇌)**입니다. '다음 교차로에서 우회전하고 멈추자'라는 고차원적인 인지 판단을 담당하죠.
|
||||
> **AI 에이전트**는 운전자의 판단을 가속 페달과 바퀴 구동력으로 변환하는 **자율주행 차량 시스템 전체**입니다.
|
||||
> 특히 차량 시스템은 운전자가 실수로 절벽으로 돌진하려 할 때 자동으로 브레이크를 밟아 차단하는 **안전 가드레일** 역할이나, 통신이 끊겼을 때 스스로 갓길에 차를 대는 **예외 통제**, 그리고 여러 에이전트의 합의를 이끄는 **합의 형성** 같은 시스템 수준의 독자적인 판단을 수행합니다. 즉, 운전자 혼자서는 달릴 수 없으며, 차량 시스템이 있어야 비로소 목적지에 안전하게 도착할 수 있는 것입니다."
|
||||
|
||||
---
|
||||
|
||||
### 🎴 Slide 6: 🛠️ AI 에이전트가 갖춰야 할 4대 필수 기능 (개요)
|
||||
* **슬라이드 제목**: AI 에이전트가 갖춰야 할 4대 필수 기능
|
||||
* **대본**:
|
||||
> "그렇다면 단순한 대화형 앱이 아니라, 진짜 자율주행 차량 같은 온전한 'AI 에이전트'가 되기 위해 소프트웨어 시스템 차원에서 제공해야 할 4대 필수 기능은 무엇일까요?
|
||||
> 첫 번째는 계획 및 추론(Planning), 두 번째는 기억 및 상태 관리(Memory), 세 번째는 도구 활용 및 실행(Tool Use & Action), 그리고 마지막 네 번째는 상호 통신 및 협업(Collaboration)입니다.
|
||||
> 이제 각각의 기능이 구체적으로 어떤 역할을 하고 어떤 식으로 작동하는지 실제 사례와 함께 하나씩 소개해 드리겠습니다."
|
||||
|
||||
---
|
||||
|
||||
### 🎴 Slide 6-1: 1. 계획 및 추론 능력 (Planning)
|
||||
* **슬라이드 제목**: 1. 계획 및 추론 능력 (Planning)
|
||||
* **대본**:
|
||||
> "첫 번째는 **계획 및 추론 능력**입니다. 최종 목표만 주면 스스로 실행 가능한 세부 단계를 쪼개고 설계하며, 실패 시 자가 성찰을 통해 유연하게 계획을 수정하는 기능입니다.
|
||||
> 예를 들어, 에이전트에게 '블로그 기사 작성'을 요청해 보겠습니다.
|
||||
> 그러면 에이전트는 먼저 '키워드 조사 ➡️ 개요 작성 ➡️ 본문 집필 ➡️ 오탈자 검사' 순으로 머릿속으로 로드맵을 그립니다.
|
||||
> 그러다 마지막 오탈자 검사 도중 치명적인 흐름 오류를 발견하면, 처음으로 돌아가는 게 아니라 본문 집필 단계로만 스스로 돌아가 내용을 고쳐 쓰는 영리함을 보입니다. 이것이 바로 인지적인 계획 능력입니다."
|
||||
|
||||
---
|
||||
|
||||
### 🎴 Slide 6-2: 2. 기억 및 상태 관리 능력 (Memory)
|
||||
* **슬라이드 제목**: 2. 기억 및 상태 관리 능력 (Memory)
|
||||
* **대본**:
|
||||
> "두 번째 필수 기능은 **기억 및 상태 관리 능력**입니다.
|
||||
> 지금 막 나눈 대화 맥락을 기억하는 단기 기억과, 과거의 수많은 작업 이력이나 데이터베이스의 지식을 필요할 때마다 영구적으로 꺼내 쓰는 장기 기억을 결합해 다루는 능력입니다.
|
||||
> 예컨대 '어제 짜던 파이썬 코드의 에러를 이어서 고쳐줘'라고 지시하는 상황이 그렇습니다.
|
||||
> 에이전트는 어제의 대화 로그와 소스코드의 직전 수정본을 장기 기억 데이터베이스(벡터 DB 등)에서 스스로 찾아내어 가져옵니다. 덕분에 우리는 끊김 없이 맥락을 유지하며 협업을 이어갈 수 있습니다."
|
||||
|
||||
---
|
||||
|
||||
### 🎴 Slide 6-3: 3. 도구 활용 및 실행 능력 (Tool Use & Action)
|
||||
* **슬라이드 제목**: 3. 도구 활용 및 실행 능력 (Tool Use & Action)
|
||||
* **대본**:
|
||||
> "세 번째는 **도구 활용 및 실행 능력**입니다. 인터넷 검색, 외부 API 호출, 파일 제어 등 컴퓨터 세상의 다양한 도구들을 안전하게 연결하고 조작하는 '에이전트의 손과 발'입니다.
|
||||
> 실제로 복잡한 나눗셈이나 곱셈이 필요하면 수학 도구(계산기)를 꺼내 오차 없이 정밀 연산합니다.
|
||||
> 또 최신 정보가 필요하면 실시간 API나 브라우저를 구동하고, 작성한 코드가 작동하는지 검사하기 위해 컴퓨터 안에 격리된 실행 환경인 Docker 컨테이너를 직접 띄워 스크립트를 자율 실행하기도 합니다."
|
||||
|
||||
---
|
||||
|
||||
### 🎴 Slide 6-4: 4. 상호 통신 및 협업 능력 (Collaboration)
|
||||
* **슬라이드 제목**: 4. 상호 통신 및 협업 능력 (Collaboration)
|
||||
* **대본**:
|
||||
> "마지막 네 번째 기능은 **상호 통신 및 협업 능력**입니다.
|
||||
> 혼자 일하는 게 아니라 전문 분야가 다른 에이전트들이나 사용자 시스템과 표준 프로토콜로 소통하며 대형 프로젝트를 분산 처리하는 능력입니다.
|
||||
> 가령 '보안 취약점 보고서를 작성해줘'라는 과업이 주어졌을 때를 상상해 보세요.
|
||||
> 코드를 전문으로 분석하는 보안 에이전트가 문제점을 뽑아내고, 클라우드 전문 에이전트가 가상 머신 보안을 검토합니다.
|
||||
> 그리고 최종적으로 리뷰어 에이전트들이 모여 보고서 내용을 교차 검증하고 합의하여 하나의 완벽한 최종 보고서를 완성해 냅니다."
|
||||
|
||||
---
|
||||
|
||||
### 🎴 Slide 7: 🚀 패러다임 전환: Model eats the Scaffolding
|
||||
* **슬라이드 제목**: 패러다임 전환: Model eats the Scaffolding
|
||||
* **대본**:
|
||||
> "마지막으로 에이전트 기술의 가장 핵심적인 변화인 **'Model eats the Scaffolding'**에 대해 말씀드리겠습니다. 이는 모델이 에이전트 외부 제어 시스템을 흡수하는 현상을 뜻합니다.
|
||||
> 과거에는 에이전트를 작동시키기 위해 계획(Planning)이나 자가 성찰(Reflection) 루프를 외부 코드로 직접 구현해야 했습니다. 하지만 최근 출시된 제미나이 씽킹(Gemini Thinking)이나 오픈AI의 o1, o3 같은 모델들은 이러한 능력을 모델 자체의 내부 추론 과정으로 소화해 냅니다.
|
||||
> 이에 따라 고차원적인 논리 설계와 계획 수립은 **AI 모델**이 전담하는 형태로 빠르게 바뀌고 있습니다. 외부의 **에이전트 인프라(Harness, 에이전트 실행 제어 장치)**는 보안 샌드박싱(격리 환경 실행), 권한 차단, 세션 관리 같은 물리적 집행과 통제에 집중하는 구조로 이원화되고 있습니다.
|
||||
> 결과적으로 단순히 실행 루프를 만드는 구현 방식은 그 경쟁력을 잃어가고 있습니다. 대신 다중 에이전트들을 표준화된 프로토콜로 유기적으로 엮어내는 오케스트레이션과 인프라 제어 기술이 새로운 차별화 요소로 떠오르는 중입니다.
|
||||
> 그럼 바로 시작하겠습니다."
|
||||
@@ -0,0 +1,82 @@
|
||||
---
|
||||
marp: true
|
||||
---
|
||||
|
||||
# 1. AI 에이전트 구현을 위한 3대 핵심 엔지니어링 기법
|
||||
|
||||
성공적인 AI 에이전트 시스템을 구현하기 위해서는 단순히 모델에게 프롬프트를 입력하는 것을 넘어, **모델 제어**, **정보 연동**, **물리적 환경 연결**을 유기적으로 엮어내는 3가지 핵심 엔지니어링 기법이 필요합니다.
|
||||
|
||||
1. **프롬프트 엔지니어링 (Prompt Engineering)**: 에이전트의 페르소나와 사고 방식(추론 가이드라인)을 규정하는 작업입니다.
|
||||
2. **컨텍스트 엔지니어링 (Context Engineering)**: 대화 흐름을 끊김 없이 보존하고 관련 데이터를 적시에 제공하는 정보 정리 작업입니다.
|
||||
3. **하네스 엔지니어링 (Harness Engineering)**: 격리된 환경에서 다양한 소프트웨어 도구를 안전하게 조작할 수 있는 물리적 손발을 달아주는 작업입니다.
|
||||
|
||||
---
|
||||
|
||||
### 1️⃣ 프롬프트 엔지니어링 (Prompt Engineering)
|
||||
|
||||
모델의 발전과 자체 추론 기능의 향상으로 예전만큼 미시적인 프롬프트 트릭에 집착할 필요는 줄어들고 있습니다. 하지만 프롬프트는 여전히 **AI 에이전트 활용의 시작점이자 뼈대**입니다. 구체적이고 명확한 작동 지침을 만들기 위해 프롬프트 작성 시 반드시 반영해야 할 3대 핵심 고려사항입니다.
|
||||
|
||||
- **역할 및 페르소나 지시 (Role)**
|
||||
에이전트에게 전문 도메인 지식과 행동 경계를 지정해 줍니다. (예: *"너는 주니어 개발자를 코칭하는 꼼꼼한 테크리더 에이전트다. 직접 고치지 말고 가이드라인만 제공해라."*)
|
||||
- **구체적인 작업 예시 제공 (Few-shot)**
|
||||
원하는 출력 형식이나 중간 추론 과정의 모범 예시를 제공하여, 에이전트의 답변 일관성과 가독성을 극대화합니다.
|
||||
- **자가 검증 방법 제시 (Verification)**
|
||||
에이전트 스스로 작업의 무결성을 점검하게 하거나, 외부 시스템이 실행 결과를 확인 및 통제할 수 있도록 정형화된 출력 규격(예: 최종 통과 시 `[VERDICT: PASS]` 명시 요구)을 정의해 줍니다.
|
||||
|
||||
---
|
||||
|
||||
### 💡 실제 프롬프트 구조 예시 (ReAct 사고 방식)
|
||||
|
||||
에이전트가 단번에 대답하지 않고 단계별로 계획을 세워 도구를 사용하도록 프롬프트 구조를 강제하는 기법입니다.
|
||||
|
||||
```text
|
||||
[System Prompt]
|
||||
너는 복잡한 수식을 계산하는 수학 에이전트다. 다음 형식으로 사고해라:
|
||||
- Thought: 문제 해결을 위한 다음 행동 계획을 작성해라.
|
||||
- Action: 호출할 도구 이름과 인자값을 JSON으로 적어라. (예: Calculator)
|
||||
- Observation: 도구 실행 결과가 여기에 채워질 것이다.
|
||||
- Thought: 실행 결과를 바탕으로 성찰하고, 필요하면 다음 Action을 설계해라.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 2️⃣ 컨텍스트 엔지니어링 (Context Engineering)
|
||||
|
||||
에이전트가 다루는 대화 맥락과 작업 상태(State)를 효율적으로 정제하고, 수많은 외부 정보 중 **지금 꼭 필요한 관련 데이터(RAG)**만을 선별하여 제한된 AI의 기억 공간(컨텍스트 윈도우)에 밀도 높게 채워 넣는 기술입니다.
|
||||
|
||||
* **핵심 설계 요소**:
|
||||
- **대화 상태 보존**: 이전 턴의 작업 결과를 유실 없이 보존
|
||||
- **동적 바인딩**: 외부 RAG 검색기에서 관련도 높은 중요 데이터만 적시에 필터링하여 공급
|
||||
- **메모리 압축**: 불필요한 과거 로그는 요약하고, 핵심 현재 상태 구조체만 유지해 토큰 낭비 방지
|
||||
* **에이전트 상태 보존 예시 (State JSON)**:
|
||||
```json
|
||||
{
|
||||
"task_id": "job_10294",
|
||||
"current_working_directory": "/workspace/src",
|
||||
"error_logs": ["SyntaxError: unexpected EOF while parsing at line 14"],
|
||||
"completed_subtasks": ["1. 소스코드 로드 완료", "2. 오류 라인 식별"],
|
||||
"next_action_required": "오류 라인 14의 괄호 닫힘 확인 및 수정 스크립트 작성"
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 3️⃣ 하네스 엔지니어링 (Harness Engineering)
|
||||
|
||||
에이전트가 파일 시스템 제어, 브라우저 조작, 외부 API 호출 등 컴퓨터 세상의 다양한 도구들을 안전하게 가동할 수 있도록 **물리적 인터페이스(연결 고리)**를 구성하는 기술입니다.
|
||||
|
||||
* **핵심 설계 요소**:
|
||||
- **도구 호출 가로채기(Intercepting)**: 모델이 내놓은 도구 호출 의도(JSON 등)를 감지하고, 실제 터미널이나 프로그램의 함수로 전달해 구동함
|
||||
- **보안 샌드박싱 (Sandboxing)**: 에이전트가 악성 코드나 파괴적인 명령어를 무단 실행하지 않도록 격리된 가상 환경을 구축하고 권한을 통제함
|
||||
* **물리 인터페이스 도구 결합 예시**:
|
||||
```
|
||||
[LLM의 출력] ──> "Action: execute_command, args: { cmd: 'ls -la' }"
|
||||
│ (하네스가 이를 가로챔)
|
||||
▼
|
||||
[하네스 제어기] ──> 격리된 Docker 샌드박스 내부에서 'ls -la' 실제 실행
|
||||
│ (실행 결과 가로챔)
|
||||
▼
|
||||
[LLM의 입력] <── "Observation: total 12\ndrwxr-xr-x 3 user..." (모델에 반환)
|
||||
```
|
||||
|
||||
|
||||
@@ -0,0 +1,64 @@
|
||||
# 🎙️ 특강 발표 대본 스크립트 — 1. Engineering
|
||||
|
||||
본 문서는 `1_engineering.md` 슬라이드에 대응하는 발표용 대본 스크립트입니다. 청중의 이해를 돕기 위해 친절한 구어체 존댓말로 작성되었습니다.
|
||||
|
||||
---
|
||||
|
||||
### 🎴 Slide 1: 1장 타이틀 및 개요
|
||||
* **슬라이드 제목**: 1. AI 에이전트 구현을 위한 3대 핵심 엔지니어링 기법
|
||||
* **대본**:
|
||||
> "그럼 이제 본격적으로 1장, **AI 에이전트 구현을 위한 3대 핵심 엔지니어링 기법**을 살펴보겠습니다.
|
||||
> 단순히 똑똑한 AI 모델을 가져온다고 해서 알아서 일하는 에이전트가 완성되지는 않습니다.
|
||||
> 모델을 정밀하게 제어하고, 실시간 대화 정보를 관리하며, 실제 물리적 환경에 연결하기 위해 세 가지 엔지니어링 분야가 유기적으로 작동해야 합니다.
|
||||
> 첫 번째는 머리를 세팅하는 **프롬프트 엔지니어링**, 두 번째는 기억을 구성하는 **컨텍스트 엔지니어링**, 세 번째는 실제 손발을 달아주는 **하네스 엔지니어링**입니다.
|
||||
> 각 기법이 구체적으로 어떤 의미를 가졌는지 실제 사례와 함께 짚어보겠습니다."
|
||||
|
||||
---
|
||||
|
||||
### 🎴 Slide 2: 1️⃣ 프롬프트 엔지니어링 (Prompt Engineering)
|
||||
* **슬라이드 제목**: 1️⃣ 프롬프트 엔지니어링 (Prompt Engineering)
|
||||
* **대본**:
|
||||
> "첫 번째 기둥인 **프롬프트 엔지니어링**입니다.
|
||||
> 최근 AI 모델들이 비약적으로 발전하고 자체적인 추론 능력이 향상되면서, 예전만큼 단어나 기호 하나에 집착하는 미시적인 프롬프트 트릭의 가치는 줄어들고 있습니다.
|
||||
> 하지만 프롬프트는 여전히 **AI 에이전트 활용의 시작점이자 가장 중요한 뼈대**입니다. 에이전트 시스템을 설계할 때 프롬프트에 반드시 반영해야 하는 세 가지 고려사항이 있습니다.
|
||||
> 첫째는 **역할 및 페르소나 지시**입니다. 에이전트가 어떤 전문 지식 범위와 행동 규칙을 고수해야 하는지 경계를 지정해 주는 것입니다.
|
||||
> 둘째는 **구체적인 작업 예시 제공, 즉 Few-shot**입니다. 에이전트가 내놓는 답변이 예외 없이 일관된 양식과 톤을 유지하도록 모범 예시를 제공하는 것입니다.
|
||||
> 셋째는 **자가 검증 방법 제시**입니다. 에이전트 스스로 결과물을 검사하게 하거나, 외부 시스템이 실행 결과를 확인하고 안전하게 통제할 수 있도록 정형화된 출력 규격(예: 통과 시 `[VERDICT: PASS]` 명시 요구)을 심어두는 것입니다. 이 세 요소가 균형을 이루어야 비로소 신뢰할 수 있는 좋은 프롬프트가 완성됩니다."
|
||||
|
||||
---
|
||||
|
||||
### 🎴 Slide 2-1: 💡 실제 프롬프트 구조 예시 (ReAct 사고 방식)
|
||||
* **슬라이드 제목**: 💡 실제 프롬프트 구조 예시 (ReAct 사고 방식)
|
||||
* **대본**:
|
||||
> "그렇다면 이 고려사항들이 반영된 실제 프롬프트 구조는 어떨까요?
|
||||
> 대표적인 기법이 바로 화면에 보이는 **ReAct(Reason + Action) 사고 방식**을 강제하는 템플릿입니다.
|
||||
> 우리는 에이전트에게 단순히 '문제를 풀어라' 하고 결과만 묻지 않습니다.
|
||||
> 대신 'Thought(문제를 풀기 위한 계획을 먼저 세우고) ➡️ Action(네가 직접 실행할 도구의 인자값을 JSON으로 적고) ➡️ Observation(도구의 실제 실행 결과를 눈으로 보고 분석해라)'이라는 단계적 생각의 길을 열어줍니다.
|
||||
> 이렇게 구조화된 사고 가이드를 프롬프트에 강제함으로써, AI가 섣불리 엉터리 답을 찍지 않고, 신중하게 도구를 실행하며 그 결과를 토대로 정답을 향해 차근차근 나아가게 제어할 수 있습니다."
|
||||
|
||||
---
|
||||
|
||||
### 🎴 Slide 3: 2️⃣ 컨텍스트 엔지니어링 (Context Engineering)
|
||||
* **슬라이드 제목**: 2️⃣ 컨텍스트 엔지니어링 (Context Engineering)
|
||||
* **대본**:
|
||||
> "두 번째 기둥은 **컨텍스트 엔지니어링**입니다.
|
||||
> AI 모델의 기억 공간인 '컨텍스트 윈도우'는 무한하지 않고 비용이 듭니다.
|
||||
> 따라서 대화 흐름을 압축하여 유지하고, 수많은 소스코드나 문서 중에서 지금 당장 필요한 핵심 데이터만 적시에 필터링하여 꽂아주는 기술이 필수적입니다.
|
||||
> 슬라이드 오른쪽의 에이전트 상태 보존 예시를 보겠습니다.
|
||||
> 에이전트는 사용자와 주고받은 20번의 긴 대화 내용을 날것 그대로 모델에 던지지 않습니다.
|
||||
> 대신 현재 작업 ID가 무엇인지, 지금 작업 디렉터리는 어디인지, 발생한 에러 로그는 무엇인지, 그리고 이미 끝낸 작업과 다음에 할 일은 무엇인지 등을 JSON 형태의 구조화된 데이터 상태로 압축하고 요약하여 보존합니다.
|
||||
> 이렇게 상태를 효율적으로 캐싱하고 정제하여 모델에 알려줌으로써, 불필요한 비용을 줄이고 답변의 정확도를 극대화할 수 있습니다."
|
||||
|
||||
---
|
||||
|
||||
### 🎴 Slide 4: 3️⃣ 하네스 엔지니어링 (Harness Engineering)
|
||||
* **슬라이드 제목**: 3️⃣ 하네스 엔지니어링 (Harness Engineering)
|
||||
* **대본**:
|
||||
> "마지막 세 번째는 에이전트에게 진짜 실행 능력을 부여하는 **하네스 엔지니어링**입니다.
|
||||
> 아무리 모델이 훌륭한 수정 계획을 세워도, 실제 디스크에 저장하거나 코드를 컴파일할 수 없다면 에이전트라고 부를 수 없습니다.
|
||||
> 하네스는 모델이 내린 판단을 감지해 실제 컴퓨터 명령어(ls, python3 run 등)로 변환해 실행하고, 그 실행 결과를 다시 모델에게 바인딩해 주는 인터페이스 인프라입니다.
|
||||
> 슬라이드의 다이어그램을 보시면 흐름이 잘 보입니다.
|
||||
> 모델이 'Action: 파일 목록을 보고 싶어'라고 텍스트로 내놓으면, 에이전트 하네스 시스템이 이를 가로채서(Intercept) 실제 격리된 컴퓨터 환경(Docker 샌드박스 등)에서 명령을 수행합니다.
|
||||
> 그리고 그 실행 결과를 다시 'Observation: 결과는 다음과 같아'라고 정형화해 모델의 눈앞에 가져다줍니다.
|
||||
> 또한, 모델이 혹시나 컴퓨터를 망가뜨릴 수 있는 명령을 내리지 못하도록 안전망(Sandboxing)을 씌워주는 것 역시 하네스 엔지니어링의 핵심 의무입니다.
|
||||
> 이 3대 기술이 완벽히 맞물렸을 때, 비로소 자율형 에이전트가 단독으로 기동할 수 있게 됩니다."
|
||||
@@ -0,0 +1,52 @@
|
||||
---
|
||||
marp: true
|
||||
---
|
||||
|
||||
# 2. AI Agent 기능 확장: MCP & SKILL
|
||||
|
||||
## MCP (Model Context Protocol)
|
||||
Model Context Protocol(MCP)은 Anthropic이 2024년 11월 발표한 오픈 소스 프로토콜로, AI 애플리케이션(Host) 내부의 클라이언트(Client)가 로컬/원격의 도구(Tools), 데이터 소스(Resources), 그리고 컨텍스트 템플릿(Prompts)을 통일된 규격으로 안전하게 호출할 수 있는 공통 인터페이스입니다.
|
||||
- **Host-Client-Server 구조**: 에이전트 플랫폼(Host) 내 클라이언트가 표준화된 MCP 프로토콜을 통해 외부의 다양한 MCP 서버들과 통신하여 기능을 동적으로 확장하는 형태
|
||||
- **3대 제공 요소**:
|
||||
- **Tools**: 에이전트가 실행할 수 있는 실행형 기능(계산기, 파일 제어, API 호출 등)을 명세하고 호출 처리
|
||||
- **Resources**: 에이전트가 읽을 수 있는 데이터 소스, 파일, 컨텍스트 상태 정보를 노출
|
||||
- **Prompts**: 자주 사용되는 프롬프트 템플릿과 실행 지침을 표준 규격으로 제공
|
||||
|
||||
## CLI 코딩 에이전트: Claude Code vs Cowork
|
||||
AI 에이전트의 대표 주자인 Claude는 Claude Desktop App에서 Claude Cowork와 Claude Code라는 두 가지 상이한 서비스를 제공합니다.
|
||||
- **작동 방식의 차이**: Claude Cowork는 일상적인 사무 비서 역할로 Cloud 상에서 필요한 파일(pdf, word, excel 등)을 읽고 쓰는 방식을 사용하며, Claude Code는 Coding 작업에 특화되어 Local Computer에 필요한 모듈과 소프트웨어를 설치하여 직접 파일 수정 및 실행을 수행
|
||||
- **환경적 이점**: Claude Code는 터미널에서 로컬 컴퓨터의 필요한 모듈/소프트웨어를 바탕으로 작업 디렉터리 내 파일을 직접 제어하여 개발 업무에 고도화된 성능 발휘
|
||||
|
||||
|
||||
|
||||
- **생산성 극대화**: Claude Code를 프로젝트에 알맞게 조련하여 사용할 경우 단순 Cloud 비서 환경 대비 월등히 높은 결과물 기대 가능
|
||||
|
||||
## SKILL이란
|
||||
Skills(기술/도구 패키지)는 AI 에이전트가 외부 환경과 동적으로 상호작용할 수 있도록 결합하는 기능적 실행 모듈입니다. 단순히 LLM에게 단순 프롬프트 지시를 하는 프롬프트 엔지니어링 수준을 넘어, 에이전트가 특정 목표를 위해 직접 실행할 수 있는 실행 코드, 도구의 명세 스키마(Tool Schema), 사용 설명 및 예시(Few-shot) 등이 하나로 패키징된 자율 확장 도구 모음입니다.
|
||||
- **동적 모듈화 및 모듈화 방식**: 상황에 따라 필요한 기술을 동적으로 로드해 사용하고, 완료 후 반환하는 독립 모듈화 형태 채택
|
||||
- **작업 수행 한계 돌파**: 텍스트 생성이라는 언어 모델의 한계를 넘어 파일 제어, 서버 배포, 물리 데이터 수집 등 실질적인 업무 대행 능력을 에이전트에 부여
|
||||
|
||||
## 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
|
||||
|
||||
|
||||
|
||||
|
||||
---
|
||||
@@ -0,0 +1,107 @@
|
||||
---
|
||||
marp: true
|
||||
---
|
||||
|
||||
# 3. 멀티 에이전트 협업 체계 및 오케스트레이션 인프라
|
||||
|
||||
## 싱글 에이전트의 한계
|
||||
단일 에이전트는 대규모 컨텍스트를 처리할 때 정보 누락(Lost in the middle) 현상이 발생하기 쉽고, 여러 도구를 한꺼번에 다루어야 할 때 환각(Hallucination)율이 증가하는 문제가 있습니다. 또한 역할 집중으로 인한 프롬프트의 장황화, 멀티태스킹 오류 및 컨텍스트 인지 한계 등의 명확한 한계를 가집니다.
|
||||
|
||||
## 멀티 에이전트란: 역할 세분화와 교차 검증
|
||||
멀티 에이전트(Multi-Agent) 시스템은 단일 에이전트(Single Agent)의 한계를 극복하기 위해, 서로 다른 페르소나와 전문 도구(Skills)를 갖춘 여러 개의 에이전트들이 협력 네트워크를 형성하여 복잡한 목표를 조율(Orchestration)하고 분할 해결하는 구조입니다.
|
||||
- **역할 세분화 (Role Specialization)**: 에이전트별로 한정된 역할(PM, Developer, QA, Researcher 등)과 도구만을 부여하여 프롬프트 노이즈를 억제하고 추론 정확도 향상
|
||||
- **교차 검증**: 서로 다른 이종 모델(Gemini 작성 ➡️ Claude 검토 등) 간의 상호 비평 및 검증 루프를 통해 결과물의 정합성을 교차 검증하고 결과 신뢰성 극대화
|
||||
- **분할 정복 (Divide and Conquer)**: 하나의 거대한 프로젝트를 독립된 세부 태스크로 쪼개어 다수의 에이전트가 병렬적으로 해결함으로써 복잡성 분산
|
||||
|
||||
## Subagent / Team agent
|
||||
|
||||
- ### Subagent란
|
||||
Subagent는 부모 에이전트(Parent Agent 또는 Orchestrator)에 의해 동적으로 생성되어 특정 국소적이고 독립적인 태스크를 대행한 뒤, 결과를 상위로 반환하고 소멸하는 종속형 에이전트입니다.
|
||||
- **컨텍스트 격리**: 하위 작업의 맥락만을 분기(Branch)하여 처리함으로써 상위 대화의 컨텍스트 오염을 막고 토큰 소모량 최적화 및 속도 개선
|
||||
- **예시**: 메인 에이전트가 리팩토링 중 특정 모듈 에러 복구 작업만을 subagent에 위임하여 처리하는 독립적인 문제 해결 기법
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
- ### Team agent란
|
||||
Team agent는 단일 계층적인 수직 구조를 넘어, 수평적이고 다양한 역할을 맡은 여러 독립 에이전트가 협의체(Crew/Team)를 구성하여 대화형 협력(Multi-agent Debate) 및 협상을 통해 목표를 완수하는 협동형 에이전트 구성 방식입니다.
|
||||
- **의견 충돌 및 합의**: 특정 설계안에 대해 서로 다른 관점의 에이전트들이 논쟁(Debate)을 벌이고, 최종적으로 조율된 결과를 PM 에이전트가 도출하는 식의 협력 모델
|
||||
- **협력적 의사결정**: 복잡한 문제에 대해 실시간으로 의견과 피드백을 교환하여 점진적으로 결과물의 품질 고도화
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## 구성 기술: TMUX · crewAI · LangGraph
|
||||
|
||||
- ### TMUX
|
||||
TMUX는 에이전트들의 독립적인 작업 공간을 제공하는 가상 터미널 관리 도구로, 백그라운드 내 장기 작업(Long-running task) 세션을 안정적으로 유지하고 AI 에이전트의 동작을 TUI로 실시간 모니터링 및 제어할 수 있도록 도와주는 소프트웨어입니다.
|
||||
- **에이전트별 독립 작업 공간 제공**: 각 에이전트 세션을 독립적인 tmux 윈도우나 패널에 격리하여 병렬로 실행할 수 있는 물리적 격리막 형성
|
||||
- **장기 실행 작업의 백그라운드 세션 유지**: SSH 연결이 끊어지거나 브라우저 세션이 끊겨도 tmux 세션 내부에서 구동되는 에이전트 작업은 유실 없이 백그라운드에서 계속 유지
|
||||
- **TUI 실시간 모니터링 및 제어**: CLI 코딩 에이전트나 멀티 에이전트들의 실행 과정을 사람이 TUI를 통해 실시간으로 관측(observe)하고 필요시 입력을 제공할 수 있도록 실시간 관측 및 제어 지원
|
||||
- *실제로 앞서 소개한 `multi-agent-mux` 스킬 데모가 이러한 TMUX 세션 관리 기능을 활용하여 설계된 멀티 에이전트 오케스트레이션 사례임*
|
||||
|
||||
- ### crewAI
|
||||
역할 기반(Role-based) 협업을 설계하는 데 특화된 프레임워크입니다. 각 에이전트에게 명확한 역할(Role), 목표(Goal), 배경 설명(Backstory)을 부여하고, 이들을 업무 프로세스(Sequential 또는 Hierarchical)에 따라 배치해 '크루(Crew)' 단위로 조율합니다.
|
||||
|
||||
- ### LangGraph
|
||||
컨텍스트 엔지니어링(Context Engineering)은 다중 에이전트 시스템에서 에이전트들 간의 대화 흐름, 전달되는 컨텍스트(State), 복잡한 제어 루프를 효율적으로 설계하고 유지하는 방법론적 학문입니다. 이를 구현하는 대표적인 상태 보존형 프레임워크가 LangGraph입니다.
|
||||
- **상태 보존 및 순환 제어**: 단순 선형적 체인 구조를 탈피하여, 에이전트 간의 루프(반복 검증), 조건부 분기(Conditional branching), 실패 시 롤백 등을 순환형 그래프(Cyclic Graph) 구조로 제어
|
||||
- **영속적 상태 관리**: 협업 과정에서 축적되는 다양한 상태 변화(State)를 중앙 저장소에서 추적 및 동기화하여 특정 노드가 실패하더라도 이전 상태부터 복구 및 재시작할 수 있는 환경 제공
|
||||
|
||||
- ### (참고) AutoGen, BeeAI
|
||||
Microsoft AutoGen과 IBM의 BeeAI도 멀티 에이전트 오케스트레이션을 지원하는 주요 프레임워크입니다.
|
||||
- **Microsoft AutoGen**: 대화형 에이전트 설계(Conversational Agentic Design)에 중점을 둔 프레임워크로, 에이전트 간 대화를 통해 코드를 실행하고 피드백을 주고받는 풍부한 동적 워크플로우 제공
|
||||
- **BeeAI**: 에이전트를 탐색, 실행, 공유할 수 있는 중앙 집중형 오픈소스 플랫폼으로 리눅스 재단(LF) 하위에서 ACP 표준 프로토콜을 백본으로 구축
|
||||
|
||||
|
||||
|
||||
## [사례] 실제 구현하며 겪은 문제점들
|
||||
|
||||
1. **Agent들과 각 Agent들의 세션 관리**
|
||||
- 다수의 에이전트와 그 아래에 동적으로 생성되는 subagent들의 생명주기(Lifecycle) 및 고유 식별자(UUID)를 동기화하고 상태를 지속적으로 보존하는 일관된 세션 관리 시스템 요구
|
||||
2. **에이전트 상호 탐색(Service Discovery)과 역할 식별**
|
||||
- 새로운 에이전트가 네트워크에 진입했을 때 어떤 에이전트가 어떤 과업을 처리할 수 있는지 동적으로 파악하는 기능 요구
|
||||
- **마스터 - 슬레이브(Master-Slave) 방식**: 중앙 오케스트레이터가 전권을 쥐고 세션을 직접 관리 및 명령하므로 통제는 쉬우나, 오케스트레이터의 에러가 시스템 전체의 단일 실패점(SPOF)이 될 위험 존재
|
||||
- **P2P 및 보고(P2P and Report) 방식**: 에이전트들이 동등한 위치에서 협상하며 자율적으로 탐색하고, 작업 결과를 기록 보관소에 보고하는 방식이나 네트워크 관리 비용 상승 우려
|
||||
3. **실시간 메시징과 이벤트 예외 처리의 복잡성**
|
||||
- 태스크 위임 완료 후, 작업 결과와 성공/실패 여부를 교환하는 통신 채널이 중단되거나 유실될 수 있는 위험성 대두
|
||||
- **송신/수신 주체의 돌발 종료**: 위임 후 송신 주체가 다운되었다가 재가동(Restart)되는 경우, 비동기 알람이 공중분해되어 전체 협업 루프 중단
|
||||
- **무한 대기 및 리소스 누수(Deadlock & Resource Leak)**: 작업을 위임받은 서브에이전트가 예외 이벤트 없이 비정상 종료(Silent death)할 경우 부모 에이전트가 무한 대기(Blocking) 상태에 빠지는 문제 발생
|
||||
|
||||
## [사례] Multi Agent Orchestration의 장점
|
||||
1. **프롬프트의 간소화 및 루프 엔진의 진화**
|
||||
- 기존의 길고 장황한 단일 "Super Prompt" 엔지니어링 시대에서 벗어나, 에이전트를 구동하고 제어하는 자율 루프(Loop Architecture) 설계 중심으로 패러다임 이동
|
||||
- *PSPDFKit 창업자이자 오픈소스 AI 에이전트 프로젝트인 OpenClaw의 크리에이터인 페터 슈타인베르거(Peter Steinberger, 2026년 초 OpenAI 합류)는 **"코딩 에이전트에 프롬프트를 더 넣지 말고, 에이전트를 구동하는 루프를 설계하라"**(Stop prompting your coding agents; start designing loops that prompt your agents)고 강조한 바 있음*
|
||||
- 멀티 에이전트 구조에서는 작업 지시 PM 에이전트, 작업 수행 Worker 에이전트, 유효성 검증 Reviewer 에이전트로 나뉨으로써 프롬프트가 단편적이고 명료해지는 이점 확보
|
||||
2. **컨텍스트 설명 불필요 (Context-Free Sharing)**
|
||||
- 공유 작업 환경(Shared Workspaces)과 Git 같은 버전 관리 시스템을 에이전트들이 공유하므로, 새로 합류한 에이전트에게 변경 이력이나 현재 맥락을 다시 텍스트로 설명하느라 불필요한 토큰과 대기 시간 낭비 방지
|
||||
3. **이종 모델 피드백을 통한 고품질 산출물 교차 검증**
|
||||
- 특정 한 모델 계열만으로 결과물을 짜고 동일한 계열에 검토를 시키는 것보다, 서로 다른 아키텍처와 특징을 지닌 이종 모델(Gemini 작성 ➡️ Claude 검토 등) 간 상호 보완할 때 결과물의 신뢰성 극대화 및 보이지 않는 맹점 상호 보완
|
||||
4. **비용 효율적인 토큰 분배 (Cost Optimization)**
|
||||
- 쉬운 코드 생성이나 정보 검색은 경량화된 저비용 모델(예: Gemini Flash 세대)을 탑재한 에이전트에 분산 위임하고, 고난도의 논리적 추론이 필요한 부분에만 최상위 고비용 모델을 탑재한 에이전트를 적절히 매칭함으로써 종합적인 API 비용 효율적 제어
|
||||
|
||||
## [요구사항] 성공적인 구현을 위해 필요한 것들 (What We Need?)
|
||||
앞의 문제점과 장점을 종합하면, 성공적인 멀티 에이전트 오케스트레이션 구현을 위해서는 다음 5가지 구성요소가 필수적이며, 이 요구사항들이 4장(표준)과 5장(인프라)에서 소개할 솔루션의 선정 기준이 됩니다.
|
||||
|
||||
1. **Agent 간 작업 환경 공유 (A2A의 Agent Card 기반)**
|
||||
- 특정 에이전트에게 태스크를 안전하게 위임하고 위임받기 위해선, 각 에이전트 카드를 통해 서로의 역할, 엔드포인트, 입력 명세 스키마를 신뢰성 있는 방식으로 동기화
|
||||
2. **에이전트 작동 인프라스트럭처 (Agent Working Infrastructure)**
|
||||
- 에이전트들이 통신에 사용할 서비스 주소와 포트를 동적으로 조회할 수 있는 서비스 디스커버리 기능 및 자동 라우팅 체계 내재
|
||||
3. **일관성 있는 워크플로우 추적 및 공유 (Issue & Workflow Tracking)**
|
||||
- 서로 다른 에이전트가 동일한 작업을 재수행할 때 동일한 프로세스와 출력을 일관되게 얻을 수 있도록 워크플로우 사양이 제어되어야 함. 또한 에러나 중간 정지가 일어났을 때 복구 및 추적이 용이하도록 규격화된 이슈 추적 인터페이스 마련
|
||||
4. **고성능 양방향 메시징 시스템 (Advanced Messaging System)**
|
||||
- 고용량의 코드 블록, 이미지 및 멀티모달 센서 데이터 등을 대량으로 빠르고 정확하게 공유하기 위해서는 기존의 MQTT나 단순 메시지 큐(MQ) 방식은 토픽 세분화와 페이로드 크기 한계로 인해 통신 병목을 겪을 수밖에 없음
|
||||
- 단편적인 이벤트 알림만 전송하는 구조에서 탈피하여 상세 에러 트레이스, 상태 구조체, 이미지 바이너리 등을 한꺼번에 담을 수 있는 풍부한 페이로드 지원 메시징 규격이 필수적임. 나아가 대용량 멀티모달 푸시(Push)와 양방향 스트리밍을 지원하기 위해 HTTP/3의 멀티 스트리밍 등 고성능 통신 수반
|
||||
5. **작업 및 태스크 관리 시스템 (Job & Task Lifecycle Controller)**
|
||||
- 하나의 부모 작업을 하위 스크럼(Scrum) 단위로 쪼개어 서브에이전트들에게 뿌려주는 라이프사이클 관리 기능이 있어야 함. 각 서브에이전트의 생성부터 소멸까지의 메시징 토픽과 임시 토큰을 정리해야 하며, 이 과정에서 부하를 고르게 배분하고 실력 있는 에이전트를 매칭하기 위한 로드 밸런싱 기법 병행
|
||||
|
||||
|
||||
|
||||
### 🔗 요구사항과 기술 솔루션 매핑 (Bridge Mapping)
|
||||
- **요구사항 1(작업 환경 공유)** 및 **요구사항 2(서비스 디스커버리)**는 상호 연동 장벽을 허물기 위해 **§4 에이전트 상호운용성 표준(ACP/A2A)**을 통해 규격화된 표준 명세로 제공
|
||||
- **요구사항 4(고성능 양방향 메시징)** 및 **요구사항 5(태스크 라이프사이클/로드밸런싱)**는 고부하 대규모 실시간 분산 환경에서 물리적 네트워크 및 런타임 최적화를 실현하는 **§5 gRPC 백본 인프라**를 통해 해결
|
||||
- **요구사항 3(워크플로우 추적)**은 표준 명세(Agent Card)의 추적 스키마와 물리 인프라(gRPC liveness probe 및 트레이싱 도구) 양대 측면에 모두 걸쳐 상호 보완적 제어
|
||||
|
||||
---
|
||||
@@ -0,0 +1,21 @@
|
||||
---
|
||||
marp: true
|
||||
---
|
||||
|
||||
# 4. 에이전트 상호운용성 확보를 위한 표준: ACP, A2A
|
||||
|
||||
## 왜 이종 에이전트 연동 표준이 필요한가
|
||||
3장에서 정의한 요구사항 중 **'Agent 간 작업 환경 공유'(요구사항 1)**와 **'서비스 디스커버리'(요구사항 2)**는 특정 벤더의 독점적 구현이 아닌 개방형 표준 규격을 통해 해결되어야 합니다. 그 핵심 해답이 되는 오픈 규격 표준이 바로 ACP와 A2A입니다.
|
||||
|
||||
서로 다른 벤더가 제작하고 각기 다른 아키텍처로 설계된 이종 에이전트들이 복잡한 맞춤형 결합 코드(Glue code) 없이도 서비스 검색, 역할 전파 및 태스크 위임을 유연하게 수행하려면 통일된 오픈 통신 규약이 필수적입니다. 표준 규격을 통하면 에이전트 생태계의 결합도가 낮아져 이종 에이전트 간의 동적 협업 네트워크 구축 속도가 비약적으로 향상됩니다.
|
||||
|
||||
## ACP (Agent Communication Protocol)
|
||||
IBM Research가 자사의 BeeAI 프레임워크 연동을 지원하기 위해 **2025년 3월** 발표했던 오픈 표준 에이전트 통신 인터페이스입니다. 이종 에이전트 간의 서비스 발견(Service Discovery), 상호작용 방법 협상, 태스크 위임 프로세스를 최초로 규격화하였습니다. 이후 **2025년 8월 27일** 공식 깃허브 저장소가 아카이빙되며 Linux Foundation AI & Data 하위의 A2A(Agent-to-Agent) 프로토콜로 공식 통합 및 병합되어 단일 연합 생태계를 형성하였습니다.
|
||||
|
||||
## A2A와 Agent Card
|
||||
- ### A2A (Agent-to-Agent) 프로토콜
|
||||
Google과 50여 개 파트너사들이 **2025년 4월** 공동 발표하고 **2025년 6월** Linux Foundation에 기증한 이종 에이전트 간 표준 메시지 교환 및 상태 추적용 통합 통신 오픈 표준입니다. 서로 다른 벤더가 구현한 에이전트나 다양한 아키텍처 기반의 에이전트가 복잡한 결합 코드 없이도 협업 메시지를 교환하고 상태 추적 지원
|
||||
- ### Agent Card (에이전트 카드)
|
||||
A2A 생태계에서 에이전트의 기능 명세서 역할을 하는 JSON 포맷의 표준 규격서입니다. 이는 **요구사항 1(작업 환경 공유)**을 물리적 파일 수준에서 구체화하는 핵심 메커니즘으로 기능함. 에이전트 카드에는 해당 에이전트의 명칭, 제공 가능한 역량(Capabilities), 호출 엔드포인트 정보, 요청 시 통과해야 하는 보안 인증 사양(Authentication) 등이 명시되어 있어 서비스 검색 시스템(Service Discovery)이 에이전트의 역할을 실시간으로 탐색할 수 있도록 보장. 주로 `/.well-known/agent-card.json` 경로에 배포
|
||||
|
||||
---
|
||||
@@ -0,0 +1,25 @@
|
||||
---
|
||||
marp: true
|
||||
---
|
||||
|
||||
# 5. 지능형 사물인터넷(AIoT) 및 gRPC 기술 동향
|
||||
|
||||
## AIoT 환경에서 멀티 에이전트가 유용한 이유
|
||||
스마트 팩토리, 스마트 팜 등 다수의 물리 디바이스로 구성된 Physical 계층과 엣지 연산 계층이 복잡하게 혼재하는 AIoT 환경에서는 단일 클라우드 에이전트만으로 지연 시간 제어와 로컬 예외 상황 대처를 감당하기 어렵습니다. 따라서 센서 수집, 이상 탐지, 자율 제어 등의 고유 역할을 여러 에이전트에 자율 분산 배치하여 협업 기반의 로컬 제어를 실현해야 합니다. 이를 통해 네트워크 연결 차단 시에도 독립 제어가 가능하며, 컴퓨팅 자원이 극도로 제한된 엣지 인프라 하에서도 실시간 협업 자율 제어를 달성할 수 있습니다.
|
||||
|
||||
## Why we need gRPC?
|
||||
3장 요구사항 중 **'고성능 양방향 메시징'(요구사항 4)**과 **'태스크 라이프사이클 관리'(요구사항 5)**를 물리적 인프라 수준에서 충족하는 강력한 통신 백본이 gRPC (Google Remote Procedure Call) 프로토콜입니다.
|
||||
|
||||
1. **A2A 프로토콜과의 높은 호환성 및 스마트 팩토리/팜 최적화**
|
||||
- 스마트 팜, 스마트 팩토리와 같은 AIoT 서비스를 타겟으로 하는 개발 단계에서 대역폭이 극단적으로 제약되는 센서 디바이스는 MQTT/CoAP 등을 혼용하되, 상위 게이트웨이 및 연산 계층에서는 gRPC가 강력하고 최적의 제어 프로토콜로 작동
|
||||
2. **고성능 멀티 모달 바이너리 스트리밍 및 Pub/Sub 네이티브 지원**
|
||||
- HTTP/2 또는 HTTP/3 기반으로 작동하여 양방향 스트리밍, Request/Response, Pub/Sub 통신 방식을 단일 포트에서 완벽히 수행하며 대용량 멀티모달 바이너리를 고속으로 처리
|
||||
- 마이크로서비스 아키텍처(MSA)에서 메인 통신 규격으로 활용되므로 타 시스템으로의 이식 및 연동 성능 탁월
|
||||
3. **구조화된 직렬화 기반의 효율적 태스크 생명주기 및 부하 분산**
|
||||
- Protobuf를 통한 강력한 스키마 기반 직렬화로 통신 메시지 처리 효율을 JSON 파싱 대비 수배 이상 향상하고 메모리 오버헤드 극소화
|
||||
- 이미 검증된 Envoy, Kubernetes gRPC liveness probe 등의 기성 인프라를 활용하여 에이전트 라이프사이클 감시 체계를 최소한의 공수로 구축 가능
|
||||
|
||||
## 기술 동향 요약
|
||||
최근 AIoT 에이전트 인프라 환경은 물리적 센서 단말에서 대역폭을 극단적으로 아끼기 위해 경량 프로토콜(MQTT/CoAP)을 사용하고, 상위 연산 및 오케스트레이터 게이트웨이 계층에서는 고성능 프로토콜(gRPC)을 사용하여 계층별 완충 혼용을 유도하는 설계가 주류 트렌드로 자리잡고 있습니다. 이러한 하이브리드 프로토콜 아키텍처는 마이크로서비스 아키텍처(MSA)에 뛰어난 이식 및 확장 성능을 보장합니다.
|
||||
|
||||
---
|
||||
@@ -0,0 +1,11 @@
|
||||
---
|
||||
marp: true
|
||||
---
|
||||
# 특강 최종 요약
|
||||
|
||||
## AI Multi-Agents 오케스트레이션 기술 동향 및 사례
|
||||
- **AI 에이전트 구현을 위한 3대 핵심 엔지니어링 기법**: 프롬프트 엔지니어링, 컨텍스트 엔지니어링, 하네스 엔지니어링을 통하여 단일 에이전트 설계 및 도구 연동 제어
|
||||
- **AI Agent 기능 확장**: MCP(Model Context Protocol) 및 SKILL 프레임워크를 기반으로 클라이언트-서버 구조로 동적인 도구(Tools) 및 데이터(Resources) 호출 인터페이스 확장
|
||||
- **멀티 에이전트 협업 체계 및 오케스트레이션 인프라**: 싱글 에이전트의 한계(Lost in the middle, 환각)를 극복하기 위해 TMUX 세션 관리 TUI, crewAI 역할 협업, LangGraph 상태 보존 그래프를 결합한 분산 협업 구조 구축
|
||||
- **에이전트 상호운용성 확보를 위한 표준**: 벤더 종속 없이 협업 위임을 실현하기 위해 ACP와 A2A 프로토콜 표준 규격 및 Agent Card 기반의 상호 탐색 환경 통일
|
||||
- **지능형 사물인터넷 (AIoT) 및 gRPC 기술 동향**: 물리 및 엣지 단말 자원 한계를 보완하기 위한 경량 프로토콜(MQTT/CoAP)과 고성능 양방향 메시징 gRPC를 계층별 완충 혼용하여 MSA 기반의 실시간 자율 분산 제어망 완성
|
||||
@@ -0,0 +1,71 @@
|
||||
# Implementation Plan — 0_intro 구어체 검토·개선 루프 (Rev.2 / Job 0fa577fa)
|
||||
|
||||
> **Rev.2 변경 요약 (Creator 이의제기 반영, Challenge Report 58a51e54)**
|
||||
> - **경로 정정**: 대상 파일 경로를 전부 저장소 루트 기준 전체 경로로 통일했다. Rev.1 §6의 축약 표기(`chapters/0_intro_script.md`)는 루트에 `chapters/`가 없어 자동화 탐색 시 File Not Found를 유발할 수 있었다.
|
||||
> - **통합 덱 동기화 단계 신설**: 통합 발표 자료인 `lib/make_slide_for_260724_seminar/SLIDE.md`는 챕터 파일들을 합친 최종 산출물임을 확인했다(0장 내용 포함, 328줄). 챕터만 고치고 통합 덱을 "변경 금지"로 묶어두면 최종 발표 자료에 개선 전 문장이 방치되는 모순이 맞다. 이에 **루프 중에는 동결, 최종 PASS 직후 병합·재동기화**하는 Step 5를 신설하고 완료 기준을 갱신했다.
|
||||
> - 어투 기준(§2)과 초기 발견 사항(§3)은 Rev.1과 동일하다.
|
||||
|
||||
> 이전 태스크(SLIDE.md 5개 장 보완, ~Rev.4)는 커밋 4d6423e로 완결(이력은 git에 보존), 이후 덱이 `chapters/` 구조로 재편됨. 본 계획서는 새 태스크(0_intro 어투 검토 루프)를 다룬다.
|
||||
|
||||
## 1. 목표
|
||||
|
||||
`lib/make_slide_for_260724_seminar/chapters/0_intro.md`(슬라이드 내용 구성 노트)와 `lib/make_slide_for_260724_seminar/chapters/0_intro_script.md`(발표 대본)를 검토하여, **발표자료 작성용 노트라는 목적에 맞게 쉽고 풀어쓴 구어체 문장**으로 다듬는다. Creator 수정 → Reviewer 판정 루프를 개선사항이 없을 때까지 반복하고, 최종 PASS 후 통합 덱에 병합한다.
|
||||
|
||||
## 2. 어투·품질 기준 (Definition of Done 체크리스트)
|
||||
|
||||
Reviewer는 아래 기준으로 판정한다:
|
||||
|
||||
1. **구어체 일관성**: 노트는 풀어쓴 설명체(-입니다/-합니다), 대본은 친절한 구어체 존댓말로 통일. 딱딱한 개조식·번역투 문장 없음.
|
||||
2. **한 문장 한 호흡**: 지나치게 긴 문장(대략 80자 이상, 절 3개 이상 중첩)은 2문장 이상으로 분할.
|
||||
3. **용어 풀이**: 영어 전문용어(Scaffolding, Harness, Test-time Compute 등)는 첫 등장 시 한 줄 우리말 풀이를 동반. "쉬운 비유" 슬라이드에는 코드 표기(`PASS` 등) 같은 기술 용어 침투 금지.
|
||||
4. **슬라이드-대본 정합성**: 대본의 슬라이드 번호·제목·핵심 용어가 노트와 일치.
|
||||
5. **의미 보존**: 어투 개선 과정에서 기술적 사실이나 논지 왜곡 없음.
|
||||
6. **Surgical**: 루프 단계에서는 두 대상 파일 외 무변경 (통합 덱 병합은 Step 5에서만 허용).
|
||||
|
||||
## 3. 현황 진단 — 초기 발견 사항 (Creator 수정 목록)
|
||||
|
||||
### `lib/make_slide_for_260724_seminar/chapters/0_intro.md`
|
||||
- **F1 (구조·정합, 필수)**: 파일 상단의 레거시 front-matter(title/description)와 동기화 NOTE 주석은 구(舊) 루트 SLIDE.md 시절의 잔재로, **챕터 파일에서는 사실이 아니다**. 형제 챕터(`1_engineering.md`)와 동일하게 `marp: true`만 남기고 title/description/NOTE를 제거한다. ⚠️ 단, 이 제거는 **챕터 파일에만 해당**한다 — 통합 덱 `SLIDE.md`의 front-matter와 NOTE는 그 위치에서는 여전히 유효하므로(paper_draft 사본 실존 확인) Step 5 병합 시 보존해야 한다.
|
||||
- **F2 (어투)**: `## 패러다임 쉬프트` 절의 2·3번 bullet처럼 한 문장에 절이 3개 이상 중첩된 장문이 있다. 기준 2에 따라 분할한다.
|
||||
- **F3 (용어)**: `Scaffolding`, `Test-time Compute`, `Harness`가 풀이 없이 등장 — 첫 등장 시 짧은 우리말 풀이를 추가. 🚗 비유 슬라이드의 "합의 형성" bullet에 있는 `` `PASS`/`NOT PASS` `` 코드 표기는 비유 톤과 어긋나므로 "통과/반려 판정을 모아 최종 결정을 내리는" 식의 풀어쓴 표현으로 교체.
|
||||
- **F4 (표기 통일)**: 제목의 "패러다임 쉬프트"는 외래어 표기법상 "시프트"이며, 같은 문서 앞부분에서는 "패러다임 전환"을 사용 중 — "패러다임 전환"으로 통일 권장(영문 부제 "Model eats the Scaffolding"은 유지).
|
||||
|
||||
### `lib/make_slide_for_260724_seminar/chapters/0_intro_script.md`
|
||||
- **F5 (어색한 자기소개)**: Slide 1 대본 "오늘 세미나 발표를 맡은 발표자입니다"는 placeholder 티가 나는 어색한 문장 — "안녕하세요, 오늘 특강을 진행하게 된 ○○○입니다"처럼 자연스러운 인사로 수정(이름은 placeholder 허용).
|
||||
- **F6 (오해 소지 마무리)**: Slide 7 대본 말미의 "감사합니다"는 발표 전체가 끝난 듯한 인상을 준다. 인트로 챕터의 끝이므로 "그럼 바로 시작하겠습니다" 같은 전환 멘트로 교체.
|
||||
- **F7 (호흡)**: Slide 3·7 대본에 3줄 이상 이어지는 장문이 있어 낭독 호흡이 길다 — 기준 2에 따라 문장 분할.
|
||||
- **F8 (정합성)**: Slide 5 대본의 "의사결정 통제"와 노트의 "합의 형성(Consensus)" 용어가 어긋난다 — 한쪽으로 통일(권장: 둘 다 "합의 형성" 계열, F3 수정과 연동).
|
||||
|
||||
## 4. 작업 절차 (수정-리뷰 루프)
|
||||
|
||||
1. **Creator**: §3의 F1~F8을 두 대상 파일에 반영한다. 목록 밖의 임의 개서(전면 재작성)는 금지 — 지적 항목 중심의 수술적 수정. 이 단계에서 통합 `SLIDE.md`는 건드리지 않는다.
|
||||
2. **Reviewer**: §2 체크리스트 6개 기준으로 두 파일을 재검토한다. 신규 발견 사항이 있으면 F-번호를 이어 붙여 목록화하고 `[VERDICT: NOT PASS]`로 반려한다.
|
||||
3. 반려 시 Creator는 신규 목록만 반영하고 2로 돌아간다. **Reviewer가 신규 발견 없음으로 `[VERDICT: PASS]`를 내면 루프 종료 → Step 5로 진행.**
|
||||
|
||||
## 5. 최종 PASS 후 통합 덱 병합 (Rev.2 신설)
|
||||
|
||||
1. `lib/make_slide_for_260724_seminar/SLIDE.md`의 0장(인트로) 구간 — 첫 슬라이드(덱 제목)부터 `## 패러다임 …(Model eats the Scaffolding)` 절 끝(1장 시작 직전)까지 — 을 확정된 `chapters/0_intro.md` 내용으로 교체한다.
|
||||
- 이때 통합 덱의 **front-matter(title/description/marp)와 NOTE 주석은 보존**한다 (챕터 파일에서 제거된 것과 무관하게 통합 덱 위치에서는 유효).
|
||||
- 1~6장 구간은 바이트 단위로 무변경이어야 한다.
|
||||
2. `cp lib/make_slide_for_260724_seminar/SLIDE.md lib/make_slide_for_260724_seminar/paper_draft/SLIDE.md`로 재동기화하고 `diff -q`로 완전 일치를 확인한다.
|
||||
3. 커밋(제안 메시지: `docs: refine 0_intro chapter and script into plain conversational tone`). 커밋 대상: 두 챕터 파일 + 통합 `SLIDE.md` + `paper_draft/SLIDE.md` + 본 계획서.
|
||||
|
||||
## 6. 완료 기준 (최종 판정)
|
||||
|
||||
1. §3의 F1~F8이 모두 반영되었거나, 반영하지 않은 항목에 대해 타당한 사유가 기록되어 있다.
|
||||
2. §2 체크리스트 6개 기준을 모두 통과한다 (Reviewer PASS).
|
||||
3. 통합 `SLIDE.md`의 0장 구간이 확정본 `0_intro.md`와 내용 일치하고, front-matter/NOTE는 보존되었으며, 1~6장 구간은 무변경이다.
|
||||
4. `paper_draft/SLIDE.md`가 통합 `SLIDE.md`와 `diff -q` 완전 일치한다.
|
||||
5. `chapters/1_*.md` ~ `6_*.md` 및 그 외 파일은 변경되지 않았다.
|
||||
6. 루프 종료 커밋이 존재하며 의도한 파일만 포함한다.
|
||||
|
||||
## 7. 대상 파일 (전부 저장소 루트 기준 경로)
|
||||
|
||||
- 루프 중 수정: `lib/make_slide_for_260724_seminar/chapters/0_intro.md`, `lib/make_slide_for_260724_seminar/chapters/0_intro_script.md`
|
||||
- PASS 후 병합(Step 5에서만): `lib/make_slide_for_260724_seminar/SLIDE.md`, `lib/make_slide_for_260724_seminar/paper_draft/SLIDE.md`
|
||||
- 변경 금지: `lib/make_slide_for_260724_seminar/chapters/1_engineering.md` ~ `6_summary.md`, `lib/make_slide_for_260724_seminar/lecture_summary.md`
|
||||
|
||||
## 부록 — 리비전 이력
|
||||
|
||||
- Rev.1 (Job 69360718): DoD 6기준 + 초기 발견 F1~F8 + 수정-리뷰 루프 수립.
|
||||
- Rev.2 (Job 0fa577fa): Creator 이의제기(58a51e54) 수용 — 경로 전체 표기 통일, 최종 PASS 후 통합 덱 병합·재동기화 Step 5 신설, F1에 통합 덱 front-matter 보존 단서 추가.
|
||||
@@ -0,0 +1,58 @@
|
||||
# AI Multi-Agents 오케스트레이션 기술 동향 및 사례
|
||||
|
||||
## 특강 내용 구성
|
||||
|
||||
* **AI 에이전트 구현을 위한 3대 핵심 엔지니어링 기법**
|
||||
* **AI 모델(LLM)과 AI 에이전트(AI Agent)의 개념 차이**: 단순 텍스트 입력을 받아 다음 단어를 예측하고 응답을 생성하는 대화형 모델(Chatbot)과 달리, 주어진 최종 목표(Goal)를 달성하기 위해 환경을 스스로 인식하고 자율적으로 행동하는 AI 에이전트의 개념.
|
||||
* **에이전트 구현을 위한 3대 핵심 엔지니어링 기법**:
|
||||
* *프롬프트 엔지니어링 (Prompt Engineering)*: 에이전트에게 명확한 역할 페르소나와 추론 가이드라인을 설계하고, 효율적인 추론 경로를 유도하기 위해 프롬프트 구조와 예시(Few-shot)를 최적화하는 기법.
|
||||
* *컨텍스트 엔지니어링 (Context Engineering)*: 대화 상태(State)와 흐름을 보존하며, 외부 데이터베이스나 기억(Memory) 장치로부터 필요한 정보를 적시에 모델의 컨텍스트 윈도우에 효율적으로 바인딩하고 공급하는 기술.
|
||||
* *하네스 엔지니어링 (Harness Engineering)*: 에이전트가 계산기, 웹 브라우저, 외부 API 및 파일 시스템 등의 물리적 도구(Tools/Tool Use)에 안전하고 유연하게 연결되어 명령을 실행할 수 있도록 연결 고리를 결합하는 도구 연동 인터페이스 기술.
|
||||
|
||||
* **AI Agent 기능 확장**: MCP & SKILL
|
||||
* **MCP, CLI 알아보기**:
|
||||
* **MCP (Model Context Protocol)**: Anthropic이 **2024년 11월** 발표한 오픈 소스 프로토콜로, AI 애플리케이션이 로컬/원격의 도구(Tools), 데이터(Resources), 프롬프트 템플릿을 통일된 규격으로 호출할 수 있는 인터페이스.
|
||||
* **CLI(Claude Code 등) 알아보기**: Claude Code처럼 터미널에서 직접 구동되어 로컬 컴퓨터의 필요한 모듈/소프트웨어를 바탕으로 작업 디렉터리에서 직접 파일을 읽고 수정 및 실행하는 코딩 에이전트의 작동 원리. (클라우드 기반 비서인 Claude Cowork와의 작동 방식 차이 비교)
|
||||
* **SKILL 추가해보기**: 단순 프롬프트 지시를 넘어, 실행 코드 + 도구 명세 스키마(Tool Schema) + 사용 예시(Few-shot)를 하나로 패키징한 자율 확장 도구 모음.
|
||||
* *개념*: 상황에 따라 필요한 기술을 동적으로 로드해 쓰고, 완료 후 반환하는 모듈화 방식.
|
||||
* *효과*: 텍스트 생성이라는 언어 모델의 한계를 넘어 파일 제어·서버 배포·물리 데이터 수집 등 실질적 업무 대행 능력을 에이전트에 부여하는 효과.
|
||||
* *대표 사례*: 코드베이스 탐색·치환·검증·커밋 자동화, 헤드리스 브라우저 기반 스크래핑, 클라우드·서버리스 배포 제어, 학술/도메인 특화 API(ChEMBL, PubMed, arXiv 등) 연동.
|
||||
|
||||
* **멀티 에이전트 협업 체계 및 오케스트레이션 인프라**: TMUX, crewAI, LangGraph
|
||||
* **싱글 에이전트의 한계**: 대규모 컨텍스트를 다룰 때 중간 정보가 누락되는(Lost in the middle) 현상과 여러 도구를 다룰 때 발생하는 환각(Hallucination) 증가. 역할 집중으로 인한 프롬프트의 장황화, 멀티태스킹 오류 및 컨텍스트 인지 한계의 문제점.
|
||||
* **멀티 에이전트란 무엇이고, 어떤 장점을 가지는가?**: 페르소나와 전문 도구를 갖춘 여러 에이전트가 협력 네트워크를 형성해 복잡한 목표를 조율·분할 해결하는 구조.
|
||||
* *역할 세분화(Role Specialization)*: 각 에이전트에 한정된 역할(PM, Developer, QA, Researcher 등)과 타겟 도구만 부여하여 노이즈를 제어하고 추론 정확도를 향상시키는 효과.
|
||||
* *교차 검증*: 서로 다른 이종 모델(Gemini 작성 → Claude 검토 등) 간의 비평 루프를 통한 맹점(Blind spot) 상호 보완 및 결과물 신뢰성 극대화.
|
||||
* **멀티 에이전트를 구성하기 위한 기술들**:
|
||||
* **TMUX**: 에이전트들의 독립적인 작업 공간을 제공하는 가상 터미널 관리 도구로, 백그라운드 내 장기 작업(Long-running task) 세션을 안정적으로 유지하고 AI Agent의 동작을 TUI로 실시간 모니터링 및 제어할 수 있도록 도와주는 소프트웨어.
|
||||
* **crewAI**: 각 에이전트에 역할(Role)·목표(Goal)·배경(Backstory)을 부여하고, 순차(Sequential) 및 계층(Hierarchical) 프로세스로 '크루(Crew)' 단위를 조율하는 역할 기반 협업 설계를 도와주는 소프트웨어 모듈.
|
||||
* **LangGraph**: 단순 선형 체인을 넘어 루프(반복 검증)·조건부 분기·실패 시 롤백을 순환형 그래프(Cyclic Graph) 구조로 관리하고, 중앙 저장소의 상태 추적 및 동기화를 통해 예외 발생 시 이전 상태부터 복구하는 상태 보존형 흐름을 제어하기 위해 사용하는 소프트웨어.
|
||||
|
||||
|
||||
* **에이전트 상호운용성 확보를 위한 표준**: ACP, A2A
|
||||
* **왜 이종 에이전트 연동 표준이 필요한가?**: 서로 다른 벤더·아키텍처로 설계된 에이전트들이 복잡한 결합 코드 없이 서비스 검색, 역할 전파 및 태스크 위임을 수행하기 위한 개방형 공통 통신 규격의 필요성.
|
||||
* **ACP(Agent Communication Protocol)**: IBM Research가 **2025년 3월** 발표한 오픈 표준으로, 서비스 발견·상호작용 협상·태스크 위임을 규격화하고 이후 **2025년 8월 27일** Linux Foundation A2A 프로토콜로 공식 통합·병합된 표준 인터페이스.
|
||||
* **A2A(Agent-to-Agent) 프로토콜**: Google과 파트너사들이 **2025년 4월** 공동 발표하고 **2025년 6월** Linux Foundation에 기증한 이종 에이전트 간 표준 메시지 교환 및 상태 추적용 통합 통신 오픈 표준.
|
||||
* **에이전트 카드(Agent Card)**: A2A 생태계에서 에이전트의 기능 명세서 역할을 하는 JSON 포맷 규격서.
|
||||
* *명세 항목*: 에이전트 명칭, 제공 역량(Capabilities), 호출 엔드포인트 정보, 보안 인증 사양(Authentication) 등.
|
||||
* *역할*: 서비스 검색 시스템(Service Discovery)이 에이전트의 역할을 실시간으로 탐색할 수 있도록 지원하는 기능.
|
||||
* *배포*: 주로 `/.well-known/agent-card.json` 경로에서 탐색 가능하도록 배포됨.
|
||||
|
||||
* **지능형 사물인터넷 (AIoT) 및 gRPC 기술 동향**
|
||||
* **AIoT 환경에서 멀티 에이전트가 유용한 이유**: 스마트 팩토리·스마트 팜 등 다수의 기기로 구성된 Physical 계층과 엣지 연산 계층이 혼재하는 환경에서 센서 데이터 수집·이상 탐지·자율 제어 등의 역할을 분산 배치하여 자원 제약 하에서도 협업 기반의 자율 제어를 달성하기 위한 연구/기술 동향.
|
||||
* **고성능 양방향 메시징(gRPC 등)의 중요성**:
|
||||
* 초경량 센서 디바이스 계층의 MQTT/CoAP 혼용 및 상위 엣지 연산 계층의 gRPC 기반 자율 통합 제어 백본 레이어 설계 기법.
|
||||
* HTTP/2 및 HTTP/3 기반으로 양방향 스트리밍, Request/Response, Pub/Sub 통신 스타일을 단일 포트에서 소화하여 대용량 멀티모달 바이너리를 고속으로 전송하는 성능.
|
||||
* Protobuf 기반의 직렬화 처리를 통한 메모리 최적화 및 Envoy, Kubernetes gRPC liveness probe 등의 인프라를 활용한 에이전트 라이프사이클 감시 체계 구축의 용이성.
|
||||
* **기술 동향 요약**: 자원 제약 환경 내 경량 프로토콜(MQTT/CoAP)과 고성능 프로토콜(gRPC)의 계층별 완충 혼용 트렌드 및 MSA 이식 확장성.
|
||||
|
||||
---
|
||||
|
||||
## 📌 특강 최종 요약 (핵심 요약)
|
||||
|
||||
### <AI Multi-Agents 오케스트레이션 기술 동향 및 사례>
|
||||
* **AI 에이전트 구현을 위한 3대 핵심 엔지니어링 기법**: 프롬프트, 컨텍스트, 하네스 엔지니어링
|
||||
* **AI Agent 기능 확장**: MCP & SKILL
|
||||
* **멀티 에이전트 협업 체계 및 오케스트레이션 인프라**: HERDR, crewAI, LangGraph
|
||||
* **에이전트 상호운용성 확보를 위한 표준**: ACP, A2A
|
||||
* **지능형 사물인터넷 (AIoT) 및 gRPC 기술 동향**
|
||||
@@ -0,0 +1,409 @@
|
||||
---
|
||||
title: AI Multi-Agents 오케스트레이션 기술 동향 및 사례
|
||||
description: AI 에이전트의 핵심 기법부터 MCP/SKILL 확장, TMUX/crewAI/LangGraph 오케스트레이션 인프라, ACP/A2A 상호운용성 표준, AIoT/gRPC 동향까지 다루는 특강 발표자료용 문서입니다.
|
||||
marp: true
|
||||
---
|
||||
<!-- NOTE: 이 문서의 동기화 사본이 paper_draft/SLIDE.md에 존재합니다. 이미지 상대경로는 루트 기준이므로 렌더링은 루트 SLIDE.md로 수행하세요. -->
|
||||
|
||||
# AI Multi-Agents 오케스트레이션 기술 동향 및 사례
|
||||
### 정적 AI 모델에서 자율적 AI 에이전트로의 패러다임 전환
|
||||
|
||||
---
|
||||
|
||||
## 🔍 이 발표에서 다루고 싶은 핵심 화두
|
||||
|
||||
최근 AI 분야에서 가장 뜨거운 화두는, 단순히 사용자의 질문에 답을 하는 **정적 AI 모델(LLM)**을 넘어 스스로 목적을 가지고 움직이는 **자율형 AI 에이전트(AI Agent)**로의 패러다임 전환입니다.
|
||||
|
||||
우리가 흔히 쓰는 AI 모델이 똑똑하게 생각하고 답변을 생성하는 '지능 엔진'이라면, AI 에이전트는 그 지능에 자율성과 행동력, 그리고 다른 에이전트와의 협업 능력까지 결합한 실제 '행동의 주체'라고 볼 수 있습니다.
|
||||
|
||||
오늘 발표에서는 단순한 AI 모델을 자율적인 에이전트로 업그레이드하는 구체적인 엔지니어링 방법론부터 시작하여, 여러 에이전트들이 유기적으로 협업하는 오케스트레이션 인프라와 산업 표준 기술 동향을 아주 쉽게 풀어보려 합니다.
|
||||
|
||||
---
|
||||
|
||||
### 💡 구체적 사례 비교: "멀티 에이전트 관련 연구를 조사해줘"
|
||||
|
||||
사용자가 **"멀티 에이전트 관련 최신 연구 동향을 조사하고 보고서로 저장해줘"**라는 명령을 내렸을 때, 두 시스템은 완전히 다르게 움직입니다.
|
||||
|
||||
먼저 **AI 모델(LLM)**은 머릿속(학습된 데이터)에 있는 지식만을 꺼내서 기존 연구 목록을 말로 친절하게 설명해 줍니다. 겉보기에는 똑똑해 보이지만, 실시간으로 최신 논문을 인터넷에서 검색해 오거나 보고서 파일을 디스크에 직접 저장하는 '행동'은 수행하지 못합니다.
|
||||
|
||||
반면 **AI 에이전트(Agent)**는 명령을 받자마자 실제 행동을 개시합니다. 학술 API에 접속해 최신 논문을 검색해 오고, PDF 파일을 직접 다운로드해서 그 내용을 파싱한 다음, 최종 결과물을 마크다운 형태의 파일로 사용자의 컴퓨터 폴더에 실제로 만들고 저장해 줍니다.
|
||||
|
||||
---
|
||||
|
||||
### 📊 역할과 작동 방식의 결정적 차이
|
||||
|
||||
이 두 개념의 차이는 다음과 같이 쉽게 풀어볼 수 있습니다.
|
||||
|
||||
- **생각(Thinking)과 행동(Doing)의 차이**
|
||||
AI 모델은 질문을 던지면 이에 부합하는 지식이나 코드를 화면에 '답변'해 주는 똑똑한 뇌 역할을 합니다. 반면 AI 에이전트는 최종 목적지에 도달하기 위해 스스로 세부 계획을 세우고 실제 컴퓨터 환경에서 발로 뛰는 손과 발 역할을 함께 수행합니다.
|
||||
- **조언(Advise)과 실행(Execution)의 차이**
|
||||
모델은 "이 스크립트를 이렇게 실행해서 저장하세요"라고 텍스트로 가이드라인만 알려줍니다. 하지만 에이전트는 운영체제나 파일 시스템에 직접 들어가서 스크립트를 실제로 실행하고 그 결과물을 직접 파일로 구체화합니다.
|
||||
- **오류를 마주했을 때의 대처 능력**
|
||||
모델은 실행 중 오류가 났을 때 사람이 에러 로그를 다시 복사해서 붙여넣어 주기 전까지는 대기할 수밖에 없습니다. 반면 에이전트는 오류가 나면 스스로 로그를 해석하고, 성찰(Reflection) 과정을 거쳐 계획을 수정해 다시 시도합니다.
|
||||
|
||||
---
|
||||
|
||||
### 🚗 아주 쉬운 비유: "운전자"와 "자율주행 차량"
|
||||
|
||||
그렇다면 에이전트는 모델이 시키는 대로만 움직이는 수동적인 존재일까요? 결코 그렇지 않습니다.
|
||||
|
||||
- **AI 모델(LLM)은 '운전자(뇌)' 입니다.**
|
||||
"여기서 우회전하고 다음에서 멈추자"라는 인지적 판단과 주행 경로(추론)를 수립합니다.
|
||||
- **AI 에이전트(Agent)는 '자율주행 차량 시스템 전체' 입니다.**
|
||||
운전자의 판단을 가속 페달과 바퀴 회전(도구 실행)으로 바꾸며, 다음과 같은 독자적인 **시스템 수준의 판단**을 수행합니다:
|
||||
- **안전 가드레일**: 운전자가 실수로 시스템을 파괴하는 명령과 같이 위험한 길로 가려 할 때 비상 제동을 걸어 이를 원천 차단합니다.
|
||||
- **예외 복구 및 통제**: 네트워크 연결이 끊기거나 무한 루프에 빠지는 상황이 발생하면 스스로 판단하여 실행을 중단하고 우회 경로를 수립합니다.
|
||||
- **합의 형성(Consensus)**: 멀티 에이전트 환경에서 각 에이전트들의 교차 검증 결과를 수집하여 통과나 반려 여부를 결정하고 최종 집행을 판정합니다.
|
||||
|
||||
---
|
||||
|
||||
## 🛠️ AI 에이전트가 갖춰야 할 4대 필수 기능
|
||||
|
||||
단순히 대화만 나누는 챗봇이 아니라, 진짜 제 역할을 하는 **자율형 AI 에이전트**가 되기 위해 소프트웨어 시스템 차원에서 반드시 제공해야 하는 4가지 핵심 기능입니다.
|
||||
|
||||
1. **계획 및 추론 능력 (Planning)**
|
||||
2. **기억 및 상태 관리 능력 (Memory)**
|
||||
3. **도구 활용 및 실행 능력 (Tool Use & Action)**
|
||||
4. **상호 통신 및 협업 능력 (Collaboration)**
|
||||
|
||||
---
|
||||
|
||||
### 1. 계획 및 추론 능력 (Planning)
|
||||
|
||||
사용자가 최종 목표만 주면 스스로 실행 가능한 단계별 세부 태스크를 설계하고, 진행 과정에서 문제가 생기면 계획을 유연하게 수정하는 능력입니다.
|
||||
|
||||
- **Task Decomposition (작업 분해)**: 복잡한 목표를 실행 가능한 작은 단위의 세부 태스크로 분할 (예: Chain of Thought, Tree of Thoughts 등)
|
||||
- **Self-Reflection (자기 성찰 및 피드백)**: 행동 결과를 스스로 분석하고 실수를 교정하여 향후 계획을 실시간으로 수정 (예: ReAct, Reflexion 프레임워크)
|
||||
|
||||
* **실제 예시**:
|
||||
에이전트에게 "블로그 기사 작성"을 요청하면, 스스로 **'키워드 조사 ➡️ 개요 작성 ➡️ 본문 집필 ➡️ 오탈자 검사'** 순으로 계획을 세웁니다. 만약 맞춤법 검사 도중 치명적인 논리 오류를 발견하면, 본문 작성 단계로 스스로 되돌아가 계획을 수정하고 다시 쓰는 자가 성찰(Self-Reflection)을 거칩니다.
|
||||
|
||||
---
|
||||
|
||||
### 2. 기억 및 상태 관리 능력 (Memory)
|
||||
|
||||
현재 나누는 대화의 즉각적인 흐름(단기 기억)뿐만 아니라, 과거의 경험과 누적된 지식(장기 기억)을 필요할 때마다 영속적으로 꺼내어 쓰는 능력입니다.
|
||||
|
||||
- **Short-term Memory (단기 기억)**: 현재 대화나 컨텍스트 윈도우 내에서 실시간으로 유지되는 즉각적인 맥락 정보
|
||||
- **Long-term Memory (장기 기억)**: 외부 데이터베이스나 벡터 DB를 활용하여 과거 대화 기록 및 지식을 RAG 기법으로 바인딩하는 정보 보존 공간
|
||||
|
||||
* **실제 예시**:
|
||||
에이전트에게 "어제 작업하던 파이썬 소스코드의 오류를 이어서 수정해줘"라고 요청하는 경우입니다. 에이전트는 데이터베이스에 누적된 과거 대화 히스토리와, 벡터 DB에 저장되어 있는 소스코드의 예전 상태 정보를 동적으로 인출(Retrieval)해 와 대화 맥락을 끊김 없이 이어갑니다.
|
||||
|
||||
---
|
||||
|
||||
### 3. 도구 활용 및 실행 능력 (Tool Use & Action)
|
||||
|
||||
인터넷 검색, 외부 API 호출, 파일 시스템 접근, 코드 실행 등 컴퓨터 세상의 다양한 소프트웨어를 직접 연결하고 작동시키는 손과 발 역할을 의미합니다.
|
||||
|
||||
* **실제 예시**:
|
||||
복잡한 나눗셈 연산을 해야 할 때 직접 계산기 도구를 호출해 오차 없이 연산하고, 최신 주식 시세를 알기 위해 증권사 API를 호출하며, 작성한 코드가 잘 돌아가는지 검증하기 위해 격리된 샌드박스 컴퓨터 환경(Docker)을 구동해 스크립트를 직접 실행합니다.
|
||||
|
||||
---
|
||||
|
||||
### 4. 상호 통신 및 협업 능력 (Collaboration)
|
||||
|
||||
혼자서 모든 일을 처리하는 것이 아니라, 다른 역할을 가진 전문 에이전트나 사용자 시스템과 표준 규격으로 메시지를 주고받으며 큰 작업을 분산 처리하는 능력입니다.
|
||||
|
||||
* **실제 예시**:
|
||||
"이 프로젝트의 보안 취약점 보고서를 작성해줘"라는 명령을 내렸을 때의 상황입니다. 보안 에이전트가 소스코드를 스캔해 취약점을 나열하면, 인프라 에이전트가 가상 머신 설정을 검토하고, 최종적으로 리뷰어 에이전트들이 보고서의 신뢰성을 상호 검증하여 하나의 완성된 산출물을 합작해 냅니다.
|
||||
|
||||
---
|
||||
|
||||
## 🚀 패러다임 전환: Model eats the Scaffolding (모델이 외부 시스템을 흡수하다)
|
||||
|
||||
현재 에이전트 기술에서 가장 중요한 변화 중 하나는, 과거에 에이전트 제어 시스템(Scaffolding, 에이전트의 구동을 돕는 외부 뼈대 구조)이 수동으로 제어하던 기능들이 점점 AI 모델 내부로 흡수되고 있는 현상입니다.
|
||||
|
||||
- https://arca.live/b/characterai/174977057?category=%EB%89%B4%EC%8A%A42&p=1
|
||||
|
||||
- **스스로 생각하는 모델의 등장 (Test-time Compute, 추론 시점 추가 연산)**
|
||||
최근 출시된 Gemini Thinking이나 OpenAI o1/o3 같은 모델들은 외부 시스템이 루프를 돌려주지 않아도, 모델 스스로 출력을 내보내기 전에 내부적으로 계획을 세우고(Planning) 스스로 오류를 성찰(Reflection)하는 과정을 완료합니다.
|
||||
- **인지와 집행의 명확한 역할 분담**
|
||||
이에 따라 고차원적인 논리 설계와 계획(Planning)은 **AI 모델** 내부로 빠르게 넘어가고 있습니다. 반면 외부의 **에이전트 인프라(Harness, 에이전트 실행 및 도구 제어 장치)**는 안전한 실행 환경(Sandboxing, 격리 환경 실행), 권한 통제, 상태 관리처럼 모델이 직접 수행하기 어려운 물리적 보호막 역할을 담당하는 방향으로 진화하고 있습니다.
|
||||
- **차별화 요소(Alpha)의 이동**
|
||||
단순히 계획을 짜는 흐름을 코드로 구현하는 것의 가치는 점차 줄어들고 있습니다. 이제는 복잡한 인프라를 실시간으로 제어하고, 서로 다른 규격을 가진 다양한 에이전트들을 표준 프로토콜로 유기적으로 엮어내는 기술이 핵심 경쟁력으로 부상하고 있습니다.
|
||||
|
||||
---
|
||||
|
||||
# 1. AI 에이전트 구현을 위한 3대 핵심 엔지니어링 기법
|
||||
|
||||
성공적인 AI 에이전트 시스템을 구현하기 위해서는 단순히 모델에게 프롬프트를 입력하는 것을 넘어, **모델 제어**, **정보 연동**, **물리적 환경 연결**을 유기적으로 엮어내는 3가지 핵심 엔지니어링 기법이 필요합니다.
|
||||
|
||||
1. **프롬프트 엔지니어링 (Prompt Engineering)**: 에이전트의 페르소나와 사고 방식(추론 가이드라인)을 규정하는 작업입니다.
|
||||
2. **컨텍스트 엔지니어링 (Context Engineering)**: 대화 흐름을 끊김 없이 보존하고 관련 데이터를 적시에 제공하는 정보 정리 작업입니다.
|
||||
3. **하네스 엔지니어링 (Harness Engineering)**: 격리된 환경에서 다양한 소프트웨어 도구를 안전하게 조작할 수 있는 물리적 손발을 달아주는 작업입니다.
|
||||
|
||||
---
|
||||
|
||||
### 1️⃣ 프롬프트 엔지니어링 (Prompt Engineering)
|
||||
|
||||
모델의 발전과 자체 추론 기능의 향상으로 예전만큼 미시적인 프롬프트 트릭에 집착할 필요는 줄어들고 있습니다. 하지만 프롬프트는 여전히 **AI 에이전트 활용의 시작점이자 뼈대**입니다. 구체적이고 명확한 작동 지침을 만들기 위해 프롬프트 작성 시 반드시 반영해야 할 3대 핵심 고려사항입니다.
|
||||
|
||||
- **역할 및 페르소나 지시 (Role)**
|
||||
에이전트에게 전문 도메인 지식과 행동 경계를 지정해 줍니다. (예: *"너는 주니어 개발자를 코칭하는 꼼꼼한 테크리더 에이전트다. 직접 고치지 말고 가이드라인만 제공해라."*)
|
||||
- **구체적인 작업 예시 제공 (Few-shot)**
|
||||
원하는 출력 형식이나 중간 추론 과정의 모범 예시를 제공하여, 에이전트의 답변 일관성과 가독성을 극대화합니다.
|
||||
- **자가 검증 방법 제시 (Verification)**
|
||||
에이전트 스스로 작업의 무결성을 점검하게 하거나, 외부 시스템이 실행 결과를 확인 및 통제할 수 있도록 정형화된 출력 규격(예: 최종 통과 시 `[VERDICT: PASS]` 명시 요구)을 정의해 줍니다.
|
||||
|
||||
---
|
||||
|
||||
### 💡 실제 프롬프트 구조 예시 (ReAct 사고 방식)
|
||||
|
||||
에이전트가 단번에 대답하지 않고 단계별로 계획을 세워 도구를 사용하도록 프롬프트 구조를 강제하는 기법입니다.
|
||||
|
||||
```text
|
||||
[System Prompt]
|
||||
너는 복잡한 수식을 계산하는 수학 에이전트다. 다음 형식으로 사고해라:
|
||||
- Thought: 문제 해결을 위한 다음 행동 계획을 작성해라.
|
||||
- Action: 호출할 도구 이름과 인자값을 JSON으로 적어라. (예: Calculator)
|
||||
- Observation: 도구 실행 결과가 여기에 채워질 것이다.
|
||||
- Thought: 실행 결과를 바탕으로 성찰하고, 필요하면 다음 Action을 설계해라.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 2️⃣ 컨텍스트 엔지니어링 (Context Engineering)
|
||||
|
||||
에이전트가 다루는 대화 맥락과 작업 상태(State)를 효율적으로 정제하고, 수많은 외부 정보 중 **지금 꼭 필요한 관련 데이터(RAG)**만을 선별하여 제한된 AI의 기억 공간(컨텍스트 윈도우)에 밀도 높게 채워 넣는 기술입니다.
|
||||
|
||||
* **핵심 설계 요소**:
|
||||
- **대화 상태 보존**: 이전 턴의 작업 결과를 유실 없이 보존
|
||||
- **동적 바인딩**: 외부 RAG 검색기에서 관련도 높은 중요 데이터만 적시에 필터링하여 공급
|
||||
- **메모리 압축**: 불필요한 과거 로그는 요약하고, 핵심 현재 상태 구조체만 유지해 토큰 낭비 방지
|
||||
* **에이전트 상태 보존 예시 (State JSON)**:
|
||||
```json
|
||||
{
|
||||
"task_id": "job_10294",
|
||||
"current_working_directory": "/workspace/src",
|
||||
"error_logs": ["SyntaxError: unexpected EOF while parsing at line 14"],
|
||||
"completed_subtasks": ["1. 소스코드 로드 완료", "2. 오류 라인 식별"],
|
||||
"next_action_required": "오류 라인 14의 괄호 닫힘 확인 및 수정 스크립트 작성"
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 3️⃣ 하네스 엔지니어링 (Harness Engineering)
|
||||
|
||||
에이전트가 파일 시스템 제어, 브라우저 조작, 외부 API 호출 등 컴퓨터 세상의 다양한 도구들을 안전하게 가동할 수 있도록 **물리적 인터페이스(연결 고리)**를 구성하는 기술입니다.
|
||||
|
||||
* **핵심 설계 요소**:
|
||||
- **도구 호출 가로채기(Intercepting)**: 모델이 내놓은 도구 호출 의도(JSON 등)를 감지하고, 실제 터미널이나 프로그램의 함수로 전달해 구동함
|
||||
- **보안 샌드박싱 (Sandboxing)**: 에이전트가 악성 코드나 파괴적인 명령어를 무단 실행하지 않도록 격리된 가상 환경을 구축하고 권한을 통제함
|
||||
* **물리 인터페이스 도구 결합 예시**:
|
||||
```
|
||||
[LLM의 출력] ──> "Action: execute_command, args: { cmd: 'ls -la' }"
|
||||
│ (하네스가 이를 가로챔)
|
||||
▼
|
||||
[하네스 제어기] ──> 격리된 Docker 샌드박스 내부에서 'ls -la' 실제 실행
|
||||
│ (실행 결과 가로챔)
|
||||
▼
|
||||
[LLM의 입력] <── "Observation: total 12\ndrwxr-xr-x 3 user..." (모델에 반환)
|
||||
```
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
# 2. AI Agent 기능 확장: MCP & SKILL
|
||||
|
||||
## MCP (Model Context Protocol)
|
||||
Model Context Protocol(MCP)은 Anthropic이 2024년 11월 발표한 오픈 소스 프로토콜로, AI 애플리케이션(Host) 내부의 클라이언트(Client)가 로컬/원격의 도구(Tools), 데이터 소스(Resources), 그리고 컨텍스트 템플릿(Prompts)을 통일된 규격으로 안전하게 호출할 수 있는 공통 인터페이스입니다.
|
||||
- **Host-Client-Server 구조**: 에이전트 플랫폼(Host) 내 클라이언트가 표준화된 MCP 프로토콜을 통해 외부의 다양한 MCP 서버들과 통신하여 기능을 동적으로 확장하는 형태
|
||||
- **3대 제공 요소**:
|
||||
- **Tools**: 에이전트가 실행할 수 있는 실행형 기능(계산기, 파일 제어, API 호출 등)을 명세하고 호출 처리
|
||||
- **Resources**: 에이전트가 읽을 수 있는 데이터 소스, 파일, 컨텍스트 상태 정보를 노출
|
||||
- **Prompts**: 자주 사용되는 프롬프트 템플릿과 실행 지침을 표준 규격으로 제공
|
||||
|
||||
## CLI 코딩 에이전트: Claude Code vs Cowork
|
||||
AI 에이전트의 대표 주자인 Claude는 Claude Desktop App에서 Claude Cowork와 Claude Code라는 두 가지 상이한 서비스를 제공합니다.
|
||||
- **작동 방식의 차이**: Claude Cowork는 일상적인 사무 비서 역할로 Cloud 상에서 필요한 파일(pdf, word, excel 등)을 읽고 쓰는 방식을 사용하며, Claude Code는 Coding 작업에 특화되어 Local Computer에 필요한 모듈과 소프트웨어를 설치하여 직접 파일 수정 및 실행을 수행
|
||||
- **환경적 이점**: Claude Code는 터미널에서 로컬 컴퓨터의 필요한 모듈/소프트웨어를 바탕으로 작업 디렉터리 내 파일을 직접 제어하여 개발 업무에 고도화된 성능 발휘
|
||||
|
||||
|
||||
|
||||
- **생산성 극대화**: Claude Code를 프로젝트에 알맞게 조련하여 사용할 경우 단순 Cloud 비서 환경 대비 월등히 높은 결과물 기대 가능
|
||||
|
||||
## SKILL이란
|
||||
Skills(기술/도구 패키지)는 AI 에이전트가 외부 환경과 동적으로 상호작용할 수 있도록 결합하는 기능적 실행 모듈입니다. 단순히 LLM에게 단순 프롬프트 지시를 하는 프롬프트 엔지니어링 수준을 넘어, 에이전트가 특정 목표를 위해 직접 실행할 수 있는 실행 코드, 도구의 명세 스키마(Tool Schema), 사용 설명 및 예시(Few-shot) 등이 하나로 패키징된 자율 확장 도구 모음입니다.
|
||||
- **동적 모듈화 및 모듈화 방식**: 상황에 따라 필요한 기술을 동적으로 로드해 사용하고, 완료 후 반환하는 독립 모듈화 형태 채택
|
||||
- **작업 수행 한계 돌파**: 텍스트 생성이라는 언어 모델의 한계를 넘어 파일 제어, 서버 배포, 물리 데이터 수집 등 실질적인 업무 대행 능력을 에이전트에 부여
|
||||
|
||||
## 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
|
||||
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
# 3. 멀티 에이전트 협업 체계 및 오케스트레이션 인프라
|
||||
|
||||
## 싱글 에이전트의 한계
|
||||
단일 에이전트는 대규모 컨텍스트를 처리할 때 정보 누락(Lost in the middle) 현상이 발생하기 쉽고, 여러 도구를 한꺼번에 다루어야 할 때 환각(Hallucination)율이 증가하는 문제가 있습니다. 또한 역할 집중으로 인한 프롬프트의 장황화, 멀티태스킹 오류 및 컨텍스트 인지 한계 등의 명확한 한계를 가집니다.
|
||||
|
||||
## 멀티 에이전트란: 역할 세분화와 교차 검증
|
||||
멀티 에이전트(Multi-Agent) 시스템은 단일 에이전트(Single Agent)의 한계를 극복하기 위해, 서로 다른 페르소나와 전문 도구(Skills)를 갖춘 여러 개의 에이전트들이 협력 네트워크를 형성하여 복잡한 목표를 조율(Orchestration)하고 분할 해결하는 구조입니다.
|
||||
- **역할 세분화 (Role Specialization)**: 에이전트별로 한정된 역할(PM, Developer, QA, Researcher 등)과 도구만을 부여하여 프롬프트 노이즈를 억제하고 추론 정확도 향상
|
||||
- **교차 검증**: 서로 다른 이종 모델(Gemini 작성 ➡️ Claude 검토 등) 간의 상호 비평 및 검증 루프를 통해 결과물의 정합성을 교차 검증하고 결과 신뢰성 극대화
|
||||
- **분할 정복 (Divide and Conquer)**: 하나의 거대한 프로젝트를 독립된 세부 태스크로 쪼개어 다수의 에이전트가 병렬적으로 해결함으로써 복잡성 분산
|
||||
|
||||
## Subagent / Team agent
|
||||
|
||||
- ### Subagent란
|
||||
Subagent는 부모 에이전트(Parent Agent 또는 Orchestrator)에 의해 동적으로 생성되어 특정 국소적이고 독립적인 태스크를 대행한 뒤, 결과를 상위로 반환하고 소멸하는 종속형 에이전트입니다.
|
||||
- **컨텍스트 격리**: 하위 작업의 맥락만을 분기(Branch)하여 처리함으로써 상위 대화의 컨텍스트 오염을 막고 토큰 소모량 최적화 및 속도 개선
|
||||
- **예시**: 메인 에이전트가 리팩토링 중 특정 모듈 에러 복구 작업만을 subagent에 위임하여 처리하는 독립적인 문제 해결 기법
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
- ### Team agent란
|
||||
Team agent는 단일 계층적인 수직 구조를 넘어, 수평적이고 다양한 역할을 맡은 여러 독립 에이전트가 협의체(Crew/Team)를 구성하여 대화형 협력(Multi-agent Debate) 및 협상을 통해 목표를 완수하는 협동형 에이전트 구성 방식입니다.
|
||||
- **의견 충돌 및 합의**: 특정 설계안에 대해 서로 다른 관점의 에이전트들이 논쟁(Debate)을 벌이고, 최종적으로 조율된 결과를 PM 에이전트가 도출하는 식의 협력 모델
|
||||
- **협력적 의사결정**: 복잡한 문제에 대해 실시간으로 의견과 피드백을 교환하여 점진적으로 결과물의 품질 고도화
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## 구성 기술: TMUX · crewAI · LangGraph
|
||||
|
||||
- ### TMUX
|
||||
TMUX는 에이전트들의 독립적인 작업 공간을 제공하는 가상 터미널 관리 도구로, 백그라운드 내 장기 작업(Long-running task) 세션을 안정적으로 유지하고 AI 에이전트의 동작을 TUI로 실시간 모니터링 및 제어할 수 있도록 도와주는 소프트웨어입니다.
|
||||
- **에이전트별 독립 작업 공간 제공**: 각 에이전트 세션을 독립적인 tmux 윈도우나 패널에 격리하여 병렬로 실행할 수 있는 물리적 격리막 형성
|
||||
- **장기 실행 작업의 백그라운드 세션 유지**: SSH 연결이 끊어지거나 브라우저 세션이 끊겨도 tmux 세션 내부에서 구동되는 에이전트 작업은 유실 없이 백그라운드에서 계속 유지
|
||||
- **TUI 실시간 모니터링 및 제어**: CLI 코딩 에이전트나 멀티 에이전트들의 실행 과정을 사람이 TUI를 통해 실시간으로 관측(observe)하고 필요시 입력을 제공할 수 있도록 실시간 관측 및 제어 지원
|
||||
- *실제로 앞서 소개한 `multi-agent-mux` 스킬 데모가 이러한 TMUX 세션 관리 기능을 활용하여 설계된 멀티 에이전트 오케스트레이션 사례임*
|
||||
|
||||
- ### crewAI
|
||||
역할 기반(Role-based) 협업을 설계하는 데 특화된 프레임워크입니다. 각 에이전트에게 명확한 역할(Role), 목표(Goal), 배경 설명(Backstory)을 부여하고, 이들을 업무 프로세스(Sequential 또는 Hierarchical)에 따라 배치해 '크루(Crew)' 단위로 조율합니다.
|
||||
|
||||
- ### LangGraph
|
||||
컨텍스트 엔지니어링(Context Engineering)은 다중 에이전트 시스템에서 에이전트들 간의 대화 흐름, 전달되는 컨텍스트(State), 복잡한 제어 루프를 효율적으로 설계하고 유지하는 방법론적 학문입니다. 이를 구현하는 대표적인 상태 보존형 프레임워크가 LangGraph입니다.
|
||||
- **상태 보존 및 순환 제어**: 단순 선형적 체인 구조를 탈피하여, 에이전트 간의 루프(반복 검증), 조건부 분기(Conditional branching), 실패 시 롤백 등을 순환형 그래프(Cyclic Graph) 구조로 제어
|
||||
- **영속적 상태 관리**: 협업 과정에서 축적되는 다양한 상태 변화(State)를 중앙 저장소에서 추적 및 동기화하여 특정 노드가 실패하더라도 이전 상태부터 복구 및 재시작할 수 있는 환경 제공
|
||||
|
||||
- ### (참고) AutoGen, BeeAI
|
||||
Microsoft AutoGen과 IBM의 BeeAI도 멀티 에이전트 오케스트레이션을 지원하는 주요 프레임워크입니다.
|
||||
- **Microsoft AutoGen**: 대화형 에이전트 설계(Conversational Agentic Design)에 중점을 둔 프레임워크로, 에이전트 간 대화를 통해 코드를 실행하고 피드백을 주고받는 풍부한 동적 워크플로우 제공
|
||||
- **BeeAI**: 에이전트를 탐색, 실행, 공유할 수 있는 중앙 집중형 오픈소스 플랫폼으로 리눅스 재단(LF) 하위에서 ACP 표준 프로토콜을 백본으로 구축
|
||||
|
||||
|
||||
|
||||
## [사례] 실제 구현하며 겪은 문제점들
|
||||
|
||||
1. **Agent들과 각 Agent들의 세션 관리**
|
||||
- 다수의 에이전트와 그 아래에 동적으로 생성되는 subagent들의 생명주기(Lifecycle) 및 고유 식별자(UUID)를 동기화하고 상태를 지속적으로 보존하는 일관된 세션 관리 시스템 요구
|
||||
2. **에이전트 상호 탐색(Service Discovery)과 역할 식별**
|
||||
- 새로운 에이전트가 네트워크에 진입했을 때 어떤 에이전트가 어떤 과업을 처리할 수 있는지 동적으로 파악하는 기능 요구
|
||||
- **마스터 - 슬레이브(Master-Slave) 방식**: 중앙 오케스트레이터가 전권을 쥐고 세션을 직접 관리 및 명령하므로 통제는 쉬우나, 오케스트레이터의 에러가 시스템 전체의 단일 실패점(SPOF)이 될 위험 존재
|
||||
- **P2P 및 보고(P2P and Report) 방식**: 에이전트들이 동등한 위치에서 협상하며 자율적으로 탐색하고, 작업 결과를 기록 보관소에 보고하는 방식이나 네트워크 관리 비용 상승 우려
|
||||
3. **실시간 메시징과 이벤트 예외 처리의 복잡성**
|
||||
- 태스크 위임 완료 후, 작업 결과와 성공/실패 여부를 교환하는 통신 채널이 중단되거나 유실될 수 있는 위험성 대두
|
||||
- **송신/수신 주체의 돌발 종료**: 위임 후 송신 주체가 다운되었다가 재가동(Restart)되는 경우, 비동기 알람이 공중분해되어 전체 협업 루프 중단
|
||||
- **무한 대기 및 리소스 누수(Deadlock & Resource Leak)**: 작업을 위임받은 서브에이전트가 예외 이벤트 없이 비정상 종료(Silent death)할 경우 부모 에이전트가 무한 대기(Blocking) 상태에 빠지는 문제 발생
|
||||
|
||||
## [사례] Multi Agent Orchestration의 장점
|
||||
1. **프롬프트의 간소화 및 루프 엔진의 진화**
|
||||
- 기존의 길고 장황한 단일 "Super Prompt" 엔지니어링 시대에서 벗어나, 에이전트를 구동하고 제어하는 자율 루프(Loop Architecture) 설계 중심으로 패러다임 이동
|
||||
- *PSPDFKit 창업자이자 오픈소스 AI 에이전트 프로젝트인 OpenClaw의 크리에이터인 페터 슈타인베르거(Peter Steinberger, 2026년 초 OpenAI 합류)는 **"코딩 에이전트에 프롬프트를 더 넣지 말고, 에이전트를 구동하는 루프를 설계하라"**(Stop prompting your coding agents; start designing loops that prompt your agents)고 강조한 바 있음*
|
||||
- 멀티 에이전트 구조에서는 작업 지시 PM 에이전트, 작업 수행 Worker 에이전트, 유효성 검증 Reviewer 에이전트로 나뉨으로써 프롬프트가 단편적이고 명료해지는 이점 확보
|
||||
2. **컨텍스트 설명 불필요 (Context-Free Sharing)**
|
||||
- 공유 작업 환경(Shared Workspaces)과 Git 같은 버전 관리 시스템을 에이전트들이 공유하므로, 새로 합류한 에이전트에게 변경 이력이나 현재 맥락을 다시 텍스트로 설명하느라 불필요한 토큰과 대기 시간 낭비 방지
|
||||
3. **이종 모델 피드백을 통한 고품질 산출물 교차 검증**
|
||||
- 특정 한 모델 계열만으로 결과물을 짜고 동일한 계열에 검토를 시키는 것보다, 서로 다른 아키텍처와 특징을 지닌 이종 모델(Gemini 작성 ➡️ Claude 검토 등) 간 상호 보완할 때 결과물의 신뢰성 극대화 및 보이지 않는 맹점 상호 보완
|
||||
4. **비용 효율적인 토큰 분배 (Cost Optimization)**
|
||||
- 쉬운 코드 생성이나 정보 검색은 경량화된 저비용 모델(예: Gemini Flash 세대)을 탑재한 에이전트에 분산 위임하고, 고난도의 논리적 추론이 필요한 부분에만 최상위 고비용 모델을 탑재한 에이전트를 적절히 매칭함으로써 종합적인 API 비용 효율적 제어
|
||||
|
||||
## [요구사항] 성공적인 구현을 위해 필요한 것들 (What We Need?)
|
||||
앞의 문제점과 장점을 종합하면, 성공적인 멀티 에이전트 오케스트레이션 구현을 위해서는 다음 5가지 구성요소가 필수적이며, 이 요구사항들이 4장(표준)과 5장(인프라)에서 소개할 솔루션의 선정 기준이 됩니다.
|
||||
|
||||
1. **Agent 간 작업 환경 공유 (A2A의 Agent Card 기반)**
|
||||
- 특정 에이전트에게 태스크를 안전하게 위임하고 위임받기 위해선, 각 에이전트 카드를 통해 서로의 역할, 엔드포인트, 입력 명세 스키마를 신뢰성 있는 방식으로 동기화
|
||||
2. **에이전트 작동 인프라스트럭처 (Agent Working Infrastructure)**
|
||||
- 에이전트들이 통신에 사용할 서비스 주소와 포트를 동적으로 조회할 수 있는 서비스 디스커버리 기능 및 자동 라우팅 체계 내재
|
||||
3. **일관성 있는 워크플로우 추적 및 공유 (Issue & Workflow Tracking)**
|
||||
- 서로 다른 에이전트가 동일한 작업을 재수행할 때 동일한 프로세스와 출력을 일관되게 얻을 수 있도록 워크플로우 사양이 제어되어야 함. 또한 에러나 중간 정지가 일어났을 때 복구 및 추적이 용이하도록 규격화된 이슈 추적 인터페이스 마련
|
||||
4. **고성능 양방향 메시징 시스템 (Advanced Messaging System)**
|
||||
- 고용량의 코드 블록, 이미지 및 멀티모달 센서 데이터 등을 대량으로 빠르고 정확하게 공유하기 위해서는 기존의 MQTT나 단순 메시지 큐(MQ) 방식은 토픽 세분화와 페이로드 크기 한계로 인해 통신 병목을 겪을 수밖에 없음
|
||||
- 단편적인 이벤트 알림만 전송하는 구조에서 탈피하여 상세 에러 트레이스, 상태 구조체, 이미지 바이너리 등을 한꺼번에 담을 수 있는 풍부한 페이로드 지원 메시징 규격이 필수적임. 나아가 대용량 멀티모달 푸시(Push)와 양방향 스트리밍을 지원하기 위해 HTTP/3의 멀티 스트리밍 등 고성능 통신 수반
|
||||
5. **작업 및 태스크 관리 시스템 (Job & Task Lifecycle Controller)**
|
||||
- 하나의 부모 작업을 하위 스크럼(Scrum) 단위로 쪼개어 서브에이전트들에게 뿌려주는 라이프사이클 관리 기능이 있어야 함. 각 서브에이전트의 생성부터 소멸까지의 메시징 토픽과 임시 토큰을 정리해야 하며, 이 과정에서 부하를 고르게 배분하고 실력 있는 에이전트를 매칭하기 위한 로드 밸런싱 기법 병행
|
||||
|
||||
|
||||
|
||||
### 🔗 요구사항과 기술 솔루션 매핑 (Bridge Mapping)
|
||||
- **요구사항 1(작업 환경 공유)** 및 **요구사항 2(서비스 디스커버리)**는 상호 연동 장벽을 허물기 위해 **§4 에이전트 상호운용성 표준(ACP/A2A)**을 통해 규격화된 표준 명세로 제공
|
||||
- **요구사항 4(고성능 양방향 메시징)** 및 **요구사항 5(태스크 라이프사이클/로드밸런싱)**는 고부하 대규모 실시간 분산 환경에서 물리적 네트워크 및 런타임 최적화를 실현하는 **§5 gRPC 백본 인프라**를 통해 해결
|
||||
- **요구사항 3(워크플로우 추적)**은 표준 명세(Agent Card)의 추적 스키마와 물리 인프라(gRPC liveness probe 및 트레이싱 도구) 양대 측면에 모두 걸쳐 상호 보완적 제어
|
||||
|
||||
---
|
||||
|
||||
# 4. 에이전트 상호운용성 확보를 위한 표준: ACP, A2A
|
||||
|
||||
## 왜 이종 에이전트 연동 표준이 필요한가
|
||||
3장에서 정의한 요구사항 중 **'Agent 간 작업 환경 공유'(요구사항 1)**와 **'서비스 디스커버리'(요구사항 2)**는 특정 벤더의 독점적 구현이 아닌 개방형 표준 규격을 통해 해결되어야 합니다. 그 핵심 해답이 되는 오픈 규격 표준이 바로 ACP와 A2A입니다.
|
||||
|
||||
서로 다른 벤더가 제작하고 각기 다른 아키텍처로 설계된 이종 에이전트들이 복잡한 맞춤형 결합 코드(Glue code) 없이도 서비스 검색, 역할 전파 및 태스크 위임을 유연하게 수행하려면 통일된 오픈 통신 규약이 필수적입니다. 표준 규격을 통하면 에이전트 생태계의 결합도가 낮아져 이종 에이전트 간의 동적 협업 네트워크 구축 속도가 비약적으로 향상됩니다.
|
||||
|
||||
## ACP (Agent Communication Protocol)
|
||||
IBM Research가 자사의 BeeAI 프레임워크 연동을 지원하기 위해 **2025년 3월** 발표했던 오픈 표준 에이전트 통신 인터페이스입니다. 이종 에이전트 간의 서비스 발견(Service Discovery), 상호작용 방법 협상, 태스크 위임 프로세스를 최초로 규격화하였습니다. 이후 **2025년 8월 27일** 공식 깃허브 저장소가 아카이빙되며 Linux Foundation AI & Data 하위의 A2A(Agent-to-Agent) 프로토콜로 공식 통합 및 병합되어 단일 연합 생태계를 형성하였습니다.
|
||||
|
||||
## A2A와 Agent Card
|
||||
- ### A2A (Agent-to-Agent) 프로토콜
|
||||
Google과 50여 개 파트너사들이 **2025년 4월** 공동 발표하고 **2025년 6월** Linux Foundation에 기증한 이종 에이전트 간 표준 메시지 교환 및 상태 추적용 통합 통신 오픈 표준입니다. 서로 다른 벤더가 구현한 에이전트나 다양한 아키텍처 기반의 에이전트가 복잡한 결합 코드 없이도 협업 메시지를 교환하고 상태 추적 지원
|
||||
- ### Agent Card (에이전트 카드)
|
||||
A2A 생태계에서 에이전트의 기능 명세서 역할을 하는 JSON 포맷의 표준 규격서입니다. 이는 **요구사항 1(작업 환경 공유)**을 물리적 파일 수준에서 구체화하는 핵심 메커니즘으로 기능함. 에이전트 카드에는 해당 에이전트의 명칭, 제공 가능한 역량(Capabilities), 호출 엔드포인트 정보, 요청 시 통과해야 하는 보안 인증 사양(Authentication) 등이 명시되어 있어 서비스 검색 시스템(Service Discovery)이 에이전트의 역할을 실시간으로 탐색할 수 있도록 보장. 주로 `/.well-known/agent-card.json` 경로에 배포
|
||||
|
||||
---
|
||||
|
||||
# 5. 지능형 사물인터넷(AIoT) 및 gRPC 기술 동향
|
||||
|
||||
## AIoT 환경에서 멀티 에이전트가 유용한 이유
|
||||
스마트 팩토리, 스마트 팜 등 다수의 물리 디바이스로 구성된 Physical 계층과 엣지 연산 계층이 복잡하게 혼재하는 AIoT 환경에서는 단일 클라우드 에이전트만으로 지연 시간 제어와 로컬 예외 상황 대처를 감당하기 어렵습니다. 따라서 센서 수집, 이상 탐지, 자율 제어 등의 고유 역할을 여러 에이전트에 자율 분산 배치하여 협업 기반의 로컬 제어를 실현해야 합니다. 이를 통해 네트워크 연결 차단 시에도 독립 제어가 가능하며, 컴퓨팅 자원이 극도로 제한된 엣지 인프라 하에서도 실시간 협업 자율 제어를 달성할 수 있습니다.
|
||||
|
||||
## Why we need gRPC?
|
||||
3장 요구사항 중 **'고성능 양방향 메시징'(요구사항 4)**과 **'태스크 라이프사이클 관리'(요구사항 5)**를 물리적 인프라 수준에서 충족하는 강력한 통신 백본이 gRPC (Google Remote Procedure Call) 프로토콜입니다.
|
||||
|
||||
1. **A2A 프로토콜과의 높은 호환성 및 스마트 팩토리/팜 최적화**
|
||||
- 스마트 팜, 스마트 팩토리와 같은 AIoT 서비스를 타겟으로 하는 개발 단계에서 대역폭이 극단적으로 제약되는 센서 디바이스는 MQTT/CoAP 등을 혼용하되, 상위 게이트웨이 및 연산 계층에서는 gRPC가 강력하고 최적의 제어 프로토콜로 작동
|
||||
2. **고성능 멀티 모달 바이너리 스트리밍 및 Pub/Sub 네이티브 지원**
|
||||
- HTTP/2 또는 HTTP/3 기반으로 작동하여 양방향 스트리밍, Request/Response, Pub/Sub 통신 방식을 단일 포트에서 완벽히 수행하며 대용량 멀티모달 바이너리를 고속으로 처리
|
||||
- 마이크로서비스 아키텍처(MSA)에서 메인 통신 규격으로 활용되므로 타 시스템으로의 이식 및 연동 성능 탁월
|
||||
3. **구조화된 직렬화 기반의 효율적 태스크 생명주기 및 부하 분산**
|
||||
- Protobuf를 통한 강력한 스키마 기반 직렬화로 통신 메시지 처리 효율을 JSON 파싱 대비 수배 이상 향상하고 메모리 오버헤드 극소화
|
||||
- 이미 검증된 Envoy, Kubernetes gRPC liveness probe 등의 기성 인프라를 활용하여 에이전트 라이프사이클 감시 체계를 최소한의 공수로 구축 가능
|
||||
|
||||
## 기술 동향 요약
|
||||
최근 AIoT 에이전트 인프라 환경은 물리적 센서 단말에서 대역폭을 극단적으로 아끼기 위해 경량 프로토콜(MQTT/CoAP)을 사용하고, 상위 연산 및 오케스트레이터 게이트웨이 계층에서는 고성능 프로토콜(gRPC)을 사용하여 계층별 완충 혼용을 유도하는 설계가 주류 트렌드로 자리잡고 있습니다. 이러한 하이브리드 프로토콜 아키텍처는 마이크로서비스 아키텍처(MSA)에 뛰어난 이식 및 확장 성능을 보장합니다.
|
||||
|
||||
---
|
||||
|
||||
# 특강 최종 요약
|
||||
|
||||
## AI Multi-Agents 오케스트레이션 기술 동향 및 사례
|
||||
- **AI 에이전트 구현을 위한 3대 핵심 엔지니어링 기법**: 프롬프트 엔지니어링, 컨텍스트 엔지니어링, 하네스 엔지니어링을 통하여 단일 에이전트 설계 및 도구 연동 제어
|
||||
- **AI Agent 기능 확장**: MCP(Model Context Protocol) 및 SKILL 프레임워크를 기반으로 클라이언트-서버 구조로 동적인 도구(Tools) 및 데이터(Resources) 호출 인터페이스 확장
|
||||
- **멀티 에이전트 협업 체계 및 오케스트레이션 인프라**: 싱글 에이전트의 한계(Lost in the middle, 환각)를 극복하기 위해 TMUX 세션 관리 TUI, crewAI 역할 협업, LangGraph 상태 보존 그래프를 결합한 분산 협업 구조 구축
|
||||
- **에이전트 상호운용성 확보를 위한 표준**: 벤더 종속 없이 협업 위임을 실현하기 위해 ACP와 A2A 프로토콜 표준 규격 및 Agent Card 기반의 상호 탐색 환경 통일
|
||||
- **지능형 사물인터넷 (AIoT) 및 gRPC 기술 동향**: 물리 및 엣지 단말 자원 한계를 보완하기 위한 경량 프로토콜(MQTT/CoAP)과 고성능 양방향 메시징 gRPC를 계층별 완충 혼용하여 MSA 기반의 실시간 자율 분산 제어망 완성
|
||||
Reference in New Issue
Block a user