A2A 프로토콜: MCP 쓰면서 이것 모르면 AI 에이전트 절반만 쓰는 것

Published on

in

A2A 프로토콜: MCP 쓰면서 이것 모르면 AI 에이전트 절반만 쓰는 것

📡 AI 에이전트 인프라 | 2026년 3월 기준 최신 정보

A2A 프로토콜: MCP 쓰면서 이것 모르면
AI 에이전트 절반만 쓰는 것

MCP가 AI와 도구를 연결한다면, A2A 프로토콜은 AI와 AI를 직접 연결합니다. 구글이 발표하고 Linux Foundation이 관리하는 이 개방형 표준을 모르면, 당신의 멀티에이전트 시스템은 태생적으로 불완전합니다.

50개 이상의 기술 파트너 참여
Linux Foundation 오픈소스
Python·JS·Java·Go SDK 제공

A2A 프로토콜이란? 한 문장으로 이해하는 핵심 개념

A2A(Agent-to-Agent) 프로토콜은 서로 다른 벤더, 서로 다른 프레임워크로 만들어진 AI 에이전트들이 서로 직접 소통하고 협업할 수 있도록 표준화된 개방형 통신 규약입니다. 2025년 4월 구글과 50개 이상의 기술 파트너가 공동으로 발표했으며, 현재는 Linux Foundation이 오픈소스 프로젝트로 관리하고 있습니다.

가장 쉽게 이해하려면 이렇게 생각하면 됩니다. 여러분이 Claude로 만든 에이전트와 누군가가 Gemini로 만든 에이전트가 있다고 가정해 보세요. 기존에는 이 두 에이전트가 서로 대화하려면 각자의 방식으로 커스텀 API를 짜야 했습니다. A2A는 바로 이 문제를 해결합니다. 어떻게 만들었든, 어디에 배포했든, 어떤 모델을 쓰든 A2A를 준수하면 에이전트끼리 공통 언어로 소통할 수 있습니다.

💡 인사이트: A2A는 에이전트 세계의 HTTP라고 볼 수 있습니다. HTTP가 서버와 클라이언트 간의 통신을 표준화했듯이, A2A는 AI 에이전트 간의 통신을 표준화합니다. 우리가 웹사이트를 만들 때 HTTP를 직접 구현하지 않듯, 머지않아 에이전트를 만들 때 A2A를 당연히 쓰게 되는 세상이 올 것입니다.

A2A는 HTTP, SSE(서버 전송 이벤트), JSON-RPC 2.0 등 이미 널리 쓰이는 기술 위에 구축되어 있어 기존 IT 인프라에 통합하기가 어렵지 않습니다. Python, JavaScript, Java, Go, C#/.NET용 공식 SDK가 모두 제공되고, DeepLearning.AI에서 공식 입문 코스도 운영하고 있습니다.

▲ 목차로 돌아가기

MCP와 A2A, 뭐가 다른가? 역할 비교 완전 정리

MCP를 쓰고 있는 분이라면 “A2A가 뭔데, 그냥 MCP로 다 되는 거 아니야?”라는 생각이 드실 수 있습니다. 결론부터 말하면, 둘은 경쟁 관계가 아니라 상호 보완 관계입니다. 역할이 완전히 다릅니다.

구분 MCP (Model Context Protocol) A2A (Agent2Agent)
만든 곳 Anthropic (2024년) Google + 50개 파트너 (2025년 4월)
연결 대상 에이전트 ↔ 도구·API·데이터소스 에이전트 ↔ 에이전트
네트워크 구조 중앙집중형 (Hub-and-Spoke) 완전 분산형 (Decentralized)
통신 방식 JSON-RPC 2.0, SSE HTTP, JSON-RPC 2.0, SSE, gRPC
내부 공개 여부 도구 로직 노출 가능 불투명(Opaque) — 내부 로직 비공개
적합한 상황 단일 에이전트가 도구 활용 여러 에이전트가 협업하는 멀티에이전트 시스템

