Foundation Models 온디바이스 LLM: Tool 프로토콜

장르: frontier-essay. 이 글은 Apple이 WWDC 2025에서 출시한 온디바이스 LLM 계약을 명명하고 라우팅 질문을 살펴봅니다. 언제 LanguageModelSession이 정답이고, 언제 AppIntent이며, 언제 MCP이고, 언제 그 어느 것도 아닌지를 다룹니다.

iOS 26은 모든 Apple Intelligence 호환 기기에 30억 파라미터 언어 모델을 탑재합니다.¹ Apple은 이 프레임워크를 Foundation Models라고 부릅니다. 프레임워크는 로컬에서 동작합니다. 추론은 Apple 실리콘에 최적화되어 있으며 온디바이스로 실행되고, 네트워크는 호출 경로에 포함되지 않습니다. 모델은 SystemLanguageModel.default에 위치하며, 앱은 LanguageModelSession을 받고, 그 세션이 유용한 작업을 수행하도록 만드는 타입화된 표면이 바로 Tool 프로토콜입니다.

Tool 프로토콜은 앱 개발자에게 가장 중요한 부분입니다. 이것이 없으면 온디바이스 LLM은 앱의 데이터, 사용자의 데이터, 또는 시스템의 나머지 부분과 연결되지 않은 채팅 완성 엔드포인트일 뿐입니다. 이것이 있으면 모델은 타입화된 Swift 함수를 호출하고, 타입화된 결과를 받고, 다음 턴에서 그 답변에 대해 추론할 수 있습니다. 도구로 증강된 온디바이스 생성이 이 프레임워크의 실제 역량입니다. 채팅 표면은 데모일 뿐입니다.

TL;DR

• Foundation Models는 모든 Apple Intelligence 호환 기기에 SystemLanguageModel.default로 30억 파라미터 LLM을 제공합니다. 모델은 로컬이며, 추론은 Apple 실리콘에 최적화되어 온디바이스로 실행되고, 네트워크는 호출 경로 밖에 있습니다.
• Tool 프로토콜은 모델과 앱 사이의 계약입니다. 도구는 타입화된 Arguments를 선언하고, 타입화된 Output을 반환하며, 생성 시점에 LanguageModelSession에 바인딩됩니다.
• Generable과 Guide 어노테이션은 모델이 단순한 문자열이 아니라 타입화된 Swift 값을 직접 생성하도록 합니다. 디코더는 프레임워크의 일부이지 여러분의 코드가 아닙니다.
• Foundation Models, App Intents, MCP 사이의 라우팅 규칙은 누가, 어디서 모델을 실행하느냐입니다. Foundation Models = 여러분의 앱이 온디바이스로 모델을 실행. App Intents = Apple Intelligence가 온디바이스로 모델을 실행하고 앱으로 라우팅. MCP = 외부 호스트가 원하는 곳에서 모델을 실행하고 도구 서버를 통해 앱에 접근.

프레임워크가 실제로 제공하는 것

세 가지 기본 요소가 프레임워크를 구성합니다. 모델, 세션, 그리고 도구입니다.²

SystemLanguageModel. 온디바이스 파운데이션 모델에 대한 참조입니다. 기본 인스턴스는 사용자 기기에 바인딩되어 있고, Apple Intelligence 호환 하드웨어에서 사용 가능하며, 앱이 런타임에 모델 사용 가능 여부를 결정하기 위해 읽는 역량 검사를 노출합니다. 프레임워크는 SystemLanguageModel(useCase:guardrails:), 커스텀 어댑터, GenerationOptions를 통한 구성을 지원하지만, OpenAI나 Anthropic에서 하듯이 임의의 클라우드 모델 ID를 선택하지는 않습니다. Apple은 OS 릴리스에 따라 온디바이스 모델을 배포하고 업데이트하며, 프레임워크는 현재 설치된 버전을 여러분에게 전달합니다.

LanguageModelSession. 호출 간에 대화 상태를 유지하는 상태 저장 객체입니다. 세션은 생성 시 시스템 프롬프트를 받고, 시간이 지남에 따라 사용자/어시스턴트 턴을 누적하며, 응답을 생성하기 위한 비동기 메서드를 노출합니다. 세션은 가볍게 생성하고 폐기할 수 있습니다. 앱당 하나가 아니라 작업당 하나씩 생성합니다. 명상 타이머는 “내 지난 7일간의 수련을 요약해 줘”를 위한 세션을 만들고, 레시피 앱은 “이걸 4인분 대신 2인분으로 변환해 줘”를 위한 다른 세션을 만듭니다.

