프롤로그 — 2026년, 웹 3D는 다시 한 번 다시 태어났다

2023년 4월, Chrome 113이 WebGPU를 기본 활성화했을 때만 해도 "또 다른 표준 전쟁"으로 보였다. WebGL 2가 충분히 잘 돌고 있었고, WebGPU는 사파리·파이어폭스에서 플래그 뒤에 있었으며, Three.js는 "WebGPURenderer"를 실험적으로 붙여놓고 있었다.

3년이 지난 2026년 5월, 풍경은 완전히 달라졌다.

- WebGPU는 Chrome·Edge·Firefox·Safari 26에서 기본으로 켜져 있다. 글로벌 커버리지 약 95%.

- Three.js r182가 `WebGPURenderer`를 권장 렌더러로 올렸다. 기존 `WebGLRenderer`는 폴백.

- Babylon.js 8이 WebGPU를 1급 시민으로 다룬다. Microsoft 후원, IndexedDB 셰이더 캐시·자동 폴백.

- PlayCanvas는 Snap 인수(2024년 6월) 이후 Snapdragon AR과 깊게 묶이면서도 오픈소스 엔진을 계속 발전시키고 있다.

- TresJS — Vue.js용 R3F. Needle Engine — Unity로 만든 씬을 glTF로 내보내 웹에서 돌린다.

- TSL(Three Shading Language)이 GLSL·WGSL을 한 벌로 묶고, WGSL 컴퓨트 셰이더가 브라우저에서 LLM·MediaPipe·whisper를 돌린다.

이 글은 2026년 5월 현재의 웹 그래픽 스택을 처음부터 끝까지 정리한다. WebGPU와 WebGL의 차이, Three.js·R3F·Babylon·PlayCanvas·TresJS·Needle의 선택 기준, WGSL의 핵심, 컴퓨트 셰이더로 ML을 돌리는 방법, 그리고 한·일 커뮤니티의 자료까지.

1장 · WebGL 2 vs WebGPU — 무엇이 달라졌나

먼저 한 줄로. **WebGL은 OpenGL ES 3.0의 자바스크립트 래퍼고, WebGPU는 Vulkan·Metal·DirectX 12를 추상한 새 API다.** 둘은 사상이 다르다.

| 항목 | WebGL 2 | WebGPU |

| --- | --- | --- |

| 출시 | 2017년 안정화 | 2023년 4월 Chrome 113 기본 |

| 기반 | OpenGL ES 3.0 | Vulkan/Metal/D3D12 추상 |

| 셰이더 언어 | GLSL ES 3.00 | WGSL |

| 컴퓨트 셰이더 | 없음 | 있음(1급) |

| 멀티스레드 큐 | 없음 | Command Encoder/Queue |

| 간접 디스패치 | 부분(인스턴싱만) | indirectDraw, indirectDispatch |

| 비동기 | 콜백 기반 | Promise 기반(맵핑·서밋) |

| 파이프라인 상태 | 글로벌 가변 | RenderPipeline 객체 |

| 텍스처 압축 | DXT/ETC/ASTC(부분) | BC/ETC2/ASTC(GPU별) |

| 디버깅 | Spector.js | Chrome DevTools WebGPU 패널 |

핵심 한 줄: **WebGL은 "그리기 위주", WebGPU는 "그리기 + 계산".** 컴퓨트 셰이더 하나가 모든 ML·시뮬레이션·이미지 후처리·파티클을 GPU에서 돌릴 수 있게 만들었다.

성능은 어떨까. 같은 씬을 두 API로 그렸을 때, 단순 래스터(폴리곤 그리기)는 비슷하다. CPU 오버헤드가 줄어드는 만큼 드로우 콜이 많을수록 WebGPU가 빠르다. 컴퓨트 위주의 작업(이미지 처리·ML 추론)에서는 2~3배가 일반적이다.

2장 · 브라우저 지원 현황 (2026년 5월 기준)

지원 표가 정리되면 의사결정이 쉬워진다.

- **Chrome/Edge** — 113+ 안정(2023.04). Android에서도 동일.

- **Firefox** — 121에서 데스크톱 기본 활성화 후, 2025년 안정화 완료.

- **Safari** — 17.4에서 macOS·iOS 베타로 시작, 26(2025.09 macOS Tahoe와 함께)에서 정식 출시.

