Core ML 온디바이스 추론: 실제로 출시되는 패턴들

Core ML은 모든 최신 Apple 디바이스에 함께 제공되는 온디바이스 추론 엔진입니다. 이 프레임워크는 모델과 하드웨어를 기반으로 가장 빠른 경로를 자동으로 선택하여, 사용 가능할 때는 Neural Engine으로, 그렇지 않을 때는 GPU로, 마지막 수단으로는 CPU로 디스패치합니다¹. 그 결과 최신 iPhone에서는 대부분의 프로덕션 모델 크기에서 1밀리초 미만에서 수십 밀리초 수준의 추론 지연 시간을 보이며, 호출당 비용이 들지 않고, 네트워크 왕복도 없으며, 서드파티 데이터 노출도 없습니다.

이 프레임워크가 “모호한 배관”이라는 평판은 이미 낡은 이야기입니다. Core ML은 이제 Apple Intelligence의 온디바이스 LLM, 사진 앱의 시맨틱 검색, 카메라 앱의 장면 인식, 그리고 로컬 ML을 탑재한 대부분의 서드파티 앱을 구동합니다. Core ML 배포가 “내 Mac에서는 됩니다” 수준이 아니라 실제로 출시되도록 만드는 패턴은 작은 집합으로 정리됩니다. 모델 변환, 디스패치 힌팅, 지연 시간 예산 책정, 그리고 양자화입니다. 이 글에서는 각각을 Apple 공식 문서에 비추어 살펴봅니다.

TL;DR

• Core ML은 .mlpackage와 .mlmodel 파일을 Apple Silicon의 Neural Engine, GPU, CPU에서 실행합니다. 디스패치는 자동이지만 MLModelConfiguration.computeUnits를 통해 힌트를 줄 수 있습니다².
• 모델 변환은 coremltools(PyTorch, TensorFlow, ONNX → Core ML)를 통해 이루어집니다. 변환은 런타임 작업이 아니라 툴링 작업입니다. 한 번 변환되어 번들에 포함되면 앱이 모델을 로드하고 실행합니다.
• Apple Silicon의 통합 메모리 아키텍처는 모델 가중치가 CPU, GPU, NE 사이에서 복사되지 않음을 의미합니다. 동일한 메모리가 세 가지 모두를 뒷받침합니다³. 이 아키텍처적 세부 사항이 1밀리초 미만의 추론을 가능하게 만드는 핵심입니다.
• 양자화(최근 Core ML 버전에서는 INT8, INT4)는 모델 크기를 줄이고 Neural Engine에서의 추론 속도를 높여주지만, 모델에 따라 측정 가능한 정확도 비용이 따릅니다.
• 에이전트 워크플로우와의 연결점: Foundation Models(Apple Intelligence의 온디바이스 LLM)는 고수준 Swift API 뒤에서 Core ML 모델로 제공되며, 동일한 디스패치 및 양자화 패턴이 적용됩니다.

멘탈 모델: 세 가지 컴퓨트 경로, 하나의 메모리

Apple Silicon(M 시리즈 Mac과 A12 Bionic 이후의 A 시리즈 iPhone)은 세 가지 추론 타깃을 제공합니다.

Neural Engine. 저정밀도 행렬 곱셈을 위해 특화된 가속기입니다. 최신 ML 모델이 의존하는 연산(컨볼루션, 어텐션, 임베딩)에서 가장 빠릅니다. 전력 소비가 가장 낮습니다. 특정 연산 유형과 텐서 형태에만 제한되어 있으며, 지원되지 않는 연산은 레이어 단위로 GPU나 CPU로 폴백됩니다.

GPU. Metal을 통한 범용 병렬 컴퓨트입니다. ML 형태의 작업에서 Neural Engine보다는 느리지만 CPU보다는 빠릅니다. Neural Engine이 지원하지 않는 연산을 처리합니다.

CPU. 폴백입니다. ML 추론에는 느리지만 항상 사용 가능하며, 모든 연산을 항상 지원하고, 예측 가능합니다.

통합 메모리 아키텍처는 동일한 물리 RAM이 세 가지 모두를 뒷받침함을 의미합니다³. 한 번 로드된 모델 가중치는 디스패치가 타깃 사이를 옮겨갈 때 복사되지 않습니다. 이 아키텍처적 사실이 멀티 타깃 디스패치를 레이어당 복사 비용에서 레이어당 스케줄링 결정으로 전환시킵니다.

MLModelConfiguration.computeUnits가 디스패치를 제어합니다.

let config = MLModelConfiguration()
config.computeUnits = .all          // default: NE, GPU, CPU
// Other options:
// .cpuAndGPU
// .cpuAndNeuralEngine
// .cpuOnly
let model = try MyModel(configuration: config)

