적용 WebRTC #

이제 WebRTC가 어떻게 동작하는지 알았으니, 실제로 만들어볼 차례입니다! 이 장에서는 사람들이 WebRTC로 무엇을 만들고, 어떻게 만들고 있는지 살펴봅니다. WebRTC로 벌어지는 흥미로운 일들을 배우게 될 것입니다. 다만 강력함에는 대가가 있습니다. 프로덕션급 WebRTC 서비스를 구축하는 일은 도전적입니다. 이 장에서는 여러분이 마주치기 전에 그런 도전 과제를 미리 설명합니다.

사용 사례별 #

많은 이들이 WebRTC를 브라우저 화상회의 기술로만 생각하지만, 그 이상입니다! WebRTC는 매우 다양한 애플리케이션에 쓰입니다. 새로운 사용 사례도 계속 등장하고 있습니다. 여기서는 대표적인 사례와, WebRTC가 어떻게 변화를 이끄는지 소개합니다.

콘퍼런싱 #

콘퍼런싱은 WebRTC의 원조 사용 사례입니다. 브라우저에서 다른 프로토콜이 제공하지 못하는 핵심 기능을 갖추고 있습니다. WebSockets만으로도 이상적 환경에서는 회의 시스템을 만들 수 있겠지만, 실제 네트워크에서 배포하려면 WebRTC가 최선입니다.

WebRTC는 미디어를 위한 혼잡 제어와 적응형 비트레이트를 제공합니다. 네트워크 조건이 변해도 사용자는 가능한 최선의 경험을 얻게 됩니다. 개발자가 별도 측정 코드를 작성할 필요도 없습니다.

참가자는 여러 스트림을 보내고 받을 수 있으며, 통화 중 언제든 스트림을 추가/제거할 수 있습니다. 코덱 협상도 자동으로 이뤄집니다. 이 모든 기능은 브라우저가 제공하므로 개발자가 별도 코드를 작성할 필요가 없습니다.

콘퍼런싱은 데이터 채널에서도 이점을 얻습니다. 메타데이터를 보내거나 문서를 공유할 수 있습니다. 여러 데이터 스트림을 만들고, 신뢰성보다 성능을 우선하도록 구성할 수도 있습니다.

방송 #

방송 영역에서도 WebRTC를 사용하는 프로젝트가 빠르게 늘고 있습니다. 이 프로토콜은 발행자와 소비자 모두에게 장점이 있습니다.

브라우저에 내장되어 있어 사용자가 영상을 쉽게 발행할 수 있습니다. 별도 프로그램을 설치할 필요가 없습니다. 브라우저가 있는 플랫폼이면 어디서든 발행이 가능하며, 여러 트랙을 보내고 필요할 때 수정/제거할 수 있습니다. 연결당 오디오/비디오 한 개만 허용하던 레거시 프로토콜 대비 큰 진전입니다.

WebRTC는 지연 대 화질의 트레이드오프를 더 세밀하게 제어할 수 있습니다. 지연이 특정 임계치를 넘지 않는 것이 더 중요하고, 약간의 디코딩 아티팩트를 감수할 수 있다면, 도착 즉시 재생하도록 뷰어를 구성할 수 있습니다. TCP 위에서 동작하는 다른 프로토콜로는 쉽지 않습니다.

원격 접속 #

원격 접속은 WebRTC로 다른 컴퓨터를 원격으로 제어하는 것을 말합니다. 전체 시스템을 제어할 수도, 특정 애플리케이션만 제어할 수도 있습니다. 로컬 하드웨어로 수행하기 어려운 연산 집약 작업(최신 게임 실행, CAD 등)에 유용합니다. WebRTC는 세 가지 측면에서 이 영역을 혁신했습니다.

첫째, 전 세계 라우팅이 되지 않는 호스트에도 접속할 수 있습니다. NAT 우회를 통해 STUN만으로 접근 가능한 컴퓨터에 연결할 수 있습니다. 이는 보안과 프라이버시 측면에서 좋습니다. 비디오를 인제스트 서버나 점프 박스에 경유시킬 필요가 없습니다. 또한 포트 포워딩이나 고정 IP 준비 없이도 배포가 쉬워집니다.

둘째, 데이터 채널이 강력합니다. 최신 데이터만 수용하도록 설정할 수 있습니다. TCP에서는 HOL(Head-of-Line) 블로킹이 발생할 수 있어 오래된 마우스 클릭이나 키 입력이 늦게 도착해 이후 입력을 막을 수 있습니다. WebRTC 데이터 채널은 손실 패킷을 재전송하지 않도록 설정할 수 있고, 백프레셔를 측정해 네트워크 용량을 초과해 보내지 않도록 제어할 수 있습니다.

