애플의 새로운 Speech 프레임워크: SpeechAnalyzer와 SFSpeechRecognizer 비교

iOS 26은 기존 SFSpeechRecognizer와 나란히 새로운 음성 인식 프레임워크를 도입했습니다. 새 API의 중심은 SpeechAnalyzer이며, 그 주위에 조합되는 모듈(SpeechTranscriber, SpeechDetector)이 함께 놓입니다¹. 애플 자신의 설명에 따르면 SpeechAnalyzer가 현대적인 선택지입니다. 새로운 온디바이스 모델, 장문 오디오 지원, 자동 언어 관리, 실시간 사용 사례를 위한 낮은 지연 시간, 그리고 앞으로 분석 유형을 계속 추가할 수 있는 모듈형 아키텍처를 갖추고 있습니다. SFSpeechRecognizer도 계속 제공되며 정상적으로 동작합니다. 남아 있을 이유는 구버전 OS 지원과 한 가지 좁은 공백입니다. 그 공백이란 새 프레임워크의 장문용 SpeechTranscriber 모델에서의 커스텀 어휘를 말하며, 짧은 발화용 DictationTranscriber 경로는 contextual strings를 받아들입니다.

이 글은 새 프레임워크와 기존 프레임워크를 나란히 놓고 살펴봅니다. 관점은 “새 API를 어떻게 쓰는가”가 아니라 “언제 마이그레이션할 것인가”입니다. 이미 동작하는 SFSpeechRecognizer 통합을 가진 팀이라면 모두 같은 판단을 마주하기 때문입니다. 새 프레임워크의 현대적인 모델과 아키텍처가 마이그레이션 비용만큼의 가치가 있는가, 아니면 기존에 쌓아 온 커스텀 어휘 투자가 그대로 남을 이유가 되는가 하는 판단입니다.

요약

• SpeechAnalyzer(iOS 26 이상)는 애플의 현대적인 온디바이스 음성 인식 프레임워크입니다. 초기화 시점에 구성한 분석 모듈을 조율하며, iOS 26에는 세 가지 모듈이 함께 제공됩니다. SpeechTranscriber(장문용), DictationTranscriber(짧은 발화용이며 SFSpeechRecognizer에 대응), SpeechDetector(음성 활동 감지이며 반드시 트랜스크라이버와 함께 써야 함)입니다².
• 새 프레임워크는 강의, 회의, 다중 화자 대화 같은 장문 오디오를 중심에 두고 만들어졌습니다. 전부 온디바이스에서 실행되고 로케일별 모델 자산을 자동으로 처리하며, 동등한 전사 작업에서 Whisper Large V3 Turbo보다 2배 빠르다고 보고된 애플의 새 독자 모델을 탑재합니다³.
• SFSpeechRecognizer는 계속 제공되고 동작하며, 커스텀 어휘는 더 이상 그쪽만의 기능이 아닙니다. 새 프레임워크의 AnalysisContext.contextualStrings(SpeechAnalyzer.setContext(_:)로 설정)는 DictationTranscriber 경로를 위해 도메인 특화 문구를 최대 100개까지 등록합니다⁶. 남은 공백은 contextual strings를 받지 않는 장문용 SpeechTranscriber 모델입니다.
• 마이그레이션은 전부 아니면 전무가 아니라 기능 단위로 진행합니다. 장문 전사, 더 낮은 지연 시간, 원거리 오디오 품질이 필요한 앱은 SpeechAnalyzer로 옮깁니다. 커스텀 어휘에 투자해 온 앱도 짧은 발화 받아쓰기는 DictationTranscriber와 contextual strings로 옮길 수 있습니다. 레거시 API를 계속 쓸 이유가 남는 것은 커스텀 어휘가 필요한 장문 전사뿐입니다.
• 이 클러스터의 Vision 프레임워크 글은 애플의 또 다른 온디바이스 인지 기본 요소를 다룹니다. SpeechAnalyzer는 같은 온디바이스, 클라우드 없는 패턴을 오디오까지 확장합니다.

아키텍처: 애널라이저와 모듈

SpeechAnalyzer 자체는 트랜스크라이버가 아닙니다. 오디오 분석 세션을 관리하고 오디오 버퍼를 하나 이상의 모듈로 분배하는 조정자입니다². 모듈은 init(modules:) 이니셜라이저를 통해 초기화 시점에 구성하고, 분석은 각각 오디오 버퍼를 감싼 AnalyzerInput 값들의 AsyncSequence를 start(inputSequence:)로 흘려보내면서 시작됩니다.

