Section 1분산 에이전트의 핵심 개념
지금까지 우리는 모든 구성 요소가 동일한 실행 컨텍스트에서 동작한다고 가정했다. 그러나 실세계 응용은 분산 아키텍처를 요구한다 — 에이전트와 툴이 서로 다른 머신·컨테이너·리전·조직에 존재하며 네트워크로 통신한다.
발견·통신·결함 내성·조율 — 이들은 고전적인 분산 컴퓨팅 문제다. 그러나 에이전트는 새로운 특성을 도입한다 — 의사결정의 자율성, 수 시간~수일에 걸친 장시간 실행, 예측 불가능한 시점의 인간 입력 요구, AI 모델이 추동하는 적응적 행동.
전통적 분산 컴퓨팅에서 조율·의사결정은 인프라 계층에 거주한다 — Kubernetes, 서비스 메시, API 게이트웨이. 분산 에이전트 시스템에서는 이 로직이 애플리케이션 계층으로 이동하며, 자율적 결정을 내리는 AI 모델이 추동한다.
| 전통적 원시 요소 | 에이전트 변형 |
|---|---|
| 메시지 큐 | 작업 위임 — AI가 작업 상태를 추론해 적응적으로 도움을 요청 |
| 서비스 디스커버리 | 에이전트 디스커버리 — 풍부한 역량 메타데이터로 의미론적 라우팅 |
| 서킷 브레이커·재시도 | 결함 내성 — 세션 재개 가능성과 영속적 작업 상태 |
| API 게이트웨이 | 오케스트레이션 — AI 기반 추론으로 요청 분해·라우팅·종합 |
분산 에이전트의 네 가지 핵심 능력 — 자율성, 장시간 실행, 상호작용성, 적응적 행동. 두 프로토콜이 이를 구현한다 — MCP(툴·컨텍스트 통합 표준화)와 A2A(조직 간 협업).
Section 2MCP — 모델 컨텍스트 프로토콜
2024년 11월 Anthropic이 MCP를 소개했을 때 초점은 좁았다 — LLM에 표준화된 방식으로 컨텍스트에 접근하게 한다. AI 애플리케이션("클라이언트")이 외부 시스템("서버")에 연결되어 툴·리소스·프롬프트를 노출하는 방법을 정의했다.
| 계층 | 역할 |
|---|---|
| MCP 서버 | 능력 노출 — 툴(호출할 함수), 리소스(읽을 데이터), 프롬프트(재사용 템플릿) |
| MCP 클라이언트 | 서버와 1:1 연결 — 메시지 교환·세션 상태·오류 처리. 호스트 안에 내장 |
| MCP 호스트 | 사용자 대면 앱(Claude Desktop, Cursor, VSCode) — 전체 워크플로우 오케스트레이션 |
MCP는 에이전트적 능력을 더해 왔다 — 진행 알림(실시간 상태 스트리밍), 재개 가능 스트림(이벤트 재생으로 네트워크 단절 견딤), 리소스 링크(영속적 결과 참조), 일리시테이션(서버가 사용자 입력 요청), 샘플링(서버가 클라이언트의 LLM에 완성 요청). 이 요소들이 결합되면 단순 툴이 장시간 실행되고 상호작용하며 적응할 줄 아는 자율 에이전트로 탈바꿈한다.
전송 메커니즘 — stdio 전송(서버를 서브프로세스로, 로컬 통합에 이상적)과 스트리밍 가능한 HTTP 전송(원격 서버, 분산 시스템).
Section 3A2A — 에이전트 간 프로토콜
구글이 2025년 4월 발표하고 6월 리눅스 재단 거버넌스 아래 출범시킨 A2A는 분산 에이전트 통신에 태스크 중심 아키텍처로 접근한다. 모든 상호작용은 고유 식별자와 생명 주기 상태를 지닌 Task를 생성한다.
| 상태 범주 | 상태 |
|---|---|
| 활성 상태 | submitted · working — 진행 중인 작업 |
| 중단 상태 | input-required · auth-required — 추가 입력을 기다림 |
| 종결 상태 | completed · failed · canceled · rejected — 불변 |
잘 알려진 URI(/.well-known/agent-card.json)에 위치한 Agent Card가 역량·스킬·인증 요구를 사전 선언해 레지스트리 없이도 자율 탐색을 가능케 한다. contextId는 서로 관련된 여러 태스크에 걸쳐 상태를 유지한다 — "헬싱키행 항공편 예약"(완료) → "Task 1을 바탕으로 호텔 예약"(진행)처럼 의존 관계를 추론하게 한다.
A2A는 검증된 웹 표준 위에 선다 — HTTP(S), JSON-RPC 2.0, SSE 스트리밍, OAuth2·API 키·bearer 토큰. 페더레이션 모델 — 서로 다른 조직의 에이전트들이 명확한 경계와 자율성을 유지하며 협업한다.
Section 4보안 고려 사항
두 프로토콜 모두 표준 웹 보안 위에 서지만 각자의 사용 사례에 맞게 변형한다.
- MCP — 전송 계층에 따라 달라지는 보안. stdio는 환경 자격 증명, HTTP는 PKCE가 필수인 OAuth 2.1. 토큰 패스스루를 명시적으로 금지해 혼동된 대리인 공격을 방지한다.
- A2A — 통일된 HTTP 보안. Agent Card가 인증 스킴을 OpenAPI 호환 형식으로 선언한다. 인가는 스킬 기반 — OAuth 스코프가 특정 역량 접근을 부여한다(
booking:read,booking:write).
Section 5프로토콜 결정 내리기
MCP와 A2A는 겹치는 목표를 가지되 다른 추상화 수준에서 작동한다. MCP는 워크플로우로 조합할 수 있는 분산 컴포넌트에 대한 세밀한 제어를, A2A는 자율 에이전트에게 태스크 전체 위임을 제공한다.
| MCP를 선택하라 | A2A를 선택하라 |
|---|---|
| 분산된 세분화된 역량의 오케스트레이션 | 태스크 전체 위임 — 고수준 요청을 자급자족 에이전트에게 |
| 통제된 정보 흐름 — 각 툴이 받을 컨텍스트 결정 | 조직 간 블랙박스 — 구현을 드러내지 않는 파트너 에이전트 |
| 멀티 플랫폼 툴 — 한 번 작성, 어디서든 | 에이전트 마켓플레이스 — Agent Card로 완전한 솔루션 탐색 |
| 세밀한 디버깅·관측 가능성 | 이질적 프레임워크 간 페더레이션 협업 |
많은 시스템은 서로 다른 계층에서 두 프로토콜을 모두 쓴다 — 오케스트레이터는 자신의 내부 역량 조합에 MCP를(데이터베이스 접근·API 호출·계산), 외부의 자율 에이전트에게 전문 태스크 위임에 A2A를(법률 검토·의료 진단·재무 분석). MCP는 개별 역량 호출의 가시성·제어를, A2A는 자율 에이전트에게 태스크 전체 위임을 제공한다.