폰 에이전트 모델 라우팅: Kimi, DeepSeek, GLM을 고르는 실제 기준

영구 우승 모델보다 작업 경로를 고르기

폰 에이전트 모델 라우팅은 “가장 좋은 모델 하나”를 찾는 일이 아니다. 사용자의 요청이 짧은 답장 초안인지, 긴 문서 요약인지, 현재 화면을 읽고 다음 작업을 준비하는 일인지, 메시지 전송처럼 결과가 남는 작업인지에 따라 적합한 모델 경로가 달라진다. 모델은 이해와 계획을 맡고, 실제 Android 실행은 별도의 권한, 도구, 화면 상태, 사용자 승인 흐름에서 처리된다.

정적 순위표가 폰 에이전트에 약한 이유는 모델 가용성, 가격, 지연 시간, API 동작, 도구 호출 습관이 계속 바뀌기 때문이다. 어떤 모델이 코딩이나 수학 평가에서 강하더라도 연락처 이름을 안전하게 해석하고, 정확한 도구 인자를 만들고, 권한이 없을 때 멈추고, 사용자가 볼 수 있는 결과를 남기는 일까지 보장하지는 않는다.

FoneClaw를 만들면서 우리는 모델 선택을 제품의 끝이 아니라 시작으로 본다. 사용자는 무료 기본 모델로 시작할 수 있고, 필요하면 호환 모델을 구성할 수 있다. 그러나 어떤 모델을 쓰든 중요한 경계는 같다. 모델은 요청을 이해하고 계획한다. FoneClaw는 지원되는 Android 작업을 화면에 보이는 결과, 권한 사용, 승인, 실패 복구로 이어간다. 실제 연결 설정을 다루는 단계는 AI 모델 API를 Android 폰 에이전트에 연결하는 법: FoneClaw 설정과 안전한 테스트에서 더 자세히 볼 수 있고, 이 글은 어떤 기준으로 라우팅할지를 다룬다.

신뢰성, 지연 시간, 비용, 문맥, 개인정보로 라우팅하기

좋은 폰 에이전트 모델 라우팅 정책은 다섯 가지 신호를 함께 본다. 첫째는 신뢰성이다. Android 작업에서는 자연스러운 문장보다 구조화된 계획과 도구 인자가 더 중요해질 때가 많다. 모델이 연락처, 시간, 앱 이름, 위치, 메시지 본문을 구분하고, 필요한 확인 단계를 빠뜨리지 않아야 한다. 스키마가 있는 도구 호출에서는 필드 이름과 인자 형식이 흔들리면 실제 작업이 멈춘다.

둘째는 지연 시간이다. 사용자가 음성으로 “이 화면 요약해서 메모해줘”라고 말했을 때 20초를 기다려야 한다면 좋은 계획도 체감 품질이 떨어진다. 반대로 긴 회의록을 요약하고 후속 일정까지 정리하는 작업은 몇 초 더 걸리더라도 문맥 이해와 정확성이 더 중요하다. 즉 빠른 모델과 깊은 모델을 같은 기준으로 비교하면 라우팅 판단이 흐려진다.

셋째는 비용이다. 자주 반복되는 알림 생성, 짧은 메시지 초안, 간단한 앱 열기 계획에는 비용 효율이 중요하다. 모든 요청을 가장 비싼 모델로 보내면 운영 비용이 빨리 커진다. 그렇다고 가장 저렴한 모델이 항상 좋은 것도 아니다. 사용자가 다시 확인하고 고쳐야 하는 시간이 늘어나면 낮은 토큰 비용이 실제 절감으로 이어지지 않는다. 비용 구조를 더 깊게 따져야 한다면 AI 에이전트 토큰 비용: 로컬 휴대폰 실행이 비용을 줄이는 방식이 비용 관점의 배경을 제공한다.

