서론: 왜 메타는 FFmpeg 포크를 유지했을까?
FFmpeg는 미디어 처리의 사실상 표준 도구입니다. 메타 앱을 통해 업로드되는 수십억 개의 동영상을 처리하기 위해 FFmpeg CLI(ffmpeg, ffprobe)는 하루에도 엄청난 횟수 실행됩니다. 초기에는 공식 FFmpeg가 제공하지 않는 기능, 특히 병렬 멀티레인 트랜스코딩과 실시간 화질 메트릭 계산이 필요했고, 이를 위해 메타는 자체 포크를 개발해 유지해 왔습니다.
하지만 시간이 지나며 이 포크는 업스트림(공식) 버전과 점점 멀어졌고, 새로운 코덱 지원이나 안정성 개선을 적용하기가 어려워졌습니다. 두 버전을 동시에 유지하는 것은 점점 더 큰 기술 부채가 되었죠.
본론 1: 업스트림으로 돌아가기 위한 두 가지 도전과제
메타가 내부 포크를 완전히 제거하고 공식 FFmpeg에만 의존하기 위해 해결해야 했던 핵심 과제는 두 가지였습니다.
1. 더 효율적인 멀티레인 트랜스코딩
사용자가 동영상을 업로드하면, DASH 재생을 위해 다양한 해상도와 품질의 인코딩(레인) 세트를 생성합니다. 단순히 각 레인을 별도의 FFmpeg 프로세스로 실행하면 디코딩 작업이 중복되어 비효율적입니다. 단일 명령어로 여러 출력을 생성하면 디코딩 오버헤드를 줄일 수 있지만, FFmpeg 6.0 이전에는 각 인코더가 프레임별로 순차적으로 실행되어 병렬성의 이점을 충분히 살리지 못했습니다.
메타의 내부 포크는 이 문제를 모든 인코더 인스턴스를 병렬로 실행하는 방식으로 해결했습니다. 이 설계는 FFmpeg 커뮤니티(FFlabs, VideoLAN)에 영감을 주었고, FFmpeg 6.0부터 8.0에 걸쳐 더 효율적인 스레딩 모델이 공식 구현되었습니다. 이는 수십 년 만에 가장 복잡한 리팩토링 중 하나였으며, 결과적으로 모든 FFmpeg 사용자가 더 효율적인 인코딩을 누릴 수 있게 되었습니다.
2. 라이브 스트리밍을 위한 실시간 화질 메트릭
VOD(주문형 비디오)가 아닌 라이브 스트리밍에서는 인코딩이 끝난 후 화질(PSNR, SSIM, VMAF 등)을 측정할 수 없습니다. 실시간으로 품질을 모니터링해야 하죠. 이를 위해선 각 출력 레인의 인코더 뒤에 비디오 디코더를 삽입해, 압축 적용 후의 프레임을 다시 얻어 원본 프레임과 비교해야 합니다.
이 '인-루프(In-loop) 디코딩' 기능이 FFmpeg 7.0부터 공식 지원되기 시작했고, 메타는 이제 내부 포크 없이도 단일 FFmpeg 명령어로 각 레인의 실시간 화질 메트릭을 생성할 수 있게 되었습니다. 이에 대한 자세한 기술적 배경은 근거자료에서 확인할 수 있습니다.
본론 2: 무엇을 업스트림에 기여하고, 무엇을 내부에 유지하는가?
메타는 실시간 화질 메트릭이나 효율적 스레딩처럼 광범위한 커뮤니티에 도움이 되는 기능은 적극적으로 업스트림에 기여합니다. 반면, 메타 스케일러블 비디오 프로세서(MSVP) 같은 자체 설계 ASIC(주문형 반도체)에 대한 지원 패치는 내부에 유지합니다. MSVP는 메타 인프라 내에서만 사용되므로, 테스트 하드웨어가 없는 FFmpeg 개발자들이 유지보수하기는 거의 불가능하기 때문입니다.
대신 메타는 FFmpeg의 표준 하드웨어 가속 API(NVDEC/NVENC, QSV 등과 동일한 방식)를 활용해 MSVP를 지원함으로써, 플랫폼별 특이사항을 최소화하면서 공통 도구를 사용할 수 있게 했습니다. 이는 특수성과 일반성의 균형을 보여주는 좋은 사례입니다.
한국 개발 생태계에서의 적용 맥락 국내에서도 대규모 미디어 서비스를 운영하는 기업들은 비슷한 딜레마에 직면할 수 있습니다. 자체 포크를 만들지, 업스트림에 기여할지, 아니면 다른 오픈소스 솔루션을 찾을지 고민하게 되죠. 메타의 사례는 '먼저 업스트림에 기여할 수 있는지 고민하라'는 중요한 원칙을 상기시킵니다. 단기적으로는 포크가 빠른 해결책처럼 보일 수 있지만, 장기적인 기술 부채와 유지보수 비용은 상상을 초월합니다.
결론: 대규모 운영에서 얻은 교훈과 다음 단계
이제 메타는 모든 VOD 및 라이브스트리밍 파이프라인에서 내부 FFmpeg 포크를 완전히 사용 중단했습니다. 25년 이상 개발되어 온 FFmpeg의 생태계 힘과, 지속적인 업스트림 기여를 통한 상생의 가치를 확인한 사례입니다.
이 기술의 한계 또는 주의사항 업스트림 기여는 시간과 협업 노력이 많이 듭니다. 메타처럼 리소스가 풍부한 조직이 아니면, 모든 수정 사항을 공식 버전에 반영하도록 노력하기는 현실적으로 어려울 수 있습니다. 또한, 매우 특수한 하드웨어나 인프라에 대한 변경 사항은 내부에 유지하는 것이 오히려 커뮤니티에 대한 책임일 수 있습니다.
다음 단계 학습 방향 제시 만약 당신의 팀도 유사한 오픈소스 도구의 포크를 유지하고 있다면, 다음 질문들을 스스로에게 던져보세요:
- 우리가 필요로 하는 기능이 업스트림에 반영되기 위해 어떤 기여를 할 수 있을까?
- 이 포크를 유지하는 데 드는 장기 비용(리베이스, 검증, 보안 패치)은 얼마나 될까?
- 우리의 변경 사항을 모듈화하거나 플러그인 형태로 만들어 포크의 필요성을 없앨 수는 없을까?
메타의 FFmpeg 이야기는 단순한 기술적 마이그레이션이 아닌, 오픈소스 생태계와의 건강한 관계 구축에 관한 인사이트를 제공합니다. 함께 보면 좋은 글로, 사용자 인터페이스의 정밀한 제어에 관한 CSS로 완벽한 파이차트 만들기 시맨틱과 접근성을 고려한 실전 가이드와, 하드웨어 리소스 최적화에 관한 LLM 추론 비용 폭탄? NVIDIA Runai와 NIM으로 GPU 활용률 2배 높이는 법을 추천합니다.