지연시간을 두고 벌이는 개발자와 이용자의 개선과 적응

우리가 흔히 빛의 속도라고 부르는 표현이 있다. 요즘은 빛의 속도를 뛰어넘는 것은 불가능하다는 인식이 완전히 잡혀서 SF를 다루는 콘텐츠에서도 실제로 빛의 속도를 뛰어넘는 속도를 내는 우주선 같은 것은 나오지 않는 시대가 되었는데, 그러다보니 실제 빛의 속도가 몇인가를 굳이 외우고 사는 사람들도 적은 편이다. 검색을 해보면 빛의 속력은 진공 상태에서 299,792,458 m/s 인데 우리가 흔히 알기 쉽게 비교하는 서울과 부산 간의 거리로 이것을 생각하면 1초에 460번정도 왕복할수 있는 셈이다. 조금 더 거리를 늘려보자. 서울의 정확한 지구 반대편의 위치를 고르라면 아마 바다 위가 될 테고, 그 근처에서 가장 가까운 도시는 부에노스 아일레스일 것이다. 부에노스 아일레스까지의 거리는 약 20000km 정도이고, 빛으로는 1초에 7.5번정도 왕복할 수 있다.

* 서울에서 부에노스 아이레스까지의 거리.

1초에 지구를 7번 반 돌 수 있다는 점을 생각하면 인간의 입장에서는 엄청 빠른 속도임에 분명하지만 어? 빛이란게 생각만큼 안빠른데? 싶은 생각도 든다. 쉽게 생각해보자. 여러분이 게임을 하는데 현대적으로 요구하는 모니터의 프레임레이트(초당 뿌려주는 화면의 개수)는 60fps 일테고, 고사양 게임용 디스플레이라면 144fps 일 것이다. 144fps 라면 프레임이 전환되는데 걸리는 시간은 프레임당 6.94ms 이고, 빛이 서울과 부에노스 아이레스를 왕복하는데 걸리는 시간은 0.133ms 이다. 대략 19프레임 정도가 지나간 셈이다.

물론 이것은 아주 이상적인, 서울과 부에노스 아이레스를 지구 표면을 지나는 가장 가까운 선으로 연결하고 진공 상태의 빛의 속도로 정보가 전달되었을 때 걸리는 시간이다. 그러나 실제로 우리가 서울과 부에노스 아이레스 사이에서 통신을 할 때는 설령 광섬유를 사용한다 하더라도 그 거리가 최단거리도 아닐 뿐 더러 여러 가지 중계기, 광섬유가 아닌 통신망 등을 거치며 발생하는 손실에 의해 이론상의 시간 안에 도달하기는 어렵다.

이런 부분은 게임을 만드는데 중대한 장애물로 작용하는 경우가 많다. 특히 점점 컴퓨터의 속도가 발전하면서 이러한 시간을 줄이는 것이 더욱 중요해지는 경향도 나타난다. 게임을 정의할 수 있는 방법 중 하나가 정보의 흐름이기 때문이다. 정보의 흐름 관점에서 게임을 보면 이는 물리적인 입력이 가상세계에 영향을 미치고 그것이 다시 플레이어의 감각으로 전달되는 순환 구조이다. 이렇게 적어놓으면 굉장히 단순해 보이지만 학교에서 배웠던 컴퓨터의 구성요소들을 생각해보자.

* 컴퓨터의 3요소: 입력장치, 처리장치, 출력장치.

우리가 보통 디지털 기기에서 즐기는 형태의 게임이 돌아가는 기계는 거의 다 이런 형태다. 입력, 출력, 처리 장치가 분리되어있는 경우도 존재하고 게임기처럼 입력장치(게임패드), 처리장치(각종 프로세서, 등등), 출력장치(스피커, 스크린)가 합쳐져 있는 경우도 존재할 것이다.

일반적으로 이러한 기기들의 시간은 사람의 신경반응속도를 제외한다면 게임에 미치는 시간적인 영향은 대부분 CPU의 처리속도와 저장매체의 통신속도 정도다. 턴제 게임이라면 문제가 없다. CPU플레이어들의 수많은 행동들을 계산하는 것도 이용자들은 기꺼이 기다려주기도 한다. RTS라면 이러한 문제점에 대비하기 위해 게임 안에 등장하는 유닛의 숫자를 제한한다. 유닛 수가 너무 많아저셔 각 유닛에 대한 처리가 CPU에 부담을 주거나 화면에 많은 유닛이 등장하면서 GPU의 처리시간이 늘어나는 것을 피하기 위함이다.

