팰월드 서버 운영과 라이브 서비스 운영

2024년 가을 현재 지금까지 업데이트 된 어지간한 컨텐츠를 플레이 할 만큼 했다고 생각해 함께 플레이 하던 사람들이 더 이상 팰월드를 이전만큼 적극적으로 플레이 하지는 않게 되었습니다. 주변에 이런 장르 게임을 좋아하는 사람들이 있는데 저는 이 분들이 모여 같은 게임을 편안하게 플레이 할 수 있는 인프라를 구축하는 역할을 맡고 있습니다. 가령 초창기 자바 버전 마인크래프트를 플레이 할 때는 멀티플레이를 안정적으로 하고 싶기는 하지만 서버를 열 마땅한 방법이 없어 AWS에 처음 가입한 계정의 무료 티어 내에서 1년간 무료로 사용할 수 있는 인스턴스에 마인크래프트 클라이언트를 실행해 놓고 그대로 켜 둔 다음 그 서버 아이피를 멀티플레이 하는데 사용하는 것으로 시작합니다. 이런 방식은 데디케이트 서버를 따로 공개하지 않는 게임이라도 아는 사람들과 편안하게 멀티플레이를 하고 싶기는 했던 관계로 이후 여러 게임에 한동안 같은 전략을 사용했습니다. 시간이 지나며 스팀으로 출시되는 그리 규모가 크지 않은 비슷한 장르 게임들이 데이케이트 서버를 함께 배포하면서 서버를 만들기 훨씬 쉬워지면서 같은 게임을 여러 사람들이 플레이 하려고 할 때 겪을 수 있는 기술적 장벽을 거의 없애 주었습니다. 또 여러 게임이 언리얼 기반으로 개발되며 언리얼 데디케이트 서버를 사용하기 시작하면서 데디케이트 서버를 제공하는 게임들이 훨씬 더 늘어났습니다.

언리얼 데디케이트 서버는 이를 기반으로 본격적인 서비스를 제공하는 상용 게임들이 있기는 하지만 2024년 가을 현재 아직까지는 이를 기반으로 게임 서비스를 제공할 결정을 내리기 쉽지 않기는 합니다. 분명 게임 세계를 여러 사람들에 걸쳐 동기화 할 수 있는 나쁘지 않은 방법이기는 하지만 사용자 수애 비해 직접 만든 서버에 비해 훨씬 높은 사양을 요구했고 이는 자칫 온라인 서비스를 제공할수록 손해를 볼 수 있는 위험이 있습니다. 하지만 상황에 따라 핵심 플레이의 동기화는 언리얼 데디케이트 서버를 사용하되 게임 모드 사이, 혹은 레벨과 레벨 사이를 중계하는데는 별도로 개발한 서버를 사용하는 식으로 용도에 맞게 사용자와 기계를 분산 시켜 매출에서 인프라 운영 비용을 적정한 수준으로 유지 시키고 있는 것 같아 보입니다. 한편 직접 온라인 서비스를 제공할 생각이 없더라도 언리얼 데이케이트 서버를 사용해 최소한의 온라인 멀티플레이 기능을 구현한 다음 이를 공개하는 게임들이 늘어나면서 어지간한 게임에는 당연히 온라인 멀티플레이를 기대하는 상황이 되고 말았는데 팰월드 역시 그런 사례입니다. 처음 팰월드를 플레이 해 보고 이런 게임이라면 당연히 작은 규모로 멀티플레이를 하면 재미있겠다는 생각을 했습니다. 이들 역시 당연하다는 듯 데디케이트 서버를 제공했는데 아무래도 온라인 멀티플레이에 기반한 게임플레이를 만들어본 경험이나 요령이 없어서인지 예측 가능한 온갖 문제들이 가득했습니다. 몬스터는 지형 지물에 걸리고 플레이어 간의 동기화는 거의 아슬아슬한 수준으로밖에 처리되지 않았으며 거점이 늘어남에 따라 사용자가 오프라인 상태일 때 시뮬레이션 해야 할 영역이 늘어나 상당히 높은 기계 사양을 요구했습니다. 이 상태로는 본격적인 상용 서비스를 할 수는 없어 보입니다.

