iPhone 앱에 AI를 통합할 때, 지금까지는 번거로운 이지선다(二択)가 있었다. 기기 내에서 완결되는 Apple의 온디바이스 모델(On-device model)은 빠르고 프라이빗하지만, 크기가 작아 무거운 추론에는 적합하지 않다. 그렇다고 클라우드의 Claude나 Gemini를 사용하면, 각 사의 SDK마다 다른 요청 형식과 응답 형식을 익혀야 하며, 프로바이더를 교체할 때마다 앱의 로직을 다시 작성해야 하는 상황에 처하게 된다.

WWDC 2026에서 Apple이 도입한 LanguageModel

프로토콜은 이 이지선다를 "하나의 API로 양쪽 모두" 가능하게 바꾼다. 온디바이스 모델도 Claude도 Gemini도, LanguageModelSession이라는 동일한 입구 뒤에 끼워 넣을 수 있게 되었다. 실제로 7월에 들어서 Anthropic과 Google 양측 모두 대응 패키지를 공개했으므로, 코드를 곁들여 내용을 살펴보자.

요점은 앱 측에서 다루는 코드가 모델을 바꿔도 거의 동작하지 않는다는 점에 있다. Apple의 온디바이스 모델을 사용할 때의 전형적인 작성 방식은 다음과 같다.

import FoundationModels
let model = SystemLanguageModel()
let session = LanguageModelSession(model: model)
...

Claude로 전환하고 싶다면, Anthropic의 ClaudeForFoundationModels (Apache 2.0, 현재 0.1.0 베타)를 추가하고, model에 전달하는 인스턴스를 교체하기만 하면 된다.

import FoundationModels
import ClaudeForFoundationModels
let model = ClaudeLanguageModel(
...

Gemini 측도 Google이 Firebase AI Logic을 경유하는 대응책을 내놓고 있다. 패키지가 바뀌어도 LanguageModelSession을 만든 이후의 작성 방식은 공통적이다.

import FoundationModels
import FirebaseAILogic
let ai = FirebaseAI.firebaseAI()
...

respond(to:)의 스트리밍 버전인 streamResponse(to:), @Generable을 붙인 타입으로 구조화된 출력(Structured output)을 받는 방식, Tool을 구현하여 디바이스 측에서 함수를 호출하게 하는 도구 이용(Tool use)까지, 세션 주변의 관례는 프로바이더를 불문하고 동일해진다. 즉, "평소에는 온디바이스, 무거운 작업 시에만 Claude로 승격"하는 에스컬레이션(Escalation) 방침을 인자 하나를 가진 분기문으로 구성할 수 있다. 이 점이 은근히 강력하다. 기존에는 이러한 승격을 위해 코드 경로를 두 개 가져가야만 했다.

"동일한 API로 교체된다"는 것을 성립시키는 메커니즘은 WWDC 세션 339에서 설명되어 있다. 프로바이더가 실제로 구현하는 것은 사실 두 개의 프로토콜이다. LanguageModel은 자신이 무엇을 할 수 있는지(capabilities)와 실행기(Executor)의 구성(executorConfiguration)을 선언할 뿐인 얇은 계층이다. 실제 생성은 LanguageModelExecutor의 respond(to:model:streamingInto:)가 담당한다.

흥미로운 점은 이 Executor가 스트림으로 흘려보내는 이벤트의 순서가 정해져 있다는 것이다. 먼저 메타데이터(모델 ID나 요청 ID), 다음으로 입력 토큰 수 등의 사용량을 "생성이 시작되기 전에" 보고하고, 그 후 텍스트의 델타(Delta)를 흘려보낸다. 프레임워크는 Configuration을 키(Key)로 하여 Executor를 캐싱하므로, 동일한 설정의 모델을 여러 개 만들어도 실체는 공유된다. 앱 개발자는 이 2개 계층을 의식하지 않고 LanguageModel과 세션만 보면 된다는 것이 설계의 의도다.

주의하지 않으면 사고가 날 수 있는 지점이 있다. auth: .apiKey(...)는 개발 전용이다. Anthropic의 문서에서는 명확하게 경고하고 있다.

A key bundled into an app is extractable from the shipping binary, and anyone who extracts it can make requests billed to your account.
(앱에 포함된 키는 배포 바이너리에서 추출될 수 있으며, 이를 추출한 누구라도 귀하의 계정으로 청구되는 요청을 보낼 수 있습니다.)

API 키를 내장한 앱은 배포 바이너리로부터 키가 탈취되어, 귀하의 비용으로 타인이 사용할 수 있다. 실제 서비스(Production)에서는 자체 백엔드를 거치는 .proxied 방식을 사용해야 한다.

를 사용하며, 키(Key)는 서버 측에서 부여한다. Gemini 측도 Firebase App Check를 통해 앱을 보호한다는 전제하에 작동한다. 요컨대 두 경로 모두 "클라이언트에 키를 두지 않는다"가 출시 조건이 된다.

서버 측 도구(Tool)를 다루는 방식에도 차이가 있다. Claude의 경우, Anthropic의 인프라 위에서 실행되는 웹 검색(Web Search)이나 코드 실행(Code Execution)을 세션(Session)이 아닌 모델(Model) 측에 설정한다.

let model = ClaudeLanguageModel(
name: .sonnet5,
auth: auth,
...

세 가지를 비교하면 역할 분담은 다음과 같다.

구분	온디바이스 (On-device)	Claude (Anthropic)	Gemini (Firebase)
추가 패키지	불필요 (표준)	ClaudeForFoundationModels	FirebaseAILogic
...

이는 주의가 필요한 단서 조항이 붙은 기술이다. 전제가 되는 iOS 27은 아직 베타(Beta) 상태이며, Xcode도 베타다. Claude 측 패키지는 0.1.0 버전으로 GA(General Availability) 전까지 API가 변경될 수 있으며, 베타 기간 중에는 외부 PR(Pull Request)을 받지 않는다. 프롬프트 캐시(Prompt Cache)의 세밀한 제어, 중단 시퀀스(Stop Sequence), 배치 처리(Batch Processing), 토큰 카운트(Token Count)와 같은 Messages API의 기능들은 이 프로토콜을 통해서는 제공되지 않으므로, 무거운 백엔드 처리를 통째로 갈아끼우는 교체 방식은 아니다. 어디까지나 온디바이스 앱(On-device App)의 UX를 끌어올리는 계층이라고 명확히 정의하는 것이 옳다.

그럼에도 불구하고, Apple이 모델 자체는 외부에 맡기면서 LanguageModelSession이라는 API의 표면만 직접 장악했다는 구도는 영리하다. 엔지니어 관점에서 본 진정한 가치는 "iOS에서 Claude가 동작한다"는 것이 아니다. API를 직접 호출하는 방식은 이전부터 가능했다. 그게 아니라, 트랜스크립트(Transcript), 구조화된 출력(Structured Output), 도구 호출(Tool Calling)과 같은 추상화(Abstraction)가 프로바이더(Provider)를 가로질러 통일되었고, 모델 선택이 앱 설계의 외부 관심사가 되었다는 점이다. 벤더 락인(Vendor Lock-in)을 한 단계 벗어날 수 있게 된 것이다. iOS 27이 정식 출시될 무렵, 이 위에서 어떤 "온디바이스 기본 + 필요 시 클라우드" 패턴이 정착될지는 지금 미리 시도해 볼 가치가 있다.