Google LiteRT.js, 브라우저에 고성능 웹 AI 추론 기능 제공…호환성이 관건

Google은 7월 9일 LiteRT.js를 출시했다. 브라우저별 하드웨어 가속 지원 수준이 제각각인 상황에서도 고성능 웹 AI 추론 런타임을 JavaScript 애플리케이션에 직접 제공하기 위해서다. 이 새로운 라이브러리는 WebGPU, 실험 단계인 WebNN 지원, 또는 WebAssembly 기반 CPU 폴백을 통해 머신러닝 모델을 로컬에서 실행한다.

중요한 변화는 단순히 브라우저에서 AI 모델을 실행할 수 있게 됐다는 점이 아니다. TensorFlow.js와 ONNX Runtime Web은 이미 이 기능을 제공하고 있다. Google은 Android, iOS, 데스크톱 시스템을 위해 개발해 온 최적화를 재사용할 수 있는 네이티브 크로스 플랫폼 LiteRT 스택을 브라우저로 확장하고 있다.

이 결정은 JavaScript 중심 추론 라이브러리에 압박으로 작용한다. 동시에 통합 네이티브 런타임이 서로 다른 브라우저와 하드웨어 환경에서 일관된 결과를 낼 수 있는지도 시험한다. Google은 상당한 벤치마크 성능 향상을 보고했지만, 해당 수치는 공개 웹에서 사용되는 다양한 기기가 아니라 통제된 Apple M4 환경에서 측정된 결과다.

Google LiteRT.js, 웹 AI 런타임 계층을 바꾸다

Google LiteRT.js는 브라우저 추론을 네이티브 엣지 플랫폼 전반에서 사용되는 런타임에 더 가깝게 만든다.

Google은 LiteRT.js를 자사의 온디바이스 추론 스택인 LiteRT의 JavaScript 바인딩으로 설명한다. 개발자는 .tflite 모델을 로드해 입력 데이터를 원격 추론 서버로 전송하지 않고 브라우저 안에서 실행할 수 있다.

LiteRT.js 출시 소식은 JavaScript 및 TypeScript 애플리케이션을 지원한다. 초기 패키지에는 모델 로드, 컴파일, 실행을 위한 도구와 벡터 검색, 객체 감지, 깊이 추정, 이미지 업스케일링을 다루는 예제가 포함됐다.

이 아키텍처는 핵심 작업이 수행되는 위치를 바꾼다. 기존 브라우저 AI 라이브러리는 JavaScript 중심 커널이나 브라우저 그래픽 인터페이스를 통해 연산을 구현하는 경우가 많았다. LiteRT.js는 브라우저가 네이티브에 가까운 속도로 실행할 수 있는 이식 가능한 바이너리 형식인 WebAssembly를 통해 Google의 네이티브 런타임을 노출한다.

런타임은 이후 가속 경로를 선택한다. XNNPACK은 최적화된 CPU 실행을 담당하고, Google의 ML Drift 계층은 WebGPU를 통해 GPU를 대상으로 한다. 신경망 하드웨어를 위한 새로운 브라우저 인터페이스인 WebNN은 전용 신경망 처리 장치에 접근하는 것을 목표로 한다.

가속 경로를 사용할 수 없을 때는 WebAssembly가 폴백을 제공한다. 모든 방문자가 동일한 브라우저, 드라이버, GPU, 운영체제를 사용한다고 웹 애플리케이션이 가정할 수 없기 때문에 이 폴백은 중요하다.

Google은 이번 출시를 이미 .tflite 모델을 사용하는 팀을 위한 발전으로 포지셔닝한다. 이러한 팀은 별도의 브라우저 파이프라인을 구축하는 대신 모바일, 데스크톱, 웹 타깃에서 하나의 모델 형식을 유지할 수 있다.

PyTorch 사용자도 LiteRT Torch를 통해 이 경로에 참여할 수 있다. Google은 이 변환 도구가 PyTorch 모델을 LiteRT 호환 아티팩트로 변환할 수 있다고 설명한다. 이후 AI Edge Quantizer를 사용하면 특정 계층에서 낮은 정밀도 표현을 적용해 모델 크기와 연산 부담을 줄일 수 있다.

