Booil Jung

WebRTC에 대한 심층 고찰

WebRTC(Web Real-Time Communications)는 구글이 주도하여 시작한 오픈 소스 프로젝트로, 웹 브라우저 간에 별도의 플러그인이나 소프트웨어 설치 없이 오디오, 비디오, 그리고 임의의 데이터를 실시간으로 통신할 수 있도록 설계된 자바스크립트 API의 집합이다.1 이 기술이 등장하기 이전, 웹에서의 실시간 통신은 Adobe Flash, Microsoft ActiveX 또는 별도의 네이티브 애플리케이션 설치와 같은 독점적이고 파편화된 기술에 의존해야만 했다.3 이러한 방식은 사용자에게 불편한 설치 과정을 강요하고, 보안 취약점을 노출하며, 개발자에게는 비싼 라이선스 비용과 플랫폼 종속성 문제를 안겨주었다.4

WebRTC의 탄생은 이러한 문제를 근본적으로 해결하려는 시도에서 비롯되었다. 프로젝트의 핵심 목표는 브라우저, 모바일 플랫폼, 그리고 사물 인터넷(IoT) 장치에 이르기까지 모든 플랫폼에서 풍부하고 고품질의 실시간 통신(RTC) 애플리케이션을 개발하고, 공통된 프로토콜 세트를 통해 이들 모두가 원활하게 통신할 수 있는 환경을 구축하는 것이다.1 즉, 특정 기업의 기술에 종속되지 않는 개방형 표준을 통해 실시간 통신 기술의 장벽을 허무는 것이 WebRTC의 궁극적인 비전이다.

이러한 비전의 이면에는 기술 자체의 혁신을 넘어선 ‘접근성의 혁명’이라는 더 큰 의미가 내포되어 있다. 과거 RTC 기술은 통신사나 소수의 전문 벤더가 독점하던 고도의 전문 분야였다. 그러나 WebRTC는 getUserMedia, RTCPeerConnection, RTCDataChannel과 같은 표준 자바스크립트 API를 통해 이 복잡한 기술을 모든 웹 개발자에게 개방했다.2 이는 실시간 통신 기술을 ‘민주화’한 사건으로 평가할 수 있으며, 이로 인해 화상 회의나 P2P 데이터 공유 기능이 더 이상 특별한 서비스가 아닌, 일반적인 웹 애플리케이션의 기본 기능(feature)으로 자리 잡게 되는 패러다임의 전환을 이끌었다.7 결과적으로 WebRTC는 실시간 통신을 소수의 전문 산업에서 웹의 근간을 이루는 핵심 빌딩 블록으로 변모시켰고, 오늘날 우리가 경험하는 수많은 협업 및 인터랙티브 애플리케이션의 폭발적인 성장을 견인하는 기술적 토대가 되었다.9

WebRTC는 여러 강력한 장점을 기반으로 빠르게 웹 표준으로 자리 잡았으나, 동시에 명확한 기술적 한계 또한 가지고 있다.

핵심 장점:

명백한 한계:

WebRTC의 강력한 기능은 크게 세 가지 핵심 자바스크립트 API를 통해 개발자에게 제공된다. 이들은 각각 미디어 획득, 피어 간 연결, 데이터 전송이라는 명확한 역할을 수행한다.

이 세 가지 API는 유기적으로 연동하여 플러그인 없는 실시간 통신을 완성한다. getUserMedia로 미디어를 얻고, RTCPeerConnection으로 피어와 연결한 뒤, 미디어 스트림과 RTCDataChannel을 통해 데이터를 교환하는 것이 WebRTC 애플리케이션의 기본적인 흐름이다.

graph TD
    A[Browser]

    subgraph "WebRTC Core APIs"
        B(MediaStream API<br>getUserMedia)
        C(RTCPeerConnection API)
        D(RTCDataChannel API)
    end

    subgraph "User's Device"
        E[Camera/Microphone]
    end

    F[Network]

    A --> B
    B --> E
    E --> B
    B --> C
    A --> C
    A --> D
    C -- Audio/Video Stream --> F
    F -- Audio/Video Stream --> C
    D -- Arbitrary Data --> F
    F -- Arbitrary Data --> D

WebRTC는 두 브라우저 간에 미디어를 직접 주고받는 P2P 프로토콜을 정의하지만, 정작 두 브라우저가 서로의 존재를 인지하고 통신을 시작하기 위해 필요한 초기 메타데이터 교환 과정, 즉 ‘시그널링(Signaling)’에 대해서는 아무것도 규정하지 않는다.11 이는 WebRTC의 가장 중요한 특징 중 하나이자, 개발자들이 처음 마주하는 가장 큰 허들이다.

시그널링은 P2P 연결이 수립되기 전에 다음과 같은 핵심 정보를 교환하는 과정이다 8:

  1. 세션 제어 메시지: 통신을 시작하고, 종료하며, 오류를 보고하는 등의 제어 신호.
  2. 네트워크 구성 정보: 각 피어가 인터넷에서 서로를 찾을 수 있는 주소 정보. 여기에는 로컬 IP 주소뿐만 아니라 방화벽이나 NAT 뒤에 있는 피어의 공인 IP 주소와 포트 정보(ICE Candidates)가 포함된다.
  3. 미디어 기능 정보: 각 피어가 지원하는 코덱, 해상도, 비트레이트 등 미디어 관련 역량 정보(SDP).

WebRTC가 시그널링을 표준화하지 않은 것은 의도적인 설계 결정이다. 만약 특정 시그널링 프로토콜(예: SIP over WebSocket)을 강제했다면, 모든 WebRTC 애플리케이션은 해당 프로토콜에 종속되었을 것이다. 이는 기존 시스템과의 통합을 어렵게 하고 기술적 혁신을 저해할 수 있다. 대신 WebRTC는 시그널링을 ‘대역 외(out-of-band)’ 프로세스로 남겨둠으로써, 개발자가 자신의 애플리케이션 요구사항에 가장 적합한 기술을 자유롭게 선택할 수 있는 ‘유연성’을 부여했다.26 예를 들어, 간단한 채팅 앱은 HTTP 롱폴링으로 시그널링을 구현할 수 있고, 복잡한 인터넷 전화 시스템은 기존 SIP 인프라를 활용할 수 있다.11

하지만 이 유연성은 개발자에게 시그널링 서버를 직접 설계, 구현하고 확장해야 하는 ‘복잡성’이라는 비용을 전가한다. 개발자는 WebSocket, 서버 전송 이벤트(SSE), 또는 다른 양방향 통신 채널을 이용해 안정적이고 확장 가능한 시그널링 서버를 구축해야 한다.11 많은 개발자들이 WebRTC의 P2P 기능에만 집중하다가 이 시그널링 서버 구축의 복잡성을 과소평가하여 실제 서비스 개발에 어려움을 겪는 경우가 많다.20 결국 ‘시그널링에 구애받지 않는(signaling agnostic)’ 특성은 WebRTC를 매우 다재다능하게 만들지만, 동시에 견고한 시그널링 계층을 구축하는 것이 성공적인 WebRTC 서비스의 선결 과제임을 명확히 보여준다.

WebRTC의 연결 협상 과정은 IETF RFC 8866에 표준으로 정의된 SDP(Session Description Protocol)를 사용하는 ‘Offer/Answer’ 모델을 기반으로 한다.3 이 모델은 두 피어가 서로의 미디어 및 네트워크 사양을 교환하고 합의에 이르는 체계적인 절차를 제공한다.

