Core ML vs MLX vs Foundation Models: 애플의 온디바이스 AI 스택 선택하기

애플은 이제 사용자의 하드웨어에서 모델을 실행하는 네 가지 방식을 제공하며, 잘못 고르면 전면 재작성이라는 대가를 치르게 됩니다. 이 글을 쓰고 있는 M2 Max에서 MLX는 fp16 행렬 연산으로 11.2 TFLOPS를 지속하고, 실측 통합 메모리 대역폭 351 GB/s로 데이터를 옮깁니다¹. 하지만 대부분의 앱에게 이 성능은 잘못된 선택입니다. 기본 내장된 Foundation Models 프레임워크가 Swift 여섯 줄로, 다운로드 용량 증가 0메가바이트로 같은 일을 해내기 때문입니다. 네 프레임워크는 경쟁 관계가 아닙니다. 하나의 질문에 대한 네 가지 다른 답입니다. 모델은 누구의 것이며, 실행은 누가 관리하는가?

TL;DR

• Foundation Models 가 기본값입니다. 애플의 온디바이스 약 3B 파라미터 LLM으로 작업을 처리할 수 있다면(요약, 추출, 분류, 구조화된 출력 생성, 직접 정의한 도구 호출), 모델 가중치를 하나도 배포하지 않고 추론 비용도 들이지 않으면서 OS 수준의 모델 업그레이드를 무료로 물려받습니다.²
• Core ML 은 자신의 학습된 모델을 앱 안에 담아 배포하기 위한 것입니다. Neural Engine 디스패치를 일급으로 지원하고, App Store에 적합한 패키징을 제공하며, 유연성을 내주는 대신 배터리 수명과 예측 가능성을 얻는 사전 컴파일 계약을 갖춘 유일한 경로입니다.³
• MLX 는 모델 자체가 제품일 때 쓰는 도구입니다. 연구, 파인튜닝, 오픈 웨이트 LLM 실행, 또는 텐서를 즉시 제어해야 하는 모든 워크로드가 여기에 해당합니다. 개발 머신과 Mac 앱을 위한 도구이지 iOS 배포 수단이 아닙니다.⁴
• Core AI (iOS 27)는 이 모든 것 아래에 새로 깔린 바닥입니다. NDArray 텐서와 명시적인 연산 유닛 지정을 갖춘 저수준 모델 실행 프레임워크로, 오늘날 Core ML을 텐서 런타임처럼 혹사하고 있는 팀을 위한 것입니다.
• 판단은 대개 질문 하나면 끝납니다. 내장 모델이면 Foundation Models, 자신의 모델을 iOS에서 돌린다면 Core ML, 자신의 모델을 자신의 Mac에서 돌린다면 MLX, iOS에서 텐서 수준의 제어가 필요하면 Core AI. 이 글의 나머지는 그 경험칙이 무너지는 20%의 사례를 다룹니다.

질문 뒤에 숨은 질문

제가 지켜본 “어떤 프레임워크인가” 논쟁은 모두 두 개의 축으로 수렴합니다. (각각에 대한 심층 분석은 따로 정리해 두었습니다. Foundation Models, Core ML, MLX, Core AI.)

첫 번째 축: 가중치는 누구의 것인가? 애플의 내장 모델인지, 직접 학습하거나 변환한 모델인지, 허브에서 받아온 오픈 웨이트인지입니다. Foundation Models가 실행하는 것은 언제나 애플의 모델뿐이며, 여기에 직접 만든 LoRA 방식 어댑터가 더해질 뿐입니다⁵. Core ML과 MLX가 실행하는 것은 언제나 사용자가 제공한 가중치뿐입니다. 이 사실 하나만으로 성능 이야기가 시작되기도 전에 선택지의 절반이 사라집니다.

두 번째 축: 실행은 누가 소유하는가? Foundation Models는 모든 것을 감춥니다. 텐서도, 연산 유닛도, 세션 객체 이상의 컨텍스트 윈도우 관리도 없습니다. Core ML은 대부분을 감춥니다. 컴파일된 .mlmodelc 를 넘기고 연산 유닛을 힌트로 알려주면 디스패치는 프레임워크가 결정합니다. MLX는 아무것도 감추지 않습니다. 배열 연산은 직접 작성하고, 지연 평가와 통합 메모리가 손에 쥔 도구가 됩니다. Core AI는 Core ML과 MLX 사이에 자리합니다. 텐서와 연산 유닛 지정은 명시적이지만, 실행은 애플이 관리합니다.

