iOS 26.4 RC 기준
Foundation Models SDK v1.0
Foundation Models,
한국어 앱에선 조건이 다릅니다
iOS 26.4에서 모델이 교체됐습니다. 지침 준수와 도구 호출 성능이 높아진 건 맞습니다. 그런데 공식 문서를 읽으면 한국어 앱에만 적용되는 조건이 따로 있습니다. 4,096토큰이라는 숫자가 영어 앱과 한국어 앱에서 완전히 다르게 작동한다는 게 핵심입니다.
iOS 26.4에서 정확히 무엇이 바뀌었나
iOS 26.4 업데이트와 함께 Foundation Models 프레임워크의 온디바이스 모델 자체가 교체됐습니다. Apple 공식 업데이트 문서에 딱 이렇게 나옵니다. “지침 준수(instruction-following)와 도구 호출(tool-calling) 능력을 향상시킨 최신 온디바이스 대규모 언어 모델을 사용하십시오.” (출처: Apple Developer Documentation — Foundation Models updates, 2026.02)
여기서 놓치면 안 되는 문장이 바로 다음에 나옵니다. “iOS 26.4로 업데이트할 때 모델이 변경되므로, 새 모델에서 프롬프트를 테스트해 앱 동작을 확인하고, 필요하다면 각 모델 버전별로 프롬프트를 업데이트하고 유지 관리하십시오.” 성능이 좋아졌다고 마냥 좋아할 수만은 없는 이유가 여기 있습니다.
이번 업데이트에는 세 가지 실질적인 변화가 함께 왔습니다. 첫째, 안전 필터(guardrails) 오탐률 감소로 멀쩡한 콘텐츠가 차단되는 경우가 줄었습니다. 둘째, 세션 내 토큰 사용량을 직접 측정할 수 있는 tokenCount(for:) 메서드가 추가됐습니다. 셋째, 컨텍스트 윈도우 최대 크기를 하드코딩 없이 가져오는 contextSize 속성이 생겼습니다.
4,096토큰이 한국어에서 실제로 얼마나 되는가
Foundation Models 프레임워크의 온디바이스 모델은 세션당 최대 4,096토큰을 처리합니다. 그런데 이 숫자가 영어와 한국어에서 완전히 다르게 느껴집니다. Apple 공식 기술 문서에 직접 나와 있습니다. “영어·스페인어 등 라틴 알파벳 언어는 1토큰 ≈ 3~4글자, 한국어·중국어·일본어는 1토큰 ≈ 1글자입니다.” (출처: Apple TN3193 — Managing the on-device foundation model’s context window, 2025.10.06)
💡 공식 수치와 실제 사용 흐름을 같이 놓고 보니 이런 차이가 보였습니다
4,096토큰을 순수 텍스트에만 쓸 수 있다고 가정하면, 영어 입력+출력은 약 12,000~16,000글자를 담을 수 있습니다. 하지만 한국어는 최대 4,096글자에서 출발합니다. 시스템 지침, 프롬프트, 툴 정의, 이전 응답이 모두 이 예산을 소진한다는 걸 감안하면, 한국어 앱에서 실제로 모델에 전달할 수 있는 본문 텍스트는 영어의 약 3~4분의 1 수준입니다.
| 언어 | 1토큰당 글자 | 4,096토큰 ≈ 글자 수 | A4 1장(약 800자) 기준 |
|---|---|---|---|
| 영어 | 3~4글자 | 12,000~16,000자 | 약 15~20장 |
| 한국어 | 1글자 | 4,096자 | 약 5장 |
한국어 앱에서 긴 대화를 구현하려 할 때 생각보다 빠르게 한계에 부딪히는 실제 원인이 여기 있습니다. 4,096이라는 숫자가 동일해도, 한국어 사용자는 영어 사용자가 쓸 수 있는 맥락의 4분의 1밖에 확보하지 못하는 겁니다.
Tool Calling을 추가하면 공간이 오히려 줄어드는 이유
iOS 26.4에서 Tool Calling 성능이 향상됐다는 소식에 바로 적용하려는 분들이 있을 겁니다. 그런데 여기서 한 가지를 먼저 알고 가야 합니다. 도구를 등록한다는 건 단순히 모델에 기능을 “추가”하는 게 아닙니다. 도구 이름, 설명, 파라미터 스키마가 JSON으로 직렬화되어 프롬프트 앞에 붙으면서 토큰 예산을 직접 소진합니다.
💡 도구를 등록할수록 실제 입력에 쓸 수 있는 공간이 줄어드는 구조입니다
실제 개발자 아르트욤 노비치코프(Artem Novichkov)가 측정한 결과, 툴 정의 하나가 수십~수백 토큰을 소비합니다. Apple이 공식 기술 문서에서 권고하는 최대 도구 수가 3~5개인 이유가 바로 이것입니다. (출처: Apple TN3193, 2025.10.06 / artemnovichkov.com, 2026.02.17)
Apple 공식 문서의 권고 사항은 이렇습니다. “도구 설명과 @Guide 설명은 각각 짧은 한 문장으로 유지하고, 모델에 제공하는 도구는 최대 3~5개로 제한하십시오.” 그리고 더 핵심적인 조언이 이어집니다. 모델이 도구를 사용할지 판단할 필요 없이 항상 특정 도구의 정보가 필요하다면, 아예 도구 호출을 건너뛰고 프롬프트를 구성하기 전에 코드로 직접 실행해서 결과를 프롬프트에 포함시키는 편이 낫습니다.
도구가 많아질수록 공간이 줄고, 공간이 줄수록 한국어 앱은 더 빠르게 한계에 닿습니다. Tool Calling 개선이 반가운 기능인 건 맞지만, 등록 전에 토큰 예산을 먼저 계산하는 순서가 필요합니다.
모델이 바뀌면 기존 프롬프트가 망가질 수 있습니다
이번 업그레이드에서 가장 조심해야 할 부분이 있습니다. 성능이 높아진 건 사실이지만, Apple은 공식 changelog에서 명시적으로 경고합니다. “iOS 26.4로 업데이트될 때 모델이 변경되므로, 새 모델에서 프롬프트를 테스트해 앱 동작을 검증하십시오. 필요하면 각 모델 버전별로 프롬프트를 따로 관리하십시오.” (출처: Apple Developer Documentation — Foundation Models updates, 2026.02)
왜 이게 문제가 되냐면, Foundation Models는 OS 업데이트와 모델 업데이트가 묶여 있기 때문입니다. 사용자가 iOS 26.4로 올리는 순간 앱이 사용하는 모델이 바뀝니다. 개발자가 선택할 수 없습니다. 지난 버전 모델을 고정해서 배포하는 것도 불가능합니다. 즉, 앱스토어 심사를 통과해 배포 중인 앱도 사용자의 OS 업데이트 한 번으로 프롬프트 동작이 바뀔 수 있습니다.
실제 개발 현장에서 이 패턴을 겪은 사례가 이미 나오고 있습니다. Medium 기사(wesleymatlock, 2026.03.24)에서 VinylCrate 앱 사례가 이를 잘 보여줍니다. 구조화 출력(@Generable)에서 문자열 필드의 @Guide 설명은 “강한 권고”일 뿐 강제가 아니라서, 모델이 바뀌면 같은 설명에도 다른 길이의 응답이 나올 수 있습니다. 배포 전 iOS 26.4 환경에서 반드시 재검증이 필요한 이유입니다.
2026년 3월, Swift 없이도 쓸 수 있게 됐습니다
Foundation Models는 iOS·macOS 앱 개발자를 위한 Swift 전용 프레임워크라는 인식이 강했습니다. 그런데 2026년 2월에 Apple이 Python SDK를 오픈소스로 공개했습니다. 이름은 Foundation Models SDK for Python이고, GitHub 저장소는 apple/python-apple-fm-sdk입니다. (출처: GitHub apple/python-apple-fm-sdk, 2026.02.25 / Apple Developer Documentation — Foundation Models updates, 2026.03)
💡 Python SDK가 나온 배경을 공식 문서와 함께 보면 이 맥락이 분명해집니다
Apple이 밝힌 Python SDK의 주 용도는 앱 품질 평가입니다. Swift 앱이 Foundation Models로 생성한 결과물을 Python의 데이터 분석 생태계로 가져와 배치 추론과 품질 측정을 할 수 있게 하는 것이 목적입니다. 단순히 Python에서 온디바이스 AI를 실행하는 수단이기도 하지만, 애초 설계 의도는 앱 개발 → 평가 → 개선 루프를 Python 도구로 지원하는 데 있습니다.
사용 요건은 macOS 26.0 이상, Python 3.10 이상, Xcode 26.0 이상, Apple Intelligence 활성화입니다. pip install apple-fm-sdk 한 줄로 설치할 수 있으며, Swift의 @Generable에 해당하는 @fm.generable 데코레이터도 제공합니다. 단, 현재는 외부 기여를 받지 않는 상태라고 README에 명시되어 있습니다.
클라우드 API와 비교하면 어디서 갈리나
Foundation Models와 클라우드 AI API(Claude, GPT 등)는 근본적으로 설계 목적이 다릅니다. 상황에 따라 어느 쪽을 택할지가 달라지는 기준이 명확합니다. 실제 앱 구현 사례(VinylCrate, wesleymatlock 2026.03.24)와 공식 문서를 교차해서 정리하면 이렇습니다.
| 비교 항목 | Foundation Models (온디바이스) | 클라우드 AI API |
|---|---|---|
| 토큰당 비용 | 없음 (OS 포함) | 호출당 과금 |
| 컨텍스트 윈도우 | 4,096토큰 (고정) | 128K~1M 토큰 |
| 프라이버시 | 완전 온디바이스 | 서버 전송 필요 |
| 오프라인 사용 | 가능 | 불가 |
| 구조화 출력 | @Generable (타입 안전) | JSON 파싱 필요 |
| 멀티모달 | 텍스트 전용 | 이미지·음성 등 지원 |
| 모델 업데이트 주기 | OS 업데이트에 종속 | 서비스 측 자체 제어 |
| 파인튜닝 | 특별 권한 필요 | 일부 지원 |
솔직히 말하면, 두 가지를 함께 쓰는 하이브리드 접근이 현실적입니다. 개인 데이터를 다루거나 화면 전환마다 추론이 필요한 고빈도 기능은 온디바이스, 긴 문서 분석이나 복잡한 다단계 추론은 클라우드 API로 분리하면 둘의 약점을 서로 보완할 수 있습니다.
Q&A
Q1. Foundation Models는 Apple Intelligence가 없는 기기에서도 쓸 수 있나요?
쓸 수 없습니다. SystemLanguageModel.default.availability가 .unavailable(.deviceNotEligible)를 반환하는 기기, 사용자가 Apple Intelligence를 끈 경우, 모델이 아직 다운로드 중인 경우 모두 사용 불가 상태입니다. 앱에서 이 세 가지 경우를 각각 구분해서 UI를 따로 처리해야 합니다. (출처: Apple Developer Documentation — Foundation Models, 2025)
Q2. iOS 26.4 업데이트 후 기존 앱을 재제출해야 하나요?
재제출은 필수가 아닙니다. 하지만 Apple 공식 changelog에서 “새 모델에서 프롬프트를 테스트해 앱 동작을 검증하고, 필요하면 프롬프트를 업데이트 및 유지 관리하라”고 명시하고 있습니다. (출처: Apple Developer Documentation — Foundation Models updates, 2026.02) 특히 구조화 출력을 쓰거나 정밀한 길이 제어가 필요한 기능이라면 반드시 iOS 26.4 환경에서 재검증이 필요합니다.
Q3. Python SDK는 iPhone에서도 돌아가나요?
iPhone에서는 안 됩니다. 현재 Python SDK의 요구 사항은 macOS 26.0 이상이며, iOS는 지원 대상이 아닙니다. 주 용도는 Mac에서 Swift 앱의 Foundation Models 기능을 평가하고 배치 추론을 돌려보는 것입니다. (출처: GitHub apple/python-apple-fm-sdk README, 2026.02.25)
Q4. 4,096토큰 한도가 앞으로 늘어날 가능성이 있나요?
Apple이 공식 답변을 내놓지 않은 부분입니다. 커뮤니티(Reddit r/vibecoding, 2026.03.15)에서도 논의는 활발하지만, 공식 로드맵은 공개된 게 없습니다. 현재 Apple 공식 문서는 4,096토큰을 고정 제약으로 다루며, 이를 전제로 한 컨텍스트 관리 전략을 권고하고 있습니다.
Q5. tokenCount(for:)와 contextSize는 언제부터 쓸 수 있나요?
iOS 26.4부터 추가됐지만, @backDeployed(before: iOS 26.4)로 표시되어 Foundation Models를 지원하는 이전 iOS 버전에서도 사용 가능합니다. 즉, 최소 지원 버전을 올리지 않아도 이 두 메서드를 쓸 수 있습니다. (출처: InfoQ — Apple Improves Context Window Management, 2026.03.23)
마치며
Foundation Models는 분명히 매력적인 프레임워크입니다. 비용 없이, 인터넷 없이, 개인정보 걱정 없이 앱에 AI 기능을 넣을 수 있다는 건 실제로 강력한 장점입니다. iOS 26.4에서 지침 준수와 Tool Calling 성능이 올라간 것도 사실이고, Python SDK로 평가 루프를 돌릴 수 있게 된 것도 의미 있는 변화입니다.
다만, 막상 한국어 앱에 적용해 보면 느끼는 게 있습니다. 4,096토큰이라는 숫자가 영어 문서에서 읽을 때와 실제로 한국어 텍스트를 채워봤을 때 체감이 완전히 다릅니다. 1글자가 1토큰인 구조에서 시스템 지침과 툴 정의까지 더하면, 실제로 쓸 수 있는 공간이 생각보다 훨씬 빨리 줄어듭니다.
iOS 26.4로 업데이트됐을 때 기존 프롬프트를 재검증해야 한다는 공식 경고도 현업에서는 생각보다 손이 많이 가는 작업입니다. 이 두 가지를 미리 알고 설계에 반영하는 것, 그게 Foundation Models를 한국어 앱에서 제대로 쓰는 출발점입니다.
📎 본 포스팅 참고 자료
- Apple Developer Documentation — Foundation Models updates
https://developer.apple.com/documentation/updates/foundationmodels - Apple TN3193 — Managing the on-device foundation model’s context window (2025.10.06)
https://developer.apple.com/documentation/technotes/tn3193-managing-the-on-device-foundation-model-s-context-window - GitHub — apple/python-apple-fm-sdk (2026.02.25)
https://github.com/apple/python-apple-fm-sdk - InfoQ — Apple Improves Context Window Management for Foundation Models (2026.03.23)
https://www.infoq.com/news/2026/03/apple-foundation-models-context - Apple Newsroom — Apple’s Foundation Models framework unlocks new intelligent app experiences (2025.09.29)
https://www.apple.com/newsroom/2025/09/apples-foundation-models-framework-unlocks-new-intelligent-app-experiences/
※ 본 포스팅은 2026년 3월 26일 기준, iOS 26.4 RC 및 Foundation Models SDK for Python v1.0 기준으로 작성됐습니다. 본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있습니다. 최신 정보는 Apple Developer Documentation에서 확인하시기 바랍니다.
댓글 남기기