요약: 향후 6개월여 동안 리그 오브 레전드 클라이언트의 백엔드 구조에 여러 변경사항과 개선사항을 적용할 계획입니다. 진행 과정을 추적하기 위해 클라이언트 부트스트랩 시간(클라이언트가 기동되기까지 걸리는 시간)과 챔피언 선택 준비 완료 시간이라는 두 가지 주요 클라이언트 성능 지표에 관한 구체적 목표를 공유해드리려고 합니다. 해당 지표들을 개선하는 과정에서 버그와 프로그램 충돌 등 다양한 요소도 함께 다룰 예정입니다. 간단히 말해서, 저희의 목표는 클라이언트 유지 보수입니다.

“라이엇 게임즈, 클라이언트는 언제 다듬을 생각이에요?”

이 질문을 지금까지 많은 플레이어 여러분께서 해 주셨습니다. 클라이언트가 현재 최상의 상태는 아닙니다. 버그도 아주 많고 처리 지연 문제(특히 챔피언 선택 과정에서의 문제)도 너무 많은데다 메모리 누수, 프로그램 충돌, 먹통 현상 등 다양한 문제를 가지고 있죠. 과거에 클라이언트를 개선하겠다는 약속을 한 적이 있지만 아직 문제는 그대로인 상황입니다.

그래서 다른 방법을 시도해보려고 합니다.

이 글에서는 모호한 표현으로 저희의 계획을 설명하는 대신 향후 6개월에 걸쳐 적용하려고 하는 변경사항에 대한 구체적인 성능 목표와 명확한 세부사항을 말씀드리겠습니다.

먼저 현재까지 적용된 최근의 성능 개선사항을 짚어본 뒤 추후 개선사항을 적용해 나가는 과정에서 이정표가 되어줄 구체적 수치 몇 가지를 살펴보겠습니다.

숫자로 본 클라이언트

지난 해 말, 저희는 클라이언트를 기동해서 완전히 사용할 수 있게 될 때까지 걸리는 시간(일명 “부트스트랩 시간”) 등 기본 성능 지표를 추적하기 위한 몇 가지 도구를 클라이언트에 추가했습니다.

저희는 상대적으로 느린 컴퓨터를 사용하는 플레이어 여러분의 경우에도 부트스트랩 시간을 15초 미만으로 단축하려고 합니다. 하지만 현재 일부 플레이어 여러분의 경우 그 서너 배에 달하는 시간이 부트스트랩 과정에 걸린다는 사실을 확인했습니다.

저희가 추적해 온 또 하나의 주요 요소는 “챔피언 선택 준비 완료” 시간입니다. 클라이언트에서 준비 완료 버튼을 클릭한 후 챔피언 선택이 확정되기까지 걸리는 시간을 말하죠. 아래 그래프는 9.22 패치 기간(주황색 선)과 10.2 패치 기간(파란색 선) 동안 챔피언 선택 준비 완료에 걸린 평균 응답 시간을 나타냅니다. 챔피언 선택 확정 응답 시간은 천 분의 일 초(ms)로 표시했습니다.

위 그래프는 플레이어에 따라 챔피언 선택 응답 시간이 얼마나 크게 달라질 수 있는지를 보여줍니다. 물론 클라이언트 성능은 컴퓨터가 얼마나 빠른지에 따라 다릅니다. 예를 들어, 챔피언 선택 확정까지 200ms 미만이 걸리는 경우는 10백분위수에 속합니다. 전체 플레이어 중 90%보다 응답 시간이 빠르다는 뜻이죠. 마찬가지로 응답 시간이 800ms을 넘기는 경우는 90백분위수에 속하며, 전체 플레이어 중 90%보다 클라이언트가 느리게 작동한다는 것을 의미합니다.

그래프에 나타난 것처럼, 챔피언 선택 확정 시간은 9.22 패치 기간에 비해 10.2 패치 기간에 대폭 개선되었습니다. 확정 시간이 개선된 큰 이유는 9.23 패치 기간에 리그 오브 레전드 클라이언트가 작동하는 기반인 크로미엄(Chromium) 버전을 업데이트했기 때문입니다. 이를 통해 상당한 개선을 이루었지만 저희는 많은 플레이어 여러분의 경우 아직 클라이언트가 너무 느리다고 생각합니다.

더 자세한 설명을 위해 일부 특정 집단의 챔피언 선택 확정 시간별 응답 속도 세부 수치를 들여다보겠습니다.

위 그래프에서 파란색 선은 플레이어 “중간값”인 50백분위수를 나타냅니다. 중간값 플레이어의 응답 시간이 가파르게 떨어진 부분은 바람직합니다. 하지만 심지어 2020년 초에도 중간값 플레이어의 챔피언 선택 응답 시간은 300ms대를 웃도는 모습을 보입니다. 최악의 수치는 아니지만 지연 시간을 체감할 수 있다는 점은 같습니다.

