LiteRT.js 브라우저 AI 추론 공개: WebGPU·WebNN으로 클라이언트 사이드 ML을 운영하는 법

요약: Google이 LiteRT.js를 공개하면서 브라우저 안에서 .tflite 모델을 실행하는 선택지가 더 현실적이 됐다. 개인정보, 서버 비용, 지연 시간 때문에 클라이언트 사이드 AI를 검토하던 팀이라면 TensorFlow.js와 WebAssembly 기반 런타임의 역할을 다시 봐야 한다.

Google Developers Blog는 2026년 7월 9일 LiteRT.js를 발표했다. LiteRT.js는 LiteRT의 JavaScript 바인딩으로, 웹 브라우저 안에서 ML·AI 모델을 로컬 실행하기 위한 런타임이다. Google은 이 접근이 사용자 개인정보 보호, 서버 비용 절감, 초저지연 실시간 경험에 유리하다고 설명한다. 특히 기존 .tflite 모델을 가진 팀에게는 모바일·데스크톱 웹 배포를 더 부드럽게 만드는 경로가 된다.

이 발표가 의미 있는 이유는 “브라우저 AI”가 더 이상 데모용 장난감만은 아니라는 점이다. 이미지 업스케일링, 객체 탐지, 오디오 처리, 웹캠 기반 인터랙션처럼 입력 데이터가 사용자 기기 안에서 발생하고 즉시 반응해야 하는 기능은 서버 왕복이 오히려 제품 품질을 떨어뜨린다. LiteRT.js는 WebAssembly, WebGPU, WebNN 같은 웹 실행 경로 위에 LiteRT의 최적화 스택을 얹는 방향이다.

LiteRT.js가 해결하려는 문제

기존 웹 AI 구현은 보통 두 갈래였다. 하나는 서버에서 모델을 돌리고 브라우저는 결과만 받는 방식이다. 구현은 단순하지만 네트워크 지연, 서버 비용, 개인정보 이슈가 생긴다. 다른 하나는 TensorFlow.js처럼 브라우저에서 모델을 실행하는 방식이다. 이 경우 서버 문제는 줄지만 모델 포맷, 성능, 하드웨어 가속, 메모리 관리가 까다롭다.

LiteRT.js는 후자의 문제를 줄이려는 시도다. Google 설명에 따르면 LiteRT.js는 기존 JavaScript 기반 커널에 의존하는 방식이 아니라, LiteRT의 네이티브 크로스 플랫폼 런타임과 최적화를 WebAssembly로 웹 개발자에게 제공한다. CPU에서는 XNNPACK, GPU에서는 WebGPU 기반 경로, 앞으로는 WebNN을 통한 NPU 활용까지 바라본다.

개발자에게 중요한 건 화려한 용어가 아니라 배포 경로다. 이미 모바일 앱에서 .tflite 모델을 쓰고 있다면 웹에서도 같은 계열의 모델 자산을 활용할 수 있다. PyTorch 모델은 LiteRT Torch를 통해 변환할 수 있고, AI Edge Quantizer로 계층별 양자화도 다룰 수 있다. 모델을 새로 학습하는 팀보다 “이미 있는 모델을 제품에 넣어야 하는 팀”에게 먼저 유용하다.

성능 수치를 어떻게 해석해야 하나

Google은 LiteRT.js가 기존 웹 런타임 대비 CPU와 GPU 추론에서 최대 3배 속도 향상을 보였고, WebGPU 또는 WebNN을 활용하는 실시간 애플리케이션에서는 표준 CPU 실행 대비 5~60배 속도 향상을 보였다고 설명한다. 단, 벤치마크는 2024년형 Apple MacBook Pro M4 환경의 통제된 브라우저에서 수행됐고, 실제 성능은 사용자 GPU, 발열, 브라우저 드라이버 최적화에 따라 달라질 수 있다고 명시했다.

이 문장을 그대로 제품 계획에 넣으면 위험하다. “최대 60배”는 마케팅 숫자로 보면 되고, 운영 판단에는 기기별 P50, P90, P99 지연 시간을 따로 재야 한다. 특히 웹캠 기반 객체 탐지나 오디오 스트리밍처럼 프레임 단위로 반응해야 하는 기능은 평균보다 tail latency가 중요하다. 10번 중 9번 빠르고 1번 멈추면 사용자는 기능이 불안정하다고 느낀다.

성능 검증은 최소 4개 그룹으로 나누는 게 좋다. 최신 데스크톱 Chrome, 보급형 Windows 노트북, Android Chrome, iOS Safari다. WebGPU와 WebNN 지원 여부도 브라우저마다 다르다. LiteRT.js가 fallback을 제공하더라도 fallback 경로가 제품 요구사항을 만족하는지 확인해야 한다.

어떤 기능에 먼저 적용할 만한가

