A2A와 MCP: AI 에이전트가 정말 두 가지 프로토콜을 모두 필요로 하는가?

MCP는 에이전트에 도구를 제공하고, A2A는 에이전트에 동료(피어)를 제공합니다.

Page content

AI 에이전트 아키텍처가 두 개의 레이어로 분화되기 시작하고 있습니다.

첫 번째 레이어는 AI 어시스턴트에게 도구, 데이터, API, 파일, 데이터베이스, 검색 시스템, 캘린더, 티켓팅 시스템 및 기타 외부 기능에 대한 접근 권한을 부여하는 것입니다. 이때 MCP(Model Context Protocol)가 그 역할을 합니다.

두 번째 레이어는 한 AI 에이전트가 다른 AI 에이전트(다른 팀, 프레임워크, 벤더 또는 조직에 의해 구축된 것일 수 있음)를 발견하고, 소통하며, 업무를 위임하고 협력하는 것입니다. 이때 A2A(Agent2Agent Protocol)가 그 역할을 합니다.

불편한 점은 두 프로토콜이 종종 동일한 문제를 해결하는 것처럼 논의된다는 것입니다. 하지만 그들은 그렇지 않습니다. 가장자리에서 일부 중복이 있지만, 대부분의 혼란은 이 중복 부분에서 비롯됩니다. 그러나 명확한 정신적 모델(Mental Model)은 간단합니다.

MCP는 주로 에이전트-투-툴(Agent-to-Tool) 관계이고, A2A는 주로 에이전트-투-에이전트(Agent-to-Agent) 관계입니다.

A2A and MCP protocol architecture — AI agents connected via A2A, each accessing tools via MCP

이것이 모든 AI 시스템이 둘 다 필요하다는 의미는 아닙니다. 실제로 대부분의 소규모 에이전트 프로젝트는 MCP로 시작하고, 실제 다중 에이전트 경계가 필요할 때까지 A2A를 무시하는 것이 좋습니다. 그러나 대규모 에이전트 시스템, 특히 별도로 배포된 에이전트, 전문 에이전트, 벤더 에이전트 또는 장기 실행 위임 작업을 다루는 시스템을 구축 중이라면 A2A가 합리적인 선택이 됩니다.

이 글에서는 두 프로토콜의 차이점, 중복 부분, 아키텍처적 트레이드오프, 그리고 실제로 둘 다 필요할 때에 대해 설명합니다.

MCP란 무엇인가?

MCP는 Model Context Protocol(모델 컨텍스트 프로토콜)의 약자입니다.

이는 AI 애플리케이션과 에이전트를 외부 도구, 리소스 및 프롬프트에 연결하기 위한 개방형 프로토콜입니다. 실용적인 측면에서 MCP는 데스크톱 어시스턴트, IDE, 코딩 에이전트 또는 채팅 애플리케이션과 같은 AI 호스트가 하나 이상의 MCP 서버에 연결할 수 있게 합니다.

MCP 서버는 다음과 같은 기능을 노출할 수 있습니다.

  • 도구(Tools): 모델이 사용할 수 있는 호출 가능한 함수
  • 리소스(Resources): 파일, API 데이터, 문서 또는 데이터베이스 레코드와 같은 읽기 가능한 컨텍스트
  • 프롬프트(Prompts): 재사용 가능한 프롬프트 템플릿 또는 워크플로우

공식 MCP 아키텍처는 호스트, 클라이언트 및 서버 모델에 기반합니다.

MCP 호스트는 사용자가 상호 작용하는 애플리케이션입니다. MCP 클라이언트는 특정 MCP 서버와의 연결을 유지하는 프로토콜 구성 요소입니다. MCP 서버는 클라이언트에게 기능을 노출합니다.

예를 들어, 코딩 어시스턴트는 다음과 같은 서버에 연결할 수 있습니다.

  • 파일시스템 MCP 서버
  • GitHub MCP 서버
  • 데이터베이스 MCP 서버
  • Sentry MCP 서버
  • Slack MCP 서버

사용자의 관점에서 보면 어시스턴트가 더 유용해집니다. 시스템 아키텍처의 관점에서 보면, 어시스턴트는 외부 컨텍스트와 작업에 대한 제어된 접근 권한을 확보하게 됩니다.

여기서 MCP의 주요 가치가 있습니다. MCP는 AI 애플리케이션이 도구와 컨텍스트에 접근하는 방식을 표준화합니다.

MCP는 도구 통합으로 가장 잘 이해됨

MCP는 도구만을 다루는 것은 아니지만, 도구를 통해 가장 쉽게 이해할 수 있습니다.

