docs: WebRTC 문서 내용 보충

HyunJinNo · HyunJinNo · commit 9999d637c7d2 · 2025-03-03T22:48:07.000+09:00
diff --git a/_posts/2024-11-03-webrtc.md b/_posts/2024-11-03-webrtc.md
@@ -1,6 +1,6 @@
 ---
 title: WebRTC (Web Real-Time Communication)
-description: WebRTC(Web Real-Time Communication)에 대해 설명하는 페이지입니다.
+description: WebRTC(Web Real-Time Communication)에 대해 정리한 페이지입니다.
 date: 2024-11-03 00:00:00 +/-TTTT
 categories: [Computer Science]
 tags: [webrtc]
@@ -12,16 +12,18 @@ image:
 comments: true
 ---
 
-<blockquote class="prompt-info"><p><strong><u>Tags</u></strong> <br />
+<blockquote class="prompt-info"><p><strong><u>Tags</u></strong><br />
 WebRTC</p></blockquote>
 
 ## 개요
 
-이번 글에서는 `WebRTC(Web Real-Time Communication)`에 대해 설명하겠습니다.
+`WebRTC(Web Real-Time Communication)`에 대해 정리한 페이지입니다.
 
-## WebRTC란?
+## WebRTC
 
-`WebRTC(Web Real-Time Communication)`란 웹 애플리케이션과 사이트가 별도의 중간자 없이 브라우저 간에 실시간 음성, 영상 통화와 데이터 전송을 가능하게 하는 기술입니다. WebRTC를 구성하는 일련의 표준들은 플러그인이나 제 3자 소프트웨어 설치 없이 P2P(Peer-to-Peer) 통신을 지원해 중간 서버를 거치지 않고 종단 간 데이터 공유와 화상 회의를 가능하게 합니다. 이를 통해 지연 시간을 줄이고 빠른 데이터 전송이 가능합니다. WebRTC는 주로 비디오 통화, 화면 공유, 파일 전송 같은 기능에 사용됩니다.
+### WebRTC의 개념
+
+`WebRTC(Web Real-Time Communication)`란 별도의 중간자 없이 브라우저 간에 실시간 음성, 영상 통화와 데이터 전송을 가능하게 하는 기술입니다. WebRTC를 구성하는 일련의 표준들은 플러그인이나 제 3자 소프트웨어 설치 없이 P2P(Peer-to-Peer) 통신을 지원해 중간 서버를 거치지 않고 종단 간 데이터 공유와 화상 회의를 가능하게 합니다. 이를 통해 지연 시간을 줄이고 빠른 데이터 전송이 가능합니다. WebRTC는 주로 비디오 통화, 화면 공유, 파일 전송 같은 기능에 사용됩니다.
 
 ### WebRTC의 주요 기능
 
@@ -45,12 +47,15 @@ WebRTC의 주요 기능은 다음과 같습니다.
 
 WebRTC의 장단점은 다음과 같습니다.
 
-**장점**
+#### 장점
 
 - `실시간 통신`
 
   플러그인 없이 브라우저 간 실시간 통신을 가능하게 해 간편하며, 서버 비용을 줄일 수 있습니다.
 
+  <blockquote class="prompt-warning"><p><strong><u>Caution</u></strong><br />
+  네트워크 환경에 따라 STUN/TURN 서버가 필요할 수도 있습니다.</p></blockquote>
+
 - `브라우저 기본 지원`
 
   Chrome, Firefox, Safari 등 주요 브라우저에서 기본적으로 지원되며, 별도의 플러그인이나 소프트웨어 설치 없이 사용할 수 있습니다.
@@ -63,7 +68,7 @@ WebRTC의 장단점은 다음과 같습니다.
 
   WebRTC는 오픈소스 라이브러리로 제공되므로 무료로 사용할 수 있으며, 다양한 오픈소스 라이브러리와 예제가 많아 개발과 확장이 용이합니다.
 
