MCP·ChatGPT 앱의 이중 iframe 구조와 CSP·샌드박스 보안 원리 해설

핵심 메시지

• MCP 앱·ChatGPT 앱은 기업이 제품과 서비스를 노출하는 새로운 접점으로, '발견성'과 대화 속 '인터랙티브 UI' 두 축을 핵심으로 한다.
• UI는 '뷰(view)'라는 작은 HTML 스니펫으로, 도구 호출의 결과로 렌더링되며 대화 시작 시 tool list 호출에서 미리 광고된다.
• 콘텐츠 보안 정책(CSP)의 script-src는 모든 스크립트에 요청마다 생성되는 nonce 서명을 요구해, 외부 앱의 임의 JS 실행을 막는다.
• iframe의 srcdoc 방식은 부모와 같은 출처·CSP를 공유해 스크립트가 차단되고, CSP를 풀면 앱이 ChatGPT의 로컬 스토리지·쿠키에 접근할 위험이 생긴다.
• 샌드박스로 출처를 null로 만들면 스토리지·쿠키를 못 쓰고, allow-same-origin을 더하면 다시 보안 구멍이 생긴다. 그래서 src로 외부 엔드포인트를 불러오는 방향으로 이어진다.

쉽게 이해하기

MCP 호스팅 기업 Alpic의 CTO 겸 공동창업자 프레드(Frédéric Barthelet)는 ChatGPT 앱과 MCP 앱이 대화 안에 외부 UI를 그릴 때 발견한 '이중 iframe(iframe 안의 iframe)' 구조를 파고든다. 그는 먼저 MCP 앱이 무엇인지 정리한다. 이는 기업이 제품·서비스를 노출하는 새로운 표면이자 획득 채널로, 두 가지가 핵심이다. 하나는 발견성(앱 스토어·커넥터에서 탐색되고 대화 맥락에서 자동으로 불려옴), 다른 하나는 기존의 텍스트 전용을 넘어선 대화 속 인터랙티브 UI다.

UI는 '뷰'라 불리는 작은 HTML 스니펫으로 제공된다. 뷰는 도구 호출의 결과로 렌더링되며, 서버는 특정 도구에 '이 결과는 이런 UI로 보여주는 게 좋다'는 메타데이터를 붙인다. 모든 뷰는 대화 시작 시점의 tool list 호출에서 미리 광고되므로, 필요한 리소스를 캐시해 두거나 도구 호출 시점에 받아올 수 있다. 호스트는 새 iframe을 만들어 거기에 도구 결과를 주입해 동적 콘텐츠를 렌더링한다.

그는 ChatGPT가 서드파티 UI를 어떻게 그리는지 궁금해 들여다보다가 iframe이 이중으로 중첩된 것을 발견했다. 그 배경에는 콘텐츠 보안 정책(CSP)이 있다. CSP는 서버가 응답 헤더로 내려보내는 지시문으로, frame-src(어떤 사이트를 iframe으로 그릴 수 있는지)와 script-src(어떤 스크립트를 실행할 수 있는지)가 특히 중요하다. ChatGPT의 script-src는 모든 스크립트가 요청마다 만들어지는 nonce로 서명되기를 요구해, 앱이 임의의 JS를 실행하지 못하게 막는다.

iframe을 채우는 방법은 두 가지다. src(브라우저가 불러올 다른 페이지의 URL)와 srcdoc(외부 로딩 없이 내용을 직접 주입). srcdoc으로 MCP 서버의 리소스를 바로 넣으면, 그 iframe은 호스트와 동일한 출처와 CSP를 공유해 스크립트가 차단된다. 보안을 풀어 임의 코드 실행을 허용하면(권장되지 않는 실험), 같은 출처를 공유하는 탓에 앱이 ChatGPT의 로컬 스토리지나 쿠키에 접근해 백엔드로 빼돌릴 수 있어 오픈AI 입장에서 허용할 수 없다.

대안으로 sandbox 속성을 쓰면 iframe이 'null 출처'로 렌더링돼 부모 출처를 공유하지 않아 스크립트가 부모 DOM에 접근하지 못한다. 그러나 출처 인덱싱에 의존하는 기능(로컬 스토리지·IndexedDB·쿠키)을 모두 잃는다. 다시 allow-same-origin을 붙여 출처를 되살리면 샌드박스를 벗어나 부모 스토리지·쿠키에 접근할 수 있는 원점으로 되돌아간다. 결국 srcdoc은 답이 아니며, src 속성으로 개발자가 자신의 서버에 뷰(작은 HTML 앱)를 정상 엔드포인트로 노출해 불러오는 방향으로 논의가 이어진다.

주요 인사이트

• MCP의 앱 확장은 MCP UI에서 출발해 지난해 10월 오픈AI의 Apps SDK로 공개되고, 여러 클라이언트에 표준화된 MCP의 첫 공식 확장으로 자리 잡았다.
• 보안과 기능은 정면으로 충돌한다. 외부 UI에 스크립트를 허용하면서도 호스트의 민감 데이터(스토리지·쿠키) 접근은 막아야 한다는 요구가 이중 iframe 설계의 근본 동기다.
• CSP의 nonce 서명은 강력한 보안 기능이지만, 바로 그 때문에 외부 앱이 같은 출처에서 JS를 실행하는 단순한 길이 막힌다.
• 샌드박스의 null 출처와 allow-same-origin은 trade-off 관계여서, 둘을 동시에 만족시키려는 시도는 보안 구멍으로 되돌아간다.
• 이런 제약을 우회하는 현실적 해법은 뷰를 개발자 서버의 일반 엔드포인트로 노출하고 iframe의 src로 불러오는 것이다.

자주 묻는 질문

관련 AI 소식