Apple의 새로운 Speech 프레임워크: SpeechAnalyzer vs SFSpeechRecognizer

iOS 26은 기존 SFSpeechRecognizer와 함께 새로운 음성 인식 프레임워크를 도입합니다. 새로운 API 표면은 SpeechAnalyzer와 그 주변에 구성되는 모듈(SpeechTranscriber, SpeechDetector)입니다¹. Apple이 직접 제시하는 관점은 SpeechAnalyzer가 현대적인 경로라는 것입니다. 새로운 온디바이스 모델, 장시간 오디오 지원, 자동 언어 관리, 실시간 사용 사례를 위한 낮은 지연 시간, 그리고 시간이 지남에 따라 더 많은 분석 유형을 추가할 수 있도록 지원하는 모듈식 아키텍처를 갖추고 있습니다. SFSpeechRecognizer는 계속 제공되고 작동합니다. 사용자 지정 어휘 기능에 의존하는 앱에는 여전히 적합한 도구로 남아 있으며, 새 프레임워크는 아직 이 기능을 제공하지 않습니다.

이 글은 새 프레임워크를 기존 프레임워크와 비교해 살펴봅니다. 관점은 “새 API를 어떻게 사용할 것인가”가 아니라 “언제 마이그레이션해야 하는가”입니다. 작동하는 SFSpeechRecognizer 통합을 가진 모든 팀은 동일한 분류 결정에 직면하기 때문입니다. 새 프레임워크의 현대적인 모델과 아키텍처가 마이그레이션 비용에 합당한가, 아니면 기존의 사용자 지정 어휘 투자가 유지를 정당화하는가?

TL;DR

• SpeechAnalyzer(iOS 26+)는 Apple의 현대적인 온디바이스 음성 인식 프레임워크입니다. 초기화 시 구성된 분석 모듈을 조정하며, iOS 26에서는 세 가지 모듈을 제공합니다. SpeechTranscriber(장시간), DictationTranscriber(짧은 발화, SFSpeechRecognizer 등가물), SpeechDetector(음성 활동 감지, 반드시 트랜스크라이버와 함께 사용)².
• 새 프레임워크는 강의, 회의, 다중 화자 대화 같은 장시간 오디오를 중심으로 구축되었습니다. 완전히 온디바이스에서 실행되며, 언어를 자동으로 관리하고, 동등한 전사 작업에서 Whisper Large V3 Turbo보다 2배 빠르다고 보고된 새로운 Apple 독자 모델을 탑재하고 있습니다³.
• SFSpeechRecognizer는 계속 제공되고 작동합니다. 레거시 프레임워크는 사용자 지정 어휘 기능(도메인 특화 용어에 대한 정확도를 높이기 위해 알려진 키워드를 등록하는 기능)을 유지하며, 새 프레임워크는 아직 이를 제공하지 않습니다.
• 마이그레이션은 기능별로 이루어지며, 전부 또는 전무가 아닙니다. 장시간 전사, 더 낮은 지연 시간, 또는 더 나은 원거리 오디오 품질이 필요한 앱은 SpeechAnalyzer로 마이그레이션합니다. 사용자 지정 어휘에 투자한 앱은 해당 기능에 대해 SFSpeechRecognizer를 유지하고 새로운 기능에는 SpeechAnalyzer를 추가합니다.
• 이 클러스터의 Vision 프레임워크 글은 Apple의 또 다른 온디바이스 인지 기본 요소를 다룹니다. SpeechAnalyzer는 동일한 온디바이스, 클라우드 없는 패턴을 오디오로 확장합니다.

아키텍처: 분석기 + 모듈

SpeechAnalyzer는 그 자체로 트랜스크라이버가 아닙니다. 오디오 분석 세션을 관리하고 오디오 버퍼를 하나 이상의 모듈에 디스패치하는 코디네이터입니다². 모듈은 init(modules:) 이니셜라이저를 통해 초기화 시 구성되며, 분석은 start(inputSequence:)를 통해 오디오 버퍼의 AsyncSequence를 공급함으로써 시작됩니다.

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는 오디오 세션 관리, 언어 감지, 전사를 단일 객체로 결합합니다. 새 API는 관심사를 분리하므로 앱은 필요한 모듈만 구성합니다.

새로운 모델이 가져오는 것

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

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

