구글, Gemini 기반 음성입력 기능 Gboard에 추가해 디키션 스타트업에 부정적일 수 있음

구글이 Gboard에 Gemini 기반 음성 받아쓰기 기능을 통합하면서 모바일 입력 환경에 큰 변화가 예고되고 있습니다. 기존 음성 인식이 단순한 STT(Speech-to-Text) 변환에 그쳤다면, Gemini 기반 받아쓰기는 대규모 언어 모델(LLM)을 결합해 문맥 이해, 문장 부호 자동 삽입, 화자 의도 추론, 그리고 후처리 단계에서의 문법 교정까지 한 번에 처리합니다. 핵심은 온디바이스(on-device)와 클라우드 추론의 하이브리드 구조로, Pixel과 Galaxy 단말의 NPU/Tensor 칩에서 1차 인코딩을 수행한 뒤 Gemini Nano 또는 클라우드 Gemini로 의미 보정을 거치는 방식이 유력합니다. 이는 Whisper 같은 오픈소스 모델 대비 지연 시간(latency)을 크게 줄이면서도 한국어처럼 어순이 자유로운 언어의 받아쓰기 정확도를 비약적으로 향상시킬 수 있는 구조입니다.

개발자 관점에서 이번 변화는 양면적입니다. 우선 Otter.ai, Rev, Krisp 같은 음성 받아쓰기 스타트업의 모바일 시장 입지가 좁아지면서, B2C 단순 STT 앱을 만드는 개발자들은 즉각적인 차별화 압박을 받게 됩니다. OS 레벨에서 무료로 제공되는 받아쓰기와 경쟁하려면 도메인 특화(의료/법률 용어), 화자 분리, 회의 요약, 실시간 번역 등 고부가가치 기능을 반드시 갖춰야 합니다. 반대로 안드로이드 앱 개발자에게는 기회 요소가 큽니다. `RecognizerIntent`나 새로운 IME API를 통해 시스템 받아쓰기 결과를 받아 쓸 수 있게 되면, 별도의 음성 SDK(구글 클라우드 STT, AWS Transcribe 등)에 월 수십만 원의 비용을 지출하지 않고도 음성 입력 UX를 앱에 자연스럽게 녹여낼 수 있게 됩니다.

엔지니어가 지금 점검해야 할 사항은 명확합니다. 첫째, 현재 운영 중인 서비스에서 구글/애플의 시스템 STT로 대체 가능한 부분과, 자체 모델 또는 외부 STT가 반드시 필요한 부분을 분리해 비용 구조를 재설계해야 합니다. 둘째, Gboard 받아쓰기가 기본값이 되면 사용자 입력 패턴이 "터치 타이핑"에서 "음성+편집" 혼합으로 바뀌므로, 입력 폼의 글자 수 제한, 자동완성, 욕설 필터링 로직이 음성 입력 결과를 가정하고 동작하는지 검증이 필요합니다. 셋째, 음성 데이터를 다루는 서비스라면 단말 내 처리(on-device)가 표준이 되는 흐름에 맞춰 개인정보 처리방침과 데이터 전송 경로를 재점검해야 합니다. 마지막으로, Gemini Nano API와 ML Kit GenAI API가 빠르게 확장되고 있으므로, 모바일 AI 통합 로드맵을 단순한 "음성 인식"이 아니라 "온디바이스 LLM 기반 멀티모달 입력"이라는 더 큰 관점에서 재구성하는 것이 중요합니다.