rein's world

또 이사

rein — Thu, 02 Sep 2010 01:09:51 +0000

어제 이사했음.

이번엔 그냥 살던 곳 근처로 이사했다; 아들이 돌이 다 되어가다보니 너무 활발해서(…) 넓은 집으로 이사.

이사하는 동안 아내는 아들 데리고 친구 집에 가 있었음; 아들은 돌아와서 신나게 뛰어 다니더라…

이미 내가 포장하기엔 짐이 너무 많아져서(…) 포장이사를 했다. 하지만 오전 8:30에 오겠다던 업체는 9시 넘어서야 도착. 일단 시작이 늦어지고(…).

책 많다고 불평하면서 – 네들이 와서 견적 내고 갔거든… – 여튼 이사는 진행. 약 12시쯤 짐을 다 싣고 출발 … 하지는 않고 점심 시간. 1시 쯤부터 실제로 이사갈 집에 가서 짐을 풀기 시작했는데, 대략 다 옮기고 청소(?)를 하고나니 오후 4:10분 쯤.

근데 불평은 좀 많이 해야겠다. KT 익스프레스 이 잡것들. 일단 일으킨 문제들. 비중 무관하게 생각나는 대로,

장판 찍어먹기 – 장판 전부 새로 깐건데 Orz
청소 대충하기 – 내가 결국 밤 11시 까지 다시 청소했다
화분 엎어버림 – 아 놔
요금에 포함된 사다리차 이용 안 했으면서 요금은 받아갔음…

게다가 정리 센스는 대체 =_=.

오늘은 클레임의 날이 될 듯…

No related posts.

C++의 유일한(?) implicit const_cast

rein — Wed, 25 Aug 2010 00:45:28 +0000

C++에는 (아마도 유일한) 묵시적 const_cast 가 있다. 바로,

 char* str = “hello, world”;

이건 C++이 (최대한) C와의 하위 호환성을 가지려다 보니 나온 문제다. C 표준 라이브러리의 수많은 문자열 처리 함수들이 char* 을 인자로 받긴하지만, 의미 상으론 const char* 인 경우가 대부분이기 때문;

만약 const char* –> char* 을 명시적으로 바꿔야 한다면 많은 수의 C 코드가 C++ 컴파일러에서 컴파일되지 않게 된다. 그래서 이건 묵시적으로 const_cast 을 해 버린다.

하지만 모든 C 문자열 처리 함수가 const char* 의 의미로 동작하는건 아니다. 그래서 예전 버전의 Mozilla 에선 이와 관련한 버그가 있었다. 공유 문자열 버퍼를 strchr 같이 실제로 버퍼를 조작하는 함수에서 문제가 생기는 것 – const semantic이 깨지는 것.

여튼 지금 문제는 이게 아니라(…), 오전에 everclear 군이 제기한 코드;
아래와 같은 코드가 있다. 왜 성공적으로 컴파일 될까?

struct A {

 int& a;

 explicit A(int& _a) : a(_a) { }

A(const A& rhs) : a(rhs.a) { }

};

const A&인 rhs.a 는 const int& 가 되야 하지 않나? 비슷하게 int& a 대신 int* const a 여도 저 코드는 잘 동작한다; 대체 왜 이럴까?

svn tag 만들 때 svn:externals 리비젼 고정하기 (2)

rein — Tue, 17 Aug 2010 02:03:51 +0000

얼마 전에 svn 에서 tagging 할 때, svn:externals 로 링크(?)된 저장소들의 리비젼을 고정하는 스크립트를 작성했다. pysvn 이 있고 python 이 깔려있으면, svn copy 후, svn:externals 를 하나씩 찾아서 리비젼을 고정시키는 스크립트다.

이 스크립트의 문제: SVN은 svn:externals 문법이 하나가 아니고, 저 스크립트에선 해당 문법을 전부 지원하는건 아니다. 일단 1.5+를 생각하면 (최신은 1.6.x) 두 가지 형태의 문법이 있다.

example_lib –r 100 svn://example.com/repos/subdir 처럼 local-directory [-r rev] svn-repository-uri 형태
file:///home/johndoe/repos/subdir johndoe_lib 처럼 [-r rev] svn-repository-uri local-directory 형태

일단 순서가 바뀐다. 이래서 맨 처음에 잘 해야;

그리고 두번째 형태는 pegged-form을 지원한다. 첫번째 형태는 pegged-form 을 지원하면 안됨(…).

svn-repoistory-uri@rev local-directory

같은 형태가 가능… 당연한거지만, –r rev 사이의 공백은 없어도 됨. 진짜 파싱하기 귀찮다. 그리고 마지막 변형으로, 두번째 형식에선 svn-repository-uri 를 상대 주소로 표현하는 문법이 들어갔다. ^/, ../, //, / 로 시작하면 각각 특정 저장소 주소의 상대 주소가 되는데,¹ 이 문법도 인식 해야함;

svn help propset에 나오는 svn:externals 설명에는 이전 문법에서도 상대 주소가 될 것 처럼 적어놨지만 (모호성 얘기도 그렇고), 내가 쓰는 svn 배포판(collab.net svn) 에선 오류를 내면서 처리 안된다. 혹시 다른 클라이언트 쓰고 있는 분은 테스트 좀(…).

여튼 이런 svn:externals 문법을 전부 인식하도록 스크립트 업데이트.

스크립트 링크: http://rein.kr/archive/frozentag.py

svn help propset 하면 설명이 잘 나온다

저장소 서버 업그레이드 기록

rein — Mon, 16 Aug 2010 01:40:38 +0000

지난 주 후반 부에 사용 중인 Perforce/Subversion 서버가 올라가 있는 서버를 업그레이드 했다.

기존 시스템이 메모리가 부족해서(4GiB RAM on Windows Server 2003 R2; x86), 메모리를 증설하고(->8GiB), OS를 새 것으로(Windows Server 2008 R2; x64) 만드는 작업이 이루어졌다.

물론 이러다 저장소에 문제 생기면 말 그대로 망하는 거라, 일단 백업 작업이 진행;

Perforce 서버 셧다운
전체 Perforce 서버 백업 (depot, journal, checkpoint …)
백업된 데이터 복사. 이건 외장 하드 디스크¹ 로.
Subversion 저장소 전체를 hotcopy
hotcopy된 저장소 네트웍 백업. (별도 HDD인지라 3과 동시 진행되었다)

이 후에 복구 작업 시작. 사실 저 백업은 최악의 경우를 상정하고 한 거라, 서버 업그레이드 / 재 설치 중에 별다른 문제는 없어서 1~5는 그냥 백업만 한 번 더 한 일이 되었지만(…).

Perforce 서버 재 설치 후, 저장소 디렉터리를 지정하고 실행하는데 서버가 안 뜬다? $P4ROOT 환경 변수 문제도 아니었음. Perforce 버전이 올라가서 저장소 업그레이드를 수행해야하는 문제였다. 업그레이드 후 서버 정상 동작.

Perforce 서버 주말 백업 스크립트 테스트. 안 돈다? 뭐가 문제인가… $P4PORT 환경 변수를 클라이언트 프로그램에서 요구하더군. 이거 설정하고 정상 동작 시작.

Subversion 서버 재 설치. Collabnet 에서 subversion 관련 바이너리만 배포하던게 없어졌더라; 그래서 collabnet edge 서버 설치하고, 거기 있는 svnserve.exe 바이너리만 이용하기로(…).

sc create 로 서비스 등록하고 서비스 시작. svn.conf 를 인식하지 않는다(…). SASL이 동작하지 않아서 그냥 구 버젼 바이너리 가지고 있던걸로(32bit 이긴하지만; 이쪽은 메모리 문제가 없었으니),

오늘 출근해보니 SVN은 주말 백업이 이루어지지 않았다. 아마도 퍼포스 백업 스크립트가 먼저 돌아야하는데, 이게 백업 완료 후 리붓해서 그런 듯. 순서 바꾸고 다음 주 테스트를 기다려야.

