2026년 웹 게임 기술 스택

웹 게임을 구동하는 기술은 세 가지, WebGL, WebGPU, WebAssembly입니다. 2026년 고성능 브라우저 게임을 위한 최고의 현대적 스택은 WebGL2와 WebGPU를 모두 지원하는 렌더러(Three.js 또는 Babylon.js), 물리 연산을 위한 Wasm(Rapier), 그리고 정적 호스팅을 조합하는 것입니다. WebGPU를 지원하는 약 87%의 브라우저에서는 WebGPU를 사용하고, 나머지에서는 WebGL2로 대응하는 방식입니다. 각 기술은 서로 다른 문제를 해결하며 서로 다른 트레이드오프를 갖습니다. 이 가이드는 화제성이 아니라 실제로 만들고 있는 것을 기준으로 선택할 수 있도록 도와드리며, 브라우저 지원 현황은 2026년 9월 기준으로 확인했습니다.

빠른 답

WebGL 2.0은 어디서나 동작하며 대부분의 게임을 무리 없이 처리합니다. 특히 모바일에서 폭넓은 호환성이 필요할 때 사용하세요. WebGPU는 컴퓨트 셰이더와 더 나은 성능을 제공하지만, 구형 브라우저와 기기의 사용자를 잃게 됩니다. WebAssembly는 CPU 코드를 더 빠르게 만들어주므로 물리 연산이나 경로 탐색에 유용하지만, 병목이 GPU에 있다면 도움이 되지 않습니다.

2026년 대부분의 게임은 WebGL을 기본으로 배포하고, 지원 가능한 브라우저에서는 선택적으로 WebGPU를 사용합니다. Wasm은 게임 전체가 아니라 성능이 중요한 핵심 코드 경로에만 선별적으로 사용됩니다.

WebGL 2.0: 지루하지만 확실한 선택

WebGL 2.0은 2017년부터 안정적으로 사용되어 왔습니다. 모든 최신 브라우저가 이를 지원합니다. 여러분의 게임은 5년 이상 전 버전까지 거슬러 올라가는 Chrome, Firefox, Safari, Edge에서 동작합니다. iOS Safari 15+, Chrome for Android, Samsung Internet에서도 작동하며, Xbox Edge나 PlayStation 브라우저 같은 콘솔 브라우저에서도 실행됩니다.

기본적인 WebGL 2 설정은 다음과 같습니다.

const canvas = document.getElementById('game');
const gl = canvas.getContext('webgl2');

if (!gl) {
  // Fallback to WebGL 1 or show error
  const gl1 = canvas.getContext('webgl');
  if (!gl1) {
    showError('Your browser does not support WebGL.');
    return;
  }
}

// Now you have a GL context
gl.clearColor(0.1, 0.1, 0.1, 1.0);
gl.clear(gl.COLOR_BUFFER_BIT);

얻을 수 있는 것

WebGL 2는 인스턴스 렌더링을 제공하여 단 한 번의 드로우 콜로 수천 개의 오브젝트를 그릴 수 있습니다. GPU 측 파티클 시스템과 시뮬레이션을 위한 트랜스폼 피드백도 있습니다. 지연 렌더링과 G-버퍼를 위한 다중 렌더 타겟, 볼류메트릭 효과를 위한 3D 텍스처, 정밀한 데이터 저장을 위한 정수 텍스처도 사용할 수 있습니다.

gl.drawArraysInstanced(gl.TRIANGLES, 0, vertexCount, instanceCount);

얻을 수 없는 것

범용 GPU 연산을 위한 컴퓨트 셰이더는 실행할 수 없습니다. 바인드리스 텍스처도 없어서 텍스처 유닛 개수에 제약을 받습니다. 영구 매핑이나 명시적 메모리 제어도 불가능하며, 메시 셰이더나 최신 지오메트리 파이프라인도 지원되지 않습니다.

대부분의 2D 게임과 많은 3D 게임에서는 이러한 제약이 문제가 되지 않습니다. WebGL 2는 지금까지 가장 성공한 웹 게임들을 여럿 배출했습니다.

WebGPU: 더 필요할 때

WebGPU는 최신 GPU가 실제로 작동하는 방식을 기반으로 설계되었습니다. Chrome은 2023년 5월에 이를 출시했고, 2025년 말에는 모든 주요 브라우저가 이를 지원하게 되었습니다. Chrome 113+, Safari 26+, Edge 113+ 모두 동작하며, Firefox는 Windows에서 141버전(2025년 7월부터), Apple Silicon macOS에서는 145버전에서 활성화했고, Linux와 Android는 아직 순차적으로 배포 중입니다. Chrome Android는 최신 기기에서 지원하며, iOS Safari 26+도 지원합니다.

