김 용묵의 절대공간 - 블로그

1.

우리나라는 잘 알다시피 삼권분립과 민주주의 정치를 표방하는 나라이다.
그런데 가만히 생각을 해 보니 입법부를 상징하는 국회의사당은 여의도에, 행정부의 상징인 정부 종합 청사는 종로구의 광화문-경복궁 일대에, 그리고 사법부를 상징하는 검찰청· 대법원은 딱 강남 서초구에 있다.
정부 청사는 과천과 대전에도 있긴 하지만 어째 우리나라 정치를 구성하는 각 축이 서울 최고 도심과, 강남과 여의도라는 부도심에 하나씩 마치 터줏대감처럼 자리잡아 있는 게 굉장히 신기하다. 의도적인 배치인지?

우리나라야 땅도 좁고 교육· 문화· 정치· 경제 할 것 없이 닥치고 무조건 서울 올인이지만, 미국만 해도 잘 알다시피 행정 수도와 실질적인 경제 수도는 완전히 다르다. 행정 수도인 워싱턴 D.C.는 시내 전역에 고도 제한까지 걸려 있는 한가한 계획형 중소도시 규모인 반면, 뉴욕이... 더 설명이 필요하지 않은 규모이다.
오스트레일리아도 행정 수도인 캔버라와, 실질적인 경제 중심지인 시드니는 서로 따로 논다.

그래서 서울의 과포화를 막고자 우리나라에서도 행정 수도의 이전이 논의되곤 했다. 이는 심지어 옛날에 박통도 구상하던 떡밥이었다. 그 시절에 그에게는 국토 균형 발전 나부랭이보다도, 서울이 북한하고 너무 가까이 있는 것부터가 굉장한 골칫거리였기 때문이다. 그의 재임 시절에 무장공비가 북악산을 넘어 청와대에 쳐들어 올 뻔하기도 했으니 얼마나 충격이 컸겠는가?

그래서 그는 강북 사대문 안의 옛 서울보다도 최소한 한강은 건넌 뒤인 강남을 개발하고, 서울에 있던 각종 연구소들을 대전으로 옮겼다.
하지만 전쟁이라도 나서 서울 전체가 박살이 나지 않는 한, 한 나라의 최고 중심지에서 잘 살던 사람이 지방으로 쉽게 내려가려 하지는 않을 것이다.

뭐, 박통은 균형 발전에도 관심이 아주 없는 건 아니었다. 그래서 서울의 무분별한 팽창과 과포화를 막으려고 외곽 곳곳에 그린벨트를 만들었다. 그게 오늘날엔 대부분 해제되는 추세이지만 말이다.

2.

예전에 본인은 군부대와 인접해 있는 전철역에 대해서 글을 쓴 적이 있다.
그런데 군부대 정도가 아니라 역 주변이 농경지 내지 허허벌판인 곳도 서울 시내에 있다. 분당선 모란-야탑이나 8호선 복정-산성처럼 역의 중간 구간이 허허벌판인 게 아니라 아예 역 주변이 비어 있는 것 말이다. 걔네들은 또 어차피 서울 밖이기도 하고.

강서구에는 역시나 5호선 마곡 역 주변과 아직 개통도 안 한 9호선 마곡나루 역 주변이 아주 유명한 예이다. 몇 년 안으로 이런 진풍경은 볼 수 없어질 것이고 여기도 빽빽한 빌딩으로 가득 들어설 터이니, 관심 있으신 분은 미리 여길 답사해서 사진 기록을 많이 남겨 두기 바란다.

한편, 남서쪽에는 7호선 천왕 역 주변이 대표적인 허허벌판이었다. 장암(7), 남태령(4), 청계산입구(신분당선)에 필적하는 잉여역이었으나 이것도 아파트가 지어지면서 모습이 바뀌는 중이다. 명목상 서울이긴 하지만 여전히 광명시와도 아주 가까운 위치임.

허허벌판이 서쪽에만 있는가 하면 그렇지는 않아서 뜻밖의 장소에도 있다. 바로 동쪽 끝자락인 8호선 문정 역 주변. 지하철까지 지나는 멀쩡한 성남 대로 근처에 웬 큼직한 면적의 땅이 놀고 있어서 무척 놀라게 된다. 물론 이런 광경을 볼 수 있는 때는 흔치 않다.

6호선의 주변에는 딱히 이런 허허벌판을 본 기억이 없다. 하지만 주변이 명목상 허허벌판으로 가려져 있는 녹사평 역이 있으니 넘어가도록 하자.
어째 2기 지하철의 주변에만 이런 허허벌판이 있는 것 같지만, 2호선 강남 구간도 처음 건설되던 시절에는 허허벌판이 많았고, 4호선 노원· 도봉구 구간도 그 당시에는 말도 못 할 정도로 주변이 황량했다.

3.
고려대와 경희대 사이에 홍릉 수목원과 카이스트 서울캠(현재는 경영 대학원만 서울에 남아 있음), 고등 과학원, KDI와 각종 연구소들이 들어서 있는 그쪽 일대는 서울에서 가장 대덕 연구 단지 분위기를 느낄 수 있는 장소임이 틀림없다.
한때는 국가 정보 대학원도 여기에 있었다고 한다. 하지만 서울이 덩치가 커지고 여기도 예전만치 오지 느낌이 안 나게 되자, 지금은 성남과 의왕의 경계인 모 산골짜기로 이사를 감. 시기를 보니 국정원이 남산에서 내곡동으로 이사 갈 때 같이 간 걸로 보인다.

4.
마곡 역은 어째 출입구가 하나뿐이고 도로(공항로)의 건너편에 출입구가 없다. 지하철이 도로 정중앙을 파면서 건설되지 않고, 이례적으로 한쪽으로 치우쳐 건설되었기 때문이다. 그렇잖아도 도로 옆도 허허벌판인데 거기를 파헤치면 되지, 굳이 멀쩡한 도로를 파헤쳐서 민폐 끼칠 필요는 없다고 판단한 모양이다. (터널식으로 지을 필요는 더욱 없으므로)

5.
전철 노선 중에, 양 역은 지하인데 그 사이에 지상 구간이 잠깐 나오는 예로 어떤 게 있을까? 의외로 흔치 않다. 한강을 건너는 지하철 노선을 생각해 봐도, 양 역 중 하나는 꼭 지상인 경우가 대부분이기 때문이다.
8호선 복정-산성이 가장 대표적인 사례이고 3호선의 북쪽 일산선 구간은 자주 지상과 지하를 오르내리긴 하는데, 저런 경우가 또 있는지는 모르겠다.
지금은 공항 철도 DMC-김포공항 구간이 추가되어 있다. 양 역은 모두 지하이지만 중간에 강도 건너고 지상 구간이 충분히 존재한다.

Posted by 사무엘

GDI+는 잘 알다시피 전통적인 윈도우 API가 제공하는 GDI에서 더 나아가, 더 향상된 그래픽과 더 깔끔해진 프로그래밍 패러다임을 제공하는 그래픽 API이다. 사실, 닷넷에서는 애초에 기본 그래픽 API가 GDI+이다. (System.Drawing 네임스페이스)

GDI+는 벌써 10년 전, 닷넷 프레임워크가 첫 등장하고 윈도우와 오피스에 XP라는 브랜드가 붙던 시절에 도입되었다. MS가 제공하는 API로는 흔치 않게 C언어 함수도 아니고 그렇다고 DirectX 같은 COM도 아닌, C++ 언어 형태로 되어 있다. 물론, 그래도 실제로 링크를 해 보면 symbol들은 다 C언어 함수 호출 형태로 된다. C++ 클래스는 단순히 C 함수를 호출하는 wrapper인 것이다.

GDI+는 여러 편리한 기능을 많이 제공하지만, 무엇보다도 벡터 그래픽에 안티앨리어싱을 넣기 위해서라도 쓰지 않을 수 없다. 이런 간단한 기능은 그냥 기존 GDI 함수에다가도 옵션을 확장해서 좀 넣어 주지 하는 아쉬움이 있다. 재래식 GDI로도 안티앨리어싱된 텍스트는 얼마든지 찍을 수 있는 것처럼 말이다. (LOGFONT 구조체에 글꼴의 품질을 지정하는 추상화 계층이 있기 때문에, 나중에 추가된 안티앨리어싱 기능도 얼마든지 지정 가능)

재래식 GDI는 열악하던 컴퓨터 환경에서 최대한 장치 독립적인 추상적인 그래픽 계층을 구현하는 게 목표였다. 그래서 래스터 그래픽보다는 벡터 그래픽에, 애니메이션보다는 정적인 그래픽에 초점이 가 있었다. 그 추상화 계층이 확장성 측면에서 편리한 점은 분명 있었지만, 색깔을 하나 바꾸려고 해도 펜이나 브러시를 다시 만들고, 도스 시절의 그래픽 프로그래밍 때는 할 필요가 없었던 GDI 객체 관리를 해야 하니 상당히 불편했다.

그래서 GDI는 게임 그래픽용으로는 적합하지 않은 구석이 있었다. 물론, 지금과 같은 틀을 유지하면서도 JPG/PNG 이미지를 지원하고, 알파 채널 비트맵 Blit이나 별도의 gradient fill 함수를 추가하고, 윈도우 2000처럼 펜이나 브러시의 색깔을 손쉽게 바꿀 수 있는 DC pen/DC brush 같은 기능을 stock object로 넣는 등, 기능 개선이 꾸준히 진행돼 왔다. 하지만 MS 측에서는 이에 만족하지 못하고 이 참에 API를 근본적으로 갈아엎고 싶다는 욕망을 느꼈던 모양이다.

GDI+는 모든 API가 자신만의 별도의 namespace 안에 선언되어 있으며, POINT 같은 간단한 자료형도 자신만의 것을 재정의하여 쓸 정도로 기존 윈도우 API와는 거리를 두고 만들어졌다. 그리고 C++답게 같은 함수도 다양한 overload 버전이 존재하며, 좌표는 정수뿐만이 아니라 실수로도 받기 때문에 편리하다.

사소한 것이다만, 글자를 찍을 때 null-terminated string에 대해서 글자 길이 지정을 생략해도 되는 것 역시 마음에 든다.
전통적으로 윈도우의 GDI 함수들은 글자를 찍는 함수들은 문자열 길이를 반드시 지정해 주게 되어 있다. 왜냐하면 한 null-terminated string을 부분적으로 여러 줄에 걸쳐 찍어야 할 일도 있기 때문이다.

