App Intents와 MCP: 라우팅의 문제

App Intents와 MCP라는 두 프로토콜은 모두 외부 에이전트가 앱의 도메인을 조작할 수 있게 해줍니다. 하지만 이 둘이 하나로 합쳐지지는 않습니다. 문제는 어떤 기능을 어느 쪽에 실을 것인가, 그리고 왜 각 프로토콜이 자기 호출자에게 알맞은 답인가입니다.

Apple이 App Intents를 내놓은 이유는, Apple Intelligence가 서드파티 앱의 UI를 건드리지 않고도 그 앱을 조작할 수 있는 타입이 붙은 선언적 표면을 주기 위해서였습니다.¹ Anthropic이 Model Context Protocol을 내놓은 이유는, 어떤 LLM이든 UI를 건드리지 않고 어떤 도구든 조작할 수 있는, 타입이 붙고 서버가 중개하는 표면을 주기 위해서였습니다.² 모양은 비슷합니다. 호출자는 비슷하지 않습니다. 둘을 하나의 표면으로 취급하면 어느 쪽 요구도 만족시키지 못하는 아키텍처가 나옵니다.

이 클러스터의 앞선 두 글에서는 각 프로토콜을 따로 다뤘습니다. App Intents는 App Intents는 여러분의 앱으로 향하는 Apple의 새로운 API에서, MCP는 두 개의 에이전트 생태계, 하나의 쇼핑 목록에서 다뤘습니다. 이번 글의 주제는 라우팅의 문제입니다. 어떤 기능이 언제 AppIntent가 되고, 언제 MCP 도구가 되고, 언제 둘 다가 되며, 무엇이 앱 안에만 남아야 합니까?

TL;DR

• App Intents는 Apple Intelligence, Siri, Shortcuts, 그리고 시스템 제안 스택으로 가는 유일한 경로입니다. 시스템은 설치 시점부터, 그리고 앱 업데이트를 통해 이들을 사용할 수 있게 만들고, App Shortcuts의 도네이션과 인덱싱이 이들을 Spotlight와 Siri 제안으로 드러내 줍니다.
• MCP 도구는 Apple이 아닌 모든 LLM(Claude, ChatGPT, Gemini, 로컬 모델)으로 가는 경로입니다. 전송 방식은 stdio 또는 Streamable HTTP이고, .mcpb는 로컬 stdio 서버를 함께 담는 경우가 많은 패키징 형식입니다. 호스트는 세션 시작 시점에 도구를 읽어들입니다. 현재 명세 리비전은 2025-11-25이고, 2026-07-28 릴리스 후보는 프로토콜을 무상태 코어를 중심으로 다시 짜고 있습니다⁶⁷.
• 두 프로토콜은 타입이 붙은 스키마, entity → action → result라는 모양, 그리고 파라미터 해석이라는 점에서 만납니다. 갈라지는 지점은 아이덴티티, 지속성, 지연 시간, 그리고 렌더링 표면입니다.
• 라우팅 규칙은 이렇습니다. 사용자가 Siri에게 물어보거나 Spotlight에서 불러낼 만한 기능이면 App Intents. 개발자가 Claude Code 세션이나 외부 에이전트 실행에 연결할 만한 기능이면 MCP. 대부분의 앱은 같은 도메인에 대해 둘 다 필요합니다.

두 프로토콜, 같은 모양

두 프로토콜 모두 외부 호출자와 앱의 도메인 사이의 동작 계약을 정의합니다. 이 계약은 세 부분으로 이루어집니다. 스키마(호출자가 무엇을 요청할 수 있는가), 리졸버(스키마가 지목한 엔티티를 앱이 어떻게 찾는가), 그리고 액션(무엇이 실행되고 무엇이 돌아오는가)입니다.

