Tencent Cloud MPS (Media Processing Service)

들어가기 전에

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

MPS의 위치

MPS의 구성은 다음과 같습니다.

라이브와 비교하면 차이가 더 잘 보입니다. 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입니다. 이름만 보면 새로운 코덱처럼 느껴질 수 있는데, 실제로는 Tencent Cloud의 자체 인코딩 커널과 장면 분석 기술을 이용해 더 낮은 비트레이트로 비슷하거나 더 나은 체감 화질을 만들려는 트랜스코딩 방식에 가깝습니다. 일반적인 트랜스코딩은 비교적 고정된 설정으로 영상을 밀어 넣습니다. 그런데 영상은 장면마다 복잡도가 다릅니다. 하늘이나 벽처럼 단순한 장면도 있고, 물결, 군중, 게임 화면처럼 압축이 빡센 장면도 있습니다. 여기에 같은 비트레이트를 균등하게 주면 단순 장면에서는 낭비가 생기고, 복잡한 장면에서는 화질이 깨집니다.

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 버킷에 영상이 업로드되면 자동으로 트랜스코딩하고, 썸네일을 만들고, 자막을 생성하고, 모더레이션까지 돌리는 구조를 만들 수 있습니다.

운영 관점에서는 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