세 가지 표면: 사람, Apple Intelligence, 에이전트

iOS 26+의 iOS 앱에서 의미 있는 모든 기능은 이제 호출될 수 있는 최대 세 가지 표면을 마주합니다. 물 한 잔을 기록하는 동일한 Swift 함수가 버튼을 탭하는 사람에 의해, Siri 요청을 라우팅하는 Apple Intelligence에 의해, 또는 MCP 도구를 호출하는 외부 에이전트(Claude Code, Cursor, ChatGPT)에 의해 트리거될 수 있습니다. 세 가지 다른 호출자, 세 가지 다른 의무, 세 가지 다른 렌더링 표면. 기능은 동일하지만, 표면은 그렇지 않습니다.

iOS 아키텍처의 많은 실수는 하나의 표면을 위해 설계한 다음 그 기능을 다른 표면에 억지로 끼워 맞추는 것에서 비롯됩니다. UI 흐름이 Siri 응답으로 새어나가고, 개발자에게는 올바른 에이전트 도구가 최종 사용자에게는 위험이 되며, 온디바이스 LLM 기능이 클라우드급 컨텍스트를 가정합니다. 이 클러스터는 개별 글에서 이러한 표면들을 매핑해 왔습니다. 이번 글은 그 종합입니다 — 세 가지 표면, 그들의 차이점, 라우팅 규칙, 그리고 어떤 것도 타협하지 않고 세 표면 모두에 봉사하기 위해 앱의 도메인 계층이 어떤 모습이어야 하는지에 대해서입니다.

멘탈 모델: 도메인 기능 하나를 선택하세요. 세 가지 표면 중 어느 것이 그것을 호출할 수 있어야 하는지 물으세요. 어느 것이 호출할 수 있는지 물으세요. 각 표면이 그 기능에서 무엇을 필요로 하는지, 그리고 그 기능이 무엇을 돌려주어야 하는지 물으세요. 그 답이 아키텍처를 형성합니다.

TL;DR

• 세 가지 표면: 사람(SwiftUI 뷰, 탭, 제스처, 화면), Apple Intelligence(App Intents, Siri, Shortcuts, Spotlight), 에이전트(MCP 서버, 외부 LLM 호스트).
• 각 표면은 다른 의무를 가집니다 — 신뢰 자세, 지연 시간 예산, 렌더링 위치, 영속성 의미론, 오류 처리, 접근성 요구사항.
• 올바른 아키텍처는 표면 아래에 있는 도메인 계층입니다. 각 표면은 동일한 Swift 함수 위의 얇은 어댑터이며, 함수는 타입이 지정된 Caller 인자를 받아 표면 프로토콜의 세부사항을 알지 못한 채로 표면 간 규칙(속도 제한, 감사, 확인)에 따라 분기할 수 있습니다.
• 모든 기능이 세 표면 모두에 봉사하지는 않습니다. 어느 표면을 결정하는 것이 설계 판단입니다. 가져서는 안 되는 표면으로부터 기능을 숨기는 것은 가져야 할 표면에 노출하는 것만큼이나 중요한 제품 결정입니다.

표면 1: 사람

사람 표면은 화면입니다. 사용자는 앱을 보고, 탭하고, 스크롤하고, 드래그하고, 스와이프하고, 입력합니다. 프레임워크는 SwiftUI(또는 UIKit, 일부 워크로드의 경우 visionOS의 RealityKit)입니다. 렌더링은 사용자의 기기에서, 앱 프로세스 안에서, 사용자가 선택한 색상 구성표, 동적 글자 크기, 접근성 설정에 맞춰 일어납니다.¹

사람 표면이 기능에서 필요로 하는 것:

• 시각적 어포던스. 버튼, 목록 행, 스와이프 제스처, 컨텍스트 메뉴. 기능은 앱의 내비게이션을 통해 발견 가능해야 하고, UI의 나머지 부분과 일관되게 스타일링되어야 합니다.
• 실시간 피드백. 모든 상호작용에는 즉각적인 가시적 응답이 필요합니다. 장시간 실행되는 작업을 발동시키는 버튼은 진행률 표시기, 활성화/비활성화 상태, 애니메이션을 보여주어야 합니다.
• 접근성. VoiceOver 레이블, Dynamic Type 지원, 색상 대비, 모터 제어 대안. 사람 표면은 사용자가 렌더링과 직접 상호작용하기 때문에 가장 까다로운 접근성 요구사항을 가진 표면입니다.
• 오류 가시성. 오류는 사용자의 뷰에 떨어집니다. 저장 실패는 알림을 보여주고, 네트워크 타임아웃은 재시도를 보여주고, 권한 거부는 설정 링크를 보여줍니다.

