AI 에이전트 대화 방법: 멀티 에이전트 통신과 A2A·MCP 차이
AI 에이전트 대화는 메시지와 작업 상태를 주고받는 통신 규칙으로 이뤄져요. A2A는 에이전트끼리, MCP는 에이전트와 도구를 잇는 프로토콜이에요. 차이와 비용·보안 위험을 정리했어요.
목차6개 섹션
핵심 요약
- AI 에이전트 대화는 자연어 채팅이 아니라 정해진 형식의 메시지·작업(Task)·결과물을 주고받는 기계 간 통신이에요.
- A2A는 서로 다른 회사·프레임워크의 에이전트끼리 협업하는 수평 연결, MCP는 한 에이전트에 도구·데이터를 붙이는 수직 연결이에요.
- 두 프로토콜은 경쟁 관계가 아니며 A2A 공식 문서도 함께 쓰는 구성을 권해요.
- 2026년 10월 기준 A2A는 v1.0 사양이 나왔고, 2026년 8월 MCP와 같은 Agentic AI Foundation 프로젝트가 됐어요.
- Anthropic 사례에서 멀티 에이전트는 일반 채팅보다 토큰을 약 15배 써서, 병렬로 나눌 수 있는 가치 높은 작업에만 맞아요.
AI 에이전트 대화는 사람이 채팅하듯 말을 주고받는 것이 아니라, 정해진 형식의 메시지와 작업 상태를 주고받는 기계 간 통신이에요. 핵심은 두 가지 연결이에요. 에이전트가 데이터베이스·API 같은 도구를 쓰는 연결은 MCP(Model Context Protocol)가, 서로 다른 팀이나 회사가 만든 다른 에이전트에게 일을 맡기는 연결은 A2A(Agent2Agent) 프로토콜이 표준화해요. 이 글은 2026년 10월 기준 두 프로토콜의 공식 문서를 바탕으로 멀티 에이전트 통신 방식과 차이, 도입 전에 따져 볼 비용·오류·보안 위험을 정리해요. 개발자뿐 아니라 'AI 에이전트끼리 대화한다'는 뉴스를 이해하고 싶은 분도 읽을 수 있게 썼어요.
AI 에이전트 대화는 어떻게 이뤄지나요
멀티 에이전트 시스템은 여러 에이전트가 하나의 목표를 나눠 처리하는 구조예요. Anthropic은 자사 리서치 기능의 구조를 설명하며 에이전트를 '도구를 반복해서 쓰는 LLM'으로 정의하고, 리드 에이전트가 질문을 쪼개 하위 에이전트들에게 병렬로 맡긴 뒤 결과를 모아 답을 만드는 오케스트레이터-워커 패턴을 소개했어요. 이때 에이전트끼리 오가는 내용은 '무엇을 조사할지(목표)', '어떤 형식으로 돌려줄지', '어떤 도구를 써도 되는지', '어디까지가 내 일인지' 같은 작업 지시와 결과물이에요.
같은 프로그램 안에서 돌아가는 하위 에이전트끼리는 프레임워크가 제공하는 함수 호출이나 공유 메모리로 충분히 소통할 수 있어요. 문제는 에이전트가 서로 다른 서버, 다른 언어, 다른 회사에서 만들어졌을 때예요. 상대가 어떤 일을 할 수 있는지, 어떤 주소로 요청을 보내야 하는지, 어떤 인증이 필요한지, 작업이 끝났는지 실패했는지를 매번 따로 약속하면 연결할 때마다 맞춤 연동 코드를 짜야 해요. A2A 측은 AAIF 합류 발표에서 A2A 이전에는 프레임워크가 다른 에이전트 사이에 일을 넘기려면 조합마다 통합 코드를 처음부터 짜야 했다고 설명해요. 표준 프로토콜은 이 약속을 미리 정해 두는 역할을 해요.
멀티 에이전트 통신의 대표 구조
- 오케스트레이터-워커: 리드 에이전트가 계획을 세우고 하위 에이전트에 일을 나눠 준 뒤 결과를 합쳐요. 가장 흔한 구조예요.
- 순차 파이프라인: 한 에이전트의 결과를 다음 에이전트가 이어받아요. 흐름이 정해져 있으면 에이전트보다 워크플로가 더 단순할 수 있어요.
- 피어 협업: 독립된 에이전트끼리 필요한 상대를 찾아 일을 맡기고 결과를 받아요. 조직 경계를 넘는 연결이 여기에 해당하며 A2A가 겨냥하는 영역이에요.
- 공유 저장소 경유: 하위 에이전트가 결과를 파일·저장소에 남기고 가벼운 참조만 넘겨요. Anthropic은 이를 '전화 게임'처럼 내용이 왜곡되는 문제를 줄이는 방법으로 소개했어요.
A2A 프로토콜과 MCP 차이: 에이전트끼리 vs 에이전트와 도구
A2A 공식 비교 문서는 두 프로토콜을 방향으로 구분해요. MCP는 수직이에요. 한 에이전트 아래에 도구·리소스를 하나씩 붙여 그 에이전트가 혼자 할 수 있는 일을 늘려요. A2A는 수평이에요. 다른 팀·부서·협력사의 에이전트에 손을 뻗어 서로를 찾고, 조건을 협상하고, 정보를 주고받아요. 문서는 'MCP는 각 에이전트에 깊이를, A2A는 시스템에 범위를 준다'고 요약하고, 둘은 경쟁이 아니라 보완 관계라고 밝혀요.
연결 대상
- MCP
- 에이전트 ↔ 도구·데이터·API
- A2A
- 에이전트 ↔ 다른 에이전트
상대의 성격
- MCP
- 입출력이 정해진, 대개 상태가 없는 기능
- A2A
- 스스로 계획·추론하고 상태를 유지하는 독립 시스템
핵심 개념
- MCP
- Tools, Resources, Prompts
- A2A
- Agent Card, Task, Message, Part, Artifact
메시지 형식
- MCP
- JSON-RPC 2.0
- A2A
- JSON-RPC, gRPC, HTTP+JSON 바인딩
대표 사례
- MCP
- DB 조회, 날씨 API 호출, 저장소 읽기
- A2A
- 고객센터 에이전트가 결제 에이전트에 문의 위임
상대 내부 공개
- MCP
- 도구 설명·입력 스키마를 공개
- A2A
- 내부 메모리·도구를 숨긴 블랙박스로 협업
공식 문서의 자동차 정비소 예시를 보면 차이가 분명해요. 고객(또는 고객의 비서 에이전트)과 '점장' 에이전트의 대화, 점장과 '정비사' 에이전트의 작업 위임, 정비사와 외부 '부품 공급사' 에이전트의 재고 문의는 A2A로 이뤄져요. 반면 정비사 에이전트가 진단 스캐너·수리 매뉴얼 DB·리프트 같은 도구를 호출하는 부분은 MCP로 처리해요. 즉 대화와 협상이 필요한 곳은 A2A, 정해진 함수를 부르는 곳은 MCP예요.
헷갈리기 쉬운 경계
A2A 에이전트의 일부 기능을 MCP 도구처럼 노출하는 것도 가능해요. 공식 문서는 기능이 명확하고 상태 없이 호출할 수 있을 때 이 방식이 잘 맞는다고 해요. 다만 여러 턴에 걸친 협업, 오래 걸리는 작업, 중간에 사람의 입력이 필요한 흐름은 A2A의 강점이에요. 같은 문서는 'A2A는 에이전트가 함께 일하는 것, MCP는 에이전트가 기능을 쓰는 것'이라고 정리해요. 같은 앱 안의 하위 에이전트끼리라면 굳이 A2A를 거치지 않고 프레임워크 기능으로 연결해도 되는 경우가 많아요.
A2A로 에이전트끼리 일을 주고받는 흐름
A2A v1.0 변경 사항 문서를 기준으로 실제 흐름을 단계별로 보면 다음과 같아요. 용어만 알아 둬도 'AI 에이전트끼리 대화한다'는 말이 구체적으로 무엇을 뜻하는지 이해하기 쉬워져요.
- 1
Agent Card로 상대를 찾아요
원격 에이전트는 이름, 설명, 할 수 있는 기술(skills), 접속 주소, 지원 바인딩, 인증 방식을 담은 JSON 문서인 Agent Card를 공개해요. 보통 잘 알려진 경로(/.well-known/agent-card.json)에서 읽어요. v1.0에서는 주소·바인딩·프로토콜 버전을 supportedInterfaces 목록으로 묶었어요.
- 2
메시지를 보내 작업을 시작해요
클라이언트 에이전트가 SendMessage로 요청을 보내요. 메시지 안의 내용 단위는 Part로, 텍스트·파일(URL 또는 원본 바이트)·구조화 데이터를 담을 수 있어요. 서버는 바로 답(Message)을 주거나 추적 가능한 작업(Task)을 만들어요.
- 3
작업 상태를 추적해요
Task는 고유 ID와 상태를 가져요. 제출됨, 진행 중, 완료, 실패, 취소, 거절, 입력 필요, 인증 필요 같은 상태가 정의돼 있어서 상대가 사람의 확인을 기다리는지, 실패했는지를 기계가 읽을 수 있어요.
- 4
스트리밍이나 푸시로 결과를 받아요
짧은 작업은 요청-응답으로 끝나고, 긴 작업은 스트리밍(SSE)으로 진행 상황을 받거나 웹훅으로 푸시 알림을 받아요. 최종 결과물은 Artifact로 전달돼요.
MCP도 2026년 7월 28일 개정 사양에서 오래 걸리는 작업을 위한 Tasks 확장을 선택 기능으로 두고 있어요. MCP 사양에 따르면 MCP는 JSON-RPC 2.0 메시지로 호스트·클라이언트·서버를 잇고, 표준 전송 방식은 로컬 하위 프로세스용 stdio와 원격용 Streamable HTTP예요. 이 개정은 요청마다 프로토콜 버전과 기능 정보를 본문에 담는 구조로 바뀌어, 예전 initialize 기반 서버와는 호환 처리가 필요해요. 이런 세부 사항은 개정마다 달라지므로 구현 전에는 반드시 해당 버전 문서를 다시 확인해야 해요.
2026년 거버넌스 변화
A2A 프로젝트는 2026년 8월 27일 발표에서 리눅스 재단이 이끄는 Agentic AI Foundation(AAIF)의 Growth Stage 프로젝트로 합류했다고 밝혔어요. 같은 재단에는 MCP, goose, AGENTS.md가 형제 프로젝트로 있어요. 발표문은 150개가 넘는 조직이 A2A를 지지한다고 했지만, 이는 프로젝트 측 주장이므로 실제 채택 범위는 사용하려는 플랫폼의 문서로 따로 확인하는 편이 좋아요.
AI 에이전트·프로토콜 관련 소식은 빠르게 바뀌어요. 더따리 AI 텔레그램 트렌드와 블로그 트렌드에서 최근 화제가 된 에이전트 소식을 훑어본 뒤, 사실 확인은 공식 사양 페이지에서 하는 순서를 권해요.
멀티 에이전트 도입 전 확인할 비용·오류·보안 위험
에이전트끼리 대화하게 만드는 일은 기술적으로 가능해졌지만 공짜는 아니에요. Anthropic의 자료에서 일반 에이전트는 채팅보다 토큰을 약 4배, 멀티 에이전트 시스템은 약 15배 썼다고 해요. 같은 글에서 Claude Opus 4 리드와 Claude Sonnet 4 하위 에이전트 구성이 내부 리서치 평가에서 단일 Opus 4보다 90.2% 높은 성과를 냈다고 밝혔지만, 이는 넓게 나눠 조사하는 작업에 대한 자사 내부 평가 결과예요. 모든 작업에 같은 효과를 기대하면 안 돼요.
비용 증가
- 무엇이 문제인가
- 에이전트 수만큼 맥락과 대화가 복제돼 토큰이 급증
- 줄이는 방법
- 작업 난도별 에이전트 수·호출 수 상한을 미리 정함
오류 전파
- 무엇이 문제인가
- 한 단계의 실패가 이후 경로 전체를 바꿈
- 줄이는 방법
- 체크포인트·재시도·중단 지점부터 재개
중복·누락
- 무엇이 문제인가
- 지시가 모호하면 하위 에이전트가 같은 일을 반복
- 줄이는 방법
- 목표·출력 형식·도구·경계를 명시한 위임
신뢰·보안
- 무엇이 문제인가
- 외부 에이전트의 응답·도구 설명을 그대로 믿음
- 줄이는 방법
- 인증 확인, Agent Card 서명 검증, 결과 검증 후 실행
디버깅 난이도
- 무엇이 문제인가
- 실행마다 경로가 달라 원인 추적이 어려움
- 줄이는 방법
- 전체 추적 로그와 결정 패턴 모니터링
보안은 특히 프로토콜이 대신해 주지 않는 부분이에요. MCP 사양은 도구가 임의 코드 실행에 해당한다고 보고, 신뢰할 수 없는 서버의 도구 설명은 믿지 말며 도구 호출 전 사용자 동의를 받아야 한다고 적고 있어요. 동시에 MCP 자체는 이런 원칙을 프로토콜 수준에서 강제할 수 없다고 밝혀요. A2A v1.0은 OAuth 2.0 흐름 정비(PKCE, 디바이스 코드), mTLS, Agent Card JWS 서명 같은 장치를 정의하지만, 어떤 에이전트에게 어떤 권한을 줄지는 여전히 운영자가 설계해야 해요. 외부 에이전트가 돌려준 텍스트에 숨은 지시가 섞여 있을 수 있으므로, 그 결과를 곧바로 다른 도구 호출에 넘기지 않는 것이 기본이에요.
도입 순서 체크리스트
- 단일 에이전트와 MCP 도구 연결로 먼저 해결되는지 시험해요.
- 작업을 독립적으로 병렬 분할할 수 있는지, 작업 가치가 늘어난 토큰 비용을 감당할 만한지 따져요.
- 같은 앱 안이면 프레임워크 기능을, 다른 팀·외부 회사 에이전트와 협업해야 하면 A2A를 검토해요.
- 상대 Agent Card의 인증 방식·서명·프로토콜 버전을 확인하고 운영 환경은 HTTPS만 써요.
- 에이전트 수·토큰·호출 횟수 상한과 실패 시 재개 지점을 정하고 추적 로그를 켜요.
정리하면, AI 에이전트끼리 대화하려면 서로를 찾는 방법(Agent Card), 일을 맡기는 단위(Task·Message), 결과를 돌려받는 형식(Artifact), 그리고 각 에이전트가 도구를 쓰는 방법(MCP)이 필요해요. 프로토콜은 연결 비용을 줄여 주지만 비용 상한, 오류 처리, 권한 설계까지 정해 주지는 않아요. 사양은 버전마다 이름과 구조가 바뀌어 왔으므로 구현에 들어가기 전에 쓰려는 SDK가 어떤 버전을 지원하는지부터 확인하세요.