+ 근데 퍼포스 서버는 왜 죽었을까? 아무도 사용하지 않을 시간 대 인데;;;

네트워크 복사로는 안정적으로 초당 10메가 바이트 이상 전송한다고 해도 대략 17 시간에서 18시간 걸릴 양이라

C++ 0x 와 VS 2010 관련해서

rein — Tue, 10 Aug 2010 03:18:19 +0000

신입 사원 대상으로 발표한 내용. 몇 가지 이유로 약간의 수정 사항이 있습니다(…).

C++0x와 VS2010

왠지 팀 세미나에서 걸렸던 시간을 생각해서 빨리했더니 예정 시간 절반에 끝나버렸다 Orz

+ 라이브 팀이 많아서인지 생각 외로 당장 VS 2010 을 쓰는 인원은 많지 않을 듯…

The Incops Strikes Back!

rein — Thu, 29 Jul 2010 13:48:24 +0000

제목이 뭔가를 떠올리게 한다면, 그건 다 오해다. (기다려달라?)

화요일 저녁에 퇴근하려는데, 옆자리의 개발자 분이 나를 부른다. 내가 개발하는 라이브러리에서,

“Debugger 붙여놓고 띄워보면 First chance exception이 나요. Access violation 이고 0×0000 0000에 뭔가 쓰려고 합니다”

라고.¹

일단 해당 자리의 디버거 창에서 살펴본 봐로는, 내가 수 주 전에 추가한 WSASend 호출 횟수 줄이는 코드에서 나온 문제인 듯 했다. Send-Queue에 패킷이 여러개 쌓이면, 이걸 모아서 전송하는 루틴을 추가했는데, 이 안에서 저 first-chance exception이 발생.² 일단 화요일엔 집에 어머니도 와 계시고 해서 바로 퇴근하고 다음 날 오전에 추적하기로 했다.

First chance exception 이 발생했다곤 해도, 프로그램이 실제로 크래시하지 않는 걸로 봐선, 어딘가에선 처리 되고 있단 얘기니 좀 안심하고 다음 날 디버깅 시작. 출근해서 코드를 열심히 들여다 봤다. 대체 어디서 문제가 생길까? 일단 내 머신에선 재현이 안되더라. 그래서 일단 저 문제를 발견한 개발자가 출근할 때 까지 기다렸다. 그리고 얘기해주는 환경을 다 끌어 모아서(플랫폼 + 컴파일러 버젼을 맞춤) 테스트.

발생하지 않는다?!?!?!?!. 해당 개발자 자리에 가서 하면 한 번에 재현된다. 그래서 잘 알려진 WinSock 관련 first-chance exception 문제처럼, 이것도 MS가 포기(?)한 버그인가 싶어서 MS에 있는 모 선배에게 물어볼까 하고 있었다. 그래도 다른 선임분의 말을 듣고 다시 디버깅하는데, 콜 스택 모듈에 보니 수상한 dll 이 하나 있더라.

anywall3.dll 이게 뭘까? 저 네이밍으로 볼 때, 저주받을(…) 삼성 SDS의 인캅스(incops)를 연상케하는데… 여튼 몇 가지 테스트를 더 해본 결과:

Incops3 가 없는 시스템에선 당연히 저 DLL이 콜 스택에 안 보인다. 그리고 저 문제도 없다….

=_=

더욱 씨니어인 다른 개발자 분의 말로는, 정확히 같은 케이스는 아니지만, 인캅스 적용 후 그런 문제를 경험하고 있다고… 나는 계속 서버 쪽 개발만해서 x64 환경만 쓰다보니 — x64에선 인캅스가 안 돈다 – 다행히 안 겪은 것 뿐이었던 듯?

결론: 개발자의 시간과 노고를 갉아먹는, 내 컴퓨터 공학 석사/학사 학위를 걸고 쓸모 없는 프로그램인 삼성 SDS Incops 좀 쓰지 맙시다. 이 회사에서도 사실 상 사용을 포기한 툴이기도 하고 – 존재 의의 중 하나가 USB 로 파일 복사를 막는 기능이 있다. 근데 “전혀 막지 못하는 버그(헛점?)”가 있는데, 리포팅하고 나서 수 개월 후에 패치는 받았다는데, 전사 적용을 못 하더라. 그리고 이젠 다른 툴을 쓴다. 인캅스 자체는 꼭 설치하지 않아도 된다고 하더라…

First chance exception에 대해서는 MSDN 블로그의 이 글을 참고 하자.
실제로 구현한 최적화는 이런 내용이다. MS Win32 WinSock 에 존재하는 시스템 콜인 WSASend 는 좀 특이하게(?)도 – 혹은 일부 UNIX 시스템에 익숙한 사람이라면 sendv() 함수를 생각하면 된다 – 하나의 바이트 스트림을 전송하는게 아니라, 일련의 바이트 스트림을 전송하게 해준다. 즉 pointer + length 를 이용하는게 아니라 pointer + length의 배열을 인자로 받아, 이를 전송해 준다. 그래서 Send-Queue에 쌓인게 많으면, 이걸 여러 번 쏘거나(system-call 수가 많다), 하나의 배열로 합치거나(추가적인 메모리 할당 및 복사가 필요하다)하지 않고, 단순히 이 버퍼들에 대한 주소 + 길이 쌍을 배열에 집어넣고 WSASend를 호출하는 것.

리뷰: 노인의 전쟁 3부작

rein — Thu, 29 Jul 2010 00:49:51 +0000

이렇게 불러도 되는건진 모르겠지만, 한국에서도 저렇게 부르고, Amazon.com 에서도 Old Man’s war trilogy 같은 표현이 있는 듯 하니 일단 그냥(…).

SF 소설로, 지난 일주일 정도 동안 열심히 봤다. 사실 이건 빌려놓고 제대로 안 읽고 있다가 막상 돌려줘야 할 때가 되서 + Windows Vista->7 업그레이드 때문에 손놓고 있던 두 시간 정도의 여유 때문(???).

‘노인의 전쟁’을 다 읽고나니, 이 후속작도 있다는 소릴 듣고 열심히 읽고, 아마존 검색 결과 그 다음권도 있길래 냉큼 사서 봤음. 처음 두 권을 한글로 보고나니, 마지막 권은 영문으로 봐도 크게 어렵지 않더라.

많은 SF 소설들이,

“이런 상황이 되었을 때, 인간은 어떤 선택을 하느냐; 나중에 이런 문제가 닥쳐올 텐데 어떻게 할까”

라는 식의 얘기를 많이 하는데, 이 씨리즈에선 약간 다른 방향… 좀 더 오락적이랄까? 으로 나간다. 특히 첫 한 권이 그렇다…

이 아래 리뷰 내용에는 낮은 수준의 까발리기가 포함되어 있다. 그렇지만 본다고 저 세 권의 책을 읽는 재미가 줄어들 수준은 아니라고 생각한다.

첫 책에선 거의 세계관 전달에 촛점을 맞춘다. 인류가 우주 개척 시대에 돌입했지만, 지구는 거의 20세기 말 그대로 남아있고, 노인이 되면(75+) 우주 개척 방위군(CDF)에 자원해서 (뭔가 방법을 써서) 젊어지고 우주에서 싸우게 되는 구조가 된 상태를 설명한다. 그리고 이 전쟁(?)의 시대에 주인공이 자원해서 CDF에서 싸우기 시작하기 까지가 책 내용의 거의 절반에 해당한다.

그 와중에 지구의 인류와 우주에 나가 있는 인류(우주 개척 연맹; Colonial Union; CU)에 대한 얘기가 나오고, 앞으로의 씨리즈에 대한(…) 지구인 관점의 설명이 이어진다. 물론 주절주절 설명하는건 아니고 책 전체에 걸쳐 이걸 느끼게 해주는게 좋았음. 오락적으로도 훌륭한 것 같고.

