[AI Frontier] AI 에이전트끼리 대화하기 시작했다, A2A와 MCP가 바꾸는 기업 AI 구조

[AI Frontier]

AI가 데이터와 도구를 사용하는 방법에 MCP가 있다면, 서로 다른 AI 에이전트가 일을 나누는 방법에는 A2A가 있다. 두 기술을 함께 보면 기업 AI가 '한 개의 똑똑한 챗봇'에서 '여러 디지털 작업자가 연결된 시스템'으로 이동하는 구조가 보인다.

회사에 매우 유능한 신입사원이 들어왔다고 생각해보자. 질문을 이해하고 문서를 잘 쓰지만 회사 파일을 읽지 못하고, 고객 데이터도 볼 수 없으며, 일정 등록이나 주문 처리도 할 수 없다. 지식은 많지만 실제 업무 시스템과 연결되지 않은 상태다.

첫 번째 문제는 이 직원에게 필요한 자료와 도구를 연결하는 것이다. 모델 컨텍스트 프로토콜(Model Context Protocol, MCP)이 주로 이 문제를 다룬다. 그런데 직원이 한 명이 아니라 구매 담당, 법무 담당, 재무 담당, 고객지원 담당처럼 여러 명이라면 다른 문제가 생긴다. 서로 어떤 일을 할 수 있는지 알고, 업무를 요청하고, 진행 상태와 결과를 주고받아야 한다. 에이전트투에이전트 프로토콜(Agent2Agent Protocol, A2A)은 이 두 번째 문제를 겨냥한다.

그래서 MCP와 A2A를 경쟁 기술로 보면 이해가 어려워진다. 하나는 AI와 도구 사이를, 다른 하나는 AI 에이전트와 AI 에이전트 사이를 연결하는 데 초점이 있다. 실제 기업 시스템에서는 둘이 함께 사용될 가능성이 더 자연스럽다.

먼저 한 문장으로

MCP는 AI에게 손과 눈을 연결하고, A2A는 여러 AI가 서로 일을 나눌 수 있게 한다. 정확한 기술 정의는 이보다 복잡하지만 처음 개념을 잡을 때는 이 차이를 기억하면 된다.

AI 에이전트는 챗봇과 무엇이 다른가

가장 먼저 '에이전트'라는 말부터 정리할 필요가 있다. 인공지능 에이전트(Artificial Intelligence Agent, AI Agent)는 질문에 답하는 것에서 멈추지 않고, 목표를 받아 필요한 정보를 찾고 도구를 선택해 여러 단계를 수행하는 소프트웨어를 뜻한다.

예를 들어 “다음 주 부산 출장 일정을 정리해줘”라는 요청을 생각해보자. 일반적인 챗봇이라면 일정표 예시를 작성하는 데 그칠 수 있다. 에이전트는 달력에서 가능한 시간을 확인하고, 회사 출장 규정을 읽고, 교통편을 찾은 뒤 예약 승인을 요청하는 식으로 다음 행동까지 이어질 수 있다.

여기에서 중요한 차이가 생긴다. 대규모 언어 모델(Large Language Model, LLM)의 지능만으로는 실제 회사 업무가 끝나지 않는다. 달력, 데이터베이스, 사내 문서, 결제 시스템처럼 현실의 도구와 연결되어야 한다.

MCP란 무엇인가: AI에게 도구 상자를 연결하는 규칙

MCP를 가장 쉽게 이해하는 방법은 컴퓨터의 공통 연결 단자를 떠올리는 것이다. 노트북에 키보드, 저장장치, 모니터를 연결할 때 기기마다 완전히 다른 연결 방식을 새로 만들 필요가 없다. 표준 연결 규격이 있기 때문이다.

AI에서도 비슷한 문제가 있었다. 한 AI를 사내 데이터베이스에 연결하고, 다시 검색 시스템에 연결하고, 프로젝트 관리 도구에 연결할 때마다 별도의 통합 방식을 만들면 연결 수가 늘어날수록 관리가 복잡해진다. MCP는 AI 애플리케이션이 외부 데이터와 도구를 일정한 방식으로 발견하고 사용할 수 있도록 공통 연결 규칙을 제공한다.

