당신이 이미 겪고 있을 문제

2025년에 에이전트 시스템 (agentic systems)을 구축하고 있다면, 당신의 스택에는 이미 두 개의 통합 계층이 존재할 가능성이 높습니다:

• MCP (Model Context Protocol) — AI 모델을 데이터베이스, API, 파일 시스템, 내부 도구에 연결
• A2A (Agent-to-Agent) 프로토콜 — 에이전트들이 서로를 발견하고, 협상하며, 호출할 수 있도록 함

이 둘은 경쟁 관계가 아닙니다. 상호 보완적입니다. 하지만 명확한 상호 운용성 (interoperability) 전략이 없다면, 과거 ESB 시대에 기업 아키텍트들을 바쁘고 고통스럽게 만들었던 통합 스파게티 (integration spaghetti) 상황을 자초하게 될 것입니다.

MCP가 실제로 하는 일

MCP는 Anthropic이 단순한 문제에 대해 내놓은 해답입니다: 어떻게 하면 모든 데이터 소스마다 맞춤형 글루 코드 (glue code)를 작성하지 않고도, LLM에 외부 리소스에 대한 구조화되고 신뢰할 수 있는 접근 권한을 부여할 수 있을까?

프롬프트에 데이터베이스 쿼리나 API 호출을 하드코딩하는 대신, 이를 **MCP 서버 (MCP servers)**로 노출합니다. 당신의 AI 클라이언트는 표준 프로토콜을 통해 연결되어, 사용 가능한 도구를 발견하고, 타입이 지정된 파라미터 (typed parameters)로 이를 호출합니다.

사용 사례 예시:

# MCP 서버가 도구를 노출함
@mcp_tool
def query_customer_orders(customer_id: str) -> list[Order]:
...

이제 당신의 LLM은 프롬프트 엔지니어링 (prompt engineering), 취약한 스크래핑 (scraping), 혹은 모델이

MCP와 달리, A2A는 여전히 파편화되어 있습니다. 단일 표준이 존재하지 않습니다. 당신은 다음과 같은 것들을 사용하고 있을지도 모릅니다:

• 커스텀 서비스 메시 (service meshes)를 사용하는 HTTP API
• 발행/구독 (Pub/sub) 큐 (Kafka, RabbitMQ)
• Protobuf 스키마를 사용하는 gRPC
• LangChain, AutoGen, CrewAI의 독점 프레임워크 (Proprietary frameworks)

각각은 작동합니다. 하지만 어느 것도 깔끔하게 상호 운용(interoperate)되지는 않습니다.

이것이 왜 익숙하게 느껴지는가 (그리고 좋지 않은 의미로)

만약 당신이 2000년대에 엔터프라이즈 통합 (enterprise integration) 분야에서 일했다면, 이것은 **ESB 데자뷔 (ESB déjà vu)**처럼 느껴질 것입니다.

엔터프라이즈 서비스 버스 (Enterprise Service Bus, ESB)는 n-제곱 통합 문제를 해결하겠다고 약속했습니다. 즉, 모든 시스템이 서로 직접 통신하는 대신, 모든 것을 중앙 버스를 통해 라우팅하는 방식입니다.

그것은 작동했습니다 — 작동하지 않게 될 때까지는 말이죠. ESB는 다음과 같은 존재가 되었습니다:

• 단일 장애점 (Single points of failure)
• 성능 병목 현상 (Performance bottlenecks)
• 독점적 락인 함정 (Proprietary lock-in traps) (TIBCO와 WebSphere를 염두에 두고 하는 말입니다)

지금 나타나고 있는 이중 계층 스택 (two-layer stack) — 하단의 MCP와 상단의 A2A — 도 주의하지 않는다면 똑같은 운명을 맞이할 위험이 있습니다.

당신이 취해야 할 조치

1. MCP를 애플리케이션 로직이 아닌 인프라로 취급하세요

MCP는 리소스 접근을 표준화하는 데 탁월합니다. MCP 도구에 비즈니스 로직을 쑤셔 넣음으로써 이를 남용하지 마세요. 도구는 가볍고(thin), 조합 가능하며(composable), 상태가 없는(stateless) 상태로 유지하십시오.

2. 경계 컨텍스트 (bounded context)당 _하나_의 A2A 패턴을 선택하세요

정말 타당한 이유가 없다면 동일한 워크플로우 내에서 발행/구독 (pub/sub)과 RPC를 혼용하지 마세요. 새벽 2시에 멀티 에이전트 (multi-agent) 실패를 디버깅할 때는 유연성보다 일관성이 승리합니다.

3. 교체 가능성을 고려하여 설계하세요

오늘 당신이 선택한 어떤 A2A 프레임워크라도 아마 18개월 뒤에는 레거시 (legacy)가 될 것입니다. 그것을 감싸세요 (Wrap). 추상화하세요 (Abstract). 교체 가능하게 만드세요.

예시:

class AgentInvoker(Protocol):
    def invoke(self, agent_id: str, task: dict) -> dict:
        ...
...

4. 두 계층을 분리하여 모니터링하세요

MCP 실패와 A2A 실패는 양상이 다릅니다:

• MCP: "Tool not found", "Database timeout", "API key expired"
• A2A: "Agent unavailable", "Circular dependency", "Message bus backlog"

당신의 관찰성 스택 (observability stack)은 이 둘을 구분할 수 있어야 합니다.

지루한 진실

아직 만능 해결책(silver bullet)은 없습니다. MCP는 빠르게 성숙해지고 있지만, A2A는 여전히 서부 개척 시대(Wild West)와 같습니다. 만약 당신이 프로덕션 에이전트 시스템 (production agentic systems) — 특히 규제 산업이나 대규모 환경 — 을 구축하고 있다면, 이를 단순한 도구 선택이 아닌 **아키텍처 리스크 (architecture risk)**로 취급하십시오.

개발을 중단할 필요는 없습니다. 하지만 반드시 다음 사항을 수행해야 합니다:

• 통합 계층 (integration layer) 격리
• 에이전트 계약 (agent contracts)의 버전 관리
• 마이그레이션 계획 수립

이를 제대로 수행하는 팀은 가장 영리한 에이전트를 가진 팀이 아닐 것입니다. 그들은 전체를 다시 작성하지 않고도 에이전트들을 재배선 (rewire) 할 수 있는 팀이 될 것입니다.

만약 MCP, A2A, 또는 에이전트 스택 (agentic stack)의 다른 부분을 평가 중이며 제2의 의견이 필요하다면, AI 자동화 및 소프트웨어 개발을 전문으로 하는 팀들이 당신이 경로를 수정하기 어려워지기 전에 아키텍처의 리스크를 줄이는 데 도움을 줄 수 있습니다.

하지만 솔직히 말할까요? 그냥 또 다른 ESB를 만들지는 마세요. 저희도 그런 경험이 있습니다. 전혀 즐겁지 않았습니다.