사람 표면이 기능에 돌려주는 것:

• 모호하지 않은 사용자 의도. 사용자가 특정 버튼을 탭했고, 기능은 정확히 무엇이 요청되었는지 압니다. 추론 계층은 없습니다.
• 빠듯한 지연 시간 예산. 가시적으로 응답하는 데 수백 밀리초 이상 걸리는 탭은 고장난 것처럼 느껴집니다. 기능은 빠르거나 즉시 진행 상황을 보여주도록 설계되어야 합니다.
• 외부 권한 없음. 사용자는 앱 안에 있고, 사용자가 가장 느슨한 의미에서 에이전트입니다(사람이 행동을 주도하는 사람입니다). 제3자 LLM도, 시스템 에이전트도 없고, 그저 사용자의 손만 있습니다.

사람 표면은 세 가지 중 가장 오래 자리 잡은 표면입니다. iOS 7 이후 플랫폼이 축적한 모든 iOS 프레임워크, 디자인 패턴, 접근성 규칙이 이 표면에 봉사합니다. 다른 두 표면은 패턴이 아직 자리 잡고 있을 만큼 최근의 것입니다.

표면 2: Apple Intelligence

Apple Intelligence 표면은 시스템 에이전트입니다. Siri, Shortcuts, Spotlight, 시스템 제안 스택. 사용자가 말을 하거나, Spotlight에 입력하거나, Shortcuts에서 작업을 연결하면 시스템이 App Intents 프레임워크를 통해 요청을 라우팅하고, 일치하는 AppIntent를 찾고, 매개변수를 해석하고, 인텐트의 perform() 본문을 실행합니다. 프레임워크는 App Intents입니다.²

Apple Intelligence 표면이 기능에서 필요로 하는 것:

• 타입이 지정된 스키마. AppIntent 타입은 @Parameter 속성을 선언하고, AppEntity 타입은 시스템이 이야기할 수 있는 것들에 대해 영속적인 정체성을 제공하며, AppEnum 타입은 닫힌 옵션 집합에 이름을 부여합니다. 시스템은 설치 시점에 스키마를 읽습니다.
• 앱 프로세스를 넘어 살아남는 정체성. 사용자가 어제 Siri를 통해 기록한 물 항목은 오늘도 Siri를 통해 참조할 수 있어야 합니다. AppEntity 모델은 시스템이 세션 간에 객체에 대해 이야기할 수 있는 안정적인 방법을 제공합니다.
• 조용한 오류 처리. 오류는 사용자의 뷰에 떨어지지 않고, Siri 응답, Shortcuts 출력, 또는 Spotlight 결과에 떨어집니다. 시스템이 기대하는 오류 형식은 시각적이 아닌 구조화된 형식입니다(Apple의 AppIntentError와 LocalizedError를 준수하는 throws).
• 재시도 시 멱등성. 시스템은 Shortcut 체인 중에 또는 부분 실패 후에 인텐트를 재호출할 수 있습니다. 상태를 변경하는 기능은 반복 호출 시 안전해야 하거나, 명확한 “이미 완료됨” 의미를 표면화해야 합니다.

Apple Intelligence 표면이 기능에 돌려주는 것:

• 사용자의 실제 정체성. 시스템은 사용자가 누구인지 알고, OS를 통해 인증했으며, 그들의 컨텍스트에서 인텐트를 실행합니다. 기능은 OS가 제공하는 것 이상으로 정체성을 검증할 필요가 없습니다.
• 시스템 수준 렌더링. 인텐트가 반환하는 결과는 시스템에 의해 적절한 크롬(잠금 화면 배너, Siri 응답 카드, Shortcuts 출력)으로 포맷됩니다. 앱은 응답이 어떻게 표시되는지 제어하지 않습니다.
• 코드를 실행하지 않고도 가능한 발견. App Intents는 앱이 실행되지 않을 때도 호출될 수 있습니다. 시스템은 스키마를 읽고 기능을 능동적으로 표면화합니다.

