DB를 경시하는 온라인 게임 개발자(사)
시스템 통합(SI), 웹 관련 산업의 불황으로 최근 많은 인력들이 비교적 안정적인 수익을 내는 게임회사로 이직을 했거나 희망 한다고들 한다. 본인 역시 인터넷 관련 업체의 DBA 로 근무를 해 오다, 약 5년 전 게임 쪽으로 업종 변경을 하였다. 최근 많은 DB 관련 인력들이 게임회사로 이직을 한 후 공통적으로 하는 이야기가 게임 회사에서는 DB를 너무 경시한다는 것이다.

- 개무시 = 개(犬) + 무시 (무우의 경상도 사투리)


과거 1세대 온라인 게임 이라 불리는 게임의 경우 모든 정보를 바이너리형태로 만든 다음에 파일 시스템에 저장 하는 형태를 주로 이용 하였다고 한다. 물론 DBMS를 사용 하는 곳이 있긴 하였지만 사용하였지만 단순히 파일을 좀더 효율적으로 관리할 목적이 아닌 파일 시스템을 대체하기 위한 수단 일뿐, 데이터 저장 공간 그 이상을 의미를 지니지 못했다.

온라인 게임에서 DB의 역할은 일반적으로 볼 때 "캐릭터 데이터"의 저장소 정도로 생각 해 볼 수 있다. 그러나 지금의 온라인 게임은 데이터저장은 기본이며 방대한 데이터의 효율적이 관리와 게임의 문제점을 해결/개선 하기 위해 끈임 없는 데이터 분석이 요구 되는 시점이 되어 버렸다.

- 잘 활용하면 상상 이상의 결과물을 만들어어 낸다.


그러나 아직도 많은 개발자(사)들 사이에서는 DB를 단순 데이터 저장소 수준으로 생각 하기 때문에, 데이터의 효율적인 관리나 분석에 대해서 크게 비중을 두지 않는다고 한다. 아니 이런 것은 퍼블리셔의 몫이라고 생각 하는 경우가 종종 있다고 한다.

상황이 이쯤 되다 보니 개발사가 퍼블리셔에게 DB의 모든 권한 심지어 설계/개발 까지도 일임을 하는 일이 종종 발생 한다고 한다. 이 경우 개발사는 데이터 운영 노하우가 전혀 없기 때문에 문제 발생시 많은 부분을 퍼블리셔에게 의존을 해야 한다. 더욱이 해외 런칭시 퍼블리셔 선정에서 상당한 제약을(DB를 잘하는 업체가 별로 없음) 받을 뿐만 아니라, 자신의 게임 데이터를 주도적으로 하지 못하기 때문에 빠른 대응과 상황 판단이 느려질 수 밖에 없다. 특히 해외에서는 시공간의 제약으로 인해서 이러한 현상이 더 심하게 느껴진다.

만일 게임의 지표가 점차적으로 나빠지는 침체기를 맞이 하고 있다고 가정 해보자. 이때에 퍼블리서갸 아낌없는 지원과 거침없는 데이터 분석을 통하여 문제를 해결 해주면 좋겠지만, 이런 일은 잘 일어나지 않는다. 오히려 "접히는 게임" 인식과 함께 쓸쓸히 서비스 종료를 맞이 해야 할지도 모른다.

- 개인적으로 좋아 하던 게임이지만 안타깝게 서비스 종료를 맞이 했다. (예시일뿐 본문과는 무관;;;)


본인의 경우 불행인지 다행인지 모르겠으나, 개발사 퍼블리셔 양쪽 근무 경험을 가지고 있다. 퍼블리셔에서 개발사로 옮기고 퍼블리셔와 첫 미팅에서 개발사와 퍼블리셔는 생각하고 추구하는 가치 자체가 항상 일치 하지 않는다는 것을 알게 되었다. 개발사의 경우 "아들 같은 게임" 이 대형 퍼블리셔에게 있어서는 우리가 "서비스하는 어려 게임중의 하나"가 될 수 있다는 것을, 특히 게임의 성적이 기대만큼 좋지 못하거나 퍼블리셔에서 제작하거나 새로이 계약한 신작이 발표 되는 경우 제한된 리소스를 사용하는 퍼블리셔는 기존 게임에 투입된 리소스를 신작에 투입하는 것은 당연 한 것이다.

이런 상황에서 개발사의 의지와 능력만을 가지고 자신의 문제를 분석하고 해결해야 한다고 가정 했을 때, 자신의 데이터를 알고 모르고는 상당한 차이를 보여줄 것이다. 특히 하나의 게임을 가지고 다양한 국가에서 동시다발로 서비스를 하는 경우에는 그 차이가 더욱 심할 것은 분명하다.

