콜센터 TTS API 비교 2026 | 실시간 응답·스트리밍·온프레미스 6종 정밀 분석

콜센터에 TTS를 붙일 때 가장 먼저 찾아보는 것은 대개 음질 점수입니다. 그런데 실제 통화에 올려 보면 문제는 다른 데서 나옵니다. 고객이 말을 마쳤는데 대답이 늦게 시작되고, 긴 안내는 끝까지 만든 뒤에야 재생되고, 전화망을 거치며 소리가 뭉개지고, 전화번호와 금액을 엉뚱하게 읽습니다. 조용한 방에서 들은 음질과 전화기로 들은 응대는 서로 다른 시험입니다.

결론부터 말씀드리겠습니다. 콜센터 TTS는 첫 음성이 나오기까지의 시간, 받는 대로 재생하는 스트리밍, 8kHz 전화망 포맷, 숫자·고유명사 발음, 설치형(폐쇄망) 가능 여부, 장애 대응 체계로 고르는 것이 맞습니다. 음질은 이 조건을 통과한 후보끼리 비교할 때 보는 기준입니다.

이 글은 휴멜로 DIVE, Google Cloud TTS, Amazon Polly, Azure Speech, ElevenLabs, 네이버 CLOVA Voice 6종을 2026년 11월 각 사 공개 문서 기준으로 비교합니다. 네트워크와 문장 길이에 따라 크게 달라지는 지연 시간은 공개 문서에 없는 숫자를 적지 않았고, 대신 우리 환경에서 직접 재는 방법을 정리했습니다.

콜센터 TTS는 일반 TTS와 무엇이 다를까

콘텐츠용 TTS는 음성 파일을 미리 만들어 두고 재생하므로 몇 초가 더 걸려도 문제가 되지 않습니다. 콜센터 TTS는 통화 중에 그때그때 문장을 만들어 바로 들려줘야 합니다. AI 콜봇이라면 고객의 말을 알아듣고(음성 인식), 답을 정하고(언어 모델), 소리로 바꾸는(TTS) 단계를 차례로 거치므로 한 단계의 지연이 그대로 통화 속 침묵이 됩니다.

전화망도 다릅니다. 콜센터 교환기(PBX)와 SIP 구간은 μ-law·A-law(G.711) 같은 8kHz 전화망 포맷을 많이 씁니다. 48kHz로 만든 음성을 다시 8kHz로 바꾸는 과정이 끼면 그만큼 처리 시간이 늘고, 바꾸는 방식에 따라 소리가 거칠어집니다. 처음부터 전화망 포맷으로 내보낼 수 있는지가 중요한 이유입니다.

원칙 콜센터 TTS는 'MOS 4.5와 4.6'의 차이가 아니라 '첫 음성이 언제 나오고, 전화기로 들었을 때 또렷한가'로 고릅니다.

콜센터 TTS API 6종 비교 (2026년 11월 공개 문서 기준)

항목	휴멜로 DIVE	Google Cloud TTS	Amazon Polly	Azure Speech	ElevenLabs	네이버 CLOVA Voice
스트리밍 응답	HTTP 청크 스트리밍·WebSocket(승인된 기업 계정)	양방향 스트리밍(Chirp 3: HD 음성, 미리보기)	합성 음성을 스트림으로 응답(문장은 한 번에 전송)	Speech SDK로 합성되는 대로 수신	HTTP 스트리밍·WebSocket 입력 스트리밍	완성된 MP3·WAV 파일로 응답
전화망 8kHz 포맷	μ-law·A-law·PCM 8kHz	μ-law·A-law	μ-law·A-law 8kHz	μ-law·A-law 8kHz	μ-law 8kHz	WAV 샘플레이트 지정
발음 교정	커스텀 단어장	발음 지정·SSML(스트리밍 요청은 SSML 미지원)	사용자 렉시콘·SSML	SSML·사용자 렉시콘	발음 사전	속도·음높이·감정 조절
설치형(온프레미스)	GPU·CPU 서버 설치, 인터넷 없는 폐쇄망 가능	클라우드 API	AWS 클라우드 서비스	신경망 TTS 컨테이너(오프라인 사용은 승인·약정 필요)	클라우드 API	클라우드 API(공공·금융 전용 클라우드 제공)
목소리 복제	2초 음성으로 30초 이내(기업 고객)	Custom Voice(사전 승인)	Brand Voice(AWS 팀과 별도 프로젝트)	Custom Neural Voice(사전 승인)	Instant·Professional Voice Clone	정해진 화자 선택(공개 API 기준)

다른 회사 항목은 각 사 공개 문서를 기준으로 정리했습니다. Google 스트리밍 합성·Chirp 3: HD, Amazon SynthesizeSpeech·Polly 기능, Microsoft Speech 컨테이너, ElevenLabs WebSocket, NAVER Cloud CLOVA Voice 문서입니다. 요금제·지역·사전 승인 여부에 따라 달라지니 도입 전에 최신 문서로 다시 확인하세요.

