SFU는 어떻게 100명·1000명을 감당하나 — 단일 노드 한계와 Cascading

"화상회의는 100명까지 되던데, 라이브 방송은 어떻게 10만 명이 보나요? 같은 WebRTC 아닌가요?". RTC 아키텍처를 검토하는 자리에서 자주 나오는 질문입니다. 답부터 말하면 — 둘은 같은 WebRTC라도 토폴로지가 다르고, 100명과 10만 명은 애초에 다른 메커니즘으로 푼다는 것입니다.

이 글은 그 경계를 처음부터 끝까지 정리합니다. P2P 풀메시가 왜 몇 명에서 무너지는지, SFU가 왜 저지연인지, 단일 SFU 노드가 몇 명에서 한계에 닿는지, 그리고 그 한계를 넘는 Cascading과 — 더 큰 규모에서는 아예 라이브 스트리밍(HLS/CDN)으로 갈아타는 분기점까지.

0. 핵심 명제 — "실시간 양방향"과 "대규모 단방향"은 다른 문제다

N명이 서로의 영상을 실시간으로 주고받는 문제(컨퍼런스)와, 1명의 영상을 N명이 보는 문제(방송)는 같은 도구로 풀지 않는다. 양방향 실시간은 규모에 따라 P2P → SFU 단일 노드 → SFU Cascading으로 전환하고, 단방향 대규모 시청은 아예 HLS/CDN으로 넘어간다. SFU의 저지연(0.2~0.5s)은 "디코딩·재인코딩 없이 패킷만 포워딩"하기 때문이고, 단일 노드의 한계는 아웃바운드 대역폭 + CPU/메모리/패킷처리가 복합적으로 작용한 결과다. 대역폭 하나가 단일 원인은 아니다.

흔한 오해와 정정:

1. 출발점 — P2P(Mesh)는 왜 몇 명에서 무너지나

가장 단순한 구조는 서버 없이 참가자끼리 직접 연결하는 P2P 풀메시(Full Mesh) 입니다. 2명이라면 완벽합니다. 문제는 인원이 늘 때입니다.

풀메시 — 모두가 모두와 직접 연결

   A ─────── B
   │ ╲     ╱ │
   │   ╲ ╱   │
   │   ╱ ╲   │
   │ ╱     ╲ │
   D ─────── C

연결 수 = N×(N-1)/2
각 참가자의 업로드 = (N-1)개 스트림 (같은 영상을 N-1번 복제 전송)
각 참가자의 다운로드 = (N-1)개 스트림

여기서 핵심은 각자가 자기 영상을 (N-1)번 복제해서 올린다는 점입니다. 서버가 없으니 분배를 대신해 줄 주체가 없습니다.

인원별 업로드 부하 산수

가정: 한 스트림당 720p ≈ 1.5 Mbps 업링크.

다운로드도 동일하게 (N-1)개가 들어오지만, 가정용 회선은 보통 다운로드가 업로드보다 훨씬 큽니다. 그래서 풀메시의 진짜 병목은 업링크입니다. 각 클라이언트의 CPU도 (N-1)개를 동시에 인코딩(또는 시뮬캐스트)하느라 같이 무너집니다.

풀메시의 한계 = 보통 4~6명. 그 이상은 클라이언트 업링크와 인코딩 CPU가 먼저 죽습니다. 그래서 서버(SFU)가 필요합니다.