- **모바일** — Chrome Android, Safari iOS 26 둘 다 기본 켜짐.

폴백은 단순하다.

if (navigator.gpu) {

// WebGPU 사용

const adapter = await navigator.gpu.requestAdapter()

const device = await adapter.requestDevice()

} else {

// WebGL 2 폴백

const gl = canvas.getContext('webgl2')

}

Three.js의 `WebGPURenderer`는 이 분기를 자동으로 처리한다. WebGPU가 없으면 `WebGLRenderer`로 떨어진다. 실무에서는 거의 신경 쓸 필요가 없다.

3장 · 네이티브 WebGPU — Dawn과 wgpu-rs

브라우저 안의 WebGPU 구현체는 둘 중 하나다.

- **Dawn** — 구글이 만든 C++ 라이브러리. Chromium의 WebGPU 구현 본체. 데스크톱 앱에서도 똑같은 코드로 쓸 수 있다(Skia·flutter가 채택).

- **wgpu-rs** — 모질라가 만든 러스트 라이브러리. Firefox·Servo·Bevy·Veloren 등이 채택. WebGPU 표준 그대로 데스크톱·모바일 네이티브로 돌린다.

핵심은 이거다. **WebGPU API는 브라우저 안에만 갇혀있지 않다.** Rust로 wgpu-rs, C++로 Dawn을 쓰면 같은 셰이더(WGSL)와 같은 API로 데스크톱·모바일 네이티브 앱을 만들 수 있다. WGSL은 이제 사실상 SPIR-V 위에 얹힌 표준 GPU 셰이더 언어다.

Bevy(러스트 게임 엔진)는 wgpu-rs를 기반으로 데스크톱·모바일·웹(WASM) 모두를 한 코드베이스로 타겟한다. "Write once, GPU anywhere"가 농담이 아니다.

4장 · WGSL — WebGPU Shading Language

GLSL을 알면 30분이면 익숙해진다. 문법만 다를 뿐 사상은 비슷하다.

가장 작은 정점 셰이더(WGSL):

struct VertexInput {

@location(0) position: vec3<f32>,

@location(1) color: vec3<f32>,

}

struct VertexOutput {

@builtin(position) clip_position: vec4<f32>,

@location(0) color: vec3<f32>,

}

@vertex

fn vs_main(in: VertexInput) -> VertexOutput {

var out: VertexOutput;

out.clip_position = vec4<f32>(in.position, 1.0);

out.color = in.color;

return out;

}

@fragment

fn fs_main(in: VertexOutput) -> @location(0) vec4<f32> {

return vec4<f32>(in.color, 1.0);

}

GLSL과의 차이를 한 줄씩.

- `@vertex`·`@fragment`·`@compute` — 함수 단위로 진입점을 표시한다. 한 파일에 정점·프래그먼트를 같이 둘 수 있다.

- `vec3<f32>` — 제네릭 타입. 정수·부동소수·정수를 명시한다. GLSL의 `vec3` 같은 암시적 부동소수가 없다.

- `@location(N)` — 입력/출력 슬롯. 정점 버퍼·프래그먼트 출력에 둘 다 쓴다.

- `@builtin(position)` — `gl_Position` 대응.

가장 큰 차이는 **컴퓨트 셰이더**.

@group(0) @binding(0) var<storage, read_write> data: array<f32>;

@compute @workgroup_size(64)

fn cs_main(@builtin(global_invocation_id) id: vec3<u32>) {

let i = id.x;

if (i < arrayLength(&data)) {

data[i] = data[i] * 2.0;

}

}

64개씩 묶어서 1차원 배열을 곱하기 2 하는 셰이더. ML·시뮬레이션·이미지 처리가 다 이 패턴이다.

5장 · Three.js와 TSL — 한 셰이더, 두 백엔드

Three.js는 npm 주간 다운로드가 270만이 넘는 웹 3D의 사실상 표준이다. r182(2025년 12월)에서 `WebGPURenderer`가 권장 렌더러로 올라갔다.

가장 작은 씬:

const scene = new THREE.Scene()

const camera = new THREE.PerspectiveCamera(75, w / h, 0.1, 1000)

camera.position.z = 5

const renderer = new WebGPURenderer({ antialias: true })

await renderer.init()