쉬운 예제 ① · 일정 잡기

사용자: “김 대리와 다음 주 30분 미팅을 잡아줘.”

AI 에이전트: 누구와 언제 만나야 하는지 판단한다.

MCP: 달력 조회 도구와 일정 생성 도구를 에이전트가 사용할 수 있게 연결한다.

결과: 가능한 시간을 찾고, 필요한 승인 후 일정을 등록한다.

여기까지는 AI가 다른 AI와 대화할 필요가 없다. 하나의 에이전트가 필요한 도구를 잘 사용할 수 있으면 된다. 그래서 이런 문제라면 A2A보다 MCP가 먼저다.

MCP의 공식 구조에서는 AI 애플리케이션이 MCP 클라이언트를 통해 하나 이상의 MCP 서버와 연결된다. 서버는 사용할 수 있는 도구와 자원 등을 노출하고, AI는 필요한 기능을 호출한다. 최근 사양은 이런 연결을 일반 웹 인프라에서 더 쉽게 확장할 수 있도록 무상태 구조와 권한 부여 방식을 강화하는 방향으로 발전하고 있다.

A2A란 무엇인가: 도구가 아니라 다른 ‘전문가’에게 일을 맡긴다

문제는 AI가 한 명에서 여러 명으로 늘어날 때 시작된다. 구매 전문 에이전트가 있고, 공급망 위험을 분석하는 에이전트가 있으며, 계약서를 검토하는 법무 에이전트가 따로 있다고 해보자.

구매 에이전트가 공급망 위험을 확인하기 위해 상대 에이전트 내부의 데이터베이스와 도구를 하나씩 직접 조작할 필요는 없다. 사람으로 치면 구매팀 직원이 위험관리팀의 내부 시스템 사용법을 모두 배울 필요가 없는 것과 같다. 대신 “이 공급업체의 위험도를 확인해 달라”고 해당 전문가에게 일을 맡기면 된다.

A2A는 이런 관계를 위한 규칙이다. 서로 다른 회사나 프레임워크에서 만들어진 에이전트도 상대가 어떤 능력을 갖고 있는지 발견하고, 요청을 보내고, 긴 작업의 진행 상태를 확인하고, 결과물을 받을 수 있게 한다.

A2A에서 기억할 세 가지

Agent Card · “나는 누구이고 어떤 일을 할 수 있는가”를 설명하는 디지털 명함
Message · 에이전트 사이에서 주고받는 요청과 응답
Task · 시간이 걸리는 업무의 상태와 결과를 관리하는 작업 단위

Agent Card가 특히 흥미롭다. 사람의 명함에 이름과 회사, 역할이 적혀 있다면 Agent Card에는 에이전트의 능력, 접속 위치, 지원 기능, 인증 요구사항 등이 담긴다. 다른 에이전트는 이것을 보고 “이 일을 이 상대에게 맡길 수 있는가”를 판단한다.

즉 A2A의 핵심은 AI끼리 사람처럼 잡담하게 만드는 것이 아니다. 서로의 능력을 발견하고, 적절한 상대에게 일을 맡기고, 그 업무의 진행과 결과를 교환하는 것에 가깝다.

구분	MCP	A2A
주된 연결	AI ↔ 데이터·도구	AI 에이전트 ↔ AI 에이전트
쉽게 비유하면	직원이 회사 시스템을 사용하는 공통 연결 규칙	부서와 전문가 사이에서 일을 의뢰하는 공통 업무 규칙
대표 질문	“이 데이터를 어떻게 읽고 이 도구를 어떻게 실행할까?”	“이 일을 어떤 에이전트에게 맡기고 결과를 어떻게 받을까?”
둘의 관계	경쟁 관계라기보다 보완 관계다. 한 에이전트 내부에서는 MCP로 도구를 사용하고, 여러 에이전트 사이에서는 A2A로 업무를 협력하는 구조를 만들 수 있다.

