LiteRT.js 공개: 브라우저 온디바이스 AI가 서버 비용을 줄이는 현실적인 구간

요약: Google이 2026년 7월 9일 LiteRT.js를 공개했습니다. .tflite 모델을 JavaScript와 TypeScript 웹 앱에서 직접 실행하기 위한 런타임이며, WebAssembly, WebGPU, WebNN 경로를 통해 CPU·GPU·NPU 가속을 노립니다. 중요한 포인트는 “모든 AI를 브라우저로 옮기자”가 아니라, 서버 호출이 낭비인 작은 추론 작업을 프론트엔드로 내릴 수 있다는 점입니다.

LiteRT.js가 해결하려는 문제

웹 앱에 AI 기능을 붙이면 가장 먼저 서버 비용이 늘어납니다. 이미지 보정, 객체 감지, 음성 전처리, 간단한 분류처럼 사용자가 자주 호출하는 기능은 요청 수가 곧 비용입니다. 게다가 사용자가 업로드한 이미지나 오디오를 서버로 보내야 하므로 개인정보 처리 범위도 커집니다.

LiteRT.js는 이 문제를 브라우저 안에서 해결하려는 선택지입니다. Google의 온디바이스 추론 런타임인 LiteRT를 웹으로 가져와 .tflite 모델을 로컬에서 실행하게 합니다. 기존 TensorFlow.js가 JavaScript 기반 커널에 기대는 구간이 많았다면, LiteRT.js는 WebAssembly와 하드웨어 가속 백엔드를 통해 네이티브 런타임의 최적화를 웹에서 쓰는 쪽에 가깝습니다.

Google 발표에 따르면 초기 릴리스는 @litertjs/core npm 패키지와 데모를 제공합니다. CPU에서는 XNNPACK, GPU에서는 WebGPU 기반 ML Drift, NPU 쪽은 Chrome과 Edge에서 실험 중인 WebNN API를 겨냥합니다. 벤치마크도 공개됐는데, 일부 컴퓨터비전·오디오 모델에서 기존 웹 런타임 대비 최대 3배, CPU 대비 GPU/NPU 경로에서는 5~60배 속도 향상을 언급했습니다. 단, 이 수치는 2024년형 M4 MacBook Pro의 통제된 브라우저 환경 기준이라 그대로 제품 SLA로 쓰면 안 됩니다.

서버 AI와 브라우저 AI를 나누는 기준

온디바이스 AI는 멋있어 보이지만 만능이 아닙니다. 실무 기준은 단순합니다. 입력 데이터가 작고, 모델이 작고, 결과가 즉시 필요하고, 개인정보 이동을 줄이고 싶다면 브라우저 실행을 검토할 가치가 있습니다.

예를 들어 이미지 업로드 전에 얼굴 또는 객체를 감지해 자동 크롭하는 기능은 브라우저가 적합합니다. 사용자가 이미지를 서버로 보내기 전에 품질을 검사하거나, 흐림 정도를 판단하거나, 배경 제거 가능성을 미리 알려주는 것도 좋은 후보입니다. 오디오 앱에서는 잡음 수준 측정, 짧은 음성 이벤트 감지, 로컬 키워드 감지가 맞습니다.

반대로 대형 언어모델 추론, 장문 생성, 복잡한 RAG, 결제나 권한 변경처럼 서버 검증이 필요한 작업은 브라우저로 내리면 안 됩니다. 모델 파일 크기가 크면 첫 로딩이 느려지고, 기기 성능 편차가 UX 편차로 이어집니다. 브라우저 AI는 서버 AI를 대체하는 전략이 아니라, 서버로 보낼 필요가 없는 반복 추론을 줄이는 전략입니다.

성능보다 먼저 봐야 할 배포 조건

LiteRT.js를 검토할 때 벤치마크 숫자만 보면 위험합니다. 실제 제품에서는 모델 다운로드 크기, 브라우저 지원, WebGPU 활성화 여부, 모바일 기기 발열, 배터리, 메모리 제한이 더 큰 변수가 됩니다.

첫 번째는 모델 크기입니다. .tflite 파일이 수십 MB를 넘으면 초기 로딩에서 이탈이 생깁니다. 따라서 모델은 lazy load하고, 기능 진입 전에 미리 받거나, 와이파이 환경에서만 고해상도 모델을 쓰는 정책을 고려해야 합니다. 캐시 전략도 필요합니다. Service Worker와 Cache Storage를 활용하되, 모델 버전이 바뀔 때 이전 파일을 정리해야 합니다.

두 번째는 백엔드 선택입니다. CPU 경로는 가장 넓게 동작하지만 속도가 제한됩니다. WebGPU는 성능이 좋지만 브라우저와 드라이버 영향을 받습니다. WebNN은 NPU를 노리지만 아직 실험적입니다. 운영 서비스라면 webgpu -> wasm CPU fallback 순서처럼 단계적 fallback을 설계해야 합니다.