renderer.setSize(w, h)

document.body.appendChild(renderer.domElement)

const cube = new THREE.Mesh(

new THREE.BoxGeometry(1, 1, 1),

new THREE.MeshStandardMaterial({ color: 0x44aa88 })

)

scene.add(cube)

scene.add(new THREE.AmbientLight(0xffffff, 0.4))

const dir = new THREE.DirectionalLight(0xffffff, 1.0)

dir.position.set(5, 10, 7.5)

scene.add(dir)

renderer.setAnimationLoop(() => {

cube.rotation.y += 0.01

renderer.render(scene, camera)

})

WebGL과의 두 가지 차이.

1. `await renderer.init()` — WebGPU는 비동기 초기화가 필수다.

2. `setAnimationLoop` — `requestAnimationFrame` 대신 권장. WebXR도 같이 잡힌다.

TSL — Three Shading Language

Three.js 0.158부터 도입된 JS DSL. 한 번 짠 셰이더를 GLSL·WGSL 양쪽으로 컴파일한다.

const myColor = Fn(() => {

const t = sin(time.mul(2.0))

return vec3(uv().x, t, uv().y)

})

material.colorNode = myColor()

GLSL 코드를 직접 쓰지 않아도 셰이더 그래프가 만들어진다. WebGPU에선 WGSL로, WebGL에선 GLSL로 자동 변환된다. **2026년 현재, 새로 시작하는 셰이더는 TSL로 짜는 것을 권장한다.**

6장 · React Three Fiber + drei — React 트리에 3D 얹기

R3F는 Three.js를 React 컴포넌트로 표현한다. 명령형 코드가 50개 노드를 넘어가면 빠르게 누더기가 되는데, R3F는 그걸 React 트리로 깔끔하게 정리한다.

function Cube() {

return (

)

}

export default function Scene() {

return (

)

}

JSX 태그 `mesh`·`boxGeometry` 등은 Three.js의 클래스명에 매핑된다. `OrbitControls`·`Environment`는 **drei**(Poimandres 팀의 헬퍼)에서 온다. drei가 없으면 R3F는 절반의 가치다.

R3F v9의 WebGPU — 비동기 `gl` prop

gl={async (props) => {

const r = new WebGPURenderer(props)

await r.init()

return r

}}

>

{/* ...씬... */}

R3F v9이 비동기 팩토리를 받게 되면서, WebGPU 초기화가 React 라이프사이클에 자연스럽게 묶인다. 2026년 5월 현재 Poimandres 팀이 적극적으로 다듬는 중.

R3F 생태계의 헬퍼들

- **leva** — GUI(dat.gui의 React 버전).

- **zustand** — 씬 상태 관리(Redux 대안).

- **valtio** — 또 다른 상태 관리.

- **maath** — 3D 수학 헬퍼.

- **react-spring** — 애니메이션.

- **drei** — `OrbitControls`·`useGLTF`·`Html`·`Text`·`Sky`·`Sparkles`...

이 묶음이 모두 Poimandres라는 단일 OSS 컬렉티브에서 나온다. 한 사람이 짠 게 아니라 한 팀이 짠 거라는 게 R3F의 큰 강점이다.

7장 · Babylon.js 8 — Microsoft가 후원하는 풀스택 엔진

Babylon.js는 Three.js와 다른 사상이다. Three.js는 "라이브러리(부품)", Babylon은 "엔진(완성품)"이다.

차이를 보면 선택 기준이 분명해진다.

- **인스펙터** — Babylon은 처음부터 비주얼 인스펙터를 내장한다. `scene.debugLayer.show()` 한 줄로 씬 그래프·라이트·머티리얼을 GUI로 편집한다.

- **물리** — Havok·Cannon·Ammo 통합이 기본.

- **WebGPU** — Babylon은 2020년부터 WebGPU를 1급으로 다뤄왔다. 셰이더 캐시·자동 폴백·컴퓨트 셰이더 API가 잘 정리되어 있다.

- **PBR** — 물리 기반 렌더링 머티리얼이 매우 정교하다(Unreal·Unity 수준).

- **Playground** — `playground.babylonjs.com`에서 즉시 코드를 실행한다.

가장 작은 Babylon 씬:

const canvas = document.getElementById('renderCanvas')

const engine = new Engine(canvas, true, { preserveDrawingBuffer: true })

