1편에서 월드모델의 가능성과 구멍을, 2편에서 엔진과 모델이 일을 나누는 하이브리드 설계를 봤다. 남은 질문은 가장 현실적인 것이다. 그래서 이게 언제, 어떻게 진짜로 돌아가는가.
공부하면서 정리가 된 관점 하나를 먼저 적어둔다. 월드모델 데모는 이미 많다. 그런데 데모와 제품 사이에는 관문이 네 개(실시간성, 장기 일관성, 다중 사용자, 통제 가능성) 있고, 이 넷을 동시에, 가장 혹독한 조건으로 요구하는 무대가 게임이다. 수십 밀리초 안에 반응해야 하고, 세션이 몇 시간씩 이어지고, 수만 명이 하나의 세계를 공유하고, 창작자가 정한 규칙대로 굴러가야 한다. 연구실 데모는 이 넷 중 어느 것도 제대로 시험하지 않는다. 게임 회사가 월드모델의 최전선이 된 건 우연이 아니라, 시험 조건이 가장 가혹한 곳이기 때문이다. 이번 편은 로블록스가 이 네 관문을 각각 어떻게 넘으려 하는지를 따라가며, 관문의 일반적인 성격을 정리한다.
네 가지 관문과 각각의 접근법. 게임은 이 넷을 동시에 요구한다.
1. 실시간성: 수 초를 30밀리초로
게임은 플레이어가 행동한 순간 반응해야 한다. 클릭했는데 몇 초 뒤에 결과가 오면 게임이 아니다. 그런데 대부분의 비디오 모델은 클립 전체를 오프라인 패스로 한 번에 생성하고, 시간 축을 앞뒤로 오가며 계산하기 때문에 수 초가 걸린다. 필요한 건 수십 밀리초마다 한 장씩 나오는 프레임이니, 대략 100배를 줄여야 한다.
로블록스가 잡은 열쇠는 self-forcing이다. 클립을 통째로 계산하던 모델을, 방금 생성한 프레임들을 조건으로 다음 한 장을 만드는 자기회귀 모델로 바꾸는 기법이다. 출력이 연속 스트림이 되니 기다림 없이 화면을 흘려보낼 수 있다. LLM이 답변을 다 쓴 뒤 보여주는 게 아니라 토큰을 하나씩 뱉는 것과 같은 구조 전환인데, 이 기법을 만든 창업자의 회사 Morpheus AI를 로블록스가 아예 인수했다.
클립 통째로 수 초 vs 프레임 단위 스트리밍. 비디오 생성의 자기회귀화다.
self-forcing 하나로 끝나는 건 아니라서 레버를 총동원한다. 모델을 작게 만들고, 실행 중 기억장치인 KV 캐시를 압축하고(고해상도에서 비용이 폭주하지 않기 위한 필수 조건이라고 한다), 생성 자체를 게임엔진 인스턴스 바로 옆, 플레이어 가까이의 엣지 데이터센터에 있는 H200·B200급 GPU에서 돌려 네트워크 왕복까지 줄인다. 모델 최적화와 인프라 배치를 하나의 지연시간 예산으로 묶어 다루는 접근이 인상적이었다. 추론 비용 얘기를 모델 팀 따로 인프라 팀 따로 하는 조직이 많다는 걸 생각하면 더 그렇다.
2. 장기 일관성: 세계가 서서히 자기를 잃는 문제
2편에서 본 데이터 모델은 프레임 사이의 드리프트를 눌러준다. 더 어려운 건 시간이다. 세션이 길어지면 작은 오차가 누적되면서 세계가 서서히 자기 자신을 잃는다. 몇 프레임이 아니라 몇 분, 몇 시간을 버텨야 한다.
여기서 필요한 능력은 모델이 자기 히스토리를 훨씬 많이 들고 있는 것, 즉 긴 컨텍스트다. 10분 전에 생성한 장면이 지금 생성하는 장면을 조건 지어야 한다. LLM에서 벌어졌던 롱 컨텍스트 경쟁이 비디오에서 그대로 반복되는 셈인데, 토큰보다 프레임이 훨씬 무겁다는 점에서 난이도는 더 높다. 로블록스는 이 능력을 처음부터 만드는 대신 인수로 확보하는 쪽을 택했다. self-forcing을 가져온 그 Morpheus AI가 장기 컨텍스트 월드모델 연구도 함께 가져왔고, 지금은 컨텍스트 윈도를 늘리는 작업을 하고 있다고 한다.
3. 다중 사용자: 군중을 그리는 것과 굴리는 것
멀티플레이어는 비디오 모델의 한계가 가장 선명하게 드러나는 지점이다. 모델은 500명이 모인 군중을 그릴 수 있다. 하지만 그건 픽셀이지, 각자 위치와 인벤토리와 행동을 가진 500명이 아니다. 2만 명이 실시간으로 반응하는 세계를 관리한다는 건 2만 개의 개별 상태를 추적한다는 뜻이고, 그럴듯한 군중 그림을 생성하는 것과는 다른 종류의 문제다. 작은 규모에서도 요구는 미묘하다. 내가 물건을 옮기면 그걸 볼 수 있는 다른 모든 플레이어의 화면에서도 물건이 움직여야 한다. 행동은 내가 한 것만이 아니라, 그 행동이 다른 모두의 세계에 남기는 효과까지다.
해법의 뼈대는 역할 분리다. 엔진이 서버 권위로서 모두가 공유하는 하나의 진실 상태를 계산하고, 각 플레이어의 비디오 모델은 그 공유 상태를 조건으로 자기 뷰만 생성한다. 시점은 다르지만 사실은 일치하는 화면들이 나온다. 반응성을 위해 즉각적인 행동은 플레이어 기기에서 빠른 예측 시뮬레이션으로 먼저 처리하고, 서버가 잠시 뒤 권위 있는 결과를 확정한다. 나중에는 플레이어 자신의 아바타만 로컬에서 렌더링해 스트리밍 화면 위에 얹는 방식도 검토 중이라는데, 사람이 가장 민감하게 느끼는 자기 움직임만큼은 즉각 반응하게 하려는 것이다. 이걸 수만 명 규모로 하는 건 아직 해결된 기능이 아니라 활발한 연구 영역이라고 한다.
정리하면 이 관문의 답은 “모델을 여러 명이 쓰게 만든다”가 아니라 “진실을 하나로 두고, 모델은 각자의 눈이 된다”였다. 확률적 생성과 공유된 진실은 원리적으로 충돌하기 때문에, 진실 쪽을 아예 모델 밖으로 빼낸 것이다.
4. 통제 가능성: 재미는 규칙에서 나온다
마지막 관문은 기술이라기보다 창작의 문제다. 게임을 재미있게 만드는 건 보통 크리에이터가 넣은 규칙과 로직이지, 얼마나 정교하게 보이느냐가 아니다. 수수하게 생긴 게임도 밑에 깔린 게임플레이가 좋으면 뜬다. 그러니 세계가 모델에서 생성되더라도 그 세계는 창작자가 정한 규칙대로 굴러가야 하는데, 학습된 가중치에서 세계를 뽑아내는 모델에게 “이 규칙만 바꿔줘”라고 말할 방법이 마땅치 않다.
로블록스에 합류한 Lucid AI 팀이 만든 조각은 게임 카트리지 하네스라 부르는 구조다. 진짜 게임엔진의 결정론적 로직으로 비디오 월드모델을 감싸서, 세계는 생성된 것처럼 보이되 행동은 고정된 규칙을 따르게 한다. 플레이어의 조작이 모델에 닿는 경로도 이 하네스다. WASD 이동 입력이 조건 신호로 주입돼서, 앞으로 가기를 누르면 엔진 속 캐릭터만 움직이는 게 아니라 생성되는 화면 자체가 그에 맞게 조향된다. 이동 너머의 통제(텍스트 프롬프트로 지휘할지, 데이터 모델을 통할지)는 아직 정해지지 않은 열린 문제라고 한다. 하네스라는 이름까지 똑같이 등장하는 걸 보고, 2편에서 말한 “생성 모델을 제품으로 만드는 회사들은 같은 모양의 답에 도착한다”는 생각이 더 굳어졌다.
5. 로봇 문제로 번역해보기
이 시리즈를 시작하게 만든 로보틱스 관점으로 돌아와서, 네 관문을 로봇의 언어로 다시 써보면 거의 1:1로 번역된다.
- 실시간성: 로봇 제어 루프도 수십 밀리초 단위다. 행동 결과를 미리 그려보는 모델이 수 초 걸리면 제어에 못 쓴다. 비디오 생성의 자기회귀화는 로봇 쪽에서도 그대로 필요한 전환이다.
- 장기 일관성: 로봇의 내부 세계 모형이 시간이 지나며 실제와 어긋나면(드리프트) 위험해진다. 긴 컨텍스트로 자기 히스토리를 유지하는 문제와 같은 문제다.
- 다중 사용자: 여러 대의 로봇이 협업하려면 공유된 세계 상태가 필요하다. “진실은 하나로 두고 각자는 자기 뷰만 생성한다”는 구조는 로봇 플릿 설계와 정확히 같은 요구다.
- 통제 가능성: 로봇은 안전 규칙과 작업 명세라는 결정론적 제약 아래에서만 움직여야 한다. 생성 모델을 결정론적 하네스로 감싸는 카트리지 구조가 필요해지는 이유도 같다.
그래서 나는 게임에서 검증되는 이 해법들이 몇 년 안에 로보틱스 스택에서 재발명되거나, 아예 직수입될 가능성이 크다고 본다. 게임은 물리 세계의 위험 없이 네 관문을 전부 시험할 수 있는 무대라서, 월드모델 입장에서는 가장 좋은 훈련장이자 시험장이다.
덧붙여 재미있었던 운영 이야기 하나. 게임 하나가 몇 주 만에 300만에서 2,200만 플레이어로 뛸 수 있는 플랫폼이라 용량 예측이 안 되니, 로블록스는 매주 프로덕션 서비스에서 일부러 용량을 제거해 한계를 먼저 찾는 훈련을 돌린다고 한다. 어떤 엔지니어든 시작할 수 있는 자동화된 테스트고, 임원도 엔지니어와 같은 온콜 로테이션을 돈다. 월드모델을 실시간 서비스로 내보내려면 모델 연구만큼이나 이런 운영 근육이 필요하다는 방증으로 읽었다. 일정은 발표 기준으로 이르면 올해 말에서 내년 초 얼리 버전, 첫 품질 목표는 2K 60fps다.
6. 개인적인 견해
1편을 “이 직업이 어떻게 변할까”라는 질문으로 시작했는데, 시리즈를 정리하고 나니 생각이 조금 구체화됐다.
세 편 내내 반복된 구조는 하나였다. 모델이 잘하는 퍼지한 부분과, 시스템이 맡아야 하는 정확한 부분을 가르고, 그 사이의 경계를 설계하는 것. 상태는 서버에 두고 픽셀은 재생성한다는 결정도, 진실은 하나로 두고 뷰는 각자 생성한다는 결정도, 결정론적 하네스로 모델을 감싼다는 결정도 전부 그 경계 긋기였다. 모델 자체는 빠르게 좋아지고 또 빠르게 흔해진다. 그런데 어디까지를 모델에 맡기고 어디부터를 시스템이 책임질지 정하는 일은, 도메인을 알고 실패 비용을 아는 사람이 해야 하는 판단으로 남는다.
데이터 과학자의 일도 결국 그쪽으로 이동하는 게 아닐까 싶다. 모델을 직접 만드는 시간은 줄어들겠지만, 무엇을 상태로 보존하고 무엇을 생성에 맡길지, 어떤 오류는 허용되고 어떤 오류는 시스템이 막아야 하는지를 정하는 일은 늘어난다. 월드모델을 공부하기 시작할 때는 새로운 모델 아키텍처를 배우게 될 줄 알았는데, 끝나고 보니 배운 건 대부분 경계 설계였다. 당분간 공부 방향도 여기에 맞추려 한다.
함께 보면 좋은 글:
- 월드모델 (1) LLM 다음은 뭘까: 다음 프레임을 예측하는 AI
- 월드모델 (2) 모델에게 세계를 통째로 맡기지 않는 이유
- AI Agent는 더 좋은 프롬프트가 아니라 더 좋은 Harness에서 나온다
참고 자료
- Inside Roblox’s Bet on World Models (ByteByteGo)
- Introducing the Roblox Hybrid Architecture (Roblox Newsroom)
본 글은 2026년 7월 21일 기준 공개 자료를 바탕으로 작성했으며, 로블록스 관련 내용은 위 참고 자료의 인터뷰와 발표를 근거로 한다. 다이어그램은 해당 자료의 그림을 참고해 직접 재구성했다. 출시 일정과 사양은 발표 기준이며 변경될 수 있다.