IBC2026 핵심 키워드: DMF, MXL, MoQ, 차세대 방송 기술 전망

‘Mr. DMF’가 말한 DMF와 MXL

이러한 키워드 중에서도 향후 방송 시스템을 논할 때 빼놓을 수 없다고 생각한 것이 DMF(Dynamic Media Facility)와 MXL(Media eXchange Layer)이다.

EBU 부스를 비롯해 Grass Valley, Sony, AWS, TAG Video Systems 등 많은 전시에서 MXL이라는 글자를 볼 수 있었다. EBU의 IBC2026 공식 페이지에도 다수의 DMF/MXL 세션과 대응 제조사의 데모가 나열되어 있었다.

그렇다면 DMF와 MXL은 대체 무엇일까? IBC의 EBU 부스에서 ‘Mr. DMF’라는 별명도 가지고 있는 EBU Senior IP Media Technology Architect인 Willem Vermost 씨에게 이야기를 들어보았다.

Vermost 씨가 처음으로 말한 것은, ‘고가의 방송 장비를 구매하고도 실제로 그 하드웨어를 유효하게 활용하고 있는가’라는 매우 단순한 문제 제기가 DMF 검토의 발단이 되었다는 이야기였다.

방송 사업자는 뉴스용 설비, 스포츠용 설비, 라디오 설비 등 각 피크 타임에 맞춰 전용 장비를 준비한다. 하지만 이들이 항상 풀 가동되는 것은 아니다. 이는 SDI를 ST 2110으로 대체해도 근본적으로 변하지 않는다. 전송 경로는 IP가 되지만, 그 양단에 특정 기능 전용 하드웨어가 존재한다면 설비 이용의 사고방식은 종래와 변함이 없기 때문이다.

한편 IT 세계에서는 상황이 크게 다르다. 범용 서버를 준비하고 Docker나 Kubernetes 등을 사용하여 필요한 애플리케이션을 필요한 때만 실행한다. 같은 계산 자원을 다양한 용도로 공유하는 것은 당연하게 여겨지고 있다.

그렇다면 방송 설비에서도 같은 일을 할 수 있지 않을까? 오전에는 라디오 제작, 낮에는 뉴스, 밤에는 스포츠 중계. 그 시간에 필요한 미디어 기능을 컨테이너로 실행하고, 종료되면 그 리소스를 해제한다. 스위처, 그래픽, EQ, 멀티뷰어, 인코더, 플레이아웃과 같은 ‘장비’를 범용 컴퓨터 상에서 동작하는 ‘기능’으로 바꾸어 가는 것. 이것이 DMF의 기본적인 발상이다.

EBU도 DMF를 ‘고정적인 하드웨어 중심의 설비에서 유연하고 확장 가능하며, 복원력 있고 상호 운용 가능한 Software Defined Infrastructure로 전환하기 위한 아키텍처’라고 정의하고 있다.

원점 중 하나는 도쿄 올림픽

흥미로웠던 점은 Vermost 씨가 DMF로 이어지는 자신의 경험으로 도쿄 올림픽을 꼽았다는 점이었다.

당시 벨기에 공영 방송국 VRT에 재직 중이던 Vermost 씨 등은 도쿄에서 여러 경기 스트림을 송출할 필요가 있었다. 하지만 벨기에에서 보면 경기 시간은 심야대였고, 종래형 제작 설비와 스태프를 준비하면 큰 비용이 발생했다.

이에 소프트웨어를 사용한 제작 시스템을 구축했다.

Vermost 씨에 따르면, 한 명의 엔지니어가 약 30일 만에 소프트웨어를 개발했다. SDI 스위처나 Audio over IP 등 기존 기술도 조합하면서, 한 명의 운영자가 세 개의 스트림을 다룰 수 있는 환경을 만들었다고 한다.

이 경험에서 보인 것은 ‘조작하는 UI와 실제로 미디어를 처리하는 기능은 같은 장소에 있을 필요가 없다’는 생각이었다.

이는 물리적인 조작 콘솔을 없앤다는 이야기가 아니다. Vermost 씨도 ‘버튼이나 T바를 없애고 싶지는 않다’고 강조한다. 중요한 것은 ‘Control / UI와 Media Function을 분리하는 것’이다.

운영자는 종래대로 T바나 버튼을 사용해도 좋다. 하지만 그 조작으로 움직이는 스위처 기능은 옆의 랙이 아니라 데이터 센터나 클라우드 상의 컨테이너에서 실행되어도 좋다. 이 분리야말로 DMF 개발의 중요한 출발점이었다.

ST 2110으로 바꾼 것만으로는 해결되지 않았던 것

하지만 미디어 기능을 소프트웨어화해 나가자 새로운 문제가 보이기 시작했다.

Vermost 씨는 다음과 같이 설명했다.

