WebRTC 및 SDK를 사용한 화상 통화 및 실시간 스트리밍

만약 당신이 만들고 있다면 자바스크립트 사이드 프로젝트 영상 통화가 필요한 경우, WebRTC를 순수하게 사용할지, Agora, Twilio, Mux, Zegocloud 같은 SDK를 사용할지, 아니면 React Native 기반의 RN-WebRTC를 사용할지 고민하는 것은 당연합니다. 안타깝게도 정답은 하나가 아닙니다. 하지만 다행히도 여러분은 실시간 JavaScript에 대한 이해가 있으므로, 정보에 기반한 결정을 내리고 아키텍처를 잘못 설계하는 실수를 방지할 수 있는 최적의 위치에 있습니다.

다음 내용에서 단계별로 작동 방식을 확인할 수 있습니다. WebRTC 내부Agora(및 기타 유사 제공업체)는 어떤 역할을 할까요? 자체 인프라(STUN/TURN, 신호 처리, SFU, 미디어 서버 등)를 구축한다는 것은 무엇을 의미할까요? 그리고 화상 통화 및 실시간 스트리밍에 있어 비용, 복잡성, 확장성 간의 실제적인 장단점은 무엇일까요?

WebRTC란 무엇이며, 왜 모든 것의 기반이 되는가?

WebRTC(웹 실시간 통신) API는 플러그인이나 외부 애플리케이션 없이 브라우저 또는 네이티브 앱에서 직접 실시간 오디오, 비디오 및 데이터 스트리밍을 가능하게 하는 오픈 소스 표준, API 및 프로토콜 세트입니다. W3C와 IETF에서 표준화되었으며 Chrome, Firefox, Safari, Edge, Opera 및 여러 모바일 브라우저를 포함한 모든 최신 브라우저에서 지원됩니다.

그들의 철학은 명확하다: 소통을 가능하게 하는 것. 피어투피어(P2P) 사용자 간 연결을 매우 낮은 지연 시간으로 제공하고, 코덱, 지터, 에코, 패킷 손실, 암호화 등 불편한 네트워크 문제를 모두 백그라운드에서 처리합니다. 이는 일대일 화상 통화부터 다양한 시스템에 이르기까지 모든 것을 포함합니다. 인터랙티브 스트리밍 적절한 인프라를 갖추면 수백 또는 수천 명의 관중을 동원할 수 있습니다.

주요 WebRTC API: getUserMedia, RTCPeerConnection 및 RTCDataChannel

WebRTC는 자체 솔루션을 구축하든 Agora와 같은 SDK를 사용하든 관계없이 반드시 사용하게 될 세 가지 주요 브라우저 측 API에 의존합니다.

미디어 스트림 / getUserMedia: 비디오와 오디오를 캡처합니다(카메라, 마이크, 심지어 화면이나 태블릿까지).
RTCPeer 연결: 피어 간에 오디오 및 비디오 스트림을 협상하고 전송합니다.
RTC데이터 채널클라이언트 간에 임의의 데이터(텍스트, 바이너리, 파일)를 낮은 지연 시간으로 전송합니다.

와 getUserMedia 브라우저의 카메라 및 마이크 접근 권한을 요청하고 답변을 받을 수 있습니다. MediaStream 그런 다음 해당 요소를 연결합니다. <video> 와 video.srcObject = stream. 신청하실 수 있습니다 제한 사항 (해상도, 프레임률, 전면/후면 카메라 등) 이러한 조건이 충족되지 않으면 다음과 같은 오류가 발생합니다. OverconstrainedError따라서 대안을 제시할 수 있도록 관리해야 합니다(예: 1080p에서 720p로 해상도를 낮추고 조정 적용). 마이크 오디오 개선).

API RTCPeer 연결 이는 통화의 핵심 부분으로, SDP(제안/응답) 협상, ICE(스탠드/턴) 후보 수집, 연결 설정 및 SRTP를 통한 보안 전송을 처리합니다. 코드에서는 단순히 연결을 생성하고, 미디어 트랙을 추가하고, 다음과 같은 이벤트에 반응하기만 하면 됩니다. onicecandidate u ontrack 그리고 표지판 관리는 당신이 맡아주세요.

마지막으로, RTC데이터 채널 웹소켓과 유사한 데이터 채널을 설정할 수 있지만, 지점 간 연결 방식이며 안정성과 순서를 세밀하게 제어할 수 있습니다. 화상 채팅, 파일 공유, 게임 상태 동기화 또는 실시간 협업에 유용합니다. 구문은 익숙합니다. dataChannel.send() y onmessage 수신기에서.

