MLVC: 마이크로소프트가 H.265 대비 비트레이트를 75% 줄이는 뉴럴 비디오 코덱을 오픈소스로 공개

이 기사는 AI를 사용하여 영어에서 번역되었습니다. 원문 읽기

2026년 7월 24일, 마이크로소프트는 Linux and Open Source 블로그를 통해 ML Video Codec인 MLVC를 오픈소스로 공개한다고 발표했습니다. 코드는 github.com/microsoft/mlvc에 MIT 라이선스로 올라와 있으며, 학습된 가중치와 학습 스크립트, 여러 NPU를 대상으로 하는 변환 도구가 함께 들어 있습니다.

360p에서 동일한 화질을 얻는 데 필요한 비트레이트를 비교한 막대그래프. H.264는 1000 kbps, H.265는 약 500 kbps, 마이크로소프트의 뉴럴 코덱 MLVC는 122 kbps. Video Conferencing Dataset을 사용한 P.910 주관 평가 시험 수치.

이를 뒷받침하는 논문 MLVC: Multi-platform Learned Video Codec for Real-World Deployment는 한 달 앞서 arXiv에 공개되었습니다.

연구실 GPU에서 한 번 돌려본 데모가 아닙니다. MLVC는 마이크로소프트 리서치가 2021년부터 발표해 온 DCVC 계열의 제품화 버전이며, 마이크로소프트는 이미 Microsoft Teams의 P2P 통화에 배포를 진행 중이라고 밝혔습니다. 실사용 텔레메트리와 A/B 테스트를 병행하고, 하드웨어나 네트워크가 감당하지 못하면 기존 코덱으로 폴백합니다.

내세운 수치가 제대로 검증해 볼 만큼 크기 때문에, 이 글은 바로 그 작업을 합니다. 숫자 자체, 그 숫자가 실제로 측정하는 것, 저장소에 정말 들어 있는 것, 그리고 이 중 무엇이라도 올해 스트리밍 스택에 영향을 주는지 살펴봅니다.

짧은 설명이 먼저 필요하다면, 스트리밍 용어집에 MLVC란 무엇인가에 대한 간단한 정의를 두고 있습니다.

발표된 수치

마이크로소프트가 직접 제시한 비교입니다. 주관 화질이 동등한 조건에서:

해상도H.264 대비 비트레이트 절감H.265 대비 비트레이트 절감
360p87.8%75.5%
540p82.7%65.4%

구체적으로 바꾸면 기억하기 쉽습니다. H.264로 1 Mbps가 필요한 360p 30fps 통화가 MLVC에서는 약 122 kbps로 처리됩니다. 대략 8분의 1 수준의 비트를, 실시간으로, 노트북 NPU에서 해냅니다.

이제 단서 조항입니다. 이 부분이 꽤 중요합니다.

PSNR이 아니라 사람이 매긴 점수입니다

이 백분율은 MOS 기반이며, 사람이 직접 클립에 점수를 매긴 ITU-T P.910 주관 평가 시험에서 나왔습니다. 원본 소재는 마이크로소프트가 함께 구축해 공개한 Video Conferencing Dataset입니다. 즉 웹캠 앞의 사람을 360p와 540p로 찍은 영상을 눈으로 보고 판단한 결과입니다.

같은 코덱을 논문의 더 넓은 테스트 세트에서 PSNR로 측정하면 BD-rate 이득은 오히려 52% 부근에 자리합니다. 여전히 매우 큰 숫자지만 87.8%는 아닙니다.

기준점은 시중에서 가장 약한 H.265입니다

비교 대상은 인텔 퀵싱크의 하드웨어 H.265이지, 느린 프리셋으로 잘 조율한 x265가 아닙니다. 회의용 지연 시간에 묶인 하드웨어 인코더는 H.265가 낼 수 있는 성능의 하한이지 상한이 아닙니다.

또한 논문 어디에도 AV1이나 VVC와의 비교가 없습니다. 저자들은 그 이유를 설명합니다. VTM과 ECM은 상용 하드웨어 구현이 없어 실시간으로 견줄 대상이 없기 때문에 제외했다는 것입니다. 연구상의 판단으로는 타당하지만, 아직 아무도 MLVC를 최신 AV1 인코더와 나란히 보여 준 적이 없다는 뜻이기도 합니다.

