ASR 생성 자막 vs 강제 정렬 (Forced Alignment): 스크립트 우선 방식의 자막이 실패가 적은 이유

자막 도구에서 제가 계속해서 목격하는 실수는 단순하지만 비용이 많이 드는 것입니다. 누군가 이미 승인된 스크립트(Script)를 가지고 있음에도 불구하고, 워크플로(Workflow)가 여전히 오디오를 다시 전사(Transcription)하는 것부터 시작한다는 점입니다.

저는 스크립트가 있는 보이스오버(Voiceover) 작업을 하면서 이 문제를 겪었습니다. 스크립트는 이미 검토가 완료된 상태였지만, 자막 도구는 여전히 오디오에서 단어를 추측하려고 했습니다.

처음에는 그것이 합리적으로 들릴 수 있습니다. 대부분의 캡셔닝(Captioning) 도구는 음성-텍스트 변환 (Speech-to-Text)을 중심으로 구축되어 있습니다. 오디오를 업로드하고, 단어를 얻고, 이를 자막으로 나누고, SRT 또는 VTT 파일을 내보내는 방식입니다.

하지만 스크립트가 있는 영상은 다른 문제입니다.

만약 스크립트가 이미 승인되었다면, ASR (Automatic Speech Recognition, 자동 음성 인식)이 진실의 근거 (Source of Truth)가 되어서는 안 됩니다. ASR은 타이밍 증거를 찾는 데 도움을 줄 수 있습니다. 불일치를 감지하는 데 도움을 줄 수 있습니다. 하지만 사용자가 이미 승인한 단어들을 조용히 다시 써서는 안 됩니다.

이것이 제가 스크립트 우선 (Script-first) 자막 워크플로를 구축하면서 고민해 온 차이점입니다.

흔한 실수: 승인된 스크립트를 다시 전사하는 것

많은 영상에서 스크립트는 오디오보다 먼저 존재합니다.

강의 레슨, 제품 워크스루 (Walkthroughs), YouTube 보이스오버, 현지화 검토, 클라이언트가 승인한 광고, 스튜디오 내레이션 등. 단어들은 미지의 것이 아닙니다. 그것들은 먼저 작성되었고, 검토되었으며, 그 후에 녹음되었습니다.

그러한 상황에서, 전사 우선 (Transcription-first) 자막 흐름은 불필요한 작업을 추가하고 새로운 위험을 생성합니다:

오디오 -> ASR 전사본 -> 자막 분할 -> 내보내기

일단 ASR 전사본이 진실의 근거 (Source of Truth)가 되면, 모든 후속 단계는 그 수정 사항을 그대로 물려받게 됩니다.

이는 최종 자막 파일이 승인된 스크립트와 작지만 짜증 나는 방식으로 달라질 수 있음을 의미합니다:

• 제품명이 변경됨
• API 용어가 정규화됨
• 숫자가 단어로 바뀌거나, 단어가 숫자로 바뀜
• 대소문자 구분이 사라짐
• 문장 부호가 단순화됨
• 도메인 특화 문구가 더 일반적인 문구로 바뀜

데모에서는 이러한 변화들이 극적으로 보이지 않을 수 있습니다. 하지만 실제 운영(Production) 환경에서는 자막 파일이 여러 곳으로 전달되기 때문에 이 문제가 중요해집니다. 자막 파일은 YouTube, 편집 타임라인(Editing timelines), 현지화 전달(Localization handoffs), 접근성 검사(Accessibility checks), 클라이언트 검토, 그리고 때로는 법적 또는 컴플라이언스(Compliance) 워크플로우로 흘러 들어갑니다.

승인된 스크립트(Script)가 단어의 주권을 가져야 합니다. 오디오는 오직 타이밍 증거(Timing evidence)만을 제공해야 합니다.

ASR이 잘하는 것

ASR은 매우 유용합니다. 이것은 "ASR이 나쁘다"는 주장이 아닙니다.

