Foundation Models 사용 사례: 언제 특화하고 언제 그냥 프롬프팅할 것인가

Foundation Models의 온디바이스 모델은 단일한 무언가가 아닙니다. Apple은 일반 프롬프팅용 기본 SystemLanguageModel과 콘텐츠 태깅을 위한 Apple 관리형 특화 버전 하나를 함께 제공합니다.¹ 또한 이 프레임워크는 개발자가 자체 어댑터를 학습시켜 로드할 수 있도록 허용합니다.² 세 개의 레일, 하나의 결정 트리, 그리고 정확히 두 개의 UseCase 값을 명시한 문서 페이지입니다.

Tool 프로토콜에 관한 이전 글은 기본 모델로 유용한 작업을 수행하는 방법을 다뤘습니다. 이 글이 답하는 질문은 그다음 단계입니다: 프롬프팅과 도구를 갖춘 기본 모델로 충분한 시점은 언제이며, Apple의 .contentTagging 사용 사례가 자기 자리를 차지하는 시점은 언제인가? 커스텀 어댑터 경로는 별도의 글로 다룹니다. 개발자 관리형 라이프사이클은 결정 루브릭과 함께 다루기에는 표면적이 너무 넓습니다.

TL;DR

• SystemLanguageModel.UseCase는 두 개의 정적 속성을 가진 구조체입니다: .general과 .contentTagging.³ 다른 사용 사례는 문서화되어 있지 않습니다.
• .general이 기본값입니다. 가장 먼저 손을 뻗으세요. 프롬프팅, 지시사항, 가이드 생성, 도구 호출은 모두 .general 위에서 동작합니다. 특화는 마지막에 당기는 레버입니다.
• .contentTagging은 한 가지 작업을 위해 특별히 설계되었습니다: 입력 텍스트에서 주제, 행동, 객체, 감정을 식별하고 한 단어에서 몇 단어 길이의 소문자 태그를 반환합니다.⁴ Apple 자체 가이드는 대신 .general을 사용해야 할 때를 알려줍니다.
• 세 번째 레일(커스텀 어댑터, Adapter 타입, 엔타이틀먼트, 툴킷)은 운영 복잡성이 자리 잡은 곳입니다. 다른 글에서 다룹니다.

SystemLanguageModel은 실제로 무엇인가

SystemLanguageModel은 FoundationModels 프레임워크의 final class로, iOS 26.0+, iPadOS 26.0+, Mac Catalyst 26.0+, macOS 26.0+, visionOS 26.0+에서 사용 가능합니다.¹ Apple은 이를 “텍스트 생성 작업이 가능한 온디바이스 대규모 언어 모델”이라고 설명합니다.

이를 사용하는 방식은 두 가지 사실이 좌우합니다. 첫째, SystemLanguageModel.default는 모델의 기본 버전을 반환합니다.¹ 이것이 특화되지 않은 모든 작업의 진입점입니다. 둘째, Apple은 OS 업데이트를 통해 모델을 갱신합니다. 작성 시점 기준으로 Apple 문서는 두 가지 모델 버전을 나열하고 있는데, 하나는 iOS, iPadOS, macOS, visionOS 26.0–26.3용이고 다른 하나는 26.4용입니다.¹ 앱은 특정 버전을 고정하지 않으며, 프레임워크는 OS가 현재 실행 중인 어떤 모델이든 반환합니다.

가용성은 런타임에 확인됩니다. SystemLanguageModel.availability는 Apple의 샘플 코드에 문서화된 다음 케이스들을 가진 Availability 열거형입니다:¹

struct GenerativeView: View {
    private var model = SystemLanguageModel.default

    var body: some View {
        switch model.availability {
        case .available:
            // Show your intelligence UI.
        case .unavailable(.deviceNotEligible):
            // Show an alternative UI.
        case .unavailable(.appleIntelligenceNotEnabled):
            // Ask the person to turn on Apple Intelligence.
        case .unavailable(.modelNotReady):
            // The model isn't ready because it's downloading or because
            // of other system reasons.
        case .unavailable(let other):
            // The model is unavailable for an unknown reason.
        }
    }
}

isAvailable은 시스템이 완전히 준비되었을 때만 true를 반환하는 편의 게터입니다.¹ 호출하기 전에 항상 확인하세요.

첫 번째 레일: 일반 모델에 프롬프팅하기

Apple은 기본 모델을 다양한 범위의 작업에 적합한 도구로 위치시킵니다. 프레임워크의 일반 가이드는 Apple이 온디바이스 모델이 잘 처리한다고 밝힌 능력들을 나열합니다:⁴

Apple은 또한 온디바이스 모델이 적합하지 않은 작업에 대해서도 명시적입니다:⁴