App Intents는 이 계약을 Swift로 표현합니다. 프로토콜 표면은 AppIntent, AppEntity, AppEnum이고, @Parameter 매크로가 스키마를 만들며 func perform()이 결과를 돌려줍니다.³ 스키마는 컴파일 시점에 생성되어 설치 시 앱에 함께 묶입니다. Apple Intelligence, Siri, Shortcuts, Spotlight는 모두 같은 스키마를 읽고, 타입이 붙은 요청을 같은 perform() 진입점으로 보냅니다.

MCP는 이 계약을 stdio나 Streamable HTTP 위의 JSON-RPC로 표현합니다. 프로토콜 표면은 tools/list와 tools/call 메서드이고, 각 도구는 이름, 설명, inputSchema를 선언합니다(2025-06-18 명세는 구조화된 반환값을 위해 선택적인 outputSchema를 추가했고, 2025-11-25 리비전은 JSON Schema 2020-12를 기본 방언으로 정하고, 메타데이터로서의 도구 아이콘을 더했으며, Anthropic을 넘어서는 거버넌스를 공식화했습니다).⁴⁶ MCP 호스트(Claude Desktop, Claude Code, Cursor, ChatGPT 데스크톱 앱)는 세션 시작 시점에 도구를 발견하고, JSON 페이로드와 함께 이름으로 호출합니다. 모델을 돌리는 쪽은 호스트이고, 도구를 돌리는 쪽은 서버입니다. 프로토콜 자체도 전환기 한가운데에 있습니다. 2026-07-28 릴리스 후보는 MCP를 평범한 HTTP 인프라 위에서 돌아가는 무상태 코어를 중심으로 다시 세우고, 오래 걸리는 작업을 Tasks 확장으로 옮기며, MCP Apps를 통해 서버가 렌더링하는 UI를 더합니다⁷. 아래의 라우팅 논의는 이 개정을 거쳐도 그대로 성립합니다. 호출자가 누구인가는 아무것도 바뀌지 않았기 때문입니다.

모양은 같습니다. 스키마, 리졸버, 액션입니다. 다른 것은 각 부분을 누가 돌리는지, 그리고 신뢰 경계가 어디에 있는지입니다. App Intents는 앱 프로세스 안, 사용자의 기기 위에서, 앱의 엔타이틀먼트 아래 실행되고 호출 라우팅은 시스템이 중개합니다. MCP 서버는 개발자가 고른 곳(로컬 stdio, 호스팅된 HTTP, 임베디드 번들)에서 돌아가고, 끝이 정해지지 않은 도구 집합에 걸친 호출 라우팅은 호스트 LLM이 중개합니다.

같은 모양을 가진 세 번째 호출자를 짚어두면 그림이 완성됩니다. Apple의 Foundation Models 프레임워크 뒤에 있는 온디바이스 모델은 Tool 프로토콜을 통해 앱 코드를 호출합니다. 이름이 있고 설명이 붙고 타입이 정해진 기능이라는 점에서 앞의 둘과 같습니다. 잘 다듬어진 도메인 계층은 누가 호출하는지 모른 채로 이 세 표면 모두에 같은 것을 공급합니다.

두 프로토콜이 갈라지는 지점

표면의 모양을 넘어서, 라우팅에 영향을 주는 운영상의 차이가 넷 있습니다.