원거리 오디오 처리. 방 건너편에 배치된 마이크, 다중 화자가 있는 회의실 오디오, 환경 소음이 있는 오디오. 모델은 이러한 조건에 대해 학습되었습니다. SFSpeechRecognizer의 이전 모델은 이를 덜 우아하게 처리합니다.

실시간 저지연 작동. SpeechTranscriber의 스트리밍 결과는 기존 프레임워크의 SFSpeechRecognitionTask.shouldReportPartialResults 콜백보다 더 빠르게 도착합니다. 라이브 전사를 표시하는 앱(자막, 음성 기반 UI, 받아쓰기)은 더 부드러운 업데이트를 받습니다.

자동 언어 관리. SpeechTranscriber(locale:)는 시작 로케일을 받지만, 모델은 스트림 중간에 언어가 전환되어도 적응할 수 있습니다. 기존 프레임워크는 개발자가 언어별 인식기를 인스턴스화하고 그들 사이를 전환할 것을 요구합니다.

앱 크기 비용 없음. 모델은 앱이 아닌 OS와 함께 제공됩니다. SpeechAnalyzer를 채택하는 앱은 추가 모델 가중치를 번들링하지 않습니다. Whisper급 모델을 앱 번들에 포함하는 것과의 대비는 큽니다. 경쟁력 있는 온디바이스 전사 스택의 번들 비용이 0바이트입니다.

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

SFSpeechRecognizer는 iOS 26에서도 계속 제공되고 작동합니다. 앱이 이를 계속 사용하는 세 가지 이유는 다음과 같습니다.

사용자 지정 어휘. SFSpeechRecognitionRequest.contextualStrings는 모델이 정확하게 인식할 가능성이 높은 알려진 키워드 목록(고유명사, 기술 용어, 제품명)을 앱이 등록하도록 합니다. 이 기능은 도메인 특화 앱(약물명을 다루는 의료 받아쓰기, 판례 인용을 다루는 법률 앱, 부품 번호를 다루는 엔지니어링 앱)의 정확도를 크게 향상시킵니다. SpeechAnalyzer는 아직 사용자 지정 어휘를 제공하지 않습니다. 이 기능에 의존하는 앱에 마이그레이션은 정확도 면에서 후퇴가 됩니다.

구형 OS 지원. SFSpeechRecognizer는 iOS 10+에서 사용할 수 있고, SpeechAnalyzer는 iOS 26+를 요구합니다. iOS 18 이하를 타겟팅하는 앱은 레거시 프레임워크가 필요합니다.

작동 중인 기존 통합. 안정적이고, 감사를 받았으며, 성능이 좋은 SFSpeechRecognizer 통합을 가진 앱은 마이그레이션할 긴급한 이유가 없습니다. 새 프레임워크의 개선 사항은 새로운 사용 사례(장시간 전사, 원거리 오디오, 다중 화자 대화)에서 가장 중요합니다. 레거시 API를 통해 짧은 음성 쿼리를 처리하는 앱은 마이그레이션을 정당화할 만큼 충분한 이득을 얻지 못할 수 있습니다.

언제 마이그레이션해야 하는가

명명할 가치가 있는 세 가지 마이그레이션 트리거는 다음과 같습니다.

앱이 장시간 오디오를 처리합니다. 회의 녹음기, 강의 전사 앱, 팟캐스트-텍스트 변환 도구. 지속적인 오디오에 대한 새 모델의 학습이 적합합니다. 기존 모델은 긴 세션 동안 성능이 저하됩니다. 먼저 마이그레이션하세요.

앱이 원거리 또는 시끄러운 오디오를 필요로 합니다. 회의실 전사, 단일 원거리 마이크로 인터뷰 녹음, 주변 소음이 있는 환경에서 캡처한 오디오. 새 모델은 이러한 조건을 눈에 띄게 더 잘 처리합니다.

앱이 라이브 전사 UI를 표시합니다. 자막 오버레이, 받아쓰기 인터페이스, 음성 기반 보조 UI. SpeechTranscriber의 스트리밍 결과의 더 낮은 지연 시간은 UI를 더 반응적으로 느끼게 합니다.

마이그레이션을 반드시 정당화하지 않는 경우는 다음과 같습니다.

