동접 1천명 == 3백만원

매출 1조짜리 기업 NHN에서 출시한 아이두 게임과 게임 오븐에 대한 짧은 생각:

1. 하루 최고 동접 1000명을 찍으면 한달에 300만원을 지급한다? 한게임 유입자수 풀을 키우려는 전략이겠지만, 너무 짜다. 돈은 현재의 2배 정도로 늘리되, in game ad를 무조건 탑재하도록 하면 윈윈이 되지 않을까.
2. 정말 이걸로 돈을 벌려면, 접속 시간을 최대한 늘이는 게임 또는 특정 시간의 접속 비율을 높이는 방향으로 게임을 디자인해야 할 것이다. (자꾸만 동접 늘리는 트릭만 구상하는 레이옷..)
3. 게임오븐 IDE은 .NET이 아니라 Native C++으로 만들어졌고, 루아(luabind)로 서버 및 클라이언트를 개발한다. 놀라운 점은 IDE 자체적으로 스크립트 디버깅이 가능한데, 브레이크 포인트라든지 콜스택, watch를 모두 지원한다는 것. (dev.naver.com/opensource에다가 이것만 따로 무료로 공개해주면 좋으련만!!!)
4. 네트워킹 역시 루아로 이루어지는데, key-value로 된 메시지를 보내거나 SyncObject라고 해서 자동적으로 테이블을 상대편으로 복제할 수 있다. 얘들도 __newindex 로 루아 테이블 내부 값의 생성, 삭제 및 변동을 추적했을까나~
5. 사실 게임 오븐으로 만든 서버를 어떻게 호스팅하는가? 가 가장 궁금하다. 그냥 서버 exe 를 적당한 서버로 배포해서 실행하지는 않을테니, 여기에 설마 클라우드 개념이 들어갔을까? 흐흠..

boost::tuple<int,short,char> t;
int i = get<0>(t);
int j = get<1>(t);
int k = get<2>(t);

그런데, 이걸 코드 생성기에서 이렇게 만들면 어떨까?

class login : public boost::tuple<wstring,string,int>
{
public :
	const wstring & userid() const { return get<0>(); }
	void userid( const wstring & v) { get<0>() = v; }
	const string & passwd() const { return get<1>(); }
	void passwd( const string & v) { get<1>() = v; }
	int key() const { return get<2>(); }
	void key( int v ) { get<2>() = v; }
};

login msg;
msg.userid(L"reiot");
msg.passwd(".com");
msg.key(1975);

wstring userid = msg.userid();
string passwd = msg.passwd();
int key = msg.key();

이 정도면 읽기도 쉽고 직렬화하기도 편한 객체처럼 보일 것 같은데… (여전히 디버거에서는 보기가 귀찮지만.. autoexp.dat 를 잘 고치면 해결할 수 있지 않을까나~)

요즘은 디버깅할 때 Ctrl+Alt+E를 눌러서 first chance exception이 발생할 때에도 브레이크포인트가 걸리게 하는 편이다. 뭔가 내가 모르는 문제가 저 안에서 벌어지고 있다는 게 못마땅하기 때문인데, 언젠가부터 64비트 OS에서 32비트 서버 어플리케이션에서 소켓 연결을 할 때, First chance exception 0x000006C5 : The tag is invalid 라는 예외가 던져져서 디버깅할 때 짜증이 솟구치는 나날들이 계속되었다. 더군다나 현재 채택한 DB 쿼리 방식이 필요할 때마다 재연결하는 connection pooling 이라서 디버거를 좀 오래 잡고만 있어도 계속 예외가 던져져서 집중이 자꾸 깨지곤 했었다.

조사해보니 마이크로소프트도 포기한 예외였는데, 도무지 이걸 무시할 방법을 찾지 못하다가 (Win32 예외 목록에 없으니까!) 그저께 커스텀 예외도 추가할 수 있다는 것을 우연찮게 겨우 이제서야 알게 되었다.

지금은… 마음이 편하다.

비주얼 스튜디오 2005에서 어떤 솔루션만 열면 인텔리센스가 멈추지 않는 현상을 만나서 검색해니, SP1 이후로 한글판 핫픽스 하나와 영문판 핫픽스 하나가 나와 있었다.

둘 중에서 후자만 깔아도 된다고는 하는데, 영문판 핫픽스는 한글판에서는 설치가 안된다는 것이 문제였다. 다행히도 쉬귀군의 팀은 영문판을 쓰고 있었기에 강제로 원격 설치(-_-)를 해서 관련 dll 들을 받아서 그냥 덮어씌워보니 그럭저럭 잘 돌아가는 것 같았다. 조금 걱정이라면 디버그-릴리즈 전환할 때마다 인텔리센스가 돌아간다는 점이랄까.

정리하자면, 영문판 사용자에게 부탁해서 다음 dll 들을 덮어쓰면 된다!

