Android AI 상호운용성: 앱이 AI 어시스턴트와 연동되기 전 확인해야 할 7가지 데이터 액세스 점검 사항

AI 어시스턴트(AI assistants)가 운영체제(operating system)에 더욱 밀접하게 다가오고 있습니다.

이는 앱 팀의 개인정보 보호 결정 방식을 변화시킵니다.

이제는 단순히 앱이 무엇을 저장하는지, 백엔드(backend)가 무엇을 처리하는지, 또는 자체 AI 기능이 무엇에 접근할 수 있는지에 대한 문제만이 아닙니다. 다음 질문은 다른 AI 어시스턴트가 귀하의 앱이 기기에서 제공하는 데이터를 검색, 검색(retrieve), 해석 또는 실행할 수 있게 될 때 어떤 일이 발생하는가입니다.

이것이 바로 유럽 위원회(European Commission)가 2026년 7월 Google에 전달한 DMA 지침 뒤에 숨겨진 유용한 신호입니다.

위원회의 Android AI 조치는 Google이 AI 서비스와 관련된 특정 Android 기능에 대해 효과적인 상호운용성(interoperability)을 제공하도록 요구합니다. 이 조치는 문맥적 호출(contextual invocation), 온디바이스(on-device) 앱 데이터에 대한 중앙 집중식 액세스, 문맥 인식 지능(context-aware intelligence), 구조화된 앱 액션(structured app actions), 온디바이스 모델 액세스, 그리고 백그라운드 실행(background execution)과 같은 영역을 다룹니다.

단순하게 말하자면, 경쟁 관계에 있는 AI 어시스턴트들이 공정하게 경쟁하기 위해 더 깊은 Android 액세스 권한이 필요할 수도 있다는 뜻입니다.

소프트웨어 팀에게 실질적인 질문은 이것입니다:

AI 어시스턴트가 기기 내부로 더 깊숙이 접근할 수 있다면, 귀하의 앱은 무엇을 의도적으로 공유하고, 보호하며, 사용자에게 설명해야 할까요?

무엇이 변했는가

2026년 7월 16일, 유럽 위원회는 Google Android AI 상호운용성 및 Google 검색 데이터 공유와 관련된 디지털 시장법(Digital Markets Act)에 따른 지침을 발표했습니다.

Android 결정은 Google 자체 AI 서비스가 사용할 수 있는 Android 기능에 대해 제3자 AI 서비스가 어떻게 효과적인 상호운용성을 제공받아야 하는지에 초점을 맞추고 있습니다.

위원회가 발표한 조치에는 다음과 같은 여러 카테고리가 포함됩니다:

문맥적 실행(contextual launch) 및 핫워드(hotword) 관련 액세스와 같은 호출(invocation) 기능,
기기에 저장된 앱 데이터에 대한 중앙 집중식 액세스,
문맥 인식 지능(context-aware intelligence),
구조화된 온디바이스 통합(structured on-device integrations),
시스템 수준의 온디바이스 모델(system-level on-device models),
온디바이스 모델 작동을 위한 하드웨어 리소스,
그리고 백그라운드 실행(background execution).

한 가지 중요한 섹션은 기기(on-device)에 저장된 앱 데이터에 대한 중앙 집중식 액세스(centralised access)를 다룹니다. 이 조치는 앱이 중앙 집중식 방식으로 공유하기로 선택한 데이터에 대한 액세스를 의미하며, 이를 통해 앱 간 검색 및 검색(cross-app search and retrieval)이 가능해집니다.

이 문구가 중요합니다:

앱이 공유하기로 선택한 데이터.

이 지점이 바로 제품 팀이 거버넌스(governance) 논의에 참여해야 하는 곳입니다.

이것이 앱 및 SaaS 팀에게 중요한 이유

많은 소프트웨어 제품은 이미 모바일 앱, 웹 대시보드, 백엔드 API (backend APIs), 알림 (notifications), 지원 워크플로 (support workflows), 그리고 AI 기능에 걸쳐 존재합니다.

