Gemini Intelligence, Android 앱을 에이전트 도구로 바꾼다

AI 요약

• 무슨 일: Google이 5월 12일 Gemini Intelligence를 발표하며 Android를 "intelligence system"으로 재정의했습니다.
  • 최신 Samsung Galaxy와 Google Pixel 폰부터 여름에 순차 배포되고, 이후 watch, car, glasses, laptops로 확장됩니다.
• 개발자 포인트: AppFunctions는 Android 앱 기능을 OS 레벨 registry에 등록해 Gemini 같은 에이전트가 발견하고 실행하게 합니다.
• 의미: 모바일 앱 경쟁이 "예쁜 화면"에서 "에이전트가 호출할 수 있는 로컬 도구" 설계로 이동합니다.
• 주의점: Gemini 통합은 아직 trusted tester 중심 private preview이며, 권한·개인정보·플랫폼 종속성 질문이 남아 있습니다.

Google이 2026년 5월 12일 The Android Show에서 던진 메시지는 꽤 분명합니다. Android는 더 이상 앱을 실행하는 운영체제에 머물지 않겠다는 것입니다. Google은 새 발표에서 Android가 "operating system"에서 "intelligence system"으로 전환한다고 표현했습니다. 말만 보면 익숙한 AI 마케팅처럼 들릴 수 있습니다. 하지만 개발자 관점에서 중요한 부분은 Gemini가 더 똑똑해졌다는 사실보다, Android 앱의 경계가 바뀌기 시작했다는 점입니다.

핵심 이름은 두 개입니다. 소비자에게 보이는 이름은 Gemini Intelligence입니다. 사용자는 Gemini에게 음식 주문, 장보기, 예약, 웹 비교, 폼 작성, 음성 메시지 정리, 자연어 위젯 생성 같은 일을 맡길 수 있습니다. 개발자에게 더 중요한 이름은 AppFunctions입니다. AppFunctions는 앱 안의 기능을 Android OS가 인덱싱할 수 있는 함수로 노출하고, Gemini 같은 에이전트나 승인된 caller가 그 기능을 발견하고 실행하게 하는 API입니다.

이 조합은 모바일 앱의 오래된 전제를 흔듭니다. 지금까지 앱은 사용자가 화면을 열고, 버튼을 누르고, 폼을 채우고, 다음 화면으로 이동하는 흐름을 중심으로 설계됐습니다. Gemini Intelligence가 말하는 미래에서는 사용자가 앱을 직접 열지 않을 수 있습니다. 대신 "Lisa가 보낸 국수 레시피 찾아서 장보기 목록에 넣어줘"라고 말하면, 에이전트가 메일 앱의 검색 기능과 쇼핑 목록 앱의 추가 기능을 이어 붙입니다. 개발자가 준비해야 할 것은 화면뿐 아니라, 에이전트가 안전하게 호출할 수 있는 기능 표면입니다.

Android의 AI 발표가 이번에는 개발자 뉴스인 이유

Google Keyword의 공식 글은 Gemini Intelligence를 최신 Android 기기의 proactive AI 기능 묶음으로 소개합니다. Gemini는 멀티스텝 앱 자동화, Chrome에서의 요약·비교·예약, 복잡한 폼 자동 입력, Gboard 음성 입력을 다듬는 Rambler, 자연어로 만드는 Create My Widget 등을 담당합니다. 배포는 올여름 최신 Samsung Galaxy와 Google Pixel 폰에서 시작되고, 이후 시계, 자동차, 안경, 노트북으로 확대됩니다.

사용자 입장에서는 "폰이 더 많은 잡일을 해준다"는 뉴스입니다. 예를 들어 긴 장보기 목록을 노트 앱에서 보고 있을 때 전원 버튼을 길게 눌러 Gemini를 부르고, 그 목록을 배송 장바구니로 만들어 달라고 요청할 수 있습니다. 여행 브로셔 사진을 찍고 "6명이 갈 수 있는 비슷한 투어를 Expedia에서 찾아줘"라고 할 수도 있습니다. Google은 Gemini가 백그라운드에서 진행 상황을 알림으로 보여주고, 마지막 확인은 사용자가 하며, 작업이 끝나면 멈춘다고 설명합니다.

