the rest is silence

월급을 올려준다길래 햄릿처럼 고민하며 열심히 일했다. 그런데 햄릿 그 놈은 일을 전혀 안 했지. 흥부전의 흥부가 일을 안 한 것처럼. 재주가 하나도 없는 흥부는 가난해서 매번 끼니 때우기도 힘들었다. 마누라는 강남 제비와 바람이 나서 십개월마다 지붕 위의 박처럼 배가 불렀다. 춘향이는 동네 한량과 놀아나던 창부의 자식이었고 수절을 지킨답시고 동사무소 7급 공무원 보다 한끗발 높은 중앙정부의 차관급 공무원에게 들러 붙어 먹었다. 심청이는 뙈놈에게 몸 팔아서 홀아비를 부양했다. 한석봉의 어머니는 떡을 쳐서 아들을 공부시켰다. 산에는 호랑이같은 산적들이 고개를 넘는 행상들로부터 엽전을 삥뜯고 돈 없는 처녀들을 희롱했다 -- 떡 하나 주면 안 잡아먹지. 여자들이 몸을 팔며 연명하는 처절하고 서글픈 사연들이다.

자전거 갖고 지하철 탈 수 있다 -- 비가 와서 자전거를 주욱 못 탔다. 1년여를 타는 동안 정강이에 근육이 붙었으나 근력은 그다지 늘지 않았고 건강해진 만큼 밥을 많이 먹어 체중만 900g 늘어났다. (175cm-100) * 0.9 = 67.5kg. 나는 정확히 표준 체중이 되었다. 아내의 권고로 보건소에서 3400원짜리 B형 간염 접종을 맞고 하루종일 몸 상태가 안 좋았다. 앞으로 두 번 더 맞아야 한다.

동강과 서강이 만나는 영월에 큰 비가 내렸고 인근의 오지 마을은 쓸려가거나 고립되었다. 인도네시아는 화산 폭발에 이어 또다시 강진이 들이닥쳤다. 기꺼이 자전거를 들쳐메고 산을 탈 각오로 7/14-7/17 황금연휴 동안 동강변을 따라 영월까지 가는 자전거 여행을 할 계획이었으나, 적어도 1년 동안은 불가능하게 되었다. 운이라고 해 두자.

그대신 사흘 동안 집에 틀어박혀 창 밖에서 들리는 빗소리를 들으며 닥터 후와 베로니카 마스 시리즈를 봤다. 마스는 귀여운 고등학생 탐정 얘긴데 스토리를 어거지로 뜯어맞춰 시리즈를 말 그대로 근근이 이어갔다. 보는 내내 이런 걸 꾸역꾸역 보고 있는 스스로가 한심스러웠다.

전에 구입한 노트북의 액정 한 구석이 누렇게 색깔이 떠 있었다. 구입 후 액정을 교체하려고 했지만 시간이 없어서 그동안 미뤄두고 있었다. HP에 전화를 걸어 증상을 설명했더니 사무실로 찾아와 액정을 교체해 준다. 액정을 교체하면 pure plate를 설치하려고 했는데 마침 행사중이라 15인치 퓨어 플레이트 + 퓨어 가드(노트북 액정 상판 보호용 필름)을 3만 2천 8백원에 구입했다. 용산 매장에 찾아가 직접 붙여달라고 했다. 용산에 간 김에 gigabyte neon cooler 8 pro를 16000원에 구입했다. 집 컴퓨터에서 소리가 심하게 나는데 아내는 아무 느낌이 없나보다. 노트북 액정이 누렇게 떠있다가 교체후 맑아졌는데 그걸 봐도 아무 느낌이 없는 모양이다. 퓨어 플레이트 달아도 아무 느낌이 없을 것이 틀림없다. 아내는 일단 하늘이 내리는 천업이랄 수 있는 예술가, 기술자, 과학자가 될 타잎은 아니다. 3년 이상 꾸준히 관찰해 본 바에 따르면 상업이나 언어, 협상, 관리, 정치, 계산, 운동, 어느 쪽에도 소질이 없다. 믿어지지 않지만 타고난 housewife 팔자란 것도 있는 모양이다.

마사 스튜어트 정도를 기대하는 것은 아니지만 중론에 따르면 housewife도 아무나 하는 것은 아닌 듯.

비스타에 기본 폰트로 사용할 예정이라는 '맑은 고딕' 폰트를 컴퓨터 마다 설치했다. 윈도우즈 최초의 완전한 한글 트루타잎 폰트라는데(맥에는 이미 오래전부터 있던 것이지만), 여러 사람들의 입소문을 타고 많이 퍼진 모양이다. 가독성이 높고 글자 모양이 예쁘다. 한 동안 써보고 그래도 질리지 않으면 그대로 사용할 것이다.

여러 차례 반복해 보았지만 아무 소득이 없는 산학협력 프로그램을, 그래도 해야 한다고 말하자 유사장은 어깨를 으쓱하며 날더러 별난 사람이라고 말했다. 실력이 없다는 이유로 사람을 가차없이 잘라야 한다고 눈 한번 깜짝이지 않고 말하면서 정작 도움이 되지도 않는 생초짜 인턴 사원들을 받아들이고 시간낭비에 불과한 산학협력을 그래도 해야 한다고 말하니까. 사장님은 마누라처럼 내게 일관성이 없어서 어제 한 말과 오늘 한 말이 다르다고 여겼다. 논리적 수미 일관성이라...