아이덴티티와 지속성. App Intents는 시스템이 저장하고, 보여주고, 나중에 다시 해석할 수 있는 AppEntity 타입으로 말합니다. Hey Siri, Water에 250ml 기록해줘로 오늘 저장한 물 기록은 재부팅을 넘어 살아남고, 사용자의 iCloud 기기들 사이에서 동기화되며, 나중에 다른 인텐트가 참조할 수 있습니다(어제 물 기록 보여줘). 시스템은 그 모든 호출에 걸쳐 엔티티 ID를 추적하고,³ iOS 27은 이 이야기를 하드웨어 너머로 확장합니다. SyncableEntity를 따르는 엔티티는 사용자의 기기들 사이에서 일관된 식별자를 지니므로, Siri는 같은 객체에 대한 대화를 iPhone에서 Mac으로, Mac에서 Watch로 넘겨줄 수 있습니다.⁸ MCP도 그 자체로 생명주기 관리를 갖춘 상태 있는 프로토콜이고, Streamable HTTP는 연결의 연속성을 위해 세션 ID를 지원합니다. 하지만 오래 지속되는 도메인 아이덴티티는 서버가 책임지는 관심사이고, 호스트 모델이 세션을 넘어 기댈 수 있는 AppEntity 식별자에 해당하는 프로토콜 수준의 장치는 없습니다. MCP는 지속적인 참조 데이터를 위해 resources를 지원하고, 2025-11-25 명세는 오래 지속되는 요청을 추적하기 위한 실험적 tasks를 더했지만, 도메인 객체의 아이덴티티는 여전히 서버 쪽 책임이지 일급 프로토콜 계약은 아닙니다.⁴⁶ 그 밑바탕의 규율은 앱 자체의 데이터 계층에 적용되는 것과 같습니다. 프로세스보다 오래 살아남는 안정적인 식별자에 대해서는 SwiftData 관점에서 스키마 규율에서 다뤘습니다.

지연 시간과 배터리. App Intent의 perform() 본문은 기기 위의 앱 또는 앱 익스텐션 컨텍스트에서 실행됩니다. 네트워크 사용이 있다면 그건 앱 자신의 코드나 그 주변의 Apple Intelligence/Siri 계층에서 오는 것이지, 인텐트 계약 자체에서 오는 게 아닙니다. 타입이 붙은 온디바이스 액션이 타입이 붙은 결과를 돌려주는 구조는 보통의 경우 빠릅니다. MCP 도구는 로컬인 것조차 stdio JSON-RPC 프레이밍을 거치며 별도의 프로세스 경계를 넘고, 원격 MCP 도구는 HTTP 왕복 비용을 치릅니다. 지연 시간 예산이 다른 것입니다. 250ml 기록해줘 App Intent는 Siri가 말을 주고받는 창 안에서 끝날 수 있습니다. 원격 MCP 도구는 Claude Code 세션의 병목이 될 수도 있습니다.

렌더링 표면. App Intents가 돌려주는 결과는 Apple Intelligence가 시스템 UI로 그립니다. 잠금 화면 배너, Siri 응답, Shortcuts 출력, Spotlight 결과처럼 말입니다. 결과가 어떻게 보일지는 앱이 통제하지 않습니다. MCP 도구는 콘텐츠 블록(텍스트, 이미지, 오디오, 임베디드 리소스, 구조화된 콘텐츠)을 돌려주고, 이를 읽은 호스트 모델이 어떻게 드러낼지 결정합니다. Claude Code 세션이라면 결과를 개발자에게 그대로 인용할 수도, 요약할 수도, 다음 호출로 넘길 수도 있습니다. 렌더링에 대한 결정은 모델 계층에 있습니다.

발견 가능성. Apple Intelligence는 설치 시점부터 App Intents를 사용할 수 있게 하고, App Shortcuts의 도네이션과 인덱싱이 사용자 행동에 따라 인텐트를 Spotlight 검색과 Siri 제안으로 드러냅니다. 앱 업데이트와 동적 엔티티가 시간이 지나며 그 표면을 조정합니다. 사용자가 도구 이름을 입력하는 일은 없습니다. MCP 호스트는 세션 시작 시점에 도구를 읽고, 모델이 어떤 도구를 볼 수 있을지는 사용자(또는 시스템 프롬프트)가 정합니다. 발견은 MCP 쪽에서는 명시적인 설정이고, App Intents 쪽에서는 암묵적인 시스템의 추론입니다.

두 프로토콜은 아이덴티티, 지연 시간, 렌더링, 발견이라는 네 가지 속성에서 갈라집니다. 이 넷은 하나의 뿌리 깊은 차이에서 따라 나옵니다. App Intents는 사용자가 설정한 적 없는 시스템 수준 에이전트를 상대합니다. MCP는 개발자가 설정한 세션 수준 에이전트를 상대합니다. 호출자가 다르면 의무도 다릅니다.