하지만 개발자에게 이 발표가 중요한 이유는 UI 자동화만이 아닙니다. UI 자동화는 어떤 면에서 불안정한 우회로입니다. 화면 구조가 바뀌면 깨지고, 접근성 트리나 텍스트 인식에 의존하며, 앱이 어떤 상태인지 명확히 알기 어렵습니다. 그래서 Google은 더 명시적인 경로를 같이 내놓았습니다. Android Developers Blog는 개발자가 "no-code change"에 가까운 앱 자동화 경로와, AppFunctions API를 통해 더 직접적으로 제어하는 경로를 선택할 수 있다고 설명합니다.

AppFunctions는 이 발표의 진짜 개발자 API입니다. Android 앱은 특정 서비스, 데이터, 액션을 함수로 노출합니다. Jetpack 라이브러리는 이 함수의 스키마를 만들고, Android OS는 이를 registry에 인덱싱합니다. caller는 사용자 의도와 앱 기능 메타데이터를 바탕으로 적절한 함수를 고르고 파라미터를 채워 실행합니다. Google 문서는 이를 "모바일판 MCP"에 가깝게 설명합니다. 서버 쪽 도구를 MCP 서버로 노출하듯, Android 앱은 온디바이스 도구를 AppFunctions로 노출하는 구조입니다.

AppFunctions는 모바일 앱을 로컬 도구 서버로 만든다

AppFunctions 문서에서 가장 눈에 띄는 문장은 앱이 "on device MCP servers"처럼 행동할 수 있다는 설명입니다. MCP는 원래 AI 에이전트가 서버 측 도구, 데이터, 외부 시스템에 표준화된 방식으로 연결하기 위한 프로토콜로 주목받았습니다. AppFunctions는 같은 사고방식을 모바일 OS 내부로 가져옵니다. 차이는 네트워크가 아니라 로컬 앱 상태와 OS registry가 중심이라는 점입니다.

흐름은 네 단계로 정리할 수 있습니다. 먼저 앱 개발자가 "Create note", "Send message", "Create calendar event" 같은 함수를 선언합니다. 다음으로 AppFunctions Jetpack 라이브러리가 XML schema 파일을 생성합니다. Android OS는 이 스키마를 인덱싱합니다. 마지막으로 에이전트는 메타데이터를 조회하고, 사용자 요청에 맞는 함수를 골라 실행합니다. 함수는 자연어 설명과 타입 정보가 붙은 도구가 됩니다.

예를 들어 생산성 앱은 "오늘 오후 5시에 회사에서 택배 찾기 알림을 만들어줘"라는 요청을 받을 수 있습니다. 에이전트는 task 앱의 createTask 함수를 찾아 title, dueDateTime, location을 채웁니다. 음악 앱은 "올해 나온 재즈 앨범으로 플레이리스트 만들어줘"라는 요청을 createPlaylistFromQuery에 연결할 수 있습니다. 캘린더 앱은 "다음 주 월요일 6시에 엄마 생일 파티 추가해줘"라는 요청을 event 생성 함수로 처리할 수 있습니다.

중요한 점은 이 기능이 앱 UI를 흉내 내는 것이 아니라는 점입니다. 에이전트가 버튼 위치를 추측하거나 텍스트 필드를 찾아 클릭하는 대신, 앱이 허용한 기능을 타입 있는 함수로 호출합니다. 이 차이는 안정성과 권한 모델에서 큽니다. UI 자동화는 사람 사용자의 행동을 모방합니다. AppFunctions는 앱 개발자가 "이 기능은 외부 caller에게 도구로 제공해도 된다"고 선언하는 계약에 가깝습니다.

Google은 caller가 EXECUTE_APP_FUNCTIONS 권한을 가져야 함수를 발견하고 실행할 수 있다고 명시합니다. AppFunctions는 Android 16 이상에서 사용 가능하지만, Gemini와의 end-to-end 통합은 2026년 5월 기준 trusted tester 대상 private preview입니다. 즉 오늘 당장 모든 앱이 Gemini에게 완전히 열리는 것은 아닙니다. 앱 개발자는 API를 구현하고 테스트할 수 있지만, 시스템 에이전트가 접근하는 전체 파이프라인은 제한적으로 운영됩니다.

