API 호출 당근마켓 시대는 끝났다: 99M 초경량 아키텍처로 167배 빠른 온디바이스 TTS 구현하기 (Supertonic 딥다이브)

Posted May 21, 2026

The Era of API Hustling is Over: Implementing 167x Faster On-Device TTS with 99M Ultra-Light Architecture (Supertonic Deep Dive)

19 min read

[Supertonic Metadata]
Repository: supertone-inc/supertonic
Core Architecture: Flow-matching 기반 Text-to-Latent 구조, 약 99M 파라미터 (V3 퍼블릭 ONNX 에셋 기준)
Runtime Ecosystem: ONNX Runtime (CPU / WebGPU / WASM / JVM JNI 등) 멀티플랫폼 지원
Performance: RTF(Real-time Factor) 0.001 (NVIDIA RTX 4090), 0.006 (Apple M4 Pro)
Language Support: 31개국어 및 Expressive Tags(<laugh>, <breath>) 지원

3. The Hook (공감과 도발): ‘API 호출’이라는 지독한 족쇄

솔직히 한 번이라도 현업에서 음성 AI(TTS) 기능을 프로덕션 레벨에 올려본 분들이라면 아실 겁니다. 로컬 환경에서 데모를 띄울 때까지만 해도 ElevenLabs나 OpenAI의 TTS API는 마치 마법 같죠. 하지만 막상 실제 유저 트래픽이 몰리기 시작하는 순간, 그때부터 진짜 ‘지옥’이 펼쳐집니다.

“응답 속도 왜 이래요? 텍스트 치고 한참 뒤에 소리가 나는데요?”, “지하철에서 네트워크 끊기니까 앱이 그냥 먹통이 됩니다” 같은 사용자들의 CS는 예사고요. 매달 트래픽에 비례해 기하급수적으로 찍히는 무시무시한 API 과금 청구서를 볼 때마다 인프라 담당자의 등골은 서늘해집니다. 게다가 금융이나 의료, 혹은 B2B 엔터프라이즈 도메인이라면? 유저의 민감한 텍스트 데이터를 클라우드로 전송하는 그 순간 사내 보안팀의 결재 반려를 피할 수 없습니다.

우리는 언제까지 클라우드 벤더사의 API 상태창만 쳐다보며 기도 메타로 서비스를 운영해야 할까요? 오늘 밑바닥까지 뜯어볼 기술은 이런 현업의 고질적인 Pain point를 완전히 박살 내기 위해 등장한 녀석입니다. 바로 수퍼톤(Supertone Inc.)에서 오픈소스로 공개한 초경량 온디바이스 TTS 엔진, Supertonic(수퍼토닉)입니다.

4. TL;DR (The Core): 핵심 가치 요약

TL;DR: Supertonic은 무거운 클라우드 의존성을 끊어내고, 단 99M 파라미터와 ONNX 런타임만으로 실시간보다 167배 빠른(RTF 0.006) 음성 합성을 완전 오프라인에서 처리해버리는 ‘엣지(Edge) 네이티브 TTS 생태계의 거대한 게임 체인저’입니다.

5. Deep Dive: Under the Hood (핵심 아키텍처 심층 분석)

Supertonic 아키텍처를 처음 접했을 때, 제 머릿속을 스친 생각은 이랬습니다. “고작 99M 파라미터로 31개국어 다국어 TTS를 한다고? 그것도 실시간보다 167배 빠르게? 장난하나?”

보통 쓸만한 고품질 TTS 모델(예: 1.5B 파라미터급 거대 모델이나 무거운 딥러닝 백엔드를 요구하는 기존 오픈소스)들은 모바일 기기나 브라우저에서 돌리기엔 무리가 있습니다. 그런데 Supertonic은 V3 기준으로 전체 모델 자산(Assets) 디스크 용량이 404MB에 불과하며, 핵심 파라미터는 약 99M 수준으로 극단적인 경량화를 이뤄냈습니다. 이 변태적인 최적화의 비밀은 아키텍처의 분리와 Flow-Matching 메커니즘의 결합, 그리고 ONNX 런타임의 극한의 활용에 있습니다.

Supertonic의 파이프라인은 크게 3개의 모듈이 ONNX 텐서를 주고받으며 굴러갑니다.

Speech Autoencoder: 무겁고 복잡한 원본 파형(Waveform)을 다루기 쉬운 연속적인 잠재(Latent) 벡터 공간으로 압축합니다.
Text-to-Latent (Flow-Matching 기반): 여기서 기존의 무거운 Diffusion 모델 대신 ‘Flow-Matching’ 기법을 사용한 것이 신의 한 수입니다. Flow-matching은 단순한 확률 분포를 타겟 분포로 직행시키는 벡터 필드(Vector Field)를 학습합니다. 수십 번의 노이즈 제거 스텝이 필요한 Diffusion과 달리, 단 2번의 추론 스텝(Inference step)만으로도 고품질의 오디오 특징을 뽑아냅니다. 이것이 무자비한 RTF(Real-Time Factor)를 달성하는 핵심 엔진입니다.
Duration Predictor: Cross-attention 메커니즘을 이용해 텍스트와 음성의 길이를 자동으로 얼라인(Align)하고 자연스러운 억양과 페이스를 부여합니다.

