Transformers.js v4 프리뷰, NPM ‘next’로 맛보기 시작하기
Transformers.js는 “브라우저에서도 돌아가는 허깅페이스 추론 라이브러리”로 알려져 있지만, v4 프리뷰의 메시지는 한 단계 더 큽니다. 이제 GitHub 소스를 붙잡고 씨름하지 않아도 npm i @huggingface/transformers@next 한 줄로 v4를 설치해 실험할 수 있고, WebGPU 가속을 중심으로 브라우저·서버·데스크톱 JS 런타임을 한 흐름으로 묶으려는 방향이 분명해졌습니다1. 이 글에서는 “그래서 내 프로젝트에 뭐가 달라지나?”를 기준으로 핵심 변화만 재미있게 정리해볼게요.
NPM에서 바로 설치: ‘next’ 태그가 바꾸는 실험 속도
v4 프리뷰가 NPM에 next 태그로 올라오면서, 이제는 정식 릴리스 전 기능을 “설치 가능 제품”처럼 바로 테스트할 수 있게 됐습니다1. 체감 포인트는 단순합니다. PoC(Proof of Concept)나 사내 데모를 만들 때, 특정 커밋을 찍어 설치하는 방식보다 재현성과 공유가 훨씬 쉬워졌다는 것.
다만 next는 말 그대로 “계속 움직이는 기차”라서, 오늘 잘 되던 코드가 다음 업데이트에서 경고를 뿜을 수도 있습니다. 실무에서는 메인 앱 의존성과 분리해서(예: 별도 패키지/브랜치/샌드박스) 벤치마크 전용으로 붙여보는 전략이 안전합니다.
WebGPU 런타임 대수술: 브라우저 전용이 아니라 “JS 전체”로
v4에서 가장 큰 변화는 WebGPU 런타임을 C++ 기반으로 전면 재작성했다는 점입니다1. 이건 “조금 빨라졌다” 수준이 아니라, 더 많은 연산자와 모델 구조를 안정적으로 커버하기 위한 기반 공사에 가깝습니다.
여기서 재미있는 포인트는 WebGPU의 무대가 브라우저만이 아니라는 메시지예요. Node/Bun/Deno 같은 JS 런타임에서도 WebGPU 가속을 전면에 내세우면서, “프론트엔드에서만 AI를 돌린다”가 아니라 “JavaScript로 어디서든 같은 코드 경로로 추론한다” 쪽으로 방향타가 꺾였습니다1. 즉, 웹 데모로 시작한 기능이 서버·엣지·데스크톱 앱까지 자연스럽게 확장되는 그림이 더 현실적으로 보입니다.
ONNX 커스텀 연산자 적극 활용: LLM이 ‘웹에서’ 빨라지는 이유
대형 모델이 웹에서 느린 이유는 단순히 “GPU가 약해서”만이 아닙니다. 모델을 내보내는(export) 방식, 연산자(operator) 구현, 런타임 최적화가 한 세트로 맞물려야 속도가 나옵니다. v4는 이 부분을 아예 다시 설계하면서, ONNX Runtime의 Contrib Operator를 적극 활용했다고 밝힙니다1.
예를 들어 특정 어텐션 구현을 바꾼 것만으로 BERT 임베딩 모델이 약 4배 빨라졌다는 언급이 있는데, 이런 변화는 “모델 파일만 바꾼다”로는 잘 안 나오는 종류의 개선입니다1. 제품 관점에서는 희소식이죠. 같은 하드웨어에서도, 같은 모델이라도, 추론 파이프라인이 더 ‘엔진 친화적’이 될 수 있으니까요.
오프라인 캐싱 강화: 현장 단말·보안망 배포가 쉬워진다
웹에서 모델을 돌릴 때 은근히 발목을 잡는 게 네트워크입니다. “첫 로딩이 너무 길다”도 문제지만, 더 골치 아픈 건 아예 인터넷 연결이 불안정하거나 없는 환경(공장/교육장/사내 폐쇄망/전시장 키오스크)입니다.
v4는 초기 다운로드 이후 브라우저에서 WASM 파일을 로컬 캐시해 오프라인에서도 실행 가능하게 하는 흐름을 강화했습니다1. 이건 단순 편의 기능이 아니라, 클라이언트/엣지 추론을 “진짜 배포 가능한 옵션”으로 만들어주는 장치에 가깝습니다. 특히 보안팀이 “외부 호출 금지”를 외치는 순간, 이 기능의 가치가 급상승합니다.
모노레포·빌드 시스템 개편: 기능 추가하면서도 더 가벼워진다
v4는 내부 구조도 크게 손봤습니다. pnpm workspaces 기반 모노레포로 전환해 하위 패키지를 유연하게 공급할 수 있는 형태가 됐고, 비대해진 모델 정의도 모듈화해 유지보수성과 기여 난이도를 낮췄습니다1. 겉으로는 개발팀 이야기 같지만, 장기적으로는 “업데이트가 잦아져도 덜 흔들리는 라이브러리”로 이어질 가능성이 큽니다.
또 하나 눈에 띄는 변화는 Webpack에서 esbuild로 옮겨 개발 빌드 시간이 2초에서 200ms로 줄었다는 점, 번들 크기도 평균 약 10% 감소했고 기본 번들 transformers.web.js는 53% 축소됐다는 내용입니다1. WebGPU/LLM처럼 무거운 기능이 늘어나는 시기에 번들까지 다이어트했다는 건, 웹 앱에서 초기 로딩 시간을 줄이는 데 직접적인 이득이 됩니다.
@huggingface/tokenizers 분리: “토크나이저만” 쓰는 선택지
웹에서 체감 성능을 깎아먹는 병목이 모델만은 아닙니다. 텍스트를 토큰으로 바꾸는 토크나이징이 느리거나 무거우면, 첫 화면 반응성이 답답해지죠. v4 흐름에서 토크나이저를 @huggingface/tokenizers라는 독립 패키지로 분리했고, gzipped 8.8kB, 의존성 0, 타입 세이프를 강조합니다1.
이 변화가 좋은 이유는 선택지가 생기기 때문입니다. “나는 추론은 다른 엔진으로 하고, 토크나이저만 가볍게 공용으로 쓰고 싶다” 같은 조합이 쉬워집니다. 결과적으로 WebML 프로젝트에서 중복 구현을 줄이고, 제품 번들 구성도 더 깔끔해질 수 있습니다.
시사점을 정리하면 이렇습니다. Transformers.js v4 프리뷰는 ‘브라우저에서 AI 된다’의 데모 단계를 넘어, WebGPU 가속을 중심으로 JS 런타임 전반에서 통합 추론 경로를 만들려는 선언에 가깝습니다1. 그래서 추천 액션도 명확합니다. 이미 제품/PoC가 있다면 v3를 그대로 갈아엎기보다 @next를 분리 설치해 성능과 정확도를 먼저 비교해보세요. 오프라인 요구가 있는 조직이라면 WASM 캐싱 기반 오프라인 동작을 가장 먼저 검증하는 게 ROI가 큽니다. 그리고 번들 크기와 초기 반응성이 민감한 웹 앱이라면, 토크나이저 분리 패키지를 단독 도입하는 것만으로도 체감이 달라질 수 있습니다.