App Intents vs MCP: 라우팅의 문제

Q: Apple Intelligence가 추적하지만 MCP이 추적하지 않는 상태는 무엇입니까?

Apple Intelligence는 호출, 세션, 그리고 재부팅 전반에 걸쳐 AppEntity 정체성을 추적합니다. 엔티티 모델은 사용자가 인텐트 전반에 걸쳐 체이닝할 수 있는 영속적인 참조를 시스템에 제공합니다. MCP 자체는 라이프사이클 관리와 Streamable HTTP의 세션 ID를 가진 상태유지 프로토콜이지만, 영속적인 도메인 정체성은 일급 프로토콜 계약이라기보다는 서버 측 책임입니다. 호스트 모델은 프로토콜 표면에서 AppEntity에 해당하는 식별자를 받지 않습니다. MCP의 resources 개념은 영속적인 참조 데이터를 지원하지만 같은 서버 소유 계층에서 작동합니다.

11분 소요

두 개의 프로토콜, App Intents와 MCP은 모두 외부 에이전트가 앱의 도메인을 조작할 수 있게 해 줍니다. 두 프로토콜은 하나로 합쳐지지 않습니다. 핵심 질문은 어느 것이 어디로 가야 하는지, 그리고 왜 각 프로토콜이 자신의 호출자에게 적합한 답인지입니다.

Apple은 Apple Intelligence가 서드파티 앱의 UI를 거치지 않고도 그 도메인을 조작할 수 있는 타입화된 선언적 표면을 제공하기 위해 App Intents를 출시했습니다.¹ Anthropic은 모든 LLM이 어떤 도구든 UI를 거치지 않고 조작할 수 있는 타입화되고 서버 매개 표면을 제공하기 위해 Model Context Protocol을 출시했습니다.² 형태는 비슷합니다. 호출자는 그렇지 않습니다. 두 프로토콜을 하나의 표면으로 취급하면 어느 쪽도 만족시키지 못하는 아키텍처가 만들어집니다.

이 클러스터의 앞선 두 게시글은 각 프로토콜을 개별적으로 다뤘습니다. App Intents는 App Intents Are Apple’s New API to Your App에서, MCP은 Two Agent Ecosystems, One Shopping List에서 다뤘습니다. 이번 게시글은 라우팅의 문제입니다. 어떤 기능에 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 서버를 함께 포함하는 패키징 형식입니다. 호스트는 세션 시작 시점에 도구를 로드합니다.
두 프로토콜 모두 타입화된 스키마, 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를 추가합니다).⁴ MCP 호스트(Claude Desktop, Claude Code, Cursor, ChatGPT 데스크톱 앱)는 세션 시작 시 도구를 발견하고 JSON 페이로드와 함께 이름으로 호출합니다. 호스트는 모델을 실행합니다. 서버는 도구를 실행합니다.

형태는 같습니다: 스키마, 리졸버, 액션. 차이점은 누가 각 부분을 실행하고 신뢰 경계가 어디에 있는지입니다. App Intents는 사용자의 기기에서 앱 프로세스 내부에서, 앱의 권한 하에 실행되며, 시스템이 호출 라우팅을 매개합니다. MCP 서버는 개발자가 실행하기로 선택한 곳(로컬 stdio, 호스팅된 HTTP, 임베디드 번들)에서 어디든 실행되며, 호스트 LLM이 무한한 도구 집합 전반의 호출 라우팅을 매개합니다.

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

표면 형태를 넘어, 라우팅에 중요한 네 가지 운영상 차이가 있습니다.

정체성과 영속성. App Intents는 시스템이 저장하고, 표시하고, 나중에 다시 해석할 수 있는 AppEntity 타입으로 말합니다. Hey Siri, log 250ml in Water를 통해 오늘 저장한 물 기록은 재부팅 후에도 살아남고, 사용자의 iCloud 기기 전반에 동기화되며, 나중에 다른 인텐트에서 참조될 수 있습니다(Show me yesterday’s water entries). 시스템은 이 모든 호출에서 엔티티 ID를 추적합니다.³ MCP 자체는 라이프사이클 관리 기능이 있는 상태유지 프로토콜이고, Streamable HTTP는 연결 연속성을 위해 세션 ID를 지원하지만, 영속적인 도메인 정체성은 서버가 소유하는 관심사입니다. 호스트 모델이 세션 전반에 걸쳐 의존할 수 있는 AppEntity 식별자에 해당하는 프로토콜 수준의 대응물은 없습니다. MCP은 영속적인 참조 데이터를 위한 resources를 지원하지만, 정체성은 일급 프로토콜 계약이라기보다는 여전히 서버 측 책임으로 남습니다.⁴