const scene = new Scene(engine)

const camera = new ArcRotateCamera('camera', -Math.PI / 2, Math.PI / 2.5, 5, Vector3.Zero(), scene)

camera.attachControl(canvas, true)

new HemisphericLight('light', new Vector3(0, 1, 0), scene)

MeshBuilder.CreateBox('box', { size: 1 }, scene)

engine.runRenderLoop(() => scene.render())

코드가 약간 더 명시적이고, 카메라가 처음부터 `ArcRotateCamera`(궤도 카메라)로 준비된다. Three.js라면 `OrbitControls`를 따로 붙여야 했다.

Babylon WebGPUEngine

WebGPU로 가려면 `Engine` 대신 `WebGPUEngine`을 쓴다.

const engine = new WebGPUEngine(canvas)

await engine.initAsync()

문법이 Three.js의 `await renderer.init()`과 거의 같다. WebGPU 셰이더 캐시(IndexedDB)는 Babylon이 더 잘 챙긴다. 큰 씬에서 첫 로딩이 빠르다.

선택 한 줄: **레퍼런스 사이트·R3F·작은 컴포넌트 위주면 Three.js. 게임·인스펙터·완성도 위주면 Babylon.js.**

8장 · PlayCanvas — 브라우저 에디터를 가진 게임 엔진

PlayCanvas는 다른 두 엔진과 결이 다르다. **브라우저 안에서 도는 비주얼 에디터**가 있다. 마치 Unity 에디터의 웹 버전 같다.

[브라우저 에디터: playcanvas.com]

│ (드래그&드롭)

▼

[씬·prefab·머티리얼·스크립트]

│

▼

[빌드 → CDN 호스팅 → <iframe> 임베드]

PlayCanvas Editor에서 씬을 만들면, 그게 바로 웹 게임이 된다. 별도 빌드 단계가 없다. 그래서 광고용 인터랙티브 3D·차량 컨피규레이터 같은 데서 압도적이다.

엔진 자체도 오픈소스(MIT). `playcanvas` npm 패키지로 코드만 써도 된다.

2024년 6월 Snap이 PlayCanvas를 인수했다. **Snapdragon Spaces·Snap Lens** 같은 AR 플랫폼과 묶이면서, 모바일 AR을 웹에서 돌리는 표준 엔진으로 자리잡고 있다. 인수 후에도 오픈소스 엔진은 계속 발전 중이다.

9장 · TresJS — Vue 진영의 R3F

Vue.js 개발자가 R3F를 부러워했다면, TresJS가 답이다. Three.js를 Vue 컴포넌트로 표현한다.

R3F의 `mesh` 대신 `TresMesh`, `boxGeometry` 대신 `TresBoxGeometry` — Vue가 PascalCase·접두사를 선호하기 때문. `@tresjs/cientos`가 R3F의 `drei`에 해당한다.

생태계 규모는 R3F의 1/10 정도지만, 핵심 기능은 다 있다. Nuxt 모듈도 있고, Vue 3 Composition API와 결이 잘 맞는다.

10장 · Needle Engine — Unity로 만들어서 웹에서 돌린다

Needle은 사상이 독특하다. **Unity 에디터로 씬을 만든 다음, glTF로 내보내서 웹에서 돌린다.**

[Unity 에디터]

│ (Needle 패키지 설치)

│ (Export glTF)

▼

[scene.glb] + [scripts.js]

│

▼

Three.js 위에 Unity의 컴포넌트 시스템을 얹은 것. Unity 측 C# 컴포넌트(`Transform`·`MeshRenderer`·`Light`)가 glTF의 확장으로 직렬화되고, 클라이언트의 JS 컴포넌트(`@needle-tools/engine`)가 그걸 복원한다.

장점: Unity의 거대한 에셋 생태계(애니메이션·셰이더 그래프·물리)를 그대로 웹으로 가져온다. WebXR도 함께. 단점: Unity가 필수다(에디터 빌드 ~10GB).

상업 라이선스가 분리되어 있어서, 인디·작은 팀은 무료에 가깝다. 큰 사이트(예: 코카콜라·LG 같은 마케팅 사이트)에 종종 보인다.

11장 · Wonderland Engine — WebXR 전용

