일반 live streaming에는 broadcaster 한 명과 많은 viewer가 있습니다. Collaborative streaming은 host와 저지연 media를 교환하면서 합성된 channel을 계속 viewer에게 보여 줄 guest broadcaster를 추가합니다. 전환은 화면 배치만 바꾸지 않습니다. RTMP에서 RTP, AAC에서 Opus, CDN origin, congestion-control state, stream을 섞는 위치가 함께 달라질 수 있습니다.

TikTok의 1세대 DualNet은 성숙한 live path를 유지하고 별도 collaborative path를 추가했습니다[1]. 초기 rollout은 쉬웠지만 초대할 때마다 두 시스템을 전환해야 했습니다. Viewer는 사실상 다른 stream을 구독하고 host는 새 transport session을 만들며 audio encoder는 서로 다른 delay를 가졌습니다. Engagement를 높이려는 시점에 audio와 video stall이 생겼습니다.

AnchorNet은 publishing path를 불변으로 만듭니다. Host는 RTC application 및 transport session 하나를 유지하고 RTC server가 두 mode에서 같은 CDN node로 연결합니다. Guest가 참여하면 server-side mixer가 stream을 합쳐 같은 경로로 program output을 돌려 줍니다. Collaboration을 끝내도 channel의 CDN identity는 바뀌지 않습니다.

Server에 mixing을 남긴 이유

Mixing은 host device, media server, 각 viewer에서 실행할 수 있습니다. Host mixing은 server compute를 아끼고 broadcaster가 전환을 직접 제어하지만 uplink 여러 개를 요구하며 phone CPU, battery, access bandwidth를 channel capacity에 포함합니다. ByteDance prototype에서 mixing은 host CPU 약 15%를 추가로 사용했고 guest 일곱 명을 늘리면 15%가 더 들었습니다. 제한된 first mile에서 uplink 두 개가 경쟁하면 viewer bitrate가 절반 가까이 될 수도 있습니다.

Viewer-side mixing은 compute를 분산하지만 모든 viewer가 여러 stream을 받아 동기화해야 합니다. 사용자 10억 명이 넘는 service에서는 subscription fan-out과 device diversity 비용이 큽니다. Server mixing은 CDN 배포용 stream 하나를 만들어 client 성능이 최대 guest 수를 정하지 않게 합니다.

AnchorNet은 server-side mixing을 유지합니다. RTC selective forwarding unit이 broadcaster 사이 media를 교환하고 multipoint control unit이 viewer program을 mixing 및 transcoding합니다. Host는 CDN을 향해 stream 하나를 송출합니다. 비용은 SFU-to-MCU round trip과 active mixing task마다 필요한 CPU 및 memory입니다.

AnchorNet은 channel을 하나의 publishing anchor에 둡니다. Solo media는 host에서 RTC server를 거쳐 한 CDN ingest로 갑니다. Guest가 들어오면 RTP stream은 SFU 및 server-side MCU에 들어가고 mixed result가 동일한 host session과 CDN destination으로 돌아옵니다. Audio sample splicing이 codec delay를 잇는 동안 viewer subscription은 바뀌지 않습니다. 이 글을 위해 새로 만든 도판.

이 구조를 모든 환경의 최적해로 주장하지는 않습니다. 작은 conference product는 viewer SFU delivery를, 고성능 broadcaster는 local mixing을 택할 수 있습니다. AnchorNet의 선택은 device population, 기존 CDN, 매우 큰 viewer fan-out을 기준으로 합니다.

단순 전환을 들리게 만드는 codec delay

기본 live streaming은 AAC를 사용하고 broadcaster RTC는 낮은 지연과 loss resilience를 위해 Opus를 씁니다. Encoder는 유효 frame을 만들기 전에 sample을 buffer합니다. Controller가 이 buffer를 고려하지 않고 packet timestamp에서 경로를 바꾸면 silence, duplicate sample, speech loss가 생길 수 있습니다.