AI 어시스턴트가 운영체제(operating system)에 더 통합됨에 따라, 사용자들은 해당 어시스턴트가 정보를 찾거나, 활동을 요약하거나, 동작을 트리거(trigger)하거나, 앱 간을 이동하는 것을 도와주기를 기대할 수 있습니다.

이는 유용할 수 있습니다.

하지만 다음과 같은 질문들도 제기합니다:

어떤 앱 데이터가 어시스턴트에 의해 검색 가능해야 하는가?
어떤 데이터가 앱 내부에 머물러야 하는가?
어시스턴트가 어떤 동작을 트리거할 수 있는가?
무엇이 앱 UI (app UI)를 필요로 해야 하는가?
사용자가 무엇이 공유되고 있는지 어떻게 알 수 있는가?
여러 어시스턴트가 유사한 액세스를 요청할 때 어떤 일이 발생하는가?
사용자가 나중에 공유 수준을 변경할 수 있는가?

이것들은 단순한 기술적 권한(technical permissions)의 문제가 아닙니다.

이것은 제품 거버넌스(product governance) 결정입니다.

데이터 액세스 문제

제품은 다음과 같은 다양한 종류의 데이터를 보유할 수 있습니다:

공개 콘텐츠 (public content),
사용자가 생성한 노트 (user-created notes),
개인 메시지 (private messages),
고객 기록 (customer records),
금융 정보 (financial information),
건강 정보 (health information),
내부 비즈니스 데이터 (internal business data),
알림 (notifications),
위치 신호 (location signals),
저장된 설정 (saved preferences),
작업 이력 (task history),
그리고 지원 상호작용 (support interactions).

모든 데이터가 동일한 공유 모델에 속하는 것은 아닙니다.

어떤 정보는 AI 지원 검색(AI-assisted search)에 안전하고 유용할 수 있습니다.

어떤 정보는 명시적인 사용자 동작이 있을 때만 유용할 수 있습니다.

어떤 정보는 신중하게 설계된 흐름(flows)을 통하지 않고서는 절대로 제품 경계(product boundary)를 벗어나서는 안 됩니다.

실수는 앱 데이터를 하나의 카테고리로 취급하는 것입니다.

그렇지 않습니다.

7가지 체크리스트 Android AI 상호운용성 검토

1. 데이터 카테고리 (Data category)

앱이 기기에 무엇을 저장하는지 분류하는 것부터 시작하세요.

분리하십시오:

공개 콘텐츠 (public content),
사용자 소유 콘텐츠 (user-owned content),
계정 데이터 (account data),
민감한 기록 (sensitive records),
트랜잭션 데이터 (transactional data),
알림 (notifications),
설정 (settings),
그리고 비즈니스 또는 워크스페이스에 속한 데이터.

목표는 제품 팀의 속도를 늦추는 것이 아닙니다.

목표는 하나의 광범위한 통합 경로를 통해 서로 다른 데이터 유형이 노출되는 것을 방지하는 것입니다.

검토 질문:
어시스턴트가 발견하거나 검색할 수 있는 데이터의 종류는 무엇인가요?

2. 사용자 의도 (User intent)

AI 어시스턴트의 액세스는 기술적 가용성뿐만 아니라 사용자 의도(user intent)를 따라야 합니다.

예를 들어, 사용자는 어시스턴트가 문서 제목은 찾기를 원할 수 있지만, 문서의 모든 내용을 읽는 것은 원하지 않을 수 있습니다. 사용자는 캘린더 요약을 원할 수 있지만, 개인적인 메모가 노출되는 것은 원하지 않을 수 있습니다. 사용자는 동작 바로가기(action shortcut)를 원할 수 있지만, 백그라운드 변경을 허용하는 것은 원하지 않을 수 있습니다.

팀은 어떤 액세스에 다음이 필요한지 결정해야 합니다:

