AI 자막이 너무 빨리 읽히는 이유를 측정했습니다 — 문제는 문구가 아니라 타이밍이었습니다

AI 요약

전사 앱 ScribeToAny를 운영하는 작성자는 자막 QC 모드가 기계 생성 자막에서 ‘읽기 너무 빠름’을 자주 감지하자 원인을 측정했습니다. 자막 업계에서는 화면에 표시된 글자 수를 표시 시간으로 나눈 CPS(characters per second)를 읽기 속도 지표로 씁니다. 작성자가 소개한 Netflix 기준은 성인 영어 자막 20 CPS, 아동용 17 CPS이며 한 줄은 42자까지입니다.

측정 방법과 결과

작성자는 제품 영상의 영어 내레이션 2분 48초 분량, 447단어를 Whisper로 전사했습니다. 자막 생성 엔진과 같은 규칙으로 문장을 나눴습니다. 자막 하나는 84자 이하, 7초 이하로 만들고 문장 끝에서 끊었습니다. 각 자막을 확인하니 문구가 너무 길어서가 아니라 표시 시간이 너무 짧은 경우가 문제였습니다. 예를 들어 “Need more?”라는 짧은 자막은 0.36초만 노출돼 28 CPS가 됐습니다.

작성자는 17 CPS 기준을 모든 자막에 적용하려면 글자 수를 1.7% 줄여야 한다고 계산했습니다. 글을 다시 쓰기 전에 표시 시간을 먼저 조정하라는 것이 QC 도구가 안내해야 할 순서라고 설명합니다. ScribeToAny의 QC 모드는 CPS, 줄 길이, 지나치게 짧은 표시 시간을 알려주고, 사용자가 시간을 편집하거나 자막을 나누고 합칠 수 있게 합니다. 자동으로 시간을 늘리거나 문구를 고치지는 않습니다. 영상의 맥락을 보지 않고 자막 표시 시간을 바꾸면 사람이 판단할 부분까지 도구가 결정하게 된다는 이유입니다.

측정 범위와 후속 검증

댓글에서 작성자는 타이밍 조정만으로 해당 파일에서 17 CPS를 넘는 자막 비율이 68%에서 24%로 줄었다고 덧붙였습니다. 다만 이는 단일 테스트 결과이며, 편집 시간이나 실제 사용자 작업량이 줄었다는 데이터는 없다고 밝혔습니다. 130 WPM과 190 WPM 음성으로 다시 측정해 말하기 속도가 결과에 미치는 영향을 확인할 계획입니다.

Indie Hackers 반응

