에이전트가 서버 경계를 넘어 브라우저 탭 안으로 들어오고 있다. Focused Labs의 분석에 따르면, 엔터프라이즈 AI 에이전트는 더 이상 서버에만 머물지 않는다. 선택된 텍스트, 저장되지 않은 폼 데이터, 현재 라우트, 뷰포트 크기, 브라우저 권한 상태—이 모든 것은 클라이언트만 알고 있다. 서버는 오래된 레코드 스냅샷만 쥐고 있을 뿐이다. 에이전트가 '지금 이 순간'을 맥락으로 삼아 행동해야 한다면, 클라이언트 런타임이 실행 표면의 일부가 될 수밖에 없다.
문제는 이 흐름이 자연스럽게 안착하지 않는다는 점이다. 가장 쉬운 접근은 앱 상태를 통째로 직렬화해서 서버로 보내고, 모델이 응답하면 UI에 패치하는 방식이다. 첫 번째 데모는 동작한다. 하지만 직렬화 형태가 바뀌는 순간 모델은 낡은 컨텍스트로 작동하고, UI가 유저 액션에서 나온 것인지 툴 실행 결과인지 구분할 수 없게 된다. 이 '사이드 채널' 방식이 실패하는 이유는 기술 부채가 아니라 계약의 부재 때문이다.
프론트엔드 툴은 계약이다. AG-UI는 에이전트에게 전달되는 툴을 런타임에 프론트엔드가 직접 정의하는 함수로 설계한다. 툴 이름, 설명, JSON Schema 파라미터—여기까지는 기존 MCP 툴과 비슷하다. 결정적인 차이는 이 툴을 언제, 누가, 어떤 조건에서 에이전트에 노출할지를 프론트엔드가 통제한다는 점이다. insertApprovedClause는 레코드가 편집 가능하고, 조항이 승인 라이브러리에서 왔고, 유저가 수정 권한을 가질 때만 활성화된다. sendCustomerReply는 초안 작성은 자유롭지만 전송은 승인이 필요하다. 이처럼 툴의 유효 범위를 애플리케이션 컨텍스트와 권한 상태에 따라 동적으로 제어하는 것, 이것이 프론트엔드가 에이전트 아키텍처에서 단순한 렌더링 셸이 아닌 실행 인프라로 격상되는 지점이다.
여기서 AG-UI의 위치가 선명해진다. MCP가 에이전트와 툴·데이터 사이의 표준 인터페이스를 제공하고, A2A가 에이전트 간 통신을 정의한다면, AG-UI는 에이전트와 사용자 대면 애플리케이션 사이의 레이어를 담당한다. 스트리밍 업데이트, 멀티모달 입력, 공유 상태, 프론트엔드 툴 콜, Human-in-the-loop 인터럽트—이 모든 것이 AG-UI의 관할이다. Microsoft의 에이전트 프레임워크도 같은 방향을 가리키며, 실시간 스트리밍·세션 관리·상태 동기화·승인 워크플로우를 웹·모바일 클라이언트 수준에서 명시적으로 다룬다.
그런데 이 구조가 작동하려면 반드시 해결해야 할 보안 문제가 있다. dev.to의 MCP 인증 분석이 지적하듯, Cursor·Claude Code 같은 프론트엔드 AI 도구가 MCP 서버에 연결할 때 사용하는 크리덴셜 관리는 현재 사실상 무방비 상태다. API 키가 클라이언트 설정 파일에 하드코딩되고, 팀원 전원이 같은 키를 공유하며, 누가 어떤 툴 콜을 발생시켰는지 추적할 방법이 없다. 에이전트가 단순 코딩 어시스턴트일 때는 불편한 수준이지만, 에이전트가 CRM 레코드를 수정하고 고객에게 이메일을 보내는 실행 주체가 되면 이건 보안 사고의 전제 조건이 된다.
해법의 방향은 MCP 게이트웨이다. 실제 서비스 크리덴셜은 게이트웨이가 보관하고, 각 개발자·에이전트에게는 스코프가 제한된 그랜트 토큰만 발급한다. 클라이언트 설정에는 실제 API 키 대신 게이트웨이 URL과 그랜트 토큰만 들어간다. 퇴사자 처리도 키 로테이션이 아니라 토큰 한 개 revoke로 끝난다. 프론트엔드 에이전트 통합에서 크리덴셜 설계를 뒤로 미루면, AG-UI가 아무리 잘 설계되어 있어도 실행 경로 전체가 감사 불가능한 블랙박스가 된다.
두 흐름을 종합하면 프론트엔드 개발자가 지금 설계해야 할 것이 윤곽을 드러낸다. 첫째, 툴을 UI 편의 기능이 아니라 타입 계약으로 정의하라. 툴의 활성화 조건, 파라미터 검증, 실행 후 상태 반영, 대화 히스토리 삽입까지 하나의 라이프사이클로 관리해야 한다. 둘째, Human-in-the-loop를 UX 옵션이 아니라 아키텍처 레이어로 설계하라. 승인이 필요한 사이드 이펙트와 그렇지 않은 것을 툴 레벨에서 명시적으로 분리해야 한다. 셋째, 크리덴셜을 클라이언트 밖으로 꺼내라. Cursor나 Claude Code로 MCP 툴을 연결하는 순간부터 게이트웨이 패턴을 고려해야 한다.
시각적 빌더나 노코드 워크플로우 툴이 이 경계를 대신할 수 없다. OpenAI가 AgentKit의 Visual Builder를 2026년 11월에 종료하고 SDK와 코드 기반 워크플로우로 방향을 선회한 것은 우연이 아니다. 캔버스는 의도를 스케치할 수 있지만, 현재 브라우저 선택 항목이 툴 콜 인수와 여전히 일치하는지 검증할 수 없고, 승인 프롬프트가 실제 사이드 이펙트를 정확히 반영하는지 증명할 수도 없다. 이 경계는 애플리케이션 아키텍처—타입 정의된 툴, 스코프 크리덴셜, 상태 동기화, 검토 가능한 사이드 이펙트, 실행 추적—가 소유해야 한다.
에이전트 거버넌스는 서버 경로가 아닌 실행 경로를 따른다. 그 실행 경로가 이제 브라우저 안까지 연장되었다. 프론트엔드 개발자에게 이것은 더 많은 책임이 생겼다는 신호가 아니라, UI가 드디어 '에이전트가 실제로 작동하는 공간'의 설계자가 되었다는 신호다.