A2A vs MCP: 새로운 에이전트 생태계를 위한 두 개의 보완적 프로토콜

사용자를 대신하여 추론과 행동을 수행하는 자율 또는 반자율 소프트웨어 엔티티인 AI 에이전트의 채택이 증가함에 따라 응용 프로그램 아키텍처의 새로운 레이어가 부상하고 있습니다.

2025년 초, 두 가지 서로 다른 프로토콜인 **A2A(Agent-to-Agent)**와 **MCP(Model Context Protocol)**가 출현했습니다. 이들의 역할을 이해하는 간단한 방법은 다음과 같습니다:

A2A: 에이전트가 서로 어떻게 상호작용하는가

MCP: 에이전트가 도구나 외부 컨텍스트와 어떻게 상호작용하는가

참고 자료: https://google.github.io/A2A/#/topics/a2a_and_mcp

이들은 다수의 에이전트, 다수의 LLM, 다수의 컨텍스트 소스가 모두 협력해야 하는 시스템 구축의 핵심 과제를 해결합니다.

이렇게 표현할 수 있습니다: "MCP는 수직 통합(애플리케이션-모델)을 제공하고, A2A는 수평 통합(에이전트 간)을 제공합니다.

개발자든 아니든, AI 제품이나 에이전트 시스템을 구축하는 사람이라면 누구나 기본 아키텍처를 이해해야 합니다. 이는 제품 설계, 사용자 상호작용, 생태계 및 장기 성장에 영향을 미치기 때문입니다.

이 기사는 두 프로토콜을 간단하고 이해하기 쉽게 소개하고, 개발자와 AI 제품 제작자를 위한 주요 통찰을 강조합니다.

A2A(Agent-to-Agent)란 무엇인가?#

**A2A(Agent-to-Agent)**는 구글과 50개 이상의 업계 파트너가 개발한 개방형 프로토콜입니다. 이는 에이전트 상호 운용성을 가능하게 하는 것을 목적으로 하며, 누가 어떻게 만들었든, 어디에 호스팅되었든 또는 어떤 프레임워크를 사용하든 상관없이 적용 가능합니다.

A2A 프로토콜 메커니즘#

A2A는 HTTP(S)를 통한 JSON-RPC 2.0을 통신 메커니즘으로 사용하며, **서버 발신 이벤트(SSE)**를 지원하여 업데이트를 스트리밍합니다.

A2A 통신 모델#

A2A는 두 에이전트가 어떻게 상호작용하는지를 정의하는 구조화된 모델을 갖추고 있습니다. 한 에이전트는 요청이나 작업을 시작하는 “클라이언트” 에이전트 역할을 하고, 다른 에이전트는 요청을 수신하고 이를 수행하는 “원격” 에이전트 역할을 합니다. 클라이언트 에이전트는 먼저 주어진 작업에 가장 적합한 에이전트를 파악하기 위해 기능 탐색을 수행할 수 있습니다.

여기서 중요한 질문이 등장합니다. 에이전트들은 어떻게 서로를 발견합니까? 각 에이전트는 자신의 에이전트 카드를 게시할 수 있습니다(표준 URL인 /.well-known/agent.json 등에서 게시됨). 이 문서는 에이전트의 기능, 기술, API 엔드포인트 및 인증 요구사항을 설명합니다.

에이전트 카드를 읽어 클라이언트 에이전트는 작업에 적합한 파트너 에이전트를 식별할 수 있습니다. 목표 에이전트가 선택되면, 클라이언트 에이전트는 작업(Task) 객체를 만들어 전송합니다.

참고 자료: https://google.github.io/A2A/#/

작업 관리#

A2A의 모든 상호작용은 작업 수행을 중심으로 이루어집니다. 작업은 요청의 세부 사항을 포함하고 상태를 추적하는 구조화된 객체입니다(프로토콜의 스키마에 의해 정의됨).

