AICore Developer Preview 운영법: Gemini Nano 온디바이스 AI를 테스트할 때 볼 지표

AICore Developer Preview는 Android에서 Gemini Nano 같은 온디바이스 모델을 production release 전에 테스트할 수 있게 해주는 프로그램이다. 구글 문서에 따르면 개발자는 AICore app의 Developer Preview mode에 opt-in한 뒤 preview model을 다운로드하고 prompt를 시험할 수 있다. 추론은 기기 안에서 처리되고, 응답은 실시간 streaming으로 돌아온다.

온디바이스 AI는 서버 LLM과 운영 방식이 다르다. API latency, token cost, rate limit만 보면 되는 문제가 아니다. 기기 지원 여부, 모델 다운로드, 최초 로딩 시간, 메모리 경합, 배터리, 저장공간, 시스템 안정성, quota 우회 설정까지 고려해야 한다. preview model은 더 느리거나 부정확할 수 있다는 경고도 있다.

이 글은 AICore Developer Preview를 “새 모델 체험”이 아니라 Android 앱 개발자의 실험 환경으로 보고, 어떤 지표를 남겨야 production 판단을 할 수 있는지 정리한다.

AICore Developer Preview로 가능한 것

AICore Developer Preview에 들어가려면 Prompt API를 지원하는 기기가 필요하다. 개발자는 aicore-experimental Google group에 참여하고, Android AICore testing program의 tester가 된 뒤, 기기 설정에서 AICore system service를 업데이트한다. 베타 라벨이 보이기까지 시간이 걸릴 수 있고, 업데이트 후 AICore launcher icon이 나타난다.

그 다음 AICore app에서 preview version의 Gemini Nano를 선택해 다운로드한다. 기기에 stable Gemini Nano가 이미 있을 수 있으므로 preview 다운로드를 기다리는 동안 stable model로 prompt를 시험할 수 있다. preview model을 받은 뒤에는 text prompt를 넣고 온디바이스 추론 결과를 확인한다.

문서에서 특히 중요한 설명은 최초 inference가 약 1분 걸릴 수 있다는 점이다. 모델을 메모리에 올리는 초기화 시간이 있기 때문이다. 또 다른 큰 모델이 사용 중이면 BUSY 오류가 날 수 있다. 즉 온디바이스 AI의 성능은 단순 평균 latency가 아니라 cold start, warm inference, BUSY rate를 분리해서 봐야 한다.

서버 LLM 테스트와 다르게 봐야 할 지표

서버 API를 테스트할 때는 보통 p50, p95 latency, output quality, cost per request, error rate를 본다. AICore 같은 온디바이스 모델에서는 여기에 device-level 지표가 붙는다.

첫째, cold start time이다. 사용자가 기능을 처음 열 때 모델이 메모리에 올라가며 긴 대기가 발생할 수 있다. 구글 문서의 약 1분 초기 inference 언급은 앱 UX에 직접 영향을 준다. 채팅 화면이라면 skeleton과 안내 문구가 필요하고, 자동완성 기능이라면 첫 실행 전 pre-warm 전략을 검토해야 한다.

둘째, warm latency다. 모델이 이미 올라간 뒤 같은 prompt 길이에서 응답이 얼마나 빨리 streaming되는지 본다. AICore 응답에는 total inference time in milliseconds가 포함되므로 이를 로그로 남기면 기기별 성능을 비교할 수 있다.

셋째, BUSY rate다. 다른 큰 모델이 사용 중이거나 짧은 시간에 자주 테스트하면 BUSY 오류가 날 수 있다. production에서는 사용자가 이 오류를 이해하지 못한다. 앱은 “AI가 잠시 바쁩니다”가 아니라 재시도, 로컬 fallback, 서버 fallback, 기능 비활성화 중 하나를 선택해야 한다.

넷째, device health다. preview mode의 bypass quota limits는 개발에는 편하지만 모든 AICore 사용 앱에 영향을 줄 수 있고 system health implication이 있다고 문서에 적혀 있다. 개발기에서만 켜고, 성능 테스트 결과를 production 기준으로 착각하지 않아야 한다.

테스트 플랜을 어떻게 짜야 하나

AICore preview 테스트는 prompt playground처럼 하면 결과가 남지 않는다. 최소한 세 가지 축으로 테스트 세트를 구성해야 한다. 입력 유형, 기기 상태, 사용자 흐름이다.

입력 유형은 짧은 명령, 긴 문장, 다국어, 오타 포함, 개인정보 포함 가능성이 있는 텍스트로 나눌 수 있다. 온디바이스 모델은 서버 frontier model보다 작은 경우가 많으므로 애매한 입력에서 품질 차이가 커질 수 있다. 앱에서 실제로 들어올 prompt를 기준으로 sample set을 만들어야 한다.

기기 상태는 배터리 낮음, 발열 상태, 백그라운드 앱 많음, 네트워크 없음, 저장공간 부족, 모델 최초 다운로드 전후로 나눈다. 온디바이스라는 장점은 네트워크 의존도를 줄이는 것이지만, 모델 다운로드와 system service 업데이트는 여전히 환경 영향을 받는다.

