🎥 WebRTC란?

WebRTC (Web Real-Time Communication)

• 브라우저 간에 플러그인 없이 실시간 오디오 비디오 데이터를 P2P(Peer-to-Peer)로 주고받을 수 있게 하는 오픈 표준 기술

---

📌 WebRTC의 특징

🧩 특징	설명
🎥 실시간성	저지연으로 음성/영상 전송
🔗 P2P 연결	브라우저끼리 직접 연결 (대역폭 절약)
🔒 보안 내장	DTLS/SRTP로 암호화 필수
⚡ 브라우저 지원	Chrome, Firefox, Safari, Edge 기본 내장
📡 Signaling 필요	연결 설정은 별도의 Signaling 서버로

⚙️ P2P란?

P2P(Peer-to-Peer)는 중앙 서버를 거치지 않고 참여자(Peer)끼리 직접 데이터를 주고받는 네트워크 구조

Client-Server: 클라이언트 → 서버 → 다른 클라이언트 (서버가 모든 트래픽 중계)

P2P: 클라이언트 ↔ 클라이언트 직접 연결 (서버는 연결 정보만 교환)

따라서 WebRTC는 P2P구조 덕분에 저지연 실시간 통신 구현!

🔍 P2P 구조의 장점

✅ 장점	설명
⚡ 저지연	중간 서버 경유 없이 직접 연결 → 속도 빠름
💵 서버 비용↓	서버는 Signaling만 담당, 데이터 트래픽은 Peers가 직접
🔗 확장성	작은 규모에선 서버 트래픽 부담 최소화
🔒 개인 정보 보호	데이터가 중앙 서버에 저장되지 않아 유출 리스크↓
🌍 분산 구조	서버 장애 발생 시에도 Peers 간 통신 가능

⚡ P2P 구조의 단점

❌ 단점	설명
📈 대역폭 한계	다자간 연결 시 각 Peer가 N명에게 전송 → 네트워크 폭발
🔀 NAT/방화벽 문제	개인 PC/네트워크에서 P2P 연결이 실패할 수 있음 (그래서 STUN/TURN 필요)
🔍 연결 관리 어려움	연결 안정성 확보, 끊김 처리 등 직접 구현해야 함
🗂️ 데이터 일관성	여러 Peer 간 데이터 동기화가 복잡
🧩 스케일링 불리	대규모 방송엔 중앙 서버/CDN이 훨씬 효율적

---

🛠️ WebRTC 동작 구조

구성 요소	역할
📡 Signaling Server	SDP/ICE 후보 교환
❄️ STUN Server	공인 IP 탐색, NAT 방화벽 우회
🔄 TURN Server	P2P 연결 실패 시 미디어 릴레이
🔗 PeerConnection	피어 간 오디오/비디오 연결
📦 DataChannel	임의 데이터(P2P 채팅 등) 전송

---

🔄 WebRTC 연결 흐름

1️⃣ Signaling 시작:
클라이언트가 Signaling Server에 SDP(Session Description Protocol)와 ICE 후보 정보 전송

2️⃣ STUN 요청:
공인 IP 획득 → NAT 방화벽 우회 시도

3️⃣ P2P 연결 성립:
직접 연결되면 미디어/데이터 전송 시작

4️⃣ TURN 사용(필요 시):
P2P 실패 시 TURN Server가 릴레이 역할

---

🧩 대표 대체 기술 비교

항목	🌐 WebRTC	📡 RTMP	📺 HLS/DASH	🧰 Zoom SDK / Agora.io
🕒 지연 시간	매우 낮음 (~200ms)	낮음 (1~2초)	높음 (5~30초)	매우 낮음 (~200ms)
🔗 연결 방식	P2P (Signaling 필요)	서버 기반 송출	서버 기반 Chunk 전송	상용 미디어 서버
⚡ 실시간성	💯	🔆	❌	💯
🧩 플러그인/설치	브라우저 기본 지원	별도 인코더 필요	브라우저 기본 지원	SDK 설치 필요
🔄 확장성	SFU/MCU로 그룹 회의 가능	서버 성능에 따라	대규모 VOD/Live	안정성 높음
🔒 보안	DTLS/SRTP 암호화	기본 미지원	HTTPS로 전송	상용 수준 보안
💰 비용	직접 구축 (무료)	미디어 서버 비용	CDN 비용	사용량 과금

🎥 대표 방송/화상 플랫폼별 핵심 스트리밍 기술