좀 웃겼던 것(그리고 이 책의 이야기가 가능했던 것)은 CU에서 모든 기술을 거의 통제해서 지구의 기술 발전을 늦춘 것이 가능 하다는 것. 근데 정보는 일단 책에서 얘기하는 공간 도약없이는 광속보다 빨리 전달 할 수 없으니 그냥저냥 말이 되서 책은 계속 읽었다 – 궤도 엘리베이터(space elevator?)라거나, 공간 도약, 유전자 조작 병사, 의식(consciousness)의 이식 등등은 CU만 가지고 있는 상태. 우주에 나간 인류는 기타 지성있는 외계인들의 대립 구도(=만인에 대한 만인의 전쟁)에서 열심히 지식을 습득해서 엄한 속도로 발전해버렸다 정도로 설명을 해서 좀…

여튼 오락적이고, 배경을 한 권 내내 깔아준 덕에 2권의 전개는 무진장 빨랐다. 인간을 인간으로 만드는게 만들어주는게(=인격?) 뭔가에 대해 상당히 재밌는 설명을 했고, 2권 전체를 관통하는 주제가 되었다. 단순히 클론을 만드는게 아니라, 하드웨어인 육체 + 데이터인 기억과 경험 + 소프트웨어인 의식이 있어야 모든게 유지 된다는 얘기가 2권 전반의 내용.

물론 1권 처럼 오락적인 면(=전쟁 씬이라거나 계략 구도 등등)도 괜찮았다. 다만 1권의 주인공은 3권이 되어야 나오는 건 좀 불만이었지만, 주인공 자체의 매력은 2권에만 나오는 주인공 자신이 꽤 괜찮았음. 시점도 3인칭으로 옮겨가긴 했지만;;

특히나 복제 인간 격인 존재들의 “자기 선택권”에 대해서 얘기하는건 꽤나 흥미로웠다.

그리고 우주 전체의 대립구도를 바꿔놓으면서 이야기 규모를 팍 키워놓고 2권이 끝나버린다. 야!!!!

3권은 2권에서 커져버린 이야기를 수습하는 단계. 다만 2권에서 만들어놓은 몇 가지 인과를 3권에서 너무 우려먹는다는 느낌은 좀 들지만; 지금의 미국 정부 + 미군을 보는 거 같은 좀 독선적인 CU와 CDF의 모습은 작가의 생각이 좀 담겨 있는 듯 하다.

여튼 1권의 주인공인 존 페리가 재등장하고, 이 존 페리가 새 개척 행성의 행정관(꼴랑 2500명이 이주하는 거긴하지만)이 되서 벌어지는 이야기와, 여기 담긴 음모, 그리고 전우주 규모의 대립이 3권의 내용.

2권 말미에서 잔뜩 벌여놓은 이야기를 잘 수습한다는 점에서 정말 잘 썼다고 생각한다. 사실 2권 읽고나면 벌어진 이야기의 크기 때문에, 3권이 있는걸 알고 안 읽을 수가 없음(…). 내가 1권에서 품었던 기술 격차 문제(CU vs. 지구)도 어떤 의미론 설명해주는게 이 3권이었던 듯 함.

궁굼한건(…) 3권 등장 인물 중에 Jane과 Zane이 있다. 한국어 번역판에선 어떻게 표기하려나?

여튼 이 책을 읽게 된건, 재밌다고 첫 책을 빌려 준 rica 덕분. 이 자리를 빌려 rica 에게 감사를.

PS. 근데 3권까지 봐도 콘수의 존재 의미는 안 밝혀집니다. 난 이게 제일 궁굼한데 Orz.

외전 격인 두 권의 책이 있긴 하지만 제목 자체가 약간의 까발리기이기도 하고 해서 여기선 언급하지 않는다. 다만 아마존 평점이 그닥이라(씨리즈 3권은 모두 4.5/5 수준의 높은 평점인데 이 건 2.5~3 수준) 안 읽을 가능성이 높음; 근데 소개된 줄거리 만으론 콘수 얘기는 없을 것 같다. 흑흑.

빌드 자동화 하기 – CruiseControl.net

프로토콜을 만드는 자세

rein — Tue, 27 Jul 2010 01:10:10 +0000

프로토콜을 만드는 경우는 라이브러리와 비슷하다고 생각한다. 적어도 내가 대학원에서 배운 프로토콜들을 생각할 때¹ 이 둘을 만드는 자세는 꽤나 비슷한 거 같다. 그런 점에서 Coders At Work의 한 구절(좀 길지만) – Joshua Bloch 와의 인터뷰 – 를 인용해보겠다. 각종 강조는 내가 남긴 것(볼드;이탤릭;밑줄)

Seibel: What is your proces for desiging software? Do you fire up Emacs and start writing code and then move it around until it looks right? Or do you sit down on your couch with a pad of paper?

Bloch: I gave a talk called “How to Design a Good API and Why It Matters” at OOPSLA a couple years ago, and serveral versions of it are floating around the Web. It does a pretty good job explaining how I go about it.

The most important thing is to know what you’re trying to build: what problem you’re trying to solve. The importance of requirements analysis can’t be overstated.

(중략)

Coming up with a good set of use cases is the most important thing you can do at this stage. Once you have that, you have a benchmark against which you can measure any possible solution. (중략)

The worst thing that you can do – and I’ve seen this happen – is you get a bunch of smart guys into a room to work for six months and write a 247-page system specification before they really understand what it is they’re trying to build. (중략)

So get those use cases and then write a skeletal API. It should be really, really short. The whole thing should, usually, fit on a page. (중략)

The whole idea is to stay agile at this stage, to flesh the API out just enough that you can take the use cases and code them up with this nascent API to see if it it’s up to the task. It’s just amazing there are obvious in hindsight but when you’re designing the API, even with the use cases in mind, you get them wrong. (중략)

As your confidence in the API increases, then you flesh it out. But the fundamental rule is, write the code that uses the API before you write the code that implements it. Because otherwise you may be wasting you time writing implmentation code that won’t get used. In fact, write the code that uses the API before you even flesh out the spec, because otherwise you may be wasting your time writing detailed spece for something that’s fundamentally broken. That’s how I go about designing stuff.

간단히 해석+요약 하자면, “뭔가를 디자인 할 때 어떻게 하는가”라는 질문에 대해, Bloch 자신이 2년 전에 했던 강연² 을 보라며 이런 말을 한다.

좋은 디자인을 하려면 요구 사항을 분석해서 use-case 를 만들어야 한다.
이 use-case 를 염두에 둔 채로 간단한 뼈대로 API 명세를 만든다.
그리고 이 초기 API를 코딩한다. 다만 충분히 기민하게 이를 수정한다.
충분히 자신감이 쌓이면 이를 내놓는다.

하지만 가장 중요한 원칙은 “API를 쓰는 코드를 API 보다 먼저 작성하라” 라는 것. 심지어 이 API 명세를 작성하기보다도 먼저…

Bottom line

현실은 시궁창. 6개월 넘게 진행된 명세라는게 1주 구현하면서 내포된 모호성 때문에 상당 수가 뒤집힌 새 명세가 되더라. 그리고 이 명세는 구현 가능할 정도로 안정적인지 난 모르겠다. 명세 내부에서도 서로 모순인게 나오는데… 완성은 언제?

나는 전기 컴퓨터 공학부 대학원에서 이동통신망을 전공했다. 거기에서 PHY 바로 윗부터 MAC 단까지의 여러 가지 프로토콜과 TCP를 다뤘다. 여기서 많은 수의 프로토콜을 분석하고, 향상시킬 수 있는 부분을 제안하거나, 시뮬레이션 하거나 하다 졸업했다
여기서 해당 제목의 PDF나 acm 포탈을 따라가면 볼 수 있다

가상화 서버 비정상동작 + redmine 재설치

rein — Tue, 27 Jul 2010 00:18:17 +0000

가상화해서 돌리던 서버 중 1대에 redmine 이 올라가 있었는데, 이 서버가 주기적으로 죽는다. 대략 매 달 4주 차의 토요일 오전에 사망함. 게다가 이건 물리서버를 내가 접근할 수도 없는데, 해당 쪽의 처리도 늦어서 어제는 오전 10시 경에 보고했는데도 실제로 서버가 살아난건 오후 5시 다 되서…