라우팅 규칙

두 프로토콜을 모두 갖춘 앱의 기능 지도는 이렇게 생겼습니다.

                    ┌──────────────────────────────────────────┐
                    │           App's domain capabilities       │
                    │                                            │
                    │  ┌─────────┐  ┌─────────┐  ┌─────────┐    │
                    │  │  CRUD   │  │ Queries │  │ Actions │    │
                    │  └─────────┘  └─────────┘  └─────────┘    │
                    └────┬────────────┬────────────┬────────────┘
                         │            │            │
              ┌──────────┴──────┐    │   ┌────────┴──────────┐
              │                 │    │   │                   │
              ▼                 ▼    ▼   ▼                   ▼
       ┌────────────┐    ┌─────────────────────┐    ┌──────────────┐
       │ App Intents │    │ Both (AppIntent +   │    │  MCP tools   │
       │   only      │    │  MCP tool wrapper)  │    │    only      │
       └────────────┘    └─────────────────────┘    └──────────────┘
            │                       │                       │
       Siri / Spotlight       Cross-protocol           Claude Code,
       Shortcuts              capabilities             external agents,
       Apple Intelligence     where both callers       LLM tooling,
       proactive surfaces     should reach the         dev workflows
                              same domain

라우팅 규칙은 순서대로 던지는 세 가지 질문입니다.

이 기능은 사용자가 Siri에게 물어보거나 Shortcuts에서 호출할 만한 것인가? 그렇다면 그 기능에는 App Intent가 필요합니다. 물 250ml 기록해줘, 명상 시작해줘, 목록에 바나나 추가해줘, 어제 내 몸무게가 얼마였지는 인텐트입니다. 사용자가 소리 내어 말하거나, Spotlight에 입력하거나, Shortcuts에서 이어붙일 수 있기 때문입니다. 그런 기능에 App Intent는 선택이 아닙니다. Apple Intelligence의 퍼스트파티 에이전트 표면에 닿는 다른 길은 없습니다.

이 기능은 외부 에이전트가 몰 수 있어야 하는가? 그렇다면 그 기능에는 MCP 도구가 필요합니다. Claude Code 세션에서 쇼핑 목록에 항목 추가하기, Get Bananas의 상태를 Cursor 에이전트 컨텍스트로 읽어오기, 원격의 도구 사용 LLM에서 워크플로 실행하기는 MCP 도구입니다. 호출자가 Apple Intelligence가 아니기 때문입니다. 호출자는 개발자가 연결해 둔 LLM이 무엇이든 그것입니다. MCP 도구는 App Intent가 호출하는 것과 같은 도메인 계층의 Swift 함수를 감쌀 수 있지만, 프로토콜 표면은 개발자가 고른 전송 방식 위의 JSON-RPC입니다.

이 기능은 시스템이 아는 안정적인 아이덴티티를 지닌 채 한 세션보다 오래 살아남아야 하는가? 그렇다면 App Intent 경로가 자연스럽게 들어맞습니다. 시스템이 AppEntity 아이덴티티, 쿼리 지원, 지속성 시맨틱을 공짜로 주기 때문입니다. 그렇지 않다면 MCP 도구는 콘텐츠 블록을 돌려주고, 오래 가는 아이덴티티는 서버의 재량에 맡기고, 엔티티 모델링 비용을 건너뛸 수 있습니다.

사소하지 않은 앱 기능 대부분은 둘 다 열에 들어갑니다. Water의 물 기록 기능에는 AppIntent가 있고(Siri가 받아쓸 수 있도록), MCP 도구도 있습니다(Claude Code 세션이 내보낸 로그에서 과거 데이터를 채울 수 있도록). 두 경로는 하나의 Swift 함수를 공유하고, 그 함수는 어느 호출자가 불렀는지 알지 못합니다.⁵