Wonderland는 더 특화된 케이스. **WebXR(VR/AR)을 가장 잘 돌리는 엔진**이다.

- 자체 비주얼 에디터(데스크톱 앱).

- 매우 가벼움(엔진 코어 ~500KB).

- WebXR 최적화: 90fps 유지가 목표.

- Meta Quest·Vision Pro 브라우저에서 거의 네이티브 수준 성능.

VR 게임·트레이닝 시뮬레이터 만들 때 Three.js나 Babylon보다 한참 빠르다. 단점: 일반 3D 사이트엔 과한 도구.

12장 · Spline — 디자이너를 위한 Figma-for-3D

Spline은 코드를 안 쓰는 진영. 브라우저 안의 디자인 툴로 3D 씬을 만들고, 그걸 React 컴포넌트나 iframe으로 임베드한다.

export default function App() {

return <Spline scene="https://prod.spline.design/abc/scene.splinecode" />

}

랜딩 페이지·히어로 섹션의 인터랙티브 3D 일러스트가 주요 용도. 2025년부터 WebGPU 렌더링 옵션을 추가했다. 디자이너가 Figma 쓰듯이 3D를 만들 수 있다는 게 핵심.

13장 · PixiJS 8 — 2D면 PixiJS

3D만 다루다가 갑자기 2D가 필요하면? Canvas 2D API는 느리고, Three.js로 2D를 그리는 건 과하다. **PixiJS**가 그 자리다.

PixiJS 8(2024년 출시)이 WebGPU를 1급으로 다룬다. Three.js와 같이 자동 폴백(WebGL).

- 2D 스프라이트·UI·인터랙티브 광고.

- 게임 UI·HUD 오버레이.

- 차트·데이터 시각화 일부.

`deck.gl`(지리 시각화)·`PixiJS` 둘 다 Uber 영향권에서 시작했지만, PixiJS는 영국 OSS 커뮤니티 주도다.

14장 · Cesium — 3D 지구·지리정보

지구를 그리는 거대한 씬을 만들 때 — `Cesium`이다. **3D Tiles** 표준(OGC 표준화)을 만든 곳이기도 하다.

- Sentinel·NASA·OpenStreetMap 데이터 직접 로드.

- 위성·드론·LiDAR 메시 스트리밍.

- WebGL 2 기반, WebGPU 백엔드 작업 중.

NVIDIA Omniverse·Unreal Engine과 연동되는 산업용 도구. 정부 GIS·국방·도시 디지털 트윈에서 표준에 가깝다.

15장 · 컴퓨트 셰이더 + 브라우저 ML

WebGPU가 가져온 가장 큰 변화는 **컴퓨트**다. 브라우저에서 GPU 계산이 가능해지면서, ML 추론이 클라이언트로 내려왔다.

TensorFlow.js + WebGPU 백엔드

await tf.setBackend('webgpu')

await tf.ready()

const model = await tf.loadGraphModel('/model/model.json')

const output = model.predict(input)

WebGL 백엔드 대비 1.5~3배 빠르다. 작은 모델(MobileNet·BlazePose) 추론은 거의 네이티브에 근접.

ONNX Runtime Web + WebGPU

Microsoft가 만드는 ONNX 런타임의 웹 빌드. WebGPU EP(Execution Provider)가 안정화됐다.

const session = await ort.InferenceSession.create('model.onnx', {

executionProviders: ['webgpu'],

})

const output = await session.run({ input: inputTensor })

HuggingFace 모델 대부분이 ONNX로 export 가능. **`transformers.js`**(HF 공식)가 이걸 래핑한다.

const generator = await pipeline('text-generation', 'Xenova/gpt2', {

device: 'webgpu',

})

const out = await generator('Once upon a time', { max_new_tokens: 50 })

브라우저에서 GPT-2급 모델이 돈다. 작은 LLM은 이제 서버 없이 클라이언트에서 추론 가능하다.

WebLLM — 진짜 LLM을 브라우저에서

Carnegie Mellon의 MLC 팀이 만드는 프로젝트. Llama·Phi·Gemma 같은 진짜 LLM을 WebGPU로 돌린다.

const engine = await webllm.CreateMLCEngine('Llama-3.2-3B-Instruct-q4f16_1-MLC')

const reply = await engine.chat.completions.create({

messages: [{ role: 'user', content: '안녕' }],

})

