Agentic Game Development as a Verifiable Trajectory Data Engine for Scaling World Models

P. Zhou, H. Wang, Z. Zhang, Y. Ma, Z. Wan, K. Zhang, W. Zhao, and Y. You, "Agentic Game Development as a Verifiable Trajectory Data Engine for Scaling World Models," arXiv:2608.25518, 2026.

월드 모델을 키우는 방법을 물으면 대체로 같은 답이 돌아옵니다. 영상을 더 긁어모으고, 모델을 키우고, 연산을 더 쓴다는 것입니다. 이 논문은 그 답이 비효율이라고 말합니다. 부족한 것은 데이터가 아니라 보상 신호이며, 그 보상 신호를 만들어주는 장치가 게임 개발 현장에 이미 있다는 주장입니다.

저자

싱가포르국립대학교 HPC-AI Lab과 Inf Rec Cardinal AI Lab, UC 버클리, 홍콩과학기술대학교가 함께 낸 논문입니다. 저자 구성이 주장의 방향을 어느 정도 설명해줍니다.

1저자 저우펑페이는 멀티모달 평가 쪽에서 이력을 쌓았습니다. 중국어 멀티모달 벤치마크 CMMU, 다학제 시험 기반 평가 MDK12-Bench, 데이터셋 증류 평가를 재검토한 DD-Ranking에 참여했습니다. 세 작업의 공통점은 "지금 쓰는 점수가 실제로 능력을 재고 있는가"를 의심한다는 것입니다. 이 논문이 공간 생성의 보상 프록시를 문제 삼으며 시작하는 이유가 여기 있습니다.

교신저자 자오왕보는 데이터셋 증류 계열 연구자입니다. 적은 데이터로 같은 학습 효과를 낼 수 있는지를 묻는 분야이니, 데이터를 더 붓는 것으로 문제를 풀지 않겠다는 이 논문의 전제와 방향이 겹칩니다. 또 다른 교신저자 유양은 Colossal-AI를 만든 대규모 분산 학습 쪽 사람입니다. 2017년 ImageNet, 2019년 BERT 학습 속도 기록을 팀 단위로 갈아치운 이력이 있습니다. 스케일링을 가장 잘 아는 사람이 스케일링만으로는 안 된다고 말하는 자리라는 점이 이 논문에서 가장 흥미로운 대목입니다.

장카이펑도 이름을 올렸습니다. 이 논문에서는 독립 연구자로 표기돼 있지만 게임 엔진 기반 동적 세계 모델링을 오래 다뤄온 사람이라, 게임 개발을 데이터 엔진으로 보자는 주장에 실무 감각을 대는 자리로 읽힙니다.

배경

논문의 출발점은 코드 에이전트와 공간 생성의 비대칭입니다.

코드는 실행됩니다. 컴파일러, 테스트, 런타임이 값싸고 조밀한 피드백을 줍니다. 여기에 개발자의 보충 검증이 얹힙니다. 테스트를 통과한 패치라도 유지보수성을 해치거나 제품 목표에 안 맞으면 반려됩니다. 이 사람-컴파일러 이중 검증이 코드 모델의 사후학습을 굴려온 동력입니다.

공간 쪽은 정반대입니다. 생성된 영상이나 3D 장면의 품질은 FVD, CLIP 유사도, MLLM 심판 점수 같은 흐릿한 프록시로 매겨집니다. 저자들은 이 프록시의 오차를 다음과 같이 분해합니다.

\[R_f(x, y) - Q^*(x, y) = \varepsilon(x, y) + b(x, y)\]

\(\varepsilon\)은 평균 0인 잡음이고 \(b\)는 체계적 편향입니다. 잡음은 샘플당 기대 이득을 깎아 학습 효율을 떨어뜨립니다. 문제는 편향입니다. \(R_f\)가 \(Q^*\)와 악용 가능한 방향으로 어긋나 있으면, \(R_f\)를 최적화할수록 프록시 점수는 오르고 실제 품질은 내려갑니다. 연산을 더 부을수록 그 악용이 증폭됩니다.