전체 과정은 통화를 시작하는 ‘Caller’와 전화를 받는 ‘Callee’ 사이에서 다음과 같이 진행된다 27:

  1. Caller의 Offer 생성: 통화를 시작하려는 피어 A(Caller)는 RTCPeerConnection.createOffer() 메서드를 호출한다. 이를 통해 자신의 미디어 스트림 정보, 지원하는 코덱 목록, 해상도, 암호화 방식 등이 기술된 SDP 형식의 ‘Offer’ 문자열을 생성한다.
  2. Caller의 로컬 설명 설정: 생성된 Offer를 setLocalDescription() 메서드를 통해 자신의 ‘로컬 설명(local description)’으로 설정한다. 이로써 피어 A의 RTCPeerConnection 인스턴스는 자신의 상태를 인지하게 된다.
  3. Offer 전송: 피어 A는 구축된 시그널링 채널(예: WebSocket)을 통해 이 SDP Offer를 피어 B(Callee)에게 전송한다.
  4. Callee의 원격 설명 설정: Offer를 수신한 피어 B는 setRemoteDescription() 메서드를 사용해 수신된 Offer를 자신의 ‘원격 설명(remote description)’으로 설정한다. 이제 피어 B는 피어 A의 미디어 사양을 알게 된다.
  5. Callee의 Answer 생성: 피어 B는 수신한 Offer를 바탕으로, 자신이 수용할 수 있는 미디어 사양을 담은 ‘Answer’를 createAnswer() 메서드를 통해 생성한다. 예를 들어, 피어 A가 VP8과 H.264 코덱을 모두 제안했다면, 피어 B는 자신이 선호하거나 지원하는 H.264만 사용하겠다는 내용의 Answer를 만들 수 있다.
  6. Callee의 로컬 설명 설정: 생성된 Answer를 setLocalDescription()을 통해 자신의 로컬 설명으로 설정한다.
  7. Answer 전송: 피어 B는 시그널링 채널을 통해 이 SDP Answer를 다시 피어 A에게 전송한다.
  8. Caller의 원격 설명 설정: Answer를 수신한 피어 A는 setRemoteDescription()으로 이를 자신의 원격 설명으로 설정한다.

이 과정이 완료되면 양측 피어는 상호 호환되는 미디어 세션에 대한 완전한 합의에 도달하게 되며, 이후 ICE 프로세스를 통해 실제 미디어 스트림을 교환할 경로를 찾기 시작한다. 이 Offer/Answer 모델은 최초 연결 설정뿐만 아니라, 통화 중에 해상도를 변경하거나 화면 공유를 추가하는 등 세션의 구성을 변경해야 할 때마다 반복적으로 사용된다.

sequenceDiagram
    participant Alice
    participant Signaling Server
    participant Bob

    Alice->>Alice: createOffer()
    Alice->>Alice: setLocalDescription(offer)
    Alice->>Signaling Server: sendOffer(offer)
    Signaling Server->>Bob: receiveOffer(offer)
    Bob->>Bob: setRemoteDescription(offer)
    Bob->>Bob: createAnswer()
    Bob->>Bob: setLocalDescription(answer)
    Bob->>Signaling Server: sendAnswer(answer)
    Signaling Server->>Alice: receiveAnswer(answer)
    Alice->>Alice: setRemoteDescription(answer)
    Note over Alice, Bob: SDP Negotiation Complete

현대의 인터넷 환경에서 대부분의 개인용 컴퓨터나 모바일 장치는 공유기나 통신사 장비 뒤에 위치하며, 사설 IP 주소를 할당받는다. 이러한 네트워크 주소 변환(NAT, Network Address Translation) 환경은 외부에서 내부 장치로 직접 접근하는 것을 차단하기 때문에, P2P 연결을 구축하는 데 있어 가장 큰 기술적 장애물이다.1 WebRTC는 이 문제를 해결하기 위해 STUN, TURN, ICE라는 세 가지 핵심 기술을 유기적으로 활용한다.

이러한 ICE 프로세스를 통해 WebRTC는 거의 모든 네트워크 환경에서 안정적으로 P2P 연결을 수립할 수 있다.

graph LR
    subgraph "Peer A (Private Network)"
        A[Client A]
    end
    subgraph "Peer B (Private Network)"
        B
    end
    subgraph Internet
        STUN(STUN Server)
        TURN(TURN Server)
        SS(Signaling Server)
    end

    A -- 1. SDP/ICE Candidates --> SS
    SS -- 2. SDP/ICE Candidates --> B
    B -- 3. SDP/ICE Candidates --> SS
    SS -- 4. SDP/ICE Candidates --> A

    A -- "What's my public IP?" --> STUN
    STUN -- "It's X.X.X.X:P" --> A
    B -- "What's my public IP?" --> STUN
    STUN -- "It's Y.Y.Y.Y:Q" --> B

    A <-.-> B;
    A <-.-> TURN;
    B <-.-> TURN;

    subgraph "ICE Process"
      direction LR
      Start((Start)) --> C1{"Collect Candidates<br>- Host<br>- Server Reflexive (STUN)<br>- Relayed (TURN)"}
      C1 --> C2{Exchange via Signaling}
      C2 --> C3{Pair Candidates &<br>Run Connectivity Checks}
      C3 --> C4{Select Best Path}
      C4 --> Stop((Connected))
    end

WebRTC 연결 성공률의 이면을 들여다보면 흥미로운 패턴이 발견된다. STUN을 이용한 직접 P2P 연결, 즉 UDP 홀 펀칭(UDP hole punching)은 약 75-80%의 경우에 성공적으로 이루어진다.31 이는 대부분의 일반적인 네트워크 환경에서는 추가 비용 없이 효율적인 통신이 가능하다는 것을 의미한다. 문제는 나머지 20-25%의 ‘까다로운’ 연결이다. 주로 대기업의 엄격한 방화벽이나 일부 통신사의 대칭형 NAT 환경에서 발생하는 이 연결 실패를 구제하기 위해 TURN 서버가 동원된다. 결국, 전체 사용자 중 소수에 불과한 이들을 위해 막대한 대역폭 비용을 유발하는 TURN 서버 인프라를 유지해야 하는 상황이 발생한다. 이는 WebRTC 서비스의 가용성을 99% 이상으로 끌어올리기 위해서는 소수의 사용자를 위해 전체 인프라 비용의 상당 부분을 투자해야 함을 시사한다. 따라서 대규모 서비스의 비용 최적화 전략은 필연적으로 TURN 서버의 사용을 최소화하는 방향으로 집중될 수밖에 없다.32

WebRTC의 순수한 P2P 모델은 1:1 통신에는 이상적이지만, 참여자가 늘어나는 순간 한계에 부딪힌다. 대규모 다자간 통신 서비스를 구축하기 위해서는 중앙 미디어 서버를 도입한 아키텍처를 선택해야 한다. 대표적인 모델로는 Mesh, SFU, MCU가 있으며, 각각의 장단점과 기술적 트레이드오프가 뚜렷하다.

Mesh는 WebRTC의 가장 기본적인 형태로, 별도의 미디어 서버 없이 모든 참여자가 다른 모든 참여자와 직접 P2P 연결을 맺는 ‘완전 연결(Full-mesh)’ 구조다.7 N명의 참여자가 있다면, 각 참여자는 N-1개의 업스트림(송신)과 N-1개의 다운스트림(수신)을 동시에 관리해야 한다.

이 방식의 가장 큰 장점은 단순함과 비용이다. 초기 연결을 위한 시그널링 서버 외에는 미디어 트래픽을 중계하는 서버가 필요 없으므로 서버 운영 비용이 매우 낮다.7 또한 모든 미디어가 참여자 간에 직접 전송되므로 지연 시간이 가장 짧고,天然적으로 종단간 암호화(End-to-End Encryption)가 보장된다.

하지만 이 단순함은 치명적인 확장성 문제를 대가로 치른다. 참여자 수가 증가함에 따라 각 클라이언트가 처리해야 할 스트림의 수가 선형적으로 증가(N−1)하고, 전체 네트워크의 연결 수는 기하급수적으로 증가(N×(N−1)/2)한다. 이는 각 클라이언트의 CPU와 업로드 대역폭에 엄청난 부담을 주며, 보통 4-5명을 넘어서는 순간부터 급격한 성능 저하를 유발한다.16 이른바 ‘N 제곱 문제(N-squared problem)’로 알려진 이 한계 때문에, Mesh 아키텍처는 1:1 통화나 3-4명 이내의 소규모 그룹 채팅에만 제한적으로 사용된다.

Mesh 아키텍처의 확장성 한계를 극복하기 위해 등장한 것이 중앙 미디어 서버를 활용하는 모델이다. 이 모델은 크게 SFU와 MCU 방식으로 나뉜다.

SFU (Selective Forwarding Unit):

SFU는 ‘선택적 전달 장치’라는 이름처럼, 각 참여자로부터 수신한 미디어 스트림을 다른 참여자들에게 그대로 ‘전달’해주는 역할을 한다.7 SFU 아키텍처에서 각 참여자는 자신의 오디오/비디오 스트림을 SFU 서버로 단 한 번만 업로드한다. 그러면 SFU 서버가 이 스트림을 복제하여 다른 모든 참여자에게 전송해준다.37

MCU (Multi-point Control Unit):