3B~8B 모델까지는 M2/M3 맥에서 토큰당 20~40ms 정도. 그렇게 빠르진 않지만, **서버 호출 없이 동작하는 LLM**이라는 사실 자체가 의미 있다. 의료·법률처럼 데이터를 절대 서버로 보내면 안 되는 도메인에서 쓰임.

MediaPipe + WebGPU

Google의 MediaPipe(이미지·비디오 ML)도 WebGPU 백엔드를 가졌다. 얼굴 인식·손 추적·포즈 추정이 브라우저에서 60fps로 돈다.

whisper.cpp + WebGPU

OpenAI Whisper를 C++로 포팅한 `whisper.cpp`도 WebAssembly + WebGPU 빌드가 있다. 브라우저에서 음성 인식.

16장 · glTF — 3D의 PNG·JPG

3D 모델을 주고받을 때의 표준은 **glTF 2.0**(Khronos). JSON + 바이너리 버퍼 + PNG/JPG/KTX2 텍스처.

- `.gltf` — JSON, 분리된 에셋들 참조.

- `.glb` — 단일 바이너리. 웹에서 권장.

Three.js의 `GLTFLoader`, R3F의 `useGLTF`, Babylon의 `SceneLoader.Append` — 다 같은 포맷.

glTF 최적화 도구체인

gltf-transform — 가장 강력한 CLI

npx gltf-transform optimize input.glb output.glb

텍스처 압축

npx gltf-transform ktx2 input.glb output.glb

Draco/Meshopt 메시 압축

npx gltf-transform draco input.glb output.glb

`gltf-transform`은 사실상 표준이다. 1GB짜리 Blender export가 50MB로 줄어든다.

Basis Universal + KTX2

JPG/PNG는 CPU에서 압축이 풀려서 GPU로 올라간다. **KTX2(Basis Universal)**는 GPU 압축 포맷(BC7·ETC2·ASTC)으로 바로 업로드. GPU 메모리·로딩 속도 모두 줄어든다.

basisu CLI

basisu -ktx2 -uastc texture.png

gltf-transform이 자동으로 KTX2를 만든다

npx gltf-transform uastc input.glb output.glb

KTX2는 WebGL 2와 WebGPU 둘 다 지원. Three.js의 `KTX2Loader`로 로드.

17장 · 셰이더 라이브러리와 도구

GLSL/WGSL 셰이더를 처음부터 짜는 건 어렵다. 다음 자원이 답이다.

- **Three.js Shading Language(TSL)** — JS DSL. 위에서 다뤘다.

- **patapom WGSL collection** — GitHub의 WGSL 예제 모음.

- **Shadertoy** — GLSL 프래그먼트 셰이더의 본진. WGSL 포팅도 있다.

- **The Book of Shaders** — Patricio Gonzalez Vivo의 무료 책.

- **WebGPU Samples** — 구글 공식. `webgpu.github.io/webgpu-samples`

디버깅 도구

- **Chrome DevTools WebGPU 패널** — Chrome 119부터 내장. 셰이더 소스·파이프라인 상태·메모리 사용량.

- **Spector.js** — WebGL 전용. 프레임 캡처·드로우 콜별 분석.

- **RenderDoc** — 네이티브 GPU 디버거. wgpu-rs/Dawn 워크플로에 유용.

18장 · 사용 시나리오 — 어디에 무엇을 쓰나

- **포트폴리오 사이트 / 히어로 섹션** — R3F + drei. Spline도 좋다.

- **제품 컨피규레이터(자동차·가구)** — Three.js 또는 PlayCanvas. PBR 머티리얼이 중요해서 Babylon도 자주 선택.

- **데이터 시각화** — deck.gl(지리), Three.js + custom 셰이더(추상적 시각화).

- **브라우저 게임** — PlayCanvas, Babylon.js. 무거우면 Wonderland.

- **AR/VR(WebXR)** — Wonderland Engine, Needle Engine.

- **8thWall 스파셜 AR** — Niantic 8th Wall 플랫폼.

- **유니티 자산 재활용** — Needle Engine.

- **2D 게임·인터랙티브 광고** — PixiJS 8.

- **지구·지도 3D** — Cesium.

- **브라우저 ML** — transformers.js + WebGPU, WebLLM.