그러니 그런 API 디자인이 수긍은 가지만, 어차피 한 줄밖에 찍을 일이 없는 문자열을 매번 _wcslen 해 주는 것도 귀찮지 않은가. 예전에는 gdi가 아니라 user 계층에 있는 DrawText 같은 고수준 함수나 문자열 길이 지정을 -1로 생략이 가능했던 반면, GDI+는 이 정책이 좀 더 확대되었다.

GDI+는 GDI에 비해서 state machine으로서의 의미가 크게 퇴색했다. 그래서 그리기에 필요한 모든 정보들을 함수 호출 때 매개변수로 일일이 전달해 줘야 하는 경우가 많다. 가령, current position이라는 개념이 없기 때문에 MoveTo와 LineTo 따로가 아니며, SelectOjbect라는 개념도 없어져서 그리기 함수 때 매번 펜이나 브러시에 해당하는 개체를 따로 공급해 줘야 한다.

이런 디자인은 편리한 점도 있지만, 당장 화면에 뭔가를 찍는 드로잉 말고 벡터 path를 기록한다거나 메타파일 같은 걸 만들 때는, 내가 보기에 좀 불편하게 작용하는 점도 있는 것 같다. 가령, GDI에서는 똑같이 HDC이고 여기에다가 BeginPath를 해 주면 그때부터 path 그리기 모드로 GDI가 상태 관리를 하면서 동작한다. 그러던 것이 GDI+에서는 Graphics와 GraphicsPath라고 클래스가 아예 갈라졌다. 두 개체를 상태별로 분리한 건 분명 잘한 디자인이라는 거 인정한다.

하지만 Graphics 말고 GraphicsPath는 어차피 예전 위치에서 계속해서 이어서 그래픽을 기술하는 게 많은 만큼, 재래식 GDI처럼 current position이 있는 게 편리하지 않을까 싶다. 지금 API 체계에서는 직전 위치에 대한 정보를 응용 프로그램이 계속 공급해 줘야 한다.

또한, 복잡한 path를 화면에다 그릴 때, 예전 GDI는 지금 DC가 가지고 있는 펜과 브러시로 윤곽선을 그리고 내부를 채우는 것을 함수 호출 한 번으로 동시에 할 수 있었다. 그러나 GDI+는 선을 그리는 것과 내부를 채우는 것을 따로 해야 한다. path의 경계를 추출하여 래스터라이즈하는 것은 상당히 복잡한 계산이 필요한 작업인데, 동일한 작업이 비효율적으로 중복 적용되는 건 아닌지 우려된다.

즉, 본인은 GDI+에 대해서 참신한 기능은 분명 마음에 든다. 이 글에서 언급된 것 말고도 여러 고급 기능들이 있다. 윈도우 비스타 Aero와 연동하는 일부 드로잉 기능(가령, 클라이언트 영역에도 반투명 Aero 효과를 추가하고, 거기에다 글자를 찍는 것)은 오로지 GDI+로만 접근해야 하는 것도 있다.

하지만 (1) 그냥 재래식 GDI API에다가 옵션을 추가하는 형태로 구현했어도 충분해 보이는 것, (2) GDI+가 바꿔 놓은 API 디자인이 오히려 좀 불편하고 비효율적일 수도 있겠다 싶은 것에 대해 비판적인 안목을 갖고 있다. 속도가 재래식 GDI보다 꽤 느린 건 차치하고라도 말이다.

Posted by 사무엘

1. 대중가요의 음정

TV나 인터넷 같은 매체에서 어렴풋이 듣기만 했던 유행가를 노래방에서 동일한 조(음정)로 그대로 따라 불러 보면, 말도 안 되는 음역 때문에 낭패를 보는 경우가 많다. 그래서 뒤늦게 음정을 3~4도 가까이 낮추게 되고, 이 때문에 곡의 분위기가 확 바뀌면서 흥도 불가피하게 잠시 깨진다. 나만 그런지는 모르겠지만, 일반인은 대체로 높은 미나 파 정도가 고음의 한계이지 않은가?

그런데 가수들의 노래를 실제로 들어 보면, 도대체 발성 연습을 어떻게 했는지, 높은 옥타브로 노래를 부르면서도 그다지 높은 옥타브를 내는 것 같지도 않다.
오래 된 노래이긴 하다만, 쿨의 <운명>을 생각해 보자. 본디 음정인 C장조로 그대로 부르기 참 난감하다. 1-2-3-4 이후에 “왜 하필 이제야 내 앞에 나타나게 된 거야” 가사는 높은 옥타브일까, 일반 옥타브일까?

“애타게 찾아 헤맬 때는 없더니”는 일반 옥타브로 부르기엔 너무 낮은 음역인 반면, 나중에 “며칠 후에 날벼락이 떨어졌어”는 높은 옥타브로 부르기에는 너무 높은 음역이다. 높은 라까지 소리 지르다간 목이 심하게 괴로울 것이다. 대중가요 중에는 이런 식의 딜레마가 들어있는 곡이 많다는 뜻이다.

<운명>을 일반인이 무리 없이 따라 부를 수 있는 음정은 G나 A장조 정도이다.
그러고 보니, CCM 중에 송 명희 작사· 최 덕신 작곡의 유명한 곡인 <나>(나, 가진 재물 없으나, 나, 가진 지식 없으나)도 주찬양 선교단 앨범에서는 C장조로 발표되었으나, 최 용덕 씨가 편집한 찬양곡집인 <찬미예수> 시리즈에서는 A장조로 편곡되었다. C장조로 부르면 무려 높은 솔까지 올라가기 때문에 말이다. -_-; (‘공평하신 하나님이’ 부분)

글쎄, 주변에서 듣기로는, 이렇게 고음 발성에 단련된 직업 가수들은 반대로 일반인들이 별다른 어려움 없이 잘 내는 저음을 제대로 발성 못 한다고 한다..

2. 자동차 전용 도로에서 위험 요소

일반적으로 자동차 운전은, 수많은 자동차들과 부대끼면서 신호 살피고 차선도 바꿔야 하는 시내 운전이 자동차 전용 도로나 고속도로에서의 운전보다 더 까다롭다고 여겨진다. 기술적으로 더 어렵고 머리를 써야 한다기보다는 그냥 신경이 더 쓰이고 스트레스를 더 받는다는 표현이 정확하겠다.

시내 운전은 접촉 사고의 위험이 상존하고 있지만, 딱히 사람이 죽을 정도의 대형 사고가 날 가능성도 별로 높지 않다. 음주운전 미치광이 차량이 중앙선을 넘어와서 내 차와 정면 충돌이라도 하지 않는 한 말이다.

자동차 전용 도로 이상에서는 사정이 달라진다. 중앙 분리대 있지, 보행자나 오토바이 같은 돌발상황 없지, 신호도 안 받지. 그저 쌩쌩 달리기만 하면 되는 자동차의 천국이니 아주 편할 것 같다. 하지만 이런 곳에서는 마치 망망대해 위에서의 빙산 내지 암초만큼이나 정말 조심해야 할 게 있다. 갑자기 퍼져서 도로 위에 서 버린 차..;; 이건 영락없이 추돌 사고로 이어진다. 그리고 참고로, 운동 에너지는 속력의 “제곱”에 비례한다. ㅎㄷㄷ

병목 지점이 아니고, 절대로 막힐 시간대나 구간이 아닌데 자동차 전용 도로가 갑자기 막히기 시작한다면 이건 십중팔구가 앞에서 퍼져 버린 차 때문이다. 이런 민폐 차량이 없어야 하겠지만 굉장히 오래 된 차, 제대로 관리와 정비를 안 한 차는 장거리 여행 중에 언제 저렇게 뻗을지 모른다.;; 돌연사라는 게 사람에게만 있는 게 아니다.

솔직히 자동차 전용 도로에서는 핸들을 일부러 꺾어서 가드레일을 부수고 절벽으로 추락하는 게 아니라면, 날 수 있는 사고가 사실상 추돌밖에 없다. 그게 무진장 위험하다. 게다가 안전 거리 안 지키고 과속 좋아하는 우리나라 운전 문화의 특성상, 한번 앞차가 갑자기 서 버리면 그게 연쇄 추돌로 이어진다(안전 거리 지키면서 운전하면, 그 넉넉한 간격에 다른 차가 꼭 끼어 들어온다. ㅆㅂ-_-).

고속도로까지 갈 것도 없고, 강변북로, 내부 순환로, 동부 간선 같은 자동차 전용 도로만 몰아도 저렇게 뻗은 차를 본인은 지금까지 심심찮게 봤으며, 그로 인해 야기된 정체를 꽤 자주 경험했었다. 운전하기 당장 편한 자동차 전용 도로라고 해서 방심해서는 결코 안 되겠다. 그리고 원인보다 결과를 더 좋아하는 우리나라의 법률은, 뒤에서 박은 차에게 이유 불문하고 굉장히 불리하게 되어 있다. -_-.

3. 대학원 세계

대학원에서 공부를 계속할 걸 염두에 두고 있는 사람에게 가장 중요한 학교 선택의 기준은 코스별로 이렇게 나뉘는 듯하다.

학사는 간판, 석사는 과, 박사는 교수.
뭐, 위의 세 변수를 모두 만족하는 동일 학교에서 계속 짱박혀 있는다면 더 할 말이 없다.

학사에 대해서는 더 이상의 자세한 설명은 생략한다 급이니 넘어가겠다. 학부 출신 학교와 평점은, 교수나 연구직 업종으로 먹고 살려는 사람에겐 평생 따라다니는 신분· 계급이나 다름없다. 그걸 보완할 수 있을 정도로 압도적으로 뛰어난 다른 대외 활동이나 입상 실적 같은 게 있지 않은 이상 말이다.

그 뒤 석사 정도 되면 협동과정도 있고 본격적으로 자신이 레알 오덕질을 할 만한 분야를 살펴볼 재량이 생긴다. 사실, 대학교에서 어떤 새로운 분야의 학과가 가장 먼저 개설되는 곳도 석사이다. 학사는 그 학문이 완전히 정설로 안정화되고 보편화되어야만 개설되며, 박사는 석사 졸업생이 연구를 계속해서 쭉 발전해 나가야 개설될 수 있으니 말이다.

즉, 대학원은 학부처럼 그저 닥치고 간판만 짱인 구도가 아니다. 그렇기 때문에 심지어 여대에도 어떤 분야에 아주 저명한 교수가 있다면 그에게서 지도를 받으러 남자 대학원생이 들어온다.

또한 수업 성적도 학부만치 중요하지는 않다. 교수가 학부생들의 얼굴은 다 모르지만, 대학원생은 교수 밑에서 사실상 일대일 관리를 받으며 졸업이 당장 지도 교수에게 달려 있다. 그러니 대학원생은 수업 성적이 C, D를 받는 게 문제이기에 앞서 교수에게 찍히는 게 훨씬 더 큰 문제이다.