이 지점에서 저자들은 리처드 서턴의 쓰라린 교훈을 다시 읽자고 제안합니다. 통상적인 요약은 "연산에 따라 확장되는 일반적 방법이 결국 손으로 설계한 사전지식을 이긴다"입니다. 저자들은 이 독법이 게임, 코드, 수학 같은 영역에서는 불완전하다고 봅니다. 그 영역들에서는 확장 가능한 학습이 항상 성공을 정의하는 평가자와 짝지어져 있었기 때문입니다. 게임 규칙, 프로그램 실행, 수치 검사기가 그것입니다. 따라서 진짜 교훈은 아키텍처 설계가 아니라 피드백 채널에서 가장 큰 이득이 나온다는 것이라고 저자들은 정리합니다.

그림 왼쪽이 지금까지의 경로입니다. 공간 데이터를 모아 주관적 어노테이션을 붙이고 저품질 보상을 뽑아내며, 비용은 높고 신호는 흐릿하고 확장성은 나쁩니다. 오른쪽이 논문이 제안하는 대안입니다. 게임 개발을 중심에 놓고 개발 궤적, 검증 가능한 보상, 데이터 스케일링, 재귀적 데이터 플라이휠이 서로를 물고 도는 구조입니다.

저자들은 이 상황을 검증 불가능성 세금이라고 부릅니다. 신뢰할 만한 검증 채널이 없으니 영상, 3D 스캔, 사람 평가를 계속 사다 부어야 하고, 언어 모델을 키울 때보다 그 비용이 훨씬 크다는 것입니다.

왜 게임 엔진인가

현대 게임 엔진에 인코딩된 장면은 실행 가능한 세계 명세입니다. 엔진은 그 명세의 인터프리터이자 런타임이자 부분 검증기입니다.

엔진이 값싸게 확인해주는 것들이 있습니다. 콜라이더 교차, 물리 안정성, 내비메시 도달 가능성, 스크립트 오류, 지정된 에이전트와 시드에서의 목표 달성 여부 같은 것들입니다. 이 신호들의 미덕은 게임하기 어렵다는 데 있습니다. 충돌 질의는 그럴듯한 텍스처에 속지 않습니다.

물론 엔진이 다 하지는 못합니다. 생성된 컷신의 분위기가 적절한지는 엔진이 판정할 수 없습니다. 그래서 저자들은 RLHEV(Reinforcement Learning with Human-Engine Verification)라는 사후학습 프레임워크를 정의합니다. 엔진 검사와 테스트 스위트가 조밀한 구조적 라벨을 만들고, 사람의 수용 판단이 진짜 자격을 검증하는 구조입니다.

보상 추상은 후보 출력에 대한 제약 최적화로 씁니다.

\[\max_{y \in \mathcal{Y}} U_H(x, y, h) - \sum_{i=1}^{n} \lambda_i(h) \phi_i(C_i(x, y)) \quad \text{s.t.} \quad G_j(x, y) = 1, \; j = 1, \dots, m\]

\(U_H\)는 사람 리뷰 효용으로 보통 수용/거부의 \(0\) 또는 \(1\)입니다. \(C_i\)는 엔진 진단 검사값이고 \(\phi_i \geq 0\)은 검사가 깨끗하면 사라지는 단조 페널티, \(\lambda_i(h)\)는 리뷰 맥락에 따른 가중치입니다. \(G_j \in \{0, 1\}\)은 엔진 런타임이 요구하는 하드 게이트입니다.

여기서 지켜지는 불변식이 권한 분리입니다. 엔진은 조밀하고 재현 가능한 검증을 제공하고, 사람 리뷰는 최종 판단을 담당합니다. 사람의 비싼 판단을 엔진이 렌더링한 값싼 실행 증거 위에 얹어놓는 것이 핵심입니다. 리뷰어는 모든 충돌과 스크립트 실패를 일일이 보지 않고 최종 수용 여부에만 집중하면 됩니다.

어떻게 만들었나

완성된 에셋은 무엇이 통했는지 알려주지만, 개발 궤적은 왜 통했는지 알려줍니다. 문제는 게임 개발 데이터가 학습에 재사용되기 어렵다는 점입니다. 에디터 저장본, 에셋, 스크린샷, 로그, QA 노트, 사람의 결정이 전부 다른 포맷으로 흩어져 있고, 어떤 편집이 왜 수용되거나 거부됐는지가 사라집니다.

저자들이 제안하는 UWDP(Unified World-Development Protocol)는 이 흩어진 것들을 상태-행동-검사-리뷰 궤적 하나로 묶는 타입 있는 멀티모달 프로토콜입니다. 인스턴스는 다음과 같이 정의됩니다.

