MCP는 AI 에이전트에게 도구를 주었지만, A2A는 동료를 줍니다

대부분의 AI 에이전트 대화는 결국 동일한 질문에 직면하게 됩니다:

하나의 에이전트만으로는 부족할 때 어떤 일이 벌어질까요?

단일 에이전트는 코드를 작성하고, 문서를 검색하며, 테스트를 실행하고, API를 호출하고, 파일을 요약하며, 보고서를 생성할 수 있습니다.

그것만으로도 이미 유용하게 느껴집니다.

하지만 실제 업무는 하나의 깔끔한 상자에 담기는 경우가 드뭅니다.

소프트웨어 프로젝트에는 다음과 같은 것들이 필요할 수 있습니다:

요구사항을 조사하는 에이전트 하나
코드를 작성하는 에이전트 하나
테스트를 생성하는 에이전트 하나
결과를 검토하는 에이전트 하나
시스템을 배포하거나 모니터링하는 에이전트 하나

고객 지원 워크플로(Workflow)에는 다음과 같은 것들이 필요할 수 있습니다:

결제 에이전트
기술 지원 에이전트
영업 에이전트
인간에게 업무를 인계하는 에이전트

콘텐츠 워크플로에는 다음과 같은 것들이 필요할 수 있습니다:

조사 에이전트
작성 에이전트
SEO 에이전트
편집자
발행 어시스턴트

그 시점에서 흥미로운 문제는 더 이상 다음과 같은 것이 아닙니다:

에이전트가 도구를 사용할 수 있는가?

그것은 다음과 같이 변합니다:

에이전트들이 서로 협업할 수 있는가?

이 지점이 바로 **A2A 프로토콜 (A2A protocol)**이 흥미로워지는 부분입니다.

그리고 이것이 Terminal Skills의 a2a-protocol 기술을 살펴볼 가치가 있는 이유입니다.

한 문장으로 보는 MCP vs A2A

MCP는 에이전트에게 도구를 주었습니다.

A2A는 에이전트에게 동료를 줍니다.

이것이 제가 생각하는 가장 단순한 방식입니다.

MCP, 즉 모델 컨텍스트 프로토콜 (Model Context Protocol)은 주로 에이전트를 도구, API, 파일, 데이터베이스, 검색 시스템 및 외부 데이터 소스에 연결하는 것에 관한 것입니다.

A2A, 즉 에이전트 투 에이전트 (Agent2Agent)는 한 에이전트를 다른 에이전트에 연결하는 것에 관한 것입니다.

이 차이는 중요합니다.

만약 에이전트가 데이터베이스를 쿼리하거나, 캘린더 API를 호출하거나, 리포지토리(Repo)를 조사해야 한다면 MCP가 적합합니다.

만약 에이전트가 고유한 역량, 상태(State), 작업 수명 주기(Task lifecycle), 출력 형식을 가진 다른 자율 에이전트에게 업무를 위임해야 한다면, A2A가 더 나은 사고 모델(Mental model)입니다.

도구는 보통 한 가지 특정한 일을 수행합니다.

에이전트는 업무의 전체 도메인을 소유할 수 있습니다.

에이전트에게 협업 레이어가 필요한 이유

현재 많은 에이전트 워크플로는 여전히 프롬프트(Prompts)로 이어져 있습니다.

다음과 같은 방식입니다:

먼저 주제를 조사하세요.
그 다음 초안을 작성하세요.
그 다음 검토하세요.
...

작은 작업에는 그런 방식이 효과적일 수 있습니다.

하지만 워크플로우 (Workflow)가 더 진지해지는 순간 상황은 복잡해집니다.

조사 작업에 5분이 소요된다면 어떻게 될까요?
작성 에이전트 (Writing agent)에게 문단이 아닌 구조화된 데이터 (Structured data)가 필요하다면 어떻게 될까요?
검토자 (Reviewer)가 결과물을 거절한다면 어떻게 될까요?
작업에 인간의 입력 (Human input)이 필요하다면 어떻게 될까요?
작업이 비동기적 (Asynchronously)으로 계속되어야 한다면 어떻게 될까요?

