앱이 MCP 서버가 된다, 안드로이드 에이전트의 새 입구

AI 요약

• 무슨 일: Google이 I/O 2026의 Android AI 업데이트를 정리하며 AppFunctions, Gemini Nano 4, Hybrid Inference, ADK for Android를 한 개발 표면으로 묶었습니다.
  • AppFunctions는 앱이 온디바이스 MCP 서버처럼 tools, services, data를 시스템과 에이전트에 제공하게 하는 experimental preview입니다.
• 의미: 모바일 앱 개발의 중심이 화면 자동화 대응에서 에이전트가 호출할 함수 계약 설계로 이동하기 시작했습니다.
• 실무 영향: Android 16 이상, private preview, 호출 권한, 온디바이스 모델 지원 범위가 초기 병목입니다.
  • ML Kit Prompt API, prefix caching, Firebase AI Logic routing은 로컬 추론과 클라우드 추론을 제품 정책으로 나누는 레버가 됩니다.

Google이 2026년 5월 26일 Android Developers Blog에 올린 글은 겉으로는 Google I/O 2026 Android AI 발표의 빠른 복습입니다. 하지만 개발자 관점에서 더 중요한 변화는 별도의 새 모델 하나가 아닙니다. Android 앱이 이제 에이전트가 "볼 수 있는 화면"을 넘어, 에이전트가 "호출할 수 있는 함수"를 제공하는 방향으로 이동하고 있다는 점입니다.

공식 글은 Android의 방향을 운영체제에서 지능 시스템으로 바꾸는 흐름이라고 설명합니다. 이 문장만 떼어 놓으면 제품 슬로건처럼 들릴 수 있습니다. 그러나 이어지는 세부 항목은 꽤 구체적입니다. Android Developers Blog는 AppFunctions를 "Android MCP"라고 부르며, 앱이 도구와 서비스와 데이터를 시스템 및 에이전트에 공유할 수 있다고 설명합니다. 여기에 AppFunctions 생성을 돕는 Android skill, 시뮬레이션 환경에서 디버깅할 수 있는 test agent, Gemini Nano 4 Preview, ML Kit GenAI Prompt API, Firebase AI Logic Hybrid Inference, A2UI Jetpack Compose Renderer, ADK for Android가 함께 붙었습니다.

이 조합이 흥미로운 이유는 Android가 에이전트 시대의 앱 통합 문제를 단순히 접근성 자동화나 화면 인식 문제로만 풀지 않으려 하기 때문입니다. 지금까지 모바일 에이전트의 흔한 상상은 "AI가 사용자의 휴대폰 화면을 보고 버튼을 누른다"에 가까웠습니다. 실제로 그런 방식은 빠르게 데모를 만들 수 있습니다. 하지만 UI는 사람에게 보이기 위해 설계된 층입니다. 버튼의 위치, 텍스트, 화면 상태, 로그인 흐름, 다국어 UI, 접근성 라벨, 광고와 팝업이 섞이면 에이전트에게는 불안정한 실행 환경이 됩니다.

AppFunctions는 다른 방향입니다. 앱이 자신이 제공할 수 있는 작업 단위를 함수로 정의하고, Android OS 안의 registry를 통해 authorized caller가 발견하고 실행할 수 있게 합니다. Android AppFunctions 문서는 이를 Android platform API와 Jetpack library의 조합으로 설명합니다. 앱은 on-device MCP server처럼 동작하고, callers는 Gemini 같은 assistant나 agent, 혹은 다른 앱이 될 수 있습니다. 서버 쪽 MCP가 API, 데이터베이스, 파일 시스템, SaaS 도구를 에이전트에 연결했다면, AppFunctions는 그 패턴을 휴대폰 안의 앱 생태계로 가져옵니다.

모바일 앱의 새 표면은 화면이 아니라 함수입니다