플랫폼	주요 기술 스택	특징
📺 YouTube Live	RTMP 업로드 → Transcoder → HLS/DASH CDN	🔄 대규모 VOD/라이브, 수 초 지연 허용
🎮 Twitch	RTMP 인gest → Media Server → HLS	🔄 게이밍 최적화, 낮은 지연, 대규모 뷰어
🎤 Zoom	WebRTC + SFU/MCU	⚡ 실시간 화상회의 최적화, 저지연
🎙️ Discord	WebRTC + SFU/MCU	⚡ 음성 채널/화면 공유 실시간 P2P
📱 Instagram Live	RTMP(방송앱) → HLS	🔄 모바일 중심, VOD 저장
🎵 TikTok Live	RTMP ingest → Transcoder → HLS	🔄 모바일, 쇼트폼 라이브, CDN

❓ 왜 WebRTC는 대규모 방송에서 잘 안 쓰일까?

이유	설명
📡 P2P 구조	1:1이나 소규모는 강력하지만 수천~수만명 동시 뷰어는 불가능
💸 SFU/MCU 비용	다중 사용자 믹싱/분배 서버 부하 ↑↑
🌎 글로벌 CDN 연동	HLS/DASH는 CDN과 궁합이 좋음, P2P는 한계

🔧 실무 영역 적용

1. WebRTC API 실제 사용법

• getUserMedia() - 카메라/마이크 접근
• RTCPeerConnection - 피어 연결 관리
• RTCDataChannel - 텍스트/파일 전송
• SDP Offer/Answer 교환 과정

2. 시그널링 서버 구현

• WebSocket vs Socket.IO vs Server-Sent Events
• 방 개념 구현 (Room-based signaling)
• 사용자 입장/퇴장 관리

3. STUN/TURN 서버 설정

• 무료 STUN 서버들 (Google, Cloudflare)
• TURN 서버 구축 (coturn 등) 또는 상용 서비스
• ICE 후보 수집과 연결성 테스트

4. 브라우저 호환성 & 제약사항

• iOS Safari의 WebRTC 제한사항
• 모바일에서의 배터리/성능 이슈
• HTTPS 필수 요구사항

5. 멀티 유저 아키텍처

• SFU(Selective Forwarding Unit) vs MCU(Multipoint Control Unit)
• 화상회의 시 대역폭 관리
• 참여자 수에 따른 성능 고려

📢WebRTC 및 스트리밍 관련 면접 대비 Q&A

Q: WebRTC란 무엇이며, 어떤 특징을 가지고 있나요?

A: WebRTC(Web Real-Time Communication)는 브라우저 간에 플러그인 없이 실시간으로 오디오와 비디오(그리고 데이터)를 P2P 방식으로 주고받을 수 있게 해주는 오픈 표준 기술입니다. 웹 애플리케이션에서 화상 통화, 라이브 스트리밍, P2P 데이터 교환 등을 구현할 때 쓰입니다. WebRTC의 주요 특징은 다음과 같습니다.

저지연 실시간 통신: 중앙 서버를 거치지 않고 직접 연결하므로 음성/영상 데이터를 거의 실시간에 가깝게 (수백 ms 수준) 주고받을 수 있습니다.

P2P 직접 연결: 참여자들 간에 Peer-to-Peer로 미디어를 전송하여, 중간 미디어 중계 서버 없이 직접 통신합니다. 이로써 서버 트래픽과 지연을 크게 줄입니다.

보안 내장: WebRTC는 DTLS/SRTP 프로토콜을 통해 전송되는 미디어를 자동 암호화합니다. 별도의 설정 없이도 기본적으로 모든 오디오/비디오/데이터 채널이 암호화되어 보안이 보장됩니다.

브라우저 기본 지원: Chrome, Firefox, Safari, Edge 등의 현대적인 브라우저에 기본 내장된 API라 별도 플러그인이나 설치가 필요 없습니다. (모바일 앱에서도 WebRTC 라이브러리를 통해 사용 가능)

별도 시그널링 필요: WebRTC 자체에는 연결 설정(handshaking)을 위한 시그널링 방식이 정의되어 있지 않기 때문에, SDP/ICE 정보를 교환할 별도의 Signaling 서버나 채널이 필요합니다.

Q: P2P란 무엇이며 WebRTC에서 왜 사용되나요? 기존 클라이언트-서버 모델과 어떻게 다른가요?

A: P2P(Peer-to-Peer)는 중앙 서버를 경유하지 않고 참여자들 간에 직접 데이터를 주고받는 네트워크 구조를 말합니다. WebRTC에서는 음성/영상 같은 미디어 스트림을 P2P로 전송하는데, 이는 전통적인 클라이언트-서버 모델과 대비됩니다.

클라이언트-서버 모델: 각 클라이언트가 중앙 서버에 데이터를 보내면, 서버가 그 데이터를 가공하거나 다른 클라이언트로 중계합니다. 예를 들어 화상통화에서 서버가 모든 영상을 받아 다시 각 참여자에게 보내는 구조입니다. 이 방식은 구현이 단순하지만 서버에 부하가 크고, 경유 과정 때문에 지연 시간이 증가합니다.

