0x03. 게임 서버 프레임워크와 원칙

프레임워크를 지탱하는 원칙 설계하기

지난 글(조금 오래됬다)에서는 모바일 게임 서버에서 사용되는 피처들을 지탱하는 시스템 컴포넌트들에 대해 간단히 살펴봤다.

컴포넌트는 개발 과정에서 삭제될 수도, 추가될 수도 있고 언제든지 바뀔 수 있다. 최악의 경우는 근본이 흔들릴 수도 있을 것이다. 나는 최악의 상황이 발생하는 일은 막고 싶지만, 한편으로는 이 과정을 통해 초기에 구상한 설계가 개발 진행 과정에서 얼마나 바뀔 수 있는지, 무엇을 배울 수 있는지 궁금하다.

원칙

길고 긴 소프트웨어 개발 여정을 시작할 때 마음 먹은 게 있는데, 이 소프트웨어에 녹일 원칙을 만드는 것이였다. 개발을 끝내기 전까지 고수하는 건 아니지만, 큰 틀에서는 이 원칙들을 지키려고 노력할 것이다.

이 프레임워크는 상용 소프트웨어로써 개발하는 게 아니다. 실제 게임의 요구사항(특히 안전성)을 반영할 것이지만, 최신 기술들을 마구잡이로 사용할 것이고 rust 버전 또한 nightly를 사용하기로 결정했다. 다시 말해 이 프레임워크는 실제 게임을 만들기 위한 목적이라기보다 설계를 검증하는 목적이 더 크다.

라이선스는 MIT를 유지할 것이다. 설계 검증이 목적이고 코드 또한 모두 공개할 것이기 때문에 라이선스에 대해 특별한 생각은 없다.

안전성을 가장 우선시하고, 프레임워크의 사용 편의성을 두 번째로 우선시한다. 성능은 가장 마지막 단계에서 우선시한다.

마이크로 서비스 아키텍처를 고수하고 모놀리씩(Monolithic) 아키텍처를 지양한다.

모든 컴포넌트는 3가지 계층으로 나눈다.

최상위 계층은 피처(Feature) 계층으로, 사용자 스토리와 편의성을 중점으로 설계한다.

중간 계층은 파운데이션(Foundation) 계층으로, 잘못 사용하기 어렵고, 쉽게 사용할 수 있게  설계한다.

마지막 계층은 시스템(System) 계층으로, 안정성과 성능을 최 우선으로 설계한다.

컴포넌트 정리

아쉽지만 아직도 첫 번째 커밋을 하려면 먼 길을 가야할 것 같다. 프로그래밍 언어보다 중요한 것이 설계이기 때문이다.

먼저, 여태까지 생각해놓은 컴포넌트들을 한 곳에 모아봤다.

0x01, 0x02에서 설명한 모든 컴포넌트들

그 다음 해야 할 것은, 계층을 나누는 것이다. 앞서 설명한 원칙에 의거해 3 가지 계층으로 나눴다. 녹색은 최상위 계층, 파란색은 중간 계층, 그리고 갈색은 시스템 계층이다.

계층 별로 구분된 컴포넌트들

계층을 구분하는 기준은 간단하다. 컴포넌트가 어떤 곳과 밀접해 있는지, 컴포넌트가 동작하기 위해 필요한 다른 컴포넌트가 있는지, 이 컴포넌트를 사용하는 대상(나 또는 프레임워크 사용자)이 누구인지 등이 구분하는 데 영향을 준다.

예를 들어 게임 로직 컴포넌트, 업적 컴포넌트는 당연히 프레임워크 사용자가 쓰게 될 것이므로 최상위 계층이 되어야 한다. 그래서 사용자 스토리와 편의성을 중점으로 만들어야 한다.

그렇다면 랭킹, 결제, 인증 컴포넌트는 어떨까? 이 컴포넌트들 또한 프레임워크 사용자가 쓸 것이다. 그래서 인터페이스 일부는 최상위 계층으로 갈 수 있다. 하지만 랭킹, 결제, 인증을 사용하는 행위 자체가 "게임 로직"에 해당하므로 사용자가 쓰는 인터페이스는 게임 로직에 해당할 것이다. 그래서 프레임워크 계층에 두었다.

계층별로 분리한 컴포넌트들

다음 글에서 다룰 것들

다음 글부터는 정말로 Rust 코드를 볼 수 있을 것 같다. Rust 프로젝트를 생성하고, 타입을 정의하면서 Spaces 라이브러리를 이용해 간단한 설정 컴포넌트를 만들 것이다.

다음 글이 언제 나올진 모르겠다. 집필 작업이 올해까지 진행될 가능성이 크기 때문이다. 그래도 올해 안에는 첫 커밋을 올리고 싶다.