MCP가 서버와 데스크톱 개발 환경에서 빠르게 퍼진 이유는 단순합니다. LLM이 텍스트를 생성하는 것만으로는 일을 끝낼 수 없기 때문입니다. 일을 끝내려면 calendar event를 만들고, issue를 열고, 파일을 고치고, 결제를 준비하고, 검색 결과를 가져오고, 권한이 있는 데이터에 접근해야 합니다. 그래서 에이전트가 사용할 수 있는 tool schema와 실행 경계가 중요해졌습니다.

Android의 AppFunctions는 이 문제를 모바일 앱 단위로 재정의합니다. 예를 들어 사용자가 "오늘 오후 5시에 회사에서 택배를 챙기라고 알려줘"라고 말했을 때, 에이전트가 할 수 있는 일은 두 가지입니다. 하나는 일정 앱이나 할 일 앱 화면을 열고, 텍스트 필드를 찾고, 시간을 입력하고, 저장 버튼을 누르는 방식입니다. 다른 하나는 task app이 제공한 createReminder 같은 함수를 호출해 제목, 시간, 장소를 structured parameter로 넘기는 방식입니다. 전자는 사람이 보는 앱을 흉내 내는 방식이고, 후자는 앱이 에이전트에게 공식 실행 계약을 제공하는 방식입니다.

Google 문서는 AppFunctions가 Android 16 이상에서 제공되며, 2026년 5월 기준 Gemini 통합은 trusted testers 대상 private preview라고 적습니다. 호출자는 EXECUTE_APP_FUNCTIONS 권한이 있어야 합니다. 이 제한은 중요합니다. "모든 앱이 곧 Gemini에게 열립니다"라는 이야기가 아닙니다. 오히려 Google은 초기부터 호출자 권한, 앱이 노출하는 함수 범위, OS registry를 통한 발견과 실행을 강조하고 있습니다. 에이전트가 무엇을 할 수 있는지의 경계를 앱 UI의 우연한 상태에 맡기지 않겠다는 신호입니다.

Google이 같이 꺼낸 도구들이 말하는 것

이번 발표가 단순한 API 소개가 아닌 이유는 주변 도구가 함께 나왔기 때문입니다. 공식 글은 AppFunctions를 생성하기 위한 새 Android skill과 test agent를 언급합니다. skill은 코드베이스의 주요 workflow를 분석해 AppFunctions에 필요한 Kotlin 코드를 만들고, AI agent가 이해하기 좋은 KDoc을 정리하며, 테스트와 디버깅을 위한 ADB command까지 제공합니다. test agent는 개발자가 실제 Gemini 통합을 기다리지 않고도 시뮬레이션 환경에서 AppFunctions를 실험하고 디버그할 수 있게 합니다.

이 대목은 작지만 실무적으로 큽니다. 에이전트가 앱을 호출하려면 함수 이름만 있으면 되는 것이 아닙니다. 어떤 작업을 함수로 쪼갤지, 어떤 parameter를 받을지, 누가 호출할 수 있는지, 실패했을 때 어떤 오류를 돌려줄지, 사용자의 confirmation이 필요한 작업과 그렇지 않은 작업을 어떻게 나눌지가 필요합니다. UI 개발자가 Activity와 Composable을 설계하듯, 이제 일부 앱은 agent-facing function surface를 설계해야 합니다.

Android AI hub도 같은 방향을 보입니다. AI on Android 문서는 AppFunctions를 "qualified agents"가 앱 capability를 사용할 수 있게 하는 기능으로 설명하고, Android Computer Control은 지원 기기에서 OEM-preloaded assistant가 task automation을 할 수 있게 하는 fallback 성격의 프레임워크로 나란히 둡니다. 즉 Google의 그림은 함수형 통합과 UI 자동화를 경쟁 관계로만 두지 않습니다. 앱이 명시적 함수를 제공하면 더 안정적인 호출 경로를 쓰고, 아직 함수가 없는 앱에는 자동화가 보조 경로가 되는 구조에 가깝습니다.

온디바이스 모델은 기능이 아니라 배포 조건입니다

