---
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: 2043
---

# 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: 2043

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

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

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)

## 독자 적용 노트

이 글은 AI agent나 코딩 도구를 실제 개발 업무에 적용하려는 개발자가 `A2A와 MCP로 보는 멀티 에이전트 개발 워크플로우`이라는 주제를 단순 개념 설명이 아니라 AI 도구를 실제 작업 흐름에 붙일 때의 실행 경계로 점검하도록 작성했습니다. 본문에서 다룬 구조는 새 도구를 도입하거나 기존 워크플로우를 바꿀 때 "무엇을 먼저 확인해야 하는가"를 정하는 데 쓰는 것이 좋습니다.

### 원본 판단 근거

이 글의 판단은 MCP와 A2A는 해결하는 문제가 다르다에서 설명한 구조와 본문 안의 예시, 표, 체크리스트를 함께 놓고 정리한 것입니다. 특히 독자가 그대로 복사할 수 있는 결론보다, 자신의 코드베이스나 팀 규칙에 맞춰 확인해야 할 경계와 실패 조건을 분리하는 데 초점을 둡니다.

### 실패 사례 또는 edge case

가장 흔한 실패는 AI 도구를 실제 작업 흐름에 붙일 때의 실행 경계를 문서나 명칭만 맞춘 상태로 끝내는 것입니다. 예를 들어 실제 입력, 권한, 로그, 배포, 검증 기준이 연결되지 않으면 겉으로는 도입이 끝난 것처럼 보여도 다음 작업에서 같은 문제가 반복됩니다. 따라서 본문을 적용할 때는 "누가 실행하는가", "무엇을 기록하는가", "실패하면 어디서 멈추는가"를 같이 확인해야 합니다.

### 실무 체크리스트

- [ ] 이 글의 핵심 개념을 현재 프로젝트의 실제 파일, API, 로그, 문서 중 하나에 연결했다.
- [ ] 본문 예시를 그대로 쓰지 않고 우리 환경의 제약 조건으로 다시 검토했다.
- [ ] 실패 사례나 edge case를 하나 이상 정하고, 재현 또는 확인 방법을 적었다.
- [ ] 적용 후 바뀌어야 할 완료 기준과 검증 명령을 분리했다.

### Q&A

#### Q1. 이 글의 내용을 바로 표준으로 써도 되나요?

바로 표준으로 고정하기보다 작은 작업 하나에 먼저 적용해 보는 편이 안전합니다. 실제 로그, 리뷰, 테스트에서 같은 판단이 반복해서 맞을 때 팀 표준으로 올리는 것이 좋습니다.

#### Q2. 본문 예시와 내 프로젝트가 다르면 어떻게 해야 하나요?

예시의 이름보다 경계를 보세요. 입력, 상태, 권한, 검증, 기록 중 어떤 경계를 다루는 글인지 먼저 찾고, 그 경계를 현재 프로젝트의 구조에 맞게 옮기면 됩니다.

### 참고자료와 불확실성

이 보강 노트는 본문에 이미 포함된 참고자료와 작성 시점의 공개 문서를 기준으로 합니다. 도구 버전, API 정책, 제품 UI는 바뀔 수 있으므로 실제 적용 전에는 공식 문서와 현재 런타임 동작을 다시 확인해야 합니다.