2주간 배운 개발지식, LoL 게임 분석에는 통할까?
[코드스테이츠 PMB 10기] 다시 보는 개발 지식
안다고 생각했는데..
다시 보니 또 새롭네?
1. 아, 그거? 알지! (아마도..)
6주차와 7주차, 총 2주를 소모하여 개발 지식을 학습했다. 데이터의 기본부터 프론트엔드, 백엔드 그리고 API까지 이 기간은 개발을 모르는 사람들이 개발자와 소통하기 위해 그들의 언어를 배우는 시간과도 다름이 없었다.
하지만 사실 나는 산업공학과라는 학과 아래, IT에 대한 지식과 경영에 대한 지식을 모두 학습을 했기 때문에 새롭게 배우는 지식은 딱히 없었다. 그저 당시에 배웠던 내용들을 다시 복습하는 정도의 느낌.. 하지만 이 감상이 당연할 수 밖에 없는 게 HTML, CSS, SQL 등과 같이 쉬운 언어부터 시작해서 JavaScript, Java, Python, C 등 조금 어려운 언어까지 모두 한번씩은 다 과제로 프로그램을 구현해내야 했기 때문이다.
항상.. 교수님께 보여드릴 때만 안되더라..?실제로 PM을 본격적으로 준비해야겠다! 하는 생각을 하기 이전에는 개발과 정보보안을 공부했고, 조금의 개발은 할 줄 아는 정보보안 전문가가 나의 미래인 줄 알았다. 그래서 그런지 프로그래머들의 밈은 이전에 과제를 할 때의 모습과 다를 바 없다. (ㅋㅋ)
하지만! 그럼에도 사람은 지속적으로 까먹는 동물이기에, 배웠던 지식들은 '아 맞다, 이건 이런 거였지.' 하는 감상들을 불러왔다. 그래도 기획자는 어느 정도의 개발지식을 알아야 하는지, 그 '정도'에 대해서는 학습할 수 있었다. 이전에 내가 배웠던 지식들과 이번에 학습한 지식들, 이를 좀 더 응용하게 된다면 개발 프로세스를 이해할 수 있는 기획자로 새로운 강점을 가질 수 있지 않을까 한다.
2. LoL '나만의 상점' 다시 분석하기
약 2주 전, W6D1의 과제로 나는 LoL 나만의 상점을 분석하고자 해당 프로세스의 데이터 플로우를 간략하게 작성해보았었다. 당시 대학 때 배웠던 지식 및 라이엇 테크 블로그를 기반으로 해당 프로세스를 만들기 위해서는 이런 형식으로 데이터 플로우가 일어나지 않을까? 하는 추측으로 작성한 글이었다.
하지만 예상 외로 학습한 내용으로는 위 프로세스를 분석하기에 많이 부족했다. DBMS 라는 측면에 대해 깊이 학습하지 않을까 하여 DBMS가 중요할 나만의 상점을 고른 것인데 핀트가 벗어나고 만 것이다. 아마 PM은 그에 대한 정의만 알면 되지 그 아래 어떤 알고리즘을 사용하는지는 알 필요가 없어서 그런 것이 아닐까 생각이 들었다.
그래도 이번에 새롭게 학습을 하면서 잘못된 추측도 볼 수 있어서..! 이번 포스팅을 통해 잘못된 부분은 바로잡고 여태 배운 것들, 그리고 테크 블로그를 바탕으로 다시 분석해보고자 한다.
'나만의 상점' 이용 플로우 차트
이전 포스팅에서도 '나만의 상점'을 이용하는 사람들의 플로우 차트는 다음과 같았다. 그리고 이 부분에서는 수정할 부분을 찾지 못하여 이전에 작성한 자료를 그대로 사용해도 될 듯 하다.
Riot Games API에서는
스킨 정보가 없다!
이전 포스팅에서 라이엇 게임즈 Open API에 대해 분석한 적이 있었다.
(*자세한 내용은 위의 포스팅을 확인해주세요!)
그리고 이에 대해 학습을 하면서 하나의 사실은 알게 되었는데, 해당 API로는 각 소환사가 어떤 챔피언을 사용했는지는 나타나지만 어떤 스킨을 착용했는지는 안 나타난다는 것이다. 당시 포스팅을 작성할 때는 '각 소환사의 챔피언의 빈도수 및 어떤 character의 스킨을 주로 사용하는지를 토대로 나만의 상점에 해당 유저가 살 만한 스킨을 제시한다.' 라고 했는데 이는 완전히 틀린 추측일 수 있다는 것이다.
아마 어떤 스킨을 가지고 있는 지는 해당 유저의 개인정보일테니 Open API로는 풀지 않는 것으로 보인다.
'나만의 상점'
뜯어보기
UI
UI란 User Interface의 약자로, 쉽게 말하여 사용자가 앱을 사용할 때 마주하는 디자인, 레이아웃, 기술적인 부분 등을 말한다. 즉, 사용자가 제품/서비스와 상호작용할 수 있도록 만들어진 매개체인 것이다.
그리고 좋은 UI는 심리학에 기반하여 만들어지며 기획자는 해당 UI를 통해 의도하고자 한 결과를 사용자로부터 얻어내야 한다.
'나만의 상점' gif 출처=https://blog.naver.com/12512512/222328912669나만의 상점 UI를 보면 위와 같다. 처음 나만의 상점에 들어갔을 때는 총 6개의 카드가 뒤집어져있는 상태로 놓여져있는데, 각 카드는 리그오브레전드 스토리에서 많이 볼 수 있는 '마법공학'이 깃들어져있다. 사용자가 하나씩 누를 때마다 상자가 열리는 듯한 애니메이션이 작동되며 살 수 있는 스킨들이 할인된 가격으로 표시된다.
라이엇게임즈에서는 이러한 애니메이션 요소를 마법공학 UI라 부르는데, 이는 HTML5 비디오를 이용하여 클라이언트에 세련미를 더하는 것이라고 한다. 그리고 이러한 비디오는 미묘한 마법 효과 또는 매우 상세한 기계 애니메이션에 적합하다고 서술되어 있었다. (참고)
이처럼 기계가 작동하는 듯한 애니메이션은 LoL의 대표적인 특징이며 사용자들이 해당 스킨들을 확인하는 과정에서도 즐거움을 주기 위한 장치라 할 수 있다.
Client
'나만의 상점'은 결국 LoL 클라이언트의 일부이다. 그러므로 LoL의 클라이언트 자체를 살펴보면 어떤 언어로 구현되었는 지 확인할 수 있다. (참고)
2008년 처음 LoL 클라이언트를 만들 때까지만 해도, 라이엇 개발팀은 Adobe AIR라는 프런트 엔드 기술을 기반으로 클라이언트를 구축했다고 한다. Adobe AIR은 RTMP 세션 기반 네트워킹 프로토콜을 사용하여 서버와 통신하는데, 당시 HTML에서는 불가능했던 애니메이션과 효과를 낼 수 있었고 더 풍부한 멀티미디어 런타임을 제공할 수 있었다고 한다.
하지만 2015년에 AIR 클라이언트는 개발자 풀이 부족했을 뿐더러 게임을 플레이할 때에도, 그리고 협업을 할 때에도 불편성이 있었기에 지금 현재의 새로운 아키텍처로 클라이언트를 업데이트했다고 한다. 그래서 현재의 프론트엔드는 CEF (Chromium Embedded Framework)를 기반으로 구축되었으며, 이는 매우 강력한 HTML5 브라우저 구성 요소를 제공한다고 한다.
CEF에 대해서 더 알아보니, 이는 크로미엄 임베디드 프레임워크라 말하며 크로미엄 기반의 레이아웃 엔진을 포함한 오픈 소스 프레임워크라고 한다. C++로 개발이 되었고, 윈도우, 리눅스, 맥 OS에서 실행되는 데스크톱 응용 프로그램을 만들 수 있다고 한다. 그리고 이 프레임워크로 업데이트를 하면 메모리 사용량, CPU 사용률, 안정성 등이 개선되며 이후에도 유지보수에 쉬울 것이라고 한다.
그 결과, 최종적으로 업데이트된 LoL의 클라이언트는 다음과 같다.
여러 팀이 독립적으로 HTML5 기반 기능을 제공할 수 있도록 하는 엔진이며, 플레이어가 연결된 상태를 유지할 수 있도록 지원하는 통신 인프라를 사용한다고 한다. 또한, 플러그인 선택이 플레이어 자격에 따라 개인화되고 동적인 C++ 마이크로서비스 및 JavaScript 웹앱을 위한 효과적인 호스팅 엔진이라고 한다.
즉, Client 자체는 CEF 기반으로 구축되었으며 UI는 HTML과 JavaScript를 이용하여 구축되었고 동적인 요소는 C++ 를 활용하여 구현한 것으로 보인다.
Server
라이엇 게임즈는 총 11개의 서버를 운영하는데, 그 중 한국 역시 라이엇 게임즈가 운영하는 서버이다. 라이엇이 직접 운영하지 않는 서버로는 동남아시아(SEA) 서버, 그리고 중국 서버가 있다고 한다.
라이엇게임즈의 서버와 관련하여 테크 블로그에서는 자세한 내용을 찾을 수 없었기에, 라이엇게임즈의 서버와 관련하여 뉴스 기사를 찾아보니 다음과 같은 기사를 발견하였다. (참고)
"클라우드 도입은 서버 인프라 문제에 있어서 중요한 문제중의 하나다. 당장은 아니지만 분명 고민하고 있는 부분이다."
- <롤서버 지난해처럼 터지지 않으려면...> 中
위의 글은 2014년에 라이엇게임즈 코리아 대표의 말로, 클라우드 서버를 도입하면 안정적인 서비스를 위한 인프라를 구축할 수 있다고 설명하고 있다. 그래서 2022년인 지금, 클라우드 서버를 도입하지 않았을까 하는 추측을 해볼 수 있다.
클라우드 서버란 애플리케이션 및 정보 처리 스토리지로써 사용되는 강력한 물리적 또는 가상 인프라이다. 즉, 하나의 물리적 서버를 나누어 여러 개의 가상 서버로 사용하는 가상화 방법의 한 형태인 것이다. 대표적으로는 AWS (Amazon Web Service) 가 있는데 넥슨 등 여러 게임 업계에서도 해당 서버를 활용하여 게임을 개발한다고 하니, 라이엇도 AWS를 사용했을 가능성이 높다.
Database
마지막으로 '나만의 상점' 데이터베이스 측면을 생각해보도록 하겠다. '나만의 상점'을 이용해본 사용자라면 알 수 있듯, 해당 서비스는 각 유저들이 가장 많이 사용한 챔피언들을 기반으로 AI 추천 시스템을 이용하여 스킨을 제안해주고 있다. 그렇다면 어떻게 이렇게 정확한 추천 시스템을 작동할 수 있는 것일까?
그에 대해 나만의 상점 원리에 대해 상세히 설명한 글을 찾을 수 있었다. (참고)
1. 협업 필터링 (collabortaive filtering)
먼저, 이렇게 정확한 추천 시스템을 작동할 수 있는 이유가 바로 '협업 필터링' 을 사용했기 때문이다. (테크 블로그에서는 '콘텐츠 기반 필터링' 역시 사용하고는 있지만, 더 명확한 결과를 위해 협업 필터링을 더 주요하게 사용하고 있다고 한다.)
협업 필터링 (collaborative filtering)이란 같은 챔피언을 이용한 두 유사한 플레이어들이 있을 때, A가 사용한 챔피언을 B에게 추천하는 것이다. 라이엇 API에서도 알 수 있듯, 스킨에 대한 정보는 알 수 없지만 어떤 챔피언을 사용했는지는 모두 데이터로서 남는다. 즉, 각 사용자별로 사용한 챔피언들의 정보를 분석을 해보면 다른 사용자에게 어떤 챔피언을 추천해줄 수 있을 지 결정할 수 있는 것이다.
2. 이웃 기반 알고리즘 (neighborhood-based)
하지만 이 협업 필터링에서의 문제점은 바로 사용자들이 사용하지 않은 챔피언에 대한 값이 비어있다는 점이다. 나만의 상점을 제공하는데 필요한 데이터는 총 145개의 챔피언과 각 챔피언이 가지고 있는 스킨에 대한 정보, 그리고 사용자의 플레이 기록인데 사실 챔피언의 수는 지속적으로 늘어나고 있기 때문에 대부분의 플레이어들은 모든 챔피언을 사용하지 않는다. 그렇기 때문에 몇몇 사용하지 않은 챔피언들에 대한 값이 비어있을 수 밖에 없다.
그래서 이러한 빈 공란을 채우기 위해서 협업 기반 필터링에는 이웃 기반 (neighborhood-based) 또는 모델 기반 (model-based) 총 2가지의 알고리즘이 존재하는데, 라이엇은 이 중에서도 이웃 기반 알고리즘을 더 자주 사용하는 듯 하다.
이웃이라는 개념은 미래를 예측하기 위해 유사한 플레이어 또는 유사한 항목을 결정함을 의미하는데, 이웃 기반 모델은 플레이어 간의 유사성을 활용한다. 즉, A와 B라는 두 플레이어가 비슷한 점수를 보인다면 챔피언 제드에 대한 A의 추론된 등급을 활용하여 동일한 챔피언에 대한 B의 관찰되지 않은 등급을 예측할 수 있는 것이다.
이 이후에도 차원축소-행렬분해, 희소선형 모델을 거치면서 각 사용자별로 추천할 만한 데이터를 뽑아낸다.
하지만 이 모든 것은 이론상으로는 잘 작동하지만 수백만명의 플레이어로 확장되었을 때는 시스템 자체에 과부하가 걸린다. 이러한 과부하 현상을 줄이기 위해 라이엇게임즈에서는 클러스터 컴퓨팅을 사용하는데, Databricks에서 관리하는 클러스터를 통해 Apache Spark에서 위의 모든 알고리즘의 분산 버전을 실행한다.
이때 라이엇게임즈에서는 일반적인 클러스터 컴퓨팅 모델인 MapReduce를 사용한다고 한다. MapReduce란 여러 노드에 태스크를 분배하는 방법으로 대규모 분산 컴퓨팅 환경에서 대량의 데이터를 병렬*적으로 분석 가능하다.
(*Parallel : 동시에 많은 분석을 수행)
그러면 데이터 스냅샷 생성에서 모든 분산 알고리즘 실행에 이르기까지 약 1000 compute 시간이 걸린다. 이후 각 소환사별 모든 데이터 세트는 각각의 버킷(bucket)에 저장되며 이후 나만의 상점 서비스에 업로드하여 전 세계에 배포한다.
쉽게 말하면, 분산 클러스터 컴퓨팅을 활용하여 각각의 테스크를 수행하고 이후 나온 모든 결과값들은 하나의 버킷에 저장하여 한꺼번에 배포한다고 이해하면 될 것 같다. 그리고 이때도 모든 데이터는 AWS에 저장한다고 한다.
모바일 웹 또는 앱에 대하여 공부한 것에 비해 '나만의 상점'은 LoL 클라이언트에서 작동되는 것이었기에 정말 전혀 새로운 정보들을 얻는 느낌이었다. 그리고 모든 과정에서 테크블로그 또는 기사를 이용하면서 정확성을 얻으려 했지만 아무래도 전문용어가 있는 영어 기술 블로그를 참고한 것이다보니 잘못된 점도 있을 거라는 생각이 든다. 그래도 게임이 어떤 식으로 제작되고 우리 사용자들에게 서비스되는 지를 알아볼 수 있는 좋은 기회였던 것 같다. 그리고 내가 아는 개발 지식은 정말 새발의 피였다는 사실도 새로 깨달았다..(또륵)
참고자료.