쉬운 예에서 한 단계 더: 출장 준비를 여러 에이전트가 맡는다면

이제 처음의 출장 예제를 조금 복잡하게 만들어보자. 사용자에게는 하나의 출장 비서만 보인다. 하지만 뒤에서는 여러 전문 에이전트가 움직인다.

쉬운 예제 ② · 여러 에이전트의 출장 준비

1. 사용자가 출장 비서 에이전트에게 “9월 초 도쿄 출장을 준비해줘”라고 요청한다.

2. 출장 비서는 MCP를 통해 사용자의 일정과 사내 출장 규정을 확인한다.

3. 항공 전문 에이전트에게 A2A로 적합한 항공편 조사를 요청한다.

4. 숙박 전문 에이전트에는 회사 규정 안에서 호텔 후보를 요청한다.

5. 각 전문 에이전트는 자신의 MCP 연결을 통해 예약 시스템이나 가격 데이터를 조회할 수 있다.

6. 출장 비서가 결과를 합쳐 사용자에게 보여주고, 최종 결제 전에 승인을 요청한다.

이 예에서 구조가 눈에 들어온다. MCP는 각 에이전트가 실제 일을 하기 위해 필요한 데이터와 도구를 연결하고, A2A는 전문성이 다른 에이전트 사이의 업무 위임을 연결한다.

이 구조의 장점은 모든 능력을 하나의 거대한 AI에 넣지 않아도 된다는 데 있다. 여행 전문 에이전트, 비용 관리 에이전트, 회사 내부 에이전트를 서로 다른 조직이나 공급자가 개발하더라도 공통 통신 규칙이 있다면 조합할 가능성이 생긴다.

기업에서는 훨씬 어려워진다: 구매 업무를 다섯 개의 AI가 처리한다면

기업에서는 이 구조가 훨씬 복잡해진다. 제조기업이 새로운 부품 공급업체를 선정한다고 가정해보자. 가격만 싸다고 계약할 수 없다. 공급능력, 재무상태, 제재 여부, 계약조건, 예산까지 함께 봐야 한다.

하나의 AI에게 모든 데이터와 권한을 주는 대신 업무를 전문 영역별로 나눌 수 있다.

MULTI-AGENT EXAMPLE

구매 에이전트 · 전체 요청을 관리

가격 에이전트 · 견적과 과거 구매가격 비교

공급망 에이전트 · 생산능력과 공급 위험 확인

법무 에이전트 · 계약 조건과 규정 검토

재무 에이전트 · 예산과 지불 조건 확인

각 에이전트가 필요한 내부 시스템을 MCP로 사용하면서, 구매 에이전트와는 A2A를 통해 요청과 결과를 주고받는 구조를 생각할 수 있다.

여기에 외부 공급업체의 에이전트까지 들어오면 조직 경계도 넘는다. 이때부터 질문은 “AI가 일을 할 수 있는가”에서 “누가 어떤 AI를 믿고 어디까지 권한을 줄 것인가”로 바뀐다.

A2A가 Agent Card, 작업 상태, 인증 방식 같은 요소를 중요하게 다루는 이유도 여기에 있다. 특히 v1.0에서는 서명된 Agent Card를 통해 에이전트의 신원과 메타데이터를 검증할 수 있는 기반을 추가했다. 여러 기술 스택과 조직 경계를 넘는 순간 '상대가 정말 누구인가'가 기능만큼 중요해지기 때문이다.

주의할 점

표준이 있다고 신뢰 문제가 자동으로 해결되는 것은 아니다. 프로토콜은 신원·권한·통신을 구현할 공통 기반을 제공할 뿐이다. 어떤 에이전트를 허용할지, 어떤 데이터까지 전달할지, 누가 최종 행동을 승인할지는 기업이 별도로 설계해야 한다.

