자체 HLS 파이프라인 재구축: TwelveLabs가 비용이 많이 드는 플레이백 병목 현상을 해결한 방법

흔히 '비디오 인텔리전스'를 떠올릴 때 모델 학습이나 검색 품질을 가장 먼저 생각하곤 합니다. 하지만 실제로 사용자가 체감하는 경험은 결과를 불러오는 동안에도 원본 비디오를 실제로 시청하고, 구간 이동(scrub)하고, 탐색할 수 있는 기술적 기반인, 겉으로 잘 드러나지 않는 백엔드 인프라에 크게 좌우됩니다.

이 글은 이러한 보이지 않는 시스템 중 하나인 HLS(HTTP Live Streaming) 생성에 관한 이야기입니다. HLS 생성은 새로 업로드된 비디오를 브라우저에서 즉시 재생 가능한 분할 스트리밍 포맷으로 변환하는 프로세스입니다. HLS는 수많은 작은 미디어 세그먼트를 가리키는 플레이리스트(흔히 .m3u8)를 사용해 미디어를 전송하므로, 플레이어가 빠르게 재생을 시작하고 네트워크 환경에 유연하게 적응하며 효율적으로 원하는 구간을 탐색할 수 있게 합니다.

지난해 저희는 뼈아픈 불일치 문제를 겪었습니다. 저희의 인덱싱 파이프라인은 극도로 빨라진 반면, (처음에는 외부 미디어 트랜스코딩 서비스에 아웃소싱했던) 스트리밍 파이프라인은 상대적으로 느렸고 비용마저 계속 늘어났습니다. 이로 인해 인덱싱은 진작 끝났는데 HLS 생성이 여전히 실행 중이어서 정작 플레이그라운드에서 비디오를 시청할 수 없는, 사용자에게 혼란을 주는 제품 경험이 발생했습니다.

그래서 저희는 이 부분을 직접 다시 구축하기로 했습니다.

1 - 외면할 수 없었던 병목 현상

계기는 단순했습니다. 지난해 저희는 더 긴 비디오(기존 약 2시간에서 최대 4시간까지)를 지원하는 Marengo 3.0을 출시했고, 그 결과 기존의 한계를 더 이상 무시할 수 없게 되었습니다. 비디오의 길이가 길어지자 재생 준비 속도가 인덱싱보다 훨씬 뒤처졌고, 시스템은 이미 비디오를 분석 완료했는데 브라우저에서는 여전히 부드럽게 재생할 수 없는 답답한 기능적 공백이 생겼습니다. 이 불일치는 내부와 외부 모두에서 드러났습니다. 사용자는 재생 준비가 되기도 전에 결과를 보게 되었고, 내부 팀원들 역시 인덱싱이 끝나면 자연스럽게 모든 준비가 완료되기를 기대했습니다.

2 - 자체 구축 vs 외부 솔루션: 타사 파이프라인을 벗어난 이유

처음부터 파이프라인을 직접 만들기로 결정한 것은 아니었습니다. 그 전에 먼저 외부 업체의 가속 모드(Accelerated Mode)로 이 격차를 충분히 좁힐 수 있는지 테스트해 보았습니다.

테스트 평가 결과, 가속 모드를 사용하면 기본 설정 대비 처리 속도가 약 3.9배 향상되었습니다. 그러나 이 결과 역시 저희가 목표로 했던 최상의 사용자 경험 수준에는 미치지 못했습니다.

또한 비용 부담도 컸습니다. 가속 모드를 쓰려면 더 높은 고가의 요금제를 사용해야 했는데, 분석해 보니 기본 설정보다 비용이 약 60% 더 비쌌습니다.

가속 모드가 성능을 개선해 주기는 했지만 근본적인 타협점까지 바꾸지는 못했던 것입니다. 기존 방식을 조금 낫게 만들었을 뿐, 장기적인 대안이 되기에는 성능 면에서도, 비용 면에서도 충분하지 않았습니다.

결국 저희는 다음 세 가지 제약 조건을 고려해 결단을 내렸습니다.

• 성능: 사용자 경험의 병목은 인덱싱이 아닌 HLS 처리에 있었습니다.

