로컬 TTS 엔진 선택 가이드: Piper, Coqui TTS, Web Speech API, Riva, Bark를 근거 중심으로 비교해요

로컬 TTS는 텍스트를 기기 안이나 애플리케이션 내부에서 음성으로 바꾸는 방식이에요. 최근 개발자 관심이 커진 배경에는 두 가지 흐름이 함께 있어요. 첫째, Piper처럼 CPU 중심의 소형 로컬 TTS 엔진이 공개 저장소에서 빠르게 확산됐고[125], 둘째, llama.cpp가 대중화한 '소형 모델+로컬 추론+쉬운 임베딩' 패턴이 음성 스택 사고방식에도 영향을 줬다고 해석할 수 있어요[132].

다만 여기서 중요한 점은 '로컬이 항상 더 낫다'고 단정하면 안 된다는 거예요. 제공된 출처는 비용 절감, 예산 예측, 개인정보 개선, 지연시간 우위 같은 운영 효과를 직접 수치로 증명하지는 않아요. 그래서 이 글은 성능 우열을 단정하기보다, 각 도구가 공식적으로 무엇을 약속하는지와 어떤 배포 패턴에 맞는지를 중심으로 설명해요.

Piper는 이번 비교군 가운데 용도가 가장 또렷하게 정의된 편이에요. 공식 저장소는 Piper를 로컬 사용을 위해 설계된 빠르고 가벼운 neural TTS로 설명하고, CPU에서의 low-latency inference와 small model sizes를 강조해요[125]. 여기에 ONNX 기반 추론과 미리 빌드된 voice model 문서가 더해져 애플리케이션에 내장하기 쉬운 방향성을 보여줘요[126].

이 설명만으로도 Piper가 잘 맞는 상황은 꽤 선명해져요. 예를 들어 네트워크 연결이 없어도 돌아가야 하는 데스크톱 앱, 키오스크, 로컬 에이전트, Node.js 기반 보조도구 같은 경우예요. 다만 '가장 단순하다'거나 '가장 자주 선택된다'는 평가는 이번 출처만으로는 검증되지 않으므로, 여기서는 CPU 지향성과 ONNX 임베딩 친화성까지만 사실로 받아들이는 게 정확해요.

Coqui TTS에 대해 이번 출처가 직접 뒷받침하는 사실은 세 가지예요. Mozilla가 공개한 오픈소스 TTS 프로젝트라는 점, multiple languages와 voices를 지원한다는 점, 그리고 개발자들 사이에서 local/offline TTS option으로 자주 언급된다는 점이에요[124]. 이 정보만으로도 Coqui TTS는 '언어와 음성 선택 폭이 중요한 로컬 TTS 후보'로 분류할 수 있어요.

반대로 주의할 점도 있어요. Coqui TTS를 Piper와 함께 'CPU 중심 엔진'으로 묶거나, 파이썬 생태계 중심, 학습·확장성 우위, 배포 복잡도 같은 평가를 덧붙이면 이번 제공 사실을 넘어서는 해석이 돼요. 그래서 편집 기준에 맞추려면 Coqui는 '다국어·다중 음성·오프라인 옵션'이라는 검증된 축으로만 설명하는 편이 안전해요.

Web Speech API는 자체 TTS 모델 이름이 아니라 브라우저 표준 기능이에요. MDN 문서는 웹앱이 별도 TTS 엔진을 번들하지 않고도 speech synthesis를 직접 사용할 수 있다고 설명해요[130]. 즉, 설치 없이 웹 페이지에서 바로 음성 합성을 붙이려는 팀에게는 매우 실용적인 시작점이 될 수 있어요.

다만 플랫폼별 음질 차이, 음색 일관성, 오프라인 일관성, 브랜드 보이스 고정 난이도 같은 평가는 이번 출처에 직접 적혀 있지 않아요. 일반적인 현업 경험으로는 그런 이슈가 논의되곤 하지만, 기사에서는 '환경에 따라 합성 경험이 달라질 수 있으므로 사전 테스트가 필요할 수 있다' 정도로 완곡하게 쓰는 게 더 정확해요. 출처 기반으로 확실하게 말할 수 있는 건 '브라우저에서 별도 엔진 번들 없이 사용 가능하다'는 점이에요[130].

NVIDIA Riva는 비교 대상 중 성격이 가장 다층적이에요. 출처에 따르면 Riva는 TTS뿐 아니라 ASR과 NLU까지 포함하는 speech AI SDK이고, production deployment, on-premise, edge use case를 지향해요[128]. 즉, 단순한 음성 합성 엔진 하나를 찾는 경우보다, 음성 입출력 전체 파이프라인을 한 벤더 스택 안에서 다루려는 조직에 더 가깝다고 볼 수 있어요.

