A2A 프로토콜: MCP와 혼동하지 않고 AI 에이전트를 연결하는 방법

A2A 프로토콜은 MCP의 또 다른 이름이 아닙니다. 이는 독립적인 에이전트들이 내부 도구를 노출하지 않고도 서로를 발견하고, 작업을 협상하며, 협업할 수 있도록 하는 계층입니다.

A2A 프로토콜, 또는 Agent2Agent 프로토콜은 독립적인 AI 에이전트들이 서로를 발견하고, 인증하며, 메시지를 교환하고, 장기적인 작업을 관리할 수 있도록 하는 개방형 표준입니다. 주요 키워드는 A2A 프로토콜이며, 스페인어 검색 의도는 이것이 무엇인지, MCP와 어떻게 다른지, 그리고 터무니없는 보안 표면을 노출하지 않고 어떻게 구현할 수 있는지를 이해하는 것입니다.

요약 (TL;DR)

인용 가능한 정의: A2A는 에이전트를 다른 에이전트와 연결하고, MCP는 에이전트를 도구 및 리소스와 연결합니다. 만약 당신의 문제가 함수를 호출하거나, 데이터베이스를 조회하거나, API를 호출하는 것이라면 MCP를 생각하십시오. 만약 당신의 문제가 자체적인 상태(state), 판단력, 도구를 가진 다른 에이전트 시스템(agentic system)에 작업을 위임하는 것이라면 A2A를 생각하십시오.

나의 입장: A2A는 더 이상 단순한 Google의 제안이 아니기에 주목할 가치가 있습니다. Linux Foundation 산하에 있으며, 1.0 사양을 갖추고 기업들의 채택이 이루어지고 있습니다. 하지만 신원(identity), Agent Card 서명, 데이터 제한, 감사(auditing) 및 위협 모델링(threat modeling)을 갖추기 전까지는 이를 개방형 에이전트 연합(federation)으로 배포해서는 안 됩니다.

A2A 프로토콜이란 무엇이며 왜 지금 중요한가

공식 사양은 A2A를 독립적이고 잠재적으로 불투명한(opaque) 에이전트 시스템 간의 통신 및 상호 운용성을 위한 개방형 표준으로 정의합니다. 여기서 '불투명한'이라는 단어가 핵심입니다. 클라이언트는 원격 에이전트가 Claude, Gemini, LangGraph를 사용하는지, 내부 도구를 사용하는지, 자체 메모리를 사용하는지, 혹은 인간이 루프 안에 있는지(human-in-the-loop) 알 필요가 없습니다. 클라이언트에게 필요한 것은 해당 에이전트가 어떤 역량을 제공하는지, 어떻게 인증하는지, 그리고 작업의 상태를 어떻게 추적하는지 아는 것입니다.

타이밍이 중요한 이유는 A2A가 더 이상 단순한 제품 홍보로만 존재하지 않기 때문입니다. Google은 중립적인 거버넌스를 부여하기 위해 이 프로젝트를 Linux Foundation으로 이관했으며, 재단은 2026년 4월에 150개 이상의 조직이 이 표준을 지원하고 있으며 대규모 클라우드 및 기업 배포 환경에서 통합이 이루어지고 있다고 발표했습니다. 이것이 성공을 보장하는 것은 아니지만, 리스크의 성격은 변화합니다. A2A를 무시하는 것은 귀하의 공급업체들이 채택하기 시작할 상호 운용성 (Interoperability) 계층에서 소외될 수 있음을 의미합니다.

DevAI Semanal을 위한 실질적인 해석은 다음과 같습니다: A2A는 단순히 어시스턴트가 귀하의 도구 (Tools)를 호출하기를 원하는 것이 아니라, 에이전트 생태계를 설계하고 있을 때 흥미로운 주제입니다. 기술적 경계는 불필요하게 비대해진 아키텍처를 방지합니다.

A2A vs MCP: 잘못된 아키텍처를 방지하는 차이점

