“사용자 데이터가 기기를 떠나지 않는다. 관리할 서버도, 토큰당 비용도, 클라우드 지연도 없다.”
WWDC26에서 Apple이 발표한 Core AI는 단순한 프레임워크가 아니다. 오픈소스 모델을 가져와서 Apple 기기에서 돌리는 전체 파이프라인 — 모델 발견, 변환, 최적화, 배포, 런타임 — 을 하나로 묶는 시도다. 그리고 놀랍게도, 실제로 작동한다.
이 세션에서 Apple 엔지니어 Karina가 언어 학습 앱을 직접 만들어 보여줬다. 카메라로 사물을 찍으면 단어장 카드가 자동으로 생성되는 앱. Vision Transformer와 대형 언어 모델이 iPhone 위에서 함께 돈다. 처음부터 끝까지.
카메라 한 번에 단어장이 만들어진다고?
Karina는 이 시나리오를 발표하면서 거의 흥분한 듯했다. 학생이 카메라로 정원의 꽃을 찍으면, 앱이 꽃을 이미지에서 분리해내고 영어 이름(label)을 뽑는다. 그 label을 언어모델에 넣으면 번역, 예문, 발음 정보가 담긴 어휘 카드가 나온다. “학습자의 일상이 곧 교과서가 된다”는 말에 그녀가 덧붙인 뉘앙스는 명확했다 — 이건 데모가 아니라 자기가 직접 쓰고 싶은 앱이라는 것.
직접 큐레이션한 단어장은 확장성이 떨어진다. 모든 단어를 정적으로 앱에 넣을 수도 없다. 하지만 카메라와 온디바이스 모델이 있으면 호기심 많은 학생을 따라잡을 수 있다.
“No curated deck can keep up with a curious student, but a camera and an on-device model can.”
이 한 문장이 이 세션 전체를 관통한다. 모델이 사용자의 삶 속으로 들어가는 방식을 보여주는 선언이다.
왜 두 개의 작은 모델인가
이 앱을 구현하려면 두 가지 AI 기능이 필요하다. 이미지에서 객체를 분리하는 것, 그리고 텍스트를 이해하고 구조화된 출력을 내는 것.
여기서 Karina는 중요한 설계 결정을 내린다. 하나의 대형 모델로 모든 걸 하지 않고, 두 개의 작은 모델로 문제를 분해한다.
SAM 3 (Segment Anything Model 3) — Meta가 만든 비전 트랜스포머 모델. 사용자가 프롬프트를 주면 이미지에서 해당 객체를 정밀하게 분리해낸다. 카드 그래픽으로 쓸 깔끔한 컷아웃을 만든다.
Qwen (6B 파라미터) — 알리바바의 다국어 언어 모델. 119개 언어와 방언을 지원하고, reasoning 모델이라 문맥이 있는 예문까지 생성한다. 영어 label을 넣으면 번역과 예문이 구조화된 형태로 나온다.
왜 굳이 분리했을까? Karina가 정리한 이유가 명확하다:
- 품질: 각 작업에 특화된 모델이 범용 모델보다 낫다
- 크기: 개별 모델 크기가 작아진다
- 독립 업그레이드: 하나만 교체할 수 있다
각 모델을 10억 파라미터 이하로 타겟팅해서 온디바이스 총 메모리를 관리 가능한 수준으로 유지한다.
모델을 앱에 어떻게 넣나 — Core ML이 아닌 Core AI
Core AI의 모델 파이프라인은 세 가지 경로를 제공한다.
- PyTorch 확장 패키지로 직접 변환
- 최적화 패키지로 압축 포함
- Core AI Models 리포지토리에서 미리 변환된 모델 사용
Karina는 세 번째 길을 택했다. Apple이 GitHub에 공개한 Core AI Models 리포지토리에서 SAM 3와 Qwen 패밀리의 변환 스크립트를 찾아 실행했다. 모델별 전처리·후처리 라이브러리도 Swift 패키지로 제공된다.
코드는 놀라울 정도로 간결하다. SAM 3 모델을 로딩하고 텍스트 프롬프트로 세그멘테이션을 수행하는 게 전부. 언어 모델은 단 한 줄로 로딩된다.
let lm = CoreLanguageModel(modelAt: modelBundleURL)여기서 핵심은 Foundation Models 프레임워크와의 통합이다. Apple 자체 온디바이스 LLM에 접근하던 LanguageModelSession API를 그대로 사용하되, 그 아래 도는 모델만 내가 가져온 걸로 바꾼다. 스트리밍, 구조화된 출력(structured output), guided generation — 모두 동일한 API로 사용 가능하다.
let session = LanguageModelSession(model: lm)이게 의미하는 바가 크다. Foundation Models API의 인체공학적 설계를 그대로 누리면서, 모델 선택의 자유를 갖는다.
첫 실행이 느리다 — Specialization의 함정
데모를 돌려보니 문제가 나타났다. SAM 3 모델을 처음 로딩할 때 스피너가 오래 돈다.
Core AI Instruments로 트레이스를 잡아보니 원인이 명확했다. Specialization — 모델을 특정 기기에서 실행 가능하게 준비하는 과정 — 이 첫 로딩을 지연시키고 있었다. 모델이 로딩될 때 이미 specialization이 완료되어 캐시되었는지 확인하고, 아니면 그 자리에서 수행한다. 대형 모델에서는 상당한 시간이 걸린다.
두 번째 실행부터는 캐시에서 읽어 빠르지만, 첫 경험은 사용자에게 안 좋다.
Karina의 해결책은 단계적이다:
1. 첫 실행 경험(First-run experience) 분리 모델 로딩을 인터랙티브 흐름에서 빼내, 사용자가 기능을 처음 알아보는 화면에서 백그라운드로 처리한다.
2. Background Assets로 모델 다운로드 지연 모델 두 개가 1GB 이상이다. 앱 번들에 넣으면 업데이트하는 모든 사용자가 다운로드해야 한다. 대신 Background Assets를 써서 기능을 실제로 사용하려는 사용자만 모델을 받도록 했다.
3. Ahead-of-Time(AOT) 컴파일
여기가 핵심이다. Specialization은 두 단계로 나뉜다: (a) 컴파일, (b) 실행 아티팩트 생성. 컴파일이 가장 비싸다. Core AI 툴체인의 coreai build 명령으로 개발 머신에서 미리 컴파일해두면, 사용자 기기에서는 나머지 작업만 하면 된다. 특화 작업이 훨씬 빨리 끝난다.
coreai build --input model.mlmodel --target-arch arm64e이 세 가지를 조합하면, 사용자는 기다림 없이 첫 추론을 시작할 수 있다.
iPhone 코드 그대로 Mac에서 — 더 큰 모델로
여기서 이야기가 끝나지 않는다.
Karina는 데모 라이브 코딩에서 자기 책상 위의 돌멩이를 카메라에 비췄다. 여행에서 주워온 돌, 룸메이트에게 받은 나무 조각, 여동생이 준 해바라기. 개인적인 물건들이었다. 그녀가 만들고 싶었던 건 기술 시연이 아니라, 자기 삶의 조각들을 새 언어로 번역하는 도구였다.
그리고 그녀는 같은 코드를 그대로 macOS로 가져간다. Core AI는 멀티플랫폼이다.
Mac에서는 한 단계씩이 아니라 배치 처리가 가능하다. 여행 사진 폴더를 통째로 넣으면 SAM 3가 모든 사진에서 객체를 병렬로 분리하고, Qwen이 카드를 한꺼번에 만든다.
더 흥미로운 건 모델 업그레이드다. Mac은 메모리와 연산 자원이 넉넉하다. Qwen 6B 대신 Qwen 38B를 돌린다. 같은 코드, 같은 API, 더 강력한 모델. 38B reasoning 모델은 각 단어의 병음(pinyin)이 정확한지 스스로 검증까지 한다.
그리고 단어 카드를 넘어 커리큘럼 설계까지 나아간다. 긴 컨텍스트 윈도우를 활용해 전체 단어 목록을 주면, 단순한 것부터 복잡한 것까지 순서를 정하고, 레슨별로 그룹화하고, 앞서 배운 어휘를 재사용하는 예문까지 작성한다. 하나의 프롬프트로 구조화된 학습 계획이 나온다.
“Same code calling the same API, just a more capable model underneath.”
이 문장이 Core AI 설계 철학의 핵심이다. 플랫폼에 따라 모델만 바꾸면 되고, 코드는 그대로다.
서버가 없다는 게 의미하는 것
세션을 관통하는 한 문장이 있다:
“There’s no server to manage, no cost per token, and no latency to the cloud.”
이건 기술적 장점 나열이 아니다. 개발자 경험의 근본적 변화를 선언하는 것이다.
- 서버 관리가 없다는 건, 인프라 팀이 필요 없다는 게 아니다. 백엔드 자체가 필요 없다는 뜻이다.
- 토큰 비용이 없다는 건, 사용자가 많아질수록 비용이 선형으로 증가하는 구조에서 벗어난다는 뜻이다.
- 클라우드 지연이 없다는 건, 200ms 왕복 레이턴시가 아니라 기기 내부 연산 속도가 병목이라는 뜻이다.
Apple이 Core AI를 통해 만들려는 건, 온디바이스 AI의 실전 배포를 당연하게 만드는 것이다. 모델 발견 → 변환 → 최적화 → AOT 컴파일 → 배포 → 런타임, 이 전체 파이프라인을 하나의 생태계 안에 넣었다.
남은 질문들
이 세션은 핸즈온이었기에 깊이 들어가지 못한 영역이 있다.
모델 생태계의 제한: Core AI Models 리포지토리에 없는 모델은 PyTorch 확장으로 직접 변환해야 한다. 지원되는 아키텍처의 범위가 어디까지인지, 변환 과정에서 어떤 제약이 있는지는 별도 세션(“Dive into Core AI model authoring and optimization”)에서 다룬다.
에러 핸들링과 엣지 케이스: 세그멘테이션이 실패하거나 언어 모델이 구조화된 출력을 생성하지 못할 때 어떻게 처리하는지는 다루지 않았다.
성능 한계: iPhone에서 Qwen 6B + SAM 3가 실제로 몇 초 걸리는지, 배터리 소모는 어느 정도인지에 대한 구체적인 수치가 없었다.
그럼에도 이 세션은 온디바이스 AI가 어떻게 실제 앱에 통합되는지를 보여준 가장 구체적인 사례 중 하나였다. 프레임워크의 존재를 아는 것과, 실제로 돌아가는 앱을 만드는 것 사이의 간극을 Core AI가 어떻게 메우려 하는지가 잘 드러난 25분이었다.
이 글은 WWDC26 세션 “Integrate on-device AI models into your app using Core AI”의 핸즈온 내용을 바탕으로 정리했습니다.