🎯 에이전트 프로토콜

생태계 개요

N×M 통합 문제와 이를 푸는 3계층 프로토콜 스택의 조감

N×M 통합 문제

에이전트 10개 × 도구 10개 = 100개 커스텀 커넥터 — 표준이 없으면 조합 폭발

3계층 프로토콜 스택

각 프로토콜이 다른 "연결"을 담당 — 수직(도구) · 수평(에이전트) · 전면(사용자)

프로토콜 비교

같은 "연결"이라도 서로 다른 방향과 목적

MCP

에이전트가 도구를 호출하고 데이터를 읽는 표준 — Host·Client·Server 3계층

MCP 아키텍처

Host → Client → Server 3계층 구조 — JSON-RPC 2.0 위에서 동작

1. 1
   Host

   • AI 애플리케이션 (Kiro, Claude Code, Cursor 등)
   • 사용자의 요청을 받아 Client에 전달
   • 모델 추론과 UI를 담당
2. 2
   Client

   • Host 안에서 MCP 서버와 1:1 연결 유지
   • JSON-RPC 요청을 서버에 전송
   • 도구 목록 조회 (tools/list) + 도구 실행 (tools/call)
3. 3
   Server

   • 3가지 Primitive를 노출하는 프로세스
   • Tools: 모델이 호출할 수 있는 함수
   • Resources: 모델이 읽을 수 있는 데이터
   • Prompts: 재사용 가능한 템플릿
4. 4
   외부 시스템

   • API, DB, 파일시스템, SaaS 등
   • Server가 래핑하여 표준 인터페이스 제공
   • 에이전트는 외부 시스템 구현을 모름

3가지 Primitive

MCP 서버가 노출하는 3종류의 능력 — 도구·데이터·템플릿

전송 방식

로컬(stdio)과 원격(Streamable HTTP) — 환경에 맞게 선택

MCP 서버 코드

FastMCP로 3줄이면 완성되는 MCP 서버

from mcp.server.fastmcp import FastMCP

# 서버 생성 — 이름이 클라이언트에 노출됩니다
mcp = FastMCP("weather-server")

# 도구 등록 — 데코레이터만 붙이면 함수가 Tool이 됩니다
@mcp.tool()
def get_weather(city: str) -> str:
    """도시의 현재 날씨를 조회합니다."""
    # 외부 API 호출
    return f"{city}: 맑음, 24°C"

@mcp.resource("config://settings")
def get_settings() -> str:
    """서버 설정을 반환합니다."""
    return '{"unit": "celsius", "lang": "ko"}'

# 실행 — streamable-http로 원격 클라이언트 접속 허용
if __name__ == "__main__":
    mcp.run(transport="streamable-http")

A2A

독립 배포된 에이전트끼리 작업을 위임하고 결과를 받는 표준 — 발견에서 반환까지

A2A 핵심 개념

독립 에이전트가 서로를 발견하고, 작업을 위임하고, 결과를 받는 표준

1. 1
   Agent Card 발행

   • /.well-known/agent-card.json에 능력 선언
   • 이름, 설명, 지원 스킬, 인증 방식 명시
   • 다른 에이전트가 이 카드를 읽어 능력 발견
2. 2
   태스크 생성

   • calling agent가 JSON-RPC로 message/send 요청
   • Task ID 발급 → 상태 추적 시작
   • 입력 데이터를 Message Parts(text/file/data)로 전달
3. 3
   처리 (working)

   • called agent가 비동기로 작업 수행
   • SSE 스트리밍 또는 push notification으로 진행 보고
   • 중간 artifact(산출물)를 점진적으로 반환
4. 4
   결과 반환

   • 상태: completed / failed / canceled
   • 최종 artifact를 Message Parts로 반환
   • calling agent가 결과를 자기 컨텍스트에 통합

Task Lifecycle

태스크 상태 전이 — submitted에서 시작하여 completed/failed/canceled/rejected 터미널 상태로 종료

