LiteRT.js 공개, 브라우저 AI를 도입할 한국 웹팀의 세 가지 경계

Google은 2026년 7월 9일 LiteRT.js를 공개했습니다. 이 JavaScript 런타임은 LiteRT 모델을 브라우저 안에서 실행하고 WebGPU, WebAssembly(Wasm), 실험적 WebNN 경로를 선택할 수 있게 합니다. 한국 웹·제품팀에는 서버 추론을 모두 대체한다는 신호가 아니라, 개인정보가 민감하거나 즉시 반응이 필요한 일부 기능을 클라이언트로 옮겨 시험할 새로운 선택지입니다.

확인된 사실: 공식 발표와 문서는 JavaScript·TypeScript 앱에서 텍스트 생성, 객체 탐지, 오디오 처리 같은 모델을 클라이언트에서 실행할 수 있고, @litertjs/core 패키지와 .tflite 모델 형식을 사용한다고 설명합니다.

7월 9일 발표가 웹 개발에 추가한 선택지

LiteRT.js의 중심은 브라우저용 추론 런타임입니다. 공식 문서는 CPU에서 XNNPack을 Wasm으로 실행하고, 지원 환경에서는 WebGPU로 GPU 가속을 사용한다고 밝힙니다. WebNN도 선택할 수 있지만 아직 실험적이며 별도 브라우저 설정과 하드웨어 조건을 요구합니다. 따라서 세 경로는 동일한 안정성 등급으로 취급하면 안 됩니다.

기본 시작점은 다음과 같습니다.

npm install @litertjs/core

공식 시작 문서는 PyTorch 모델을 LiteRT로 변환하고, Wasm 파일을 제공한 뒤, 브라우저에서 모델을 불러오는 흐름을 제시합니다. 모델은 torch.export.export와 호환돼야 하고 동적 입출력 차원에 제한이 있다고 설명합니다. 즉 npm 패키지 설치만으로 기존 모델이 자동 이식되는 것은 아닙니다.

WebGPU·Wasm·WebNN을 같은 지원표에 넣지 말아야 한다

확인된 사실을 실행 경로별로 나누면 다음과 같습니다.

공식 core 문서는 WebGPU가 처리하지 못하는 연산이 있을 때 환경에 따라 연산 단위로 Wasm에 나누거나 모델 전체가 Wasm으로 폴백할 수 있다고 설명합니다. 이 차이는 기능 성공 여부뿐 아니라 응답 시간과 배터리 사용량에도 영향을 줄 수 있으므로, “WebGPU 지원 브라우저”라는 한 줄만으로 배포 대상을 정하면 부족합니다.

POEMORA의 해석은 브라우저·OS 이름보다 대표 기기군의 실제 실행 경로를 관측해야 한다는 것입니다. 한국 서비스라면 최신 데스크톱뿐 아니라 보급형 Android, 기업용 Windows, iPhone Safari를 나눠 모델 로드 성공률과 첫 실행 시간을 기록하는 편이 현실적입니다. 이 항목들은 공개 발표의 보장치가 아니라 팀이 자체 측정해야 할 운영 지표입니다.

한국 제품팀이 먼저 정할 세 가지 경계

첫 번째는 기능 경계입니다. 브라우저에서 즉시 결과가 필요한 이미지 분류, 입력 보조, 로컬 문서 분류처럼 짧고 실패해도 복구 가능한 기능부터 선택합니다. 결제 승인, 의료 판단, 접근 통제처럼 오류 비용이 큰 결정은 단지 로컬에서 실행된다는 이유로 맡기면 안 됩니다.

두 번째는 데이터 경계입니다. 온디바이스 처리는 입력을 서버로 보내지 않는 설계를 가능하게 하지만, 그것만으로 개인정보 보호가 완료되지는 않습니다. 모델 파일 요청, 분석 로그, 오류 수집, 결과 동기화가 어떤 데이터를 외부로 보내는지 별도로 문서화해야 합니다. “로컬 AI”라는 제품 문구와 실제 네트워크 동작이 일치해야 합니다.

세 번째는 배포 경계입니다. 모델 파일과 Wasm 자산의 크기, 캐시 정책, 버전 무효화, 무결성, 저사양 폴백을 애플리케이션 릴리스 기준에 포함해야 합니다. 모델 다운로드가 실패해도 핵심 화면이 작동하는지, 새 모델이 오래된 코드와 섞이지 않는지, 탭을 닫을 때 자원이 정리되는지를 확인합니다.

작은 기능으로 검증하는 도입 절차

1. 서버 전송을 줄이면 사용자 가치가 분명한 단일 기능을 고릅니다.
2. 모델을 LiteRT 형식으로 변환하고 공식 Model Tester 또는 자체 벤치에서 CPU·GPU 결과를 비교합니다.
3. Wasm을 기본 안전망으로 두고 WebGPU는 기능 감지 후 선택합니다. WebNN은 실험군으로 분리합니다.
4. 대표 기기에서 모델 크기, 다운로드 시간, 첫 추론과 반복 추론, 메모리, 실패율을 측정합니다.
5. 지원하지 않는 환경에서는 서버 추론 또는 비AI 기능으로 돌아가는 경로를 제공합니다.
6. 입력·결과·로그의 외부 전송 여부를 개인정보 안내와 운영 문서에 반영합니다.

이 절차에서 중요한 것은 최고 속도 한 건이 아니라 지원 범위의 하한입니다. 브라우저 기반 기능 설계와 성능 예산을 함께 검토해야 한다면 POEMORA 웹 서비스에서 대표 사용자 여정과 폴백까지 묶어 점검할 수 있습니다.

확인된 범위와 아직 남은 불확실성

확인된 사실은 LiteRT.js가 브라우저에서 .tflite 모델을 실행하고, Wasm·WebGPU·WebNN 가속기를 선택하며, TensorFlow.js 파이프라인과의 상호 운용 경로를 제공한다는 점입니다. 공식 저장소는 런타임이 모델 실행을 맡지만 전처리와 후처리는 애플리케이션이나 다른 라이브러리가 담당한다고 명시합니다.

아직 단정할 수 없는 것은 모든 모델의 변환 성공, 모든 브라우저에서 같은 연산 지원, 각 한국 서비스의 비용 절감률과 사용자 체감입니다. 특히 WebNN은 실험적이므로 일반 사용자 기능의 유일한 경로로 두기 어렵습니다. LiteRT.js를 평가할 때는 “서버가 없어졌다”가 아니라 “어떤 입력이 기기를 떠나지 않고도 처리되며, 실패하면 어디로 돌아가는가”를 최종 질문으로 삼아야 합니다.