LiteRT의 Play services 전환: 작은 앱과 안정적인 첫 실행을 함께 설계하기

설치 파일에서 빠지는 것과 앱에 남는 것

Google은 2026년 10월 28일, Google Play services의 LiteRT에 ML Drift 기반 GPU 가속과 CompiledModel API를 제공한다고 발표했다. 공급자 시험에서는 기존 GPU delegate 대비 약 1.4배의 추론 속도와 약 8MB의 앱 크기 감소를 제시했다. 이 수치는 개별 앱의 보장값이 아니다. 이 글에서는 직접 측정하지 않았으며, Play services가 없는 기기를 포함한 모든 Android 배포에 적용되는 변화로 해석하지 않는다. 공식 발표

변화의 중심은 런타임의 전달 방식이다. 독립형 LiteRT는 앱이 실행 엔진을 함께 배포하고, Play services 방식은 기기의 공유 런타임을 사용한다. 앱마다 엔진을 넣는 부담을 줄일 수 있지만, 앱이 쓸 .tflite 모델과 입력 처리까지 저절로 사라지는 것은 아니다. 사진 배경 제거라면 사진의 방향·크기·색상 처리, 모델 입력 만들기, 마스크를 원본 사진에 맞추는 코드는 여전히 앱의 역할이다. 모델을 앱에 담을지 별도로 내려받을지도 따로 결정한다. Play services 개요

따라서 용량 검증은 같은 모델과 같은 기능을 가진 두 앱 빌드를 비교해야 한다. 전환하면서 모델을 더 작게 바꾸거나 테스트 자산까지 지웠다면 감소분 전체를 공유 런타임의 효과라고 할 수 없다. 다운로드 크기와 설치 후 저장 공간도 같은 수치가 아니므로, 비교 도구와 대상 기기 조건을 함께 남기는 편이 좋다.

이 글의 기준은 10월 29일 확인한 play-services-litert:17.0.0과 Play services 런타임 2.3.2다. SDK는 앱을 빌드할 때 쓰는 인터페이스와 라이브러리이고, 런타임은 기기에서 모델을 실행하는 쪽이다. 버전 번호의 자릿수가 다른 것은 서로 다른 구성 요소를 가리키기 때문이다. 10월 28일 릴리스 노트

배포 방식과 실행 API를 두 축으로 고른다

CompiledModel은 Play services 전용 API가 아니다. 독립형 LiteRT에서도 사용할 수 있다. 독립형 Kotlin 안내는 litert:2.3.0과 선택적 litert-gpu:2.3.0 의존성을 제시하고, 모델·입출력 버퍼를 만든 뒤 실행하는 흐름을 설명한다. 같은 API 이름이 보인다고 설치할 패키지와 초기화 경로까지 같다고 보면 안 된다.

아래 표는 17.0.0 전환을 검토할 때 쓸 선택표다. 기능 전체의 호환성 보증이나 모든 LiteRT 버전의 지원표는 아니다.

현재 상황	먼저 정할 경로	남는 확인
독립형 CompiledModel로 CPU·GPU 추론 중	공유 런타임으로 옮길지 선택	Play services 환경 초기화와 기존 의존성 제거
Play services의 기존 Interpreter로 CPU 추론 중	의존성 교체와 API 이전을 단계적으로 진행	실제 사용 중인 지원 라이브러리의 호환성
기존 GPU delegate로 추론 중	CompiledModel GPU 경로로 이전	CPU 대체 실행과 출력 품질 대조
Play services 없는 기기·필수 custom op·당장 NPU 필요	독립형 LiteRT를 우선 검토	대상 기기·모델·가속기 조합의 별도 지원 조건

공식 개요는 Play services에서 NPU를 예정 기능으로 구분하고, custom op나 Play services 없는 기기가 필요하면 독립형을 안내한다. 독립형이라는 이유만으로 모든 NPU와 연산자가 동작한다는 뜻은 아니다. 현재 배포 경로의 조건

또 “기존 CPU 코드는 유지 가능”이라는 설명은 의존성 전체를 그대로 두라는 뜻이 아니다. 릴리스 노트는 새 SDK의 최소 Android API 수준을 24로 명시한다. 기존 play-services-tflite-gpu, play-services-tflite-acceleration-service, play-services-tflite-support와의 병용 제한도 있다. 특히 마지막 항목을 입력 처리에 쓰던 앱이라면 GPU 호출만 고쳐서는 이전이 끝나지 않는다. 17.0.0의 호환성 변경

사진 한 장을 처리하는 동안 무엇을 준비해 둘까

가상의 상품 등록 앱을 생각해 보자. 사용자는 사진을 골라 배경을 지운 뒤 가장자리를 확인하고 저장한다. 앱에는 검토한 분할 모델이 있고, 기존 CPU 경로로 얻은 출력도 비교 자료로 남아 있다고 가정한다. 다음은 직접 구현하거나 실행한 앱이 아닌 이전 설계 사례다.