MCU는 ‘다지점 제어 장치’로, SFU보다 훨씬 더 중앙 집중적인 방식으로 미디어를 처리한다.7 각 참여자가 자신의 스트림을 MCU 서버로 보내면, MCU는 수신된 모든 스트림을 디코딩하여 하나의 비디오 레이아웃으로 합성(mixing/composing)하고, 오디오를 믹싱한다. 그 후, 이 단일화된 스트림을 다시 인코딩하여 모든 참여자에게 전송한다.39

MCU는 과거 하드웨어 기반 화상회의 시스템에서 주로 사용되던 방식이며, 레거시 시스템과의 호환성이나 극도로 제한된 클라이언트 환경 지원과 같은 특수한 요구사항이 있을 때 여전히 유효한 선택지다. 하지만 현대적인 대규모 실시간 통신 서비스의 아키텍처는 대부분 SFU를 채택하고 있다. 이는 SFU가 확장성(scalability), 유연성(flexibility), 비용 효율성(cost-effectiveness) 사이에서 가장 합리적인 균형점을 제공하기 때문이다. 최신 클라이언트 장치들은 여러 개의 비디오 스트림을 동시에 디코딩할 수 있을 만큼 충분히 강력해졌고(일반적으로 4-9개 스트림 처리 가능) 36, MCU의 막대한 트랜스코딩 비용보다는 SFU의 네트워크 대역폭 비용이 상대적으로 저렴하기 때문이다. Discord, Google Meet과 같은 대부분의 현대적인 서비스들이 SFU 아키텍처를 기반으로 구축된 것은 이러한 기술적, 경제적 트레이드오프를 반영한 결과다.42

기능 Mesh (P2P) SFU (Selective Forwarding Unit) MCU (Multipoint Control Unit)
확장성 낮음 (2-4명) 좋음 (수백 명) 좋음 (수백 명)
지연 시간 가장 낮음 낮음 중간 (트랜스코딩 지연)
서버 CPU 부하 없음 (시그널링 전용) 낮음 (라우팅 전용) 매우 높음 (트랜스코딩)
서버 대역폭 없음 (시그널링 전용) 높음 (N×(N−1) 스트림) 중간 (N 스트림 입력, N 스트림 출력)
클라이언트 CPU 부하 높음 (N-1개 스트림 인코딩/디코딩) 중간 (1개 인코딩, N-1개 디코딩) 낮음 (1개 인코딩, 1개 디코딩)
클라이언트 업링크 높음 (N-1개 스트림) 낮음 (1개 스트림) 낮음 (1개 스트림)
클라이언트 다운링크 높음 (N-1개 스트림) 높음 (N-1개 스트림) 낮음 (1개 스트림)
종단간 암호화(E2EE) 기본 지원 가능 (Insertable Streams/SFrame 사용) 불가능
주요 사용 사례 1:1 통화, 소규모 그룹 그룹 화상 회의, 웨비나 레거시 시스템 연동, 저사양 클라이언트

단일 지역에 위치한 SFU 서버는 전 세계 사용자를 대상으로 서비스를 제공할 때 물리적 거리로 인한 지연 시간(latency) 문제에 직면한다.44 예를 들어, 미국에 있는 서버에 호주 사용자가 접속하면 왕복 시간(RTT)만으로도 200ms 이상이 소요되어 원활한 실시간 통신이 어렵다.

이 문제를 해결하기 위한 아키텍처가 ‘Cascading SFUs’ 또는 ‘Geo-distributed SFUs’다.36 이 구조는 전 세계 여러 주요 거점(region)에 SFU 서버를 분산 배치하고, 이 서버들을 서로 계층적으로 연결하는 방식이다.

Cascading SFU는 단순히 서버를 여러 곳에 복제하는 것을 넘어, 사용자를 최적의 엣지 서버로 지능적으로 라우팅하고(‘geo-sticky’ 세션 관리) 44, 서버 간의 효율적인 스트림 교환을 관리하는 정교한 시스템이다. 이는 현대적인 글로벌 실시간 통신 서비스를 구축하기 위한 필수적인 아키텍처 패턴으로 자리 잡았다.

WebRTC의 핵심 기능은 미디어와 데이터를 실시간으로 처리하고 전송하는 파이프라인에 있다. 이 파이프라인은 MediaStream, RTCPeerConnection, RTCDataChannel이라는 세 가지 API를 중심으로 구성되며, 코덱과 대역폭 적응 기술이 그 효율성을 결정한다.

MediaStream API는 WebRTC 미디어 파이프라인의 출발점이다. 이 API의 핵심은 navigator.mediaDevices.getUserMedia() 메서드로, 웹 애플리케이션이 사용자의 카메라와 마이크에 접근할 수 있도록 해준다.19

MediaStream은 하나 이상의 MediaStreamTrack을 담는 컨테이너 역할을 한다.21 각 트랙은 독립적인 미디어 소스를 나타내며, 개발자는 이 트랙 단위로 음소거(mute), 활성화(enable) 등의 제어를 할 수 있다. 이처럼 MediaStream API는 WebRTC 통신의 원재료인 미디어 데이터를 안전하고 유연하게 획득하는 관문 역할을 수행한다.

RTCPeerConnection은 WebRTC 연결의 생성부터 협상, 유지, 종료에 이르는 전체 생명주기를 관리하는 핵심 인터페이스다.5 이는 ICE, DTLS, SRTP와 같은 복잡한 하위 프로토콜들을 추상화하여 개발자가 상대적으로 간단하게 P2P 연결을 제어할 수 있도록 돕는다.

이러한 메서드와 이벤트의 조합을 통해 개발자는 복잡한 P2P 연결 과정을 체계적으로 관리할 수 있다. 특히 연결 과정의 모든 단계가 비동기 Promise 기반으로 작동하므로, async/await 구문을 활용하면 코드를 더 명확하고 간결하게 작성할 수 있다.50

RTCDataChannel은 WebRTC의 또 다른 강력한 기능으로, 오디오/비디오 스트림과 독립적으로 임의의 데이터를 P2P로 직접 전송할 수 있는 채널을 제공한다.3

RTCDataChannel은 단순한 채팅 기능 구현을 넘어, 웹 개발자에게 강력하고 유연한 P2P 전송 계층을 제공한다는 점에서 그 진정한 가치가 있다. 이 API는 전통적인 웹 통신에서 개발자가 TCP(신뢰성, 순서 보장)와 UDP(비신뢰성, 순서 무관) 중 하나를 선택해야 했던 제약에서 벗어나게 해준다. RTCDataChannel은 내부적으로 SCTP(Stream Control Transmission Protocol)를 기반으로 동작하는데, SCTP는 TCP와 UDP의 특징을 모두 아우르는 전송 프로토콜이다.24

개발자는 createDataChannel() 메서드를 호출할 때 간단한 옵션을 통해 채널의 동작 방식을 세밀하게 제어할 수 있다 25:

이러한 유연성은 하나의 RTCPeerConnection 내에서 다양한 목적의 데이터 채널을 동시에 운영할 수 있게 한다. 예를 들어, 파일 전송을 위해서는 신뢰성과 순서가 보장되는 채널(ordered: true)을 생성하고, 동시에 실시간 멀티플레이어 게임의 플레이어 위치 데이터를 전송하기 위해서는 지연 시간을 최소화한 비신뢰성, 비순차 채널(ordered: false, maxRetransmits: 0)을 생성하여 사용할 수 있다.53 이는 별도의 WebSocket 연결과 UDP 소켓을 함께 사용해야 했던 기존의 복잡한 구조를 단일 P2P 연결로 통합할 수 있음을 의미한다. 모든

RTCDataChannel 통신은 RTCPeerConnection의 DTLS 세션을 통해 의무적으로 암호화되므로, 별도의 보안 계층을 구현할 필요 없이 안전한 데이터 전송이 보장된다.55

코덱(Codec)은 아날로그 미디어 신호를 디지털 데이터로 압축(인코딩)하고, 다시 원래 신호로 복원(디코딩)하는 알고리즘이다. WebRTC의 통신 품질과 효율성은 어떤 코덱을 사용하느냐에 따라 크게 좌우된다.

WebRTC 표준은 모든 브라우저가 의무적으로 지원해야 하는 코덱을 명시하고 있다. 비디오의 경우 구글이 개발한 로열티 없는 코덱인 VP8이, 오디오의 경우 뛰어난 음질과 낮은 지연 시간을 자랑하는 Opus가 기본 코덱으로 지정되었다.1 이와 더불어, 하드웨어 가속 지원이 폭넓게 이루어져 모바일 기기에서 효율적으로 동작하는 H.264 역시 사실상의 표준으로 널리 사용된다.56

