서론

안녕하세요 프론트엔드 개발자 여찬규입니다! 현재 재직 중인 회사에서 원격 솔루션을 개발하고 있는데요
그 중 제가 담당하고 있는 서비스의 가장 핵심 기능이 실시간 영상 상담인데, 이 모든 것의 기반 기술이 바로 WebRTC(Web Real-Time Communication)입니다.

처음WebRTC를 접했을 때는 브라우저에서 영상 통화를 할 수 있게 해주는 기술 정도로만 이해했습니다.
그러나 실제 운영 환경에서 WebRTC를 다뤄보니, 단순한 영상 통화를 넘어서 네트워크, 시그널링, NAT 우회 등이 얽혀 있으며 모든 실시간 상호작용을 가능하게 하는 기반 기술이라는 것을 알게 되었습니다.

이번 글은 WebRTC 박살내기 시리즈의 시작으로, WebRTC를 처음 접하는 개발자도 이해할 수 있도록 WebRTC의 기본 개념부터 실제 연결 구조, 그리고 핵심 기술들을 차근차근 정리해보겠습니다.

WebRTC 정의와 특징

WebRTC란?

WebRTC는 W3C와 IETF에서 표준화한 오픈 웹 기술로, 웹 브라우저나 네이티브 앱에서 플러그인 없이 실시간 음성, 영상, 데이터 전송을 가능하게 해줍니다.
2011년 Google이 오픈소스 프로젝트로 공개한 기술로, 현재는 모든 주요 브라우저에서 지원하는 웹 표준이 되었습니다.

우리가 일상적으로 사용하는 Google Meet, Zoom, Discord, ZEP 같은 화상 회의 서비스부터, 브라우저 기반 게임의 실시간 데이터 전송, P2P 파일 공유까지 다양한 분야에 활용되고 있습니다.

특히 서버 없이 P2P(Peer To Peer)로 연결되어 데이터를 주고받을 수 있다는 점이 특징입니다.
물론 P2P 연결을 위한 초기 과정에서는 시그널링 서버가 필요하지만, 일단 연결이 성립되면 피어끼리 직접 통신합니다.

WebRTC의 주요 특징

WebRTC가 기존 웹 기술과 다른 점은 다음과 같습니다.

플러그인 불필요

Flash나 ActiveX 같은 별도 플러그인 없이 브라우저 자체에서 지원합니다.

P2P 통신 기반

피어끼리 직접 연결하여 지연 시간과 서버 비용을 절감합니다.

다양한 데이터 전송 지원

오디오·비디오뿐만 아니라 텍스트, 파일 등 모든 종류의 데이터 전송이 가능합니다.

보안 내장

모든 미디어와 데이터가 DTLS와 SRTP로 암호화되어 전송됩니다.

💡 DTLS와 SRTP란?
DTLS(Datagram Transport Layer Security)는 패킷 손실이 있는 환경에서도 안전하게 키 교환과 인증을 제공하는 보안 프로토콜이고, SRTP(Secure Real-time Transport Protocol)는 DTLS로 교환된 키를 이용해 실시간 오디오·비디오 스트림을 암호화하는 프로토콜입니다.

다양한 코덱 지원

WebRTC는 다양한 비디오 코덱을 지원합니다

• VP8: 필수 코덱으로 모든 WebRTC 구현체에서 지원
• H.264: 필수 코덱으로 하드웨어 가속을 활용한 효율적인 인코딩/디코딩 가능
• VP9: 선택 코덱으로 VP8보다 개선된 압축 효율 제공
• AV1: 2024년 8월 RFC 9634로 공식 표준화된 차세대 코덱
  • VP9 대비 약 30% 향상된 압축 효율
  • Chrome/Edge 93+, Firefox 111+에서 지원
  • 낮은 대역폭 환경에서 고품질 영상 전송에 유리

코덱 선택은 RTCRtpSender.setParameters()를 통해 우선순위를 지정하거나, SDP 협상 과정에서 결정됩니다.

WebRTC의 장점

낮은 지연 시간 (Low Latency)

인스타그램 라이브, 유튜브 라이브, 트위치 등은 RTMP를 사용해 보통 2-5초의 지연 시간을 가집니다.
반면 WebRTC는 P2P 연결 시 50-200ms, SFU 사용 시 200-500ms의 매우 낮은 지연 시간으로 거의 실시간에 가까운 통신이 가능합니다.

