이 글의 목차
A2A는 다른 에이전트에 일을 맡기는 통신을, MCP는 애플리케이션이 도구와 자료에 연결하는 통신을 이해하는 출발점입니다. AI를 여러 개 연결했다고 협업이 저절로 좋아지는 것은 아닙니다. 누가 일을 맡겼고, 지금 어느 상태이며, 결과가 누구에게 보이는지 정해야 합니다.
A2A 프로젝트는 1.0을 안정화된 프로토콜로 발표했고, 공식 문서는 MCP와의 관계도 따로 설명합니다. A2A 1.0 발표, A2A와 MCP 여기서는 ‘AI끼리 대화한다’는 표현을 실제 서비스 설계로 옮길 때 생기는 질문을 다룹니다.
도구 호출과 업무 위임의 차이
예를 들어 여행 도우미가 항공편 검색 함수를 호출하는 경우와, 여행 전문 에이전트에게 일정 전체의 후보를 만들어달라고 위임하는 경우를 비교해보세요. 둘 다 내부에 모델이나 코드가 있을 수 있지만 외부에 노출하는 계약이 다릅니다.
| 비교 | 도구 호출 중심 | 에이전트 위임 중심 |
|---|---|---|
| 요청 | 특정 입력으로 기능 실행 | 목표와 제약을 전달 |
| 결과 | 정해진 출력 | 진행 상태·추가 질문·산출물 |
| 작업 시간 | 즉시 끝나거나 별도 비동기 설계 | 긴 작업의 수명 관리가 중요 |
| 책임 | 기능의 계약 준수 | 목표 달성 여부와 결과 검증 |
MCP에도 긴 작업을 다루는 확장이 있습니다. 따라서 ‘MCP는 무조건 짧은 함수만 가능’이라고 분류하면 안 됩니다. 프로토콜 이름보다 외부에 어떤 작업 계약을 제공하는지부터 정하세요. MCP 2026 변경점과 함께 읽으면 경계를 이해하기 쉽습니다.
Agent Card·Task·Artifact를 구별
A2A 명세는 에이전트의 기능·접속·보안 정보를 나타내는 Agent Card, 작업 상태를 관리하는 Task, 결과물을 나타내는 Artifact 등의 모델을 정의합니다. A2A 1.0 고정 버전 명세
이 구조를 사용자 관점에서 풀면 다음과 같습니다.
- Agent Card: 어디에 어떤 일을 맡길 수 있는지 찾는 정보.
- Task: 맡긴 일이 진행 중인지, 입력을 기다리는지, 끝났는지 확인하는 단위.
- Artifact: 작업이 만든 문서·자료 등 결과물.
결과 문서가 존재한다는 사실만으로 작업이 성공한 것은 아닙니다. 요구한 언어, 기간, 출처, 접근 권한이 맞는지 따로 확인해야 합니다. 카드에 기능을 적었다고 결과 품질이나 운영 신뢰가 인증되는 것도 아닙니다.
가상의 시장조사 업무를 나눠보기
다음은 프로토콜의 실제 메시지 형식이 아니라, 역할을 나누기 위한 업무 예시입니다.
조정 에이전트: 조사 질문·기간·출처 조건을 정리수집 에이전트: 허용된 자료에서 근거를 수집분석 에이전트: 근거와 계산을 대조조정 에이전트: 최종 보고서와 미확인 항목을 사용자에게 반환여기서 각 에이전트가 모든 원본 자료와 계정 토큰을 공유할 필요는 없습니다. 수집 에이전트는 읽기 권한만, 보고서 저장 에이전트는 특정 폴더의 쓰기 권한만 갖도록 범위를 나눌 수 있습니다. 조정 에이전트가 임의로 더 넓은 권한을 전달하는 상황도 막아야 합니다.
협업에서 가장 먼저 터지는 네 가지 문제
1. 추가 질문을 실패로 오해
작업에 필요한 날짜나 자료 범위가 없으면 에이전트가 입력을 기다릴 수 있습니다. 시스템이 이를 단순 timeout으로 처리하면 작업을 재시작해 같은 질문만 반복할 수 있습니다. 사용자에게 필요한 정보를 보여주고 기존 작업에 이어서 답하는 경로를 설계하세요.
2. 같은 작업을 두 번 시작
응답이 끊겼다고 새 업무를 시작하면 중복 보고서나 중복 외부 변경이 생길 수 있습니다. 작업 식별자, 재시도 규칙, 원본에서의 멱등성을 정하세요. 통신 형식과 실제 변경의 정확성은 별도입니다.
3. 결과 파일의 링크만 반환
링크가 만료됐거나 사용자에게 접근 권한이 없으면 산출물은 있지만 전달에 실패한 것입니다. 결과의 접근 범위·저장 기간·만료와 사용자 조회 경로를 함께 시험하세요.
4. 다른 에이전트의 문장을 지시로 신뢰
외부 에이전트가 반환한 텍스트에는 오해·잘못된 정보·악의적인 내용이 있을 수 있습니다. 연결 성공을 콘텐츠 신뢰로 바꾸지 말고, 원래 사용자의 요청과 서버 권한 범위를 유지하세요. 특히 도구를 실행하는 에이전트에는 결과 검증 단계가 필요합니다.
프로토콜 선택을 위한 의사결정표
| 현재 문제 | 먼저 검토할 것 |
|---|---|
| 단일 앱에서 DB·검색 도구 연결 | MCP 또는 기존 API 계약 |
| 외부 팀의 에이전트에 업무 위임 | A2A 작업·보안·호환 계약 |
| 단순한 순서의 세 작업 실행 | 일반 workflow로 충분한지 |
| 새 상태를 여러 시스템에 반영 | 트랜잭션·멱등성·보상 동작 |
| 서로 신뢰하지 않는 사용자 공유 | 계정·저장소·권한 경계 분리 |
일정한 처리 순서라면 모델끼리 자유롭게 협상하게 하는 것보다 명시적 workflow가 더 관측하기 쉬울 수 있습니다. A2A를 채택하는 이유는 다른 에이전트와의 상호운용 요구여야 합니다. 이름이 새롭다는 이유로 모든 내부 함수를 외부 에이전트로 바꿀 필요는 없습니다.
성능보다 먼저 측정할 협업 결과
완료율, 추가 입력 대기율, 재시작 횟수, 검증 실패율과 사용자에게 전달된 산출물의 접근 성공률을 기록하세요. 평균 응답 시간이 빨라도 잘못된 결과를 넘기는 시스템은 업무를 끝내지 못한 것입니다.
분산 추적 가이드처럼 작업 흐름을 관측하고, 각 단계의 책임과 실패 원인을 구분하면 모델 문제·통신 문제·권한 문제를 분리하기 쉽습니다.
자주 묻는 질문
A2A 1.0이 나오면 MCP는 필요 없어지나요?
두 프로토콜은 상호 보완적으로 사용할 수 있습니다. 에이전트 간 위임과 도구 연결이 모두 필요한 서비스라면 각각의 역할을 설계해야 합니다.
Agent Card가 있으면 안전한 에이전트인가요?
기능과 보안 정보를 읽을 수 있다는 것과 실제 서비스가 믿을 만하다는 것은 다릅니다. 연결 대상, 인증, 권한, 결과 검증을 확인하세요.
에이전트를 늘리면 정답률이 자동으로 올라가나요?
그렇지 않습니다. 역할·근거·검증이 분리되지 않으면 오류를 반복하거나 비용만 늘 수 있습니다. 단일 방식과 같은 업무 사례로 비교해야 합니다.
참고 자료
2026년 10월 8일 확인. 1.0 명세 기준의 개념 설명이며 설치할 SDK와 연결 대상의 버전·기능 지원을 확인해야 합니다.