-**단점**
+#### 단점
 
 - `네트워크 환경에 따른 품질 저하`
 
@@ -77,43 +82,102 @@ WebRTC의 장단점은 다음과 같습니다.
 
   `STUN 서버`와 `TURN 서버`를 설정해야 하며, `ICE(Interactive Connectivity Establishment)` 프로토콜을 통해 연결을 설정해야 하므로, 단순한 HTTP 통신보다 복잡합니다. 또한 다자간 연결을 위해서는 SFU나 TURN 서버를 별도로 운영해야 하므로, 운영 비용과 복잡도가 증가합니다.
 
-### 구성해야 하는 서버
+### STUN/TURN 서버
+
+WebRTC에서 P2P 연결을 설정하려면 두 클라이언트가 서로의 공인 IP 주소 및 네트워크 경로를 알아야 합니다. 하지만 대부분의 경우에는 사용자가 `NAT(Network Address Translation)` 방화벽 뒤에 있기 때문에 직접적인 연결이 어려울 수 있습니다. 이를 해결하기 위해 `STUN 서버`와 `TURN 서버`가 사용됩니다.
+
+#### STUN 서버
+
+`STUN(Session Traversal Utilities for NAT) 서버`란 <b>클라이언트가 자신의 공인 IP 주소와 포트를 알아내기 위해 사용하는 서버</b>입니다. 클라이언트는 STUN 서버에 요청을 보내고, 서버는 요청을 수신한 IP 주소와 포트를 클라이언트에게 알려줍니다. 이를 통해 클라이언트는 자신의 공인 IP와 포트를 알아내어 NAT 방화벽을 넘어 다른 클라이언트와 직접 P2P 연결을 시도할 수 있습니다.
+
+STUN 서버는 주로 NAT 방화벽 뒤에 있는 클라이언트들이 연결을 설정할 때 필요한 정보를 제공합니다. 연결을 위한 경로 정보만 제공하고, 실제 데이터는 클라이언트 간의 P2P 연결을 통해 직접 전달됩니다.
+
+#### TURN 서버
+
+`TURN(Traversal Using Relays around NAT) 서버`란 <b>클라이언트 간에 직접 P2P 연결이 불가능한 경우 중계 서버 역할을 하여 데이터를 전송하는 서버입니다.</b> 클라이언트는 TURN 서버에 데이터를 보내고, 서버는 이를 상대방 클라이언트에게 전달합니다.
+
+TURN 서버는 NAT 방화벽이 강력하여 STUN 서버를 통해 연결이 불가능할 때 사용됩니다. 다만 TURN 서버는 모든 데이터를 중계하기 때문에 대역폭 사용량이 높아져 서버 비용이 발생할 수 있습니다.
+
+### WebRTC 구성 요소
+
+WebRTC는 다음 3가지 핵심 API로 구성됩니다.
+
+- `MediaStream(getUserMedia)`
+
+  카메라, 마이크 등 디바이스 미디어 접근을 요청하는 API로, 사용자 권한 허가 후 실시간 영상/음성 스트림을 획득합니다.
 
-- `STUN 서버`
+  ```javascript
+  navigator.mediaDevices
+    .getUserMedia({ video: true, audio: true })
+    .then((stream) => {
+      videoElement.srcObject = stream;
+    })
+    .catch((error) => console.error(error));
+  ```
 
-  `STUN(Session Traversal Utilities for NAT) 서버`란 클라이언트가 자신의 공인 IP 주소와 포트를 알아내기 위해 사용하는 서버입니다. 클라이언트는 STUN 서버에 요청을 보내고, 서버는 요청을 수신한 IP 주소와 포트를 클라이언트에게 알려줍니다. 이를 통해 클라이언트는 자신의 공인 IP와 포트를 알아내어 NAT 방화벽을 넘어 다른 클라이언트와 직접 P2P 연결을 시도할 수 있습니다.
+- `RTCPeerConnection`
 
