콘텐츠 관리 시스템을 만들며 정리한 트랜스코딩 이야기

영상·사진·음원을 모아 관리하는 콘텐츠 관리 시스템(CMS)을 만들고 있습니다. 화면에 보이는 기능은 AI 검색이나 워터마크지만, 실제로 가장 많은 시간과 자원을 쓰는 곳은 트랜스코딩입니다. 영상이 들어오는 순간부터 재생, 장면 분석, 외부 전달까지 모든 단계가 '영상을 한 번 더 인코딩하는 일'이기 때문입니다.

이 글에서는 만들면서 정한 원칙을 단계별로 정리합니다.

1. 원본은 손대지 않고, 용도별 사본을 만든다#

첫 번째 원칙은 원본을 그대로 보관하고, 쓰임새마다 따로 사본을 만드는 것입니다.

원본을 직접 재생하거나 원본을 그대로 내보내지 않습니다. 이렇게 하면 두 가지가 좋아집니다.

• 원본이 밖으로 나갈 일이 없습니다.
• 사본은 언제든 다시 만들 수 있어 설정을 바꾸기 쉽습니다.

2. 들어오자마자 '풀리는 영상인지' 먼저 확인한다#

업로드된 파일은 처리 전에 두 번 확인합니다. 먼저 파일의 정보(길이·해상도·트랙 구성)를 읽고, 다음으로 첫 프레임을 실제로 디코딩해 봅니다.

확장자가 .mp4여도 코덱을 모르거나 파일이 손상된 경우가 생각보다 많습니다. 긴 변환을 돌리다 중간에 실패하는 것보다, 처음 몇 초 안에 "해독할 수 없는 코덱", "영상 트랙이 없는 파일"처럼 사람이 읽을 수 있는 이유를 남기고 멈추는 편이 운영하기 훨씬 편합니다.

3. 재생용 사본: 고정 용량 대신 화질 기준으로 인코딩한다#

웹 재생은 HLS 스트리밍으로 합니다. 해상도에는 상한을 두고, 원본이 더 작으면 억지로 키우지 않습니다. 영상을 일정 길이의 조각으로 나누면서 조각마다 키프레임을 넣어, 장면을 눌렀을 때 정확한 시점으로 이동할 수 있게 했습니다.

처음에는 하드웨어 인코더로 고정 비트레이트 인코딩을 했습니다. 빠르지만, 정지 화면이 많은 영상에도 움직임이 많은 영상과 똑같은 용량을 썼습니다. 그래서 화질 기준 인코딩에 비트레이트 상한을 두는 방식으로 바꿨습니다. 우리 샘플 기준으로 용량이 OO~OO% 줄었고, 화질 지표(VMAF) 차이는 OO 미만이었습니다.

속도가 급할 때를 위해 하드웨어 인코더도 설정 하나로 고를 수 있게 남겨 두었습니다. 용량과 속도 중 무엇이 중요한지는 상황마다 다르기 때문입니다.

4. 장면 분할도 결국 디코딩 작업이다#

AI가 장면마다 설명을 붙이려면 먼저 영상을 장면으로 나눠야 합니다. 이 과정도 영상을 처음부터 끝까지 풀어 보는 작업이라, 트랜스코딩만큼 자원을 씁니다.

• 작게 줄여서 분석한다 — 장면 전환을 찾는 데는 원본 해상도가 필요 없습니다. 크기를 줄이면 속도가 크게 빨라집니다.
• 기준은 영상마다 다르게 — 모션그래픽처럼 컷이 거의 없는 영상은 같은 기준으로는 장면이 잘 안 나뉩니다. 결과를 보며 기준을 단계적으로 조정합니다.
• 장면 길이를 보정한다 — 너무 짧은 장면은 앞 장면에 합치고, 너무 긴 장면은 나눠 AI가 다루기 좋은 길이로 맞춥니다.
• 대표 프레임은 여러 장 — 장면 하나에서 한 장만 뽑으면 놓치는 내용이 생겨, 여러 시점의 프레임을 함께 AI에 넘깁니다.

