Google Android App Functions는 보안 케이지를 구축했지만, 대부분의 AI 에이전트는 여전히 밖에 남아 있다

Google은 Android 에이전트가 다른 앱에 접근할 수 있는 통제된 경로를 구축했지만, 대다수 사용자는 여전히 그 경로를 확인하거나 관리하거나 실질적으로 활용할 수 없다. Google Android App Functions는 승인된 어시스턴트가 애플리케이션 전반에서 특정 작업을 발견하고 실행하는 방식을 새롭게 정의한다. 문제는 폭넓은 에이전트 생태계가 형성되기 전에 보안 아키텍처가 먼저 도입됐다는 점이다.

이는 단순히 미완성 상태의 또 다른 Android 기능이 아니다. Google은 누가 애플리케이션 내부에서 행동할 수 있는지, 그 주체들이 무엇을 발견할 수 있는지, 개발자가 어떤 작업을 공개할지를 결정하고 있다. 이러한 선택은 메모를 만들고, 사진을 찾고, 미디어를 재생하거나, 장바구니를 구성하는 미래의 에이전트를 위한 제어 계층을 확립한다.

또한 이는 화면을 해석하고 탭을 흉내 내며 휴대전화를 조작하는 에이전트와 Google의 접근 방식을 구분한다. 화면 조작 시스템은 깊은 앱 통합 없이도 작동할 수 있지만, 레이아웃 변경과 오도하는 콘텐츠에 여전히 취약하다. App Functions는 더 깔끔한 경로를 제공하지만, 승인된 에이전트와 참여 앱만 이를 사용할 수 있다.

Google은 이미 Gemini가 Samsung Gallery를 통해 사진을 가져오는 사례를 포함해 제한적인 통합을 시연했다. Android 17은 프레임워크를 한층 확장한다. 그럼에도 일반적인 Android 사용자는 서드파티 어시스턴트와 호환 가능한 작업으로 채워진 범용 에이전트 대시보드를 찾을 수 없다.

이 간극은 겉보기 모순을 설명한다. 케이지가 문자 그대로 비어 있는 것은 아니지만, 그 안의 구성원은 여전히 적고 통제되며 일반 사용자가 살펴보기 어렵다. Google은 주변 시장을 열기 전에 출입구부터 보안으로 막았다.

Google Android App Functions가 에이전트의 앱 진입 방식을 바꿨다

App Functions는 시뮬레이션된 화면 제어를 Android가 식별하고 제한할 수 있는 선언형·구조화된 작업으로 대체한다.

앱 함수는 애플리케이션이 승인된 호출자에게 제공하는 개별 작업이다. 메모 앱은 “메모 만들기”를 공개할 수 있고, 미디어 앱은 “노래 재생”을 공개할 수 있다. 에이전트는 앱의 시각적 인터페이스를 탐색하는 대신 구조화된 매개변수를 전송한다.

공식 App Functions framework는 두 당사자를 설명한다. 제공자 앱은 작업을 선언하고, 신뢰할 수 있는 에이전트는 이를 발견해 실행한다. Android는 AppFunctionManager 및 관련 서비스를 통해 이 교환을 중개한다.

이 아키텍처가 중요한 이유는 시각적 인터페이스가 인간의 판단을 위해 설계됐기 때문이다. 사람은 버튼이 이동했는지, 수신자가 잘못됐는지, 구매 총액이 바뀌었는지를 알아차린다. 자동화 시스템은 화면을 잘못 읽거나 표시된 콘텐츠에 삽입된 악의적 지시를 따른 뒤에도 계속 진행할 수 있다.

구조화된 함수는 가능한 행동의 범위를 좁힌다. 에이전트는 앱에 한 가지 작업을 요청할 수 있다는 이유만으로 무제한 제어 권한을 얻지 않는다. 제공자는 함수와 입력값, 반환 결과를 정의한다.

Android는 함수가 활성화됐는지도 추적한다. 함수가 존재하지 않거나, 찾을 수 없거나, 사용할 수 없는 경우 실행 요청은 실패할 수 있다. 이는 에이전트에 애플리케이션 인터페이스 전반의 접근 권한을 부여하는 방식보다 더 명확한 경계를 만든다.

