LiteRT.js 공개: 브라우저 온디바이스 AI를 검토할 때 볼 성능·보안 기준

LiteRT.js 공개는 웹 개발자에게 중요한 선택지를 하나 더 추가했다. 이제 일부 AI 추론을 서버 API로 보내지 않고 브라우저 안에서 직접 실행하는 방식이 현실적인 옵션이 됐다. Google은 2026년 7월 LiteRT.js를 발표하며 .tflite 모델을 JavaScript와 TypeScript 앱에서 실행할 수 있고, WebAssembly, WebGPU, 향후 WebNN을 통해 CPU·GPU·NPU 가속을 활용한다고 설명했다.

왜 브라우저 온디바이스 AI가 다시 중요해졌나

웹에서 AI를 쓰는 일반적인 방식은 서버 호출이다. 사용자가 이미지를 올리거나 텍스트를 입력하면 백엔드가 OpenAI, Gemini, Claude 같은 모델 API를 호출하고 결과를 돌려준다. 이 구조는 강력하지만 비용, 지연 시간, 개인정보, 오프라인 사용성에서 한계가 있다.

브라우저 온디바이스 AI는 이 문제를 다른 방향에서 푼다. 작은 모델이나 특정 목적 모델을 사용자의 기기에서 직접 실행한다. 예를 들어 객체 탐지, 배경 분리, 간단한 음성 처리, 이미지 업스케일링, 로컬 분류 같은 작업은 굳이 서버로 보내지 않아도 된다. 사용자의 카메라 프레임이나 로컬 파일을 외부 서버에 올리지 않아도 되므로 개인정보 부담도 줄어든다.

LiteRT.js가 의미 있는 이유는 기존 TensorFlow.js식 JavaScript 커널 중심 접근보다 네이티브에 가까운 런타임을 웹으로 가져오려는 시도이기 때문이다. Google은 LiteRT.js가 WebAssembly 기반으로 동작하고, CPU에서는 XNNPACK, GPU에서는 WebGPU 기반 ML Drift, 실험 단계의 WebNN에서는 NPU를 목표로 한다고 밝혔다. 발표 자료에는 일부 컴퓨터 비전·오디오 모델에서 다른 웹 런타임 대비 최대 3배, CPU 대비 GPU·NPU 경로에서 5~60배 속도 개선 사례도 제시되어 있다. 단, 이 수치는 2024년형 M4 MacBook Pro의 통제된 브라우저 환경에서 측정됐으므로 그대로 모든 사용자 환경에 적용하면 안 된다.

서버 AI와 브라우저 AI의 역할을 나눠야 한다

LiteRT.js를 보고 모든 AI 기능을 클라이언트로 옮기면 안 된다. 브라우저 AI와 서버 AI는 역할이 다르다. 서버 AI는 대형 언어 모델, 복잡한 reasoning, 기업 데이터 접근, 감사 로그가 필요한 작업에 강하다. 브라우저 AI는 짧은 지연 시간, 개인 데이터 보호, 반복 호출 비용 절감, 네트워크 불안정 환경에서 유리하다.

실무에서는 다음처럼 나누는 게 좋다.

핵심은 ‘AI를 어디서 돌릴 수 있나’가 아니라 ‘어디서 돌리는 것이 제품 요구에 맞나’다. 같은 기능이라도 개인정보가 핵심인 의료·교육·업무 문서 앱은 브라우저 추론의 가치가 크고, 최신 지식 기반 답변이 중요한 SaaS 고객지원은 서버 모델이 더 적합하다.

LiteRT.js 적용 전 확인해야 할 기술 조건

LiteRT.js는 .tflite 모델 실행이 중심이다. 이미 TensorFlow Lite나 LiteRT 기반 모델을 보유한 팀에는 진입 장벽이 낮다. PyTorch 모델은 LiteRT Torch로 변환할 수 있고, AI Edge Quantizer를 통해 계층별 양자화를 적용할 수 있다고 Google은 설명한다. 그러나 모델 변환이 된다고 곧바로 제품 적용이 끝나는 것은 아니다.

첫 번째 조건은 모델 크기다. 브라우저 앱에서 모델을 내려받아야 하므로 초기 로딩 시간이 UX에 직접 영향을 준다. 5MB 모델과 200MB 모델은 완전히 다른 제품 경험을 만든다. 모델 파일은 캐시 정책, CDN, 버전 관리와 함께 설계해야 한다.

두 번째 조건은 백엔드 호환성이다. WebGPU 지원 브라우저와 그렇지 않은 브라우저의 성능 차이가 클 수 있다. WebNN은 아직 실험적 영역이므로 production 의존도를 높게 잡기 어렵다. 따라서 기본 경로는 CPU/WASM, 가속 경로는 WebGPU, 향후 최적화 경로는 WebNN으로 나누고 fallback 전략을 둬야 한다.

세 번째 조건은 메모리다. 모바일 브라우저에서는 탭 메모리 제한, 발열, 배터리 문제가 생긴다. 데스크톱 벤치마크에서 빠른 모델도 저가 Android 기기에서는 버벅일 수 있다. 제품 지표는 평균 FPS가 아니라 p95 지연 시간, 메모리 피크, 작업 실패율로 봐야 한다.

