2026 Unity GDC 요약

이번 포스트에서는 Unity가 GDC 2026 직전에 진행한 Product Update 라이브 스트림의 주요 내용을 정리해보려고 한다. 공식 안내에 따르면 이번 발표는 단순한 기능 소개를 넘어서, Graphics & Performance Improvements, AI Updates, Path to CoreCLR, Platform Toolkit, IAP를 중심으로 앞으로의 엔진 방향성을 보여주는 자리였다.

 1  |  개요 

개인적으로 이번 발표를 보면서 느낀 점은, Unity가 이제 더 이상 기능 몇 개 추가했습니다 수준의 업데이트를 이야기하는 단계가 아니라는 것이다. 이번 발표는 꽤 명확하게 다음 질문에 대한 답을 주고 있었다.

앞으로 Unity 엔진은 어떤 구조를 중심으로 발전하려는가?

그리고 그 답은 대략 다음 네 가지로 정리할 수 있었다.

• URP 중심의 그래픽 전략 강화
• AI를 개발 도구 안으로 깊게 통합
• Mono에서 CoreCLR로의 본격적인 전환
• 플랫폼별 배포 및 런타임 현대화

이 글에서는 발표 순서에 맞춰 내용을 정리하면서, 중간중간 왜 이 변화가 중요한지도 함께 적어보려고 한다.

이번 발표는 여러 발표자가 파트를 나눠서 진행했다.

이 영상은 단순 홍보 영상보다는, Unity가 GDC 전에 개발자들에게 이번 시즌에 무엇을 밀고 있는지 미리 보여주는 기술 브리핑에 더 가깝다. 블로그를 읽는 입장에서 가장 중요한 건 결국 이런 것이다.

• 지금 당장 써먹을 수 있는 기능은 무엇인가
• 앞으로 1~2년 안에 작업 방식이 바뀔 만한 변화는 무엇인가
• 기존 프로젝트 구조에 영향을 줄 만한 발표는 무엇인가

이번 발표에서는 특히 CoreCLR과 Entities + GameObject 통합 방향이 그런 성격이 강했다. 표면적으로는 기능 추가처럼 보여도, 실제로는 엔진의 중심축을 천천히 옮기고 있다는 느낌이 강했다.

 2  |  Graphics 

🔷 2-1. Graphics 개요

그래픽 파트에서 가장 먼저 강조된 메시지는 다음과 같았다.

Build Fast / Build Beautiful / Deploy Everywhere

이 세 문장은 단순한 슬로건처럼 보일 수 있지만, 이번 발표 전체의 방향을 아주 잘 압축하고 있다. Unity는 그래픽 품질을 올리면서도 제작 속도를 유지하고, 동시에 특정 하이엔드 플랫폼에만 맞춘 기능이 아니라 여러 플랫폼에서 공통적으로 사용할 수 있는 구조를 만들겠다는 쪽으로 움직이고 있었다. 그 중심에 있는 것이 바로 URP ( Universal Render Pipeline ) 다.

과거에는 Unity의 렌더 파이프라인 이야기를 하면 항상 Built-in / URP / HDRP 중 뭘 쓸까 ? 라는 고민부터 시작했다. 그런데 이번 발표의 뉘앙스는 꽤 분명했다. 앞으로의 중심은 URP이며, 가능한 한 많은 기능과 품질 향상을 URP에 집중하겠다는 것이다.

여기서 중요한 건 HDRP가 사라진다 는 뜻은 아니라는 점이다. 오히려 해석은 이렇게 하는 편이 맞다.

즉, 개발자 입장에서는 여러 렌더링 선택지 사이에서 계속 갈팡질팡하기보다, URP를 메인 축으로 보고 투자하라 는 신호에 가깝다.

🔷 2-2. Surface Cache GI (SCGI)

그래픽 파트에서 가장 눈에 띄는 기능 중 하나는 Surface Cache GI였다. GI (Global Illumination) 는 늘 아름답지만 귀찮은 기술이었다. 보기 좋게 만들려면 비용이 많이 들고, 비용을 줄이려면 품질이나 동적 대응성이 깨지는 경우가 많았기 때문이다. (사실 나는 3D 작업을 많이 안해봐서 잘 몰랐다… 😖)