P2P 모델 (메시 구조): 각 피어(클라이언트) 가 서로 직접 연결되어 데이터를 직접 주고받는 구조입니다. WebRTC에서는 시그널링을 통해 연결 정보를 교환한 후, 브라우저끼리 직접 미디어를 송수신합니다. 중간에 미디어를 중계할 서버가 없으므로 지연이 최소화되고, 서버 트래픽 비용도 줄어드는 장점이 있습니다. WebRTC가 P2P 방식을 사용하는 이유도 이러한 낮은 지연을 달성하고 대역폭 효율을 높이기 위해서입니다. (서버는 연결 설정에만 관여하고 실제 미디어 데이터는 가능하면 서버를 거치지 않습니다.)
요약하면, WebRTC의 P2P 통신 덕분에 양쪽 클라이언트가 직접 음성/영상을 주고받아 실시간성을 극대화하며, 이는 기존 서버 중계 방식보다 빠르고 경제적인 전송을 가능케 합니다.

Q: P2P 구조의 장점과 단점은 무엇인가요?

A: P2P 구조는 WebRTC의 핵심이지만, 상황에 따라 장단점이 있습니다:
✅ 장점:
저지연 높은 실시간성: 중간 서버를 거치지 않아 전송 지연이 매우 낮고 실시간 상호작용에 유리합니다.

서버 부담 및 비용 감소: 미디어 트래픽을 중앙 서버가 처리하지 않으므로 서버 대역폭/처리 부담이 감소하고 서버 운영 비용이 줄어듭니다. (서버는 signaling 등 최소한의 역할만 수행)
분산 및 안정성: 통신이 분산 구조로 이루어지기 때문에, 부분적으로 서버에 장애가 생겨도 피어 간 통신은 유지될 수 있습니다. 또한 데이터가 중앙 서버에 머물지 않아 개인정보 노출 위험도 낮습니다.

소규모 활용에 효율적: 1:1 통화나 少인원의 통신에선 P2P가 최적입니다. 피어 수가 적을 경우 직접 연결로 충분히 감당 가능하고, 이때 서버 부하는 최소화됩니다.

❌ 단점:
피어 대역폭 부담: 참여자 수가 늘어나면 각 피어가 모든 다른 피어에게 별도 스트림을 전송해야 하므로, 예를 들어 4명이면 한 사용자 카메라 영상을 3명이 각각 받아야 하고 송신자는 3개의 업로드 스트림을 보내야 합니다. 이 때문에 N명이 모두 서로 주고받는 메쉬 구조는 대역폭 부담이 급증하여 대규모로 확장하기 어렵습니다.

NAT/방화벽 문제: 대부분 사용자가 공유기 뒤나 사내망 뒤에 있는데, 직접 P2P 연결이 NAT나 방화벽에 막혀 실패할 수 있습니다. 이때는 STUN을 통한 NAT 탐색이나 TURN 서버를 통한 중계가 필요합니다.

연결 관리 복잡: 여러 피어 간 연결 상태를 유지하고 재접속/끊김 처리를 각 클라이언트가 상호 관리해야 해서 구현이 복잡합니다. (중앙 서버가 모두 컨트롤하는 구조보다 끊어진 피어 처리 등이 어려움)

데이터 동기화 어려움: P2P는 중앙 조정자가 없다보니 여러 피어 간 데이터 일관성을 유지하거나 전체 참가자에 대한 글로벌 상태 관리가 복잡합니다.

대규모 방송 비부적합: 수백 명~수천 명이 시청하는 일대다 방송에는 P2P가 맞지 않습니다. 이런 경우 각 시청자와 스트리머를 P2P로 모두 연결할 수 없으므로, CDN이나 중앙 서버 기반 전송(예: HLS)이 선호됩니다.

Q: WebRTC 연결을 수립하기 위해 어떤 구성 요소(서버나 기술)가 필요한가요?

A: WebRTC로 두 브라우저(피어)가 직접 통신하려면 WebRTC API만으로는 부족하고, 주변에 몇 가지 필수 구성 요소가 필요합니다:

📡 시그널링(Signaling) 서버: WebRTC 연결 설정에 필요한 정보(세션 설명과 네트워크 정보)를 교환하는 용도의 서버입니다. WebRTC 자체에는 signaling 방법이 정의되어 있지 않으므로, 일반적으로 웹소켓이나 HTTP를 이용한 커스텀 signaling 서버를 둡니다. 이 서버를 통해 SDP(세션 기술 프로토콜로 오디오/비디오 코덱 등 능력 명세)와 ICE 후보(피어의 가능한 네트워크 주소들) 정보를 서로 주고받아 연결 협상을 시작합니다.

