Apple Foundation Models를 통해 Claude와 Gemini를 동일한 Swift API로 호출할 수 있다

WWDC 2026을 전하는 뉴스 헤드라인은 대부분 "iPhone에서 Claude를 사용할 수 있게 된다"였다. 하지만 현업에서 앱에 LLM을 통합하고 있는 입장에서 보면, 진짜 중요한 지점은 그곳이 아니다. Apple은 온디바이스 모델 (On-device model)용으로 2025년에 출시한 Foundation Models 프레임워크를 프로바이더 비의존적 (Provider-independent) 추상 레이어로 재설계해 왔다. 앱은 단 하나의 Swift API에 대해 코드를 작성하고, 그 이면에서 Apple 자체 모델, Private Cloud Compute (PCC) 상의 클라우드 모델, Claude나 Gemini와 같은 프론티어 모델 (Frontier model)을 교체한다. 데이터베이스의 JDBC나 ORM에 해당하는 것이 드디어 LLM 계층으로 내려왔다고 이해하는 것이 가장 적절하다.

Apple 뉴스룸은 개발자가 "Claude나 Gemini, 혹은 새로운 language model 프로토콜을 구현한 임의의 프로바이더"의 모델을 선택할 수 있다고 명시하고 있다. Foundation Models 자체는 이미지 입력, 서버 모델, 커스텀 스킬 (Custom skill)에 대응하는 단일 네이티브 Swift API로 재정의되었다.

[IMG:1]
a single native Swift API that supports more powerful on-device models with image input, support for server models, and the ability to build custom skills

핵심은 특정 모델명이 아니라 이 프로토콜이다. 어떤 프로바이더든 프로토콜을 준수하기만 하면 동일한 세션 로직의 이면에 삽입될 수 있다. 앱 측의 코드는 "모델에 질의한다"는 지점에서 멈추며, 어떤 백엔드가 응답할지는 설정과 라우팅 (Routing)의 문제가 된다. 모델 계층이 범용화(Commodity)되고, 선택은 실행 시점의 관심사로 이동한다는 방향성 그 자체다.

구체적인 Swift 호출 시그니처 (Signature)는 Apple의 세션 영상 "What's new in the Foundation Models framework (Session 241)"에 집약되어 있다. 프로토콜의 메서드 이름까지 포함하여 정확하게 확인하고 싶은 사람은 그 영상을 보는 것이 빠르다.

"동일한 API로 호출할 수 있다"는 편리하지만, 추상화에는 반드시 누수(Leak)가 발생한다. 요청(Request)마다 온디바이스/PCC/프론티어를 전환한다는 것은 레이턴시 (Latency), 비용, 컨텍스트 길이 (Context length), 도달 가능한 능력이 크게 다른 대상들을 동일한 호출구 너머에 나란히 세운다는 의미이기도 하다. 이 부분은 표로 정리해 둘 가치가 있다 (수치는 모델이나 플랜에 따라 변동되므로 성질의 비교에 그친다).

라우팅 대상	데이터 경로	비용 부담	주요 용도
온디바이스 모델	단말기 내에서 완결	없음	저레이턴시 · 오프라인 · 민감한 데이터
...	동일한 session

동일한 session 이면에서 이 정도로 성질이 변한다면, 프롬프트의 이식성 (Portability)은 거저 얻어지는 것이 아니다. Apple 자체 모델에 맞춰 작성한 지시 사항이 Claude나 Gemini에서 그대로 최적으로 작동한다는 보장은 없다. 추상 레이어가 숨겨주는 것은 "호출의 형태"이지 "모델별 특성"이 아니다. 이를 혼동하면 라우팅을 늘릴수록 프롬프트 분기가 늘어나는, 은근한 유지보수 비용 문제에 나중에 직면하게 된다.

교체는 정적인 빌드 시점 설정에 머물지 않는다. Dynamic Profiles는 진행 중인 세션 안에서 모델, 도구, 지시 사항 (Instructions)을 동적으로 교체하는 메커니즘으로 알려져 있다. 멀티 에이전트 (Multi-agent) 방식으로, 간단한 질문은 온디바이스에서 처리하고 복잡해지는 순간 프론티어 모델로 승격시키는 등의 제어를 동일 세션 내에서 작성할 수 있다.

