Velog
Agent2Agent (A2A) 프로토콜은 무엇인가요?
구글의 A2A 는 에이전트 간 통신 표준. JSON-RPC + 에이전트 카드 + 작업(Task) 상태 머신으로 "각자 다른 에이전트에게 일을 넘기는" 일을 표준화한다. MCP 의 빈 자리 를 메운다.
핵심 요약
A2A 의 핵심 4요소:
| 요소 | 역할 | 비유 |
|---|---|---|
| Agent Card | 에이전트의 명함(능력·인증·엔드포인트) | 채용 공고 + 명함 |
| Task | 비동기 작업 단위, 상태 머신 | 발주서 |
| Message | 작업 진행 중 양방향 텍스트 메시지 | 카카오톡 메시지 |
| Artifact | 작업 산출물(파일·스트림) | 납품물 |
역할 분리:
- 클라이언트 에이전트: 일을 시킨다 —
createTaskJSON-RPC 호출, 입력 추가 가능 - 원격 에이전트: 일을 한다 —
TaskStatusUpdate/TaskArtifactUpdate이벤트 스트림
흐름:
1) 클라 → /agent-card 검색 → 능력/인증 확인
2) 클라 → POST createTask → task id
3) 원격 → SSE 로 status/artifact 스트리밍
4) 필요 시 클라 → 추가 input 메시지
5) 원격 → completed | failed | canceled 로 종료
중요한 점: 단방향 통신 — 원격은 클라이언트를 콜백할 수 없고, 단지 input-required 상태로 클라에게 질문 만 가능.
A2A 의 멘탈 모델은 "한 에이전트 안의 도구 호출(MCP) vs 에이전트 간 작업 위임(A2A)" 으로 갈린다.
- MCP: 한 LLM 이 자기 회사 도구 를 호출하기 위한 스키마 — 사내 핸드북
- A2A: 다른 에이전트에게 작업 자체 를 넘기기 위한 통신 프로토콜 — 회사 간 휴게실 잡담
두 프로토콜은 경쟁이 아니라 계층이 다르다. MCP 가 도구·함수 호출이라면 A2A 는 비동기 작업/스트리밍/인증을 포함한 프로세스 간 통신.
에이전트 도입은 이미 "시작" 단계가 아니라 "통합" 단계다. 회사마다 자체 에이전트가 있고, 이걸 다른 회사/팀의 에이전트와 묶으려 할 때 다음 통증이 반복된다.
- 핸드오프 JSON 형식이 깨지면 체인 전체 실패
- 모든 에이전트가 자체 인증 — 보안팀 승인 폭증
- SDK 락인으로 특정 클라우드에 묶임
A2A 는 이 셋을 표준화 후보로 끌어올린다. 면접에서 "AI 에이전트 시스템 설계해보세요" 는 더 이상 모델 선택만의 질문이 아니라 에이전트 간 통신/관찰가능성/보안 까지 묻는 질문으로 확장된다.
학습 포인트
면접 답변으로 연결할 학습 포인트입니다.
MCP 가 채울 수 없던 자리
MCP 는 한 에이전트가 자기 도구를 호출 하기 위한 스키마다. 좋은 사례지만 다음을 처리하지 않는다.
- 검색: 다른 에이전트가 누군지 어떻게 찾나?
- 인증: 두 에이전트가 서로 어떤 토큰을 받아들이나?
- 장기 작업: 5초가 아닌 5분짜리 일을 어떻게 추적하나?
- 스트리밍: 진행률·중간 산출물을 어떻게 흘리나?
A2A 는 이 네 항목을 프로토콜 차원 에서 정의해 MCP 위에 얹는다. "MCP = 도구함, A2A = 사내 메신저" 비유가 정확.
"A2A 가 MCP 를 대체한다" 는 인식. 둘은 계층이 다르고 자주 함께 쓰인다.
Task 는 상태 머신 — 비동기·재시도·취소가 1급
작업은 단순 "요청-응답" 이 아니라 명확한 상태 그래프를 갖는다.
submitted → working ↔ input-required → completed
↓
failed | canceled
클라이언트는 상태 변화 이벤트 를 SSE 로 받고, 필요 시 추가 입력을 넣는다. 즉 A2A 는 "비동기 + 휴먼-인-더-루프" 가 기본 가정. 동기 호출처럼 쓰려면 클라이언트가 종료 상태까지 폴링/스트리밍을 책임진다.
Task 를 동기 RPC 처럼 다뤄 5분짜리 작업 을 단일 HTTP 응답으로 기다리려는 시도. 대부분의 게이트웨이 타임아웃에 막힌다.
보안·관찰가능성의 책임 분리
A2A 는 "누가 일을 시켰는지(클라)" + "누가 일을 했는지(원격)" 를 분리한다. 이것이 다음을 가능하게 한다.
- 최소 권한: 클라이언트는 자기 토큰으로 인증, 원격은 자기 자원에 대한 권한만 위임
- 추적: 모든 task 에 id 가 있어 분산 추적 자연스러움
- 비용 분리: 원격 에이전트는 자기 LLM 호출 비용을 자기 청구
표준 인증 메커니즘(OAuth2, mTLS) 이 카드에 명시되므로 보안팀 승인 없이 바로 통합 하기 어려운 SaaS 락인을 우회한다.
원격 에이전트에 클라 토큰을 그대로 넘겨 임시변통하는 것. 토큰 권한이 과대해지고 사고 시 경계가 흐려진다.
읽는 순서
- 1이론
A2A 의 4요소(Agent Card, Task, Message, Artifact)와 task 상태 머신을 노트에 그린다. MCP 와의 책임 분리를 한 문장으로 적는다.
- 2구현
Node.js + Express 로 작은 원격 에이전트를 만든다.
GET /agent-card,POST /tasks,GET /tasks/:id/events(SSE) 엔드포인트만 구현해 클라가 task 상태를 따라가게 한다. - 3실무
현재 프로젝트의 "외부 서비스 호출" 중 비동기/장기 실행 작업을 1개 골라, A2A 식으로 카드 + task + 이벤트 스트림 인터페이스를 설계해본다. 기존 fetch 기반과 비용·관찰가능성을 비교.
- 4설명
동료에게 "MCP 만으로 멀티 에이전트 시스템을 만들면 어떤 한계가 있는가" 를 5분 안에 설명한다. 검색·인증·장기 task·스트리밍 4축으로 답한다.
면접 연결 질문
[감점 답변] "둘 다 LLM 통신 프로토콜". [좋은 답변] MCP 는 한 에이전트가 자기 도구·데이터를 호출 하기 위한 스키마(함수 시그니처+권한). A2A 는 서로 다른 에이전트가 작업을 위임 하는 통신 프로토콜(검색·인증·작업 상태 머신·스트리밍 포함). 동시 사용 예: 클라이언트 에이전트가 사내 도구는 MCP 로 직접 호출, 외부 전문 에이전트(예: 디자인 자동화)에 작업 위임은 A2A 로.
[감점 답변] "표준이라 안전". [좋은 답변] (1) 인증: 카드에 표준 메커니즘(OAuth2, mTLS) 이 명시 → 보안팀이 정책으로 승인 가능. 직접 fetch 는 개별 검토. (2) 추적: task id 가 있어 분산 추적/감사 로그가 자연스러움. (3) 권한 분리: 클라/원격이 각자 토큰을 사용 → 사고 경계 명확. (4) 재시도/취소: 상태 머신이 표준이라 게이트웨이/큐 미들웨어가 일관 처리.
[감점 답변] "기다리면 됨". [좋은 답변] (1) 이벤트 스트림 끊김 대비 — SSE 가 끊기면 task id 로 재구독 또는 폴링으로 회복. (2) input-required 처리 — 원격이 추가 입력을 요청할 수 있으므로 휴먼-인-더-루프 또는 자동 응답 정책을 미리 정의. 보너스: 타임아웃/취소(cancelTask) 도 함께 설계.
자기 점검
"단순 요청-응답" 으로 보는 것. 실제로는 비동기 + 휴먼 인 더 루프 가 기본 가정.
"A2A 만 쓰면 충분" 이라는 단정. 사내 도구는 MCP 로도 충분한 경우가 더 많다.