결론

상업적 이용 가능 (Apache 2.0)한 다국어 Voice Clone OSS가 최근 반년 사이에 3개나 등장했습니다. 모두 Mac에서 구동 가능합니다 (CosyVoice는 CPU, Qwen3-TTS는 MPS).

Qwen3-TTS (Alibaba Qwen, 2026-01, Apache 2.0): 7개 언어 중 6개 언어에서 CER ≤ 0.045, 전처리 전혀 불필요, zh(중국어)만 CER 0.20로 재검증 필요 -
CosyVoice 2 (Alibaba, 2024-12, Apache 2.0): JA(일본어)에서 CER 0.023, 수치상으로는 최강이지만, de(독일어)/zh(중국어)에서 여성화, ko(한국어)/fr(프랑스어)에서 장문 중복 등 타 언어에서 중대한 버그 있음. 스택이 오래되어 의존성 해결이 어려움 -
Fun-CosyVoice 3 (Alibaba, 2025-12, Apache 2.0): 모든 언어에서 음질이 안정적이지만, JA를 kanji(한자)로 직접 입력하면 CER 0.25로 붕괴(frontend 버그 기인). 전처리 (kanji→katakana + は→わ)를 통해 CER 0.045까지 개선 가능

Qwen3-TTS 0.6B-Base가 현재의 유력한 후보입니다. JA CER은 CosyVoice 2 (0.023)에 비해 0.045로 수치상으로는 밀리지만, 200자 기준 4자 차이이며 Whisper 인식 오차와 비슷한 수준이라 실운용 시에는 구분이 불가능합니다. Mac MPS에서 구동 가능 / pip install qwen-tts.

한 번에 실행 가능 / 타 언어에 대한 보험이 작동함 / 1.7B-Base로의 업그레이드 경로(upgrade path)가 존재함 등, CER 이외의 모든 축에서 승리합니다.

CosyVoice 3는 전처리 파이프라인을 구축할 각오가 되어 있다면 9개 언어에서 안정적이며, Qwen3-TTS가 zh에서 무너지는 용도를 보완하는 형태가 됩니다.

검증 코드, 생성 음성, 스코어 JSON은 모두 GitHub에 공개되어 있습니다.

지난 글까지의 흐름

지난 글 (2026-06-20)에서 F5-TTS / XTTS-v2 / OpenVoice v2 / ElevenLabs를 7개 언어로 비교하였으며, 종합 1위는 ElevenLabs, OSS 중에서는 XTTS-v2가 선두라는 결론을 내렸습니다.

하지만 채택 관점에서는 다음과 같은 문제점이 있었습니다.

XTTS-v2 (CPML): Coqui 해산으로 상업용 라이선스 발행 주체가 소멸하여, 프로덕션(production) 채택 불가 -
F5-TTS (CC-BY-NC): 상업적 이용 불가. 사내 도구라 하더라도 '업무 이익에 기여한다면 상업적 이용'으로 간주하는 해석이 일반적 -
Fish Speech open weights (CC-BY-NC-SA): 위와 동일 -
OpenVoice v2 (MIT): 상업적 이용 가능하나 JA 품질이 2선급이며, de는 구조적으로 불가 -
ElevenLabs: 상업적 이용 가능한 API이지만 단가가 높고 voice slot 상한선이 있음

"상업적 이용 가능 + 다국어 + JA 구동 + 자체 호스팅 가능"을 모두 만족하는 선택지가 사실상 없었습니다.

그 후 최신 정보를 조사한 결과, Alibaba 계열에서 3개의 Apache 2.0 Voice Clone 모델이 출시되었기에 이를 검증하는 방식으로 진행합니다.

비교 대상 (3개 모델, 모두 Apache 2.0)

GitHub repo / HF weights 모두 Apache 2.0임을 확인했습니다. NOTICE / LICENSE 동봉 규칙만 준수한다면 SaaS 배포도 가능합니다.

검증 조건

지난번 (06-20)의 프레임워크를 유용함.

결과 요약

CER (낮을수록 좋음)

★ = 상용 채택 가능 수준, ✕ = 채택 불가, ⚠ = 재검증 필요

F0 차이 (참조 음성 104.9Hz에 대한 차이, ±20Hz 이내에서 음질 유지)

CER과 F0를 종합해 보면,

