꿀벌이

내가 라이엇 게임즈의 리그 오브 레전드라는 게임을 할 때 정보를 얻기 위해 종종 이용하는 사이트에서 이런 메시지를 본적이 여러 번 있었다.

단순하게 라이엇의 서버가 불안정하다고 이해하고 있었지만, 오늘 수업자료를 통해 API를 배움으로써 위 메시지가 어떤 의미를 뜻하는지 대략적으로 알게 되었다. 먼저 오늘 내가 배운 API가 무엇인지 정의를 하도록 하겠다.

API란 무엇인가

API는 Application Programming Interface의 약자이며, 사용자가 특정 서비스로부터 데이터를 주고 받도록 중간다리 역할을 한다. 이해를 돕기 위해 아래 그림을 보도록 하자. 

위와 같이 사용자가 어플리케이션 B와 소통을 하기 위해  API를 거친다. 여기서 API가 하는 일은 다음과 같다:

• 정보 교환을 위해 이용되는 기술을 정의하고, 사용자가 어플리케이션으로부터 어떻게 데이터를 받을지 결정한다.
• 사용자와 어플리케이션의 소통할 수 있도록 인터페이스 역할을 한다.

어떻게 보면 API는 일종의 계약이라고도 할 수 있다. 이 계약은 사용자가 애플리케이션으로부터 어떤 명령을 수행할 수 있는지, 어떤 명령어를 입력 할 수 있는지, 어떤 데이터를 받을 수 있는지에 대한 내용들이 정의되어 있다.

앞서 말했듯이, 오늘은 라이엇 게임즈가 제공하는 API를 분석하여 우리가 어떤 명령을 수행하여, 어떤 데이터를 받을 수 있는지 알아보도록 하겠다.

라이엇 게임즈의 API

먼저 라이엇 게임즈가 자사의 API를 왜 공개하였는지에 대해서 설명하도록 하겠다.

라이엇 게임즈는 Open API를 통해 게임 관련 소프트웨어 개발자들에게 지정된 데이터를 액세스 할 수 있도록 해준다. 이런 데이터를 통해 개발자들은 게임 관련 소프트웨어를 개발하고, 유저들에게 게임 자체에서 볼 수 없거나, 보기 불편한 데이터를 유저들이 보기 쉽게 가공하여 제공한다. 이렇게 라이엇 게임즈의 API를 활용하여 제작된 서비스가 OP.GG라고 볼 수 있다. 

Open API를 통해 라이엇 게임즈는 본인들이 직접 개발하지 않아도, 다른 회사들이 이런 서비스를 직접 제공한다. 물론 라이엇 게임즈가 이런 서비스를 직접 개발할 수 있지만, 오히려 API를 공개함으로써 여기에 드는 인력과 자원을 아낄 수가 있는 거다. 그리고 API를 사용하는 서비스에게 API 사용료를 청구하여 수익을 창출할 수도 있다.

먼저 라이엇 게임즈의 API는 Riot Games Developer Portal에서 API Key를 부여 받은 뒤 사용할 수 있다. 이렇게 API Key를 부여받은 사용자는 라이엇 게임즈의 API를 사용할 수 있으며, 라이엇 게임즈는 해당 사용자의 API Key를 통해 API로부터 어떤 데이터를 활용하는지 측정할 수 있다.

오늘 교육에서 배운바로는 개발자 API와 개인 API가 구분된다고 들었는데, 라이엇도 마찬가지로 개인 API Key/소규모 개발팀 API Key/대규모 개발팀 API Key 등으로 구분한 걸로 봐서는 특정 그룹에게는 API 사용 시 금액을 청구할 거 같다는 생각이 들었다.

이제 라이엇 API가 어떻게 구성되어있는지 알아보도록 하겠다.

화면에 보이는 바와 같이, 좌측에 API로 얻을 수 있는 정보를 카테고리별로 구분해 놓았다. 예시로 Hide on bush라는 리그 오브 레전드 유저의 정보를 찾아보도록 하겠다.

위 화면과 같이 SUMMONER-V4(게임언어로 유저라는 뜻)라는 섹션으로 들어와 우측에 있는 각 API에서 내가 얻을 수 있는 정보가 무엇이 있는지 찾아보았다. 해당 유저의 계정 ID는 알 수가 없고, 유저명만 알고 있었기 때문에 2번째 항목으로 들어갔다. 그리고 해당 항목의 앞부분이 GET이라고 적혀 있는 걸로 봐서, 라이엇 게임즈의 API는 REST API인걸 알 수 있었으며 데이터를 불러오는 행동을 한다는 점도 확인할 수 있었다.

좌측 상단 화면의 RESPONSE CLASSES 통해 우리는 특정 유저의 유저명을 입력하면 어떤 데이터를 받을 수 있는지 정의되어있다. 우측 상단 화면의 RESPONSE ERRORS는 입력값에 따른 응답 오류 값들이 정의되어 있다. 마지막으로 하단에 PATH PARAMETERS 섹션은 우리가 인풋 데이터를 입력할 수 있는 곳이다. 이제 Hide on bush라는 유저명을 입력하여 어떤 정보가 나오는지 보도록 하겠다.

첫 번째 RESPONSE CODE는 200이라고 나와있었다. 200이 무슨 의미인지 개발자 포털에서 찾아봤더니, 아래와 같이 설명이 되어있었다.

2XX response codes는 API response body에 요청한 데이터가 JSON 형식으로 출력되었다고 설명되어있었다. 따라서, 내가 입력한 인풋 값은 정상이라고 해석이 되었다.

위 화면의 RESPONSE BODY에 생성된 데이터는 id, accountId, puuid 등 RESPONSE CLASSES에 나온 데이터들이 순서는 다르지만 동일하게 출력되어 있었다. 이런 정보들은 일반 유저들은 모르지만, 라이엇 게임즈의 API를 사용하는 개발자들에게는 상황에 따라 필요할 수 있는 정보라고 여겨졌다.

이번엔 해당 유저의 티어를 알아보기 위해, 다시 API의 메인화면으로 돌아가서 관련 있어 보이는 섹션을 모두 눌러보았고, LEAGUE-V4가 순위 정보를 알려준다는 걸 알 수 있었다. 그리고 아래 화면의 tier와 rank라는 데이터를 통해 해당 유저의 순위를 찾을 수 있었다.

이제 path parameters에 가서 아래와 같이 유저명을 입력하였는데, response code 400이 출력되었다.

알고 보니 해당 API는 우리가 흔히 알고 있는 유저명을 입력하는 게 아니라 encryptedSummonerId라는 값을 입력해야 정상적으로 아웃풋이 생성되는 것이었다. 따라서, 첫 번째 예시에서 생성되었던 encryptedSummonerId를 가져와 다시 입력을 했다.

위와 같이 정상적인 데이터가 출력되었고, 해당 유저의 티어를 알 수 있게 되었다.

이제까지 라이엇 게임즈의 API를 통해 어떤 데이터를 얻을 수 있는지 알아보았다. 하지만 내가 API에서 볼 수 있는 자료와 OP.GG에서 볼 수 있는 자료에는 분명한 차이가 있었다. 내가 추측하기로는 라이엇에서 제공하는 한정된 데이터를 바탕으로 OP.GG에서 AI 러닝을 통해 자체적으로 유용한 데이터를 더 만든다고 생각되었다. 아니면 대형회사들에게는 더 많은 정보를 받을 수 있는 그들만의 API Key가 있을지도 모른다. 지난 6개월간 궁금했던 점에 대해 오늘 배우게 되어서 나름 재밌는 시간이었다.

오늘은 앱의 4가지 형태에 대해서 알아보고 각각의 특징과 장단점을 정리해 보는 시간이다. 일단 앱의 4가지 형태가 무엇이 있는지 알아보겠다. 아래는 오늘 교육 자료에서 나온 앱의 4가지 형태를 간략하게 설명한 내용이다.