실제 기능을 이 두 축 위에 찍어 보면 프레임워크는 저절로 정해집니다.

Foundation Models: 0메가바이트 기본값

대부분의 팀이 가장 먼저 시도해야 할 프레임워크는 모델이 아예 필요 없는 쪽입니다. Foundation Models는 Apple Intelligence 뒤에 있는 온디바이스 LLM을 LanguageModelSession 을 통해 노출하는데, 결정적인 기능은 모델이 아닙니다. 바로 가이드 생성(guided generation) 입니다. Swift 구조체에 @Generable 을 붙이면 프레임워크가 디코딩을 제약해, 모델의 출력이 파싱하고 기도해야 하는 문자열이 아니라 바로 그 타입 이 됩니다.²

@Generable
struct Itinerary {
    let destination: String
    let days: Int
    @Guide(description: "Budget in USD") let budget: Double
}

let session = LanguageModelSession()
let itinerary = try await session.respond(
    to: "Weekend in Kyoto under $800",
    generating: Itinerary.self
).content

통합 작업은 이것이 전부입니다. 다운로드 단계도, 양자화 결정도, 발열을 따져야 할 일도 없습니다. OS가 모델을 스케줄링하고, 기기의 모든 앱이 그것을 공유하며, 릴리스마다 업그레이드됩니다. 도구 호출을 쓰면 직접 정의한 함수를 모델이 실행하게 할 수 있어, 서버 없이도 진정으로 에이전트다운 기능을 만들기에 충분합니다.²

제약은 대칭적입니다. 이 모델은 약 3B 파라미터의 제너럴리스트입니다. 요약하고, 추출하고, 분류하고, 구조화된 출력을 잘 흉내 내지만, 오픈 도메인 세계 지식이나 긴 컨텍스트의 문서 분석, 프런티어 모델이 해내는 일은 하지 못합니다. 내장 모델로 부족할 때 애플이 내놓은 답은 어댑터, 즉 애플의 툴킷으로 베이스 모델에 대해 학습시키는 LoRA 방식 파인튜닝입니다. 다만 어댑터는 하나의 약속입니다. 애플이 베이스 모델을 개정할 때마다 다시 학습시켜야 하기 때문입니다⁵. 세션 관리와 심사자들이 부딪히는 실패 모드를 포함한 전체 분해는 Foundation Models 심층 분석에 정리해 두었습니다.

선택 기준: 작업이 언어의 형태를 띠고, 내장 모델이 품질 기준을 넘어서며, 가중치를 하나도 배포하지 않는 것이 중요한 경우입니다. 여기에 해당하는 기능은 대부분의 팀이 짐작하는 것보다 훨씬 많으니, 아래의 어떤 선택지로 손을 뻗기 전에 먼저 시도해 보시기 바랍니다.

Core ML: 자신의 모델, 애플의 실행

Core ML은 다른 질문에 답합니다. 이미 모델이 있고(비전 분류기, 임베딩 모델, 음성 파이프라인, 증류된 LLM 등), 그것을 iOS 앱 안에서, 배터리로, App Store 용량 제한 안에서, 올해 안에 돌려야 하는 상황입니다.

계약은 사전 컴파일입니다. coremltools 로 가중치를 변환하면 모델이 .mlmodelc 로 컴파일되고, 런타임에 프레임워크가 Neural Engine, GPU, CPU 로 작업을 분배합니다. 이 목록에서 오늘날 iOS의 ANE를 내주는 것은 Core ML뿐입니다. 진짜 엔지니어링이 자리 잡은 곳은 변환 단계입니다. 연산자 커버리지, 양자화(팔레타이제이션, 선형 8/4비트, 희소성. coremltools 의 최적화 스택은 정말로 깊습니다⁶), 그리고 모델이 2와트로 돌지 8와트로 돌지를 결정하는 연산 유닛 힌트가 그것입니다. 실제 프로덕션에서 살아남는 패턴(디스패치 힌트, 지연 시간 예산, 양자화 사다리)은 Core ML 기둥 글에서 다룹니다.

