APK 용량 8MB를 아끼면서 커스텀 모델을 1.4배 빠르게 돌리는 법: Google Play 서비스의 LiteRT 2.x와 ML Drift GPU 가속 해부

Google Play 서비스의 단일 LiteRT 2.x 런타임 위에서 턴키 ML Kit API와 커스텀 모델이 ML Drift GPU 가속기로 동작하며 스마트폰·스마트워치·차량 디스플레이로 확장되는 구조를 형상화한 3D 아이소메트릭 개념 일러스트다. 실제 프로파일러나 콘솔 화면이 아니다.

Google이 공개한 Android Dev Summit 2026 온디바이스 ML 세션 영상(Mastering on-device intelligence with ML Kit and LiteRT in Google Play services)과 Google Play 서비스 기반 LiteRT 공식 문서는 LLM 외에 앱 현장에서 가장 많이 쓰이는 비전·오디오·전통적 머신러닝(Classical ML) 모델을 APK 용량 증가 없이 어떻게 빠르게 구동할 것인가를 다룬다. LiteRT 프로덕트 매니저 Chintan Parikh와 Android ML Services 엔지니어링 리드 Fergus Henderson은 차세대 LiteRT CompiledModel API의 Google Play 서비스 정식 탑재, 오픈소스 GPU 가속기 ML Drift 통합, 그리고 Wear OS 4+ 및 Android Automotive OS 확장 소식을 발표했다.

결론부터 말하면, 기존 TensorFlow Lite(LiteRT 1.x)의 Interpreter API를 쓰거나 런타임을 APK에 직접 번들링하던 앱은 com.google.android.gms:play-services-litert:17.0.0 기반의 CompiledModel API로 전환함으로써 앱 용량을 약 8MB 줄이고, 오픈소스 ML Drift 엔진을 통해 기존 GPU 델리게이트 대비 1.4배(CPU 대비 최대 10배) 빠른 추론과 하드웨어 버퍼 제로카피(Zero-copy) 파이프라인을 별도 네이티브 바이너리 배포 없이 그대로 얻을 수 있다. 다만 이 글은 Google의 공식 발표 영상과 개발자 문서를 교차 검증해 정리한 것이며, 개별 단말기 SoC 환경에서 프레임 레이트나 메모리 점유율을 직접 실측한 벤치마크는 아니다.

왜 턴키(ML Kit)와 커스텀 모델(LiteRT)을 하나의 Play 서비스 런타임에서 돌리는가

Android Dev Summit 2026 — Mastering on-device intelligence with ML Kit and LiteRT in Google Play services 공식 세션 썸네일 (원본 JPEG)

온디바이스 ML 기능을 앱에 넣을 때 개발팀은 흔히 ‘검증된 턴키 API(ML Kit)를 쓸 것인가, 자체 학습한 커스텀 모델을 직접 번들링할 것인가’의 양자택일 문제로 접근한다. 하지만 발표(00:57~09:25)에서 강조하듯 두 방식은 별개의 런타임이 아니라 **Google Play 서비스 내부의 동일한 LiteRT 런타임으로 들어가는 두 개의 정문(front door)**이다.

APK당 약 8MB 용량 절감과 런타임 공유: 런타임과 GPU 가속 바이너리를 앱마다 중복해서 묶지 않고 OS의 Google Play 서비스가 제공하는 공유 런타임을 얇은 클라이언트(play-services-litert)로 호출하므로 APK 크기가 약 8MB 줄어든다(LiteRT in Google Play services 문서).

38억 대 기기에서 검증된 드라이버 호환성과 자동 패치: 하루 1조 건 이상의 추론을 처리하는 Google Play 서비스가 수백 종의 모바일 SoC·ROM·GPU 드라이버 파편화 우회 패치와 보안 업데이트를 앱 재배포 없이 백그라운드에서 자동 반영한다.