최근 WebRTC 생태계의 가장 큰 변화는 차세대 비디오 코덱인 AV1의 부상이다.56 AV1은 구글, 아마존, 넷플릭스, 메타 등이 참여한 AOMedia(Alliance for Open Media)에서 개발한 로열티 없는 오픈 코덱으로, 기존의 VP9이나 H.264에 비해 약 30% 이상 뛰어난 압축 효율을 자랑한다.57 이는 동일한 화질의 비디오를 훨씬 낮은 비트레이트로 전송할 수 있음을 의미하며, 특히 네트워크 대역폭이 제한적인 모바일 환경에서 사용자 경험을 획기적으로 개선할 수 있다.58

하지만 AV1으로의 전환은 단순한 코덱 업그레이드 이상의 복잡한 트레이드오프를 수반한다. 높은 압축 효율은 그만큼 복잡한 연산을 필요로 하므로, 인코딩 및 디코딩 과정에서 상당한 CPU 자원을 소모한다.58 이는 구형 기기나 저사양 모바일 장치에서 오히려 성능 저하와 배터리 소모 증가를 유발할 수 있다.

이러한 문제를 해결하기 위해 메타(구 페이스북)와 같은 선도 기업들은 정교한 적응형 전략을 사용한다. 이들은 단순히 AV1을 기본 코덱으로 설정하는 대신, 통화 시작 시 H.264와 AV1을 모두 협상하는 ‘하이브리드 인코더’ 방식을 도입했다.58 통화 중에 클라이언트의 장치 성능과 실시간 네트워크 상태를 지속적으로 모니터링하여, 장치 성능이 충분하고 네트워크 상태가 좋지 않을 때는 AV1으로 전환하여 대역폭을 절약하고, 장치 성능이 부족할 때는 하드웨어 가속이 가능한 H.264를 사용하여 CPU 부담을 줄이는 동적 최적화를 수행한다.

결론적으로 AV1으로의 전환은 WebRTC 애플리케이션이 더욱 지능적이고 상황 인지적인 미디어 파이프라인 관리 능력을 갖추어야 함을 의미한다. 이는 더 이상 ‘하나의 코덱으로 모든 상황에 대응’하는 방식이 아니라, 실시간으로 변화하는 환경에 맞춰 최적의 균형점을 찾아가는 동적 최적화 문제로 진화하고 있음을 보여준다.

기능 VP8 H.264 VP9 AV1
라이선스 로열티 없음 로열티 있음 (MPEG LA) 로열티 없음 로열티 없음 (AOMedia)
압축 효율 양호 양호 매우 좋음 (H.264 대비 ~50% 향상) 탁월함 (VP9 대비 ~30% 향상)
CPU 부하 낮음 낮음 (하드웨어 가속 보편화) 중간-높음 높음
호환성 WebRTC 필수 지원 폭넓게 지원 (하드웨어 가속) 양호 (Chrome, Firefox) 성장 중 (Chrome, Firefox, Safari)
주요 사용 사례 기본 호환성 확보 모바일 기기 (하드웨어 가속) 고화질 스트리밍 저대역폭 환경, 화면 공유

SFU 아키텍처를 사용하는 다자간 통화에서는 참여자들의 네트워크 환경이 각기 다르다. 고성능 데스크톱 사용자와 저속의 3G 네트워크를 사용하는 모바일 사용자가 동시에 통화에 참여할 수 있다. 이처럼 이기종 네트워크 환경에서 모든 참여자에게 최적의 통화 품질을 제공하기 위해 대역폭 적응 기술이 필수적이다. WebRTC에서는 주로 Simulcast와 SVC가 사용된다.

현재는 구현의 용이성 때문에 Simulcast가 널리 사용되고 있지만, 코덱 지원과 기술 성숙도가 높아짐에 따라 장기적으로는 더 효율적인 SVC가 대세가 될 것으로 예상된다. 이 두 기술은 SFU가 다양한 네트워크 환경에 동적으로 대응하여 서비스 품질(QoE)을 유지하는 데 핵심적인 역할을 수행한다.

WebRTC는 설계 초기부터 보안을 최우선 과제로 삼았다. 웹 페이지가 사용자의 카메라와 마이크라는 매우 민감한 자원에 접근할 수 있는 강력한 권한을 갖게 되면서, 이에 따르는 개인정보 침해 및 도감청 위협을 원천적으로 차단할 필요가 있었기 때문이다.

WebRTC의 보안 모델은 ‘기본적으로 안전하게(Secure by Default)’라는 철학에 기반한다. 이는 보안을 개발자의 선택 사항으로 남겨두지 않고, 프로토콜 스택의 모든 계층에서 암호화를 의무화하는 방식으로 구현되었다.66 암호화되지 않은 WebRTC 통신은 IETF 표준에 의해 명시적으로 금지되며, 브라우저는 암호화 설정이 없는 연결 시도를 거부한다.5

이 의무적 암호화는 두 가지 핵심 프로토콜을 통해 이루어진다:

이처럼 DTLS와 SRTP가 유기적으로 결합된 DTLS-SRTP 방식은 WebRTC 통신의 모든 구성 요소(시그널링 메타데이터 교환, 데이터 채널, 미디어 스트림)가 강력한 암호화로 보호되도록 보장한다. WebRTC가 암호화를 선택이 아닌 필수로 규정한 것은, 개발자의 실수나 무지로 인해 발생할 수 있는 보안 허점을 근본적으로 차단하고, 모든 사용자가 기본적으로 안전한 통신 환경을 누릴 수 있도록 하기 위한 핵심적인 설계 결정이었다.

1:1 P2P 통신에서는 DTLS-SRTP가 두 참여자 사이의 통신을 직접 암호화하므로 완벽한 종단간 암호화(E2EE, End-to-End Encryption)를 제공한다. 하지만 다자간 통신을 위해 SFU 서버를 도입하는 순간, 이 E2EE 모델은 깨지게 된다.16

SFU 아키텍처에서는 각 참여자와 SFU 서버 사이에 개별적인 보안 채널(DTLS-SRTP 세션)이 설정된다. 참여자 A가 보낸 미디어 스트림은 A와 SFU 사이의 키로 암호화된다. SFU는 이 스트림을 다른 참여자 B에게 전달하기 위해 먼저 A의 키로 복호화한 뒤, 다시 B와 SFU 사이에 설정된 키로 재암호화하여 전송해야 한다. 이 과정에서 SFU 서버는 일시적으로 암호화되지 않은 미디어 데이터에 접근할 수 있게 된다.72 이는 SFU 운영 주체를 신뢰해야만 통신의 기밀성이 보장된다는 것을 의미하며, 진정한 의미의 E2EE는 아니다.

이러한 ‘hop-by-hop’ 암호화의 한계를 극복하고 SFU 환경에서도 E2EE를 구현하기 위해 W3C와 IETF는 새로운 기술 표준을 도입했다.

Insertable Streams와 SFrame의 등장은 확장성을 위해 SFU를 사용하면서도 최고 수준의 개인정보 보호를 달성하고자 하는 현대 RTC 서비스의 요구를 충족시키는 핵심적인 발전이다. 이는 WebRTC가 단순한 통신 도구를 넘어, 의료, 금융, 법률 등 민감한 정보를 다루는 엔터프라이즈급 보안 솔루션으로 진화하는 데 필수적인 기술적 기반이 되고 있다.

WebRTC는 이론적인 기술을 넘어 구글 미트, 페이스북 메신저, 디스코드 등 수많은 글로벌 서비스의 핵심 기술로 자리 잡았다.9 이러한 성공적인 서비스들은 WebRTC를 단순히 사용하는 것을 넘어, 자사의 요구사항에 맞게 최적화하고 확장하는 정교한 개발 전략을 적용했다.

게이머를 위한 음성 채팅 플랫폼으로 시작한 Discord는 수백만 명의 동시 접속자를 안정적으로 지원하며 WebRTC의 확장성을 증명한 대표적인 사례다.43 Discord의 성공 비결은 표준 WebRTC 기술을 그대로 사용하지 않고, 자사의 특수한 요구사항에 맞춰 핵심 구성 요소를 재설계하고 최적화한 데 있다.

