Foundation Models 에이전트 워크플로: 인앱 vs 툴링 LLM

iOS 26의 Swift 앱에는 매우 다른 계층에서 닿는 두 개의 LLM가 있습니다. 하나는 사용자가 앱의 LanguageModelSession을 통해 실행하는 온디바이스 모델입니다. 다른 하나는 개발자가 처음 앱을 작성하기 위해 Claude Code나 Cursor, Codex CLI를 통해 실행한 에이전트입니다. 이 두 LLM를 혼동하는 것은 에이전트형 Apple 개발에서 반복되는 아키텍처 실수입니다. 둘은 같은 문제가 아니며, 보안 모델을 공유하지 않고, 배포 방식을 공유하지도 않으며, 한쪽에 통하는 패턴이 다른 쪽에서는 적극적으로 실패합니다.

런타임 LLM는 사용자에게 출시되는 기능입니다. 툴링 LLM는 개발자가 손에 쥔 스타일러스입니다. 런타임 모델은 사용자의 프라이버시 기대, 시스템의 가용성 검사, App Store 심사 뒤에 존재합니다. 툴링 모델은 개발자의 API 키, IDE의 파일시스템 권한, 그리고 개발자가 책임지는 코드 리뷰 뒤에 존재합니다. 두 스택은 거의 교차하지 않으며, 교차할 때(개발 중 앱 도메인을 다루기 위해 개발자가 사용하는 MCP 서버를 런타임 앱이 최종 사용자 자동화를 위해 노출할 수도 있는 경우)는 신뢰 경계가 이동하므로 아키텍처가 이를 인정해야 합니다.

이 글은 그 구분과 뒤따르는 라우팅 질문, 즉 어떤 LLM가 어떤 기능을 제공해야 하는가, 그리고 각각이 사용자에게 무엇을 빚지고 있는가를 정의합니다.

TL;DR

• 런타임 LLM는 Foundation Models입니다(SystemLanguageModel.default와 Tool 프로토콜). 추론은 로컬에서 이루어지고, 모델은 OS와 함께 출시되며, 앱은 사용자를 대신해 호출을 실행합니다.¹
• 툴링 LLM는 개발자가 선택한 무엇이든 됩니다. Claude Code의 Claude, Cursor의 GPT, Swift용 Codex CLI 등입니다. 추론은 원격에서 이루어지고(Anthropic의 인프라 또는 구성된 Claude 공급자, OpenAI 등), 모델은 호스트가 둔 곳 어디든 있으며, 개발자가 에이전트를 운전합니다.
• 두 LLM는 보안, 배포, 지연 예산, 책임을 공유하지 않습니다. 한 계층에서 의미가 있는 기능이 다른 계층에서는 잘못된 형태인 경우가 많습니다.
• 개발자가 Claude Code 세션 중에 사용하는 동일한 MCP 서버가 자동으로 최종 사용자 에이전트 자동화에 적합한 표면이 되는 것은 아닙니다. 신뢰 경계가 변하며, 개발자 통제 도구였던 것이 사용자 통제(또는 시스템 통제) 도구가 됩니다.

두 개의 스택, 같은 단어 “LLM”

이런 대화에서 충돌이 일어납니다. 누군가 “앱에 LLM를 추가해야 한다”고 말합니다. 그것이 사용자가 호출하는 기능(나에게 명상 요약을 작성해 달라, 이 초안을 다듬어 달라, 이 사진을 분류해 달라)을 의미하는지, 아니면 개발자가 자신의 반복 루프에 연결하는 도구(Claude Code가 마이그레이션을 작성하게 하라, Cursor가 뷰를 리팩터링하게 하라)를 의미하는지는 그 문장만으로는 분명하지 않습니다. 둘 다 LLM 추가입니다. 어느 것도 같은 엔지니어링 결정이 아닙니다.

Foundation Models는 하나의 스택입니다. 모델은 SystemLanguageModel.default에 존재하며, 고정된 컨텍스트 창을 가지고, Apple silicon에서 실행되며, 절대로 디바이스를 떠나지 않고, 사용자의 Apple Intelligence 자격 여부에 의해 게이트됩니다.¹ 앱 개발자는 @Generable 타입을 통해 입력을 제약하고, Tool 프로토콜을 통해 앱 기능을 노출하며, 기능이 트리거될 때 모델을 호출하는 바이너리를 출시합니다. 사용자가 기능을 호출하고, OS가 모델을 제공하며, 앱이 둘을 엮어줍니다.

