---
title: "A2A와 MCP로 보는 멀티 에이전트 개발 워크플로우"
slug: "coding-agent-runtime-03-a2a-mcp-workflow"
canonicalUrl: "https://moonshotnotes.com/posts/coding-agent-runtime-03-a2a-mcp-workflow/"
sourceUrl: "https://moonshotnotes.com/posts/coding-agent-runtime-03-a2a-mcp-workflow/"
markdownUrl: "https://moonshotnotes.com/agent/posts/coding-agent-runtime-03-a2a-mcp-workflow.md"
language: "ko"
category: "AI Agent"
updatedAt: "2026-05-06"
agentTokenEstimate: 1724
---

# A2A와 MCP로 보는 멀티 에이전트 개발 워크플로우

A2A Protocol v1.0과 MCP의 차이를 기준으로 Agent Card, Task, Artifact를 개발 하네스의 작업 위임과 산출물 계약으로 해석합니다.

## Agent metadata

- Source: https://moonshotnotes.com/posts/coding-agent-runtime-03-a2a-mcp-workflow/
- Markdown: https://moonshotnotes.com/agent/posts/coding-agent-runtime-03-a2a-mcp-workflow.md
- Language: ko
- Category: AI Agent
- Tags: A2A, MCP, Multi Agent, Agent Card, Artifact, AI Agent
- Updated: 2026-05-06
- Estimated tokens: 1724

멀티 에이전트 개발은 에이전트를 많이 붙인다고 좋아지지 않습니다. 역할과 산출물 계약 없이 에이전트를 늘리면 책임만 흐려지고, 한 에이전트의 잘못된 판단이 다음 단계로 전파됩니다.

그래서 멀티 에이전트 설계의 출발점은 “몇 개의 에이전트를 둘 것인가”가 아니라 **누가 무엇을 할 수 있고, 어떤 입력을 받고, 어떤 산출물을 남기는가**입니다.

1편에서는 코딩 에이전트를 런타임으로 봐야 한다고 정리했습니다. 2편에서는 Goal Runtime을 다뤘습니다. 이번 3편에서는 여러 에이전트가 함께 일하는 구조를 다룹니다. 핵심 키워드는 A2A와 MCP입니다.

## 핵심 요약

- MCP는 Agent-to-Tool 축에 가깝습니다.
- A2A는 Agent-to-Agent 축에 가깝습니다.
- 멀티 에이전트 개발에서는 “누가 무엇을 할 수 있는가”를 설명하는 Agent Card가 필요합니다.
- 작업은 대화 메시지가 아니라 상태를 가진 Task로 관리해야 합니다.
- 결과물은 채팅 응답이 아니라 Artifact로 분리해야 합니다.
- 개발 하네스에서는 A2A 전체를 당장 구현하지 않더라도 Task/Artifact 모델을 차용할 수 있습니다.

## MCP와 A2A는 해결하는 문제가 다르다

AI 에이전트 생태계에서 MCP와 A2A는 자주 함께 언급됩니다. 하지만 둘은 같은 문제를 해결하지 않습니다.