Discord의 사례는 WebRTC의 진정한 잠재력이 브라우저 API를 넘어, 그 근간을 이루는 강력하고 유연한 네이티브 미디어 엔진에 있음을 보여준다. 그들은 WebRTC를 단순한 ‘웹 기술’로 국한하지 않고, 핵심 ‘미디어 엔진’으로 접근하여 자사 서비스의 특수성에 맞게 ‘해킹’하고 최적화함으로써 경쟁 우위를 확보했다. 이는 대규모 고성능 애플리케이션을 구축하려는 개발자들에게 표준 API의 한계를 넘어 네이티브 스택을 활용하는 것의 중요성을 시사하는 중요한 교훈이다.

안정적인 WebRTC 서비스를 운영하기 위해서는 통화 품질을 지속적으로 측정하고 문제가 발생했을 때 신속하게 원인을 파악할 수 있는 ‘관측 가능성(Observability)’ 확보가 필수적이다. 이를 위해 WebRTC는 강력한 내장 도구를 제공한다.

성공적인 WebRTC 서비스 운영을 위해서는 getStats() API를 주기적으로(보통 1초 간격) 호출하여 핵심 지표들을 수집하고, 이를 분석 서버로 전송하여 시계열 데이터베이스(예: Prometheus)에 저장한 뒤, 대시보드(예: Grafana)를 통해 시각화하는 모니터링 파이프라인을 구축하는 것이 표준적인 접근 방식이다.32

WebRTC 서비스를 대규모로 운영할 때 가장 큰 과제 중 하나는 비용 관리다. 주요 비용은 미디어 서버 운영에 필요한 ‘컴퓨팅’ 자원과 데이터를 전송하는 데 드는 ‘대역폭’에서 발생한다. 효과적인 비용 최적화는 이 두 가지 요소를 지능적으로 관리하는 데서 시작된다.

결론적으로, 대규모 WebRTC 서비스의 비용 최적화는 기술적 문제의 총합이다. 올바른 아키텍처 선택, TURN 트래픽 최소화, 동적인 대역폭 관리, 그리고 탄력적인 인프라 운영이 조화를 이룰 때 지속 가능한 서비스 운영이 가능하다.

WebRTC 개발은 “시작은 쉽지만, 완성은 어렵다”는 말로 요약할 수 있다. 간단한 1:1 비디오 채팅 데모는 금방 만들 수 있지만, 실제 인터넷 환경의 복잡성과 WebRTC 생태계의 동적인 특성을 고려하지 않으면 수많은 함정에 빠지기 쉽다.

WebRTC는 지난 10년간 웹 실시간 통신의 표준으로 자리 잡았지만, 그 진화는 멈추지 않고 있다. 현재 WebRTC 생태계는 더 효율적인 전송 프로토콜의 등장과 인공지능(AI) 기술의 깊숙한 통합이라는 두 가지 거대한 흐름을 중심으로 빠르게 재편되고 있다.

WebTransport는 HTTP/3의 기반이 되는 QUIC 프로토콜을 활용하여 클라이언트와 서버 간의 저지연 양방향 통신을 지원하는 새로운 웹 API다.92 이는 RTCDataChannel과 마찬가지로 신뢰성 있는 스트림(streams)과 신뢰성 없는 데이터그램(datagrams)을 모두 지원하여, WebRTC의 데이터 채널과 유사한 기능을 제공한다.94

하지만 두 기술의 근본적인 설계 철학과 목표 시장은 명확히 다르다.

이러한 차이점 때문에 WebTransport는 RTCDataChannel의 ‘대체재’가 아니라 ‘보완재’로 보는 것이 타당하다. 두 기술은 서로 다른 통신 토폴로지(topology)에 특화되어 있다. 1:1 파일 공유나 P2P 멀티플레이어 게임처럼 클라이언트 간 직접 통신이 필수적인 시나리오에서는 여전히 RTCDataChannel이 유일한 해답이다.

반면, SFU 아키텍처 기반의 화상 회의에서 클라이언트가 서버와 채팅 메시지나 실시간 투표 데이터를 교환하는 경우를 생각해보자. 현재 이 역할은 주로 WebSocket이 담당하고 있다. 하지만 WebTransport는 단일 연결 내에서 여러 독립적인 스트림을 지원하여 TCP의 ‘Head-of-Line Blocking’ 문제를 해결하고, 신뢰성 없는 데이터그램 전송도 가능하므로, WebSocket보다 더 효율적이고 유연한 대안이 될 수 있다.93 또한, WebRTC와 달리 Web Worker 내에서도 작동하여 메인 스레드의 부하를 줄일 수 있다는 장점도 있다.97

미래의 복합적인 RTC 애플리케이션은 두 기술을 함께 사용하는 하이브리드 모델로 발전할 가능성이 높다. 즉, P2P 미디어 및 데이터 전송에는 WebRTC를 사용하고, 클라이언트와 미디어 서버 간의 시그널링 및 보조 데이터 전송에는 WebTransport를 활용하는 것이다.

기능 WebRTC DataChannel WebTransport
주요 모델 Peer-to-Peer (P2P) Client-Server
기반 프로토콜 SCTP over DTLS over UDP QUIC (HTTP/3) over UDP
연결 설정 복잡함 (시그널링, ICE, STUN/TURN) 상대적으로 단순함 (QUIC Handshake)
주요 사용 사례 P2P 파일 공유, P2P 게임, 채팅 저지연 클라이언트-서버 메시징, 게임 상태 동기화, WebSocket 대체
서버 복잡성 높음 (시그널링 + STUN/TURN 서버) 중간 (HTTP/3 서버 필요)
Web Worker 지원 불가능 가능

WebRTC는 본래 양방향 상호작용을 위해 설계되었지만, 초저지연 특성 덕분에 라이브 스트리밍 및 방송 분야에서도 큰 주목을 받고 있다. 하지만 WebRTC에는 표준화된 시그널링 프로토콜이 없어, OBS와 같은 방송 소프트웨어나 CDN(콘텐츠 전송 네트워크)과 같은 기존 방송 인프라와 연동하는 데 어려움이 있었다.

이러한 문제를 해결하기 위해 IETF에서 WHIP과 WHEP이라는 두 가지 표준 프로토콜이 제안되었다.

WHIP/WHEP은 WebRTC를 기존 방송 생태계에 통합하는 표준화된 ‘접착제’ 역할을 한다. 이를 통해 개발자들은 특정 벤더에 종속되지 않고 다양한 방송 솔루션을 자유롭게 조합하여 초저지연 라이브 스트리밍 서비스를 구축할 수 있게 되었다. 이는 WebRTC가 양방향 통신을 넘어 대규모 일대다(one-to-many) 방송의 영역으로 확장되는 중요한 전환점이 되고 있다.

인공지능(AI) 및 머신러닝(ML) 기술은 더 이상 WebRTC의 부가 기능이 아니라, 핵심적인 사용자 경험(UX)과 서비스 품질(QoE)을 결정하는 요소로 깊숙이 통합되고 있다.

이러한 진화는 WebRTC의 역할을 재정의하고 있다. WebRTC는 더 이상 단순히 미디어 패킷을 전달하는 전송 계층에 머무르지 않고, AI 모델이 실시간으로 미디어 스트림을 분석, 가공, 최적화하는 ‘지능형 미디어 파이프라인’의 핵심 인프라로 기능하고 있다. 미래의 WebRTC 서비스 경쟁력은 누가 더 정교한 AI 모델을 미디어 파이프라인에 통합하여 우수한 사용자 경험과 안정적인 품질을 제공하느냐에 따라 결정될 것이다.

WebRTC의 시그널링은 여전히 중앙 서버에 의존하고 있어, 확장성, 개인정보 보호, 검열 저항성 측면에서 근본적인 한계를 가지고 있다. 이러한 문제를 해결하기 위한 노력은 표준화 기구와 학계 연구를 중심으로 진행되고 있다.

현재의 중앙화된 시그널링 모델은 당분간 주류로 남겠지만, 장기적으로는 MIMI와 같은 표준화 노력을 통해 서비스 간 상호운용성이 증대되고, 탈중앙화 기술의 발전이 WebRTC를 진정한 의미의 서버리스 P2P 통신 기술로 완성하는 마지막 퍼즐 조각이 될 잠재력을 가지고 있다.

WebRTC는 지난 10여 년간 웹의 지형을 근본적으로 바꾸어 놓았다. 독점적인 플러그인 기술의 시대를 종식시키고, 모든 웹 개발자에게 실시간 통신이라는 강력한 도구를 제공함으로써 웹을 단순한 정보 소비의 공간에서 실시간 상호작용과 협업의 플랫폼으로 진화시켰다.