Claude Code, Cursor, Codex CLI, 그리고 다른 모든 에이전트형 IDE는 다른 스택을 형성합니다. 모델은 호스트 LLM 공급자가 실행하는 곳 어디든 존재합니다(Claude의 경우 Anthropic의 서버, GPT의 경우 OpenAI의 서버 등). IDE가 호스트입니다. MCP 서버는 호스트의 모델이 호출할 수 있는 도구입니다. 개발자의 머신은 파일시스템 접근, 셸 접근, 그리고 IDE가 노출하기로 선택한 무엇이든 가지고 있습니다. 개발자가 에이전트를 호출하고, 에이전트는 개발자의 파일시스템에 접근하며, 결과물은 개발자의 프로젝트에 떨어집니다.²

같은 단어 “LLM”이지만, 매우 다른 폭발 반경입니다.

두 스택이 갈라지는 여섯 가지 축

여섯 가지 속성이 그 분기를 구체적으로 보여줍니다.

신뢰 경계가 핵심을 떠받치는 행입니다. 런타임 LLM는 사용자의 프라이버시 기대 아래 앱의 샌드박스 내에서 동작하고, 툴링 LLM는 개발자의 권한 아래 개발자의 머신 내에서 동작합니다. LLM가 셸 명령을 실행하게 하라와 같은 패턴은 툴링에서는 정상이며(Claude Code는 Bash 도구를 통해 끊임없이 그렇게 합니다)³ 런타임에서는 시작도 못 할 일입니다. Foundation Models에는 Bash 도구가 없으며, Tool 프로토콜은 앱 개발자가 작성하고 검토하는 타입화된 Swift 함수입니다.¹

오용 비용 행은 신뢰 경계를 잘못 잡았을 때의 결과입니다. 사용자 데이터를 서버로 빼내는 런타임 LLM는 프라이버시 위반이며 가이드라인 위반에 따른 거절 사유입니다. 개발자의 소스 코드를 LLM 공급자에게 빼내는 툴링 LLM는 개발자의 계약에 따라 예상된 동작이거나 누출입니다. 둘 다 중요하지만, 중요한 이유가 다릅니다.

사이에 자리 잡은 MCP 서버

경계가 이동하는 것을 가장 명확하게 볼 수 있는 곳은 단일 MCP 서버가 두 스택 모두에 의해 사용될 때입니다. Get Bananas는 쇼핑 목록 작업(항목 읽기, 항목 추가, 완료 표시)을 노출하는 MCP 서버를 출시합니다. 동일한 서버가 두 곳에서 실행됩니다.⁴

반복 작업 중 개발자의 Claude Code 세션에서, MCP 서버는 개발자의 에이전트가 개발자 자신의 목록을 조작하기 위해 호출하는 도구입니다. 서버는 iCloud Drive에 있는 JSON 파일을 대상으로 실행됩니다. 개발자는 MCP 호스트 구성에 서버를 연결했고, 호스트는 그것을 호출할 줄 알며, 에이전트는 더 큰 개발 작업의 일부로 쇼핑 항목을 읽고 씁니다.

최종 사용자 에이전트 표면(예를 들어 공유 목록을 가리키는 외부 Claude Desktop 사용자)에서, 동일한 MCP 서버는 다른 의무를 가집니다. 호출자는 더 이상 전체 파일시스템 신뢰를 가진 Blake-개발자가 아니며, 호출자는 인증, 인가, 의도 검증이 개발자의 책임이 아닌 최종 사용자입니다. 그 표면이 안전해지기 전에 MCP 서버는 그 가드레일을 시행해야 합니다(또는 자신을 노출하기를 거부해야 합니다).

동일한 JSON-RPC 메서드 add_item이, 인증 없이 로컬 stdio 전송으로 개발자에게 제공될 때는 적절한 형태입니다. 인증 없이 임의의 최종 사용자를 대신해 인터넷에서 도달 가능한 호스트에 제공된다면, 그것은 데이터 무결성 위험입니다. MCP 서버는 동일한 코드이지만, 주변의 배포가 모든 것을 바꿉니다.