• 네이티브 앱(Native App) - 모바일 운영체제에 최적화된 언어를 사용해 개발한 앱으로서 안드로이드, iOS에서 제공하는 SDK를 사용해 개발한다.
• 모바일 웹(Mobile Web) - 모바일 기기에서 사용하기 편한 방식으로 개발된 '웹 페이지' 기반 서비스를 의미한다. 웹브라우저에서 동작한다.
• 웹 앱(Web App) - 앱의 형태를 가지고 있지만 실제 내용은 대부분 웹에서 구현해 보여주는 페이지다. 네이티브 앱에 비해 간단하게 구현이 가능하다.
• 하이브리드 앱(Hybrid App) - 네이티브 앱의 구조로 되어 있으나, 일부 기능들을 웹으로 구현해 개발하는 방식이다. 웹의 기능을 쉽게 연결할 수 있는 특징이 있다.

그렇다면 이제 각 종류에 따라 어떠한 특징과 장단점이 있는지 알아보고, 예시를 통해 이해가 되도록 설명을 해보겠다.

네이티브 앱(Native Apps)

네이티브 앱은 우리가 일반적으로 iOS나 안드로이드에서 흔히 사용하는 카카오톡과 포켓몬고 같은 앱을 말하며, 우리가 핸드폰에서 사용하는 대부분의 앱이 네이티브 앱이라고 말할 수 있다. 네이티브앱은 지정된 OS에서만 작동하며, 앱스토어나 구글 플레이 등 앱 다운로드 플랫폼에서 다운로드하여 설치를 해야 실행이 가능하다. 같은 OS라도 구동 환경이 다를 수 있기 때문에, 개발자들은 여러 디바이스를 고려해서 최적화된 앱을 유저에게 제공한다. 

네이티브 앱의 장점

• 4가지 형태 중 가장 속도가 빠르고 안정적이며 유저와의 상호작용이 가장 원할하다.
• 핸드폰의 여러 하드웨어 기능(카메라, 마이크, 컴퍼스, 가속도계, 스와이프 기능)들과 원활한 상호작용이 가능하다.
• 푸시 알림 사용이 가능하다.
• 핸드폰의 OS에 최적화된 UI를 제공한다.
• 앱스토어/구글플레이 등을 통해 앱의 품질에 대해 쉽게 알 수 있다.

네이티브 앱의 단점

• iOS와 Android 등 각 OS에 대한 앱을 따로 개발해야 한다. (iOS: Objective-C, Swift / Android: Java)
• 따라서, 여러 OS에 출시를 희망할 경우 개발에 대한 시간과 비용이 추가적으로 요구된다.
• 앱 업데이트가 필요할 시 OS마다 업데이트를 따로 진행해야 한다.

하이브리드 앱 (Hybrid Apps)

이번 과제를 통해 배운 유형 중 가장 이해가 힘들었고, 근 몇 년간 많은 발전을 해온 하이브리드 앱에서 다뤄보겠다. 처음 과제를 작성할 때만 해도, 내가 이해했던 하이브리드 앱의 개념은 아래와 같았다.

네이티브 앱과 같이 다운로드하여 OS에서 구동하지만, 사실상 속 내용은 웹 앱과 동일하다. (웹 앱에 대해서는 뒤에서 설명하겠다.) 일반적으로 하이브리드 앱은 스타트업에서 많이 사용한다. 우리가 어떤 프로덕트를 개발할 때 사람들이 좋아하는지 아닐지는 제품을 출시하기 전까지는 알 수 없다. 따라서, 스타트업에서는 개발 시간과 비용이 비교적 적게 요구되는 하이브리드 앱을 출시해서 잠재 고객들이 MVP(Minimum Viable Product)를 경험하도록 한다.

하지만 트위터, 페이스북, 스포티파이와 같은 앱이 모두 하이브리드 앱이라는 사실을 알고, 내가 완전히 잘못 이해했다는 걸 깨닫게 되었다. 단순히 눈으로 트위터, 페이스북을 봤을 때, "이건 무조건 네이티브 앱이다"라고 생각했지만, 하이브리드 앱의 기술 발전으로 인해 이제 네이티브나 하이브리드를 시각적으로 구분할 수 없다는 사실을 알게 되었다. 

하이브리드/네이티브 앱 개발에 사용되는 크로스 플랫폼(Cross Platform) 프레임워크

위에서 네이티브 앱의 단점으로 각 OS에 대해서 다른 소스 코드로 개발해야만 하는 불편함을 언급했다. 이런 불편함을 해소하기 위해 2011년부터 여러 회사들이 크로스 플랫폼 프레임워크를 개발하기 시작했고, 대표적으로 구글의 플러터(Flutter), 페이스북의 리엑트 네이티브 (React Native), 마이크로소트의 닷넷 마우이(.Net Multi-platform App UI) 등이 있다. 크로스 플랫폼은 단순히 안드로이드와 iOS에 국한되지 않고 macOS와 윈도우와 같은 PC 운영체제에서도 한 번에 프로그래밍할 수 있는 기술이다. 이렇게 여러 플랫폼에서 하나의 언어로 프로그래밍 할 수 있는 장점을 가지고 있지만, 각 운영체제에 100% 최적화되지 않았기 때문에 성능이 떨어진다는 단점이 있다.

하이브리드 앱의 특징과 장단점

일단 오늘 하이브리드 앱에 대해서 얘기할 때, 요즘 트렌드가 그렇듯이 크로스 플랫폼 프레임워크로 개발된다는 가정하에 이야기를 진행하겠다. 하이브리드 앱의 특징은 앱의 외형을 지니고 있지만, 사실 우리가 보는 화면은 웹 화면이라는 것이다. 이걸 구현하기 위해 하이브리드 앱은 웹 뷰(Web View)라는 요소를 사용하여 앱이 지정한 주소를 볼 수 있도록 한다. 인터넷에서 아주 좋은 예시가 있어 아래에 첨부하였다.

이제 하이브래드 앱의 화면은 웹에서 가져온다는 사실을 이제 알게 되었다. 그리고 화면만 웹에서 가져온 것뿐이지, 기본적인 형태는 앱의 형태를 지니고 있기 때문에, 네이티브의 장점으로 앞에서 언급한 핸드폰의 하드웨어 기능도 문제없이 사용할 수 있다. 또한, 크로스 플랫폼 프레임워크로 제작하기 때문에 코드 작성과 테스트를 한 가지 코딩 언어로 진행하고, 마지막에 iOS나 Android에 맞게 옷만 잘 입혀서 나가게 해 주면 된다. 

이제 장점과 단점을 알아보겠다.

모바일 웹

모바일 웹에 대해서는 굳이 설명이 필요 없다고 생각한다. 흔히 우리가 핸드폰에서 크롬이나, 엣지 등 인터넷 브라우저로 웹 서핑을 할 때 보는 화면을 모바일 웹이라고 한다. 

모바일 웹의 장단점

웹 앱

웹 앱은 간단하게 말하면 우리가 모바일 기기에서 url을 입력하여 들어간 웹사이트가 앱의 형태를 지니고 있는 것을 말한다. 핸드폰 브라우저에서 gmail.com을 접속하면, 우리가 흔히 아는 웹사이트의 형태가 아닌 앱의 형태를 갖춘 걸 볼 수 있다. (아래 예시 참고)

웹 앱의 장단점

내가 PM이라면 어떤 형태의 앱을 사용할까?

이제 내가 어떤 프로덕트의 PM이라고 가정하고, 기획하는 과정에서 어떤 형태의 앱을 쓸 수 있을지 생각해보려 한다.