그 시점에는 프롬프트 체인 (Prompt chain)만으로는 충분하지 않습니다.

프로토콜 (Protocol)에 더 가까운 무언가가 필요합니다.

A2A 모델은 다음과 같은 개념들을 도입합니다:

발견 (Discovery)을 위한 에이전트 카드 (Agent Card)
선언된 기술 (Skills) 및 역량 (Capabilities)
작업 생명주기 상태 (Task lifecycle states)
에이전트 간 메시지 (Messages between agents)
출력물로서의 아티팩트 (Artifacts)
스트리밍 업데이트 (Streaming updates)
푸시 알림 (Push notifications)
취소 (Cancellation)
구조화된 데이터 교환 (Structured data exchange)

이것은 가장 긍정적인 의미에서 지루하게 들립니다.

지루한 프로토콜이야말로 데모를 인프라 (Infrastructure)로 바꾸는 핵심입니다.

에이전트 카드는 과소평가된 부분입니다

A2A에서 가장 유용한 아이디어 중 하나는 **에이전트 카드 (Agent Card)**입니다.

에이전트 카드는 기본적으로 에이전트가 무엇인지, 어디에 존재하는지, 그리고 무엇을 할 수 있는지에 대한 설명입니다.

에이전트의 내부 도구, 메모리(Memory) 또는 비공개 상태(Private state)를 노출하지 않으면서 정체성, 역량, 기술, 엔드포인트(Endpoints) 및 인증(Auth)을 설명합니다.

다음 내용을 포함할 수 있습니다:

에이전트 이름
설명
엔드포인트 URL
버전
역량 (Capabilities)
기술 (Skills)
입력 모드 (Input modes)
출력 모드 (Output modes)
인증 요구 사항 (Authentication requirements)

다음과 같은 표준 발견 엔드포인트 (Discovery endpoint)는:

/.well-known/agent-card.json

그리 흥미롭게 들리지 않을 수도 있습니다.

하지만 이는 실제 문제를 해결합니다.

에이전트들이 협업하려면, 자신들이 누구와 대화하고 있는지 알아야 합니다.

코딩 에이전트 (Coding agent)는 코드 리뷰 에이전트 (Code review agent)를 발견할 수 있어야 합니다.
지원 라우터 (Support router)는 결제 에이전트 (Billing agent)를 발견할 수 있어야 합니다.
조사 에이전트 (Research agent)는 작성 에이전트 (Writer agent)를 발견할 수 있어야 합니다.

발견 레이어 (Discovery layer)가 없다면, 모든 멀티 에이전트 워크플로우는 맞춤형 접착제 (Custom glue)가 되어버립니다.

발견 레이어가 있다면, 에이전트들은 서비스 (Services)처럼 동작하기 시작할 수 있습니다.

예시: 에이전트로 구성된 코드 파이프라인

간단한 소프트웨어 파이프라인을 상상해 보세요.

모든 것을 수행하는 하나의 거대한 에이전트를 원하지는 않을 것입니다.

대신, 워크플로 (workflow)를 다음과 같이 나눕니다:

코드 작성자 (Code writer): 구현 코드를 생성합니다.
테스트 작성자 (Test writer): 테스트를 생성합니다.
코드 리뷰어 (Code reviewer): 두 가지 모두를 검토합니다.
오케스트레이터 (Orchestrator): 흐름을 조정합니다.

각 에이전트는 좁은 범위의 책임을 가질 수 있습니다.

코드 작성자는 테스트 전략에 대한 모든 것을 알 필요가 없습니다.
테스트 작성자는 제품 요구사항 (product requirements)을 소유할 필요가 없습니다.
리뷰어는 초기 구현을 작성할 필요가 없습니다.

이는 워크플로를 검사하기 더 쉽게 만듭니다.