Core ML이 하지 않는 일도 그만큼 중요합니다. 학습하지 않고, 파인튜닝하지 않으며, 그래프 중간의 텐서를 건드리게 해주지도 않습니다. 추론 전용 장치인 셈입니다. “내 그래프를 실행하면서 동시에 중간 결과도 들여다보고 싶다”는 팀들은 그동안 Core ML을 텐서 런타임으로 억지로 비틀어 왔습니다. 바로 그 뒤틀림을 흡수하기 위해 Core AI가 등장했습니다.

선택 기준: 가중치가 자신의 것이고, 대상이 iOS/iPadOS(또는 애플 플랫폼 전반)이며, 배터리와 용량과 ANE가 중요한 경우입니다. 다시 말해 이 플랫폼에서 배포된 커스텀 모델 기능의 거의 전부입니다.

MLX: Mac 안의 연구 머신

MLX는 이 목록에서 이질적인 존재입니다. OS 프레임워크가 아니라 애플 ML 연구 그룹이 만든 오픈소스 배열 프레임워크이기 때문입니다⁴. 생김새는 NumPy를 닮았고, 평가는 지연 방식이며, Apple silicon의 통합 메모리를 있는 그대로 하나의 기능으로 다룹니다. 호스트와 디바이스 사이의 복사가 없는데, 별도의 디바이스 메모리 자체가 없기 때문입니다.

이 머신에서 나온 수치가 그 주장을 구체적으로 만들어 줍니다. M2 Max는 아무런 튜닝 없이 MLX에서 4096×4096 fp16 행렬 곱 11.2 TFLOPS와 실측 스트리밍 대역폭 351 GB/s 를 지속합니다¹. 양자화된 30B 파라미터 오픈 웨이트 모델을 대화형으로 돌리고, 7B 모델을 LoRA로 하룻밤 만에 파인튜닝하며, 그러지 않았다면 클라우드 GPU를 빌려야 했을 학습 루프를 반복하기에 충분한 수치입니다. mlx-lm 생태계 덕분에 대부분의 오픈 모델은 pip install 과 다운로드 한 번이면 손에 들어옵니다.

경계 역시 그만큼 구체적입니다. Neural Engine은 쓸 수 없습니다. MLX가 프로그래밍하는 대상은 GPU(와 CPU)이지 ANE가 아닙니다. iOS 배포 서사도 없습니다. 기술적으로 끼워 넣을 수는 있지만, 가중치 배포와 발열, 심사 지침을 생각하면 잘못된 도구입니다. MLX는 자신의 Mac, 사용자의 Mac, 그리고 자신의 연구 루프를 위한 것입니다. 그리고 실행을 대신 관리해 주는 존재는 없습니다. 메모리 압박, 양자화 선택, 평가 스케줄링은 모두 자신의 몫입니다. “애플의 모델이 아니라 내 모델”이 그 소유 비용을 치를 만한 때가 언제인지는 MLX 기둥 글에서 다룹니다.

선택 기준: 학습이나 파인튜닝을 하고 있거나, 오픈 웨이트 LLM을 로컬에서 돌리고 있거나, 모델 제어 자체가 제품이 되는 Mac 네이티브 도구를 만들고 있는 경우입니다. 주력 장비가 넉넉한 RAM을 갖춘 Apple silicon Mac이라면, MLX는 그것을 제대로 된 ML 워크스테이션으로 바꿔 놓습니다.

Core AI: 새로운 바닥

iOS 27은 애플에 빠져 있던 계층을 더했습니다. 바로 Core AI 입니다. NDArray 텐서, 에셋과 모델의 분리, 명시적인 연산 유닛 지정, 호출 가능한 추론 함수를 갖춘 저수준 모델 실행 프레임워크입니다⁷. Core ML의 “컴파일된 모델을 건네면 예측을 받는다”는 계약이 지나치게 경직됐을 때 꺼내 드는 도구입니다. 텐서 연산과 모델 호출을 번갈아 엮는 파이프라인, ANE에서 돌아야 마땅한 커스텀 전처리·후처리, 버퍼를 공유하는 다중 모델 그래프 같은 경우입니다.

