발표자:
- 이재황, 박찬규 (CJ ENM Mnet Plus, Platform Engineering)
- 임윤택 (AWS Solutions Architect)
글로벌 K-POP 라이브가 직면한 언어 장벽
Mnet+의 K-POP 라이브는 대부분 한국어로 진행된다. 하지만 시청자의 상당수가 해외 팬이다.
실제 라이브 방송 중에는 채팅창에 다양한 언어로 다음과 같은 메시지가 반복적으로 올라왔다.
"지금 뭐라고 했어요?"
"방금 내용 번역해주세요."
즉, 콘텐츠 자체보다도 언어 장벽이 사용자 경험(UX)을 저해하는 핵심 문제로 작용하고 있었다.
초기에는 속기사 기반 자막 시스템을 운영했지만, 글로벌 서비스를 확장하기에는 한계가 명확했다.
속기사 기반 자막 시스템의 한계
1. 실시간 운영의 어려움
속기사가 단순히 내용을 입력하는 것만으로 끝나지 않았다.
- 자막 시스템 사용 방법을 숙지해야 함
- 방송 싱크를 맞추기 위한 별도 모니터링 인력 필요
- 라이브 상황에 따라 지속적인 운영 개입 필요
2. 높은 운영 비용
지원 언어가 늘어날수록 비용이 선형적으로 증가했다.
비용 = 지원 언어 수 × 방송 시간 × 운영 인력
3. 확장성 부족
영어, 일본어, 중국어를 동시에 실시간 제공하는 구조를 인력만으로 운영하는 것은 사실상 불가능했다.
이러한 이유로 Mnet+는 AI 기반 실시간 자막 시스템 구축을 추진하게 되었다.
시스템 아키텍처 (System Architecture Overview)
발표에서는 AWS의 미디어 서비스와 AI 서비스를 조합한 이벤트 기반 아키텍처를 소개했다.
라이브 방송 영상은 MediaConnect, MediaLive, MediaPackage를 통해 송출되며, 오디오 세그먼트는 S3와 SQS 기반 이벤트 파이프라인을 통해 처리된다.
이후 EKS 기반 애플리케이션이 자막 처리 워크플로를 수행하며, Amazon Transcribe를 활용해 음성을 텍스트로 변환하고 Amazon Bedrock을 통해 자막 정제 및 다국어 번역을 수행한다. 생성된 자막은 데이터베이스에 저장된 뒤 클라이언트에 제공된다.
발표에서는 S3와 SQS를 활용한 이벤트 기반 비동기 처리 구조를 강조했다.
각 컴포넌트는 서로 강하게 결합되지 않으며, 독립적으로 스케일 아웃할 수 있도록 설계되었다.
또한 실제 운영 환경에서는 장애 대응을 위해 메인 파이프라인과 백업 파이프라인을 동시에 운영하고 있다.
“완전한 실시간”보다 중요한 것
발표 중 인상적이었던 부분은 지연(Latency)에 대한 솔직한 설명이었다.
AI 자막 시스템은 다음 단계들을 거쳐야 한다.
- 음성 수집
- STT 변환
- LLM 정제 및 번역
- HLS 전송
- 클라이언트 렌더링
따라서 다음과 같은 지연이 누적된다.
STT 지연
+ LLM 처리 지연
+ HLS 지연
결국 사용자 경험을 결정하는 핵심은 AI 사용 여부가 아니라, '얼마나 지연 시간을 줄일 수 있는가' 라는 점을 강조했다.
장애 상황을 고려한 Fallback 설계
라이브 서비스에서는 품질보다 먼저 안정성이 요구된다.
발표에서는 자막 시스템 설계 원칙을 다음 세 가지로 설명했다.
- 자막이 끊기지 않을 것
- 중복 자막이 노출되지 않을 것
- 부적절한 표현이 노출되지 않을 것
라이브 자막은 잘 동작할 때는 존재감이 없지만, 한 번이라도 잘못 출력되면 즉시 사용자에게 노출된다. 따라서 안정성을 최우선 목표로 설계했다고 설명했다.
방송 송출 파이프라인 이중화
발표에서는 자막 시스템뿐 아니라 라이브 영상 송출 자체도 장애에 대비해 이중화되어 있다고 설명했다.
방송 송출 경로는 단일 파이프라인에 의존하지 않는다.
각각 독립적인 MediaLive → MediaPackage → S3 경로를 구성하고 있으며, 두 파이프라인의 결과는 CloudFront를 통해 사용자에게 전달된다.
사용자는 직접 MediaPackage 엔드포인트에 접근하지 않고 CloudFront만 바라보기 때문에, 특정 송출 경로에 장애가 발생하더라도 서비스는 백업 경로로 전환될 수 있다.
발표에서는 이를 “자동 백업 전환” 구조라고 설명했으며, 라이브 방송 중 장애가 발생하더라도 시청자가 최대한 이를 인지하지 못하도록 설계했다고 소개했다.
이러한 스트리밍 인프라 이중화는 라이브 서비스의 안정성을 위한 첫 번째 방어선이었다. 발표에서는 이와 함께 STT와 번역 파이프라인에도 각각 별도의 장애 대응 전략을 적용했다고 설명했다.
STT Fallback
기본 STT 엔진에 장애가 발생할 경우 즉시 Amazon Transcribe로 전환된다.
흥미로웠던 점은 재시도를 거의 하지 않는다는 것이다.
일반적인 백엔드 시스템에서는 재시도를 통해 복구를 시도하지만, 라이브 서비스에서는 재시도 자체가 지연으로 이어진다.
따라서 다음과 같은 정책을 사용했다.
실패 감지
→ 즉시 Fallback
→ 서비스 지속
또한 운영자가 콘솔에서 직접 STT 엔진을 변경할 수 있는 기능도 제공한다.
Bedrock LLM Fallback
STT를 통해 텍스트가 생성된 이후에는 정제 및 번역 단계가 이어진다.
정제 및 번역(Refine & Translate) 기능은 별도의 비동기 파이프라인으로 구성되어 있다.
STT 결과가 생성되면 S3에 저장되고, 이후 SQS를 통해 EKS Consumer가 이벤트를 수신한다. EKS는 프롬프트 생성과 Amazon Bedrock 호출을 담당하며, 정제된 원문과 다국어 번역 결과를 생성한다.
이러한 구조를 통해 정제 및 번역 처리량이 증가하더라도 EKS Consumer를 독립적으로 확장할 수 있으며, Bedrock 호출 로직 역시 애플리케이션 레벨에서 제어할 수 있도록 설계했다.
이처럼 정제·번역 파이프라인을 독립적으로 구성한 뒤, LLM 계층에도 별도의 장애 대응 전략을 적용했다.
라이브 방송 시간에는 다른 서비스가 Bedrock 리소스를 과도하게 사용하지 못하도록 자막 전용 리소스를 우선 할당한다.
그럼에도 예상치 못한 스로틀링 상황을 고려해 Circuit Breaker 패턴을 적용했다.
Circuit Breaker 패턴이란
Circuit Breaker는 외부 서비스(예: Bedrock)가 연속으로 실패하면 추가 요청을 일시적으로 차단하는 패턴이다. 장애가 발생한 서비스에 계속 요청하지 않고, Fallback 모델이나 대체 경로로 즉시 전환해 서비스 중단을 방지한다. 일정 시간이 지난 뒤 일부 요청으로 복구 여부를 확인하고, 정상화되면 다시 원래 서비스로 복귀한다.
동작 방식
연속 실패 발생
↓
임계치 초과
↓
Circuit Open
↓
Fallback LLM 전환이를 통해 장애 상황에서도 자막 생성 자체는 지속될 수 있도록 설계했다.
장애 상황에서 자막 생성이 중단되지 않도록 하는 것과 별개로, 실시간 이벤트 기반 구조에서는 동일 자막이 여러 번 생성될 가능성도 고려해야 했다.
중복 자막 문제 해결
실시간 이벤트 처리 시스템에서는 중복 처리 문제가 자주 발생한다.
이번 사례에서도 두 가지 원인이 존재했다.
1. SQS의 At-Least-Once Delivery
동일 이벤트가 여러 번 전달될 수 있다.
2. 메인/백업 파이프라인 동시 운영
동일한 오디오 세그먼트를 두 파이프라인이 동시에 처리할 수 있다.
3단계 중복 방지 전략
1. Redis 분산락
세그먼트 키를 기준으로 Redis Lock을 획득한 컨슈머만 처리한다.
Lock 획득 성공
→ 처리
Lock 획득 실패
→ Skip2. 자동 페일오버
일정 시간 동안 메인 세그먼트가 도착하지 않으면 백업 자막을 사용한다.
3. 복구 후 중복 방지
메인이 복구되었을 때는 백업이 마지막으로 처리한 시점을 기준으로 버퍼를 더한 뒤, 그 이후 세그먼트만 처리한다.
이를 통해 장애 복구 과정에서도 중복 자막 노출을 방지했다.
자막 품질 개선을 위한 3-Layer Prompt 구조
초기 QA 과정에서는 다음과 같은 문제가 발견되었다.
1. K-POP 고유 명사 오표기
- 아티스트 이름
- 프로그램명
- 팬덤명
등이 잘못 변환되는 경우가 많았다.
2. Hallucination
실제로 존재하지 않는 숫자나 단어가 생성되는 문제가 발생했다.
3. 음악 효과 표현 오류
예를 들어 슬픈 배경음악이 나오는데, “신나는 노래가 재생 중” 처럼 잘못 해석되는 사례가 발생했다.
해결 방법
STT 결과를 바로 번역하지 않고, 아래와 같은 과정을 거치도록 설계했다.
STT
↓
정제(Cleaning)
↓
번역Layer 1. System Prompt
LLM의 행동 범위를 제한하는 규칙이다.
주요 규칙은 다음과 같다.
- 자막만 출력할 것
- 이해할 수 없으면 빈 문자열 반환
- 부적절한 표현 마스킹
특히 “이해할 수 없으면 빈 문자열 반환” 규칙은 환호성이나 음악 구간에서 억지 번역이 발생하는 문제를 줄이는 데 효과적이었다.
Layer 2. Custom Prompt
방송 담당자가 CMS에서 직접 설정하는 프롬프트다.
예를 들어 다음 정보를 사전에 입력할 수 있다.
- 신곡 가사
- 특별 게스트 정보
- 팬덤 용어
- 방송 특수 용어
이를 통해 라이브별 문맥(Context)을 제공했다.
Layer 3. Live Metadata Prompt
방송 메타데이터를 자동으로 주입한다.
포함되는 정보는 다음과 같다.
- 방송 제목
- 아티스트 이름
- 방송 소개글
예를 들어 메타데이터가 없을 때는
M COUNTDOWN
→ "m 카드 카운트 다운"처럼 오인식되었지만,
메타데이터를 함께 제공한 뒤에는 프로그램명으로 정확하게 해석할 수 있게 되었다.
비용 최적화 전략
AI 자막 시스템을 운영하면서 예상보다 크게 증가한 비용 요소는 입력 토큰이었다.
특히 모든 요청에 프롬프트를 함께 전송하다 보니 토큰 사용량이 빠르게 증가했다.
이를 해결하기 위해 두 가지 전략을 적용했다.
1. Prompt Caching
고정적으로 반복되는 시스템 프롬프트를 캐싱했다.
매 세그먼트마다 동일한 프롬프트를 반복 전송하지 않도록 하여 입력 토큰 비용을 줄였다.
2. 다국어 번역을 단일 호출로 통합
초기 방식은 언어별 API 호출 구조였다.
한국어 → 영어
한국어 → 일본어
한국어 → 중국어지원 언어가 늘어날수록 호출 수도 함께 증가했다.
이를 다음과 같이 변경했다.
한국어 정제
+ 영어 번역
+ 일본어 번역
+ 중국어 번역
= 1회 호출이 방식은 비용 절감뿐 아니라 동일한 문맥에서 여러 언어를 생성하기 때문에 번역 일관성 향상에도 도움이 되었다.
실제 운영 결과와 향후 과제
이러한 아키텍처 개선과 비용 최적화 전략을 적용한 뒤 실제 서비스에 배포했고, 이후 3개월간 사용자 피드백을 수집했다.
배포 후 3개월 동안 수집한 사용자 피드백은 언어권별로 차이가 있었다.
- 영어권 사용자
- 의미 전달에 대한 만족도는 높았다.
- 반면 자막이 음성과 정확히 맞지 않는 싱크 문제에 대한 개선 요청이 많았다.
- 일본어권 사용자
- 싱크보다는 문장 자연스러움에 대한 요구가 더 많았다.
- 즉, 언어권마다 품질을 판단하는 기준이 달랐다.
마무리
이번 세션에서 흥미로웠던 점은 AI 모델 자체보다도 라이브 서비스 운영 관점의 설계에 초점이 맞춰져 있었다는 점이다.
발표의 핵심은 단순히 “Bedrock으로 번역했다”가 아니라,
- 장애 발생 시 어떻게 자막을 지속 제공할 것인가
- 중복 자막을 어떻게 방지할 것인가
- 실시간성과 품질 사이의 균형을 어떻게 맞출 것인가
- LLM 비용을 어떻게 통제할 것인가
와 같은 실제 운영 환경의 문제를 어떻게 해결했는지에 있었다.
발표는 현재 성과뿐 아니라 앞으로 해결해야 할 과제도 함께 공유하며 마무리되었다.
향후 과제로는 자막 품질을 정량적으로 측정할 수 있는 지표 구축, 한국 문화 특화 표현 처리, 할루시네이션 최소화, 엔드투엔드 지연 단축, 자막 싱크 정확도 향상, 그리고 화자 분류 기능 추가 등을 제시하며 발표를 마무리했다.
