코드 하이라이팅은 오랫동안 언어별 문법(grammar) 규칙에 의존해 왔다. TextMate 문법이나 Tree-sitter 같은 방식은 각 언어의 토큰 규칙을 사람이 정의하고, 파서가 그 규칙에 맞춰 색을 입힌다. 정확하지만, 지원하지 않는 언어나 낯선 방언(dialect)을 만나면 무력해진다는 한계도 함께 따라온다. 최근 공개된 gpu-lexer는 이 전제를 뒤집는다. 문법을 고르는 대신, 주변 문맥을 보고 각 조각이 무엇인지 '추측'하는 작은 모델을 브라우저의 WebGPU 위에서 돌린다.
어떻게 동작하나
동작 원리는 의외로 단순하다. gpu-lexer는 먼저 소스 코드를 단어, 공백, 줄바꿈, 기호라는 원시적인 조각들로 쪼갠다. 그다음 아주 작은 WebGPU 모델이 각 조각의 지역적 문맥과 파일 전체의 문맥을 함께 결합해 라벨을 붙인다. 같은 라벨이 인접해 있으면 하나의 하이라이트 구간(span)으로 묶여 결과로 반환된다. 핵심은 '언어에 구애받지 않는다'는 점이다. 특정 문법을 선택하지 않고, 학습 중 한 번도 본 적 없는 언어나 구문이라도 주변 코드만 보고 각 부분의 유형을 판별하려 시도한다. 배포 번들은 27.5KB에 불과하며, 모든 언어에 대해 동일한 하나의 번들을 사용한다는 점도 언어별 문법 파일을 따로 싣는 기존 방식과 구분되는 지점이다.
정확도는 어디까지인가
제작자 스스로 이것이 문법 기반 하이라이터와 동등한 결과물이 아니라 '실험'임을 분명히 한다. 학습에 쓰지 않은 파일에서 현재 모델의 토큰 라벨 중 12.57%가 Shiki와 다르게 나온다. 여기서 주의할 점은 이 수치가 '객관적 정답'과의 차이가 아니라 Shiki와의 일치도를 잰 것이라는 사실이다. 즉 Shiki가 기준선(reference)일 뿐이며, 학습에 없던 언어나 실제 현업 코드에서는 이 불일치가 더 커질 수 있다. 평가 방식도 구체적이다. 각 라이브러리의 토큰 이름을 plain, comment, string, number, keyword, type, function, constant, operator라는 아홉 개 공통 클래스로 정규화하고, GitHub Innovation Graph의 2026년 1분기 상위 25개 언어에서 뽑은 1,069개의 검증용 파일을 대상으로 공백이 아닌 부분만 비교했다. 점수는 각 언어의 푸시(pusher) 수로 가중되며, 지원하지 않는 언어는 0점 처리된다.
성능과 벤치마크의 맥락
속도 측면에서는 흥미로운 시연이 함께 제시됐다. 2026년 9월 8일, three.min.js를 열 번 이어 붙인 556만 자 분량 입력을 M4 Pro(20코어 GPU)·24GB MacBook Pro의 Chrome 152에서 워밍업 한 번 뒤 실행한 결과다. 각 엔진은 전용 워커에서 돌았고 DOM 렌더링은 측정에서 제외됐다. 다만 비교 대상들의 출력 형태가 제각각이라는 점은 해석에 주의를 요한다. gpu-lexer와 Shiki는 토큰 데이터를, Starry Night는 HAST 트리를, Sugar High·Prism.js·Highlight.js는 완성된 하이라이트 HTML을 반환한다. 반환 형식이 다르면 실제 화면에 그리기까지의 비용도 달라지므로, 이 숫자만으로 우열을 단정하기는 어렵다. 번들 크기 역시 9월 8일 기준 minify 후 Brotli 압축 상태로 측정됐으며, Starry Night의 경우 Oniguruma WASM 페이로드까지 포함한 합계라는 단서가 붙는다.
실무자가 새겨둘 지점
한국의 프론트엔드·개발도구 실무자에게 이 프로젝트의 의미는 두 갈래다. 첫째, 브라우저 안에서 GPU 추론으로 하이라이팅을 처리한다는 접근 자체가 WebGPU의 실용적 활용 사례를 하나 더 보탰다. 사내 위키, 코드 리뷰 도구, 문서 플랫폼처럼 온갖 언어의 스니펫이 뒤섞여 들어오는 환경에서는 언어를 미리 지정하지 않아도 되는 방식이 매력적일 수 있다. 둘째, 그럼에도 이것은 프로덕션 대체재가 아니라 개념 증명에 가깝다. 12.57%라는 불일치율은 열 토큰 중 한 개꼴로 색이 달라질 수 있다는 뜻이고, 정확한 구문 강조가 가독성과 직결되는 코드 에디터나 기술 문서에서는 이 오차가 곧 신뢰 저하로 이어진다. WebGPU를 지원하지 않는 브라우저나 GPU가 빈약한 환경에서의 동작 역시 별도로 검증해야 할 부분이다. 결국 gpu-lexer는 '문법을 정의하는 하이라이팅'에서 '문맥을 학습하는 하이라이팅'으로 넘어가는 초기 실험으로 보는 편이 정확하다. 방향성은 도발적이지만, 지금 도입을 고민한다면 어디까지가 검증된 사실이고 어디부터가 실험인지 구분해 읽어야 한다.