공식 CompiledModel 가이드의 핵심은 환경 초기화를 기다린 다음 모델을 만들고, 환경·모델·버퍼를 반복 호출에 재사용하는 것이다. 메인 스레드를 막지 않아야 하며, 더 이상 필요 없을 때 자원을 닫는다. GPU를 쓰려면 환경 초기화에서 setEnableGpu(true)를 설정하고, 모델 생성 옵션에 Accelerator.GPU와 Accelerator.CPU를 함께 지정하는 경로를 안내한다. 초기화·재사용·GPU 설정

이 계약을 사진 편집 화면에 옮기면 다음과 같은 상태 구분이 필요하다.

사진 선택 버튼과 자동 배경 제거 버튼을 같은 준비 상태에 묶을 필요는 없다. 런타임을 준비하는 동안에도 원본 미리보기와 수동 편집은 허용하고, 자동 처리만 준비 중으로 보여 줄 수 있다. 초기화 실패 시에는 “처리 중” 표시를 계속 돌리는 대신 재시도와 원본 유지 중 무엇을 할지 고르게 한다. 이는 필자의 UI 설계 제안이다.

모델이 준비된 뒤 두 번째 사진을 받는다면 입력·출력을 갱신하며 같은 자원을 재사용한다. 사진마다 모델을 다시 생성하는 코드는 반복 작업에 준비 비용을 끼워 넣는다. 반대로 재사용한다고 여러 추론이 동시에 같은 버퍼를 덮어써도 되는 것은 아니다. 여기서는 한 번에 한 요청만 처리하는 직렬 구조를 가정한다. 새 사진을 고르면 이전 요청 ID의 결과를 버리거나, 이전 처리가 끝난 뒤 다음 요청을 시작하는 정책이 필요하다.

사용자가 화면을 떠났을 때도 실행 종료와 화면 표시 종료를 구분한다. 코루틴을 취소했다는 이유만으로 기저 추론까지 중단됐다고 단정하지 않는다. 작업 완료 전 사용 중인 버퍼를 닫지 않고, 늦게 도착한 결과가 재진입 후 선택한 다른 사진에 붙지 않도록 화면 세대 또는 요청 ID를 대조한다. 구체적인 중단·해제 방식은 실제 앱의 작업 소유자와 사용 API에 맞춰 검증해야 한다.

GPU 대체 실행이 해결하는 실패는 한정돼 있다

GPU 가속기는 지원 기기에서 필요에 따라 내려받는다. CPU 대체 옵션은 GPU를 사용할 수 없을 때 CPU로 실행할 수 있도록 하는 설정이다. Play services 환경 초기화 자체의 실패, 손상된 모델, 입력 형상 오류까지 성공으로 바꾸는 일반 복구 기능은 아니다. 릴리스 노트의 GPU 다운로드·대체 설명을 이런 범위로 읽어야 한다. 릴리스의 실행 조건

사진 앱에서 다음 시험을 분리하면 “내 기기에서는 잘 됐다”보다 유용한 이전 결과가 남는다. 표의 결과는 관측값이 아니라 앞으로 확인할 기준이다.

시험 조건	확인할 사용자 결과	판단에 남길 기록
새 설치 후 첫 자동 처리	준비가 끝나면 정확한 사진에 마스크가 표시됨	초기화·모델 준비·첫 추론·표시까지 각각의 시간
준비된 상태에서 다음 사진 처리	재초기화 없이 새 사진의 결과를 표시	반복 추론과 전후처리 시간
GPU 사용 불가 조건	CPU에서 정상 출력 또는 설명 가능한 실패	설정·기기·실행 결과, 가속기 경로 미확인 여부
준비 실패 또는 네트워크 제약	대기 표시가 끝나고 원본 유지·재시도 가능	실패 단계·오류 코드·자원 준비 상태
처리 중 이탈 후 다른 사진 선택	이전 결과가 새 사진을 덮지 않음	요청 식별·자원 소유·해제 시점

새 설치와 이미 준비된 기기의 오프라인 실행은 별도로 시험한다. 필요한 구성 요소가 남아 있는 기기에서 한 번 성공했다고 최초 준비까지 오프라인으로 가능하다고 결론 내리지 않는다. 초기화 대기를 포함한 첫 처리와 준비된 반복 추론도 섞어 평균 내지 않는다.

출력 비교는 속도와 별도다. 가령 가는 머리카락·상품 손잡이·반투명 포장 가장자리처럼 업무상 중요한 경계가 CPU와 GPU에서 얼마나 달라지는지 확인한다. 입력 크기·정규화·모델 해시를 같게 유지하고, 차이를 허용할 기준은 앱의 용도에 맞춰 정한다. 배경 제거 속도가 빨라도 판매할 상품 일부가 지워지면 이전 성공으로 볼 수 없다. 실제 품질과 성능은 이 글에서 측정하지 않았다.