시그널링: WebRTC가 정의하지 않은 "연결 고리"

흔히 발생하는 오해: WebRTC 표지판은 포함되어 있지 않습니다.RTCPeerConnection은 정보 교환이 필요하지만, 교환 방식을 지정하지는 않습니다. 사용자가 직접 정의하거나, 타사 SDK를 사용하여 추상화할 수 있습니다.

쌍은 시그널링을 통해 전송됩니다.

세션 제어 메시지통화 시작, 통화 종료, 오류.
네트워크 정보: ICE 후보 (발견된 IP 주소/포트).
미디어 메타데이터SDP는 코덱, 해상도 등을 포함한 오퍼와 응답을 제공합니다.

이 표지판은 일반적으로 다음과 같은 방식으로 설치됩니다. WebSocket을Socket.IO, HTTP(폴링/롱폴링), MQTT 또는 기타 양방향 메커니즘. 매우 일반적인 패턴은 Node.js 서버를 사용하는 것입니다. Socket.IO "방"을 관리하고 메시지를 전달하는 기능 텍스트/JSON 유형 고객 간:

서버: 받는다 create or join이 앱은 방이 없으면 방을 생성하고, 최대 두 명의 클라이언트(기본 화상 통화 기준)를 지원하며, 메시지를 전달합니다. message 방 안의 다른 콘센트로 전원을 공급할 수 있습니다. 최대 사용자 수를 초과하지 않도록 하거나, 방의 작동 로직을 직접 설계하는 것은 사용자 본인의 책임입니다.

고객페이지를 로드할 때 방 이름을 입력받거나(또는 URL에서 유추) 다음과 같은 메시지를 출력합니다. create or join다음과 같은 이벤트들을 들어보세요 created, joined, full, ready 그리고 상대방과 통화 시작 또는 거부에 대해 합의합니다.

이 패턴은 다음과 같은 용도에 적합합니다. 프로토타입 또는 사이드 프로젝트이 솔루션은 필요에 따라 클러스터 및 로드 밸런서를 사용하여 확장할 수 있는 경량 시그널링 서버를 제공합니다.

기절, 전환, 차단: NAT와 방화벽을 혼란 없이 통과하는 방법

이상적인 세상에서는 두 사용자가 항상 접근 가능한 네트워크에 연결되어 직접 연결될 것입니다. 하지만 현실 세계에는 여러 가지 어려움이 있습니다. NAT, 방화벽, CGNAT ISP와 편집증적인 기업 네트워크로부터 보호하기 위해 ICE가 등장했습니다. ICE는 STUN과 TURN을 결합한 이름입니다.

충격 (NAT용 세션 트래버설 유틸리티)를 사용하면 클라이언트가 자신의 세션을 찾을 수 있습니다. 공용 IP 및 포트STUN 서버는 해당 정보만 응답으로 보냅니다.
회전 (NAT를 우회하는 릴레이를 사용한 트래버스)는 다음과 같이 작동합니다. 릴레이 서버 직접적인 P2P 채널을 열 수 없을 때 미디어를 전송하는 데 사용됩니다. 오디오/비디오 트래픽이 이 채널을 통해 전송되므로 서버 대역폭을 소모하고 비용이 발생합니다.
ICE (상호 연결 설정)은 실행 가능한 경로를 찾을 때까지 모든 가능한 후보(STUN, TURN 릴레이에 반영된 로컬 주소)를 테스트하는 역할을 합니다.

실제로 RTCPeerConnection 구성 객체에 배열을 추가합니다. 아이스서버 STUN/TURN URI를 사용하면 브라우저가 나머지 작업을 처리합니다. 자체 인프라를 구축하는 경우 STUN/TURN 서버를 배포하고 유지 관리해야 하지만, Agora, Twilio 또는 Zegocloud와 같은 SDK를 사용하는 경우에는 이러한 작업이 이미 완료되어 프로덕션 환경에서 바로 사용할 수 있습니다.

저지연 실시간 스트리밍: WebRTC vs HLS/DASH