두 번째 축은 Gemini Nano 4와 ML Kit GenAI입니다. 공식 recap은 AICore Developer Preview에서 다음 세대 Gemini Nano 모델을 이미 prototype할 수 있으며, production-ready 앱은 ML Kit GenAI Prompt API를 통해 Gemini Nano 4를 활용하는 흐름으로 전환할 수 있다고 설명합니다. 이 모델은 올해 말 flagship devices에 들어갈 예정이라고 적혀 있습니다.

이 표현에는 기대와 제약이 같이 들어 있습니다. 온디바이스 AI는 개인정보, 지연 시간, 오프라인 처리, 비용 측면에서 매력적입니다. 그러나 모든 Android 기기가 같은 모델을 같은 성능으로 돌릴 수 있는 것은 아닙니다. Reddit의 Android와 LocalLLaMA 쪽 반응도 이 지점에 걸려 있습니다. 일부 사용자는 Gemini Nano 4와 Gemma 계열이 모바일에서 돌아가는 점을 긍정적으로 보지만, 다른 사용자는 NPU 지원 여부, 로컬 모델이 차지하는 저장 공간과 메모리, 기기별 지원 범위가 실제 제품 경험을 좌우할 것이라고 봅니다.

Google이 ML Kit 쪽에서 structured output과 prefix caching을 강조한 것도 그래서입니다. 앱 기능 안에 LLM을 넣는 순간 개발자는 "대충 답이 그럴듯하다"로 끝낼 수 없습니다. 일정, 메시지, 결제, 쇼핑, 헬스케어, 업무 앱 안에서 모델 출력은 UI 상태와 데이터 변경으로 이어집니다. Prompt API의 structured output은 반환 객체 형태를 안정화하려는 시도이고, prefix caching은 반복되는 prompt의 중간 상태를 재사용해 지연 시간을 줄이려는 장치입니다. ML Kit prefix caching 문서는 공유되고 반복되는 prompt 부분을 처리한 LLM state를 저장해 inference time을 줄이는 방식이라고 설명합니다.

이것은 작은 최적화처럼 보이지만 모바일에서는 더 큰 의미를 갖습니다. 서버에서는 토큰 비용과 처리량이 병목입니다. 휴대폰에서는 그 위에 배터리, 발열, foreground latency, 모델 다운로드, 기기별 accelerator 차이가 붙습니다. 같은 agent flow라도 "항상 클라우드로 보내기"와 "항상 로컬에서 처리하기"는 둘 다 단순하지만 제품적으로 거칠 수 있습니다. 어떤 요청은 개인정보 때문에 로컬이 맞고, 어떤 요청은 모델 품질 때문에 클라우드가 맞으며, 어떤 요청은 연결 상태에 따라 fallback이 필요합니다.

Hybrid Inference는 모바일 AI의 라우팅 정책입니다

Firebase AI Logic Hybrid Inference가 흥미로운 지점이 여기에 있습니다. Google은 4월 별도 글에서 Firebase API for hybrid inference를 소개하며, 초기에는 rule-based routing으로 on-device Gemini Nano와 cloud-hosted Gemini models 사이를 전환할 수 있다고 설명했습니다. 5월 recap은 이를 다시 가져와 PREFER_ON_DEVICE, PREFER_CLOUD, ONLY_ON_DEVICE, ONLY_CLOUD 같은 orchestration mode를 제시합니다.

이 네 가지 mode는 개발자에게 단순한 옵션 이상의 의미를 가집니다. ONLY_ON_DEVICE는 개인정보와 오프라인 요구가 강한 기능에 맞습니다. 예를 들어 사용자의 로컬 메모나 화면 안 정보를 요약하되 서버 전송을 피해야 하는 경우입니다. PREFER_ON_DEVICE는 대부분 로컬에서 처리하되 품질이나 지원 여부에 따라 cloud fallback을 고려하는 제품에 맞습니다. PREFER_CLOUD는 복잡한 추론이나 최신 모델 품질이 필요한 기능에 맞고, ONLY_CLOUD는 온디바이스 모델로는 감당하기 어려운 작업에 맞습니다.