• @kevinbai — 측정이 탄탄하고, 단어를 고치기 전에 타이밍을 보는 순서도 맞습니다. QC 결과에 파일 전체의 실제 발화 CPS와 목표 읽기 한도의 비율도 표시하면 좋겠습니다. 447단어를 2분 48초에 말하면 약 160 WPM으로 내레이션치고 빠릅니다. 같은 자막 분할 규칙을 135 WPM 음성에 적용하면 17 CPS를 넘는 자막이 훨씬 줄어듭니다. “한도의 68% 초과”만 보면 타이밍 문제인지 말하는 사람이 빠른 건지 알기 어렵습니다. 실제 발화 CPS를 한도 옆에 표시하면 타이밍 조정으로 얼마나 여유를 확보할지도 가늠할 수 있습니다. 발화 CPS가 한도에 가깝다면 자막을 무음 구간까지 늘리고 짧은 자막끼리 합쳐 초과분 대부분을 흡수할 수 있습니다. 68%에서 24%로 줄어든 결과가 바로 그 경우입니다. 발화 CPS가 한도보다 훨씬 높다면 타이밍 조정만으로 해결되지 않아 글자를 줄여야 합니다. 비율을 보면 편집을 시작하기 전에 어느 쪽인지 알 수 있습니다.
• @fred_abila — 저희도 같은 결과를 봤습니다. 단어가 말로 나오는 시점이 아니라 읽기 속도에 맞춰 자막 시간을 정하면 ‘너무 빠르다’는 불만 대부분이 사라집니다. 저희가 효과를 본 규칙은 초당 약 17자, 아동·학습자용은 15자, 최소 표시 시간 약 1초, 최대 6~7초, 최대 두 줄에 한 줄당 약 42자입니다. 자막 사이에는 눈이 바뀐 것을 알아차리도록 2프레임 정도 간격을 둡니다. 다음 자막이 허용하면 음성이 끝난 뒤에도 자막을 조금 더 띄웁니다. 자막 시작과 끝이 장면 전환 시점에서 10프레임 이내라면 그 시점에 맞춥니다. CPS가 적절해도 장면 전환을 가로지르는 자막은 급하게 느껴집니다. 줄은 구절 경계에서 나누고 구절 중간은 피합니다. ASR의 단어 단위 타임스탬프는 시작 시점에 유용하지만, 끝 시점은 읽기 속도 계산으로 정해야 합니다.
• @James_UtilitySEO — 이 측정이 핵심입니다. 자막 속도를 점검하는 사람 대부분은 자막 하나의 단어 수부터 보므로 문제를 문구에서 찾습니다. 실제 발화 속도와 CPS를 비교하면 변수가 분리됩니다. 문구는 괜찮고 표시 구간이 문제입니다. 최소 표시 시간을 늘리는 방법은 내용에 손대지 않고 문구가 화면에 머무는 시간만 바꿉니다. 저희 사이트 감사 도구에서도 비슷한 일이 있습니다. 페이지가 400ms 만에 로드돼도 측정 구간이 로드의 잘못된 단계를 잡으면 성능 검사를 통과하지 못합니다. 지표와 측정 대상은 모두 맞아도 둘의 정렬이 어긋난 셈입니다. 구체적인 발견에 비해 댓글 네 개뿐인 점이 아쉽습니다.
• @linglistack — 측정이 좋습니다. 한도 초과 비율과 함께 자막별 CPS의 90백분위수도 보고하면 좋겠습니다. 초과 비율이 낮아도 30 CPS가 넘는 자막 몇 개가 있으면 파일이 잘 읽힌다고 보기 어렵습니다. 표본도 함께 봐야 합니다. 447단어를 2분 48초에 말하면 약 160 WPM이고, 발화 속도는 큰 교란 요인입니다. 130 WPM과 190 WPM 파일에서도 다시 측정하면 68%라는 기준값이 안정적인지, 말하는 속도에 따라 달라지는지 알 수 있습니다.
  • @raymac — 두 가지 모두 좋은 지적입니다. 결과가 극단적인 30 CPS 이상 자막 몇 개를 숨기지 않도록 자막별 CPS 90백분위수도 추가하겠습니다. 447단어를 2분 48초에 말하면 약 160 WPM이므로 68%는 보편적인 기준값이 아니라 단일 테스트 결과로 봐야 합니다. 발화 속도에 따라 효과가 얼마나 달라지는지 보려고 약 130 WPM과 190 WPM으로 다시 측정하겠습니다.
• @raymac — 타당한 지적입니다. 아직은 폭넓은 사용자 검증을 마친 생산성 주장이라기보다 한 번 측정한 결과로 설명하겠습니다. 편집 시간이 얼마나 줄었는지 보여주는 데이터는 없습니다. 해당 파일에서는 단어를 삭제하지 않고 타이밍만 바꿔 17 CPS를 넘는 자막 비율을 68%에서 24%로 낮췄습니다. 타이밍을 먼저 조정하면 불필요한 문구 수정을 줄일 수 있다는 뜻입니다. 실제 사용자 프로젝트에서 편집 횟수와 완료 시간이 줄어드는지 확인하는 것이 다음 단계입니다.
• @aryan_sinh — 실제 사용자에게서 자막 타이밍을 먼저 고치면 편집 부담이 줄어든다는 결과를 얻었나요? 아니면 아직 본인의 테스트 사례에서 나온 발견인가요?

원문: Indie Hackers / 번역·요약: Trawling