2026년 9월 기준 지원 현황은 gpuweb 구현 상태 페이지와 각 브라우저의 릴리스 노트를 참고했습니다.

브라우저	기본적으로 지원	아직 미지원
Chrome / Edge	Windows, macOS, ChromeOS에서 113+. Linux는 144버전(Intel Gen12+)과 147버전(Wayland의 NVIDIA)부터. Chrome for Android는 Android 12+에서 121+	Windows on ARM(플래그 뒤에 숨김)
Safari	macOS Tahoe, iOS, iPadOS, visionOS에서 26(WebKit 기준, 2025년 9월)	구형 macOS 버전
Firefox	Windows에서 141(2025년 7월), Apple Silicon Mac(macOS 26)에서 145, Apple Silicon 기반 모든 macOS 버전에서 147(2026년 1월)	Linux와 Android(Nightly 전용, Linux는 2026년 목표)
Samsung Internet	24+

caniuse 집계 기준으로 전 세계 페이지 뷰의 약 87%에 해당하며, 이 때문에 엔진들도 흐름을 따라가고 있습니다. Unity 6.6(2026년 8월)은 WebGL2 자동 폴백을 갖춘 정식 지원 웹 그래픽스 API로 WebGPU를 채택했으며, Three.js r185와 Babylon.js 9.25는 모두 자체적으로 폴백하는 WebGPU 렌더러를 갖추고 있고, PlayCanvas 2.22는 성숙한 WebGPU 경로를 제공하며, Godot 4.7과 Phaser 4는 브라우저에서 여전히 WebGL2 전용입니다. 렌더링 트레이드오프에 대해서는 게임용 WebGPU vs WebGL 가이드를 참고하시고, 특정 기기가 무엇을 지원하는지 확인하려면 WebGL/WebGPU 체커를 실행해보세요.

문제는 나머지 기기와 브라우저에는 이 기능이 없다는 것이므로, 폴백 전략이 필요합니다.

얻을 수 있는 것

컴퓨트 셰이더를 사용하면 물리 연산, 파티클, AI, 이미지 처리를 위한 범용 GPU 연산을 실행할 수 있습니다.

// A compute shader that processes data in parallel
const computeShaderCode = `
@group(0) @binding(0) var<storage, read_write> data: array<f32>;

@compute @workgroup_size(64)
fn main(@builtin(global_invocation_id) id: vec3<u32>) {
  data[id.x] = data[id.x] * 2.0;
}
`;

또한 성능적으로 예측하기 어려운 문제를 줄여주는 명시적 리소스 관리, 반복 사용을 위해 드로우 콜을 미리 기록해두는 렌더 번들, 그리고 C 언어를 흉내 낸 방식이 아니라 GPU를 위해 설계된 현대적 셰이더 언어인 WGSL도 함께 사용할 수 있습니다.

실전 WebGPU 설정

WebGL 폴백과 함께 WebGPU를 초기화하는 방법은 다음과 같습니다.

async function initGraphics(canvas) {
  // Try WebGPU first
  if (navigator.gpu) {
    const adapter = await navigator.gpu.requestAdapter();
    if (adapter) {
      const device = await adapter.requestDevice();
      const context = canvas.getContext('webgpu');
      
      context.configure({
        device,
        format: navigator.gpu.getPreferredCanvasFormat(),
      });
      
      return { type: 'webgpu', device, context };
    }
  }
  
  // Fall back to WebGL 2
  const gl = canvas.getContext('webgl2');
  if (gl) {
    return { type: 'webgl2', gl };
  }
  
  // Last resort: WebGL 1
  const gl1 = canvas.getContext('webgl');
  if (gl1) {
    return { type: 'webgl', gl: gl1 };
  }
  
  throw new Error('No graphics API available');
}

실제로 도움이 되는 경우

WebGPU는 CPU 왕복 없이 수백만 개의 파티클을 컴퓨트 셰이더로 갱신해야 할 때, GPU 가속 충돌 감지와 천 시뮬레이션이 필요할 때, 지형이나 텍스처, 메시를 절차적으로 생성할 때, SSAO나 블룸, 피사계 심도 같은 복잡한 후처리 효과를 사용할 때, 또는 NPC 행동이나 이미지 효과를 위해 학습된 모델을 구동할 때 진가를 발휘합니다.