스마트폰을 넘어 워치와 차량까지 단일 .tflite 실행: 기존 Android 7(2016년) 이상 스마트폰·태블릿뿐 아니라, 이제 Wear OS 4 이상 스마트워치와 Android Automotive OS(Android 11 이상) 차량 인포테인먼트 시스템에서도 폰 컴패니언 앱 없이 동일한 API와 .tflite 모델을 기기 자체에서 바로 실행할 수 있다.

발표 데모에서는 실시간 카메라 피드에서 턴키 API인 ML Kit Selfie Segmentation으로 인물 전경 마스크를 추출하고, 동시에 Hugging Face·Kaggle에서 가져와 litert-torch(구 ai-edge-torch)로 변환·양자화한 커스텀 스타일 트랜스퍼 모델을 LiteRT GPU에서 돌려 **단일 APK에서 두 개의 모델을 초당 30프레임(30 FPS)**으로 합성하는 파이프라인을 시연했다.

기존 TFLite Interpreter(1.x)와 차세대 LiteRT CompiledModel(2.x)의 아키텍처 비교

Google은 이번 업데이트를 통해 Google Play 서비스의 런타임을 LiteRT 2.x 기반 CompiledModel API로 업그레이드했다. 기존 Interpreter 방식과 비교하면 하드웨어 가속기 설정과 버퍼 처리 구조가 근본적으로 단순해졌다(LiteRT 마이그레이션 가이드).

비교 항목	기존 `TFLite / LiteRT 1.x` (`Interpreter` API)	차세대 `LiteRT 2.x` (`CompiledModel` API in Play services)
Maven 의존성 패키지	`play-services-tflite-java` (현재 보안 패치만 제공되는 유지보수 모드 전환)	`com.google.android.gms:play-services-litert:17.0.0` (`Interpreter`와 `CompiledModel` 모두 포함하여 점진적 전환 지원)
GPU 가속 엔진 및 성능	레거시 TFLite GPU Delegate (가속기별 수동 Delegate 설정 필요)	Apache 2.0으로 오픈소스화된 ML Drift 엔진 내장 — 기존 GPU 대비 1.4배, CPU 대비 최대 10배 빠른 추론 (OpenCL·OpenGL·Metal 크로스플랫폼 지원)
하드웨어 가속기 폴백(Fallback)	GPU 실패 시 개발자가 별도 예외 처리 및 CPU 인터프리터 재생성 코드 작성	`CompiledModel.Options(Accelerator.GPU, Accelerator.CPU)` 한 줄로 GPU 미지원 기기에서 자동 CPU 폴백 처리
메모리 복사 및 실시간 파이프라인	카메라 프레임을 CPU 배열로 복사한 뒤 텐서로 전달하는 오버헤드 발생	비동기 실행 및 `AHardwareBuffer`·OpenGL 버퍼 직결 제로카피(Zero-copy) 지원으로 수 밀리초 단위 실시간 렌더링 병목 제거
NPU 및 레거시 API 지원	2024년 지원 중단(deprecated)된 `NNAPI` 의존	`NNAPI`는 2027년부터 완전 제거 예정. CPU·GPU는 Play 서비스로 즉시 지원하며 NPU 가속은 현재 스탠드얼론 번들 지원(Play 서비스 지원 예정)

PyTorch 모델 변환·양자화부터 Play 서비스 GPU 실행까지의 코드 흐름

커스텀 PyTorch 모델을 Play 서비스의 LiteRT GPU에서 실행하는 과정은 크게 파이썬에서의 .tflite 변환·양자화 단계와 Android 앱에서의 비동기 환경 초기화 단계로 나뉜다.

먼저 파이썬 환경에서는 ai-edge-torch의 새로운 이름인 litert-torch를 사용해 모델을 플랫버퍼(.tflite)로 내보내고, GPU에 권장되는 8비트 정수 가중치 + 32비트 부동소수점 활성화(int8 weight / fp32 activation) 레시피로 양자화한다.