좋은 사업 아이디어가 있어 제품의 PMF을 확인하기 위해 초기 단계에서는 HTML, CSS, JavaScript를 사용하여 프론트엔드 개발이 비교적 간편한 웹 앱 혹은 모바일 웹을 만들어 일단 인터넷 상에 노출시키려 할 것이다. 또한, 서비스 초기에는 이용자가 많지 않기 때문에 작업용 pc를 서버로 활용하여 서비스를 구동하도록 할것이다. 

간단한 구성을 가진 앱을 출시한 뒤 사업의 발전 가능성과 이용자 증가가 눈에 보인다면, 슬슬 앱의 발전 방향을 정해야 할 것으로 생각한다.

개인적으로 아래와 같은 사항을 고려해야한다고 생각한다:

• 개발자가 어떤 방식의 앱 개발을 제일 잘하는지 알아야 한다.
• 우리가 제공하는 서비스의 기술적 특징이 무엇이 있는지 (예: 트래픽이 특정 시간대에 몰리는 서비스라면, 서버 트래픽을 잘 관리하는 기술 스택을 선택해야 한다)
• 제품 출시 기한은 언제인지 (기한이 임박했을 경우 빠르게 개발할 수 있는 하이브리드 앱을 고려 할 수 있다)
• 우리가 제품에서 원하는 기능을 구현할 수 있는 기술 스택인지 고려
• 서비스의 최적화를 위해 꼭 앱을 개발해야하는지 혹은 그냥 웹 앱/모바일 웹으로 진행해도 되는지 생각 해야한다.
• 현재 회사 인재풀로 원하는 앱을 개발 할 수 없을 경우, 어떻게 개발팀 인력을 증원할 지 고려

위에 대해서 고민한 뒤 방향이 정해졌다면 개발에 착수한다. 

오늘은 모바일 앱의 4가지 종류를 알아보았다. 단순히 이용자로써 이런 측면을 전혀 생각해보지 못했었는데, 리서치를 통해 많은 지식을 얻게 되어 유익한 시간이었다.

오늘은 HTML, CSS, JavaScript에 대해서 간략하게 배웠다. 웹 개발/디자인에는 전혀 지식이 없는터라 강의 자료를 통해 개념만 대충 이해했다 뿐이지, 크롬에서 F12를 눌러서 코드를 보면 뭐가 뭔지 도무지 알 수가 없다. 오늘 과제는 내가 선택한 랜딩페이지의 HTML/CSS/JavaScript 요소를 정리하고 분석하는 일이고, 따라서 사이트의 구성이 간단하게 여겨졌던 네이버 뉴스를 분석하기로 했다. 네이버 뉴스에 대해서는 별 다른 설명이 필요 없다고 생각하므로, 바로 페이지 레이아웃에 대해 얘기해보겠다.

네이버 뉴스 페이지 레이아웃

아래 왼쪽은 네이버 뉴스의 랜딩 페이지를 캡쳐한 화면이고, 오른쪽은 랜딩 페이지의 레이아웃을 간소화한 그림이다.

대부분의 웹사이트와 같이 상단에 header 섹션이 위치해 있고, 가운데 main 섹션은 3개의 칼럼으로 나뉘어있다. 그리고 메인 섹션의 우측에는 작게 aside 섹션이 자리하고 있다. 마지막으로 하단에는 footer가 위치해 있다. 따라서, 크게 보면 총 3개의 섹션(header, main, footer)으로 나뉜 것을 알 수 있다. 물론 예외도 있겠지만, 오늘 과제를 정하기 위해 둘러본 7~8개 사이트들이 모두 이와 같은 레이아웃으로 구성되어 있었다.

HTML 이란?

HTML(HyperText Markup Language)은 웹페이지를 이루는 가장 기초적인 구성요소이며, 웹사이트의 여러 요소들의 의미와 구조를 정의할 때 사용하는 마크업 언어다. 우리가 글을 쓸 때 서론-본론-결론이 있듯이, HTML도 마찬가지로 비슷한 느낌의 구조로 작성할 수 있다. 이해를 돕기 위해 아래 그림을 보도록 하겠다.

위에 DOCTYPE은 무시하고, 바로 <html>을 보도록 하자.

HTML 문서의 시작은 <html>로써, HTML 문서 내용이 아래에 이어진다. 그리고 HTML 문서가 모두 입력이 되었으면 마지막으로 </html>을 입력하여 HTML 문서가 끝났다는 신호를 보낸다. 시작과 끝은 한번 밖에 있을 수 없으므로, <html>과 </html>은 한 페이지에 한 번씩 밖에 나올 수 없다.

<head> 섹션은 문서의 메타데이터를 정의하는 곳이다. 따라서, 해당 섹션에 입력된 내용들은 페이지에 디스플레이 되지 않는다. 위의 예시와 같이 HTML 문서의 제목을 입력할 수도 있고, CSS와 script를 정의할 수 있다. 

<body> 섹션은 우리가 웹페이지를 이용할 때 눈으로 보게되는 내용들이 정의되는 항목이다. 앞서 언급한 페이지 레이아웃 요소 3가지(header, main, footer)가 모두 <body> 섹션 안에 입력된다.

이해가 어느 정도 되었다면 이제 네이버 뉴스의 HTML은 어떻게 구성되어 있는지 몇 가지 요소를 골라서 알아보도록 하겠다.

네이버 뉴스의 HTML 구성 요소

위는 HTML 문서를 최소화해서 head와 body만 보이게 축소한 화면이다. 앞서 말한대로, <html> - <head> - <body> - </html> 순서로 구성된 점을 알 수 있다.

<head> 섹션

웹페이지의 메타데이터가 입력되는 곳이다. 첫번째 줄 <title id="browserTitleArea">네이버 뉴스 </title>에서 웹페이지의 제목이 입력되는 것을 알 수 있다. 다음으로 <link rel="stylesheet" type="text/css" href="https://ssl.pstatic.net/static.news/mnews/resources/20221006_055519/css/generated/newshome.css"> 에서 웹페이지의 디자인을 구성하는 CSS stylesheet를 <head>에서 불러온다는 점을 알 수 있다. (CSS stylesheet에 대해서는 뒤에 자세히 얘기하도록 하겠다.) 그리고 웹사이트에 기능을 부여해주는 여러 script와 웹사이트 정보 역할을 하는 여러 metadata가 입력되는 과정을 볼 수 있다. 이와 같이 <head> 섹션은 HTML의 <body> 섹션에서 수행해 나갈 기능들을 미리 정의해주는 역할을 하는 걸 볼 수 있다.

<body> 섹션

HTML의 대부분을 차지하는 <body> 섹션이다. 여기는 실제 우리가 눈으로 보는 페이지의 요소들을 위치시키고 정의한다. 아래 화면을 통해 어떻게 구성되어 있는지 알아보겠다.

실제 페이지 레이아웃과 동일한 순서(header-main-aside-footer)로 각 항목들이 정의되어 있다. 

1. <section class="news_header">
2. <section class="main_content">
3. <section class="main_aside">
4. <div class="mp_footer">

재미삼아 header와 footer의 위치를 바꿔보았는데, 바로 페이지에 반영이 되었다.

방금 전 실험을 통해 HTML이 위에서 아래로 렌더링 된다는 점을 찾아낼 수 있었다. 아마 이런 이유로 stylesheet나 script가 대부분 <head>에서 정의가 되는 거 같다. 이제 전반적인 구조에 대해서 알았으니, 한 요소를 골라서 그 안에는 뭐가 있는지 알아보자.

위 그림은 header은 네비게이션 메뉴인데, 현재 "언론사별" 페이지에 들어왔기 때문에 글씨가 파란색으로 표시되어있다. 해당 요소의 HTML은 어떻게 구성되어 있고, 각 요소들이 무엇을 의미하는지 알아보도록 하겠다.

• class="Nlist_item is_active"
  • "언론사별" 항목이 현재 활성화 되어있다. (이 페이지가 지금 열려있다는 뜻)
