Rhea's Package

1. 네트워크 아키텍쳐
익히 알려져 있는대로, 소켓 속에는 주요 함수가 몇개 없습니다.
클라이언트를 기준으로 하면 연결을 위한 connect(), 주고받는 send()/recv(), 연결해제를 위한 close()뿐입니다.
그러나 많은 게임들은 이 몇안되는 단순한 함수들로 클라이언트/서버(이하 C/S)과 Peer-To-Peer(이하 P2P)를 오가는
마법과 같은 네트워크들을 보여줍니다.

1.1 모든 것은 서버로 C/S
C/S 모델은 100% 서버 지향 네트워크 아키텍쳐입니다.
사용자는 게임 클라이언트 실행시 서버에 의해 게임 플레이가 결정됩니다.

가장 좋은 예는 MMORPG와 맞고/포커같은 카드류 게임입니다.
C/S 모델은 MMORPG가 발전한 우리 나라에서 크게 발전된 모델입니다(기술뿐만 아니라 운영도 포함해서).

C/S 모델의 장점은 보안에 강력하다는 점입니다.
모든 결정이 서버에 의해 판가름나므로 해킹에 강합니다.
만약 해킹을 통해 어떤 짓을 했다고 하더라도 다음날 아침이면 들통납니다.
대부분의 온라인 게임 회사들일 경우, 출근하자마자 볼수 있는 것이 어제 급격히 레벨이 오른 유저의 전적입니다.
당장 제재가 가해지지는 않지만 어김없이 들키고 맙니다.
...나머지는 서버개발자가 아닌, 이름은 친절하지만 사실은 무서운 아저씨들인 고객만족팀에서 해결해주시곘죠.

여기서 한가지 명확하게 짚고 넘어갈 것이 있습니다.

홈페이지 이야기를 하니 헛갈린다면 게임으로 넘어옵시다.
C/S기반의 슈팅 게임을 있다고 할때 공격 성공 판정을 서버에서 해야할까요, 클라이언트에서 해야 할까요?
서버에서 하자니 매 키입력마다 네트워크를 타야 합니다.
클라이언트에서 하자니 검증이 불가능합니다.

정답은 그때그때 다르다이고 서버에서 처리할 것과 클라이언트에서 처리할 것을 알맞게 나눠야 한다는 것입니다.
앞으로 게임을 만들며 이 문제를 실전에서 다시 짚을 것입니다.

1.2 우리끼리 놀자 P2P
P2P는 유저들끼리 데이터를 주고 받으며 게임을 진행하는 방식입니다. P2P의 대표적인 게임이라면 스타크래프트와 FPS게임들일 것입니다.
그러나 MMORPG 위주의 우리 나라에서는 꽤나 오랜 시간 P2P 기술이 홀대를 받았습니다.
보안에 취약하고 지금처럼 FPS가 유행하기 전까지는 P2P에 어울리는 게임이 없었기 때문입니다.

P2P의 장점은 로비를 제외하면 대용량 서버를 구축할 일이 없다는 것입니다.
단점은 클라이언트가 결국 서버와 클라이언트, 모두를 맡아야 하므로 네트워크 측면에서 만들기가 좀더 어렵다는 점입니다.
특히 P2P는 (플레이어수-1)((플레이어수-1)-1) /2 만큼 연결을 가져야 하므로 사용자가 늘어날때마다 디버깅이 힘들어집니다.
그리고 절대 잊을수 없는 문제가 있지요, 바로 NAT(Network Address Translator)이라고 불리는 공유기 문제입니다.
공유기 아래에 있는 Peer는 서버로 작동할 수 없습니다. 그래서 홀펀칭(hole punching)이라는 방법이 거론됩니다.

그러나 현실적으로 P2P만으로 게임 서비스를 만들기는 불가능합니다.
친구들을 모으고 채팅을 하며 어떤 방이 있는지 목록을 보기 위해서는 반드시 중앙에 서버가 있어야 합니다.
스타크래프트로 치면 바로 배틀넷(battle.net)이죠.

구분	장단점	주 프로토콜	게임 스타일
C/S	장점 : 보안에 유리 단점 : 높은 트래픽, 대용량 서버 기술 필요	TCP가 주로 사용되나 UDP도 사용	온라인 게임
P2P	장점 : 대용량서버 필요없음 단점 : 복잡성 증가, NAT 홀펀칭 필요	서버연결은 TCP, P2P에는 UDP가 주로 사용	네트워크 게임

<표1. C/S와 P2P 정리>

2. 네트워크 아키텍쳐의 실전 사례 분석

오래 전부터 네트워크를 분석하는 툴은 많았습니다.
기본 프로그램인 netstat도 훌륭한 도구이며(그 유명한 TCP/IP Illustrated 도 netstat로 실습하고 있습니다.)
약간의 관심만 가진다면 어떤 유명 게임이라도 클라이언트 상에서 어떤 과정을 거치는지 쉽게 확인할수 있습니다.
악용하지 않는다면 정말 좋은 공부가 됩니다.

이런 도구들이 있는데 유명 게임들의 네트워크 아키텍쳐를 전혀 모른다는 말은 개발자로써 관심이 없다는 말일 겁니다.
가끔 면접 볼때 무슨 게임에 몇년을 투자했다는 열정에 대한 자랑을 듣지만,
그 게임의 라이팅이나 네트워크를 짐작도 못하고 있으면 공돌이로썬 안타깝게 느껴집니다.

이 강좌에서는 비쥬얼스튜디오 이외에 앞으로 두가지 툴을 자주 쓰겠습니다.

2.1 C/S 모델
여기서 말하고픈 것은 C/S 아키텍쳐라도 절대로 서버 1대로만 접속하지 않는다는 점입니다.
MMORPG도 그 수많은 종류만큼 다양한 네트워크 아키텍쳐가 있습니다만, 간단한 카드류 게임으로 서버에 어떻게 접속하는지 보겠습니다.

이렇듯 C/S 모델이라도 최소한 두개의 서버를 번갈아 접속했다는 사실을 알수 있습니다.
그리고 TCP 이외에 UDP도 사용하고 있고요.
UDP는 연결지향이 아니니까 책에서 본대로 접속은 이뤄지지 않았습니다.

물론 서버는 이 두개 뿐만이 아닙니다.
직접 해보시면 서버 주소가 다를 것이고 테스트해볼때마다 다를 수도 있습니다.
이 말은 실제 각 로비서버와 각 게임서버는 여러 대가 있다는 의미입니다.
그리고 다른 서버로 접속했다 하더라도 같은 방에 있어야 합니다.

이를 위해서는