💡 Latency란?
네트워크에서 요청을 보내고 응답을 받기까지 걸리는 시간을 뜻합니다. 지연 시간이 짧을수록 오디오·비디오 통화가 끊기지 않고 자연스럽게 전달됩니다.

개발 진입장벽이 낮음

웹 표준 기술이므로 별도의 복잡한 미디어 송출 소프트웨어나 서버 설치 없이도 비교적 쉽게 실시간 통신 기능을 구현할 수 있습니다.

무료 기술

오픈 웹 표준으로 라이선스 비용이 없고, Google, Apple 등 주요 브라우저 벤더들이 지속적으로 지원하고 있습니다.

WebRTC의 한계점

이러한 장점들이 있지만 한계점도 존재합니다.

브라우저 호환성 문제

Chrome, Firefox, Safari, Edge 등 모던 브라우저에서는 잘 지원되지만, 구버전 브라우저에서는 제대로 작동하지 않을 수 있습니다.

STUN/TURN 서버 의존성

P2P 통신을 위해서는 NAT 뒤에 있는 사용자들의 실제 IP 주소를 찾아야 하는데, 이를 위해 STUN 서버가 필수적입니다.
복잡한 네트워크 환경에서는 TURN 서버도 필요해 추가적인 인프라 비용이 발생합니다.

STUN과 TURN 그리고 NAT에 대한 내용은 조금 뒤에 더 자세하게 다루겠습니다.

WebRTC 연결 과정

WebRTC 연결은 생각보다 복잡한 과정을 거칩니다.
마치 두 사람이 처음 만나서 대화하기 위해 서로 언어를 확인하고, 만날 장소를 정하는 것과 비슷합니다.

전체적인 연결 흐름은 다음과 같습니다.

1. 시그널링 서버 연결
2. Offer/Answer 교환 (SDP를 통한 미디어 협상)
3. ICE 후보 수집 및 교환
4. 연결 확립 및 미디어 스트림 전송

Step 1. 시그널링 (Signaling)

시그널링은 두 피어가 직접 연결되기 전에 서로 통신을 준비하기 위한 정보 교환 과정입니다.
쉽게 말해 "너 어떤 코덱 쓸 거야?", "네트워크 주소는 뭐야?" 같은 초기 협상 대화입니다.

WebRTC 표준에는 시그널링 방식이 정의되어 있지 않습니다.

🧐 왜 표준에 정의가 안되어있을까?
서비스마다 요구사항과 인프라가 달라서, 특정 프로토콜을 강제하기보다 개발자가 환경에 맞게 자유롭게 구현할 수 있도록 열어두었기 때문입니다.

따라서 개발자가 WebSocket, Socket.IO, REST API 등을 활용해 별도의 시그널링 서버를 구현해야 합니다.
최근에는 WHIP(WebRTC HTTP Ingestion Protocol)와 WHEP(WebRTC HTTP Egress Protocol) 같은 표준화된 HTTP 기반 시그널링 방식도 등장하고 있습니다.

Step 2. Offer/Answer 교환 (SDP를 통한 미디어 협상)

시그널링 서버를 통해 Offer SDP와 Answer SDP를 교환합니다.

이 단계에서는 "우리가 어떤 방식으로 통신할까?"를 결정합니다.

• Caller(발신자): 나는 이런 코덱과 해상도를 지원해 (Offer)
• Receiver(수신자): 그럼 우리는 이 방식으로 하자 (Answer)
• 양쪽이 공통으로 지원하는 최적의 미디어 설정으로 합의 완료

SDP에 대한 내용은 뒤에서 더 자세하게 다루겠습니다.

Step 3. ICE 후보 수집 및 교환

💡 ICE Candidate란?
WebRTC에서 두 피어가 연결될 수 있는 네트워크 경로 후보(주소 + 포트 + 프로토콜 정보)를 말합니다. 쉽게 말해 "이 IP와 포트로 연결할 수 있어!", "이 경유지(TURN 서버)로도 접근 가능해!" 같은 가능한 길목 리스트입니다.

이제 "어떤 경로로 데이터를 주고받을까?"를 찾는 단계입니다.

브라우저는 연결 가능한 모든 네트워크 경로 후보를 자동으로 수집하고, 가장 빠르고 효율적인 경로를 찾기 위해 다음 순서로 시도합니다