• href="https://news.naver.ccom/?viewType=pc"
  • 해당 글씨를 클릭하면 href에 정의된 링크로 이동한다
• onclick="nclk(event,'lnb.pcmedia','','')
  • 버튼을 누르면 nclk라는 함수를 실행한다. (nclk가 무슨 역할을 하는지 도무지 찾을 수가 없다...)
  • 한 가지 알 수 있는 건 함수의 2번째 입력값이 어느 페이지로 이동하는지 뜻한다는 것이다
• class와 role은 개발자가 항목을 구분 짓기 위해 표시한 이름이라고 생각한다. 그리고 aria-selected가 true로 되어있으므로, 해당 항목이 현재 선택되어있다는 뜻이다. (area인데 개발자 오타인 거 같다. 아니면 aria란 전문 용어가 따로 있을지도...)

이와 같이 버튼 하나를 정상 작동시키기 위한 HTML 요소가 무엇이 있는지 알아보았다. 이제 CSS는 어떤 식으로 구성되어 있는지 알아보겠다.

CSS 구성요소

페이지의 CSS 요소를 확인하다 흥미로운 점을 하나 발견했다. 페이지의 모든 구성 요소들이 CSS 정보를 newshome.css에서 가져오지만 aside 섹션만 CSS 정보를 aside.css에서 가져왔던 것이다. 그래서 이유가 무엇인지 알아봤더니, aside 섹션은 네이버 뉴스 페이지의 구성 요소가 아니라 다른 페이지가 embed 된 것을 알 수 있었다. 아래 화면의 2번째 줄의 첫 부분인 iframe이 "https://news.naver.com/aside?oid="를 불러오고 있는 것을 확인할 수 있다. 실제로 이 주소를 치면 aside 메뉴만 나온다.

aside 섹션에 대한 얘기가 나왔으니, 해당 항목의 CSS는 어떤 식으로 구성되어있는지 알아보겠다.

그리고 CSS 정보는 아래와 같이 구성되어있다.

여기서 우리는 이 정보들이 해당 섹션의 디자인을 나타냄을 알 수 있다. 그리고 동일한 내용이 aside.css의 29번째 줄에 위치해있다. 이제 CSS를 수정하면 어떻게 되는지 예시로 두 개 요소의 값을 바꿔보겠다.

• 배경색 = 흰색에서 노란색으로 변경 (background-color)
• 테두리를 직각으로 변경 (border-radius)

이와 같은 형태로 CSS를 수정하여 페이지의 디자인이 변경되는 것을 확인할 수 있었다.

JavaScript 분석

JavaScript 동작 원리를 알기 위해서 많은 시간을 투자했지만, 얻은 게 없었다.. 일단 현재까지 발견된 점만 이야기 나눠보겠다.

위에 있는 새로보기 버튼에 대한 HTML 정보는 아래와 같다.

여기서 onclick 항목의 nclk가 JavaScript 함수라고 생각되는데, 이유는 event, 'home.editndnew' 등의 입력값이 들어가기 때문이다. 그리고 여기서 'home.editndnew'가 새로보기의 역할을 한다고 생각한다. 하나의 예시를 더 들어보겠다.

위는 검색창에서 검색 버튼을 실행하는 HTML 정보인데, 여기서도 마찬가지로 nclk 함수에서 'gnb.schn'을 입력하면 검색 기능이 실행된다는 걸 알 수 있다. 

결론적으로 nclk가 네이버 개발자가 생성해놓은 JavaScript 라이브러리이지 않을까 싶다.

오늘은 너무 새로운 걸 공부하느라 오랜 시간이 걸렸다. 머리가 아파서 글도 머리에서 생각나는대로 대충 썼다. 힘든 하루였다. 이제 자야지.

오늘도 지난주와 마찬가지로 스포티파이에 관한 주제로 위클리 프로젝트를 이어나가려 한다. 이번에는 스포티파이의 전반적인 서비스에 대해서가 아닌, 스포티파이가 독보적으로 잘하는 '큐레이션'에 대해 얘기를 해보려 한다. 스포티파이 관련 첫번째 블로그에서 큐레이션에 대해 언급을 한 적이 있는데, 이번에 다시 한 번 짧게 설명을 하고 시작하려 한다.

큐레이션에 대해서

큐레이션(Curation)은 '작품에 생기를 부여하는 활동'이란 의미를 가지고 있다. 대부분의 영어가 그렇지만 이 단어도 '돌보다', '보살피다'라는 뜻의 라틴어인 큐레어(Curare)에서 유래한다. 사실 이것보다 더 적절한 비유는 바로 미술관 혹은 박물관에서 일하는 큐레이터(Curator)를 생각하면 된다. 큐레이터는 미술관이나 박물관에서 전시할 작품을 고르는 사람을 말하는데, 그들이 전시관의 컨셉과 대중을 고려해서 작품을 선정해서 전시회의 퀄리티를 높여주듯이, 스포티파이의 큐레이션도 고객에게 맞는 작품을 선정해서 추천을 해준다. 하지만 스포티파이의 큐레이션은 대중을 고려한게 아니라, 정말 개인화된 큐레이션 제공함으로써 전 세계 이용자 4억4000만명 모두에게 각각 취향에 맞는 음악을 알고리즘을 통해 선별해준다.

스포티파이만의 차별점은 무엇인가?

지난 5주간 음원 스트리밍에 대해서 공부를 하면서 느낀점은 상위권에 위치한 음원 스트리밍 서비스의 전반적인 퀄리티는 차이가 거의 없다는 것이다. 여기서 말하는 퀄리티는 UI, 가격, 컨텐츠의 양, 음원의 오디오 품질 등을 말하는 것이다. 따라서, 현재 국내 서비스와 해외 서비스 마찬가지로 차별화를 두기 위해 독점 컨텐츠를 확보하고 있긴 하지만, 아직까지는 독점 컨텐츠에 대한 메리트가 크게 있다고 생각하지 않는다. 결국 대중이 즐겨듣는 초대형 아티스트들은 모든 플랫폼에 제공되기 때문이다. (사실 팟캐스트는 독점 컨텐츠 확보가 매우 큰 의미가 있다. 하지만 오늘은 음원 큐레이션에 대해 얘기할 예정이므로 팟캐스트는 제외하도록 하겠다.)

서비스 품질의 차이도 없고, 독점 컨텐츠도 의미가 없으면 유튜브 뮤직, 애플 뮤직, 아마존 뮤직 등 무엇을 사용하든 상관없지 않냐고 물을 수 있다. 하지만 스포티파이는 단순히 음원 청취가 아닌 새로운 음악적 경험을 하게 해준다. 그리고 여기서 말하는 새로운 음악적 경험의 원천이 바로 스포티파이의 '큐레이션'이라고 볼 수 있다. 오늘은 이 '큐레이션'이라는 주제를 통해 스포티파이가 무엇을 통해 '큐레이션'을 더 발전 시킬 수 있는지 생각하고, 발전 요소가 정당한지 확인할 수 있는 데이터가 무엇이 있는지 알아보려고 한다.

고객별 스포티파이 큐레이션의 적합성 확인

스포티파이의 큐레이션을 통해 고객에게 제공되는 컨텐츠가 적합한지 확인하기 위해서 무엇을 봐야 할까? 여기서 고려해볼 만한 요소는 아래와 같다:

• 고객이 컨텐츠를 좋아하는가
• 다양한 컨텐츠를 제공하는가
• 고객이 제공되는 컨텐츠를 모두 쉽게 엑세스 할 수 있는가

