웹RTC 6년, 어제와 오늘 그리고 미래(1)

[컴퓨터월드 기고]

웹RTC(WebRTC, Web Real Time Communication), 플러그인이나 설치 없이 브라우저만으로 실시간 화상통화와 데이터 통신을 할 수 있다는 그 매력에 빠진 사람들은 수년간 입에 달고 살았을 기술. 이렇게 이야기를 시작하는 이유는 우리나라의 여러 환경이 웹RTC를 하기에는 많이 어려웠기 때문이다. 이걸 다른 방법으로 풀어 성공한 국내 회사도 있긴 하지만.

2017년은 웹RTC가 사업성을 더욱 확보하게 되는 중요한 시기다. 웹RTC 표준이 완성되는 해이고, 애플 사파리(Safari) 11이 웹RTC 지원을 시작하기 때문이다. 웹RTC에 대해 잘 모르는 이들을 위해, 또 아는 사람들은 그 가치를 한번 되짚어보는 의미에서 웹RTC의 어제를 살펴보겠다.

▲ 손성영 알서포트 웹RTC 비저니스트

웹RTC의 미션

개발자도 아닌데 어쩌다보니 작년부터 스스로를 웹RTC 비저니스트(Visionist)라고 하면서 동향과 이슈에 대해 발표하고 다니는데, 그때마다 가장 먼저 하는 얘기가 있다. 바로 “‘웹RTC의 미션’이 뭔지 아느냐”다. 구글이 웹RTC 공식사이트에 적어놨지만 적잖은 이들이 무심코 지나쳤을 그 미션은 다음과 같다.

“To enable rich, high-quality RTC applications to be developed for 1) the browser, 2) mobile platforms, and 3) IoT devices, and 4) allow them all to communicate via a common set of protocols.”

첫 번째는 브라우저 간의 고품질 실시간 통신 서비스 개발을 위해, 두 번째는 모바일, 세 번째는 IoT, 그리고 결국 일반 프로토콜셋을 통해 이 모두가 통신하도록 만드는 것이다. 웹RTC의 활용분야가 어디까지가 될지 알 수 있는 중요한 미션이라고 하겠다.

웹RTC의 생김새

웹RTC가 많이 알려지긴 했지만, 아직 모르는 개발자들도 많이 있는 게 사실이다. 화상회의를 오랫동안 개발하던 사람들도, 웹개발을 하는 사람들도 잘 모르는 경우가 많아, 기본적인 것들 중에 필요한 부분을 알아보겠다.

 

▲ 웹RTC 아키텍처

먼저, 웹RTC 아키텍처를 먼저 보는 게 좋을 거 같다. 아키텍처 그림은 구글의 것을 조금 업데이트한 것이다. 이 그림에서 웹RTC의 영역은 음성엔진, 비디오엔진, 전송 영역에 세션 컨트롤(Session Control), 웹RTC C++ API 등으로 돼있는데, 통상 웹RTC라고 하면 밖에 있는 웹 API까지를 포함한 것을 말한다.

웹API는 자바스크립트로 돼있으며, 이 표준에 대한 문서는 W3C에서 작성한다. 그래서 우리가 웹RTC 표준이라고 하면 보통 이 W3C의 ‘WebRTC 1.0: Real-time Communication Between Browsers’를 말하는 것이고, 그렇기 때문에 웹개발자가 간단한 웹 API만으로 브라우저를 통해 실시간 통신 애플리케이션을 만들 수 있게 되는 것이다. 이것은 매우 중요한 웹RTC의 장점 중 하나다.

웹RTC (네이티브) C++ API는 미디어스트림(Media Stream)과 피어커넥션(Peer Connection)으로 구성됐다. 이건 누가 만드는 걸까? 브라우저 개발사에서 만든다. Webrtc.org에는 구글의 네이티브 API가 있고, 그것을 통해 웹RTC 호환 브라우저나 응용프로그램을 만들 수 있다.

아키텍처에서 또 중요하게 생각하는 부분은, 보이스엔진과 비디오엔진 부분에 실시간 전송을 위한 기술들이 포함됐다는 점이다. 기존에 화상회의 솔루션을 만들 때 에코 캔슬, 노이즈 제거, 전송 지연에 대응하는 음성과 비디오 처리 기술들은 상당한 노하우가 필요했고, 제대로 구현하는 데 상당한 시간과 인력이 요구됐다. 성능이 나오는 솔루션을 만들기 위해 오디오와 비디오 처리에 수십 명 이상의 박사급 개발자들이 있어야 했다.

다시 한 번 생각해보라. 지금 변화무쌍한 환경의 인터넷 위에 실시간 화상통신 솔루션을 개발해고자 한다면, 위 아키텍처 그림에 있는 미디어와 데이터 전송을 처리하기 위한 기술들과 노하우를 알기까지 얼마나 많은 시간이 걸릴지 말이다. 그런데 웹RTC에는 이미 그런 기술들이 포함돼있으니, 아이디어만 있으면 HTML과 자바스크립트로 실제 사용할 수 있는 것을 개발할 수 있다. 시간과 비용을 줄이고 빨리 원하는 서비스나 제품을 만들 수 있는 것이다.

짧게 보는 웹RTC의 역사와 의의

웹RTC의 역사에 대해서는 이제 인터넷에서 많이 찾아 볼 수 있다. 그럼에도 언급하고 넘어가야 하는 이유는, 오늘날의 웹RTC가 되기까지 우여곡절을 살펴봄으로써 앞으로 그 영역확장에 있어 가속도가 더 붙게 될 것임을 짐작할 수 있기 때문이다.