MCP와 A2A를 함께 보면 기업 AI의 5단계 구조가 보인다

여기까지의 내용을 하나의 구조로 다시 정리하면 기업 AI를 보는 관점도 달라진다. 중요한 것은 어떤 모델이 가장 똑똑한지만이 아니다.

AGENCYTIMES · 5-LAYER AGENT MAP

1. 모델 → 질문을 이해하고 추론한다.

2. MCP → 데이터, 파일, 검색, 업무 도구와 연결한다.

3. 에이전트 → 목표를 받아 여러 도구와 단계를 조합해 업무를 수행한다.

4. A2A → 전문성이 다른 에이전트 사이에서 업무를 위임하고 결과를 교환한다.

5. 인간·정책 → 예산, 권한, 승인, 책임의 경계를 정한다.

마지막 다섯 번째 층이 가장 중요하다. 앞의 네 층이 아무리 발전해도 기업은 예산을 승인하고, 고객 데이터를 열어주고, 계약에 서명하고, 돈을 지불하는 권한을 어디까지 자동화할지 결정해야 한다.

플랫폼을 운영할 때 연결점이 많아질수록 문제가 기능에서 운영으로 이동하는 경우가 많다. AI 에이전트도 마찬가지다. 한 개의 시범 에이전트가 성공하는 것과 수십 개의 에이전트가 회사 데이터와 외부 파트너를 넘나들며 안정적으로 일하는 것은 전혀 다른 문제다.

따라서 A2A와 MCP가 중요한 이유는 AI가 더 똑똑해져서만은 아니다. AI를 하나씩 직접 연결하는 방식에서, 연결 자체를 표준화하는 단계로 이동하고 있기 때문이다.

진짜 어려운 질문은 ‘대화할 수 있는가’ 다음에 온다

2026년 들어 두 프로토콜은 빠르게 기업 운영을 의식한 방향으로 발전하고 있다. MCP는 7월 28일 사양에서 일반 웹 인프라에 더 쉽게 확장할 수 있는 무상태 코어와 권한 부여 강화를 내놓았다. 8월 13~14일에는 서울에서 MCP Dev Summit이 열렸고, 멀티에이전트 시스템과 기업 통합, 보안과 운영이 주요 의제로 다뤄졌다.

A2A 역시 v1.0에서 기업 배포를 위한 다중 고객 분리 운영, 버전 협상, 서명된 Agent Card와 보안 구조를 강화했다. Linux Foundation의 2026년 4월 발표 기준으로 A2A를 지원하는 조직은 150곳을 넘어섰다고 한다. 이 숫자는 프로젝트 측 발표라는 점을 감안해야 하지만, 적어도 에이전트 간 상호운용성이 하나의 독립적인 인프라 문제로 자리 잡고 있음을 보여주는 신호다.

그렇다고 모든 기업이 지금부터 멀티에이전트 시스템을 만들어야 한다는 뜻은 아니다. 한 에이전트와 몇 개의 도구로 해결할 수 있는 문제에 여러 에이전트를 투입하면 오히려 비용, 지연시간, 장애 지점, 보안 검토가 늘어난다.

도입 전에 물어볼 질문

도구 연결 문제인가? 그렇다면 우선 MCP를 검토할 수 있다.
전문 에이전트 사이의 협업 문제인가? 그렇다면 A2A가 의미를 갖기 시작한다.
한 에이전트로 충분한가? 충분하다면 굳이 멀티에이전트 구조를 만들 이유가 없다.
에이전트가 다른 에이전트에게 일을 넘길 때 권한도 함께 넘어가는가?
실패했을 때 어느 에이전트의 판단이 문제였는지 추적할 수 있는가?
돈을 쓰거나 데이터를 외부로 보내는 행동의 최종 승인자는 누구인가?

