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

3. 피의 메리

1539년에 크고 아름다운 그레이트 성경까지 나온 뒤에야 영국은 확실히 개신교 국가로 탈바꿈하는가 싶었으나, 헨리 8세가 죽은 후 개신교 계열의 에드워드 6세(병으로 요절)와 그 후의 9일천하 레이디 제인 그레이(지못미..;;)가 제대로 권력 승계를 못 하면서 메리 1세가 역사를 다시 뒤로 되돌려 놓았다.

말이 나왔으니 말인데 비운의 9일천하 여왕인 제인 그레이는 삶이 정말 기구했다. 왕위에 앉을 마음이 없었고 사실은 “너 여왕 됐어”란 말에 너무 충격을 받아 졸도를 할 정도였던 여인도 아니고 소녀였다. 부모를 비롯한 어른들의 등쌀에 떠밀려 정략 결혼을 하고, 조국의 개신교 노선을 이어 나갈 여왕 자리에까지 여차여차 올랐지만 백성들의 의식은 거기에 미치지 못했던 모양.

결국 골수 가톨릭 신자인 메리 1세에게 왕위를 빼앗겼다. 메리 1세는 제인 당사자가 권력욕이 있는 인물이 아닌 것을 알았지만, 제인의 부모가 정치적으로 너무 위험한 인물이었기 때문에 그녀를 살려 두기도 곤란했다. 그래서 절충안으로 제인더러 가톨릭으로 개종하면 살려 주겠다는 카드를 제안하였으나, 그녀는 이를 거절했다. 이 때문에 그녀는 결국 20살도 못 된 고등학생 나이에 처형 당했다. 그땐 단두대 같은 것도 없었고, 사형 방식은 그냥 도끼로 목을 치는 것이었다..;;

제인 그레이는 라틴· 히브리 등 5개 국어를 구사할 정도로 똑똑했고, 전해지는 바에 따르면 외모도 아주 아름다웠다고 한다. 그냥 귀족하고만 결혼해서 학자나 교사로 평범하게 살았을 사람인데 저렇게 정치· 종교적 희생양으로 전락하여 비극적인 죽음을 맞이한 것이다. 다만 겨우 고등학생 나이 때도 자기 신앙을 목숨과도 바꾸지 않았을 정도로 독실한 개신교 크리스천이었던 것은 사실이다.

역사 자료에 따르면, 그녀는 최후의 순간에 시편 51편을 외웠으며, 집행을 앞두고 눈이 가려진 뒤엔 “어, 형틀이 어디 있지?” 하면서 당황하며 자신이 목을 내밀 곳을 손을 더듬어 찾았다고 한다. 이 장면은 주변 사람들의 애처로움을 더욱 자아냈으며, 이것이 그림으로 남아 전해진다.

이런 사연을 거쳐 왕위에 오른 메리 1세는 잘 알다시피 피의 메리(Bloody Mary)라고 불릴 정도로 성공회를 포함해 개신교를 무자비하게 탄압하였다. 선왕이 구축해 놓은 영국 내의 종교 개혁 인프라를 모조리 망가뜨렸다. 그래서인지 메리 1세는 초상화를 봐도 좀 표독스러운 모습의 못생긴 여자로 그려져 있고, 특히 이 원복 교수의 <먼 나라 이웃 나라>에서는 네로에 필적하는 싸이코 폭군으로 묘사되었다.

그때 화형 당한 크리스천이 남녀노소를 불문하고 아무리 적게 잡아도 300여 명이라고 전해지는데, 이 숫자만 보면 그래도 1000단위도 아니고 생각보다는 적은 규모인 것 같다. 프랑스 대혁명이나 공산당 숙청 수준은 아닌 듯. 하지만 메리 여왕이 사람만 죽인 게 아니라 성경까지 죄다 불태우라고 지시했다는 것에 주목하는 세속 역사가는 별로 없는 것 같다.

종교 문제를 빼면 메리는 사회· 정치적으로는 그렇게 악한 군주가 아니었다고 전해진다. 그 분야에까지 막장이었으면 진작에 짤렸겠지;; 또한 메리 역시 여왕에 오르기까지 개인사나 가정사는 불운한 편이었으며, 왕위에 오른 후에도 지병으로 인해 자녀 한 명 못 낳고 중년의 나이에 세상을 떠났다.

이렇게 영국에서 갑자기 개신교 박해가 시작되자, 영국에 있던 종교 개혁 성향의 학자들은 죄다 외국으로 피신했다. 이들은 스위스에서 피신해 있는 동안 지금까지 구축된 원어 자료를 집대성하여 더욱 좋은 성경을 만들어 냈는데, 이것이 제네바 성경이다. 예정론과 개신교 교황이라는 오명 때문에 종교 개혁자들 중에서는 비교적 좋지 않은 평판을 갖고 있는 존 칼빈이 그래도 이때는 영국의 종교 개혁자들을 잘 보호해 준 공로를 세웠다.

제네바 성경은 처음으로 66권 전서를 모두 원어에서 번역했으며, 오늘날과 같은 장· 절 구분이 처음으로 생겼다. 그리고 무슨 스터디 성경처럼 온갖 난외주가 첨가되어 성경의 각 구절마다 편찬자들이 생각하는 해설과 강해가 성경 본문의 양보다도 많이 들어갔다.

4. 킹 제임스 성경 -- 종교 개혁 성경의 종결자

메리에 이어 엘리자베스 1세 시대가 되면서 영국은 다시 개신교 노선으로 돌아갔다. 이 시절에 영국 내부의 종교 대립은 가히 오늘날 우리나라의 좌우 이념 대립에 맞먹는 수준이었으며, 반가톨릭 진영에서는 진짜 반공 교육 수준으로 교황을 험담했다. “나는 공산당이 싫어요”가 아니라 “나는 교황이 싫어요” 급이었으며, 교황이 성경에서 예언된 적그리스도 바로 그놈이라고 대놓고 가르쳤다.

예전에 헨리 8세에 이어 왕위를 잠시 이었던 에드워드 6세 왕은 어릴 때부터 궁정 교육을 어떻게 받았는지, 겨우 초등학생 나이인 11살 때 “교황은 레알 마귀 자식이며, 나쁜 놈이요 적그리스도요 가증스러운 독재자 천하의 개쌍놈”이라고 썼을 정도니까. 이건 거짓말이 아니라 정말로 이 승복 어린이 수준이지 않은가? “교황을 죽입시다 교황은 나의 원수”

그도 그럴 것이 영국은 정치적으로도 가톨릭과 앙금이 생길 대로 생긴 게 사실이다. 또, 과거의 역대 교황들이 자신을 예수님 급으로 신성시하면서 “교황의 말에 절대적으로 복종해야만 구원받을 수 있다” 같은 안하무인 개드립을 치는 것을 보면, 어차피 그들은 북한 김 일성· 김 정일이 하는 짓과 똑같은 짓을 하고 있긴 했다.

제네바 성경은 재야(?) 종교 개혁자들이 사용해 온 좋은 성경이긴 했으나 외국에서 자기네끼리 제작된 사역(私譯)이었으며, 엘리자베스 시절엔 국교회 내부에서 또 그레이트 성경의 개정판 격인 비숍 성경이라는 걸 만들어 썼다. 가톨릭-개신교뿐만이 아니라 같은 영국의 개신교 노선 내부에서도 성공회와 청교도 사이의 갈등이 깊어진 게 이 시기이다. 가톨릭으로부터의 박해가 없어진 뒤엔 영국 교회가 또 대립과 반목으로 인해 분열될 위기에 처했다.

그래서 엘리자베스 여왕의 서거 이후, 후임인 제임스 1세 왕은 청교도와 성공회를 중재하는 차원에서, 이제 다시는 성경을 또 만들 필요가 없게끔 완벽한 성경을 만들기로 승인을 내려 준다. 그래서 킹 제임스 성경이 드디어 1611년에 나왔다. 장과 절 구분, 100% 원어 번역, 청교도와 성공회 모두 OK, 국내 인쇄 등 예전 성경들이 차츰차츰 확보한 좋은 속성을 모조리 물려받았다.

이 책이 세상을 완전히 바꿔 놓았으며, 킹 제임스 이후 영국에서는 먼 훗날, 1881년에 부패한 웨스트코트· 호르트 본문에 기반한 RSV가 나오기 전까지는 또 새로운 성경이 나오지 않았다. 새로운 역본이 나올 필요가 이제는 없어졌기 때문이다. 특히 성공회와 청교도 사이의 대립 구도로 인해, KJV가 번역될 때는 성경 번역 역사상 전무후무한 철저한 검증 시스템이 도입되었으며, 이것 덕분에 KJV는 유례가 없는 고품질로 만들어질 수 있었다. 위기가 기회로 승화된 셈이다.

엘리자베스 시대에는 종교 개혁을 거꾸러뜨릴 목적으로, 바티칸의 일종의 비밀 결사대인 예수회라는 무지막지한 비밀 조직이 결성되었다. 이들은 KJV에 앞서 듀에이 레임스라는 판타지 짝퉁 성경을 만든 바 있으며, 엘리자베스 다음으로 영국에 가톨릭이 아닌 개신교 왕이 즉위하자 용병을 고용하여 화약 폭발로 제임스 1세 왕을 죽이려고 음모를 꾸미기도 했다. 그러나 이 음모는 기적적으로 사전 발각되어 미수에 그쳤다.

세속 역사가들은 인류가 기독교적인 사고방식을 벗어나 휴머니즘을 추구하면서 교황의 권위가 약화되고 르네상스 시대가 찾아왔다고 가르친다. 그러나 본인의 시각에서는 성경이 널리 보급되고 복음이 전파되면서 교황의 권위가 약화되고 세상이 암흑에서 빛으로 나아가기 시작한 것으로 보인다. 바티칸 교황이 역사적으로 인류의 발전을 가로막고 엄청난 해악을 끼쳤다는 것에는 본인 역시 세속 역사가의 시각과 100% 일치한다만, 그것이 기독교라고 싸잡아 분류되는 것에는 본인은 동의할 수 없다.

유럽 국가들 중 영국만이 종교사가 저렇게 특이한지, 왜 영국만 국가 교회가 존재하며 개신교와 가톨릭 사이의 팽팽한 줄다리기가 있어 왔는지? 왜 영어 성경만 여러 계보가 존재해 왔는지? 더 나아가 하필 킹 제임스 성경이 세계에 퍼져 나간 최종 권위 성경이 되었는지에 대해 KJV 신자라면 관심을 가질 필요가 있다. 나도 역사를 잘은 모르지만 내 신앙의 정체성과 뿌리를 이해하는 데 필요한 최소한의 내력은 공부해 두려 한다.

오늘날 인도에 불교가 없으며 예루살렘에 기독교가 없는 것처럼, 영국도 이제 성공회의 노선은 천주교 쪽으로 다시 거의 기울었고 사람들은 킹 제임스 성경에 대해 잘 모른다. 발간 400주년을 맞이한 작년에 반짝 조명 정도나 받았을 뿐이다. 그러나 야만인 바이킹들이나 뛰놀던 섬나라 영국이 세계를 호령하는 제국이 되었으며, 영국뿐만 아니라 유럽이 전반적으로 중세 암흑기를 벗어나 식민지 개척을 할 정도로 강대국이 된 것에 성경과 복음이 기여한 것을 부인할 수는 없을 것이다.

Posted by 사무엘

1. 유럽의 중세 암흑기

천 년이라는 시간은 그야말로 어마어마하게 장구한 시간이다. 성경에는 앞으로 예수님이 재림하셔서 이 세상을 공의로 1000년 동안 다스릴 것이라는 예언이 있다. 한편, 한국사에서는 신라가 AD 900년대까지 거의 1000년 가까이 존속하여, 도읍인 경주 역시 ‘천년고도’(千年古都)라고 불린다. 본인이 경주 출신이다만, 그 작은 도시가 천년고도였다는 게 믿어지지 않는다.

그런데 서양에서는 교회사가 시작되었으나 진리의 빛이 꺼졌던 중세 암흑기가 거의 1000년에 가까이 계속되었다고 여겨진다. 로마 제국이 멸망한 뒤 나중에 르네상스 시대가 열리고 신대륙이 발견되고 종교 개혁이 일어나고, 유럽이 본격적으로 동양을 과학 기술로 압도하기 그 전에! 그 사이 기간에 대해서 나만 아무 정보가 없는 걸까?

그 사이에 있었던 굵직한 사건이라고는 진짜 십자군 전쟁 정도밖에 생각이 안 난다. 영국과 프랑스의 백년 전쟁과 잔다르크는 1400년대 사건이니, 중세 중에서는 그나마 나중인 편이고.

그 기간 동안 어느 샌가 교황이 유럽을 모조리 장악했으며 성경은 금서가 되었고 종교 재판과 마녀 사냥이 횡행했다. 어떻게 해서 교황이 저런 국제적인 종교 괴물로 등극할 수 있었는지 그 메커니즘을 잘 모르겠다. 교회사를 정확히 알기 위해서라도 여기에 대한 지식이 보충되어야 할 것 같다. (아 하긴, 우리나라만 해도 이단 교주들이 얼마나 돈 잘 버는지를 생각해 보면, 교황이 종교 장사로 큰 대박을 내는 것도 충분히 가능은 했겠다.)