신뢰 자세: Apple Intelligence는 Apple의 1차 에이전트입니다. 사용자가 그것을 구성한 것이 아니라 시스템이 구성했습니다. 사용자는 OS를 신뢰하고, OS는 앱이 심사를 통해 출시한 App Intents 스키마를 신뢰합니다. 신뢰 사슬은 OS → 앱입니다. App Intents는 requestConfirmation(...)과 포그라운드 모드 확인을 지원하므로, 기술적으로는 “정말이세요?”가 필요한 기능이 거기에 살 수 있습니다. 고위험 확인이 Siri 턴 안에 속하는지 아니면 앱 자체 화면에 속하는지는 플랫폼의 제약이 아닌 제품 판단입니다. 비가역적인 모든 것(계정 삭제, 파괴적인 대량 편집, 결제)은 App Intents가 확인을 요청할 수 있더라도 사람 표면이 보통 더 안전합니다.³

표면 3: 에이전트

에이전트 표면은 앱의 도메인을 운영하고자 하는 다른 모든 LLM 기반 시스템입니다. Claude Desktop, Claude Code, Cursor, ChatGPT 데스크톱 앱, Codex CLI, 커스텀 에이전트 하니스. 프레임워크는 Model Context Protocol입니다 — MCP 서버가 JSON-RPC tools/call 메서드를 통해 앱의 도메인을 노출하고, 호스트 LLM이 세션 시작 시 도구를 발견하여 JSON 페이로드와 함께 이름으로 호출합니다.⁴

에이전트 표면이 기능에서 필요로 하는 것:

• JSON-RPC 계약. 도구 이름, 설명, inputSchema, 선택적 outputSchema. 에이전트는 호출할지 결정하기 위해 설명을 읽고, 인자를 포맷하기 위해 스키마를 따릅니다.
• 유용한 설명. 모델은 도구의 설명에 기반하여 언제 사용할지 결정합니다. 다른 개발자(모델)가 읽을 것으로 예상되는 docstring처럼 설명을 다루세요. 모호한 설명은 잘못된 도구 선택을 낳습니다.
• 두 가지 형태의 오류. 도구 실행 오류는 모델이 읽는 도구 결과에 콘텐츠 블록과 함께 isError: true로 반환됩니다. 프로토콜 수준 오류(잘못된 요청, 누락된 도구, 전송 실패)는 호스트가 처리하는 표준 JSON-RPC error 응답으로 반환됩니다. 도구 작성자가 첫 번째를 소유하고, 프로토콜이 두 번째를 소유합니다.
• 무상태 또는 명시적 상태 의미론. MCP은 프로토콜 계층에서 상태가 있지만(세션 수명 주기, Streamable HTTP의 세션 ID), 영구적인 도메인 정체성은 서버 측의 책임이지 프로토콜 수준 보장은 아닙니다. 동일한 식별자가 세션 간에 동일한 의미를 가져야 한다면, 서버가 이를 강제해야 합니다.

에이전트 표면이 기능에 돌려주는 것:

• 사용자가 아닌 호스트의 인증. 신뢰는 MCP 서버를 배포한 사람으로부터 옵니다. 개발자의 로컬 stdio: 개발자 자신의 파일시스템 권한. 인터넷 도달 가능 HTTP: 서버가 강제하는 어떤 인증이든. 기능은 정체성 주장이 서버가 부여한 것이라고 가정해야 합니다.
• 가변적 지연 시간 허용. 호스트는 사람 표면이나 Apple Intelligence 표면보다 더 오래 기다릴 수 있습니다. 30초 걸리는 도구 호출은 에이전트 표면에서는 받아들일 수 있지만 다른 표면에서는 받아들일 수 없습니다.
• 렌더링 표면 없음. 결과는 모델이 해석하는 텍스트 또는 구조화된 데이터입니다. 크롬도, UI도, 시스템 포맷도 없습니다.