잡코리아 LOOP 팀의 AI 엔지니어가 적절히 표현했듯, “MCP가 LLM을 어떤 어플리케이션과도 이어주는 가교 역할을 한다면, A2A는 그 끝쪽을 ‘도구’ 대신 ‘에이전트’로 바꾼 것”입니다. 즉, MCP는 에이전트가 외부 세계와 소통하는 손, A2A는 에이전트들이 서로 대화하는 입이라고 볼 수 있습니다.

🔑 핵심 요약: 혼자 일하는 에이전트에게는 MCP로 충분합니다. 하지만 여러 에이전트가 팀을 이뤄 복잡한 업무를 나눠서 처리해야 한다면, A2A 없이는 불가능합니다. 2026년의 엔터프라이즈 AI는 이미 후자를 향하고 있습니다.

▲ 목차로 돌아가기

A2A의 5가지 설계 원칙과 작동 구조

A2A는 구글이 대규모 멀티에이전트 시스템을 실제로 운영하면서 발견한 문제들을 해결하기 위해 설계되었습니다. 단순히 아이디어 차원이 아니라, 실전 경험이 녹아있는 5가지 원칙을 기반으로 합니다.

1

에이전트 고유 역량 존중 (Embrace Agentic Capabilities)

에이전트들이 메모리, 도구, 컨텍스트를 공유하지 않아도 자연스럽게 협업할 수 있도록 설계했습니다. 각 에이전트는 블랙박스처럼 자신의 내부 로직을 공개하지 않고도 결과만 공유할 수 있습니다.

2

기존 표준 위에 구축 (Build on Existing Standards)

HTTP, SSE, JSON-RPC처럼 이미 수십 년간 검증된 기술 위에 쌓았습니다. 새로운 기술을 배울 필요 없이 기존 IT 스택과 쉽게 통합할 수 있는 이유가 여기에 있습니다.

3

기본적으로 보안 (Secure by Default)

API 키, OAuth 2.0, OpenID Connect 등 엔터프라이즈 수준의 인증·인가를 기본 지원합니다. OpenAPI 사양과 동등한 보안 체계를 갖추고 있어 기업 환경 도입 장벽이 낮습니다.

4

장기 실행 작업 지원 (Long-running Tasks)

단순 API 호출과 달리, 수시간 혹은 수일이 걸리는 복잡한 업무도 처리할 수 있습니다. 인간이 개입해야 하는 단계에서 작업을 일시 중단하고, 완료 시 웹훅으로 비동기 알림을 보내는 구조입니다.

5

모달리티 무관 (Modality Agnostic)

텍스트에만 국한되지 않습니다. 오디오, 비디오 스트리밍까지 지원하도록 설계되어 있어, 향후 피지컬 AI나 멀티모달 에이전트 협업에도 대응할 수 있습니다.

A2A의 3단계 워크플로

A2A는 세 단계를 거쳐 에이전트 간 통신을 처리합니다. 먼저 탐색(Discovery) 단계에서 클라이언트 에이전트가 에이전트 카드를 조회하여 작업에 가장 적합한 원격 에이전트를 찾습니다. 이어지는 인증(Authentication) 단계에서 API 키나 OAuth 2.0으로 신원을 확인하고, 마지막 커뮤니케이션(Communication) 단계에서 HTTPS 위에서 JSON-RPC 2.0으로 실제 작업을 주고받습니다.

▲ 목차로 돌아가기

에이전트 카드·작업·아티팩트: A2A 핵심 구성 요소

A2A를 실제로 구현하려면 프로토콜이 정의하는 7가지 핵심 빌딩 블록을 이해해야 합니다. 각각이 어떤 역할을 하는지 명확히 알아야 에이전트 시스템 설계가 가능합니다.

🪪 에이전트 카드 (Agent Card)