넷째는 문맥이다. 긴 파일, 여러 알림, 현재 화면, 이전 대화, 일정 정보가 함께 들어가면 문맥 처리 능력이 필요하다. 하지만 큰 문맥 창이 늘 정답은 아니다. 짧은 요청에 불필요한 자료를 많이 넣으면 비용과 지연 시간이 늘고, 모델이 핵심을 놓칠 수 있다. 다섯째는 개인정보와 배포 위치다. 연락처, 이메일, 위치, 파일처럼 민감한 정보가 들어가는 요청은 온라인 모델, 지원되는 온디바이스 모델, 최소 정보 전송, 사용자 확인의 경계를 함께 정해야 한다.

Kimi, DeepSeek, GLM을 현재 후보로 읽는 법

Kimi, DeepSeek, GLM은 폰 에이전트 모델 라우팅을 설명하기 좋은 현재 후보들이다. Kimi K3가 GitHub Copilot의 선택 가능한 모델로 제공된다는 신호는 모델 선택지가 빠르게 넓어지고 있음을 보여준다. DeepSeek과 GLM도 개발자와 기업 사용자가 성능, 비용, 공개성, 배포 경로를 함께 비교하는 이름이다. 다만 특정 제품의 모델 선택지로 등장했다는 사실이 곧 Android 작업 신뢰성을 증명하지는 않는다.

우리는 이런 모델을 “승자 후보”가 아니라 “라우팅 후보”로 읽는다. Kimi는 긴 문맥과 생성 품질을 기대하며 검증할 수 있고, DeepSeek은 비용과 추론 효율을 중점적으로 살필 수 있으며, GLM은 중국어와 다국어, 공개 평가 흐름을 함께 볼 수 있다. 그러나 이 모든 판단은 가설이다. 폰 에이전트에서는 실제 요청, 실제 기기, 실제 권한 상태로 다시 테스트해야 한다.

예를 들어 같은 모델이라도 “한국어로 가족에게 보낼 짧은 메시지 작성”과 “영어 회의록을 요약해 일정과 후속 작업을 만들기”에서 성능이 다르게 보일 수 있다. 더구나 Android 실행은 모델 바깥의 문제다. 모델이 훌륭한 초안을 만들었더라도 수신자가 두 명이면 선택이 필요하고, 캘린더 권한이 없으면 권한 복구가 필요하며, 사용자가 전송을 승인하지 않으면 작업은 멈춰야 한다.

이 때문에 모델 이름은 출발점일 뿐이다. 현재 후보를 검토할 때는 공식 가용성, API 안정성, 가격 변화 가능성, 응답 지연, 언어 적합성, 도구 호출 형식, 실패 시 복구 문장까지 함께 본다. 실행 평가를 더 엄격하게 하고 싶다면 안드로이드 폰 에이전트 벤치마크 가이드: 성공률보다 신뢰성을 평가하는 법에서 텍스트 점수가 아니라 작업 신뢰성을 보는 기준을 이어갈 수 있다.

가격과 가용성 변화에 흔들리지 않는 정책

모델 라우팅 정책은 가격과 가용성 변화에 견딜 수 있어야 한다. 통합 모델 라우팅 API와 멀티 provider 인프라가 늘어나는 흐름은 개발자가 하나의 모델에 고정되지 않으려는 수요를 보여준다. Google Developers의 AI model routing API 설명도 여러 모델 provider를 하나의 관리형 API 표면에서 다루려는 방향을 보여주는 인프라 신호로 읽을 수 있다.

하지만 provider를 바꾸는 일은 단순한 비용 절감 버튼이 아니다. 같은 프롬프트라도 모델마다 도구 인자 형식, 거절 방식, 긴 문맥 처리, 한국어 말투, 안전 응답, 지연 시간이 달라진다. 특히 전화, 메시지, 메일, 캘린더, 위치처럼 결과가 남는 Android 작업에서는 조용한 provider 전환을 피해야 한다. 민감한 작업은 사용자가 어떤 경로로 처리되는지 이해할 수 있어야 하고, 새 경로는 다시 검증해야 한다.