-  STUN 서버는 주로 NAT 방화벽 뒤에 있는 클라이언트들이 연결을 설정할 때 필요한 정보를 제공합니다. 연결을 위한 경로 정보만 제공하고, 실제 데이터는 클라이언트 간의 P2P 연결을 통해 직접 전달됩니다.
+  P2P 연결을 설정하고 암호화, 대역폭 관리, 네트워크 통신을 처리하는 API입니다. `ICE(Interactivity Connectivity Establishment)` 프로토콜을 사용하여 연결을 설정합니다.
 
-- `TURN 서버`
+- `RTCDataChannel`
 
-  `TURN(Traversal Using Relays around NAT) 서버`란 클라이언트 간에 직접 P2P 연결이 불가능한 경우 중계 서버 역할을 하여 데이터를 전송하는 서버를 의미합니다. 클라이언트는 TURN 서버에 데이터를 보내고, 서버는 이를 상대방 클라이언트에게 전달합니다.
+  P2P 간 텍스트, 파일 등의 데이터를 전송하는 API로, 낮은 지연시간(Low Latency)으로 빠른 데이터 전송이 가능합니다. TCP/UDP를 모두 지원하며, 게임 스트리밍 등에 활용됩니다.
 
-  TURN 서버는 NAT 방화벽이 강력하여 STUN을 통해 연결이 불가능할 때 사용됩니다. 다만 TURN 서버는 모든 데이터를 중계하기 때문에 대역폭 사용량이 높아져 서버 비용이 발생할 수 있습니다.
+### WebRTC 작동 방식
 
-### WebRTC의 기본 작동 원리
+WebRTC를 통한 P2P 연결 과정은 다음과 같습니다.
 
-WebRTC는 `시그널링(Signaling)`을 통해 두 장치가 서로 통신할 수 있도록 Peer 간 정보를 교환합니다. 시그널링(Signaling)이란 위의 3가지 API를 통해서 데이터 교환이 이루어지며 RTCPeerConnection들이 적절하게 데이터를 교환할 있게 처리해 주는 과정을 의미합니다. `시그널링 서버(Signaling Server)`는 WebRTC 표준에 포함되지 않았기 때문에 별도로 구현하거나 외부 서비스를 이용해야 합니다. 시그널링 과정이 끝나면 두 장치는 직접 P2P 연결을 통해 데이터를 주고 받게 됩니다.
+1.  `미디어 접근 요청(getUserMedia())`
 
-## WebRTC 접근 방식
+    먼저 사용자의 카메라 및 마이크 접근 권한을 요청합니다.
 
-WebRTC는 기본적으로 P2P 방식이므로, 각 참가자가 서로 직접 연결을 맺게 됩니다. 참가자가 많아질수록 각 연결에 대한 리소스 소모가 커지며, 특히 대역폭과 CPU에 부담이 생길 수 있습니다.
+    ```javascript
+    navigator.mediaDevices
+      .getUserMedia({ video: true, audio: true })
+      .then((stream) => {
+        videoElement.srcObject = stream;
+      })
+      .catch((error) => console.error(error));
+    ```
 
-### Mesh 방식
+2.  `RTCPeerConnection 생성`
 
-`Mesh 방식`는 각 참가자가 모든 다른 참가자와 직접 연결을 맺는 방식을 의미합니다. 즉, 모든 참가자가 서로 연결하는 방식이비다. 예를 들어, 6명의 참가자가 존재할 경우, 각 참가자는 5개의 연결을 맺어야 합니다.
+    `RTCPeerConnection` 객체를 생성하여 WebRTC 연결을 관리합니다. 이 때 ICE 서버(STUN/TURN) 정보를 설정하여 연결을 시도할 준비를 합니다.
 