MCP 없이 모든 AI 애플리케이션은 각 외부 시스템마다 맞춤형 통합 코드가 필요합니다. 한 에이전트 프레임워크는 자체 플러그인 형식을 가지고 있고, 다른 프레임워크는 자체 도구 스키마를 가지며, 또 다른 프레임워크는 다른 API 래퍼 패턴을 사용합니다. 모든 통합이 매번 다시 구축됩니다.

MCP는 이러한 낭비를 줄이려고 합니다.

도구 제공자가 MCP 서버를 노출하면, 많은 MCP 호환 클라이언트가 이를 사용할 수 있습니다. 개발자가 내부 시스템을 위해 MCP 서버를 구축하면, 여러 AI 애플리케이션이 이를 연결할 수 있습니다. Go에서의 MCP 서버 및 Python에서의 MCP 서버에 대한 실제 구현 가이드는 프로토콜이 중량 작업을 처리하면 통합 레이어가 얼마나 직관적으로 될 수 있는지 보여줍니다.

이 때문에 MCP가 이렇게 빠르게 중요해졌습니다. MCP는 지루하지만 고통스러운 통합 문제를 해결합니다.

그리고 지루한 통합 문제는 종종 내구성 있는 표준이 탄생하는 곳입니다. 이러한 표준은 누구나 해야 하는 반복 작업을 줄여주기 때문에 살아남습니다.

A2A란 무엇인가?

A2A는 Agent2Agent Protocol(에이전트 투 에이전트 프로토콜)의 약자입니다.

이는 독립적인 AI 에이전트 시스템 간의 통신과 상호 운용성을 위한 개방형 표준입니다. 개별 빌딩 블록(에이전트 카드, 작업 수명주기, 메시지, 부품, 아티팩트)에 대한 더 깊은 분석은 A2A 프로토콜이란 무엇인가? 에이전트 카드와 작업 설명에서 각 개념을 상세히 다룹니다. 공식 A2A 사양은 이 프로토콜을 다른 프레임워크, 언어 또는 벤더로 구축된 에이전트들이 공통 상호 작용 모델을 통해 통신할 수 있는 방법으로 설명합니다.

핵심 문구는 “독립적인 에이전트 시스템"입니다.

A2A의 주된 목적은 하나의 어시스턴트에게 계산기, 데이터베이스 또는 파일 시스템에 대한 접근 권한을 부여하는 것이 아닙니다. 이는 자체 기능, 상태, 정책, 작업 모델 및 백그라운드에서 자체 도구를 가진 다른 에이전트와 한 에이전트가 통신하는 것에 관한 것입니다.

A2A 에이전트는 에이전트 카드를 통해 자신이 할 수 있는 일을 광고할 수 있습니다. 다른 에이전트나 클라이언트는 해당 기능을 발견하고, 작업을 보내며, 메시지를 주고받고, 아티팩트를 받으며, 작업 수명주기를 추적할 수 있습니다.

A2A는 다음과 같은 개념을 도입합니다.

  • 에이전트 카드(Agent Cards)
  • 에이전트 및 클라이언트
  • 작업(Tasks)
  • 메시지(Messages)
  • 부품(Parts)
  • 아티팩트(Artifacts)
  • 작업 상태(Task states)
  • 스트리밍 및 비동기 작업

이러한 개념들을 종합하면, A2A는 단순한 도구 호출 프로토콜보다 에이전트 협력 프로토콜처럼 느껴집니다. 이는 에이전트가 정체성, 상태 및 다른 에이전트와의 지속적인 관계를 가지고 있다는 아이디어를 중심으로 설계되었습니다.

A2A는 에이전트 협력으로 가장 잘 이해됨

사용자가 기업용 어시스턴트에게 다음과 같이 요청한다고 상상해 보세요.

“일본 시장 진입 보고서를 준비해 주세요. 법적 고려사항, 가격 리스크 및 출시 프로젝트 계획을 포함해 주세요.”

간단한 어시스턴트는 모든 것을 스스로 시도할 수 있습니다. 그러나 더 큰 에이전트 시스템은 작업의 일부를 위임할 수 있습니다.

  • 연구 에이전트가 시장 정보를 수집함
  • 법률 에이전트가 규제 고려사항을 확인함
  • 재무 에이전트가 가격 리스크를 추정함
  • 프로젝트 계획 에이전트가 배포 계획을 생성함
  • 작성 에이전트가 최종 보고서를 조립함

이러한 에이전트들이 모두 하나의 코드베이스 내부의 내부 함수라면 A2A가 필요하지 않을 수 있습니다. 함수나 서비스를 직접 호출하면 됩니다.

