AI 기반 음성 인식 도구 출시

Nothing이 공개한 온디바이스 받아쓰기(dictation) 도구는 100개 이상의 언어를 지원하면서도 클라우드 서버로 음성 데이터를 전송하지 않고 기기 내부에서 처리된다는 점이 핵심이다. 이는 최근 모바일 NPU(Neural Processing Unit)와 양자화(quantization) 기술의 발전 덕분에 가능해진 흐름으로, Whisper나 Conformer 계열의 스트리밍 ASR(Automatic Speech Recognition) 모델을 INT8/INT4로 경량화해 수백 MB 수준으로 압축한 뒤 모바일 칩셋의 가속기에서 실시간 추론하는 방식이 일반적이다. 100개 이상 언어를 단일 모델로 커버한다는 점에서 Meta의 SeamlessM4T나 OpenAI Whisper-large와 유사한 다국어 공유 인코더 구조를 채택했을 가능성이 높으며, 온디바이스 제약을 고려하면 Distillation과 Mixture-of-Experts 일부 라우팅, 혹은 언어별 LoRA 어댑터를 스위칭하는 설계가 유력하다.

개발자/엔지니어 관점에서 이 트렌드는 두 가지 실질적 변화를 의미한다. 첫째, 음성 입력을 전제로 한 앱 설계에서 네트워크 왕복 지연이 제거되므로 지하철·비행기·사내망 차단 환경에서도 안정적으로 동작하는 기능을 기본값으로 가정할 수 있게 된다. 둘째, GDPR·개인정보보호법(PIPA)·기업 보안 정책 대응이 훨씬 수월해진다. 그동안 음성 데이터는 서버 업로드 시 별도의 동의·로그 정책이 필요했지만, 온디바이스 처리는 "데이터가 기기를 떠나지 않음"을 기술적으로 보장하므로 금융·의료·공공 분야 B2B 제품의 진입 장벽이 크게 낮아진다. 이는 단순한 제품 기능이 아니라 컴플라이언스 설계의 기본 가정을 바꾸는 변화다.

한국 개발자가 당장 체크해야 할 포인트는 세 가지다. 첫째, 자사 앱에서 음성 입력이나 STT 기능을 제공한다면 서버 기반 API(Google Cloud Speech, Azure Speech, 네이버 CLOVA) 호출을 기본 경로로 두되, Android의 `SpeechRecognizer` on-device 모드(Android 12+의 Live Caption, Pixel의 on-device dictation)와 iOS의 `SFSpeechRecognizer`의 `requiresOnDeviceRecognition` 옵션을 폴백이자 프라이버시 모드로 병행 지원하는 이중 아키텍처를 설계해 두는 것이 좋다. 둘째, 한국어 성능은 여전히 영어 대비 WER(Word Error Rate)이 1.5~2배 높은 경향이 있으므로 정식 배포 전 도메인 특화 데이터(사내 용어, 고유명사)로 벤치마크를 반드시 수행해야 한다. 셋째, 온디바이스 모델은 배터리·발열·RAM 점유에 영향을 주기 때문에 백그라운드 세션 관리와 모델 언로딩 전략을 설계 초기부터 고려해야 하며, 장기적으로는 WebGPU/ONNX Runtime Web을 활용한 웹 환경의 온디바이스 STT까지 시야에 두고 기술 스택을 준비할 필요가 있다.