EasyQA
Venus와 마찬가지로 ETRI, 한국전자통신연구원(맞나? 인턴한 지가 오래 되니 기억이 가물가물)에서 새롭게 개발한 온라인 게임 서버용 테스트 도구인가 보다. 세션 중에 요약한 바부터 살펴보자.
2009년부터 개발을 시작했고 로드맵이 아직 한참 남았네.
성숙도 면에선 마이너스!
현재 고객사는 2, 3 곳 정도인가? 예정인 곳이 3곳 정도 더 있다는데 그거야 두고 볼 일.
그래도 아쉬우면 쓰는 거지 뭐.
케이비온라인 슈퍼 다다다의 적용 사례
모니터링 도구나 스트레스 테스트 도구 이야기가 있는데 실제 프로그램을 직접 돌려보며 확인하면 좋겠다.
약간 지루하네.데이터베이스의 데이터 변경도 지원하나 보네.
모니터링 도구가 서버 측에 붙는 게 아니고 가상 유저마다 붙네
서버측 모니터링은 추후 지원 예정이라네.게임 프로젝트의 규모가 너무 작아서 아직은 훌륭한 사례라 하긴 모자라네.
세션 제목이 시나리오 기반 어쩌구 인데 시나리오는 하나도 없네. 아, 그 세션은 이 세션 바로 전이었구나. 이런 착각!
치매라도 걸린 것도 아닐 텐데 왜 이리 기억을 못 믿겠는지 확실하진 않지만 슈퍼 다다다는 개발자 총 넷에 서버 담당이 그 중 둘이었던 것 같다. 게임 업계 들어와서 운이 좋았는지 첫 프로젝트를 크게 치뤘더니 참 작아 보이는데, 현실에선 이 정도 규모인 팀이 많은 듯 하다. 서버 개발자만 최대 열… 아, 또 기억 안 나네! 하여튼 평균 10 명 정도였던 그런 팀(물론 개발자의 자질도 우수하고)이라면 자체적으로 시나리오 기반의 테스트 클라이언트, 고도의 분산 서비스, 빌드 자동화 등등 북치고 장구치고 하겠지만 사람이 없으면 솔루션 가져다 쓰는 게 다행이 아닐까 싶다.
비너스의 경우 소스코드 임베딩이 필수적이라 게임이 완성 단계에 가까울 때 적용하기가 부담스러웠다고 한다. 그래서 EasyQA는 패킷 자동 분석 등의 해결책을 제시한다. 하지만 내 생각엔 소스코드 임베딩이 그 모든 단점에도 불구하고 최선이지 않나 싶다. EasyQA를 언리얼 엔진이나 크라이 엔진처럼 소스코드와 도구 통째로 판매하고, 프로젝트 종반이 아닌 초반에 구매하도록 유도하는 게 좋지 않을까? 물론 나중에야 부랴부랴 서버 안정화한다고 난리 치며 솔루션을 알아보는 모습이 눈에 선하긴 하다. 그러한 판매 전략이 쉽진 않아 보인다. 하지만 안정화를 막판에 생각한다면 결과야 뻔하니 중언부언하기 싫다.
벤더가 아닌 개발 팀의 입장에서 보면 최선의 방법은 서버 프레임워크, 클라이언트 네트워크 라이브러리, 그리고 이 둘의 개발 과정에 개밥 먹기로 쓸 테스트 도구의 제작을 팀 자체적으로 해결하는 것이라 본다. 개밥 먹기의 위력, 먹어본 이는 안다. 먹을 땐 쓴데 뒷맛은 참 개운하다. 패치나 신규 컨텐츠 추가가 괴롭지 않은 (아니, 그건 뻥이고 조금 괴롭긴 하다) 그런 세상에 살아보면 천국 같을 게야.
참, 그러고 보니 아무리 바퀴를 다시 발명하지 말라지만 현실에선 꼭 그렇지는 않다. 라이선스 비용도 생각해야 하고, 기술의 축적도 무시 못할 일이다. 다만, 옆 팀에서 좋은 바퀴를 만들어놨는데 그걸 안 쓰고 내 팀 바퀴를 새로 만들겠다면 글쎄… 난 반대일세!
무슨 말인가 하니, 솔루션 사서 쓰는 걸 옹호하는 사람이 지나칠 정도로 많아진 듯 하여 어제에 이어 오늘도 잔소리(마녀)가 하고 싶은 게다. 요즘 돈 참 잘 버는 모 회사에 계신 지인과 KGC를 핑계로 만나서 이야기를 나누었다. KGC 기념품 중에 광고지가 몇 장 있는데 그 중에 소스코드의 결함을 자동으로 탐지해준다는 도구가 있다. 마침 지인의 회사에서 이 비싼 도구를 사서 쓴다기에 물어봤더니 좋긴 좋단다. 그런데 품질에 제일 중요한 “단위 테스트”는 다들 짜기 싫어한다더라. 나 역시 Visual Studio에 있는 각종 버그 탐지 기능을 켜놓고 사는 사람이지만 개발해보니 어떤 자동화 도구도 단위 테스트에 비할 바는 못 된다. 돈이 넘치면 비싼 도구 사는 건 찬성이지만 그걸로 내 할 일 다 했다고 믿으면 오산이라는 이야기가 하고 싶었다.
첨언
테스트 도구와는 별개의 이야기인데 세션 중에 유니코드 이야기가 나와서 말이지. 레가시 코드라면 몰라도 새로 짜는 코드는 무조건, 토 달지 말고 유니코드로 짜야 하는 게 아닐까? 가만 보면 게임 하나 나오면, 중국, 동남아, 북미, 유럽, 남미까지 쭈욱 팔아먹는데 기반 코드를 유니코드로 짜지 않았다면 참 앞날이 험난하다. 그리고 윈도우 개발자라면 모르는 사람이 많진 않으리라 생각하는데, 윈도우의 기반 코드 자체가 유니코드라 std::wstring 이 아닌 std::string 같은 걸 자꾸 쓰면 오히려 성능에도 좋지 않다. 특히 STL엔 w 시리즈가 다 있으니 처음 듣는 이야기라면 MSDN 이라도 훑어봤으면 한다.