애초에 대학원의 코스웍의 목표는 달달 외우고 시험 쳐서 점수 잘 따는 게 아니다. 수업 내용에서 연구 주제 떡밥을 하나 물어서 논문을 쓰는 게 목표이다. 공부에 대한 패러다임이 다르고 학교에서의 위상이 다른 셈이다. 그렇기 때문에 학기당 듣는 과목 수도 학부 때보다 훨씬 더 적다.

다만, 그렇다고 해서 대학원은 출신 간판이나 평점이 아예 중요하지 않다는 소리는 절대로 아니다. 대학원은 아무나 가는 곳이 아니고 대학 입시 같은 수준의 경쟁이 없기 때문에, 지원자도 뜻이 있어서 아주 특수한 연구 환경을 찾는 게 아니라면, 같은 조건이면 당연히 더 좋은 간판의 학교로 몰린다.
교수들도 이를 아니, 가능하면 더 평판이 좋은 대학이나 서울과 가까운 대학으로 가려 애쓴다. 그래야만 더 똘똘한 학생들이 휘하에 들어오니까.

4. 군대 비하 발언 (이건 오랜만에 좀 쓴소리)

노인 비하와 더불어, 군대에 대해서 헛소리를 하는 사람치고 사상과 가치관이 제정신인 사람을 난 지금까지 못 봤다.

• 지난 2008년 건군 60주년 국군의 날 행사 때 군대 폐지를 요구하면서 알몸 퍼포먼스를 벌인 강 모 씨
• 2010년, 군대 비하 발언으로 대망의 평생까임권을 획득한 EBS 강사 장 모 씨
• 그 다음으로 얼마 전에 해군을 해적이라고 비하하여 구설수에 오른 극렬 운동권 고대녀 김 모 씨

마지막의 경우, 일반 병사들을 해적이라고 싸잡아 비하한 건 아니라는 해명은 언어도단이요 궤변이다. 말 같지도 않은 변명이다. 해적 기지는 병사들을 비롯해 그 안에서 근무를 하는 사람들이 다 해적이니까 해적 기지라는 뜻이지 않은가. 해군 기지 건설을 반대하더라도 그런 돼먹지 못한 표현을 쓰면서 반대해서는 안 된단 말이다! 나이도 아직 젊은 사람이 좀 철이 들었으면 하는 바람이 있다.

미우나 고우나 국군은 나라의 주권을 지키는 집단이다. 누군 군대를 두고 싶어서 두는 게 아니고, 멀쩡한 청년들을 일부러 괴롭히고 싶어서 징병제를 시행하는 것도 아니다. 막대한 돈을 굴려서 군대를 운영하지 않을 수 없게 만들고 우리나라로 하여금 징병제를 시행하지 않을 수 없게 만들고 있는 진짜 배후가 뭔지 정녕 모른단 말인가?
그리고 우리나라가 옛날에 나라를 스스로 지킬 힘이 없어서 정규군이 강제 해산되고 무장이 해제된 뒤에 어떤 일이 일어났으며, 그때 외세에게 어떤 참혹한 꼴을 당했는지를 정녕 모르겠는가?

누군 뭐 국가 위정자들이 하는 짓이 다 마음에 들어서 이런 논리를 펴는 줄 아는가? 내가 이런 초등학교 사회· 도덕 시간에나 나올 법한 고리타분하고 구태의연한 훈계조 설교를 왜 또 적으면서 열을 내야 하는지 모르겠다? -_-;;

강 씨와 김 씨는 그냥 ‘옛다 관심 중2병’이 의심되는 케이스에 더 가깝다만, 2년 전의 EBS 강사 사건은 내겐 가히 멘탈 붕괴를 초래할 만한 충격과 공포 수준이었다. 도대체 저 나이 쳐먹도록 도대체 머리에 뭐가 들어있고 평소에 국방에 대해서 무슨 생각을 하고 지냈기에 강의 중에 저런 저질 망언이 튀어나왔는지 내 상식으로 이해가 되지 않는다. 미쳐도 단단히 미쳤다.

이런 인간에 비하면 일명 ‘군삼녀’의 망언은 차라리 애교 수준이다. 어째 머리는 좋아서 서울대 나오고 고려대 나오고, 공부깨나 하고 말빨 있어서 남 가르치는 일을 하면 뭘 하나. 그러고도 정신 연령 내지 정신 상태는 저 지경이 될 수가 있다. 안타까운 일이다.

Posted by 사무엘

코레일이나 각종 지하철 회사 같은 우리나라의 철도 운영 기관들은 현재 대체로 빚이 많으며 운영난을 겪고 있다. 그러나 그 이유는 근본적으로 막대한 건설 부채를 떠안고 있어서가 가장 크며, 다음으로 원가보다 훨씬 더 저렴한 운임, 손해를 감수하고 공익을 추구한 비경제적인 노선 운영, 그리고 전세계에서 유례를 찾을 수 없는 노인 전철 완전 무임 승차로 인한 손실이 뒤를 잇는다.

방만· 부실 경영이 차지하는 비중은 없다고는 할 수 없어도 아주 미미하다. 한국 철도가 굉장히 사회주의적인 준독점 시스템인 건 사실이지만, 태생적으로 적자를 감수하고라도 매우 큰 복지 혜택을 제공하고 있는 것도 사실이다. 이런 사실에 대해 무지한 채 그저 상업주의 민영화만이 철도 경영 효율을 위한 방안이라는 생각에는 본인은 공감할 수 없다.

아무리 오늘날의 노인 어르신들이 국가 근대화의 초석이었다고 하지만, 완전 무임은 너무하다는 생각이 든다. 단돈 100원을 내더라도 뭔가 지불하는 건 있어야지, 아예 0은 도덕적 해이를 부추긴다. (주말에 경춘선 전철을 한번 타 보라. 승객의 연령비에 아마 기겁을 하게 될 것이다.)

듣자하니 노인 전철 무임 승차 제도는 전통 시절인 1984년에 생긴 거라고 한다. 그때는 당연히 지금보다 노인 인구가 훨~씬 더 적던 시절이었고, 전철 노선 자체도 지금보다 훨~씬 더 빈약하던 시절이었다.

이 제도의 부조리와 폐해가 계속해서 논의되고 있지만, 그게 선뜻 폐지나 재조정이 못 되고 있는 이유는, 성탄절· 석탄일이 공휴일에서 선뜻 제외되지 못하고 있는 이유와 정확히 동일한 맥락에서 살펴볼 수 있다. 공휴일이 너무 많다고 맨날 징징대는 경제인 사장님들 단체들도, 감히 종교 공휴일을 건드릴 엄두는 못 내고 한글날 내지 제헌절 같은 것이나 대신 칼질을 하지 않았던가..

(사실, 10년쯤 전에 진작에 없어졌을 병역 특례 산업 기능 요원도 아직까지 그래도 명맥은 유지되고 있는 것 역시, 업계에서 온몸으로 강력하게 반발하면서 폐지를 막았기 때문이다. 중소기업은 이런 제도라도 없으면 정말로 유능한 사람을 못 뽑는다고. 재계의 목소리는 병무청이든 중앙 정부든 결코 무시 못 할 위상이긴 하다.)

본론으로 돌아오면, 물론 철도 적자의 원인을 전부 노인 무임 승차 탓으로만 돌리는 것도 좋은 진단은 아니다. 철도가 태생적으로 적자이긴 해도, 각종 광고 게시나 부동산 임대 사업을 하고 여타 각종 창의적인 사업 아이템을 생각해 내어, 승객 운임에만 지나치게 의존하지는 않는 탄탄한 재정 구조를 만드는 것이 철도 회사 경영자가 해야 할 일이다. 신문사는 구독료에 너무 의존해서는 곤란하며, 대학 역시 학생 등록금에만 너무 의존해서는 곤란하다.

그런 창의적인 일을 하는 것에는 경쟁이 필요하고 민간 사업자 유치가 필요할지도 모른다. 이런 일을 전부 정부나 정부 출자 공기업에만 맡겨서는, 철도 기관이 맨날 보조금에나 의존하는 세금 먹는 하마로 전락할 위험이 있다. 그러지 말라고 철도청이 진작부터 코레일이라는 공기업으로 바뀌었다. 하지만 수익 추구만 지나치게 강조하다 보면 철도 특유의 공공성이 훼손될 가능성도 커진다.

어느 쪽도 참 쉽지 않은 문제이다. 다만 본인이 이 글에서 얘기하고자 하는 것은, 철도 기관의 경영 수지에 대해 논하려면 오늘날 한국 철도가 처한 현실과 그 성격부터 제대로 직시할 필요가 있다는 것이다.

Posted by 사무엘

Windows라는 PC용 운영체제는 1985년에 처음 나온 이래로 많은 변화를 겪었다.

1.0 시절에 윈도우는 잘 알다시피 독자적인 실행 파일 포맷을 갖고 있긴 했지만, 완전한 운영체제가 아니라 16비트 도스 위에서 추가로 구동되는 액세서리 멀티태스킹 환경에 불과했다. 또 개발 언어가 의외로 C가 아닌 파스칼이었기 때문에, 실행 파일 내부의 각종 export/import 심볼을 보면 대소문자 구분이 없이 다 대문자였고, 문자열도 null-terminated 형태가 아니라 글자수가 앞에 찍힌 형태로 저장되어 있었다.

상업적으로 최초로 대성공을 거둔 윈도우 3.0때부터(혹은 2.x때?) C언어 형태 기반으로 API가 재정비되었으나, 이런 파스칼의 흔적은 실행 파일 포맷이라든가 함수 호출 규약 같은 데에 여전히 일부 남아 있었다. API에 하위 호환성도 잘 지켜진 편이기 때문에 1.x~2.x용 실행 파일도 내부의 리소스 데이터의 구조만 살짝 고쳐 주면 3.x에서 바로 실행 가능할 정도였다.

그랬는데 1993년에 윈도우 NT가 개발되면서 프로그램의 내부 구조가 크게 바뀌었다. 16비트에서 32비트 환경으로 갈아탔으며, 멀티스레딩+선점형 멀티태스킹이라는 게 도입되었다. 이때 실행 파일의 포맷도 NE에서 PE 방식으로 바뀌었고, 이 전통이 오늘날까지 그대로 이어져 내려오고 있다.