내가 일관성이 있는지 없는지는 여기서 중요한 것이 아니므로 나중에 떠들고, 요점은, 인간에게 기회를 주고 주어진 기회에도 불구하고 제대로 하지 못하면 제거한다. 쯤 된다. 그리고 기회는 질릴 때까지 여러 번 줘봐야 한다. '제거'라니까 몹시 살벌하게 들릴 것 같은데, 그렇지는 않았다. 우리가 '함께' 기회를 나누는 일만 없을 따름이다. 그리고 나를 제외하고도 그가 다른 사람들과 여전히 기회를 나눠 가질 수 있다. 오히려 더 많은 기회를 얻을 수도 있다(산학을 하던, 인턴 사원을 뽑던 평균적으로 일년 내내 프로젝트를 3개 진행하는 엄청난 내 업무량은 변함이 없다). 그거라도 안하면 그 아이들이 10여년 이상 프로그래밍을 한 사람들과 소위 경쟁상대가 되지 못한다. 나 같은 사람은 거의 20년 동안 프로그래밍을 했고 그 20년 동안 뭔가를 조건반사적으로 학습했다. 10년 전에는 프로그래머가 특수한 직업군이라 개나 소나 무엇을 하든 최소한 기회 또는 특권이 주어졌다. 지금은 그들에게 기회가 주어지지 않거나, 스스로 어렵게 기회를 만들어야 한다. 애당초 상대가 안되는 게임이다.

독일에서는 회사에서 야근하는 사람들의 연봉을 깎는다고 한다. 그들이 야근을 함으로서 다른 사람들이 그 잡을 가질 '기회'를 얻지 못하게 되니까. 사실인지 아닌지는 모르겠으나, 공평하게 들린다. 균등한 기회 부여를 거의 모든 사람들이 떠들어 대면서도 정작 특정 사안에 대한 개개인의 이해관계가 구체적으로 쐐기날처럼 콕 찝어서 거론될 때는 어김없이 개수작을 하는 것을 뭐라고 이해해야 할까? 그럴 때, 논리적 수미 일관성이 부족하다고 할켜줘야 하나?

엊그제는 갑자기 논쟁이 붙었다. STL이 속도가 느리고 학교에서 애들 공부할 때나 쓰는 거지 실무에 적용하긴 좀 그래서 안 쓴다고 말했는데, .net 2005에서 stl 속도가 빨라졌다며 표준 라이브러리인 stl을 안 쓰는 것은 바보같은 짓이라는 말을 하길래, 어 정말 빨라졌나? 하는 생각에 간단한 벤치마크를 했다.

void test_stl()
{
map channels;
...
for (int i = 0; i < MAX_ITER; i++) {
sprintf(s, "Item%d", rand() % MAX_CHANNELS);
ChanndelDef* p = channels[s];
...
}
}

ChannelDef* find(const char* key)
{
for (int ch = 0; ch < MAX_CHANNELS; ch++)
if (strcmp(channels[ch].key, s) == 0)
return &channels[ch];
return NULL;
}

void test_loop()
{
...
for (int i = 0; i < MAX_ITER; i++) {
sprintf(s, "Item%d", rand() % MAX_CHANNELS);
ChannelDef* p = find(s);
...
}
}

test_stl()이 소스 코드가 작고 직관적으로 알기 쉽다. 게다가 test_loop() 보다 빠르다고 생각할 것이다. 그럼 얼마나 빠를까? MAX_CHANNELS (n)이 작으면 test_stl()이 test_loop()보다 얼마 안 빠르다. 128일 때 test_stl()이 test_loop()에 비해 약 2배 정도 빠르다. 10억번 테스트 해 봤다.

두번째로, 만약

1. channels 어레이가 작고
2. 입출이 거의 없으며
3. 어레이가 소팅되어 있으며
4. find() 대신 bsearch를 사용하도록 test_loop()를 바꾸면

굳이 벤치마크를 안 돌려 봐도 계산상 test_loop()가 '최악의 경우' test_stl()보다 n / (ln(n) / ln(2)) * 1/2 배 빠르다. 최악의 경우다. 대략 3.5배~5배 정도 더 빠르다. 저건 실제로 컴파일러에서 심볼 테이블을 참조할 때 쓰이는 루틴이다. 소스가 2백만 statement이고(텍스트 파일로 무려 200MB) 한 statement에서 참조되는 심볼 수가 많으면 128개인데 심볼 테이블의 추가/삭제가 거의 일어나지 않는 경우다. 간단히 말해 그럴 때 stl map이나 mfc의 CMap 따위를 쓰면 좆된다. 컴퓨터 성능이 엄청나게 좋아지고 툴들이 대단히 빠른 속도로 발전했으며 프로그래밍 방법론이 지속적으로 개발되고 논의되지만 프로그래밍의 근본은 바뀌지 않았다. 문제의 패턴을 분석하고 패턴에 알맞는 알고리즘과 데이터 구조를 적절하게 사용해야 한다는 것. '무조건 stl이 좋다'는 식이 아니라.

굳이 벤치마크를 짤만한 케이스가 못되는 것이지만 hash를 비롯한 여러 종류의 알고리즘을 직접 프로그래밍해 본 적이 없고 앉아서 빅 오를 스스로 계산해 본 적이 없는 비전산과 출신의(전산 출신도 요즘은 마찬가지지만) '근거가 없는' 논리를 잠재우려면 어쩔 수 없었다. 저 계산식이 어째서 저 모양이냐고 물으면 그것도 설명해 줘야 하는데, 이렇게 되면 또 잘난 척 한다는 말이나 듣는다.

하여튼 증거를 댔으니, 회사 내부에서 프로그래밍시 stl 사용을 다시 보류했다 -- 사용하고 싶으면 사용하는데, 그래도 속도는 나와야 한다...는 뜻이다. 기계가 충분히 빨라져서 stl을 쓰나 안 쓰나 가시적인 속도 차이가 더 이상 나지 않는다면 뭐, 언젠가는 나도 사용할 것이다.