가이드에 있는 메서드도 이번 런타임에서는 미지원일 수 있다

10월 29일 확인한 Kotlin·Java 가이드는 GPU 사용 가능 여부를 env.getAvailableAccelerators()로 확인하는 방법을 안내한다. 그러나 10월 28일 릴리스 노트는 같은 메서드와 일부 관련 API가 현재 kLiteRtStatusErrorUnsupported로 실패한다고 명시한다. SDK에 인터페이스가 포함됐다는 사실과 Play services 런타임의 구현 지원이 서로 다른 사례다. 가이드의 GPU 절 · 릴리스의 미지원 목록

이 글에서는 그 메서드를 전제로 “GPU면 이 모델, 아니면 저 모델”을 고르는 복사·실행 예제를 만들지 않았다. 실제 단말에서 어느 문서와 일치하는지는 아직 시험하지 않았다. 17.0.0 도입 설계는 릴리스의 제한을 기준으로 보수적으로 잡고, 후속 수정이나 대상 단말 시험으로 확인한 뒤 해당 조회 경로를 채택하는 편이 맞다.

그렇다고 앱이 성공 응답을 받으면 GPU였다고 기록해도 되는 것은 아니다. CPU 대체를 허용했다면 성공은 기능 완료의 근거일 뿐 실행 장치를 확정하지 않는다. 현재 지원되는 관측 수단으로 경로를 확인하지 못했다면 요청한 가속기: GPU+CPU, 실제 경로: 미확인으로 남긴다. 기능 성공과 GPU 성능 실험을 구분할 수 있다.

문서 충돌은 이전 전체를 포기할 이유도, 어느 쪽이든 편한 문구를 고를 이유도 아니다. 필수 기능인지 먼저 정한다. 단일 모델의 CPU·GPU 대체가 목적이라면 가속기 목록 조회를 앱의 필수 준비 조건에서 제외할 수 있다. 반대로 하드웨어별 모델 선택이 제품의 핵심이면 조회나 선택 API의 지원을 확인할 때까지 그 이전 범위를 보류한다. 이것은 제품 요구에 따라 다른 결정이다.

무엇을 확인하면 전환을 결정할 수 있나

Play services 방식은 지원 기기에서 CPU·GPU 모델을 실행하며 앱마다 런타임을 배포하는 부담을 줄이고 싶은 경우에 비교할 만하다. 반면 필수 custom op나 Play services 없는 배포 대상이 있다면 독립형 경로의 필요가 남는다. 런타임이 자동 갱신된다는 장점도 앱 팀의 출력 회귀 확인을 없애지는 않는다.

데이터 처리도 범위를 나눠 설명해야 한다. 공식 문서는 LiteRT API의 입력 처리는 기기 안에서 이뤄지며 입력을 Google 서버로 보내지 않는다고 설명한다. 동시에 업데이트·호환 정보 통신과 API 성능·이용 지표 전송도 명시한다. 따라서 이 선택만으로 앱 전체가 무통신이라고 안내하면 안 된다. 사진 업로드·분석 SDK 등 앱의 다른 경로는 따로 확인해야 한다. 공식 데이터 처리 설명

다음 기록은 팀이 이전 후보를 검토할 때 쓸 수 있다. 빈칸은 측정값을 채울 자리이며, 이 글의 실행 결과가 아니다.

앱 버전 / 모델 해시 / 입력 전처리 버전:
대상 Android·Play services / SDK·런타임 확인 범위:
필수 연산자 / 지원 라이브러리 / 독립형 유지 대상:
동일 조건의 전환 전후 다운로드 크기·설치 공간:
새 설치 첫 처리: 준비 __ / 추론 __ / 화면 표시까지 __
준비 후 반복 처리: 추론 __ / 전후처리 __
요청한 가속기 / 확인한 실제 경로 또는 미확인:
CPU·GPU 출력 차이 / 업무상 허용 기준:
준비 실패·재시도·화면 이탈·재진입 결과:
채택할 범위 / 남길 기존 경로 / 되돌릴 조건:

이전의 완료 조건은 의존성 이름이 바뀐 커밋보다 구체적이어야 한다. 같은 사진이 올바르게 처리되고, 준비되지 않은 상태도 사용자에게 설명되며, 불필요한 런타임을 제거한 크기 차이를 확인할 수 있어야 한다. 위 조건을 충족한 기기와 모델 범위부터 전환을 결정하면 된다.

실행 경로의 호환성을 더 넓게 보는 방법은 Windows Arm의 로컬 AI 도입 분석, 사용자가 기다리는 시간의 경계는 AI 지연 시간 측정 가이드에서 이어 읽을 수 있다. 이전 기록을 다시 사용할 때는 글 상단의 저장 기능을, 다른 플랫폼 분석은 소프트웨어 모음과 RSS를 이용할 수 있다.