AnchorNet은 broadcaster와 RTC server를 audio-sample 단위로 조정합니다. 이전 및 새 경로의 encoder delay를 추적하고 splice point를 고르며, 전환 뒤 첫 sample이 마지막 delivered sample 다음에 오도록 timestamp를 맞춥니다. 목표는 화면 배치가 바뀌며 video가 잠깐 반복돼도 audio는 이어지는 것입니다.

이 비대칭은 의도한 설계입니다. Viewer는 click이나 음절 손실을 바로 느끼지만 host 큰 화면이 guest grid로 바뀌는 동안 momentary repeated video frame은 가릴 수 있습니다. AnchorNet은 audio-video synchronization을 위해 몇 video frame을 replay 또는 re-encode하고 전환 뒤 playback speed도 조절할 수 있습니다. 두 media timeline을 수학적으로 동일하게 움직이기보다 지각되는 연속성을 최적화합니다.

소규모 시험에서 AnchorNet switch에는 audio rebuffering이 없었습니다. DualNet은 초 단위 audio·video stall을 보였고 다른 비교 제품은 전환마다 약 100ms audio pause가 있었습니다. 통제 환경은 splice mechanism을 분리하지만 약한 mobile access link를 대표하지 않으므로 운영 A/B 시험이 더 강한 근거입니다.

4주 운영 전환 결과

2024년 4분기 A/B 시험은 4주 동안 거의 같은 수의 사용자를 AnchorNet과 DualNet에 배정했습니다. 보고한 차이는 적어도 95% confidence level을 만족했습니다. Live에서 collaborative mode로 갈 때 viewer session당 video stall duration은 60.3%, stall count는 60.1% 줄었고 audio duration과 count는 각각 67.4%와 64.5% 감소했습니다.

반대 전환의 개선 폭은 더 컸습니다. Collaborative-to-live video stall duration은 78.9%, count는 78.5% 줄었고 audio duration과 count는 77.1%, 76.3% 감소했습니다. 두 architecture에서 startup과 teardown work가 다르기 때문에 비대칭이 생깁니다. 60% 이상이라는 요약은 안전하지만 switch direction도 결과의 일부입니다.

Daily active time은 host broadcaster 0.53%, guest co-broadcaster 2.15%, viewer 3.83% 늘었습니다. 원문은 viewer session이 이미 모든 mode switch를 포함하므로 stall 자체가 줄어든 시간만큼 watching time이 기계적으로 늘어난 것이 아니라고 설명합니다. 그래도 하나의 product에서 얻은 online correlation이며 모든 streaming service가 3.83%를 얻는다는 증명은 아닙니다.

이 실험은 전환 시스템에 mode별 계측이 필요한 이유도 보여 줍니다. 전체 stall rate 하나로는 일반 재생과 publishing graph가 바뀌는 짧은 구간이 섞이므로, 수치가 좋아진 원인이 transport 개선인지 collaborative session 감소인지 구분할 수 없습니다. AnchorNet은 전환 방향, media 종류, 지속 시간, 횟수를 나누어 기록합니다. 실제 배포에서는 access network, device codec capability, guest 수, 선택한 mixer까지의 거리도 함께 나눠 봐야 합니다. 그래야 하나의 global average가 전체 이용자를 대표하는지, 느린 지역 꼬리를 가리는지 판단할 수 있습니다.

AnchorNet은 user-space congestion control로 uplink fluctuation을 더 잘 처리해 일반 live mode도 개선했습니다. Video와 audio rebuffering은 최대 13.47%, 11.02% 줄고 host push frame rate는 3.11% 증가했습니다. Hardware codec acceleration을 우선해 host CPU는 1.33% 줄었지만 GPU는 0.8%, memory는 0.31% 늘었습니다. Unified-path mechanism과 분리해서 볼 implementation effect입니다.

Mixing cost와 geography의 경계

