Meta의 엔지니어링 블로그에 올라온 FFmpeg 관련 글이 최근 Hacker News를 뜨겁게 달궜습니다. 하루에 수백억 번의 FFmpeg 바이너리를 실행하는 Meta가, 수년간 유지하던 내부 Fork 버전을 버리고 드디어 Upstream(메인라인)으로 합류했다는 내용입니다.

솔직히 말해서 시니어 엔지니어라면 누구나 공감할 만한 애증의 주제입니다. 급한 비즈니스 요구사항 때문에 오픈소스를 내부적으로 Fork해서 쓰다가, 시간이 지나면서 메인라인과 너무 멀어져 버려 업데이트를 못하는 그 끔찍한 기술 부채 말입니다. 저 역시 과거에 비슷한 결정을 내렸다가 몇 년 뒤 피눈물을 흘리며 마이그레이션했던 기억이 납니다.

이번 글에서는 Meta가 FFmpeg에 기여한 두 가지 핵심 기술적 변화와, 이를 둘러싼 커뮤니티의 현실적인 논쟁을 파헤쳐 보겠습니다.

Multi-Lane Transcoding: 병렬 처리의 재설계

VOD나 라이브 스트리밍 환경에서 유저가 영상을 업로드하면, 다양한 네트워크 환경에 맞추기 위해 여러 해상도와 비트레이트로 영상을 변환해야 합니다. 이를 DASH(Dynamic Adaptive Streaming over HTTP)라고 부릅니다.

가장 단순한 방법은 각각의 해상도마다 별도의 FFmpeg 프로세스를 띄우는 것입니다. 하지만 이는 비디오 디코딩과 프로세스 시작 오버헤드를 중복으로 발생시킵니다. 그래서 보통은 하나의 FFmpeg 명령어 안에서 여러 개의 출력을 뽑아내는 방식을 사용합니다.

하지만 과거의 FFmpeg는 여러 인코더가 작동할 때 각 프레임에 대해 인코더를 직렬로 실행했습니다. Meta는 이를 병렬화하는 최적화를 내부 Fork에서 구현해 사용하고 있었습니다.

이 기능이 마침내 FFmpeg 6.0부터 도입되어 8.0에서 완성되었습니다. FFlabs 및 VideoLAN 개발자들과의 협업으로 이루어진 이 작업은 FFmpeg 역사상 수십 년 만에 가장 복잡한 리팩토링 중 하나로 평가받습니다. 이제 단일 프로세스 내에서 여러 인코더 인스턴스가 완벽하게 병렬로 실행되며, 이는 대규모 Transcoding 파이프라인을 운영하는 모든 기업에게 엄청난 컴퓨팅 리소스 절감을 가져다줍니다.

In-Loop Decoding: 실시간 품질 측정

PSNR, SSIM, VMAF 같은 시각적 품질 지표는 압축으로 인한 손실을 수치화하는 데 필수적입니다. VOD라면 인코딩이 다 끝난 후 원본과 비교하면 그만이지만, 라이브 스트리밍에서는 Latency 문제 때문에 실시간으로 이 지표를 뽑아내야 합니다.

이를 위해 Meta는 각 출력 레인의 비디오 인코더 바로 뒤에 디코더를 삽입하는 구조를 만들었습니다. 인코딩된 프레임을 즉시 다시 디코딩하여 압축 전 원본 프레임과 비교하는 것입니다.

이른바 In-loop decoding 기능은 FFmpeg 7.0부터 메인라인에 포함되었습니다. 이제 별도의 파이프라인을 구축할 필요 없이 단일 FFmpeg 명령어로 실시간 품질 측정이 가능해졌습니다.

Hacker News의 반응: 오픈소스 기여인가, 마케팅인가?

이 블로그 포스트에 대한 Hacker News 커뮤니티의 반응은 꽤나 날카로웠습니다. 기술적인 성취는 인정하지만, Meta의 태도에 대한 비판이 많았습니다.

가장 많이 나온 지적은 애초에 Upstream을 자주 했어야 하는 것 아니냐는 것입니다. 수년간 자신들만의 Fork를 유지하다가 이제 와서 커뮤니티를 위해 기여한 것처럼 포장하는 것이 위선적이라는 의견이죠.

하지만 현업에서 구르는 엔지니어로서 저는 Meta의 입장에 깊이 공감합니다. 당장 서비스가 터져나가고 배포 일정이 턱밑까지 다가온 상황에서, FFmpeg 메인테이너들과 아키텍처 방향성을 논의하며 우아하게 PR을 올릴 시간은 없습니다. 일단 내부적으로 패치해서 불을 끄고 보는 것이 현실입니다.

• 현실적인 문제: 사내의 특수한 유즈케이스를 범용적인 오픈소스 기능으로 다듬어 메인라인에 올리는 것은 내부 패치보다 수십 배의 리소스가 듭니다.
• 커뮤니티의 방향성: 아무리 좋은 기능이라도 오픈소스 메인테이너의 철학과 맞지 않으면 거절당하기 일쑤입니다.

또한, Meta가 자금을 충분히 지원하지 않는다는 비판도 있었습니다. 독일의 기술 펀드가 FFmpeg에 기여한 금액에 비해 Meta의 금전적 지원이 부족하다는 지적입니다. 하지만 저는 수십 년 된 C 기반의 복잡한 멀티미디어 프레임워크를 리팩토링하는 데 투입된 Meta 엔지니어들의 인건비와 시간이야말로 수백만 달러 이상의 가치가 있다고 봅니다.

결론: 기술 부채의 성공적인 청산

물론 Meta가 모든 것을 Upstream에 올린 것은 아닙니다. 자신들의 커스텀 ASIC인 MSVP(Meta Scalable Video Processor)를 위한 하드웨어 가속 패치는 여전히 내부에 남겨두었습니다. 외부 개발자들이 테스트할 수 없는 하드웨어 종속적인 코드를 억지로 올리는 것은 오히려 민폐이기 때문에 이는 매우 합리적인 결정입니다.

결과적으로 Meta는 낡아빠진 내부 Fork라는 거대한 기술 부채를 청산하는 데 성공했습니다. 이 과정에서 FFmpeg 커뮤니티는 최신 멀티 코어 환경에 걸맞은 강력한 병렬 처리 능력과 실시간 모니터링 기능을 얻었습니다.

기업이 오픈소스를 사용하는 방식에 있어 완벽한 정답은 없습니다. 하지만 기술 부채에 짓눌려 시스템을 방치하는 대신, 엄청난 리소스를 들여 메인라인과 동기화하고 커뮤니티에 환원한 Meta의 엔지니어링 결정은 충분히 가치 있는 작업이었습니다. FFmpeg 8.0을 프로덕션에 도입할 계획이 있다면, 이번 병렬 처리 아키텍처의 이점을 꼭 테스트해 보시길 권장합니다.