여섯 개의 MCP 도구, 그리고 어댑터가 다음에 열어줄 것 (현재는 17개)

MCP를 말할 수 있는 모델이라면 어떤 것이든 벤더별 커스텀 통합 없이 런타임을 구동할 수 있다. RakuAI의 여섯 도구 계약은 결정론적 권한(deterministic-authority) 런타임을 실제로 만드는 경계이며, 이것이 다른 이들이 그 위에 무언가를 구축하는 인프라로 전환되는 변곡점이다.

런타임은 3월 말부터 Model Context Protocol을 사용해 대화해왔다. 배포된 커밋은 138b538b, “feat(mcp): reframe MCP server from game-agent control to world model runtime orchestration.”이다. 그 커밋 메시지에 담긴 프레이밍의 변화가 이 글의 본질이며, 다음으로 취할 행보가 내가 여기 적어두고 싶은 것이다.

오늘날 런타임에서 MCP는 어떤 모습인가

여섯 개의 도구가, src/mcp/raku_mcp_server.py에 있는 Python 서버에, stdio 트랜스포트로, raku.* 네임스페이스로 존재한다. 도구별·호출자별로 기본값이 거부인(deny-by-default) 권한이 강제된다. 모든 호출은 감사 로그에 기록된다.

여섯 개의 도구:

1. load_world_model(adapter_name, config) 는 월드 모델 백엔드를 등록한다. 오늘 시점에서 어댑터 이름은 자리표시자(placeholder)로, VideoPredictor-v2, NeuralRadianceField, PhysicsFoundation이다. 내일이면 실제 어댑터가 될 것이다.
2. ingest_frame(adapter_name, frame_data, frame_index, timestamp) 는 생성형 모델에서 나온 프레임을 런타임의 씬 그래프로 전달한다.
3. get_scene_state(include_physics, include_transforms) 는 월드에 대한 읽기 전용 스냅샷이다. 모든 모드에서 안전하다.
4. set_render_target(target_type, config) 는 월드가 어디에 렌더링될지 구성한다. WebGL, VR 헤드셋, 네이티브 창, 오프스크린.
5. start_simulation(tick_rate, max_duration, realtime) 은 시뮬레이션 루프를 시작한다. 샌드박스와 개발 환경에서만 가능하다. 프로덕션 서버는 이 호출을 거부한다.
6. get_metrics() 는 성능 스냅샷을 반환한다. FPS, 프레임 시간, 노드 수, 어댑터 부하, 가동 시간. 모든 모드에서 안전하다.

읽기 전용 도구는 모든 환경에서 동작한다. 변형을 일으키는 도구(load, ingest, set, start)는 샌드박스와 개발 환경에서만 동작한다. 프로덕션의 태도는 “외부 에이전트는 물어볼 수는 있지만 지시할 수는 없다”는 것이다. 그 태도는 호출자가 아니라 서버 단에서 강제된다. 오작동하는 파트너가 실수로 프로덕션 월드 모델을 변형할 수 없다.

왜 다른 것이 아니라 이 여섯 개인가

3월 이전의 초기 버전 MCP 서버는 게임 에이전트용 도구를 노출했다: move_npc, set_dialog, place_object, query_inventory. 이것들은 이 경계에 맞지 않는 도구다. 이들은 엔진 수준의 관심사가 아니라 애플리케이션 수준의 관심사다. 그것들은 엔진을 에이전트가 파고드는 대상으로 만든다. 엔진은 원래 에이전트가 그 위에서 실행되는 대상이어야 한다.

PR #1311의 재구성은 도구 표면을 교체했다. 새로운 도구들은 월드 모델 추상화 위에서 동작한다: 백엔드를 로드하고, 프레임을 밀어넣고, 상태를 조회하고, 렌더링을 구성하고, 시뮬레이션을 시작하고, 지표를 읽는다. NPC를 움직이고 싶은 에이전트는 엔진에서 move_npc를 호출하는 방식이 아니라 월드 모델 어댑터를 통해 프레임을 밀어넣는 방식으로 그렇게 한다. 엔진은 물리, 충돌, 점수, 멀티플레이어 상태에 대한 권한을 계속 유지한다. 월드 모델은 기여자이지 통제자가 아니다.

이 구분이야말로 엔진이 반대편에 어떤 월드 모델이 있는지에 대해 불가지론적(agnostic)일 수 있게 해주는 것이다. Genie, Runway, 서비스를 종료하기 전의 Sora, 자체 개발한 모델, 물리 파운데이션 모델, 실험적인 뉴럴 래디언스 필드 렌더러. 이들 모두가 동일한 여섯 도구 표면을 사용한다. 그 어느 것도 시뮬레이션에서 실제로 일어나는 일에 대한 엔진의 권한을 무시할 수 없다.

이것이 바로 “결정론적 권한 런타임(deterministic authority runtime)”이 실무에서 의미하는 바다. 우리는 파트너들과의 대화에서 이 문구를 자주 쓴다. MCP 표면이 바로 그 말을 사실로 만들어주는 것이다.

오늘과 다음 단계 사이의 간극

MCP가 현재 어디쯤 있는지에 대한 정직한 버전은 이렇다: 서버는 실재하고, 보안 계층은 견고하며, 스키마는 타입이 지정되어 있고, 감사 로그는 작동하며, 어댑터는 스텁(stub)이다.