사용자 선택 동의 (user opt-in),
즉각적인 확인 (in-the-moment confirmation),
앱 수준 권한 (app-level permission),
워크스페이스 관리자 승인 (workspace admin approval),
또는 공유를 전혀 하지 않음.

검토 질문:
사용자가 이러한 데이터 공유 동작을 명확하게 선택했습니까?

3. 동작 경계 (Action boundary)

검색(Search)과 동작(Action)은 다릅니다.

어시스턴트가 정보를 찾도록 허용하는 것은 무언가를 변경하도록 허용하는 것과 같지 않습니다.

제품은 다음을 구분해야 합니다:

검색 (search),
검색/추출 (retrieval),
요약 (summarization),
초안 작성 (drafting),
탐색 (navigation),
데이터 업데이트 (data update),
트랜잭션 (transaction),
삭제 (deletion),
제출 (submission),
또는 외부 전송 (external send).

작업 목록을 읽을 수 있는 어시스턴트가 자동으로 작업을 완료하거나, 계정 기록을 업데이트하거나, 메시지를 보내거나, 결제 변경을 트리거할 수 있어서는 안 됩니다.

검토 질문:
어시스턴트가 읽기만 할 수 있습니까, 아니면 동작도 할 수 있습니까?

4. 민감한 워크플로우 보호 (Sensitive workflow protection)

특정 워크플로우는 더 강력한 제어를 요구해야 합니다.

예시는 다음과 같습니다:

결제 (billing),
계정 삭제 (account deletion),
권한 변경 (permission changes),
데이터 내보내기 (data export),
고객 기록 업데이트 (customer record updates),
법률 또는 컴플라이언스 콘텐츠 (legal or compliance content),
의료 또는 금융 정보 (medical or financial information),
신원 확인 (identity verification),
그리고 관리자 작업 (admin actions).

어시스턴트가 사용자가 해당 영역에 더 빠르게 도달하도록 도울 수 있더라도, 최종 단계에서는 여전히 앱 소유의 확인(app-owned confirmation)이 필요할 수 있습니다.

검토 질문:
어떤 워크플로 (workflows)가 앱 경험 내부에 유지되어야 합니까?

5. 사용자 가시성 (Visibility to users)

사용자는 외부 AI 서비스가 앱 데이터 (app data)를 사용하거나 앱 작업 (app actions)을 트리거할 수 있다는 점을 이해해야 합니다.

이것이 사용자에게 권한 텍스트를 쏟아부어야 한다는 의미는 아닙니다.

권한을 의미 있게 만드는 것을 의미합니다:

무엇이 공유되는지,
왜 공유되는지,
어떤 어시스턴트가 이를 사용할 수 있는지,
어떤 작업이 허용되는지,
그리고 어떻게 이를 끌 수 있는지.

제품은 사용자가 어시스턴트가 무엇을 볼 수 있는지 추측하게 만들어서는 안 됩니다.

검토 질문:
일반 사용자가 어시스턴트에게 허용된 작업이 무엇인지 이해할 수 있습니까?

6. 철회 및 변경 (Revocation and change)

동의 (Consent) 및 권한 (permissions)은 기본적으로 영구적이지 않아야 합니다.

사용자는 마음을 바꿀 수 있습니다. 회사는 어시스턴트 제공업체를 변경할 수 있습니다. 워크스페이스 관리자 (workspace admin)가 액세스를 제한할 수 있습니다. 규제 (regulation)로 인해 더 엄격한 통제가 필요할 수 있습니다. 기능 (feature)이 변경될 수 있습니다.

팀은 철회 (revocation) 과정을 명확하게 설계해야 합니다:

사용자 수준의 오프 스위치 (user-level off switch),
워크스페이스 수준의 제어 (workspace-level controls),
관리자 정책 (admin policy),
감사 추적 (audit trail),
권한 만료 (permission expiry),
그리고 액세스가 제거되었을 때의 폴백 동작 (fallback behavior).

검토 질문:
제품을 망가뜨리지 않고 액세스를 변경하거나 제거할 수 있습니까?