이번 출시에는 npm을 통해 배포되는 @litertjs/core 패키지가 포함됐다. Google은 LiteRT 저장소에서 브라우저 데모와 통합 예제도 제공한다. 이러한 리소스는 이번 발표가 단순한 로드맵 제시를 넘어선다는 점을 보여주지만, 실제 프로덕션 적용 가능성은 여전히 각 애플리케이션의 모델과 브라우저 지원 대상에 달려 있다.

이제 브라우저는 네이티브 기기에서 사용되는 더 넓은 런타임 제품군과 동일한 계열의 런타임을 통해 텍스트 생성, 객체 감지, 오디오 처리, 임베딩 모델을 호스팅할 수 있다. 이는 이미 엣지 AI를 제공하고 있는 팀에 더 명확한 배포 경로를 만든다.

로컬 실행 방식은 운영 모델도 바꾼다. 입력 데이터는 사용자의 기기에 남을 수 있고, 추론에 서버 왕복이 필요하지 않으며, 일부 기능은 네트워크 연결이 없어도 계속 작동할 수 있다.

그러나 이러한 이점은 자동으로 보장되지 않는다. 브라우저는 여전히 모델과 런타임을 다운로드해야 한다. 또한 기기는 응답성을 해치지 않고 작업을 실행할 수 있을 만큼 충분한 메모리와 연산 성능을 갖춰야 한다.

따라서 핵심 뉴스는 아키텍처에 있다. Google이 브라우저 기반 추론을 처음 도입하는 것은 아니다. 수년간의 네이티브 엣지 배포를 통해 다듬어진 런타임에 브라우저 개발자가 접근할 수 있도록 한 것이다.

지금 Google LiteRT.js의 고성능 웹 AI 추론이 중요한 이유

브라우저는 클라우드 모델을 위한 단순한 인터페이스가 아니라 AI 실행 대상이 되고 있다.

대부분의 생성형 AI 제품은 여전히 프롬프트와 기타 입력을 원격 인프라로 전송한다. 이 방식은 대형 모델, 중앙 집중식 업데이트, 소비자 하드웨어의 한계를 넘어서는 작업에 적합하다.

하지만 클라우드 추론에는 네트워크 지연, 지속적인 서비스 운영 비용, 데이터 전송에 대한 우려가 따른다. 안정적인 연결에 의존하게 되면서 원래는 로컬에서 처리할 수 있는 워크플로가 네트워크에 종속될 수도 있다.

브라우저 추론은 다른 방식을 제시한다. 애플리케이션이 적절한 모델을 다운로드하고 기기에서 데이터를 처리한 뒤, 매 요청마다 추론 엔드포인트에 접속하지 않고 결과를 반환하는 방식이다.

이 접근법은 모델이 작고 상호작용이 빈번한 작업에 적합하다. 웹캠 효과, 오디오 분류, 문서 임베딩, 이미지 개선, 객체 추적 등은 반복적인 네트워크 왕복을 피함으로써 이점을 얻을 수 있다.

Google의 벡터 검색 데모가 한 가지 예다. LiteRT.js는 브라우저 안에서 임베딩 모델을 실행해 텍스트를 로컬 유사도 검색에 활용할 수 있는 수치 표현으로 변환한다.

이 방식은 사용자가 제공한 제한된 콘텐츠 모음에서 비공개 검색을 지원할 수 있다. 또한 더 많은 비용이 드는 클라우드 모델을 요청하기 전에 애플리케이션이 로컬에서 항목의 순위를 매기는 데도 활용할 수 있다.

이번 출시는 주요 Chromium 브라우저에서 WebGPU가 실용적인 연산 옵션으로 자리 잡기 시작한 시점에 나왔다. WebGPU는 저수준 그래픽과 범용 연산을 중심으로 설계된 웹 표준을 통해 최신 GPU 기능을 제공한다.

WebNN은 다른 계층을 다룬다. 웹 애플리케이션에 그래프 기반 인터페이스를 제공하며, 브라우저 구현은 이를 플랫폼의 가속 프레임워크에 매핑할 수 있다. 시스템에 따라 이러한 프레임워크에는 Core ML과 Windows ML이 포함된다.