“텍스트에서 태그 생성”이 일반 모델의 잘하는 작업 표에 등장한다는 점에 주목하세요. 이는 아래 특화 결정에서 중요한 맥락입니다.

기본 레일은 전체 도구 모음을 사용할 수 있습니다: 지시사항, 프롬프트, Generable을 통한 가이드 생성, Tool 프로토콜을 통한 도구 호출, 그리고 temperature 같은 생성 옵션. Foundation Models를 도입하는 대부분의 앱은 이 레일에서 동작하며 사용 사례 지정자를 건드릴 일이 없을 것입니다.

시스템 모델의 컨텍스트 윈도우는 4,096 토큰입니다.⁴ Apple은 영어, 스페인어, 독일어 같은 언어에서 토큰 하나가 3~4개의 문자에 해당하며, 일본어, 중국어, 한국어 같은 언어에서는 문자 하나당 토큰 하나에 해당한다고 명시합니다. 지시사항, 프롬프트, 출력 모두 한도에 포함됩니다. 세션이 한도를 초과하면 프레임워크는 LanguageModelSession.GenerationError.exceededContextWindowSize(_:)를 던집니다.⁴

두 번째 레일: .contentTagging

SystemLanguageModel.UseCase는 두 개의 정적 속성을 가진 struct(열거형이 아님)로 문서화되어 있습니다:³

static let general: SystemLanguageModel.UseCase
static let contentTagging: SystemLanguageModel.UseCase

다른 문서화된 케이스는 없습니다. 어떤 글이 세 번째 사용 사례를 언급한다면, 그 글은 지어내고 있는 것입니다.

.contentTagging은 .general과 다른 모양을 갖습니다. Apple의 가이드는 contentTagging 모델을 “입력 텍스트에서 주제, 행동, 객체, 감정을 식별하는” 모델로 설명하며 태그를 “한 단어에서 몇 단어 길이의 소문자”로 생성한다고 명시합니다.⁵ 이 모델은 대화식으로 응답하기보다는 입력을 평가하도록 만들어졌습니다: “사람의 질의에 응답하는 일반적인 언어 모델이 아닙니다. 대신 제공한 입력을 평가하고 그룹화합니다.”⁵

.contentTagging으로 모델을 로드하기:

let model = SystemLanguageModel(useCase: .contentTagging)
let session = LanguageModelSession(
    model: model,
    instructions: """
        Provide the two tags that are most significant in the context of topics.
        """
)

문서화된 편의 이니셜라이저는 init(useCase:guardrails:)입니다.¹ Apple의 샘플 코드는 guardrails 인자 없이 호출하는데, 이는 guardrails가 호출 측에서 기본값을 갖는다는 것을 시사합니다.

contentTagging 모델은 Generable과 통합되므로, 원하는 태그의 형태를 포착하는 Swift 타입을 정의할 수 있습니다:

@Generable
struct ContentTaggingResult {
    @Guide(
        description: "Most important actions in the input text.",
        .maximumCount(2)
    )
    let actions: [String]

    @Guide(
        description: "Most important emotions in the input text.",
        .maximumCount(3)
    )
    let emotions: [String]

    @Guide(
        description: "Most important objects in the input text.",
        .maximumCount(5)
    )
    let objects: [String]

    @Guide(
        description: "Most important topics in the input text.",
        .maximumCount(2)
    )
    let topics: [String]
}

let response = try await session.respond(
    to: prompt,
    generating: ContentTaggingResult.self
)

Apple의 가이드에는 유용한 동작 관련 메모가 포함되어 있습니다: “매우 짧은 입력 질의의 경우, 주제 및 감정 태깅 지시사항이 가장 좋은 결과를 제공합니다. 행동 또는 객체 목록은 너무 구체적이며 질의의 단어를 반복할 수 있습니다.”⁵ contentTagging 모델은 또한 “지시사항이 없는 경우에도 원하는 출력 형식을 따르므로”, Generable 형태가 장황한 시스템 프롬프트보다 더 큰 비중을 차지합니다.

결정 트리 (Apple 자신의 표현으로)

사용 사례 API의 흥미로운 부분은 Apple 문서가 언제 특화하지 말아야 하는지에 대해 명시적이라는 점입니다. contentTagging 가이드에서:⁵

1. “행동, 객체, 감정 또는 주제가 아닌 콘텐츠에 태그를 지정하는 경우 대신 general을 사용하세요.”
2. “소셜 미디어 게시물용 해시태그와 같은 콘텐츠를 생성하려면 general 모델을 사용하세요.”
3. “도구 호출 API을 채택하고 태그를 생성하려는 경우, general을 사용하고 Tool 출력을 content tagging 모델에 전달하세요.”
4. “태깅 모델의 maximum count 지원보다 더 복잡한 태깅 제약 조건이 있는 경우 대신 general을 사용하세요.”

