들어가며

예전 Unity 프로젝트들을 보면 대부분 Built-in Render Pipeline 기반으로 제작되어 있습니다.

한때 Unity 렌더링의 기본 구조였고, 많은 게임들이 이 파이프라인 위에서 만들어졌습니다.

그런데 시간이 지나면서 Unity는 새로운 렌더링 파이프라인을 적극적으로 밀기 시작했습니다.

• URP(Universal Render Pipeline)
• HDRP(High Definition Render Pipeline)

그리고 최근 Unity 6 기준으로 보면, 새로운 기능 상당수가 SRP 기반으로 개발되고 있습니다.

그렇다면 자연스럽게 이런 의문이 생깁니다.

왜 Unity는 기존 Built-in Render Pipeline 구조에서
SRP(Scriptable Render Pipeline) 구조로 변화하게 되었을까?

이번 글에서는 Built-in Render Pipeline의 구조적 한계와 SRP가 등장한 배경에 대해 정리해보겠습니다.

---

Built-in Render Pipeline이란?

Built-in Render Pipeline은 Unity가 오랫동안 기본으로 제공하던 렌더링 구조입니다.

쉽게 말하면 Unity 내부에 이미 만들어져 있는 렌더링 파이프라인입니다.

개발자는

• Material 설정
• Shader 작성
• Lighting 설정

정도만 조절할 수 있었고, 렌더링 전체 흐름 자체는 Unity 엔진 내부에 고정되어 있었습니다.

즉,

Unity 내부 렌더링 구조
↓
개발자는 일부 설정만 수정 가능

형태에 가까웠습니다.

---

당시에는 왜 충분했을까?

초기 Unity의 강점은 “빠르게 게임을 만들 수 있다”는 점이었습니다.

특히 인디 게임 / 모바일 게임 / 소규모 프로젝트에서는 매우 강력한 생산성을 보여줬습니다.

Built-in Render Pipeline 역시 쉽게 사용할 수 있고, 설정이 단순하며, 빠르게 결과를 볼 수 있다는 점에서 큰 장점이 있었습니다.

문제는 게임 규모와 하드웨어 성능이 점점 커지기 시작하면서 발생합니다.

---

점점 커지는 렌더링 요구사항

시간이 지나면서 게임들은 점점 더 복잡한 렌더링 기술을 요구하게 됩니다.

• PBR(Physically Based Rendering)
• 대규모 오픈월드
• 실시간 글로벌 일루미네이션
• 고해상도 그림자
• 대규모 라이트 처리
• 플랫폼별 최적화

같은 요구사항이 증가하기 시작했습니다.

그리고 여기서 Built-in Render Pipeline의 구조적 한계가 드러나기 시작합니다.

---

Built-in Render Pipeline의 가장 큰 한계

가장 큰 문제는 렌더링 흐름 자체를 개발자가 제어하기 어렵다는 점이었습니다.

• 특정 렌더링 단계 수정
• 커스텀 렌더 패스 추가
• 플랫폼 특화 최적화
• 렌더링 순서 제어

같은 작업이 매우 제한적이었습니다.

즉, Unity가 제공하는 흐름 안에서만 작업 가능한 구조였습니다.

---

모바일과 콘솔 시대의 문제

특히 모바일 시대가 본격적으로 열리면서 문제가 더 커집니다.

모바일 GPU는 PC GPU와 구조가 꽤 다릅니다.

• Tile Based Rendering
• 메모리 대역폭 제한
• 오버드로우 민감도

같은 특징이 존재합니다.

즉, 플랫폼마다 최적의 렌더링 전략이 달라질 필요가 생겼습니다.

하지만 Built-in Pipeline은 모든 플랫폼에 대해 비교적 공통적인 구조를 사용했습니다.

이 구조는 플랫폼별 최적화를 어렵게 만드는 원인이 됩니다.

---

Forward / Deferred 구조의 한계

Built-in Pipeline은 대표적으로 다음 렌더링 방식을 사용했습니다.

• Forward Rendering
• Deferred Rendering

하지만 프로젝트 규모가 커질수록 두 방식 모두 한계가 드러납니다.

• Forward → 많은 Light 처리 비효율
• Deferred → 모바일 메모리 부담 증가

같은 문제가 발생했습니다.

즉, 프로젝트 성격에 따라 더 유연한 렌더링 구조가 필요해졌습니다.

---

“모든 프로젝트를 위한 하나의 파이프라인” 문제

Built-in Render Pipeline은 사실상 모든 프로젝트가 하나의 렌더링 구조를 공유하는 형태였습니다.

하지만 현실에서는 프로젝트마다 요구사항이 완전히 다릅니다.

예를 들어

• 모바일 게임
• AAA 콘솔 게임
• VR 프로젝트
• 2D 게임

은 필요한 렌더링 구조 자체가 다릅니다.