본 고찰을 통해 WebRTC의 다층적인 구조와 핵심적인 기술적 트레이드오프를 확인할 수 있었다.

  1. 아키텍처의 진화: 단순한 1:1 통신을 위한 Mesh 구조에서 출발하여, 대규모 다자간 통신을 위한 SFU 아키텍처가 현대적인 표준으로 자리 잡았다. 이는 확장성, 비용, 클라이언트 부하 사이의 가장 합리적인 균형점을 제공하며, Cascading SFU를 통해 글로벌 서비스로의 확장을 가능하게 한다. MCU는 레거시 호환성 등 특수한 요구사항을 위한 선택지로 남아있다.
  2. 보안 우선 설계: ‘의무적 암호화’는 WebRTC의 타협할 수 없는 설계 철학이다. DTLS-SRTP를 통해 모든 통신 채널을 기본적으로 보호하며, 최근에는 Insertable Streams와 SFrame의 도입으로 SFU 환경에서도 진정한 종단간 암호화(E2EE)를 구현할 수 있는 길이 열렸다. 이는 WebRTC가 최고 수준의 보안을 요구하는 애플리케이션으로 영역을 확장하는 기반이 된다.
  3. 성공적인 서비스의 조건: Discord와 같은 성공 사례는 WebRTC의 잠재력을 최대한 활용하기 위해서는 표준 API를 사용하는 것을 넘어, 네이티브 라이브러리 수준의 깊이 있는 최적화와 서비스 특성에 맞는 독자적인 시그널링 프로토콜 설계가 중요함을 보여준다. 또한, getStats() API와 webrtc-internals를 활용한 체계적인 모니터링 및 디버깅 없이는 안정적인 서비스 운영이 불가능하다.
  4. 미래를 향한 끊임없는 혁신: WebRTC 생태계는 정체되어 있지 않다. 클라이언트-서버 통신을 위한 WebTransport, 방송 표준화를 위한 WHIP/WHEP과 같은 차세대 프로토콜이 등장하며 그 영역을 넓히고 있다. 무엇보다 AI 기술이 미디어 파이프라인에 깊숙이 통합되면서, 단순한 품질 향상을 넘어 네트워크 상태를 예측하고 선제적으로 대응하는 지능형 통신으로 진화하고 있다.