어렸을 때 즐겨 읽었던 유레카 학습 만화 세계 역사 시리즈를 다시 펼쳐 보았다. 그런데 내가 이렇게 알고 있는 게 잘못된 게 아니었다. 제6권에서 예수님의 부활과 승천부터 서로마 제국의 멸망까지 나오는데, 제8권은 곧바로 메디치 가문이 어떻고 미켈란젤로, 르네상스, 콜럼버스, 루터 따위가 나온다. 시간 차이가 장난이 아닌데 중간에 그야말로 엄청난 skip을 한 것이다. (제7권은 칭기즈 칸과 오스만 튀르크 제국 같은 아시아 편이고 유럽 얘기가 아님.)

더 정확히는 6권의 뒷부분에 ‘중세 유럽’이 특집 형태로 수박 겉핥기식으로 대충 짚고 넘어가 있었다. 세심하게 여러 에피소드를 편성하고 스토리가 있는 만화를 넣은 게 아니라, 글과 벽화 소개 위주로 백화사전식으로 “그냥 이런 게 있었다. 끗”이었던 것이다. 중세는 정말 긴 기간이었는데도 이때의 유럽 역사는 이렇다 할 위인이나 큰 변화가 그다지 없었고 사료도 부족하고... 세속 역사가들로부터도 가히 흑역사로 취급받는다는 걸 이제야 실감할 수 있었다. 그래서 판타지 게임이나 영화들의 주된 배경이 되기도 하고.. ㄲㄲ

이 글에서는 유럽이 중세 암흑기를 벗어나 근대로 나아가는 시기에 있었던 일을 영국의 교회사 위주로 요약해 보겠다.
중세에 교황의 권위를 거부하고 성경을 읽고 침례를 행하던 크리스천들은 알비겐시스, 왈덴시스처럼 지역이나 모임 리더의 이름을 딴 다양한 명칭으로 불리며 숨어 지내던 소수의 무리들이었다. 루터가 이신칭의를 주장하기 전부터 이 사람들은 ‘믿음을 통해 은혜로 받는 구원’ 정도는 진작에 알고 있었다.

“우리나라에 복음이 들어오기 전에 고려· 조선시대 사람들은 그럼 아무 기회도 없이 다 지옥 갔냐”라고 기독교에 트집을 잡는 분들이 많은 줄로 안다. 허나 내가 보기에는, 중세엔 서양도 복음에 대한 접근성이 동양하고 별 차이 없었을 것 같다. 그쪽에서는 어차피 교황이 성경을 다 빼앗아 불태우고 수많은 사람들을 거짓 교리로 지옥으로 보내 주고 있었으니까 말이다. 동양엔 왈덴시스 같은 집단이 없었던 게 사실이지만, 그래도 종교 재판소도 없지 않았는가? -_-;;; 피장파장이다.

도미니크 구즈만(천주교에서 성 도미니크라고 부르는 그 사람)이라는 수도승이 그런 크리스천들과 교리 논쟁(오늘날로 치면, 종교갤에서의 키배)을 종종 벌였으나, 그들을 도무지 이길 수 없었다. 가톨릭은 교리도 완전히 잘못됐을 뿐만 아니라 그 기원부터가 로마 제국 시절에 세상 권력과 결탁하여 순교자들의 피를 부르며 시작되었다고 조목조목 반박하는데, 당할 재간이 없었다.

그래서 말로 곱게 회유가 안 되는 반동분자들을 적당히 꼬투리 씌워 조지기 위해 도미니크 수도회가 만들어 낸 게 종교 재판소의 원조이다. 서기 1223년, 교황 그레고리 9세에 의해 드디어 정식 공표된 종교 재판은 마녀도 아니고, 이슬람 같은 완전히 다른 이교도도 아니라 전적으로 크리스천들을 죽이고 그들 재산을 빼앗기 위해 제정된 것이었다. 나머지 목적은 2순위, 3순위일 뿐이다.

2. 헨리 8세 이후 영국의 성경 번역의 역사

그러다가 존 위클리프라는 영국 사람이 처음으로 14세기에 처음으로 영어 성경이라는 걸 만들었다. 열악한 당대 상황 때문에 비록 본문이 부패한 천주교 라틴 벌게이트 기반이었지만, 영어 철자법도 아직 정립해 있지 않던 시절에 원어가 아닌 영어 성경이 나온 것만 해도 어디냐. 그 위상이 가히 영국의 개역성경이라 해도 좋을 것이다. (구한말에 나온 한글 개역성경도 부패한 본문 기반 + 맞춤법 비정립 시기! 1881년 RSV 할 때의 그 개역을 가리키는 게 아니다.)

위클리프는 성경을 번역한 덕분에 천주교로부터 극심한 미움을 받았으며, 나중에 죽고 나서 40년 가까이 지나서야 무덤에서 시신이 다시 꺼내어져 목이 잘렸다.;;; 쉽게 말해서 오늘날 국어에서 욕설로 쓰이는 육시(戮屍)를 실제로 당했다는 뜻이다.

이런 일이 있은 후 영국은 정치적으로 중요한 사건을 겪었다. 아마 대부분의 사람들은 가장 오래 된 영국 왕으로 헨리 8세 아니면 기껏해야 7세 정도까지만 기억을 할 것이다. 이 헨리 8세는 원래는 당시 유럽의 여느 군주들이 그랬듯이 막강한 교황의 권세 앞에서 깨갱 하고 있었다. 친가톨릭이었고 딱히 소신 있는 종교 개혁자 성향도 아니었다.

그랬는데 부인을 6명이나 둔 호색한이었던 그는 치정 문제로 인해, 더 정확히는 ‘아라곤의 캐서린’이라고 불리는 왕비와의 이혼을 교황의 승인 없이 추진하려다 보니 교황과 결별· 단절을 선언하게 되었다. 그리고 영국 국교회(성공회)의 수장을 자처하기 시작했다.

바티칸은 이 소식에 당연히 발칵 뒤집혔으며, 헨리 8세에게 험담과 저주를 퍼붓기 시작했다. 지금까지도 천주교는 이 사람을 루터만큼이나 몸서리치게 미워하며 나쁘게 말한다. 비록 헨리가 의도하지는 않았지만 하나님께서 그의 똘끼를 선한 방향으로 이끄신 것으로 보인다.

이렇게 영국이 천주교의 손아귀에서 정치적으로 벗어날 징조가 보이던 15~16세기엔 천주교에는 악재, 기독교에는 호재가 연달아 터졌다. 에라스무스라는 학자가 바른 성경 계보인 공인 본문을 처음으로 유럽에 소개하였는데, 이것이 가능했던 것에는 동로마 비잔틴 제국의 멸망이라는 당대 정세도 기여를 했다.

이때 루터는 95개조 반박문을 시작으로 종교 개혁을 일으켰을 뿐만 아니라, 공인 본문을 기반으로 신약 성경을 최초로 독일어로 번역했다. 마침 구텐베르크가 발명한 활판 인쇄술로 책을 값싸게 많이 찍어 보급할 수 있게 된 것도 지금으로 치면 컴퓨터· 인터넷· 스마트폰에 필적하는 정보화 혁명이었다.

그리고 영국에는 윌리엄 틴데일이라는 참으로 위대한 믿음의 선배가 등장하여 그 독일어 성경을 다시 영어로 번역한 영어 성경을 만들었다(신약+모세오경+알파. 아직 전서를 만들지는 못함). 바른 원문 계보에서 번역된 최초의 영어 성경이다.

틴데일은 “누구나 성경을 휴대하고 읽을 수 있는 세상을 만들겠다. 소 몰고 밭 가는 촌뜨기 아이라도 교황보다 성경을 많이 알게 만들어 놓겠다”라는 도발적인 공언까지 했는데, 이는 시대를 너무 앞서가는 발상이었고, 그런 열성 때문에 그는 결국은 나중에 순교자의 대열에 오르게 되었다.

그는 교수형과 화형을 순차적으로, 혹은 동시에 당하면서 죽었으며, 죽기 전에 “주여, 우리나라 왕의 눈을 열어 주시옵소서!”라고 크게 외쳤다. 아직 영국은 친가톨릭과 친개신교 노선이 오락가락하는 중이었고, 영국의 고위 관료나 성직자 중에는 친가톨릭 성향에 틴데일을 미워하는 사람도 많았기 때문에, 헨리 8세 왕이 틴데일의 죽음을 막을 수는 없었던 것 같다.

그러나 틴데일의 기도는 그가 죽은 지 6개월 남짓한 시간 만에 응답되어, 헨리 8세는 틴데일의 친구인 마일스 커버데일이라는 사람으로 하여금 영국 성공회가 공식 사용할 영어 성경을 만들게 했다. 커버데일은 사역(私譯)이던 틴데일의 번역물을 십분 활용하여 1535년, 커버데일 성경을 만들었다. 왕이 승인하고(公譯) 성경 66권이 모두 번역된 최초의 영어 성경이 바로 이것이다.

그로부터 몇 년 뒤에는 존 로저스라는 사람이 매튜라는 가명을 써서 매튜 성경을 내었다. 이것은 잉글랜드라는 자국내에서 인쇄된 최초의 성경이라 한다. 틴데일과 커버데일 성경은 모두 영어 성경이지만, 각각 독일과 스위스에서 인쇄된 후 영국으로 밀반입되었기 때문이라고. 국가가 떳떳하게 대놓고 성경을 찍을 정도로 개신교 세력이 충분히 크지 못했던 걸로 보인다.

(下에서 계속)

Posted by 사무엘

이 광근 교수는 프로그램의 정적 분석 분야에서는 아마 우주괴수급의 전문가가 아닌가 여겨지는 분이다.
카이스트 교수로 첫 부임했다가 2003년부터 서울대로 이직했다. 학부 출신 역시 서울대. 1983년에 입학 당시 자연과학 단과대 수석을 차지했으며, 재학 성적 역시 내내 최상위권이던 수재였다.
사진을 보면 알겠지만 이 교수는 상당한 동안이고 학생 시절 모습이 어땠을지가 상상이 된다.

개교 초창기부터 딱부러지게 전산학과가 있었던 카이스트와는 달리, 서울대는 198, 90년대엔 이과에 속한 계산통계학과와 공과에 속한 전자계산기공학과로 컴퓨터 쪽 학과 계열이 므흣하게 나뉘어 있었다. 통합된 컴퓨터공학부라는 게 생긴 것은 1990년대 말 내지 21세기에 들어와서이다. 덧붙이자면, 연세대 역시 컴퓨터과학과라는 이름이 생긴 건 2005년부터이고 그 전엔 정보산업공학이라고 하여 이쪽으로의 분류가 모호했다.
IT 붐과 함께 지금은 당연시되고 있는 학과 이름이 비교적 최근까지도 일류대급에 속하는 대학에도 없었던 게 의외이다. 어쨌든, 이 교수 역시 당시는 서울대 계산통계학과를 졸업했다.

이분의 설파 교리(?)와 연구 분야는 이러하다.
먼저, 기계 중심적이지 않고, 수학적으로 더 엄밀하며 인간의 사고와 논리를 더 자연스럽게 표현할 수 있는 프로그래밍 언어를 지향한다. 사실, C/C++이나 자바는 오늘날의 최신 프로그래밍 언어 이론이나 방법론이 반영된 깨끗한 언어가 아니다.

그래서 이런 전산학 순수주의자(?)는 특별히 람다 대수에 기반한 OCaml이나 최소한 Scheme 같은 함수형 언어를 선호한다. 함수가 마치 일반 상수처럼 코드 중간에서 별다른 작명 없이도 자유롭게 만들어지고 값처럼 다뤄질 수 있다.
이게 좋은 패러다임이기 때문에 심지어 C++도 C++0x에서는 함수 포인터를 대체할 만한 람다 대수 문법이 추가되었으며, 비주얼 스튜디오 2010에서는 F#이라는 함수형 프로그래밍 언어가 새로 도입되었다. 이것은 의미심장한 변화이다.

그리고 이 교수가 연구하는 정적 분석이란, 프로그램을 실제로 실행해 보지 않고, 그 구조를 뜯어보기만 하고서 이 프로그램이 잠재적으로 배열 첨자 초과 오류나 메모리 누설 따위가 발생할 수 있겠다고 진단을 내리는 기술을 말한다. 사실, 좋은 프로그래밍 언어란, 컴파일러만 통과한 프로그램이라면 뻗지 않고 잘 돌아간다는 보장이 되어야 하고 컴파일 시점 때 해당 코드에 존재하는 잠재적인 모든 문제를 찾아낼 수 있어야 한다는 것이 이분의 지론이다.

이게 가능할까? 입력은 키보드나 파일로 들어오고 메모리 할당과 해제가 일어나는 통로가 주어져 있을 때, 복잡한 루프와 배열, 함수 재귀호출, 다중 포인터 로직을 추적하면서(프로그램을 실행하는 게 아니고!) 딱 보고 이 코드는 구조적인 문제가 있다는 걸 찾아내는 게 과연 쉬운 일일까? ㅋㅋ