그렇기 때문에 이러한 문제점들을 빠르게 해결 하기 위해서는 데이터의 주도적인 권한은 개발자(사)가 확보 하고 있어야 한다는 것이다. 손자 병법을 보면 지피지기백전불태 [知彼知己百戰不殆] 라는 말이 있다. 知彼 (시장, 경쟁), 知己(고객의 상태) 중에서 지피(知彼)를 위해서는 고객의 정보가 기록되는 데이터가 반드시 필요 한데 개발자가 자신의 게임을 즐기는 유저의 정보에 대해서 잘 모른 체 상황을 판단 하면, 어떻게 되겠는가??

혹 지금까지 단순히 DB를 저장소 정도로 생각 했거나, DB 를 활용한 데이터 분석이나 해외 서비스의 적극적인 지원이 현 기업이나 팀의 상황에서 불편하고 잘 몰라 못한다는 문제라 생각 한다면, 장기적인 안목을 가지고 투자를 하라고 부탁 드리고 싶다. 특히나 협업에 있어서는 고객의 데이터를 엑티브하게 활용 하는 것은 필수 적이다.

- 현재를 통하여 미래를 내다 볼수 있다면...


혹 이 긁을 보시는 현업에 계시는 게임 개발자(사) 분이라면 앞에서 말씀 드린 데이터 관리의 중요성과 데이터를 활용한 게임의 개선가치가 무궁 무진 하다는 것을 말씀 드리고 싶다. 제발 DB의 보석 같은 가치를 발견 하고 이를 만들고 설계 하는 DBA들 좀 사랑 해주시길 부탁 드리고 싶다.

또한 게임 업계로 이직을 한지 얼마 안된 DB 설계자나 DB 관련자들은 게임 제작에 관한 "전체적인 관점" 특히 서버에서 데이터가 어떻게 움직이는지에 대해서 공부 해두는 것을 권하고 싶다. (그래야 서버 프로그래머나 프로듀서에게 말빨이 먹힌다)

by wowhoon™ | 2009/01/19 16:26 | ■ 뻘소리 컬럼 | 트랙백 | 덧글(16)
트랙백 주소 : http://wowhoon.egloos.com/tb/4074731
☞ 내 이글루에 이 글과 관련된 글 쓰기 (트랙백 보내기) [도움말]
Commented by JOSH at 2009/01/19 17:29
보통 DB에 대해 무지하거나
그 사람들의 전문분야가 아니라서 그런 경우가 많은 것 같습니다.

온라인게임의 시스템이란 극단적으로 말하자면
처음부터 끝까지 클라이언트와 DB의 대화 인데....

사실 DB 단 프로그래밍 하는게 엄청 구식으로 보이고 쉽지는 않잖습니까 ^^

저도 메인은 java프로그래머로 시작했습니다만
DB에서 프로시저나 펑션 잘 만 짜면 훨씬 빨리 될 수 있는 프로세스를
느린 java에서 열심히 처리해서 DB로 넘기는거 보면....
..... 좀... 무섭...

그런데
나 그런거 몰라, 내 기술 말고 저 기술이 더 좋아 하고 인정하기가 쉽지 않죠....
사회생활이란게. T-T
Commented by 쌍부라 at 2009/01/19 20:35
아니 이 무슨 도발적인 타이틀인가 했더니 역시 훈님 -ㅅ-);

그런데 윗분 말씀에 또 이의가 있는게.. http://toby.epril.com/?p=468 이런 글에서는 "뭔 소리야 로직을 왜 sp에 둬?" 하고 있거든요. ORM 프레임워크의 발전으로 오버헤드가 크지 않을 뿐더러 각종 로직 처리에는 db보다 프로그래밍 언어가 낫다는 거죠;;

이거야 뭐 끊임없는 떡밥이기도 하고, 부분적으로 SQL이 약한 점을 보완하기 위해 MS를 비롯한 여러 벤더에서도 java runtime을 붙인다든지 (nhn Cubrid였나..) .net을 내장시킨다든지, 스크립트 런타임을 붙인다든지 (PostgreSQL) 하고 있으니 말입니다.

확실히 분산 트랜잭션이라면 db에서 db를 불러서 처리하기도 하지만 COM+ 써서 처리하는 경우도 많지 않던가요. 물론 속도가 생명인 게임 서버가 거기에 끼는 것은 거의 못봤습니다만..

