붉은 삼각형의 감격은 오래가지 않았다. 그것은 단지 첫 번째 이정표일 뿐, WebGPU가 꿈꾸는 세상은 단순히 그림을 더 빨리 그리는 것에 머물지 않았기 때문이다. NXT 프로젝트의 설계 초기부터, 드미트리와 뜻을 같이하는 이들의 머릿속에는 훨씬 더 거대한 야망이 자리 잡고 있었다.
그것은 바로 GPGPU (General-Purpose computing on Graphics Processing Units). 즉, GPU를 범용 계산에 활용하는 것이었다.
W3C 커뮤니티 그룹의 한 미팅.
드미트리는 새로운 의제를 제시했다.
“이제 ‘컴퓨트 셰이더(Compute Shader)’에 대한 논의를 본격적으로 시작해야 합니다.”
그의 말에 회의에 참석한 엔지니어들의 눈빛이 달라졌다. 지금까지의 논의는 ‘렌더 파이프라인’, 즉 화면에 무언가를 그리는 과정에 집중되어 있었다. 하지만 컴퓨트 셰이더는 차원이 다른 이야기였다.
컴퓨트 셰이더는 정점이나 픽셀 같은 그래픽스 개념에 얽매이지 않는다. 그것은 순수하게 GPU의 막강한 병렬 처리 능력을 이용해 대규모 데이터를 계산하기 위한 도구였다. 수천, 수만 개의 코어를 가진 GPU에게 복잡한 수학 문제를 던져주고, 동시에 풀어내게 하는 것.
한 개발자가 질문했다.
“웹에서 GPGPU가 왜 그렇게 중요합니까? 대부분의 웹 애플리케이션은 렌더링 성능만으로도 충분하지 않나요?”
드미트리가 대답했다.
“웹의 미래는 단순히 문서를 보여주는 것을 넘어, 사용자의 기기에서 직접 강력한 연산을 수행하는 방향으로 나아가고 있습니다. 사진 필터링, 실시간 영상 처리, 물리 시뮬레이션, 그리고… 머신러닝.”
머신러닝.
그 단어가 나오는 순간, 회의장의 공기가 미묘하게 바뀌었다. 2010년대 후반, AI의 바람은 이미 실리콘밸리를 강타하고 있었다. 거대한 데이터센터에서나 가능했던 신경망 연산이 점차 개인 기기로 내려오고 있었다.
“상상해 보십시오. 개발자들이 별도의 서버 없이, 사용자의 브라우저 안에서 직접 이미지 인식 모델이나 간단한 언어 모델을 실행할 수 있게 된다면. 개인정보를 서버로 전송할 필요도 없이, 즉각적인 피드백을 제공할 수 있습니다. 웹의 가능성이 완전히 새로운 차원으로 확장되는 겁니다.”
이것이 WebGPU의 숨겨진 야망이었다. 단순히 ‘더 빠른 WebGL’이 아니라, 웹 브라우저를 그래픽과 AI 연산을 위한 새로운 컴퓨팅 플랫폼으로 격상시키는 것.
하지만 이 강력한 힘에는 그만큼의 책임과 위험이 따랐다.
브라우저 보안팀의 대표가 즉시 우려를 표했다.
“컴퓨트 셰이더는 렌더 파이프라인보다 훨씬 위험합니다. 그래픽스와 무관한 데이터에 접근하고 연산할 수 있다는 의미니까요. 만약 악의적인 코드가 컴퓨트 셰이더를 이용해 다른 탭의 픽셀 데이터를 훔쳐보거나, 시스템의 민감한 정보를 유추하는 타이밍 공격을 시도한다면 어떻게 막을 겁니까?”
그의 지적은 날카롭고 현실적이었다. 무한한 자유는 무한한 위협이 될 수 있었다. 웹의 가장 중요한 가치인 ‘보안’과 ‘격리(Isolation)’ 원칙이 흔들릴 수 있는 중대한 문제였다.
논쟁은 격렬해졌다. 컴퓨트 셰이더의 API를 어떻게 설계해야 하는가?
렌더링과 마찬가지로 별도의 ‘컴퓨트 파이프라인’을 만들어야 한다는 데에는 의견이 일치했다. createComputePipelineAsync. 그러나 어떤 기능을 허용하고, 어떤 기능을 제한할 것인지를 두고 의견이 팽팽히 맞섰다.
- 데이터 접근은 어떻게 제한할 것인가? Bind Group을 통해 명시적으로 할당된 버퍼에만 접근하도록 엄격히 통제해야 한다.
- 실행 시간은 어떻게 통제할 것인가? 악의적인 셰이더가 무한 루프에 빠져 GPU를 마비시키는 것을 막기 위해, 브라우저가 강제로 실행을 중단시킬 수 있는 ‘타임아웃’ 메커니즘이 필요하다.
드미트리와 동료들은 보안팀의 요구사항을 하나씩 API 설계에 녹여내기 시작했다. 강력한 힘을 제공하되, 그 힘이 오남용되지 않도록 견고한 안전장치를 겹겹이 두르는 작업이었다.
Dawn 프로젝트 팀은 이 논의를 바탕으로 컴퓨트 셰이더의 프로토타입 구현에 착수했다.
이번 목표는 삼각형이 아니었다. 거대한 행렬 두 개를 곱하는, 순수한 수학 연산이었다.
벤이 새로운 WGSL 코드를 작성했다.
@group(0) @binding(0) var<storage, read> A: mat4x4<f32>;
@group(0) @binding(1) var<storage, read> B: mat4x4<f32>;
@group(0) @binding(2) var<storage, write> C: mat4x4<f32>;
@compute @workgroup_size(1)
fn main() {
C = A * B;
}
두 개의 입력 행렬(A, B)을 받아 곱한 뒤, 결과 행렬(C)에 저장하는 간단한 코드.
그들은 이 연산을 수백만 번 반복 실행하고, 순수 자바스크립트로 실행했을 때와 시간을 비교했다.
결과는 압도적이었다. GPU의 병렬 처리 능력 덕분에, WebGPU를 이용한 연산 속도는 수십, 수백 배나 빨랐다.
모니터에 찍힌 결과 숫자를 보며 드미트리는 확신했다.
WebGPU는 이제 막 그래픽스라는 껍질을 깨고, 웹을 위한 범용 고성능 컴퓨팅 엔진이라는 본모습을 드러내기 시작했다. 삼각형은 시작일 뿐이었다. 진짜 혁명은 이제부터였다.
