Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

들어가며 — 내일 비엔나에서 IETF 126이 시작된다
MOQT는 무엇인가 — pub/sub를 전송 계층으로 내린 설계
스펙의 현재 — 두 달마다 와이어가 바뀐다
현실 체크 1 — 가장 큰 릴레이는 draft-07에 멈춰 있다
현실 체크 2 — 최초 제안자의 포크, moq-lite
그래서 WebRTC를 지금 버려도 되나 — 아니요
판단 — 언제 들여다보고, 언제 기다릴 것인가
마치며
참고 자료

들어가며 — 내일 비엔나에서 IETF 126이 시작된다

내일(2026년 7월 18일)부터 오스트리아 비엔나에서 IETF 126이 열립니다. 아젠다를 보면 Media over QUIC(MoQ) 워킹그룹은 7월 20일(월), 23일(목), 24일(금) — 한 주에 세 번이나 세션을 잡았습니다. 그리고 열하루 전인 7월 6일, 핵심 문서인 draft-ietf-moq-transport가 열아홉 번째 리비전(-19)으로 갱신됐습니다. 149쪽짜리 문서입니다.

한쪽에서 표준화가 이렇게 달리고 있는데, 배포된 현실은 묘한 곳에 있습니다. 지금 인터넷에서 누구나 붙어 볼 수 있는 가장 큰 MoQ 릴레이 — Cloudflare가 2025년 8월에 켠 것 — 는 여전히 draft-07 부분집합에 고정돼 있습니다. 그리고 이 프로토콜 -00 리비전의 제1저자였던 Luke Curley는 지금 moq-lite라는 포크를 따로 만들고 있습니다.

스펙이 어디까지 왔는지, 배포가 어디에 있는지, 그 간극이 무엇을 말하는지 — 세 가지를 전부 1차 소스(datatracker 메타데이터, 드래프트 원문, 벤더 문서)로 확인해 정리했습니다.

MOQT는 무엇인가 — pub/sub를 전송 계층으로 내린 설계

MOQT(Media over QUIC Transport)는 QUIC과 WebTransport 위에서 도는 publish/subscribe 프로토콜입니다. -19 초록의 문장을 그대로 옮기면, QUIC의 스트림·데이터그램·우선순위·부분 신뢰성(partial reliability)을 활용해 point-to-point로도, 중간 릴레이를 거쳐서도 동작하며, 이를 통해 확장 가능한 저지연 전달을 노립니다. 흥미로운 문장이 하나 더 있습니다 — "이름과 달리 MOQT는 미디어에 무관(media agnostic)하며 광범위한 사용 사례에 쓸 수 있다." 정작 워킹그룹 헌장(2025년 4월 개정)은 라이브 스트리밍·게임·미디어 컨퍼런싱을 위한 미디어 전달 솔루션으로 범위를 잡고 있으니, 문서 스스로가 헌장보다 야심이 커진 셈입니다.

데이터 모델은 계층형입니다. 트랙(Track) 안에 그룹(Group)이 있고, 그룹 안에 객체(Object)가 있으며, 그룹 안에서 객체를 서브그룹(Subgroup)으로 묶을 수 있습니다. 스펙이 드는 예가 설계 의도를 잘 보여 줍니다 — 시간적 확장성(temporal scalability)이 있는 코덱으로 고/저해상도 영상을 보낼 때, 해상도별로 트랙을 나누고(수신자가 대역폭에 맞게 선택), 독립 복호 가능한 픽처 시퀀스를 그룹으로(랜덤 액세스 포인트 = 조인 지점), 시간 계층을 서브그룹으로(대역폭이 모자라면 우선순위 기제가 하위 계층을 우선), 프레임 하나를 객체 하나로 보냅니다.

