제미나이가 경쟁사 앱을 호출하는 날, 내 사이드 앱은 준비됐을까

 

'내일 오전 팀장님이랑 회의 잡아줘.' 사용자가 제미나이(gemini)에 말합니다. 제미나이가 캘린더 앱을 열고 일정을 넣어요. 그런데 그 캘린더 앱은 제가 만든 앱이 아니라, 인텐트(intent) 필터를 제대로 달아둔 경쟁사 앱이에요.

 

2026-05-12 android show에서 발표된 제미나이 인텔리전스(gemini intelligence)의 핵심이 바로 이 장면인데요. 사실 이 기능의 밑바탕에는 올해 2월부터 차근차근 풀리고 있던 appFunctions 기술이 깔려 있습니다. 앱 자동화라고 부르는 이 기능, 쉽게 말하면 제미나이가 사용자의 자연어 요청을 해석해서 기기에 깔린 앱의 특정 기능을 직접 실행해주는 구조예요. 사이드 프로젝트로 앱을 운영하고 있다면 지금부터 무엇을 손봐야 할지 하나씩 정리해봤습니다.

 

제미나이 앱 자동화가 실제로 동작하는 방식

동작 구조는 생각보다 단순합니다. 제미나이가 자연어 요청을 받고 → 앱에 정의된 함수(appFunctions) 스키마와 매칭하고 → 인텐트로 해당 기능을 실행한 뒤 → 결과를 돌려주는 흐름이에요.

 

중요한 점은 민감한 정보 처리는 가급적 온디바이스에서 이뤄지도록 설계됐다는 점이에요. 덕분에 클라우드 서버를 거치지 않아 사용자의 로그인 세션이나 개인 데이터가 외부로 나갈 위험이 적고, 개발자 입장에서는 별도 서버 비용 없이 제미나이와 연동할 수 있다는 얘기입니다.

 

다만 현실적인 위험이 하나 있어요. 제미나이가 작업을 대신 처리하면 사용자는 '앱이 해줬다'가 아니라 '제미나이가 해줬다'고 인식하게 됩니다. 앱 브랜드 노출이 줄고, 광고나 인앱 결제로 이어지는 경로도 우회될 수 있는 구조더라고요. 수익 모델을 처음부터 같이 고민해둬야 하는 이유입니다.

 

발표에 따르면 android 17(one ui 9) 정식 출시와 함께 갤럭시 S26과 픽셀 10에 먼저 탑재되는데, 초기엔 일부 카테고리와 지역 한정으로 열리고 연내 단계적으로 확대될 예정이라고 해요. iOS는 무관합니다.

 

 

사이드 앱 인텐트 필터, 지금 당장 점검해야 할 이유

제미나이가 어떤 앱을 호출할지 결정하는 첫 번째 기준은 AndroidManifest.xml에 선언된 인텐트 필터입니다.

 

android.intent.action.SEND(공유)나 android.intent.action.VIEW(링크 열기) 같은 암시적 인텐트(implicit intent) 필터가 없으면 외부에서 앱을 호출하는 경로 자체가 막힙니다. 제미나이는 특정 앱을 지목해서 실행하는 게 아니라, 해당 인텐트를 처리할 수 있는 앱 중에서 골라 실행하는 방식을 씁니다. 인텐트 필터가 없으면 아예 후보 목록에 오르지도 못해요.

 

딥 링크(deep link) 완성도도 함께 체크해볼 필요가 있습니다.

adb shell am start -a android.intent.action.VIEW -d "https://yourapp.com/..."

 

위 명령어로 딥 링크가 앱 화면으로 정상 라우팅되는지 바로 확인할 수 있어요. 생각보다 이 테스트에서 막히는 앱이 많더라고요.

 

appFunctions 스키마로 제미나이 자연어 호출 준비하기

인텐트 필터가 '앱이 열릴 수 있느냐'를 결정한다면, appFunctions는 '제미나이가 어떤 기능을 어떻게 부를지'를 결정합니다.

 

예전처럼 res/xml/app_functions.xml 파일을 직접 손으로 만드는 게 아니에요. 이제는 훨씬 편해졌더라고요. kotlin 함수에 @AppFunction 어노테이션을 달고, KDoc 주석으로 이 함수가 어떤 동작을 하고 어떤 파라미터를 받는지 자연어 설명을 자세히 적어주면, 컴파일러가 빌드 시점에 스키마를 알아서 만들어주는 구조입니다.

