일단 다음과 같은 가정으로 설치하게 했다:

1. (Dev) django app은 데비안 패키지(.deb)로 묶는다
2. (Deploy) .deb은 chroot-jailed sftp에 전송
3. (Deploy) 올린 애를 apt 저장소 형식으로 내보냄
4. (Service front-end) 이걸 자동으로 받거나, 원격 스크립트, 혹은 로컬에서 직접 설치
5. (Service front-end) 설치 작업 자체는 .deb의 postinst 를 이용한다:
   • 사이트 실제 코드는 .deb으로 포장된 python package 형식으로 설치
   • 사이트에서 읽을 일부 스태틱 데이터도 이 .deb에 포함.
   • 매우 간단한 wsgi application 정의하는 파일과 django 설정 파일을 특정 디렉터리에 복사하고
   • 기본 설정 파일(=django가 읽을 settings module)을 서버 정보를 이용해서 sed로 수정
   • static file 들은 적당한 mount 지점에 가도록 symlink 추가
   • 처음에 설치한 디렉터리를 이용해서 띄우는 설정을 /etc/apache/available에 추가하고 apache 재시작

…를 하는 상황.

근데 바꿀 수 있는 부분이 대략 이렇다:

• django: 하지만 python 기반 (뭐 wsgi 기반의…) 이어야 함.  ((Go로 만들고 싶은 생각이 약간 있긴 하지만 그건 근 미래에는 힘들 듯))
• apache: 맘 편하게 gunicorn + nginx reverse proxy 같은 고전적인 조합을 생각하는 중
• .deb 전송 방식으로 sftp^[1] : shell 권한을 주기 곤란해서 고른 것인데, 그냥 http put 으로 넣는게 더 나을지도?

django 기반의 사이트를 배포해 보신 분들의 의견을 구합니다. 아는 게 없는 동네라 뭔가 엄한 -_- 조합을 만들었다 싶기도 하고.

혹은 다른 WSGI 프레임웍을 썼을 때 좀 더 배포가 편했다거나 — flask나 cherrypy만 써도 이보다 간단할 것 같은데… — 하는 경험 있으면 들려주세요. 흑흑
상식적인(?) 방법은 fabric이나 puppet으로 배포하는 쪽인 거 같긴하지만; (혹은 chef?)

1. chroot jail이라 upload 디렉터리만 보이는 정도로

넥슨 김이선 님의 발표.

내용 요약:

돈을 벌기 전에는 배포 전 디버깅이 중요하다.
라이브 상황에서는 배포 후 디버깅이 더 중요해진다.

덤프 파일

특정 상황 — 특히 안좋은 상황 — 에서 프로세스 상태를 디버깅 용으로 남기는 것.
풀 메모리 덤프를 남기면 좋지만 커서(…) 미니 덤프를 남긴다.
상용 서비스까지 갔다면 미니덤프를 남기고 이를 수집해서 디버깅하는 시스템은 필수.

하지만 미니 덤프 디버깅의 현실은…

• 덤프 파일을 열었는데 심볼이 없다고 어셈블리 코드가 보이는 경우
• 여기서 죽으면 안되는데 왜 죽었나 싶은 경우?
• 콜스택이 깨졌다거나
• 풀 메모리 덤프를 남겼는데 내가 보려는 객체는 어디에?

덤프 파일과 pdb 파일 연결하기

• 미니덤프 헤더는 RSDS 헤더, GUID, age, pdb-path 등이 들어감
• pdb, exe, minidump는 이 GUID로 연결된다
• 심볼서버는 당연히 써야
• 보안 솔루션 (더미다 류) 을 사용하면 덤프 파일의 GUID가 바뀐다
• 하지만 COFF file format의 링크 시간을 기록한 타임 스탬프는 유지
• 클라이언트 덤프 수집단계에 미니덤프와 해당하는 PDB를 맺어주는 단계를 넣자(클라이언트 버전 정보; 타임 스탬프를 이용해서)

여러 개의 덤프 파일을 분석할 때

