[WebRTC] WebRTC 찢어버리기 - 이론 정리

출처: https://webrtc.github.io/webrtc-org/press

 

 

 

📖 개요

---

반갑습니다. WebRTC 관련 글이 저의 첫 포스팅이 되었네요. 이 내용을 작성하게 된 데는 나름의 계기가 있습니다.

 

부트캠프에서 팀 프로젝트를 진행하면서, 기능 요구사항을 만족시키기 위해 WebRTC라는 기술을 처음 접하고 적용했었습니다. 구현 단계부터 많은 문제를 만났었고, 수많은 깃헙 레포지토리와 블로그 글을 참고했지만, 기초 이론에 대한 부족함을 느낀 채로 데드라인에 쫓겨 프로젝트를 어영부영 마무리 했었습니다.

 

개인적인 회고를 진행하면서 이런 생각이 들었습니다.

“면접에서 WebRTC의 동작 방식이나 사용 이유를 물어본다면, 제대로 설명할 수 있을까?”
“누군가 WebRTC를 처음 쓴다고 조언을 구해온다면, 명쾌하게 설명해줄 수 있을까?”

 

질문에 대한 제 대답은 “NO” 였습니다. 부족한 부분이 무엇인지 인지했고, 과거의 저처럼 막막함을 느낄 누군가에게 도움이 되고자 다시 공부하고 이 글을 작성하게 되었습니다.

 

이 포스팅은 이론 편과 실습 코드 편으로 나누어 작성되었으며, 구성은 다음과 같습니다.

• WebRTC란?
• WebRTC 동작방식
• 핵심 정리
• 마치며

 

 

 

🤔 WebRTC란?

---

Web Real-Time Communication의 약자로, 별도의 플러그인 없이 웹/앱 환경에서 카메라, 마이크, 데이터 채널을 통한 실시간 커뮤니케이션을 가능하게 해주는 기술입니다.

 

주요 특징

• Peer-to-Peer 연결
  • 미디어/데이터가 서버를 거치지 않고 사용자 간 전송
  • Real-Time과 비슷한 실시간 스트리밍 제공
  • P2P 연결을 맺기 위한 Signaling 단계 필요
• 미디어뿐 아니라 데이터 전송도 가능
  • 오디오/비디오 외에 텍스트, 바이너리 데이터도 P2P로 전송 가능
  • 게임, 채팅, 파일 전송 등에 활용
• 브라우저 자체 지원
  • 별도 플러그인 없이 동작
  • Chrome, Firefox, Safari 등 주요 브라우저에서 지원
  • Android 및 iOS에서도 지원 가능
  • 일부 비주류 브라우저/버전에서는 미지원 가능성 있음
• 비교적 낮은 진입장벽
  • 기본 JavaScript API로 구성

 

왜 WebRTC가 필요할까?

기능 개발 요구 사항으로 사용자 간 실시간 화상채팅이 있다고 생각해봅시다. 지금까지는 REST API로 JSON 상하차만 하다가 실시간 스트리밍 데이터를 다뤄야 한다니 머리가 새하얘집니다. WebRTC가 없다면 고려해야할 요소들이 너무나 많습니다.

• P2P 연결을 직접 구성할 것인가?
• 모든 데이터를 서버를 통해 중계할 것인가?
• 실시간이라면 UDP를 직접 다뤄야 하나?
• 관련 라이브러리나 프레임워크는 뭐가 있을까?
• 플러그인이나 복잡한 설정이 필요한 건 아닐까?
• 알아야 할 프로토콜은 또 왜 이렇게 많은 건지…

이쯤 되면 머리카락이 한 올씩 빠지기 시작합니다.

다행히도 WebRTC는 이런 고민들을 덜어주는 기술입니다.

 

간단하게 주요 특징을 살펴봤으니, 이제부터는 기술을 실제로 사용하기 위해 WebRTC가 어떻게 동작하는지에 대해 깊지 않고 적당한 선에서 알아보려고 합니다.

 

 

 

🚀 WebRTC 동작방식

---

앞선 내용에서, WebRTC는 P2P 연결을 기반으로 한다고 언급했습니다.

P2P 연결을 설립하기 위해 Signaling 이라는 과정을 먼저 거칩니다. 왜 Signaling이 필요한지 그리고 어떤 방식으로 이루어지는지를 두 명의 유저가 화상채팅을 시도한다고 가정하고 실행의 흐름에 따라 설명해보겠습니다.

 