마이크로소프트는 동일 코드를 거의 고치지 않아고도 재컴파일만으로 16비트 바이너리와 32비트 바이너리를 동시에 만들 수 있게 많은 배려를 했다. 특히 운영체제의 API 함수는 int 크기가 4바이트가 된 것 같은 불가피한 변화를 빼면 프로토타입이 거의 바뀌지 않았다.
그럼에도 불구하고 불가피하게 프로토타입이 크게 바뀐 함수가 의외로 GDI 계층에 많이 있다. MoveToEx 함수가 그 예이다.

16비트 윈도우 시절에 이 함수는

long MoveTo(HDC, int x, int y);

처럼 정의되어 있었다. 주어진 DC가 내부적으로 기억하고 있는 그리기 기준 위치를 x, y로 옮기고, 예전의 기준 위치를 리턴값으로 돌려줬다. 그때는 좌표계의 범위가 16비트이기 때문에, 두 개의 16비트 수치를 32비트 long 정수로 합산해서 표현하는 게 괜찮은 방법이었다.

그러나 이 디자인은 32비트 환경에서는 바뀌는 게 불가피해졌다. int 개개의 값이 32비트로 커졌고 32비트 윈도우는 32비트 좌표계를 지원하기 때문이다. 16비트 숫자야 범위가 너무 좁기 때문에 16비트 컴퓨터 시절에도 느리게나마 32비트 정수를 다루는 long 같은 타입이 있었지만, 32비트 둘을 합친 64비트 정수는, 언어 차원에서 표준으로 지정된 타입이 그 당시에 없었다.

그래서 32비트 환경에서는 예전의 기준 위치를 POINT라는 별도의 구조체의 포인터에다가 되돌리는 형태로 동작 방식이 바뀌어야 했고, MoveToEx라는 함수가 추가되었다.

BOOL MoveToEx(HDC, int x, int y, POINT *pPoint);

윈도우 API에 어떤 함수의 Ex 버전이 추가되더라도 MS는 어지간하면 옛날 버전 함수도 남겨 두는 편인데, MoveTo만큼은 그렇게 하지 않았다. 원래 있던 함수는 삭제되고 새로운 함수로 대체되었기 때문에, 16비트 코드를 포팅하는 사람은 이 함수의 호출 부분을 수동으로 리팩터링을 하지 않을 수 없게 되었다. 좌표계가 어차피 16비트 범위를 넘을 일이 절대 없다는 보장이 있고 기존 16비트 코드를 빠르게 포팅해야 하는 사람이라면, 그냥 이런 wrapper 함수를 자체적으로 만들 필요가 있을 것이다.

long MoveTo(HDC hDC, int x, int y)
{
    POINT pt;
    MoveToEx(hDC, x, y, &pt);
    return MAKELONG(pt.x, pt.y);
}

오리지널 버전을 왜 살려 두지 않았냐 하면, 저런 식으로 확장해야 하는 함수가 한두 개가 아니기 때문에, 오리지널 버전을 다 살려 뒀다간 윈도우 API가 심하게 너무 지저분해지기 때문이다.

GetViewportExtEx, GetWindowExtEx, GetViewportOrgEx, GetWindowOrgEx와 이들의 Set 버전들. 오늘날의 윈도우 API에 Ex 버전만 존재하고 오리지널은 남아 있지 않은 이유가 동일하다. 16비트 시절에는 간단하게 x, y좌표를 32비트 long으로 합쳐서 되돌리던 함수였는데 그것이 32비트 윈도우에서부터는 POINT나 SIZE 구조체를 통해서 결과값을 받도록 바뀌었다.

사실, GDI라는 게 화면 픽셀만을 취급한다면 좌표계가 16비트 범위만으로도 아주 충분할 것이다. 오늘날도 화면 해상도는 끽해야 1000~2000대를 벗어나지 않기 때문이다. 그러나 GDI는 화면뿐만 아니라 프린터도 다루고, 픽셀뿐만 아니라 장치 독립적인 더욱 정밀한 단위도 취급하기 때문에 궁극적으로는 좌표계의 크기를 32비트로 확장할 필요가 있었다.

다만, 과거의 윈도우 9x는 GDI와 USER 계층의 상당수가 16비트 코드를 그대로 답습하고 있었기 때문에, API는 저렇게 32비트 형태여도 내부적으로 여전히 16비트 좌표계의 한계를 지니고 있긴 했다. 그러니 실수로 32767을 넘어가는 40000쯤 되는 좌표로 선을 그으라고 하면, 숫자가 음수로 바뀌어 인식되어 선이 오른쪽 끝이 아닌 왼쪽 끝으로 가게 되었다. 이런 보정은 응용 프로그램이 알아서 해 줘야 했다. 암울했던 시절이다.

이런 점에서 윈도우 API를 커버하는 계층인 MFC가 편한 구석이 있다. 16비트 시절이나 32비트 시절이나 CDC 클래스의 멤버 함수의 프로토타입은 CPoint MoveTo(int x, int y)로 동일하다. POINT 자료구조를 생으로 함수값으로 되돌리게 한 것은 오버헤드가 따르지만, 그냥 이식성과 개발 편의에다 더 비중을 두고 클래스를 설계한 셈이다.

그럼, 세월이 흘러 32비트에서 64비트로 넘어가는 과정에서 생긴 큰 변화는 무엇일까?
뭐니뭐니해도 GetWindowLong 함수를 예로 들 수 있다. Set 버전도 포함.
얘는 원래 주어진 윈도우에 대해서 스타일, ID, 윈도우 프로시저 주소 등 다양한 수치 정보를 얻어 오는 일종의 다형적인(polymorphic) 함수이다. 리턴값이 일반 숫자일 수도 있고 포인터나 핸들일 수도 있다.

32비트 시절에는 컴퓨터가 표현하는 숫자의 크기는 32비트로 사실상 획일화되어 있었기 때문에, 문제될 게 없었다. int나 long을 바로 포인터로 typecast하거나 그 반대로 해도 정보가 손실될 일이 없었다.
그러나 64비트에서는 이것이 큰 문제로 작용하게 되었다. 윈도우 운영체제는 int와 long은 호환성 차원에서 32비트로 그대로 유지하고,포인터와 핸들만 64비트로 키우는 정책을 선택했기 때문이다.

그래서 개발자의 편의를 위해 비주얼 닷넷쯤의 플랫폼 SDK에서는 잘 알다시피 INT_PTR처럼 _PTR이라는 자료형 typedef가 추가되었다. 포인터의 크기와 같은 정수형이라는 보장이 있는 정수형을 따로 구분해서 표현하기 위해서이다. 윈도우 API도 원래는 GetWindowLong 하나만 있었는데 GetWindowLongPtr이라는 명칭이 추가되었다. 이것이 32비트 환경에서는 그냥 GetWindowLong로 도로 치환되는 매크로에 불과하지만, 64비트에서는 Ptr 버전만이 운영체제의 user32.dll에 실제로 존재하는 함수이다.

다시 말해, 32비트에서는 기존 Long과 새로운 LongPtr 버전을 둘 다 쓸 수 있고 LongPtr이 내부적으로는 Long으로 도로 바뀌어 처리되는 반면, 64비트에서는 LongPtr만 써야 하고 Long을 쓰면 에러가 난다.

이 함수가 받는 매개변수도 32비트 범위로 충분한 GWL_STYLE, GWL_ID 같은 상수는 바뀐 게 없는데, 포인터와 크기가 같은 윈도우 프로시저나 인스턴스 핸들 같은 걸 지정할 때는 GWL_*말고 GWLP_*라는 명칭이 새로 추가되었다. 둘은 의미하는 값도 차이가 없는데 왜 이런 조치를 취한 것일까?

이는 단순히 프로그래머의 편의를 위해서이다.

int n = (int)GetWindowLong(hWnd, GWL_WNDPROC);

64비트에 환경에서는 윈도우 프로시저의 크기 (8바이트)가 int의 크기(4바이트)보다 더 크기 때문에, 이런 식으로 32비트 관행을 전제를 하고 작성된 코드는 64비트 환경에서 아예 컴파일이 되지 않게 하기 위해서이다.

INT_PTR n = (INT_PTR)GetWindowLongPtr(hWnd, GWLP_WNDPROC);

이렇게 짜 주면 32비트와 64비트에서 모두 안전하게 잘 동작하는 코드가 된다.

memory mapped file을 만드는 CreateFileMapping이나 MapViewOfFile 함수는 메모리의 크기를 64비트 범위로 잡을 수 있어서 그 값을 32비트 기계에서 처리하기 편하게끔 두 개의 32비트 숫자로 쪼개서 받아들인다. 64비트 윈도우에서는 굳이 그렇게 할 필요가 없지만 함수의 프로토타입이 바뀌지 않았다. 어차피 64비트 윈도우라고 해서 당장 4GB를 능가하는 어마어마한 양의 메모리를 한 번에 잡는 일은 실제로 거의 없기 때문이다.

GlobalAlloc, VirtualAlloc, HeapAlloc 같은 메모리 할당 함수들은 메모리의 양을 잡는 숫자의 자료형이 SIZE_T이다. 즉, 32비트 환경에서는 32비트, 64비트 환경에서는 64비트로 결정된다는 뜻. SIZE_T는 UINT_PTR과 의미상 사실상 동급인 셈이다.
하지만 파일을 읽고 쓰는 ReadFile와 WriteFile은 정보를 전송하는 단위가 SIZE_T도 아니고 그냥 DWORD(32비트)로 고정되어 있다.

다만, 32비트 환경에서라도 32비트 크기의 범위를 능가하는 방대한 파일을 취급해야 할 일이 있기 때문에 파일의 크기를 얻거나(GetFileSize), 파일의 특정 지점을 탐색하는(SetFilePointer) 함수는 역시 32비트 필드를 두 개 받아서 64비트 숫자를 전달할 수 있게 되어 있다. 윈도우 2000부터는 숫자를 32비트 단위로 쪼갤 필요 없이 64비트 숫자를 한 번에 전달받는 Ex 함수가 운영체제 차원에서 추가되었다.

MFC는 운영체제에 그런 Ex 함수가 추가되기 전부터 CFile::Seek나 CFile::GetLength는 언제나 64비트 정수를 다뤄 왔으니 속 편한 경우라 하겠다.

GlobalMemoryStatus 함수는 현재 컴퓨터의 전체 메모리 양과 남은 메모리 양을 되돌리는 함수인데, 램 용량이 4GB를 넘어서는 날이 올 거라고 과거에 상상이 가능했을까. 구조체의 각 멤버가 32비트 크기로 고정되어 있다가 이것이 64비트로 확장된 Ex 함수가 역시 윈도우 2000 때부터 추가되었다. 64비트 운영체제에서는 오리지널 함수를 없애 버려도 될 법도 해 보이는데 이건 오리지널과 Ex가 여전히 남아 있다.