발표에서 소개된 SCGI의 방향을 정리하면 다음과 같다.

• 동적 오브젝트에 대응 가능한 GI
• 라이트맵에 덜 의존하는 방향
• URP 환경에서도 실용적인 성능을 목표
• 머티리얼이나 레이어를 대규모로 다시 손대지 않아도 되는 워크플로 지향

이게 왜 중요하냐면, 실제 프로젝트에서는 GI가 있다 보다 GI를 프로덕션에 넣을 수 있느냐 가 더 중요하기 때문이다. 특히 모바일이나 멀티플랫폼 프로젝트에서는 GI가 예쁘더라도 파이프라인이 무거우면 바로 탈락한다. SCGI는 바로 그 지점을 겨냥한 기능으로 보였다. 즉, 이 기능은 정적인 라이트맵 중심 접근과 완전한 실시간 조명 사이의 간극을 메우려는 시도로 이해하는 게 가장 자연스럽다.

🔷 2-3. 셰이더 컴파일과 빌드 시간 개선

그래픽 품질 못지않게 실무에서 중요한 것이 빌드 시간과 런타임 스터터 (stutter)일 것이다. 아무리 좋은 셰이더가 있어도, 실제 기기에서 로딩 중이나 전투 중에 셰이더 컴파일로 프레임이 튀면 체감 품질이 무너진다.

이번 발표에서는 이 문제를 줄이기 위한 방향으로 PSO 캐싱과 DXC 기반 셰이더 툴체인 전환이 소개되었다. 여기서 눈 여겨볼 포인트는 두 가지다.

• 첫째, 런타임 셰이더 컴파일 스터터를 줄이려는 시도라는 점.
• 둘째, 셰이더 빌드 파이프라인 자체를 더 현대적인 방향으로 가져간다는 점이다.

개발자는 종종 그래픽 기능 추가 만 큰 변화처럼 느끼는데, 사실 프로젝트를 오래 굴려보면 이런 빌드 파이프라인 개선이 훨씬 체감이 크다. 빌드가 느리면 결국 반복 작업이 늦어지고, 반복 작업이 늦어지면 팀의 판단 속도도 같이 느려진다. 예쁜 렌더링도 중요하지만, 엔진이 팀의 시간을 얼마나 덜 잡아먹느냐도 못지않게 중요하다. 이쪽은 참으로 낭만 없는 숫자 싸움 같지만, 실제 생산성은 대체로 여기서 갈린다.

여기서 잠깐. PSO가 뭘까? 영상을 보다가 모르는 부분이 있어서 정리를 하고 넘어가고자 한다.

🔶 2-3-1. PSO (Pipeline State Object) 란?

한만디로 요약하자면, Pipeline State Object는 그래픽 파이프라인 상태를 하나의 객체로 묶은 것이다. 예를 들어 GPU가 화면에 어떤 오브젝트를 그리기 위해서는 다음과 같은 상태들이 필요하다:

• Vertex Shader
• Pixel Shader
• Blend State
• Depth Stencil State
• Rasterizer State
• Render Target Format

예전 그래픽 API(OpenGL, DirectX11 등)에서는 이러한 상태를 각각 설정하는 방식이었다.

SetShader(...)
SetBlendState(...)
SetDepthState(...)
Draw()

하지만 최신 그래픽 API (DirectX12, Vulkan 등)는 접근 방식이 다르다. 이 모든 상태를 하나의 객체로 미리 만들어 두고 사용한다.

PipelineStateObject pso = CreatePSO(...);

SetPipelineState(pso);
Draw();

이렇게 GPU 파이프라인 상태를 하나로 묶어 관리하는 것이 바로 PSO이다.

🔶 2-3-2. 그런데 왜 문제가 될까 ? : PSO 생성 비용은 생각보다 크다

문제는 PSO 생성 자체가 꽤 무거운 작업이라는 점이다.

