LiteRT.js 브라우저 AI 추론: 서버 비용 없이 WebGPU로 모델 돌리는 방법

요약: Google이 LiteRT.js를 공개하면서 브라우저 AI 추론의 선택지가 하나 더 생겼습니다. TensorFlow.js처럼 JavaScript 커널 중심으로 처리하는 방식이 아니라, LiteRT 런타임을 WebAssembly와 WebGPU, WebNN 방향으로 가져오는 접근입니다. 핵심 키워드는 LiteRT.js, 브라우저 AI 추론, WebGPU, on-device AI입니다.

개발자가 봐야 할 변화

브라우저에서 AI를 돌리는 요구는 오래전부터 있었습니다. 개인정보를 서버로 보내지 않고, 네트워크 지연 없이, 사용자의 기기에서 바로 처리하고 싶기 때문입니다. 하지만 실제 서비스에서는 성능이 자주 발목을 잡았습니다. 간단한 분류 모델은 가능해도 실시간 object detection, 음성 처리, 이미지 업스케일링처럼 latency에 민감한 작업은 서버 추론으로 돌아가는 경우가 많았습니다.

LiteRT.js는 이 지점에 들어옵니다. Google은 기존 LiteRT의 cross-platform runtime을 웹으로 가져오고, .tflite 모델을 브라우저에서 직접 실행할 수 있게 했습니다. 초기 릴리스에는 @litertjs/core npm 패키지와 데모가 포함되어 있고, CPU는 XNNPACK, GPU는 WebGPU 기반 가속, 향후 NPU는 WebNN을 바라봅니다.

뉴스로서 중요한 부분은 “브라우저에서도 모델을 돌릴 수 있다”가 아닙니다. 이미 가능했습니다. 중요한 부분은 모바일·데스크톱·웹에서 같은 LiteRT 계열 최적화를 공유하는 방향이 더 명확해졌다는 것입니다.

서버 추론과 브라우저 추론의 역할이 달라진다

서버 추론은 여전히 필요합니다. 대형 언어 모델, 민감한 API 키, 중앙 통제된 모델 업데이트, 대량 batch 처리에는 서버가 맞습니다. 반대로 브라우저 추론이 이기는 영역도 분명합니다.

• 카메라 프레임을 실시간으로 분석하는 UI
• 음성·이미지 전처리처럼 개인정보가 강한 작업
• 사용량이 많아질수록 서버 비용이 선형으로 증가하는 기능
• 네트워크가 불안정해도 동작해야 하는 기능
• 짧은 latency가 제품 경험을 좌우하는 기능

예를 들어 이력서 사진 자동 보정, 문서 스캔 품질 체크, 웹캠 기반 posture detection, 이미지 업스케일 preview는 서버 왕복 없이 처리할 때 UX가 좋아집니다. 반대로 최종 고해상도 생성이나 복잡한 reasoning은 서버에 맡기면 됩니다. LiteRT.js는 이 경계선을 다시 그리게 만듭니다.

성능 수치는 기대치를 정하는 데만 써야 한다

Google은 LiteRT.js가 기존 웹 런타임 대비 CPU·GPU 추론에서 최대 3배, CPU 대비 GPU 또는 NPU 경로에서 5~60배 속도 향상을 보였다고 설명합니다. 단, 벤치마크는 2024년 Apple M4 MacBook Pro의 통제된 브라우저 환경 기준입니다. 실제 사용자 기기에서는 GPU 성능, 브라우저 드라이버, thermal throttling, 메모리 압박에 따라 차이가 큽니다.

실무적으로는 이 숫자를 “우리 서비스도 60배 빨라진다”로 읽으면 안 됩니다. 대신 다음 질문에 답하는 근거로 써야 합니다.

• 브라우저 추론을 PoC 해볼 만큼 runtime maturity가 생겼는가?
• WebGPU 경로를 기본값으로 두고 CPU fallback을 둘 수 있는가?
• 모델 크기와 초기 로딩 시간을 UX 안에 숨길 수 있는가?
• 사용자의 기기 분포가 on-device inference에 맞는가?

특히 한국 서비스라면 모바일 웹 비중과 저가형 Android 기기 비중을 따로 봐야 합니다. 고성능 노트북에서 잘 도는 데모가 전체 사용자 경험을 대표하지 않습니다.

도입 구조는 feature flag부터 시작한다

LiteRT.js를 바로 핵심 기능에 넣는 것은 위험합니다. 브라우저 추론은 기기 편차가 크고, 디버깅도 서버보다 어렵습니다. 첫 적용은 feature flag와 fallback 구조로 시작하는 편이 안전합니다.

권장 구조는 이렇습니다. 먼저 서버 추론 API를 기존대로 유지합니다. 그 위에 클라이언트에서 LiteRT.js를 사용할 수 있는 환경인지 감지합니다. WebGPU 또는 WebNN 사용 가능 여부, 메모리 예산, 모델 파일 로딩 성공 여부를 체크합니다. 조건을 만족하면 클라이언트 추론을 사용하고, 실패하면 서버 API로 전환합니다.

이때 중요한 것은 실패를 “조용히” 처리하는 것입니다. 사용자가 브라우저 모델 로딩 실패 메시지를 볼 필요는 없습니다. 제품에서는 그냥 약간 느린 서버 경로로 돌아가면 됩니다. 개발팀은 내부 telemetry로 어떤 기기와 브라우저에서 fallback이 많이 나는지 보면 됩니다.

TensorFlow.js 사용 팀의 migration 관점

TensorFlow.js를 이미 쓰는 팀은 LiteRT.js를 완전 대체제로 보기보다 .tflite 중심 모델 배포 옵션으로 보는 게 현실적입니다. LiteRT Torch를 통해 PyTorch 모델을 변환할 수 있고, AI Edge Quantizer로 모델 크기와 성능을 조정할 수 있습니다. 하지만 모델 변환, quantization, 정확도 회귀 테스트가 필요합니다.

따라서 migration은 모델 단위로 해야 합니다. 가장 latency 민감하고 정확도 허용 범위가 넓은 기능부터 옮깁니다. 예를 들어 preview, 추천 후보 생성, local ranking, 입력 품질 검사는 적합합니다. 결제, 의료, 법률처럼 오류 비용이 큰 판단은 client-only로 두면 안 됩니다.

실행 체크리스트

• 브라우저 추론 후보 기능을 “개인정보”, “latency”, “서버 비용” 기준으로 점수화합니다.
• .tflite 모델 준비 가능 여부와 변환 난이도를 먼저 확인합니다.
• WebGPU 가능 브라우저, CPU fallback, 서버 fallback을 모두 설계합니다.
• 모델 파일 크기와 첫 로딩 시간을 측정하고 skeleton UI 또는 lazy loading을 붙입니다.
• 정확도 회귀 테스트를 모델 변환 전후로 실행합니다.
• 저사양 Android, Safari, 회사 보안 브라우저 환경을 별도로 테스트합니다.
• 기능 출시 후 fallback 비율, 평균 추론 시간, crash log를 대시보드로 봅니다.

출처: Google Developers Blog, “LiteRT.js, Google’s high performance Web AI Inference”, 2026-07-09.