LiteRT.js 공개: 브라우저 온디바이스 AI가 웹 앱 구조를 바꾸는 이유

Google이 LiteRT.js를 공개했다. LiteRT.js는 웹 브라우저 안에서 AI 모델을 로컬로 실행하기 위한 JavaScript 바인딩이다. 핵심은 서버 API 호출 없이 클라이언트에서 .tflite 모델을 돌릴 수 있다는 점이다. 웹 개발자 입장에서는 개인정보, 지연 시간, 서버 비용, 오프라인 동작을 동시에 다시 설계할 수 있는 옵션이 생긴다.

이번 소식은 “브라우저에서도 AI가 된다” 정도로 끝낼 일이 아니다. 이미 TensorFlow.js를 써본 팀이라면 성능과 배포 복잡도 때문에 포기한 경험이 있을 수 있다. LiteRT.js는 WebAssembly, XNNPACK, WebGPU, WebNN 같은 실행 경로를 활용해 브라우저 추론을 더 현실적인 선택지로 만들려는 시도다.

핵심 키워드는 LiteRT.js, 브라우저 AI, 온디바이스 AI, Web AI inference다. 검색 의도는 두 가지다. 하나는 최신 Google AI 개발자 뉴스를 확인하려는 의도이고, 다른 하나는 실제 웹 앱에 로컬 추론을 넣을 수 있는지 검토하려는 의도다. 그래서 발표 내용과 함께 적용 기준을 정리한다.

LiteRT.js가 해결하려는 문제

현재 많은 웹 AI 기능은 서버 API 호출에 의존한다. 사용자가 이미지를 업로드하면 서버로 보내고, 서버가 모델을 호출하고, 결과를 다시 내려준다. 이 구조는 구현이 쉽지만 단점도 분명하다. 네트워크 지연이 생기고, 서버 비용이 늘고, 민감한 데이터가 외부로 이동하며, 오프라인 상태에서는 기능이 멈춘다.

LiteRT.js는 이 중 일부를 브라우저 내부 추론으로 해결하려 한다. 예를 들어 이미지 분류, 객체 감지, 간단한 텍스트 처리, 오디오 전처리, 개인화 추천처럼 모델 크기가 관리 가능한 기능은 서버에 보내지 않고 사용자 기기에서 처리할 수 있다. 특히 개인정보가 섞인 이미지나 음성 데이터는 로컬 처리만으로도 제품 신뢰도를 높일 수 있다.

물론 모든 AI 기능을 브라우저로 옮길 수는 없다. 대형 언어 모델 전체를 브라우저에서 안정적으로 돌리는 것은 여전히 기기 성능, 메모리, 다운로드 용량의 제약을 받는다. LiteRT.js의 현실적인 출발점은 “작고 빠른 모델을 웹 앱에 붙이는 것”이다.

기술적으로 달라진 지점: .tflite, WASM, 하드웨어 가속

Google 발표에 따르면 LiteRT.js는 기존 LiteRT 스택을 웹으로 가져온다. 개발자는 .tflite 모델을 JavaScript 또는 TypeScript 앱에서 실행할 수 있고, 실행 경로는 WebAssembly와 하드웨어 가속을 활용한다. CPU에는 XNNPACK, GPU에는 WebGPU 기반 가속, NPU에는 실험적인 WebNN 경로가 언급됐다.

이 구조가 중요한 이유는 브라우저 AI의 병목이 모델 자체보다 실행 런타임에 있는 경우가 많기 때문이다. 같은 모델이라도 JavaScript 커널 위에서 돌리는 것과 최적화된 네이티브 런타임을 WASM으로 가져오는 것은 성능 차이가 날 수 있다. 특히 실시간 카메라 처리나 오디오 처리처럼 프레임 단위 응답이 필요한 기능에서는 몇십 밀리초 차이가 UX를 바꾼다.

또 하나의 변화는 PyTorch 모델 변환과 양자화 흐름이다. LiteRT Torch를 통해 PyTorch 모델을 LiteRT로 변환하고, AI Edge Quantizer로 모델 크기와 성능을 조정할 수 있다. 실무에서는 모델 정확도만 보는 것이 아니라 번들 크기, 초기 로딩 시간, 추론 시간, 배터리 사용량을 함께 봐야 한다.

어떤 제품에 먼저 적용할 수 있나

