AG-UI 추천: AI 에이전트를 웹앱 UI에 붙이는 새 프로토콜
MCP·A2A 다음에 봐야 할 프론트엔드용 에이전트 상호작용 계층
AG-UI는 무엇이고 왜 지금 볼 만한가?
AG-UI는 AI agent backend와 웹앱 UI 사이의 이벤트 기반 상호작용을 맞추려는 오픈 프로토콜입니다. 2026년 5월 20일 최신 릴리스와 2026년 5월 21일 GitHub API 기준 최근 push가 확인되어, 프론트엔드 개발자가 지금 테스트해 볼 만한 GitHub 추천 후보입니다.
AI 에이전트를 웹앱에 붙일 때 막히는 곳은 모델 호출보다 화면 쪽인 경우가 많습니다. 사용자가 보는 UI에서는 로딩, 중간 진행, 도구 호출, 승인 요청, 취소, 오류, 상태 동기화가 모두 따로 움직입니다. 이걸 백엔드마다 임의 payload로 맞추기 시작하면 금방 유지보수 일이 됩니다.
AG-UI는 그 빈칸을 다룹니다. 공식 설명 기준으로 AG-UI는 Agent-User Interaction Protocol이며, ag-ui-protocol ag-ui agent user interaction protocol이라는 검색어가 가리키는 그대로 agent와 사용자-facing application 사이의 상호작용 계층을 겨냥합니다.
제가 보기에는 이 저장소의 매력은 '새 챗봇 UI'가 아니라 agent backend마다 제각각 만들던 이벤트 payload를 줄일 수 있는 공통 언어라는 점입니다. React나 Next.js 화면에 에이전트를 붙이는 팀이라면 MCP, A2A만 보고 끝낼 일이 아니라 AG-UI도 같이 확인할 만합니다.
MCP, A2A와 AG-UI는 어디가 다른가?
MCP가 agent와 tools/data/context를 잇고 A2A가 agent 간 통신을 맡는다면, AG-UI는 agent와 사용자-facing application 사이의 interaction layer를 맡습니다. 셋은 대체재라기보다 서로 다른 계층을 담당하는 보완재로 보는 편이 정확합니다.
MCP를 이미 따라가고 있다면 AG-UI가 또 다른 프로토콜 이름처럼 보일 수 있습니다. 하지만 공식 문서가 나누는 역할은 꽤 분명합니다. MCP는 에이전트가 외부 도구, 데이터, 컨텍스트에 접근하는 쪽에 가깝고, A2A는 에이전트끼리 협업하는 통신 계층으로 설명됩니다.
AG-UI는 사용자가 실제로 보는 앱 화면 쪽에 붙습니다. 사용자의 메시지, 에이전트 실행 상태, 텍스트 스트리밍, 도구 호출 결과, 공유 상태 변화를 UI가 이해할 이벤트로 다루려는 층입니다.
| 구분 | 주로 다루는 문제 | AG-UI와의 관계 |
|---|---|---|
| MCP | tools, data, context 연결 | 에이전트가 무엇을 쓸 수 있는지 다룸 |
| A2A | agent-to-agent 통신 | 에이전트끼리 어떻게 협업할지 다룸 |
| AG-UI | agent-user interaction | 사용자가 보는 웹앱 UI와 에이전트 사이를 다룸 |
한국 사용자 입장에서는 이 구분이 중요합니다. 'MCP를 붙였으니 UI 문제도 끝났다'고 생각하면 프론트엔드에서 SSE, WebSocket, 상태 관리 규칙을 다시 손으로 맞추게 됩니다. ag-ui-protocol ag-ui agent user interaction protocol은 바로 그 작업을 덜어보려는 프로젝트에 가깝습니다.
최근 활동 타임라인: 왜 오늘 추천 후보인가?
AG-UI는 2025년 공개 이후 2026년 5월에도 릴리스와 push가 이어지고 있습니다. 다만 stars, forks, open issues는 계속 변하므로 확인 날짜와 기준을 함께 보는 것이 맞습니다.
2026년 5월 21일 기준으로 이 저장소는 최근 push와 전날 릴리스가 같이 확인됩니다. GitHub 추천 글에서 별 수는 참고 신호일 뿐이지만, 활동이 이어지는지와 첫 테스트 경로가 있는지는 꽤 중요합니다.
- 2025년 4월 9일: AG-UI 문서의 What's New 흐름에서 저장소 공개와 초기 릴리스가 기록됨
- 2025년 5월 7일: GitHub API 기준 ag-ui-protocol/ag-ui 저장소 생성
- 2026년 5월 20일: Release 2026-05-20 게시, release body에서 create-ag-ui-app 0.0.53 배포 확인
- 2026년 5월 21일: GitHub API 기준 pushed_at 2026-05-21T10:27:49Z, 약 13,714~13,715 stars 확인
여기서 볼 부분은 '인기가 있다'보다 '실제로 만져볼 공식 경로가 있다'는 점입니다. 다만 open issues가 적지 않고 통합 목록도 빠르게 바뀌는 영역이라, production-ready라는 말은 각 팀의 PoC와 운영 테스트 뒤에 붙이는 편이 안전합니다.
첫 테스트: create-ag-ui-app으로 웹앱에서 확인하기
가장 빠른 확인 경로는 공식 quickstart의 npx create-ag-ui-app@latest로 앱을 만들고 npm run dev로 로컬에서 실행하는 방식입니다. CopilotKit 예제는 localhost 경로에서 확인하도록 안내되어 있어 React 개발자에게 진입 장벽이 낮습니다.
처음부터 서버 구현을 새로 짜면 AG-UI 자체보다 주변 설정에 시간을 더 쓰게 됩니다. 먼저 공식 스캐폴딩으로 이벤트가 UI에 어떻게 들어오는지 보는 편이 낫습니다.
```bash
npx create-ag-ui-app@latest my-agent-app
cd my-agent-app
npm run dev
```
공식 quickstart는 CopilotKit 예제를 `http://localhost:3000/copilotkit`에서 확인하는 흐름을 안내합니다. 여기서 중요한 것은 화면이 뜨는지만 보는 일이 아닙니다. 사용자 메시지를 보낸 뒤 run 시작, 스트리밍 텍스트, 종료 또는 오류 상태가 UI에 어떻게 반영되는지 봐야 합니다.
기존 앱에 붙일 계획이라면 다음 질문이 먼저입니다. 현재 백엔드 agent API가 `POST` 요청을 받고 `text/event-stream`으로 이벤트를 내보낼 수 있는가? 인증 헤더와 API key는 브라우저가 아니라 서버 경계에서 관리되는가? 긴 실행을 멈추는 cancel UX를 넣을 여지가 있는가?
AG-UI의 핵심 구조: 이벤트, 상태, HttpAgent
AG-UI의 차별점은 agent 응답을 단일 텍스트가 아니라 lifecycle, text message, tool call, state management 같은 event stream으로 다룬다는 점입니다. 이 구조 덕분에 UI는 진행 상태, 스트리밍 텍스트, 도구 호출, 상태 변경을 분리해 렌더링할 수 있습니다.
일반적인 챗봇 API는 요청 하나에 답변 하나를 받는 구조로 시작합니다. 하지만 agent UI는 그렇게 단순하지 않습니다. 사용자는 답변 생성 중간에 멈추고 싶어 하고, 도구 호출이 진행되는지 보고 싶어 하며, 어느 단계에서 오류가 났는지도 알아야 합니다.
AG-UI 문서의 event category는 lifecycle, text message, tool call, state management, activity 등으로 나뉩니다. 예를 들어 run은 시작 이벤트로 열리고 완료 또는 오류 이벤트로 닫힙니다. 텍스트도 한 번에 떨어지는 결과물이 아니라 start, content delta, end 흐름으로 조립될 수 있습니다.
상태 관리는 실제 UI 품질과 바로 이어집니다. `STATE_SNAPSHOT`은 전체 상태를 맞추는 데, `STATE_DELTA`는 JSON Patch 스타일의 증분 변경을 전달하는 데 쓰입니다. 여기서 확인할 부분은 이 이벤트를 프론트엔드 상태 관리와 어떻게 연결할지입니다. Zustand, Redux, React state 중 무엇을 쓰든 이벤트 contract가 흐트러지면 화면은 금방 불안정해집니다.
`@ag-ui/client`의 `HttpAgent`는 기존 remote AI agent endpoint와 프론트엔드 사이를 연결할 때 보는 핵심 경로입니다. ag-ui-protocol ag-ui agent user interaction protocol을 단순 문서가 아니라 앱 구조로 평가하려면, `HttpAgent({ url, headers })`가 우리 백엔드의 인증, timeout, abort, SSE 처리와 맞는지를 작은 테스트로 확인해야 합니다.
도입 시뮬레이션: 설치보다 먼저 검증할 것
AG-UI 도입은 '설치가 된다'보다 event stream, state sync, cancel/error handling, backend key 관리, 기존 agent framework 연결을 검증하는 방식으로 봐야 합니다. 단순 Q&A 챗봇만 필요하거나 이벤트 스트림을 유지할 팀 여력이 없다면 도입을 미루는 편이 낫습니다.
제가 권하는 첫 주 테스트는 작게 잡는 쪽입니다. `create-ag-ui-app`으로 샘플을 띄운 뒤, 기존 agent endpoint 하나만 AG-UI 흐름으로 감싸서 메시지 1개를 보내봅니다. 성공 기준은 '답변이 보인다'가 아니라 아래 네 가지가 모두 보이는지입니다.
- `RunStarted`에 맞춰 로딩 상태가 켜지는가
- 스트리밍 텍스트가 끊기지 않고 조립되는가
- `RunFinished` 또는 `RunError`에서 UI가 정확히 닫히는가
- 중간 취소가 `AbortController` 또는 서버 cancel 처리와 맞물리는가
운영으로 넘어가면 체크가 더 늘어납니다. Node 런타임, pnpm 버전, Python SDK를 쓸 경우 Python 3.12+와 Poetry, backend API key 관리, SSE 관측, timeout, e2e 테스트가 필요합니다. 특히 API key를 브라우저에 넣는 예시는 피해야 합니다. 프론트엔드는 AG-UI 이벤트를 소비하고, 민감한 provider key와 tool 권한은 backend endpoint 또는 secure proxy에서 관리하는 구성이 더 현실적입니다.
> AG-UI는 agent UI 배선을 줄이는 도구이지, 보안 모델과 데이터 거버넌스를 대신 설계해주는 도구가 아닙니다.
추천 분야는 꽤 선명합니다. agentic chat, copilot UI, workflow dashboard, human-in-the-loop review, 내부 개발자 도구처럼 사용자가 agent 실행 흐름을 계속 봐야 하는 화면에 잘 맞습니다. 반대로 FAQ성 단문 응답만 필요한 서비스라면 ag-ui-protocol ag-ui agent user interaction protocol을 억지로 넣을 이유는 약합니다.
React/프론트엔드 팀에 중요한 이유
프론트엔드 팀 입장에서는 agent backend마다 임의 SSE/WebSocket payload를 새로 맞추는 부담을 줄일 수 있다는 점이 핵심입니다. 특히 agentic chat, copilot UI, workflow dashboard, human-in-the-loop review처럼 상호작용이 많은 화면에서 가치가 커집니다.
프론트엔드 팀 입장에서는 실무적인 의미가 있습니다. AI 에이전트 프로젝트에서 '백엔드는 다 됐으니 UI만 붙이면 된다'는 말이 나오지만, 실제 화면에는 진행률, 단계명, 도구 호출, 사용자 승인, 오류 복구, 재시도, 취소 버튼이 들어갑니다.
AG-UI가 흥미로운 이유는 이 문제를 프론트엔드 쪽 언어로 풀려고 한다는 점입니다. `@ag-ui/core`는 이벤트와 타입의 기준점을 주고, `@ag-ui/client`는 remote agent endpoint와 연결하는 클라이언트 경로를 제공합니다. 기존 LangGraph, CrewAI, Mastra, Pydantic AI, Agno, LlamaIndex, Google ADK 같은 agent framework를 이미 쓰고 있다면, AG-UI는 그 위의 사용자-facing layer 후보가 됩니다.
한국 개발팀에서는 레거시 웹앱 위에 AI 기능을 붙이는 일이 많습니다. 새 agent UI를 별도 제품처럼 만들기보다 기존 admin, CRM, 사내 도구, 리뷰 화면 안에 넣어야 하는 경우가 흔합니다. AG-UI는 이 상황에서 '에이전트가 지금 무엇을 하고 있는지 UI가 해석할 수 있게 만드는 공통 계약'으로 검토할 만합니다.
도입 전에 조심할 점
AG-UI는 UI interaction layer를 표준화하려는 도구이지 보안, 권한, 데이터 거버넌스, agent reasoning 품질을 자동 해결하지 않습니다. API key는 브라우저에 노출하지 말고 backend endpoint, auth, audit, timeout, cancellation, e2e test를 별도로 설계해야 합니다.
다만 '프로토콜'이라는 단어가 주는 착시는 조심해야 합니다. AG-UI를 W3C나 IETF 같은 공식 표준화 기구의 승인 표준으로 쓰면 안 됩니다. 공식 자료의 맥락은 open protocol/open standard에 가깝지만, 규제나 조달 문서에 넣을 때는 표현을 정확히 해야 합니다.
또 하나는 통합 목록입니다. 공식 docs에 이름이 있다고 해서 모든 framework integration이 같은 수준의 production support를 가진다는 뜻은 아닙니다. 특히 in progress, community, help-wanted 성격의 경로는 팀 내부에서 유지보수 책임을 질 수 있는지 확인해야 합니다.
보안 측면에서는 더 현실적으로 봐야 합니다. agent endpoint가 어떤 tool을 호출하는지, 사용자별 권한이 어떻게 적용되는지, 로그에 개인정보가 남는지, 취소나 timeout이 실패했을 때 비용이 계속 발생하는지 확인해야 합니다. AG-UI는 이런 판단을 화면과 이벤트 구조로 드러내는 데 도움을 줄 수 있지만, 정책 자체를 대신 만들어주지는 않습니다.
그래서 이 글의 추천은 '당장 전면 도입'이 아닙니다. 에이전트 UI를 만들 팀이라면 작은 범위에서 먼저 테스트할 만하다는 쪽에 가깝습니다.
자주 묻는 질문
Q. AG-UI는 MCP와 무엇이 다른가?
A. MCP는 agent가 tools, data, context에 접근하는 계층으로 설명되고, AG-UI는 agent와 사용자-facing application 사이의 interaction layer를 다룹니다. 따라서 MCP로 도구 연결을 처리하고 AG-UI로 웹앱 UI 이벤트를 처리하는 식의 조합이 가능합니다.
Q. AG-UI는 A2A를 대체하는 프로토콜인가?
A. 공식 문서 기준으로 A2A는 agent-to-agent 통신 쪽이고 AG-UI는 agent-user interaction 쪽입니다. 여러 agent가 뒤에서 협업하고, 앞에서는 사용자가 하나의 웹앱 UI로 그 흐름을 보는 제품이라면 둘은 경쟁보다 보완 관계에 가깝습니다.
Q. React나 Next.js 앱에서 가장 빨리 테스트하는 방법은 무엇인가?
A. 공식 quickstart의 `npx create-ag-ui-app@latest`로 샘플 앱을 만들고 `npm run dev`로 로컬 실행하는 방식이 가장 빠릅니다. CopilotKit 예제는 `http://localhost:3000/copilotkit` 확인 경로가 안내되어 있어 이벤트 흐름을 바로 살피기 좋습니다.
Q. 기존 agent API가 있으면 HttpAgent로 바로 붙일 수 있나?
A. 가능성을 볼 수는 있지만 endpoint가 AG-UI가 기대하는 입력과 event stream을 맞춰야 합니다. `HttpAgent`는 remote agent endpoint에 HTTP로 연결하고 `text/event-stream` 계열 응답을 AG-UI events로 다루는 경로이므로, 인증 헤더, POST body, abort, timeout, 오류 이벤트를 먼저 작게 검증해야 합니다.
Q. 어떤 팀은 AG-UI를 건너뛰는 편이 낫나?
A. 단순 FAQ 챗봇처럼 요청 하나에 답변 하나면 충분한 서비스는 AG-UI의 event stream 구조가 과할 수 있습니다. 또한 공식 표준화 기구 승인 프로토콜만 써야 하는 조직, 브라우저와 백엔드 권한 경계를 설계할 여력이 없는 팀, lifecycle/state/cancel e2e 테스트를 운영할 수 없는 팀은 도입을 미루는 편이 안전합니다.
함께 읽으면 좋은 글
참조 링크
- GitHub - ag-ui-protocol/ag-ui — 공식 저장소, README, owner/repo, license, release, quickstart 확인 기준
- Release 2026-05-20 — 최신 릴리스 날짜와 create-ag-ui-app 0.0.53 배포 확인
- AG-UI Overview — AG-UI의 목적, MCP/A2A와의 위치, building blocks, integration 목록 확인
- MCP, A2A, and AG-UI — MCP, A2A, AG-UI의 계층 차이를 확인한 공식 문서
- Build applications — create-ag-ui-app, npm run dev, localhost 확인 경로
- Core architecture — transport, HttpAgent, state events, architecture 근거
- Events — lifecycle, text message, tool call, state management event contract 확인
- HttpAgent — @ag-ui/client의 HTTP agent 연결 방식과 event stream 처리 확인
- Python SDK overview — Python SDK 설치 명령과 ag_ui.core import 경로 확인