근데 죽는 타이밍이 너무 기가 막히니(…), 저거 누군가 해답을 알려나?

Redmine 사용하는 2개 팀이 그냥 서버 이전하기로 합의 보고, 어제 저녁에 이전 작업을 했다. 일단 예전에 써놓은 대로 작업을 진행했다. 근데 이게 왠걸. 일단 mysql 백업 복구하는 과정에서 막혔다.

잠시 삽질하다 원인을 찾아보니, 해당 서버에 2 개의 mysqld 가 떠 있었고, 나는 내가 설치하지 않은(bitnami-redmine-stack 1.0 설치) mysqld 랑 연결하고 있던 것 Orz. 일단 이렇게 백업은 복구. redmine files 디렉터리도 복사하고, 서버를 띄웠더니 svn 저장소 로그는 보이는데, repository browser 탭이 보이질 않는다.

로그를 뒤져도 딱히 이상한게 없고(이건 log-level 문제인가?), redmine 홈페이지의 트러블슈팅을 따라하다가, 다음 명령에서 문제가 있는 걸 확인.

> rake -f Rakefile redmine:fetch_changesets RAILS_ENV=”production”
svn: Cannot negotiate authentication mechanism
svn: Cannot negotiate authentication mechanism
svn: Cannot negotiate authentication mechanism
…

이런 식으로 대략 연동된 저장소 수 만큼 나오더라. 문제의 원인은 svn 저장소 중 일부가 SASL 인증을 써서 였음. bitnami redmine stack 에 포함된 svn 으론 SASL 인증이 안되더라… Collabnet 에서 나온 svn 클라이언트 설치하고, binary 바꿔치기해서 상황 종료.

Google Go: 간단한 성능 평가

rein — Mon, 19 Jul 2010 17:09:55 +0000

수요일에 있을 팀 세미나 준비하면서, Google Go로 간단한 병렬 프로그램을 짜고, 직렬(serial;sequential) 구현과 성능을 비교 해봤다. 일단 간단히 여기에 정리. 모든 테스트는 x64 버젼의 MacOSX 를 돌리는 MacBook(2008년에 산 녀석)/dual-core 에서 이루어 졌다.

매우 간단하게 병렬화 되는 알고리즘인, quicksort를 가지고 성능 테스트를 했다. pivot을 그냥 순열 중간에서 찍어내는 단순 무식한 방법으로 만들었음.

이하에선 대략 배열 길이가 512 보다 작으면 그냥 순차 알고리즘만 동작하게 했음.

Naïve 하게 시작

우선 처음엔 fork-join 하는 형태로 좀 많이 naïve 하게 짜봤다: 정수 400만개 정렬 시켰더니, goroutine 수가 너무 많다고 뻗음. (이건 내 코드의 버그였음). 더 이상 fork하지 않고 도는 threshold를 좀 높게 잡고(8192?) 돌렸더니 대략 1200ms 정도 걸리더라. 단순하게 그냥 짠 알고리즘을 싱글 스레드로 돌리면 약 2000ms. 거의 2 배의 스피드업이 있긴하다.

그래도 이건 좀 아니다 싶어서(…), Work-stealing queue를 짜기 시작.

Work-Stealing Queue

완전히 다 구현한건 아니고, 배열을 둘로 쪼갠 순간 다음과 같이 동작하게 했다.

배열의 앞 부분은 work-stealing queue로 전달하고, 나머지는 그 goroutine이 직접 정렬하게 했다. 물론 이것도 재귀적으로 적용되니까 전부 한 goroutine에선 이루어지지 않는다.

Work-Stealing Queue를 간단하게 구현한다고(…) 좀 가짜로 만들었다. 일단 큐를 스레드 별로 두지 않았다. 다만 자기 자기 큐에서 꺼낼 때의 LIFO 동작을 흉내내려고 전부 큐에 넣는게 아니라 마지막에 분할한 부분 배열은 자기가 직접 정렬한다. 그리고 다른 스레드의 큐에서 꺼내는걸 따라(?)해서 큐에서 꺼내는건 FIFO…

처음에 작업 종료되는걸 감지할 방법을 못찾고 해매다가, Queue에 넣은 작업 갯수 만큼 종료 신호를 받게 했다. 이것도 단순히 빈 슬라이스를 응답으로 보내게 해서 이거 숫자를 셌다(…).

대략 1100ms 정도 걸린다. 총 goroutine 수가 입력에 비례하는게 아니라, 코어 수에 맞춰놔서 naïve 구현처럼 panic() 함수 호출되는 일은 없었음;;;

C++이랑 비교

C++의 에 있는 sort 랑 비교해봤더니 너무 큰 차이가 난다. 대략 700ms 좀 안 걸리게 돌더라. 이건 무려 싱글 스레든데;;; 사실 이건 내 구현이 sort() 함수의 introsort 보다 예상 성능 자체가 낮아서 생기는 일이기도 하지만;;
내가 짠 알고리즘을 싱글 스레드로 돌린 경우 1580ms 정도 걸렸다. (cf. Go는 2000ms)

intel tbb의 tbb::parallel_sort()를 사용한 경우 대략 350ms 쯤 걸린다. linear-speedup? 이게 가장 빠르긴 하구나.

Go 쪽에 썼던 코드를 그대로 넣고 돌렸더니 대략 1600ms. 그래도 코어 2개 쓰는 쪽이 빠르긴 하지.

요약

Go(single-thread): 2000ms
Go (parallel) : 1100ms

C++(single-thread; same algorithm): 1600 ms
C++(single-thread; std::sort() ) : 700ms
C++(2-threads; tbb::parallel_sort() ): 350ms

간단한 감상: 좀 더 최적화 할 여지가 있어 보인다. 심심풀이로 실제 물리 코어 수 보다 더 많은 MACPROCS를 지정했더니 성능이 꽤 빨리 내려간다. 생각보다 channel 통한 통신의 오버헤드는 크지 않아서 만족스러웠다. fork-join 과 worker-thread 비슷하게 짠 게 큰 차이는 안나는걸 보니… 반대로 goroutine은 아무리 많이 만들어도(한 6만개 만들어도 잘 돈다) 괜찮긴 하더라..

+ naïve 하게 짜면 망한다(???).

스팸의 한국어가 좀 더 세련되게 변했네요

rein — Mon, 19 Jul 2010 14:46:40 +0000

블로그를 열어보니 보이는 스팸 두 통.

멋진 장소? 식의 괴악한 한국어를 벗어나 “공유해 주셔서 감사합니다. 정말이야!”라니…

그나마 한국어의 탈을 쓴 듯한 스팸이 오네요. 그래봐야 akismet에 걸린 듯 하지만…

리뷰: 프로그래머가 몰랐던 멀티코어 CPU 이야기

rein — Tue, 13 Jul 2010 09:14:08 +0000

art.oriented의 김민장(object)님이 쓴 책이다. 한빛미디어의 Blog2Book 씨리즈 중 하나.

평소에 저 블로그를 구독하고 있다면, object 님이 전반적인 컴퓨터 구조와 최적화에 관해서 얘기하는 걸 여러 번 봤을 거다 – 구독하지 않고 있다면 RSS 리더에 추가하는 걸 추천! 잘 읽히는 블로그 글 솜씨만큼이나 책도 쉽게 읽을 수 있어서 좋았음.

이 책에서는 컴퓨터 구조, 특히 CPU 에서 명령어를 빨리 실행하기 위해 무엇을 하는지를 중심으로 현대 CPU의 여러 부분을 설명하고 있다. 간단히 읊어 보자면,

프로세서의 각 부분에 대한 설명
컴퓨터 성능 평가와 암달의 법칙
고성능 프로세서에 들어간 최적화 부분: 파이프라인, 비순차 실행, 하이퍼 스레딩, 멀티 코어 그리고 데이터 병렬성
분기문의 복잡함과 최적화: if 문, virtual function
멀티코어 CPU 혹은 SMP 아키텍쳐에서 벌어지는 몇 가지 문제들
느려터진 메모리의 최적화: 캐시와 메모리 계층 구조, 메모리 프리펫치