하지만 이 게임을 그저 몇 명이 모여 조용히 플레이 할 생각인 우리들에게 이런 동작은 단점 축에 끼지도 못합니다. 고사양을 요구하면 좀 천천히 플레이 하면 되고 몬스터가 지형에 걸려 멍청하게 움직이는 것은 이 몬스터를 거의 공짜로 잡을 기회이기 때문입니다. 너무 쉽게 예상 가능한 시나리오에 의해 어뷰징 가능한 요소들은 우리가 회사에서 이걸 본격적인 온라인 멀티플레이 게임으로 개발하고 있었다면 정말 심각한 문제이겠지만 우리들끼리 플레이 할 때는 알고 있지만 귀찮아서 안 하는 수준의 없는 것이나 다름 없는 문제에 불과했습니다. 그래서 이번에도 다른 여러 게임들과 마찬가지로 제가 항상 켜져 있는 기계에 팰월드 데디케이트 서버를 구동해 놓기로 했는데 마지막으로 제가 게임 서버를 만들었을 때는 스팀 기반으로 배포되는 서버 프로그램을 설치하고 구동하기 위해 서버에 윈도우 기반 스팀 클라이언트를 설치하고 이에 기반해 서버 프로그램을 실행했었습니다. 하지만 오랜만에 똑같이 행동하려다가 곰곰이 생각해보니 이번에는 굳이 윈도우 기계를 서버로 만들 필요 없이 장기적으로 비용을 낮추기 위한 온프레미스 전환에 소개한 맥미니를 게임 서버로 사용할 수 있지 않을까 싶은 생각이 들었습니다. 사실 팰월드 서버는 맥미니의 사양보다 훨씬 높은 사양을 요구했지만 일단 한번 돌려 보고 할만 하다 싶으면 유지, 도저히 안되겠다 싶으면 윈도우 기계를 사용할 생각으로 일단 맥미니에 팰월드 서버를 올려보기로 합니다. 하지만 이 계획은 이전과 똑같이 맥에 스팀 클라이언트를 설치하고 스팀 기반으로 제공되는 데디케이트 서버가 윈도우 전용이라는 사실을 깨달으면서 바로 취소됩니다.

그렇게 포기하려다가 혹시나 해서 검색해보니 재미있게도 누군가가 리눅스용으로 배포된 팰월드 데디케이트 서버를 예쁘게 컨테이너로 묶어 배포하고 있다는 것을 알게 되었습니다. 이미 맥미니에서는 개인용 퍼포스 사용기 및 영업에 소개한 퍼포스 서버 뿐 아니라 여러 가지 웹 서비스, 자동화 서비스, 데이터베이스 따위가 도커 기반으로 돌고 있었기에 똑같은 모양으로 구동할 수 있으면 정말 편할 것 같았습니다. 컨테이너를 받은 다음 순식간에 설정을 마치고 서버를 열었고 팰월드 데디케이트 서버는 맥에서 동작하는 리눅스 VM 위에서 아이들 상태일 때 최대 800%의 CPU 사용량 중 약 200%를 소모하며 구동 되기 시작합니다. 요구 사양에 비해 어처구니 없이 적은 램이 걱정거리였는데 이 서버에서 플레이 하기를 원하는 모든 사람들이 동시에 접속했지만 램이 부족해서 뭔가 문제가 발생하지는 않습니다. 다만 서버를 오랫동안 띄워 두면 반응이 점점 느려지는 문제가 있어 일정 시간마다 서버가 재시작 되도록 설정해야만 했고 이 정도 조치 말고는 M1 맥미니에서 도커를 통해 팰월드 서버를 실행하고 한 자리 수 플레이어들이 동시에 플레이하는데 별 지장이 없었습니다. 사실 윈도우에 띄울 서버는 훨씬 더 고사양을 요구했고 플레이어 한 명이 추가될 때마다 훨씬 많은 메모리를 요구한 것이 사실입니다. 이전에 언리얼 데이케이트 서버 기반으로 개발할 때에도 테스트 서버를 상시 AWS에 띄우기 어려울 정도로 비용이 높아 분명 문제가 생길 거라고 예상했는데 의외로 적은 사용자 수준에서는 맥미니 정도 사양으로도 적당히 커버되는데 놀랐습니다.

