Custom 게임 엔진 렌더링 파이프라인 구현

렌더링 파이프라인

렌더링 파이프라인이라는 단어, 게임 개발자라면 한 번쯤 들어봤을 법한 용어다. 하지만 실제로 그것을 직접 짜본 사람은 많지 않다. 단순히 GPU에 메시와 텍스처를 넘겨주는 절차? 아니다. 그것만으로는 본질을 전혀 설명하지 못한다. 왜냐하면 이 시스템은 단지 화면에 뭔가를 띄우는 것이 아니라, ‘시각적 현실성의 통합 표현’을 담당하는 핵심 메커니즘이기 때문이다. 이걸 구현한다는 건 결국, 시간 흐름 안에서 세계를 조작하고 그 결과를 정확하게 시각적으로 피드백하는 흐름 전체를 설계한다는 뜻이다.

렌더링의 핵심 구성요소

렌더링이란 단어 자체가 가진 추상성이 문제다. 그렇다면 구체적으로 쪼개서 생각해보자. 무엇이 진짜 핵심일까? 카메라 매트릭스? 조명 계산? 셰이더 호출? 각각은 단지 한 조각일 뿐이다. 전체 구조에서 핵심은 결국 ‘상태의 조합’이다. 프레임마다 상태를 설정하고 그에 맞는 드로우 호출을 발생시키는 일련의 상태 머신으로 이해할 필요가 있다.

GPU 상태 전이와 스테이트 객체

GPU는 내부적으로 상태 변경에 민감하게 반응한다. 예를 들어 Direct3D12에서는 PSO(Pipeline State Object)를 통해, OpenGL에서는 쉐이더 프로그램과 바인딩 포인트를 통해 이를 처리한다. 단순한 드로우 호출이더라도, 동일한 메시를 다른 머티리얼로 렌더링한다면, 각각의 상태 셋이 다르게 구성돼야 한다. 이것이 렌더링 파이프라인 구현에서 가장 먼저 고려해야 할 구조적 축이다.

불변 상태 캐싱 전략

상태 변경 비용을 줄이기 위해 가장 많이 사용되는 방법 중 하나는 ‘불변 상태 묶음’을 캐싱하는 방식이다. 예를 들어 머티리얼 + 셰이더 + 블렌딩 모드 + 렌더타겟 구성 등을 하나의 불변 묶음으로 추상화하고, 동일한 구성일 경우 이를 재활용하는 방식이다. Unreal Engine과 같은 대형 엔진들도 이 전략을 채택하고 있으며, PSO의 재활용 여부는 퍼포먼스에 직결된다 (Epic Games, Rendering Optimization Talk, 2021).

동적 상태 전이 최소화

반면 동적으로 변하는 값들 — 예를 들어 라이팅 파라미터, 카메라 위치, 애니메이션 매트릭스 등은 매 프레임 갱신되어야 한다. 이때 중요한 건 상태를 무작위로 변경하지 말고, ‘변경 흐름을 최소화하는 순서’로 렌더 큐를 구성하는 전략이다. 흔히 이것을 Sort-Key 기반의 렌더큐 최적화라고 한다.

렌더 패스의 계층 구조

렌더링 파이프라인은 단일 단계가 아니라, 여러 개의 렌더 패스(Render Pass)로 구성된 계층 구조를 가진다. 예를 들어 그림자를 먼저 렌더링한 후, G-Buffer를 채우고, 조명을 계산하고, 후처리 효과를 적용하는 일련의 과정이 하나의 파이프라인으로 통합되어야 한다.

Shadow Pass의 위치와 역할

그림자는 시각적 리얼리즘에서 빠질 수 없는 요소다. 특히 Directional Light의 경우, Cascaded Shadow Map(CSM) 기법을 사용하면 멀리 있는 그림자와 가까운 그림자를 동시에 고려할 수 있다. 여기서 중요한 점은, Shadow Pass는 실제 화면에 렌더링되지 않지만, 후속 조명 계산에 필수적인 깊이 정보를 생성한다는 점이다. 다시 말해, 이는 시각적으로는 보이지 않지만 논리적으로는 가장 먼저 실행되어야 하는 ‘숨은 시작점’이다.

G-Buffer와 Deferred Rendering