• CosyVoice 2: JA(일본어)는 CER 0.023으로 수치상 최강이지만, de/zh에서 여성화가 발생하고, ko/fr에서 장문/무음 중복이 나타남 (상세 후술)
• CosyVoice 3: 모든 언어에서 음질이 안정적이지만, JA가 붕괴됨 (이 또한 상세 후술)
• Qwen3-TTS: 6개 언어에서 완벽하며, zh(중국어)만 주의 필요. JA는 CosyVoice 2와 0.022 차이(200자 기준 4자 차이)로 실질적으로 호각 수준

일본어 (ja) 비교 청취

기대 텍스트: 皆さん、こんにちは。本日は新しい機能についてご紹介します。どうぞよろしくお願いいたします。(여러분, 안녕하세요. 오늘은 새로운 기능에 대해 소개해 드리겠습니다. 잘 부탁드립니다.)

CosyVoice 2 (bigram 0.93 / CER 0.023)

Whisper 전사: 「皆さんこんにちは 本日は新しい機能についてご紹介します どうぞよろしくお願いいたします」

구두점이 누락되었을 뿐 음절은 완전히 일치합니다. 수치상으로는 3개 모델 중 CER이 가장 낮으며, ElevenLabs (CER 0.020)와 대등한 수준입니다. F0 차이도 −8Hz로 완벽합니다. 다만 후술할 Qwen3-TTS (CER 0.045)와의 차이는 200자 기준 4자 차이로, 청감상 거의 구별할 수 없습니다.

CosyVoice 3 (bigram 0.50 / CER 0.250) — 한자(kanji) 직접 입력 시 파손

Whisper 전사: 「皆さんこんちいっかいマロは新しい機能についてご誠意しますどうぞよろしくお願いいたします」

「こんにちは(안녕하세요)」 → 「こんちい(콘치이)」、「本日は(오늘은)」 → 「いっかいマロは(잇카이마로와)」、「紹介(소개)」 → 「誠意(성의)」와 같이 무너졌습니다. 동일한 Alibaba 계열이자 동일한 Apache 2.0 라이선스임에도 JA의 품질은 이 정도로 차이가 납니다. 원인은 frontend의 버그이며, 근본 원인은 다음 섹션에서 분리하여 설명하겠습니다.

Qwen3-TTS (bigram 0.86 / CER 0.045)

Whisper 전사: 「皆さんこんにちは 本日は新しい機能についてご紹介しますどうぞよろしくお願いいたします」

전사 결과는 CosyVoice 2와 동일하며, 구두점이 누락되었을 뿐 완벽한 내용입니다. CER 0.045와 0.023의 차이는 앞서 언급한 대로 4자 차이이므로 청감상 구별 불가합니다.

CosyVoice 2와의 결정적인 차이는:

• 한자 (kanji) 직접 입력 시 문제없이 작동 (CosyVoice 3의 contains_chinese() 버그가 없음)
• Mac MPS에서 동작 (CosyVoice는 CPU만 지원)
• pip install qwen-tts 명령 한 번으로 설치 완료 (CosyVoice는 git clone + 서브모듈 + setuptools<76 고정 + numpy 1.26 고정 등 의존성 해결이 매우 까다로움)
• transformers-style의 직관적인 API (CosyVoice는 load_vllm=False와 같은 최적화 플래그를 수동으로 False로 설정해야 하며, Matcha-TTS의 sys.path 설정이 필요함)
• 0.6B / 1.7B 두 가지 사이즈 공개로 품질 업그레이드 경로(upgrade path)가 존재
• 6개 언어에 대한 보험이 적용됨 (향후 "다국어 대응을 하고 싶다"라고 결정했을 때, CosyVoice 2는 de/zh/fr에서 무너짐)

일본어(JA) 용도라 할지라도, 이 요소들을 종합하면 Qwen3-TTS를 선택하지 않을 이유가 거의 없다는 것이 솔직한 평가입니다. CosyVoice 2를 선택할 동기가 성립하는 경우는 "CER의 마지막 2%를 쥐어짜야 하는 특수한 품질 요구사항이 있으며, 동시에 다른 언어는 영원히 절대 사용하지 않는다"라는 극히 제한적인 조건 하에서만 가능합니다.

contains_chinese() 버그

CosyVoice 3가 일본어(JA)에서 무너지는 이유 — CosyVoice 3의 일본어 성능 저하의 정체는 프론트엔드(frontend)의 언어 판정 로직이 일본어의 한자(kanji)를 중국어로 오판정하는 것입니다.