당연히 머리가 터져나가게 어려운 일일 것이다.
하지만 그게 가능하기만 하다면 프로그램을 일일이 실행해 보는 것보다 훨씬 더 꼼꼼하고 확실한 검증이 행해질 수 있다. 자동차를 실제로 만든 뒤에 충돌시켜서 부숴 보지 않고도 디자인만 딱 보고 운전자의 안전에 어떤 문제가 있겠는지 예측하는 것과 비슷한 맥락이지 않은가.

사실, 프로그램 정적 분석과 뿌리를 공유하는 가장 원초적인 문제는, 바로 전산학에서 다루는 정지 문제(halting problem)이다. 이는 오늘날의 컴퓨터 모델인 튜링 기계에서는 100% 완벽하게 푸는 게 애시당초 불가능하다는 게 증명되어 있다.

이런 맥락에서 프로그램 정적 분석기 또한 100% 완벽하고 정확하게 동작하는 건 불가능하다. 실제로는 문제가 있는 부분이 아닌데 문제가 있다고 진단하는 false alarm도 존재한다. 그 이상 더 정밀하게 동작할 수는 없기 때문.

그래도 이것만으로도 어디냐. C/C++은 성능이 무지막지하게 좋은 대신, dangling pointer, memory leak, buffer overflow 등 이름만 들어도 치를 떨 무시무시한 버그와 보안 문제들에 무방비로 노출되어 있는 chaotic한 언어가 아니던가? 전산학 전공자는 소프트웨어 공학 시간에 익히 배워 알듯, 소프트웨어 개발이란 건 그렇잖아도 작업의 절대적인 양과 질을 측정하기가 어려운 분야이다. 그러니 소스 코드를 정적 분석으로 검증하는 시스템이 없이는 IT 산업계가 제대로 돌아갈 수가 없다. 그렇지 않으면, 어디서 뻑이 날지 모르는 C/C++ 언어로 의료 기기나 우주선 같은 크리티컬 시스템을 만들거나 사용하려면 미리 보험이라도 들어 놔야 하지 않을까 싶다. 진짜로. -_-;;

이런 복잡도를 제어하는 시스템을 연구하는 게 이 광근 교수의 목표이다.
그분은 이걸로 이미 저명한 학술지에 적지 않은 논문을 냈고, 소프트웨어 검증 솔루션을 개발하여 기업체에 납품했다.

사실, 비주얼 스튜디오도 일반인이나 학생이 사용하는 라이선스 말고 제일 비싼 엔터프라이즈급 라이선스 제품을 써 보면, 소스 코드 정적 분석 기능이 들어있다.
기회가 되면 내가 개발한 프로그램도 그런 걸로 한번 좀 분석해 봐야 할 텐데 말이다. 메모리나 GDI 개체, 커널 핸들 등 해제가 필요한 자원들은 전부 클래스 소멸자가 처리하게 바꾸고, 지속적인 개량과 코드 리팩터링을 해 왔기 때문에 그런 초보적인 실수는 이제 없으리라 여겨진다만, 이걸 시스템 차원에서 깔끔하게 입증을 못 하고 있다는 게 문제이긴 하다.

코드를 실행하지 않고 척 들여다보기만 한 뒤 그 코드로부터 문제될 만한 부분을 알아서 찾아 내는 것은 활용 가능성이 굉장히 많다. 마치 공항 검색대가 가방을 열어 보지 않고 사생활 침해 걱정이 없이 비행기에 실을 수 없는 물건을 찾아내는 것처럼 말이다. 이 얼마나 유용한 기술인가?

이 광근 교수는 자기 연구 분야를 차치하고라도, 독특한 스타일의 강의 자료나 여러 글들을 읽어 보면, 가히 공부의 본질을 아는 사람이며 정말로 보통사람이 아니다 싶은 면모가 여럿 느껴진다. 특히 이분은 우리말로 학문하기에 대한 관념이 굉장히 투철한 걸로 잘 알려져 있다.

• “MIT라는 이름은 본토 사람들이 보기에는 그냥 황해도 과기원 정도로밖에 들리지 않으며, 떼제베도 프랑스 원어민에게 다가오는 의미는 단지 매우 빠른 열차일 뿐이다. 우리만 혼자 폼나 보인다고 외래어 알파벳을 남발하고 있다.”
• “비록 어떤 개념이나 기술이 외국에서 유래되었다 하더라도, 그 원판을 능가하는 학문적 성과는 언제나 모국어를 통해서만 이뤄져 왔다.”

외래어는 싹 다 배격하고 정확· 엄밀함을 희생해서까지 무조건 뭉뚱그려서 순우리말만 쓰자는 국수주의 주장이 절대 아니며, 오히려 완전히 다른 차원에서의 주장이다.
작년에 한창 카이스트가 자살과 영어 강의 때문에 시끄럽던 시절에 이분은 자기의 지론을 다시 한데 정리한 개념글을 하나 교수신문에다 기고했다. 그 후 이 글은 전산 비전공자, 심지어 인문학 하는 사람들에게서도 인용되고 폭풍처럼 칭송받고 있는 중이다.

IT 쪽 최정상에 앉아 있는 사람이 이례적으로 용어 순화와 모국어 강의를 옹호하니 뜻밖이지 않은가? 저 글에 딱히 정치색이 있는 건 물론 전혀 아니지만, 영어 강의, 세계화 이런 것들을 반대하고 이념적으로 진보 성향이 좀 있는 사람들이 더욱 지지를 하는 경향이 있었다. 예를 들어 조 국 교수도 그 글을 완전 극찬한 바 있다.

카이스트 교수 부임 시절에 이 교수는 학과 이름을 전산학과에서 컴퓨터xx학과로 바꾸는 것도 괜히 쓸데없는 일이라고 만류한 적이 있다. ACM, IBM의 M은 완전 구닥다리 용어인 '기계'라는 뜻이지 않냐고 말이다.

그리고 대학 캠퍼스 내부의 건물들을 초행자도 식별하기 쉽게 번호가 좀 있어야 한다고 제안하신 바 있다.
그 제안 때문인지 이분이 서울대로 전근 가신 뒤에 얼마 안 되어(2004~2005년쯤 아마?) 카이스트도 건물들에 N0, E0, S0 같은 식으로 번호가 붙었다.
서울대는 워낙 건물이 많고 내부가 복잡해서 진작부터 그런 게 있다.
연세대는 그런 거 없다. 본교 도입이 시급합니다.

지금이야 카이스트 전산학동이 수 년 전부터 몇 층 더 증축되었지만, 그 당시에 이 광근 교수는 아마 공간 부족으로 인해 전산학동이 아닌 이웃 산업공학동에 연구실이 있었다. 그리고 이런저런 어른들의 사정이 더해져서 그분은 서울대로 전근을 가신 걸로 추정된다. 비슷한 시기에 전산학과의 김 태환 교수도 서울대로 가셨다.

이분의 수업은 진짜 그냥 온갖 기호와 공식, 증명이 즐비한 수학 덕후식이며 빡세다..;;;
그래서 카이스트 재학 시절, 내게는 좀 굴욕적인 기억이 있다.
C++의 사고방식에 완전히 중독되다시피하던 내 머리 구조로는 nML이네 뭐네 하는 “프로그래밍 언어 PL” 수업을 도저히 따라갈 수가 없어서... 전공 필수 과목일 뿐만 아니라 전근을 앞둔 스타 교수의 마지막 수업을 드랍하고 말았다. 2003년 봄 학기의 일이다. 그것도 수강 변경도 아닌 철회 기간에 출혈을 감수하며 드랍.

난 그 당시 <날개셋> 한글 입력기 2.x와 3.0의 개발과 직접적인 관련이 있지 않은 복잡한 추상화 계층이나 뜬구름 잡는 이론에는 머리가 전혀 돌아가지 않던 시절이었다. 동기 부여를 받으면 철도 덕후 수준으로 머리가 미쳐 돌아가지만, 동기 부여가 없는 곳에는 난 담을 확 쌓아 버리고 죽어도 관심 안 보인다. 역시 난 프로그래밍으로 다른 창의적인 작품을 만드는 게 삶의 목적이지, 프로그래밍 패러다임 자체를 바꾸는 일은 내 적성이 아니라는 걸 알 수 있었다. C++보다 더 엄밀하고 깔끔한 프로그래밍 언어로 수학 덕질하는 것보다는, 당장 윈도우 API로 옛한글과 세벌식 모아치기를 구현하는 것에만 온통 관심이 쏠려 있어서..

그래서 나중에 한 태숙 교수의 PL을 다시 들었다. 이분의 PL 수업이 그나마 내가 생각했던 PL 수업에 더 근접한 평범한(?) 것이었고, 들을 만했다.;; 각종 프로그래밍 언어들의 특성과 개념, 값의 평가 시기, LL 파서, LR 파서, garbage collector의 동작 원리 등등.. 참고로 덧붙이자면, 내가 예전 글에서도 소개한 적이 있듯 한 교수 역시 왕년에 1등을 놓친 적이 없었고 대입 학력고사 전국 수석을 차지했던 공부 만렙 괴물이다.;;

현재는 카이스트 전산학과의 류 석영 교수가 과거 이 광근 교수의 제자이며, 그분 뒤를 이어 카이스트 프로그래밍 언어 연구실을 공동 운영하고 있다(한 태숙, 최 광무 교수와 같이).
류 교수의 증언에 따르면 이 교수 연구실은 말도 못 하게 무지막지하게 빡세기 때문에, (그 대신 잘 적응하면 얻는 것도 많겠지);; 어지간한 각오가 돼 있지 않다면 그분 연구실로 대학원 진학을 하는 건 비추라고 한다. =_=;;;
그래도, 좀 까칠한 것만 빼면 교수님은 학자로서 정말 좋은 분이라고.. ㅜㅜ

어쨌든 이 광근 교수. 수업 하나 들은 적도 없이 헤어졌지만, 이런 식으로 내 기억에 남아 있다.
본인이 이분에 대해 수집한 모든 정보들의 출처는 당연히 그분의 공식 홈페이지이므로, 관심 있으신 분은 방문해 보시라.

Posted by 사무엘

한 달쯤 전에 비주얼 베이직 리뷰를 쓴데 이어 오늘은 델파이와 해당 계열 RAD 툴의 리뷰를 좀 써 보겠다.
비주얼 베이직뿐만이 아니라 델파이와 C++ 빌더(C++ Builder)는 본인이 지금 같은 골수 비주얼 C++ 유저가 되기 전에, 도스에서 윈도우 프로그래밍으로 넘어가던 과도기 시절에 잠깐 써 본 개발툴이다. 고등학교 시절의 추억이 담겨 있다.

일단 파스칼이라는 언어 자체가 본인이 베이직에서 C/C++로 넘어가기 전에 과도기적으로 잠깐 공부했던 언어이다. 당시 정보 올림피아드 공부용으로 파스칼이 아주 깔끔하고 좋다는 말이 있기도 했고 말이다. 이 언어는 정말로 베이직과 C 사이의 과도기 역할을 하면서 본인의 프로그래밍 패러다임의 전환에 굉장한 도움을 주었다.

도스용 볼랜드 파스칼 역시 상당히 잘 만든 개발툴이었다. 그래서 본인은 이걸로 뭔가 이렇다할 프로그램을 개발해 보지 못한 게 좀 아쉽다. 개발툴의 본좌(?)이던 마이크로소프트와 볼랜드는 둘 모두 도스에서는 16비트의 한계를 벗어나질 못했으니 말이다. 그리고 지금 역시 <날개셋> 한글 입력기처럼 극도의 최적화를 추구해야 하는 프로그램은, 비주얼 C++만치 더 적격인 툴이 없는 것도 어쩔 수 없는 현실이다.

1990년대 초중반에 마이크로소프트가 '비주얼' 브랜드로 새로운 개발툴을 내놓은 것처럼 볼랜드는 오브젝트 파스칼 기반의 완전히 새로운 RAD 툴을 내놓았다. 그것이 바로 델파이. 게다가 1995년에 첫 출시된 1.0은 전무후무하게 16비트 윈도우용이었다.

델파이는 원래 AppBuilder라는 제품명이 붙을 예정이었고 Delphi는 코드명일 뿐이었다. 내 기억이 맞다면 이에 대해서 재미있는 일화가 전해진다.
잘 알다시피 IT계엔 그 이름도 유명한 Oracle이라는 데이터베이스 엔진(DBMS)가 있다. 이거 참 센스 있는 작명인게, DB에다가 SQL을 때려서 쿼리가 수행되는 것을 마치 신탁을 내리는 것에다 비유한 것이다. “수천만 개의 레코드 중에서 요것과 연계하여 이런 조건을 만족하는 놈을 눈앞에 0.1초 안에 대령하라.” 검색 엔진에다 심마니라는 이름을 붙인 것과 비슷한 맥락의 작명이라 하겠다.

그런데 신탁이 내려지는 곳이 어디던가? 신전이다. 그리고 고대 그리스에는 델파이라는 도시에 아폴로 신전이 있었다.
델파이는 DB와 연동하는 업무용 프로그램을 파스칼 언어를 기반으로 빠르고 편리하게 개발해 내라고 만들어진 개발툴이다. 그래서 DB 쿼리라는 신탁이 내려지는 장소에다 빗대어 델파이라는 코드명이 정해졌고, 이게 곧 제품명이 되었다. (뭐, 굳이 DB를 안 쓰더라도 각종 유틸리티나 에디터, 툴을 만드는 용도로도 좋지만 말이다.)