퍼즐 게임이나 비주얼 노벨을 만드는 중이라면 WebGPU는 도움이 되지 않습니다. 파티클이 많은 액션 게임이나 복잡한 3D 월드를 만드는 중이라면 호환성 트레이드오프를 감수할 가치가 있을 수 있습니다.

WebAssembly: 빠른 CPU 코드

WebAssembly는 컴파일된 코드를 네이티브에 가까운 속도로 실행합니다. 그래픽에 관한 것이 아니라, CPU 코드를 더 빠르게 만드는 것에 관한 이야기입니다.

도움이 되는 경우

Wasm은 물리 엔진(Box2D, Bullet, Rapier 모두 Wasm 빌드를 제공합니다), 큰 그리드에서의 경로 탐색, 에셋 압축 해제, 구형 게임 콘솔 에뮬레이션, 기존 C++이나 Rust 코드베이스를 웹으로 이식하는 작업에 잘 어울립니다.

도움이 되지 않는 경우

GPU는 드로우 콜이 JavaScript에서 왔는지 Wasm에서 왔는지 신경 쓰지 않으므로 렌더링이 빨라지지는 않습니다. 에셋 가져오기나 네트워크 요청 같은 I/O 바운드 코드도 이득을 보지 못합니다. 그리고 여러분의 JavaScript가 이미 1밀리초 이내로 실행되고 있다면, Wasm이 이를 더 개선해주지는 않습니다.

실전 Wasm 예제

다음은 물리 연산을 위해 Wasm으로 컴파일한 최소한의 Rust 함수입니다.

// src/lib.rs
#[no_mangle]
pub extern "C" fn step_physics(dt: f32) {
    // Your physics code here
}

다음 명령으로 컴파일합니다.

wasm-pack build --target web

JavaScript에서 사용하는 방법은 다음과 같습니다.

import init, { step_physics } from './physics_bg.wasm';

await init();

function gameLoop(dt) {
  step_physics(dt); // Runs at near-native speed
  render();
  requestAnimationFrame(gameLoop);
}

스레딩은 복잡해진다

Wasm은 병렬 처리를 위해 스레드를 사용할 수 있지만, 이를 위해서는 SharedArrayBuffer가 필요하며 이는 곧 서버에 교차 출처 격리 헤더를 설정해야 한다는 의미입니다.

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp

이 헤더들은 여러 가지를 망가뜨립니다. CORP 헤더가 없는 서드파티 iframe이 동작을 멈추고, 일부 분석 스크립트가 깨지며, OAuth 팝업이 실패할 수 있습니다. require-corp 대신 credentialless를 사용하면 피해를 줄일 수 있지만, 여전히 까다로운 부분입니다. 이런 헤더를 설정할 수 없는 공유 호스팅이나 itch.io 환경이라면 Wasm 스레드를 사용할 수 없습니다. 다만 단일 스레드 Wasm은 여전히 문제없이 작동합니다.

실제 게임을 위한 실전 결정

2D 플랫포머를 만든다면 Phaser나 PixiJS 같은 라이브러리를 통해 WebGL 2를 사용하세요. WebGPU는 과할 뿐이니 건너뛰고, JavaScript만으로도 2D 물리 연산에 충분히 빠르니 Wasm도 건너뛰세요. 최신 기능보다 폭넓은 호환성이 더 중요하며, 병목은 기술이 아니라 콘텐츠입니다.

3D 오픈 월드를 만든다면 WebGL 2로 시작하되 WebGPU로 업그레이드할 수 있는 구조로 설계하세요. Rapier나 Bullet을 이용한 물리 연산에 Wasm을 고려해보세요. 지금은 최대한 넓은 도달 범위가 필요하지만, 나중에는 컴퓨트 셰이더가 초목, 파티클, LOD 처리에 도움이 될 것입니다. 물리 연산을 Wasm에 맡기면 CPU 예산을 낮게 유지할 수 있습니다.

C++ 엔진을 포팅하는 중이라면 Emscripten을 통한 Wasm을 사용하세요. 그래픽은 기본적으로 WebGL 2이며, 엔진이 지원한다면 WebGPU를 쓸 수 있습니다. 이미 코드가 있으니 Emscripten이 변환을 처리해줍니다.

