안드로이드의 파편화된 세계에 질서를 부여하려는 Dawn 팀의 노력은 점차 결실을 보고 있었다. requestAdapterInfo와 같은 새로운 API 제안은 개발자들에게 좋은 반응을 얻었고, 그들은 이제 모바일 환경의 다양성에 더 지능적으로 대응할 수 있게 되었다. 팀은 이제 WebGPU가 마주할 다음 도전은 무엇일지, 장기적인 성능 최적화 계획을 논의하고 있었다.
그들의 예측 가능한 미래에, 전혀 다른 차원의 질문이 던져졌다.
질문은 한 통의 내부 메일에서 시작되었다. 발신인은 구글 클라우드 플랫폼(GCP)의 데이터 시각화 서비스팀이었다.
팀 회의실. 드미트리는 클라우드 팀의 리드 엔지니어, 데이비드를 화상으로 마주하고 있었다. 데이비드의 표정에는 해결되지 않은 기술적 난제에 대한 고민이 깊게 서려 있었다.
“데이비드, 저희가 도울 일이 있다고 들었습니다.”
드미트리가 먼저 입을 열었다.
데이비드는 고개를 끄덕이며 화면에 복잡한 금융 데이터 차트를 띄웠다.
“저희 서비스는 고객의 데이터를 바탕으로 이런 복잡한 차트와 보고서를 이미지 파일로 생성해서 제공합니다. 문제는 이 이미지 생성 작업이 전부 서버의 CPU 위에서 이루어진다는 겁니다. 고객 요청이 몰리는 시간에는, 수천, 수만 개의 이미지를 생성하기 위해 엄청난 양의 서버 자원이 소모됩니다. 비용도 비용이지만, 속도가 너무 느려서 고객 경험을 해치고 있죠.”
그는 잠시 말을 멈추고, 드미트리를 똑바로 바라보았다.
“그래서 저희 팀에서 미친 아이디어가 하나 나왔습니다. 만약… 이 이미지 렌더링 작업을 서버의 GPU로 옮길 수 있다면? 그리고 만약… 이때 WebGPU를 사용할 수 있다면 어떨까요?”
그의 질문에 Dawn 팀의 회의실에는 미묘한 정적이 흘렀다.
카이가 조심스럽게 대답했다.
“매우 흥미로운 아이디어입니다만, 데이비드. WebGPU는 이름 그대로 ‘웹’을 위한 API입니다. 브라우저 환경에서, HTML의 <canvas> 엘리먼트에 그림을 그리기 위해 설계되었죠. 서버에는 브라우저도, 캔버스도 없지 않습니까?”
기술적으로는 완벽하게 맞는 말이었다. WebGPU의 모든 초기화 과정은 navigator.gpu 객체에서 시작하여, 최종적으로는 캔버스의 렌더링 컨텍스트에 연결되는 구조였다.
데이비드는 실망한 기색을 감추지 못했다.
“역시 그런가요… 하지만 저희가 WebGPU에 주목한 이유가 있습니다. 저희 고객 중 일부는 웹 애플리케이션 안에서 실시간으로 차트를 조작하기도 합니다. 만약 클라이언트(브라우저)에서 차트를 그리는 렌더링 코드와, 서버에서 이미지를 생성하는 렌더링 코드를 WebGPU로 통일할 수만 있다면… 코드 재사용성과 개발 효율성이 극적으로 향상될 겁니다. 같은 WGSL 셰이더를 양쪽에서 그대로 쓸 수 있으니까요.”
‘하나의 코드로, 클라이언트와 서버 양쪽에서.’
그 말이 드미트리의 뇌리에 박혔다.
그는 지금까지 WebGPU를 항상 ‘사용자에게 보여지는’ 그래픽을 위한 기술로만 생각해왔다. 하지만 데이비드는 전혀 다른 관점을 제시하고 있었다. 최종 결과물이 화면이 아니라, 파일이나 메모리 버퍼가 되는 시나리오.
드미트리는 눈을 감았다. 그의 머릿속에서 Dawn의 아키텍처가 빠르게 재구성되기 시작했다. GPUDevice를 얻는 과정, 파이프라인을 생성하는 과정, 컴퓨트 셰이더를 실행하는 과정… 그 어떤 핵심 로직도 본질적으로 ‘화면’에 종속되어 있지 않았다. 캔버스는 단지 렌더링 결과물을 내보내는 여러 ‘출력 장치’ 중 하나일 뿐이었다.
그는 눈을 떴다. 그의 눈빛이 달라져 있었다.
“데이비드. 당신의 아이디어는 미친 게 아닙니다. 어쩌면 그게 WebGPU의 궁극적인 진화 방향일지도 모릅니다.”
그는 팀원들을 돌아보며 말했다.
“우리는 지금까지 캔버스라는 창문을 통해서만 GPU를 바라봤어. 하지만 만약, 그 창문이 없어도 GPU의 작업실로 들어갈 수 있는 뒷문이 있다면?”
이것은 API의 철학을 뒤흔드는 발상이었다.
‘헤드리스(Headless) WebGPU’.
어떤 시각적인 인터페이스도 없이, 순수하게 계산과 렌더링 능력만을 사용하기 위해 GPU에 접근하는 방식.
벤이 반문했다.
“하지만 그걸 구현하려면 Dawn의 초기화 로직을 대대적으로 수정해야 합니다. 캔버스 컨텍스트에 의존하는 모든 부분을 분리해내야 하죠. 이건 완전히 새로운 기능을 만드는 것과 같습니다. 우리의 로드맵에 없던 일입니다.”
“그럼 지금부터 로드맵에 추가하면 돼.”
드미트리의 목소리는 단호했다.
“이것은 단순한 기능 추가가 아니야. 이것은 WebGPU의 영토를 브라우저의 프론트엔드를 넘어, 서버와 백엔드, 그리고 모든 종류의 자동화된 시스템으로 확장하는 일이다. 우리가 이 문을 열지 않으면, 언젠가 다른 누군가가 비슷한 목적의 비표준 라이브러리를 만들게 될 거야. 플랫폼의 미래를 위해서라면, 이 길은 우리가 직접 열어야 해.”
그의 설득에 팀의 분위기가 바뀌었다. 이것은 더 이상 클라우드 팀의 문제를 해결해주는 지원 업무가 아니었다. WebGPU라는 플랫폼 자체의 운명을 결정할 중대한 분기점이었다.
그날 오후, 드미트리는 Dawn 프로젝트의 코드 저장소에 새로운 이슈를 등록했다.
제목: [Feature] Support for headless/windowless device creation
이슈 내용은 단 한 줄이었다.
Investigate the feasibility of creating a GPUDevice without an associated canvas or presentation context.
그 한 줄의 문장이, WebGPU를 시각 예술의 도구에서 보편적인 컴퓨팅 유틸리티로 변모시킬, 거대한 여정의 시작을 알리고 있었다.