cosyvoice/utils/frontend_utils.py:

chinese_char_pattern = re.compile(r'[一-鿿]+')
def contains_chinese(text):
    return bool(chinese_char_pattern.search(text))

一-鿿은 CJK Unified Ideographs 블록이며, 일본어의 상용 한자는 모두 이 범위에 포함됩니다 (중국어와 동일한 Unicode 블록을 공유).

cosyvoice/cli/frontend.py에서의 사용법:

if contains_chinese(text):
    text = self.zh_tn_model.normalize(text) # 중국어 텍스트 정규화
    text = text.replace(".", "。")
    ...

즉, 일본어 한자가 포함된 텍스트는 통째로 **중국어 전처리 경로(preprocessing path)**를 타게 됩니다. 이로 인해 일본어(JA)가 붕괴됩니다.

구제 레시피 (CER 0.045까지 개선)

contains_chinese를 몽키 패치(monkey-patch)하는 것만으로는 불충분하며 (모델 본체에도 한자 $\rightarrow$ 중국어식 읽기 편향(bias)이 존재함), 다음과 같은 레시피가 필요합니다:

def cosyvoice3_ja(text_kanji):
    # 1. 한자(kanji) $\rightarrow$ 가타카나(katakana) (pyopenjtalk / pykakasi)
    target_kana = to_katakana(text_kanji)
    ...

이렇게 하면 CER 0.045 / F0 $-4\text{Hz}$까지 개선됩니다.

11가지 변형(zero_shot / cross_lingual $\times$ 한자 / 히라가나 / 가타카나 $\times$ 시스템 프롬프트 유무)으로 분류한 표는 GitHub의 cosyvoice-notes.md에 정리해 두었습니다.

참고로 inference_cross_lingual에서 가타카나를 전달하면 CER은 0.000이 되지만, F0가 265Hz로 완전히 여성화됩니다. CER만으로 평가하면 놓칠 수 있으므로, 반드시 F0 비교를 병행해야 합니다. 이 또한 하나의 함정(trap)으로서 기록해 둘 가치가 있습니다.

contains_chinese() 버그는 업스트림(upstream)에 PR을 보낼 가치가 있습니다 (contains_japanese()를 추가하고 frontend.py에서 일본어 경로를 명시적으로 분기).

CosyVoice 2의 타 언어 버그 (de / zh / ko / fr)

반대로 CosyVoice 2는 일본어(JA)에서는 최강이지만, 다른 언어에서는 3가지 종류의 버그를 일으킵니다.

zh 음성에서 여성화 현상을 확인할 수 있습니다:

CER (Character Error Rate)는 0.000으로 완벽해 보이지만, 목소리의 질감이 완전히 다른 사람(성인 여성 영역)으로 변해 있습니다.

CosyVoice 3 / Qwen3-TTS는 동일한 ref (참조)를 사용했을 때 모든 언어에서 목소리 질감이 유지되므로, 이는 CosyVoice 2 고유의 문제입니다. 25Hz 개선 전 모델이라는 점이 다국어 확장 시 발목을 잡은 것으로 추측됩니다.

Qwen3-TTS의 zh(중국어) 열화

3개 모델 중 유일하게 Qwen3-TTS가 무너지는 부분이 zh입니다.

기대 텍스트: 大家好，今天我将为大家介绍一项新功能，感谢您的参与。

Whisper 전사(Transcription): 「大家好,今天我再为大家介绍一款新货的感谢您的参与」

一项新功能 (한 가지 새로운 기능)

이 一款新货 (한 종류의 신상품)로 바뀌어 있습니다.

이는 Whisper의 환각(hallucination)이라기보다, 생성된 음성 측에서 실제로 "新货"라고 발음해 버렸을 가능성이 높습니다. Voice clone 과정에서 원본 화자의 일본식 억양이 섞인 중국어를 재현해 버렸고, Whisper가 이를 다른 단어로 인식했다는 시나리오가 일관성이 있습니다.

이를 구분하기 위해서는 (a) 1.7B-Base 모델로 재실행, (b) 중국어 네이티브 ref로 동일한 텍스트를 clone, (c) 샘플링 변동성 확인 등이 필요하지만, 본 기사의 범위에서는 검증되지 않았습니다.