이 정의는 도입 질문도 바꿔줘요. 'TTS가 되느냐'보다 'ASR과 NLU까지 같은 스택으로 묶을 계획이 있느냐'가 더 중요해져요. 반대로 개인 개발자나 소규모 팀이 브라우저 앱 하나에 음성만 얹으려는 상황이라면, Riva의 생산용 범위는 과할 수 있어요. 물론 그 판단 자체는 조직 규모와 운영 목표에 따라 달라지므로, 기사에서는 범용 우열이 아니라 적합한 범주 차이로 설명하는 게 맞아요.

Bark에 대해 이번 출처가 확인해 주는 내용은 비교적 제한적이에요. Suno AI의 Bark는 음성을 포함한 text-to-audio 출력을 생성하는 generative audio model이며, 더 표현력 있는 local audio generation workflow에 대한 관심을 키웠다고 돼 있어요[129]. 이 설명만 보면 Bark는 전통적인 낭독형 TTS보다 생성형 오디오 실험에 가까운 도구로 읽는 편이 자연스러워요.

하지만 '경량성이 떨어진다', '추론 비용이 크다', '제어 가능성이 낮다' 같은 평가는 이번 제공 사실로는 바로 입증되지 않아요. 그래서 Bark를 소개할 때는 '정교한 표현 실험에 관심이 있다면 검토할 수 있지만, 낭독형 TTS와 동일 기준으로 단정 비교하기는 어렵다' 정도가 안전해요. 편집자의 지적처럼, 여기서는 모델 성격 차이만 분명히 하는 편이 더 객관적이에요.

Whisper는 로컬 음성 스택 논의에서 자주 같이 언급되지만 본질적으로는 TTS가 아니에요. OpenAI의 Whisper는 2022년에 공개된 오픈소스 모델이고, speech recognition용이라는 점이 명시돼 있어요[127]. 따라서 '말하기'를 담당하는 Piper·Coqui·Web Speech API와 '듣기'를 담당하는 Whisper를 한 줄 추천으로 섞으면 독자가 혼동할 수 있어요.

실무적으로는 Whisper가 오히려 좋은 보완재가 될 수 있어요. 예를 들어 음성 비서나 음성 메모 도구는 ASR과 TTS를 모두 필요로 하니까요. 다만 기사 문장에서는 'Whisper는 같은 로컬 음성 AI 스택에서 함께 검토될 수 있지만, 기능은 ASR'이라고 분리 표기하는 게 가장 정확해요[127].

ONNX Runtime은 web과 Node.js를 위한 JavaScript 지원을 제공해요[131]. 이 사실은 ONNX 기반 로컬 AI 모델, 특히 Piper 같은 TTS 엔진이 브라우저와 앱 스택에 더 쉽게 통합될 수 있는 이유 중 하나로 연결돼요[126][131]. 여기에 WebAssembly System Interface, 즉 WASI와 WebAssembly toolchain이 native AI runtime을 browser-adjacent와 desktop app deployment로 패키징하는 데 점점 더 쓰인다는 흐름도 확인돼요[133].

다만 이것을 '반드시 브라우저 로컬 TTS가 쉬워진다'고 단정할 수는 없어요. 더 정확한 표현은 'ONNX Runtime JS 지원과 WASM/WASI 확산은 로컬 음성 엔진 배포를 쉽게 만드는 방향으로 해석할 수 있다'예요[131][133]. 특히 llama.cpp가 보여준 소비자 하드웨어용 효율 추론 패턴이 이 사고방식에 영향을 줬다는 점도, 엄밀히는 생태계 해석으로 제시하는 편이 적절해요[132].

이 질문 방식의 장점은 과장된 추천 문구를 피할 수 있다는 데 있어요. '가장 현실적', '가장 쉬운', '정답' 같은 표현 대신, 어떤 제약에서 어떤 도구가 자연스럽게 떠오르는지를 보여줄 수 있어요. 독자 입장에서도 스택 전체를 갈아엎지 않고 2개 후보만 추리는 데 도움이 돼요.

기사나 기획 문서 단계에서 가장 실용적인 다음 행동은 1주일짜리 평가표를 만드는 거예요. 예를 들어 후보를 Piper 1개, Coqui TTS 1개, Web Speech API 1개로 좁히고[124][125][130], 같은 문장 20개를 읽혀서 필요한 기능이 실제로 충족되는지 확인하는 방식이에요. 여기서도 성능 우열을 일반화하기보다, 내 서비스 요구사항에 맞는지 여부를 기록하는 게 핵심이에요.

만약 브라우저 제품이라면 Web Speech API로 먼저 사용자 반응을 보고[130], 이후 더 강한 제어가 필요할 때 ONNX 기반 로컬 엔진으로 넘어가는 2단계 전략도 생각해볼 수 있어요[126][131]. 반대로 처음부터 ASR과 TTS를 모두 묶어야 한다면 Whisper와 TTS 조합 또는 Riva 같은 통합 SDK 접근이 더 자연스러울 수 있어요[127][128]. 중요한 건 특정 도구를 '최고'라고 미리 정하기보다, 제품의 형태와 배포 경로에 맞춰 실험 순서를 짜는 일이에요.