라이엇 공지사항 둘러보다가 이상하게 여기만 불친절하게 번역이 안되어 있길래 봤는데

별 내용도 아닐 뿐더러 왜 안했는지 알겠더군요 지금 신클라 문제점이 몇가지 나오는 중인데 민망할정도로 찬양일색이라.. 

번역이 발퀄이라 보시는분들 입장에서 이해 할지도 모르겠고 정작 번역해보는 저도 용어가 너무 생소하고 특히 기술적인 부분들이그렇네요 의역도 심하게 되있고 오역은.. 아마 없을거임 ㅡㅡ

걍 심심해서 해봤습니다 

 

반갑습니다! 저는 앤드류(Andrew Mcveigh)이고 라이엇에서 소프트웨어 아키텍쳐 분야를 담당하고 있습니다.

리그오브레전드 클라이언트를 새로 뜯어고치는데 막바지에 다다랐고 우리는 클라이언트 업데이트라고하죠.

이 글에서 저는 이 업데이트의 소프트웨어 기술에 대해 간략하게 설명할 것이고,

우리가 선택해야만 했던 그 이유와 배경들을, 그리고 현재(구버전)의 한계에 대해서 짚어낼 예정입니다.
여기 최종 아키텍쳐까지 오기까지의 여정은 환상적이었고 저는 이러한 내용들을 설명하기 앞서 흥분되네요.  

 

왜 클라이언트를 바꾸는가?

지금의 클라이언트는 2008년에 프런트엔드기술인 어도비에어로 만들었습니다.
어도비에어는 RTMP 세션을 기반으로한 네트워킹 프로토콜로 호스트 서버와 연결하는 기술이죠. 
이 플랫폼은 그 역할로써 그동안 잘 수행해주었고 동시대에 존재했던 HTML에선 제공하지 못했던 풍부한 멀티미디어 런타임을,

그리고 애니메이션과 효과를 제공했습니다.

 

빠르게 7년이란 세월이 지나면서 2015년이 되었고 주목할만한 세가지 문제점이 에어 클라이언트에서 극명하게 대두되기 시작했습니다. 새로운 기술구조만이 해결하는 문제였죠.
 

문제 #1 - HTML5의 표준화

HTML5와 자바스크립트는 독자적인 데스크톱 클라이언트 기술이 되었습니다.
이것은 많은 이점을 가져왔는데요. 작업의흐름과 개발자툴들을 표준화 하는것을 포함해 재능있는 개발자들을 한데 묶는데 도움이 되었죠. 우리는 이 플랫폼을 최대한 활용하고 싶었고 진척시키고 싶었습니다.

 

 

문제 #2 - 소환사들은 게임에 떠나도 계속 접속하길 원했습니다. 
백그라운드에서 높은 점유율, 사용량의 이유로 사람들은 에어클라이언트가 지속적으로 활성화되길 원하지 않았습니다.
그러나 온라인 접속에 대한 인식이 최근 몇년간 많이 바뀌면서 소환사들은 게임을 떠나도 다른 소환사들과 계속 연결되길 원했고, 이것은 단지 PC 앞에 없다는 이유만으로 누구도 게임초대를 놓치길 원하지 않아야만한다는 우리의 철학과 일치했습니다.(우리가 모바일앱을 해결책으로 내놓은 이유죠)

 

 

문제 #3 - 라이엇 개발자들은들은 조화롭게 일하길 원합니다.
리그오브레전드와 라이엇은 2008년부터 거대하게 성장했습니다.
그리고 우리 중 어느 누구도 이렇게 수많은 팀들이 생겨날지 몰랐고, 그러한 팀들이 클라이언트에 얼마나 다양한 기능들을 넣고 싶어하는지 예상하지 못했습니다. 
초창기의 코드베이스는 작은 규모지만, 대단히 결속력있는 팀을 주축으로 만들어졌으나 추가적인 팀들이 생겨나고, 성장함에 따라 요구되는 자주성과 개별성을 주진 못했습니다.  
이러한 개발자팀들의 문제점은 서로간에 충돌하기 마련이었고 사라지지 않았습니다. 새로운 기능을 집어 넣을 때마다 계속해서 생겨났고 더 심각해졌죠.

 

 