하지만 이러한 에이전트들이 독립적인 시스템이고, 서로 다른 팀이나 벤더가 소유한 경우라면 표준 에이전트-투-에이전트 프로토콜이 유용해집니다.

이것이 A2A의 사용 사례입니다.

A2A 대 MCP: 간단한 차이점

가장 간단한 비교는 다음과 같습니다.

질문 MCP A2A
주요 관계 에이전트에서 도구로 에이전트에서 에이전트로
주요 목적 AI 앱을 도구, 데이터, 프롬프트에 연결 독립적인 에이전트들이 통신하고 협력하도록 함
일반적인 작업 단위 도구 호출 또는 리소스 읽기 작업, 메시지, 아티팩트, 위임
가장 적합한 경우 도구 통합 다중 에이전트 상호 운용성
예시 에이전트가 데이터베이스 도구를 호출함 연구 에이전트가 법률 에이전트로 위임함
범위 컨텍스트 및 기능 접근 에이전트 조정 및 작업 교환

이 표는 완벽하지는 않지만 초기 정신적 모델을 구축하는 데 유용합니다. 요약하면, MCP는 “이 AI 애플리케이션은 외부 기능에 어떻게 접근하는가?“라는 질문에 답하고, A2A는 “이 에이전트는 다른 에이전트와 어떻게 협력하는가?“라는 질문에 답합니다.

이 구분이 중요한 이유는 도구 통합과 에이전트 협력에는 서로 다른 실패 모드(failure modes)가 있기 때문입니다. 잘못된 도구 호출은 잘못된 데이터를 반환하거나 잘못된 파일을 수정할 수 있지만, 잘못된 에이전트 위임은 책임 사슬을 불분명하게 만들거나, 민감한 컨텍스트를 누출하거나, 에이전트 간 루프를 발생시키거나, 작업을 중복하거나, 아무도 감사할 수 없는 아티팩트를 생성할 수 있습니다. A2A는 아키텍처에서 한 단계 더 높은 수준에 위치하며, 그 실패 모드는 상응하는 더 높은 결과를 초래합니다.

개발자들이 A2A와 MCP를 혼동하는 이유

이 혼란은 이해할 만합니다.

많은 MCP 서버가 단순히 멍청한 도구가 아닙니다. 일부 MCP 서버는 다단계 작업을 수행할 수 있습니다. 일부는 에이전트처럼 보이는 고수준 기능을 노출합니다. MCP 서버는 계획 서비스, 검색 시스템 또는 심지어 다른 LLM 기반 워크플로우를 래핑할 수 있습니다.

이 지점에서 경계가 흐릿해집니다.

research_topic이라는 이름의 MCP 도구가 복잡한 연구 워크플로우를 수행한다면, 그것은 도구인가 에이전트인가?

솔직한 답은: 아키텍처적으로는 상황에 따라 다르다.

호스트가 도구 스키마를 가진 호출 가능한 기능으로 취급한다면, 그것은 도구로 기능합니다.

자체 정체성, 기능, 작업 수명주기, 메시지, 아티팩트 및 위임 동작을 가진다면, 그것은 에이전트처럼 보이기 시작합니다.

이것이 “A2A 대 MCP"가 종교적인 논쟁으로 변할 때 잘못된 프레임인 이유입니다. 더 나은 프레임은 다음과 같습니다.

  • 이 외부 기능은 도구로 모델링하는 것이 가장 좋은가?
  • 아니면 독립적인 에이전트로 모델링하는 것이 가장 좋은가?

이 결정이 프로토콜 선택을 주도해야 합니다.

MCP만 사용하는 경우

대부분의 AI 프로젝트는 MCP만으로 시작해야 합니다. 이는 다소 주관적인 입장이나 실용적인 것입니다.

코딩 어시스턴트, 내부 챗봇, 로컬 AI 워크플로우, 개인 자동화 에이전트 또는 간단한 기업용 어시스턴트를 구축 중이라면, 첫 번째 문제는 보통 에이전트-투-에이전트 협력이 아닙니다. 첫 번째 문제는 도구 접근입니다.

어시스턴트에게 파일을 읽고, 데이터베이스를 쿼리하고, 문서를 검색하고, API를 호출하고, 티켓을 열며, 로그를 요약하고, 메트릭을 검사하거나, 레코드를 업데이트하도록 해야 합니다.

MCP가 이를 매우 잘 지원합니다.

다음과 같은 경우 MCP만 사용하세요.

  • 에이전트가 주로 도구와 데이터에 접근해야 할 때
  • 호스트 애플리케이션을 제어할 때
  • 대부분의 통합을 제어할 때
  • 외부 시스템이 실제로 자율 에이전트가 아닐 때
  • 워크플로우가 주로 동기식 또는 단기 실행일 때
  • 일반적인 도구 호출이 충분할 때
  • 에이전트 발견이 필요하지 않을 때
  • 에이전트 간 작업 상태가 필요하지 않을 때
  • 독립적인 에이전트로부터의 아티팩트가 필요하지 않을 때