❄️ STUN 서버: Session Traversal Utilities for NAT 서버로, 각 클라이언트가 자신의 공인 IP와 포트를 알아내는 데 사용됩니다. 피어가 STUN 서버에 요청하면 서버가 "외부에서 보이는 IP:PORT"를 알려주고, 이를 ICE 후보로 사용하여 NAT 뒤에 있어도 상대에게 연결 가능한 주소를 전달할 수 있게 합니다. (즉, NAT traversal 용도)

🔄 TURN 서버: Traversal Using Relays around NAT 서버로, 최후의 수단인 미디어 릴레이 서버입니다. 피어 간 P2P 직접 연결이 NAT나 방화벽 문제로 실패할 경우, 미디어 데이터를 TURN 서버를 통해 중계합니다. TURN 서버는 양쪽과 모두 연결되어 클라이언트 A의 데이터를 받아 B에 전달하고, 반대로 B의 데이터를 A로 보내주는 중계자 역할을 합니다. (직접 연결이 안 될 때 Fallback으로 사용되며, 지연이 다소 증가하고 서버 트래픽 비용이 들게 됩니다.)

🔗 PeerConnection: WebRTC에서 제공하는 피어 연결 객체(인터페이스) 로, 두 피어 간의 오디오/비디오 스트림 전송을 담당합니다. 어플리케이션은 이 PeerConnection API를 통해 상대와 연결하고 미디어(또는 데이터)를 주고받습니다. 내부적으로는 ICE, RTP/RTCP, DTLS 등 프로토콜을 활용하여 미디어의 송수신, 네트워크 품질 관리 등을 처리합니다.

📦 데이터 채널(DataChannel): WebRTC의 부가 기능으로, 임의의 데이터(텍스트 채팅, 파일 등)를 P2P로 보낼 수 있는 채널입니다. PeerConnection을 통해 설정되며, UDP 기반의 신뢰성/순서 보장 옵션을 조절할 수 있는 프로토콜(SCTP over DTLS)을 사용합니다. 예를 들어 WebRTC 기반 화상 앱에서 채팅 메시지를 주고받을 때 DataChannel을 활용할 수 있습니다.

이처럼 WebRTC 기반 서비스를 구축하려면, 클라이언트 측 WebRTC API 외에도 Signaling 용 서버와 STUN/TURN 인프라가 함께 필요합니다. (물론 STUN은 공용 무료 서버를 쓰기도 하지만, 서비스 품질을 위해 자체 구축하기도 합니다.)

Q: WebRTC 연결은 어떤 절차로 이루어지나요? (SDP 교환부터 P2P 연결 성립까지)

A: WebRTC를 이용한 두 피어 간 연결 수립은 시그널링 단계 → ICE 후보 교환 및 연결 시도 → 미디어 스트림 전송 순으로 진행됩니다. 요약하면 아래와 같습니다:

1️⃣ Signaling 단계 (SDP 교환): 통신을 시작할 클라이언트 A가 SDP Offer를 생성합니다. 여기에는 자신의 영상/음성 코덱, 해상도, 네트워크 가능 정보 등이 포함됩니다. 이 SDP Offer를 시그널링 서버를 통해 상대방 B에게 전달합니다. B는 이를 받고 자신도 SDP Answer를 만들어 응답합니다. 이 과정에서 양측의 미디어 능력과 설정이 합의됩니다. (또한 signaling 채널을 통해 ICE 후보 정보도 주고받기 시작합니다. ICE 후보란 각 피어의 잠재적인 네트워크 엔드포인트 목록입니다.)

2️⃣ NAT 탐색 및 ICE 후보 교환: 각 피어는 ICE 프로토콜을 사용하여 자신이 연결될 수 있는 후보 주소들을 수집합니다. 로컬 IP(예: 192.168.x.x)뿐 아니라, STUN 서버에 질의해서 얻은 공인 IP:PORT, 그리고 만약에 대비한 TURN 릴레이 주소까지 포함하여 여러 ICE 후보들을 만들어냅니다. 이 후보들을 서로 시그널링을 통해 교환하면서, 직접 연결 시도를 진행합니다. NAT 유형에 따라 여러 후보를 시험해서, 양쪽 모두 통과 가능한 최적 경로를 찾습니다.

3️⃣ P2P 연결 성립 (ICE 연결): 교환된 ICE 후보들을 토대로 피어 간 직접 통신을 시도합니다. 예를 들어 A의 공인 IP와 B의 공인 IP로 바로 UDP 패킷을 보내본다든지, 한 쪽은 다른 쪽의 TURN 서버 주소로 보내본다든지 여러 경로를 테스트합니다. 이 과정을 ICE 후보 탐색/체크라고 합니다. 성공적인 조합이 발견되면 즉시 그 경로로 P2P 연결이 확립됩니다. (성공한 후보 쌍을 ICE 연결로 선택하고 나면 다른 시도는 중단됩니다.)

