"Apple Silicon 엔 좋은 귀가 넷 있어. 네 목소리엔 기본을 고르고, 나머지는 어댑터로 둬."
온디바이스는 협상 대상이 아냐
엔진을 비교하기 전에, 시장 대부분을 걸러 내는 규칙이 하나 있어. 엔진은 이 기계 위에서 돌아야 해. 클라우드 API 가 더 정확할 수도 있어. 그런데 Firekeeper 가 존재하는 근거인 두 약속을 깨. 오디오가 로컬에 남는다는 것, 오프라인으로도 된다는 것. 그래서 아래 엔진은 전부 온디바이스야. 그 안에서 뭘 고르느냐는 속도, 언어 처리, 패키징 문제지 '오디오가 나가도 되나?' 문제가 아니고. 그 답은 항상 '안 돼' 니까.
네 엔진
엔진 성격 Firekeeper 에서 역할
---- ---- -----------------
WhisperKit Swift 네이티브, 기본. 한/영 혼합 처리.
Core ML large-v3-turbo 모델.
Apple SpeechAnalyzer macOS 26 API, 빠른 2번 엔진. 모델 파일
무다운로드 없음. 스트리밍 친화.
whisper.cpp C/C++, Core ML 폴백 / 벤치마크용.
MLX Whisper Python, MLX 선택적 배치 '파워 모드'.WhisperKit 이 기본인 건 Swift 네이티브고, Core ML 최적화됐고, 결정적으로 아빠의 한/영 혼합 말을 처리해서야. Apple SpeechAnalyzer(macOS 26)는 빠른 두 번째 엔진이야. 관리할 모델 파일이 없고 스트리밍도 네이티브로 돼. 대신 두 레슨 뒤에 만날 언어 함정을 하나 달고 있어. whisper.cpp 는 잘 익은 폴백이고, CLI 벤치마크를 올려놓기에 딱 좋아. MLX Whisper 는 배치 작업용 Python 기반 파워 모드야. 긴 녹음엔 좋은데 패키징한 앱에는 안 맞고.
기본 더하기 어댑터
모양을 봐. 기본 하나에 어댑터 여럿. 엔진 하나를 영원히 정하는 게 아냐. 흔한 경우에 쓸 기본을 고르고, 나머지는 공통 인터페이스 뒤에 두고 갈아끼울 수 있게 해 두는 거지. 엔진이 텍스트랑 감지한 언어를 같이 돌려주니까, 앱의 나머지는 넷 중 누가 그 단어를 만들었는지 알 필요가 전혀 없어. 그 인터페이스가 다음 트랙 주제 전부야. 여기선 '어느 STT 엔진을 쓸까' 가 평생 가는 결혼이 아니라 런타임에 고르는 선택이라는 것만 새겨 둬.