16비트 시절에는 윈도우 메시지와 함께 전달된 두 개의 부가 정보 중 WPARAM은 16비트이고 LPARAM은 32비트 크기였다. 그러던 것이 32비트 환경에서는 둘 다 32비트가 되었다. 16비트와 같은 사고방식이라면 64비트 환경에서는 WPARAM은 32비트이고 LPARAM만 64비트로 승격해도 될 것 같으나 그렇지 않다. 둘 다 64비트이다.

machine word보다 더 작은 크기로 정보를 제한해서 담을 필요가 전혀 없을 뿐더러, 이미 32비트 시절에 WPARAM과 LPARAM을 구분하지 않고 포인터와 핸들을 담는 관행이 10년 넘게 지속되었을 텐데 다시 그 구분을 넣는다는 건 불가능한 지경이 되었기 때문이다.

한 플랫폼에서만 10년 넘게 프로그래밍을 하니까 이제는 그 API를 처음에 설계한 사람의 마음을 읽고 시대에 따른 변천사를 이해하는 경지에 도달하는 걸 느낀다. ^^

Posted by 사무엘

화상이 얼마나 고통스러운지, 그리고 불에 타 죽는 게 얼마나 고통스러운 죽음인지는 모르는 사람이 없을 것이다.
그래서 역사적으로 불은 사람에게 공포를 주고 대중을 통제하는 수단으로 잘 쓰이곤 했다.

작게는 담뱃불, 크게는 다리미나 인두로 생살을 지지는 것은 고문 방법으로 통용되어 왔다.
그리고 중세에는 화형이란 게 있어서 반역자나 종교적 이단 같은 죄질이 굉장히 나쁜 죄인은 이 방법으로 처형했다.

동양의 조선이나 중국은 거열형이나 능지처참 같은 다른 끔찍한 형벌이 있을지언정, 화형은 없었나 보다. 그래서 화형 하면 일단 중세 유럽이 떠오른다.
게다가 그 당시는 지금처럼 불에 활활 잘 타는 천연 가스나 석유· 석탄이 개발되어 쓰이기 전이었음을 생각해 보자. 그러니 사형수를 완전히 확 불태우는 게 쉽지 않은 일이었으며, 집행 시간은 길었고 그만큼 사형수의 고통도 더했다.

근현대에 와서는 먹고 살 만해지고 인권(?) 의식이 향상되면서 그런 잔인한 형벌은 사라졌다. 그러나 사회 구조가 막장인 곳에서는 열사의 길을 가기 위해 분신 자살이라는 엄청난 방법을 선택한 사람이 이따금씩 나오곤 했다.

우리나라는 대표적인 예로 전 태일이 있다(1948-1970).
노동청에 탄원서를 보내고 대통령 면담을 요청하는 등, 노동자의 권익 보호를 위해서 합법적으로 할 수 있는 일은 다 해 봤지만 바뀌는 게 전혀 없으니,
이놈의 있으나마나한 근로기준법에 사망 선고를 내리자는 차원에서 자기 몸에다 기름을 끼얹은 뒤 불을 지르고 만 것이다.

난 어렸을 땐 우리 민족은 6· 25 폐허에서 한강의 기적을 이룩해 냈다고까지만 배웠는데, 그 과정에서 이런 희생자도 있었다는 걸 나중에 알게 됐을 때, 적지 않은 충격을 받았다.

세계적으로 분신 자살/자결의 예로 가장 유명한 사건은, 틱 광둑이라는 환갑이 넘은 베트남의 어느 불교 승려의 죽음이다.
그는 남베트남의 부패 독재 정권(응고 딘디엠 대통령)의 학정을 세계에 알리고 이에 항거하는 뜻을 전하고자 1963년 5월 29일, 수백 명의 불자들에게 둘러싸인 가운데 가부좌를 하고 앉아서 휘발유 화염에 휩싸였다.

아니, 불교에는 대의를 명분으로 하는 이런 행위에 대해서 '소신공양'(燒身供養)이라고 용어가 따로 있다고 한다.
에밀레종 같은 얘기만 있는 줄 알았는데 그게 아니다. 하긴, 한국인에게는 김 동리의 소설 <등신불>을 통해 이 개념이 비교적 널리 소개되기도 했다.

세상에 사람이 라이브로 불에 타 죽는 장면은 영화로도 보기가 쉽지 않다. 그런데 틱 광둑 스님의 충격적인 자결 장면은 처음부터 끝까지 동영상과 정지 사진으로 촬영되어 전세계에 알려졌다. 이것이 국제 사회에 경종을 울리고 독재 정권의 명을 재촉했음은 물론이다.
동영상을 보면 알 수 있듯, 그는 죽는 마지막 순간까지도 고통에 울부짖거나 바둥대지 않았고 꼿꼿하게 책상다리 차림으로 앉아 있었다. 절명해서 몸에 힘이 완전히 빠진 뒤에야 뒤로 벌렁 넘어갔다.

지금으로부터 무려 반세기 가까이 전인 1963년의 일인데 동영상이 컬러로 남아 있고 오히려 정지 사진은 흑백이다.
동영상 (1:34 지점부터 불이 확! 2:21에 시신이 쓰러짐)
정지 사진
비위가 약하신 분은 열람 금지.

동영상은 멀리서 찍은 것이고 활활 타는 불밖에 안 보이는 반면, 정지 사진은 고인의 모습을 비교적 가까이서 여러 장 찍은 듯하다.

처음에 밝은 색 계열이던 승복이 시간이 흐르면서 새까맣게 탔다.
화마가 얼굴 피부까지 검붉게 할퀸 모습은, 흑백이 아닌 컬러 사진이라면 훨씬 더 참혹하고 끔찍한 장면이었을 것이다.
안면 화상을 입은 이 지선 씨 모습만 해도 얼마나 끔찍했던가?

응고 딘디엠 정권은 막장이었을 뿐만 아니라 불교를 대놓고 탄압까지 했다. 뭐 그렇다고, 시대가 20세기인데 멀쩡한 불자들을 잡아 죽인다거나 한 건 아니고, 사찰을 파괴하고 석가탄신일을 금지하는 등 불교를 제도적으로 디스하고 불이익을 준 정도이다.

그런데 여기서 굉장히 이상한 점이 있는데, 응고 딘디엠은 독실한 가톨릭 신자였다는 점이다! 정부 관료들도 전부 가톨릭 신자만 등용했다.
분명히 말하지만 개신교 계열이 절대 아니다. 그런데 불교를 탄압했다고라...
응고 딘디엠의 아내, 즉 베트남의 영부인이라는 사람은 틱 광둑 스님의 죽음을 보고는 아예 “바베큐 파티”라고 천하의 개쌍놈급의 개드립을 공공연히 치기도 했다.

난 정말 이상함을 느꼈다.
우리나라는 가톨릭과 불교가 얼마나 사이가 좋은가?
성탄절과 석가탄신일 때 천주교계와 불교계가 서로 축하해 주는 건 뭐 관행으로 정착한 지 오래이다.
그러면서 천주교는 타 종교에 대해서 관용과 화합 잘 한다고 폭풍 칭송을 받고 있는 반면에, 우리나라에서는 개독 먹사들이 담대하게 복음 전한 것도 아니고 타 종교인들에게 무례한 무개념 병크 저질러서 간증 상실하고 욕 바가지로 얻어먹고 있지 않은가?

물론 가톨릭의 전략을 아는 사람에게야 이런 차이가 그리 새삼스럽지 않을 것이다. 그들은 각 국가와 문화에 따라서 자신이 약자일 때나 경쟁자와 아직 동급일 때 취하는 전략이 다르고, 마침내 그들이 진짜 주류가 되고 정치· 종교적 갑이 되었을 때 시행하는 전략이 또 완전히 다르다. 섬뜩할 정도로 다르다. 우리가 역사를 통해 뭔가를 배우고자 한다면, 이런 패턴을 배워야 할 것이다.

기독교는 교회 역사상 순교자가 셀 수 없이 많이 나왔으며, <폭스의 순교사> 같은 책을 보면 '흠좀무'라는 말밖에 안 나오는 사례들이 많이 기록되어 있다. 특히 (겉보기로) 아무 고통 없이 화형 당한 사람 얘기가 나온다. 토머스 헉스(Thomas Haukes)라는 사람은 1555년, 피의 메리 시절에 유아 세례 반대라는 죄목으로 화형을 당해 순교했는데, 불에 타 죽는 고통이 견딜 만하면 위로 손을 뻗어 손뼉을 치고 죽을 테니 손은 묶지 말라고 말했다. 그리고 그는 진짜로 손뼉을 세 번 친 뒤 숨을 거뒀다고 한다.
그런데 이런 사건 자체는 기독교에만 있는 사건이 아닌 것 같다. 불에 타 죽는 고통조차도 인간의 극한의 정신력으로 극복할 수 있는 것인지 신기한 일이다.

틱 광둑에 이어, 우리나라에서는 지난 2010년, 문수 스님이라는 노승이 이 명박 정권을 정면으로 비판하고 4대강 사업의 전면 중단을 촉구하면서 소신공양으로 생을 마감했다. <민중의 소리> 같은 진보 성향 언론에서는 진짜 문자 그대로 새까만 숯덩이가 되어 버린 고인의 시신까지 사진으로 공개했다. 이것 역시 비위가 약한 분은 클릭 금지.

그런 사람들이 인간적으로야 정말 숭고한 뜻으로 자기 목숨을 그렇게 비장하게 초개처럼 버렸을 수는 있다. 허나 인간의 의로 참 하나님의 절대적인 의의 기준을 통과할 수 없다는 것은 실로 애석한 일이 아닐 수 없다.
사람의 육신의 몸이 불타면서 느끼는 고통은 정말 끔찍하긴 해도 그래도 길어야 수 분이 채 안 되어 끝이겠지만, 그 동일한 고통을 죽음으로 종결지을 수조차도 없이 영원무궁토록 겪어야 하는 '그곳'에 또 가게 된다면 얼마나 안타까울까??

마가복음 9장 끝부분에 기록된 “거기는 그들의 벌레도 죽지 않고 불도 꺼지지 않느니라” 3콤보의 경고를 이 시간에 되새기도록 하자. 이것이 하나님으로부터 진짜로 정죄받은 죄인의 최후인 것이다. (단, 3콤보는 KJV에만 있음)