4️⃣ 보안 협상 및 미디어 전송 시작: 연결이 성립되면, 두 피어는 DTLS를 통해 보안 키 교환을 수행하고 미디어 스트림을 암호화할 준비를 합니다. 이후 SRTP를 통해 오디오/비디오 패킷을 실시간 전송하게 됩니다. 이제 브라우저 간 P2P로 음성/영상 스트림이 오가며 통화나 스트리밍이 시작됩니다. 통신 중에는 네트워크 상태에 따라 실시간으로 대역폭 조절, FEC, NACK 등 품질 제어가 WebRTC 엔진에 의해 수행됩니다.

5️⃣ (TURN 중계): 만약 직접 경로가 끝내 실패한 경우(예: 양쪽 모두 symmetric NAT이거나 방화벽에 막힌 경우), TURN 후보(릴레이 서버 경로)가 선택됩니다. 이때는 각 피어가 TURN 서버로만 통신하고, TURN 서버가 패킷을 상대 피어로 대신 전달해 줍니다. 이렇게 해서라도 연결이 보장되도록 하는 것이 목적이며, TURN을 쓰면 P2P가 아니므로 지연이 늘고 서버 트래픽도 발생하지만 통신 자체는 성공하게 됩니다.

정리하면, WebRTC 연결 과정은 (a) 시그널링 협상으로 통신 준비 → (b) ICE로 최적 P2P 경로 탐색 → (c) direct P2P 연결로 미디어 송수신 (안 되면 TURN 중계) 순으로 진행됩니다. 이 모든 과정이 사용자는 의식하지 못하는 사이에 수백 ms~몇 초 내에 이루어져서, 결과적으로 영상/음성이 실시간으로 양쪽에 전달되는 것입니다.

Q: STUN과 TURN 서버는 무엇이며, WebRTC에서 왜 필요한가요?

A: STUN/TURN은 WebRTC의 NAT 문제 해결을 위해 쓰이는 두 가지 핵심 서버입니다:
STUN (Session Traversal Utilities for NAT): 말 그대로 NAT를 통과하기 위한 도구입니다. 클라이언트의 공인 IP 주소를 알려주는 서버로 이해할 수 있습니다. 내부 망(사설 IP)에 있는 기기가 STUN 서버에 요청을 보내면, STUN 서버는 해당 요청이 보낸 공인 IP와 포트 번호를 응답으로 돌려줍니다. WebRTC 피어는 이 정보를 받아 "내가 밖에서 보이는 주소는 X다"를 알아내고 이를 ICE 후보로 상대에게 제공합니다. 상대는 이 공인 주소로 연결을 시도함으로써, NAT를 뚫고 직접 통신할 가능성을 높입니다. (대부분의 NAT 환경에서 STUN 응답으로 받은 주소를 사용하면 P2P 연결이 성립될 수 있습니다.)

TURN (Traversal Using Relays around NAT): 미디어 릴레이용 서버입니다. 최악의 경우 두 피어 모두 방화벽/NAT 제약이 심해 직접 연결이 불가능할 때 쓰이는 우회로입니다. 한 피어가 TURN 서버에 먼저 연결을 맺고, 다른 피어도 같은 TURN 서버에 연결한 뒤, TURN이 양쪽 데이터를 중계해주는 방식입니다. 쉽게 말해, 두 클라이언트가 모두 접속해있는 Proxy 서버 역할을 하는 셈입니다. WebRTC에서는 가급적 TURN을 쓰지 않고 바로 연결하려 하지만, 연결 실패 대비 안전장치로 항상 TURN 후보를 함께 제공합니다. TURN 서버를 쓰면 지연이 증가하고 서버 트래픽 비용이 발생하지만, 방화벽을 넘어 통신을 가능하게 하는 유일한 방법일 때가 있어 중요합니다.

요약하면 STUN은 "내 외부 주소를 알아내는 용도", TURN은 "직접 연결이 안 될 때 대신 전달해주는 용도" 입니다. 둘 다 WebRTC의 원활한 P2P 통신을 위해 필수적인 인프라입니다. (실제로 많은 상용 WebRTC 서비스들은 안정적인 연결을 위해 자체 TURN 서버까지 운영합니다.)

Q: WebRTC와 RTMP, HLS/DASH 같은 다른 스트리밍 기술의 차이는 무엇인가요?

A: 실시간 통신/스트리밍을 구현하는 여러 기술이 있으며, WebRTC, RTMP, HLS/DASH는 각각 특징과 용도가 다릅니다.

WebRTC: 양방향 실시간 통신에 최적화된 기술입니다. 지연이 매우 낮아 (일반적으로 200ms 이내 수준) 화상회의, 라이브 채팅처럼 인터랙티브한 사용 사례에 적합합니다. P2P 전송(또는 SFU 서버 경유)으로 작동하고, 브라우저에서 플러그인 없이 동작하며 보안이 기본 내장되어 있습니다. 다만 Signaling 서버 등 초기 설정이 필요하고, 대규모 일대다 방송에는 부하가 커지는 단점이 있습니다.