셋째, 브라우저에서 바로 사용할 수 있어 사용자 경험이 좋아졌습니다. 전용 클라이언트를 설치하지 않아도 세션을 시작할 수 있고, 스마트 TV 등 더 많은 클라이언트가 WebRTC를 내장하고 있습니다.

파일 공유와 검열 우회 #

파일 공유와 검열 우회는 전혀 다른 문제처럼 보이지만, WebRTC는 두 경우 모두에서 같은 문제를 해결합니다. 접근성을 높이고 차단을 어렵게 만듭니다.

첫째 문제는 ‘클라이언트 얻기’입니다. 파일 공유 네트워크에 참여하려면 클라이언트를 내려받아야 합니다. 네트워크가 분산되어 있어도 마찬가지입니다. 제약된 네트워크에서는 이 다운로드가 차단되기 쉽고, 다운로드하더라도 설치/실행을 못 할 수 있습니다. WebRTC는 이미 모든 브라우저에 있으므로 즉시 사용할 수 있습니다.

둘째 문제는 트래픽 차단입니다. 파일 공유에만 쓰이는 프로토콜을 사용하면 트래픽 특성만으로 차단되기 쉽습니다. 반면 WebRTC 트래픽은 일반 웹 트래픽과 구분하기 어렵고, UDP/TCP 조합과 포트도 다양해 차단이 쉽지 않습니다.

토폴로지별 #

WebRTC 애플리케이션을 설계할 때 사용할 수 있는 대표적인 연결 토폴로지는 다음과 같습니다.

1:1 #

가장 단순한 모델입니다. 한 사용자가 다른 사용자와 직접 연결합니다. 데이터 채널과 미디어 트랙을 원하는 대로 추가할 수 있습니다.

연결 형태는 다음과 같습니다.

풀 메시(Full Mesh) #

소규모 회의나 멀티플레이어 게임에 적합합니다. 모든 사용자가 서로에게 직접 연결합니다. 애플리케이션을 구축할 수 있지만 단점도 있습니다.

각 사용자가 통화 참여자마다 독립적으로 인코딩하여 업로드해야 합니다. 연결마다 네트워크 상태가 달라 같은 비디오를 재사용할 수 없습니다. 오류 처리도 어렵습니다. 전체 연결이 끊긴 것인지, 특정 피어와의 연결만 끊긴 것인지 신중히 판단해야 합니다.

이런 이유로 풀 메시 토폴로지는 소규모 그룹에 적합하며, 더 큰 규모에는 클라이언트/서버 토폴로지가 좋습니다.

하이브리드 메시 #

풀 메시의 문제를 일부 완화하는 대안입니다. 모든 사용자 사이에 직접 연결을 만들지 않고, 네트워크 내 다른 피어를 통해 미디어를 릴레이합니다. 원본 발행자가 미디어 배포에 쓰는 대역폭을 줄일 수 있습니다.

다만 단점도 있습니다. 원본 발행자는 자신의 비디오가 누구에게 전달되는지, 성공적으로 도착했는지 알기 어렵습니다. 또한 홉이 늘어날수록 지연이 증가합니다.

SFU(Selective Forwarding Unit) #

SFU는 풀 메시의 문제를 전혀 다른 방식으로 해결합니다. P2P 대신 클라이언트/서버 토폴로지를 구현합니다. 각 WebRTC 피어는 SFU에 연결해 자신의 미디어를 업로드하고, SFU는 이를 각 클라이언트로 전달합니다.

이 방식에서는 각 에이전트가 비디오를 한 번만 인코딩/업로드하면 됩니다. 시청자에게 배포하는 부담은 SFU가 집니다. 또한 SFU를 공인 주소에서 운영할 수 있어 연결성이 P2P보다 쉽습니다. NAT 매핑 걱정도 줄어듭니다. 다만 TCP 경로(ICE-TCP 또는 TURN) 노출은 여전히 필요합니다.

간단한 SFU는 주말 동안에도 만들 수 있지만, 모든 유형의 클라이언트를 잘 다루는 ‘좋은’ SFU를 만드는 일은 끝이 없습니다. 혼잡 제어, 오류 정정, 성능 튜닝은 지속적인 과제입니다.

MCU #

MCU(Multi-point Conferencing Unit)는 SFU처럼 클라이언트/서버 토폴로지이지만, 출력 스트림을 합성합니다. 개별 스트림을 그대로 배포하는 대신 하나의 피드로 다시 인코딩해 전달합니다.