먼저 경계를 나누기
A2A와 MCP를 함께 쓸 때 가장 먼저 해야 할 일은 역할을 섞지 않는 것이다. 둘 다 "연결"을 다루지만, 연결하는 대상이 다르다.
MCP(Model Context Protocol)는 에이전트가 도구와 리소스를 쓰는 방법을 표준화한다. 여기서 도구와 리소스란 데이터베이스, 파일 시스템, 사내 API, SaaS API, 검색 도구, 결제 조회 API처럼 비교적 명확한 입력과 출력을 가진 기능을 말한다. 쉽게 말해 MCP는 에이전트가 작업대 위의 공구를 안전하게 꺼내 쓰는 규칙이다.
A2A(Agent2Agent)는 에이전트가 다른 에이전트와 협업하는 방법을 표준화한다. 상대는 단순한 함수가 아니다. 자신의 판단 과정, 도구, 메모리, 정책을 내부에 숨긴 채 하나의 업무를 맡아 처리하는 협업 주체다. 쉽게 말해 A2A는 프로젝트 매니저가 다른 전문가에게 일을 맡기고, 진행 상황과 결과물을 주고받는 규칙이다.
공식 설명에서도 MCP는 에이전트와 도구·리소스 사이의 통신, A2A는 독립적인 에이전트들 사이의 협업 통신으로 구분한다1. 이 구분이 분명해야 아키텍처가 단순해진다. 데이터베이스 조회를 위해 A2A 에이전트를 만들 필요는 없다. 반대로 여러 단계의 판단, 추가 질문, 중간 산출물, 책임 있는 결과 반환이 필요한 업무를 MCP 도구 하나로 억지로 표현할 필요도 없다.
AI 생성 이미지
MCP 서버는 에이전트의 도구 창고다
MCP 서버는 도구와 리소스를 에이전트에게 노출하는 구성 요소다. 예를 들어 다음과 같은 MCP 서버를 생각해 볼 수 있다.
고객 데이터베이스에서 주문 이력을 조회하는 MCP 서버
사내 문서 저장소에서 정책 문서를 검색하는 MCP 서버
Git 저장소와 이슈 트래커에 접근하는 MCP 서버
CRM, ERP, Slack, Jira 같은 SaaS API를 감싸는 MCP 서버
파일 시스템에서 보고서 템플릿을 읽고 결과 파일을 저장하는 MCP 서버
에이전트는 이 서버들을 통해 외부 세계에 접근한다. 중요한 점은 MCP 서버가 보통 "업무 전체"를 맡지는 않는다는 것이다. MCP 도구는 대체로 구조화된 입력을 받고 구조화된 결과를 돌려준다. 예를 들어 customer_id를 입력하면 주문 목록을 돌려주거나, query를 입력하면 검색 결과를 돌려주는 식이다.
따라서 MCP 서버는 에이전트의 판단을 대체하지 않는다. 에이전트가 "무엇을 조회해야 하는지", "조회 결과를 어떻게 해석해야 하는지", "다음에 어떤 행동을 해야 하는지"를 결정하고, MCP는 그 결정에 필요한 도구 접근 경로를 제공한다.
이 구조는 운영에도 유리하다. 데이터베이스 접속 정보, SaaS 토큰, 파일 접근 권한을 에이전트 코드 곳곳에 흩뿌리지 않고 MCP 서버 뒤에 모을 수 있다. 도구별 권한, 사용량 제한, 감사 로그, 스키마 변경 대응도 MCP 계층에서 관리할 수 있다.
A2A는 MCP를 쓰는 에이전트들의 협업 채널이다
이제 더 큰 그림을 보자. 한 조직에 여러 전문 에이전트가 있다고 하자.
리서치 에이전트: 웹 검색 MCP 서버와 문서 검색 MCP 서버를 사용한다.
재무 분석 에이전트: 회계 데이터베이스 MCP 서버와 스프레드시트 MCP 서버를 사용한다.
고객 지원 에이전트: CRM MCP 서버와 티켓 시스템 MCP 서버를 사용한다.
보고서 작성 에이전트: 파일 저장소 MCP 서버와 문서 생성 도구를 사용한다.
각 에이전트는 내부적으로 MCP 도구를 쓴다. 하지만 이 에이전트들이 서로 협업할 때는 A2A를 쓴다. 예를 들어 오케스트레이터가 "지난 분기 주요 고객 이탈 원인을 분석해 보고서로 정리해 줘"라는 요청을 받았다고 하자. 오케스트레이터는 먼저 고객 지원 에이전트에게 이탈 고객의 문의 패턴을 요청한다. 이어서 재무 분석 에이전트에게 매출 변화와 계약 규모를 분석하게 한다. 마지막으로 보고서 작성 에이전트에게 두 결과를 합쳐 경영진용 요약본을 만들게 한다.
이때 오케스트레이터가 각 에이전트의 내부 MCP 도구를 직접 호출하지 않는 것이 핵심이다. 오케스트레이터는 고객 지원 에이전트가 어떤 CRM 쿼리를 실행하는지 알 필요가 없다. 재무 분석 에이전트가 어떤 테이블을 조인하는지도 몰라도 된다. A2A를 통해 업무를 맡기고, 상태를 확인하고, 필요한 추가 입력을 제공하고, 최종 Artifact를 받으면 된다.
이렇게 하면 책임 경계가 선명해진다.
MCP 경계: 에이전트가 도구와 데이터를 안전하게 사용하는 경계
A2A 경계: 에이전트가 다른 에이전트에게 업무를 위임하고 결과를 받는 경계
엔터프라이즈 참조 아키텍처에서도 이 분리는 중요하게 다뤄진다. A2A는 외부 또는 타 시스템 에이전트와의 위임·협업 경계로, MCP는 API와 데이터 소스를 거버넌스 아래 도구로 노출하는 경계로 설명된다2.
내부는 MCP, 외부는 A2A인 에이전트
실전에서 가장 자주 쓰는 패턴은 "내부는 MCP, 외부는 A2A"이다.
예를 들어 MarketResearchAgent라는 에이전트를 만든다고 하자. 이 에이전트는 외부에는 A2A 서버로 노출된다. Agent Card에는 다음과 같은 능력이 적혀 있다.
시장 동향 조사
경쟁사 비교
웹 자료 기반 요약
출처 목록이 포함된 리서치 메모 생성
클라이언트 에이전트는 이 Agent Card를 읽고 "시장 조사 업무는 이 에이전트에게 맡길 수 있겠다"고 판단한다. 그리고 A2A의 message/send나 스트리밍 호출로 태스크를 보낸다.
하지만 MarketResearchAgent 내부에서는 다른 일이 일어난다. 에이전트는 사용자의 요청을 해석한 뒤 MCP 서버를 호출한다. 검색 MCP 서버로 관련 문서를 찾고, 웹 페이지 추출 MCP 도구로 본문을 가져오고, 사내 지식베이스 MCP 서버로 내부 자료를 조회한다. 그 결과를 종합해 A2A의 Message나 Artifact로 반환한다.
구조를 글로 그리면 다음과 같다.
Client Agent / Orchestrator
|
| A2A: 태스크 요청, 상태 확인, 결과 수신
v
MarketResearchAgent as A2A Server
|
| MCP: 검색, 문서 조회, 파일 접근
v
MCP Servers
|
v
Databases / Files / SaaS APIs / Web Tools이 패턴의 장점은 외부 계약과 내부 구현을 분리한다는 데 있다. 외부 클라이언트는 MarketResearchAgent가 어떤 검색 API를 쓰는지, 어떤 MCP 서버와 연결되어 있는지 알 필요가 없다. 반대로 에이전트 개발팀은 내부 도구를 교체해도 A2A 계약을 유지할 수 있다. 검색 API를 바꾸거나, 데이터베이스 스키마를 조정하거나, MCP 서버를 새 버전으로 교체해도 Agent Card의 능력과 A2A 응답 형식이 유지되면 클라이언트 영향은 줄어든다.
실습 생태계에서는 ADK 에이전트가 MCP 도구를 내부 도구 집합으로 연결하고, 바깥쪽에서는 A2A를 통해 다른 에이전트와 조율하는 예시가 자주 등장한다3. 특정 프레임워크를 반드시 써야 한다는 뜻은 아니다. 핵심은 "도구 사용은 안쪽에서, 협업 계약은 바깥쪽에서"라는 구조다.
도구 실패와 협업 실패를 분리해 보기
A2A와 MCP를 함께 쓰면 실패도 두 층으로 나누어 관찰해야 한다.
첫째, 도구 호출 실패가 있다. MCP 서버가 응답하지 않거나, 데이터베이스 권한이 없거나, SaaS API 사용량 제한에 걸리거나, 파일이 존재하지 않는 경우다. 이 실패는 에이전트 내부에서 발생한다. 원인은 도구, 네트워크, 인증, 데이터 품질에 있을 수 있다.
둘째, 에이전트 협업 실패가 있다. A2A 태스크가 실패하거나, 원격 에이전트가 input-required 상태에서 멈추거나, 기대한 Artifact를 반환하지 않거나, 오케스트레이터가 여러 에이전트의 결과를 병합하지 못하는 경우다. 이 실패는 협업 흐름에서 발생한다. 원인은 작업 분해, 라우팅, 정책, 응답 형식, 상태 관리에 있을 수 있다.
두 실패를 섞어 기록하면 복구가 어려워진다. 예를 들어 최종 태스크가 실패했을 때 "에이전트 실패"라고만 남기면 부족하다. 실제 원인은 CRM MCP 서버의 인증 만료일 수도 있고, 재무 분석 에이전트가 추가 입력을 요구했는데 오케스트레이터가 놓친 것일 수도 있다.
따라서 관측성 설계는 다음처럼 나누는 것이 좋다.
A2A 태스크 ID와 MCP 호출 ID를 연결해 추적한다.
A2A 상태 전환과 MCP 도구 호출 로그를 별도 이벤트로 남긴다.
사용자에게 보여 줄 오류와 운영자가 볼 진단 정보를 구분한다.
MCP 오류가 일시적이면 에이전트 내부에서 재시도한다.
A2A 협업 오류가 발생하면 오케스트레이터가 다른 에이전트로 우회하거나 사용자에게 추가 입력을 요청한다.
예를 들어 검색 MCP 서버가 일시적으로 실패했다면 MarketResearchAgent는 다른 검색 도구를 시도하거나 잠시 후 재시도할 수 있다. 이때 A2A 태스크는 바로 실패로 끝낼 필요가 없다. working 상태를 유지하거나, 제한된 근거로 초안을 만들 수 있음을 중간 메시지로 알릴 수 있다.
반대로 원격 에이전트가 필요한 조건을 명확히 묻지 않고 모호한 결과를 반환했다면 이는 MCP 문제가 아니라 A2A 협업 품질 문제다. 오케스트레이터는 후속 메시지로 명확한 기준을 다시 제시하거나, 다른 전문 에이전트에게 재검토를 맡겨야 한다.
깨끗한 결합을 위한 설계 원칙
MCP와 A2A를 함께 쓸 때는 다음 원칙을 지키면 구조가 단단해진다.
첫째, 도구를 에이전트처럼 포장하지 않는다. 단순 조회, 변환, 계산, 저장 기능은 MCP 도구로 두는 편이 낫다. 모든 API를 A2A 에이전트로 만들면 태스크 상태, 메시지, Artifact 같은 협업 모델이 불필요하게 무거워진다.
둘째, 에이전트를 도구처럼 호출하지 않는다. 전문 판단, 장기 작업, 중간 질문, 결과 책임이 필요한 대상은 A2A 에이전트로 다루어야 한다. 이런 대상을 단순 함수처럼 호출하면 실패 복구와 상태 관리가 어려워진다.
셋째, 외부 계약은 A2A로 안정화하고 내부 도구는 MCP로 교체 가능하게 만든다. 좋은 A2A 에이전트는 내부 도구 목록을 모두 노출하지 않는다. 대신 "무슨 업무를 맡을 수 있는지", "어떤 입력과 출력을 지원하는지", "어떤 보안 조건이 필요한지"를 Agent Card와 태스크 응답으로 설명한다.
넷째, 보안 경계를 이중으로 본다. A2A에서는 어떤 클라이언트 에이전트가 어떤 업무를 맡길 수 있는지 통제한다. MCP에서는 해당 에이전트가 어떤 데이터와 도구에 접근할 수 있는지 통제한다. A2A 인증을 통과했다고 해서 모든 MCP 도구 접근을 허용해서는 안 된다.
다섯째, 최종 책임자는 오케스트레이터다. 여러 에이전트가 MCP 도구를 사용해 각자 결과를 만들더라도, 사용자 목표에 맞게 결과를 검토하고 병합하고 설명하는 책임은 클라이언트 에이전트 또는 오케스트레이터에게 남는다.
정리하면 MCP는 에이전트의 손과 발을 외부 도구에 연결한다. A2A는 에이전트들이 서로 일을 맡기고 결과를 조율하는 대화 채널을 만든다. 둘을 구분하면 멀티 에이전트 시스템은 더 작고 명확한 부품으로 나뉜다. 도구는 도구답게, 에이전트는 에이전트답게 설계할 수 있다.
참고
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.