그렇다면 게임 개발자가 겪는, 특히 줄일 수 있다면 가장 줄여야만 하는 시간이라는 장애물은 어떤 것일까. 대표적인 부분은 로딩과 랙이다. 물론 개발 작업에 사용해야 하는 시간부터 이용자가 게임에 참여해 놓고 화장실에 가는 시간까지 수많은 시간들이 게임에 영향을 끼치지만 프로그래머가 컨트롤해야 하는 시간들은 이 부분이고 최대한 없는 것처럼 숨겨야 게임의 경험이 부드러워지는 부분이 바로 로딩과 랙이다.

좀 더 과거로 돌아가보자. 우리가 흔히 저장 아이콘으로 기억하는 디스크만 하더라도 나왔을 무렵에는 기존에 사용하던 카세트 형식의 자기 테이프보다 데이터를 읽어오는 속도에서 굉장한 우월함을 보였다. 당시 게이머들은 30분~1시간씩 데이터 로딩을 기다려가면서 게임을 해왔는데 게이머는 사실상 그냥 기다리는 수밖에 없었고 프로그래머들은 그 느린 데이터를 가져오는 속도, 한정된 용량등을 최대한 활용하여 성능을 내도록 수많은 알고리즘을 개발하고 사용해왔다.

하지만 온라인게임이라면 이 문제는 좀더 복잡해진다. 여기에 인체 신경의 반응속도까지 고려한다면 더 복잡한 상황이 벌어진다. 만약 온라인 게임 서버 등이 들어가면 어떻게 될까? 나의 행동에 피드백할 수 있는 또다른 플레이어 B 가 존재한다면? 실제로 명확한 수치는 아니지만 플레이어 A 가 한 행동이 플레이어 B 에게 도달하는데까지 걸리는 시간들을 쭉 나열해보자.

* 데이터의 흐름에 걸리는 시간들

플레이어 A가 모니터에서 상황을 인식하고 (13ms), 고민한다음 (100ms), 손으로 입력한후(200ms), 키보드로부터 컴퓨터가 입력을 받아(1ms), 공유기로 신호를 보내고 (0.5ms), 인터넷으로 신호를 전달해서 (30ms), 게임서버로 보내진후 (30ms), 서버에서 처리를 한 후 다시 인터넷으로 신호를 보내서 (30ms), 상대방의 공유기에 신호가 도달하고 (30ms), 공유기에서 PC로 (0.5ms), 게이밍PC에서 모니터로 (10ms), 사람의 눈이 모니터에서 신호를 확인할 때까지 걸리는 (13ms)까지. 판단과 반응속도에 걸린 시간 300ms를 제외하면 158ms 정도 시간이 걸린다. 이건 그냥 그럴수 있다는 것이고 사실 인터넷은 여러 레이어를 통해서 연결이 진행되기 때문에 실제 시간은 이것보다 훨씬 많이 걸릴 뿐더러 컴퓨터 사양, 네트워크 환경, 서버와의 거리, 사람의 컨디션 등으로 이 수치는 얼마든지 변할 수 있다. 다만 이 수치를 아무리 줄여도 결국 중간 단계가 늘어날수록 딜레이는 생겨날 수 밖에 없다.

이 과정을 정보의 흐름이라고 생각해보자. 만약 우리가 게임의 데이터 처리에 있어 사용자의 모든 입력을 반영해야 한다면, 그리고 이렇게 만든 한국의 게임을 아르헨티나의 한국 게임을 사랑하는 청년이 플레이한다면 어떤 과정을 겪게 될까?

게임 서버가 사용자의 입력에 반응할 때까지 0.13초 정도가 필요하다. 이는 144Hz환경으로 환산한다면 19프레임 정도로 볼 수 있을 것이다. 그런데 이는 빛의 속도로 통신한다는 가정 하에 이루어진 계산이고 실제 현실에서는 앞서 언급한 여러 이유로 대략 0.3초 정도의 지연이 발생한다고 볼 수 있을 것이다. 이조차 사실은 가장 낙관적인 계산이기도 하다. 만약 정말 서버가 유저의 입력을 기다려서 처리를 해야 한다면 우리는 한번의 처리를 0.3초에 한 번씩밖에 할 수 없고, 이는 1초에 3번밖에 계산을 할 수 없다는 의미이다.