P2P가 NAT/방화벽 때문에 연결 자체가 안 되는 문제는 별개 주제입니다 (#8 참고). 여기서는 "연결이 되더라도 부하 때문에 안 된다"는 이야기입니다.

2. SFU — "복제 분배"를 서버에 떠넘긴다

SFU(Selective Forwarding Unit) 는 중앙에 서버를 한 대 두고, 각 참가자가 자기 영상을 서버에만 한 번 올리면, 서버가 그걸 다른 참가자들에게 복제·분배하는 구조입니다.

SFU — 각자는 서버와만 연결

        ┌─────────┐
   A ──→│         │──→ B,C,D 에게 A 영상 분배
   B ──→│   SFU   │──→ A,C,D 에게 B 영상 분배
   C ──→│ (서버)  │──→ A,B,D 에게 C 영상 분배
   D ──→│         │──→ A,B,C 에게 D 영상 분배
        └─────────┘

각 참가자의 업로드 = 1개 스트림 (서버로 1번만)
각 참가자의 다운로드 = (N-1)개 스트림 (서버에서)
서버의 아웃바운드 = N × (N-1) 스트림

클라이언트 부하 비교 — 업로드가 1개로 고정된다

핵심은 "부하의 이동"입니다. 풀메시에서 클라이언트가 짊어지던 복제 부담을 SFU가 대신 집니다. 클라이언트 업로드와 인코딩이 N과 무관하게 1로 고정되므로, 클라이언트 입장에서 100명 회의든 10명 회의든 보내는 부담은 같습니다.

정정 (다운로드는 여전히 N에 비례): SFU가 풀메시 문제를 다 해결하진 않습니다. 각 참가자가 받는 다운스트림은 여전히 (N-1)개입니다. 100명이면 99개 스트림을 받아야 하므로, 실무에서는 화면에 보이는 일부만 큰 해상도로 받고 나머지는 작은 해상도(시뮬캐스트/SVC)로 받거나 끄는 식으로 다운링크를 관리합니다.

3. SFU vs MCU — 저지연의 근거는 "포워딩만 한다"

여기가 SFU 저지연의 핵심입니다. SFU는 수신한 RTP 패킷을 디코딩·재인코딩 없이 그대로 포워딩합니다. 반면 MCU(Multipoint Control Unit) 는 여러 스트림을 디코딩→합성→재인코딩해서 한 개의 통합 스트림으로 내보냅니다.

🟢 SFU — 포워딩만 (Selective Forwarding)
   [A의 패킷] → SFU → [그대로] → B,C,D
   - RTP 패킷 수준에서 동작
   - 디코딩 X, 합성 X, 재인코딩 X (재암호화는 함)
   - CPU 부하 ∝ 패킷 레이트 (비트레이트와 거의 무관)
   - 인코딩 지연 0, 세대 손실(generational loss) 없음
   - 결과: 저지연 (대략 0.2~0.5s), 원본 화질 유지

🔴 MCU — 합성 (Mixing / Transcoding)
   [A,B,C,D 패킷] → MCU → 디코딩 → 한 화면에 합성 → 재인코딩 → 통합 스트림
   - CPU 집약적 (참가자마다 디코딩+인코딩)
   - 트랜스코딩 지연 추가
   - 재인코딩으로 화질 세대 손실 발생
   - 장점: 수신측은 스트림 1개만 받으면 됨 (저사양 단말/믹스 녹화에 유리)

비교 매트릭스

비유하면, SFU는 우편물을 뜯어보지 않고 그대로 라벨만 보고 분류·전달하는 우체국이고, MCU는 여러 편지를 다 읽고 한 장에 요약해서 다시 쓰는 비서입니다. 우체국은 빠르고 싸지만 받는 사람이 여러 통을 받고, 비서는 한 통으로 정리해주지만 느리고 비쌉니다. 기술적 실체로 환원하면 — SFU는 RTP 페이로드를 건드리지 않아 디코더/인코더를 거치지 않으니 지연과 CPU가 작고, MCU는 디코드→믹스→인코드 파이프라인을 타므로 그 반대입니다.

4. 코덱 협상 — SFU가 포워딩만 하려면 양끝 코덱이 맞아야 한다

SFU가 "디코딩 없이 포워딩만" 하려면 전제가 있습니다 — 송신자가 인코딩한 코덱을 수신자가 디코딩할 수 있어야 합니다. SFU는 트랜스코딩을 안 하므로 코덱을 바꿔주지 못합니다. 이 합의가 SDP(Session Description Protocol) 협상입니다.

       Offer (내가 보낼/받을 수 있는 코덱 목록)
   A ───────────────────────────────────────→ SFU
       Answer (교집합으로 확정된 코덱)
   A ←───────────────────────────────────────── SFU

SDP 예 (요약):
m=video 9 UDP/TLS/RTP/SAVPF 96 97 98
a=rtpmap:96 VP8/90000
a=rtpmap:97 H264/90000
a=rtpmap:98 AV1/90000
   → 양끝이 공통으로 지원하는 코덱(payload type)만 살아남음

핵심 제약

그래서 SFU 환경에서는 모든 참가자가 공통으로 지원하는 코덱으로 수렴시키는 게 중요합니다. 한 명이라도 특정 코덱만 디코딩 가능하면, 그 코덱으로 인코딩하도록 강제하거나(또는 시뮬캐스트로 여러 코덱 동시 송출), 예외적으로 그 사용자만 트랜스코딩 게이트웨이를 거치게 합니다. 코덱 협상 자체(VP8/H.264/AV1, 프로파일 등)에 대한 깊은 내용은 #28을 참고하세요.

5. 단일 SFU 노드의 한계 — 아웃바운드 산수

SFU 한 대가 감당할 수 있는 인원에는 명확한 천장이 있습니다. 그 천장의 1차 요인이 아웃바운드 대역폭입니다.

컨퍼런스(모두가 모두를 봄): 아웃바운드 = N × (N-1)

모든 참가자가 서로를 보는 회의라면, 서버가 내보내는 총 스트림 수는 N × (N-1)로 제곱에 가깝게 증가합니다.

서버 아웃바운드 스트림 = N × (N-1)
스트림당 1.5 Mbps 가정

100명이 전원 카메라를 켜고 서로를 보는 시나리오는 단일 노드 기준 이미 15 Gbps에 육박합니다. 그래서 실무 컨퍼런스는 "전원이 전원을 풀해상도로 본다"를 절대 허용하지 않고, 활성 발화자 몇 명만 큰 해상도 + 나머지는 썸네일/오디오만으로 다운링크를 줄입니다.

방송형(1명 → N명): 아웃바운드 = N

반대로 1명이 송출하고 N명이 보는 구조라면 아웃바운드는 N에 선형 비례합니다.

(아웃바운드 산수는 선형이며, 1,000명 이상은 단일 노드 한계를 넘어 Cascading 영역입니다.)

단일 노드의 현실적 천장

정정 (대역폭 단일 원인 아님): 흔히 "단일 SFU 한계는 대역폭 때문"이라고 단정하지만, 부분적으로만 맞습니다. 단일 SFU는 일반적으로 동시 500~1000명 수준을 안전하게 처리하며 구현에 따라 그 이상도 가능합니다. 천장은 아웃바운드 대역폭뿐 아니라 CPU(패킷 처리·암호화), 메모리, 네트워크 I/O, 패킷 레이트 처리 능력이 복합적으로 작용한 결과입니다. 대략적인 운영 경험치로 약 500명당 1Gbps 정도가 회자되지만, 이는 코덱·해상도·시뮬캐스트 구성에 따라 크게 달라집니다. [NEEDS VERIFICATION: 정확한 수치는 SFU 구현체(LiveKit/mediasoup/Janus 등)와 하드웨어, 트래픽 패턴에 따라 다르며 벤더 벤치마크로 확인 필요]

이 천장에 닿으면 선택지는 두 가지입니다 — (1) 더 큰 서버로 수직 확장(한계 명확), (2) 여러 SFU를 묶는 Cascading으로 수평 확장.

6. Cascading — SFU를 묶어 수만 명으로

Cascading(캐스케이딩) 은 지역별로 여러 SFU를 배치하고, 서버 간 고대역폭·저지연 링크로 필요한 트래픽만 릴레이해 단일 노드 한계를 넘는 표준 아키텍처입니다.

단일 SFU (한계 ~500~1000명)

           ┌──────┐
   많은 ──→│ SFU  │──→ 많은
   참가자   └──────┘    참가자
            (한 대에 다 몰림 → 천장)


Cascading (지역 SFU + 서버 간 릴레이)

  [서울 참가자들]        [도쿄 참가자들]        [LA 참가자들]
       │                     │                    │
       ↓ (가까운 엣지)        ↓                    ↓
  ┌──────────┐  inter-SFU ┌──────────┐ inter-SFU ┌──────────┐
  │ SFU 서울 │←──릴레이──→ │ SFU 도쿄 │←──릴레이──→│ SFU LA   │
  └──────────┘  (전용링크) └──────────┘ (전용링크) └──────────┘
       │                     │                    │
   각 참가자는 "가장 가까운 엣지"에만 연결
   타 리전 참가자 영상은 SFU끼리 필요한 것만 1번씩 릴레이

Cascading의 핵심 이득

예: A(서울) 영상을 도쿄의 100명이 봐야 한다

❌ 단일 SFU(서울)에 도쿄 100명이 직접 붙으면:
   - 서울 SFU가 도쿄로 100개 스트림을 각각 송출 (장거리 × 100)
   - 서울→도쿄 국제 구간에 같은 영상이 100번 흐름

🟢 Cascading:
   - 서울 SFU → 도쿄 SFU 로 A 영상을 1번만 릴레이
   - 도쿄 SFU가 도쿄 내부 100명에게 분배
   - 장거리 국제 구간 트래픽 = 100분의 1

즉 Cascading은 장거리 구간의 중복 전송을 제거하고, 참가자는 항상 가까운 엣지에 붙어 last mile 지연을 최소화합니다. 이 구조로 수만 명 이상(방송형이면 수십만~수백만 시청자) 까지 확장합니다.

추가 지연은 얼마나?

서버 간 릴레이가 한 홉 더 끼므로 지연이 늘어납니다. 다만 SFU끼리는 고대역폭·저지연 전용 링크(또는 백본) 로 연결되므로 추가 지연은 수십 ms 수준입니다. 양방향 컨퍼런스 체감에는 대체로 무시 가능한 범위입니다.

Cascading의 도전 과제

Agora의 SD-RTN(250+ 엣지 노드 + 실시간 최적 경로 백본)은 이 Cascading 사상을 글로벌 전용망 레벨로 구현한 사례로 볼 수 있습니다 (#43 참고). 참가자는 가까운 엣지에 붙고, 엣지 간 백본은 BGP가 아니라 Agora 소프트웨어가 실시간 측정값으로 경로를 고릅니다.

7. 그런데 수십만 명이면? — SFU가 아니라 HLS/CDN

Cascading으로 수만 명까지는 늘립니다. 하지만 단방향 라이브 방송에서 수십만~수백만 시청자가 목표라면, 구조 자체를 WebRTC SFU에서 HLS/CDN으로 바꾸는 게 정석입니다. 양방향 실시간이 필요 없는데 굳이 RTC의 비용·복잡도를 떠안을 이유가 없기 때문입니다.

구조의 근본 차이

✅ WebRTC SFU/Cascading — 상태 기반(stateful) 연결
   - 시청자마다 개별 RTC 세션(연결·암호화·혼잡제어 상태 유지)
   - 저지연(0.2~0.5s), 양방향, 인터랙티브
   - 서버가 연결 수만큼 상태를 가짐 → 비싸고 확장 한계 명확

✅ HLS/CDN — 무상태(stateless) HTTP 파일 배포
   - 영상을 작은 세그먼트 파일로 쪼개 m3u8 플레이리스트로 나열
   - 시청자는 그냥 HTTP로 파일을 주기적으로 다운로드 (CDN 캐시 활용)
   - 무상태라 CDN 엣지가 무한 복제 → 수백만 명도 비용 효율적
   - 대가: 지연이 큼

HLS 라이브의 동작 (RFC 8216)

인코더 → 세그먼트(예: 6초짜리 .ts/.m4s) 계속 생성
       → 미디어 플레이리스트(m3u8)에 #EXTINF로 새 세그먼트 append
       → #EXT-X-MEDIA-SEQUENCE 번호 단조 증가
플레이어 → 주기적으로 m3u8 재요청 → 새 세그먼트 감지 → HTTP로 다운로드

정정 (HLS 지연 = 단순 곱셈이 아님): "HLS 지연 610초"는 자주 인용되지만 정확하지 않습니다. 610초는 세그먼트 길이이지 총 지연이 아닙니다. 실제 glass-to-glass 총 지연은 세그먼트 인코딩 시간 + 플레이어 버퍼(보통 약 3 세그먼트 선다운로드) + 네트워크 지연의 합이며, 전통적 HLS는 흔히 약 18~30초(약 20초 전후) 에 이릅니다. Apple은 기본 세그먼트를 10초에서 6초로 줄였고, LL-HLS(저지연 HLS) 는 부분 세그먼트·청킹으로 약 2~5초까지 낮춥니다. 프로토콜별 의사결정은 #40을 참고하세요.

라이브 트랜스코딩 vs VOD 트랜스코딩 (AWS 예)

대규모 라이브에서는 보통 여러 화질(ABR)을 동시에 만들어 CDN으로 내보냅니다. 이때 쓰는 서비스가 "라이브용"인지 "파일용"인지 구분이 필요합니다.

정정 (ABR "단일 인코더 동시 인코딩"은 구현 의존): "하나의 인코더 인스턴스가 1080p/720p/480p를 동시 병렬 인코딩한다"는 표현은 부분적으로만 맞습니다. 정확히는 단일 소스로부터 여러 해상도 렌디션을 병렬로 생성하는 것을 지원하는 것이며, 실제로 단일 인스턴스가 모든 렌디션을 동시에 처리하는지는 구현·벤더·리소스에 따라 다릅니다. 일반적으로 각 해상도는 분리된 트랜스코딩 작업으로 처리되고, VOD는 배치, 라이브는 병렬 처리가 가능하되 아키텍처 세부는 벤더별로 상이합니다. ABR 래더·키프레임 동기화 산수는 #38을 참고하세요.

8. 규모·지연으로 보는 토폴로지 의사결정

┌────────────────────────────────────────────────────────────┐
│ Q1. 양방향 실시간 인터랙션(대화)이 필요한가?               │
│   NO (단방향 시청) → Q4 (HLS/CDN 검토)                     │
│   YES → Q2                                                  │
├────────────────────────────────────────────────────────────┤
│ Q2. 동시 참가자가 몇 명인가?                                │
│   ~2명, 좋은 네트워크 → P2P 직결                            │
│   ~4~6명 이하        → P2P 풀메시도 가능 (업링크 주의)     │
│   수십~수백 명       → SFU 단일 노드                       │
│   수천~수만 명       → SFU Cascading                       │
├────────────────────────────────────────────────────────────┤
│ Q3. 글로벌 분산 사용자인가?                                 │
│   YES → 지역 엣지 SFU + Cascading(또는 SD-RTN류 전용망)    │
│   NO  → 단일 리전 SFU로 충분                               │
├────────────────────────────────────────────────────────────┤
│ Q4. 수십만~수백만 시청자 + 지연 수~수십 초 허용?           │
│   YES → HLS/CDN (무상태 파일 배포, 비용 효율)              │
│   "저지연 + 대규모" 둘 다 → LL-HLS 또는 WebRTC 대규모 설계 │
└────────────────────────────────────────────────────────────┘

규모대별 요약 카드

트레이드오프 한 줄: 지연을 낮출수록(P2P→SFU→Cascading) 인터랙티브하지만 서버가 상태를 들고 있어 비싸고 확장이 어렵고, 규모를 키울수록(→HLS/CDN) 싸고 무한 확장되지만 지연이 커진다. "저지연 + 대규모"를 동시에 원하면 비용·복잡도 모두 가장 높은 영역(대규모 WebRTC 또는 LL-HLS)으로 들어간다.

9. 한 장 요약 — 암기 카드

P2P 풀메시 = 클라이언트가 복제 분배 (소수 한정)
SFU        = 서버가 포워딩 분배   (수백, 저지연)
SFU 캐스케이딩 = 엣지 SFU + 릴레이 (수만, 글로벌)
HLS/CDN    = 무상태 파일 배포      (수십만+, 고지연)

10. 한 줄 결론

"100명·1000명을 어떻게 감당하나"의 답은 단일 기술이 아니라 규모대별 토폴로지 전환이다. 소수는 P2P, 수십수백은 SFU 단일 노드(디코딩 없이 포워딩만 해서 0.20.5s 저지연), 수천수만은 지역 엣지 SFU를 서버 간 릴레이로 묶는 Cascading(추가 지연 수십 ms), 그리고 수십만 이상 단방향 시청은 아예 무상태 HLS/CDN으로 넘어간다. 단일 SFU의 천장(보통 5001000명)은 대역폭만이 아니라 CPU·메모리·I/O가 복합 작용한 결과이며, 저지연과 대규모는 본질적으로 트레이드오프 관계다 — 둘 다 원하면 비용과 복잡도가 가장 큰 영역으로 들어간다."

관련 글

• #43 Agora 자체 코덱 vs Web SDK, SD-RTN, FEC — SD-RTN은 Cascading을 글로벌 전용망으로 구현한 사례
• #40 라이브 스트리밍 프로토콜 선택 — HLS / LL-HLS / WebRTC — 수십만 시청자에서 HLS/CDN으로 넘어가는 분기점
• #8 왜 P2P가 막히는가? — NAT, STUN, TURN — P2P가 연결 자체에서 막히는 별개 문제
• #28 H.264 Profile·인코더 옵션·비트레이트의 현실 — SFU 포워딩의 전제인 코덱 협상 깊게 보기
• #38 ABR Ladder와 키프레임 동기화 — HLS/CDN의 다해상도 렌디션 산수

참고 자료

• RFC 8216 — HTTP Live Streaming (HLS) — m3u8 플레이리스트·EXT-X-MEDIA-SEQUENCE·#EXTINF 표준
• WebRTC SFU Cascading (getstream.io) — Cascading 아키텍처 개요
• SFU Cascading (webrtcHacks) — Cascading의 동작과 도전 과제
• Scaling WebRTC with a distributed mesh (LiveKit) — 분산 메시/캐스케이딩 확장
• An introduction to Selective Forwarding Units (Voximplant) — SFU vs MCU 기본
• WebRTC P2P vs MCU vs SFU (dev.to) — 토폴로지 비교
• LiveKit SFU internals — SFU 구현 내부
• AWS Elemental MediaLive features — 라이브 인코딩 서비스
• AWS Elemental MediaConvert — 파일 기반 VOD 트랜스코딩
• Enabling Low-Latency HLS (Apple) — LL-HLS 저지연