큐레이션을 통해 고객에게 제공되는 컨텐츠의 적합성을 판단하기 위해 3가지 요소를 정하였다. 그러면 각 요소마다 우리가 볼 수가 있는 지표가 무엇이 있는지 알아보도록 하겠다. 이에 앞서 스포티파이가 어떤 메타데이터를 통해 음원을 분류하는지 알아보겠다. 이에 대한 이해가 있어야 아래 지표에 대한 설명이 충분히 와닿을거라 생각한다. 그렇다면 이제 아래 그림을 통해 대략적으로 어떤 메타데이터를 수집하는지 알아보자.

메타데이터 구조

사실 위 그림은 이해를 돕기 위한 예시이기 때문에 실제로는 훨씬 많은 메타데이터를 수집한다는 점, 그리고 각 메타데이터 항목마다 훨씬 더 많은 데이터가 수집된다는 점을 참고하기 바란다. 아무튼 위와 같이 구성된 음원 메타데이터는 이제 각 고객과 매칭을 시켜주기 위한 정보로 이용이 된다. 예를 들어 아래와 같이 고객의 성향을 추적한 메타데이터가 있다고 생각해보자. 이 고객은 조용한 음악을 선호하며 발라드, K-POP 등을 좋아한다는 점을 알 수 있다. 그리고 스포티파이의 큐레이션은 고객과 음원의 메타데이터를 분석하여 고객에게 좋아할만한 음원/플레이리스트/아티스트/앨범을 매칭 시켜준다.

조금 빈약한 설명이지만, 어떤 느낌인지는 알 수 있을거라 생각한다. 그렇다면 이제 본격적으로 지표에 대해서 이야기를 나눠보겠다.

고객이 컨텐츠를 좋아하는가

고객이 컨텐츠를 좋아하는지 판단 할 수 있는 데이터는 워낙 많긴하다. 왜냐하면 큐레이션은 단순히 곡을 제공하는것 뿐만 아니라 플레이리스트, 아티스트와 같이 1개의 곡이 아닌 패키지를 추천하는 경우도 많기 때문이다. 따라서, 고객이 각 음원에 대해서 어떻게 반응했는지도 중요하지만, 플레이리스트와 앨범에 대한 반응을 통해서도 고객의 성향을 파악할 수 있기 때문이다. 어찌됐든 모든 데이터를 다룰수는 없으니, 제일 간단하게 설명할 수 있는 '음원 재생 시간' 데이터를 통해 얘기를 이어나가겠다.

지표: 음원 재생 시간

여기서 말하는 '음원 재생 시간'은 곡의 길이를 말하는 것이 아니다. 고객이 특정 음원을 재생했을때 곡을 끝까지 다 들었는지, 아니면 중간에 다음곡으로 넘겼는지 등을 얘기하는 것이다. 그런데 무작정 곡을 넘겼다고 해서, 그 곡이 고객에게 적합한 곡이 아니라고 판단 내릴 수 있을까? 그건 또 아니라고 생각한다. 메타데이터적인 요소가 고객과 일치하지만, 고객이 현재 스포티파이를 이용하는 환경에 따라서 고객에게 적절하지 않은 컨텐츠가 될수도 있다. (이어서 작성)

다양한 컨텐츠를 제공하는가

앞서 얘기했듯이 큐레이션의 궁극적 목표는 고객에게 새로운 음악적 경험을 제공하는 것이다. 그렇기 때문에 큐레이션 알고리즘은 단순히 메타데이터를 통해 고객에게 알맞는 컨텐츠를 제공하는 것만이 아닌, 아직 고객이 탐험하지 않은 영역에 조금씩 발을 들일수 있도록 하는것도 중요하다. 마침 해당 토픽에 대해서 리서치를 하다가 인터넷에서 흥미로운 자료를 발견했다. 참고로 필자가 스포티파이 관련 첫번째 블로그에서 언급한 BaRT(Bandits for Recommendations as Treatments)가 여기서 다시 나온다. (Bandit 알고리즘에 대해 알고 싶다면 다음 링크 참고: Bandit 알고리즘과 추천시스템) 이제 스포티파이의 알고리즘이 어떤식으로 새로운 컨텐츠를 추천하는지에 대해서 아래 그림을 통해 알아보자. 

Bandit 알고리즘에는 두가지 개념이 있다: 수확(Exploit), 탐험(Explore). 스포티파이의 관점에서 수확이라 함은 고객에게 최고로 적절하다고 확신이 드는 컨텐츠를 소개하는 것이다. 그리고 탐험은 고객에게 새로운 컨텐츠 소개를 하여 새로운 경험을 얻게 하는 것이다. 그런데 위에 보면 탐험은 2개의 영역을 차지하고 있다: 1) low certainty-low relevance(낮은 확실성-낮은 연관성), 2) low certainty-high relevance(낮은 확실성-높은 연관성). 두 영역의 차이는 relevance의 정도의 차이인데, 당연히 high relevance에 해당되는 컨텐츠가 훨씬 높은 빈도로 고객에게 추천되지 않을까 추측해본다. 마지막으로 무시(Ignore)는 말 그대로 고객과 관련이 없는 컨텐츠가 확실하기 떄문에 추천 컨텐츠에서 제외된다.

그렇다면 다양한 컨텐츠를 제공한다는 뜻은 무슨 의미일까? 위 Bandit 알고리즘을 통해 해석하자면, 나눠진 3개의 영역(explore, explore, exploit)에 해당하는 컨텐츠가 모두 일정 수준 고객에게 노출되어야 한다는 뜻이다. 그렇다면 이 3가지 영역이 골고루 고객에게 노출된다는 것을 어떻게 지표로 표현할 수 있을까? 

지표: BaRT Score

일단 BaRT Score는 아무런 근거 없는, 필자의 상상속에서 만들어진 지표라는 점 먼저 이해하기 바란다. 스포티파이는 그들만의 지표와 공식이 정해져 있을 것이다. 아무튼 본 지표를 통해 찾아내고자 하는 내용은 아래와 같다:

• Explore 영역이 충분히 고객에게 전달되고, 고객이 긍정적으로 반응하는지 알기 위함
• 세 영역이 고객에게 골고루 노출되는지 알기 위함

먼저 단어가 너무 길기 때문에 아래와 같이 용어를 정의하겠다:

• Explore(high relevance-low cerntainty) = E1
• Explore(low relevance-low certainty) = E2
• Exploit = X

첫번째로 계산 공식은 아래와 같다:

E1 score = (E1 청취 횟수 / 총 E1 제공 횟수) × 100
E2 score = (E2 청취 횟수 / 총 E2 제공 횟수) × 100
X score = (X 청취 횟수 / 총 X 제공 횟수) × 100

BaRT score = (E1 score + E2 score + X score) ÷ 3  (100점 만점 기준)

(수정 해야됨)

제공되는 컨텐츠를 모두 액세스 할 수 있는가

스포티파이가 보유한 음원 라이브러리는 우리가 인생을 두번 살아도 다 들을 수 없을 정도로 방대하다.

'마약 청정국' → '마약 오염국' 된 대한민국

최근 특정 연예인의 마약 사건으로 인해 다시 한번 대한민국 마약 범죄의 심각성이 다시 한번 재조명되고 있다. 그가 마약을 투약했다는 점도 문제지만, 더 놀라운 건 그가 소지하고 있던 필로폰의 양이 무려 1000회분에 해당한다는 점이었다. 1000회분은 절대로 1인이 혼자서 투여할 수 있는 양이 아니다. 따라서, 해당 약물을 공급받거나 같이 투약하는 공범들이 다수 존재한다는 뜻이다. 그리고 우리는 본 케이스를 통해 대한민국의 마약 범죄는 이미 널리 퍼졌다는 사실을 간접적으로 알 수 있다. 불과 2010년대 중반까지만 해도 우리나라는 마약 청정국으로 분류될 만큼 마약 범죄가 비교적 적은 나라였지만, 2016년과 2019년을 기점으로 마약류 범죄 단속수는 급속도로 증가하였다. 