일어나지 않을 것 같은 일도 덤프 파일이 많으면 분석할 수 있음^[1]

• 분류 기준으로 EIP, callstack, 게임에 따른 정보(맵, 장비, …)
• 외부 모듈이나 말이 안되는 곳이면 어떻게하지? 클라는 환경을 통제할 수 없으니 외부 변수를 추적한다
• EIP와 다른 변인 (OS, CPU, GPU) 등을 보면 예상되는 것과 다른 분포인 경우가 있다 (=환경 편재)
• OS라면 드라이버 버그, CPU의 문제 (보통은 mainboard), GPU 문제, 외부 모듈 (보안 프로그램이나 해킹 툴)

사례 분석

1. DF의 코드 베이스를 VS 2003에서 VS 2008로 이전함.
2. 특정 유저 (소수) 에서 채널 선택하는 순간 HeapAlloc/HeapFree 중에 크래시 하는 버그 발견
3. Heap-corruption이라,
   • 게임 시작에서 채널 선택하는 부분까지의 코드를 리뷰
   • 이 영역에 많은 수의 trap code와 HeapValidate 코드 삽입
   • 하지만 문제는 발견되지 않음
4. 모듈 목록에 환경 편재가 있음: BFCO0GAF.dll 등의 알파벳/숫자가 섞인 특정 패턴의 모듈 발견
5. 해당 dll이 악성 프로그램이 삽입한 것; 2003과 2008의 heap 구현이 달라서 생긴 일

콜 스택이 깨지는 경우

• EBP, ESP 중 하나만 깨져도 콜 스택을 복원할 수 없다
• 이를 다음 휴리스틱으로 극복
  1. 스택 메모리에서 주소를 추려낸다 (모듈 정보의 주소 영역을 이용해서)
  2. 스택 메모리에서 스택 주소를 추려낸다
  3. 1 + 2를 해서 콜 스택을 추정
• 프로그래머의 해석이 필수

힙 메모리 문제

• 메모리 덤프가 있으면 디버깅에 큰 도움이 된다
• 하지만 모든 메모리 객체에 접근하는 건 쉽지 않음
• 메모리를 exhaustive하게 검색
• vfptr 값 이용
• typeid(T)의 구현 형태를 이용해서 타입 이름을 이용해서 검색

…이걸 포함한 오픈소스 툴을 공개

감상:

이번에 네 개 세션 밖에 못들었는데, 그 중 제일 괜찮은 강연이었다. 다음 세션을 회사 돌아갈 시간이라 못 들은게 아쉬움.

내가 예전에 했던 유사한 시도는 통계적으로 분류하고 / 적당한걸 찾을 수 있게 도와준다 정도였는데 (VS 안띄우게 하는게 목표였으니..) 이렇게 실제 사례를 바탕으로 한 내용을 알고 있었다면 훨씬 좋게 할 수 있었을 듯.
그리고 바이너리가 수정된 경우의 처리는 제대로 못했는데 — ipkn 패치해서 돌아가게 수정 — 이 부분에 대한 정보도 얻게 되어서 좋았다.