CosyVoice 2/3는 모두 zh에서 CER 0.000이었으므로, zh 중심의 용도라면 CosyVoice 계열을 사용하는 것이 안전합니다.

유럽어 (de / fr / es) — 3개 모델의 명암

de / fr / es는 3개 모델의 결과가 명확하게 갈립니다.

de를 대표로 3개를 나열합니다:

CosyVoice 2 (CER 0.875, 거의 다른 내용):

CosyVoice 3 (CER 0.125, 대체로 말하지만 accent(억양) 있음):

Qwen3-TTS (CER 0.000, 완벽):

세대 차이를 느낄 수 있는 결과가 나왔습니다.

「목소리 질감 유지」 축 — ElevenLabs에도 없는 Qwen3-TTS의 우위

여기서부터가 본 기사의 핵심입니다. CER과 bigram만 보면 Qwen3-TTS와 ElevenLabs는 동등한 품질로 보이지만, 실제로 들어보면 전혀 다른 것이었습니다.

대표로 en을 나열합니다.

ElevenLabs (06-20):

Qwen3-TTS:

CosyVoice 3 (이 모델 역시 목소리 질감 유지에 가까움):

ElevenLabs의 en은 확실히 자연스러운 영어 네이티브 발음이지만, "이것은 나의 목소리"라는 느낌이 희석되는 방향으로 작동합니다. 반면 Qwen3-TTS / CosyVoice 3는 "일본식 억양이 섞인 영어를 말하는 나 자신"이 그대로 재현되는 감각이며, 듣기에 이질감이 없다(= 원본 화자로서 일관성이 있다)는 또 다른 차원의 자연스러움이 있습니다.

이는 설계 사상의 차이이며, 용도에 따라 구분해서 사용해야 할 기준입니다.

• accent(억양) 없는 깔끔한 영어 나레이션이 필요하다 → ElevenLabs
• "사용자 자신의 목소리"가 강점인 SaaS → Qwen3-TTS / CosyVoice 3

멀티 테넌트 (multi-tenant) SaaS에서 "이건 내 목소리야"라고 느낄 수 있는 경험을 만들고자 한다면, Apache 2.0 라이선스의 셀프 호스트 (self-host) 진영이 더 적합할 가능성이 높습니다. 목소리를 녹음한 본인이 나중에 듣고 "자신"이라고 인식할 수 있는 연속성은 악센트 중립화 (accent neutralization) 과정에서 상실되는 방향으로 움직이기 때문입니다.

이를 정량화하려면 ECAPA-TDNN 코사인 유사도 (cosine similarity) 등으로 목소리 유사도 (voice similarity)를 측정하는 것이 정석이지만, 본 기사에서는 F0 차이를 통해 간접적으로 확인하고 있습니다 (앞서 언급한 F0 표 참조).

Cloud Run GPU에서의 비용 산출

셀프 호스트 (self-host) 모델이므로, 운영 환경에서는 GPU 추론 비용이 직접적으로 발생합니다. Cloud Run L4 GPU (도쿄 리전, Tier 1)를 전제로 산출했습니다. 3개 모델 모두 0.5B~0.6B 클래스이므로 비용은 거의 동일합니다.

초당 단가 (L4 최소 구성)

L4는 최소 vCPU 4 + 메모리 16 GiB 세트가 필수입니다:

요청당 단가 (200자 = 7초 오디오)

L4 상의 RTF (real-time factor)는 공식 H100 값인 0.288에서 추정하여 0.5~0.7입니다. 동시성 (concurrency) 6까지 배치 (batch) 처리가 가능합니다.

API 제공업체와의 요청당 (per-req) 비교

월간 환산 (min-instances=1 고정으로 상시 warm 상태)

고정비 $756/월을 요청 수로 안분합니다:

월 300k req 기준으로는 Fish Audio API를 역전하며, 그 이상부터는 셀프 호스트 (self-host)가 압도적입니다. 비동기 작업 (asynchronous job, concurrency 6 batch)이라면 어떤 규모에서도 셀프 호스트 (self-host)가 더 저렴합니다.

상세 산출 내역은 GitHub의 qwen3-tts-notes.md를 참조해 주세요.

셋업 과정에서 막혔던 포인트

3개 모델에 대해 정리합니다.

CosyVoice 2/3 공통

