화상회의에서 상대의 목소리가 들립니다.
그 소리는 회사 서버를 거쳐서 온 게 아닙니다.
상대의 노트북에서 내 노트북으로 곧장 넘어왔습니다.
이걸 가능하게 하는 기술이 WebRTC입니다.
그런데 "실시간"이라는 말 때문에 웹소켓과 자주 헷갈립니다.
둘은 경쟁 관계가 아닙니다.
무엇이고, 웹소켓과 뭐가 다르고, 어디에 쓰이는지 정리했습니다.
브라우저끼리 직접 연결합니다
보통의 웹은 전부 서버를 거칩니다.
내가 올린 사진도 서버에 저장됐다가 상대에게 갑니다.
WebRTC는 이 중간을 건너뜁니다.
브라우저와 브라우저가 직접 통로를 뚫습니다.
설치할 프로그램도 플러그인도 없습니다.
브라우저에 이미 들어 있는 기능입니다.
2021년 1월 W3C 정식 표준으로 확정됐습니다.
암호화는 선택 사항이 아닙니다.
규격상 암호화되지 않은 연결은 아예 열리지 않습니다.
직접 연결인데 서버가 필요합니다
두 사람 모두 공유기 뒤에 숨어 있기 때문입니다.
서로의 진짜 주소를 모릅니다.
그래서 서버 세 종류가 따로 붙습니다.
시그널링 서버는 소개를 맡습니다.
"이런 화질로 통화 가능한가요"를 대신 전달합니다.
STUN 서버는 거울 역할입니다.
"당신의 바깥 주소는 이겁니다"라고 알려줍니다.
TURN 서버는 우회로입니다.
직접 연결이 끝내 실패하면 트래픽을 대신 날라줍니다.
실제 통화의 약 20%가 TURN을 거칩니다. 회사 방화벽 안에서는 이 비율이 더 올라갑니다.
TURN은 영상을 그대로 통과시킵니다.
그래서 여기서 대역폭 비용이 발생합니다.
웹소켓과 뭐가 다를까
첫째, 나르는 짐이 다릅니다.
웹소켓은 텍스트와 이벤트를 나릅니다.
채팅 한 줄, 주문 알림, 시세 숫자입니다.
WebRTC는 소리와 영상을 나릅니다.
용량이 비교가 되지 않습니다.
둘째, 손실을 대하는 태도가 반대입니다.
웹소켓은 순서와 도착을 보장합니다.
채팅은 한 글자만 빠져도 말이 안 되니까요.
미디어는 늦게 온 프레임을 그냥 버립니다.
0.5초 늦은 영상보다 살짝 깨진 지금 영상이 낫습니다.
| 구분 | 웹소켓 | WebRTC |
|---|---|---|
| 나르는 것 | 텍스트 · 이벤트 | 소리 · 영상 |
| 경로 | 서버를 거칩니다 | 브라우저끼리 직접 |
| 손실 처리 | 순서와 도착을 보장 | 늦은 프레임은 버림 |
| 서버 부담 | 연결 수만큼 증가 | 미디어는 거의 없음 |
그리고 반전이 하나 있습니다.
둘은 대부분 함께 쓰입니다. 앞에서 말한 시그널링을 웹소켓으로 구현하는 경우가 많습니다.
참가자가 늘면 구조가 바뀝니다
1:1 통화는 직접 연결로 충분합니다.
문제는 인원이 늘어날 때입니다.
5명이 전부 직접 연결하면 각자 영상 4개씩을 올려보내야 합니다.
노트북 팬이 돌고 배터리가 녹습니다.
그래서 중계 서버(SFU)를 둡니다.
내 영상은 서버로 한 번만 올립니다.
서버가 나머지 참가자에게 나눠서 뿌립니다.
다인원 화상회의는 대부분 이 구조입니다.
실제 서비스 사례 6가지
하나, 구글 미트. 설치 없이 브라우저만으로 회의방이 열립니다.
둘, 디스코드 음성 채널. 게임 중에도 지연이 체감되지 않습니다.
셋, 슬랙 허들. 클릭 한 번으로 통화가 시작됩니다.
넷, 줌 웹 버전. 앱 대신 브라우저로 들어가면 이 경로입니다.
다섯, 비대면 진료·상담의 화상채팅. 병원 앱 안에서 바로 얼굴을 봅니다.
여섯, 화면 공유 원격 지원. 카메라 대신 화면을 실어 보냅니다.
여섯 가지에 공통점이 있습니다.
몇 초만 늦어도 대화가 성립하지 않습니다.
마치며
지연 시간은 보통 0.2초에서 0.5초입니다.
일반 라이브 방송(HLS)은 2초에서 30초입니다.
그럼 전부 이 기술로 바꾸면 될까요.
아닙니다.
시청자가 수만 명인 일방향 방송에는 HLS가 낫습니다.
CDN에 얹어서 훨씬 싸게 뿌릴 수 있기 때문입니다.
기준은 하나로 정리됩니다.
시청자가 대화에 끼어들어야 하는가.
끼어들어야 하면 WebRTC, 보기만 하면 HLS입니다.
함께 읽어보세요 — 웹소켓을 언제 쓰고 언제 피해야 하는지 · SSE로 AI 답변을 한 글자씩 흘려보내는 원리 · 에그코드 앱 개발 서비스