우리는 왜 HLS 프로토콜을 사용하려 하는가

음악 추천 스트리밍 서비스

 

우테코 레벨 3에서는 '음악 추천 스트리밍 서비스'를 구현하는 프로젝트를 기획하기로 했다.

 

사용자가 음악을 듣고 얼마나 유지하는지, 관련된 음악을 계속 듣고 싶은지 아니면 듣고있는 종류의 음악을 더 이상 듣고 싶지 않은지 등등에 대한 액션을 취할 때 우리의 서비스는 그에 액션에 맞는 음악을 추천해줘야한다. 

 

쉽게 말해서 사용자의 선호도를 판단해서 음악을 추천해주는 서비스라고 생각하면 된다.

 

 

우리는 이 서비스의 핵심적인 기능 중 하나를 '스트리밍'으로 봤다.

딜레이없는 음악 감상, 딜레이없는 음악 추천.

그것이 우리의 서비스가 제공해야할 핵심적인 사용자 경험이라 생각했다.

 

---

어떻게 스트리밍 서비스를 제공할까?

 

스트리밍 서비스를 제공해주기 위해선 크게 두 가지 방법이 있었다.

1. 서버에 저장한 음악/영상 데이터를 직접적으로 스트리밍한다.

2. 유튜브 api를 사용해 음악/영상 데이터를 간접적으로 스트리밍한다.

 

 

이를 조금 더 세분화하면 다음과 같다.

 

1. 음악/영상 데이터를 서버에 저장한 뒤에 해당 영상의 url을 전달한다.

2. 음악/영상 데이터를 서버에 저장한 뒤에 해당 영상을 HLS 프로토콜을 사용해 전달한다.

3. 음악/영상 데이터를 유튜브 API를 사용해 관련 영상의 url을 전달한다.

4. 음악/영상 데이터를 유튜브 API를 사용해 관련 영상이 저장되어있는 url을 전달한다.

 

---

각각의 장단점을 한번 따져보자.

 

1. 음악/영상 데이터를 서버에 저장한 뒤에 해당 영상의 url을 전달한다.

클라이언트와 서버가 통신할 때 고전적인 방법으로 알고 있다. 그만큼 구현의 난이도는 간단할 것으로 예상된다. 그러나 서버에 음악/영상을 모두 저장하기 때문에 서버 비용이 부담될 수 있다는 단점이 있다. 서비스를 진행할 때에는 꽤나 많은 데이터를 가지고 있어야하는데 이는 현재로서는 비용 대비 산출이 적다고 판단된다. (지금은 조금 다른 생각이다. 이는 뒤에서 다시 설명하겠다.)

 

이 뿐만 아니라 다른 선택지 대비 딜레이가 더 많이 발생할 것으로 예상된다. 어플이라는 특성 상 이동통신 네트워크를 사용해 서비스를 제공하는 것을 가정해야한다. 물론 일반적인 웹 환경도 그러하겠지만 스마트폰을 사용하는 경우에는 이러한 부분에 더 취약할 것으로 예상된다.(이동 중에 스마트폰을 사용한다면 와이파이의 성능이 약해질수도 있고, 갑자기 다른 와이파이에 연결이 되는 등의 현상이 발생할 수 있기 때문이다.) 결국 네트워크 환경이 언제든지 변할 수 있다는 것을 가정해야한다. 이러한 환경도 고려하여 딜레이를 없애는 것을 목표로 해야하기 때문에 단순히 url을 전달해서 이를 스트리밍하는 것은 딜레이에 취약할 것으로 예상한다.

 

결국 위의 딜레이 문제를 해결할 수 있는 방법이 2번째 선택안이다.

 

---

2. 음악/영상 데이터를 서버에 저장한 뒤에 해당 영상을 HLS 프로토콜을 사용해 전달한다.

HLS 프로토콜은 사용자에게 미디어 컨텐츠를 제공할 때 사용하는 프로토콜을 의미한다. 예전에 네트워크 수업 시간에 배웠던 짧은 지식을 토대로 요약해보자면 이는 사용자의 네트워크 통신 환경에 맞춰서 하나의 영상을 스트리밍하는 기능을 제공한다. 요약된 글을 읽어보면 위에서 발생하는 딜레이를 더 줄일 수 있을 것으로 예상된다.

 

하지만 새로운 프로토콜을 적용해야하는 만큼 새롭게 공부하고 적용해야하는 부분이 발생한다. 그만큼 학습 비용이 발생한다고 할 수 있다. 그리고 아직 서버 비용 문제를 해결하지 못했다.

 