라는 결론이 나옵니다. 그 구조를 클라이언트에서 알수는 없습니다만, 아키텍쳐는 나온 것이죠.
이러한 유추를 통해 각기 다른 월드나 지역으로 구분하는데도 유용하게 사용할수 있습니다.

2.2 P2P 모델
P2P의 대표 모델인 스타크래프트 배틀넷을 분석해보죠.
스타크래프트의 P2P 모델은 DirectPlay의 P2P 모델과 일치합니다.
DirectPlay를 그대로 가져다 쓴 것이라 여겨집니다.

P2P에서는 크게 자신이 세션(방)을 만드는 것과 다른 사람이 만든 세션을 검색해서 들어가는 두가지로 나뉩니다.
각 단계에서 소켓에서는 어떤 함수가 불려지는지 정리해보지요.

1) 내가 방을 만들어 접속하는 경우
1-1) TCP 소켓 생성

pSocket->Create(TCP); 와 같은 형태로 함수가 호출될 겁니다.

1-2) Connect()

버전업 체크 서버와 버전을 확인을 한후 로긴을 합니다.
이때 pSocket->Connect(배틀넷, 스타크래프트_확장팩); 형식으로 접속을 하게 됩니다.

1-3) recv()

배틀넷 서버에 접속했습니다.
recv() 함수가 작동되며 공지사항이 날라옵니다.

1-4) 로컬에 서버 소켓 생성

세션이 만들어졌습니다.
이때가 무척 중요합니다.
내가 세션을 만드는 것도 중요하지만 다른 유저들이 내가 만든 방을 검색하기 위해서
배틀넷 서버에게 내 세션의 정보를 알려줘야 합니다.
가장 중요한 것은 "서버인 나의 IP"입니다.

1-5) 세션 호스트로써 게임 시작
게임을 시작합니다.
이때 배틀넷과 접속을 끊습니다.
P2P답게 다른 유저들과 접속이 이뤄지고 있을 뿐 배틀넷과의 접속은 의미가 없기 때문이죠.

만약 세션 호스트(방장)이 게임에서 나가게 되면 세션 마이그레이션(session migration)이라는 과정을 거치며
P2P 세션 호스트의 자리를 다른 사용자에게 물려주게 됩니다.
안정적으로 이것을 수행하는 것이 꽤나 난이도 있는 일이며 홀펀칭과 함께 P2P 라이브러리가 해주는 중요한 역활입니다.
스타크래프트에서 일반 유저보다 방장이 나갈때 잠시 랙이 걸리는 이유입니다.

1-6) P2P close(), 배틀넷 connect()
방을 나간 사람은 P2P 세션에서 나가며 다시 배틀넷에 Connect를 하게 됩니다.
이때 이겼다, 졌다의 정보를 갖고 배틀넷에 send()를 합니다.
이때가 P2P가 보안에 취약할 때입니다. 실제 이겼는지 졌는지 배틀넷은 모릅니다.
져놓고서 이겼다는 패킷을 날려도 배틀넷은 알지 못합니다.

2) 다른 사람의 만든 방에 접속할 경우
2-1) 세션 목록 recv()
1-3) 까지는 똑같습니다.
가장 중요한 것은 배틀넷이 현재 접속을 요청하는 세션 목록을 나타내는 것입니다.

2-2) 세션에 참여 P2P connect
배틀넷과 접속을 끊고 해당 세션 호스트의 IP로 접속을 하게 됩니다.

2-3) 게임 시작
세션 호스트라는 것이 아니면 네트워크 상으로는 똑같습니다.


2-4) P2P close(), 배틀넷 connect()
게임을 나가게 되면 P2P 세션을 닫고 배틀넷으로 접속합니다.
이 역시 1-6)과 같습니다.

3. 홀펀칭
P2P는 세션 마이그레이션 이외에도 NAT이 가장 골치꺼리입니다.
NAT 뒤에 있는 IP는 실제 IP가 아니기 때문에 밖에서 들어올 수 없는 것이죠.
공유기에 따라 특정 IP를 밖으로 노출 시키는 경우도 있고 아닌 경우도 있습니다.
어찌되었건 게임 서비스를 하는 입장에서는 NAT 특성에 관계없이 연결을 만들어줘야 합니다.

