AI 에이전트에 기능을 붙이기 시작하면 곧 연결 문제가 나온다. 파일을 읽게 하고, 내부 API를 호출하게 하고, 다른 에이전트에게 작업을 맡기고 싶어진다. 처음에는 이 연결을 모두 tool calling이라고 생각했다.
그런데 MCP와 A2A 글을 같이 읽어보니 둘은 비슷한 JSON 메시지를 사용해도 해결하려는 경계가 달랐다. MCP는 에이전트가 도구와 resource를 발견하고 사용하는 쪽에 가깝고, A2A는 내부 구현을 모르는 다른 에이전트와 task를 주고받는 쪽에 가깝다.
이번에는 MCP 2026-07-28 명세 소개, A2A 협업 글, Agent Protocol 가이드를 읽으면서 어디에 어떤 프로토콜이 필요한지 정리했다.
MCP Specification — 에이전트와 도구 사이의 계약
MCP에서는 client가 server가 제공하는 tool, resource, prompt를 발견하고 정해진 schema로 호출한다. 모델이 직접 database 연결 방법이나 파일 형식을 알지 않아도 server가 공개한 계약을 통해 기능을 사용할 수 있다.
사용자
→ Agent / MCP Client
→ MCP Server
→ Tool
→ Resource
→ Prompt
2026-07-28 명세 소개에서는 stateless transport, authorization, 요청 식별 header, caching처럼 실제 운영 연결에 필요한 부분이 다뤄졌다. tool 이름과 parameter schema만 맞추는 데서 끝나지 않고 요청의 인증과 수명, 재사용 가능성을 더 명시하는 방향이다.
tool 하나를 아주 단순하게 줄이면 다음과 같은 모양이 된다.
{
"name": "read_order",
"description": "주문 상태를 읽습니다.",
"inputSchema": {
"type": "object",
"properties": {
"order_id": { "type": "string" }
},
"required": ["order_id"]
}
}
schema가 있다는 사실은 중요하지만 안전을 보장하지는 않는다. order_id가 string이라는 건 알 수 있어도 현재 사용자가 그 주문을 볼 수 있는지, 운영 환경 호출이 허용됐는지, 결과에서 어떤 필드를 가려야 하는지는 server와 애플리케이션 정책이 결정해야 한다.
MCP server를 만들 때 tool 구현보다 먼저 적어야 할 내용은 이쪽이라고 생각한다.
| 경계 | 결정할 내용 |
|---|---|
| 대상 | DEV, STG, PRD 중 어디를 읽는가 |
| 권한 | 사용자와 agent가 어떤 resource에 접근 가능한가 |
| 부작용 | read-only인지 외부 상태를 바꾸는지 |
| 증거 | 호출 결과와 실패를 어디까지 남기는가 |
| 비밀 | token과 credential을 누가 주입하고 가리는가 |
A2A Collaboration — 다른 에이전트에게 작업을 맡기는 계약
A2A는 다른 에이전트의 내부 tool을 하나씩 호출하는 대신 상대가 제공하는 capability를 확인하고 task를 전달하는 쪽에 가깝다. 상대가 어떤 모델과 framework를 쓰는지 몰라도 message, task 상태, artifact라는 계약을 통해 협력할 수 있다.
Agent A
→ Agent Card로 capability 확인
→ Task와 Message 전달
→ Agent B가 자체 도구로 처리
← 상태 갱신과 Artifact 반환
이 차이는 책임을 나눌 때 중요하다. MCP tool은 대체로 호출자가 작업 흐름을 조정한다. A2A task는 상대 에이전트가 내부 계획과 도구 선택을 맡을 수 있다. 그래서 A2A에서는 시작, 진행 중, 입력 대기, 완료, 실패 같은 task 수명과 긴 작업의 재개가 더 중요해진다.
예를 들어 코드 분석 에이전트와 문서 작성 에이전트를 연결한다고 하자. 문서 에이전트가 코드 저장소의 모든 tool을 직접 사용할 수도 있다. 하지만 분석 에이전트에게 “이 변경의 API 영향과 증거를 정리해 달라”는 task를 보내고 결과 artifact만 받으면 각 에이전트의 권한과 책임을 나누기 쉽다.
반대로 같은 프로세스 안에서 단순히 함수 두 개를 순서대로 실행하는데 A2A를 넣으면 task 상태와 네트워크 실패만 늘어난다. 독립적으로 배포되고 서로 내부 구현을 숨겨야 하는 경계인지가 먼저다.
Protocol Map — 연결 이름보다 먼저 볼 문제
Agent Protocol 가이드는 여러 프로토콜을 각자 다른 상호작용 층으로 나눠 소개한다. 여기서 얻은 가장 큰 힌트는 “어떤 프로토콜이 더 좋은가”보다 “지금 막힌 연결이 어느 종류인가”를 먼저 묻는 것이다.
모델 ↔ 도구와 데이터 : MCP
에이전트 ↔ 다른 에이전트 : A2A
에이전트 ↔ 사용자 화면 : UI 상호작용 프로토콜
에이전트 ↔ 결제와 위임 : 별도 권한·거래 프로토콜
한 제품 안에서 둘을 같이 사용할 수도 있다. 예를 들어 coordinator agent가 A2A로 배포 분석 agent에게 task를 맡기고, 분석 agent가 MCP로 Git과 build 결과를 읽는 구조다.
Coordinator Agent
└─ A2A Task → Deployment Analyst
├─ MCP Tool → Git reader
├─ MCP Tool → Build status reader
└─ Artifact → evidence report
이 그림에서 A2A가 MCP를 대체하지 않고 MCP도 A2A를 대체하지 않는다. 서로 다른 경계에 놓인다. 다만 프로토콜이 두 개가 되면 인증과 추적이 끊길 수 있으므로 사용자 요청 ID, task ID, tool call ID를 연결할 방법이 필요하다.
Tool Boundary — 프로토콜보다 먼저 둘 안전장치
프로토콜을 붙이면 agent가 더 많은 일을 할 수 있다. 하지만 실제 업무에서 중요한 건 할 수 있는 일의 수보다 멈춰야 할 위치였다. 읽기와 쓰기, 로컬 변경과 외부 변경, DEV와 PRD를 같은 tool 목록에 평평하게 두면 모델이 판단해야 할 위험이 너무 커진다.
처음에는 read-only tool만 노출하는 게 좋다.
tool: inspect_build
environment: dev
side_effect: none
inputs:
build_id: string
outputs:
status: string
artifact_sha: string
checked_at: datetime
외부 상태를 바꾸는 tool은 호출 전 승인과 중복 실행 방지, 실행 후 readback을 별도 계약으로 둬야 한다.
요청 해석
→ 대상과 권한 확인
→ 실행 계획 표시
→ 사용자 승인
→ idempotency key 기록
→ 외부 작업 실행
→ 결과 readback
→ 증거와 남은 위험 보고
MCP authorization이 있어도 업무 승인 정책 전체를 대신하지는 않는다. 연결된 client가 누구인지 확인하는 것과 특정 운영 배포를 지금 실행해도 되는지는 다른 질문이다. A2A로 task를 보낼 수 있어도 상대 에이전트가 고객 데이터에 접근해도 된다는 뜻은 아니다.
또한 tool 결과를 자연어 한 줄로만 돌려주면 상위 agent가 완료 여부를 다시 확인하기 어렵다. 결과에는 상태, 확인 시각, 대상 식별자, 증거 위치, 실패 종류처럼 기계적으로 읽을 수 있는 필드가 필요하다.
내가 실제로 도입한다면 다음 순서로 범위를 넓힐 것 같다.
- 공식 문서와 코드 검색 같은 read-only MCP tool
- 결과에 출처와 확인 시각을 포함하는 공통 envelope
- 실패해도 부작용이 없는 분석 task의 A2A 위임
- 긴 task의 중단, 입력 대기, 재개 처리
- 제한된 로컬 파일 변경과 diff 검증
- 별도 승인 경계가 있는 외부 상태 변경
MCP와 A2A를 읽고 나니 프로토콜을 도입한다는 말이 조금 더 구체적으로 들린다. 도구를 연결하려는 건지, 독립 에이전트에게 책임을 넘기려는 건지, 사람과 상호작용하려는 건지에 따라 필요한 계약이 다르다.
프로토콜은 연결 방법을 표준화하지만 좋은 권한 설계와 복구 절차를 자동으로 만들어 주지는 않는다. 다음 에이전트 기능을 만들 때는 server나 agent 수부터 늘리지 않고, 어떤 경계를 넘는 호출인지와 실패했을 때 누가 다시 확인할지를 먼저 정해보려고 한다.