wavve 뽀로로 사태를 점검합니다

이 글은 웨이브를 저격하거나 폄하하는 글이 아닙니다. 이번 일을 통해 스트리밍 기술을 이해하고, OTT 서비스를 하고자 한다면 보안적으로 어떤 부분을 신경 쓰면 좋은지 점검하는 글입니다. 오해 없으시길 바랍니다. 

---

2021년 신년이 되자마자 wavve에서 대형 사고가 터졌습니다. 이전에도 유사한 문제가 있었다고 하는데 개발직군에 종사하고 있는 사람으로서 문제를 진단하고 처방하는 시간을 갖도록 하겠습니다. 포털에 "wavve 뽀로로"를 검색하면 아래와 같이 이번 사고 내용이 확인됩니다. "뽀로로 컴퓨터 왕국 대모험"이 시청되는 도중에 성인물 베드신이 송출되었다고 하네요. 어떻게 이런 일이 가능한 걸까요? 웨이브 측은 에러파일을 복구하는 과정에서 일부 오류가 있었음을 인정했다고 합니다.

구글 검색 결과

 

한편, 1월 30일에 페이스북 생활코딩 그룹에 wavve에서 뽀로로가 재생되는 중간에 성인물이 수초 간 재생되었다는 글이 올라왔습니다. 아래는 그 당시에 제가 작성했던 댓글입니다. 아무래도 너무 띄엄띄엄 작성해서 이해가 어려운 사람들을 위해 조금 더 구체적으로 정리해보기로 했습니다. 

 

우선 문제를 진단하기 위해서는 스트리밍 기술을 적당히 이해해야 합니다. 이 글은 스트리밍 기술을 소개하는 글이 아니기 때문에 깊이 들어가지는 않겠습니다. 적당히 로직만 알면 이번 뽀로로 사태를 진단하는데 충분하니까요. 

스트리밍 방식은 동영상 방식과 구분이 됩니다. 동영상 방식의 경우 상영시간이 2시간인 영화 한 편을 시청하기 위해서는 2시간에 해당하는 영상을 전부 다운로드하여야 합니다. 편의를 위해 영상 크기가 2 GiB 정도라고 가정하죠. 그럼 사용자는 2 GiB 전체를 다운로드할 때까지 영상을 시청할 수 없습니다. 버퍼링만 바라보며 기다려야겠죠. 영화뿐만이 아니라 페이스북, 인스타그램, 틱톡 등에서 제공하는 짤막한 영상도 마찬가지입니다. 하지만 사용자를 이렇게 오래 기다리게 한다면 그 서비스는 당연히 망할 겁니다. 다행히 위에서 언급한 서비스들은 모두 스트리밍 방식을 사용합니다. 사용자를 기다리게 하지 않죠.

한편, 스트리밍 방식은 2GiB 영상을 아주 짧은 단위로 잘라 놓습니다. 예를 들어 10초 단위로 영상을 잘라서 사용자에게 내려주는 방식이죠.

사용자는 10초에 해당하는 영상만 다운로드하면 바로 영상을 시청할 수 있게 됩니다. 10초면... 대충 수백KiB 정도 될 텐데요, 요즘처럼 LTE를 넘어 5G로 가는 세상에서 판단하기에 수백 ms 이내에 다운로드가 완료됩니다. 구체적으로 어느 정도냐고요? 사람이 눈 깜빡하는 속도가 평균 100~150ms 정도라고 하는데 그 정도 시간밖에 안 걸리는 겁니다. 거의 느끼지 못하는 거죠. 10초 영상을 보는 도중에 그 뒷부분 10초가 백그라운드에서 다운로드가 진행되고 연결되기 때문에 연속적으로 영상 시청이 가능합니다. 사용자는 영상이 잘려있다는 사실을 알 수 없죠. 알 필요도 없고요. 자, 그럼 이런 스트리밍 처리를 위해 어떤 표준기술이 필요할까요?

스트리밍에는 HLS(http live streaming), DASH 같은 기술이 사용됩니다. 웨이브 서비스 트래픽을 보니 m3u8 플레이리스트가 사용되고 ts(Transport Stream) 파일로 영상이 나뉘어 있는 것을 보니 HLS를 사용 중입니다.

 