우리가 이야기 할 때 라이브 스트리밍 크게 두 가지 세계가 있습니다. 하나는 HTTP 기반 프로토콜(HLS, DASH)이고 다른 하나는 WebRTC입니다. HLS/DASH는 클라이언트에서 비디오 세그먼트를 다운로드하고 재생하는 방식으로 작동합니다. 이는 CDN을 통한 확장성에 매우 적합하지만, 다음과 같은 문제점을 야기합니다. 수초의 지연 시간 (5~30초 정도는 거뜬히 걸립니다.)

반면 WebRTC는 다음을 사용합니다. UDP + RTP 또한 소스에서 플레이어로 "푸시" 모드로 비디오를 전송하며, 시작 시간이 매우 짧고 일반적인 지연 시간은 다음과 같습니다. 500 MS (네트워크 상태가 좋을 경우 보통 약 250ms) 이러한 빠른 응답 속도를 보이는 이유는 다음과 같습니다.

혼잡 제어 패킷 손실, 지터 또는 RTT에 따라 비트 전송률과 해상도를 실시간으로 조정하는 통합 기능입니다.
효율적인 코덱(VP8, VP9, H.264, 점차 AV1 사용 증가)을 활용 하드웨어 가속 가능한 경우.
수신기가 자신의 네트워크/장치가 지원할 수 있는 레이어만 수신하도록 SVC(확장 가능한 비디오 코딩)를 사용할 수 있는 가능성.

그래서 WebRTC는 다음과 같은 경우에 자연스러운 선택입니다. 실시간 경매실시간 스포츠 베팅, 거래, 인터랙티브 게임, 원격 지원, 원격 의료, 참여형 가상 교실 또는 금융 대시보드와 같이 몇 초의 지연도 허용할 수 없는 서비스들이 있습니다.

문제는 순수 P2P WebRTC는 수천 명의 시청자를 수용할 정도로 확장성이 좋지 않다는 것입니다. 이를 위해서는 다른 방식이 필요합니다. SFU, 미디어 서버 또는 하이브리드 플랫폼바로 그런 점에서 Flussonic, Agora 또는 이와 유사한 솔루션이 필요합니다.

P2P를 넘어선 확장: SFU, 미디어 서버 및 하이브리드 아키텍처

일대일 화상 통화에서는 WebRTC가 완벽하게 작동합니다. 하지만 사용자가 10명, 20명, 또는 100명으로 늘어나기 시작하면 상황이 달라집니다. 각 클라이언트는 여러 개의 스트림을 송수신해야 하고, CPU 과열이 발생하며, 네트워크가 다운됩니다. 여기서 세 가지 전형적인 패턴이 나타납니다.

MCU(다지점 제어 장치)서버는 모든 스트림을 수신하여 혼합한 후 각 클라이언트에 단일 스트림으로 전송합니다. 장점: 클라이언트 측 리소스 소모가 적습니다. 단점: 서버 부하가 높고, 개별적인 품질 관리가 어려워집니다.
SFU(선택적 전송 장치)서버는 스트림을 수신하고 혼합하지 않고 선택적으로 전달합니다. 각 시청자는 필요한 스트림을, 필요에 따라 서로 다른 화질로 수신할 수 있습니다. 이는 오늘날 가장 일반적으로 사용되는 방식입니다. 다중 사용자 화상 회의 확장 가능한 대화형 스트리밍 기능도 제공합니다.
하이브리드 아키텍처 WebRTC + HLS/DASHWebRTC는 데이터 수집 및 상호 작용에 사용되는 반면, HLS/DASH는 실시간 상호 작용이 필요하지 않은 대규모 사용자에게 데이터를 배포합니다. 이는 두 가지 방식의 균형을 맞추는 것입니다. 초저지연 "배우"들을 위한 기능과 "관객"들을 위한 대규모 확장성을 제공합니다.

미디어 서버와 같은 것들 플루소닉 다른 업체들은 필요한 백엔드 기능을 제공합니다. 웹RTC 스트림을 수신하고, 필요한 경우 트랜스코딩하고, 웹RTC를 통해 다른 클라이언트로 전달하거나, 대량 배포를 위해 HLS 유형 프로토콜로 변환합니다. 이러한 인프라가 실제로 일대일 통화를 넘어선 다중 통화 방식을 구현하는 데 필수적인 요소이며, 굳이 처음부터 모든 것을 새로 개발할 필요가 없게 만듭니다.

일반적인 사용 사례: 화상 통화, 스트리밍, IoT 등