자, 이제 뚱이와 스폰지밥이 날씨 이슈로 인해서 집콕을 하기로 합니다.

하지만, 둘은 만나서 놀고싶은거죠. 이 때, 스폰지밥이 브라우저를 통해서 화상채팅으로 만나자고 제안합니다.

뚱이는 생각했습니다.

“우리 각자 컴퓨터에서 사용중인 프로세스의 IP와 PORT 번호를 알아야 정확히 P2P로 연결할 수 있을텐데, 어떻게 알아내지?”

 

 

Signaling

Signaling 이란, 고정 IP를 가지는 애플리케이션(e.g, AWS EC2로 배포한 서버)을 통해 WebSocket, REST API 등의 별도의 채널을 사용해 서로의 SDP 정보와 ICE Candidate를 교환하는 과정을 말합니다.

 

뚱이와 스폰지밥의 컴퓨터는 일반 가정 네트워크 환경에 있기 때문에, 외부 연결을 시도할 때마다 사용 가능한 IP와 PORT 번호가 매번 동적으로 바뀌고, NAT가 동작하는 라우터 뒤에 숨어 있어 서로의 IP, PORT 번호를 직접 알 수 없습니다.

 

하지만 누군가 화상채팅 서비스를 위해 배포한 서버가 있다고 해봅시다.

해당 서버는 언제나 접근할 수 있도록 고정된 IP:PORT를 가지고 있기 때문에 뚱이와 스폰지밥은 각자 이 서버에 연결하여 자신의 연결 정보를 전달할 수 있습니다.

그런 다음, 서버는 뚱이의 정보를 스폰지밥에게, 스폰지밥의 정보를 뚱이에게 전달할 수 있게 됩니다.

 

이처럼 P2P 연결을 맺기 위한 초기 메시지 교환 과정을 Signaling이라고 부르고, 중개하는 서버를 Signaling Server 라고 합니다. Signaling 기능은 WebRTC API에 포함돼 있지 않으므로 개발자가 직접 구현해야 합니다. 하지만, 전달 대상만 명확히 구분할 수 있는 로직을 작성한다면 메시지를 받은 그대로 대상에게 전달하면 되기 때문에 비교적 간단하게 구현할 수 있습니다.

 

한꺼번에 생소한 키워드가 쏟아졌다면 잠깐 멈추고 싶어질 수도 있습니다. 궁금한 부분, 가볍게 정리하고 가봅시다.

 

 

NAT(Network Address Translation)

“왜 서버는 고정 IP이고, 뚱이와 스폰지밥은 동적인 IP/PORT를 쓰는 거지?”

핵심은 바로 IPv4 주소의 부족과 이를 해결하기 위한 NAT 때문입니다.

 

IPv4는 약 43억 개의 주소(2³²)를 제공하지만, 우리가 생각하는 것보다 훨씬 빨리 고갈되었습니다. 왜냐하면 컴퓨터, 스마트폰은 물론이고 냉장고, 세탁기, 자동차까지 인터넷에 연결되는 시대가 왔기 때문이죠. 모든 기기에 고유한 IP를 부여하기엔 수가 턱없이 부족합니다.

 

이에 대한 해결책이 NAT 입니다.

NAT는 하나의 공인 IP를 여러 내부 장치들이 함께 사용하는 기술입니다. 우리가 집에서 쓰는 공유기도 사실 NAT 기반의 장치입니다. 공유기는 내부 네트워크의 사설 IP들을 외부에 노출시키지 않고, 대신 자신의 공인 IP로 통신을 중개합니다.

 

위 그림에서 뚱이가 외부 서버로 요청을 보냈을 때 과정을 살펴보겠습니다.

1. 공유기와 연결된 뚱이의 데스크탑은 로컬 DHCP 서버를 통해서 private IP 할당받습니다.
   • 192.168.0.23
2. 뚱이가 고정 IP를 가진 서버로 요청을 보냅니다.
3. 라우터가 NAT 변환을 수행하고 외부로 요청을 전달합니다.
   • 라우터가 가진 공인 IP + 사용 가능한 PORT 로 변환
     • 192.168.0.23:52933 ⇒ 112.113.114.115:62000
   • 연결이 지속된다면 NAT가 매핑한 해당 IP:PORT 를 뚱이가 계속 점유하면서 사용
4. 뚱이는 외부 응답을 받고 연결이 종료됩니다.
   • 할당 받았던 IP:PORT를 매핑 테이블에서 제외
   • PORT 번호 62000이 다시 가용 상태가 됨

 

