Apple은 AI 가시성(AI visibility)을 의무화하고, AI 통합을 제공자 중립적(provider-agnostic)으로 만들었습니다. 무엇이 변했는지, 왜 이것이 App Tracking Transparency와 유사한지, 그리고 9월에 iOS 27이 출시되기 전에 무엇을 출시해야 하는지에 대해 알아봅니다.

요약 (TL;DR)

• App Intents는 이제 Siri가 귀하의 앱에 도달할 수 있는 유일한 방법입니다. App Intents가 없다면 귀하의 앱은 새로운 Siri에게 보이지 않습니다.
• Foundation Models는 모델 추상화 계층(model abstraction layer)을 추가했습니다. 코드 한 줄로 Apple의 온디바이스 모델, Gemini 또는 Claude를 교체할 수 있습니다.
• 프레임워크는 이제 Python SDK를 제공하며, Linux에서 실행되고, 제3자 앱으로부터 이미지 입력을 허용합니다.
• EU와 중국은 개발자 API는 제공받지만, 출시 시점에 소비자용 Siri AI 기능은 제공받지 못합니다.

WWDC 2026에서 Apple은 모바일 빌더들을 위해 두 가지 사항을 플랫폼 기본값(platform defaults)으로 전환했습니다. 첫째는 AI 가시성입니다. App Intents는 이제 Siri가 귀하의 앱 내부로 들어갈 수 있는 유일한 방법이며, SiriKit은 지원 종료(deprecation) 시계가 돌아가고 있습니다. 이를 건너뛴다면 귀하의 앱은 iOS 27의 어시스턴트에서 사라지게 됩니다. 둘째는 AI 통합입니다. Foundation Models 프레임워크는 모델 추상화 계층, Python SDK, Linux 지원 및 이미지 입력을 추가했습니다. 따라서 온디바이스 또는 멀티 프로바이더(multi-provider) AI를 추가하는 것은 이제 Apple의 로드맵에 도박을 거는 대신, 작고 이식 가능한 변경 사항이 되었습니다.

이 키노트를 지루하게 만든 습관 (좋은 의미에서)

몇 년 전, 저는 Apple 개발자 릴리스 노트(release notes)를 브라우저 탭에 고정해 두곤 했습니다. Apple이 App Tracking Transparency를 출시하고 데이터 공유 프롬프트를 의무화했을 때, 제가 아는 앱의 절반 이상에서 분석(analytics)과 어트리뷰션(attribution)이 깨졌습니다. 사용자의 명시적인 동의 없이는 아무것도 측정할 수 없게 되었고, 팀들은 이를 따라잡기 위해 몇 달 동안 허둥지둥했습니다. 저는 그 조치가 의무화되기 훨씬 전부터 상황을 주시하고 있었기에, 의무화된 주간에 제 React Native 앱에 동의 흐름(consent flow)을 이미 연결해 두었습니다.

Apple이 무엇을 의무화하는지 주시하고 이를 조기에 출시하는 습관이 이 플랫폼에서 승리하는 게임의 대부분입니다. 이것이 바로 어제의 키노트(keynote)가 저를 놀라게 하지 않은 이유이기도 합니다. 올해의 의무적인 변화는 트래킹 프롬프트(tracking prompt)가 아닙니다. 그것은 AI가 당신의 앱을 볼 수 있는지, 그리고 당신의 앱이 단일 벤더(vendor)에 전체 아키텍처(architecture)를 거는 도박 없이 AI를 사용할 수 있는지에 관한 것입니다.

모바일 제품을 만드는 사람들을 위해 필터링한 핵심 내용은 다음과 같습니다. React Native 관련 세부 사항은 하단에 있습니다.

App Intents 없이는 Siri에게 당신의 앱이 보이지 않는 이유