그 마지막 단어가 이번 토요일의 무게다. 여섯 개의 도구는 adapter_name 문자열을 받는다. 스텁 어댑터들(VideoPredictor-v2, NeuralRadianceField, PhysicsFoundation)은 디스패치 경로를 증명하는 자리표시자다. src/environment/에는 VeoEnvironmentAdapter와 RunwayEnvironmentAdapter를 위한 뼈대 파일들이 있지만 아직 실제 모델에 연결되지는 않았다.

다음 행보는 실제 파트너 모델을 반대편에 둔, 처음부터 끝까지 이어지는 어댑터 하나다. GDC에서 나눈 대화들에서 계속 나오는 후보는 비디오 예측 모델(Runway, 혹은 더 작은 오픈 모델)이 ingest_frame을 통해 씬 프레임 데이터를 공급하는 동안 엔진이 그 아래에서 물리와 충돌을 처리하는 방식이다. 시각적 결과물은 생성형 모델에서 나오고 게임플레이는 엔진에서 나오며, 양쪽 모두 MCP 경계를 통하지 않고서는 서로에 대해 알 필요가 없는 데모.

그 데모가 작동한다면, 다른 모든 어댑터는 이미 알려진 형태가 된다. 어려운 부분은 통합이 아니다. 어려운 부분은 계약이다. 그 계약이 바로 이 여섯 개의 도구다.

이것이 파트너들에게 의미하는 바

두 가지 구체적인 것이 있고, 둘 다 소리 내어 말할 가치가 있다.

MCP를 말할 수 있는 어떤 에이전트든 런타임을 구동할 수 있다. 자신의 생성 결과를 실제 엔진에 대해 테스트하고 싶은 모델 랩은 커스텀 통합이 필요 없다. MCP 클라이언트를 작성하고, 자신의 백엔드로 load_world_model을 호출하고, ingest_frame으로 프레임을 밀어넣고, get_scene_state로 씬 상태를 읽으면 된다. 나머지는 엔진이 처리한다. 파트너는 자신의 모델에 대한 실제 평가 표면을 얻는다. 우리는 엔진이 특정 제공사에 종속되지 않는다는 실제 증거를 얻는다.

런타임 위에 도구를 구축하는 어떤 개발자든 동일한 표면을 사용할 수 있다. MCP 서버는 파트너 전용 API가 아니다. 그것이 바로 API다. 저작 도구를 만드는 스튜디오, 배치 평가를 실행하는 연구자, 새로운 센서를 통합하는 하드웨어 파트너, 이들 모두가 동일한 여섯 개의 도구를 받는다. 공개 API 뒤에 숨겨진 별도의 “내부” API 같은 것은 없다. MCP 표면과 SDK가 사용하는 C API가 있을 뿐이며, 그것이 런타임의 공개된 얼굴 전체다.

아직 해야 할 견고화 작업

기록해두어서 반드시 완료되게 하고 싶은 세 가지 작업이 있다:

프로덕션 배포 하네스. 오늘날 MCP 서버는 테스트 안에서 인스턴스화된다. 서비스 템플릿이 필요하다: 모드와 인증 토큰과 레이트 리밋을 위한 환경 변수 설정, 헬스체크 엔드포인트, 우아한 종료(graceful shutdown), 컨테이너 패키징. 표준적인 운영 위생 작업이다. 화려하지는 않다. 작동하는 서버를 배포 가능한 서버로 바꿔주는 일이다.

다중 제공사 폴백. 주 어댑터가 느리거나 사용할 수 없을 때, 서버는 보조 어댑터로 라우팅할 수 있어야 한다. 전략 문서에서는 이에 대해 한동안 이야기해왔다. 구현은 아직 착지하지 않았다. 형태는 단순하다. 테스트가 진짜 작업이 될 것이다.

어댑터 바운티 프로그램. 어댑터 하나가 처음부터 끝까지 작동하고 계약이 증명되면, 올바른 행보는 어댑터 계약을 공개하고 생태계가 더 많은 어댑터를 작성하도록 초대하는 것이다. Genie를 아는 누군가가 만드는 Genie 어댑터. Marble을 아는 누군가가 만드는 Marble 어댑터. 연구 그룹이 만드는 커스텀 모델 어댑터. 우리의 일은 “모든 모델을 통합하는 것”에서 “계약을 공개하고 구현을 리뷰하는 것”으로 바뀐다.

그 마지막 행보가 내가 가장 기대하는 것이다. MCP가 우리 자신을 위해 만든 도구이기를 멈추고 다른 사람들이 그 위에 무언가를 쌓아 올리는 인프라가 되는 변곡점이다.

앞으로의 한 주

이번 토요일 아침 내가 정리하는 큐에는 첫 번째 실제 어댑터가 올라 있다. 구체적으로 범위가 정해져 있고, 목표는 좁으며, 잘 풀린다면 이번 달 말까지 작동하는 데모가 나올 것이다. 잘 풀리지 않는다면, 아직 바꾸는 비용이 저렴할 때 계약에 대해 우리가 무엇을 잘못 이해했는지 배우게 될 것이다.

만약 당신이 모델 랩에 있고 생성형 모델과 대화하는 런타임을 위한 MCP 스타일 경계가 어떤 모습이어야 하는지에 대한 의견이 있다면, 지금이 그것을 공유하기 좋은 주다. 계약은 아직 고정되지 않았다. 지금 하는 코멘트는 한 분기 후보다 비용이 적게 든다.

여섯 개의 도구, 배포되었고, 감사되었고, 스키마 타입이 지정되었고, 기본값은 거부다. 다음은 어댑터다. 경계는 실재한다. 그 위에서 돌아가는 작업이 그다음에 오는 것이다.

움직이는 토요일.