지스타 2일째인 18일 오후 3시, 벡스코 컨벤션홀에서는 '더 안정적이고 빠른 게임서버 개발 방법' 이라는 제목으로 넷텐션 배현직 CTO의 강연이 진행됐다. 

이번 강의는 코로나로 인해 지스타 방문객이 상당 수 줄어들었음에도 불구하고 준비된 자리가 모두 찰 정도로 많은 주목을 받았다. 

배 CTO는 서두에서 '프로그래머가 아닌 분들에게 초점을 맞추어 강연을 진행한다' 고 밝혔고, 실제로 강연의 내용 역시 비 프로그래머인 기자도 어렵지 않게 이해가 가능하도록 쉬운 설명으로 진행되었다. 

배 CTO는 우선 기본적인 이해를 돕기 위해 일반적인 서버 아키텍쳐를 소개했다. 이와 함께 모바일 RPG, 그리고 보다 복잡한 멀티플레이 온라인 게임의 서버 구조를 설명하며 게임 서버가 어떠한 역할을 하며 어떤 식으로 데이터가 흘러가는지를 설명했다. 

이후 서비스 오픈 중 발생하는 서버 문제들을 소개하는 시간을 가졌다. 가장 큰 문제로 서버 크래시를 꼽았는데, 클라이언트에서 서버와 연결이 끊어졌다고 메시지를 보내는 경우, 서버가 죽어 버리는 상황으로 상황에 비해 쉽게 문제 체크가 가능하다고 설명했다.

다음은 서버 응답 안함 현상이다. 서버는 죽지 않았지만 서버가 클라이언트의 요청을 들어주지 않는 경우로, 이는 서버 처리량보다 클라이언트 요청이 훨신 많을때 많이 발생하고 순간적으로 요청이 많이 몰리는 경우에도 발생한다. 서버 크래시보다는 해결 요구도가 높은 편이라고 언급했다.

세번째는 게임을 하면서 많이 겪게 되는 서버 랙 현상이다. 서버에서 처리량이 많거나 적거나를 반복하게 되고 이러한 상황이 심해지면 서버 응답 안함 현상으로 바뀌게 된다. 클라이언트와 서버 간에 거리가 멀면 시간 차이가 생기게 되는데 이러한 경우에도 서버 랙 현상이 발생한다고 설명했다. 다른 조건보다 시급함은 덜 한 경우라고 언급했다. 

서버 오동작 문제는 서버가 죽지 않았으나 결과가 이상하게 나오거나 오동작을 일으키는 경우다. 이 경우 백 섭이 필요하기도 하고 아이템 복사와 같은 상황이 발생하기도 한다. 이로 인해 로그 추적 등 여러 조치가 필요해지는 문제인데, 서버 오동작은 서버 개발자의 실수에 의해 발생하며 서버를 수평 확장했을 경우 이런 일이 많이 발생한다고 소개했다. 

마지막 문제는 해킹이다. 해킹을 막기 위해서는 모든 정보를 서버에서 관리해야 하는데, 이 경우 서버의 과부하가 심해지기 때문에 어느 정도는 포기하고 클라이언트에 맡기게 되는데 이로 인해 해킹이 가능해진다고 설명했다. 이러한 해킹의 대표적인 것이 에임핵인데 이를 서버에서 막을 경우 처리량이 엄청나게 상승하다보니 에임핵과 같은 요소들은 별도의 프로그램을 통해 걸러 내는 방식으로 처리한다고 언급했다. 디도스 공격과 같은 것들은 서버의 장비빨에 의해 좌우된다는 말도 곁들였다. 

이처럼 대표적인 서버 문제들을 설명한 후에는 서버 문제가 개발일정에 문제를 주는 이유에 대해 소개하는 시간을 가졌다. 