1. 같은 네트워크 내 직접 연결 (로컬 IP)
2. 인터넷을 통한 직접 연결 (STUN으로 찾은 공인 IP)
3. TURN 서버를 통한 중계 연결 (마지막 수단)

ICE와 STUN/TURN에 대한 자세한 내용은 뒤에서 다루겠습니다.

Step 4. 연결 확립 및 미디어 스트림 전송

모든 후보를 교환한 후 실제 연결 테스트를 수행합니다.
ICE가 각 후보 조합을 테스트해서 가장 안정적이고 빠른 경로를 선택하면, P2P 연결이 완성됩니다.

연결이 성립되면 다음과 같은 상황이 됩니다

• 시그널링 서버는 더 이상 필요하지 않음 (연결 과정에서만 사용)
• 모든 미디어 데이터가 피어 간 직접 전송
• 실시간 오디오·비디오·데이터 통신 시작

SDP

Offer와 Answer는 내부적으로 SDP(Session Description Protocol) 형식을 따릅니다.

SDP는 멀티미디어 세션(오디오, 비디오, 데이터 스트림 등)의 형식과 조건을 기술하는 표준 포맷입니다.
쉽게 말해 "내가 영상을 720p 해상도, H.264 코덱, Opus 오디오로 보낼 거야. 암호화는 이렇게 할 거야" 같은 컨텐츠에 대한 메타데이터 설명서입니다.

SDP 자체가 실제 미디어 데이터를 포함하지는 않고, 두 피어가 어떤 방식으로 데이터를 주고받을지 협상하는 데 사용됩니다.

SDP의 구조

SDP는 크게 두 부분으로 나뉩니다.

세션(Session) 수준 정보: 버전, 세션 ID, 네트워크 타입, 시간 정보
미디어(Media) 수준 정보: 사용할 코덱, 포트 번호, 전송 방향

주요 SDP 필드

SDP 예시

v=0  
o=- 46117327 2 IN IP4 127.0.0.1  
s=-  
c=IN IP4 192.168.0.10  
t=0 0  
m=audio 49170 RTP/AVP 0  
a=rtpmap:0 PCMU/8000  
m=video 5004 RTP/AVP 96  
a=rtpmap:96 H264/90000  

NAT와 네트워크 장벽

NAT란?

현실적으로 대부분의 사용자는 공유기나 방화벽 뒤에 있어서 NAT(Network Address Translation) 환경에 있습니다.

NAT는 내부 네트워크의 사설 IP(192.168.x.x)를 외부 인터넷의 공인 IP로 변환해주는 기술입니다.
이를 통해 제한된 공인 IP 주소로 여러 대의 기기가 인터넷을 사용할 수 있게 됩니다.

NAT가 WebRTC에 문제가 되는 이유

일반적인 웹 서비스에서는 클라이언트가 서버로 요청을 보내는 단방향 통신이므로 NAT가 큰 문제가 되지 않습니다.
그러나 WebRTC는 P2P 통신을 기본으로 하기 때문에 다음과 같은 문제가 발생합니다.

직접 연결의 어려움

외부에서 NAT 뒤의 기기로 직접 연결을 시작할 수 없고, 사설 IP는 인터넷에서 라우팅되지 않습니다.

NAT 타입별 제약

• Full Cone NAT: 비교적 연결이 쉬움
• Restricted Cone NAT: 특정 조건에서만 연결 가능
• Port Restricted Cone NAT: 더 엄격한 제한
• Symmetric NAT: 가장 제한적, 직접 연결이 거의 불가능

추가적인 네트워크 장벽

• 기업 방화벽: UDP 트래픽을 차단하는 경우가 많음
• 이중 NAT: 공유기 뒤에 또 다른 공유기가 있는 복잡한 구조

STUN/TURN/ICE

STUN (Session Traversal Utilities for NAT)

const peerConnection = new RTCPeerConnection({  
	iceServers: [{ urls: "stun:stun.l.google.com:19302" }]  
});  

STUN 서버는 NAT 환경에서 피어가 자신의 공인 IP와 포트를 확인할 수 있게 도와줍니다.
피어는 STUN 서버에 요청을 보내고, STUN 서버는 해당 요청이 어떤 공인 IP와 포트에서 왔는지 알려줍니다.

장점: 가볍고 빠름, 무료 서비스 다수 존재
단점: Symmetric NAT 등 복잡한 환경에서는 직접 연결 불가능