import Speech

let transcriber = SpeechTranscriber(
    locale: .current,
    transcriptionOptions: [],
    reportingOptions: [.volatileResults],
    attributeOptions: []
)
let analyzer = SpeechAnalyzer(modules: [transcriber])

try await analyzer.start(inputSequence: audioInputSequence)

for try await result in transcriber.results {
    if result.isFinal {
        print(result.text)
    }
}

iOS 26에는 세 가지 모듈이 포함됩니다.

SpeechTranscriber. 장문 오디오(강의, 회의, 다중 화자 대화)를 위해 설계된 음성-텍스트 변환 모듈입니다. 토큰별 타이밍, 신뢰도 점수, 그리고 앱이 for try await로 소비하는 results AsyncSequence와 함께 스트리밍 결과를 반환합니다. 각 결과에는 isFinal 플래그가 있어 임시 부분 가설과 확정된 텍스트를 구분해 줍니다.

DictationTranscriber. 기존 SFSpeechRecognizer 사용 사례를 그대로 대체하는 모듈입니다. SFSpeechRecognizer가 쓰는 것과 동일한 온디바이스 모델로 짧은 발화를 전사합니다. 짧은 질의를 위해 SFSpeechRecognizer에서 옮겨 오는 앱은 DictationTranscriber를, 장문 녹음을 위해 이 프레임워크를 채택하는 앱은 SpeechTranscriber를 선택합니다. 이 구분이 중요한 이유는 SpeechTranscriber와 DictationTranscriber가 서로 다른 언어 지원 범위와 서로 다른 모델 경로를 쓰기 때문입니다.

SpeechDetector. 음성 활동 감지를 담당합니다. 오디오 스트림 안에서 발화가 시작되고 끝나는 시점을 이벤트로 알려 줍니다. 이 디텍터는 단독으로 실행할 수 없고, 같은 SpeechAnalyzer 인스턴스 안에서 트랜스크라이버 모듈 중 하나와 반드시 짝을 이뤄야 합니다. 앱은 이를 이용해 전사 연산을 줄이거나(무음은 전사하지 않기) “지금 말하세요” 같은 UI 신호를 제어합니다.

모듈형 아키텍처는 SFSpeechRecognizer 대비 구조적인 개선점입니다. 기존 API는 설정, 버퍼 처리, 결과 전달을 recognizer와 request 한 쌍에 몰아넣었고 사용자가 설정 앱에서 언어를 켜 두는 것에 의존했습니다. 새 API는 세션 조정자와 분석 모듈을 분리해, 앱이 필요한 것만 조합할 수 있게 합니다.

새 모델이 가져오는 것

SpeechTranscriber 뒤에 있는 전사 모델은 애플이 이 프레임워크를 위해 특별히 개발한 새로운 온디바이스 모델입니다⁴. WWDC 2025에서 애플이 강조한 개선점은 다음과 같습니다.

장문 오디오 품질. 이 모델은 짧은 질의뿐 아니라 수 분에서 수 시간에 이르는 지속적인 전사를 위해 학습되었습니다. 강의, 팟캐스트, 다중 화자 회의, 받아쓰기 세션이 애플이 Whisper급 모델과 견줄 만하다고 내세우는 정확도로 전사됩니다. MacStories의 독립 테스트는 동등한 전사 작업에서 MacWhisper의 Large V3 Turbo 빌드보다 약 2.2배 빠르다고 측정했습니다³.

원거리 오디오 처리. 방 건너편에 놓인 마이크, 여러 화자가 있는 회의 테이블 오디오, 환경 소음이 섞인 오디오가 여기에 해당합니다. 새 모델은 이런 조건을 상정해 학습되었고, SFSpeechRecognizer의 예전 모델은 이런 상황을 그만큼 매끄럽게 다루지 못합니다.

실시간 저지연 동작. SpeechTranscriber에서 오는 스트리밍 결과는 기존 프레임워크의 SFSpeechRecognitionRequest.shouldReportPartialResults 콜백보다 빠르게 도착합니다. 실시간 전사를 화면에 보여 주는 앱(자막, 음성 기반 UI, 받아쓰기)은 더 부드러운 갱신을 얻습니다.