70백분위수 플레이어(녹색 선)는 최근 상당히 개선된 모습을 보였지만 챔피언 선택 응답 시간은 450ms대 이상을 기록하고 있습니다. 거의 0.5초에 달하는 지연 시간으로, 중간 성능 컴퓨터로 플레이하는 경우에 대해 저희가 원하는 속도보다 솔직히 훨씬 느린 수치입니다.

마지막으로 90백분위수(주황색 선)는 전체적으로 말도 안 되는 수치를 나타내고 있습니다. 당연히 90백분위수의 경우에는 대부분의 플레이어보다 훨씬 느린 응답 속도를 체감하게 될 겁니다. 하지만 800ms는 너무 깁니다. 이것이 크로미엄 업데이트 후에도 적지 않은 플레이어 여러분이 처한 상황인 것이죠.

그럼 앞으로의 계획에 대해 말씀드리겠습니다!

앞으로 우선적으로 개선할 부분

저희가 우선시하는 구체적이고 장기적인 클라이언트 성능 목표 두 가지는 아래와 같습니다.

1. 부트스트랩 시간을 90백분위수 플레이어의 경우에도 약 15초로 단축하려고 합니다. 현재에 비하면 서너 배 빠른 수치입니다.
2. 챔피언 선택 확정 응답 시간을 90백분위수 플레이어의 경우에도 약 100ms로 낮추려고 합니다. 현재보다 약 8배 빠른 속도입니다.

여러분이 무슨 생각을 하시는지 알 것 같습니다. 버그는 어쩌고요? 프로그램 충돌이나 메모리 누수가 일어나면 어쩌죠?

이 두 목표를 우선시하는 이유는 무엇일까요? 그 이유는 부트스트랩 시간과 챔피언 선택 확정 시간을 개선하는 과정에서 클라이언트 아키텍처의 근본적인 특정 요소를 정리하고 재작업하게 될 것이기 때문입니다. 저희는 이 목표들을 추구하는 과정에서 버그, 메모리 누수, 프로그램 충돌도 자연스럽게 처리할 수 있을 것이라고 생각합니다.

챔피언 선택 화면의 “블랙 스크린(검은 화면이 나타나는 현상)” 버그나 룬 페이지가 제대로 저장되지 않는 등의 문제는 이번 개선 과정의 일환으로 저희가 다루려고 하는 것의 일부 사례일 뿐입니다. 하지만 이 작업에는 시간이 필요하다는 사실은 분명히 말씀드리고 싶습니다. 저희는 현재 약 6개월 간의 계획을 마련했으며 이 기간 동안 해당 목표들을 향해 의미 있는 발전을 이룰 수 있을 것이라고 생각합니다. 하지만 장기적인 목표를 달성하기까지는 더 오랜 시간이 걸릴 것으로 보입니다.

위에 말씀드린 내용은 목표이며, 목표를 달성하지 못할 가능성도 있습니다. 저희가 목표를 여러분께 말씀드리는 이유는 클라이언트에 대한 여러분의 신뢰를 얻기 위해서는 그 어느 때보다 투명하게 알려드려야 한다는 사실을 알기 때문입니다.

그럼 여러분은 물으실 겁니다. "그걸 정확히 어떤 방식으로 하려는 건가요?"

추후 개선 방식

현재 저희는 부트스트랩 시간을 지연시키는 구조적인 주요 문제 두 가지를 확인했습니다. 첫 번째는 클라이언트 코드를 활용성 있는 묶음으로 나눠주는 플러그인 아키텍처입니다. 이 아키텍처는 클라이언트에 새로운 기능을 추가하는 과정에서 너무나 커진 상태입니다. 두 번째는 UI를 구동시키는 일명 엠버(Ember)라고 불리는 자바스크립트 프레임워크가 남용되고 있다는 점입니다.

현재 클라이언트는 너무 많은 플러그인과 엠버 앱을 사용하고 있습니다. 실제로 클라이언트 부트스트랩 과정 동안 로딩되는 플러그인은 41개, 앱은 16개나 됩니다. 이들 각각을 기동하는 데에는 100ms에서 800ms의 시간이 필요하죠. 바람직하지 않은 현상입니다.

저희의 계획은 이 모든 플러그인과 앱을 훨씬 적은 수의(그리고 이론적으로 더 효율적인) 플러그인과 앱으로 통합하는 것입니다. 먼저 부트스트랩 과정에서 기동되는 부분들에 초점을 맞추려고 합니다. 전체적인 클라이언트 성능을 가장 크게 개선할 수 있다고 생각되는 요소이기 때문이죠.

1단계: 부트스트랩