TURN (Traversal Using Relays around NAT)

const peerConnection = new RTCPeerConnection({  
	iceServers: [  
		{ urls: "stun:stun.l.google.com:19302" },  
		{  
			urls: "turn:your-turn-server.com:3478",  
			username: "user",  
			credential: "password"  
		}  
	]  
});  

TURN 서버는 STUN으로 해결할 수 없는 상황에서 사용되는 중계 서버입니다.
모든 미디어 트래픽을 TURN 서버가 대신 받아서 상대방에게 전달합니다.
직접 P2P 연결이 불가능한 경우의 최후의 수단입니다.

장점: 어떤 복잡한 네트워크 환경에서도 연결 보장
단점: 높은 서버 비용, 대역폭 소모, 지연 시간 증가

ICE (Interactive Connectivity Establishment)

ICE는 STUN과 TURN을 포함하는 통합 솔루션으로, 두 피어 간의 최적의 통신 경로를 찾는 프레임워크입니다.

ICE 작동 흐름

1. 후보 수집: 브라우저가 모든 가능한 연결 후보를 수집
2. 후보 교환: 시그널링 서버를 통해 피어끼리 후보 정보 교환
3. 연결 테스트: 모든 후보 조합에 대해 실제 연결 테스트 수행
4. 경로 선택: 가장 우선순위가 높고 안정적인 경로 선택

ICE는 지연 시간이 가장 짧은 경로를 찾기 위해 다음 순서로 연결을 시도합니다

1. 직접 UDP 연결 (사설 IP, STUN 사용)
2. TCP 연결 (HTTP/HTTPS 포트)
3. TURN 서버를 통한 간접 연결

이런 방식으로 ICE는 최대한 직접 연결을 시도하되, 불가능한 경우에만 TURN 서버를 사용하여 비용과 성능의 균형을 맞춥니다.

Trickle ICE

기존 ICE는 모든 후보를 수집한 후에 교환하기 때문에 연결 시작이 느렸습니다.
Trickle ICE는 후보를 찾는 즉시 상대방에게 전송하여 연결 시간을 크게 단축시킵니다.

작동 방식

1. 로컬 후보 발견 즉시 시그널링으로 전송
2. 원격 후보 수신 즉시 연결 테스트 시작
3. 모든 후보 수집이 완료되지 않아도 연결 가능

현재 대부분의 WebRTC 구현은 Trickle ICE를 기본으로 사용합니다.

WebRTC 아키텍처 패턴

다자간 통신에서는 단순한 1:1 P2P로는 한계가 있습니다.
참가자 수와 서비스 특성에 따라 적합한 아키텍처가 다릅니다.

P2P는 WebRTC의 기본이지만, 참가자가 많아지면 과부하가 발생합니다.
N명이 참여하면 N(N-1)/2 개의 연결이 필요하게 되어, 10명이면 총 45개의 연결이 생성됩니다.

그래서 상황에 맞는 다른 아키텍처들이 필요하게 됩니다

Mesh (P2P)

동작 방식

가장 단순한 구조로, 모든 피어가 서로 직접 연결됩니다.
각 피어는 자신의 영상을 인코딩하고, 다른 모든 참가자에게 각각 별도로 전송합니다.

인코딩/디코딩 부하

• 인코딩: 다른 참가자 수만큼 인코딩 (N-1번)
• 디코딩: 다른 모든 참가자의 영상을 각각 디코딩 (N-1개)
• 업로드 대역폭: 참가자 수에 비례하여 증가 (N-1배)

5명이 참가한 회의를 예로 들면?

• 내가 보내는 영상: 4번 인코딩 (A, B, C, D에게 각각)
• 받아서 재생해야 하는 영상: 4개 디코딩
• 업로드 대역폭: 720p 기준 약 4-5Mbps 필요

문제는 인코딩과 업로드 대역폭입니다.
각 참가자마다 별도로 인코딩해야 하므로 CPU/GPU 부하가 급증하고, 가정용 인터넷의 업로드속도(평균 5-10Mbps)로는 5-6명 이상부터 버거워집니다.

적합한 사용 사례

• 소규모 회의 (2-4명)
• 1:1 화상 통화
• 서버 비용 없이 낮은 지연시간이 필요한 경우

SFU (Selective Forwarding Unit)

동작 방식