자동 언어 관리. 여기서 애플이 말하는 바(애플의 용어가 아니라 필자의 표현입니다)는 스트림 도중의 언어 전환이 아니라 모델과 자산 관리를 가리킵니다. OS가 AssetInventory를 통해 해당 로케일에 맞는 모델 자산을 내려받아 설치하므로, 앱이 언어별 모델 가용성을 손수 관리할 필요가 없어집니다. 트랜스크라이버 인스턴스가 한 번에 하나의 로케일만 다루는 점은 기존 프레임워크와 같지만, 다국어 지원을 성가시게 만들던 자산 배관은 이제 시스템의 몫입니다.

앱 용량 부담 없음. 모델은 앱이 아니라 OS와 함께 제공됩니다. SpeechAnalyzer를 채택하는 앱은 추가 모델 가중치를 번들에 담지 않아도 됩니다. Whisper급 모델을 앱 번들에 넣는 경우와의 차이는 상당해서, 경쟁력 있는 온디바이스 전사 스택을 번들 용량 0바이트로 얻게 됩니다.

기존 프레임워크가 여전히 제공하는 것

SFSpeechRecognizer는 iOS 26에서도 계속 제공되고 동작합니다. 앱이 이를 계속 쓸 만한 이유는 세 가지입니다.

장문 오디오에서의 커스텀 어휘. SFSpeechRecognitionRequest.contextualStrings를 쓰면 이미 알고 있는 키워드(고유명사, 전문 용어, 제품명) 목록을 등록할 수 있고, 모델이 이를 더 정확하게 인식할 가능성이 높아집니다. 이 기능은 도메인 특화 앱(약품명을 다루는 의료 받아쓰기, 판례 인용을 다루는 법률 앱, 부품 번호를 다루는 엔지니어링 앱)의 정확도를 크게 끌어올립니다. 새 프레임워크에도 받아쓰기 경로를 위한 자체 방식이 있습니다. AnalysisContext.contextualStrings는 태그별로 묶은 문구를 최대 100개까지 받고 SpeechAnalyzer.setContext(_:)로 애널라이저에 설정하며, 여기에 등록한 문구는 시스템 어휘에 없더라도 인식될 수 있습니다⁶. 여기에 더해 DictationTranscriber는 ContentHint.customizedLanguage(modelConfiguration:) 콘텐츠 힌트를 통해 커스텀 언어 모델 구성도 받아들입니다⁷. 아직 대응물이 없는 것은 장문용 SpeechTranscriber 모델의 contextual strings입니다. 즉 장문 전사에서 커스텀 어휘가 필요한 앱은 그 경로를 옮기면 오히려 기능이 후퇴합니다.

구버전 OS 지원. SFSpeechRecognizer는 iOS 10 이상에서 쓸 수 있지만 SpeechAnalyzer는 iOS 26 이상을 요구합니다. iOS 18 이하를 대상으로 하는 앱에는 레거시 프레임워크가 필요합니다.

이미 잘 돌아가는 통합. 안정적이고 감사를 거쳤으며 성능도 나오는 SFSpeechRecognizer 통합을 가진 앱이라면 서둘러 옮길 이유가 없습니다. 새 프레임워크의 개선은 새로운 사용 사례(장문 전사, 원거리 오디오, 다중 화자 대화)에서 가장 크게 드러납니다. 레거시 API로 짧은 음성 질의를 처리하는 앱은 마이그레이션 비용을 정당화할 만큼의 이득을 얻지 못할 수도 있습니다.

언제 마이그레이션할 것인가

짚어 둘 만한 마이그레이션 신호가 세 가지 있습니다.

앱이 장문 오디오를 처리한다. 회의 녹음기, 강의 전사 앱, 팟캐스트를 텍스트로 바꾸는 도구가 그렇습니다. 지속적인 오디오로 학습된 새 모델이 딱 들어맞고, 예전 모델은 긴 세션에서 성능이 떨어집니다. 여기부터 먼저 옮기세요.

앱이 원거리 또는 소음이 있는 오디오를 다뤄야 한다. 회의실 전사, 멀리 놓인 마이크 하나로 하는 인터뷰 녹음, 주변 소음이 있는 환경에서 담은 오디오가 여기에 해당합니다. 이런 조건에서 새 모델이 눈에 띄게 더 잘 처리합니다.