[A2A 공식 문서의 MCP 비교](https://a2a-protocol.org/dev/topics/a2a-and-mcp/)는 MCP가 agent가 database나 API 같은 도구와 리소스를 사용하는 방식을 다루고, A2A는 agent-to-agent collaboration을 가능하게 하는 별도 축이라고 설명합니다.

짧게 정리하면 축이 다릅니다.

```mermaid
%% MCP와 A2A는 같은 agent runtime 안에서도 서로 다른 연결 축을 담당한다.
flowchart TD
  Boundary["에이전트 연결 경계"] --> ToolAxis["MCP: 도구 호출"]
  Boundary --> AgentAxis["A2A: 작업 위임"]
  ToolAxis --> Tools["도구 / API / DB / 파일 시스템"]
  AgentAxis --> Agents["리뷰 / 테스트 / 문서화 에이전트"]
```

| 구분 | MCP | A2A |
|---|---|---|
| 연결 대상 | 도구, API, DB, 파일 시스템 | 다른 에이전트 |
| 핵심 질문 | 이 에이전트가 무엇을 사용할 수 있는가? | 이 에이전트가 누구에게 일을 맡길 수 있는가? |
| 주요 목적 | tool/resource access | agent collaboration |
| 개발 하네스 적용 | 테스트 실행, 파일 검색, DB 조회 | 코드 리뷰, 테스트 분석, 문서화 위임 |

## Agent-to-Tool과 Agent-to-Agent

개발 하네스를 만들 때 이 차이를 놓치면 구조가 꼬입니다.

다음은 MCP에 가까운 작업입니다.

```text
파일 읽기
테스트 실행
Git diff 조회
DB schema 확인
API 문서 검색
```

반면 다음은 A2A에 가까운 작업입니다.

```text
보안 리뷰 에이전트에게 변경사항 검토 요청
테스트 에이전트에게 실패 테스트 분석 요청
문서화 에이전트에게 migration note 작성 요청
성능 분석 에이전트에게 병목 후보 정리 요청
```

MCP는 능력을 확장합니다. A2A는 책임을 분리합니다.

개발 하네스에서는 도구 호출과 작업 위임을 아래처럼 분리해 다뤄야 합니다.

```mermaid
%% MCP는 도구 접근, A2A는 역할 위임을 담당한다.
flowchart TD
  Lead["Lead Coding Agent"] -->|MCP| Tools["git, test, file, search"]
  Lead -->|A2A| Review["Review Agent"]
  Lead -->|A2A| Test["Test Agent"]
  Lead -->|A2A| Docs["Docs Agent"]
  Review --> ReviewArtifact["review artifact"]
  Test --> TestArtifact["test artifact"]
  Docs --> DocsArtifact["docs artifact"]
```

## Agent Card는 에이전트의 자기소개서다

[A2A Protocol v1.0 발표](https://a2a-protocol.org/latest/announcing-1.0/)는 A2A를 AI agent 간 communication을 위한 stable, production-ready open standard라고 설명합니다. 이 프로토콜에서 중요한 개념 중 하나가 Agent Card입니다.

Agent Card는 에이전트가 어떤 능력을 가지는지, 어떤 방식으로 통신하는지, 어떤 입력과 출력을 지원하는지를 설명합니다.

개발 하네스 관점에서는 Agent Card를 이렇게 볼 수 있습니다.

```json
{
  "name": "Code Review Agent",
  "description": "보안, 유지보수성, 테스트 누락을 중심으로 PR을 검토한다.",
  "skills": [
    "review-diff",
    "detect-risky-auth-change",
    "suggest-test-cases"
  ],
  "inputModes": ["diff", "file-list", "test-result"],
  "outputModes": ["review-artifact"],
  "requiresApprovalFor": [
    "suggest-db-migration",
    "modify-auth-policy"
  ]
}
```

Agent Card가 없으면 Lead Agent는 다른 에이전트가 무엇을 잘하는지 알 수 없습니다. 사람 팀에서도 역할 정의가 필요하듯, 에이전트 팀에서도 역할 정의가 필요합니다.

## Task는 상태를 가진 작업 단위다

[A2A specification](https://a2a-protocol.org/v0.2.6/specification/)은 Task를 A2A server가 처리하는 stateful unit of work로 설명합니다. Task는 id, contextId, status, history, artifacts 같은 필드를 가질 수 있습니다.

개발 하네스에서 Task는 다음처럼 해석할 수 있습니다.

```text
Task:
  id: review-payment-webhook-change
  owner: security-review-agent
  input:
    - changed files
    - payment webhook diff
    - related tests
  status: input_required
  question:
    현재 webhook signature 검증 로직 변경이 포함되어 있습니다.
    기존 secret rotation 정책을 확인할 수 없으므로 구현을 중단하고 사용자 승인을 요청합니다.
```

여기서 중요한 상태는 `input_required`입니다. 에이전트가 위험한 결정을 직접 하지 않고 사람에게 되묻는 상태가 필요합니다.

```text
계속 진행해도 되는가?
mock으로 대체해도 되는가?
DB migration을 생성해도 되는가?
외부 API를 호출해도 되는가?
```

이 질문이 사라지면 자동화는 빨라지지만 위험해집니다.

## Artifact는 검토 가능한 결과물이다

Artifact는 에이전트가 만든 결과물입니다. [A2A v0.1 specification](https://a2a-protocol.org/v0.1.0/specification/)은 artifact를 task 중 생성된 tangible output으로 설명합니다.

코딩 에이전트에서 artifact는 특히 중요합니다. 채팅 메시지는 흘러갑니다. Artifact는 검토됩니다.

| 나쁜 결과 | 좋은 Artifact |
|---|---|
| “수정했습니다” | 변경 파일 목록 |
| “테스트 통과했습니다” | 실행 명령과 로그 요약 |
| “문제 없어 보입니다” | blocker, warning, suggestion 분류 |
| “기억해둘게요” | source, scope, validated_at이 있는 memory candidate |

실무에서는 마지막 응답보다 artifact contract가 더 중요합니다.

```text
Review Artifact:
  Summary:
    결제 webhook 변경사항을 검토했다.

  Blockers:
    - signature 검증 실패 시 fallback 경로가 없다.

  Warnings:
    - retry 정책이 기존 결제 API와 다르다.

  Verified:
    - unit test 12개 통과
    - webhook parser 변경 없음

  Not Verified:
    - 실제 PG sandbox 호출은 수행하지 않음
```

이런 artifact가 있어야 사람이 검토할 수 있습니다.

## 개발 워크플로우에 적용하기

멀티 에이전트 구조를 처음부터 복잡하게 만들 필요는 없습니다.

MVP 단계에서는 다음 정도면 충분합니다.

| 역할 | 설명 |
|---|---|
| Lead Agent | 목표 분해, 실행 순서 결정, 최종 요약 |
| Implementation Agent | 코드 수정 |
| Test Agent | 테스트 생성과 실패 분석 |
| Review Agent | 리스크와 누락 검토 |
| Human Owner | 승인, 배포, 최종 병합 판단 |

핵심은 모든 에이전트를 실제 별도 프로세스로 나누는 것이 아닙니다. 처음에는 한 에이전트 안에서 역할만 분리해도 됩니다.

```text
이번 단계에서는 Test Agent 역할로만 행동한다.
목표는 실패 테스트 원인 분석이다.
코드 수정은 하지 말고 test artifact만 남긴다.
```

이 방식은 단순하지만 효과가 큽니다. 에이전트가 한 번에 분석, 구현, 테스트, 리뷰를 모두 하려고 하면 산출물이 흐려집니다. 역할을 나누면 결과물이 선명해집니다.

## 멀티 에이전트의 리스크

멀티 에이전트는 강력하지만 리스크도 큽니다. [MetaGPT 논문](https://arxiv.org/abs/2308.00352)은 여러 LLM agent를 단순 연결하면 오류가 전파될 수 있으며, 이를 줄이기 위해 SOP와 modular output을 강제하는 접근을 제안합니다. [ChatDev 논문](https://arxiv.org/abs/2307.07924)도 소프트웨어 개발을 여러 communicative agents의 협업으로 모델링하지만, 이런 구조가 작동하려면 역할, 단계, 대화 방식, 검증이 필요합니다.

실무 리스크는 다음과 같습니다.

| 리스크 | 설명 | 대응 |
|---|---|---|
| 책임 불명확 | 누가 최종 판단을 하는지 모름 | Lead Agent와 Human Owner 분리 |
| 오류 전파 | 한 에이전트의 잘못된 분석이 다음 단계로 전달 | Artifact 검토 단계 추가 |
| 과도한 자동화 | 승인 없이 위험 작업 수행 | Permission Gate |
| 산출물 혼합 | 대화와 결과가 섞임 | Artifact Contract |
| 비용 증가 | 여러 에이전트 반복 호출 | Task budget 설정 |

## 체크리스트

멀티 에이전트 구조를 설계할 때는 에이전트 수보다 아래 계약이 먼저입니다.

```text
[ ] MCP와 A2A 역할을 구분했다.
[ ] Lead Agent 책임을 정의했다.
[ ] 각 Agent의 입력과 출력을 정의했다.
[ ] Task 상태를 기록한다.
[ ] Artifact 형식을 정했다.
[ ] input_required 상태에서 사람에게 질문한다.
[ ] 최종 판단자는 Human Owner로 남겨뒀다.
[ ] 위험 작업에는 Permission Gate가 있다.
```

## 이번 편에서 가져갈 기준

MCP는 에이전트가 사용할 수 있는 도구를 늘리고, A2A는 다른 에이전트에게 맡길 수 있는 책임을 정의합니다. 둘을 섞으면 구조가 흐려집니다. 멀티 에이전트 MVP는 Agent Card, Task 상태, Artifact 형식부터 잡아야 합니다.

## 다음 편

4편에서는 memory로 넘어갑니다. 특히 AI Memory를 RAG와 구분하고, 실패 로그와 Run Ledger를 어떻게 다뤄야 하는지 정리합니다.

## 시리즈 이어 읽기

- 1편: 코딩 에이전트는 왜 런타임이 되는가
- 2편: Codex `/goal`로 보는 목표 기반 개발
- 3편: A2A와 MCP로 보는 멀티 에이전트 개발 워크플로우
- 4편: AI Memory는 RAG가 아니다
- 5편: 개발 하네스에 적용하는 AI 코딩 에이전트 문서 세트

## 참고자료

- [Announcing Version 1.0 - A2A Protocol](https://a2a-protocol.org/latest/announcing-1.0/)
- [A2A and MCP - A2A Protocol](https://a2a-protocol.org/dev/topics/a2a-and-mcp/)
- [A2A Protocol v0.2.6 Specification](https://a2a-protocol.org/v0.2.6/specification/)
- [A2A Protocol v0.1.0 Specification](https://a2a-protocol.org/v0.1.0/specification/)
- [MetaGPT: Meta Programming for Multi-Agent Collaborative Framework](https://arxiv.org/abs/2308.00352)
- [ChatDev: Communicative Agents for Software Development](https://arxiv.org/abs/2307.07924)