사실 이런 구성이 된 건 예전에 Dell UltraSharp U2407 을 얻어서 사용했는데, 이게 맛이 가면서 삼성 SyncMaster 2343BWX (TN 패널) 을 받게 되어서 임. 이거 하나랑 17” 두 개 쓰다가 17” 하나를 동일한 23”로 바꿔서 현재까지의 상태가 된 것.

프로그래머는 막눈이라고 – 적어도 일단 나는 – 그냥 저냥 쓸만한 모니터 같긴 한데, 이젠 눈이 나빠서인지 삼성 2343BWX가지곤 오래 집중하기가 힘들더라. 그런 의미에서 삼성 SyncMaster 2343 BWX 의 가장 큰(?) 단점: 도트 피치가 작다 – 사람에 따라선 선호할 수도 있음; 여기서는 VS 2010 전체 화면 모드로, 2048 by 1152 해상도에서 16pt 폰트를 쓰면 한 화면에 두 개의 에디터 창(80 column)을 볼 수 있음. 하지만 도트 피치 문제로 10pt~14pt 정도에선 집중하기 힘들더라; 두통이 찾아오는 지라(…).

게다가 해상도 가지고 계산해 보면 알겠지만 16:9 비율이다. 이것도 취향문제일진 모르겠지만, 에디터에서 위 아래 길이가 짧은 건 꽤나 불편하다. 그렇다고 이 크기의 모니터를 회전 시켜서 쓰는 것도 좀;;; (TN 패널 자른 방향 때문인지 세로로 쓰면 색 왜곡도 심하다)

그래서 새해 지름으로 – 그러니까 내 돈으로 – Dell UltraSharp U2412M (이하 U2412M)두 대를 질렀다. 이걸로 17" 한 대와 23" 한 대를 대체했음. 개발 머신 용 설정으로 이 두 대를 수평으로 이어서 쓰게 되었다. 대략 다음과 같은 구성:

해상도는 1920 by 1200으로 줄어들었지만, 폰트 크기는 15pt로 줄여서, 수직으로 더 많은 내용을 볼 수 있는 건 내 취향임. 폰트 크기를 줄여도 실제 글자 크기는 거의 동일하다. (도트 피치 0.249 vs. 0.270) 비슷한 이유로, 수평 해상도는 살짝 줄어들었지만 폰트 크기 역시 줄어서 수평 공간도 80 column 기준으로 오히려 약간 남게 바뀐다.^[1]

게다가 이 모니터는 의자 위치에 따라 색이 바뀌진 않아…

그래서 Samsung SyncMaster 2343 BWX 랑 Dell U2412M을 비교한다면 난 전적으로 후자의 손을 들어주겠음 – 적어도 내가 프로그래머인 한은 말이다… 어떤 의미로 비교대상은 고가 모델인 Dell U2410 쪽인데, 집에서 쓰는 이 모델이랑 비교하자면 이렇다:

• 입력 단자 수가 적다. DVI도 하나 뿐이고, VGA, DP 로 끝.
• SD 카드 리더도 없고…
• 설정 버튼도 훨씬 촌스럽고(…) 불편하다.
• 색 재현 율이 다르다고 하지만 이건 내 능력 밖의 얘기라 (먼산)
• 더 가볍다 (포장 기준으로 거의 3Kg 차이)

집에서 쓴다면 XBox360도 연결하고 쓴다거나 하고, 편의 기능 (DVI가 2개라거나; SD 카드 읽기라거나) 도 있어서 굳이 U2412M을 사진 않겠지만, 두 대 사서 구성할 생각이면 U2412M도 훌륭하다고 생각한다. (일단 가격이 절반임; 양쪽 다 IPS 패널임에도…)
물론 금전적인 여유가 있다면 U2410 두 대 구성도 가능하지만, 그 돈이면 그냥 U3011 사세요 (…). 얘는 HDMI도 2개임…

PS. 델 4:3 모니터인 UltraSharp 2007FP는 왜 이렇게 비싼가요? 36만이라니 이거면 U2412M 사고도 돈이 남는다고…

1. 오른쪽 모니터에 떠 있는 에디터의 색상 테마는 solarized임. 흰색이 아니다

Sometimes, the terms “astral plane” and “astral characters” are used informally to refer to the planes above the Basic Multilingual Plane (planes 1–16) and their characters.

(강조는 내가 넣은 것)

아스트랄 플레인이라니!! 사실 슬레이어즈는 유니코드 문자셋의 앞쪽 코드 포인트들이 뒷쪽 코드 포인트(아스트랄 플레인)를 사용한 암투인 것.

관련 글:

1. 패킷 직렬화 / 핸들링 라이브러리

• C++
• Python
• C#
• JavaScript
• SQL
• Lua
• Go

C++

우선 주 언어로 쓴 C++. 내년에 공개될 모 서버를 작성했다. 사내 테스트까지 나간 것 중 C++11을 사용한 것으론 처음일듯.
그리고 옮겨간 팀의 서버 역시 C++로 작성하고 있다. 크래시 보고 도구도 밑 단은 C++…

내가 주목한 특징을 꼽자면,

• 바위에 끌로 새기는 것 같이 작업함 – 집중해서 빡쎄게;
• lambda로 이전에 boost 쓰는 걸 대체 – C++11 만세!(…)
• 괜찮은 성능 – 내가 사용하는 모든 언어 중 가장 월등한 성능을 자랑한다
• Bare metal 위에서 돈다 (위랑 같은 의미?)
• 원하는 수준만큼 저 수준에서, 원하는 만큼 세밀하게 제어할 수 있다

Python

팀 내의 코드 생성기나 대부분의 스크립트는 python으로 작성한다. 올해에는 대략,

• 데이터 변환 도구; .xls -> sqlite -> (C++ internal form) 으로 몇 가지 데이터를 옮겼는데, 이 중 첫 단계는 모두 python에서 해결
• 크래시 덤프 분석 및 집계 기능. 크래시 덤프를  cdb 수준에서 분석하면 이를 토대로 다른 덤프들과 비교하고, 이에 대해서 웹에서 볼 수 있게 했다
• 덤프 수집 (web)
• 크래시 덤프 뷰어 (web)
• 빌드 도구나 덤프 관련 툴에서 메일 생성 / 알림 기능

에서 python을 주로 썼다. 물론 예전부터 쓰던 코드 생성기, 빌드 보조 도구에도 python을 쓰고 있다.

…덧붙이자면 요즘 .svg를 python으로 만드는 뻘짓을 했다. 근데 생각해보니 python-cairo를 쓰는 게 더 간단하잖아?;;;

C#

연초에 파일 전송 도구를 하나 짜야 했다. 원래 생각했던 건 python 기반으로 빨리 짜고 딴거 하고 놀자(…)였는데, 

이거 누가 유지 보수 하냐

라는 태클에 물건너 갔음. 흑흑.

그래서 실 서비스에서 써본적(…)도 없는 C#으로 짰음. 사실 태클건 사람들은 태클 걸면 C++로 짤 거라고 생각했다고…
애매하게 편하고, 애매한 수준까지만 제어할 수 있어서 개인적으로 불만이 좀 많았음. 내가 python을 안 쓴다면 모를까 Orz. 

누가 비슷한거 시키면 그땐 정말 python 쓸 테다… 일단 저거 linux에서 옮겨서 쓸 생각을 하니 눈 앞이 캄캄하기도 하고 — 누가 Mono 관련 조언 좀…

JavaScript

까놓고 말하면 js에는 완전 초보임. 그래서 python쪽에서 js를 쓰긴 했는데, 크롬에서만 돌길래(…) 포기하고 jQuery로 전부 옮겼다. JavaScript를 썼다기 보단 jQuery를 쓴 느낌이지만 (…).

CouchDB에서 map-reduce 용 언어로 js를 쓰긴하지만, 이건 그렇게까지 복잡하게 활용한게 없으니 좀 애매하다. 따지고 보면 올해는 js보다 json을 더 많이 본 것도 같다(운다).

올해 얻은 건 jQuery를 좀 더 익숙하게 쓰게 되었다 정도?

SQL

ORM하나 제대로 쓰고 싶었습니다만 꿈도 희망도 없어; 그냥 python위에서 클래스 수준으로 포장해서 하단의 데이터 스토어로만 쓴 듯.
위안이라면 MySQL / CouchDB를 선택해서 쓸 수 있게 만들었다 정도지만; 

Lua