앞에서 스트리밍 방식에 대해서 간단히 소개했지만 다시 한번 정리하자면 동영상 하나를 전체 다운로드하지 않고 쪼개진 파일을 내려받으면서 플레이시키는 기법입니다. 잘게 쪼개진 파일들의 경로는 m3u8 이라고 하는 플레이 리스트 파일에 기록해 두고 그 파일을 클라이언트에 내려줌으로써 클라이언트는 m3u8 안에 담긴 ts 파일의 경로를 재생시키게 됩니다. 더 깊숙이 들어가면 사용자의 네트워크 환경에 따라 고화질/저화질이 조절되는 adaptive bitrate streaming까지 필요하지만 여기서 중요한 문제는 아닙니다.

아무튼, 클라이언트에서 m3u8 플레이 리스트 파일을 받아서 안에 기록된 파일을 하나씩 다운로드하면서 영상이 플레이되는데요, 사용자 입장에서는 영상을 플레이시키자마자 시청할 수 있어서 좋고 영상을 본 만큼만 파일이 다운로드가 되기 때문에 데이터도 절약돼서 좋습니다.

m3u8 파일을 열어보면 대충 아래 같은 형식으로 저장되어 있습니다. 조금 더 상세하게 이야기하면 파일에는 ts 영상의 길이, 위치, 화질 등 다양한 옵션이 있지만 편의상 생략합니다. 

# main.m3u8
blabla/00001.ts # 5-10초 정도 분량
blabla/00002.ts
blabla/00003.ts
........
blabla/09329.ts

 

위에 파일이 뽀로로 한편에 해당하죠. 이때 내부적으로 파일을 저장할 때 blabla/00193.ts 파일이 (어떤 이유로) 성인물의 파일로 잘못 덮어써졌다면 이번 사태처럼 영상 중간에 수초 간 다른 영상이 재생될 수 있게 됩니다. 이론상으로 이렇지만 사실 중간에 파일 하나가 바뀐다는 건 극악의 상황/확률입니다. 그럴 수가 없어요. 프로그래밍이나 아키텍처가 잘못되지 않았다면요.

네. 맞습니다. 뭔가 아키텍처가 잘못되어 있기 때문에 발생한 문제인데 어떤 경우에 이런 문제 상황이 발생할 수 있을까요?

• ts 파일명이 유니크하지 않게 사용되고 있어서 여러 영상이 다뤄지는 과정에서 일부 파일의 overwrite가 실패
  
  • 위에 스크린샷을 보면 media_N.ts 파일을 사용하고 있는데 매우 위험한 방식으로 보입니다.
  • 굳이 특별한 이유가 없다면 해시 문자열을 사용하는 게 더 낫습니다. 자사 데이터를 조금이라도 더 안전하게 보호할 수 있는 장치기도 하죠. 어쨌든 유추하기 쉬운 파일명을 열어둘 필요는 없으니까요.
  • 뭐 물론 m3u8 파일만 획득하면 영상의 모든 ts 파일 정보를 알 수 있지만 무작위로 데이터를 긁어가는 공격에는 충분히 대비할 수 있습니다.
• 수동으로 파일을 복사 하는 과정에서의 문제
  
  • 일반적으로 HLS 으로 나누는 건 ffmpeg 같은 오픈소스 프로그램을 통해서 진행합니다. 사람이 GUI를 통해 쪼개지 않는다는 이야기죠. 원본 영상을 잘게 쪼개고, 쪼갠 파일을 다시 서버에 등록(업로드)하는 등 모든 과정은 자동화로 처리되는게 정석입니다.
  • 이 과정에 사람이 개입하면 안됩니다. 휴먼 에러가 발생할 수 있기 때문이죠.
