LiteRT.js 적용법: 브라우저에서 AI 추론을 돌릴 때 먼저 볼 성능 기준

요약: LiteRT.js는 .tflite 모델을 브라우저에서 실행하기 위한 Google의 JavaScript 바인딩입니다. 개인정보, 서버 비용, 지연 시간이 중요한 웹 앱이라면 “모델을 서버에 둘지, 브라우저에 둘지”를 다시 검토할 만합니다.

브라우저 AI 추론이 다시 중요해진 이유

AI 기능을 붙일 때 가장 쉬운 방식은 서버에서 모델 API를 호출하는 것입니다. 구현이 빠르고 모델 교체도 쉽습니다. 하지만 모든 기능에 서버 추론이 맞는 건 아닙니다. 카메라 프리뷰, 오디오 처리, 이미지 보정, 간단한 텍스트 분류처럼 사용자 입력이 빠르게 반복되는 기능은 네트워크 왕복만으로 UX가 나빠집니다.

LiteRT.js는 이 문제를 겨냥합니다. Google은 LiteRT의 JavaScript 바인딩을 공개했고, 웹 개발자가 .tflite 모델을 브라우저 안에서 실행할 수 있게 했습니다. CPU에서는 XNNPACK, GPU에서는 WebGPU 기반 ML Drift, 앞으로는 WebNN을 통한 NPU 활용까지 바라봅니다. 공식 벤치마크에서는 기존 웹 런타임 대비 최대 3배, GPU나 NPU 사용 시 CPU 대비 5~60배 속도 향상 사례를 제시했습니다. 단, 해당 수치는 2024년형 M4 MacBook Pro의 통제된 브라우저 환경 기준이라 실제 사용자 기기에서는 달라질 수 있습니다.

개발자가 봐야 할 핵심은 “서버 없이 AI 가능”이라는 문구가 아닙니다. 어떤 기능을 클라이언트 추론으로 빼야 총비용과 UX가 좋아지는지 판단하는 기준입니다.

서버 추론과 브라우저 추론을 나누는 기준

모든 모델을 브라우저로 옮기면 안 됩니다. 모델 크기, 초기 로딩, 기기 성능, 배터리, 브라우저 호환성 문제가 있습니다. 대신 다음 기준으로 나누는 게 현실적입니다.

브라우저 추론이 잘 맞는 경우:

• 입력 데이터가 민감해서 서버로 보내기 부담스러운 경우
• 카메라, 마이크, 캔버스처럼 실시간 반응이 중요한 경우
• 같은 모델을 짧은 간격으로 반복 호출하는 경우
• 결과가 개인화되어 서버 캐싱 효과가 낮은 경우
• 서버 API 비용이 기능 사용량에 비례해 크게 늘어나는 경우

서버 추론이 더 맞는 경우:

• 모델 크기가 커서 다운로드가 부담스러운 경우
• 고성능 GPU가 필요한 생성형 모델인 경우
• 결과 일관성과 중앙 통제가 중요한 경우
• 모델 업데이트를 즉시 강제해야 하는 경우
• 보안상 모델 파일 자체를 노출하면 안 되는 경우

예를 들어 쇼핑몰 이미지 검색에서 객체 감지는 브라우저에서 1차 처리하고, 최종 상품 매칭은 서버에서 할 수 있습니다. 화상회의 앱에서는 배경 분리나 노이즈 감지처럼 프레임 단위 처리는 브라우저가 유리하고, 회의 요약은 서버 모델이 유리합니다.

LiteRT.js 도입 전에 확인할 기술 요소

공식 설명 기준으로 LiteRT.js의 강점은 .tflite 모델과 LiteRT의 통합 런타임을 웹으로 가져온다는 점입니다. PyTorch 모델은 LiteRT Torch를 통해 변환할 수 있고, AI Edge Quantizer로 layer별 quantization을 적용할 수 있습니다. 브라우저에서는 @litertjs/core 패키지로 모델을 loadAndCompile한 뒤 Tensor를 넣어 실행합니다.

실무에서는 다음 항목을 먼저 검토해야 합니다.