뚱이와 스폰지밥처럼 일반 사용자는 보통 NAT 뒤에 있습니다.

그 안에서는 사설 IP를 DHCP서버에게 동적으로 할당받고 외부에서는 공유기의 공인 IP 하나만 보이기 때문에 실제로 누구와 어떻게 연결돼야 하는지 외부에서는 알기 어렵습니다. 이렇게 동작함으로써 일반 사용자는 필요할 때마다 동적으로 IP:PORT를 할당받고 해제합니다. 결과적으로, IP 주소 부족 현상을 완화할 수 있게 됩니다.

 

반면 서버는 왜 고정 IP를 쓸까요?

WebRTC에서 Signaling Server처럼 중간 역할을 수행해야 하는 서버는 클라이언트들이 항상 접근할 수 있어야 하기 때문에 고정 IP가 사실상 필수입니다.고정된 위치에 있기 때문에 뚱이와 스폰지밥이 서버와 통신하길 원할 때, 서버를 통해 서로의 정보를 교환하고 연결할 수 있는 거죠. 매번 바뀌는 IP로 운영한다면 사용자도 혼란스럽고, 도메인 매핑도 힘들 수 밖에 없습니다.

 

그럼 일반 사용자는 고정 IP를 못 가지는 걸까요?

꼭 그런 건 아닙니다. 일반 사용자도 고정 IP를 신청해서 사용할 수는 있습니다. 하지만 대부분의 가정용 인터넷 환경에서는 특별히 신청하지 않으면 동적 IP가 기본입니다. 일반적으로 고정 IP는 추가 비용을 지불해야 하고, 관리 비용도 증가하며 보안 측면에서도 동적 IP가 더 안전하다고 여겨지기 때문입니다.

 

 

SDP (Session Description Protocol)

“SDP는 어떤 정보를 담고 있길래 교환을 해야할까?”

내가 어떤 방식으로 미디어를 주고받을 수 있는지를 알려주는 설명서입니다.

WebRTC에서 피어 간 연결을 수립하기 위해, 각자의 환경과 능력을 문서 형태로 정리해서 서로 교환해야 합니다.

 

{
	"sdp" : "...", // 세션 설명 문자열
	"type": "offer" // 또는 "answer"
}

RTCPeerConnection의 createOffer() 또는 createAnswer() 호출을 통해서 자신의 SDP를 생성하면 sdp와 type 필드를 가지는 객체가 생성됩니다.

 

v=0 
o=- 2011585323452908947 2 IN IP4 127.0.0.1 
s=-
t=0 0 
a=group:BUNDLE 0 1
a=extmap-allow-mixed
a=msid-semantic: WMS f5471704-1d3a-4ee9-904d-88c34dd79e39 
m=audio 9 UDP/TLS/RTP/SAVPF 111 63 9 0 8 13 110 126 
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:OrFD 
a=ice-pwd:8+5g70q/An4QYpxFt9XxErsN 
a=ice-options:trickle 
a=fingerprint:sha-256 CF:06:5C:E1:57:D0:C1:B4:13:72:25:85:57:C6:36:7E:CC:E2:67:44:DA:DD:5F:E9:A5:19:52:5F:3C:6E:A9:5B 
a=setup:actpass 
a=mid:0 
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level 
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid
a=sendrecv
a=msid:f5471704-1d3a-4ee9-904d-88c34dd79e39 c9076eae-d8c4-4535-b702-ab5ee80b0781 // WebRTC에서 media stream과 track 식별자 지정
a=rtcp-mux 
a=rtcp-rsize
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc 
a=fmtp:111 minptime=10;useinbandfec=1 
.
.
.

위 데이터는 생성한 SDP 데이터 일부를 가져온 것입니다.

어떤 미디어를, 어떤 방식으로, 어떤 코덱으로 보낼 수 있는지를 기술한 정보 집합입니다.

 

“왜 각자의 SDP 를 교환해야할까”

각 피어의 브라우저는 서로 다른 네트워크 구성, NAT, 코덱 지원, 트랙 개수 등 다른 환경 입니다. 서로 어떤 조건으로 미디어를 주고받을 수 있는지 합의하기 위해 offer(caller의 SDP)와 answer(callee의 SDP)를 주고받아야 합니다.

• offer(SDP): Caller가 자신의 조건을 먼저 제안
• answer(SDP): 받은 offer에 대해서 Callee가 이를 수용하거나 조정해서 응답