• VC/packages/vcpkg.dll
• VC/packages/VCProjectEngine.dll
• VC/packages/VCProject.dll

참고로, VC/bin/amd64 또는 x86_amd64 아래에도 버전은 같지만 크기가 다른 VCProjectEngine.dll 파일이 있긴 한데 얘네들은 안덮어써도 돌긴 돌아갔다…

ps. 컴파일이 빨라진다는 핫픽스도 있구나..

성장 동력이 없거나 멈춘 국내 게임 회사들이, 직원 월급을 못주고 있다는 첩보가 속속 입수되고 있다.  정말 대충 예상해본 것들이 슬슬 현실로 다가 오고 있다는 이야기다. 그나마 반가운 소식은 게임이 불황에도 웃음지을 수 있는 몇 안되는 산업이라는 뉴스 정도다.  

혹자는 힘들 때일수록 몸집을 줄이고 직원 교육에 투자하라고 조언하지만, 내가 사장이라도 그건 쉽지 않은 일이다.  마구 사람을 잘라내고 있는 서구 기업들은 과연 바보라서 그러는 걸까. 그럼 우리는 이 추운 겨울을 어떻게 견디어내야 할까? 개인적으로도 선 거두절미 후 줄탁동시를 시행해야 한다고 본다. 즉,

• 무엇보다도 가장 먼저 바보 C급 인재들을 내보낸다. 기회 비용을 고려해 봤을 때, 무작정 열심히 일하는 C급 인재야말로 회사의 최대 적이다. 덤으로 불만분자들도 함께 처분하면 더욱 좋다. (뜨끔!!)
• A급 리더들은 쓰다듬어주기만 해도 알아서 잘 할테니, 웅크리고 있는 B급 인재들에게는 인센티브 강화 같은 당근과 **** 등의 채찍을 제공한다. 개인적으로 테라의 공개된 영상에 많은 감명을 받았는데, 외부의 공격(?)이 내부의 결속을 강화시킨 좋은 예가 아닐까 한다. 
• 돈, 지식, 노하우, 그리고 열정적인 핵심 인재들 등 축적할 수 있는 모든 리소스들을 아껴서, 더욱 더 길어질 겨울에 대비한다. 아무리 생각해도, 이번 겨울은 10년짜리다. 
• 부동산 난개발과 같은 불필요한 중복 개발을 자제하고, 제대로된 게임을 최대한 빨리 출시할 수 있는 프로세스를 다진다. 이걸 갖춘 회사만이 10년을 살아남을 게다. 결과적으로 개발을 투명하게 바라볼 수 있게 해주는, 애자일 프로세스의 전사적 도입도 좋은 방법이 되겠지만, 준비되지 않은 상태에서는 오히려 반감만 불러일으킬 확률이 99.999% 되겠다.
• 무엇보다도 전장 플랫폼을 바꾼다. 살아남는 자가 강한 것처럼, 하고 싶어 하는 것보다는 잘하는 분야를 계속 파나가고, 그걸 다른 플랫폼으로 옮겨가는 전략은 어떨까. 돈먹는 하마인 MMO, 다 비슷비슷한 캐주얼, 횡스크롤 액션..  새로운 성장 동력 찾기가 쉽지 않은 건 알고 있는데, 너무 멀리서 찾다가 피같은 돈을 다 날려먹으면 곤란하다. 물론 와우를 능가하는 MMO를 만들어서 년간 1조씩 벌어들여도 되겠지만. 

뻔한 이야기를 시니컬하게 쓰면 다들 우러러 보는 게 요즘 트렌드이길래, 나도 덩달아서 비스무리하게 써 봤다. 그러나 요즘은 불유쾌한 예언을 하는 자가 잡혀 들어가는 세상인지라, 또 쓸데없이 오해 크리나 받지나 않을까 해서 고이 모셔뒀었는데, 오늘 또 ING 7천, 필립스 6천, GM 2천 등 총 7만명짜리 GLOBAL JOB CUTS 이 있었다길래 어째 으스스해서 공개해본다.

이클립스의 얼랭 개발환경(perspective)인 erlide를 사용하면, 매번마다 c(module) 로 컴파일하는 번거로움에서 벗어날 수 있다. 그냥 Save 만 하면, 알아서 코드를 컴파일하고 경고나 오류를 보여주기 때문이다. 일단 매뉴얼에 써 있는 대로 설정하고 나면, 이클립스 IDE의 기능들을 간단히 쓸 수 있으므로, 얼랭 초보라면 반드시 eclipse 부터 설치하기를 권장한다.

어차피 매뉴얼에 다 나오는 내용인데, 핵심 기능들만 간단하게만 소개하자면

