우리가 선 자리 — 어디서 시작했고 무엇을 제안하는가

열세 글을 지나왔다. 접는다.

두 축

"그거랑 뭐가 다르냐"는 두 개의 질문이었다.

장치 안에서 앱을 돌리는 플랫폼에게는 — 비즈니스의 주인이 누구인가. 저쪽은 디바이스를 가진 쪽 하나가 사업을 만들고, 확장이 대수로 정해진다. 여기서는 도메인을 가진 사람들이 각자 만들고, 확장이 도메인 수로 정해진다. 그리고 그 둘은 싸울 자리가 아니다 — 그 안에 앱 하나로 들어가면 그 화면이 바깥의 장치들을 다루는 자리가 된다.

모델이 띄우는 창에게는 — 그 창의 주인이 누구인가. MCP Apps는 모델이 사람에게 보여주는 창이고, 여기는 사람이 기계를 직접 다루는 창이다. 앞의 것은 모델을 빼면 사라지고, 뒤의 것은 모델이 없어도 돌아간다. 그리고 둘은 같은 화면에 함께 있을 수 있다.

층이 다르니 두 답이 서로를 깎지 않는다. 이 권은 어느 쪽도 깎지 않으려고 이 순서로 썼다.

어디서 시작했나

이 작업은 MCP를 보고 시작한 것이 아니다.

선언만으로 앱이 도는 런타임을 그 전부터 만들어 왔다. 자체 샌드박스, 상태 격리, 리소스 관리, 실행 엔진을 갖춘 구조였다. MCP가 공개된 뒤 그 위에 연결 계층을 얹었다.

공개 기록은 이렇다.

현재 UI 런타임은 1.4 스펙을 구현한다. 158개 위젯, Material 3 테마, 디자인 토큰 왕복, 다중 서버 오케스트레이션. 폼팩터는 여섯이고 그중 하나가 embedded다 — 호스트가 고정해 쓰는, 키오스크와 산업 장비와 차량 콘솔을 위한 것이다.

날짜를 앞세우려는 게 아니다. 이 권의 앞 열세 글이 날짜를 한 번도 꺼내지 않은 것이 그 뜻이다. 차이를 먼저 말하고, 물으면 날짜를 댄다.

이 표가 말하는 것은 하나다 — 다른 쪽에서 같은 문제를 풀고 있었다. 저쪽은 웹 호스트에서 출발했고 이쪽은 장치에서 출발했다. 서로를 몰랐을 뿐이다.

여기서부터는 도메인이 한다

이 구조가 여는 자리와, 그 자리를 채우는 쪽은 다르다.

채널마다 다른 등급의 화면. 한 서버가 접속한 자리에 따라 다른 화면을 내주는 것은 이 권에서 화면으로 확인했다. 등급을 몇 층으로 나누고 어느 자리에 무엇을 열지는 그 장비를 아는 쪽이 정한다 — 그 결정이 바깥으로 새지 않는 것이 이 구조의 요점이다.

현장의 통신 규격. 산업 버스든 선급 규격이든, 그것을 받는 자리는 장치 쪽이다. 장치가 자기 기능을 내밀면 화면은 그대로 따라온다 — 규격이 바뀌어도 화면을 다시 짜지 않는다.

도메인의 검증 체계. 검증의 주체는 장비를 만든 쪽에 그대로 남는다. 화면이 기능을 복제하지 않기 때문이다. 이 권의 축 하나가 그것이었다.

세 자리 모두 장비를 만든 쪽이 채운다. 이 구조는 그 셋을 대신하지 않고, 각각이 들어올 자리를 정해 둔다.

제안

MCP는 확장의 길을 열어 뒀고 작업 그룹 위임 모델로 가는 중이다. 지금 있는 자리는 전송, 인증, 레지스트리, 보안, 멀티모달리티, 컴플라이언스다.

제약 환경과 물리 장치를 다루는 자리는 아직 없다.

우리는 그 논의를 시작하자고 제안한다. 스펙을 새로 만들자는 것이 아니라, 임베디드에서 무엇이 되고 무엇이 안 되는지를 돌아가는 구현을 갖고 정리하자는 것이다. 실제로 올려 봐야 알 수 있는 것들이 있다 — 이 권의 열세 글이 그 목록의 일부다.

같은 문제를 다른 쪽에서 풀고 계신 분들과 이야기하고 싶다.

마지막으로

이 권은 "우리가 더 낫다"를 한 번도 쓰지 않았다. 쓸 필요가 없어서다.

주인이 다르면 되는 일과 안 되는 일이 저절로 갈린다. 그 갈림을 열세 번 적었고, 그중 확인할 수 있는 것은 화면으로 확인했다.

그리고 이 구조는 문서 위에 서 있다. 선언이 무엇을 보장하는지가 적혀 있고, 화면은 적힌 그대로 나온다. 이 권의 근거는 전부 거기서 나왔다.

---

makemind.dev 「탐구」 — 이 권의 실측은 전부 함께 실린 샘플과 프로브에서 나왔다.