아직 단어를 모르는 상태라면 ASR이 올바른 기본값입니다:
오디오 -> 전사(Transcript)

이것이 일반적인 음성-텍스트 변환(Speech-to-text) 문제입니다. NVIDIA의 용어 사전(Glossary)은 음성-텍스트 변환을 구어(Spoken language)를 문어(Written text)로 변환하는 것으로 설명하며, 이는 회의, 인터뷰, 팟캐스트, 대본 없는 영상, 그리고 거친 메모(Rough notes)에 정확히 필요한 기능입니다.

ASR은 스크립트가 있는 워크플로우에서도 도움이 됩니다. 음향적 증거(Acoustic evidence), 대략적인 단어 타이밍, 신뢰도 신호(Confidence signals), 그리고 불일치 힌트(Mismatch hints)를 제공할 수 있습니다.

제가 중요하게 생각하는 경계는 더 좁습니다:

사용자가 스크립트를 제공할 때, 시스템은 ASR 출력을 해당 스크립트를 대체할 권한으로 취급해서는 안 됩니다.

강제 정렬(Forced alignment)이 실제로 하는 일

강제 정렬은 ASR의 반대 개념이 아닙니다.

이 점이 중요합니다. 많은 정렬 도구(Aligners)들이 내부적으로 여전히 ASR 모델이나 음향 모델(Acoustic models)을 사용합니다. 예를 들어, NVIDIA의 NeMo Forced Aligner는 CTC 기반의 ASR 모델을 사용하여 토큰(Token), 단어(Word), 세그먼트(Segment) 수준의 타임스탬프를 생성하며, 사용자가 제공한 참조 텍스트(Reference text)와 함께 작동할 수 있습니다. 핵심적인 차이점은 목표입니다: 새로운 텍스트를 생성하는 것인가, 아니면 오디오 내에서 이미 알고 있는 텍스트의 위치를 찾는 것인가의 차이입니다.

ASR은 오디오에서 텍스트를 복구(Recover)하려고 시도합니다.

강제 정렬은 오디오에서 제공된 텍스트의 위치를 찾으려고(Locate) 시도합니다.

단순화된 스크립트 우선(Script-first) 흐름은 다음과 같습니다:

승인된 스크립트 (Approved script)
-> 텍스트 정규화 (Text normalization)
-> 오디오 세그먼테이션 (Audio segmentation)
-> 강제 정렬 / 타이밍 증거 (Forced alignment / Timing evidence)
-> 불일치 탐지 (Mismatch detection)
-> 큐 생성 (Cue generation)
-> 큐 검증 (Cue validation)
-> 검토 이슈 표출 (Review issue surfacing)
-> SRT / VTT 내보내기 (Export)

제품 결정(Product decision)은 단순히 "어떤 모델을 사용할 것인가?"가 아닙니다.

제품 결정은 "누가 단어의 주권을 갖는가?"입니다.

스크립트 우선 (Script-first) 자막 시스템에서 정답은 지루할 정도로 엄격해야 합니다. 즉, 스크립트가 단어의 주권을 가져야 합니다.

자막에서 신뢰할 수 있는 정보원 (Source-of-truth)이 중요한 이유

전사 데이터 (Transcript)와 자막 에셋 (Subtitle asset) 사이에는 차이가 있습니다.

전사 데이터는 대략적일 수 있습니다. 사람이 훑어보거나, 검색하거나, 나중에 수정할 수 있기 때문입니다.

하지만 자막 에셋은 다른 시스템에 의해 소비되어야 합니다. 타임스탬프 (Timestamps)가 있고, 포맷팅 제약 (Formatting constraints)이 있으며, 줄 바꿈 (Line breaks)과 큐 경계 (Cue boundaries)가 있습니다. 비디오 플랫폼에 직접 업로드되거나, 준비가 완료되었다고 가정하는 다른 사람에게 전달될 수도 있습니다.

이러한 특성 때문에 신뢰할 수 있는 정보원 (Source-of-truth)에서 발생하는 실수는 더 큰 비용을 초래합니다.

