Media over QUIC — MoQ — 는 2025-2026년 가장 많이 논의되는 차세대 스트리밍 프로토콜입니다. 블로그 글이 쏟아지고, 컨퍼런스 발표가 줄줄이 이어지며, CDN 업체들은 앞다투어 지원을 발표하고 있습니다. 라이브 스트리밍 업계에서 일한다면, 아마 이런 질문을 받아보셨을 것입니다: MoQ로 전환해야 하나요?
현재 제품을 출시하고 있는 대부분의 경우, 짧은 답변은 아니요 — 아직은 아닙니다입니다. 그러나 MoQ는 이해할 가치가 있습니다. MoQ가 해결하려는 문제들은 실제로 존재하며, 프로덕션 준비가 되기까지의 타임라인이 이제 수년이 아닌 수개월 단위로 측정되고 있기 때문입니다.
이 글에서는 MoQ가 실제로 무엇인지, 2026년 3월 현재 어디까지 와 있는지, HLS, WebRTC, SRT와 비교해 무엇이 달라지는지 — 그리고 우리가 실제로 배포한 두 제품에 적합한지 설명합니다: WeSpeakSports(WebRTC를 통한 실시간 팬 오디오 해설)와 DJing Stream(SRT 및 HLS 무손실을 통한 방송급 DJ 오디오).
MoQ가 실제로 무엇인가
MoQ는 Media over QUIC의 약자입니다. 2022년에 시작된 IETF 워킹 그룹의 노력으로, QUIC(HTTP/3의 기반이 되는 전송 계층) 위에 구축된 새로운 미디어 전송 프로토콜을 정의하기 위한 것입니다.
핵심 전송 사양인 draft-ietf-moq-transport는 2026년 3월에 버전 17에 도달했습니다. 스트리밍 포맷 사양(draft-ietf-moq-msf)도 진행 중이며, CMAF 패키징 및 헤더 압축에 대한 보조 초안도 함께 작업되고 있습니다. 이 중 아직 최종 확정된 RFC는 없습니다.
핵심적으로 MoQ는 publish/subscribe 프로토콜입니다. 퍼블리셔는 명명된 미디어 객체(오디오 프레임, 비디오 프레임, 메타데이터)를 릴레이에 전송하고, 구독자는 명명된 트랙을 구독하여 이를 수신합니다. 이는 HLS(세그먼트에 대한 HTTP 요청/응답)와 WebRTC(SDP/ICE를 통한 피어 투 피어 세션 협상) 모두와 근본적으로 다릅니다.
MoQ는 QUIC 스트림과 데이터그램 위에서 실행되며, 네이티브로 또는 WebTransport(QUIC용 브라우저 API)를 통해 동작합니다. 이를 통해 QUIC의 멀티플렉싱, 우선순위 지정 및 부분 신뢰성 기능에 접근할 수 있습니다 — 즉, 프로토콜이 설계상 재전송을 기다리며 전체 스트림을 멈추는 대신 늦은 비디오 프레임을 드롭할 수 있습니다.
MoQ가 대체하려는 것
Cisco의 Cullen Jennings(MoQ 워킹 그룹 참여자)에 따르면, 현재 스트리밍 세계에는 두 개의 사일로가 있습니다. 한쪽에서는 Netflix와 YouTube 같은 서비스가 HTTP 기반 CDN을 통해 대규모로 미디어를 제공하지만, 수 초의 지연 시간이 발생합니다. 다른 한쪽에서는 Zoom 및 WebRTC 기반 플랫폼 같은 화상회의 도구가 거의 실시간으로 미디어를 전달하지만, 대규모 시청자에게 비용 효율적으로 확장할 수 없습니다.
MoQ는 기여(수집)부터 배포(시청자 전달)까지, 그 사이에 CDN 호환 릴레이 인프라를 두고, 실시간과 준실시간 사용 사례 모두를 제공할 수 있는 단일 프로토콜로 이 두 세계를 연결하는 것을 목표로 합니다.
MoQ의 현재 위치 (2026년 3월)
현재 상태를 정확히 짚어보겠습니다:
사양이 거의 완성되었지만 아직 마무리되지 않았습니다. 전송 초안은 버전 17이며 빠르게 반복되고 있습니다. 스트리밍 포맷 초안은 2026년 1월에 발표되었습니다. CMAF 패키징 및 헤더 압축에 대한 활발한 보조 작업이 진행 중입니다. 하지만 아직 비준된 RFC는 없습니다.
Safari/WebTransport 격차가 줄어들고 있습니다. 브라우저에서의 MoQ는 WebTransport에 의존하며, 이는 HTTP/3와 QUIC가 필요합니다. Chrome과 Firefox는 이미 WebTransport를 지원합니다. Safari가 유일한 미지원 브라우저였지만 — Apple이 Safari 26.4 베타(2026년 2월)에 WebTransport 지원을 추가했으며, 이는 WebKit의 공식 Interop 2026 약속 사항입니다. 2026년 3월 현재, 아직 안정 Safari 릴리스에는 포함되지 않았지만, 이제 여부가 아닌 다음 OS 사이클에서 언제의 문제입니다. 브라우저를 통해 iPhone 및 iPad 사용자를 대상으로 하는 제품의 경우, 격차가 거의 해소되었습니다.
초기 프로덕션 배포가 존재하지만 제한적입니다. Nanocosmos는 MonteVIDEO Summer Project에서 엔드투엔드 MoQ 전송(OBS 수집부터 글로벌 시청자까지)을 시연했습니다. Cloudflare가 MoQ 베타를 출시했습니다. Red5는 2026년 말까지 MoQ 지원을 발표했습니다. 그러나 이들은 얼리 어답터 배포이지, 주류 인프라는 아닙니다.
커뮤니티는 성숙도에 대해 솔직합니다. Twitch(현 Discord)에서 최초의 MoQ 구현 중 하나를 만들고 moq-lite 간소화 초안을 작성한 Luke Curley조차도, 전체 MoQ 전송 사양이 "너무 복잡해졌으며" "메시지, 선택적 모드, 반쯤 완성된 기능이 너무 많다"고 명시적으로 밝히고 있습니다. 그의 moq-lite 초안은 이러한 복잡성에 대한 대응입니다.
업계 베테랑들은 신중합니다. BlogGeek.me의 Tsahi Levent-Levi는 2026년에 개발자들이 MoQ보다 WebRTC에 대해 더 많이 불평할 것이라고 예측했습니다 — MoQ가 더 낫기 때문이 아니라, MoQ 사용자들이 아직 거친 부분을 예상하는 얼리 어답터이기 때문입니다. 실제 현장의 기대치를 감당하며 모든 곳에서 프로덕션으로 운영되고 있는 것은 WebRTC입니다.
MoQ가 HLS와 비교해 바꾸는 것
HLS(HTTP Live Streaming)는 미디어를 세그먼트로 분할하고, HTTP 서버에 기록한 뒤, 플레이어가 재생 목록을 통해 새 세그먼트를 폴링하는 방식으로 작동합니다. 성숙하고, CDN 친화적이며, 광범위하게 배포되었고, RFC 8216 및 Apple의 HLS 저작 사양에 잘 문서화되어 있습니다. Low-Latency HLS(LL-HLS)는 지연 시간을 대략 2-4초까지 줄입니다.
MoQ는 전송 모델을 여러 면에서 변경합니다:
폴링에서 푸시로. HLS 플레이어는 세그먼트를 요청합니다. MoQ 구독자는 게시되는 즉시 객체를 수신합니다. 이로써 폴링 지연 시간이 제거됩니다.
세그먼트에서 객체로. HLS는 수 초 단위의 세그먼트(또는 LL-HLS의 부분 세그먼트)로 동작합니다. MoQ는 프레임 수준에서 동작할 수 있습니다. 단일 비디오 프레임이나 오디오 프레임이 개별적으로 주소 지정 가능하고, 개별적으로 전달 가능한 객체가 될 수 있습니다.
TCP에서 QUIC으로. HLS는 HTTP/TCP 위에서 실행됩니다. TCP 패킷이 손실되면, 그 뒤의 모든 것이 멈춥니다(헤드 오브 라인 블로킹). MoQ는 QUIC 위에서 실행되며, 스트림이 독립적이므로 — 하나의 스트림에서 패킷이 손실되어도 다른 스트림을 차단하지 않습니다.
명시적 우선순위 지정. MoQ의 전송 초안은 프로토콜 수준에서 우선순위 및 전달 순서를 정의합니다. 혼잡 상황에서 릴레이는 모든 것을 동등하게 지연시키는 대신 낮은 우선순위의 객체(예: B-frames)를 드롭할 수 있습니다.
통합된 수집 및 배포. 현재 대부분의 라이브 워크플로우는 기여에 하나의 프로토콜(RTMP, SRT, WHIP)을, 배포에 다른 프로토콜(HLS, DASH)을 사용합니다. MoQ는 단일 프로토콜로 두 경로를 모두 제공할 수 있어, 오리진 서버에서의 리패키징 단계를 제거할 수 있습니다.
HLS가 여전히 우세한 경우
이 중 어느 것도 HLS가 구식이라는 것을 의미하지 않습니다. HLS는 다음과 같은 경우에 여전히 더 강력한 선택입니다:
- 수 초의 지연 시간이 완전히 허용 가능한 경우
- 광범위한 기기 호환성이 필수적인 경우(모든 휴대폰, TV, 셋톱박스가 HLS를 재생합니다)
- 기존 CDN 및 도구 투자가 잘 작동하고 있는 경우
- 운영의 단순성과 실전 검증된 안정성이 지연 시간을 더 줄이는 것보다 중요한 경우
표준 OTT 라이브 및 VOD 전송 — 스트리밍 트래픽의 압도적 다수를 차지하는 — 에서 HLS는 고장 나지 않았으며, MoQ가 존재하지 않는 문제를 해결하는 것도 아닙니다.
MoQ가 WebRTC와 비교해 바꾸는 것
WebRTC는 실시간 피어 투 피어 통신을 위해 설계되었습니다: 화상 통화, 화면 공유, 1대1 또는 소그룹 대화. 업계는 이를 원래 범위를 훨씬 넘어 확장해 왔으며, SFU(Selective Forwarding Unit) 아키텍처를 사용하여 WebRTC를 더 큰 규모의 시청자에게 확장하고 있습니다.
MoQ는 여러 중요한 면에서 WebRTC와 다릅니다:
아키텍처. WebRTC는 SFU를 통해 중재되더라도 근본적으로 세션 지향 피어 투 피어 프로토콜입니다. MoQ는 처음부터 릴레이와 CDN 스타일 배포를 중심으로 설계된 클라이언트-서버 publish/subscribe 프로토콜입니다.
확장성 모델. WebRTC를 확장하려면 전용으로 구축된 고비용의 SFU 인프라가 필요합니다. MoQ 릴레이는 기존 CDN 인프라와 통합되도록 설계되었습니다 — HTTP/3 서버를 확장하여 MoQ 트래픽을 처리할 수 있으며, 이것이 Akamai와 YouTube 같은 CDN 벤더가 적극적으로 참여하고 있는 이유입니다.
복잡성. WebRTC는 상당한 복잡성을 수반합니다: SDP 오퍼/앤서 협상, ICE 후보 수집, NAT 트래버설을 위한 STUN/TURN 서버, 암호화를 위한 SRTP, 데이터 채널을 위한 SCTP. MoQ의 연결 설정은 더 간단합니다 — QUIC 핸드셰이크 후 subscribe/publish 메시지가 이어집니다.
코덱 유연성. WebRTC의 코덱 협상은 프로토콜에 긴밀하게 결합되어 있습니다. MoQ는 전송 수준에서 코덱에 구애받지 않습니다 — 미디어 포맷은 애플리케이션 계층(MSF, LOC 또는 커스텀 컨테이너)에서 처리됩니다.
브라우저 의존성. 두 프로토콜 모두 웹 기반 전달을 위해 브라우저 API에 의존합니다. WebRTC는 범용적인 브라우저 지원을 갖추고 있습니다. MoQ는 WebTransport에 의존하는데, Safari는 베타(26.4, 2026년 2월)에서야 추가했으며 아직 안정 버전을 출시하지 않았습니다. 이 격차는 좁혀지고 있지만, 현재 MoQ에 대한 실질적인 고려 사항입니다.
WebRTC가 여전히 우세한 경우
WebRTC는 다음과 같은 경우에 여전히 더 나은 선택입니다:
- 진정한 양방향 실시간 통신이 필요한 경우(화상 통화, 화상 회의)
- Safari/iOS를 포함한 모든 플랫폼에서의 브라우저 호환성이 필요한 경우
- 사용 사례가 피어 투 피어 또는 소그룹이며 CDN 규모의 배포가 필요 없는 경우
- 검증된 프로덕션급 도구 및 SDK 성숙도가 중요한 경우
MoQ가 SRT와 비교해 바꾸는 것
SRT(Secure Reliable Transport)는 예측 불가능한 네트워크를 통해 고품질 미디어를 A 지점에서 B 지점으로 전송하는 데 탁월합니다. AES 암호화, ARQ(Automatic Repeat Request)를 통한 패킷 손실 복구, 적응형 비트레이트 지원을 제공합니다. SRT는 수집 워크플로우(카메라에서 스튜디오로, 원격 프로덕션에서 클라우드 인코더로)에 널리 채택되어 있지만, DJing Stream이 보여주듯이 포인트 투 포인트 배포 프로토콜로도 사용됩니다.
MoQ와 SRT는 겹치지만 서로 다른 목적을 제공합니다:
SRT는 포인트 투 포인트; MoQ는 publish/subscribe. SRT는 하나의 송신자를 하나의 수신자에 연결합니다. MoQ는 릴레이를 통한 1대다 배포를 네이티브로 지원합니다.
SRT는 전달을 보장; MoQ는 보장하지 않을 수 있습니다. SRT의 ARQ 메커니즘은 손실된 모든 패킷을 재전송하여 무손실 전달을 보장하지만, 패킷 손실 시 지연 시간이 추가됩니다. MoQ는 부분 신뢰성으로 구성할 수 있습니다 — 늦은 객체를 재전송하는 대신 드롭합니다 — 이는 라이브 지연 시간에 민감한 전달에는 더 낫지만, 모든 샘플이 중요한 경우에는 허용할 수 없습니다.
SRT는 성숙하고 배포되어 있음; MoQ는 등장 중. SRT는 광범위한 하드웨어 및 소프트웨어 지원(OBS, vMix, FFmpeg, Haivision, 모든 주요 인코더)을 갖추고 있습니다. MoQ는 초기 단계의 구현을 가지고 있습니다.
SRT가 여전히 우세한 경우
SRT는 다음과 같은 경우에 더 강력한 선택입니다:
- 사용 사례가 포인트 투 포인트인 경우(소스에서 인코더로, 인코더에서 오리진으로, 또는 현장 직접 배포)
- 무손실 전달이 절대 최소 지연 시간보다 더 중요한 경우
- 워크플로우에 이미 SRT를 지원하는 전문 방송 장비가 포함된 경우
- 비트 수준의 오디오 충실도가 양보할 수 없는 조건인 경우
사례 연구: WeSpeakSports — WebRTC를 통한 실시간 팬 해설
WeSpeakSports는 실시간 팬 오디오 해설 플랫폼입니다. 팬들은 스포츠 경기 중 실시간 오디오 해설을 만들거나 청취합니다 — 축구, 농구, 럭비, F1 등. 이 앱은 iPhone, iPad, Mac(Apple Silicon) 및 Vision Pro에서 사용할 수 있습니다.
현재 아키텍처는 오디오 스트리밍에 WebRTC를 사용합니다. 팬 해설자가 자신의 기기에서 오디오를 방송하면, 청취자가 거의 실시간으로 수신합니다. 오디오는 음악 품질이 아닌 음성 품질입니다 — 명료성과 낮은 지연 시간이 오디오 마니아 수준의 충실도보다 훨씬 더 중요합니다.
MoQ가 WeSpeakSports에 적합할까요?
이론적으로는 그렇습니다 — 이 사용 사례에 매우 적합합니다. WeSpeakSports는 실시간 기대치를 가진 1대다 라이브 오디오 방송입니다. 이것은 정확히 MoQ가 채우도록 설계된 격차입니다: 효율적인 WebRTC 확장에는 청취자가 너무 많고, HLS에는 지연 시간에 너무 민감합니다.
MoQ의 publish/subscribe 모델은 WeSpeakSports 아키텍처에 자연스럽게 매핑됩니다: 해설자가 오디오 트랙을 게시하고, 청취자가 구독하며, CDN 릴레이가 배포를 처리합니다. 이는 WebRTC SFU 인프라보다 확장이 더 간단하고 저렴할 것입니다.
실제로는 아직 아닙니다 — 두 가지 확실한 이유 때문입니다:
- Safari/iOS가 거의 다 왔지만, 아직은 아닙니다. WeSpeakSports는 iOS 18.0이 필요합니다. 앱의 주요 사용자층은 iPhone에 있습니다. 브라우저에서의 MoQ는 WebTransport에 의존하는데, Apple이 Safari 26.4 베타에 추가했지만 아직 안정 릴리스에는 포함되지 않았습니다. 네이티브 iOS 앱의 경우에도, Apple 플랫폼용 프로덕션 준비된 MoQ SDK가 현재 존재하지 않습니다. iOS의 WebRTC 스택(Apple의 내장 WebKit 지원 및 성숙한 서드파티 SDK를 통해)은 검증되었고 작동합니다.
- 성숙도. WeSpeakSports는 실제 사용자가 있는 출시된 제품입니다. 전송 계층을 검증된 프로토콜에서 1.0 이전 사양으로 교체하는 것은 시기상조입니다. WebRTC가 현재 규모를 처리하고 있습니다. 마이그레이션의 복잡성 비용은 현재 사용자 기반으로는 정당화되지 않습니다.
재평가 시점
MoQ가 WeSpeakSports에 대해 평가할 가치가 생기는 시점:
- WebTransport가 안정 Safari에 탑재될 때 — Safari 26.4 베타를 감안하면 이제 임박했습니다 — 그리고 iOS/macOS용 성숙한 네이티브 MoQ SDK가 등장할 때
- 사용자 기반이 WebRTC SFU 비용이 의미 있는 제약이 되는 규모로 성장할 때
- MoQ 릴레이 인프라가 SLA 약속이 있는 최소 두 개의 CDN 제공업체에서 사용 가능할 때
- MoQ 전송 사양이 RFC 상태에 도달할 때
그 시점에서 MoQ는 배포 아키텍처를 의미 있게 단순화하고 청취자당 비용을 줄일 수 있습니다. 해설자-릴레이-청취자 모델은 교과서적인 MoQ 사용 사례입니다. 적합성이 아닌 타이밍의 문제입니다.
사례 연구: DJing Stream — SRT를 통한 방송급 DJ 오디오
DJing Stream은 매우 특정한 사용 사례를 위해 설계된 macOS 앱입니다: DJ의 셋업에서 공연장의 사운드 시스템으로, 인터넷을 통해, 실시간으로 방송급 오디오를 스트리밍하는 것입니다. 이 아키텍처는 오디오 품질을 무엇보다 우선시합니다.
현재 스택은 실시간 배포에 SRT를 사용합니다 — DJ의 Mac에서 공연장의 사운드 시스템으로 48kHz의 24비트 PCM 스테레오 오디오(약 2.3 Mbps)를 전달합니다. 원격 청취자에게 더 넓게 배포하기 위해, 오디오는 무손실 오디오가 포함된 HLS로도 제공될 수 있습니다. 전체 설계 철학은 DJ의 오디오가 물리적 케이블 연결과 동일한 충실도를 가져야 한다는 것입니다.
MoQ가 DJing Stream에 적합할까요?
아니요 — 이것은 타이밍 문제가 아닙니다. MoQ는 DJing Stream의 요구사항과 근본적으로 맞지 않습니다.
그 이유는 다음과 같습니다:
- 무손실 전달은 양보할 수 없습니다. DJing Stream은 비압축 PCM 오디오를 전송합니다. 모든 샘플이 중요합니다. SRT의 ARQ 재전송은 모든 패킷이 도착하도록 보장합니다 — 손실이 발생하면 오디오를 드롭하는 대신 지연 시간을 추가합니다. MoQ의 부분 신뢰성 모델은 라이브 비디오에서의 핵심 장점 중 하나이지만, 방송급 오디오에는 정확히 잘못된 트레이드오프입니다. 드롭된 오디오 프레임은 클럽 사운드 시스템에서 들을 수 있는 글리치입니다. 이는 허용할 수 없습니다.
- 포인트 투 포인트가 주요 사용 사례입니다. DJing Stream의 핵심 시나리오는 한 DJ가 한 공연장으로 스트리밍하는 것입니다. 이것은 배포 문제가 아닌 포인트 투 포인트 링크입니다. MoQ의 publish/subscribe 릴레이 모델은 이 토폴로지에서 이점 없이 복잡성만 추가합니다.
- 브라우저 요구사항이 없습니다. DJing Stream은 공연장 하드웨어에 연결하는 네이티브 macOS 앱입니다. 루프에 웹 브라우저가 없습니다. WebTransport/Safari 격차는 무관하지만, MoQ의 주요 장점인 브라우저 네이티브 전달 역시 마찬가지입니다.
- SRT가 이미 적합한 도구입니다. SRT는 정확히 이를 위해 설계되었습니다: 예측 불가능한 네트워크를 통한 고품질 미디어의 안정적이고, 암호화된, 저지연 전송. 방송 프로덕션에서 실전 검증되었습니다. 모든 인코더와 미디어 서버가 이를 지원합니다. DJ에서 공연장으로의 배포 링크에서 SRT를 MoQ로 교체하는 것은 의미 있는 이점 없이 보장된 전달을 포기하는 것을 의미합니다.
- HLS 무손실이 배포 측면을 처리합니다. 더 넓은 시청자(웹 청취자)에게 배포하는 부차적 사용 사례의 경우, 무손실 오디오 코덱이 포함된 HLS는 검증되었고 모든 기기와 호환됩니다. 원격 청취자의 지연 시간 허용치는 공연장 자체보다 높으므로, HLS의 세그먼트 기반 모델은 완벽히 적합합니다.
재평가 시점
솔직히? 핵심 DJ-공연장 링크에 대해서는 아마 영원히 없을 것입니다. SRT가 DJing Stream이 필요로 하는 것을 정확히 수행하며, MoQ의 설계 목표(혼잡 시 허용 가능한 품질 손실을 동반한 확장 가능한 배포)는 DJing Stream의 설계 목표(모든 오디오 샘플의 무손실 전달)와 반대됩니다.
MoQ가 DJing Stream에 관련될 수 있는 유일한 시나리오는 제품이 더 낮은 충실도 기대치를 가진 대규모 팬 배포로 확장되는 경우입니다 — 예를 들어, DJ 세트의 압축 버전을 수천 명의 청취자에게 동시에 스트리밍하는 경우. 그 경우에도 HLS 또는 LL-HLS가 더 간단하고 더 광범위하게 호환될 가능성이 높습니다.
결정 프레임워크
MoQ에 대해 광범위하게 조사한 결과 — IETF 초안, Broadpeak, Red5, BlogGeek.me, webrtcHacks, Meetecho, Nanocosmos의 업계 논평 — 제가 제시할 수 있는 가장 간단한 결정 규칙은 다음과 같습니다:
현재 스택을 유지해야 하는 경우
- 제품이 현재 출시되어 있고 현재 프로토콜이 잘 작동하는 경우
- 현재 Safari/iOS 브라우저 지원이 필요한 경우(WebTransport가 Safari 베타에 있지만 아직 안정 버전이 아님)
- 수 초의 지연 시간이 허용 가능한 경우(-> HLS/LL-HLS)
- 보장된 무손실 전달이 필요한 경우(-> SRT)
- 진정한 양방향 실시간 통신이 필요한 경우(-> WebRTC)
MoQ 평가를 시작해야 하는 경우
- 대규모 시청자에 대한 초저지연이 제품 가치의 핵심인 경우(실시간 베팅, 경매, 동기화된 세컨드 스크린 경험)
- 수집부터 재생까지 전체 스택을 제어하고 새 프로토콜을 수용할 수 있는 경우
- WebRTC 확장 비용이 실질적인 비즈니스 문제가 되고 있는 경우
- 2026년 하반기 또는 2027년까지 출시되지 않을 새 제품을 개발 중인 경우
- 사양이 RFC에 도달하기 전에 여전히 변경될 수 있음을 수용할 수 있는 경우
MoQ를 주의 깊게 지켜봐야 하는 경우
- CDN 또는 릴레이 인프라를 운영하는 경우(MoQ는 HTTP/3 CDN과 함께 작동하도록 설계됨)
- 동기화 요구사항이 있는 라이브 스포츠 제품을 개발하는 경우
- 수집과 배포를 단일 프로토콜로 통합하고 싶은 경우
- RTMP/SRT 수집 -> HLS 배포의 리패키징 오버헤드에 불만이 있는 경우
결론
MoQ는 실체가 있으며, 잘 설계되었고, 오늘날 스트리밍 프로토콜 환경의 진정한 한계를 해결합니다. 그 야심 — 수집부터 배포까지, CDN 규모의 릴레이 지원과 함께, 실시간과 준실시간 모두를 위한 하나의 프로토콜 — 은 설득력이 있습니다.
그러나 야심과 준비 완료는 같지 않습니다. 사양은 아직 확정되지 않았습니다. Safari는 WebTransport가 베타에 있지만 아직 안정 릴리스에는 없습니다. 프로덕션 배포는 얼리 어답터에 한정되어 있습니다. HLS, WebRTC, SRT를 프로덕션에서 안정적으로 만드는 SDK, 도구, 운영 지식의 생태계가 MoQ에는 아직 존재하지 않습니다.
2026년에 출시하는 대부분의 스트리밍 제품에서, MoQ는 추적해야 할 대상이지 — 도입해야 할 대상이 아닙니다. 성숙해지면, 그리고 그렇게 될 것이지만, 현재 여러 프로토콜을 리패키징 레이어로 연결하는 아키텍처를 단순화할 잠재력이 있습니다.
그때까지: HLS가 전달에 잘 작동한다면, 유지하세요. WebRTC가 실시간 요구에 잘 작동한다면, 유지하세요. SRT가 포인트 투 포인트 링크에 잘 작동한다면, 유지하세요. 최고의 프로토콜은 컨퍼런스 슬라이드에서 가장 흥미진진한 프로토콜이 아니라, 현재 출시되어 작동하고 있는 프로토콜입니다.
참고 자료
- IETF MoQ Transport 초안 (v17, 2026년 3월): datatracker.ietf.org/doc/draft-ietf-moq-transport
- IETF MoQ 헌장: datatracker.ietf.org/group/moq/about
- moq-lite 초안: ietf.org/archive/id/draft-lcurley-moq-lite-02.html
- IETF 블로그 — MoQ에 대해: ietf.org/blog/moq-overview
- BlogGeek.me — MoQ: 실시간 미디어를 어떻게 재정의할 것인가: bloggeek.me/moq-redefine-realtime
- webrtcHacks — 사용 사례별 WebRTC vs. MoQ: webrtchacks.com/webrtc-vs-moq-by-use-case
- RFC 8216 (HLS): rfc-editor.org/rfc/rfc8216.html
- Apple HLS 개요: developer.apple.com/streaming
- WebKit — Interop 2026 발표 (WebTransport 약속): webkit.org/blog/17818/announcing-interop-2026
- MoQ CDN — Open-source MoQ CDN relay infrastructure: moqcdn.net
- Erik Herz on LinkedIn: linkedin.com/in/erikherz