Gear.Club Unlimited 3에서 시속 500km로 렌더링하기

Eden Games는 성능이 시각적 충실도(visual fidelity)만큼이나 중요한 레이싱 게임을 개발하며 25년을 보냈습니다. 이들의 최신 출시작인 Gear.Club Unlimited 3 (GCU 3)는 이러한 균형을 더욱 밀어붙입니다. 이 게임은 콘솔부터 레이 트레이싱 (ray tracing)이 지원되는 하이엔드 PC에 이르는 하드웨어를 타겟으로 하면서, 시속 500km에 육박하는 속도로 거대한 환경을 스트리밍할 수 있는 60 fps 아케이드 레이서입니다. 2026년 2월 19일에 출시된 GCU 3는 Eden Games의 완전히 성숙한 커스텀 렌더링 파이프라인 (custom rendering pipeline)을 탑재하여 출시된 첫 번째 타이틀이기도 하며, 올해 말 다른 플랫폼으로 확장하기 전에 Nintendo Switch™ 2에서 먼저 데뷔했습니다. 우리는 리드 그래픽 프로그래머 (lead graphics programmer)인 Nasim Bouguerra, 그리고 시니어 렌더링 프로그래머 (senior rendering programmer)인 Florian Falavel와 함께 GPU 구동 아키텍처 (GPU-driven architecture) 구축, 플랫폼 전반에 걸친 레이 트레이싱 (ray tracing) 스케일링, 그리고 극한의 스트리밍 제약 조건 하에서 안정적인 성능을 유지하는 방법에 대해 이야기를 나누었습니다.

GCU 3를 제작하면서 팀이 직면한 가장 큰 렌더링 과제는 무엇이었나요?

Nasim Bouguerra (NB): 우리의 주요 과제 중 하나는 시속 500km에 달하는 속도로 월드 데이터를 스트리밍하면서 안정적인 60 fps를 유지하는 것이었습니다. 그 정도 속도에서는 에셋 로딩 (asset loading), 동기화 지점 (synchronization points), 가비지 컬렉션 (garbage collection)과 같은 사소한 스톨 (stalls)조차 게임 플레이의 몰입감을 즉시 깨뜨립니다. 이러한 스파이크 (spikes)를 제거하는 것이 주요 엔지니어링 목표가 되었습니다.
GCU 3는 Nintendo Switch 2를 위한 우리의 첫 번째 게임이기도 했기에, 촉박한 마감 기한 내에 새로운 하드웨어에 맞춰 최적화를 진행해야 했습니다. 이와 동시에, 이번 프로젝트는 우리의 완전한 자체 제작 렌더링 파이프라인 (in-house rendering pipeline)이 처음으로 프로덕션에 적용된 사례였습니다. 이는 아키텍처를 안정화하고, 플랫폼 간의 확장성을 검증하며, 플랫폼별 경로를 동시에 튜닝해야 함을 의미했습니다.

왜 커스텀 스크립터블 렌더 파이프라인 (Scriptable Render Pipeline)을 구축하기로 결정했나요?

NB: 지난 2019년에 우리는 매우 상이한 하드웨어 전반에 걸쳐 확장할 수 있도록 자체적인 스크립터블 렌더 파이프라인 (Scriptable Render Pipeline)을 구축했습니다. 이를 통해 성능과 기능에 대한 완전한 제어권을 가질 수 있었고, 완전한 GPU 구동 시스템 (GPU-driven system)을 가능하게 했으며, DLSS 4.5, FSR 4, XeSS 2, 그리고 패스 트레이싱 (path tracing)과 같은 현대적인 기술들을 지원할 수 있었습니다.

그 이후로 우리는 이 파이프라인을 통해 네 개의 게임을 출시했으며, GCU 3는 이 파이프라인의 가장 중대한 진화를 보여줍니다.

Unity 6가 귀사의 렌더링 파이프라인(rendering pipeline)과 저수준 그래픽 스택(low-level graphics stack)에 어떤 영향을 미쳤나요?

Florian Falavel (FF): Unity 6는 렌더링 백엔드(rendering backend)에 대해 더 큰 접근 권한과 유연성을 제공하여, 저수준 그래픽 기능들을 활용하고 최적화된 맞춤형 솔루션을 구축할 수 있게 해줍니다. 또한 우리는 PC의 NVIDIA DLSS 및 Nintendo Switch 2, 레이 트레이싱(ray tracing)을 위한 NRD 디노이저(denoiser), 그리고 기타 고급 도구들과 같이 아직 Unity에서 노출되지 않은 기능들을 통합하기 위해 네이티브 렌더링 플러그인(Native Rendering Plugins)에 의존합니다. 이러한 수준의 제어력은 모든 타겟 플랫폼에서 안정적인 시각적 품질을 유지하면서 고성능 스트리밍(streaming)을 구현하는 데 필수적입니다.

GPU 구동 렌더링(GPU-driven rendering)이 환경과 레이스 트랙을 구축하는 방식에 어떤 변화를 주었나요?