에이전트 카드는 JSON 형식의 자기소개서입니다. LLM의 모델 카드와 유사하게, 에이전트의 이름·설명·버전·서비스 엔드포인트 URL·지원 모달리티·인증 요구 사항 등을 담고 있습니다. 클라이언트 에이전트는 이 카드를 보고 “이 에이전트에게 이 작업을 맡길 수 있겠다”라고 판단합니다. 쉽게 말해 에이전트들의 명함이자 이력서입니다.

📋 작업 (Task)

작업은 요청을 수행하는 데 필요한 처리 단위입니다. 고유 ID를 가지며 “제출됨 → 작업 중 → 입력 필요 → 완료됨/실패” 의 수명 주기를 거칩니다. 단순한 일회성 호출부터 사람의 검토가 필요한 다단계 승인 워크플로까지 모두 커버합니다. 작업이 완료되면 그 산출물을 아티팩트라고 부릅니다.

📦 아티팩트 (Artifact) & 파트 (Part)

아티팩트는 작업 결과물입니다. 문서, 이미지, 스프레드시트 등 형태는 다양하며, 각 아티팩트는 하나 이상의 파트로 구성됩니다. 파트는 텍스트(TextPart), 파일(FilePart), 구조화 JSON 데이터(DataPart)로 분류되어, 클라이언트와 서버가 서로 알맞은 형식을 협상(Negotiation)할 수 있습니다.

💡 실전 팁: 에이전트 카드는 /.well-known/agent.json 경로에 노출하는 게 관례입니다. 이 URL만 알면 다른 에이전트가 자동으로 기능을 탐색하고 통신을 시작할 수 있습니다. 마치 웹사이트의 robots.txt처럼요.

▲ 목차로 돌아가기

실전 시나리오: MCP + A2A 함께 쓰는 방법

이론은 이해했는데, “그래서 실제로 어떻게 쓰는 건데?”라는 질문이 자연스럽게 따라옵니다. 구글이 공식 문서에서 제시한 채용 프로세스 자동화 시나리오가 가장 직관적인 예시입니다. 하지만 여기서는 한국 독자에게 더 친숙한 전자상거래 재고 관리 시나리오로 바꿔서 설명하겠습니다.

시나리오: 쇼핑몰 재고 자동 보충 시스템

단계 사용 프로토콜 동작
1. 재고 감지 MCP 재고 에이전트가 MCP로 데이터베이스에 접근해 품절 임박 상품을 감지
2. 내부 승인 요청 A2A 재고 에이전트가 A2A로 구매 승인 에이전트에게 발주 요청 작업 위임
3. 공급사 발주 A2A 구매 에이전트가 A2A로 외부 공급사 에이전트와 통신해 주문 생성
4. 배송 추적 MCP 배송 에이전트가 MCP로 물류 API에 접근해 실시간 배송 현황 파악

이 시나리오에서 핵심은 MCP와 A2A가 레이어를 분리해서 작동한다는 점입니다. MCP는 에이전트가 외부 시스템(DB, API)과 소통하는 ‘손발’ 역할을 하고, A2A는 에이전트들이 서로 업무를 위임하고 결과를 공유하는 ‘언어’ 역할을 합니다. 둘 중 하나만 쓰면 시스템이 절름발이가 됩니다.

🔐 보안 포인트: A2A의 불투명성(Opacity) 원칙 덕분에, 외부 공급사 에이전트는 여러분의 재고 데이터베이스 구조나 내부 로직을 전혀 알 수 없습니다. 결과물(발주 확인서)만 공유됩니다. 이것이 기업 환경에서 A2A가 환영받는 이유입니다.

▲ 목차로 돌아가기

Linux Foundation 오픈소스화 이후 달라진 것들