놀라운 아키텍쳐로의 확장.

이러한 문제점들을 해결하기 위한 몇가지 방법이 있습니다.
예를들어 처음에 우리는 구식인 에어 브라우저에 남아 있기로 했고, 상당한 시간을 현재 에어 코드를 재 정립하는데 들였습니다. 
그러나, 이러한 선택을 하고서 깊이 들여다보니 깨달은것은 상기된 문제들을 강력하게 해결하고, 오랜시간동안 쓸 수 있게 하려면 플랫폼을 바꿔야 된다는것을요.
새로 갈아 엎으려니 그것이 가져다 줄 위험 또한 수반해야 했지만, 장기적인 시각으로 봤을때 소환사들의 이익이 더 이득이라는 믿음이 있었기 때문입니다.

그러한 이유로, 우리는 다시 시작했고 크로미늄 임베디드 프레임워크(CEF)를 우리의 프런트엔드로 구축했습니다.
엄청 강력한 HTML5 브라우저 구성요소이자 우리의 입맛에 맞춰 커스터마이징 할 수 있죠.

이제 우리가 최종 아키텍쳐로 가는 방법을 어떻게 찾았는지 말씀드릴게요.

 

단계 A : 자바스크립트는 세계의 왕이다!
우리의 처음 생각은 모든 작업을 자바스크립트로 하는것이었습니다.
UI를 개발함에 있어 우리는 HTML과 자바를 사용하려 했기 때문에, 모든 사업적인것들을 넣고 커뮤니케이선 로직을 자바로 넣는것이 아키텍쳐를 단순화 하고 획일성을 만들것이라고 생각했기 때문에 우리는 단순하면서도 간결한 C++라이브러리를 개발했습니다.

 

이 라이브러리는 자바스크립트가 RTMP를 통해 송수신이 가능하게 하죠.
RTMP는 우리 기준에선 현재도 문제없이 잘 작동하고 있고 통신 프로토콜을 클라이언트하고 동시에 변경하고 싶지 않았기 때문에 계속 유지하기로 했습니다.

 

내부 몇가지 프로토타입을 가지고 우리는 ember.js를 단일 페이지 응용 프로그램으로, ember-orbit을 데이터 레이어로 사용하기로 결정했습니다.
 

 

어떤 문제점이 생겼을까요? 몇가지가 나타났습니다.

 

웹티어에서 비동기 작업을 처리하다보니 자바 스크립트 코드가 매우 복잡해기 시작했습니다.

더 나아가 플레이어의 상태가 자바스크립트 상태다 보니 우리가 메모리 쉬이 점유율을 낮출 수 없었죠.

 

그래서 이 아키텍쳐는 상기된 1번 문제를 해결할진 몰라도 2번 문제나 3번문제에는 아무런 도움이 되지 못했습니다.
가슴 아팠지만, 내부 개발자들을 상대로 한 만족도 조사에서도 이 방식으로 개발하면 과거 에어클라이언트보다 생산성이 떨어진다고 나왔습니다. 

 

단계 B : 웹응용 프로그램(그러나 데스크톱에서)의 재발견!
우리의 다음 단계는 비동기 게임 프로토콜을 REST 리소스로 제공하여 마이크로-서비스들을 C++로 제공하는것이었습니다. 

 

우리는 일반 웹 응용프로그램들이 어떻게 설계되었는지 생각하기 시작했고 중간 단계 부분을 빼먹었다는것을 깨달았습니다.
그래서 RTMP 프로코토콜을 REST 리소스로 제공하기 위해, 자바스크립트가 지나치게 비동기화 되지 않기 위해 마이크로서비스 레이어(사용자의 데스크탑에서 실행중인)를 만들었죠. 
우리는 웹소켓을 UI로 사용했고 이 마이크로 서비스 레이어를 우린 "기반"이라고 명명했습니다.

 

 