앱이 실시간 전사 UI를 보여 준다. 자막 오버레이, 받아쓰기 인터페이스, 음성으로 조작하는 접근성 UI가 그렇습니다. SpeechTranscriber 스트리밍 결과의 낮은 지연 시간 덕분에 UI 반응이 더 빠르게 느껴집니다.

반면 반드시 마이그레이션할 필요는 없는 경우도 있습니다.

• 커스텀 어휘에 의존하는 장문 전사(약품명이나 판례 인용을 놓쳐서는 안 되는 회의 녹음기 등). 장문용 SpeechTranscriber 모델은 contextual strings를 받지 않으므로, 애플이 이 공백을 메울 때까지 이 조합은 SFSpeechRecognizer에 머무릅니다. 커스텀 어휘를 쓰는 짧은 음성 질의는 깔끔하게 옮길 수 있습니다. DictationTranscriber와 AnalysisContext.contextualStrings의 조합이 이를 감당합니다⁶.
• iOS 18 이하를 지원해야 하는 앱. SpeechAnalyzer는 iOS 26 전용이므로, 어차피 구버전 타깃을 위해 코드베이스에 레거시 프레임워크가 필요합니다.

병행 사용 패턴

구버전 OS도 지원하면서 iOS 26 이상에서는 새 프레임워크의 품질을 얻고 싶은 앱이라면, 둘을 나란히 두는 패턴이 알맞습니다.

import Speech

if #available(iOS 26.0, *) {
    let transcriber = DictationTranscriber(locale: .current, preset: .shortDictation)
    let analyzer = SpeechAnalyzer(modules: [transcriber])
    try await analyzer.start(inputSequence: audioInputSequence)
    for try await result in transcriber.results {
        if result.isFinal {
            handleTranscription(result.text)
        }
    }
} else {
    let recognizer = SFSpeechRecognizer(locale: .current)!
    let request = SFSpeechAudioBufferRecognitionRequest()
    request.shouldReportPartialResults = true
    request.requiresOnDeviceRecognition = true
    let task = recognizer.recognitionTask(with: request) { result, error in
        guard let result else { return }
        handleTranscription(result.bestTranscription.formattedString)
    }
}

iOS 26 이상 분기에서 DictationTranscriber가 옳은 선택인 이유는 마이그레이션 대상이 SFSpeechRecognizer의 사용 사례(같은 받아쓰기 모델을 쓰는 짧은 질의)이기 때문입니다. 장문 오디오를 겨냥하는 앱은 iOS 26 분기에서 DictationTranscriber를 SpeechTranscriber로 바꾸면 됩니다.

두 프레임워크는 공존하고, 런타임 검사가 가용성에 따라 알맞은 쪽을 고릅니다. 어느 쪽도 다른 쪽을 막지 않으며, 앱의 전사 파이프라인이 상황에 맞춰 적응합니다.

프라이버시와 음성 인식 권한

두 프레임워크는 권한 계층에서 갈립니다. SFSpeechRecognizer는 전용 음성 인식 권한을 그대로 유지합니다. Info.plist의 NSSpeechRecognitionUsageDescription과 SFSpeechRecognizer.requestAuthorization(_:) 프롬프트가 그것입니다⁵. SpeechAnalyzer는 이 경로를 쓰지 않습니다. 이 프레임워크로 실시간 오디오를 전사하는 앱에는 마이크 권한(NSMicrophoneUsageDescription)이 필요하고, 앱이 이미 갖고 있는 오디오를 전사할 때는 그 이상 필요한 것이 없습니다. 프라이버시 측면에서는 둘 다 온디바이스입니다. SpeechAnalyzer는 설계상 온디바이스 전용이고, SFSpeechRecognizer는 SFSpeechRecognitionRequest 자체에서 requiresOnDeviceRecognition 플래그를 true로 설정했을 때 온디바이스로 동작합니다. 이는 기본값이 아니라 반드시 지정해야 하는 값이며, 설정하지 않으면 서버 측 경로를 쓸 수 있습니다.