혼동하기 쉽지만, Core AI는 이와는 별개의 새로운 프레임워크다. Apple은 이를 "디바이스에서 모델을 구동하는 최선의 방법"이라고 설명하며, Apple Silicon의 유니파이드 메모리 (Unified memory)와 Neural Engine에 최적화된 아키텍처를 통해 풀스케일 LLM을 로컬에 전개할 수 있다고 밝혔다. Foundation Models가 "어떤 모델을 호출할 것인가"의 레이어라면, Core AI는 "자체 모델을 디바이스에서 어떻게 실행할 것인가"의 레이어라고 역할을 나누어 이해하는 것이 옳다.

게다가 모델에서 Vision 프레임워크의 도구(OCR이나 바코드 읽기)를 직접 호출할 수 있다는 점과, AI 기능의 동작을 검증하는 Evaluations 프레임워크가 준비되었다는 점도 실무적인 관점에서 꽤 큰 업데이트다. 유닛 테스트(Unit Test)로는 포착하기 어려운 '동적인 조건에서의 동작'을 확인할 수 있는 수단이 표준으로 제공된 것은 솔직히 매우 고무적이다.

Google도 같은 날 수신 측의 대응을 내놓았다. iOS 27 세대 이후부터 Foundation Models 프레임워크를 통해 클라우드의 Gemini를 호출할 수 있게 되며, 그 구현은 Firebase Apple SDK (Firebase AI Logic)를 통해 제공된다. 개인 개발자는 Google AI Studio에서 취득한 Gemini API 키를 그대로 사용할 수 있고, 엔터프라이즈는 Gemini Enterprise Agent Platform을 통해 전용 쿼터(Quota)나 데이터 프라이버시 제어권을 얻는 이중 구조를 취하고 있다. 나아가 Apple 자신의 온디바이스 모델이 "Google과의 협업을 통해 커스텀 빌드되었다"라고 명시된 점도 간과할 수 없다. 플랫폼 제공자(Platformer)들이 현재의 모델과 SDK 양쪽 모두에서 협력하고 있는 것이다.

지엽적이지만 효과적인 부분은 과금 체계다. App Store Small Business Program의 멤버이면서 누적 최초 다운로드 수가 200만 미만인 앱은, 차세대 Apple Foundation Models를 Private Cloud Compute 상에서 클라우드 API 비용 없이 사용할 수 있다. 기기에서는 너무 무거운 추론을 기밀성을 유지한 채 무료로 돌릴 수 있는 프레임이 소규모 개발자들을 향해 열리는 것이다.

이는 강력한 배포 레버(Lever)라고 생각한다. 프라이버시 보호를 내세운 클라우드 추론을 무료로 제공한다면, 초기 비용에 민감한 개인 및 소규모 팀일수록 더 강력하게 끌어당길 수 있다. 동시에 이는 Apple 플랫폼으로의 락인(Lock-in)을 "개방"이라는 단어로 포장한 전략이기도 하다. 프로토콜을 공개하여 타사 모델을 수용하는 개방성과, 무료 프레임을 통해 자사 클라우드에 머물게 하는 인력이 하나의 발표 안에 공존하고 있다. 어느 한쪽 측면만 보고 평가한다면 판단을 그르칠 것이다.

총체적으로 이번 발표의 본질은 "iPhone에 Claude가 왔다"는 사실이 아니라, Apple이 모델 선택을 OS/SDK 레벨의 추상화로 밀어 올렸다는 점이다. 모델을 교체 가능한 부품으로 취급하는 설계에는 찬성하지만, 교체되는 것은 연결의 형태일 뿐 프롬프트와 평가까지 자동으로 이식되는 것은 아니다. 구현하는 측의 업무는 API가 하나로 줄어든 만큼, 라우팅 방침과 모델별 동작 검증으로 옮겨가게 될 것이다.