이 프레임워크는 Android 16과 연결된 버전인 API 수준 36에서 플랫폼에 도입됐다. Google 문서는 계속해서 App Functions를 베타 또는 실험적 프리뷰로 설명하고 있다. Android 17은 런타임 등록, 활동 범위 함수, 업데이트된 접근 수준, 더 세부적인 검색 제어 기능을 추가한다.

이러한 변화는 Google이 앱 간 에이전트 기능을 운영체제 차원의 과제로 다루고 있음을 보여준다. 모든 어시스턴트 개발자가 각자 비공개 통합 계층을 발명하도록 맡기지 않는다. 플랫폼은 공통 식별자, 메타데이터, 상태 관리, 요청, 응답, 권한 검사를 제공한다.

간단한 메모 작성 시나리오를 보면 그 차이가 더 분명해진다. 에이전트는 “여행 메모에 호텔 주소를 저장해 줘”라는 지시를 받는다. 호환되는 함수를 검색하고, 대상 앱을 식별하며, 제목과 내용을 제공한 뒤 결과를 받는다.

반면 화면 조작 에이전트는 앱을 열고, 버튼을 찾고, 노트북을 선택하고, 텍스트 필드에 포커스를 맞추고, 내용을 입력한 뒤 저장을 눌러야 한다. 시각적 전환 단계마다 모호성이나 조작이 개입될 여지가 추가된다.

App Functions가 에이전트가 원래 요청을 정확히 이해했음을 보장하는 것은 아니다. 앱이 작업을 안전하게 구현했음을 증명하는 것도 아니다. 다만 개방형 인터페이스 여정을 개발자가 명시적으로 선언한 작업으로 대체해 공격 표면을 줄인다.

이것이 첫 번째 중요한 변화다. 이제 Android에는 에이전트가 애플리케이션 안에서 행동하기 위한 네이티브 어휘가 있으며, 단순히 해당 애플리케이션을 언급하거나 화면을 실행하는 수준에 머물지 않는다.

두 번째 변화는 덜 눈에 띈다. Android는 일반 애플리케이션이 단순히 전제할 수 없는 권한 뒤에 앱 간 실행을 배치한다. 이 결정은 App Functions를 편의성 API가 아니라 게이트키핑 시스템으로 만든다.

권한 모델은 Google과 기기 제조사에 통제권을 부여한다

보안상의 이점은 강력한 호출자를 제한하는 데서 나오지만, 같은 제약은 독립 Android 에이전트를 관문 밖에 남겨 둔다.

애플리케이션은 특별한 권한 없이 자체 함수를 실행할 수 있다. 패키지 간 실행은 다르다. AppFunctionManager는 호출 에이전트가 다른 앱의 함수를 검색하거나 실행하도록 승인된 Android 권한을 보유해야 한다.

초기 Android 프레임워크 작업은 어시스턴트 역할을 보유한 사전 설치 또는 시스템 애플리케이션에 EXECUTE_APP_FUNCTIONS를 할당했다. 관련 신뢰 권한은 엄격히 통제되는 시스템 인텔리전스 구성요소에 사용됐다. permission history는 Android가 에이전트 실행을 특권 역할과 얼마나 명시적으로 연결했는지 보여준다.

현재 프레임워크는 더 세분화된 접근 수준을 향해 발전하고 있다. 개발자는 앱 자체, 시스템 호출자 또는 Android가 인증한 호출자를 위해 함수를 표시할 수 있다. 그러나 인증은 다운로드한 어떤 어시스턴트든 프롬프트를 표시한 뒤 받을 수 있는 일반적인 런타임 권한과는 다르다.

이 차이는 일반 휴대전화에서 이 기능이 부재한 것처럼 느껴지는 이유를 설명한다. 사용자는 카메라, 마이크, 연락처, 위치 접근을 승인하는 데 익숙하다. 하지만 임의의 어시스턴트를 설치한 뒤 일반 설정 화면에서 광범위한 App Functions 권한을 부여할 수 있는 것은 아니다.