게다가 저를 가장 감탄하게 만든 부분은 텍스트 정규화(Text Normalization)가 파이프라인 맨 앞에 완전히 내장되어 있다는 점입니다. 보통의 딥러닝 기반 TTS 시스템에서는 개발자가 직접 파이썬으로 지저분한 정규식(Regex)을 짜서 $5.2M을 five point two million dollars로 변환해 주는 별도의 파이프라인을 유지보수해야 합니다. 이건 사실상 실무에서 언어가 추가될 때마다 터지는 시한폭탄과 같죠. 반면 Supertonic은 자체 유니코드 프로세서가 이를 <lang> 토큰과 결합해 전처리 없이 모델 내부 인덱서에서 즉각적으로 매핑해버립니다.

아키텍처 특성 / 엔진	Supertonic 3 (Edge Native)	대형 클라우드 TTS (API)	전통적 VITS 기반 로컬 모델
파라미터/메모리 풋프린트	약 99M / RAM 1GB 이하 점유	비공개 (최소 1B 이상의 거대 모델)	약 30M ~ 150M
네트워크 의존성	완전 오프라인 (Zero-latency)	필수 (RTT 통신 지연 발생)	완전 오프라인
추론 속도(RTF)	0.001(RTX 4090) ~ 0.006(M4 Pro)	네트워크 응답 및 벤더 트래픽에 종속	0.1 ~ 0.3 수준 (최적화 부재 시)
텍스트 정규화 로직	모델 파이프라인 단에 기본 내장	클라우드 내부 블랙박스 처리	개발자가 별도 전처리 서버 구축 필수
인프라 비용	0원 (유저 디바이스 로컬 자원 소모)	트래픽에 비례한 막대한 종량제 과금	클라우드 GPU 인스턴스 유지 비용

이 구조가 코드로 어떻게 돌아가는지 민낯을 한번 까봅시다. 겉보기엔 허탈할 정도로 단순하지만, 이면의 로직은 대단히 날카롭습니다.

  
import time
import json
from supertonic import TTS

# 1. 커스텀 보이스 JSON 로드 (V3의 핵심: style_ttl, style_dp 임베딩 벡터값 로드)
# 수퍼톤 보이스 빌더 등에서 추출한 브랜드 고유의 페르소나를 모델의 Latent 공간에 주입합니다.
with open("brand_persona_voice.json", "r") as f:
    voice_embedding = json.load(f)

# 2. ONNX 모델 자동 다운로드 및 메모리 적재 (초기 구동 시에만 콜드스타트 발생)
tts = TTS(auto_download=True)
style = tts.get_voice_style(voice_name="M1") # 기본 프리셋 사용 시

# 정규화가 까다로운 텍스트와 V3의 익스프레시브 태그 혼합
text = "The startup secured $5.2M in venture capital. <laugh> It's an amazing milestone!"

start_time = time.time()
# 3. Text-to-Latent -> Autoencoder 보코더를 거치는 파이프라인 실행
wav, duration = tts.synthesize(
    text, 
    voice_style=style, 
    speed=1.0, 
    expressive_tags=True # <laugh>, <breath> 등의 태그를 모델이 직접 파싱하여 운율 부여
)
latency = time.time() - start_time

print(f"Generated {duration:.2f}s of audio in {latency:.4f}s (RTF: {latency/duration:.4f})")
tts.save_audio(wav, "output_16bit.wav")

이 한 줄의 synthesize() 코드가 실행될 때, 파이썬의 악명 높은 GIL(Global Interpreter Lock)은 전혀 문제가 되지 않습니다. C++로 작성된 ONNX Runtime이 내부적으로 하부 스레드 풀을 관리하며 텐서 연산을 병렬 처리하기 때문입니다.

6. Pragmatic Use Cases (실무 적용 시나리오)

현업에서 이 녀석을 어떻게 아키텍처에 녹여낼 수 있을까요? 뻔한 장난감 프로젝트가 아니라, 진짜 피 튀기는 실무 시나리오를 설계해 봅시다.

시나리오 A: 브라우저 WebGPU를 활용한 ‘비용 제로’ 대규모 트래픽 방어 매일 아침 8시, 전 세계 10만 명의 동시 접속자에게 뉴스 브리핑을 읽어주는 서비스를 운영한다고 가정해보죠. 이 트래픽을 서버 사이드나 외부 API로 처리하면 아침 식사 시간 한 번에 수십만 원의 비용이 증발합니다. 하지만 Supertonic의 브라우저 패키지(web/)를 프론트엔드에 심어버리면 이야기가 달라집니다. WASM과 WebGPU를 통해 사용자 기기(크롬 브라우저, 아이폰 사파리 등)의 컴퓨팅 파워를 빌려 완전 오프라인으로 16-bit WAV 버퍼를 실시간 생성해냅니다. 서버 부하는 ‘0’이 되고, 동시 접속자가 100만 명으로 뛰어도 TTS 인프라 비용은 단 1원도 증가하지 않습니다. 이것이 엣지 컴퓨팅의 진정한 파괴력입니다.