WebNN 사양은 여전히 개발 중이며 브라우저 지원도 제한적이다. Google은 Chrome과 Edge에서 WebNN 지원이 실험 단계라고 설명하고 있어, WebNN은 보편적인 프로덕션 경로라기보다 미래 지향적인 구성 요소에 가깝다.

이러한 공백 때문에 LiteRT.js는 여러 백엔드가 필요하다. WebGPU는 지원되는 시스템에서 폭넓은 GPU 가속을 제공할 수 있다. WebNN은 장기적으로 효율적인 NPU 실행을 제공할 수 있으며, WebAssembly는 그 외 환경에서도 애플리케이션이 작동하도록 유지한다.

Google 입장에서 이번 시점은 포트폴리오 문제와도 관련이 있다. Google은 이미 브라우저 머신러닝을 위한 TensorFlow.js와 네이티브 엣지 추론을 위한 LiteRT를 보유하고 있다. 최적화 경로를 별도로 유지하면 플랫폼 간 개선 사항을 이전하기가 더 어려워진다.

공유 런타임은 이에 대한 보다 직접적인 해법을 제시한다. 모델 변환, 양자화, 연산자 개선, 하드웨어별 작업을 여러 배포 대상으로 전달할 수 있다.

이 전략은 모바일 앱과 웹 앱에서 동일한 AI 기능을 유지 관리하는 개발자에게 중요하다. 공유 .tflite 아티팩트가 모든 플랫폼 차이를 없애지는 않지만, 관리해야 하는 모델 형식과 런타임 가정의 수를 줄여준다.

민감한 자료를 로컬에서 처리하는 방안을 검토하는 기업에도 중요하다. 추론을 기기에서 수행하면 외부 시스템으로 전송되는 데이터를 줄일 수 있지만, 개발자는 여전히 분석, 로깅, 모델 다운로드, 애플리케이션 코드를 점검해야 한다.

로컬 지식 워크플로를 구축하는 팀도 비슷한 선택에 직면한다. 검색 가능한 지식 베이스는 임베딩이나 분류 같은 작업에 로컬 모델을 사용하고, 더 복잡한 추론이 필요한 경우에는 대형 클라우드 모델을 활용할 수 있다.

모든 AI 작업을 브라우저로 옮기는 것보다 이러한 하이브리드 방식이 현실적일 가능성이 높다. LiteRT.js는 서버의 필요성을 없애지 않으면서 이 설계에서 로컬 처리 영역을 강화한다.

가장 먼저 압박을 받는 것은 기존 웹 추론 런타임이다. 이들은 모델 호환성, 실행 속도, 패키지 크기, 개발자 도구, 브라우저별 동작을 놓고 경쟁해야 한다.

클라우드 전용 애플리케이션 아키텍처도 영향을 받는다. 일반적인 인식, 검색, 미디어 작업이 클라이언트 하드웨어에서 충분한 수준으로 실행된다면, 개발자는 지연 시간과 인프라 사용량을 관리할 수 있는 또 하나의 방법을 얻게 된다.

네이티브 런타임, JavaScript 중심 AI에 도전하다

LiteRT.js는 런타임 통합을 통해 경쟁하고, 기존 대안은 모델 생태계와 브라우저 지원 범위를 통해 경쟁한다.

TensorFlow.js는 여전히 가장 명확한 역사적 기준점이다. 개발자는 TensorFlow.js를 통해 JavaScript로 머신러닝 모델을 구축하고 실행할 수 있으며, 백엔드로 WebGL과 WebAssembly 등을 사용할 수 있다.

Google은 이제 LiteRT.js가 .tflite 모델에 더 나은 실행 경로를 제공한다고 주장한다. 회사에 따르면 기존 TensorFlow.js 접근 방식은 효율성이 낮은 JavaScript 기반 커널에 의존했지만, LiteRT.js는 WebAssembly를 통해 네이티브 LiteRT 최적화를 노출한다.

그렇다고 TensorFlow.js가 obsolete해지는 것은 아니다. TensorFlow.js는 모델 생성, 학습, 텐서 연산, 이미 정립된 JavaScript API를 지원한다. 현재 LiteRT.js는 고성능 추론 런타임이라는 더 좁은 범위의 용도로 제시되고 있다.

