음성 상담의 첫 안내가 늦거나, 예약 내용을 잘못 받아 적거나, 회의록에서 제품명을 반복해 틀리는 문제는 모델 비교표의 전체 순위로 설명하기 어렵습니다. 사용자가 기다리는 순간, 틀리면 업무가 멈추는 단어, 월별 사용량이 늘어나는 방식이 서비스마다 다르기 때문입니다.
TTS와 STT 모델을 고를 때 공개 벤치마크는 후보를 줄이는 데 유용합니다. 그러나 최종 선택은 서비스의 음성 흐름을 재현한 시험으로 내려야 합니다. 핵심은 “가장 정확한 모델”을 찾는 일이 아니라, 각 업무 구간에서 허용할 수 있는 지연, 오류, 비용, 장애 범위를 먼저 정하는 일입니다.
실시간 대화와 사후 처리를 같은 기준으로 묶지 않는다
TTS(Text-to-Speech)는 텍스트를 음성으로 만드는 기능이고, STT(Speech-to-Text)는 음성을 텍스트로 바꾸는 기능입니다. 둘 다 음성 AI이지만 사용자가 문제를 느끼는 시점은 다릅니다.
실시간 음성 상담, 음성 비서, 통역처럼 대화가 이어지는 서비스에서는 TTS의 TTFA(Time to First Audio) 가 중요합니다. 이는 텍스트 요청 뒤 첫 오디오 조각이 도착하기까지 걸리는 시간입니다. 첫 음성이 늦으면 사용자는 시스템이 응답하지 않는다고 판단할 수 있습니다.
STT에서는 TTFS(Time to Final Segment) 를 봐야 합니다. 사용자의 발화 종료 신호 뒤 최종 텍스트를 받기까지 걸리는 시간입니다. 이 결과를 받은 뒤 LLM이 답변을 만들고, 예약 시스템을 조회하고, 상담 이력을 기록한다면 TTFS가 뒤 단계 지연에도 영향을 줍니다.
다만 이 수치만으로 체감 속도를 판단하면 부족합니다. 다음 조건도 함께 확인해야 합니다.
- STT가 말하는 중간 결과를 스트리밍으로 제공하는가
- 애플리케이션이 중간 결과를 화면에 보여주는가, 최종 결과만 사용하는가
- 사용자가 말을 끊었을 때 진행 중인 TTS 요청을 취소할 수 있는가
- 발화 종료를 시스템이 어떻게 감지하는가
- LLM 응답 생성, 검색, CRM 조회 시간을 음성 모델 시간과 분리해 측정했는가
예를 들어 통화 종료 후 회의록을 만드는 기능은 수 초의 처리 지연을 감수할 수 있습니다. 반면 고객과 대화 중인 음성 에이전트는 첫 반응과 차례 전환이 늦어질수록 대화 자체가 부자연스러워집니다. 두 업무에 같은 모델 등급과 같은 지연 목표를 적용할 이유는 없습니다.
WER은 평균 오류율이며, 업무 위험도는 따로 측정해야 한다
WER(Word Error Rate)은 단어 오류율입니다. 공개 모델 비교에서 정확도를 살필 때 널리 쓰이지만, 낮은 WER이 곧바로 낮은 업무 오류를 뜻하지는 않습니다.
예약 번호 한 자리, 고객 이름의 한 음절, 약품명, 상품 코드, 주소의 동·호수처럼 특정 항목 하나가 틀리면 후속 업무가 잘못될 수 있습니다. 이런 서비스는 평균 WER 외에 “틀렸을 때 어떤 일이 일어나는가”를 기준으로 시험 데이터를 구성해야 합니다.
한국어 환경에서는 특히 다음 조건을 따로 봐야 합니다.
- 숫자와 단위가 섞인 문장: 금액, 날짜, 시간, 수량, 층수
- 고유명사와 약어: 사람 이름, 조직명, 브랜드, 제품명, 내부 코드
- 한글과 외국어가 섞인 입력: 영문 제품명, 로마자 약어, 외래어 발음
- 표기 차이가 있는 표현: 띄어쓰기, 조사, 숫자의 한글 읽기
- 통화 품질이 낮은 입력: 배경 소음, 겹침 발화, 말끝이 잘린 녹음
TTS에서도 WER은 전달된 텍스트를 음성으로 명료하게 표현하는지 비교하는 지표 중 하나로 볼 수 있습니다. 하지만 안내문을 듣는 사람이 중요하게 느끼는 요소는 더 많습니다. 숫자와 단위의 읽기, 고유명사 발음, 긴 문장의 억양, 문장 중간 취소 뒤 재생성, 음성의 일관성은 별도로 확인해야 합니다.
평가표에는 오류 개수뿐 아니라 오류의 종류를 기록하는 편이 좋습니다.
| 구분 | 확인할 질문 | 판단에 미치는 영향 |
|---|---|---|
| 복구 가능한 오류 | 사용자가 한 번 더 말하거나 확인하면 해결되는가 | 재질문 UX와 처리 시간을 검토 |
| 업무 중단 오류 | 주문, 예약, 기록, 인증 결과가 잘못 처리되는가 | 높은 품질 모델 또는 확인 절차 검토 |
| 표기 오류 | 의미는 맞지만 CRM·검색·분석 형식과 맞지 않는가 | 후처리 규칙과 정규화 비용 검토 |
| 발음 오류 | TTS가 이름·숫자·약어를 다르게 읽는가 | 사전, SSML, 음성별 제어 가능 여부 확인 |
모델별 평균 점수가 비슷하다면, 업무 중단 오류가 적은 쪽이 더 적합할 수 있습니다. 반대로 오류가 있어도 즉시 재질문으로 복구되는 알림성 기능이라면 비용과 지연을 더 크게 볼 여지가 있습니다.
공개 벤치마크는 후보 압축에 쓰고, 수치의 조건을 분리해 읽는다
공개 벤치마크는 같은 방식으로 여러 API를 비교할 수 있게 해 줍니다. 다만 순위는 측정 시점, 데이터셋, 요청 방식, 공개 가격 정보, 포함된 엔드포인트 범위에 따라 달라질 수 있습니다.
2026년 9월 14일 기준으로 공개된 Coval 벤치마크 설명에서 Nari Labs의 Qwen3-ASR Fast는 중앙값 TTFS 44ms와 WER 3.6%로 제시됐습니다. Qwen3-TTS Fast는 중앙값 TTFA 63ms와 WER 3.8%로 제시됐습니다. 해당 게시물은 순위가 수시로 변동할 수 있으며, 수치는 특정 시점의 1일 보기와 벤치마크 조건에 따른 결과라고 밝혔습니다.
이런 수치는 “검토할 후보가 성능·지연의 어느 위치에 있는가”를 보는 데 적합합니다. 그러나 다음 질문에 대한 답은 별도 검증이 필요합니다.
- 우리 서비스의 한국어, 영어, 일본어 비중에서 같은 품질이 나오는가
- 짧은 명령문과 긴 상담 문장에서 지연 분포가 어떻게 달라지는가
- 예상 동시 요청이 몰릴 때 느린 요청이 얼마나 늘어나는가
- 사용자의 네트워크 환경과 배포 리전에서 왕복 시간이 어느 정도인가
- 모델 버전이나 음성 버전이 바뀌었을 때 결과가 달라지는가
- 특정 엔드포인트의 공개 수치가 계약 조건의 성능 보장을 뜻하는가
같은 Qwen3-TTS 계열을 제공하는 것으로 설명된 여러 공개 엔드포인트에서도 TTFA와 WER 수치가 서로 다르게 제시된 바 있습니다. 이 사실만으로 차이의 원인을 단정할 수는 없습니다. 다만 기반 모델 이름이 같아도, 구매하려는 API 엔드포인트 자체를 대상으로 시험해야 한다는 이유는 충분합니다.
비용은 분당 단가보다 서비스 흐름에서 계산한다
STT는 음성 시간 기준, TTS는 생성 문자 수 기준으로 가격을 정하는 경우가 많습니다. 따라서 “더 저렴한 음성 AI”를 고르려면 두 비용을 같은 단가로 환산하기보다 각 기능이 서비스에서 얼마나 쓰이는지 먼저 계산해야 합니다.
Nari Labs가 당시 공개한 가격은 Qwen3-ASR Fast가 시간당 0.12달러, Standard가 시간당 0.06달러였습니다. Qwen3-TTS Fast는 문자 100만 자당 10달러, Standard는 문자 100만 자당 5달러로 제시됐습니다. 이는 해당 시점의 공개 가격이므로, 계약 전에는 최신 요금, 최소 청구 단위, 지역별 조건, 무료 사용량, 초과 과금 규칙을 다시 확인해야 합니다.
예산표에는 모델 사용료 외에 다음 항목을 분리해 넣어야 합니다.
- STT 사용량: 실제 발화 시간, 무음 구간 과금 여부, 동시 채널 수, 재전사 요청
- TTS 사용량: 생성 문자 수, 같은 문구의 반복 생성, 캐시 적용 가능 여부
- 주변 인프라 비용: 음성 스트리밍, 통화 연결, 저장소, LLM 호출, 관측 도구
- 복구 비용: 재질문, 사람 상담 전환, 인식 결과 수정, 장애 시 이중 호출
- 운영 비용: 오류 표본 검수, 모델 변경 회귀 테스트, 고객 문의 대응
저가 모델이 항상 월 비용을 낮추지는 않습니다. 인식 오류로 재확인이 늘거나, 음성 응답 지연으로 사용자가 반복 요청하면 모델 호출량과 사람의 처리 시간이 함께 증가할 수 있습니다. 반대로 안내 방송, 상태 알림, 교육 콘텐츠 낭독처럼 오류의 업무 위험이 낮은 구간은 가격과 캐시 효율을 더 우선할 수 있습니다.
PoC는 데모가 아니라 장애까지 포함한 운영 시험이어야 한다
벤더 선정 단계에서는 한두 문장을 읽어 보거나 짧은 녹음 파일을 전사해 보는 데서 멈추기 쉽습니다. 그 방식은 API 연결 가능 여부는 확인하지만, 운영 중 문제가 생길 지점을 찾기는 어렵습니다.
다음 순서로 PoC를 설계하면 선정 회의의 논점을 모델 이름에서 업무 조건으로 옮길 수 있습니다.
-
후보를 제한합니다
지원 언어, API 형태, 스트리밍 제공 여부, 가격 공개 여부, 데이터 처리 조건을 기준으로 후보를 2~4개로 줄입니다. -
업무용 평가 세트를 만듭니다
일반 문장만 넣지 말고, 실제 안내문·상담 표현·상품명·숫자·주소·약어를 포함합니다. STT는 허용 가능한 범위에서 통화 품질이 낮은 녹음과 겹침 발화도 포함합니다. -
지연을 분포로 기록합니다
중앙값만 보지 말고, 느린 요청이 반복되는 조건, 오류 응답, 타임아웃, 재시도 뒤의 동작을 따로 기록합니다. 실시간 기능에서는 소수의 느린 응답도 사용자 경험을 망칠 수 있습니다. -
업무 시스템까지 연결합니다
인식된 텍스트가 CRM, 예약, 주문, 검색, LLM 프롬프트로 전달될 때 오류가 확대되는지 확인합니다. 음성 모델 자체의 오류와 후처리 규칙의 오류를 구분해야 고칠 대상을 잘못 잡지 않습니다. -
대체 경로를 시험합니다
공급자 API가 느려지거나 실패했을 때 텍스트 채널로 전환할지, 다른 모델로 넘길지, 기능을 축소할지 정합니다. 전환 규칙이 없다면 모델 하나의 장애가 전체 대화 흐름을 멈출 수 있습니다.
공급자에게는 평균 성능 수치 외에 다음을 물어보는 편이 좋습니다. 목표 언어별 성능 자료가 있는지, 스트리밍 중간 결과와 최종 결과를 어떻게 구분하는지, 동시성·속도 제한이 무엇인지, 모델 및 음성 버전 변경을 사전에 알리는지, 장애 상태와 지원 응답 체계를 어떻게 제공하는지 확인해야 합니다. 데이터 보관, 학습 사용, 삭제 조건도 기술 문서만 보지 말고 계약 조건에서 확인할 항목입니다.
모델 하나를 정하기 전에 라우팅 규칙부터 합의한다
음성 기능 전체에 하나의 최고 점수 모델을 붙이면 구성은 단순해 보입니다. 하지만 실시간 대화, 통화 후 기록 정리, 반복 안내, 개인화된 긴 답변은 요구하는 지연과 품질, 비용이 서로 다릅니다.
실시간 대화에는 TTFA와 TTFS를 우선하고, 통화 후 전사에는 처리 시간보다 정확도와 표기 규칙을 더 엄격하게 볼 수 있습니다. 반복 안내는 캐시와 문자당 비용을 중심으로 검토할 수 있으며, 개인화된 응답은 고유명사 발음과 음성 일관성을 더 중요하게 평가할 수 있습니다.
선정 회의에서 모델명부터 비교하지 말고 네 가지를 먼저 정해 보십시오. 사용자가 첫 반응을 기다릴 수 있는 시간, 틀리면 업무가 중단되는 정보, 사용량 증가에 따라 비용이 커지는 단위, 공급자 장애 때 유지할 최소 기능입니다. 이 기준이 합의되면 공개 순위는 홍보 문구가 아니라, 우리 서비스에 맞는 후보를 좁히는 입력값으로 바뀝니다.