만약 ASR (자동 음성 인식) 생성 자막이 "VTT"를 "VT"로 바꾸거나, "webhook"을 "web hook"으로 바꾼다면, 파일은 여전히 그럴싸해 보일 수 있습니다. 문제는 그럴싸하게 틀린 자막이 명백한 실패보다 잡아내기가 더 어렵다는 점입니다.

저는 텍스트를 조용히 깔끔하게 만드는 것보다, 불확실성을 드러내는 쪽을 택하겠습니다.

불확실성은 조용한 편집이 아니라 검토 (Review) 이슈가 되어야 합니다.

작은 실패의 사례

다음은 내보내기(Export)를 하기 전까지는 사소해 보이는 사례입니다.

원본 스크립트:
Deploy the VTT file after the webhook returns 200.

가능한 ASR 출력:
Deploy the VTT file after the web hook returns two hundred.

이것은 끔찍한 전사 데이터는 아닙니다. 사람은 이를 이해할 수 있습니다.

하지만 에셋이 변질되었습니다:

• webhook이 web hook이 됨
• 200이 two hundred가 됨
• 개발자 용어 (Developer wording)가 더 구어체적으로 변함

어떤 콘텐츠에서는 괜찮을 수 있습니다. 하지만 기술 튜토리얼, 문서 영상, 클라이언트가 승인한 내레이션, 또는 현지화 소스 파일 (Localization source file)의 경우, 이는 더 이상 동일한 텍스트가 아닙니다.

또한 전형적인 웃픈 사례도 있습니다:
Upload the SRT to YouTube Studio before 9:00.

이 다음과 같이 변하는 경우입니다:
Upload the shirt to YouTube studio before nine.

이 사례는 웃어넘기기 쉽지만, 더 현실적인 실패는 보통 완전히 잘못 듣는 것이 아닙니다. 정확한 어구 (Exact wording)가 서서히 소실되는 것입니다.

스크립트 우선 자막의 엔지니어링 문제

스크립트 우선 정렬 (Script-first alignment)은 단순해 보입니다:
스크립트 + 오디오 -> 타임스탬프 (Timestamps)

실제로 시스템이 보수적으로 접근해야 하는 몇 가지 지점이 있습니다.

텍스트 정규화 (Text normalization)가 재작성 (Rewriting)이 되어서는 안 됩니다

어느 정도의 정규화는 유용합니다. 구두점이 적은 텍스트, 소문자 형태, 숫자의 변형, 또는 토큰화된 단어들을 비교해야 할 수도 있습니다.

하지만 비교를 위한 형태가 곧 출력 형태가 되어서는 안 됩니다.

내보내기(Export)되는 자막은 사용자가 명시적으로 편집하지 않는 한 승인된 스크립트 텍스트를 그대로 유지해야 합니다. 정규화는 매칭을 돕는 용도여야 하며, 숨겨진 재작성 단계가 되어서는 안 됩니다.

오디오와 스크립트는 종종 미세하게 일치하지 않습니다

보이스오버 (Voiceover)는 인간이 합니다.

사람들은 작은 단어를 건너뛰거나, 구절을 추가하거나, 숫자를 다르게 읽거나, 실수한 문장을 다시 읽기도 합니다. 때로는 스크립트가 실제 녹음 내용과 정확히 일치하지 않는, 거의 최종본에 가까운 초안일 수도 있습니다.
시스템은 증거가 불분명할 때 어떻게 행동할지 결정해야 합니다.

저의 선호 방식은 다음과 같습니다:
제출된 스크립트를 보존한다
불확실한 구간 (Span)에 플래그를 표시한다
필요할 때 검토를 요청한다

유혹적인 지름길은 ASR 전사 (Transcript)를 사용하여 자막 텍스트를 "수정"하는 것입니다. 그렇게 하면 UI상으로는 더 매끄러워 보일 수 있지만, 신뢰할 수 있는 단일 출처 (Source-of-truth) 계약을 깨뜨리게 됩니다.