이 구분은 중요하다. TensorFlow.js를 대화형 학습이나 맞춤형 텐서 연산에 사용하는 팀과 고정된 최적화 .tflite 모델을 배포하는 팀은 요구 사항이 다르다.

Google은 기존 TensorFlow.js 파이프라인 안에서 LiteRT.js 추론을 사용하는 방법도 안내한다. 이는 모든 TensorFlow.js 사용 사례를 즉시 대체하기보다 마이그레이션 과정에서 공존할 가능성을 시사한다.

ONNX Runtime Web은 더 직접적인 경쟁 비교 대상이다. 이미 WebAssembly, WebGL, WebGPU, WebNN 실행 프로바이더를 통해 브라우저 내 추론을 지원하고 있다.

웹 추론 가이드는 지연 시간 감소, 오프라인 작동, 개인정보 보호, 서버 작업 감소 등 로컬 실행의 장점을 설명한다. 동시에 핵심 제약도 인정한다. 클라이언트 측 모델은 성능이 낮은 하드웨어의 역량에 맞아야 한다는 점이다.

ONNX Runtime Web은 ONNX 모델을 사용하는 반면 LiteRT.js는 .tflite 아티팩트에 초점을 맞춘다. 기업이 이미 성숙한 변환, 검증, 배포 파이프라인을 갖추고 있다면 이러한 형식 선택이 벤치마크 결과보다 더 큰 영향을 미칠 수 있다.

PyTorch 중심의 팀은 이미 모델을 ONNX로 내보내고 있을 수 있다. LiteRT를 사용하는 모바일 팀은 기존 Android 및 iOS 배포 작업과 연계되는 .tflite를 선호할 수 있다.

가속 지원 범위 역시 단순하지 않다. ONNX Runtime Web은 WebAssembly와 기존 WebGL뿐 아니라 WebGPU와 WebNN도 지원한다고 문서화하고 있다. LiteRT.js는 WebGPU, WebNN, XNNPACK 기반 CPU 경로를 사용한다.

따라서 두 접근 방식 모두 동일한 근본 현실을 인정한다. 현재 어떤 단일 브라우저 가속 API도 모든 주요 기기를 포괄하지 못한다.

전략적 차이는 런타임의 기반에 있다. ONNX Runtime은 ONNX 형식을 중심으로 구축된 크로스 플랫폼 추론 시스템을 브라우저로 확장한다. Google은 LiteRT와 .tflite를 중심으로 자사의 엣지 런타임을 브라우저로 확장한다.

이는 단순히 빠른 패키지와 느린 패키지 간의 경쟁이 아니다. 배포 생태계 간의 경쟁이다.

Google은 이 경쟁에서 여러 자산을 보유하고 있다. LiteRT는 이미 Google의 모바일 및 엣지 도구 체계와 연결되어 있다. Kaggle은 사전 학습된 모델을 호스팅하고, LiteRT 커뮤니티는 Hugging Face에서 모델을 관리한다. Ultralytics도 YOLO 모델의 LiteRT 내보내기 지원을 추가했다.

Ultralytics 통합은 컴퓨터 비전 팀이 모델 도구에서 브라우저로 이어지는 구체적인 경로를 제공한다. Google의 시연에서는 LiteRT 스택을 통해 객체 탐지 모델 제품군인 YOLO26을 실행한다.

다른 시연은 가속화의 효과를 눈에 보이게 보여준다. 한 시연은 Depth Anything V2와 WebGPU를 사용해 웹캠 영상을 3차원 포인트 클라우드로 변환한다. 또 다른 시연은 Real-ESRGAN을 실행해 128×128픽셀 이미지 패치를 512×512픽셀로 확대한다.

이 사례들은 로컬 실행이 상호작용 측면에서 분명한 이점을 제공하는 작업을 보여준다. 사용자는 웹캠 깊이 추정이나 이미지 조작이 반복적인 업로드와 서버 응답을 기다리지 않고 지속적으로 반응하기를 기대한다.

다만 시연은 선별된 환경에서 이루어진다. 동일한 모델이 일반적인 스마트폰과 노트북에서 빠르게 로드되고, 배터리 수명을 유지하며, 일정한 프레임 속도를 보장한다는 점까지 입증하는 것은 아니다.

