TTS 크레딧은 지키고 오디오는 다듬기: 콘텐츠 스코어링과 텍스트 정규화

웹사이트에 셀프서비스 TTS를 구축하다 보면 보이스, 모델, API와는 거의 상관없는 두 가지 문제에 슬그머니 부딪히게 됩니다. 첫째, 원본 텍스트는 스피커로 나올 때 원하는 대로 들리는 경우가 드뭅니다. 둘째, 공개 페이지에 TTS 엔드포인트를 두는 순간 낯선 사람도 그것을 호출할 수 있습니다. TTS2Go는 두 가지 전용 시스템으로 이 문제를 해결합니다. 합성 전에 어색한 입력을 고쳐 쓰는 텍스트 정규화 파이프라인, 그리고 실제로 사이트에 어울리는 요청만 자동 승인하는 AI 콘텐츠 스코어링 계층입니다. 이 글에서는 두 시스템이 무엇인지, 왜 존재하는지, 그리고 왜 함께 쓰는 것이 중요한지 살펴봅니다.

브라우저 SDK는 자신이 어느 프로젝트에 속하는지 알아야 하고, 그 식별자는 사용자가 들여다볼 수 있는 코드 안에 있습니다. 도메인 허용 목록과 속도 제한으로 보호할 수는 있지만, 식별자 자체는 비밀이 아닙니다. 누군가 엔드포인트를 찾아내면 요청을 보낼 수 있습니다. 그 요청 하나하나가 합성 단계에 도달하면 제공업체 크레딧을 소모할 수 있습니다.

본능적으로는 생성 전에 모든 요청을 사람이 승인하도록 하고 싶어집니다. 그 판단은 옳고, TTS2Go도 기본적으로 그렇게 동작합니다. 하지만 이 업무는 담당 팀보다 더 빠르게 불어납니다. 실제 트래픽이 생길 즈음이면 수동 승인은 하루 종일 업무를 끊어 놓는 일이 됩니다.

품질 측면에서도 TTS 제공업체마다 흔한 패턴을 읽는 방식이 다릅니다. “2026-04-21” 같은 날짜는 어떤 엔진에서는 “April twenty-first, twenty twenty-six”로, 다른 엔진에서는 “twenty twenty-six dash oh four dash twenty-one”으로 읽힐 수 있습니다. 통화, 시간, 약어, 큰 숫자 모두 예측하기 어렵게 동작합니다. 작성자는 제공업체의 내부 동작을 통제할 수 없고, 제공업체는 여러분의 콘텐츠를 알지 못합니다.

모든 TTS2Go 프로젝트는 수동 승인으로 시작합니다. SDK가 생성 요청을 보내면 요청이 대시보드 대기열에 들어옵니다. 검토한 뒤 승인하거나 거부하며, 승인된 요청만 크레딧을 소모합니다. 이는 안전한 기본값이며 실제로 잘 작동합니다. 자신의 목소리로 나가는 모든 오디오를 꼼꼼히 챙기려는 팀은 완전한 통제권을 갖게 됩니다.

하지만 느립니다. 트래픽이 충분히 많아지면 기계에 맡기고 싶어지는 종류의 워크플로가 됩니다.

AI 콘텐츠 스코어링이 바로 그 기계입니다. 프로젝트마다 짧은 콘텐츠 프로필을 구성합니다. 사이트가 무엇에 관한 것인지, 사이트 유형, 언어, 그리고 몇 가지 예시 문구를 적어 둡니다. 생성 요청이 들어오면 TTS2Go는 요청 텍스트와 프로필을 언어 모델에 보내고, 모델은 1부터 10까지의 점수와 짧은 이유를 돌려줍니다.

임계값은 직접 정합니다. 임계값 이상인 요청은 자동 승인되어 합성으로 넘어갑니다. 임계값 미만인 요청은 사이트에 맞게 수동 대기열로 돌리거나 바로 거부할 수 있습니다. 척도는 이분법이 아닙니다. 가장 낮은 “스팸 또는 악용”부터 “관련성 낮음”, “일치 가능성 있음”, “잘 일치함”을 거쳐 가장 높은 “완벽히 일치함”까지 단계가 나뉩니다. 콘텐츠 구성에 맞게 원하는 만큼 엄격하거나 너그럽게 설정할 수 있습니다.