WebRTC는 이제 어디에나 존재하며, 여러분은 아마도 의식하지 못하는 사이에 매일 사용하고 있을 것입니다. WebRTC가 특히 잘 어울리는 몇 가지 예는 다음과 같습니다... 화상 통화 및 화상 회의:

영상 통화 및 화상 회의Google Meet, Jitsi, Slack, Microsoft Teams 및 기타 여러 도구는 비디오, 오디오 및 화면 공유를 위해 WebRTC를 (일부 또는 전체적으로) 사용합니다.
실시간 스트리밍 서비스Twitch, Meta Live, Vimeo Livestream과 같은 플랫폼이나 Streamyard와 같은 도구는 데이터 수집을 위해 WebRTC를 사용하고 대량 배포를 위해 다른 기술을 결합합니다.
채팅 및 메시지 전송, 파일 공유 기능 포함RTCDataChannel 덕분에 중앙 미디어 서버 없이도 실시간 채팅, 파일 공유, 상태 동기화 등을 할 수 있습니다.
클라우드 게임 및 멀티플레이어GeForce NOW나 Xbox 클라우드 게임과 같은 서비스는 인터랙티브 비디오를 위해 유사한 기술을 활용하며, 많은 P2P 게임은 게임 플레이 동기화를 위해 WebRTC를 사용합니다.
사물인터넷(IoT) 및 감시스마트 카메라, 아기 모니터, 비디오 도어벨 또는 드론은 영상을 전송할 수 있습니다. 실시간 비디오 WebRTC를 사용하여 모바일 기기 및 브라우저에 연결합니다.
교육 및 원격진료화이트보드, 퀴즈, 양방향 비디오를 갖춘 가상 교실이나 지연 시간과 보안이 중요한 온라인 의료 상담 등이 그 예입니다.

WebRTC 보안: 암호화, 권한 및 모범 사례

WebRTC에서 보안은 추가 기능이 아니라 기본적으로 내장되어 있습니다. 설계 단계부터 통합됨모든 미디어 구성 요소는 암호화되어 있으며 API는 보안 출처(HTTPS 또는 localhost)에서만 작동하지만, 항상 주의를 기울이는 것이 좋습니다. 영상 통화를 이용한 사기.

DTLS (데이터그램 전송 계층 보안)은 전송 중인 데이터를 암호화합니다.
SRTP (보안 실시간 전송 프로토콜)은 오디오와 비디오를 보호하여 쉽게 조작되거나 가로채지지 않도록 합니다.
에 액세스 카메라와 마이크 사용자의 명시적인 허가가 필요하며, 시각적 표시기(아이콘, 색깔 있는 점 등)를 통해 허가 여부를 확인할 수 있습니다.
플러그인을 설치할 필요가 없으므로 위험 부담이 없습니다. 악성 소프트웨어 타사 확장 프로그램이나 바이너리에 위장되어 있습니다.

그렇긴 하지만, 여러분은 자신의 레이어를 직접 관리해야 합니다: 사용 HTTPS를 통해요청하는 권한을 검토하고, 브라우저와 라이브러리를 최신 상태로 유지하며, 시그널링 서버나 REST API의 보안을 소홀히 하지 마십시오.

WebRTC와 다른 기술(VoIP, WebSockets 및 독자적인 플랫폼) 비교: WebRTC와 VoIP, WebSockets, 그리고 독자적인 플랫폼

기존 VoIP 환경에 익숙하신 분이라면 SIP, PBX, 소프트폰, 그리고 고가의 서버에 대해 잘 알고 계실 겁니다. WebRTC는 이러한 패러다임을 완전히 바꿔놓았습니다. 사용자에게 어떠한 정보도 요구할 필요가 없기 때문입니다. 데스크탑 클라이언트 특별한 하드웨어는 필요하지 않습니다. 브라우저와 비교적 간단한 시그널링 서버만 있으면 충분합니다.

대 기존 VoIPWebRTC는 핵심 인프라 부담을 줄이고 웹에 직접 통합되는 애플리케이션의 가능성을 열어줍니다. 많은 경우, 시그널링을 WebRTC로 변환하는 게이트웨이를 통해 기존 SIP 백엔드를 재사용할 수 있습니다.

관련 WebSocket을둘은 상호 보완적인 관계로 보는 것이 좋습니다. 알림, 간단한 채팅 또는 상태 업데이트에는 이상적이지만, 고화질 미디어에는 적합하지 않습니다. WebRTC는 다음과 같은 용도에 최적화되어 있습니다. 실시간 오디오/비디오혼잡 제어, 코덱, 지터 버퍼 등을 포함합니다. 실제로 많은 프로젝트에서 시그널링에는 WebSockets을, 미디어 전송에는 WebRTC를 사용합니다.