이런 이유로 인해, 델파이는 지금까지도 신전이나 집 비슷한 모양을 한 아이콘을 갖고 있다. 델파이의 C++ 버전이고 델파이보다는 훨씬 덜 유명한 C++ Builder는 집+크레인처럼 생긴 건축 기계 모양 아이콘이다. C++ 빌더는 다른 건 델파이와 비슷한데 역시 C++의 특성상 빌드 속도는 훨씬 더 느리며, RAD 툴의 용도에 맞게 C++ 문법을 자기 식대로 확장한 게 좀 있다. 또한 C++답게 경쟁사의 MFC 라이브러리도 내장하고는 있다.

그런 곳에서는 C++의 위상이 좀 므흣한 게, 닷넷으로 치면 마치 C++ managed extension 같은 존재이다. 닷넷에서는 아예 확실하게 C#을 쓰고 필요한 곳에나 unsafe 코드를 가끔씩 집어넣고 말지, 네이티브 기계어 개발이 아니라면야 C++이 얼마나 메리트가 있겠나 싶다. C/C++을 쓸 정도이면 아예 Win32 API만을 이용한 하드코어 저수준 개발을 하지, 애초에 RAD용으로 만들어진 게 아닌 언어에다가 그 정도로 추상화 계층을 거친 RAD 껍데기를 거추장스럽게 씌울 필요가 있겠나 하는 생각이다.

볼랜드에서는 자기네 RAD 툴에다가도 닷넷 기술을 연동하여 C# Builder 같은 툴을 만들기도 했지만 이건 얼마 못 가 접었다. 다들 비주얼 C#을 쓰지 굳이 볼랜드 툴을 쓰지 않았기 때문. 볼랜드는 그런 자신의 RAD 영역을 더욱 발전시켜서 마치 qt 같은 크로스 플랫폼 개발 프레임워크를 표방하며 리눅스용으로 카일릭스(Kylix)도 내놓고, 지금은 맥 OS X 범용 개발 환경도 내놓았는데, 아이디어는 분명 좋다만 결과는 과연 어떨까 궁금하다. 카일릭스는 수 년 전에 망했고 개발이 중단됐다.

하긴, 말이 나왔으니 말인데 얘들은 개발사의 명칭이나 주체가 여러 번 바뀌었다(개명· 인수 합병). 볼랜드이다가 한때는 Inprise, Codegear를 거쳐 지금은 Embarcadero임.

이런 저런 사정이 많았으나 델파이는 결국 오늘날까지도 그냥 윈도우 플랫폼 한정으로 강세인 것으로 보인다. 나름 네이티브 코드(오옷!)를 가히 C++로는 엄두를 못 낼 전광석화의 속도로 생성하는 RAD 툴이니, 생산성은 확실히 우위이다. 프레임웍에 속하는 코드가 단일 exe에 모조리 static 링크되어 들어가기 때문에, Hello world 급의 프로그램도 Release 빌드의 exe는 1MB 이상은 먹고 들어간다.

비주얼 C++ 2008 이상부터는 MFC를 static link해도 그 정도는 먹고 시작한다. 과거의 6.0 시절에는 MFC의 static link 오버헤드 크기가 200~300KB대였는데, 재미있게도 그 당시의 델파이 2~3도 exe의 기본 크기가 그 정도였으니 옛날이나 지금이나 오버헤드가 서로 비슷하다.

이런 이유로 인해, 델파이로 개발된 프로그램은 실행 파일을 실행 파일 압축기로 압축한 채 배포되는 경우가 종종 있다. 하지만 압축된 실행 파일은 코드 실행 영역이 동적으로 생성되고 고쳐지기 때문에, 동일 EXE가 중복 실행되었을 때 코드 영역이 동일한 물리 메모리를 공유하여 메모리를 절약하는 효과를 못 보지 싶다. 실행 파일 압축기가 집어넣어 준 압축 해제 stub이 그런 걸 똑똑하게 감지하여 처리하지 않는다면 말이다. 뭐, 요즘은 어차피 메모리도 차고 넘치는 시대이긴 하지만...;;

내 기억이 맞다면, C++ Builder는 델파이와는 달리 수 MB짜리 vcl.dll (Visual Component Library) 런타임이 필요한 작은 exe를 생성했었지 싶다. 즉, 정적 링크가 아니라 동적 링크 방식.

그런데 얘들의 프레임웍 라이브러리는 덩치만 큰 게 아니라 윈도우 API를 나름 체계적으로 잘 커버하고 있다. MFC는 윈도우 API에다 아주 최소한의 껍데기만 씌운 것에 가까운 반면, 볼랜드의 라이브러리는 운영체제 API에는 존재하지 않는 여러 추상적인 계층을 더 만들고, 심지어 같은 에디트 컨트롤도 single line (TEdit)과 multi line (TMemo) 버전을 따로 만들었다. MFC는 그냥 CEdit 하나로 끝인데 말이다. 내부 구현이 옵션만 다르게 지정된 동일한 에디트 컨트롤이니까 말이다.

라디오 버튼이나 체크 버튼도 under the hood는 그냥 버튼 컨트롤일 뿐이기 때문에 MFC는 CButton 하나로 끝이다. 그러나 볼랜드의 라이브러리는 응당 TRadioButton과 TCheckBox로 클래스가 따로 나뉘어 있다.
볼랜드의 프레임워크는 DC고 GDI 객체고 나발이고 생각할 것 없이 자기네가 마련한 TCanvas라는 개체를 통해 마음대로 색깔을 바꾸고 픽셀 단위 그래픽 접근이 가능한 반면, MFC에서는 그런 자비를 찾아볼 수 없다. 그런 추상화 계층을 마련하는 오버헤드가 exe의 실행 파일 크기 내지 런타임 DLL로 나타난다고 생각하면 됨.

이런 전통이 사실 볼랜드의 옛 C++ 라이브러리인 OWL (Object Windows Library)부터 어느 정도 전해져 오고 있었다. 델파이가 나오기 전, 볼랜드 C++/파스칼이 윈도우용으로 있던 시절 얘기이다. OWL이 좀 더 객체 지향 철학을 살려서 더 잘 만들어진 라이브러리이긴 했으나, 언제부턴가 IE가 넷스케이프를 누르듯이 MFC가 OWL을 떡실신시켜 버렸다.

세월이 세월이다 보니 델파이도 도움말 레퍼런스는 MS 비주얼 스튜디오의 Document Explorer를 쓰고 있어서 뜻밖이라는 생각이 들었다. 하긴, 옛날 버전은 아예 WinHelp를 쓰고 있었는데, 자기네만의 도움말 시스템을 새로 만드는 건 너무 뻘짓이고 그냥 chm을 쓰기엔 레퍼런스의 분량이 너무 방대한데, 저렇게 하는 게 나은 선택이다.

델파이의 근간 언어인 파스칼은 내부적으로 문자열을 포함하는 방식이 원래 C/C++과는 다르다. 그러나 운영체제의 각종 API들이 오로지 C/C++ 스타일의 null-terminated 문자열만을 취급하기 때문에 델파이 프로그래머도 C/C++ 스타일 문자열이라는 개념을 몰라서는 안 된다. 사실 파스칼과 C/C++은 함수 호출 규약조차도 달라서 과거에는 C/C++에서도 함수 선언할 때 STDCALL뿐만이 아니라 PASCAL이라는 속성이 있을 정도였다.

파스칼에도 포인터가 있긴 하다. 하지만 C/C++만치 배열과 포인터를 아무 구분 없이 남발할 수 있는 건 아니며 쓰임이 제한적이다. a[2]뿐만이 아니라 2[a]까지 가능한 건 가히 C/C++의 변태적인 특성이다만, 파스칼은 등장 초기에는 동적 배열이라는 개념 자체가 아예 없었다고 한다.
타입 선언에서 포인터를 의미하고 실제 수식에서는 포인터가 가리키는 값을 얻어오는 연산자가 C/C++은 *인데 파스칼은 ^이다.
그리고 이미 있는 변수의 주소를 얻어 오는 address-of 연산자는 C/C++은 &이고, 파스칼은 @이다.

델파이로 개발된 프로그램은 윈도우 비스타/7의 Aero 환경에서 창을 최소화해 보면 창이 작업 표시줄 쪽으로 미끄러지듯 fade out이 되지 않고 그냥 혼자 싹 없어지곤 했다. 나타나는 비주얼이 살짝 다르다. 델파이로 빌드된 다른 프로그램들을(특히 구버전) 살펴보면 차이를 알 수 있다.

그랬는데 최신 2011년도 델파이 XE2로 프로그램을 하나 빌드해 보니까 드디어 여타 프로그램처럼 제대로 최소화된다. 개선이 된 듯하다.
델파이가 유니코드와 64비트를 제대로 지원하기 시작한 것도 생각보다 최근이라고 들었다만.. 앞으로 이 툴이 어디까지 발전하고 MS의 비주얼 툴과는 다른 독자적인 지위를 유지할 수 있을지가 지켜보는 건 흥미로운 일일 것이다.

* 2014년 7월 1일 추가함.
델파이 1.0은 특정 업종 종사자들만 사용하는 딱딱한 개발툴인 주제에 무슨 게임을 방불케 하는 화려한 설치 화면을 자랑했다.

설치 프로그램이 full screen 모양으로 실행되는 게 유행이던 시절의 즐거운 추억이다. 본인도 중학생이던 시절 저 화면을 직접 본 적이 있다. 정말 개발툴 역사상 전무후무한 디자인이 아닐까 싶다.

속도계는 어떤 축적된 분량이 아니라 단위 시간당 변화량 개념이기 때문에,
굳이 이런 프로그램에 넣더라도 차라리 지금 파일의 전송 속도를 나타내는 용도가 더 적절할 것 같다만..;;
어쨌든 저 계기판에서 속도계가 전체 설치 진행 상황을 나타낸다.

굉장한 창의력과 잉여력이 아닐 수 없다. 그때는 MS Office 9x 프로그램에도 간단한 핀볼이나 3D 레이싱 게임이 이스터 에그로 들어가 있었을 정도이니 뭐...
단, 델파이의 경우 설치 중에 저 배경에서 차가 실제로 주행하여 배경이 입체적으로 스크롤된다거나 하지는 않는다. ^^ 그건 일말의 아쉬운 점이다.

Posted by 사무엘

1.
겨울방학도 이렇게 끝이 보인다.
본인이 이번 방학 때 이뤄낸 가장 뜻 깊은 성과를 둘 꼽자면 하나는 <날개셋> 한글 입력기 6.5이고, 다른 하나는 HFT(아래아한글 전용 글꼴) 해킹 성공이다.

저 글꼴들을 MS 오피스 제품에서도 쓰고 PDF도 자유롭게 만들고, 무엇보다도 화면에 anti-alias가 된 부드러운 모습으로 보니 너무 좋다.. 근성의 reverse engineering 오덕질을 통해서 이뤄 낸 성과. ㅋㅋ 새로운 글꼴로 아무 글이나 마구마구 써 보고 싶다.

또한, 날개셋 6.5 버전은 아직까지도 프로그램을 크게 고친 부분이 없을 정도로 역대 최고로 손꼽히는 안정성과 완성도로 잘 만들어졌다. 대단히 만족스럽다. 그래서 당분간 안심하고 완전히 새로운 기능 연구와 논문 준비 등에 전념할 수 있을 것 같다.

2.
윈도우 7은 콘솔(명령창)에서 세벌식을 쓰면 '다다.' 이렇게 한글이 덧나는 버그가 있다. 왜 SP1에서도 안 고쳐진 걸까? 예전에도 언급한 적이 있지만, 이런 건 두고두고 디스를 좀 해 줘야 된다.
윈도우 운영체제는 NT 계열도 꼭 이런 이상한 버그가 역사적으로 하나씩 있었다.

과거 2000은 256색으로 들어갔다가 돌아오면 군청색 제목 표시줄의 색깔이 옅어지는 버그를 유일하게 갖고 있어서 SP4에서까지 안 고쳐졌고,
XP는 테마를 저장했다가 불러오면 Luna 모드에서도 메뉴가 클래식 모드처럼 표시되어 색깔이 이상해지는 버그가 있는데 역시 SP3에서까지 안 고쳐지고 저렇게 끝났다.

이런 이유로 인해 본인은 한글 IME 개발과 관련하여 까탈스럽고 안 좋은 추억 때문에 남들이 7 좋아하는 것만치 7을 좋아하지는 않으며, 남들이 비스타 싫어하는 것만치 비스타를 싫어하지도 않는다. -_-;; 뭐, 비스타도 희한한 버그 의심 증상이 하나 있긴 했으나, SP1에서 곧바로 고쳐짐.

3.
<날개셋> 편집기는 txt 확장자를 자기 프로그램으로 연결한다거나 하지는 않는다.
그렇기 때문에 이렇게만 놔 둬서는 윈도우 7의 jump list를 활용하지 못한다. (윈7 사용자 중에 jump list가 뭔지 모르는 분은 없으리라 생각되지만, 어쨌든 모른다면 검색 요망)