이 라우팅은 에이전트 안전과도 연결됩니다. 에이전트가 사용자의 앱을 조작하고 데이터를 읽는다면, 단지 "모델이 똑똑한가"가 아니라 "어떤 데이터가 어디서 처리되는가"가 제품 신뢰의 핵심이 됩니다. Android가 OS 레벨에서 AppFunctions, AICore, ML Kit, Firebase AI Logic을 함께 밀고 있다는 것은 모바일 AI의 경쟁이 모델 호출 API 하나로 끝나지 않는다는 뜻입니다. 앱 함수 표면, 로컬 모델, 클라우드 모델, 권한, UI 렌더링, 개발 도구가 하나의 stack으로 묶여야 합니다.

A2UI와 ADK for Android가 가리키는 다음 단계

공식 글에서 짧게 언급된 A2UI Jetpack Compose Renderer도 지나치기 어렵습니다. 에이전트가 단순 텍스트 답변을 넘어서 앱 안에서 사용자에게 선택지를 보여주고, 진행 상태를 설명하고, 확인 UI를 띄우고, 결과를 native UI component로 표현하려면 "에이전트가 UI를 말하는 방식"이 필요합니다. Google은 A2UI messages를 Jetpack Compose component로 자동 렌더링하는 방향을 언급했습니다. 이는 agent output을 markdown이나 chat bubble로만 보여주는 단계를 넘어, 앱 UI 안에 안전하게 끼워 넣는 문제입니다.

ADK for Android 0.1.0은 더 직접적입니다. Google Developers Blog의 ADK for Kotlin and Android 발표는 Android 앱 안에서 LLM agent, tools, sub-agents를 구성하는 예시를 보여줍니다. Android용 dependency를 추가하고, LlmAgent에 model, instruction, tools, subAgents를 붙이는 식입니다. 아직 실험 성격이 강하지만, 모바일 앱이 단순히 Gemini를 호출하는 client가 아니라 자기 안에 agent workflow를 품는 방향을 열어둔 셈입니다.

이 흐름을 AppFunctions와 합치면 그림이 더 선명해집니다. 한쪽에서는 Android 앱이 외부 agent에게 자신의 기능을 도구로 제공합니다. 다른 한쪽에서는 Android 앱 내부에 agent workflow를 만들 수 있습니다. 여기에 Firebase Hybrid Inference가 로컬과 클라우드 모델 라우팅을 맡고, A2UI가 agent output을 native UI로 바꿉니다. 결국 모바일 앱의 AI 통합은 "채팅창 하나 붙이기"에서 "앱 기능, 모델 위치, UI 출력, 권한 경계, 테스트 도구를 함께 설계하기"로 넓어집니다.

개발자가 지금 볼 포인트

첫째, 모든 기능을 AppFunctions로 노출할 필요는 없습니다. 오히려 그렇게 하면 위험합니다. 에이전트가 호출해도 되는 작업은 사용자의 intent가 명확하고, 입력 schema가 안정적이며, 실패와 되돌리기 경로가 분명해야 합니다. 읽기 작업, draft 생성, 검색, 추천, 미리보기는 초기 후보가 될 수 있습니다. 결제, 삭제, 외부 전송, 권한 변경 같은 작업은 confirmation과 audit trail이 없으면 곤란합니다.

둘째, KDoc과 schema는 문서가 아니라 실행 품질의 일부가 됩니다. MCP 생태계에서 이미 보듯, tool description이 애매하면 모델은 잘못된 도구를 고르거나 parameter를 엉뚱하게 채웁니다. Google이 AppFunctions skill에서 KDoc 최적화를 언급한 이유도 여기에 있습니다. 사람 개발자에게만 읽히던 주석이 이제 agent planner의 입력이 됩니다.

셋째, 로컬 모델과 클라우드 모델을 제품 정책으로 나눠야 합니다. "AI 기능"이라는 이름 아래 모든 요청을 하나의 모델로 보내는 방식은 모바일에서는 오래 버티기 어렵습니다. 사용자의 민감 데이터, 지연 시간, 네트워크 상태, 모델 품질, 비용, 배터리 조건이 기능마다 다르기 때문입니다. Hybrid Inference mode는 아직 단순해 보이지만, 실제 제품팀에는 개인정보 정책과 UX fallback을 코드로 표현하는 시작점이 됩니다.