진짜 성과는 압축률이 아니라 결정성입니다

비트레이트 숫자에 묻혀 버린 부분이자, 공학적으로는 더 흥미로운 이야기입니다.

뉴럴 코덱은 부호화 효율에서 기존 코덱을 앞선 지 꽤 되었습니다. 그런데도 배포할 수 없었던 이유는, 부호화한 기기와 다른 기기에서 안정적으로 복호할 수 없었기 때문입니다.

엔트로피 부호화는 인코더와 디코더가 동일한 확률을 계산해야 합니다. 같은 네트워크를 애플 뉴럴 엔진과 퀄컴 헥사곤에서 돌리면 부동소수점 결과가 일치하지 않습니다. 컴파일러가 선택하는 커널이 다르고, 연산자 융합 방식이 다르며, 반올림도 다르기 때문입니다. 그러면 비트스트림은 쓰레기 데이터로 복호됩니다.

논문은 여기에 수치를 붙였습니다. 제약 없는 DCVC-RT는 인코더와 디코더가 같은 플랫폼에 있을 때 BD-rate 기준 약 69.6%의 개선을 보입니다. 플랫폼이 달라지면 BD-rate가 무한대가 됩니다. 영상이 아예 복호되지 않는다는 말을 점잖게 표현한 것입니다.

해결 방식

MLVC는 양쪽 끝이 운으로 일치하기를 바라는 것을 그만두었습니다. 엔트로피 모델의 스케일 파라미터를 하이퍼프라이어를 통해 명시적으로 전송해, 양쪽이 각자 계산하는 대신 비트스트림에서 같은 값을 읽도록 했습니다.

그 주변에서도 팀은 결과가 갈릴 만한 요소를 전부 걷어냈습니다. 특이한 활성화 함수는 사라지고 ReGLU 게이팅을 곁들인 ReLU와 LeakyReLU로 대체되었습니다. INT8 양자화는 아예 배제했습니다. INT8 합성곱은 제조사 간 재현성이 없고, 구형 애플 실리콘에서는 어차피 FP16으로 흉내 내기 때문입니다. 전체가 FP16으로 동작합니다.

이 절제는 실제 압축 성능을 대가로 치릅니다. 지각 기반으로 학습한 DCVC-RT가 81.9%를 기록하는 자리에서 MLVC는 75.5%입니다. 마이크로소프트는 자사 소유가 아닌 하드웨어에서 복호되는 코덱을 얻기 위해 BD-rate 약 6포인트를 내놓았습니다.

영상을 실제로 서비스에 올려 본 사람이라면 이것이 명백히 옳은 맞교환임을 압니다. 그리고 학습형 코덱이 그 교환을 성사시킨 것은 이번이 처음입니다.

저장소에 실제로 들어 있는 것

직접 들여다볼 가치가 있습니다. 저장소는 발표문과 조금 다른 이야기를 들려주기 때문입니다.

저장소는 2026년 1월 28일에 만들어졌고, 이후 여섯 달 동안 라이선스와 README 초안, 마이크로소프트 표준 거버넌스 파일 외에는 아무것도 없었습니다. 실제 코드는 7월 22일 "Hello MLVC"라는 제목의 단일 커밋으로 들어왔고, 올린 사람은 논문 제1저자인 Tanel Pärnamaa입니다. 이 글을 쓰는 시점에 커밋 8개, 스타 189개, 포크 10개이며 태그된 릴리스는 하나도 없습니다.

즉 한 번에 던져진 코드이지 공개적으로 개발되어 온 프로젝트가 아닙니다. 비판이 아니라 적절한 기대치를 갖자는 이야기입니다. 열려 있는 이슈 네 건은 모두 transformers, jupyterlab, cryptography에 대한 Dependabot 업데이트입니다. 지금까지 병합된 유일한 외부 기여는 GCC 13 이상과 최신 Clang에서 C++ 엔트로피 코더가 빌드되도록 EntropyCoder.h에 #include <cstdint>를 추가한 한 줄짜리 수정입니다. 작지만 좋은 신호입니다. 마이크로소프트 외부의 누군가가 며칠 만에 빌드를 시도했고, 마이크로소프트가 그 패치를 받아들였다는 뜻이니까요.

