[개발 일기] 2025.05.07 - WebRTC 구현 방식

💡 개요

 

어젠 WebRTC의 연결과정에서 사용되는 기술이나 프로토콜을 정리했다.

 

 

오늘은 WebRTC에서 사용되는 화상통화 구현 방식에 대해 정리해 보자.

 

 

 

👨🏻‍💻 WebRTC 구현 방식

 

WebRTC를 구현할 때 주로 사용되는 서버 형태는 주로 Signaling, SFU, MCU가 있다.

 

 

⚙️ Signaling

 

Signaling 서버의 역할은 피어 간에 offer, answer, ICE candidate 등 초기 연결 정보를 중계하는 것이다.

 

 

즉, WebRTC 연결이 성립되기 전까지 필요한 메타데이터만 전달할 뿐, 실제 미디어(오디오/비디오) 데이터는 중계하지 않는다.

 

 

그렇기 때문에 피어(화상채팅을 하고자하는 사용자)가 서로 연결될 때 서버의 부하가 발생한다.

 

 

그 이후엔 별도의 부하는 발생하지 않는다.

 

 

따라서 1:1 화상 채팅처럼 연결 수가 적고 미디어 트래픽이 피어 간에 직접 전달되는 상황에서 적합하다.

 

 

하지만 N:N 연결의 경우엔 Signaling 방식은 적합하지 않다.

 

 

왜냐하면 연결된 피어 수 만큼 Uplink(송신)와 Downlink(수신)가 늘어나 클라이언트에게 가해지는 부하가 커지기 때문이다.

 

 

 

⚙️ MCU (Multipoint Control Unit)

 

 

MCU(Multipoint Control Unit)는 다수의 사용자가 참여하는 화상회의 등에서 모든 미디어 스트림을 중앙 서버로 모아서 믹싱하고, 다시 각 사용자에게 전송하는 방식이다.

 

 

쉽게 말해, 자신을 제외한 모든 참가자의 영상과 음성을 중앙 서버에서 하나로 합쳐 하나의 스트림처럼 받아보는 구조라고 할 수 있다.

 

 

이 방식에서는 각 사용자가 오직 하나의 Uplink와 하나의 Downlink만 사용하며, 모든 통신은 중앙 MCU 서버를 통해 이루어진다.

 

 

이러한 특징 때문에 클라이언트의 부하가 작고, N:N와 같은 연결 구조에 적합한 서버 방식이다.

 

 

하지만 그 만큼 하나의 영상으로 만들기 위해 중앙 서버에서 사용되는 리소스나 지연시간이 있다.

 

 

그렇기 때문에 실시간성이 저해될 수 있다.

 

 

 

⚙️ SFU(Selective Forwarding Unit)

 

 

SFU 방식은 각 사용자가 서버에 보낸 미디어 스트림을 그대로 다른 참가자들에게 선택적으로 전달하는 역할을 한다.

 

 

즉, MCU처럼 스트림을 하나로 믹싱하지 않고, 단순히 중계만 하는 구조다.

 

 

이러한 방식은 중앙 서버의 부하와 지연 시간을 줄이는 데 유리하며, 클라이언트는 오직 하나의 Uplink(송신) 스트림만 서버로 전송하면 되므로 송신 측 부담도 적다.

 

 

다만, 클라이언트는 다른 참가자들의 스트림을 모두 Downlink(수신)로 받아야 하므로, 참여 인원이 많아질수록 여러 개의 영상 스트림을 디코딩하고 렌더링하는 부담이 커질 수 있다.

 

 

그럼에도 불구하고, 현재 대부분의 WebRTC 기반 서비스는 SFU 방식을 선호한다.

 

 

지연이 적고 확장성이 뛰어나며, 클라이언트 환경에 따라 유연한 품질 제어도 가능하기 때문이다.

 

 

Discord, Zoom, OpenVidu 등 오늘날 많이 사용되는 WebRTC 관련 프레임워크와 서비스들 역시 대부분 SFU 방식을 채택해 실시간 커뮤니케이션을 구현하고 있다.