이것이 에이전트형 Apple 개발에서 MCP 서버에 대한 라우팅 규칙입니다. 서버는 도메인에 대한 타입화된 계약입니다. 스택의 어디에 자리하는지(개발자 도구 vs 최종 사용자 표면)는 배포 결정이지 프로토콜 결정이 아닙니다. 배포를 코드 리뷰하시고, 프로토콜의 관대한 기본값이 배포의 올바른 기본값이라고 가정하지 마세요.

온디바이스 Tool 프로토콜은 MCP 서버가 아닙니다

흔한 혼동이 있습니다. Foundation Models에는 Tool 프로토콜이 있고, MCP에는 도구 호출이 있습니다. 둘은 같습니까? 아닙니다. 그리고 그 차이는 라우팅에 중요합니다.

Foundation Models의 Tool 프로토콜은 앱 개발자가 구현하는 Swift API입니다.¹

struct WaterEntryLookup: Tool {
    let name = "lookup_water_entries"
    let description = "Look up water intake entries for a given date range."
    @Generable struct Arguments { ... }
    func call(arguments: Arguments) async throws -> String { ... }
}

도구는 앱 프로세스 내부에서 실행됩니다. 도구가 제공하는 모델은 디바이스의 SystemLanguageModel입니다. 인수와 출력은 Swift 타입입니다. 개발자가 구현을 검토하고, App Store가 앱을 심사합니다. 사용자가 기능을 호출하고, 앱의 세션이 도구를 호출하며, 로컬 모델이 결과를 사용합니다.

MCP 도구는 MCP 서버가 노출하는 JSON-RPC 메서드이며, MCP 서버는 호스트 LLM(Claude, GPT 등)가 연결하는 별도의 프로세스입니다.²

{
  "name": "add_item",
  "description": "Add an item to the shopping list.",
  "inputSchema": {"type": "object", "properties": {"name": {"type": "string"}}}
}

도구는 개발자가 선택한 어떤 언어로든 에이전트 프로세스 외부에서 실행되며, stdio 또는 Streamable HTTP를 통해 JSON로 통신합니다. 모델은 호스트가 둔 곳 어디든 있습니다. 인수는 스키마에 대해 검증된 JSON입니다. 책임은 MCP 서버를 배포한 사람에게 있습니다.

두 프로토콜은 서로 다른 범위로 겹치는 문제를 해결합니다.

라우팅 규칙은 단순합니다. 기능이 최종 사용자를 위한 앱 자체의 LLM 기능을 제공한다면, Foundation Models Tool에 들어갑니다. 기능이 프로세스를 가로질러 동작하는 외부 에이전트(개발자 또는 최종 사용자)를 제공한다면, MCP 도구에 들어갑니다. 어떤 앱은 둘 다 필요하며, 동일한 Swift 함수가 두 어댑터를 모두 뒷받침할 수 있지만, 어댑터는 서로 다른 스택 계층에 자리하며 서로 다른 릴리스 주기를 통해 출시됩니다.⁵

후크는 툴링 LLM가 자신의 자리를 벌어들이는 곳입니다

툴링 LLM의 폭발 반경은 후크를 핵심을 떠받치는 안전 프리미티브로 만듭니다. Claude Code의 후크 시스템은 라이프사이클 이벤트(PreToolUse, PostToolUse, UserPromptSubmit, SessionStart, Stop)에서 스크립트를 실행합니다.⁶ Claude Code를 사용하는 iOS 개발자가 후크를 설정하는 것은 에이전트가 악의적이어서가 아니라, 에이전트의 권한이 광범위하기 때문입니다. 파일시스템 쓰기, 셸 실행, git 커밋, 푸시 등이 그 예입니다.

에이전트형 Apple 작업에서 자신의 후크 자리를 벌어들이는 패턴들입니다.

명시적 승인 없이 xcodebuild 또는 xcrun에 매칭되는 Bash 명령에 대한 PreToolUse 차단. 허용한다면 Claude Code는 빌드를 실행하고, 시뮬레이터를 지우고, 서명이나 익스포트 단계를 호출하거나, 생성된 프로젝트 상태를 변경할 수 있습니다. 후크는 “에이전트가 빌드를 실행했다”를 “에이전트가 빌드 실행을 요청했고 승인을 받았다”로 바꿔줍니다. 되돌릴 수 없는 동작에서 에이전트의 속도를 늦추는 것이 개발자의 자신감을 위한 올바른 트레이드오프입니다.

