TypeScript 파일 맨 위에 import 문 하나가 있습니다. 불러오는 대상이 .ts가 아니라 .wgsl, WebGPU 셰이더 파일이에요. 에디터에서 자동완성이 붙고, 빌드가 돌고, 안 쓰는 코드는 지워집니다. JS 모듈을 다루던 손놀림 그대로 GPU 코드를 다루는 장면입니다.
이 장면을 만든 라이브러리가 vGPU입니다. Vercel이 vercel.com 화면에 들어가는 셰이더를 구현하려고 내부에서 만들었고, MIT 라이선스 오픈소스로 풀었어요. 8월 28일 보도로 알려졌습니다. npm에 올라온 버전은 v0.3.1, 아직 초기지만 방향은 이미 선명합니다.
README에 이런 명시가 있습니다. 완전한 풀스크린 이펙트가 25KB gzipped, 그리고 이 예산을 CI가 강제한다. 저는 이 한 줄이 라이브러리 전체 성격을 요약한다고 봅니다.
셰이더가 왜 모듈 취급을 받아야 할까요?
지금까지 셰이더는 대체로 문자열이었습니다. JS 코드 안에 긴 문자열로 박아 넣거나, 별도 파일을 텍스트로 읽어와 GPU에 넘기는 식이었죠. 문자열이니 빌드 도구가 내용을 모릅니다. 어떤 함수가 안 쓰이는지, 바인딩 구조가 뭔지, 번들러 입장에선 깜깜이였어요. 오타를 내도 빌드는 통과하고, 화면이 깨진 뒤에야 사람이 알아차리는 구조였습니다.
vGPU는 .wgsl 파일을 TypeScript 모듈처럼 import·export하게 만듭니다.
빌드 시점에 벌어지는 일이 넷입니다. 셰이더끼리 얽힌 모듈 그래프를 해석하고, 바인딩을 리플렉션으로 뽑아내고, 안 쓰는 선언을 제거하고, 압축합니다. JS 생태계가 번들러로 해온 일이 셰이더에 그대로 적용되는 겁니다.
25KB 예산이 현실이 되는 근거가 여기 있습니다. 미사용 선언 제거와 압축이 빌드에 내장돼 있으니, 예산을 숫자로 정해두고 기계가 지키게 할 수 있어요.
GPU 없는 서버에서 렌더링을 어떻게 검증할까요?
렌더링 코드가 테스트하기 어려운 이유는 단순합니다. 결과가 화면에 그려지는 그림이고, CI 서버엔 보통 GPU가 없거든요.
vGPU는 같은 셰이더를 세 곳에서 똑같이 돌립니다. 브라우저 캔버스, Dawn 기반 headless Node.js, 그리고 결정적 mock 어댑터. 개발자 브라우저에서 보던 그림이 서버에서도, 테스트 환경에서도 같은 코드로 나옵니다.
세 런타임 중 마지막 mock이 핵심입니다. GPU가 아예 없는 환경에서, 같은 입력이면 같은 결과가 나오게 돌아가요.
그 위에 스냅샷 테스트가 기본으로 실려 있습니다. pixelmatch와 pngjs로 렌더링 결과를 픽셀 단위로 비교해요. 셰이더를 고치고 나서 그림이 어긋났는지, 사람이 눈으로 확인하는 대신 CI가 판정합니다. 텍스트 코드가 수십 년간 누려온 회귀 테스트를 GPU 코드가 이제 받는 셈입니다.
이 구조는 에이전트에게도 문을 엽니다. 시각 결과물은 에이전트가 검증하기 가장 어려운 영역이었는데, 결정적 mock과 픽셀 비교가 있으면 에이전트도 자기가 고친 셰이더를 스스로 채점할 수 있어요.
25KB 예산은 왜 사람이 아니라 CI가 지킬까요?
용량 가이드라인을 문서에 적어두는 프로젝트는 많습니다. 그리고 그 가이드라인은 대체로 몇 달 안에 죽습니다. 기능이 하나 붙고, 예외가 하나 생기고, 아무도 재지 않는 사이에 숫자만 남아요.
vGPU는 문서에 적는 대신 CI에 걸었어요. 예산을 넘기면 빌드가 막힙니다. 절제가 문화가 아니라 기계 장치인 거죠. 사람 의지에 기대는 규칙과 기계가 막는 규칙은 수명이 다릅니다.
이 손버릇은 낯설지 않습니다. vGPU를 낸 Vercel Labs는 7.8MiB Zig 바이너리 하나로 코딩 에이전트 fx를 만든 그 랩이에요. 이 계정에서 하네스 미니멀리즘이라 불러온 축, 작게 만들고 작음을 강제하는 설계가 라이브러리에서도 반복된 겁니다.
에이전트가 정식 사용자라는 말은 무슨 뜻일까요?
vGPU에서 에이전트 지원은 부록이 아니라 1급 기능입니다.
레포에 agents.md와 llms.txt가 들어 있습니다. OpenAPI 3.1 스펙을 따르는 예제 API가 붙어 있고요. vgpu.sh/api/mcp 주소로 호스팅되는 읽기전용 MCP 서버가 있고, 레포에는 설치형 agent skill까지 동봉돼 있습니다.
사람용 문서와 기계용 문서가 같은 무게로 놓인 구성입니다. 지금까지 라이브러리는 사람이 읽고 사람이 붙이는 물건이었어요. 에이전트에게 시키면 웹을 뒤져 낡은 예제를 긁어오거나, 그럴듯한 API를 지어내는 게 다반사였고요. vGPU는 에이전트가 문서를 읽고, MCP로 질의하고, 스킬을 설치해 곧바로 쓰는 경로를 출시 시점부터 깔아놨습니다. 지어낼 필요가 없게 정답지를 레포에 같이 넣어둔 겁니다.
그래서 무엇이 바뀌는 걸까요?
먼저 선을 그어둘 게 있습니다. vGPU는 호스팅 서비스가 아닙니다. 계정도 쿼터도 추론 요금도 없어요. MIT 라이브러리 하나가 전부입니다. Vercel 제품 퍼널로 끌고 가는 장치가 아니라는 뜻이에요.
저는 이 레포에서 두 가지를 읽습니다.
하나, 절제를 기계가 강제하는 설계가 라이브러리 층위까지 내려왔습니다. 25KB 예산과 CI 게이트는 fx에서 봤던 미니멀리즘과 같은 계보예요.
둘, 신제품 기본 사양이 바뀌고 있습니다. agents.md·MCP 서버·agent skill 동봉은 이전 세대 라이브러리엔 없던 항목입니다. 사람만 겨냥해 만든 라이브러리와 에이전트까지 사용자로 대접하는 라이브러리, 이 갈림이 이제 출시 사양표에 드러나기 시작했어요. vGPU는 그 첫 세대에 서 있는 물건이고, 저는 뒤따르는 레포들이 이 구성을 표준처럼 베끼게 될 거라고 봅니다.
원문·소스
- vGPU 공개 보도 (MarkTechPost): https://www.marktechpost.com/2026/08/28/vercel-vgpu-webgpu-library-open-source/
- vGPU 깃허브 레포: https://github.com/vercel-labs/vgpu
- vGPU 공식 사이트: https://vgpu.sh/
FAQ
자주 묻는 질문
- 셰이더가 왜 모듈 취급을 받아야 할까요?
- 지금까지 셰이더는 문자열이었기 때문에 빌드 도구가 내용을 몰랐고, 오타를 내도 빌드는 통과했습니다. vGPU는 .wgsl 파일을 TypeScript 모듈처럼 import·export하게 만들어, 모듈 그래프 해석·바인딩 리플렉션·미사용 선언 제거·압축을 빌드 시점에 처리해요.
- GPU 없는 서버에서 렌더링을 어떻게 검증할까요?
- 브라우저 캔버스, Dawn 기반 headless Node.js, 결정적 mock 어댑터 세 런타임에서 같은 셰이더를 돌립니다. GPU가 없는 환경에서도 같은 입력이면 같은 결과가 나오는 mock 위에 pixelmatch·pngjs 스냅샷 테스트가 기본으로 실려 있어, CI가 렌더링 회귀를 픽셀 단위로 판정해요.
- 25KB 예산은 왜 사람이 아니라 CI가 지킬까요?
- 문서에 적어둔 용량 가이드라인은 대체로 몇 달 안에 죽기 때문입니다. vGPU는 예산을 CI에 걸어 넘기면 빌드가 막히게 했어요. 사람 의지에 기대는 규칙과 기계가 막는 규칙은 수명이 다릅니다.
- 에이전트가 정식 사용자라는 말은 무슨 뜻일까요?
- 레포에 agents.md, llms.txt, OpenAPI 3.1 스펙을 따르는 예제 API, 설치형 agent skill이 들어 있고, vgpu.sh/api/mcp에서 호스팅되는 읽기전용 MCP 서버까지 갖췄다는 뜻이에요. 에이전트가 문서를 읽고, MCP로 질의하고, 스킬을 설치해 곧바로 쓰는 경로를 출시 시점부터 깔아놨습니다.