많은 시스템의 경우, MCP와 좋은 애플리케이션 아키텍처면 충분합니다. 많은 팀이 실제로 도구 사용 어시스턴트인 시스템에 A2A를 과도하게 엔지니어링하며, 이는 프로토콜 문제가 아니라 어떤 프로토콜로도 해결할 수 없는 아키텍처 규율 문제입니다.

A2A만 사용하는 경우

A2A 전용 시스템은 덜 흔하지만 존재할 수 있습니다.

시스템이 에이전트 간의 통신에 주로 초점을 맞추고, 각 에이전트가 이미 내부적으로 자체 도구를 관리한다면 MCP 없이 A2A를 사용할 수 있습니다.

예를 들어:

  • 전문 에이전트의 마켓플레이스
  • 벤더 간 에이전트 통합
  • 조직 간 워크플로우
  • 각 에이전트가 자체 사설 도구체인을 가진 다중 에이전트 시스템
  • 클라이언트가 내부 도구 세부 정보를 알 필요가 없는 위임 네트워크

이 모델에서 A2A는 독립적으로 관리되는 에이전트 간의 공개 경계입니다. 에이전트 A는 에이전트 B가 백그라운드에서 PostgreSQL, Elasticsearch, MCP, LangChain, 사용자 정의 API 또는 셸 스크립트를 사용하는지 알 필요가 없습니다. 에이전트 A는 에이전트 B가 무엇을 할 수 있는지, 작업을 보내는 방법, 결과를 받는 방법만 알면 됩니다.

이는 깔끔한 추상화입니다.

다음과 같은 경우 A2A만 사용하세요.

  • 에이전트를 독립적인 서비스로 노출할 때
  • 호출자가 에이전트의 내부 도구를 알 필요가 없을 때
  • 에이전트 기능 발견이 중요할 때
  • 직접 도구 접근보다 위임이 더 중요할 때
  • 작업이 장기 실행될 수 있을 때
  • 결과에 아티팩트가 포함될 수 있을 때
  • 에이전트가 다른 벤더나 팀에 의해 구축될 수 있을 때

A2A는 독립적으로 소유된 에이전트가 내부 도구체인을 노출하지 않고 작업과 아티팩트를 교환해야 하는 시스템 경계에서 가장 강력합니다. 이는 모든 에이전트 런타임의 모든 레이어에 연결해야 하는 프로토콜이 아닙니다.

A2A와 MCP를 모두 사용하는 경우

가장 흥미로운 아키텍처는 A2A 대 MCP가 아닙니다. A2A와 MCP입니다.

이 패턴에서 에이전트는 다른 에이전트에게 A2A 인터페이스를 노출하지만, 내부적으로 도구에 접근하기 위해 MCP를 사용합니다.

이는 두 개의 깔끔한 레이어를 제공합니다.

  • 외부 A2A: 에이전트들이 서로 통신하는 방식
  • 내부 MCP: 각 에이전트가 도구, 데이터 및 서비스에 접근하는 방식

이것이 아마도 가장 내구성 있는 정신적 모델일 것입니다.

고객 지원 에이전트는 A2A 인터페이스를 노출할 수 있습니다. 다른 에이전트들은 이를 통해 지원 관련 작업을 위임할 수 있습니다. 내부적으로 지원 에이전트는 Zendesk, Slack, 문서 검색, CRM 조회 및 내부 정책 검색을 위해 MCP 서버를 사용합니다.

DevOps 에이전트는 A2A 인터페이스를 노출할 수 있습니다. 다른 에이전트들은 이를 통해 사건을 조사하도록 요청할 수 있습니다. 내부적으로 이는 Prometheus, Grafana, GitHub, Kubernetes, 로그 및 클라우드 API를 위한 MCP 서버를 사용합니다.

재무 에이전트는 A2A 인터페이스를 노출할 수 있습니다. 다른 에이전트들은 예산 분석을 요청할 수 있습니다. 내부적으로 이는 스프레드시트, 회계 시스템, 송장 데이터베이스 및 예측 모델을 위한 MCP 서버를 사용합니다.

이 패턴은 에이전트 간의 깔끔한 경계를 유지합니다. 다른 에이전트들은 각 도구에 대한 직접 접근이 필요하지 않습니다. 그들은 전문 에이전트와 통신하며, 해당 에이전트는 작업을 완료하는 데 필요한 도구를 내부적으로 결정합니다.