한편 팰월드 서버는 세계의 여러 가지 규칙을 설정할 수 있습니다. 일단 서버를 띄워 플레이가 가능해진 다음 시간이 지나자 고객들은 서버 설정 변경을 요구합니다. 저는 이 게임을 개발한 사람이 아니기 때문에 버그를 수정하거나 근본적인 규칙을 고칠 수는 없었지만 팰월드 개발자들이 서버마다 바꿀 수 있도록 해 놓은 설정들을 수정한 다음 서버를 재시작 해 우리들이 함께 플레이 하는 서버의 규칙을 아주 조금씩 수정할 수는 있었습니다. 고객들이 맨 처음 요구한 것은 낮과 밤의 길이를 조절해 달라는 것입니다. 밤에 일어나는 플레이가 의미 있기는 하지만 준비가 잘 안 된 상태일 때 밤을 맞으면 쉽게 곤경에 처하거나 아무것도 못 하고 밤이 지나가기를 기다려야만 할 수도 있습니다. 사실 이런 결과는 낮과 밤 구분을 넣은 개발자들이 의도한 플레이일 것이 분명하고 이를 위해 각 고객들은 밤이 찾아오기 전에 밤에 대비한 준비를 하는 것이 당연한 플레이입니다. 하지만 고객들은 밤을 썩 좋아하지 않았습니다. 그렇다고 밤이 아예 없으면 플레이가 불가능해지는 부분도 있어 낮보다 밤이 훨씬 더 빨리 지나가도록 설정합니다. 고객들은 만약 준비가 덜 된 상태로 밤을 맞이하더라도 이전에 비해 밤이 더 빨리 지나갔기 때문에 밤을 덜 귀찮아 하게 됐고 또 밤을 위한 준비를 덜 해도 됐기 때문에 대체로 만족했습니다. 고맙게도 팰월드는 낮에 시간이 흐르는 속도와 밤에 시간이 흐르는 속도 비율을 따로 조절할 수 있게 만들어 놓아 쉽게 해결할 수 있습니다.

나중에 게임을 시작한 고객들은 플레이어와 몬스터 사이의 대미지 비율을 조정해 전투를 더 쉽게 만들기를 원했습니다. 팰월드 서버는 몬스터가 플레이어에게, 플레이어가 몬스터에게 주는 대미지 배율을 각각 조절할 수 있게 되어 있어 이를 조정하면 플레이어는 상대적으로 강하게, 몬스터는 상대적으로 약하게 만들 수 있습니다. 하지만 이 요구사항은 무지성으로 적용하기 좀 꺼려졌는데 이 설정은 분명 늦게 게임을 시작한 고객들을 편안하게 만들어줄 것이 분명했지만 게임의 수명을 극적으로 줄이는 결과를 가져올 것이 뻔하기 때문입니다. 또한 이미 앞서 게임을 시작한 플레이어들이 상위 컨텐츠를 깨고 다니는 재미를 극적으로 감소 시킬 것 역시 분명하기에 이 요구사항은 받아들이지 않았습니다. 다만 먼저 시작한 고객들을 좀 갈궈서 나중에 시작한 고객들에게 자원과 팰을 충분히 나눠주고 함께 돌아다니며 버스를 태워 달라고 요구했습니다. 다행히 이 요구는 잘 먹혔고 플레이어와 몬스터 사이의 대미지 배율을 조절하는 요구사항을 무시할 수 있었습니다. 사실 라이브 서비스의 라이프사이클을 걱정할 입장이 아니기는 하지만 기왕 오랜만에 사람들이 모였으니 게임이 너무 빨리 소모되어 이 즐거운 경험을 끝내 버리고 싶지 않았습니다.

