Huny's Dev Blog
huny.dev

Amazon Polly 한국어 음성 추가: API는 그대로인데 다시 검증해야 할 것

Polly Generative 업그레이드와 한국어 Hyunduk 추가를 계기로 엔진·리전 조회, 숫자 읽기 회귀검증, Speech Marks 제약을 정리한다.

Hun Jang
Hun Jang Oct 28, 2026

클라우드에서 바뀐 음성이 스피커로 전달되는 모습을 표현한 생성형 개념 이미지. 실제 AWS 제품이나 측정 화면이 아니다.

TTS API 코드를 바꾸지 않았는데 서비스의 목소리는 달라질 수 있을까? 관리형 생성형 TTS라면 API 호환성과 음성 출력의 동일성을 따로 확인해야 한다. Amazon Polly의 이번 업그레이드가 좋은 사례다.

AWS는 October 22, 2026 기술 블로그에서 Generative 엔진 업그레이드를 소개했다. 한국어 Hyunduk을 포함한 새 음성이 추가됐고, 기존 Generative 음성의 이름과 API 호출 방식은 유지된다고 설명한다. 기존 Standard·Neural 음성은 이번 변경의 대상이 아니다. 품질·정확도 향상은 AWS의 설명이며, 이 글에서 직접 청취 비교하거나 성능을 측정한 결과는 아니다. AWS 공식 발표

먼저 엔진과 리전을 확인한다

목소리 이름만 설정 파일에 적어두면 충분하지 않다. 배포 리전에서 그 음성이 어떤 엔진을 지원하는지 확인하는 단계가 필요하다.

다음은 독자가 자신의 승인된 AWS 환경에서 사용할 조회 예제다. 이 글을 작성하며 계정 API를 호출하지는 않았다. AWS CLI 설정과 polly:DescribeVoices 권한이 필요하다.

--engine과 --language-code는 사용할 범위를 줄인다. 결과의 Id를 합성 요청에 사용하고, SupportedEngines도 함께 보관하면 설정 점검에 도움이 된다. 목록은 시점과 리전에 따라 달라질 수 있으므로 이 글에 가상의 응답을 붙이지 않았다. DescribeVoices 공식 CLI 문서

새 음성을 합성할 때는 엔진을 명시한다

아래 명령은 위 조회에서 Hyunduk 지원을 확인한 뒤 사용하는 예제다. 실행하면 음성 합성 요금이 발생할 수 있다. 이 글에서는 실행하지 않았다.

SynthesizeSpeech는 엔진을 생략하면 Standard를 기본으로 선택한다. 해당 음성이 Standard를 지원하지 않으면 오류가 날 수 있다. 따라서 새 Generative 음성을 적용할 때는 기본값에 기대지 않는 편이 명확하다. 합성 명령과 기본값

API가 그대로여도 다시 들어봐야 하는 이유

다음은 공식 발표의 성능 보장이 아니라, 운영 서비스에 적용할 때 권하는 검증 방법이다.

  1. 주문 번호·금액·날짜·영문 약어처럼 틀리면 의미가 달라지는 문장을 고정한다.
  1. 사람이 기대하는 읽기를 별도로 적고, 실제 음성의 누락·반복·숫자 읽기를 확인한다.
  1. 짧은 안내와 긴 문장을 나눠 문장 끝이 잘리거나 불필요한 발화가 붙는지 듣는다.
  1. 같은 엔진·음성·리전·출력 형식으로 비교하고, 생성 시각과 입력 원문을 남긴다.
  1. 첫 오디오 도착 시간과 전체 생성 완료 시간을 분리해서 측정한다. 체감이 빠르다는 말만으로 지연 개선을 확정하지 않는다.

기존에 저장한 안내 음성과 새로 합성한 음성을 섞어 사용하는 서비스라면 목소리와 말투의 연결감도 점검할 만하다. 캐시를 전부 지우고 재합성하기보다 대표 문장부터 검토하는 편이 비용과 변경 범위를 통제하기 쉽다.

자막 타이밍과 SSML은 별도 확인이 필요하다

Polly의 Generative 음성은 현재 Speech Marks를 지원하지 않는다. 단어별 타임스탬프를 받아 자막이나 입 모양을 맞추던 파이프라인이라면 음성만 교체해서 끝낼 수 없다. SSML도 모든 태그를 동일하게 지원한다고 가정하면 안 된다. Generative 엔진의 지원 기능과 제한

같은 문장 길이에 같은 재생 시간이 나온다는 전제도 피해야 한다. AWS의 음성 속도 문서는 목소리마다 발화 속도가 다르다고 설명한다. 그 문서의 Speech Marks 기반 측정 예제는 이를 지원하지 않는 Generative 엔진에 그대로 적용할 수 없다. 완성된 오디오의 길이와 실제 발화를 기준으로 후처리 타이밍을 확인해야 한다. 음성 속도에 관한 공식 설명

정리

이번 소식의 실무 포인트는 한국어 선택지가 늘었다는 것과 기존 API를 유지하면서도 그 뒤의 생성 모델이 바뀐다는 것이다. 배포 리전의 음성 목록을 조회하고, 중요한 읽기 사례와 후처리 타이밍을 따로 검증하는 절차를 두면 관리형 TTS의 변화를 더 안전하게 받아들일 수 있다.

이 글은 공식 문서 확인과 적용 방법 제안까지 다룬다. 실제 AWS 계정 호출, 음질 청취 비교, 지연·정확도 벤치마크를 수행했다는 의미는 아니다.

추천 글