LiteRT.js는 입력 데이터가 크고 민감하며, 결과가 즉시 필요하고, 모델이 상대적으로 작거나 양자화 가능한 경우에 잘 맞는다. 예를 들어 브라우저 이미지 보정, 배경 제거 미리보기, 객체 탐지, 포즈 추정, 문서 스캔 품질 검사, 오디오 노이즈 분석, 로컬 키워드 감지 같은 기능이다.

반대로 대형 언어 모델 전체를 브라우저에서 안정적으로 돌리는 것을 1차 목표로 잡으면 난이도가 올라간다. Google은 LiteRT-LM.js를 통해 브라우저 LLM 지원도 언급하지만, 제품에서 먼저 노려야 할 영역은 고전적인 비전·오디오 모델과 작은 분류 모델이다. 이런 모델은 입력과 출력이 명확하고, 결과 검증도 쉽다.

예를 들어 이커머스 관리자 도구에서 상품 사진 품질을 검사한다고 하자. 서버 업로드 전에 브라우저에서 흐림, 노출, 배경, 객체 위치를 검사하면 불필요한 업로드와 서버 추론 비용을 줄일 수 있다. 사용자는 즉시 피드백을 받고, 서버는 최종 저장 이미지만 처리한다. 이런 사용 사례가 LiteRT.js의 현실적인 시작점이다.

구현 시 주의할 브라우저 운영 이슈

첫 번째 이슈는 모델 파일 크기다. 모델이 30MB만 넘어도 초기 로딩 경험이 나빠진다. 사용자가 버튼을 눌렀을 때 모델을 처음 받게 하면 기능이 멈춘 것처럼 보인다. 모델은 route prefetch, service worker cache, lazy warmup을 조합해 준비해야 한다. 단, 모든 사용자에게 미리 내려받게 하면 트래픽 낭비가 되므로 기능 노출 조건에 맞춰야 한다.

두 번째는 메모리 해제다. 브라우저 추론은 GPU 리소스와 typed array를 많이 쓴다. React 컴포넌트가 unmount됐는데 세션이나 tensor가 살아 있으면 탭이 느려진다. inference session lifecycle을 UI 컴포넌트와 분리하고, 명시적인 dispose 경로를 만들어야 한다.

세 번째는 개인정보 고지다. 클라이언트 사이드 추론은 “서버로 안 보낸다”는 장점이 있지만, 사용자는 그 사실을 모른다. 카메라, 마이크, 파일 입력을 다루는 기능이라면 “분석은 기기 안에서 처리되며 원본은 업로드되지 않습니다” 같은 문구가 전환율과 신뢰에 영향을 준다. 실제로 서버 업로드가 없는지 네트워크 탭으로 검증하고 정책 문서에도 맞춰야 한다.

TensorFlow.js 사용자라면 어떻게 봐야 하나

TensorFlow.js를 이미 쓰는 팀은 당장 전부 갈아엎기보다 모델별로 평가하는 게 맞다. Google도 TensorFlow.js 파이프라인에서 LiteRT.js를 활용하는 경로를 문서로 연결했다. 핵심 질문은 세 가지다. 첫째, 현재 모델을 .tflite로 안정 변환할 수 있는가. 둘째, LiteRT.js 실행 경로에서 정확도가 유지되는가. 셋째, 실제 대상 기기에서 체감 성능이 개선되는가.

마이그레이션은 가장 비용이 큰 모델부터 하지 말고, 사용자 가치가 명확하고 실패해도 되돌리기 쉬운 기능부터 시작한다. 예를 들어 “이미지 업로드 전 품질 점수”는 실패해도 서버 업로드를 막지만 않으면 피해가 작다. 반면 결제 전 본인 인증, 의료 판단, 법적 검토처럼 실패 비용이 큰 기능은 충분한 계측 뒤에 적용해야 한다.

성능 계측에는 모델 로드 시간, 컴파일 시간, 첫 추론 시간, 반복 추론 시간, 메모리 사용량, fallback 비율을 포함한다. 단순히 run 함수만 빠른지 보지 말고 사용자가 기능을 처음 눌렀을 때부터 결과를 보는 전체 시간을 재야 한다.

개발팀 실행 체크리스트

• LiteRT.js 적용 후보를 “민감한 입력”, “낮은 지연 시간”, “서버 비용 절감” 기준으로 3개만 고른다.
• 각 후보 모델의 .tflite 변환 가능성과 양자화 후 정확도 변화를 먼저 확인한다.
• WebGPU, WebNN, WASM fallback별 성능을 대상 브라우저에서 따로 측정한다.
• 모델 로드 시간과 첫 추론 시간을 제품 지표로 기록한다. 반복 추론 시간만 보지 않는다.
• 모델 파일은 service worker cache 또는 기능 진입 전 lazy warmup으로 준비한다.
• tensor와 GPU 리소스 해제 경로를 테스트한다. 탭을 10분 켜둔 뒤 메모리 누수를 본다.
• 개인정보 문구와 실제 네트워크 동작을 일치시킨다. 로컬 처리라고 쓰고 업로드하면 신뢰가 깨진다.
• 실패 시 서버 추론으로 fallback할지, 기능을 비활성화할지 정책을 정한다.