실무 정책은 가격 트리거와 품질 하한선을 함께 둔다. 예를 들어 짧은 저위험 작업은 비용 상한을 낮게 두고, 중요한 메일 초안이나 일정 변경은 더 높은 신뢰성 기준을 둔다. provider 장애나 지연이 생기면 대체 모델로 넘기되, 도구 호출 스키마와 승인 흐름을 다시 확인한다. 비용은 줄이되 작업의 의미가 바뀌면 안 된다.

또 하나의 원칙은 실패 기록이다. 라우팅 정책은 성공한 답변만 보지 말고 실패 이유를 기록해야 한다. 인자 누락, 시간대 오류, 연락처 혼동, 권한 부족, 앱 미설치, 사용자가 취소한 승인, 네트워크 오류를 따로 보면 어떤 모델을 언제 바꿔야 하는지 보인다. 저렴한 모델이 신뢰성을 낮추는지 여부도 이 실패 데이터로 판단해야 한다.

Android 실행 루프 안에서 모델 품질 측정하기

폰 에이전트의 모델 품질은 Android 실행 루프 안에서 측정해야 한다. 올바른 답변을 만들었지만 잘못된 도구를 고르면 작업은 실패한다. 적절한 도구를 골랐지만 인자가 틀리면 멈춘다. 인자가 맞아도 기기 권한이 닫혀 있으면 복구가 필요하다. 사용자가 승인해야 하는 작업을 승인 없이 진행하려 하면 신뢰를 잃는다.

따라서 테스트는 텍스트 품질, 계획 품질, 도구 인자, 기기 상태, 승인, 결과, 복구를 나눠 봐야 한다. “내일 오전 9시에 약 복용 알림을 만들어줘”라는 요청이라면 모델이 날짜와 시간을 정확히 해석하는지, 알림 또는 일정 중 어떤 경로를 선택하는지, 저장 전 내용을 보여주는지, 권한이 없을 때 설정 안내를 제공하는지, 완료 후 사용자가 확인할 수 있는 결과를 남기는지 평가한다.

기기와 계정도 고정해야 한다. 같은 모델이라도 Pixel, Samsung, 중급 Android 기기, 업무 프로필, 지역 설정, 언어 설정, 기본 앱 구성에 따라 결과가 달라질 수 있다. 그래서 모델 비교를 할 때는 같은 기기, 같은 앱, 같은 권한 상태, 같은 요청으로 두 경로를 비교해야 한다. 모델만 바꾸고 나머지 조건을 바꾸면 원인을 알 수 없다.

FoneClaw에서는 이 실행 루프를 제품의 핵심으로 본다. 모델은 사용자의 말에서 의도와 작업 계획을 만든다. Android 도구는 가능한 실행을 담당한다. 승인 UX는 결과가 남는 작업에서 사용자 결정을 받는다. 복구 흐름은 권한 부족이나 실패 상태를 다음 선택으로 바꾼다. 더 넓은 실행 구조가 필요하다면 AI 에이전트 폰 제어란 무엇인가: 안드로이드 폰 에이전트가 실제로 해야 할 일에서 Android 폰 에이전트의 역할을 함께 보면 좋다.

FoneClaw에서 모델 추론과 Android 실행을 나누기

FoneClaw에서 우리는 모델 선택과 Android 실행을 분리해 설계한다. 사용자는 무료 기본 모델로 시작할 수 있고, 필요하면 호환되는 온라인 모델 또는 지원되는 온디바이스 모델 경로를 구성할 수 있다. 모델은 요청을 이해하고 작업 순서를 제안한다. FoneClaw는 100+ built-in tools를 통해 지원되는 Android 작업을 수행하고, 결과를 화면에 보여주며, 필요한 권한과 승인을 다룬다.