Tool (프로토콜). Arguments 타입, Output 타입, 그리고 비동기 call(arguments:) 함수를 선언하는 Swift 프로토콜입니다. 도구는 생성 시점에 세션에 바인딩됩니다(LanguageModelSession(tools: [...], instructions: ...)). 모델이 도구가 필요하다고 판단하면 구조화된 호출을 발행하고, 프레임워크가 인수를 디코딩하고, 도구를 실행하고, 결과를 인코딩한 다음, 다음 턴을 위해 세션에 다시 입력합니다. 모델은 Swift를 보지 않으며, 마샬링은 프레임워크가 처리합니다.

Tool 프로토콜의 형태를 압축하면 다음과 같습니다.

import FoundationModels

struct WaterEntryLookup: Tool {
    let name = "lookup_water_entries"
    let description = "Look up water intake entries for a given date range."

    @Generable
    struct Arguments {
        @Guide(description: "Start date in ISO-8601 format")
        let startDate: String

        @Guide(description: "End date in ISO-8601 format")
        let endDate: String
    }

    func call(arguments: Arguments) async throws -> ToolOutput {
        let entries = try store.entries(
            from: ISO8601DateFormatter().date(from: arguments.startDate) ?? .now,
            to: ISO8601DateFormatter().date(from: arguments.endDate) ?? .now
        )
        return ToolOutput(GeneratedContent(properties: [
            "count": entries.count,
            "total_ml": entries.reduce(0) { $0 + $1.amountMl }
        ]))
    }
}

모델은 도구 설명과 JSON 형태의 인수 스키마를 봅니다. Swift 코드는 타입화된 입력과 타입화된 출력을 봅니다. 디코드/인코드 경계는 Apple이 소유하는 부분입니다.

Generable과 Guide: 파서 없는 타입화된 출력

도구 인수를 타입화하는 동일한 어노테이션 시스템은 모델이 타입화된 Swift 값을 직접 생성하도록 만드는 데도 사용됩니다.³ @Generable 구조체는 자신의 형태를 선언하고, 프레임워크는 모델의 출력이 그에 맞도록 제약합니다.

@Generable
struct PracticeSummary {
    @Guide(description: "Single-sentence headline summarizing the user's week")
    let headline: String

    @Guide(description: "Total practice duration this week in minutes")
    let totalMinutes: Int

    @Guide(description: "Three short observations as bullet points")
    let observations: [String]
}

let session = LanguageModelSession(instructions: "You are a meditation coach.")
let summary = try await session.respond(
    to: "Summarize this week of practice given the entries.",
    generating: PracticeSummary.self
)

모델은 PracticeSummary 값을 반환합니다. 코드에 JSON 파싱이 없고, “headline:”에 대한 문자열 매칭도 없으며, 모델이 잘못된 객체를 반환했을 때의 폴백도 없습니다. 프레임워크는 제약된 디코딩을 사용하여 모델의 토큰 단위 출력을 스키마와 구조적으로 일치하도록 유지하므로, 구조적으로 유효하지 않은 출력은 경계를 통과하지 못합니다.

Swift 타입화된 표면이 이 프레임워크를 클라우드 LLM SDK와 구별하는 지점입니다. 클라우드 SDK(OpenAI Structured Outputs, Anthropic tool use 등)도 제약된 디코딩을 지원하지만, 개발자가 받는 타입화된 값은 스키마에 대해 검증된 JSON 객체이고, 그 다음 별도의 단계로 Codable Swift 타입으로 디코딩됩니다. Foundation Models는 그 단계들을 하나로 통합합니다. @Generable 매크로와 프레임워크의 디코더가 타입화된 Swift 값을 직접 반환값으로 생성하며, 필드별 @Guide 어노테이션이 생성 제약에 의도를 담아 전달합니다. 출력이 타입화되어 있는 이유는 개발자가 Swift로 재구성한 JSON 사양이 아니라, Swift 스키마에 대해 생성 자체가 타입화되었기 때문입니다.