코드로 보면 하나의 도메인 메서드와 그것을 함께 호출하는 두 개의 어댑터 래퍼라는 모양입니다.

// Domain layer (Swift, no protocol assumptions)
func logWater(amount: Measurement<UnitVolume>, at: Date, caller: Caller) throws -> WaterEntry {
    try guards.requireWritePermission(caller)
    let entry = WaterEntry(amount: amount, timestamp: at)
    try store.insert(entry)
    return entry
}

// Adapter 1: App Intent (Apple Intelligence / Siri / Shortcuts)
struct LogWaterIntent: AppIntent {
    static var title: LocalizedStringResource = "Log Water"
    @Parameter(title: "Amount") var amount: Measurement<UnitVolume>

    func perform() async throws -> some IntentResult & ReturnsValue<WaterEntry> {
        let entry = try domain.logWater(amount: amount, at: .now, caller: .siri)
        return .result(value: entry)
    }
}

// Adapter 2: MCP tool (Claude Desktop / Code / external agent)
// Tool name "log_water" with inputSchema {amount_ml: number}
// Handler:
let entry = try domain.logWater(
    amount: .init(value: ml, unit: .milliliters),
    at: .now,
    caller: .mcp(host: hostName)
)
return .text("Logged \(entry.amount) at \(entry.timestamp)")

두 어댑터가 달라 보이는 건 호출자가 다르기 때문입니다. 그들이 호출하는 함수는 같습니다.

앱 안에 남는 것

작지만 중요한 한 무리의 기능은 앱 안에만 두어야 합니다. 이들을 어느 한쪽 프로토콜로 보내는 건 실수입니다.

UI 상태 기능. “세 번째 탭 열기”, “맨 아래로 스크롤”, “이 행 강조”는 도메인 동작이 아닙니다. 상호작용의 원시 요소입니다. App Intents는 OpensIntent와 Shortcuts를 통해 일부를 지원하지만 장르적 궁합이 나쁩니다. 사용자가 원하는 건 대개 결과이지 화면 이동이 아니기 때문입니다. UI 내비게이션에 대한 MCP의 지원은 더 나쁩니다. 모델이 몰고 있는 건 화면이 아니라 도구이기 때문입니다.

사람의 몸이 개입해야 하는 기능. 사진 촬영, 생체 인증, 민감한 개인정보 입력, 그리고 사용자가 화면을 보고 탭해야 하는 모든 흐름입니다. 카메라 흐름을 위해 Apple의 CameraCaptureIntent가 있지만, 그 설계 의도는 포그라운드 촬영 액티비티를 띄우는 것이지 에이전트에게 백그라운드 카메라 접근을 내주는 게 아닙니다. 두 프로토콜에 공통으로 적용되는 정직한 규칙은 이렇습니다. 카메라, 생체 인증, 민감한 입력 흐름은 조용한 인텐트 호출이나 도구 호출이 아니라 사용자의 명시적 확인을 동반한 포그라운드 UI로 실행해야 합니다. 이런 기능은 앱 UI 뒤에 두고, 에이전트는 사용자를 화면으로 안내하게 하세요. 화면을 통과해 지나가게 하지 마세요.