모바일 MCP라는 표현이 과장만은 아니다

AppFunctions를 MCP와 바로 동일시하면 놓치는 부분이 있습니다. MCP는 플랫폼 중립적인 서버-클라이언트 연결 표준입니다. AppFunctions는 Android OS에 묶인 platform API입니다. MCP 서버는 보통 네트워크나 로컬 프로세스 경계를 넘어 에이전트와 연결됩니다. AppFunctions는 앱 패키지, Android 권한, OS 인덱싱, Jetpack annotation processor, 온디바이스 실행을 전제로 합니다.

그럼에도 "모바일 MCP"라는 비유가 유용한 이유가 있습니다. 에이전트가 앱을 쓰는 방식이 사람이 앱을 쓰는 방식에서 분리되기 때문입니다. 웹에서 좋은 에이전트 경험을 만들려면 API, MCP server, tool schema, auth boundary가 중요해졌습니다. Android에서도 같은 일이 벌어집니다. 앱은 사용자용 화면뿐 아니라 에이전트용 함수 표면을 설계해야 합니다.

이 변화는 특히 슈퍼앱이 아닌 일반 앱에 중요합니다. 모든 앱이 자체 AI assistant를 만들 수는 없습니다. 하지만 Android OS의 agent runtime이 보편화되면, 앱은 Gemini에게 "내가 할 수 있는 일"을 알려주는 방식으로 존재감을 유지할 수 있습니다. 레시피 앱은 재료 추출과 저장 기능을, 은행 앱은 잔액 조회와 송금 준비 기능을, 피트니스 앱은 운동 기록 생성 기능을, 메신저 앱은 메시지 전송과 통화 시작 기능을 노출할 수 있습니다.

Google이 예로 든 KakaoTalk 테스트도 이 맥락에서 중요합니다. Android Developers Blog는 KakaoTalk 같은 앱으로 "send messages"와 "initiate voice calls"를 private preview에서 테스트하기 시작했다고 밝혔습니다. 또 AppFunctions가 이미 25개 앱 use case의 local execution을 device manufacturers 전반에서 가능하게 했다고 설명합니다. 숫자가 크지는 않지만, Google이 단순 데모가 아니라 앱 생태계 통합을 준비하고 있다는 신호입니다.

앱의 경쟁 단위가 화면에서 의도 처리로 이동한다

모바일 앱 개발자가 지금까지 최적화해온 것은 대부분 화면 흐름이었습니다. 첫 실행 온보딩을 줄이고, 탭 수를 줄이고, 리스트를 빠르게 로딩하고, 폼을 덜 귀찮게 만들고, 푸시 알림으로 재방문을 유도합니다. Gemini Intelligence 이후에도 이 일은 사라지지 않습니다. 하지만 앱이 선택받는 경로가 하나 더 생깁니다. 사용자가 앱 아이콘을 누르는 대신, Gemini에게 목적을 말하고, Gemini가 적절한 앱 기능을 호출하는 경로입니다.

이때 앱의 경쟁력은 "에이전트가 나를 정확히 선택할 수 있는가"로 바뀝니다. 함수 이름, KDoc 설명, 파라미터 타입, 반환 타입, enabled 상태, 실패 처리, 권한 요청 UX가 제품 경험의 일부가 됩니다. 검색 엔진 시대에 웹사이트가 사람과 크롤러를 동시에 고려해야 했던 것처럼, 에이전트 시대의 앱은 사람과 caller를 동시에 고려해야 합니다.