저는 어제 전부터 질문을 품고 있었습니다. 휴대폰 내부에서 실행되는 AI 도구들이 당신의 앱을 볼 수 있게 하려면 어떻게 해야 할까요? 저는 그 답변이 백엔드(backend) 데이터를 노출하는 MCP 서버이거나, 그와 비슷하게 복잡한 무언가일 것이라고 어느 정도 예상했습니다. App Intents가 제가 예상했던 답변이었지만, 이번에 Apple이 만든 방식만큼 직접적이지는 않았을 뿐입니다.

Siri AI는 App Intents를 기반으로 작동합니다. SiriKit은 WWDC 2026을 기점으로 컴파일 타임 경고(compile-time warnings)와 함께 지원이 중단(deprecated)되었으며, App Intents는 Siri가 서드파티(third-party) 앱을 호출할 수 있는 유일한 지원 방식입니다. 만약 당신의 앱이 핵심 동작들을 인텐트(intents)로 노출하지 않는다면, 새로운 Siri는 그 어떤 것도 볼 수 없거나 트리거(trigger)할 수 없습니다.

이것은 App Tracking Transparency(앱 추적 투명성)의 순간이 반복되는 것입니다. 당시의 의무 사항은 동의 프롬프트(consent prompt)였습니다. 이번에는 당신의 앱이 무엇을 하는지에 대한 기계 판독 가능한 설명(machine-readable description)입니다. iOS 27에서 어시스턴트(assistant)는 정문이 되었고, App Intents는 그 자물쇠에 맞는 유일한 열쇠입니다.

App Intents 2.0은 더 풍부한 엔티티(entity) 타입, 오래 걸리는 동작을 위한 스트리밍 응답(streaming responses), 그리고 멀티턴 대화형 후속 조치(multi-turn conversational follow-ups)를 추가했습니다. 만약 당신이 소비자용 앱을 출시하고 사용자들이 Siri를 사용한다면, 이것은 9월 전까지 당신의 프로젝트에서 단일 최우선 순위로 다뤄야 할 추가 사항입니다. 저는 이것을 2021년에 트래킹 동의 흐름(tracking consent flow)을 다루었던 방식과 동일하게 취급하고 있습니다. 즉, 선택 사항이 아니며, 일찍 처리할수록 좋습니다.

이것은 제가 현재 저의 AI 모바일 런처(AI Mobile Launcher) 내부에 있는 습관 앱인 Morrow Self에서 진행하고 있는 작업입니다. Morrow Self는 누군가의 일상 루틴의 중심에 자리 잡고 있으므로, Siri를 통해 접근할 수 있게 만드는 것이야말로 그 가치를 증명하는 통합 방식입니다. 즉, 앱을 열지 않고도 음성만으로 습관을 추가하고, 오늘의 진행 상황을 확인하며, 연속 달성 기록(streak)을 기록하는 것과 같은 기능들입니다. 저는 어시스턴트가 앱을 직접 제어할 수 있도록 iOS 27에 앞서 핵심 동작들을 App Intents로 연결하고 있습니다.

왜 App Intents에 생성형 UI (Generative UI)가 필요하며, 왜 이 부분이 아직 해결되지 않았는가

App Intents는 질문의 절반에 대해 답을 줍니다. 즉, 이제 어시스턴트가 여러분의 앱 동작을 호출할 수 있게 되었다는 점입니다. 하지만 나머지 절반, 즉 호출되었을 때 사용자가 무엇을 보게 되는지에 대해서는 답하지 못합니다. 인텐트(Intent)는 작은 SwiftUI 스니펫을 반환할 수는 있지만, 응답이 단순한 확인(confirmation)을 넘어 차트, 다단계 양식(multi-step form), 사용자가 조작할 수 있는 리스트 등 더 풍부한 정보가 되는 순간, 여러분은 가능한 모든 응답에 대해 고정된 화면을 일일이 수동으로 제작해야 하는 상황으로 돌아가게 됩니다.