A2A에서 각 에이전트는 두 가지 역할 중 하나를 맡습니다:

• 클라이언트 에이전트: 작업을 시작
• 원격 에이전트: 작업을 수신 및 처리

작업은 보고서 생성, 데이터 검색, 워크플로 시작 등의 모든 형태의 작업을 포함할 수 있습니다. 결과는 아티팩트로 반환되며, 에이전트는 실행 중에 구조화된 메시지를 보내 조정하거나 명확히 할 수 있습니다.

협업 및 콘텐츠 협상#

A2A는 단순 작업 요청보다 더 많은 것을 지원합니다. 에이전트는 텍스트, JSON, 이미지, 비디오 또는 인터랙티브한 콘텐츠를 포함하는 풍부하고 다중 파트로 구성된 메시지를 교환할 수 있습니다. 이는 각 에이전트가 처리하거나 표시할 수 있는 형식에 따라 형식 협상을 가능하게 합니다.

예를 들어, 원격 에이전트는 차트를 원시 데이터나 이미지로 반환하거나 인터랙티브 폼을 열 것을 요청할 수 있습니다. 이 디자인은 모듈리스틱, 모드 독립적인 통신을 지원하며, 에이전트가 내부 도구나 메모리를 공유할 필요가 없습니다.

사용 사례 예#

다음은 A2A가 기업 시나리오에서 어떻게 사용될 수 있는지 보여주는 실제 사례입니다:

한 대기업에 새로운 직원이 입사합니다. 온보딩에는 여러 시스템과 부서가 관련됩니다:

• HR은 기록을 만들고 환영 이메일을 보내야 합니다.
• IT는 노트북과 회사 계정을 제공해야 합니다.
• 시설 관리팀은 책상과 출입 배지를 준비해야 합니다.

전통적으로 이러한 단계는 수동으로 처리되거나 내부 시스템 간의 밀접한 통합을 통해 처리됩니다.

각 부서는 A2A 프로토콜을 사용하여 각자의 에이전트를 노출합니다:

다중 에이전트 시스템 — 이를 OnboardingPro라고 부르겠습니다(예: onboarding-agent.company.com) — 전체 온보딩 워크플로를 조정합니다.

1. 탐색: 각 에이전트의 .well-known/agent.json을 읽어 기능과 인증을 파악합니다.
2. 작업 위임:
   • HR 에이전트에 createEmployee 작업 전송.
   • IT 에이전트에 setupEmailAccount 및 orderHardware 작업 전송.
   • 시설 관리 에이전트에 assignDesk 및 generateBadge 작업 전송.
3. 스트리밍 업데이트: 에이전트는 서버 발신 이벤트를 사용하여 진행 상황을 스트리밍합니다(예: "노트북 배송됨", "책상 할당됨").
4. 아티팩트 수집: 최종 결과(예: PDF 배지, 확인 이메일, 계정 자격 증명) 는 A2A 아티팩트로 반환됩니다.
5. 완료: OnboardingPro는 온보딩이 완료되면 담당 채용 관리자에게 알림을 보냅니다.

MCP(Model Context Protocol)란 무엇인가?#

**MCP(Model Context Protocol)**는 외부 애플리케이션이 실행 중인 언어 모델 기반 에이전트에 구조화된 컨텍스트와 도구를 제공하는 문제를 해결하기 위해 Anthropic이 개발했습니다.

에이전트 간 통신을 가능하게 하는 대신, MCP는 컨텍스트 윈도우에 중점을 둡니다 — LLM의 작업 메모리입니다. 그 목표는:

• 모델의 추론 세션에 관련 도구, 문서, API 기능 또는 사용자 상태를 동적으로 삽입하는 것
• 프롬프트나 로직을 하드 코딩하지 않고 함수 호출 및 문서 가져오기를 허용하는 것

MCP 주요 아키텍처#