물론 모든 마약이 우리 사회에 악영향을 끼치고 범죄자들의 정상적인 생활을 방해하지만, 정말 우려되는 점은 한국에서 유통되고 있는 향정신성의약품과 형태의 마약 비중이 급속하게 늘고 있다는 부분이다. 우리가 영화에서 흔히 보는 LSD, 메스암페타민 등이 향정신성의약품에 속한다. 그리고 이런 마약류는 인체를 크게 훼손시키는 뿐만 아니라, 중독성과 후유증이 심하기 때문에 한 번 발을 들인 이상 정상적인 삶으로 복귀하는 일은 사실상 불가능하다. 청나라가 아편으로 인해 겪었던 문제를 우리 모두 역사를 통해서 배웠을 것이다. 마약 복용자가 급증하고 있는 만큼, 대한민국이 마약에 대한 심각성을 다시 한번 느끼길 바라는 점에서 이번 블로그를 써본다.

마약 범죄에 대한 나만의 가설

대한민국에서 일어나는 마약 범죄에 대해서 사실 별로 아는 지식이 없기 때문에, 별 근거없이 추측을 통해 가설을 설정하겠다.

1. 마약범죄는 금전적 여건이 갖춰지고 마약에 대한 미디어 노출이 많은 30~40대 연령층에서 가장 많이 일어난다.
2. 마약 투약 또는 흡입한 후 행해지는 범죄율이 증가하고 있다.
3. 마약은 동남아 국가들에서 가장 많이 유통되며, 국내 거주중인 외국인 중 동남아 국가 출신 마약사범이 가장 많다.

위와 같이 3가지 가설을 설정하였으므로, 각 가설에 맞는 데이터를 인터넷에서 찾아보도록 하겠다.

가설 검증

마약류 관리법 위반 연령대 조사

위에서 제시한 "마약범죄는 금전적 여건이 갖춰지고 마약에 대한 미디어 노출이 많은 30~40대 연령층에서 가장 많이 일어난다."에 대한 자료를 찾기 위해 KOSIS 국가통계포털 자료(제목: 범죄자 연령)를 참고하였다. 모든 범죄 유형에 대한 통계 자료 중 마약류 관리법 위반에 대한 통계를 따로 분류하였다. 해당 통계 자료에서 얻어낸 결과는 아래와 같다:

예상한 바와 같이 금전적인 여유가 생기는 시점부터 마약을 접하게 된다는 가설이 위 자료를 통해 뒷받침되는 거 같다. 사실 한국의 마약류 시세는 다른 나라에 비해 평균적으로 5~6배 비싸기 때문에 웬만해서는 쉽게 접하기가 힘들거라 생각한다. 또한, 마약이 연예인들 사이에서 유행하는 이유도 그들의 평균 소득이 일반인보다 월등히 높기 때문이라고 믿는다.

마약에 의한 범죄율이 증가하고 있다

앞에서 세운 가설에 대한 검증 자료를 찾기 위해 마찬가지로 KOSIS 국가통계포털에서 "범죄자 마약류 등 상용여부"를 참고하였다. 외국영화에서 마약 관련 범죄를 너무 많이 봐서 그런지는 모르겠지만, 마약이 널리 퍼지면서 마약을 복용/투약한 사람들이 저지르는 범죄가 늘어났을 거라 생각했다. 아래 자료와 같이 마약 복용/투약한 사람들이 저지르는 범죄율 비중이 7년간 2배 정도 증가했지만, 애초에 숫자가 매우 낮기 때문에 크게 의미가 있는지는 판단이 서질 않는다.

국내 거주 중인 동남아 국가 출신의 마약 범죄 비중

사실 해당 가설은 최근에 뉴스를 통해 마약이 동남아로부터 유입되고 있다는 뉴스를 많이 접해서 알게 된 사실이다. 어찌 됐든 사실 여부를 확인하기 위해 2020년도 외국인 마약 범죄율을 국가별로 나타낸 자료(KOSIS의 "범죄자 국적")를 참고하였다. 가설에서 설정한 바와 같이 동남아 국가(태국, 대만, 베트남)의 비중이 52%로 절반을 넘었다. 마약 범죄율 이외에도 국내로 유통되는 경로도 동남아가 맞는지 찾고 싶었지만 마땅한 통계자료를 구할 수 없었다.

KOSIS에 있는 통계자료를 그대로 tableau나 google studio에 입력하니 데이터 차트가 너무 이상하게 나오는 바람에 시간이 많이 걸렸다. 오늘 한 가지 배운 점은 위와 같은 차트를 생성할 때 데이터를 최대한 심플하게 만들어야, 차트 생성에 문제가 발생해도 바로바로 수정할 수 있다는 것이었다. 마지막으로 우리나라 인구수는 지난 10년간 차이가 거의 없는데, 범죄 건수는 1.5배가량 늘었다. 한국 경찰의 수사력이 좋아진 건지 아니면 실제로 사람들이 범죄를 더 많이 저지르는 건지 의문이다.

트위치

게임을 좋아하는 사람들이라면 트위치에 대해서 한 번쯤은 들어봤을 거라 생각한다. 트위치는 미국 아마존이 소유하고 있는 인터넷 방송 중계 서비스고, 전 세계 최대 규모의 플랫폼이다. (한국의 아프리카와 같은 서비스) 

트위치는 유저 컨텐츠 서비스이며, 이유는 아래와 같다:

• 시청자 참여로 인해 광고 수익이 발생하고, 시청자의 구독료를 통해 트위치와 스트리머가 수익을 얻는다.
• 2022년 1월 기준 트위치 스트리머 인구는 920만 명, 시청자 MAU는 1억 4천만 명이다. 비교적 적은 스트리머 인구가 올리는 컨텐츠를 다수의 시청자가 라이브 혹은 다시 보기를 통해 이용한다.
• 이메일 알림, 모바일 푸시 알림 기능 등을 통해 유저들이 신규 컨텐츠가 방송되면 시청자들이 재방문하도록 한다.

이와 같은 특징들을 통해 트위치가 유저 컨텐츠 서비스라는 점을 확인할 수 있다.

오늘 교육자료를 통해 배운 사업 단계는 총 5가지가 있다:

• 공감 - 흡인력 - 바이럴 - 매출 - 확장

이 중 트위치는 현재 매출 단계에 해당한다고 생각한다. 이런 대형 플랫폼이 왜 확장 단계가 아닌 매출 단계에 있냐라고 생각할 수도 있지만, 현재 트위치는 높은 망 사용료로 인해 수익 구조를 개편해야 하는 상황을 겪고 있다. 따라서, 이미 '확장' 단계를 통해 여러 수익 모델을 추가 창출해낸 트위치지만, 현재는 트위치의 본질인 라이브 스트리밍의  품질과 구독 및 광고에 따른 수익을 재조정해야 하는 단계로 왔다고 생각한다. 이해를 돕기 위해 현 상황을 보여주는 몇몇 자료를 참고하겠다.

현 상황 요약

현재 트위치는 인프라를 유지함에 있어 막대한 비용으로 인해 부담을 갖고 있다고 트위치 회장 Dan Clancy가 밝혔다. 사실 아마존 계열사이기 때문에 아마존 웹서비스의 IVS(Interactive Video Service)에 대한 비용을 적게 낸다고 생각했지만, 사실상 그들도 다른 고객들과 동일한 금액(200시간 방송하는 스트리머 기준, 월 140만 원)을 낸다.

따라서, 이게 얼마나 트위치 측에 큰 타격인지 궁금해서 대략적인 연 IVS 지출을 계산해보았다. 위 글에서 트위치 회장이 언급한 바로는, 100 CCU 스트리머 한정 월 IVS 지출이 140만 원이라고 하였다. 그리고 전체 920만 스트리머 중 평균 100 CCU(concurrent user: 동시 시청자 수)를 보유하는 트위치 스트리머는 1퍼센트에 못 미친다고 한다. 계산의 편의성을 위해 100 CCU 스트리머의 비율을 1%라 가정하고 아래와 같이 계산해봤다. (100 CCU 미만 스트리머도 송출/수신 비용이 들긴 하니, 대략적으로 비슷할 거 같다는 추측이다)