.pbxproj 파일에 대한 모든 Edit 또는 Write 도구 호출에 대한 PostToolUse 검증기. Xcode 프로젝트 파일은 사람이 편집하지만 에이전트에 독성이 있습니다. 한 줄만 잘못되면 팀의 모든 개발자에게 빌드가 조용히 깨집니다. 커밋하기 전에 모든 .pbxproj 쓰기에 대해 plutil -lint(또는 유사한 구조 검사)를 실행하는 후크가 “에이전트가 5분 만에 마이그레이션을 작성했다”와 “에이전트가 마이그레이션을 작성하고 git bisect로 45분을 보냈다”의 차이를 만듭니다.

에이전트가 작업 완료를 선언하기 전에 swift build(또는 적절한 빌드 명령)를 실행하는 Stop 후크. 에이전트는 대화에서 완료가 어떻게 보이는지에 대해 학습됩니다. 후크는 “완료”를 “빌드가 여전히 컴파일된다”로 의미하게 하며, 그것이 출시에 중요한 유일한 정의입니다.

런타임 LLM는 이 중 어떤 것도 필요로 하지 않습니다. Foundation Models에는 셸도, git도, 프로젝트 파일도, MCP 서버 구성도 없습니다. 온디바이스 Tool은 앱 개발자가 작성한 Swift 함수일 뿐이며, 사용자가 기능을 호출하고, 앱 자신의 Tool 구현이 하지 않는 한 어떤 것도 앱의 샌드박스나 권한을 벗어나지 않습니다.

비대칭이 핵심입니다. 툴링 LLM는 더 많은 권한을 가지고 더 많은 가드레일이 필요합니다. 런타임 LLM는 구조상 권한이 더 적습니다. Apple은 런타임 LLM를 안전하게 만드는 작업을 했고, 개발자는 툴링 LLM를 안전하게 만드는 작업을 합니다.

아키텍처 규칙

런타임/툴링 구분에서 세 가지 아키텍처 규칙이 따라옵니다.

앱이 아니라 기능별로 계층을 선택하세요. 명상 앱은 인앱 요약(런타임 LLM, 온디바이스, 앱과 함께 출시)에 Foundation Models를 사용할 수 있고, 그리고 개발자가 반복 작업 중에 세션 이력을 일괄 가져오기 위해 Claude Code와 함께 사용하는 MCP 서버를 노출할 수도 있습니다. 두 LLM는 서로 다른 계층에서 서로 다른 작업을 수행합니다. 둘을 하나의 결정으로 다루면 둘로 다루는 것보다 두 계층 모두에서 더 나쁜 결과가 나옵니다.

툴링 LLM의 도달 범위를 코드 리뷰하세요. 전체 파일시스템 접근과 원격 MCP 서버를 가진 Claude Code 세션은 강력한 개발 환경이며 관대한 공격 표면입니다. 완화책은 “에이전트를 신뢰하라”가 아니라, 후크, 범위가 지정된 권한, 그리고 diff를 읽는 개발자입니다. 에이전트는 당신을 위해 일하지만, 에이전트는 당신이 아닙니다.

런타임 LLM의 Tool 세트를 안정적인 API로 출시하세요. Foundation Models 도구는 앱의 바이너리 계약의 일부입니다. 릴리스 사이에 도구를 제거하거나 이름을 바꾸는 것은 그 기능에 의존한 사용자에게 행동의 변경입니다. 도구 정의를 내부 헬퍼가 아니라 UI 어포던스처럼 다루세요.

내 스택에서 다르게 만들 것

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

