모바일 제어를 위한 음성 파이프라인 최적화

Github: Jin-A-Park/Speak2UI

실시간으로 음성 명령을 입력받아 LLM으로 사용자 명령을 분석하고, Android A11y API를 통해 동작을 실행하는 프로젝트다. 안드로이드 단에서 정보를 불러오고 조작하는 코드는 주로 Jin-A-Park님께서 작업해 주셨고, 필자는 주로 LLM 기반 명령 해석 모듈의 개발 및 실험을 담당했다. 추가로 음성 파이프라인 최적화와 코드 리펙토링을 담당했다. LLM 단의 작업은 뻔한 내용이기에, 본 글에서는 음성 파이프라인을 최적화해야 했던 이유와 방법을 중심으로 소개하려 한다.

왜 하필 음성인가요

처음에는 시선 추적을 이용해 화면을 조작하려 했다. 하지만 시선 추적 정확도가 높지 않을뿐더러, 정확한 시선 추적이 된다 하더라도 모바일 상의 버튼이 너무 작아서 정밀한 조작이 어렵다고 판단했다. 그래서 버튼의 물리적인 크기에 구애받지 않는 인터페이스가 필요했고 음성 명령이라는 결론에 도달했다. 대신 음성으로 조작하기 위해서는 화면 상에 상호작용한 요소가 무엇이 있는지 파싱하고, 사용자의 명령을 어떤 요소와 매핑할지 실시간으로 추론해야 하는 등 추가적인 판단과 조작이 들어가야 했다. 따라서 우리 팀은 tooptip + LLM을 활용하기로 했다.

상호작용 가능한 요소를 정확히 매핑하기 위해 레이블이 명확하지 않은 요소는 실시간으로 숫자를 매기도록 했다. 이 기능을 tooltip이라고 이름 붙였다. 사용자 명령이 어떤 요소를 의도했는지 판단하는데는 LLM의 추론 능력을 활용했다. 자세한 구현은 논문(공개예정)에서 확인할 수 있다. 이 방식을 통해 버튼의 물리적인 크기에 제약받지 않으면서도 직관적인 인터페이스를 제공할 수 있다.

음성 인식 왜 이렇게 느려요

필자가 음성 처리 파이프라인 쪽으로 넘어갈 당시, VAD가 구현되어 있었지만 무슨 이유에서인지 짧은 발화를 인식하는데 10초가 걸렸다. 처음에 의심했던 부분은 I/O로 인한 딜레이였다. 사용자 발화를 메모리에 모두 저장했다가, 발화가 종료되면 wav 파일로 저장되는 흐름이었기 때문에 메모리에서 디스크로 저장하는 과정에서 딜레이가 발생할 거라 생각했다. 따라서 한 번에 wav로 저장하는 대신 실시간으로 디스크에 음성 정보를 밀어넣고, 입력이 끝나면 wav 포맷으로 재구성해주는 방식을 이용해 I/O 딜레이를 해결했다. 그림으로 표현하면 아래와 같다.

하지만 여전히 음성 처리에 10초가 걸렸다. 문제를 디버깅 해보니 VAD 자체에 문제가 있었다. VAD 구현을 간단히 정리하면 특정 크기(db) 이상의 소리가 들리면 사용자가 발화를 시작했다고 판단한다. 그런데 소음을 판단하는 기준(threshold)이 낮게 설정되어 있으면 잡음까지도 발화라고 인식하는 현상이 생긴다. 추가로 시스템에서 발화의 최대 길이를 10초로 제한해뒀기 때문에 음성 인식에 항상 10초가 걸렸던 것이었다. 해결 방법은 간단하다. 음성 인식을 받기 전, 짧게 주변 소음 수준을 인식해 동적으로 임계값을 조절하면 된다. 그럼 완벽하진 않지만 주변의 소음 수준을 지속적으로 반영할 수 있게 된다. 이 방식을 적용했더니 10초가 걸리던 음성 인식을 1초 대로 단축할 수 있었다.

말귀를 못 알아 들어요

마지막으로 실사용성을 확인하기 위해 사용자에게 영상 재생, 네비게이션 검색, 채팅 전송 3가지 과제를 수행하도록 하고 관찰 실험과 설문을 진행했다. 8명의 실험 참가자는 모두 한국어를 사용해 명령을 수행했다. 그런데 생각보다 명령이 의도한대로 처리되지 못했다. 실시간으로 로그를 뜯어보니 STT 단계가 문제였다. 애초에 오디오가 텍스트로 정확히 변환이 안 되니 그 뒤에 일어나는 과정도 제대로 수행되지 않았다. 빠르고 저렴하게 처리하기 위해 gpt-4o-mini-transcribe를 사용했는데, 아직 부정확한 한국어 발음은 잘 처리하지 못하는 모양이다. STT 모듈은 쉽게 변경할 수 있기 때문에 상황에 맞는 적절한 모델을 선택해 성능 개선을 기대할 수 있다.