즉, ‘Software A → ST 2110 → NIC → Network → NIC → Software B’라는 경로가 된다.

Vermost 씨 등은 여기에 불필요한 처리와 지연이 발생한다는 점을 깨달았다. ‘같은 컴퓨터 상에 있는 소프트웨어끼리인데, 왜 영상을 한 번 ‘밖’으로 내보내야 하는가?’

이 문제를 해결하기 위해 필요했던 것이 소프트웨어 간에 직접 미디어를 주고받는 메커니즘이었다. 바로 그것이 MXL(Media eXchange Layer)이다.

DMF와 MXL의 관계

또 한 가지, Vermost 씨가 강조한 중요한 점이 있다. ‘DMF라는 규격이 발표된 것이 아니다’라는 점이다. ‘DMF는 아키텍처이며, 비전이다’라고 한다.

EBU는 2026년 4월 DMF Reference Architecture v2.0을 공개하고, 범용 컴퓨터, 미디어 교환, 미디어 기능, 컨트롤, 오케스트레이션 등의 관계를 정리했다. 특히 v2.0에서는 오케스트레이션을 여러 레이어에 걸친 기능으로 명확히 하고 있다.

EBU와 AMWA는 2025년 9월, 소프트웨어 정의형 동적 미디어 제작 환경을 실현하기 위한 참조 아키텍처, 베스트 프랙티스, 사양, 가이드라인, 비즈니스 모델 프레임워크를 작성하는 것을 주요 목적으로 Joint Taskforce on Dynamic Media Facilities(JT-DMF)의 설립을 발표했다. 공영 방송만의 구상이 아니라, 상업 방송국, 제조사, IT 벤더를 포함한 업계 공통의 틀로 확대하려 하고 있다.

즉, DMF는 ‘설계 사상/Reference Architecture’이며, MXL은 ‘그 안에서 최초로 구현된 공통 기술’이라는 관계이다.

SDK 제공에 의한 ‘Implement-Fist’ 접근 방식

EBU는 MXL을 규격으로 정리하고 있는 것이 아니라, 사양서와 오픈 소스 SDK로 제공하고 있다. 종래에는 사양서를 만들고 각 제조사가 그 사양을 읽고 각각 구현하는 단계를 거쳐야 했다. 그리고 마지막으로 Plugfest 등을 통해 ‘A사와 B사는 실제로 연결되는가’를 확인할 필요가 있었다.

하지만 MXL은 그와 다른 접근 방식을 취하고 있다. 제조사 각자가 같은 오픈 소스 코드를 기반으로 제품을 개발하는 ‘implement-first’라고 EBU가 설명하는 접근 방식이다. MXL 코드는 Linux Foundation 하에서 공개되어 있다.

Grass Valley도 독자 방식에서 MXL로

DMF/MXL의 맥락에서 흥미로웠던 것은 Grass Valley에서 들은 이야기였다.

이 회사는 DMF라는 단어가 등장하기 이전부터 스위처, 멀티뷰어, 그래픽, 플레이아웃 등을 소프트웨어로 구동하는 AMPP Platform 환경을 제공해왔다. 말하자면 DMF와 유사한 세계를 이미 상용화했던 제조사이다.

하지만 AMPP는 원래 MXL을 사용했던 것은 아니다. Grass Valley Japan의 미와 씨에 따르면, AMPP에는 소프트웨어 간에 미디어를 교환하는 독자적인 메커니즘이 있었고, 그 생각 자체는 MXL과 가까웠다고 한다. 그런데 EBU를 중심으로 MXL이 업계 공통의 메커니즘으로 자리 잡고 많은 제조사가 참여하게 되었다. 이에 Grass Valley도 독자 방식에 머무르지 않고 MXL로 전환하는 판단을 했다고 한다.

IBC2026에서는 AMPP가 MXL v1.1을 네이티브 지원한다는 발표가 있었다. MXL 플로우의 장비 검색 및 제어에는 NMOS를 이용하고, SDI, ST 2110, MXL, AMPP 애플리케이션을 동일한 환경에서 구동했다.

즉, ‘AMPP를 MXL로 대체한 것이 아니라, AMPP가 MXL을 통합했다’는 설명이었다.

한편, Vermost 씨와의 인터뷰에서는 흥미로운 지적이 있었다. 그가 그리는 DMF/MXL의 이상은 특정 제조사의 플랫폼에 의존하지 않는 환경이다. 범용 컴퓨터와 Kubernetes 등의 IT 기반 위에서 Sony, Grass Valley, Lawo, Riedel, 혹은 향후 등장할 AI 벤더의 소프트웨어를 자유롭게 조합하는 것이다. MXL은 그를 위한 공통 미디어 교환 레이어라는 생각이다.

