에이전트 여러 개를 연결하려는 개발자 질문에는 자주 같은 선택지가 등장한다. 간단한 API를 만들면 되는지, MCP 서버로 감싸야 하는지, A2A를 붙여야 하는지 헷갈린다는 질문이다. 이름만 보면 둘 다 AI가 다른 무언가와 대화하는 규격처럼 보인다.

가장 짧게 나누면 이렇다. MCP는 에이전트가 기능을 쓰는 연결이고, A2A는 에이전트가 다른 에이전트와 일을 나누는 연결이다. 둘은 같은 자리를 두고 경쟁하기보다 한 시스템의 서로 다른 층에서 함께 쓰인다.

고객 지원 에이전트가 A2A로 결제 에이전트에게 일을 맡기고 결제 에이전트가 MCP로 주문 조회와 환불 처리 도구를 쓰는 구조.

그림에서 에이전트 사이의 위임은 A2A가 맡고, 결제 에이전트와 두 도구 사이의 연결은 MCP가 맡는다. 한 요청 안에서 두 규격의 역할이 겹치지 않는다.

연결 상대가 다르다

MCP 공식 소개는 MCP를 AI 애플리케이션과 외부 시스템을 연결하는 공개 표준으로 설명한다. 외부 시스템은 파일, 데이터베이스 같은 자료와 검색, 계산, 일정 생성 같은 도구를 아우른다. MCP 서버는 이 기능을 일정한 형식으로 내보내고, AI 애플리케이션은 필요한 기능을 골라 쓴다.

A2A 공식 문서는 A2A를 서로 다른 개발자와 조직이 만든 독립 에이전트의 통신 규격으로 설명한다. 상대 에이전트는 단순한 함수 목록이 아니다. 맡은 일을 해석하고, 계획하고, 필요한 정보를 다시 물으며, 진행 상태와 결과물을 돌려주는 작업자다.

그래서 첫 질문은 “어느 규격이 더 좋은가?”가 아니다.

지금 연결하려는 상대는 정해진 기능인가, 아니면 판단하고 일을 이어가는 독립 에이전트인가?

이 질문에 답하면 두 규격의 자리가 훨씬 선명해진다.

MCP는 자료와 도구를 꺼내 쓰게 한다

최신 MCP 2026-07-28 규격은 서버가 내보내는 기본 기능을 세 가지로 나눈다.

  • Resources: 파일 내용이나 데이터처럼 AI가 참고할 자료
  • Tools: 검색, 계산, 쓰기처럼 실행할 기능
  • Prompts: 사용자가 고르는 미리 만든 지시문이나 작업 흐름

예를 들어 고객 지원 에이전트가 주문 데이터베이스를 조회한다고 해보자. MCP 서버는 주문 번호로 조회 같은 도구를 설명하고 입력과 출력 형식을 정한다. 에이전트는 그 도구를 호출해 결과를 받은 뒤 다음 판단을 이어간다. 도구 자체가 고객과 대화하거나 환불 조건을 협상할 필요는 없다.

MCP 아키텍처 문서에서 전체 대화와 여러 서버의 연결을 조정하는 쪽은 host다. 각 MCP 서버는 필요한 자료와 기능에 집중하고, 다른 서버의 내부 상태나 전체 대화를 저절로 보지 않는다. 이 경계 덕분에 하나의 AI 애플리케이션이 여러 기능을 조합해도 연결 책임을 한곳에서 관리하기 쉽다.

다만 “MCP는 한 번 호출하고 끝나는 짧은 함수만 다룬다”라고 외우면 최신 규격과 맞지 않는다. 2026-07-28 규격에는 오래 걸리는 실행을 추적하는 Tasks 확장이 들어갔다. MCP도 진행 중인 작업을 다룬다. 길이보다 누가 작업의 주도권을 갖고 어떤 계약으로 연결되는지가 더 중요한 구분이다.

A2A는 에이전트에게 일을 맡기게 한다

A2A에서 상대는 독립된 원격 에이전트다. 호출하는 쪽은 그 에이전트의 내부 모델, 메모리, 도구를 알지 않아도 된다. 대신 공개된 능력과 통신 방법을 보고 일을 맡긴다.

A2A 핵심 개념 문서에는 이 협업을 위한 네 가지 요소가 나온다.

  • Agent Card: 에이전트의 주소, 능력, 지원 형식, 인증 방법을 담은 소개서
  • Message: 요청, 질문, 답변을 주고받는 한 차례의 대화
  • Task: 고유 번호와 진행 상태가 있는 작업 단위
  • Artifact: 문서, 이미지, 구조화된 자료처럼 작업이 만든 결과물

예를 들어 여행 계획 에이전트가 항공권 담당 에이전트에게 “다음 주 서울에서 헬싱키로 가는 조건을 찾아 달라”고 맡긴다고 해보자. 항공권 에이전트는 날짜나 수하물 조건을 다시 묻는다. 검색이 오래 걸리면 진행 상태를 보내고, 마지막에는 예약 후보를 결과물로 돌려준다. 호출한 쪽은 항공권 에이전트가 내부에서 어느 모델과 도구를 썼는지 몰라도 된다.

A2A 작업 수명 문서는 즉시 끝나는 응답과 상태를 추적하는 작업을 따로 다룬다. 입력이 더 필요하면 input-required, 인증이 필요하면 auth-required 상태로 알린다. 이 구조는 정해진 함수 한 번보다 협상과 보완 질문이 필요한 일을 맡길 때 유용하다.