를 비롯해서, 이 포스팅에선 언급 안한 것도 잔뜩 포함해서, 컴퓨터 구조의 여러 내용을 설명하고 있다. 특히 상대적으로 쉬운 내용 – 프로세서의 나 각 실행/제어 단위에 대한 설명, 기본 개념에 대한 설명 – 부터 시작해서, 비순차 실행이라거나 분기 예측, 투기적 실행(speculative execution)처럼 학부 수준의 컴퓨터 구조 시간에는 간단히만 다루는 현대의 복잡한 CPU 구조의 부분부분을 설명해주기 때문에, 좀 어려울 수는 있어도 따라갈 수 없는 내용은 아니다.

물론 이 주제의 상당 부분은 학부 컴퓨터 구조와 컴파일러 시간에 배우는 내용보다 좀 더 최신이고, 상대적으로 좀 더 깊이 들어간 부분이 있기 때문에, 빈말로도 “쉽다”라곤 말 못하겠다. 그렇지만 학부 수업을 차근차근 듣는 기분으로, 찬찬히 살펴본다면 얻을게 정말 많다.

하드웨어 얘기이긴 하지만, 이 하드웨어가 우리가 만드는 소프트웨어와 직접적으로 연관이 있고, 하드웨어의 많은 부분은 소프트웨어 쪽 구현에도 영향을 준다. 책에서도 몇 번 강조하는 얘기지만, 여기서 설명하는 파이프라인의 개념은 여러 멀티스레드 프로그래밍에 나오는 개념이다(Task-parallel pattern; 잘하면 task+data parallel pattern도 됨). 비슷하게 메모리 미리 읽기(pre-fetch)나 캐시 활용 같은게 실제 응용 프로그램에서 쓰이는 사례는 말 안 해도 알 것이다. 그래서 “난 SW에만 관심이 있어!”라고 말하는 사람(=rein)들에게도 좋은 책이라고 생각한다.

비록 오자가 좀(…) 있다곤 하지만, 빠르게 업데이트 되고 있어서, 오자 페이지를 찾아가서 확인하면서 보면 괜찮을 거다;

rein은 이 책을 그레이트 코드 2권 같은 책에 매우 큰 흥미를 보였거나(…), 컴퓨터 구조에 대해서 알고 싶거나, 혹은 더 배우고 싶은 분들에게 매우매우 추천한다. 비슷한 이유로 팀 신입 사원들에게도 읽어보라고 권하고 있다

리뷰: Complexity: A Guided Tour

rein — Sun, 04 Jul 2010 13:10:00 +0000

현대 과학에 새로 생겨난(?) 분야 중 하나가 복잡계 과학이란 분야다. 이 책에서 얘기하는 것처럼 명확히 정의되지 않고, 그 경계도 모호한 분야지만 여러 분야 – 생물학, 물리학, 컴퓨터 과학, 수학, 기상학, … – 에서 나타나는 “복잡계” 때문에 많은 사람들에게 친숙(?)한 용어이긴 하다.

이미 번역된 책으로 이머전스, 딥 심플리시티, 링크(linked), 동시성의 과학 싱크(sync) 같은 많은 책이 나와있긴 한데, 좀 묶어서 나온 책이 없다고 생각해서, 추가로 읽게 된 책이다.

책 초반부에 이런 얘기가 나온다:

복잡성에 관한 “하나의 과학”은 아직 없다. 복잡성에 대해 서로 다른 정의를 갖는 몇 개의 서로 다른 과학이 있을 뿐이다. 이 정의(notion)은 일부분에선 매우 수학적(formal)이고, 일부에선 그렇지 않다. 만약 여러 복잡성의 과학이 “하나의” 복잡성의 과학이 된다면, 이 서로 다른 정의가 어떤 관계인지 알게 될 것이다.

즉, 아직 “충분히 연구되지 않아서” 명확히 정의 내리긴 어렵고, 각각의 분야에서 서로 다른 생각을 하고 있다는 것. 그리고 이런 분야에 관해 저자가 하나하나 설명하는 식으로 책이 진행된다(…).

책 전반에서는 “복잡성”의 의미를 저자가 생각하는 몇 가지 카테고리로 나누고, 이에 대한 예를 굉장히 많이 든다. 링크에서 얘기했던 스케일 없는 네트워크 비슷한 내용이라거나, 여러 분야에서 공통으로 반복되는 상수라거나 구조 등등. 일단 복잡성 자체를 “계산”이라는 (그래도 불명확하지만) 의미로 묶고, 이에 대해서 잘 쪼개서 설명하고 있다.

책 자체는 굉장히 쉬운 문체로 쓰여 있어서 술술 잘 읽힌다. 내가 컴퓨터 공학 전공이라 그런지 “복잡계”의 특성으로 “계산”을 가지고 얘기하는 게 꽤나 편하게 들렸다. “파인만의 엉뚱 발랄한 컴퓨터 강의”에서 얘기하는 “계산”의 특성에 관한 내용과 열역학 제 2법칙에 관한 내용도 다루는데, 이 책은 설명이 좀 부실하다. 파인만의 ~~~ 책 쪽이 훨씬 설명이 나음. 더불어, 몇 가지 컴퓨터 공학의 경계(frontier)에 해당할 “유전 알고리즘”이라거나 “셀룰러 오토마타; 세포 자동자”에 관한 얘기도 많이 다룬다. 매스매티카의 울프람 씨 얘기도 많이 나오고, 유전 알고리즘으로 최적화된 셀룰러 오토마톤을 찾는 얘기도 나온다.

다만 저자 자신의 박사 논문에 해당하는 copycat 프로그램을 다루는 절은 좀 지루했다. 스킵해도 뒤에선 별 차이 없더라…

책 자체가 복잡성 과학이 적용된 몇 가지 분야에 대해서 예를 많이 든다는 점은 매우 큰 장점인 듯 하다. . 전산학(계산; 자기복제; 셀룰러 오토마타; 유전알고리즘…), 생물학(유전; 발생; 신경계; …) 등등이 이에 해당. 그래서 상대적으로 저자의 말을 이해 하는 게 쉬웠다. 이런 류의 책의 주 독자층은 적어도 한 두 분야는 약간씩 접해보았거나, 자기 전공과 관련이 있을 테니 꽤나 보기 쉽게 만들어줄 듯 하다.

덤으로 마지막 장에서 저자가 “이 복잡성 과학이 쓸모 없다는 반론이 있지만 나는 그렇지 않을 거라 믿는다”라 말하고 있는데, 나는 대략 반반의 의견. 세부 분야가 정말 쪼개져버리거나 – 각 분야의 이해가 깊어지면서, 그 분야에 맞는 이론으로 고착화 되기 – 아니면 저자 말대로 하나의 과학 분야가 생겨나거나..

리뷰: The Design of Design

rein — Sat, 03 Jul 2010 14:37:16 +0000

어쩌다 보니(…) 책을 읽어놓기만 하고 리뷰 안 한 것들과, 그리고 몇 가지 의미로 리뷰를 올리지 못한 책들의 리뷰를 몰아서 업데이트 하게 되었다. 우선 가장 오래 전에 읽은 책 먼저.

The Myhtical Man-Month 의 저자 Frederick Brooks 의 신작이다.¹

일단 이 책은 부제인 “Essay from a Computer Scientist”에 나와 있듯, 일종의 에세이다. 저자의 사고를 일정한 순서로 풀어놓고, 이를 묶어서 책으로 만든 느낌이다.

이 책에서는 “디자인”을 어떻게 하는가 – 그러니까 디자인(설계)을 어떻게 설계해야 하는가 – 를 다룬다. 좀 불명확하긴 하지만, 디자인이 뭔지, 그리고 여기에 들어가는 사람들이 어떻게 사고하며 (이를 위한 SW는 어떤지, 이걸 써본 결과는 어땠는지), 그리고 어떻게 상호작용하는 지도 다룬다. 더불어, 디자인에 영향을 주는 요소들 – 자원(예산), 제약 사항 등등 – 도 다룬다.