트위치가 부담하는 월 IVS 이용료:

9,200,000 × 0.01 × 1,400,000 = 128,800,000,000 = 약 1300억 원

연 IVS 이용료 = 1300억 원 × 12개월 = 약 1조 6천억 원

트위치의 2021년 연매출이 3조였는데, 매출의 절반 가까운 비용이 IVS 이용료로 지출되고 있는 셈이다.

내가 생각하는 문제 해결 방법

해결 방법을 논하기 앞서, 과제에는 이전 단계에서 어떻게 현재 단계로 넘어왔는지 설명하라고 나와있지만, 현재 트위치는 확장 단계에서 한 단계 후퇴를 하여 매출 단계를 극복해야 하는 상황이기 때문에, 현재 단계에서 트위치가 어떤 방식으로 문제를 해결할 수 있을지 가정해보려 한다.

트위치가 현재 수익 모델에서 매출을 증가할 수 있는 루트는 아래와 같다:

• 구독료 증가
• 광고료 증가
• 도네이션 수수료 증가

이 중 나는 광고료에 초점을 두어보려 한다. 인터넷상의 대부분의 자료가 유료화되어 (심지어 이틀 전까지 볼 수 있던 statista도 ip가 막혔다) 양질의 자료는 찾을 수 없었지만 2019년 트위치의 광고 수익이 4000억 정도라는 점은 찾을 수 있었다. 그리고 2020년 예상 광고 수익은 약 7000억 정도였다.

당시 비슷한 유저수를 보유했던 스포티파이의 광고 수익과 비교를 해보겠다. (물론 성향이 다른 서비스긴 하다.) 2019년 당시 1억 3000만 명 정도의 유저수를 보유했던 스포티파이의 광고 수익은 7500~8000억 원 사이였다. 당시 트위치도 1억 2600만 명의 유저수를 보유하고 있음에도 트위치의 광고 수익이 훨씬 저조했다는 걸 알 수 있다. 개인적인 경험을 빗대어 보자면, 트위치는 광고의 빈도도 적을뿐더러 웹 브라우저를 이용하기 때문에 애드블록 같은 프로그램으로 인해 광고수익에서 손해가 발생할 수밖에 없다.

따라서, 개인적으로 이런 문제를 해결하기 위해서 아래와 같은 방법을 생각해봤다:

1. 트위치 시청에 영향을 크게 주지 않는 PiP(Picture in Picture) 광고의 빈도를 높여서 광고 수익을 증가시킨다.
2. 자체 플랫폼 소프트웨어를 만들어 광고 우회 플러그인으로 인한 광고 수익에 대한 손해를 줄인다.

그렇다면 이제 트위치가 현 상황을 헤쳐나가기 위해 진행 중인 전략을 알아보자.

현재 트위치가 진행 예정 중인 전략

플랫폼 유지비에 대한 부담을 줄이기 위해 트위치는 2023년 6월부터 트위치와 스트리머의 연간 수익 배분을 조정하기로 했다. 대부분의 스트리머는 해당되지 않지만, 대형 스트리머는 기존 '70:30=스트리머:트위치'에서 스트리머의 수익이 1억 4천만원을 넘는 시점부터 수익 배분이 50:50 형태로 바뀐다. 이로 인해 전체 스트리머 중 10퍼센트가 영향을 받는다고 한다. (연 1억 4천만원 이상의 수익을 갖는 스트리머가 거의 100만 명이라는 사실에 놀랐다.)

이와 같이 트위치는 현재 감당하기 힘든 플랫폼 유지비를 극복하기 위해 수익 배분을 조정하려 한다. 하지만 이로 인해 매우 극심한 피해를 보게 되는 대형 스트리머들이 불만을 공공연하게 표출하고 있고, 현재 트위치 관련 업계에서 매우 큰 이슈로 부상하였다. 이로 인해 수익배분 측면에서 더 유리한 유튜브 게이밍(70:30 배분율)으로 이동하려는 트위치 스트리머가 늘어나고 있다고 한다. 이를 어떻게 감당할지 트위치의 행보가 매우 기대된다.

사실 오늘 과제의 질문과는 결이 맞지 않은 내용을 작성했지만, 트위치의 현 상황을 고려했을 때 이런 방식으로 접근하는 게 최선이었다고 생각한다. 혹시라도 문제가 된다면 피드백 부탁드립니다.

Flood-it!

오늘은 Google Analytics를 사용해 Flood-it! 이라는 게임을 분석해보자 한다. 사실 Google Analytics 데모 중 Flood-it!이 있었고, 따라서 이 게임의 analytics 데이터를 내가 직접 보고, 내가 원하는 대로 보는 방식을 정할 수 있어서 해당 앱을 선정했다. Flood-it! 은 22개의 제한된 턴에서 보드의 색상을 통일시키는 게임이다. 게임을 시작하면 아래와 같이 최대 6가지 색상의 블록이 보드를 이루고 있는데, 좌측 상단 코너의 색깔과 맞닿은 블록 색을 게임 하단에서 클릭하면 해당 색으로 변경이 되면서 좌측 상단 코너의 영역이 늘어난다. 이런 식으로 최대한 적은 턴을 사용하여 (최대 22 턴) 보드의 색깔을 통일하는 게임이다. 설명이 별로인 거 같아 예시를 하나 들어보겠다.

예시

아래 좌측화면이 첫 번째 턴이고, 우측은 두 번째 턴이다. 첫 번째 턴에서 좌측 상단 블록(좌표 = 0,0)은 녹두색이며, 총 4개의 블록 영역을 차지하고 있다. 첫 번째 턴에서 4개의 녹두색 블록과 맞닿은 블록은 보라색 밖에 없다. 따라서, 보드 아래에 위치한 파렛트에서 보라색을 클릭하면, 우측 화면처럼 해당 영역이 보라색으로 바뀐다. 이런 방식으로 최대 22 턴 내에 보드의 모든 색상을 통일시키는 게임이 Flood-it!이다.

Flood-it! 의 수익구조

Flood-it! 은 기본적으로 제공되는 30개의 스테이지가 있고, 어려운 단계에서 22 턴 안에 완료하지 못할 경우 $0.99~$4.99를 지불하여 추가 턴을 구매할 수 있다. 또한, 스테이지를 완료할 때마다 광고가 재생이 되는데, 이를 없애기 위해 $0.99를 지불할 수 있다.

게임 내 구매 항목

추가 턴 구매 (옵션 1) = $4.99

추가 턴 구매 (옵션 2) = $0.99

광고 제거 =  $0.99

핵심 기능 및 관련 지표

처음 이 게임을 과제로 선정했을 때, GA 내 데이터를 보면서 굉장히 의아했다. 유저도 너무 적을뿐더러, 지난 일주일간 수익이 $6.07 밖에 되지 않았다. 그래서 개발사인 Lab Pixies가 누군지 궁금해서 찾아봤더니, 별다른 정보는 찾을 수 없었지만 회사 주소가 나와있어 구글맵에서 검색해봤더니 구글 본사였던 것이다. 내 개인적인 추측이지만 구글에서 재미로 게임을 만들어서 릴리스했거나, 아니면 GA의 데모용으로 사용하기 위해 만든 거라고 생각된다.