@Guide 어노테이션은 프롬프트에 직접 작성하지 않고도 모델에 필드별 의도를 전달하는 방법입니다. 생성된 설명은 생성 제약의 일부가 됩니다. 필드 수준 가이드는 프롬프트를 깔끔하게 유지하고 스키마를 데이터에 가깝게 둡니다.

라우팅 질문, 세 가지 방식

이제 Apple은 앱이 자신의 도메인을 언어 모델에 노출하는 데 사용할 수 있는 세 가지 프로토콜 표면을 제공합니다. 이들은 서로 다른 실행자로 라우팅됩니다.

Foundation Models (LanguageModelSession). 여러분의 앱이 온디바이스 모델을 로드하고 추론을 실행합니다. 세션이 호출할 수 있는 도구는 여러분 앱의 코드가 정의한 도구입니다. 모델은 절대 기기를 떠나지 않습니다. 사용자가 Siri를 통해 호출하지 않으며, 여러분 앱의 코드가 호출합니다. 사용 사례는 앱 내부입니다. LLM을 사용해 한 주를 요약하는 명상 앱, 더 적은 인분으로 레시피를 조정하는 레시피 앱, “점심 때 한 잔 마셨어”를 구조화된 항목으로 변환하는 물 섭취 추적 앱이 그 예입니다.

App Intents. Apple Intelligence가 사용자를 대신해 LLM을 실행하고(Apple의 1차 에이전트), 역량 호출을 여러분 앱의 AppIntent 타입으로 라우팅합니다. 여러분의 앱은 모델을 실행하지 않습니다. App Intents 프레임워크를 통해 타입화된 액션을 선언하면, Apple의 시스템 스택이 사용자 요청, Spotlight 쿼리, Siri 입력, 또는 단축어 오케스트레이션에 따라 언제 호출할지 결정합니다. 자세한 내용은 App Intents Are Apple’s New API to Your App에서 다룹니다.⁴

MCP. 외부 호스트(Claude Desktop, Claude Code, Cursor, ChatGPT)가 개발자가 선택한 모델을 실행합니다. 여러분의 앱은 호스트의 모델이 호출할 수 있는 서버를 노출합니다. 모델은 호스트가 실행하는 곳 어디에서나 실행되며, 도구 호출은 JSON-RPC 전송을 가로지릅니다. Two Agent Ecosystems, One Shopping List와 라우팅 질문 종합인 App Intents vs MCP에서 다룹니다.⁵

라우팅 결정은 결국 누가 에이전트인가로 귀결됩니다.

                  ┌──────────────────────────────────┐
                  │  Who is the language model?       │
                  └────┬─────────────┬─────────────┬──┘
                       │             │             │
              ┌────────┴────┐ ┌──────┴──────┐ ┌────┴──────┐
              │ Your app's  │ │   Apple     │ │  External │
              │ own use of  │ │ Intelligence│ │   host's  │
              │   LLM       │ │   agent     │ │   agent   │
              └──────┬──────┘ └──────┬──────┘ └────┬──────┘
                     │               │             │
                     ▼               ▼             ▼
              Foundation Models  App Intents     MCP
              + Tool protocol   + AppEntity    + tools/list
              (on-device, your  (system runs   (host runs
               app runs model)   the model)     the model)

사용자의 한 주를 요약하는 명상 앱은 Foundation Models를 사용합니다. 앱 자체가 모델을 호출하고 결과를 앱 내부에 표시하고 싶기 때문입니다. 같은 앱의 “5분 세션 기록하기” 역량은 Siri가 호출할 수 있도록 App Intents를 사용합니다. 같은 앱의 “내 마지막 명상 기록 항목 보여줘” 역량은 Claude Code 세션이 사용할 때 MCP을 사용합니다. 세 가지 다른 실행자, 세 가지 다른 의무, 그 아래에 공유된 하나의 도메인 레이어가 있습니다.

추론 예산: 프레임워크가 여러분에게 요구하는 것

LLM을 온디바이스로 실행하는 것은 무료가 아닙니다. Apple 실리콘이 추론을 처리하지만, 모델은 여전히 컨텍스트 윈도우, 토큰 예산, 그리고 기기에 따라 달라지는 벽시계 지연 시간을 가집니다. 세 가지 제약이 프레임워크로 설계하는 방식을 결정합니다.⁶