.all이 기본값이며 거의 모든 앱에 올바른 선택입니다. 프레임워크는 연산별로 가장 빠른 경로를 선택하고, 이 연산별 결정은 개발자가 작성할 수 있는 어떤 휴리스틱보다도 빠릅니다. 이를 재정의하는 드문 이유는 테스트 동등성을 위해 .cpuOnly를 강제하거나(모델이 경로별로 다르게 동작할 때 결정론적인 경로를 원하는 테스트에서), 다른 동시 작업을 위해 Neural Engine을 해제하려고 .cpuAndGPU를 강제하는 경우입니다.

모델 변환: 툴링 작업

대부분의 ML 모델은 PyTorch, TensorFlow, 또는 직접 Apple의 Create ML로 학습됩니다. Core ML은 Xcode 13에서 도입된 최신 형식인 .mlpackage 파일을 받아들이며, 이 형식이 기존의 .mlmodel을 대체합니다⁴. 변환은 Apple의 오픈소스 Python 패키지인 coremltools를 통해 이루어집니다⁵.

일반적인 PyTorch에서 Core ML로의 변환은 세 단계를 거칩니다.

1. 학습된 PyTorch 모델을 로드하고 추론 모드로 전환합니다.
2. 프로덕션 입력 형태와 일치하는 예제 입력 텐서로 모델을 트레이싱합니다.
3. 트레이싱된 모델을 타깃 배포 iOS 버전에 맞춰 coremltools로 변환합니다.

import torch
import coremltools as ct

model = MyTrainedModel()
model.load_state_dict(torch.load("weights.pth"))

example_input = torch.rand(1, 3, 224, 224)
traced_model = torch.jit.trace(model, example_input)

mlmodel = ct.convert(
    traced_model,
    inputs=[ct.ImageType(name="image", shape=example_input.shape)],
    minimum_deployment_target=ct.target.iOS18,
    compute_units=ct.ComputeUnit.ALL,
)
mlmodel.save("MyModel.mlpackage")

변환은 개발 환경에서, 타깃 배포 iOS 버전(minimum_deployment_target)에 대해 한 번만 수행됩니다. 출력된 .mlpackage가 Xcode 프로젝트에 들어가는 결과물입니다. 런타임 앱은 coremltools를 실행하지 않습니다.

변환에서 실무적으로 빠지기 쉬운 함정이 두 가지 있습니다. 첫째, 동적 형태 입력은 ct.RangeDim을 통해 명시적으로 처리해야 합니다. Core ML의 정적 형태 기본값이 프로덕션 앱에서 다양한 입력 크기를 공급할 때 도움이 되지 않는 오류를 발생시키기 때문입니다. 둘째, Core ML에 대응이 없는 PyTorch 커스텀 연산은 Core ML 커스텀 레이어(누락된 연산을 실행하는 Swift 코드)나 변환 전에 해당 연산을 제거하기 위한 모델 아키텍처 변경 중 하나가 필요합니다. 둘 다 잘 문서화되어 있습니다⁵.

실제로 적용되는 지연 시간 예산

출시 가능한 앱에 중요한 지연 시간 예산은 세 가지입니다.

16ms (60fps 라이브 UI). 실시간 카메라 필터, 프레임마다 업데이트되는 AR 장면, 라이브 오디오 분석기 등이 해당됩니다. 이 예산에는 모든 것이 포함됩니다. 이미지 전처리, 모델 추론, 후처리, UI 업데이트입니다. 이에 맞는 모델은 일반적으로 작으며(MobileNetV3급, 1억 파라미터 미만) Neural Engine에서 실행됩니다.

100ms (인터랙티브 UI). 사용자가 액션을 취하고 결과를 기다리는 경우입니다. 탭으로 식별, 그려서 인식, 받아쓰기로 전사하는 등이 해당됩니다. 이 예산은 더 너그러우며 더 큰 모델을 지원합니다. 10억 파라미터 미만의 언어 모델, 작은 비전 트랜스포머, 그리고 대부분의 프로덕션 등급 분류기가 무리 없이 들어맞습니다.

1초 이상 (백그라운드 또는 배치). 사진 라이브러리 인덱싱, 문서 분석, 앱 실행 시 모델 워밍업 등이 있습니다. 더 큰 모델도 동작하지만, 진행 상태 표시기로 사용자 기대치를 설정해야 합니다. Foundation Models 온디바이스 LLM는 더 큰 컨텍스트 윈도우 작업에서 이 영역에 위치합니다.

