Google AI Edge Gallery 음성 기능 공개: 오프라인 ASR·TTS 도입 전 확인할 것

스마트폰 안에서 음성 입력과 출력을 처리하는 구조를 표현한 생성형 개념 이미지다. 실제 제품 화면이나 측정 결과가 아니다.

음성 챗봇을 오프라인으로 옮길 때 가장 먼저 정할 것은 모델 이름이 아니라 배포 경로다. Android의 시스템 관리형 음성 기능을 이용할지, 앱이 모델과 실행 환경을 직접 관리할지에 따라 지원 기기와 초기 준비 과정이 달라진다. 데모에서 소리가 난다는 것과 서비스에서 안정적으로 대화가 이어진다는 것도 별개다.

Google은 2026년 11월 10일 AI Edge Gallery의 온디바이스 음성 인식(ASR)과 음성 합성(TTS)을 소개했다. 음성 입력을 텍스트로 바꾸고, 로컬 언어 모델의 답을 다시 음성으로 출력하는 구성을 직접 살펴볼 수 있게 한 변화다. 이 글은 공식 발표와 개발 문서를 바탕으로 통합 경로와 검증 기준을 정리한다. Android 실기기에서 실행하거나 속도를 측정한 후기는 아니다. Google 공식 발표

첫 번째 선택: 시스템 관리형 ML Kit인가, 모델을 직접 관리할 것인가

Android 우선 서비스라면 ML Kit 경로부터 검토할 수 있다. 다만 SDK를 추가했다고 모든 기기에서 같은 기능이 열리는 것은 아니다.

ML Kit Speech Recognition은 Basic과 Advanced 모드를 구분한다. Advanced는 일부 기기에서 제공된다. 인식 결과는 수정될 수 있는 부분 결과와 최종 결과로 전달되므로, 화면 미리보기와 후속 명령 실행을 분리하는 편이 안전하다. 이 API는 현재 alpha이며 호환성을 깨는 변경이 가능하다. ML Kit 음성 인식 문서

TTS도 지원 기기와 음성 모델 준비 상태를 확인해야 한다. 공식 문서는 최신 Google Speech Recognition & Synthesis 앱을 요구하며, 앱이 없거나 오래된 경우 checkStatus()가 UNAVAILABLE을 반환할 수 있다고 설명한다. 대상 음성을 조회한 다음 다운로드 가능 상태인지 확인하고, 필요한 모델을 내려받는 순서다. 온디바이스 추론을 지원한다는 말은 첫 실행부터 네트워크가 전혀 필요 없다는 뜻이 아니다. ML Kit TTS 문서

여러 플랫폼을 지원하거나 모델을 직접 선택해야 한다면 MediaPipe와 LiteRT 기반 경로를 검토한다. MediaPipe TTS 문서는 모델 파일을 지정해 전체 음성을 생성하거나 청크를 순차적으로 받는 예제를 제공한다. 반환된 청크의 샘플레이트를 재생기에 전달해야 하며, 예제에 있는 특정 음성이나 모델의 언어 지원을 다른 모델에도 그대로 적용해서는 안 된다. MediaPipe TTS 문서

실무 판단 기준은 단순하다. 시스템이 지원하는 기기 집합 안에서 운영할 수 있으면 관리 부담을 줄이는 경로를 먼저 평가한다. 대상 기기와 모델 선택권이 더 중요하면 파일 배포, 캐시, 메모리, 업데이트를 직접 책임지는 경로를 검토한다. 어느 쪽이 항상 빠르다는 결론은 실측 없이 내릴 수 없다.

두 번째 선택: 토큰이 아니라 발화 단위로 연결한다

공식 Gallery 발표는 문장 단위 합성과, 읽을 필요가 없는 Markdown·코드·표를 처리하는 방식을 소개한다. 앱 개발에서 중요한 것은 텍스트가 생성되는 속도와 사람이 듣는 속도가 다르다는 점이다. Gallery 음성 파이프라인 소개

다음은 SDK 사용법이 아니라 앱 계층의 설계 제안이다.

1. ASR 부분 결과는 화면에만 표시한다.

2. 최종 인식 결과가 확정되면 새 응답 세대를 시작한다.

3. 언어 모델의 출력을 발화 가능한 문장으로 모은다.

4. 문장별 합성 결과를 순서대로 재생한다.

5. 사용자가 중단하면 생성 작업과 재생 큐를 함께 취소한다.

특히 취소 요청만 보내고 끝내면 이미 처리 중이던 청크가 늦게 도착할 수 있다. 응답 세대 번호를 함께 검사하면 이전 답이 새 대화에 끼어드는 일을 막는 데 도움이 된다.

이 가드는 실행 중인 추론과 오디오 장치 자체를 멈추지 않는다. 실제 구현에서는 SDK 취소, 이미 재생 중인 버퍼 비우기, 자원 해제까지 별도로 연결해야 한다. 여러 스레드에서 상태를 만진다면 직렬화나 잠금도 필요하다.

한국어 서비스라면 이렇게 검증한다

아래는 이 글에서 제안하는 테스트 계획이다. 통과 결과를 주장하는 목록이 아니다.

• 설치 직후와 준비 완료 후를 나눈다. 모델이 없는 상태의 안내, 다운로드 실패, 준비가 끝난 뒤 비행기 모드에서의 동작을 따로 확인한다.

• 한국어를 독립 항목으로 둔다. 대상 모델·음성의 지원 목록을 확인한 뒤, 숫자·금액·영문 제품명·약어가 섞인 문장으로 발음과 인식 오류를 기록한다. 영어 데모 성공을 한국어 품질의 근거로 쓰지 않는다.

• 첫 소리와 전체 완료 시간을 따로 잰다. 요청부터 첫 재생까지, 마지막 재생까지, 중간 무음 간격을 분리한다. 모델 초기화가 포함된 실행과 재사용 실행도 구별한다.

• 중단을 일부러 겹친다. 첫 청크 전, 재생 중, 마지막 청크 직전에 멈춘 뒤 곧바로 새 질문을 한다. 이전 음성이 섞이거나 새 응답까지 취소되지 않는지 확인한다.

• 동시 부하를 재현한다. 언어 모델 생성과 TTS가 함께 도는 조건에서 발열·메모리·재생 끊김을 확인한다. 단독 TTS 측정만으로 대화 품질을 판단하지 않는다.

• 데이터 경로를 점검한다. 음성 추론이 로컬이어도 앱의 로그·분석·백업이 별도로 내용을 전송할 수 있다. 온디바이스라는 이름만으로 전체 앱의 개인정보 보호를 보장하지 않는다.

결론: 모델보다 준비 상태와 대화 수명주기가 먼저다

이번 발표의 실용적 가치는 로컬 음성 대화의 구현 선택지를 구체적인 데모와 API로 확인할 수 있다는 데 있다. 도입할 때는 대상 기기에서 모델과 음성을 준비할 수 있는지부터 확인하고, 문장 단위 재생과 취소 경계를 설계하는 편이 좋다.

지원 범위와 alpha API는 바뀔 수 있다. 이 글의 공식 자료 확인 기준일은 2026년 11월 15일이며, 실제 배포 전에는 링크된 문서와 대상 기기에서 다시 검증해야 한다.