Google A2UI와 MCP Apps 결합, iframe UI를 벗기는 3가지 패턴

AI 요약

• 무슨 일: Google A2UI Team이 A2UI와 MCP Apps를 함께 쓰는 3개 에이전트 UI 패턴을 공개했습니다.
  • 공식 글 날짜는 2026년 6월 17일이며, 예제 코드와 A2UI 문서, MCP Apps 문서를 함께 연결했습니다.
• 핵심 변화: MCP 서버가 application/a2ui+json을 반환하면 호스트가 네이티브 컴포넌트로 화면을 그릴 수 있습니다.
• 실무 쟁점: iframe 자유도와 네이티브 렌더의 보안·일관성을 어디서 나눌지가 에이전트 제품 설계 문제가 됐습니다.

Google Developers Blog에 2026년 6월 17일 올라온 글은 에이전트가 텍스트 답변만 내놓는 시대가 끝났다는 선언보다 구체적입니다. Google A2UI Team은 A2UI와 MCP Apps를 통합하는 글에서 3개 아키텍처 패턴을 제시했습니다. 에이전트가 폼, 차트, 편집기, 게임처럼 조작 가능한 화면을 만들 때 MCP Apps의 iframe 방식과 A2UI의 선언형 렌더 방식을 어떻게 섞을지에 관한 문서입니다.

이번 글이 눈에 띄는 이유는 MCP를 둘러싼 논의가 도구 연결에서 화면 경계로 이동했기 때문입니다. 최근 몇 달 동안 MCP는 에이전트가 파일, 저장소, SaaS, 데이터베이스, 브라우저 도구를 호출하는 연결 규격으로 빠르게 퍼졌습니다. 하지만 도구 호출 결과를 사용자가 어떻게 검토하고 수정할지는 별개의 문제입니다. JSON 한 덩어리나 긴 텍스트 요약만으로는 결제 승인, 좌석 선택, 문서 수정, 데이터 탐색 같은 작업을 안전하게 끝내기 어렵습니다.

Google이 제시한 대립축은 비교적 명확합니다. MCP Apps는 iframe 안에서 표준 웹 기술을 실행하므로 복잡한 UI를 만들 수 있습니다. 반대로 iframe은 호스트 앱의 디자인 시스템과 어긋나거나, 중첩 스크롤과 렌더 지연을 만들거나, 보안 격리 부담을 키울 수 있습니다. A2UI는 HTML, CSS, JavaScript를 직접 보내지 않고 JSON 페이로드로 렌더 의도를 보낸 뒤, 호스트가 자기 네이티브 컴포넌트로 화면을 그리는 방식입니다.

첫 번째 패턴은 A2UI-over-MCP입니다. Google 글은 MCP 서버가 일반 텍스트 응답이나 번들된 웹 앱 대신 application/a2ui+json MIME 타입의 구조화 JSON을 반환할 수 있다고 설명합니다. 이 페이로드는 a2ui://dynamic-ui/recipe-card 같은 URI와 함께 MCP resources/read 또는 tools/call 경로로 전달됩니다. A2UI를 이해하는 호스트는 이 구조를 받아 자기 렌더링 엔진으로 넘깁니다.

정적 UI와 동적 UI의 구분도 이 패턴 안에 들어갑니다. 고정된 개인정보 안내, 설정 패널, 선호도 폼처럼 대화 맥락과 무관한 화면은 MCP Resources의 resources/read에 맞습니다. 반대로 실시간 데이터 시각화, 날씨 카드, 개인화된 추천 카드처럼 실행 시점의 인자와 데이터가 필요한 화면은 MCP Tool 호출인 tools/call에 맞습니다. 이 구분은 에이전트 UI를 모두 LLM이 즉석 생성해야 한다는 착각을 줄입니다.

개발자에게 중요한 지점은 MCP가 백엔드 도구와 데이터 접근을 맡고, A2UI가 프런트엔드 컴포넌트 렌더를 맡는 분리입니다. Google은 이 방식이 React, Flutter, Angular 같은 서로 다른 표면으로 이식될 수 있다고 설명합니다. 같은 MCP 서버가 표면마다 다른 HTML을 준비하는 대신, 호스트가 자기 컴포넌트 카탈로그 안에서 같은 의도를 그리는 구조입니다. 제품팀 입장에서는 디자인 시스템, 접근성, 다크 모드, 모바일 레이아웃을 호스트 쪽에서 계속 통제할 수 있습니다.

두 번째 패턴은 MCP Apps in A2UI입니다. 모든 화면을 선언형 컴포넌트로만 만들 수는 없습니다. 좌석 선택기, 미니 게임, 복잡한 편집기, 지도처럼 상태가 촘촘한 UI는 표준 웹 앱으로 만드는 편이 빠르고 안전할 때가 있습니다. Google은 이 경우 MCP App을 A2UI 컴포넌트 안에 넣고, 점수판이나 요약 카드 같은 주변 UI는 A2UI 네이티브 컴포넌트로 유지하는 방식을 제시했습니다.

