원래는 온전한 네트워크 게임을 만드는 것이 목표였지만 각자의 취업준비로 인해 로그인 및 데이터 송수신 정도만을 구현한 채 종료되었다.
2주간 서버사이드와 같이 개발을 하면서 배우고 느낀 것들을 하나씩 정리해보았다.
새로 학습한 부분
웹서버 연결
UnityWebRequest와Coroutine을 이용한 비동기 웹서버 연결- 델리게이트를 사용한 이벤트 실행
프로퍼티의 이벤트 바인딩
C# Property에 델리게이트를 이용해 프로퍼티의 값이Get혹은Set될 때마다 이벤트 실행
아쉬웠던 부분
데이터 정의 및 사용
클라이언트 입장에서 서버를 연결할 때와 연결하지 않을 때의 가장 큰 차이점은 데이터의 주도권이라 생각한다.
클라이언트에서 원하는 구조로 저장할 수 있는 클라이언트 베이스 게임과 달리 서버 베이스 게임은 서버의 DB에서 처리할 수 있는 구조를 바탕으로 데이터의 구조를 작성하게 된다.
이로 인해 아무래도 서버에서 먼저 데이터 처리에 관한 이야기가 먼저 나오고, 클라이언트에서는 이를 바탕으로 프론트엔드를 작업하게 되었다.
평소에 파일로 저장해서 자유롭게 끌어쓰던 것과 달리 서버에서 요청을 해야 하기 때문에 데이터의 저장 기법이 조금 달라지게 된다. 해당 프로젝트에서는 DontDestroyOnLoad와 싱글턴 조합을 이용해 모든 씬에서 데이터를 갖고 있을 수 있게 하였고, 메일의 경우에는 유저 인터페이스의 상호작용으로 변화되는 값 중 일부분을 서버에 전송함과 동시에 클라이언트에서 자체적으로 변경하기도 하였다.
지금 생각해보면 서버에게 무언가를 요청할 때 필요한 최소한의 정보(로그인 토큰, ID 등)을 제외하고는 씬이 전환되든, 버튼을 누르든 인터페이스가 변화되는 시점에 그 인터페이스에게 필요한 모든 정보를 서버에 요청하는 것이 가장 올바른 방법이라는 생각이 든다.
내가 사용한 방법은 클라이언트에 데이터를 저장하므로 데이터 탈취 및 위변조의 위험이 있었고, 인터페이스 변경 로직이 잘못되었을 시 서버에 저장된 값과 클라이언트에 표시되는 정보가 다르다는 위험 요소가 존재했다.
혹은 패킷 구조체를 다변화해서 특정 상황에 대한 패킷들을 많이 만들어놓는 것도 방법이 될 수 있을 것 같다. 서버분께서 말씀하시길 정보를 제공하는 것은 SQL 트랜잭션으로 간단하게 원하는 것만 제공할 수 있다고 하셨었으니 이것도 잘 합의할 수 있으면 좋은 방법이 될 것 같다.
결론적으로 서버의 부하를 우려하여 값의 초기화 및 수정 시에만 서버와 통신을 했지만, 안정성을 위해서 값을 사용할 때에도 실시간으로 서버에 요청하는 것이 더 낫겠다는 판단을 하였다.
과도한 싱글턴 사용
위에서 이어지는 문제인데, 네트워크 모듈과 데이터 모듈을 싱글턴과 DontDestroyOnLoad를 사용함으로써 데이터 남용 및 전지적 클래스의 가능성을 열어두었다.
추후 개발 시에는 중요 클래스들을 각 씬마다 따로 배치한 후, 씬이 로드될 때 그 클래스들이 새로 서버와 통신을 해 값을 불러오게 하는 등 수명 관리와 권한 관리 면에서 신경써야겠다.
서버와 클라이언트의 진도 차이
서버가 바쁜 시간과 클라이언트가 바쁜 시간이 따로 있다. 또 서버와 클라이언트가 합동 테스트를 할 때 어느 한 쪽에서 버그나 오류를 발견하면 이를 해결하면서 일처리에 병목이 생기게 된다.
이는 사실 서버와 클라이언트가 각각 테스트용 클라이언트, 테스트용 서버를 제작하거나 받으면 편한 부분이기도 하다. 이런 걸 구하기 어렵다면 상황을 빠르게 파악하고 이를 태스크 리스트에 넣어 따로 처리하는 방법으로 최적화할 수 있기는 한다.
프로젝트 도중에는 매일 정기적으로 세 시간씩 디스코드로 의견 교류를 하였기 때문에 실시간으로 의사소통을 하며 장애를 극복할 수 있었지만, 절차를 챙겨야 하는 회사에 가게 되는 것을 대비하여 클라이언트 내에 데이터리스트 등으로 모의 서버를 만들어 테스트하는 방식 또한 학습이 필요하다
느낀 점
2주의 짦은 시간동안 꽤 많은 것을 배울 수 있어 좋은 시간이었다. 각자의 사정으로 인해 조기에 종료되었지만 다음에 기회가 된다면 만들던 게임 로직까지 완성할 수 있으면 좋겠다.
서버 만드시느라 고생하신 Gyeon님께 감사하다.