도메인 계층을 먼저 구축하세요. 런타임 도구와 툴링 MCP 서버가 동일한 Swift 함수를 감싸도록 하세요. App Intents vs MCP에서의 듀얼 어댑터 패턴은 런타임 LLM 도구로 자연스럽게 확장됩니다. logWater(amount:caller:) 도메인 메서드는 AppIntent(Apple Intelligence 표면), MCP 도구(외부 에이전트 표면), 그리고 Foundation Models Tool(인앱 런타임 LLM 표면)에 의해 감싸집니다. 세 개의 프로토콜 어댑터, 하나의 도메인 함수, 서로 다른 의무를 가진 세 개의 호출자 클래스(시스템 에이전트, 외부 에이전트, 온디바이스 모델). 함수는 어떤 호출자가 호출했는지 알지 못하며, 어댑터가 신뢰 신호를 운반합니다.

에이전트의 MCP 서버를 구성이 아닌 코드로 다루세요. iOS 프로젝트에서 참조되는 .mcp.json은 범위 및 우선순위 신뢰 표면입니다(저장소가 자신의 신뢰에 투표권을 가져서는 안 된다에서 다룸). Claude Code는 MCP 서버 범위를 local > project > user로 해결하며, 프로젝트 범위의 서버는 사용되기 전에 개발자에게 승인을 요청합니다. 에이전트는 구성을 읽고 개발자가 승인한 서버에 연결하며, 개발자는 구성과 서버를 검토합니다. 프로젝트에 MCP 서버를 추가하는 것은 구성 조정이 아니라 코드 리뷰입니다.

Foundation Models가 적합한 때와 툴링 LLM가 적합한 때

클러스터의 글들이 수렴하는 결정 트리입니다.

Is the capability a feature an end user invokes inside your app?
├── Yes → Runtime LLM (Foundation Models or cloud LLM behind an Apple Intelligence-aware surface)
│         Use the Tool protocol for app-internal tool calls.
│         Use App Intents for capabilities the system agent should reach.
└── No → It is part of the developer's iteration loop.
          ├── Is the capability local to one developer's machine? → Tooling LLM
          │     Use Claude Code, Cursor, or Codex CLI directly.
          │     Wrap shared utilities as MCP servers behind hooks.
          └── Is the capability shared across the team? → Tooling LLM with shared MCP servers
                Deploy the MCP server somewhere the team can reach.
                Code review the server like production code; gate dangerous tools behind explicit approval.

결정이 동률을 만드는 경우는 드뭅니다. 동률이 나올 때(동일한 기능이 정당하게 최종 사용자와 개발자 모두에게 제공될 수 있는 경우), 답은 하나의 공유 표면이 아니라 두 개의 어댑터입니다. 신뢰 자세와 업데이트 주기가 충분히 다르기 때문에 둘 모두를 제공하려는 하나의 표면은 둘 모두에서 타협하게 됩니다.

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

세 가지 시사점입니다.

1. 두 개의 LLM, 두 개의 스택. 런타임 LLM(Foundation Models, 온디바이스)는 사용자의 에이전트가 앱 내부에서 그들의 데이터에 대해 동작하는 것입니다. 툴링 LLM(Claude Code, Cursor, Codex CLI)는 개발자의 에이전트가 앱을 빌드하기 위해 개발자의 머신에서 동작하는 것입니다. 둘은 “LLM”라는 단어를 공유하고 거의 그 외에는 아무것도 공유하지 않습니다.

2. 신뢰 경계가 곧 아키텍처입니다. 모델이 어디서 실행되는지, 누가 그것을 실행하는지, 그것이 무엇에 닿는지가 의무를 정의합니다. 한 경계에 맞는 패턴은 다른 경계에서는 적극적으로 실패합니다.

3. MCP 서버가 경계를 운반합니다. 동일한 서버가 한 배포에서는 개발자 도구이고 다른 배포에서는 최종 사용자 표면입니다. 프로토콜은 변하지 않으며, 배포가 변하고, 배포가 엔지니어링 주의를 필요로 하는 부분입니다.

전체 Apple 생태계 클러스터: Apple Intelligence를 위한 타입화된 App Intents; 교차-LLM 에이전트를 위한 MCP 서버; 둘 사이의 라우팅 질문; 온디바이스 LLM와 Tool 프로토콜을 위한 Foundation Models, 그리고 워크로드 적합도와 전문화 형제로서 사용 사례와 커스텀 어댑터; iOS 잠금 화면 상태 머신을 위한 Live Activities; Apple Watch에서의 watchOS 런타임 계약; 프레임워크 기질을 위한 SwiftUI 내부; visionOS 장면을 위한 RealityKit의 공간 멘탈 모델; 영속성을 위한 SwiftData 스키마 규율; 시각 계층을 위한 Liquid Glass 패턴; 교차 디바이스 도달을 위한 멀티 플랫폼 출시. 허브는 Apple 생태계 시리즈에 있습니다. 더 넓은 iOS-with-AI-에이전트 컨텍스트는 iOS 에이전트 개발 가이드를 참고하세요.

