WebGPU는 단순히 “더 빠른 WebGL”이 아니다. 최신 GPU 구조에 가까운 그래픽 및 컴퓨트 모델을 제공하며, 웹 애플리케이션이 파이프라인을 더 명확하게 구성하고 병렬 연산을 활용할 수 있게 한다. Three.js에서는 WebGPURenderer가 이 구조로 들어가는 실용적인 출발점이다.

도입 이유를 자동적인 FPS 상승으로 잡아서는 안 된다. 렌더링, 컴퓨트, 머티리얼, 후처리를 복잡한 3D 작업에 맞게 재구성할 수 있다는 점이 핵심이다. 대신 실험 단계의 렌더러, 새로운 셰이더 작성 방식, 여러 백엔드 테스트라는 비용을 받아들여야 한다.

WebGPURenderer는 무엇을 바꾸는가?

Three.js 공식 가이드에 따르면 WebGPURenderer는 WebGPU를 우선 사용하고 지원되지 않는 환경에서는 WebGL 2로 자동 폴백하는 범용 렌더러다. 하나의 코드베이스로 신구 기기를 지원할 수 있지만 WebGPU 전용 기능까지 WebGL에서 동일하게 제공되는 것은 아니다.

가장 큰 변화는 아키텍처다. 새 렌더러는 노드 머티리얼, Three.js Shading Language(TSL), 현대적인 후처리 스택, 렌더와 컴퓨트의 결합을 중심으로 설계되었다. JavaScript로 셰이더 그래프를 표현하면 Three.js가 WebGPU용 WGSL 또는 WebGL용 GLSL로 변환한다.

import * as THREE from 'three/webgpu';

const renderer = new THREE.WebGPURenderer({ antialias: true });
renderer.setPixelRatio(Math.min(window.devicePixelRatio, 2));
renderer.setSize(window.innerWidth, window.innerHeight);
renderer.setAnimationLoop(() => renderer.render(scene, camera));
document.body.appendChild(renderer.domElement);

WebGPU 초기화는 비동기다. setAnimationLoop()를 사용하면 첫 프레임 전에 초기화를 보장할 수 있다. 직접 requestAnimationFrame() 루프를 관리한다면 렌더링 전에 await renderer.init()을 호출해야 한다.

렌더러 교체보다 중요한 TSL

마이그레이션에서 가장 어려운 부분은 대개 머티리얼이다. ShaderMaterial, RawShaderMaterial, onBeforeCompile() 기반 수정은 WebGPURenderer에서 직접 지원되지 않는다. 이 코드는 노드 머티리얼과 TSL로 옮겨야 한다.

TSL은 JavaScript로 셰이더 연산을 조합하고 노드를 재사용하며 컴파일러가 중복 계산을 제거하도록 한다. 단순한 GLSL 문법 변경이 아니라 의존성 순서, 타입 변환, 백엔드 출력을 Three.js 노드 시스템에 맡기는 방식이다. 잘 설계된 그래프는 WGSL과 GLSL을 함께 대상으로 삼을 수 있다.

컴퓨트 셰이더가 유용한 작업

컴퓨트 파이프라인은 WebGPU의 핵심 기능이다. Three.js에서는 파티클 시뮬레이션, 대량 변환, 절차적 생성, 데이터 전처리처럼 폭넓은 병렬 처리가 필요한 작업에 적합하다. 데이터 생성과 갱신, 소비를 GPU 안에서 처리하면 JavaScript와 GPU 메모리 사이의 전송도 줄일 수 있다.

모든 알고리즘이 빨라지는 것은 아니다. 작은 작업, 분기가 많은 로직, 결과를 CPU로 자주 읽어야 하는 작업은 이점이 적을 수 있다. 평균 FPS뿐 아니라 CPU/GPU 프레임 시간, 버퍼 업로드, GPU 메모리, 프레임 안정성을 함께 측정해야 한다.

아직 전환하지 않는 편이 나은 경우

MDN은 현재 WebGPU를 Limited availability로 표시하며 API는 HTTPS 보안 컨텍스트에서만 동작한다. Three.js도 WebGPURenderer가 실험 단계라고 명시한다. 일부 기능이 없거나 특정 장면에서 WebGLRenderer가 더 빠를 수 있다.

• ShaderMaterial, onBeforeCompile, 기존 EffectComposer에 크게 의존한다면 WebGLRenderer를 유지한다.
• 주요 사용자 기기의 WebGPU 및 WebGL 2 폴백을 검증하지 않았다면 전체 전환을 미룬다.
• 동일한 장면, 기기, 해상도, 화질로 벤치마크하기 전에는 성능 향상을 약속하지 않는다.

위험을 낮춘 마이그레이션 순서

1. 병목이 측정된 대표 장면을 선택한다.
2. 모든 머티리얼을 바꾸기 전에 three/webgpu와 WebGPURenderer를 먼저 연결한다.
3. TSL로 옮겨야 할 ShaderMaterial, onBeforeCompile, 후처리 코드를 목록화한다.
4. 동일 조건에서 WebGPU, WebGL 2 폴백, 기존 WebGLRenderer를 비교한다.
5. 프레임 시간, 메모리, 기기 범위가 제품 기준을 충족할 때만 전환 범위를 넓힌다.

결론

• WebGPURenderer는 새로운 렌더러 아키텍처이지 FPS 스위치가 아니다.
• TSL은 여러 백엔드에서 머티리얼과 후처리를 공유하는 기반이다.
• 큰 데이터를 GPU에 유지하고 처리할 때 컴퓨트의 가치가 커진다.
• WebGL 2 폴백도 별도의 제품 타깃처럼 테스트해야 한다.
• 기대만으로 전체 전환하기보다 측정 가능한 PoC부터 시작하는 편이 안전하다.