게임 서버 프로그래밍 입문 - (1)

게임 서버의 정의

 

우선 목적을 명확이 해야지 서버책 한 권이라도 잘 이겨나갈 수 있을 것이다.

서버가 어떤 프로그램인지 먼저 생각해보자.

 

온라인 게임이라 하면, 다수와 접속해서 즐기는 MMORPG 온라인 게임도 있을 것이고,

디아블로3 처럼 특정 몇 명만 같이 즐기는 게임도 있다.

 

이런 프로그램들을 만들고 관리하는 서버 프로그래머들은 어떤 일을 할까?

 

신규 게임이라면 당연히 게임 서버를 만들지 않을까?

 

기획자들이 이것저것 새로운 게임에 대한 콘텐츠 기획을 제안할 것이고

그것에 맞게 프로그램 구조를 고려해 서버 프로그램을 작성할 것이다.

 

물론 신생회사가 아니거나, 기존 코드가 엉망인 아닌 이상 기존에 안전성을 검증받은

코드를 계승해서 제작하게 될 것이다.

 

요약하면, 이미 돌아올 수 없는 강(가정을 고려한 코딩)을 너무 많이 건넜고

이 진화한 소스를 처음부터 다시 만들자는 것은 즉,

이미 쌓아놓은 노하우를 버리겠다는 뜻이 되어 버리니

이걸 다시 처음부터 구현하기에는 시간과 개발 리소스가 많이 들어가게 된다.

 

어쨌든, 신규 게임이면 서비스하고 있는 타 온라인 게임과 최대한 차별화를 두거나

많은 부분 차용해서 만들 테니(WOW, 디아, 리니지, 던파, 서든 등) 그 게임을 열심히 해보고

시스템 설계를 할 것이다.

 

그럼 그 반대로, 이미 서비스 중인 게임의 유지보수를 하는

서버 프로그래머라는 어떤 일을 할까?

 

이 유지보수를 할 정도면 성공한 온라인 게임이고,

고정 마니아 층이 있어서, 매일 매일 일정 수익이 나온다.

 

그리고 대부분 유저 레벨이 높은 레벨에 포진하기 때문에

신규 유저 보다는 기존 유저들이 질려서 나가는 비율이 높다.

즉 CCU(Concurrent connected User)가 꾸준히 떨어지는데,

신규 유저를 유치하겠다고 낡은 시스템을 갈아엎는 기획이 나오곤 한다.

이런 과한 욕심으로 기존 시스템에 익숙한 고객층이 대량으로 떨어져 나가고,

게임 이미지 벨류가 이미 낡아 신규 유입도 실패하는 경우도 많다.

 

그러므로 거의 콘텐츠 추가 (유행하는 LOL과 같은 게임 넣기),

시스템의 부분 개편 등을 주로 작업하며,

기획자들이 원하는 콘텐츠를 추가하기 위한 기능 추가 작업이 대부분이다.

 

프로그램 입장에서는 기존 코드 위에 개선작업을 해야 하므로

기존 코드를 분석하는 능력과 리펙토링(코드 구조를 좀 더 효율적으로 보기 좋게 개선)을

할 줄 아는 능력이 요구된다.

 

내가 나중에 게임 회사에 입사해서 처음 맡는 프로젝트가

신규 개발팀일지, 라이브 유저 팀일지는 잘 모르겠지만

결국 어느 쪽 길을 선택하든 프로그램 개발을 해야하고 녹녹하지 않은 길이다.

 

물론 공통으로 게임 서버가 어떻게 돌아가는지 내부 움직임을 잘 알고 있어야

서버 프로그래머로서 원활하게 일 할 수 있을 것이다.

이는 클라이언트, 엔진도 서버를 알아두면 좋다는 얘기다.

서로의 소통에 있어서 몰라서 막히는 부분이 없도록

최대한 의사소통을 원활히 할 수 있다는 뜻이 된다.

 

그런 의 cubesat 같은 간단한 온라인 서버 코어를 만들어보고

이들 시스템이 어떻게 유기적으로 연결되고

데이터 처리를 하는지 이해해 보자.

 

 

 

Use Case 다이어그램
 