신뢰 자세: MCP 서버는 누가 호출할 수 있는지에 대한 개발자의 계약입니다. 동일한 서버의 두 가지 배포(개발용 로컬 stdio, 최종 사용자용 인터넷 HTTP)는 매우 다른 신뢰 자세를 가지며 매우 다른 가드레일이 필요합니다. 프로토콜은 같지만, 배포가 아키텍처입니다. App Intents vs MCP: 라우팅 질문과 LLM이 앱 안에 살 때 vs 도구 안에 살 때에서 자세히 다룹니다.⁵

표면들이 의견 차이를 보이는 6가지 축

세 표면을 비교 표로 끌어내면 아키텍처 결정이 구체화됩니다:

이 의견 차이는 합쳐집니다. 사람 표면을 위해 설계된 기능은 빠듯한 지연 시간, 풍부한 렌더링, 앱이 관리하는 오류를 가정합니다. 그것을 Apple Intelligence를 통해 억지로 끼워 맞추면 렌더링 제어를 잃고 OS가 매개하는 정체성이 추가됩니다. 그것을 에이전트 표면을 통해 억지로 끼워 맞추면 렌더링이 완전히 사라지고 신뢰 경계가 서버를 배포한 사람에게로 이동합니다. 기능은 단순히 다시 감싸지는 것이 아니라 다시 형성되어야 합니다.

아키텍처 규칙: 표면 아래의 도메인 계층

세 표면을 가로질러 살아남는 패턴은 그 아래의 도메인 계층입니다. 도메인 계층은 평범한 Swift 함수입니다 — 타입이 지정된 입력, 타입이 지정된 출력, 프로토콜 가정 없음. 각 표면은 도메인 위의 얇은 어댑터입니다. 동일한 logWater(amount:caller:) 함수가 SwiftUI 버튼, App Intent의 perform(), 그리고 MCP 도구의 핸들러를 뒷받침합니다.

스케치(실제 프로덕션에서는 App Intent 반환을 위해 WaterEntry를 AppEntity에 준수시키고, domain을 최상위 참조가 아닌 의존성으로 주입하며, 인텐트에 필수 static var title을 추가할 것입니다):

// Domain layer (the actual capability)
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 A: human surface (SwiftUI button)
Button("Log 250ml") {
    Task {
        let entry = try await domain.logWater(
            amount: .init(value: 250, unit: .milliliters),
            at: .now,
            caller: .human
        )
        // Update view state, show confirmation animation, etc.
    }
}

// Adapter B: Apple Intelligence surface (AppIntent)
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)  // WaterEntry conforms to AppEntity
    }
}

// Adapter C: agent surface (MCP tool 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)")

세 명의 호출자. 하나의 도메인 함수. 도메인 함수는 Caller 매개변수를 받아 각 표면이 다시 구현할 필요 없이 표면별로 다른 규칙(속도 제한, 감사 로깅, 확인 요구사항)을 강제할 수 있습니다. 어댑터는 멍청하고, 도메인은 똑똑합니다.

이 형태는 App Intents vs MCP의 이중 어댑터 패턴을 일반화합니다. 사람 표면을 세 번째 호출자 클래스로 추가하는 것은 자연스러운 확장입니다. Foundation Models 온디바이스 LLM은, 앱 내부에서 사용될 때, 사람 표면 위에 위치합니다(사용자가 모델을 호출하는 앱 내 기능을 발동시킨 것입니다). 런타임 LLM은 네 번째 표면이 아니라, 이미 사람 표면에 속한 기능을 실행하는 방법입니다.⁶

모든 기능이 세 표면 모두에 봉사하지는 않습니다

평등한 노출이 목표가 아닙니다. 다른 기능은 다른 표면에 속합니다.

일반적으로 포그라운드 사람 존재를 요구해야 하는 기능. 사진 촬영, 생체 인증, 민감한 PII 입력, 결제 확인, 계정 삭제. 사람은 화면을 보고, 동의하고, 인증해야 합니다. Apple Intelligence는 기술적으로 앱을 포그라운드로 가져와 확인을 요청할 수 있지만, 에이전트 표면은 그에 상응하는 존재 보장이 없습니다. 제품 판단은 이러한 기능이 조용한 Siri나 백그라운드 도구 호출이 아닌, 명시적이고 의도적인 행동을 동반한 포그라운드 UI로 실행되어야 한다는 것입니다.