공식 문서는 이를 상당히 깔끔한 분리로 설명합니다. MCP는 에이전트가 구조화된 입출력을 통해 도구 (Tools), API, 데이터베이스 및 리소스를 사용하는 방식을 표준화합니다. 반면 A2A는 자율적인 에이전트들이 서로 협업하고, 역량을 발견하며, 상호작용을 협상하고, 컨텍스트 (Context)를 유지하며, 더 긴 작업을 관리하는 방식을 표준화합니다.

예시: 만약 지원 에이전트가 get_invoice(customer_id)를 조회해야 한다면, 이는 MCP 또는 도구 함수 (Tool function)에 해당합니다. 하지만 동일한 에이전트가 대화를 나누고, 정책을 검증하며, 추가 데이터를 요청할 수 있고, 감사 가능한 (Auditable) 결과를 반환하는 청구 에이전트에게 전체 조사를 위임해야 한다면, 이는 A2A에 더 적합합니다.

건강한 아키텍처는 두 가지를 모두 결합합니다. 한 에이전트가 다른 에이전트와 A2A로 대화할 수 있으며, 내부적으로 그 두 번째 에이전트는 자신의 도구를 호출하기 위해 MCP를 사용할 수 있습니다. 한 문장으로 요약하자면: A2A는 에이전트 간의 조정 (Coordination)이며, MCP는 역량에 대한 접근 (Access)입니다.

기술적 블록: Agent Card, Message, Task, Part 및 Artifact

첫 번째 개념은 Agent Card입니다. 이는 에이전트의 정체성(identity), 서비스 엔드포인트(endpoint), A2A 역량(capabilities), 인증 요구사항(authentication requirements) 및 스킬 목록(list of skills)을 기술하는 JSON 문서입니다. 이는 클라이언트가 해당 에이전트와 상호작용할 수 있을지 결정하기 전에 분석하는 기술적인 명함과 같습니다.

다음은 통신 요소들입니다. Message는 클라이언트와 에이전트 사이의 한 턴(turn)을 나타냅니다. Part는 메시지와 아티팩트(artifact) 내의 콘텐츠 컨테이너로, 텍스트, 구조화된 데이터(structured data), 인라인 바이트(inline bytes) 또는 URL 참조를 포함합니다. Artifact는 문서, 구조화된 데이터 또는 생성된 파일과 같이 작업의 구체적인 결과물입니다.

중요한 운영 단위는 Task입니다. 이는 상태(state)를 가지며, 고유 ID와 자체적인 생명주기(lifecycle)를 갖는 작업입니다. 이를 통해 장기 작업, 멀티 턴(multi-turn), 스트리밍(streaming), 폴링(polling) 및 알림(notifications)이 가능해집니다. 만약 귀하의 케이스가 상태나 생명주기를 필요로 하지 않는다면, 아마도 도구(tool)만으로 충분한 곳에 A2A를 사용하려고 시도하고 있는 것일 가능성이 높습니다.

A2A 요청이 전달되는 방식

실제 구현 단계에서 클라이언트는 Agent Card를 발견하거나 수신하고, 원격 에이전트가 필요한 역량을 지원하는지 확인하며, 선언된 스키마에 따라 인증을 수행한 뒤 요청을 보냅니다. 버전 1.0은 JSON-RPC, gRPC 및 HTTP+JSON에 대한 동등한 바인딩(bindings)을 공식화합니다. 단순한 경로는 HTTP 요청으로 시작할 수 있지만, 설계상 폴링(polling), 스트리밍(streaming) 및 웹훅(webhooks)을 지원합니다.

확인해야 할 사항

JSON-RPC에서 핵심 메서드(core methods)에는 메시지 전송, 스트리밍을 포함한 메시지 전송, 작업 조회, 작업 목록 나열, 작업 취소, 작업 구독 및 푸시 알림(push notifications) 설정 관리가 포함됩니다. 이는 A2A가 어떤 유형의 시스템을 기대하는지 이미 말해줍니다. 즉, 200밀리초짜리 무상태(stateless) 호출이 아니라, 진행 상황, 취소, 재시도 및 추적 기능이 포함된 협업 시스템입니다.

