WebGL vs WebGPU: 지금 새로 시작한다면 어느 쪽으로 가야 하나

같은 화면을 그리는 두 세대의 API

브라우저에서 GPU를 쓰는 방법이 지금 두 가지입니다. 오랫동안 표준이었던 WebGL과, 그 뒤에 나온 WebGPU입니다. 새 프로젝트를 시작하는 입장에서는 "이제 WebGPU로 가면 되나"가 궁금할 텐데, 답은 무엇을 만드느냐에 따라 갈립니다.

두 API는 성능 차이 이전에 설계 세대가 다릅니다. 그 차이를 먼저 이해하면 선택이 쉬워집니다.

WebGL은 상태 기계, WebGPU는 명시적 객체

WebGL은 OpenGL ES를 웹에 옮긴 API입니다. 전역 상태를 바꿔가며 그립니다. "지금 이 버퍼를 바인딩하고, 이 셰이더를 쓰고, 그려라" 하는 식이라 순서와 현재 상태에 결과가 좌우됩니다.

gl.bindBuffer(gl.ARRAY_BUFFER, buffer);
gl.useProgram(program);
gl.drawArrays(gl.TRIANGLES, 0, 3);

이 방식은 배우기 쉬운 대신 두 가지 대가가 있습니다. 상태가 어디서 바뀌었는지 추적하기 어려워 규모가 커지면 디버깅이 힘들어지고, 매 드로우 콜마다 드라이버가 상태를 검증하느라 CPU 비용이 붙습니다.

WebGPU는 이 구조를 뒤집었습니다. 렌더 파이프라인, 바인드 그룹 같은 객체를 미리 만들어 검증을 끝내두고, 실제 그리기는 커맨드 인코더에 명령을 담아 한 번에 제출합니다. Vulkan·Metal·D3D12 같은 최신 네이티브 API가 택한 방식과 같습니다.

초기 코드가 길어지는 대신, 매 프레임 반복되는 구간에서 CPU가 할 일이 줄어듭니다. 그려야 할 객체가 많아질 때 차이가 드러나는 지점입니다.

결정적 차이는 컴퓨트 셰이더

성능 수치보다 실질적인 차이는 이쪽입니다. WebGPU에는 컴퓨트 셰이더가 있고 WebGL에는 없습니다.

WebGL에서 GPU로 범용 계산을 하려면 데이터를 텍스처에 밀어넣고 프래그먼트 셰이더로 그리는 척하면서 결과를 다시 텍스처에서 읽는 우회를 써야 했습니다. WebGPU는 계산 전용 파이프라인을 제공하므로 이런 우회가 필요 없습니다.

입자 수만 개의 물리 시뮬레이션, 이미지·영상 처리, 브라우저에서 도는 머신러닝 추론처럼 "그리기가 아니라 계산"이 목적인 작업이라면 이것만으로 WebGPU를 고를 이유가 됩니다.

셰이더 언어도 다릅니다. WebGL은 GLSL ES, WebGPU는 WGSL을 씁니다. 기존 GLSL 셰이더를 그대로 옮길 수는 없습니다.

지원 환경이 선택을 가른다

WebGL은 사실상 모든 최신 브라우저에서 동작합니다. 아주 오래된 기기까지 포함하면 WebGL 2가 아닌 WebGL 1로 폴백해야 하는 경우가 남아 있지만, 웹 그래픽의 기본값이라고 봐도 됩니다.

WebGPU는 2023년 Chrome을 시작으로 순차 도입되어 지원 범위가 계속 넓어지고 있습니다. 다만 브라우저·OS·기기 조합에 따라 여전히 쓸 수 없는 환경이 있습니다. 지원 여부는 시점에 따라 바뀌므로 이 글의 서술이 아니라 배포 시점에 직접 확인하는 편이 정확합니다. caniuse 같은 자료를 보거나, 실행 시점에 감지하는 방법이 있습니다.

const hasWebGPU = "gpu" in navigator && !!(await navigator.gpu?.requestAdapter());

공개용 프로젝트라면 감지 후 WebGL로 폴백하는 경로를 반드시 준비해야 합니다. 폴백이 없으면 일부 방문자에게는 그냥 검은 화면입니다.

대부분은 라이브러리로 해결된다

직접 API를 다룰 필요가 없는 경우도 많습니다. Three.js와 Babylon.js 같은 라이브러리는 WebGPU 렌더러를 별도로 제공합니다. 씬 구성 코드는 그대로 두고 렌더러만 교체하는 구조라, 지원 환경에 따라 런타임에 고르는 방식도 가능합니다.

즉 라이브러리를 쓴다면 "WebGL이냐 WebGPU냐"를 지금 확정하지 않아도 됩니다. 나중에 바꿀 여지를 남긴 채 시작할 수 있습니다. 단, 커스텀 셰이더를 직접 작성했다면 GLSL과 WGSL 양쪽을 준비해야 하므로 그만큼 짐이 늘어납니다.

어느 쪽으로 시작할까

WebGL로 시작하는 편이 나은 경우

• 3D 모델을 보여주는 정도의 일반적인 시각화·게임
• 방문자 환경을 가릴 수 없는 공개 서비스
• 참고 자료와 예제가 많이 필요한 학습 단계

WebGPU를 고를 만한 경우

• 컴퓨트 셰이더가 필요한 작업(대량 파티클, 시뮬레이션, 추론)
• 드로우 콜이 많아 CPU가 병목이 된 프로젝트
• 사내 도구처럼 실행 환경을 통제할 수 있는 경우

양쪽 다 준비하는 경우

• 라이브러리를 쓰면서 렌더러만 감지해 교체하는 구성

WebGPU가 WebGL보다 항상 빠른가요?

아닙니다. 병목이 어디냐에 달려 있습니다. GPU 연산 자체가 한계인 장면은 API를 바꿔도 크게 달라지지 않습니다. WebGPU가 이득을 주는 쪽은 드로우 콜이 많아 CPU가 먼저 막히는 경우, 그리고 컴퓨트로 처리하면 훨씬 유리한 작업입니다. 삼각형 몇 개 그리는 화면이라면 차이를 체감할 수 없습니다.

지금 WebGL로 만들면 나중에 다시 써야 하나요?

렌더링 계층은 다시 써야 합니다. 다만 라이브러리를 쓰고 있다면 교체 범위가 렌더러 설정과 커스텀 셰이더로 줄어듭니다. 직접 API를 다뤘다면 사실상 새로 쓰는 작업이 됩니다. 그래서 처음부터 렌더링 코드를 게임 로직·데이터와 분리해두는 것이 실질적인 대비입니다.

WebGL은 앞으로 없어지나요?

가까운 시일에 사라질 가능성은 낮습니다. 이미 배포된 웹 콘텐츠 상당수가 WebGL에 의존하고 있어서, 브라우저가 지원을 끊기 어렵습니다. 새로 만드는 것에 WebGPU를 권하는 흐름과, 기존 WebGL이 계속 동작하는 것은 별개의 문제로 보는 편이 맞습니다.

판단은 실제 장면에서

두 API의 차이는 문서로 읽으면 추상적이고, 같은 장면을 양쪽으로 만들어보면 구체적입니다. 특히 드로우 콜 수를 늘려가며 프레임을 재보면 어디서 갈리는지가 눈에 보입니다.

만든 결과물이 브라우저에서 돌아가는 상태라면 Vibeollio에 프로젝트 등록해서 공개해보세요. 그래픽 작업은 기기와 브라우저에 따라 결과가 크게 다른데, 여러 환경의 방문자가 직접 실행해보고 남기는 반응이 내 기기 한 대에서 재본 수치보다 정확합니다.