병행 사용 패턴에 주는 함의는 이렇습니다. 두 프레임워크를 함께 돌리는 앱은 두 가지 권한 표면을 모두 떠안습니다. SpeechAnalyzer 분기에는 마이크 프롬프트가, 레거시 분기에는 음성 인식 권한이 필요하며, App Store의 개인정보 처리 방침 라벨에도 둘 다 반영해야 합니다.

마이크 오디오를 애널라이저로 흘려보내는 앱에는 표준적인 AVAudioSession 구성이 그대로 적용됩니다. 이 클러스터의 Privacy Manifest 글은 Speech를 쓰는 앱의 매니페스트 항목을 다룹니다. 두 프레임워크 모두 같은 프라이버시 선언의 범위에 들어갑니다.

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

SpeechAnalyzer의 온디바이스 모델과 구조화된 출력은 이 클러스터의 두 가지 패턴과 깔끔하게 맞물립니다.

앱 내 추론을 위한 Foundation Models. SpeechTranscriber로 오디오를 전사한 다음 그 전사문을 온디바이스 LLM(Foundation Models 온디바이스 LLM에서 다룹니다)으로 요약하는 파이프라인은 전부 온디바이스에서 돌아갑니다. 네트워크 호출 총합은 0이고, 서드파티로 나가는 데이터도 0입니다.

음성 기반 동작을 위한 App Intents. 전사문을 입력으로 받는 AppIntent는 Vocal Shortcuts(플랫폼으로서의 접근성에서 다룹니다)나 애플 인텔리전스의 동작 표면을 통해 호출할 수 있습니다. 인텐트의 perform 메서드가 SpeechAnalyzer를 실행해 입력을 전사한 뒤 앱 로직으로 넘깁니다. 이 흐름 전체가 비공개이면서 로컬입니다.

패턴은 이렇습니다. 새 Speech 프레임워크는 온디바이스 인지의 삼각형(이미지의 Vision, 언어 추론의 Foundation Models, 오디오의 Speech)을 완성해, 완전히 로컬에서 도는 AI 기능을 iOS 앱에서 현실적인 선택지로 만듭니다.

iOS 26 이상 앱에 주는 의미

기억해 둘 점은 세 가지입니다.

1. 새 코드에서는 SpeechAnalyzer를 기본으로 삼으세요. 현대적인 모델, 모듈형 아키텍처, 그리고 장문과 원거리, 실시간에서의 성능 향상을 고려하면 출발점으로 알맞습니다. 레거시 프레임워크는 구버전 OS 지원이나 장문 전사에서의 커스텀 어휘가 필요할 때의 대비책입니다.

2. 어휘에 의존하는 앱은 오디오 길이로 갈립니다. 커스텀 어휘를 쓰는 짧은 발화 받아쓰기는 옮길 수 있습니다. DictationTranscriber와 AnalysisContext.contextualStrings가 도메인 용어를 실어 나르기 때문입니다⁶. 커스텀 어휘를 쓰는 장문 전사는 SpeechTranscriber 모델이 contextual strings를 받아들일 때까지 SFSpeechRecognizer에 남겨 둡니다. 두 프레임워크는 공존하므로 기능 단위로 섞어 쓰는 것이 올바른 패턴입니다.

3. 온디바이스 프라이버시 이야기가 Vision에서 Speech로 확장됩니다. Vision의 온디바이스 컴퓨터 비전을 중심으로 만들어 온 앱이 이제 오디오에서도 같은 것을 갖게 되었습니다. 추론을 담당하는 Foundation Models와 결합하면, 인지에서 언어까지 이어지는 전체 파이프라인을 서드파티 데이터 노출 없이 로컬에서 돌릴 수 있습니다.

Apple Ecosystem 클러스터 전체 목록입니다. 타입이 있는 App Intents, MCP 서버, 라우팅 문제, Foundation Models, 런타임과 툴링 LLM의 구분, 세 가지 표면, 단일 진실 공급원 패턴, 두 개의 MCP 서버, 애플 개발을 위한 hooks, Live Activities, watchOS 런타임, SwiftUI의 내부, RealityKit의 공간 사고 모델, SwiftData 스키마 규율, Liquid Glass 패턴, 멀티 플랫폼 출시, 플랫폼 매트릭스, Vision 프레임워크, Symbol Effects, Core ML 추론, Writing Tools API 도입, Swift Testing, Privacy Manifest, 플랫폼으로서의 접근성, SF Pro 타이포그래피, visionOS 공간 패턴, 내가 쓰지 않기로 한 것들입니다. 허브는 Apple Ecosystem 시리즈에 있습니다. iOS와 AI 에이전트에 대한 더 넓은 맥락은 iOS 에이전트 개발 가이드를 참고하세요.