/**
 * 음성으로 받은 내용을 텍스트 메모로 저장하고 자동 태그를 붙입니다.
 * @param title 메모의 제목입니다.
 * @param content 저장할 메모 내용입니다.
 * @param tags 쉼표로 구분된 태그 목록입니다.
 */
@AppFunction(isDescribedByKDoc = true)
fun saveVoiceMemo(title: String, content: String, tags: List<String>) {
    // ... 메모 저장 로직 구현
}

 

여기서 KDoc으로 작성한 설명문 품질이 호출 빈도를 좌우하는데, 이게 기존 앱스토어 최적화(ASO)가 LLM 최적화(LLMO)로 확장되는 지점이라고 보시면 됩니다. 추상적인 설명보다 실제 동작을 묘사한 설명이 제미나이의 선택을 받을 가능성이 높은데, 공식 가이드에서도 이런 동작 중심의 구체적인 설명을 권장하고 있거든요. 핵심 기능 3~5개에 집중해서 설명을 다듬는 게 현실적입니다.

 

개인적으로는 기능 목록을 적기 전에 '제미나이가 어떤 말로 이 기능을 부를까'를 먼저 생각해보는 게 도움이 됩니다. UI 중심이 아니라 함수 단위로 앱을 다시 보게 되는 계기가 되거든요.

 

 

안드로이드 접근성 설정으로 UI 인식률 끌어올리기

appFunctions로 명시적으로 등록하지 않은 기능도 제미나이가 화면을 직접 분석해서 자동화에 활용할 수 있습니다. 화면 캡처를 OCR로 읽어 UI 요소를 찾아 실행하는 방식이에요.

 

이때 기준이 되는 게 접근성(accessibility) 설정입니다. 버튼과 입력 필드에 android:contentDescription이 제대로 달려 있지 않으면 제미나이가 해당 요소를 인식하지 못하는 일이 생길 수 있어요. WCAG 기준의 색 대비 비율이나 아이콘에 텍스트 레이블을 병기하는 습관도 인식률에 직접 영향을 줍니다.

 

특히 jetpack compose의 시맨틱 속성을 활용하면 제미나이의 UI 구조 이해도를 한층 더 끌어올릴 수 있다고 해요. 예를 들어 UI 요소가 버튼인지 헤더인지 명확히 알려주는 거죠. 다행히 머티리얼 디자인 3(material design 3) 컴포넌트를 이미 쓰고 있다면 상당 부분 기본으로 갖춰진 경우가 많습니다.

 

지금 점검할 인텐트 필터 3가지와 appFunctions EAP

appFunctions SDK는 지금 EAP(조기 접근 프로그램) 단계라 구글 플레이 콘솔에서 신청할 수 있습니다. 버전 카탈로그에 appFunctions = "1.0.0-alpha08" 정도로 추가해서 테스트해볼 수 있어요. 비공개 테스트 중이라 프로덕션 앱에 배포하면 안 되고, 테스트 빌드에서만 써야 해요. 아, 그리고 다른 앱에서 내 앱 기능을 실행하려면 매니페스트에 android.permission.EXECUTE_APP_FUNCTIONS 권한 설정도 챙겨야 합니다.

 

그 대신 지금 당장 서버 비용 없이 할 수 있는 준비가 세 가지 있습니다.

1. AndroidManifest.xml에 SEND, VIEW 같은 암시적 인텐트 필터 추가
2. adb로 딥 링크 라우팅 정상 동작 확인
3. 버튼·입력 필드에 contentDescription 전면 보강

이 세 가지는 제미나이 대응 효과뿐 아니라 앱 접근성 전반을 즉시 개선하는 작업이라 어느 쪽으로도 손해가 없어요. EAP 신청도 가능하다면 지금 해두는 편이 안전합니다.

 

 

마치며

제미나이가 앱 인터페이스를 대신 처리하는 비율이 커질수록 '인텐트 필터 하나 빠진 앱'은 설치조차 안 된 앱과 다를 게 없어집니다.

저도 사이드로 운영 중인 앱 두 개부터 이번 주말에 인텐트 필터와 contentDescription 보강을 시작할 생각입니다.