영상 내레이션용 Gemini TTS와 ElevenLabs, 같은 대본으로 비교하기

내레이션 모델을 고를 때는 받아들일 수 있는 음성 결과물, 실제 API 경로에서 사용할 수 있는 제어 기능, 그리고 결과물을 영상에 맞추는 데 필요한 작업을 함께 고려해야 합니다. 문자당 가격과 오디오 토큰 가격을 비교하는 것만으로는 완성된 내레이션 중 어느 쪽의 비용이 더 낮은지 알 수 없습니다. 서로 다른 대본을 비교해서는 같은 작업을 어느 음성이 더 잘 처리하는지도 알 수 없습니다.

2026년 10월 10일, 원본 영어 대본 하나를 Ofox를 통해 elevenlabs/eleven_v4와 google/gemini-3.8-flash-tts에 각각 전송했습니다. 두 요청 모두 성공했습니다. ElevenLabs 파일의 길이는 10.00초, Gemini 파일은 9.76초입니다. 아래에서 두 원본 파일을 모두 다운로드할 수 있습니다. 이는 구성별로 한 번씩 생성해 관찰한 결과이지, 자연스러움이나 지원 언어 또는 프로덕션 안정성을 평가한 순위가 아닙니다.

보편적인 승자를 찾기보다 작업부터 살펴보세요

10초짜리 제품 설명 영상과 오디오북, 실시간 음성 비서, 다국어 교육 과정은 서로 다른 수용 기준이 필요합니다. 이 비교는 영상에 사용할 사전 제작 내레이션을 대상으로 합니다. 즉, 요청 전에 대본을 준비하고, 오디오 파일을 받은 뒤, 편집자가 게시 전에 결과물을 확인하는 작업입니다.

스트리밍 대화, 음성 복제, 감정 표현 범위, 두 서비스 카탈로그의 모든 음성을 시험한 것은 아닙니다. 통제된 청취 패널을 통한 평가도 아닙니다. 생성된 결과물과 기술적 특성은 확인했지만, 독자는 각자의 발음과 전달 방식에 대한 요구사항에 맞춰 실제 파일을 직접 들어보고 평가해야 합니다.

따라서 가장 유용한 질문은 다음과 같습니다. 다음에 만들 특정 결과물에 어떤 구성을 먼저 시험해 볼까요? 두 모델이 모두 대본을 읽을 수 있더라도, 답은 현재 사용 중인 음성 파이프라인, 원하는 음성, 편집 예산, 확인된 과금 내역에 따라 달라질 수 있습니다.

동일한 대본과 실제 사용한 두 구성

두 호출 모두 아래 원문을 사용했습니다. 동일한 UTF-8 파일에서 읽었으며, 앞뒤 공백을 제거한 뒤 요청했습니다.

A clear product video starts with a clear brief. Show the real interface, explain one useful task, and check the exported video before sharing it.

대본은 변경하지 않았고 두 경우 모두 속도 1.0을 요청했습니다. 두 제공업체가 게이트웨이에서 서로 다른 선택지를 제공하므로 음성과 출력 프리셋은 서로 다릅니다. 따라서 이는 음성 식별과 인코딩을 동일하게 유지하고 모델만 분리해 비교하는 실험이 아니라, 실제 사용을 고려한 구성 간 비교입니다.

경과 시간은 네트워크 상태를 포함한 단일 클라이언트 요청의 결과입니다. 첫 바이트 스트리밍 지연 시간을 측정한 것이 아닙니다. 파일 크기 차이는 요청한 압축 MP3와 WAV 형식의 영향을 크게 받습니다. 파일이 더 크다고 해서 음성이 더 좋다는 증거는 아닙니다.

정규화하기 전에 원본 파일부터 들어보세요

ElevenLabs MP3와 Gemini WAV를 다운로드하세요. 전체 키트에는 대본, 클라이언트, 구성 파일과 메타데이터가 포함되어 있어 예시에서 인증 정보를 복사하지 않고도 테스트를 재현할 수 있습니다.

