WebRTC 및 실시간 커뮤니케이션 기술
1. WebRTC (Web Real-Time Communication)
WebRTC는 웹 브라우저나 모바일 애플리케이션이 플러그인 없이 P2P(Peer-to-Peer) 방식으로 오디오, 비디오, 데이터를 실시간으로 주고받을 수 있도록 하는 오픈 표준 기술입니다.
이는 단순히 통신 프로토콜을 넘어, 실제 통신에 필요한 API 집합을 포함합니다.
WebRTC 자체는 특정 라우팅 방식(MCU, SFU 등)을 강제하지 않습니다.
즉, WebRTC만으로도 두 사용자(A ↔ B) 간의 단순 P2P 통신이 가능하며, 여러 사용자 간에는 메시(Mesh) 형태의 연결도 가능합니다.
WebRTC는 클라이언트와 클라이언트, 또는 클라이언트와 서버 사이에서 미디어를 전송할 때 항상 사용되는 핵심 프로토콜입니다.
💡 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만으로 직접적인 P2P 연결이 불가능할 때 중계 서버를 통해 데이터를 릴레이하는 역할을 합니다.
방화벽이 엄격하거나 복잡한 네트워크 환경에서 직접 연결이 어려울 때 유용하게 사용됩니다.
하지만 TURN 서버는 많은 대역폭을 소비하고 비용이 많이 발생할 수 있습니다.- ICE: 연결 후보 수집 및 시도
- STUN: 내 공인 IP 확인
- TURN: 연결 불가 시 릴레이 중계
- ICE: 연결 후보 수집 및 시도
2. SFU (Selective Forwarding Unit)
SFU는 다자간 화상회의를 위한 미디어 라우팅 아키텍처입니다.
다자간 통화에서 모든 참가자가 다른 모든 참가자에게 개별 스트림을 직접 보내면 네트워크 부담이 커지는데, SFU는 이 문제를 해결합니다.
SFU 방식에서는 각 참가자가 서버에 자신의 스트림을 한 번만 업로드합니다.
SFU 서버는 이 스트림을 수신한 후, 다른 수신자들에게 선택적으로 "포워딩"해 줍니다.
이때 서버는 스트림을 믹싱하거나 트랜스코딩하지 않고, 원본 스트림을 그대로 전달하는 것이 특징입니다.
SFU는 WebRTC 위에 구축되어 미디어 전송은 WebRTC를 사용하되, 전송 방식(라우팅 아키텍처)으로 SFU를 적용하는 형태입니다.
3. MCU (Multipoint Control Unit)
MCU는 다자간 화상회의를 위한 또 다른 미디어 서버 방식입니다.
SFU와 결정적으로 다른 점은 서버가 미디어를 직접 처리하고 믹싱(합성)한다는 것입니다.
| 특징 | MCU (Multipoint Control Unit) | SFU (Selective Forwarding Unit) |
|---|---|---|
| 역할 | 미디어 믹싱 (합성) | 미디어 선택적 전달 |
| 서버 동작 | 모든 참가자 스트림을 수신, 하나로 합성 후 각 클라이언트에 단일 스트림 전송 | 참가자별로 필요한 스트림만 선택적으로 전달 (믹싱 없음) |
| 클라이언트 부하 | 낮음 (서버가 믹싱하여 한 스트림만 수신, 디코딩 부담 적음) | 높음 (여러 개별 스트림 수신, 디코딩 부담 큼) |
| 서버 부하 | 높음 (연산량 많음: 믹싱 및 트랜스코딩) | 상대적으로 낮음 (단순 포워딩) |
| 지연 (Latency) | 높음 (믹싱 및 인코딩 시간 소요) | 낮음 |
💡 MCU 간단 예시
- 4명이 회의에 접속합니다.
- 각 참가자는 자신의 비디오·오디오 스트림을 MCU 서버에 업로드합니다.
- MCU 서버는 모든 참가자의 스트림을 수신하여 하나의 비디오로 합성합니다
(예: 화면에 4명의 얼굴이 모두 포함된 단일 비디오). - 서버는 합성된 단 하나의 비디오 스트림을 모든 참가자에게 전송합니다.
- 클라이언트는 단 하나의 비디오 스트림만 디코딩하면 됩니다.
4. Mesh (메시)
Mesh는 가장 단순한 다자간 통신 방식으로, 서버를 거치지 않고 모든 참가자가 서로 직접 P2P 연결을 맺는 모델입니다.
이는 순수한 WebRTC P2P 통신에 해당합니다.
🌟 Mesh 방식의 특징
- 각 참가자가 다른 모든 참가자에게 직접 스트림을 전송합니다.
- 예: 4명이 회의하면 각 참가자는 3개의 스트림을 다른 3명에게 직접 전송합니다
(총 개의 연결).
- 예: 4명이 회의하면 각 참가자는 3개의 스트림을 다른 3명에게 직접 전송합니다
- 별도의 서버에서 믹싱이나 포워딩을 하지 않습니다.
- 장점
- 구현이 가장 간단합니다.
- 지연(latency)이 가장 낮습니다 (직접 연결).
- 서버 비용이 거의 들지 않습니다 (시그널링 서버만 필요).
- 단점
- 참가자 수가 늘수록 트래픽과 연결 복잡도가 기하급수적으로 증가합니다 (O(N×(N−1))).
- 각 클라이언트의 CPU 및 대역폭 요구량이 급증합니다.
- 모바일이나 저사양 기기에서는 현실적으로 3~4명 이상 지원하기 어렵습니다.
🧩 다시 요약
- WebRTC: 오디오, 비디오, 데이터를 실시간으로 주고받는 프로토콜/기술 스택입니다.
- SFU / MCU / Mesh: WebRTC 스트림을 다자간으로 어떻게 처리하고 중계할지 결정하는 서버 아키텍처입니다.
대표 라이브러리 소개
현재 서비스 환경에서 MCU를 고려할 수 있지만, 다음과 같은 이유로 SFU 방식이 대규모 화상 회의에 더 적합합니다.
❌ MCU의 한계점
-
서버 CPU 부하가 엄청나게 큼: 참가자 수, 비디오 해상도, FPS에 비례하여 인코딩 작업을 수행해야 합니다
(예: 10명 참가 시 10개 스트림을 믹싱 후 다시 10개로 인코딩). 이로 인해 50~100명만 넘어가도 서버 증설 비용이 기하급수적으로 증가하여 기업 입장에서 비용 효율성이 떨어집니다. -
지연(Latency) 증가: 믹싱과 인코딩 과정에 시간이 소요되므로, SFU의 실시간성에 비해 딜레이를 체감할 수 있습니다.
-
대규모 회의에 부적합: 위와 같은 CPU, 메모리 비용 문제 때문에 요즘에는 대부분의 대규모 화상 회의 서비스가 SFU로 대체되는 추세입니다.
그러므로 우리는 SFU 라이브러리 위주로 살펴볼 것이며, 아래 표에서 가장 눈길을 끄는 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
Mediasoup은 Node.js 기반의 서버 사이드 WebRTC SFU 라이브러리로, 대규모 멀티파티 화상회의 및 실시간 스트리밍에 최적화되어 있습니다.
🧩 주요 구성 및 특징
-
아키텍처: Node.js 프로세스와 복수의 C++ 워커(worker)가 CPU 코어별로 분산 실행되어, 하나의 서버에서 수백~수천 명의 미디어 스트림을 효율적으로 처리할 수 있습니다.
-
확장성: router.pipeToRouter() 기능을 통해 여러 서버/워커 간에 트래픽을 분산시켜, 단일 서버의 한계를 넘는 대규모 회의를 지원합니다.
-
코덱 지원: VP8, VP9, H.264, Opus 등 다양한 미디어 코덱을 유연하게 지원하며, 송출자별로 코덱을 다르게 설정하는 등 세밀한 제어가 가능합니다.
-
커스터마이징: 신호 처리부터 미디어 라우팅, 외부 미디어 연동(FFmpeg, GStreamer 등)까지 거의 모든 부분을 개발자가 직접 설계하고 구현할 수 있습니다.
-
UI 미포함: Mediasoup 자체에는 사용자 인터페이스가 포함되어 있지 않으므로, 모든 클라이언트 시그널링 및 UI를 직접 개발해야 합니다.
💪 장점
- 최고 수준의 확장성: 수백~수천 명의 동시 접속자 처리에 강점이 있습니다.
SFU 구조이므로 서버 부하 분산 및 네트워크 효율이 뛰어납니다. - 유연성/모듈성: 원하는 기능만 선택적으로 구현 가능하여 다양한 비즈니스 요구에 맞는 맞춤형 플랫폼 구축에 적합합니다.
- 고급 미디어 처리: 시뮬캐스트(Simulcast), SVC(Scalable Video Coding), 다양한 코덱, 외부 미디어 연동 등 고급 기능을 지원합니다.
- 낮은 레이턴시: 미디어 디코딩/인코딩이 없어 빠릅니다.
❌ 단점
- 높은 개발 난이도: 신호 처리, 미디어 라우팅, 클라이언트 및 UI 개발까지 모두 직접 구현해야 하므로, WebRTC 및 미디어 서버에 대한 깊은 이해가 필요합니다.
- 커뮤니티/문서: Jitsi에 비해 커뮤니티와 문서 자료가 적은 편입니다.
- 운영 난이도: 대규모 환경에서는 워커/라우터/로드밸런싱 등 인프라 설계가 복잡합니다.
🏗️ 대규모 회의 고려사항 (300명 이상)
- "모두가 모두의 영상"은 현실적으로 불가능합니다 (브라우저가 300개의 비디오 트랙을 처리하기 어렵습니다).
- 적절한 "레이아웃 정책" 설계가 필수적입니다 (예: 발표자 1~2명은 영상/음성 스트림, 청취자는 오디오만 구독).
- 상호간 채팅 기능과 제한적인 마이크 권한 부여를 고려해야 합니다.
- 필요시 여러 Worker를 띄워 부하를 분산해야 합니다.
2.Jitsi
Jitsi는 완성형 오픈소스 화상회의 솔루션 (Jitsi Meet)으로, 서버 및 클라이언트(웹/모바일)까지 모두 제공합니다
🧩 주요 구성 및 특징
-
핵심 구성 요소
- Jitsi Videobridge (JVB): SFU 서버 역할을 합니다.
- Jicofo: 회의 관리 및 시그널링 중심의 코디네이션을 담당합니다.
- Prosody: XMPP 기반의 시그널링 서버입니다.
- Jitsi Meet: 웹 기반 사용자 인터페이스(UI)입니다.
-
아키텍처: Jitsi Meet(프론트엔드), Jicofo(회의 관리), JVB(Jitsi Video Bridge, SFU), Prosody(XMPP 시그널링) 등으로 구성된 모듈형 구조입니다.
-
확장성: JVB(Videobridge)를 여러 대 추가하고, Octo(분산 처리) 및 로드밸런싱을 적용하면 200~250명 이상의 대규모 회의도 지원하며, 최적화 시 수백~수천 명까지 확장 가능합니다.
-
기본 기능: 화면 공유, 채팅, 녹화, 브라우저 기반 UI, 모바일 앱 등 대부분의 화상회의 기능이 기본으로 제공됩니다.
-
커스터마이징: 로고, UI 변경, 기능 추가 등 커스터마이징이 가능하지만, Mediasoup만큼의 자유도는 아닙니다.
💪 장점
- 빠른 구축: 별도 개발 없이 바로 사용 가능하며, 완성형 UI와 서버를 제공합니다.
- 확장성: JVB 추가 및 서버 최적화, Octo 활용 시 200~250명(기본), 최적화 시 수백~수천 명까지 확장 가능합니다.
- 커뮤니티/문서: 대규모 커뮤니티와 풍부한 문서, 다양한 성공 사례가 존재합니다.
- 보안: E2EE(1:1 통화), 서버 자체 운영, 다양한 보안 옵션을 지원합니다.
🏗️ 대규모 회의 고려사항
- Simulcast 필수: 발표자 비디오는 고화질로, 청취자에게는 저화질로 전송하는 등 효율적인 미디어 전송을 위해 시뮬캐스트를 활용해야 합니다.
- Octo 모드 활용: Videobridge 여러 대를 연결하여 부하를 분산해야 합니다.
- 클라이언트 제한: UI에서 "타일 뷰"를 제한하여 표시되는 비디오 수를 축소하는 것이 좋습니다.
- 대규모 방에서는 청취자 전용 모드를 권장하여 클라이언트의 부하를 줄여야 합니다.
Mediasoup vs. Jitsi Meet 비교
| 항목 | Mediasoup | Jitsi Meet |
|---|---|---|
| 확장성 | 매우 높음 (수백~수천 명, 워커/라우터 분산) | 높음 (JVB/Octo로 200~250명, 확장 가능) |
| 아키텍처 | SFU, Node.js + C++, 완전 모듈/커스텀 | 완성형 솔루션, 모듈 구조 (XMPP + Videobridge + Web UI) |
| 시그널링 | 직접 구현 | 내장 (Prosody) |
| 대규모 확장성 | 매우 유연함 (Worker 분산) | Octo로 다중 브리지 가능 |
| 커스터마이징 | 매우 높음 (모든 기능 직접 구현) | 중간 (UI/기능 위주) |
| 개발 난이도 | 높음 (WebRTC/미디어 서버 지식 필요) | 낮음 (즉시 사용 가능) |
| UI 제공 | 없음 (직접 개발) | 있음 (웹/모바일) |
| 커뮤니티 | 중간 | 매우 활발 |
| 주요 용도 | 맞춤형 대규모 플랫폼, 고급 미디어 처리 | 일반 화상회의 서비스, 빠른 구축 |
