들어가며

최근 Unity 렌더링 구조를 보면 자주 등장하는 키워드 중 하나가 바로 RenderGraph입니다.

특히 Unity 6 이후부터는 URP/HDRP 내부 구조에서도 RenderGraph 기반 흐름이 점점 강조되고 있습니다.

그런데 처음 RenderGraph를 접하면 이런 생각이 들기도 합니다.

“기존에도 렌더링은 잘 되고 있었는데, 굳이 왜 RenderGraph 같은 구조가 필요한 걸까?”

이번 글에서는

• 기존 렌더링 구조의 한계
• RenderGraph가 등장한 이유
• Unity 6에서 무엇이 달라졌는지
• 왜 현대 엔진들이 Graph 기반 구조로 이동하는지

를 중심으로 정리해보겠습니다.

---

기존 렌더링 구조의 문제

예전 렌더링 구조는 대체로 다음과 같은 방식으로 동작했습니다.

Pass A 실행
↓
Texture 생성
↓
Pass B 실행
↓
Texture 전달
↓
Pass C 실행

즉, 렌더링 패스를 순차적으로 직접 관리하는 방식입니다.

처음에는 단순하고 이해하기 쉽습니다.

하지만 렌더링 규모가 커질수록 문제가 발생하기 시작합니다.

---

🎯 렌더링 패스가 많아질수록 복잡해진다

현대 렌더링에서는 생각보다 훨씬 많은 패스가 존재합니다.

• Shadow Pass
• Depth Pass
• GBuffer Pass
• Lighting Pass
• Post Processing
• Bloom
• TAA
• SSAO

그리고 각 패스들은 서로 데이터를 주고받게 됩니다.

이 패스가 어떤 Texture를 사용하고, 누가 생성했고, 언제 해제되는가? 같은 관리 문제가 매우 복잡해지기 시작합니다.

---

🧠 특히 GPU 메모리 관리가 어려워진다

렌더링 패스가 늘어나면 Render Texture 사용량도 크게 증가합니다.

문제는 GPU 메모리는 생각보다 매우 비싼 자원이라는 점입니다.

• 4K Render Target
• HDR Buffer
• Depth Buffer
• GBuffer

등은 상당한 메모리를 사용합니다.

즉, 불필요한 Texture 생성과 유지 자체가 성능 문제로 이어질 수 있습니다.

---

🎮 기존 방식의 한계

기존 구조에서는 개발자가 직접 리소스를 관리하는 경우가 많았습니다.

예

CreateRenderTexture();
ExecutePass();
ReleaseRenderTexture();

이런 식입니다.

문제는 패스가 복잡해질수록 여러 문제가 발생한다는 점입니다.

• 리소스 재사용 어려움
• 불필요한 메모리 유지
• GPU 동기화 문제
• 렌더링 순서 의존성 증가

---

그래서 등장한 것이 RenderGraph

RenderGraph의 핵심 아이디어는 생각보다 단순합니다.

“렌더링 패스들의 관계를 그래프 형태로 관리하자”

즉:
단순히 순서대로 실행하는 것이 아니라,
패스 간 의존성을 구조적으로 관리하기 시작한 것입니다.

---

Graph라는 이름의 의미

RenderGraph에서 Graph는 수학적인 그래프 구조 개념에 가깝습니다.

• 노드(Node) → Render Pass
• 간선(Edge) → 리소스 의존성

형태입니다.

예를 들면, 아래와 같이 어떤 패스가 어떤 데이터를 사용하는지 연결됩니다.

Shadow Pass
↓
Lighting Pass
↓
Post Processing

---

RenderGraph의 핵심 장점

RenderGraph의 가장 큰 장점은 엔진이 전체 렌더링 흐름을 이해할 수 있게 되었다는 점입니다.

이게 굉장히 중요합니다.

왜냐하면 전체 흐름을 이해하면 엔진이 자동 최적화를 수행할 수 있기 때문입니다.

---

자동 리소스 관리

대표적인 장점이 바로 리소스 생명주기 관리입니다.

예전에는 개발자가 직접 Texture 생성/해제를 관리했습니다.

하지만 RenderGraph에서는 엔진이 사용 시점을 분석합니다.

• 언제 생성할지
• 언제 재사용할지
• 언제 해제할지

