Apple Foundation Models에 Claude 탑재하기

 (platform.claude.com)
5P by GN⁺ | ★ favorite | 댓글 1개
  • Apple의 Foundation Models 프레임워크에 Claude를 서버 사이드 모델로 연결하는 Swift 패키지로, 개발자가 Apple 온디바이스 모델과 똑같은 코드 경로로 Claude를 호출할 수 있게 됨
  • WWDC 2026에서 Apple이 도입한 LanguageModel 프로토콜 덕분에, 온디바이스 모델로 프로토타이핑한 뒤 복잡한 작업만 클라우드 모델로 넘기는 하이브리드 구조가 표준 API 하나로 가능해짐
  • 핵심은 프로바이더 교체 가능성 - 세션 로직을 건드리지 않고 Swift Package 의존성만 바꿔 Apple·Claude·Gemini 사이를 오갈 수 있다는 점
  • Anthropic이 Apache 2.0으로 공개한 이 패키지는 그 "어떤 백엔드든 연결 가능하다"는 구상의 실제로 동작하는 첫 사례
  • 요청이 앱에서 Claude API로 직접 가고 Apple은 경로에 없어 프롬프트·응답을 보지 못하며, 비용도 Anthropic 계정에 직접 청구

왜 중요한가

  • iOS 앱에 언어 모델을 붙이려면 그동안 별도 클라우드 API 가입, 키 관리, 토큰당 과금, 모든 프롬프트의 기기 외부 전송이 필요했는데, WWDC 2026에서 Apple이 이 오랜 불편을 해결
  • Foundation Models 프레임워크가 Apple Intelligence의 온디바이스 모델, Private Cloud Compute, Claude·Gemini 같은 서드파티 클라우드를 하나의 네이티브 Swift API로 모두 호출하는 형태로 확장
  • Anthropic은 이 새 프로토콜을 구현한 Swift 패키지를 공개함. Claude를 Apple 온디바이스 모델에서 넘겨받아 더 복잡한 워크플로를 처리하도록 호출하는 용도

개발자에게 달라지는 점

  • 코드 변경 없는 프로바이더 전환

    • Apple 온디바이스 모델로 앱을 프로토타이핑한 뒤, 복잡한 쿼리를 Google Gemini나 Anthropic Claude로 라우팅하거나 그 사이를 전환하는 작업을, Swift Package Manager 의존성만 갱신하면 세션 로직이나 나머지 앱 코드 변경 없이 수행
    • 온디바이스 모델은 요약·추출 같은 빠르고 로컬한 작업에, 멀티스텝 추론·코드 생성·웹 검색·코드 실행이 필요할 때만 Claude로 핸드오프
    • 두 경우 모두 동일한 LanguageModelSession API라 model: 인자 교체만으로 전환

  • 타입 기반 핸드오프

    • 프로젝트에 추가하고 Anthropic API 키로 로그인한 뒤, Apple 온디바이스 모델의 타입화된 출력을 Claude 요청으로 전달하면, 패키지가 스트리밍·도구 호출·구조화 응답을 다시 SwiftUI 뷰로 처리
    • 가이드 생성을 통해 단 세 줄의 코드만으로 타입화된 Swift 값을 반환할 만큼 사용이 간단

프라이버시·비용 구조

  • 요청이 앱에서 Claude API로 직접 전달되어 Apple은 요청 경로에 없으며 프롬프트·응답을 보지 못함
  • 사용량은 표준 API 가격으로 Anthropic 계정에 직접 청구
  • 앱이 세션마다 Claude를 쓸지 Apple 온디바이스 모델을 쓸지 직접 결정