따라서 개발자 채택 여부는 운영상의 세부 사항에 달려 있다. 팀에는 예측 가능한 모델 변환, 충분한 연산자 지원, 유용한 오류 메시지, 관리 가능한 번들 크기, 프로파일링 도구가 필요하다.

마이그레이션 경로도 필요하다. 팀이 모델 출력을 재현하고 전처리 및 후처리를 과도한 엔지니어링 작업 없이 통합할 수 있을 때에야 런타임 성능이 의미를 갖는다.

Google LiteRT.js high-performance Web AI inference는 기존 LiteRT 사용자에게 설득력 있는 이점을 제공한다. 과제는 공유 런타임이 이미 ONNX Runtime Web이나 TensorFlow.js에 투자한 팀을 끌어들일 만큼 충분한 이점을 제공하는지 입증하는 것이다.

성능 주장이 브라우저 현실과 만나는 지점

Google의 벤치마크는 고무적이지만, 하드웨어의 다양성과 실험적 API 때문에 개발자가 도출할 수 있는 결론에는 한계가 있다.

Google은 LiteRT.js가 전통적인 컴퓨터 비전 및 오디오 처리 모델의 CPU·GPU 추론 전반에서 다른 웹 런타임보다 최대 3배 높은 성능을 보였다고 밝혔다.

또한 WebGPU와 WebNN을 통한 GPU 또는 NPU 실행이 일부 테스트에서 일반적인 CPU 실행보다 5배에서 60배까지 빠른 성능 향상을 보였다고 보고했다.

이러한 주장은 적용 범위를 신중하게 설정해 해석해야 한다. Google은 2024년형 Apple M4 실리콘 탑재 MacBook Pro에서 통제된 브라우저 환경으로 공개 벤치마크를 진행했다.

Google은 GPU 성능, 열 스로틀링, 브라우저 드라이버 최적화에 따라 결과가 달라질 수 있다고 명시적으로 설명한다. 이 단서는 이번 발표를 평가하는 데 핵심적이다.

고성능 M4 노트북은 로컬 추론에 유리한 환경을 제공한다. 그러나 많은 웹 방문자는 구형 노트북, 저가형 스마트폰, 관리형 기업 기기 또는 가속화 지원이 다른 브라우저를 사용한다.

웹의 강점은 폭넓은 배포에 있지만, 이러한 배포 범위는 테스트 문제를 낳는다. 개발자는 통제된 기기군에 배포되는 네이티브 애플리케이션처럼 특정 하드웨어를 기준으로 최적화하기 어렵다.

WebGPU의 이용 가능성은 개선되었지만, 브라우저와 운영체제 전반의 지원은 여전히 고르지 않다. 따라서 기능 감지는 필수적이다. GPU 초기화에 실패하거나 특정 연산이 가속화를 지원하지 않을 때 사용할 수 있는 실용적인 대체 경로도 필요하다.

WebNN은 더 큰 성숙도 시험에 직면해 있다. Google은 Chrome과 Edge에서 WebNN을 실험적 기능으로 규정한다. WebNN의 가치는 상당하다. 신경망 그래프를 NPU를 비롯한 전용 플랫폼 가속기에 매핑할 수 있기 때문이다.

그러나 실험적 기능이라는 특성상 개발자는 WebNN을 일반 대중용 애플리케이션의 기본 경로로 취급할 수 없다. 구현 현황 대시보드는 Chromium과 플랫폼 백엔드 전반의 연산 지원 현황을 추적하며, 지원이 연산자 단위로 발전하고 있음을 보여준다.

연산자 지원 범위는 모델 전체가 가속기에서 실행될 수 있는지를 좌우한다. 지원되지 않는 연산이 오류를 일으키거나 더 느린 대체 실행으로 전환되면, 눈에 띄는 속도 향상 수치가 애플리케이션 전체를 설명하지 못할 수 있다.

모델 다운로드 시간도 제약 요인이다. 로컬 추론은 반복적인 서버 요청을 없애지만, 브라우저가 먼저 모델 가중치와 런타임 파일을 받아야 한다. 대용량 아티팩트는 첫 유용한 상호작용까지의 시간을 늘릴 수 있다.