양쪽이 서로 수용 가능한 조건에 합의하면 ICE Candidate 교환을 통해 실제 네트워크 상에서 연결을 수립하게 됩니다.

 

 

ICE Candidate (Interactive Connectivity Establishment)

P2P 연결을 맺기 위해 가능한 모든 네트워크 경로 후보(IP:PORT)를 나열한 정보입니다.

 

"candidate:1025593763 1 udp 2122260223 192.168.0.44 51935 typ host generation 0 ufrag JuFu network-id 1 network-cost 10"

위 데이터는 실제 수집한 ICE Candidate 중 하나입니다.

 

연결 유형, IP 주소, PORT 번호, 우선순위, 전송 방식 등 네트워크 연결을 위한 정보가 포함되어 있습니다.

각 피어는 로컬 IP, STUN, TURN 등에서 다양한 후보 경로를 수집합니다. 상대방과 직접 연결이 가능한 경로를 테스트하기 위해 모든 후보를 서로에게 전달합니다. 후보들을 받은 뒤, 가장 원활한 경로를 선택해 연결을 수립합니다.

 

서로의 SDP만 주고 받았다면 연결 방식은 알 수 있지만 어디로 연결할지 알 수 없습니다. ICE Candidate만 있으면 어디로 연결하지는 알 수 있지만, 어떻게 연결할지 알 수 없습니다. 결국에는, 연결하길 원하는 피어 간 SDP와 ICE Candidate 가 둘 다 정상 교환 되어야 안정적인 화상채팅을 진행할 수 있습니다.

 

 

STUN / TURN

앞에서 ICE Candidate는 “P2P 연결을 맺기 위해 가능한 모든 네트워크 경로 후보(IP:PORT)를 나열한 정보”라고 했습니다. 그런데 이 후보들은 어떻게, 어디서 수집되는 걸까요?

바로 STUN과 TURN 서버의 도움을 받아야 가능한 이야기입니다.

 

“STUN이 뭐죠? 개발자가 직접 구현해야 하나요?”

STUN (Session Traversal Utilities for NAT)는 자신을(NAT 뒤에 숨어있는 일반 유저) 외부(NAT 가 노출한 공인 IP:PORT)에서 봤을 때 어떤 IP와 포트를 사용 중인지 알려주는 서버입니다.

 

일반 사용자는 대부분 NAT 뒤에 있어서 내부 IP만 알고 있습니다 (예: 192.168.x.x). WebRTC 연결을 위해선 상대방에게 공인 IP:PORT 정보를 알려줘야 합니다. 이때 STUN 서버에 요청을 보내면, 외부 기준의 IP:PORT를 알려줍니다.

 

STUN은 별다른 인증 없이 public STUN 서버를 사용할 수 있습니다. 개발자가 직접 구축하지 않아도 된다는 말이 되겠네요. 비교적 리소스 부담이 적고 무상 제공이 가능하기 때문이라고 하는데, 자주 사용되는 STUN 서버는 stun.l.google.com:19302 이고, 다른 서드 파티 STUN 서버들도 여럿 존재합니다.

 

“STUN만 있으면 될 것 같은데, TURN 은 또 뭐죠? 이건 직접 구현해야 하나요?”

STUN 을 통한 외부 노출 IP:PORT 를 얻는 연결 자체를 차단하거나 방화벽 이슈, 대칭 NAT 구조로 인해 연결이 불가능할 수 있습니다. 이 때, 최후의 수단이 TURN (Traversal Using Relays around NAT) 입니다.

 

🤔 대칭 NAT란?

대칭 NAT는 매핑한 공인 IP:PORT를 특정 목적지에 한정합니다.
STUN을 통해서 노출된 공인 IP:PORT쌍을 알아냈다고 해도, 해당 IP:PORT는 STUN을 위한 주소이고 STUN이 아닌 다른 주소지에서 STUN을 통해 얻은 공인 IP:PORT 로 연결을 시도하면 NAT는 해당 주소의 요청을 인식하지 못합니다.

정리하자면, 대칭 NAT환경에선 STUN으로 얻은 IP:PORT는 "STUN의 요청만" 받아들일 수 있는 주소가 됩니다. 그러므로, 해당 주소로 STUN이 아닌 다른 사용자가 요청을 시도할 수 없게 됩니다.

 

TURN은 STUN으로 직접 연결이 안 되면, 중계 서버를 통해 통신할 수 있도록 해주는 서버입니다.