지연 시간과 배터리. App Intent의 perform() 본문은 기기의 앱 또는 앱 익스텐션 컨텍스트에서 실행됩니다. 모든 네트워크 사용은 인텐트 계약 자체가 아니라 앱 자체 코드 또는 주변의 Apple Intelligence/Siri 계층에서 발생합니다. 타입화된 결과를 반환하는 타입화된 온디바이스 액션은 일반적인 경우 빠릅니다. MCP 도구는 로컬에 있더라도 별도의 프로세스 경계가 있는 stdio JSON-RPC 프레이밍을 거치며, 원격 MCP 도구는 HTTP 라운드 트립을 발생시킵니다. 지연 시간 예산이 다릅니다. log 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가 필요합니다. Log 250ml of water, Start a meditation, Add bananas to my list, What did I weigh yesterday는 사용자가 큰 소리로 말하거나, Spotlight에 입력하거나, Shortcuts에서 체이닝할 수 있기 때문에 인텐트입니다. 이러한 기능에 App Intent는 선택사항이 아닙니다. 다른 어떤 것도 Apple Intelligence의 일급 에이전트 표면에 도달하게 해 주지 않습니다.

그 기능은 외부 에이전트가 구동할 수 있어야 하는 것입니까? 그렇다면 그 기능은 MCP 도구가 필요합니다. Add an item to the shopping list from a Claude Code session, Read Get Bananas state into a Cursor agent context, Trigger a workflow from a remote tool-using LLM는 호출자가 Apple Intelligence가 아니기 때문에 MCP 도구입니다. 호출자는 개발자가 연결한 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 지원은 더 나쁩니다. 모델은 화면을 구동하는 것이 아니라 도구를 구동하고 있습니다.

사람의 몸이 루프 안에 있어야 하는 기능. 사진 촬영, 생체 인증, 민감한 PII 입력, 사용자가 화면을 보고 탭해야 하는 모든 흐름. Apple의 CameraCaptureIntent는 카메라 흐름을 위해 존재하지만, 설계 의도는 포그라운드 캡처 활동을 시작하는 것이지 에이전트에게 백그라운드 카메라 접근을 허용하는 것이 아닙니다. 두 프로토콜에 대한 정직한 규칙: 카메라, 생체 인증, 민감한 입력 흐름은 침묵의 인텐트나 도구 호출이 아니라 명시적인 사용자 확인과 함께 포그라운드 UI로 실행되어야 합니다. 이러한 기능을 앱의 UI 뒤에 두고 에이전트가 사용자를 화면으로 라우팅하게 하되, 화면을 거치지 않게 해야 합니다.

장시간 실행되는 백그라운드 작업. App Intents는 진행 상황을 표면화하기 위한 ProgressReportingIntent를 포함하고, MCP은 진행 알림과 작업 프리미티브를 포함하지만, 두 프로토콜의 렌더링 계층 모두 소비자 흐름의 지속적인 진행 상황을 위해 만들어지지 않았습니다. MCP 세션의 호스트 모델은 일반적으로 몇 분짜리 도구가 완료되기 훨씬 전에 추론 체인을 타임아웃시킵니다. 소비자 대상의 장시간 실행 작업의 경우, 작업을 앱 자체의 UI를 통해 노출하고, 프로토콜이 요청이 큐에 들어갔습니다를 반환하고 상태 화면으로 링크하게 해야 합니다.

다른 사용자의 데이터를 건드리는 모든 것. 두 프로토콜의 신뢰 경계는 호출하는 에이전트입니다. Apple Intelligence는 사용자의 iCloud 계정 하에서 실행됩니다. MCP은 개발자가 연결한 자격 증명에 따라 실행됩니다. 사용자를 가로지르는 작업(공유, 다중 계정 접근, 관리자 작업)은 호출 정체성이 잘못된 정체성이기 때문에 어느 프로토콜을 통해서도 안전하지 않습니다.

다르게 만들었을 것

위의 라우팅 규칙을 알고 있다면, 저는 이제 서비스 경계에서 API를 설계하는 방식으로 Swift 앱의 도메인 계층을 설계할 것입니다. 도메인 메서드는 타입화된 입력을 받고 타입화된 출력을 반환하며, 프로토콜 가정이 내장되어 있지 않습니다. 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 스택에 의미하는 것

두 가지 주요 시사점.