테스트가 약하다면, 테스트 에이전트를 개선하십시오.
리뷰가 얕다면, 리뷰 에이전트를 개선하십시오.
인수인계 (handoff)가 실패한다면, 오케스트레이터를 개선하십시오.

이는 다섯 개의 숨겨진 역할이 포함된 하나의 거대한 프롬프트 (prompt)를 디버깅하는 것보다 훨씬 깔끔합니다.

예시: 고객 지원 라우터 (customer support router)

A2A는 고객 지원 (support) 분야에서도 타당합니다.

지원 라우터 에이전트가 고객 메시지를 받습니다:

두 번 결제되었는데 제 계정은 여전히 비활성 상태로 나옵니다.

라우터가 모든 것을 스스로 해결하려고 해서는 안 됩니다.

라우터는 다음과 같이 위임할 수 있습니다:

결제 질문 -> 결제 에이전트 (billing agent)
계정 활성화 -> 기술 에이전트 (technical agent)
환불 자격 -> 정책 에이전트 (policy agent)
불분명하거나 민감한 이슈 -> 사람에게 인수인계 (human handoff)

라우터의 역할은 분류 (classification), 조정 (coordination), 그리고 응답 조립 (response assembly)입니다.

특화된 에이전트들은 각자의 도메인 (domain)을 소유합니다.

이것이 실제 팀이 일하는 방식입니다.

모든 사람이 모든 일을 하지는 않습니다.

흥미로운 점은 에이전트들이 동일한 패턴을 따르도록 만드는 것입니다.

Terminal Skills가 적합한 위치

이 지점이 바로 Terminal Skills가 유용해지는 곳입니다.

a2a-protocol 스킬은 단순히 명세 (spec)로 연결되는 링크가 아닙니다.

이는 AI 코딩 에이전트에게 A2A 시스템을 구축하기 위한 실질적인 운영 가이드를 제공합니다:

언제 A2A를 사용할 것인가
에이전트 카드 (Agent Card)를 정의하는 방법
서버를 구축하는 방법
클라이언트를 구축하는 방법
작업 상태 (task states)를 처리하는 방법
언제 스트리밍 (streaming)을 사용할 것인가
여러 에이전트를 오케스트레이션 (orchestrate)하는 방법
A2A가 MCP와 어떻게 다른가
어떤 구현 가이드라인을 따라야 하는가

이것이 중요한 이유는 에이전트가 실패하는 원인이 지능의 부족이 아니라, 워크플로 구조 (workflow structure)의 부족인 경우가 많기 때문입니다.

모델은 일반적인 의미의 A2A를 이해할 수 있습니다.

하지만 기술 (skill)은 모델에게 반복 가능한 경로를 제공합니다:

terminal-skills install a2a-protocol

그 이후, 에이전트는 모호한 기억이나 일반적인 웹 지식에 의존하는 대신, 해당 작업에 대한 집중된 참조 (reference)를 갖게 됩니다.

이것이 Terminal Skills 이면에 있는 더 큰 아이디어입니다:

에이전트에게 필요한 것은 단순히 더 많은 컨텍스트 (context)가 아닙니다. 그들에게는 재사용 가능한 운영 지침 (operational instructions)이 필요합니다.

A2A는 MCP의 대체제가 아닙니다

모든 새로운 프로토콜을 승자 독식 방식의 비교 대상으로 만들고 싶은 유혹이 생길 수 있습니다.

하지만 저는 이것이 올바른 프레이밍 (framing)이라고 생각하지 않습니다.

A2A와 MCP는 서로 다른 문제를 해결합니다.

두 가지를 구분하는 실질적인 방법은 다음과 같습니다:

필요 사항	더 적합한 것
도구 또는 API 호출	MCP
...

MCP는 에이전트 대 도구 (agent-to-tool)입니다.

A2A는 에이전트 대 에이전트 (agent-to-agent)입니다.

실제 시스템에서는 아마도 두 가지 모두를 원할 것입니다.