다만 게임 서버 프로그래머들중 상당수가 DB를 저장소 이상의 개념으로 생각하지 않는다는 점에는 상당히 동의합니다.
Commented by JOSH at 2009/01/19 21:32
하하... 네.. 로직을 DB에 두는 것에 거부감을 느끼시는 분들도 많지요.
요즘엔 그게 일종의 대세이기도 하고....
그런데, 위험한 생각인지도 모르겠습니다만 그런 논지를 보면
'내가 다루는 기술 가지고 다 커버 가능하다.
컨트롤 불가능한 곳에 주도권을 주기 싫다' 는 뉘앙스가 읽히는 느낌이 좀 있습니다.

뭐 리소스가 충분히 확보되어서 특정 방법론을 지향하는 것을
반대하자는 이야기는 아닙니다.
어느 프로젝트든 가 보면 거기 할당되는 리소스(인력)가 어디에 익숙하냐에 따라
거기에 맞는 개발하는 방법론을 택하는게 옳을테니까요.
비즈니스로직은 프레임웍에서만 다루자, SP를 쓰지말자 하고
제한하는 방향으로 접근하는게 맞나 해서 그렇습니다.

http://zeous.egloos.com/2135418
자백하자면 이 글에서도 프로시저에 반감을 가진 분에 대해 반론을 하기도 했는데...

똑같이 DB프레임웍을 쓴다 해도
저번 프로젝트에서는
아예 중간 매핑을 철저히 자동화 시켜서
자바소스는 한줄도 안 건드리고 jsp 에서 서비스명 결정하고,
데이터 던져줄 쿼리 만 고민해서 열심히 짠 다음
매핑SW 에 서비스명에 따른 쿼리 집어넣으면 작동되어서
그 프레임웍이 뭐였는지 알 수도 없었던 프로젝트도 있었고...

지금하는 프로젝트는 ibatis를 쓰는데
원체 건성건성 하는 타입이다보니 꼼꼼히 수작업으로 매핑하는게
성에 맞지 않아서 무럭무럭 아이바티스 살해충동이 높아지고 있는 중입니다... ^^
Commented by wowhoon™ at 2009/01/20 11:18
뭐 항상 그렇지만, 적당히가 중요한 것 같습니다.

현실적으로 SQL 가지고 모든걸 다 처리하는건 무리인듯 하고,
그리고 그게 좋지도 않고 게임 서버와 적절한 밸런싱을 하는게 중요한것 같습니다.

일전에 모(?) 게임의 SQL 쿼리 튜닝을 한적이 있는데 인벤토리 콜 부분에서
ORDER BY 를 쓰길레 이걸 빼자고 하니 서버 프로그래머가 소팅 어렵다고 (귀찮다고)
DBA는 서버 로직을 정확히 모르니, 힘쎈(?) 서버 프로그래머가 하자는대로 하는 형국의..;;

저도 첨에 게임 회사와서 게임 서버 로직 몰라서 개 삽질 할때가 생각 나는데
알고 모르고의 차이는 큰것 같습니다. 결론은 뭐든지 아는게 힘 ~~!!!!
Commented by Sikuru at 2009/01/19 20:41
시도해보진 않았지만, .Net CLR 프로시저 + MSSQL 정도면, 유저와 디비 사이에 소켓 통신을 담당하는 해주는 심플한 서버로 간단한 캐쥬얼 게임류 정도는 MSSQL에 얹은 CLR로 로직처리를 할 수 있지 않을까 생각도 해봤었지요 ^^;;;

디비가 해줄수 있는것까지 Raw Data 수준으로 쿼리해서 데이터를 코드로직에서 다 처리하려는건 저도 이해하지 못하겠어요 -ㅁ-;;

특히나 DB에 바이너리 스트림 때려박는 님들은 백번 양보해도 이해할 수 없어요.
Commented by JOSH at 2009/01/19 20:54
> 특히나 DB에 바이너리 스트림 때려박는 님들은 백번 양보해도 이해할 수 없어요.
... 대단하군요... =ㅁ=
Commented by 쌍부라 at 2009/01/19 21:42
그런 여러분들을 위해!

자상한 마소 SQL Server Team에서는 SQL Server 2008 에 FileStream 기능을 추가하였습니다!

오오 경배하라 오오 (결론이.. 어?)
Commented by wowhoon™ at 2009/01/20 11:14
게임서버는 모르겠고, 저는 주로 툴 개발에 저런식을 종종 사용 합니다.
상당히 편리하고 작업 효율도 좋구요, 주로 성능과 상관 없는 곳에서 사용 하긴 하는데..
아직은 성능이 민감한 곳은, 하드코어 하게 SQL 만 가지고 컨트롤 하는게 편하더라구요.