MCP를 이해하기 위해서는 전반적인 아키텍처를 먼저 이해해야 합니다 — 모든 부분들이 어떻게 함께 작동하는지.

MCP 호스트: "이번에 사용하는 AI"#

MCP 호스트는 AI 앱 자체로 생각할 수 있습니다 — Claude Desktop이나 코딩 도우미와 같은.

이는 당신이 사용하는 인터페이스입니다 — 당신이 입력하거나 대화하는 곳입니다.

모델이 더 나은 응답을 제공할 수 있도록 도구와 데이터를 끌어들이고 싶어합니다.

MCP 클라이언트: "연결기"#

MCP 클라이언트는 당신의 AI 호스트(예: Claude)를 외부 세계와 연결하는 소프트웨어 부분입니다. 이는 스위치보드와 같습니다 — 다양한 MCP 서버와의 보안하고 일대일 연결을 관리합니다. AI가 무언가에 접근하고자 할 때, 클라이언트를 통해 진행합니다.

ChatGPT, Claude chat, 또는 Cursor IDE와 같은 도구를 MCP 호스트로 생각하는 것이 유용합니다 — 그들은 당신이 상호작용하는 인터페이스를 제공합니다. 뒤에서, 그들은 MCP 클라이언트를 이용하여 MCP 서버를 통해 다양한 도구와 데이터 소스를 연결합니다.

참고 자료: https://modelcontextprotocol.io/introduction

MCP 서버: "도구 제공자"#

MCP 서버는 한 특정 도구나 기능을 노출하는 작은 집중된 프로그램입니다 — 예를 들어:

• 컴퓨터에서 파일 검색
• 로컬 데이터베이스의 데이터 조회
• 외부 API 호출 (날씨, 금융, 일정 등)

각 서버는 MCP 프로토콜을 따르고, AI는 그것이 무엇을 할 수 있고 어떻게 호출할 수 있는지를 이해합니다.

로컬 데이터 소스: "자신의 파일 및 서비스"#

일부 MCP 서버는 당신의 기계에 있는 것들에 연결됩니다 — 예를 들어:

• 문서와 폴더
• 코드 프로젝트
• 데이터베이스나 로컬 앱

이를 통해 AI는 데이터를 클라우드로 업로드하지 않고도 검색, 검색 또는 계산할 수 있습니다.

원격 서비스: "API 및 온라인 도구"#

다른 MCP 서버는 인터넷에 연결되어 있습니다 — 이들은:

• API(예: Stripe, Notion, GitHub)
• SaaS 도구
• 클라우드의 회사 데이터베이스

와 통신합니다. 이렇게 AI는 예를 들어: "GitHub 서버에 전화를 걸어 열린 PR 목록을 가져오십시오."라고 말할 수 있습니다.

MCP는 이제 원격 MCP 서버 연결을 지원합니다. 이는 MCP 클라이언트가 더 강력한 능력을 갖출 수 있음을 의미합니다. 이론적으로,

적절한 MCP 서버 세트를 통해, 사용자는 모든 MCP 클라이언트를 "모든 것을 할 수 있는 앱"으로 변환할 수 있습니다.

참고 자료: https://a16z.com/a-deep-dive-into-mcp-and-the-future-of-ai-tooling/

모든 것을 함께 조합하기#

이제 다이어그램을 이용하여 모든 것이 어떻게 함께 작동하는지를 봅시다.

1. 당신이 AI에게 복잡한 것을 요청합니다
2. AI(호스트)는 클라이언트에게 도움을 요청합니다
3. 클라이언트는 올바른 MCP 서버를 호출합니다 — 아마도 파일을 검사하거나 API를 호출하는 것일 수 있습니다
4. 서버는 데이터를 보내거나 기능을 실행합니다
5. 결과는 작업을 완료하는 데 도움이 되도록 모델에게 다시 전달됩니다

A2A vs MCP — 비교#

어떻게 함께 작동하는지#