App Intents와 MCP을 같은 도메인 위의 직교 계약으로 취급하라. 경쟁하는 프로토콜이 아닙니다. Apple Intelligence, Siri, Shortcuts, Spotlight는 시스템 수준의 의무를 가진 한 호출자 클래스입니다. Claude, Cursor, ChatGPT 등은 세션 수준의 의무를 가진 두 번째 호출자 클래스입니다. 둘 다 타입화된 접근을 받을 자격이 있습니다. 그것들 아래의 도메인 계층은 변하지 않습니다.
라우팅 규칙은 누가 호출하느냐이지, 무엇이 실행되느냐가 아닙니다. App Intent와 MCP 도구는 같은 Swift 함수를 호출할 수 있습니다. 호출자가 짊어지는 의무, 그것들이 받는 렌더링, 그리고 그것들이 기대하는 영속성에서 차이가 납니다. 함수를 올바르게 만드세요. 프로토콜 계층은 얇게 두세요.

전체 Apple Ecosystem 클러스터: Apple Intelligence를 위한 타입화된 App Intents, 크로스 LLM 에이전트를 위한 MCP 서버, 잠금 화면 상태 머신을 위한 Live Activities, 시각적 계층을 위한 Liquid Glass 패턴, 그리고 크로스 디바이스 도달을 위한 멀티 플랫폼 출시. 허브는 Apple Ecosystem Series에 있습니다. AI 에이전트가 있는 iOS의 더 넓은 맥락은 iOS Agent Development guide를 참조하세요.

FAQ

같은 기능에 대해 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 server post에서 다룸)와 Water(App Intents post에서 다룸)는 초기 사례입니다. 패턴은 도메인 계층을 아래에 두고, 그 위에 App Intent 어댑터와 MCP 도구 어댑터를 두는 것입니다. 두 어댑터 모두 같은 Swift 함수를 호출합니다.

Apple Intelligence가 추적하지만 MCP이 추적하지 않는 상태는 무엇입니까?

Apple Intelligence는 호출, 세션, 그리고 재부팅 전반에 걸쳐 AppEntity 정체성을 추적합니다. 엔티티 모델은 사용자가 인텐트 전반에 걸쳐 체이닝할 수 있는 영속적인 참조를 시스템에 제공합니다. MCP 자체는 라이프사이클 관리와 Streamable HTTP의 세션 ID를 가진 상태유지 프로토콜이지만, 영속적인 도메인 정체성은 일급 프로토콜 계약이라기보다는 서버 측 책임입니다. 호스트 모델은 프로토콜 표면에서 AppEntity에 해당하는 식별자를 받지 않습니다. MCP의 resources 개념은 영속적인 참조 데이터를 지원하지만 같은 서버 소유 계층에서 작동합니다.

어느 프로토콜을 통해서도 노출하지 말아야 할 기능이 있습니까?

네. UI 상태 기능(이 탭 열기, 여기로 스크롤), 사람의 몸이 루프 안에 있어야 하는 기능(카메라 캡처, 생체 인증, 민감한 입력), 장시간 실행되는 백그라운드 작업, 그리고 여러 사용자의 데이터를 가로지르는 작업은 모두 앱의 UI 뒤에 머물러야 합니다. 두 프로토콜 모두 이러한 것들에 대한 약한 프리미티브를 가지고 있으며, 어느 쪽도 사용자 전반에 걸쳐 안전하게 작동하는 데 필요한 신뢰 신호를 가지고 있지 않습니다.

참고 문헌

Apple Developer, “App Intents framework”. Apple Intelligence, Siri, Shortcuts, 그리고 Spotlight가 라우팅할 수 있는 인텐트, 엔티티, 매개변수, 쿼리를 선언하기 위한 표면. ↩
Anthropic, “Model Context Protocol”. LLM 호스트 전반의 타입화된 도구 노출을 위한 오픈 프로토콜. 전송 방식은 stdio 또는 Streamable HTTP입니다. .mcpb는 일반적으로 로컬 stdio 서버를 함께 포함하는 패키징 형식입니다. 사양은 tools/list, tools/call, resources, 그리고 프롬프트를 다룹니다. ↩
Apple Developer, “Creating your first app intent” 그리고 “AppEntity”. AppIntent 프로토콜, @Parameter 매크로, func perform() 진입점, 그리고 영속적 정체성을 위한 AppEntity. ↩↩
Anthropic, “MCP Specification: Tools (2025-06-18)”, “MCP Architecture”, 그리고 “Transports (2025-06-18)”. tools/list와 tools/call을 위한 JSON-RPC 메서드 정의, inputSchema와 선택적 outputSchema, 호스트 책임, 라이프사이클 관리, 그리고 stdio / Streamable HTTP 전송 방식. ↩↩
저자의 분석은 App Intents Are Apple’s New API to Your App와 Two Agent Ecosystems, One Shopping List에 있습니다. 이중 어댑터 패턴(하나의 Swift 도메인 메서드, 두 개의 프로토콜 래퍼)은 Water와 Get Bananas에 대해 두 게시글 모두에서 구현 수준으로 설명됩니다. ↩