팀 내에서 사용하는 서버 용 부하 테스트 툴은 (NDC에서 ipkn이 발표한 내용은 http://ipkn.upnl.org/ndc.html 을 참조) lua를 스크립트 언어로 쓴다.
그런 의미에서랑, 몇 가지 도구에서 lua를 썼다. 이쪽에선 내가 발전이 전혀 없는듯… 

Go

연초에는 좀 만졌지만 — 위에서 C#/Python으로 헀던 일 중 일부는 원래 Go로 하려던 건데 — 그 이후엔 망했음.
과연 내년에는 나의 야망(…)대로 Go로 돌아가는 서비스를 만들 수 있을까;

일단 올해에는 회사 안에서 / 실제 서비스에서 linux 기반으로 해도 된다는 건 확인했으니, 내년을 기약합시다(…). 

요약:

• C++/python을 여전히 많이 쓰고 있다.
• C#은 안 편했음; 내년에는 아마 다른 선택을 할 듯.
• 웹 질(…)로 JavaScript/SQL을 좀 만졌다. 내년엔 기약 없음…
• Go. linux 기반 서비스를 좀 더 해도 될 것 같으니 내년을 기약 

관련 글:

1. 이번 주 팀 세미나: NDC 2011 마영전 서버 세션 정리
2. C# 잡상: 2011-03-04
3. C#이 예전 기억만큼 편하지 않다

• 매일 매일 얼마나 많은 덤프가 나오는지,
• 가장 많이 발생한 원인 (WinDbg의 버킷 비슷한 것) 은 뭔지,
• 같은 원인으로 죽은 덤프는 어떤지,
• 각각의 덤프 별 콜 스택 플랫폼 정보 (OS 버전, 각 모듈 별 버전) 는 어떤지

가 나오는 페이지를 만들었다.^[1] 아니 근데 생각지도 못했던 문제를 만났다;

여름에 서버를 설치한 후, 총 3개 팀이 사용하게 했고, 이에 따라 차근차근 크래시 덤프가 쌓여간다. 최근 덤프가 좀 무섭게 쌓여서 (…) 디스크 사용량을 추적해봤더니 대략 이런 결과가; (8월 중순 쯤 서버를 리셋했고, 그 이후의 디스크 사용량)

팀 + 1개 팀 상태에서는 참 완만하게 올라갔는데 (…), 좀 덩치 큰 다른 팀까지 적용했더니 순식간에 하드디스크가 차고 있다; 게다가 기울기가 더 올라가서, 현재 Doomsday는 다음 달 중순까지 당겨진 상태 Orz. 개발 중인 프로그램에 적용한 것이고, 개발 팀만 접근 가능한 위치라 전체 메모리 덤프를 받게 했더니 정말 저장 공간을 왕창 잡아 먹더라; 이건 내 예상 실패라고 밖엔;

HDD 가격 올랐다고 구매 신청해도 안 사줄 기세던데 이를 어찌 해결하는가; 일단 같은 콜 스택 + 같은 모듈 (이름; 버전; 체크 섬) 인 것들 지워서 지난 주 후반에 40 GiB 쯤 확보했는데, 그럼에도 불구하고 (…) 이미 216 GiB 쯤 쓴 상태. 사진은 2주 전 상태임.

저 서버를 설정할 때만 해도, 연말까지 300 GiB 정도는 넉넉하리라 생각했다^[2] 하다못해 HDD 하나 추가하는 건 별 큰 일 아니라고 생각했다. 하지만 태국 홍수 덕에 구매 팀에서 HDD 가격 비싸다고 장비도 안 사주는 마당이니, 망한 상황인 듯. 아마 1월부턴 90일 정도만 남기고 – 어차피 개발 중인 프로그램들 용으로 덤프 받는 서버라 버전 정보가 휙휙 올라가는지라; – 다 지워버리던가 해야.

사실 내가 궁금한 건 이거다; 과거의 덤프가 남아있다면 뭐가 좋을까? 그냥 간단한 텍스트 정보 – 크래시 한 상황에 대한 OS 정보, 콜 스택 정도가 있다면 충분할까? 아니면 전체 메모리 덤프가 다 있다면 오~래 가는 버그를 좀 더 쉽게 잡을 수 있을까?

원래 목적이던 “자주 발생하는 버그를 빨리 잡자”는 어느 정도 되어가는 것 같은데 – 일주일쯤 피크 치는 버그는 대충 잘 잡히는 듯? – 오래된 버그를 잡는데 도움이 되려면 어느 정도 범위를 가지고 있어야 할지;;;

PS. iPhone 4 렌즈 수차 정말 망이네; 화면 위 아래 수평선의 기울기를 비교해보면 Orz (…).

1. 실제 페이지 구현은 회사에서 만든 부분이라 여기서 공개하는 건 무리
2. 즉, 한 달에 50 GiB 이상은 안 나오겠지 정도로…

관련 글:

1. Egloos 이오공감/밸리에서 특정 블로그 무시하는 플러그인
2. 리뷰: 셜록 홈즈 미공개 사건집

운영 팀에서 "서비스와 데스크톱 상호 작용 허용" (allow service to interact with desktop) 설정을 켰음 – 이유는 모르겠지만, 대부분의 개발팀이 이 설정을 요구한다고; 계정은 로컬 시스템 계정 (local administrator) 였고; 여하튼 이 설정이 켜져서 문제가 된 부분은 대략 이렇다:

• 개발 편의성을 도모하고자, 1개의 바이너리가 서비스 혹은 콘솔 창 모드로 동작함
• 이 두 가지를 Environment.UserInteractive 값을 가지고 구분했다
• "서비스와 데스크톱 상호 작용 허용"이 체크되어 있으면, Environment.UserInteractive가 true로 설정된다
• …그리고 내가 작성한 서비스는 콘솔 창을 띄웠다 (…)

Orz.

부연하자면, 서비스는 세션 0에서 실행되기 때문에^[1] 사용자가 터미널 접속한 경우, "이런 이런 서비스에서 창을 띄우려고 합니다"란 메시지를 받게 된다. 그리고 그런 유저가 없으니 – 서비스는 보통 sc \\host-name start blah-blah-service 명령이나 관제 툴로 띄운다 – 서비스는 더 진행하지 못하고 사망. 일정 시간 안에 서비스를 시작하지 못하면 서비스 매니저는 그 서비스를 죽여버린다(…).

결과:

• 일단 그 날 저 체크 박스 꺼버리는 걸로 문제 해결.
• Environment.UserInteractive 말고도 SessionID를 확인하도록 코드 추가. (세션 0이면 서비스로 뜨게)

.NET을 잘 모르고 써서 생긴 문제긴 한데, 내가 운영 매뉴얼?을 좀 만들었으면 괜찮았을지도 모르겠다. 으으.

1. Session 0 isolation 참고

관련 글:

1. TLS, DLL, 그리고 Legacy Windows
2. Python으로 Windows Service 제작해보기
3. On Windows 7

• 팀이 바뀌었다
• 모 게임의 서버를 새로 짜는 작업을 하고 있다
• 회사에서도 linux 서버를 만지기 시작

첫 번째 일과 두 번째는 사실 한 몸이고; 나머지에 대해서 기록;

저 linux 서버 위에 예전에 짰던 크래시 덤프 수집하는 녀석을 올렸다. Windows + IIS + MSSQL Server + WSGI  (isapi 사용) application 이던 걸 linux + apache2 + MySQL (or CouchDB) + WSGI (mod_wsgi) 로 옮겼다. 실제 서버는 아마 nginx proxying + gunicorn 같은 애를 쓰게 되지 않을까 싶지만;

저기로 옮기면서 페이지도 페이스 리프팅. 원래 좀 중구난방이던 크래시 덤프 보기 페이지에 시간 대 별 보기라거나, 카테고리 기능이라거나, failure bucket id (windbg 얘기) 로 분류하기 등등을 넣었다. 덕분에 거의 0이던 jquery 프로그래밍 경험치가 충전된 듯 (…).
아무래도 이건 혼자 쓸 것만 만들다가 Firefox / Chrome이 아닌 웹 브라우저에서도 동작하게 해서 그런 거지만;

내가 처음 짠 코드의 문제가 CherryPy 에서 html 코드를 직접 토해낸다는 점. 간단한 건 그냥 문자열 혹은 문자열의 list로, 좀 복잡하면 문자열 yield return으로 때웠는데, 코드가 좀 길어지니까 감당이 안되더라. 일단 이걸 내가 계속 진행할 수 있는 처지가 아니라서 – 요약 1 참조 – 다른 프로그래머에게 넘겨주게 생겼는데 얘기하다 나온 게

• 유지 보수가 가능한가? Python을 중점적으로 쓰는 나와 ipkn 말고 유지가 가능한가?
• 굳이 linux 서버를 쓸 이유가?

이 두 가지. 그래서 목표가 "다른 프로그래머가 적응하는 시간을 줄이자", "문서를 최소한만 쓰자"로  데, 이건 대략 만족한 듯. 만약 이걸 asp.net 으로 옮긴다고 해도 로직 / 화면 두 가지만 분해되어 있으면 어떻게 될 거라고 믿기로 하고 (하략). 매우 저 수준으로(…) html을 직접 토해내던 WSGI application을 좀 분해하기로 했다. ipkn의 조언에 따라 – 그리고 손에 든 것만으로 문제를 푸는 나의 나쁜 습관을 가까스로 극복하고 – 템플릿 언어를 하나 골라서 써 보기로 했다. 그래서 flask 쓸 때 잠시 봤던 신사 (jinja2; http://jinja.pocoo.org/ )를 써봤다..

홈페이지의 첫 예제를 여기 가져와보자면,

정도인데; layout.html의 내용을 상속하고, (아마도 이중 일부인) body 블록을 override하는 예제. {{ }} 안의 내용은 print, {% %} 안은 제어문이 들어간다. 대략 있을 건 다 있음. 제대로 만든 PHP 같다고 누가 얘기했는데 누구였는지 까먹었다. 참고로 저 for 문 마지막에 : 찍어도 된다 (…). 레이아웃 코드에 제어문이 있는 걸 싫어하는 사람도 있지만 난 PHP도 싫어하지 않는 성향이라; 이 정도면 오히려 적절한 조합이 아닌가 싶다.

html 템플릿 파일 쪽만 봐도 내용을 어느 정도 알 수 있고, 중복 제거도 쉽고, python 쪽에서 미리 데이터를 구워(?)두기도 편한 편. 극단적으로 말하면 2000년 즈음의 VBA의 생산성을 다른 형태로 살렸다고도 할 수 있다.^[1]

경험담:

• python 코드 크기 절반으로. 기능도 추가했는데! (…)
• Jinja의 템플릿 언어가 python과 비슷하다. 적응하는데 5분이면 충분함.
• 페이지 레이아웃을 python 함수로 표현하는 건 무모했다. 적당한 hook을 만들기가 영; Jinja2의 템플릿 페이지 상속 기능으로 다 대체하는 편이 편했음.
• vim 용 문법 강조 파일도 제공함.
• JSON 응답도 템플릿 처리가 가능; 텍스트 형태의 응답이면 대부분 쉽게 될듯함.

라서 매우 편하게 작업했다. 팀 동료 몇 명에게 보여줬는데, 반응도 나쁘지 않았음.
내가 전에 작업했던 얘길 했더니 팀 동료 한 명은 이렇게 표현했음:

"이 생퀴 python으로 CGI 프로그래밍하지 마라"

Orz. 하..하지만 나 C로 CGI짜본 남잔데! (어이)

요약(?)

• 새 도구 좀 빨리 씁시다
• 머리가 나쁘면 손발이 고생

1. DB –> UI 로 넘기는 형태의 프로그래밍에서 작업할게 거의 없다

관련 글:

1. URI 삽질
2. Google Go on Android/nacl?
3. Adobe FlashSocketPolicyDaemon (python) 코드의 버그

VisualStudio 2010에서 포스트모텀 디버깅^[1] 할 때 심볼 서버, 소스 서버를 이용해서 디버깅하는데, 얘가 소스 서버에서 파일을 안 가져온다. 그래서 내가 추적한 순서 (…)

svn.exe 가 있는가 – 없으면 svn.exe cat … 이 실행 안될테니

심볼 서버 접근이 잘 되는가 – 안 그러면 .pdb 에서 소스 리스팅을 못할테니

.pdb에 소스 정보가 없는가 – …없으면 못 찾아올테니

…여기까지 했으니 전부 아니었음. .pdb도 잘 가져오고, 거기에 소스 인덱싱된 것도 있고, 거의 똑같은 설정의 다른 머신에선 디버깅 잘 되더라고 Orz

관리자 모드로 VS 2010을 재실행하고 나니 원인이 보이더라. 유저 홈 디렉터리를 d:\Users로 옮겼는데, 소스 서버 데이터를 c:\Users\rein\AppData\… 에 저장하는 것. 이전에는 일반 유저 권한이라 c:\Users 밑에 뭔가 못 만들어서 svn.exe cat이 실패한 모양. 이유는 모르겠지만, VS2010은 저 설정이 거의 하드 코딩되어 있거나, 홈 디렉터리 위치를 c:\에서 d:\로 바꾸려고 레지스트리에서 바꾼게 불충분한 모양.

좀 더 이유를 아시는 분은 설명 좀 (굽신굽신)

1. 혹은 사후 디버깅. 크래시 덤프를 가지고 진행하는 디버깅

관련 글:

1. rein’s world 2010 통계
2. C++ 0x 와 VS 2010 관련해서
3. VisualStudio 2010 체험(?)기

여기서 그의 명복을 빌어본다.

지난 주의 스티브 잡스 사망도 슬픈 일이지만, 개인적으로는 데니스 리치의 사망이 더 임팩트 큰 일.

간단히 말해서, 우리가 현재 쓰고 있는 SW의 가장 밑 바닥을 지탱하는 기술과 개념이 데니스 리치 손에서 태어났다.

• 시스템 프로그래밍의 가장 널리 쓰이는 C 언어의 창시자다; 우리가 쓰는 linux, Windows는(아마?)는 C 기반의 커널로 되어 있다. 대표적인 웹 서버 (아파치나 nginx) 역시 C로 만들었다. 그리고 이 C로 Unix를 재 작성(!)해서 `앞으로 OS를 어떻게 만드느냐’에 관해선 사실 상 결론을 내려버렸다.^[1]
• 내가 가장 사랑하는 *nix의 일관성 – 간단한 텍스트 기반 I/O의 프로그램을 연결해주는 파이프.
• 현대적인 개념의 C-runtime IO 방식을 고안.
• 내가 읽어 본 가장 간결하고 군더더기 없는 프로그래밍 책 – The C Programming Language의 저자.

좀 더 쓰자니 그냥 여길 링크: http://j.mearie.org/post/11385959754/rip-dennis-ritchie 에 더 잘 정리되어 있다.

1. 더불어 이 두 업적으로 1983년에 켄 톰슨과 함께 튜링 어워드를 받았다

관련 글:

1. 파일 대신 SQLite 쓰기
2. NDC 참관기: 마비노기 영웅전 자이언트 서버의 비밀
3. Gccgo in GCC mainline

• i7 2600 (7.6)
• intel 80G ssd (320 series) + sata hdd 500G (7.7)
• ddr3 1333MHz 4G (4G * 4 따로 달고 기존 달린 건 딴 머신으로) (7.6)
• nVidia 450 GTS (7.2)

우왕ㅋ굳ㅋ. 여기에 ㅊㅊㅅ 님이 "256G SSD + GTX 560ti" 주는 곳 있음! 이라고 츳코미를 날렸지만 뭐(…).

어제는 32 bits OS가 깔린 채로 와서, 밀고 새 OS 깔고 퇴근. 이 아래는 오늘의 삽질기.

드라이버 디스크를 집에서 만들어왔으나, 정작 이걸 묶어서 (.tar.gz) 가져왔다가 망함. gzip은 .NET의 System.IO.compression.GZipStream 으로 풀었으나 tar가 Orz. 여하튼 이건 꼼수로 넘어가서 각종 드라이버 설치. (여기까지 대략 오전 10시)

(사이에 모종의 사내 서버 문제가 풀리는 걸 확인…)

intel DP67BA 보드가 PS/2 슬롯이 없는지라, 이걸 위한 젠더 케이블을 링코 코엑스 점 가서 사와야 했음. 어차피 연필도 사야 하는 상황이라 겸사겸사 (…). 11시가 넘어서 네트워크에 연결 완료. (mac address 등록까지 걸리는 시간이…)

본격적으로 프로그램 설치 시작. 대략 VisualStudio 3종 세트^[1] – 이게 바로 라이브러리 개발자의 위용 – 와 기본적인 개발 도구를 설치 했음. 대략,

• 소스 컨트롤 3종 셋: p4, svn, git
• viemu / gvim
• perl + Debugging Tools for Windows
• python 및 내가 쓰는 패키지 일부
• 7-zip
• putty
• Google Chrome
• mRemote

정도를 설치. 여기서 p4, git, vim, putty, mRemote는 설정 파일과 registry도 이전;

점심 쯤 추가 DRAM 도착. 설치하고 ram-disk 4G 할당. 이제 스크래치는 전부 여기로^[2] 옮기게 설정. 근데 이 때 케이스 외곽에 꽂혀있는 드라이버 디스크 발견. 아침엔 무슨 삽질을 한 것인가…

소스 저장소에서 파일을 못 가져와서 뭐가 문제일까 고민했는데, 대략 회사 보안 정책 / 보안 도구 문제 ;; 이거 해결하고 마지막으로 (대략 오후 3시?) 설치된 프로그램 테스트. C# 프로젝트들은 빌드 되는데, C++ 프로젝트는 빌드가 안되네? CL.exe 실행하는 MSBuild task들이 예외를 던지더라…확인 결과 TEMP, TMP는 드라이브 루트면 안됨; MS 파일 시스템의 권한 설정 상 루트가 특이해서 생기는 문제인 듯. (thanx to Azyu)

OS 설치할 때 USB 키보드를 생각 없이 꽂아서 했더니 키보드 타입이 101key, type 3가 아닌 101 key type 1으로 잡혀버림; 망했다를 외치고 레지스트리를 고쳤다 Orz. 평소 하던 데로 ctrl, win key도 caps lock, ctrl 자리로 보냈음.

여하튼 이렇게 하루가 끝. 4시부터 대략 2 시간 동안은 크래시 덤프 디버깅하는 운명에 처하긴 했지만 말이다…

대략 빌드 속도는 프로젝트마다 차이가 있지만 1.5~3배 정도 빨라짐. 스크래치 디렉터리 옮기고 + CRT는 SSD에서 읽고 + CPU 파워가 올라간 덕택인 듯…

1. VS 2005, 2008, 2010; 그리고 각각에 속한 SP와 일부 hotfix 설치
2. TEMP, TMP, Windows\Temp, Windows\tmp, 그리고 VS의 C++ 메타 파일도 전부 이전

관련 글:

1. intel tbb 2.2 released
2. 프로그래머의 일상: OS 재설치
3. 가상화 서버 체험기

• 팀장 권한으로 새 머신을 신청할 수 있다는 사실을 확인했고,
• (이를 이용해서) 4. 6년된 머신 대신 새 머신을 하나 받기로 했고
• 대략 원하는 스펙^[1]의 머신을 받게 될 듯 (예정?)

여하튼 대략 이러한 상황이 되었음. 이젠 내 머신에서도 릴리즈 빌드가 할만해질듯.

엄하게 팀장님 디스하는 상황이 (사내에서) 되어버린 건 좀 많이 죄송하지만 (……..)

댓글란에 적어준, 혹은 트위터 멘션으로 보내준 의견/사연들을 놓고 생각하면 소위 IT 업계란 곳도 프로그래머 생산성, 좁게봐서 하드웨어 공급면에 그다지 신경쓰지 않는 듯 하다. 일단 48개월 주기의 교체 일정에 대해선 사람들 반응이 매우 안 좋다.

교체 주기가 24개월 이하인 곳은 규모가 있는 한국계 회사 중엔 1개 (NHN)인 듯 하다. 나머지는 24개월, 36개월, 내가 있는 곳은 48개월(…).
기껏해야 연봉의  1~2% 수준인^[2] 수준일 머신 비용에 너무 신경 쓰는 건 너무 피곤하지 않은가.

뭐 국내 굴지의 모 기업에선 `이미 효과가 상당부분 인정되는 듀얼모니터‘를 절전이란 이유로 자제하라고 한다니 말 다했지.

혹은 모 금융 공기업 전산직은 연차 순(…)으로 좋은 머신을 주고, 5+년된 머신으로도 개발한다는데야…

원인은 뭘까? 내 나름대로 정리하자면,

• 프로그래머 연봉이 아직 낮은 축이라 생산성이 아니라 소요 비용에 신경쓴다
• 조직이 커지면 개발 부문 이외, 사무나 회계 등의 연간 목표도 중요하다
• 비슷하게, 상대적으로 컴퓨터 성능에 영향을 덜 받는 부문에서는 이런 얘기에 귀 기울이지 않는 듯

1. i7 2600, RAM 8G, SSD/HDD 듀얼 구성, …
2. 이번 모회사 공채에 신입사원에게 준다는 기준선이라던 연봉 3000만원 기준으로 150만원짜리 머신을 2년 쓴다면 대략 2.5%. 여러가지 부대 비용이 들어가는 걸 생각하면 대략 총비용을 2 년치로 나눠서 1.25%다 겨우… 연봉이 높아지면 이 비율은 더 작겠다

Joel on Software의 Joel Test 9번째 항목은 이러하다.

9. (예산이 허용하는 범위 내에서) 가장 좋은 툴을 사용하는가?

9. Do you use the best tools money can buy?

현재 내 상황은 이 항목에 대한 답이 `No’다. 나는 지금 939일 (2.6년) 된 장비와, 1689일 (=4.6년) 된 개발 장비 쓰고 있는데.<sup>[1]</sup> 연초에 교체 대상 컴퓨터를 조사해 갔던 것 같은데, 이 중 후자만 바꿔준다고 해놓고 교체없이 3Q가 끝나간다면 문제가 많지 않나. Workstation을 쓰고 있는 것도 아니고 지극히 일반적인 의미에서의 개발용 데스크 탑 쓰고 있는데 4+년의 교체 주기는 `회사가 생산성에 관심이 없거나’, `내 가치가 이런 것도 오래 걸릴 정도의 평가를 받고 있거나’가 아닐까.

혹시 SW회사에서 개발 장비 교체 문제에 감가상각 같은 정신 나간 기준을 들면 그 회사에서 나가야 한다는 강력한 신호인데 말이지.^[2] 아오.

나와 같이 일하는 동료들, 혹은 IRC나 기타 SNS 미디어를 통해 얘기하는 사람들은 잘 알고 있겠지만, 나 스스로 올해 정해놓은 시한이 하나 있다:

2007년 2월에 입사하면서 받은 개발 머신을 올해 말까지 계속 써야만 하는 상황이면 다른 회사를 알아보거나 창업하기로

적어놓으니 뭔가 하드웨어 구걸하는 꼬락서니긴 한데. 지금으론 슬슬 `내가 왜 이런 걸로 고민해야 하는가’의 한계선인 듯. 어차피 회사 다니는 것도 단순한 계약일 뿐,

내가 얻는 이익 (돈, 안정감, 일의 만족) > 내가 받는 피해 (짜증, 귀찮음, 시간 소모)

이 부등식이 만족되지 않으면^[3] 별로 더 연장할 이유가 없다. 연초에 연봉 왕창(~2x%?) 올려주면 뭐하냐.

얼마 전에 사람이 필요해서 학교 후배들이랑 열심히 이 사람 저 사람 알아보다가 좀 시들해진 것도 이거 탓이 꽤 큼. 4년 넘는 장비를 쓰는 회사로 `내가 후배를 데려오는 것’에 대한 도덕적인 거부감이 – 즉, 엔지니어에 대한 적당한 대우가 아니다 – 이유다. `반짝 반짝한’ 후배들 중 상당 수가 대학원에 묶여 있거나^[4] 이미 다른 회사를 다니면서 이직할 생각 없다고 말한 것도 이유이긴 하지만… 여하튼 Joel Test 9번 항목과 영 안 맞는 상황이니 내가 짱짱한 후배를 데려오기엔 죄책감이 든다.

1. 심지어 전자의 장비는 후자의 장비가 너무 느려서 퇴사자 컴퓨터 받아온 것
2. 물론 시중에는 개발을 랩탑에서 하는 이상한 곳도 있다. 데스크 탑 / 랩탑 선호로 선택하거나 둘 다 지급 하는 게 아니라 랩탑에서… 워크스테이션과 노트북과 테스트 용 서버(…)를 지급하는 회사도 있던데…
3. > 대신 >> 가 와야 맞겠지
4. 석사 학위 없으면 병역 특례 자격이 없으니

관련 글:

1. 내 생산성의 장애물
2. 난 아직도 커맨드라인이 더 편하다
3. 내가 원하는 test-runner 의 조건

어제 Steam에서 구매한 (발매 일은 8/16)^[1] 게임. 가벼운(?) 게임 플레이를 제공하는 아기자기한 2D 게임을 원하던 터라 주저 없이 구매. 19.99 (이하 USD)를 할인해서 14.99던가에 판매하더라.. 다만 OST 합본 팩을 안 산걸 조금 후회… OST를 따로 사니 추가로 $5쯤 추가로 들었다 Orz.

전형적인 2D, 쿼터 뷰, 핵&슬래시 장르라고나 할까…
게임 배경이 배경이니 좀 음울하긴 하지만 색조는 화사(?)한 편에 가깝다. 2D에서 좀 더 보여주기 쉬운 색감이랄까.

화면 중앙 왼쪽의 다리 난간이 좀 이상하게 보일 거다. 던전(?)에 들어가면 일부 지역만 보이고/이동가능하고, 특정 경로로 이동하면 화면에 타일들이 `떠오른다’. 저 다리 난간도 떠올라서 생기는 중(…). 적도 그렇게 생긴 화면에 턱 하고 나타나는 경우가 있어서 나름대로 긴장감 유지에 좋음.

정말 좋았던 부분은 음악 + 해설(?). 주요 등장 인물 중 한 명이 주인공의 행동을 서술하는 형식인데. 이게 음성으로 낮게 깔려 나옴. 일부 동작 – 예를 들어 새로 얻은 무기로 열심히 물건들을 부순다거나, 추락한다거나, … – 에 반응해서 그에 대한 설명을 하기도 한다. 시작하자마자 떨어지고 나서 나오는 해설에 잠시 멍해지더라(…).

무기가 다양하게 나오는데 – 망치, 바셰티, 창(할버드?), 활, 저격소총, 샷건, 박격포, …이건 뭐라 설명할 수 없는 로켓포(?), 화염방사기 등… – 이에 대한 업그레이드 재료 + 돈으로 이 무기에 추가 옵션을 달아서 게임 플레이가 꽤 변한다. 로켓포 최종 업그레이드 같은 경우 자동 추적(…)옵션이 달리기도. (무려 범위 무기에 궁극 무기라 한 방에 거의 다 잡는데…)

스크린 샷에서는 터렛에 맞아가며 박격포를 조준하는 장면. 무기마다 컨트롤이 확연히 다른 것도 재미요소. 활은 오래 겨냥하면 더 세게 나가고, 저격 소총은 오래 겨냥하면 더 정확히 나가고… 박격포는 더 오래 겨냥해야 멀리 나가고(…). 일부 근접 무기는 오래 누르면 던진다거나 하기도; 그리고 무기 마스터 던전도 존재한다. 각 무기에 맞는 특정 미션을 수행하면 수행 수준에 따라 보상을 달리 주는 곳(…).

사원이란 시스템으로 난이도를 조절하는 것도 괜찮았음. 사원에 특정 신상을 활성화하면 특정 조건의 몹이 특정 형태로 더 강해지거나 하는 게 생김 – 물론 돈과 경험치도 더 줍니다… 그래서 별도의 난이도 시스템이 외부에 preset으로 주어지는 게 아니라 유저가 알아서 잘(?) 하면 되는 구조… 요즘처럼 게임이 대중화 된 상태에선 난이도에 대해 호 불호가 극명하기 때문에 이건 꽤 괜찮은 선택으로 보인다.

보너스: Steam 판매용 버전에만 있다는 깨알 같은 포탈 패러디. 특수 스킬을 고를 수 있는데 Gel Canister란 녀석이 있다(…). 이거에 대한 NPC들의 반응도 깨알 같다(…). 일단 `Who Knows Where’클리어 할 때 매우 편하다.

한 번 클리어한 던전에 또 진입할 수가 없는데, 대신 `Who Knows Where’라는 모드가 있다. 게임이 전체적으로 3종류의 던전 배경이 있는데 그 각각에 대해 몬스터의 웨이브가 k번 반복되는 그런 반복 던전. 돈은 여기서 모으면 됩니다. 어차피 스토리를 이해하기 위해선 꼭 한 번 씩은 가야 하니…

마을은 왼쪽에 보이는 노란 아이콘 (검은 배경) 같은 상점(?)류가 총 6곳 있다. 처음엔 0곳이지만 스토리를 진행하다 보면 늘어나고, 각각이 지원하는 기능이 다름. 하지만 마을은 큰 의미가 없는 게임이라(…).

전체적으로 올해 나온 게임 중엔 가장 맘에 듬. 짧다는 것만 빼고(…). 시작해서 엔딩 볼 때 까지 실 플레이 시간은 5시간 미만?. 물론 두 번 엔딩 봐야 하고(…), 업적도 채워야 하니 그보다 더 걸리긴 함. 일단 가격도 그다지 비싸지 않으니 추천. 이 게임 분류가 인디긴 하지만 무려 HD 해상도도 지원하고 / 그래픽 / 사운드(!!) 모두 나무랄 곳이 없다.

PS. 여기서 잠시 스포일러 성 멘트 하나. 게임 엔딩 선택지가 commit or rollback이다. 이런 공돌이들 같으니(?).

1. XBox Live Arcade를 통해서는 지난 달에 발매되긴 했다.

관련 글:

1. 게임물 등급 심의 제도에 관한 생각
2. Project DarkStar 는 왜 실패했을까?
3. Tomb Raider: Underworld

현재 상황은 대략 망해가는 프로젝트인 것 같다.

마지막 stable version이 작년 12월에 릴리즈. 다운로드 수는 누적으로 70회;

마지막에 등록된 티켓(trac issue)이 올해 2월.

위키 최종 편집 시간이 6월^[1] 포럼에만 활동이 약간 있는 정도. 이 정도면 거의 활동없는 프로젝트라고 봐야하나?

(실질적으로) 사용하는 곳이 없고 / 개발 팀도 응집되지 않은 듯 하고 (커밋한 사람 수를 보면…) / 앞으로 비전이 있는 프로젝트는 못 될듯 하다.

1. 그 이전에 올해 들어와서 수정된 페이지가 6개 , 그리고 각각 1번씩만 수정

관련 글:

1. Project DarkStar 는 왜 실패했을까?
2. Project Dark Star 개발 중단 및 오픈 소스화

• 유닛 테스트(혹은 기능 테스트)를 돌렸는데 끝이 안난다거나
• 컴파일러 메시지가 쭉 뜨고있거나 혹은 링커/코드 생성 메시지에서 끝이 안나고 있다거나
• 빌드 서버에서 끝없이 노란 불(=빌드 중)이 들어가 있거나
• 안티바이러스 스캐닝이 하드 디스크를 긁고 있거나^[1]

여하튼 이런 일에 신경이 쓰이면 뭔가 발이 잡힌 것 같고, 집중이 퍽하고 깨진다.

개인적으로는 이거에 대해 약간의 우회책을 넣어 대처하고 있다(=성격 나빠지고 있다).

우선 빌드 속도와 테스트 케이스 실행 속도.
google test 를 써서 작성한 테스트인 경우 실행 파일 생성 시간이 바뀌면 자동으로 테스트를 실행하고 실패하면 화면 오른쪽 아래에 커다란 빨간 팝업을 뜨게 했다. 클릭하기 전에는 안 사라지는 그런 팝업임.

대충 여기 화면 오른쪽 아래에 나오는 식.^[2] 반대로 모든 테스트가 성공하면 쬐끄마한 녹색 팝업을 수 초쯤 띄우고 사라지게 했다. 이전에 빨간 팝업이 있었으면 그것도 지우고…
상대적으로 좀 덜 기다리고 (문제가 생기면 알려주고) 다른 작업을 할 수 있게;

이전 포스팅에서 말했던 원래 문제(긴 테스트 시간)도 약간은 견딜만한 문제정도로 바꿨다. 다만 이 방법도 항상 통하는건 아니다. 코드 작성 -> 빌드 -> 실행 -> 보고의 한 싸이클이 너무 길면 큰 도움이 안된다. 테스트가 다 돌기도 전에 다음 싸이클의 코드 작업이 끝나고 빌드 버튼을 누르면 이미 실패. 엄한 링크 오류나 보게 된다.

그덕에 직전 포스팅에 나온 작업에 착수. 테스트 실행시간을 줄이고나니 어지간해선 — 멍청한 안티바이러스라거나가 빌드 시간을 잡아먹지 않는다면 — 견딜 수 있는 범위 내로 어떻게 어떻게 되더라.

빌드 서버 결과기다리는 것도 예전엔 상태 보면서 기다렸는데, 요즘은 신경 끄고 딴 일하다 실패 팝업 뜨면 그 때 보기는 방식으로 가고 있다. 문제는 내가 고친 프로젝트 말고 다른 사람 프로젝트 깨지면 그것도 신경쓰게 된다는 거지만;

하지만 이런 짓하면 성공적으로 전진하는 경우야 좋지만 실패했을 때의 페널티가 크다. 내가 뭘 생각하고 있었나도 돌아봐야하고, 문제를 풀고나서도 다시 원래있던 곳으로 사고를 돌려야하니…

여하튼 세 줄 요약

• 작업 싸이클에 드는 시간이 짧아야 집중해서 일할 수 있다
• 특정 단계가 너무 길다 싶으면 비동기로 바꾸고, 보고할만한 내용이 있으면 눈에 잘 띄게 알려주자(소리나 불빛 덜 방해되는 영역의 팝업)
• 이래도 안되면^[3] 하드웨어에 투자해야. 뭐 난 그게 안되서 테스트 코드를 최적화했다만(…)

1. 물론 이 경우에는 정말 아무 것도 할 수 없기 때문에, 수단과 방법을 가리지 않고 안티 바이러스를 종료한다. 안 꺼지면 파워 버튼을 연타
2. 화면 오른쪽 아래 좀 탁하게 찍힌 화면이 그것. 화면 해상도가 2048 by 1152 임을 감안하고 보실 듯
3. 사실이게 제일 싼 방법 같은데

관련 글:

1. VisualStudio 2010 체험(?)기
2. svn tag만들 때 svn:externals 리비젼 고정하기
3. 서버 설치 기록 post-mortem

원래의 구현은 엑셀 파일(.xls)을 서버 시작시점에 읽어서 특정 시트를 각 시트에 맞는 데이터 타입으로 바꿔서 저장하는 것. 이를 위해 Microsoft Office용 일부 dll (MS Visual Studio 2010 Tools for Office Runtime, AccessDatabaseEngine_x64)을 필요로 함. 이걸 써서 OLE로 값을 읽는다. 그리고 좀 엄하게도(…) 일부 셀은 리스트, 그것도 구조체 비슷한 것의 리스트를 적당한 토큰으로 구분해놨다. 이 부분은 문자열로 읽고 정규 표현식으로 분리해서 메모리에 올린다.

개인적으로 이 구현은 굉장히 맘에 안들었다. 문제라고 생각하는 부분은 두 가지. 일단 속도. 백 개 정도의 테스트 케이스를 실행하면 140초쯤 걸린다. 교체 대상인(…) 내 Q8400에서 약 140초쯤 걸림. 물론 콘솔 출력을 날려버리면 (> nul) 8x ~ 9x초 수준까진 줄어든다. 느린 부분이,

• OLE로 데이터 가져오는 부분(700ms)
• regex 로 데이터 언마셜링하는 부분(500ms).

물론 기능 테스트에서만 전체 데이터를 로드하는 거지만 전체 테스트가 느려지는 건 스트레스.  그리고 60% 이상의 케이스가 기능 테스트이고, 이 때마다 서버 런타임 전체를 초기화 하기 때문에 여기 들어가는 시간이 매우 스트레스였다.
일단 OLE에서 데이터 읽는 부분은 처음 읽을 때만 사용하고, 이 때 데이터를 텍스트 형태로 메모리에 올린 후, 그 이후 테스트 케이스에선 이걸 읽게 했더니 꽤 빨라지긴 했지만(140초->100초) 여전히 남은 정규 표현식 Orz. 그리고 이건 데이터 늘어나면 더 느려질게 뻔하니…

두 번째는 외부 의존성. 서비스하기 위해 추가로 설치해야 하는 외부 프로그램이 있는게 좀…

그래서 (a) SQLite 테이블로 바꾸는 스크립트, (b) SQLite 테이블에서 데이터 읽는 코드 이렇게 두 가지를 만들었다.

우선 엑셀 파일(.xls)로 되어있는 데이터를 SQLite 테이블로 변환하는 코드를 작성했다. python xlrd 팩키지로 특정 시트를 읽고 여기 있는 첫 번째 행에 있는 데이터를 열 이름으로 처리하고 나머지 행에서 셀 데이터 타입을 받은 후 여기서 빈 셀이 아닌 것의 주요 타입을 열 타입으로 고름. 다만 정수/실수 선택은 적당히 실제 셀 값을 뒤져서 골랐다. 근데 SQLite에 문자열로 넣고 실행시간에 select한 후 읽는 쪽에서 고르는 게 나을지도 모르겠다. 이 테이블에 개별 행을 하나 씩 읽어서 삽입.  (INSERT ?, ?, … , args)로 끝.

마지막으로 이전에 정규 표현식으로 처리하던 부분을 python에서 해석하는 단계에서 별도 테이블을 생성하게 바꿨다. 나중에 유효성 검사할 걸 생각하면 역시 단계가 하나 더 있어야 하고, 이걸 여러 번 할 이유가 없거든…

SQLite에서 데이터 읽는 부분은 흔히 하는 sqlite3 open, prepare(SELECT 구문), 데이터 다 나올 때 까지 step k번으로 해결. OLE로 읽는 거 보다 당연히 빠르고 텍스트로 캐싱한 것 읽는 거보다 조금 늦은 수준으로 끝나더라.

이제 외부 의존성은 없고(sqlite.c가 추가되지만) 테스트 케이스 실행은 50초 수준까지 줄었다. nul로 콘솔 출력 보내면 20초 미만…

여하튼 이거 오늘 git에서 메인 스트림으로 보내버리고 딴 버그 잡고나니 하루가 지나가긴 했다. (상당 수의 작업은 금요일에 했음)

1. 링크에 적어놓은 말 자체는 Hacker News 페이지의 제목이고, 실제로 연결된 페이지는 SQLite 사이트의 화이트 페이퍼 페이지다

관련 글:

1. 평범하지 않게 파일 복사하기
2. TLS, DLL, 그리고 Legacy Windows
3. 당신 역시 초보일 수 있습니다

최근에 알게된 dulwich 프로젝트 덕분에 svn 프로토콜 일부를 구현하면 아마 기존 저장소를 git으로 옮기고, svn 클라이언트 쓰는 사람들에겐 ‘여전히 svn 저장소로 보이도록’만드는게 가능하지 않을까 싶다.

일단 떠오르는 것만 간단히. 잘못된 부분이나 추가할 사항 있으면 댓글로 좀(…).

svn은 revision 번호가 존재함. git에서 (내부적으로) 적당히 tag달아서 그걸 기준으로 해석해서 보내주면 되려나? (클라이언트 동작이긴하지만 git svn을 생각하면 어렵지 않을듯)

svn은 몇 가지 (미리 정해놓은) svn:… 형식의 프로퍼티를 지원한다. 이걸 어떻게 흉내낼까? link 가 없다고 가정(…)하면 상당히 쉬울 것 같긴한데…
(물론 여기서도 svn:externals 문제가 생길 거 같긴 하다)
executable mode야 별도로 처리하니까 (파일 퍼미션은 별도로 저장하긴하니까) svn:executable은 처리해줄 수 있고, svn:ignore 도 .gitignore나 .git/info/exclude 생각하면 어찌 되겠지. (.gitignore에 가깝군…)

svn:keywords 같이 서버 수준에서 처리하는 기능은 GG. 이건 어찌 해볼 도리가 없다.

svn branch (copy?)를 어떻게 처리할까? git 브랜치 처럼 처리하면 망하지 않을까?

MIME 타입 처리?
http://stackoverflow.com/questions/3537575/can-git-store-the-mime-type-of-a-file-like-svn-does-for-browsing-html
로 보아서는 잘 안될듯하다.

svn은 (대부분의 응답으로) unified diff를 보낸다. git에서 diff를 딸 때 unified diff로 따는 게 있었던 것 같으니 이건 큰 문제가 안될 것 같다.

svn은 저장소를 재귀적으로 정의한다. git은 저장소를 `하나로’본다. svn의 서브 디렉터리 요청이 오면 이걸 잘 처리할 방법이 필요한 듯. git에 이런 명령어(혹은 object 접근 방법)이 있던가?; log 랑 diff는 적당히 제한할 수 있었던 것 같으니 큰 문제 아닌가?

SVN 에서 서버 접근할 때 일반적으로 쓰는 명령이 뭐가 있을까?

update, commit, ls, copy, move, rm, … 정도인가?

관련 글:

1. svn tag만들 때 svn:externals 리비젼 고정하기
2. git svn 동작이 거지같게 느껴지던 이유
3. git(on svn)이 대소문자만 다른 디렉토리를 커밋해버렸다

이전 글을 다 보신 분은 굳이 읽지 않아도 됩니다. 밑의 링크는 HTML5 지원하는 웹 브라우져에서 봐야 함.

NDC2011 – 마비노기 영웅전 서버 관련 세션 정리

Beamer — LaTeX .sty 중 하나 — 로 처음 작성한 슬라이드. 예전에 타카하시 메서드로 발표한 적이 있긴 하지만, ‘준비’만 따지고 보면 이게 이제까지 써본 툴 중 제일 쉬웠던 듯.
MacOSX용 키노트가 쓰기 편한 툴이긴 하지만, 내 영혼은 아무래도 *nix 터미널에 묶여있는 듯 하다.

결과물 자체가 PDF로 나오기에 아예 다른 출력포맷 신경 안쓰고 작업할 수 있는 것도 좋음. 결과물도 그다지 크지 않고…
다만 한 줄씩 혹은 한 문단씩 나오게 하는 효과를 만들면 이게 k 개 페이지에 쪼개져서(…) 페이지가 생성된다는 점은 좀 별로다만;

하지만 회사 스타일 문서 써서 만들려면 이걸 못 쓴다는 건 좀 심각한 단점. 아니다 내가 beamer 테마 파일 만드는 법을 익히면 되나?-_-;; 이건 정말 야크 쉐이빙일거 같은데?

관련 글:

1. 2011, 내 프로그래밍 언어는…
2. NDC 참관기: 게임 애셋 스트리밍 패치
3. C# 잡상: 2011-03-04

5월 말에 예비군 훈련을 다녀오고나니 (…), 내가 작성한 C++/Win32 기반의 서버 런타임에 문제가 발생했더라. 정확한 요인은 모르겠지만, 메모리 사용량이 팍 뛰었고, 32bit 프로세스의 한계로 사망 -_-

다행히 ipkn이 작성한 부하 테스트 툴로 원인을 좁힐 수 있었다. 해당 프로세스에 미리 할당하는 소켓 수 이상으로,

1. 연결을 계속해서 맺고
2. 과다한 트래픽을 흘려보내고,
3. 다시 끊고

…을 수 시간 반복하면 서버가 크래시하더라.

이미 수 개월 동안의 라이브 서비스 동안 별 문제 없어서 안정화 끝났다라고 생각했는데 그게 아니었던 모양.

처음 찾은 버그는 이런 거였다. 대략 소켓 래퍼 객체의 참조 카운트를 가지고 최종적으로 할당된 자원을 재활용하는데, 단 하나의 시나리오에서 이 패킷 버퍼와 소켓의 참조 카운트 해제하는 순서가 반대(…)로 되어있더라. 그래서 대략 k 시간의 코드 리뷰 후에 잡았음. 그나마 패킷 버퍼 쪽에서 문제가 되는 코어 덤프가 있었으니 Orz.

…그리고 이 상태로 다시 부하 테스트 시작. 또 죽는다? 다행히도 디버그 빌드에서도 재현이 된다. 문제는 heap corruption이라는 것? -_-;; 정확히 1 bytes가 0로 셋팅되더라.^[1] 그래서 서버 런타임 전체에서 1바이트 세팅하는 코드를 전부 뒤졌다.
그 결과, 일부 per-thread 타이머 객체가,

• 해당 스레드에서 타이머 객체가 종료되어 자원 해제
• 다른 스레드에서 해당 타이머 객체 invalidate

하는 경우가 있을 수 있더라. 역시나 참조 카운터 문제 -_-; 선형화처리 코드는 들어가 있지만, 해당 객체가 살아있다는 보장이 없는 상황이라, 대부분 잘 돌지만(…) 이렇게 레이스가 일어나면 얼마든지 맛이 갈 수 있더라;

이 두 가지 문제 해결하고나니 대략 (눈에 보이는) 버그는 잡은 거 같지만…
일단 부하 테스트는 잘 버티고 있다.

…근데 애초에 문제가 되었던, 갑자기 메모리 사용량 1G 점프하던건 뭐였을까? 십중팔구는 처리가 늦어지고, 그에 따라 센드 큐가 늘어나고, 그에 따라 처리가 더 늦어지고(…) 하는 악순환의 결과였던 거 같지만 -_-;

만약 크래시 덤프도 없고, 디버그 모드에서 재현 못했으면 어쨌을지를 생각하니 좀 끔찍하긴 하구나 -_-;

글쓰기

역시 공대생을 위한 글쓰기 수업을 들었어야 했나 -_-;
내가 얘기하고자 하는 부분이 아닌 걸 계속 써야하나?

예전에 책 번역 할 때도, 영어보다 한국어 실력이 더 문제란 느낌이었으니 에휴.

1. Win32 DEBUG heap이 마킹해주는 덕에 이건 파악할 수 있었다. 정말 다행임

OpenMP나 tbb, 혹은 MS의 Parallel Patterns Library 모두 일을 더 쉽게 만들어주는게 아니다. 그네들은 병렬 프로그래밍을 쉽게해주는 기능을 제공해 주긴 한다. 하지만 당연히 싱글스레드 프로그래밍보다 어렵다.
즉, 원래 목표여야 하는 “병렬 하드웨어 활용을 쉽게해주는 것”이 아니다. 이 툴들의 목적은 현재 단일 스레드로 작성한 프로그램을 , 어떻게 멀티스레드 프로그램으로 수정하면 병렬 하드웨어를 좀 더 잘 쓸 수 있을까 하는 경우를 해결하는 것이다.
이거랑 멀티코어 CPU를 잘 쓰는 일은 동일한게 아니다.

쉬운 길은 이미 “많은 프로그램들이 잘 하고 있는 일”이다.간단하게, 하드웨어가 병렬화가 되면 `할 일을 더 주면 된다’. (Gustafson’s Law)
웹 서버나, hadoop처럼 부하가 늘어나면 작업 단위를 처리하는 `프로세스를 더 많이 띄우면 된다’.복수의 프로세스(스레드)가 특정 상태를 공유하면서 / 업데이트하지 않는 이상, 이 방법은

• 작성하기 익숙하고 (익숙한 싱글스레드 프로그램이다!)
• 디버깅 하기 쉽고 (멀티스레드 프로그램은 비결정론적이다)
• 기존 코드를 거의 변경하지 않아도 된다

라는 엄청난 장점이 있다.
서버 프로그래밍의 — 특히 게임 서버 프로그래밍 — 목적은, 지연 시간을 일정 이하로 유지하는 수준에서 최대 처리량(throughput)을 얻는 것에 있다고 생각한다. 즉, 개별 서버 프로세스가 비슷한 일 — 프로세스마다 1개 채널의 로비를 처리한다거나 — 을 처리해서 부하를 적당히 쪼개고, 싱글스레드에서 처리가능한 수준^[1] 의 부하를 담당한다면, 굳이 이걸 omp/tbb/ppl 같은 걸 써서 복잡하게 짤 이유는 없지 않은가?

물론 공유 상태가 많으면 MT로 짤 수는 있겠지만, 그 경우에도 비슷한 원칙을 유지한다.

• 싱글스레드화 되는 부분 — 동기화 처리부분 — 은 메시지 교환 등으로 우회하거나, 최소화하고
• 같은 일을 하는 프로세스…대신 스레드를 여럿 둔다
• 그리고 이 스레드의 수만 늘린다

즉, 본질적으로는 일부분을 제외하고는 싱글스레드 프로그래밍을 하고, 이 부분을 늘려서 주어진 병렬 하드웨어를 잘 쓰자라는 것.

그러니까, 싱글 스레드 성능 향상이 목적이 아니라면, omp/ppl/tbb 다 그렇게 영양가 높은 얘기는 아니다라는게 내 생각이다.^[2] 오히려, 전체 구조를 잘 생각하고 똑같은게 여러 개 돌 부분을 찾고, 이 부분을 여럿 띄울 생각을 하는게 — 예를 들자면 마비노기 영웅전의 micro-kernel 틱한 구조에서 개별 서비스를 여러 개 띄우는 것 처럼 — 생산적인게 아닐까?

그 이전에(…) 서버 자체는 많은 경우 애초부터 멀티스레드로 짜고, 독립적으로 할 수 있는 부분도 많기 때문에 tbb같은게 적합할 태스크 패러럴, 혹은 데이터 패러럴한 워크로드가 아닌 것도 좀… 코어를 다 차지할 만큼의 스레드들이 있는데, 굳이 단일 스레드 프로그래밍에서 CPU  코어 여러개 쓰기 위한 방법을 가져다 쓸 이유가 있을까?

—

내가 리뷰 안 쓰는 무언가 때문에 이런 글을 썼다고 느끼면 “그게 다 기분 탓” 입니다.

1. 그러니까 엄한 지연 시간이 나오지 않는
2. 물론 일부분, 예를 들어 tbb scalable allocator라거나 concurrent container류는 그 자체만으로 쓸모있는 라이브러리이기 때문에 여기저기 쓸 곳이 많다. 그렇지만 parallel_for, parallel_reduce 같은게 정말 필요한가?

여기에는 하재승 군과 같은 팀에 있어서(…) 좀 더 우호적인 관점의 내용이 있다는 점을 생각하며 읽어주기 바람;

이하는 내용 요약

—

게임 오픈 혹은 대규모 패치 후에 서버가 폭주(?)하는 사례가 많다.

네트워크 스트레스 테스트 툴이 필요하다?

• 예상되는 스트레스 상황 테스트 / 반복 실행
• 미리 문제를 찾고 해결하자

Pros.

• 쉽게 테스트 작성
• 대량의 테스트 진행
• 테스트 진행 중 데이터 자동 수집 / 모니터링

미리 작성된 테스트 시연

간단한 채팅 서버를 가지고,

• 1 명 들어와서 채널에 메시지 말하고 나가기
• 100 명 들어와서 같은 동작
• 테스트 동안 모니터링한 결과 보여주기

잘 알려진(…) 올해의 게임 Minecraft를 가지고,

• 여러 마리의 봇이 로그인해서,
• 봇들은 (미리 지정한) 유저를 따라다니고, 유저가 삽질(마우스 왼쪽 클릭)하는걸 따라함(…)
• 100 명 수준이 되어가면 서버가 심하게 랙이 걸리는 걸 볼 수 있음^[1]
• 더불어, 이 동안의 시스템 모니터링한 그래프를 보여주기

테스트 자동으로 작성하기

• 클라이언트 -> 복수의 서버 군(로그인, 채널, 게임, 챗, 몬스터, …)의 통신을 캡쳐해서 자동으로 테스트를 작성
• 상대적으로 쉽고 간편하게 + 버그 재현에 써먹기
• 바로 캡쳐해서 쓸 수는 없다 -> 툴을 이용해서 쉽게
• 미리 만든 스트레스 테스트 용 아이디 (특정 prefix + 숫자)가 필요함

툴을 이용해서 테스트 스크립트 수정

한 눈에 패킷 보기, 패킷에 들어가는 값을 특정 전역 변수랑 연동/편집, 스크립트 내보내기… 를 처리하는 GUI 편집툴 제공

Client.Send_LoginRequest(A, "test"..index(), "testpass")
local pkt = Recv(A)
if pkt.__id__ ~= Server.LoginResult then fail() end

…같은 형식의 스크립트가 최종적으로 나옴.

결과 분석

• 가상 유저 별로 받은 패킷 순서, 전달된 패킷의 개별 값, 특정 메시지 간 시간, 특정 행동(로그인)에 걸린 시간 값 등등을 측정
• 서버 자원 모니터링

요약

프로토콜 파일 작성

• 캡쳐/스트레스 테스트에 이용
• 클라이언트 — 서버 간 패킷 내용 정의 ;(Python, lua, C#, C++ 코드 생성)
• 패킷 정의가 없으면 해당 프로젝트에 쓰는 방식을 분석하고 정의 파일 만들기
• 구조체 기반인 경우 아예 C++ 헤더를 파싱해서 만들기도 함
• 헤더/푸터,암호화,체크섬 등 처리 가능

덤

UDP 통신 / HTTP 통신 / 네트워킹 모듈 기능 테스트

계획

• 복잡한 테스트 수행 (장시간 반복하기; 현재는 쉘 스크립트로 대체)
• 테스트 결과 분석 강화
• 네트워크 상태 시뮬레이션 (패킷 로스, 지연 상황)

—

촌평.

온라인 게임으로 한정할 경우, 많은 네트워크 테스트 도구가 갖는 문제가 뭐냐하면,

• 부적당한 추상화 수준 : TCP/IP 패킷 레벨, HTTP 메시지, …
• 부하 테스트 시나리오를 생성할 방법
• 부하 테스트 시나리오를 유지 관리할 방법
• 충분한 수준의 부하를 생성할 방법
• 복수의 서버군이 있을 때 이에 대한 추상화는 어떻게 할지

등등?

이런 문제에 대한 접근법으로, 적당한 도메인 분리 + 개별 공략은 타당한 선택지라고 판단된다. 대략 서버 버너 구조 자체가,

• 프로토콜 데이터의 별도 표현(yaml)
• 메시지 캡쳐 / 편집 프로그램
• (수동) 추가적인 스크립트 편집
• 복수의 머신에서 동시에 부하 스크립트 동시 시작/종료/통계 처리

로 쪼개져 있다. 그리고 이 중 수동으로 스크립트를 추가 수정하는 부분만 빼면 많은 경우 그다지 복잡할 게 없다.

우선 추상화 수준의 문제.

사실 게임…이라고 해도 장르 자체가 다르면 기술적인 의미에서 추상화 수준이 서로 다르다. 그래서 ‘메시지’라는 좀 저수준이지만 공통(?)일 수 있는 수준을 잡고, 여기에 대해 UDP/TCP/혹은 응용프로그램 수준 메시지로 잘 쪼개서 처리하는 접근은 적당하다고 생각한다. 대략 게임이라면 TCP, TCP 기반의 메시지 (HTTP라거나? 전용 포맷?), UDP (전용 p2p 프로토콜 류) 정도를 생각할 수 있는데, 이거에 대해서 프로토콜 데이터만 기술해주면 대략 이 수준의 추상화는 메서드 호출처럼 표현할 수 있다.^[2] 메시지를 특정 형태로 기술하는 일은, 팀 내에서야 이게 공통 포맷이라(…) 시간이 0이 걸리고, 사내 다른 팀 껄로도 거의 전환 시간 없이 가능했던걸 생각하면 어찌어찌 가능은 할 듯 하다. 대략 엔지니어 하나 붙여놓고 하루 안에 적용이 가능했으니…^[3]

예를 들어 인증 메시지 보내는 것은: SendAuthMessage(utf-8-string-id, bytes-credential, bytes-session-key) 수준 정도로?

다음으로 메시지 캡쳐, 편집.

일단, 부하테스트 시나리오 생성을

• 패킷을 아예 캡쳐하고, 이걸 적당히 조작(시연 동영상을 보면 좀더 이해가..) 하거나,
• 아예 중간에 이걸 릴레이하는 서버 (개발팀이라면 언제라도 가능한) 를 두고 모든 메시지를 가로채거나
• 서버가 여러 대인 경우에도 이걸 적당한 스트림으로 보여주고, 일부를 병합하거나

하는 식으로 실제 메시지를 가지고 만들어내고, 이걸 lua 스크립트 수준에서 처리하면 된다는 점이…

복수 머신에서 부하 자체를 생성하는 일

머신 한 대에서 생성하는 부하에는 한계가 있다. 왠만큼 시간을 들여 짜고 + 튜닝하지 않고서야, 머신 당 유저 수는 크게 제한된다. 차라리 가짜 유저 간 상호 작용을 줄이고 머신 붙인 만큼 유저를 더 만들어 내는게 대략 맞는 방향인 거 같다.
부하자체는 테스트 스크립트를 시작하는 프로세스와, 이 테스트 스크립트를 받아 실제로 메시지를 보내는 k개의 프로세스를 써서 보내기 때문에 (물론 머신도 k개에 준하게…) 물리 머신 수만 충분하다면 원하는 수준의 부하를 만들 수 있다. 다만 밑단의 lua 스크립트는 짜야겠지만(…).

Q/A 팀에서 일일이 부하테스트를 짜는건 약간 힘들지 몰라도, 서버 프로세스를 짜는 프로그래머라면 큰 무리 없이 쓸 수 있는 수준의 도구라고 생각한다.

1. 테스트할 때 쓴 서버는 대략 Win7 x64, RAM 4GiB, Q8600 정도
2. 다만 UDP는 별도로 .dll을 짜서 python/lua 바인딩을 제공해줘야 한다…
3. 강연 때도 나온 얘기지만 아예 xml 기반의 프로토콜이나 압축, 별도 체크섬 같은거 붙이는건 큰 일이 아님…