에이전트가 도구에 접근하기 위해 내부적으로 MCP를 사용하는 동시에, 다른 에이전트가 작업을 위임할 수 있도록 A2A 인터페이스를 노출할 수 있습니다.

이러한 조합이 바로 흥미로운 지점입니다.

이것이 개발자에게 유용한 이유

개발자에게 가치는 프로토콜의 약어에 있는 것이 아닙니다.

가치는 취약한 워크플로 (fragile workflows)가 줄어든다는 데 있습니다.

모든 핸드오프 (handoff)를 하드코딩하는 대신, 다음과 같은 관점에서 생각하기 시작할 수 있습니다:

발견 가능한 에이전트 (discoverable agents)
선언된 역량 (declared capabilities)
명시적인 작업 상태 (explicit task states)
구조화된 메시지 (structured messages)
취소 가능한 작업 (cancellable work)
스트리밍 진행 상황 (streaming progress)
출력물로서의 아티팩트 (artifacts as outputs)

이는 프롬프트 엔지니어링 (prompt engineering)보다는 소프트웨어 엔지니어링 (software engineering)에 더 가깝습니다.

그리고 솔직히 말해서, 그것이 핵심입니다.

차세대 에이전트 시스템은 하나의 거대한 프롬프트로 구축되지 않을 것입니다.

그들은 명확한 계약 (contracts)을 바탕으로 연결된 전문 작업자들의 네트워크와 더 유사한 형태를 띨 것입니다.

그 작업자 중 일부는 도구를 호출할 것입니다.

일부는 다른 에이전트를 호출할 것입니다.

시스템의 품질은 특정 모델이 마법 같은 능력을 갖추었는지 여부보다, 핸드오프가 얼마나 잘 설계되었는지에 더 많이 좌우될 것입니다.

중요한 작은 변화

첫 번째 AI 에이전트(AI agents)의 물결은 모델에게 도구(tools)를 제공하는 것이었습니다.

그것은 거대한 진전이었습니다.

하지만 도구가 전부가 아닙니다.

에이전트가 실제 업무를 처리하려면 조정(coordination)이 필요합니다.
위임(delegation)이 필요합니다.
발견(discovery)이 필요합니다.
계약(contracts)이 필요합니다.
그리고 다음과 같이 말할 수 있는 방법이 필요합니다:

나는 이 작업을 수행할 수 있습니다.
나를 호출하는 방법은 다음과 같습니다.
내가 반환하는 값은 다음과 같습니다.
...

이것이 바로 A2A를 주목해야 하는 이유입니다.

모든 프로젝트가 오늘날 멀티 에이전트 아키텍처(multi-agent architecture)를 필요로 하기 때문이 아닙니다.

대부분은 그렇지 않습니다.

하지만 방향은 명확합니다:

에이전트는 고립된 비서에서 상호 운용 가능한 작업자(interoperable workers)로 이동하고 있습니다.

MCP는 에이전트에게 도구를 주었습니다.

A2A는 그들에게 동료를 줍니다.

그리고 a2a-protocol과 같은 기술(skills)은 에이전트가 빈 프롬프트(blank prompt)에서 시작하지 않고도 그러한 미래를 구축하는 방법을 배울 수 있도록 돕습니다.

직접 시도해보고 싶다면, 해당 기술은 여기에 있습니다:

https://terminalskills.io/skills/a2a-protocol

설치:

terminal-skills install a2a-protocol

그 다음, 당신의 코딩 에이전트(coding agent)에게 아주 작은 A2A 루프를 구축하도록 요청하세요: 에이전트 카드(Agent Card) -> 서버(server) -> 클라이언트(client) -> 위임된 작업(delegated task).

작게 시작하세요.

하나의 집중된 에이전트.
하나의 명확한 역량.
하나의 검증 가능한 핸드오프(handoff).

그것이 보통 진정한 워크플로(workflow)가 시작되는 지점입니다.