Why I run speech-to-text locally instead of calling a cloud API

개요

개인 서버에서 클라우드 API 대신 로컬로 Speech-to-Text(STT)를 실행하는 것은 작업 통화와 같이 민감한 오디오 데이터의 보안을 강화하고 데이터 프라이버시를 보장하는 효과적인 방법이다.

주요 내용

* 클라우드 STT API의 문제점: OpenAI Whisper, Google Speech-to-Text, Amazon Transcribe와 같은 클라우드 STT API를 사용하면 오디오 데이터가 외부 서버로 전송되고 제어할 수 없는 하드웨어에서 처리된다.
* 로컬 STT의 이점: 개인 서버에서 Whisper를 로컬로 실행하면 오디오 파일이 해당 머신에 머물러 데이터가 외부로 유출되지 않으므로 민감한 정보(고객 이름, 프로젝트 세부 정보, 가격 논의 등)를 보호할 수 있다.
* 로컬 STT 설정: RTX 3060 (12 GB VRAM) GPU를 갖춘 로컬 서버에서 int8 양자화 모드의 faster-whisper를 사용하여 오디오 파일을 PWA를 통해 업로드하고 같은 머신에서 처리한다. API 호출, 인증 헤더, 외부 요청 로그 등이 발생하지 않는다.
* VRAM 제약 관리: 12GB VRAM 환경에서 Whisper medium (int8)은 약 2.5–3 GB를 사용하며, 다른 모델(gemma, bge-m3)과 VRAM을 공유한다. 모델은 순차적으로 로드되며, GPU 부하가 높을 경우 Whisper는 CPU로 대체 실행되어 속도는 느려지지만 중단 없이 작업을 완료한다.
* 로컬 STT의 한계: 로컬 STT는 자동적으로 정확도를 보장하지는 않으며, Whisper medium은 완벽하지 않아 이름, 전문 용어, 잡음 등에 따라 정확도가 저하될 수 있다. 또한, STT 이후의 다운스트림 파이프라인(텍스트에서 구조화된 정보 추출 등)은 별도로 구축해야 한다.
* 로컬 STT vs. 호스팅 Whisper 엔드포인트: 데이터 거주지가 중요하지 않다면 호스팅 Whisper 엔드포인트가 더 빠르고 하드웨어 관리 및 VRAM 예산 책정이 필요 없다는 장점이 있다. 하지만 데이터 보안이 우선이라면 로컬 실행이 더 적합하다.
* 구축 중인 애플리케이션: 이 로컬 STT 기능은 전화, 문자, 이메일을 통해 수집된 정보를 유용하게 변환하는 전화 비서 애플리케이션의 일부로 사용되며, 현재 STT 이후의 정보 추출 및 통합 부분은 개발 중이다.

시사점

민감한 데이터를 다루는 애플리케이션 개발 시, 클라우드 API 사용에 따른 데이터 보안 위험과 로컬 인프라 구축 및 운영 비용 간의 균형을 고려하는 것이 중요하다. 로컬 STT는 프라이버시와 보안을 최우선으로 할 때 실질적인 대안이 될 수 있다.