사람 + Apple Intelligence 표면에 살아야 하는 기능. 사용자 대면 작업의 대부분. 물 기록, 명상 시작, 목록에 항목 추가, 화요일의 기록 보여줘. 사용자가 버튼을 탭할 수도 있고 “헤이 Siri”라고 말할 수도 있습니다. 두 표면 모두 유효하며, 둘 다 동일한 도메인 함수에 도달해야 합니다.

세 표면 모두에 살아야 하는 기능. 프로세스 간 통합. 사용자의 iPhone과 레시피를 가져오는 Claude Code 세션 사이에 공유되는 쇼핑 목록. 사람 표면은 일상적 사용을 소유하고, Apple Intelligence 표면은 Siri/Spotlight 도달 범위를 소유하며, 에이전트 표면은 개발자 또는 사용자가 주도하는 외부 워크플로우를 소유합니다.

에이전트 표면에만 살아야 하는 기능. 최종 사용자 검토 흐름이 없는 개발자 또는 관리자의 대량 가져오기, 외부 시스템과의 통합, Siri나 앱 내 표현이 없는 에이전트 오케스트레이션 워크플로우. 일회성 백필 중에 개발자의 CSV에서 500개의 과거 항목을 대량 가져오기. 최종 사용자 파일 가져오기는 종종 사람 표면 흐름을 가지며(Shortcuts가 파일을 전달할 수 있고, 앱 내 가져오기가 진행 상황을 청크로 처리할 수 있습니다), 에이전트 전용 사례는 다른 두 표면에 진정으로 자리가 없는 워크플로우입니다.

결정이 곧 설계입니다. 기능이 봉사하지 않는 표면을 나열하는 것은 봉사하는 표면을 나열하는 것만큼 중요합니다.

다르게 만들 것

이 클러스터의 앱들이 출시했거나 출시하기를 바라는 두 가지 패턴.

Caller를 도메인 계층의 1급 타입으로 만드세요. 모든 공개 도메인 함수는 Caller 인자를 받습니다. 이 타입은 어느 표면이 호출을 발동시켰는지(.human, .siri, .mcp(host:))를 인코딩합니다. 도메인 로직은 확인 프롬프트, 속도 제한, 감사 로깅, 민감한 작업 게이트를 위해 그것에 따라 분기합니다. 대안(각 표면이 규칙을 다시 구현하는 것)은 표류하지만, 중앙화된 버전은 일관성을 유지합니다.

표면 커버리지를 명시적인 체크리스트로 다루세요. 기능을 추가할 때, 설계 문서는 세 표면 중 어느 것이 그것을 노출해야 하고 어느 것이 거부해야 하는지를 나열합니다. 거부 목록은 기본값이 아니라, 의도적인 선택입니다. 거부됨: Apple Intelligence 표면, 기능이 Siri가 제공할 수 없는 사용자 주의 증명을 요구하기 때문에. 추론이 기록되고, 감사가 나중에 표류를 잡아냅니다.

iOS 26+에 출시되는 앱들에게 이 패턴이 의미하는 것

세 가지 핵심.

1. 세 가지 표면, 세 가지 신뢰 자세. 사람, Apple Intelligence, 에이전트. 각각 다른 표면에는 없는 의무를 가집니다. 하나를 위해 설계하고 다른 표면에 억지로 끼워 맞추는 것은 모든 표면에서 나쁜 아키텍처를 낳습니다.

2. 아래는 도메인, 위는 어댑터. 기능당 하나의 Swift 함수, 표면당 얇은 어댑터, 함수는 한 곳에서 표면별 규칙을 강제할 수 있도록 Caller 매개변수를 받습니다.

3. 모든 기능이 세 표면 모두에 봉사하지는 않습니다. 가져서는 안 되는 표면으로부터 기능을 숨기는 것은 노출하는 것만큼이나 중요한 설계 결정입니다. 거부 목록은 그 자리를 얻습니다.