게임이 정보의 흐름이라면 결국 이 흐름의 속도는 이용자가 게임을 하는데 느끼는 핵심적인 경험의 요소 중 하나가 된다. 턴제 게임이라면 어떻게 넘어갈 수도 있겠지만 실시간으로 이루어져야 하는 게임들이라면 이러한 데이터 지연 시간 문제는 플레이에 큰 장애를 만들 수 밖에 없다. 격투게임, RTS, MMORPG, 액션게임, 많은 게임들은 이러한 이유로 온라인상의 멀티플레이로 구현하기 힘들다는 평가를 받기도 했다. 그런데 게임 개발자들은 결국 이를 극복하고 온라인상에서 플레이어에게 지연이 느껴지지 않는 수준의 구현을 이루어냈다.

현대 게임 서버의 개발자들은 0.3초 지연이 발생할 수 있다는 것을 가정하고 게임 서버를 개발한다. 이부분을 명시적으로 정하거나 하지는 않았지만 0.2초~0.5초에서 지연이 발생했을 때도 자연스럽게 게임이 이어질 수 있도록 하는 설계해야 한다는 부분은 경험을 통해서나 혹은 선배 개발자들의 조언을 통해 이어져 내려오기도 한다. 과거에 이런 네트워크 지연으로 발생하는 게임의 버그들은 모든 기계장치가 모여있는 작업환경에서는 잘 발생하지 않아서 출시 시점에서야 몸으로 겪는 경우들이 많이 발생했지만, 최근에는 이러한 지연 처리의 중요성이 개발과정에서 부각되며 언리얼 엔진의 데디케이티드 서버부터 iOS의 에뮬레이터까지 게임 실행 차원에서 네트워크 지연에 대해 처리할 수 있는 일종의 에뮬레이션을 제공하는 경우들도 등장했다.

정보전달 속도라는 물리적인 한계를 극복하기 위해 개발자들은 다양한 해결책을 고안하고 있다. 가장 쉬운 방법은, 그냥 기다리는 것이다. 네트워크에서 지연이 발생했다면 그냥 동기화가 될 때까지 플레이어를 기다리게 만드는 방법도 존재한다. 모두가 다 같이 게임의 정지상태를 기다려줄 수 있는 참을성만 존재하면 괜찮다.

옛날 편지로 바둑을 두시던 분들 정도의 참을성이라면, 그리고 그런 게임이라면 문제가 없겠지만 실시간으로 움직여야 하는 게임들이라면 아무래도 이러한 기다림은 문제가 될 수 밖에 없다. 그러다보니 게임 개발자들은 어떤 사람들의 대답이 늦어져도 게임이 계속 돌아가게 만드는 방법들을 계속 적용하고 있다.

일반적인 방법은 예측이다. 게임 프로그램이 이용자의 움직임을 예측하는 것이다. 예측을 해낼 수 있다면 네트워크 딜레이가 1초가 있어도 괜찮다. 컴퓨터가 1초 후의 이용자의 움직임을 예측했다면 1초후에 보여줄 것을 미리 계산해서 보여주는 것으로 게임 안에서의 흐름은 완전하게 동작한다. 하지만 안타깝게도 컴퓨터는 완벽한 예언가가 아니다.

MMORPG나 액션게임을 하다가 만약에 상대방의 컴퓨터가 이동속도보다 빠르게 이동하는 부분을 겪었다면 컴퓨터가 예언을 실패한 것이다. 컴퓨터는 상대방의 이동을 예측해서 재현했지만 실제 결과가 달라졌기 때문에 나중에 입력된 실제 행동에 맞춰 미리 재현했던 부분과의 차이를 억지로 맞추는 것이다.

* 캐릭터의 동기화. 갑자기 이동시키거나 보간해서 미끄러듯이 맞추는 것이 일반적이다.

대전격투에서는 이런 시간의 문제가 특히 많이, 깊게 발생한다. 과거의 격투게임의 대전은 오락실이라는 공간에서 이루어지거나, 혹은 같은 기기에서 두 개의 게임패드가 붙어 이루어졌다. 네트워크 레이턴시가 거의 존재하지 않는 환경이었지만 격투게임의 이용자들은 자신의 입력을 가장 빠르게 게임에 입력하기 위해서 자신의 반사신경과 사고를 다듬는 것은 물론, 프레임 레벨에서 이루어지는 게임의 메커니즘을 파고들기도 했다. 이는 실제 게임의 입력 프레임과 처리 프레임, 그것이 모니터에 출력되는 프레임이 다르기 때문이기도 한데, 1프레임 단위로 기술의 승패가 결정되는 대전 격투게임의 세계에서는 이런 상황까지 분석하는 경우도 존재했다.