제공되는 것

  • 체크포인트 4종. 파라미터 1830만 개의 전체 MLVC와 540만 개의 경량 MLVC-S가 각각 PSNR 최적화판과 지각 최적화판으로 제공됩니다. 지각 최적화판은 LPIPS와 얼굴 분할 마스크로 학습되어, 무엇을 위해 만들어졌는지가 그대로 드러납니다.
  • 전체 학습 파이프라인. 이미지 모델과 비디오 모델 모두를 다루며 YAML 설정으로 제어합니다. 마이크로소프트는 학습 데이터 수집 방법까지 문서화했는데, 이는 대부분의 공개 사례보다 앞선 수준입니다.
  • 내보내기 도구. 모델을 애플용 CoreML, 인텔과 OpenVINO용 ONNX, 퀄컴용 QNN으로 고정 입력 크기에서 변환합니다. 지원 런타임은 CPU와 GPU의 ONNX Runtime, ONNX Runtime QNN, OpenVINO, Windows ML입니다.
  • C++ rANS 엔트로피 코더. packages/msrtc_rans에 파이썬 바인딩과 함께 들어 있으며, BD-rate와 MS-SSIM, LPIPS, VIF, DeQA를 계산하는 벤치마크 도구도 포함됩니다.

들어 있지 않은 것은 애플리케이션에 링크할 수 있는 C++ 코덱 라이브러리입니다. 마이크로소프트는 후속 릴리스에서 제공하겠다고 밝혔습니다. 현재 사용 가능한 표면은 파이썬이며, 설치에는 Python 3.12 또는 3.13과 uv가 필요합니다.

프레임레이트가 실제로 놓이는 지점

속도야말로 이 이야기의 핵심이므로 해상도 사다리가 중요합니다. 논문에 실린 부호화 처리량입니다.

해상도MLVC, Apple M3 ProMLVC, 3개사 평균MLVC-S, Apple M3 Pro
360p129.5 fps103 fps미공개
540p65.7 fps49 fps미공개
720p33.8 fps미공개83.8 fps
1080p15.6 fps미공개39.5 fps

복호는 전 구간에서 부호화보다 초당 몇 프레임 느립니다. 인텔 루나레이크의 1080p 수치는 10.5 fps이며, 시험된 세 제조사는 애플 M3와 M4, 인텔 루나레이크, 퀄컴 스냅드래곤 X 엘리트입니다.

솔직한 요약은 이렇습니다. 실제로 내놓을 수 있는 수준은 세 제조사 모두에서의 540p 30fps이고, NPU 사용률은 절반 미만입니다. 실시간 1080p는 경량 모델에서, 애플에서만, 한 방향으로만 성립합니다. 논문은 또한 한 기기에서 1080p 이상을 동시에 부호화하고 복호하는 것은 여전히 과제라고 언급합니다. 양방향 통화에 필요한 것이 바로 그것인데 말입니다.

마이크로소프트의 로드맵도 이를 따릅니다. 먼저 540p를 안정화하고 손실 내성을 개선한 뒤, 1080p와 더 넓은 스트리밍 시나리오로 나아갑니다.

이것을 스트리밍 래더에 넣을 수 없는 이유

스트리밍에서 코덱의 운명을 결정한 것은 한 번도 압축 효율이 아니었습니다. 디코더가 결정합니다.

우리는 HEVC가 약속된 미래가 되지 못한 과정에 관해 글 한 편을 따로 썼습니다. 원인은 라이선스와 기기 지원이었지 부호화 도구가 아니었습니다. AV1도 휴대폰에 하드웨어 디코더가 실리고 나서야 실제 배포에서 의미를 갖기 시작했습니다.

포맷은 곧 가중치입니다