이것이 바로 생성형 UI (Generative UI)의 격차입니다. 웹에서는 이 패턴이 정착되어 있습니다. 모델이 등록된 컴포넌트 세트 중에서 선택하여 내용을 채우는 방식이므로, 인터페이스가 요청에 맞춰 하드코딩(hard-coded)되는 대신 적응하게 됩니다. 모바일에서는 이러한 패턴이 패키지화된 형태로 거의 존재하지 않습니다. App Intents는 어시스턴트가 선택할 수 있는 타입이 지정된 동작(typed surface of actions)을 제공합니다. 반면 생성형 UI는 어시스턴트가 응답으로 조합할 수 있는 타입이 지정된 컴포넌트(typed surface of components)를 제공할 것입니다. Apple은 올해 그 절반을 출시했습니다. 나머지 절반은 여전히 미해결 과제이며, 아직 누구도 이에 대한 깔끔한 해답을 내놓지 못했습니다.

제가 이 문제에 관심을 갖는 이유는 이것이 "AI가 사용 가능한 앱을 만드세요"라는 문구 뒤에 숨겨진 진짜 제품(Product)에 관한 질문이기 때문입니다. 호출 가능(Callable)하다는 것은 이제 기본 요건(Table stakes)입니다. 미리 구축된 인터페이스가 아니라, 그 순간을 위해 생성된 적절한 인터페이스로 응답할 수 있느냐가 사용자 경험의 승패를 가르는 지점입니다. 이것이 바로 제가 Wire RN을 구축하고 있는 이유이기도 합니다. App Intents가 액션(Actions) 사이에서 선택할 수 있게 해주는 것과 같은 방식으로, 어시스턴트가 선택할 수 있는 React Native 컴포넌트들을 등록하는 방법입니다. 의도(Intent) 레이어는 이제 표준화되었습니다. UI 레이어는 여전히 주인이 없는 상태입니다.

Apple은 단 한 줄의 코드로 AI 제공자를 교체할 수 있게 만들었습니다

iOS 27의 Foundation Models(파운데이션 모델)에서는 LanguageModel 프로토콜(문서 링크)이 도입되었습니다. Apple의 온디바이스 모델, Google Gemini, 그리고 Anthropic Claude 모두 이 프로토콜을 구현합니다. 세션 로직을 한 번만 작성하면, 제공자를 전환하는 것은 단 한 줄의 변경만으로 가능합니다.

어제까지만 해도 Foundation Models를 기반으로 구축한다는 것은 귀하의 AI 아키텍처를 Apple의 모델과 Apple의 출시 일정에 종속시키는 것을 의미했습니다. 제가 대화하는 대부분의 팀은 그러한 도박을 거부하고 대신 OpenAI API를 기반으로 구축하며 비용과 개인정보 보호(Privacy) 측면의 기회비용을 감수해 왔습니다. 이제 이 추상화 레이어(Abstraction layer)는 거부할 이유를 없애줍니다.

[

]

실질적인 형태는 하이브리드 라우팅(Hybrid routing)입니다. 짧고, 개인적이며, 단순한 호출은 무료이고 오프라인에서도 작동하는 온디바이스 모델로 보냅니다. 복잡한 추론은 동일한 API를 통해 Claude나 Gemini로 라우팅합니다. 최첨단(Frontier) 품질이 필요한 호출에 대해서만 비용을 지불하면 됩니다. 프로덕션 팀들은 지난 2년 동안 이를 수동으로 구축해 왔으나, Apple은 이를 단 하루 만에 끝낼 수 있는 작업으로 만들어 버렸습니다.

Foundation Models가 이제 Linux에서 실행되며 Python을 지원합니다

Apple은 Foundation Models를 위한 Python SDK를 출시하고 프레임워크가 Linux에서 실행되도록 만들었습니다. 이제 Apple Intelligence와 인접한 런타임(Runtime)을 Linux 서버의 Python 스크립트에서 호출할 수 있습니다.