백엔드에 미치는 영향은 명확합니다. A2A는 프롬프트(prompt) 위에 단순히 엔드포인트 하나를 추가하는 방식으로 구현되지 않습니다. 작업의 지속성(persistence), ID, 상태, 로그, 권한 제어, 타임아웃(timeouts), 동시성 제한(concurrency limits) 및 오류에 대한 합리적인 이력(history) 관리가 필요합니다.

검토하기 부끄럽지 않은 최소한의 엔드포인트 (Endpoint)

좁은 범위의 스킬 (skill)을 가진 단일 원격 에이전트 (remote agent)로 시작하세요. do_work와 같이 범용적인 스킬을 스무 개씩 공개하지 마세요. 대신 review_openapi_contract, triage_ci_failure 또는 summarize_security_finding과 같이 감사 (auditable) 가능한 것을 공개하세요. 각 스킬은 설명, 예상되는 입력 (input), 출력 (outputs), 제한 사항 (limits) 및 인증 요구 사항 (authentication requirements)을 포함해야 합니다.

공개용 에이전트 카드 (Agent Card)에는 발견 (discovery)을 위한 최소한의 정보, 즉 이름, 버전, 엔드포인트 (endpoint), 기능 (capabilities), 지원 프로토콜 (supported protocols), 인증 (auth) 및 민감하지 않은 스킬 (skills)이 포함되어야 합니다. 내부 세부 정보를 노출해야 하는 경우, 인증된 확장 에이전트 카드 (extended Agent Card)를 사용하세요. 사양 (specification)은 인증 수준에 따라 추가 정보를 반환하기 위한 확장 카드를 고려하고 있습니다.

구현을 위해 task_id, client_id, skill_id, state, created_at, updated_at, expires_at, input_hash, artifact_refs 및 audit_log_ref를 포함하는 agent_tasks 테이블을 생성하세요. 이틀 전의 작업 (task)에 대해 무슨 일이 일어났는지 답변할 수 없다면, 아직 진지한 A2A 서버를 갖춘 것이 아닙니다.

구현 체크리스트 (Checklist)

• 단일 초기 스킬과 그 입/출력 계약 (input/output contract)을 정의합니다.
• 최소한의 버전 관리된 에이전트 카드 (Agent Card)를 공개합니다.
• 에이전트 카드 (Agent Card), 메시지 (Message), 작업 (Task), 파트 (Part) 및 아티팩트 (Artifact)의 스키마 (schema)를 검증합니다.
• 민감한 데이터를 포함한 작업을 수락하기 전에 인증 (authentication)을 요구합니다.
• 작업 상태 (task states), 취소 (cancellation) 및 타임아웃 (timeouts)을 구현합니다.
• 아티팩트 (artifacts)를 로그 (logs)와 분리하고 명시적인 보존 정책 (retention)을 적용합니다.
• 사용자에게 실제 가치를 제공하는 경우에만 스트리밍 (streaming)을 추가합니다.
• 외부 에이전트에 의존할 때는 에이전트 카드 (Agent Cards)에 서명하거나 검증합니다.
• 누가, 어떤 작업을, 어떤 에이전트에게, 어떤 권한 (permissions)으로 위임했는지 기록합니다.
• 실패 사례를 테스트합니다: 느린 에이전트, 중복된 작업, 유효하지 않은 페이로드 (payload) 및 취소된 자격 증명 (credential).

보안: 에이전트 카드 (Agent Card) 또한 악성 입력 (hostile input)이 될 수 있습니다

순진한 실수는 Agent Card (에이전트 카드)를 무해한 문서로 취급하는 것입니다. 실제로 외부 에이전트나 디렉토리는 다른 에이전트에 영향을 미치도록 설계된 설명, 태그, 예시 또는 메타데이터를 게시할 수 있습니다. A2A 보안 연구에서는 Agent Card 스푸핑 (spoofing), 태스크 리플레이 (task replay), 권한 상승 (privilege escalation), 프롬프트 인젝션 (prompt injection) 및 승인되지 않은 데이터 흐름과 같은 위험을 언급합니다.