ElevenLabs 생성 음성

Gemini 생성 음성

출처를 확인할 수 있도록 원본 파일을 보관하세요. 청취용으로 음량을 정규화한 사본을 만들었다면 원본과 구분되는 이름을 붙이고 별도로 기록하세요. 음량 차이가 선호도에 영향을 줄 수 있으므로 공정하게 청취 비교를 하려면 재생 음량을 일정하게 맞춰야 합니다. 다만 다운로드한 파일을 몰래 처리한 뒤 처리한 사본을 API 원본 결과물인 것처럼 설명해서는 안 됩니다.

헤드폰을 사용하거나 시청자가 실제로 영상을 들을 기기에서 확인하세요. “API”, 브랜드명, 날짜, 핵심 동작이 명확하게 들리는지 점검하세요. 마음에 드는 2초만 골라 듣지 말고 전체 문장을 맥락 속에서 확인하세요. 짧은 샘플에서 매력적으로 들리는 음성도 실제 대본에 적용하면 편집 작업이 너무 많이 필요할 수 있습니다.

이 글에서는 자연스러움 점수를 매기지 않습니다. 청취 절차를 정의하고 실제 청취자 기록을 남기지 않은 상태에서 수치 점수를 제시하면 정확해 보이는 것에 비해 근거가 부족해집니다. 근거 없는 “더 좋게 들린다”는 주장에 기대지 않고 직접 확인할 수 있도록 파일을 제공했습니다.

동일한 대본 테스트 재현하기

Ofox 키를 설정하고 Python requests, FFmpeg, ffprobe를 설치한 뒤 키트의 압축을 풀고, 새 출력 파일 이름을 지정해 각 제공업체에 한 번씩 요청하세요.

python3 audio_api.py speech --engine elevenlabs \
  --text comparison.txt --output my-elevenlabs.mp3
python3 audio_api.py speech --engine gemini \
  --text comparison.txt --output my-gemini.wav

이 명령은 실제 요청을 두 번 전송합니다. 게시된 예시 파일을 확인하려고 실행할 필요는 없습니다. 해당 파일은 이미 키트에 들어 있습니다. 클라이언트는 지정한 출력 파일이 이미 있으면 중단하며, 오류는 오디오 파일과 별도로 저장합니다. 요청 결과를 알 수 없는 경우 자동으로 POST를 반복 전송하는 재시도 루프는 사용하지 않습니다.

관련 Ofox 연동 정보는 ElevenLabs와 Gemini TTS 모델 페이지에서 확인할 수 있습니다. 페이로드를 변경하기 전에 페이지를 살펴보세요. ElevenLabs 공식 음성 합성 문서와 Google TTS 개요도 참고할 만하지만, 각 문서에 나오는 전체 매개변수 집합이 어댑터를 통해 변경 없이 전달된다고 가정해서는 안 됩니다.

한 구성이 실패했다면 음성 품질의 승자를 선언하기 전에 먼저 실패 원인을 해결하세요. 이전 시도에서 ElevenLabs 경로는 업스트림 할당량 오류를 반환했습니다. 복구된 뒤에는 제공된 파일을 생성했습니다. 이 운영상 문제는 모델의 음성 품질이 낮다는 뜻이 아니며, 이후 요청이 성공했다고 해서 장기적인 가동 시간을 비교할 수 있는 것도 아닙니다.

편집 작업에서 0.24초의 길이 차이가 의미하는 것

이 파일에서는 ElevenLabs가 Gemini보다 0.24초 길며, Gemini 녹음 길이인 9.76초를 기준으로 2.46% 차이가 납니다. 영상의 컷 전환 시점이 엄격하다면 영향을 줄 수 있지만, 이는 특정 구성에서 한 번 관찰한 아주 작은 차이입니다. 다른 생성 결과, 음성, 언어 또는 문장에서는 다르게 나타날 수 있습니다.