탐색기에서 txt 파일을 우클릭하여 '연결 프로그램 선택 → 찾아보기' 등을 골라서 <날개셋> 편집기를 한 번이라도 지정한 뒤(꼭, 기본 연결을 시켜 놓을 필요는 없고 이렇게만이라도), 나중에 <날개셋> 편집기의 열기 대화상자로 txt 파일을 열고 나면 그건 앞으로 jump list 에 등재되게 된다.

jump list를 좀 더 창의적으로 활용하면, 편집기는 당장 저런 기본 용도만으로도 충분할 것이고(최근 파일 열기),
변환기는 클립보드 변환 같은 자주 사용할 만한 task를 등록해 놓을 수 있겠으며,
입력 패드는 자주 쓰는 보조 입력 도구를 실행과 동시에 바로 꺼내 놓게 할 수 있겠는데 더 자세한 활용법에 대해서는 좀 더 시간을 두고 고민해 봐야겠다.

4.
얼마 전엔 드디어 <날개셋> 한글 입력기 프로젝트를 비주얼 C++ 2010용으로 정식으로 포팅해서 빌드해 봤다. 특이사항으로는,

- 사소한 컴파일 에러가 있었으나, 더 깔끔하고 분명한 코드를 만드는 데 도움이 되는 에러였으며 쉽게 잡았다.
- VS 2010의 빌드 시스템은 $(TargetPath) 변수의 값을 예전과는 다른 방식으로 부여하는 듯하다. 그래서 이걸 조정하는 노가다를 매 프로젝트들마다 좀 해야 했다.

이것 외엔 딱히 트러블이 없었으니 무리 없이 잘 갈아탔다.

동일한 옵션으로 빌드했지만 x86 바이너리(32비트)들은 VS 2008과 비교했을 때 크기가 살짝 더 커졌고, x64 바이너리(64비트)들은 살짝 더 줄어들었다.
같은 코드를 빌드했을 때 바이너리 크기가 조금씩 더 커지는 건, VC6 이래로 개발툴이 업데이트되면서 비교적 일관되게 관찰되는 추세였다. 최적화가 인라이닝 등 코드 크기를 더 키우는 쪽으로 행해져서 그런 것 같다.

비주얼 C++ 2010은 C/C++ 언어도 빌드 중에 'Linking...'이라는 말이 안 뜨고 generating code...에 링킹이 포함되는 듯하다.
똑똑한 인텔리센스는 부러운 점이긴 하다만, 너무 커진 덩치, 이질감이 생긴 GUI와 도움말 시스템 때문에 2010은 개인적으로 언제쯤 도입하게 될지 모르겠다. 다만, 리소스 에디터가 드디어 윈도우 비스타의 PNG 내장 아이콘(256*256)까지 제대로 표시해 주는 점은 마음에 든다.

5.
내 경험상 윈7은 USB 메모리(스틱 or 외장 하드) 매체의 제거를 예전 OS에 비해 더 관대하게, 더 빨리 허용해 주는 것 같다. 해당 드라이브를 사용하는 프로그램들을 다 껐는데도 '사용 중이기 때문에 제거 못 함' 꼬장 때문에 할 수 없이 아예 OS를 로그오프하거나 아니면 그냥 강제로 매체를 제거해 버린 일이 거의 발생하지 않았다.

그리고 다른 얘기이다만, 윈도우 7은 Taskbar에 있는 각종 프로그램들 아이콘과 시스템 트레이의 아이콘을 드래그하여 마음대로 순서를 바꿀 수 있는 게 무척 인상적이다.
7에서 새로 바뀐 작업 표시줄은, 실행 중인 프로그램과(동일 프로그램이 중복 실행된 것 포함) 그렇지 않은 프로그램의 구분이 잘 되아 보이는 걸 개인적으론 안 좋게 생각했었다. 그러나 한동안 써 보니까 이게 그럭저럭 나쁘지 않은 디자인이라는 생각이 든다.

무엇보다도, 창을 몇 개씩 띄워 놔도 많이 띄웠다는 느낌이 심리적으로 안 드는 게 인상적임.
옛날에 윈9x의 전통적인 시작 메뉴 시절엔, 컴을 몇 년 쓰면서 수십 종류의 프로그램들을 설치하고 나니까 '프로그램' 메뉴 옆으로 프로그램 리스트가 두 칼럼 이상씩 차지하는 크고 아름다운 면적으로 주렁주렁 달렸던 거 기억하는가?

또한 인터넷 서핑하다가 브라우저 창이 열몇 개씩 넘어가니까 작업 표시줄 모습이 가히 가관으로 바뀌던 것도 기억하시는지? 윈도우 7은 복잡도를 제어하는 디자인에 무척 신경을 썼다..

6. 윈도우 비스타와 7 모두, 로그인 화면에서 암호를 입력하고 나면, 암호가 맞든 틀리든 일단 Welcome부터 출력하면서 설레발을 치다가 그 뒤에 암호가 틀렸으면 사용자 진입을 거부한다. “안 돼! / 돼!”도 아니고 츤데레도 아니고 이건 도대체 무슨 디자인일까?? -_-;;
암호가 맞을 때만 Welcome을 출력하게 개선되면 좋겠다.

7.
윈도우 9x는 프로그램을 조심해서 짜는 데에 도움을 준다.
NT 계열에서는 해제했던 메모리를 중복 해제하거나, 자원을 반납· 해제하는 걸 깜빡하는 식으로 대충 대충 짜도 당장 티가 안 나며 그냥 넘어간다. 그러나 9x에서 그랬다간 얼마 못 가 시스템 자원이 바닥난다거나 바로 뻗어 버리기 때문에, 이런 차이 덕분에 프로그램을 윈도우 9x에서 테스트하다가 버그를 발견하여 구조적인 문제를 해결한 경우가 지금까지 종종 있다.

아마 <날개셋> 한글 입력기도 한 2~3년 동안 윈9x에서 테스트를 안 한 채 개발을 계속하다가 버전이 1.0쯤 올라간 뒤에 다시 윈9x용으로 테스트하면, 여기저기서 원인을 알 수 없는 버그가 자꾸 튀어나와서 단순히 유니코드 API layer를 쓰는 것만으로는 윈9x를 결코 다시 지원할 수 없는 수준에 이를 것이다.
지금 <날개셋> 한글 입력기 소스가, 비록 같은 C++언어이지만 비주얼 C++ 6.0으로는 도저히 개발을 계속할 수 없는 이질적인 단계에 도달한 것처럼 말이다(각종 문법 차이 때문).

Posted by 사무엘

우리나라에는 잘 알다시피 국군이라고 불리는 정규 군대가 존재하고 징병제를 시행하고 있다.
이웃 나라 일본은 너무 국력이 강해서 과거에 세계를 상대로 깽판을 친 벌로, 국제법상으로는 오히려 군대를 가질 수 없는 나라가 되었는데... 우리나라는 지정학적 여건이 좋지 않고 국력도 충분치 못해서 반대로 징병을 안 하면 안 되는 신세가 된 게 한탄스럽긴 하다.

우리나라 국군의 기본적인 이념은 defensive이다. 아니, 사실 오늘날 적극적인 offensive를 표방하는 군대는 세계 경찰· 지구 방위대를 자처하는 미군-_-밖에 없을 것이다.
군대는 육· 해· 공으로 분야가 크게 나뉜다. 한국군은 국토가 삼면이 바다인 반도 지형인데도 불구하고 육군만 기형적으로 너무 크다는 지적이 있다. 뭐, 비록 오늘날의 전쟁은 최첨단 무기의 각축장이긴 하나, 그래도 정말 최후에 점령지에서 깃발 꽂고 승리 인증샷을 남기는 사람은 언제나 재래식 육군 보병이니, 전쟁의 기본 구도가 예나 지금이나 크게 바뀔 일은 없을 것이다.

군대에는 군대를 잘 이끌어나갈 유능한 차세대 지도자가 필요하며, 이를 양성하기 위해 우리나라에도 육· 해· 공별로 총 3개의 사관학교가 있다. 육사는 서울 노원구에 있고, 공사는 충북 청원에, 해사는 창원에 있어서 남한의 북부· 중부· 남부에 자리잡고 있다.

원래 공사는 서울에 있었으나 1985년에 충청도로 이사 갔다. 그리고 옛 공사 부지가 지금의 보라매 공원으로 조성되어 있다. 이것이 서울 지하철 7호선 보라매 역의 어원이다.
한편, 다른 덴 몰라도 해사는 당연히 바닷가 항구 도시에 있어야 할 것이다. 그래서 그런지 해군은 병사 훈련소도 사관학교와 동일한 창원시 진해군에 있다.

사관학교는 예나 지금이나 명문 학교로 간주되고 있으며, 또 그래야만 정상이다.
군사 정권 시절에 비해서는 인지도가 떨어진 게 사실이나, 지금도 경쟁률이 꽤 높으며 서성한이나 중경외시 사이는 충분히 되는 입결인 걸로 본인은 알고 있다.
이 어려운 연간 등록금 1000만 원 시대에, 사관학교는 학비는 물론 주거비· 생활비가 전혀 들지 않으며, 오히려 학교에서 품위유지비 월급까지 나온다. 입학하면 개인별로 노트북 PC가 지급되고 기숙사 방에는 프린터도 있다.

그리고 그렇기 때문에 사관학교는 학생을 상대로 굉장히 까다로운 조건을 걸고 까칠하게 굴 수 있다.
입학 전형은 여름 무렵부터 일찌감치 시작되며, 필기고사부터 시작해 내신은 물론 마지막의 수능 결과까지 입시에 반영된다. 필기고사는 3사관학교가 공동 출제하여 동시에 시험을 보기 때문에, 학생은 서로 다른 군의 사관학교에 동시 지원을 할 수 없다. 체력 검정과 신원 조회까지 다 한다.

최종 합격자는 고3 겨울방학 자유시간이 없다. 가입교 기간이라 하여 군사 훈련을 받으면서 다 보내야 한다. 뭐, 해군과 공군처럼 100% 지원자로만 구성되는 군대는 병사도 가입교 기간이 있긴 하다만, 사관학교의 가입교는 성격이 좀 다르다.

정식 입학한 사관학교 학생은 생도라고 불린다. 영어로도 그냥 student가 아닌 cadet이라고 다른 호칭이 붙는다. 이들은 국비로 엘리트 장교로 양성되는 대신, 일반 대학생보다 개인 자유를 훨씬 더 제한당한 채 4년을 보내야 한다.
학교 생활 전반이 군생활이다. 수업을 들으러 기숙사에서 강의동으로 이동하는 것도 단순 등교가 아니라 학사 출장이기 때문에, 단체로 오와열 맞춰서 해야 한다.
방학다운 방학도 없으며, 이때의 스케줄은 군사 훈련이나 국토 대장정 같은 다른 활동으로 꽉 차 있다..

군대는 전쟁터에서 공권력을 동원한 폭력을 합법적으로 행사하는 집단이 아니던가. 그래서 조직이 잘 돌아가게 하기 위해 야만성을 최대한 감추고, 그 대신 명예와 규율, 정의를 이념적으로 어지간한 종교 집단 이상으로 대단히 강조한다. 육· 해· 공 사관학교는 공통으로, 중간과 기말 때 감독이 없는 명예 시험을 실시하며, “사관 생도는 진실만을 말한다. 사관 생도의 언행은 언제나 일치한다...” 같은 honor code도 부과되고 있다.

생도는 학사 경고를 한 번만 먹어도 바로 퇴교(퇴학도, 제적도 아닌 퇴교)이며, 심한 질병이 아닌 다른 사유로는 휴학도 못 한다.
육사의 경우 낙하산 타고 뛰어내리는 공수 훈련을 무서워서 못 받으면 퇴교이고, 승마와 태권도도 졸업 때까지 무슨 급 이상까지 못 해내면 퇴교이다. 뭐, 이런 저런 식으로 언뜻 보기에 까다로운 제약 조건이 많긴 하지만, 군인 정신 투철하고 육사까지 갈 정도로 심신이 건강한 사람이 못 할 수준은 물론 아니다.

이런 학교 시스템에 적응을 못 하고 퇴교하는 사람이 종종 발생하는데, 이것은 국가로서는 예산 낭비이고 손실이다. 성적 미달(능력 부족-_-)이나 질병(불가피) 이외의 사유로 퇴교하는 사람은--특히 자퇴하거나 사고 치고 짤리면-- 이제 국군에서 어떤 형태로든 장교가 영원히 될 수 없다. 그리고 1학년은 병-_-으로, 2~3학년은 하사로, 4학년은 중사로 곧바로 군 복무를 하게 된다. 뭐, 연장자도 자기가 원한다면 부사관 대신 병으로 복무할 수도 있긴 하지만.. 왕년의 짬밥이 있으니 군사 훈련은 물론 면제이고 바로 자대 배치이며, 육사에 다녔던 기간이 감안되어 복무 기간은 다소 짧아진다고 한다.