시나리오 B: 레거시 Java Spring Boot 환경에서의 마이크로서비스 무중단 연동 기존 Java 기반 금융권 엔터프라이즈 서버에 음성 인증이나 ARS 동적 생성 기능을 얹어야 할 때, 파이썬 기반의 무거운 AI 모델을 RPC 통신으로 묶는 것은 트랜잭션 관리의 재앙을 낳습니다. Supertonic은 JNI(Java Native Interface)를 통한 크로스 플랫폼 JVM 바인딩(java/)을 공식 지원합니다. 외부 통신 없이 Spring 애플리케이션의 힙 메모리 밖에서 직접 .onnx 모델을 로드하여 즉각적으로 음성 Byte Array를 생성한 뒤, WebSocket이나 WebRTC 프로토콜을 태워 클라이언트에게 스트리밍할 수 있습니다.

7. Honest Review & Trade-offs (진짜 장단점과 한계)

자, 여기까지 보면 모든 문제를 해결해 줄 완벽한 은탄환 같지만, 시니어 엔지니어의 비판적인 시선으로 보면 절대 도입 전 간과해선 안 될 치명적인 트레이드오프들이 도사리고 있습니다.

첫째, 극단적 경량화로 인한 ‘감정적 뉘앙스’의 깊이 부족입니다. 99M 파라미터는 컴퓨팅 효율성에 있어서는 기적에 가깝지만, 무려 1.5B 파라미터를 넘나드는 ElevenLabs 급의 소름 돋는 내러티브 연기나 섬세한 컨텍스트 인식을 온전히 기대하긴 힘듭니다. V3에서 <laugh>, <sigh> 같은 표현 태그를 도입하여 활로를 뚫었지만, 긴 호흡의 오디오북을 생성할 때 문맥의 반전을 이해하고 스스로 톤을 극적으로 바꾸는 능력에서는 여전히 깡통 로봇 같은 한계점이 이따금 노출됩니다.

둘째, 숨겨진 벤더 락인(Vendor Lock-in) 리스크입니다. Supertonic의 추론(Inference) 엔진 자체는 MIT/Apache 라이선스 기반의 훌륭한 오픈소스지만, 서비스만의 독창적인 ‘커스텀 보이스 페르소나’를 생성하기 위한 Voice Builder 플랫폼은 수퍼톤의 상용 서비스에 강하게 묶여 있습니다. 커스텀 보이스의 style_ttl, style_dp JSON을 추출하기 위해서는 결국 지갑을 열어야 하는 비즈니스 모델을 취하고 있다는 점을 아키텍처 설계 시 비용 리스크로 상정해두어야 합니다.

셋째, ONNX와 하드웨어 파편화의 디버깅 지옥입니다. 로컬 기기의 자원을 쓴다는 것은 기기 파편화의 저주를 개발자가 오롯이 짊어진다는 뜻입니다. WebGPU가 지원되지 않는 구형 안드로이드 기기에서의 WebGL/WASM Fallback 처리, Rust나 C++ 백엔드에서 ONNX Runtime 세션 메모리가 해제되지 않아 발생하는 메모리 누수(Memory Leak) 등은 여전히 프론트/클라이언트 개발자를 괴롭힐 매우 까다로운 과제입니다.

8. Closing Thoughts: 개발자가 통제권을 되찾는 시간

그럼에도 불구하고, Supertonic이 쏘아 올린 공은 음성 AI 생태계에 매우 건강한 패러다임 시프트를 던지고 있습니다. “모든 것을 무겁게 클라우드에 올려라”라고 강요하던 빅테크들의 독점적 문법에서 벗어나, “필요한 곳에서, 극단적으로 가볍고, 프라이빗하게”라는 엣지 컴퓨팅의 반격이 시작된 것이죠.

현업 실무자로서 우리가 취해야 할 스탠스는 명확합니다. 모든 문제에 수십억 개의 파라미터짜리 거대 모델을 들이밀 필요는 없습니다. 사용자의 터치 한 번에 0.1초 내로 피드백이 떨어져야 하는 반응성, 네트워크 연결조차 보장할 수 없는 가혹한 모바일 환경, 그리고 극강의 서버 비용 절감이 필요한 백엔드 구간이 있다면 주저 없이 Supertonic 같은 초경량 ONNX 아키텍처를 과감히 도입해야 합니다. 기술의 ‘무게’를 덜어내고 인프라의 주도권을 되찾는 것, 그것이 결국 서비스 생존력을 높이는 가장 예리한 무기이기 때문입니다.

References

https://github.com/supertone-inc/supertonic
https://huggingface.co/Supertone/supertonic-3
https://huggingface.co/spaces/Supertone/supertonic-2
https://supertone.ai/voice-builder

Tech

This post is licensed under CC BY 4.0 by the author.