RTMP: Real-Time Messaging Protocol로 과거 플래시 기반으로 많이 쓰인 실시간 스트리밍 업로드 프로토콜입니다. 주로 방송 송출자가 미디어 서버로 영상 스트림을 전송할 때 사용합니다(예: OBS 소프트웨어가 RTMP로 YouTube/Twitch 서버에 업로드). 지연은 비교적 낮아서 1~2초 내외로 가능하지만, 브라우저 표준이 아니어서 Flash나 별도 라이브러리가 필요했습니다. 현재는 방송 업로드 용도로 제한적으로 쓰이고, 시청자에게 직접 전달하는 프로토콜은 아닙니다. (대부분 RTMP 스트림은 서버에서 HLS 같은 포맷으로 변환되어 배포됩니다.)

HLS/DASH: HTTP Live Streaming(Apple)과 MPEG-DASH는 HTTP 기반 적응형 스트리밍 프로토콜입니다. 동영상 파일을 수 초 단위 조각으로 쪼개서 웹서버/CDN으로 전달하고, 클라이언트는 순차적으로 이를 다운로드&재생합니다. 지연 시간이 길어서 보통 5초~30초까지도 허용되지만, 대규모 동시 시청에 매우 강합니다. 전세계 CDN을 통해 수십만 명에게도 안정적으로 스트림 전송이 가능하므로, 일방향 대규모 라이브 방송이나 VOD 서비스에 활용됩니다. WebRTC보다 실시간 상호작용성은 떨어지지만, 높은 품질과 안정성으로 많은 시청자를 처리할 수 있습니다.

이외에도 Zoom/Agora SDK 같은 상용 솔루션은 WebRTC와 유사하게 낮은 지연을 달성하지만, 자체 네트워크와 프로토콜을 통해 최적화된 서비스를 제공합니다. 예를 들어 Zoom이나 Discord는 내부적으로 WebRTC 기술을 사용하면서도, SFU/MCU 미디어 서버를 두어 다자간 통화를 효율적으로 처리합니다. 이러한 솔루션은 별도의 SDK/앱 설치가 필요하지만, 대규모 그룹 통화도 낮은 지연으로 비교적 안정적으로 제공하는 것이 특징입니다.

Q: 수천 명이 보는 대규모 라이브 방송에 WebRTC가 잘 사용되지 않는 이유는 무엇인가요?

A: WebRTC는 소규모 실시간 상호작용에 뛰어나지만, 대규모 방송(일대다) 에는 제약이 있습니다. 주요 이유는 확장성 문제인데, 세부적으로 보면.

P2P의 구조적 한계: WebRTC의 기본 P2P 메시는 참여자 수가 늘어날수록 기하급수적으로 연결 수와 대역폭 부담이 증가합니다. 1:1은 P2P가 최적이지만, 스트리머 1명과 시청자 1000명을 P2P로 직접 연결하는 것은 불가능합니다. 시청자가 많으면 각 시청자와의 P2P 세션을 1000개 맺을 수도 없고, 스트리머 쪽도 업로드를 1000번 해야 하므로 현실적으로 불가능합니다.

SFU/MCU로도 한계 존재: 다자간을 위해 SFU나 MCU 같은 미디어 서버를 도입할 수 있지만, 이 역시 서버 측에 부하가 집중됩니다. 예를 들어 SFU는 스트리머로부터 영상 한 스트림을 받아 수천 명에게 복제해 뿌려야 하는데, 이는 사실상 방송국 서버 역할을 하는 것이어서 CDN 없이는 버티기 어렵습니다. MCU 방식 (서버에서 믹싱)도 마찬가지로 서버에 과부하가 걸리고 비용이 매우 높습니다.

CDN 활용 불가: WebRTC는 양방향 실시간 통신을 지향하기 때문에, HLS처럼 전세계 CDN 캐시를 활용하는 구조와 거리가 멉니다. 일대다 방송에서는 동일한 콘텐츠를 많은 사람에게 전달하는데, WebRTC는 각 대상에게 개별 스트림을 전송하므로 비효율적입니다. 반면 HLS/DASH는 HTTP 기반이라 CDN이 각 지역에서 스트림 조각을 캐싱하여 수십만 동시접속자도 분산 처리할 수 있습니다. WebRTC는 이러한 대규모 분산 전송에 최적화되어 있지 않습니다.