퍼즐 게임을 만든다면 Canvas 2D나 Phaser를 통한 WebGL 2를 사용하세요. 그 외에는 다 건너뛰세요. 단순한 게임은 단순하게 유지되어야 합니다.

최대 성능이 절대적으로 필요하고 구형 브라우저 사용자를 일부 잃어도 괜찮다면 WebGPU와 Wasm 조합을 선택하세요. 다만 결정하기 전에 실제 사용자층에 미치는 영향을 반드시 측정해보세요.

실제로 게임을 빠르게 만드는 요소

웹 게임이 잘 작동하는지를 결정하는 요소를 중요도 순으로 정리했습니다.

체감 성능의 절반가량은 에셋 크기가 좌우합니다. 1초 만에 로드되는 2MB짜리 게임은 FPS가 더 좋더라도 50MB짜리 게임보다 더 빠르게 느껴집니다. 모든 것을 압축하고, 3D 모델의 경우 glTF 최적화 도구를 사용하면 Meshopt 압축과 텍스처 크기 조정을 한 번에 처리할 수 있습니다. 가능한 부분은 지연 로딩(lazy-load)하세요.

드로우 콜은 3D 게임에서 상당히 중요하며, 성능 예산의 약 30%를 차지합니다. 지오메트리를 배칭하고, 텍스처 아틀라스를 사용하고, 반복되는 오브젝트는 인스턴싱하세요. 이는 WebGL이냐 WebGPU냐보다 훨씬 더 큰 영향을 미칩니다.

JavaScript 성능은 아마 15% 정도를 차지합니다. 핫 루프에서의 할당을 피하고, 타입드 배열을 사용하고, 최적화하기 전에 먼저 프로파일링하세요.

그래픽 API 선택은? 솔직히 말하면 아마 5% 정도입니다. 대부분의 게임에서 API 자체보다 어떻게 사용하느냐가 더 중요합니다.

게임이 느리다면 먼저 처음부터 너무 많은 것을 로드하고 있지는 않은지 확인하세요. 그다음 드로우 콜을 너무 많이 발생시키고 있지는 않은지 확인하세요. 그다음 게임 루프 안에서 JavaScript가 뭔가 비효율적인 일을 하고 있지는 않은지 확인하세요. 이 모든 걸 확인한 후에야 다른 그래픽 API가 도움이 될지 물어봐야 합니다.

제가 실제로 사용할 스택

오늘 새로운 웹 게임을 시작한다면, 렌더링에는 Three.js(r185, 2026년 7월)나 Babylon.js(9.x)를 사용하겠습니다. WebGL과 WebGPU를 추상화해주기 때문입니다. 물리 연산에는 3D 물리가 필요하면 Rapier(러스트를 Wasm으로 컴파일한 것)를, 더 단순한 게임이라면 엔진에 내장된 2D 물리를 사용하겠습니다. 오디오는 Howler.js나 Web Audio API를 직접 사용하겠습니다. 빌드 도구는 Vite를 사용하겠는데, 개발 중에는 빠르고 프로덕션 빌드 품질도 좋기 때문입니다. 그리고 호스팅은 Netlify, Vercel, GitHub Pages, itch.io 같은 정적 호스팅을 사용하겠습니다.

이 스택은 WebGPU가 기본값이 될 때를 대비하면서도, 지금 당장 98% 이상의 기기에서 작동하는 게임을 만들어냅니다.

확정하기 전에 테스트하세요

기술 스택을 확정하기 전에 작은 프로토타입을 만들어 실제로 테스트해보세요. Chrome DevTools의 스로틀링 기능으로 3G 환경에서의 로딩 시간을 확인하세요. 느린 연결 환경에서도 5초 안에 게임을 플레이할 수 있어야 합니다. 저사양 안드로이드 폰에서 성능을 테스트하세요. 직접 빌려서 쓰거나 BrowserStack을 이용하면 됩니다. 그 기기에서 돌아간다면 어디서든 돌아갑니다. Safari에서도 반드시 테스트하세요. 다른 브라우저와 충분히 달라서 예상치 못한 문제가 생길 수 있습니다. 그리고 Newgrounds나 Kongregate에 게임을 올릴 예정이라면 iframe 안에서도 테스트하세요.

이런 테스트들은 WebGL과 WebGPU 중 무엇을 쓸지 논쟁하는 것보다 실제 문제를 훨씬 더 많이 잡아냅니다.

자주 묻는 질문

