음성 API 요금이 매출을 갉아먹는다, 기기에서 도는 목소리로 뒤집을 수 있을까

어떤 문제인가

음성을 많이 쓰는 서비스는 성장할수록 원가가 같이 자란다. 오디오북 낭독, 시각장애인용 화면 리더, 언어학습 앱의 발음, 영상 더빙, IVR 안내음성. 이들은 대부분 클라우드 TTS API를 호출하고, 요금은 글자 수나 분 단위로 매겨진다.

문제는 이 비용이 매출과 함께 선형으로 늘어난다는 점이다. 사용자가 두 배 늘면 음성 생성 비용도 두 배다. 서버비처럼 규모의 경제가 잘 안 든다. 특히 같은 문장을 여러 사용자가 반복 요청하는 서비스가 아니면 캐싱 효과도 약하다. 결과적으로 음성이 핵심 기능인 제품일수록, 매출총이익률이 사용량과 반대로 움직인다. 잘 팔릴수록 마진이 얇아지는 구조다.

왜 지금인가

작은 오픈 음성 모델의 품질과 속도가 임계점을 넘었다. Kokoro는 82M 파라미터에 불과한데 Apache 2.0으로 가중치가 공개돼 있고, 그래픽카드 없이 CPU만으로도 실시간보다 빠르게 음성을 뽑는다. 애플 실리콘 CPU 기준 대략 실시간의 5배 이상 속도가 보고됐고, 모델 파일은 300MB 대다. v1.0은 8개 언어에 54개 목소리를 담았다.

이 조합이 의미하는 건 하나다. 음성 생성을 사용자의 기기나 내 서버 한 대에서 돌릴 수 있게 됐다는 것. 분당 API 요금이 고정비(장비·전기)로 바뀐다. 사용량이 열 배 늘어도 추가 비용은 거의 0에 수렴한다. 클라우드 음성 API가 만들던 “쓸수록 손해” 구조가 뒤집힌다.

flowchart LR
  A[텍스트 입력] --> B{음성 생성 위치}
  B -->|기존| C[클라우드 TTS API<br/>분당·글자당 과금]
  B -->|전환| D[온디바이스/자체서버<br/>Kokoro 등 오픈모델]
  C --> E[매출과 함께<br/>선형 증가하는 원가]
  D --> F[고정비<br/>한계비용 0에 수렴]

어떻게 만들 수 있나

MVP는 “음성 원가가 아픈 한 버티컬”을 골라 시작한다. 예를 들어 긴 글을 오디오로 바꿔 듣는 리더 앱이라면, 서버 대신 사용자 브라우저·앱 안에서 온디바이스로 음성을 합성한다. 첫 방문에 모델을 한 번 받고 캐시하면, 이후 낭독은 네트워크도 요금도 없이 돈다.

기술 스택은 가벼운 오픈 TTS 모델(Kokoro 계열)을 온디바이스 런타임(WebAssembly·모바일 네이티브)에 얹는 것이 핵심이다. 품질이 클라우드 프리미엄 음성만 못한 구간은 남는다. 그래서 처음부터 전부를 대체하기보다, “무료·기본 음성은 온디바이스, 프리미엄 목소리만 클라우드”처럼 층을 나누는 설계가 현실적이다. 비용의 대부분을 만드는 대량·일반 사용을 고정비로 옮기고, 클라우드는 프리미엄에만 남긴다.

성공 조건

핵심 가정은 두 가지다. 첫째, 타깃 사용자가 “완벽한 목소리”보다 “요금 없이 무제한”을 더 원하는가. 접근성·학습·대량 낭독처럼 양이 가치인 영역은 여기에 맞는다. 둘째, 온디바이스 모델 로딩과 첫 합성 지연을 사용자가 감내할 수준으로 숨길 수 있는가. 이 둘이 검증되면, 경쟁사가 클라우드 요금에 묶여 있는 동안 당신만 한계비용 0으로 싸울 수 있다.