이 네 가지를 함께 읽어보세요. contentTagging 모델은 좁게 범위가 정해져 있습니다: 주제, 행동, 객체, 감정. 그 외의 모든 것(해시태그 생성, 도구 호출이 관여하는 태그 파이프라인, maximumCount보다 풍부한 제약을 가진 태그 출력)은 일반 모델에 속합니다.

태깅을 원한다고 생각하는 앱을 위한 실용적인 결정 루브릭:

기본값으로 .general을 사용하세요. Apple의 표가 설명하는 광범위한 생성 작업, “텍스트에서 태그 생성”을 포함해 처리합니다. 대부분의 앱은 여기서 멈춥니다.

다음의 경우에만 .contentTagging에 손을 뻗으세요. 입력이 텍스트 형태이고, 출력이 Apple의 네 가지 카테고리(주제/행동/객체/감정)에 깔끔하게 들어맞는 한 단어에서 몇 단어 길이의 작은 태그 집합이며, 제약이 maximumCount에 적합한 경우입니다. Apple이 제시하는 예시가 그 패턴입니다: 주제 대시보드를 구동할 게시물별 태그를 원하는 소셜 앱, 자동 라벨링을 원하는 이메일 클라이언트, 집계된 트렌드 신호를 원하는 콘텐츠 스토어.

커스텀 어댑터로 미루세요. 두 레일 모두 적합하지 않고, 사용 사례가 특정 시스템 모델 버전에 묶인 어댑터를 학습시키고 배포하는 운영 비용을 흡수할 만큼 가치가 높을 때만 그렇게 하세요. 커스텀 어댑터 경로는 별도로 문서화되어 있습니다. 라이프사이클 복잡성(툴킷 버전, 재학습 주기, 배포)은 자체적인 다룸이 필요합니다.

Apple이 발표하지 않은 것

문서화된 표면에 없는데도 추측이 분분한 몇 가지 사항이 있습니다:

• Apple이 모델을 .contentTagging용으로 특화하는 데 사용하는 메커니즘. Apple의 contentTagging 가이드는 프레임워크가 “콘텐츠 태깅에 특화된 적응된 온디바이스 시스템 언어 모델”을 제공한다고 설명합니다.⁵ Apple은 특화 메커니즘을 공개하지 않으며, 그 문장의 “적응된”이라는 동사는 별도의 레일인 개발자 관리형 SystemLanguageModel.Adapter 타입과 혼동해서는 안 됩니다.
• 다른 사용 사례 값들. 현재 문서 기준으로 구조체에는 두 개의 정적 속성이 있습니다. 세 번째 케이스는 향후 OS 업데이트로 출시되어야 할 것입니다.
• .general과 .contentTagging이 항상 공존한다는 보장. Apple은 “Apple은 정기적인 OS 업데이트로 SystemLanguageModel을 주기적으로 갱신해 온디바이스 모델의 능력과 성능을 개선할 것”이라고 말합니다.¹ 이 표면을 버전 관리되는 것으로 취급하세요.
• 태깅 벤치마크에서 .contentTagging 대비 .general의 구체적인 품질 수치. Apple은 이 선택을 작업 적합성 문제로 위치시키지, 품질 순위표로 두지 않습니다.

어떤 글이(이 글이든 다른 글이든) developer.apple.com에 없는 어댑터 메커니즘에 대한 정량적 주장을 한다면, 그 주장은 기본적으로 틀린 것으로 간주하세요.

두 레일이 실제로 안겨주는 것

두 번째 레일은 “모델이 더 좋아진다”가 아닙니다. “모델이 한 가지 작업을 위해 만들어졌고 Apple이 언제 그것을 선택할지 문서화했다”입니다. 이는 경제성을 바꿉니다:

1. 태깅 작업에 대한 프롬프트 엔지니어링 표면 감소. contentTagging 모델은 “지시사항이 없는 경우에도 원하는 출력 형식을 따릅니다.”⁵ 일반 모델에서 필요했을 여러 단락의 프롬프트 대신 @Generable과 maximumCount에 의존할 수 있습니다.
2. 제약된 의미론적 형태. 모델은 입력 용어 간의 유사성을 찾아 의미론적으로 일관된 태그를 생성합니다(Apple의 예시: “hi”, “hello”, “yo”의 주제 태그로 “greet”이 등장합니다).⁵ 이는 사용자 생성 콘텐츠에 대한 집계 분석이 정확히 필요로 하는 것입니다.
3. 문서화된 결정 루브릭. Apple은 자신들의 특화가 적합한 시점과 대안으로 돌아갈 시점을 알려줍니다. 그 루브릭이 사용 사례 API의 가장 가치 있는 부분입니다: 앱 개발자들이 그렇지 않으면 제1원칙에서부터 다툴 질문에 대한 의견 있는 답변입니다.

