온디바이스 LLM 최적화와 폰 AI 에이전트: 속도, 배터리, 실행 흐름

폰 에이전트 품질은 벤치마크보다 체감 지연에서 갈린다

휴대폰에서 AI 에이전트를 쓸 때 사용자가 가장 먼저 느끼는 것은 모델 이름이 아니라 기다리는 시간이다. “엄마에게 10분 늦는다고 초안 보여줘”, “방금 온 알림 중 급한 것만 정리해줘”, “지도 앱 열고 다음 목적지 보여줘” 같은 요청은 생각보다 짧은 시간 안에 이해, 판단, 앱 이동, 확인이 이어져야 한다. 한두 초의 지연도 반복되면 사용자는 다시 손으로 앱을 연다.

온디바이스 LLM 최적화 폰 AI 에이전트가 중요한 이유는 여기에 있다. 좋은 폰 에이전트는 답을 길게 쓰는 모델이 아니라, 화면과 앱 상태 가까이에서 빠르게 반응하고 배터리를 과하게 쓰지 않으며, 사용자가 확인할 수 있는 결과를 남기는 시스템이다. 메모리 압박이 크면 앱이 다시 로드되고, 배터리 비용이 크면 상시적인 보조 경험이 부담스러워진다. 또 앱이 전면에 있을 때와 백그라운드에 있을 때 가능한 일이 다르기 때문에, 에이전트는 기술 성능과 Android 화면 흐름을 함께 다뤄야 한다.

Android Developers의 Gemini Nano 문서는 Gemini Nano가 Android AICore를 통해 온디바이스 생성형 AI를 제공하고, 지원되는 환경에서 낮은 추론 지연과 네트워크 없는 경험, 개인정보에 민감한 사용 사례를 목표로 한다고 설명한다. FoneClaw에서 우리는 이런 로컬 AI 추론의 장점을 사용자가 볼 수 있는 Android 동작으로 이어 보는 데 집중한다. 더 넓은 휴대폰 실행 흐름은 AI 에이전트의 휴대폰 제어에서 이어서 이해할 수 있다.

모델 크기, 양자화, 어댑터를 Android 작업 기준으로 보기

모바일 LLM 최적화는 논문 속 모델 압축 이야기가 아니라, 실제 휴대폰에서 어떤 일을 빠르게 처리할지 정하는 문제다. 모든 요청에 큰 모델을 쓰면 답은 풍부할 수 있지만, 메모리와 전력, 첫 응답 시간이 부담이 된다. 반대로 작은 모델만 쓰면 빠르지만 복잡한 맥락 판단이나 긴 문장 작성에서 부족할 수 있다. 폰 에이전트는 이 둘 사이에서 작업별로 맞는 길을 찾아야 한다.

양자화는 모델을 더 작고 가볍게 만들어 모바일 기기에서 실행하기 쉽게 하는 접근이다. 어댑터는 기본 모델 위에 특정 작업 성향을 얹는 방식으로 이해하면 된다. 작은 모델 분기는 “이 요청은 알림 분류처럼 짧은 판단인가, 고객 메시지처럼 문장 품질이 중요한가, 일정 변경처럼 확인이 필요한가”를 먼저 나누는 방식이다. Android에서는 이런 분기가 앱 열기, 초안 작성, 리마인더, 화면 확인 같은 실제 작업으로 드러난다.

Apple의 Foundation Models 2025 업데이트는 온디바이스 모델 효율을 위해 KV 캐시 공유, 양자화, 어댑터, 로컬과 서버 모델 분리를 설명한다. 플랫폼은 다르지만 사용자가 체감하는 질문은 비슷하다. 어떤 요청을 기기에서 빠르게 처리하고, 어떤 요청을 더 깊은 추론으로 보내며, 어느 순간에 사용자 확인을 남길 것인가다. FoneClaw에서 우리는 이 구분을 Android의 지원되는 동작과 확인 흐름으로 옮겨 본다.

AICore, Gemini Nano, ML Kit GenAI, LiteRT-LM이 만드는 실행 경로

온디바이스 AI가 제품에서 작동하려면 모델 파일만으로 충분하지 않다. 어떤 기기에서 쓸 수 있는지 확인하고, 모델을 내려받고, 첫 호출을 준비하고, 토큰 한도와 앱별 사용량을 다루고, CPU와 GPU 같은 실행 경로를 고르는 과정이 필요하다. 사용자는 이런 내부 절차를 보지 않지만, 결과는 “바로 반응하는가”, “오프라인에서도 되는가”, “배터리를 과하게 쓰는가”로 느낀다.

Google ML Kit GenAI Prompt API 문서는 지원되는 Android 기기 확인, 기능 사용 가능 여부 점검, Gemini Nano 다운로드, 첫 호출 지연을 줄이기 위한 준비 단계, 토큰 제한과 앱별 할당량을 다룬다. 이는 폰 에이전트가 “언제 로컬 기능을 쓸 수 있는지”를 사용자 경험 안에서 판단해야 한다는 뜻이다.

Google AI Edge는 MediaPipe 작업 API, LiteRT, LiteRT-LM 같은 온디바이스 ML과 AI 경로를 제시하고, LiteRT-LM 개요는 로컬 LLM 예시와 prefill, decode, 첫 토큰 시간, CPU/GPU 경로, 메모리, 오프라인 로컬 모델 실행 같은 성능 관점을 다룬다. FoneClaw 관점에서 이 실행 경로는 추상적인 개발자 옵션이 아니라, 지원되는 Android 동작을 얼마나 빠르게 열고 복구하고 확인할 수 있는지와 연결된다.

KV 캐시, 준비 단계, 첫 토큰, 반복 작업의 체감 속도