고성능 브라우저 게임을 위한 최고의 최신 기술 스택은 무엇인가요?

두 API를 모두 지원하는 렌더러, CPU가 병목인 부분에는 Wasm, 그리고 작은 빌드가 정답입니다. 구체적으로는 Three.js나 Babylon.js(WebGPU와 자동 WebGL2 폴백), 3D 물리를 위해 Wasm으로 컴파일된 Rapier, 사운드를 위한 Howler.js나 순수 Web Audio, 빌드용 Vite, 에셋을 위한 KTX2 텍스처와 Meshopt로 압축된 glTF, 그리고 CDN 뒤에서 서비스되는 정적 호스팅을 사용하세요. 완전한 엔진에서 시작하고 싶다면 PlayCanvas와 Unity 6.6 모두 폴백이 포함된 WebGPU를 제공하며, Godot는 작은 WebGL2 빌드를 제공합니다. 웹 게임 엔진 비교에서 빌드 크기와 로딩 시간 기준으로 모든 엔진의 순위를 확인할 수 있습니다.

2026년에도 WebGL을 사용할 가치가 있나요?

네, 여전히 기본값입니다. WebGL 2.0은 여러분의 플레이어가 소유한 모든 브라우저와 기기에서 작동합니다. 리눅스와 안드로이드용 Firefox 빌드, 그리고 아직 WebGPU가 없는 구형 폰들도 포함해서 말이죠. WebGPU가 출시되었다고 해서 WebGL 빌드가 작동을 멈추는 것은 전혀 아니며, 2D 게임과 대부분의 3D 게임에서 WebGL2는 애초에 병목이었던 적이 없습니다. WebGL2로 출시하고, 렌더러가 무료로 제공하는 부분에서만 WebGPU를 업그레이드로 추가하고, 나머지 노력은 에셋 크기와 드로우 콜에 쏟으세요.

WebGPU로 단순한 게임을 만들 수 있나요?

가능은 하지만, 그럴 필요가 거의 없습니다. 퍼즐 게임, 플랫포머, 카드 게임은 WebGPU에서든 WebGL2에서든 성능 차이가 나지 않으며, 오히려 아직 WebGPU를 지원하지 않는 브라우저의 플레이어를 잃게 됩니다. 단순한 게임에서 WebGPU가 제 몫을 하는 경우는 단 하나의 효과에 컴퓨트가 필요할 때입니다. 수천 개의 파티클, 유체나 천 시뮬레이션 토이, GPU 기반 군중 처리 같은 경우죠. 이런 경우에는 순수 WebGPU 코드를 직접 작성하기보다 자동으로 폴백을 처리해주는 라이브러리(Three.js나 Babylon.js)를 사용하거나, 게임을 설명하면 Cinevva가 WebGPU로 직접 만들어드립니다. 순수 API를 다루고 싶다면 저희 WebGPU 시작하기 튜토리얼을 참고하세요.

더 읽어보기

웹 게임 엔진 비교에서는 처음부터 직접 만들고 싶지 않은 경우를 위한 완전한 엔진들을 다룹니다. 브라우저에서의 Three.js + USDC에서는 Three.js에서 USD 에셋을 불러오는 방법을 보여줍니다. itch.io에 출시하는 방법에서는 무언가를 완성한 후 배포하는 방법을 다룹니다.

각 API를 더 깊이 다루는 실습 튜토리얼:

• 게임 개발자를 위한 WebGL 기초: 셰이더, 버퍼, 텍스처, 렌더 루프
• WebGPU 시작하기: 디바이스 설정, 파이프라인, WGSL 셰이더
• 게임 로직을 위한 웹 워커: 작업을 백그라운드 스레드로 넘기기
• COOP/COEP와 SharedArrayBuffer: Wasm 스레딩에 필요한 헤더
• 게임 물리 라이브러리: Rapier, Cannon-es, Ammo.js, Matter.js 등

올바른 기술 스택이란 여러분의 게임을 실제로 출시할 수 있는 스택입니다. 아는 것을 선택하고, 일찍 테스트하고, 최적화는 나중에 하세요.

지금 바로 해보세요스택 고민은 건너뛰고 결과만 얻으세요

WebGL, 물리 연산, 에셋 파이프라인까지 모두 처리됩니다. 여러분은 게임을 설명하기만 하면 됩니다.

무료로 만들기 →무료입니다. 설치 없이 브라우저에서 바로 실행됩니다.