왜 TypeShade인가
셰이더가 두 벌이 되는 이유
WebGL2와 WebGPU 양쪽에서 돌아야 하는 셰이더는 두 벌이 됩니다. 두 언어는 타입, 진입점, 리소스 바인딩, 정밀도가 서로 달라서 두 번째 복사본은 사실상 처음부터 다시 쓰는 일입니다. 한쪽에만 들어간 수정은 다른 경로를 타는 기기에서야 드러나고, 리뷰어는 두 언어로 된 코드를 나란히 읽으면서 둘이 여전히 같은 일을 하는지 판단해야 합니다.
WebGPU로 넘어가는 흐름
웹은 지금 그런 이동의 한가운데에 있습니다. MapLibre 그래픽 현대화 로드맵, deck.gl WebGPU 가이드, PixiJS v8 마이그레이션 가이드 모두 기존 WebGL 경로 옆에 WebGPU 경로가 생기는 과정을 설명합니다. GLSL로 쓴 커스텀 레이어라면 WGSL로 된 복사본이 하나 더 필요해집니다.
설문 결과
Khronos 2026 Real-Time Shading Ecosystem Survey에서는 응답한 셰이더 개발자 400명 이상 가운데 64%가 플랫폼, API, 도구를 넘나들며 셰이더를 옮기고 있다고 답했고, 10% 가까이는 그 일을 상당한 또는 가장 큰 엔지니어링 비용으로 꼽았습니다.
TypeShade가 하는 일
TypeShade는 소스를 하나로 둡니다. 모듈이 타입 있는 TypeScript라서 잘못 쓴 필드나 틀린 반환 타입은 편집기에서 잡힙니다. 중간 표현 하나가 두 언어를 모두 내고, 같은 모듈이 CPU에서 배정밀도로 실행되므로 백엔드가 낸 결과를 같은 소스로 계산한 기준값과 맞춰 볼 수 있습니다. 푸시마다 무엇을 실행하는지는 검증 페이지에 있습니다.
하지 않는 일
TypeShade에는 렌더러도 씬 그래프도 없습니다. 문자열과 리플렉션 메타데이터를 돌려줄 뿐이고, 파이프라인 생성, 리소스 바인딩, 드로우 호출은 호스트의 몫입니다. SPIR-V, MSL, HLSL은 WGSL을 naga나 Tint에 넣어 얻습니다. 네이티브 호스트는 모두 Dawn이나 wgpu를 거쳐 WGSL을 이미 받기 때문입니다.