AI 음성 생성(TTS)은 텍스트를 음성으로 바꾸고, 음성 인식(STT)은 녹음된 말을 텍스트로 바꿉니다. 둘은 입력과 출력의 방향이 반대지만, 품질은 모델 이름 하나가 아니라 텍스트 전처리, 언어와 음성, 마이크·녹음 환경, 모델 및 설정, 후처리와 평가 방법이 함께 결정합니다.
확인 기준은 2026년 9월 15일의 Google Cloud 음성 문서, W3C 음성 합성 표준, NIST·ITU-T 평가 자료입니다. 서비스마다 제공 기능과 설정이 다르며 내부 모델 구조와 학습 데이터는 공개 범위가 다릅니다. 특정 모델이 모든 언어와 소음 환경에서 항상 더 정확하거나 자연스럽다고 단정하지 않습니다.
AI 음성 기술, 소통의 경계를 허물다
TTS와 STT는 화면을 읽기 어려운 사용자의 정보 접근, 영상 자막, 회의 기록, 음성 안내, 콘텐츠 내레이션 등에 활용될 수 있습니다. 다만 “활용 가능”과 “그대로 운영해도 충분한 품질”은 다릅니다. 이름·숫자 오류가 큰 업무, 화자 구분이 필요한 회의, 긴급 안내나 의료·법률 문구처럼 오류 비용이 큰 경우에는 사람의 검수와 서비스별 책임 범위를 먼저 정해야 합니다.
아래 처리 흐름은 제품을 비교하고 오류 지점을 찾기 위한 개념도입니다. 최신 모델은 여러 단계를 하나의 신경망으로 결합하거나 음향 토큰을 바로 생성할 수 있으므로 모든 제품에 동일한 내부 모듈이 존재한다는 뜻은 아닙니다.
TTS의 기본 처리 흐름
TTS는 대체로 다음 문제를 순서대로 처리하지만 구현 방식은 모델마다 다릅니다.
- 텍스트 정규화: 숫자, 날짜, 약어, 기호를 어떻게 읽을지 해석합니다.
- 발음·언어 처리: 글자열을 발음 단위나 모델의 내부 표현으로 바꿉니다.
- 운율 결정: 문장 경계, 강세, 속도, 높낮이와 쉼을 반영합니다.
- 음향 생성: 음향 특징, 음향 토큰 또는 파형을 생성합니다.
- 출력 처리: 필요한 오디오 형식으로 변환하고 음량·끊김·길이를 확인합니다.
전통적인 신경망 TTS 설명에서는 멜 스펙트로그램 같은 중간 표현과 보코더를 나누지만, 모든 현행 모델이 이 구조를 그대로 쓰는 것은 아닙니다. 일부는 중간 단계를 결합하거나 다른 음향 표현과 생성 방식을 사용합니다.
W3C SSML 권고안은 break, phoneme, prosody, say-as, sub처럼 쉼·발음·운율·숫자나 약어 해석에 힌트를 주는 요소를 정의합니다. 그러나 같은 문서도 언어의 모호성과 처리기 차이 때문에 표시하지 않은 숫자·약어·고유명사가 서로 다르게 읽힐 수 있다고 설명합니다. Google Cloud TTS의 SSML 문서는 W3C 요소 전체가 아니라 제품이 지원하는 일부만 쓸 수 있음을 명시합니다. 따라서 SSML 지원 여부와 결과는 사용하는 엔진 문서에서 다시 확인해야 합니다.
STT의 기본 처리 흐름
STT는 대체로 다음 관찰 지점으로 나눌 수 있습니다.
- 수집: 마이크나 파일에서 음성을 받고 인코딩·채널·샘플링 정보를 확인합니다.
- 음성 표현: 파형을 음향 특징이나 모델이 처리하는 내부 단위로 바꿉니다.
- 인식·디코딩: 음성과 언어 문맥을 이용해 가능한 문자·토큰·단어열을 계산합니다.
- 후처리: 띄어쓰기, 구두점, 숫자 표기, 화자 구분, 타임스탬프 등을 적용합니다.
- 검증: 원문 전사와 비교하고 중요한 고유명사·숫자·누락을 별도로 확인합니다.
Google Cloud STT 요청 개요는 요청에 오디오 인코딩, 샘플링률, 언어·지역과 용도에 맞는 모델 정보가 포함될 수 있음을 보여 줍니다. 현행 end-to-end 모델은 전통적인 음향 모델·발음 사전·언어 모델 경계를 내부에서 결합할 수 있으므로 모든 STT가 독립된 세 모듈로 구성된다고 단정할 수 없습니다.
WER은 무엇을 재고 무엇을 놓치는가
WER(Word Error Rate, 단어 오류율)은 기준 전사와 인식 결과를 정렬해 대체(S), 삭제(D), 삽입(I) 오류 수를 기준 전사의 단어 수(N)로 나눈 값입니다. 즉 WER = (S + D + I) / N입니다.
이 비율은 기준 전사의 단어가 하나 이상일 때 계산할 수 있습니다. 기준 전사가 비어 있으면 N=0이므로 위의 비율은 정의되지 않습니다. JiWER 문서는 최소 편집거리로 정렬하며 버전 4.0부터 빈 기준 전사에 별도의 처리 규칙을 정의합니다. 따라서 빈 전사를 포함한 평가에서는 사용한 도구의 버전과 처리 방식을 함께 기록해야 합니다. Google Cloud의 음성 정확도 측정 문서는 WER과 사람이 확정한 ground truth를 설명하며, 삽입이 많으면 WER이 100%를 넘을 수도 있고 신뢰도 점수와 WER은 서로 다른 값이라고 명시합니다. NIST의 ASR 평가 자료도 전사 품질과 시험 세트·단어 매핑 방법이 다르면 결과를 곧바로 비교할 수 없다고 경고합니다.
WER이 낮을수록 같은 기준 전사와 정규화 규칙을 쓴 동일 시험 안에서는 단어 오류가 적다고 해석할 수 있습니다. 그러나 다음 한계가 있습니다.
여러 문장을 평가할 때 전체 오류를 전체 기준 단어 수로 나눈 값과 문장별 WER의 단순 평균은 서로 다를 수 있습니다. 문장 길이가 다르면 각 방식이 문장에 부여하는 비중이 다르기 때문입니다. 비교할 때는 집계 방식을 명시하세요. JiWER 사용 문서는 여러 문장을 함께 평가하는 예와 정렬 결과 확인 방법을 제공합니다.
- 고유명사 한 글자 오류와 의미가 거의 같은 조사 오류의 업무상 피해를 구분하지 않습니다.
- 띄어쓰기와 숫자 표기, 구두점 포함 여부 등 정규화 규칙에 영향을 받습니다.
- 서로 다른 언어·데이터셋·녹음 조건에서 나온 WER은 공정한 순위표가 아닙니다.
- 화자 구분, 타임스탬프, 지연, 문장부호, 금칙어 처리 품질을 모두 나타내지 않습니다.
- 짧은 표본 하나의 WER은 실제 사용 분포를 대표하지 못합니다.
따라서 전체 WER과 함께 업무상 중요한 고유명사·숫자 정확도, 누락, 화자 구분, 처리 시간과 수정 시간을 따로 기록해야 합니다.
TTS 품질은 자연스러움 하나로 끝나지 않는다
TTS에는 STT의 WER처럼 한 숫자로 모든 품질을 설명하는 지표가 없습니다. 청취자가 품질을 평가한 점수를 평균내는 MOS(Mean Opinion Score)가 널리 쓰이지만, ITU-T P.800.1은 MOS가 청취 품질인지 대화 품질인지, 주관 시험인지 객관 모델의 예측인지 등 조건을 식별해야 한다고 정리합니다. 서로 다른 청취자·문장·장비·평가 질문으로 얻은 MOS를 단순 비교하면 안 됩니다.
실제 선택에서는 적어도 다음 항목을 분리해서 듣는 편이 낫습니다.
- 명료도: 내용을 다시 듣지 않고 알아들을 수 있는가
- 발음: 고유명사, 외래어, 약어와 숫자가 의도대로 읽히는가
- 운율: 쉼표·마침표의 쉼, 강세와 억양이 문맥에 맞는가
- 일관성: 문장 사이 음색·속도·음량이 갑자기 변하지 않는가
- 완전성: 단어가 빠지거나 반복되고 끝부분이 잘리지 않는가
- 용도 적합성: 내레이션, 안내 방송, 대화 등 목표에 맞는가
합성 음성을 STT로 다시 전사해 단어 오류를 보는 방법은 발음 명료도의 보조 지표가 될 수 있지만, 그 결과에는 사용한 STT의 오류도 섞입니다. 이를 TTS 자연스러움의 단독 점수로 사용하면 안 됩니다.
소음·마이크·언어·모델·후처리의 영향
STT 오류는 소음 하나로 설명되지 않습니다. 마이크 거리와 방향, 잔향, 여러 사람의 겹말, 클리핑, 인코딩, 채널, 언어·지역 설정, 모델 용도, 고유명사 힌트와 후처리가 모두 결과에 영향을 줄 수 있습니다. Google Cloud STT 권장사항은 해당 서비스에서 마이크를 화자 가까이 두고 클리핑을 피하며 요청의 인코딩·언어·모델을 실제 오디오와 맞추라고 안내합니다. 동시에 사전 노이즈 제거가 그 서비스의 인식을 오히려 낮출 수 있다고 적고 있으므로 “노이즈 제거를 하면 항상 좋아진다”고 일반화할 수 없습니다.
희귀한 고유명사나 전문 용어는 일반 문장과 다른 오류 패턴을 보일 수 있습니다. 제품이 제공한다면 모델 적응·구문 힌트 안내를 확인할 수 있지만, 힌트를 추가하면 모든 문장이 좋아진다는 보장은 없습니다. 목표 단어뿐 아니라 다른 단어의 오인식도 함께 비교해야 합니다.
TTS 역시 언어·지역, 목소리, 입력 표기, 문장부호, 숫자·약어 정규화, SSML 지원 범위, 오디오 형식과 재생 장치에 영향을 받습니다. 엔진 이름만으로 특정 고유명사 발음이나 모든 환경의 자연스러움을 보장할 수 없습니다.
결과를 꾸미지 않는 STT 비교 절차
아래 절차는 예상 결과가 아니라 독자가 자신의 파일과 제품으로 채우는 기록 방법입니다.
- 고유명사·숫자·일반 문장이 섞인 짧은 기준 문장을 작성하고 정답 전사를 확정합니다.
- 같은 화자·문장·마이크·거리·공간에서 녹음한 원본 파일 하나를 보관합니다.
- 비교할 STT마다 같은 파일을 넣고 모델 이름·버전, 언어, 설정과 실행 시각을 기록합니다.
- 출력 원문을 수정하지 않은 채 대체·삭제·삽입을 세고 같은 정규화 규칙으로 WER을 계산합니다.
- 고유명사·숫자 오류, 구두점, 화자 구분, 처리 시간과 사람이 수정한 시간을 별도 열에 적습니다.
- 마이크나 소음 조건을 비교하려면 한 번에 변수 하나만 바꾸고 새 파일로 구분합니다.
| 항목 | 기록 방법 |
|---|---|
| 기준 문장·정답 전사 | 테스트 전에 직접 입력해 둔다 |
| 원본 오디오·마이크·거리·환경 | 녹음 조건을 항목별로 메모한다 |
| STT 제품·모델·버전·언어 설정 | 사용한 제품명·모델·버전·언어를 적는다 |
| 수정 전 출력과 S·D·I·N | 보정 전 원문 출력에서 대체·삭제·삽입·정답 수를 센다 |
| WER·고유명사·숫자·누락 | 위 4번 규칙대로 계산한다 |
| 처리 시간·사람의 수정 시간 | 같은 기준(초 단위)으로 측정한다 |
표본 하나로 서비스 전체의 정확도를 결론 내리지 말고, 실제 사용 환경의 조용한 음성·소음·겹말·전문 용어 표본을 분리해 반복합니다.
TTS 발음·쉼·숫자 점검 절차
- 실제 원고에서 고유명사, 외래어, 약어, 날짜·시간·금액·전화번호, 쉼표와 괄호가 든 문장을 고릅니다.
- 같은 TTS 제품·모델·음성·언어·속도·오디오 형식으로 원문을 합성합니다.
- 단어 누락·반복·잘림, 고유명사·숫자 발음, 문장부호의 쉼, 속도와 음량 변화를 항목별로 듣습니다.
- 제품이 지원하는 경우에만 발음 사전, 텍스트 치환이나 SSML을 적용하고 변경 전후 파일을 따로 보관합니다.
- 한 번에 표기 또는 설정 하나만 바꿔 어떤 수정이 결과에 영향을 줬는지 구분합니다.
- 최종 재생 장치에서도 클리핑, 음량과 알아듣기 어려운 부분을 다시 확인합니다.
| 점검 항목 | 판정 기록 |
|---|---|
| 고유명사·외래어·약어 | 의도한 발음 / 수정 필요 |
| 숫자·날짜·단위 | 읽는 방식과 누락 여부 |
| 쉼표·마침표·괄호 | 쉼의 위치와 길이 |
| 단어 누락·반복·끝 잘림 | 발생 위치 |
| 속도·억양·음량 | 용도 적합 여부 |
| 수정 방법 | 원문 치환·사전·지원되는 SSML |
이 표에는 실제로 들은 결과만 씁니다.
활용할 때의 최종 확인 순서
회의록과 자막에서는 WER뿐 아니라 사람 이름·제품명·숫자, 화자 구분과 타임스탬프를 확인합니다. 오디오북·안내 음성에서는 발음·쉼·누락·재생 장치 품질을 먼저 봅니다. 접근성 용도에서는 대상 사용자가 실제로 이해하고 조작할 수 있는지 별도 검증이 필요합니다. 실시간 통역은 STT 오류에 번역·TTS 오류와 지연이 더해지므로 각 단계를 나눠 평가합니다.
한국어 TTS의 구체적인 전처리와 속도·억양 점검은 한국어 TTS 품질을 좌우하는 요소에서 이어서 볼 수 있습니다. Edge-TTS 사용 중 발음과 자막 싱크를 확인하는 절차는 Edge-TTS 한국어 가이드, NAS 자동화 구성의 실제 범위는 UGREEN NAS 쇼츠 자동화 구축기에서 확인할 수 있습니다.
핵심은 서비스 이름이나 데모 한 번으로 품질을 확정하지 않는 것입니다. 같은 입력과 조건을 보존하고, WER의 시험 조건과 TTS 청취 기준을 명시하며, 모델·언어·설정과 후처리를 함께 기록해야 내 용도에 맞는 결과인지 판단할 수 있습니다.