넷째, 테스트 전략이 바뀝니다. 기존 Android 테스트는 UI test, unit test, integration test가 중심이었습니다. AppFunctions가 들어오면 agent가 함수 목록을 어떻게 발견하는지, 어떤 자연어 intent가 어떤 function으로 라우팅되는지, permission denied와 partial failure가 어떻게 보이는지, 생성된 UI가 사용자의 확인을 제대로 받는지를 검증해야 합니다. Google이 test agent를 제공하는 이유는 이 표면이 실제 Gemini 배포 전에 먼저 깨져야 하기 때문입니다.

아직은 좁은 문입니다

이번 발표를 과장해서 읽으면 안 됩니다. AppFunctions는 experimental preview이고, Gemini 통합은 private preview입니다. Android 16 이상이라는 조건도 있습니다. Gemini Nano 4는 flagship devices에 들어갈 예정이며, 온디바이스 모델 성능과 지원 범위는 기기별로 갈릴 수 있습니다. ADK for Android도 0.1.0 단계입니다. 즉 지금 당장 모든 Android 앱이 AI agent의 도구가 되는 것은 아닙니다.

하지만 방향은 분명합니다. Google은 Android 앱 생태계를 에이전트 시대에 맞게 다시 주소 지정하려 합니다. 지금까지 앱은 launcher icon, intent, deep link, notification, share sheet, widget 같은 표면을 통해 시스템과 연결됐습니다. AppFunctions가 자리 잡으면 여기에 "agent-callable function"이라는 새 표면이 추가됩니다. 사용자는 앱을 직접 열지 않고도 Gemini나 다른 agent를 통해 앱의 기능을 호출할 수 있고, 개발자는 그 호출이 무슨 일을 할 수 있고 할 수 없는지 정의해야 합니다.

이 변화는 앱 discovery에도 영향을 줄 수 있습니다. 모바일에서 앱의 가치는 오랫동안 홈 화면의 위치, push notification, 검색 노출, store ranking, deep link 연결로 측정됐습니다. 에이전트가 사용자의 intent를 받아 앱 기능을 대신 호출하는 구조가 커지면, 앱은 사람에게 잘 보이는 UI뿐 아니라 agent에게 잘 설명된 capability를 가져야 합니다. "이 앱은 어떤 일을 할 수 있는가"가 자연어와 schema로 발견되는 시대가 되는 것입니다.

결론: Android 개발의 AI 과제는 앱 안쪽으로 들어왔습니다

Google의 5월 26일 Android AI recap은 큰 무대 발표 뒤에 나온 개발자용 정리글입니다. 그러나 그 안에 담긴 메시지는 작지 않습니다. Android의 에이전트 전략은 Gemini 앱 하나의 기능 경쟁이 아니라, 앱이 OS 안에서 호출 가능한 도구가 되는 생태계 전환에 가깝습니다.

개발자에게 당장 필요한 대응은 유행어를 따라 agent를 붙이는 것이 아닙니다. 앱의 핵심 workflow를 살펴보고, 어떤 작업이 함수로 노출될 때 사용자에게 이득이 있는지, 어떤 작업은 절대 자동 호출되어서는 안 되는지, 로컬 모델과 클라우드 모델 중 어느 쪽이 맞는지, agent가 만든 UI를 어디까지 native flow에 들일지 판단하는 일입니다.

MCP가 서버와 개발 도구의 연결 방식을 바꿨다면, AppFunctions는 그 질문을 휴대폰 안으로 가져옵니다. 앱이 화면으로만 존재하던 시대에서, 앱이 에이전트가 호출할 수 있는 권한 있는 도구 묶음으로 존재하는 시대로 가는 초입입니다. Android의 새 입구는 그래서 Gemini 자체가 아니라, 앱 개발자가 정의하게 될 작은 함수들일 수 있습니다.