Ch.2 -JMAN's Study-온라인 게임 서버 프로그래밍

 

챕터2는 기초 수준의 기능에 대해 설명하고 있다. 역시 둘러볼만한 정도의 내용이라 포스트 하나로 정리 가능할 것 같다. 

 

 

2-1 Stream 클래스

버퍼를 스트림 형태로 입출력하는 방식은 거의 대부분의 도메인에서 활용되는 방식이다. 직렬화, 프로토콜 스택 등 다양한 활용이 가능하겠다. 교재에도 그 중요성을 인식하여 가장 먼저 설명한 것이 아닐까 생각이 들었다. 그런데... 15년 가량 현업을 경험하다보니 버퍼에 내용을 순서대로 채우다가도 예기치 못하게 지나간 자리에 변경을 가해야 하는 일이 발생하는 경우가 항상 존재했다. 컨베이어 벨트처럼 이상적으로 시스템이 동작하면 좋겠지만, SW의 유연성이 역설적으로 이런 문제를 야기하는 것 같다. 그 덕에 사람의 손길이 많이 필요하게 되는 것이고, 우리 IT인들이 밥을 먹고 사는 이유이기도 하겠다.

 

어쨌든 이런저런 이유 때문에 Stream 클래스라고 해도 일반 버퍼처럼 랜덤 액세스도 가능하도록 하거나 stream to stream 즉, stream을 substream으로 잘게 쪼개고 최종 단계에서 mainstream에 합류하게 방법 등 다양한 해법이 필요한 것 같다.

 

 

2-2 Registry 클래스

Windows 특유의 기능인 Registry를 이용하기 위한 래퍼 클래스를 설명하고 있다. OS의 DB 영역에 정보를 저장하기 때문에 안전하기도 하고 동기화 문제도 해결되는 등 장점이 있지만, 모든 정보가 공용공간에 저장이 되므로, 프로그램 삭제 시 cleanup을 직접 해줘야 한다. 그렇지 않으면 garbage registry로 영원히 남게 되는데, 이를 제거할 방법이 없다. 지금이야 registry 크기가 아무리 늘어나도 PC 성능에 영향이 없지만, 오래 전에는 registry의 크기가 PC 성능에 까지 영향을 미치게 되어 OS를 재설치하는 일이 많았다. 스마트폰 같은 경우에는 아예 앱 별로 저장 공간이 있어 서로 간의 간섭이 없고, 앱 삭제 시 완벽하게 정리가 되고 있다. (물론 안드로이드는 조금 예외 사항이 있지만...)

 

때문에 요새는 registry를 아예 안쓰는 PC 앱도 많고, 윈도스토어의 앱 역시 조금 다른 방식으로 관리하는 것으로 안다. 게임 쪽에서는 registry를 적극 사용하는지 경험을 해본 후 다시 포스팅을 해볼까 한다.

 

 

2-3 IniFile 클래스

윈도우즈에서 제공하는 Win32 API 중 ini 파일을 관리하는 API의 래퍼 클래스이다. ini는 아래와 같은 형태로 되어 있는데,

 

...
[Section1]
Key1 = Value1
; comment
...
...
[Section2]
Key2 = Value2
...

 

이를 구조화하여 읽기/저장하는 것이다. 만약 위와 같은 정형화된 패턴으로만 설정을 관리하고 크로스플랫폼이 필요하지 않다면 이용해 볼만 할 것 같다.

 

 

2-4 CircularQueue 클래스

원형 큐는 배열을 기초로 하여 큐를 구현할 때 기본적으로 사용하는 자료구조인데, 교재에는 그 것을 구현한 소스 코드가 인쇄되어 있다. 자료구조를 직접 만들어 쓰는 게 일반적인지 아직 현업에서 확인을 하지 못했기 때문에 경험 후 현황을 업데이트해야 겠다.

 

 

2-5 Log 클래스

로그의 중요성은 IT종사자라면 굳이 언급할 필요가 없을 것 같다. 본 교재도 '당연히' 로그의 중요성을 설명하였고, 자체 제작 로그 소스코드까지 인쇄되어 있었다.

 

나는 현업을 하면서 로그를 이용함에 있어 자체제작, 오픈소스 두가지 방식 모두 활용하였다. 자체제작이 재미도 있고 한데, 라이브러리가 고도화될수록 생각보다 구현량도 많고, 성능이나 안정성 역시 고민을 해야해서 업무 시간을 갉아 먹었던 것으로 기억한다. 경험상 잘 구현된 오픈소스를 이용하는 것이 좋은 선택이라 생각한다. 마지막으로 사용했던 오픈소스는 plog 였는데, 아주 심플한 반면, 성능이 약간 아쉬웠다. 때문에 개발의 형태에 따라 사용성과 성능을 잘 고려한 선택이 필요하겠다.