Google은 위험한 최저 수준 경쟁을 막고 있다. 하나의 모호한 동의 프롬프트 이후 어떤 애플리케이션이든 공개된 모든 함수를 호출할 수 있다면, 공격적인 어시스턴트는 광범위한 권한을 추구할 것이다. 사용자는 얼마나 많은 중요한 작업이 가능해지는지 이해하지 못한 채 이를 승인할 수 있다.

앱 간 에이전트는 수동적 챗봇과 다른 위험을 수반한다. 잘못된 답변은 불편할 뿐이다. 잘못된 행동은 엉뚱한 사람에게 메시지를 보내고, 비공개 문서를 공개하고, 기록을 수정하거나, 거래를 시작할 수 있다.

프롬프트 인젝션은 이 차이를 더욱 뚜렷하게 만든다. 에이전트는 웹페이지, 메시지, 문서 또는 이미지를 읽는 동안 사용자의 의도를 덮어쓰도록 설계된 텍스트를 접할 수 있다. 최근 mobile-agent research는 Android 접근성 기반 에이전트가 간접 프롬프트 인젝션에 어떻게 노출될 수 있는지를 구체적으로 살펴본다.

권한 경계가 모델을 조작에 면역되게 할 수는 없다. 하지만 어떤 애플리케이션이 에이전트로 행동할 수 있는지, 그 에이전트가 어떤 함수에 도달할 수 있는지는 제한할 수 있다. 또한 제공자 앱에 인수를 검증하고 자체 검사를 적용할 수 있는 명확한 실행 경로를 제공한다.

그러나 중앙집중적 통제는 또 다른 문제를 만든다. Google과 Android 기기 제조사는 어떤 어시스턴트가 일류 접근 권한을 받을지를 사실상 결정하는 주체가 된다. 독립 에이전트는 정교한 계획 도구를 구축해도 공식 프레임워크를 통해 서드파티 앱을 오케스트레이션할 권한이 없을 수 있다.

이 압력은 세 그룹에 가해진다.

첫째, 어시스턴트 개발자는 Android의 신뢰 경로에 적격 판정을 받거나 덜 직접적인 기술에 의존해야 한다. 애플리케이션으로 딥링크를 연결하고, 기존 인텐트를 사용하며, 접근성 서비스를 통해 동작하거나, 개발 도구로 상호작용을 시뮬레이션할 수 있다. 어느 방식도 동일한 표준화된 접근을 제공하지 않는다.

둘째, 애플리케이션 개발자는 어떤 함수를 공개할 가치가 있는지 결정해야 한다. 모든 함수에는 구현, 테스트, 입력 검증, 수명 주기 처리, 호환성 작업이 필요하다. 소규모 앱 팀은 그러한 함수를 호출할 수 있는 에이전트를 보유한 사용자가 충분히 늘어날 때까지 주저할 수 있다.

셋째, 사용자는 거래의 양측을 모두 신뢰해야 한다. 어시스턴트가 요청을 정확히 해석했으며 제공자 앱이 예상보다 광범위한 작업을 실행하지 않을 것이라는 확신이 필요하다.

이는 익숙한 플랫폼 콜드 스타트를 만든다. 에이전트는 사용량을 끌어들이기 전에 유용한 함수가 필요하다. 앱 개발자는 통합에 엔지니어링 시간을 투자하기 전에 활성 에이전트가 필요하다. Google은 Gemini와 주요 파트너를 통해 이 순환을 끊을 수 있지만, 독립 참여자는 여전히 접근 정책에 의존한다.

따라서 이 설계는 보안 케이지이자 배포 관문이다. 실행을 제한하면 즉각적인 악용은 줄어들지만, 인증과 플랫폼 특권은 누가 의미 있는 Android 자동화를 구축할 수 있는지를 결정한다.

Google의 안전 우선 설계는 도입 문제와 충돌한다