• venv 이름은 cosyvoice-venv로 설정하세요. cosyvoice라고 하면 대소문자를 구분하지 않는 APFS 환경에서 이후의 git clone CosyVoice (대문자)와 충돌합니다.
• setuptools 82+ 버전에서 pkg_resources가 삭제되어, openai-whisper==20231117의 setup.py를 로드할 수 없습니다. venv 측에 setuptools<76을 설치하고 --no-build-isolation 옵션으로 고정하세요.
• numpy 2.x에서 pyworld 0.3.4가 깨집니다. → numpy==1.26.4로 미리 고정(pin)하세요.
• vLLM / TensorRT 계열의 최적화 플래그는 Mac에서 작동하지 않습니다 (load_vllm=False, load_trt=False, fp16=False).

CosyVoice 3 고유 사항

• <|endofprompt|>

토큰이 필수 (CosyVoice3LM 클래스에서 assert)이며, example.py:76 포맷으로 system prompt를 앞에 배치해야 합니다. 일본어(JA)를 한자(kanji)로 직접 입력하면 앞서 언급한 contains_chinese() 버그로 인해 결과가 무너집니다. 프로덕션(production)에 채택할 경우 반드시 전처리 파이프라인을 넣어야 합니다. Qiita나 note의 기사에서 보이는 "<|endofprompt|>를 tts_text 끝에 붙인다", "한자 그대로 입력한다" 방식은 v2 API를 상정한 방식입니다. v3에서 동일한 방식으로 작성하면 CER(Character Error Rate) 1.364로 완전히 붕괴됩니다 (기사 작성자는 v2를 호출했을 가능성이 높습니다). 샘플링 편차(sampling fluctuation)가 큽니다. 동일한 ref / 동일한 prompt / 동일한 target으로 3회 실행해도 CER이 0.125~0.458 사이에서 변동합니다.

Qwen3-TTS 고유 사항

• 공식 README는 CUDA + FlashAttention 2를 전제로 하지만, Mac MPS에서 동작합니다 (포크(fork) 및 기사를 통해 실증됨).
• dtype=torch.float32가 필수입니다. bfloat16 / float16 사용 시 voice clone 과정에서 NaN logits이 발생합니다 (issue #333).
• attn_implementation="sdpa"를 명시해야 합니다. FlashAttention 2는 CUDA 전용이며 Mac에는 존재하지 않습니다.
• Qwen/Qwen3-TTS-Tokenizer-12Hz는 별도 리포지토리(repo)로 공개되어 있으나, **0.6B-Base / 1.7B-Base 안에 speech_tokenizer/가 포함(bundle)**되어 있으므로 추론에는 불필요합니다 (처음에 다운로드(DL)했다면 낭비였습니다).
• sox: command not found 경고는 무시해도 됩니다.

완전한 동작 환경 설정 절차는 GitHub의 envs/ 디렉토리에 남겨두었습니다.

용도별 현실적인 선택 방법

지정학적 리스크 메모

CosyVoice 2/3 및 Qwen3-TTS는 모두 Alibaba 제품이지만, self-host 방식이므로 가중치(weights)를 로컬로 다운로드하여 로컬 GPU에서 추론하는 한, 생성 데이터가 중국 측으로 유출되지 않습니다. 기술적인 국경 초월 리스크는 사라집니다.

남은 리스크는 다음과 같습니다:

• 가중치 배포처 (HuggingFace / ModelScope)의 규제
• 고객 인지 리스크 ("중국제 AI를 채택하지 않는다"는 조달 기준)
• 미국의 수출 규제로 인해 Qwen / CosyVoice 계열이 향후 Entity List에 포함될 가능성

대책은 **가중치를 사내 artifact registry에 미러링(mirror)**하고, 계약 및 아키텍처 설계 시 "로컬 추론을 통해 중국 서버와 통신하지 않음"을 명시하는 것입니다.

또한 Alibaba Cloud의 DashScope API를 통해 Qwen3-TTS / CosyVoice를 사용하는 경로도 있지만, 이 방식은 음성/텍스트가 중국 본토의 Alibaba 서버를 통과하므로 PIPL(개인정보보호법) 대상이 됩니다. B2B SaaS로서 금융, 관공서, 국방, 통신 분야를 고객으로 포함하는 업종이라면 조달 기준에서 탈락할 가능성이 높으므로, self-host(자체 호스팅)가 유일한 선택지라고 생각합니다.

요약