통상적으로 서버 테스트를 위해서는 수많은 과부하를 걸거나 다양한 상황을 시험해 봐야 하는데, 사내 테스트로는 한계가 있는 만큼 다수의 봇을 만들어 테스트를 해 본다고 설명했다. 하지만 봇은 사람처럼 창의적인 테스트가 불가능하고 기상천외한 상황을 만드는 일이 어렵기 때문에 나중에 문제가 발생하게 될 수밖에 없다고 언급하며 유저들은 다양한 꼼수 플레이를 시도하는데, 이를 예방하기 위한 충분한 서버 테스트가 불가능하고, 이러한 부분이 개발 일정 지연에 한 몫을 한다고 소개했다. 

또한, 클라이언트 버그가 발생하는 경우에는 개인에게만 해당이 되지만, 서버 버그시에는 다수의 플레이어에게 영향을 주기 때문에 더 크리티컬한 문제가 되는 만큼 보다 신중한 개발이 필요하다고 강조했다. 

여기에 클라이언트 버그의 경우 직접적으로 화면에 표시되는 등 발견이 쉬운 편이고 에러가 되면 클라이언트가 정지되지만 해당 클라이언트만 해당될 뿐이고 다른 수많은 클라이언트는 정상 동작한다. 그에 반해 서버는 화면에 에러 상황을 보여주는 구조가 아니다 보니 서버 개발자들의 경우 모니터링 툴 등을 이용해 검사를 한다고 언급했다. 

그러한 만큼 디버거처럼 강력하게 서버 상태를 확인하기 어려운 단점이 있는데, 만약 서버에 디버거를 붙이면 서버는 무응답 상태가 되기 때문에 일반적인 상황에서는 사용이 불가능하고 사내에서 개발 중일 때와 같은 상황에서만 사용할 수 있다고 설명했다. 라이브 서버에서는 디버거를 사용할 수 없다는 말이다.

이로 인해 서버 개발자들은 서버에서 사건들을 기록하고 서버에서 오동작 발생시 로그를 살펴보는 방식으로 진행하게 되는데, 디버거보다는 부족하지만 서버 개발자에게는 나름 최선의 방법이라고 소개하기도 했다.  

서버 문제를 줄이는 방법으로는 서버 설계 시 게임과 관련된 각종 수치 등을 직관적으로 자세히 정리해 서버 팀에 공유하는 것을 추천했다. 또한 개발을 진행함에 따라 불가피하게 수평 확장 서버 설계가 나오게 되는데, 기획 내용을 서버팀에 정확히 전달하고 이를 토대로 서버팀이 수평 확장을 하는 형태를 추천했다. 커뮤니케이션의 중요성을 언급한 부분이다. 

추가로 서버 팀에게 빠르게 문제 추적이 가능한 스킬이나 방법을 가지고 있는지를 체크하는 것도 필요하다고 강조했다. 이를 통해 서버팀에게 유지 보수 및 문제 발생 시 이를 감당할 수 있는 스킬을 준비하도록 유도시키는 방법인 셈이다. 

마지막으로 배 CTO는 자사가 개발했던 프라우드넷에 관한 이야기로 끝을 맺었다. 서버에는 디버그 툴을 붙이기 어렵지만 프라우드넷이라면 디버그 트레이스를 작동시켜 로그를 디버그 수준으로 상세하게 제공할 수 있다거나 서버 메모리 상태를 디버거에 준하는 수준으로 표시할 수 있는 등 프라우드넷의 장점을 상세히 소개했다. 또한 현재 개발중인 프라우드넷 2에 대한 소개도 병행됐다. 

프라우드넷을 사용하면 서버 부하 모니터링이 가능하고 크래시 리포트 기능이 있으며, 서버를 다운시키지 않고 바로 패치가 가능한 점, 그리고 전체 코딩의 상당 부분을 자동화하여 서버의 부하를 줄일 수 있다. 

실제로 프라우드넷은 많은 게임 제작사들이 사용하고 있으며, 현재도 적지 않은 업체에서 라이센스를 사용하고 있는 프로그램이다. 특히 인디 게임 제작사 등 소규모 개발사에는 무상으로 제공하고 있는 등 긍정적인 부분도 존재하고 있다.

김은태 / desk@gameshot.net