만약 그것들을 다음과 같은 플랫폼과 비교해 본다면 Zoom, GoToMeeting 또는 WebEx차이점은 모델에 있습니다. 기존 도구들은 폐쇄형 솔루션으로, 데스크톱 앱 설치가 필수적이며 독점적인 백엔드를 사용하는 경우가 많습니다. 반면 WebRTC는 기반 기술이므로, 이를 기반으로 자체적인 "미니 미팅"을 구축하거나 Google Meet 또는 Microsoft Teams와 같이 이미 WebRTC를 사용하는 서비스와 통합할 수 있습니다.

WebRTC를 이용한 개발: 실제 복잡성과 일반적인 함정

API는 이론상으로는 간단해 보이지만, WebRTC를 처음부터 구현하는 것은 훨씬 더 복잡합니다. 다음과 같은 사항들을 고려해야 합니다.

SDK를 지원하는 실시간 CDN: Agora, Twilio, Mux, ZEGOCLOUD 등

같은 서비스 아고라, 트윌리오, 뮤크스, 제고클라우드 또는 유사한 기술은 WebRTC 위에 가치 계층을 구축하여 수개월의 작업과 수많은 골칫거리를 줄여줍니다.

그들은 당신에게 글로벌 미디어 네트워크 전 세계에 분산된 SFU를 통해 낮은 지연 시간을 위해 최적화되었습니다.
추상적인 STUN/TURN, 신호, 재시도재연결 및 복잡한 네트워크 관리.
여기에는 잘 관리된 SDK가 포함됩니다. 웹, iOS, 안드로이드, 리액트 네이티브 그리고 다른 프레임워크들.
그들은 다음과 같은 추가 서비스를 제공합니다. 녹화, RTMP/HLS로 방송중재, 실시간 통계, 품질 관리, 사용자 역할(호스트, 청중, 발표자) 등

짐작하시겠지만, 가장 큰 문제는 비용입니다. 조금이라도 돈이 있다면 말이죠. 몇 분 분량의 영상 또는 동시 접속자 수가 많아지면 요금이 급증합니다. 게다가 해당 플랫폼과 그 가격 또는 API 변경 사항에 의존하게 됩니다.

귀하의 구체적인 상황에서, 풍부한 경험을 바탕으로 실시간 자바스크립트합리적인 선택은 SDK를 사용하여 개발 속도를 높이고, 제품을 검증하고, 룸 모델, 역할, 스트림 수명 주기 및 상태 관리에 대해 학습하는 것입니다. 나중에 프로젝트가 성공적으로 진행되고 비용이 문제가 되면 솔루션의 일부를 보다 강력한 플랫폼으로 점진적으로 마이그레이션할 수 있습니다. 독점 WebRTC 인프라 또는 Flussonic 유형의 미디어 서버를 사용하여 배포 계층을 제어할 수도 있습니다.

WebRTC 디버깅을 위한 모범 사례 및 도구

WebRTC의 블랙박스에 갇히지 않으려면 브라우저와 생태계에 이미 존재하는 도구를 활용하는 것이 좋습니다.

크롬 : // webrtc-internals (o about:webrtc (파이어폭스에서): 연결, 비트 전송률, 패킷 손실, 활성 코덱 등에 대한 자세한 통계를 보여주는 패널.
어댑터.js커뮤니티에서 유지 관리하는 래퍼로, 브라우저와 버전 간의 차이를 완화해 줍니다.
테스트.webrtc.org카메라, 마이크, 네트워크 및 기기의 전반적인 호환성을 확인하기 위해서입니다.
공식 샘플 webrtc.github.io/samples에서 제약 조건, 피어 연결, 데이터 채널, 화면 공유 등의 예제를 찾아볼 수 있습니다. 패턴을 복사하는 데 매우 유용합니다.

또한, 코드를 구조화할 때는 필요한 부분을 명확하게 분리하는 것이 좋습니다. 신호 레이어 (소켓, 방, 메시지) 레이어 순수 WebRTC (연결 생성, 스트림 관리, 이벤트 핸들러). 이를 통해 클라이언트 로직 전체를 다시 작성하지 않고도 시그널링 백엔드 또는 미디어 서버를 교체할 수 있습니다.