webRTC란 무엇일까요? 주요 개념들 쉽게 설명 해드립니다.

✨ WebRTC란 뭘까?

실시간 통신에 있어 아주 재밌는 기술이 있습니다.

바로 webRTC(Web Real-Time Communication)인데요.

2011년, Google의 개발자들에 의해서 탄생한 기술입니다.

WebRTC를 사용하는 유명한 서비스들 중 Google Meet, Discord, Zoom 등 존재합니다.

쉽게 말해서 "다양한 플랫폼에서 가능한 실시간 커뮤니케이션 기술"이라고 생각하시면 됩니다.

화상 채팅, 음성 통화, 파일 공유 등등 이 모든 걸 별도의 프로그램 없이 웹 브라우저는 물론이고, 모바일 앱, 데스크탑 앱에서도 사용할 수 있는 오픈소스 프로젝트이며 강력한 기술입니다.

더욱 신기한 점은 서버 없이 P2P(Peer To Peer)로 연결되어 데이터를 주고받을 수 있다는 점입니다.

(P2P로 연결되기 위한 과정에서 중계 서버는 필요합니다. 이 내용은 아래 Signaling에 관한 설명을 참고해 주세요.)

WebRTC를 뒷받침하는 기술은 개방형 웹 표준(기술 표준이 문서가 공개되어 있으며 사용이 자유로운 경우를 가리키는 용어)으로 구현되며 모든 주요 브라우저에서 일반 자바스크립트 API로 제공됩니다.

Android 및 iOS 애플리케이션과 같은 네이티브 클라이언트의 경우 동일한 기능을 제공하는 라이브러리를 사용할 수 있어요.

💡 주요 개념 및 용어

webRTC에는 주요 용어 및 개념들이 존재하는데요.

바로

시그널링(Signaling)
SDP(Session Description Protocol)
ICE(Interactive Connectivity Establishment)
STUN/TURN

등의 용어가 있습니다.

그럼 조금 더 쉽고 자세하게 알아보겠습니다.

시그널링(Signaling)

이전에 제가 P2P로 연결하기 위해 중계 서버가 필요하다고 언급했습니다.

이 중계서버를 통해서 서로를 찾고 연결을 시작하는 과정을 바로 시그널링(Signaling)이라고 합니다.

비유하자면 시그널링의 개념은 마치 소개팅 주선자처럼 양쪽에서 서로의 정보를 전달해 주는 역할입니다.

이 시그널링은 서버를 통해 이루어지게 되고, 어떻게 구현할지는 자유입니다.

WebSocket, HTTP 등 적절한 프로토콜을 개발자가 선택하면 됩니다.

SDP(Session Description Protocol)

SDP는 "무엇으로 소통할지, 어떻게 소통할지"에 대한 정보가 담겨있는 양식입니다.

즉, "나는 이런 오디오, 비디오를 지원해"라고 알려주는 자기소개서와 같다고 보면 됩니다.

더 자세하게는 세션 정보, 네트워크 정보, 미디어의 종류, 코덱, 스트림의 속성 등 많은 내용이 담겨있습니다.

그래서 연결하는 시작하는 쪽에서는 Offer SDP를 생성하고, 받는 쪽에서는 Answer SDP로 응답합니다.

이 정보들을 통해서 양쪽 피어가 지원하는 코덱, 해상도 등을 협상하여 최적의 설정을 결정하게 되는 것이죠.

SDP의 구조를 한번 볼까요?

v=0
o=- 1234567890 1234567890 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE audio video
m=audio 9 UDP/TLS/RTP/SAVPF 111
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:someufrag
a=ice-pwd:someicepwd
a=fingerprint:sha-256 somefingerprint
...

이 SDP를 가지고 피어끼리 알아서 협상을 하게 되기 때문에 이걸 개발자 입장에서는 자세히 하나하나 모두 외울 필요는 없어요.

각 줄의 의미는 아래와 같아요.

온전히 세션 설명을 위한 형식이라고 이해하시면 됩니다.

ICE(Interactive Connectivity Establishment)

위에서 자기소개(SDP)를 했으니 이제 어떻게 연락을 할지 정해야겠죠?

ICE는 "나한테 연락하려면 이 주소로 연락해!"라고 알려주는 과정입니다.

즉, 두 피어 간의 최적의 통신 경로를 찾기 위해 사용되는 프레임워크입니다.