5. 받는 사람마다 다른 사본: 워터마크는 트랜스코딩 위에서 동작한다#

외부 파트너에게 영상을 보낼 때는 받는 사람마다 눈에 보이지 않는 식별값을 넣은 사본을 따로 만듭니다. 영상을 프레임 단위로 풀고, 식별값을 넣고, 다시 인코딩하는 과정입니다. 이 과정을 하나로 이어 흘려보내는 방식으로 만들어, 긴 영상도 전체를 메모리에 올리지 않고 처리합니다. 화질은 받는 쪽 용도에 맞게 고·중·저 세 단계로 고를 수 있고, 음원도 같은 방식으로 단계별 사본을 만듭니다.

중요한 점은 워터마크가 '그 뒤에 일어날 트랜스코딩'도 견뎌야 한다는 것입니다. 유출된 영상은 대개 잘리고, 화질이 낮아지고, 다시 인코딩된 상태로 발견됩니다. 그래서 일부러 짧게 자르고 낮은 화질로 다시 인코딩한 영상으로 시험했고, 식별값 OO비트 중 OO비트가 일치해 받는 사람을 특정할 수 있었습니다. 화면이 심하게 훼손된 경우를 대비한 보완 장치도 함께 두었습니다.

6. FFmpeg가 못 푸는 포맷: 카메라 RAW#

방송·영화 현장의 촬영 원본에는 FFmpeg 같은 범용 도구가 해독하지 못하는 카메라 제조사 독자 RAW가 많습니다(RED R3D, Blackmagic RAW, ARRIRAW, Sony X-OCN 등). 이런 파일은 다음 순서로 처리하도록 구조를 나눴습니다.

1. 1제조사 SDK나 편집 도구를 '변환기'로 연결합니다.
2. 2고화질 중간 파일로 바꿉니다.
3. 3중간 파일을 기존 처리 단계(스트리밍·장면 분할·태깅·워터마크)로 넘깁니다.

MXF는 일반 방송 코덱과 RAW가 같은 확장자를 쓰기 때문에 파일을 열어 봐야 구분할 수 있습니다. 사진 RAW는 영상 변환 대상에서 빼고 이미지 처리 경로로 따로 보냅니다.

7. 운영: 실패는 반드시 일어난다#

트랜스코딩은 오래 걸리고 자원을 많이 써서, 처음부터 실패를 전제로 설계했습니다.

• 작업 대기열 — 변환 요청은 대기열에 쌓고, 작업자가 하나씩 가져가 처리합니다. 요청이 몰려도 서버가 한꺼번에 무너지지 않습니다.
• 일시적 오류는 자동 재시도 — 간격을 점점 늘려 가며 정해진 횟수까지 다시 시도합니다.
• 영구 오류는 바로 알린다 — 손상된 파일이나 영상 트랙이 없는 파일은 다시 시도해도 결과가 같으니, 재시도 없이 바로 이유를 보여 줍니다.
• 운영 화면 — 변환·워터마크·메일 작업의 대기·처리 중·실패 수와 스토리지 사용량을 한눈에 봅니다.

참고로 노트북 1대로 재 보니, 영상 1시간을 처리하는 데 약 OO분 걸렸습니다. 스트리밍 변환, 장면 분할, AI 태깅까지 포함한 시간입니다.

마치며#

CMS에서 트랜스코딩은 '재생 가능한 파일 만들기'에서 끝나지 않습니다. 검색을 위한 분석, 보안을 위한 사본 만들기, 유출 추적까지 모든 기능이 트랜스코딩 위에서 돌아갑니다. 그래서 다음 세 가지가 시스템 전체의 비용과 안정성을 결정했습니다.

• 원본은 손대지 않는다.
• 용도별로 사본을 만든다.
• 화질 기준으로 인코딩하고, 실패를 전제로 운영한다.

영상·음원 같은 미디어를 다루는 시스템이나, 여기에 AI 검색·분석을 더하는 일이 필요하다면 에스제이시스템이 설계부터 운영까지 함께할 수 있습니다.