WebGPU Samples 프로젝트가 성공적으로 안착하면서, 커뮤니티에서는 이를 기반으로 한 경이로운 창작물들이 매일같이 쏟아져 나왔다. 그중에서도 가장 큰 화제를 모은 것은 한 아티스트가 만든 ‘절차적 은하 생성기(Procedural Galaxy Generator)’였다. 사용자는 단 몇 개의 파라미터 조작만으로, 수십억 개의 별과 성운으로 이루어진 자신만의 은하계를 실시간으로 창조하고 탐험할 수 있었다. 데스크톱에서는 흠잡을 데 없이 완벽하게 작동했다.
그 완벽함에 균열이 가기 시작한 것은, 구글 플레이 스토어의 크롬 리뷰 페이지에서부터였다.
★☆☆☆☆ “최신 업데이트 후, 특정 웹사이트에 들어가기만 하면 브라우저가 멈추고 강제 종료됩니다.”
★☆☆☆☆ “폰이 손난로가 됐어요. 배터리가 10분 만에 20%가 사라졌습니다. 대체 무슨 짓을 한 거죠?”
★★☆☆☆ “예전엔 잘 되던 3D 게임이 이제는 엄청나게 버벅거려요.”
처음에는 일반적인 불만 접수려니 했다. 하지만 곧 패턴이 보이기 시작했다. 문제를 호소하는 사용자들은 모두 안드로이드 스마트폰을 사용하고 있었다.
Dawn 팀의 연구실.
“도대체 어떻게 된 일이야? 우리의 자동화 테스트는 모든 안드로이드 기기에서 통과했다고.”
벤이 당혹스러운 목소리로 말했다. 그의 앞에는 최신 구글 픽셀폰이 놓여 있었고, 그 화면에서는 문제의 ‘절차적 은하 생성기’가 아무런 문제 없이 부드럽게 돌아가고 있었다.
“그게 문제일지도 몰라, 벤.”
드미트리가 나지막이 말했다.
“우리가 테스트한 기기들은 전부 제조사가 제공하는, 가장 이상적인 환경의 플래그십 모델들이야. 하지만 지금 우리에게 불만을 제기하는 수억 명의 사용자들은, 세상에 존재하는 수천, 수만 종류의 각기 다른 스마트폰을 쓰고 있어.”
그의 말은 냉엄한 현실이었다.
데스크톱 세계는 엔비디아, AMD, 인텔이라는 소수의 강자들이 지배하는 비교적 질서 있는 곳이었다. 하지만 모바일의 세계, 특히 안드로이드의 세계는 혼돈 그 자체였다. 퀄컴의 아드레노(Adreno), ARM의 말리(Mali), 이매지네이션의 파워VR(PowerVR). 수많은 제조사가 만든 각양각색의 GPU들이 탑재된, 그야말로 ‘부서진 세계(A Fractured World)’.
드미트리는 팀원들에게 지시했다.
“당장 시중에 판매되는 중저가형 안드로이드폰을 종류별로 구해오게. 우리가 직접 그 ‘진짜 세상’을 경험해봐야 해.”
며칠 후, 연구실 한쪽에는 다양한 브랜드의 스마트폰들이 즐비하게 늘어섰다. 팀원들은 마침내 진짜 필드 테스트에 돌입했다.
결과는 처참했다.
A사의 스마트폰에서는 은하 생성기를 실행하자마자 화면이 깨지며 탭이 크래시되었다. 로그를 분석해보니, 해당 기기의 말리 GPU 드라이버가 WGSL의 특정 내장 함수를 제대로 컴파일하지 못하는 버그가 있었다.
B사의 스마트폰에서는 처음 몇 분간은 잘 동작하다가, 이내 기기가 뜨거워지면서 프레임 속도가 급격히 떨어졌다. 강력한 성능을 요구하는 셰이더가 ‘서멀 스로틀링(Thermal Throttling)’, 즉 과열 방지를 위한 강제 성능 저하를 유발한 것이다.
C사의 구형 스마트폰은 아예 데모를 실행조차 하지 못했다. GPU 메모리가 부족하여, 거대한 버퍼를 할당하는 단계에서부터 실패했다.
플래그십 모델에서는 결코 볼 수 없었던 문제들이 동시다발적으로 터져 나왔다.
“이걸 우리가 어떻게 다 해결합니까? 세상 모든 폰의 드라이버 버그를 우리가 고쳐줄 수도 없는 노릇이고…”
한 엔지니어의 목소리에 무력감이 묻어났다.
그때, 드미트리가 말했다.
“우리가 해결하는 게 아니야. 개발자들이 ‘스스로 해결할 수 있도록’ 만들어줘야 해.”
그는 다시 화이트보드 앞에 섰다.
“지금 개발자들은 자신이 어떤 하드웨어 위에서 코드를 실행하는지 알 방법이 없어. 마치 안대를 쓰고 운전하는 것과 같지. 우리는 그들의 안대를 벗겨줘야 해.”
그는 새로운 API 함수 하나를 적었다.
navigator.gpu.requestAdapterInfo()
“이 함수를 통해, 개발자가 최소한의 하드웨어 정보를 얻을 수 있게 합시다. 벤더(Vendor), 아키텍처(Architecture) 같은 정보 말입니다. 만약 특정 말리 GPU에서 버그가 있다는 것을 안다면, 개발자는 해당 기기에서는 문제가 되는 기능을 비활성화하는 대체 코드를 실행시킬 수 있습니다.”
그는 이어서 device.limits 객체를 강조했다.
“그리고 우리는 개발자들에게 ‘device.limits’의 중요성을 더 적극적으로 알려야 합니다. 현재 기기가 지원하는 최대 버퍼 크기, 최대 텍스처 크기 같은 정보들이 모두 여기에 담겨 있습니다. 개발자들은 이 한계치를 확인하고, 저사양 기기에서는 더 작은 텍스처를 로드하거나, 파티클 개수를 줄이는 식으로 ‘우아하게 성능을 낮추는(Graceful Degradation)’ 전략을 구사해야 합니다.”
이것은 WebGPU의 철학을 한 단계 더 진화시키는 발상이었다.
개발자에게 무조건적인 고성능을 약속하는 것이 아니라, 현재 환경의 ‘한계’를 명확히 알려주고, 그 한계 안에서 최선의 경험을 만들어낼 수 있는 선택지를 제공하는 것.
드미트리는 깨달았다. 웹 플랫폼의 진정한 힘은 모든 기기에서 똑같은 경험을 제공하는 획일성이 아니라, 각기 다른 수많은 환경에 맞춰 스스로 모습을 바꿀 수 있는 ‘적응성’에 있다는 것을.
그의 임무는 이제 이 부서진 세계를 하나로 통일하는 것이 아니었다. 그 부서진 세계의 모든 조각들 위에서, 개발자들이 길을 잃지 않고 자신만의 지도를 그려나갈 수 있도록 돕는 것이었다.
