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) 방침을 인자 하나를 가진 분기문으로 구성할 수 있다. 이 점이 은근히 강력하다. 기존에는 이러한 승격을 위해 코드 경로를 두 개 보유해야만 했다.

프로토콜은 2개 층으로 나뉘어 있다

"동일한 API로 교체된다"를 성립시키는 메커니즘은 WWDC 세션 339에서 설명되어 있다. 프로바이더가 실제로 구현하는 것은 사실 2개의 프로토콜이다. LanguageModel은 자신이 무엇을 할 수 있는지(capabilities)와 실행기 구성(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 키를 심은 앱은 배포된 바이너리로부터 키가 탈취되어, 당신의 비용으로 타인이 사용하게 된다. 프로덕션 환경에서는 자체 백엔드를 거치는 .proxied를 사용하고, 키는 서버 측에서 부여한다. Gemini 측도 Firebase App Check를 통해 앱을 보호한다는 전제하에 작동한다. 요컨대 어느 경로를 선택하든 "클라이언트에 키를 두지 않는다"가 출시 조건이 된다.

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

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

세 모델을 나란히 놓으면 역할 분담은 다음과 같다.

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

아직 0.1.0이지만, 나아가야 할 방향은 옳다

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

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

Discussion