기술을 이해하고,
정리합니다.

Mesh, SFU, MCU, Hybrid의 media path와 처리 경계를 토폴로지·시퀀스 다이어그램으로 비교합니다. Mesh의 direct path에는 TURN relay 예외가 있고, SFU는 선택 전달, MCU는 서버 합성을 담당합니다. 참가자 수만으로 결론을 내리지 않고 codec·subscription·layout·region·hardware·recording 요구를 함께 검증하는 기준을 제시합니다.

Full Mesh, 단일 SFU, 지역 간 SFU cascading, CDN 기반 방송 구조의 부하 특성을 비교합니다. SFU 용량은 참가자 수만으로 정해지지 않고 publish·subscribe 수, simulcast layer, bitrate, packet rate, 암호화, 하드웨어에 따라 달라집니다. 따라서 예시 계산은 용량 계획의 출발점으로만 사용하고 실제 트래픽 모델로 부하 시험해야 합니다.

Zoom, Discord, LiveKit, Agora, Slack, Meta가 공개한 자료를 바탕으로 표준 WebRTC, libwebrtc, 자체 미디어 계층의 경계를 비교합니다. 클라이언트 엔진과 서버 토폴로지, 전송 최적화, 운영 모델을 분리해 설명하고 공개 자료로 확인되지 않는 내부 구현은 추정하지 않습니다.

Meta가 공개한 엔지니어링 글을 기준으로 장기 유지한 libwebrtc fork를 upstream 계열로 전환한 과정을 정리합니다. 두 구현의 호출 경계를 shim으로 통제하고 use case별로 이동한 방식, fork가 보안 패치와 기능 추적에 만드는 비용, 공개된 사실과 추정을 구분하는 방법을 다룹니다.

브라우저의 WebRTC API와 코덱 협상 범위, Agora Web SDK가 제공하는 채널·미디어 API, SD-RTN으로 설명되는 서비스 네트워크의 역할을 분리합니다. 네이티브 SDK의 비공개 내부 구현은 단정하지 않고, FEC와 retransmission 같은 손실 대응 기법도 표준과 공개 문서 범위에서 설명합니다.

HLS, LL-HLS, WebRTC를 지연 구성 요소, 호환성, 상호작용, 배포 방식, 운영 비용으로 비교합니다. 고정된 지연 수치로 프로토콜을 선택하지 않고 목표 latency와 audience 규모, 양방향 media 요구, device 지원 범위를 측정해 결정하는 절차를 제시합니다.

RTC 채널의 압축 프레임이 RTP로 패킷화되는 과정과 서버 측 미디어 제품이 그 흐름에 개입하는 지점을 추적합니다. Media Gateway·Media Pull·Cloud Transcoding·Media Push·Cloud Recording을 입력, 변환, 출력 기준으로 구분하고 CDN 송출과 stream fallback까지 같은 데이터 경로 위에서 설명합니다.

WebRTC는 미디어 저장 방식을 정의하지 않으므로 녹화가 필요하면 별도 파이프라인을 설계해야 합니다. 이 글은 브라우저 `MediaRecorder`, 자체 미디어 서버, Agora Cloud Recording의 통제 범위와 운영 부담을 비교합니다. Cloud Recording의 non-streaming client 모델, `acquire → start → query → stop` 수명주기, REST 인증과 RTC token의 역할도 구분합니다.