실제 조직도 보통 이렇게 작동합니다. 모든 사람에게 프로덕션 데이터베이스에 대한 직접 접근 권한을 주지 않습니다. 해당 도메인을 담당하는 팀이나 서비스에 요청합니다.

참조 아키텍처: 외부 A2A, 내부 MCP

실용적인 다중 에이전트 아키텍처는 다음과 같을 수 있습니다.

User
  |
  v
Primary assistant or orchestrator
  |
  |-- A2A --> Research agent
  |              |
  |              |-- MCP --> Web search
  |              |-- MCP --> Document store
  |
  |-- A2A --> Coding agent
  |              |
  |              |-- MCP --> GitHub
  |              |-- MCP --> Filesystem
  |              |-- MCP --> CI system
  |
  |-- A2A --> DevOps agent
                 |
                 |-- MCP --> Metrics
                 |-- MCP --> Logs
                 |-- MCP --> Kubernetes

이 디자인에서 A2A는 에이전트 간 위임을 처리하고, MCP는 각 에이전트와 그 도구 간의 통합을 처리합니다. 오케스트레이터는 각 전문가에게 사용 가능한 모든 도구를 알 필요가 없습니다. 오케스트레이터는 어떤 유형의 작업을 어떤 에이전트가 담당하는지만 알면 되므로, 도구 과부하를 줄이고 전체 아키텍처를 더 모듈식으로 유지할 수 있습니다. 추론, 메모리, 라우팅 및 툴링이 프로덕션 어시스턴트 내부에서 어떻게 맞춰지는지에 대한 더 깊은 분석은 AI 어시스턴트 아키텍처: LLM, 메모리, 도구, 라우팅, 관찰성에서 해당 레이어들을 자세히 다룹니다.

A2A가 과도한 경우

“다른 에이전트"가 실제로는 그냥 함수일 때 A2A는 과도합니다.

애플리케이션이 몇 가지 도구를 호출하는 하나의 LLM 워크플로우를 가지고 있다면, 현대적으로 들린다고 해서 A2A를 추가하지 마세요. Python 함수, HTTP 엔드포인트, 큐 또는 MCP 도구가 충분할 수 있습니다.

다음과 같은 경우 A2A가 너무 많을 수 있습니다.

  • 에이전트가 하나뿐일 때
  • 모든 구성 요소가 하나의 코드베이스에 있을 때
  • 워크플로우가 짧고 동기식일 때
  • 발견이 필요하지 않을 때
  • 독립적인 작업 상태가 필요하지 않을 때
  • 별도의 에이전트 정체성이 필요하지 않을 때
  • 제3자 에이전트를 예상하지 않을 때
  • 벤더 또는 프레임워크 상호 운용성이 필요하지 않을 때

프로토콜은 무료가 아닙니다. 프로토콜은 개념, 인프라, 디버깅 표면, 보안 문제 및 운영 비용을 추가합니다. 지루한 API나 간단한 함수 호출이 때로는 더 나은 엔지니어링 선택일 수 있으며, 필요성보다는 습관적으로 A2A를 선택하는 것 자체가 일종의 과잉 엔지니어링입니다. 더 간단한 옵션을 선택하는 것은 A2A에 반대하는 것이 아니라, 아키텍처를 지지하는 것입니다.

MCP가 충분하지 않은 경우

MCP는 에이전트라고 명확히 말할 수 있는 것들을 표현하는 데 사용할 때 부족해지기 시작합니다.

예를 들어, MCP 서버가 다음과 같은 도구를 노출한다고 가정해 보세요.

complete_enterprise_procurement_review

이 도구는 다음을 수행합니다.

  • 벤더 데이터 읽기
  • 정책 규칙 확인
  • 명확화 질문 제기
  • 법률 검토 위임
  • 리스크 보고서 생성
  • 여러 아티팩트 반환
  • 20분 동안 실행
  • 작업 상태 유지
  • 감사 기록 필요

어느 시점에서 이 기능을 “도구"라고 부르는 것은 어색해집니다. 왜냐하면 이 기능은 더 이상 단순한 호출 가능한 함수가 아니라, 자체 상태, 위임 및 감사 요구사항을 가진 워크플로우 소유 전문가이기 때문입니다. 바로 여기서 A2A가 도구 추상화의 자연스러운 경계를 넘어서는 것보다 더 적합한 선택이 됩니다.

MCP는 강력한 도구를 노출할 수 있지만, 에이전트 정체성, 피어 간 협력, 작업 소유권, 위임 시맨틱스 또는 다중 에이전트 감사 추적은 마법처럼 해결하지 않습니다.

