대규모 오브젝트 렌더링, Unity GPU Instancing과 SRP Batcher로 성능 최적화하는 법

대규모 Unity 프로젝트에서 GPU Instancing과 SRP Batcher를 활용해 렌더링 성능을 극대화하고 CPU 부하를 획기적으로 줄이는 실전 최적화 전략을 알아봅니다.

대규모 게임 월드를 구축하거나 수많은 오브젝트를 동시에 렌더링해야 할 때, 성능 저하는 개발팀의 가장 큰 난관 중 하나입니다. 특히 복잡한 장면에서 발생하는 드로우 콜(Draw Call) 증가는 CPU에 막대한 부하를 주어 프레임 속도를 떨어뜨리고, 이는 곧 사용자 경험 저하로 이어집니다. 이러한 문제에 직면한 테크리드 및 엔지니어링 매니저님들께 Unity GPU Instancing과 SRP Batcher는 핵심적인 해결책을 제시합니다. 하지만 이 두 기술에 대한 몇 가지 널리 퍼진 오해들이 존재하며, 이를 명확히 이해하고 올바르게 적용하는 것이 팀의 기술적 역량과 프로젝트 성공에 결정적인 영향을 미칩니다.

지금부터 이 두 가지 강력한 최적화 기법에 대한 통념들을 바로잡고, 실제 프로젝트에 어떻게 적용하여 최대의 성능 효율을 이끌어낼 수 있는지 객관적인 관점에서 살펴보겠습니다.

📑 목차

• 오해 1: GPU Instancing은 단순히 같은 오브젝트 복제에만 유용하며, 복잡한 셰이더에는 적용하기 어렵다?
• GPU Instancing의 본질: 드로우 콜 감소와 유연한 속성 제어
• 오해 2: SRP Batcher는 URP/HDRP 전용 기능이며, 기존 Built-in 렌더 파이프라인 프로젝트에는 아무런 영향을 주지 않는다?
• SRP Batcher의 핵심: CPU 렌더링 오버헤드 감소
• 오해 3: GPU Instancing과 SRP Batcher는 상호 배타적이거나 단순한 중복 기능이다?
• 상호 보완적인 두 기술의 시너지 효과
• 최적화 전략 수립을 위한 조언

Image by birder62 on Pixabay

오해 1: GPU Instancing은 단순히 같은 오브젝트 복제에만 유용하며, 복잡한 셰이더에는 적용하기 어렵다?

많은 개발자들이 GPU Instancing을 단순히 동일한 나무, 돌멩이 같은 정적인 오브젝트를 대량으로 배치할 때만 효과적인 기술로 생각합니다. 또한, 복잡한 셰이더를 사용하거나 오브젝트별로 속성 변화가 필요할 경우 Instancing이 깨진다고 오해하기도 합니다. 그러나 이는 GPU Instancing의 진정한 잠재력을 간과하는 것입니다.

GPU Instancing의 본질: 드로우 콜 감소와 유연한 속성 제어

GPU Instancing의 핵심은 같은 메쉬(Mesh)와 같은 머티리얼(Material)을 사용하는 여러 오브젝트를 단 하나의 드로우 콜로 렌더링하여 CPU 부하를 획기적으로 줄이는 것입니다. 여기서 '같은 머티리얼'이라는 조건 때문에 오해가 생기기 쉽습니다. 하지만 Unity는 MaterialPropertyBlock 기능을 제공하여, 같은 머티리얼 인스턴스 내에서도 각 오브젝트별로 색상, 스케일, 텍스처 오프셋 등 다양한 속성을 다르게 적용할 수 있도록 지원합니다. 이는 셰이더 코드를 복잡하게 만들지 않으면서도 시각적 다양성을 확보할 수 있게 해줍니다.

예를 들어, 수천 개의 풀잎을 렌더링할 때 각 풀잎의 색상이나 흔들림 정도를 다르게 하고 싶다면, MaterialPropertyBlock을 통해 각 인스턴스별 데이터를 GPU에 전달할 수 있습니다. 이는 개발팀이 시각적 품질을 유지하면서도 드로우 콜을 효과적으로 관리할 수 있는 유연성을 제공합니다.