NAT(Network Address Traslation)와 방화벽 등의 네트워크 장벽을 극복하고 직접적인 연결을 가능하게 하는 중요한 역할을 합니다.

연결 후보 수집: 가능한 모든 연결 방법(후보)을 찾아냅니다.
연결성 검사: 각 후보에 대해 실제 연결 가능 여부를 테스트합니다.
우선순위 결정: 가장 효율적인 연결 경로(지연시간이 가장 짧은 연결을 선호)를 선택합니다.
NAT 및 방화벽 통과: 다양한 네트워크 환경에서의 연결을 가능하게 합니다.

ICE 프레임워크 알고리즘은 두 피어를 연결하기 위해 지연 시간이 가장 짧은 경로(최적의 통신 경로)를 찾고, 아래 옵션을 순서대로 시도합니다.

직접 UDP 연결, 사설 IP (이 경우에만 STUN 서버는 피어의 네트워크 연결 주소를 찾는 데 사용됩니다)
HTTP 포트를 통한 직접 TCP 연결
HTTPS 포트를 통한 직접 TCP 연결
relay/TURN 서버를 통한 간접 연결 (직접 연결이 실패한 경우. 예를 들어, 한 피어가 NAT 통과를 차단하는 방화벽 뒤에 있는 경우)

STUN / TURN

일반적으로 같은 네트워크를 사용하는 상황보다 완전히 다른 환경에서 다른 피어와 연결을 하는 상황이 많습니다.

같은 네트워크 망에 있으면 사설 IP로 P2P 연결이 가능하나, 서로 다른 네트워크 환경에서 각자의 사설 IP로는 연결이 불가능하죠.

이런 상황에서 STUN 서버와 TURN 서버가 사용됩니다.

즉, 네트워크 주소 변환(NAT) 뒤에 있는 장치들이 인터넷을 통해 서로 통신할 수 있도록 도와주는 역할입니다.

STUN

STUN(Session Traversal Utilities for NAT)은 우리의 컴퓨터가 "나 지금 어디 있는 거야?"라고 물어볼 때 대답해 주는 친절한 서버라고 생각하시면 됩니다.

NAT환경에서 Private IP를 별도로 가지고 있기 때문에 P2P 통신이 불가능해요.

따라서 클라이언트는 자신의 Public IP를 확인하기 위해 STUN 서버로 요청을 보내고 서버로부터 자신의 Public IP를 받게 됩니다.

STUN 서버의 특징으로는 가볍고 빠르게 주소를 확인할 수 있습니다.

TURN

TURN(Traversal Using Relays around NAT)은 마치 "너희 둘이 만나기 어려우면, 내가 중간에서 메시지를 전해줄게!"라고 하는 친절한 중계자입니다.

TURN 서버는 STUN 서버로 해결할 수 없는 상황에서 사용됩니다.

일부 고집이 센(?) NAT 구성에서는 외부 서버와의 직접적인 P2P 연결을 허용하지 않습니다.

그래서 TURN 서버의 특징으로는 완벽한 중계 서비스를 제공하지만, 상대적으로 느리고 리소스를 많이 사용합니다.

그래서 WebRTC는 보통 이렇게 행동해요.

"먼저 STUN으로 해볼까? 오 잘되네 이걸로 가자!"
"STUN이 안 되네..? 그럼 TURN한테 부탁하자"

즉, STUN 서버로 먼저 시도하고 안되면 TURN 서버로 시도하게 됩니다.

webRTC에서는 아래 예시처럼 설정할 수 있어요.

const peerConnection = new RTCPeerConnection({
  iceServers: [
    { urls: 'stun:stun.l.google.com:19302' }, // STUN 서버
    { 
      urls: 'turn:your-turn-server.com',      // TURN 서버
      username: '유저네임',
      credential: '비밀번호'
    }
  ]
});

👀 동작 원리

전체적인 큰 그림을 한번 살펴볼까요?

서로 다른 네트워크 환경이라 가정한 상황에서 STUN 서버를 통해 연결 가능한 정보를 획득하고 시그널링 서버를 통해서 SDP를 주고받게 됩니다.

물론 이 SDP에 ICE 후보의 연결 가능한 IP주소도 포함되어 있습니다.

