언리얼 엔진 5 나나이트 아키텍처: 포괄적인 기술 분석, 최적화 전략 및 플레이스테이션 5 개발 가이드
가상화된 마이크로폴리곤 지오메트리의 기초와 패러다임의 전환
실시간 렌더링(real-time rendering) 기술과 컴퓨터 그래픽스 산업에서 수십 년간 이어져 온 가장 큰 제약 중 하나는 하드웨어 리소스의 효율적인 사용을 위해 폴리곤 예산과 "드로 콜"(draw call) 수가 중앙처리장치(CPU)와 그래픽 처리 장치(GPU) 사이의 통신에서 야기하는 피할 수 없는 병목 현상들입니다. 1 전통적인 게임 개발 워크플로우에서 3D 아티스트와 테크니컬 디렉터가 고해상도 모델(예: 시네마틱 품질의 ZBrush 스컬프트, 레이저 스캔 또는 포토그래메트리 데이터)을 게임 엔진으로 가져오려면 수동으로 토폴로지를 최적화하고, "Level of Detail"(LOD) 체인을 생성하며, 고해상도 디테일을 "Normal Map"(노멀 맵) 내에 베이킹(baking)하는 것이 필수적이었습니다. 1 이 과정은 제작 일정을 늘리는 고된 작업 부하를 유발할 뿐만 아니라 메모리 제약으로 인해 화면의 디테일 수준을 인위적인 한계에 가두었습니다. 1 언리얼 엔진 5(UE5)와 함께 업계 표준이 된 나나이트 기술은 이러한 전통적인 장벽을 근본적으로 제거하는 가상화된 마이크로폴리곤 지오메트리(virtualized micropolygon geometry) 시스템입니다. 1 나나이트는 폴리곤 예산을 더 이상 기술적인 제약으로 두지 않고, 수십억 개의 폴리곤으로 구성된 영화 품질의 원본 파일을 수동 LOD 프로세스 없이 실시간으로 장면에 직접 가져올 수 있도록 합니다. 1 이 시스템은 플레이어의 카메라로 화면에서 현재 볼 수 있는 디테일만 처리하도록 설계되었으며, 픽셀 크기보다 작은 삼각형(triangle)이나 지오메트리 조각은 불필요하게 렌더링되지 않습니다. 3 이 기술은 지속적이고 유연하며 중단 없는 자동 LOD 시스템을 제공하여 전통적인 렌더링 파이프라인(rendering pipeline)을 완전히 GPU 중심의 데이터 스트리밍(streaming) 아키텍처로 대체합니다. 1 나나이트의 핵심 혁신은 네 가지 주요 항목으로 요약됩니다 1:
가상화된 지오메트리: 전체 장면에 단 하나의 거대한 스태틱 메시(mesh)로 취급되며 화면에 보이는 부분만 처리 대상에 포함됩니다.
자동 디테일 레벨(LOD): 점진적이고 끊기는 LOD 변경(LOD popping) 대신 거리와 화면 해상도에 따라 중단 없이 유연한 디테일 변화가 제공됩니다.
GPU 중심 파이프라인(Pipeline): 드로 콜과 컬링(culling) 작업이 CPU에서 가져와져 GPU의 병렬 처리 능력에 위임됩니다.
효율적인 스트리밍(Efficient Streaming): SSD를 통한 직접 메모리 스트리밍이 제공되어 필요한 지오메트리 데이터만 즉시 메모리에 로드됩니다.
본 연구 보고서는 나나이트 시스템의 심층적인 작동 원리, 프로젝트 통합에 필요한 단계, 최적화 요구 사항, 병목 현상을 극복하는 방법, 그리고 특히 하드웨어 수준에서 고유한 압축과 고속 데이터 스트리밍(I/O)을 갖춘 플레이스테이션 5(PS5) 플랫폼을 위한 게임 개발 동향을 포괄적인 분석 프레임워크로 검토합니다.
나나이트 기술 아키텍처 및 데이터 구조
나나이트 시스템의 핵심에 있는 철학은 지오메트리 데이터를 메모리 제한에 맞추려는 거대한 스태틱 메시(static meshes)로 다루는 것이 아니라, 가상 텍스처(virtual texturing)에서와 마찬가지로 동적으로 스트리밍되고(streaming) 온디맨드로 관리되는 조각난 데이터 세트로 다루는 것입니다. 3 기존 엔진은 오브젝트의 아주 작은 부분만 카메라의 시야(frustum) 안에 있어도 전체 오브젝트를 메모리에 로드하고 처리하려고 시도하는 반면, 나나이트는 이 가시성을 밀리미터 픽셀 정밀도로 평가합니다. 3
계층적 클러스터 구조 (Hierarchical Cluster Structure)
가져오기(import) 단계에서 나나이트 알고리즘은 3D 모델을 분석하여 계층적 클러스터(cluster) 트리로 분할합니다. 1 처리되는 각 스태틱 메시는 하드웨어 수준에서 최고의 성능을 발휘하도록 정확히 128개의 삼각형으로 구성된 작은 데이터 패킷(cluster)으로 나뉩니다. 1 128개의 삼각형이라는 이 고정 크기는 최신 GPU의 웨이브프론트(wavefront) 또는 워프 크기에 완벽하게 부합하며, 병렬 처리 장치와 캐시 제한(cache limits)으로부터 최대의 처리 효율성을 얻기 위해 특별히 선택된 최적의 단위입니다. 1 이러한 클러스터는 그들 사이에 경계 박스(bounding box) 정보, 화면 공간(screen space) LOD 선택을 위한 기하학적 오차 메트릭, 그리고 부모-자식(parent-child) 관계를 포함하는 방향성 비순환 그래프(Directed Acyclic Graph - DAG)와 유사한 트리 데이터 구조를 형성합니다. 1 카메라가 관련 오브젝트에 가까워지거나 멀어질 때, 시스템은 이 트리 구조를 실시간으로 탐색하여 각 화면 영역에 대해 어떤 클러스터가 화면의 픽셀 밀도에 가장 적합한지 결정합니다. 1 기존 접근 방식과 달리 오브젝트 전체가 갑자기 변경되지 않습니다. 끊기는 LOD 변경 대신 오브젝트 표면의 서로 다른 영역이 동시에 서로 다른 클러스터 디테일 수준으로 처리될 수 있으며, 하드웨어 래스터화에서 시각적 찢어짐이나 균열(crack)이 발생하지 않도록 가장자리가 부드럽게 병합됩니다. 3
가시성 버퍼 (Visibility Buffer)와 분리된 셰이딩
나나이트가 CPU 병목 현상을 극복하고 최신 렌더링 아키텍처에서 혁명을 일으킨 가장 중요한 구조는 렌더링 파이프라인(pipeline)의 대부분을 GPU로 직접 이동하고 기존의 전방(Forward) 또는 지연(Deferred) 셰이딩(shading) 로직을 "Visibility Buffer"(가시성 버퍼)로 대체하는 것입니다. 1 나나이트의 렌더링 루프에서 가시성 버퍼 개념은 다음과 같이 작동합니다: 기존 G-Buffer 구조에서는 픽셀을 계산할 때 색상, 노멀, 거칠기(roughness)와 같은 거대한 크기의 데이터가 각 픽셀에 대해 메모리에 기록됩니다. 반면 나나이트는 화면의 각 픽셀에 32비트 또는 64비트 크기의 식별 번호(Primitive ID 및 Cluster ID)만 기록합니다. 1 이 버퍼 메모리는 색상이나 셰이딩 데이터를 포함하지 않으며, 화면의 해당 특정 픽셀에 어떤 삼각형과 어떤 클러스터가 나타나는지를 보여주는 참조 맵일 뿐입니다. 1 가시성 버퍼가 완전히 채워진 후, 화면 공간의 각 픽셀에 대해 한 번만 머티리얼 데이터가 호출되고 셰이딩 작업이 수행됩니다. 이 "분리된"(decoupled) 아키텍처 덕분에 카메라 뒤에 남겨진 다른 오브젝트 뒤에 숨겨진, 또는 최종 이미지에 아무런 기여를 하지 않는 수백만 개의 삼각형에 대해 불필요한 머티리얼 계산이 수행되지 않습니다. 이 상황은 GPU의 가장 큰 적 중 하나인 "Overdraw"(오버드로우) 문제를 머티리얼 계산 기반으로 완전히 제거합니다. 9
GPU 중심 컬링(Culling) 메커니즘
나나이트 아키텍처에서 컬링(culling) 작업은 기존 엔진에서처럼 CPU에서 오브젝트(actor) 기반으로 수행되지 않습니다. CPU 측의 전통적인 드로 콜 준비가 완전히 우회되고, 컬링 프로세스가 GPU 내부의 컴퓨트 셰이더(compute shaders)에 직접 위임됩니다. 10 오클루전 컬링(Occlusion Culling) 단계에서 나나이트는 화면 공간에 다양한 깊이 수준(mipmaps)이 로그 방식으로 저장되는 HZB(Hierarchical Z-Buffer)라는 구조를 사용합니다. 9 HZB는 128개 삼각형으로 구성된 각 클러스터의 경계 박스(bounding box)를 화면 공간의 깊이 데이터와 비교합니다. 9 클러스터가 장면의 다른 오브젝트 뒤에 남아 있으면 즉시 렌더링 작업에서 버려집니다. 이 컬링은 매우 정밀하여 오브젝트 단위가 아닌 클러스터 단위로 수행되기 때문에 거대한 산 뒤에 남겨진 거대한 숲의 나무들 중 산 뒤에 남겨진 부분에 해당하는 클러스터만 컬링되는 동안 산정상에서 튀어나온 나뭇잎 클러스터는 계속해서 처리됩니다. 8
래스터화 경로: 소프트웨어 및 하드웨어 처리 동역학
나나이트는 삼각형을 화면 픽셀로 변환(래스터화)하기 위해 단일 처리 유닛을 사용하는 대신, 삼각형의 화면 크기와 머티리얼 속성에 따라 동적으로 결정되는 두 가지 별도의 래스터화 경로(raster path)를 사용합니다. 9 성능 최적화는 이 두 경로 사이의 균형을 완벽하게 구축하는 데 달려 있습니다.
소프트웨어 래스터화 (Software Raster Path)
소프트웨어 래스터화는 나나이트의 가장 효율적이고 빠르며 혁신적인 핵심 처리 경로입니다. 9 이 경로는 삼각형이 화면에서 1픽셀보다 작거나(sub-pixel) 정확히 1픽셀 크기일 때 활성화됩니다. 9 이 시나리오에서 나나이트는 GPU의 하드웨어 삼각형 드로잉 단일을 완전히 우회하여 프로세스를 "Compute Shader"(컴퓨트 셰이더)를 통해 실행합니다. 64비트 원자 연산(atomic interlocks)을 사용하여 픽셀이 가시성 버퍼에 엄청난 속도로 기록되도록 보장합니다. 개발자 콘솔에서 r.Nanite.Visualize.Advanced 1 또는 r.nanite.showmeshdrawevents 1 명령으로 Raster Bins 시각화 모드가 켜지면 소프트웨어 래스터화를 통과하는 클러스터가 파란색으로 표시됩니다. 9 잘 최적화된 장면에서는 지오메트리의 압도적인 다수가 파란색이어야 합니다. 9
하드웨어 래스터화 (Hardware Raster Path)
하드웨어 래스터화는 삼각형이 화면에서 1픽셀 크기보다 크거나 나나이트의 컴퓨트 기반 소프트웨어 래스터화에서 처리할 수 없는 특수 머티리얼 속성이 사용될 때 활성화되는 고전적인 GPU 드로잉 방법입니다. 9 이 경로는 시각화 모드에서 빨간색으로 표시됩니다. 9 특히 카메라도 거대한 벽에 가까워지면 삼각형이 픽셀보다 커지기 때문에 시스템이 하드웨어 래스터화로 전환되는 것은 정상입니다. 9 그러나 카메라에서 먼 오브젝트나 마이크로폴리곤이 여전히 빨간색으로 표시되면 이는 "Hardware Fallback"(하드웨어 폴백)이 발생했음을 나타내며 심각한 최적화 문제입니다. 9 하드웨어 래스터화로 원치 않는 저하가 발생하는 가장 큰 원인은 마스크된(masked), 투명한 또는 복잡한 변형 오프셋이 있는 머티리얼의 사용입니다. 9
Raster Bins (래스터 빈) 및 머티리얼 관리
나나이트 성능의 핵심은 지오메트리 자체보다는 지오메트리에 적용된 머티리얼이 "Raster Bins"라는 가상 빈에 분산되는 방식과 관련이 있습니다. 9 나나이트는 표준, 불투명 및 픽셀 깊이 오프셋(PDO) 또는 월드 포지션 오프셋(WPO)이 없는 모든 머티리얼을 단 하나의 거대한 Raster Bin(래스터 빈)에 포함하며, 시스템은 이 빈을 단일 패스(pass)에서 번개 같은 속도로 처리합니다. 9 그러나 오브젝트에 변위(displacement), 마스킹(masked/alpha test) 또는 바람 효과를 위해 사용되는 밀집된 WPO가 포함된 머티리얼이 사용되면 이러한 오브젝트는 나나이트의 빠른 패스 경로에서 제외되어 각 머티리얼 유형에 대해 서로 다른 독립적인 Raster Bin이 생성됩니다. 9
성능 클래스머티리얼 유형 및 속성나나이트 영향 및 처리 상태전략적 개발자 제안최고 (Best)Opaque (불투명), WPO, PDO 또는 Displacement 오프셋이 없는 순수한 머티리얼.단일 Raster Bin 내에서 혼합됩니다. 소프트웨어 래스터화가 활성 상태로 작동하며, 드로 콜 비용이 0에 가깝습니다.9프로젝트의 환경 디자인, 건물 및 하드 서페이스(hard surface)의 90% 이상이 확실히 이 유형이어야 합니다.9좋음 (Good)Opaque (불투명), 단 최소 수준의 WPO (World Position Offset) 존재.WPO가 사용되기 때문에 스태틱 클러스터가 GPU에서 개별적으로 계산되기 시작합니다. 경계 박스(bounding boxes)가 움직임으로 인해 변경되므로 컬링(culling) 작업이 어려워집니다.경계 박스의 손상과 잘못된 컬링 수행을 방지하기 위해 WPO 이동 거리는 반드시 클램핑(clamp)되어야 합니다.3 변형이 정적이면 베이크되어야 합니다.9보통 (Okay)Masked (마스크됨/투명한 가장자리, Alpha Cutout).강제로 하드웨어 래스터화(Hardware Raster Path)로 떨어집니다. 빈 픽셀의 지속적인 평가 결과로 심각한 "Overdraw"(오버드로우)를 유발합니다.고전적인 나뭇잎 또는 울타리 모델링에 사용되지만 성능을 저해하므로 매우 아껴서 사용해야 합니다.8최악 (Worst)복잡하게 변형된 머티리얼 (밀집된 WPO + PDO).각 변형이 별도의 Raster Bin을 생성합니다. 상태 변경을 늘리고 프레임 시간을 즉시 예산 한도를 초과하게 만듭니다.먼 거리의 오브젝트에서는 즉시 취소되거나(LOD fallback) UE 5.7과 함께 제공되는 나나이트 스키닝(Nanite Skinning)과 같은 보다 현대적인 대안으로 전환되어야 합니다.9
너무 많은 Raster Bin이 생성되면 GPU에서 증가하는 상태(state) 변경과 증가하는 드로 콜 변형을 의미하며 GPU를 심각하게 느리게 만듭니다.9 60 FPS를 목표로 하는 프로젝트(프레임당 16.66ms)에서는 VisBuffer 작업이 4ms 미만, BasePass 작업이 3ms 미만으로 유지되어야 하며, 그렇지 않으면 후처리기(post-processing), Lumen, 인공지능과 같은 다른 시스템에 할당될 시간이 남지 않습니다.7
Nanite 엔테그레이션: 프로젝트에서 사용하는 방법
Nanite 엔테그레이션은 기존의 Unreal Engine 게임 개발 워크플로우에 최소한의 마찰력으로 통합될 수 있도록 설계되었습니다. 구세대 방식의 수동 LOD 생성 또는 노멀 맵 베이킹 과정을 없애주는 이 시스템은 올바르게 설정되면 성능을 스스로 최적화합니다.1
지오메트리 유형 및 지원되는 컴포넌트
지오메트리가 Nanite의 기능을 활용하려면 임포트 단계 또는 그 이후에 Static Mesh Editor를 통해 이 기능을 활성화해야 합니다.3 Unreal Engine 5의 최신 버전에서는 Nanite이 지원하는 컴포넌트 유형이 크게 확장되었습니다:
● 스태틱 메시(Static Meshes): 프로젝트에 포함된 모든 Static Mesh는 에디터 내에서 "Enable Nanite Support" 옵션을 체크하여 변환할 수 있습니다. 수천 개의 오브젝트가 있는 거대한 씬에서는 Content Browser를 통해 일괄 선택(batch-enable)하여 전체 라이브러리를 동시에 Nanite 포맷으로 전환할 수 있습니다.3 Nanite 시스템의 주된 타겟층이 바로 이 메시들입니다.
● 스켈레탈 메시(Skeletal Meshes): 초기 UE5 버전에서는 정적 오브젝트만 지원되었으나, UE 5.3 이후 버전에서 제공되는 Skeletal Mesh API 지원 덕분에 동적으로 변형되는(애니메이션되는) 캐릭터, 크리처, 차량에서도 Nanite을 사용할 수 있게 되었습니다.3 스켈레탈 메시의 가장 큰 혁신은 전체 메시당 단 하나의 드로우 콜(one draw call)만 생성된다는 점입니다. Nanite Skeletal Mesh는 전통적인 지오메트리 LOD 대신 애니메이션 LOD를 사용하여 작동합니다.3
● 스플라인 메시(Spline Meshes) 및 랜드스케이프(Landscape): Nanite은 도로, 파이프라인, 벽과 같이 곡선을 따라 모양이 변하는 Spline Mesh와 광활한 오픈 월드 Landscape 토폴로지(Nanite Tessellation을 통해)를 기본적으로 지원합니다.3 지면의 미세한 변위(displacement) 디테일은 폴리곤 밀도를 높이거나 성능을 저하시키지 않고 머티리얼을 통해 직접 구현할 수 있습니다.
● 인스턴스화된 메시(Instanced Static Meshes - ISM / HISM): 수백만 개의 복사본이 있는 오브젝트(예: 거대한 숲의 바위나 건물의 벽돌)는 Nanite의 가시성 버퍼 덕분에 단일 메모리 풋프린트로 렌더링됩니다. 단, 씬에 존재할 수 있는 최대 Nanite 인스턴스(instance) 수는 하드웨어적으로 1,600만 개로 제한된다는 점을 유의해야 합니다.3
폴백 메시(Fallback Mesh) 생성 및 역할
Nanite 데이터가 생성될 때 "Build Nanite" 체크박스가 선택되면, 엔진은 고딕테일 메시와 함께 전통적인 폴리곤 수를 가진 "Fallback Mesh"(폴백 메시)라는 단순화된 지오메트리를 자동으로 파생시킵니다.13
이 폴백 메시가 존재하는 이유는 매우 중요합니다. Nanite의 GPU 중심 래스터라이제이션 시스템은 복잡한 물리 충돌(collision) 계산, Lightmass를 이용한 사전 계산된 라이트맵(baked lighting), 그리고 가장 중요한 하드웨어 레이 트레이싱(hardware ray tracing / Lumen HWRT) 반사광에 직접 사용할 수 없기 때문입니다.13 게임 엔진의 CPU 측 로직 시스템은 이 전통적인 삼각형 데이터가 필요합니다. 폴백 메시의 디테일 수준은 "Fallback Relative Error" (폴백 상대 오차) 파라미터를 변경하여 제어할 수 있습니다.3 오차율이 낮아질수록 폴백 메시의 폴리곤 수가 증가하며, 이는 하드웨어 레이 트레이싱 반사(Lumen Hit Lighting)가 더 정확하게 계산되도록 돕지만 메모리(VRAM) 사용량도 비례하여 증가시킵니다.14
Nanite Foliage: UE 5.6/5.7에 도입된 복셀 및 조립(Assembly) 시스템
게임 엔진에서 숲 지역과 촘촘한 식생은 겹쳐진 수많은 투명(masked) 나뭇잎 표면 때문에 수년간 Nanite의 가장 취약한 약점으로 여겨졌습니다.15 전통적인 풀이나 나뭇잎 모델링(alpha cards)은 픽셀이 여러 번 반복해서 평가되도록 만들고 HW Raster에 부담을 주는 "Overdraw" 문제를 유발했습니다.8
Unreal Engine 5.6 및 특히 5.7 버전은 "Nanite Foliage" 시스템을 통해 이 문제를 근본적이고 아키텍처적인 변화로 해결했습니다 12:
Nanite Voxels (복셀): 카메라에서 멀어지는 나무나 식생의 복잡하고 오버드로우를 유발하는 나뭇잎 삼각형들은 "Shape Preservation" 메뉴에서 "Voxelize" 옵션을 설정하여 원거리에서 복셀로 변환됩니다.17 마인크래프트 블록과 유사한 이 복셀들은 삼각형과 달리 볼륨감 있는 픽셀로 처리되어 투명도(alpha) 필요성을 완전히 제거하며, 결과적으로 하드웨어 레벨에서 오버드로우 문제를 방지합니다.15 멀리 있는 수십만 그루의 나무는 화면 픽셀 크기의 볼륨 복셀로서 극도로 낮은 비용으로 처리되며, 가까워질수록 부드럽게 풀 디테일의 마이크로폴리곤으로 전환됩니다.15
Nanite Assemblies (어셈블리): 거대한 나무들이 고해상도로 모델링되면 디스크와 메모리에서 엄청난 용량을 차지하게 됩니다. Nanite Assemblies 기능 덕분에 나무의 각 가지, 잎, 줄기는 별도의 거대한 스태틱 메시가 아니라 USD(Universal Scene Description) 임포터를 통해 계층적 전체(assembly)로 읽혀집니다.12 Houdini Solaris와 같은 프로그램에서 준비된 NaniteAssemblyRootAPI 스키마 덕분에 수천 개의 잎은 사실상 동일한 작은 잎 메시의 인스턴싱(instancing) 방식으로 호출된 것입니다.19 이 구조는 메모리 풋프린트를 엄청나게 줄여줍니다.
Nanite Skinning: 전통적인 WPO(World Position Offset) 기반 바람 애니메이션은 각 클러스터의 바운딩 박스를 매 프레임마다 변경하여 CPU/GPU에서 지속적인 재계산(culling invalidation)을 요구했습니다.15 UE 5.7에 도입된 Nanite Skinning을 사용하면 나무가 스켈레탈 메시(skeletal mesh)로 임포트되며, 물리 및 절차적 바람 효과는 뼈대(bones)를 통해 "Dynamic Wind" 플러그인을 사용하여 계산됩니다.12 이를 통해 Nanite은 Raster Bins 성능을 희생하지 않으면서 훨씬 더 유기적이고 일관된 바람 상호작용을 제공합니다. 새로운 Quixel Megaplants 라이브러리와 Procedural Vegetation Editor(PVE)는 이러한 기술들을 완벽하게 통합하여 활용함으로써 60 FPS 목표를 쉽게 달성할 수 있도록 합니다.15
최적화 프로세스: 무엇을 주의해야 할까요?
Nanite은 성능을 향상시키도록 설계되었지만 "무한 폴리곤" 약속은 마법의 지팡이가 아닙니다. 잘못 사용하거나 하드웨어 한계를 지키지 않을 경우 프레임(frame) 시간을 심각하게 위협할 수 있는 복잡한 시스템입니다.11
투명도(Translucency), 마스킹 및 오버드로우 문제
전통적인 게임 최적화(UE4 이전)에서는 디테일한 오브젝트를 저폴리곤 표면과 투명 마스크(alpha texture / masked material) 조합으로 시뮬레이션하는 것이 표준적인 접근 방식이었습니다.8 하지만 Nanite 아키텍처에서는 이 접근 방식이 완전히 잘못되었으며 재앙적인 결과를 초래합니다.8
Nanite은 가시성 버퍼를 계산할 때 투명한(빈) 픽셀을 건너뛰기 위해 추가적인 하드웨어 패스가 필요합니다. 마스크 머티리얼이 겹쳐서 배치되면(예: 철망 울타리나 나뭇잎), 시스템은 동일한 픽셀의 깊이와 투명도를 수십 번 읽고 처리해야 하며 이를 "Overdraw"라고 부릅니다.10
핵심 규칙: Nanite 시스템에서는 "지오메트리는 매우 저렴하지만 투명도는 매우 비싸다". 나뭇잎, 울타리, 그물망 같은 구멍 뚫린 오브젝트를 만들 때 마스크된 텍스처(masked material)를 사용하는 대신, 필요하다면 모양의 테두리를 수십만 개의 추가 폴리곤으로 완전하게(fully modeled) 모델링하고 머티리얼을 반드시 "Opaque"로 설정해야 합니다.8 완전히 모델링된 나뭇잎은 마스크된 평면(plane)보다 훨씬 빠르게 렌더링됩니다.8
가상 그림자 지도(Virtual Shadow Maps - VSM) 통합
전통적인 그림자 맵(Cascaded Shadow Maps - CSM)은 Nanite 오브젝트가 제공하는 마이크로폴리곤 수준의 엄청난 디테일 수준에 적응할 수 없습니다. Nanite과 함께 사용하도록 특별히 설계된 Virtual Shadow Maps(VSM)는 그림자 해상도를 화면 픽셀과 동적으로 일치시켜 면도날처럼 날카로운 그림자를 제공합니다.23
VSM은 본질적으로 높은 VRAM 메모리 요구 사항을 가집니다. 그림자를 드리우는 오브젝트가 계속 움직이는 경우(예: WPO로 흔들리는 나뭇잎), VSM 그림자 캐시(shadow cache)는 매 프레임마다 무효화(invalidated)되며 그림자 맵이 처음부터 다시 계산되어 심각한 FPS 드롭을 유발합니다.22 따라서 정적 씬이나 건물은 Nanite과 VSM 조합으로 완벽하게 작동하지만, 움직임이 많은 숲 지역에서는 WPO 제한을 적용하거나 성능 테스트에 따라 전통적인 그림자 맵(Shadow Maps)으로 전환하는 것을 고려해야 합니다.25
프로파일링(Profiling) 및 성능 읽기 명령어
최적화 문제의 근본 원인을 찾고 병목 현상이 CPU와 GPU 중 어디에서 비롯되었는지 확인하기 위해 UE5에서 제공하는 내부 프로파일(stat) 명령어를 정기적으로, 그리고 프로젝트 초기 단계부터 파악하는 것(optimize early 원칙)이 필수적입니다.26
개발자가 정기적으로 사용해야 하는 프로파일 명령어 및 시각화 도구는 다음과 같습니다 28:
프로파일 명령어 / 모드설명 및 사용 목적개발자 액션stat unit기본 병목 현상 감지. 화면의 총 소요 시간을 "Frame" (전체 시간), "Game" (CPU 게임 루프), "Draw" (CPU 렌더 준비) 또는 "GPU"별로 밀리초(ms) 단위의 세부 내역으로 보여줍니다.28GPU 시간이 16.66ms를 초과하면 그래픽 제약 조건을, Game 시간이 초과하면 인공지능이나 Blueprint 틱 최적화에 집중해야 합니다.
명령어 / 도구기능 및 설명최적화 액션stat gpu 또는 stat scenerenderingGPU 내부의 구체적인 렌더 부하를 나열합니다. Nanite BasePass, Lumen, 그림자(Shadow Depths) 및 포스트 프로세스 부하에 소요되는 시간을 세부적으로 보여줍니다.Nanite VisBuffer가 4ms를 초과하거나 BasePass가 3ms를 초과하는 경우 Raster Bins 또는 Overdraw를 확인해야 합니다.r.nanite.showmeshdrawevents 1GPU Profiler (Ctrl+Shift+,) 내에서 특정 Nanite 머티리얼과 오브젝트가 소요하는 시간을 계층적으로 검사합니다.비용이 많이 드는 WPO 머티리얼이나 투명 오브젝트를 식별하고 격리하는 데 사용됩니다.NaniteStats화면 모서리에 "ShaderPrint" 기술로 직접 UI를 그려줍니다. 가상 그림자와 기본 뷰(Primary View) 중 어느 쪽이 Nanite에서 드로잉 부하를 유발하고 있는지 실시간으로 필터링합니다.콘솔에 파라미터(primary, VirtualShadowMaps)를 입력하여 활성 패스의 부하를 파악합니다.View Mode > Nanite Visualization > Overdraw화면에서 픽셀이 겹치는 밀집 영역을 파란색(좋음), 주황색, 빨간색(나쁨) 스펙트럼으로 색칠합니다.투명 머티리얼이 밀집된 영역을 식별하고 완전 모델링(opaque)으로 수정합니다.
PlayStation 5 (PS5) I/O 아키텍처와 Nanite 스트리밍(Streaming)의 관계
PlayStation 5용 게임을 개발할 때 Nanite의 잠재력을 이론적 한계를 넘어 실제 성능의 정점으로 끌어올리는 유일한 요소는 콘솔의 혁신적인 SSD 스토리지와 하드웨어 압축/압축 해제(decompression) 아키텍처입니다. Nanite의 128 삼각형 클러스터는 필요 시 로딩(on-demand streaming pages) 방식으로 설계되었으며, PS5의 I/O(입출력) 계층 구조는 이 설계와 완벽한 조화를 이룹니다.
Kraken 하드웨어 압축 및 Oodle Texture 통합
기존 PC 시스템과 구세대 콘솔(PS4, Xbox One)에서는 디스크에서 읽어온 압축 데이터(ZLIB 같은 범용 알고리즘 사용)를 먼저 RAM에 적재한 뒤, 메인 프로세서(CPU)가 이를 풀어 해제해야 합니다. 수십억 개의 폴리곤으로 이루어진 Nanite 클러스터의 거대한 용량이 카메라가 움직일 때마다 초당 기가바이트(GB/s) 단위의 새로운 데이터 스트림을 요구할 때, 이 소프트웨어 압축 해제(software decompression) 방식은 PC와 구세대 콘솔에서 프로세서를 멈추게 만들고 게임 메커니즘(인공지능, 물리 등)을 처리하지 못하게 만듭니다.
소니는 PS5 하드웨어를 설계할 때 표준에만 머무르지 않고, RAD Game Tools가 개발한 Oodle Kraken 압축 알고리즘을 해제할 수 있도록 실리콘 수준의 특수 하드웨어 압축 해제기 칩(hardware decompressor block)을 I/O 컴플렉스에 통합했습니다. Kraken은 구세대 ZLIB 형식에 비해 데이터를 무손실(lossless) 방식으로 29% 더 작게 압축할 수 있으며, 압축 해제 속도 측면에서는 3~4배 더 효과적입니다.
PS5의 Kraken 칩은 "Oodle Texture" 무손실 형식(BC7Prep 등의 텍스처 압축 최적화와 함께)을 사용할 때 SSD의 기본 5.5 GB/s 읽기 속도를 곱셈 효과로 증폭시켜, 초당 평균 8~9 GB, 피크(peak) 시에는 초당 17~22 GB에 달하는 놀라운 대역폭 속도로 데이터를 전송합니다.
CPU 병목 현상 극복 및 대역폭 승수
이 I/O 아키텍처가 Nanite에 갖는 의미는 매우 깊습니다. 다음 표는 PS5의 압축 기술이 경쟁 기기 및 구세대 기기에 비해 얼마나 큰 CPU 절감 효과를 제공하는지 요약합니다:
압축 하드웨어 및 알고리즘 메트릭PS4 / 이전 세대Xbox Series XPlayStation 5기본 압축 알고리즘ZLIB (소프트웨어 중심)BCPack (ZLIB HW 변형)Oodle Kraken + Oodle Texture (전용 HW)최대 출력 속도(Peak Bandwidth)~100-200 MB/s~6 GB/s (SFS 적용 시 유효)~22 GB/s평균 출력 속도(Average Bandwidth)< 100 MB/s~4.8 GB/s8-9 GB/s (Oodle 사용 시 17 GB/s)프로세서(CPU) 동등 성능 절감CPU에 완전한 부하 유발Zen 2 코어 약 5개 분량에 해당Zen 2 코어 약 9개 분량에 해당
이 표는 분명하게 보여줍니다. PS5의 I/O 컴플렉스는 일반 컴퓨터에서 SSD의 데이터를 해제하기 위해 무려 9개의 독립된 Zen 2 프로세서 코어가 소비할 연산량을 혼자서 도맡고 있습니다.
Nanite가 매 프레임(16ms 이내)마다 카메라의 새로운 시점에 따라 디스크에서 수만 개의 새로운 클러스터(streaming pages)를 요청할 때, SSD에서 읽어온 이 데이터들은 하드웨어 Kraken 칩을 거쳐 CPU를 완전히 우회한 채 직접 RAM과 GPU 풀로 공급됩니다. 게임 개발자들은 데이터가 "제때 도착하지 못하는 현상(pop-in)"에 대한 걱정 없이 Nanite의 "Virtual Texturing for Geometry"(지오메트리를 위한 가상 텍스처) 철학을 끝까지 활용할 수 있습니다. 에픽게임즈 엔지니어들은 이 거대한 잠재력을 파악하고, PS5의 이 독특한 I/O 구조를 위해 언리얼 엔진 5의 코어 로딩 하위 시스템(core I/O subsystems)을 PS5 전용으로 처음부터 다시 작성했습니다.
VRAM 관리 및 스트리밍 풀(Streaming Pool) 최적화
PlayStation 5는 16 GB 용량의 초고속 통합(unified) GDDR6 메모리를 탑재하고 있습니다. 하지만 PC 아키텍처와 달리 콘솔에서는 메모리 한계가 엄격하고 유연하지 않은(fixed memory) 구조를 가집니다. 가상 메모리 오버플로우는 용인될 수 없으며 시스템의 즉각적인 다운(OOM - Out of Memory)을 유발합니다.
Nanite가 사용하는 메모리 풀(streaming pool)은 화면 해상도에 따라 기하급수적으로 증가합니다. Nanite는 삼각형 ID를 저장하기 위해 화면 크기에 비례하는 가시성 버퍼(Visibility Buffer)를 사용합니다. 해상도가 1080p에서 4K로 올라갈 때(픽셀 수가 4배 증가하므로), Visibility Buffer의 VRAM 요구량 역시 곧바로 4배로 늘어납니다.
PS5 프로젝트에서 최적화를 보장하고 VRAM을 관리하려면 "Nanite Streaming Pool" 크기를 개발자가 제한해야 합니다. 기본 풀 크기는 빈 프로젝트에서 512 MB 부근을 유지하지만, Nanite 비중이 높은 AAA 프로젝트에서는 명령 줄이나 .ini 파일(예: DefaultEngine.ini 내부의 ``)에서 다음과 같은 매개변수를 설정해야 합니다:
r.Nanite.Streaming.StreamingPoolSize = 2048
(씬의 무게와 기타 시스템에 따라 2000~3000 MB 수준). 이 풀 예산이 너무 부족하게 설정되면 원거리 오브젝트의 고밀도 세부 클러스터가 제때 로드되지 못해 Nanite 폴백 모델로 떨어지게 되며, 너무 넓게 잡으면 Lumen 표면 캐시(Surface Cache), 고해상도 텍스처, 운영체제를 위한 RAM이 부족해집니다. 개발자들은 UE 5.7부터 콘솔 한계(일반적으로 2~4 GB 초과)를 넘어서는 StreamingPoolSize 상황에서 경고 시스템이 작동하는 것을 보게 될 것입니다.
PlayStation 5 개발 요구 사항 및 콘솔 설정
언리얼 엔진 5를 통한 PS5 플랫폼 개발 과정은 에픽게임즈와 소니의 긴밀한 협력 덕분에 매우 정제되었지만, 프로젝트가 컴파일되고 최적의 속도로 실행되려면 특정 소프트웨어 개발 키트(SDK) 및 시스템 구성을 반드시 준수해야 합니다.
SDK 버전 및 컴파일러 플래그
언리얼 엔진의 최신 5.6 및 5.7 버전으로 PS5 하드웨어에서 빌드(컴파일)할 때 주의해야 할 하드웨어 및 소프트웨어 라이브러리 요구 사항은 다음과 같습니다:
지원되는 SDK 및 시스템 버전: PS5 개발 환경의 기본 요구 사항은 "Prospero SDK 11.00.00.40"(또는 고급 스토리지 시스템의 경우 SDK 12) 및 "시스템 소프트웨어 11.00.00.43"으로 지정되었습니다. 프로젝트 구성(IntlNetwork SDK 또는 Interhaptics 같은 서드파티 플러그인과 작업할 때)에서의 버전 불일치는 충돌의 원인이 됩니다.
컴파일러(Compiler) 설정: 컴파일 작업 중 소니 고유의 툴체인 외에 clang-cl이 사용됩니다. Clang 19에서의 정의되지 않은 동작(undefined behavior) 및 NaN(Not a Number) 오류를 방지하기 위해 소스 코드는 이제 필수적으로 -fhonor-nans 플래그로 컴파일됩니다. 또한 과거에 크로스 플랫폼 문제를 유발했던 -ffp-contract=off 매개변수는 -ffast-math와 충돌하기 때문에 PS5 컴파일러에서 제거되었습니다.
표준 라이브러리(Stdlib) 전환: UE 5.7과 함께 PS5용 C++20 표준 라이브러리(stdlib v2) 지원이 추가되었습니다. 개발자들은 미래 지향적 호환성과 성능 향상을 위해 UEBuildPS5.cs 또는 BuildConfiguration.xml 구성 파일을 통해 StandardLibVersion = 'v2'를 지정할 것을 강력히 권장합니다.
시스템 최적화 설정: GPU 상의 샘플러(sampler) 상태가 누적되는 것을 방지하기 위해 AgcRHI 아키텍처에 새로운 LRU(Least Recently Used) 캐시 시스템이 도입되었습니다. 이 제한은 기본적으로 r.Agc.MaxSamplerStates 4096으로 설정되어 있습니다.
60 FPS 목표를 위한 확장성(Scalability) 프로필
UE5는 PS5 및 Xbox Series X 콘솔에서 기본 "Epic" 품질 수준으로 30 FPS 목표(프레임당 33.3ms)에 맞춰 구성되어 있습니다. 레이 트레이싱과 막대한 폴리곤 부하가 걸리는 현대 게임에서 60 FPS(프레임당 16.6ms)를 목표로 하는 것은 Nanite와 Lumen의 렌더링 해상도 및 품질에 대한 의도적인 희생을 요구합니다.
PS5에서 부드러운 60 FPS 경험으로 게임을 출시하고자 하는 스튜디오는 엔진의 하드웨어 수준 DeviceProfiles.ini 설정에서 Lumen 글로벌 Illumination(GI) 및 반사 시스템의 품질을 60 FPS에 맞추어 적응시키는 "High" 스케일로 낮추어야 합니다. 이 프로필에서 게임은 Temporal Super Resolution (TSR)으로 업스케일되기 전에 내부적으로(internal resolution) 1080p 또는 1440p 부근에서 렌더링됩니다.
게임 디렉토리 내의 [ProjectName]\Platforms\PS5\Config\PS5DeviceProfiles.ini 파일에 직접 다음 구성 블록을 추가해야 합니다:
; Set Lumen GI and reflection quality to High, targeting 60 fps console budget
+CVars=sg.GlobalIlluminationQuality=2
+CVars=sg.ReflectionQuality=2
이 구성은 Lumen의 연산 부하를 콘솔의 한계 수준으로 낮춰, Nanite로 처리되는 수백만 개의 폴리곤이 프레임당 16.66ms 내에 숨 쉴 수 있는 여유를 제공합니다. 추가적으로 Nanite 성능을 향상시키기 위해 TSR의 얇은 지오메트리 감지(Thin Geometry detection) 기능을 활성화 상태로 유지하는 것이 중요합니다.
Lumen 및 Nanite 동기화를 위한 PS5 전용 개선 사항
Nanite 시스템 단독으로는 오직 정적 지오메트리 드로잉만을 담당합니다. 하지만 게임의 시각적 품질을 결정하는 것은 Nanite 표면에서 반사되어 포토리얼리스틱한 그림자를 형성하는 Global Illumination(글로벌 일루미네이션) 시스템인 Lumen입니다. 두 시스템이 결합할 때 PS5 하드웨어는 한계까지 밀어붙여집니다.
Lumen은 두 가지 작동 모드를 가집니다: 거리 필드(Distance Fields)를 사용하는 소프트웨어 레이 트레이싱(SWRT)과 삼각형을 직접 연산하는 하드웨어 레이 트레이싱(HWRT). Nanite는 보유한 복잡한 지오메트리를 앞에서 언급한 폴백 메시(Fallback Meshes)를 통해 HWRT 메커니즘에 공급합니다. 구세대 엔진 버전에서는 60 FPS를 위해 부득이하게 SWRT가 권장되었으나, 언리얼 엔진 5.6 및 5.7 버전에서는 콘솔 하드웨어(특히 PS5의 AMD RDNA2 기반 RT 코어)의 부담을 덜어줄 근본적인 HWRT 개선이 이루어졌습니다:
1. ShortRangeAO 최적화: 근거리 앰비언트 오클루전(Ambient Occlusion) 연산이 새로운 디노이저(denoiser)의 도움을 받아 이제 해상도의 절반(half resolution)으로 구동됩니다. 이 작업은 콘솔에서 이 패스가 정확히 두 배 더 빨라지도록 만들어 줍니다. 49
2. Far Field(원거리) Occlusion Only 모드: 거대한 오픈 월드에서 World Partition 시스템으로 로드되는 아주 먼 거리의 Nanite 오브젝트에서 오는 반사 연산은 시스템을 질식시킬 수 있습니다. 새로운 r.LumenScene.FarField.OcclusionOnly 1 명령어를 사용하여 PS5에서 Lumen의 원거리 성능을 50% 향상시킵니다. 49
3. Downsampled Screen Probe Gather: 주변 조명을 화면에 투영하는 Probe Gather 패스에서 픽셀 간의 통합 샘플링 비율을 낮추는 것(r.Lumen.ScreenProbeGather.IntegrateDownsampleFactor)은 PS5의 1080p 렌더링 시나리오에서 0.3~0.5ms의 시간을 절약해 줍니다. 20 디테일에 약간의 부드러움이 보일 수 있으나 60Hz 예산에는 매우 이상적인 트레이드오프입니다.
4. Shader Execution Reordering (SER): HitLighting 및 레이 트레이스드 투명도(ray-traced translucency)를 사용하며 매우 다양한 머티리얼을 가진 복잡한 씬에서, 하드웨어 수준에서 명령의 재정렬 작업을 활성화하는 r.Lumen.HardwareRayTracing.ShaderExecutionReordering 명령어는 지원되는 RHI 유닛에서 가속을 제공합니다. 49
개발자가 씬에서 높은 Nanite 최적화에도 불구하고 PS5의 렌더링 한계에 부딪히는 경우, "stat gpu" 프로필로 HWRT 비용을 측정하고 필요한 경우 그림자 연산 비용을 줄이기 위해 방향성 라이트에서 가상 그림자 지도(VSM) 대신 고전적인 Shadow Maps로 되돌아가는 시나리오를 프로젝트 초기 단계에(optimize early) 테스트해야 합니다. 25
전략적 결론 및 개발자 제안
심층적인 분석을 바탕으로, 언리얼 엔진 5의 Nanite 아키텍처는 최신 GPU compute shader 기능, 하드웨어 레이 트레이싱 통합, 차세대 데이터 압축 알고리즘을 융합하여 컴퓨터 그래픽스 산업에서 진정한 혁신을 일으키고 있습니다. 폴리곤 수와 드로우 콜 병목 현상을 더 이상 장애물로 만들지 않는 이 기술은 그와 동시에 서로 다른 워크플로우(Assemblies, Voxelization)와 엄격한 메모리 예산 규율(Streaming Pools)을 가져옵니다.
PlayStation 5 플랫폼에서 게임을 개발할 테크니컬 아티스트(Technical Artists)와 엔진 프로그래머(Engine Programmers)가 반드시 고려해야 할 핵심 전략적 발견 사항은 다음과 같습니다:
1. I/O 이점을 올바르고 한계까지 활용하기: PS5의 독보적인 Kraken 하드웨어 디컴프레서는 SSD를 통해 엄청난 I/O 대역폭을 제공합니다. 개발자들이 Nanite 스트리밍을 제한하는 구세대 수동 LOD 전략에서 벗어나 영화 품질의 원본 소스 메시(source mesh) 사용으로 직접 전환하는 것이 시스템의 자연스러운 흐름에 더 적합합니다.
2. 투명성 및 오버드로우 비용 피하기: Nanite의 약점인 WPO(World Position Offset) 기반 애니메이션과 알파 마스크/컷아웃(Alpha Mask/Cutout) 사용은 특히 식물 군락에서 성능을 크게 떨어뜨립니다. UE 5.6 및 5.7에서 제공되는 Nanite Voxels, Nanite Assemblies 및 Nanite Skinning 기능은 PS5의 60 FPS 오픈 월드 목표에서 기존 풀 모델링을 대체할 핵심 방법으로 채택되어야 합니다. 모델 최적화 대신 고폴리곤이지만 매끄러운 "Opaque" 지오메트리로의 전환이 필수적입니다.
3. 정밀한 VRAM 예산 책정: PS5의 고정 메모리 구조는 Nanite 가시성 ID(Visibility Buffer)와 Lumen 표면 캐시에 의해 빠르게 소모될 수 있습니다. StreamingPoolSize 제한은 세심하게 설정해야 하며, 4K 네이티브 렌더링 스케일링 대신 Temporal Super Resolution(TSR)을 동반한 1080p에서 1440p 사이의 내부 해상도 목표를 사용하여 높은 시각적 품질과 안정적인 프레임 속도를 조화시켜야 합니다.
4. 정기적이고 조기 프로파일 분석(Optimize Early): 개발 프로세스 끝까지 기다리지 말고 stat gpu, stat unit, NaniteStats 프로파일링 도구를 적극적으로 모니터링해야 합니다. 문제가 되는 Raster Bins를 생성하는 머티리얼 구성을 찾아 병합함으로써 CPU와 GPU 간의 상태 변경을 최소화해야 합니다.
Nanite는 마법 같은 성능 향상 지팡이가 아닙니다. 오히려 기능을 올바르게 사용하면 비전을 제한하지 않지만, 규칙을 지키지 않으면(예: 과도한 마스크 머티리얼 사용) 하드웨어 장벽에 강하게 부딪히게 만드는 매우 강력한 생태계입니다. PS5 하드웨어의 전용 I/O 아키텍처와 언리얼 엔진 5의 렌더링 혁신이 동기화되어 작동할 때, 인터랙티브 미디어의 시각적 및 볼륨적 경계는 전례 없는 방식으로 확장됩니다.
*참고: 이미지는 Google Gemini에 의해 생성되었습니다.