이런 얘기를 접하노라면, 이와는 반대로, 맹렬히 불이 붙었는데도 재가 되지 않고 멀쩡히 살아있는 떨기나무(출 3:2-3)가 얼마나 대단한 기적인지 실감하게 된다. 또한, 평소보다 연료와 공기를 7배나 더 공급해서 달궈진 맹렬한 용광로 불길로부터 멀쩡히 살아서 돌아온 다니엘의 세 친구들 이야기가 얼마나 경이로운지도 또 실감하게 된다. 하나님은 불을 만드신 분이고, 연소라고 불리는 급격한 화학적 산화 현상을 제어하여 예외로 적용할 능력도 응당 갖추고 계시기 때문이다.

성경에 따르면 결박만 없어졌을 뿐 그들은 머리털 하나도 상하지 않았고 옷도 전혀 타지 않았다고 기록되어 있다(단 3:27). 오히려 그들을 용광로에 집어넣으려던 병사가 허둥대다가 불에 타 죽었다. 그러나 용광로에서는 하나님의 아들, 곧 성육신 전의 예수님이 그들을 미리 기다리고 있다 맞이했다니 얼마나 경이로웠을까? (세 명이 아니라 네 사람이 용광로에 있었다. 단 3:25) 그들은 왕이 부르기 전까지는 오히려 용광로에서 나가고 싶지 않았을 것이다.

물론, 하나님께서 인류 역사상 수많은 순교자들 중에 다니엘의 세 친구들에게만 예외적으로 기적을 허락해 준 것은 하나님의 경륜상의 특별한 이유 때문이었을 것이다. 게다가 그들은 하나님께서 설령 자기를 불에서 구해내지 않고 죽게 허락할지라도 그래도 느부갓네살 왕의 형상에는 절을 하지 않겠다고, 한 치의 타협도 하지 않고 순교를 불사할 생각으로 단호하게 자기 신앙을 “먼저” 지켰다는 것을 우리는 명심할 필요가 있다. (단 3:17-18) “그리 아니하실지라도”라는 찬양의 의미를 생각해 보자.

지금까지 불, 화상, 화형, 분신자살, 순교 등 여러 섬뜩한 주제로 어찌 보면 두서없을 수도 있는 형태로 얘기가 나왔다.
글을 쓰면서 더욱 느꼈는데, 나는 인간의 알량한 의를 내세우지 않는 나의 종교, 아니 나의 신앙이 좋다. 복음이라는 말이 괜히 나온 게 아니다.

성경의 하나님은 그 아무리 큰 죄를 짓고 그 어떤 급으로 하나님이나 교회, 기독교의 명예를 실추시켰다 하더라도 진심어린 눈물의 회개만 하면 다 용서하고, 생명이 붙어 있는 한 사람을 다시 사용해 주신다. 그래서 베드로의 예수님 부인과 회개 장면이 더욱 드라마틱하게 읽히는 것이다.

성경에는 너희(크리스천) 몸을 하나님께 살아 있는 희생물로 드리라는 권면이 분명히 기록되어 있지만(롬 12:1) 그건 무슨 신앙의 자유를 위해 세상 정부를 상대로 투쟁하고 시위대의 불화살이 되거나, 명예 회복을 위해 할복을 하라는 소리가 절~대로 아니다. 너도 십자가형 체험을 일부러 해 보라는 소리도 결코 아니다. 남이 먼저 날 죽여서 순교를 하면 했지, 기독교는 그 어떤 명분이라도 자해나 자결 같은 열사의 길을 권장하지 않는다. 그런 식으로 티를 내 봤자 우리 의가 설마 예수님의 의를 능가하겠는가?

기독교가 세상의 여느 시민 단체, NGO 단체와 다를 바가 없다면, 매 예배 때마다 아마 순교선열들에 대한 묵념도 하고, 각종 유명한 순교자들의 동상도 세워서 떠받들고 숭배하는 게 정상일 것이다. 그래서 천주교에서 하는 게 딱 이러한 발상에서 비롯된 성인 시성과 성인 숭배이다. 수많은 크리스천들을 잡아 죽인 종교이지만, 자기네들이 내세우는  자기네 순교자도 없는 건 아니어서..=_=;; 그러나 성경을 믿는 기독교는 애시당초 그렇게 사람을 떠받들지 않으며, 그건 다 이유가 있기 때문이다.

기독교는 죄 때문에 인간이 정말로 죽어야 할 때도 동물을 대신 피 흘려 죽게 해 주고, 나중에는 하나님께서 직접 성육신하여 인간에게 죽임을 당했다고 가르친다. 심청전에도 나오는 인신 공양 같은 게 절대로 없다. 다른 종교와는 차원이 다르다. 구약 성경에서 하나님께서 이스라엘 백성에게 이방 민족들을 전부 죽이고 흔적도 남기지 말고 파괴하고 멸하라는 잔인한 명령을 왜 내렸는지 아는가? 이 방법이 아니면 이방 민족들의 그런 악한 관행들을 뿌리뽑을 수가 없어서였다!

아무쪼록 육신의 장막을 벗고 사망도, 슬픔도, 고통도, 울부짖음도 없는(계 21:4) 세상이 올 것을 염원해 본다. 여기에는 불에 의한 사망, 고통, 울부짖음도 당연히 포함되어 있다. 불 및 불과 관련된 일련의 사건들을 생각하면서도 많은 사람들이 구원의 길을 다시 생각하고 예수님께로 돌아오면 좋겠다.

NOTE:

'스님'은 님짜 때문에 높임의 뜻이 들어가기 때문에, 공식적인 글에서는 '승려' 정도가 적절하다는 지적이 있다. 그에 대해서 나는 좀 회의적이다. 그런 식의 논리이면 '장님'도 분명히 높임말이다. 그런데도 그건 또 정서적으로 받아들여지지 않아서 성경에 나오는 장님이나 소경도 요즘은 다 그냥 '맹인'이나 심지어 시각 장애인으로 바뀌는 추세이다.

님짜를 뗀 '스'는 말이 되지 않으며, '장'도 마찬가지이다. 심지어 '하나님'도 님짜를 떼면 말이 되지 않는다. 본인은 그런 단어들은 단어 전체를 한 형태소로 보며, 그렇게 의도적인 존칭이 들어가 있다고 생각하지 않는다. 이 점을 염두에 두고 본문에서 '스님'이라는 단어를 사용하였음을 밝힌다.

그 반면에 '예수님' 다음의 님짜는 명백하게 존칭어미이다. 그래서 우리끼리는 글 쓸 때 예수님이라고 하지만 다른 불신자들은 그냥 예수라고만 부른다.

Posted by 사무엘

과거에 항공 교통이 지금처럼 거대해지기 전에는, 철도 간이역처럼 자그마한 건물에다 활주로랍시고 잔디밭 공터만 덩그러니 있는 시설에서 비행기가 뜨고 내린 적이 있었다. 그러나 오늘날은 여객용 공항 대접을 받으려면 첨단 관제 시설과, 튼튼하게 포장된 활주로, 편의 시설을 갖춘 여객 터미널과 주변 보안 시설 등이 필수이다.

크기뿐만이 아니라 공항의 특성을 분류하는 속성(property; attribute)들로는 당장 다음과 같은 것을 떠올릴 수 있다.

1. 국제 공항인가?

국제 공항은 일반적으로 국내선 비행기보다 더 큰 여객기를 취급할 수 있어야 하고, 세관이나 검역 (그리고 면세점) 같은 추가 시설이 있어야 한다. 국제 공항 내부의 면세 구역은 국제법상으로 나름 치외법권 지대이다.
대구에 있는 공항은 대구 국제 공항이지만, 포항이나 울산에 있는 공항은 국제 공항이 아니다.

2. 24시간 운항 가능한가?

비행기는 움직이면서 주변에 끼치는 소음 공해가 장난이 아니다. 그렇기 때문에 주거지로부터 충분히 멀리 떨어져 있지 못한 공항은 민폐를 끼치지 않기 위해 심야 시간대에는 비행기 취급을 금지하는 curfew가 시행된다.

멀찍한 영종도에 건설된 인천 공항은 24시간 운항 가능하고 청주 공항도 마찬가지이다. 그러나 김포나 제주 공항은 그렇지 않음. 그래서 밤에 김포 공항으로 날아가는 비행기가 만약 지연크리를 먹게 되면, 부득이 김포 공항에 못 내리고 인천 공항에 착륙하는 경우가 생긴다. 사실, 국제 허브 공항 역할을 하는 데는 운행 시간대의 제약이 없이 24시간 운항 가능한 공항이 좋을 것이다.

3. 대표하는 지역과 일치하는 지명으로 불리는가?

대도시의 유명 공항은 의외로 해당 도시의 이름으로 불리지는 않는 경우가 있다. 인천(서울), 김포(서울), 김해(부산) 등. 일본 도쿄(하네다/나리타), 미국 뉴욕(케네디), 영국 런던(히드로)을 대표하는 간판급 공항도 지역 이름이 공항 이름이지는 않다. 그러나 역시 미국의 대도시인 LA의 공항은 그대로 LA 국제 공항. 명칭은 말 그대로 케바케인 셈이다.
우리나라는 김포 공항은 김포에 있지 않고 서울에 있는데, 서울 공항은 서울이 아닌 성남에 있다. 좀 웃기지 않은지?

4. 군사 비중은?

요즘 철도역이나 버스 터미널은 백화점 내지 영화관 같은 상업 시설과 결합한 민자 형태로 건설되는 경우가 많으며, 김포 공항도 청사 하나가 완전한 상업 단지로 개조되면서 그런 유행을 많이 받아들였다. 그러나 공항은 마냥 민간 상업 시설로만 쓰기에는 군사적인 역할이 차지하는 비중도 무척 크다.

한국의 대표적인 간판 공항인 김포와 인천 공항은 100% 민간 공항이다. 그렇기 때문에 인터넷 지도로 항공 사진을 봐도 활주로의 모습까지 모두 공개되어 있다. 그러나 우리나라에 100% 민간 공항은 흔치 않다. 김포와 인천 말고는 울산, 여수, 양양 정도가 고작.

그래서 당장 김해나 제주 공항에만 가도 인근의 군사 시설 때문에 경비가 서울의 공항들보다 훨씬 더 삼엄하며 공항 주변에 사진 촬영도 함부로 못 한다. 민· 군 겸용 공항인 것이다. 그래서 인터넷 지도를 보면 이런 공항들은 김포· 인천과는 달리, 활주로가 흐리게 처리되었거나 공항 부지가 아예 풀숲· 논밭으로 대체된 것을 볼 수 있다. 포항, 대구, 청주, 원주 공항들이 모두 마찬가지이다. 다 이유가 있어서 그렇게 된 것임.