핵심 트레이드오프는 단순하다. 더 엄격한 통제는 Android 에이전트의 배포 안전성을 높이는 반면, 더 느린 접근은 현재 프레임워크의 유용성을 낮춘다.

Google은 2026년 2월 App Functions를 잘 알려지지 않은 API 참조 문서 수준에서 공개적으로 끌어올렸다. Android 개발팀은 이 기능을 초기 단계라고 부르며 개인정보 보호와 보안을 기반 설계 원칙으로 설명했다.

회사는 구체적인 배포 사례도 제시했다. Gemini는 요청을 해석하고 Samsung Gallery의 App Function을 트리거한 뒤 Gemini 인터페이스 안에서 선택한 사진을 반환할 수 있었다. Samsung integration에 따르면, 이 경험은 Galaxy S26 시리즈에서 시작됐으며 더 많은 Samsung 기기로의 확장이 계획돼 있다.

이 사례는 프레임워크가 비어 있는 코드 껍데기가 아님을 증명한다. 동시에 출시 범위가 얼마나 제한적인지도 드러낸다. 시연에는 Google의 어시스턴트, 주요 Android 제조사, 퍼스트파티 갤러리 애플리케이션, 그리고 일부 기기가 포함된다.

광범위한 생태계는 다른 모습일 것이다. 사용자는 적격 에이전트 중에서 선택할 수 있다. 수천 개의 애플리케이션이 문서화된 작업을 공개할 것이다. Android는 어떤 에이전트가 어떤 함수를 호출했는지, 어떤 데이터가 이동했는지, 어떤 작업에 확인이 필요한지를 보여줄 것이다.

기존 프레임워크는 그 미래의 몇 가지 요소를 제공하지만, 완전한 공개 사용자 경험은 제공하지 않는다. 개발자는 메타데이터를 정의하고, 함수를 게시하며, 상태를 관찰하고, 실행 요청을 처리할 수 있다. Android 17은 더 동적인 등록과 활동별 동작도 도입한다.

Google의 Android 17 update에는 개발용 테스트 에이전트 애플리케이션과 ADB 명령어가 포함된다. ADB(Android Debug Bridge)는 기기를 제어하고 검사하기 위한 개발자 인터페이스다. 이러한 도구는 소비자 에이전트가 널리 지원하기 전에 프로그래머가 함수를 검증하는 데 도움을 준다.

테스트 지원은 필요하지만 도입과 같지는 않다. 개발자는 실제로 얼마나 많은 어시스턴트가 이를 호출할지 알지 못한 채 “메모 만들기”가 예상한 응답을 반환하는지 증명할 수 있다. 호환되는 함수는 수백만 대의 기기에서 비활성 상태로 남을 수 있다.

이 프레임워크에는 공유 스키마도 필요합니다. 두 개의 노트 앱이 유사한 작업을 서로 다른 이름, 인수, 결과 형식으로 노출할 수 있습니다. 제공업체마다 자체 계약을 만든다면, 에이전트는 점점 늘어나는 독점 인터페이스를 이해해야 합니다.

표준 스키마를 사용하면 에이전트는 각 애플리케이션을 외우는 대신 기능을 기준으로 검색할 수 있습니다. Android의 메타데이터 모델은 스키마 정보를 지원하지만, 실질적인 상호운용성은 여전히 개발자들이 일관된 정의에 수렴하는지에 달려 있습니다.

사용자 제어는 또 다른 미해결 계층을 제시합니다. 앱은 기능의 활성화 상태를 유지할 수 있고, 최신 메타데이터는 다양한 접근 수준을 표현할 수 있습니다. 그러나 일반 사용자는 실질적인 질문에 답할 수 있는 이해하기 쉬운 모델이 필요합니다.

Gemini는 메모를 만들 수는 있지만 삭제할 수는 없는가? 다른 인증 에이전트는 사진을 외부에 공유하지 않고 검색할 수 있는가? 승인은 한 번만 적용되는가, 앱별인가, 기능별인가, 민감한 요청별인가? 문제가 발생한 후 사용자가 작업 이력을 검토할 수 있는가?