• gen_server, gen_fsm 등 OTP 기본 템플릿 제공
• F3 – 함수 정의/선언으로 바로가기
• Ctrl + I – 자동 들여쓰기
• Ctrl + Space – 자동 완성
• Alt + O – 개요 보기
• Ctrl + Up/Down – 콘솔창에서 히스토리 기능
• 브레이크 포인트는 라인 맨 앞을 더블클릭
• 디버깅 끝낼 때에는 perspective 를 다시 얼랭으로 전환할 것

특히 놀라운 것은, (사실 erl 콘솔에서도 볼 수 있지만) Process List View 에서 보면 무려 36개의 얼랭 프로세스들이 떠 있다는 점이다. 루아나 파이썬처럼 그냥 달랑 스크립트만 실행되는 게 아니라는 건 짐작하고 있었지만, 조금은 부하가 걱정될 정도로많이 떠 있긴 하다.

대강의 포맷은

가령 로그인 메시지를 “ppl” 이라는 포맷으로 정의하면, 파서는 이걸 읽고

typedef boost::tuple<string,string,long> msgLogin;

이라는 클래스를 정의한다는 거다. 요기에 좀 더 기능을 첨부하자면,

• 64 bit integer
• datetime, smalldatetime 등 T-SQL 타입 지원(또는 매핑)
• STL 지원 : list, vector, map, set
• 비트 연산 지원 : B3은 바이트 타입인데 3비트만 읽고 쓴다는 뜻이 된다.

단점이라면 내부 멤버 접근을 userid, passwd 같은 이름 기반이 아니라 get<1>, get<2> 처럼 해야 한다는 점인데, 이건 좀 심하게 귀찮긴 하겠다. 역시 이름 기반 접근이 그나마 컴파일러가 검증해주니 제일 좋은 방법인가.

자. 만들어주세요.

http://www.flickr.com/photos/jasoncross/1260110610/

네트워크 프로그래머가 클라이언트 서버간 통신(혹은 P2P 통신)을 바라보는 메타포에 대해서 갑자기 궁금해졌다.

가장 흔한 개념은 바로 패킷이다. 만약 컨텐트 코드에서 Packet 이나 Command, Message 같은 객체와, Send 와 Receive 같은 함수가 노출되어 있다면, 그걸 만든 사람은 데이터 통신을 바이트의 전송이라는 개념으로 인지하는 것이 아닐까? 데이터를 던지고 받는다는 개념의 네트워킹은 아마도 귀찮은 하드코딩 노가다 작업일 확률이 높다. 흐흐.

조금 높은 레벨(?)로 올라간다면 원격 함수 호출(RPC)이 있겠다. 무언가를 상대방에게 요청(request)하면, 상대방은 그걸 처리한 후 성공이나 실패 같은 결과(response)를 보내준다. 이런 메타포에서는 동기/비동기라든지, 타임아웃 같은 처리들이 따라오게 된다. 만약 네트워크로 무언가를 요청하는 행위가 함수 호출 인터페이스처럼 잘 래핑되어 있다면, 대략 1초간 으쓱해도 무방하겠다.

추가적으로, 결과가 없는 요청은 특별히 이벤트(event) 혹은 통지(notification)라는 메타포라고 부를 수 있겠다. 사실 매번 렌더링을 해야 하는 게임 클라이언트나, 항상 빠른 응답 속도를 보장해야 하는 서버가 동기적 요청을 하는 일은 정말 드문 경우이다. 이런 이유로 비동기적인 통신이 대부분이기 때문에 적당히 현재 상황을 알려주고 잊어버리고 있다가, 혹시나 결과(보통은 에러)가 오면 음..그런가? 하고 처리하는 느낌으로 코드를 만들 때가 있다. 시간이 나면 Notify 같은 이름들이 있는지 한번 체크해보시라.

위에 나온 것들은 대체로 즉각적인 처리를 필요로 하는 반면, 어떤 이벤트들은 시간축으로 늘어질 때가 있다. 무슨 말이냐 하면 이동, 공격, 물리 같이 float 단위의 정밀한 사건들은 공간 뿐만 아니라 시간과도 밀접한 관계가 있기 때문이다. 이런 상황을 아름답게 처리하려면, 받는 족족 무언가를 처리하기보다는, 데이터를 시간순으로 쌓아두고 예측, 보간을 통해 그럴듯하게 보여줄 필요가 있다. 이런 걸 보통 동기화(synchronization) 또는 복제(replication)이라고 부른다. 보통 이런 코드들은 네트워크를 넘어선 상위 로직 레벨에 존재하는 경우가 많은데, 어떤 네트워크 라이브러리들은 이런 수준도 알아서 잘 처리하기도 한다.

from http://www.problogger.net