전체 Apple Ecosystem 클러스터: Apple Intelligence 표면을 위한 타입이 지정된 App Intents, 에이전트 표면을 위한 MCP 서버, 그들 사이의 라우팅 질문, 사람 표면 내부의 온디바이스 LLM 기능을 위한 Foundation Models, 런타임 vs 도구 LLM 구분, iOS 잠금 화면 상태 머신을 위한 Live Activities, Apple Watch에서의 watchOS 런타임 계약, 사람 표면의 기반을 위한 SwiftUI 내부, visionOS 장면을 위한 RealityKit의 공간 멘탈 모델, 표면 간 영속성을 위한 SwiftData 스키마 규율, 사람 시각 계층을 위한 Liquid Glass 패턴, 기기 간 도달 범위를 위한 멀티 플랫폼 출시. 허브는 Apple Ecosystem Series에 있습니다. AI 에이전트가 함께하는 더 넓은 iOS 컨텍스트는 iOS Agent Development guide를 참조하세요.

FAQ

iOS 앱의 세 가지 표면은 무엇인가요?

사람 표면(SwiftUI 뷰, 탭, 제스처, 화면), Apple Intelligence 표면(App Intents, Siri, Shortcuts, Spotlight), 그리고 에이전트 표면(Claude Code, Cursor, ChatGPT 같은 외부 LLM 호스트에 노출되는 MCP 서버). 각각 자체 호출자 정체성, 지연 시간 예산, 렌더링 위치, 영속성 의미론, 신뢰 자세를 가집니다. 둘 이상의 표면에 봉사하고자 하는 기능은 표면별 얇은 어댑터 아래의 도메인 계층에 위치해야 합니다.

모든 기능이 세 표면 모두에 노출되어야 하나요?

아니요. 일부 기능은 하나 또는 두 개의 표면으로 정확히 제한됩니다. 사진 촬영, 생체 인증, 민감한 작업 확인은 보통 포그라운드 사람 표면 흐름이 가장 적합합니다. 신뢰 신호(사용자 주의, 의도적 행동)가 거기서 가장 신뢰할 수 있게 존재하기 때문입니다. 최종 사용자 검토 흐름이 없는 개발자 주도 대량 작업은 에이전트 표면에만 속합니다. 설계 판단은 기능이 어느 표면에 봉사하고 어느 표면을 거부하느냐입니다.

Apple Intelligence와 에이전트 표면의 차이는 무엇인가요?

Apple Intelligence는 Apple의 1차 에이전트입니다 — 사용자가 Siri, Shortcuts 또는 Spotlight를 호출하면 시스템이 App Intents를 통해 라우팅합니다. 신뢰는 OS에서 옵니다. 에이전트 표면은 다른 모든 LLM 호스트입니다 — 개발자는 Claude Code 또는 Cursor를 실행하고, 최종 사용자는 Claude Desktop 또는 ChatGPT를 실행합니다. 신뢰는 MCP 서버를 배포한 사람으로부터 옵니다. App Intents는 첫 번째에 대한 프로토콜 표면이고, MCP은 두 번째에 대한 프로토콜 표면입니다.

온디바이스 Foundation Models LLM은 어디에 맞나요?

사람 표면 안에. 사용자가 Foundation Models를 호출하는 앱 내 기능을 발동시킬 때, 런타임 LLM은 네 번째 표면이 아닌 사람 표면 기능의 구현입니다. 런타임 LLM은 자체 Siri 또는 외부 호스트 호출자가 없습니다. Foundation Models 도구는 온디바이스 모델이 앱 도메인 상태를 읽고 쓰는 방법입니다 — 호출을 주도하는 사람은 사용자입니다.

도메인 계층 패턴은 다중 표면 코드를 어떻게 단순화하나요?

규칙을 중앙화함으로써. 하나의 Swift 함수가 Caller 인자를 받아 한 곳에서 표면별 동작(확인 프롬프트, 속도 제한, 감사 로깅)을 강제합니다. 각 표면은 표면의 프로토콜을 도메인 함수로 번역하는 얇은 어댑터(SwiftUI 바인딩, AppIntent.perform, MCP 핸들러)입니다. 진실의 단일 출처가 있기 때문에 표면 간 표류가 불가능해집니다.

References