오리진 트라이얼이 낳은 피드백의 폭풍 속에서, 드미트리는 한 가지 사실을 명확히 깨달았다. 개별 개발자들이나 소규모 팀이 보내오는 버그 리포트도 중요했지만, WebGPU가 진정한 시험대에 오르기 위해서는 더 큰 존재들의 참여가 절실했다. 바로 웹 3D 생태계를 양분하고 있는 두 개의 거대한 기둥, Babylon.js와 Three.js였다.
이 두 라이브러리는 수많은 웹 개발자들이 3D 그래픽을 구현하기 위해 사용하는 사실상의 표준이었다. 만약 이들이 WebGPU를 지원하지 않는다면, WebGPU는 소수의 전문가를 위한 난해한 기술로 전락할 위험이 있었다. 반대로 이들이 동참한다면, 수십만 개발자들이 간접적으로 WebGPU의 힘을 사용하게 되는, 생태계 확장의 기폭제가 될 것이었다.
문제는 그 과정이 결코 간단치 않다는 점이었다.
Babylon.js와 Three.js는 모두 WebGL의 아키텍처 위에 수년간 공들여 쌓아 올린 정교한 성채와 같았다. 그들의 렌더링 엔진 중심에는 WebGL의 ‘상태 기계’ 모델이 깊숙이 자리 잡고 있었다.
드미트리는 팀 회의에서 이 문제를 설명했다.
“이 라이브러리들은 렌더링 루프 안에서 객체의 재질(Material)에 따라 실시간으로 WebGL의 상태를 바꿉니다. gl.enable(BLEND), gl.depthFunc(LESS)… 이런 식으로요. 하지만 우리의 WebGPU는 파이프라인이라는 ‘불변의 청사진’을 미리 만들어두고 사용하는 방식입니다. 패러다임 자체가 다릅니다. 단순히 렌더러(Renderer) 일부를 교체하는 수준이 아니라, 엔진의 심장부를 들어내는 대수술이 필요한 작업입니다.”
그것은 마치 잘 달리던 가솔린 자동차의 엔진을 전기 모터로 바꾸는 것과 같았다. 단순히 엔진만 바꾼다고 해결될 일이 아니었다. 배터리 위치, 동력 전달 방식, 냉각 시스템 등 모든 것을 새로 설계해야 했다.
가장 먼저 움직인 것은 Babylon.js 팀이었다. 그들은 기술적 도전에 적극적이기로 유명했다. Babylon.js의 리더, 세바스티앙(Sébastien Vandenberghe)과 그의 팀은 구글의 Dawn 팀과 긴밀한 소통 채널을 열었다.
첫 번째 화상 회의. 화면 너머로 Babylon.js 팀의 진지한 얼굴들이 보였다.
“WebGPU의 가능성에 크게 기대하고 있습니다. 저희는 이미 렌더러 재설계에 착수했습니다.”
세바스티앙의 목소리에는 자신감이 넘쳤다. 하지만 그는 곧바로 현실적인 난관을 털어놓았다.
“가장 큰 고민은 파이프라인 관리입니다. 저희 라이브러리는 수백, 수천 가지의 다른 재질 조합을 지원합니다. 만약 모든 조합에 대해 개별적인 파이프라인 객체를 생성한다면, 메모리 사용량이 폭발하고 파이프라인 생성에 따른 초기 로딩 시간이 길어질 겁니다. 어떻게 효율적으로 파이프라인을 캐싱하고 재사용할 수 있을까요?”
이것은 드미트리의 팀이 미처 깊게 고민하지 못했던, 실제 대규모 애플리케이션의 관점에서 나온 날카로운 질문이었다. 그들은 지금까지 API의 기능 구현 자체에 집중해왔다.
드미트리는 즉시 답했다.
“훌륭한 지적입니다. 저희도 그 부분에 대한 모범 사례(Best Practice)를 고민해야겠습니다. 예를 들어, 셰이더 코드만 다른 파이프라인들은 레이아웃을 공유하게 하거나, 동적으로 일부 상태를 변경할 수 있는 제한적인 기능을 추가하는 방안도 검토해 볼 수 있겠습니다.”
이 회의는 일방적인 피드백 세션이 아니었다. 거대한 라이브러리를 만드는 이들의 현실적인 고민은 Dawn 팀에게 새로운 과제를 안겨주었고, API의 부족한 부분을 채우고 개발자 편의성을 높이는 방향으로 사양을 개선하는 계기가 되었다.
Three.js 커뮤니티 역시 조용하지만 꾸준히 움직이고 있었다. Three.js의 창시자, 리카르도(Ricardo Cabello, mrdoob)를 중심으로 한 핵심 기여자들은 WebGPU 렌더러를 실험적으로 구현하기 시작했다. 그들은 더 많은 객체를 그릴 때 발생하는 Bind Group 생성의 번거로움과, WebGL에 비해 늘어난 초기 설정 코드의 복잡성에 대한 구체적인 피드백을 깃허브 이슈로 남겼다.
얼마 후, Babylon.js 팀으로부터 놀라운 소식이 전해졌다.
“저희의 대표 데모인 ‘스폰자(Sponza)’ 씬을 WebGPU로 렌더링하는 데 성공했습니다.”
드미트리와 팀원들은 떨리는 마음으로 링크를 클릭했다. 화면에는 고대 건축물을 정교하게 묘사한 스폰자 씬이 나타났다. WebGL 버전과 겉모습은 똑같았다. 하지만 결정적인 차이가 있었다.
성능 분석 도구를 열자, CPU 사용률 그래프가 거짓말처럼 바닥에 붙어 있었다. 수많은 광원과 복잡한 재질에도 불구하고 프레임 속도는 흔들림 없이 60을 유지했다. WebGPU의 힘이 비로소 대중적인 라이브러리를 통해 그 위력을 증명하는 순간이었다.
두 개의 거대한 기둥이 움직이기 시작했다. 그들의 동참은 WebGPU가 더 이상 구글이나 모질라만의 프로젝트가 아님을 선언하는 것과 같았다. 웹 3D 생태계 전체가 다음 시대로 나아가기 위해 함께 힘을 모으기 시작한 것이다. 드미트리는 이제 WebGPU가 거친 파도를 넘어, 넓은 바다로 나아갈 수 있으리라는 강한 확신을 느꼈다.
