MCP Apps와 Tasks로 설계하는 서버 렌더 UI와 장기 실행 작업

단발 툴 호출 밖으로 넓어지는 MCP 상호작용

2026년 7월 28일 확정될 차기 Model Context Protocol(MCP) 사양은 에이전트와 도구의 상호작용을 단발 호출만으로 제한하지 않는다. 서버가 상호작용형 화면을 제공하는 MCP Apps(SEP-1865), 그리고 오래 걸리는 작업을 상태 기반으로 다루는 Tasks 확장이 Extensions Framework의 공식 확장으로 자리 잡았다.

대시보드, 폼, 시각화처럼 화면을 통한 조작이 필요한 상황과 수 분~수 시간 동안 진행되는 비동기 작업은 one-shot tool call만으로 자연스럽게 표현하기 어렵다. Apps와 Tasks는 각각 이 두 공백을 메운다.

MCP Apps(SEP-1865)는 서버가 상호작용형 HTML UI를 제공하고 호스트가 샌드박스 iframe에서 이를 렌더링하도록 정의한다.
Tasks 확장은 tools/call의 즉시 응답 대신 태스크 핸들(task handle)을 돌려주며, 클라이언트는 폴링·조회·취소를 통해 작업을 다룬다.
Extensions Framework는 역방향 DNS ID와 capability map을 사용해 협상되는 1급(first-class) 확장 체계다. 코어 사양과 별도로 버전을 관리한다.

2026-05-21 RC 잠금부터 2026-07-28 최종 공표까지는 10주 검증 창으로 잡혔고, Python·TypeScript·Go·C# SDK 베타가 제공됐다. MCP Apps는 2025-11-21 제안된 뒤 2026-01-26 첫 공식 확장으로 출시됐으며, 커뮤니티 mcp-ui와 OpenAI Apps SDK 패턴을 통합했다. Tasks는 2025-11-25 실험적 코어 기능으로 처음 도입된 후 운영 경험을 반영해 코어에서 분리되고 공식 확장으로 승격됐다.

UI 리소스와 태스크 핸들이 움직이는 방식

MCP Apps에서 서버는 HTML/JS 번들을 담은 ui:// 스킴 리소스를 등록한다. 툴 정의는 _meta.ui.resourceUri로 해당 UI 리소스를 사전에 참조한다. 호스트는 리소스를 프리페치하고 캐시한 다음, 렌더링 전에 HTML을 보안 검토(pre-render review)한다. 이후 UI는 제한된 권한(restricted permissions)의 샌드박스 iframe에서 실행된다.

iframe과 호스트는 postMessage 위의 JSON-RPC로 통신한다. UI가 시작한 모든 액션 역시 로깅과 감사를 거치는 경로에 놓이며, 호스트는 UI 발 툴 호출에 명시적 사용자 승인을 요구할 수 있다. 이 구조를 따르면 Claude·ChatGPT·VS Code·Goose 등에서 동일한 UI 자산을 재사용할 수 있다.

Tasks는 클라이언트가 확장 지원 여부를 광고(advertise)하는 데서 출발한다. 서버가 비동기 실행 여부를 결정하는 server-directed 모델이며, tools/call은 태스크 핸들을 반환한다. 클라이언트는 tasks/get으로 상태를 조회하고 tasks/update로 갱신하며 tasks/cancel로 취소한다.

세션 고정(session pinning) 없이 라우팅할 수 있도록 Stateless 지향으로 설계됐고, tasks/list 메서드는 제거됐다. 결과가 준비되면 핸들을 통해 회수하며 다중 라운드트립도 지원한다. 서버 개시 요청은 서버가 클라이언트 요청을 능동 처리하는 동안에만 발생하므로 예기치 않은 프롬프트를 피할 수 있다. 모든 상호작용은 사용자 또는 그 에이전트가 시작한 행위로 추적 가능하다. 확장은 ext-* 저장소에서 위임 관리자(delegated maintainer)가 독립적으로 버전을 관리한다.

⤢✕

화면 중심 작업과 오래 걸리는 실행을 나누어 도입하기

MCP Apps는 텍스트 교환만으로 처리하기 비효율적인 폼, 대시보드, 데이터 탐색, 문서 리뷰부터 적용할 수 있다. Tasks는 배치 처리, 대용량 분석, 외부 시스템 연동처럼 수 초 이상 걸리는 작업에 선택한다.