게다가 강연자 분이 “이런거 되는걸 모아서 새로 짜서 공유했습니다”라고 말한건 대박(…).
아마 `지식 공유’란 점에서 모델이 될만한 수준.

summerlight 님이 녹화한 영상도 토런트 시딩되고 있을테니 (촬영 가능한 세션이었음) 관심 생기신 분들은 한 번씩 보는걸 추천합니다.

1. 이건 이전 회사에 있을 때 내가 포스트모텀 디버깅, 그것도 최대한 많은 수를 수집해야 한다고 주장한 이유와 같음

HTTP 자체가 프로토콜 적으로 한계를 갖기 때문에 여러 가지 보완 방법이 제시되고 있는데, 현재 상태를 다른 수단으로 극복하기 위한 몇 가지 시도에 대해서 논해서 재밌었다.

구현이 궁금했지만 까본 적은 없었던 몇 가지 구현체 — FB 메신저, gmail에 달린 google talk — 를 분석하고 이에 대한 단점 (장점이야 HTTP 한계 극복이니) 을 논한 점은 +.
html5의 web-socket을 좀 더 자세히 다뤄줬으면 좋았겠지만 이건 스코프를 벗어나는 문제인 듯 하니 어쩔 수 없겠지.

앞으로 알아봐야 할 것, 생각해 볼 것들을 정리하자면,

• http가 주 프로토콜인 non-SNG 게임 서비스를 만들 일이 근 미래(3년 내)에 있을까?
• 그렇다면 html5 + web socket 기술이 충분히 침투한 상태일까?
• 모바일까지 지원한다면 결국 어느 기술을 골라서 쓰게 될까?
• 말미에 언급한 미들웨어 서버의 성숙도는 충분할까?

정도인데;

일단 http가 주 프로토콜인 서비스를 만들 일은 머지 않은 미래에 겪게될 것 같다. 지금 하는 일이랑 연관이 없긴 하지만(…).

표준화 속도나 사람들이 적응하는 속도를 따져보면 mobile 말고는 html5 지원율은 높지 않을 (낮을?) 것이고, web socket 침투율은 더 낮을 것 같다. 특히 브라우저 벤더에 따라 기본 보안 설정이 상이할 가능성이 높을 것 같음.

뭔가 별도 플러그인으로 가기엔 모바일 지원이 매우 힘들 것 같고, 강연에서 언급한 몇 가지 방식을 잘 조합하거나, 성숙도 높은 미들웨어를 고르지 않을까 하는 정도.

대부분의 문제를 잘 해결해주는(…) 미들웨어 솔루션을 만들어서 팔 수 있다면 좋겠다는 생각도 좀 들긴한다.

발표 자료는 http://ricanet.com/new/view.php?id=blog/120425 에서.

HTTP Protocol의 한계

http는 request/response protocol이다. 이로 인해서 클라이언트 쪽의 이벤트는
서버 쪽에 쉽게 전달할 수 있지만, 서버 쪽의 이벤트는 클라이언트가 요청하기
전에는 전달할 수 없다.

그런데 현재의 웹 쪽 트렌드를 보자면, twitter나 facebook, google mail (or talk)
같은 경우 실시간으로 메시지를 보낸다. 어떻게 하는걸까?

이를 극복하기 위한 기법들

기본적으로 꼼수다 — 프로토콜의 한계 때문에.

Polling

웹 브라우저에서 주기적으로 요청을 보낸다. (클라이언트 쪽 타이머 이용)
문제:

• 트래픽이 많다 / 서버 쪽 부하가 걸린다
• 지연 시간이 크다; 이벤트-클라이언트 요청 시간 차이 때문에. 그렇다고지연 시간을 줄이면 트래픽/서버 부하가 더 커진다.

Long-polling

클라이언트가 미리 요청을 보내고, 서버는 이벤트가 생기는 순간까지 기다렸다가
이를 모아서 (이미 온 요청에) 응답을 보낸다.
Facebook 메신저 구현이 이를 이용한다.
문제:

• 구현 복잡도. 서버가 요청이 이미 와 있는 경우와 그렇지 않은 경우를 구분해서 처리해야하는 등.
• 지연 시간; 응답을 보낸 후 클라이언트가 다시 요청을 보내올 때까지의 시차.

Hidden iframe

페이지에 숨겨 놓은 iframe을 통해서 메시지를 계속 흘려 보낸다. (서버가 응답을
끝내지 않는다) 그래서 http streaming이라고 부르기도 한다.
Gmail messenger(=google talk)에서 사용하는 방법이다.

문제:

• 응답이 끝나지 않기 때문에 클라이언트 쪽 웹 브라우저에 메모리 릭이 생긴다.
• 프록시 / 보안 프로그램이 응답이 완전히 끝나야만 이를 넘겨주는 경우가 있다.

Browser plugin

Flash, ActiveX 등을 이용. 사실 상 TCP 소켓처럼 쓸 수 있다.
호환성 문제가 너무 커서…

WebSocket (html5)

javascript 단에서 진짜 소켓을 쓸 수 있다. 표준화가 아직이라 (protocol은
결정되었지만, API가 아직 unstable).
기존 웹브라우저와의 호환성 문제.

WebIRC (=IRC web-bridge for smartphones) 만들기

Long-polling이 호환성이 좋고 (최소한 iOS, android를 지원해야 했음),
구현이 재밌어 보여서(…) 이를 구현함.

프로토콜

• InitLog: 각 채널 최근 로그 k 줄을 요청
• UpdateLog(last\[\]): 각 채널에서내가 마지막으로 받은 로그 ID가 last일 때 그 이후 로그를 요청

서버 구현 이슈

HTTP 핸들러가 새로운 내용이 없으면 대기하는 것.
vs.
Event listener가 새로운 내용이 왔을 때 대기 중인 스레드(의 요청)를 깨우는 것
사이의 레이스 컨디션.^[1]

node.js 류를 사용하면 오히려 쉬웠을지도 모르지만 이미 python으로 구현.

Webserver Architecture

동시에 살아있는 연결이 많아서,

• 커넥션 당 1 스레드 때문에 메모리 병목
• 고전적인 웹 서버의 경우 더 중요한 페이지 뷰보다 동시 접속 수가 문제
• Gevent로 쉽게 해결
• Long-polling에 맞춰서 구현했더니 stateless 프로토콜이 되어 네트워크 단절에 강해졌다.
• 채팅 보내는 것이 네트워크 불안정엔 약했음. 이걸 극복하려니 사실상 TCP 류의 프로토콜을 HTTP 위에 재구현하는 형태가 되어버리게 되서…

Middlewares

앞에서 언급한 방법들엔 정답이 없다. 각 방법의 장단점이 다름.

orbited2, socket.io 같은 미들웨어가 있다.
그렇지만 정작 제작 시점에 사용하려던 orbited 사이트가 내려가 있어서
long-polling을 직접 구현.

Orbited

orbited.js + *application.js* — orbited server — application server

위의 형태로 구성. Web-router + firewall의 역할. Legacy TCP 응용프로그램
서버인 경우에도 쉽게 통신할 수 있다.

socket.io

nopde.js 기반. 메시지 단위 전송을 지원한다.

확인해야 할 사항

• 연결 당 서버 리소스 소모량
• 연결이 불안정하면 어떻게 되는가?
• 웹 브라우저를 껐다켜도 괜찮은가?

웹-게임 연동

이런 기술을 쓰면 웹 게임에서도 네트워크 제약(http 문제)이 *거의* 없어진다.

WoW 전정실, 아이온, 마비의 거래소, 넥슨 홈이나 스팀의 업적 시스템 구현이라거나,
게임 웹 채팅, 친구 게임 참여 알리기, 우편 도착 알림 등의 실시간 기능이 가능해질듯.

결론(?): 취미 프로젝트 좋아요(…)

1. 내 생각, 그리고 최치선 군의 의견을 조합하자면, 저건 pthread condvar 류의 동기화 도구를 사용하면 해결 될듯 함. 치선 군이 실 서비스에서 사용하고 있는 추천 구현체는 gevent의 Queue (monkey-patching하는).

사용한 도구는 Chrome용 Pagespeed 확장기능. 여기서 네트워크 탭을 이용해서 오래걸리는 기능을 하나씩 제거했다.
최적화 하기 이전 측정치는  다음과 같다.

WordPress JetPack 관련
이 플러그인엔 적어도 두 가지 문제가 있다. 우선 통계 플러그인이 제 3자인 quantcast 쪽에 js파일을 큰 쿠키를 던져 요청하고, 이걸 실행한다. 위에서 quant.js, pixel;… 에 해당하는 내용. 이게 적어도 500ms는 걸리더라. 이게 이전부터 꽤 이슈였던듯. Respecting User Privacy in WordPress에 따르면 2011년 초 이전부터 있던 일이란다. 이슈화돼서 그런지 이에 대한 방책도 있다. WP DoNotTrack이란 플러그인이 이에 해당하는 DOM 삽입을 차단해준다. 이걸 쓰면 이 500ms를 줄일 수 있더라.그리고 쓰지도 않는 gravatar hovercard관련으로 로드하는 js 파일도 지연시간이 꽤 큰 편. 게다가 css까지 로드 하는 시간을 생각하면 아주 악몽이다. 저 위에선 6초 넘게 날려먹었음. (분산도 커서 더욱 거지 같기도하고). 첫 js 로드도  길고, 얘가 로드하는 파일도 다운로드가 오래 걸리고…
하지만 이게 어이 없었던건 — 난 켜지도 않은 기능이니 — 데이터베이스에 원래 있어야 할 옵션이 없어서 그렇다. 다음 항목을 wp_options 테이블에 추가하면 됨. (wp 부분은 설치 설정에 따라 다름)

mysql> insert into wp_options (option_id, option_name, option_value) values (NULL, ‘gravatar_disable_hovercards’, ‘disabled’);

이걸로 적어도 500ms ~ 3000ms 정도를 벌 수 있다.

 

블로그 테마 관련

위의 두 가지를 제외하면 다음 내용들이 적당히 튀어나온다.

1. 블로그 내용 시작 부분에 Google Transliteration관련 스크립트를 로드하더라. 이건 내 블로그엔 필요 없는 듯 하니 제거. jquery도 구글 서버에서 가져오게 수정.

2. 서버의 vhost 중 내 블로그만 mod_pagespeed 를 적용해 봤다.^[1] wp supercache가 문제를 일으키길레 일단 이 플러그인은 삭제. 그리고 .htaccess에서 켰던 mod_deflate 강제하는 것도 껐다. 어차피 mod_pagespeed가 따로 로드하고 적용함. 이거 적용한 후엔 html 타입으로 가는 컨텐츠에 각 파일 별 만료 태그, css sprite, caching등이 자동 적용된다. 약간은 빨라지는듯.

3. 최근 댓글 보여주는 것도 잠시 생각하고 껐다. 이건 이글루스 블로그들을 따라 해본던데 좀 별로인듯.

4. 더불어 CC라이센스 플레이트에 붙어있는 아이콘 이미지 로딩이 느리길레 역시 제거함.

 

최종 결과:

이 결과 대략 800ms ~ 900ms 정도에 페이지 로딩이 되고, 최종 렌더링도 1.3초 수준에 해결.

 

1. 사실 캡쳐한건 이 모듈 적용 후임

작년에 지급 받은 머신 셋팅을 수정해서 어떻게 빌드 속도를 올렸는지 정리. 아마 한동안 업으로 Win32에서 C++ 할 일은 없을 것 같아서 기억이 사라지기 전에 정리.
저 머신 자체가 내 손을 이미 떠나서 틀린 부분이 있을테니 발견하면 지적 좀 해주시길.

머신 스펙은  대략,

• CPU: intel i7-2600
• DRAM: 16 GiB
• Storage: intel SSD 80 GB + SATA HDD 500 GB

그리고 SSD 용량이 적어서 아래 같은 일을 추가로 했다.

• 4 GiB의 RAM drive를 할당하고, TEMP, TMP에 해당하는 디렉터리를 RAM 드라이브에 맵핑
• VisualStudio와 Windows Platform SDK는 SSD에 설치
• 기타 프로그램(오피스나 LaTeX)은 HDD에 설치
• 소스 체크아웃은 HDD 쪽에
• 빌드 스크랫치도 HDD 쪽에
• IPCH 파일 저장되는 위치 변경. 방법은 민장님 블로그의 “Visual Studio (C/C++) 2010 몇 가지 팁” 참조

대략 이 정도만 설정해도 꽤 빨라지더라. 이전 머신 (Q8600 + 4GiB RAM + HDD only) 에서 빌드할 때 20+분 걸리던게 2+분 수준으로 줄어듦. 예전엔 인크레디빌드 써봐야 빌드 시간이 18분 수준이라 안 쓰느니만 못한 꼴을 몇 번 봤고, 머신 변경 후에는 아예 안 쓰게 되었음. 최대 코어 수도 12개던가로 제한되어 있기도 하고(구입한 라이센스 문제).
그 원인이 된건 다음 것들인듯.

• IO가 두 디스크에 분산되서 소스 로드 속도가 빨라졌다; 어차피 Windows 헤더와 개발 중이 프로그램 헤더가 모두 로드 되야 하니…
• VS가 북키핑 용으로 쓰는 듯한 일부 .log, build.unsuccessful^[1] 파일들 (내용물이 없거나 매우 짧은) 을 임시 디렉터리에 해당하는 곳에 잔뜩 쓴다. 이게 RAM drive로 옮겨가서 디스크 IO 감소 + 분산
• CPU 아키텍쳐 변화 (무려 두 세대) + 코어 수 증가(4에서 8로)로 단일 파일 컴파일 속도 증가
• Win32/x64가 다 있는 경우 개발 중에는 x64 빌드만 사용. 빌드 / 테스트 수행 시간 모두 짧더라

등의 이유로 빨라졌다고 생각한다.

궁금한 것:

• 모든 소스가 SSD 두 개, 혹은 SSD RAID 위에 올라가 있다면 좋겠지만 그런 설정은 받아본 적이 없으니 궁금증만…
• 빌드 스크랫치 전체를 RAM 위에 올려놓고 싶긴한데, ECC RAM 아니면 살짝 불안하기도 하고, 그 정도로 메모리를 풍족하게 써본 적도 없고…
• 여기에 unity build를 섞었다면 어땠을까 하는 것..

해보신 분들의 의견을 구합니다(…).

PS. 근데 가장 좋은건 Google이나 Microsoft 처럼 빌드 팜이 있는 거겠지만, 그 정도의 엔지니어링을 하는 건 아니었으니…

1. 정확한 파일 이름은 누가 좀..

iPhone은 정리에는 그다지 좋은 기기라고 못하겠다. 내가 생각하던 문맥을 저장하기엔 내 활용 방법의 문제거나 기기가 부족하거나; 여하튼 기억나는 글들을 여기 정리하자면 (twitter는 정리가 불가능하니 제외),

웹 서버 아키텍처와 프로그래밍 모델의 진화 http://ricanet.com/new/view.php?id=blog/110903 (node.js의 I/O 모델을 점검하기에 좋은 글)

Node.js의 소개글 들에 대한 유감 http://himskim.egloos.com/3810574

이에 대한 홍민희 님의 글 http://blog.dahlia.kr/post/18300740247

그리고 다시 (홍민희 님의) 비동기 I/O 프로그래밍 모델 관련 글 http://blog.dahlia.kr/post/18355002657

이에 대한 내 생각을 정리하자면:

1. node.js는 hype이라 생각한다. node.js 광신도(…)들이 말하는 장점은 이미 오래된 얘기고 (이벤트 기반의 비동기 I/O 모델, 단일 이벤트 루프와 그로 인한 싱글 스레드의 단순함), 이런 시도를 하는게 node.js만 있는 것도 아니다. 다만 세상에 JavaScript 프로그래머가 많기 때문에 그렇게 느껴지는 것 뿐이지. 서버 혹은 백엔드 프로그래밍에선 너무 오래된 — (게임) 서버 프로그래밍을 주로 하던 이들 사이엔 이게 왜 이슈가 되는지 궁금해하는 사람들이 나온다 – 이슈라서 말이지.

다음 언어들로도 `흔히’ CPS 스타일의 프로그래밍을 할 수 있다. 그리고 이 언어들 모두에서 node.js에서 `하면 안된다’라고 주장하는 한 이벤트에서 긴 계산을 하는 일도 실행 모델에 따라선 해도 된다. 그리고 이 언어들에선 `흔히 하는 일’에 불과하다.

