AG-UI 프로토콜 완전정복
MCP·A2A 다음 퍼즐, 지금 모르면 뒤처진다
AI가 도구를 쓰고(MCP), 에이전트끼리 대화하는(A2A) 시대는 이미 왔습니다.
그런데 정작 사용자 화면과 에이전트는 어떻게 연결될까요?
AG-UI 프로토콜이 그 마지막 1마일을 닫습니다.
오픈소스
이벤트 기반
12개 프레임워크 통합
한국어 최초 심층 분석
🧩 AG-UI 프로토콜이란? — 에이전트 생태계의 마지막 퍼즐
AG-UI 프로토콜(Agent–User Interaction Protocol)은 백엔드 AI 에이전트와 사용자 대면(프론트엔드) 애플리케이션 사이의 양방향 통신을 표준화하는 개방형 경량 이벤트 기반 프로토콜입니다. 2025년 5월 CopilotKit이 오픈소스로 공개했으며, 불과 1년도 되지 않아 Microsoft·Google·AWS를 포함한 주요 에이전트 프레임워크 12개 이상이 공식 지원에 합류했습니다.
이름이 생소하더라도 개념은 단순합니다. MCP가 에이전트와 외부 도구(데이터베이스, API, 파일시스템)를 연결하고, A2A가 서로 다른 에이전트끼리 협업하도록 한다면, AG-UI는 그 에이전트가 최종적으로 사람의 화면에 실시간으로 결과를 보여주고, 승인을 요청하고, 함께 편집하는 모든 상호작용을 담당합니다. 세 프로토콜이 모두 갖춰질 때 비로소 진정한 에이전틱 애플리케이션이 완성됩니다.
⚡ 왜 REST API로는 부족한가 — 에이전틱 앱의 4가지 난제
전통적인 웹 개발은 단순한 요청-응답 모델로 작동했습니다. 클라이언트가 요청을 보내면 서버가 데이터를 돌려주고, 클라이언트가 화면에 표시하는 것으로 끝이었습니다. 그런데 AI 에이전트는 이 모델을 근본적으로 깨뜨립니다.
LLM은 토큰을 점진적으로 생성합니다. 사용자는 전체 응답이 완성될 때까지 빈 화면을 볼 수 없습니다. 동시에 멀티턴 세션에서 에이전트는 수십 초에서 수분에 걸쳐 작업을 수행하며, 그 과정에서 중간 상태를 UI에 계속 전달해야 합니다. 기존 REST API는 이 실시간 스트리밍 요구를 충족시키지 못합니다.
에이전트는 작업 중에 화면 구성 요소를 동적으로 바꿔야 할 때가 있습니다. 코드 실행 진행률 바를 보여주거나, 검색 결과를 테이블로 렌더링하거나, 승인 버튼을 팝업시키는 것이 그 예입니다. 이처럼 비결정론적으로 UI를 제어하는 행위를 기존 REST/GraphQL로 구현하려면 엄청난 커스텀 로직이 필요합니다.
에이전트는 텍스트·음성·도구 호출 결과·상태 업데이트를 동시에 뒤섞어 출력합니다. 순수 텍스트만 전달하는 SSE나, 정형 데이터만 전달하는 REST 둘 다 이 혼합 I/O를 깔끔하게 처리하지 못합니다.
LangGraph, CrewAI, 직접 만든 커스텀 에이전트는 각자 다른 방식으로 UI와 통신합니다. 개발팀이 프레임워크를 바꿀 때마다 UI 연동 코드를 처음부터 다시 짜야 하는 것이 현실이었습니다. AG-UI는 이 파편화를 하나의 표준으로 해소합니다.
🔬 AG-UI의 핵심 구조 — 이벤트 스트림 완전 해부
AG-UI의 작동 원리는 놀라울 정도로 단순합니다. 프론트엔드가 에이전트 엔드포인트에 HTTP POST 요청을 보내면, 에이전트는 순서화된 JSON 이벤트 스트림으로 응답합니다. 모든 복잡성은 이 이벤트 스트림 하나로 추상화됩니다.
AG-UI 핵심 이벤트 유형
이 이벤트들이 하나의 스트림으로 흘러오면, 프론트엔드 SDK(주로 CopilotKit의 useAgent 훅)가 이를 파싱해 화면을 실시간 업데이트합니다. 개발자는 이벤트 해석 로직을 직접 짤 필요 없이, 결과로 받은 messages·state 객체만 화면에 바인딩하면 됩니다.
공유 상태(Shared State): AG-UI만의 차별점
AG-UI의 가장 강력한 기능 중 하나는 공유 상태(Shared State)입니다. 에이전트와 UI가 동일한 상태 객체를 실시간으로 양방향 동기화합니다. 예를 들어, 에이전트가 리서치 작업을 진행하면서 발견한 핵심 사항을 상태 객체에 추가하면, 사용자의 화면에 즉시 반영됩니다. 반대로 사용자가 화면에서 특정 항목을 수정하면, 에이전트가 다음 스텝에서 그 변경 사항을 반영합니다. 이것이 바로 진정한 인간-에이전트 협업입니다.
⚖️ MCP·A2A·AG-UI 3대 프로토콜 비교 — 어디서 무엇을 쓰나
에이전트 생태계를 처음 접하는 분들이 가장 많이 혼동하는 부분이 바로 이 세 프로토콜의 역할 구분입니다. 결론부터 말하면 이들은 경쟁하지 않습니다. 각자 담당하는 통신 계층이 다릅니다.
| 구분 | MCP | A2A | AG-UI |
|---|---|---|---|
| 개발 주체 | Anthropic | Google (→ Linux Foundation) | CopilotKit (오픈소스) |
| 통신 대상 | 에이전트 ↔ 도구/데이터 | 에이전트 ↔ 에이전트 | 에이전트 ↔ 사용자 UI |
| 방향성 | 주로 단방향 요청 | 양방향 위임·협업 | 양방향 실시간 스트림 |
| 전송 방식 | stdio / SSE | HTTPS + JSON-RPC 2.0 | HTTP POST + SSE / WebSocket |
| 핵심 기능 | 외부 도구 호출, 데이터 접근 | 에이전트 발견, 인증, 작업 위임 | 스트리밍, 상태 동기화, HITL |
| 비유 | AI의 “손” | AI의 “팀워크” | AI의 “얼굴” |
| 공개 시점 | 2024년 11월 | 2025년 4월 | 2025년 5월 |
실제 엔터프라이즈 시나리오: 세 프로토콜의 협업
마케팅 팀이 “이번 달 경쟁사 동향 보고서를 만들어줘”라고 AI 에이전트에게 요청하는 상황을 생각해 보겠습니다. 먼저 사용자의 요청이 AG-UI를 통해 오케스트레이터 에이전트에 전달됩니다. 오케스트레이터는 MCP를 이용해 웹 검색 API와 내부 데이터베이스에서 정보를 가져옵니다. 데이터 분석이 필요하면 A2A로 분석 전문 에이전트에게 작업을 위임합니다. 최종 보고서가 완성되는 과정과 결과는 다시 AG-UI를 통해 사용자 화면에 실시간 스트리밍됩니다. 사용자는 중간에 승인하거나 방향을 수정할 수 있습니다.
💻 실전 통합 가이드 — React에서 에이전트 연결하기
AG-UI는 개발자 경험(DX)을 최우선으로 설계되었습니다. CopilotKit의 React SDK를 이용하면 단 몇 줄로 어떤 AG-UI 호환 에이전트든 프론트엔드와 연결할 수 있습니다. 아래 예시 코드는 그 핵심 패턴을 보여줍니다.
import { CopilotKit } from ‘@copilotkit/react-core’;
export default function App() {
return (
<CopilotKit runtimeUrl=“/api/copilotkit”>
<MyAIPage />
</CopilotKit>
);
}
import { useCoAgent, useCoAgentStateRender } from ‘@copilotkit/react-core’;
function ResearchPanel() {
// state: 에이전트와 실시간 동기화되는 공유 상태
const { state, setState } = useCoAgent({
name: “research_agent”,
initialState: { findings: [], status: “idle” }
});
// 에이전트 상태를 화면에 렌더링
useCoAgentStateRender({
name: “research_agent”,
render: ({ state }) => (
<div>진행 상태: {state.status} | 발견 항목: {state.findings.length}건</div>
)
});
return <ResearchUI findings={state.findings} />;
}
백엔드 에이전트 설정 (Python · LangGraph 예시)
from copilotkit import CopilotKitRemoteEndpoint, LangGraphAgent
from fastapi import FastAPI
app = FastAPI()
sdk = CopilotKitRemoteEndpoint(
agents=[
LangGraphAgent(
name=“research_agent”,
graph=research_graph, # LangGraph 그래프 객체
)
]
)
# /copilotkit 엔드포인트가 AG-UI 이벤트 스트림을 자동 방출
app.include_router(sdk.router())
실제로 이것이 전부입니다. 에이전트 로직은 LangGraph 그래프 안에서 평소처럼 작성하면 되고, CopilotKit SDK가 AG-UI 이벤트 변환을 모두 자동으로 처리합니다. 개발자는 통신 계층을 걱정하지 않고 비즈니스 로직에만 집중할 수 있습니다.
🙋 Human-in-the-Loop — AG-UI가 진짜 쓸모 있는 이유
AI 에이전트의 가장 현실적인 문제는 “완전 자율”이 아직 위험하다는 점입니다. 중요한 이메일을 전송하거나, 코드를 프로덕션에 배포하거나, 대규모 데이터를 삭제하는 작업에서는 반드시 인간의 확인이 필요합니다. AG-UI는 이 Human-in-the-Loop(HITL) 패턴을 일급 기능으로 지원합니다.
HITL 작동 방식
TOOL_CALL_START와 함께 사용자 확인을 요청하는 상태를 UI에 전달합니다.
Generative UI — 에이전트가 화면을 직접 그린다
AG-UI의 또 다른 혁신은 Generative UI입니다. 에이전트가 텍스트 응답 대신 타입이 지정된 UI 컴포넌트를 직접 생성합니다. 예를 들어, 항공편 검색 에이전트가 텍스트로 “다음 편 있습니다”라고 답하는 대신, 좌석·가격·일정이 담긴 인터랙티브 카드 컴포넌트를 직접 렌더링합니다. 이는 챗봇 UI의 한계를 넘어서는 완전히 새로운 AI 경험입니다.
🌐 AG-UI 생태계 현황 — 2026년 3월 기준 지원 프레임워크
AG-UI가 불과 10개월 만에 주요 플랫폼들의 공식 지원을 확보할 수 있었던 것은, 기존 에이전트 프레임워크를 교체하는 것이 아니라 그 위에 얹히는 추상 계층이기 때문입니다. LangGraph로 만든 에이전트는 LangGraph를 그대로 쓰면 됩니다. AG-UI 어댑터만 추가하면 됩니다.
| 카테고리 | 프레임워크/플랫폼 | 지원 상태 |
|---|---|---|
| 파트너십 | LangGraph, CrewAI | ✅ 지원 완료 |
| 1st Party (마이크로소프트) | Microsoft Agent Framework | ✅ 지원 완료 |
| 1st Party (구글) | Google ADK | ✅ 지원 완료 |
| 1st Party (AWS) | AWS Strands Agents | ✅ 지원 완료 |
| 1st Party (기타) | Mastra, Pydantic AI, Agno, LlamaIndex, AG2 | ✅ 지원 완료 |
| 진행 중 | OpenAI Agent SDK, AWS Bedrock Agents, Cloudflare Agents | ⏳ 지원 예정 |
| 프로토콜 | A2A Middleware | ✅ 지원 완료 |
| SDK | TypeScript, Python, Kotlin, Go, Java, Rust, Dart | ✅ 지원 완료 |
특히 주목할 점은 OpenAI Agent SDK 지원이 진행 중이라는 것입니다. OpenAI가 합류하는 순간, AG-UI는 사실상 에이전트-UI 통신의 사실상 표준(de facto standard)이 될 가능성이 높습니다. 개인적으로, MCP가 Claude로 시작해 모든 AI에 퍼진 것처럼, AG-UI도 비슷한 궤적을 따를 것이라고 봅니다.
❓ 자주 묻는 질문 (Q&A)
AG-UI 프로토콜은 무료인가요? 상업적으로 사용할 수 있나요?
네, AG-UI는 MIT 라이선스의 완전한 오픈소스 프로젝트입니다. GitHub(ag-ui-protocol/ag-ui)에서 소스코드를 자유롭게 열람하고 기여할 수 있으며, 상업적 프로젝트에도 제한 없이 사용할 수 있습니다. 다만, AG-UI를 손쉽게 활용하기 위한 클라이언트인 CopilotKit은 별도의 유료 플랜이 있으므로 확인이 필요합니다.
AG-UI를 사용하려면 반드시 CopilotKit을 써야 하나요?
아닙니다. AG-UI는 독립적인 오픈 프로토콜이며, CopilotKit은 AG-UI를 가장 쉽게 쓸 수 있게 해주는 클라이언트 라이브러리 중 하나입니다. AG-UI 공식 GitHub에는 TypeScript, Python, Kotlin, Go, Java, Rust, Dart 등 다양한 언어의 SDK가 있어 CopilotKit 없이도 AG-UI를 직접 구현할 수 있습니다. 직접 구현할 경우 HTTP POST + SSE 스트림에서 JSON 이벤트를 파싱하는 로직을 작성하면 됩니다.
MCP를 이미 잘 쓰고 있는데 AG-UI도 반드시 도입해야 하나요?
MCP와 AG-UI는 전혀 다른 문제를 해결합니다. MCP가 없어도 AG-UI를 쓸 수 있고, 반대도 마찬가지입니다. 만약 개발 중인 AI 에이전트가 CLI나 백오피스 시스템에서만 동작하고 사용자 대면 UI가 없다면 AG-UI가 당장 필요하지 않을 수 있습니다. 하지만 에이전트가 웹 앱이나 모바일 앱을 통해 최종 사용자와 상호작용해야 한다면, AG-UI는 현재 시점에서 가장 합리적인 표준 선택지입니다.
AG-UI와 WebSocket의 차이는 무엇인가요?
WebSocket은 양방향 실시간 통신을 위한 네트워크 전송 프로토콜입니다. AG-UI는 그보다 상위 추상 계층으로, “어떤 형식의 메시지를 주고받는가”를 정의하는 애플리케이션 프로토콜입니다. AG-UI는 전송 계층으로 SSE, WebSocket, Webhook 등을 모두 지원합니다. 즉, WebSocket을 이용하더라도 AG-UI 이벤트 형식을 따르지 않으면 프레임워크 간 상호운용이 되지 않습니다. AG-UI의 핵심 가치는 전송 방식이 아니라 이벤트 스키마의 표준화에 있습니다.
AG-UI는 보안 측면에서 안전한가요? 기업 환경에 적합한가요?
AG-UI 사양 자체는 인증·암호화를 전송 계층(HTTPS, OAuth 등)에 위임합니다. 기업 환경에서는 AG-UI 미들웨어 계층에 보안 프록시를 두어 에이전트와 UI 사이의 통신을 안전하게 라우팅하는 방식을 권장합니다. Microsoft Agent Framework와 Google ADK는 이미 엔터프라이즈 보안 요구 사항을 충족하는 방식으로 AG-UI를 통합했습니다. 또한, 모든 이벤트가 순서화된 로그로 남기 때문에 감사(Audit)가 용이하다는 점도 기업 입장에서 큰 장점입니다.
✍️ 마치며 — 총평
솔직히 말하면, AG-UI는 “있으면 편한 도구”가 아니라 “없으면 매번 바퀴를 재발명해야 하는 기반 표준”입니다. MCP와 A2A가 각각 Anthropic과 Google이라는 거대 플레이어 주도로 빠르게 퍼진 것처럼, AG-UI도 Microsoft·Google·AWS가 공식 지원에 합류한 시점부터 사실상 표준화가 가속되고 있습니다.
특히 Human-in-the-Loop와 Generative UI는 에이전틱 애플리케이션을 단순한 챗봇에서 진짜 협업 도구로 격상시키는 핵심 기능입니다. “AI가 스스로 다 알아서 한다”는 환상보다, “AI와 인간이 가장 효율적으로 협업하는 방법”을 설계하는 것이 2026년 에이전트 개발의 핵심이라고 봅니다. AG-UI는 바로 그 설계를 위한 가장 실용적인 도구입니다.
한국어 자료가 아직 매우 부족한 주제인 만큼, AG-UI Dojo에서 직접 데모를 실행해보고 공식 문서를 탐색해 보시길 권합니다. 지금 이 프로토콜을 이해해두는 것이 1~2년 후 에이전트 서비스를 설계할 때 결정적인 차이를 만들 것입니다.
본 포스팅의 정보는 2026년 3월 11일 기준으로 작성되었습니다.
AG-UI 프로토콜 사양 및 지원 프레임워크는 업데이트될 수 있으며,
최신 정보는 공식 문서(docs.ag-ui.com)를 통해 확인하시기 바랍니다.
본 글은 특정 서비스의 유료 구독을 권유하지 않습니다.
댓글 남기기