오래 걸리는 백그라운드 작업. 여기서는 두 프로토콜 모두 실질적인 원시 요소를 갖게 되었고, 계산은 “절대 하지 말 것”에서 “프로토콜의 장치를 써서 의도적으로 할 것”으로 옮겨갔습니다. Apple 쪽에서는 iOS 27의 LongRunningIntent가 진행 상황을 보고한다는 조건 아래 인텐트를 시스템의 30초 백그라운드 제한 너머로 실행하게 해줍니다(이 프로토콜은 ProgressReportingIntent를 다듬은 것입니다). 그 진행 상황은 Live Activities가 그려줍니다⁸. MCP 쪽에서는 2025-11-25 명세가 폴링과 지연된 결과 수신을 갖춘 오래 지속되는 요청을 위한 실험적 tasks를 더했고, 2026-07-28 릴리스 후보에서 Tasks 확장으로 승격됐습니다⁶⁷. 지금의 정직한 경계는 이렇습니다. 호출자가 그 작업을 직접 시작했고 지켜보기를 기대한다면 이 원시 요소를 쓰세요. 소비자가 필요로 하는 “진행 상황”이 퍼센트보다 풍부할 때, 또는 호스트 모델이 기다리다 추론 사슬을 타임아웃시킬 때는 그 작업을 앱 자신의 UI 뒤에 두세요. 끝이 열려 있는 작업에 대해서는 요청을 큐에 넣었습니다. 여기 상태 화면이 있습니다가 여전히 옳은 반환값입니다.

다른 사용자의 데이터를 건드리는 모든 것. 두 프로토콜에서 신뢰 경계는 호출하는 에이전트입니다. Apple Intelligence는 사용자의 iCloud 계정 아래 돌아갑니다. MCP는 개발자가 연결해 둔 자격 증명 아래 돌아갑니다. 사용자를 가로지르는 작업(공유, 다중 계정 접근, 관리자 동작)은 호출하는 아이덴티티가 옳은 아이덴티티가 아니기 때문에 어느 프로토콜을 통해서도 안전하지 않습니다.

다시 만든다면 이렇게

위의 라우팅 규칙을 알고 나면, Swift 앱의 도메인 계층은 제가 요즘 서비스 경계에서 API를 설계하는 방식 그대로 설계하게 됩니다. 도메인 메서드는 타입이 붙은 입력을 받고 타입이 붙은 출력을 돌려주며, 프로토콜에 대한 전제는 하나도 박아 넣지 않습니다. App Intents는 @Parameter 스키마와 perform() 접착 코드로 도메인 메서드를 얇게 감쌉니다. MCP 도구는 JSON 스키마와 stdio 프레이밍으로 같은 도메인 메서드를 얇게 감쌉니다. 두 프로토콜 모두 얇은 어댑터이고, 일은 도메인에 있습니다.

여기서 두 가지 결론이 따라 나옵니다.

호출자 아이덴티티는 도메인의 관심사이지 프로토콜의 관심사가 아닙니다. App Intent 본문은 시스템이 해석한 파라미터를 받고, 사용자가 시스템의 인텐트 호출 흐름을 거쳐온 컨텍스트에서 실행됩니다. MCP 도구 본문은 호스트가 마련한 자격 증명이 무엇이든 그것을 받습니다. 둘 다 명시적인 caller 인자로 도메인 메서드에 넘겨집니다. 인가, 확인 프롬프트, 그 밖의 도메인 불변식을 강제하는 건 도메인 메서드입니다. 어느 프로토콜도 호출자가 사용자인 척할 권한을 갖지 못합니다.

두 어댑터는 같은 어포던스 집합을 드러냅니다. 어떤 기능을 어떤 호출자에게 노출할지에 대한 결정은 여기저기 흩어진 프로토콜 코드가 아니라 두 개의 매니페스트에 담깁니다. 새 기능을 더한다는 건 도메인 메서드 하나, 어댑터 래퍼 둘, 매니페스트 항목 둘입니다. 기능을 없애는 것도 대칭입니다. 위의 행렬이 실제 파일이 되는 것입니다.

앞으로 몇 년간 Apple 플랫폼의 프런티어는 프로토콜 하나를 고르는 일이 아닙니다. 프런티어는 둘을 같은 도메인 계층에서 합성되는 직교 계약으로 다루는 일입니다. Apple Intelligence 에이전트는 사용자에 대해 한 묶음의 의무를 집니다(온디바이스에서 돌고, Siri로 말하고, 시스템을 통해 그립니다). 외부 LLM 에이전트는 개발자에 대해 다른 묶음의 의무를 집니다(어디서든 돌고, JSON-RPC로 말하고, 개발자가 고른 모델을 통해 그립니다). 둘 다 여러분의 앱으로 향하는 타입 붙은 표면을 가질 자격이 있습니다. 그리고 둘 다 유일한 표면이 될 자격은 없습니다.

