앱갈피
Back to Home
iOS Development • 2026년 8월 19일

iOS 27에서 AI가 내 앱을 못 보게 막는 법

#iOS #iOS 27 #App Intents #Apple Intelligence #Siri

궁금했던 것

WWDC26 이후로 iOS 27 자료를 보다 보면 죄다 "앱을 AI에 어떻게 여느냐" 얘기다.

App Intents를 붙여라, App Schemas를 채택해라, 지금 안 하면 늦는다. 그런데 읽다 보니 반대쪽이 궁금해졌다.

AI가 앱을 제어하는 기능을 이렇게 많이 넣었으면, 반대로 "이건 절대 건드리지 마"를 지정하는 기능도 넣었을까?

내 예상은 "안 만들었을 것"이었다.

App Intents는 개발자가 직접 만들어야 동작하니까, 안 만들면 어차피 아무것도 안 된다. 굳이 차단 API를 따로 팔 이유가 없어 보였다.

결론적으로 반은 맞고 반은 틀렸다. 확인한 걸 claude와 함께 정리한다.


AI가 앱을 읽는 경로는 셋이다

먼저 뭘 막아야 하는지부터 알아야 한다. 시스템 AI가 앱 콘텐츠에 닿는 경로는 세 개다.

  1. Spotlight 시맨틱 인덱스 — 엔티티에 IndexedEntity를 채택하고 indexAppEntities(...)로 색인에 넣는다. 로컬에 있는 정적인 콘텐츠용이다.

  2. IntentValueQuery — 서버에 있거나 자주 바뀌는 콘텐츠용. 색인해두는 게 아니라 질의가 들어온 시점에 검색한다.

  3. onscreen awareness — NSUserActivity나 .appEntityIdentifier 뷰 모디파이어로 화면과 엔티티를 매핑한다. "세 번째 거 틀어줘" 같은 말을 해석하는 데 쓰인다.

셋 다 공통점이 있다. 채택해야 작동한다.

Apple 문서 표현도 전부 "adopt"다. 자동으로 빨려 들어가는 게 아니다.

실제 사례도 있다. iOS 27 베타에서 Siri에게 테슬라 차량 상태를 물으면, App Intents를 구현한 서드파티 앱 Tessie는 답을 주는데 테슬라 공식 앱은 못 준다.

같은 계정, 같은 데이터인데 구현 여부만 다르다.


안 만들면 안 보인다 — 근데 그게 전부가 아니었다

여기까지는 내 예상대로였다. 안 만들면 안 보인다. 그리고 개별 인텐트를 숨기고 싶으면 isDiscoverable = false를 주면 Shortcuts와 Spotlight에서 빠진다.
앱 안의 버튼이나 위젯에서만 쓰고 싶을 때 쓰는 물건이다.

그래서 "역시 차단 API 같은 건 안 만들었네"로 끝날 줄 알았는데, 세션 목록을 훑다가
347번 세션이 통째로 그 얘기인 걸 claude가 찾아주었다. 제목이 Secure your app: mitigate risks to agentic features다.

읽어보니 Apple은 "안 만들면 어차피 안 되니까 됐지"로 끝내지 않았다. 만든 사람들을 위한 방어 장치를 따로 팠다.


실행은 막을 수 있다

세션 347이 상정하는 공격은 구체적이다. 요약하면 간접 프롬프트 인젝션이다. 사용자의 캘린더 일정이나 친구 피드처럼 앱이 읽어들이는 외부 데이터에 공격자가 지시문을 심는 방식이다.

사용자는 엄마에게 메시지를 보내려는 건데, 공격자가 자기에게 보내라는 지시를 주입한다. (파라미터 조작)

사용자는 그냥 메일을 요약해달라고 했는데, 공격자가 LLM을 유도해 메일 내용을 붙인 URL로 악성 페이지를 열게 만든다. (액션 조작)

두 번째가 특히 고약하다. 요약해달라는 요청 하나가 데이터 유출이 된다.

막는 수단은 세 가지가 나온다.

.onToolCall — 툴이 돌기 전에 가로챈다

.onToolCall { call in
    guard call.toolName == "orderTeaTool" else { return }
    guard ConfirmationAction.confirmWithUser() else {
        throw LooseLeafError.userConfirmationDenied
    }
}

LLM이 툴 호출을 뱉는 순간, 실행기가 툴을 돌리기 전에 반드시 불린다. 그리고 이 콜백에서 에러를 던지면 툴은 아예 실행되지 않는다. 확인 절차를 넣기에 딱 좋은 자리다.

.historyTransform — 모델에 넘어가기 전에 손본다