물론 이 디자인을 하기 위해 뭘 어떻게 배워야 하는지. 우리가 배울 수 있는 예제들은 어떤지, 그리고 그걸 배우곤 있는 지라거나 등등에 관해서도 열심히 얘기한다. 마지막으로 이 내용들을 몇 가지 사례(컴퓨터 관련, 건축 관련, 책 관련…)를 들어 설명한다.

저자인 브룩스가 IBM의 통합된 형식(프로그래밍 모델이라거나, OS라거나 …)의 컴퓨터 군으론 최초로, 거대한 성공을 이룬 IBM System 360 을 설계 책임자여서인지는 모르겠지만, 여기서 얻은 경험을 예제로 여러 번 들고 있으며, 컴퓨터 구조 및 OS 설계 과정을 케이스 스터디로 각각 다루고 있다.

개인적으로 가장 의미심장 했던 대목을 다루자면,

성공적인 디자인은 공통적으로 이런 패턴을 갖는다: 물리적으로 격리; 작은 팀; 극도의 집중; 한 명의 리더십. 특히 (특정 설계의) 후속 디자인에 비해 어떤 획기적인 디자인에서 이게 반복적으로 나타난다. 예로, Joe Mitchell의 스핏파이어 팀이나, U-2와 F-117을 만든 켈리 존슨의 스컹크 웍스(Skunk Works), 애플에 대항하기 위해 PC를 설계했던 IBM의 격리된 lab이 있다.

이거랑 직접적인 대응은 아니지만, 중간에 다룬 내용으로, system 360 의 아키텍처를 정하기 위해 13 개의 서브 팀으로 쪼갠 후 경쟁 시켰다는 대목이 나온다. 즉, 작은 팀(1~3명)으로 / 격리 시키고 / 단기에 집중 시켜서 얻어낸 결과로 결론을 내렸다는 것. 가장 좋았던 두 개의 후보의 차이는 나머지는 거의 차이가 없고, 6bit 바이트일지 8bit 바이트일지 였다고…

그리고 보론처럼 들어간 게,

저자가 본 모든 팀 프로젝트에서, 디자인의 각 부분은 매 순간 한 사람만 다룬다. 그 한 사람이 그 부분에 대한 제안서를 준비한다. 그리고 동료들과 어떤 부분이 영향을 받는지 아주 작은 세션(micro-session)의 디자인 리뷰를 한다. 그리고 협력해서 내린 각 결정과 방향에 따라 세부 사항을 작업한다.

몇몇 개발 방법론에서 얘기하는 것 처럼, 코드 소유자가 있고, 그 부분을 각자 진행하는 시간이 있다는 것. Coders at Work에 나왔던 Erlang 개발 얘기도 이거랑 비슷한 느낌이 좀 있다.²

덧. 책 내용 자체가 에세이라고 생각하면 상당히 가벼워지긴 하지만, 저자 자체가 갖는 이름값도 굉장하고 해서 좀 무겁게 읽었다. 왠지 이 책과 비교해서 번역서로 읽었던 Mythical Man-Month는 좀 거칠거칠했다는 느낌도 받게 되었음 – 그러니까 번역 후에 어조가 바뀐 느낌; 어쩌면 그 사이에 흘러버린 시간 때문일 수도 있지만.

덧2. 얼마 전에 이 책을 읽다 부끄러워졌다고 썼는데, 이 책에선 디자이너를 어떻게 하면 잘 키워낼까를 얘기하면서 많은 예제들을 보라고 한다. 그래서 나 지금은 좀 하고 있나?(..)

사실 4개월이나 지났지만…
다만 이건 브룩스가 말하는 특별한 케이스 – 2 인 팀 – 이긴 하다

팀 세미나: Go Programming Language #2

rein — Mon, 28 Jun 2010 23:47:04 +0000

지난 번에 이어, 팀 세미나에서 얘기했던 내용을 업로드.

Introduction to Go Programming Language #2

거의 일주일 전에 한거지만 업로드는 이제야…

지난 번에 받은 느낌은 C버젼의 Erlang 비슷한 언어였는데, 좀 더 쓰다보니 대략 Python 을 연상케한다.

Syntactic sugar라거나, http 모듈 구현 방식이라거나, duck-typing이나 다름 없는 interface 구조라거나
하지만 python 을 컴파일 언어로 만들긴 힘드니, 상당한 제약이 들어가 있다
그럼에도 불구하고 꽤나 편하게 만질 수 있었다 (System Programming 언어를 표방하는 애들 중엔 제일…)
C 랑 매우 잘 붙는 것도 거의(…)
C 와의 인터페이스로 쓰는 C pseudo-package 도 왠지 ctypes가 생각 나는 것이…

…이런 느낌?

이번엔 지난 번(4주 전)에 이어 간단한 웹 서버 모듈 짜고, 이걸로 뭔가 보여주려고 했는데, 예제 짜고나서 이걸 설명하려니 지난 번에 설명하지 못했던 개념들이 이거저거 나와서(…) 그것들과 C 언어 링킹, Goroutine 과 그 구현의 현재 문제점들, 그리고 간단한 웹 서버 모듈을 설명하는 걸로 마쳤다.

일단 웹 서버 모듈(http 팩키지)만 놓고 보면, python 의 BasicHTTPServer 처럼 http 팩키지의 핸들러를 적당히 등록하는 방식으로 만들 수 있어서 꽤나 편했다. python이랑 달리 아예 URI 별로 핸들러를 등록시키는 방식이라, 상대적으로 모듈 쪼개기가 쉬워보임. C랑 잘붙어서 기존 라이브러리 가져다 쓰기도 매우 편한 것 같고… C랑 붙이기 위해서 “C” 란 가짜 패키지를 (만드는 척해서) 사용하는데, C.struct_name, C.function_name 만으로 접근되는게 꽤 편했음. (다만 이를 위해 SWIG 처럼 cgo 란 툴로 팩키지 빌드를 하긴 해야함)

여튼 C 연결을 쓰는 sqlite 래퍼를 찾고(…), 여기에 http 팩키지로 만든 웹서버를 띄워서 간단한 북마크 저장소를 시연하고 이번 치 세미나는 끝. 다음 번 주제를 좀 고민하고 있는데, 웹 서버처럼 상대적으로 full-swing 하는게 쉽게 보이는 걸 좀 더 해볼지, 아니면 게임 서버처럼 서로 얽히고 섥힌(…) 녀석을 만들어 볼지 고민 중이다.

Google Chrome 확장 기능 만들기

rein — Sun, 27 Jun 2010 15:55:09 +0000

아내가 egloos 육아 밸리에 누군가(…) 계속 보기 싫은 글 올린다고 불평을 하길래, 주말을 맞이해서 간단한(?) 플러그 인을 짜봤다. 그렇게 완성 시킨 걸 구글 크롬 확장 기능 페이지에 올려놨다.

Google Chrome 확장 기능은 개념적으로 매우 단순한 구조를 가지고 있다. 다만 보안 상의 이유로 몇 가지 제약 사항이 있어서 짜는데 삽질을 해야 했지만;;

전체적으로는 몇 개의 파일을 묶어서 플러그 인이 되게 한다. manifest.json라는 파일을 포함해야 하는데, 여기에 구글에서 정의한 기능 단위로 어느 파일이 어떤 기능을 하는지 정의 한다. 예를 들어, 이 아이콘을 쓰고, 옵션 페이지는 이 html 을, “~~한 URI”에는 이 javascript 를 … 하는 식으로 정의 한다.

내가 짠 스크립트는 이글루스 밸리에서 특정 블로그를 차단하면 되는 거라, 특정 URI에 해당하는¹ 페이지를 만나면, 여기에 동작하는 content_scripts를 짜는 걸로 했다. 일단 시작 자체는 튜토리얼만 따라 해도 돼서 편하게 갔음.

옵션을 표현하는 페이지를 manifest에 options_page 로 주고, 여기에서 localStorage² 에 어느 블로그를 차단할지 저장하게 했다.