// C# 스크립트에서 MaterialPropertyBlock을 사용한 Instancing 예시
// 이 코드는 개념적인 설명이며, 실제 사용 시에는 오브젝트 관리 로직이 필요합니다.

public Mesh instancedMesh;
public Material instancedMaterial;
public int instanceCount = 10000;

private MaterialPropertyBlock propBlock;
private Matrix4x4[] matrices;
private Vector4[] colors;

void Start()
{
    propBlock = new MaterialPropertyBlock();
    matrices = new Matrix4x4[instanceCount];
    colors = new Vector4[instanceCount];

    for (int i = 0; i < instanceCount; i++)
    {
        // 각 인스턴스별 위치, 회전, 스케일 설정
        Vector3 position = new Vector3(Random.Range(-50f, 50f), 0, Random.Range(-50f, 50f));
        Quaternion rotation = Quaternion.Euler(0, Random.Range(0, 360), 0);
        Vector3 scale = Vector3.one * Random.Range(0.5f, 2.0f);
        matrices[i] = Matrix4x4.TRS(position, rotation, scale);

        // 각 인스턴스별 색상 설정 (랜덤)
        colors[i] = new Vector4(Random.value, Random.value, Random.value, 1.0f);
    }
}

void Update()
{
    // MaterialPropertyBlock에 색상 데이터 설정
    propBlock.SetVectorArray("_Color", colors); 
    
    // Instanced Material을 사용하여 메쉬 렌더링
    // 이 방식은 Unity의 내부 Batching에 의존하며, 더 정교한 제어는 CommandBuffer를 활용할 수 있습니다.
    Graphics.DrawMeshInstanced(instancedMesh, 0, instancedMaterial, matrices, matrices.Length, propBlock);
}

이처럼 MaterialPropertyBlock을 활용하면, 셰이더 내부에서 _Color와 같은 속성을 인스턴스별로 다르게 받아 처리할 수 있습니다. 결과적으로 GPU Instancing은 단순한 복제뿐만 아니라, 효율적인 방식으로 시각적 다양성을 확보하는 데 매우 강력한 도구로 활용될 수 있습니다.

