- Published on
[Network Gaming 2] 독재자의 통치술: 데디케이티드 서버는 어떻게 거짓말로 세상을 지배하는가
- Authors
- Name
- Logan Kim
0. 시간을 거스르는 아저씨들의 컨트롤
라떼 아저씨들이라면 리니지나 바람의나라, 울티마 온라인 같은 초기 MMORPG를 해본 사람이 꽤 있을 것이다.
내가 리니지 헤비유저는 아니지만, 당시에는 흑단막대 컨트롤이라는 게 있었다. 흑단막대로 상대를 타게팅해 경직을 주고, 그 짧은 딜레이 사이에 붙어서 칼질할 타이밍을 버는 기술이다. PK 잘하는 네임드들의 고급 스킬이었다.
바람의나라에는 한 칸 띄기, 두 칸 띄기라는 게 있었다. 몬스터가 플레이어에게 붙기 전에 필살기(백호검무, 백호참 등)를 꽂아 넣는 고수들의 기술이다. 화면상으로는 마치 공간을 건너뛴 것처럼 보이고, 다른 플레이어 눈에는 이게 더 극단적으로 보인다.
이 글에서는 이런 기술들을 묶어서 '틱 컨트롤'이라고 부르겠다. 이게 되는 사람과 안 되는 사람의 차이는 단순히 손이 빠르냐가 아니었다. 서버가 세상을 '언제' 계산하는지를 몸으로 아느냐의 차이였다.
지난 편에서 우리는 락스텝이라는 민주주의가 무너지고 데디케이티드 서버라는 독재자가 세워지는 과정을 봤다. 결론은 이랬다.
"니들 클라이언트 연산은 전부 가짜야."
진짜 좌표는 오직 서버에만 있다.
그런데 이 독재 체제에는 치명적인 약점이 하나 있었다. 독재자는 느리다. 모든 판결이 서버를 한 번 왕복해야만 내려진다.
이번 편은 그 느림을 감추기 위해 게임 개발자들이 동원한 온갖 거짓말과 속임수에 대한 이야기다. 그리고 그 속임수의 흔적은, 아날로그에서 디지털로 넘어가던 시절, 추억보정이 잔뜩 묻은 채로 우리가 PC방에서 겪었던 이상한 현상들 속에 고스란히 남아 있다.
1. 틱(Tick): 독재자의 심장박동
독재자는 세상을 연속적으로 보지 않는다. 정해진 박자마다 한 번씩 세상을 멈춰 세우고, 그 사이에 들어온 모든 입력을 모아서 한꺼번에 판결한다. 이 한 번의 판결 주기를 틱(Tick)이라고 부른다.
초당 10틱이라면 서버는 0.1초에 한 번 세상을 계산한다. 그 0.1초 사이에 "흑단막대 시전"과 "이동 마우스 입력"을 동시에 눌렀다면, 그 입력은 다음 틱이 올 때까지 서버 대기실에 앉아 있어야 한다.
내가 이해하기로는, 다음 틱에서 스킬 적중과 적중당한 플레이어의 경직이 계산되고 마우스 광클릭으로 플레이어는 이동도 같이 했기 때문에 경직과 동시에 순간적으로 공격대상 플레이어에게 붙어버리게 된다.
틱 컨트롤의 정체가 바로 이것이다. 고수들은 틱이니 입력 지연이니 하는 전문용어는 몰라도, 이 0.1초라는 짧은 시간 동안 '이렇게 하면 되더라'라는 감각을 몸으로 익혔다. 이론은 몰랐어도, 독재자의 심장박동에 맞춰 춤을 춘 셈이다.
여기에 핑(Ping)까지 더해진다.
- 내 입력이 서버까지 가는 시간
- 서버가 틱을 기다리는 시간
- 결과가 다시 내 화면으로 돌아오는 시간
이 세 개가 쌓이면 내가 키를 누른 순간과 서버가 그걸 '사실'로 인정하는 순간 사이에는 생각보다 큰 시차가 생긴다. 다이얼업 모뎀 시절이었다면 수백 밀리초는 우스웠다.
문제는 사람이 이 시차를 너무 잘 느낀다는 것이다. 키를 눌렀는데 캐릭터가 0.3초 뒤에 움직이면, 그 게임은 '렉 게임'이라는 낙인이 찍힌다. 독재자는 공정했지만, 너무 굼떴다.
2. 클라이언트 예측: 허락받기 전에 먼저 움직여라
1996년, id Software의 존 카맥(John Carmack)은 바로 이 굼뜸과 싸우고 있었다. 퀘이크(Quake)는 순수한 서버 권위 구조였고, 모뎀 유저들은 키를 누를 때마다 캐릭터가 한 박자 늦게 반응하는 고통을 겪었다. 그가 QuakeWorld에서 내놓은 해법은 간단하면서도 대담했다.
"서버의 허락을 기다리지 말고, 클라이언트가 먼저 움직여라."
이것이 클라이언트 측 예측(Client-Side Prediction)이다. 내가 앞으로 가는 키를 누르면, 클라이언트는 서버의 응답을 기다리지 않고 '아마 서버도 이렇게 계산하겠지'라고 예측해서 내 캐릭터를 즉시 움직인다. 동시에 그 입력을 서버로 보낸다. 대부분의 경우 서버의 계산과 클라이언트의 예측은 일치하고, 유저는 렉을 느끼지 못한다.
잠깐, 15편에서 클라이언트 연산은 전부 가짜라고 하지 않았나? 맞다. 여전히 가짜다. 다만 독재자가 판결을 내리기 전까지 임시로 보여주는 가짜일 뿐이다. 진짜 판결이 도착하면 클라이언트는 무조건 거기에 복종해야 한다.
고무줄 현상: 독재자의 정정 보도
그럼 예측이 틀리면 어떻게 될까? 렉이 심하게 걸린 상태에서 열심히 달렸는데, 갑자기 캐릭터가 몇 걸음 뒤로 '쭉' 끌려가는 경험. 다들 한 번씩 해봤을 것이다. 흔히 고무줄 현상(Rubber-banding)이라고 부른다.
이건 버그가 아니라, 독재자의 정정 보도다. 클라이언트는 "나 저기까지 갔어"라고 예측했지만, 서버는 "아니, 너는 벽에 막혔어" 혹은 "네 입력은 도착하지 않았어"라고 판결한 것이다. 클라이언트는 서버가 확정한 위치로 되돌아간 뒤, 아직 서버가 확인하지 않은 입력들을 그 위에 다시 재생한다. 이 과정을 서버 보정(Server Reconciliation)이라고 한다.
고무줄처럼 끌려가는 그 순간, 우리는 가짜 세계가 진짜 세계에 의해 덮어씌워지는 장면을 눈으로 보고 있었던 것이다.
3. 보간: 남의 캐릭터는 언제나 과거에 산다
내 캐릭터는 예측으로 해결했다. 그런데 다른 유저는? 남의 입력은 내가 예측할 방법이 없다. 서버가 보내주는 위치 정보, 즉 스냅샷(Snapshot)만 받아볼 수 있을 뿐이다.
문제는 이 스냅샷이 틱마다 띄엄띄엄 온다는 것이다. 받은 좌표를 그대로 찍으면 다른 캐릭터는 한 칸, 한 칸 순간이동하듯 뚝뚝 끊겨 움직인다. 패킷 하나가 빠지기라도 하면 몇 칸을 한 번에 점프한다. 렉 걸린 날 필드에서 다른 유저들이 미끄러지듯 순간이동하던 그 모습이 바로 이것이다.
그래서 개발자들은 또 하나의 속임수를 꺼냈다. 보간(Interpolation)이다. 클라이언트는 받은 스냅샷을 바로 보여주지 않고, 일부러 조금 늦게 재생한다. 그리고 두 스냅샷 사이를 부드럽게 이어서 그려준다. 0.1초 전의 위치와 지금 받은 위치 사이를 선으로 쭉 그어서 그 위를 걸어가게 만드는 것이다.
덕분에 화면은 부드러워졌다. 하지만 여기엔 섬뜩한 진실이 하나 숨어 있다. 우리가 보는 다른 유저는 언제나 과거의 모습이다.
- 나 자신은 예측 덕분에 미래를 살고 있고,
- 남들은 보간 때문에 과거를 살고 있다.
같은 화면 안에 서로 다른 시간대가 공존하는 것이다.
15편에서 락스텝이 평행우주를 만들었다고 했던가. 데디케이티드 서버는 평행우주는 없앴지만, 대신 시차가 뒤섞인 우주를 만들어냈다. 그리고 이 시차는 다음 섹션에서 아주 억울한 죽음으로 이어진다.
4. 랙 보상: 독재자의 소급 판결
시차가 뒤섞인 우주에서 총을 쏘면 무슨 일이 벌어질까?
내 화면에 보이는 적은 과거의 적이다. 나는 과거의 적 머리에 정확히 조준해서 쐈다. 그런데 서버의 장부에서 그 적은 이미 몇 걸음 옆으로 이동해 있다. 서버 기준으로 판정하면 내 총알은 허공을 가른다. 분명히 맞혔는데 안 맞는 게임. 이런 게임은 아무도 하지 않는다.
그래서 Valve는 하프라이프와 카운터 스트라이크 시절, 더 과감한 수를 둔다. 서버가 판정을 내릴 때 시간을 되감는 것이다.
서버는 모든 플레이어의 과거 위치를 일정 시간만큼 기록해둔다. 그리고 내가 총을 쏜 입력이 도착하면, "이 사람의 핑과 보간 지연을 감안하면, 쏘는 순간 이 사람 화면에는 세상이 이렇게 보였겠구나"라고 계산해서 그 시점으로 모든 플레이어를 되돌린 뒤 명중 여부를 판정한다. 판정이 끝나면 다시 현재로 돌아온다. 이것이 랙 보상(Lag Compensation)이다.
독재자가 피고의 진술 시점으로 시계를 돌려서 소급 판결을 내리는 셈이다. 쏜 사람 입장에서는 공정하다. 문제는 맞은 사람이다.
벽 뒤로 완전히 숨었는데 한 박자 늦게 쓰러지는 경험, FPS를 해본 사람이라면 다 안다. 내 화면에서는 이미 안전지대였지만, 상대의 과거 화면에서는 내가 아직 벽 밖에 있었던 것이다. 독재자는 상대의 과거를 기준으로 판결했고, 나는 이미 지나간 시간 속에서 죽었다.
비슷한 이유로 모퉁이에서 먼저 튀어나오는 쪽이 유리해지는 피커스 어드밴티지(Peeker's Advantage)도 생긴다. 튀어나오는 사람의 움직임은 상대 화면에 시차를 두고 도착하기 때문이다. 이 시차를 줄이려는 노력이 결국 틱레이트 경쟁으로 이어지는데, 이건 다음 편의 이야기로 남겨두자.
5. MMO의 독재는 스케일이 다르다: 존과 AOI
여기까지는 FPS든 MMORPG든 공통으로 쓰는 기술이다. 그런데 MMORPG에는 FPS가 겪지 않는 고유한 지옥이 하나 더 있다. 바로 머릿수다.
FPS 한 판은 많아야 10명 남짓이다. 한 명의 움직임을 나머지 9명에게 알려주면 끝이다. 틱당 90건 정도의 소식만 전하면 된다.
MMORPG는 다르다. 한 마을에 1,000명이 모여 있다고 해보자. 모든 사람의 움직임을 모든 사람에게 알려주려면, 틱당 1,000 × 999, 약 100만 건의 소식을 뿌려야 한다. 인원이 두 배가 되면 비용은 네 배가 된다.
이건 서버 성능의 문제가 아니라 산수의 문제다. 아무리 좋은 서버를 사와도 이 산수는 이길 수 없다.
그래서 MMORPG의 독재자는 통치 방식을 바꿨다. 두 가지 분할 통치다.
- 존(Zone) 분할: 세상을 여러 구역으로 쪼개서 각 구역을 따로 관리한다. 마을과 사냥터를 오갈 때 나오던 로딩 화면, 같은 사냥터인데 '1채널', '2채널'로 나뉘어 있던 것, 서버 선택 화면에서 고르던 '데포로쥬'나 '켄라우헬' 같은 서버들. 전부 독재자가 한 번에 감당할 수 있는 인원을 나누기 위한 장치였다.
- 관심 영역(AOI, Area of Interest): 같은 구역 안에서도, 내 주변 일정 범위 안에 있는 대상의 소식만 받는다. 마을 반대편 끝에 있는 사람이 뭘 하는지는 내게 알려줄 필요가 없다. 내 시야 밖의 세상은, 적어도 내 클라이언트에게는 존재하지 않는 것으로 취급한다.
아무리 존이나 AOI로 대상을 줄여도, MMORPG 서버는 여전히 매 틱마다 많은 대상을 처리해야만 한다.
리니지의 스킬 구성이 상대적으로 단순한 이유도 당시 시대상이 있었겠지만, 서버가 복잡한 공격·피격 연산을 감당할 깜냥이 안 됐던 게 컸을 것이다. 무엇보다 리니지가 한창 성장하던 시기의 서버는 지금 스마트폰보다 연산력이 떨어졌다. 그러니 틱레이트를 가능한 데까지 낮추고 공격 판정도 단순하게 가져갈 수밖에 없었을 것이다. 내가 NC 개발진이 아니라 팩트는 아닐 수 있겠지만, 시대상이 그랬다.
나는 실제로 Photon Fusion과 FishNet 위에서 MMORPG 서버를 만들어본 적이 있다. 그래서 "이런 넷코드 라이브러리로 리니지의 개떼 공성전을 만들 수 있냐"고 묻는다면, 내 대답은 이렇다.
"가능하다, 다만 꽤 많이 비싸다."
이유는 범용성이다. 이런 라이브러리들은 FPS와 MMORPG를 모두 소화해야 하기 때문에, 가장 까다로운 장르의 요구사항을 기본값으로 깔고 간다. 네트워크 오브젝트 하나하나가 틱마다 상태를 기록하고, 예측과 재시뮬레이션을 위한 이력을 들고 다닌다. 10명짜리 FPS 한 판에서는 아무렇지 않은 비용이지만, 수백 명이 한 화면에 몰리는 공성전에서는 그 비용이 머릿수만큼 곱해진다.
캐릭터 컨트롤러(KCC, Kinematic Character Controller)가 대표적이다. 경사로, 계단, 벽 미끄러짐, 점프, 넉백까지 어떤 장르든 받아줄 수 있게 만든 다목적 컨트롤러라서, 캐릭터 하나가 움직일 때마다 돌아가는 충돌 검사와 보정 연산이 제법 무겁다. 예측까지 켜면 클라이언트는 서버의 정정 보도가 올 때마다 그 연산을 여러 틱 분량 다시 돌린다. 내가 만들려던 게임에는 필요 없는 기능들의 값을, 수백 명분 치르고 있는 셈이었다.
범용 엔진은 "무엇이든 만들 수 있다"는 대가로, 무엇을 만들든 일정한 무게를 짊어지게 한다. 어쩌면 MMORPG에 필요한 건 모든 걸 할 수 있는 독재자가 아니라, 해야 할 일만 하는 독재자일지도 모른다.
대규모 공성전에서 사람이 몰리면 캐릭터가 뒤늦게 '뿅' 하고 나타나거나, 투명한 적에게 맞던 경험이 있을 것이다. AOI 처리가 밀리거나 서버가 소식을 다 못 뿌려서 생기는 현상이다. MMORPG 서버 아키텍처의 실력은 결국 이 세상을 얼마나 잘 쪼개느냐에서 갈린다고 해도 과언이 아니다.
6. 스피드핵 튕김: 독재자의 검문소
클라이언트 예측은 렉을 감춰줬지만, 동시에 문을 하나 열어줬다. 클라이언트가 먼저 움직이고 나중에 서버에 보고하는 구조라면, 클라이언트가 보고를 조작하면 어떻게 될까?
리니지 시절의 스피드핵, 흔히 가속기라고 부르던 걸 기억하는 사람이 많을 것이다. PC의 시간 흐름 자체를 빠르게 조작해서 이동과 공격 속도를 끌어올리는 프로그램이었다. 클라이언트는 "나 1초에 이만큼 움직였어"라고 성실하게 보고하지만, 사실 그 1초는 조작된 1초다.
유명한 게임은 아니었지만, 내가 하던 영웅문이라는 게임에서는 PC방 모니터 옆에 이상한 버튼 같은 게 붙어 있었다. 그걸 연타하면 캐릭터가 실제로 빨리 갔다. 나중에 개발을 배우고 나서야 짐작이 갔다. 아마 입력을 빠르게 반복해주는 매크로 장치였을 것이고, 서버가 이동 패킷의 간격을 검증하지 않았으니 보내는 족족 이동이 인정됐던 것이다.
그리고 다들 기억하듯, 스피드핵을 쓰면 튕겼다. 이게 바로 독재자의 검문소다. 서버는 클라이언트가 보낸 입력의 '결과'만 보는 게 아니라, 입력이 들어오는 간격과 시간까지 검증한다. "이 캐릭터의 이동 속도로는 0.5초 만에 이 거리를 올 수 없다", "이 입력은 너무 촘촘하게 들어왔다"라고 판단하면 가차 없이 연결을 끊어버린다.
이것이 서버 권위 구조의 진짜 위력이다. 독재자는 느리지만, 적어도 자기 장부 안에서 일어나는 일에 대해서는 거짓말을 허락하지 않는다. 좌표와 시간에 관한 한, 클라이언트는 독재자를 속일 수 없다.
그런데 여기서 질문이 하나 남는다. 독재자의 장부 밖에서 벌어지는 거짓말은? 서버에 정상 입력처럼 보이는 자동 사냥 매크로, 서버가 보내준 정보를 몰래 들여다보는 월핵 같은 것들 말이다. 이건 독재자가 아무리 장부를 꼼꼼히 봐도 잡아낼 수가 없다. 이 이야기는 다음 편의 핵심 주제다.
7. 그리고 독재자도 쓰러진다
정리해보자. 독재자는 느렸다. 그래서 개발자들은 거짓말을 쌓아 올렸다.
- 내 캐릭터는 예측으로 미래를 산다.
- 남의 캐릭터는 보간으로 과거를 산다.
- 판정은 랙 보상으로 과거를 되감아 내린다.
- 너무 많은 백성은 존과 AOI로 쪼개서 다스린다.
- 장부를 속이는 자는 검문으로 쫓아낸다.
우리가 '렉'이라고 뭉뚱그려 부르던 현상들, 틱 컨트롤, 고무줄, 순간이동하는 유저, 벽 뒤에서의 억울한 죽음, 스피드핵 튕김. 이것들은 전부 이 거짓말들이 삐걱대는 소리였다.
그런데 이 모든 정교한 통치술에도 불구하고, 독재 체제에는 아직 해결하지 못한 근본적인 약점이 남아 있다.
15편에서 락스텝의 공포는 "Waiting for player..."였다. 한 명이 끊기면 모두가 멈췄다. 그렇다면 데디케이티드 서버의 공포는 무엇일까. MMORPG를 해본 사람이라면 다들 알고 있다.
"서버와의 연결이 끊어졌습니다."
그리고 몇 시간 뒤 올라오는 공지사항. "○월 ○일 ○시 ○분 기준으로 롤백됩니다." 어렵게 얻은 아이템이 공중분해되던 그 순간의 허탈함.
독재자는 모든 진실을 독점한다. 그 말은, 독재자가 쓰러지면 진실도 함께 사라진다는 뜻이다. 락스텝은 한 명의 배신에 무너졌고, 데디케이티드 서버는 단 한 대의 죽음에 세계가 멈춘다.
다음 편에서는 이 독재 체제가 지금 어디까지 와 있는지를 다룬다. 128틱이라는 군비 경쟁, 독재자가 끝내 잡지 못한 핵들과 우리 PC에 강제로 설치되는 보안 프로그램, 그리고 그 모든 비용의 청구서가 결국 어디로 향하고 있는지에 대해서.
참고 자료
- John Carmack, QuakeWorld development notes (.plan, 1996): the origin of client-side prediction
- Gabriel Gambetta, "Fast-Paced Multiplayer" series: prediction, reconciliation, interpolation, and lag compensation explained (gabrielgambetta.com)
- Valve Developer Community, "Source Multiplayer Networking"
- Yahn Bernier, "Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization" (GDC 2001)
- Glenn Fiedler, "Snapshot Interpolation" and "State Synchronization" (Gaffer On Games)
- Riot Games, "VALORANT's 128-Tick Servers" (2020)