긴 오디오는 드리프트 (Drift)를 발생시킵니다

짧은 클립은 관대합니다. 45초짜리 데모는 타이밍이 약간 거칠어도 괜찮게 느껴질 수 있습니다.

하지만 긴 보이스오버는 관대하지 않습니다. 파일 초반의 작은 경계 오류가 나중에 나오는 큐 (Cue)들을 어긋나게 만들 수 있습니다. 긴 파일은 낙관적인 단 한 번의 통과 대신, 섹션 나누기, 로컬 체크, 그리고 최종 큐 검증 (Validation)이 필요합니다.

단어 타임스탬프 (Word timestamps)는 원재료이지, 자막 파일이 아닙니다

단어 수준의 타이밍은 유용하지만, 완성된 SRT 파일은 아닙니다.

자막에는 큐 경계 (Cue boundaries)가 필요합니다. 읽기 좋은 줄 바꿈이 필요합니다. 플레이어가 수용할 수 있는 타임스탬프가 필요합니다. 지속 시간과 읽기 속도에 대한 제약 조건이 필요합니다.

이 지점이 많은 "우리는 단어 타임스탬프를 가지고 있다"라는 데모들이 한계를 드러내는 부분입니다. 단어 타임스탬프는 재료입니다. 자막 파일은 완성된 제품입니다.

검증 (Validation): 불확실성을 검토 이슈로 전환하기

저는 검증기 (Validator)야말로 자막 시스템이 신뢰를 얻는 지점이라고 생각합니다.

최소한, 내보내기(export) 준비가 되었다고 판단하기 전에 다음과 같은 검사들을 수행하고 싶습니다:

• start_time < end_time (시작 시간 < 종료 시간)
• no overlapping cues (큐(cue) 중첩 없음)
• timestamps within audio duration (오디오 재생 시간 내의 타임스탬프)
• minimum cue duration (최소 큐 지속 시간)
• maximum cue duration (최대 큐 지속 시간)
• max characters per line (줄당 최대 글자 수)
• max lines per cue (큐당 최대 줄 수)
• reading speed limit (읽기 속도 제한)
• preserve approved script text (승인된 스크립트 텍스트 보존)
• detect skipped script spans (누락된 스크립트 구간 탐지)
• detect repeated script spans (반복된 스크립트 구간 탐지)
• flag low-confidence alignment spans (신뢰도가 낮은 정렬 구간 표시)
• flag audio-script mismatch (오디오-스크립트 불일치 표시)
• valid SRT / VTT timestamp formatting (유효한 SRT / VTT 타임스탬프 형식)

이 중 일부는 구조적인 검사이며, 일부는 가독성(readability) 검사이고, 일부는 소스 충실도(source-fidelity) 검사입니다.

스크립트 우선(script-first) 워크플로우에서 제가 가장 중요하게 생각하는 것은 소스 충실도 검사입니다. 만약 스크립트에 'webhook returns 200'이라고 적혀 있다면, 오디오 모델이 그렇게 처리하는 것이 더 쉽다는 이유만으로 내보낸 자막이 'web hook returns two hundred'로 바뀌어서는 안 됩니다.

신뢰도가 낮을 때 시스템은 아는 척을 해서는 안 됩니다. 대신 사용자에게 문제가 어디에 있는지, 그리고 왜 그것이 중요한지를 보여주어야 합니다.

그러한 검토 인터페이스(review surface)는 있으면 좋은 디버그 패널이 아니라, 제품의 일부입니다.

강제 정렬(Forced Alignment)이 적절한 도구가 아닌 경우

강제 정렬이 항상 정답인 도구는 아닙니다.

다음과 같은 경우에는 ASR을 사용하세요:

• 스크립트가 없는 경우
• 화자가 즉흥적으로 말하는 경우
• 오디오에 스크립트에 없는 질의응답(Q&A)이 포함된 경우
• 스크립트가 대략적인 개요 수준인 경우
• 여러 화자가 스크립트에서 크게 벗어나는 경우