PSO를 생성할 때 GPU 드라이버는 내부적으로 다음과 같은 작업을 수행한다.

Shader 최적화 / Shader Linking/ GPU ISA 컴파일/ 파이프라인 검증 / …

이 과정은 단순한 객체 생성이 아니라 GPU용 실행 코드를 생성하는 컴파일 과정에 가깝다. 그래서 PSO 하나를 생성하는 데 수 밀리초 이상의 시간이 걸리는 경우도 있다. 만약 이 작업이 게임 플레이 도중 발생한다면 어떻게 될까? 바로 그 순간 프레임 드랍이 발생한다.

🔶 2-3-3. 그럼 어떻게 할까 ? : 한 번 만든 PSO는 저장해서 다시 사용하자

PSO Caching의 아이디어는 매우 단순하다. 한번 생성한 PSO를 저장해 두고 다음 실행 때 재사용하자 동작 방식은 다음과 같다. 게임을 처음 실행하면 다음과 같은 작업이 진행된다.

게임 실행 → 새로운 PSO 생성 → 디스크에 Cache 저장 -> PSO 사용

그 이후엔 이렇게 된다.

게임 실행 → PSO Cache 로딩 → PSO 재사용

이렇게 하면 다음 실행부터는 PSO 컴파일 과정이 필요 없기 때문에 런타임 스터터를 크게 줄일 수 있다. 실제로, 최근 PC 게임을 실행하면 종종 다음과 같은 화면을 볼 수 있다.

다시 돌아와서, Unity GDC에서 보여준 데모에서도 성능 체감을 크게 느낄 수 있다.

PSO 캐싱은 이번 발표에서 처음 등장한 완전한 신규 기능이라기보다는, Unity 6부터 이어져 오던 PSO tracing / precooking 흐름을 다시 한 번 강조한 내용으로 보였다

📚 참고자료 :

• Unity Discussions | Prevent shader compilation stutters with PSO Tracing in Unity 6

 3  |  AI Tooling 

🔷 3-1. AI Toolings 개요

이번 발표에서 가장 요즘 Unity답다 는 느낌이 강했던 파트는 AI였다. Unity는 AI 기능을 단순 보조 도구가 아니라 에디터 워크플로 안으로 들어오는 작업 파트너처럼 소개했다. AI 관련 기능은 자칫하면 홍보 문구만 잔뜩 늘어놓고 끝나기 쉬운데, 이번 발표는 비교적 사용 장면이 명확했다.

• Scene 생성
• 프로파일러 분석
• UI 생성
• 이미지 인식 기반 편집
• 체크포인트와 롤백
• MCP 기반 외부 에이전트 연동
• 외부 모델 사용

즉 채팅창에 단순히 대화하는 AI 가 아니라, 에디터에서 실제 작업을 건드리는 AI를 목표로 하고 있었다.

근데 블로그 글을 쓰다보니 조금 웃기긴 하다. 예전에는 AI와 자유롭게 대화하는 것도 생각하기 어려웠는데… 이제는 “단순히 대화하는”이 되어버리는 시대에 살고있다니…

🔷 3-1. Scene Generation

Scene Generation은 이름 그대로, 프로젝트 내 에셋을 활용해 프롬프트 기반으로 씬을 배치하는 방향의 기능이다. 이 기능의 핵심은 씬을 자동으로 만들어준다 보다도, 기획 초기나 반복 배치 작업에서 손이 많이 가는 부분을 줄여준다는 데 있는것 같다.

예를 들어 다음과 같은 상황을 떠올릴 수 있다:

• 프로토타입 맵을 빨리 깔아보고 싶을 때
• 기존 에셋들을 조합해 초안 레벨을 만들고 싶을 때
• 아트팀에 정식 요청하기 전에 대략적인 레이아웃을 보고 싶을 때

물론 이걸로 완성형 레벨 디자인이 해결되지는 않을 것이다. 하지만 초기 배치, 조합, 반복 수정 같은 단계에서 생산성을 높이는 데는 꽤 쓸모가 있어 보인다.