비용도 명확합니다: .contentTagging은 한 가지 작업 형태에 묶여 있습니다. 그 형태를 벗어나는 것은 모두 .general로 돌아가며, 프롬프트와 Generable 설계에 따라 살거나 죽습니다.

핵심 정리

1. 오늘은 두 레일, 나중에는 더 많을 가능성. .general과 .contentTagging은 Apple이 문서화한 유일한 두 개의 UseCase 정적 속성입니다. 다른 것이 있다고 가정하는 코드를 작성하지 마세요.
2. 기본값으로 .general을 사용하세요. 프롬프팅 + 도구 + 가이드 생성은 온디바이스 모델이 설계된 대부분의 사용 사례를 처리합니다. 특화는 첫 번째가 아니라 마지막 레버입니다.
3. .contentTagging은 Apple이 문서화한 형태에 맞을 때만 선택하세요. 주제, 행동, 객체, 감정. 한 단어에서 몇 단어 길이의 소문자 태그. maximumCount 수준의 제약. 그 이상이라면, 대안으로 돌아가세요.
4. Apple의 “대신 general을 사용하세요” 규칙을 읽으세요. contentTagging 가이드의 네 개의 구체적인 문장입니다.⁵ 각각이 실제 경계입니다.
5. 커스텀 어댑터 경로는 별도의 결정입니다. 다른 표면적, 다른 라이프사이클, 다른 글.

전체 Apple Ecosystem 클러스터: 프레임워크의 기본 요소를 다루는 온디바이스 LLM과 Tool 프로토콜; 인앱과 개발자 도구 LLM 사이의 에이전틱 워크플로 분기; 세 가지 모두에 걸친 라우팅 질문을 다루는 App Intents 대 MCP. 허브는 Apple Ecosystem 시리즈에 있습니다. AI 에이전트를 활용한 더 폭넓은 iOS 맥락은 iOS Agent Development 가이드를 참조하세요.

FAQ

SystemLanguageModel.UseCase 값은 몇 개인가요?

현재 문서 기준 두 개의 정적 속성입니다: .general과 .contentTagging.³ 튜토리얼이나 LLM이 생성한 답변에서 세 번째 값이 언급되는 것을 본다면, 채택하기 전에 developer.apple.com에서 확인하세요.

단순히 .general에 프롬프팅하는 대신 언제 .contentTagging을 사용해야 하나요?

작업이 입력 텍스트에서 주제, 행동, 객체 또는 감정을 식별하고 짧은 소문자 태그를 반환하는 것일 때 .contentTagging을 사용하세요. Apple의 가이드는 .general이 대신 정답인 네 가지 시나리오를 나열합니다: 그 네 가지 카테고리에 맞지 않는 태깅, 해시태그 생성, 도구 호출을 통해 라우팅되는 태그 파이프라인, maximumCount보다 풍부한 태깅 제약 조건.⁵

contentTagging 모델은 일반 모델처럼 임의의 지시사항을 받아들이나요?

지시사항을 받아들이지만, 모델의 설계는 사용자 스타일의 질의에 응답하기보다는 입력을 평가하는 것입니다. Apple의 가이드는 contentTagging 모델이 “지시사항이 없는 경우에도 원하는 출력 형식을 따른다”고 명시하므로, @Guide 어노테이션이 있는 @Generable 형태가 제약을 운반하지 긴 프롬프트가 아닙니다.⁵

온디바이스 모델의 컨텍스트 윈도우는 얼마인가요?

시스템 모델 기준 4,096 토큰입니다.⁴ 토큰 대 문자 비율은 영어/스페인어/독일어에서 토큰당 대략 3~4개 문자, 일본어/중국어/한국어에서는 문자당 토큰 하나입니다. 세션이 한도를 초과하면 프레임워크는 LanguageModelSession.GenerationError.exceededContextWindowSize(_:)를 던집니다.

Apple의 샘플 코드는 왜 SystemLanguageModel(useCase:)을 guardrails: 없이 호출하나요?

문서화된 편의 이니셜라이저는 init(useCase:guardrails:)입니다.¹ Apple의 contentTagging 가이드는 guardrails 인자 없이 호출하는데, 이는 guardrails가 호출 측에서 기본값을 갖는다는 것을 시사합니다. 두 인자 형태가 문서화된 표면이며, 한 인자 형태는 Apple이 발표한 샘플 코드가 보여주는 것입니다.

References