다음과 같은 경우에는 스크립트 우선 정렬(script-first alignment)을 사용하세요:

• 스크립트가 승인된 경우
• 내레이션(voiceover)이 스크립트를 밀접하게 따르는 경우
• 정확한 문구가 중요한 경우
• 결과물이 단순한 전사(transcript)가 아닌 자막 에셋(subtitle asset)인 경우

이러한 구분이 도구를 정직하게 유지해 줍니다.

만약 오디오가 정말로 스크립트가 없는 상태라면, 이를 참조 텍스트에 강제로 맞추는 것은 또 다른 종류의 나쁜 결과를 초래합니다. 반대로 스크립트가 권위 있는 기준이라면, 이를 다시 전사하는 것은 피할 수 있는 텍스트 오염(text pollution)을 만드는 일입니다.

내가 이것을 TimedSubs에 구축하고 있는 이유

저는 이 워크플로우를 TimedSubs에 구축하고 있습니다:
스크립트 + 보이스오버 (voiceover) 오디오 -> 내보내기 전 QA를 거친 타임스탬프 자막 파일

이러한 좁은 범위 설정은 의도적인 것입니다. 저는 이것이 일반적인 전사 (transcription) 복제본이나 비디오 편집기가 되기를 원하지 않습니다. 유용한 부분은 바로 이 제약 조건에 있습니다. 스크립트가 제공될 때, 스크립트가 권위(authoritative)를 유지하며, 시스템은 오디오를 사용하여 타이밍 증거와 검토 신호를 생성합니다.

빌더들을 위한 체크리스트

만약 여러분이 캡션(captions) 또는 자막 도구를 구축하고 있다면, 저는 다음과 같은 질문을 던질 것입니다:

1. 시스템이 사용자가 승인된 스크립트를 가지고 있는지 알고 있는가?
2. 스크립트가 존재할 경우, 최종 자막 텍스트가 이를 보존하는가?
3. ASR 결과가 증거로 취급되는가, 아니면 대체 텍스트로 취급되는가?
4. 시스템이 건너뛰거나, 반복되거나, 스크립트 구간이 일치하지 않는 것을 감지할 수 있는가?
5. 긴 파일에서도 안정적으로 유지되는가, 아니면 시간이 지남에 따라 타이밍 드리프트 (timing drift)가 발생하는가?
6. 다운로드 전에 큐(cue) 레벨의 내보내기 차단 요소(export blockers)를 확인하는가?
7. 사용자가 왜 특정 세그먼트(segment)에 검토가 필요한지 확인할 수 있는가?

마지막 질문은 들리는 것보다 훨씬 더 중요합니다.

사람들은 "이 구간에 대해 확신할 수 없습니다"라고 말하는 시스템은 견딜 수 있습니다. 하지만 승인된 단어를 조용히 바꾸고 그 결과를 준비되었다고 말하는 시스템은 신뢰를 잃게 됩니다.

요점 (Takeaway)

ASR은 단어가 무엇인지 찾아내야 할 때 유용합니다.

강제 정렬 (Forced alignment)은 이미 단어를 알고 있고 타이밍이 필요할 때 유용합니다.

스크립트 기반의 비디오, 강의, 보이스오버, 그리고 로컬라이제이션 (localization) 워크플로우의 경우, 이 차이가 제품 설계 전체를 바꿉니다. 캡션 시스템은 승인된 스크립트를 아무렇지 않게 새로운 기계 전사 (machine transcript)로 바꿔버려서는 안 됩니다.

승인된 스크립트가 단어를 소유해야 합니다. 오디오는 오직 타이밍 증거만을 제공해야 합니다.

다른 분들은 실제 운영 워크플로우에서 이를 어떻게 처리하는지 궁금합니다. ASR 생성 자막을 소스로 신뢰하시나요, 아니면 승인된 스크립트를 유지하고 그에 맞춰 정렬하시나요?