\[u_t = (b, o_t, s_t, a_t, g_t, v_t, h_t, \rho_t)\]

\(b\)는 프롬프트 기반 설계 의도, \(o_t\)는 안정적인 객체·관계·영역 식별자, \(s_t\)는 공간·의미·물리·증거 상태 필드, \(a_t\)는 편집이나 도구 호출, \(g_t\)는 엔진 출력, \(v_t\)는 렌더링된 증거, \(h_t\)는 리뷰어 결정, \(\rho_t\)는 수리 연결과 비용, 잔여 위험입니다.

논문의 표 1이 든 예시가 이해를 돕습니다. 의도는 "출구로 가는 길이 뚫린 플레이 가능한 창고를 배치하라"이고, 객체는 crate_07과 near(chair_03) 관계, 행동은 "crate_07을 (2.4, 0.0, 2.6)으로 옮기고 콜라이더를 재생성", 엔진 출력은 "수리 전 충돌 실패, 수리 후 내비메시 통과", 리뷰어는 "수정 필요 표기 후 수리되자 수용"입니다.

여기서 중요한 것이 안정적 식별자입니다. 이것이 있어야 모델이 실패한 검사를 그것을 유발한 객체와, 그리고 그것을 고친 수리 행동과 연결할 수 있습니다. 이 구조 덕분에 데이터가 이미지-캡션 쌍보다는 테스트와 패치가 딸린 코드 궤적에 가까워집니다.

저장된 궤적은 세 가지 형태의 학습 인스턴스로 컴파일됩니다. 수용된 최종 상태는 의도 \(b\)를 조건으로 하는 지도 생성 타깃이 되고, 실패한 검사와 그 수리 행동의 쌍은 다음 편집·수리 예측 쌍이 되며, 엔진 출력 \(g_t\)와 리뷰어 결정 \(h_t\)는 RLHEV의 융합 보상이 됩니다. 거부된 궤적도 버리지 않고 남깁니다. 최종 산출물만 모은 코퍼스가 통상 잃어버리는 수용 신호의 음성 절반이 여기서 나옵니다.

실제 학습 보상은 다음과 같이 게이트가 걸린 스칼라입니다.

\[r_{\alpha,\beta}(\mathbf{x}, \mathbf{a}) = \mathbb{I}\{\mathbf{g}(\mathbf{x}, \mathbf{a}) = \mathbf{1}\} \left( \alpha h(\mathbf{x}, \mathbf{a}) + \beta e(\mathbf{x}, \mathbf{a}) \right) - \lambda_c c(\mathbf{x}, \mathbf{a})\]

메인 실험에서는 \(\alpha = 0.65\), \(\beta = 0.35\)를 씁니다. 사람 쪽에 더 큰 가중치를 둔 셈입니다.

모델 자체인 AWoMo(Agentic World Model)는 Cosmos 3에서 초기화한 뒤 온폴리시 증류와 계속 사전학습을 거칩니다. 계속 사전학습은 A100 8장, 글로벌 배치 4096, 그래디언트 누적 2로 돌렸고 학습 샘플 79,130개, 검증 4,333개, 테스트 4,282개를 썼습니다. 최적 체크포인트는 검증 손실 기준 589 스텝입니다. 사전학습 매니페스트는 수용 샘플 87,745개와 거부 샘플 504개로 구성되고, 출력 모달리티는 텍스트 87,745, 이미지 53,426, Unreal 9,678, Unity 7,423, 3D 에셋 3,194, 메시 3,194, MuJoCo 2,946, Godot 2,685, 3D 가우시안 12건입니다.

위쪽 파이프라인이 기존 경로입니다. 합성과 수동 어노테이션을 거쳐 생성된 에셋을 CLIP이나 MLLM 심판이 채점하는데, 그 보상이 모호하고 잡음이 껴 있어 과최적화 싱크홀과 성능 정체로 이어집니다. 아래쪽이 제안하는 경로입니다. 에셋을 실행 가능한 세계로 바꾸고, 게임 엔진과 내부 테스트 스위트가 국소 실패를 드러내며, 렌더링된 증거가 리뷰를 뒷받침하고, 개발자가 최종 수용 신호를 줍니다. 오른쪽 의사코드가 이 루프를 그대로 옮긴 것입니다. 검증기가 수용할 때까지 측정하고 개선하는 while 문입니다.