Google은 이러한 제어와 사용 마찰의 균형을 맞춰야 합니다. 무해한 모든 작업을 확인하게 하면 에이전트의 편의성이 사라집니다. 광범위한 범주를 승인하면 위험이 감춰질 수 있습니다. 유용한 시스템은 일상적인 작업은 빠르게 진행하면서도 되돌릴 수 없거나 민감한 단계 전에 멈춰야 합니다.

이 문제는 권한 설계와 유사하지만, 작업 도중 에이전트의 의도가 바뀝니다. 카메라 권한은 알려진 센서에 대한 접근을 부여합니다. 에이전트는 목록을 읽는 것으로 시작해 여러 하위 작업을 추론하고, 여러 앱을 참조한 뒤 구매를 제안할 수 있습니다. 중요한 경계는 워크플로 중간에 나타납니다.

따라서 단일 권한보다 정책이 더 중요합니다. Android는 호출자 신원, 기능 범위, 제공업체 규칙, 사용자 환경설정, 거래 민감도, 현재 맥락을 결합해야 합니다.

우리 비유는 이 설계의 일부만 포착합니다. Android는 신뢰할 수 없는 하나의 프로세스를 상자 안에 격리하는 것이 아닙니다. 각 애플리케이션이 자신의 문 뒤에서 일어나는 일에 대한 책임을 유지한 채, 좁게 노출된 문을 통해 신뢰된 호출자를 조율하고 있습니다.

개발자에게 당장의 판단은 여전히 불확실합니다. Google Android App Functions를 지원하면 앱은 미래 에이전트 워크플로에 참여할 수 있습니다. 동시에 배포, 인증, 사용자 수요가 아직 형성 중인 베타 인터페이스에 투자해야 한다는 의미이기도 합니다.

화면 조작 에이전트는 출시가 빠르지만 신뢰하기 어렵다

Google의 주된 경쟁자는 다른 모바일 플랫폼이 아니라, 에이전트가 사람처럼 화면을 조작하도록 하는 지름길입니다.

화면 조작 에이전트는 더 적은 파트너십으로 시작할 수 있습니다. 픽셀이나 접근성 트리를 읽고, 상호작용할 위치를 판단하며, 탭·스와이프·텍스트 입력을 생성합니다. 사람이 인터페이스를 통해 작업을 완료할 수 있다면, 에이전트도 같은 경로를 시도할 수 있습니다.

이러한 범용성은 매력적입니다. 개발자는 모든 대상 애플리케이션이 기능을 공개하도록 만들 필요가 없습니다. 연구자는 기존 소프트웨어 전반에서 에이전트를 시험할 수 있고, 스타트업은 통합을 협상하기 전에 광범위한 지원 범위를 시연할 수 있습니다.

Google 자체의 Android 연구는 이 접근법을 정립하는 데 기여했습니다. Android in the Wild 데이터세트는 여러 Android 버전과 기기 유형에 걸쳐 30,000개의 지시를 포함한 715,000개의 에피소드로 구성됩니다. 이는 다양한 인터페이스를 통해 작동하는 시스템을 학습하거나 평가하는 데 필요한 규모를 보여줍니다.

그러나 광범위한 시각적 제어는 명시적인 계약을 추론으로 대체합니다. 에이전트는 각 화면의 의미, 콘텐츠의 신뢰성, 상호작용이 의도한 결과를 만들었는지를 판단해야 합니다.

앱 업데이트 후 버튼 라벨이 바뀔 수 있습니다. 대화 상자가 예상한 대상을 가릴 수 있습니다. 악성 페이지는 모델이 읽을 위치에 지시를 배치할 수 있습니다. 결제 흐름은 최종 확인 전에 수수료를 추가하거나 상품을 변경할 수 있습니다.

사람도 이런 상황에서 실수하지만, 에이전트는 이를 더 빠르고 더 큰 규모로 반복할 수 있습니다. 에이전트는 백그라운드에서 작동하고, 애플리케이션을 넘나들며 계속 진행하며, 사용자가 직접 검토하지 않는 정보를 처리할 수 있습니다.

