WebRTC는 단일 프로토콜이라기보다 브라우저 API와 여러 표준 프로토콜의 조합이다. 카메라와 마이크 접근, 피어 연결, NAT 통과, 암호화된 미디어 전송이 함께 움직인다.
1:1 통화나 아주 작은 그룹에서는 Peer-to-Peer로 충분할 수 있다. 그러나 참가자가 늘어나면 문제는 API 사용법에서 미디어 라우팅으로 바뀐다. 누가 스트림을 복제하고, 누가 품질을 조정하며, 누가 장애를 책임지는지가 설계의 핵심이 된다.
가장 단순하지만 가장 빨리 무너진다
Mesh는 참가자들이 서로 직접 연결되는 구조다. 서버는 주로 시그널링만 담당하고, 실제 미디어는 클라이언트끼리 주고받는다.
서버 비용은 낮지만 각 클라이언트가 다른 모든 참가자에게 스트림을 보내야 한다. 참가자가 늘어날수록 업로드 대역폭, CPU, 배터리 부담이 빠르게 커진다.
시간 순서대로 미디어가 어느 지점을 거치는지 보여줍니다.
서버는 미디어를 전달하지 않고, 각 클라이언트가 다른 클라이언트로 직접 보냅니다.
참가자 n명 기준 연결은 n(n-1)/2개, 각 사용자의 업로드 스트림은 n-1개까지 늘어납니다. 그래서 1:1 또는 아주 작은 그룹에는 단순하지만, 그룹이 커지면 클라이언트 부담이 먼저 터집니다.
대부분의 실시간 회의가 도착하는 기본값
SFU는 Selective Forwarding Unit이다. 클라이언트는 SFU로 스트림을 보내고, SFU는 수신자별로 필요한 스트림을 선택해 전달한다.
핵심은 서버가 영상을 합성하지 않는다는 점이다. 대신 네트워크 상태, 화면 레이아웃, 활성 발화자 여부에 따라 어떤 스트림 또는 품질 레이어를 보낼지 결정한다.
시간 순서대로 미디어가 어느 지점을 거치는지 보여줍니다.
각 사용자는 서버로 하나를 올리고, SFU는 필요한 스트림만 골라 내려보냅니다.
SFU는 보통 미디어를 디코딩·합성하지 않습니다. 대신 수신자별 네트워크 상태, 화면 레이아웃, 활성 발화자, simulcast/SVC 레이어에 따라 어떤 스트림을 전달할지 선택합니다.
클라이언트 부담을 서버 비용으로 산다
MCU는 Multipoint Control Unit이다. 서버가 여러 미디어 스트림을 받아 디코딩하고, 믹싱하거나 레이아웃을 만든 뒤 다시 인코딩해 배포한다.
수신자는 하나의 합성 스트림만 받으면 되므로 클라이언트 구현과 디코딩 부담이 줄어든다. 대신 서버는 미디어 처리를 직접 하므로 비용과 지연이 증가한다.
시간 순서대로 미디어가 어느 지점을 거치는지 보여줍니다.
서버가 여러 스트림을 받아 디코딩, 믹싱, 인코딩한 뒤 하나의 결과 스트림을 배포합니다.
MCU는 수신 클라이언트 부담을 낮추고 녹화·고정 레이아웃·방송 송출에 강합니다. 대신 서버가 미디어를 직접 처리하므로 비용과 지연이 SFU보다 커지는 편입니다.
실제 서비스는 하나만 쓰지 않는다
1:1 상담은 P2P로 시작할 수 있다. 참가자가 늘면 SFU로 전환한다. 녹화, 방송 송출, 고정 레이아웃이 필요하면 MCU나 트랜스코딩 파이프라인을 붙인다.
이 방식은 유연하지만 운영 난도가 높다. 전환 조건, 장애 격리, 지역별 라우팅, 품질 관측성을 함께 설계해야 한다.
실제 서비스는 세션 규모와 기능 요구에 따라 Mesh, SFU, MCU를 함께 씁니다.
Hybrid 설계의 핵심은 전환 정책입니다. 참가자 수, 녹화 여부, 방송 송출 여부, 네트워크 품질, 지역 라우팅을 기준으로 어떤 구간을 Mesh/SFU/MCU로 보낼지 정해야 합니다.
질문은 몇 명까지 되나요가 아니라, 누가 미디어 책임을 지나요여야 한다
| 기준 | Mesh | SFU | MCU |
|---|---|---|---|
| 미디어 복제 책임 | 클라이언트 | 서버 | 서버 |
| 서버 역할 | 시그널링 중심 | 선택 전달 | 디코딩, 믹싱, 인코딩 |
| 클라이언트 부담 | 높음 | 중간 | 낮음 |
| 서버 비용 | 낮음 | 중간 | 높음 |
| 지연 시간 | 낮을 수 있음 | 중간 | 상대적으로 높음 |
| 강한 사용처 | 1:1, 소규모 | 회의, 수업, 협업 | 방송, 녹화, 고정 레이아웃 |
미디어 복제를 클라이언트가 할 것인가, 서버가 할 것인가?
서버가 단순 전달만 할 것인가, 미디어를 직접 처리할 것인가?
지연 시간, 비용, 품질, 녹화, 방송 송출 중 무엇이 핵심인가?
이 인프라를 직접 운영할 역량과 이유가 있는가?
플랫폼은 복잡성을 없애기보다 운영 책임을 이전한다
Agora 같은 CPaaS의 가치는 WebRTC API를 감싸는 데서 끝나지 않는다. 글로벌 라우팅, 품질 제어, 녹화, 방송 송출, 보안, 토큰 기반 인증, 장애 대응, 운영 가시성 같은 부분을 제품팀 대신 플랫폼이 맡는다.
직접 SFU나 MCU를 운영할 수도 있다. 다만 제품의 핵심이 미디어 인프라가 아니라 교육, 상담, 커뮤니티, 커머스 경험이라면 CPaaS를 쓰는 편이 더 빠르고 덜 위험할 수 있다.