1년 전이었다면 말도 안 되는 소리였을 것입니다. 이는 iOS 기기 없이도 모바일 AI 기능을 프로토타이핑할 수 있고, CI(지속적 통합) 환경과 온디바이스 (on-device) 환경에서 동일한 평가 스위트 (evaluation suite)를 실행할 수 있으며, Claude나 Gemini 옆에서 Python 에이전트 프레임워크 (agent framework)를 통해 Apple의 모델을 타겟팅할 수 있음을 의미합니다. Apple 스택을 위해 개발하는 비용이 이제 OpenAI API를 위해 개발하는 비용과 거의 비슷한 수준으로 떨어졌습니다.

온디바이스 (on-device) 모델은 이제 서드파티 (third-party) 앱으로부터의 이미지 입력도 수용합니다. 사진 분석, OCR (광학 문자 인식), 또는 장면 이해 (scene understanding)를 수행하는 모든 앱은 내장된 1~2GB 규모의 비전 모델 (vision model)을 제거하고 대신 시스템 API를 호출할 수 있습니다. MyFitnessPal에 인수되기 전 4,000만 달러의 매출을 달성했던 사진 기반 칼로리 계산 앱인 Cal AI는 정확히 이러한 방식의 비전 호출을 기반으로 구축되었습니다. 어제의 발표 이후, 해당 기능은 모든 사용자에게 무료이며 온디바이스 (on-device)로 제공됩니다.

Apple과 Google의 계약이 시사하는 점

Apple Foundation Models on Cloud는 최첨단 (frontier) 품질 계층이며, Google의 인프라 위에서 실행됩니다. AFM Cloud Pro는 Google Cloud 내부의 Nvidia Blackwell B200 칩에서 실행되며, 이는 Apple이 커스텀 Gemini 모델을 위해 연간 약 10억 달러를 지불하는 파트너십 관계에 있는 것으로 알려져 있습니다. Apple의 계약은 Google이 Siri 쿼리를 사용하여 향후 모델을 학습시키는 것을 금지합니다.

Apple은 이를 개인정보 보호 (privacy)를 위한 결정으로 규정했습니다. 더 단순하게 해석하자면, Apple이 아직 단독으로 최첨단 LLM (대규모 언어 모델)을 구축할 수 없기에 Google의 모델을 빌려 쓰고 있다는 것입니다. 개발자들에게 있어 이점은 클라우드 계층이 Apple의 개인정보 보호 계약으로 보호받으면서, Apple의 API 인터페이스를 통해 Gemini와 대등한 품질을 제공한다는 점입니다. 규제가 엄격한 환경에서 최첨단 추론 (reasoning) 능력이 필요하다면, 이제 이는 실질적인 옵션이 되었습니다.

EU와 중국에 대한 주의 사항, 저에게는 개인적인 문제입니다

Siri AI 소비자 기능은 규제 제약을 이유로 WWDC 2026에서 EU 또는 중국에는 출시되지 않습니다. 만약 해당 시장에 소비자용 앱을 출시한다면, 사용자는 출시 시점에 새로운 Siri를 사용할 수 없습니다.

중요한 뉘앙스는 다음과 같습니다: Foundation Models 개발자 API는 어디서나 작동합니다. 여러분의 앱은 모든 지역에서 온디바이스 모델 (on-device model), 클라우드 모델 (cloud model), 그리고 멀티 프로바이더 추상화 (multi-provider abstraction)를 호출할 수 있습니다. 격차는 개발자 측이 아닌 소비자 측에 존재합니다. 저는 베를린에 있으므로, 제 주변 사람들은 출시 첫날 Siri AI를 볼 수 없을 것입니다. 하지만 제가 만드는 앱은 오늘 바로 전체 프레임워크를 사용할 수 있으며, 이것이 바로 우리가 실행에 옮겨야 할 부분입니다.

iOS 27 출시 전 해야 할 일