이것이 실제 문제라면, 당신은 A2A 영역에 있는 것입니다.

보안: 모두가 과소평가하는 부분

보안 모델은 A2A와 MCP가 모두 심각해지는 곳입니다.

MCP는 에이전트에게 도구와 데이터에 대한 접근 권한을 제공합니다. 이는 AI 시스템이 파일을 읽고, 데이터베이스를 쿼리하고, API를 호출하고, 메시지를 보내고, 티켓을 업데이트하거나, 인프라 작업을 트리거할 수 있음을 의미합니다.

A2A는 에이전트에게 다른 에이전트에게 작업을 위임할 수 있게 합니다. 이는 하나의 에이전트가 컨텍스트를 전달하고, 작업을 요청하며, 다른 에이전트로부터 아티팩트를 받을 수 있음을 의미합니다.

둘 다 강력합니다. 둘 다 위험할 수 있습니다.

주요 보안 질문은 다릅니다.

MCP의 경우:

  • 이 에이전트는 어떤 도구를 사용할 수 있는가?
  • 어떤 데이터를 읽을 수 있는가?
  • 어떤 작업을 수행할 수 있는가?
  • 사용자가 작업을 승인하는가?
  • 도구 메타데이터가 모델을 조작할 수 있는가?
  • 로컬 및 원격 서버가 신뢰할 수 있는가?

A2A의 경우:

  • 어떤 에이전트들이 서로 통신할 수 있는가?
  • 각 에이전트의 정체성은 무엇인가?
  • 에이전트 A가 에이전트 B에게 권한을 위임할 수 있는가?
  • 얼마나 많은 컨텍스트를 공유할 수 있는가?
  • 최종 결과에 대해 누가 책임 있는가?
  • 작업 사슬을 감사할 수 있는가?

이것이 “모든 것을 그냥 연결하는” 것이 나쁜 전략인 이유입니다. 추가하는 프로토콜이越多수록, 시스템을 안전하고 감사 가능하게 유지하기 위해 정책, 정체성, 로깅, 승인 흐름 및 최소 권한 권한이 더 필요합니다.

좋은 프로덕션 아키텍처에는 다음이 포함되어야 합니다.

  • 에이전트 정체성
  • 도구 정체성
  • 사용자 정체성
  • 범위 지정된 권한
  • 위험한 작업에 대한 승인 게이트
  • 작업 수준의 감사 로그
  • 도구 호출 로그
  • 위임 로그
  • 아티팩트 출처
  • 속도 제한
  • 타임아웃 정책
  • 이그레스 제어

A2A와 MCP를 모두 사용하여 구축 중이라면, 보안은 나중에 붙이는 것이 아닙니다. 보안은 아키텍처의 일부입니다.

관찰성: 로그가 아닌 트레이스가 필요합니다

다중 에이전트 시스템은 디버깅이 어렵습니다.

사용자가 한 가지 질문을 합니다. 오케스트레이터가 두 에이전트를 호출합니다. 한 에이전트가 세 도구를 호출합니다. 다른 에이전트가 부분적인 진행 상황을 스트리밍합니다. 세 번째 에이전트가 실패하고 재시도합니다. 최종 답변이 합리적으로 보이지만, 어떤 데이터 소스가 이를 영향을 미쳤는지 아무도 모릅니다.

이는 프로덕션에서 용납될 수 없습니다.

MCP 중심 시스템의 경우, 다음을 관찰해야 합니다.

  • 도구 선택
  • 도구 인자
  • 도구 결과
  • 도구 대기 시간
  • 도구 오류
  • 사용자 승인
  • 모델에 주입된 컨텍스트

A2A 중심 시스템의 경우, 다음을 관찰해야 합니다.

  • 에이전트 발견
  • 작업 생성
  • 작업 상태 변경
  • 에이전트 간 메시지
  • 생성된 아티팩트
  • 위임 사슬
  • 실패 및 재시도
  • 최종 답변의 출처

시스템이 더 에이전트식으로 될수록 추적 가능성이 더 중요해집니다. 작업이 여러 에이전트, 도구 호출 및 아티팩트 인도를 넘나들 때 평범한 애플리케이션 로그만으로는 충분하지 않습니다. 어떤 답변도 그 기원으로 추적될 수 있도록 전체 실행 경로를 따르는 작업 트레이스가 필요합니다. LLM 시스템 관찰성: 메트릭, 트레이스, 로그 및 프로덕션 테스트는 이에 대한 툴링 및 계측 측면을 깊이 있게 다룹니다.

결정 프레임워크: A2A, MCP, 둘 다, 아니면 어느 것도 필요 없는가?

다음 결정 프레임워크를 사용하세요.