트랜스크립트가 모델로 렌더링되기 직전에 불린다. 신뢰할 수 없는 툴 출력에 <<UNTRUSTED>> 같은 델리미터를 씌우거나, 개인정보를 [REDACTED]로 지우는 데 쓴다.

주의할 게 하나 있다. 변환은 현재 추론 회차에만 적용된다. 다음 호출에는 안 남으니 매번 다시 적용해야 한다.

IntentAuthenticationPolicy — 잠긴 기기에서 막는다

struct DeletePhotoIntent: DeleteIntent {
    var entities: [LooseLeafPhoto]
    static var authenticationPolicy: IntentAuthenticationPolicy = .requiresAuthentication
    // ...
}

여기서 제일 인상적이었던 게 있다. 스키마를 채택하면 기본 정책이 딸려오는데, 그걸 더 느슨하게 바꿀 수가 없다.

제약은 하나뿐이다. 당신의 정책은 더 엄격해야 한다.
더 약한 정책을 설정하려 하면 빌드 에러가 나고, 허용되는 최소 정책이 뭔지 친절하게 알려준다.

보안 완화를 컴파일러로 막았다. 런타임 경고도 아니고 문서상 권고도 아니고 빌드 에러다. 이건 좀 Apple답다고 느꼈다.

이건 iOS 27을 기다릴 필요가 없다.

SDK를 확인해보니 인텐트에 정책을 다는 authenticationPolicy 프로퍼티가 iOS 26.0부터고, IntentAuthenticationPolicy 열거형 자체는 App Intents 첫 버전인 iOS 16.0부터 있었다.

그리고 케이스가 셋이다.

public enum IntentAuthenticationPolicy: Sendable {
  case alwaysAllowed
  case requiresAuthentication
  case requiresLocalDeviceAuthentication
}

세 번째 requiresLocalDeviceAuthentication은 세션에서 언급되지 않는데, 이름대로면 원격 기기가 아니라 이 기기에서 직접 인증할 것을 요구한다.

Watch나 다른 기기를 경유한 실행까지 신경 쓴다면 볼 만하다.

세션이 반복해서 강조하는 원칙도 같은 결이다. 확률적인 방어(프롬프트로 잘 타이르기)보다 결정론적인 방어(확인받기, 인증 요구하기, 지우기)를 기본선으로 두라는 것이다. 감사하기 쉽고 추론하기 쉬우니까.


열람 — 세션에는 없는데 SDK에는 있었다

여기서 한 번 헛다리를 짚었다.

위에 나온 건 전부 AI가 뭘 실행하는가에 대한 방어다.

그럼 AI가 뭘 보는가는? 앱은 Siri에 열고 싶은데 이 화면만 빼고 싶다, 이건 어떻게 하나.

세션 343(Explore advanced App Intents features for Siri and Apple Intelligence)을 분석시켰다.

등장하는 API가 전부 노출용이다. NSUserActivity, appEntityIdentifier, appEntityIdentifiers, IndexedEntity. 제외하는 얘기는 안 나온다.

비밀번호나 금융정보 같은 민감한 콘텐츠를 어떻게 다루라는 언급도 없다.

그래서 "열람은 못 막는구나"로 결론 낼 뻔했다.

그런데 세션에 안 나온다는 게 API가 없다는 뜻은 아니다. SDK를 직접 까보게 했다.

SDK를 grep하는 법

Xcode에서 심볼에 Cmd+클릭해도 되지만, 뭐가 있는지 훑을 때는 .swiftinterface 파일을 직접 보는 게 빠르다.

/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/
  Developer/SDKs/iPhoneOS.sdk/System/Library/Frameworks/
  AppIntents.framework/Modules/AppIntents.swiftmodule/arm64e-apple-ios.swiftinterface

그냥 텍스트 파일이다.

iOS 26.5 SDK 기준 11,752줄이고, @available 어노테이션이 그대로 붙어 있어서 어느 버전부터 쓸 수 있는지도 바로 나온다.

문서 페이지가 자바스크립트로 렌더링돼서 검색이 잘 안 될 때 특히 쓸모 있다.

여기서 exclude, hidden, redact 같은 단어로 훑었더니 하나가 걸렸다.

hideInSpotlight (iOS 18.4+)

@available(macOS 15.0, iOS 18.0, visionOS 2.0, *)
public protocol IndexedEntity: AppEntity {
  var attributeSet: CSSearchableItemAttributeSet { get }


  @available(macOS 15.4, iOS 18.4, visionOS 2.4, *)
  var hideInSpotlight: Bool { get }
}

엔티티 단위로 Spotlight 노출을 끌 수 있다.