홀펀칭 역시 제 블로그(http://rhea.pe.kr/)에서도 2-1 편으로 다시 정리하겠습니다.
UDP 예제도 이번 포스트 소스로 넣어야겠군요...

자, 이번 포스트를 통해 소켓 사용법 이외에 네트워크 게임 개발자로써 고민해야할 1차적인 아키텍쳐를 이야기해봤습니다.
강조하고픈 것은 아키텍쳐에 게임을 맞추지 말고,
게임에 따라 유연한 아키텍쳐를 생각해내고 업데이트에 따라 유연하고 쉽게 바뀔 수 있는 자세를 가져야 한다는 것입니다.
좋아하는 게임이 있으면 어떤 네트워크 아키텍쳐를 갖고 있는지 최대한 유추해보시길 바랍니다.
그리고 PC게임 뿐만 아니라 스마트폰 게임이나 콘솔게임기를 추적해보는 것도 좋은 공부가 됩니다.

다음 시간에는 서버와 절대로 떼어놓을 수 없는 Database를 살펴보겠습니다.
아직도 게임을 만들 시기는 아닙니다.

 내용은 맘대로 퍼갈수 있지만 동의없는 수정은 안되며 출처(http://www.gamedevforever.com/ , http://rhea.pe.kr/ )를 명시해주세요.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

얼마전 mongoDB를 좀 갖고 놀았다.

DBA는 DB 저장 프로시져가 당연히 첫번째 관심사항이겠지만
서버 개발자의 경우 DB와 연결하는 드라이버가 첫번째 관심사항이다.
당연히 개발자답게 Windows용 C++ Driver부터 빌드하였다.
소문대로 mongoDB 빌드는 무척 더러웠다.
mongoDB 소스를 갖고 Windows용 C++ 드라이버를 빌드한다는 것이 좀 이해가 안된다.

그리고 내린 결론은...
Windows 서버에서는 C++로 mongoDB 서버를 짜지 말자는 것이다.
추천언어는 C#.

이런 결정이 내려진 이유는...

서버상에서 가장 큰 이유는 물론 두번째 항목이다.
boost 1.45에서 interface가 많이 바뀌었는데 mongoDB만으로 위해서 boost 1.42 를 따로 관리하고 빌드시 참조해야 한다는게 말도 안된다.
일괄빌드에 치명적인 문제를 안긴다. 소위 말하는 빌드비용의 증가 문제가 따라온다.

그래서 C++은 포기했다.
아니 애시당초 이렇게 복잡한 빌드 방법이라니 mongoDB는 Windows에서 C++로 쓰지 말라는 말같다. ㄴㅁ...

기왕 좀 삽질한 거, 서비스로 드라이버인 mongoclient.lib를 포스트에 올려드리고 싶지만,
용량이 무려 150 메가 이상이라 차마 올려드리진 못하겠다.

대신 mongoDB 드라이버 빌드팁을 적어본다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

1. 윈속의 역사
이미 게임을 하나 운영하고 있는 곳이라면 많은 것이 갖춰져 있습니다.
개발자 이외에도 DB, 서버, 패치 시스템, 그리고 그것을 돌려주는 여러 DBA, SE분들이 있습니다.
그러나 아무 것도 없는 곳에서 새로 온라인/네트워크 게임을 만든다면 맨땅에 헤딩을 해야 합니다.

우선 기획서가 나오고 DB라던가 여러 가지 인프라들이 먼저 있어야할 것이지만,
가장 단순하게 윈도우 서버와 클라이언트부터 만든다고 가정합시다.
자, 그럼 서버는 어떻게 만들어야 할까요?
서버를 만들기 전에 서버와 클라이언트에는 어떤 "Winsock Model"을 사용할런지부터 결정해야 합니다.

원래 소켓은 Windows 운영체제가 아니라 BSD UNIX에서 먼저 만들어졌습니다.
그래서 초창기 윈도우 3.1 같은 경우에는 소켓(http://www.joinc.co.kr/modules/moniwiki/wiki.php/man/12/BSD%20socket)
이 아예 존재하지 않았습니다.

이는 단순 소켓 지원 여부를 떠나 당시 마이크로소프트(앞으로 MS)의 중요한 의사 표방이기도 합니다.
소켓은 TCP/IP, UDP를 위한 라이브러리이고 TCP/IP, UDP같은 프로토콜은 바로 인터넷의 기반이 되는 프로토콜들이죠. 모든 것을 집어삼킨 HTTP 역시 TCP/IP 80번 포트를 이용한 텍스트기반 프로토콜 아니겠습니까?

다시 말해, MS는 현재의 인터넷이 이리 사용될지 몰랐습니다, 무려 90년대 중반까지도요!
MS는 소켓과 TCP/IP가 아닌 자신들의 프로토콜로 MS-Network라는 현재의 인터넷과 비슷무리하지만 다른 개념을 만들고 싶었습니다.

그 망상은 Windows 2000 이 등장하면서 공식적으로 사라졌는데 \\로 접근하던 다른 PC접근과 네트워크 공유를 NetBIOS(NetBIEU) 설치 없이 TCP만 설치하면 되도록한 것이 그 증거(?)라고 볼수 있습니다. 정확하게 말하면 NetBIOS over TCP/IP 이란 개념인데 아뭏든 90년대에도 MS는 인터넷도, TCP도, BSD 소켓도 반대! 그냥 MS껄로 다 정ㅋ벅ㅋ할꺼야!!였었습니다.

....................




...........





.....


..


그러나 어쩌겠습니까?
모두가 알다시피 인터넷(다시 말해 TCP/IP과 그것을 쓰기 위한 BSD Sockets)이 대세가 되었는데요.

할수 없이, MS는 BSD 소켓과 똑같은 윈도우용 소켓 라이브러리를 제작합니다.
BSD 소켓 4.3에 기반해 1993년 WinNT 3.51과 함께 Winsock 1.1을 공개합니다.
즉, Winsock은 WINdows + SOCKet의 약자지요.

이 윈속 1.1은 놀랄만큼 BSD 소켓과 동일합니다.
고인이신 스티븐슨의 UNIX Network Programming에 있는 소스 대부분이 헤더 파일만 약간 바꾸면 그대로 돌아갈 정도입니다.

이는 다이렉트X 초창기의 모습과 유사합니다. DOS 게임 개발자들에게 복잡한 Windows Procedure와 콜백을 잘 몰라도 DOS 게임을 그대로 포팅할수 있도록 한 배려와 비슷한 모습입니다.

하지만 이때까지도 MS는 TCP/IP의 가능성을 잘 몰랐습니다.
...그래서 Winsock 1.1을 사용하는 Windows 서버는 ....상당히 구렸습니다.
윈도우는 서버로는 절대 안된다는 말이 이때부터 흘러나왔죠.

그러나 1995년 WinNT 4.0의 등장과 함께 선보인 Winsock 2.0부터 상황은 달라지기 시작합니다.
아키텍쳐부터 싹 달라졌습니다.
1.0과의 호환성은 100% 유지하면서 Windows에 최적화된 진짜 Winsock이 등장한 것입니다.
(달라진 아키텍쳐로 "개인방화벽" 프로그램이 만들어질 수 있었습니다. 자세한건 "SPI"로 검색을 ^^)

현재 우리가 주력으로 사용하는 Winsock은 16비트 모드가 제거되어 1996년에 발표된 2,2를 사용하고 있으며
Win8이 등장할때 Winsock에 Registered IO extensions 이 추가된다고 하는데 간만에 Winsock에 새로운 기능이 추가되는 것이라 기대가 큽니다.

2. 윈속 모델

드디어 오늘 기초의 핵심인 윈속 모델 이야기를 하겠습니다.
안타깝게도 윈속이 버전업이 되었다고 해서 윈속의 성능이 공짜로 올라가는 것은 아닙니다.

네트워크 프로그래밍에서 첫쨰 난관은 언제 "1) 누가 서버에게 Connect를 해 올줄 모른다"는 점입니다. 그리고 이때 클라이언트가 Connect를 해오는 순간, 아주 빠르게 accpet()를 해줘야 합니다. 접속이 수천개가 되면 이 작업 역시 딜레이가 걸리고 컨텍스트 스위칭이 걸립니다.
그런 다음, 일단 양쪽이 연결이 되면 "2) 서버든 클라든 언제 상대방의 메시지를 듣기 위해 recv()를 해야할지 모른다"는 점입니다(아시겠지만 연결을 끊는 close() 역시 사실은 상대방에게는 recv()입니다.)

이미지 출처 : http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=%2Frzab6%2Frzab6connectionor.htm

사실 게임 클라이언트처럼 소켓 5개 정도에서는 큰 차이가 없습니다만,
서버는 한 프로세스가 수백~수천개의 접속을 관리해야 합니다.
이를 위해 단일 thread를 돌리는 방법으로는 고작 수십명이면 금방 한계에 찹니다.
아무리 서버장비가 좋아도 똑같습니다.
왜 단일 thread는 안될까요?
thread라는게 마법은 아닙니다. 단순히 CPU 한계치까지 일을 시킬 뿐, 계속 루프를 돌며 찌질하게 검사하는 역활 밖에 할 수 없습니다.

좋은 서버란 가장 적은 thread와 CPU를 사용해 가장 많은 접속을 빠르게 처리해줄수 있어야 하며 이를 위해 두가지 개념을 먼저 알아야 합니다.

우선 비동기(asynchronous )라는 개념이 들어갑니다.
쉽게 말해 계속 루프를 돌며 검사하는게 아니라 클라이언트에게 접속요청이 왔거나 메시지가 왔을때에만
해당 소켓에게 알맞은 작업을 해주는 것입니다.

그래서 비동기 Winsock을 위해 4가지 모델이 고려되었습니다.

...는 아니고...

모델명	특징	기타
Window Message Select (WSAAsyncSelect)	소켓 이벤트를 윈도우 메시지를 이용해 알려준다.	윈도우 메시지를 이용하므로 반드시 윈도우가 생성되어야 하며 MFC의 CSocket 클래스가 바로 이 모델.
Kernel Event Select (WSAEventSelect)	소켓 이벤트를 커널 이벤트로 알려준다.	한 객체당 최대 64개의 이벤트 밖에 못쓰므로 서버로 쓰기 위해서는 코드가 쓸때없이 복잡해짐.
Overlapped I/O (Overlapped)	소켓 이벤트를 비동기 읽기/쓰기를 위한 오버랩 구조체를 이용해 알려준다.	위의 둘과 달리 Overlapped와 IOCP는 Win95, 98에서는 안됩니다. 이 기법은 파일에 비동기로 읽기쓰기를 같이 하기 위함이었으나 소켓이든 파일이든 둘다 같은 HANDLE 이잖아요? ^^ 역시 MS의 꽁수의 결정체라 불릴만 합니다.
Overlapped I/O + IOCP (IOCP)	위의 방식에 더해 커널 큐잉을 통해 소켓 이벤트를 통보받는다.	사실상 윈됴에서 서버는 이넘으로 정해져있다. C#에서 비동기 선언해도 IOCP가 만들어진다. 결론은 서버는 IOCP가 정답입니다!

...이런 모델들입니다.


두번째는 넌블로킹(non blocking)개념입니다.
단일 thread가 아닌 비동기 서버를 짰다고 합시다.
이때 어떤 이벤트가 일어나면 비동기로 OS가 서버에게 알려줍니다.
그러나 send(), recv() 같은 함수는 블로킹(blocking)함수 입니다.
send(), recv() 작업이 끝날 때까지 서버 프로그램은 다음 일을 할수 없습니다.
이때 WSASend(), WSARecv같은 넌블로킹 함수로 대체한다면, 작업이 끝나기 전에 서버는 다음 작업으로 진행될 수 있습니다.

아마 넌블러킹 함수는 네트워크 프로그래밍에서 처음 보신 분들도 있을 것이지만,
수많은 I/O관련 함수들의 고급은 전부 넌블러킹으로 흘러가게 됩니다.
넌블러킹 함수는 어쩔수 없이 Callback 함수가 반드시 뒤따라갑니다.
그래서 처음 접하면 조금 어렵습니다............................................가 아니라 실은 많이 어렵습니다,
거기에 Overlapped나 IOCP같은 비동기 통보까지 더해지면 아주 복잡해집니다.

다행히 클라이언트에서 주로 쓰이는 WSAAsyncSelect 모델과 WSAEventSelect 모델에서는 넌블로킹이 그리 중요한 개념은 아닙니다. 유선 인터넷이 하도 빨라서요...
클라이언트에서 넌블로킹을 잘못 쓰면 소켓 응답 오기 전까지 게임 프로그램 자체가 위험해질수도 있고
그 사이 화면 UI처리같은 다른 할일들도 신경을 써야 합니다(<-이거 은근 고급 토픽입니다.).

3. 오늘의 소스
오늘의 소스는 간단한 클라이언트/서버 소스입니다.
클라이언트는 MFC로 만들었고 Winsock Model 역시 CSocket, 즉 윈도우 메시지 방식입니다.
서버는 boost::asio로 짰습니다. 기본 TCP 서버를 그대로 썼습니다.
단, 한 파일로 설명된 소스를 보기 좋게 클래스별로 나눠놨습니다.
이 정도면 네트워크 프로그래밍에 익숙하지 못한 초보분이라도 약간의 노력이면 다음 시간부터 따라오실수 있을 것입니다.

이 간단한 프로그램들로 네트워크 게임을 위한 첫 삽질이 시작될 것입니다.

4. 더 생각해볼꺼리

내용은 맘대로 퍼갈수 있지만 동의없는 수정은 안되며 출처(http://www.gamedevforever.com/ , http://rhea.pe.kr/ )를 명시해주세요.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

게임데브 포에버에 참가합니다.
포프님이 주관하는 게임데브 포에버에 저는 4일과 19일에 포스트를 올리게 되었습니다.

서버답게 네트워크 게임 튜터리얼를 올리려고 합니다.
그런데 세가지 난제들이 생기더군요.


이런 난제들로 어떻게 내용을 적어갈까 고민중입니다.
등의 방법으로 해결할려 합니다.

서버는 학습용이란 특징 때문에 굳히 IOCP나 ASIO같이 비동기로 만들어 디버깅을 힘들게 하지는 않겠습니다.
단순한 형태로 소켓 서버를 만들어 프로토콜과 게임 제작 위주로 가볼려고 합니다.
어느 정도가 되면 이 프로토콜과 유저 관리를 그대로 두고, 서버 I/O만 바꾸면 되니까요.
여기서 문제는 비동기로 만들지 않으면 프로토콜 헤더에서 패킷 사이즈의 의미가 왕창 사라져버린다...인데 좀 난감합니다. >_<

클라이언트 역시 좀 골치아프네요... .
그냥 간단히 MFC로 만들어도 프로토콜을 보는 Dummy 역활을 충분히 할테지만.
FPS(Frame Per Second) 개념이 없어지니 FPS 맞물린 네트워크 동기화에 대한 설명이 참 힘들 것 같습니다.
계속 클리앙이나 김학규님 홈페이지에서 링크 당해 키보드 워리어들에게 욕먹고 있는(^^)
디아2의 네트워크 개념을 설명할수가 없으니까요(학규님이 보시면 머라고 그러실까...).

그래서 일단 일반 윈도우가 아닌 DirectDraw나 Direct3D로 FPS 갱신은 시켜야 할 듯 합니다.
그런데 또 이게 처음부터 나가면 이번에는 클라이언트 디버깅이 힘들다는 말을 들을 것 같아 또 고민되네요.
클라이언트에도 쓰레드나 이벤트 동기화 객체들이 붙어야할 것 같고요... .
이러니 분량이 참 많아져 버리는데,
원래 오래 전부터 하기로 한거니까 그래도 해야할 듯 합니다.

그럼 시기가 되면 게임데브 포에버에서 뵈요~

추가) 그래도 비동기로 하드 트레이닝 하자라는 의견이 있어 비동기 생각중입니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

최근 개발자를 소개해달라는 요청들을 많이 받습니다.
돌이켜보면 정작 저 자신도 항상 사람을 구하기가 힘들었고 지금 역시 마찬가지입니다.

그와 동시에 몇년전부터 불어닥친 IT/게임쪽 구인난에 대한 생각을 적어봅니다.

제가 신입일때, 널린게 개발자였습니다.
프로그래머, 아티스트, 웹디자이너, 웹프로그래머, DBA, 이런 기획자, 저런 기획자... 정말 많았습니다.
90년대 후반, 2000년도 초반 이야기입니다.

그당시 그렇게 "IT 개발자"라고 칭하던 사람들이 많았던 이유는
김대중 정부시절, IT 개발자 양산 정책에 의해 짧게는 한달, 길게는 6개월~1년 정도의 IT 교육을 받은 사람들이 대거 양성되었고
시장에 많이 풀렸었습니다.
그때는, 20대 여성이라면 대부분 웹프로그래머나 웹디자이너일 정도였습니다.
할 것 없으면 정부지원금받고 개발자 교육 몇달 듣고 개발자라고 이력서를 썼습니다.

그리고 10여년이 흘렀습니다...

그럼 지금 싯점에 왜 개발자가 그렇게 없는 것일까요?


보다 더 정확하고 많은 이유가 있겠지만,
제 개인적인 경험은 위의 네가지 이유에서 파생된다고 생각합니다.

그리고 현재는 아주 재미있는 모습이 보이는데,
저 포함하여 매니져라 할수 있는 직급인 팀장/실장/이사급이 현역 코딩을 하는 경향이 짙어졌다는 것입니다.

회사의 직급 변화가 인력수급을 따라가지 못해 신기한 현상이 일어난 것입니다.
사실 하는 일로 보면 리드 프로그래머입니다. 그러나 팀을 관리할 매니져 역활도 계속 할수 밖에 없습니다.
이쯤되면 리더급 프로그래머와 프로젝트 매니져를 나누어야 하는데
이 둘다 부족한 실정이니, 매니징도 하고 코딩도 해야하는 힘든 팀장/실장/이사님들이 늘어난 것입니다.

이것은 아주 긍정적인 방향이라고 생각합니다.
앞으로는 나이/경력에 무관하게 리드 프로그래머와 프로젝트 매니져가 각각 독립적으로 존재하고
프로젝트 매니져가 절대로 절대로 절대로 리드 프로그래머의 상관이 되지 않을 것입니다.
필요에 따라 필요한 직군과 사람을 두는 것입니다.
원조 IT인 미국처럼요.

그리고 가장 하고 싶은 결론을 적어야겠군요.

자, 개발자를 구하기 힘든데, 개발자더 많아져야 하는가? 라는 점입니다.

Rhea의 생각은 절대 아니다!! 입니다.
지지난 정권때처럼 강제로 국비를 쏟아부어 잉여->개발자로 만들 필요는 절대로 없습니다.
이는 생태계를 파괴시키는 짓이며 이미 증명되었습니다.

제 생각으로는 지금 IT 산업의 사이즈와 개발자의 수가 딱 맞습니다.

현재 돌아가는 IT 산업 전반을 볼때 개발자가 더 있을 필요는 없습니다.
늘어나는 정년과 평균수명을 생각해보면, 합리적인 일정 속에 현재의 개발자들을 잘 성장시키면 산업과 고용 생태계는 문제없이 굴러갑니다.

10여년 전처럼, 개발자는 구인광고만 내면 우루루 달라붙는 시대가 아니기 때문에 합리적으로 프로젝트를 잘 운영해야 합니다.
그리고 그만큼 가치있게 대우를 해줘야 합니다.

이는 취업을 원하는 구직자도 마찬가지인데요, 제대로 된 실력이 아니면 없느니만 못한 경우가 꽤나 많습니다.
지원하고자 하는 업무에 맞는 실력과 능력이 반드시 필요합니다.
IT개발은 사실 상당히 전문직입니다. 의사/법조계에 꿀리지 않게 전문분야입니다.
이런 분야에 이력서 한장 잘써서 들어가는 것이 아니기 때문입니다.

제목은 "그많던 개발자들은 다 어디로 갔을까?"였지만
결론은 "원래 없었고 이제 겨우 고용 생태계가 안정되었다."로 적게되는군요.

여기에 더 늘어난 20대때의 교육기간, 늦춰진 첫 직장잡는 나이...등도 추가되겠지만 다음 기회의 떡밥으로 남겨둘까 합니다.
한가지만 더하만 줄어든 군대 기간은 별 영향이 없는 것 같습니다. 잉여 불변의 법칙이 여기서도 통용되는 것 같습니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

...등의 근거 있는 소문이 가득한 시크릿박스(Secret Box).
8월 1일에는 안드로이드 버전이 티스토어에서 선보였고
http://www.tstore.co.kr/userpoc/game/viewProduct.omp?insDpCatNo=DP03004&insProdId=0000252150&prodGrdCd=PD004401&t_top=DP000503
8월 5일에는 한국 앱스토어에도 아이폰 버전이 올라왔다.
http://itunes.apple.com/kr/app/id453706647?mt=8

밖에서 어떻게 보이든 나에게 가장 중요한 점은 에픽하츠에 이어 두번째로 선보이는 Game4U 플랫폼 프로젝트라는 것과,
별도의 서버 없이 플랫폼 서버로만 구성된 프로젝트라는 점이다.

기획은 작년 11월 중에 했고,
처음 예정은 한달만에 만들어 금방 올리자는 것이 목표였다.
그것이 물론 반년을 넘겨 8월에 출시된건 "어른들의 사정"이라고만 밝혀두겠다.

Game4U 플랫폼을 만들때 가장 신경 쓴 부분은 플랫폼과 컨텐츠의 구분이었다.
너무나 당연한 이야기지만 이 신념은 설계부터 각 부분의 서버와 컴포넌트들에게까지 철저하게 지켜졌었고
지금도 굳건하다는 점이 중요하다.

이 신념어린 설계는 어느 정도 플랫폼 완성을 보이자 스스로 새로운 가능성을 만들어 주었다.
바로 플랫폼만으로의 서비스이다.
Game4U 기본 플랫폼을 살짝 변형시키면 소셜 앱을 만드는 것은 야동보며 휴지 찾듯 자연스럽고 쉬운 일이었던 것이다.

또한 원래 그것이 Game4U Open API의 목적이기도 했다. Game4U는 현재 트위터 이상의 Open API들을 담고 있다.
API 갯수가 많다고 반드시 좋은건 아니겠지만, SNG 플랫폼으로써 개발자의 Needs는 최대한 충족시켰다고 생각한다.
그렇게 시크릿박스는 하나의 완벽한 서비스이면서 "Game4U를 이용한 소셜 데모 프로젝트"의 역활을 보여주었다.

이런 발상은 전에 몸담았던 피망과 세이클럽이 여전히 내 머리 속에 남아있는 탓이기도 했다.
뭔말인고 하니, 피망의 게임들이 컨텐츠라고 한다면, 플랫폼은 다름아닌 세이클럽이었다.


즉, 게임을 돌려주는 플랫폼만으로도 무언가 서비스를 할수 있다는 생각이 많이 들었고
그것이 Game4U를 만드는 동안, 내 잠재의식 속에 존재하고 있었음이 분명하다.
소셜에서 게임이 아니라 게임에서 소셜로 반대로 진행한 점이 재밌다.

시크릿박스는 소셜 목표가 Game4U와는 좀 다르다.
Game4U는 같은 게임을 하고 있는 사람을 공유하고, 친구가 하고 있는 게임을 공유하는게 목적이다.
시크릿박스는 LBS 기반으로 메시지(박스)를 공유해 새로운 친구를 사귀는 것이 목적이다.

초기 프로젝트명은 할인의 달인에 이은 "삽질의 달인"

에픽하츠 내에서 시크릿박스 친구를 보여줌ㅋ

혹자는 마마마 전체 캐릭터를 위해 프로필 이미지를 5개 만들었냐고 묻지만...낭설이다.

에픽하츠에서의 Game4U

그러나 어디에서 친구를 사귀더라도 Game4U라는 플랫폼 내에서 친구 네트워크는 함께 사용한다.
너무나 당연한 것이지만 국내에서 만들어진 플랫폼 중, 아직 두개 이상의 게임이 지원되는 플랫폼은 내가 알기론 Game4U 뿐이다.
다른 게임들도 준비 중이지만 Open API 의 위력으로 아주 쉽게 붙이고 이식되고 있는 중이다.
물론 아이폰/안드로이드 양쪽에서.
시크릿박스는 아직 어떤 홍보나 이벤트를 전혀 붙이지 않아 사용자는 현재 그리 많지는 않다.
(그만큼 레벨 올리기 좋고 친목 쩔고 있음.)
사실 지금은 베타 기간이라 봐도 무방한데 오늘도 서버 정기점검을 했고,
소중한 건의와 원래 계획들로 꾸준한 클라이언트 업데이트를 거치면 보다 나은 모습이 될 것이다.

개발실장의 삶의 질을 한방에 지옥으로 날려보낸 카르마만큼, 이 앱이 많은 사람들에게 좋은 모습으로 애용되었으면 한다.
그리고 부족한 인원으로 운영까지 뛰고 있는데 이상한 뻘짓은 하지 말았으면 한다.
음란성 멘트로 여성분들을 탈퇴시키면 반드시 보복하겠다.
한 서비스에 변태는 나 하나로 충분하다!!

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

사람들이 왜 스마트폰으로 개발 무대를 옮기는지에 대한 분석은 참 많다.
스톰님의 분석(http://sstorm.egloos.com/5516226)과 같이 손익분기점에 대한 논의가 분석의 중심이겠지만,
난 개발자라 개발자의 미시적인 시선을 적어본다.

내가 스마트폰으로 무대를 옮긴 이유는,
의 세가지 조건 때문이었고 이 세가지 조건만 있으면 PC와 모든 환경이 같아진다.

언제나처럼 하나하나 살펴보자. ...정말이지 난 세가지 조건이나 이유를 상당히 좋아하는 듯 하다.

1) 셰이더
셰이더가 PC개발자들에게도 다가온 것은 MS가 XBOX를 만들며 다이렉트X 8.0에 셰이더를 공개한게 처음이었을 것이다.
그전까지 셰이더는 그야말로 콘솔 게임기 개발자들만의 독특한 기술이었고,
PC게임 개발자들에게는 접근할 방법이 없었다.
콘솔게임기 잡지에서 극찬할때 주로 사용하는 멘트인,
"기기의 성능을 120% 활용한~"이란 말은 결국은 셰이더를 잘 썼다라는 말이다.

나머지 개발자가 할수 있는 것은 텍스쳐 로딩 방식과 CD/DVD 파일 구조 및 캐쉬 이야기이다.
이럴땐 보통 "빠른 로딩과 쾌적한 플레이를 제공한다~"라고 기사 쓴다. 딴지 걸지말길, 나도 게임스팟 필자였다.

아뭏든 게임기의 전유물이었던 셰이더는 XBOX 개발을 위해 다이렉트X 8.0이 만들어지며 PC개발자들에게 선보이게 되었고 꾸준한 개선을 통해 현재에 이르렀다.

아이폰과 안드로이드도 OpenGL을 이용하므로 당연히 셰이더(픽셀셰이더)가 된다.
이는 언젠가 스마트폰에서 실시간 시차매핑이 등장하리란 기대를 증폭시켜줬고 결국 인피니티 블레이드가 선을 보이게 되었다. 지극히 당연한 결과다.

하지만 셰이더의 힘은 단순히 좋은 그래픽에서 끝나지 않는다. 이를 통해 할 수 있는 것들은 무궁무진하니까.
다만 셰이더가 작동할 메모리가 어디인지 어떤 것인지 안드로이드는 하드웨어에 따라 걷잡을 수 없다.
그래서 안드로이드에서 괜찮은 3D 그래픽 뽑기가 아주 힘들지만, 아이폰이라면 정해진 스펙이 있다.
오오미~ 역시 아이폰은 게임기랑께~~



유튜브를 뒤져보면 아이폰 셰이더 데모는 참 많다.

결국 당장은 아니더라도 약간의 시간이 더 흘러준다면
3D 그래픽에 대한 하드웨어 준비와 엔진들은 쏟아져 나와줄 것이라 예상했고, 그렇게 흘러가고 있다.

우선 그래픽에 대한 기대치와 안정은 확보가 된 셈이었다.


2) 다중소켓
수많은 PC 온라인/네트워크 게임들은 소켓을 하나 이상 사용한다.
당장 아무 게임이나 하나 실행시켜놓고 네트워크를 검사해보면 생각보다 훨씬 많은 소켓이 접속 중이란것을 알수 있다.
일차적으로 이것만 잘 분석해도 내가 하는 게임의 서버 구성을 유추할 수 있다.

이는 온라인 서비스에서 무척이나 중요한 사항이다.
만약 클라이언트가 소켓을 하나 밖에 열지 못한다면 서버의 구성은 접속서버 하나만 물고 있어야 한다.
채팅서버, 로비서버, 게임서버가 따로 존재하더라도 이 세 서버를 묶은 하나의 서버를 개발하고 이것하고만 통신해야 한다.
전체를 놓고 봤을때 과연 둘중 어느 것이 더 쾌적한 구조일까?
클라이언트만 본다면 하나의 서버와 통신하는게 더 편하게 느껴지겠지만, 클라이언트에도 두명 이상의 개발자가 붙게 되고,
서비스가 커지면 단일 소켓은 참 힘들어진다.

그리고 다중소켓을 사용하더라도 스마트폰의 배터리를 더 많이 소모시키지는 않는다.
전통적인 TCP/IP에서 alive 체크를 위해 패킷이 좀더 사용되겠지만 이건 크지 않다.
실제 소켓을 하나만 사용하더라도 send/recv 데이터량에 의해 배터리의 차이가 나게 된다.


결과적으로 클라이언트가 여러 개의 소켓을 함께 쓸수 있으면,
PC 온라인 게임과 같은 서버 아키텍쳐를 만들수 있게 된다.

3) 웹브라우저
클라이언트가 웹브라우저를 내장했다는 말은 두가지 의미이다.
하나는 프로그램 내에서 웹브라우저를 내장하여 사용할 수 있다는 의미이고
두번째는 웹브라우저가 가진 HTTP 통신 함수, XML파서, JavaScript 런타임을 쓸수 있다는 의미가 된다.

우선 첫번째를 보자.
이미 많은 게임들은 알게 모르게 웹브라우저를 내장하고 있다.
공지사항, 도움말은 물론이고 아이템샵과 결제창에서 빠뜨릴 수 없는 것이 웹브라우저다.
(이는 게임 개발팀과 운영팀/빌링팀을 구분해 작업할 수 있게 해준다.)
그래서 한때 HTML 사이즈에 맞춰 동적 팝업창 만들기와 다이렉트3D 풀화면에서 웹브라우저를 임베딩하는 방법등이 클라이언트 개발자들 사이에 비기로 취급받기도 하였다.

이는 스마트폰에서도 마찬가지로 적용된다.
PC에서 그래왔던 것처럼 지금 대부분의 공지사항과 도움말은 웹브라우저로 작동된다. 아직은 PC처럼 웹창에서 결제를 하는 것이 보편화되어 있지 않은게 흠이다.

그래서 아이템샵에서는 아이템 리스트만 웹브라우저를 이용하고 실제 결제는 웹브라우저위에 앱의 버튼을 올려 결제를 유도시키는 방식이 주를 이루고 있다.

그러나 진짜 웹브라우저의 저력은 단순한 임베딩이 아니다.

HTTP 통신함수의 제공으로 수많은 SNG를 손쉽게 제작하도록 했으며
JavaScript 런타임으로 HTML/Javascript만으로 앱제작이 가능케했다.
따라서 퀵커넥트 아이폰이나 폰갭같은 하이브리드 앱 프로젝트들이 아이폰 등장 이후 얼마 되지 않아 선보이게 된 것이다.

최근에는 이런 프로젝트들이 더 많아졌는데 이런 추세를 보면 JAVA나 .NET Framework같은 것은 그야말로 인류를 대표하는 잘못된 삽질이 아닐까...하는 생각이 들때도 있다.

나는 케케묵은 바이너리 개발자라서 하이브리드 방식도 좋지만 그래도 역시 API를 직접 호출하는게 제일 좋다.
그러나 세상은 언제 어떻게 변할지 모르는 법이다.

결론적으로 스마트폰은 그래픽/네트워크/아키첵쳐가 PC의 그것과 같다.
기술이 같아면 아키텍쳐와 운영과 문화 역시 비슷해질 수밖에 없다.
그래서 나는 손익분기점 문제가 아닌, 월급받는 개발자로써 스마트폰으로 뛰어들었다.

그리고 역시...똑같았다.
다만 3G 환경이 엉망이 되었고 이슬이의 4G가 필요하다는 것만 빼면 말이다.

어쩌면 이 만화가 말하는 것이 폰 점유율 이야기가 아니라 지금 기술은 PC/Windows에서 시작되었다는 것이 아닐까?

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

오늘은 Game4U 7월 2차, 횟수로는 두번째 정기점검이다.
회원수에 관계없이, 규모에 관계없이 정기점검은 지난 일년 반동안 정말 뛰고 싶었던 행사(?)였다.
정기점검이야말로 서비스가 나가고 있다는 증거이고 온라인 게임 회사만의 규칙이기 때문이다.
즉, 빨리 Game4U를 선보이고 싶었고 원래 피처폰 게임 조직어었던 이곳을 빨리 온라인 조직으로 이끌고 싶었다.
온라인 게임 회사는 모든 스케쥴이 정기점검에 맞춰져 있다고 생각하면 된다.
간단하게 "정책결정->기회서 제작->리소스 제작->코딩->QA->정기점검을 통한 배포"가 한 사이클로 돌아간다.
한 정기점검에 늦게 되면 당연히 다음 정기점검 때 패치를 해야 하는 것이고.

정기점검은 기획자, 디자이너, 프로그래머, 그리고 QA들만의 일이 아니다.
가장 중요한 것은 "개발환경->QA환경->배포환경->실서버 배포"까지
유기적으로 돌아가는 내부 프로세스가 수행되어야 하는데
이 프로세스를 만들고 확립하고 원할하게 만들고 정기점검동안 관장하는 팀이 필요하다.
그리고 빠뜨릴 수 없는게 각 서버에 있는 binary를 동기화 시켜 개발환경부터 실서버까지 배포시키는 SE팀의 능력이다.
(SE는 단순히 OS 업데이트하고 서버 설치하는 일만 있는 것이 아니다.)
마지막으로 정기점검 프로세스는 각 회사마다 특징이 있지만
온라인 게임 하나를 올리는지, 크고 작은 게임 여러 개를 올리는지에 따라 프로세스도 많이 바뀐다.

지금은 Game4U라는 플랫폼과 에픽하츠 하나 뿐이지만, 이 모습은 게임 포탈을 염두에 두고 만든 모습이다.
앞으로 꾸준히 게임이 늘어날 것이므로 여러 개의 게임을 올리는 방향으로 프로세스를 만들었다.
오늘 정기점검은 무엇이 바뀔까?
우선 커뮤니케이션 서버의 유령사용자 현상을 없애고(채팅 좀 많이 해주세요~)
사용자 정보 변경 기능의 버그를 고쳤다.
가장 중요한 것은 7월중 배포한다고 약속했던 시크릿 박스를 위한 서버 프로토콜이 올라간다.
이제 일주일 정도 후면 우선 안드로이드에서 시크릿 박스란 앱을 볼수 있을 것이다.
게임은 아니지만 Game4U 커뮤니티를 더욱 강력하게 해줄 Base Platform 서비스로 무리가 없을 것이다.
다음 정기점검은 또 새로운 기능과 서비스를 위한, 혹은 새 게임을 위한 정기점검이 될 것 같다.

그래서 나는 정기점검이 즐겁다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

칭기스칸의 성공요인은 여러가지가 있을 것이다.
워낙 능력자니까 땅따먹기 성공한건 사실이고 몽골문화를 잘살린 부대편성과 작전은 당시 최강이었을 것이다.
여기서 우리는 징기스칸의 툴(Tool)을 생각해보자.

징기스칸은 몽골민족의 필수요소인 조랑말을 타고 달렸다.
식량은 육포와 치즈, 그리고 청국장이었다.

조랑말은 다리가 짧고 왜소했지만 강한 체력을 지녔고 조랑말과 함께 커온 몽골의 기병대를 당할 부대는 없었다.
또한 징기스칸의 부대는 말안장 속에 위에 언급한 식량을 넣고 다녔다.
치즈나 청국장인 이유가 말안장 속에 넣은 음식들이 저절로 발효되었기 때문이다.
사이즈가 작고 열량이 높은 음식들이었다. 보급부대 따윈 필요없었고 말을 달리며 식사까지 마쳤을 것이다.
스타크래프트로 말하지면 서플라이 디폿이 필요없는 종족이었다.

작고 기민한 팀이 가질수 있는 최고의 전략이었고 대제국들을 차례대로 박살낼수 있었다.
징기스칸의 이야기는 나베르에서도 잘 다루었으니 읽어볼만 하다.
http://navercast.naver.com/contents.nhn?contents_id=1824
이 조랑말들은 700여년 후, 아시아 대륙이 아닌 다른 대륙에서 경쟁을 하게 된다.
남극대륙에서 사모예드라는 북극개와 또다른 승부를 짓게 된 것이다.

1911년 영국의 스코트와 노르웨이의 아문센는 남극점 일빠를 위해 달린다.
여기서도 다른 점은 생각하지 말고 운송수단과 식량만을 생각해보자.

스코트의 툴은 칭기스칸이 애용했던 검증된 툴인 만주산 조랑말과 당시 최신형인 엔진으로 움직이는 썰매였다.
그리고 아문센이 선택한 툴은 에스키모들의 전통적인 솔루션인 사모예드가 이끄는 썰매였다.

대결은 누구나 아는대로 아문센의 승리로 끝났고 스코트 탐험대는 전원이 사망하였다.
(당시 영국의 언론플레이로 스코트 탐험대가 승부에는 졌지만 더 스타덤에 올랐다고 한다.
하지만 지금은 누구나 남극점 정ㅋ벅ㅋ은 아문센을 기억할 것이다.)
남극이라는 환경에서 스코트의 조랑말들은 무력하게 죽어갔으며 최신형인 엔진 썰매는 고장의 연속이었다.
한편 아문센의 개썰매는 북극에서와 마찬가지로 남극에서도 그 진가를 발휘하였다.
또한 썰매의 원동력인 개가 죽으면 그것을 다른 개와 자신들의 식량으로 썼다.
열심히 달리다가 쓰러진 썰매개지만, ......눈속에서 먹는 개장국은 정말 맛있었겠다.
이외에도 이 두 탐험대의 이야기는 철저한 준비성을 논할때 빠질수 없는 성공사례와 실패사례이다.
이건 나중에 Test Driven 개발을 이야기할때 따로 적어볼까 한다.

PC에서 흥했던 네트워크/온라인 게임의 시대가 점점 변하고 있다.
스마트 디바이스의 급부상으로 이 둘이 융합되면서 메인 개발툴과 개발방식과 솔루션이 달라지고 있다.
물론 PC 게임이 몰락한다는 말은 절대 아니다. 나 역시 언젠가 다시 PC나 콘솔용 MMO를 만들 것이다.
하지만 이전과 같은 전략과 개발은 아닐 것이다.
칭기스칸의 시대의 솔루션은 이미 증명되었고 이제는 남극점 정ㅋ벅ㅋ이 시작된 것이다,

그러나 본격적인 레이스가 언제부터 시작되었다고, 나는 벌써 스코트 탐험대와 같은 팀을 다수 목격할 수 있었다.
남극탐험에 만주산 조랑말과 모터 썰매를 가져갈지, 개썰매를 가져갈지는 잘 결정해야 한다.
조랑말로 개썰매를 끌게 하거나 사모예드에게 모터 스키를 끌게 하는 실수도 범하지 말아야 한다.

내가 지친 팀원을 잡아먹는다는 이야기도 결코 아니니 난독증을 앓고 있는 분은 착각하지 말길 바란다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

남들이 좋다고 말하는 이클립스이지만 예전에 잠깐 써봤더니 버그 투성이었다.
공짜인 티, 팍팍 낸다.
(이것이 좋은 툴이라고 하악하악 할수 밖에 없는 특정 영역 개발자들에게 급위로를 보낸다.)

안드로이드를 개발하다가 흔한 실수는 프로젝트 경로를 잘못 썼더니 무한 폴더가 생성되는 것일테다.
병1신같은 이클립스는 에러도 없이 쓰레드 무한으로 돌리며 무한 폴더를 생성한다.

그리고...이 폴더는... 260자 한계를 초월해 버린다면 지울수도 없다!
완전 해킹툴이다, 이클립스... 어떻게 한거지?
파워쉘로도 안되는데 이때는 Cygwin 이 정답이다.
Cygwin이 무엇인지는 전부다 알꺼고,
해당 드라이브를 cd 드라이브명: 해서 들어간후 cd로 폴더를 찾아 rm -rf 폴더명 으로 삭제해주자.

하다보니 안드로이드쪽 포스트를 연속 두개 올렸는데,
안드로이드 3,0부터라도 좀 제대로 된 개발환경이라는 소식을 듣고 싶다.
우리 팀원들이 불쌍하자나 ㅠㅠ

...창문에 끼인채 사과로 당하는, 안드로걸 능욕짤 그리고 싶다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.