두 방식 모두 드로우콜을 줄이는 최적화 기법인데, 접근 방식이 근본적으로 다릅니다.
Static Batching
CPU가 빌드/씬 로드 시점에 여러 메시를 하나의 거대한 메시로 합쳐버립니다.
- 같은 머티리얼을 쓰는 오브젝트들을 미리 병합
- 런타임에 추가 연산 없이 한 번에 드로우콜 발생
- 단점: 합쳐진 메시 데이터를 메모리에 별도 저장 → 메모리 사용량 증가
- 단점: Static으로 마킹된 오브젝트만 가능 (움직이면 안 됨)
- 같은 메시를 100개 쓰면 → 버텍스 데이터도 100배로 메모리에 저장됨
GPU Instancing
GPU에게 "이 메시를 이 위치들에 여러 번 그려라"고 명령을 한 번만 보냅니다.
- 메시 데이터는 GPU 메모리에 딱 1개만 존재
- 위치/회전/스케일/색상 등의 per-instance 데이터만 배열로 전달
- 장점: 메모리 효율적 (같은 메시 반복 사용 시 특히 강력)
- 단점: 런타임에 인스턴스 데이터 갱신 비용 존재
- 오브젝트가 움직여도 됨
핵심 차이 정리
| Static Batching | GPU Instancing | |
|---|---|---|
| 병합 시점 | 빌드/로드 타임 | 런타임 |
| 메모리 | 많이 사용 | 효율적 |
| 이동 가능 여부 | ❌ | ✅ |
| 최적 상황 | 다양한 메시, 움직이지 않는 배경 | 같은 메시 대량 반복 (나무, 돌, 적 유닛 등) |
| 머티리얼 조건 | 같은 머티리얼 | 같은 머티리얼 + 같은 메시 |
실무 판단 기준:
- 숲의 나무 1000그루 → GPU Instancing (같은 메시 반복)
- 도시 건물, 지형 오브젝트 (각각 다른 메시) → Static Batching
- 파티클 시스템은 내부적으로 GPU Instancing 사용
Static Batching - CPU, 빌드/로드 타임
메시 병합 연산을 미리 해놓고 결과를 저장해두기 때문에 런타임 CPU 부담은 거의 없습니다.
Dynamic Batching - CPU, 매 프레임 런타임
매 프레임마다 CPU가 배칭 가능한 오브젝트를 찾고, 버텍스를 합쳐서 하나의 드로우콜로 만드는 연산을 실시간으로 수행합니다. 그래서 오브젝트 수가 많아지면 오히려 CPU 부담이 커져서 역효과가 날 수 있습니다.
GPU Instancing - GPU
CPU는 인스턴스 데이터(위치, 회전 등) 배열만 전달하고, 실제 반복 렌더링은 GPU가 처리합니다. 그래서 대량 반복 오브젝트에서 세 방식 중 가장 효율적입니다.
GPU는 "주어진 데이터를 렌더링"하는 역할이고, 무엇을 묶어서 보낼지 판단하고 준비하는 건 CPU입니다.
흐름을 보면:
- CPU가 매 프레임 씬을 순회하며 배칭 가능한 오브젝트 탐색
- CPU가 해당 오브젝트들의 버텍스 데이터를 하나의 버퍼로 합침
- CPU가 GPU에 드로우콜 한 번 전송
- GPU는 받은 버퍼를 렌더링
즉 GPU는 "합쳐진 결과물"만 받아서 그리는 것이고, 합치는 작업 자체는 CPU가 하는 겁니다. Dynamic Batching의 부담이 CPU에 있는 이유가 이겁니다.
GPU Instancing이 효율적인 이유도 여기서 나옵니다. CPU는 인스턴스 목록만 넘기고 합치는 작업을 안 하기 때문에 CPU 부담이 훨씬 적습니다.
- Static Batching → 빌드 타임(또는 씬 로드 타임)에 Unity 에디터/엔진이 CPU로 미리 병합해서 결과물을 저장해둠
- Dynamic Batching → 런타임 매 프레임마다 CPU가 병합
그래서 Static Batching은 런타임 CPU 부담이 없는 겁니다. 이미 다 합쳐진 상태로 GPU에 넘기기만 하면 되니까요. 대신 그 병합된 메시 데이터를 메모리에 계속 들고 있어야 해서 메모리 비용이 발생하는 거고요.
