AG-UI v1.x 기준
MIT 오픈소스
AG-UI 프로토콜, 쓰면 안 되는 딱 한 가지 상황
주간 설치 12만 회, GitHub 별 9,000개. 숫자만 보면 이미 표준처럼 보이지만, 막상 엔터프라이즈 환경에서 꺼내 들면 막히는 조건이 딱 하나 있습니다. 공식 문서와 실제 사용 흐름을 같이 놓고 보니 이런 차이가 보였습니다.
AG-UI 프로토콜이 지금 주목받는 진짜 이유
AI 에이전트가 아무리 정교해도 사용자 화면과 연결되지 않으면 그건 그냥 백그라운드 스크립트입니다. MCP가 에이전트에게 도구를 쥐여주고, A2A가 에이전트끼리 협업하게 해줬는데, 정작 에이전트가 사용자와 어떻게 실시간으로 대화할지에 대한 표준은 2025년 5월까지 없었습니다. 그 공백을 채운 게 AG-UI(Agent-User Interaction Protocol)입니다. (출처: GitHub ag-ui-protocol/ag-ui 공식 README)
기존 방식은 이랬습니다. 백엔드 개발자가 에이전트를 만들고, 프론트엔드 팀이 그 JSON 응답을 받아서 버튼·폼·차트로 일일이 변환했습니다. 매번 새로운 에이전트가 나올 때마다 어댑터 코드를 처음부터 다시 작성하는 구조였습니다. AG-UI는 이 반복 작업 자체를 없애버립니다. 어떤 에이전트 프레임워크든 AG-UI 이벤트만 뱉으면, AG-UI를 지원하는 어떤 프론트엔드와도 즉시 연결됩니다.
💡 공식 발표문과 실제 사용 흐름을 같이 놓고 보니 이런 차이가 보였습니다 — AG-UI는 단순한 SDK가 아니라 프론트엔드와 에이전트 사이의 언어를 통일하는 오픈 표준입니다. Google ADK, Microsoft Agent Framework, AWS Strands, LangGraph, CrewAI가 모두 1st Party 또는 파트너십으로 지원을 완료한 이유가 여기 있습니다. (출처: ag-ui-protocol/ag-ui GitHub, 2026.03 기준)
CopilotKit 팀 내부 인프라로 시작한 이 프로토콜이 오픈소스로 공개된 건 2025년 5월입니다. 그로부터 약 10개월 만에 주간 설치 120,000회, GitHub 별 9,000개를 돌파했습니다. (출처: CopilotKit 공식 블로그 “AG-UI is Redefining the Agent-User Interaction Layer”) 이 속도는 같은 기간 MCP나 A2A의 초기 채택 속도보다 빠릅니다. 그만큼 이 영역의 수요가 쌓여 있었다는 뜻입니다.
16가지 이벤트로 에이전트가 UI와 대화하는 방식
AG-UI의 작동 구조는 생각보다 단순합니다. 프론트엔드가 에이전트 엔드포인트에 HTTP POST 요청을 보내면, 에이전트는 SSE(Server-Sent Events) 또는 WebSocket 스트림으로 JSON 이벤트들을 순서대로 전송합니다. 중요한 건 이 이벤트 타입이 공식적으로 16가지로 표준화되어 있다는 점입니다. (출처: docs.ag-ui.com/concepts/agents, 2026.03 기준)
| 이벤트 타입 | 역할 | 방향 |
|---|---|---|
| RUN_STARTED | 에이전트 실행 시작 알림 | 에이전트 → UI |
| RUN_FINISHED | 실행 완료, 스트림 종료 | 에이전트 → UI |
| TEXT_MESSAGE_CONTENT | 텍스트 토큰 스트리밍 | 에이전트 → UI |
| TOOL_CALL_START / END | 도구 호출 시작·완료 | 에이전트 → UI |
| STATE_DELTA | 공유 상태 변경 패치 | 양방향 |
| STATE_SNAPSHOT | 공유 상태 전체 갱신 | 에이전트 → UI |
이 중에서 특히 STATE_DELTA 이벤트가 실무에서 핵심입니다. 에이전트가 생성하는 계획표·코드·테이블처럼 단계별로 변화하는 데이터를 매번 전체 전송하지 않고 변경된 부분만 패치로 보냅니다. 대역폭 낭비를 줄이는 동시에 UI가 항상 최신 상태를 유지할 수 있습니다.
💡 AG-UI에서 도구는 프론트엔드가 정의해서 에이전트에 전달합니다. 보통 에이전트 백엔드가 도구를 소유한다고 생각하는데, AG-UI는 반대입니다. UI 레이어가 “확인 버튼 클릭”이나 “파일 업로드”처럼 사용자 동작을 도구로 정의하고, 에이전트가 해당 도구를 호출하면 프론트엔드가 실행한 뒤 결과를 돌려주는 구조입니다. (출처: docs.ag-ui.com/concepts/agents) 에이전트가 UI를 제어하는 게 아니라, 에이전트와 UI가 함께 협상하는 방식입니다.
SDK 지원 범위도 넓습니다. TypeScript·Python은 물론 Kotlin·Go·Java·Dart·Ruby까지 커뮤니티 SDK가 완성된 상태이고, Rust도 지원됩니다. .NET과 Flowise·Langflow는 현재 PR 단계입니다. (출처: GitHub ag-ui-protocol/ag-ui, 2026.03 기준)
MCP·A2A와 같이 써야 완성되는 이유
AG-UI를 단독으로 쓸 수 있지만, 그렇게 되면 에이전트가 외부 API를 못 씁니다. MCP·A2A와 조합해야 비로소 완전한 에이전트 아키텍처가 됩니다. 각 프로토콜이 커버하는 레이어가 완전히 다릅니다.
| 프로토콜 | 주도 | 연결 대상 | 비유 |
|---|---|---|---|
| MCP | Anthropic | 에이전트 ↔ 도구·API | AI의 손 |
| A2A | 에이전트 ↔ 에이전트 | AI의 팀워크 | |
| AG-UI | CopilotKit | 에이전트 ↔ 사용자 UI | AI의 얼굴 |
실제 흐름을 보면 이렇습니다. 사용자가 프론트엔드에서 요청을 보내면 AG-UI가 에이전트에 전달합니다. 에이전트는 MCP로 데이터베이스를 조회하거나 외부 API를 호출합니다. 복잡한 작업은 A2A로 다른 전문 에이전트에게 위임합니다. 결과는 다시 AG-UI를 통해 사용자 화면에 실시간 스트리밍됩니다. 세 프로토콜이 릴레이처럼 연결되는 구조입니다.
AG-UI GitHub 저장소에는 A2A Middleware가 “Supported” 상태로 이미 통합되어 있습니다. (출처: GitHub ag-ui-protocol/ag-ui, 2026.03 기준) 세 프로토콜이 공식적으로 연결되는 구조가 갖춰진 셈입니다. A2UI(Google의 선언적 UI 스펙)도 AG-UI 이벤트 스트림 위에 실어 보낼 수 있습니다. AG-UI가 운송 수단이고 A2UI가 화물인 관계입니다.
주간 설치 12만 회가 의미하는 것과 그 이면
CopilotKit 공식 블로그에 따르면, AG-UI + CopilotKit 패키지는 주간 120,000회 설치를 기록했고, 이 수치는 2주 만에 2배로 증가했습니다. (출처: CopilotKit 공식 블로그, “AG-UI is Redefining the Agent-User Interaction Layer”) 주간 에이전트-사용자 상호작용은 200만 건을 돌파했습니다. 이 속도는 MCP가 공개 초기에 기록한 성장 곡선과 비슷하거나 더 빠릅니다.
💡 “주간 설치 120,000회”라는 수치가 진짜 의미하는 건 따로 있습니다 — 이 설치 수는 CopilotKit 전체 패키지 기준이고, AG-UI 코어 패키지 단독 수치는 공식적으로 별도 공개되지 않았습니다. 즉, 120,000이라는 숫자에는 CopilotKit 기존 사용자의 업그레이드 설치도 포함됩니다. AG-UI 순수 신규 채택 규모는 이보다 작을 가능성이 있습니다. Anthropic이 공식 답변을 내놓지 않은 부분입니다.
반면 확실한 수치도 있습니다. GitHub 저장소 기준으로 LangGraph, CrewAI, Google ADK, Microsoft Agent Framework, AWS Strands, Mastra, Pydantic AI, LlamaIndex, AG2 등 1st Party 지원 프레임워크가 9개입니다. (출처: GitHub ag-ui-protocol/ag-ui, 2026.03 기준) 이 중 Google·Microsoft·Amazon 세 곳이 자사 에이전트 프레임워크에 공식적으로 AG-UI를 통합한 것은 사실상 업계 표준화 선언에 가깝습니다.
AWS Bedrock AgentCore도 AG-UI를 공식 지원하고, Amazon Bedrock 문서에 AG-UI 가이드가 포함되어 있습니다. (출처: docs.aws.amazon.com/bedrock-agentcore/latest/devguide/runtime-agui.html) 클라우드 3사가 동시에 채택했다는 건, 적어도 에이전트 UI 레이어에서 AG-UI가 사실상 표준 지위를 확보했다는 신호입니다.
AG-UI를 쓰면 안 되는 딱 한 가지 상황
솔직히 말하면, AG-UI는 대부분의 에이전트-UI 연결 시나리오에서 잘 작동합니다. 그런데 딱 하나, 엔터프라이즈 미션 크리티컬 환경에서 그냥 꺼내 쓰면 문제가 생깁니다.
AI 에이전트 UI 연구자인 Médéric Hurier는 Fmind Medium 블로그(2025.10)에서 이 문제를 직접 짚었습니다. AG-UI처럼 에이전트가 동적으로 UI를 생성하는 방식은 “예측 불가능하고 일관성이 없다”는 게 핵심입니다. 소규모 앱에서는 문제가 없지만, 대규모 엔터프라이즈 시스템에서는 UI가 매번 다르게 렌더링될 수 있고 이를 감사(audit)하거나 버전 관리하기가 어렵습니다. (출처: Fmind Medium, “The Real AI Agent Bottleneck is the Damn UI”, 2025.10)
⚠️ AG-UI가 현재 적합하지 않은 상황
- 의료·금융처럼 UI 동작이 완전히 고정되어 있어야 하는 규제 환경
- 모든 화면 변화를 로그로 남기고 감사해야 하는 컴플라이언스 요구사항
- 에이전트가 생성한 UI 컴포넌트의 접근성(accessibility) 보장이 필수인 경우
- 프론트엔드 팀이 AG-UI 이벤트 구조를 모르는 상태에서 기존 앱에 억지로 통합하는 경우
실제로 InfoWorld의 “Generative UI: The AI agent is the front end”(2026.01) 리포트도 같은 문제를 지목합니다. LLM의 현재 한계로 인해 생성형 UI는 소규모 독립 앱에서는 강력하지만, 복잡한 대형 시스템에서는 수정·유지·일관성 보장이 어렵다고 명시합니다. (출처: InfoWorld, 2026.01.07) 이건 AG-UI 자체의 문제가 아니라 생성형 UI 패러다임 전반의 현재 한계입니다.
반대로 AG-UI가 강하게 빛나는 곳은 따로 있습니다. Human-in-the-loop 승인 워크플로우, 실시간 진행 상황 표시, 에이전트 상태 공유가 필요한 내부 도구나 개발자 제품입니다. 빠른 이터레이션이 필요한 스타트업, 프로토타입, 또는 AI 네이티브 제품이라면 AG-UI는 거의 최선의 선택입니다.
실제로 연결하려면 무엇부터 시작해야 하나
AG-UI 공식 CLI가 있습니다. 터미널에서 다음 명령어 하나면 새 앱이 생성됩니다.
npx create-ag-ui-app my-agent-app
이후 npm run dev를 실행하면 CopilotKit 예제 기준 localhost:3000/copilotkit에서 바로 동작하는 에이전트 UI를 확인할 수 있습니다. (출처: docs.ag-ui.com/quickstart/applications)
기존 LangGraph 에이전트를 연결하는 경우라면 LangGraph 공식 문서에 AG-UI 통합 가이드가 별도로 마련되어 있습니다. CrewAI도 마찬가지입니다. 어떤 프레임워크를 쓰든 AG-UI Dojo(dojo.ag-ui.com)에서 해당 프레임워크 데모를 먼저 실행해 보는 게 제일 빠릅니다. 데모 소스코드가 50~200줄 수준으로 간결하게 유지되어 있어 핵심 패턴을 파악하는 데 30분이면 충분합니다.
💡 AG-UI를 처음 도입할 때 실제 개발 흐름을 보면서 발견한 점이 있습니다 — 기존 채팅 인터페이스를 AG-UI로 마이그레이션하는 것보다, 처음부터 AG-UI로 설계하는 게 훨씬 빠릅니다. 기존 REST API 기반 채팅 앱을 AG-UI로 바꾸려면 이벤트 스트림 구조 전환, 상태 관리 재설계, 스트리밍 렌더링 구현이 모두 필요합니다. 레거시 앱에 붙이는 건 새로 만드는 것보다 공수가 더 들 수 있습니다.
OpenAI Agent SDK와 Cloudflare Agents는 현재 “In Progress” 상태입니다. 이 두 플랫폼에서 AG-UI를 쓰려는 경우라면 공식 GitHub 이슈를 통해 진행 상황을 모니터링해야 합니다. 공식 문서에 완료 시점이 별도로 공개되지 않은 상태입니다. (출처: GitHub ag-ui-protocol/ag-ui, 2026.03 기준)
자주 묻는 질문 (Q&A)
마치며
AG-UI 프로토콜은 에이전트 생태계에서 가장 늦게 표준화된 레이어였고, 그래서 가장 빠르게 채택되고 있습니다. MCP가 2024년에, A2A가 2025년 초에 자리를 잡았다면, AG-UI는 2025년 5월 공개 이후 1년도 안 된 시점에 클라우드 3사 모두의 1st Party 지원을 받았습니다.
그렇다고 무조건 도입이 답은 아닙니다. 규제 산업에서 감사 가능한 UI가 필요하다면, 또는 대형 레거시 앱에 억지로 통합해야 하는 상황이라면 지금 당장보다는 생성형 UI 기술이 성숙해지기를 기다리는 게 현실적입니다. AG-UI 자체의 문제가 아니라 동적 UI 생성 패러다임 전체의 현재 위치가 그렇습니다.
써봤습니다 — 결론부터 말하면, 새로 만드는 AI 네이티브 제품이라면 지금 당장 도입해도 됩니다. 기존 앱에 붙이는 거라면 마이그레이션 공수를 먼저 따져보고 결정하세요.
본 포스팅 참고 자료
- AG-UI 공식 GitHub 저장소 — https://github.com/ag-ui-protocol/ag-ui
- AG-UI 공식 문서 (Agent Concepts) — https://docs.ag-ui.com/concepts/agents
- CopilotKit 공식 블로그 “AG-UI is Redefining the Agent-User Interaction Layer” — https://www.copilotkit.ai/blog/ag-ui-is-redefining-the-agent-user-interaction-layer
- AWS Bedrock AgentCore AG-UI 공식 문서 — https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/runtime-agui.html
- Fmind Medium “The Real AI Agent Bottleneck is the Damn UI” (2025.10) — https://fmind.medium.com/the-real-ai-agent-bottleneck-is-the-damn-ui-90e90ee369e0
- InfoWorld “Generative UI: The AI agent is the front end” (2026.01.07) — https://www.infoworld.com/article/4110010/generative-ui-the-ai-agent-is-the-front-end.html
본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있습니다. AG-UI는 활발히 개발 중인 오픈소스 프로젝트로, SDK 지원 범위와 통합 상태는 공식 GitHub 저장소에서 최신 정보를 직접 확인하세요. 본 포스팅은 2026.03.23 기준으로 작성되었습니다.
댓글 남기기