부채널 공격의 위협에 대한 방어벽을 쌓는 동안, WebGPU 커뮤니티의 다른 한편에서는 조용하지만 의미 있는 변화가 일어나고 있었다. 그것은 그래픽 기술의 최전선이 아닌, 웹의 가장 기본적인 구성 요소인 HTML과의 관계에 대한 논의였다.
논의의 시작은 한 웹 프레임워크 개발자가 올린 깃허브 이슈였다.
“현재 WebGPU를 사용하려면, HTML에 반드시 <canvas> 엘리먼트를 추가해야 합니다. 하지만 저희 프레임워크는 모든 UI를 자바스크립트 객체로 추상화하여 관리합니다. 개발자가 직접 DOM을 조작하는 것을 지양하죠. 캔버스를 화면에 직접 추가하지 않고, 메모리상에서만 WebGPU 렌더링을 수행한 뒤, 그 결과를 다른 UI 요소와 합성할 수 있는 방법이 없을까요?”
이 질문은 ‘헤드리스 WebGPU’와는 미묘하게 다른 문제였다. 헤드리스는 아예 시각적 출력이 없는 서버 사이드 렌더링을 위한 것이었다. 하지만 이 개발자는 시각적 출력을 원했다. 단지 그 출력이 전통적인 캔버스 엘리먼트에 묶여있지 않기를 바랐을 뿐이다.
이 이슈는 곧바로 수많은 ‘+1’과 공감의 댓글을 받았다.
“맞습니다. WebGL 시절부터 이 문제는 항상 골칫거리였습니다.”
“리액트(React)나 뷰(Vue) 같은 현대적인 프레임워크 환경에서는, 캔버스를 DOM의 특별한 존재가 아니라 다른 컴포넌트처럼 다룰 수 있기를 바랍니다.”
드미트리는 이 흐름을 예의주시했다. 이것은 단순히 개발자의 편의성 문제를 넘어, WebGPU가 낡은 웹의 유산에서 벗어나, 현대적인 웹 아키텍처와 어떻게 통합될 것인가에 대한 근본적인 질문이었다.
W3C 회의.
드미트리는 이 문제를 공식 안건으로 상정했다.
“우리는 캔버스와 WebGPU의 결합 방식을 재고해야 합니다. 현재의 canvas.getContext('webgpu') 방식은 너무 경직되어 있습니다.”
애플의 딘 잭슨이 즉시 반응했다. 그는 이 분야에 대해 깊은 고민을 해 온 듯했다.
“저희도 같은 생각을 하고 있었습니다. 캔버스는 단지 픽셀을 담는 그릇일 뿐입니다. 그 그릇에 그림을 그리는 화가(WebGPU 렌더러)는 독립적인 존재여야 합니다. 저희는 GPUCanvasContext라는 객체를 분리해내는 아이디어를 제안합니다.”
그의 제안은 혁신적이었다.
기존 방식:
const context = canvas.getContext('webgpu');
// context가 생성되자마자 바로 사용 가능했음
// 별도의 설정 단계 없이 즉시 렌더링 가능
새로운 방식:
const context = canvas.getContext('webgpu');
// context 생성 후 반드시 configure() 단계가 필요
const presentationFormat = navigator.gpu.getPreferredCanvasFormat();
context.configure({
device,
format: presentationFormat,
alphaMode: 'premultiplied',
});
// 이제 context 사용 가능
얼핏 보면 비슷해 보이지만, 결정적인 차이가 있었다.
configure라는 새로운 단계가 추가된 것이다. 이제 컨텍스트는 생성되자마자 바로 사용할 수 있는 것이 아니라, 어떤 GPUDevice를 사용하여, 어떤 텍스처 포맷으로 그림을 그릴지를 명시적으로 ‘설정(configure)’해주어야 했다.
드미트리가 그 의미를 즉시 파악하고 부연 설명했다.
“이것은 엄청난 유연성을 가져다줍니다. 개발자는 이제 렌더링 도중에라도 context.configure()를 다시 호출해서, 렌더링에 사용할 디바이스나 텍스처 포맷을 동적으로 바꿀 수 있게 됩니다. 예를 들어, 사용자가 고성능 GPU와 저전력 GPU 사이를 전환할 때, 페이지를 새로고침할 필요 없이 렌더링 컨텍스트를 재설정할 수 있게 되는 거죠.”
더 나아가, 이 구조는 캔버스의 역할을 근본적으로 바꾸었다.
이제 캔버스는 더 이상 렌더링의 주체가 아니었다. getCurrentTexture()라는 함수를 통해, 매 프레임마다 그림을 그릴 수 있는 ‘빈 텍스처’를 제공해주는 역할만 하게 된다. 개발자는 이 빈 텍스처를 받아, 다른 일반 텍스처에 그림을 그리듯이 WebGPU 명령을 실행하면 된다. 렌더링이 끝나면, 브라우저가 알아서 이 텍스처를 화면에 표시(Present)해준다.
캔버스는 렌더링 엔진에서 ‘렌더 타겟 제공자’로 역할이 격하된 것이다.
이 제안은 큰 반대 없이 커뮤니티의 폭넓은 지지를 얻었다.
API의 이름과 세부 옵션에 대한 약간의 논쟁이 있었지만, 캔버스와 렌더링 로직을 분리한다는 핵심 철학에는 모두가 동의했다.
Dawn 팀과 wgpu 팀은 즉시 이 새로운 컨텍스트 모델의 구현에 착수했다.
이것은 단순히 함수 몇 개를 바꾸는 작업이 아니었다. 브라우저의 컴포지터(Compositor)가 캔버스 텍스처를 처리하고 화면에 합성하는 방식까지 손대야 하는, 깊숙한 곳의 수술이었다.
몇 달 후, 새로운 캔버스 모델이 적용된 크롬 카나리 버전이 배포되었다.
겉으로 보기에는 아무것도 달라지지 않았다. 하지만 웹 프레임워크 개발자들은 즉시 그 변화를 환영했다.
한 리액트 라이브러리 개발자가 트위터에 글을 올렸다.
“새로운 WebGPU 캔버스 모델 덕분에, 이제 3D 씬을 다른 UI 컴포넌트처럼 완벽하게 캡슐화할 수 있게 되었습니다. 캔버스가 더 이상 특별한 존재가 아닙니다. 이것이야말로 진정한 컴포넌트 기반 아키텍처입니다.”
드미트리는 그 글을 보며, 자신들이 또 하나의 보이지 않는 벽을 허물었음을 느꼈다.
그들은 WebGPU를 낡은 DOM의 제약으로부터 해방시켜, 현대적인 웹의 흐름 속으로 자연스럽게 흘러 들어가게 만든 것이다. 이것은 화려한 3D 데모보다 더 조용했지만, 웹 플랫폼의 진화라는 관점에서는 그 무엇보다도 의미 있는 진보였다.
