Unity 6.6, WebGPU의 실험 단계를 끝냈지만 기본값은 꺼진 채
Unity는 9월 1일 Unity 6.6을 출시했습니다. 이 버전은 "지원(Supported)" 릴리스로, 6.7이 나올 때까지 LTS와 동일한 수준의 안정성 지원을 받으며 해당 LTS 전 Unity 6 계열의 마지막 릴리스입니다. 브라우저용 게임을 출시하는 사람이라면 일주일 전 Web Graphics 팀 게시물에 나온 한 문장이 가장 눈에 띌 것입니다. "Unity 6000.6부터 WebGPU 그래픽 API는 더 이상 실험 단계가 아니며, 이제 완전히 지원되는 기능입니다."
Unity는 2025년 초 6.1부터 WebGPU를 실험적 백엔드로 제공해 왔습니다. 당시 저희도 이를 다뤘고, 이후 Safari의 WebGPU 출시부터 모든 주요 브라우저의 지원 도입까지 브라우저 쪽의 변화를 추적해 왔습니다. 이제 엔진 쪽도 따라잡았습니다.
Unity가 직접 소개하는 6.6의 새로운 기능
WebGPU로 활성화되는 기능
Unity에서 WebGPU가 특히 중요한 이유는 컴퓨트 셰이더입니다. WebGL 2에는 컴퓨트 셰이더가 없었기 때문에 GPU 컴퓨팅에 의존하는 Unity 기능은 웹 빌드에서 아예 사용할 수 없었습니다. WebGPU를 선택하면 웹 빌드에서 GPU Resident Drawer와 GPU 오클루전 컬링, Spatial-Temporal Post-Processing 업스케일링, GPU 시뮬레이션 파티클을 사용하는 VFX Graph, Adaptive Probe Volumes, 컴퓨트 스키닝을 사용할 수 있습니다. Unity가 게시물에서 선보인 데모 장면은 건물이 빽빽한 스타일라이즈드 마을인 Fantasy Kingdom과 VFX Graph 파티클로 가득한 우주선 내부였으며, 둘 다 브라우저에서 실행되었습니다.
VFX Graph 파티클은 GPU로 시뮬레이션되므로 WebGL 2에서는 전혀 사용할 수 없었습니다. 이미지: Unity.
WebGPU를 지원한다고 보고하지만 전체 기능을 처리할 수 없는 하드웨어를 위한 경량 호환 모드도 있습니다. 따라서 개발자가 별도로 조치하지 않아도 동일한 빌드가 더 많은 기기에서 실행됩니다.
Unity가 의도적으로 하지 않은 것
WebGPU는 기본적으로 활성화되지 않습니다. 웹 빌드의 기본 그래픽 API는 계속 WebGL 2입니다. WebGPU를 사용하려면 Web 플레이어 설정을 열고 자동 그래픽 API 선택을 해제한 다음 목록에 WebGPU를 추가해야 합니다. Unity는 런타임에 우선순위에 따라 API를 시도하고, 첫 번째 API를 사용할 수 없으면 다음 API로 폴백합니다.
WebGPU는 Graphics APIs 목록에 직접 추가해야 합니다. 이미지: Unity.
게시물에 나온 두 가지 주의사항은 놓치면 하루를 허비할 만한 내용입니다. 첫째, 브라우저는 보안 컨텍스트에서만 WebGPU를 노출합니다. 따라서 로컬 파일이나 일반 HTTP 호스트에서 제공되는 빌드는 아무런 경고 없이 WebGL 2로 전환되며, 개발자는 컴퓨트 기능이 왜 사라졌는지 의아해할 수 있습니다. 둘째, Unity의 표현을 그대로 옮기면 "WebGPU 지원을 보고하는 모든 기기가 일관된 경험을 제공하는 것은 아닙니다." 그래서 6.6에는 문제가 있다고 확인된 특정 브라우저, GPU 또는 드라이버에서 폴백을 강제하는 규칙 모음인 Graphics Device Filtering이 추가되었습니다.
6.6의 나머지 웹 관련 개선은 용량과 메모리에 초점을 맞춥니다. WebAssembly64를 사용하면 브라우저 빌드에서 기존의 4GB 한도를 넘어 최대 16GB의 메모리를 주소 지정할 수 있습니다. Chrome 및 Edge 128 이상과 Firefox 129 이상에서 지원됩니다. Progressive Asset Loading은 에셋을 처음부터 한꺼번에 다운로드하는 대신 장면별로 전달하므로, 나머지 에셋이 스트리밍되는 동안 플레이어는 첫 장면에서 게임을 시작할 수 있습니다. 두 기능 모두 Unity 웹 게임이 역사적으로 선택받기 어려웠던 두 가지 이유, 즉 큰 용량과 메모리 부족 문제를 해결합니다.
릴리스의 나머지 내용
브라우저 외 영역에서는 이제 새 프로젝트에 Fast Enter Play Mode가 기본 적용되어 도메인 리로드 없이 장면을 다시 불러옵니다. Unity는 이를 Unity 7의 CoreCLR 전환을 위한 준비로 설명합니다. 마침내 Inspector에서 Dictionary가 네이티브로 직렬화됩니다. 새로운 Build Analysis 창은 빌드 기록과 지표를 추적하며, Content Directories는 Addressables 통합 및 Windows와 Xbox의 DirectStorage 지원을 통해 로컬 콘텐츠를 정리합니다. 셰이더 개선 사례로 Unity는 키워드 배리언트를 동적 분기로 전환한 뒤 빌드 시간이 1시간 46분에서 32분으로 줄어든 빌드를 들었습니다.
웹 게임에 미치는 영향
저희는 three.js와 WebGPU를 직접 사용하므로 Unity 백엔드의 정식 지원 전환은 경쟁 위협이라기보다 확신을 뒷받침하는 신호에 가깝습니다. 이제 브라우저 GPU 컴퓨팅은 설치 기반이 가장 큰 엔진에서 지원되는 경로가 되었습니다. 이는 WebGPU를 전제로 출시되는 게임이 늘어나고, 더 많은 플레이어가 호환성의 경계 사례를 마주하며, 브라우저 공급업체가 이런 문제를 해결해야 한다는 압박을 더 크게 받게 된다는 뜻입니다. 저희는 게임에서 WebGPU와 WebGL이 서로 어떻게 비교되는지, 그리고 웹용 엔진 선택지를 정리한 바 있으며, 두 글의 조언은 여전히 유효합니다. WebGPU를 활성화하되 WebGL 2 폴백을 함께 제공하고, 실제 저사양 하드웨어에서 테스트하며, "브라우저가 지원한다고 표시한다"는 사실을 결론이 아니라 검증의 출발점으로 삼아야 합니다.
지원 릴리스에서 Unity가 WebGPU를 기본적으로 꺼둔 것은 올바른 판단이며, 동시에 상황을 보여주는 신호이기도 합니다. API는 준비되었습니다. 아직 기기 생태계는 균일하지 않으며, 그 모든 기기에서 실행되어야 하는 엔진은 누구보다도 이 사실을 잘 알고 있습니다.