가용성은 기기별로 다릅니다. 모든 iOS 26 기기에 Apple Intelligence가 있는 것은 아닙니다. 구형 iPhone, 잠금된 기기, 사용자가 Apple Intelligence를 비활성화한 기기는 SystemLanguageModel.default.availability에서 사용 불가 상태를 반환합니다. 가용성을 확인하지 않고 LanguageModelSession을 호출하는 코드는 런타임에 생성 오류를 발생시킵니다. 올바른 패턴은 가용성 상태에 따라 UI를 미리 분기하고, 사용 불가 상태일 때 LLM 없는 경로를 제시하는 것입니다. 모델을 보장이 아닌 기능 플래그로 취급하세요.

지연 시간이 무시할 수 없습니다. iPhone 16 Pro의 첫 토큰 지연 시간은 앱 내 인터랙션에 사용할 만하지만, 더 긴 생성과 도구 호출 체인은 즉각적이지 않습니다. 클라우드 LLM 스트리밍에 사용되는 UI 패턴이 여기에서도 작동합니다. 메인 스레드를 차단하지 말고, 점진적 출력을 보여주고, 사용자가 생성 중에 다른 곳으로 이동하는 경우를 위해 설계하세요.

컨텍스트 윈도우가 클라우드보다 작습니다. 온디바이스 모델은 GPT-4 클래스 클라우드 모델보다 작은 컨텍스트 윈도우를 가집니다. 긴 문서는 요약이나 청킹이 필요합니다. 긴 대화 기록은 잘라내야 합니다. 큰 구조화된 페이로드를 반환하는 도구 출력은 다음 턴이 필요할 때 다시 가져올 수 있는 참조(ID, 키)를 반환해야 하지, 전체 페이로드를 인라인으로 반환해서는 안 됩니다.

제약 집합은 프론티어 클라우드 모델이 아니라 저사양 엣지 런타임을 위해 설계하는 것과 비슷합니다. 프레임워크의 어포던스는 더 즐겁게 만들지만, 기저의 물리적 한계는 움직이지 않습니다.

언제 Foundation Models를 선택할 것인가

이 프레임워크의 가장 강력한 적합 영역은 온디바이스, 저마찰 생성이 곧 제품인 경우입니다.

재포맷팅과 다시쓰기. 사용자의 자유 형식 메모를 구조화된 항목으로 바꾸고, 메시지 초안을 다듬고, 캡처된 녹취록을 요약합니다. 지연 시간 허용도는 보통이고, 데이터 민감도는 높으며, 클라우드 추론은 과합니다.

비공개 데이터에 대한 로컬 종합. 사용자의 운동 기록을 “이번 주” 요약으로 변환하는 운동 앱. 사용자의 지출 패턴을 설명하는 금융 앱. 한 분기의 항목 전반에 걸쳐 주제를 부각시키는 일기 앱. 데이터는 기기를 떠나지 않아야 하고, 답변은 앱 내부에 나타나야 하며, 프롬프트는 경계가 정해져 있어야 합니다.

앱 내부 자동화를 위한 가벼운 도구 호출. 사용자가 “화요일 명상 기록 보여줘”라고 말할 수 있게 하고, 도구를 사용해 기저 레코드를 가져온 다음 답변을 포맷하는 앱. 에이전트는 앱이고, 도구는 앱 자체의 데이터 레이어이며, 모델은 로컬입니다.

타입 일치 생성. 앱이 그렇지 않으면 JSON 파서나 문자열 템플릿을 직접 작성해야 하는 모든 곳에서, @Generable과 @Guide는 더 견고한 표면입니다.

언제 Foundation Models를 선택하지 말아야 하는가

이 프레임워크는 흔한 여러 경우에 잘못된 선택입니다.

사용자가 Siri에게 물어볼 만한 모든 것. “물 250ml 기록해 줘”, “5분 명상 시작해 줘”, “바나나를 목록에 추가해 줘”는 App Intents입니다. 실행자는 Apple Intelligence이고, 여러분의 앱은 목적지입니다. Foundation Models는 앱 내부 생성용이지, Siri 라우팅 액션용이 아닙니다. 같은 역량을 두 번 만들면(App Intent + 도구가 있는 LanguageModelSession), 사용자는 앱 내 화면이 아니라 Siri를 호출하기 때문에 App Intent가 이깁니다.