대안이 아니라, A2A와 MCP는 상호 보완적입니다. 많은 시스템에서 둘 다 함께 사용될 것입니다.

예제 워크플로우#

1. 사용자가 기업 에이전트 인터페이스에서 복잡한 요청을 제출합니다.
2. 조정 에이전트가 A2A를 사용하여 특화된 에이전트에 하위 작업을 위임합니다(예: 분석, HR, 재무).
3. 그 에이전트 중 하나가 MCP를 내부적으로 사용하여 검색 기능을 호출하거나, 문서를 가져오거나, 모델을 사용하여 계산합니다.
4. 결과는 A2A를 통해 아티팩트로 반환되며, 모듈식 도구 액세스를 통한 에이전트 간 협업이 가능합니다.

이 아키텍처는 **에이전트 간 통신(A2A)**과 **에이전트 내의 기능 호출(MCP)**을 분리하여 시스템을 구성하고 확장하며 보안을 더 쉽게 합니다.

결론#

A2A는 네트워크를 통해 에이전트 간 대화를 가능하게 합니다 — 안전하고 비동기적으로, 그리고 작업 중심으로.

MCP는 모델 세션에 구조화된 기능을 주입하는 것으로, LLM이 도구와 데이터를 맥락적으로 추론할 수 있게 합니다.

함께 사용될 때, 이는 구성 가능한 다중 에이전트 시스템을 지원하여, 확장 가능하고 상호 운용할 수 있습니다.

MCP + A2A 기반 인프라가 에이전트 제품 마켓플레이스의 미래를 어떻게 형성할 수 있는가#

마지막으로, 이 핵심 기술 기반이 AI 마켓플레이스의 미래를 어떻게 형성할 수 있는지에 대해 이야기하겠습니다 — 그리고 AI 제품을 개발하는 사람들에게 이는 무엇을 의미합니까.

인간-컴퓨터 상호작용의 변화#

개발자 및 서비스 워크플로에서 이 변화의 명확한 예를 볼 수 있습니다. 이제 IDE 및 코딩 에이전트에 MCP 서버가 통합되면서, 개발자가 도구와 상호작용하는 방식이 근본적으로 변화하고 있습니다.

이전에는 적합한 서비스를 검색하고, 호스팅을 설정하고, 문서를 읽고, API를 수동으로 통합하고, IDE에서 코딩하고, 저코드 대시보드를 통해 기능을 구성하는 등의 전형적인 워크플로가 있었습니다. 단계마다 맥락 전환과 기술적 부담이 필요했습니다.

이제 MCP에 연결된 코딩 에이전트를 사용하면, 이러한 복잡성의 많은 부분이 추상화될 수 있습니다. 개발자는 대화형 프롬프트를 통해 더 자연스럽게 도구를 발견하고 사용할 수 있습니다. API 통합은 별도의 UI나 수동 설정이 필요없을 때 코딩 흐름의 일부가 되고 있습니다. (AWS나 마이크로소프트의 대시보드가 얼마나 복잡할 수 있는지 생각해보십시오.) 상호작용은 더 부드럽고 — 기능 조립이 아닌 행동 안내에 관한 것이 됩니다.

이 모델에서, 사용자 또는 개발자의 상호작용은 기능 구성에서 행동 조정으로 전환됩니다. 이는 제품 디자인의 역할도 변화시킵니다.

UI를 사용하여 기술적 문제를 "보완"하는 대신(예: "코딩이 너무 어렵다, 설정 패널을 만들자"), 이제는:

• 엔드 투 엔드 경험을 생각해야 합니다
• AI + 사용자 상호작용이 어떻게 그리고 언제 결합되어야 하는지 설계해야 합니다
• AI가 논리를 처리하고, 사용자는 의도와 흐름을 유도해야 합니다