여자 생도야 퇴교와 동시에 군대와의 인연은 그대로 끝이다. 단, 남자든 여자든 가입교 기간에 뛰쳐나간 것은 애시당초 정식 입학이 아니기 때문에 추후의 장교 복무 지원에 문제가 되지 않는다.

고된 4년간의 생도 생활을 마치면 이들은 군사학 학사와 더불어 자기 전공에 따라 문학사나 공학사, 이렇게 두 개의 학사 학위를 받고 소위로 임관한다. 이들이 방학도 없이 얼마나 빡세게 지냈는지를 감안하면, 학위를 둘 받는 게 이상한 일은 아닐 듯. 임관식 때는 잘 알다시피 대통령을 비롯한 높으신 분들도 많이 온다. 이들의 의무 군복무 기간은 10년이나, 아마 5년차에 단기 전역 신청도 가능은 하지 싶다.

일단 중위에서 대위로 넘어가면 정말 군대가 단순 통과 경로가 아니라 삶의 목적이며 생계 수단인 사람들인데, 10년보다도 더 오래 남아 있으려는 사람은, 대령에 장군까지도 넘보는 군대 고위 간부요 만렙 지망생인 셈이다. 중령 이상 되면 전역 후에도 연금까지 나올 걸?

사관학교는 우리가 생각하는 것보다 굉장히 작은 학교여서 전교생이 몇백 명, 천 명이 될까말까이다. 그러니 실제 복무 중인 장교들은 사관학교뿐만이 아니라 학사 장교, ROTC 등 다른 출신이 더 많다.

하지만 이들 중에 사관학교 출신이야말로 성골이며, 진급이 가장 유리함은 두말 할 나위도 없다. 딱히 전쟁이 안 나고 누가 북한군을 몇 명 더 잡았다는 식으로 눈에 띄는 공적 기록이 없는 군인들의 세계에서는, 저런 출신으로 랭크가 생기는 게 어쩔 수 없는 귀결이다. 다만, 이들이 더 힘들고 위험한 전방 부대의 전투 병과로 더 우선적으로 배치되며, 그런 곳에서의 근무 경력이 진급에 당연히 더 유리하게 작용하는 것도 사실이다. 큰 사고 안 치면 중령까지는 거의 확실하고 대령부터가 갈라진다고 보면 된다.

생도와 일반 병사와의 관계는 어떨까? 사관학교는 학교인 동시에 일종의 군부대이기 때문에 내부에서 잡일 근무하는 병사도 소수 존재한다. 사관학교 내부에 근로 장학생을 둘 수는 없는 노릇이니까. 그러나 병사와 생도는 서로 다른 구역에서 생활하며, 마주치더라도 상종을 안 하는 게 불문율이다. 덧붙이자면, 육사 출신이 그런 병사들을 통솔하는 간부로 발령 나지도 않는다.

다만, 육사에는 생도들에게 승마를 가르치는 군마조교병이라는 특기병이 있는 건 특이점이라 하겠다. 병사가 생도를 가르친다니! 이곳에서 근무하는 병사의 인터뷰를 본인은 본 적이 있다.
또한 여기가 비록 군사 시설이라 해도, 민간인의 사관학교 방문은 국정원을 방문하는 것만치 까다롭지는 않다.

사관학교는 잘 알다시피 해병대처럼 학번 대신 기수로 서열을 매긴다. 군대가 무슨 민영화-_-를 해서 다른 경쟁 사관학교가 있기라도 한 게 아니기 때문에, 사관학교 출신들은 순혈주의-_- 동문 문화가 굉장히 발달해 있고, 교수들도 당연히 육사면 육사, 공사면 공사 등 동일 학교 출신이다. 군 복무 기간 동안 군에서 보내 주는 대학원에서 공부를 더 한 케이스라 하겠다.

사관학교 출신은 비록 군대에 오래 몸담지 않고 일찍 예편한다 하더라도, 앞서 말했듯이 나름 명문대 출신으로 사회에서도 응당 인정을 받고 있다. 회사에서도 사람 뽑을 때 같은 값이면 병보다는 장교 복무 경력이 있는 사람을 더 쳐주지 않던가? 게다가 공사 졸업한 전투기 조종사 출신은 민간 항공기 조종사라는 마법의 진로까지 있다. 군대보다 보수가 훨씬 더 좋고, 민항사에서 공사 출신 인재를 적극 원하기도 하니 윈윈 게임인데 정작 공군 측에서는 인재 유출 때문에 고민이라고 한다. (과학고/카이스트에서 국비로 공부한 이공계 인재가 그래 봤자 다 의대로 빠져나가는 것과 비슷한 차원의 고민쯤으로 생각하면 됨 ㄲㄲㄲㄲ)

사관학교는 명목상 국립 특수 대학교이긴 하지만, 대표자의 직함이 총장이 아니라 교장이다. 얘네들은 이상하게 '교'짜를 좋아한다. 역시 국립 특수 대학교인 카이스트는 한때 대표자의 직함이 원장이었는데, 한 2004년 무렵부터 총장으로 바뀐 케이스에 속한다.
요즘은 사관학교 교장은 중장, 다시 말해 쓰리스타의 보직으로 여겨지고 있다. 군 지도자를 양성하는 최정예 교육기관을 대표하는 보직이니 높을 수밖에 없다.

그런데, 육· 해· 공을 막론하고 역대 사관학교 교장들의 재임 기간을 보면, 임기가 굉장히 짧다. 교장이 거의 2년 주기로 바뀌며, 생긴 지 길어야 70년도 안 된 학교가 교장의 대수가 3, 40대에 육박해 있다. 왜 그럴까?
이는 하루가 멀다하고 수시로 바뀌는 장군들의 보직 이동 때문이라고 생각하면 되겠다. 사관학교 교장은 일반 대학교의 총장과는 신분이 다르기 때문이다. 우리나라 국군은 인사적체가 아주 심해서 장군 수에 비해 보직 수는 부족하니, 번갈아가면서 교장 자리 앉혀 준 뒤, 빨리 군단장 거쳐서 더 진급할 사람은 포스타 사령관, 합참의장 자리까지 가는가 보다. 잘 알다시피 군대 장교 시스템이라는 것은, 부사관과는 달리 일정 나이 때까지 진급 못 하면 짤리는 피라미드 구조이기 때문.

이상으로 본인이 우리나라의 사관학교에 대해서 알고 있는 것을 쭉 memory dump해 보았다. 참고로 이 글을 쓴 필자는 밀덕이 전혀 아니며, 군대 체질하고는 영 안 맞는 1人이다. -_-;;;

영천에는 3사관학교라고 하여 또 다른 육군 장교 양성 학교가 있다. 생도는 다른 2년제 대학을 마치고 입학해서는 2년 교육 후 여기서 4년제 대학 졸업으로 나오고 임관하는 만큼, 이게 학사 장교나 ROTC보다는 높게 평가되는 듯하다. 하지만 성골인 육사에 비해서는 인지도가 떨어지는 게 사실이다. 교장도 쓰리가 아닌 투스타더라.

Posted by 사무엘

윈도우 운영체제에는 잘 알다시피 DLL이라는 게 있어서 한 프로세스를 구성하는 코드들을 여러 모듈로 분할할 수 있고, 반대로 동일한 코드를 여러 프로세스가 동시에 효율적으로 공유할 수 있다. 유닉스 계열의 운영체제에는 이와 비슷한 개념으로 shared library (*.so)라는 게 있다.

윈도우 DLL은 주소 공간이 해당 DLL을 로딩한 프로세스(EXE)에 완전히 종속된다. 그렇기 때문에 DLL이 사용하는 코드는 공유될지언정, 그 DLL이 선언하는 전역변수 같은 건 EXE마다 제각각이며, 심지어 동일 EXE를 여러 번 실행하더라도 제각각이다. 이것은 유닉스의 shared library와 다른 점이다. 윈도우에서 진짜 여러 프로세스들이 공유할 수 있는 메모리를 만들려면 내부적으로 공유되는 메모리 섹션을 별도로 생성해 놔야 한다.

이런 차이로 인해 특별히 조심해야 할 점이 있다. 한 EXE 안에서 3개의 DLL이 돌아가고 있고, 이들은 모두 동일한 버전의 비주얼 C++로 개발되어 동일한 CRT 라이브러리를 사용한다고 치자. 만약 이들이 모두 CRT를 DLL로 링크하여 동일한 CRT 라이브러리의 코드와 데이터를 공유한다면, 어느 모듈에서 malloc/new한 메모리를 다른 모듈에서 곧바로 free/delete해도 된다.

그러나 이들이 제각각 CRT를 static link했다면 그럴 수 없다. 한 모듈에서 할당한 메모리는 반드시 동일한 모듈에서만 해제해야 한다. 비록 메모리를 할당하고 해제하는 코드는 실질적으로 동일하지만 해당 코드가 동작하는 context는 모듈들이 모두 서로 다르기 때문이다. 모듈간에 메모리 할당과 해제를 자유롭게 하려면 각 모듈들은 자신만의 메모리 할당/해제 함수를 외부에다 별도로 제공해 줘야 한다.

DLL을 만드는 일은 64비트 운영체제가 등장하면서 다소 까다로워졌다. 32비트와 64비트 사이에는 DLL의 교차 로딩이 되지 않기 때문이다. 즉, 32비트 모듈(EXE/DLL)은 64비트 DLL을 읽을 수 없으며, 반대로 64비트 모듈은 32비트 DLL을 읽을 수 없다. 다시 말해, x64 운영체제에서도 x86 EXE를 아무 차이 없이 실행은 할 수 있지만, 그래도 64비트 EXE가 32비트 DLL을 내부적으로 읽을 수는 없으므로 착오 없기 바란다.

한 주소 공간은 전부 32비트 아니면 전부 64비트뿐이지, 두 종류의 코드가 섞여 있을 수가 없어졌다. 옛날과는 달리 지저분한 썽킹 계층 같은 게 없다. 동일 코드를 32비트와 64비트용으로 제각기 빌드해서 다같이 내놓아야 한다.
그러니 태생적으로 반드시 네이티브 코드 DLL을 만들어야 하는 컴포넌트/미들웨어/드라이버 분야라든가, 훅킹 내지 운영체제의 shell extension을 만드는 쪽은 다른 어떤 분야보다도 진작부터 64비트 프로그래밍이 필요했다. 사실은 IME 쪽도 예외가 아니다.

그런데 문제가 있다. 지금까지 DLL은 코드를 담는 용도로만 쓰여 온 게 아니라는 점이다. 잘 알다시피 윈도우 운영체제는 실행 파일의 포맷 차원에서 리소스라 하여 나름 계층을 갖춘 custom 데이터를 간편하게 불러오는 기능이 있다. 일일이 메모리 할당을 할 필요가 없이, 운영체제가 알아서 메모리 주소를 잡아서 로딩해 주고, API 함수 호출 한 번에 데이터를 곧장 찾아 주기까지 하니, 상당히 편리하다. 그래서 데이터 리소스만 갖춘 DLL도 엄청 많이 쓰였다.

특히 다국어 지원을 위한 외국어 리소스를 집어넣는 데 DLL보다 더 좋은 수단은 지금까지 별로 없었다. 운영체제의 대화상자 내지 string table 같은 주요 리소스 파일의 포맷은 32비트나 64비트나 바뀐 게 없다. 호환성 차원에서 일부러 동일하게 유지시킨 듯하다. 비주얼 스튜디오 200x의 MSDN(Document Explorer)이 사용하는 *.hxs 파일도 리소스 전용 DLL이다.

그런데 DLL은 태생적으로 컴퓨터 기계 종류에 지극히 종속적인 코드를 담는 게 주 목적인 파일 포맷이다. 그렇다면 기계 종류에 관계없이 동일한 데이터를 담는 DLL도 기계별로 일일이 다 따로 만들어야 할까?
그렇지는 않다. 데이터밖에 들어있지 않은 리소스 전용 DLL을 위해서 운영체제는 다음과 같은 배려를 하고 있다.

먼저, DLL을 읽을 때 흔히 사용하는 LoadLibrary 대신, LoadLibraryEx 함수는 LOAD_LIBRARY_AS_IMAGE_RESOURCE 같은 플래그를 제공하여 DLL의 코드 부분을 전혀 감안하지 않고 데이터 부분만 읽게 할 수 있다. 이렇게 하면 해당 DLL은 DllMain 함수 자체가 실행되지 않으며, 자신과 호환되지 않는 기계를 타겟으로 만들어진 DLL도 읽을 수 있다. 물론, FindResource 같은 함수로 리소스 추출만 가능할 뿐, GetProcAddress 같은 기능을 사용할 수는 없다.

다음으로, DLL 자신이 리소스 전용 DLL일 뿐이라고 명시해 줄 수 있다. 비주얼 C++의 DLL 프로젝트에서 링커 옵션을 보면 /NOENTRY가 있다. 이 옵션이 지정되면 그 DLL에는 아무 코드도 삽입되지 않으며, 진입점인 DllMain 함수 자체가 없는 리소스 전용 DLL임이 인증된다. 이런 DLL은 외부에서 그냥 대놓고 LoadLibrary로만 호출해도 기계 종류에 관계 없이 읽을 수 있다.