• 비용: 아웃소싱 파이프라인 비용이 매달 무시할 수 없는 수준으로 올라가고 있었고, 상승 곡선을 그리고 있었습니다.

• 미래 요구사항: 저희는 온프레미스(On-Premise) 배포를 지원하고자 합니다. 핵심 재생 인프라를 특정 클라우드 벤더에 의존하면 이러한 방향성을 추진하기가 어려워집니다.

마지막 포인트는 미묘하지만 매우 중요합니다. 폐쇄망(air-gapped) 환경의 온프레미스 배포를 성공시키려면 '우리가 직접 실행할 수 있는 것은 무엇인가?'를 고민하고 관리형 클라우드 서비스에 대한 의존도를 최소화해야 합니다. 이미 저희 팀은 핵심 비동기 인프라를 쿠버네티스(Kubernetes) 및 제한된 환경에서도 실행할 수 있는 구조로 전환해 가고 있었습니다.

자체 구축한 HLS 파이프라인은 이러한 전략적 방향성과 완벽히 일치했습니다.

3 - 설계 및 구현: 실용적이고 확장 가능한 자체 HLS 파이프라인

아키텍처 설계에 본격적으로 착수하기 전에, 먼저 가장 기본적인 가설을 검증해야 했습니다. 바로 순수 FFmpeg 트랜스코딩만으로 충분히 빠른 속도를 낼 수 있는가 하는 점이었습니다.

HLS 출력은 일반적으로 미디어를 세그먼트로 나누고 이를 참조하는 플레이리스트 파일을 쓰는 작업입니다. FFmpeg은 이를 위한 전용 HLS 멀티플렉서(muxer)까지 제공합니다.

하지만 성능 외에도 시스템이 갖추어야 할 요건들이 더 있었습니다.

• 대규모 환경에서도 안정적으로 상시 실행되어야 하고,

• 기존의 '업로드 → 인제스트(수집) → 인덱싱' 워크플로우에 매끄럽게 통합되어야 하며,

• 실제 비디오 입력값으로 인해 예외 상황이 발생하더라도 안전하게 대처(재시도, 알림, 분류 및 대응)할 수 있어야 했습니다.

첫 번째 설계 제안서에서 저희는 간단하고 명확한 접근법을 정립했습니다. FFmpeg 기반의 자체 'HLS 변환 서비스'를 만들고, 큐(Queue) 기반의 워커(Worker) 그룹을 활용하는 방식이었습니다.

3.1 - 상위 수준 흐름

전반적인 아키텍처의 도식은 다음과 같습니다.

그림 1: 비디오 인제스트 프로세스는 두 개의 독립적인 경로로 분기됩니다. 분석 파이프라인은 검색 가능한 표현체를 생성하고, 재생 파이프라인은 스트리밍을 위한 HLS 세그먼트를 준비합니다. 두 경로는 목적이 분리되어 있지만 동일한 입력을 공유하므로, 재생단에서의 비효율성은 즉각 제품의 병목 현상으로 직결됩니다.

1. 백엔드 오케스트레이터 서비스가 '변환 태스크'를 Redis 기반의 큐에 생성해 넣고, 완료 메시지를 수신하여 작업 상태를 업데이트합니다.

2. Redis를 작업 큐이자 메시지 브로커로 활용하며, 변환 태스크용 스트림과 완료 신호(SUCCEEDED/FAILED)용 스트림을 독립적으로 분류해 운영합니다.

3. 워커는 FFmpeg을 실행하고, HLS 세그먼트와 플레이리스트를 생성하여 그 결과를 스토리지에 업로드하도록 설계된 'HLS 변환기 포드(Pod)'로 구성됩니다.

3.2 - 오토스케일링

인코딩 워크로드는 가변적입니다. 데모 데이나 새로운 모델 출시 시기에는 '스트리밍 준비가 필요한 비디오'가 한꺼번에 몰릴 수 있습니다. 상시 작동하는 HLS 워커 서버를 불필요하게 가득 띄워 두고 싶지는 않았습니다.

이에 따라, 이벤트 소스(Redis 포함)를 기반으로 워크로드를 스케일링할 수 있는 쿠버네티스 이벤트 기반 오토스케일러인 KEDA를 도입하여 큐의 상황에 워커의 대수를 연동했습니다.

