적을 쏴 쓰러뜨리고 뒤돌아 걷는다. 방금 지나친 방, 그 안에 떨어진 아이템과 반쯤 열린 문은 이제 화면 밖이다. 몇 분 뒤 되돌아오면 그 상태는 그대로 남아 있을까?
영상 생성 모델로 게임 화면을 그리는 접근은 바로 이 지점에서 가장 자주 무너진다. 화면 밖으로 나간 것은 모델의 '기억' 안에만 남는데, 그 기억은 시간이 갈수록 흐려지기 때문이다.
Matrix-Game 4.0이 택한 원칙은 하나다. 세계가 지금 어떤 상태인지를 모델의 기억에 맡기지 않고, 코드가 따로 붙들어 둔다. 그 덕분에 RTX 5090 그래픽카드 한 장에서 480p·60FPS로 플레이되는 세계를, 키를 누르고 화면에 반영되기까지 112ms 지연으로 돌려낸다.
생성 모델로 조작 가능한 영상을 만드는 흐름 자체는 새롭지 않다. Genie 계열의 '인터랙티브 월드 모델'—플레이어 입력에 반응해 다음 화면을 실시간으로 만들어내는 모델—이 이미 가능성을 보여줬다. 문제는 목표가 '잠깐 둘러보기'에서 '규칙이 살아 있는 긴 게임'으로 바뀌는 순간 드러난다. 영상 생성에만 기대 세계를 유지하려 하면 세 가지가 어긋난다.
상태를 잊는다. 세계의 상태가 생성된 픽셀과 모델의 문맥 안에만 암묵적으로 들어 있다. 시야에서 벗어난 영역은 따로 저장되지 않는다. 그래서 되돌아온 방이 처음 본 방과 달라져 있다.
오차가 쌓인다. 모델은 직전 프레임을 보고 다음 프레임을 만든다(이것을 자기회귀라 부른다). 바로잡아 줄 외부 기준이 없으니 작은 오차가 프레임을 거치며 눈덩이처럼 불어나고, 장면이 서서히 무너진다. 외부 3D 도구로 카메라 위치를 추정해 붙여도, 그 추정의 오차가 쌓이면 결국 같은 벽에 부딪힌다.
규칙을 집행하기 어렵다. 상호작용이 이동과 단순한 환경 반응에 머문다. 명중과 빗맞음을 판정하고, 행동의 결과를 유지하고, 플레이어가 좇을 목표를 거는 일—게임을 게임답게 만드는 규칙을 영상 생성만으로 강제하기는 어렵다. 게다가 지나간 프레임이 공간 정보로 정리되지 않고 그대로 쌓이기만 해서, 플레이가 길어질수록 메모리 비용이 불어난다.
결국 폭발처럼 보이는 화면을 그리는 일과, 그 폭발이 남긴 피해를 계산해 세계에 기록하는 일은 서로 다른 일이다. 확산 모델(노이즈에서 이미지를 복원하며 배우는 생성 모델)은 '무엇이 무엇과 함께 나타나는가'라는 통계적 상관을 배울 뿐, 물리나 인과를 이해하지는 않는다. 그래서 논문은 지금의 영상 생성기를, 세계를 이해하는 모델이라기보다 지시받은 대로 그려 내는 렌더러에 가깝게 본다.[^1]
기존 접근과의 차이부터 짚자. Genie 계열은 영상 생성이 세계 상태까지 떠안는다—방금 본 약점들이 향하는 곳이 이쪽이다. Matrix-Game 4.0은 반대로 간다. 코드로 정의한 세계를 영상 모델이 렌더링하는 쪽에 서되, 거기에 실시간 자기회귀 생성과 코드를 직접 쓰는 AI 에이전트를 결합한다. '조작 가능한 영상'에서 '실행 가능한 세계'로 넘어가려는 것이다.
실제로 어떻게 맞물리는지, 플레이어가 바닥의 기름통을 쏘는 한 장면으로 따라가 보자. 일은 세 몫으로 나뉜다. 엔진이 판정하고, 에이전트가 코드와 설명을 준비하며, 모델이 화면을 만든다.
엔진 — 판정과 기억. 가벼운 게임 엔진이 세계의 상태와 규칙을 코드로 쥔다. 총알이 기름통에 맞았는지, 맞았다면 폭발이 일어나고 주변 체력이 얼마나 깎이는지를 엔진이 정한다. 이때 엔진은 완성된 화면을 그리지 않는다. 기름통도 벽도 캐릭터도 단순한 도형으로만 둔다. 핵심은 폭발로 사라진 기름통과 그을린 바닥의 상태를, 플레이어가 고개를 돌려 화면 밖으로 보내도 엔진이 그대로 들고 있다는 점이다.
에이전트 — 미리 준비하는 쪽. 엔진과 모델 사이에는 멀티모달 코딩 에이전트가 있다('멀티모달'은 글과 이미지를 함께 다룬다는 뜻이다). 중요한 건 이 에이전트가 매 프레임 끼어드는 게 아니라, 플레이가 시작되기 전이나 규칙이 바뀌는 순간에 일한다는 점이다.
하는 일은 두 가지다. 첫째, 플레이어가 말로 새 규칙을 요구하면 그것을 실행 가능한 게임 코드로 바꿔 엔진에 더한다. "몬스터가 사방에서 몰려오게 해줘"라는 한마디는 코드로 옮기는 순간 여러 결정을 요구한다—어디서 나타나고, 어떻게 움직이고 공격하며, 무엇으로 승패를 가르는가. 플레이어가 비워 둔 부분은 에이전트가 기존 장면의 맥락에 맞춰 채운다. 아직 아무것도 정해지지 않은 문을 열면, 에이전트가 "구석에 잠긴 철제 상자가 있는 창고"를 지어 엔진에 등록하고, 그 순간부터 상자의 상태와 열림 여부는 엔진이 관리한다.
둘째, 장면에 등장할 객체마다 어떤 모습인지 설명을 미리 붙여 둔다. 밋밋한 상자 하나에 어떤 재질·어떤 색이라는 의미를 달아 두는 식이다. 이 설명이 나중에 화면을 그릴 때 재료가 된다.
모델 — 화면. 영상 생성 모델은 엔진이 넘긴 단순한 도형 화면을 받는다. 이 도형 화면을 논문은 저폴리 프록시라 부르는데, 질감 없이 기본 도형만 남긴 뼈대 화면이라는 뜻이다. 모델은 이 뼈대의 구조와 움직임은 그대로 지키면서 재질·조명·분위기를 입힌다. 지금 입력과 직전까지의 프레임을 조건으로 영상을 이어 그린다.
플레이 중 실시간 루프는 이렇게 돈다. 플레이어 입력 → 엔진이 상태 갱신 → 도형 화면과 제어 신호 → 영상 렌더링 → 플레이어에게 시각 피드백. 눈여겨볼 점은 이 루프 안에 에이전트가 없다는 것이다. 기름통이 터질 때마다 에이전트가 불려 나와 장면을 설명하는 게 아니다. 폭발 판정은 엔진이 내리고, 그 결과를 화면에 알리는 '설명'은 뒤에서 보듯 엔진의 상태값으로 자동으로 채워진다. 에이전트가 쓴 코드와 미리 붙여 둔 객체 설명은 이 루프가 돌기 전에 이미 준비돼 있다.
이렇게 나눠 두면 세계를 일관되게 유지하는 어려운 일과 실시간 속도가 걸린 일이 분리된다. 엔진은 가벼운 시뮬레이션만 돌리면 되므로, 속도 부담은 렌더링 쪽에 몰아 거기서 집중적으로 깎을 수 있다. 같은 세계 상태를 여러 플레이어가 공유하며 각자 시점으로 보는 길도 이 구조에서 자연스럽게 열린다.
렌더러는 '단순한 도형 화면 → 고화질 영상'이라는 대응을 배워야 한다. 그러려면 똑같은 장면을 두 가지 버전으로 찍은 짝 데이터가 필요하다. 하나는 완성된 고화질 영상, 다른 하나는 같은 카메라·같은 타이밍의 도형 화면이다. 둘이 픽셀 단위로 맞물려야 모델이 "이 뼈대에는 이런 질감"이라는 규칙을 익힌다.
이 짝 데이터는 언리얼 엔진 5에서 합성했다. 짚고 넘어갈 점이 있다. 데이터를 만든 이 언리얼 엔진 5와, 플레이 중 상태·규칙을 쥐는 '가벼운 게임 엔진'은 이름만 비슷할 뿐 서로 다른 쓰임이다. 하나는 학습 재료를 찍는 촬영장이고, 다른 하나는 게임이 실제로 돌아가는 무대다.
다룬 장면은 네 종류—메가시티 운전, 사막 개활지와 중세 성의 3인칭 슈팅, 사막 협곡의 공중전—로, 모두 합쳐 클립 114,334개, 1,712시간 분량이다. (장면별 세부 규모와 평가용으로 떼어 둔 데이터는 부록에 정리했다.)
도형 화면은 이렇게 생겼다. 하늘은 검고 바닥은 회색 체커보드, 건물과 벽은 단색 상자와 각기둥, 나무는 원기둥 위에 구, 캐릭터는 블록 형상이다. 모두 검은 윤곽선만 두르고 질감·반사·그림자는 없다. 공간의 기하 구조만 남기고 나머지를 걷어낸 셈이다. 엔진은 이 화면과 함께 객체 ID, 가시성, 상호작용 이벤트도 기록한다.
이 기록이 '동적 캡션'으로 이어진다. 앞서 실시간 루프에서 미뤄 둔 그 '설명'이 바로 이것이다. 동적 캡션은 모델을 부르지 않고 엔진의 상태값만으로 만든다. 인터랙티브 게임에서는 플레이어가 움직일 때마다 화면이 바뀐다. 카메라를 돌리면 보이는 객체가 달라지고, 이벤트가 객체 상태를 바꾼다. 고정된 설명 한 줄로는 이걸 따라갈 수 없다. 그래서 객체마다 미리 달아 둔 의미 설명(에이전트가 준비해 둔 그 설명이다)에, 지금 보이는 객체와 실시간 상태를 규칙 기반 템플릿으로 채워 넣는다. 차가 떠나면 설명에서 빠지고, 보행자는 "서 있음"에서 "접근 중"으로 바뀌며, 새로 들어온 객체는 "변경"으로 표시된다. 도형 화면이 위치·배치라는 구조를, 캡션이 어떤 객체가 어떤 상태인지라는 의미를 공급해 서로를 채운다. 비전-언어 모델을 거치지 않으니 틀릴 여지가 적고 추가 지연도 없다.
렌더링 모델은 Wan2.2 5B의 Fun Control 변형을 영상-대-영상(V2V) 모델로 개조한 것이다. V2V는 입력 영상을 받아 다른 모습의 영상으로 바꾸는 방식을 말한다. 한 덩이(청크)를 생성할 때 네 가지가 조건으로 들어간다. 엔진의 도형 화면은 "무엇을 어디에 그릴지"를 지시하고, 동적 캡션은 디테일을 공급하며, 공간 메모리 참조 프레임은 플레이어가 같은 장소로 돌아왔을 때 앞서 본 모습과 어긋나지 않게 잡아 주고, 첫 프레임은 새로 만든 영상을 지금 화면에 이어 붙인다. (네트워크 사양과 학습 설정은 부록에 있다.)
실시간은 속도와 반응 사이의 줄다리기다. 한 번에 짧게 생성하면 반응은 빨라지지만 모델을 더 자주 불러야 하고, 호출마다 하는 일이 적으면 GPU가 다음 지시를 기다리며 논다. 논문은 두 가지로 이 줄다리기를 푸는데, 효과부터 말하면 하나는 '그리는 횟수를 줄이는 것'이고 다른 하나는 '이미 한 계산을 다시 쓰는 것'이다.
그리는 횟수를 줄인다. 보통 확산 모델은 노이즈를 여러 번에 걸쳐 조금씩 걷어내며 그림을 완성한다. 이 모델은 증류를 거쳐 그 과정을 한두 번으로 압축한다. 증류란 큰 모델의 결과를 작은 절차로 흉내 내도록 가르치는 것이다. 걷어내는 횟수가 줄면 한 프레임에 드는 계산도 그만큼 줄어 빨라진다.
이미 한 계산을 다시 쓴다. 매 프레임 모든 걸 처음부터 계산하는 대신, 앞서 만든 프레임과 바뀌지 않은 캡션의 중간 계산 결과를 담아 두고 다시 꺼내 쓴다. 특히 캡션은 바뀔 때만 다시 계산한다. 같은 것을 두 번 계산하지 않는 만큼 시간이 빠진다.
누적 최적화 중 큰 몫은 두 단계에서 나왔다. 생성 단계를 한 번으로 줄인 증류가 처리량을 24.2에서 51.2FPS로 끌어올렸고, 여러 연산을 하나로 묶는 커널 최적화가 지연을 367ms에서 121ms로 떨어뜨렸다. 최적화를 하나씩 쌓은 결과와 각 단계의 수치는 부록 표에 정리했다. 전체로는 약 19배 빨라지고 지연은 약 9.9배 낮아졌다.
수치는 조건과 함께 읽어야 오해가 없다. 특히 두 종류의 속도를 섞으면 안 된다. 하나는 모델이 프레임을 찍어내는 처리량이고, 다른 하나는 플레이어가 키를 눌렀을 때 화면이 반응하는 속도다. 측정 대상이 다르다.
논문이 대표 성과로 내세우는 쪽은 반응 속도다. RTX 5090 한 장에서 480p·60FPS로 플레이되고, 키 입력이 화면에 반영되기까지 112ms가 걸린다. 플레이 체감에 직결되는 수치다.
처리량 쪽 대표값은 83FPS로, 단일 스텝 디노이징의 정상 상태 생성 속도다. 이때 GPU 메모리는 최대 약 18.2GiB를 쓴다. 60FPS 플레이와 83FPS 처리량이 따로 적히는 이유가 여기 있다. 앞은 게임이 실제로 돌아가는 프레임 레이트, 뒤는 모델이 프레임을 뽑아내는 속도다.
보급형 GPU로 내려가도 쓸 만하다. 고정 프롬프트에서 단일 스텝 생성이 RTX 5080에서 약 67FPS, RTX 5070 Ti에서 약 58FPS에 이른다. 둘 다 16GiB급이라 로컬 배포 범위가 넓어진다. 단 '고정 프롬프트'라는 단서를 흘려선 안 된다. 앞서 봤듯 캡션이 바뀌면 텍스트 쪽 계산을 다시 해야 하므로, 프롬프트가 고정된 쪽이 속도에서 유리하다. 캡션을 캐시하도록 짠 설계가 그대로 성능 조건으로 드러나는 셈이다.
기능 면에서는 엔진이 규칙을 강제하는, 손볼 수 있는 슈터와 운전 게임을 시연한다. 코드와 모델 가중치, 저폴리 에셋을 공개한다는 점은 연구와 창작 양쪽에 쓸모가 있다.
저자들이 밝힌 제약부터 보자. 학습은 게임마다 모델을 하나씩 두는 방식이다. 네 장면에 각각 전용 모델이 있고, 하나의 범용 렌더러가 모든 게임을 처리하지는 않는다. 데이터도 전부 언리얼 엔진 5에서 합성한 짝 영상이라, 도형→고화질 대응이 이 합성 파이프라인이 낼 수 있는 범위 안에서 정의된다. 보급형 GPU의 높은 FPS도 고정 프롬프트가 전제다.
더 깊은 질문은 '세계가 일관되다'는 말을 뜯어 보면 나온다. 사실 이건 세 가지 다른 요구다.
첫째, 상태가 유지되는 것. 한 번 터진 기름통은 계속 사라진 채로 있어야 한다. 이건 엔진이 상태를 코드로 쥐는 것만으로 꽤 해결된다.
둘째, 같은 장소가 같은 모습으로 보이는 것. 엔진이 "여기 창고가 있다"는 사실을 쥐고 있어도, 그 창고를 다시 그리는 건 모델의 몫이다. 모델이 매번 조금씩 다르게 그리면 상태는 그대로인데 외형이 흔들린다. 공간 메모리 참조 프레임을 따로 두는 이유가 바로 이 외형의 흔들림을 잡기 위해서다.
셋째, 판정과 화면이 일치하는 것. 엔진은 명중으로 판정했는데 화면에서는 총알이 빗나간 듯 보이면, 플레이어는 무엇을 믿어야 할지 알 수 없다. 에이전트가 지어낸 문이 엔진에는 '열 수 없는 장식'으로 등록돼 있는데 화면은 열릴 듯 그려지면, 다가간 플레이어는 헛손질을 하게 된다.
이걸 확인된 결함이라 단정하긴 이르다. 다만 어떻게 들여다볼지는 말할 수 있다. 같은 장소를 떠났다 돌아오며 외형이 얼마나 달라지는지 재 보고, 엔진의 명중 판정과 화면에 그려진 피격 표현이 프레임 단위로 맞아떨어지는지 비교해 보는 것이다. 자연어로 장면과 규칙을 지어내는 흐름이 실제로 얼마나 일관되게 코드로 떨어지는지도 지금은 정성적 시연으로만 확인될 뿐이다. 이 셋을 나눠 측정하는 순간, 설계 소개는 평가의 관점으로 깊어진다.
이 논문에서 우리가 가져오는 원칙은 하나다. 지속되는 상태를 모델의 대화 기억 밖에서 관리한다. 온틀에 이미 구현된 설계를 설명하는 게 아니라, 이 논문을 우리 작업에 비추어 본 관점이다.
지금 우리가 고민하는 문제는 이렇다. AI PM이 한 주 동안 여러 프로젝트의 작업 상태를 쫓으며 아침마다 브리핑을 만든다. 흔한 실패는 모델에게 "지난주 맥락을 기억해서" 상태를 유지시키려는 것이다. PM 에이전트가 대화 기억만으로 "이 태스크는 끝났던가"를 추론하면, 작은 착오가 다음 브리핑으로, 또 그다음으로 번진다. 영상 모델이 세계 상태를 픽셀과 문맥에 품고 있다가 오차가 쌓이는 구조와 같은 함정이다.
그래서 적용할 설계도 같다. 상태의 진실은 모델이 아니라 태스크 DB에 둔다. 어떤 태스크가 어떤 상태인지는 결정론적 시스템이 쥐고, 그 태스크가 이번 대화 문맥 밖에 있어도 상태는 DB에 남는다. 모델은 DB가 내놓은 상태를 사람이 읽을 브리핑으로 옮기고, "이번 주 지연된 것만 리스크 중심으로" 같은 요청을 조회 조건과 분류 규칙으로 번역한다. 동적 캡션을 규칙 기반으로 뽑은 것과 같은 정신이다.
하지만 비유가 그대로 성립하지 않는 지점이 있다. 게임 엔진은 세계의 상태를 스스로 만들어 내므로, 엔진이 쥔 값은 그 자체로 참이다. 업무 DB는 다르다. 태스크 상태는 커밋 로그, 리뷰 승인, 사람의 보고 같은 외부 신호가 들어와야 채워지고, 그 신호는 해석과 확인을 거쳐야 믿을 수 있다. DB가 상태를 '보관'하는 것과 그 상태가 '올바르게 들어오고 갱신되는' 것은 다른 문제다. 그래서 절차를 하나 더 건다. 완료 여부가 모호하거나 출처가 충돌하는 태스크—이를테면 커밋은 올라왔는데 리뷰는 미승인인 경우—는 브리핑에 자동 반영하지 않고 '확인 필요'로 분리해, 사람이나 원 출처에 한 번 되물어 상태를 갱신한 뒤에만 '완료'로 넘긴다.
연구 단계의 기술 보고서이며, 코드와 모델 가중치, 저폴리 게임 에셋을 공개합니다. 공식 저장소가 공개한 모델·게임은 중세 성·고대 이집트·도시 운전 세 종이며(학습에 쓴 사막 협곡 공중전은 공개 목록에 없습니다), 장면마다 전용 모델을 학습한 구조라 공개된 장면 밖으로 바로 확장되지는 않습니다.
아직은 아닙니다. 데이터가 UE5에서 합성한 짝 영상이고 장면마다 모델을 따로 학습한 구조라는 전제가 있습니다. 저자들은 게임 개발 워크플로에서 코딩 에이전트와 신경 렌더링이 어떻게 쓰일 수 있는지를 보여주는 '구체적 예고편'으로 이 작업을 자리매김합니다.
표 1. 학습 데이터
| 장면 | 클립 수 | 분량 | FPS |
|---|---|---|---|
| 중세 성 | 17,848 | 290시간 | 24 |
| 고대 이집트 사막 | 40,296 | 643시간 | 24 |
| 사막 협곡 공중전 | 28,720 | 467시간 | 24 |
| CitySample 메가시티 | 27,470 | 312시간 | 17 |
| 합계 | 114,334 | 1,712시간 |
슈터와 공중전 클립은 대략 1분 길이다. 과적합과 평가 오염을 막으려고 성·사막·도시는 완전한 촬영 세션을 3개씩, 공중전은 멀티머신 촬영 배치 전체를 떼어내 평가용으로만 쓴다. 이 세션들은 학습에 한 클립도 들어가지 않는다.
표 2. 최적화 누적 효과 (RTX 5090, 청크 1잠재프레임=4프레임, KV 윈도우 21잠재프레임)
| 최적화 (누적) | FPS | 지연 |
|---|---|---|
| 기본 Causal Wan2.2 DiT (4스텝, 풀 Wan VAE) | 4.5 | 1110ms |
| + 타이니 VAE(TAEHV) | 6.5 | |
| + RoPE 커널·텍스트 KV 캐시 | 15.4 | |
| + 8비트 가중치·CUDA Graph | 24.2 | |
| + 1스텝 증류 | 51.2 | |
| + 비동기 I/O 파이프라인 | 57.7 | |
| + 퓨즈드 Triton 커널 | 65.8 | 367ms → 121ms |
| + 링 KV 캐시 | 73.7 | |
| + 스플릿-KV FlashAttention | 83.4 |
네트워크 (DiT, 50억 파라미터)
학습 (게임마다 모델 1개)
[^1]: 저자들은 이 '그림으로 옮김'을 야콥슨의 기호 분류 중 기호 간 번역(intersemiotic translation)에 빗댄다. 의미를 쥔 쪽은 상류의 언어 모델이고, 확산 모델은 그 지시를 그림으로 옮긴다는 것이다.