동작은 세 갈래입니다. SUBSCRIBE는 지금부터 도착하는 객체를 받는 것(라이브 시청), FETCH는 과거 구간을 요청하는 것(되감기·VOD성 접근), PUBLISH는 구독 요청을 기다리지 않고 퍼블리셔가 밀어 넣는 푸시 모델입니다. 릴레이는 이 구조 덕에 미디어 내용을 이해하지 않고도 — 코덱도, 컨테이너도, (설계상으로는) 종단 간 암호화 키도 몰라도 — 팬아웃과 캐싱을 할 수 있습니다. 종단 간 키 수립 메커니즘 자체는 헌장이 명시적으로 범위 밖으로 뒀습니다.

여기까지가 설계의 약속입니다. WebRTC의 저지연 상호작용과 HLS/DASH의 CDN 확장성을 한 아키텍처로 — 이 문구는 Cloudflare 발표문의 표현이기도 합니다. 문제는 지금부터입니다.

스펙의 현재 — 두 달마다 와이어가 바뀐다

datatracker 제출 기록으로 최근 리비전 케이던스를 보면 이렇습니다.

리비전	제출일
draft-16	2026-01-13
draft-17	2026-03-02
draft-18	2026-05-12
draft-19	2026-07-06

대략 두 달에 한 번, IETF 회기에 맞춰 돌고 있습니다. 중요한 건 빈도가 아니라 내용입니다. 문서에 포함된 변경 이력(Appendix A)을 읽어 보면, 이 단계에서도 와이어 포맷과 메시지 집합이 계속 움직이고 있음을 알 수 있습니다.

-18에서 -19로 오면서(2026년 5월 → 7월) 구독에 Range Filter가 추가됐고, 트랙 하나에 동시 구독 여러 개가 허용됐고, PUBLISH_BLOCKED 메시지가 PUBLISH_SKIPPED로 개명됐고, 릴레이가 객체를 재정렬·드롭할 수 있던 예외 조항이 삭제됐습니다. 한 단계 전인 -17에서 -18은 더 컸습니다 — moqt:// URI 스킴 통합, SUBSCRIBE_NAMESPACE를 SUBSCRIBE_NAMESPACE와 SUBSCRIBE_TRACKS로 분리, PUBLISH_OK 메시지 타입 삭제(REQUEST_OK의 별칭으로 흡수), FETCH 응답의 델타 인코딩 도입, 7바이트 varint 허용까지. 이름이 바뀌고, 메시지가 사라지고, 인코딩이 바뀝니다. 컨트롤 메시지는 -19 기준 SETUP부터 PUBLISH_SKIPPED까지 18종입니다.

버전 협상 정책도 알아 둘 필요가 있습니다. 최종 RFC의 ALPN은 moqt가 되지만, 드래프트 구현은 moqt-19처럼 드래프트 번호를 붙인 ALPN을 씁니다. 그리고 -15 이전 드래프트는 전부 moq-00이라는 ALPN 하나를 쓰고 SETUP 메시지에서 버전을 협상했습니다. 요컨대 드래프트 세대가 다르면 ALPN 문자열부터 갈라지므로, 서버가 일부러 여러 세대를 동시 구현하지 않는 한 드래프트 간 상호운용은 구조적으로 없습니다.

일정 목표는 명시돼 있습니다. WG 마일스톤은 전송 프로토콜(MOQT)과 Common Access Token 기반 인증의 IESG 제출을 2026년 12월 31일로, 그 위에 얹히는 WARP 스트리밍 포맷·LOC 컨테이너 포맷·Privacy Pass 인증은 2027년 3월 31일로 잡고 있습니다. 목표일은 목표일일 뿐이지만, 적어도 워킹그룹 스스로는 올해 안에 기저 프로토콜을 잠그겠다는 계획입니다.

현실 체크 1 — 가장 큰 릴레이는 draft-07에 멈춰 있다

Cloudflare는 2025년 8월 22일 MoQ 릴레이 네트워크 출시를 발표했습니다. 자체 발표에 따르면 330개 이상 도시의 모든 Cloudflare 서버가 릴레이로 동작하는 최초의 MoQ 릴레이 네트워크이고, relay.cloudflare.mediaoverquic.com 엔드포인트에 누구나 붙을 수 있는 기술 프리뷰(현재 무료)입니다. 지연에 대한 "1초 미만" 같은 수치도 발표문에 있지만 이는 벤더 자체 서술이고, 측정 조건이 명시된 벤치마크는 공개되지 않았습니다.