🔷 3-2. Profiler 분석

개인적으로 AI 파트에서 가장 실용적으로 느껴진 건 Profiler 통합이다. 성능 이슈는 늘 중요하지만, 프로파일링 데이터는 읽기가 어렵다. 숫자와 타임라인은 정직한데, 인간은 늘 피곤하다. 그래서 병목을 정확히 읽는 데 시간이 걸린다.

이번 발표에서 소개된 방향은 대략 다음과 같다.

• 프로파일러 캡처를 AI가 분석
• 성능 스파이크 원인을 설명
• 최적화 제안을 자연어로 제공

이건 개발자 경험 측면에서 꽤 큰 변화다. 기존에는 데이터는 있는데 해석이 오래 걸린다 가 문제였는데, 앞으로는 최소한 첫 번째 해석 비용을 줄여주는 도구가 생기는 셈이다.

물론 AI의 분석 결과를 그대로 믿으면 안 된다. 성능 분석은 결국 측정 > 가설 > 검증의 과정이기 때문에, AI가 제안한 원인은 어디까지나 참고하는편이 맞다. 그래도 의심되는 부분을 빨리 뽑아주는 것만으로도 이미 꽤 유용할 것으로 기대한다.

🔷 3-3. UI Builder

세션에 따르면, AI기반으로 UI작업도 진행할 수 있다고 한다. 요 세션에서 흥미로웠던 부분은 AI가 단순 텍스트 입력만 받는 것이 아니라, 이미지와 스케치, 편집 맥락까지 받아들이는 방향으로 확장되고 있다는 점이다.

• UI Builder : 프롬프트나 이미지를 바탕으로 HUD, 메뉴 등을 생성
• Vision : 스크린샷이나 씬 이미지를 분석
• Annotations : 이미지 위에 표시한 영역을 중심으로 작업 수행
• Checkpoints : 작업 전 상태 저장 및 롤백

실무에서는 이 UI를 대충 이렇게 바꿔줘 가 텍스트보다 이미지 지시로 더 빠를 때가 많다. 또 AI가 에디터 작업을 건드리기 시작하면 반드시 필요한 것이 되돌리기 안전장치인데, 체크포인트 기능은 바로 그 지점을 보완한다. 이건 Unity가 AI 기능을 넣으면서 최소한의 현실 감각은 챙겼다는 뜻으로 보인다.

하지만 개인적으로 UI Toolkit을 쓰는 UXUI 디자이너들을 본 적이 별로 없어서… 실무에서 진짜 쓸 수 있을지는 잘 모르겠다.

 4  |  CoreCLR & Engine Roadmap 

🔷 4-1. CoreCLR & Engine Roadmap 개요

클라이언트 개발자로서 이번 영상의 가장 중요하게 봤던 부분을 꼽으라면, CoreCLR이라고 생각한다. 이 변화는 기능 추가가 아니라 런타임 세대 교체에 가깝기 때문이다. 오랫동안 Unity의 .NET/Mono 환경은 늘 아쉬움의 대상이었다. 그러나 이번 발표는 그 오래된 숙제를 드디어 끝내겠다는 선언처럼 보였다!

🔷 4-2. 왜 CoreCLR이 중요한가

CoreCLR 전환의 의미는 단순히 새 런타임을 쓴다 가 아니다. 실제로 연결되는 효과는 훨씬 넓다. 즉, 이건 그냥 런타임 교체가 아니라 Unity 개발자들이 오랫동안 느껴온 .NET 쪽 답답함을 풀어내려는 작업이다.

📚 참고자료 :

• Unity Blog | Unity를 CoreCLR로 포팅하는 과정

이후 발표는 버전별 로드맵을 제시했다. 여기서 중요한 건 각 버전의 개별 기능보다도 흐름인데, 일단 어떤 내용이 있는지 먼저 살펴보도록 하자.

🔶 4-2-1. Unity 6.5

• 멀티스레드 메모리 할당 개선
• 로깅 프레임워크 현대화
• 에디터 라이프사이클 API 추가

