MCP(모델 컨텍스트 프로토콜)가 텍스트만 돌려주던 시절엔 README에 아스키 아트와 이모지가 넘쳤다는 이야기와, 이제는 서버가 UI 리소스를 함께 돌려줘 호스트가 그걸 샌드박스 아이프레임에 렌더링하는 구조를 알게 됨. 리엄 햄프턴이 직접 짠 Go 코드를 5초 동안 프로파일링해 플레임 그래프를 iframe 안에서 바로 띄우는 데모와, 쇼피파이·익스칼리드로·피그마가 MCP 앱을 실제로 쓰는 방식도 담겨 있음.
한줄 코멘트. MCP가 글만 돌려주던 자리에 만질 수 있는 화면이 온다. 새로 생긴 것은 하나다. 서버가 결과와 함께 화면 재료를 돌려주고, 호스트가 그것을 가둬 둔 틀 안에 그린다. 한 번 그리고 끝나지 않고 사용자가 만지면 서버로 되물어 갱신한다는 점이 이 구조의 값이다.
마이크로소프트와 깃허브에서 개발자 애드보킷으로 일하는 두 사람이 발표한다. 한 사람은 VS Code와 코파일럿 쪽을 주로 다룬다고 밝힌다.
주장은 한 줄이다. MCP 앱은 서버 도구가 채팅 안에서 바로 그려지는 화면을 돌려주게 한다.
바닥 구조부터 짚는다. *MCP에는 호스트가 있고, 클라이언트가 있고, 서버가 있다.
글만 오던 자리에 화면이 온다
같은 물음에 무엇이 돌아오나
예전에는 서버가 글만 돌려줬다. 그래서 설명 문서에 아스키 그림과 이모지가 넘쳤다고 말한다.
같은 물음을 그림 그리는 MCP 서버에 던지자 이번에는 다이어그램이 만들어져 떴다. 나란히 놓고 보이는 대비다.
화면이 뜨기까지
*MCP 앱은 세 부분으로 이루어진다.
MCP 앱을 이루는 셋
| 부분 | 무엇인가 |
|---|---|
| 도구 | 모델과 호스트가 부르는 자리 |
| 리소스 | 묶어 둔 HTML 화면 |
| 링크 | 그 도구와 그 화면을 잇는 것 |
도는 순서는 이렇다. 사용자가 묻고, 모델이 어느 도구를 쓸지 정하고, 서버가 결과와 함께 화면 재료를 가리키는 표를 돌려준다. 호스트가 그 HTML을 가져와 가둬 둔 틀 안에 그린다.
거기서 끝나지 않는다. 사용자가 그 화면을 만지면 앱이 서버로 되묻고, 서버가 새 자료를 돌려주면 화면이 갱신된다.
시연은 프로파일링이다. 직접 짠 Go 코드를 5초 동안 재서 어디에 시간이 가장 많이 쓰이는지 본다. 그 결과가 플레임 그래프로 채팅창 안에 떴다.
쓰는 곳으로 쇼피파이와 그림 도구와 피그마를 든다. 다만 피그마 쪽은 잘 그려진 화면 예시를 못 찾았다고 발표자가 그대로 밝힌다.
수치가 없다. 5초는 프로파일링을 돌린 시간이지 이 구조가 무엇을 얼마나 낫게 하는지를 잰 값이 아니다.
화면이 오면 무엇이 나아지는지 견줄 값도 없다. 글로 받을 때와 화면으로 받을 때 사람이 일을 얼마나 빨리 끝내는지가 나오지 않는다. 아스키 그림과 다이어그램을 나란히 보이는 것으로 대신한다.
가둬 둔 틀이 무엇을 막는지 없다. 서버가 준 HTML을 화면에 그린다는 구조라 무엇을 허용하고 무엇을 막는지가 안전의 핵심인데, 가둬 놓았다는 말까지만 있다.
언제까지 유효한 이야기인지도 밝히지 않는다.
용어