Vermost 씨는 한 예로 Sony의 M2 Live를 들며, 컨테이너로 전개할 수 있는 구현을 DMF의 생각과 가깝다고 평가하는 한편, AMPP에 대해서는 Grass Valley의 플랫폼으로서 폐쇄적인 성격이 남아있다고 지적했다. 여기에는 EBU가 그리는 완전히 오픈된 DMF라는 이상과, Grass Valley가 AMPP라는 기존 상용 플랫폼을 MXL 대응시켜 나가는 현실적인 구현 간의 차이가 있다.

이 점에 대해 Grass Valley의 미와 씨는, ‘MXL이 공통화되는 것은 소프트웨어 간에 미디어를 교환하는 부분이지만, 그 위에서 어떤 애플리케이션을 실행할지, 어디에 컴퓨팅 리소스를 할당할지, 언제 중지할지, 시스템을 어떻게 감시할지, 이용 요금을 어떻게 관리할지와 같은 오케스트레이션 기능은 여전히 필요하다’고 말했다.

AMPP의 경우, 필요한 소프트웨어 모듈을 추가/중지할 수 있으며, 사용을 중지하면 과금도 중지된다.

미와 씨에 따르면, AMPP는 본방송과는 별도로 테스트 모드도 준비되어 있어, 워터마크는 들어가지만 과금 없이 시스템을 실행할 수 있다. 사전 구축이나 리허설은 테스트 모드에서 진행하고, 본방송 시에만 필요한 기능을 활성화하는 등의 운용도 가능해진다.

따라서 MXL이 ‘미디어 교환의 공통 레이어’인 반면, AMPP는 ‘애플리케이션이나 컴퓨터 자원, 운용, 과금을 묶는 상용 플랫폼’이라는 관계이다.

DMF/MXL로 실현되는 SDB(Software-Defined Broadcast)

필자가 NAB2026 전에 방문했던 캐나다 CBC/Radio-Canada의 몬트리올 본부나, IBC2026 후에 방문했던 France Télévisions 등에서는 발 빠르게 DMF/MXL 도입 검토에 착수했으며, JT-DMF에 따른 사양이 확정되고 벤더들이 대응해 온다면 즉시 도입할 것이라고 말했다. France Télévisions에서는 MoIP 대응 방송 장비의 본체는 방송국에서 떨어진 데이터 센터에 두고, 조작 관련 UI 부분만 본사에 설치하는 시스템을 이미 실현하고 있다. ST 2110에 이어 DMF/MXL이 일반화된다면, SDB(Software-Defined Broadcast)가 한 걸음 더 실현에 가까워질 것이다.