또한, 고객 간의 자원 독점 문제를 방지하고 공평한 리소스 배분을 위해 큐 메시지는 여러 고객사에 고르게 분배되도록 발행 타깃을 제어합니다.

3.3 - 안정성

HLS 처리를 외부에 맡긴다고 해서 실패 요인이 사라지는 것은 아닙니다. 단지 눈앞에서 보이지 않게 넘겼을 뿐입니다. 기술을 내재화한다는 것은 최종 단계의 안정성까지 우리가 직접 책임지겠다는 의미였습니다.

개발 초기 단계부터 장애 허용성(fault tolerance)을 세심하게 고려했습니다.

• 체계적인 백오프(backoff) 정책 기반의 재시도 구성,

• 처리에 계속 실패하는 비정상 작업을 격리하기 위한 데드 레터 큐(Dead-Letter Queue),

• 그리고 기술 지원팀과 엔지니어가 신속하게 대응할 수 있도록 명확한 오류 보고 및 관측성(Observability) 확보.

물론 그럼에도 오류 이벤트는 발생했습니다. 가령 내부 사용자로부터 "HLS 처리가 끝나지 않는다"는 리포트가 접수되었고, 원인을 분석한 결과 자체 구현한 HLS 컨슈머가 정상적으로 요청을 처리하지 못하는 상태("hls task is never activated")임을 확인하기도 했습니다.

이 시스템을 직접 운영하면서, 예전에는 아웃소싱으로 무상 제공받는 듯했던 안정적인 인프라 운영체력을 자체적으로 강화해야 했습니다.

• 핸들러 시작 지점의 상세한 로깅 기록,

• 컨슈머 헬스 체크를 위한 고도화된 모니터링 알림 설정,

• 그리고 대기 상태인 작업이 소리 없이 멈추지 않도록 확실한 처리 보장 장치 마련.

결과적으로, 크론잡(cronjob)을 통한 컨슈머 자동 정리 기법과 하트비트(heartbeat) 메커니즘을 적용하여 타임아웃 발생률을 대폭 낮췄습니다.

4 - 진짜 속도 제어의 핵심은 'FFmpeg Flag'가 아니었습니다.

그림 2: FFmpeg은 전체 시스템 흐름 중 단지 한 단계일 뿐입니다. 엔드투엔드 지연 시간을 결정짓는 요인은 비디오 데이터가 내부에서 이동하는 방식입니다. 워커에 데이터를 제공하는 방식(스트리밍 vs 다운로드), 디스크 I/O 및 중간 쓰기 작업, 그리고 결과를 스토리지에 다시 업로드하는 과정이 이에 해당합니다. 성능을 좌우하는 것은 인코더 옵션이 아니라 바로 이러한 바운더리 영역의 최적화입니다.

비디오 파이프라인 개발 시 흔히 범하는 오해 중 하나는 성능 개선이 주로 '올바른 FFmpeg 명령어 옵션 선택'에 달려있다고 생각하는 것입니다. 실제 대규모 인프라에서는 FFmpeg 외적인 영역의 효율화가 훨씬 더 극적인 성능 개선을 만들곤 합니다.

저희 역시 처음부터 완벽한 성능 지표를 달성하지는 못했습니다. 저희가 해결해야 했던 핵심 과제들은 워커로의 비디오 전송 속도, 디스크 I/O, 임시 데이터 쓰기 방식, 그리고 CPU와 GPU 중 최적의 연산 리소스를 선별하는 벤치마킹 과정이었습니다.

이 과정에서 의사결정에 차이를 만든 구체적인 설계 전략들은 다음과 같습니다.

4.1 - 소스 스트리밍 방식과 사전 다운로드 방식의 조합

워커 노드로 비디오 파일을 가져오는 것은 말로만 들으면 간단해 보이지만, 대용량 업로드가 쏟아지는 규모에서는 복잡한 문제가 됩니다.