즉,  “모든 게임에 하나의 렌더링 구조를 사용하는 것”자체가 점점 한계에 도달하기 시작했습니다.

---

그래서 등장한 것이 SRP

지금까지 설명한 Built-in Render Pipeline의 구조적 한계와 SRP 기반 구조 변화를 그림으로 정리해보면 다음과 같습니다.

핵심은 Unity가 단순히 새로운 기능을 추가한 것이 아니라, 렌더링 구조 자체를 더 유연하게 바꾸기 시작했다는 점입니다.

이런 문제를 해결하기 위해 등장한 구조가 SRP(Scriptable Render Pipeline)입니다.

핵심은 렌더링 흐름 자체를 스크립트로 제어 가능하게 만들었다는 점입니다.

즉,

Unity 내부 고정 렌더링 구조
↓
개발자가 직접 렌더링 흐름 구성 가능

형태로 변화하게 됩니다.

SRP는 렌더링 흐름 자체를 개발자가 직접 구성 가능하게 만들면서, 현대 렌더링 엔진 구조에 맞춰 발전하기 시작했습니다.

---

SRP에서 Scriptable이라는 이름의 의미

SRP에서 중요한 단어는 Scriptable입니다.

즉, 렌더링 흐름을 코드 레벨에서 구성할 수 있다는 의미입니다.

• 렌더 패스 추가
• 렌더링 순서 변경
• 커스텀 라이팅 구조
• 플랫폼 최적화

같은 작업이 가능해졌습니다.

이건 단순 기능 추가 수준이 아니라 렌더링 구조 자체의 철학이 바뀐 것에 가깝습니다.

---

URP와 HDRP는 왜 나뉘었을까?

SRP 등장 이후 Unity는 대표적으로 두 가지 파이프라인을 제공하기 시작합니다.

• URP
• HDRP

이 구조 자체가 Built-in Pipeline의 한계를 보여주는 좋은 사례입니다.

---

URP란

URP는 다양한 플랫폼에서 동작 가능한 범용 파이프라인입니다.

특히, 모바일 / 콘솔 / 중간급 하드웨어 같은 환경에 맞춰 최적화되어 있습니다.

즉, 성능과 범용성을 중요하게 보는 구조입니다.

---

HDRP란

HDRP는 고사양 환경을 위한 파이프라인입니다.

• 고급 조명
• 고품질 그림자
• 볼류메트릭 효과
• 고급 포스트 프로세싱

같은 기능에 초점이 맞춰져 있습니다.

즉,  최고 수준의 비주얼 품질을 목표로 합니다.

---

결국 Unity도 “플랫폼 특화” 방향으로 가게 되었다

예전에는 하나의 렌더링 구조로 모든 플랫폼을 대응하려 했습니다.

하지만 지금은

• 모바일
• 콘솔
• PC
• VR

모두 요구사항이 너무 달라졌습니다.

그래서 현대 엔진들은 점점 더 플랫폼 특화 렌더링 구조로 발전하고 있습니다.

Unity의 SRP 역시 이 흐름 속에서 등장한 구조라고 볼 수 있습니다.

---

최근 Unity 6 흐름

Unity 6 기준으로 보면 신규 렌더링 기능 상당수가 SRP 기반으로 개발됩니다.

• RenderGraph
• Forward+
• GPU Resident Drawer
• 최신 Renderer Feature

같은 기능들이 그렇습니다.

현재 Unity 렌더링의 중심은 사실상 SRP 기반으로 이동했다고 볼 수 있습니다.

---

핵심 정리

• Built-in Render Pipeline은 Unity 내부에 고정된 렌더링 구조였다
• 프로젝트 규모와 플랫폼 다양성이 증가하면서 구조적 한계가 드러났다
• 특히 모바일과 콘솔 환경에서 플랫폼 특화 최적화 필요성이 커졌다
• SRP는 렌더링 흐름 자체를 개발자가 구성 가능하게 만든 구조다
• URP와 HDRP는 서로 다른 목적을 가진 렌더링 파이프라인이다
• 최근 Unity 렌더링 구조는 SRP 중심으로 발전하고 있다

---

마무리

예전에는 Built-in Render Pipeline만으로도 충분히 많은 게임을 만들 수 있었습니다.

하지만 게임 규모와 하드웨어 환경이 변화하면서 더 유연하고 플랫폼 특화된 렌더링 구조가 필요해졌습니다.

그리고 이런 흐름 속에서 SRP가 등장하게 됩니다.

개인적으로는 SRP의 등장은 단순 기능 추가라기보다, “현대 렌더링 엔진 구조 변화”에 가까운 흐름이라고 생각합니다.

Unity 역시 점점 더 GPU 구조 / 플랫폼 특성 / 렌더링 병목을 직접 고려하는 방향으로 발전하고 있다고 볼 수 있습니다.