다만 작성하는 동안 최대 문제는, 내가 사용한 content_scripts 가 “페이지를 변환”하는 기능을 하기 때문에, 당연히 XSS 위험이 있을 수 밖에 없고, 이거 때문에 chrome 확장 API 들을 거의 접근할 수 없었다. 그래서 localStorage 도 직접 접근할 수 없었고, background.html 이라고 플러그 인을 위해 계속 떠 있는 페이지³ 를 이용해서 데이터를 읽으려 해도, 역시 보안 상의 이유로 실패 Orz.

좀 더 API 문서를 읽어보니, background.html 에 asynchronous query 하는 건 되더라. 그래서 여기에 옵션 값 내놓으라는 요청을 보내고(…), 이걸 받는 후에야 특정 블로그 내용이 나올지 말지 결정하게 했다. 그랬더니 어찌 어찌 동작하게 되더라; 그리고 플러그 인 페이지에 한 번 낚였는데 –_-.

구글 크롬 자체의 플러그 인 페이지에 개발 중이 플러그 인을 배포용으로 묶어 주는 기능이 있는데, 구글의 공식 확장 기능 페이지에는 이 파일을 업로드 하는 게 아니었음. 개인키로 서명까지 하게 해 놓고 이게 무슨 삽질인지 –_-; 사실 구글 계정과 플러그 인 업로드가 묶이기 때문에 그런 거 같긴 하지만;

Mozilla FireFox 플러그 인은 XUL 배우기가 귀찮아서 전혀 손도 안 대보고 있었는데, 나중에 기회가 나면 그쪽으로 포팅하는 걸 고려 중이다. 아내가 주로 쓰는 브라우저가 그거라서…

여하튼 감상:

json, javascript, html + 약간의 데이터(이미지 등등)를 통해 금방 플러그 인을 작성할 수 있더라
특정 기능(content_script) 사용의 경우 Java Applet이나 Adobe ActionScript 처럼 상당한 제약이 걸린다. 우회해야 하는 게 한 무더기.
특정 시나리오, 예를 들어 플리커에서 사진을 가져온다거나 하는 일은 매우 쉽다. 로컬 연결이 아닌 웹의 각 open API를 쓰긴 쉬워 보였다. 기본 예제도 그렇고.
npapi도 지원하긴 하더라. 별로 쓰고 싶진 않지만(…)

