- Published on
BuilderIO Agent-Native: AI 앱의 중심이 채팅창에서 제품 상태로 이동한다
- Authors
- Name
- Kyunghyun Park
- @devkhpark
Agent-Native · MCP · A2A · Shared Product State
AI 앱을 만들 때 가장 흔한 실수는 “기존 제품 옆에 채팅창 하나 붙이면 된다”는 생각이다. 데모는 그럴듯하다. 사용자가 채팅창에 “이메일 답장 써줘”, “캘린더 일정 잡아줘”, “대시보드 만들어줘”라고 말하면 모델이 뭔가 해준다. 하지만 제품이 실제로 쓰이기 시작하면 문제가 바로 드러난다. UI에서 누른 버튼, 에이전트가 호출한 툴, 백엔드 API, 승인 플로우, 권한, 로그, 상태 동기화가 서로 다른 세계에 존재한다.
BuilderIO의 Agent-Native가 흥미로운 이유는 이 문제를 정면으로 겨냥하기 때문이다. README의 첫 문장은 “rich user interfaces”와 “autonomous agents” 사이에서 선택하지 말라는 메시지다. 핵심은 에이전트를 제품 바깥의 보조 챗봇으로 두지 않고, UI와 에이전트를 같은 상태·같은 액션·같은 권한 체계 안에 넣는 것이다.
이 글은 2026년 6월 20일 GitHub Trending에 오른 BuilderIO/agent-native, 공식 README, Agent-Native 문서, GitHub API와 저장소 구조를 바탕으로 작성했다. 결론부터 말하면, Agent-Native는 “또 하나의 에이전트 프레임워크”라기보다 에이전트가 제품의 일급 사용자이자 일급 실행 주체가 되는 앱 아키텍처에 가깝다.
왜 지금 “Agent-Native”라는 말이 필요한가
지난 1년 동안 AI 제품의 기본 패턴은 빠르게 바뀌었다. 처음에는 RAG 챗봇이 많았다. 그다음에는 툴 호출과 워크플로 자동화가 붙었다. 최근에는 MCP, A2A, 에이전트 스킬, 코딩 에이전트 플러그인, 멀티 에이전트 협업 같은 말이 한꺼번에 쏟아지고 있다.
문제는 제품 구조가 이 속도를 따라가지 못한다는 점이다. 많은 팀이 여전히 아래와 같은 식으로 AI 기능을 붙인다.
- 기존 SaaS UI는 그대로 둔다.
- 별도 채팅 패널을 만든다.
- 모델이 호출할 API wrapper를 몇 개 붙인다.
- 사용자의 실제 화면 상태, 선택 영역, 권한, 작업 로그는 나중에 연결한다.
이 방식은 MVP에는 빠르지만, 운영 단계에서는 계속 비용을 만든다. 사용자는 UI에서 본 것과 에이전트가 알고 있는 것이 다르다고 느끼고, 개발자는 같은 기능을 버튼용·API용·에이전트용으로 중복 구현하며, 운영자는 누가 어떤 권한으로 어떤 액션을 실행했는지 추적하기 어렵다.
Agent-Native의 README가 반복해서 강조하는 표현은 “Every action works both ways — click it or ask for it”이다. 이 문장은 꽤 중요하다. AI 앱의 핵심 인터페이스가 채팅인지 버튼인지가 아니라, 같은 제품 행동을 사람이 클릭해도 되고 에이전트가 호출해도 되는 구조가 되어야 한다는 뜻이기 때문이다.
핵심 설계: 액션 하나가 UI·에이전트·API·MCP·A2A를 함께 먹여야 한다
Agent-Native README의 가장 직접적인 코드 예시는 defineAction이다. 이메일 답장을 저장하는 액션 하나를 정의하면, 이 액션이 UI, agent, HTTP, MCP, A2A, CLI에서 모두 쓰일 수 있다는 식이다.
이 패턴의 실무적 의미는 크다. 기존 앱에서는 보통 “버튼을 눌렀을 때 실행되는 함수”와 “에이전트가 호출할 툴”이 분리된다. 처음에는 비슷해 보여도 시간이 지나면 둘은 다르게 썩는다. UI 쪽에는 validation이 있는데 에이전트 툴에는 없거나, API는 권한 체크를 하지만 MCP wrapper는 빠뜨리거나, CLI 경로는 로그가 남지 않는 식이다.
Agent-Native가 제안하는 방향은 반대다.
- 제품의 행동 단위를 먼저 액션으로 정의한다.
- 그 액션에 스키마, 권한, 상태 변경, 관측 지점을 붙인다.
- UI, 채팅, HTTP, MCP, A2A, CLI는 그 액션을 호출하는 표면이 된다.
이렇게 보면 MCP나 A2A는 별도 제품이 아니라 제품 액션의 외부 노출면이 된다. 한국 팀이 AI 기능을 붙일 때도 이 관점이 중요하다. “MCP 서버를 하나 만들자”보다 먼저 물어야 할 질문은 “이 MCP 도구가 실제 제품 액션과 같은 권한·검증·로그 체계를 쓰는가?”다.
채팅창을 붙이는 것과 제품 상태를 공유하는 것은 완전히 다르다
Agent-Native README는 agent와 UI가 “same database and one state”를 공유한다고 설명한다. 또 실시간 멀티플레이어, CRDT merging, live presence, selection ring, agent as a first-class peer editor 같은 표현을 쓴다. 이건 단순한 UX 장식이 아니다.
예를 들어 콘텐츠 편집 앱을 생각해보자. 사용자가 특정 문단을 드래그한 뒤 “이 부분을 더 짧게 바꿔줘”라고 말한다면, 에이전트는 전체 문서 텍스트만 받아서는 부족하다. 사용자가 무엇을 선택했는지, 현재 어떤 블록을 보고 있는지, 그 블록이 어떤 데이터 모델과 연결되어 있는지, 바뀐 결과가 다른 사용자에게 어떻게 동기화되는지까지 알아야 한다.
캘린더 앱도 마찬가지다. 사용자가 회의 카드를 보고 있을 때 에이전트가 “다음 주 같은 시간으로 옮길까요?”라고 제안한다면, 이건 단순 자연어 응답이 아니다. UI selection, 일정 ID, 참석자 권한, 충돌 검사, 외부 캘린더 provider credential, 승인 플로우가 함께 움직여야 한다.
그래서 Agent-Native의 흥미로운 지점은 “채팅 UI가 있다”가 아니라 “채팅이 제품 상태와 붙어 있다”에 있다. 채팅창이 오른쪽 사이드바에 있든, 중앙에 있든, 헤드리스 API로만 쓰이든 핵심은 같다. 에이전트가 제품 바깥에서 추측하는 게 아니라 제품 내부 상태를 근거로 행동해야 한다.
세 가지 제품 형태: headless, rich chat, whole app
Agent-Native 문서와 README는 같은 에이전트 primitive를 세 가지 제품 형태로 사용할 수 있다고 설명한다.
| 형태 | 무엇을 만드는가 | 실무 의미 |
|---|---|---|
| Headless | 코드, CLI, HTTP, MCP, A2A에서 호출되는 에이전트/API | 내부 자동화, 백엔드 워크플로, 외부 에이전트 연결에 적합 |
| Rich chat | 표, 차트, 승인, 설정 플로우, 툴 결과를 렌더링하는 채팅 | 단순 텍스트 챗봇보다 제품형 응답을 만들기 좋음 |
| Whole app | 전체 SaaS UI와 에이전트가 같은 상태를 공유 | AI 기능이 부가기능이 아니라 제품 작동 방식이 됨 |
이 구분은 SEO 키워드처럼 들릴 수 있지만, 실제 제품 설계에서는 꽤 유용하다. 모든 AI 기능을 “챗봇”으로 시작할 필요도 없고, 모든 에이전트를 처음부터 완전한 SaaS 앱으로 만들 필요도 없다. 중요한 건 나중에 형태가 바뀌어도 액션·상태·권한 계약을 다시 짜지 않는 것이다.
Agent-Native가 OpenAI, AG-UI, Claude Agent SDK, Vercel AI SDK chat runtime connectors, MCP, A2A, deep links를 같은 액션 표면에 매달 수 있다고 설명하는 이유도 여기에 있다. 특정 모델 provider나 특정 채팅 SDK 하나에 잠기는 대신, 제품의 중심 계약을 액션과 상태로 잡겠다는 것이다.
저장소 구조가 보여주는 실제 포지션: 프레임워크 + 템플릿 + 운영 가드레일
GitHub API와 저장소 트리를 보면 Agent-Native가 단순 샘플 앱이 아니라 꽤 큰 프레임워크 지향 프로젝트라는 점이 보인다. 최상위에는 packages/core, packages/code-agents-ui, docs가 있고, packages/core/src 안에는 actions, agent, mcp, a2a, jobs, observability, secrets, credentials, collab, templates, deploy 같은 디렉터리가 있다.
package.json도 방향이 뚜렷하다. Node 22 이상, pnpm workspace, Drizzle 계열 SQL, Nitro 호스팅, Vercel AI SDK와 여러 guard 스크립트가 보인다. 특히 guard:no-env-credentials, guard:no-unscoped-credentials, guard:db-tool-scoping, guard:no-localhost-fallback, guard:no-drizzle-push 같은 스크립트 이름은 이 프로젝트가 “데모가 돌아간다”보다 운영 중 실수 방지를 중요하게 본다는 신호다.
이 부분은 한국 개발팀에게 특히 중요하다. AI 에이전트 앱은 데모보다 운영에서 더 어렵다. 모델이 똑똑해질수록, 오히려 아래 문제가 더 크게 터진다.
- 에이전트가 어느 사용자의 credential로 어떤 외부 API를 호출했는가
- 특정 액션이 workspace, org, user scope를 제대로 지켰는가
- 승인 없이 실행되면 안 되는 작업이 자동화 경로로 새지 않았는가
- 에이전트 작업 로그와 비용, 실패율을 관측할 수 있는가
- MCP나 외부 에이전트 연결이 제품 권한 모델을 우회하지 않는가
Agent-Native의 가치는 이 질문들을 제품 초기부터 프레임워크 primitive로 끌어올리는 데 있다.
운영 관점: 에이전트 앱은 “권한 있는 실행면”이다
에이전트가 단순 질의응답만 할 때는 틀린 답이 가장 큰 문제였다. 하지만 에이전트가 캘린더를 수정하고, 이메일을 보내고, 문서를 편집하고, 고객 데이터를 조회하고, 외부 SaaS를 호출하기 시작하면 문제가 바뀐다. 이제 에이전트는 권한 있는 실행면이다.
Agent-Native README가 per-user workspace, skills, memory, instructions, sub-agents, MCP servers, reusable integrations, vault, shared account metadata, credential refs를 한꺼번에 언급하는 이유가 여기에 있다. 이 요소들은 기능 목록이 아니라 운영면이다.
실무적으로는 다음과 같은 설계 원칙이 필요하다.
1) 에이전트 메모리는 개인화 기능이면서 보안 경계다
사용자별 instruction, memory, skill이 SQL-backed workspace에 저장된다는 말은 편리함만 뜻하지 않는다. 어떤 기억이 어떤 사용자와 조직에 속하는지, 어떤 앱에서 접근 가능한지, 삭제·감사·이관이 가능한지가 중요해진다.
2) 외부 연결은 credential이 아니라 capability로 다뤄야 한다
Agent-Native는 Dispatch와 vault, credential refs를 언급한다. 좋은 방향이다. AI 앱에서 credential을 단순 환경변수로 흘리는 순간, 에이전트 경로와 사람 경로의 권한 분리가 어려워진다. 에이전트에게는 “토큰”이 아니라 “승인된 범위의 행동”을 주는 편이 맞다.
3) 관측은 나중에 붙이는 로그가 아니다
에이전트가 어떤 tool call을 했는지, 실패했는지, 승인 대기에서 멈췄는지, 비용이 얼마였는지, 어느 사용자 상태를 바꿨는지 추적할 수 있어야 한다. Agent-Native 저장소에 observability와 jobs가 별도 축으로 보이는 점은 그래서 중요하다.
검색 의도 관점: 왜 이 주제가 지금 랭킹 가치가 있는가
“agent native app”, “AI agent application framework”, “MCP app framework”, “A2A agent app”, “AI SaaS agent architecture” 같은 검색어는 아직 완전히 정착된 카테고리가 아니다. 하지만 수요는 빠르게 생기고 있다. 개발자들은 더 이상 “챗봇 만들기”만 검색하지 않는다. 실제로 궁금한 것은 다음에 가깝다.
- 우리 SaaS에 에이전트를 어떻게 안전하게 붙일까?
- MCP 도구와 기존 제품 API를 어떻게 하나로 관리할까?
- 채팅 UI와 실제 앱 상태를 어떻게 동기화할까?
- 에이전트가 사용자별 권한과 credential을 어떻게 다뤄야 할까?
- 코딩 에이전트, Claude, ChatGPT, Cursor 같은 외부 에이전트가 우리 앱과 연결되면 어떤 구조가 필요한가?
Agent-Native는 이 질문에 대한 하나의 구체적인 답이다. 아직 생태계가 성숙했다고 보기는 어렵지만, 방향은 선명하다. AI 제품 경쟁은 모델 wrapper 경쟁에서 제품 상태와 실행 권한을 누가 더 잘 설계하느냐로 이동하고 있다.
실무 해석: 지금 당장 배울 점 네 가지
Agent-Native를 바로 도입하지 않더라도, 여기서 배울 수 있는 구조적 교훈은 분명하다.
첫째, 제품 액션을 에이전트 툴보다 먼저 정의하라
에이전트가 호출할 tool schema를 급하게 만드는 대신, 사람이 클릭하는 제품 행동과 같은 액션 계약을 먼저 만들 필요가 있다. 그래야 UI, API, MCP, CLI가 같은 검증과 로그를 공유한다.
둘째, 채팅 히스토리보다 현재 제품 상태가 더 중요하다
에이전트가 잘 행동하려면 긴 대화 기록보다 지금 사용자가 보고 있는 화면, 선택한 객체, 권한, 데이터 모델이 더 중요할 때가 많다. context-aware UI가 과장이 아닌 이유다.
셋째, 외부 에이전트 연결은 통합이 아니라 보안 설계다
Claude, ChatGPT, Codex, Cursor, GitHub Copilot, OpenCode 같은 외부 agent host가 제품에 연결되는 순간, MCP endpoint 하나를 여는 문제가 아니다. 어떤 액션을 노출할지, 어떤 승인 단계를 요구할지, 어떤 로그를 남길지 설계해야 한다.
넷째, AI 앱의 차별화는 “모델 호출”보다 “상태 전이 품질”에서 나온다
모델은 점점 commodity에 가까워지고 있다. 반대로 특정 비즈니스 도메인의 상태 전이, 승인, 협업, 재시도, 감사, UI 피드백은 각 팀이 직접 설계해야 한다. Agent-Native가 말하는 “same database and one state”는 이 지점을 찌른다.
리스크와 미지수도 있다
물론 Agent-Native를 그대로 표준으로 받아들이기에는 아직 확인해야 할 것이 많다. 저장소는 크고 야심적이며, 프레임워크가 제공하는 추상화가 실제 프로덕션 팀에게 얼마나 안정적으로 맞을지는 더 봐야 한다. MCP, A2A, AG-UI, Claude Agent SDK, Vercel AI SDK 같은 표면을 한꺼번에 다루는 만큼 복잡도도 생긴다.
또한 “앱이 스스로 개선된다”는 메시지는 강력하지만, 운영자 입장에서는 바로 경계해야 할 문장이기도 하다. self-modifying app은 제품 개발 속도를 높일 수 있지만, 승인·테스트·롤백·감사 체계 없이 열어두면 위험하다. Agent-Native 저장소에 여러 guard 스크립트가 있는 것은 좋은 신호지만, 실제 도입 팀도 자체 정책을 강하게 가져가야 한다.
그래서 이 프로젝트를 볼 때는 “지금 당장 모든 것을 대체할 프레임워크”보다 “AI 앱 아키텍처가 어디로 가는지 보여주는 진한 신호”로 읽는 편이 안전하다.
결론: AI 앱의 중심은 채팅창이 아니라 제품 런타임이다
Agent-Native가 던지는 메시지는 단순하다. AI 앱을 만든다는 것은 모델 호출 버튼을 붙이는 일이 아니다. 사람이 클릭하는 UI, 에이전트가 호출하는 액션, 외부 agent host가 연결되는 프로토콜, 사용자별 권한과 메모리, 관측과 승인 흐름이 같은 제품 런타임 안에서 움직여야 한다.
한국 개발자와 테크 운영자에게 이 흐름은 꽤 실용적인 의미가 있다. 지금 AI 기능을 붙이고 있다면 “어떤 모델을 쓸까?” 다음 질문은 바로 이것이어야 한다.
이 기능은 사람이 클릭해도, 에이전트가 호출해도, 외부 MCP/A2A 경로로 들어와도 같은 상태·권한·로그 체계를 쓰는가?
이 질문에 답하지 못하면 AI 기능은 데모에서 멈춘다. 반대로 이 질문에 답하기 시작하면, 제품은 채팅창이 붙은 SaaS가 아니라 진짜 agent-native application에 가까워진다.