겉보기에는 화려하지 않지만, 뒤에 올 더 큰 구조 변화를 위한 바닥 다지기처럼 보인다.

🔶 4-2-2. Unity 6.6

• Jobs Profiler 개선
• Fast Enter Play Mode 기본값 방향
• CoreCLR player 관련 실험적 진입

🔶 4-2-3. Unity 6.7 LTS

• CoreCLR Desktop Player 실험적 제공
• SCGI 확장
• C# 직렬화 현대화
• Entities와 GameObject 워크플로 통합 시작

LTS라는 점까지 생각하면, 많은 개발팀이 이 시점을 기준으로 이제 진짜 프로젝트에 검토해볼까? 를 고민하게 될 가능성이 크다.

🔶 4-2-4. Unity 6.8

발표 내용 기준으로는 사실상 CoreCLR 전환의 완성 단계를 목표로 하고 있었다.

• Mono 완전 제거 방향
• .NET 10 / C# 14 지원 목표
• MSBuild 지원
• PlayerLoop 구조 변화
• Entities + GameObject 통합

이건 주목할 만 하다고 생각했다. 예전의 Unity가 게임 오브젝트 중심 엔진에 ECS가 붙어 있는 구조 였다면, 앞으로는 엔티티 시스템이 엔진 중심축이 되고, GameObject가 거기에 더 자연스럽게 연결되는 구조 를 향해 가고 있다는 뜻이기 때문이다.

🔷 4-3. Entities + GameObject 통합

이건 Unity 개발자에게 꽤 의미있는 메시지라고 생각했다! 지금까지는 대체로 이런 인식이 있었다.

• GameObject는 익숙하고 범용적이다
• ECS는 빠르지만 별도 세계처럼 느껴진다 (= 쓰기 어렵다)

그런데 이번 발표 방향은 이 둘을 따로 두기보다, 점점 더 한 워크플로 안으로 묶어가겠다는 쪽에 가깝다. 이게 중요한 이유는 단순하다. 좋은 기술이라도 엔진 주류 흐름 밖에 있으면 adoption이 느리다. 반대로 에디터 워크플로, 계층 구조, 직렬화, 플레이어 루프까지 연결되기 시작하면 그때부터는 선택 기술 이 아니라 기본 엔진 구조 가 된다.

특히 ECS 기반 프로젝트를 다루는 입장에서는 이 변화가 남 일 같지 않다. 지금은 DOTS를 적극적으로 쓰는 팀만 체감하는 구조 변화처럼 보일 수 있지만, 장기적으로는 Unity 전체의 업데이트 구조와 성능 모델이 그쪽으로 조금씩 기울 가능성이 높다.

 5  |  Platform & Deployment 

🔷 5-1. Steam 공식 지원

Unity에서 Steam 연동은 오랫동안 어차피 직접 붙여야 하는 것 에 가까웠다. 그런데 엔진 차원에서 더 공식적인 지원 흐름이 잡히면, 초기 세팅과 유지보수 부담이 줄어들 수 있다. 이건 인디나 소규모 팀에서 특히 의미가 크다. 출시 직전에는 늘 해야 할 일이 산더미인데, 플랫폼 통합 작업이 조금이라도 덜 복잡해지면 체감 차이가 꽤 크다.

🔷 5-2. DirectStorage, Android, Apple, Web

플랫폼 파트는 사실 여러 조각이 있었지만, 흐름으로 보면 하나로 묶인다. 각 플랫폼의 성능과 배포 파이프라인을 현대화한다 눈에 띄는 키워드는 다음과 같다.

• DirectStorage
• Android 성능 개선
• Apple 플랫폼 Glue 레이어 현대화
• WebGPU / Web 성능 개선
• Progressive Asset Loading

웹은 한동안 돌아가면 다행 같은 취급을 받던 시절이 있었는데, 이제는 다시 꽤 진지한 배포 타겟이 되어가는 분위기다. WebGPU와 자산 로딩 개선이 붙으면, 웹도 단순 체험판이 아니라 꽤 본격적인 타겟으로 검토할 여지가 생긴다.

 6  |  In-App Purchase / Web Shop 