-Mesh 방식은 구현이 간단하고 서버 비용이 적게 든다는 장점이 있지만, 연결이 늘어날 수록 네트워크 및 CPU 부담이 커지기 때문에, 여러 명의 참가자가 존재하는 경우에는 성능 저하가 발생할 수 있다는 단점이 있습니다. 따라서 Mesh 방식은 비교적 소규모 그룹에 적합한 방식입니다.
+3.  `시그널링(Signaling)`
 
-### SFU 방식
+    WebRTC는 시그널링(Signaling)을 통해 두 장치가 서로 통신할 수 있도록 Peer 간 `SDP(Session Description Protocol)` 정보를 교환합니다. 시그널링(Signaling)이란 위의 3가지 API를 통해서 데이터 교환이 이루어지며 RTCPeerConnection들이 적절하게 데이터를 교환할 있게 처리해 주는 과정을 의미합니다. 시그널링 서버(Signaling Server)는 WebRTC 표준에 포함되지 않았기 때문에 별도로 구현하거나 외부 서비스를 이용해야 합니다.
 
-`SFU 방식`은 `Selective Forwarding Unit 서버`를 활용하는 방식입니다. 각 참가자는 자신의 미디어 스트림을 SFU 서버로 보내고, 서버는 각 참가자에게 다른 사람들의 스트림을 중계합니다. 서버는 단순히 데이터를 중계하는 역할만 하기 때문에 CPU 부담이 적고 확장성이 뛰어납니다.
+    <blockquote class="prompt-info"><p><strong><u>Info.</u></strong><br />
+    <b>SDP(Session Description Protocol)</b>: 미디어 세션 정보(코덱, 대역폭 등)를 텍스트 형식으로 정의합니다.</p></blockquote>
+
+4.  `STUN/TURN 서버 활용`
+
+    대부분의 디바이스는 NAT나 방화벽 뒤에 있기 때문에 공인 IP 주소를 확인하거나 중계 서버를 사용해야 합니다. STUN 서버를 통해 클라이언트의 공인 IP 주소와 포트 번호를 확인해 직접 연결을 시도합니다. 만약 직접 연결이 불가능한 경우 TURN 서버를 중계 서버로 활용합니다. 이 때 STUN/TURN 서버에서 생성된 ICE 후보 경로들을 조합하여 최적의 연결 경로를 선택합니다.
+
+5.  `P2P 연결`
+
+    ICE 후보 교환이 완료되면 WebRTC P2P 연결이 확립됩니다. 이 때부터 두 클라이언트 간 비디오/오디오 데이터가 직접 전송됩니다.
+
+### WebRTC 접근 방식
+
+WebRTC는 기본적으로 P2P 방식이므로, 각 참가자가 서로 직접 연결을 맺게 됩니다. 참가자가 많아질수록 각 연결에 대한 리소스 소모가 커지며, 특히 대역폭과 CPU에 부담이 생길 수 있습니다. WebRTC 기반 실시간 통신 시스템에서 여러 명이 동시에 화상 채팅을 할 때, 참가자들의 미디어 스트림을 어떻게 전달할 것인지에 따라 다음 3가지의 미디어 스트리밍을 관리하는 서버 아키텍처 방식으로 나뉩니다.
+
+#### Mesh (P2P)
+
+`Mesh`는 각 참가자가 모든 다른 참가자와 직접 연결을 맺는 방식을 의미합니다. 즉, 모든 참가자가 서로 연결하는 방식입니다. 예를 들어, 6명의 참가자가 존재할 경우, 각 참가자는 5개의 연결을 맺어야 합니다.
+
+Mesh 방식은 구현이 간단하고 서버 비용이 적게 든다는 장점이 있지만, 연결이 늘어날 수록 네트워크 및 CPU 부담이 커지기 때문에, 여러 명의 참가자가 존재하는 경우에는 성능 저하가 발생할 수 있다는 단점이 있습니다. 따라서 Mesh 방식은 비교적 소규모 화상 회의(2 ~ 4명)나 간단한 P2P 파일 공유에 적합한 방식입니다.
+
+#### SFU (Selective Forwarding Unit)
+
+`SFU`은 `Selective Forwarding Unit 서버`를 활용하는 방식입니다. 각 참가자는 자신의 미디어 스트림을 SFU 서버로 보내고, 서버는 각 참가자에게 다른 사람들의 스트림을 중계합니다. 예를 들어 3명의 참가자가 존재하는 경우, 각 참가자는 1개의 발신 스트림을 SFU로 전송하고, 2개의 수신 스트림을 받습니다. SFU 서버는 단순히 데이터를 중계하는 역할만 하기 때문에 CPU 부담이 적고 확장성이 뛰어납니다.
 
 SFU 방식의 경우 각 참가자는 서버와 하나의 연결만 맺으면 되므로 네트워크 사용량이 적고 대규모 그룹 채팅이 가능하다는 장점이 있습니다. 다만 SFU 서버를 설정해야 하므로 서버 비용이 발생할 수 있고 설정 복잡도가 높다는 단점이 존재합니다.
 
 SFU 방식은 다수의 참가자가 참여하는 화상 채팅을 구현할 때 일반적으로 사용되는 방식입니다. SFU 방식을 적용하기 위해 OpenVidu, mediasoup, jitsi Meet, Twilio 등 SFU 방식을 지원하는 오픈 소스나 서비스를 사용할 수 있습니다.
 
