감사히 단독으로 라이브 스트리밍 클라이언트단을 개발해볼 기회를 얻었다..!
사실 이 글을 쓰는 시점은 이미 라이브 스트리밍의 일부 데모 개발을 마친 시점이다.
중간점검 느낌으로 그 간 개발 과정을 정리해보자 !
팀장님께서 위 두 가지 서비스를 통해 우리 라이브 스트리밍 서비스를 자체 개발할 것이라고 말씀하셨다. 그래서 위 두 방법을 비교해보고 보고하라! 라는 명령이 떨어졌다.
사실 처음엔 YouTube Live Streaming API로 갈 줄 알았다. 왜냐면 접근성도 좋고 가격도 무료!! 이기 때문이다. 그런데 결국 YouTube Live Streaming API를 사용해서 개발을 하지는 않았다. 그 이유를 살펴보자.
유튜브는 라이브 스트리밍을 API 형태로 제공한다. 시청자들이 실시간으로 시청할 수 있는 이벤트를 제공한다.
유튜브 라이브 스트리밍의 API는 크게 3가지의 API로 분류된다.
- Youtube Live Streaming API
- Youtube Data API
- Youtube Analytics API
위 API를 조합하여 스트리밍 서비스를 개발할 수 있다. 정확하게는 어떤 유튜브로 방송중인 라이브 방송의 ID값 + Youtube API를 버무려서 하나의 스트리밍 서비스를 개발하는 것이다.
이에 대한 제약사항은 당연히 있다.
일단 몇 가지의 사전작업이 필요하다.
Google Cloud Platform에 프로젝트를 등록하고 그 프로젝트에 사용하고자하는 API
(Youtube Live Streaming API, Youtube Data API, Youtube Analytics API)를 등록한다.
또한 사용자 인증을 해야한다. 사용자 인증은 이곳에 잘 나와있다.
인증을 받고나면 API를 사용할 수 있다.
물론 다양한 기능을 제공하고 또 접근성은 좋았지만 우리는 AWS IVS로 갔다.
가장 큰 이유는 한 가지가 있다.
커스텀에 제약이 많다
대표님과 팀장님은 완전히 커스텀하여 우리 서비스를 론칭하는 것이 목표다.
그런데 유튜브는 결국 iframe 태그 위에 해당 스트리밍 중인 유튜브 방송 주소를 넣고
API를 사용하여 제어하는 형식이다. 물론 chat, player 등 다양한 기능을 제공하지만
어쩔수 없이 남는 유튜브의 흔적이 있다.

이게 가장 초기에 만든 데모 버전(디자인 신경 ㄴㄴ ㅋㅋ)인데 멈춤 버튼을 누르면

위에 보이는 삭제할 수 없는 UI들이 있다. 나중에시청, 공유, Youtube 로고등..
또한 유튜브 라이브 스트리밍이 완전 무료는 또 아니다. 일정 사용량이 넘으면 크레딧을 충전해야하기 때문에 그런 메리트도 없기 때문에 YouTube Live Streaming은 가지 않기로 했다.

(유튜브 바이바이)

AWS가 트위치를 인수한 것이 바로 이 AWS-IVS 때문이라는 말이 있다.
트위치가 수년간 쌓아온 실시간 스트리밍 서비스에 대한 노하우와 기술력을 그대로 흡수한 결과물이 AWS IVS이다. 실제로 AWS 기술 상담팀과 회의를 진행하며 들은 정보로 AWS 내에서 트위치에 계시던 개발자분들이 대부분 계시고 그 분들은 AWS에서 터치를 거의 받지않고 생태계를 유지중이라고 하신다. 그만큼 AWS에서도 신경을 쓰고있는 기술 분야가 아닐까 생각이든다.
지금 부터는 필자가 팀원들 앞에서 발표했던 ppt를 중간중간 가져와 설명해보겠다.
이제 AWS IVS에 알아보자
AWS - IVS -> Interactive Video Service 이다.

인터랙티브 하다는 것은 사용자의 능동적 참여를 가능하게 한다는 것이다.
AWS IVS는 인터렉티브한 참여를 가능하게 하는데 그 중심에 있는게 timed-meta-data이다.
meta data는 잠시 후에 설명하고 먼저 aws-ivs의 두 가지 스트리밍 모드에 대해 알아보자.
지연 시간: 2~5초
참여자수: 수천 명 이상
사용 목적: 대규모 방송, 강의, 이벤트
프로토콜: HTTP 기반 (HLS 최적화)
플레이어: IVS Player
지연 시간: <300ms
참여자 수: 최대 12명 (Publisher), 수백 명(시청자)
사용 목적: 실시간 상호작용(화상채팅, 게임, 원격 협업 등)
프로토콜: WebRTC
플레이어: WebRTC SDK (JavaScript, Android, iOS 등)
우리 서비스는 라이브 커머스를 위해 개발을 진행한다. 그렇기 때문에 굳이 Real-Time Streaming을 사용할 필요가 없고 오히려 적절한건 Low-Latency Streaming이 적합하다.
그래서 우리는 Low-Latency Streaming 방식을 선택했다.
Low-Latency Streaming 방식이라 하더라고 인터렉티브한 소통을 가능하게 하는 건 Timed Metadata이다. 이는 다음 포스팅에서 그대로 진행하겠다.