이 구조에서 AI 모델 라우팅은 실용적인 선택 도구가 된다. 짧고 반복적인 요청은 빠르고 비용 효율적인 경로로 처리할 수 있다. 긴 문서나 복잡한 계획은 문맥 처리와 추론 안정성이 더 좋은 경로가 필요하다. 개인정보가 많이 포함된 요청은 처리 위치와 전송 범위를 더 엄격하게 본다. 중요한 점은 라우팅이 승인 우회를 뜻하지 않는다는 것이다. AutoAttach, Suggest, Fallback 같은 기능 매칭은 가능한 경로를 찾고 제안하는 역할을 하며, 외부 결과가 생기는 실행은 작업 성격에 맞는 확인을 거친다.

예를 들어 사용자가 “이 화면의 주문 정보를 메모하고, 내일 배송 확인 알림을 만들어줘”라고 요청한다고 하자. 모델은 화면 내용에서 주문 정보와 날짜 후보를 추출하고, FoneClaw는 메모와 알림 같은 지원 작업을 준비한다. 사용자는 저장될 내용과 알림 시간을 확인한다. 권한이 없거나 시간이 애매하면 FoneClaw는 멈추고 질문하거나 복구 경로를 제시한다. 이때 좋은 모델은 단순히 문장을 잘 쓰는 모델이 아니라, 모호함을 줄이고 필요한 확인을 빠뜨리지 않는 모델이다.

우리가 원하는 라우팅은 사용자가 모델 이름을 계속 의식하게 만드는 것이 아니다. 사용자는 “내 요청이 정확히 이해되었는가”, “결과가 보이는가”, “위험한 단계에서 내가 결정하는가”, “실패했을 때 다음 길이 있는가”를 본다. FoneClaw는 이 기준에 맞춰 모델 추론을 Android 실행으로 연결하고, 모델이 바뀌어도 작업의 신뢰 기준은 유지되도록 다듬고 있다.

실전 폰 에이전트 라우팅 정책 만들기

실전 정책은 다섯 단계면 충분하다. 먼저 작업을 분류한다. 정보 조회, 초안 작성, 현재 화면 요약, 앱 열기, 알림 생성, 메시지 전송, 캘린더 변경처럼 위험도와 결과가 다르다. 다음으로 품질 하한선을 정한다. 도구 인자 정확도, 모호성 질문, 한국어 품질, 지연 시간, 복구 문장을 최소 기준으로 둔다.

세 번째는 비용 상한선이다. 자주 반복되는 낮은 위험 작업은 비용 효율을 우선하고, 민감하거나 복잡한 작업은 신뢰성을 우선한다. 네 번째는 fallback이다. 주 모델이 느리거나 실패할 때 어떤 경로로 바꿀지 정하되, 민감한 작업에서는 사용자에게 보이는 확인을 유지한다. 다섯 번째는 되돌리기 쉬운 테스트다. 같은 기기에서 같은 요청을 두 모델로 실행하고, 답변 품질보다 실패 원인을 기록한다.

• 작업 분류: 조회, 초안, 요약, 기기 작업, 외부 결과가 남는 실행을 나눈다.
• 품질 기준: 스키마 안정성, 모호성 처리, 언어 품질, 복구 문장을 본다.
• 비용 기준: 반복 작업과 고위험 작업의 예산을 다르게 둔다.
• fallback: 장애, 지연, 품질 저하 시 대체 경로와 재검증 규칙을 정한다.
• 실행 검증: 같은 Android 기기, 같은 권한, 같은 앱 상태로 비교한다.

폰 에이전트 모델 라우팅의 결론은 고정된 순위가 아니라 운영 가능한 정책이다. Kimi, DeepSeek, GLM 같은 후보는 계속 바뀔 수 있다. FoneClaw가 유지해야 하는 기준은 더 안정적이다. 모델은 이해와 계획을 맡고, FoneClaw는 지원되는 Android 실행, 승인, 중지, 복구, 보이는 결과를 책임지는 구조다.