현재 많은 플레이어 여러분의 경우 부트스트랩 완료까지 40초에 달하는 시간이 필요합니다. 여기에 해당되신다면 이 시간이 엄청나게 느리고 짜증날 수 있다는 것을 아실 겁니다. 게다가 클라이언트가 프로그램 충돌을 일으키기라도 한다면 다시 클라이언트를 실행시키는 것이 훨씬 더 괴롭게 느껴지기도 하죠.

알림, 친구 목록, 컬렉션 탭 등 클라이언트 전체적으로 많은 부분들이 부트스트랩 과정에서 기동되는 플러그인과 앱의 영향을 받습니다. 그래서 저희가 정한 장기적 목표는 부트스트랩 시간을 90백분위수 플레이어의 경우에도 15초로 단축하는 것이지만 그 과정에서 클라이언트 전체에 영향을 주는 수많은 버그와 비효율적인 부분들도 처리하게 될 것이라고 생각합니다.

부트스트랩 개선에 몇 달간 집중한 후에는 목표에 얼마나 가까워졌는지 평가한 후, 아마 늦봄쯤에 특별히 챔피언 선택 과정에 집중하는 단계로 넘어갈 계획입니다.

2단계: 챔피언 선택

챔피언 선택 과정에서는 추가적으로 많은 플러그인과 엠버 앱이 등장합니다. 직설적으로 말하자면, 챔피언 선택 과정에서 활용되는 거의 모든 요소가 새로운 앱을 실행시킵니다. 챔피언을 맞교환(“챔피언 스왑”)할 경우 두 개의 앱이 실행되죠. 소환사 주문을 변경하는 경우에도 마찬가지입니다.

클라이언트를 종료하지 않은 채로 리그 오브 레전드를 오래 플레이할수록 이러한 앱들이 갈수록 더 쌓이게 되고 결국 점점 속도가 느려지는 것을 체감하게 됩니다. 엎친 데 덮친 격으로 이 문제는 챔피언 선택 과정에서 하는 행동 대부분이 라이엇 게임즈 서버와의 통신에 의존한다는 사실 때문에 매 상호작용마다 지연 시간이 추가되는 결과를 낳습니다.

챔피언 선택 과정의 진정한 근본적 문제는 리그 오브 레전드의 백엔드 시스템이 데이터를 관리하는 방법입니다. 현재 챔피언 선택 과정의 아키텍처는 내부 시스템을 통해 수많은 데이터를 강력하게 처리할 수 있게 합니다. 예를 들어, 라이엇 게임즈가 랭크 게임에서 어느 챔피언을 사용하지 못하도록 결정하는 순간 거의 바로 모든 플레이어는 그 챔피언을 사용할 수 없게 될 겁니다. 챔피언 사용 금지가 적용될 때 챔피언 선택 과정에 있다고 하더라도 말이죠.

아주 강력한 시스템이지만 구현하려면 많은 자원이 필요합니다. 그리고 이 시스템이 현재 설정되어 있는 방식의 처리 과정에는 불필요한 많은 관문이 있고 병목현상도 일어나죠. 그래서 작은 입력 데이터 하나만 변경되어도 엄청나게 많은 데이터가 다시 전송되는 경우가 많습니다. 이 때문에 클라이언트 경험이 크게 악화되는 결과가 발생합니다.

이 문제를 해결하기 위해 저희는 챔피언 선택 과정 백엔드 구조가 작동하는 방식을 근본적으로 변경해야 할 겁니다. 챔피언 선택 과정에서 모든 데이터가 서버를 통해 클라이언트로 전달되는 방식을 재작업할 계획이며, 여기에는 어느 정도 시간이 걸릴 겁니다.

클라이언트 전체를 플러그인이 전혀 없는 단일 엠버 앱으로 통합하는 등 챔피언 선택 과정을 훨씬 더 효율적으로 개선할 수 있는 다른 원대한 장기적 목표도 있습니다. 하지만 단기적으로는 앞에서 말씀드린 목표 속도로 클라이언트가 동작할 수 있도록 하기에 충분한 변경사항을 적용하려고 합니다.

6개월에 걸친 이 작업 과정을 마쳤을 때 “바람직한 상태”에 얼마나 가까워져 있을지는 확실하지 않습니다. 하지만 이 과정이 끝나면 아마 엄청난 개선이 이뤄져 있을 것이며 다음 단계가 명확히 보이는 상태가 되어 있을 것이라고 생각합니다.

추후 행보

성능에 관한 구체적인 수치와 프로젝트 일정 조정 내용을 담은 작업 진행 상황을 개발자 블로그를 통해 두 달마다 전해드리려고 합니다.

클라이언트 개선 작업에 많은 기대 부탁드립니다! 리그 오브 레전드를 플레이해 주셔서 진심으로 감사드리며, 곧 새 소식으로 찾아뵙겠습니다.