아래의 다음 사진은 Swagger UI로 기반 패치 리소스의 일부를 보여주고 있는 사진입니다.
이 배열은 자바 스크립트 코드를 굉장히 단순화 시키고 있고 개발자들은 이제 표준 웹 기술을 사용할 수 있게 되었습니다.

 

 

또한 우린 이 아키텍쳐에서 추가적인 이점을 발견 할 수 있었는데요.
클라이언트를 최소화 할때 우리는 CEF UI를 포함한 모든 자바 VM을 끌 수 있었고 "기반"만 남겨 둘 수 있었습니다.
이것이 가능했던것은 "기반"이 표준상태를 유지 했기 때문입니다-전체 UI는 GET을 사용해 재구성 가능합니다.
이 기반은 오직 약 20메가바이트의 메모리만 사용하고 이 사용량은 대략적으로 고양이 사진 몇개정도로 나타낼 수 있겠네요. 
이제 더 이상 누구도 게임을 끝내고 클라이언트를 끌 이유가 없어졌고, 우리는 2번문제였던, "항시 접근 가능하고 사용가능한" 클라이언트를 구축 할 수 있었습니다.   
기반은 백그라운드 상태에서도 게임초대 혹은 친구추가등의 알림도 표시가 가능합니다.

 

단계 C : 한발자국씩..

다음단계는 확장성 아키텍처를 추가하는것입니다.

개발팀들이 마이크로서비스와 기능을 개발하기 시작하면서 새로운 문제에 직면했습니다.
이 팀들은 똑같은 코드를 업데이트 하면서도 또 서로 충돌했죠. 

 

확장성에 대해 알기 쉽게 비유하자면, 열명의 사람들이 하나의 책을 쓴다고 생각해보세요.
각 챕터들을 동시에 쓴다고 생각해보죠. (예를 들면 챕터2 : 초심자가 리그오브레전드를 하는법에 대해 열명이 동시에 쓴다)
서로의 문장이 맞다며 바꿔대고 고쳐댈텐데 아마 생지옥이 다름 없을겁니다.
반면 그들에게 각각의 챕터를 쓰게하여 같은 책에 독자적으로 작업 할 수 있게 한다면 효과적인 작업이 되겠죠.
(예로, 챕터5: 특성찍는법은 A가, 챕터6: 룬은 B가 작성)

 

저희는 비슷한 문제를 클라이언트 업데이트에서 겪었습니다.
팀들은 자기네 팀들의 기능을 추가하면서 서로 너무 잦은 코드들과 프레임워크들을 건드리다보니 우리는 가능한 독립성을 유지하기위해 아키텍쳐 패턴이 필요했습니다.

 

저는 이 확장성 아키텍쳐 작업에 상당한 시간을 소비했고 개발자간의 충돌 문제에 대해 어떻게 라이엇이 해결했는지 잘 알고 있습니다.
아키텍처를 단순하게 유지하기 위해 우리는 플러그인이라고 하는 확장적인 접근법을 선택했습니다.
플러그인은 독립적인 단위로서 소유권 개발, 테스트 그리고 배포를 아우르고 있습니다.
각각의 플러그인은 SEMVER(Semantic Versioning)를 존중하며, 반드시 어떤 플러그인들과 버전들에 맞는지 지칭해야합니다.
우리는 이것을 더 발전시켜 사용된 모든 플러그인들이 어떻게 종속되어있고 연결되었는가를 알 수 있도록 잘 보이게 그래프로 나타냈습니다

 

그래서, UI 화면이나 기능들이 우리가 부르는 프론트엔드(FE) 플러그인으로 들어가고 C++ 커뮤니케이션 로직은 (말도 어렵게 생긴)백엔드(BE) 플러그인으로 들어갑니다.
프론트엔드와 백엔드 플러그인 모두 새 클라이언트에 존재합니다.
우리가 프론트엔드, 백엔드라는 용어를 사용한 이유는 비록 단일 데스크톱 프로세스 내부에 있더라도, 서버 아키텍처를 흉내냈기 때문이죠.

 

 