표에서 보듯 스트리밍과 전화망 포맷은 대부분 지원하지만 조건이 다릅니다. Google의 스트리밍은 Chirp 3: HD 음성에서만 쓰는 미리보기 기능이고, Amazon Polly는 합성한 음성을 스트림으로 돌려주지만 문장은 한 번에 보내야 합니다. CLOVA Voice 공개 API는 완성된 파일로 응답합니다. 설치형까지 필요하면 선택지가 더 좁아져, 이번에 확인한 공개 문서 기준으로는 휴멜로 DIVE와 Azure 컨테이너가 남습니다.

도입 전에 확인할 7가지 기준

기준	왜 중요한가	이렇게 확인하세요	우리 목표·측정값
① 첫 음성까지 시간	음성 인식·답변 생성 뒤에 TTS가 붙어 지연이 쌓인다	실제 통화 경로에서 같은 문장을 20회 이상, 첫 오디오 조각 도착 시간	____ ms
② 스트리밍 합성	긴 안내도 첫 문장부터 바로 들려야 한다	조각이 오는 대로 재생되는지, 문장 이음새가 자연스러운지	____
③ 전화망 포맷	8kHz 변환 과정에서 지연과 음질 손실이 생긴다	μ-law·A-law 8kHz를 바로 내보내는지	____
④ 재합성 일관성	같은 안내가 매번 다르게 들리면 고객이 불안해한다	같은 문장을 10회 합성해 억양·속도 비교	____
⑤ 숫자·고유명사 발음	전화번호·금액·일시·상품명이 가장 자주 나온다	단어장 적용 전후로 잘못 읽은 목록 비교	오독 ____건
⑥ 설치형·폐쇄망	금융·공공·통신은 데이터 외부 전송이 막혀 있다	오프라인 설치, 서버 사양(GPU·CPU), 설치 주체	____
⑦ 장애 대응·유지보수	통화 채널은 멈추면 바로 고객이 기다린다	연락 경로·응답 시간·대체 경로를 계약서에 기재	____

재합성 일관성은 놓치기 쉬운 기준입니다. 생성형 TTS는 같은 문장도 매번 조금씩 다르게 읽을 수 있어, "잠시만 기다려 주세요" 같은 안내가 통화마다 다르게 들리면 고객은 시스템이 불안정하다고 느낍니다. 자주 반복되는 안내 멘트는 한 번 만든 음성을 다시 쓰면(캐싱) 소리도 같아지고 지연도 줄어듭니다. (관련 글: 「TTS 레이턴시 줄이는 캐싱 전략 | AI 보이스 응답 속도 최적화」)

숫자와 고유명사는 콜센터에서 가장 자주 틀리는 영역입니다. 전화번호, 주문번호, 금액, 날짜와 시각, 상품명과 지점명이 거의 모든 통화에 나오므로, 실제 상담 기록에서 자주 나오는 표현 100개를 골라 후보마다 읽혀 보세요. 잘못 읽은 단어는 단어장(발음 사전)으로 읽는 방식을 고정할 수 있는지가 운영 부담을 크게 가릅니다.

설치형은 처음부터 후보를 가르는 조건입니다. 금융·공공·통신 콜센터는 통화 내용과 고객 정보가 밖으로 나가면 안 되는 경우가 많아, 클라우드 전용 서비스는 성능과 관계없이 후보에서 빠집니다. 인터넷이 없는 환경에 설치할 수 있는지, 서버 사양은 무엇인지, 설치와 장애 대응을 누가 맡는지를 먼저 확인하세요. (관련 글: 「온프레미스 AICC 보안·컴플라이언스 가이드 2026 | 금융·공공 폐쇄망 도입 필수 체크리스트」)

장애 대응은 계약 전에 문서로 남겨야 합니다. 콜센터는 분 단위로 고객이 기다리는 채널이라, 장애가 났을 때 누구에게 어떤 경로로 연락하고 몇 분 안에 답을 받는지, TTS가 멈추면 녹음 멘트나 상담원 연결로 넘기는 대체 경로가 있는지를 정해 두세요.

응답 지연은 이렇게 재 보세요

10개 언어를 비교한 연구에서, 사람끼리 대화할 때 한 사람이 말을 마치고 다음 사람이 말을 시작하기까지 가장 흔한 틈은 0~0.2초였습니다(Stivers 외, 2009, PNAS). AI 콜봇은 여러 단계를 거쳐 사람보다 느릴 수밖에 없으므로, 고객이 느끼는 침묵을 줄이려면 TTS 단계에서 첫 음성이 나오는 시간을 따로 재고 관리해야 합니다.