하지만 오락실이란 공간이 시대의 변화에 못 버티고 점차 사라지는 환경에서 많은 대전격투게임들의 대전이 네트워크라는 가상의 공간으로 올라오면서 네트워크 레이턴시는 격투 게임 개발자들에게 새로운 도전으로 다가왔다. 초기에는 네트워크 레이턴시 대응에 익숙하지 않아 나쁜 평가를 받기도 했지만 현대 대전 격투게임에 이르면 네트워크 대전 지원이 필수 요소로 인식되면서 기술과 꼼수 두 측면에서 모두 괄목할 발전을 보여주고 있다.

최근 격투게임에서 주로 이용되는 부분은 롤백이다. 흔히 롤백 넷코드라고 불리는 이러한 기능은 마찬가지로 상대방의 움직임을 컴퓨터가 미리 예측해서 해당 부분을 미리 보여줌으로써 게임이 실시간으로 빠르게 전달되고 있다는 “느낌”을 이용자에게 제공하고 있다. 그런데 입력을 예측하는데 실패했다면 컴퓨터는 어떻게 이를 처리할까. 몇프레임 뒤로 게임을 롤백해버린다.

이런 대응을 위해 애니메이션 단위에서 몇 프레임이 뒤로 돌아가도 어색하지 않도록 아트 단위에서 작업하는 게임들도 존재하며, 어떤 게임들은 기술 발동의 애니메이션 시간에 조금 여유를 둬서 네트워크를 동기화할 시간을 벌기도 한다. 입력이 들어가자마자 발동되는 잡기 기술이 점차 사라지고 있는 이유이기도 하다.

MMORPG도 비슷하다. 게임들의 캐스팅(주문시전) 시간에는 서버와의 통신 시간을 느끼지 못하게 하는 기능들이 일정부분 들어있다.  플레이어와 서버, 혹은 다른 플레이어 사이에서 주문의 결과를 동시에 나타나고 처리하기 위해서는 동기화 문제가 중요해지며, 이는 네트워크 레이턴시를 어떻게 숨길 것인가와 직접적으로 연관되기 때문이다. 많은 MMORPG가 논타겟팅이 아닌 타겟팅인 부분도 같은 이유에서다. 논타겟팅으로 진행을 한다면 타겟이 위치한 좌표가 서버와 플레이어의 컴퓨터 사이가 같은 시간 동일하게 나타나야 하는 동기화 문제가 중요해지며 이 이유는 플레이어가 실제로 자신의 공격 범위 안에 들어왔다고 생각하고 기술을 시전했을 때 기술의 성공 유무가 달라지기 때문이다.

네트워크 지연을 숨기기 위해 게임의 디자인 측면에서 약점을 숨겨버리는 경우도 존재한다. 특히 즉시 기술이 발동하는 부분은 한번에 보내는 데이터의 양부터 속도까지 여러 가지 영향을 받는 요소이기 때문에 MMORPG에서는 한번에 많은 스킬을 쓰지 못하게 하는 경우도 존재한다. 스킬을 사용했을 때 쿨타임 후에 동작하는 부분부터 타겟팅 문제, 플레이어 캐릭터의 상호 충돌 판정 제거와 같은 부분은 게임 서버의 개발 난이도를 낮추는 요소들이다. 물론 과감하게 여러 트릭과 기술력으로 문제점을 정면돌파하는 경우들도 존재한다. 만 명이 넘어가는 공통 월드의 MMORPG, 100명이 한 레벨에서 경쟁하는 FPS나, 4안 멀티가 가능한 벨트스크롤 액션게임 등은 그 전까지는 네트워크 환경에서 힘들다는 평가를 받던 도전을 트릭과 기술력으로 돌파했다고 보아도 괜찮을 것이다.

한편, 숨길 수가 없는 네트워크 지연은 앞서 말했듯이 강력하게 숨겨버린다. 예를 들어 게임 캐릭터의 위치는 조금 달라도 이용자들이 받아들일 수 있는 부분이다. 그런데 결제한 금액이 틀리는 건 문제의 차원이 다르며, 보안 문제 역시 존재한다. 이러한 영역에서의 시간 지연은 강렬한 연출로 가려버리는 것이 일반적이다. 현대 캐릭터 수집 가챠 게임의 캐릭터 뽑기에서 초반에 기대감을 연출하는 화려한 애니메이션은 이용자의 소비를 유도하는 강렬한 후킹 요소이기도 하지만, 서버와의 통신시간을 감추는 트릭이기도 하다. 드물게 준비된 연출 시간보다 반응에 시간이 더 많이 소요될 경우 문이 열리거나 다음 화면으로 넘어가지 않고 계속 이펙트가 돌아가는 연출을 본 사람들도 존재할 것이다.

