폭풍 전의 목소리들

드미트리가 느낀 ‘보이지 않는 벽’은 그 혼자만의 감상이 아니었다. 그것은 실리콘밸리 전역에 조용히, 하지만 분명하게 퍼져나가는 공감대였다. 웹의 영광스러운 시대가 기술적 정체라는 암초에 부딪혔다는 위기감. 그 목소리는 가장 먼저 웹의 가능성을 최전선에서 밀어붙이던 이들에게서 터져 나왔다.

구글의 한 회의실.
대형 스크린에는 화려한 그래픽을 자랑하는 판타지 게임의 데모 영상이 재생되고 있었다. 거대한 용이 불을 뿜고, 수백의 병사가 격돌하는 장면. 네이티브 앱으로 실행했을 때, 이 장면은 영화와 같은 유려함을 뽐냈다.

“그리고 이것이 웹 버전입니다.”

발표를 맡은 유니티(Unity)의 엔지니어가 다음 슬라이드를 넘겼다. 똑같은 장면이 웹 브라우저 안에서 펼쳐졌다. 그러나 결과는 처참했다. 프레임은 뚝뚝 끊겼고, 용의 불길은 마치 종잇장이 펄럭이는 듯 어색했다. 회의실에 앉아있던 구글 직원들 사이에서 나직한 탄식이 흘러나왔다.

드미트리는 스크린에서 눈을 떼지 않았다. 저것은 유니티의 잘못이 아니었다. 그들은 자신들의 막강한 엔진을 웹에서 구동하기 위해 Emscripten 같은 기술을 사용해 필사적인 노력을 기울였다. 문제는 엔진이 아니라, 엔진이 달릴 ‘도로’에 있었다. WebGL이라는 도로는 저런 고성능 차량이 질주하기엔 너무 좁고 구불구불했다.

발표자가 말을 이었다.
“문제는 드로우 콜(Draw Call)입니다. 저희 엔진은 수천 개의 객체를 화면에 그려야 합니다. 네이티브 환경에서는 이 명령들을 효율적으로 묶어 GPU에 전달할 수 있지만, WebGL 환경에서는 CPU가 하나하나의 명령에 너무 깊이 관여합니다. 결과적으로 CPU 병목 현상이 발생하고, GPU는 제 성능을 내지 못합니다. 보시다시피요.”

그의 목소리에는 실망감과 함께 은근한 압박이 섞여 있었다. ‘웹의 미래를 책임지겠다는 구글이 이 문제를 해결해야 하지 않는가?’ 하는 무언의 질문이었다.

회의가 끝나고 자리로 돌아온 드미트리는 생각에 잠겼다.
물론, 그동안 손을 놓고 있었던 것은 아니다. WebGL 2.0이라는 중요한 업데이트가 있었다. WebGL 1.0이 OpenGL ES 2.0에 기반했다면, WebGL 2.0은 OpenGL ES 3.0을 기반으로 삼아 훨씬 더 많은 기능을 제공했다. 향상된 텍스처 기능, 다중 렌더 타겟, 유니폼 버퍼 객체 등. 개발자들에게 더 많은 무기를 쥐여준 것은 사실이었다.

‘하지만… 근본적인 설계 철학은 바뀌지 않았어.’

WebGL 2.0은 분명 훌륭한 진보였다. 하지만 그것은 기존의 ‘상태 기계(State Machine)’ 모델을 그대로 계승했다. GPU를 제어하기 위해 CPU가 여전히 모든 상태를 일일이 설정하고 확인해야 하는 구조. 1차선 도로를 2차선으로 넓힌 수준의 개선일 뿐, 고속도로를 새로 건설한 것은 아니었다. 유니티와 언리얼 같은 거대 엔진이 요구하는 수준의 처리량을 감당하기엔 여전히 역부족이었다.

그 무렵, 웹 표준을 논의하는 W3C(World Wide Web Consortium)의 ‘커뮤니티 그룹’ 메일링 리스트는 서서히 달아오르고 있었다.
한 모질라(Mozilla) 엔지니어가 글을 올렸다.
“모바일에서의 전력 소모 문제를 더 이상 외면할 수 없습니다. WebGL의 CPU 사용률은 배터리 수명에 치명적입니다.”

얼마 뒤, 마이크로소프트(Microsoft) 소속의 개발자가 의견을 보탰다.
“우리의 네이티브 API인 DirectX 12는 명시적인 제어권을 개발자에게 넘겨줌으로써 엄청난 성능 향상을 이뤘습니다. 웹도 비슷한 접근법을 고민해야 할 때입니다.”

애플(Apple)의 엔지니어들도 비슷한 목소리를 냈다. 그들의 ‘Metal’ API 역시 같은 철학 위에 서 있었다.

서로 다른 회사, 서로 다른 운영체제, 서로 다른 이해관계. 하지만 그들이 가리키는 방향은 놀라울 정도로 일치했다.

‘로우 레벨(Low-level)’. ‘명시적(Explicit)’. ‘CPU 오버헤드 감소’.

이 키워드들이 보이지 않는 폭풍의 핵처럼 응집되고 있었다. 더 이상 기존의 WebGL을 개선하는 것만으로는 부족하다는 공감대가 형성되기 시작한 것이다.

드미트리는 키보드에 손을 올렸다. 지금껏 머릿속으로만 정리해왔던 생각을 글로 옮길 때였다.
그는 단순한 문제 제기를 넘어, 구체적인 방향을 제시하고 싶었다. Vulkan, Metal, DirectX 12. 이 세 개의 서로 다른 세계를 아우를 수 있는 새로운 웹 표준의 필요성. 그것은 단순히 더 빠른 그래픽을 위한 것이 아니었다.

이것은 웹이 앱과 대등하게 경쟁하고, 차세대 컴퓨팅 플랫폼으로 살아남기 위한 생존의 문제였다.

그의 손가락이 움직이기 시작했다.
“제목: 차세대 웹 그래픽스 API를 위한 제언(A proposal for a next-generation graphics API for the web)”

메일을 전송하는 순간, 그는 거대한 폭풍의 중심부로 한 걸음 내디뎠음을 직감했다. 이것은 이제 구글 내부의 고민이 아니었다. 웹의 미래를 짊어진 모든 플레이어들이 함께 풀어야 할 거대한 숙제였다. 그리고 그 숙제를 풀기 위한 첫 번째 공식적인 무대, ‘GPU for the Web’ 커뮤니티 그룹의 첫 미팅이 다가오고 있었다.