이 아키텍처로 옮기는 과정에서 저희는 우리만의 획일적인 자바스크립트 데이터 레이어를 풀어야했습니다.
우리는 REST 리소스를 나타내는 단일로 연결된 그래프를 유지하기 위해서 Ember-Orbit이용했습니다.
이것은 팀들이 서로 다른 팀들의 데이터에 요청과 허락없이 접근 할 수 있다는점에서 큰 문젯거리였죠.

 

그래서 우린 Orbit을 사용하는걸 포기하고 프론트엔드 플러그인들이 가지고 있는 단순한 리소스 캐쉬를 사용했습니다.

 

단계 D : N 자바 스크립트 개발자에게 그들이 가장 좋아하는 MVC 프레임워크를 물어봤고 N+1의 답을 얻었습니다.

 

우리는 각 기능팀이 자체적으로 그들만의 자바 스크립트 프레임워크를 선택 할 수 있도록 허용했습니다.
우린 이제 훨씬 더 생산적인 아키텍처를 갖게 되었고 팀들은 화면들과 서비스들을 빠르게 만들 수 있었죠. 
책임은 각자의 몫으로 명확히 할 수 있었고요.

 

그러나 이번에 닥친 문제는 개발자 문제였습니다. 일부팀은 Ember.js를 좋아하지 않았고 웹 구성요소를 사용하길 원했습니다.
다른 팀들은 벌써 갖가지 프레임워크로 만들어진 응용프로그램을 새 클라이언트에 넣으려고 만들어버렸고요.

이 시점에서 우린 단지 개발자의 기호 때문에 "모든것을 Ember.js로"라는 규칙을 완화 시킬 순 없었죠.
Ember.js와 관련된 가정을 제거하고 단일 임베디드 프레임워크로 전환하는것은 심각한 작업이죠.

 

터닝포인트는 모든 사람들을 Ember로 강요할 수 없단것을 우리가 깨달았을때였습니다.
고통러웠지만 클라이언트를 설계하면서 각 플러그인이 잠재적으로 자체 프레임워크를 가질 수 있도록 하였습니다.
-자바 스크립트 프레임워크는 각각의 프런트엔드 도메인이 되었습니다. 

상기에 잠재적이란 단어에 유의해주세요.
우린 여전히 Ember를 대부분의 주요 기능에 일관성을 위해 사용하지만 이젠 기술적으로는 필요치 않습니다

 

최종 설계

업데이트 된 클라이언트는 앞에 언급되었던 세가지 근원적인 문제를 잘 해결하고 있습니다.

우리는 앞에서 언급했던 개발자를 상대로한 설문조사를 다시 시행했고, 대략 15%가 상황이 향상되었음을 그리고 빠르게 상승하고 있음을 나타내 주었습니다.

한 개발자는 우리가 데스크톱에서 데이터 센터를 만들었다고 말하기도 했습니다.
다른 관점에서 저는 우리가 게임클라이언트를 만들었는데 Atom(텍스트 에디터) 혹은 Electron 프레임워크로 Github의 CEF기반으로한 확장 가능한 텍스트 편집기를 만든것과 동등한일을 해냈다고 생각합니다.
흥미로운 작업들이었고, 처음 시작했을때 우리가 여기까지 오리라곤 생각지도 못했습니다.

 

질문이 너무 많아 이 게시물에서 다루지 못한 내용도 있습니다.
예를들어 어떻게 우리가 기능들이 상호 작용하게끔 하면서 원할하게 했는지
HTML5를 이용해 우리가 어떻게 게임 품질 효과를 나타냈는지
기능을 어떻게 개별적으로 탑재시켰는지 등등

흥미로운 주제이고 많은 관심이 있으시다면 이러한것들을 가지고 심도있는 대화를 다음에 해보겠습니다.