WebRTC란? 2026년 개발자 완벽 가이드
브라우저에서 아무것도 설치하지 않고 화상 통화에 참여한 적이 있다면, WebRTC를 사용한 것입니다. 두 브라우저가 지구 반대편에서 어떻게 서브초 지연으로 비디오를 스트리밍할 수 있는지 궁금해 본 적이 있다면 -- 플러그인 없이, Flash 없이, Java 애플릿 없이 -- 이 가이드는 당신을 위한 것입니다.
WebRTC(Web Real-Time Communication)는 브라우저와 모바일 앱이 실시간으로 피어 투 피어 방식으로 오디오, 비디오 및 임의의 데이터를 교환할 수 있도록 하는 오픈소스 프레임워크입니다. Google은 2011년에 초기 코드를 공개했고, W3C는 2021년에 표준화했으며, 2026년까지는 Zoom 스타일의 회의부터 AI 음성 에이전트, 원격 의료 플랫폼까지 모든 것을 지원합니다. 글로벌 WebRTC 시장은 올해 108억 9천만 달러에 도달할 것으로 예상되며, 2034년까지 약 37%의 CAGR을 유지할 것입니다.
저는 여러 해 동안 여러 프로덕션 앱에 WebRTC 기반 기능을 구축했으며, 다음을 말씀드립니다: 프로토콜은 우아하고, API는 놀랍도록 접근하기 쉽지만, 엣지 케이스는 당신을 겸손하게 만들 것입니다. 모든 것을 파고들어봅시다.
목차
- WebRTC는 실제로 무엇인가
- WebRTC의 내부 작동 방식
- 세 가지 핵심 API
- 신호화: WebRTC가 처리하지 않는 부분
- NAT 통과: STUN, TURN, ICE
- WebRTC의 보안
- 2026년 WebRTC 사용 사례
- 2026년의 새로운 것
- WebRTC와 대안 비교
- WebRTC로 구축하기: 라이브러리 및 플랫폼
- 일반적인 함정 및 어려운 교훈
- FAQ
WebRTC는 실제로 무엇인가
핵심적으로 WebRTC는 두 엔드포인트(일반적으로 브라우저)가 직접 연결을 설정하고 미디어 또는 데이터를 교환할 수 있도록 하는 JavaScript API 및 기본 네트워크 프로토콜 세트입니다. 이상적인 경우 서버가 미디어 경로의 중간에 앉지 않습니다. 플러그인이 없습니다. 다운로드가 없습니다.
"실시간" 부분이 중요합니다. 초 단위가 아닌 밀리초 단위로 측정된 지연을 이야기하고 있습니다. 기존의 HTTP 기반 스트리밍(HLS, DASH)은 일반적으로 3-30초의 지연을 도입합니다. WebRTC는 이를 500ms 미만으로, 종종 200ms 미만으로 줄입니다. 이는 대화와 무전기로 말하는 것의 차이입니다.
WebRTC는 2026년 모든 주요 브라우저에서 지원됩니다:
| 브라우저 | WebRTC 지원 | 참고 |
|---|---|---|
| Chrome | 완전 | 참조 구현 |
| Firefox | 완전 | 강력한 DataChannel 지원 |
| Safari | 완전 | 2020년 이후 큰 개선 |
| Edge | 완전 | Chromium 기반, Chrome 미러 |
| Brave | 완전 | Chromium 기반 |
| Mobile Chrome/Safari | 완전 | iOS는 역사적으로 문제가 있었지만 대부분 해결됨 |
브라우저 외부에서도 사용 가능합니다. iOS, Android, C++, Rust 및 Python용 네이티브 라이브러리가 존재합니다. VoIP 앱, 드론 제어 시스템 또는 IoT 데이터 파이프라인을 구축하는 경우 WebRTC도 작동합니다.
WebRTC의 내부 작동 방식
WebRTC를 처음 접했을 때 실제로 이해하는 데 도움이 된 정신 모델입니다.
두 사람이 전화 통화를 하려고 하지만 서로 전화번호를 모르고 둘 다 잠긴 문(NAT 및 방화벽) 뒤에 있다고 상상해보세요. 그들은 상호 친구(신호 서버)가 번호를 교환해야 합니다. 서로의 정보를 가지면, 그들은 직접 대화합니다 -- 상호 친구는 더 이상 관여하지 않습니다.
기술적 흐름은 다음과 같습니다:
1. 미디어 캡처
브라우저는 getUserMedia()를 통해 사용자의 카메라와 마이크에 액세스할 권한을 요청합니다. 이는 MediaStream 객체를 반환합니다.
2. 신호화(대역외)
두 피어가 연결하기 전에 연결 메타데이터를 교환해야 합니다: 지원하는 코덱, 네트워크 주소, 보안 지문. 이 교환을 신호화라고 하며, WebRTC는 의도적으로 발생 방식을 지정하지 않습니다. WebSocket, HTTP 폴링, 비둘기 우편 -- 작동하는 것이면 무엇이든 됩니다.
신호 교환에는 두 가지 유형의 메시지가 포함됩니다:
- SDP(Session Description Protocol): 피어가 보내기/받기를 원하는 미디어와 방법을 설명합니다
- ICE 후보자: 피어에 도달할 수 있는 네트워크 주소
3. 연결 설정(ICE)
ICE(Interactive Connectivity Establishment) 프레임워크는 피어를 연결하는 여러 경로를 시도합니다. 먼저 직접 연결을 시도한 다음 STUN 서버를 사용하여 공인 IP를 발견하고, 피어 투 피어가 실패하면 TURN 릴레이 서버로 폴백합니다.
4. 보안 미디어 흐름
연결되면 미디어는 DTLS 및 SRTP로 암호화된 피어 간에 직접 흐릅니다. 암호화되지 않은 WebRTC 연결은 허용되지 않습니다 -- 이는 명세에 의해 필수입니다.
세 가지 핵심 API
WebRTC는 JavaScript에 세 가지 주요 API를 노출합니다. 이들을 이해하는 것이 전투의 80%입니다.
getUserMedia()
사용자의 장치에서 오디오 및 비디오를 캡처합니다.
// 기본 카메라 + 마이크 접근
const stream = await navigator.mediaDevices.getUserMedia({
video: {
width: { ideal: 1280 },
height: { ideal: 720 },
frameRate: { ideal: 30 }
},
audio: {
echoCancellation: true,
noiseSuppression: true
}
});
// 비디오 요소에 첨부
document.getElementById('localVideo').srcObject = stream;
getDisplayMedia()를 사용하여 화면 공유를 얻을 수도 있습니다:
const screenStream = await navigator.mediaDevices.getDisplayMedia({
video: { cursor: 'always' },
audio: true // 시스템 오디오, 브라우저 지원은 다양함
});
RTCPeerConnection
이것은 워크호스입니다. 피어 연결의 전체 생명 주기를 관리합니다: 코덱 협상, ICE 후보자 수집, DTLS 핸드셰이크, 대역폭 추정, 패킷 손실 복구.
const config = {
iceServers: [
{ urls: 'stun:stun.l.google.com:19302' },
{
urls: 'turn:turn.yourserver.com:3478',
username: 'user',
credential: 'pass'
}
]
};
const pc = new RTCPeerConnection(config);
// 로컬 트랙 추가
stream.getTracks().forEach(track => pc.addTrack(track, stream));
// 원격 피어의 들어오는 트랙 처리
pc.ontrack = (event) => {
document.getElementById('remoteVideo').srcObject = event.streams[0];
};
// 오퍼 생성(발신자 측)
const offer = await pc.createOffer();
await pc.setLocalDescription(offer);
// 신호 서버를 통해 원격 피어로 오퍼 보내기
// 다른 쪽에서는 오퍼를 받고 답변을 생성합니다
await pc.setRemoteDescription(receivedOffer);
const answer = await pc.createAnswer();
await pc.setLocalDescription(answer);
// 신호를 통해 답변을 다시 보냅니다
RTCDataChannel
이것은 충분한 주목을 받지 못합니다. DataChannel을 사용하면 피어 간에 임의의 데이터를 보낼 수 있습니다 -- 텍스트, 이진, 파일, 게임 상태, 무엇이든. SCTP를 기반으로 하므로 정렬된/정렬되지 않은 전달 및 신뢰할 수 있는/신뢰할 수 없는 전송 옵션이 있습니다.
const dataChannel = pc.createDataChannel('chat', {
ordered: true // 메시지 순서 보장
});
dataChannel.onopen = () => {
dataChannel.send('Hello from peer A!');
};
dataChannel.onmessage = (event) => {
console.log('Received:', event.data);
};
// 원격 피어에서
pc.ondatachannel = (event) => {
const channel = event.channel;
channel.onmessage = (e) => console.log('Got:', e.data);
};
DataChannel을 실시간 협업 편집, 멀티플레이어 게임 상태 동기화 및 대용량 파일 전송에 사용했습니다. 데이터가 서버를 통해 라우팅되지 않기 때문에 지연은 WebSocket보다 훨씬 낮습니다.
신호화: WebRTC가 처리하지 않는 부분
처음에는 모든 개발자를 당황하게 합니다. WebRTC는 미디어 발견이 아니라 미디어 전송을 위한 프로토콜입니다. 두 피어는 도움 없이 서로를 찾을 수 없습니다.
다음을 수행하는 신호 서버를 구축(또는 사용)해야 합니다:
- 피어가 자신의 존재를 등록할 수 있도록 합니다
- 피어 간 SDP 오퍼 및 답변을 전달합니다
- ICE 후보자를 릴레이합니다
대부분의 팀은 신호화에 WebSocket을 사용합니다. 최소한의 Node.js 예제는 다음과 같습니다:
// 서버(ws 라이브러리 사용)
const WebSocket = require('ws');
const wss = new WebSocket.Server({ port: 8080 });
const rooms = new Map();
wss.on('connection', (ws) => {
ws.on('message', (data) => {
const msg = JSON.parse(data);
if (msg.type === 'join') {
rooms.set(msg.roomId, [...(rooms.get(msg.roomId) || []), ws]);
}
if (['offer', 'answer', 'ice-candidate'].includes(msg.type)) {
// 방의 다른 피어로 전달
const peers = rooms.get(msg.roomId) || [];
peers.forEach(peer => {
if (peer !== ws && peer.readyState === WebSocket.OPEN) {
peer.send(JSON.stringify(msg));
}
});
}
});
});
신호 서버는 반드시 실행해야 하는 유일한 서버입니다. 연결이 설정되면 사라질 수 있습니다(재연결 시나리오를 위해 주변에 있으면 좋습니다).
NAT 통과: STUN, TURN, ICE
이것은 WebRTC가 까다로워지는 지점입니다. 대부분의 장치는 NAT(Network Address Translation) 뒤에 있으므로 로컬 IP 주소를 인터넷에서 도달할 수 없습니다. WebRTC는 이 문제를 해결하기 위해 3계층 접근 방식을 사용합니다:
STUN(Session Traversal Utilities for NAT): 브라우저에 "여기 공인 IP와 포트"를 알려주는 가벼운 서버입니다. Google은 무료 STUN 서버(stun:stun.l.google.com:19302)를 운영합니다. STUN은 빠르고, 저렴하며, 약 80-85%의 시간에 작동합니다.
TURN(Traversal Using Relays around NAT): 직접 피어 투 피어가 실패할 때(대칭 NAT, 엄격한 방화벽) TURN은 미디어 릴레이로 작동합니다. 모든 트래픽은 TURN 서버를 통해 흐릅니다. 이는 100% 작동하지만 대역폭을 소비하고 지연을 추가합니다. 프로덕션 앱에 대해 자신의 TURN 서버를 실행하는 것은 필수입니다. Coturn은 표준 오픈소스 옵션입니다.
ICE(Interactive Connectivity Establishment): STUN과 TURN을 조율하는 프레임워크입니다. ICE는 후보자 주소(로컬, STUN을 통한 서버 반사적, TURN을 통한 릴레이)를 수집하고 작동하는 최고의 경로를 찾기 위해 체계적으로 테스트합니다.
제 경험상, 프로덕션의 약 15-20%의 연결이 TURN을 통해 진행됩니다. 회사 방화벽이 가장 큰 원인입니다. TURN 서버 비용을 예산으로 편성합니다 -- 선택 사항이 아닙니다.
WebRTC의 보안
WebRTC는 기본적으로 안전하여 신선합니다. 다음이 기본 제공됩니다:
- DTLS(Datagram Transport Layer Security): 모든 데이터 채널을 암호화합니다. UDP용 TLS를 생각하세요.
- SRTP(Secure Real-time Transport Protocol): 모든 미디어 스트림을 암호화합니다.
- 필수 암호화: 정말로 암호화되지 않은 WebRTC 연결을 설정할 수 없습니다. 명세가 이를 금지합니다.
- 권한 프롬프트: 브라우저는 카메라 또는 마이크에 액세스하기 전에 명시적 사용자 동의를 요구합니다.
- 원점 격리: 웹 페이지는 보안 원점(HTTPS)에서만 WebRTC API에 액세스할 수 있습니다.
"암호화 비활성화" 플래그가 없습니다. 안전하지 않은 폴백이 없습니다. 이것은 의도적인 설계 선택이며, 좋은 것입니다.
즉, 신호 서버는 잠재적 취약점입니다. 누군가 신호를 손상시키면 연결을 악의적 피어로 리디렉션할 수 있습니다. 인증된 WebSocket 연결을 사용하고 서버 측에서 모든 것을 검증합니다.
2026년 WebRTC 사용 사례
명백한 사용 사례는 화상 통화이지만, WebRTC는 그것을 훨씬 넘어 확산되었습니다.
화상 회의
Zoom, Google Meet, Microsoft Teams 및 수십 개의 더 작은 플레이어 모두 WebRTC(또는 기본 프로토콜의 수정된 버전)를 사용합니다. 다중 당사자 통화의 경우, 대부분의 플랫폼은 순수 피어 투 피어 대신 SFU(Selective Forwarding Unit) 아키텍처를 사용합니다 -- 아래에서 자세히 설명합니다.
AI 음성 에이전트
2026년 가장 빠르게 성장하는 사용 사례입니다. Vapi, Retell 및 Bland.ai와 같은 회사는 WebRTC를 사용하여 사용자와 AI 모델 간 오디오를 실시간으로 전송합니다. 서브 200ms 지연은 중요합니다 -- 더 많은 지연이 있으면 대화가 부자연스러워집니다.
원격 의료
원격 의사 방문은 COVID 기간에 폭발했고 사라지지 않았습니다. WebRTC는 소프트웨어 설치가 필요 없는 HIPAA 호환 암호화 비디오를 제공합니다.
라이브 쇼핑 및 브로드캐스팅
라이브 상거래를 위한 초저지연 스트리밍입니다. 시청자는 제품 시연을 실시간으로 보고 즉시 상호작용할 수 있습니다. 기존 스트리밍 프로토콜은 너무 많은 지연을 추가합니다.
고객 지원
지원 위젯에 직접 내장된 화면 공유 및 화상 채팅입니다. 고객은 아무것도 다운로드하지 않습니다. 에이전트는 문제를 실시간으로 봅니다.
IoT 및 드론
DataChannel은 엣지 장치에 제어 명령을 보내고 원격 측정을 받는 데 탁월합니다. WebRTC에 기본 제공되는 NAT 통과는 IoT 개발자가 수동으로 처리해야 하는 많은 문제를 해결합니다.
2026년의 새로운 것
WebRTC는 정지해 있지 않습니다. 몇 가지 중요한 발전이 현재 우리가 이를 사용하는 방식을 형성하고 있습니다.
AI 통합이 모든 곳에 있습니다
실시간 음성 인식, 실시간 번역, ML 모델로 구동되는 배경 소음 억제, 통화 중 감정 분석 -- 이 모든 것은 WebRTC의 저지연 전송에 달려 있습니다. WebRTC 인프라와 대규모 언어 모델의 수렴은 아마도 올해 실시간 통신의 가장 큰 추세일 것입니다.
WebTransport 및 WebCodecs
WebTransport(HTTP/3 및 QUIC를 기반으로 함)는 일부 스트리밍 시나리오에서 대체 전송 계층을 제공합니다. WebRTC를 대체하는 것이 아닙니다 -- 피어 투 피어 또는 NAT 통과를 처리하지 않습니다 -- 하지만 인코딩에 대한 더 많은 제어를 원할 때 서버 대 클라이언트 스트리밍에 강한 보완입니다.
WebCodecs는 개발자에게 브라우저의 미디어 파이프라인을 우회하는 하드웨어 비디오 인코더 및 디코더에 직접 액세스할 수 있습니다. WebRTC의 Insertable Streams API와 결합하면 이것은 훨씬 더 나은 성능으로 사용자 정의 비디오 처리(종단 간 암호화, AR 필터)를 사용할 수 있습니다.
확장 가능한 비디오 코딩(SVC)
SVC 지원은 크게 성숙했습니다. VP9 SVC 및 AV1 SVC와 같은 인코더를 사용하면 단일 인코딩된 스트림이 여러 품질 수준을 제공할 수 있으며, 이는 SFU 기반 아키텍처에 엄청났습니다. 3개의 별도 품질 스트림을 인코딩하는 대신(시뮬캐스트) 한 번 인코딩하면 SFU는 각 수신자의 대역폭에 따라 계층을 제거합니다.
WHIP 및 WHEP
WebRTC-HTTP Ingestion Protocol(WHIP) 및 WebRTC-HTTP Egress Protocol(WHEP)은 WebRTC가 미디어 서버에 연결하는 방식을 표준화합니다. 이러한 프로토콜 이전에는 모든 미디어 서버가 자체 독점 신호를 가지고 있었습니다. WHIP/WHEP은 생태계에 건전성을 가져옵니다.
WebRTC와 대안 비교
WebRTC는 다른 실시간 통신 기술과 비교하여 어디에 적합합니까?
| 기술 | 지연 | 방향 | NAT 통과 | 브라우저 지원 | 최적 용도 |
|---|---|---|---|---|---|
| WebRTC | < 500ms | P2P 또는 SFU를 통해 | 기본 제공(ICE) | 모든 주요 브라우저 | 화상 통화, 실시간 상호작용 |
| HLS | 3-30s | 서버 → 클라이언트 | N/A | 보편적 | VOD, 대규모 청중으로 라이브 스트리밍 |
| DASH | 3-30s | 서버 → 클라이언트 | N/A | 대부분의 브라우저 | 적응형 비트레이트 VOD |
| WebSocket | ~50ms(데이터만) | 클라이언트 ↔ 서버 | 아니요 | 모든 주요 브라우저 | 채팅, 알림, 실시간 데이터 |
| WebTransport | ~50ms | 클라이언트 ↔ 서버 | 아니요 | Chrome, Firefox, Edge | 저지연 서버 스트리밍 |
| RTMP | 1-5s | 클라이언트 → 서버 | 아니요 | 플레이어 필요 | 스트리밍 플랫폼으로 수집 |
| SRT | 0.5-2s | 포인트 간 | 제한적 | 앱 필요 | 브로드캐스트 기여 |
핵심 구분: WebRTC는 피어 투 피어를 수행하는 유일한 브라우저 네이티브 옵션이며 기본 제공 NAT 통과 및 필수 암호화가 있습니다. 브라우저에서 실시간 양방향 통신이 필요하면 여전히 답변입니다.
WebRTC로 구축하기: 라이브러리 및 플랫폼
원본 브라우저 API를 사용하여 처음부터 모든 것을 구축할 수 있습니다. 저는 그렇게 했습니다. 깊은 전문성과 특정 이유가 없는 한 프로덕션에서는 권장하지 않습니다.
2026년에 중요한 도구들입니다:
미디어 서버(SFU)
- LiveKit: 오픈소스, Go로 구축, 탁월한 개발자 경험. 대부분의 프로젝트에 대한 현재 권장. SFU 아키텍처, 시뮬캐스트, 데이터 채널을 지원하며 모든 주요 플랫폼용 SDK가 있습니다.
- Janus: 성숙한 C 기반 미디어 서버. 매우 유연하지만 저수준. 더 많은 코드를 작성해야 합니다.
- mediasoup: Node.js 기반 SFU. JavaScript 생태계에 사는 팀에 좋습니다.
- Pion: Go의 WebRTC 구현. 완전한 미디어 서버는 아니지만 사용자 정의 WebRTC 인프라를 구축하는 데 매우 유용합니다.
CPaaS 플랫폼
- Twilio: 800파운드의 고릴라. 광범위한 API, 좋은 문서, 프리미엄 가격책정.
- Agora: 아시아 태평양에서 강함, 좋은 SDK 품질.
- Daily.co: 개발자 친화적, 깔끔한 API, 합리적인 가격책정.
- Vonage(이전 Tokbox): 견고함, 오래전부터 존재.
구축 대 구매 시점
비디오가 기능인 제품을 구축하는 경우(예: 지원 대시보드에 화상 채팅 추가), CPaaS 또는 LiveKit을 사용합니다. 비디오가 제품이면 더 많은 제어가 필요하며 자신의 SFU 인프라 실행을 고려해야 합니다.
Next.js 또는 Astro와 같은 프레임워크로 구축된 웹 애플리케이션의 경우, LiveKit의 React SDK와 같은 라이브러리를 통해 WebRTC를 통합하는 것은 간단합니다. 우리는 헤드리스 CMS 기반 사이트에 실시간 비디오 기능을 통합했습니다 -- 분리된 아키텍처는 실제로 프론트엔드 프레임워크가 UI를 처리하는 동안 WebRTC가 미디어 전송을 독립적으로 처리하므로 더 쉽게 만듭니다.
일반적인 함정 및 어려운 교훈
여러 WebRTC 애플리케이션을 구축한 후, 다음이 누군가가 나에게 일찍 말씀해주었으면 하는 것입니다:
항상 TURN 서버를 배포합니다. "테스트에서는 문제없이 작동한다"고 말하는 개발자를 봤습니다. 테스트 장치가 동일한 네트워크에 있기 때문에 작동합니다. 프로덕션에서는 15-20%의 사용자가 제한적인 NAT 또는 방화벽 뒤에 있을 것입니다. TURN 없이는 이 사용자들은 단순히 연결할 수 없습니다.
연결 끊김을 적절히 처리합니다. 네트워크 조건은 끊임없이 변합니다. 앱은 연결 끊김을 감지하고, 재연결을 시도하며, 사용자에게 알리는 것이 필요합니다 -- 모두 애플리케이션 상태를 잃지 않고. iceconnectionstatechange 이벤트가 당신의 친구입니다.
대역폭 추정은 어렵습니다. WebRTC에는 기본 제공 대역폭 추정이 있지만 마법은 아닙니다. 혼잡한 네트워크에서 비디오 품질은 저하됩니다. getStats()를 사용하여 연결 품질을 모니터링하고 UI를 조정합니다 -- 아마도 "연결 상태 나쁨" 표시기를 표시하거나 오디오 전용으로 드롭다운할 수 있습니다.
Safari는 특이합니다. 훨씬 나아졌지만 Safari는 여전히 일부 엣지 케이스를 다르게 처리합니다. 실제 iOS 장치에서 테스트합니다. 특히 시뮬캐스트 동작은 당신을 놀라게 할 수 있습니다.
피어 투 피어를 넘어 스케일링하려면 SFU가 필요합니다. 1대1 통화는 간단한 P2P입니다. 메시 방식을 사용한 4인 통화(모든 사람이 모든 사람과 연결)는 각 참가자가 3개의 연결을 유지한다는 의미이고, 3개의 비디오 스트림을 인코딩하고 업로드합니다. 확장하지 않습니다. 3명 이상의 참가자의 경우 각 참가자가 1개의 스트림을 서버로 보내고 서버가 모든 사람에게 전달하는 SFU를 사용합니다.
WebRTC 레이어를 헤드리스 CMS 설정과 함께 아키텍처하고 있고 도움이 필요하면 저희에게 연락해주세요 -- 우리는 이것을 충분히 했으므로 지뢰가 어디에 있는지 알고 있습니다.
FAQ
WebRTC는 무엇을 의미합니까?
WebRTC는 Web Real-Time Communication을 의미합니다. 단순한 JavaScript API를 통해 브라우저 및 모바일 애플리케이션에 실시간 오디오, 비디오 및 데이터 통신 기능을 제공하는 오픈소스 프로젝트이자 W3C 표준입니다.
WebRTC는 무료로 사용할 수 있습니까?
WebRTC API 및 프로토콜은 완전히 무료이며 오픈소스입니다. 그러나 프로덕션 애플리케이션을 구축하려면 신호 서버, TURN 릴레이 서버(대역폭 소비) 및 잠재적으로 미디어 서버(SFU) 비용이 포함됩니다. STUN 서버는 일반적으로 무료입니다 -- Google은 공개 서버를 제공합니다.
WebRTC는 서버 없이 작동합니까?
완전하지는 않습니다. 미디어는 피어 투 피어로 흐릅니다(미디어 경로에 서버가 없음), 피어가 서로를 발견하고 연결 정보를 교환하는 데 도움이 되는 신호 서버가 여전히 필요합니다. 또한 NAT 통과를 위해 STUN/TURN 서버가 필요합니다. 핵심은 서버가 미디어 데이터를 보거나 처리하지 않는다는 것입니다.
WebRTC는 WebSocket과 어떻게 다릅니까?
WebSocket은 클라이언트와 서버 간에 영구적인 양방향 연결을 제공합니다 -- 채팅, 알림 및 실시간 데이터에 좋습니다. WebRTC는 클라이언트 간에 피어 투 피어 연결을 제공하며 미디어(오디오/비디오)를 위해 최적화됩니다. WebRTC는 더 낮은 지연을 위해 UDP를 사용하고 WebSocket은 TCP를 사용합니다. 실제로 많은 앱은 신호화에 WebSocket을 사용하고 미디어 전송에 WebRTC를 사용합니다.
WebRTC를 수천 명의 시청자에게 라이브 스트리밍하는 데 사용할 수 있습니까?
순수 피어 투 피어 WebRTC는 수천 명의 시청자에게 확장할 수 없습니다. 그러나 SFU 또는 미디어 서버와 결합하면 WebRTC는 대규모 브로드캐스트를 처리할 수 있습니다. 플랫폼은 브로드캐스터가 1개 스트림을 서버로 보내는 아키텍처를 사용하며, 서버는 WebRTC를 통해 수천 명의 시청자에게 배포합니다. 10,000명 이상의 청중의 경우 HLS/DASH를 사용한 CDN 기반 접근이 일반적으로 더 비용 효율적입니다.
WebRTC는 안전합니까? 통화를 가로챌 수 있습니까?
WebRTC는 기본적으로 안전합니다. 모든 미디어 및 데이터는 DTLS 및 SRTP를 사용하여 암호화됩니다 -- 암호화는 필수이며 비활성화할 수 없습니다. 암호화는 피어 투 피어 시나리오에서 종단 간 발생합니다. SFU를 사용할 때 서버는 미디어를 해독하고 다시 암호화하므로 서버 운영자를 신뢰하고 있습니다. SFU를 통한 진정한 종단 간 암호화를 위해 Insertable Streams(WebRTC에서 "E2EE"라고도 함)를 살펴보세요.
STUN과 TURN 서버의 차이점은 무엇입니까?
STUN 서버는 가볍습니다 -- 브라우저에 공인 IP 주소와 포트를 알려줄 뿐이므로 직접 피어 투 피어 연결을 설정하는 데 도움이 됩니다. TURN 서버는 더 무겁습니다 -- 직접 연결이 실패할 때 미디어를 릴레이로 작동합니다. 모든 미디어 트래픽은 TURN 서버를 통해 흐릅니다. STUN은 저렴합니다(거의 무료), TURN은 비쌉니다(대역폭에 대해 비용 지불). 약 80-85%의 연결이 STUN만으로 성공합니다. TURN은 나머지를 처리합니다.
WebTransport가 WebRTC를 대체합니까?
아니요. WebTransport와 WebRTC는 다양한 문제를 해결합니다. WebTransport(HTTP/3 및 QUIC를 기반으로)는 클라이언트 대 서버 통신에 좋으며 낮은 지연이지만 피어 투 피어 연결이나 NAT 통과를 수행하지 않습니다. WebRTC는 직접 피어 투 피어 미디어 통신을 위한 유일한 브라우저 네이티브 솔루션으로 남아 있습니다. 이들은 상호 보완적인 기술이며 2026년 많은 애플리케이션이 둘 다 사용합니다.