웹에서 그래픽 효과를 다룰 때 개발자는 대개 두 갈래 중 하나를 택해 왔다. 디자이너가 만든 결과물을 영상이나 이미지로 받아 붙이거나, 직접 셰이더 언어를 붙들고 GPU 코드를 작성하는 것이다. 전자는 상호작용이 빈약하고 후자는 진입 장벽이 높다. Shaders(shader-effects-inc/shaders)는 이 간극을 'WebGPU 효과를 UI 컴포넌트처럼 다룬다'는 접근으로 메우려는 오픈소스 프로젝트다. React, Vue, Svelte, Solid는 물론 순수 JavaScript와 디자인 도구 Framer까지 지원 대상으로 삼는다.
효과를 컴포넌트 트리로 다룬다
이 라이브러리의 핵심 모델은 단순하다. 모든 효과가 하나의 컴포넌트이고, 최상위 가 캔버스를 렌더링한다. 그 안에 들어가는 자식들은 각각 하나의 레이어가 되며, 위에서 아래 순서로 평가되어 GPU 위에서 합성(blend)된다. 포토샵의 레이어 패널을 떠올리면 이해가 빠르다. 다만 그 합성이 CPU가 아니라 GPU에서 일어난다는 점이 성능과 상호작용 측면의 차이를 만든다. 프런트엔드 개발자에게 익숙한 선언형 컴포넌트 문법 안에 그래픽 파이프라인을 녹여 넣은 셈이어서, 효과를 끼워 넣고 떼어내는 일이 일반 UI 요소를 다루듯 이루어진다.
라이브러리는 200개가 넘는 컴포넌트를 제공한다고 밝히고 있으며, 각 컴포넌트에는 라이브 미리보기와 함께 모든 프로퍼티(prop)가 문서화되어 있다. 효과 하나하나가 어떤 입력값을 받는지 문서로 공개되어 있다는 점은, 손으로 직접 튜닝하려는 개발자에게는 중요한 참고 자료가 된다.
코드보다 '디자인'이 먼저인 워크플로
흥미로운 지점은 제작진이 '대부분의 사람은 효과를 손으로 작성하지 않고 디자인한다'고 전제한다는 것이다. 이를 위해 shaders.com에 무한 캔버스 형태의 디자인 에디터를 두었다. 여기서 컴포넌트를 쌓고, 실제 컨트롤로 각 프로퍼티를 조정하며, 커서나 타임라인으로 값의 변화를 구동하고, 결과를 실시간으로 확인한다. 원하는 모습이 나오면 'Export Code' 기능이 사용 중인 프레임워크에 맞는 컴포넌트 트리를 뱉어내 그대로 붙여넣을 수 있다. 디자인과 코드 내보내기는 계정만 있으면 무료이고, 작업물은 프로젝트 단위로 저장돼 나중에 다시 열 수 있다.
코드베이스와의 연결은 CLId이 담당한다. CLI는 Shaders 계정과 프로젝트를 이어 주어, 에디터에서 디자인한 효과가 실제 컴포넌트 파일로 프로젝트에 내려오고 동기화 상태를 유지하도록 한다. 프레임워크를 자동 감지해 컴포넌트 폴더에 파일을 쓰고, 무엇을 설치했는지 잠금 파일(lock file)에 기록한다. 전역으로 설치할 것이 없다는 점도 명시돼 있다. 또한 코딩 에이전트에게 개발자와 동일한 도구를 쥐여 줄 수 있다고 설명하는데, AI 보조 개발 환경을 염두에 둔 구성으로 읽힌다.
직접 만들거나, 저수준으로 내려가거나
기성 컴포넌트로 부족하면 새 컴포넌트를 작성할 수 있다. 컴포넌트는 defineShader에 넘기는 평범한 객체로, 이름과 프로퍼티, 그리고 픽셀마다 무엇을 그릴지를 정의한 것이다. 이렇게 만든 것은 로 마운트해 다른 컴포넌트와 똑같이 쓴다. 픽셀 부분을 기술하는 방법은 두 가지다. 제공되는 std 프리미티브를 조합하는 방식은 아직 실험적(experimental) 단계이고, WGSL(WebGPU Shading Language)을 직접 작성하는 방식은 안정적(stable)이라고 구분해 둔다. 손이 많이 가더라도 검증된 길을 원한다면 WGSL을, 추상화된 편의를 원한다면 프리미티브를 택하라는 안내인 셈이다.
라이선스와 비용 구조도 짚어둘 만하다. 앞서 언급한 디자인·내보내기·CLI 등은 모두 무료이며, 유료 등급인 Pro가 라이브러리와 그를 둘러싼 워크플로를 추가로 제공한다. 엔진 자체는 packages/core에 있고 src/shaders/ 아래 컴포넌트마다 폴더가 하나씩 대응되며, 프레임워크별 패키지는 이 코어에서 생성된다. 이슈와 풀 리퀘스트를 받되, 단순 버그 수정이 아닌 변경은 PR 전에 이슈로 먼저 논의하라는 기여 가이드도 두고 있다.
실무 관점의 의미와 한계
한국의 프런트엔드 실무자에게 이 프로젝트가 주는 함의는 분명하다. 그래픽 효과를 '자산'이 아니라 '컴포넌트'로 버전 관리하고, 디자인 도구에서 나온 결과가 잠금 파일과 함께 레포에 그대로 들어온다면, 디자이너와 개발자 사이의 수작업 전달 과정이 줄어든다. 멀티 프레임워크 지원은 사내에서 React와 Vue를 섞어 쓰는 조직에 특히 매력적이다.
다만 공개된 설명만으로는 판단을 유보해야 할 지점도 남는다. WebGPU는 비교적 최신 표준이라 구형 브라우저나 환경에서의 폴백 처리가 어떻게 되는지, 200여 개 컴포넌트가 실제 제품 수준의 성능과 접근성을 만족하는지는 원문에서 수치로 확인되지 않는다. 또한 핵심 워크플로의 상당 부분이 shaders.com이라는 특정 서비스와 계정에 묶여 있어, 오픈소스 엔진과 호스티드 서비스 사이의 의존 관계를 어느 선까지 감당할지는 도입 전 각 팀이 따져볼 몫이다. 실험적 프리미티브와 안정적 WGSL을 명확히 구분해 표기한 점은 신뢰를 주지만, 커스텀 효과를 본격적으로 쓰려면 결국 셰이더 언어에 대한 이해가 필요하다는 현실은 그대로다.