아래와 같은 상황을 생각해보자.
콘텐츠를 기획하는 기획자가 게임 내 어느 한 장소에서 유튜브 같은 비디오스트리밍을 틀어 놓아
유저들을 모두 함께 시청하는 장소를 게임 내에 구현하고 싶다고 기획을 내놓았다.
 
자, 서버 프로그램은 뭘 해야 할까?
어느 특정맵에 모이는 건 알겠는데 몇 명까지 허용시켜야 할까?
해당 맵에는 아무나 입장이 가능할까?
같은 클럽 원이나 같은 팀원들만 들어가는 장소를 제공해야 할까?
 
이걸 임의로 구현시켜 버리면,
이후 기획자가 내용을 검토 및 테스트를 하면서 
"어? 왜 레벨 50이하는 여기 안오지?" 라던가 "특정 퀘스트를 하고 있으 ㄹ때만 여기 진입해야 하는데요?"
라는 식으로 일을 제대로 안했다고 하면 어떻게 할까?
 
결국 이때부터 추가 구현 작업이 들어가게 되고,
느긋했던 일정은 촉박한 일정으로 변모하여 야근, 주말 출근을 부르게 되고
결국 일정이 무산되게 되는 사태가 비일비재하다.
 
즉 기획자와 개발자 간의 대화 소통에서 나오는 문제이다만,
이는 각기 전문 분야가 다르므로 발생하는 문제로서 이런 소통 문제를 최소화해야 하는 노력이 필요하다.
 
같은 한국어로 이야기하는데 무슨 소릴 하는 거지 라고 생각된다면,
한번 법률 사전을 읽어보길 추천한다.
거기에 있는 같은 한국어가 아닌 것처럼 보일 거다.
 
어쨌든, 자신의 의사가 정확히 표현되지 않으면,
회의해도 소통이 안되고, 서로가 소통이 안 도니다고 생가하게 된다.
그러면 오해가 커져서 팀의 협업 작업도 크게 틀어지게 된다.
 
그래서 서로 간 소통이 되도록 고안해 낸 것이 이 Use Case 다이어그램이다.
전문용어가 배제된 도형으로 무슨 일을 어떻게 할지 쉽게 표현할 수 있다.
 

 
 
 자 그럼 이제 마인드맵을 명세로 작성해보자!

 

서버 프로그램 명세서
-> 목적
 온라인 게임 서버에 맞는 대규모 세션 관리 네트워크 프로그램 작성

-> 흐름
클라이언트 PC로도, 모바이로도 접속이 가능해야 한다.
접속 시 새 세션을 생성하며, 이 세션을 이용해서 캐릭터 선택 등을 한다.
캐릭터를 가지고 어떤 게임 행위를 한다.
해당 데이터는 실시간 혹은 정기적으로 DB에 저장시킨다.
서버에 이상이 있을 시 서버 또는 관리자에게 해당 내용을 보고 하는 시스템이 필요하다.

 

이제 이를 이용해서 서버 프로그램에 대한 Use Case를 그려보자.

 

 

짜잔!

 

현업에서는 기획자나 개발자들이 새 시스템을 만들려고 할 때

이와 같은 다이어그램을 작성하여,

여기선 이렇게 하고 이게 저거에 영향을 주어 돌아간다는 식으로 설명할 수 있으므로,

명세서로 전달하는 것보다 오해가 들어갈 여지를 많이 줄여준다.

 

 

Acivity 다이어그램

 

활동 다이어그램이라 불리는 이 도식 표는 업무, 로직 흐름을 시각적으로 표현해 주는 다이어그램이다.

고등하굑 수학 시간 때 잠시 봤을 수도 있는데,

로직을 간략화한 도식 표라 생각하면 이해하기 편할 것이다.

 

 

도형	의미
	프로세스 시작을 의미한다. 보통 함수 시작을 알린다.
	어떤 행위를 나타낸다. 일종의 로직 처리이다.
	분기이다. C로 보면 if문과 같다.
	프로세스 종료이다. 즉, 함수 스코프 밖으로 나가는 행위이다.
	프로그램 처리 흐름이다.

 

 

어떻게 쓸지 잘 감이 안올 것 같으니, 간단하게 로그인 처리에 대해서 한번 생각해 보자.