이 예산들은 가이드라인이며 절대적인 한계가 아닙니다. 올바른 접근은 다른 머신에서의 이론적 수치를 신뢰하기보다는, 타깃 디바이스에서 os_signpost나 Instruments의 Core ML 템플릿⁶을 사용해 측정하는 것입니다.

양자화: 더 작을수록 더 빠를 때

Core ML은 여러 양자화 수준을 지원합니다⁷.

• Float32 (전정밀도). 학습의 기본값입니다. 가장 크고, 가장 정확하며, 가장 느립니다.
• Float16. 반정밀도입니다. GPU와 NE에서 더 작고 더 빠릅니다. 잘 조정된 모델에서는 정확도 손실이 보통 무시할 만한 수준입니다.
• INT8. 캘리브레이션을 동반한 8비트 정수 양자화입니다. Float32보다 약 4배 작고, NE에서 종종 2~4배 빠릅니다. 정확도 손실은 다양합니다. 비전 모델의 경우 양자화 인식 학습으로 1% 미만의 top-1 정확도 손실을 달성할 수 있습니다.
• INT4 이하. 최근 Core ML 버전이 특정 모델 아키텍처(LLM, 대형 비전 모델)에 대해 지원하는 공격적인 양자화입니다. 상당한 정확도 손실이 트레이드오프이며, 모델 인식 양자화 인식 학습과 짝을 이룰 때 가장 잘 동작합니다.

coremltools.optimize.coreml.linear_quantize_weights를 통한 선형 양자화 구성은 양자화 모드(linear_symmetric 또는 linear)를 선택하는 전역 op 구성과, 그 미만에서는 가중치를 전정밀도로 유지하는 가중치 크기 임계값을 받아들입니다. 변환은 기존 .mlpackage에 대해 실행되어 새로운 양자화된 패키지를 생성합니다. 두 패키지는 번들 안에 나란히 포함될 수 있으며, 앱은 디바이스 클래스에 따라 어느 쪽을 로드할지 선택합니다.

양자화 결정은 모델별로 다릅니다. 작은 분류기는 컴퓨트가 이미 저렴하기 때문에 이득을 보지 못할 수 있고, 큰 언어 모델은 컴퓨트가 양자화된 가중치에 대한 행렬 곱셈에 의해 좌우되기 때문에 막대한 이득을 봅니다. 올바른 접근은 양자화하고, 보류된 테스트 세트에서 정확도를 측정하고, 정확도 손실이 사용 사례에 허용 가능하면 출시하는 것입니다.

그대로 가져다 쓸 수 있는 Apple의 내장 모델

Apple은 Core ML Models 페이지를 통해 사전 학습된 여러 Core ML 모델을 제공합니다⁸. 알아둘 만한 카테고리는 다음과 같습니다.

• 이미지 분류: MobileNetV2, ResNet50, SqueezeNet 변형들로, 모두 번들로 제공되어 Vision 프레임워크의 VNCoreMLRequest에 바로 투입할 수 있도록 준비되어 있습니다.
• 객체 감지: YOLOv3, MNIST, CenterNet 변형.
• 포즈 추정: 신체 포즈를 위한 PoseNet (Vision의 VNDetectHumanBodyPoseRequest에 대한 베이스라인 대안).
• 시맨틱 세그멘테이션: 이미지 세그멘테이션을 위한 DeepLabV3.
• 텍스트 인식: Vision의 내장 OCR에 대한 ML 기반 대안.

대부분의 앱에서 Apple의 사전 학습 모델은 커스텀 학습 없이도 인식 프리미티브(분류, 감지, 세그멘트)를 충분히 커버합니다. Foundation Models 온디바이스 LLM(Foundation Models on-device LLM에서 다룸)는 가장 큰 예입니다. 고수준 Swift API 뒤에서 Core ML 모델로 제공되고, Neural Engine에서 디스패치되며, 오프라인에서 사용 가능한 수십억 파라미터 LLM입니다.

모델 암호화 및 App Store 고려 사항

앱 번들에 포함된 .mlpackage는 IPA를 압축 해제하는 누구나 읽을 수 있습니다. 의미 있는 지적 재산을 표상하는 모델이라면, Apple은 Encrypt your Core ML model 워크플로우를 통해 모델 암호화를 지원합니다⁹. Xcode를 통해 암호화 키가 생성되고 CloudKit을 통해 관리되며, 번들의 모델은 암호화되어 있고 Core ML이 로드 시점에 복호화합니다.

