앞 글에서 창이 두 개라고 했다. 사람이 기계를 직접 다루는 창은 MCP가 겨냥한 자리가 아니었고, 빠진 것은 화면이라고 했다.
이 글은 그 화면을 어디서 가져오느냐다.
전제 하나를 바꾼다
보통은 호스트가 화면을 안다. 어떤 장치가 어떤 값을 주는지, 그 값을 어떤 위젯으로 그릴지, 어떤 버튼이 어떤 명령을 보낼지를 앱이 알고 있다. 그래서 장치가 하나 늘면 앱을 고친다.
바꾸는 전제는 이것이다. 화면을 호스트가 아니라 장치가 정의한다.
장치는 이미 MCP 서버로서 자기 기능을 도구로 노출한다. 여기에 하나를 더한다 — 자기 화면을 선언적으로 서술한다. 클라이언트는 그 서술을 받아 네이티브로 그린다. 브라우저도, 내장 웹엔진도 필요 없다.
그러면 클라이언트는 무엇을 그릴지 미리 알 필요가 없다. 처음 보는 장치도 붙는 순간 다룰 수 있다.
책상 위의 두 대
이걸 말로 하면 그럴듯하게 들리고, 그래서 실물로 확인했다.
보드 두 대다. STM32H723은 USB 시리얼로 붙고, ESP32는 Wi-Fi로 붙는다. 발견 방식도 다르다 — 하나는 포트를 열어 찾고, 하나는 네트워크에서 찾는다. 전기적으로도 프로토콜 전송로도 서로 남남이다.
각 보드에 브리지가 붙어 자기 기능을 도구로 내놓고, 자기 화면을 리소스로 내놓는다. 그리고 클라이언트는 양쪽에 대해 동일하다. 보드별 분기가 없다.
화면이 뜬다. 버튼을 누르면 책상 위의 LED가 실제로 켜진다.
이 샘플에는 규칙이 하나 걸려 있다 — 보드가 없으면 통과시키지 않는다. 시뮬레이션으로 대체하지 않고, 어느 포트를 찾았는지 밝히고 실패로 끝낸다. 하드웨어 없이 "검증"되는 하드웨어 이야기는 검증된 것이 아니기 때문이다.