MLVC는 그 문제의 더 가혹한 판본을 안고 있습니다. 학습된 가중치가 곧 포맷이기 때문에 MLVC 비트스트림 표준이라는 것이 존재하지 않습니다. 어떤 스트림을 복호할 수 있는 기기는, 그것을 부호화한 모델과 정확히 같은 모델을 갖고 있으면서 연산을 재현할 만큼 충실히 실행하는 기기뿐입니다.

적합성 스트림도 없고 MIME 타입도 없습니다. 패키징 이야기도, DRM 이야기도 없으며, 스마트 TV와 셋톱박스, 브라우저 어디에도 이를 재생할 수 있는 것이 없습니다. CDN은 전달할 수 있지만, 반대편에는 그것을 열 수 있는 것이 아무것도 없습니다.

그 콘텐츠는 당신의 콘텐츠가 아닙니다

인상적인 수치는 저해상도의 정적인 토킹헤드 영상에서 나왔고, 모델은 얼굴 ROI 마스크를 이용해 얼굴로 학습되었습니다. 스포츠, 필름 그레인, 빠른 패닝, 움직임이 많은 장면이야말로 기존 코덱이 휴리스틱의 값어치를 하는 영역인데, 논문은 그에 관해 아무것도 주장하지 않습니다.

오히려 약점 하나를 수치로 밝힙니다. 장기 참조 메커니즘은 급격한 장면 전환에서 BD-rate를 약 2%포인트 악화시키며, 운영 시 장면 전환 감지로 완화한다고 합니다. 그런데 영화란 대부분이 장면 전환입니다.

그리고 아무도 전력 소비를 재지 않았습니다

논문 스스로 마지막에 꼽은 한계입니다. 실시간성은 해결했으니 다음 전선은 전력 소비라고 저자들은 말합니다. 두 시간짜리 영화의 모든 프레임마다 NPU에서 신경망을 돌리는 것은, 배터리로 구동되는 기기에서는 10년간 최적화되어 온 고정 기능 디코더와 전혀 다른 이야기입니다.

지금 실제로 쓸모 있는 영역

양쪽 끝이 모두 직접 통제하는 컴퓨터이고, 제약이 실리콘이 아니라 네트워크인 모든 곳입니다.

우선 화상회의이며, 그래서 Teams가 출시 무대가 되었습니다. 열악한 업링크를 통한 기여 회선, 원격 제작, 드론, 로보틱스, 감시 회선, 클라우드 게이밍이나 원격 렌더링도 해당합니다. 마이크로소프트는 발표문에서 스트리밍과 VOD와 더불어 이 모든 분야에 대한 협력을 명시적으로 요청했고, NPU 지원 범위를 넓히는 플랫폼 이식도 환영한다고 밝혔습니다.

최신 하드웨어에서 실시간 P2P 제품을 만들고 있다면 지금 반나절을 투자할 가치가 있습니다. OTT 서비스를 운영 중이라면 아직입니다.

코덱 종사자가 정말 주목해야 할 부분

75%가 아닙니다. 기울기입니다.

마이크로소프트는 MLVC의 부호화 효율이 모델 용량과 학습 연산량에 따라 좋아진다고 주장합니다. 지난 몇 년간 다른 모든 머신러닝 시스템이 그러했듯이 말입니다.

기존 코덱은 세대당 대략 30~50% 개선되지만, 한 세대에는 10년에 가까운 표준화 작업이 필요하고, 그 뒤로 하드웨어 보급을 몇 년 기다려야 하며, 이어서 특허 풀을 둘러싼 논쟁이 붙습니다. 학습형 코덱이 연산을 더 투입할 때마다 계속 좋아지고, 게다가 이미 어디에나 실려 있는 NPU에서 돌아간다면 그 경쟁의 형태 자체가 달라집니다.

라이선스는 MIT이며, 이는 HEVC를 죽인 또 다른 요인을 조용히 걷어냅니다. 그리고 이 문제는 평범한 엔지니어링 과제로 환원됩니다. 모델 버전을 배포하고, 코덱을 협상하듯 협상하며, 상대편이 실행하지 못하면 폴백하면 됩니다.