A2UI 문서에서 보안 설명은 더 직접적입니다. A2UI는 신뢰할 수 없는 서드파티 코드를 실행하기 위해 double-iframe isolation pattern을 사용한다고 밝힙니다. 내부 iframe에는 sandbox="allow-scripts allow-forms allow-popups allow-modals"를 두되 allow-same-origin은 넣지 않습니다. 이 설정은 내부 앱이 localStorage, sessionStorage, IndexedDB, 쿠키에 접근하지 못하게 만들고, 부모 DOM을 직접 만지는 경로도 줄입니다.

이중 iframe 구조는 단순한 장식이 아닙니다. Google A2UI 샘플의 mcp-apps-in-a2ui-sample은 FastAPI 에이전트, Lit 클라이언트, 샌드박스 프록시, 내부 iframe을 나눕니다. 샘플 README는 개발 환경에서 Vite의 /@fs/ 경로와 개발용 CSP 설정을 쓰지만, 운영 환경에서는 동적 CSP와 엄격한 격리를 구현해야 한다고 적습니다. 에이전트가 만든 UI 정의와 데이터 스트림도 신뢰하지 말아야 한다는 경고가 포함되어 있습니다.

두 번째 패턴의 핵심은 상태 동기화입니다. 예를 들어 Pong 데모에서 공과 패들의 미세 상태는 iframe 안의 MCP App이 다룹니다. 점수가 나면 앱이 도구 호출 이벤트를 보내고, A2UI 컴포넌트 계층이 이를 구조화된 액션 맥락으로 바꿉니다. 에이전트는 점수나 확정 상태 같은 큰 상태만 추적하고, A2UI 렌더링 엔진은 점수판 같은 네이티브 컴포넌트를 다시 채웁니다. DOM을 훑거나 매 순간 상태를 폴링하는 방식이 아니라 명시적인 이벤트 루프를 둔다는 점이 차이입니다.

세 번째 패턴은 A2UI in MCP Apps입니다. 이미 MCP App iframe 컨테이너만 지원하는 오래된 제품이 있다면, 호스트 전체를 A2UI 기반으로 바꾸기 어렵습니다. Google은 이 경우 MCP App 번들 안에 A2UI 렌더러를 넣어 동적 UI를 앱 내부에서 그리는 방식을 제안합니다. 호스트는 iframe을 로드하고, MCP App은 서버에서 받은 application/a2ui+json 응답을 자기 내부 렌더러에 넘깁니다.

이 구조는 기존 웹 앱을 가진 팀에게 현실적인 경로입니다. 예를 들어 문서 편집기 안에서 사용자가 특정 문단을 선택하면, MCP App이 그 맥락을 서버로 보내고, 서버 뒤의 에이전트가 수정 강도나 문체 옵션 같은 동적 컨트롤을 A2UI JSON으로 반환할 수 있습니다. 사용자는 iframe 안에서 컨트롤을 조절하고, 앱은 수정 제안을 생성합니다. 호스트가 A2UI를 네이티브로 지원하지 않아도 에이전트 UI 실험을 시작할 수 있습니다.

세 패턴을 나란히 보면 Google의 메시지는 "A2UI가 MCP Apps를 대체한다"가 아닙니다. A2UI-over-MCP는 정형 화면과 네이티브 렌더가 필요한 곳에 맞고, MCP Apps in A2UI는 복잡한 웹 앱을 제한된 경계 안에 넣는 방법입니다. A2UI in MCP Apps는 기존 iframe 기반 제품에 생성형 UI를 조금씩 추가하는 통로입니다. 선택 기준은 프로토콜 이름보다 화면의 상태 복잡도, 보안 격리, 디자인 통제, 호스트 지원 범위입니다.

이번 발표가 개발자에게 주는 직접 영향은 MCP 서버의 응답 설계입니다. 지금까지 많은 MCP 서버는 도구 결과를 텍스트나 JSON 데이터로만 반환했습니다. A2UI-over-MCP가 자리 잡으면 서버 작성자는 resources/read로 고정 UI를 내보낼지, tools/call로 실행 결과에 맞춘 UI를 반환할지 결정해야 합니다. 그 결정은 프런트엔드팀의 디자인 시스템, 보안팀의 샌드박스 정책, 플랫폼팀의 컴포넌트 카탈로그와 연결됩니다.

또 하나의 영향은 에이전트 제품의 책임 분리입니다. 에이전트가 모든 화면을 직접 만드는 구조는 매력적으로 들리지만, 운영 환경에서는 브랜드 일관성, 접근성, 입력 검증, 권한 표시, 감사 로그가 필요합니다. A2UI는 호스트가 렌더링과 컴포넌트 제한을 통제한다는 점에서 이 요구에 맞습니다. MCP Apps는 복잡한 웹 앱을 빠르게 붙일 수 있지만, 격리와 통신 경계가 제품 품질의 일부가 됩니다.

