WebRTC는 단일 프로토콜이라기보다 브라우저 API와 여러 표준 프로토콜의 조합이다. 카메라와 마이크 접근, 피어 연결, NAT 통과, 암호화된 미디어 전송이 함께 움직인다.
1:1 통화나 아주 작은 그룹에서는 Peer-to-Peer로 충분할 수 있다. 그러나 참가자가 늘어나면 문제는 API 사용법에서 미디어 라우팅으로 바뀐다. 누가 스트림을 복제하고, 누가 품질을 조정하며, 누가 장애를 책임지는지가 설계의 핵심이 된다.
Mesh: 클라이언트가 미디어를 복제한다
Mesh는 참가자들이 서로 피어 연결을 만드는 구조다. 직접 ICE 경로가 잡히면 미디어는 클라이언트끼리 오가지만, 직접 연결이 어려우면 TURN 서버가 릴레이한다.
완전 연결 구조에서는 각 클라이언트가 다른 참가자에게 미디어를 보내야 한다. 참가자가 늘어날수록 업로드 대역폭, 인코딩 방식, CPU와 배터리 부담이 커진다. 다만 TURN 사용량까지 포함한 서버 비용은 연결 환경에 따라 달라진다.
시간 순서대로 미디어가 어느 지점을 거치는지 보여줍니다.
직접 ICE 경로 예시입니다. 연결 조건에 따라 미디어가 TURN 릴레이를 거칠 수 있습니다.
완전 연결 Mesh에서 참가자 n명 기준 피어 쌍은 n(n-1)/2개이고, 각 사용자의 송신 대상은 n-1명까지 늘어납니다. 실제 한계는 코덱, simulcast, 단말 성능과 네트워크에서 시험해야 합니다.
SFU: RTP 패킷을 선택 전달한다
SFU는 Selective Forwarding Unit이다. 클라이언트는 SFU로 스트림을 보내고, SFU는 수신자별로 필요한 스트림을 선택해 전달한다.
일반적인 SFU는 영상을 디코딩해 합성하지 않는다. 대신 RTP/RTCP 상태와 구독 정책을 바탕으로 어떤 스트림 또는 simulcast/SVC 레이어를 전달할지 결정한다. 구체적인 정책은 구현마다 다르다.
시간 순서대로 미디어가 어느 지점을 거치는지 보여줍니다.
각 사용자는 SFU로 트랙과 인코딩 레이어를 게시하고, SFU는 선택한 RTP 패킷을 전달합니다.
SFU는 일반적으로 미디어를 디코딩·합성하지 않고 RTP/RTCP와 코덱 메타데이터를 처리합니다. 수신자별 네트워크 상태, 구독 정책, simulcast/SVC 구성에 따라 전달 스트림이나 레이어를 고를 수 있습니다.
MCU: 서버가 미디어를 합성한다
MCU는 Multipoint Control Unit이다. 서버가 여러 미디어 스트림을 받아 디코딩하고, 믹싱하거나 레이아웃을 만든 뒤 다시 인코딩해 배포한다.
하나의 합성 스트림을 받는 구성에서는 클라이언트의 동시 디코딩 부담을 줄일 수 있다. 대신 서버가 미디어 처리를 직접 하므로 연산 비용과 처리 지연이 추가된다.
시간 순서대로 미디어가 어느 지점을 거치는지 보여줍니다.
서버가 여러 스트림을 받아 디코딩, 믹싱, 인코딩한 뒤 하나의 결과 스트림을 배포합니다.
MCU는 합성 스트림, 고정 레이아웃과 방송 출력에 적합할 수 있습니다. 대신 서버가 미디어를 직접 처리하므로 연산 비용과 처리 지연이 추가됩니다. 패킷 기반 녹화에는 반드시 MCU가 필요한 것은 아닙니다.
토폴로지는 요구에 맞춰 조합할 수 있다
1:1 상담은 검증 결과에 따라 P2P로 운영할 수 있고, 다자간 선택 전달에는 SFU를 사용할 수 있다. 합성 화면이나 다른 출력 코덱이 필요하면 별도의 합성·트랜스코딩 파이프라인을 연결한다. 녹화만으로 MCU가 필수인 것은 아니다.
이 방식은 유연하지만 운영 난도가 높다. 전환 조건, 장애 격리, 지역별 라우팅, 품질 관측성을 함께 설계해야 한다.
서비스 요구에 따라 Mesh, SFU, 합성·트랜스코딩 경로를 조합할 수 있습니다.
Hybrid는 가능한 설계 패턴이지 필수 단계가 아닙니다. 참가자 수, 출력 형식, 네트워크 품질, 지역 라우팅과 운영 복잡도를 기준으로 경로를 나눕니다. 녹화 자체가 반드시 MCU를 요구하는 것은 아닙니다.
참가자 수보다 미디어 처리 책임을 먼저 정한다
| 기준 | Mesh | SFU | MCU |
|---|---|---|---|
| 미디어 복제 책임 | 클라이언트별 송신 | 서버 패킷 전달 | 서버 디코딩·합성·재인코딩 |
| 서버 역할 | 시그널링과 필요 시 TURN | 수신자별 선택 전달 | 합성 스트림 생성 |
| 클라이언트 부담 | 참가자 수에 따라 증가 | 구독 수·레이어에 따라 변동 | 합성 스트림 수에 따라 변동 |
| 서버 부담 | 시그널링·TURN 사용량 | 대역폭·패킷 처리 | 연산 집약적 미디어 처리 |
| 지연 특성 | 직접 또는 TURN 경로 | SFU 홉 추가 | 처리 파이프라인 추가 |
| 대표 사용처 | 검증된 소규모 세션 | 다자간 선택 전달 | 합성 출력·레거시 연동 |
미디어 복제를 클라이언트가 할 것인가, 서버가 할 것인가?
서버가 단순 전달만 할 것인가, 미디어를 직접 처리할 것인가?
지연 시간, 비용, 품질, 녹화, 방송 송출 중 무엇이 핵심인가?
이 인프라를 직접 운영할 역량과 이유가 있는가?
플랫폼은 복잡성을 없애기보다 운영 책임을 이전한다
CPaaS는 SDK 외에도 관리형 미디어 라우팅, 품질 제어, 녹화, 방송 송출, 인증과 운영 도구를 제공할 수 있다. 실제 제공 범위와 책임 경계는 제품, 요금제, 리전과 계약을 확인해야 한다.
직접 SFU나 합성 파이프라인을 운영하면 제어권은 커지지만 개발·관측·장애 대응 책임도 함께 커진다. CPaaS는 출시 속도를 높일 수 있는 대신 벤더 종속, 비용 구조와 기능 제약을 검토해야 한다.