결과

평가는 UnitySceneBench에서 이뤄집니다. Unity 에셋 편집 후보에 대한 수용/거부 분류로, 학습 720개, 검증 80개, 테스트 200개(수용 100 + 거부 100) 구성입니다. 주 지표는 다음과 같이 정의된 가중합입니다.

\[\text{Primary} = 0.45 \cdot \text{balanced accuracy} + 0.25 \cdot \text{accuracy} + 0.20 \cdot F_1 + 0.10 \cdot \text{AUC}\]

이해 쪽 분류 결과에서 Full RLHEV는 시드 8개 중 최고 기준으로 주 지표 0.681, 정확도 0.665, 균형 정확도 0.665, \(F_1\) 0.733, AUC 0.690을 기록했습니다. 두 번째로 좋은 방법 대비 주 지표 \(+0.098\), 정확도와 균형 정확도 \(+0.120\) 차이입니다.

생성 쪽 결과는 학습 예산별로 나눠 보는 편이 낫습니다.

숫자는 시드 8개 평균 생성 품질입니다. 표에서 눈여겨볼 것은 절대 순위가 아니라 곡선의 모양입니다. Fuzzy Proxies와 SFT는 학습 데이터를 늘려도 오르지 않습니다. 40개에서 720개로 18배를 늘렸는데 Fuzzy Proxies는 오히려 0.7478에서 0.7174로 내려갔습니다. 흐릿한 보상으로는 데이터가 늘어도 이득이 없다는 논문의 주장이 가장 선명하게 드러나는 대목입니다.

반대로 Engine-based RLVR은 320개 지점부터 뚜렷하게 꺾여 올라갑니다. 0.7137에서 0.7550, 0.7904, 0.7934로 이어집니다. 검증 가능한 보상이 붙으면 데이터 스케일링이 다시 작동한다는 뜻입니다. Full RLHEV는 전 구간에서 가장 높고, 720개에서 0.8197로 Engine-based RLVR의 0.7934보다 0.0263 앞섭니다. 사람 수용 신호를 얹은 몫이 이 차이입니다.

일반화 쪽은 두 갈래로 나눠 봅니다. 분포 이동은 Unity 소스에서 별도 Unity 예제로(소스 5,895개, 타깃 1,254개), 엔진 간 전이는 Unity에서 Unreal과 Godot으로(각 1,000개, 720/80/200 분할) 갑니다.

가장 강한 양성 사례는 분포 이동입니다. 0.25에서 0.75로 오릅니다. 엔진 간 전이는 이득이 작습니다. Unreal은 0.25에서 0.35, Godot은 0.15에서 0.35입니다.

이 표에서 저자들이 크게 다루지 않은 줄이 하나 있습니다. Unity-source only 조건입니다. 소스 체크포인트를 타깃 적응 없이 그대로 돌리면 프록시 점수가 0.005로 무너지고 손실이 16.7로 치솟습니다. 소스 엔진 궤적은 그 자체로는 다른 엔진에서 쓸 수 없고, 오직 초기화 재료로만 값어치가 있다는 뜻입니다. 저자들도 C5 항목에서 이 점을 인정하며 타깃 런타임 보정이 필수 단계라고 적습니다.

체화 진단은 R2R, Gymnasium MuJoCo, D4RL Gym-MuJoCo에서 원본 베이스라인, 단순 증강, AWoMo 증강을 비교합니다.

세 벤치마크 모두에서 AWoMo 증강이 가장 좋습니다. 다만 표준편차를 함께 봐야 합니다. Gymnasium MuJoCo는 평균 1724에 표준편차가 1642입니다. 평균보다 편차가 큰 수준이라 \(+9.96\%\)라는 상대 개선을 유의미한 차이로 읽기 어렵습니다. D4RL도 27.155±9.491과 25.555±12.448이 겹칩니다. 상대 개선률이 가장 큰 \(+48.43\%\)는 원본 베이스라인 값 18.295가 낮아서 생긴 배수 효과이기도 합니다. R2R만 편차가 작아 차이가 비교적 선명합니다.

회고