발표문에서 정말 중요한 문장은 따로 있습니다. Cloudflare의 릴레이 구현은 draft-ietf-moq-transport-07의 부분집합이며, 그들의 표현으로 이 버전이 "여러 오픈소스 프로젝트 사이의 사실상(de facto) 상호운용 타깃"이 됐다는 것입니다. 발표 시점의 최신 드래프트가 이미 한참 앞이었는데도 -07에 멈춘 이유를 Cloudflare는 솔직하게 적었습니다 — 움직이는 표적을 계속 쫓는 대신, 거기서 멈추고 릴레이 네트워크 배포 자체에 힘을 쓰기로 했다고.

이 상태는 지금도 그대로입니다. Cloudflare MoQ 문서(2026년 4월 21일 갱신)는 여전히 draft-07 부분집합 지원을 명시합니다. 더 흥미로운 건 같은 문서의 Known Issues 항목입니다. Cloudflare 구현의 서브그룹 헤더에는 draft-07에는 없는 Subscribe ID 필드가 하나 더 들어 있습니다.

draft-ietf-moq-transport-07의 정의:        Cloudflare 구현이 실제로 주고받는 것:

STREAM_HEADER_SUBGROUP Message {           STREAM_HEADER_SUBGROUP Message {
  Track Alias (i),                           Subscribe ID (i),      <- 여분 필드
  Group ID (i),                              Track Alias (i),
  Subgroup ID (i),                           Group ID (i),
  Publisher Priority (8),                    Subgroup ID (i),
}                                            Publisher Priority (8),
                                           }

이전 드래프트에서 잘못 남은 잔재이며 추후 릴리스에서 고치겠다고 문서에 적혀 있습니다. 즉 현재의 "사실상 표준"은 draft-07도 아니고, draft-07에 특정 구현의 편차가 얹힌 무엇입니다. 이것이 2026년 7월, 표준화 4년 차 프로토콜의 상호운용 현실입니다 — 발표문에 나열된 상호운용 테스트 상대(Luke Curley의 moq.dev, Lorenzo Miniero의 imquic, Meta의 Moxygen, moq-rs, moq-js, Norsk, Vindral)도 이 draft-07 언저리를 타깃으로 맞춘 결과입니다.

스펙 절에서 본 ALPN 정책과 붙여 보면 결론이 명확해집니다. 오늘 최신 스펙(-19)대로 클라이언트를 구현하면, 유일하게 규모 있는 퍼블릭 릴레이와는 연결 협상조차 되지 않습니다.

현실 체크 2 — 최초 제안자의 포크, moq-lite

datatracker에서 draft-ietf-moq-transport-00(2023년 7월)을 열어 보면 제1저자가 L. Curley(당시 Twitch)입니다. -19의 저자 명단은 Cisco의 Nandakumar, Google의 Vasiliev와 Swett, Meta의 Frindell — Curley의 이름은 없습니다. 그는 지금 draft-lcurley-moq-lite라는 개인 드래프트를 유지하고 있고, 가장 최근 리비전(-05)은 2026년 6월 30일 자, 40쪽짜리입니다. MOQT의 149쪽과 나란히 놓으면 그 자체가 메시지입니다.

포크의 논거는 moq-lite 드래프트의 Rationale 절에 이례적으로 직설적으로 적혀 있습니다. 요지를 옮기면 — MoQ의 동기와 잠재력은 전적으로 믿지만, 이런 실험적 프로토콜을 위원회로 설계하기는 어려웠고, MoqTransport는 너무 복잡해졌다. 메시지가 너무 많고, 선택적 모드가 너무 많고, 덜 익은(half-baked) 기능이 너무 많다. 표준화 과정이 실전 실험을 오히려 가로막고 있으며, 가설상의 애플리케이션을 두고 논쟁하는 대신 실제 애플리케이션을 만들어야 한다. 그래서 moq-lite는 "WebRTC를 대체하려는 실시간 애플리케이션에 필요한 최소한"만 남기고 전부 걷어냈다는 것입니다. 그룹 순서(group order)처럼 그가 좋은 아이디어라고 인정하는 것도 "필요해지면 그때" 추가하겠다며 뺐고, 드래프트 스스로 "이 문서는 현재 상태이지 최종 상태가 아니다"라고 못 박습니다.