App Functions는 해석을 다른 계층으로 옮깁니다. 에이전트는 여전히 사용자의 요청을 해석하지만, 각 화면의 작동 방식을 추론할 필요는 없습니다. 선언된 작업을 선택하고 형식이 지정된 정보를 제공합니다.

이는 애플리케이션 프로그래밍 인터페이스를 사용하는 방식과 브라우저를 통해 웹사이트를 자동화하는 방식의 차이와 유사합니다. API는 보통 더 높은 안정성과 더 명확한 입력을 제공합니다. 브라우저 자동화는 API가 없는 서비스에도 도달할 수 있지만, 레이아웃, 세션, 콘텐츠의 변화를 처리해야 합니다.

구조화된 경로는 책임 추적도 개선합니다. Android는 호출 패키지, 대상 기능, 요청, 결과를 식별할 수 있습니다. 제공업체 앱은 잘못된 인수를 거부하거나 자체 확인 절차를 요구할 수 있습니다. 플랫폼 정책은 민감한 기능을 일반 기능과 다르게 다룰 수 있습니다.

이 중 어느 것도 모델 수준의 방어 필요성을 없애지는 않습니다. 침해된 에이전트는 잘못된 이유로 허용된 기능을 호출할 수 있습니다. 부주의한 제공업체는 검증이 약한 작업을 노출할 수 있습니다. 신뢰된 호출자도 모호한 지시를 오해할 수 있습니다.

구조화된 작업은 유해한 행동의 신뢰성도 높일 수 있습니다. “send payment” 기능에 도달한 악성 에이전트는 혼란스러운 인터페이스를 탐색할 필요가 없습니다. 보안 가치는 접근을 제한하고, 의도를 확인하며, 적절한 순간에 확인 절차를 요구하는지에 달려 있습니다.

그렇기 때문에 EXECUTE_APP_FUNCTIONS를 지나치게 폭넓게 열면 아키텍처적 이점의 상당 부분이 사라집니다. Google은 단순히 표준 대화 상자에 권한을 배치하고 문제가 해결됐다고 볼 수 없습니다. 플랫폼에는 사용자가 이해할 수 있는 자격 규칙과 관찰 가능한 행동이 필요합니다.

동시에 접근을 제한하면 화면 자동화를 사용하려는 압력이 생깁니다. 독립적인 어시스턴트는 출시할 수 있는 경로를 따를 것입니다. 공식적인 문이 계속 닫혀 있다면, 일부 개발자는 접근성 서비스, ADB 기반 도구, 기기 자동화로 돌아갈 것입니다.

그 결과는 정책의 역설입니다. Google은 에이전트가 더 안전한 구조화 경로를 사용하기를 원하지만, 더 위험한 대안을 대체할 수 있을 만큼 그 경로를 접근 가능하게 만들어야 합니다.

경쟁사와 오픈 소스 프로젝트는 기존 앱 전반에서 더 유능해 보이는 에이전트를 제공하며 이 격차를 활용할 수 있습니다. 제공업체 통합을 기다리지 않기 때문에 데모에서 더 많은 작업을 다룰 수 있습니다. Google의 시스템은 경계를 강제하기 때문에 오히려 제약적으로 보일 수 있습니다.

소비자는 API 문서를 통해 이러한 아키텍처를 평가하지 않을 것입니다. 에이전트가 요청을 완료할 수 있는지를 보게 됩니다. 화면 조작 경쟁 제품이 열 개의 앱을 처리하는 반면 Gemini의 구조화 경로가 두 개만 지원한다면, 구매 결정에서는 추상적인 안전성보다 기능이 더 중요할 수 있습니다.

개발자는 AI workflows를 설계할 때도 같은 긴장에 직면합니다. 신뢰할 수 있는 자동화는 예측 가능한 입력, 통제된 작업, 눈에 보이는 검토 지점에 달려 있습니다. 범용 인터페이스 제어는 도달 범위를 제공하는 반면, 구조화된 기능은 더 명확한 보장을 제공합니다.