한 요청에서 둘을 함께 쓴다

A2A 공식 비교 문서는 두 규격을 보완 관계로 설명한다. 고객 지원 상황을 단순하게 그리면 다음과 같다.

고객 지원 에이전트
  └─ A2A → 결제 담당 에이전트
                ├─ MCP → 주문 조회 도구
                └─ MCP → 환불 처리 도구

고객 지원 에이전트는 결제 문제 전체를 결제 담당 에이전트에게 맡긴다. 두 에이전트 사이에서는 추가 질문, 진행 상태, 최종 결과가 오가므로 A2A가 맞는다. 결제 담당 에이전트가 주문 한 건을 조회하거나 승인된 환불 기능을 실행할 때는 MCP 도구를 쓴다.

역할은 이렇게 나뉜다.

  • A2A는 누가 이 일을 맡아 협업할지를 연결한다.
  • MCP는 그 일을 하려면 어떤 자료와 기능을 쓸지를 연결한다.

이 구조라면 결제 담당 에이전트의 내부 도구가 바뀌어도 고객 지원 에이전트와의 협업 계약은 유지하기 쉽다. 반대로 주문 조회 도구를 여러 에이전트가 써도 같은 MCP 연결을 다시 활용하기 좋다.

에이전트를 도구로 감싸도 되는 때가 있다

모든 에이전트 연결에 A2A가 필요한 것은 아니다. 상대가 내부에서 모델을 쓰더라도, 호출하는 쪽에서 보면 입력 하나를 받고 정해진 결과 하나를 돌려주는 기능이다. 예를 들어 “이 문장을 세 줄로 요약”처럼 범위가 좁고 추가 질문이나 진행 상태가 필요 없다면 MCP 도구로 내보내도 충분하다.

반대로 다음 조건이 늘어나면 A2A를 검토할 이유가 생긴다.

  • 상대가 별도로 배포되고 다른 팀이나 조직이 운영한다.
  • 상대의 능력과 인증 방법을 먼저 발견해야 한다.
  • 일을 맡긴 뒤 보완 질문과 여러 차례의 대화가 이어진다.
  • 오래 걸리는 작업의 상태와 결과물을 독립적으로 추적해야 한다.
  • 상대의 내부 도구와 메모리를 공개하지 않은 채 협업해야 한다.

한 애플리케이션 안에서 직접 만든 두 모듈을 연결하는 정도라면 둘 다 과하다. 일반 함수 호출이나 현재 쓰는 에이전트 프레임워크의 내부 위임 기능이 더 단순하다. 서로 독립된 시스템 사이에 공통 계약이 필요해질 때 규격의 이점이 커진다.

선택 전에 다섯 가지만 묻는다

구현 이름부터 고르지 말고 연결 계약을 먼저 적어보자.

  1. 상대가 스스로 다음 단계를 판단하는가? 호출한 쪽이 모든 순서를 정하면 MCP 도구를 고른다. 상대가 계획하고 일을 나누면 A2A를 검토한다.
  2. 추가 질문이 오가는가? 입력과 출력이 고정되어 있으면 MCP가 단순하다. 요청 범위를 협상해야 하면 A2A의 메시지와 작업 상태가 잘 맞는다.
  3. 상대가 독립적으로 운영되는가? 같은 코드 안의 모듈이라면 직접 연결부터 본다. 조직과 배포 경계가 다르면 A2A의 Agent Card와 표준 통신이 도움이 된다.
  4. 무엇을 결과로 받아야 하는가? 함수 결과 하나면 MCP 도구로 충분하다. 진행 상태, 여러 메시지, 파일과 결과물을 함께 추적한다면 A2A Task와 Artifact를 살펴본다.
  5. 어디에서 권한을 확인할 것인가? MCP 호스트는 도구와 자료 접근을 통제해야 한다. A2A 클라이언트는 Agent Card의 인증 요구를 읽고 원격 에이전트의 신원과 권한 범위를 확인해야 한다.

마지막 질문은 어느 쪽에서도 빠지지 않는다. 연결 규격이 생겼다고 안전이 자동으로 따라오지는 않는다. MCP 보안 안내는 사용자 동의, 토큰 검증, 권한 범위를 별도 구현 책임으로 둔다. A2A 기업 환경 안내도 운영 환경의 HTTPS와 표준 인증 방식을 요구한다.

경쟁 규격이 아니라 층이 다른 규격이다

A2A와 MCP를 고를 때 MCP 대 A2A라는 제품 비교표부터 만들 필요는 없다. 연결 상대와 책임을 먼저 보면 된다.

  • AI 애플리케이션에 자료와 도구를 붙인다: MCP
  • 독립 에이전트끼리 일을 맡기고 결과를 주고받는다: A2A
  • 원격 에이전트가 내부 도구를 써서 일을 처리한다: A2A와 MCP를 함께 사용
  • 같은 프로그램 안의 단순한 두 모듈을 잇는다: 직접 호출부터 검토

핵심은 프로토콜 이름이 아니라 경계다. 기능을 호출하는 계약인지, 독립된 작업자에게 일을 맡기는 계약인지 먼저 정하면 A2A와 MCP의 자리가 겹치지 않는다.

이 글의 규격 동작과 제한은 2026년 8월 17일 공식 문서와 원 자료를 기준으로 확인했다.

확인한 공식·원 자료