-#### SFU 방식의 작동 원리
+##### SFU 방식의 작동 원리
 
 SFU 방식의 작동 원리는 다음과 같습니다.
 
@@ -129,7 +193,7 @@ SFU 방식의 작동 원리는 다음과 같습니다.
 
    각 클라이언트는 다른 사용자들의 스트림을 SFU 서버로부터 다운로드합니다. 이렇게 하면 각 클라이언트는 SFU 서버와만 연결되며, 여러 명의 사용자와 직접 연결할 필요가 없습니다.
 
-#### SFU 방식의 장단점
+##### SFU 방식의 장단점
 
 SFU 방식의 장단점은 다음과 같습니다.
 
@@ -165,7 +229,16 @@ SFU 방식의 장단점은 다음과 같습니다.
 
   SFU 방식은 서버가 다운되면 전체 연결이 끊어질 수 있습니다. 이를 대비해 여러 서버를 활용한 부하 분산이나 백업이 필요할 수 있습니다.
 
+#### MCU (Multipoint Control Unit)
+
+`MCU`는 중앙 서버가 모든 스트림을 혼합해 단일 스트림으로 제공하는 방식입니다. 각 참가자는 자신의 미디어 스트림을 MCU 서버로 보내고, MCU는 모든 스트림을 하나의 합성된 화면/음성으로 조합해 전송합니다. 예를 들어 3명의 참가자가 존재하는 경우, 각 참가자는 1개의 발신 스트림을 전송하고, 1개의 수신 스트림을 받습니다. MCU 방식은 클라이언트가 단 하나의 스트림만 수신하므로 클라이언트 부하가 가장 적습니다.
+
+MCU 방식의 경우 각 참가자는 서버와 하나의 연결만 맺으면 되므로 네트워크 사용량이 적고 대규모 그룹 채팅이 가능하다는 장점이 있습니다. 다만 MCU 서버를 설정해야 하므로 서버 비용이 발생할 수 있고 설정 복잡도가 높다는 단점이 존재합니다.
+
+MCU 방식은 100명에서 수 천명에 다다르는 대규모 웹 세미나를 구현할 때 적합한 방식입니다.
+
 ## 참고 자료
 
 - <a href="https://developer.mozilla.org/ko/docs/Web/API/WebRTC_API" target="_blank">WebRTC API</a>
 - <a href="https://medium.com/@hyun.sang/webrtc-webrtc%EB%9E%80-43df68cbe511" target="_blank">[WebRTC] WebRTC란?</a>
+- <a href="https://velog.io/@suzieep/WebRTC-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0" target="_blank">[WebRTC] WebRTC 이해하기</a>