아직 표준으로 굳었다고 보기에는 이릅니다. Google 글은 A2UI를 지원하는 MCP 확장을 검토 중이라며 GitHub discussion으로 관심을 요청했습니다. 이는 A2UI-over-MCP가 현재 완전히 닫힌 규격이라기보다, 구현자 피드백을 받는 단계라는 뜻입니다. MCP Apps 자체도 호스트별 지원과 보안 모델이 계속 정리되는 중입니다. 따라서 지금 당장 모든 에이전트 UI를 A2UI로 옮기는 결론은 성급합니다.

그렇다고 기다리기만 할 문제도 아닙니다. 이미 에이전트 제품은 사용자의 파일을 고치고, 티켓을 옮기고, 코드 리뷰를 요청하고, 결제나 배포 직전의 승인 화면으로 접근하고 있습니다. 이런 화면에서 "예"와 "아니오" 버튼이 어디서 렌더링되는지, 버튼을 누른 뒤 어떤 도구 호출이 발생하는지, 상태 변경이 감사 로그에 어떻게 남는지는 보안 요구사항입니다. A2UI와 MCP Apps의 결합 논의는 화면 장식보다 승인 경로의 증거성을 다루는 쪽에 가깝습니다.

특히 기업 환경에서는 호스트가 네이티브 컴포넌트를 그린다는 A2UI의 장점이 큽니다. 보안팀은 허용된 컴포넌트 카탈로그, 입력 타입, 링크 정책, 파일 첨부 정책을 미리 심사할 수 있습니다. 디자인팀은 버튼, 경고, 토스트, 테이블, 폼 검증 메시지가 제품 전체에서 같은 의미로 보이게 만들 수 있습니다. 플랫폼팀은 접근성 점검과 다국어 메시지를 호스트 계층에서 처리할 수 있습니다. MCP 서버 작성자는 화면 픽셀보다 데이터, 도구, 상태 전이를 더 명확하게 책임집니다.

반대로 MCP Apps가 필요한 영역도 남습니다. 좌석 배치도, 캔버스 편집기, 지도, 코드 diff 뷰어, 실시간 시뮬레이터처럼 웹 앱 자체가 기능인 화면은 선언형 컴포넌트 목록만으로 재현하기 어렵습니다. 이때 Google의 두 번째 패턴은 iframe을 금지하는 대신, iframe을 제한된 컴포넌트로 취급합니다. 내부 앱은 자기 상호작용을 빠르게 처리하고, 호스트는 승인, 점수, 선택 결과처럼 업무 상태에 필요한 요약만 받습니다. 이 분리는 성능과 보안의 타협선입니다.

개발 조직이 지금 실험한다면 작은 MCP 서버 하나에서 시작하는 편이 현실적입니다. 예를 들어 저장소 분석 도구가 tools/call로 취약 파일 목록을 반환할 때, 텍스트 요약만 보내지 말고 A2UI JSON으로 필터 가능한 표를 함께 돌려주는 식입니다. 그 다음 단계에서 특정 행을 눌렀을 때 패치 제안이나 테스트 실행 버튼을 어떻게 표현할지 정할 수 있습니다. 이 실험은 모델 성능보다 제품 경계에 관한 실험입니다.

이때 성공 기준은 예쁜 데모가 아니라 실패했을 때의 흔적입니다. 잘못된 도구 호출이 거부됐는지, 사용자가 승인한 입력만 서버로 갔는지, iframe 안의 상태가 호스트 권한을 넘지 않았는지 확인해야 합니다.

그래도 이 문서는 에이전트 UI 논의를 한 단계 구체화합니다. "에이전트가 앱을 만든다"는 문장만으로는 운영 제품을 설계할 수 없습니다. 어떤 코드는 iframe 안에서만 실행할지, 어떤 화면은 네이티브 컴포넌트로 제한할지, 어떤 상태는 에이전트가 알고 어떤 상태는 앱 내부에 남길지 정해야 합니다. Google의 3개 패턴은 그 결정을 제품 설계표로 옮길 수 있게 만듭니다.

한국 개발팀이 살펴볼 지점도 분명합니다. 사내 업무 에이전트, 데이터 분석 에이전트, 고객지원 에이전트가 표와 폼을 반환하기 시작하면 "대화형 UI를 누가 소유하는가"가 팀 경계 문제가 됩니다. 백엔드가 MCP 서버를 만들고, 프런트엔드가 A2UI 카탈로그를 관리하고, 보안팀이 iframe 샌드박스와 CSP를 검토하는 구조가 필요합니다. 이번 Google 글은 그 경계를 미리 그려볼 수 있는 참고 설계에 가깝습니다.

마지막으로 이 발표는 MCP 생태계가 단순 연결 규격에서 사용자 경험 규격으로 확장되는 장면입니다. Cloudflare OAuth가 에이전트 배포의 인증 경계를 다뤘다면, A2UI와 MCP Apps의 결합은 에이전트가 만든 결과물을 사람이 검토하고 조작하는 화면 경계를 다룹니다. 에이전트가 실제 업무에 들어갈수록 두 경계는 함께 움직입니다. 권한을 위임받은 에이전트가 어떤 UI로 사용자 확인을 받는지가 다음 제품 경쟁의 작은 단위가 됩니다.