화면이 정확히 10초에 끝난다면 마지막 발화 단어와 그 뒤의 무음을 확인하세요. 컨테이너에 표시된 파일 길이만으로는 마지막 단어가 실제로 끝난 시점을 알 수 없습니다. ElevenLabs 샘플을 별도로 Scribe로 전사한 결과, 마지막 단어가 끝난 시점은 9.78초였습니다. 직접 확인하지 않은 Gemini 파일에 이 타이밍을 그대로 적용하지 마세요.

긴 프레젠테이션에서는 장면별로 내레이션을 나눠 구성하세요. 그래야 한 줄을 수정할 때 녹음 전체를 다시 생성하지 않아도 됩니다. 대본 구간, 오디오 테이크, 장면 길이를 함께 저장하세요. 문장을 다시 생성했다면 이전 파일의 길이에 기대지 말고 해당 문장의 타이밍과 자막 정렬을 다시 계산하세요.

영상 내레이션 워크플로에서는 오디오를 측정하고 MP4와 결합하는 방법을 설명합니다. Scribe 자막 튜토리얼에서는 실제 단어 타이밍으로 자막을 만드는 방법을 다룹니다. 어느 모델의 오디오 길이도 기존 타임라인이 수정 없이 그대로 맞을 것이라는 보장으로 받아들여서는 안 됩니다.

유용한 청취·편집 평가 기준

제공업체를 선택하기 전에 짧은 수용 기준표를 만드세요. 검토자가 실제로 확인할 수 있는 기준을 사용하고, 문제가 있다면 해당 구간의 타임코드를 기록하세요. 이렇게 하면 막연한 선호가 재현할 수 없는 제작 기준으로 굳어지는 일을 막을 수 있습니다.

내부 블라인드 비교를 한다면 청취용 파일에서 제공업체 표시를 숨기고, 동일한 재생 조건을 사용하며, 검토자에게 판단 이유를 기록하게 하세요. 그런 다음 구성을 공개하면 됩니다. 검토자가 두 명뿐이거나 문장 하나만 비교했다면, 결과를 시장 전체의 선호처럼 표현하지 말고 표본 규모를 함께 밝혀야 합니다.

전사본 확인은 유용하지만 한계가 있습니다. Scribe는 문장부호를 제외하고 ElevenLabs 샘플에서 의도한 단어를 복원했습니다. 이는 이처럼 깨끗한 예시에서 텍스트가 복원됐다는 점을 뒷받침할 뿐, 지각적 품질 점수는 아닙니다. 전사되지 않은 Gemini 샘플에 대해서도 그 자체로는 아무것도 입증하지 않습니다.

서로 다른 단가가 아닌 승인된 내레이션의 비용을 비교하세요

현재 Ofox 카탈로그에서 두 모델은 서로 다른 가격 항목을 사용합니다. ElevenLabs에는 문자 기준 입력 항목이 있고, Gemini TTS에는 텍스트 입력 및 오디오 출력 토큰 항목이 있습니다. 이런 차이는 단순 수치 비교가 왜 오해를 낳는지 보여줍니다. 하지만 이 항목만으로는 다운로드한 예시의 요청별 확정 청구액을 알 수 없습니다.

이 두 호출을 개별 청구 내역과 대조해 확인하지 않았으므로, 표에는 “실제 비용”이나 절감 비율을 주장하는 내용을 넣지 않았습니다. 카탈로그에 표시된 가격, 지갑 잔액 변화, 확정된 요청별 청구액은 서로 다른 근거입니다. 공유 지갑 잔액은 무관한 작업으로도 변할 수 있으며, 바이너리 오디오 응답에 청구 대상 카운터가 모두 포함되는 것도 아닙니다.

직접 평가할 때는 요청 ID와 해당 사용량 기록을 함께 확인하세요. 게이트웨이의 과금 기준에 따라 텍스트를 계산하고, 해당되는 경우 반환되었거나 기록된 토큰 수량을 사용한 다음, 적용된 가격 정보와 반올림 여부를 확인하세요. 제공업체 가격과 Ofox 계정에 청구된 가격은 따로 기록하세요.