캐싱은 재방문 사용자에게 도움이 되지만, 저장소 정책과 브라우저의 캐시 삭제로 인해 그 효과가 일관되지 않을 수 있다. 모바일 연결 환경에서는 초기 페이로드 크기도 더욱 중요하다.

메모리 사용량도 관련 문제를 일으킨다. 최신 노트북에서는 여유 있게 실행되는 모델이더라도 브라우저와 페이지, 다른 탭이 가용 자원을 점유하면 스마트폰에서는 부담이 될 수 있다.

개발자는 메인 스레드의 반응성도 고려해야 한다. 모델 자체가 정상적으로 실행되더라도 무거운 전처리, 텐서 전송 또는 CPU 대체 실행이 인터페이스를 멈추게 할 수 있다.

GPU와의 데이터 이동에는 특히 주의해야 한다. CPU 메모리에서 GPU로 입력을 보내고 출력을 되돌리는 과정에서 가속 추론으로 절약한 지연 시간의 일부가 소모될 수 있다.

중간 텐서를 GPU에 유지하는 애플리케이션은 이러한 전송을 줄일 수 있다. 이를 위해서는 세심한 메모리 관리와 JavaScript 배열로 불필요하게 데이터를 내려받지 않는 설계가 필요하다.

ONNX Runtime의 WebGPU 문서도 GPU 상주 텐서와 입출력 바인딩을 지원하며 같은 문제를 강조한다. 여러 런타임에 유사한 메커니즘이 존재한다는 점은 커널 속도가 애플리케이션 성능을 구성하는 여러 요소 중 하나일 뿐임을 보여준다.

개인정보 보호에 대한 주장도 정확하게 다뤄야 한다. 로컬 추론은 원시 입력을 기기에 보관할 수 있지만, 로컬 모델을 사용한다고 해서 애플리케이션 전체가 자동으로 비공개가 되는 것은 아니다.

페이지는 여전히 분석 데이터, 오류 로그, 식별자, 프롬프트 또는 파생 결과를 전송할 수 있다. 개발자는 런타임이 어디에서 실행되는지만으로 개인정보 보호를 추론하지 말고 전체 데이터 흐름을 점검해야 한다.

모델 노출은 정반대의 우려를 낳는다. 클라이언트 측 애플리케이션은 사용자의 기기에 모델을 전달해야 하므로, 서버에서 호스팅하는 모델보다 가중치에 접근하기가 쉬워진다.

이러한 절충은 오픈 모델과 일반적인 인식 작업에서는 받아들일 수 있다. 그러나 가중치에 귀중한 데이터나 제품 로직이 담긴 독점 모델에는 받아들이기 어려울 수 있다.

보안 경계 역시 여전히 중요하다. 로컬 추론은 일부 데이터 전송을 줄이지만, 신뢰할 수 없는 웹 콘텐츠, 손상된 종속성, 악성 모델 파일은 다른 위험을 만들 수 있다.

따라서 Google의 성능 증거를 가장 강하게 해석하더라도 결론은 제한적이어야 한다. LiteRT.js는 지원되는 하드웨어에서 일부 모델을 크게 가속할 수 있으며, 네이티브 런타임 기반은 진지하게 평가할 가치가 있다.

그러나 이 증거만으로는 공개 웹 환경 전반에서 일관된 성능 향상이 나타난다고 입증할 수 없다. 독립적인 테스트에서는 여러 브라우저, 운영체제, 기기 등급, 모델 제품군, 지속 실행 작업을 포괄해야 한다.

엔지니어링 팀이 기준으로 삼아야 할 벤치마크는 자체 애플리케이션의 성능이다. 모델 다운로드, 초기화, 워밍업, 전처리, 추론, 후처리, 메모리 사용량, 전력 소비, 대체 실행 동작을 모두 포함해야 한다.

로컬 브라우저 추론이 가장 적합한 영역

LiteRT.js는 로컬 실행이 네트워크 지연이나 반복적인 데이터 전송으로 발생하는 상호작용 저하를 개선할 때 가장 설득력 있다.

실시간 컴퓨터 비전은 대표적인 분야다. 객체 탐지, 배경 처리, 제스처 인식, 깊이 추정은 카메라 프레임을 지속적으로 분석해야 할 수 있다.