둘 다 만들지 말아야 할 때

이 논의는 양쪽으로 다 벱니다. 어떤 앱은 한 프로토콜만 필요하고 다른 하나는 필요 없습니다.

개발자용 표면이 없는 순수한 소비자 유틸리티. 손전등. 새소리 식별 앱. 증강현실 줄자. 사용자는 Siri로 불러내고 싶어 할 수 있지만(App Intents는 쓸모 있습니다), 그것을 LLM 워크플로에 연결할 개발자는 없습니다(MCP는 겉치레에 그칠 것입니다).

최종 사용자용 표면이 없는 순수한 개발자 도구. 코드 포매터 MCP 서버. 저장소 검색 도구. 패키지 버전 검사기. 여기서 사용자는 Claude Code 세션에 있는 개발자이고, Siri와 Apple Intelligence가 맡을 역할은 없습니다.

어느 에이전트 부류에도 잘 응답하지 못하는 앱. 상호작용이 강한 게임, 실시간 멀티플레이어 앱, 앱 안에 있고 화면을 보는 것 자체가 가치인 앱입니다. 어느 프로토콜도 잘 맞지 않습니다. 옳은 답은 훌륭한 앱을 만들고 에이전트 계약은 두지 않는 것입니다.

결정해야 할 것은 기본적으로 하나냐 둘이냐가 아닙니다. 결정해야 할 것은 이 앱은 무엇을 위한 것이고 또 누가 이 도메인을 조작하고 싶어 할까입니다. 답은 아무것도 아닐 수도, 하나일 수도, 둘 다일 수도 있습니다. 도메인 계층이 잘 다듬어져 있다면 하나를 만드는 비용은 작습니다. 그 도메인 계층 위에 둘 다 만드는 비용도 마찬가지로 작습니다. 정작 큰 비용은 유스케이스가 요구하는데도 하나를 만들지 않는 비용입니다. 그러면 그 기능은 해당 에이전트 표면에서 완전히 사라집니다.

이 패턴이 iOS 26 이후 Apple 스택에 갖는 의미

가져갈 점은 둘입니다.

1. App Intents와 MCP를 경쟁하는 프로토콜이 아니라 같은 도메인 위의 직교 계약으로 다루세요. Apple Intelligence, Siri, Shortcuts, Spotlight는 시스템 수준의 의무를 지닌 하나의 호출자 부류입니다. Claude, Cursor, ChatGPT 등은 세션 수준의 의무를 지닌 두 번째 호출자 부류입니다. 둘 다 타입 붙은 접근을 가질 자격이 있습니다. 그 아래의 도메인 계층은 바뀌지 않습니다.

2. 라우팅 규칙은 누가 호출하는가이지 무엇이 실행되는가가 아닙니다. App Intent와 MCP 도구는 같은 Swift 함수를 호출할 수 있습니다. 다른 것은 호출자가 지는 의무, 돌려받는 렌더링, 그리고 기대하는 지속성입니다. 함수를 제대로 만들고, 프로토콜 계층은 얇게 두세요.

Apple Ecosystem 클러스터 전체는 이렇습니다. Apple Intelligence를 위한 타입 붙은 App Intents, LLM을 가로지르는 에이전트를 위한 MCP 서버, 잠금 화면 상태 기계를 위한 Live Activities, 시각 계층을 위한 Liquid Glass 패턴, 그리고 기기를 가로질러 닿기 위한 멀티플랫폼 출시. 허브는 Apple Ecosystem 시리즈에 있습니다. iOS와 AI 에이전트라는 더 넓은 맥락은 iOS 에이전트 개발 가이드를 참고하세요.

