AI 에이전트가 단독으로 작동하는 시대는 지나가고 있습니다. 이제 여러 에이전트가 협력하여 복잡한 업무를 처리하는 멀티 에이전트 시스템이 현실이 되고 있는데, 여기서 핵심적인 질문이 하나 있습니다.
“에이전트 A가 과거에 나눈 대화 내역과 학습한 맥락을 에이전트 B에게 넘겨줄 수 있을까?”
이 글에서는 Google의 A2A(Agent-to-Agent) 프로토콜을 중심으로 에이전트 간 대화 내역과 메모리를 공유하는 방법을 정리합니다.
1. A2A 프로토콜이란?
A2A(Agent-to-Agent)는 Google이 2024년에 발표하고 2026년 3월에 v1.0.0을 릴리스한 오픈 프로토콜입니다. 서로 다른 프레임워크, 다른 벤더에서 만든 AI 에이전트들이 표준화된 방식으로 통신하고 협업할 수 있게 해줍니다.
기술 스택
| 구성 요소 | 기술 |
|---|---|
| 전송 계층 | HTTP/HTTPS |
| 메시지 형식 | JSON-RPC 2.0 |
| 실시간 스트리밍 | SSE (Server-Sent Events) |
| 에이전트 발견 | Agent Card (JSON 메타데이터) |
핵심 데이터 모델
A2A의 통신은 다음 구조로 이루어집니다.
Task (작업 단위)
├── Message (대화 턴)
│ ├── role: "user" | "agent"
│ ├── contextId
│ ├── messageId
│ └── parts[]
│ ├── TextPart (텍스트)
│ ├── FilePart (파일 참조)
│ └── DataPart (구조화된 JSON 데이터)
└── Artifact (에이전트가 생성한 산출물)
└── parts[]
- Task: 에이전트 간 협업의 기본 단위. 하나의 작업 요청과 그에 대한 응답 전체를 포괄합니다.
- Message: Task 내의 개별 대화 턴.
contextId로 대화 맥락을 추적합니다. - Part: 메시지를 구성하는 최소 콘텐츠 단위. 텍스트, 파일, 구조화된 데이터를 담을 수 있습니다.
- Artifact: 에이전트가 작업 결과로 생성한 산출물(문서, 이미지, 데이터 등).
2. A2A의 핵심 원칙: Opaque Execution
A2A 프로토콜의 가장 중요한 설계 원칙은 Opaque Execution(불투명 실행)입니다.
에이전트는 자신의 내부 상태, 메모리, 도구, 추론 과정을 상대 에이전트에게 공개하지 않습니다.
이것은 의도적인 설계입니다. 각 에이전트의 독립성, 보안, 지적 재산을 보호하면서도 협업을 가능하게 하기 위함입니다. 에이전트는 서로를 블랙박스로 취급하되, 선언된 능력(Agent Card)과 교환된 메시지(Message/Artifact)를 기반으로 협력합니다.
이것이 의미하는 것
에이전트 A 에이전트 B
┌─────────────┐ ┌─────────────┐
│ 내부 메모리 │ ← 비공개 │ 내부 메모리 │
│ 추론 과정 │ │ 추론 과정 │
│ 사용 도구 │ │ 사용 도구 │
├─────────────┤ ├─────────────┤
│ Agent Card │ ─── 공개 ───→ │ │
│ Message │ ←── 교환 ───→ │ Message │
│ Artifact │ ←── 교환 ───→ │ Artifact │
└─────────────┘ └─────────────┘
즉, A2A 프로토콜 자체만으로는 에이전트의 과거 대화 내역이나 내부 메모리를 직접 공유하는 메커니즘이 없습니다. 하지만 이를 해결하기 위한 여러 접근 방식이 존재합니다.
3. A2A 내에서 컨텍스트를 전달하는 방법
A2A가 내부 메모리를 직접 공유하지는 않지만, 프로토콜이 제공하는 메커니즘을 활용하면 필요한 맥락을 명시적으로 전달할 수 있습니다.
3-1. DataPart를 활용한 구조화된 컨텍스트 전달
DataPart에 과거 대화 요약, 사용자 선호도, 작업 상태 등을 JSON 구조로 담아 전달할 수 있습니다.
{
"jsonrpc": "2.0",
"method": "tasks/send",
"params": {
"id": "task-001",
"message": {
"role": "user",
"parts": [
{
"kind": "text",
"text": "이전 대화를 바탕으로 보고서를 작성해주세요."
},
{
"kind": "data",
"data": {
"conversation_summary": "사용자가 Q1 매출 분석을 요청했고, 특히 아시아 시장에 관심이 많음",
"key_decisions": ["분석 기간: 2025 Q1", "비교 대상: 전년 동기"],
"user_preferences": {
"format": "executive_summary",
"language": "ko"
}
}
}
]
}
}
}
3-2. Artifact를 통한 작업 결과 전달
에이전트 A의 작업 결과(Artifact)를 에이전트 B의 입력으로 사용하는 파이프라인 패턴입니다.
에이전트 A (데이터 분석) → Artifact(분석 결과) → 에이전트 B (보고서 작성)
Artifact에는 텍스트, 파일, 구조화된 데이터를 모두 담을 수 있으므로, 이전 에이전트의 작업 결과를 풍부하게 전달할 수 있습니다.
3-3. contextId를 통한 대화 맥락 유지
A2A의 Message에는 contextId 필드가 있어, 같은 맥락에 속하는 메시지들을 그룹핑할 수 있습니다. 이를 통해 에이전트가 하나의 대화 흐름 안에서 맥락을 유지하며 통신할 수 있습니다.
한계
이 방법들은 모두 명시적 전달입니다. 오케스트레이터(혹은 클라이언트)가 “어떤 맥락을 전달할지”를 결정하고 직접 구성해야 합니다. 에이전트가 자동으로 과거 기억을 검색하거나 공유하는 것은 아닙니다.
4. A2A를 넘어서: 에이전트 간 메모리 공유 솔루션
A2A만으로는 부족한 부분을 보완하기 위해 여러 프로토콜과 프레임워크가 등장했습니다.
4-1. MACP (Multi-Agent Cognition Protocol)
MACP는 A2A와 MCP 사이의 간극을 메우는 공유 조정 프로토콜입니다.
핵심 아이디어: 로컬 SQLite 파일을 공유 버스로 사용하여, 에이전트 간에 메모리와 컨텍스트를 교환합니다.
에이전트 A ──┐
├──→ [ SQLite (공유 메모리) ] ←──┤
에이전트 B ──┘ ├── 에이전트 C
│
제공 기능:
| 기능 | 설명 |
|---|---|
macp_ext_set_memory |
메모리 저장 |
macp_ext_get_memory |
메모리 조회 |
macp_ext_search_memory |
메모리 검색 |
macp_ext_list_memories |
메모리 목록 |
특징:
- 제로 런타임 의존성 (TypeScript,
npm i macp) - 중앙 네트워크 서비스 불필요 (로컬 SQLite 파일로 동작)
- Claude Code, Cursor, Gemini CLI 등 주요 AI 도구 지원
- 에이전트별 독립적 워킹 컨텍스트를 유지하면서 공유 메모리 접근
활용 시나리오: 하나의 프로젝트에서 여러 에이전트가 동시에 작업할 때, 파일 소유권 시그널링, 작업 대기열 관리, 발견한 사실의 공유 등에 활용됩니다.
4-2. SAMEP (Secure Agent Memory Exchange Protocol)
SAMEP은 2025년 arXiv에 발표된 논문에서 제안된 프로토콜로, 보안이 중요한 환경에서의 에이전트 메모리 공유를 다룹니다.
해결하는 세 가지 문제:
- 세션 간 컨텍스트 영속성: 에이전트가 재시작되어도 과거 대화 맥락을 유지
- 안전한 멀티 에이전트 협업: 세밀한 접근 제어로 필요한 정보만 공유
- 효율적인 시맨틱 검색: 과거 맥락 중 관련된 것만 빠르게 찾기
기술 구성:
- 분산 메모리 저장소 + 벡터 기반 시맨틱 검색
- AES-256-GCM 암호화 기반 접근 제어
- 기존 프로토콜(MCP, A2A)과의 호환성
- HIPAA 등 규제 컴플라이언스 지원
실험 결과:
- 중복 연산 73% 감소
- 컨텍스트 관련성 점수 89% 향상
4-3. A2A Memory System (Context Engineering 접근)
A2A Memory System은 Google의 “Context Engineering: Sessions & Memory” 원칙을 구현한 오픈소스 프로젝트입니다.
다섯 가지 메모리 유형:
| 메모리 유형 | 설명 | 예시 |
|---|---|---|
| Declarative | 사실과 정책 | “회사 방침은 모든 API에 인증을 필수로 한다” |
| Procedural | 워크플로우와 절차 | “배포 프로세스: 빌드 → 테스트 → 스테이징 → 프로덕션” |
| Episodic | 특정 상호작용 기록 | “지난주 회의에서 DB 마이그레이션을 3월로 연기하기로 함” |
| Semantic | 개념과 관계 | “서비스 A는 서비스 B에 의존한다” |
| Working | 현재 작업 컨텍스트 | “지금 처리 중인 Task의 중간 결과” |
이렇게 메모리를 유형별로 분류하면, 에이전트가 상황에 맞는 메모리를 선택적으로 검색하고 공유할 수 있어 128K 토큰 컨텍스트 윈도우를 효율적으로 활용할 수 있습니다.
5. 실전 아키텍처 패턴
패턴 1: 오케스트레이터 + 공유 메모리
가장 실용적인 패턴으로, 오케스트레이터가 컨텍스트 라우팅을 담당합니다.
┌──────────────────────┐
│ Orchestrator │
│ (A2A Client) │
└──┬───────┬───────┬───┘
│ │ │
A2A │ A2A │ A2A │
│ │ │
┌──┴──┐ ┌──┴──┐ ┌──┴──┐
│ 분석 │ │ 작성 │ │ 검증 │
│Agent│ │Agent│ │Agent│
└──┬──┘ └──┬──┘ └──┬──┘
│ │ │
MCP │ MCP │ MCP │
│ │ │
┌──┴───────┴───────┴──┐
│ Shared Memory │
│ (MACP / Vector DB) │
└─────────────────────┘
동작 방식:
- 오케스트레이터가 사용자 요청을 받아 Task를 생성
- 분석 에이전트에게 A2A로 분석 요청 → 결과를 공유 메모리에 저장
- 작성 에이전트에게 A2A로 작성 요청 시, DataPart에 이전 분석 결과의 참조를 포함
- 작성 에이전트는 공유 메모리(MCP 서버)에서 상세 컨텍스트를 가져와 작업
패턴 2: 파이프라인 + Artifact 체인
에이전트의 Artifact를 다음 에이전트의 입력으로 직접 연결하는 패턴입니다.
사용자 요청
│
▼
[리서치 Agent] ──Artifact(조사 결과)──→ [분석 Agent] ──Artifact(분석 보고서)──→ [요약 Agent]
│
최종 결과물
이 패턴에서는 각 에이전트가 이전 에이전트의 산출물을 “대화 내역”처럼 받아서 작업합니다. Artifact가 곧 공유되는 컨텍스트 역할을 합니다.
패턴 3: 메모리 서버 + MCP
MCP(Model Context Protocol) 서버로 메모리 저장소를 구성하고, A2A 에이전트들이 MCP를 통해 접근하는 패턴입니다.
에이전트 A ──(MCP)──→ Memory MCP Server ←──(MCP)── 에이전트 B
│
┌─────┴─────┐
│ Vector DB │
│ (메모리) │
└───────────┘
장점:
- A2A는 에이전트 간 통신에만 집중
- 메모리 관리는 MCP 도구로 분리
- 각 에이전트가 필요한 메모리만 시맨틱 검색으로 가져옴
6. 프로토콜 간 역할 비교
| 프로토콜 | 역할 | 메모리 공유 |
|---|---|---|
| A2A | 에이전트 ↔ 에이전트 통신 | Message/Artifact를 통한 명시적 전달 |
| MCP | 에이전트 → 도구/데이터 접근 | 메모리 서버를 도구로 제공 가능 |
| MACP | 에이전트 간 실시간 조정 | SQLite 기반 공유 메모리 |
| SAMEP | 보안 메모리 교환 | 암호화된 분산 메모리 저장소 |
이 프로토콜들은 상호 배타적이지 않습니다. 오히려 함께 사용할 때 완전한 멀티 에이전트 메모리 공유 시스템을 구축할 수 있습니다.
A2A → 에이전트가 서로 대화하는 방법
MCP → 에이전트가 메모리 저장소에 접근하는 방법
MACP → 에이전트가 실시간으로 컨텍스트를 조정하는 방법
SAMEP → 메모리를 안전하게 암호화하고 접근 제어하는 방법
7. 현실적인 한계와 고려사항
표준화의 현재 상태
A2A v1.0.0이 2026년 3월에 출시되었지만, 에이전트 간 메모리 공유에 대한 공식 표준은 아직 없습니다. 현재의 인터롭 표준들(A2A, MCP, AG-UI)은 “통신”을 해결하지만 “인지”는 해결하지 않는다는 지적이 있습니다.
“Standards without shared memory create connected strangers.” — MemU Blog
토큰 효율성
과거 대화를 통째로 전달하면 토큰 사용량이 급증합니다. 실제로는 다음과 같은 최적화가 필요합니다.
- 요약(Summarization): 긴 대화를 핵심 포인트로 압축
- 시맨틱 검색: 현재 작업에 관련된 과거 맥락만 선택적으로 가져오기
- 계층적 메모리: 중요도에 따라 메모리를 계층화하여 관리
보안 고려사항
에이전트 간 메모리를 공유할 때 반드시 고려해야 할 점들입니다.
- 어떤 에이전트가 어떤 메모리에 접근 가능한지 접근 제어
- 민감 정보의 암호화 (SAMEP의 AES-256-GCM 등)
- 메모리 교환의 감사 로그 (특히 규제 환경)
- 한 에이전트의 hallucination이 다른 에이전트로 전파되는 오염 방지
8. 정리
A2A 프로토콜은 에이전트 간 통신의 표준을 제공하지만, 과거 대화 내역과 메모리의 직접적인 공유 메커니즘은 내장되어 있지 않습니다. 이는 보안과 독립성을 위한 의도적인 설계입니다.
하지만 다음과 같은 방법으로 에이전트 간 대화 내역과 메모리를 공유할 수 있습니다.
| 방법 | 난이도 | 설명 |
|---|---|---|
| A2A DataPart로 명시적 전달 | 낮음 | 오케스트레이터가 필요한 맥락을 DataPart에 담아 전달 |
| Artifact 체인 | 낮음 | 이전 에이전트의 산출물을 다음 에이전트의 입력으로 연결 |
| MCP 메모리 서버 | 중간 | Vector DB 기반 MCP 서버를 공유 메모리로 활용 |
| MACP 프로토콜 | 중간 | SQLite 기반 실시간 공유 메모리 |
| SAMEP 프로토콜 | 높음 | 암호화된 분산 메모리 저장소로 엔터프라이즈급 메모리 공유 |
멀티 에이전트 시스템에서 메모리 공유는 아직 발전 중인 영역입니다. 하지만 A2A + MCP를 기반으로 MACP나 SAMEP 같은 보완 프로토콜을 결합하면, 에이전트들이 과거 대화와 학습한 맥락을 효과적으로 공유하는 시스템을 지금도 구축할 수 있습니다.