애플 새 음성 인식 API, 온디바이스 영어 전사에서 위스퍼 스몰까지 이겼다

• 결론부터 꽤 세게 나옴. 애플의 새 온디바이스 음성 인식 API인 스피치애널라이저(SpeechAnalyzer)가 테스트한 엔진 중 가장 정확했음
  • 리브리스피치(LibriSpeech) clean과 noisy 양쪽에서 위스퍼 스몰(Whisper Small)까지 이겼음
  • 위스퍼 스몰보다 정확하면서, 오디오 1초당 처리 시간은 대략 3배 짧았음
  • 기존 애플 API인 SFSpeechRecognizer는 clean 음성에서 40MB짜리 위스퍼 Tiny보다도 뒤처졌음

• 숫자가 꽤 명확함. 기존 애플 API에서 새 API로 가면 단어 오류율(WER)이 3.5~4배 줄었음

  • clean 음성에서는 9.02%에서 2.12%로 떨어졌음
  • noisy 음성에서는 16.25%에서 4.56%로 떨어졌음
  • 한 시간짜리 회의록을 뜬다고 치면, 기존 API는 새 API보다 틀린 단어가 대략 4배 더 많다는 얘기임

• 테스트 조건은 개발자가 보기 좋게 꽤 투명하게 잡았음

  • 모든 엔진은 애플 M2 프로, 32GB 메모리, macOS 26.5.1에서 완전 온디바이스로 실행됐음
  • clean 세트는 2,620개 발화, other 세트는 더 어렵고 noisy한 2,939개 발화로 구성됨
  • 총 5,559개 발화에 대해 애플 엔진 2개와 위스퍼 모델 3개를 같은 제품 코드 경로로 돌렸음

• 애플이 iOS 26과 macOS 26에서 SFSpeechRecognizer를 SpeechAnalyzer·SpeechTranscriber로 대체했지만, 정작 정확도 수치는 공개하지 않았음

  • 그래서 앱 개발자 입장에선 마이그레이션할 가치가 있는지 감으로 판단해야 했음
  • Inscribe 팀은 자기 제품에서 애플 엔진과 위스퍼 모델을 같이 제공하고 있어서, 같은 오디오와 같은 머신으로 비교할 수 있었음

• 스피치애널라이저가 이긴 영역은 정확도만이 아님

  • 테스트한 5개 엔진은 모두 실시간보다 빨랐고, 대략 12배에서 40배 속도로 전사했음
  • 즉 한 시간짜리 오디오는 온디바이스에서 약 1.5~5분 안에 전사되는 수준임
  • 정확한 속도표는 아직 공개하지 않았는데, 정확도 측정 중 개발 작업이 같은 머신에서 돌고 있어 타이밍 노이즈가 있었다고 설명했음

• 그래도 위스퍼가 밀려났다고 보기엔 아직 조건이 있음

  • 스피치트랜스크라이버(SpeechTranscriber)는 약 30개 로케일을 지원함
  • 위스퍼는 100개 이상 언어를 커버하고, 애플 플랫폼이 아닌 곳에서도 돌아감
  • 영어·애플 하드웨어·OS 26이라는 조건에서는 애플 내장 엔진이 강하지만, 다국어와 크로스플랫폼 제품이면 위스퍼가 여전히 필요함

• 벤치마크 신뢰도를 위해 원시 결과도 공개했음

  • 위스퍼 결과는 오픈AI가 공개한 리브리스피치 WER과 비교해 검증했음
  • 작은 양의 일관된 차이는 더 엄격한 텍스트 정규화와 CoreML 양자화 때문이라고 설명했음
  • 애플 엔진의 발화별 결과도 내려받을 수 있게 해, 정규화 방식이 마음에 안 들면 직접 다시 채점할 수 있게 했음

• 세부 방법론도 음성 인식 벤치마크에서 중요한 포인트를 잘 짚고 있음

  • 최신 엔진은 구두점, 대소문자, 숫자를 출력하지만 리브리스피치 정답은 대문자·무구두점·숫자 철자 표기라, 양쪽을 같은 방식으로 정규화했음
  • 짧은 발화가 과하게 반영되지 않도록 발화별 평균이 아니라 전체 오류 수를 전체 정답 단어 수로 나눈 corpus WER을 썼음
  • SFSpeechRecognizer는 기본적으로 애플 서버로 보낼 수 있어서, 테스트에서는 온디바이스 인식을 강제하고 클라우드 fallback이 생기면 실패하도록 만들었음

• 재밌는 건 벤치마크가 자기 제품 버그도 찾아냈다는 점임

  • Inscribe의 애플 엔진 파일 import 경로에서 SpeechAnalyzer에 오디오를 넣고 입력 스트림을 닫았지만, finalizeAndFinishThroughEndOfInput()을 호출하지 않았음
  • 그래서 최종 결과가 오지 않아 import가 영원히 멈추는 버그가 있었음
  • 기존 Auto 설정이 위스퍼를 우선해서 이 버그가 숨어 있었고, 벤치마크 과정에서 발견해 같은 날 수정했다고 함

• Inscribe는 이 결과를 실제 제품 기본값에도 반영했음

  • 지원 언어에서는 SpeechAnalyzer를 우선 사용함
  • 그 외 언어에서는 위스퍼를 사용함
  • 벤치마크를 마케팅 자료로만 쓰는 게 아니라 제품 선택 로직에 넣었다는 점은 꽤 설득력 있음

---

기술 맥락

• 여기서 핵심 선택은 “애플 플랫폼 영어 전사에서 위스퍼를 계속 기본값으로 둘 것인가, OS 내장 SpeechAnalyzer로 바꿀 것인가”예요. 이유는 단순해요. 같은 온디바이스 조건에서 SpeechAnalyzer가 WER 2.12%와 4.56%를 찍으면서 기존 API와 위스퍼 스몰을 모두 앞섰거든요.

• 트레이드오프는 정확도 하나로 끝나지 않아요. SpeechAnalyzer는 애플 OS 26 환경에 묶이고 지원 로케일도 약 30개라서, 다국어 제품이나 윈도우·리눅스까지 가는 앱이면 위스퍼를 버릴 수 없어요. 대신 최신 아이폰·맥에서 영어 전사만 보면 더 빠르고 더 정확한 기본 엔진이 생긴 셈이에요.

• 구현 관점에선 “온디바이스 강제”가 꽤 중요해요. SFSpeechRecognizer는 기본 동작에서 서버 전송이 끼어들 수 있어서, 프라이버시 제품이 벤치마크하려면 클라우드 fallback을 막아야 하거든요. 이걸 안 막으면 정확도 비교도, 개인정보 보호 주장도 둘 다 애매해져요.

• 또 하나 배울 점은 벤치마크가 제품 품질 도구가 될 수 있다는 거예요. Inscribe는 측정 과정에서 finalizeAndFinishThroughEndOfInput() 누락으로 import가 멈추는 버그를 찾았어요. 모델 선택 비교를 하다가 실제 사용자 경로의 장애를 발견한 케이스라, 벤치마크를 별도 실험이 아니라 제품 코드 경로로 돌린 이유가 분명해져요.