실시간성 vs 규모 트레이드오프: 결국 몇 초 지연을 감수하면 HLS/DASH+CDN으로 안정적 방송이 가능하고, 지연을 줄이면 WebRTC로 소규모는 가능하지만 대규모는 어려운 트레이드오프가 있습니다. 그래서 유튜브 라이브, 트위치 같은 플랫폼은 약간의 지연을 허용하고라도 HTTP 스트리밍을 채택합니다. 반면 화상회의나 소규모 인터랙티브 세션은 WebRTC를 사용합니다. 대규모 방송에서는 WebRTC가 잘 쓰이지 않는 이유는 이처럼 확장성과 비용 문제 때문입니다.

Q: SFU와 MCU는 무엇이며, WebRTC에서 어떻게 활용되나요

?
A: SFU(Selective Forwarding Unit)와 MCU(Multipoint Control Unit)는 WebRTC 다자간 통화를 가능하게 하는 서버 측 미디어 처리 방식입니다. P2P 메시는 소규모에 한정되므로, 3명 이상 다자 통화에서는 보통 SFU나 MCU 구조를 사용해 확장합니다.

SFU (선택적 포워딩 유닛): 일종의 패킷 라우터 역할을 하는 경량 미디어 서버입니다. 각 참가자가 자신의 영상/음성 스트림을 SFU 서버로 보내면, SFU는 이를 다른 참가자들에게 전달만 합니다. 혼합(mixing) 은 하지 않고, 필요에 따라 특정 참가자의 영상만 선별하여 보낼 수도 있습니다. 예를 들어 5명이 있으면, SFU는 각 사람이 보낸 5개의 스트림을 받아서 각 클라이언트에게 자기 제외 4개 스트림을 그대로 포워딩합니다. SFU는 스트림을 디코딩/인코딩하지 않기 때문에 지연이 매우 낮고, 서버 부하도 비교적 적습니다 (단순 포워딩). 다만 각 클라이언트는 동시에 여러 개의 원본 스트림을 받아 처리해야 하므로 클라이언트 측 부하는 조금 증가할 수 있습니다.

WebRTC 기반 화상회의 솔루션 대부분은 SFU 방식을 선호하며, Zoom/Google Meet/Discord 등이 SFU를 활용해 대규모 그룹 통화를 구현하고 있습니다 (필요 시 화자만 전송, 해상도 조절 등 최적화도 가능).

MCU (멀티포인트 컨트롤 유닛): 일종의 중앙 미디어 믹서 서버입니다. 모든 참가자의 영상을 서버로 보내면, 서버가 이를 디코딩해서 한 화면으로 합성하거나 오디오도 믹싱하여 단일 스트림으로 인코딩합니다. 그리고 그 하나로 합쳐진 스트림을 다시 모든 참가자에게 송출합니다. 이렇게 하면 각 참가자는 하나의 스트림만 처리하면 되므로 클라이언트 부하는 최소화됩니다. 그러나 서버가 모든 혼합 연산을 담당하므로 CPU/GPU 등 자원 소모가 매우 크고, 보통 지연 시간도 증가합니다 (인코딩/디코딩 지연). 또한 각 참가자별로 개별화된 영상 배치가 어렵고 일률적인 합성 화면을 받게 됩니다. MCU는 과거 회의 시스템이나 하드웨어 단말기 등에서 사용되었으며, 현대 웹 서비스에서는 잘 쓰지 않지만 특정 상황(예: 저성능 기기 지원, 녹화용 믹싱)에 쓰이기도 합니다.

정리: SFU는 필요 최소한의 중계로 다자간 연결을 효율화하는 방식이고, MCU는 중앙에서 다 처리해서 보내주는 방식입니다. WebRTC 다자간 통화에서는 대체로 SFU가 표준적 선택이며, 지연이 낮고 확장성이 우수합니다. MCU는 서버 비용과 지연이 커 잘 안 쓰지만, 모든 부하를 서버가 떠안는 대신 클라이언트를 아주 경량화해야 할 때 선택됩니다.

Q: 마이크로서비스 아키텍처(MSA)란 무엇이며, WebRTC 기반 서비스를 설계한다면 MSA를 어떻게 구성하는 것이 좋을까요?

A: 마이크로서비스 아키텍처 (Microservice Architecture) 는 하나의 애플리케이션을 기능 별로 작은 서비스 단위로 분리하여 구성하는 설계 방식입니다. 각 마이크로서비스는 독립적으로 배포되고 자율적으로 운영될 수 있으며, 다른 서비스들과 가벼운 통신(API) 으로 협력합니다. 이를 통해 유연한 확장성과 변경 용이성을 얻을 수 있고, 한 부분의 문제가 전체 시스템으로 전파되는 위험을 줄입니다. WebRTC 기반의 실시간 통신 서비스에 MSA를 적용한다면, 다음과 같이 역할별로 서비스들을 분리하여 설계하는 것이 좋습니다.

