MCP는 모델이 도구와 대화하기 위한 프로토콜로 시작했다. 모델이 서버에 무엇이 있는지 묻고, 도구를 부르고, 결과를 받는다. 사람은 그 대화의 바깥에 있었고, 화면이 필요하면 글자로 돌아왔다.
도구가 늘면서 글자로는 부족해졌다. 표를 보여줘야 하고, 지도를 띄워야 하고, 버튼을 눌러야 했다. 창이 필요해진 것이다.
여기서 갈린다. 창은 한 종류가 아니다.
창 ① — 모델이 사람에게 보여주는 창
2025년 11월, MCP-UI 커뮤니티와 OpenAI의 Apps SDK가 같은 필요를 각자 풀고 있었다. 그 둘이 합쳐져 MCP Apps(SEP-1865)가 됐고, MCP 최초의 공식 확장으로 Final에 도달했다.
구조는 이렇다.
- 서버가
ui://스킴으로 UI 리소스를 미리 선언한다 - 도구가 메타데이터로 그 리소스를 참조한다
- 도구가 호출되면 호스트가 샌드박스 iframe에 HTML을 렌더링한다
- iframe과 호스트는 양방향으로 통신한다
- UI가 도구를 호출할 때는 사용자 동의를 받는다
잘 설계된 스펙이다. 사전 선언 덕에 호스트가 미리 받아 캐시하고 보안 검토를 할 수 있고, iframe 샌드박스로 신뢰할 수 없는 서버의 UI를 격리한다. HTML만 다루기로 한 결정도 분명하다 — 어디서나 돌고, 보안 모델이 단순하고, 화면을 갈무리할 수 있다.
이 창의 주인은 모델이다. 대화 중에 도구가 불리고, 그 결과가 화면으로 나타난다. 대화의 표현력이 넓어진 것이다.
창 ② — 사람이 기계를 직접 만지는 창
그런데 이런 장면이 있다.
선박의 조타실. 엔진 상태, 연료, 밸러스트, 발전기. 기관장은 콘솔에서 직접 만진다. 선장은 태블릿으로 계기만 본다. 갑판의 선원은 휴대폰으로 알람만 받는다. 같은 장비, 다른 화면, 다른 권한.
여기 모델은 없다. 있으면 좋다 — "3번 발전기 온도가 15분째 오르고 있습니다"라고 먼저 말해 주는 쪽이 낫다. 하지만 없어도 배는 간다. 기관장은 계기를 보고 밸브를 잡는다.
특장차의 제어반도, 농기계의 작업기 조작도, 공장 설비의 운전반도 같다. 사람이 기계를 직접 다루는 창이다. 도구 호출의 결과물이 아니라 조작면 그 자체다.
이 창은 MCP가 원래 겨냥한 자리가 아니었다. 하지만 MCP는 이미 그 일을 할 재료를 갖고 있다 — 장치가 자기 기능을 도구로 노출하고, 상태를 리소스로 내보내고, 변화를 알린다. 빠진 것은 화면이다.
왜 창 ①로 창 ②를 만들 수 없는가
우열의 문제가 아니라 설계 전제의 문제다. 넷 다 MCP Apps 스펙에 적혀 있는 것이다.
첫째, HTML과 iframe이 요건이다. 렌더 대상이 HTML이고 샌드박싱은 선택이 아니라 필수다. 그런데 수십 KB RAM의 마이크로컨트롤러에는 HTML 엔진이 없다. iframe도 없다. 장치가 자기 LCD에 화면을 그려야 하는 상황에서 이 요건은 넘을 수 없는 벽이다.
둘째, 도구가 호출돼야 UI가 뜬다. 루프가 모델 → 도구 → UI → 사용자다. 모델을 빼면 창이 열리지 않는다. 반면 조타실 콘솔은 배에 전원이 들어오면 켜져 있어야 한다.
셋째, 채널이라는 축이 없다. "같은 장비를 조타실에서는 제어권으로, 휴대폰에서는 조회만" — 이 구분을 표현할 자리가 없다. 창을 여는 호스트가 하나이기 때문이다.
넷째, 위협 모델이 반대 방향이다. MCP Apps가 막는 것은 "신뢰할 수 없는 서버가 내 채팅 클라이언트에 악성 UI를 보내는 것"이다. 장치 제어에서 막아야 하는 것은 "누가 이 기계를 조작해도 되는가"다. 전자는 사용자를 보호하고, 후자는 기계와 사람의 안전을 보호한다.
두 창은 경쟁하지 않는다
MCP Apps는 모델이 사람에게 보여주는 창이고, 장치 제어면은 사람이 기계를 직접 다루는 창이다. 앞의 것은 모델을 빼면 사라지고, 뒤의 것은 모델이 없어도 돌아간다.
그리고 두 창은 같은 화면에 함께 있을 수 있다. 모델이 이상 징후를 말하면서 추이 그래프를 띄우고(창 ①), 그 옆에서 기관장이 직접 밸브를 조작한다(창 ②).
설계자가 말한 것도 그 그림이다 — 모델이 대화하는 창구를 사람도 같이 대화할 수 있는 창으로 만든 것이고, 같이 보면서 할 수도 있다는 것.
여기까지가 둘째 축이다
첫째 축은 사업의 층에서 비즈니스의 주인을 물었고, 둘째 축은 프로토콜의 층에서 창의 주인을 물었다. 층이 다르니 두 답이 서로를 깎지 않는다.
다음 글부터는 화면이다. 창 ②가 실제로 어떻게 만들어지는지 — 장치가 자기 화면을 서빙한다는 것이 무슨 뜻인지, 책상 위의 보드 두 대에서 확인한다.
makemind.dev 「탐구」 — MCP Apps에 대한 서술은 전부 그 스펙 문서에서 확인한 것이다.