사용자는 “캐시가 잘 재사용됐는가”를 묻지 않는다. 대신 “왜 방금 전과 비슷한 요청인데 또 오래 걸리지?”라고 느낀다. 폰 에이전트에는 반복 작업이 많다. 같은 메시지 앱을 열고, 같은 가족에게 초안을 만들고, 같은 알림 묶음을 정리하고, 같은 지도 흐름으로 이동한다. 이런 반복에서 캐시와 준비 단계가 체감 속도를 크게 바꾼다.

KV 캐시는 모델이 이전 문맥을 처리하며 만든 일부 계산 결과를 재사용할 수 있게 하는 구조로 이해하면 된다. prefill은 입력 문맥을 먼저 처리하는 단계이고, decode는 실제 답을 한 토큰씩 만들어 내는 단계다. 첫 토큰 시간이 짧으면 사용자는 “반응이 시작됐다”고 느낀다. 준비 단계는 첫 요청에서 생기는 지연을 줄이기 위한 사전 준비다. 컨텍스트 길이가 길수록 더 많은 문맥을 볼 수 있지만 메모리와 시간 부담도 커진다.

이 기술들은 휴대폰에서 매우 실제적인 의미를 가진다. “오늘 알림 요약해줘”를 매번 새로 무겁게 처리하는 대신, 반복되는 앱과 연락처, 최근 작업을 효율적으로 활용하면 더 자연스러운 흐름이 된다. 물론 사용자가 확인해야 하는 메시지, 일정, 결제, 위치 공유는 빠른 처리 뒤에도 보이는 확인이 필요하다. FoneClaw에서 우리는 속도를 자동 전송의 이유로 쓰기보다, 사용자가 더 빨리 결과를 보고 판단하게 하는 장점으로 삼는다.

로컬 추론과 클라우드 추론을 언제 나눠 쓸까

모든 작업을 기기 안에서 처리하는 것이 항상 최선인 것도 아니고, 모든 작업을 클라우드로 보내는 것이 항상 편한 것도 아니다. 짧은 명령 분류, 간단한 요약, 앱 열기 준비, 알림 우선순위 판단처럼 빠른 반응이 중요한 일은 로컬 추론이 잘 맞는다. 긴 문서 이해, 복잡한 계획, 넓은 지식이 필요한 요청은 더 큰 모델의 도움을 받을 때 품질이 좋아질 수 있다.

사용자에게 중요한 것은 이 분기가 보이지 않는 기술 자랑으로 끝나지 않는 것이다. 예를 들어 FoneClaw가 “회의 10분 늦는다고 답장 초안 만들어줘”라는 요청을 받으면, 로컬에서 의도와 앱 흐름을 빠르게 잡고, 필요하면 더 깊은 문장 생성이나 맥락 판단을 다른 경로로 이어 갈 수 있다. 최종적으로는 메시지 앱, 수신자, 초안, 전송 확인이 화면에 보여야 한다. 이것이 폰 AI 에이전트에서 최적화가 제품 경험으로 바뀌는 지점이다.

로컬과 클라우드의 큰 선택 기준은 클라우드와 로컬 AI 에이전트에서 더 넓게 볼 수 있고, 운영체제와 앱, 모델이 만나는 구조는 OS 에이전트의 3계층 기반에서 이어서 다룬다. 이 글에서는 그 논의를 휴대폰 작업의 체감 속도와 회복 흐름으로 좁혀 본다. FoneClaw에서 우리는 사용자가 볼 수 있는 결과, 앱 권한 안의 지원 동작, 확인 가능한 다음 단계가 분기 설계의 중심이 되도록 한다.

온디바이스 LLM 기능을 평가할 때 확인할 체크리스트

새 Android 휴대폰이나 AI 기능을 볼 때 “온디바이스 LLM”이라는 문구만으로 경험을 판단하기는 어렵다. 실제 폰 에이전트 품질은 기기 지원, 오프라인 동작, 개인정보 처리, 지연 시간, 사용량 제한, 배터리, 화면 복구, 대체 흐름이 함께 맞을 때 좋아진다.

• 기기 지원: Gemini Nano, AICore, ML Kit GenAI, LiteRT-LM 같은 기능이 해당 기기와 Android 버전에서 제공되는지 확인한다.
• 오프라인 동작: 네트워크가 없을 때 어떤 기능이 유지되고 어떤 기능이 연결을 기다리는지 본다.
• 개인정보 흐름: 로컬에서 처리되는 정보와 외부 추론으로 넘어가는 정보를 사용자가 이해할 수 있어야 한다.
• 지연 시간: 첫 응답, 첫 토큰, 반복 요청, 앱 전환 후 복구 속도를 실제 작업으로 확인한다.
• 할당량과 한도: 토큰 제한, 앱별 사용량, 모델 다운로드 조건이 경험에 영향을 줄 수 있다.
• 배터리와 발열: 상시 보조 기능이 하루 사용을 방해하지 않는지 확인한다.
• 화면 회복: 앱이 닫혔거나 화면이 바뀌었을 때 사용자가 어디서 다시 시작할 수 있는지 본다.
• 확인 흐름: 메시지, 일정, 결제, 위치 공유 같은 중요한 행동은 사용자가 확인할 수 있는 단계로 남아야 한다.

Apple Foundation Models 프레임워크도 앱 안에서 온디바이스 언어 모델, 구조화된 출력, 도구 호출을 제공하는 방향을 보여 준다. Android와 Apple 모두에서 공통적으로 보이는 흐름은 기기 가까운 모델이 앱 경험과 직접 만나고 있다는 점이다. FoneClaw에서 우리는 이 흐름을 지원되는 Android 휴대폰 동작, 보이는 결과, 필요한 확인으로 연결해 사용자가 “빠른 AI”를 실제 작업 완료로 느낄 수 있게 만드는 데 집중한다.