윈도우는 공유 라이브러리를 다루는 개념이 유닉스 계열과 차이가 있을 뿐만 아니라 실행 파일을 로딩하는 방식에도 개념적인 차이가 있다. 윈도우는 position-dependent, 즉, 주소 종속적인 방식이다. 윈도우의 EXE와 DLL에는 preferred address라는 게 있어서, 이 메모리 주소에 딱 로딩이 되면 아주 성능이 좋지만, 그 주소에 로딩이 못 되면 재배치 페널티가 따르는 방식을 사용한다. 재배치 작업을 어떻게 하면 되는지에 대한 재배치 정보가 reloc이라는 섹션에 있다.

EXE야 Win32s 같은 과거의 열악한 환경이 아닌 이상, 자신만의 고유한 주소 공간이 있기 때문에 언제나 preferred address에 로딩된다는 보장이 있다. 그에 반해 남의 주소 공간에 달라붙는 형태인 DLL은 그렇지 못하기 때문에 일반적으로 반드시 reloc 섹션이 필요하다.
다만, 이런 재배치 작업도 코드가 없는 리소스 전용 DLL에는 전혀 해당사항이 없다. 리소스 내부에 DLL의 메모리 주소에 종속적인 숫자 데이터 같은 게 있을 리가 없기 때문이다.

그러니 이론적으로 리소스 전용 DLL은 reloc 정보를 생략해 버려도 괜찮지만, 그냥 대놓고 생까-_- 버리는 것도 곤란하다. 윈도우 2000 미만의 옛날 운영체제의 경우 DLL을 preferred base에다 로딩을 못 하는데 재배치 정보마저 없다면, 원래 재배치를 할 게 없는 리소스 전용 DLL임에도 불구하고 그냥 일방적으로 로딩을 거부해 버리게 된다.

재배치를 안 해도 괜찮은 DLL이라는 별도의 플래그는 윈도우 2000 이상에서부터 도입되었다. 물론, 애당초 기계어 코드가 들어있지 않은 DLL의 reloc 섹션에 의미 있는 재배치 정보 자체가 있을 리가 없다. 그냥 껍데기뿐인 잉여인 것이다.

이렇듯, DLL은 원래 코드를 공유하려고 만들어졌지만 기계와는 무관한 리소스나 데이터를 공유하는 container 역할도 결코 무시할 수 없는 위치에 있다. 심지어 트루타입(TTF) 글꼴이 도입되기 전에 윈도우에서 쓰이던 비트맵/벡터 글꼴인 FON 파일은 16비트 형태의 리소스 전용 DLL로, 오늘날의 64비트 윈도우에서도 그 잔재가 남아 있다!

그래서 운영체제가 리소스 전용 DLL에 대해서는 예외적으로 기계를 가리지 않고 읽을 수 있고, 또 그런 DLL에는 불필요한 정보를 합법적으로 생략도 할 수 있게 별도의 배려를 해 왔음을 우리는 윈도우 API의 변천사를 통해 알 수 있다.
그러고 보니, 32/64비트 응용 프로그램이 각각 32/64비트에 해당하는 윈도우 시스템 디렉터리나 각종 프로그램 디렉터리를 얻어 오고 접근하는 법도 꽤 복잡해져 있는데, 이건 다음 기회에 다루도록 하겠다.

Posted by 사무엘

1. 시스템 종료를 시스템 재시작으로 바꾸기

아주 오래 전부터 생각해 오던 건데...
시스템 종료 명령을 내려서 운영체제가 shutdown 중일 때 특정 글쇠를 누르면...
시스템 종료를 철회하는 것까지는 안 되더라도, 최소한 나중에 컴이 아주 꺼져 버리는 게 아니라 reboot/restart로 바뀌게 하기... 이것만 있어도 아주 아주 편할 것 같다. 난 윈 9x 시절부터 이거 필요성을 몇 년째 느껴 왔다. -_-;;
기술적으로 별로 어려운 것도 없을 텐데.

2. IE의 안습한 속도

내가 IE 쓰면서 굉장히 불만스럽고 싫은 것 중 하나는..
페이지 인코딩이나 팝업 허용 옵션을 변경할 때 매번 해당 페이지를 reload하는 것...
최소한 사용자한테서 묻고 하거나, 지금 로딩돼 있는 놈을 해당 설정만 바꿔서 다시 표시할 수 없나?

그리고 속도도 불만이다. 웹 브라우저가 체감 성능이 좋으려면 페이지 캐싱을 잘 해야 하고 자바스크립트 구동하는 속도가 빨라야 하고 HTML 파싱과 렌더링 알고리즘이 좋아야겠지만, 그 중 기본 중의 기본은 새 탭이나 새 창을 띄우는 반응 속도가 빨라야 한다.

그런데 이 속도를 IE와 사파리와 구글 크롬 이 셋끼리 비교해 보면 IE는 그저 한숨만 나올 뿐이다.

Ctrl+N/T를 누르거나 링크에 대한 Ctrl/Shift+클릭을 했을 때의 반응...;;
IE 이놈은 살 좀 빼야 할 것 같다.
그래도 다운로드 확인 대화상자가 떠 있는 동안 미리 다운로드를 하는 건 좋은 아이디어이며, 체감 다운로드 속도를 크게 끌어올린 주역이다. IE9가 머리 좀 썼다..

3. 악성 코드가 붙은 웹페이지

다만, 크롬도 성가시고 불편한 점이 없지는 않다.
일부 사이트에 들어가면 이 사이트는 어디어디로부터 유래된 악성 코드가 묻어 있으니 위험하다면서 브라우저가 페이지 표시를 거부한다.
요즘 아무리 HTML이 동적인 요소가 많이 발달했다 해도, HTML은 기본적으로 컴퓨터에 아무 영향을 주지 않는 문서일 뿐인데 정보 열람을 브라우저가 제멋대로 거부하니까 굉장히 불쾌하다. 오피스 문서도 출처가 의심스러운 매크로가 있으면 매크로만 제외하고 보여주면 되지 않는가.

실제로, 그런 사이트들의 소스를 보면 문서가 다 끝난 닫는 html 태그 뒤에, 또 이상한 자바스크립트가 들어가 있긴 하다. 이런 건 정체가 무엇이며 내 컴퓨터에 정확하게 어떤 영향을 끼칠 수 있는지? 이런 사이트는 서버가 해킹이라도 당했기 때문에 소스 뒤에 이상한 자바스크립트가 첨부되어 나오는지? 여러가지 디테일이 궁금하다. 바이너리 형태인 EXE 실행 파일 안에 바이러스 코드가 붙은 것도 아니고, 텍스트 형태인 웹문서 소스에도 악성 코드가 붙을 수 있구나? -_-

4. 사용자 계정 컨트롤 (UAC)

윈도우 비스타에서 이 기능이 첫 도입된 취지는 적극 이해한다만, 이를 제대로 인식이나 활용 못 하는 옛날 애플리케이션들 때문에 상당히 고달프다.
다른 브라우저는 테스트하지 않았다만, 내 컴의 IE9는 일반 권한 모드로 실행하면, TextCube 블로그 엔진으로 글 쓰면서 첨부 파일 업로드 버튼을 눌렀을 때 파일 열기 대화상자가 먹통이 되고 뜨지 않는다. 웹 프로그래밍이 UAC의 영향을 받기라도 하나? 그 이유는 모르겠다. 어쨌든 당장 내 블로그에다 그림이 곁들여진 글을 올릴 때는 IE를 관리자 권한으로 실행해야 한다.

여차여차 하다 보면 결국 일반 권한 프로그램과 최고(=관리자) 권한 프로그램이 뒤섞여 있게 되는데, 일반 권한 프로그램은 관리자 권한 프로그램에다가 메시지를 보내거나 interprocess communication을 할 수 없다. 그래서 분명 파일을 열라는 요청을 내렸는데 이게 아무 말도 없이 씹힌다거나 하는 일이 비일비재하다. Program Files 폴더 아래에다가 파일을 건드리는 (몰상식한) 프로그램의 경우, 이게 진짜 Program Files인지, 아니면 UAC가 redirect한 가짜 Program Files인지도 아리까리해지고.. 불편하다.

그리고 나로 하여금 운영체제 차원에서 UAC를 끄지 않을 수 없게 만든 결정적인 주범은 아래아한글 2007.
UAC가 켜져 있으면 아래아한글을 “관리자 권한 주고 실행”하더라도 PDF 인쇄 기능이 전혀 동작하지 않고 그냥 먹통이 된다. 아래아한글 전용 글꼴인 HFT는 자기네 전용 드라이버를 안 쓰면 PDF로 제대로 만들지도 못하는데, 문제는 본인은 아래아한글 2.5 확장팩 글꼴 매니아여서 HFT를 안 쓰면 안 된다는 것. -_-

차라리 발상을 정반대로 바꿔서 말이다. 평소에는 전체 권한으로 지내다가, 좀 risk가 있는 웹페이지 들어갈 때 사용자가 지정한 특정 응용 프로그램만 “권한 낮춰서 실행” 이렇게 접근하는 건 어떨까 싶기도 하다. 파워 유저의 입장에서는 그게 더 편할지도..;

5. 컴퓨터의 시계

시계가 없는 컴퓨터란 상상할 수 없다. 컴퓨터의 내부에는 상당히 정확한 시계가 있다. 기계식일 리는 없고 당연히 전자식.
옛날에 IBM PC XT는 시계 배터리가 없었다. 그래서 컴을 켤 때마다 날짜와 시각을 다시 설정해야 했으며, 이 때문에 당시 MS-DOS는 autoexec.bat가 없더라도 date와 time 명령은 수행한 후 명령 프롬프트가 나타났었다.

그 반면 오늘날처럼 제대로 된 컴퓨터와 운영체제 하에서는 시스템의 날짜와 시각을 바꾸기 위해 관리자 권한이 필요하며, 사실 그렇게 해야 하는 게 마땅하다. 시스템의 날짜· 시각이 멋대로 바뀔 수 있으면 그걸 기준으로 동작하는(특히 뭔가 업데이트 여부를 판단하는) 프로그램들이 모조리 혼란에 빠진다.

윈도우 운영체제를 쓰다가 간단하게 달력을 꺼내 보는 방법은, 작업 표시줄에 있는 시계를 더블클릭하여 날짜/시각 대화상자를 꺼내는 것이었다. 그게 옛날에는 대화상자였는데 비스타부터는 간단한 팝업창처럼 바뀌어서 키보드 포커스를 잃으면 창이 바로 사라져 버리며, 결정적으로 창을 옮길 수가 없게 되어 좀 불편해졌다.
다만, 비스타부터 다른 시간대의 추가 시계를 출력하는 기능이 추가된 것은 아주, 대단히 편리하다. 마음에 든다. 본인은 LA의 시간대와, GMT 표준시간대를 추가해 놓고 지낸다.

그나저나 시계 하니까 생각나는데... 시계의 원조는 기계식 시계이며, 톱니바퀴와 렌치가 일반인들의 머리에 각인되어 있는 기계의 상징인 건 틀림없는 것 같다. 그래서 윈도우에서도 DLL 확장자의 상징 아이콘은 톱니바퀴 그림이고, 각종 공구 모양은 제어판이나 도구, 옵션 기능의 아이콘이 되어 있다.

6. Task dialog

잘 알다시피 윈도우 비스타부터 Task Dialog는 아주 멋진 UI 요소가 추가되었다.
그런데 여기에서 좀 이상한 동작 방식을 우연히 발견하여 여기에 그 내역을 공개한다.
Windows 환경에서는 Alt+F4는 창 닫기 내지 종료를 의미하며, 대화상자는 당연히 '취소'로 닫기 때문에 ESC와 역할이 거의 같다.
하지만 Task dialog를 Alt+F4로 닫아 보면... '취소'가 아니라 언제나 맨 첫째 버튼을 누른 결과가 전달되는 듯하다.

메모장을 띄운 뒤, 텍스트를 고치고서 저장 안 하고 Alt+F4를 누른다.
“변경 내용을 저장하시겠습니까?” 대화상자(task dialog임)가 뜬 상태에서 포커스를 '저장'이나 '저장하지 않음', '취소' 중 아무것에다 둔 뒤에 Alt+F4를 누르면...
놀랍게도 '다른 이름으로 저장' 대화상자가 뜬다. 맨 왼쪽의 '저장' 버튼이 눌린 것처럼 반응이 온다.
이거 좀 문제가 있어 보인다.
윈도우 비스타와 7 모두 최신 서비스 팩 있는 상태에서도 동일하게 동작함.

Posted by 사무엘

본인은 10여 년 전인 2000~2001년 사이에 세벌식 솔루션 3관왕-_-? 3총사를 차례로 최초로 개발하였다. 이 홈페이지 대문에 다 공개되어 있다.

하나는 주력 연구 작품인 <날개셋> 한글 입력기. 이건 사실 세벌식 글자판을 기본으로 삼아 한글 입력 체계에 대한 총체적인 연구를 목표로 하는 학술적인 프로그램이다. 이윤을 목표로 만드는 것도 아니고, 또 딱히 사용자 중심적으로 만드는 프로그램도 아니기 때문에, 여느 공개 소프트웨어에서는 찾을 수 없는 특이한 기능과 라이선스, 그리고 초심자가 언뜻 보기에 접근하기 어려워 보이는 복잡한 UI를 고수하고 있다.

