WebRTC 전송과 토폴로지 — ICE, Full Mesh, SFU

WebRTC topology를 이해하려면 transport path, 송신 복제량, server의 media 처리 범위를 나눠 봐야 합니다. 이 글은 WebRTC가 UDP를 우선하면서도 TURN/TCP·TURN/TLS relay를 사용할 수 있는 이유, full mesh의 부하가 참가자 수와 함께 늘어나는 방식, SFU가 RTP packet을 선택 전달하는 경계를 예제와 다이어그램으로 설명합니다.

Encoding·decoding의 위치와 1:1 통화에서 SFU를 사용할지 여부도 제품 요구사항에 따라 구분합니다. 아키텍처 유형 비교는 #51, SFU 확장 방식은 #48에서 이어집니다.

0. 핵심 명제 — SFU는 미디어 패킷을 선택 전달한다

WebRTC는 실시간 미디어에 UDP를 우선 사용하되 ICE를 통해 TURN/UDP와 TURN/TCP, 구현에 따라 TURN/TLS 같은 대체 경로도 선택할 수 있습니다. 풀 메시에서는 참가자마다 송신 대상과 연결 상태가 늘어납니다. SFU는 각 송신자가 게시한 RTP 스트림을 수신자별로 선택해 전달하며, 일반적으로 MCU처럼 모든 영상을 디코딩·합성·재인코딩하지 않습니다.

먼저 흔한 오해부터 정정하고 시작합니다:

1. WebRTC 실시간 미디어 전송

HTTP/1.1·HTTP/2와 실시간 미디어의 요구가 다르다

HTTP/1.1과 HTTP/2는 TCP 위에서 동작하고, 파일 다운로드와 전통적인 HLS 전달에도 흔히 쓰입니다. 다만 HTTP/3는 QUIC/UDP를 사용하므로 "웹은 전부 TCP"라고 말하면 정확하지 않습니다. TCP는 애플리케이션에 순서가 보장된 바이트 스트림을 제공합니다.

TCP 세그먼트가 유실되면 해당 연결의 뒤쪽 바이트는 재전송된 바이트가 채워질 때까지 애플리케이션에 순서대로 전달되지 못할 수 있습니다. 이것이 전송 계층의 Head-of-Line Blocking(HOL 블로킹) 입니다.