1. 여러분의 iOS 앱에 대한 App Intents 커버리지를 감사(Audit)하세요. 만약 커버리지가 없다면, 여러분의 앱은 새로운 Siri에게 보이지 않는 존재가 됩니다. SiriKit에서 벗어나는 마이그레이션 계획을 8월이 아닌 지금 세우세요.
2. 온디바이스 Foundation Models를 어댑터 (adapter) 뒤에 있는 하나의 실제 기능에 연결하세요. 그래야 나중에 코드를 다시 작성하지 않고도 프로바이더를 교체할 수 있습니다. 채팅 (chat)이 아닌 구조화된 추출 (structured extraction)이나 분류 (classification)부터 시작하세요.
3. 네이티브 iOS를 출시한다면, Claude Code 또는 OpenAI Codex를 Xcode MCP 서버에 연결하세요. Xcode 26.3은 이미 MCP를 통해 빌드, 테스트 및 진단 기능을 노출하고 있습니다. 이것이 이번 기조연설에서 가장 높은 보상을 가져다줄 워크플로우의 변화입니다.
4. AI 제품을 만든다면, Extensions 개발자 베타를 신청하세요. Apple은 사용자가 자신의 어시스턴트 프로바이더로 Claude, ChatGPT 또는 Gemini를 선택할 수 있도록 Siri Extensions를 개방했습니다. 이는 20억 대의 기기를 보유한 배포 채널이며, 정식 출시는 약 3개월 남았습니다.

React Native 개발자를 위한 사항

이 내용의 대부분은 하나의 주의사항과 하나의 기회와 함께 React Native로도 적용됩니다.

주의사항: Foundation Models는 Swift 프레임워크이므로, RN에서 이를 호출하려면 브릿지 (bridge)가 필요합니다. 현재 가장 깔끔한 경로는 Callstack의 @react-native-ai/apple이며, 이는 이미 프레임워크를 Vercel AI SDK 호환 인터페이스로 래핑(wrap)하고 있습니다. 이 라이브러리는 iOS 26 버전을 기준으로 구축되었으므로, iOS 27의 추가 기능들(모델 추상화, 멀티모달, 파인튜닝)을 RN에서 사용하려면 브릿지 업데이트가 필요할 것입니다. 해당 리포지토리를 주시하세요.

기회는 여기에 있습니다: Apple이 네이티브(Native) 환경에서 출시한 멀티 프로바이더(multi-provider) 스토리는 @react-native-ai가 이미 구축해 오던 방향과 동일합니다. 프로바이더를 등록하고, 단 한 줄로 교체하며, 동일한 API를 사용합니다. 이 두 가지는 이제 서로 반대편 끝에서 동일한 아키텍처(Architecture)를 설명하고 있으므로, RN 측에서도 빠르게 따라잡을 수 있을 것입니다.

App Intents의 경우, 프로젝트의 네이티브 측 Swift를 통해 노출하며, 보일러플레이트(Boilerplate)를 줄여주는 커뮤니티 패키지들이 존재합니다. MCP의 경우, RN 전용의 무언가가 필요하지 않습니다. Xcode 통합은 Xcode 레벨에서 작동하므로, 에이전트(Agent)를 워크스페이스(Workspace)로 지정하기만 하면 작동합니다. 그리고 제가 getwireai.com에서 개발 중인 오픈 소스 생성형 UI SDK인 Wire RN은 Foundation Models 멀티 프로바이더 API가 안정화됨에 따라 이를 추적할 것입니다.

FAQ

App Intents를 지원하기 위해 앱을 다시 작성해야 하나요?

아니요. App Intents는 기존 UI를 대체하는 것이 아니라, 기존 UI와 함께 추가되는 것입니다. Swift에서 앱의 핵심 동작을 인텐트(Intents)로 선언하면, Siri, Spotlight, 단축어(Shortcuts), 그리고 동작 버튼(Action button)이 모두 이를 호출할 수 있습니다. 기존의 화면들은 지금과 똑같이 그대로 작동합니다.