그 결과, 엔드포인트를 찾아내 관련 없는 텍스트를 생성하려는 낯선 사람은 낮은 점수를 받아 합성 단계에 결코 도달하지 못합니다. 여러분의 페이지에서 나온 정상적인 콘텐츠는 높은 점수를 받아 개입 없이 낭독됩니다. 여러분은 중간 구간만, 그것도 원할 때만 확인하면 됩니다.

스코어링은 정규화된 버전이 아니라 원본 텍스트를 대상으로 실행됩니다. 스코어링은 오디오가 최종적으로 어떻게 들릴지가 아니라 콘텐츠가 적절한지를 판단하는 일이기 때문입니다.

콘텐츠가 생성 승인을 받으면, 다음 질문은 그것이 어떻게 들릴지입니다. TTS2Go는 승인된 모든 요청을 제공업체에 보내기 전에 규칙 기반 정규화 파이프라인에 통과시킵니다. 이 파이프라인은 제공업체마다 처리 방식이 들쭉날쭉한 원본 텍스트의 요소들을 고쳐 씁니다. 정수와 소수, 날짜와 시간, 여러 형식의 통화, 백분율, 로마 숫자, 그리고 “Dr.”, “Mr.”, “etc.” 같은 흔한 약어가 그 대상입니다.

예를 들어 “The invoice of $1,234.56 is due on 2026-04-21”은 “The invoice of one thousand two hundred thirty-four dollars and fifty-six cents is due on April twenty-first, twenty twenty-six.”가 됩니다. “Chapter IV has 5 sections”는 “Chapter four has five sections.”가 됩니다. 모든 변환은 결정적이고, 각각에 대응하는 단위 테스트가 있으며, 런타임 비용이 전혀 들지 않습니다. 모두 로컬에서 처리되므로 합성 경로에 API 호출이 추가되지 않습니다.

AI 계층을 하나 더 두는 대신 규칙 기반을 택한 것은 의도적인 선택입니다. 규칙은 예측 가능합니다. 재현할 수 있고, 설명할 수 있고, 차이를 비교할 수 있습니다. 사용자가 이상한 소리를 들었다면 그 이유를 정확히 찾아내 문제를 일으킨 특정 규칙을 고칠 수 있습니다. 오디오는 하나의 공연이고, 공연에는 반복 가능한 대본이 필요합니다.

두 시스템은 파이프라인의 양 끝에서 작동합니다. 스코어링은 무엇이 합성에 도달할지를 결정하고, 정규화는 그것이 어떻게 들릴지를 결정합니다. 하나는 예산을 지키고, 다른 하나는 출력 품질을 지킵니다. 스코어링을 없애면 크레딧이 노출되고, 정규화를 없애면 오디오 품질이 들쭉날쭉해집니다. 두 시스템이 함께하면 콘텐츠 검수자와 언어학자가 필요했던 TTS 연동 프로젝트가 SDK 코드 한 줄로 바뀝니다.

두 시스템 모두 대시보드 사이드바에서 실시간 데모를 제공합니다. AI Content Scoring 페이지에서는 샘플 텍스트를 붙여 넣고, 각 프로젝트의 콘텐츠 프로필 기준으로 정확한 점수, 이유, 자동 승인 여부를 확인할 수 있습니다. Speech Formatting 페이지에는 입력한 내용의 정규화된 버전을 전후 비교 예시와 나란히 보여 주는 Try-It 입력창이 있습니다. 둘 다 속도 제한이 걸려 있고, 크레딧을 소모하지 않으며, 실제 요청이 들어왔을 때 프로덕션에서 일어나는 처리를 그대로 반영합니다.

이미 TTS2Go 프로젝트가 있다면 대시보드를 열어 두 가지를 모두 사용해 보세요. 이제 막 시작한다면 프로젝트를 만들고, 페이지에 React SDK를 넣은 뒤, 처음 들어오는 몇 건의 요청을 수동 대기열에서 받아 보세요. 전체 파이프라인이 처음부터 끝까지 작동하는 모습을 확인할 수 있습니다.