NXT 프로젝트의 두뇌(Command Buffer)와 뼈대(Pipeline)가 제자리를 찾았다. 이제 팀의 관심은 자연스럽게 프로젝트의 심장, 즉 셰이더(Shader)로 옮겨갔다. 셰이더는 GPU 위에서 직접 실행되며, 3D 모델의 정점 위치를 계산하고 각 픽셀의 최종 색상을 결정하는 핵심 프로그램이다. 이 심장을 어떤 언어로 뛰게 할 것인가?
회의실의 정적을 깬 것은 NXT 프로젝트의 젊은 엔지니어, 벤이었다.
“일단은 GLSL을 쓰는 게 가장 현실적이지 않을까요? WebGL 개발자들에게 가장 익숙한 언어니까요. 진입 장벽을 낮추는 것도 중요합니다.”
GLSL(OpenGL Shading Language). WebGL의 표준 셰이더 언어. 그의 제안은 합리적으로 들렸다. 하지만 드미트리는 조용히 고개를 저었다.
“벤의 말도 일리가 있습니다. 하지만 GLSL을 그대로 가져오는 순간, 우리는 우리가 해결하려던 바로 그 문제에 다시 발목을 잡히게 됩니다.”
드미트리가 모두를 둘러보며 말했다.
“WebGL에서 GLSL은 어떻게 동작합니까? 개발자는 셰이더 코드를 ‘문자열(String)’ 형태로 API에 전달합니다. 브라우저는 이 문자열을 받아 실행 시점(Runtime)에 파싱하고, 문법을 검사하고, 컴파일해서 GPU에 보냅니다. 이 모든 과정이 CPU에서 일어나죠.”
그는 잠시 숨을 골랐다.
“바로 그겁니다. 우리가 그토록 피하고 싶었던 ‘실행 시점의 CPU 부하’. 게다가 문자열 기반의 셰이더는 보안에도 취약점을 가질 수 있습니다. 우리가 만드는 새로운 API는 시작부터 달라야 합니다.”
익숙함이라는 달콤한 유혹을 단호히 거절한 드미트리의 말에 회의실은 다시 침묵에 잠겼다. 그렇다면 대안은 무엇인가?
카이가 조심스럽게 다른 가능성을 제시했다.
“마이크로소프트의 HLSL(High-Level Shading Language)은 어떻습니까? DirectX의 표준 언어이고, 수십 년간 게임 업계에서 검증된 강력한 언어입니다. 기능도 풍부하고요.”
HLSL은 분명 매력적인 카드였다. 하지만 여기에는 기술적인 문제 이전에 ‘정치적인’ 문제가 있었다.
드미트리가 대답했다.
“HLSL이 훌륭한 언어라는 점은 부정할 수 없습니다. 하지만 우리가 마이크로소프트의 언어를 표준으로 채택한다면, W3C의 다른 참여자들, 특히 애플과 모질라가 순순히 동의할까요? 이것은 웹 표준이 특정 기업의 기술에 종속된다는 인상을 줄 수 있습니다. 웹 표준은 정치적으로 중립적이어야 합니다.”
GLSL은 낡았고, HLSL은 위험했다. 진퇴양난이었다. 모두의 표정이 어두워지던 바로 그때, 드미트리가 결정적인 화두를 던졌다.
“우리는 관점을 바꿔야 합니다. 개발자가 ‘무엇을 작성하는가’가 아니라, 브라우저가 ‘무엇을 소비하는가’에서부터 시작해야 합니다.”
그는 화이트보드에 새로운 단어를 썼다.
‘SPIR-V (스피어-브이)’
팀원 중 몇몇의 눈이 커졌다. SPIR-V는 Vulkan의 공식 중간 표현(Intermediate Representation)이었다. 인간이 읽고 쓰는 고급 언어가 아니라, 컴파일러가 생성하는 일종의 바이트코드(Bytecode), 즉 기계 친화적인 형태의 코드였다.
“우리의 브라우저가 고급 언어의 문자열을 직접 받는 대신, 사전에 컴파일되고 검증된 SPIR-V를 받는다고 상상해 보십시오. 파싱도, 복잡한 유효성 검사도 필요 없습니다. 브라우저는 이 최적화된 중간 코드를 받아 각 플랫폼(Vulkan, Metal, DirectX 12)에 맞는 네이티브 코드로 빠르고 안전하게 변환하기만 하면 됩니다. CPU의 부담은 거의 제로에 가까워지죠.”
이것은 판도를 바꾸는 아이디어였다.
웹의 보안과 성능 문제를 동시에 해결할 수 있는 우아한 해법. 브라우저가 소비할 이상적인 ‘음식’을 찾아낸 것이다. 연구실의 분위기가 순식간에 반전되었다. 막혔던 길이 뻥 뚫리는 듯한 상쾌함이 모두를 감쌌다.
하지만 환호는 길지 않았다. 카이가 날카로운 질문을 던졌다.
“알겠습니다, 드미트리. 브라우저가 SPIR-V를 소비하는 것이 최선이라는 데 동의합니다. 하지만… 개발자는요? 우리에게 SPIR-V를 직접 작성하라고 할 수는 없지 않습니까? 그건 어셈블리어를 쓰는 것과 같은데요.”
그의 질문에 모두가 다시 현실로 돌아왔다. 그렇다. 가장 중요한 문제가 남아있었다.
브라우저라는 기계에게는 SPIR-V라는 완벽한 음식을 주면 된다.
그렇다면 그 음식을 만들 요리사, 즉 개발자에게는 어떤 ‘레시피’를 쥐여줘야 하는가?
새로운 해법은 동시에 새로운 질문을 낳았다. 그리고 그 질문의 답은, 결국 그들 스스로가 완전히 새로운 언어를 창조해야 한다는, 훨씬 더 거대한 여정의 시작을 의미하고 있었다.