대부분의 앱에서 암호화는 과합니다. 일반적인 ImageNet 데이터로 학습된 모델은 경쟁 차별화 요소가 아닙니다. 이를 암호화하면 가치 있는 무언가를 보호하지 못한 채 운영상의 복잡성만 더해집니다. 암호화는 진짜 학습 데이터 투자나 경쟁 우위를 표상하는 모델에만 사용하세요.

온디바이스 프라이버시: 아키텍처적 승리

프라이버시 이야기는 직접적입니다. Core ML 추론은 전적으로 디바이스에서 일어납니다. 입력 데이터(이미지, 오디오, 텍스트)는 디바이스를 떠나지 않습니다. 모델 파일은 로컬이고, 추론도 로컬이며, 결과도 로컬입니다.

규제 산업(헬스케어, 금융, 교육)의 앱에서 이러한 아키텍처적 사실은 컴플라이언스 작업의 한 부류를 통째로 제거합니다. 프라이버시 정책에 추가해야 할 서드파티 데이터 처리자가 없습니다. 보안을 검증해야 할 모델 API 엔드포인트가 없습니다. 데이터가 이동하지 않으므로 데이터 거주지 문제도 없습니다.

Privacy Manifest 형식¹⁰은 App Store 제출용 프라이버시 이야기를 코드화합니다. 추론 외에는 다른 어떤 것도 사용하지 않고 온디바이스 추론에 Core ML을 사용하는 앱은 추론 경로에 대해 서드파티 데이터 공유가 전혀 없다고 선언할 수 있습니다. 제출 절차가 더 빠르고, 프라이버시 검토가 더 짧으며, 사용자에게 보이는 프라이버시 영양 정보 라벨이 더 깔끔해집니다.

에이전트 워크플로우와의 연결

Core ML은 클러스터에서 이미 다룬 세 가지 패턴과 짝을 이룹니다.

Vision Framework의 VNCoreMLRequest. 커스텀 Core ML 모델은 자동 전처리와 함께 Vision 파이프라인을 통해 실행됩니다. 이 패턴(Vision Framework에서 다룸)은 iOS 앱 안에서 커스텀 이미지 분류기나 감지기를 출시하는 올바른 방식입니다.

Foundation Models 온디바이스 LLM. Apple Intelligence의 LLM은 고수준 Swift API 뒤에서 동작하는 Core ML 모델입니다. 동일한 디스패치(Neural Engine 우선), 양자화(LLM 가중치에 대한 INT4), 그리고 지연 시간 예산(짧은 생성에서 1초 미만) 패턴이 적용됩니다. Foundation Models 글이 API를 다루며, 이 글은 그 아래에 있는 엔진을 다룹니다.

로컬 ML을 사용하는 App Intents 도구. 로컬 이미지 분류기나 텍스트 분류기를 실행하는 AppIntent는 네트워크 왕복 없이 Apple Intelligence에 구조화된 결과를 반환합니다. 이 조합이 “에이전트형 Apple”을 실제로 프라이빗하게 만드는 요소입니다. 프레임워크가 이를 지원하기 때문에 에이전트의 도구가 로컬에서 실행됩니다.

클라우드 추론이 올바른 선택일 때

Core ML의 한계는 디바이스의 컴퓨트입니다. 클라우드가 옳은 세 가지 경우가 있습니다.

번들로 출시하기에는 너무 큰 모델. 700억 파라미터 LLM은 앱 번들에 들어가지 않습니다. 그 규모의 워크로드에는 클라우드 추론(또는 다른 패턴인 가중치 스트리밍 방식의 온디바이스)이 올바른 도구입니다.

추론 중 디바이스 간 공유 상태가 필요한 경우. 추론 중에 공유 데이터베이스를 읽거나 써야 하는 모델(수십억 레코드에 대한 협업 필터링 기반의 추천 시스템)입니다. Core ML의 순수 로컬 모델은 이에 맞지 않습니다.

빠른 모델 반복. 매일 모델 업데이트를 출시하는 팀은 롤아웃에 App Store 검토 사이클이 필요하지 않으므로 서버 측 추론에서 이득을 봅니다. Core ML의 모델을 앱에 번들링하는 패턴은 모델 개정 주기에 마찰을 더합니다. 이 트레이드오프는 실재합니다.

패턴: 클라우드는 규모와 반복 속도에서 이기고, Core ML은 지연 시간, 비용, 프라이버시에서 이깁니다.

이 패턴이 iOS 26+ 앱에 의미하는 바

세 가지 핵심을 정리합니다.

1. 번들에 들어가고 사용자가 행동에 옮길 수 있는 호출별 결과를 내는 모든 모델에 대해 Core ML을 기본으로 하세요. 이미지 분류, 객체 감지, 오디오 분류, 제스처 인식, 임베딩 생성, 그리고 작거나 중간 크기의 언어 작업이 해당됩니다. 프레임워크의 자동 디스패치와 Apple Silicon NPU는 1밀리초 미만에서 수십 밀리초 수준의 추론을 무료로 제공합니다.