LiteRT.js가 바로 효과를 낼 수 있는 제품은 서버 왕복이 UX를 망치는 기능을 가진 웹 앱이다. 예를 들어 브라우저 기반 이미지 편집기에서 배경 분리나 객체 감지를 로컬로 처리하면 사용자가 파일을 업로드하지 않아도 된다. 화상 회의 앱에서 소음 감지나 간단한 음성 이벤트 분류를 클라이언트에서 처리하면 지연 시간을 줄일 수 있다. 교육용 앱에서는 손글씨, 발음, 제스처 같은 입력을 실시간으로 분석할 수 있다.

반대로 적용을 미뤄야 하는 경우도 있다. 모델 파일이 너무 커서 첫 방문 로딩이 길어지는 서비스, 결과 품질이 사용자 기기별로 크게 달라지면 안 되는 서비스, 서버에서 중앙 통제가 필요한 규제 산업 기능은 신중해야 한다. 브라우저 추론은 배포 후에도 기기 스펙, 브라우저 버전, GPU 드라이버 차이를 계속 마주친다.

따라서 첫 적용 과제는 “핵심 결제 흐름”보다 “로컬에서 실패해도 대체 가능한 보조 기능”이 좋다. 예를 들어 서버 API를 기본 경로로 두고, 지원 기기에서는 LiteRT.js를 우선 사용하게 하는 점진적 도입이 안전하다.

성능 테스트는 서버 API와 다른 방식으로 해야 한다

브라우저 AI 성능 테스트는 서버 API 벤치마크와 다르다. 서버에서는 같은 인프라에서 평균 지연 시간과 처리량을 보면 된다. 클라이언트에서는 기기 편차가 핵심 변수다. 고성능 노트북, 보급형 안드로이드, 오래된 iPhone, 회사 지급 Windows 노트북에서 결과가 다를 수 있다.

테스트 항목은 최소 6개가 필요하다. 첫째, 모델 다운로드 크기와 캐시 전략. 둘째, 첫 실행까지 걸리는 시간. 셋째, 단일 추론 평균 시간과 p95 시간. 넷째, 연속 실행 시 발열과 배터리 영향. 다섯째, 브라우저별 지원 여부. 여섯째, 실패 시 서버 fallback 동작이다.

특히 WebNN은 아직 실험적인 환경이므로 “지원하면 빠르다”보다 “지원하지 않아도 제품이 망가지지 않는다”가 중요하다. 기능 탐지, 런타임 선택, 원격 설정을 준비해야 한다. 모델 파일도 CDN 캐싱, 버전 관리, 롤백 경로를 갖춰야 한다.

개발팀이 지금 준비할 것

지금 당장 할 일은 대형 모델을 브라우저에 억지로 넣는 것이 아니다. 제품 안에서 로컬 추론이 이득을 주는 작은 기능을 찾는 것이다. 예를 들어 “이미지 업로드 전 민감 정보 감지”, “문서 분류 미리보기”, “오디오 입력 품질 체크”, “오프라인 추천 후보 생성” 같은 기능이 후보가 된다.

그다음은 모델 파이프라인을 정리한다. 학습 프레임워크, LiteRT 변환, 양자화, 정확도 회귀 테스트, 브라우저 성능 테스트, 배포 버전 관리를 한 흐름으로 묶어야 한다. 프론트엔드 팀만의 일이 아니라 ML 엔지니어, 백엔드, 보안 담당자가 함께 봐야 한다.

LiteRT.js는 웹 앱을 “서버가 모든 지능을 처리하는 구조”에서 “클라이언트가 일부 판단을 맡는 구조”로 움직이게 만든다. 이 변화는 비용 절감보다 아키텍처 선택지 확대에 가깝다.

실행 체크리스트

• 서버 왕복 때문에 UX가 느린 AI 기능을 먼저 찾는다.
• 모델 파일 크기, 첫 실행 시간, p95 추론 시간을 측정한다.
• 고사양·저사양·모바일·데스크톱 기기에서 따로 테스트한다.
• LiteRT.js 실패 시 서버 API로 fallback하는 경로를 만든다.
• 모델 버전, CDN 캐시, 롤백 전략을 배포 전에 정한다.
• 개인정보가 포함된 입력은 로컬 처리 이점이 큰지 우선 검토한다.
• WebNN·WebGPU 지원 여부를 기능 탐지로 분기한다.

참고한 공개 자료

• Google Developers Blog, “LiteRT.js, Google’s high performance Web AI Inference” https://developers.googleblog.com/litertjs-googles-high-performance-web-ai-inference/