예를 들어 음식 배달 앱이 Gemini Intelligence에 대응한다고 해봅시다. 단순히 "주문하기" 하나만 노출하면 에이전트는 많은 확인을 다시 요구해야 합니다. 반대로 "최근 주문 반복", "장바구니 생성", "대체 품목 제안", "배송 시간 조회", "쿠폰 적용 가능성 확인", "최종 결제 전 요약" 같은 함수를 잘 나누면 에이전트는 사용자의 의도를 더 자연스럽게 처리할 수 있습니다. 하지만 너무 넓은 함수를 열면 권한과 오작동 위험이 커집니다. 함수 설계가 곧 제품 설계이자 보안 설계가 됩니다.

여기서 Android의 위치가 흥미롭습니다. 웹 에이전트는 브라우저와 서버 API 사이에서 움직입니다. 데스크톱 코딩 에이전트는 파일 시스템, 터미널, Git, 브라우저를 다룹니다. Android 에이전트는 사용자의 가장 개인적인 기기 안에서 연락처, 메시지, 위치, 일정, 결제, 사진, 앱 상태를 다룰 수 있습니다. 생산성 잠재력은 크지만, 실패 비용도 큽니다. 그래서 Google이 "투명성과 통제"를 반복하는 것은 필수에 가깝습니다.

Google이 동시에 밀고 있는 세 가지 자동화 경로

이번 발표를 하나의 기능으로 보면 복잡합니다. 실제로는 세 가지 자동화 경로가 겹쳐 있습니다. 첫째는 앱 UI 자동화입니다. Gemini가 사용자의 명령을 받아 여러 앱을 넘나들며 작업을 수행합니다. Google은 음식·차량호출 파트너와 테스트한 멀티스텝 자동화를 더 많은 vertical과 form factor로 확장한다고 밝혔습니다.

둘째는 AppFunctions입니다. 개발자가 명시적으로 앱 기능을 도구화하는 경로입니다. 이 방식은 UI 자동화보다 안정적이고, 앱 개발자가 제어할 수 있는 범위가 넓습니다. Google은 이를 "more control"이 필요한 개발자에게 제시합니다. AppFunctions는 로컬 앱 상태를 직접 쓸 수 있고, 별도 서버를 유지하지 않아도 됩니다. 문서의 FAQ도 AppFunctions와 MCP의 차이를 이 지점에서 설명합니다.

셋째는 Chrome과 Autofill 같은 시스템 기능 확장입니다. Google은 6월 말부터 Android 기기에서 Gemini in Chrome이 웹 콘텐츠 조사, 요약, 비교를 돕고, Chrome auto browse가 예약이나 주차 공간 확보 같은 mundane task를 처리할 수 있다고 예고했습니다. Autofill with Google은 Gemini의 Personal Intelligence와 연결되어 더 복잡한 모바일 폼을 채우는 방향으로 진화합니다. 이 연결은 opt-in이며 설정에서 켜고 끌 수 있다고 Google은 설명합니다.

이 세 경로는 서로 대체재가 아니라 보완재입니다. 앱이 AppFunctions를 제공하면 에이전트는 명시적 도구를 호출할 수 있습니다. 앱이 준비되지 않았거나 웹 플로우가 중심이면 Gemini는 UI나 브라우저 자동화를 사용할 수 있습니다. 폼처럼 구조화된 개인정보 입력은 Autofill이 담당합니다. Google이 말하는 "intelligence system"은 특정 챗봇 기능이 아니라, OS 여러 층에 걸친 자동화 라우팅에 가깝습니다.

개인화와 권한 문제는 피할 수 없다

이 발표가 흥미로운 만큼 불편한 질문도 큽니다. Gemini Intelligence는 사용자의 연결 앱, 화면, 이미지, 웹 페이지, 위치, 일정, 메일, 폼, 음성 입력과 가까워질수록 더 유용해집니다. 동시에 더 민감해집니다. Google은 데이터 프라이버시와 사용자 통제를 강조합니다. Gemini는 사용자의 명령에 따라 행동하고, 최종 확인을 남기며, Rambler의 음성은 실시간 transcription에만 쓰이고 저장되지 않는다고 설명합니다. Autofill과 Gemini 연결도 opt-in이라고 말합니다.