저희는 하이브리드 수집 전략을 선택했습니다. 파일의 크기와 런타임 추정치에 맞춰, 워커가 사전 서명된 URL(Presigned URL)로부터 직접 데이터를 스트리밍하도록 하거나 혹은 로컬 디스크에 전체 파일을 다운로드하여 작업하도록 분기 처리했습니다. 이를 통해 대용량 파일 가동 시의 불필요한 데이터 세그먼트 이동을 막고, 가벼운 작업은 직관적이고 빠르게 끝낼 수 있도록 유연하게 최적화했습니다.

4.2 - 세그먼트 병렬 업로드

HLS 출력물은 비디오의 총 길이와 개별 조각 크기에 따라 인덱스 파일 하나 외에도 수백 혹은 수천 개의 세그먼트 파일로 구성됩니다.

이 때문에 업로드 프로세스의 설계가 성능을 좌지우지하게 됩니다. 인코딩 단계를 빠르게 끝냈더라도 업로드를 순차적으로 처리하게 되면 결과적으로 '재생 가능한 시점'이 크게 늦어져 병목이 생깁니다.

저희는 인코딩 + 패키징 + 전송의 전 과정을 유기적인 하나의 단계로 묶고 동시에 병렬로 밀어 올리도록 구성했습니다.

4.3 - 초고속 로컬 NVMe와 디스크 I/O 설계

임시 생성 파일과 최종 HLS 세그먼트가 물리 디스크에 실시간으로 기록되는 시점에는 스토리지 처리 속도(Throughput) 자체가 핵심 경로가 됩니다. 특히 대용량 HLS 출력이 수없이 발행되는 대규모 인프라 작업군에서는, 일반적인 Elastic Block Store(EBS) 디스크 I/O가 생각지 못한 지극히 치명적인 병목 지점이 되었습니다. CPU와 메모리 자원은 넉넉한데 정작 디스크 쓰기 속도가 이를 따라가지 못해 시스템 전체가 대기 상태에 빠지는 현상이었습니다.

이를 해결하기 위해 로컬 NVMe 스토리지를 적극적으로 활용했으며, 기존 플레이어 영역 최적화 연구 성과를 접목해 EKS(Elastic Kubernetes Service) 내 노드 로컬 스토리지 역량을 최대로 확보했습니다. 이에 따라 미디어 트랜스코딩 엔진이 막힘없이 실시간으로 데이터를 가공하고 패키징할 수 있는 뛰어난 안정성을 다지게 되었습니다.

5 - 결과: 더 빠르고, 더 저렴하며, 배포 유연성이 극대화된 파이프라인

그림 3: 격리된 개별 인코딩 과정 대신 전체 데이터 전달 과정을 유기적으로 설계함으로써, 파이프라인 성능을 세 가지 차원에서 획기적으로 개선했습니다. '재생 가능 시점 단축', '인프라 비용의 획기적 축소', '폭넓은 배포 유연성 확보'가 그것입니다. 재생 준비가 더 이상 병목 현상이 되지 않고 비디오 공급 규모에 맞추어 유연하게 확장되는 인프라를 마련했습니다.

저희는 이번 작업의 성공 지표를 '재생 대기 시간 단축 효과', '운영 원가 절감 수준', 그리고 '성공적인 기능 내재화 달성 여부'로 정의하고 면밀히 측정했습니다.

5.1 - 성능 지표

기존 트랜스코딩 인프라와 대비하여, 평균 처리 속도가 무려 6.6배가량 향상되었습니다. 이를 통해 4시간 분량의 긴 비디오 스트리밍을 준비하는 시간이 기존 1시간 이상에서 단 몇 분 수준으로 단축되었습니다.

시스템 완성도를 지속 관리하기 위해 여타 다운스트림 인프라 영역의 레이턴시 역시 실시간으로 추적하고 있으나, 이번 개선만으로도 사용자가 겪었던 가장 큰 문제인 '인덱싱은 끝났는데 재생이 불가능한 현상'을 말끔하게 해소할 수 있었습니다.

5.2 - 비용 효율

기존 타사 플랫폼에 의존하던 방식을 기준으로 삼았을 때, 비디오 시간당 HLS 처리 연산 원가가 기존 $0.045에서 $0.006 수준으로 크게 절감되었으며 이는 무려 약 87%에 준하는 절약 수치입니다. 향후 스토리지 유지보수 예상 비용까지 종합적으로 감안하더라도, 자체 전용 파이프라인을 운영하는 편이 훨씬 경제적임을 증명했습니다.

