Tencent Cloud MPS (Media Processing Service)

들어가기 전에

Tencent Cloud 미디어 제품들을 보다 보면 비슷한 기능이 여기저기서 반복해서 나온다. VOD에서도 트랜스코딩이 있고, CSS에서도 라이브 트랜스코딩이 있고, StreamLive에서도 채널 출력 포맷을 바꾼다. 자막 생성, 콘텐츠 모더레이션, 화질 개선 같은 기능도 제품마다 조금씩 다른 이름으로 등장한다. 처음 보면 제품마다 별도의 처리 엔진을 가진 것처럼 보이지만, 실제로는 뒤쪽에 공통 처리 레이어가 있다고 보는 편이 이해하기 쉽다. 그 역할을 하는 서비스가 MPS(Media Processing Service)다. 결론부터 말하면 MPS는 "업로드된 미디어 파일을 클라우드에서 가공하는 서비스"다. 트랜스코딩, 패키징, 썸네일 추출, 화질 개선, 음질 개선, 자막 생성, 콘텐츠 분석, 품질 검사 같은 작업을 하나의 처리 파이프라인으로 묶어준다. 이게 핵심이다. MPS는 플레이어도 아니고 CDN도 아니다. 영상을 받아서 시청자에게 뿌리는 서비스가 아니라, 영상이 배포되기 좋은 형태가 되도록 중간에서 갈아엎는 처리 공장에 가깝다.

MPS의 위치

MPS의 구성은 다음과 같다.

image.png

라이브와 비교하면 차이가 더 잘 보인다. CSS나 StreamLive는 실시간 스트림을 받으면서 처리한다. RTMP나 SRT로 들어오는 스트림을 그 자리에서 트랜스코딩하고, HLS나 DASH 같은 재생 포맷으로 내보내는 쪽에 가깝다.MPS는 기본적으로 파일 기반 처리에 더 가깝다. COS 같은 오브젝트 스토리지에 올라간 영상을 대상으로 작업을 걸고, 결과물을 다시 스토리지에 남긴다. 물론 내부적으로 Tencent Cloud의 다른 미디어 서비스와 연결되기 때문에 사용자는 VOD 콘솔 안에서 기능을 켰을 뿐인데 뒤에서는 MPS 계열 처리 엔진이 움직이는 식의 구조도 나온다. 심지어 Tencent Cloud의 스토리지에 파일이 없어도 기능을 이용할 수 있다. S3 버킷에 있는 영상이나 , IDC에 보관하고 있는 영상들도 public 하게 접근 가능한 (혹은 접근제어가 등록된 private 경로) 파일 경로만 있다면 영상의 이동 없이 API만으로 작업을 수행할 수 있다.

구분

역할

CSS

라이브 스트림 수신, 트랜스코딩, 배포

StreamLive

방송급 라이브 채널 처리

VOD

업로드 영상 관리와 재생 워크플로

MPS

파일 기반 미디어 처리, AI 분석, 품질 개선

그러니까 MPS를 독립 제품 하나로만 보면 감이 좀 덜 온다. Tencent Cloud 미디어 제품군 전체에서 "영상 처리 담당 백엔드"라고 보면 된다. 겉으로는 VOD 버튼 하나 눌렀는데 안쪽에서는 인코딩 워커, AI 모델, 품질 검사 모듈이 줄줄이 붙는 구조다. 겉보기엔 버튼 하나인데 내부는 거의 수공업처럼 바쁘다.

가장 기본은 트랜스코딩이다

MPS에서 제일 기본이 되는 기능은 트랜스코딩이다. 원본 영상을 다른 코덱, 해상도, 비트레이트, 컨테이너로 변환한다. 예를 들어 4K 원본 하나를 업로드했다고 치자. 이걸 그대로 모바일 사용자에게 주면 네트워크도 울고, 플레이어도 울고, 사용자 요금제도 같이 운다. 그래서 보통은 1080p, 720p, 480p 같은 여러 ladder를 만들고, HLS나 DASH로 패키징해서 네트워크 상황에 따라 적당한 품질을 고르게 한다. MPS에서는 이런 작업을 템플릿과 워크플로로 구성한다.

작업

예시

코덱 변환

H.264, H.265, AV1 등

해상도 변환

4K 원본을 1080p, 720p로 변환

비트레이트 조정