하지만 사용자와 규제기관이 이 설명만으로 충분히 안심할지는 별개의 문제입니다. Android 커뮤니티 반응은 이미 갈립니다. 일부 사용자는 드디어 모바일 assistant가 실제 일을 처리하는 단계로 들어갔다고 봅니다. 반면 다른 사용자는 "Google이 사용자를 통제한다"는 식의 냉소적 반응을 보입니다. EU 같은 지역에서는 개인정보, 경쟁, 플랫폼 권한 이슈 때문에 기능 출시가 늦어질 수 있다는 예상도 나옵니다.

개발자에게도 책임이 생깁니다. AppFunctions는 앱 기능을 열어주는 API입니다. 어떤 함수는 읽기 전용이어도 괜찮지만, 어떤 함수는 메시지 전송, 결제 준비, 일정 생성, 데이터 삭제처럼 되돌리기 어려운 행동을 합니다. 함수 호출 전에 어떤 확인이 필요한지, 사용자가 어떤 로그를 볼 수 있어야 하는지, 실패하거나 오인식됐을 때 어떻게 롤백할지 정해야 합니다. 에이전트가 호출한다고 해서 앱의 기존 보안 모델을 우회해도 되는 것은 아닙니다.

특히 "최종 확인"의 위치가 중요합니다. Google의 소비자 발표는 Gemini가 작업을 처리하고 마지막 confirmation은 사용자에게 남긴다고 설명합니다. 그러나 앱마다 confirmation의 의미가 다릅니다. 장바구니 생성은 괜찮아도 결제는 다릅니다. 메시지 초안 작성은 괜찮아도 전송은 다릅니다. 캘린더 초안 생성은 괜찮아도 참석자 초대 발송은 다릅니다. AppFunctions를 설계하는 팀은 함수별 risk tier를 나누고, low-risk 자동화와 high-risk 확인 단계를 분리해야 합니다.

Apple App Intents와의 다음 경쟁

Google의 AppFunctions는 Android만의 독립 사건으로 보기 어렵습니다. Apple 생태계에는 이미 App Intents가 있습니다. Siri, Shortcuts, Spotlight, Widgets 같은 시스템 기능과 앱 액션을 연결하는 방식입니다. Apple Intelligence가 더 강한 개인 assistant로 진화할수록 App Intents의 중요성도 커집니다. Google은 AppFunctions로 Android 앱 생태계에 비슷하지만 더 에이전트 중심적인 표면을 만들고 있습니다.

차이는 Google이 MCP와 agentic automation의 언어를 더 직접적으로 쓰고 있다는 점입니다. AppFunctions 문서는 함수가 agents and assistants의 tools로 쓰인다고 설명하고, server-side remote MCP tools와 local AppFunctions를 함께 고려할 수 있다고 말합니다. 이는 모바일 앱이 클라우드 에이전트와 로컬 앱 도구의 조합 안에 들어간다는 뜻입니다.

예를 들어 사용자가 "다음 출장 준비해줘"라고 요청하면 에이전트는 Gmail에서 항공권을 찾고, Calendar에 일정을 넣고, Maps에서 이동 시간을 계산하고, 메신저로 동료에게 도착 시간을 보내고, 회사 expense 앱에 영수증 폴더를 만들 수 있습니다. 일부는 서버 MCP로, 일부는 Android AppFunctions로, 일부는 브라우저 자동화로 처리됩니다. 플랫폼이 이 routing을 잘하면 사용자는 하나의 assistant를 쓰는 것처럼 느낍니다. 플랫폼이 실패하면 앱마다 권한 팝업과 확인 화면이 쌓입니다.

이 경쟁의 승자는 모델 성능만으로 결정되지 않습니다. 앱 생태계가 얼마나 빨리 도구 표면을 제공하는지, OS 권한 모델이 얼마나 신뢰를 주는지, 개발자 도구가 얼마나 덜 귀찮은지, 사용자가 자동화를 얼마나 자주 실제로 성공 경험으로 느끼는지가 중요합니다. Google은 Android라는 배포면을 갖고 있지만, fragmentation이라는 오래된 숙제도 함께 갖고 있습니다. AppFunctions가 Android 16 이상이라는 조건을 가진다는 점도 초기 확산 속도에 영향을 줄 수 있습니다.