서버가 중계 역할을 하는 구조입니다.
각 피어는 자신의 영상을 서버에 1번만 전송하고, 서버는 받은 영상을 그대로 다른 참가자들에게 전달합니다.

핵심은 서버가 인코딩·디코딩을 하지 않는다는 점입니다.
서버는 단순히 데이터 패킷을 받아서 전달만 합니다.

인코딩/디코딩 부하

• 서버: 인코딩·디코딩 없음 (단순 전달만)
• 피어 인코딩: 자신의 영상 1개만 인코딩 (Mesh와 달리 1번만!)
• 피어 디코딩: 다른 참가자 영상들을 각각 디코딩 (Mesh와 동일)
• 업로드 대역폭: 서버에만 전송 (1배)

5명이 참가한 회의를 예로 들면?

• 내가 서버로 보내는 영상: 1번만 인코딩
• 서버에서 받아서 재생하는 영상: 4개 디코딩
• 업로드 대역폭: 720p 기준 약 1-1.5Mbps만 필요

디코딩 부하는 여전히 피어가 담당하지만, 인코딩과 업로드 대역폭이 크게 줄어드는 것이 가장 큰 장점입니다.
또한 서버에서 각 피어의 네트워크 상황에 맞게 화질을 조절(Simulcast)하거나, 현재 발언자 강조 같은 최적화도 가능합니다.

적합한 사용 사례

• 중대규모 화상 회의 (5-100명)
• Google Meet, Zoom 같은 화상 회의 서비스
• 서버 비용은 발생하지만, 피어의 인코딩 부담과 업로드 대역폭 절약

MCU (Multipoint Control Unit)

동작 방식

서버가 모든 참가자의 영상을 하나로 합쳐서 피어에게 전달합니다.
마치 TV 뉴스에서 여러 화면을 격자로 보여주는 것처럼, 서버가 모든 영상을 실시간으로 합성합니다.

핵심은 피어는 항상 1개의 합성된 스트림만 받는다는 점입니다.

인코딩/디코딩 부하

• 서버: 모든 참가자 영상을 디코딩 → 합성 → 1개로 다시 인코딩 (매우 높은 CPU 부하)
• 피어 인코딩: 자신의 영상 1개만 인코딩 (SFU와 동일)
• 피어 디코딩: 서버에서 보낸 합성된 영상 1개만 디코딩
• 다운로드 대역폭: 합성된 1개 스트림만 수신 (1배)

5명이 참가한 회의를 예로 들면?

• 서버가 하는 일: 5개 영상을 각각 디코딩 → 하나로 합성 → 다시 인코딩
• 내가 받아서 재생하는 영상: 합성된 1개만 디코딩
• 다운로드 대역폭: 720p 기준 약 1-1.5Mbps만 필요

피어 입장에서는 참가자가 100명이든 1개 영상만 디코딩하면 되므로 저사양 기기나 모바일에서도 안정적입니다.
데이터 사용량도 항상 일정해서 예측 가능합니다.

하지만 서버가 실시간으로 수십 개의 영상을 디코딩하고 합성해서 다시 인코딩해야 하므로 CPU 사용량이 매우 높습니다.
이 과정에서 지연 시간이 발생할 수 있어 실시간성이 다소 떨어질 수 있습니다.

적합한 사용 사례

• 대규모 웨비나나 강의 (100명 이상)
• 저사양 기기 지원이 필수적인 환경
• 제한된 데이터 요금제 사용자가 많은 경우
• 모든 참가자에게 동일한 화면을 보여줘야 하는 경우

아키텍처 비교 요약

정리

WebRTC는 단순한 영상 통화 기술을 넘어서, 네트워크, 시그널링, 보안, 아키텍처가 종합적으로 얽힌 복합 기술입니다.

• P2P 기반 실시간 커뮤니케이션 - 낮은 지연시간과 서버 비용 절약
• Offer/Answer, ICE, 시그널링 - 체계적인 연결 과정
• STUN/TURN/ICE - NAT 문제 해결을 위한 필수 기술
• 아키텍처 패턴 - 규모에 따른 Mesh, SFU, MCU 선택

처음에는 복잡해 보이지만, 각 단계별로 차근차근 이해하면 WebRTC의 전체 그림이 보일 것입니다.
다음 글에서는 WebRTC의 미디어 스트림과 트랙에 대해 다뤄보겠습니다.