좀 억지스럽긴 하나, 이메일이나 RSS 등에서 주로 쓰이는 발행(publish)과 구독(subscribe)이라는 메타포는 어떨까?  채팅 채널 같이 지속적인 이벤트가 간간히 발생하는 논리적인 영역에 참가하면, 꾸준히 어떤 이벤트들이 날아오게 된다. 사람들이 바글바글 거리는 지역에 발생하는 수많은 이벤트들을 클라이언트에게 알려줄 때 즉각적인 브로드캐스팅 대신, 이런 개념을 사용한다면 필터링을 통해 트래픽 절감의 효과를 손쉽게 얻을 지도 모르겠다. 후후.

이렇게 단순한 이야기를 현학적으로 어렵게 쓴 이유는, 사실 며칠 전 XML로 프로토콜을 정의하고 코드를 만드는 걸 한번 해볼까 하고, 스키마 튜토리얼을 살펴 보다가, 프로토콜은 XML이 아니라 XSD에 들어가는게 맞지 않냐는 생각이 들어서였다. 물론 XSD도 사실 XML이니까, 쓸데없는 고민 없이 그냥 해도 될 것 같기도 한데… 그러다보니 또 굳이 요즘 세상에 트래픽이 많은 게임이 아니라면 XML 프로토콜을 쓰고, 파싱 및 검증을 XSD로 하는 것도 괜찮지 않냐는 망상에서 허우적 거리고 있다.

또 한편으로는 클래스 다이어그램과 시퀀스 다이어그램으로 클라이언트/서버간 통신을 표현하고, 그걸 파싱해서 각종 RPC 함수들의 골격을 만들어내면 인생이 좀 수월해지지 않을까 하는 생각도 든다. 물론 프로토콜이 바뀔 때에 기존 코드가 날아가지 않도록 코드 제너레이터를 잘 짜야겠지.

글 시작과 끝의 주제가 다른 걸로 봐서, 아무래도 요즘 스트레스를 많이 받나 보다. ㅋㅋ

9.11 Memory Wall

구글에서 memory wall 을 검색하면 위와 같은 사진들이 나온다. 아마도 기억과 회상을 위한 그림이나 사진, 메모들을 붙이는 벽을  memory wall 또는 remembrance wall 이라고 부르는 모양이다.

훗날 128 코어의 시대가 도래하면 얼랭 게임 서버가 혹시 대세가 되지는 않을까 했는데, 벌써부터 멀티 코어에도 메모리 장벽이라는 한계가 있다는 이야기가 솔솔 들린다. 이로 인해 8-16코어를 넘어서기가 힘들다고 해서 널티코어 효과(Nulticore Effect)라고 부른다니.. xeraph님이 GG하신 게 정답이지도?

보통 물리적/논리적으로 서버 프로세스가 늘어날수록 디버깅이 어려워지고, 관리 비용도 증가한다고 한다. 그래서 요즘은 분산을 고려해서 모듈끼리도 메시지 통신을 하도록 한 후, 개별 모듈들을 최대한으로 단순하게 구현하려고 노력중이다. 대신 메시지를 만드는게 여간 귀찮은 일이 아니라서, 언제 시간이 나면 후딱 XML 메시지 같은 걸 만들어볼까 싶기도 한데… 그럴 여유도 없을 뿐더러, 만들어도 같이 감동해줄 전우가 없다는 게 안타깝다. 크흑.

• 열심히 하는 사람 보다는, 잘하는 사람이 되어라.(Don’t Work Hard, Work Well)
• 전문 직장인이 되기 보단, 전문 직업인이 되어라.

예전에 모시던 분들이 즐겨 하시던 말들이다. 과거의 무능하고 나태했던 내 모습을 곳곳에서 찾아낼 때마다, 혹시나 나도 곧 그렇게 무뎌질까 두렵다.

칼날을 더욱 날카롭게 세우기 위해서, 이번 달부터 새벽 영어 회화를 다시 시작했다. 영어 강사에게 리만 브라더스가 왜 나쁜지를, 왜 미국산 소고기가 나쁜지를 설명하기가 여간 힘들지 않았다. 역시나 함께 듣는 이십대 중반의 젊은 친구들은 정치에 관심이 없었다는 것도 확인했다. 덕분에 의도하지 않게 근무 시간이 한 시간 넘게 늘어나 버렸는데, 나보다 항상 더 일찍 나와서 일하는 사람도 있어서 깜짝 놀랬다. 역시 출근 순서가 회사의 실질적 직급 순라는 이야기가 맞는 걸까 하핫

그리고, 스마트한 회사 친구들과 얼랭 대결(?) 프로젝트도 바야흐로 가동되었다. 주사위를 굴려 2:2 로 짝을 지어 모종의 코딩 대결을 펼치려고 하는 중인데, 역시나 한 마디만으로 열길 사람 속도 알아듣는 친구들이라서 기대가 된다. 반짝이는 후학들의 걸림돌이 되지 않기 위해서라도, 집에서 열심히 예습복습을 해야것다. 클클.