LiteRT.js 브라우저 AI 추론 가이드: WebGPU로 클라이언트에서 모델을 돌리는 기준

Google이 2026년 7월 9일 공개한 LiteRT.js는 웹 개발자에게 중요한 선택지를 하나 더 추가했습니다. 서버 API로 모든 AI 기능을 처리하는 대신, 일부 모델 추론을 브라우저 안에서 실행할 수 있게 해주는 런타임입니다. WebGPU와 WebNN을 활용하고, 필요하면 WebAssembly로 fallback하는 구조입니다. 검색 키워드로는 LiteRT.js, 브라우저 AI 추론, WebGPU AI, 클라이언트 사이드 AI가 핵심입니다.

중요한 점은 “이제 모든 AI를 브라우저에서 돌리자”가 아닙니다. 어떤 기능은 서버가 낫고, 어떤 기능은 클라이언트가 낫습니다. LiteRT.js의 의미는 웹 제품에서 AI 기능의 배치 위치를 더 세밀하게 나눌 수 있다는 데 있습니다.

브라우저 추론이 필요한 이유

서버 기반 AI API는 구현이 쉽습니다. 사용자의 입력을 서버로 보내고, 서버에서 모델 API를 호출하고, 결과를 돌려주면 됩니다. 하지만 비용, 지연 시간, 개인정보 문제가 따라옵니다.

브라우저 추론은 이 문제 중 일부를 줄입니다.

• 사용자의 원본 데이터가 서버로 가지 않는다.
• 짧은 반복 추론에서 네트워크 지연이 줄어든다.
• 서버 API 비용을 줄일 수 있다.
• 오프라인 또는 불안정한 네트워크에서도 일부 기능이 작동한다.
• 인터랙션이 많은 UI에서 즉각적인 피드백을 줄 수 있다.

예를 들어 이미지 미리보기 품질 검사, 텍스트 분류, 로컬 추천, 간단한 음성 이벤트 감지 같은 작업은 서버 왕복 없이 처리하는 편이 사용자 경험에 유리할 수 있습니다.

서버 AI와 클라이언트 AI를 나누는 기준

기준 없이 클라이언트 추론을 붙이면 오히려 제품이 무거워집니다. 모델 파일 다운로드, 디바이스 성능 차이, 배터리 사용량, 브라우저 호환성까지 고려해야 합니다.

실무에서는 하이브리드가 가장 현실적입니다. 브라우저에서 1차 필터링을 하고, 서버에서 고품질 추론을 수행하는 방식입니다. 예를 들어 문서 업로드 서비스라면 클라이언트에서 파일 유형과 민감정보 패턴을 먼저 감지하고, 서버에는 필요한 텍스트만 보낼 수 있습니다.

WebGPU를 쓰기 전에 확인할 것

WebGPU는 브라우저에서 GPU 가속을 사용할 수 있게 해줍니다. 하지만 모든 사용자가 같은 환경을 갖고 있지 않습니다. 운영 제품에서는 feature detection과 fallback이 필수입니다.

확인해야 할 항목은 다음과 같습니다.

• 사용자의 브라우저가 WebGPU를 지원하는가.
• 모바일 환경에서 성능과 발열이 허용 가능한가.
• 모델 로딩 시간이 UX를 해치지 않는가.
• 첫 방문에서 모델 파일 크기가 과하지 않은가.
• WebAssembly fallback으로도 최소 기능이 가능한가.

가장 흔한 실패는 데스크톱 개발 환경에서만 테스트하고 모바일 사용자를 잊는 것입니다. 브라우저 AI는 사용자의 하드웨어 위에서 실행됩니다. 서버처럼 같은 성능을 기대하면 안 됩니다.

모델 파일 배포 전략

클라이언트 추론은 모델 파일을 배포해야 합니다. 이때 모델 파일은 사실상 프론트엔드 자산입니다. 캐시, 버전, 롤백을 설계해야 합니다.

추천 전략은 아래와 같습니다.