Sony는 InterBEE의 Sony 부스에서 ‘MXL’을 Sony는 어떻게 파악하고 있는가? Sony가 그리는 라이브 제작의 미래’라는 제목의 세미나를 개최하고, Sony가 추진하는 SDB의 미래상을 이야기할 것이라고 예고했다. (11월 20일 금요일 14시~14시 30분, https://x.gd/J3LNW)

또 다른 버즈워드 ‘MoQ’

IBC에서 화제가 되었던 또 다른 버즈워드가 ‘MoQ(Media over QUIC)’였다. 이 주제에 대해서는 프랑스의 인코더 제조사 Ateme와 오스트리아 공영 방송 ORF의 관련 회사인 Big Blue Marble에서 이야기를 들어보았다.

OTT의 ’15~20초’를 1초 이하로

MoQ는 Google이 개발한 통신 프로토콜의 제3세대 ‘HTTP/3’의 기반이기도 한 UDP 기반 트랜스포트 ‘QUIC’ 위에서 영상·음성을 ‘객체’로서 전송하는 메커니즘이다. 표준은 오픈이며, RTP 패킷이나 DASH 세그먼트 등 운반하는 객체를 유연하게 정의할 수 있다.

HTTP/2(TCP+TLS)에서는 하나의 TCP 연결로 여러 데이터(이미지나 CSS 등)를 병렬 전송할 수 있었지만, 패킷이 하나라도 손실되면 TCP의 메커니즘상 모든 데이터의 도착이 중단되는 문제(Head of Line Blocking)가 있었다. HTTP/3(QUIC)에서는 각 데이터 스트림이 독립적으로 처리되기 때문에, 일부 패킷이 사라져도 다른 데이터의 읽기가 중단되지 않는다.

또한 종래(TCP + TLS)의 절차에서는 통신을 시작하기 전에 여러 번 왕복하는 교환(핸드셰이크)이 필요했지만, HTTP/3에서는 전송 계층의 확립과 암호화(TLS 1.3)를 한 번에 수행하기 때문에 지연(RTT)을 대폭 줄이고, 한 번 연결된 상대라면 0-RTT(왕복 없음)로 데이터 전송을 시작할 수 있다.

Big Blue Marble에 따르면, 일반적인 OTT 전송에서는 지연이 15~20초 발생하고, 저지연 구성에서도 약 5초에 머무르는 반면, MoQ에서는 카메라 렌즈부터 시청자의 디스플레이까지(글래스 투 글래스) 약 1초, 혹은 그 이하를 실현했다고 한다.

Ateme: WebRTC의 후계로서, 우선 B2B부터

Ateme는 MoQ를 ‘WebRTC의 대체/후계를 목표로 하는 기술’로 위치시켰다. 당분간은 콘텐츠 프로바이더와 디스트리뷰터 간의 B2B 용도가 선행되고, 1초 미만의 지연이 효과적인 스포츠 인터랙션이나 베팅 등을 예상한다. 장기적으로는 같은 기반을 OTT/B2C 규모로 확대할 구상이다.

부스에서는 동사의 Titan Gateway로 인코딩한 영상을 MoQ 릴레이를 통해 디코더에 전달하고, 약 600ms의 지연으로 재생하는 데모가 시연되었다. TS/CMAF 어느 쪽의 객체에도 대응하며, DRM 암호화 통합 등 현재 HTTP 전송에서 실현하고 있는 기능을 MoQ 상에서도 제공할 방향이라고 한다.

흥미로운 것은 개인화라는 발상이다. 한 번 인코딩한 스트림을 여러 수신자에게 전달하고, 후단에서 각각이 그래픽이나 뉴스를 삽입하는 것이다. 1대1의 B2B에 그치지 않고, 1대다 또는 단말별 개별화로 발전시킬 전망이 이야기되었다. 다만 600ms는 어디까지나 당일의 데모 수치이며, 대규모 B2C 환경에서 동등한 성능이 확인된 것은 아니다.

Big Blue Marble: F1 중계로 실증, 5G Broadcast와의 이중화도

Big Blue Marble은 MoQ에 대해서는 제품 출시 전 개발 및 사내 랩 테스트 단계이지만, 지연 1초 이하를 유지한 채 최대 5,000의 동시 접속을 확인한 시험 결과를 소개했다. ORF의 F1 중계에 사용된 검증에서는 위성 방송 대비 약 1초, 지상파 대비 약 5초의 지연이라는 수치도 제시되었다.

이 회사가 강조한 점은 MoQ 자체는 비트레이트나 프레임 레이트를 규정하지 않는다는 점이다. 실제 지연은 전단의 인코더 설정이나 압축, 처리 속도에 좌우되며, 화질과의 트레이드오프도 존재한다. 1초 전후의 지연을 실현하려면 전송 계열 전체의 설계가 필수적이다.

더욱이 이 회사는 5G Broadcast와 MoQ를 조합한 이중화 구성도 제안했다. 양쪽 모두에 대응하는 단말이라면, 5G 방송 수신이 끊겼을 때 단말 측에서 인터넷 경유 MoQ로 자동 전환하여 모바일 시청의 연속성을 확보할 수 있다는 것이다. 다만 이 연계는 실험·검증 중이며, 부스에서 전환 자체의 시연은 없었다.

MoQ의 표준화와 구현은 향후 주목점

양사의 설명에서 알 수 있었던 것은, MoQ가 ‘방송 수준의 지연을 인터넷 전송으로 실현하는’ 현실적인 선택지가 되어가고 있는 한편, 현시점에서는 B2B 전송이나 랩 검증이 중심이며, 대규모 B2C 전송에서의 실적은 앞으로 나올 것이라는 점이다.

2025년 9월에는 Akamai, CDN77, Cisco, Synamedia, YouTube, Red5 등이 중심이 되어 업계 컨소시엄 ‘OpenMOQ Software Consortium’이 발족했다. IETF에서 표준화가 진행되는 MoQ Transport 프로토콜에 대해, 인제스트, 릴레이, 재생을 담당하는 오픈 소스 구현을 공동으로 개발하여 벤더 간의 상호 운용성을 확보하는 것이 목적이다.

이후에도 Bitmovin, EZDRM, MainStreaming 등이 참여했으며, 이번 취재한 Ateme도 멤버로 이름을 올리고 있다. 각 벤더가 독자적으로 구현을 진행하는 것이 아니라, 공통의 기반 위에서 호환성을 보장하는 틀이 갖춰지고 있다는 점은 MoQ 채택을 검토하는 방송 사업자에게 중요한 판단 재료가 될 것이다. MoQ의 표준화와 구현이 어디까지 진행되고, 기존 CDN이나 DRM, 광고 삽입 메커니즘과 어떻게 통합되어 갈 것인가. 2027년을 향해 주목해야 할 주제 중 하나이다.

MoQ의 표준화와 구현이 어디까지 진행되고, 기존 CDN이나 DRM, 광고 삽입 메커니즘과 어떻게 통합되어 갈 것인가. 2027년을 향해 주목해야 할 주제 중 하나일 것이다.