19장 · 크로스플랫폼 3D 엔진의 웹 타겟

웹 전용이 아닌, 데스크톱·모바일도 만드는 큰 엔진들도 웹을 타겟한다.

- **Unity WebGL** — 오래된 옵션. 빌드 크기가 큼(20MB+). **Unity WebGPU**가 실험적으로 추가됐다(2024).

- **Unreal Engine — Pixel Streaming** — 서버에서 렌더링해서 비디오로 스트리밍. WebRTC 기반. 무거운 씬을 모바일에서 보여줄 때.

- **Godot 4 — Web Export** — WebAssembly + WebGL 2. WebGPU는 4.4부터.

웹 네이티브 엔진(Three.js·Babylon·PlayCanvas) 대비 빌드 크기·시작 시간이 단점. 단, Unity·Unreal에 이미 작업이 있다면 Pixel Streaming이 가장 빠른 경로다.

20장 · 한국·일본 커뮤니티

웹 3D는 영어권 자원이 압도적이지만, 한·일 커뮤니티도 빠르게 자라고 있다.

**한국**:

- 한국 WebGL/WebGPU 사용자 모임 — 페이스북·디스코드 그룹.

- Three.js 한국어 번역 — `threejs.kr` 비공식 번역(커뮤니티 주도).

- 토스 프론트엔드 — `tossface`와 3D 인터랙션, SLASH 컨퍼런스 발표 다수.

- NAVER FE 토크 — Three.js·R3F 세션 정기.

**일본**:

- **ICS.media** — 일본 최대 프론트엔드 매거진. Three.js·WebGPU 튜토리얼이 압도적으로 많다.

- **Three.js Tokyo / 三.js Japan** — 정기 밋업.

- **池田 泰延(Yasunobu Ikeda)** — ICS.media 운영자. Three.js 책 다수 저술.

- **WebGL Total** — 일본어 WebGL 입문 사이트.

ICS.media는 영어로 번역되어도 손색 없는 수준의 글이 많다. 일본어가 어렵지 않다면 자주 들르는 걸 권한다.

21장 · 유명한 Three.js 사이트들

영감이 필요하면 다음 사이트들.

- **bruno-simon.com** — Three.js Journey 강사 Bruno Simon의 포트폴리오. 자동차로 사이트를 운전한다.

- **active-theory.com** — 인터랙티브 광고 에이전시. 자사 사이트 자체가 쇼케이스.

- **lusion.co** — 영국 에이전시. Three.js 마케팅 사이트의 정수.

- **rafa-marsala** / **igor-bachelard.com** — 개인 포트폴리오.

- **threejs.org/examples** — 200개+ 공식 예제. 새 기능이 여기 먼저 들어온다.

Bruno Simon의 **Three.js Journey** 강의(threejs-journey.com)는 사실상 표준 교재. 95개 챕터, 100시간+. 새로 시작한다면 무조건 추천.

22장 · 학습 로드맵 (실용 버전)

처음 시작한다면, 다음 순서.

1. **JS·웹 기본** — DOM·Canvas·`requestAnimationFrame`이 익숙해야 한다.

2. **Three.js 기초** — `threejs.org/manual` 또는 Three.js Journey 1~30장.

3. **첫 씬 만들기** — 큐브·라이트·OrbitControls·glTF 로드까지.

4. **R3F 입문** — Three.js를 이해한 다음에 R3F로 넘어가는 게 빠르다.

5. **셰이더(GLSL/TSL)** — `The Book of Shaders` 무료 책 + Shadertoy.

6. **WebGPU** — `webgpu.github.io`의 공식 튜토리얼.

7. **WGSL** — Google의 `WebGPU Samples`.

8. **특수 주제** — WebXR·glTF 최적화·컴퓨트 셰이더 중 필요한 것 선택.

평균 3~6개월이면 프로덕션 사이트를 짤 수 있는 수준이 된다.

23장 · 자주 묻는 질문 5개

**Q1. WebGL 2를 아직 배워야 하나?**

폴백 코드가 필요하다면 기본은 알아야 한다. 다만 새로 짜는 셰이더는 TSL 또는 WGSL로 가는 게 미래지향적.

**Q2. R3F vs 순수 Three.js?**

React 프로젝트면 R3F. 정적 사이트·바닐라 JS면 Three.js. 둘은 같은 엔진을 다른 식으로 쓰는 것이다.