저장 비용과 전송 비용 절감

컨테이너 변환

MP4, HLS, DASH 등

오디오 처리

오디오 코덱 변환, 볼륨 정규화

실무에서 중요한 건 "변환할 수 있다"가 아니다. 얼마나 많은 파일을 안정적으로 처리하고, 실패했을 때 어디서 재시도하고, 결과물이 어떤 규칙으로 저장되는지가 더 중요하다. 인코딩 자체보다 워크플로와 운영 상태 추적이 사람을 더 피곤하게 만든다. ffmpeg 한 줄은 쉬워 보이는데, 수천 개 파일을 안정적으로 돌리는 순간부터 개발자 수명이 갈린다.

TSC는 비트레이트를 줄이는 쪽에 가깝다

Tencent Cloud MPS를 이야기할 때 자주 나오는 기능이 TSC(Top Speed Codec)다. 이름만 보면 새로운 코덱처럼 느껴질 수 있는데, 실제로는 Tencent Cloud의 자체 인코딩 커널과 장면 분석 기술을 이용해 더 낮은 비트레이트로 비슷하거나 더 나은 체감 화질을 만들려는 트랜스코딩 방식에 가깝다. 일반적인 트랜스코딩은 비교적 고정된 설정으로 영상을 밀어 넣는다. 그런데 영상은 장면마다 복잡도가 다르다. 하늘이나 벽처럼 단순한 장면도 있고, 물결, 군중, 게임 화면처럼 압축이 빡센 장면도 있다. 여기에 같은 비트레이트를 균등하게 주면 단순 장면에서는 낭비가 생기고, 복잡한 장면에서는 화질이 깨진다.

TSC의 방향은 이 문제를 줄이는 것이다.

TSC 트랜스코딩 처리 흐름

이런 방식은 저장 비용과 CDN 전송 비용에 직접 영향을 준다. 특히 VOD처럼 같은 영상을 여러 번 재생하는 구조에서는 비트레이트 10~20% 차이도 누적되면 돈이 된다. 트래픽 많은 서비스에서는 이게 그냥 최적화가 아니라 운영비 방어선이다. 물론 공짜 점심은 없다. 장면 분석과 더 복잡한 인코딩을 넣으면 처리 시간이 늘거나 비용 모델이 달라질 수 있다. 결국 "인코딩 비용을 더 써서 저장/전송 비용을 줄일 것인가"의 trade-off다. 여기서 계산 안 하고 감으로 켜면, 나중에 청구서 보고 조용히 모니터만 보게 된다.

TSC에 관해서는 다른 글에서 좀 더 자세히 다룰 예정이다.

화질 개선과 음질 개선

MPS는 단순 변환뿐 아니라 영상과 오디오 품질 개선 기능도 제공한다. 이쪽은 AI 모델이 들어가는 영역이라 설명 문구만 보면 약간 마법처럼 보이는데, 실제로는 손상되거나 부족한 신호를 모델이 추정해서 보정하는 작업이다.

대표적으로는 이런 기능들이 있다.

영역

기능

영상

초해상도, 저조도 개선, 노이즈 제거, 압축 아티팩트 완화

색/명암

HDR 변환, 색감 보정

오디오

노이즈 제거, 음량 정규화, 음성 분리

품질 평가

VMAF, PSNR, SSIM 같은 지표 기반 평가

여기서 중요한 건 원본 품질이 완전히 망가진 영상을 무조건 살려내는 서비스는 아니라는 점이다. VLC가 플레이어가 아니라 거의 복구툴처럼 보일 때가 있긴 한데, 클라우드 AI도 물리법칙을 완전히 무시하진 못한다. 원본에 정보가 없으면 모델은 추정할 뿐이다.

그래도 오래된 교육 영상, 저조도 촬영본, 압축을 여러 번 거친 콘텐츠처럼 "그럭저럭 볼 수는 있는데 아쉬운" 영상에는 꽤 의미가 있다. 특히 B2B 콘텐츠 라이브러리처럼 원본을 다시 찍을 수 없는 경우에는 이런 후처리 파이프라인이 현실적인 선택지가 된다.

미디어 AI는 운영 자동화에 가깝다

MPS의 미디어 AI 기능은 영상을 더 예쁘게 만드는 것보다 운영 자동화에 더 가깝게 보는 게 좋다.

