기업이 AI 에이전트를 만들기 시작하면 처음에는 한 애플리케이션 안에서 모든 일을 처리하려고 합니다. 고객 문의를 이해하고, CRM을 조회하고, 주문 상태를 확인하고, 환불 규정을 검색한 뒤 답변까지 만드는 하나의 큰 에이전트입니다. 도구가 늘어나면 MCP(Model Context Protocol) 서버를 연결해 기능을 확장합니다.
이 구조는 한 팀과 한 보안 경계 안에서는 효율적입니다. 그러나 재무, 생산, 물류, 고객지원처럼 소유 조직과 권한이 다른 업무를 한 에이전트에 계속 넣으면 문제가 생깁니다. 프롬프트와 도구 목록은 커지고, 한 계정에 너무 많은 권한이 모이며, 어느 팀이 어떤 판단을 책임지는지 흐려집니다.
여기서 A2A(Agent2Agent) Protocol이 등장합니다. A2A는 다른 프레임워크와 공급자, 조직에 속한 독립적인 에이전트가 자신의 내부 구현을 공개하지 않고 능력을 알리고, 작업을 주고받고, 진행 상태와 결과물을 교환하도록 하는 공개 프로토콜입니다. 2025년 Google이 공개한 뒤 Linux Foundation의 오픈소스 프로젝트로 이관됐고, 2026년에는 주요 클라우드 플랫폼과 여러 조직의 지원을 받는 상호운용 표준으로 발전하고 있습니다.
하지만 A2A를 도입한다고 시스템이 자동으로 멀티에이전트 아키텍처가 되는 것은 아닙니다. MCP와 A2A는 경쟁 기술이 아니라 서로 다른 경계를 표준화합니다. 무엇을 도구로 노출하고 무엇을 독립 에이전트로 운영할지 결정하는 일이 먼저입니다.
MCP는 깊이를, A2A는 범위를 확장한다
A2A 공식 문서는 두 프로토콜을 수직과 수평 계층으로 설명합니다. MCP는 하나의 에이전트가 데이터베이스, API, 파일, 검색기와 같은 도구와 자원에 접근하는 수직 연결입니다. 연결이 늘수록 해당 에이전트가 직접 할 수 있는 일이 많아집니다.
A2A는 독립적인 에이전트 사이의 수평 연결입니다. 다른 에이전트는 단순 함수가 아니라 자체 모델, 메모리, 정책, 도구와 장기 작업 상태를 가진 서비스입니다. 요청을 받은 뒤 추가 정보를 물어보고, 여러 단계를 수행하며, 중간 상태를 알리고, 문서나 구조화 데이터 같은 결과물을 반환할 수 있습니다.
| 구분 | MCP | A2A |
|---|---|---|
| 연결 대상 | 에이전트 ↔ 도구·데이터·프롬프트 | 에이전트 ↔ 독립 에이전트 |
| 주요 단위 | 도구 호출과 구조화된 결과 | 메시지, 상태가 있는 작업, 결과물 |
| 상호작용 | 대체로 명확하고 제한된 기능 | 대화형·장기 실행·비동기 협업 |
| 내부 구현 | 호출 가능한 기능을 노출 | 원격 에이전트 내부는 불투명 |
| 대표 사례 | DB 조회, 문서 검색, API 실행 | 지원 에이전트가 결제 에이전트에 조사 위임 |
하나의 업무에서도 둘은 함께 쓰입니다. 고객지원 에이전트가 환불 가능성을 확인하기 위해 결제 에이전트에 A2A로 작업을 맡길 수 있습니다. 결제 에이전트는 내부에서 MCP를 통해 결제 API와 정책 문서를 조회합니다. 고객지원 에이전트는 결제 시스템의 테이블 구조나 내부 도구를 알 필요가 없습니다.
모든 API를 에이전트로 감싸면 안 된다
멀티에이전트가 유행한다고 계산기, 검색 API, 데이터 조회 기능까지 각각 에이전트로 만들 필요는 없습니다. 에이전트가 늘면 네트워크 호출, 모델 추론, 인증, 로그, 장애 지점과 비용이 함께 늘어납니다.
다음 조건이 강할수록 MCP 도구가 적합합니다.
- 입력과 출력 스키마가 명확하고 호출이 짧게 끝난다.
- 자체 목표나 장기 상태 없이 요청받은 기능만 수행한다.
- 호출자가 실행 순서와 오류 처리를 통제해야 한다.
- 한 애플리케이션과 보안 경계 안에서 관리된다.
반대로 다음 조건이 있다면 A2A 에이전트 경계를 검토할 수 있습니다.
- 다른 팀이나 회사가 독립적으로 운영하고 배포한다.
- 내부 계획과 도구를 감춘 채 업무 결과에 책임진다.
- 처리 시간이 길고 추가 질문이나 사람 승인이 필요하다.
- 작업 상태, 취소, 재개와 결과물 관리가 필요하다.
- 여러 채널과 공급자가 같은 계약으로 상호운용해야 한다.
판단 기준은 “LLM을 쓰는가”가 아닙니다. 독립적인 업무 책임과 생명주기를 가진 서비스인가입니다. 규칙 기반 시스템도 A2A 서버가 될 수 있고, LLM을 사용하는 기능도 단순 도구일 수 있습니다.
A2A의 핵심 객체를 업무 계약으로 이해하기
Agent Card: 능력을 알리는 명세
Agent Card는 에이전트의 정체성, 엔드포인트, 지원 기능, 인증 방식과 스킬을 설명하는 JSON 메타데이터입니다. 클라이언트 에이전트는 이를 읽고 요청을 보낼 수 있는지 판단합니다. 사람의 명함보다는 서비스 카탈로그와 OpenAPI 문서의 역할에 가깝습니다.
다만 Agent Card가 존재한다고 상대를 신뢰해도 된다는 뜻은 아닙니다. 카드의 출처, 도메인, 인증서와 등록 절차를 검증해야 합니다. 인터넷에서 발견한 에이전트를 곧바로 업무에 연결하는 대신 승인된 레지스트리와 게이트웨이를 두는 것이 기업 환경에 적합합니다.
Task: 상태가 있는 작업 단위
Task는 고유 ID와 생명주기를 가진 작업입니다. 즉시 답할 수 없는 요청이나 여러 단계가 필요한 일을 추적합니다. 작업은 대기, 진행, 추가 입력 필요, 완료, 실패, 취소 같은 상태를 가질 수 있습니다. 클라이언트는 상태를 조회하거나 스트림과 알림을 통해 변경을 받을 수 있습니다.
Message와 Part: 협업을 위한 대화
Message는 지시, 질문, 설명과 상태 정보를 교환하는 한 차례의 통신입니다. 실제 내용은 Part에 담기며 텍스트, 구조화 데이터, 파일 참조나 바이너리를 표현할 수 있습니다. 따라서 문서, 이미지, JSON 데이터를 같은 상호작용 안에서 교환할 수 있습니다.
Artifact: 작업의 지속 가능한 결과물
Artifact는 보고서, 견적서, 분석 데이터처럼 작업이 만들어낸 구체적인 산출물입니다. 공식 사양은 일반적인 대화와 실제 결과를 구분합니다. 중요한 결과를 마지막 메시지 문자열에만 넣으면 재연결과 감사가 어렵습니다. 결과물은 작업에 연결된 Artifact로 식별하고 저장 정책과 무결성 정보를 가져야 합니다.
긴 작업은 HTTP 요청 하나로 끝내지 않는다
에이전트 협업은 몇 초 만에 끝나는 조회부터 사람이 승인할 때까지 며칠 기다리는 조달 업무까지 포함할 수 있습니다. A2A는 요청·응답과 폴링, Server-Sent Events 기반 스트리밍, 웹훅 형태의 푸시 알림 같은 상호작용을 지원합니다.
선택 기준은 처리 시간과 연결 안정성입니다.
- 즉시 응답: 짧고 결과가 바로 나오는 질문
- 스트리밍: 연결을 유지하며 중간 진행이나 부분 결과를 보여줘야 하는 작업
- 폴링: 클라이언트가 일정 간격으로 상태를 확인해도 되는 작업
- 푸시 알림: 연결을 계속 유지할 수 없는 장기 작업이나 외부 시스템 연계
스트리밍 메시지를 영구 기록으로 가정하면 안 됩니다. 연결이 끊기면 일부 상태 알림을 놓칠 수 있습니다. 중요한 상태와 결과는 Task 조회로 복구할 수 있어야 하고, 완료 알림을 못 받더라도 클라이언트가 최종 상태를 재확인할 수 있어야 합니다.
신원은 ‘어떤 에이전트인가’보다 ‘누구를 대신하는가’가 중요하다
에이전트 A가 에이전트 B를 호출할 때 최소 세 주체가 존재합니다. 요청을 시작한 사용자, 호출하는 애플리케이션 또는 에이전트, 실제 업무를 수행하는 원격 에이전트입니다. 이 셋을 하나의 공용 API 키로 뭉개면 감사와 최소 권한을 지킬 수 없습니다.
A2A는 인증을 새로 발명하기보다 HTTPS, OAuth 2.0, OpenID Connect와 같은 기존 웹 보안 방식을 활용합니다. 인증 요구사항은 Agent Card에 표현할 수 있지만 실제 자격증명은 HTTP 계층에서 전달합니다. 서버는 매 요청을 인증하고, 스킬과 데이터·행동 수준에서 별도로 권한을 검사해야 합니다.
실무에서는 다음 정보를 분리해 기록하는 것이 좋습니다.
- 최종 사용자와 소속 테넌트
- 호출한 클라이언트 에이전트의 서비스 신원
- 사용자를 대신해 행사할 수 있는 위임 범위와 만료 시각
- 호출할 수 있는 스킬과 데이터 범위
- 사람 승인이 필요한 행동과 승인 근거
원격 에이전트가 내부 MCP 도구를 호출할 때도 동일한 경계를 적용해야 합니다. A2A에서 인증됐다는 이유만으로 모든 내부 도구에 접근하게 하면 원격 요청이 권한 상승 통로가 됩니다.
멀티에이전트에서 새로 생기는 다섯 가지 위험
1. Agent Card 위조와 잘못된 발견
공격자가 정상 에이전트와 비슷한 이름과 스킬을 광고하면 잘못된 대상에게 문서와 작업을 보낼 수 있습니다. 카드가 배포되는 도메인과 서명, 레지스트리 등록 주체, 인증서와 조직 소유권을 검증해야 합니다.
2. 혼동된 대리인 문제
권한이 큰 원격 에이전트가 권한이 작은 호출자의 요청을 받아 민감한 행동을 대신 수행할 수 있습니다. 호출자 신원뿐 아니라 최종 사용자와 위임 범위를 확인하고 스킬별 권한을 적용해야 합니다.
3. 에이전트를 건너는 프롬프트 인젝션
한 에이전트가 읽은 외부 문서의 악성 지시가 Message나 Artifact에 섞여 다음 에이전트로 전달될 수 있습니다. 데이터와 명령을 구조적으로 분리하고, 원격 출력은 신뢰할 수 없는 입력으로 취급하며, 후속 도구 호출을 독립적으로 승인해야 합니다.
4. 무한 위임과 비용 폭주
A가 B에, B가 C에 작업을 맡기고 C가 다시 A를 호출하면 순환 위임이 생길 수 있습니다. 최대 위임 깊이, 총 모델 호출 수, 시간·비용 예산과 허용된 에이전트 목록을 작업 컨텍스트에 포함해야 합니다.
5. 결과물의 데이터 유출
Artifact는 파일과 구조화 데이터를 담을 수 있어 대화 텍스트보다 민감할 수 있습니다. 최소 데이터만 전송하고, 다운로드 URL의 만료와 접근 제어, 악성 파일 검사, 저장 위치와 보존 기간을 관리해야 합니다.
분산 작업의 신뢰성은 REST API보다 더 많은 규칙이 필요하다
네트워크가 끊긴 뒤 클라이언트가 같은 요청을 다시 보내면 원격 에이전트가 주문이나 결제를 두 번 실행할 수 있습니다. 모든 변경 작업에는 멱등성 키가 필요하고, 서버는 일정 기간 처리 결과를 기억해 중복 실행을 막아야 합니다.
다음 항목을 프로토콜 바깥의 운영 계약으로 명시해야 합니다.
- 요청·작업·컨텍스트·추적 ID의 관계
- 생성, 조회, 취소와 알림의 멱등성 규칙
- 상태별 타임아웃과 재시도 가능한 오류 구분
- 지수 백오프, 최대 재시도와 서킷 브레이커
- 부분 완료 후 취소할 때의 보상 작업
- 웹훅 서명, 재전송과 중복 제거
- 결과물 체크섬과 버전, 만료 정책
취소도 즉시 완료를 의미하지 않을 수 있습니다. 원격 시스템에서 이미 실행 중인 작업을 중단할 수 없는 경우 “취소 요청됨”과 “취소됨”을 구분하고, 완료 후 되돌리는 보상 절차를 제공해야 합니다.
한 번의 사용자 요청을 끝까지 추적하는 법
에이전트가 세 개만 연결돼도 로그는 여러 서비스에 흩어집니다. 사용자에게는 한 번의 요청이지만 내부에서는 A2A 작업, 모델 호출, MCP 도구 호출, 데이터베이스 쿼리와 외부 API가 연쇄적으로 발생합니다.
모든 구간에서 W3C Trace Context 같은 표준 추적 컨텍스트를 전달하고 다음 정보를 스팬과 감사 로그에 연결해야 합니다.
- 사용자 요청과 A2A Task ID
- 호출자·수행자 에이전트와 스킬 버전
- 모델·프롬프트·정책 버전
- 내부 MCP 도구와 외부 시스템 호출
- 상태 변화, 재시도, 승인과 취소 이벤트
- 입출력 크기, 지연시간, 토큰과 금액 비용
- Artifact의 위치, 민감도와 해시
내용 전체를 로그에 복사하면 개인정보와 영업비밀이 새로운 로그 저장소로 확산됩니다. 본문 대신 식별자와 해시, 분류 등급을 남기고 상세 내용은 권한이 통제되는 원본 저장소에서 조회하는 편이 안전합니다.
기업용 권장 구조: 에이전트 게이트웨이와 승인된 레지스트리
각 에이전트가 인터넷의 다른 에이전트를 직접 찾고 호출하게 두면 정책과 관측이 분산됩니다. 기업에서는 에이전트 게이트웨이를 통해 외부·부서 간 호출을 통제하는 구조가 현실적입니다.
- 에이전트 레지스트리가 승인된 Agent Card와 소유팀, 위험 등급, 버전을 관리합니다.
- 정책 결정 지점이 사용자·클라이언트·스킬·데이터 민감도에 따라 호출 허용 여부를 판단합니다.
- A2A 게이트웨이가 인증, 속도 제한, 위임 깊이, 비용 예산과 감사 로그를 적용합니다.
- 작업 저장소가 Task 상태와 멱등성 키, 결과물 참조를 지속적으로 보관합니다.
- 각 도메인 에이전트는 자신의 보안 경계 안에서 MCP 도구와 데이터를 사용합니다.
- 관측 플랫폼이 A2A와 MCP 호출을 하나의 분산 추적으로 연결합니다.
게이트웨이가 모든 업무 판단을 대신하면 새로운 중앙 병목이 됩니다. 공통 보안과 운영 정책은 중앙에서 적용하되, 스킬의 의미와 결과 품질은 도메인 소유팀이 책임지는 연합형 운영이 적합합니다.
제조·서비스 통합 예시
고객이 설비 이상을 신고했다고 가정해보겠습니다. 서비스 에이전트는 고객과 증상을 정리하고, 설비 진단 에이전트에 A2A 작업을 위임합니다. 진단 에이전트는 내부 MCP 도구로 센서 이력과 정비 매뉴얼을 조회합니다.
부품 교체가 필요하면 진단 에이전트는 부품 공급 에이전트에 재고와 납기를 묻습니다. 서비스 일정 에이전트는 기술자의 스킬과 위치를 고려해 방문 후보를 계산합니다. 비용이 기준을 넘으면 사람 승인 상태로 전환하고, 승인 후 각 에이전트가 만든 진단서·견적서·일정표를 Artifact로 묶어 고객에게 제공합니다.
이 구조에서 고객지원 에이전트가 생산 DB나 기술자 인사정보를 직접 볼 필요는 없습니다. 각 도메인이 자신의 데이터와 규칙을 책임지고 필요한 결과만 공개합니다. 이것이 단순히 큰 에이전트를 여러 개로 쪼개는 것보다 중요한 아키텍처 효과입니다.
도입 순서: 프로토콜보다 업무 경계를 먼저 검증한다
- 도메인 경계 선택: 소유팀과 권한이 다르고 수작업 인계가 많은 업무 하나를 고릅니다.
- 현재 계약 정의: 요청·상태·결과·오류·승인 조건을 모델과 무관한 업무 계약으로 적습니다.
- 도구와 에이전트 분류: 짧고 결정적인 기능은 MCP 도구로, 독립 책임과 장기 상태가 있는 기능은 A2A 에이전트로 둡니다.
- 단일 위임 PoC: 에이전트 둘 사이의 한 방향 위임부터 시작해 Task와 Artifact를 검증합니다.
- 보안·실패 테스트: 권한 없는 스킬, 토큰 만료, 중복 요청, 타임아웃, 취소, 악성 Artifact를 시험합니다.
- 관측과 비용 기준선: 성공률뿐 아니라 전체 지연, 재시도, 모델·도구 비용과 사람 개입률을 측정합니다.
- 레지스트리와 정책 자동화: 검증된 에이전트만 단계적으로 추가하고 버전 호환성을 관리합니다.
프로토콜 표준화가 업무 표준화를 대신하지는 않는다
A2A를 사용하면 서로 다른 플랫폼의 에이전트가 같은 통신 형식을 사용할 수 있습니다. 하지만 “환불 가능”, “납기 확정”, “점검 완료”가 각 조직에서 무엇을 의미하는지까지 프로토콜이 정의해주지는 않습니다. 스킬의 입력·결과 스키마, 오류 의미, SLA와 책임 경계는 여전히 회사가 정해야 합니다.
또한 사양과 SDK는 계속 발전합니다. Agent Card에 기능과 확장, 지원 버전을 명시하고, 클라이언트가 지원하지 않는 필수 기능을 조용히 무시하지 않도록 해야 합니다. 계약 테스트와 호환성 테스트를 CI에 넣고 이전 버전 종료 정책을 운영해야 공급자 간 상호운용성이 실제로 유지됩니다.
결국 MCP와 A2A의 선택은 프로토콜 취향이 아니라 시스템 경계의 문제입니다. 에이전트가 직접 사용하는 제한된 기능은 MCP로, 독립적인 책임과 상태를 가진 다른 업무 주체와의 협업은 A2A로 연결합니다. 그리고 그 사이에 신원 위임, 최소 권한, 멱등성, 관측성과 사람 승인을 설계해야 합니다.
좋은 멀티에이전트 시스템은 에이전트 수가 많은 시스템이 아닙니다. 각 에이전트가 무엇을 책임지고, 누구를 대신하며, 실패했을 때 어디까지 되돌릴 수 있는지가 명확한 시스템입니다. 프로토콜은 그 경계를 연결하는 공통 언어이고, 운영 가능한 아키텍처는 그 언어 위에 세워야 합니다.