A2A v1.0은 JWS를 통한 Agent Card 서명 검증 및 JSON 정규화 (canonicalization), 더 풍부한 보안 선언, 상호 TLS (mutual TLS) 지원, 현대적인 OAuth 흐름, PKCE 및 페이지네이션 (pagination)을 통해 기반을 강화합니다. 하지만 구현 단계에서 모든 카드를 수락하거나, 테넌트 (tenant) 데이터를 혼합하거나, 원격 설명을 메인 에이전트의 프롬프트에 직접 노출한다면 이러한 기능만으로는 안전을 보장할 수 없습니다.

Agent Card와 Artifacts (아티팩트)를 외부 입력 (input)으로 취급하십시오: 스키마 (schema)를 검증하고, 프롬프트에 넣기 전에 텍스트를 정제 (sanitize)하며, 크기를 제한하고, 출처를 확인하고, 버전을 기록하며, 도메인 허용 목록 (allowlist)을 적용하고, 스킬 (skill)별로 권한을 분리하십시오. 연합 에이전트 (federated agent)가 귀하의 내부 도구 (tools)를 자동으로 상속받아서는 안 됩니다.

A2A를 사용해야 할 때와 사용하지 말아야 할 때

내부 에이전트 마켓플레이스, 부서 간 조정, 공급업체의 전문 에이전트, 긴 백오피스 (backoffice) 흐름, 도메인 간 핸드오프 (handoff)가 필요한 고객 서비스, 또는 에이전트가 내부 구현을 알지 못해도 다른 에이전트에게 위임해야 하는 시스템의 경우 A2A 사용을 권장합니다.

단순한 API 래퍼 (wrapper), 결정론적 (deterministic) 함수, 내부 스크립트, 데이터베이스 쿼리, 문서 검색 (retrieval) 또는 자체 상태 (state)가 필요하지 않은 자동화에는 사용하지 마십시오. 그러한 경우에는 MCP, OpenAPI, 일반적인 큐 (queue) 또는 잘 설계된 HTTP 호출이 대개 더 단순하고 감사 (auditable)하기 쉽습니다.

결정을 위한 질문은 다음과 같습니다: "상대방이 추론하고, 상태를 유지하며, 작업 과정에서 아티팩트 (artifacts)를 생성할 수 있는가?" 만약 대답이 '아니오'라면, A2A는 과잉 설계 (overarchitecture)일 가능성이 높습니다.

관측성 (Observability) 및 거버넌스 (Governance)

건강한 A2A 배포를 위해서는 HTTP 트레이스 (traces) 이상의 것이 필요합니다. 어떤 에이전트가 작업을 요청했는지, 어떤 에이전트 카드 (Agent Card)가 사용되었는지, 어떤 버전의 스킬 (skill)이 작업을 수락했는지, 어떤 데이터가 경계를 넘었는지, 어떤 아티팩트 (artifacts)가 생성되었는지, 어떤 권한이 활성화되어 있었는지, 그리고 민감한 작업이 있었을 경우 누가 결과를 승인했는지에 대해 답할 수 있어야 합니다.

스킬별 작업 완료, 취소, 만료 및 실패율; p50/p95 지연 시간 (latency); 아티팩트 바이트 수; 정책 거부 또는 차단; 원격 에이전트에 의해 수행된 내부 도구 호출; 그리고 필요한 인간의 검토 (human reviews)를 측정하십시오. 단순히 위임 횟수만 측정한다면, 아무도 검토하지 않는 작업을 축하하고 있는 것일 수도 있습니다.

실용적인 거버넌스 (Governance): 승인된 에이전트 디렉토리, 에이전트 카드별 소유자 (owner), 자격 증명 (credentials) 만료, 스킬의 정기적 검토, 테넌트 (tenant)별 제한, 그리고 제공자별 킬 스위치 (kill switch)를 구축하십시오. A2A는 상호 운용성 (interoperability)을 용이하게 하지만, 어떤 에이전트가 신뢰할 만한지 대신 결정해주지는 않습니다.

흔한 실수

