Dawn 엔진의 스레드 안전성 강화라는 거대한 내부 수술이 진행되는 동안, 외부에서는 WebGPU의 성공이 또 다른, 예상치 못한 영역과의 충돌을 만들어내고 있었다. 이번의 충돌 지점은 웹 플랫폼의 가장 오래되고 기본적인 구성 요소 중 하나인, 이미지(<img>)와 비디오(<video>) 태그였다.
문제는 한 대형 소셜 미디어 회사의 웹 프론트엔드 팀에서 시작되었다.
그들은 사용자가 업로드한 이미지나 동영상에, WebGPU를 이용해 실시간으로 필터를 적용하고, 스티커를 붙이는 기능을 개발하고 있었다.
팀의 리드 개발자, ‘진’이 드미트리에게 기술적인 어려움을 토로했다.
“드미트리, 저희는 지금 데이터 복사라는 보이지 않는 벽에 갇혀 있습니다. 성능이 발목을 잡히고 있어요.”
그녀가 설명하는 문제는 이러했다.
HTML의 <img>나 <video> 엘리먼트를 WebGPU에서 텍스처로 사용하려면, 먼저 그 내용을 캔버스 2D 컨텍스트에 그린 다음, 그 캔버스의 내용을 다시 WebGPU 텍스처로 복사해야 하는, 여러 단계를 거쳐야 했다.
이미지/비디오
-> (CPU 디코딩) -> CPU 메모리
-> (캔버스 2D) -> GPU 텍스처(A)
-> (WebGPU 복사) -> GPU 텍스처(B)
이 과정, 특히 여러 번의 메모리 복사는 매 프레임마다 엄청난 오버헤드를 유발했다.
“저희는 단지 이미지에 필터를 적용하고 싶을 뿐인데, 마치 물건을 옆방으로 옮기기 위해 도시 전체를 한 바퀴 돌아가는 기분입니다. GPU 메모리 안에 있는 이미지/비디오 텍스처에, WebGPU가 직접 접근할 수 있는 방법은 정말 없는 건가요?”
그녀의 질문은, 웹 플랫폼의 오래된 칸막이들을 향한 근본적인 도전이었다.
<img>, <video> 태그가 렌더링되는 방식은 브라우저의 전통적인 HTML 렌더링 파이프라인에 깊숙이 묶여 있었다.
반면 WebGPU는 완전히 독립적이고 새로운 그래픽스 파이프라인 위에서 동작했다.
두 개의 다른 세계 사이에, 보이지 않는 벽이 존재하고 있었던 것이다.
드미트리는 이 문제가 단순히 성능을 넘어, 웹의 ‘상호운용성(Interoperability)’에 대한 중요한 질문임을 깨달았다. 새로운 기술인 WebGPU가, 어떻게 기존의 낡은 웹 기술들과 자연스럽게 통합될 수 있는가?
그는 이 문제를 해결하기 위해, HTML과 DOM 표준을 다루는 WHATWG(Web Hypertext Application Technology Working Group)와, WebGPU 워킹 그룹의 공동 회의를 주선했다.
이것은 서로 다른 언어와 문화를 가진 두 거대 조직의 첫 만남과도 같았다.
회의는 초반부터 난항을 겪었다.
HTML 측 전문가들은 보안과 안정성을 최우선으로 생각했다.
“웹 페이지의 핵심인 이미지와 비디오 리소스에, WebGPU와 같은 저수준 API가 직접 접근하도록 허용하는 것은 너무 위험합니다. 수많은 잠재적인 보안 취약점을 만들 수 있습니다.”
WebGPU 측 전문가들은 성능과 유연성을 강조했다.
“불필요한 데이터 복사야말로 웹 성능의 가장 큰 적입니다. 우리는 제로-카피(Zero-Copy)에 가까운 방식으로, 두 세계가 데이터를 공유할 수 있는 다리를 놓아야 합니다.”
팽팽한 긴장 속에서, 드미트리는 두 세계를 모두 만족시킬 수 있는 중재안을 제시했다.
그는 ‘외부 텍스처(External Texture)’라는 새로운 개념을 도입하자고 제안했다.
“WebGPU는 이미지나 비디오의 원본 메모리에 직접 접근하지 않습니다. 대신, 브라우저가 제공하는 특별한 ‘외부 텍스처’ 객체를 가져오는 겁니다. 이 객체는 실제 텍스처 데이터에 대한 일종의 ‘읽기 전용 참조’와 같습니다.”
그는 새로운 API의 모습을 그렸다.
const externalTexture = device.importExternalTexture({
source: htmlImageElement,
});
개발자는 이 externalTexture를 Bind Group에 바인딩하여, 셰이더 안에서 일반 텍스처처럼 샘플링할 수 있다.
하지만 이 텍스처에 데이터를 쓰는 것은 불가능하다. 또한, 이 텍스처의 데이터는 YUV와 같은 비디오 코덱 고유의 색상 포맷으로 되어 있을 수 있으며, 셰이더 안에서 RGB로 변환하는 작업이 필요할 수도 있다.
이 제안은 양쪽 모두를 만족시키는 영리한 타협이었다.
보안 측면에서는, WebGPU가 원본 데이터를 수정할 수 없으므로 안전했다.
성능 측면에서는, 브라우저가 내부적으로 GPU의 텍스처 공유 메커니즘을 활용하여 불필요한 메모리 복사를 최소화할 수 있었다.
이 ‘외부 텍스처’ 제안은 두 워킹 그룹의 긴밀한 협력을 통해 점차 구체화되기 시작했다.
이것은 단순히 API 하나를 추가하는 것이 아니었다.
그것은 브라우저의 가장 오래된 구역과 가장 새로운 구역을 잇는, 새로운 다리를 건설하는 대역사였다.
드미트리는 이 과정을 지켜보며, 플랫폼의 진화가 때로는 가장 빛나는 첨단 기술이 아니라, 가장 낡고 평범해 보이는 것들과 어떻게 관계를 맺느냐에 달려있다는 것을 배우고 있었다.
그는 이제, 새로운 영토를 개척하는 것을 넘어, 기존에 존재하던 여러 개의 다른 대륙들을 연결하여, 데이터가 자유롭게 흐르는 하나의 거대한 판게아(Pangaea)를 꿈꾸는, 지도를 다시 그리는 지리학자가 되어 있었다.