네트워크 레이턴시가 아니라 데이터가 오가는 레이턴시 역시 개발자들에게는 주요하게 뛰어넘어야 할 벽들이다. 오픈월드는 특히 이 문제가 도전적으로 다가오는 장르인데, 오픈월드 내의 이동속도에 걸리는 제한 등은 이러한 하드웨어 한계로부터 기인한다. 오픈월드에서 빠른 속도로 이동했을 때 게임 월드의 로딩이 늦어진다면 이미 플레이어가 목표지점에 도착한 후에 건물이 생겨나던가 NPC가 생겨나는 것을 보아야 하기 때문에 이것 또한 개발자들에게는 극복해야하는 요소들이다.

블리자드의 <월드오브 워크래프트>는 이러한 로딩에 대한 요소를 레벨 디자인적인 요소로 해결하였다. 스톰윈드나 오그리마, 언더월드, 썬더 블러프의 입구는 한번에 도시 내부가 다 보일 수 없도록 통로를 크랭크 형태로 디자인함으로써 플레이어가 도시 내부에 들어가는 동안 도시 내 환경 요소들의 로딩을 마무리하기 위한 트릭 중 하나다.

* 스톰윈드 정면. 도시 밖에서 안으로 들어가기 위해서는 입구에서 직진하는 대신 좌우의 크랭크식 통로로 꺾어져 들어가야 하며 이 시간동안 컴퓨터는 도시를 로드한다. 출처 월드 오브 워크래프트 클래식 사이트.

지연시간 문제를 아예 강력한 기계적인 성능으로 메꿔버리는 경우도 존재한다. 플레이스테이션 5부터 게임기에서는 SSD가 일반적으로 사용되기 시작했는데, 이는 게임 로딩의 주요한 병목이 되는 디스크로부터 데이터를 읽어오는 시간을 줄일 수 있는 방법이다.

게임 개발자들이 다양한 프로그래밍, 디자인 기술을 통해 시간지연 문제에 대응해 온 것 이상으로, 게이머들 또한 로딩과 랙을 중요하게 다루며 대응하고 발전해 온 바 있다.

최적화된 게임 플레이를 원하는 이용자들은 최대한 로딩을 적게 보기 위한 방법을 하고 실험하고 도입하고 있다. 특히 격투게임의 경우는 레이턴시를 프레임 단위로 계산하며 게임을 진행하는 것이 고수들 사이에는 일반적이다. <월드 오브 워크래프트>처럼 다인 참여형 대규모 레이드가 주요 콘텐츠인 게임에서도 게이머들은 자신의 DPS를 높이기 위해 스킬과 스킬 사이의 입력에 시간적인 손실이 발생하지 않도록 하기 위해 게임 서버와 클라이언트 사이의 시간에 대해서 끊임없이 연구한다.

개발자 입장에서 가장 황당한 경우는 네트워크 레이턴시가 존재할 때만 발생하는 틈을 노리는 기술들을 네트워크 대전에서 사용하는 경우일 것이다. 정상적인 네트워크 레이턴시라면 기술이 막혀야 하는 상황에서 레이턴시로 인해 클라이언트에서 기술이 막히기 전에 한번 더 기술을 사용하는 이런 특수한 사례들을 이용자는 성공률이 낮다고 하며 사용하지만, 개발자 입장에서는 네트워크 레이턴시, 즉 랙이 존재해야만 들어가는 기술을 사용하는 사례를 보며 네트워크 레이턴시조차 개발자들의 의도를 벗어나 사용하는 이용자들의 행동에 대해 고민하게 만드는 것이다.

게임 개발자에게 지연시간은 넘어서야 할 장애물이지만 게이머들에게는 이조차 자신이 이용할수 있는 수단이기도 하다. 개발자들은 이 장애물을 없애거나 줄이기 위해 싸우고, 이용자는 현실적인 랙에 적응하고 이용해가면서 디지털게임은 계속 어딘가를 향해 나아가고 있다.