자바 공부/스프링공부

웹RTC(WebRTC)-1

ari0930 2025. 12. 4. 15:46

WebSocket으로 실시간 영상 전송 시 발생하는 문제와 WebRTC를 통한 해결 방법

실시간 영상 전송을 구현할 때 많은 개발자가 처음 떠올리는 방식은 WebSocket이다.

양방향 통신이 가능하고 다양한 환경에서 쉽게 구현할 수 있기 때문이다.

나 또한 IoT 기기에서 찍힌 실시간 영상을 WebSocket을 통해 전송하는 구조를 사용하면서 몇 가지 한계를 경험했다.

이 글에서는 WebSocket 기반 영상 전송의 문제점,

그리고 이를 해결하기 위해 등장한 WebRTC의 구조·동작 방식·장단점을 정리한다.

1. WebSocket으로 영상 스트리밍을 구현할 때의 문제점

WebSocket은 메시지 기반의 양방향 실시간 통신에 매우 적합하지만,

영상·음성 전송에는 구조적으로 큰 한계가 존재한다.

1) 서버를 반드시 경유하는 구조(Server Relay)

WebSocket은 기본적으로 다음과 같은 구조를 가진다:

Client A → WebSocket Server → Client B

즉, 모든 영상 프레임이 서버를 거쳐야 한다.

문제가 되는 이유는?

  • 서버가 업로드와 다운로드를 모두 처리 → 대역폭 2배 소모
  • 서버가 병목(Bottleneck)이 되어 FPS ↓, latency ↑
  • 클라이언트 수가 늘어날수록 서버 부하 급증
  • Base64 인코딩 등으로 데이터 크기가 커지며 전송 비효율 발생

실제로 고화질 영상을 30FPS 이상으로 보내면

서버 CPU, 네트워크 사용량이 폭발하면서 프레임 드랍과 지연이 심해지는 현상이 쉽게 발생한다.

2. WebRTC는 어떻게 이 문제를 해결할까?

WebRTC(Web Real-Time Communication)는

브라우저 간 P2P 실시간 통신을 위한 표준 기술이다.

WebSocket과 가장 큰 차이는 다음 한 줄로 요약된다:

WebRTC는 서버를 거치지 않고 클라이언트끼리 직접(P2P) 영상·음성을 전송한다.

💡 WebRTC의 핵심 특징

✔ 1) P2P 연결 (Peer-to-Peer)

전송 경로는 다음과 같다:

Client A ↔ Client B

서버는 연결 초기 설정과 시그널링에만 관여하며

실제 영상 데이터는 직접 연결을 통해 주고받는다.

→ 지연(latency)이 크게 감소

→ 서버 부하가 사실상 0에 가까움

→ 고해상도 영상도 안정적으로 전송 가능


✔ 2) 영상·음성 코덱 내장

WebRTC는 스트리밍 특화 코덱을 기본 지원한다.

  • VP8 / VP9H.264
  • Opus(음성 처리)

즉, Base64 같은 비효율적인 방식이 아니라

최적화된 인코딩으로 전송한다.


✔ 3) 네트워크 품질 적응 (Bandwidth Adaption)

네트워크가 나빠지면:

  • 자동으로 비트레이트 감소
  • FPS 조절
  • 해상도 하향

네트워크가 좋아지면 다시 복구된다.

덕분에 영상 품질이 튀거나 끊기는 현상이 적다.


✔ 4) 데이터 채널(DataChannel)

영상·음성뿐 아니라 WebSocket처럼 일반 데이터(P2P)도 송수신 가능하다.


3. WebRTC는 어떻게 연결될까? (동작 방식)

WebRTC 연결 과정은 다음 3가지 요소가 핵심이다:

1) Signaling 서버

  • WebRTC가 P2P 연결을 생성하기 위해 필요한 SDP 정보와 ICE 후보를 교환하는 용도
  • WebSocket, HTTP 등 어떤 프로토콜이든 가능
  • 실제 영상 데이터는 시그널링 서버를 거치지 않는다

2) STUN 서버

  • 클라이언트의 공인 IP와 포트를 알려주는 서버
  • 방화벽/공유기 뒤에서도 P2P 연결 가능하게 해줌

3) TURN 서버 (Fallback)

  • P2P 연결이 도저히 불가능할 때
  • 중계(relay) 역할을 수행
  • 비용이 크기 때문에 가능한 사용 최소화

4. WebRTC의 장점과 단점

✅ 장점

1) 지연(latency)이 매우 낮음

  • P2P 직접 연결
  • 서버 병목 없음
  • → 화상회의, 원격제어, 실시간 영상 전송에 최적화

2) 서버 비용 감소

영상 데이터가 서버를 거치지 않기 때문에 트래픽 비용이 거의 발생하지 않는다.

3) 영상·음성 특화 코덱 자동 제공

개발자가 인코딩/디코딩을 직접 처리할 필요 없음.

4) 네트워크 자동 최적화

지연/비트레이트/FPS 등 자동 조절.


❌ 단점

1) 구현 난이도가 높음

WebSocket과 비교하면

시그널링, STUN, ICE 후보 교환, 연결 상태 관리 등 다룰 요소가 많다.

2) P2P 연결이 항상 가능한 것은 아님

기업 내부망, 방화벽, 대규모 NAT 환경에서는

P2P 연결이 어려워 TURN 서버가 필요한 경우도 있다.

3) 멀티 사용자(1:N, N:N)가 복잡해짐

  • Mesh 구조는 트래픽이 사용자 수만큼 증가
  • SFU 서버(Selective Forwarding Unit)를 구성해야 할 때도 있음
  • → Zoom, Google Meet이 사용하는 방식
반응형