MCP 다음은 A2A다 《2》
MCP 다음은 A2A다
Agent끼리 통신하는 아키텍처는 언제 필요한가
앞선 글에서는 Multi-Agent 구조를 만들 때 모든 전문 기능을 Agent로 분리할 필요는 없다는 이야기를 했습니다.
정해진 절차
+
명확한 Tool
↓
Skill + MCP반대로 이런 작업은 조금 다릅니다.
탐색
+
가설
+
반복 판단
+
독립적인 Context
↓
Agent그렇다면 실제로 Agent를 분리해야 할 때는 어떻게 연결해야 할까요?
같은 애플리케이션 안의 객체라면 직접 호출하면 됩니다.
하지만 Agent가
- 다른 서버에서 실행되고
- 다른 팀이 관리하고
- 다른 언어와 Framework로 만들어졌으며
- 서로 다른 모델과 Context를 사용하고
- 몇 분 또는 몇 시간 동안 독립적으로 작업한다면
단순한 Function Call로 보기 어려워집니다.
이때 등장하는 것이 A2A, Agent2Agent Protocol입니다.
현재 A2A 공식 사양은 0.3.0까지 발전했고, JSON-RPC뿐 아니라 HTTP+JSON, gRPC까지 Transport 범위가 확장됐습니다.
그리고 2026년 9월에는 Linux Foundation 산하 Agentic AI Foundation(AAIF)의 Hosted Project로 들어가면서 특정 Vendor의 Agent Protocol보다 산업 표준에 가까운 방향으로 움직이고 있습니다.
A2A를 한 문장으로 정리하면 이렇습니다.
MCP가 Agent에게 Tool을 연결하는 표준이라면, A2A는 독립된 Agent에게 일을 맡기는 표준에 가깝습니다.
1. MCP와 A2A는 경쟁 관계가 아니다
A2A 이야기가 나오면 가장 먼저 생기는 오해가 있습니다.
MCP
vs
A2A둘 중 하나를 선택해야 한다는 생각입니다.
하지만 역할이 다릅니다.
MCP는 Agent가 사용할 Capability를 제공합니다.
Agent
↓
MCP
↓
GitHub
Database
Browser
CIAgent가 직접 판단하고 Tool을 호출합니다.
반면 A2A는 다른 Agent에게 Task 자체를 위임합니다.
Main Agent
↓
A2A
↓
Security Agent
↓
Security ToolsMain Agent는 Security Agent 내부 Tool을 직접 제어할 필요가 없습니다.
Security Agent가 자신의 Context와 Tool을 이용해 스스로 판단합니다.
정리하면:
MCP
"이 기능을 실행해줘."에 가깝고,
A2A
"이 일을 맡아줘."에 가깝습니다.
2. Tool과 Agent의 가장 큰 차이는 독립적인 판단이다
예를 들어 다음 Function이 있다고 해보겠습니다.
run_swiftlint()Input과 Output이 명확합니다.
Input
→ Project
Output
→ Findings이건 Tool입니다.
반면 이런 요청은 다릅니다.
이번 배포 이후 Crash가 늘어난 원인을 찾아줘.
이 작업에는 정해진 호출 순서가 없습니다.
Agent는 먼저 Crash 데이터를 확인할 수 있습니다.
Crash Rate
↓
특정 iOS Version인가?그다음:
최근 Release 확인
↓
관련 Commit 검색또는:
API Error 확인
↓
Backend 변경 확인으로 갈 수도 있습니다.
중간 결과를 보고 새로운 가설을 세웁니다.
Observe
↓
Hypothesis
↓
Tool Call
↓
Verify
↓
Re-plan이 정도가 되면 Function Call보다는 독립적인 Agent Task에 가깝습니다.
A2A는 바로 이런 Agent 사이의 경계를 표준화합니다.
3. 가장 현실적인 예 — Coding Agent와 Security Agent
개발팀에 Coding Agent가 있다고 해보겠습니다.
Coding Agent
Repository 분석
코드 생성
Refactoring
Test보안팀에는 별도의 Security Agent가 있습니다.
Security Agent
SAST
Dependency Scan
Secret Scan
Threat Model
Security PolicyCoding Agent가 PR을 만든 뒤 보안 검토가 필요합니다.
여기서 Security Tool을 Coding Agent에게 전부 제공할 수도 있습니다.
Coding Agent
+
Security Tools
+
Security Prompt
+
Security Policy하지만 시스템이 커질수록 문제가 생깁니다.
Coding Agent가 보안팀의 내부 규칙과 Tool까지 알아야 합니다.
Security Tool이 바뀌면 Coding Agent도 영향을 받습니다.
Security Context 역시 Main Agent Context에 들어옵니다.
대신 Security Agent를 독립적으로 두면:
Coding Agent
↓
A2A
↓
Security Agent
↓
Security Tools구조가 됩니다.
Coding Agent가 해야 할 일은 단순합니다.
"이 PR의 보안 위험을 검토해줘."입니다.
Security Agent가 내부적으로 어떤 Scanner를 사용하는지는 Coding Agent가 몰라도 됩니다.
4. 다른 팀이 소유한 Agent라면 A2A가 더 자연스럽다
A2A가 특히 의미 있는 지점이 팀 경계입니다.
예를 들어 회사에 다음 Agent들이 있다고 해보겠습니다.
개발팀
Coding Agent
SRE팀
Incident Agent
보안팀
Security Agent
법무팀
Compliance Agent각 Agent는 서로 다른 팀에서 운영합니다.
각 팀은 자신들의 Agent에 대해
Model
Prompt
Knowledge
Tools
Permission
Deploy Cycle을 독립적으로 관리합니다.
Main Agent가 이 내부 구현까지 알 필요는 없습니다.
Coding Agent
↓
A2A
↓
Compliance Agent형태로 Task만 전달합니다.
이 경우 A2A는 단순 Agent 연결 기술이 아니라 조직의 Ownership Boundary를 유지하는 방법이 됩니다.
5. Agent Card는 Agent용 API 문서에 가깝다
독립적인 Agent끼리 연결하려면 먼저 알아야 할 것이 있습니다.
저 Agent가 뭘 할 수 있지?
A2A에서는 이를 Agent Card로 표현합니다.
Agent Card는 JSON 형태의 Metadata Document입니다.
대략 이런 정보를 갖습니다.
Agent Card
├─ name
├─ description
├─ version
├─ capabilities
├─ skills
├─ endpoint
├─ supported transports
└─ authentication requirements예를 들어 Security Agent가 다음 Capability를 공개할 수 있습니다.
Security Review Agent
Skills
- dependency-security-review
- code-security-review
- secret-detectionClient Agent는 Agent Card를 보고 이 Agent가 자신의 Task를 처리할 수 있는지 판단합니다.
기본적인 Discovery 방식 중 하나는:
/.well-known/agent-card.json입니다.
Enterprise 환경에서는 Agent Registry나 Catalog를 사용할 수도 있습니다.
개념적으로 보면 Agent Card는 Agent 세계의 OpenAPI Document와 비슷한 역할을 합니다.
6. 최신 A2A에서는 Transport도 하나로 고정되지 않는다
A2A 초기 버전은 JSON-RPC 중심이었습니다.
현재 0.3.0에서는 Core Transport로 다음 방식을 정의합니다.
JSON-RPC
gRPC
HTTP+JSONAgent는 자신이 지원하는 Interface를 Agent Card에 공개할 수 있습니다.
예를 들어:
Security Agent
JSON-RPC
→ https://security.example.com/a2a
gRPC
→ grpc.security.example.com
HTTP+JSON
→ https://security.example.com/v1같은 식입니다.
Client는 지원되는 Transport 중 적절한 것을 선택합니다.
이 변화는 A2A가 단순한 Agent SDK 기능에서 분산 시스템 Protocol로 발전하고 있다는 신호이기도 합니다.
7. A2A의 중심은 Message보다 Task다
일반적인 Chat 시스템에서는 Message가 중심입니다.
User Message
↓
Assistant MessageA2A에서는 Agent에게 긴 작업을 맡길 수 있기 때문에 Task라는 개념이 중요합니다.
예를 들어 Architecture Review Agent에게:
이 Repository 전체의
Architecture 문제를 분석해줘.라고 요청했다고 해보겠습니다.
몇 초 안에 끝나지 않을 수 있습니다.
Task는 상태를 가집니다.
Submitted
↓
Working
↓
Input Required
↓
Working
↓
Completed또는
Failed
Canceled
Rejected로 종료될 수도 있습니다.
즉 A2A는 단순 RPC보다 비동기 Job Protocol에 더 가까운 부분이 있습니다.
8. 결과는 Message가 아니라 Artifact가 될 수 있다
Agent가 만드는 결과도 단순 Text Response만 있는 것이 아닙니다.
A2A에는 Artifact라는 개념이 있습니다.
예를 들어 Security Agent가 작업 결과로:
security-report.json
security-review.md
dependency-risk.csv를 만들 수 있습니다.
Architecture Agent라면:
architecture-review.md
dependency-graph.json을 반환할 수 있습니다.
구조는:
Task
│
├─ Messages
│
└─ Artifacts입니다.
Message는 Agent끼리 통신하는 내용이고,
Artifact는 실제 작업 결과물입니다.
이 구분은 Long-running Agent를 설계할 때 꽤 중요합니다.
9. Streaming도 Agent 협업에서는 중요하다
Agent 작업이 10분 걸린다고 생각해보겠습니다.
완료될 때까지 아무 응답이 없다면 Client에서는 장애인지 작업 중인지 알기 어렵습니다.
A2A는 Streaming을 지원합니다.
Main Agent
↓
Architecture Agent
"Repository 분석 시작"
↓
"Dependency 분석 완료"
↓
"순환 의존성 발견"
↓
"Report 생성 중"
↓
Artifact현재 Protocol에서는 SSE를 이용한 Streaming뿐 아니라 Transport에 따라 Streaming 방식을 지원할 수 있습니다.
즉 Client Agent가 Remote Agent의 진행 상태를 실시간으로 받을 수 있습니다.
10. 몇 시간짜리 작업이라면 Push가 더 자연스럽다
모든 Agent가 Streaming Connection을 계속 유지할 필요는 없습니다.
예를 들어 Research Agent에게:
지난 6개월 경쟁사 기술 변화와
GitHub Release를 조사해서
보고서 만들어줘.라고 요청했다고 해보겠습니다.
30분이 걸릴 수도 있습니다.
이 경우:
Request
↓
Connection 30분 유지보다:
Task 생성
↓
Connection 종료
↓
Agent Background Processing
↓
완료
↓
Webhook이 더 자연스럽습니다.
A2A는 Push Notification 방식도 정의합니다.
Long-running Task와 잘 맞는 이유입니다.
11. 다른 언어와 Framework를 연결할 때 A2A가 빛난다
Production 환경에서는 모든 Agent가 같은 Framework로 만들어지지 않습니다.
예를 들어:
Coding Agent
Python
LangGraph보안팀은:
Security Agent
Go
Custom Runtime법무팀은:
Compliance Agent
.NET
Microsoft Agent Framework일 수 있습니다.
이 Agent들을 모두 하나의 Framework로 다시 만드는 것은 현실적이지 않습니다.
A2A에서는 Protocol만 맞으면 됩니다.
Python Agent
↓
A2A
↓
Go AgentGoogle도 2026년 실제 개발 예제로 Python 기반 Contract Extraction Agent와 Go 기반 Compliance Agent를 A2A로 연결하는 구조를 공개했습니다.
이게 A2A의 대표적인 장점입니다.
Agent Framework보다 Protocol Boundary를 기준으로 시스템을 연결할 수 있습니다.
12. 같은 애플리케이션 안의 Subagent라면 A2A는 과할 수 있다
여기서 중요한 점이 있습니다.
Agent가 두 개라고 무조건 A2A를 쓸 필요는 없습니다.
예를 들어 같은 Process 안에서:
Main Agent
├─ Planning Agent
├─ Coding Agent
└─ Test Agent를 단순히 역할 분리용으로 사용하고 있다고 해보겠습니다.
모든 Agent가
같은 Runtime
같은 Deployment
같은 Team
같은 Model Provider에 있다면 A2A는 오히려 복잡도를 늘릴 수 있습니다.
Network
Serialization
Timeout
Retry
Authentication
Versioning
Tracing문제가 추가됩니다.
이런 경우에는 Framework 내부의
Subagent
Agent as Tool
Handoff정도로 충분할 수 있습니다.
A2A는 Agent가 있다는 이유로 쓰는 것이 아니라 실제 시스템 경계가 있을 때 쓰는 것이 자연스럽습니다.
13. A2A를 쓰는 순간 분산 시스템 문제가 생긴다
A2A는 Agent Architecture 문제만이 아닙니다.
Network Boundary가 생깁니다.
그래서 기존 Backend와 비슷한 문제가 다시 나타납니다.
Timeout
Retry
Partial Failure
Authentication
Authorization
Version Compatibility
Observability예를 들어 Main Agent가 Security Agent에게 Task를 보냈는데 응답이 없습니다.
요청 실패인가?
아직 작업 중인가?
Agent Process가 죽었나?
Network가 끊겼나?를 구분해야 합니다.
Task ID와 상태가 중요한 이유입니다.
Agent 시스템도 결국 Production에 들어가면 분산 시스템 Engineering이 됩니다.
14. Retry도 단순히 다시 보내면 안 된다
이 부분은 실무에서 특히 중요합니다.
예를 들어:
"Production Deploy 실행해줘."라는 Task를 Remote Agent에게 보냈습니다.
응답이 Timeout됐습니다.
Client가 그냥 다시 보내면:
Deploy #1
Deploy #2가 실행될 수도 있습니다.
따라서 실제 Production A2A에서는:
Task ID
Operation ID
Idempotency
State Persistence같은 설계가 필요합니다.
Protocol이 있다고 Distributed System Design이 사라지는 것은 아닙니다.
오히려 Agent가 실제 Action을 수행하기 시작하면 더 중요해집니다.
15. Authentication과 Authorization도 Agent Card와 연결된다
A2A Agent Card에는 해당 Agent가 어떤 인증 방식을 요구하는지 선언할 수 있습니다.
하지만:
Agent Card에
"OAuth 사용"이라고 적는 것만으로 보안이 끝나는 것은 아닙니다.
실제 Agent Server에서는 매 요청마다 Authentication과 Authorization을 적용해야 합니다.
예를 들어 Security Agent가:
scan_repository
read_security_report
change_security_policySkill을 제공한다고 해도 사용자마다 권한은 다를 수 있습니다.
Developer
scan_repository ⭕
change_security_policy ❌처럼 Service Layer에서 검증해야 합니다.
A2A 공식 사양 역시 서버가 각 요청을 인증하고 최소 권한 원칙을 적용하도록 요구합니다.
16. Agent Card도 공개 정보와 내부 정보를 나눌 수 있다
Agent Card에는 Capability 정보가 들어갑니다.
하지만 Enterprise Agent라면 모든 Capability를 외부에 공개하고 싶지 않을 수 있습니다.
현재 A2A 사양에는 Authenticated Extended Agent Card 개념도 있습니다.
처음에는 Public Agent Card만 제공합니다.
Public Agent Card
Security Review 가능인증 이후에는:
Extended Agent Card
Dependency Scan
Source Scan
Internal Policy Review
Production Audit처럼 더 상세한 Capability를 제공할 수 있습니다.
Agent Discovery 자체에도 Security Boundary가 생기는 것입니다.
17. MCP + Skill + A2A를 같이 쓰면 구조가 이렇게 된다
앞선 글과 연결하면 가장 현실적인 Agent Architecture는 이런 형태입니다.
Main Coding Agent
│
┌──────────────────┼──────────────────┐
│ │ │
Swift Migration Release Skill Security Agent
Skill │ │
│ │ A2A
MCP MCP │
│ │ Security Runtime
Compiler/Test CI │
MCP
│
Security Tools여기서:
Skill
→ 작업 절차MCP
→ Tool / CapabilityA2A
→ 독립 Agent에게 Task 위임을 담당합니다.
셋은 대체 관계가 아닙니다.
각자 다른 Layer입니다.
18. 실제 개발팀에서는 이런 구조가 가능하다
조금 더 현실적인 예를 만들어보겠습니다.
Developer
↓
Coding AgentCoding Agent는 Swift 6 Migration을 수행합니다.
Coding Agent
↓
Swift 6 Migration Skill
↓
Compiler MCP코드를 수정한 뒤 Security Review가 필요합니다.
Coding Agent
↓ A2A
Security AgentSecurity Agent는 자기 Tool을 사용합니다.
Security Agent
↓
Security Skill
↓
MCP
↓
CodeQL
Dependency Scanner
Secret Scanner그리고 Production에서 장애가 발생하면:
Main Agent
↓ A2A
Incident AgentIncident Agent가 독립적으로:
Logs
Metrics
Tracing
Deploy History를 분석합니다.
이 구조에서 Main Agent가 모든 Tool Schema와 Domain Prompt를 가질 필요가 없습니다.
19. A2A가 필요한지 판단하는 기준
Agent를 Remote Service로 분리하기 전에 다음 질문을 해보면 됩니다.
다른 팀이 소유하는가?
YES
→ A2A 후보별도 Deployment Cycle이 필요한가?
YES
→ A2A 후보다른 언어나 Framework로 구현됐는가?
YES
→ A2A 후보독립적인 Context와 Memory가 필요한가?
YES
→ A2A 후보몇 분 이상 장시간 작업하는가?
YES
→ A2A 후보자체적으로 탐색하고 재계획하는가?
YES
→ A2A 후보반대로:
같은 Process
같은 Team
정해진 Procedure
명확한 Tool정도라면 A2A까지 갈 필요가 없을 가능성이 높습니다.
20. A2A의 최근 흐름도 달라지고 있다
A2A는 2025년 Google이 공개한 Protocol에서 시작했습니다.
하지만 지금은 Google 전용 Protocol로 보는 것도 조금 맞지 않습니다.
현재 A2A는 Linux Foundation의 Agentic AI Foundation에서 운영되는 Open Standard로 이동했고, 150개가 넘는 조직이 참여하는 생태계로 확대되고 있습니다.
공식 A2A 사양도 현재 0.3.0까지 발전했습니다.
특히 최근에는:
Agent Discovery
Multi Transport
Authentication
Streaming
Push Notification
Long-running Task
Artifact Exchange처럼 실제 Production Agent를 운영하는 데 필요한 영역들이 구체화되고 있습니다.
즉 A2A가 단순한
Agent끼리 Chat한다.수준에서
Distributed Agent Runtime을
어떻게 연결할 것인가.라는 문제로 이동하고 있습니다.
21. 결국 A2A는 Agent용 HTTP에 가까워질 수 있다
HTTP가 등장했다고 모든 Function Call을 HTTP로 바꾸지는 않습니다.
같은 Process 안에서는 그냥 Function을 호출합니다.
function()서비스 경계가 생겼을 때 HTTP가 의미를 갖습니다.
Service A
↓ HTTP
Service BA2A도 비슷하게 볼 수 있습니다.
같은 Runtime
→ Subagent / Agent as ToolCapability 호출
→ MCP독립 Agent Runtime
→ A2A입니다.
그래서 A2A를 Agent끼리 대화하는 새로운 기능 정도로 보기보다 Agent 시스템 사이의 Network Contract로 보는 편이 더 정확합니다.
마치며
앞선 글에서는 모든 전문 기능을 Agent로 만들 필요가 없다는 이야기를 했습니다.
정해진 절차
+
명확한 Tool
↓
Skill + MCP가 더 단순한 경우가 많습니다.
하지만 Agent를 정말 분리해야 하는 순간도 있습니다.
독립적인 판단
별도 Context
별도 Runtime
별도 Team
장시간 Workflow
다른 언어 / Framework가 필요하다면 Agent 자체가 하나의 독립 서비스가 됩니다.
그리고 그때 필요한 것이 A2A입니다.
정리하면 세 가지의 역할은 꽤 명확합니다.
Skill
"어떻게 일할 것인가"MCP
"무엇을 실행할 수 있는가"A2A
"어떤 Agent에게 일을 맡길 것인가"이 세 가지를 같이 보면 최근 Agent Architecture의 방향도 조금 더 명확해집니다.
모든 기능을 하나의 거대한 Agent에 넣을 필요도 없고,
모든 기능을 Specialist Agent로 만들 필요도 없습니다.
Main Agent
│
├─ Skill
│ └─ MCP Tool
│
├─ Skill
│ └─ MCP Tool
│
└─ A2A
↓
Independent Agent
↓
MCP형태의 Hybrid Architecture가 오히려 더 현실적입니다.
결국 Agent Architecture를 설계할 때 중요한 질문은 Agent가 몇 개인지가 아닙니다.
이 기능이 단순 Capability인가, 아니면 독립적으로 일을 맡길 수 있는 시스템인가.
A2A는 후자가 필요해지는 순간부터 의미가 생깁니다.
참고자료
-
A2A Protocol — Official Specification 0.3.0
Agent Card, Task, Message, Artifact, Streaming, Push Notification과 JSON-RPC·gRPC·HTTP+JSON Transport를 포함한 현재 공식 A2A 사양입니다.
A2A 0.3.0 공식 Specification 보기 -
A2A Protocol — Core Concepts
Agent Card, Task, Message, Part, Artifact 등 A2A의 핵심 Domain Model을 정리한 공식 문서입니다.
A2A Core Concepts 보기 -
Google Developers — Build Cross-Language Multi-Agent Team with ADK and A2A
Python으로 만든 Contract Extraction Agent와 Go 기반 Compliance Agent를 A2A로 연결하는 실무 예제를 확인할 수 있습니다.
Google A2A Cross-Language 사례 보기 -
Microsoft Agent Framework — A2A Agent Service
Agent Card Discovery, Remote Agent 연결, Streaming, Background Response와 Long-running Task를 Microsoft Agent Framework에서 사용하는 방법을 확인할 수 있습니다.
Microsoft A2A 공식 문서 보기 -
Linux Foundation — A2A / Agentic AI Foundation
A2A가 Linux Foundation 산하 Agentic AI Foundation의 Hosted Project로 운영되는 현재 생태계와 표준화 흐름을 확인할 수 있습니다.
Linux Foundation 공식 자료 보기
현재 공식 A2A 사양은 0.3.0이며, Agent Card를 통한 Discovery, 상태를 가지는 Task, 결과물인 Artifact, Streaming과 Push Notification을 중심으로 독립 Agent 간 장기 작업을 다룰 수 있도록 설계되어 있습니다. 0.3.0에서는 JSON-RPC, gRPC, HTTP+JSON을 핵심 Transport로 정의하고 있습니다.
또한 A2A는 현재 Linux Foundation 산하 AAIF의 Hosted Project로 운영되고 있으며, Linux Foundation은 2026년 9월 기준 150개가 넘는 조직이 A2A 생태계에 참여하고 있다고 설명하고 있습니다. 따라서 현재 흐름은 특정 Agent Framework의 내부 기능보다 서로 다른 Vendor·Language·Runtime의 Agent를 연결하기 위한 독립적인 Protocol Layer에 더 가깝습니다.
:::