Commented by Sikuru at 2009/01/21 12:18
쌍부라님 // 그럴때 선조들은 '그러라고 만든 게 아닐텐데 ?' 라고 하셨죠 (...)
Commented by designo at 2009/01/21 10:16
혹시 추천해주실만한 서적이 있을까요? DB에 무지한 게임기획자가 겉맛이라도 살짝 볼만한..
Commented by wowhoon™ at 2009/01/21 10:47
책을 좀 찾아 봤는데, 안타깝게도 게임에 특화된 DB 관련 서적은 없는것 같네요. 게임에 특화된 내용을 다루는 책은 없으니 일단 전체적인 설계자의 관점에서 데이터 모델을 어떻게 만드는지에 대해서 알아 두시는게 어떨런지요 ??

"소설처럼 읽는 DB 모델링 이야기" 란 책이 있는데 처음 접하시는 분들도 읽기 쉽도록 쉽게 쓰여저 있는 것 같습니다. 데이터를 어떻게 기록 하면 좋을지에 분야에 대해 관심을 가지고 보시면 좋을 것 같네요.

개인적으로 DB 나 DB를 통한 분석에 조금더 관심이 있으시다면 툴쪽으로는 엑서스, 엑셀관련 관련 책이나, 학문적으로는 통계학을 공부해보시는 것도 조금 도움이 되실 것 같습니다.
Commented by 쌍부라 at 2009/01/22 01:36
그러고보니 요샌 학기 핑계대고 한참 손에서 완전히 놨다가 (..)
요새 "계속 미루다가 중지되어 양치기 소년이 된 계기가 되어준" 관리툴 작업하면서
기존 구조 리뷰하고 이거저거 보고 그러고 있습니다 ㅡ,.ㅡa

(그 와중에 70-432 하나 따긴 했는데 이거 거의 찍기로 딴거라 땄다고 하기도 민망하고..)

음.. 책이라면 거시기 좀 쉽게나온 DB책같은게 있었는데.. 한빛의 Blog2Book 시리즈에 DB 책이 있는데 괜찮았고요 (책이름은 까먹고~) 요샌 리팩토링 데이터베이스 구매신청 해서 읽고 있다져 ㅎ_ㅎ
Commented by Dortmann at 2009/01/23 16:43
웹서핑 도중 도발적인 제목에 이끌려 죽~ 읽어보게 되었습니다만, 동감되는 내용이라 흔적 남깁니다. ^^ 저 역시, 저희 기획팀 녀석들에게 자주 하는 말 중 하나가.. "서버와 친하게 지내라"는 거거든요. 좋은 글 잘 보고 갑니다. 종종 들르겠습니다.
Commented by wowhoon™ at 2009/01/25 04:54
제목을 도발적으로 뽑아서 그렇지 실제로 내용은 별거 없습니다. -_-;

최근 주변의 들리는 이야기 에서, DB 쪽 개발의 비중이 의사결정권자들 사이에서 너무 가볍게 여겨지는 느낌을 많이 받아서 가능성에 대해서도 이야기 해보고 블로그를 한풀이(?)도 한번 해본 것이었습니다. ^^

기획자가 구현에 대해서 잘 알면, 아무래도 둘간의 협업에 도움이 될 것 같습니다. 반대로 프로그래머 역시 기획을 알면 도움이 될 것 같습니다. 기획자, 아티스트, 개발자 모두 서로의 입장을 이해 해준다면 아무래도 좋은 결과를 만들어 낼 것 같습니다.

일전에 넥슨 데브켓의 이은석 PD 가 KAIST 에서 발표하신 세미나 내용 중에 "공대생 서바이벌 가이드" (http://doocub.egloos.com/3623707) 이란 게 있는데, 개발자의 센스에 대해서 이야기 해둔 것이 있으니 한번 보셔도 좋을 듯 합니다.
Commented by 소천환 at 2009/04/10 11:50
최근에 "부의 미래"란 동영상을 보며..
느낀바의 또다른 공감글이네요 ^^

앞으로 DB를 지배, 정리, 관리한 기업이나 개인이..
주된 이목을 받지 않을까 하네요.. ㅎ

봄소풍 않가심까? ㅋㅋㅋㅋ
Commented by wowhoon™ at 2009/04/20 18:11
일에 치여서 봄소풍은 당분간 힘들듯...
DB를 지배하는 작업은 이미 많은 기업이 준비 중일듯...

:         :

:

비공개 덧글

◀ 이전 페이지   다음 페이지 ▶