예를 들면 이런 작업이다.

기능

의미

스마트 자막

ASR/OCR 기반 자막 생성과 번역

하이라이트 추출

주요 장면을 찾아 짧은 클립 생성

태깅

장면, 물체, 인물, 키워드 추출

콘텐츠 모더레이션

부적절한 장면, 음성, 텍스트 탐지

품질 검사

블랙 프레임, 무음, 깨진 파일, 포맷 이상 탐지

영상이 몇십 개면 사람이 봐도 된다. 문제는 몇천 개, 몇만 개가 되는 순간이다. 그때부터는 사람이 직접 검수하는 구조가 아니라, 시스템이 1차로 걸러주고 사람이 예외만 보는 구조로 가야 한다.

이게 업계에서 미디어 AI를 보는 현실적인 관점이다. "AI가 콘텐츠를 이해한다" 같은 말보다 "운영자가 새벽에 영상 하나하나 열어보는 일을 줄인다"가 훨씬 중요하다. 결국 AI보다 retry logic이 더 열심히 일하는 경우가 많다.

Job과 Workflow

MPS를 실제로 쓸 때는 Job과 Workflow 개념을 구분해야 한다.

개념

설명

Job

특정 파일 하나 또는 작업 하나를 직접 처리

Workflow

업로드 이벤트를 기준으로 여러 작업을 자동 실행

Job은 단건 처리다. 이미 올라간 파일에 대해 "이 파일을 1080p로 트랜스코딩해줘", "이 파일에서 썸네일 뽑아줘" 같은 식으로 작업을 던진다.

Workflow는 자동화 파이프라인이다. 예를 들어 COS 버킷에 영상이 업로드되면 자동으로 트랜스코딩하고, 썸네일을 만들고, 자막을 생성하고, 모더레이션까지 돌리는 구조를 만들 수 있다.

MPS Workflow 자동화 흐름

운영 관점에서는 callback이 중요하다. 처리가 끝났는지, 실패했는지, 어떤 출력물이 생겼는지를 후속 시스템이 알아야 하기 때문이다. 여기서 이벤트 처리가 허술하면 관리자 화면에는 "처리 중"이라고 떠 있는데 실제 워커는 이미 실패한 상태가 된다. 표면상으론 멀쩡한데 내부 clock은 이미 지옥 가 있는 상태다.

언제 MPS를 쓰면 좋을까

MPS는 이런 경우에 잘 맞는다.

  • 업로드된 영상을 여러 해상도와 포맷으로 자동 변환해야 할 때

  • VOD 서비스에서 저장 비용과 전송 비용을 줄이고 싶을 때

  • 오래된 영상이나 저품질 영상을 후처리해야 할 때

  • 자막 생성, 태깅, 모더레이션을 자동화해야 할 때

  • 대량 파일 처리 상태를 API와 callback으로 관리해야 할 때

반대로 실시간 방송의 ingest, channel switching, live output orchestration이 핵심이면 MPS 하나만 보는 건 애매하다. 그 경우에는 CSS나 StreamLive 쪽이 먼저다. MPS는 라이브 방송국의 master control room이라기보다, 후반 작업실과 인코딩 팜에 가깝다.

정리

MPS는 Tencent Cloud 미디어 제품군에서 파일 기반 처리와 미디어 AI를 담당하는 핵심 레이어다. 트랜스코딩, TSC 기반 압축 효율 개선, 화질/음질 보정, 자막 생성, 콘텐츠 분석, 모더레이션, 품질 검사까지 한 파이프라인 안에 묶을 수 있다. 실무적으로는 "영상을 어떻게 재생할 것인가"보다 "재생 가능한 상태로 어떻게 안정적으로 만들어낼 것인가"에 가까운 서비스다. 그리고 이 차이가 중요하다. 재생은 플레이어와 CDN의 문제지만, 처리 파이프라인은 비용, latency, 실패 재시도, 결과물 관리까지 끌고 들어온다. 처음엔 그냥 트랜스코딩 서비스처럼 보인다. 그런데 운영 들어가면 결국 workflow, callback, retry, 품질 검사, 비용 최적화랑 싸우게 된다. 이쯤 되면 MPS는 기능 목록보다 파이프라인 설계 관점으로 보는 게 맞다.

참고: Tencent Cloud Media Processing Service