2. 정확도 손실이 허용 가능할 때는 공격적으로 양자화하세요. INT8은 보통 안전합니다. INT4는 크기 절감이 중요한 큰 모델에 적합합니다. 양자화가 보편적으로 안전하다고 신뢰하기보다는, 보류된 세트에서 정확도를 측정하세요.

3. 완전한 로컬 파이프라인을 위해 Vision 및 Foundation Models와 짝을 지으세요. Core ML은 엔진이고, Vision은 그 위의 인식 API이며, Foundation Models는 그 위의 LLM입니다. 클러스터의 Vision 글과 Foundation Models 글이 더 상위의 표면을 다룹니다.

전체 Apple 생태계 클러스터: 타입 기반 App Intents; MCP 서버; 라우팅 질문; Foundation Models; 런타임 vs 툴링 LLM 구분; 세 가지 표면; 단일 진실 공급원 패턴; 두 개의 MCP 서버; Apple 개발용 훅; Live Activities; watchOS 런타임; SwiftUI 내부 구조; RealityKit의 공간 멘탈 모델; SwiftData 스키마 규율; Liquid Glass 패턴; 멀티 플랫폼 출시; 플랫폼 매트릭스; Vision 프레임워크; Symbol Effects; 내가 쓰지 않기로 한 것들. 허브는 Apple Ecosystem Series에 있습니다. AI 에이전트가 결합된 더 폭넓은 iOS 컨텍스트는 iOS Agent Development guide를 참고하세요.

FAQ

Core ML은 Neural Engine, GPU, CPU 사이에서 어떻게 결정하나요?

Core ML은 모델 그래프의 각 연산을 검사하여 해당 연산을 지원하는 가장 빠른 타깃으로 디스패치합니다. Neural Engine은 지원되는 연산(대부분의 행렬 곱셈, 컨볼루션, 어텐션)을 가장 낮은 지연 시간과 전력으로 처리합니다. GPU는 NE가 지원하지 않는 연산을 처리합니다. CPU가 나머지를 처리합니다. 결정은 연산별이고, 자동이며, 손으로 작성한 휴리스틱보다 빠릅니다.

항상 .computeUnits = .all을 사용해야 하나요?

거의 항상 그렇습니다. 프레임워크의 자동 디스패치는 잘 튜닝되어 있습니다. 출력 동등성을 테스트할 때(부동소수점 반올림으로 인해 NE와 CPU에서 동일한 모델이 약간 다른 결과를 반환할 수 있음) .cpuOnly로 재정의하거나, 동시 작업을 위해 Neural Engine을 비우려고 .cpuAndGPU로 재정의하세요.

.mlpackage와 .mlmodel의 실용적인 차이는 무엇인가요?

.mlpackage는 Xcode 13에서 도입된 최신 형식입니다. 저장된 메타데이터, ML Program(mlprogram) 컴파일을 위한 다중 모델 변형, iOS 13 이후의 툴체인을 지원합니다. .mlmodel은 레거시 형식입니다. 둘 다 여전히 MLModel을 통해 로드되며, 새 개발에는 .mlpackage를 사용해야 합니다.

앱 번들에 포함되는 Core ML 모델은 얼마나 커질 수 있나요?

고정된 한도는 없지만 App Store 번들 크기는 다운로드 기준 4GB로 제한되며 OTA 설치에 실용적인 한계가 있습니다. Foundation Models의 온디바이스 LLM는 약 3GB이며 앱 번들이 아니라 OS에 의해 배포됩니다. 앱 번들에 포함되는 모델의 경우 100MB 미만이 편안하고, 100~500MB는 실행 시 로딩 전략으로 가능하며, 500MB 이상은 BGProcessingTask 백그라운드 다운로드나 온디맨드 리소스를 통해 처리하는 것이 가장 좋습니다.

양자화가 모델 정확도를 해쳤는지 어떻게 알 수 있나요?

테스트 세트를 보류해 두고, 원래 Float32 모델과 양자화된 모델에서 추론을 실행한 다음, 메트릭(분류기에는 top-1 정확도, 감지기에는 F1, 언어 모델에는 perplexity, 번역에는 BLEU 등)을 비교하고, 애플리케이션의 정확도 요구 사항에 따라 결정합니다. 양자화 인식 학습(손실에 양자화를 시뮬레이션하면서 모델을 학습)은 보통 정확도 손실의 대부분을 회복시킵니다.

참고 자료