지금 앱 팀이 봐야 할 실무 질문

이번 발표를 보고 당장 모든 Android 앱이 AppFunctions를 구현해야 한다고 말하기는 이릅니다. Gemini 통합은 private preview이고, API도 experimental입니다. Google 문서도 API surface를 다듬는 중이며 변경될 수 있다고 말합니다. 하지만 방향성은 충분히 분명합니다. 사용자의 의도는 점점 assistant를 통해 들어오고, 앱은 그 의도를 처리할 수 있는 구조화된 기능을 제공해야 합니다.

앱 팀이 먼저 할 일은 "우리 앱에서 사람이 반복하는 행동은 무엇인가"를 정리하는 것입니다. 반복적이고 저위험이며 파라미터가 명확한 작업부터 함수 후보가 됩니다. 알림 생성, 목록 추가, 검색, 초안 작성, 예약 가능 시간 조회, 상태 확인, 즐겨찾기 저장, 최근 주문 재구성 같은 기능입니다. 반대로 결제, 삭제, 외부 전송, 권한 변경, 개인정보 공개는 더 엄격한 확인 흐름이 필요합니다.

두 번째 질문은 "에이전트가 이 기능을 발견할 만큼 설명이 좋은가"입니다. 함수 이름과 설명은 사람 개발자만 읽는 문서가 아닙니다. 에이전트가 도구 선택에 참고할 메타데이터입니다. 모호한 이름, 과도하게 넓은 함수, 문자열 하나로 모든 것을 받는 API는 에이전트에게도 나쁜 도구입니다. 좋은 AppFunction은 작은 범위, 명확한 타입, 예측 가능한 반환값, 실패 이유를 가져야 합니다.

세 번째 질문은 "사용자가 나중에 무슨 일이 일어났는지 알 수 있는가"입니다. 에이전트 자동화는 성공했을 때는 마법처럼 보이지만, 실패했을 때는 책임 소재가 흐려집니다. 앱은 호출 로그, pending confirmation, 취소 가능 상태, 변경 내역을 사용자에게 보여줄 필요가 있습니다. 특히 메시지, 일정, 결제, 파일, 건강 데이터처럼 민감한 도메인은 자동화보다 auditability가 먼저입니다.

Android는 에이전트 런타임이 될 수 있을까

Google의 이번 발표는 AI 기능 추가라기보다 Android의 역할 재정의에 가깝습니다. Android는 앱 런처, 권한 관리자, 알림 시스템, 백그라운드 작업 관리자, 결제와 ID의 중개자였습니다. Gemini Intelligence와 AppFunctions가 자리 잡으면 Android는 여기에 에이전트 런타임이라는 역할을 더합니다. 앱은 화면으로만 존재하지 않고, OS가 발견하고 조합할 수 있는 기능 묶음으로도 존재합니다.

성공하면 모바일 사용 방식은 크게 달라집니다. 사용자는 앱 사이를 옮겨 다니며 작은 작업을 직접 연결하지 않아도 됩니다. 개발자는 자신의 앱 기능이 더 많은 intent 흐름 안에서 호출될 기회를 얻습니다. Google은 Gemini를 Android 생태계의 기본 조율자로 만들 수 있습니다. 실패하면 또 하나의 과한 assistant 레이어가 됩니다. 권한은 복잡해지고, 자동화는 불안정하며, 사용자는 끄는 법부터 찾게 됩니다.

지금 단계에서 가장 현실적인 해석은 중간입니다. Gemini Intelligence는 아직 완성된 모바일 에이전트 시대가 아닙니다. 하지만 AppFunctions는 그 시대를 준비하는 API입니다. 웹에서 MCP가 "에이전트가 쓸 수 있는 도구 표면"의 표준 언어가 된 것처럼, Android에서는 AppFunctions가 같은 질문을 던지고 있습니다. 당신의 앱은 사람이 누르는 화면인가, 아니면 에이전트가 안전하게 호출할 수 있는 기능인가. 2026년 Android 개발에서 이 질문은 점점 더 중요해질 것입니다.