두 가지만 짚어 두면 많은 독자가 잘못된 길로 새는 것을 막을 수 있습니다. Core AI는 Foundation Models의 대안이 아닙니다(이 계층에는 여전히 내장 LLM이 없으며, 컴파일된 에셋은 직접 가져와야 합니다). 그리고 iOS판 MLX도 아닙니다. 학습도, 자동 미분도, 즉시 실행 기반의 연구 루프도 없습니다. Core ML의 기관실 해치를 열어 둔 것이라고 보면 됩니다. Core ML의 추상화와 싸워 본 적이 없다면 Core AI는 필요 없습니다. MLMultiArray 곡예를 배포해 봤거나 불필요한 변환을 거쳐 모델을 줄줄이 엮어 봤다면, 이미 필요한 상태입니다. 텐서 모델과 지정 API는 Core AI 기둥 글에서 다룹니다.

실제로 논쟁이 되는 사례들

“LLM이 필요한데, 우리 것이거나 더 큰 모델이어야 합니다.” Foundation Models는 외부 가중치를 불러올 수 없습니다. 예외는 없습니다. 증류한 소형 LLM을 Core ML로 돌리면 동작하고 ANE도 얻습니다. 양자화한 오픈 모델을 MLX로 돌리면 Mac에서 동작합니다. 온디바이스 진영의 누구도 입 밖에 내고 싶어 하지 않는 대안도 솔직하게 인정합시다. 작업에 프런티어급 품질이 필요하다면 답은 서버 호출이며, 온디바이스 계층은 폴백과 프라이버시에 민감한 부분집합을 맡습니다.

“iPhone과 Mac에 하나의 스택을 쓰고 싶습니다.” Foundation Models와 Core ML은 둘 다 애플 생태계 안에서 크로스 플랫폼이지만, MLX는 사실상 Mac 전용입니다. Mac용 프로 앱과 iOS 동반 앱을 함께 내는 팀은 흔히 Mac에는 MLX(큰 모델, 사용자가 제공한 가중치), iOS에는 Core ML이나 Foundation Models라는 결론에 도달합니다. 같은 기능, 두 개의 엔진, 그리고 기기가 서로 다르다는 하나의 솔직한 인정입니다.

“이미 Core ML 파이프라인이 있습니다. Core AI가 마이그레이션 대상인가요?” 파이프라인이 아픈 부분에 한해서만 그렇습니다. Core AI가 흡수하는 것은 텐서 형태의 가장자리이고, 오늘도 잘 돌아가는 컴파일된 모델의 핵심은 계속 그대로 돌아갑니다. 건강한 Core ML 배포를 통째로 옮기는 데서 얻을 것은 없습니다.

“SwiftData나 App Intents가 이 판단을 바꾸나요?” 인접하되 겹치지는 않습니다. 모델 계층은 App Intents가 시스템에 노출하는 기능에 재료를 공급하고, 저장하는 데이터는 SwiftData의 스키마 규율을 따릅니다. 여기서 다룬 프레임워크가 결정하는 것은 추론이 어떻게 실행되는가 이지, 그 주위의 앱을 어떻게 만드는가가 아닙니다.

의사결정 트리

Is the task language-shaped and within a ~3B generalist's reach?
├── YES → Foundation Models. Ship zero weights. Done.
└── NO → Whose weights?
    ├── Apple's, but specialized → Foundation Models + trained adapter
    │     (accept: retrain per base-model rev)
    └── Yours →  Where does it run?
        ├── iOS/iPadOS app → Core ML
        │     └── unless you need tensor-level control → Core AI (iOS 27+)
        ├── Mac, models-as-product / training / open weights → MLX
        └── Frontier-quality required → server, with on-device fallback

핵심 정리

기능을 배포하는 앱 팀에게: - 먼저 Foundation Models로 프로토타입을 만드십시오. Swift 여섯 줄은 가능한 가장 값싼 실험이며, “내장 모델로 충분했다”는 것이 가장 흔한 놀라움입니다. - Core ML 변환 시간은 추론 시간과 분리해 예산을 잡으십시오. 몇 주가 통째로 사라지는 곳은 연산자 커버리지와 양자화입니다.

ML 엔지니어에게: - 64GB 이상을 갖춘 Apple silicon Mac은 MLX 아래에서 진짜 파인튜닝 장비가 됩니다. 클라우드 GPU를 빌리기 전에 먼저 측정하십시오. 위의 11.2 TFLOPS / 351 GB/s 수치는 두 세대 전 노트북용 칩에서 나온 것입니다.¹ - ANE는 여전히 Core ML의(그리고 이제는 Core AI의) 해자입니다. 추론당 배터리 소모가 중요하다면 어떤 GPU 경로도 상대가 되지 않습니다.