구글이 A2A를 처음 발표했을 때만 해도 “구글이 자기 생태계 확장을 위해 만든 프로토콜 아닐까?”라는 의심이 있었습니다. 그런데 이후 A2A를 Linux Foundation에 기증하고 오픈소스화하면서 상황이 달라졌습니다. 특히 IBM이 자체 개발하던 ACP(Agent Communication Protocol)마저 A2A 프레임워크 아래로 편입된 것은, A2A가 사실상 업계 표준으로 굳어지는 과정을 잘 보여줍니다.

Linux Foundation 편입 이후 달라진 실질적인 변화는 다음과 같습니다. 우선 멀티 벤더 거버넌스가 확립되었습니다. 더 이상 구글 혼자 방향을 결정하지 않으며, 기여자 커뮤니티가 사양을 함께 발전시켜 나갑니다. 또한 공식 SDK 다양화가 이루어졌습니다. Python, JavaScript에 더해 Java, Go, C#/.NET용 SDK까지 공식 제공되어 다양한 기술 스택에서 채택할 수 있게 되었습니다. 마지막으로 DeepLearning.AI와의 공식 교육 코스 파트너십을 통해 학습 장벽을 낮추는 노력도 이루어지고 있습니다.

앞으로 추가될 기능들

A2A는 아직 진화 중입니다. 공식 문서에 공개된 로드맵 기준으로 예정된 개선 사항은 다음과 같습니다. 에이전트 카드에 권한 부여 체계와 선택적 자격 증명을 공식으로 포함하는 것, 예상치 못한 스킬을 동적으로 확인하는 방법, 대화 중간에 오디오나 비디오를 추가하는 UX 동적 조정 기능, 그리고 푸시 알림 방법과 스트리밍 안정성 향상이 예정되어 있습니다. 표준이 완성에 가까워질수록 채택 비용은 낮아지고, 생태계의 가치는 기하급수적으로 높아질 것입니다.

▲ 목차로 돌아가기

A2A를 지금 공부해야 하는 이유 (주관적 총평)

솔직히 말하겠습니다. A2A는 지금 당장 여러분의 일상을 바꾸는 기술이 아닙니다. MCP처럼 “오늘 당장 Claude에 Notion 붙이기” 수준의 즉각적인 활용도는 없습니다. 그렇다면 왜 지금 공부해야 할까요?

이유는 간단합니다. 2026년의 AI 시장은 단일 에이전트의 시대에서 협업 에이전트의 시대로 이미 넘어가고 있기 때문입니다. Salesforce의 Agentforce, ServiceNow, SAP Joule, PayPal 같은 대형 플랫폼들이 모두 A2A를 지원 선언한 상황에서, 이 표준을 이해하지 못한 채 에이전트 시스템을 설계하는 것은 HTTP를 모르고 웹 개발을 하는 것과 같습니다.

개인적으로는 A2A가 지닌 불투명성(Opacity) 원칙이 가장 창의적인 설계 결정이라고 생각합니다. 에이전트들이 서로의 내부 구현을 몰라도 협업하게 만든 것은, 단순히 보안 때문이 아니라 에이전트 생태계를 진짜 시장처럼 작동하게 만들기 위한 것입니다. 공급사 에이전트가 여러분의 재고 DB 구조를 알 필요가 없듯, 에이전트 경제에서도 인터페이스만으로 거래가 이뤄지는 세상이 오고 있는 것입니다.

📌 개인 견해: MCP를 도구 연결의 표준으로, A2A를 에이전트 협업의 표준으로 익혀두는 것은 앞으로 2~3년 안에 AI 엔지니어링의 기본기가 될 것입니다. 지금이 선점할 수 있는 마지막 시간입니다.

▲ 목차로 돌아가기

❓ Q&A — 자주 묻는 5가지 질문

Q1. A2A는 무료로 쓸 수 있나요?

네, 완전히 무료입니다. A2A는 Linux Foundation이 관리하는 오픈소스 프로토콜로, 사용 비용이 없습니다. Python·JavaScript·Java·Go·C#/.NET용 공식 SDK도 모두 무료로 제공됩니다. 공식 GitHub 저장소(github.com/a2aproject/A2A)에서 바로 시작할 수 있습니다.