FAQ

아키텍처 관점에서 Foundation Models와 Claude Code의 차이는 무엇입니까?

Foundation Models는 런타임 기능입니다. LLM는 iOS 26과 함께 출시되고, 사용자의 디바이스에서 SystemLanguageModel.default를 통해 실행되며, 앱의 LanguageModelSession이 트리거될 때 호출됩니다. 앱은 사용자를 대신해 호출을 실행합니다. Claude Code는 개발 도구입니다. LLM는 Anthropic의 인프라(또는 구성된 Claude 공급자)에서 실행되고, 개발자의 머신이 IDE를 호스팅하며, 에이전트는 개발자의 파일시스템, 셸, MCP 서버에 접근할 수 있습니다. 개발자가 에이전트를 운전하고, 에이전트는 앱을 빌드하는 데 도움을 줍니다.

동일한 MCP 서버가 내 에이전트와 최종 사용자 모두를 제공해야 합니까?

아마도 아닙니다. 동일한 JSON-RPC 계약이 둘 모두에게 적합한 형태일 수 있지만, 배포는 다릅니다. 인증 없는 개발자 측 stdio는 개발자 도구로는 정상이지만 최종 사용자 표면으로는 위험합니다. 프로토콜은 재사용 가능하지만 배포는 그렇지 않습니다. 동일한 서버를 둘 모두에게 노출한다면, 두 청중을 위한 하나의 표면이 아니라 하나의 코드베이스 뒤의 두 개의 배포로 다루세요.

왜 툴링 LLM는 후크가 필요하지만 런타임 LLM는 필요하지 않습니까?

툴링 LLM는 개발자의 머신에서 파일시스템 접근, 셸 접근, MCP 서버, 임의의 코드 실행 권한을 가집니다. 런타임 LLM(Foundation Models)는 앱의 Tool 구현이 노출하는 것만, 앱의 샌드박스 내부에서, 셸 없이 가집니다. 폭발 반경이 비대칭입니다. 후크는 광범위한 권한에 대한 사전 실행 검토와 사후 실행 검증을 개발자에게 제공합니다. 런타임 LLM는 권한이 구조상 제약되어 있기 때문에 후크가 필요하지 않습니다.

단일 Swift 도메인 함수가 런타임과 툴링 LLM 사용 사례 모두를 제공할 수 있습니까?

예, 그리고 그것이 올바른 패턴입니다. 듀얼 어댑터 접근(하나의 Swift 함수, 여러 프로토콜 래퍼)은 App Intents vs MCP에서 확장되어 Foundation Models 도구를 포함합니다. 함수는 어떤 호출자가 호출했는지 알지 못하며, 어댑터가 스키마, 신뢰 신호, 프로토콜별 의무를 운반합니다. 세 개의 어댑터, 하나의 도메인 메서드.

호스팅된 클라우드 LLM(OpenAI, Anthropic API 직접)는 이 그림에 어디에 들어맞습니까?

런타임에 앱 내부에서 호출되는 클라우드 LLM는 세 번째 범주입니다. 오프디바이스 추론을 가진 런타임 LLM입니다. 그것들은 “앱이 사용자를 대신해 호출을 실행한다”는 Foundation Models 신뢰 자세를 공유하지만, 온디바이스 프라이버시 스토리와 OS가 제공하는 가용성 스토리를 잃습니다. 결정 트리가 확장됩니다. 클라우드 런타임 LLM는 온디바이스 모델의 한도를 진정으로 초과하는 기능(대규모 컨텍스트, 프런티어 추론, 대규모 멀티모달)에 적합하며, 사용자의 프라이버시 기대에 (투명한 공개와 함께) 수용 가능해야 합니다. Foundation Models는 워크로드가 맞을 때의 기본값이며, 클라우드는 맞지 않을 때의 에스컬레이션입니다.

참고 자료