개념

필수 단어

1. WebRTC 란?

WebRTC(Web Real-Time Communication)는 브라우저나 앱이 직접 P2P로 오디오·비디오·데이터를 송수신하는 표준 기술을 뜻한다.
즉, WebRTC는 통신 프로토콜과 API의 집합이야. ()
WebRTC 자체에는 특정한 “라우팅 방식”(MCU, SFU 등)을 강제하지 않는다.
👉 WebRTC만으로도 A ↔ B 단순 P2P 통신이 가능하고, 여러명이면 메시에 가까운 연결도 가능.

WebRTC는 "클라이언트 ↔ 서버(또는 클라이언트 ↔ 클라이언트) 사이 미디어 전송에 항상 쓰이는 표준 프로토콜이다.

✅ ICE (Interactive Connectivity Establishment)
WebRTC의 “네트워크 후보”를 찾고 연결을 시도하는 프레임워크.
예: 로컬 IP, 공인 IP, TURN 릴레이 IP 등 여러 경로를 테스트해서 최적의 경로를 찾음.
즉, ICE = 연결 성립 프로세스의 총칭.

✅ STUN (Session Traversal Utilities for NAT)
NAT(Network Address Translation)를 통과하기 위한 서버.
브라우저가 “내 공인 IP를 알 수 있게” 도와줌.
아주 가볍고 빠름. P2P 통신 시 주로 사용.

✅ TURN (Traversal Using Relays around NAT)
STUN으로 연결이 안 될 때 중계 서버를 통해 릴레이.
예: 방화벽이 너무 빡세서 직접 연결 불가할 때.
TURN 서버는 대역폭도 많이 쓰고 비용도 큼.

ICE = 후보를 모아 연결 시도
└─ STUN = 내 공인 IP 알려주기
└─ TURN = 연결 안 되면 릴레이 중계

2. SFU (Selective Forwarding Unit) 란?

SFU는 다자간 화상회의의 미디어 라우팅 아키텍처를 말하는 거야.

보통 다자간 통화에서는 모든 참가자가 모든 다른 참가자에게 각각 스트림을 보내면 부담이 커지는데,
SFU는 참가자가 서버에 하나만 업로드하고, 서버가 각 수신자에게 스트림을 “포워딩”해 줘.

SFU는 WebRTC 위에 구축될 수 있어.
즉, 미디어 전송은 WebRTC를 쓰고, 전송 방식(라우팅 아키텍처)으로 SFU를 적용하는 거지.

3. MCU (Multipoint Control Unit) 란?

다자간 화상회의의 미디어 서버 방식이야.
그런데 SFU랑 결정적으로 다른 점이 있어:

🏷️	MCU	SFU
역할	미디어 믹싱 (합성)	미디어 선택적 전달
서버 동작	서버가 모든 참가자의 스트림을 수신해 하나로 믹싱(합성) 후 각 클라이언트에 한 스트림만 전송	서버가 참가자별로 필요한 스트림만 선택해서 전달 (믹싱 안 함)
클라이언트 부하	클라이언트 부하 적음 (서버가 믹싱해서 한 스트림만 수신)	클라이언트가 여러 스트림 수신 (부하 더 큼)
서버 부하	서버 부하 큼 (연산량 많음)	서버 부하 상대적으로 적음
지연(latency)	믹싱 때문에 지연 더 큼	지연 더 낮음

✅ MCU 간단 예시

1. 4명이 회의에 접속
2. 각자 서버에 스트림을 업로드
3. 서버가 모든 참가자의 비디오·오디오를 하나로 합성 (예: 화면에 4명 다 들어간 하나의 큰 비디오)
4. 서버가 합성된 하나의 비디오를 모든 참가자에게 전송
5. 클라이언트는 하나의 비디오만 디코딩하면 됨

✅ SFU 간단 예시

1. 4명이 회의에 접속
2. 각자 서버에 스트림을 업로드
3. 서버는 믹싱 없이 단순 포워딩 (예: A의 스트림은 B,C,D,E에게 개별 전달, B의 스트림도 마찬가지)
4. 클라이언트는 4개의 개별 스트림을 디코딩해서 갤러리 뷰 구성

4. Mesh 란?

Mesh(메시) 는 가장 단순한 다자간 통신 방식으로, 서버를 거치지 않고 모든 참가자가 서로 직접 P2P 연결을 맺는 모델이다.
🌟 Mesh 방식의 특징
각 참가자가 다른 모든 참가자에게 직접 스트림을 전송
예: 4명이면 각자가 3개의 스트림을 보냄

복사
편집
A ─────────▶ B
A ─────────▶ C
A ─────────▶ D
(B, C, D도 마찬가지)

별도의 서버에서 믹싱이나 포워딩을 하지 않음
순수 WebRTC P2P 이다.