민간 여객기를 전혀 취급하지 않고 공군이 전투기를 띄울 때만 사용하는 100% 군용 공항은 대체로 그냥 비행장이라 불린다. 하지만 군용 공항 중에서 성남의 서울 공항은 국빈 방문 때도 사용되고, 에어쇼 할 때 민간인 접근을 허용하기도 하는 예외적인 경우이다. 사실, 유사시에 만약 김포와 인천 공항이 마비된다면 수도권에 있는 이 공항과 국토의 중앙에 있는 청주 공항이 대체 공항 역할을 하게 될 것이다.

군대, 보안 하니까 생각나는 분석인데 말이다. 고정익 항공기를 띄우는 공항은 하늘 위가 뻥 뚫린 방대한 면적의 활주로가 필요하다는 이유로 인해, 은폐가 사실상 불가능하다. 핵무기 연구야 지하 실험실에서 몰래 한다 하더라도, 비행기는 역학 특성상 지하에다가 활주로를 만들어서 거기서 비행기를 불쑥 띄울 수는 없는 노릇이지 않은가. 그리고 활주로가 또 좀 기냐? 그러니 인공위성 사진에 공항은 어지간하면 다 노출이 된다.

요즘 버스 터미널은 상업 시설과 결합하여 정작 버스 탑승은 지하에서 하기 때문에 밖에서 보면 버스 터미널이라는 티도 안 나는 경우가 있다. 성남 버스 터미널이 좋은 예임. 철도도 그렇다. 광명 역은 KTX가 서는 역 중에 지상에서 역의 앞뒤로 레일이 전혀 안 보이는 유일한 역이다.
하지만 공항은 항구만큼이나 그런 티가 안 나게 만들어지지는 못할 듯하다. (원주 공항은 여객 터미널과 활주로가 서로 멀리 떨어져 있는 경우임)

Posted by 사무엘

주기적으로 또 철도(+성경) 드립을 좀 칠 때가 됐다.

1. 나 자신이 하나님 앞에서 죄인임을 시인하고, 예수님의 죽으심과 부활이 진정 나를 위한 것이었음을 믿고 그분을 나의 개인적인 구주로 받아들인 사람이 곧 구원받은 사람이다.
그것처럼 경부선, 중앙선 등 한국의 모든 철도가 진정 나를 위한 것임을 인지하고, 철도 규격 및 건설 역사 같은 얘기를 듣기만 해도 마치 내 일처럼 감격과 기쁨과 행복을 느끼는 사람이 바로 철도 성령으로 충만한 사람이다.

2. 내가 확신하노니 사망이나 생명이나 천사들이나 정사들이나 권능들이나 현재 있는 것들이나 장래 있을 것들이나 높음이나 깊음이나 다른 어떤 창조물이라도 능히 우리를 새마을호 안에 있는 한국 철도의 사랑에서 떼어 놓지 못하리라.

3. 내가 또한 받은 것을 무엇보다 먼저 너희에게 전하였노니 그것은 곧 문헌 기록대로 대한민국에 새마을호 열차가 1974년부터 운행되었으며 1987년부터는 전후동력형 디젤 동차가 투입되었고 2002년부터 2007년 사이에는 시발역 출발 전과 종착역 도착 직전에 Looking for you가 흘러나왔다는 것이라.

참으로 철도는 모든 것이 사랑스럽도다. (yea, the railroad is altogether lovely 아 5:16 참고)
2와 3도 성경 구절 패러디인데, 원래 구절이 뭔지 궁금하신 분은 알아서 찾아 보시라. ㅋ

4. “마이크로소프트 UX팀의 이사 샘 모라우가 밝힌 바에 따르면, 메트로 UI는 지하철이 지나가는 모습에서 영감을 얻어 탄생한 UI라고 한다. 이름부터 ‘Metro(지하철)’다.”
그래서 메트로이구나! 오 역시나 윈도우 8을 개발하는 과정에서 철도 성령이 MS에게도 임한 게 분명하다!!

세월이 흐르면서 그리스도인이 구원에서 성화로, 내가 아닌 남을 생각하고 남의 믿음을 세워 주는 단계로 신앙이 성숙하듯, 철도와 본인과의 개인적인 교제도 더욱 친밀해지고 있다.

하긴, 유니클락 배경 음악을 들으면서도 난 이런 생각이 바로 들었다.
“이 곡 템포는 정확하게 ♩=120 이겠구나!” (왜 그런지 화면 보호기+음악 시청하면서 생각해 보셈)

어떤 음악이든 앞부분 몇 초를 들으면 조와 템포와 박자부터 먼저 귀에 들어오고 악보가 떠오른 경지에 도달하게 된 것도 철도 덕분이다. Looking for you를 3천 번 들으면서 채보를 해 보면 누구나 저렇게 될 수 있다. 이건 전적으로 집념과 노력의 결과이지 선천적인 재능이 아니다.
철도님, 사랑합니다.

Posted by 사무엘

굳이 전산학이나 컴퓨터과학· 공학의 전공자가 아니어도, 그리고 현업 프로그래머가 아니더라도 조금만 기계 다루는 것에 조예가 있는 컴덕후라면 요즘 컴퓨터의 발전 추세가 어떤지는 다들 알 것이다. 사실은 <날개셋> 한글 입력기의 개발자인 본인보다도 더 잘 알 것이다.

튜링 완전하며 메모리로부터 프로그램을 읽어 와서 구동하는(프로그램 내장 방식) 범용 컴퓨터가 발명된 지가 아직 100년은커녕 반세기 남짓밖에 지나지 않았다. 그러나 컴퓨터의 속도와 메모리 용량은 가히 넘사벽급으로 발달했다. 컴퓨터는 지난 수십 년 동안 자연이 아니라 인간의 발명한 물건의 내부에서, 시간에 따른 지수함수 스케일의 발전을 볼 수 있던 얼마 안 되는 엄청난 분야였다.

그러나 그것도 한계는 있어서 컴퓨터 성능의 대표적인 지표이던 클럭 속도가 2003년 즈음에 놀랍게도 지수함수적인 성장이 멈췄다. 10년까지는 아닌 거 같다만 8, 9년 전의 PC나 지금의 PC나 다 3GHz대이다. 오늘날과 같은 반도체 회로라는 근본적인 패러다임이 바뀌지 않는 한, 전력 소모와 발열 때문에 컴퓨터의 기본 동작 자체만의 속도가 더 빨라질 수는 없다.

우리가 다루는 컴퓨터는 생각보다 굉장히 정밀하고 빡세게 만들어져 있다. 예전부터 파이프라인, pre-fetching 등 온갖 있는 테크닉, 없는 꼼수를 다 동원해서, 어떻게든 낭비되는 자원이 없이 모든 자원이 계산에 동원되고, 1ms라도 속도를 더 올리려고 공돌이들의 온갖 공밀레 연구가 동원되었다. 이런 수직적인 성장이 한계에 달하니 요즘 컴퓨터는 코어 수를 늘려서 분업이라는 수평적인 성장을 추구하고 있다.

100이라는 일이 있어서 이게 2GHz짜리 컴으로 다 처리하는 데 10이라는 시간이 걸린다면, 1GHz짜리 컴으로는 20만큼의 시간이 걸릴 것이다. 그러나 1GHz 짜리 컴이 2개 있어서 그 일을 정확히 50씩 분담할 수 있다면, 각각의 컴퓨터의 최대 속도는 비록 1GHz밖에 안 되더라도 10에 가까운 시간 만에 일을 끝마칠 수 있어서 2GHz에 준하는 효과를 낼 수 있다. 이것이 기본적인 아이디어이다.

물론, 딱 10으로 줄이지는 못한다. 일을 분할하고 두 대의 컴퓨터를 세팅하고 굴린 후, 두 컴퓨터(코어)가 내놓은 결과를 취합하는 오버헤드가 역시 결코 작지 않기 때문이다. 그리고 세상에 상호 의존성이 없이 역할을 저렇게 딱 분담할 수 있는 작업이란 흔치 않다.

방대한 계산이 필요한 작업을 다수의 컴퓨터 기계들을 여러 대 동원해서 수행하는 건, 분산 컴퓨팅이라 하여 예전부터 그리 생소한 개념이 아니었다. 3D 그래픽으로 영화를 만드는 업계에서는 rendering farm이라 하여 수많은 컴퓨터들을 농장에다 비유할 정도로 열나게 굴려서 영상을 만들어 낸다. 빌드 속도가 느린 걸로 악명 높은 C++ 언어를 위해서 Incredibuild라는 이스라엘산 분산 빌드 시스템도 있다.

그런 것처럼 개개의 컴퓨터도 이제 코어가 여러 개 돌아가고 멀티스레딩 능력이 충분히 뛰어나니, 이제는 프로그램 차원에서 멀티코어-aware한 개발이 필요해졌다. 왜냐하면 분산 처리 시스템을 설계하는 건 정말 머리가 뽀개질 정도로 복잡하기 때문에 컴퓨터나 컴파일러가 자동화를 해 줄 수 없다. 예전 계산 결과에 의존적인 다음 계산을 병렬로 동시 수행시킬 수는 없는 노릇이니까 말이다.

그렇기 때문에 멀티코어-aware하지 않은 옛날 프로그램은 컴퓨터가 언제나 최악의 case로 가정하고 보수적으로 돌려서 코어를 하나만 할당하여 돌아가게 된다. 한 프로그램이 while(1); 만 하고 가만히 있다 해도 CPU 사용률이 100%로 치솟지 않는다.

특히 C/C++의 포인터는 그야말로 아무 메모리 주소나 가리킬 수 있고, *a, *b가 있으면 둘이 가리키는 주소가 같을지 아닐지 등 최적화나 병렬화를 할 여지가 없을 정도로 너무 generic하기 때문에 오히려 처리가 어렵다고 한다. 파스칼이나 포트란처럼 언어 표현력이 C/C++보다 부족한 대신에 컴파일러가 소스 코드만 보고서 그 복잡도를 어느 정도 파악할 수 있는 언어가 병렬화에는 오히려 더 유리하다고.

그래서 소스 코드의 특정 구간에 대해서 컴파일러나 CPU가 안심하고 병렬화를 할 수 있게 중간 중간에 부가정보를 인위적으로 넣어 줄 필요가 생겼는데, 이런 부가정보를 기술하는 표준 규격 중 하나가 그 이름도 유명한 OpenMP이다. #pragma omp 같은 컴파일러 지시자도 있고, OpenMP 라이브러리보부터 호출해서 쓰는 함수도 있다.