아키텍트에게: - 네 프레임워크를 경쟁자가 아니라 계층으로 다루십시오. 언어 기능에는 Foundation Models, 배포하는 커스텀 모델에는 Core ML, 텐서 형태의 가장자리에는 Core AI, Mac과 연구실에는 MLX입니다. 진지한 앱에서 혼합 구성은 냄새가 아니라 표준입니다. - 장기적인 비용 센터는 모델의 소유권 입니다. Foundation Models의 가중치는 애플이 관리하고, 나머지 전부는 여러분이 관리합니다. 이 점을 선택의 가격에 포함시키십시오.

자주 묻는 질문

온디바이스로 모델을 실행하려면 어떤 애플 프레임워크를 써야 합니까

판단은 대개 질문 하나면 끝납니다. 내장 모델이면 Foundation Models, 자신의 모델을 iOS에서 돌린다면 Core ML, 자신의 모델을 자신의 Mac에서 돌린다면 MLX, iOS에서 텐서 수준의 제어가 필요하면 Core AI를 쓰십시오. 기능을 두 개의 축, 즉 누구의 가중치를 돌리는가와 실행을 누가 소유하는가에 찍어 보면 프레임워크는 저절로 정해집니다. 네 가지를 경쟁자가 아니라 계층으로 다루십시오. 진지한 앱에서 혼합 구성은 표준입니다.

Foundation Models로 제 모델 가중치를 돌릴 수 있습니까

아니요. Foundation Models가 실행하는 것은 언제나 애플의 내장 온디바이스 모델, 즉 대략 3B 파라미터의 제너럴리스트와 직접 만든 LoRA 방식 어댑터뿐입니다. 외부 가중치는 불러올 수 없으며 예외는 없습니다. 자신만의 LLM이 필요하다면 증류한 소형 모델을 Core ML로 돌리는 방법이 동작하고 Neural Engine도 얻을 수 있으며, 양자화한 오픈 모델을 MLX로 돌리면 Mac에서 동작합니다. 작업에 프런티어급 품질이 필요하다면 답은 서버 호출입니다.⁵

MLX를 iOS 앱에 넣어 배포할 수 있습니까

현실적으로는 불가능합니다. MLX는 OS 프레임워크가 아니라 애플 ML 연구 그룹이 만든 오픈소스 배열 프레임워크이고, GPU와 CPU만 프로그래밍하며 Neural Engine 접근이 없습니다. 게다가 가중치 배포와 발열, 심사 지침을 생각하면 iOS 번들에는 잘못된 도구입니다. MLX는 자신의 Mac, 사용자의 Mac, 그리고 자신의 연구 루프를 위한 것입니다.⁴

Core ML과 Core AI의 차이는 무엇입니까

Core ML은 사전 컴파일 방식의 추론입니다. 컴파일된 .mlmodelc 를 건네고 연산 유닛을 힌트로 알려주면 디스패치는 프레임워크가 결정합니다. iOS 27에 추가된 Core AI는 바로 그 기관실의 해치를 열어 둔 것으로, NDArray 텐서와 에셋·모델 분리, 명시적인 연산 유닛 지정을 제공합니다. 그래도 학습은 하지 않고 내장 LLM도 함께 배포되지 않습니다. Core ML의 추상화와 싸워 본 적이 없다면 필요하지 않습니다.⁷

로컬 머신러닝에서 M2 Max는 얼마나 빠릅니까

이 글을 쓰고 있는 M2 Max에서 MLX는 아무런 튜닝 없이 4096×4096 fp16 행렬 곱 11.2 TFLOPS와 실측 스트리밍 대역폭 351 GB/s를 지속합니다. 양자화된 30B 파라미터 오픈 웨이트 모델을 대화형으로 돌리고 7B 모델을 LoRA로 하룻밤에 파인튜닝하기에 충분한 수준입니다. 클라우드 GPU를 빌리기 전에 먼저 측정하십시오. 이 수치는 두 세대 전 노트북용 칩에서 나온 것입니다.¹

참고 자료