Google은 Android 에이전트를 제한 없는 원격 제어 장치로 바꾸지 않으면서 이 기능 격차를 좁혀야 합니다. App Functions는 그 메커니즘을 제공하지만, 개발자가 실제로 이를 사용할지는 도입과 접근 정책에 달려 있습니다.

진짜 시험대는 그 우리가 마켓플레이스가 되는지 여부다

다음 단계는 더 많은 프레임워크 클래스가 아니라 앱 참여, 에이전트 접근, 사용자에게 보이는 제어에 달려 있습니다.

첫 번째로 살펴볼 신호는 App Functions를 노출하는 실제 운영 애플리케이션의 수와 다양성입니다. Samsung Gallery는 사진 검색이 개인 데이터를 포함하고 사용자가 쉽게 이해할 수 있는 작업이기 때문에 유용한 시연 사례입니다. 그러나 이것만으로는 커뮤니케이션, 생산성, 금융, 쇼핑, 여행, 미디어 전반의 폭넓은 지원을 입증하지 못합니다.

주요 애플리케이션은 홍보용 데모 작업 이상의 기능을 공개해야 합니다. 반복적이고 실용적인 워크플로는 이 프레임워크가 사용자에게 의미 있는 노력을 절감하는지 보여줄 것입니다. 메모 만들기, 특정 사진 찾기, 재생목록 시작하기, 장바구니에 상품 추가하기는 초기 시험 사례입니다.

여러 독립 앱 개발자가 작동하는 통합을 발표한다면 도입은 Google의 접근법을 강화합니다. 지원이 Google 소프트웨어, 기기 제조사 앱, 선정된 출시 파트너에 집중된다면 그 주장은 약화됩니다.

두 번째 신호는 Google 이외 에이전트의 접근입니다. Android의 최신 메타데이터는 Android가 인증한 호출자를 언급하며, 하나의 퍼스트파티 어시스턴트보다 넓은 경로를 시사합니다. 결정적인 질문은 인증 요건이 무엇인지, 자격을 갖춘 서드파티 에이전트가 합리적인 조건에서 경쟁할 수 있는지입니다.

신뢰할 수 있는 프로그램에는 공개된 기준, 보안 의무, 권한 철회 절차, 예측 가능한 심사가 필요합니다. 개발자는 에이전트가 어떻게 접근 권한을 얻고 어떤 행동으로 그 접근 권한을 잃는지 알아야 합니다.

이런 세부 사항이 없다면 권한 시스템은 Gemini를 위한 비공개 배포 우위가 될 위험이 있습니다. Google은 엄격한 접근이 사용자를 보호한다고 주장할 수 있고, 경쟁사는 같은 규칙이 Android의 기본 에이전트로서 Google의 지위를 보호한다고 주장할 수 있습니다.

여러 인증 에이전트가 존재한다는 증거는 보안 우선 해석을 강화할 것입니다. 지속적인 퍼스트파티 독점은 게이트키핑 해석을 강화할 것입니다. 프레임워크의 정당성은 신뢰 요건과 특혜 접근을 구분하는 데 달려 있습니다.

세 번째 신호는 사용자 대면 제어 및 감사 경험입니다. Google의 더 광범위한 Gemini Intelligence rollout은 휴대전화와 기타 기기 전반의 선제적 자동화를 약속합니다. 백그라운드 작업이 늘어날수록 가시성은 더욱 중요해집니다.

사용자는 어떤 기능이 존재하는지, 어떤 에이전트가 이를 호출할 수 있는지, 어떤 권한이 활성 상태로 남아 있는지를 확인해야 합니다. 또한 에이전트가 무엇을 요청했고 각 애플리케이션이 무엇을 반환했는지 설명하는 이력이 필요합니다.

유용한 제어 화면은 저위험 편의성과 중대한 권한을 구분해야 합니다. 노래 재생은 메시지 전송이나 주문 제출과 같은 수준의 마찰을 요구하지 않습니다. 플랫폼은 오류가 발생하기 전에 그 차이를 전달해야 합니다.