TURN 서버는 자신의 IP와 포트를 임대해주고, 클라이언트 간 트래픽을 중간에서 대신 전달합니다. 이렇게 연결이 수립되고 화상채팅을 진행한다면, 실제로 P2P가 아닌 TURN 경유한 형태로 미디어 스트림을 주고 받게 됩니다. 결국 P2P 연결은 실패했지만, 서버를 거치는 안정적인 연결로 이어질 수 있는거죠.

 

TURN은 개발자가 직접 구축할 수도 있고, 클라우드 서비스도 존재합니다.

제가 팀 프로젝트를 진행했을 땐, 오픈 소스인 coturn 을 따로 배포하여 최후의 수단인 릴레이 연결이 수행되도록 구현했었습니다. coturn 을 직접 배포하는 것 말고도 유용한 기술들이 많은 것으로 알고 있으니, 실제 서비스에 적용하고 싶으시다면 한 번 찾아보시면 좋을 것 같습니다 🙂

 

 

그럼 이제, WebRTC의 P2P 화상채팅 연결을 이해하기 위한 관련 키워드 Signaling, NAT, SDP, ICE Candidate, STUN/TURN을 알게됐으니, 뚱이와 스폰지밥의 화상채팅을 위한 연결 과정을 완성된 그림으로 다시 한 번 보겠습니다.

 

먼저 STUN 으로 얻은 ICE Candidate로 연결 가능한 경우, Signaling의 흐름을 보겠습니다.

1. 뚱이와 스폰지밥이 Signaling Server를 통해서 SDP를 교환합니다.
   • caller의 SDP = offer
   • callee의 SDP = answer
2. 뚱이와 스폰지밥이 서드 파티의 STUN 서버를 사용해서 ICE Candidate를 수집합니다.
3. 각각 STUN을 통해 수집한 ICE Candidate를 Signaling Server 를 통해 교환합니다.
4. 뚱이와 스폰지밥은 교환한 ICE Candidate를 통해 P2P 연결에 성공합니다.

 

STUN만으로는 불가능 한 상황에서 TURN의 도움을 받는 Signaling의 흐름을 보겠습니다.

1. 뚱이와 스폰지밥이 Signaling Server를 통해서 SDP(caller는 offer, callee는 answer) 를 교환합니다.
2. 뚱이와 스폰지밥이 서드 파티의 STUN 서버를 사용해서 ICE Candidate를 수집합니다.
3. 각각 STUN을 통해 수집한 ICE Candidate를 SDP처럼 Signaling Server 를 통해 교환합니다.
   • 이때, 서로 주고받은 STUN 기반 ICE Candidate로 연결을 시도했지만 실패합니다.
4. 뚱이와 스폰지밥이 개발자가 직접 구축한 TURN 서버를 활용하여 ICE Candidate를 수집합니다.
   • TURN을 통해 수집한 ICE Candiate를 사용하면 사실상 P2P가 아닌 TURN을 경유하는 연결이 설립됩니다.
5. 각각 TURN을 통해 수집한 ICE Candidate를 Signaling Server 를 통해 교환합니다.
6. 뚱이와 스폰지밥은 TURN 의 ICE Candidate를 통해, P2P가 아닌 relay 기반 연결에 성공합니다.

 

 

 

🧹 핵심 정리

---

• WebRTC: P2P 기반 실시간 통신 기술
• Signaling: WebRTC 연결 전에 필요한 SDP와 ICE Candidate 교환
• SDP: 어떤 방식으로 미디어를 송수신할 수 있는지에 대한 설명서
• ICE Candidate: 사용할 수 있는 IP:PORT 후보 목록
• STUN: 자신의 공인 IP와 PORT 식별
• TURN : P2P 연결이 불가능할 때 중계 서버 역할

 

 

 

👋🏻 마치며

---

지금까지 WebRTC의 기본 개념부터 동작 원리, 그리고 연결 과정까지 정리해보았습니다.

이론을 바탕으로 한 실습을 원하신다면 아래 포스팅을 확인해주시면 됩니다. 실습은 WebRTC & 스프링부트 & 리액트 기반 1대 1 통화기능 구현입니다

 

 

[WebRTC] WebRTC 화상채팅 실습 (SpringBoot + React)

 

 

읽어주셔서 감사합니다.

궁금한 점에 대한 질문 환영합니다!

부족한, 잘못된 설명이 있다면 알려주시면 감사하겠습니다 🙏🏻

 

 

 

📚 Reference

---

Network address translation - Wikipedia

BlogGeek.me | The leading authority on WebRTC

WebRTC