반면 고객들의 요구를 거절하고 싶었지만 설득할 수 없는 사례도 있었는데 팰들이 배고파지는 속도를 줄여 달라는 요구가 그랬습니다. 서버 설정에는 팰들이 얼마나 빨리 배고파질지를 한 번에 설정하는 숫자를 고칠 수 있었습니다. 팰들을 함께 데리고 다니다 보면 팰들은 배가 고파지고 제때 밥을 먹이지 않으면 필요한 순간에 사용할 수 없게 됩니다. 극초반에는 팰에게 직접 먹이를 줘야 하지만 먹이주머니를 만든 다음에는 여기에 먹을 것을 채워 놓기만 하면 팰들이 알아서 먹이를 먹기 때문에 그리 귀찮지 않습니다. 근본적으로 여러 팰을 데리고 다니며 필요한 순간마다 다른 팰을 소환 시켜 사용하는 플레이를 요구하는 게임에서 각각의 팰이 굶주리지 않도록 수동으로 관리하기를 요구할 리가 없었습니다. 팰들이 배고파지는데 걸리는 속도를 조절하면 분명 팰을 먹일 필요가 없으니 게임이 훨씬 편해지겠지만 이 역시 게임 전체를 볼 때 수명을 단축 시키는 원인으로 작용할 수 있었습니다. 이제 와서 생각하면 게임의 나머지 경제 규모에 비해 이 정도는 그냥 편의를 위해 과감히 0으로 설정해 팰들에게 먹이를 주는 메커닉 자체를 동작하지 않도록 만들어도 딱히 이상하지는 않았겠다는 생각이 들기는 합니다. 그 정도로 팰월드는 초기에 경제시스템이 꽤 엉망으로 만들어져 있어 고객들이 자원을 획득하고 소모함에 따라 게임 수명이 잘 유지되지 않는 모양으로 간신히 동작하는 수준으로만 만들어져 있었습니다. 팰에게 먹이를 주는 메커닉 역시 궁극적으로는 플레이어에게 지속적인 유지 비용을 요구해 한 번에 데리고 다닐 수 있는 팰 수를 제한하려는 목적으로 만들어졌을 것 같지만 먹이주머니가 등장하는 시점에 이 메커닉은 완전히 무력화 됩니다. 하지만 버그로 팰들이 먹이주머니에 있는 먹이를 자동으로 먹지 않고 그냥 쫄쫄 굶다가 빈사상태가 되는 일이 자주 발생하자 게임 수명이고 뭐고 당장 이 메커닉을 무력화 하라는 요구를 거절할 수가 없었습니다.

죽었을 때 패널티는 분명 고객들이 요구할 거라고 예상해 미리 제거했습니다. 팰월드의 사망 패널티는 팰, 장비, 아이템을 모두 드랍하거나 장비, 아이템만 드랍하거나, 아이템만 드랍하도록 단계 별로 조정할 수 있는데 기본 설정은 팰, 장비, 아이템을 모두 드랍하는 것입니다. 죽음에 대한 패널티는 게임을 여러 모로 흥미롭게 만들고 같은 행동을 할 때 다시 한 번 생각하게 만드는 요소이기도 합니다. 죽음이 두렵지 않다면 게임이 제시하는 어지간한 챌린지는 우습게 보이게 되고 이는 게임의 실질적인 재미를 반감 시킵니다. 로그라이크 장르에서 두 번째 기회가 주어진다면 이는 근본적으로 장르를 파괴하는데 장르가 성립하지 않게 되는 이유는 게임이 고객에게 제안하는 여러 챌린지가 더이상 챌린지로 받아들여지지 않기 때문입니다. 만약 엑스컴에서 동료를 잃지 않게 된다면 그들을 충분히 신중하게 행동하게 만들 필요도 없어지고 게임은 의도를 지탱하는 핵심 메커닉이 완전히 붕괴되어 재미를 상실해 버리게 됩니다. 다만 팰월드 같은 장르, 그리고 아는 사람들이 모여 안전하게 플레이 하기를 원하는 상황에서 죽음은 게임 메커닉을 파괴하기에 앞서 사람들의 플레이 의욕과 시간을 파괴하는 요소로 먼저 작용합니다. 다들 다음날 출근해야 하기 때문에 최대한 적은 시간을 투자해 의미 있는 경험을 하기를 원했는데 이런 상황에서 죽음에 의해 소지품을 잃어버리고 이를 다시 주으러 가야 하는 상황은 게임 메커닉의 붕괴를 이야기하기 이전에 시간이 별로 없는 사람들을 극도로 짜증나게 만들 것이 뻔했습니다. 실은 이전에 다른 게임에서도 그랬습니다. 그래서 미리 죽었을 때 패널티를 제거하고 거점에서 부활하도록 설정해 예상되는 고객들의 짜증을 미리 피했습니다.

