Google Tensor ML SDK가 Beta로 올라오면서 Pixel 10 계열 기기에서 Tensor TPU를 활용한 온디바이스 AI 개발 흐름이 더 현실적인 선택지가 됐습니다. 함께 강조된 LiteRT는 PyTorch 또는 TFLite 모델을 변환, 컴파일, 배포, 실행하는 통합 워크플로우를 제공합니다. 개발자 입장에서는 “모델을 서버에 올릴까, 기기에서 돌릴까”를 기능 단위로 다시 나눠볼 타이밍입니다.
출처: Google Developers Blog, “Google Tensor SDK Beta with LiteRT”, 2026-05-19.
모든 AI 기능을 온디바이스로 돌릴 필요는 없습니다. 큰 모델 추론, 복잡한 reasoning, 최신 지식 검색, 고품질 생성은 여전히 서버가 유리합니다. 하지만 지연 시간, 개인정보, 오프라인 동작, 사용량 비용이 중요한 기능은 기기 실행이 더 낫습니다. 예를 들어 음성 명령의 첫 단계 인식, 카메라 프리뷰 기반 객체 감지, 간단한 텍스트 분류, 앱 내부 액션 라우팅, 접근성 보조 기능은 서버 왕복 없이 처리하는 편이 사용자 경험이 좋습니다.
Google 발표에서 Tensor SDK Beta의 장점은 두 가지입니다. 첫째, LiteRT와 통합된 개발 흐름입니다. 모델을 변환하고, Tensor TPU에 맞게 컴파일하고, 앱에서 실행하는 과정이 하나의 도구 체계로 묶입니다. 둘째, 100개 이상의 모델이 포함된 Model Garden입니다. 컴퓨터 비전, 음성 인식, Gemma 3 1B, Function Gemma, EmbeddingGemma 같은 모델을 직접 실험할 수 있습니다.
실무에서는 이걸 “멋진 데모”가 아니라 “기능 분해”로 봐야 합니다. 서버 LLM이 모든 것을 처리하는 구조는 구현이 단순하지만 비용과 지연 시간이 쌓입니다. 반대로 기기에서 가능한 전처리와 라우팅을 먼저 처리하면 서버 호출 수를 줄이고, 서버에는 더 어려운 요청만 보낼 수 있습니다.
LiteRT는 Google의 on-device ML deployment framework입니다. 발표에 따르면 Tensor ML SDK는 LiteRT와 통합되어 PyTorch 또는 TFLite 모델을 Tensor TPU용 최적화 바이너리로 변환하고 컴파일할 수 있습니다. 배포는 Play Feature Delivery와 AI Packs를 활용합니다. 실행 단계에서는 LiteRT Runtime을 통해 몇 줄의 코드로 TPU inference를 돌리고, TPU를 사용할 수 없을 때 CPU 또는 GPU fallback을 지정할 수 있습니다.
이 구조에서 중요한 운영 포인트는 fallback입니다. 온디바이스 AI는 기기별 성능 차이가 큽니다. Pixel 10 계열처럼 지원이 명확한 환경에서는 TPU를 쓰더라도, 다른 기기에서는 CPU/GPU 또는 서버 fallback이 필요합니다. 따라서 앱 코드는 “AI 기능이 항상 빠르게 동작한다”를 가정하면 안 됩니다. capability detection, model availability, runtime download 상태, battery 상태, thermal throttling 가능성을 함께 봐야 합니다.
또 하나는 모델 배포 크기입니다. AI Packs로 모델을 넣을 수 있다고 해도 앱 설치 용량과 업데이트 비용은 사용자 이탈로 이어질 수 있습니다. 모든 모델을 기본 설치에 넣기보다, 기능 진입 시 필요한 모델만 다운로드하는 구조가 낫습니다. 단, 첫 실행 시 다운로드 지연이 생기므로 skeleton UI, progress copy, Wi-Fi 권장 같은 UX도 같이 설계해야 합니다.
첫 번째 후보는 private classification입니다. 사용자의 메모, 사진 설명, 음성 전사 일부처럼 서버로 보내기 민감한 데이터를 기기에서 분류합니다. 예를 들어 생산성 앱이라면 메모를 업무, 개인, 할 일, 아이디어로 1차 분류하고, 서버에는 사용자가 명시적으로 요청한 경우에만 보낼 수 있습니다.
두 번째 후보는 local action routing입니다. Function Gemma 같은 작은 모델을 활용해 “내일 오전 9시에 회의 알림 만들어줘” 같은 문장을 앱 내부 action schema로 바꿉니다. 이때 중요한 것은 모델이 직접 외부 작업을 실행하지 않게 하는 것입니다. 모델은 intent와 slot을 추출하고, 앱의 deterministic layer가 검증 후 실행해야 합니다.
세 번째 후보는 camera/audio preprocessing입니다. 객체 감지, segmentation, 음성 인식의 1차 처리를 기기에서 하면 서버 비용과 latency가 줄어듭니다. 특히 카메라 프리뷰는 실시간성이 중요하기 때문에 서버 왕복이 UX를 망칩니다. Tensor TPU를 활용할 수 있다면 이 영역의 체감 효과가 큽니다.
가장 현실적인 구조는 하이브리드입니다. 온디바이스 모델은 빠르고 사적인 1차 판단을 담당하고, 서버 모델은 어려운 판단과 생성 품질이 필요한 작업을 맡습니다. 예를 들어 문서 스캔 앱을 생각해봅시다. 기기에서 OCR 품질 점수, 문서 영역 감지, 개인정보 포함 여부를 판단합니다. 서버에는 사용자가 명시적으로 요약을 요청한 문서만 올립니다. 서버는 고품질 요약과 검색 인덱싱을 수행합니다.
이 구조는 비용도 줄입니다. 모든 입력을 서버로 보내면 요청 수와 토큰 수가 계속 늘어납니다. 반면 기기에서 “처리할 가치가 있는 요청”만 걸러내면 서버 사용량을 제어할 수 있습니다. 또한 네트워크가 불안정한 환경에서도 최소 기능을 유지할 수 있습니다.
주의할 점은 두 모델의 결과가 충돌할 때입니다. 온디바이스 분류 결과와 서버 결과가 다르면 어떤 것을 우선할지 정해야 합니다. 개인정보, 안전, 권한 관련 판단은 보수적인 값을 우선해야 합니다. 예를 들어 기기 모델이 “민감하지 않다”고 했더라도 서버 업로드 전 deterministic rule이 주민번호, 전화번호, 카드번호 패턴을 다시 검사해야 합니다.
온디바이스 AI는 서버 로그만으로 디버깅할 수 없습니다. 앱 내부에서 latency, runtime 선택(TPU/GPU/CPU), 모델 버전, 실패 코드, fallback 발생 여부를 익명화해 수집해야 합니다. 단, 개인정보가 포함된 raw input은 수집하지 않는 편이 안전합니다. 대신 입력 길이, 파일 크기, 기기 모델, OS 버전, 배터리 상태 같은 메타데이터만으로도 많은 문제를 찾을 수 있습니다.
품질 평가는 offline test set으로 시작합니다. 각 기능별로 정상 케이스, 짧은 입력, 긴 입력, 노이즈 입력, 다국어 입력, 실패해야 하는 입력을 준비합니다. 모델이 action routing을 한다면 schema validation 통과율과 잘못된 action 실행 가능성을 봐야 합니다. speech나 vision 기능이라면 기기별 FPS, memory, thermal 변화를 같이 측정합니다.
배포는 feature flag로 쪼개야 합니다. 모든 사용자에게 한 번에 켜지 말고, 지원 기기와 앱 버전 조건을 걸어 단계적으로 늘립니다. 모델 파일도 rollback이 가능해야 합니다. 앱 코드 업데이트 없이 모델만 바꿀 수 있다면 빠르게 고칠 수 있지만, 반대로 잘못된 모델이 배포됐을 때 즉시 disable할 kill switch가 필요합니다.
LiteRT와 Tensor SDK의 포인트는 “모바일에서 큰 AI를 돌린다”가 아닙니다. 앱 기능을 서버와 기기 사이에 제대로 나누는 것입니다. 온디바이스 AI는 잘 쓰면 비용, 속도, 개인정보를 동시에 개선하지만, fallback과 배포 전략 없이 붙이면 디버깅하기 어려운 장애가 됩니다.