이후 Android 프로젝트의 build.gradle에서 기존 번들 런타임 의존성을 제거하고 Google Play 서비스 LiteRT 패키지만 추가한 뒤, LiteRt.initialize() API로 런타임 환경(Environment)을 주입받아 모델을 실행한다.

C++ 네이티브 코드(JNI)에서 실행해야 하는 경우에도 LiteRt.initializeNative(context, initOptions)로 핸들을 받아 C++ 측 GmsLiteRtInitializeEnvironment()에 넘기면 동일한 litert::CompiledModel::Create() API를 그대로 쓸 수 있다(CompiledModel C++ API 문서). 또한 직접 마이그레이션 코드를 작성하는 대신 코딩 에이전트에 새로 공개된 공식 Android LiteRT Skill을 연결하면 기존 TFLite 앱의 의존성 교체와 CompiledModel 전환을 수 분 내에 자동화할 수 있다.

기존 앱을 Play 서비스 기반 LiteRT 2.x로 전환할 때 확인할 점

실무 프로젝트에서 온디바이스 ML 파이프라인을 업그레이드하거나 신규 설계할 때는 발표와 공식 문서에서 명시된 다음 네 가지 주의사항을 먼저 점검해야 한다.

번들 런타임 의존성 완전 제거 전까지는 8MB 용량 절감 효과가 나타나지 않음: 대규모 앱에서는 컴포넌트별로 하나씩 play-services-litert로 점진적 마이그레이션을 진행할 수 있다. 다만 앱 내부의 서드파티 라이브러리나 레거시 모듈 중 하나라도 스탠드얼론 com.google.ai.edge.litert:litert를 물고 있으면 네이티브 바이너리가 APK에 그대로 남으므로, 최종 용량 절감을 위해서는 의존성 트리를 끝까지 정리해야 한다.

Play 서비스 런타임 객체와 번들 런타임 객체 간의 혼용 금지: 점진적 전환 기간에 한 앱 안에서 두 런타임을 함께 띄우는 것 자체는 가능하지만, Play 서비스 LiteRT에서 생성한 Environment·CompiledModel·TensorBuffer 객체를 스탠드얼론 번들 LiteRT 측으로 넘기거나 반대로 섞어 쓰면 충돌이 발생하므로 경계를 명확히 분리해야 한다.

UI 메인 스레드에서의 동기 대기(Tasks.await()) 절대 금지: LiteRt.initialize()는 Google Play 서비스의 동적 모듈(특히 enableGpu 설정 시 별도로 로드되는 GPU 가속기 모듈)을 비동기로 불러오므로, 메인 스레드에서 Tasks.await()를 호출하면 화면 프리징이나 ANR이 발생할 수 있다. 반드시 Kotlin 코루틴의 .await()를 백그라운드 디스패처에서 호출하거나 addOnSuccessListener 콜백 패턴을 사용해야 한다(CompiledModel Java/Kotlin 가이드).

2027년 NNAPI 완전 제거 일정에 맞춘 가속기 전환 및 개인정보 처리방침 고지 확인: 2024년에 지원 중단된 NNAPI는 2027년부터 런타임에서 완전히 삭제될 예정이므로 기존 NNAPI 의존 코드는 CompiledModel의 GPU 가속 또는 번들 NPU 가속으로 미리 옮겨야 한다. 아울러 Play 서비스 기반 LiteRT는 기기 모델·OS 버전·사용된 가속기 종류·추론 성능 지표 및 에러 코드를 진단 목적으로 Google에 전송하므로 앱의 개인정보 처리방침에 관련 고지가 반영되어 있는지 확인하는 편이 안전하다(Play services 데이터 수집 정책).

결국 모바일 온디바이스 AI의 실전 경쟁력은 거대 모델 하나를 억지로 우겨넣는 데 있는 것이 아니라, 검증된 턴키 비전·언어 API(ML Kit)와 차별화된 커스텀 모델(LiteRT CompiledModel)을 OS 공유 런타임 위에서 가볍고 빠르게 조합하는 데서 나온다.