확인 설계는 가장 어려운 부분이 될 것입니다. 프롬프트가 너무 많으면 사용자는 모든 것을 승인하게 됩니다. 프롬프트가 너무 적으면 사용자는 의도하지 않은 작업에 놀라게 됩니다. 맥락에 따른 승인은 모든 워크플로를 중단의 연속으로 만들지 않으면서도 명확하게 유지되어야 합니다.

Google은 처리 위치도 설명해야 합니다. 일부 기능은 로컬 애플리케이션 상태를 바탕으로 실행될 수 있는 반면, 어시스턴트의 추론에는 클라우드 서비스가 관여할 수 있습니다. 사용자는 언제 자신의 데이터가 기기를 떠나는지, 어느 주체가 이를 받는지 이해해야 합니다.

프레임워크의 상태 제어는 긴급 권한 철회를 지원할 수 있습니다. 에이전트가 예상치 못하게 행동하면 사용자는 개별 애플리케이션을 일일이 찾지 않고도 앱 간 권한을 비활성화할 수 있어야 합니다. 제공업체 앱 역시 민감한 기능을 신속하게 중단할 수 있어야 합니다.

개발자는 운영 도구도 기대할 것입니다. 실패한 호출을 위한 로그, 스키마 검증, 호환성 테스트, 악용 신고, Android 버전 전반에서 명확한 동작이 필요합니다. 팀이 실제 운영 환경에서 이를 지원할 수 있을 때에야 프레임워크는 생태계가 됩니다.

Google의 단계적 출시는 타당합니다. 제어 장치가 마련되기 전에 제한 없는 앱 간 에이전트 기능을 출시하면 예측 가능한 실패를 초래할 것입니다. 대신 이 회사는 범용 접근을 활성화하기 전에 권한 검사, 제공업체 계약, 테스트 도구, 확장되는 플랫폼 API를 구축했습니다.

회의적인 시각도 마찬가지로 타당합니다. 호출 가능한 기능이 거의 없는 보안 프레임워크는 소비자에게 큰 가치를 제공하지 못합니다. 엄격하게 통제된 경로는 독립 개발자를 이 프레임워크가 대체하려던 바로 그 화면 자동화로 밀어낼 수도 있습니다.

따라서 Google Android App Functions는 중요하지만 아직 완성되지 않은 전환점에 놓여 있다. Android는 이제 에이전트가 범위가 제한된 작업을 발견하고 실행할 수 있는 네이티브 메커니즘을 갖췄다. 하지만 이 메커니즘이 개방적이고 경쟁적이며 폭넓게 채택되는 에이전트 시장을 뒷받침할 수 있는지는 아직 입증되지 않았다.

향후 몇 달 동안은 출시 파트너를 넘어선 프로덕션 통합, 외부 에이전트를 위한 공개 접근 규칙, 그리고 사용자가 확인할 수 있는 권한 이력을 주시할 필요가 있다. 이러한 신호는 Google이 공동 인프라를 구축한 것인지, 아니면 Gemini를 위한 보호된 전용 경로를 만든 것인지를 보여줄 것이다.

Android 소유자에게 실질적인 질문은 AI 에이전트가 화면을 탭할 수 있느냐가 아니다. 실험적 시스템은 이미 그것이 가능하다는 점을 보여줬다. 핵심은 Android가 사용자가 의미 있는 통제권을 포기하지 않고도 에이전트가 개인 앱 전반에서 행동하도록 허용할 수 있느냐다.

개발자에게는 더 이른 시점에 결정이 다가온다. 구조화된 방식으로 노출할 가치가 있는 안전하고 유용한 작업을 식별하고, 어디에 확인 절차를 둘지 정의해야 한다. 기다리면 단기적인 작업은 피할 수 있지만, 사용자가 인터페이스를 직접 여는 대신 작업을 위임하기 시작할 때 앱이 보이지 않게 될 수 있다.

Google은 출입구를 만들고 자물쇠를 설치했다. 이제 신뢰할 수 있는 에이전트, 독립 개발자, 일반 사용자가 모두 올바른 열쇠를 받을 수 있음을 증명해야 한다.