간단한 코드로 충분할 때 어느 것도 사용 안 함

다음과 같은 경우 일반적인 함수, API 또는 큐를 선택하세요.

  • 모든 구성 요소를 제어할 때
  • LLM 네이티브 도구 발견이 필요하지 않을 때
  • 에이전트 상호 운용성이 필요하지 않을 때
  • 시스템이 결정론적일 때
  • 통합이 안정적이고 간단할 때

모든 통합이 AI 프로토콜을 필요로 하는 것은 아닙니다.

에이전트가 도구가 필요할 때 MCP 사용

다음과 같은 경우 MCP를 선택하세요.

  • AI 앱이 외부 데이터가 필요할 때
  • 에이전트가 도구를 호출해야 할 때
  • 재사용 가능한 통합을 원할 때
  • 도구 발견을 원할 때
  • 표준 클라이언트-서버 통합을 원할 때
  • 코딩 에이전트, 어시스턴트, IDE 또는 내부 도구를 구축 중일 때

이는 대부분의 빌더에게 기본 시작점입니다.

에이전트가 피어가 필요할 때 A2A 사용

다음과 같은 경우 A2A를 선택하세요.

  • 에이전트가 독립적으로 배포될 때
  • 에이전트가 서로를 발견해야 할 때
  • 에이전트가 다른 팀이나 벤더에 의해 구축될 때
  • 작업이 장기 실행될 때
  • 위임이 중요할 때
  • 아티팩트가 중요할 때
  • 도구 경계가 아닌 에이전트 경계가 필요할 때

이는 아키텍처의 단위가 에이전트일 때 올바른 선택입니다.

전문 에이전트가 도구가 필요할 때 둘 다 사용

다음과 같은 경우 둘 다 선택하세요.

  • 에이전트들이 서로 협력할 때
  • 각 에이전트도 도구에 접근해야 할 때
  • 위임과 실행 사이에 깔끔한 경계를 원할 때
  • 사설 내부 도구체인을 가진 전문 에이전트를 원할 때
  • 확장 가능한 다중 에이전트 아키텍처를 원할 때

이는 가장 현실적인 기업 패턴입니다.

일반적인 반패턴(Anti-Patterns)

반패턴 1: 모든 도구를 에이전트로 변환

모든 함수가 에이전트 래핑을 필요로 하는 것은 아닙니다.

환율 변환 API는 아마도 도구일 것입니다. 데이터베이스 쿼리는 아마도 도구일 것입니다. 파일 리더는 아마도 도구일 것입니다.

작은 기능마다 A2A 에이전트로 래핑하면 불필요한 복잡성이 생깁니다.

반패attern 2: 하나의 MCP 도구 뒤에 전체 에이전트를 숨기기

반대 실수도 흔합니다.

MCP 도구가 은밀하게 장기 실행, 상태 유지, 다중 에이전트 워크플로우를 실행한다면, MCP 추상화가 너무 얇아질 수 있습니다. 작업 상태, 위임, 아티팩트 및 책임에 대한 가시성을 잃게 됩니다.

이 시점에서 A2A 경계가 필요할 수 있습니다.

반패attern 3: 모든 에이전트가 모든 도구를 호출하도록 허용

이는 권한 혼란을 만듭니다.

전문 에이전트는 범위 지정된 도구를 가져야 합니다. 작성 에이전트는 프로덕션 데이터베이스 접근이 필요하지 않을 것입니다. 연구 에이전트는 인프라 배포 권한이 필요하지 않을 것입니다.

최소 권한을 사용하세요.

반패attern 4: 위험한 작업에 대한 인간 승인 없음

에이전트 시스템은 고영향 작업을 침묵하게 수행해서는 안 됩니다.

다음과 같은 작업에는 인간 승인이 필요합니다.

  • 외부 이메일 발송
  • 프로덕션 데이터 수정
  • 인프라 배포
  • 파일 삭제
  • 권한 변경
  • 서비스 구매
  • 민감한 데이터 공유

프로토콜은 통합을 쉽게 만듭니다. 그러나 책임은 제거하지 않습니다.

실용적인 예시

예시 1: 로컬 코딩 어시스턴트

로컬 코딩 어시스턴트는 다음에 접근하기 위해 MCP를 사용합니다.

  • 파일시스템
  • Git 저장소
  • 테스트 러너
  • 패키지 관리자
  • 문서 검색

이는 아마도 A2A가 필요하지 않을 것입니다.

MCP만으로도 충분합니다.

예시 2: 기업용 지원 어시스턴트

지원 어시스턴트는 다음에 접근하기 위해 MCP를 사용합니다.

  • CRM
  • 티켓팅 시스템
  • 문서
  • Slack
  • 고객 데이터베이스