거부된 테이크도 포함해야 합니다. 제공업체 A는 한 줄을 승인받기까지 요청 세 번과 수동 수정이 필요하지만, 제공업체 B는 한 번으로 끝난다면 실제 사용 가능한 결과물의 비용은 단일 호출 가격과 달라집니다. 실무용 계산표는 다음과 같습니다.

accepted_narration_cost = sum(verified charges for all takes)
editing_minutes = time spent reviewing and repairing those takes
acceptance_rate = accepted takes / generated takes

계산 결과를 보고할 때는 오디오의 범위와 검토 기준도 함께 밝혀야 합니다. 요청 시간의 밀리초를 청구액으로 환산하거나, 다운로드 바이트 수를 오디오 출력 토큰 대신 사용하지 마세요. 과금 데이터를 확인할 수 없다면 비용을 검증되지 않은 것으로 표시하고, 운영 및 결과물 기준으로 비교하는 것이 정확합니다.

어떤 구성을 먼저 평가하면 좋을까요?

기존 프로젝트에서 특정 ElevenLabs 음성을 이미 사용 중이라면 호환되는 경로를 통해 해당 음성으로 시작해 실제 대본을 시험하세요. 익숙한 음성을 유지하면 편집 변경을 줄일 수 있지만, 이 샘플이 모든 계정별 음성이나 복제 음성을 Ofox에서 사용할 수 있다는 점을 입증하는 것은 아닙니다.

공개된 Ofox Gemini 다국어 워크플로를 확장하는 경우에는 검증된 Gemini 구성을 먼저 사용해 대본과 조립 도구를 일관되게 유지하세요. 그런 다음 호환되는 선호 음성이 있거나 발음 요구사항을 충족하지 못하는 등 구체적인 이유가 있을 때 다른 제공업체와 비교하세요. 익숙한 구성을 쓰면 구현이 수월할 수 있지만, 그것이 전반적인 음성 우위를 증명하지는 않습니다.

정해진 음성이 없는 새 프로젝트라면 실제 대본에서 가장 까다로운 용어가 들어간 짧은 구절을 시험하세요. 두 결과물을 같은 장면에 넣어 비교하세요. 수용 기준을 충족하고 감당 가능한 비용이 검증된 쪽을 선택하세요. 대체 구성을 마련해 두고, 이에 의존하기 전에 실제 동작을 시험하세요.

실시간 비서, 음성 복제, 사용 빈도가 낮은 언어, 엄격한 방송 송출 기준을 다룬다면 별도의 평가를 진행하세요. 이 영어 영상 내레이션 예시는 그런 기능을 입증하지 않습니다. 사용 사례를 넓히려면 비교 제목에 더 강한 수식어를 붙일 것이 아니라 추가 근거를 확보해야 합니다.

실험을 반복 가능한 워크플로로 만들기

원본 텍스트, 모델 식별자, 음성, 형식, 생성 파일, 검토 결과를 하나의 기록으로 버전 관리하세요. 모델 별칭이 바뀌거나 음성을 변경했다면 새 구성으로 취급하세요. 과거에 성공한 테이크를 오늘의 모델 이름으로 조용히 바꿔 기록해서는 안 됩니다.

일괄 작업을 시작하기 전에 소규모 테스트 예산과 중단 조건을 정하세요. 경로에서 결과를 알 수 없는 시간 초과가 발생했다면 요청을 무작정 수십 번 재시도하지 말고 상태를 확인하세요. 두 옵션이 모두 기준을 통과했다면, 새로운 근거가 전환 비용을 정당화할 때까지 가장 간단하고 유지 관리하기 쉬운 워크플로를 사용하세요.

다음으로 유용한 테스트는 대개 근거 없는 기능 주장을 더 나열하는 것이 아니라, 실제 대본에서 가장 까다로운 문장이나 두 번째 대상 언어를 시험하는 것입니다. 이 샘플은 직접 확인할 수 있는 두 가지 출발점과 내레이션의 성공 여부를 판단하는 방법을 제공합니다.