TCP의 세계 — 패킷 #2 하나가 유실되면:

 보낸 순서:  [#1] [#2] [#3] [#4] [#5]
                   ✗ 유실
 받는 쪽:   [#1] ....... 대기 ....... 
                  │
                  │ #2 재전송 요청 → 왕복 시간(RTT)만큼 기다림
                  ▼
            [#1] [#2] [#3] [#4] [#5]   ← #3~#5는 이미 도착해 있었는데
                                          #2 때문에 전부 묶여 있었음

택배로 비유하면: 3권짜리 전집을 주문했는데 2권이 배송 중 분실됐다고 이미 도착한 3권을 경비실이 안 내주는 상황입니다. 소설책이라면 순서대로 읽어야 하니 합리적이지만…

실시간 미디어는 다르다 — "늦은 프레임은 죽은 프레임"

화상회의에서는 늦게 도착한 데이터의 가치가 낮아질 수 있습니다. 그래서 WebRTC 미디어는 보통 UDP 경로에서 지터 버퍼, NACK/RTX, FEC와 코덱 오류 은닉을 조합합니다. 모든 손실을 무조건 버리는 것도, 모든 재전송을 무조건 기다리는 것도 아닙니다.

브라우저는 웹 페이지에 범용 UDP 소켓을 직접 제공하지 않습니다. WebRTC는 ICE 연결성 검사와 DTLS-SRTP 등 필요한 보안 절차를 포함한 실시간 미디어 API를 제공합니다. 다만 WebRTC가 항상 UDP로 연결되는 것은 아니며, RFC 8835는 TURN/UDP와 TURN/TCP 지원을 요구하고 TURN/TLS는 선택적으로 둘 수 있습니다. WebTransport도 UDP 기반 datagram을 제공하지만 WebRTC의 미디어 캡처·RTP 처리 API를 대체하는 동일한 기능은 아닙니다.

프리세일즈 답변: WebSocket은 TCP의 순서 보장과 HOL 특성을 상속합니다. 직접 미디어 전송을 설계할 수는 있지만 혼잡 제어, 지터 처리, 손실 복구, A/V 동기화까지 애플리케이션이 책임져야 합니다. 브라우저 실시간 통화에는 이 기능을 표준화한 WebRTC가 보통 적합합니다.

2. 풀 메시 P2P의 확장 비용

1:1 — 직접 경로와 TURN 경로

WebRTC 피어 연결은 ICE가 찾은 후보 쌍 중 우선순위와 연결성 검사를 통과한 경로를 사용합니다. 두 브라우저가 직접 연결될 수도 있고, NAT·방화벽 조건에 따라 TURN 서버를 거칠 수도 있습니다. 시그널링 서버도 애플리케이션이 별도로 제공해야 합니다.

      A ◀━━━━ 직접 ICE 경로 예시 ━━━━▶ B

  · 직접 경로가 잡히면 미디어 서버를 거치지 않음
  · 직접 경로가 실패하면 TURN 릴레이 가능
  · 실제 지연과 비용은 선택된 후보 쌍에 따라 달라짐

n명 — 업로드 회선이 먼저 죽는다

그런데 3명, 5명, 8명이 되면? P2P 구조(풀 메시, full mesh)에서는 각자가 나머지 전원에게 자기 영상을 따로따로 업로드해야 합니다.

        4명 회의의 P2P (Mesh):

         A ◀━━━━▶ B          각 참가자:
         ▲ ╲    ╱ ▲           · 업로드 3줄기 (n-1)
         ┃  ╲  ╱  ┃           · 다운로드 3줄기 (n-1)
         ┃   ╲╱   ┃           · 연결 관리 3개
         ┃   ╱╲   ┃
         ▼  ╱  ╲  ▼          전체 연결 수: n(n-1)/2 = 6개
         C ◀━━━━▶ D

숫자를 넣어보면 문제가 선명해집니다. 720p 영상 한 줄기를 1.5Mbps라고 하면:

포인트는 두 가지입니다:

1. 완전 연결 풀 메시에서는 송신 대상이 (n-1)개로 늘어납니다. 실제 병목은 가입자 회선의 업링크, 무선 상태와 TURN 사용 여부에 따라 달라집니다.
2. 구현은 같은 인코딩 결과를 여러 연결에 보낼 수도 있고 피어별 설정에 따라 추가 인코딩을 만들 수도 있습니다. 어느 경우든 연결별 혼잡 제어와 암호화·송신 부담은 늘어납니다. (모바일 발열의 구조적 원인은 #46 참고)

따라서 P2P Mesh의 상한을 "4명"이나 "6명"으로 고정할 수는 없습니다. 목표 코덱·해상도·simulcast 구성, 단말 등급, TURN 비율과 네트워크 조건으로 부하 시험한 결과를 제품 한계로 사용해야 합니다.

3. SFU — 게시한 스트림을 수신자별로 전달한다

우체국 모델

SFU(Selective Forwarding Unit) 는 이 문제를 구조로 풉니다. 중앙에 미디어 라우팅 허브(서버)를 두고:

• 각 참가자는 자기 미디어 트랙과 필요하면 여러 인코딩 레이어를 SFU에 게시
• SFU가 "이 스트림을 지금 누가 봐야 하지?"를 판단해서 선택적으로(Selective) 전달(Forwarding)

        4명 회의의 SFU:

         A ━━1줄기━━▶ ┌─────────┐ ━━━▶ B (A,C,D의 영상 수신)
         B ━━1줄기━━▶ │   SFU   │ ━━━▶ A (B,C,D의 영상 수신)
         C ━━1줄기━━▶ │ (서버)  │ ━━━▶ C (A,B,D의 영상 수신)
         D ━━1줄기━━▶ └─────────┘ ━━━▶ D (A,B,C의 영상 수신)

  각 참가자: 참가자별 복제 대신 SFU에 게시
  다운로드: 보는 사람 수만큼 (이건 SFU가 화질 조절로 관리)

같은 1.5Mbps 단일 게시 스트림 가정으로 SFU를 계산하면:

수신자마다 같은 스트림을 따로 보내는 구조를 피할 수 있습니다. 다만 simulcast를 사용하면 송신자가 여러 인코딩 레이어를 올리고, 화면 공유나 보조 카메라가 있으면 게시 트랙도 늘어납니다. 따라서 SFU 업로드를 언제나 "한 줄기 상수"라고 표현하면 안 됩니다.

"Selective"가 핵심 — 그냥 중계기가 아니다

SFU의 S(선택적)는 장식이 아닙니다. 25명 회의에서 내 화면에 보이는 건 크게 잡아도 9칸입니다. SFU는:

• 구독 정책에 따라 화면에 필요한 참가자의 영상만 전달할 수 있습니다.
• 송신자가 Simulcast로 여러 인코딩을 올리면 수신자 조건에 맞는 레이어를 고를 수 있습니다.
• 수신자별 대역폭 추정과 구독 정책에 따라 전달 품질을 다르게 설정할 수 있습니다.

즉 SFU는 "복사해서 뿌리는 기계"가 아니라 참가자별 맞춤 배달 정책을 실행하는 라우터입니다.

SFU vs MCU — 열어보느냐, 그대로 배달하느냐

SFU와 자주 비교되는 것이 MCU(Multipoint Control Unit) 입니다. MCU는 모든 참가자의 영상을 서버에서 디코딩 → 한 화면으로 합성 → 다시 인코딩해서 완성된 영상 1줄기를 내려보냅니다.

  SFU: 포장 그대로 배달                MCU: 열어서 재포장

  A ━▶ ┌─────┐ ━▶ (A,B,C 각각)       A ━▶ ┌──────────┐
  B ━▶ │ SFU │      압축된 채로       B ━▶ │   MCU    │ ━▶ 합성된
  C ━▶ └─────┘      그대로 전달       C ━▶ │ 디코딩   │    영상 1줄기
                                           │ 합성     │
       서버 부담: 패킷·대역폭 중심          │ 재인코딩 │  서버 부담: 연산 중심
       지연: 경로에 따라 측정               └──────────┘  지연: 처리 단계 추가

다자간 회의에는 SFU가 널리 쓰이고, 합성 출력이나 레거시 장비 연동에는 MCU 또는 별도 트랜스코딩 경로를 사용할 수 있습니다. 실제 선택 기준은 #51에서 다룹니다.

4. 그래서 인코딩·디코딩은 어디서 하나요 — Device인가 Server인가

고객 미팅에서 정말 자주 나오는 질문이고, 답은 아키텍처마다 다릅니다. 결론부터 표로:

SFU 구조의 인코딩·디코딩 분업

SFU 구조에서 한 프레임의 여정을 따라가 보면:

 [송신자 기기]                [SFU 서버]              [수신자 기기]
                                
 카메라 캡처                                          
   ↓                                                  
 인코딩 ◀━ 하드웨어 코덱      패킷 헤더만 보고          
 (H.264/VP8/AV1)             누구에게 보낼지 결정      
   ↓                          (영상 내용은 안 봄)      
 암호화(SRTP)                    ↓                    
   ↓                          구간별 재암호화 후        복호화
 UDP 송신 ━━━━━━━━━━━▶       전달(forward) ━━━━━━▶     ↓
                                                     디코딩 ◀━ 하드웨어 코덱
                                                       ↓
                                                     화면 렌더링

• 인코딩은 송신자 기기에서 수행합니다. 브라우저와 단말은 코덱·해상도·플랫폼에 따라 하드웨어 또는 소프트웨어 경로를 선택합니다. Simulcast를 쓰면 여러 인코딩을 동시에 만들 수 있으므로 CPU와 업로드 비용은 실제 단말에서 측정해야 합니다.
• 일반적인 SFU는 미디어를 디코딩·합성하지 않습니다. RTP 헤더와 RTCP 피드백, 코덱 메타데이터를 이용해 패킷이나 레이어를 라우팅합니다. 처리량과 지연은 구현, 암호화, 패킷 처리와 네트워크 용량에 따라 달라집니다.
• 디코딩은 수신자 기기에서, 받는 스트림 수만큼. 9분할 화면이면 9개 스트림을 동시에 디코딩합니다. 이게 수신 측 부담의 정체이고, SFU가 Selective하게 저화질 층을 골라주는 이유입니다.

프리세일즈 답변: SFU는 대역폭과 패킷 처리량이 중요한 반면, 디코딩·합성·재인코딩 경로는 CPU/GPU 비용이 커질 수 있습니다. 예상 구독 수, 코덱, 레이어와 egress를 함께 산정해야 합니다.

SFU 구조의 일반적인 WebRTC 전송은 A→SFU와 SFU→B가 별도 DTLS-SRTP 세션입니다. 따라서 SFU는 전송 계층에서 미디어에 접근할 수 있습니다. SFU가 내용에 접근하지 못하는 E2EE가 필요하면 W3C WebRTC Encoded Transform 같은 메커니즘과 별도 키 관리를 설계해야 합니다. 전송 암호화와 종단간 암호화를 구분해야 합니다.

5. SFU 운영에서 확인할 문제

SFU 운영에는 배치, 대역폭, 스케일링과 관측성 문제가 따라옵니다.

① 방 배정 문제 — 첫 입장자의 저주

전통 SFU는 "방(room) 하나 = SFU 서버 1대"로 묶는 경우가 많습니다. 그럼 그 서버를 어느 리전에 둘까요? 흔한 방식이 "방을 만든 첫 사용자와 가까운 리전"인데:

  서울에 사는 A가 방 개설 → 방이 서울 SFU에 배정
  그런데 참가자 B,C,D,E가 전부 상파울루에서 접속하면?

  B(브라질) ━━ 지구 반대편 ━━▶ [서울 SFU] ━━ 지구 반대편 ━━▶ C(브라질)
  
  같은 도시의 B와 C가 대화하는데
  미디어는 서울을 왕복 (장거리 경로 지연 추가)

위 수치는 경로를 설명하기 위한 예시이며 실제 RTT가 아닙니다. 해법으로는 참가자를 가까운 SFU에 붙이고 SFU끼리 잇는 Cascading(#48), 리전 재배치, 글로벌 라우팅 등이 있습니다. Anycast는 접속 지점을 가까운 네트워크 위치로 유도할 수 있지만, 그 자체로 방 상태와 미디어 처리를 특정 서버에서 분리해주지는 않습니다.

② Egress 비용 — SFU 경제학의 본체

SFU는 1줄기를 받아 (보는 사람 수)줄기로 내보냅니다. 즉 트래픽이 서버에서 증폭됩니다. 10명 회의, 각자 1.5Mbps, 1시간이면:

• 수신(ingress): 10 × 1.5Mbps ≈ 6.75GB/시간
• 송신(egress): 10명이 각자 나머지 9명 영상 수신 ≈ 60GB/시간 — 클라우드가 과금하는 것이 바로 이것

이 계산은 모든 사용자가 나머지 9개 영상을 같은 비트레이트로 한 시간 구독한다고 가정한 상한 예시입니다. 실제 egress는 구독 정책, simulcast/SVC 레이어, 오디오, 프로토콜 오버헤드와 재전송에 따라 달라집니다. 클라우드의 ingress·egress 과금도 사업자와 리전에 따라 확인해야 합니다.

③ 그 외 반복되는 고민들

프리세일즈 답변: 직접 구축과 CPaaS를 비교할 때는 서버 설치 시간보다 글로벌 배치, cascading, egress, 피크 스케일링, 장애 대응과 관측 비용을 함께 계산해야 합니다. CPaaS는 운영 책임 일부를 이전하는 대신 요금, 기능 제약과 벤더 종속이 생깁니다.

6. 1:1 전화도 SFU를 쓰나요 — "사용자가 많으면"의 진짜 의미

마지막으로, 논리적으로 헷갈리기 쉬운 질문입니다. "SFU는 다인원용이라면서요. 그럼 1:1 통화는 P2P로 하면 되는 것 아닌가요? 그런데 왜 대형 서비스들은 1:1도 서버를 거친다고 하죠?"

혼동의 원인은 "사용자가 많다"의 두 가지 의미를 섞어 쓰기 때문입니다.

• 방 안의 참가자 수가 많으면 풀 메시의 연결과 송신 대상이 늘어 SFU 같은 서버 토폴로지를 검토합니다.
• 서비스 전체의 동시 통화 수가 많으면 1:1이라도 운영 일관성, 관측성, 기능과 비용을 따로 판단해야 합니다.

1:1인데도 서버를 거치는 이유를 하나씩 쌓아보면:

첫째, 직접 경로가 항상 만들어지지는 않습니다. ICE는 host, server-reflexive, relayed 후보를 검사하고, NAT·방화벽 조건에서 직접 후보가 실패하면 TURN 릴레이를 사용할 수 있습니다. TURN 비율은 사용자 네트워크와 정책에 따라 크게 달라지므로 고정 비율을 쓰지 말고 서비스 지표로 확인해야 합니다.

둘째, 경로가 나뉘면 운영 모델도 나뉩니다. 직접 P2P와 TURN/SFU 경로는 지연·비용·관측 지점이 다릅니다. 한 경로로 통일하면 운영은 단순해질 수 있지만 서버 대역폭 비용이 늘므로 트레이드오프를 계산해야 합니다.

셋째, 서버 경유가 필요한 기능들이 있습니다.

• 서버 측 녹화/분석: recorder가 참가자로 합류하거나 서버 미디어 경로를 사용해야 합니다. 클라이언트 로컬 녹화는 별도 선택지입니다.
• 1:1 → 그룹 확장: P2P에서 SFU로 전환하려면 새 연결과 미디어 경로를 준비해야 합니다. 끊김 여부와 전환 시간은 구현에 달려 있습니다.
• 프라이버시: 직접 ICE 후보 쌍은 상대 피어에 네트워크 주소 정보를 노출할 수 있습니다. TURN-only 정책은 이를 줄이는 대신 릴레이 비용을 늘립니다.
• 경로 품질 제어: 가까운 SFU나 관리형 백본이 유리할 때도 있지만, 우회 홉이 늘어 불리할 때도 있으므로 지역별로 측정해야 합니다.

넷째, 직접 P2P는 미디어 서버 대역폭을 줄일 수 있습니다. 대신 TURN 폴백, 경로별 품질 관측, 기능 차이를 운영해야 합니다. 특정 서비스의 내부 토폴로지는 공개 문서 없이는 추정하지 않는 편이 안전합니다.

정리하면:

프리세일즈 답변: 1:1 과금은 제품별로 TURN/SFU 대역폭, 글로벌 라우팅, 녹화·분석 기능과 운영 서비스가 반영될 수 있습니다. 가격표와 실제 미디어 경로를 확인한 뒤 설명해야 합니다.

7. 한 장 요약 — 고객 질문 → 답변 치트시트

설명할 때는 전송과 토폴로지를 분리하면 됩니다. WebRTC는 연결 가능한 보안 미디어 경로를 선택하고 손실을 실시간 요구에 맞게 처리합니다. SFU는 그 위에서 어떤 RTP 스트림과 레이어를 누구에게 전달할지 결정합니다.

공식 참고 자료

• W3C WebRTC 1.0
• MDN WebRTC API
• RFC 8835 — WebRTC Transports
• RFC 8445 — ICE
• RFC 8656 — TURN
• RFC 7667 — RTP Topologies
• W3C WebRTC Encoded Transform
• RFC 9114 — HTTP/3
• W3C WebTransport

함께 보면 좋은 글

• #51 WebRTC 아키텍처 가이드 — Mesh, SFU, MCU, Hybrid를 어떻게 고를까
• #48 SFU는 어떻게 100명·1000명을 감당하나 — 단일 노드 한계와 Cascading
• #43 Agora 자체 코덱과 Web SDK의 정체 — WebRTC 표준, SD-RTN 전용망, FEC의 분업
• #46 모바일 영상 파이프라인의 발열 — 메모리 복사, GPU Texture, Zero-Copy, 하드웨어 코덱