AI 서비스에 TTS 붙이기
“일단 제일 자연스러워 보이는 걸로?” 했다가 후회하기 전에
AudioStack"여기도 AI 하나 붙이죠"
"여기 텍스트도 그냥 읽어주는 TTS 같은 거 붙이면 좋겠네요."
제품이나 서비스에 AI를 얹을 수 있는 지점은 끝이 없습니다. 챗봇, 추천, 자동 요약, 음성 안내 같은 것들이 대표적이죠. 문제는, 실제로 구현 단계에 들어가면 질문이 훨씬 구체적으로 바뀐다는 점입니다.
어떤 벤더를 쓸 건가
가격은 어느 정도 수준까지 감당할 수 있나
우리 데이터는 어디까지 학습에 쓰이는가
나중에 저작권, IP 분쟁이 나면 누가 어디까지 책임지나
겉으로 보기에 간단히 붙여보자고 생각되지만, 막상 들어가 보면 수년간 유지/운영해야 할 인프라 선택이 되어버립니다. 특히 텍스트 자산이 많은 서비스라면 더 그렇습니다. 뉴스나 미디어 서비스, 긴 글 위주의 콘텐츠 플랫폼, 고객지원이나 FAQ 중심의 서비스, 금융 서비스처럼 약관이나 사용 가이드가 긴 경우가 있죠. 설명, 가이드, 알림, 내레이션처럼 길이가 있는 텍스트를 한 번 음성으로 만들어 두면 서비스 안에서 오랫동안, 반복적으로 재생되기 때문입니다.
"일단 제일 자연스러워 보이는 데로 가죠" 의 함정
TTS 서비스를 쓴다고 가정하면, 실무에서는 보통 이렇게 흘러갑니다.
1. 각 벤더 콘솔에서 텍스트를 붙여넣고
2. 몇 가지 보이스를 들어본 다음
3. 제일 자연스럽게 들리는 엔진을 고릅니다.
짧게 써보는 데모 단계에서는 이 접근이 편합니다. 하지만 실제 서비스에 붙이는 순간, 기준이 달라집니다. 우리 텍스트와 오디오는 어디까지 로그/학습/품질 개선에 쓰이는지, 생성된 오디오의 권리는 누구에게 귀속되는지, 상업적으로 어떻게 쓸 수 있는지, 나중에 IP 이슈가 생기면 벤더가 어디까지 방어해 주고, 어떤 부분은 온전히 우리 책임인지 따져 봐야 합니다.
이런 부분은 콘솔에서 재생 버튼 몇 번 눌러 보는 것만으로는 알 수 없습니다. 결국 누군가는 약관이나 데이터 정책, 가격표를 직접 읽어야 합니다. 보통 그 역할은 서비스 기획자 또는 PO/PM 에게 떨어집니다.
그래서 문서와 약관을 끝까지 읽어봤습니다
저는 이런 배경에서, TTS 를 실제 서비스에 붙이기 전에 주요 벤더 다섯 곳을 대상으로 공식 문서, 데이터/저작권/면책 관련 정책, 가격 구조를 한 번씩 다 읽어보면서 제 기준으로 정리했습니다.
Google Cloud TTS
Amazon Polly
Microsoft Azure TTS
OpenAI TTS
ElevenLabs
이 글은 그 정리 내용을 기획자의 관점으로 정리하는 글입니다. 콘솔에서 몇줄 써보는 수준이 아니라, 대량 배치 생성과 장기 운영을 전제해 봅니다. 각 벤더가 제공하는 기본 보이스 프리셋만 사용하고, 커스텀 보이스나 브랜드 보이스, 음성 클로닝 같은 것들은 제외합니다. 어느 엔진이 가장 사람 같냐는 순위 매기기도 제외하고, 프로토타입용 초단기 사용 케이스도 제외합니다.
관심 있는 분들께 도움이 될 만한 부분은
1. 어떤 시나리오를 전제로 보고
2. 어떤 축으로 벤더를 비교하면 좋은지
3. POC를 어떻게 설계하면 덜 후회하는지
세가지 정도로 꼽아보고자 합니다. 제가 정리한 것을 바탕으로 생성형 AI의 도움을 받아 추가 정보를 얻어보시는 것도 좋겠어요.
어떤 시나리오를 전제로 봤는가
TTS를 쓰는 서비스는 많지만, 저는 일단 이런 상황을 상정하고 프레임을 잡았습니다.
1. 입력 텍스트
문단, 문장 단위의 텍스트 블록
평균 길이가 어느 정도 일정한 콘텐츠 (예: 설명, 내레이션, 안내문 등)
별도의 전처리는 최소화하고, 최대한 원문 그대로 음성화
2. 출력
한 번 만들어 두면 서비스 안에서 오래 재생될 수 있는 음성 자산
특정 화면이나 기능에 붙어서 반복적으로 호출되는 형태
3. 사용 방식
콘솔에서 몇 줄 테스트하는 수준이 아니라,
대량 배치 생성과 반복 사용이 기본 전제
이렇게 전제를 고정하고 보니, 음질을 체감하는 리뷰보다는 데이터/저작권/면책 구조, 비용, 운영성을 같이 봐야 한다는 결론이 자연스럽게 나왔습니다.
서비스 기획자의 시선으로 잡은 비교 프레임
벤더별 문서와 약관을 뒤져보면서, 저는 결국 아래 세 가지 질문만 계속 붙들고 보게 되더군요.
Q1. 우리 텍스트/오디오가 모델 학습에 쓰이지 않게 통제할 수 있는가
기본값이 모델 학습에 사용하지 않는 것인지
아니면 콘솔이나 조직 단위에서 직접 opt-out 설정을 해야 하는 구조인지
텍스트, 오디오가 품질 개선, 로그, 모니터링 목적으로 어느 범위까지 사용되는지
보관 기간, 삭제 정책이 문서로 어느 정도 명확하게 나와 있는지
장기적으로 보면, 우리가 넣은 텍스트와 생성된 오디오가 어디까지 흘러가는지는 결국 서비스 리스크와도 연결됩니다. AI 기술을 활용한 많은 기업이 소송에 걸려 있죠. 그래서 저는 이 부분을 첫 번째 축으로 두고 비교했습니다.
Q2. IP(지식재산권) 관련해서 누가 어디까지 책임지는가
메이저 클라우드 벤더들의 약관을 보면 크게 아래 두 가지가 나뉩니다.
1. 서비스 기술 자체
TTS 엔진이 제3자의 특허, 저작권, 상표권을 침해했다는 청구
이 부분은 대부분의 메이저 클라우드가 자기 서비스에 대해서는 방어, 보상(IP Indemnity)를 제공합니다.
2. 우리가 넣은 콘텐츠와 사용 방식
어떤 텍스트를 넣었는지, 그 텍스트를 어디에, 어떻게 재생했는지
이 부분은 거의 예외 없이 고객 책임이고, 고객이 벤더를 면책하는 구조가 약관에 들어가 있습니다.
문장 표현이나 상세 조건은 조금씩 다르지만, 결국 어디까지가 기술 책임이고, 어디부터가 콘텐츠 책임인지를 한 번 정리해놓고 보니 각 벤더가 좀 더 분명하게 보였습니다.
Q3. 커스텀 보이스/클로닝은 ‘지금’ 필요한 기능인가
이번에 봤던 다섯 벤더는 정도의 차이만 있을 뿐, 어떤 식으로든 커스텀 보이스나 음성 클로닝에 발을 담그고 있습니다. 문제는 이게 단순 기능을 넘어 원 음성 제공자의 동의나 라이선스 구조, 사칭/표절/허위 콘텐츠에 대한 리스크와 바로 연결된다는 점입니다.
그래서 이번 비교에서는 아예 지금은 기본 제공 보이스만 쓴다고 선을 긋고, 커스텀 보이스는 정책이나 계약을 따로 준비했을 때 다시 검토할 기능으로 분리했습니다. 대신, 각 벤더가 이 영역을 얼마나 엄격하게 관리하는지 정도만 메모 수준으로 체크했습니다.
이 세 가지 질문을 정리해놓고 나니, 단순히 어디가 더 자연스럽냐는 비교에서 벗어나 장기적으로 같이 갈 수 있는 조합이 어디인가를 보는 데 집중할 수 있었습니다.
TTS 벤더별 한 줄 요약
이번에 문서를 들춰본 벤더는 다섯 곳입니다.
Google Cloud TTS
Amazon Polly
Microsoft Azure TTS
OpenAI TTS
ElevenLabs
이렇게 각각을 서비스 기획자의 관점에서 한 줄로만 정리하자면, 저는 대략 이렇게 느꼈습니다.
1. Google Cloud TTS
가격, 품질, 정책이 가장 기본값에 가까운 옵션.
대량으로 돌리고, 장기간 운영해야 할 때 기본 축으로 보기 좋은 서비스.
2. Amazon Polly
이미 AWS를 쓰고 있다면 인프라 통합이 깔끔한 선택지.
다만 데이터 학습 opt-out 설정을 제대로 해두지 않으면 마음이 편치 않은 구조.
3. Microsoft Azure TTS
SSML, 발음 사전, 스타일/감정 제어 등 세밀하게 프로소디를 튜닝하고 싶은 팀에게 잘 맞는 엔진.
Custom Neural Voice까지 쓸지 여부에 따라 법무 난이도가 달라짐.
4. OpenAI TTS
표준 SSML 제어보다는 기본 운율이나 감정 표현과 스트리밍에 강점이 있는 쪽.
문장부호나 줄바꿈만 잘 써도 꽤 자연스럽게 읽어줘서, 빨리 만들되 퀄리티는 일정 이상을 원할 때 후보가 될 수 있습니다.
5. ElevenLabs
클로닝, 브랜디드 보이스에 특화된 서비스.
그만큼 사용자가 가져가야 할 책임이 더 직접적으로 느껴지는 구조
메인 기능보다는 특정 캠페인/브랜딩용 시나리오에서 보는 게 현실적이라고 판단했습니다.
POC를 설계한다면
비슷한 상황에서 다시 TTS를 도입해야 한다면, 저는 아마 이런 식으로 POC(개념 검증)를 설계할 것 같습니다.
1. 샘플 텍스트 구성
실제 서비스에서 나올 법한 텍스트 블록 100개 정도를
길이, 톤, 문장 구조가 다양한 문구로 구성합니다.
별도의 SSML 없이 그냥 텍스트만 넣었을 때의 기준도 함께 체크합니다.
2. 벤더별 동일한 텍스트 생성
OpenAI, Google, AWS, Azure 기본 TTS 엔진으로 각각 1세트씩 생성
ElevenLabs는 필요 시 브랜딩/홍보용 시나리오에 한정해 별도로 테스트
3. 평가 관점
음질, 자연스러움 (주관적 판단)
서비스 맥락에 어울리는 톤인지 (너무 과장되거나, 기계적이지 않은지)
남/여, 차분함/활기참 등 몇 가지 역할 프리셋으로 묶기가 얼마나 쉬운지
API 사용성, 배치 처리 난이도, 에러 핸들링
콘솔/설정 화면에서 데이터 사용, 로그, 학습 관련 옵션을 어디까지 제어할 수 있는지
4. 비용 시뮬레이션
월 5M chars, 20M chars 정도 두 구간을 기준으로
Neural 계열 기준 단가를 비교해 보고,
운영 환경에 가장 가까운 시나리오에서 연 단위 비용을 러프하게 계산해 봅니다.
실제 가격표를 비교해 보면 Neural 계열의 단가는 벤더마다 조금씩 다르지만 극단적으로 벌어지는 수준은 아닙니다. 결국 데이터 정책, IP 구조, 운영 편의성까지 같이 놓고 봐야 현실적인 선택이 가능하다는 생각이 들었습니다.
지금 시점에서의 정리
이렇게 다섯 벤더를 훑어보면서 제가 정리한 결론은 대략 이렇습니다.
1. IP 책임 구조는 메이저 클라우드끼리는 크게 다르지 않다.
서비스 기술에 대한 IP 분쟁은 벤더가 책임지고,
우리가 넣는 콘텐츠와 사용 방식에서 생기는 문제는 우리 책임이라는 큰 틀은 똑같습니다.
2. 실제 차이는 데이터 학습 기본값과 커스텀 보이스 정책에서 더 잘 드러난다.
기본값부터 학습 비사용인 곳이 있고,
조직/콘솔 단에서 반드시 opt-out을 걸어야 안심할 수 있는 구조도 있습니다.
커스텀 보이스/클로닝은 편하다고 바로 켜기보다는,
별도 정책과 계약을 준비해 놓고 접근해야 할 영역에 가깝습니다.
3. 비용은 한 군데 몰아넣기보다, 용도에 따라 조합하는 쪽이 현실적이다.
대량 배치, 내부용에는 가격 대비 무난한 Standard/Neural 계열
외부 노출이 큰 콘텐츠에는 표현력이 좋은 엔진을 섞는 식으로 조합을 짜는 게 더 합리적입니다.
agile42마치며
이 글은 어디까지나.. 텍스트가 많은 서비스를 만들면서 TTS를 검토해야 했던 서비스 기획자가 주요 벤더 문서를 직접 읽어보며 정리한 글입니다. 비슷한 고민을 하고 계신 분들이 있다면 어떤 축으로 벤더를 비교할지, POC를 어떻게 설계할지, 커스텀 보이스나 클로닝은 어느 타이밍에 꺼낼지 생각을 정리하시는 데 하나의 레퍼런스로 써보셔도 괜찮습니다.
이런 종류의 텍스트 자산이 많은 서비스나 AI/TTS 도입을 고민하시는 분들의 입장에서 한 가지 덧붙이고 싶은 이야기가 있습니다. 이런 판단은 단순히 어느 벤더가 싸고, 음질이 좋냐는 문제는 아닙니다.
데이터가 어디까지 학습에 쓰이는지
나중에 저작권, IP 이슈가 생기면 누가 어디까지 책임지는지
트래픽이 늘었을 때 비용 곡선이 어떻게 휘는지
우리 서비스의 UX 흐름 안에서 이 기능이 정말 의미가 있는지
를 같이 봐야 하는 문제입니다.
이걸 한번에 다루려면 기술, 법무, 비즈니스, 사용자 경험을 한 페이지이 올려놓고 조정하는 사람이 필요합니다. 바로 그 역할이 서비스 기획자 또는 PO/PM입니다.
개발자는 "어떻게 구현할 수 있는지", 디자이너는 "어떻게 보여줄지/듣게 할지" 에 강하다면,
기획자는 "무엇을, 왜, 어느 수준까지 할 것인지" 를 정의하는 역할을 맡습니다.
AI 기능은 한 번 붙이면 몇년동안 유지, 운영되면서 데이터와 비용, 리스크를 계속 만들어 냅니다.
초기에 기준과 프레임을 잡는 사람이 있느냐 없느냐에 따라
나중에 손해보는 비용과 시간, 그리고 "이거 왜 이렇게 해놨지?" 하는 후회가 크게 달라집니다.
그래서 이런 종류의 서비스를 만들고자 하는 분이라면,
우리 서비스에 맞는 기준을 잘 생각해 보시거나, 기준을 같이 만들 사람이 필요하다고 보시는게 좋겠습니다.
기준을 한 번 잘 만들어 두면, 이후에 어떤 AI 기능을 더 붙이더라도 훨씬 덜 흔들리는 의사결정을 하실 수 있게 됩니다.
