지난 편에서 비디오 월드모델의 매력과 두 개의 구멍(세계를 기억하지 못한다, 픽셀은 이해가 아니다)을 봤다. 이번 편은 그 구멍을 실제 서비스 규모에서 정면으로 맞닥뜨린 회사가 어떤 답을 내놨는지 들여다본다. 로블록스다.
로블록스를 사례로 고른 데는 이유가 있다. 동시접속 4,500만 명을 찍어본 플랫폼인데, 정작 그 게임 대부분은 회사가 아니라 크리에이터들이 만든다. 회사는 도구와 인프라만 제공한다. 그래서 “장비 좋은 대형 스튜디오만 쓸 수 있는 기술”은 이 회사에게 선택지가 아니고, 아키텍처 결정에 그 제약이 고스란히 박혀 있다. 극단적인 조건에서 나온 설계일수록 배울 게 많다.
1. 게임은 두 가지 일을 동시에 해야 한다
사람들은 게임을 칭찬할 때 보통 그래픽을 말하지만, 그래픽은 눈에 가장 잘 띄는 부분일 뿐 엔지니어링에서는 오히려 작은 부분이다. 게임을 게임으로 만드는 일은 크게 둘로 나뉜다.
하나는 세계를 모두에게 일관되게 유지하는 일이다. 어디에 무엇이 있고 무슨 일이 있었는지 기억하는 지속 상태, 누구에게나 같은 방식으로 적용되는 규칙, 기대한 대로 움직이고 부딪히는 물리, 수천 명이 하나의 세계를 공유하게 하는 실시간 동기화, 그리고 행동하는 순간 반응하는 즉각성. 레이싱 게임이라면 트랙과 점수와 페널티, 차마다 다른 조작감, 다른 차들의 위치까지 전부 정확해야 하고, 모든 플레이어가 같은 순간 같은 것을 봐야 한다. 하나라도 어긋나면 플레이어는 바로 알아챈다.
다른 하나는 진짜처럼 보이게 하는 일이다. 바람에 흔들리는 풀, 차 뒤로 이는 먼지, 표면을 따라 변하는 빛. 요즘 플레이어들이 당연하게 기대하는 수준의 사실감.
게임엔진은 일관성에 강하고, 월드모델은 사실감에 강하다. 서로 정확히 반대편에 강하다.
지난 편에서 본 대로 월드모델은 두 번째에 강하고 첫 번째에 무력하다. 흥미로운 건 게임엔진이 정확히 그 반대라는 점이다. 엔진은 상태를 추적하고 규칙을 집행하고 물리를 계산하는 일에는 성숙한 기술이지만, 포토리얼리즘 앞에서는 무너진다. 진짜처럼 보이려면 고해상도 텍스처와 복잡한 조명과 빛의 산란까지 전부 명시적으로 렌더링해야 하는데, 사실적으로 갈수록 비용이 가파르게 는다. 그래서 엔진들은 조명을 미리 구워두고, 먼 객체를 단순한 버전으로 바꿔치기하고, 아예 디테일 부족이 안 보이는 스타일라이즈드 룩으로 도망간다. 대부분의 게임이 여전히 현실이 아니라 “게임처럼” 보이는 이유다.
더 아픈 건 이 비용이 서버가 아니라 사람에게 떨어진다는 점이다. 디테일을 만들려면 크리에이터의 기술과 시간이 필요하고, 돌리려면 플레이어의 기기가 좋아야 한다. 대형 스튜디오는 감당해도 2인 팀과 평범한 폰은 못 한다. 크리에이터 생태계가 곧 회사인 플랫폼에게는 치명적인 제약이다.
서로 정확히 반대편에 강한 두 기술이 있으면, 다음 질문은 하나로 좁혀진다. 어떻게 이어붙일 것인가.
2. 거대 단일 모델이라는 유혹, 분업이라는 선택
여기서 갈림길이 나온다. 한쪽 길은 “모델을 계속 키우면 언젠가 상태도 규칙도 물리도 전부 배울 것”이라는 거대 단일 모델의 길이다. AGI 서사와 잘 어울리고, 연구실 데모도 이 방향으로 나온다. 다른 쪽 길은 세계에 대한 추론이 꼭 신경망 안에 있을 필요는 없다고 보는 길이다. 정확한 상태와 규칙과 물리는 이미 수십 년 다듬어진 게임엔진이 잘하니 거기 맡기고, 모델은 자기가 가장 잘하는 픽셀에 전 용량을 쓰게 하는 것.
로블록스는 후자에 베팅했고, 그 시스템을 Roblox Reality라고 부른다. 구성은 세 부분이다.
엔진과 클라우드가 일관성을 지키고, 월드모델이 사실감을 맡는다.
게임엔진은 “무엇이 실제로 있는가”를 아는 부분이다. 중심에는 데이터 모델이라 부르는 구조화된 장부가 있다. 세계의 모든 객체와 속성(차가 어디 있고, 얼마나 빠르고, 어느 방향이고, 무엇으로 만들어졌는지)을 기록하고, 그 위에서 물리와 규칙을 매번 똑같이 계산한다. 계산이 정확하고 반복 가능하기 때문에 엔진은 모든 플레이어의 화면이 합의해야 하는 진실의 원천 역할을 할 수 있다.
클라우드는 그 엔진을 스케일로 돌리는 기반이다. 각 세계의 상태를 영구 저장해 며칠 뒤 돌아와도 게임이 그대로 있게 하고, 수백만 개의 라이브 세션을 플레이어와 가까운 데이터센터에서 돌린다. 권위 있는 상태가 지구 반대편이 아니라 플레이어 옆에 있어야 빠르고 공정한 멀티플레이가 성립한다.
Super Upsampler가 비디오 월드모델인데, 이름이 곧 역할이다. 세계를 무(無)에서 상상하는 게 아니다. 엔진이 먼저 형태·위치·카메라 움직임은 정확하지만 텍스처와 조명은 단순한, 말하자면 밋밋한 초안 프레임을 렌더링한다. 모델은 그 초안을 받아 포토리얼로 업샘플링한다. 대형 비디오 모델을 이 작업에 맞게 사후학습한 것이라 시각 세계의 생김새는 이미 알고 있고, 앞유리의 빗방울이나 차가 지나갈 때 흔들리는 나뭇잎 같은 디테일만 채우면 된다. 장면에 뭐가 있는지는 엔진이 정하고, 모델은 그게 어떻게 보이는지만 정한다. 정확하고 싼 부분은 엔진이, 비싸고 퍼지한 부분만 모델이 맡으니 양극단 어느 쪽보다 비용이 덜 든다는 계산이다.
3. 모델을 묶는 세 가닥의 고삐
이 분업은 플레이어가 이음새를 못 느껴야 성립하고, 그래서 진짜 엔지니어링은 두 부분을 잇는 데 있다. 모델이 세계를 마음대로 지어내면 안 되니까, 매 프레임 픽셀을 생성하기 전에 모델은 엔진이 만든 재료들로 조건화된다. 주행 게임의 한 프레임이라면 엔진은 저품질 렌더링 프레임, 깊이맵, 장면의 조명과 날씨, 모든 객체의 구조화된 정보를 만들어내고, 이 신호들은 성격에 따라 세 갈래 경로로 모델에 주입된다.
신호의 기하학적 성격에 따라 주입 경로가 다르다. 픽셀 단위 신호는 격자에 붙이고, 장면 단위 신호는 전체에 뿌리고, 텍스트형 신호는 필요한 곳이 참조한다.
- 밀집 신호: 거친 렌더링 프레임과 깊이맵처럼 픽셀마다 값이 있는 신호. 출력과 같은 격자를 공유하므로 모델 입력에 이어붙이거나 ControlNet 스타일 사이드 네트워크로 주입한다. 생성되는 모든 픽셀이 제 위치와 색에 고정된다. (ControlNet은 이미지 생성 모델에 “이 윤곽, 이 구도를 지켜라”라는 제약을 걸어주는 보조 네트워크라고 생각하면 된다.)
- 전역 신호: 한낮, 가벼운 비, 왼쪽에 낮게 뜬 해처럼 장면 전체에 하나만 적용되는 설정. 모델 활성값 전체를 한 번에 스케일·시프트하는 modulation으로 들어간다. 디퓨전 모델이 timestep을 주입하는 것과 같은 방식이다.
- 구조화 신호: “금속 스포츠카, 위치 (120, 0, 48), 초속 40미터” 같은 텍스트에 가까운 압축 설명과 스타일 프롬프트. cross-attention으로 들어가 프레임의 어느 부분이든 필요할 때 참조한다.
이 재료로 모델이 최종 2K 프레임을 그린다. 젖은 도장의 광택, 앞유리의 눈부심, 타이어에서 튀는 물보라까지. 단, 차를 움직이거나 사물의 거리를 바꾸는 일은 없다. 지난 편의 드리프트 문제도 같은 방식으로 눌러둔다. 데이터 모델이 어떤 객체가 존재하고 고정인지 알려주기 때문에, 문 4개짜리 차는 다음 프레임에도 문 4개짜리 차다. 다만 게임 상태 전체를 매 프레임 넣을 수는 없어서, 지금 렌더링에 관련된 객체만 골라오는 검색 단계를 거친다.
4. 저장할 것과 다시 만들 것
이 아키텍처에서 내가 가장 오래 곱씹은 부분은 화려한 모델 쪽이 아니라 저장 설계다. 모두가 합의해야 하는 세계 상태는 서버의 데이터 모델에 산다. 공유되고, 긴 세션 동안 안정적으로 유지되고, 영구 저장된다. 반면 세계의 겉모습은 모델의 비디오 latent에 산다. 계속 재생성되고, 저장될 필요가 없고, 플레이어마다 조금씩 달라도 된다. 진실은 서버가 정하고, 달라도 안전한 부분만 모델이 채운다.
진실의 원천은 하나만 두고 파생물은 언제든 다시 만들 수 있게 하라는, 소프트웨어 설계의 오래된 원칙이 생성 AI 시대에 다시 나타난 것이다. 그리고 무엇을 상태로 보존하고 무엇을 매번 다시 만들지 가르는 감각은, LLM 에이전트를 설계할 때 컨텍스트에 뭘 남기고 뭘 버릴지 정하는 문제와 정확히 같은 근육을 쓴다. 관련 객체만 골라오는 검색 단계까지 포함하면, RAG를 만들어본 사람에게는 전체 그림이 낯설지 않을 것이다.
5. 개인적인 견해
“추론이 모델 안에 다 있을 필요는 없다”는 선택은, 지난 편 말미에 얘기했던 하네스 패턴의 가장 큰 규모 사례로 읽힌다. LLM 에이전트에서 결정론적이어야 하는 부분(도구 실행, 상태 관리, 검증)을 코드가 맡고 퍼지한 부분(계획, 생성)을 모델이 맡듯, 여기서는 게임엔진이 결정론을 맡고 월드모델이 픽셀을 맡는다. 텍스트든 픽셀이든, 생성 모델을 제품으로 만드는 회사들이 결국 같은 모양의 답에 도착하고 있다는 게 이 사례의 가장 큰 시사점이라고 생각한다.
물론 반론도 가능하다. 거대 단일 모델 진영이라면 “그 분업은 과도기적 목발이고, 모델이 충분히 커지면 엔진도 삼켜질 것”이라고 말할 것이다. LLM에서도 하네스로 해결하던 것들이 모델 세대가 바뀌며 모델 안으로 흡수된 사례가 있으니 흘려들을 얘기는 아니다. 다만 멀티플레이어의 공유 상태처럼 “모두가 하나의 진실에 합의해야 한다”는 요구는 확률적 생성과 원리적으로 충돌하는 부분이라, 이쪽 경계는 꽤 오래 남을 거라고 본다. 그 경계가 실제로 어디서 시험받는지(실시간성, 장기 일관성, 멀티플레이어, 통제)는 다음 편에서 다룬다.
함께 보면 좋은 글:
- 월드모델 (1) LLM 다음은 뭘까: 다음 프레임을 예측하는 AI
- 월드모델 (3) 게임이 월드모델의 가장 혹독한 시험장인 이유
- 컨텍스트 압축(Context Compaction): 에이전트에게 전부 넣지 말고 필요한 것만 남기기
참고 자료
- Inside Roblox’s Bet on World Models (ByteByteGo)
- Introducing the Roblox Hybrid Architecture (Roblox Newsroom)
본 글은 2026년 7월 21일 기준 공개 자료를 바탕으로 작성했으며, 로블록스 관련 내용은 위 참고 자료의 인터뷰와 발표를 근거로 한다. 다이어그램은 해당 자료의 그림을 참고해 직접 재구성했다. 세부 구현은 발표 기준이며 실제 출시 형태는 달라질 수 있다.