그 어느 것도 올해 일어나지 않습니다. "내 M3에서 540p로 돌아간다"와 "어느 집 거실의 5년 된 TV에서 재생된다" 사이의 간극은, 지금껏 모든 코덱이 건너는 데 15년이 걸린 바로 그 간극입니다. 그래도 압축 기술이 논문을 읽어 볼 만큼 흥미로워진 것은 오랜만이고, 이 논문은 한 시간을 쓸 값어치가 있습니다.

그래서 무엇을 해야 하나

인코딩 래더에서 바꿀 것은 없습니다. 도달 범위를 위해 H.264를, 기기가 지원하는 곳에서는 HEVC와 AV1을 계속 서비스하고, 다음 세 가지가 일어나면 그때 다시 살펴보십시오.

  • 애플의 MLVC-S만이 아니라, 전체 모델에서의 실시간 1080p.
  • 실제로 제품에 링크할 수 있는 C++ 라이브러리.
  • 마이크로소프트 자사 제품 밖의 디코더.

궁금하다면 저장소를 클론해 보십시오. 학습 파이프라인과 크로스 플랫폼 분석은 뉴럴 코덱을 직접 출시하든 아니든 배울 점이 있습니다. INT8 양자화가 제조사 간에 갈리는 이유를 다룬 부록은, 보통이라면 훨씬 긴 설명이 필요한 문제를 압축해 설명합니다.

자주 묻는 질문

MLVC는 무료로 사용할 수 있나요?
네. 마이크로소프트가 MIT 라이선스로 공개했으며, 모델 소스 코드와 학습된 가중치, 학습 스크립트가 대상입니다. 특허 풀이 따라붙지 않는데, 이는 HEVC와의 의미 있는 차이입니다.

MLVC를 스마트 TV나 브라우저로 스트리밍할 수 있나요?
아니요. 복호에는 신경망을 실행할 수 있는 기기와, 해당 스트림을 부호화한 것과 정확히 같은 모델이 필요합니다. 현재 MLVC 디코더를 갖춘 TV, 셋톱박스, 휴대폰, 브라우저는 없으며, 이들이 구현할 비트스트림 표준도 존재하지 않습니다.

MLVC는 실제로 대역폭을 얼마나 줄이나요?
마이크로소프트는 360p에서 H.264 대비 87.8%, 하드웨어 H.265 대비 75.5% 낮은 비트레이트를 ITU-T P.910에 따른 사람의 평가로 제시합니다. 더 넓은 테스트 세트에서 PSNR로 측정하면 절감폭은 52% 부근입니다. 두 수치 모두 화상회의 콘텐츠에서 하드웨어 인코더와 비교한 값입니다.

MLVC에는 어떤 하드웨어가 필요한가요?
NPU입니다. 마이크로소프트는 M3와 M4의 애플 뉴럴 엔진, 인텔 루나레이크, 퀄컴 스냅드래곤 X 엘리트에서 시험했고, 세 제품 모두에서 NPU 용량의 절반 미만으로 실시간 540p 30fps를 달성했다고 밝혔습니다.

MLVC가 AV1보다 나은가요?
그 비교는 공개된 적이 없습니다. 논문은 H.264와 H.265만을 대상으로 측정했고, AV1과 VVC, ECM은 실시간으로 비교할 상용 하드웨어 구현이 없어 제외했습니다.

MLVC와 DCVC의 차이는 무엇인가요?
DCVC는 마이크로소프트 리서치가 2021년부터 발표해 온 뉴럴 코덱 계열입니다. MLVC는 그 제품화 버전으로, 압축 효율 약 6포인트를 내주는 대신 서로 다른 제조사의 NPU에서 안정적으로 복호할 수 있는 능력을 얻었습니다.

이것이 우리 서비스에 어떤 의미인지 판단이 필요하신가요?

코덱 결정은 잘못되면 비용이 큽니다. 그리고 비용의 대부분은 비트레이트가 아니라 몇 년 뒤 기기 지원과 라이선스에서 드러납니다. 스트리밍과 방송 전문 인력이 코덱과 인코딩 래더, 배포 스택을 대규모로 운영해 온 경험을 바탕으로, 실제로 겪고 있는 문제를 직접 상의하실 수 있습니다.