저자들은 부록 C.1에서 다섯 가지 반론을 스스로 세우고 답합니다. 논문 본문보다 이 대목이 정직합니다.

게임은 현실이 아니다. 저자들은 맞다고 인정합니다. 그리고 현재 실험에 실제 스캔도, 실제 로봇도, 진짜 real-to-sim-to-real 루프도 없다고 명시합니다. 따라서 게임 엔진 보상이 이미 물리 세계로 전이된다는 증거로 읽으면 안 된다고 못 박습니다. 논문 전체의 주장 강도를 스스로 낮추는 문장이라 인용해둘 가치가 있습니다.

엔진 보상도 게임될 수 있다. 역시 맞다고 인정합니다. 게임 엔진은 오라클이 아니라 부분 검증기이며, 느슨한 충돌·내비게이션·예산 검사는 단독으로 쓰이면 우회당한다는 것입니다. 다만 엔진 보상의 실패는 지각적 프록시와 달리 국소화되고 테스트 가능하다는 점을 방어 논거로 듭니다.

소스 엔진에 과적합될 수 있다. 앞서 본 표 5의 붕괴가 이 반론의 실물 증거입니다.

논문이 스스로 짚지 않은 긴장이 하나 더 있습니다. 저자들은 서론과 3장에서 MLLM 심판 점수를 흐릿하고 편향되고 게임 가능한 프록시로 규정합니다. 그런데 일반화 실험의 주 지표가 바로 그 MLLM 심판 점수입니다. 저자들도 이 문제를 알고 있어서, Unity·Unreal·Godot 출력을 공통 척도로 비교할 엔진 고유 스칼라가 없기 때문에 현재로서는 루브릭 기반 심판이 유일한 실용적 방법이라고 설명합니다. 또한 심판은 사람 리뷰 채널과 같은 수용/거부 루브릭을 따르고, 보고된 모든 심판 점수는 사람 검수를 거쳤으며, 평가 도구로만 쓰이고 학습 보상으로는 절대 쓰이지 않는다고 못 박습니다.

방어 자체는 성실합니다. 다만 결과가 남습니다. "공간 생성에는 믿을 만한 검증기가 없다"고 주장하는 논문이, 자기 주장을 입증하는 자리에서 그 없는 검증기를 다시 빌려 쓰고 있습니다. 게다가 표 4의 심판 점수는 0.15, 0.25, 0.35, 0.75처럼 0.05 단위로만 나옵니다. 눈금이 이렇게 성기다는 것은 평가 표본이 작다는 뜻이고, 0.25에서 0.35로의 이동을 몇 건의 판정 뒤집힘으로도 만들 수 있다는 뜻이기도 합니다.

규모 자체도 짚어야 합니다. UnitySceneBench는 학습 720개, 테스트 200개입니다. 저자들 본인이 실험을 파일럿이자 진단이라고 표현하고, 일반화 능력을 확인하려면 더 큰 스케일링 연구가 필요하다고 적습니다. 논문의 1차 기여를 "논거와 연구 어젠다"라고 명시한 것도 같은 맥락입니다. 이 글의 표들을 성능 랭킹이 아니라 방향성 증거로 읽어야 하는 이유입니다.

정리

• 병목을 데이터에서 보상 채널로 옮겨 놓은 것이 이 논문의 값어치입니다. 코드에는 컴파일러, 수학에는 정답 대조가 있었고 공간 생성에는 없었다는 계보를 세우고, 그 빈자리를 게임 엔진이 이미 채우고 있다고 지목합니다. Cosmos 3나 Looped World Models가 다룬 아키텍처 축과는 다른 축의 이야기입니다.
• 생성 품질 표의 곡선 모양이 가장 강한 증거입니다. 흐릿한 보상 계열은 학습 데이터를 18배로 늘려도 오르지 않고 오히려 내려간 반면, 엔진 검증 보상이 붙은 계열은 320개 지점부터 다시 올라갑니다. 사람 수용 신호를 얹은 Full RLHEV가 전 구간 최고입니다.
• 다만 증거의 규모가 주장의 규모를 아직 못 따라갑니다. 실제 스캔도 로봇도 없고, 벤치마크는 200개 테스트이며, 일반화 지표는 저자 본인이 흐릿하다고 비판한 MLLM 심판입니다. 포지션 페이퍼로 읽고 후속 검증을 기다리는 편이 정확합니다.