🗣️ 시그널링 서비스: WebRTC 피어 간 연결 설정(offer/answer 교환, ICE 후보 교환 등)을 담당하는 Signaling Server를 하나의 마이크로서비스로 구성합니다. 이 서비스는 예를 들어 WebSocket 서버로 구현하여 SDP 및 ICE 정보를 중계하는 역할을 합니다. 무상태(stateless) 로 설계하여 다수 인스턴스를 로드밸런싱으로 확장 가능하게 만들고, 장애 시 다른 인스턴스로 대체되도록 합니다. (이 서비스는 세션 제어만 담당하고 미디어는 취급하지 않으므로 비교적 가볍게 확장할 수 있습니다.)

🌐 STUN/TURN 서비스: NAT 트래버설 및 릴레이를 담당하는 STUN/TURN 서버들을 별도의 마이크로서비스(또는 인프라 서비스)로 둡니다. 예를 들어 Coturn과 같은 TURN 서버를 사용한다면, 이를 독립적인 배포 단위로 운영합니다. 이들은 네트워크 경계에 위치시켜 전세계 여러 리전에 분산 배치하고, 클라이언트 가까운 곳에서 STUN 응답이나 TURN 릴레이가 이뤄지도록 설계할 수 있습니다. (TURN은 트래픽이 많이 몰릴 수 있으므로 수평 확장이 용이하게 구성하고, 별도의 모니터링으로 부하 상태를 관리하는 것이 좋습니다

🎥 미디어 처리 서비스 (SFU/미디어 서버): 다자간 통화나 방송 기능이 필요하다면 미디어 서버(SFU 또는 MCU) 를 운영해야 합니다. 이를 마이크로서비스로 별도 구성하여, 필요에 따라 여러 대를 띄워 규모 확장할 수 있게 합니다. 예를 들어 SFU 서버 풀을 구성하고, 새로운 화상채팅 방이 열릴 때마다 가용한 SFU 인스턴스에 할당하는 식입니다. SFU 서버 자체(예: Jitsi Videobridge, mediasoup, Janus 등)는 고성능이 요구되므로, 다른 서비스와 격리하여 전용 인스턴스로 배포하고 관리합니다. 또한 SFU 간 부하 분산이나 참가자 라우팅을 위해 신호 서버와 협조가 필요하므로, 이러한 조정 로직을 별도 서비스로 둘 수도 있습니다. (예: 방 관리 서비스가 방ID를 기반으로 어느 SFU에 연결할지 결정해주는 등.)

📑 웹/애플리케이션 API 서비스: WebRTC 기반 어플리케이션의 일반 백엔드 로직 (예: 사용자 관리, 인증/인가, 채팅 메시지 저장, 친구 목록 등)은 별도의 마이크로서비스로 구성합니다. 예컨대 인증 서비스, 프로필/관계 관리 서비스, 채팅 서비스 등을 도메인 별로 분리할 수 있습니다. 이들은 REST API나 gRPC 등의 형태로 제공되어, 프런트엔드나 시그널링 서버 등이 필요 시 호출하도록 설계합니다. 이렇게 분리하면, 미디어 전송과 무관한 일반 애플리케이션 기능도 독립적으로 개발 및 스케일 아웃이 가능합니다.

📊 모니터링 및 기타 서비스: 실시간 품질을 추적하기 위한 QoS 모니터링 서비스, 통화 기록이나 녹화를 위한 기록/저장 서비스, 알림을 위한 푸시 서비스 등 부가 요소들도 각각 마이크로서비스로 만들 수 있습니다. 예를 들어 통화 중 발생하는 네트워크 통계나 오류 로그를 수집해 분석하는 서비스가 따로 있을 수 있고, 녹화가 필요하면 SFU와 연동하는 Recording 서비스를 분리하여 운영할 수 있습니다.

이처럼 MSA 구성을 하면, 각 서비스가 자신의 역할에 집중하고 독립적으로 배포/확장될 수 있습니다. 예를 들어 접속자가 증가할 때 시그널링 서버는 많아질 signaling 요청에 맞춰 별도 확장하고, SFU 서버는 미디어 부하에 맞춰 확충하는 식입니다. 한 컴포넌트에 장애가 발생해도 시스템 전체가 다운되지 않게 격리되며, 업데이트도 부분적으로 수행할 수 있어 개발 민첩성도 높아집니다.

요약: WebRTC 서비스에 MSA를 적용한다면, Signaling, STUN/TURN, Media(SFU), 일반 API 백엔드 등을 모듈별 마이크로서비스로 분리합니다. 이렇게 함으로써 실시간 통신 시스템도 다른 대규모 서비스처럼 유연한 확장성과 안정성을 확보할 수 있습니다. (물론 초기에는 단순히 모놀리식으로 시작해도 되지만, 규모가 커질수록 이런 분리가 필요해집니다.)