옛날에 C언어가 처음 발명되던 시절엔 최적화를 위해서 변수를 가능한 한 레지스터에 올려라고 지시하던 register라는 카워드가 있었는데, 앞으로 C/C++ 같은 네이티브 코드 언어는 멀티코어를 언어 차원에서 수용하는 규격이 덩달아 생겨야 할 것이다.

물론, CreateThread 같은 함수를 써서 코드의 로직 차원에서 대놓고 여러 작업 스레드를 만들었다면, 단일 프로세스가 여러 개의 코어를 자연스럽게 점유하는 게 응당 가능하다. 그러나 디자인의 성격상, 멀티스레딩은 보통 일하는 스레드, 사용자 UI 스레드, 입출력 신호를 기다리는 스레드처럼 용도별로 달리 배당하는 게 바람직하지, 동일한 일을 하는 코드 내부에서 굳이 다중 코어 활용을 위해 스레드를 분할하기에는 동기화를 비롯해 일이 너무 복잡해진다. 서버 같은 게 아니라면, 제각기 CPU를 full로 사용하는 여러 작업 스레드를 만들 일 자체가 매우 드물다.

이때 멀티코어 프로그래밍을 잘 하면 이런 단일 코드가 명시적인 스레드 생성을 하지 않고도 CPU의 자원을 골고루 전부 활용해서 고성능으로 돌아가게 된다. 다만 앞서 말했듯이 이렇게 작업을 분할하는 오버헤드부터가 큰 편이기 때문에, 소규모 작업보다는 동영상 인코딩이나 대용량 파일 압축이나 컴파일 같은 진짜 방대한 작업에서 멀티코어의 진가는 더욱 두드러질 것이다.
일례로, 비주얼 C++은 2005부터 빌드할 때 병렬 컴파일이 수행된 경우, 빌드 로그에 해당 빌드를 수행한 코어의 번호가 뜬다.

O(n^3)짜리 행렬 곱셈은 워낙 단순 무식하고 복잡한 의존도 따위도 없는 순수 노가다이다 보니, “나 병렬화 해 주세요”라고 온몸으로 외치는 문제라고 볼 수 있다. 퀵 정렬이나 병합 정렬처럼 구간이 딱딱 나뉘는 알고리즘이 병렬화에도 적합한 구조일 것 같긴 하다만, 요즘 컴퓨터의 성능이라면 겨우 internal sort 규모의 정렬 작업은 굳이 멀티코어를 쓸 필요도 없을 정도로 금방 끝날 듯.

요컨대 이제는 고성능 컴퓨터를 쓰는 것만으로 프로그램의 수행 속도가 저절로 올라가는 시대는 끝났다. 그 다음으로 레지스터 배당이라든가 캐시나 파이프라인 적중률 같은 건 CPU 설계에 맞춰 컴파일러가 더 똑똑해야 하는 영역인데, 이 역시 튜닝의 수준은 예술의 경지에 도달해 있다. 그리고 그 다음으로 필요해진 것이 코드에 등재되어 있는 병렬화 가능성 정보라고 생각하면 되겠다. 멀티코어는 프로그래머가 잘 숙지하고 있어야 하는 프로그래밍 패러다임이 되었음이 틀림없다.

Posted by 사무엘

옛날에 본인은 윈도우 운영체제의 도움말 시스템에 대해서 심층 분석을 하는 글을 쓴 적이 있다. 그때 그 글은 윈도우 3.0 시절부터 XP까지 존속했던 HLP, 즉 과거의 WinHelp 기반 도움말을 주로 다뤘다. 그래서 이번에는 WinHelp를 대체하는 새로운 도움말 시스템인 HTML 도움말의 기술적 디테일에 대해서 보충 설명을 좀 하겠다.

HTML 도움말 파일의 확장자는 CHM이다. 예전 글에도 언급돼 있듯, HTML 도움말은 웹브라우저의 렌더링 엔진을 도움말에도 그대로 재활용하자는 발칙한 발상을 토대로, 인터넷 익스플로러 4 시절에 첫 도입되었다.

HTML 도움말과 관련된 모든 구동과 조작은 도움말 SDK에 스펙이 명시되어 있는 HtmlHelp 함수 하나로 다 가능하다. 함수의 디자인은 여러 모로 종래의 WinHelp와 유사한 구조로 되어 있다. 다만, WinHelp가 운영체제의 user32.dll에 직통으로 당당히 등재된 함수인 것에 비해 HtmlHelp는 메커니즘이 약간 복잡하다.

HtmlHelp.lib는 다른 dll에 대한 import용 껍데기 라이브러리가 아니다. HTML 도움말 ActiveX 컨트롤 컴포넌트인 hhctrl.ocx 파일로부터 진짜배기 HtmlHelp 함수를 수동으로 LoadLibrary/GetProcAddress하여 호출하는 코드가 안에 들어있으며, 링크 시에 그 코드가 들어가게 된다. 따라서 HtmlHelp 함수를 호출한다고 해서 뭔가 생소한 DLL에 대한 직접적인 의존도가 추가되지는 않는다.

과거에 HLP 파일을 생성해 주는 도움말 컴파일러가 있었듯, 마이크로소프트에서는 CHM 파일을 생성해 주는 도움말 컴파일러도 만들었다. 이름하여 HTML Help Workshop. MS 홈페이지에서 무료로 구할 수 있다.

이 프로그램에는 HTML Help Image Editor라고, 기능이 아주 빈약한 간단한 그래픽 에디터도 포함되어 있다. 그런데 이게 내가 보기에 좀 특이한 프로그램이다. 일단, MS 내부에서 개발한 프로그램 중에서 MFC를 사용하여 만들어진 극소수 프로그램 중 하나이며... (헐) 드로잉 기능조차 하나 없이 화면 캡처, 이미지 자르기, 디더링, 복붙 편집이 전부인 초간단 그래픽 에디터의 실행 파일 크기가 무려 750KB에 달한다. JPG/PNG 파일을 읽고 쓰는 코드가 들어있기라도 한 것도 아니다(그런 건 외부 필터 DLL이 따로 담당).

이게 무슨 델파이로 만든 프로그램도 아니고, 게다가 MFC를 static이 아닌 DLL로 링크했음에도 불구하고 기능에 비해 수긍이 어려운 크기인지라 실행 파일 내부를 들여다봤는데, 그냥 BMP로 때려박아 넣은 리소스 이미지 때문에 크기가 커진 것 같다.;;

이 프로그램의 진짜 특이한 면모는 도움말 창이 뜨는 모습이다. 도킹 윈도우처럼 생긴 보조 윈도우 밑에, HTML 도움말 윈도우가 child 윈도우로 떠 있다. 시스템 메뉴와 캡션, 최소/최대화 버튼까지 있는 당당한 독립 윈도우가 무슨 MDI child 윈도우처럼 다른 윈도우 내부에 이상하게 끼여 있는 게 심히 기괴하다. 저런 식으로 윈도우가 떠 있는 프로그램은 난 지금까지 저 프로그램밖에 못 봤다.

오늘날은 잘 알다시피 HLP 도움말이 사라지고 없기 때문에, 운영체제가 기존 WinHelp 함수에다 HtmlHelp 함수의 기능을 그냥 그대로 집어넣어 버려도 될 것 같다는 생각이 든다. 파일 매체만 다를 뿐이지 하는 일은 거의 똑같으니까.

그런데 문제는 HLP에 이어서 CHM도 MS가 이제 더 지원이나 개발을 하지 않는다는 점이다. <날개셋> 한글 입력기를 포함해 CHM 도움말을 사용하는 아무 프로그램이나 띄워서 도움말을 꺼내 보기 바란다. 윈도우 7에 이르기까지 도움말 창의 도구모음줄 아이콘은 10년 전의 16색 그대로이다. -_-;; HTML 도움말은 UTF8 인코딩 본문 검색도 지원하지 않는다.

HTML Help Workshop은 1997년에 첫 개발된 뒤 실질적인 개발은 1999년에 끝났고, 2002년인가 2003년에 여전히 1.x 마이너 업그레이드를 끝으로 버전업이 중단됐다. 물론 MS는 도움말 컨텐츠를 HTML로 표시하는 건 변함없다. 하지만 이제 CHM 파일을 사용하지는 않는다.

정통으로 자기네 도움말 표시에 HtmlHelp API + CHM 파일을 썼던 건 운영체제는 98과 2000이 전부이고, 오피스 프로그램은 내 기억이 맞다면 2000/XP/2003이 끝이다. 그 뒤엔 또 자기네들만의 독자적인 도움말 시스템을 중복 개발해서 쓴다.

HLP만 보안 위협이 있는 게 아니라 CHM도 웹이 다이나믹한 요소 때문에 위험한 것만큼이나 보안 위협이 많기 때문에, 오히려 CHM의 권한은 약화돼 왔다. 그래서 윈도우 XP의 모 보안 업데이트(아마 SP1 시절인 듯)가 적용된 뒤부터는, 인터넷에서 다운로드한 CHM 파일은 내용이 곧장 표시되지 않게 되었다. 속성을 열어서 파일이 안전하다는 플래그를 수동으로 설정한 뒤에야 내용을 볼 수 있다.

HTML 도움말은 웹브라우저와 붙어 있는 컴포넌트인 만큼, 윈도우 운영체제가 먼 미래에 CHM마저 과거의 HLP처럼 지원을 아예 중단해 버릴 가능성은 내가 보기에 희박하다. 하지만 요즘은 도움말 자체가 그냥 개발사 홈페이지를 통한 온라인 도움말로 대체되는 추세여서 오프라인 도움말 관련 기술의 입지가 좁아져 있는 것도 사실이다. 난 개인적으로는, 웹 에디터만으로 도움말을 간편하게 만들 수 있게 해 준 HTML 도움말을 무척 유용하게 잘 활용하고 있는데 MS가 지나치게 이걸 홀대하고 있다고 생각한다.

그나저나 말이 나왔으니 말인데, 윈도우 프로그래밍을 15년 가까이 했음에도 불구하고, 본인은 아직도 overlapped window와 popup window의 개념적인 차이를 잘 모르겠다. -_-;;
옛날에 윈도우 1.0은 애플 사와의 특허 문제 때문에 모든 프로그램 창들이 벽지 타일처럼 안 겹치게 다닥다닥 배열되는 엽기적인 모습으로 출시됐었기 때문에, 그 당시엔 겹침 가능한 윈도우(overlapped)가 별도의 스타일로 표현되는 특징이었다. 그리고 대화상자처럼 진짜 팝업 형태로 뜨는 윈도우(popup)도 별도의 스타일로 표현되긴 했었는데, 지금은 아마 별 의미가 없는 자질이지 싶다.

Posted by 사무엘