MCP vs A2A: 에이전트 아키텍처를 잘못 구축하는 것을 멈추세요

만약 당신이 지금 프로덕션 환경에서 AI 에이전트들을 연결하고 있다면, 아마 저와 똑같은 혼란을 겪고 있을 것입니다: 언제 MCP를 사용해야 하고, 언제 A2A가 필요한가?

알고 보니, 이 둘은 대안 관계가 아닙니다. 이들은 스택의 서로 다른 계층에서 서로 다른 문제를 해결합니다. 이 둘을 혼동하면 v1을 출시하기도 전에 아키텍처를 망가뜨리게 될 것입니다.

3개월 전 누군가가 저에게 말해줬으면 좋았을 내용들을 정리해 보겠습니다.

MCP: 에이전트가 도구와 대화함

Model Context Protocol (Anthropic의 규격)은 **에이전트-도구 간 통신 (agent-to-tool communication)**에 관한 것입니다. 이를 LLM과 무언가를 수행하기 위해 필요한 것들 사이의 인터페이스 계층이라고 생각하세요.

에이전트가 다음과 같은 작업을 수행해야 할 때:

• 데이터베이스 쿼리 (Query a database)
• 내부 API 호출 (Call an internal API)
• 파일 시스템 읽기 (Read from a file system)
• 고객 기록 가져오기 (Fetch customer records)

...이것은 MCP의 영역입니다.

MCP가 실제로 제공하는 것

// MCP 서버가 기능을 노출함
const mcpServer = {
  tools: [
...

이 프로토콜은 에이전트가 어떤 도구가 존재하는지 _발견(discover)_하고, 어떻게 호출하며, 결과가 어떻게 다시 흘러 들어오는지에 대한 방식을 표준화합니다. 이는 스키마 협상 (schema negotiation) 기능이 내장된 RPC입니다.

결정적으로: MCP는 에이전트의 자율성 (autonomy)에 신경 쓰지 않습니다. 이는 요청-응답 (request-response) 패턴입니다. 에이전트가 요청하면, 도구가 응답합니다. 그것으로 끝입니다.

A2A: 에이전트들이 서로 대화함

Agent-to-Agent 프로토콜 (멀티 에이전트 조정에 대한 Google의 해답)은 완전히 다른 계층에서 작동합니다. 이것은 자율 시스템들이 서로 협상하는 것에 관한 것입니다.

다음이 필요할 때:

• 리서치 에이전트가 요약 에이전트에게 작업을 위임할 때
• 플래닝 에이전트가 실행 에이전트들과 조율할 때
• 에이전트들이 작업 소유권을 협상할 때
• 에이전트 워크플로우 간의 비동기적 핸드오프 (Asynchronous handoffs)

...이것은 A2A의 영역입니다.

핵심 차이점

A2A는 양측 모두가 에이전시 (agency)를 가지고 있다고 가정합니다. 그들은 단순한 도구를 호출하는 것이 아닙니다. 자신만의 목표, 컨텍스트, 의사결정 능력을 가진 다른 지능형 시스템과 협업하는 것입니다.

A2A 조정 (개념적)

에이전트 A -> 에이전트 B: "영국 세금 계산을 처리할 수 있나요?"
에이전트 B -> 에이전트 A: "네, 거래 데이터를 보내주세요"
...

이러한 주고받는 과정을 주목하세요. 이것이 바로 협상 (Negotiation)입니다. MCP는 이를 수행하지 않습니다.

구축 시 이것이 중요한 이유

팀들이 실수하는 지점은 바로 여기입니다. 에이전트들을 서로 연결하기 위해 MCP를 사용하려고 시도하는 것입니다.

이렇게 하지 마세요:

# 안티 패턴 (Anti-pattern): MCP를 통한 에이전트 간 통신
mcp_server.register_tool(
    name="call_summarisation_agent",  # ❌ 이것은 에이전트이지, 도구가 아닙니다.
...

왜 이것이 문제가 될까요?

• MCP는 동기적 (Synchronous)이고 차단적 (Blocking)입니다. 에이전트에게는 비동기적 (Async) 조정이 필요합니다.
• MCP에는 에이전트 상태 (State)나 컨텍스트 전달 (Context handoff)에 대한 개념이 없습니다.
• 협상 계층 (Negotiation layer)을 잃게 됩니다. (만약 에이전트가 바쁘거나, 사용 불가능하거나, 명확한 설명이 필요하다면 어떻게 될까요?)

대신, MCP를 사용하여 각 에이전트에게 고유한 도구를 부여한 다음, A2A (또는 메시지 버스, 혹은 에이전트 인지 의미론을 가진 HTTP)를 사용하여 에이전트들이 서로 조정할 수 있도록 하세요.

더 나은 아키텍처:

┌─────────────────┐         ┌─────────────────┐
│   Agent A       │         │   Agent B       │
│                 │         │                 │
...

각 에이전트는 도구에 접근하기 위한 고유한 MCP 인터페이스를 가집니다. 에이전트들은 A2A를 통해 서로 통신합니다.

내일부터 해야 할 일

에이전트 시스템을 설계하고 있다면 다음을 수행하세요:

1. 도구 계층을 먼저 매핑하세요 — 에이전트에게 필요한 외부 기능은 무엇인가요? 그것들을 위한 MCP 서버를 구축하세요.
2. 에이전트 경계를 식별하세요 — 한 에이전트의 책임이 어디서 끝나고 다른 에이전트의 책임이 어디서 시작되나요?
3. A2A 전송 방식을 선택하세요 — Google의 사양일 수도 있고, 에이전트 인지 의미론을 가진 메시지 큐 (Message queue)일 수도 있습니다. 단, MCP를 사용하지는 마세요.
4. 에이전트가 서로의 내부 구조에 대해 무지하도록 유지하세요 — 에이전트들은 RPC가 아닌 상위 수준의 의도 (Intent)를 통해 조정해야 합니다.

2계층 스택 (two-layer stack)은 이론적인 것이 아닙니다. 이는 여러분의 시스템이 개념 증명 (Proof-of-concept) 단계를 넘어 확장하기 위해 필요한 관심사 분리 (Separation of concerns)입니다.

핵심 요약

• MCP = 에이전트 (agent) ↔ 도구 (tool) (동기식 (synchronous), 요청-응답 (request-response), 기능 노출 (capability exposure))
• A2A = 에이전트 (agent) ↔ 에이전트 (agent) (비동기식 (asynchronous), 상태 유지 (stateful), 조정 (coordination))

이를 잘못 설계하면 세 번째 에이전트를 추가해야 할 때 전체 스택을 리팩터링 (refactoring)해야 하는 상황에 직면하게 됩니다. 반대로 올바르게 설계하면 규모를 확장하더라도 아키텍처 (architecture)를 깔끔하게 유지할 수 있습니다.

만약 이를 실제로 구축하고 있으며 아키텍처 설계에 도움이 필요하다면, 진지하게 AI 자동화 및 소프트웨어 개발 (AI automation and software development)을 수행하는 팀들은 이미 이 멘탈 모델 (mental model)을 사용하고 있습니다.

이제 더 많은 에이전트를 추가하더라도 무너지지 않는 무언가를 구축하러 가십시오.