자주 묻는 질문

SFSpeechRecognizer는 더 이상 지원되지 않나요?

애플은 SFSpeechRecognizer를 공식적으로 deprecated 처리하지 않았습니다. iOS 26에서도 계속 제공되고 지원됩니다. WWDC 2025의 설명은 새 코드에는 SpeechAnalyzer가 현대적이고 권장되는 경로라는 것입니다. 레거시 프레임워크는 특정 상황(장문 전사에서의 커스텀 어휘, 구버전 OS 지원)에 알맞은 도구입니다.

미리 녹음한 오디오 파일에도 SpeechAnalyzer를 쓸 수 있나요?

쓸 수 있습니다. SpeechAnalyzer.start(inputSequence:)는 각각 오디오 버퍼를 감싼 AnalyzerInput 값들의 AsyncSequence를 받습니다. 앱은 어떤 오디오 소스든(AVAudioEngine을 통한 마이크, 녹음 파일 URL, AVAsset 인스턴스) AsyncSequence 어댑터로 감싸 애널라이저에 넣어 줍니다. 전사 스트림은 입력 소스와 무관하게 동일한 for try await result in transcriber.results 형태로 소비됩니다.

마이그레이션하면 커스텀 어휘는 어떻게 되나요?

어느 트랜스크라이버로 옮기느냐에 달렸습니다. 받아쓰기 경로는 지원합니다. AnalysisContext.contextualStrings로 최대 100개의 문구를 등록하고 SpeechAnalyzer.setContext(_:)로 컨텍스트를 설정하면 DictationTranscriber가 이를 사용합니다⁶. 장문용 SpeechTranscriber 모델은 contextual strings를 받지 않으므로, 어휘에 민감한 장문 전사는 애플이 그 공백을 메울 때까지 contextualStrings를 쓰는 SFSpeechRecognizer에 남겨 두는 편이 좋습니다. 혼합 방식(일반 전사에는 새 프레임워크, 어휘에 민감한 장문 경로에는 레거시 API)도 iOS 26에서 문제없이 동작합니다.

SpeechAnalyzer를 서버에서 실행할 수 있나요?

없습니다. SpeechAnalyzer는 온디바이스 전용 프레임워크이며 서버 측 경로가 없습니다. 서버에서 전사하려면 클라우드 API(OpenAI Whisper API, Google Cloud Speech-to-Text, AWS Transcribe)나 직접 호스팅하는 모델이 알맞습니다. 애플 프레임워크의 가치는 정확히 온디바이스 프라이버시와 호출당 비용이 0이라는 점에 있습니다.

언어 감지는 어떻게 동작하나요?

SpeechTranscriber(locale:)는 트랜스크라이버 인스턴스마다 하나의 로케일을 받으며, 스트림 도중에 언어를 바꿀 수는 없습니다. iOS 26이 자동화하는 것은 자산 쪽입니다. AssetInventory가 로케일별 모델 자산을 내려받고 관리하므로, 여러 언어를 지원한다고 해서 모델 가용성을 손수 관리할 필요는 없습니다. 언어를 미리 아는 앱(현지화된 앱의 받아쓰기 기능 등)에서는 명시적으로 지정하세요. 다국어 상황(화자가 언어를 바꿀 수 있는 회의 전사 등)에서는 언어를 감지하거나 사용자가 고르게 한 다음, 그 로케일용 트랜스크라이버를 생성합니다.

이 클러스터의 다른 온디바이스 ML 글들과는 어떻게 이어지나요?

SpeechAnalyzer는 온디바이스 인지 스택의 세 번째 기둥입니다. Vision(Vision Framework에서 다룹니다)이 이미지를, Speech가 오디오를 맡고, Core ML(Core ML 온디바이스 추론에서 다룹니다)이 그 둘의 밑바탕이 되는 엔진입니다. 언어 추론은 Foundation Models(Foundation Models 온디바이스 LLM에서 다룹니다)가 담당합니다. 이들을 합치면 네트워크 호출이 필요 없는 완전한 온디바이스 AI 파이프라인이 완성됩니다.

참고 자료