사용자 흐름은 기능 진입, 첫 응답, 연속 요청, 앱 전환 후 복귀, 권한 거부, 오류 재시도까지 포함한다. 특히 streaming UX는 중간 token이 늦게 오거나 멈췄을 때 사용자가 취소할 수 있어야 한다.

앱 구조에서 분리해야 할 계층

온디바이스 AI를 붙일 때 가장 흔한 실수는 UI에서 바로 Prompt API를 호출하는 것이다. 빠른 demo는 가능하지만 운영에는 불리하다. 모델 선택, 오류 처리, fallback, telemetry를 바꾸려면 호출 계층을 분리해야 한다.

권장 구조는 AiInferenceClient 같은 interface를 두고, 내부 구현을 AICore, server LLM, mock으로 나누는 방식이다. UI는 “요약해줘”, “분류해줘”, “추천해줘” 같은 use case만 호출한다. 실제 inference provider는 feature flag나 device capability에 따라 결정한다.

이렇게 하면 지원 기기가 아닌 경우 서버 API로 fallback할 수 있다. preview model에서 품질이 낮은 task만 서버로 보내는 hybrid routing도 가능하다. 테스트에서는 mock provider로 deterministic output을 넣어 UI 회귀 테스트를 만들 수 있다.

또 모델 선택을 코드에 고정하지 않는 편이 좋다. 구글 문서는 AICore에서 다른 모델을 테스트한 뒤 Prompt API로 앱이 사용할 모델을 선택할 수 있다고 설명한다. 모델 버전이 바뀔 때마다 앱 전체를 수정하지 않으려면 provider 설정과 prompt template을 분리해야 한다.

개인정보와 로그 정책

온디바이스 AI의 가장 큰 장점은 민감한 입력을 서버로 보내지 않아도 된다는 점이다. 그러나 이것만으로 개인정보 문제가 끝나지는 않는다. 앱이 prompt와 output을 analytics에 그대로 남기면 온디바이스 처리의 장점이 사라진다.

로그에는 원문 입력 대신 task type, prompt length bucket, model version, inference time, error code, fallback 여부 정도만 남기는 것이 안전하다. 품질 개선을 위해 샘플이 필요하다면 사용자의 명시적 동의와 redaction 과정을 둬야 한다.

서버 fallback을 제공하는 경우에는 사용자에게 처리 위치가 바뀔 수 있다는 사실을 알려야 한다. 예를 들어 “기기에서 처리할 수 없을 때 서버에서 처리합니다” 같은 설정 설명이 필요하다. 민감한 메모, 의료, 금융, 업무 문서 기능이라면 fallback을 기본 off로 두는 선택도 가능하다.

preview model은 production 품질 보장이 아니다. 따라서 preview 테스트 중 나온 output을 사용자에게 노출하는 실험에서는 라벨링과 feedback 수집이 필요하다. 내부 dogfood와 외부 beta를 구분하는 것도 중요하다.

품질 평가 기준

Gemini Nano 같은 온디바이스 모델을 평가할 때 서버 모델과 같은 정답률만 보면 안 된다. 온디바이스 모델이 더 작은 대신 빠르고 private하며 offline에 강하다면, 적합한 task를 고르는 것이 핵심이다.

좋은 후보는 짧은 텍스트 분류, 로컬 요약, 입력 보정, 템플릿 추천, 간단한 의도 파악, 개인정보가 많은 문장의 로컬 전처리다. 반대로 최신 지식이 필요한 질문, 긴 문서 추론, 복잡한 코딩, 높은 정확도가 필요한 법률·의료 판단은 서버 모델이나 retrieval이 필요하다.

평가표에는 task별 acceptable quality threshold를 적어야 한다. 예를 들어 “일정 제목 자동 분류는 90% 이상 정확도”, “메모 요약은 핵심 누락률 5% 이하”, “오류 응답은 100% fallback 제공”처럼 기준을 수치화한다. 감으로 “괜찮아 보인다”는 preview에서 가장 위험한 판단이다.

실행 체크리스트

AICore Developer Preview는 Android 온디바이스 AI를 빨리 검증할 수 있는 좋은 통로다. 하지만 preview 모델의 속도와 안정성을 production 품질로 착각하면 안 된다. 개발 목표는 “모델을 써봤다”가 아니라 “우리 앱의 어떤 task가 온디바이스에 적합한지 증명했다”여야 한다.

테스트 전 아래를 확인하자.

• Prompt API 지원 기기 목록과 테스트 기기 모델을 기록한다.
• stable model과 preview model 결과를 분리해서 저장한다.
• cold start time, warm latency, BUSY rate, total inference time을 로그로 남긴다.
• bypass quota limits는 개발기에서만 켜고 production 판단 지표에서 제외한다.
• UI는 Prompt API 직접 호출 대신 inference client 계층을 통해 호출한다.
• 지원 기기 아님, BUSY, 모델 미다운로드, 네트워크 없음 상황의 fallback을 정한다.
• prompt 원문을 analytics에 남기지 않고 길이 bucket과 error code 중심으로 기록한다.
• task별 정확도와 허용 실패율을 수치로 정한다.

온디바이스 AI는 서버 AI를 대체하는 만능 카드가 아니다. 잘 맞는 task를 골라 privacy와 latency 이점을 얻는 설계 문제에 가깝다.