Forward Rendering의 원리와 한계
Forward Rendering은 어떤 방식인가?
Forward Rendering은 3D 렌더링에서 가장 기본적이고 직관적인 방식으로, 모든 물체를 하나씩 화면에 그리면서 조명을 바로 적용합니다. 말 그대로 ‘앞으로 뿌리는’ 방식이죠. 객체 하나를 그릴 때마다 모든 라이트를 순차적으로 검사하고 계산합니다.
연산 흐름의 단순성
이 방식의 장점은 단연코 구조의 간단함입니다. 특별한 버퍼 설정 없이 곧바로 화면에 렌더링되는 만큼, 셰이더 코드도 비교적 단순하게 유지할 수 있고 디버깅도 수월합니다. 게임 초기 버전이나 모바일 게임에서 이 방식을 많이 사용하는 이유도 여기에 있죠.
낮은 메모리 사용량
Deferred 방식과 달리, 추가적인 G-Buffer를 생성하지 않기 때문에 GPU 메모리 소비량이 낮습니다. 즉, 하드웨어가 제한적인 환경에서도 활용 가능성이 높습니다.
그런데 왜 Forward는 이제 구식이 되었을까?
라이트 수의 폭발적 증가에 대응 불가
문제는 ‘모든 물체에 모든 라이트를 계산’한다는 점입니다. 만약 1,000개의 객체와 50개의 라이트가 있다면, 최대 50,000번의 라이트 셰이딩이 발생하는 셈입니다. 그 중 대부분은 실제로 화면에 영향을 주지 않는데도 불구하고 말이죠.
투명도 문제
또 하나의 단점은 투명 오브젝트 처리입니다. Forward Rendering에서는 투명 객체를 올바르게 렌더링하려면 z-buffer 정렬을 수동으로 해야 하는데, 동적 씬에서는 이게 거의 불가능에 가깝습니다. 결과적으로 화면이 깨지거나, 이상하게 렌더링되는 문제가 자주 발생합니다.
사용자 경험에서의 체감 문제
직접 Unity에서 Forward Rendering으로 라이팅된 복잡한 실내 맵을 테스트해봤을 때, 그림자가 엉망이고 라이트 수만 조금 늘려도 FPS가 급격히 떨어졌습니다. 제 경우에는 단 12개의 포인트 라이트만 추가했을 뿐인데, 프레임이 절반 이하로 줄어들더군요.
Custom 게임 엔진 렌더링 파이프라인 구현 👆Deferred Shading의 구조와 강점
Deferred는 무엇을 ‘연기’하는가?
Deferred Shading의 ‘연기’란 조명 계산을 나중으로 미룬다는 뜻입니다. 처음에는 각 픽셀의 정보(색상, 노멀, 깊이 등)를 여러 개의 G-Buffer에 저장합니다. 그 다음 프레임 후반에 한 번에 조명을 계산합니다.
G-Buffer란 무엇인가?
G-Buffer는 Geometry Buffer의 줄임말로, 각각의 픽셀에 대한 정보를 따로 저장해두는 버퍼입니다. 예를 들어, 화면 전체 픽셀의 월드 노멀을 저장한 텍스처, 알베도 색상을 저장한 텍스처 등 여러 버퍼로 나뉘죠.
빛과 그림자의 자유도 증가
Deferred Shading에서는 각 픽셀이 어떤 조명의 영향을 받는지를 화면 전체 기준으로 계산하므로, 수십에서 수백 개의 조명이 존재해도 시스템이 버티는 이유가 여기에 있습니다. Epic Games는 Unreal Engine 4에서 Deferred Shading을 채택한 이유로 “대규모 조명 처리에 최적화된 구조”를 들었습니다 (Epic Games, UE4 Architecture, 2016).
어떤 문제점도 여전히 존재한다
투명도와의 충돌
Deferred 방식은 투명 오브젝트와 궁합이 나쁩니다. G-Buffer는 오직 하나의 픽셀 정보만 저장할 수 있기 때문에 반투명 효과나 유리 재질의 표현이 어렵습니다.
Anti-Aliasing 문제
Deferred는 MSAA(Multisample Anti-Aliasing)를 직접 사용할 수 없습니다. 대신 FXAA나 TAA 같은 후처리 기반의 Anti-Aliasing을 써야 하는데, 이건 선명도를 떨어뜨리는 경우가 많습니다.
고사양 GPU 필요성
많은 버퍼와 복잡한 후처리 과정 때문에 GPU 메모리를 더 많이 사용합니다. 따라서 엔트리급 시스템에서는 성능 저하를 피하기 어렵습니다. 실제로 Frostbite 엔진이 채택한 Deferred 렌더링 방식은 30% 이상의 VRAM 사용량 증가를 보였다는 결과도 있습니다 (EA DICE, 2014).
Job System의 실전 적용 사례 분석 👆Tiled Forward Rendering의 절충안 접근
기본 원리는 무엇인가?
Tiled Forward는 말 그대로 화면을 타일처럼 잘게 쪼개고, 각 타일별로 해당 영역에 영향을 미치는 조명만 적용하는 방식입니다. Forward와 Deferred의 중간 성격을 가진 하이브리드 렌더링이죠.
타일링 구조의 장점
타일 크기는 보통 16×16 픽셀이며, 해당 타일 안에 어떤 라이트가 있는지 빠르게 판별하여 불필요한 연산을 줄입니다. 덕분에 모바일 환경이나 VR 기기에서도 꽤 괜찮은 성능을 보입니다.
Unity 엔진의 적용 사례
Unity는 5.6 버전부터 Tiled Forward Rendering을 도입했습니다. 개발자들은 수십 개의 라이트를 동시에 띄우면서도 GPU 부하를 낮출 수 있다는 점에서 큰 이점을 체감했습니다. 제 경험으로는 모바일 AR 앱 개발 당시 Tiled Forward가 진정한 해답이 되어줬죠.
기술적 트레이드오프
복잡한 조명 구성에선 제한적
라이트 수가 수백 개 이상 넘어가면, 타일마다 고려해야 할 조명 수가 폭증하면서 오히려 퍼포먼스가 저하될 수 있습니다. 복잡한 광원 구조에선 Clustered가 더 낫다는 평가도 많습니다.
깊이 기반 최적화 부족
타일링은 2D 화면 기준이라 깊이 정보를 활용하지 않습니다. 이 때문에 동일한 타일 안에 위치해도 z축 방향으로 분리된 물체들을 구분할 수 없다는 한계가 있습니다.
멀티스레드 게임 루프 설계 및 병렬 처리 👆Clustered Lighting: 진화된 3D 기반 접근
Clustered는 왜 혁신적인가?
Clustered Rendering은 기존 타일 방식에서 한 발 더 나아가, z축까지 포함해 3차원 공간 전체를 클러스터 단위로 나눕니다. 결과적으로 각 클러스터에 영향을 주는 라이트를 더욱 정밀하게 계산할 수 있습니다.
깊이 기반 클러스터링의 강점
깊이 정보를 활용해 같은 화면 영역이라도 z값에 따라 다른 클러스터로 나누기 때문에, 입체적인 조명 계산이 가능합니다. 예를 들어, 높은 빌딩 안과 바깥쪽을 같은 타일로 보던 Tiled 방식과 달리, Clustered는 각기 다른 클러스터로 분리해 처리할 수 있습니다.
SIGGRAPH 논문 기반의 구조
2012년 SIGGRAPH에 발표된 Olsson 외 연구팀의 논문에서는 Clustered Rendering이 기존 Tiled 방식보다 대규모 씬에서 4~6배의 성능 향상을 보인다고 언급했습니다 (Olsson et al., SIGGRAPH 2012).
실제 사용 사례에서의 경험
저는 WebGPU 기반의 개인 엔진 테스트에서 Clustered 방식으로 500개 이상의 동적 광원을 처리해봤습니다. Forward나 Tiled에서는 30FPS도 유지하기 힘들던 씬이, Clustered에서는 50FPS 이상으로 유지됐죠. 특히 라이트들이 z축으로 흩어져 있는 경우, 성능 차이는 훨씬 더 극명했습니다.
개발 도구 내장화
Unreal Engine과 Godot 4, 최신 Unity 엔진은 이제 기본적으로 Clustered 기술을 적용하고 있습니다. 대형 씬이나 실시간 글로벌 일루미네이션을 다루는 프로젝트에선 필수적인 기술로 자리 잡고 있습니다.
Unity DOTS, Bevy ECS, Flecs 메모리 친화적 구조 설계 👆결론
지금까지 살펴본 Forward+, Deferred Shading, Tiled Rendering, Clustered Lighting은 단순한 그래픽 기법의 차이를 넘어서, 각각의 철학과 기술적 접근 방식이 고유하게 반영된 렌더링 전략이다. 과거의 간단한 장면에서는 Forward Rendering이 모든 것을 감당할 수 있었지만, 수십 개의 조명, 복잡한 반사 효과, 깊이 기반 최적화가 요구되는 현재의 3D 환경에서는 분명 한계가 드러난다.
Deferred Shading은 대규모 조명을 다룰 수 있다는 점에서 확실히 우위를 가지지만, 그만큼 높은 메모리 사용과 투명도 처리의 어려움이라는 단점도 분명 존재한다. 이에 대한 대안으로 등장한 Tiled Forward는 성능과 품질 사이에서 균형을 추구하며 모바일 및 VR 환경에서 강점을 보인다. 그리고 가장 진보된 형태인 Clustered Lighting은 깊이까지 고려한 클러스터링으로 극도로 복잡한 씬에서도 퍼포먼스를 확보하는 혁신적인 접근이라 할 수 있다.
결국 어떤 기술이 ‘더 낫다’고 단정짓기보다는, 프로젝트의 성격, 목표 플랫폼, 표현하고자 하는 조명의 복잡도에 따라 최적의 방법을 선택하는 것이 핵심이다. 렌더링 기술의 세계는 끊임없이 진화 중이다. 지금 이 순간에도, 개발자와 연구자들은 더 빠르고 아름다운 화면을 만들기 위해 다음 단계를 설계하고 있을 것이다.
Entity-Component-System (ECS) 아키텍처 설계 및 최적화 👆FAQ
Forward Rendering은 여전히 유효한가요?
예, 단순한 씬이나 모바일 게임, 하드웨어 자원이 제한된 환경에서는 여전히 매우 유효합니다. 특히 조명이 많지 않고 투명 오브젝트가 적은 경우에는 간단한 구조 덕분에 디버깅이나 구현 속도 면에서 유리합니다.
Deferred Shading을 사용할 때 가장 큰 장점은 무엇인가요?
가장 큰 장점은 다수의 동적 라이트를 효율적으로 처리할 수 있다는 점입니다. G-Buffer를 기반으로 모든 라이트를 화면 전체 기준으로 연산하기 때문에, 50개 이상의 조명도 실시간으로 계산 가능해집니다.
Tiled Forward Rendering은 언제 쓰는 게 좋은가요?
조명이 꽤 많지만, 여전히 투명 오브젝트 처리나 MSAA 같은 기능이 중요한 경우 좋습니다. VR, AR, 모바일 앱 등에서 Forward의 장점과 Deferred의 성능을 절충하고 싶을 때 적합합니다.
Clustered Lighting은 모든 경우에 더 나은가요?
아닙니다. 구조가 복잡하고, 클러스터 관리를 위한 연산이 추가되기 때문에 단순한 씬에는 오히려 과한 선택일 수 있습니다. 대신 깊이 축이 많은 복잡한 씬에선 확실한 퍼포먼스 향상을 기대할 수 있습니다.
Tiled과 Clustered는 어떤 점이 가장 다른가요?
Tiled는 화면을 2D 타일로만 나누지만, Clustered는 여기에 깊이(z축)를 포함해 3D 클러스터로 나눕니다. 즉, 같은 화면 위치라도 거리 차이에 따라 조명 영향을 다르게 줄 수 있다는 점이 큰 차이입니다.
투명한 재질은 어떤 기법에서 잘 처리되나요?
전통적인 Forward Rendering이 투명 재질 처리에는 가장 적합합니다. Deferred에서는 투명도를 G-Buffer에 표현할 수 없기 때문에 별도 패스로 처리하거나 Forward Pass를 추가해야 합니다.
모든 기술을 하나의 프로젝트에 혼합해서 사용할 수 있나요?
일부 엔진에서는 가능합니다. 예를 들어 Unity는 일부 오브젝트만 Forward로 처리하고, 나머지는 Deferred로 처리하는 하이브리드 방식을 지원합니다. 하지만 구현이 복잡해질 수 있으므로 주의가 필요합니다.
이 기술들은 어떤 엔진에서 쓸 수 있나요?
Unreal Engine은 기본적으로 Deferred 기반이며, Clustered 지원도 내장되어 있습니다. Unity는 Forward, Deferred, Tiled Forward, URP/HDRP에 따라 선택 가능합니다. Godot 4는 Forward+와 Clustered Lighting을 지원합니다.
모바일 게임에도 Clustered Rendering이 적용되나요?
최근 일부 고성능 모바일 칩셋에서는 가능해졌지만, 여전히 제한적인 경우가 많습니다. 일반적으로는 Tiled Forward 방식이 모바일에서 더 적합합니다.
이 기술들을 스스로 구현할 수 있나요?
가능은 하지만, 그래픽스 API(OpenGL, Vulkan, WebGPU 등)에 대한 이해와 셰이더 프로그래밍, 수학 지식이 필요합니다. SIGGRAPH 논문이나 공식 엔진 소스코드를 참고하면 큰 도움이 됩니다. 연습과 실험이 가장 좋은 선생님입니다.
LiveOps 시스템 구축 (A/B 테스트, 원격 설정, 클라우드 통계 기반 핫패치) 👆