• 첫 번째 실수는 모든 웹훅 (webhook)을 A2A라고 부르는 것입니다. 에이전트 카드 (Agent Card), 작업 (tasks), 인증 (authentication), 상태 (state), 그리고 상호작용 계약 (interaction contract)이 없다면, 그것은 아마도 단순한 API일 뿐입니다.
• 두 번째 실수는 너무 광범위한 스킬을 공개하는 것입니다. general_coding_agent는 강력해 보이지만 검토하기가 매우 어렵습니다. 범위가 넓은 스킬은 데이터, 권한 및 기대치를 제한하는 것을 더 어렵게 만듭니다.
• 세 번째 실수는 발견 (discovery)과 신뢰 (trust)를 혼동하는 것입니다. 에이전트 카드 (Agent Card)를 찾는 것이 해당 에이전트가 합법적이거나, 최신 상태이거나, 귀하의 테넌트 (tenant)에 대해 권한이 있음을 의미하지는 않습니다.
• 네 번째 실수는 보존 (retention)을 잊는 것입니다. 아티팩트 (artifacts)와 메시지에는 민감한 데이터가 포함될 수 있습니다. 데이터가 얼마나 오래 유지되는지, 누가 읽을 수 있는지, 그리고 어떻게 삭제되는지를 정의하십시오.

결론

A2A 프로토콜 (A2A Protocol)은 팀, 제공업체 또는 플랫폼 간에 멀티 에이전트 (multi-agent) 시스템을 구축하고 있다면 매우 진지한 구성 요소입니다. 그 가치는 MCP를 대체하는 데 있는 것이 아니라, 내부 도구를 노출하고 싶지 않거나 노출할 수 없는 에이전트들 사이의 상태 유지 협업 (stateful collaboration)이라는 별도의 계층을 다루는 데 있습니다.

확인해야 할 사항

저의 권장 사항은 작게 시작하는 것입니다: 하나의 에이전트, 하나의 스킬, 최소한의 에이전트 카드 (Agent Card), 강력한 인증 (auth), 지속되는 작업 (persisted tasks), 유용한 로그, 그리고 민감한 작업에 대한 인간의 검토 (human review)를 갖추는 것입니다. 이것이 가치를 제공한다면 확장하십시오. 그렇지 않다면 MCP나 일반적인 API로 돌아가십시오. 기술적 성숙도는 보안과 추적 가능성 (traceability)을 유지하면서 가장 단순한 계층을 선택하는 데 있습니다.

자주 묻는 질문 (FAQ)

A2A 프로토콜이란 무엇인가요?

A2A 프로토콜은 독립적인 AI 에이전트들이 서로를 발견하고, 통신하며, 상태가 있는 (stateful) 작업에서 협업할 수 있도록 하는 개방형 표준입니다.

A2A 프로토콜이 MCP를 대체하나요?

아니요. A2A와 MCP는 상호 보완적입니다. A2A는 에이전트 간의 협업을 위해 사용되며, MCP는 에이전트가 도구와 리소스를 사용하는 데 사용됩니다.

A2A에서 에이전트 카드 (Agent Card)란 무엇인가요?

에이전트 카드는 에이전트의 정체성, 엔드포인트 (endpoint), 역량, 스킬, 그리고 인증 요구 사항을 기술하는 JSON 문서입니다.

A2A는 JSON-RPC를 사용하나요?

네. 1.0 사양은 JSON-RPC, gRPC, 그리고 HTTP+JSON에 대한 바인딩 (bindings)을 정의하며, 이들 사이에는 기능적 동등성이 보장됩니다.

언제 A2A를 사용해야 하나요?

상태, 자체 역량 및 아티팩트 (artifacts)를 가진 다른 자율 에이전트에게 작업을 위임할 때 사용하십시오. 단순한 함수 호출 (function call)을 위한 것이 아닙니다.

A2A의 보안 리스크에는 어떤 것들이 있나요?

주요 리스크로는 에이전트 카드 스푸핑 (Agent Card spoofing), 메타데이터에 대한 프롬프트 인젝션 (prompt injection), 작업 재전송 (replay), 과도하게 넓은 권한, 아티팩트 유출, 그리고 외부 에이전트에 대한 자동화된 신뢰 등이 있습니다.

출처 및 참고 문헌