7. 감사 및 지원 (Audit and support)

AI 어시스턴트가 앱 데이터와 상호작용할 때, 지원 팀 (support teams)은 새로운 질문에 답변해야 할 수도 있습니다.

사용자는 다음과 같이 질문할 수 있습니다:

어시스턴트가 왜 이것을 보여주었나요?
어떤 데이터가 사용되었나요?
어떤 앱이 이를 허용했나요?
작업이 발생했나요?
이를 되돌릴 수 있나요?
다음에는 어떻게 이것을 중단하나요?

팀은 출시 전에 기본적인 감사 추적 (audit trails)과 지원 언어 (support language)를 계획해야 합니다.

검토 질문:
사용자가 어시스턴트의 작업에 대해 의문을 제기할 경우, 팀이 무슨 일이 일어났는지 설명할 수 있습니까?

간단한 구현 모델

실용적인 모델은 앱 데이터와 작업을 네 가지 계층 (tiers)으로 분리하는 것입니다.

계층 1: 안전한 탐색 (Safe discovery)

민감한 콘텐츠를 노출하지 않고도 찾거나 나타낼 수 있는 데이터입니다.

예시:

공개 도움말 페이지 (public help pages),
기능 이름 (feature names),
문서 제목 (document titles),
앱 바로가기 (app shortcuts),
비민감 메타데이터 (non-sensitive metadata).

계층 2: 사용자 승인 검색 (User-approved retrieval)

사용자가 명확하게 요청할 때만 검색될 수 있는 데이터입니다.

예시:

개인 메모 (personal notes),
할 일 목록 (task lists),
저장된 항목 (saved items),
계정별 요약 (account-specific summaries).

계층 3: 앱 확인 작업 (App-confirmed actions)

어시스턴트가 단계를 준비할 수는 있지만, 완료하기 전에 앱의 확인을 거쳐야 하는 작업입니다.

예시:

레코드 업데이트 (updating a record),
메시지 전송 (sending a message),
파일 내보내기 (exporting a file),
설정 변경 (changing a setting).

계층 4: 보호된 워크플로 (Protected workflows)

앱 소유의 제어 기능 뒤에 유지되어야 하는 영역입니다.

예시:

결제 변경 (billing changes),
권한 변경 (permission changes),
계정 삭제 (account deletion),
민감한 데이터 내보내기 (sensitive data exports),
규제 대상 데이터 (regulated data).

이 모델은 어시스턴트의 액세스를 '전부 아니면 전무(all-or-nothing)'로 취급하지 않으면서도 제품의 유용성을 유지합니다.

창업자를 위한 시사점 (Founder takeaway)

AI 상호운용성 (AI interoperability)은 더 나은 사용자 경험을 창출할 수 있습니다.

하지만 어시스턴트의 접근 권한이 깊어질수록 데이터 거버넌스 (data governance)의 중요성도 커집니다.

창업자에게 있어 결정해야 할 사항은 단순히 AI 어시스턴트를 지원할지 여부만이 아닙니다.

그것은 제품이 다음과 같은 질문에 명확히 답할 수 있는지에 대한 문제입니다:

어떤 데이터를 탐색 (discover)할 수 있는가,
어떤 데이터를 검색 (retrieve)할 수 있는가,
어떤 작업 (actions)을 트리거할 수 있는가,
무엇이 확인 (confirmation)을 필요로 하는가,
무엇이 보호 (protected)된 상태로 남는가,
그리고 사용자가 자신의 선택을 어떻게 변경할 수 있는가.

유용한 제품을 만들기 위한 질문은 다음과 같습니다:

어시스턴트가 우리 앱의 데이터를 사용할 수 있는가? 가 아닙니다.

그것은 다음과 같습니다:

사용해야 하는가? 어떤 조건 하에서여야 하는가? 그리고 어떤 사용자 제어 (user control)를 동반해야 하는가?

이 지점이 바로 AI 상호운용성이 제품 거버넌스 (product governance) 결정이 되는 지점입니다.

Insights