멀티 에이전트 개발은 에이전트를 많이 붙인다고 좋아지지 않습니다. 역할과 산출물 계약 없이 에이전트를 늘리면 책임만 흐려지고, 한 에이전트의 잘못된 판단이 다음 단계로 전파됩니다.
그래서 멀티 에이전트 설계의 출발점은 “몇 개의 에이전트를 둘 것인가”가 아니라 누가 무엇을 할 수 있고, 어떤 입력을 받고, 어떤 산출물을 남기는가입니다.
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 비교는 MCP가 agent가 database나 API 같은 도구와 리소스를 사용하는 방식을 다루고, A2A는 agent-to-agent collaboration을 가능하게 하는 별도 축이라고 설명합니다.
짧게 정리하면 축이 다릅니다.
| 구분 | MCP | A2A |
|---|---|---|
| 연결 대상 | 도구, API, DB, 파일 시스템 | 다른 에이전트 |
| 핵심 질문 | 이 에이전트가 무엇을 사용할 수 있는가? | 이 에이전트가 누구에게 일을 맡길 수 있는가? |
| 주요 목적 | tool/resource access | agent collaboration |
| 개발 하네스 적용 | 테스트 실행, 파일 검색, DB 조회 | 코드 리뷰, 테스트 분석, 문서화 위임 |
Agent-to-Tool과 Agent-to-Agent
개발 하네스를 만들 때 이 차이를 놓치면 구조가 꼬입니다.
다음은 MCP에 가까운 작업입니다.
파일 읽기테스트 실행Git diff 조회DB schema 확인API 문서 검색반면 다음은 A2A에 가까운 작업입니다.
보안 리뷰 에이전트에게 변경사항 검토 요청테스트 에이전트에게 실패 테스트 분석 요청문서화 에이전트에게 migration note 작성 요청성능 분석 에이전트에게 병목 후보 정리 요청MCP는 능력을 확장합니다. A2A는 책임을 분리합니다.
개발 하네스에서는 도구 호출과 작업 위임을 아래처럼 분리해 다뤄야 합니다.
Agent Card는 에이전트의 자기소개서다
A2A Protocol v1.0 발표는 A2A를 AI agent 간 communication을 위한 stable, production-ready open standard라고 설명합니다. 이 프로토콜에서 중요한 개념 중 하나가 Agent Card입니다.
Agent Card는 에이전트가 어떤 능력을 가지는지, 어떤 방식으로 통신하는지, 어떤 입력과 출력을 지원하는지를 설명합니다.
개발 하네스 관점에서는 Agent Card를 이렇게 볼 수 있습니다.
{ "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은 Task를 A2A server가 처리하는 stateful unit of work로 설명합니다. Task는 id, contextId, status, history, artifacts 같은 필드를 가질 수 있습니다.
개발 하네스에서 Task는 다음처럼 해석할 수 있습니다.
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입니다. 에이전트가 위험한 결정을 직접 하지 않고 사람에게 되묻는 상태가 필요합니다.
계속 진행해도 되는가?mock으로 대체해도 되는가?DB migration을 생성해도 되는가?외부 API를 호출해도 되는가?이 질문이 사라지면 자동화는 빨라지지만 위험해집니다.
Artifact는 검토 가능한 결과물이다
Artifact는 에이전트가 만든 결과물입니다. A2A v0.1 specification은 artifact를 task 중 생성된 tangible output으로 설명합니다.
코딩 에이전트에서 artifact는 특히 중요합니다. 채팅 메시지는 흘러갑니다. Artifact는 검토됩니다.
| 나쁜 결과 | 좋은 Artifact |
|---|---|
| “수정했습니다” | 변경 파일 목록 |
| “테스트 통과했습니다” | 실행 명령과 로그 요약 |
| “문제 없어 보입니다” | blocker, warning, suggestion 분류 |
| “기억해둘게요” | source, scope, validated_at이 있는 memory candidate |
실무에서는 마지막 응답보다 artifact contract가 더 중요합니다.
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 | 승인, 배포, 최종 병합 판단 |
핵심은 모든 에이전트를 실제 별도 프로세스로 나누는 것이 아닙니다. 처음에는 한 에이전트 안에서 역할만 분리해도 됩니다.
이번 단계에서는 Test Agent 역할로만 행동한다.목표는 실패 테스트 원인 분석이다.코드 수정은 하지 말고 test artifact만 남긴다.이 방식은 단순하지만 효과가 큽니다. 에이전트가 한 번에 분석, 구현, 테스트, 리뷰를 모두 하려고 하면 산출물이 흐려집니다. 역할을 나누면 결과물이 선명해집니다.
멀티 에이전트의 리스크
멀티 에이전트는 강력하지만 리스크도 큽니다. MetaGPT 논문은 여러 LLM agent를 단순 연결하면 오류가 전파될 수 있으며, 이를 줄이기 위해 SOP와 modular output을 강제하는 접근을 제안합니다. ChatDev 논문도 소프트웨어 개발을 여러 communicative agents의 협업으로 모델링하지만, 이런 구조가 작동하려면 역할, 단계, 대화 방식, 검증이 필요합니다.
실무 리스크는 다음과 같습니다.
| 리스크 | 설명 | 대응 |
|---|---|---|
| 책임 불명확 | 누가 최종 판단을 하는지 모름 | Lead Agent와 Human Owner 분리 |
| 오류 전파 | 한 에이전트의 잘못된 분석이 다음 단계로 전달 | Artifact 검토 단계 추가 |
| 과도한 자동화 | 승인 없이 위험 작업 수행 | Permission Gate |
| 산출물 혼합 | 대화와 결과가 섞임 | Artifact Contract |
| 비용 증가 | 여러 에이전트 반복 호출 | Task budget 설정 |
체크리스트
멀티 에이전트 구조를 설계할 때는 에이전트 수보다 아래 계약이 먼저입니다.
[ ] 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 코딩 에이전트 문서 세트
댓글
GitHub 계정으로 로그인하면 댓글을 남길 수 있습니다. 댓글은 GitHub Discussions를 통해 운영됩니다.