FF: GPU 구동 렌더링은 CPU 제출 병목 현상(CPU submission bottlenecks)을 제거하여, 훨씬 더 밀도 높은 환경과 더 복잡한 레이스 트랙을 구현할 수 있게 합니다. 우리는 이를 지형 및 프롭(props)을 위한 커스텀 가상 텍스처링(virtual texturing) 시스템과 결합하여, 아티스트들이 메모리와 성능을 예측 가능한 범위 내로 유지하면서도 고해상도 에셋을 사용할 수 있도록 했습니다. 그 결과, 60 fps 프레임 레이트를 타협하지 않으면서도 더 높은 장면 복잡도를 달성할 수 있었습니다.

시속 500km에 육박하는 속도에서는 스트리밍이 매우 중요해집니다. 끊김 현상(stutters)을 방지하기 위해 렌더링, 에셋 스트리밍, 그리고 메모리 관리를 어떻게 처리하시나요?

NB: 스트리밍은 우리의 가장 큰 과제 중 하나였습니다. 우리는 끊김 없이 Nintendo Switch 2의 I/O를 포화시킬 수 있는 완전한 멀티스레드(multithreaded) 스트리밍 시스템을 구축했습니다. 또한 게임 플레이 중에 가능한 한 많은 GC 할당(GC allocation)을 제거하는 데 시간을 투자했으며, 가비지 컬렉션(garbage collection) 관련 프레임 드롭이 레이스 중에 드물게 발생하도록 증분 가비지 컬렉션(incremental garbage collection)을 활성화했습니다. 우리의 지형 및 가상 텍스처링 시스템 또한 피드백 루프(feedback loops)를 사용하여 필요한 데이터만을 정확히 필요한 시점에 로드합니다.

이러한 접근 방식은 극한의 속도에서도 스트리밍(streaming)을 매끄럽게 유지합니다. Nintendo Switch 2에서 60 fps를 달성하기 위해 핵심이 된 렌더링 기술과 GPU 최적화는 무엇이었나요? FF: Nintendo Switch 2에서는 파이프라인(pipeline)의 모든 단계가 그 비용을 정당화해야 했습니다. 우리는 GPU 예산(GPU budgets) 내에 머물기 위해 DLSS를 동적 해상도 시스템(dynamic resolution system)과 긴밀하게 통합했으며, 워크로드(workloads)를 중첩시키고 점유율(occupancy)을 극대화하기 위해 비동기 연산(asynchronous compute)에 크게 의존했습니다. 우리의 GPU 구동형 아키텍처(GPU-driven architecture) 또한 CPU 오버헤드(CPU overhead)를 줄여주었으며, 이는 격렬한 게임플레이 시나리오 동안 일관성을 유지하는 데 도움이 되었습니다. 광범위한 플랫폼 프로파일링(platform profiling)을 통해 패스(pass) 수준에서의 의사결정을 유도했으며, 이 과정에서 대역폭(bandwidth) 소모가 큰 단계를 다듬고, 리소스 전환(resource transitions)을 재구성하며, 동기화 스톨(synchronization stalls)을 제거했습니다. 가변 재생률(Variable Refresh Rate, VRR)은 추가적인 안전 마진을 제공하여, 시스템적인 문제를 은폐하지 않으면서도 드물게 발생하는 에지 케이스(edge cases)를 부드럽게 처리했습니다. Nintendo Switch 2 외에 다른 플랫폼에서는 렌더링 접근 방식이 어떻게 달라지나요? NB: 우리는 기능이 완전히 갖춰진 구성(feature-complete configuration)에서 시작하여, 실제 게임플레이 조건 하에서 각 시스템을 프로파일링합니다. 그 후, 완전히 별개의 렌더링 경로를 유지하는 대신 플랫폼별로 기능을 선택적으로 확장하거나 특화하며, 플랫폼이 제공할 수 있는 최선의 활용법을 찾기 위해 반복(iterate)합니다. PC에서는 HDR, 울트라와이드(ultrawide) 지원, DLSS, 실시간 패스 트레이싱(real-time path tracing)을 포함하여 우리가 지원하는 모든 렌더링 기능 세트를 플레이어에게 제공합니다. 또한 Steam Deck과 같은 저전력 기기에서도 플레이어가 동일한 핵심 비주얼을 즐길 수 있도록 확장성(scalability) 옵션을 제공합니다. 목표는 서로 다른 파이프라인을 만드는 것이 아닙니다. 단일하고 확장 가능한 프레임워크 내에서 제어된 성능 저하(controlled degradation)를 구현하는 것입니다. 팀이 레이 트레이싱(ray tracing)에 그토록 집중하게 된 동기는 무엇이며, 그 결정이 개발 과정에서의 시각적 목표와 기술적 제약 모두를 어떻게 형성했나요? NB: 레이 트레이싱은 물리적으로 정확한 비주얼과 조명 아티스트들의 더 빠른 반복 작업(iteration)을 위해 모두 필수적입니다.