뭐, 그래도 어쨌든 대부분의 일반 사용자들은 그냥 에디터가 하나 필요해서, 혹은 Shift+Space를 쓰거나 한글 로마자 글자판을 쓰려고, 혹은 세벌식 모아치기를 하려고, 또는 드보락 자판을 같이 쓰려고 이 프로그램을 사용한다. 하지만 그건 이 프로그램이 제공하는 기능의 완전 빙산일각일 뿐이다. 좀 외람된 비유이다만, 구원받아서 누리는 크리스천의 온갖 영적 복은 다 제끼고, 오로지 죽어서 지옥 안 가고 천당 가려고 예수 믿는 것과 비슷한 맥락이다. (엥?)

그리고 다음으로 잘 알다시피 타자연습 프로그램이 있다. 세벌식을 연습하려면 세벌식 사용자가 만든 세벌식에 최적화된 타자연습 프로그램이 있어야겠다는 생각을 해서 만들었다. 세벌식이 그냥 잉여 옵션이 아니라, 세벌식, 특히 최종 자판이 main인 프로그램.

사실, 아래아한글 워디안/2002가 리모델링된 한컴타자 유틸리티를 공개하기 전이던 2000년대 초엔, 세벌식 최종을 정식 지원하는 타자연습 프로그램은 박 정만 님이 개발한 '광타'밖에 없었다. 그리고 윈도우 운영체제와 아래아한글 97이 제공하던 최종 자판은 오류가 있었다. 그만치 최종 자판은 인지도가 안습하였다. 그런 와중에 세벌식 최종 전용 타자연습 프로그램인 <날개셋> 타자연습의 임팩트는 결코 작지 않았다.

타자연습은 잘 알다시피 한글 입력기의 한글 입출력 엔진을 빌려서 개발되었다. 비록 수 년 전부터는 입력기의 연구 개발에 밀려서 타자연습의 메이저 버전업이 중단된 상태이지만, 본인은 이 프로그램의 개발을 완전히 접거나 포기한 상태가 아니다. 껀수가 생기면 얼마든지 프로그램을 또 업데이트할 생각이다. 이 프로그램은 입력기보다는 훨씬 더 사용자 지향적으로 개발되고 있다.

다음으로 이 두 프로그램에 비해 인지도가 덜하고 <날개셋>이라는 브랜드도 붙어 있지 않으나, 또 아주 중요한 세벌식 솔루션이 마지막으로 있으니, 그것은 바로 세벌식 파워업이다.

세벌식 파워업은 세벌식과 관계가 있으나 <날개셋> 한글 입력기와는 무관한 프로그램이다. 이건 <날개셋> 없이 운영체제의 기본 IME만으로 세벌식을 쓰려는 사람에게 필요하다. 이 프로그램은 클릭 한 번으로 MS 기본 한글 IME의 두벌식/세벌식 설정을 간편하게 바꿔 준다. 이 외에도 화면에 세벌식 최종 글쇠배열을 띄워 놓는 기능과 한글 IME 제어판 설정을 바로 꺼내 주는 기능도 있어서 세벌식 사용자에게 무척 유용하다.

이 프로그램은 사실 <날개셋> 한글 입력기 1.0의 개발이 끝나고 정보 올림피아드도 끝났던 2000년 말에 처음으로 개발되었다. 레지스트리 설정을 바꿈으로써 윈도우 95/98/ME의 한글 IME를 대상으로는 잘 동작했으나, 2000에서는 동작하지 않았다. 하지만 이 기능만으로도 본인은 세벌식 사용자들에게서 칭찬과 감사의 말을 굉장히 많이 들었다.

그러다가 세벌식 파워업이 진짜로 ‘파워업’이 된 때는 2004년, <날개셋> 한글 입력기가 3.0으로 대폭 업그레이드된 그 시절이었다. 그때 두 가지 정말 큰일을 해냈다. 먼저 공유 메모리 패치 지점을 reverse engineering으로 찾아냄으로써, 드디어 2000/XP 등 모든 계열의 한글 IME에서 세벌식 자동 전환 기능을 동작시키는 데 성공했다. 그리고 다음으로, 당시 오류가 있던 MS 한글 IME의 세벌식 최종 글쇠배열을 아예 파일 차원에서 ‘패치’하는 엽기적인 기능을 추가했다!

그 당시는 <날개셋> 한글 입력기 3.0과 더불어 외부 모듈이 처음으로 개발되고 있었는데, 그러는 한편으로 MS IME 자체에 대한 연구도 진행되어, 그걸로 참고표와 가운뎃점을 찍는 방법을 찾아냈던 것이다. 이것 역시 <날개셋> 개발에 필적하는 쾌거였다.

파워업 프로그램이 마지막으로 큰 변화를 겪은 때는 그로부터 2년 반쯤 뒤에, 윈도우 비스타와 MS 오피스 2007이 나왔을 때이다. 이제야 정신을 차린 MS가 세벌식 최종 글쇠배열 오류를 고쳐 준 덕분에, 패치 기능은 이제 더 필요하지 않았다. 하지만 글자판 자동 전환 기능이 동작하려면 바뀐 메모리 변경 지점을 알아야 했기에, 그때는 VMware로 윈도우 비스타를 급히 설치하고, 아주 가벼운 개발툴인 비주얼 C++ 4.2 (무려 1996년 프로그램!)를 설치하여 그거 디버거를 이용해 메모리 변경 지점을 알아냈다.

윈도우 7/오피스 2010의 한글 IME는 윈도우 비스타/오피스 2007의 그것과 구조가 거의 같기 때문에 파워업의 추가적인 알고리즘 패치가 필요하지 않다. 하지만 파워업을 관리자 권한으로 실행하고 나면 한글 IME 설정 대화상자가 뜨지 않으며(그쪽에서 의도적으로 실행을 거부함), 관리자 권한으로 실행된 프로그램은 파워업의 글자판 전환 기능이 통하지 않는 문제가 있었다.
새로운 이슈가 발견된 셈인데, 글자판 전환 기능이 안 되던 문제는 최근에 다행히 간단한 조치 끝에 해결하여 패치를 등록하였다. 관심 있으신 분은 받아서 사용하기 바란다.

내가 왕년에 무슨 생각으로 무슨 똘끼를 발휘하여 이런 세벌식 솔루션을 세 종류나 만들어 버렸는지 모르겠다. 세벌식을 극도로 활용한 전문적인 한글 입력기, 그리고 세벌식 beginner를 위한 타자연습, 그리고 단순 세벌식 light user를 위한 파워업. 제각기 커버하는 영역이 있다!.

공교롭게도 이 세 프로그램은 유니코드 API를 지원하는 방식도 제각기 다 다르다. 입력기는 잘 알다시피 자체 제작한 호환 레이어가 있어서 유니코드 기반 바이너리로도 9x 계열 운영체제에서 동작 가능한 가장 정교하고 바람직한 구조로 되어 있다. 타자연습은 ANSI/유니코드 에디션이 제각각 빌드되어 있고, 파워업은 그냥 ANSI 빌드로만 배포된다. 한편, 64비트 바이너리가 따로 빌드되어 배포되고 있는 건 입력기가 유일하다.

본인은 이 프로그램들이 지난 10여 년 동안 세벌식의 보급에 큰 기여를 해 왔을 거라는 자부심을 갖고 있다. 고인드립이 될까 봐 조심스럽게 하는 말이지만, 공 병우 박사님이 5~10년 정도만 더 살아 계셨으면(1995년 타계) <날개셋> 한글 입력기가 개발되는 것도 보고 가셨을 텐데 하는 약간의 아쉬움도 있다.

내가 지금까지 왜 이런 짓을 했을까? 글쎄다. 딴 게 아니고 한글 같은 문자는 컴퓨터에서 두벌식으로만 쓰기에는 너무 아깝다는 막연한 관념이 있어서였다. 그리고 한글 기계화 이념에 관한 한은 세벌식만이 살 길이라는 강한 확신이 들어서이다. 그 생각은 10년 전이나 지금이나 변함이 없다. 좀 심하게 표현하자면 이렇게까지 말할 수 있다. “그 불편한 두벌식을 쓰면서 어떻게 한글이 우수한 문자라는 말을 할 수 있을까?”

지금은 세월이 흘러, 나의 감성을 건드리는 영역은 철도에게 자리를 많이 내 줬다. 세벌식 쪽은 그냥 워낙 오래 전부터 내가 전문적으로 연구해 온 분야이기 때문에 지금까지 그저 관성만으로 덕-_-력이 유지되고 있는 것도 있다.

그러나 세벌식은 그래도 너무 매력 있는 한글 글쇠배열이며, 동시에 한글 기계화의 근간을 이루는 교리이다. 요즘은 컴퓨터도 다들 멀티코어가 대세인데, 세벌식은 내가 예전에 글로 쓴 적이 있듯이 사람 손의 병렬화-_-에 유리한 방식이다. 이 글을 보시는 분들도 다들 이 기회에 세벌식으로 글자판을 바꿔 보시길 바란다. 터치스크린이 주류인 모바일에서는 세벌식은 동시치기를 통한 활로를 적극적으로 모색되어야 하지 않을까 싶다.

Posted by 사무엘

이제는 더 말하면 입만 아프겠다만,
본인은 2003~2004년 사이에 새마을호에서 Looking for you라는 음악을 들으면서 철도 성령을 체험하고 철도 덕후의 길을 가기 시작했다.

그 Looking for you를 작곡한 사람은 MALTA라는 예명을 쓰는 일본의 재즈 색소폰 연주자이다. (☞ 공식 홈페이지) 유튜브에서 검색해 보면, 공유 정신이 투철한 네티즌들 덕분에 이 사람 주요 곡은 물론, 심지어 과거의 실황 공연 동영상까지도 어렵지 않게 찾을 수 있다.

생각보다 연세가 지긋한 분이고, 본인의 부모님 연배이다. 아니, 부모님보다 나이 더 많다..;;
일본인이라기보다는 서양 사람처럼 생겼다. 덩치도 그렇고.

공식 홈페이지에 기재된 프로필에 따르면, 그는 13세 때부터 색소폰을 불기 시작해서 도쿄 예술 대학을 졸업했다. 그 후 미국 유학을 선택하여 그 이름도 유명한 버클리(Berklee) 음대를 졸업하고 거기서 강사도 역임했다고 한다.
재즈 내지 실용 음악이 강한 학교에 잘 찾아간 듯하다. 몇 년 전에 본인이 뒷조사를 해 본 기억에 따르면, 버클리 음대 Alumni 리스트에 저 사람도 있었다.

그리고 1983년 11월, 일본에서 MALTA라는 예명으로 활동을 시작하고 첫 음반을 냈다.
Looking for you가 수록된 앨범은 Obsession으로, 1988년에 발매됐다. 즉, 여전히 상당히 초창기 시절의 작품인 것이다. 그때는 기술과 장비가 차이가 있었는지, 음반 녹음을 미국 LA에서 했다고 자랑을 치던 시절이었다. 즉, 우리가 지금 듣는 Looking for you도 원판은 미국에서 녹음됐다는 뜻.

생각을 해 보라. 어느 때에 한국의 대중교통에서, 운행 시작 전이나 종료 후에 객실 내부에서 저렇게 가슴 터질 것 같은 빠르고 경쾌하고 톡 쏘는 아름다운 음악이 흘러나왔던가? 그리고 그 당시 철도청이나 코모넷(새마을호 내부의 시청각 UI를 담당하던 하청 업체) 담당자는 어째 이렇게 매니악한 음악을 선곡할 생각을 했을까? 생각하면 생각할수록 신통방통하지 않은가?

난 재즈를 별로 좋아하지도 않는데 저 음악만은 예외로 그냥 닥치고 수백, 수천 번 듣고 또 들었다. 눈 지그시 감고 앉아서 새마을호 객실에서 저 음악 들으면서 타거나 내리던 시절을 회상하는 게 습관이 됐다. 그리고 전곡을 허접하게나마 nwc 악보로 옮겼다.

참고로 Looking for you는 새마을호에 처음으로 비디오 화면이 도입된 지 얼마 되지 않았던 2001~2002년 사이에 등장했다가, KTX가 개통한 2004년 중반부터는 종착역 도착 때만 흘러나오는 걸로 바뀌었고(출발 전에는 이제 Steve Barakatt의 Dreamers로 변경), 2007년 중반 무렵에 완전히 사라진 것으로 추정된다. 본인이 2006년에 세 차례 Looking for you 열차내 재생 장면을 촬영하여 유튜브에 올린 것은 이제 전설적인 역사 기록으로 등극해 있다.

나는 흔히 말하는 각종 가요나 연예인, 영화, 락 음악 같은 것에 전혀 영향을 받지 않은 대신, 그쪽 똘끼가 여기에 전부 쏟아졌다.
MALTA 당사자는 꿈에도 모르겠지만, 역사는 그의 음악이 한국에서 극렬 철도 덕후를 한 명 배출하는 데 결정적인 역할을 했다고 기록할 것이다. 철도님, 사랑합니다.

Posted by 사무엘