5.3 - 가치 지표와 향후 계획

HLS 처리 기술을 자체 내재화한 의미는 처리 시간 단축과 비용 절감에 국한되지 않습니다. 향후 추진할 멀티 배포 모델과의 기술 호환성을 담보할 토대를 마련했다는 데 의의가 큽니다.

저희는 폐쇄형 사내 에어갭(Air-gapped) 환경에서도 인프라가 원활히 작동할 수 있게 설계하고, 궁극적으로 온프레미스 설치형 배포 구동 시 클라우드 관리 오버헤드를 제로화하는 고도화 투자 작업에 박차를 가하고 있습니다.

자체 마련한 HLS 구조 역시 이러한 설계 철학의 연속선상에 놓여 있습니다. 타사 인프라에의 종속성을 줄여 시스템 제어력을 높이고, 핵심 가치가 외부 클라우드의 가용성 상황이나 갑작스러운 과금 가격 정책 변동에 기인하여 흔들릴 위험을 사전에 완차단한 것입니다.

6 - 기술 조직과 공유하고 싶은 핵심 러닝포인트

지금까지 저희가 진행한 'HLS 트랜스코딩 마이그레이션' 과정을 되짚으며 얻은 값진 인사이트를 공유합니다.

1. 첫째, 개발팀이 가장 선호하는 서브시스템이 아닌, 실제 사용자가 겪는 '핵심 경로(Critical Path)'의 가치 최적화에 주력해야 합니다. 아무리 검색 속도와 인덱싱 기술의 우수한 성능을 자랑스럽게 여겨도, 정작 사용자가 비디오 재생 지연이라는 일차적이고 핵심적인 경험에서 막힌다면 그 제품 가치는 반감됩니다.

2. 둘째, 전 단계의 프로세스를 넓은 관점으로 벤치마킹하고 단편적인 병목 부각 지점에 너무 매몰되지 말아야 합니다. 단지 "명령어 수행 속도가 기가 막히게 빠르다"고 해서 "최종 시스템 성능이 극대화되었다"는 것을 의미하지 않기에, 저희는 FFmpeg 외부 인터페이스(실제 기기 입출력 데이터 전달 과정, 디스크 I/O 최적화, 스토리지 업로드 로직 배분 작업 및 고속 메시지 큐 정렬 등)를 통합적으로 조율하고 끈질기게 파고들었습니다.

3. 셋째, 자체 클라우드 인프라를 구성하는 결정은 단순 기술적 열정의 결과물이 아니라 거시적인 비즈니스 손익과 엔드 프로덕트 가치를 종합한 경제적인 결정이어야 합니다. 이번 핵심 동인 역시 단순 "자체 변환 장치를 설계하는 즐거움" 때문이 아니라 (a) 실사용자의 사용자 경험을 방해하는 긴 레이턴시 지연을 잡기 위해, (b) 향후 성장을 방해하는 우상향 비용 곡선을 평탄화하기 위해, (c) 폐쇄망을 포함한 다양한 하이브리드 인프라 환경 배포 가능성을 열기 위한 현실적인 분석 결과였습니다.

4. 넷째, 기술 내재화를 단행했다면 비로소 안정성 그 자체를 핵심 서비스 상품으로 다루어야 합니다. 태스크 활성화 지연 장애 등을 접하며 얻은 교훈을 계기로 시스템 전반의 디버깅 편의성을 갖추고 실시간 헬스 체크용 모니터링 체계를 보다 정교하게 설계해 탄탄한 인프라 기초 체력을 일궜습니다.

5. 마지막으로, 점진적으로 민첩하게 출시(Ship incrementally)하십시오. 저희의 일차적인 지표는 명확했습니다. 뛰어난 실시간 동작비(Real-time ratio)를 달성하고, 유저 관점에서 꼭 필요한 핵심 기능들의 커버리지를 채워 나가는 것이었습니다. 첫날부터 100% 완전무결한 그림을 선보이려 하기보다, 지속해서 검증해 다듬을 수 있는 빠르고 저렴하면서 안전한 길을 개척하는 것이 진정한 혁신의 방법입니다.