따라서, 해당 게임의 GA 데이터가 사실 유의미하다고 생각하지 않는다. 어찌 됐든 이 게임이 신생 게임이라는 가정을 하고, 최대한 유의미한 지표를 선택해서 이번 과제를 진행해보도록 하겠다. 그렇다면 이 게임의 핵심 기능은 무엇일까? 사실 게임의 핵심 기능이 뭐가 되었든, 문제는 유저 수가 정말 없다는 것이다. 유저 자체가 없는데 수익 모델에 대해 고민을 할 필요가 있겠는가 싶다. 게임 자체는 킬링타임으로는 괜찮지만, 부가적인 콘텐츠가 매우 부족하고 게임 플레이에 관한 도움/설명이 전혀 없다. 따라서, 해당 게임의 핵심 포인트를 게임의 playability (풀이: 게임이 난이도는 적절한가? / 재미있는 요소들이 충분히 있는가?)로 정했고, 추적할 지표는 아래와 같다:

추적할 지표

게임의 playability가 어느 정도인지 확인하기 위해서 2가지 지표를 선택했다.

• 각 스테이지별 유저들이 평균 실패한 횟수
• 각 스테이지별 유저들이 재시도를 한 횟수

지표 확인을 위해 GA를 어떻게 활용할 수 있을까?

위 두가지 지표를 통해, 어느 시점부터 고객이 게임에 어려움을 느끼고 그만두는지 알고 싶었다. 하지만 위와 같은 데이터는 전혀 찾아볼 수 없었다. 결국 내가 해볼 수 있는 다른 방식으로 접근을 하기로 했다. GA의 여러 항목을 이것저것 눌러보다, 아래와 같은 자료를 찾았다.

'Users who have completed the first 10 progressive levels'라는 문구를 보고 약간의 힌트를 얻었고, 그러면 각 항목들이 어떻게 정의되었는지 보고싶었다. 이것저것 누르다보니 우측에 '보기'란 메뉴가 있어서 들어가 봤더니 아래와 같은 화면이 나왔다.

자세히 살펴보니, 10 스테이지를 완료한 사람을 level>=10으로 구분해놓았던 것이다. 그러면 내가 level>0, level>1, level>2 등등 조건을 입력해서 각 조건에 맞는 총 사용자수를 찾으면 된다고 생각했다. 그러면 내가 원하는 대로 수식을 입력할 수 있는 공간만 있으면 된다고 생각했고, 보고서 항목이 그런 역할을 할 수 있다는 걸 알아냈다. 따라서, 보고서에 아래와 같이 조건들을 입력하여 지난 30일간 1~8까지 각각 몇 명의 유저가 해당 스테이지를 완료했는지 알아보았다. (아래 캡처 화면이 잘 안 보이니 확대해서 보기 바란다.)

위 자료를 입력하고 보고서 시각화 형태를 테이블로 설정했더니 아래와 같은 데이터가 나왔다.

앞서 말했듯이 Flood-it!은 게임만 던져주고 설명은 전혀 없기 때문에, 정말 쉬운 1 스테이지를 제외하고는 상당수의 유저들이 방법을 정확히 모르기 때문에 2 스테이지에서 게임을 그만했을 거라는 추측을 해본다. 사실 이 게임은 조금의 도움만 있으면 어렵진 않지만 그런 걸 전혀 제공하지 않는다. 더불어 게임 자체도 그리 재밌지는 않다. 

결론적으로 Flood-it!에 유입되는 인구는 1주일에 만명이 넘을정도로 아주 적진 않지만, 불친절한 UI로 인해서 조금만 막히면 스테이지마다 이용자가 급격하게 떨어진다고 나름 추측해봤다. 요즘 모바일 게임처럼 튜토리얼을 제공하고 막힐때마다 광고를 보면 힌트를 주는 방식으로 게임을 구성하면 어느 정도 효과를 볼 수 있지 않나 싶다.

결론적으로 원하는 데이터를 찾진 못했지만, 여러 번 사용하다 보면 조금씩 나아질 거라는 생각이 든다. 그리고 애초에 해당 데이터를 찾아낼 수 있는 변수가 제공되지 않기 때문에 내가 원하는 데이터를 제공하지 않는다고 생각한다. 그래도 GA에서 제공하는 여러 가지 변수를 통해서 데이터를 생성했다는 점에서 의미를 두어야겠다.

이전 직장을 다니면서 야근하고 야식먹고, 일주일에 술을 3~4번씩 먹다가 살이 10kg나 찐적이 있다. 엄청 후회하고 운동을 시작했는데, 먹는 양이 줄지 않아서 다이어트에 실패한 경험이 있다. 나중에 퇴사를 하고 집에서 놀면서 살을 빼려고 했는데, 운동하기는 귀찮고 해서 간헐적 단식을 했고 2개월 사이에 8kg나 빠졌었다. 문제는 지금 다시 살이 쪘다는 것이다. 그래서 다시 간헐적 단식을 하려 하는데, 요즘 PM 공부를 하느라 워낙 스트레스를 많이 받아서 나 혼자의 의지로는 힘들거 같다는 판단이 섰다. 그래서 '단식 추적기' 앱을 받아서 실천하려고 하는데, 마침 해당 앱을 오늘 과제의 주제로 사용할 수 있을거 같았다.

'단식 추적기'의 고객 행동 Flow Chart

아래와 같이 단식추적기를 사용하는 유저가 앱을 설치하는 시점부터 사용(경험)하는 단계까지 어떤 행동을 하게 되는지 flow chart를 이용해 보여주려 한다. '가입 및 설정 단계' 에서는 순차적으로 세부 단계를 통해 고객의 현재 상태 파악하기 위한 데이터 수집을 진행하고, 목표와 단식 플랜을 설정한다. '경험 단계'는 크게 가지 기능으로 분류 되는데, '단식' 항목을 제외하면 모두 부가적인 기능들이다.

위 flow chart가 잘 안보일 경우 아래 링크를 통해 확인 부탁드린다.

'단식 추적기'의 고객 행동에 따른 데이터 이동

유저가 해당 앱을 사용하면서 실행하는 여러 행동을 포괄적으로 묶어 '데이터 입력'과 '데이터 요청'으로 구분하여 유저한테는 어떤 화면이 보이고, 유저가 입력하는 데이터가 어떻게 전송되고 도착하는지 설명하려 한다.

1. UI 단계 (데이터 입력)

유저가 사용하기 편리한 GUI를 통해 데이터를 입력한다. 아래는 목표 체중을 입력하는 단계 화면이다. 

2. 클라이언트 단계 (데이터 저장)

위와 같이 입력된 체중은 유저의 데이터에 추가 된다. 아래 화면의 유저 데이터에 '현재 체중 = 65kg'가 입력된 것을 확인할 수 있다.

3. 서버 단계 (데이터 전송 및 가공)

클라이언트에 저장된 유저 데이터는 앱 서버로 전송되고, 비정형 데이터는 전처리(가공) 진행 후 데이터베이스로 전송된다. 여기서 가공된 데이터는 데이터베이스의 효율성을 위해 데이터가 효율적인 형태로 변형된다고 생각한다. 아래는 내가 추측하는 가공된 형태의 데이터 예시다.

4. 데이터베이스 단계 (데이터 저장)

데이터베이스는 가공된 데이터가 저장되어있으므로 아래와 같은 형태를 지니고 있지 않을까 추측해본다.

예시

김OO(User ID = 1926751)의 단식 강도 = "1926751.01.0"

김OO(User ID = 1926751)의 단식 강험 여부  = "1926751.02.1"

위와 같이 4단계를 통해 고객이 입력한 데이터가 데이터베이스에 저장되지 않을까 싶다. 그리고 고객이 특정 데이터를 요청한 경우, 위 4단계를 반대로 진행하면 된다고 생각한다. 물론 중간에 유저가 볼 수 있는 형식으로 데이터 포맷 전환도 이뤄져야 한다. 이해를 돕기 위해 데이터 이동 경로를 도식화하였으니 아래 파일을 참고 바란다.