세 번째는 테스트 매트릭스입니다. 개발자의 M4 MacBook에서 빠르다고 안드로이드 중급기에서 빠른 것은 아닙니다. 최소한 iOS Safari, Chrome Android, 데스크톱 Chrome, 저전력 노트북을 나눠 측정해야 합니다. 측정 항목은 첫 모델 로딩 시간, 첫 추론 시간, 평균 추론 시간, 메모리 피크, 실패율, 배터리 영향입니다.

프론트엔드 구조는 이렇게 잡는 편이 안전하다

LiteRT.js 같은 브라우저 추론 기능은 UI 컴포넌트 안에 바로 넣지 않는 것이 좋습니다. 모델 로딩, 백엔드 선택, 텐서 변환, 결과 후처리를 inference service로 분리하세요. React 기준으로는 hook이 아니라 독립 모듈 또는 Web Worker에 가깝게 두는 편이 안전합니다.

추천 구조는 네 단계입니다. 첫째, modelRegistry가 모델 URL, 버전, 입력 크기, 지원 백엔드를 관리합니다. 둘째, runtimeLoader가 LiteRT wasm 경로와 accelerator 옵션을 초기화합니다. 셋째, inferenceWorker가 이미지나 오디오를 tensor로 바꿔 실행합니다. 넷째, UI는 결과만 받아 표시합니다.

Web Worker를 쓰는 이유는 메인 스레드 정지 때문입니다. 모델 로딩과 이미지 전처리가 UI 스레드를 잡아먹으면 사용자는 “AI가 느리다”가 아니라 “앱이 버벅인다”고 느낍니다. 특히 카메라 프리뷰, 드래그앤드롭 이미지 편집, 실시간 오디오 UI에서는 Worker 분리가 거의 필수입니다.

비용 절감 효과를 계산하는 방법

온디바이스 AI 도입은 기술 과시가 아니라 비용 구조 개선으로 봐야 합니다. 계산식은 간단합니다. 월간 기능 호출 수, 서버 추론 1회 비용, 브라우저 성공 처리율, fallback 서버 호출률을 놓고 비교하면 됩니다.

예를 들어 월 100만 번 호출되는 이미지 품질 검사 기능이 있고, 서버에서 1회 처리 비용이 0.3원이라고 가정하면 월 30만 원입니다. 브라우저에서 80%를 처리하고 20%만 서버 fallback을 태우면 단순 추론 비용은 월 6만 원으로 줄어듭니다. 여기에 업로드 트래픽과 저장 비용, 개인정보 처리 리스크도 같이 줄어듭니다.

다만 반대 비용도 있습니다. 모델 배포 CDN 비용, 초기 로딩으로 인한 이탈, 기기별 QA, fallback 서버 유지 비용입니다. 따라서 고빈도·저위험·소형 모델 기능부터 시작해야 합니다. “문서 전체를 로컬 LLM으로 요약”보다 “이미지 업로드 전 품질 검사”가 훨씬 좋은 첫 프로젝트입니다.

어떤 제품에 먼저 적용할 만한가

개발자 입장에서 LiteRT.js의 초기 적용처는 명확합니다. 이미지·비디오 편집 SaaS, 브라우저 기반 디자인 툴, 교육 앱, 헬스케어 전처리, 커머스 이미지 검수, 현장 점검 PWA가 후보입니다.

커머스 관리자 페이지라면 상품 이미지 업로드 전에 해상도, 흐림, 객체 위치, 배경 품질을 로컬에서 검사할 수 있습니다. 교육 앱이라면 손글씨나 발음의 1차 피드백을 서버 전송 전에 처리할 수 있습니다. 현장 점검 앱이라면 네트워크가 불안정한 환경에서도 사진 분류를 먼저 하고, 최종 결과만 동기화할 수 있습니다.

중요한 것은 “AI 기능”이라는 이름으로 크게 시작하지 않는 것입니다. 사용자에게는 “업로드 전에 문제를 바로 알려주는 기능”, “오프라인에서도 동작하는 검사”, “사진이 서버로 가기 전에 미리 처리”처럼 구체적 가치로 보여야 합니다.

실행 체크리스트

• 서버 호출이 많은 소형 추론 기능부터 후보를 고른다.
• 모델 파일 크기, 첫 로딩 시간, 평균 추론 시간, 메모리 사용량을 먼저 측정한다.
• WebGPU를 기본 후보로 보되 wasm CPU fallback을 반드시 둔다.
• 모델 로딩과 추론은 UI 컴포넌트가 아니라 별도 inference service나 Web Worker로 분리한다.
• iOS Safari, Android Chrome, 데스크톱 Chrome, 저사양 노트북에서 성능을 따로 측정한다.
• 사용자 데이터가 서버로 가지 않아도 되는 구간을 먼저 찾아 개인정보 처리 범위를 줄인다.
• CDN 캐시와 모델 버전 정리 정책을 만든다.
• 서버 비용 절감액에서 QA·CDN·fallback 유지 비용을 뺀 실제 순효과를 계산한다.