게다가 계산 프로퍼티라 상수가 아니어도 된다. "비공개로 표시한 메모만 숨긴다" 같은 판단을 런타임에 할 수 있다는 뜻이다.

기본 구현이 익스텐션으로 제공되니 필요한 엔티티에서만 오버라이드하면 된다.

색인에서 지우는 API도 있다

public func deleteAppEntities<Entity>(
  identifiedBy identifiers: [Entity.ID], ofType type: Entity.Type
) async throws


public func deleteAppEntities<Entity>(ofType entityType: Entity.Type) async throws

개별 엔티티도, 타입 전체도 색인에서 뺄 수 있다.

사용자가 항목을 삭제하거나 비공개로 바꿨을 때 불러줘야 하는 것들이다.

그럼 3경로 중 뭘 막을 수 있나

정리하면 이렇게 갈린다.

Spotlight 시맨틱 인덱스 — 막을 수 있다. hideInSpotlight, deleteAppEntities, 그리고 Core Spotlight 시절 수단(attributeSet 조정, protectionClass: .complete로 잠금 시 접근 차단)까지 겹쳐 있다.

IntentValueQuery — 막고 자시고 할 게 없다. values(for:)를 개발자가 직접 구현하니 뭘 돌려줄지가 곧 통제다.

onscreen awareness — 여기만 제외 수단이 안 보인다. SDK를 훑어도 appEntityIdentifier를 붙이는 API만 있고 빼는 쪽은 없다. 결국 민감한 화면에는 어노테이션을 달지 않는 것이 유일한 방법이다.

처음 예상("안 만들면 어차피 못 하니 차단 API는 없을 것")은 onscreen에서만 맞았다.


그래서 실무에서는

정리하면 이렇게 판단하게 된다.

앱을 Siri에 열기 전에 결정할 것은 "무엇을 노출할까"가 아니라 "무엇을 노출하지 않을까"다.

Spotlight는 나중에도 뺄 수 있지만 onscreen은 그렇지 않으니, 어노테이션을 달 때 정해야 한다.

민감한 화면은 .appEntityIdentifier를 붙이지 않는다. onscreen에서는 이게 유일한 차단이다.

색인은 엔티티 단위로 고른다. 숨길 건 hideInSpotlight로 끄고, 이미 들어간 건 deleteAppEntities로 뺀다.

삭제·전송·공유처럼 되돌릴 수 없는 인텐트에는 .requiresAuthentication을 건다. 어차피 스키마 기본값이 이미 엄격한 경우가 많고, 느슨하게는 못 만든다.

외부 데이터를 툴로 읽어오는 구조라면 .onToolCall과 .historyTransform은 선택이 아니라 기본이다.

앱 안에서만 쓸 인텐트는 isDiscoverable = false로 사용자 표면에서 뺀다.

근데... 다들 안할거잖아..?

아니지.. 정확히는 위에서는 관심도 없잖아? 😭😭😭😭


확인 못 한 것

정직하게 클로드가 못찾았다고 이야기해준 것 .

여기서 확인한 건 iOS 26.5 SDK다. Xcode 26.6 기준이라 iOS 27 신규 API는 들어 있지 않다.

onscreen awareness 제외 수단이 iOS 27에서 새로 생겼을 가능성은 남아 있다. Xcode 27이 정식으로 나오면 같은 방법으로 다시 훑어봐야 한다.

iOS 27에서 사용자가 Apple Intelligence를 통째로 끌 수 있는지는 자료마다 엇갈린다.

설정에서 끌 수 있다는 글도 있고, 메뉴가 사라졌다는 커뮤니티 증언도 있다.

관리자(MDM) 쪽도 Writing Tools나 Genmoji는 막을 수 있지만 강화된 Siri는 못 막는다는 서술이 있다.

이건 iOS27 GM 정도 나왔을 때 확인하면 될듯.


마지막으로, 검색하다 보면 "WWDC26 키노트에서 Extensions가 발표됐다"고 쓴 글이 여럿 나온다. Claude나 ChatGPT를 Siri 안에서 고를 수 있게 해주는 그 기능 말이다.

확인해보니 사실이 아니었다. 슬라이드에도 데모에도 보도자료에도 없었고, 베타에 코드와 설정 패널은 들어 있지만 백엔드에서 꺼져 있는 상태다.

AI가 써낸 요약글이 서로를 베끼면서 퍼진 것으로 보인다.

이 글을 쓰면서도 검색 요약이 무관한 두 문장을 엮어 놓은 걸 한 번 밟았다.

1차 출처는 결국 직접 열어보고 검증시켜야 한다.


참고

Comments