장기 실행 작업에서는 Stateless 태스크 모델을 사용해 로드밸런서와 수평 확장 환경에서 세션 고정을 피하는 구성이 가능하다. 핸들 기반 재개(resume)를 설계하면 클라이언트 재접속과 네트워크 단절에도 대응할 수 있다. 폴링 주기, 타임아웃, 취소 정책은 SLA에 맞춰 표준화해야 한다.

UI에서 시작된 액션과 태스크 전이는 JSON-RPC 로그에 적재해 규제 대응을 위한 감사 추적을 남긴다. UI 발 툴 호출에는 명시적 동의 게이트를 두고, iframe에는 최소 권한(least privilege) 샌드박스를 강제한다. HTML 템플릿은 CSP와 정적 스캔을 포함한 사전 검토 파이프라인에서 다룬다.

운영 비용에는 장기 태스크의 폴링과 상태 보관에 필요한 서버 리소스, UI 자산 캐시와 CDN 비용을 포함한다. 코어 사양과 분리된 확장 버저닝에 맞춰 업그레이드 주기도 관리해야 한다. capability map 협상은 미지원 클라이언트의 그레이스풀 폴백에 쓰이고, ext-* 확장 버전 핀과 호환성 매트릭스는 배포 파이프라인에 통합할 수 있다.

클라이언트 UI와 단발 호출에 비해 달라지는 지점

구분	MCP Apps 서버 렌더 UI	클라이언트 전용 UI
렌더 주체	서버 선언 HTML을 호스트가 iframe 렌더	클라이언트가 자체 코드로 구현
상호운용	Claude·ChatGPT·VS Code 등 크로스 호환	클라이언트별 재구현 필요
감사·동의	JSON-RPC 통합 경로, UI 액션 로깅	클라이언트 구현 의존, 표준 부재
배포	ui:// 리소스 중앙 관리·캐시	클라이언트 릴리스에 종속

구분	Tasks 장기 실행	단발 툴 호출
응답 모델	task handle + 폴링/취소	즉시 동기 응답
적용 작업	분~시간 단위 비동기 작업	초 단위 짧은 작업
확장성	Stateless, 세션 고정 불필요	단순하나 장기 작업 부적합
표준 vs 벤더	공식 확장 프레임워크 표준	벤더 전용 확장은 이식성 낮음

엔터프라이즈 거버넌스에 연결되는 설계 기준

Apps와 Tasks는 같은 JSON-RPC 기반 위에서 UI와 비동기 작업을 한 흐름으로 묶는다. 이기종 에이전트-도구 생태계의 상호운용 표준을 강화하는 구조다. 확장 프레임워크는 코어의 안정성과 기능 진화를 분리하므로 EA(Enterprise Architecture) 관점에서 변화 관리에도 활용할 수 있다.

UI 액션과 태스크 전이의 감사 추적성은 내부통제와 컴플라이언스(ISMS-P, 개인정보) 대응 근거가 된다. 최소 권한 샌드박스와 명시적 동의 게이트는 자동화 과정의 오작동과 권한 남용을 통제한다. capability 협상에 따른 그레이스풀 폴백은 다벤더 환경에서 서비스 연속성을 보장하는 수단이다.

정보전략(ISP) 관점에서는 표준 확장을 채택해 벤더 종속(lock-in)을 완화하고, TCO의 예측성과 이식성을 높이는 방향으로 볼 수 있다.

2026년 이후의 확장 경로

2026-07-28 최종 사양 공표 뒤에는 SDK GA와 클라이언트 구현 확산이 가속될 전망이다. MCP Apps 기반 서버 렌더 UI는 에이전트 앱 배포의 사실상 표준으로 정착하고, 앱 스토어형 유통 생태계를 형성할 가능성이 있다.

Tasks 확장은 리서치와 데이터 파이프라인 같은 장기 실행 에이전트 워크플로를 본격화한다. Extensions Track(SEP 프로세스)은 실험적 확장을 공식화하는 파이프라인을 활성화할 수 있다. Stateless Core와 결합하면 서버리스와 수평 확장 배포의 최적화가 가능해지고, 엔터프라이즈 채택도 본격화될 전망이다.