App Intents 대 MCP: 라우팅 문제

장르: frontier-essay. 이 글은 에이전트 기반 Apple 개발을 위한 라우팅 규칙을 명명합니다. 두 프로토콜(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를 통해 오늘 저장한 물 항목은 재부팅을 거쳐도 살아남고, NSUbiquitousKeyValueStore를 통해 동기화되며, 나중에 다른 인텐트(어제의 물 항목을 보여줘)에서 참조될 수 있습니다. 시스템은 그 모든 호출에 걸쳐 엔터티 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가 필요합니다. 물 250ml 기록, 명상 시작, 내 목록에 바나나 추가, 어제 몸무게가 얼마였지는 사용자가 큰소리로 말하거나, Spotlight에 입력하거나, Shortcuts에서 체이닝할 수 있는 인텐트입니다. App Intent는 그러한 기능에 선택사항이 아닙니다. 다른 어떤 것도 Apple Intelligence의 퍼스트 파티 에이전트 표면에 도달하게 해주지 않습니다.

그 기능이 외부 에이전트가 구동할 수 있어야 하는 것인가? 그렇다면 그 기능은 MCP 도구가 필요합니다. Claude Code 세션에서 쇼핑 목록에 항목 추가, Cursor 에이전트 컨텍스트로 Get Bananas 상태 읽기, 원격 도구 사용 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 지원은 더 나쁩니다. 모델은 화면을 구동하지 않으며, 도구를 구동합니다.

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

장시간 백그라운드 작업. App Intents는 진행 상황을 노출하기 위한 ProgressReportingIntent를 포함하고, MCP은 진행 알림과 작업 프리미티브를 포함하지만, 어느 프로토콜의 렌더링 레이어도 소비자 흐름에서 지속적인 진행을 위해 만들어지지 않았습니다. MCP 세션의 호스트 모델은 보통 몇 분짜리 도구가 끝나기 훨씬 전에 추론 체인을 타임아웃시킵니다. 소비자 대상의 장시간 작업의 경우, 앱 자체의 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 스택에 의미하는 것

두 가지 시사점.

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에 있습니다. 더 폭넓은 iOS-와-AI-에이전트 컨텍스트는 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 서버 게시물에서 다룸)와 Water(App Intents 게시물에서 다룸)가 초기 사례입니다. 패턴은 도메인 레이어가 아래에 있고, 그 위에 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에 대해 구현 수준에서 설명됩니다. ↩