🔷 6-1. In-App Purchase / Web Shop

마지막으로 수익화 쪽도 꽤 실무적인 변화가 소개되었다.

핵심 메시지는 단순하다.

앱 안에서만 파는 구조를 넘어서 웹샵까지 연결하고 결제와 카탈로그 연동을 단순화하겠다!

특히 직접 판매 채널은 라이브 서비스 게임에서 민감한 주제다. 이 영역은 기술만의 문제가 아니라 결제 경험, 수수료, 운영, 법적 처리까지 연결되기 때문에, 엔진이 일정 부분 프레임워크를 제공한다는 점 자체가 의미가 있다. 물론 이건 엔진 핵심 구조 변화만큼 모든 개발자에게 직접적인 뉴스는 아닐 수 있다. 하지만 라이브 게임 운영 관점에서는 출시 후 매출 구조를 어디까지 엔진 도구 안에서 관리할 수 있느냐 라는 꽤 현실적인 질문과 연결된다.

 7  |  인사이트 

이번 GDC를 보면서, 개인적으로 중요하다고 생각한 점을 정리해본다. 이번 발표를 기능 목록으로만 읽으면 새로운 기능이 많네 정도로 끝날 수 있다. 그런데 조금 멀리서 보면, 더 중요한 흐름이 보인다.

🔷 7-1. Unity는 URP를 중심으로 그래픽 전략을 정리하고 있다.

이건 단순히 렌더링 기능이 늘어나는 이야기가 아니라, 제작 파이프라인 선택 비용을 줄이는 방향이다.

🔷 7-2. AI를 채팅창 장난감이 아니라 에디터 작업 흐름 안으로 넣고 있다.

씬 생성, UI 생성, 프로파일링 분석, 이미지 기반 편집 등 다양한 기능이 추가되었다.

🔷 7-3. CoreCLR 전환은 단순 업그레이드가 아니라 구조 교체다.

이건 앞으로의 반복 작업 속도, 언어 기능, 툴 생태계, 런타임 경험 전체에 영향을 줄 수 있다.

🔷 7-4. Entities와 GameObject 통합은 ECS를 엔진 중심부로 끌어들이는 신호다.

이 변화가 실제로 완성되면, Unity의 성능 모델과 워크플로 자체가 지금보다 훨씬 달라질 가능성이 있다.

즉 이번 발표는 이 기능도 추가됩니다~ 의 나열이 아니라, Unity가 앞으로 어떤 개발 경험을 기본값으로 만들고 싶은지 보여주는 발표 였다고 보는 편이 맞다.

 8  |  마치며 

이번 Unity Pre-GDC 2026 발표는 겉으로 보면 Graphics, AI, Platform, IAP를 두루 다루는 종합 업데이트처럼 보인다. 하지만 실제로는 꽤 분명한 방향이 있었다.

• Unity는 엔진을 더 현대적인 런타임 위에 올리려고 하고 있다.
• URP를 중심으로 렌더링 전략을 정리하려고 하고있다.
• AI를 에디터 안으로 가져오려고 하고있다.
• ECS를 더 엔진 중심으로 끌어오려 하고있다.

이 변화가 모두 한 번에 체감되지는 않을 것이다. 당장 이번 분기에 프로젝트가 갑자기 완전히 달라지는 것도 아니다. 하지만 방향은 충분히 읽혔다. 특히 개인적으로는 CoreCLR과 Entities + GameObject 통합 이라는 두 가지 키워드가 가장 크게 기억에 남았다.

이 두 가지는 단순한 편의 기능이 아니라, 앞으로 Unity 개발 방식 자체를 바꿀 수 있는 변화다. 지금은 로드맵과 실험적 기능의 형태로 보이더라도, 이후 몇 개 버전을 거치면서 실제 개발 문화에 영향을 줄 가능성이 크다. 결국 이번 발표는 Unity가 무엇을 추가할까 보다, 앞으로 어떤 엔진이 되고 싶은가 를 보여준 발표였다고 정리할 수 있을 것 같다.