근래엔 Code 생성을 적극적으로 활용하고 있다. 반복 작업 최소화, 실수 방지 측면에서 효율적이라 생각한다. 그 부분들에 대해 소개하려 한다. MessagePack Code Generation MessagePack은 AOT Code Generation을 지원한다. Unity에서 MessagePack을 사용하기 때문에 AOT로 직접 생성된 Formatter를 사용한 결과가 더 좋기 때문에 AOT Code Generation을 사용한다. (mobile platform에선 il emit을 허용하지 않음 Unity documentation) 측정 결과가 다른 것을 경험하고 server에도 AOT 생성된 Formatter를 사용하는데.. 정확한 결과 비교는 해봐야 알 듯. 기억에 남는건 기본 MessagePack 의 Serialize 결과와 AOT Generated Formatter를 사용했을 때 결과가 달랐다....
세번째 포스트는 프로젝트에서 사용중인 Library와 Package들에 대해 소개하려 한다. MessagePack GitHub 프로젝트 시작시 Serialization Library를 어떤 것을 사용할지 꽤 고민했었다. 이전 프로젝트에선 client <-> server 통신시 Protobuf를 사용했었는데, 이게 꽤나 불편했었다. -_- IDL을 수정하고, Compile하고, Compile된 결과물을 각각 project에 복사하고. (자동화 스크립트가 있다고 하더라도 꽤나 귀찮았다.) 이번 프로젝트에선 모든 Language를 C#으로 통일했기에, IDL을 사용할 필요가 없어져서 Protobuf은 후보 선상에서 제외. 또한 output에 meta-data 없이 payload 만 필요하기 때문에, 그 면에서도 MessagePack이 적합하다고 판단했다....
먼저, Repository에 대해. Repository client-dash 유니티 클라이언트 프로젝트 Unity 2019.4x, .Net 4.x data-dash, lib-dash server-dash 로비서버, 매치서버, 인게임 서버등 서비스에 필요한 서버들의 모음 .Net Core 3.x data-dash, lib-dash admin-dash 관리자툴, 유저 및 게임 서비스에 대한 제어 .Net Core 3.x data-dash, lib-dash dummyclient-dash 더미 클라이언트. 인게임 전투, API 요청, 특수한 시나리오등을 수행하는 클라이언트 .Net Core 3.x data-dash, lib-dash etc AWS Lambda 에서 실행되는 MicroService 등 눈치 채신 분들도 있겠지만, data-dash, lib-dash는 Submodule 이다....
이번 프로젝트 리드를 하며 아키텍쳐를 잡을 때 최우선 사항은 생산성 이었다. 대형 프로젝트도 아니고, 소수의 프로그래머가 지속적으로 바뀌는 요구사항과 짧은 일정을 소화하려면 생산성이 가장 중요하다고 생각했다. 유려한 아키텍쳐 및 프로젝트 구성 샐틈없는 강력한 보안의 코드 / 동기화 모델 엄청난 Throughput을 보여주는 고성능 프로그램 을 다 충족시키며 우리 팀의 목적 달성은 현실적으로 어렵다고 판단했다. 결국 선택과 집중이 필요한 부분인데.. 게임 개발 경력이 아직 길진 않지만, 재밌는 게임을 만들기 위해선 수많은 수행 착오를 거쳐야 하고...