서버는 당근 서버 개발자가 만든다고 생각하는데 이게 그렇게 쉽게 구분되어서는 안된다.
클라이언트가 서버를 만드는 경우 상당히 많다. 그럼 클라이언트가 서버를 만든다는 의미는 무엇일까?

고전적인 개발 그룹에서는 클라이언트팀과 서버팀으로 나눠진다. 서버팀은 DB와 소켓 I/O, 그리고 패킷 라이브러리를 만든다.
클라이언트팀에서 짬밥이 좀 되거나 UI보다 로직 파트를 맡은 사람이 서버팀과 협업을 하여 패킷을 짜맞춘다.
그래서 이런 고전 모델에서 가장 자주 듣게 되는 대화는 이거다.

"여기 이렇게 보냈는데 잘가?"
"브로드캐스팅 할테니 다 가는지 잘봐~~"
"얼래? 왜 안오지?"
등등등, 주로 패킷 송수신 이야기가 대부분을 이루며 생산성은 당연히 떨어진다.

열받은 클라이언트 개발자가 서버 개발자를 공격하는 모습

열받은 클라이언트 개발자가 서버 개발자를 공격하는 모습

그리하여 그룹마다 다르겠지만 좀 연륜이 쌓인 그룹이라면 단순한 클라이언트/서버 구조가 아닌, 클라이언트 엔진/서버 플랫폼/컨텐츠 개발의 3가지 이상의 파트로 나눠지게 된다.

결론적으로 클라이언트 엔진 파트는 게임 내용과 기획을 120%까지는 몰라도 된다. 걍 함수만 조낸 만드는거다. 이펙트건 애니메이션 보간이건 그냥 함수만 호출하도록 만들어 주신다. 서버 플랫폼은 굳건한 소켓 I/O와 빠른 DB처리, 그리고 패킷 루틴을 처리해줄 인터페이스를 만든다.

그럼 컨텐츠는 말 그대로 게임 안의 컨텐츠를 만들게 된다. 눈에 보이는 UI는 물론이고 컨텐츠의 모든 것을 다 만든다. 인원도 제일 많다. 서버와의 필요한 패킷 송수신 루틴도 당연히 컨텐츠 개발자가 만들게 된다. 클라이언트 측은 물론이고 서버에서 처리할 루틴도 이 컨텐츠 개발자가 만들게 된다.

모두에게 사랑받는 컨텐츠 개발자의 모습

모두에게 사랑받는 컨텐츠 개발자의 모습

컨텐츠 개발자는 사실 다이렉트X 따윈 잘 몰라도 된다. 엔진 개발자가 다 만들어주니까 그거만 호출하면 된다. 소켓 역시 마찬가지다. 최소한 recv() 부분은 서버 플랫폼팀에서 클라이언트쪽을 만들어주고 패킷 처리기까지 서비스해줘야 한다.
recv() 받고 패킷 추출까지 끝나면 그떄부터 컨텐츠 개발자의 역활이다. 서버 역시 I/O와 패킷 처리 부분이 분리되어 있다. 서버 패킷 처리 부분은 컨텐츠 개발자가 로컬에서 DLL 만들듯 함수 추가해가며 꾸역꾸역 만들기만 하면 된다.

이렇게 만들어진 서버 패킷 처리 바이너리를 서버에 획 복사해넣으면 서버는 우아하게(와~ 내가 이 표현을 쓰다니!) 작동된다.

자, 그럼 방금의 두번째 그룹에서 서버는 누가 만들었는가?
I/O 와 DB 처리는 분명 서버(플랫폼)에서 만들었다. 그렇다면 컨텐츠라 할수 있는 서버의 패킷 처리와 서버에 존재할 로직은 클라이언트가 만든 것이다. 다시 말해 클라이언트가 서버(의 컨텐츠 부분)를 만든 셈이다.

누구나 아는대로 컨텐츠와 프로그램의 분리는 중요하다. 따라서 그와 함께 인력도 그에 맞게 맞추는 것이 좋다.
(아직도 "서버.EXE" 하나로 작동되는 MMO급 게임들이 알게 모르게 존재하는데 업데이트 할때마다 라이브 개발자는 죽을 맛일 꺼라 생각든다.)

오래전부터 이렇게 세팅된 그룹도 있고 여전히 2개의 구분법으로 조직되고 운영되는 그룹도 많다.
그러나 생산성과 유지보수를 생각한다면 개발팀은 최소 3개의 구분을 두는 것이 좋고 컨텐츠 개발자에게 서버 컨텐츠를 맡겨야 한다. 물론 이를 위해서는 굳건하고 안전한 서버 플랫폼이 필수적이다.

클라이언트가 서버를 만든다는 말을 잘 이해하지 못하는 분들이 많아 주절주절거려 보았지만 아직 이런 체계를 갖추지 않은 그룹이 있다면 심각하게 고려해볼 일이란 생각이 든다.


크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by Rhea君
TAG ,