faster-whisper로 AI 내레이션 받아 적기: 자막(SRT) 만들고 대본과 맞춰 발음 검사하기

기준: faster-whisper 1.2.1(Windows, CPU), 공식 README와 YouTube 고객센터 자막 파일 형식 안내. 2026년 11월 4일에 확인했습니다. 그림 1·2는 직접 돌린 결과를 표와 막대로 옮긴 도표, 그림 3은 형식을 보이려고 지어낸 예, 그림 4는 공식 페이지 화면입니다. 예로 쓴 내레이션은 아직 공개하지 않은 영상의 것이라 대본 글은 싣지 않았습니다.

AI 목소리로 내레이션을 만들면 사람이 녹음하는 것보다 빠르지만, 한 가지 일이 남습니다. AI가 대본을 제대로 읽었는지 확인하는 일입니다. 숫자를 엉뚱하게 읽거나, 비슷한 소리의 다른 낱말로 들리게 읽는 일이 생각보다 자주 생깁니다. 10분짜리 내레이션을 귀로만 처음부터 끝까지 확인하기는 어렵습니다.

이 글에서는 faster-whisper라는 무료 받아 적기 도구로 내레이션을 글자로 바꾼 뒤, 대본과 한 줄씩 맞춰 보며 이상한 곳만 골라 듣는 방법을 따라 합니다. 받아 적은 결과는 그대로 **자막 파일(SRT)**이 되니, 유튜브 자막도 함께 얻습니다. 예로 쓰는 소리는 AI 목소리로 만든 한국어 해설의 앞 60초입니다.

이 글을 마치면 아래를 할 수 있습니다.

1. faster-whisper로 소리 파일을 받아 적어 SRT 자막 파일을 만듭니다.
2. small과 medium 모델의 정확도와 걸리는 시간 차이를 구분합니다.
3. 받아 적은 글과 대본을 맞춰 잘못 읽힌 낱말을 찾습니다.
4. 잘못 읽힌 줄을 고치는 대본 쪽 방법을 씁니다.

1. 받아 적기로 검사하는 까닭

받아 적기(음성 인식, speech-to-text)는 소리를 듣고 글자로 바꾸는 일입니다. 받아쓰기 시험과 같습니다. 선생님(AI 목소리)이 읽은 문장을 학생(받아 적기 도구)이 받아 쓰고, 우리는 답안지(대본)와 맞춰 봅니다.

이 방법이 쓸모 있는 까닭은 틀린 곳이 글자 차이로 드러나기 때문입니다. 받아 적기 도구가 대본과 다른 낱말을 적었다면, AI 목소리가 그 낱말을 또렷하지 않게 읽었을 가능성이 있습니다. 10분을 다 듣는 대신, 글자가 다른 몇 곳만 골라 귀로 들으면 됩니다.

다만 받아 적기 도구도 틀립니다. 글자가 다르다고 곧 목소리가 틀린 것은 아닙니다. 그래서 순서는 언제나 **"글자로 후보를 고르고, 귀로 판정한다"**입니다.

2. faster-whisper: Whisper를 빠르게 돌리는 판

Whisper는 OpenAI가 공개한 받아 적기 모델이고, faster-whisper는 그 모델을 CTranslate2라는 실행 엔진으로 다시 만든 판입니다. 공식 README는 같은 정확도에서 원래 판보다 최대 4배 빠르고 메모리를 덜 쓴다고 소개합니다(그림 4). 같은 요리법을 더 좋은 주방 기구로 만드는 것과 비슷합니다. 맛(정확도)은 같고 시간이 줄어듭니다.

그림 4. faster-whisper 공식 저장소의 첫 화면 (GitHub 화면 캡처)

GPU가 있어도 위 라이브러리가 없으면 GPU로 돌지 않습니다. 제 PC에도 NVIDIA 그래픽카드가 있지만 cuBLAS 파일(cublas64_12.dll)을 찾지 못한다는 오류로 GPU 실행이 실패했고, 그래서 아래 시험은 모두 CPU로 돌렸습니다. CPU에서는 compute_type="int8"을 주면 숫자를 줄여 계산해 더 빨라집니다. 숫자를 반올림해 암산하는 것처럼, 아주 조금 덜 정밀한 대신 빠릅니다.

3. 받아 적기 스크립트

시작 전에: 파이썬이 깔린 PC에서 명령 창에 pip install faster-whisper를 입력해 설치합니다. 소리 파일을 자르려면 무료 도구 ffmpeg도 있으면 편합니다.

따라 하기:

1. 내레이션 파일의 앞 60초만 잘라 시험용 파일을 만듭니다. 처음부터 긴 파일을 돌리면 결과를 기다리는 시간이 깁니다.

   ffmpeg -i narration.mp3 -t 60 -ac 1 -ar 16000 clip60.wav
   

   -t 60은 60초만, -ac 1은 모노, -ar 16000은 1초에 16,000번 기록하는 소리로 바꾸라는 뜻입니다. Whisper는 16 kHz 소리를 쓰므로 미리 맞춰 두면 깔끔합니다.

2. 아래 내용을 fw.py로 저장합니다. 모델 이름, 소리 파일, 결과 이름을 받아 SRT 파일을 씁니다.

   import sys, time
   from faster_whisper import WhisperModel
   
   size, src, out = sys.argv[1], sys.argv[2], sys.argv[3]
   t0 = time.time()
   model = WhisperModel(size, device="cpu", compute_type="int8")
   t1 = time.time()
   segments, info = model.transcribe(src, language="ko", word_timestamps=True)
   segments = list(segments)
   t2 = time.time()
   
   def ts(s):
       h, m, sec = int(s // 3600), int(s % 3600 // 60), s % 60
       return f"{h:02d}:{m:02d}:{int(sec):02d},{int(round((sec - int(sec)) * 1000)):03d}"
   
   with open(out + ".srt", "w", encoding="utf-8") as f:
       for i, s in enumerate(segments, 1):
           f.write(f"{i}\n{ts(s.start)} --> {ts(s.end)}\n{s.text.strip()}\n\n")
   print(size, "load", round(t1 - t0, 1), "transcribe", round(t2 - t1, 1))
   

3. 명령 창에서 small 모델부터 돌립니다.

   python fw.py small clip60.wav narration_small
   

4. 같은 파일을 medium 모델로 한 번 더 돌립니다.

   python fw.py medium clip60.wav narration_medium
   

처음 돌릴 때는 모델 파일을 인터넷에서 받아 오므로 시간이 더 걸립니다. 두 번째부터는 받은 파일을 다시 씁니다.

language="ko"는 한국어라고 미리 알려 주는 값입니다. 빼면 앞부분을 듣고 언어를 스스로 고르는데, 짧은 파일에서는 잘못 고를 수 있으니 알고 있으면 넣으세요. word_timestamps=True는 낱말마다 시각을 받는 값입니다. 자막에는 문장 조각 시각만 쓰지만, 나중에 영상의 컷을 낱말 끝에 맞출 때 쓸모가 있습니다.

4. 결과: small과 medium 견주기

그림 1은 대본과 두 모델의 결과를 줄마다 맞춰 보고, 뜻이나 철자가 다른 곳이 몇 군데인지와 어떤 꼴로 틀렸는지만 적은 표입니다. 숫자를 숫자로 적었는지 글자로 적었는지 같은 적는 방식 차이와 띄어쓰기 차이는 세지 않았습니다.

그림 1. 앞 60초(13줄)에서 대본과 다르게 받아 적은 곳의 수와 종류. 빨간 칸이 다른 곳입니다 (도표)

두 모델의 차이에서 알 수 있는 것이 있습니다. small이 틀린 다섯 곳은 medium이 모두 맞게 적었습니다. 그러니 small의 실수는 목소리 탓이 아니라 받아 적기 쪽 실수입니다. 특히 숫자를 틀리게 적은 것이 위험합니다. 대본 검사에 small을 쓰면 멀쩡한 숫자를 틀렸다고 의심하거나, 반대로 자막에 틀린 숫자가 들어갈 수 있습니다.

medium이 다르게 적은 세 곳은 "의/에", "내/네"처럼 우리말에서 소리가 거의 같은 글자입니다. 목소리가 틀렸다기보다 소리만으로는 가리기 어려운 곳입니다. 이런 곳은 귀로 한 번 듣고 넘어가면 됩니다.

5. 걸린 시간

그림 2. 60초 소리를 받아 적는 데 걸린 시간. 제 PC(Intel Core i9-14900HX, CPU int8)에서 잰 값이고 모델을 불러오는 시간은 뺐습니다 (도표)

제 PC에서 small은 60초 소리를 48.0초에, medium은 231.3초에 받아 적었습니다. medium이 약 4.8배 느립니다. 모델을 불러오는 데도 small 8.2초, medium 21.3초가 따로 걸렸습니다.

이 비율로 어림하면, 10분짜리 내레이션은 CPU의 medium으로 40분 가까이 걸립니다. 기다리는 동안 다른 일을 하면 되니, 정확도가 중요한 검사에는 medium을 권합니다. 빨리 대강 보고 싶을 때만 small을 쓰세요. 시간은 CPU, 소리의 길이와 말 빠르기에 따라 달라지므로 여러분 PC에서는 짧은 파일로 먼저 재 보는 것이 가장 정확합니다.

6. SRT 자막 파일 읽는 법

스크립트가 쓴 narration_medium.srt를 메모장으로 열면 그림 3과 같은 꼴입니다. 그림 3은 형식을 보이려고 지어낸 문장으로 만든 예입니다.

그림 3. SRT 파일의 꼴. 형식을 보이려고 지어낸 문장 세 묶음입니다 (도표)

SRT(SubRip)는 가장 단순한 자막 파일 형식입니다. 영화관 매표소의 상영 시간표처럼, 무엇이 언제 시작해 언제 끝나는지만 적습니다.

YouTube 고객센터의 자막 파일 형식 안내에는 SubRip(.srt)이 기본 형식으로 올라 있습니다. 꾸밈 정보는 읽지 않고, 파일은 UTF-8로 저장해야 합니다. 위 스크립트는 encoding="utf-8"로 저장하므로 한글이 깨지지 않습니다. 메모장에서 고쳐 저장할 때도 인코딩이 UTF-8인지 확인하세요.

받아 적은 SRT를 그대로 올리면 자막 글자가 대본과 조금 다릅니다(그림 1의 "의/에" 바꿔 적기처럼). 올리기 전에 대본을 보고 글자를 고쳐 두면, 시각은 받아 적기가 맞춰 준 것을 쓰고 글자는 대본대로 쓸 수 있습니다.

7. 잘못 읽힌 줄 고치기

글자로 후보를 골랐으면 그 줄만 귀로 듣고 판정합니다. 목소리가 정말 틀리게 읽었다면 고칠 곳은 AI 목소리에 넣는 글입니다. 같은 내레이션 105줄 전체를 medium으로 받아 적어 검사했을 때, 다시 만든 줄은 7줄이었습니다. 틀린 꼴과 고친 방법은 아래와 같습니다.

7줄 가운데 3줄은 한 번에 고쳐졌고, 2줄은 두 번째 판을 썼고, 2줄은 고쳐도 낫지 않아 처음 판을 그대로 썼습니다.

고치는 요령은 세 가지입니다.

• 띄어 쓰거나 쉼표를 넣어 낱말 경계를 분명히 합니다. 붙어 있는 소리가 다른 낱말로 뭉개지는 것을 막습니다.
• 조사나 낱말을 하나 더해 앞뒤 뜻을 분명히 합니다. 화면 자막은 대본 그대로 두고, 목소리에 넣는 글만 바꿉니다.
• 고치다 나빠지면 처음 판으로 돌아갑니다. 위 표의 여섯째 줄처럼 쉼표를 빼자 오히려 다른 낱말로 들렸습니다. 한 줄에 두 번까지만 고쳐 보고, 그래도 안 되면 귀로 듣고 괜찮은지 판정합니다.

숫자를 목소리에 넣을 때 미리 소리 나는 대로 풀어 쓰는 요령(예: "30분" → "삼십 분")과 대본 길이를 맞추는 법은 AI 내레이션 대본 길이 맞추기에 따로 정리했습니다.

연습 문제

1. 여러분 목소리로 30초를 녹음해 small과 medium으로 받아 적고, 두 결과에서 다른 낱말이 몇 곳인지 세어 보세요.
2. 같은 파일을 language="ko"를 빼고 돌려, 첫 줄의 언어를 무엇으로 골랐는지 확인합니다.
3. 받은 SRT 파일의 두 번째 묶음 끝 시각을 0.5초 늦추고, 다른 묶음과 겹치지 않는지 보세요.

자주 하는 실수와 해결

한 줄 정리

faster-whisper medium으로 받아 적어 SRT를 얻고, 대본과 글자가 다른 줄만 골라 귀로 듣고, 틀린 줄은 목소리에 넣는 글만 띄어쓰기·쉼표·낱말 하나로 고치기.

다음에는 AI 내레이션 대본 길이 맞추기에서 대본을 쓸 때부터 실제 말 길이를 맞추는 법을 봅니다.

참고 자료

• faster-whisper 공식 저장소(README, 설치·GPU 요구 사항·int8 예시·word_timestamps·vad_filter): https://github.com/SYSTRAN/faster-whisper
• YouTube 고객센터, 지원되는 자막 파일 형식: https://support.google.com/youtube/answer/2734698
• 함께 읽기: AI 내레이션 대본 길이 맞추기, 영상 코덱 기초, Blender 비디오 시퀀서 기초
• 그림 라이선스: 그림 1·2는 직접 돌린 결과를 옮긴 도표, 그림 3은 지어낸 문장으로 만든 형식 예, 그림 4는 공식 페이지 화면을 설명용으로 일부 실었습니다.