2010년: 구글 2개 회사 인수(On2-비디오, GIPS-오디오), 웹M 프로젝트(무료코덱, 이후 VP8)

2011년: 구글 웹RTC 표준 제안, 워킹그룹 시작

2012년: 특별한 이벤트 없이 웹RTC 표준 문서 위주로 진행됐던 해

2013년: 파이어폭스, 오페라, 안드로이드 크롬 웹RTC 지원, MS ORTC 제안

2014년: 안드로이드 오페라 웹RTC 지원

2015년: AV1 시작, (Only) HTTPS

2016년: MS 엣지와 크롬 간 오디오 연결, 하드웨어 인코딩 가능

2017년: MS 엣지 웹RTC 1.0 및 VP 코덱 지원, 사파리11 웹RTC 지원, 표준 완성단계(구글, 모질라)

2010년 구글은 웹만으로 비디오와 오디오 실시간 통신이 가능한 프로젝트를 진행하기 위해 2개 회사를 인수한다. 인수 후 가장 먼저 한 것은, 현재 VP8 코덱의 전신인 웹M 프로젝트를 진행하며 비디오 코덱을 오픈소스로 만든다. 이듬해에는 웹RTC 표준을 제안, W3C에 워킹그룹(WG)이 만들어진다.

2013년에는 파이어폭스(Firefox)가 웹RTC를 적극 지원한다. 그런데 마이크로소프트(MS)에서 웹RTC에 대항하는 ORTC라는 표준을 제안한다. 이에 웹RTC 생태계에서는 웹RTC 시장이 갈라지는 것을 우려했고, 웹RTC와 ORTC 두 가지를 모두 해야 되는지 고민했다.

2015년은 웹RTC의 성능 향상이 컸던 시기다. 또한 웹RTC 관련 벤더들 간 교류도 활발하게 진행됐다. 이때 중요했던 이슈 중 하나는 HTTPS였다. 구글은 웹RTC의 보안을 강화하기 위해 크롬에서 카메라나 오디오 장치를 불러오려면 HTTPS에서만 가능하게 했다. 지금은 다른 브라우저들도 HTTPS에서 동작한다.

2016년 들어 MS 엣지(Edge)와 크롬이 오디오 연결에 성공한다. 구글과 MS가 협력하고 있음을 알리는 신호탄이었다. ‘TPAC 2016 리스본’에서는 웹RTC의 다음 버전에 대한 고려사항이 거론된다. 웹AR/VR 지원 등 다양한 논의가 있었고, 다음 버전이 어떻게 진행될지 알 수 있는 중요한 행사였다. 구글과 MS는 웹RTC와 ORTC가 서로 호환되도록 하기 위해 협력하고 있으며, 향후에는 서로의 장점을 결합해 웹RTC 다음 버전으로 통합한다는 계획이다.

그리고 2017년 MS 엣지가 웹RTC 1.0 표준과 VP8 코덱을 지원한다. 웹RTC 표준이 연말까지 완성될 예정이다. 웹RTC가 사업성을 더욱 갖게 된다.

그동안의 걸림돌은 해결됐다

그동안 웹RTC 사업 관련 걸림돌들과, 이에 대한 현재 상황은 다음과 같다.

● 미지원 브라우저: MS 엣지와 애플 사파리가 지원하게 됨에 따라 대부분의 브라우저가 지원하게 됐다. 문제가 됐던 인터넷익스플로러(IE) 지원은 이전엔 플러그인과 플래쉬를 활용할 수 있었으나, 이제는 nw.js를 이용해 원소스로 윈도우 응용프로그램으로 쉽게 만들 수 있게 됐다.

● 표준 미완성: 올 연말까지 웹RTC 1.0 표준 완성을 목표로 구글과 모질라가 바쁘게 움직이고 있다. 이전까지 일부 시장에서는 표준이 완성되지 않아서 어떻게 될지 모르므로 사업에 적용할 수 있는 것은 아니라는 시각이 있었다. 그러나 이제는 표준의 완성으로 다양한 클라이언트가 그 표준에만 맞추면 실시간 비디오, 오디오, 데이터 전송 서비스를 만들 수 있게 된 것이다.

● 웹RTC 성능: 크롬과 파이어폭스의 업데이트 주기는 평균 6~8주 정도였으며, 이때마다 많은 성능 개선과 버그 수정, 새로운 API 등이 있었다. 초창기에만 웹RTC를 접했던 이들이 지금의 모습을 본다면 그 차이를 실감할 것이다.

● P2P를 넘어: 웹RTC는 P2P로 1:1 통신에 최적화됐기 때문에, 다중 참석 솔루션으로는 힘들다는 의견도 있었다. 그러나 요즘에는 많은 인원이 참석하는 솔루션이 일반적으로 생각될 만큼 웹RTC 미디어서버(Media Server) 오픈소스도 많은 성능 향상이 있었다. 오히려 웹RTC가 낮은 지연시간(Low Latency)으로 각광받게 됐다.

● 모바일: 모바일 브라우저에도 웹RTC가 지원된다. 앱을 만들 수도 있지만, 모바일도 브라우저로 대응할 수 있다. ‘홈에 바로가기’를 하면, 웹 주소를 입력해 서비스에 접속하는 게 아니라 터치만으로 모바일 앱처럼 실행할 수도 있다.

더 많은 이야기가 있겠지만, 1편은 이 정도로 웹RTC의 역사와 의미를 생각해보는 것으로 마무리하겠다. 다음 편에서는 웹RTC를 이용한 다양한 유즈케이스에 대해 다뤄보고자 한다.