를 자동으로 판단할 수 있게 됩니다.

---

리소스 재사용 최적화

예를 들어, 두 Render Pass가 동시에 Texture를 사용하지 않는다면 같은 메모리 영역 재사용 가능합니다.

즉, GPU 메모리 사용량을 줄일 수 있습니다.

현대 렌더링에서 이 차이는 상당히 큽니다.

• 모바일
• 콘솔
• VR

환경에서는 특히 매우 중요합니다.

---

불필요한 Pass 제거

RenderGraph는 패스 의존성도 분석할 수 있습니다.

즉, 최종 결과에 사용되지 않는 패스를 자동 제거할 수 있습니다.

출력에 사용되지 않음
↓
Pass 실행 생략

이 역시 기존 방식에서는 구현이 꽤 어려운 최적화였습니다.

---

GPU 동기화 최적화

현대 GPU는 병렬 작업을 굉장히 많이 수행합니다.

문제는 잘못된 동기화가 발생하면 GPU가 기다리게 된다는 점입니다.

따라서 GPU Pipeline Stall이 발생할 수 있습니다.

RenderGraph는 리소스 의존성을 분석하면서 동기화 지점도 더 효율적으로 구성할 수 있게 됩니다.

---

결국 “전체 흐름 최적화”가 가능해졌다

예전 방식은 개별 패스를 관리하는 느낌이었다면,
RenderGraph는 전체 렌더링 흐름 자체를 최적화하는 구조에 가깝습니다.

이건 현대 엔진 구조에서 굉장히 중요한 변화입니다.

---

Unity 6에서 달라진 점

Unity 6에서는 URP 내부 구조 역시 RenderGraph 기반 흐름이 강화되었습니다.

예전보다 Renderer Feature 구조 / Pass 관리 / 리소스 관리가 더 Graph 중심으로 바뀌고 있습니다.

특히, Unity도 점점 GPU 메모리 효율 / 플랫폼 최적화 / GPU Driven Rendering방향으로 발전하고 있다는 느낌이 강합니다.

---

Unreal Engine도 비슷한 방향이다

흥미로운 점은 이런 흐름이 Unity만의 이야기는 아니라는 점입니다.

Unreal Engine 역시 RDG(Render Dependency Graph) 구조를 사용합니다.

현대 렌더링 엔진들은 점점 RenderGraph 기반 구조로 이동하고 있습니다.

이건 단순 유행이라기보다 현대 GPU 구조와 렌더링 복잡도 증가에 대응하기 위한 흐름에 가깝습니다.

---

RenderGraph가 중요한 진짜 이유

개인적으로 RenderGraph의 핵심은 단순 최적화 기능이 아니라고 생각합니다.

오히려 “렌더링 구조를 사람이 직접 관리하기 어려운 수준까지 복잡해졌기 때문”에 가깝습니다.

현대 렌더링은 패스 수 증가 / 리소스 수 증가 / GPU 동기화 증가 / 멀티 플랫폼 대응 문제로 인해
자동 흐름 관리가 점점 더 중요해지고 있습니다.

---

핵심 정리

• 현대 렌더링은 Render Pass 구조가 매우 복잡해졌다
• 기존 방식은 리소스 관리와 의존성 관리 한계가 있었다
• RenderGraph는 패스 관계를 그래프 형태로 관리하는 구조다
• 엔진이 전체 흐름을 이해하면서 자동 최적화가 가능해졌다
• GPU 메모리 재사용과 불필요한 Pass 제거가 가능해졌다
• Unity 6 역시 RenderGraph 중심 구조로 발전하고 있다

---

마무리

예전에는 렌더링 패스를 순차적으로 직접 관리하는 방식만으로도 충분했습니다.

하지만 현대 렌더링은 생각보다 훨씬 복잡해졌습니다.

그리고 이런 복잡도를 관리하기 위해 RenderGraph 같은 구조가 등장하게 됩니다.

개인적으로는
RenderGraph의 등장은 단순 기능 추가라기보다,
“현대 GPU 시대에 맞춘 렌더링 구조 변화”에 가깝다고 생각합니다.

앞으로의 렌더링 엔진들은 점점 더 자동 리소스 관리 / GPU 중심 구조 / 의존성 기반 최적화방향으로 발전할 가능성이 높다고 봅니다.