valley.egloos.com/* 그리고 www.egloos.com/* 및 비슷한 페이지들
5MiB 까지 데이터를 저장할 수 있는 공간이 있다; 그리고 여기에 의존하다 피 봤음
각 플러그인마다 존재하고 이것도 manifest 에 기술하고 html 파일을 플러그 인에 추가하면 끝.

리뷰: REWORK

rein — Wed, 09 Jun 2010 22:30:00 +0000

Signal vs. Noise 라는 이름으로 37signals¹ 에서 운영하는 블로그가 있다. 여 튼 이 블로그에 글을 쓰는 사람 중 두 명이, 상당 부분 블로그 내용에 가깝게 책을 썼고, 이게 3월에 발매되었다. 이 책을 산 이유 중 하나는 광고 문구로, “각 종 사업을 시작해보려는 사람, 사업 중인 사람, 혹은 전혀 그럴 생각이 없는 사람들을 대상으로 썼다” 라고 되어 있길래 대체 무슨 소린가 해서. Jeff Atwood라거나 Joel Spolsky 가 추천하는 것도 있었고 …

간단히 요약하자면, 책 저자들이 작은 회사 – 요새 유행하는 용어를 쓰자면 강소 기업? – 를 잘 운영하고 있어서 그런지, 그런 방향으로 “이걸 이렇게 생각해서 성공적이었다”는 식으로 강조하는 게 꽤 많고, 상당히 납득할만한 방식으로 서술해서 재미있게 봤다. 그리고 이걸 잘 돌려서 생각하면, 그냥 고용인 입장에서 봐도 납득할 만한 + 스스로 실천해볼만한 사항이 많다. 그래서 이 책의 권장(혹은 광고 대상?) 독자 층이 저렇게 잡히는 거 같지만.

책은 별로 길지 않다. 본문을 인용하자면,

Lots of things get better as the get shorter. Directors cut good scenes to make a great movie. (중략) We cut this book in half between the next-to-last and final draft. From 57,000 words to about 27,000 words. Trust us, it’s better for it.

더 짧게 만들면 더 좋아지는 것들이 많다. 감독은 명작을 만들어내기 위해 좋은 씬들을 잘라 낸다. (중략). 이 책의 최종 원고와 그 직전 원고 사이에 거의 절반의 양을 잘라 냈다. 대략 5.7만 단어에서 2.7만 단어 수준으로 줄였다. 믿어보자, 이게 더 낫다.

(REWORK 의 Progress – Build half a product, not a half-assed product 에서 발췌; 모든 저작권은 REWORK 의 저자들에게 있다)

즉, 더 나은 책을 쓰려고 양을 반으로 줄여서 그리 길지 않은 – 종이 책 기준으로 약 280 페이지 – 책이 된 것. 덕분에 읽는데 일주일도 안 걸렸다(…). 그리고 많은 내용이 이들의 블로그에서 말한 내용이다. 완전히 같지는 않을지라도, 저 블로그 구독하고 있다면 많이 본 얘기들이 나온다. 뭐 이 책에서 말하는 “문화”란게 저런 거 겠지만;;

책 자체는 중 주제 몇 개를 소주제로 쪼개서 간결한 그림 한 장 + 설명 한 페이지 ~ 세 페이지 정도? 로 설명하고 있다. 여기서 이들의 경험을 기반으로 “어떻게 살아야(?)하는지” 얘기한다. 특히나 벤처, 특히 IT 벤처업계의 상식이(???) 된 얘기들에 반하는 내용을 꽤나 직설적으로 말한다.

처음부터 이익을 낼 수 있어야 한다거나, 몇 년 짜리 계획(혹은 사업 계획서)은 무의미하다거나. 상품만 파는 게 아니라 상품을 만들기 위한 지식도 팔고, 상품에 덤으로 나오는 것도 잘 팔면 된다거나.

벤처 캐피털의 도움을 받는 건 절대 하지 말아야 할 일(Plan Z)라고 부르고 있고, “작은 회사가 좋은 점”에 대해서도 꽤나 길게 몇 개 소주제로 역설한다. 그리고 역시 자신들의 경험에 빗대어 사람을 어떻게 뽑을지, 그리고 지리적으로 넓게 분산되어 있는 팀은 어떤 지도 얘기한다.

맘에 드는 대목을 몇 개 꼽자면,

아이디어는 매우 값싸고 많다. 맨 처음 아이디어 자체는 비즈니스 전체에서는 매우 작은 부분만 차지할 뿐이고, 거의 무시할 수준이다. 정말 중요한 것은 “얼마나 잘 실행하느냐”다.

Go – Start making something,

더 작은 질량을 갖고 간다고 생각하자. 지금 당장이 가장 작고, 군살을 뺀, 가장 빠른 상태며, 앞으론 점점 살이 붙게 된다. 그리고 점점 더 변화하기 힘들게 된다.

Go – Less mass

경쟁자보다 더 쓰고, 더 팔고, 혹은 더 후원하는 것보다 더 “가르치려고” 하라. 경쟁자는 생각조차 하지 않을 일이고, 이건 일반적인 마케팅 방법으론 얻을 수 없는 “유대감(bond)”을 만들어 줄 것이다.

Promotion – Out-teach your competition

사업가는 왜 더 크게 보이려고, 딱딱한 언어, 공식 발표, 만들어낸 친밀감, 법적인 것들 등등을 왜 쓰는가? 마치 로봇 같다. 즉, 당신과 대화 하려는 게 아니라, 당신에게 설교하려 든다.

읽을 만한 글을 쓰자. 쓰기 위한 글을 쓰면 안 된다. 뭔가 쓰고 난 후엔 크게 소리 내서 읽어라. 대화하는 것처럼 들리는가? 그렇지 않다면 더 대화문같이 수정하자.

Culture – Sound like you

Ruby on Rails 를 만든 회사이기도 하고, 몇 개의 사용하기 쉽고 간결한 툴들을 만든다. 사실 저 프레임웍 자체도 이 툴들 중 하나를 만들다 나온 것.

No related posts.

Google Go on Android/nacl?

rein — Mon, 07 Jun 2010 00:44:17 +0000

Google 의 Go Programming Language 의 빌드 상태 페이지를 발견하고, 적당히 살펴봤다.

Google Go 의 타겟 플랫폼으로 알고 있던 게, linux x86/x64, darwin(MacOSX) x86/x64, arm 이었는데, 몇 가지가 더 보이더라. 그 중 주목(?)할 만한 게 있었음.

일단 linux-arm-android 가 있고, 추가로 nacl 386 이 있다. 좀 놀란 이유는 며칠 전 구글 I/O 에서,

Android 지원은 가능하지만(arm 에서 빌드가 되니), 아직 높은 우선 순위는 아니다

라고 답한 거였는데 … (정확히는 FAQ 목록이지만) 그리고 이 빌드가 한참된거라서 (올해 1월부터 있다; Fail이 좀 많긴 하지만)

뭐 일단 Android 도 어느 정도 테스트되고 있는 듯(golang.org 에도 사용가능한 플랫폼으로 그에 대한 언급이 있다). 덤으로 WebApp 용 native client(nacl) 지원도 있는 듯 함. 다만 벤치 마크 페이지에는 darwin x86/x64, linux x86/x64 만 있는 걸로 보아 아직 불안정한 상태인 듯도. (그리고 Google I/O 발언대로라면 아직 그렇게 높은 우선 순위가 아니라는 정도?)

PS. 근데 내가 Go 를 정말로 쓰기 위한 최우선 과제(?) I/O 성능 개선인데, 이건 언제쯤? 사실 이건 밑 단 라이브러리만 잘 되면 좋겠는데. 하다 못해 Java 보다야 I/O 성능이 좋아야할 거 아닌가;;

이 글을 쓰는 사이에 스리슬쩍 FAQ관련된 비디오가 업데이트 되었다. 이건 집에가서 봐야하나.

아들 근황 + 책!!!

rein — Mon, 31 May 2010 15:48:17 +0000

아들이 요즘 들어 잘 기어 다니더니, 뭔가 잡고 일어서고 싶어한다. 옆에 내가 누워있으면 나를 이용해서 일어선다… 그러더니 이젠 슬금슬금 책장에 접근해서, 책장을 잡고 일어선다.

그리고는, 책장에 꽂힌 내 책(사진의 예쁘장한 파란색 하드커버 책)을 뽑으려고 한다. 김명수 교수님의 모 수업을 들었던 분들은 무슨 책인지 잘 아실 듯(…)

아들이 관심을 갖는 건, 학부 4학년 때? 던가 그 학기에 처음 개설된(…) 3학년 과목의 교재였던 Gilbert Strang 교수의 "Introduction to Applied Mathematics"란 책. 무광 파란색에 하얀 테두리가 맘에 드는 모양(?).

학부 4학년 봄 학기에 가장 많이 뒤져본 책이 아닐까 싶은데, 무겁고(…), 비쌌고!(한 달 생활비 1/4넘게 날아감), 심지어 거의 절판된(지금은 절판) 책이었는데, ‘수학 그게 뭔가요’하는 무지한 공대생들에게, 선형대수학…이라기보단 그 응용을 적절히 다뤄준 책.

심지어 첫 학기라고, 그 랩 박사과정 형님 + 석사과정 누님 한 분이 주말마다 연습문제 풀이도 해주셨음(하지만 토요일 오전 9시던가 10시의 압박은 실로 -ㅁ-)

덕분에 그 이후에 들었던 컴퓨터 애니메이션(…의 탈을 쓴 컴퓨터 그래픽스 + 선형대수학)은 쉽게 쉽게 들었다는 훈훈한 얘기가(???).

근데 아들은 파란색이 맘에 드는지 저 책을 뽑고 + 핥고 + 꾸깃꾸깃(그래 봐야 하드커버!) 하고 싶어한다. 아들아, 추억의 책은 좀 남겨주지 않으련? 절판돼서 아마존에서도 못 구한단다 Orz.

ps. 근데 Gilbert Strang으로 아마존 검색해보니 3년 전에 나온 Computational Science and Engineering 도 있다. 이것도 사서 연습문제 따라 천천히 읽어보고 싶어지네…

팀 세미나: Go Programming Language #1

rein — Sat, 29 May 2010 06:01:42 +0000

팀에서 매 주 한 번씩, (회사 일 이외에) 자기가 관심 갖는 주제에 대해 발표하는 시간을 가지고 있다.
그리고 그 시간에 먹을 피자 대금에 대한 사다리 타기 대결도(…)

나는 이 시간에 Google 에서 만드는 오픈 소스 프로그래밍 언어인 Go 에 대해 하기로 했다. 요즘 심심풀이로 만지는 언어가 Go라서…

여기 그 때 썼던 자료를 게시한다. export를 잘못했는지 슬라이드 노트들은 없다(…).

Introduction to Go Programming Language

사용한지 기껏해야 한달 좀 넘었지만, 기본적인 구조는 C를 따르고, 여기에 몇 가지 제약을 가하고 기본 타입과 concurrency primitive 를 더해서,¹ Erlang 비슷한 언어가 되었다는 느낌.

그래서 이런 느낌을 가지고 Go 가 가지는 강점과 약점이라고 생각되는걸 간단히 요약하자면,

굉장히 빠른 시스템 빌드 시간 – 대부분의 의존성(type, import,…)을 명시적으로 해결하기 때문에 빌드가 정말 빠르다
간단하고 어느 정도 duck-typing이 돼서 조작하기 쉽다
메시지 패싱에 기반하는 병행/병렬 프로그래밍에 특화되어 있다 – Erlang 과 유사함
C 와 달리 내장 타입이 좀 더 다양하다
UTF-8 내장 + range() 문을 사용하면 문자열을 byte 단위와 문자 단위(variable-length)로 모두 순회하기 쉽다
문자열은 상수고, 배열도 그냥 복사된다. 이건 Erlang 에 대해 내가 쓴 글에서도 말했듯이, 변하지 않는 데이터가 병렬성에선 정말 중요하다.²

단점도 몇 가지,

아직 툴 체인이 완성되지 않았다 – gccgo(gcc를 백엔드로 씀), 8g(x86 용), 6g(x64 용), 5g(arm 용) 등이 따로 논다. 특히 전자와 뒤의 3가지는 정말 따로 놈. 내장 기능의 수행방식도 약간 다른 수준이라.
라이브러리가 아직 정말 빈약하다 –_-;
툴 체인이 완성되지 않았다?랑 비슷한 얘기지만, 아직 충분히 최적화된 코드가 아닌 느낌. 몇몇 벤치 마크 결과가 그리 좋지 않다. (Java 보다도 느리다니…)

뭐 그래도 Erlang 보다는 많은 수의 (예비) 프로그래머가 있으니(C/C++/Java) 상대적으로 병렬 프로그래밍 작성할 때 쓰기엔 나은 듯도 하다. 다만 얼마나 빨리 성숙한 상태에 도달하느냐가 문제지만;

덧. (MacOSX 의) Exposé 의 Spaces를 이용해서 Keynote 프레젠테이션과 코드를 실행하는 터미널을 번갈아 가며 쓰려고 했다. 그런데 프레젠테이션 중엔 Ctrl + 화살표³ 로 다른 스페이스로 못 넘어 가더라. 그래도 Command + Tab 으로 프로그램 선택이 바뀌면 스페이스 바뀌니 어찌 되긴 하더라.

물론 GC도 제약이라면 제약이지만 추가사항으로 치자
물론 배열을 복사하지 않고, 배열 전체 혹은 일부를 참조하는 slice란 문법을 지원한다
Fn +인가? 손이 기억하는 거라 잘 모르겠다