과제는 AI와 사용자 입력이 언제 그리고 어떻게 결합되어야 하는지, AI가 논리를 처리하고, 사용자는 의도와 흐름을 유도하고 올바른 시점에 올바른 상호작용을 삽입하는 방법을 결정하는 것입니다.

개발자 서비스 및 API 제품을 예로 들어 사용자 상호작용이 어떻게 변할 수 있는지를 보여드렸지만, 같은 것이 비즈니스 소프트웨어에도 적용됩니다. 오랫동안 비즈니스 도구는 복잡하고 사용하기 어려웠습니다. 자연어 상호작용은 이러한 워크플로 중 많이를 단순화할 가능성이 있습니다.

에이전트 제품 패러다임 및 SaaS에 미치는 영향#

우리는 점점 더 많은 MCP 서버가 등장하는 것을 확인할 수 있습니다. Airbnb가 예약 MCP 서버를 제공하거나, 구글 맵이 지도 MCP 서버를 노출하는 것을 상상해보십시오. 에이전트(예: MCP 클라이언트로)가 이러한 서버 여러 개를 한 번에 연결할 수 있다면 — 이전에는 맞춤형 통합이나 밀접하게 연결된 앱이 필요했던 워크플로를 잠금 해제할 수 있습니다.

수동적이고 경직된 통합이 일반적이었던 SaaS 시대와 비교할 때, 이 모델은 더 자율적인 워크플로우와 서비스 간의 유연한 연결을 가능하게 합니다. 다음은 두 가지 예입니다:

1. 문서에서 디자인까지

   당신은 Notion에서 PRD를 작성합니다. Figma 에이전트는 문서를 읽고 기본 개념을 레이아웃하는 와이어프레임을 자동으로 생성합니다 — 수동 핸드오프가 필요 없습니다.

2. 경쟁사 연구, 처음부터 끝까지

   당신은 경쟁사 분석을 요청합니다. 여러 에이전트 그룹이 웹을 검색하고, 해당 서비스를 당신 대신에 등록하며(보안 인증), 결과를 수집하여 반환된 아티팩트를 제공합니다 — 이미 당신의 Notion 작업 공간에 조직화되어 있습니다.

인증 및 인가 경계의 문제#

에이전트 간 연결, MCP 클라이언트와 MCP 서버 간 연결이 증가하면서, 인증과 권한 부여에 대한 많은 근본적인 요구가 있습니다. 에이전트는 인간과 사용자를 대신하여 작동하며, 사용자 계정 정보는 이 여정 동안 안전하게 보호되어야 하기 때문입니다.

에이전트 간 및 MCP의 새로운 부상과 관련된 몇 가지 시나리오가 있습니다.

1. 에이전트 vs SaaS & 웹 애플리케이션
2. MCP 클라이언트(에이전트) vs MCP 서버
3. 사용자 vs 에이전트
4. 에이전트 vs 에이전트

구글이 언급한 다중 식별자 페더레이션의 흥미로운 사용 사례가 있습니다:

예를 들어, 사용자 U가 A 시스템의 식별자가 필요한 에이전트 A와 협력하고 있습니다. 만약 에이전트 A가 식별자가 필요한 B 시스템의 툴 B 또는 에이전트 B를 의존한다면, 사용자는 단일 요청에서 A 시스템과 B 시스템 모두의 식별자를 제공해야 할 수도 있습니다. (A 시스템은 엔터프라이즈 LDAP 식별자이고, B 시스템은 SaaS 제공자의 식별자입니다.)

Logto는 오픈ID 및 OAuth 제공자로서, AI 통합의 미래에 잘 맞습니다.

이는 유연한 인프라를 통해 그 기능을 활발하게 확장하고 있으며, 개발자가 빠르게 시작할 수 있도록 일련의 튜토리얼을 발표했습니다.

질문이 있나요?

우리에게 연락하세요 — 또는 오늘 Logto로 무엇을 구축할 수 있는지 탐색해보십시오.