요약
-----
지난 며칠간 라이엇 e스포츠 기술팀은 2022 미드시즌 인비테이셔널 (MSI) 대회 중 현지 및 원격 선수 의 핑 값을 맞추는 도구에 발생한 기술 문제를 해결하고자 노력했습니다.
첫 번째 문제는 대회에 참가하는 모든 선수의 지연율(핑)을 35ms로 조정하도록 설정한 Latency Service Tool (지연율 제어 툴)이라는 소프트웨어에서 발견된 버그였습니다. 해당 버그로 인해 한국 부산의 경기장에 있던 선수의 실제 핑은 화면에 표시된 35ms 핑보다 더 높았습니다. 실제로 중국 선수들은 35ms 핑으로 플레이한 반면 부산 선수들은 더 높은 수치의 핑으로 플레이한 것입니다. 하지만 대회가 시작되기 전에 해당 문제를 파악하지 못했습니다. 원인을 더 빨리 파악하지 못한 이유는 해당 툴의 코드 상의 핑 지연 계산 버그로 인해 게임 로그에서조차도 잘못된 값이 기록되어 지속적인 모니터링 및 사전 테스트에서도 모든 것이 올바르게 작동하는 것으로 나타났기 때문입니다.
기술팀은 문제를 해결하고자 5월 13일에 지연율 제어 툴의 설정을 변경했습니다. 초과 지연율을 적용하면 네트워크 환경이 부산 경기장의 선수들에게 불리하다는 점을 고려하여 핑 레벨이 동등하지 않았던 3개의 B조 경기를 다시 진행하는, 어렵지만 필요한 결정을 내리게 되었습니다.
5월 13일 수정 적용 후 부산에서 플레이하던 선수 화면에 표시된 핑이 실제 수정된 핑보다 낮게 표시되는 부작용이 발생했습니다. 그 결과 선수의 모니터를 방송 화면으로 송출했을 때 잘못된 낮은 핑 값이 표시되었고, 이 시각적인 불일치를 사전에 설명하지 않아 시청자들은 당연히 경기장의 선수가 실제보다 낮은 핑으로 플레이하고 있다고 믿게 되었습니다.
이 글을 통해 대회 전부터 현재(그룹 스테이지 이후)까지의 상황을 기술적인 관점에서 설명하고자 합니다.
대회 전
---------
올해 MSI 이벤트를 위한 기술 설정의 마지막 단계를 준비하며 계속되고 있는 코로나19 문제에 대한 조치 또한 취해야 했습니다. LPL 팀 대표인 RNG(Royal Never Give Up)은 상하이에서 부산까지 이동할 수 없었기 때문에 원격으로 참여해야 했죠.
표면적으로 봤을 때 원격 참여 팀은 원격으로 MSI 서버에 연결하여 플레이하고 현지 참여 팀은 경기장 네트워크에서 연결해 플레이하는 것이 가장 쉬운 방법이었을 수 있습니다. 하지만 이 방법에는 몇 가지 문제가 있었습니다.
첫 번째로는 부산과 상하이는 황해를 사이에 두고 약 850km 떨어져 있습니다. 네트워크 트래픽이 상하이와 한국에 있는 MSI 대회 서버를 통과해 다시 상하이로 돌아오게 됩니다.
이때 이 왕복 네트워크 트래픽 타이밍은 '핑' 혹은 '지연율'로 측정됩니다. RNG의 위치에서 MSI 대회 서버까지 왕복하는데에는 약 35ms(밀리초)가 걸립니다. 부산 현장에 있는 팀은 11개 팀 중 10개 팀이며, 이 팀들의 핑은 약 15ms로 더 낮습니다. 이 핑 값은 자연적으로 +/- 5ms만큼 변동할 수 있기 때문에 근사치라는 점을 참고해 주시기 바랍니다.
일반적인 리그 오브 레전드 플레이어의 경우 35ms와 15ms의 핑 차이가 현저히 느껴지지 않을 수 있지만, 프로 선수의 경우에는 게임 플레이에 변화를 줄 수 있을 만큼 유의미한 차이입니다. 라이엇의 핵심 원칙 중 하나가 경쟁의 무결성이기 때문에 토너먼트 기간 동안 모든 팀이 공정한 환경에서 경쟁할 수 있도록 조치해야 했습니다.
따라서 이 공정한 환경을 구축하기 위해 핑 차이 문제를 해결해야 했습니다.
원격 플레이를 통한 대회 진행
---------------------------------------
e스포츠 경기는 네트워크를 통해 진행되기 때문에 저희는 2022 MSI를 원격으로도 참여할 수 있는 솔루션을 찾고자 했습니다.
문제는 두 가지였습니다.
상하이와 부산 사이의 35ms 핑은 최상위 수준의 선수들이 실력을 발휘할 수 있는 허용 범위 내에 있는가?
모든 선수가 동일한 지연율을 경험하며 플레이할 수 있는 공정한 환경을 구축할 수 있는가?
1번 문제에 대한 대답은 '그렇다'였습니다. 리그 오브 레전드 e스포츠는 최상위 수준의 대회에서 플레이가 가능한 상한선을 40ms로 두며, 이때 허용 가능한 편차는 +/- 5ms입니다. 이 수치는 2020년 중반 내외부 파트너사, 내부 게임 분석 및 기획 그룹과 함께 심층적인 논의와 분석을 거쳐 결정된 사항입니다. 면담을 진행한 선수 대부분이 핑을 인식하기 시작하는 변곡점이 40ms이며, 40ms부터 교차 선택, 스킬 적중, 상대 플레이에 대한 빠른 반응 속도와 같은 요소가 영향을 받기 시작합니다.
2번 문제에 대한 답변을 내놓기 위해서 몇 가지 해결책을 고려했습니다.
**해결책 1: 모든 팀이 자연적인 네트워크 지연율에 따라 플레이한다**
이 선택권은 원격 참여 팀이 가장 빠른 인터넷을 사용하여 MSI 대회 서버에 접속하는 것입니다. 그렇게 되면 MSI 현지 경기장에서 참여하는 팀은 매우 낮은 핑(~15ms)에서 플레이할 수 있지만, 원격 팀(RNG)은 서버와의 거리에 의한 자연적인 지연율(중국의 경우 ~35ms)로 플레이하게 됩니다.
경쟁의 무결성이라는 원칙에 따라 검토한 결과, 모든 팀의 공정성을 위해 이 해결책은 배제하는 것으로 결정했습니다.
**해결책 2: 서버를 중국과 한국의 중간에 배치한다**
중국과 한국 사이의 핑이 35ms인 만큼 서버를 두 나라 중간에 배치하고 핑 차이를 나누어 모든 팀의 핑이 17.5ms가 되도록 하는 방법도 있습니다. 이 해결책에는 많은 문제가 있습니다. 그중 가장 큰 문제는 바다 한가운데에 서버를 배치해야 한다는 점입니다.
**해결책 3: 인위적인 지연율을 적용한다**
한국에서 플레이하는 팀의 핑이 매우 낮고 중국에서 플레이하는 팀의 핑이 더 높은 것이 문제라면, 한국 쪽에 약간의 지연을 적용해 평준화하면 어떨까요? 이를 통해 문제를 해결할 수 있을까요? 이 방법이 가능할까요?
리그 오브 레전드 개발팀은 이미 지연율 제어라고 알려진 인위적인 지연율을 적용하는 방법을 마련했습니다. 이걸 '가짜 핑'이라고도 합니다. 이 가짜 핑은 코로나19로 여행이 제한됨에 따라 원격으로 경기를 진행할 수 있도록 경기장 환경을 평준화하기 위해 구축된 클라이언트/서버 기능입니다. 지연율 제어를 통해 목표값(예: 35ms 핑)을 설정할 수 있고, 필요에 따라 각 선수의 클라이언트와 서버 간에 인위적인 지연을 적용해 모든 선수의 환경을 동일한 수준의 지연율로 평준화할 수 있습니다.
지연율 제어는 과거 e스포츠 이벤트에서 사용된 적 있지만, 이 경우 모두 원격으로 진행되었습니다. 일부 팀이 현지 경기장에 있음에도 지연을 적용하는 글로벌 이벤트는 이번이 처음이었을 겁니다. 그렇기 때문에 이전에 사용한 적이 있더라도 환경상의 사소한 차이로 인해 달리 확인할 수 없었던 버그가 발생할 가능성은 항상 있습니다. 저희는 스크림 서버에 인위적인 지연을 적용하고 기존 인프라 및 네트워크 테스트를 진행하면 그룹 스테이지 시작 전에 주요 문제를 찾아내기에 충분한 양의 실제 사용 데이터를 얻을 수 있을 거라고 판단했습니다.
**최종 해결책**
주어진 해결책을 비교하면서, 가장 중요한 것은 경쟁의 공정성이므로 인위적인 지연율 적용이 최선의 방법이라는 결론에 도달했습니다.
인위적인 지연율 적용 작동방식
------------------------------------------
지연율 제어는 리그 오브 레전드 소프트웨어의 기본 클라이언트/서버 네트워크 스택에 내장되어 있습니다. 지연율 제어를 통해 각 플레이어와 서버 간 실제 네트워크 지연율을 지속적으로 측정하고 목표 지연율에 도달할 수 있도록 인위적인 지연을 적용하고 필요에 따라 조정합니다. 지연율 제어는 클라이언트/서버 솔루션이므로 서버와 클라이언트 양쪽에 동등하게 지연을 적용합니다.
위 그림은 다양한 시스템 구성 요소를 보여줍니다. 그림 상단에는 게임 서버 구성 요소를, 하단에는 클라이언트(플레이어의 PC)를 나타내었습니다. 이 예시를 보면 지연율 제어는 35ms에 맞추어 평준화하도록 설정되어 있습니다. 빨간색 화살표는 실제 네트워크 지연율을 나타냅니다. 부산에서 경기한 선수 1과 선수 2의 '실제' 핑은 15ms였으며 상하이에서 경기한 선수 10의 핑은 35ms였습니다. 노란색 상자는 클라이언트와 서버 측에 인위적으로 적용된 지연율을 보여줍니다. 이 경우 선수 1과 선수 2의 클라이언트 측과 서버 측에 각각 10ms의 지연율을 추가하여 목표 지연율인 35ms를 달성합니다. 플레이어 10의 실제 지연율은 이미 목표 지연율과 동일한 35ms이므로 지연율이 추가되지 않습니다.
하나의 공정한 환경, 두 개의 공정환 환경?
----------------------------------------------------
더 자세히 설명하기 위해 원격 환경과 현장 환경에 대해 저희가 내린 결정을 말씀드리겠습니다.
e스포츠 테크놀로지 팀은 라이브 이벤트의 위험 요소를 최소화하기 위해 항상 노력하고 있습니다. 2012년 로스앤젤레스에서 열린 시즌 2 월드 챔피언십 도중 인터넷 문제로 경기를 중단해야 했던 기억은 e스포츠를 담당하는 모든 라이엇 직원들에게 쓰라린 기억으로 남아 있습니다.
저희는 2022 MSI 이벤트의 네트워크 구성에 대해 두 가지 전략 중에서 하나를 선택해야 했습니다.
**전략 1: 모든 경우에 대해 한가지 네트워크 구성 사용**
라이엇의 글로벌 토너먼트 대회는 이벤트 현장에 물리적으로 설치한 게임 서버를 통해 진행됩니다. 이 방식은 네트워크와 서버를 현장에서 직접 제어할 수 있게끔 하기 때문에 높은 안정성이 보장됩니다. 한 팀은 원격으로 플레이한다는 점을 고려하여 해당 팀이 인터넷 네트워크를 통해 접속하는 경우에 대비해야 했습니다. 한 팀이 인터넷을 통해 접속해야 한다면 현장에 배치된 서버를 사용하지 않고 모든 팀이 인터넷을 통해 접속하는 것도 하나의 방법일 겁니다.
안정성의 원칙을 고려하면, 인터넷을 통해 접속하는 게임 서버를 사용할 경우 가장 안정적인 서버를 택하고 싶었습니다. 바로 한국의 대회용 서버였죠. 이는 프로 전용 환경으로서, 한국의 일반 서버와 동일한 데이터 센터에 있으며 한국 이스포츠 리그인 LCK에서 현재 사용하고 있는 서버입니다. 다시 말해 수많은 플레이 시간을 통해 양호한 네트워크 연결과 안정적인 인프라가 검증된 서버입니다. 안정성을 따지고 보면 최소 한 팀이 원격으로 경기에 참여해야 할 때 이 방법이 가장 합리적입니다. 그런데 이 서버를 모든 경기에 사용해야 하는지, 아니면 원격 팀이 참가하는 경기에만 사용해야 하는지에 대한 의문이 있었습니다. 이는 '전략 2: 네트워크 장애 요소 최소화'로 이어집니다.
**전략 2: 필요시에만 원격 접속 형태 사용으로 네트워크 장애 요소 최소화**
전략 1에 따라 특정 경기만 인터넷 환경에서 플레이하게 되면 '모든 게임을 인터넷 환경에서 플레이하지 않을 이유는 무엇인가?'라는 질문이 생깁니다. 이에 대한 답변은 매우 간단합니다. 바로 인터넷 안정성 문제죠. 인터넷은 완벽하게 잘 작동할 수도 있지만, 그렇지 않을 수도 있습니다. MSI 대회의 모든 경기를 인터넷을 통해 플레이하면 잠재적인 인터넷 문제가 게임에 영향을 줄 가능성이 모든 게임에 존재합니다. 반면 원격 참가 팀이 있는 경기만 인터넷을 통해 플레이한다면 그러한 위험을 해당 경기만으로 한정할 수 있죠. 저희는 여러 비상 상황 대비 계획을 통해 인터넷 문제에 충분히 대응할 자신이 있지만, 그럼에도 이런 위험을 가능한 한 최소한으로 유지하는 것이 바람직합니다. 저희가 인위적인 지연율을 적용하여 핑 측면에서 경기 환경을 평준화할 수 있다는 점을 고려하면 이는 복잡성이냐, 안정성이냐의 문제였습니다. 저희는 위험 부담을 낮추기 위해 (혹은 잠재적인 인터넷 안정성 문제를 최소화하기 위해) 두 가지 접속 형태를 준비해봤습니다.
이 두 가지를 비교한 후 대회의 안정성과 경쟁의 무결성 측면에서 전반적인 위험이 가장 낮을 것으로 판단되는 전략 2를 진행하기로 결정했습니다.
아래는 저희가 선택한 접속 형태를 도식화한 것입니다. 네트워크 연결에 대한 다양한 상황을 나타냅니다.
최선의 계획…
----------------
모든 요인을 고려한 후 저희는 모든 경기에서 지연율 수준을 동일하게 맞추기 위해 지연율 제어를 사용함으로써 게임의 무결성을 유지하면서 두 종류의 접속 형태를 지원하기로 결정했습니다. 물리적으로 한국에 있는 팀의 경기는 MSI 경기장의 게임 서버를 통해, 원격 팀이 포함된 경기는 한국 데이터 센터의 대회 서버를 통해 진행하게 되었습니다. 저희는 시스템을 설정하고 인프라 테스트를 수행하여 모든 것이 제대로 되었는지 확인했습니다. 여기에는 핑 값, 핑 값 변동 정도 측정 및 모니터링과 패킷 손실 여부를 확인하는 작업이 포함되어 있었습니다. 또한 선수팀이 e스포츠 게임 서버를 사용하여 스크림 경기를 하도록 하고, 경기장에서도 사전 체크를 하도록 요청했습니다.
대회 첫날 후 선수들은 게임이 매끄럽지 않았다고 말했습니다. 화면 오버레이에 핑이 35ms로 나와 있지만 더 느리게 느껴졌다고 보고한 선수들도 있었습니다. 어떤 로그나인프라모니터링 툴상에서도 문제가 없었지만 저희는 원인을 밝혀내기 위해 계속 조사했습니다.
**알 수 없는 원인**
문제의 근원은 불분명했습니다. 인프라 모니터링 도구에 따르면 어떠한 문제도 없었습니다. 핑이 높게 느껴진다는 보고가 있었지만, 자세히 확인해봐야 할 특별한 버그나 게임 상황 또한 없었습니다. 결국 기본 원칙을 되짚었습니다. 어떤 데이터를 사용할 수 있는가? 어떤 로그가 있는가? 어떤 정보를 수집할 수 있는가?
두 갈래의 접근 방식을 취했습니다. 첫 번째로는 상황을 더 잘 파악할 수 있도록 프로팀에게 전달할 질문을 모았죠. 어디에서 해당 현상을 발견했는지? 경기장 서버와 e스포츠 대회 서버 중 어느 쪽이 더 좋지 않았는지? 경기장 네트워크와 스크림 네트워크 중 어느 쪽이 더 좋지 않았는지? 모든 경기에서 해당 현상을 발견했는지? 아니면 일부 경기에서만 발견했는지? 두 번째로, 표준 보고서에는 어떠한 문제도 보이지 않았기 때문에 다른 로그와 측정 기준을 사전에 파악하고 불일치하는 부분이 있는지 확인하기 시작했습니다. 토너먼트에서 클라이언트 및 서버 로그를 가져와 그 데이터를 조사하기 시작했죠.
예시로, 게임 서버가 프레임 속도를 안정적으로 유지하지 않는지에 대한 한 가지 가설이 있었습니다. 그래서 처음 며칠 동안 모든 경기의 로그를 모아 검토 도구를 통해 데이터를 시각화했고 위의 그래프를 얻게 되었습니다. 그래프를 보면 한 경기에서 다음 경기까지 서버에서 일관된 프레임 속도를 유지하고 있음을 알 수 있습니다. 데이터에 따르면 게임 서버 성능도 안정적이었습니다. 따라서 프레임 속도는 선수들이 보고한 일관되지 않은 응답 속도의 원인이 아닐 가능성이 높았습니다.
로그를 살피는 일은 세심함이 요구되는 작업입니다. 로그 데이터는 무작위 숫자가 나열된 여러 페이지처럼 보이고, 이를 시각화하고 이해하려면 다양한 도구를 거쳐 편집해야 합니다. 하지만 이 과정을 거칠 때마다 문제가 없다는 결과가 나왔죠.
로그와 코드를 살피면서 프로팀으로부터 추가적인 정보를 받기 시작했습니다. MSI 경기장 환경에 대한 불만이 더 많았습니다. 저희가 납득할 만한 정보가 아닌 듯했습니다. 무엇보다 경기장에서는 모든 선수가 선수들과 같은 곳에 있는 서버를 사용하여 경기를 진행합니다. 어떻게 완벽하게 제어되는 네트워크 환경의 경기가 인터넷을 통해 진행하는 경기보다 좋지 않을 수 있을까?
이는 또 다른 가설로 이어졌습니다. 로그에는 지연율 측정 결과가 양호한 것으로 나오지만 게임이 매끄럽지 않다면 로그에 문제가 있는 건 아닐까? 지연율을 측정하는 방식에 문제가 있던 것은 아닐까?
이를 테스트하고자 개발팀에서 코드를 만들어 클라이언트의 사용자 지정 디버그 빌드를 편집했습니다. 일반적으로 로그는 게임 데이터 패킷이 서버상의 네트워크 레이어와 클라이언트 내 네트워크 레이어 사이를 '왕복'하며 생성됩니다. 이 로그 상에는 오류가 없었습니다. 그래서 새로운 도구를 통해 다른 방식으로 지연율을 테스트했습니다. 네트워크 레이어에서 트래픽의 지연율을 테스트하는 대신, 사용자가 클릭한 후 해당 클릭에 대한 응답이 올 때 까지의 전체 종단 간 루프를 테스트하고자 했습니다. 다시 말하자면, 단순히 네트워크의 성능을 측정하는 것이 아닌, 게임 엔진의 모든 시스템 사이에서 발생하는 상호 작용을 측정하는 것이었습니다.
이 개념은 위 그림에 설명되어 있습니다. 기존 네트워크 모니터링 시스템은 녹색 화살표에 따라 네트워크 레이어의 지연율을 측정합니다. 이렇게 하면 네트워크 레이어와 지연율 제어의 지연 사이에 있는 모든 것이 측정됩니다. 업데이트된 모니터링 도구의 경우 빨간색 화살표를 따라 지연율을 측정합니다. 이를 통해 입력 레이어에서 네트워크 레이어를 통해 서버상의 게임 엔진까지, 다시 클라이언트에 이르기까지 전부 측정할 수 있습니다.
이 새로운 진단 측정 도구를 가지고 선수들이 언급한 문제를 재현할 수 있는지 보기 위해 몇 가지 실험을 준비하고자 했습니다.
저희는 가장 먼저 지연율 제어를 비활성화한 상태에서 기준 측정값을 얻고자 했습니다. 공식 서버의 수많은 플레이 시간 데이터가 있기 때문에 이 실험은 서버 버그가 없다고 확신할 수 있는 '대조' 테스트로 간주했습니다. 기준이 되는 이 첫 번째 실험에서는 한국팀과 중국팀이 모두 인터넷을 통해 서버에 연결되었을 때의 환경을 시뮬레이션했습니다.
**실험 1: 지연율 제어를 비활성화한 상태에서 한국 네트워크와 중국 네트워크 비교**
이 실험의 데이터는 복잡했지만, 데이터를 취합해 시각적으로 나타낸 후 나타난 현상을 이해할 수 있었습니다.
게임 시간을 나타내는 X축을 따라가면, 처음에는 차트 왼쪽과 같이 지연율이 낮았던 것으로 확인됩니다. 저희는 몇 분 후 (차트 중앙을 기준으로 왼쪽에서 오른쪽으로) 핑이 더 높은 네트워크 환경(예: 상하이)을 시뮬레이션했습니다. 세로축의 지연율이 위쪽으로 이동한 것이 보이실 겁니다. 정확히 저희가 예상했던 결과죠. 핑이 낮은 네트워크에서는 지연율이 낮고 핑이 높은 네트워크에서는 지연율이 더 높습니다.
대조 테스트였던 첫 번째 실험에서 새로운 기술을 사용한 측정 결과는 저희의 예상과 일치했습니다. 순조로운 시작이었죠.
다음으로는 동일한 네트워크 조건 속에서 지연율 제어가 활성화된 상태에서 테스트를 진행했습니다.
**실험 2: 지연율 제어를 활성화한 상태에서 한국 네트워크와 중국 네트워크 비교**
지연율 제어의 목적은 자연적인 네트워크 핑과 상관없이 지연율을 평준화하는 것입니다. 저희는 실험에서 네트워크 핑 특성을 변경하면 지연율 제어가 보정되고, 결과적으로 지연율 측정값이 동일하게 유지될 것이라고 예상했습니다. 그러나 데이터 결과는 달랐습니다. 데이터를 보면 지연율 측정값은 한국 네트워크보다 상하이 네트워크 시뮬레이션 시 더 낮았습니다. 이 결과는 예상과 달랐으며 지연율 제어가 상하이 환경보다 한국 환경에서 더 높은 지연율을 발생시키고 있었음을 알 수 있습니다.
이 보고서를 바탕으로 세 가지 결론을 내렸습니다.
- 문제는 실제로 존재하며, 새로운 데이터는 선수들이 보고한 내용과 일치한다.
- 우리는 실험을 통해 문제를 재현할 수 있다.
- 문제는 인위적인 지연율 도구와 관련이 있을 가능성이 있다.
저희는 이 정보를 가지고 코드의 어느 부분에서 문제를 살펴야 하는지에 대한 좋은 아이디어를 얻을 수 있었습니다. 실험실 환경 특성을 변경했을 때 어떤 결과가 발생했는지 확인하기 위해 다양한 추가 테스트를 진행했습니다. 그 과정 중에 실제 핑이 목표 지연율보다 훨씬 낮은 경우에서만 발생하는 계산 오류가 있다는 것을 알게 되었죠. 이 경우 실제 지연율은 플레이어의 화면 오버레이에 표시되는 값보다 훨씬 더 높을 수 있습니다.
이 오류는 여태껏 저희가 경험한 다양한 문제에 대한 답을 주었습니다. 로그에 어떠한 문제도 나타나지 않던 이유는 애초에 계산이 잘못되었기 때문이었습니다. 핑이 낮은 환경에서는 계산 버그가 더 심하게 나타나기 때문에 인터넷 서버보다 경기장에서 지연율이 더 좋지 않았는 지를 설명해 주었습니다. 또한 부산에 있던 선수들이 35ms보다 핑이 더 좋지 않았다고 느끼는 이유가 화면에는 핑이 35ms로 나와 있지만 실제로는 더 나빴기 때문이라는 점도 설명이 되었습니다.
이제 문제를 파악했으니 다음으로 문제를 최대한 빠르게 해결해야 했습니다.
다행히도 코드를 살펴보았기 때문에 문제의 본질을 파악하고 계산 오류를 보정할 수 있는 해결책을 찾을 수 있었습니다.
환경을 시뮬레이션하는 방법과 사용자 지정 도구를 사용해 실제 지연율을 측정하는 방법을 알아냈기 때문에 양쪽 네트워크에서 지연율이 알맞게 평준화될 때까지 환경 설정을 조정할 수 있었죠.
아래 차트는 이전 두 실험과 동일한 네트워크 시뮬레이션을 나타냅니다. 하지만 이번에는 지연율 제어의 버그를 보정한 업데이트된 설정을 적용했습니다.
**실험 3: 설정이 수정된 지연율 제어 활성화**
앞서 언급한 두 가지 실험에서처럼 이번에도 먼저 낮은 핑 환경을 시뮬레이션한 다음 몇 분 후에 조정하여 높은 핑 환경을 시뮬레이션했습니다. 하지만 이전 실험과 다르게 설정 변경을 적용한 후에는 지연율 제어가 올바르게 지연율을 보정했습니다. 그래프와 같이, 낮은 핑에서 높은 핑으로 전환한 후에도 지연율에 큰 차이가 없음을 확인할 수 있었습니다.
**그렇다면 문제가 해결된 것이 아닌지?**
설정 변경을 통해 게임 내 핑 계산 버그를 수정하긴 했지만, 변경 사항 적용 후 FPS와 핑을 표시하는 화면 (ctl-v) 오버레이가 부산에 있는 선수들에게 실제 지연율보다 약 13ms 낮은 잘못된 값을 표시한다는 부작용이 있었습니다. 이는 지연율 제어에 적용한 설정 변경이 계산 버그를 보정하기 위해 목표값에 기본적으로 오프셋을 추가하여 발생한 현상입니다. 이 현상은 클라이언트에서 기록되고 표시되는 핑 값에 오프셋이 적용되는 문제로 이어졌습니다. (이후 상세 설명 추가) 즉 화면에 표시된 숫자가 실제 핑보다 13ms 낮다는 것이었습니다. 유감스러운 일이지만, 화면에 잘못된 값이 표시되더라도 공정한 경기를 위해 올바른 지연율을 게임에 적용하는 것이 낫겠다고 생각했습니다.
가야 할 방향과 쉽지 않은 결정
---------
실제 지연율을 올바르게 측정하는 방법과 계산 오류 보정을 위해 설정을 변경하는 방법을 알아낸 후 저희는 즉시 수정 사항 적용 계획과 그 배경을 선수와 커뮤니티에 전달하기 위해 준비하기 시작했습니다.
그런데 문제를 파악하며 더 복잡한 문제점이 있다는 것을 알게 되었습니다.
MSI 경기장 내 선수들이 35ms보다 더 높은 핑으로 플레이한 반면 상하이에서 플레이하는 원격팀은 상하이와 부산 간의 자연 지연율인 35ms 핑 범위 내에서 플레이했다는 점과 그로 인해 공정한 경기를 위한 동등한 핑을 구축하지 못했다는 점이었습니다.
이를 즉시 해당 팀에 알려야 했습니다. 이것이 경기를 다시 치러야 할 만큼 유의미한 차이인지에 대한 의문은 해결하지 못했습니다. 이는 대회 운영팀 측에서 결정해야 할 사항이었습니다. 저희가 판단한 바로는 지연율 차이가 15~20ms 범위 이내였으며, 이를 근거로 공정한 경쟁을 위해 3개 경기에 새로운 설정 변경을 적용해 다시 진행한다는 어려운 결정을 내리게 되었습니다.
핑 오버레이 수치에 대한 이해
---------
토너먼트 초반에 문제가 있었던 경기를 다시 치르기로 결정한 후 저희는 많은 일을 해야 했습니다. 일정을 재조정하고 해당 팀에 연락하여 상황과 이유를 납득시켜야 했죠. 또 게임 서버에 적용할 설정 변경을 준비하고 전체 테스트를 다시 진행하여 변경이 적용되었는지도 확인해야 했습니다. 또한, 문제가 해결되었는지 두 번, 세 번 거듭 확인하기 위해 프로 선수들을 초청하여 새로운 구성으로 서버를 테스트했습니다. 프로 선수들을 대상으로 두 설정을 모두 확인해 보고 어느 쪽이 35ms 핑처럼 느껴지고 어느 쪽이 더 높게 느껴지는지 확인하는 블라인드 테스트를 진행하기도 했습니다.
하지만 안타깝게도 선수 화면에 보이는 핑 오버레이 수치가 정확하지 않다는 사실을 선수들과 방송팀에 분명하게 전달하지 않았죠.
토너먼트가 재개되고 얼마 지나지 않아 팬들은 부산에서 경기를 진행한 팀에게 부당한 이점으로 작용한 것처럼 보이는 문제를 제기하기 시작했습니다. 팬분들은 저희가 예상했던 ~35ms 핑 대신 22ms 핑을 보여주는 스크린샷을 게시하기 시작했습니다.
이 부분은 분명히 설명하겠습니다.
앞서 말씀드렸던 지연율 제어 버그를 해결하고자 이를 보정하는 오프셋 값이 설정에 추가되었습니다. 이 오프셋 값은 화면 오버레이에 표시된 값에 영향을 미치는 문제점이 있었습니다.
- 상하이에 있는 선수에게 표시된 핑 값은 정확합니다.
- 부산에 있는 선수에게 표시된 핑 값은 정확하지 않습니다. 실제 게임 플레이 지연율은 표시되는 것보다 약 13ms 더 높습니다.
원인을 반복하여 설명하자면, 상하이의 핑은 이미 목표 지연율인 35ms이므로 보정이 적용되지 않았기 때문에 상하이의 핑 값은 정확합니다. 부산의 핑 값이 잘못된 이유는 지연율 설정의 오프셋이 엔진의 핑 오차를 보정하여 실제 핑은 ~35ms로 맞춰졌는데, 그 결과 로그와 오버레이 화면의 핑을 약 13ms 상쇄했기 때문입니다.
이를 검증하기 위해 30개 이상의 세션에서 클라이언트 로그를 수집했고, 플레이어가 화면에서 볼 수 있는 값과 상관관계가 있는 핑/지연율 데이터를 그래프로 나타냈습니다.
위 그래프에는 RNG의 게임만 표시되어 있습니다. Y축은 보고된 핑 값입니다. 시간 경과에 따른 데이터를 나타내는 이전 섹션의 그래프와 달리 위 그래프에서는 X축이 각 게임의 개별 데이터 세트를 나타냅니다. 위 히스토그램의 녹색 사각형은 한 경기에서 한 선수의 머신으로부터 보고된 핑 값을 클라이언트 로그에서 읽은 대로 나타낸 것입니다. 보이는 것과 같이 값에 약간의 변동이 있고 모두 33ms에서 39ms 범위에 있습니다. 알려진 대로 RNG의 자연적인 핑 값인 35ms +/- 5ms에 들어맞는 범위입니다.
다음으로 살펴본 데이터 세트는 설정 변경 전과 설정 변경 후의 부산에 있는 선수들의 클라이언트 로그였습니다.
위 그래프는 부산 경기장에서 진행된 게임만 볼 수 있게 필터링된 데이터입니다. 양방향 화살표 왼쪽에 표시된 경기는 설정 변경 전에 플레이한 경기입니다. 보이는 것과 같이, 보고된 값은 35ms +/- 5의 범위에 있는 33~39ms입니다. 핑이 잘못되었다고 느낀 선수의 보고에 따라 추후 수정된 종단 간 모니터링 도구로 확인한바, 이 값이 잘못된 것임을 알게 되었습니다.
우측을 보면 실제 핑을 수정하여 설정 변경을 적용한 후 보고된 핑 값이 감소하여 19ms와 25ms 사이의 값을 표시하며, 일반적으로 22ms +/- 5ms의 범위에 값이 표시되는 것을 알 수 있습니다. 이 두 값을 뺄셈하면 보고된 핑 값의 오프셋 오차가 약 13ms(35ms-22ms=13ms)로 일관됨을 알 수 있습니다. 따라서 실제 지연율 문제를 해결하기 위해 설정을 변경한 후 부산 내 선수 화면에서 오버레이 핑 값이 22ms로 표시될 때 실제 값은 35ms인 것이 맞습니다.
다시 T1 대 SGB 경기 스크린샷을 보면 설정 변경을 통해 실제 핑을 35ms로 맞췄음에도 Zeus 선수의 화면에는 왜 22ms로 표시되었는지 알 수 있습니다. 클라이언트 로그 실증 데이터에서 수집한 13ms의 보정 오프셋 값을 더하면 35ms라는 올바른 핑 값이 나오게 됩니다.
결론
---------
저희는 라이브 이벤트를 지원하는 기술팀으로서 원활한 경기 진행을 보장하고자 경기 환경을 테스트하고 이중, 삼중 확인하는 절차를 진행하고 있습니다. 또한 프로팀을 위해 공정한 경기를 만들고자 최선을 다하는 것을 항상 최우선으로 삼습니다. 저희의 목표는 기술적인 문제 없이 멋진 경기와 게임 플레이를 선보이는 것입니다.
경쟁의 공정성을 유지하고 전 세계 팬들에게 최고의 e스포츠 시청 경험을 선사하기 위해 최선을 다하고 있습니다. 계획을 변경하는 데는 위험이 수반되지만 저희는 선수들과 팬들에게 최고의 경험을 선사하고자 계획을 세우고 이러한 위험을 검토합니다.
이번 일의 경우, 게임에 영향을 주는 버그를 파악하지 못했습니다. 대회 진행에 혼란과 불편을 드린 점, 핑 오버레이 수치 오류를 명확하게 설명하지 않아 혼란을 드린 점 진심으로 사과드립니다.
쉽지 않은 일이었음을 인지하고 있으며, 럼블 스테이지와 토너먼트 스테이지를 원활하게 진행할 수 있도록 추가적인 테스트와 검증 조치를 준비하고 있습니다. 이러한 어려움이 있었음에도 경기 내내 뛰어난 적응력을 보여준 프로팀과 선수들의 공로를 인정하고 싶습니다. 또한, 이 문제를 해결할 수 있도록 피드백을 주셔서 감사합니다. 향후에도 대회에 영향을 미치는 문제가 다시는 없을 것이라고 장담할 수는 없지만, 이번 기회를 통해 배우고, 더 발전하며, 팀 및 팬분들과 더 적극적으로 소통하도록 하겠습니다. 또한 이벤트 환경을 모니터링하고 확인하는 능력을 계속 개선해 나가겠습니다.