• 같은 문장으로 잽니다. 실제 안내와 비슷한 길이(예: 30자 안팎)의 문장을 정해 모든 후보에 똑같이 보냅니다.
• 실제 경로에서 잽니다. 콜봇 서버나 콜센터 서버에서 API까지, 운영과 같은 네트워크로 요청합니다.
• 첫 조각을 기준으로 잽니다. 요청을 보낸 시점부터 첫 오디오 조각이 도착한 시점까지(TTFB)를 보고, 전체 합성이 끝난 시간과 구분합니다.
• 여러 번 잽니다. 20회 이상 재서 중앙값과 느린 쪽(상위 5%)을 함께 보고, 통화가 몰리는 시간대에도 다시 잽니다.
• 전화기로 들어 봅니다. 8kHz μ-law로 받은 음성을 실제 전화 회선으로 들어 보며 또렷함과 숫자 발음을 확인합니다.

휴멜로 DIVE는 30자 문장 기준 0.3초 이하를 공개 기준으로 제시하지만, 이 값도 실제 네트워크와 동시 통화 수에 따라 달라지므로 같은 방법으로 다시 재 보시길 권합니다.

시나리오별 추천

시나리오	먼저 볼 조건	추천 구성
금융권 AICC(폐쇄망)	데이터 외부 전송 금지, 오프라인 설치	휴멜로 DIVE·DIVE Flex 설치형(GPU 서버)
공공기관 ARS·안내 방송	폐쇄망, 정해진 안내 문장	휴멜로 DIVE 설치형(용도에 맞춰 GPU·CPU 서버)
통신사·대형 콜센터 콜봇	동시 통화 수, PBX 연동, 스트리밍	휴멜로 DIVE Flex 설치형 + PBX·로드 밸런싱 구성, 또는 DIVE 스트리밍 API
중소·스타트업 콜봇(클라우드)	빠른 연동, 8kHz 포맷	휴멜로 DIVE API·WebSocket
3개 이상 언어를 쓰는 다국어 콜봇	지원 언어 수	다국어 폭이 넓은 클라우드 TTS(예: Azure Speech·Google Cloud TTS) + 한국어·영어 구간은 휴멜로 DIVE

휴멜로 DIVE로 콜센터 TTS를 구성하면

휴멜로 DIVE는 30자 문장 기준 0.3초 이하로 음성을 만드는 음성합성 엔진입니다. 승인된 기업 계정에는 HTTP 청크 스트리밍과 WebSocket을 열어 드리며, WebSocket은 한 연결에서 합성을 마치면 다음 요청을 이어 받습니다. 출력은 μ-law·A-law·PCM 8kHz 같은 전화망 포맷부터 48kHz까지 고를 수 있어, 교환기로 보내는 음성과 앱·웹 상담 화면의 음성을 한 엔진으로 만듭니다.

자주 틀리는 전화번호 읽기나 상품명은 커스텀 단어장으로 읽는 방식을 고정하고, 속도(0.5~2배)·높낮이·음량은 요청마다 조절합니다. 문장을 배열로 보내면 문장 사이 무음을 0.1~2초로 정할 수 있어 안내 멘트의 호흡을 맞추기 쉽습니다. 기업 고객은 2초 음성으로 30초 안에 브랜드 목소리를 복제할 수 있고, 한국어 화자의 목소리로 영어를, 영어 화자의 목소리로 한국어를 말하게 할 수 있습니다. DIVE 나나 목소리는 이용자가 모델 이름을 모른 채 더 자연스러운 쪽을 고르는 한국어 TTS 아레나에서 전체 부문 1위입니다(2026년 11월 3일 확인, ELO 1,720). (관련 글: 「휴멜로 'DIVE 나나', 한국어 TTS 아레나 1위…OpenAI·구글 등 주요 모델과 공개 평가」)

설치형이 필요하면 DIVE를 고객사 GPU·CPU 서버에 둘 수 있고, 상담·통화처럼 주고받는 대화에는 앞선 대화를 보고 말투와 속도, 감정을 고르는 대화형 엔진 DIVE Flex를 설치형으로 제공합니다. 인터넷 연결이 없는 폐쇄망에도 설치하며, 설치는 휴멜로가 직접 하고 필요하면 PBX 서버와 로드 밸런싱까지 함께 구성합니다. 유지보수는 별도 계약으로 범위를 정하고, PoC로 먼저 검증할 수 있습니다.

DIVE 목소리는 PROSODY 콘솔에서 바로 들어 볼 수 있습니다. DIVE Flex와 콜센터 PoC는 도입 문의로 신청해 주세요.

결론적으로, 콜센터 TTS는 음질 순위표보다 실제 통화 경로에서 잰 첫 음성 시간, 받는 대로 재생하는 스트리밍, 전화망 포맷, 숫자 발음, 설치형 여부, 장애 대응 체계로 고르는 것이 맞습니다. 7가지 기준표의 빈칸을 우리 콜센터의 목표값으로 채운 뒤 같은 문장과 같은 네트워크로 후보를 재 보면, 어떤 엔진이 맞는지 숫자로 드러납니다.