---

3. 음악/영상 데이터를 유튜브 API를 사용해 관련 영상의 url을 전달한다.

4. 음악/영상 데이터를 유튜브 API를 사용해 관련 영상이 저장되어있는 url을 전달한다.

 

 

세번째와 네번째 선택지인 유튜브 API를 사용하면 서버 비용문제를 해결할 수 있다. 비용 대비 산출을 고려하지 않아도 된다는 것이다. 또한 기존에 제공된 기능을 활용하면 되기 때문에 비교적 빠르게 개발을 진행할 수 있다는 장점도 있다.

 

유튜브 API에 의존적이라는 단점이 있겠지만 우리가 비즈니스를 어떤 식으로 정의하는 지에 따라 이는 단점이 아니게 될 수 있다고 생각한다. 비즈니스 유형 중에 다른 서비스에 의존적인 비즈니스도 충분히 많으니 말이다.(하드웨어에서는 자전거와 자전거 바퀴, 소프트웨어에선 Linux와 Red Hat이 있을 수 있다. 사실 대부분의 비즈니스는 의존적이라고 볼 수 있다.) 그리고 의존적인 것이 문제라고 이야기하는 것은 대게 '의존 중인 대상에 수정 사항이 발생했을 때' 그 영향력이 크기 때문이다. 그런데 유튜브라는 기업에서 제공해주는 API는 이미 수많은 기업들이 의존하고 있기 때문에 이를 쉽게 변경하지도 않을 것으로 예상될 뿐더러 수정사항이 있어도 미리 공지를 해줄 것으로 예상되기에 이는 큰 문제가 되지 않을 것으로 생각했다.(개인적으로는)

 

그런데 3번째나 4번째가 아닌 2번째 방법인 우리는 왜 HLS 프로토콜을 사용하려고 했을까?

---

핵심은 서비스

 

3번째와 4번째 선택지를 선택했을 때 사용자들에게 제공할 수 있는 경험이 제한적일 것이라고 예상했기 때문이다. 우선 3번째 방법은 우리에게 익숙한 방식인 플레이버튼, 소리 바 등등이 모두 포함된 형태의 모습으로 사용자에게 영상을 제공해야한다. 

 

이런 형태로 말이다.

 

자, 구현은 쉽게 했는데 이런 화면이면 사용자들에게 과연 어떤 가치를 제공해줄 수 있을까? 음악을 스트리밍할 때 쇼츠, 릴스와 같은 숏폼 형태로 기획을 하고 있는데, 위와 같은 디자인의 영상이라면 과연 사람들에게 매력적으로 다가올 수 있을까? 전혀아니라고 생각한다. 사용자들이 어플을 켜고 음악 추천을 받으려고 할 때 이미 저 디자인의 화면이 뜬다면 음악 추천에 대한 신뢰도를 완전히 잃어버리게 될 것이다. 결국 우리가 원하는 서비스를 제공해줄 수 없다.

 

그러면 4번째 방법은? 이건... 불법인 것 같다. 그래서 처음에 의견만 나오고 이 방법은 사용하지 않기로 합의를 봤다. 

 

 

결국 사용자들에게 음악 추천 스트리밍이라는 서비스를 제공한다는 측면에서 2번 방법이 가장 부합하다고 판단되어 우리는 HLS 프로토콜을 사용하기로 결정했다.

 

아까 언급했던 서버 비용 문제도 지금 다시 고민해보면 그렇게 크지 않을 수 있다고 생각이 들기도 하다. 내 취향에 맞는 음악을 찾아가는 것이 목표이기 때문에 한 사람마다 많아봐야 50~200곡 정도 들을 것으로 예상하기 때문이다.(적어도 서비스 진입 단계에서는 말이다.) 그리고 아까 나왔던 의견 중에 영상은 레코드판이 돌아가는 것만 틀어주는 식으로 만들어보자고 이야기가 나왔는데 이 방법도 괜찮은 것 같다.

 

 

경영학도가 기본 베이스여서 그런지 모르겠지만 가장 중요한 것은 fancy한 기술, 트랜디한 기술 이런 것들이 아니라 사용자가 누구이고, 그들에게 어떤 가치를 제공할 것인지가 가장 중요하다고 생각한다.(그래서 오늘 프로젝트 방향성을 이야기할 때에도 타겟층은 누구로 할지, 어떤 기능을 핵심 기능으로 할지를 먼저 합의하고 진행했다.) 개발에만 몰입하다보면 이를 잊어버리기 쉬운데 이를 항상 기억하자.