첫째, 모델 파일 크기입니다. 사용자가 페이지에 들어올 때 50MB 모델을 받게 만들면 첫 사용 경험이 망가집니다. lazy loading, route 기반 로딩, service worker 캐싱이 필요합니다.

둘째, backend fallback입니다. WebGPU가 되는 기기와 안 되는 기기가 섞입니다. CPU fallback이 너무 느리면 기능을 비활성화하거나 품질을 낮춰야 합니다.

셋째, typed array와 메모리 이동 비용입니다. GPU에서 나온 결과를 CPU로 옮기는 과정도 비용입니다. 매 프레임마다 큰 tensor를 이동하면 추론이 빨라도 UI가 버벅일 수 있습니다.

넷째, 모델 업데이트 전략입니다. 모델 파일에 버전을 붙이고, 캐시 무효화 정책을 명확히 해야 합니다. 잘못된 모델이 브라우저 캐시에 오래 남으면 디버깅이 어려워집니다.

성능 측정은 어떻게 해야 하나

브라우저 AI 기능은 “내 노트북에서 빠름”으로 판단하면 안 됩니다. 실제 사용자의 기기 분포를 반영해야 합니다.

최소한 세 그룹으로 나눠 테스트하는 게 좋습니다.

• 고성능 데스크톱: 최신 MacBook, 외장 GPU PC
• 중간급 노트북: 사무용 Windows 노트북, 구형 MacBook
• 모바일/저전력 기기: Android 중급기, iPhone 구형 모델

측정 지표는 평균 latency만 보면 부족합니다. p95 latency, 첫 모델 로딩 시간, 메모리 사용량, 배터리 소모, thermal throttling 이후 성능 저하를 봐야 합니다. 특히 카메라 기반 기능은 1분 뒤와 10분 뒤 프레임 처리 시간이 다를 수 있습니다.

운영 로그도 필요합니다. 클라이언트에서 backend 종류(WebGPU, WASM, WebNN), 모델 버전, 추론 시간, 오류 유형을 익명·집계 형태로 수집해야 개선 방향을 알 수 있습니다. 개인정보 보호가 목적이라면 원본 입력은 보내지 말고 성능 메타데이터만 보내는 식으로 설계합니다.

제품 기능으로 풀 때의 예시

LiteRT.js는 단순 데모보다 UX 안에 잘 녹일 때 가치가 큽니다.

• 문서 스캔 웹앱: 브라우저에서 문서 경계 감지와 품질 점수를 계산하고, 서버에는 보정된 결과만 업로드합니다.
• 이커머스 관리자: 상품 사진의 객체 위치, 흐림 여부, 배경 품질을 클라이언트에서 즉시 표시합니다.
• 교육 앱: 웹캠 기반 자세 인식이나 발음 시각화를 서버 전송 없이 처리합니다.
• 크리에이터 도구: 이미지 업스케일 미리보기나 간단한 세그멘테이션을 로컬에서 제공합니다.

이런 기능은 “AI가 답변한다”보다 “사용자가 기다리지 않는다”가 더 중요합니다. 지연이 줄어들면 AI 기능이 별도 버튼이 아니라 인터랙션의 일부가 됩니다.

바로 실행할 체크리스트

• 기능이 서버 추론보다 클라이언트 추론에 맞는 이유를 적었는가?
• 모델 크기, 첫 로딩 시간, 캐시 전략을 측정했는가?
• WebGPU 실패 시 WASM fallback UX를 정했는가?
• p50뿐 아니라 p95 latency와 10분 사용 후 성능을 봤는가?
• 모델 버전과 backend 정보를 익명 성능 로그로 수집하는가?
• 원본 이미지·오디오를 서버로 보내지 않는다는 개인정보 약속을 지키는가?
• 모델 파일 노출이 비즈니스 리스크가 아닌지 확인했는가?

LiteRT.js는 모든 AI 웹앱의 답이 아닙니다. 하지만 실시간성, 개인정보, 서버 비용이 동시에 걸린 기능이라면 브라우저 추론은 이제 실험이 아니라 제품 설계 옵션입니다.