• 파일명이 유니크가 아니라서 CDN(content delivery network) 캐싱 문제
  
  • 위에 언급한 부분과 유사한 문제입니다. 경로가 정확히 일치하면 CDN에 걸려서 원본 영상이 교체가 되더라도 캐시가 반영되는데 시간이 걸립니다.
  • 즉, blabla/media_55.ts 파일이 성인물이었는데 뽀로로 파일로 덮어써졌다면 CDN에 반영되는데 시간이 걸리기 때문에 네트워크 설정에 따라 수십분 이상, 혹은 수시간까지도 기존 성인물 파일이 재생됩니다.
  • 캐시가 유지되는 시간 동안은 클라이언트의 영상 요청에 서버를 뒤지지 않고 CDN에서 캐싱되어 있는 정보를 내려주기 때문입니다.
  • 하지만 이건 가능성이 극히 낮습니다. 경로에 있는 의미를 알 수 없는 S01_E453827993.1 과 같은 부분이 난수이길 기대하면 말입니다. 아, 밑에 스크린샷에서도 볼 수 있듯이 "https://vod.cdn.wavve.com" CDN을 통해 영상이 내려받아집니다. 서버에 다녀오지 않구요.
• 인프라 취약점에 의한 해..해키..ㅇ
  
  • 이건 말을 아끼는게 좋겠습니다. 확률도 낮을 뿐더러 이정도 규모의 서비스라면 뻔히 클라우드의 스토리지(AWS라면 S3, GCP라면 GCS 등)를 사용할텐데 클라우드 공급업체에서 기본적인 보안을 전부 제공하기 때문입니다.
  • 웨이브를 넘어서 클라우드 프로바이더를 해킹한다는건 상상하기 어렵습니다.
  • 오히려 굳이 해킹을 의심해야 하는 상황이라면 ts파일을 쪼개는 자동화 서버를 문제 삼거나, 자동화 스크립트의 오류를 의심하는게 나을겁니다. 뭐 당연히 파일을 쪼개는 등의 프로세스는 다른 영상과 섞이지 않도록 독립(격리)된 환경에서 실행되겠지요.

 

CDN 사용중

 

이 외에 또 어떤 부분이 있을까요? 실제 문제가 됐던 m3u8 파일을 보지 못했고 상황을 직면하지 못했기 때문에 이렇게 유추밖에 할 수 없지만 서비스 개발자는 정말 많은 부분을 신경 써야 합니다. 심지어 누군가(내부직원)가 일으킬 수 있는 휴먼에러조차 전면 차단하는 방식으로 방어적인 개발을 해야 하죠. 영상 서비스를 고민하고 있다면 이번 사건을 통해 신경써야 하는 부분들은 무엇이 더 있을지 고민해보면 좋을 겁니다.

 

---

 

마무리

요즘 OTT(Over-the-top media service) 판세를 보면 군웅할거로 보입니다. 넷플릭스를 중심으로 여러 서비스(영웅)들이 들고 일어서고 있죠. 국내에도 웨이브뿐만 아니라 왓챠, 쿠팡 플레이 등 여러 서비스가 있습니다. 아마 모든 서비스가 사용자의 편의를 위해 스트리밍 방식을 사용하고 있을 겁니다. 또한 그 기술을 사용하는데 크게 다르지 않을 겁니다. 서비스의 핵심 기술인 ffmpeg를 누가 더 고도화해서 잘 사용하는지, 레이턴시를 줄이기 위한 아키텍처 고민 정도일까요? 이건 국내 기술 한정입니다. 훨씬 더 나은 영상 서비스를 제공하기 위해서는 자체 기술을 반드시 개발해야 합니다. 아무튼, 이번 사태는 웨이브의 문제로만 삼을 필요는 없습니다. 이번 일을 계기로 국내 모든 OTT 서비스는 자사의 파일 관리 시스템을 점검하고 다시 한번 심혈을 기울일 수 있기를 바랍니다.

추가로, 사용자는 조금 더 쓰기 편하고, 다양한 영상을 제공하는 서비스를 사용하면 됩니다. 그게 꼭 only one일 필요는 없어요. 겹치는 영상이 적어서 여러 서비스를 구독하는 사용자도 많습니다. 넷플릭스를 구독하는 사용자가 디즈니도 구독하는 일도 허다하죠. 각 플랫폼 별로 장점을 강화해서 좋은 서비스를 제공한다면 모두에게 승산 있는 시장이 될 겁니다. 한국 OTT 업체도 각자의 색깔을 찾을 수 있기를 바랍니다. 여기 시장이 박터질수록 사용자는 더 좋은 서비스를 제공받을 겁니다! :-)