디퍼드 렌더링(Deferred Rendering)은 G-Buffer라는 중간 버퍼에 정보(노멀, 알베도, 깊이 등)를 분리 저장한 뒤, 라이트 패스에서 이를 조합해 최종 색상을 만들어낸다. 이 방식은 수많은 광원을 처리하는 데 매우 효율적이다. 하지만 반대로, 반투명 객체나 포워드 렌더링 방식과는 충돌이 생기기 때문에, G-Buffer 패스와 별도로 포워드 패스를 설계하는 하이브리드 접근이 필요하다 (NVIDIA, Deferred vs Forward Rendering Whitepaper, 2020).

실제 파이프라인 설계 시 고려사항

그냥 이론만 나열하면 쉽게 들릴 수 있다. 하지만 현실은 훨씬 복잡하다. 프레임마다 렌더링할 객체 수가 수백에서 수천에 이르고, 서로 다른 셰이더, 머티리얼, 라이트가 혼재한다. 이 모든 것을 효율적으로 처리하려면, 파이프라인은 단순히 ‘순서의 집합’이 아니라 ‘의사결정 체계’여야 한다.

객체 정렬과 Batching 전략

가장 단순한 최적화는 객체 정렬이다. 동일한 머티리얼을 가진 객체끼리 묶어 렌더링 순서를 정렬하면 드로우 콜 수를 줄일 수 있다. 그러나 여기서 중요한 건 단순 정렬이 아니라 ‘Batching 기준’을 명확하게 정하는 것이다. Draw Call을 줄이기 위한 Instancing 적용 여부, 머티리얼의 Dynamic 유무에 따라 기준이 바뀌기 때문이다.

인스턴싱과 머티리얼 다형성

GPU Instancing은 동일한 메시를 반복적으로 렌더링할 때 매우 유효하다. 하지만 만약 머티리얼이 각각 다르다면? 이때는 GPU에서 머티리얼 파라미터를 배열로 전달하거나, 머티리얼 ID를 통해 분기 처리하는 방식이 필요하다. 즉, 물리적으로는 같은 메시지만, 시각적으로는 다른 표현을 가능하게 해야 진정한 파이프라인 유연성이 확보된다.

Depth Pre-Pass 여부 결정

Depth Pre-Pass는 Z-Buffer를 미리 채워 과도한 픽셀 셰이딩을 줄이는 기법이다. 하지만 너무 일괄적으로 적용하면 GPU 리소스 낭비가 생길 수 있다. 이 판단 기준은 화면 전체 중 ‘오버드로우 비율’과 셰이더 복잡도에 달려 있다. 예를 들어, 복잡한 셰이더를 사용하는 씬에서 Overdraw가 30% 이상이면 Depth Pre-Pass가 효과를 발휘한다 (Intel, Real-Time Rendering Techniques, 2019).

결론

커스텀 게임 엔진의 렌더링 파이프라인을 직접 구현한다는 것은 단순히 셰이더를 호출하고 화면에 물체를 그리는 기능을 만드는 작업이 아니었다. 프레임마다 변화하는 세계의 상태를 수집하고, GPU의 상태 전이를 관리하며, 렌더 패스 간의 의존성을 조율하고, 퍼포먼스를 극대화하기 위해 데이터 흐름을 재구성하는 지적 도전의 연속이었다. 설계가 유기적으로 얽혀 있다는 사실을 깨닫는 순간, 파이프라인은 더 이상 기술 요소의 집합이 아니라 하나의 살아있는 시스템으로 보였다. 그 과정에서 내가 가장 크게 배운 점은, 진짜 문제는 기술 자체가 아니라 ‘의사결정의 순서’라는 사실이었다. 렌더링은 결국 최적의 결정을 쌓아올리는 예술이다. 그래서 실패와 실험이 당연히 필요했고, 실제로 매번 디버깅할 때마다 예상치 못한 병목을 발견하면서 스스로의 시야가 한 단계씩 확장되었다. 만약 지금 이 글을 읽고 있는 누군가가 커스텀 렌더링 파이프라인을 만들고자 한다면, 가장 먼저 구조와 흐름을 바라보는 시선을 갖추라고 이야기해주고 싶다. 거기서부터 모든 가능성이 열린다.

FAQ