SDP를 주고받고 서로의 SDP를 webRTC에서 연결이 설정된 후 나면 비로소 P2P 연결이 가능하게 됩니다.

덧붙이자면, 이 시그널링 서버는 연결 과정에서만 필요하고 더 이상 P2P 연결을 위한 시그널링 서버는 필요하지 않습니다.

이후 통신은 webRTC를 통해 P2P로 통신을 하게 되죠.

실제 코드를 통한 webRTC P2P 연결은 다음 포스팅에서 진행할 예정입니다.

⁉️ P2P 연결의 한계

webRTC를 통한 개발을 위해서는 꼭 알아두어야 하는 부분이 있습니다.

P2P 연결은 webRTC의 기본이지만, 참가자가 많아지면 과부하가 오기 시작합니다.

마치 한 사람이 여러 명에게 동시에 말하려다가 목이 아파지는 것처럼요.

만약 N명이 참여하면 N(N-1) / 2 개의 연결이 필요하게 됩니다.

참가자가 10명이면 45개의 연결이 생성되게 됩니다.

즉, 이렇게 되면 CPU에 과부하가 올 가능성이 매우 높습니다.

대신 보통 P2P 구현은 서버에 별도의 부하가 없고, Peer 간의 직접적인 연결로 실시간성이 보장됩니다.

그래서 매우 적은 사용자들만 필요로 할 때 사용하게 되는 구현 방식입니다.

그럼 어떻게 효율적으로 처리할 수 있을까요?

어떠한 방식들이 있을지 간단하게 짚고 마무리하겠습니다.

SFU(Selective Forwarding Unit)

SFU는 영리한 미디어 라우터라고 생각하시면 됩니다.

미디어 간의 트래픽을 중계하는 중앙 서버이며 서버와 클라이언트 간의 Peer을 연결합니다.

각 참가자로부터 하나의 스트림만 받아서 필요한 곳에 전달합니다.
참가자들의 대역폭과 성능에 따라 영상 품질을 조절할 수 있습니다.
확장성이 뛰어나고, 지연 시간도 비교적 짧습니다.

작동 방식을 알아보면 아래와 같습니다.

A가 영상을 SFU로 한 번만 전송해요.
SFU가 이 영상을 B, C, D에게 각각 전달해요.
A는 업로드를 한 번만 하면 됩니다.

그래서 1:N 형식 또는 소규모 N:M 형식의 실시간 스트리밍이 필요한 상황에서 주로 채택되고 있어요.

MCU(Multipoint Control Unit)

MCU는 영상을 받아서 섞은 다음에 하나의 스트림으로 만들어 보내게 됩니다.

MCU 방식은 클라이언트에 부담이 가장 적고, 일관된 경험을 제공하지만 서버 리소스를 가장 많이 사용합니다.

그리고 최대 단점으로는 webRTC의 최대 장점인 실시간성이 보장되지 않을 수 있어요.

작동 방식은 아래와 같아요

A, B, C가 각자의 영상을 MCU로 보냅니다.
MUC가 이 영상들을 하나의 스트림으로 만들어요
그리고 이 통합된 스트림을 모든 참가자에게 보내주게 됩니다.

간단하게 요약하자면

SFU: 유연하고 확장성이 좋아요. 대규모 회의에 적합합니다.
MCU: 일관된 경험을 제공하고 클라이언트 부담이 적습니다. 작은 회의나 낮은 성능의 기기에 좋아요.

저희가 알고 있는 서비스 중에서 Zoom은 SFU와 MCU의 하이브리드 방식을 사용하고, GoogleMeet는 SFU 방식을 사용하고 있다고 하네요.

📕 마무리

이번 글에서는 webRTC가 무엇이고, 이를 통해서 어떻게 실시간 통신이 이루어지는지, 어떤 한계점이 있고 어떤 방식이 있는지 알아보았습니다.

그리고 마지막에 설명했던 P2P 방식, SFU, MCU와 같은 방식은 각각 상황에 맞게 사용하면 되고 정답은 없습니다.

전체적인 개념에 대해서 정리를 해보았고 다음 포스팅은 실제 코드 예제를 통한 webRTC의 간단한 P2P 방식 화상채팅 서비스를 통해서 동작 방식을 더 자세히 알아보도록 하겠습니다.

감사합니다.

참고 문헌:

저작자표시 비영리 변경금지