• 사용자 지정 어휘를 사용하는 짧은 음성 쿼리(처방 받아쓰기, 법률 용어). 어휘 기능을 위해 SFSpeechRecognizer를 유지하세요. Apple이 향후 릴리스에서 어휘 지원을 추가하면 SpeechAnalyzer로 옮기세요.
• iOS 18 이하를 지원해야 하는 앱. SpeechAnalyzer는 iOS 26 전용입니다. 코드베이스는 어쨌든 구형 타겟을 위해 레거시 프레임워크가 필요합니다.

사이드-바이-사이드 패턴

구형 OS 버전을 타겟팅하면서 iOS 26+에서 새 프레임워크의 품질을 원하는 앱의 경우, 사이드-바이-사이드 패턴이 올바른 접근 방식입니다.

import Speech

if #available(iOS 26.0, *) {
    let transcriber = DictationTranscriber(locale: .current)
    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)
    }
}

DictationTranscriber는 iOS 26+ 분기에 적합한 선택입니다. 마이그레이션 대상이 SFSpeechRecognizer 사용 사례(동일한 받아쓰기 모델을 사용하는 짧은 쿼리)이기 때문입니다. 장시간 오디오를 타겟팅하는 앱은 iOS 26 분기에서 DictationTranscriber를 SpeechTranscriber로 교체합니다.

두 프레임워크는 공존합니다. 런타임 검사가 가용성에 따라 올바른 것을 선택합니다. 어느 쪽도 다른 쪽을 차단하지 않습니다. 앱의 전사 파이프라인이 적응합니다.

개인정보 보호와 Speech 권한 표면

두 프레임워크는 동일한 Speech 프레임워크 권한(Info.plist의 NSSpeechRecognitionUsageDescription)과 동일한 사용자 대면 권한 흐름을 공유합니다⁵. 개인정보 보호 측면은 동일합니다. 음성 전사는 두 프레임워크 모두에서 온디바이스로 이루어집니다. SpeechAnalyzer는 설계상 온디바이스 전용입니다. SFSpeechRecognizer는 SFSpeechRecognitionRequest 자체에서 요청의 requiresOnDeviceRecognition 플래그가 true로 설정되면 기본적으로 온디바이스로 처리되며, 그렇지 않으면 서버 측 경로로 폴백할 수 있습니다.

이것이 시사하는 바는 SpeechAnalyzer를 사용하는 앱이 여전히 Speech 권한을 올바르게 처리해야 한다는 것입니다. 사용자 프롬프트, 설정 항목, App Store 개인정보 영양 라벨은 모두 동일한 권한 메커니즘을 사용합니다.

마이크 오디오를 분석기로 스트리밍하는 앱의 경우, 표준 AVAudioSession 구성이 적용됩니다. 이 클러스터의 Privacy Manifest 글은 Speech를 사용하는 앱의 매니페스트 항목을 다룹니다. 두 프레임워크 모두 동일한 개인정보 선언에 해당합니다.

에이전트-워크플로우 연결

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

앱 내 추론을 위한 Foundation Models. SpeechTranscriber로 오디오를 전사한 다음 온디바이스 LLM(Foundation Models 온디바이스 LLM에서 다룸)으로 전사문을 요약하는 파이프라인은 완전히 온디바이스에서 실행됩니다. 총 네트워크 호출: 0회. 총 제3자 데이터 노출: 0회.

음성 기반 액션을 위한 App Intents. 전사문을 입력으로 받는 AppIntent는 Vocal Shortcuts(플랫폼으로서의 접근성에서 다룸)나 Apple Intelligence의 액션 표면을 통해 호출될 수 있습니다. 인텐트의 perform 메서드는 SpeechAnalyzer를 실행해 입력을 전사한 다음 앱의 로직으로 디스패치합니다. 전체 흐름은 비공개이며 로컬에서 이루어집니다.

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

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

세 가지 시사점입니다.

1. 새 코드에는 SpeechAnalyzer를 기본으로 사용하세요. 현대적인 모델, 모듈식 아키텍처, 향상된 장시간 / 원거리 / 라이브 성능이 올바른 출발점이 됩니다. 레거시 프레임워크는 구형 OS 지원이나 사용자 지정 어휘가 필요할 때의 대비책입니다.

2. 어휘 의존 앱에는 SFSpeechRecognizer를 유지하세요. Apple이 새 프레임워크에 사용자 지정 어휘를 추가할 때까지, 도메인 특화 용어의 정확도를 위해 contextualStrings에 의존하는 앱은 기존 API를 유지합니다. 두 프레임워크는 공존합니다. 기능별로 혼합하는 것이 올바른 패턴입니다.