자주 묻는 질문

같은 기능에 대해 App Intent와 MCP 도구 중 무엇을 만들어야 하나요?

그 기능이 Apple Intelligence, Siri, Shortcuts, Spotlight에 닿아야 한다면 App Intent를 만드세요. 외부 LLM(Claude, ChatGPT, Claude Code나 Cursor 안의 에이전트)에 닿아야 한다면 MCP 도구를 만드세요. 두 호출자 부류 모두에 응답해야 하는 도메인 기능이라면, 공유된 Swift 도메인 메서드 위에 얇은 어댑터로 둘 다 만드세요.

App Intents와 MCP 서버는 서로 경쟁하나요?

아닙니다. App Intents는 Apple의 퍼스트파티 에이전트 스택으로 가는 경로이고, MCP는 그 밖의 모든 LLM으로 가는 경로입니다. Apple Intelligence는 MCP 도구를 호출하지 않고, 외부 LLM 에이전트는 App Intents를 직접 호출할 수 없습니다(시스템을 거칩니다). 두 프로토콜은 서로 다른 신뢰 모델, 서로 다른 지연 시간 예산, 서로 다른 렌더링 표면을 지닌 서로 다른 호출자 부류에 응답합니다.

앱 하나가 두 프로토콜 모두로 도메인을 노출할 수 있나요?

가능하고, 에이전트 도달 범위를 온전히 갖고 싶은 사소하지 않은 앱 대부분은 그렇게 해야 합니다. Get Bananas(MCP 서버 글에서 다뤘습니다)와 Water(App Intents 글에서 다뤘습니다)가 초기 사례입니다. 패턴은 아래에 도메인 계층을 두고 그 위에 App Intent 어댑터와 MCP 도구 어댑터를 얹는 것입니다. 두 어댑터 모두 같은 Swift 함수를 호출합니다.

Apple Intelligence는 추적하지만 MCP는 추적하지 않는 상태는 무엇인가요?

Apple Intelligence는 AppEntity 아이덴티티를 호출과 세션과 재부팅에 걸쳐 추적하고, iOS 27의 SyncableEntity를 쓰면 사용자의 기기들에 걸쳐서도 추적합니다⁸. 엔티티 모델은 사용자가 인텐트를 가로질러 이어붙일 수 있는 지속적인 참조를 시스템에 제공합니다. MCP 자체도 생명주기 관리와 Streamable HTTP의 세션 ID를 갖춘 상태 있는 프로토콜이지만, 오래 지속되는 도메인 아이덴티티는 일급 프로토콜 계약이 아니라 서버 쪽 책임입니다. 호스트 모델은 프로토콜 표면에서 AppEntity에 해당하는 식별자를 받지 못합니다. MCP의 resources 개념과 2025-11-25 명세의 실험적 tasks는 지속적인 참조 데이터와 오래 지속되는 요청을 뒷받침하지만, 둘 다 서버가 소유하는 같은 계층에서 동작합니다⁶.

어느 프로토콜로도 노출하지 말아야 할 기능이 있나요?

있습니다. UI 상태 기능(이 탭 열기, 여기까지 스크롤), 사람의 몸이 개입해야 하는 기능(사진 촬영, 생체 인증, 민감한 입력), 그리고 여러 사용자의 데이터를 가로지르는 작업은 앱 UI 뒤에 남아야 합니다. 어느 프로토콜도 사용자를 가로질러 안전하게 동작하는 데 필요한 신뢰 신호를 싣고 있지 않기 때문입니다. 오래 걸리는 백그라운드 작업은 경계가 움직인 예외입니다. iOS 27의 LongRunningIntent와 MCP의 tasks 확장이 이제 실질적인 원시 요소를 주니, 그 장치를 통해 의도적으로 노출하고, 끝이 열려 있고 진행 막대보다 풍부한 정보가 필요한 작업만 여러분의 UI 뒤에 두세요.

참고 자료