여기에서 앞으로 더 큰 질문도 나온다. 기업용 AI의 경쟁력은 가장 좋은 모델을 가진 회사에 생길까, 아니면 가장 많은 도구와 에이전트를 안전하게 연결할 수 있는 회사에 생길까. 그리고 에이전트가 다른 에이전트를 스스로 찾아 일을 맡기게 된다면, 사람에게 검색엔진이 중요했던 것처럼 에이전트가 다른 에이전트를 발견하는 관문이 새로운 플랫폼 권력이 될 가능성은 없을까.

A2A와 MCP가 흥미로운 이유는 이 질문을 기술 문서 밖으로 끌어내기 때문이다. AI의 다음 경쟁은 모델의 지능만으로 설명되지 않을 수 있다. 연결, 발견, 권한, 신뢰, 비용, 책임이 함께 설계되어야 실제 기업 시스템이 된다.

Summary

MCP는 AI가 데이터와 도구를 일정한 방식으로 사용할 수 있게 하고, A2A는 서로 다른 AI 에이전트가 능력을 발견하고 업무를 위임하며 결과를 교환할 수 있게 한다. 둘은 경쟁 기술이라기보다 서로 다른 연결 계층이다. 기업이 봐야 할 다음 문제는 연결 가능 여부보다 누가 어떤 데이터와 권한을 갖고, 에이전트 사이에 권한이 어떻게 이동하며, 마지막 행동을 누가 승인하고 책임질 것인가다.

FAQ

A2A와 MCP에 대해 자주 묻는 질문

Q. MCP와 A2A는 무엇이 가장 다른가요?

MCP는 주로 AI 애플리케이션과 데이터·도구의 연결을 표준화하고, A2A는 서로 독립적인 AI 에이전트 사이의 통신과 업무 조정을 표준화합니다. 실제 멀티에이전트 시스템에서는 한 에이전트가 MCP로 도구를 사용하고 A2A로 다른 에이전트와 협력하는 구조가 가능합니다.

Q. MCP를 사용하면 A2A는 필요 없나요?

그렇지 않습니다. 하나의 에이전트가 여러 도구를 사용하는 정도라면 MCP만으로 충분할 수 있지만, 서로 다른 에이전트가 능력을 발견하고 업무를 주고받아야 한다면 A2A가 다루는 문제가 생깁니다. 시스템을 복잡하게 만들 필요가 없다면 처음부터 둘을 모두 사용할 이유도 없습니다.

Q. A2A를 사용하면 서로 다른 회사의 AI도 협업할 수 있나요?

A2A는 서로 다른 프레임워크·공급자·조직의 에이전트가 상호운용될 수 있는 공통 규칙을 제공하는 것이 목표입니다. 다만 실제 기업 간 연결에서는 신원 검증, 데이터 접근권, 인증, 계약, 보안 정책을 별도로 설계해야 합니다.

Q. 기업이 지금 가장 먼저 준비해야 할 것은 무엇인가요?

프로토콜 도입보다 업무 경계를 먼저 정의하는 편이 낫습니다. 어떤 데이터를 AI가 읽을 수 있는지, 어떤 행동을 자동 실행할 수 있는지, 다른 에이전트에게 무엇까지 위임할 수 있는지, 최종 승인과 책임을 누가 갖는지를 먼저 정해야 합니다.

TERMINOLOGY

본문에 나오는 주요 용어

용어	뜻	기억할 포인트
MCP	모델 컨텍스트 프로토콜	AI와 데이터·도구의 연결
A2A	Agent2Agent Protocol	독립된 에이전트 사이의 발견·통신·업무 위임
Agent Card	에이전트의 신원·능력·접속 정보 등을 담은 메타데이터	에이전트의 디지털 명함
Task	에이전트가 수행하는 상태를 가진 업무 단위	오래 걸리는 작업의 진행과 결과를 추적
상호운용성	서로 다른 시스템이 공통 규칙을 통해 함께 작동하는 능력	특정 공급자 하나에 모든 시스템을 맞추지 않아도 되는 기반

이 블로그 검색