Go: goroutine 자체가 일종의 CPS 스타일 프로그래밍이다. 그리고 일반적인 이벤트 큐 처럼 쓸 수 있는 channel 개념 역시 존재한다. 그리고 이 두 개념을 최대한 활용해서 만든 언어가 Go다. 자세한 내용은 내 과거 포스팅을 참조하자 (http://rein.kr/blog/archives/tags/go) 개인적으론 이런 류의 I/O 비동기 / 멀티플렉싱을 생각하고 짠다면 Go가 가장 깔끔한 프로그램이 나온다고 생각한다.^[1]

C#: C#의 익명 함수 (delegate라고 부르던데) 역시 이런 CPS 스타일로 프로그래밍 할 수 있다. Nexon의 `마비노기 영웅전’과 `마비노기 2′도 이런 개념을 활용해서 서버를 구현했다. 2011년 NDC 세션의 내용을 정리해놓은 것처럼 (http://rein.kr/blog/archives/2696, http://rein.kr/blog/archives/2671) 이걸가지고도 JS에서 흔히 하듯이 성공/실패 처리를 cps로 작성한다.

C++: C++11의 lambda 혹은 그 이전의 std::function^[2] 을 이용하면 역시 CPS 형태의 코드를 작성할 수 있다. 내가 작성한 게임 서버 라이브러리 역시 이를 이용한 CPS 스타일의 코드가 포함되어 있다.

2. node.js가 단일 스레드, 즉 단일 문맥만으로 처리하기 때문에, computation-intensive한 작업은 처리할 수 없다. 그래서 어쩔 수 없이 백그라운드 태스크 큐 등을 써야하고, 이로 인해 생기는 지연 시간(latency) 문제는 극복할 수 없다.
게임 서버에서도 node.js처럼 (혹은 그보다 낫게)

• 복수의 스레드가 네트워크 이벤트(read/write)를 비동기로 처리하고,
• 네트워크 이벤트를 서버 메인 스레드(그러니까 논리적으론 단일 스레드 프로그램)로 전달하고,
• 서버 메인스레드가 내부 로직을 처리해서 다시 네트워크로 보내는

구조를 사용한 서버들이 있다. 다만 이 경우엔 계산 량이 많은 경우 지연 시간이 길어진다. 그것도 게임 상에서 상호 연관이 없어 보이는 부분들 사이에 영향을 주는 형태로 -_-;
게임 서버는 웹과는 좀 다르게 persistent storage에 다 저장하지도 못하고, 각 연결 간에 상호 작용도 많아서 어쩔 수 없이 생기는 문제이긴하지만 맨 첫 글에서 얘기하는 것 처럼 node.js가 `유니크’한 것은 아니다. JavaScript로 서버 프로그래밍을 진행한다는 것은 꽤 참신하지만 말이다.

그리고 서버 메인스레드가 1개가 아니라 복수개 일 수도 있고 — 내가 본 코드에선 이게 주류다 — 걔 중에도 IO 스레드가 full swing을 하돼 non-blocking한 알고리즘을 이용해서 복수의 큐를 사용하고, 블럭킹을 제거한 구현체도 있다.

3. 프로그래밍 모델은 CPS는 `쉽게 만들어낼 수 있지만’, 프로그래머에겐 꽤 골치거리라 생각한다. 홍민희 님의 말대로 가장 쉬운 형태는 co-routine일 것이라 생각한다. CPS처럼 이전 문맥에 대해 생각할 필요도 없고, 불필요한 nesting (node.js말하는 거임) 도 필요치 않다. 다만 이 경우에는 언어적인 수준에서 지원하지 않으면 안된다. 불행히도 내가 사용하는 주요 언어인 C/C++의 경우 co-routine을 사용할 수단은 OS fiber수준 정돈데, 이 경우엔 다른 동기화 객체들을 쓸 때, 동기화 단위가 스레드라서 fiber끼리 switching할 때 지옥을 보게 된다. 하지만 node.js 정도의 프로그래밍 모델에선 이게 가장 간편할 것이다. 각 연결 별 문맥끼리 상호작용이 적다면 더더욱 말이다.

1. 이 언어를 만든 회사가 Google이란 생각을 하면 더 그렇다
2. 혹은 그 이전 구현체인 std::tr1::function, 혹은 이거랑 별반 다를게 없는 boost::function을 생각하면 더 이전부터

크게 세 가지 주제를 다룬다:

1. 표면적인 것 개선하기 (Surface-level improvements): 변수 명 짓기, 코멘트 달기/달지 말기,
2. 반복문과 로직 단순하게 만들기 (Simplifying loops and logic): 읽기 쉬운 구조로 짜기; 중간 변수 뽑기; 거대한 expression쪼개기 등등
3. 코드 재조직하기 (Reorganizing your code): 리팩터링에 가까운 이야기들; 한 번에 하나의 일만 하게 코드 뽑아내기 등등
4. (덤. 추가 주제; 테스팅만 다룸)

대략 이런 예제들이 나온다^[1] :

pp. 78 – 79 의 중첩된 루프 제거하기:

for (int i = 0; i < results.size(); i++) {
    if (results[i] != NULL) {
        non_null_count++;
        if (results[i]->name != "") {
            cout << "Considering candidate…" << endl;
            // …
        }
    }
}

를 이렇게 바꾼다:

for (int i = 0; i < results.size(); i++) {
    if (results[i] == NULL) continue;
    non_null_count++;

    if (results[i]->name == "") continue;
    cout << "Considering candidate…" << endl;
    // …
}

뭐 이렇게 간단한 거 말고도 리팩터링 책에서 말하는 메서드/멤버 함수 뽑아내기, 한 메서드/멤버 함수에서 한 가지 일만 하기 등등 같은 것도 다룬다.

엄청 큰 내용을 다루는 것은 아니지만,

1. 읽기 쉬운 코드에 대한 (저자 주관이 담겨있지만) 개념 정리

2. 간단한 실례들.

3. 적당한 follow-up 글/책을 알려줌

정도가 있으니 어느 정도 `읽기 좋은 코드’에 신경을 쓰게 될 것 같고, 이 이후에 따라가기도 편한 듯 싶다.

게다가 챕터 구성이 처세술 책 같다 – 이거 칭찬임; 중요한 내용을 서두에 던지고, 설명하고, 요약하는 구성을 사용하기 때문에 머리에 잘 남는다.

ps. 정작 이 책을 읽었으면 하는 사람들은 안 읽을 거 같음. (…)

1. 예제는 C++, JavaScript, Python, Java(?) 위주; 어려운 문법은 안 나옴

사실 이런 구성이 된 건 예전에 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.

(강조는 내가 넣은 것)

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

• 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 기반 서비스를 좀 더 해도 될 것 같으니 내년을 기약 

• 매일 매일 얼마나 많은 덤프가 나오는지,
• 가장 많이 발생한 원인 (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 이상은 안 나오겠지 정도로…

운영 팀에서 "서비스와 데스크톱 상호 작용 허용" (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 참고

• 팀이 바뀌었다
• 모 게임의 서버를 새로 짜는 작업을 하고 있다
• 회사에서도 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 로 넘기는 형태의 프로그래밍에서 작업할게 거의 없다

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. 혹은 사후 디버깅. 크래시 덤프를 가지고 진행하는 디버깅

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

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

간단히 말해서, 우리가 현재 쓰고 있는 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년에 켄 톰슨과 함께 튜링 어워드를 받았다

• 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++ 메타 파일도 전부 이전

• 팀장 권한으로 새 머신을 신청할 수 있다는 사실을 확인했고,
• (이를 이용해서) 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. 석사 학위 없으면 병역 특례 자격이 없으니

어제 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를 통해서는 지난 달에 발매되긴 했다.