**Q3. Babylon이 Three.js보다 좋은가?**

장단점이 다르다. Babylon은 완성도·인스펙터·물리·WebGPU 성숙도가 강점. Three.js는 생태계·문서·예제 수·취업 시장이 강점.

**Q4. PlayCanvas의 비주얼 에디터는 정말 쓸 만한가?**

마케팅 사이트·차량 컨피규레이터처럼 디자이너 손이 많이 가는 프로젝트에서 압도적이다. 코드 위주 프로젝트라면 굳이 안 써도 된다.

**Q5. 브라우저에서 LLM을 진짜 돌릴 수 있나?**

3B~8B까지는 실용 가능. 70B는 메모리·속도가 무리다. 작은 어시스턴트·코드 보조·번역 정도가 적합한 사이즈.

24장 · 마무리 — "한 번 짜면 어디서나 돈다"의 시대

2026년의 웹 3D는 세 가지 흐름이 합쳐졌다.

1. **WebGPU의 안착** — 95%의 사용자가 컴퓨트 셰이더를 쓸 수 있다.

2. **TSL의 등장** — 한 셰이더로 GLSL·WGSL을 둘 다 만든다.

3. **브라우저 ML의 일상화** — `transformers.js`·WebLLM·MediaPipe가 서버 없는 ML을 가능하게 했다.

이게 합쳐지면, **서버 없는 인터랙티브 3D + AI** 사이트가 현실이 된다. 사용자의 GPU를 빌려서 LLM·이미지 생성·실시간 3D를 동시에 돌린다. 서버 비용도, 레이턴시도, 프라이버시 우려도 0에 가깝다.

도구는 충분히 준비됐다. 남은 건 만드는 것이다. 한 줄의 좋은 셰이더, 한 장면의 씬, 한 페이지의 실험. 그게 모이면 다음 시대의 웹이 된다.

참고자료

- WebGPU 표준 — `https://www.w3.org/TR/webgpu/`

- WGSL 표준 — `https://www.w3.org/TR/WGSL/`

- WebGPU 사용 가능 여부 — `https://caniuse.com/webgpu`

- Three.js — `https://threejs.org/`

- Three.js Journey(Bruno Simon) — `https://threejs-journey.com/`

- TSL 문서 — `https://github.com/mrdoob/three.js/wiki/Three.js-Shading-Language`

- React Three Fiber — `https://r3f.docs.pmnd.rs/`

- drei — `https://github.com/pmndrs/drei`

- Poimandres 컬렉티브 — `https://pmnd.rs/`

- Babylon.js — `https://www.babylonjs.com/`

- Babylon.js Playground — `https://playground.babylonjs.com/`

- PlayCanvas — `https://playcanvas.com/`

- PlayCanvas Engine GitHub — `https://github.com/playcanvas/engine`

- TresJS — `https://tresjs.org/`

- Needle Engine — `https://needle.tools/`

- Wonderland Engine — `https://wonderlandengine.com/`

- Spline — `https://spline.design/`

- PixiJS — `https://pixijs.com/`

- Cesium — `https://cesium.com/`

- glTF 2.0 — `https://www.khronos.org/gltf/`

- gltf-transform — `https://gltf-transform.dev/`

- Basis Universal — `https://github.com/BinomialLLC/basis_universal`

- KTX 2.0 — `https://www.khronos.org/ktx/`

- Dawn (Chromium WebGPU) — `https://dawn.googlesource.com/dawn`

- wgpu-rs — `https://wgpu.rs/`

- TensorFlow.js — `https://www.tensorflow.org/js`

- ONNX Runtime Web — `https://onnxruntime.ai/docs/tutorials/web/`

- transformers.js — `https://huggingface.co/docs/transformers.js/`

- WebLLM (MLC) — `https://webllm.mlc.ai/`

- MediaPipe — `https://developers.google.com/mediapipe`

- WebGPU Samples — `https://webgpu.github.io/webgpu-samples/`

- The Book of Shaders — `https://thebookofshaders.com/`

- Shadertoy — `https://www.shadertoy.com/`

- ICS.media (일본) — `https://ics.media/`

- Khronos glTF Sample Models — `https://github.com/KhronosGroup/glTF-Sample-Assets`