실제로 구조가 얼마나 다른지 보면:

데이터 모델은 Broadcast → Track → Group → Frame으로, MOQT의 서브그룹 계층이 없고 객체(Object)는 미디어 용어에 맞춰 프레임(Frame)으로 개명됐습니다.
양방향 스트림 타입은 Announce, Subscribe, Fetch, Track, Probe, Goaway 여섯 개가 전부입니다. MOQT의 컨트롤 메시지 18종과 대비됩니다.
대신 MOQT에 없는 게 있습니다 — -05는 QUIC, WebTransport 외에 Qmux over TCP/TLS와 Qmux over WebSocket까지 네 가지 전송 바인딩을 정의합니다. QUIC이 막히는 네트워크와 WebTransport가 없는 브라우저(Safari)를 위한 TCP 폴백이 스펙 안에 있는 겁니다. 데이터그램은 QUIC/WebTransport 바인딩에서만 지원됩니다.

Cloudflare 출시 다음 날 Curley가 쓴 The First MoQ CDN은 이 관점을 더 노골적으로 보여 줍니다. 그의 집계(2025년 8월 기준)로 moq-transport 저장소에는 이슈 650개+, PR 500개+가 쌓였고, 기저 네트워킹 계층이 RFC가 되기까지 "적어도 3년은 더" 걸릴 것이라고 봅니다. 그가 드는 비교가 QUIC입니다 — Google이 2012년에 배포를 시작했고, 2015년에 표준화를 시작했고, RFC는 2021년에 나왔다. 그리고 QUIC에는 스펙을 다듬을 프로덕션 데이터가 산더미였지만 MoQ에는 아직 데모 수준의 사용 경험뿐이라는 겁니다. 참고로 Cloudflare의 릴레이 코드 자체가 Curley의 Rust 구현을 포크한 것이라고 그는 밝히고 있습니다(그의 표현이며, Cloudflare 발표문은 코드 계보를 명시하지 않습니다). 출시 시점 기준으로 인증이 없고, ANNOUNCE 미지원이라 방송 시작/종료 디스커버리가 안 되고, Safari가 안 된다는 한계도 그의 글에 정리돼 있습니다.

정리하면 지금 MoQ 생태계에는 두 갈래가 있습니다. IETF 트랙(MOQT, 2026년 말 IESG 제출 목표)과 moq-lite 트랙(개인 드래프트 + 실동 구현 + 그가 운영하는 데모들). 두 갈래는 개념과 용어를 공유하지만 와이어에서 호환되지 않습니다.

그래서 WebRTC를 지금 버려도 되나 — 아니요

MoQ 진영의 목표 자체가 WebRTC 대체인 건 맞습니다(moq-lite 드래프트가 명시적으로 그렇게 적습니다). 하지만 2026년 7월 기준으로 갈아탈 수 없는 이유가 셋 있습니다.

첫째, 브라우저 커버리지. MOQT는 브라우저에서 WebTransport를 요구하는데, Safari의 WebTransport는 아직 완전하지 않습니다. Cloudflare 문서가 정리한 바로는 Safari 18.4(2025년 3월 31일)부터 개발자 플래그 뒤에 이른(아직 완전히 동작하지 않는) 구현이 들어갔을 뿐입니다. 같은 문서의 결론이 상징적입니다 — Safari가 완전한 WebTransport를 갖추기 전까지 일부 MoQ 사용 사례는 WebRTC나 WebSocket으로 폴백해야 한다. 대체하겠다는 대상에 폴백해야 하는 동안은, 대체가 아니라 병행입니다.