우리는 초기 개발 단계부터 레벨 제작 및 런타임(runtime)까지 이를 통합했으며, 지형(terrain)과 프롭(props)부터 조명(lighting)과 머티리얼(materials)에 이르기까지 모든 시스템이 예상대로 작동하도록 보장했습니다. 또한 레이 트레이싱 가속 구조(RTAS) 메모리가 레이 트레이싱의 주요 병목 현상이 되기 때문에, 제작 과정 중 아티스트들을 위해 고메모리 GPU가 필요합니다.

참조 패스 트레이서(reference path tracer)를 사용하여 전역 조명(GI)을 베이크(bake)한 과정과, 그 작업이 PC 버전에서 사용된 실시간 패스 트레이싱(real-time path tracing) 솔루션에 어떻게 정보를 제공하거나 대조되었는지 설명해 주시겠습니까?

FF: 레이 트레이싱은 우리 전역 조명(GI) 워크플로우의 중추입니다. 우리는 정확성을 위해 참조 패스 트레이서를 구축했으며, 이는 우리의 베이크된 GI 시스템을 검증하고 아티스트들에게 예측 가능한 결과를 제공합니다. 이를 통해 반복 작업(iteration) 속도가 빨라져, 아티스트들이 전체 베이크를 실행하기 전에 최종에 가까운 조명을 미리 볼 수 있습니다.

PC 버전에서는 하이엔드 하드웨어를 위해 실시간 ReSTIR 기반 패스 트레이서를 추가하여 그라운드 트루스(ground truth)에 가깝게 유지했습니다. 레이 트레이싱은 장기적인 투자이며, 우리는 렌더링 API를 개선하고 안정화하기 위해 Unity와 긴밀히 협력했습니다.

Unity의 레이 트레이싱 팀과의 협업이 최종 렌더링 파이프라인에 어떤 영향을 미쳤습니까?

FF: 우리의 GPU 구동(GPU-driven) 파이프라인은 초기 Unity 버전에서 제공하지 않았던 레이 트레이싱 기능이 필요했습니다. 우리는 GPU에서 생성된 데이터를 가속 구조에 주입할 수 있는 기능을 추가하여 RayTracingAccelerationStructure.AddInstancesIndirect와 같은 API를 도입했으며, 패스 트레이싱 성능을 높이기 위해 네이티브 렌더링 플러그인(Native Rendering Plugin)을 통해 NVIDIA Shader Execution Reordering을 통합했습니다. 이러한 협업은 우리의 최종 아키텍처를 형성했으며, GPU 구동 방식을 유지하면서도 레이 트레이싱을 확장할 수 있게 해주었습니다.

현대의 업스케일링(upscaling) 기술은 전반적인 렌더링 전략에 어떻게 부합합니까?

NB: 현대의 업스케일링은 시각적 선명도와 성능 사이의 균형을 맞추는 데 필수적입니다. 머신 러닝(machine learning) 기반 솔루션은 시간적 안티앨리어싱(TAA)과 같은 전통적인 방식보다 더 나은 안티앨리어싱(anti-aliasing)을 제공할 수도 있습니다.

PC에서는 자체적인 시간적 업샘플러 (temporal upsampler)와 NVIDIA DLSS 4.5, AMD FSR 4, 그리고 Intel XeSS 2를 지원하여 최대한의 유연성을 제공합니다. 그렇다고 해서 업스케일링 (upscaling)이 마법 같은 해결책인 것은 아닙니다. 업스케일링은 기반이 되는 파이프라인 (pipeline)이 이미 효율적일 때 가장 잘 작동하며, 이를 통해 특히 제약 조건이 더 엄격한 콘솔 (console)에서 선명도, 성능, 그리고 이미지 품질 사이의 균형을 맞출 수 있습니다.

렌더링 전략을 구축하려는 개발자들에게 어떤 조언을 해주시겠습니까?

NB: 우선 아티스트와 플레이어가 실제로 무엇을 필요로 하는지 이해하는 것부터 시작하여, 그 요구 사항을 효율적으로 충족할 수 있도록 렌더링 시스템을 설계하십시오. 불필요한 복잡성은 피하고, 기존 시스템으로부터 최대한의 결과물을 얻는 데 집중하며, 접근 방식은 단순하고 확장 가능하게 유지하십시오. 항상 타겟 하드웨어 (target hardware)에서 프로파일링 (profile)을 수행하십시오. 최적화 (optimization)는 중요한 지점에서 테스트되지 않으면 오히려 성능을 저하시킬 수 있습니다.

FF: 저도 그 의견에 동의합니다. 진정으로 중요한 시각적 특징들을 식별하고 이를 중심으로 전략을 구축하십시오. 모든 기능을 구현해야 한다는 압박감을 느끼지 마십시오. 성능과 시각적 품질을 모두 유지하기 위해 중요한 것에 우선순위를 두십시오.

Unity로 제작된 프로젝트에 대해 더 자세히 알아보려면 리소스 (Resources) 페이지를 방문하십시오.
*Nintendo Switch는 Nintendo의 상표입니다.