외부 LLM 에이전트가 주도해야 하는 모든 것. 여러분 앱의 도메인에 접근하는 Claude Code 세션은 MCP에 속합니다. 앱이 LLM을 실행하지 않으며, 호스트가 실행하고, 모델은 호스트가 둔 곳 어디에나 있습니다. Foundation Models는 외부 에이전트에 서비스를 제공할 수 없습니다.

큰 문서에 대한 무거운 추론. 온디바이스 모델은 작습니다. 200쪽 계약서, 긴 코드베이스 컨텍스트, 또는 많은 사진에 대한 다중 이미지 추론은 컨텍스트 윈도우와 파라미터 수가 워크로드와 일치하는 클라우드 추론(여러분 자신의 것이든 벤더의 것이든)에 속합니다. 프레임워크의 범위를 초과하는 작업은 구체적인 오류를 생성합니다. 컨텍스트 윈도우 초과, 가드레일 위반, 지원되지 않는 로케일 등입니다. 모델이 범위를 벗어난 작업을 처리하는 데 의존하는 흐름을 설계하기보다는 그러한 오류를 의도적으로 표면화하세요.

기기 간 및 사용자 간 워크플로. 온디바이스 모델은 앱이 세션에 전달하는 것에만 접근할 수 있습니다. 기기 간 동기화(Watch에서 iPhone으로의 타이머 상태), 사용자 간 협업(공유 목록, 공유 문서), 그리고 서버 측 조정의 이점을 누리는 모든 흐름에는 서버가 필요합니다. 모델은 네트워크 기본 요소가 아닙니다.

제 스택에서 다르게 만들 만한 것

이 프레임워크는 첫 번째 시도에서 잘못 이해하기 쉬운 특정 아키텍처 선택에 보상을 줍니다. 사용자가 앱 UI를 통해 호출하는 역량과 LLM이 도구로 소비하는 역량은 중복된 산문 경로가 아니어야 합니다.

명상 앱이 LLM으로 요약된 “주간 리뷰” 창을 추가할 수 있습니다. 단순한 빌드는 하나의 프롬프트입니다. “이번 주 사용자의 항목들이 여기 있습니다, 한 단락을 작성하세요.” 더 나은 빌드는 모델이 한 주에 무엇이 있었는지 알아야 할 때 호출할 수 있는 WeeklyEntries 도구를 정의하고, @Generable을 통해 구조화된 WeeklySummary 출력을 추가합니다. 첫 번째 빌드는 취약하고(모델이 호출마다 긴 항목 목록을 수용해야 함), 토큰 측면에서 비싸며, 구조화되지 않은 산문을 생성합니다. 두 번째는 견고하고(“무엇이 일어났는지”와 “그것에 대해 어떻게 말할지”를 도구 호출이 분리), 저렴하며(모델은 필요한 것만 가져옴), 구조화되어 있습니다(결과는 타입화된 Swift 값입니다).

이 패턴은 App Intents와 MCP과 깔끔하게 결합됩니다. 동일한 WeeklyEntries 쿼리는 AppIntent 파라미터 리졸버의 본문이자 MCP 도구 핸들러이기도 합니다. 하나의 Swift 함수, 세 가지 표면. 모델은 사용자가 호출하는 것과 동일한 함수를 호출합니다.

또 다른 아키텍처 결정은 도구 설명이 프롬프트의 일부라는 것입니다. 모델은 호출 여부와 시점을 결정하기 위해 Tool.description을 읽습니다. 설명을 미래의 기여자가 실제로 읽을 것이라고 기대하는 docstring처럼 다루세요. 모델이 그 미래의 기여자입니다.

iOS 26+의 Apple 스택에서 이 패턴이 의미하는 것

세 가지 핵심입니다.

1. 온디바이스 LLM은 백엔드가 아니라 런타임 기능입니다. 원격 서비스가 아니라, 컨텍스트 윈도우와 온디바이스 추론 예산을 가진 시스템 프레임워크처럼 다루세요. 아키텍처 결정은 가용성, 지연 시간, 컨텍스트 윈도우 규율, 그리고 구조화된 출력입니다.

