아무도 예상하지 못한 이중 계층 문제

만약 당신이 지금 AI 에이전트(AI agents)를 활용해 무엇인가를 구축하고 있다면, 아마 저와 같은 벽에 부딪혔을 것입니다. 즉, 커스텀 통합(custom integrations)으로 인한 취약한 난장판을 만들지 않고 어떻게 여러 에이전트를 서로 연결할 것인가 하는 문제입니다.

결과적으로, 이 문제를 깔끔하게 절반으로 나누어 해결하기 위한 두 가지 프로토콜이 등장하고 있습니다. **MCP (Model Context Protocol)**는 수직적(vertical) 측면, 즉 단일 에이전트가 자신의 도구(tools) 및 데이터 소스(data sources)와 통신하는 방식을 다룹니다. **A2A (Agent-to-Agent)**는 수평적(horizontal) 측면, 즉 에이전트들이 서로를 어떻게 발견하고 통신하는지를 다룹니다.

이러한 분리를 조기에 이해하는 것은 나중에 겪게 될 아키텍처 설계에 대한 후회를 방지해 줍니다. 왜 그런지 설명해 드리겠습니다.

수직 계층: MCP

MCP를 에이전트와 실제 작업을 수행하는 데 필요한 모든 것 사이의 표준화된 배관(plumbing)이라고 생각하십시오. MCP 이전에는 모든 LLM 프레임워크가 API 호출, 데이터베이스 쿼리(database queries), 또는 파일 시스템 액세스(file system access)를 래핑(wrapping)하는 각기 다른 방식을 가지고 있었습니다.

MCP가 표준화하는 내용은 다음과 같습니다:

• 도구 정의 (Tool definitions) — 함수가 무엇을 하는지, 어떤 파라미터(parameters)가 필요한지를 설명하기 위한 일관된 스키마 (schema)
• 리소스 액세스 (Resource access) — 에이전트가 데이터베이스, 파일 시스템 또는 외부 API로부터 읽는 방식
• 프롬프트 및 컨텍스트 (Prompts and context) — 컨텍스트와 지침을 주입하는 프로토콜 수준의 방식

실제로 이는 MCP 서버를 한 번 작성하면 Claude, 커스텀 LangChain 에이전트, 또는 기타 다른 MCP 호환 런타임(runtime)에 바로 연결할 수 있음을 의미합니다:

# 의사 코드(Pseudocode): 도구를 노출하는 MCP 서버
class WeatherMCPServer:
    @mcp_tool
...

Anthropic이 MCP를 주도하고 있으며, 채택이 빠르게 늘고 있습니다. 신뢰할 수 있는 도구 액세스가 필요한 에이전트를 구축하고 있다면, MCP는 안전한 기본값(default)이 되고 있습니다.

수평 계층: A2A

A2A는 다른 문제를 해결합니다: 에이전트들이 어떻게 서로를 찾고 협업할 것인가?

세 명의 전문 에이전트로 구성된 고객 지원 시스템을 구축한다고 가정해 봅시다:

• 요청을 라우팅(routes)하는 접수 에이전트 (intake agent)
• 제품 문의를 처리하는 기술 에이전트 (technical agent)
• 환불을 처리하는 결제 에이전트 (billing agent)

A2A가 없다면, 당신은 이러한 연결들을 하드코딩(hard-code)해야 할 것입니다. A2A를 사용하면 에이전트들이 디렉토리(directory)에 자신의 역량을 등록하고, 다른 에이전트들이 이를 동적으로 발견(discover)할 수 있습니다.

주요 A2A 개념:

• 에이전트 발견 (Agent discovery) — 에이전트가 자신이 무엇을 할 수 있는지 광고하는 레지스트리 (registry)
• 메시지 라우팅 (Message routing) — 에이전트 간 통신을 위한 표준화된 봉투 (envelopes)
• 역량 협상 (Capability negotiation) — 에이전트가 자신의 기술을 선언하면, 다른 에이전트들이 이를 조회하고 호출 (invoke)함