장점	단점
드로우 콜 획기적 감소: CPU 부하를 크게 줄여 프레임 속도 개선.	메모리 오버헤드: 인스턴스별 데이터(위치, 색상 등)를 GPU에 전달하기 위한 메모리 필요.
유연한 속성 제어: MaterialPropertyBlock을 통해 인스턴스별 시각적 다양성 확보.	셰이더 수정 필요: Instancing을 지원하도록 셰이더를 수정해야 할 수 있음. (#pragma instancing_options)
GPU 효율성 증대: GPU가 한 번에 많은 기하학적 데이터를 처리하여 파이프라인 효율 개선.	제한된 인스턴스 수: 한 번의 드로우 콜로 처리할 수 있는 인스턴스 수에 제한이 있음 (일반적으로 1023개).

Image by Henning_W on Pixabay

오해 2: SRP Batcher는 URP/HDRP 전용 기능이며, 기존 Built-in 렌더 파이프라인 프로젝트에는 아무런 영향을 주지 않는다?

SRP Batcher는 Unity의 Scriptable Render Pipeline (SRP)과 함께 도입된 강력한 최적화 기능입니다. 이로 인해 많은 개발팀이 Built-in 렌더 파이프라인 프로젝트에서는 SRP Batcher의 이점을 전혀 누릴 수 없다고 생각합니다. 이는 부분적으로는 사실이지만, SRP Batcher의 본질적인 이점과 그로 인해 얻을 수 있는 CPU 렌더링 오버헤드 감소 효과를 간과하는 것입니다.

SRP Batcher의 핵심: CPU 렌더링 오버헤드 감소

SRP Batcher의 가장 큰 강점은 드로우 콜 수를 줄이는 것 이상으로, 드로우 콜당 CPU 처리 시간을 획기적으로 줄여주는 데 있습니다. 기존 렌더 파이프라인에서는 드로우 콜마다 CPU가 셰이더 및 머티리얼의 상수 데이터를 GPU로 전송하는 오버헤드가 발생했습니다. 하지만 SRP Batcher는 같은 셰이더 코드를 사용하는 다른 머티리얼 인스턴스들의 상수 데이터를 효율적으로 관리하고 GPU에 캐싱하여, 매 프레임마다 데이터를 다시 업로드하는 비효율을 제거합니다.

이는 URP나 HDRP와 같은 SRP 기반 프로젝트에서 수많은 오브젝트와 다양한 머티리얼을 사용할 때 CPU 렌더링 시간을 20~30% 이상 단축시키는 효과를 가져올 수 있습니다. Built-in 렌더 파이프라인 프로젝트의 경우 SRP Batcher를 직접 사용할 수는 없지만, 이러한 최적화 메커니즘을 이해하는 것은 SRP 전환의 전략적 가치를 평가하는 데 매우 중요합니다. 대규모 프로젝트에서 CPU 바운드 문제가 심각하다면, SRP로의 전환을 통해 얻을 수 있는 SRP Batcher의 이점은 기술 스택 변경의 충분한 명분이 될 수 있습니다.

Unity Profiler와 Frame Debugger를 활용하여 렌더링 파이프라인에서 발생하는 CPU 병목 현상을 분석하면, SRP Batcher가 제공하는 최적화 효과를 명확히 확인할 수 있습니다. 특히 "Render.OpaqueGeometry"나 "DrawCall.Render"와 같은 프로파일러 항목에서 CPU 시간이 비정상적으로 높게 나타난다면, SRP Batcher의 적용을 심도 있게 고려해볼 필요가 있습니다.

오해 3: GPU Instancing과 SRP Batcher는 상호 배타적이거나 단순한 중복 기능이다?

두 기술 모두 렌더링 성능 최적화를 목표로 하지만, 작동 방식과 최적화 대상이 다릅니다. 이로 인해 둘 중 하나만 선택해야 하거나, 한쪽이 다른 쪽의 기능을 완전히 대체한다고 오해하는 경우가 많습니다. 그러나 사실은 두 기술은 상호 보완적이며, 함께 적용했을 때 더 큰 시너지 효과를 발휘할 수 있습니다.

상호 보완적인 두 기술의 시너지 효과

GPU Instancing은 동일한 메쉬와 머티리얼을 사용하는 오브젝트들을 하나의 드로우 콜로 묶어 드로우 콜 수를 직접적으로 줄이는 데 특화되어 있습니다. 반면, SRP Batcher는 동일한 셰이더 코드를 사용하는 다른 머티리얼 인스턴스들의 CPU 렌더링 오버헤드를 최소화하는 데 중점을 둡니다. 즉, GPU Instancing이 '드로우 콜 자체'를 줄이는 데 기여한다면, SRP Batcher는 '각 드로우 콜의 CPU 처리 비용'을 줄이는 데 기여하는 것입니다.

실제 게임 개발 환경에서는 이 두 기술을 다음과 같이 활용하여 최대의 성능을 이끌어낼 수 있습니다:

• 수많은 나무, 풀, 바위 등 동일한 에셋을 반복적으로 사용하는 지형 오브젝트에는 GPU Instancing을 적용하여 드로우 콜 수를 최소화합니다.
• 다양한 캐릭터, 건물, UI 요소 등 서로 다른 메쉬와 머티리얼을 사용하지만 같은 셰이더 그래프나 셰이더 코드를 공유하는 오브젝트에는 SRP Batcher를 통해 CPU 렌더링 오버헤드를 줄입니다.
• 만약 Instancing이 적용된 오브젝트들이 사용하는 머티리얼이 SRP Batcher의 조건을 충족한다면 (즉, 같은 셰이더 코드를 사용한다면), GPU Instancing으로 줄어든 드로우 콜조차도 SRP Batcher의 효율적인 상수 데이터 관리의 혜택을 받게 되어 더욱 최적화된 성능을 기대할 수 있습니다.

특징	GPU Instancing	SRP Batcher	전통적인 Batching (Static/Dynamic)
주요 최적화 대상	드로우 콜 수 (동일 메쉬/머티리얼)	드로우 콜당 CPU 오버헤드 (동일 셰이더 코드)	드로우 콜 수 (병합 가능한 메쉬)
작동 방식	GPU가 한 번의 명령으로 여러 인스턴스 렌더링	CPU에서 셰이더 상수 데이터 관리 효율화 및 GPU 캐싱	CPU가 여러 메쉬를 하나의 메쉬로 병합하여 렌더링
적용 조건	동일 메쉬, 동일 머티리얼 (MaterialPropertyBlock으로 속성 변화 가능)	SRP 기반 프로젝트, 동일 셰이더 코드를 사용하는 머티리얼	오브젝트가 움직이지 않거나(Static), 작은 메쉬인 경우(Dynamic)
주요 이점	CPU 드로우 콜 처리 시간 대폭 감소, 프레임 속도 향상	CPU 렌더링 스레드 오버헤드 감소, 전체 CPU 사용량 절감	드로우 콜 수 감소 (Static), 일부 CPU 부하 감소 (Dynamic)
주의사항	인스턴스별 데이터 전송 메모리, 셰이더 지원 필수	SRP 전환 필요, 모든 셰이더에 적용되는 것은 아님	메모리 사용량 증가 (Static), CPU 부하 증가 가능 (Dynamic)

최적화 전략 수립을 위한 조언

테크리드 및 엔지니어링 매니저로서, 이러한 기술들을 팀에 적용할 때는 다음과 같은 관점을 고려해야 합니다:

1. 프로파일링을 통한 병목 현상 파악: Unity Profiler와 Frame Debugger를 사용하여 현재 프로젝트의 렌더링 병목 현상이 CPU 바운드인지, GPU 바운드인지, 또는 드로우 콜 수 때문인지를 정확히 진단해야 합니다.
2. 전략적 기술 선택: 진단 결과에 따라 GPU Instancing, SRP Batcher, 또는 이 둘의 조합 중 어떤 것이 가장 효과적인 해결책이 될지 판단합니다. Built-in 렌더 파이프라인이라면 SRP 전환 비용과 SRP Batcher의 이점을 비교 분석해야 합니다.
3. 지속적인 모니터링 및 튜닝: 기술 적용 후에도 성능 지표를 지속적으로 모니터링하고, 필요에 따라 셰이더 최적화, 메쉬 최적화 등 추가적인 튜닝을 진행해야 합니다.

Unity GPU Instancing과 SRP Batcher는 대규모 오브젝트 렌더링 시 발생하는 성능 문제를 해결하는 데 필수적인 도구입니다. 이들에 대한 정확한 이해와 전략적인 적용은 팀의 생산성을 높이고, 궁극적으로 사용자에게 더욱 몰입감 있는 게임 경험을 제공하는 데 기여할 것입니다. 단순히 드로우 콜을 줄이는 것을 넘어, 렌더링 파이프라인의 깊은 곳에서 CPU와 GPU의 효율성을 극대화하는 방법을 모색해야 합니다.

여러분의 프로젝트에서는 이 두 기술을 어떻게 활용하고 계신가요? 또는 어떤 난관에 부딪히셨는지 댓글로 경험을 공유해 주세요!

📌 함께 읽으면 좋은 글

• [게임 개발] 게임 캐릭터 애니메이션, 렌더링 성능 20% 향상 비밀: 스켈레톤 vs 프로시저럴 현명한 선택법
• [게임 개발] 게임 핵 방지, 클라이언트와 서버 검증 중 어떤 솔루션을 선택해야 할까?
• [게임 개발] 인디 게임 출시 전, 스팀 상점 페이지 최적화에 실패하는 치명적인 이유

이 글이 도움이 되셨다면 공감(♥)과 댓글로 응원해 주세요!
궁금한 점이나 다루었으면 하는 주제가 있다면 댓글로 남겨주세요.