이러한 프레임을 서버에 업로드하면 대역폭과 지연 시간이 늘어난다. 일부 사용자나 조직이 받아들이지 않을 수 있는 민감한 데이터 스트림도 만들어진다.

로컬 오디오 처리도 비슷한 이점을 제공한다. 키워드 감지, 소리 분류, 제한적인 음성 인식 작업은 녹음을 계속 외부로 전송하지 않고 마이크 입력을 처리할 수 있다.

문서 워크플로도 실용적인 분야다. 브라우저 애플리케이션은 클라우드 모델을 호출하기 전에 로컬 텍스트의 임베딩을 생성하거나, 문서를 분류하거나, 문단의 순위를 매길 수 있다.

이 방식은 계층형 아키텍처를 지원한다. 작고 빈번한 작업은 로컬에서 실행하고, 더 폭넓은 지식이나 연산이 필요한 요청은 대규모 언어 모델이 처리한다.

이미지 조작도 자연스러운 활용 분야다. Google의 Real-ESRGAN 시연은 브라우저에서 패치를 로컬로 처리한 뒤 확대된 이미지를 재구성한다.

가치는 단순히 지연 시간이 줄어드는 데 있지 않다. 로컬 처리를 사용하면 원본 이미지를 업로드하고, 서버 대기열을 기다리고, 결과를 다시 다운로드할 필요가 없다.

오프라인 지원 애플리케이션도 이점을 얻는다. 현장 근무자, 여행자, 학생은 연결이 끊겨도 일부 AI 기능을 계속 사용할 수 있다.

프로그레시브 웹 애플리케이션은 캐시된 모델을 로컬 저장소 및 서비스 워커와 결합할 수 있다. 모든 네이티브 기능을 대체할 수는 없지만, URL을 통해 유용한 추론 기능을 제공할 수 있다.

이러한 시나리오에는 공통된 특성이 있다. 클라이언트 하드웨어에서 실행할 수 있을 만큼 작은 모델을 사용하고, 빠르고 반복적인 실행에서 가치를 얻으며, 지속적으로 갱신되는 서버 측 지식이 필요하지 않다.

대규모 생성 모델은 더 어려운 사례다. 파라미터 수가 증가하면 모델 크기, 메모리 부담, 토큰 생성 속도, 배터리 사용량이 중요한 문제가 된다.

Google은 브라우저 언어 모델 지원을 위해 LiteRT-LM.js를 제시하고, 최적화된 온디바이스 생성형 AI를 로드맵의 주요 우선순위로 꼽았다. 이 방향은 중요하지만, 초기 LiteRT.js 출시 제품에 대한 기대를 규정해서는 안 된다.

초기 패키지는 인식, 임베딩, 기타 범위가 제한된 추론 작업에서 가장 강점을 보일 것으로 보인다. 이러한 워크로드는 브라우저 자원 및 확립된 양자화 기법과 더 잘 맞는다.

기업은 로컬 AI를 기본값으로 삼기 전에 거버넌스도 마련해야 한다. 어떤 모델 버전을 배포할지, 업데이트는 어떻게 진행할지, 어떤 기기가 대상인지, 대체 실행이 사용자 기대에 어떤 영향을 미칠지 결정해야 한다.

추론이 다양한 클라이언트 하드웨어에서 실행되면 모니터링도 복잡해진다. 서버 측 시스템은 중앙에서 지연 시간과 오류 지표를 확인할 수 있지만, 브라우저 실행에서는 개인정보 보호 목표를 훼손하지 않는 신중한 텔레메트리가 필요하다.

품질 보증은 수치 출력과 사용자 경험을 모두 다뤄야 한다. 양자화된 모델은 더 빠르게 실행되고 공간도 덜 차지하지만, 팀은 특정 데이터에서 정확도가 허용 가능한 수준으로 유지되는지 확인해야 한다.

접근성 역시 테스트에 포함되어야 한다. CPU 자원을 과도하게 사용하는 AI 기능은 보조 기술을 방해하거나 구형 기기에서 반응성을 떨어뜨릴 수 있다.