더 큰 그림

  • Apple은 2025년에 출시한 온디바이스 모델용 네이티브 Swift API인 Foundation Models 프레임워크를 올여름 오픈소스로 전환할 예정이며, 새 LanguageModel 프로토콜로 Apple 자체 모델이든 원격 프로바이더든 거의 모든 모델이 단일 Swift API 뒤에서 LanguageModelSession을 구동
  • 이 "어떤 백엔드든 연결 가능하다"의 실례로 Anthropic의 ClaudeForFoundationModels가 어댑터 패턴을 구체화
  • Apple은 Dynamic Profiles 시스템으로 앱이 세션 중간에 모델·도구·지시를 교체할 수 있게 하고, 이를 멀티 에이전트 워크플로의 토대로 포지셔닝
  • 단, 이 통합은 iOS·iPadOS·macOS·visionOS·watchOS 27 및 Xcode 27을 요구하는 베타 단계로, 정식 출시 전 API 변경 가능성 있음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • Apple이 사용자 경험은 통제하면서 LLM을 범용재로 만들고 있음
    하드웨어 회사답게 AI 사용에 가장 좋은 기계를 계속 팔겠다는 전략이고, 잘한 선택으로 보임

    • Benedict Evans가 결국 맞았을 수도 있음. 프런티어 모델은 점점 90년대 통신사처럼 보임
      인프라에 수십억 달러를 투자하지만, 가치는 더 위쪽 계층의 다른 회사들이 가져가는 구조임
    • 사용자 경험 통제라는 말과는 조금 별개지만, 이게 AI의 가장 마음에 드는 결과임. 수십 년 동안 회사들이 자기 서비스를 벽으로 둘러치고 형편없는 UI를 강요했는데, 지난 12개월 사이 갑자기 모든 것에 MCP가 생기고 명령줄 채팅 인터페이스로 쓸 수 있게 됨
      적응하지 않는 회사는 사람들이 만든 AI 기반 DIY 웹 스크래퍼에 두들겨 맞다가 결국 굴복할 수밖에 없음
    • 여기서 말하는 AI 사용에 가장 좋은 기계가 맞는 표현인지 모르겠음. 이 모델들은 여전히 서버 쪽에서 도는 것 아닌가
    • AI가 결국 운영체제 수준에 내장될 거라는 건 몇 년 전부터 분명했음. Apple도 Apple Intelligence를 처음 공개했을 때 이미 그걸 인식하고 있었음
      LLM을 범용재로 만든다든지 하는 표현은 맞겠지만, 이건 이미 몇 년째 다듬어 온 사용자-facing 기능임
    • 이제 하드웨어만 범용재로 만들면 됨

  • Apple's Foundation Models framework에서 Claude를 서버 측 언어 모델로 쓸 수 있게 해주는 Swift 패키지라니, 반대 방향을 기대했음. Claude Code의 기존 기능들이 somehow 내 노트북의 Neural Engine에서 로컬로 돌기를 바랐음
    M2에 8GB RAM이면 헛된 꿈이지만, 잠깐 희망이 생겼음

    • 이 WWDC 세션을 보면 됨. 당연히 프런티어 모델과 경쟁하진 못하고 8GB도 너무 작다고 보지만, Apple이 MLX + OpenCode를 시연하긴 했음
      https://developer.apple.com/videos/play/wwdc2026/232/
      https://www.youtube.com/watch?v=wykPErJ8M-8
    • OpenCode나 Pi를 SSD 스트리밍으로 쓰면 기술적으로는 모든 기능을 갖출 수 있음. 다만 견딜 수 없을 만큼 느릴 것임
    • 대부분의 프런티어 코딩 모델은 제 기능을 모두 쓰려면 300GB에서 1TB 정도가 필요해 보였음
    • Claude Code는 환경 변수를 통해 호환 API만 있으면 말 그대로 원하는 아무 엔드포인트나 질의하게 만들 수 있음
    • 클라우드가 실제로 사용자의 비공개 iCloud라면 괜찮을 것 같음. 사용자가 비용을 내고, 이미 iPhotos를 저장하는 Apple 서버 근처에서 실행된다면 아주 우아한 해법일 수 있음
      그런데 실제로는 어디에 호스팅되는지도 모를 Claude를 받게 됨. X-AI 데이터센터일 수도 있고, Amazon 어딘가일 수도 있고, 아무도 모름

  • 이건 Claude 전용이 아님. 개발자들은 Google의 서버 기반 Gemini 모델을 호출하는 앱도 만들 수 있음
    WWDC에서 Apple은 Foundation Models framework를 서드파티 클라우드 모델 제공자에게 열겠다고 발표했음. iOS 27, macOS 27, iPadOS 27, visionOS 27, watchOS 27부터 모델 제공자는 새 공개 LanguageModel 프로토콜을 구현해 모델 추론을 위한 공통 인터페이스를 제공할 수 있음. Google은 Firebase Apple SDK를 통해 Gemini 모델을 Foundation Models framework에서 쓸 수 있게 했음
    이로써 완전한 네이티브 개발 경험이 가능해짐. 클라우드 호스팅 Gemini 모델이 같은 API를 통해 Foundation Models framework에 직접 연결될 수 있고, 기기 내 Apple 모델과 클라우드 호스팅 Gemini 모델이 공통 API 표면 뒤에 놓이므로, 사용 사례에 맞춰 로컬 추론과 클라우드 추론을 쉽게 바꿀 수 있음
    https://blog.google/innovation-and-ai/technology/developers-...

    • 중요한 건 Apple이 OpenAI 호환 API를 language model protocol로 다시 이름 붙였다는 점이고, 그 끔찍하게 긴 표현에 저주받기 전에 모두 이쪽으로 빨리 뭉쳐야 함

  • Apple이 이런 추상화를 도입한 건 반갑지만, 주된 걱정은 로컬 모델 쪽임
    예를 들어 Gemma4를 쓰고 싶다고 해도, 사용자 관점에서 앱 10개가 같은 모델을 각각 내려받으면 휴대폰이 불필요하게 부풀어 오름
    Apple이 여러 앱이 같은 기기 내 모델을 쓸 수 있게 하는 방법을 제공했는지 아직 이해하지 못했음. 까다로운 네임스페이스나 권한 꼼수 없이 가능해야 함
    그런 걸 시사하는 내용은 못 봤음

    • Apple이 피하려는 게 바로 그 부분이라고 봄. 기기 내 지능이 필요하면 “이미 기기에 있는 모델이 최고”라는 식으로 제안했고, 더 구체적인 게 필요하면 어댑터, 즉 파인튜닝/LoRA가 최선이라는 입장임
      기기 내 모델이 한참 뒤처졌을 때는 틀렸지만, 장기적으로는 여전히 맞을 수도 있음
      내가 쓰는 여러 앱이 Gemma 4 E4B를 필요로 할 수 있지만, 앱은 수십 개를 쓰고 개발자들은 수백 개 모델 중 고를 수 있음. 공유 캐시가 겹치는 경우에는 용량을 조금 줄여주겠지만 핵심 문제는 남음. 각 앱이 모델을 고르면 디스크와 메모리 스와핑이 폭발함
      기기 제조사가 기본값을 내장하는 편이 더 나을 가능성이 큼. 다른 모델 사용을 막자는 건 아니지만, 하나의 공유 기본값이 앱 99%에는 개발자와 사용자 경험 모두에서 최선일 수 있음
      메모리에 이미 올라와 있는 상태가 가장 큰 성능 향상이고, 기본 모델은 따뜻하게 유지될 가능성이 훨씬 큼
      “최고의 모델”은 대개 RAM과 연산량을 감안한 “이 기기에 가장 좋은 모델”임. 개발자는 모든 기기를 테스트할 수 없지만 Apple은 할 수 있고 할 것임
      각 모델은 하드웨어에 맞게 최적화되어야 함. ANE, Metal, CPU 중 어디서 무엇이 도는지가 중요하고, 기본 모델은 최적화됨
      맞춤 모델이 필요하면 LoRA가 아마 최선임. 30MB 정도이고 위 장점을 모두 누릴 수 있음
      기본값을 교체 가능하게 해야 한다고 할 수는 있지만, 그건 Apple보다는 Linux식 이상에 가까워서 실제로 보게 될지는 의문임. 게다가 실제 단점도 있음. 의도했든 아니든 프롬프트는 개발 대상 모델에 맞춰 최적화되기 때문에, 기본 시스템 모델을 바꾸면 모든 앱 품질이 나빠질 수 있음
    • Apple이 범용 고유 모델 ID 프로토콜과 공유 저장 공간을 제공해 개발자들이 모델을 등록하게 할 좋은 기회임
    • “Bring an LLM provider to the Foundation Models framework”를 보면 됨
      https://developer.apple.com/videos/play/wwdc2026/339
    • 앱들은 같은 프레임워크와 API로 시스템이 제공하는 기기 내 모델을 쓸 수 있음. 하지만 앱 간 맞춤 모델 중복을 제거하는 장치는 없음
    • 그게 바로 foundation models임. Android의 AICore도 마찬가지로 내부적으로 Gemma를 쓰고, 앱이 자체 모델을 번들링하는 대신 LLM에 질의해 응답을 받게 됨

  • Apple이 개발자들에게 LLM을 자기 API 추상화 계층을 통해 쓰도록 유도하는 건가 싶음. 나중에 자체 LLM을 출시했을 때 개발자들이 매끄럽게 전환하도록 돕기 위한 것일 수도 있음
    Apple이 학습에 많은 돈을 쓰고 있고 Siri나 현재 Apple AI와 somehow 연관될 수 있다는 얘기를 들은 것 같음. 아니면 그냥 개발자 편의 기능인지, 다른 의도가 있는지 궁금함

    • Apple에는 사용자 데이터를 보호하기 위한 꽤 영리한 장치가 있음. 최근 앱 추적 관련 작업을 해야 했는데, 서드파티 플랫폼에 추적 이벤트를 보고하기 전에 SKAN과 차등 개인정보보호로 익명화된 코호트 안에 사용자 세부 정보를 숨기는 방식이 예상보다 잘 설계되어 있었음
      개인정보 보호를 중요하게 본다면 Apple이 중간에 들어오는 데 가치가 있음
    • 이건 reality/mac/iPad/watch/tv/iOS 27에 포함되는 새 프레임워크 지원임. 올해 말 오픈소스로 공개하겠다고 했으니, Swift를 백엔드에 배포하는 경우에도 활용할 수 있을 것으로 보임
      이 프레임워크의 핵심은 같은 API로 기기 내장 모델, Apple 호스팅 온라인 모델인 Private Cloud Computer, 또는 임의 호스팅 온라인 모델을 호출하는 자체 shim을 모두 대상으로 삼을 수 있게 해준다는 점임
      그러면 “이건 로컬 모델로 쓰고, 저건 Claude로 쓰고 싶다”는 식의 자체 추상화 계층을 만들거나 Anthropic/OpenAI API 통합을 직접 붙일 필요 없이, 시스템 API로 호출을 다른 모델/제공자 유형에 동적으로 라우팅할 수 있음
      도구 호출 같은 것을 한곳에서 추상화하고, 세션 중 제공자나 모델을 동적으로 바꿔도 같은 transcript를 이어가는 등 편의점과 특이점이 여럿 있음
    • 냉소적으로, 혹은 현실적으로 보면 이 추상화 계층은 실제 LLM을 다른 회사가 제공하더라도 사용자가 그 기능을 Apple Intelligence의 공로로 받아들이게 하려는 Apple식 방법 같음
    • 어두운 해석이지만 완전히 부당하진 않음. Apple이 다른 회사가 제공하는 모델에 대한 결제를 받기 쉬워지고, 원한다면 사용자가 서드파티 모델을 쓰는 방식에서 데이터를 모아 자체 모델 학습용 데이터셋을 만들 수도 있음
      이 API는 Apple 기기에서만 쓰이므로, iOS에서 제대로 동작하게 만들려면 개발자가 같은 시스템을 쓸 수 없게 시장을 쪼개고 사용자를 더 강하게 묶어두는 효과도 있음
    • 이 프레임워크를 통해 개발자가 이미 쓸 수 있는 기기 내 모델이 있음. Claude는 거기에 추가되는 하나의 모델일 뿐임

  • Apple이 자기 기기 내 모델이 더 좋아질 것에 대비하는 것으로 보이고, Gemini에 접근할 수 있게 된 걸 생각하면 말이 됨
    개발자들이 외부 LLM 호출 코드를 모두 이걸로 작성하면, Apple 모델이 더 유능해지고 더 많은 사용 사례를 포괄할 때 개별 호출 지점에서 쉽게 바꿀 수 있음. 그러면 앱 사용자 경험이 좋아지고, Apple이 수수료를 받지 못하는 개발자 청구 비용도 줄어듦

    • 달리 말하면 돈이 안 되므로 일어날 가능성이 낮음. Apple은 사람들이 구독할 수 있는 새 AI와 AI-lite 요금제를 만드는 편이 더 나을 것임
      Apple은 회사이고, 회사가 무엇을 신경 쓰는지는 모두 알기 때문에, 휴대폰에서 로컬 모델이 돌아가는 유토피아가 될 가능성은 낮아 보임
    • Gemini를 쓴다고 어떻게 기기 내 모델이 더 좋아지는지 모르겠음
    • 사용자 경험은 생태계 구축의 다른 말이고, 그게 Apple이 경쟁사보다 가장 잘하는 일임. 거기에 맞는 하드웨어까지 하는 것도 해가 되지 않음
      Microsoft와 Nvidia가 괜히 손잡는 게 아님

  • 이걸 사용자에게 배포할 소프트웨어에서 실제로 어떻게 쓰는지 궁금함. 사용자에게 직접 API 키를 만들고 입력하라고 하는 건 좋은 사용자 경험에는 너무 높은 장벽임

    • 더 큰 장벽은 일반 사용자, 즉 개발자가 아닌 사람에게 토큰 기반 가격을 납득시키는 것임
      “질문 하나에 얼마가 나갈지 모르는 돈을 내고, 원하는 답을 못 받을 수도 있으며, 더 쓰려면 돈을 더 내야 한다”는 구조는 도박꾼이 아닌 대부분에게 매력적이지 않음. 긴 대화 끝의 “고마워”가 문맥 때문에 비쌀 수 있다는 걸 설명하는 건 평균적인 사용자에게 더 받아들이기 어려움
      토큰 비용이 요요처럼 오르내리는 것도 도움이 안 됨. 일반 사용자는 고정 비용이 필요하고 AI 흐름을 계속 따라가느라 에너지를 쓰고 싶어 하지 않음. “지난달에는 내 구독이 훨씬 오래 갔는데” 같은 문제도 좋은 방향이 아님
      대부분의 경우 로컬 LLM이 미래라는 Apple 판단은 맞다고 봄
    • 정말 그렇다. allihat.com을 운영 중인데, 아직도 Claude와 통신하는 유일한 Safari 확장인 것 같고 수요도 꽤 있음. 그런데 사용자가 직접 망할 Claude API 키를 넣어야 함
      Anthropic 약관도 아직 완전히 이해가 안 됨. setup-token Set up a long-lived authentication token (requires Claude subscription) 같은 걸 입력할 수는 있는데, 함정처럼 보임. 누가 이걸 쓰는지 모르겠고, 어디든 쓰면 즉시 약관 위반이 되는 것 아닌가 싶음
      지금 allihat.com에서는 Claude 키를 쓰기 싫으면 로컬 Apple 모델을 쓰게 해뒀고, 유료 사용자 전환율이 3배 정도 올랐음. 하지만 당연히 Claude의 대체품은 아님. Apple이 Claude 프록시를 대신 해주는 어떤 장치를 만들어주길 바랐음. 나도 Claude API 사용량을 관리하려고 내 서버로 프록시할 필요가 없게 말임
    • 프로덕션에서는 .proxied로 요청을 자체 백엔드를 통해 라우팅하라고 되어 있음
      Apple은 다운로드 200만 미만 개발자에게 자사 서버를 통한 무료 AI 모델을 제공하고 있음 https://techcrunch.com/2026/06/08/apple-bets-cheaper-ai-will...
    • 전과 같은 방식, 즉 요청을 자체 백엔드로 프록시하면 됨
    • 사용자가 API 키를 주는 게 아님. 문서에 백엔드 프록시 설정 방법이 나와 있음

  • “요청은 앱에서 Claude API로 직접 가며, Apple은 요청 경로에 없고 프롬프트나 응답을 보지 않는다”는 문구는 개발자 관점이라는 건 알겠음
    하지만 소비자 입장에서는 그냥 웃김

    • 왜?

  • Microsoft는 먼저 Copilot 약관에 “Copilot은 오락 목적으로만 제공된다”고 넣고, Excel용 Copilot에도 “정확성이나 재현성이 필요한 작업, 법적·규제·컴플라이언스 영향이 있는 작업에는 COPILOT 사용을 피하라”는 경고를 넣으면서 판을 깼음
    이어 Apple은 경쟁 LLM을 만들려고 수십억~수천억 달러를 투자하지 않으며 조용히 참여를 거부하고 있음. 물론 순진한 사람들을 위해 Claude를 재판매하거나 Gemini를 활용하긴 하지만, Apple은 상황을 알고 있음
    https://www.microsoft.com/en-us/microsoft-copilot/for-indivi...
    https://support.microsoft.com/en-US/Excel/copilot-function

  • 코딩 에이전트 자체가 이미 강제로 얹힌 계층인데, 이제 계층을 하나 더 추가하는 건가 싶음. 코딩 에이전트는 90년대 인력파견업체의 벤더 관리자 같을 때가 많음
    고객에게 하늘 아래 모든 걸 약속하고, 불쌍한 계약자를 닦달해 납품하게 만드는 식임. 코딩 에이전트는 인력파견업체가 고객에게 청구한 돈과 계약자에게 준 돈의 차이처럼 토큰을 10배 더 먹음. 간단한 테스트로, 코딩 에이전트를 통하면 모델이 문맥 길이를 초과하는 같은 작업이 직접 프롬프트하면 잘 돌아감
    계층은 사치이고, 통제와 투명성을 없앰

    • 코딩 에이전트를 만들 때는 이걸 쓰지 않을 것임
답변달기