둘째, 운영 성숙도. 퍼블릭 릴레이는 인증 없는 기술 프리뷰이고(추측 불가능한 경로 이름이 곧 접근 제어입니다), 표준은 위에서 본 대로 아직 메시지 이름이 바뀌는 단계입니다. 화상회의·라이브 커머스처럼 SLA가 걸린 트래픽을 올릴 단계가 아닙니다.

셋째, 조용히 따라오는 비용. QUIC으로 미디어를 받는다는 건 수신 경로의 CPU 비용 구조가 TCP+TLS와 달라진다는 뜻이기도 합니다. 이 주제는 어제 쓴 QUIC 수신자 CPU 비용과 커널 QUIC 편에서 측정 데이터와 함께 다뤘으니, MoQ를 서버 쪽에서 검토한다면 같이 읽어 보시길 권합니다.

한편 오늘의 실시간 스택이 어디에 있는지는 이미 정리한 글들이 있습니다 — WebRTC 미디어 인프라와 WHIP/WHEP 생태계는 WebRTC 미디어 인프라 2026 편에서, WebTransport를 포함한 실시간 웹 전송 선택지는 실시간 웹 2026 편에서 다뤘습니다. 음성 AI처럼 양방향 대화 지연이 생명인 스택이 오늘 WebRTC 위에 서 있는 이유도 AI 음성 스택 비교 편의 맥락과 이어집니다. MoQ가 이들을 대체하려면 표준 완성, 브라우저 커버리지, 인증·과금 같은 운영 기능이 전부 채워져야 하고, 그 어느 것도 아직 끝나지 않았습니다.

판단 — 언제 들여다보고, 언제 기다릴 것인가

지금 실험할 가치가 있는 경우:

라이브 스트리밍 파이프라인(인제스트 → 팬아웃)을 직접 소유하고 있고, WebRTC SFU의 확장 비용이나 LL-HLS의 지연 바닥에 실제로 부딪히고 있다. 무료 프리뷰 릴레이와 오픈소스 구현으로 개념 검증까지는 오늘 가능합니다.
프로토콜 자체에 이해관계가 있다 — 지금이 피드백이 스펙에 반영될 수 있는 마지막 구간입니다. WG 마일스톤대로면 올해 말 IESG로 넘어갑니다.

기다리는 게 맞는 경우:

프로덕션 SLA가 걸린 미디어 트래픽. 인증 없는 프리뷰 릴레이, 두 달마다 바뀌는 와이어, 드래프트 간 비호환 — 셋 중 하나만으로도 충분한 이유입니다.
Safari를 포함한 전체 브라우저 커버리지가 필수인 서비스. WebTransport 폴백 계획 없이는 시작할 수 없습니다.
"MoQ가 WebRTC보다 지연이 좋다/나쁘다"를 근거로 의사결정을 해야 하는 경우 — 조건이 명시된 공개 비교 측정은 아직 없습니다. 벤더 발표문의 지연 서술은 마케팅 문장으로 읽어야 합니다.

마치며

정리하면 이렇습니다. MOQT 스펙은 -19까지 왔고 워킹그룹은 올해 안에 IESG 제출을 목표로 하지만, 와이어 포맷은 여전히 리비전마다 움직입니다. 반면 배포의 중력 중심은 draft-07 언저리에 있습니다 — 가장 큰 퍼블릭 릴레이가 거기 멈춰 서서 사실상의 상호운용 타깃이 됐고, 그마저 문서화된 와이어 편차를 갖고 있습니다. 그리고 프로토콜의 첫 제안자는 "실험이 표준보다 먼저여야 한다"며 6분의 1 분량의 포크를 굴리고 있습니다.

이 그림은 실패의 징후라기보다, 프로토콜 표준화의 정상적인 진통에 가깝습니다 — QUIC도 배포와 RFC 사이에 9년이 있었습니다. 다만 엔지니어로서의 실용적 결론은 분명합니다. 지금 MoQ는 관찰하고 실험할 대상이지, 갈아탈 대상이 아닙니다. 다음 확인 시점은 두 개로 잡으면 됩니다 — 다음 주 IETF 126의 MoQ 세션 결과, 그리고 2026년 말 IESG 제출이 실제로 이뤄지는지.