제품 팀에게 LiteRT.js는 이러한 결정을 없애주지 않는다. 대신 Google의 네이티브 엣지 스택과 더 긴밀하게 연결된 또 하나의 실행 계층을 제공한다.

가장 적절한 도입 전략은 선택적으로 시작하는 것일 가능성이 크다. 범위가 제한된 기능 하나부터 시작해 대표적인 기기에서 전체 경험을 측정하고, 지원되지 않는 환경을 위한 대체 경로를 유지하는 방식이다.

로컬 경로가 품질 및 반응성 목표를 충족하면 적용 범위를 넓힐 수 있다. 그렇지 않다면 동일한 애플리케이션에서 부담이 큰 작업을 서버로 전달할 수 있다.

이러한 유연성은 브라우저가 클라우드 추론을 대체해야 한다는 일괄적인 주장보다 가치가 크다. LiteRT.js는 하이브리드 설계를 더 쉽게 검토하게 해주지만, 적절한 경계는 여전히 워크로드가 결정한다.

세 가지 신호가 LiteRT.js의 채택을 결정한다

다음 단계는 브라우저 지원, 독립적인 성능 결과, 개발자가 실제 애플리케이션을 런타임으로 이전할 수 있다는 증거에 달려 있다.

첫 번째 신호는 WebNN이 실험적 접근 단계에서 일반적인 브라우저 이용 가능 단계로 발전하는지 여부다. 전용 NPU 실행은 지연 시간과 에너지 효율을 개선할 수 있다는 점에서 LiteRT.js의 가장 흥미로운 약속 중 하나다.

WebNN 지원이 확대되면 Google의 통합 런타임 주장이 더욱 힘을 얻을 것이다. 플래그나 제한된 플랫폼에 계속 의존한다면 대부분의 프로덕션 워크로드는 WebGPU와 WebAssembly가 맡게 될 것이다.

두 번째 신호는 독립적인 벤치마킹입니다. 테스트는 다양한 노트북, 휴대전화, 브라우저, 모델 유형에서 LiteRT.js를 ONNX Runtime Web 및 TensorFlow.js와 비교해야 합니다.

Google의 M4 설정을 벗어난 환경에서도 일관된 성능 향상이 확인된다면, 고성능 Web AI 추론이라는 주장은 더욱 힘을 얻을 것입니다. 편차가 크거나 지원되지 않는 연산자가 많고 초기화 비용이 높다면 적합한 애플리케이션의 범위는 좁아질 수 있습니다.

세 번째 신호는 데모를 넘어선 실제 제품 도입입니다. 카메라 도구, 미디어 애플리케이션, 프라이빗 검색, 오프라인 워크플로에 LiteRT.js를 적용해 출시하는 팀이 등장하는지 지켜봐야 합니다.

Ultralytics 내보내기 지원은 널리 사용되는 비전 생태계와 LiteRT 배포를 연결한다는 점에서 유용한 출발점입니다. 더 강력한 검증은 개발자들이 변환 성공 여부, 패키지 오버헤드, 디바이스 지원 범위, 측정 가능한 사용자 편익을 문서화할 때 이뤄질 것입니다.

Google은 시간이 지나면서 LiteRT.js와 TensorFlow.js가 각각 어떤 역할을 맡게 될지도 명확히 설명해야 합니다. Google이 엣지 도구를 통합해 나가는 상황에서 개발자들은 현재의 아키텍처가 앞으로도 지원될 것이라는 확신이 필요합니다.

이번 출시는 네이티브 엣지 인프라를 기반으로 한 신뢰할 만한 브라우저 런타임을 Google에 제공합니다. 하지만 ONNX Runtime Web이 이미 유사한 백엔드를 지원하고 서로 다른 모델 생태계를 대상으로 하고 있기 때문에, 웹 추론 경쟁의 승패를 결정짓지는 못합니다.

개발자가 당장 취할 수 있는 조치는 실용적입니다. 대표 모델 하나를 선정해 가속 경로와 CPU 경로를 테스트한 뒤, 전체 사용자 경험을 측정해야 합니다. Google LiteRT.js의 고성능 Web AI 추론은 실제 디바이스, 실제 브라우저, 실제 애플리케이션의 제약 속에서도 런타임 성능 향상이 유지될 때 비로소 중요한 의미를 갖게 됩니다.