Q2. MCP만 써도 되는 상황과 A2A도 필요한 상황은 어떻게 구분하나요?

단일 에이전트가 Notion, Gmail, Slack 같은 도구들을 활용해 혼자 업무를 처리할 때는 MCP만으로 충분합니다. 하지만 “여행 계획 에이전트가 항공 예약 에이전트, 호텔 예약 에이전트, 현지 투어 에이전트에게 각각 업무를 위임하고 결과를 취합해야 한다”처럼 여러 에이전트가 협력해야 하는 워크플로에서는 A2A가 필수입니다.

Q3. LangChain, CrewAI 같은 프레임워크에서도 A2A를 쓸 수 있나요?

네. A2A는 프레임워크 독립적(Framework-agnostic)으로 설계되었습니다. LangChain, CrewAI, AutoGen, Google ADK, OpenAI Agents SDK 등 어떤 프레임워크로 만든 에이전트든 A2A를 준수하면 서로 통신할 수 있습니다. GitHub 샘플 저장소(a2a-samples)에서 다양한 프레임워크 통합 예제를 확인할 수 있습니다.

Q4. A2A와 OpenAI의 ACP(Agents Communication Protocol)는 어떻게 다른가요?

IBM이 BeeAI 프레임워크용으로 개발한 ACP는 A2A가 Linux Foundation에 기증된 후 A2A 프레임워크 안으로 통합되었습니다. OpenAI 역시 에이전트 통신 표준 논의에 참여하고 있습니다. 현재 시점에서 A2A가 가장 넓은 산업 지지(50개+ 파트너)를 받는 사실상 표준(de facto standard)에 가장 근접한 프로토콜입니다.

Q5. 비개발자도 A2A를 이해하고 활용해야 할까요?

직접 코드를 짤 필요는 없지만, 개념은 이해하는 것이 좋습니다. 특히 AI 서비스를 기획하거나 구매하는 PM, 기획자, 경영진이라면 “이 에이전트가 우리 사내 다른 에이전트와 A2A로 연동 가능한가?”라는 질문을 벤더에게 던질 수 있어야 합니다. A2A 지원 여부가 향후 AI 시스템 선택의 중요한 기준이 될 것입니다.

▲ 목차로 돌아가기

마치며 — 에이전트 시대의 공통 언어를 먼저 배우세요

A2A 프로토콜은 아직 한국에서 제대로 조명받지 못하고 있는 기술입니다. MCP 열풍에 가려져 있지만, 엔터프라이즈 AI의 실제 구현 현장에서는 이미 A2A 없이는 대화가 안 되는 수준까지 와 있습니다. Salesforce, SAP, ServiceNow, PayPal, Atlassian, LangChain이 모두 A2A를 공식 지원한다는 사실은, 이게 단순한 기술 실험이 아니라 산업 인프라가 되고 있다는 신호입니다.

결론은 이렇습니다. MCP는 오늘 당장 쓸 수 있는 도구이고, A2A는 내년의 인프라입니다. 두 가지를 함께 이해하고 있을 때 비로소 에이전트 시스템의 전체 그림이 보입니다. 공식 문서와 Python 튜토리얼이 이미 준비되어 있습니다. 지금 시작하세요.

▲ 목차로 돌아가기

본 포스팅은 2026년 3월 10일 기준으로 공개된 공식 문서와 기술 자료를 바탕으로 작성되었습니다. A2A 프로토콜 사양은 지속적으로 업데이트되므로, 구현 전 공식 문서를 반드시 확인하시기 바랍니다. 본 내용은 정보 제공 목적이며 특정 기술 선택에 대한 법적·상업적 책임을 지지 않습니다.

댓글 남기기


최신 글


아이테크 어른경제에서 더 알아보기

지금 구독하여 계속 읽고 전체 아카이브에 액세스하세요.

계속 읽기