AI 네이티브 게임 엔진이 출시되고 있고, 이들은 Unity와 전혀 다르게 생겼다
글 Oleg Sidorkin, Cinevva CTO
3월에 게임 엔진 세 개가 등장했는데, Unity/Unreal/Godot 계보의 그 어떤 것과도 아키텍처가 다르다. 이들에겐 비주얼 에디터가 없다. 사람이 메뉴를 클릭해 가는 흐름에 맞춰 최적화하지도 않는다. 이들은 AI 에이전트가 게임 상태를 읽고, 쓰고, 제어하도록 처음부터 만들어졌다.
이건 "AI 탭이 붙은 Unity"가 아니다. 이건 다른 종류의 엔진이다.
AI는 이미 3D 게임 개발 워크플로를 바꾸고 있다. 엔진 계층이 그다음이다.
세 개의 엔진
nAIVE Engine 은 오픈소스이고, Rust로 작성됐으며 WebGPU 렌더링을 쓴다. 1초 미만 핫 리로드를 한다. 셰이더는 200ms 이내, 씬은 100ms 이내, 스크립트는 50ms 이내다. 씬, 파이프라인, 머티리얼이 YAML로 정의되는데, 이는 LLM이 바이너리 포맷을 파싱하지 않고도 이들을 읽고 생성할 수 있다는 뜻이다. AI 에이전트가 JSON-RPC를 통해 엔진 기능을 제어할 수 있게 해 주는 MCP 명령 인터페이스를 노출한다. 일급 기능인 Gaussian splatting과 자동화 테스트용 헤드리스 렌더링을 기본 탑재했다. 아키텍처 전체가 주된 사용자가 마우스를 든 사람이 아니라 AI 에이전트일 수 있다고 가정한다.
Arcane Engine 은 코드 우선 2D 엔진이다. Rust 코어에 TypeScript 스크립팅. 비주얼 에디터가 아예 없다. 그 철학은 "코드가 곧 씬"이다. 게임 상태는 씬 트리가 아니라 쿼리 가능한 데이터베이스다. AI 에이전트 상호작용을 위한 프로토콜이 내장돼 있다. Apache 2.0 라이선스다.
Mirror Engine 은 알파 단계이고, 멀티플레이어 우선에 엔티티 컴포넌트 시스템을 갖췄다. 흥미로운 부분은 이렇다. 텍스트 프롬프트로부터 약 60초 만에 Gaussian splat을 만들어 내는 AI 텍스트-투-3D 생성을 포함한다. TypeScript 스크립팅에, 브라우저 기반 "Mirror Lite" 클라이언트가 있다.
이 세 엔진은 코드베이스나 팀을 공유하지 않지만, 하나의 설계 논지를 공유한다. 게임 엔진으로 들어가는 주된 인터페이스는 GUI가 아니라 구조화된 텍스트여야 한다는 것이다.
왜 이 아키텍처가 중요한가
전통적인 게임 엔진은 책상 앞에 앉은 사람을 위해 진화했다. 뷰포트가 있다. 계층 패널이 있다. 인스펙터가 있다. 타임라인이 있다. 모든 게 클릭하고, 드래그하고, 시각적으로 오브젝트를 배치하는 것을 중심으로 설계돼 있다. 그 워크플로는 강력하다. 그리고 AI 에이전트가 쓰기엔 불가능하기도 하다.
주된 "사용자"가 LLM일 때는 다른 기본 요소가 필요하다. 바이너리 씬 포맷 대신 YAML. 중첩된 씬 트리 대신 쿼리 가능한 상태. 마우스 클릭 대신 프로토콜 기반 명령. 윈도우 렌더링 대신 헤드리스 동작.
이건 DevOps가 GUI 제어판에서 코드형 인프라(infrastructure-as-code)로 옮겨 갔을 때 인프라 분야에서 일어난 것과 같은 전환이다. 똑같은 일이 게임 엔진에서 벌어지고 있는데, 다만 20년 늦게 일어나는 것뿐이다.
nAIVE의 MCP 인터페이스가 가장 분명한 예다. MCP(Model Context Protocol)는 AI 에이전트가 도구와 통신하는 표준 방식이 되어 가고 있다. 엔진이 MCP를 네이티브로 말할 때, 이 프로토콜을 지원하는 어떤 AI 에이전트든 사람이 끼어들지 않고도 씬을 조작하고, 파라미터를 조정하고, 테스트를 돌리고, 게임플레이를 반복 개선할 수 있다. 그건 전통적인 엔진에 갖다 붙인 기능이 아니다. 그건 엔진과 그 사용자 사이의 근본적으로 다른 관계다.
게임 개발에서의 Gaussian splatting. nAIVE와 Mirror 둘 다 이걸 일급 렌더링 기본 요소로 다룬다.
더 큰 그림
이 세 엔진이 유일한 신호는 아니다. Meshy의 Black Box는 런타임에 AI가 생성하는 게임 메커니즘을 시연했다. OpenAI는 GDC에서 Phaser로 만든 전술 RPG를 선보였다. "AI가 무언가를 생성한다"와 "그 무언가가 플레이 가능한 게임으로 돌아간다" 사이의 도구 계층은 매달 더 얇아지고 있다.
Cinevva에서 우리는 이 다리를 반대 방향에서 놓아 왔다. 우리 엔진은 렌더링, 물리, 실시간 상호작용을 맡고, AI는 에셋 생성을 맡는다. 접근 방식은 nAIVE나 Arcane과 다르지만, 그 밑에 깔린 베팅은 같다. 미래의 게임 엔진은 AI를 플러그인으로 그냥 더하는 게 아니라, 제1 언어로 말해야 한다는 것이다.
전통적인 엔진 제작사들도 이걸 안다. Unity는 GDC에서 AI 게임 제작 도구를 미리 공개했다. Roblox는 AI 기반 4D 모델 제작을 출시했다. 하지만 인간을 위해 설계된 엔진에 AI 기능을 더하는 것과, AI가 주된 인터페이스인 엔진을 설계하는 것 사이에는 의미 있는 차이가 있다.
다음에 무슨 일이 벌어질지에 대한 내 생각
이 엔진들 대부분은 살아남지 못할 것이다. 새 카테고리에선 정상적인 일이다. 하지만 설계 패턴은 남을 것이다. YAML 기반 씬 정의, 에이전트 제어를 위한 MCP 프로토콜, 쿼리 가능한 게임 상태, 헤드리스 동작. 이 아이디어들은 2년 안에 주류 엔진들로 흡수될 것이다.
이 시대를 거머쥘 엔진은 아마 아직 존재하지 않는다. 하지만 아키텍처 차원의 DNA는 바로 지금, 이 세 프로젝트와 한 줌의 다른 프로젝트들 속에서 쓰이고 있다. 질문은 게임 엔진이 AI 네이티브가 될 것이냐가 아니다. 그 변화가 기존 강자들 내부에서 올지, 아니면 첫날부터 에이전트를 위해 설계한 신규 진입자들에게서 올지다.
관련 글:
- 이제 모두가 AI 게임 엔진이 되고 싶어 한다 — 무대를 깔아 준 플랫폼 경쟁
- 최전선 오픈소스 생성형 AI 모델 — 이 엔진들이 통합하고 있는 모델들
- 웹 게임 엔진 비교 — 새 엔진들이 더 넓은 생태계에서 어디에 들어맞는지
- 오픈소스에 AI 오염 문제가 있다 — AI가 생성한 기여의 비용 측면