1. 1
   submitted

   calling agent가 message/send 호출
   Task 객체 생성 — 고유 ID 부여
   아직 처리 시작 안 됨

2. 2
   working

   called agent가 작업 수행 중
   SSE로 진행 이벤트 스트리밍 가능
   중간 산출물(artifact) 점진 반환

3. 3
   input-required

   추가 정보가 필요하여 대기
   calling agent에게 질문 전송
   응답 후 working으로 복귀

4. 4
   터미널 상태

   성공 completed — 최종 artifact
   실패 failed — 에러 메시지
   취소 canceled — tasks/cancel 요청
   거절 rejected — called agent가 수행 거부

MCP vs A2A — 언제 무엇을

MCP = 도구 연결(수직), A2A = 에이전트 위임(수평) — 상호 보완적

AG-UI

에이전트 백엔드의 동작을 프론트엔드에 실시간 전달하는 표준 — SSE(대표 전송) 위의 typed 이벤트

AG-UI 개요

에이전트 백엔드의 모든 동작을 프론트엔드에 실시간으로 전달하는 이벤트 프로토콜

1. 1
   에이전트 실행

   • 백엔드에서 에이전트가 작업 수행
   • Strands Agent, LangGraph 등 어떤 프레임워크든
   • 실행 중 이벤트를 AG-UI 포맷으로 방출
2. 2
   SSE 스트리밍

   • Server-Sent Events로 이벤트 전송
   • messages, tool_calls, state_patches, lifecycle
   • 단일 HTTP 연결로 모든 이벤트 전달
3. 3
   프론트엔드 수신

   • React/Vue/Svelte 등 프론트엔드가 이벤트 소비
   • 채팅 UI 실시간 업데이트
   • 상태 동기화 — 에이전트 상태를 UI에 반영

AG-UI 이벤트 유형

에이전트 동작의 모든 단면을 이벤트로 표현

AG-UI vs 일반 채팅 API

단순 텍스트 스트리밍을 넘어, 에이전트의 전체 동작을 UI와 동기화

선택 가이드

연결 대상이 무엇인지에 따라 프로토콜을 고르고 조합하는 판단 기준

의사 결정 흐름

무엇을 연결하려는지에 따라 결정되는 프로토콜

1. 1
   도구/데이터를 연결?

   • 외부 API, DB, 파일에 접근해야 하는가?
   • → MCP 서버를 만들어 에이전트에 연결
   • 가장 먼저, 가장 자주 필요한 프로토콜
2. 2
   다른 에이전트에 위임?

   • 독립 배포된 전문 에이전트에게 작업을 맡기는가?
   • 결과를 비동기로 받아도 되는가?
   • → A2A로 에이전트 간 태스크 위임
3. 3
   사용자 UI와 연동?

   • 에이전트 동작을 실시간으로 보여줘야 하는가?
   • 공유 상태(장바구니, 폼 등)를 동기화해야 하는가?
   • → AG-UI로 프론트엔드 이벤트 스트리밍

프로토콜 조합 패턴

실제 프로덕션에서 세 프로토콜이 한 아키텍처에 공존 — 기반(MCP) · 확장(A2A) · 표면(AG-UI)

1. 1
   MCP (기반)

   • 모든 에이전트가 도구를 사용 — 기본 레이어
   • Gateway로 중앙 관리 + 인증 + 관측
   • 예: 날씨 API, DB 쿼리, 파일 읽기
2. 2
   A2A (확장)

   • 전문 에이전트를 팀처럼 조직
   • 오케스트레이터가 specialist에게 위임
   • 예: 코드 리뷰어, 보안 스캐너, 번역기
3. 3
   AG-UI (표면)

   • 최종 사용자에게 에이전트를 노출
   • 채팅, 대시보드, 코파일럿 UI
   • 예: Streamlit + CopilotKit + React

도입 순서

모든 것을 한 번에 갖출 필요 없는 단계적 도입 순서