애플 SpeechAnalyzer, Whisper보다 정확하고 3배 빨랐어요

애플의 새 온디바이스 음성 인식 API인 SpeechAnalyzer가 공개 벤치마크에서 Whisper Small보다 낮은 단어 오류율을 기록했어요. 기존 SFSpeechRecognizer와 비교하면 오류가 3.5~4배 줄었고, 구두점과 대소문자까지 정리된 결과를 내놓았어요. 다만 영어 낭독 데이터와 Apple M2 Pro 한 대에서 진행한 시험이라 실제 앱에 도입하기 전에는 사용 환경에 맞춘 재검증이 필요해요. 1
핵심 요약
| 구분 | 핵심 | 왜 볼 만한가요 |
| 정확도 | SpeechAnalyzer의 WER는 깨끗한 음성 2.12%, 잡음이 많은 음성 4.56%였어요 | Whisper Small과 기존 애플 API보다 낮은 오류율을 기록했어요 |
| 속도 | Whisper Small보다 오디오 1초당 처리 시간이 약 3분의 1이었어요 | 온디바이스 전사 앱의 대기 시간과 배터리 부담을 줄일 여지가 있어요 |
| 이전 효과 | SFSpeechRecognizer의 WER 9.02%, 16.25%를 크게 낮췄어요 | 긴 회의나 인터뷰를 다루는 앱이라면 API 교체 효과가 커요 |
| 제약 | 약 30개 로케일과 OS 26 이상 애플 기기에 묶여 있어요 | 다국어와 크로스 플랫폼 지원에서는 Whisper가 여전히 유리해요 |
1. 애플의 새 음성 인식 API가 Whisper Small을 앞섰어요
Inscribe는 Apple M2 Pro 32GB와 macOS 26.5.1에서 음성 인식 엔진 5개를 같은 코드 경로로 비교했어요. 평가에는 LibriSpeech의 깨끗한 낭독 음성 2,620개와 더 어렵고 잡음이 많은 음성 2,939개를 썼어요. 모두 합치면 5,559개예요. 모든 처리는 네트워크 전송 없이 기기 안에서 이뤄졌어요. 2
측정 기준은 단어 오류율인 WER예요. 인식기가 단어를 바꾸거나 빠뜨리거나 없는 단어를 더한 비율이라 낮을수록 좋아요. SpeechAnalyzer는 깨끗한 음성에서 2.12%, 잡음이 많은 음성에서 4.56%를 기록했어요. 같은 조건에서 Whisper Small은 3.74%와 7.95%, Whisper Base는 5.42%와 12.51%, Whisper Tiny는 7.88%와 17.04%였어요.
기존 SFSpeechRecognizer와의 차이는 더 컸어요. 이전 API의 WER는 두 데이터셋에서 각각 9.02%와 16.25%였어요. SpeechAnalyzer로 바꾸면 같은 음성에서 오류율이 3.5~4배 낮아져요. 이전 API가 내놓던 거친 전사문과 달리 구두점과 대소문자도 적용돼 후처리 부담을 덜 수 있어요.
속도도 눈에 띄어요. 다섯 엔진은 M2 Pro에서 실시간보다 약 12~40배 빠르게 작동했어요. 1시간짜리 오디오를 약 1.5~5분 안에 처리한 셈이에요. SpeechAnalyzer는 Whisper Small보다 정확하면서 처리 시간은 약 3분의 1이었어요.
다만 엔진별 정밀 속도표는 아직 공개되지 않았어요. 정확도 시험 중 같은 컴퓨터에서 개발 작업이 함께 돌아가 시간 측정에 잡음이 섞였기 때문이에요. WER 비교는 같은 음성과 코드 경로를 썼지만, 배터리 사용량과 메모리 점유율도 공개되지 않았어요. 속도 수치는 전용 유휴 환경에서 다시 측정한 결과를 기다려 보는 편이 좋아요.
iOS와 macOS 앱에서는 이전 기준이 달라져요
긴 회의, 강의, 인터뷰를 전사하는 앱이라면 SpeechAnalyzer로 옮길 이유가 뚜렷해졌어요. 오류율 감소만 있는 게 아니에요. 구두점과 대소문자 후처리를 줄이고, 시스템 모델을 사용해 별도 Whisper 모델 파일을 앱에 넣지 않아도 돼요. Whisper Small은 약 460MB, Base는 약 140MB, Tiny는 약 40MB예요.
그렇다고 Whisper가 필요 없어지는 건 아니에요. SpeechTranscriber가 지원하는 범위는 약 30개 로케일이고, OS 26 이상 애플 플랫폼에서만 쓸 수 있어요. 더 많은 언어를 처리하거나 Android, Windows, Linux까지 같은 엔진을 써야 한다면 Whisper가 편해요. 지원 언어와 기기 조건을 먼저 확인한 뒤 엔진을 나누는 방식이 현실적이에요.
벤치마크 숫자를 그대로 제품 품질로 보면 안 돼요
LibriSpeech는 영어 오디오북 낭독 데이터예요. 실제 회의의 겹치는 발화, 멀리 있는 마이크, 고유명사, 한국어와 영어가 섞인 대화까지 대신 보여주지는 못해요. 이번 결과만으로 한국어 통화 녹음이나 현장 소음이 큰 영상에서도 같은 격차가 난다고 말하기 어려워요.
평가를 공개한 Inscribe가 여러 음성 엔진을 제공하는 제품을 운영한다는 점도 함께 봐야 해요. 다행히 전체 전사 결과와 평가 코드가 공개돼 있고, Whisper 측정값도 OpenAI가 공개한 LibriSpeech 수치와 가까웠어요. 그래도 도입 전에는 실제 사용자 음성으로 WER, 처리 시간, 메모리, 배터리를 다시 재는 편이 안전해요.
왜 중요한가요
애플 플랫폼에서 음성 전사 기능을 만드는 팀은 그동안 시스템 API의 간편함과 Whisper의 정확도 사이에서 선택해야 했어요. 이번 시험에서는 시스템에 내장된 SpeechAnalyzer가 정확도와 속도를 모두 앞섰어요. 영어 중심 앱이라면 기본 엔진을 다시 검토할 만한 근거가 생겼어요. 2
제품 설계에서는 하나의 엔진을 모든 환경에 강제로 맞출 필요가 없어요. OS 26 이상 애플 기기와 지원 로케일에서는 SpeechAnalyzer를 쓰고, 지원하지 않는 언어나 다른 운영체제에서는 Whisper로 전환할 수 있어요. 실제로 Inscribe도 이런 방식으로 자동 선택 기준을 바꿨어요.
개발팀이 확인할 항목은 분명해요. 먼저 앱에서 자주 들어오는 언어와 녹음 환경으로 자체 평가셋을 만들어요. 그다음 WER뿐 아니라 문장부호 품질, 고유명사 인식, 첫 결과가 나오는 시간, 장시간 처리 때의 발열과 배터리 사용량을 함께 비교해요. 기존 SFSpeechRecognizer를 쓰고 있다면 긴 오디오부터 새 API로 시험해 보는 편이 좋아요.
참고 자료
'IT & AI' 카테고리의 다른 글
| WebAssembly 파일을 IDE에서 분석하는 Hexana, JetBrains와 VS Code를 함께 지원해요 (0) | 2026.07.15 |
|---|---|
| Papermake, Typst 템플릿을 사내 PDF API로 바꿔줘요 (0) | 2026.07.14 |
| Bun의 Zig→Rust 전환, AI가 엔지니어링을 대체했다는 증거일까? (0) | 2026.07.14 |
| AI가 코드를 써도 개발자가 직접 코딩해야 하는 이유 (0) | 2026.07.14 |
| TCP/IP 설계자 빈트 서프가 은퇴하며 AI 에이전트 표준을 꺼냈어요 (0) | 2026.07.14 |