장점.
구현이 가장 간단
지연(latency)이 가장 낮음 (직접 연결)
서버 비용이 거의 안 듦 (시그널링 서버만 있으면 됨)

단점.
참가자 수가 늘수록 트래픽 폭발 (연결 복잡도 O(n×(n−1)) )
CPU/대역폭 요구량이 급증
모바일/저사양 기기에서는 현실적으로 3~4명 이상 지원하기 어려움.

🧩 다시 요약
✅ WebRTC = 스트림 송수신 프로토콜/기술
✅ SFU/MCU/Mesh = 스트림을 어떻게 처리해 다자간으로 중계할지 결정하는 서버 아키텍처

대표 라이브러리 소개

우선 소개하기 앞서 현재 우리 상황에서 MCU 를 사용하면 아주 좋지 않을까? 생각할 수 있다. 나도 그랬다.
각 경로당 네트워크가 해당 현재 우리 회사 서비스 전용망이 아니기 때문에 화질이 매우 자주 깨진다. 그래서 하나의 비디오로 인코딩해서 내려보내면 좋을 것이라 생각했다.

그러나 이는 오산이었다.

1. ❌ 서버 CPU 부하가 엄청나게 큼
   참여자 수 비디오 해상도 FPS 만큼 인코딩해야 한다. (예) 10명 → 10개 스트림 믹싱 후 다시 10개로 인코딩)
   이 때문에 50~100명 정도만 넘어가도 서버 증설 비용이 기하급수적으로 증가한다.
   당연한 소리지만 이윤을 창출하는 기업에선 서버 비용도 고려해야할 매우 중요한 요소 중 하나다.

2. ❌ 지연(latency) 증가
   믹싱과 인코딩 시간이 걸린다. SFU의 실시간성에 비해 딜레이 체감된다.

3. ❌ 대규모 회의에 부적합
   결론적으로 CPU, 메모리 비용 때문에 요즘은 거의 SFU로 대체되는 추세이기 때문이다.

그러므로 우리는 SFU 라이브러리 위주로 살펴볼 것이다.
참고로 그나마 명맥을 유지중이던 Kurento가 그나마 오픈소스 중 유명했지만, 요즘은 Maintain 활동이 많이 줄어들었다.

그리고 아래 전반적인 표를 보고 가장 눈길을 끄는 Jitsi 와 Mediasoup 에 대해 알아보자.

라이브러리/API	오픈소스	커스터마이징	확장성	비용	주요 단점
WebRTC	O	매우 높음	중	무료	복잡한 시그널링, 대규모 한계
Jitsi	O	높음	중	무료	UI 커스터마이징 필요
Mediasoup	O	높음	중	무료	웹소켓, HTTP 시그널링 등 직접 구축 필요
Janus	O	매우	높음	중	무료
Twilio	X	보통	높음	유료	비용, 일부 기능 부족
Agora	X	중	높음	유료	비용, 커스터마이징 난이도
CometChat	X	보통	높음	유료	확장성 비용, 백엔드 한계
Sendbird Calls	X	보통	높음	유료	비용, 일부 고급 기능 미지원
Zoom SDK	X	낮음	높음	유료	보안 이슈, 무료 플랜 제한

1. Mediasoup

Node.js 기반의 서버 사이드 WebRTC SFU(Selective Forwarding Unit) 라이브러리로, 대규모 멀티파티 화상회의 및 실시간 스트리밍에 최적화되어 있음.

🧩 주요 구성

1. 아키텍처: Node.js 프로세스와 복수의 C++ 워커(worker)가 CPU 코어별로 분산 실행되어, 하나의 서버에서 수백~수천 명의 미디어 스트림을 효율적으로 처리 가능.
2. 확장성: router.pipeToRouter() 기능을 통해 여러 서버/워커 간에 트래픽을 분산시켜, 단일 서버 한계를 넘는 대규모 회의도 지원.
3. 코덱 지원: VP8, VP9, H.264, Opus 등 다양한 미디어 코덱을 유연하게 지원하며, 송출자별로 코덱을 다르게 설정하는 등 세밀한 제어 가능.
4. 커스터마이징: 신호 처리부터 미디어 라우팅, 외부 미디어 연동(FFmpeg, GStreamer 등)까지 거의 모든 부분을 개발자가 직접 설계·구현할 수 있음.
5. UI 미포함: Mediasoup 자체에는 사용자 인터페이스가 없으며, 모든 클라이언트·시그널링·UI를 직접 개발해야 함.

💪 장점

1. 최고 수준의 확장성: 수백~수천 명의 동시 접속자 처리에 강점. SFU 구조라 서버 부하 분산 및 네트워크 효율이 뛰어남.
2. 유연성/모듈성: 원하는 기능만 선택적으로 구현 가능. 다양한 비즈니스 요구에 맞는 맞춤형 플랫폼 구축에 적합.
3. 고급 미디어 처리: 시뮬캐스트, SVC, 다양한 코덱, 외부 미디어 연동 등 고급 기능 지원.
4. 낮은 레이턴시미디어 디코딩/인코딩이 없으므로 빠름.