결론적으로, WebRTC는 단순한 기술 스택을 넘어 하나의 거대한 생태계로 성장했다. 그 복잡성에도 불구하고, WebRTC가 제공하는 강력한 실시간 P2P 통신 능력은 미래의 웹 애플리케이션을 정의하는 핵심 요소로 계속해서 기능할 것이다. 개발자는 이 기술의 근본적인 원리와 아키텍처적 트레이드오프를 깊이 이해함으로써, 단순한 화상 채팅 앱을 넘어선 혁신적인 실시간 서비스를 창조할 수 있을 것이다.

  1. [webRTC 뽀개기] webRTC란 - SHININGJEAN DEV STORY - 티스토리, accessed July 29, 2025, https://shiningjean.tistory.com/72
  2. WebRTC - 위키백과, 우리 모두의 백과사전, accessed July 29, 2025, https://ko.wikipedia.org/wiki/WebRTC
  3. WebRTC란? - Medium, accessed July 29, 2025, https://medium.com/@hyun.sang/webrtc-webrtc%EB%9E%80-43df68cbe511
  4. Use WebRTC API to Stream In-Browser Media - OnSIP, accessed July 29, 2025, https://www.onsip.com/voip-resources/voip-fundamentals/use-webrtc-api-stream-in-browser-media
  5. RTCPeerConnection - Everything You Need To Know - 100ms.live, accessed July 29, 2025, https://www.100ms.live/blog/rtcpeerconnection
  6. WebRTC and SIP: What’s Best for My Business? - Vonage, accessed July 29, 2025, https://www.vonage.com/resources/articles/webrtc-vs-sip-whats-best-for-my-business/
  7. [WEB] WebRTC란?, accessed July 29, 2025, https://jmdwlee.tistory.com/17
  8. [WebRTC] WebRTC란 무엇일까? - GHY ‘s TechBlog - 티스토리, accessed July 29, 2025, https://gh402.tistory.com/38
  9. 8 Powerful Applications Built Using WebRTC - United World Telecom, accessed July 29, 2025, https://www.unitedworldtelecom.com/learn/webrtc-applications/
  10. What is WebRTC? (Explanation, use cases, and features) - Ably, accessed July 29, 2025, https://ably.com/blog/what-is-webrtc
  11. WebRTC란? - 오늘도 깨달았다 - 티스토리, accessed July 29, 2025, https://realizetoday.tistory.com/41
  12. WebRTC 란? - 생각하는 개발자 - 티스토리, accessed July 29, 2025, https://com789.tistory.com/24
  13. WebRTC, accessed July 29, 2025, https://webrtc.org/
  14. WebRTC (Web Real-Time Communication) 소개 - Cross Code, accessed July 29, 2025, https://cross-code.github.io/posts/WebRTC/
  15. Limitations of WebRTC - Dyte, accessed July 29, 2025, https://dyte.io/blog/webrtc-limitations/
  16. What Are the Disadvantages of WebRTC in 2025? Full Guide for Developers - VideoSDK, accessed July 29, 2025, https://www.videosdk.live/developer-hub/webrtc/what-are-the-disadvantages-of-webrtc
  17. What is the difference between SFU and MCU - Oodles Technologies, accessed July 29, 2025, https://www.oodlestechnologies.com/dev-blog/what-is-the-difference-between-sfu-and-mcu/
  18. How to Successfully Scale Your WebRTC Application in 2021 - LiveSwitch, accessed July 29, 2025, https://www.liveswitch.io/blog/archive/how-to-successfully-scale-your-webrtc-application
  19. WebRTC를 사용한 실시간 통신 - Google Codelabs, accessed July 29, 2025, https://codelabs.developers.google.com/codelabs/webrtc-web?hl=ko
  20. 7 Common WebRTC Pitfalls to Avoid at Any Cost - Softobiz, accessed July 29, 2025, https://softobiz.com/7-common-webrtc-pitfalls-to-avoid-at-any-cost/
  21. Media Capture and Streams API (Media Stream) - Web APIs MDN, accessed July 29, 2025, https://developer.mozilla.org/en-US/docs/Web/API/Media_Capture_and_Streams_API
  22. WebRTC Media Stream APIs - Tutorialspoint, accessed July 29, 2025, https://www.tutorialspoint.com/webrtc/webrtc_media_stream_apis.htm
  23. RTCPeerConnection - Web APIs MDN, accessed July 29, 2025, https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection
  24. RTCDataChannel - WebRTC Explained - OnSIP, accessed July 29, 2025, https://www.onsip.com/voip-resources/voip-fundamentals/rtcdatachannels
  25. RTCDataChannel - Web APIs MDN, accessed July 29, 2025, https://developer.mozilla.org/en-US/docs/Web/API/RTCDataChannel
  26. RTCPeerConnection - WebRTC Explained - OnSIP, accessed July 29, 2025, https://www.onsip.com/voip-resources/voip-fundamentals/rtcpeerconnection
  27. WebRTC connectivity - Web APIs - MDN Web Docs - Mozilla, accessed July 29, 2025, https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/Connectivity
  28. WebRTC mistakes: Common mistakes (beginner) - BlogGeek.me, accessed July 29, 2025, https://bloggeek.me/common-beginner-mistakes-in-webrtc/
  29. SDP Messages Tutorial - Session Description Protocol - GetStream.io, accessed July 29, 2025, https://getstream.io/resources/projects/webrtc/basics/sdp-messages/
  30. Introduction to WebRTC protocols - Web APIs - MDN Web Docs - Mozilla, accessed July 29, 2025, https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/Protocols
  31. WebRTC Security - Understanding the Role of ICE, STUN, and TURN for Enhanced Communication - MoldStud, accessed July 29, 2025, https://moldstud.com/articles/p-webrtc-security-understanding-the-role-of-ice-stun-and-turn-for-enhanced-communication
  32. How to Optimize Costs in Large-Scale WebRTC Applications - CyberPanel, accessed July 29, 2025, https://cyberpanel.net/blog/how-to-optimize-costs-in-large-scale-webrtc-applications
  33. WebRTC Stun vs Turn Servers - GetStream.io, accessed July 29, 2025, https://getstream.io/resources/projects/webrtc/advanced/stun-turn/
  34. STUN vs. TURN vs. ICE - SignalWire Docs, accessed July 29, 2025, https://developer.signalwire.com/platform/basics/general/stun-vs-turn-vs-ice/
  35. WebRTC: P2P, SFU, MCU and All You Need to Know About Them Software Mansion, accessed July 29, 2025, https://blog.swmansion.com/webrtc-p2p-sfu-mcu-and-all-you-need-to-know-about-them-596b6ccb6ddf
  36. Selective Forwarding Unit (SFU) - GetStream.io, accessed July 29, 2025, https://getstream.io/resources/projects/webrtc/architectures/sfu/
  37. WebRTC SFU: the complete Guide. - Metered Video, accessed July 29, 2025, https://www.metered.ca/blog/webrtc-sfu-the-complete-guide/
  38. P2P? SFU? MCU? Which WebRTC Architecture is Right for You SignalWire, accessed July 29, 2025, https://signalwire.com/blogs/industry/p2p-sfu-mcu-find-out-which-webrtc-architecture-is-right-for-you
  39. Multipoint Control Unit (MCU) - GetStream.io, accessed July 29, 2025, https://getstream.io/resources/projects/webrtc/architectures/mcu/
  40. SFU, MCU, or P2P: What’s the Difference Between These WebRTC Architectures?, accessed July 29, 2025, https://getstream.io/blog/what-is-a-selective-forwarding-unit-in-webrtc/
  41. WebRTC Architecture and How does it Work – A Layman’s Guide - Tragofone, accessed July 29, 2025, https://tragofone.com/webrtc-architecture-types-guide/
  42. How does Google Meet work technically? A Deep Dive into Real-Time Communication, accessed July 29, 2025, https://www.byteplus.com/en/topic/99967
  43. How Discord Handles Two and Half Million Concurrent Voice Users …, accessed July 29, 2025, https://discord.com/blog/how-discord-handles-two-and-half-million-concurrent-voice-users-using-webrtc
  44. Scaling Real-Time Video on AWS: How We Keep WebRTC Latency Below 150ms with Kubernetes Autoscaling HackerNoon, accessed July 29, 2025, https://hackernoon.com/scaling-real-time-video-on-aws-how-we-keep-webrtc-latency-below-150ms-with-kubernetes-autoscaling
  45. SFU Cascading - Why cascade Selective Forwarding Units, accessed July 29, 2025, https://getstream.io/glossary/sfu-cascading/
  46. MediaDevices: getUserMedia() method - Web APIs MDN, accessed July 29, 2025, https://developer.mozilla.org/en-US/docs/Web/API/MediaDevices/getUserMedia
  47. WebRTC MediaStream Tutorial - GetStream.io, accessed July 29, 2025, https://getstream.io/resources/projects/webrtc/basics/mediastream/
  48. Media Capture and Streams - W3C, accessed July 29, 2025, https://www.w3.org/TR/mediacapture-streams/
  49. RTCPeerConnection WebRTC Tutorial - GetStream.io, accessed July 29, 2025, https://getstream.io/resources/projects/webrtc/basics/rtcpeerconnection/
  50. Peer connections WebRTC, accessed July 29, 2025, https://webrtc.org/getting-started/peer-connections-advanced
  51. WebRTC API - MDN Web Docs - Mozilla, accessed July 29, 2025, https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API
  52. RTCDataChannel WebRTC Tutorial - GetStream.io, accessed July 29, 2025, https://getstream.io/resources/projects/webrtc/basics/rtcdatachannel/
  53. WebRTC data channels - Game development - MDN Web Docs, accessed July 29, 2025, https://developer.mozilla.org/en-US/docs/Games/Techniques/WebRTC_data_channels
  54. WebRTC Data Channels: A Comprehensive Guide for Developers - VideoSDK, accessed July 29, 2025, https://www.videosdk.live/developer-hub/webrtc/webrtc-data-channel
  55. Using WebRTC data channels - Web APIs, accessed July 29, 2025, https://udn.realityripple.com/docs/Web/API/WebRTC_API/Using_data_channels
  56. Codecs used by WebRTC - Media - MDN Web Docs - Mozilla, accessed July 29, 2025, https://developer.mozilla.org/en-US/docs/Web/Media/Guides/Formats/WebRTC_codecs
  57. 5 Key Reasons AV1 Will Play a Big Role in WebRTC Streaming - Red5 Pro, accessed July 29, 2025, https://www.red5.net/blog/av1-webrtc-streaming/
  58. Better video for mobile RTC with AV1 and HD - Engineering at Meta, accessed July 29, 2025, https://engineering.fb.com/2024/03/20/video-engineering/mobile-rtc-video-av1-hd/
  59. AV1 Codec Hardware Decode Adoption - ScientiaMobile, accessed July 29, 2025, https://scientiamobile.com/av1-codec-hardware-decode-adoption/
  60. Scalable Video Coding for WebRTC - Wowza, accessed July 29, 2025, https://www.wowza.com/blog/scalable-video-coding-for-webrtc
  61. VP9 Scalable Video Coding for routed sessions Vonage Video API Developer, accessed July 29, 2025, https://tokbox.com/developer/guides/codecs/vp9-public-beta.html
  62. Scalable Video Coding (SVC)：What is it and How It Work? - ZEGOCLOUD, accessed July 29, 2025, https://www.zegocloud.com/blog/scalable-video-coding
  63. Scalable Video Coding (SVC) - What is it and how does it work? - GetStream.io, accessed July 29, 2025, https://getstream.io/glossary/scalable-video-coding/
  64. Temporal Scalability BlogGeek.me, accessed July 29, 2025, https://bloggeek.me/webrtcglossary/temporal-scalability/
  65. How is SVC different from simulcast? - YouTube, accessed July 29, 2025, https://www.youtube.com/watch?v=HhIVI54XwxM
  66. Why is WebRTC encrypted? - Stack Overflow, accessed July 29, 2025, https://stackoverflow.com/questions/35070473/why-is-webrtc-encrypted
  67. WebRTC Encryption and security [Complete guide] - Telnyx, accessed July 29, 2025, https://telnyx.com/resources/webrtc-encryption-and-security
  68. Understanding WebRTC Security Architecture - Nabto, accessed July 29, 2025, https://www.nabto.com/understanding-webrtc-security/
  69. A Study of WebRTC Security, accessed July 29, 2025, https://webrtc-security.github.io/
  70. WebRTC Security - Is it secure and safe? - GetStream.io, accessed July 29, 2025, https://getstream.io/resources/projects/webrtc/advanced/security/
  71. This is common and necessary for WebRTC SFUs, which perhaps is why Discord does - Hacker News, accessed July 29, 2025, https://news.ycombinator.com/item?id=22032066
  72. True End-to-End Encryption with WebRTC Insertable Streams - webrtcHacks, accessed July 29, 2025, https://webrtchacks.com/true-end-to-end-encryption-with-webrtc-insertable-streams/
  73. WebRTC Encryption and Security: Everything You Need to Know (Update) - Wowza, accessed July 29, 2025, https://www.wowza.com/blog/webrtc-encryption-and-security
  74. Intent to Ship: WebRTC Insertable Streams - Google Groups, accessed July 29, 2025, https://groups.google.com/a/chromium.org/g/blink-dev/c/XFO4OXrdSRA
  75. End-to-end-encrypt WebRTC in all browsers! - The Mozilla Blog, accessed July 29, 2025, https://blog.mozilla.org/webrtc/end-to-end-encrypt-webrtc-in-all-browsers/
  76. What is WebRTC Insertable Stream: Comprehensive Guide to WebRTC Encoded Transform, accessed July 29, 2025, https://trtc.io/blog/details/what-is-webrtc-insertable-streams
  77. End-to-End Post-Quantum Cryptography Encryption Protocol for Video Conferencing System Based on Government Public Key Infrastructure - MDPI, accessed July 29, 2025, https://www.mdpi.com/2571-5577/6/4/66
  78. SFrame E2EE for Video Conferencing - IETF Datatracker, accessed July 29, 2025, https://datatracker.ietf.org/meeting/109/materials/slides-109-sframe-sframe-e2ee-01
  79. SFrame.js: end to end encryption for WebRTC by Medooze - Medium, accessed July 29, 2025, https://medooze.medium.com/sframe-js-end-to-end-encryption-for-webrtc-f9a83a997d6d
  80. Discord Blog - Medium, accessed July 29, 2025, https://medium.com/discord-engineering/subpage/da6018da75f8
  81. WebRTC getStats() results explained - YouTube, accessed July 29, 2025, https://www.youtube.com/watch?v=B1MgeVkRQ-M
  82. Making sense of getStats in WebRTC - BlogGeek.me, accessed July 29, 2025, https://bloggeek.me/getstats/
  83. Identifiers for WebRTC’s Statistics API - W3C, accessed July 29, 2025, https://www.w3.org/TR/webrtc-stats/
  84. WebRTC Statistics using getStats, accessed July 29, 2025, https://www.webrtc-developers.com/webrtc-statistics-using-getstats/
  85. Enhance WebRTC Performance - A Comprehensive Developer’s Guide to Debugging Tools, accessed July 29, 2025, https://moldstud.com/articles/p-enhance-webrtc-performance-a-comprehensive-developers-guide-to-debugging-tools
  86. Measuring WebRTC Call Quality - Part 1 - 100ms.live, accessed July 29, 2025, https://www.100ms.live/blog/measuring-webrtc-call-quality-part-1
  87. Tools to use when debugging WebRTC Video calls - GetStream.io, accessed July 29, 2025, https://getstream.io/blog/debug-calls-dashboard/
  88. webrtc-internals - BlogGeek.me, accessed July 29, 2025, https://bloggeek.me/webrtcglossary/webrtc-internals/
  89. Everything you wanted to know about webrtc-internals and getStats - BlogGeek.me, accessed July 29, 2025, https://bloggeek.me/webrtc-internals/
  90. 10 Important WebRTC Streaming Metrics and Configuring Prometheus + Grafana Monitoring, accessed July 29, 2025, https://flashphoner.com/10-important-webrtc-streaming-metrics-and-configuring-prometheus-grafana-monitoring/
  91. 8 ways to optimize WebRTC performance - BlogGeek.me, accessed July 29, 2025, https://bloggeek.me/optimize-webrtc-performance/
  92. WebRTC vs WebTransport: Comparison Guide - VideoSDK, accessed July 29, 2025, https://www.videosdk.live/developer-hub/webtransport/webrtc-vs-webtransport
  93. Using WebTransport Capabilities - Chrome for Developers, accessed July 29, 2025, https://developer.chrome.com/docs/capabilities/web-apis/webtransport
  94. What is WebTransport and can it replace WebSockets? - Ably, accessed July 29, 2025, https://ably.com/blog/can-webtransport-replace-websockets
  95. WebSocket vs WebRTC DataChannel: Choosing the Right Real-Time Tech - VideoSDK, accessed July 29, 2025, https://www.videosdk.live/developer-hub/webrtc/websocket-vs-webrtc-datachannel
  96. Using WebTransport - Hacker News, accessed July 29, 2025, https://news.ycombinator.com/item?id=32867644
  97. An additional benefit of WebTransport over WebRTC DataChannels is that the WebTr… Hacker News, accessed July 29, 2025, https://news.ycombinator.com/item?id=38074346
  98. WHIP - BlogGeek.me, accessed July 29, 2025, https://bloggeek.me/webrtcglossary/whip/
  99. RFC 9725: WebRTC-HTTP Ingestion Protocol (WHIP), accessed July 29, 2025, https://www.rfc-editor.org/rfc/rfc9725.html
  100. WebRTC WHIP & WHEP Tutorial: Build a live Streaming App - Metered Video, accessed July 29, 2025, https://www.metered.ca/blog/webrtc-whip-whep-tutorial-build-a-live-streaming-app/
  101. RFC 9725 - WebRTC-HTTP Ingestion Protocol (WHIP) - Datatracker - IETF, accessed July 29, 2025, https://datatracker.ietf.org/doc/rfc9725/
  102. wish-wg/webrtc-http-egress-protocol: WHEP - GitHub, accessed July 29, 2025, https://github.com/wish-wg/webrtc-http-egress-protocol
  103. WebRTC adaptive bitrate WHEP in Nimble Streamer - Softvelum, accessed July 29, 2025, https://softvelum.com/2024/05/webrtc-whep-abr-nimble-streamer/
  104. Building Interactive Streaming Apps: WebRTC, WHIP & WHEP Explained, accessed July 29, 2025, https://blog.swmansion.com/building-interactive-streaming-apps-webrtc-whip-whep-explained-d38f4825ec90
  105. How to Implement AI Noise Reduction in WebRTC - Tencent RTC, accessed July 29, 2025, https://trtc.io/blog/details/How-to-Implement-AI-Noise-Reduction
  106. ElevenLabs Conversational AI now supports WebRTC, accessed July 29, 2025, https://elevenlabs.io/blog/conversational-ai-webrtc
  107. How can I improve noise suppression in OpenAI with WebRTC? - Bugs, accessed July 29, 2025, https://community.openai.com/t/how-can-i-improve-noise-suppression-in-openai-with-webrtc/1245043
  108. Deep Learning-based Background Removal And Blur In A Real …, accessed July 29, 2025, https://mobidev.biz/blog/background-removal-and-blur-in-a-real-time-video
  109. Edit live video background with WebRTC and TensorFlow.js - Francium Tech, accessed July 29, 2025, https://blog.francium.tech/edit-live-video-background-with-webrtc-and-tensorflow-js-c67f92307ac5
  110. Background blurring for WebRTC: “Backgrounds are blurry, but the future is clear - YouTube, accessed July 29, 2025, https://www.youtube.com/watch?v=yuUbVQdTRZQ
  111. The Ultimate Guide to Live Transcription API: Real-Time Speech-to-Text for Developers (2025) - VideoSDK, accessed July 29, 2025, https://www.videosdk.live/developer-hub/social/live-transcription-api
  112. Transcribe Meetings in Realtime Deepgram’s Docs, accessed July 29, 2025, https://developers.deepgram.com/docs/transcribe-meetings-in-realtime
  113. 1 Introduction - arXiv, accessed July 29, 2025, https://arxiv.org/html/2410.03339v2
  114. Robust Bandwidth Estimation for Real-Time Communication with Offline Reinforcement Learning - ResearchGate, accessed July 29, 2025, https://www.researchgate.net/publication/393512015_Robust_Bandwidth_Estimation_for_Real-Time_Communication_with_Offline_Reinforcement_Learning
  115. Optimizing RTC bandwidth estimation with machine learning - Engineering at Meta, accessed July 29, 2025, https://engineering.fb.com/2024/03/20/networking-traffic/optimizing-rtc-bandwidth-estimation-machine-learning/
  116. Understanding AI Network Congestion Control: A Comprehensive Guide - Orhan Ergun, accessed July 29, 2025, https://orhanergun.net/understanding-ai-network-congestion-control-a-comprehensive-guide
  117. Machine Learning for End-to-End Congestion Control, accessed July 29, 2025, https://par.nsf.gov/servlets/purl/10179370
  118. More Instant Messaging Interoperability (mimi) - Datatracker - IETF, accessed July 29, 2025, https://datatracker.ietf.org/wg/mimi/about/
  119. MIMI: More IM Interop - Datatracker, accessed July 29, 2025, https://datatracker.ietf.org/doc/bofreq-mahy-mimi-more-im-interop/
  120. More Instant Messaging Interoperability - IETF Datatracker, accessed July 29, 2025, https://datatracker.ietf.org/doc/bofreq-cooper-more-instant-messaging-interoperability/
  121. draft-mahy-mimi-content-00 - More Instant Messaging Interoperability (MIMI) message content - IETF Datatracker, accessed July 29, 2025, https://datatracker.ietf.org/doc/draft-mahy-mimi-content/00/
  122. Distributed WebRTC Signaling Term Project - eprints, accessed July 29, 2025, https://eprints.ost.ch/id/eprint/737/1/HS%202018%202019-SA-EP-R%C3%B6llin-Thoma-P2P%20Messenger%20%20%20P2P%20Skype.pdf
  123. Decentralized Bootstrapping for WebRTC-based P2P Networks - UPV, accessed July 29, 2025, https://personales.upv.es/thinkmind/dl/conferences/web/web_2017/web_2017_1_30_40029.pdf
  124. Decentralized WebRTC signaling : r/ethereum - Reddit, accessed July 29, 2025, https://www.reddit.com/r/ethereum/comments/2ihtan/decentralized_webrtc_signaling/