two-host video pipeline을 구축하면서 GPU 없이 GitHub Actions에서 실행할 수 있는 대부분의 무료 신경망 TTS (Text-to-Speech) 옵션들을 살펴보았습니다. 제가 중요하게 생각한 기준은 다음과 같습니다: API 비용 제로, 수용 가능한 음성 품질, CI 환경에서의 헤드리스 (headless) 실행 가능 여부, 그리고 추론 (inference) 시 CUDA가 필요하지 않을 것.

제가 테스트했거나 진지하게 검토한 4가지 옵션의 비교 결과입니다.

edge-tts (현재 사용 중인 방식)

GitHub: rany2/edge-tts | License: MIT (wrapper) | Voices: 100개 이상의 언어에 걸쳐 400개 이상의 음성

edge-tts는 Microsoft Edge의 읽어주기 TTS 엔드포인트(Edge에서 텍스트를 우클릭하고 "읽어주기"를 선택했을 때 실행되는 것과 동일한 엔드포인트)를 사용하는 Python 래퍼 (wrapper)입니다. MP3 출력을 스트리밍합니다. en-US-GuyNeural 및 en-US-AvaNeural 음성의 품질은 진정으로 방송 품질 수준이며, 오래된 오픈 소스 모델보다 눈에 띄게 뛰어나고 상용 API와 경쟁할 만한 수준입니다.

원격 엔드포인트에서 스트리밍하기 때문에 속도가 빠릅니다. CI 러너 (runner)의 하드웨어와 관계없이 10분 분량의 오디오 파일이 30~60초 내에 생성됩니다.

주의할 점: 비공식 Microsoft 엔드포인트를 호출한다는 것입니다. Microsoft는 이에 대한 공개 계약을 발표하지 않았으며 예고 없이 액세스를 제한할 수 있습니다. 저는 약 한 달 동안 문제없이 매일 실행해 왔지만, 이는 실제 운영상의 리스크입니다.

pip install edge-tts
edge-tts --voice en-US-GuyNeural --text "Hello world" --write-media out.mp3

가장 적합한 경우: 음성 품질이 중요하며 외부 비공식 API 의존성을 수용할 수 있는 CI 파이프라인.

Kokoro-82M

HuggingFace: hexgrad/Kokoro-82M | License: Apache 2.0 | Params: 82M

Kokoro는 완전히 로컬에서 실행되는 작은 TTS 모델입니다. 모델 크기 대비 음성 품질이 좋습니다. Tacotron2나 FastSpeech2와 같은 오래된 모델보다는 눈에 띄게 뛰어나지만, 긴 문장의 자연스러움 측면에서는 edge-tts보다는 낮습니다.

CI를 위한 주요 트레이드오프(tradeoff): 표준 GitHub Actions 러너(runner)에서 CPU로 추론(inference)할 경우 실시간(real-time)보다 훨씬 느리게 작동합니다. 10분 분량의 오디오 작업은 세그먼트(segment) 수와 텍스트 밀도에 따라 렌더링하는 데 10분보다 훨씬 더 오랜 시간이 걸릴 수 있습니다. 짧은 형식의 콘텐츠(3분 미만)의 경우 보통 문제가 되지 않지만, 더 긴 영상의 경우에는 병목 현상(bottleneck)이 됩니다.

첫 실행 시 약 320MB의 모델 가중치(model weights)를 다운로드합니다. GitHub Actions에서 이를 캐시(cache)하면 이후 실행 시 다운로드를 건너뛸 수 있습니다.

from kokoro import KPipeline
pipeline = KPipeline(lang_code="a")  # "a" = American English
audio, sr = next(pipeline("Hello world", voice="af_heart"))

가장 적합한 경우: 외부 API 호출 없는 완전한 로컬 추론(local inference), 감사 가능하고 오프라인 작동이 가능한 TTS가 필요한 프로젝트.

MeloTTS

GitHub: myshell-ai/MeloTTS | License: MIT | Languages: 영어, 중국어, 일본어, 한국어, 프랑스어, 스페인어

MyShell.ai의 MeloTTS는 다국어 모델이며, 제 테스트 결과 평균 이상의 영어 자연스러움을 보여주었습니다. Python 패키지는 melo-tts (pip)이며, API를 통해 클립 사이에서 모델을 다시 로드할 필요 없이 발화(utterance)별로 화자 ID(speaker ID)와 속도를 설정할 수 있습니다. 이는 수백 개의 짧은 대화 세그먼트를 배치(batch)로 렌더링할 때 유용합니다.

CPU 추론 속도는 Kokoro와 비슷한 범위입니다. 모델 다운로드 크기는 약 500MB입니다. MIT 라이선스는 이를 기반으로 제품을 구축할 때 실질적인 장점입니다. Apache 라이선스 호환성 문제를 고민할 필요가 없습니다.

from melo.api import TTS
tts = TTS(language="EN", device="cpu")
tts.tts_to_file("Hello world", tts.hps.data.spk2id["EN-Default"], "out.wav")

가장 적합한 경우: 다국어 콘텐츠 파이프라인, 또는 견고한 영어 품질을 갖춘 MIT 라이선스 로컬 TTS를 원하는 경우.

Bark by Suno

GitHub: suno-ai/bark | License: MIT | Size: ~1.7GB (small), ~8GB (large)

Bark는 네 가지 모델 중 목소리의 표현력(expressiveness) 측면에서 가장 뛰어납니다. 프롬프트 텍스트 내에 웃음([laughs]), 한숨, 망설임, 그리고 비음성적 소리(non-speech sounds)를 직접 지정할 수 있습니다. 대형 모델(large model)의 품질은 상용 TTS API와 경쟁할 만한 수준입니다.

표준 CI(Continuous Integration) 환경에서의 문제는 다음과 같습니다: 대형 모델은 상당한 VRAM을 갖춘 GPU가 필요하며, CPU에서는 30초 분량의 오디오를 렌더링하는 데 몇 분이 소요됩니다. 소형 모델(small model)은 RAM에 적합하지만 품질이 눈에 띄게 저하됩니다. GitHub Actions의 표준 러너(runners)에는 GPU가 없기 때문에, 대형 모델은 비실용적이며 소형 모델은 품질이 크게 떨어지는 문제가 있습니다.

가장 적합한 용도: 표현력 있는 음성 효과가 하드웨어 요구 사항을 정당화할 수 있는 로컬 GPU 추론(inference). 표준 CPU 전용 CI 러너에는 실용적이지 않습니다.

비교 (Comparison)

표준 GitHub Actions 러너에서 자동화된 비디오 파이프라인을 구축한다면, 비공식 API 의존성을 수용할 경우 edge-tts가 실용적인 선택입니다. 만약 완전한 로컬 추론이 필요하고 비디오 길이가 3~4분 미만이라면, Kokoro 또는 MeloTTS 모두 합리적인 작업 시간 예산 내에서 작동합니다. Bark는 무료 CI 러너가 아닌 GPU 장비에 적합합니다.

세 개의 AI 큐레이션 디렉토리 사이트를 운영하는 6개월간의 지속적인 실험의 일부입니다. 여기에 언급된 기술적 주장들은 사실이며, 이 기사는 AI의 도움을 받아 작성되었습니다.