보안과 개인정보 기준

온디바이스 AI는 개인정보 측면에서 유리하지만 자동으로 안전해지는 것은 아니다. 모델 파일이 클라이언트에 배포되므로 누구나 내려받아 분석할 수 있다. 모델 자체가 비즈니스 핵심 자산이라면 브라우저 배포가 맞지 않을 수 있다. 또한 로컬 추론 결과가 곧바로 신뢰 가능한 것도 아니다. 사용자는 브라우저 환경을 조작할 수 있고, 입력도 변조할 수 있다.

따라서 보안 기준은 다음처럼 잡는 것이 현실적이다.

• 민감 원본 데이터는 서버로 보내지 않는 방향으로 설계한다.
• 모델 결과를 결제, 권한, 심사 같은 최종 판단에 단독 사용하지 않는다.
• 서버 검증이 필요한 의사결정은 브라우저 결과를 힌트로만 쓴다.
• 모델 파일 버전과 해시를 관리해 잘못된 버전이 캐시되지 않게 한다.
• 입력 데이터와 추론 결과를 analytics로 수집할 때 명시적 동의를 받는다.

특히 브라우저 AI를 ‘개인정보 보호’ 메시지로 마케팅하려면 실제 네트워크 전송을 확인해야 한다. 파일은 로컬에서 처리한다고 말하면서 썸네일, 로그, 오류 리포트에 원본 일부를 실어 보내면 신뢰를 잃는다.

프론트엔드 아키텍처 예시

LiteRT.js 기반 기능은 메인 UI 스레드에 직접 얹지 않는 편이 좋다. 추론이 짧아도 모델 로딩과 텐서 변환은 UI 버벅임을 만들 수 있다. 권장 구조는 Web Worker를 분리하고, 모델 로딩 상태를 명확히 관리하는 방식이다.

UI Thread
  - 파일 선택, 카메라 프리뷰, 결과 표시
  - 모델 준비 상태 표시
  - 추론 요청 enqueue

Worker
  - LiteRT.js 초기화
  - 모델 다운로드와 컴파일
  - 입력 텐서 변환
  - 추론 실행
  - 결과 후처리

Server
  - 모델 manifest 제공
  - 버전·해시·AB 테스트 정책 관리
  - 필요한 경우 최종 검증

이 구조의 장점은 실패 처리가 쉽다는 점이다. WebGPU 초기화 실패, 모델 다운로드 실패, 메모리 부족, 지원하지 않는 브라우저를 각각 다른 fallback으로 처리할 수 있다. 예를 들어 실시간 효과는 비활성화하되 서버 처리 버튼을 제공하거나, 저사양 기기에서는 낮은 해상도 모델을 내려받게 할 수 있다.

성능 측정은 이렇게 시작한다

벤치마크를 볼 때 평균값만 보면 실패한다. 브라우저 온디바이스 AI는 사용자 기기 차이가 크기 때문이다. 최소한 다음 지표를 나눠 기록해야 한다.

• 모델 다운로드 시간: 최초 방문과 재방문을 분리
• 모델 컴파일 시간: WASM, WebGPU, WebNN 경로별 측정
• 첫 추론까지 걸린 시간: 사용자가 체감하는 실제 대기 시간
• p50/p95 추론 시간: 평균보다 p95가 중요
• 메모리 피크: 모바일 브라우저에서 크래시 여부 확인
• 배터리·발열: 장시간 카메라/오디오 처리 기능이면 필수
• fallback 비율: WebGPU 실패 후 CPU로 내려간 비율

이 데이터를 쌓으면 기능을 켤 대상 기기를 정할 수 있다. 모든 사용자에게 같은 모델을 제공하는 것보다, 기기 성능에 따라 모델 크기와 실행 경로를 다르게 주는 편이 낫다.

도입 체크리스트

LiteRT.js를 검토한다면 PoC 전에 아래 기준부터 정하자.

• 서버 호출을 줄여야 하는 명확한 이유가 있는가
• .tflite 모델 또는 변환 가능한 모델이 있는가
• 모델 크기가 초기 로딩 UX를 망치지 않는가
• WebGPU 미지원 환경에서 fallback이 있는가
• 모바일 저사양 기기에서 p95 지연 시간과 메모리를 측정했는가
• 모델 파일 버전·해시·캐시 정책을 관리하는가
• 브라우저 결과를 최종 권한·결제·심사 판단에 단독 사용하지 않는가
• 개인정보 보호 메시지와 실제 네트워크 전송이 일치하는가

LiteRT.js의 가치는 ‘웹에서도 AI를 돌릴 수 있다’가 아니다. 실시간성, 비용, 개인정보 때문에 서버 호출이 제품 경험을 망치는 구간을 브라우저로 옮길 수 있다는 점이다. 먼저 작은 기능 하나를 골라 모델 크기, p95 지연 시간, fallback 비율을 측정해 보자. 그 숫자가 맞으면 그때 제품 기능으로 키우는 편이 안전하다.