대신 아군에게 대미지를 주는 옵션은 원래 꺼져 있지만 설정을 바꿔 켜 놨습니다. 이는 불특정 다수가 플레이 하는 환경에서 게임 장르를 순식간에 리니지로 바꿔 버릴 수 있고 장르가 바뀌는 순간 고객들이 모두 떠나 버리는 불상사를 일으킬 수 있는 위험한 옵션입니다. 하지만 아는 사람들만 모여 플레이 하는 환경에서는 이 옵션이 켜져 있으면 의도하지 않은 결과를 통해 웃긴 상황을 만들어낼 수 있음을 알고 있기에 미리 옵션을 켜 놓았습니다. 필드 보스와 전투할 때 무지성으로 공격하다 보면 그 옆에 있던 우리 편에게 거대한 대미지를 줘 거점부터 달려오거나 전투가 끝날 때까지 바닥에 누워 있도록 만들거나 어설프게 이들을 살리려 시도하다가 파티 전원이 사망하는 상황을 만들어내기도 했는데 이 상황이 보스에게 공격을 받아서가 아니라 아군끼리 오인사격으로 일어난 상황이라는 점 때문에 짜증날 법한 상황이 일어났음에도 고객들을 웃길 수 있었습니다. 또한 파티원 사이에 대미지를 줄 수 있으면 이를 활용한 다양한 의사소통을 할 수도 있었기에 앞서 사망 패널티를 제거한 것과는 달리 의도적으로 아군에게 대미지를 줄 수 있게 했고 이는 악의 없이 플레이 하는 사람들 사이에 의도 대로 동작했습니다.

이 정도 설정 변경으로 한동안 다른 요구 없이 플레이를 이어 갑니다. 설정에서 거점을 훨씬 더 많이 만들 수 있게 해 놓은 덕분에 고객들은 각자 자신이 원하는 위치에 제멋대로 거점을 만들어 놓았고 각각의 거점은 누가 만들었는지 굳이 알아볼 필요도 없이 누구의 거점인지 알 수 있을 정도로 각자의 특징을 잘 드러나는 모양으로 만들어집니다. 밤은 조금 더 빨리 흘러가고 팰들은 배고파하지 않게 됩니다. 물론 이 시점에는 팰들을 직접 먹이지 않는 이상 예상하지 않은 시점에 먹이주머니를 무시하고 기아 상태에 빠지곤 했기 때문에 무슨 짓을 하더라도 결국 팰들은 배고파질 운명이었습니다. 아군에게 대미지를 줄 수 있었지만 이는 웃긴 상황을 만들었는데 근본적으로는 죽음에 대한 패널티가 없었기 때문에 아군이 주는 대미지를 재미로 받아들이고 또 의사소통 방식의 하나로 사용할 수 있었던 거라고 생각합니다. 한편 다들 본격적으로 알을 부화시키는데 매달리기 시작하자 거의 동시에 여러 고객들로부터 알 부화 시간을 줄여 달라는 요구를 받았습니다. 알에 따라 부화에 아주 긴 시간이 필요했습니다. 이는 게임의 중반 이후 게임 수명을 유지 시키는 중요한 메커닉입니다. 물론 항상 온라인에 기반한 끝이 없는 게임을 만들던 입장에서 이 정도 장치만으로는 순식간에 컨텐츠가 고갈될 수밖에 없다는 사실을 알고 있었지만 그나마 이거라도 있는 것이 어딘가 싶었습니다. 하지만 고객들은 부화에 걸리는 긴 시간을 납득하지 않았습니다.