❌ 단점

1. 높은 개발 난이도: 신호 처리, 미디어 라우팅, 클라이언트·UI 개발까지 모두 직접 구현해야 하므로, WebRTC 및 미디어 서버에 대한 깊은 이해 필요.
2. 커뮤니티/문서: Jitsi에 비해 커뮤니티와 문서가 적은 편.
3. 운영 난이도: 대규모 환경에서는 워커/라우터/로드밸런싱 등 인프라 설계가 복잡함.

🏗️ 대규모 회의 고려사항
300명이라면 "모두가 모두의 영상"은 불가능 (브라우저가 300개의 비디오 트랙을 처리 못 함)
적절한 "레이아웃 정책" 설계 필요
발표자 1~2명: 영상/음성 스트림
청취자: 오디오만 구독
상호간 채팅 + 제한적 마이크 권한
필요 시 여러 Worker를 띄워 부하 분산

2. Jitsi

완성형 오픈소스 화상회의 솔루션(Jitsi Meet)으로, 서버 및 클라이언트(웹/모바일)까지 모두 제공.

핵심 구성 요소:
1. Jitsi Videobridge: SFU 서버
2. Jicofo: 회의 관리 (시그널링 중심)
3. Prosody: XMPP 서버(시그널링)
4. Jitsi Meet: 웹 UI

🧩 주요 특징

1. 아키텍처: Jitsi Meet(프론트엔드), Jicofo(회의 관리), JVB(Jitsi Video Bridge, SFU), Prosody(XMPP 시그널링) 등으로 구성된 모듈형 구조.
2. 확장성: JVB(Videobridge)를 여러 대 추가하고, Octo(분산 처리) 및 로드밸런싱을 적용하면 200~250명 이상의 대규모 회의도 지원.
3. 기본 기능: 화면 공유, 채팅, 녹화, 브라우저 기반 UI, 모바일 앱 등 대부분의 화상회의 기능이 기본 제공.
4. 커스터마이징: 로고, UI, 기능 추가 등 커스터마이징 가능하지만, Mediasoup만큼의 자유도는 아님.

💪 장점

1. 빠른 구축: 별도 개발 없이 바로 사용 가능. 완성형 UI와 서버 제공.
2. 확장성: JVB 추가 및 서버 최적화, Octo 활용 시 200~250명(기본), 최적화 시 수백~수천 명까지 확장 가능.
3. 커뮤니티/문서: 대규모 커뮤니티와 풍부한 문서, 다양한 사례.
4. 보안: E2EE(1:1), 서버 자체 운영, 다양한 보안 옵션 지원.

❌ 단점

1. 커스터마이징 한계: UI/기능 커스터마이징은 가능하지만, 완전히 새로운 아키텍처나 신호 처리 로직 구현은 제한적.
2. 리소스 사용량: 대규모 회의 시 클라이언트(브라우저)와 서버 모두 높은 리소스 요구. 특히, 모든 참가자가 비디오를 켜면 브라우저 성능이 한계에 도달할 수 있음.
3. 기본 구조: Mediasoup에 비해 미디어 처리의 세밀한 제어(코덱, 라우팅 등)는 어려움.
4. XMPP 의존: 시그널링이 Prosody XMPP 기반이라 러닝커브 있음.

🏗️ 대규모 회의 고려사항

• Simulcast 필수
  발표자 비디오 고화질 + 청취자 저화질
• Octo 모드
  Videobridge 여러 대 연결하여 부하 분산
• Client 제한
  UI에서 "타일뷰"를 제한하여 표시 수 축소
• 대규모 방에서는 청취자 전용 모드 권장

항목	Mediasoup	Jitsi Meet
확장성	매우 높음 (수백~수천명, 워커/라우터 분산)	높음 (JVB/Octo로 200~250명, 확장 가능)
아키텍처	SFU, Node.js+C++, 완전 모듈/커스텀 (Node.js + C++ SFU)	완성형 솔루션, 모듈 구조 (XMPP + Videobridge + Web UI)
시그널링	직접 구현	내장 (Prosody)
대규모 확장성	매우 유연함 (Worker 분산)	Octo로 다중 브리지 가능
커스터마이징	매우 높음 (모든 기능 직접 구현)	중간 (UI/기능 위주)
개발 난이도	높음 (WebRTC/미디어 서버 지식 필요)	낮음 (즉시 사용 가능)
UI 제공	없음 (직접 개발)	있음 (웹/모바일)
커뮤니티	중간	매우 활발
주요 용도	맞춤형 대규모 플랫폼, 고급 미디어 처리	일반 화상회의 서비스, 빠른 구축