2. Tool 프로토콜이 표면입니다. 도구가 없으면 모델은 여러분의 도메인과 연결되지 않은 채팅 완성 엔드포인트입니다. 도구가 있으면 모델은 앱 데이터에 대한 구조화된 쿼리 레이어가 됩니다.

3. Foundation Models, App Intents, MCP 사이의 라우팅 규칙은 “누가 모델을 실행하는가”입니다. 앱 내부 생성은 Foundation Models로 갑니다. Apple Intelligence 라우팅 역량은 App Intents로 갑니다. 외부 에이전트 역량은 MCP으로 갑니다. 동일한 Swift 도메인 함수가 세 가지 표면 모두에 의해 호출될 수 있습니다.

전체 Apple 생태계 클러스터: Apple Intelligence를 위한 타입화된 App Intents, 교차 LLM 에이전트를 위한 MCP 서버, 둘 사이의 라우팅 질문, 잠금 화면 상태 머신을 위한 Live Activities, 시각 레이어를 위한 Liquid Glass 패턴, 기기 간 도달을 위한 멀티 플랫폼 출시. 허브는 Apple Ecosystem Series에 있습니다. AI 에이전트가 있는 iOS의 더 넓은 맥락은 iOS Agent Development guide를 참조하세요.

FAQ

iOS 26의 Foundation Models 프레임워크란 무엇인가요?

Foundation Models는 iOS 26(및 iPadOS 26, macOS 26, visionOS 26)의 Apple Intelligence 호환 기기에 탑재되는 온디바이스 언어 모델에 접근하기 위한 Apple의 프레임워크입니다. 프레임워크는 SystemLanguageModel, LanguageModelSession, 그리고 Tool 프로토콜을 노출하여 앱이 네트워크 액세스 없이 타입화된 온디바이스 LLM 호출을 실행할 수 있게 합니다.

Tool 프로토콜은 어떻게 작동하나요?

Tool은 Arguments 구조체(@Generable과 @Guide로 어노테이션됨), 비동기 call(arguments:) 메서드, 그리고 모델이 호출 시점을 결정하는 데 사용하는 이름 + 설명을 선언하는 Swift 타입입니다. 도구는 생성 시점에 LanguageModelSession에 바인딩됩니다. 모델이 도구가 필요하다고 판단하면, 프레임워크는 인수를 디코딩하고, 호출을 실행하고, 타입화된 출력을 다시 세션에 입력합니다.

Foundation Models, App Intents, MCP의 차이는 무엇인가요?

Foundation Models는 여러분의 앱이 앱 내 생성을 위해 온디바이스에서 LLM을 실행하는 용도입니다. App Intents는 Apple Intelligence(시스템 에이전트)가 여러분 앱의 타입화된 역량을 호출하는 용도입니다. MCP은 외부 LLM 호스트(Claude, ChatGPT 등)가 JSON-RPC 전송을 통해 여러분 앱의 타입화된 도구를 호출하는 용도입니다. 세 프로토콜은 누가 모델을 실행하느냐에서 다릅니다. 동일한 Swift 도메인 함수가 셋 모두에 서비스를 제공할 수 있습니다.

Foundation Models가 MCP 도구를 호출할 수 있나요?

아니요. LanguageModelSession.tools는 MCP 도구 서버가 아니라 Apple의 Tool 프로토콜 준수자를 받습니다. 둘을 연결하려면 call 메서드가 MCP 클라이언트를 호출하는 Foundation Models Tool을 작성해야 합니다. Apple은 내장 어댑터를 제공하지 않았으며, 이 다리는 앱 측 코드가 됩니다.

온디바이스 모델이 프로덕션에 충분히 좋은가요?

프레임워크가 설계된 사용 사례(재포맷팅, 요약, 로컬 데이터에 대한 구조화된 생성, 가벼운 도구 호출)에는 그렇습니다. 큰 컨텍스트에 대한 프론티어 추론, 대규모 멀티모달 이해, 또는 교차 문서 추론에는 그렇지 않습니다. 온디바이스 모델은 클라우드 LLM보다 작은 컨텍스트 윈도우를 가진 30억 파라미터 모델입니다. 범위에 맞는 워크로드를 선택하세요.

References