3. 온디바이스 개인정보 보호 스토리는 Vision에서 Speech로 확장됩니다. Vision의 온디바이스 CV를 중심으로 구축된 앱은 이제 오디오에 대한 동등물을 갖게 됩니다. 추론을 위한 Foundation Models와 결합되면, 전체 인지-언어 파이프라인이 제3자 데이터 노출 없이 로컬에서 실행될 수 있습니다.

전체 Apple 생태계 클러스터: 타입 지정된 App Intents; MCP 서버; 라우팅 질문; Foundation Models; 런타임 vs 툴링 LLM 구분; 세 가지 표면; 단일 진실 소스 패턴; 두 개의 MCP 서버; Apple 개발용 훅; 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 Series에 있습니다. 더 광범위한 iOS-AI 에이전트 컨텍스트는 iOS Agent Development 가이드를 참조하세요.

FAQ

SFSpeechRecognizer는 더 이상 사용되지 않습니까?

Apple은 SFSpeechRecognizer를 공식적으로 더 이상 사용하지 않는 것으로 표시하지 않았습니다. iOS 26에서 계속 제공되며 지원됩니다. WWDC 2025의 관점은 SpeechAnalyzer가 새 코드에 권장되는 현대적인 경로라는 것입니다. 레거시 프레임워크는 특정 사례(사용자 지정 어휘, 구형 OS 지원)에 적합한 도구입니다.

사전 녹음된 오디오 파일과 함께 SpeechAnalyzer를 사용할 수 있습니까?

네. SpeechAnalyzer.start(inputSequence:)는 오디오 버퍼의 AsyncSequence를 받습니다. 앱은 모든 오디오 소스(AVAudioEngine을 통한 마이크, 사전 녹음된 파일 URL, AVAsset 인스턴스)를 AsyncSequence 어댑터로 감싸 분석기에 공급합니다. 전사 스트림은 입력 소스에 관계없이 동일한 for try await result in transcriber.results 소비를 생성합니다.

마이그레이션하면 사용자 지정 어휘는 어떻게 됩니까?

사용자 지정 어휘는 현재 SpeechAnalyzer / SpeechTranscriber에서 지원되지 않습니다. 도메인 특화 정확도를 위해 이에 의존하는 앱은 Apple이 이 기능을 추가할 때까지 해당 경로를 마이그레이션하지 않아야 합니다. 하이브리드 접근 방식(일반 전사에는 SpeechAnalyzer를 사용하고 어휘에 민감한 전사에는 contextualStrings와 함께 SFSpeechRecognizer를 사용)이 iOS 26에서 작동합니다.

SpeechAnalyzer를 서버 측에서 실행할 수 있습니까?

아니요. SpeechAnalyzer는 온디바이스 전용 프레임워크입니다. 서버 측 경로가 없습니다. 서버 측 전사의 경우, 적절한 도구는 클라우드 API(OpenAI Whisper API, Google Cloud Speech-to-Text, AWS Transcribe) 또는 자체 호스팅 모델입니다. Apple 프레임워크의 가치는 정확히 온디바이스 개인정보 보호와 호출당 비용 0이라는 점입니다.

언어 감지는 어떻게 작동합니까?

SpeechTranscriber(locale:)는 초기 로케일을 받습니다. 모델은 스트림 중간 언어 전환에 자동으로 적응할 수 있습니다. 언어가 미리 알려진 앱(현지화된 앱의 받아쓰기 기능)의 경우, 명시적으로 지정하세요. 다국어 컨텍스트(화자가 언어를 전환할 수 있는 회의 전사기)에서는 자동 관리가 올바른 동작입니다.

이것이 클러스터의 다른 온디바이스 ML 글들과 어떻게 어울립니까?

SpeechAnalyzer는 온디바이스 인지 스택의 세 번째 기둥입니다. Vision(Vision Framework에서 다룸)은 이미지를 처리하고, Speech는 오디오를 처리하며, Core ML(Core ML 온디바이스 추론에서 다룸)은 두 가지 모두의 기반이 되는 엔진입니다. Foundation Models(Foundation Models 온디바이스 LLM에서 다룸)는 언어 추론을 처리합니다. 이들은 함께 네트워크 호출이 필요 없는 완전한 온디바이스 AI 파이프라인을 형성합니다.

참고 문헌