알 부화 시간을 극적으로 단축 시키면서 그렇잖아도 컨텐츠 고갈에 딱히 신경 쓰지 않고 만들어졌을 것이 분명한 경제 밸런스는 머지않아 무너질 거라고 예상했습니다. 물론 고객들은 얼마 지나지 않아 그 시점까지 게임이 제공하는 컨텐츠를 전부 다 소모하고 다음번 업데이트를 기약하기는 했습니다. 하지만 모두가 그렇게 컨텐츠 고갈에 따라 게임을 떠나기만 한 것은 아닙니다. 팰월드는 아주 간단한 규칙에 기반해 조립식 건물을 지을 수 있습니다. 이 시스템은 어찌나 단순한지 아무리 정교한 건물을 만들려고 해도 그 한계가 너무나 뚜렷했습니다. 하지만 이런 메커닉에 끌리는 저 자신을 포함한 사람들은 이런 제약 속에서 플레이 하는 것이 너무나 익숙한 사람들이었고 뻔한 문짝과 뻔한 벽에 기반해서도 괴상한 건물을 만들어내는데 시간을 보냅니다. 모험과 성장 측면에서 보면 여러 설정 변경을 통해 컨텐츠가 훨씬 발리 고갈되도록 만들었고 이런 플레이를 주로 하는 고객들은 더 이상 할 일이 없다며 게임을 떠나갔지만 건물을 만드는데 집중하는 사람들은 하늘 위로 계속해서 올라갔고 어째서 땅 속이나 물속으로는 들어갈 수 없는지 아쉬워 했습니다.

지금은 그런 플레이조차 시들해져 더 이상 플레이어가 찾지 않는 도커 컨테이너를 멈춰 놓고 있고 만약 팰월드가 업데이트 된다면 서버를 업데이트 한 다음 다시 열 수도 있고 아니면 또 다른 이런 식으로 플레이 할 수 있는 게임이 나타날 때 까지는 더 이상 게임 서버를 열지 않을 수도 있습니다. 이번에는 이전과 달리 맥미니에 서버를 열어 훨씬 조용하고 훨씬 전기를 덜 먹는 기계 기반으로 서버를 돌릴 수 있어 좋았고 또 클라우드 기반 인프라에 의존하지 않아 비용을 완전히 통제할 수 있었다는 점 역시 좋았습니다. 아무래도 맥미니에 비해 고사양인 윈도우 기계를 24시간 켜 놓으면 시끄럽고 덥고 전기요금도 더 많이 나와 부담이 없지 않았지만 맥미니는 이런 부담이 거의 없었습니다. 심지어 팬도 거의 돌지 않았고 서버는 SSD 위에서 동작하고 있어 아무 소리도 내지 않았습니다. 또 이전과 달리 스팀 기반의 바이너리를 바로 실행하는 대신 도커 기반으로 서버를 실행해 같은 기계를 사용하는 나머지 서비스들과 실행 환경을 완전히 격리할 수 있는 점, 그리고 서버 설정을 바꾸고 재시작하기를 반복할 때 훨씬 편안했고 또 컨테이너 제작자가 컨테이너를 업데이트 하면 너무 편하게 업데이트 받을 수 있는 점도 좋았습니다. 이전에는 윈도우 기반이어서 주로 크롬 리모트 데스크탑을 통해 서버를 제어했는데 이번에는 도커 기반에 ssh를 열어 커맨드라인으로 서버를 제어할 수 있는 점 역시 굉장히 편리했습니다.

팰월드를 다시 플레이 하게 되거나 다른 게임을 플레이 하기 위해 서버를 만들어야 한다면 앞으로도 비슷한 방법을 사용할 수 있으면 좋겠다 싶었고 또 오랜만에 아주 짧은 라이브 서비스 운영을 체험하며 어떤 결정이 사람들을 더 재미있게 만들고 또 어떤 설정이 게임 수명을 갉아먹는지 시험하고 또 직접 체험해볼 수 있는 기회가 되어 마음에 들었습니다.