Median server-side mixing task는 logical CPU core 0.4개 미만과 memory 220MB를 사용했습니다. ByteDance는 thread 128개와 500GB 넘는 memory를 가진 server에서 mixer instance 100개로 concurrent collaborative channel 약 1만5천~3만 개를 지원할 수 있다고 추정합니다. Guest count, codec, resolution, percentile에 따라 달라지는 deployment estimate이며 고정 server specification이 아닙니다.

Mixer가 멀면 SFU-MCU 추가 path가 보입니다. Global average end-to-end delay는 AnchorNet과 DualNet이 비슷했는데, DualNet이 collaboration에서 큰 CDN jitter buffer를 예약했기 때문입니다. 가장 가까운 MCU cluster에서 먼 한 국가에서는 AnchorNet collaborative mode가 평균 170ms를 추가했습니다. Edge MCU를 넓히면 지연은 줄지만 배포 비용과 운영 surface가 늘어납니다.

Mixing과 transcoding 때문에 solo와 collaborative mode 사이에는 수백 ms 차이가 남습니다. CDN 및 viewer jitter buffer는 variation을 가릴 뿐 propagation과 compute time을 제거하지 않습니다. Interactive commerce처럼 더 짧은 end-to-end 지연이 필요하면 edge mixer를 더 두거나 viewer path를 바꿔야 합니다.

Unified session은 RTC server dependency도 집중합니다. Bridge 장애가 collaboration뿐 아니라 두 mode에 영향을 줄 수 있습니다. Migration은 sequence number, timestamp, congestion state, CDN ingest continuity를 유지해야 합니다. Planned mode change 때 조정할 component 수는 줄지만 failover는 별도 설계 과제입니다.

Channel identity를 유지하는 구조

AnchorNet은 media composition이 바뀌는 동안 channel, transport session, CDN ingest를 안정된 identity로 취급합니다. Feature transition이 origin migration이 되는 것을 막습니다. User session 중 codec, presenter, compute backend를 바꾸는 서비스도 external subscription을 보존하고 variability를 anchor 뒤로 옮기는 같은 원칙을 사용할 수 있습니다.

Continuity에는 media-aware handling이 필요합니다. Packet sequence만으로 codec lookahead를 이을 수 없고 수학적으로 동기화한 timeline이 layout change 아래 video 반복을 숨기는 방식보다 지각상 나쁠 수 있습니다. Audio·video stall count와 duration, end-to-end delay, device pressure, server mixing cost, engagement를 함께 측정해야 합니다.

배포 순서는 정상 상태의 수용량만큼 중요합니다. 먼저 기존 viewer path를 fallback으로 남긴 채 publishing session을 anchor에 고정하고, 다음 단계에서 제한된 cohort에 server mixing을 켠 뒤, 마지막으로 병렬 RTC path를 제거할 수 있습니다. 이렇게 하면 session 또는 region 단위 rollback이 가능합니다. 중간 상태마다 기존 CDN ingest와 새 mixer가 모두 이해하는 timestamp와 codec parameter를 보존해야 한다는 호환 조건도 명확해집니다. Architecture simplification의 이익은 첫 성공적인 switch가 아니라 이 coexistence period를 끝낸 뒤에 실현됩니다.

ByteDance 운영 결과는 architecture consolidation이 migration complexity를 상환할 수 있음을 보여 줍니다. 동시에 smoother mode switching을 server mixing 및 추가 path length와 교환한다는 비용도 드러냅니다. 올바른 배치 지점은 viewer fan-out, phone capability, edge-MCU coverage, application이 하나의 stable publishing path를 위해 허용할 latency에 달려 있습니다.

출처와 저작권 안내

이 글은 Silicon & Systems가 작성한 편집 분석으로, 배치 구조와 측정, 한계를 우리 표현으로 다시 썼습니다. 원문의 문장, 표, 도판은 재수록하지 않았고 도판은 이 글을 위해 새로 만들었습니다. 전체 논문은 USENIX ATC 2025 발표 페이지에서 확인할 수 있으며, 저작권은 저자에게 있습니다. 2025.