처음에는 MCP만으로도 충분합니다.

나중에 회사는 전문 에이전트를 추가합니다.

  • 청구 에이전트
  • 법적 정책 에이전트
  • 제품 문제 해결 에이전트
  • 에스컬레이션 에이전트

이제 지원 어시스턴트가 다른 에이전트에게 작업을 위임해야 하므로 A2A가 합리적으로 보입니다.

둘 다 사용하세요.

예시 3: 에이전트 마켓플레이스

플랫폼은 제3자 에이전트가 기능을 광고하고 다른 에이전트로부터 작업을 받도록 합니다.

플랫폼은 각 에이전트의 내부 구현을 알지 못합니다.

A2A가 강력한 적합성을 가집니다.

개별 에이전트들은 내부적으로 여전히 MCP를 사용할 수 있지만, 공개 경계는 A2A입니다.

예시 4: 데이터 분석 에이전트

데이터 분석 에이전트는 웨어하우스를 쿼리하고, 대시보드를 읽고, 차트를 생성하며, 보고서를 작성합니다.

도구를 사용하는 단일 에이전트라면 MCP만으로도 충분합니다.

통계적 검토를 한 에이전트에게, 비즈니스 설명을 다른 에이전트에게, 규정 준수 검토를 또 다른 에이전트에게 위임한다면, A2A가 유용해집니다.

저의 주관적인 의견

MCP는 대부분의 빌더에게 실용적인 기본값이며, A2A는 실제 에이전트-투-에이전트 조정 필요성이 생길 때 더 큰 시스템이 성장하는 아키텍처적 경계입니다.

유용한 첫 번째 AI 에이전트를 구축 중이라면 MCP로 시작하세요. AI 시스템 클러스터는 자체 호스팅 어시스턴트, MCP 서버 및 에이전트 메모리를 연결된 집합으로 다루며, 이러한 조각들이 실제로 어떻게 맞춰지는지에 대한 더 넓은 그림을 제공합니다. 에이전트에게 안전하고 잘 범위 지정된 도구 및 데이터 접근 권한을 부여하세요. 도구 설명이 깨지는 곳을 배우세요. 권한이 복잡해지는 곳을 배우세요. 관찰성이 약한 곳을 배우세요.

다중 에이전트 판타지 아키텍처로 시작하지 마세요.

하지만 시스템에 여러 독립적으로 소유된 에이전트가 있다면, A2A는 훨씬 더 흥미로워집니다. 이는 에이전트 기능, 작업 위임 및 에이전트 간 협력을 표현하는 더 깔끔한 방법을 제공합니다.

실수는 A2A와 MCP를 경쟁자로 취급하는 것입니다.

이들은 서로 다른 레이어로 더 잘 이해됩니다.

  • MCP는 에이전트를 기능에 연결합니다.
  • A2A는 에이전트를 다른 에이전트에 연결합니다.

MCP만으로 유용한 시스템을 구축할 수 있습니다.

A2A만으로 에이전트 네트워크를 구축할 수 있습니다.

하지만 가장 확장 가능한 패턴은 아마도 둘 다일 것입니다: 에이전트 협력을 위한 A2A, 도구 통합을 위한 MCP.

최종 결론: AI 에이전트에게 정말 둘 다 필요한가?

때때로 — 하지만 항상은 아니며, 답은 거의 전적으로 시스템에 진정한 에이전트-투-에이전트 경계가 있는지 아니면 도구 사용 함수의 컬렉션만 있는지에 달려 있습니다.

AI 에이전트가 도구만 필요하면 MCP를 사용하세요.

AI 시스템이 독립적으로 배포된 에이전트들이 협력해야 한다면 A2A를 사용하세요.

전문 에이전트들이 도구가 필요하고 다른 에이전트들과도 협력해야 한다면 둘 다 사용하세요.

가장 깔끔한 아키텍처는 “A2A 대 MCP"가 아닙니다. 에이전트 경계에서의 A2A와 도구 경계에서의 MCP이며, 각 프로토콜이 설계된 문제를 정확하게 처리합니다. 이러한 관심사 분리가 다중 에이전트 시스템을 이해하기 쉽고, 안전하며, 시간이 지남에 따라 진화하기 쉽게 유지합니다.

2026년에서 A2A의 위치(적용 단계, 보안 요구사항, 기업 사용 사례 및 도입 시기 결정 프레임워크)에 대한 더 넓은 분석은 2026년 Google A2A 프로토콜: 적용, 과열 및 현실을 참조하세요.

출처

구독하기

시스템, 인프라, AI 엔지니어링에 관한 새 글을 받아보세요.