렌더링 파이프라인 설계는 처음부터 디퍼드 렌더링으로 가는 것이 좋을까?

처음부터 디퍼드 렌더링을 선택하는 것이 반드시 정답은 아니다. 디퍼드는 많은 광원 처리에 강력하지만 반투명 객체 처리나 메모리 사용량 측면에서 부담이 크다. 작은 규모의 프로젝트라면 포워드 렌더링으로 시작하고, 필요할 때 하이브리드로 확장하는 접근이 더 현실적이다.

G-Buffer를 구성할 때 반드시 포함해야 하는 정보는 무엇인가?

노멀, 알베도, 깊이, 월드포지션 정보는 일반적으로 필수다. 하지만 모든 프로젝트가 동일한 구성을 필요로 하지는 않는다. 조명 모델과 후처리 요구사항에 따라 가변적으로 설계할 수 있으며, 실제로 엔진 제작자들은 메모리 트레이드오프를 고려해 조정한다 (NVIDIA G-Buffer Architecture Report, 2020).

Depth Pre-Pass는 언제 적용하는 것이 좋은가?

픽셀 셰이더가 무겁고 오버드로우가 많은 씬에서 매우 유효하다. 반대로 각 오브젝트의 셰이더가 단순하고 화면의 대부분이 하늘이나 배경이면 오히려 손해가 된다. 결국 통계 기반의 결정을 내려야 한다는 뜻이다.

렌더 큐 정렬 기준은 어떻게 정하는 것이 좋을까?

일반적으로 상태 변경 비용이 큰 요소를 우선 기준으로 삼아 정렬한다. 예를 들어 셰이더 프로그램 > 머티리얼 > 텍스처 > 메시 순서로 묶는 방식이 흔히 사용된다. 하지만 엔진 구조와 타겟 플랫폼에 따라 최적해는 다를 수 있다.

PSO(Pipeline State Object) 캐싱이 성능에 얼마나 중요한가?

Direct3D12나 Vulkan 같은 API에서는 PSO 재생성이 매우 비싸다. 대형 프로젝트에서는 PSO 캐싱이 수십 밀리초 단위로 성능 차이를 만들기도 한다. 그래서 PSO를 불변 상태 묶음으로 취급하고 사전에 생성 또는 캐싱하는 전략이 실질적인 성능의 핵심이다.

Instancing과 Batching은 반드시 적용해야 하는가?

렌더링 파이프라인의 효율을 위해 거의 필수적인 요소다. 특히 같은 메시가 반복적으로 등장하는 환경에서는 GPU Instancing이 드로우 콜을 획기적으로 줄여준다. 단, 머티리얼 파라미터 차이를 처리할 전략이 함께 갖춰져야 한다.

그림자 렌더링은 왜 가장 먼저 처리해야 하는가?

그림자 패스는 후속 조명 계산의 입력 데이터로 사용된다. 즉, 그림자 깊이 정보가 있어야 조명이 올바르게 계산되므로 Shadow Pass는 시각적으로 보이지 않아도 논리적 파이프라인의 시작점이 된다.

포스트 프로세싱의 순서는 왜 중요한가?

효과의 순서가 현실감을 결정한다. 예를 들어 블룸과 HDR 톤 매핑의 순서가 바뀌면 결과가 완전히 달라진다. 파이프라인의 후반부는 단순히 시각적 장식이 아니라 화면 전체의 감정적 톤을 결정하는 영역이다.

커스텀 렌더링 파이프라인을 만들 때 가장 중요한 마음가짐은?

완벽한 정답은 없다는 점을 먼저 받아들이는 것이다. 파이프라인은 끊임없는 시행착오의 산물로 완성된다. 실제 현업 엔진 개발자도 실험과 실패를 반복하며 개선해 나간다. 조급해하지 말고, 변화에 열려 있는 태도가 더 중요하다.

직접 엔진을 만들면서 가장 어려웠던 점은 무엇이었는가?

기술보다 의사결정의 문제였다. 무엇을 제거하고 무엇을 남길지 판단하는 과정이 가장 힘들었다. 특히 처음에는 모든 기능을 다 넣고 싶었지만, 결국 가장 큰 최적화는 삭제와 단순화에서 찾아지는 경험을 하게 되었다.