Google은 A2A를 강력하게 추진하고 있으며, 주요 클라우드 벤더(cloud vendors)들도 지원을 위해 줄을 서고 있습니다. 이 2계층 스택 (two-layer stack)은 본격적인 멀티 에이전트 시스템을 위한 사실상의 표준 아키텍처 (de facto architecture)로 빠르게 자리 잡고 있습니다.

개발자들이 실수하는 부분

제가 보는 가장 큰 실수는 무엇일까요? MCP를 사용하여 A2A 문제를 해결하려 하거나, 그 반대로 하는 것입니다.

예를 들어:

• ❌ 에이전트 간 메시지 라우팅을 위해 MCP 도구 호출 (tool calls)을 사용하려고 시도함
• ❌ A2A가 이미 정의하고 있음에도 불구하고 커스텀 에이전트 발견 (agent discovery) 기능을 구축함
• ❌ MCP 서버 내부에서 A2A 방식의 역량 협상 (capability negotiation)을 구현함

명확하게 구분하세요:

• MCP = 하나의 에이전트, 여러 개의 도구 (tools)
• A2A = 여러 개의 에이전트, 하나의 대화 (conversation)

실제 아키텍처 (Real-World Architecture)

제가 프로덕션 시스템을 구성한다면 다음과 같이 할 것입니다:

┌─────────────────────────────────────┐
│   A2A 계층 (에이전트 조정)         │
│  - 발견 레지스트리 (Discovery registry) │
...

각 에이전트는 자신만의 MCP 스택을 가집니다. A2A 계층은 전체 시스템을 오케스트레이션 (orchestrate)합니다.

표준화의 리스크

한 가지 주의할 점은, 두 프로토콜 모두 아직 중립적인 표준화 기구 (standards body)에 의해 관리되지 않고 있다는 점입니다. MCP는 Anthropic의 산물이며, A2A는 Google의 것입니다. 이것이 반드시 결정적인 결함은 아니지만, 상업적 우선순위에 따라 사양 (specs)이 변할 수 있음을 의미합니다.

엔터프라이즈급 (enterprise-grade) 시스템을 구축하고 있다면 거버넌스 (governance)를 주시하십시오. 최악의 시나리오는 특정 벤더의 사양 해석에 종속(lock-in)되는 것입니다.

지금 당장 신경 써야 할까요?

만약 당신이 다음과 같은 것을 구축하고 있다면:

• 단일 에이전트 시스템 (Single-agent systems) → MCP가 즉시 유용합니다. 거기서부터 시작하세요.
• 멀티 에이전트 오케스트레이션 (Multi-agent orchestration) → 두 계층 모두 필요합니다. 첫날부터 A2A를 고려하여 설계하세요.
• 대규모 엔터프라이즈 AI (Enterprise AI at scale) → 이 2계층 스택은 이제 필수 요건 (table stakes)이 되고 있습니다. AI 자동화 및 소프트웨어 개발 분야에서 활동하는 팀들은 이미 이 아키텍처를 채택하고 있습니다.

그 보상은 확실합니다: 더 깔끔한 코드, 더 낮은 결합도 (less coupling), 더 쉬운 확장성. 그리고 다음 대형 LLM 프레임워크가 출시되어도, 모든 것을 다시 작성할 필요가 없을 것입니다.

시작하는 방법

1. MCP로 실험하기 — Anthropic의 문서가 매우 탄탄합니다. 간단한 툴 서버 (tool server)를 구축해 보세요.
2. A2A 사양 읽기 — Google이 올해 초에 이를 발표했습니다. 예상보다 훨씬 명확합니다.
3. 분리된 구조를 고려하여 설계하기 — 오늘 당장 두 가지를 모두 사용하지 않더라도, 마치 사용할 것처럼 코드를 구조화하세요.

에이전트 인터넷 (agent internet)이 다가오고 있습니다. 이 두 프로토콜은 그 기반이 되는 배관 (plumbing) 역할을 할 것입니다.