1. 모델 파일에 명시적 버전을 붙인다. 예: classifier-v1.3.0.task.
2. CDN 캐시 정책을 길게 잡되, 파일명 변경으로 업데이트한다.
3. 앱 코드와 모델 버전 호환성을 검사한다.
4. 모델 다운로드 실패 시 서버 추론 또는 기능 비활성화로 fallback한다.
5. 모델 성능 지표를 버전별로 수집한다.

특히 모델과 앱 코드의 호환성이 중요합니다. 전처리 방식이 바뀌었는데 이전 모델이 캐시되어 있으면 결과가 이상해질 수 있습니다. 모델도 코드와 같이 배포 단위로 봐야 합니다.

개인정보 보호 UX를 명확히 보여줘야 한다

클라이언트 AI의 강점 중 하나는 개인정보 보호입니다. 하지만 사용자가 모르면 가치가 전달되지 않습니다. “이 분석은 브라우저 안에서만 실행되며 원본 파일은 서버로 전송되지 않습니다” 같은 문구는 제품 신뢰에 직접 영향을 줍니다.

단, 과장하면 안 됩니다. 실제로 서버에 일부 데이터가 간다면 정확히 구분해야 합니다.

좋은 안내 예시는 이렇습니다.

• “이미지 품질 검사는 브라우저에서 실행됩니다.”
• “최종 요약을 생성할 때만 선택한 텍스트가 서버로 전송됩니다.”
• “원본 파일은 업로드하지 않습니다.”

AI 기능이 많아질수록 사용자는 어떤 데이터가 어디서 처리되는지 궁금해합니다. 브라우저 추론은 기술 선택이면서 신뢰 설계입니다.

성능 측정은 평균값만 보면 안 된다

클라이언트 추론은 사용자 환경 편차가 큽니다. 평균 추론 시간이 120ms라도 하위 10% 기기에서는 2초가 걸릴 수 있습니다. 따라서 지표를 percentile로 봐야 합니다.

권장 지표는 다음과 같습니다.

• 모델 다운로드 시간 p50/p90/p99
• 모델 초기화 시간 p50/p90/p99
• 단일 추론 시간 p50/p90/p99
• fallback 발생률
• 모바일 배터리 이슈 신고율
• 기능 사용 후 이탈률

특히 p90과 fallback 발생률이 중요합니다. 브라우저 AI는 “되는 사람에게는 빠르고, 안 되는 사람에게는 아예 안 됨” 패턴이 나오기 쉽습니다. 이 경우 서버 fallback이 제품 품질을 지킵니다.

적용하기 좋은 기능 예시

LiteRT.js 같은 브라우저 런타임은 아래 기능부터 적용하기 좋습니다.

• 이미지 업로드 전 품질 검사
• 문서 내 민감정보 패턴 감지
• 짧은 텍스트 카테고리 분류
• 입력값 자동 태깅
• 카메라 프레임 기반 단순 감지
• 로컬 검색 결과 재랭킹
• 오프라인 초안 추천

반대로 긴 문서 요약, 복잡한 reasoning, 고품질 코드 생성, 대형 멀티모달 추론은 서버 모델이 아직 더 적합한 경우가 많습니다.

실행 체크리스트

브라우저 AI 추론을 도입하기 전 아래를 확인하세요.

• 기능을 서버, 클라이언트, 하이브리드 중 어디에 둘지 표로 비교한다.
• WebGPU 지원 여부를 감지하고 fallback 경로를 만든다.
• 모델 파일 크기와 첫 로딩 UX를 측정한다.
• 모델 버전, CDN 캐시, 롤백 전략을 정한다.
• 개인정보 처리 위치를 사용자에게 명확히 안내한다.
• p90 기준 성능과 fallback 비율을 운영 지표로 본다.
• 모바일 저사양 기기에서 반드시 테스트한다.

LiteRT.js의 가치는 “브라우저에서 AI도 된다”가 아닙니다. AI 기능을 무조건 서버로 보내던 기본값을 깨는 데 있습니다. 작고 반복적이고 민감한 추론은 클라이언트로 내리고, 복잡하고 품질이 중요한 추론은 서버에 남기는 식으로 제품 구조를 다시 설계할 수 있습니다.