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

1. 고종 어차(1903)

황제의 즉위 무려 40주년을 기념하여 도입됐으며(참고로 영국의 엘리자베스 2세 여왕은 60년이 넘었다만..), 이게 한반도 땅에서 최초로 달린 자동차이다. 차종은 '포드 모델 A'이라는 2도어 오픈카로 추정되지만 정확한 기록이 없어서 확실치 않으며, 자동차 역사 연구자 사이에서 그게 아니라는 반론도 있다. 이런 거야말로 고종 실록 같은 데에 수록되지 않았나?

허나, 이 차는 얼마 못 가 러일 전쟁 기간 중에 소실된 관계로 현재는 전해지지 않는다. 그 시절에 자동차는 얼마나 비싼 물건이었을 텐데, 명백한 사고 폐차도 아니고 러일 전쟁 자체가 한국 땅에서 벌어진 것도 아닌데(청일 전쟁이 아님), 도대체 그 당시에 국가 자산 관리가 얼마나 막장으로 되고 있었는지 궁금해질 지경이다. 그래서 얘는 가정사로 치면, 첫째 자식보다 먼저 태어났지만 이름도 없이 일찍 죽은 형· 누나 정도의 존재감으로 취급된다.

2. 순종 어차(1913)

일제 강점기가 된 뒤에 데라우치 총독이 자기 차와 더불어 조선 황실에 대한 예우를 위해 선물해 준 차라고 한다. 1911년엔 고종 어차 시즌 2로 영국제 다임러 리무진이 들어왔고, 1913년에는 순종 어차 명목으로 더 큰 캐딜릭 8기통 리무진이 들어왔다. 고종-순종 부자가 타라고 차를 두 대 구매했으나, 실소유자는 곧 순종-왕비 부부로 바뀌었다. 도입 시기가 시기이다 보니 운전대는 명백하게 오른쪽에 있다.

이 차들에 대해서도 도입 시기에 대해서 정확한 기록이 남아 있는 건 아니다. 1911-1913년 도입이라고 하는데 다른 자료에서는 한참 나중인 1918년식이라는 얘기도 있고. 저래 뵈어도 엔진의 배기량은 5000cc가 넘는데 제원상 최대 출력은 30몇 마력밖에 안 됐다는 것 역시 참 안습하다. 지금으로부터 100년 전 자동차 기술의 한계가 거기까지였다.

그럼에도 불구하고 이 차들은 엄연히 현재까지 국내에 남아 있는 가장 오래 된 자동차 실물이다. 그리고 저 차종 자체가 오늘날까지 남아 있는 차량이 전세계적으로 극소수인데, 한국에 있는 물건은 보존 상태가 양호해서 세계 자동차 역사의 관점에서도 유물로서 가치가 대단히 높다고 한다. 6· 25 전쟁의 포화까지 견뎠을 정도이니, 얼마 타지도 못하고 흔적도 없이 사라진 고종 어차 최초 도입분과는 운명이 정반대이다.

일단 아래 사진에서 왼쪽 것이 1911년도 다임러 리무진이고 오른쪽 것이 1913년도 캐딜락 리무진이다. 범퍼와 라디에이터 그릴의 모양이 서로 미묘하게 차이가 있다.

이들은 한때는 흙 묻고 빛 바래고 먼지가 수북이 앉은 채로 창덕궁 차고에 방치돼 있었으나, 1990년대 말에 현대 자동차와 영국의 올드카 복원 전문 업체가 협력해서 표면을 광 내고 대대적으로 보수를 했다. 복원하는 덴 시간이 5년에 가깝게 걸렸으며 비용도 10억 원가량이 들었다고 한다.

복원 작업은 2001년 말에 완료됐으며, 이 덕분에 어차는 완전히 새 차처럼 변했다. 캐딜락의 경우 원래 검정이었는데 표면 도색도 빨강으로 바꾼 듯하다. 현재 이들은 경복궁 안의 국립 고궁 박물관에 전시되어 있다.
아래 사진은 캐딜락 리무진의 before과 after를 대조한 것이다. 그야말로 환골탈태를 했다. 저 차들이 191X년대에 갓 들여 온 직후에는 저렇게 반들반들 윤이 났을 것이다. 자유의 여신상이 지금 시퍼렇게 녹이 슬었다고 해서 그게 처음 만들어지던 당시에도 퍼렇지는 않았으며(동상은 원래 갈색· 구리색임), 옛날 사진이 지금 누렇게 바래 있다고 해서 옛날 그 당시의 풍경 자체가 누렇게 바랬던 건 아니듯이 말이다.

3. 김 일성 리무진

이것은 다름아닌 북한의 수괴인 김 일성이 몰고 다니던 승용차이다. 우리나라에 남아 있는 유일한 구소련 시절의 자동차이다.
구소련이라 하면 총(AK47!)과 비행기(AN-??)와 우주선은 만들었어도 정작 고유 모델 자동차를 만들었다는 정보는 영 생소하다. 저건 ZIS 110이라는 모델로, 1948년에 김 일성이 스탈린으로부터 선물받았다고 한다.

김 일성은 이 차를 즐겨 몰고 다녔다. 6· 25 전쟁 중에는 안전한 후방에서 보고나 받고 명령만 내린 게 아니라, 경북 왜관까지 남하해서 전선을 시찰하고 북한군 병사들을 지휘했다고 한다. 고속도로도 없던 와중에 참 멀리까지도 내려왔다. 낙동강을 사수하네 마네 하던 리즈(?) 시절엔 그야말로 한반도 전역의 적화통일이 코앞에 있다고 생각했을 것이다.

그랬는데 1950년 가을, 인천 상륙 작전으로 인해 전세가 역전되었고 김 일성은 시급히 후퇴를 해야 했다. 평양까지 빼앗기고 계속 북으로 올라가야 하는데, 앞은 강으로 가로막혀 있고 다리가 없고 차량으로는 도저히 건너갈 수가 없었다. 다른 길로 뺑뺑이를 칠 수도 없고.. 그래서 김 일성은 (아마 눈물을 머금고) 자기 애마를 어쩔 수 없이 버리고 도망쳤다고 한다. 난 차량이 남한에서 노획되었는 줄 알고 있었는데 그건 아니었다.

이 차량은 1950년 10월 22일, 평양에서 동북쪽으로 약 100km쯤 떨어진 청천강 근처에서 남한 국군(6사단 수색대)에 의해 발견되고 노획됐다. 국군이 38선을 최초로 넘어서 국군의 날이 시초가 된 10월 1일 이후로 정확히 3주 만의 일이다.
이걸 최초로 발견하고 신고한 병사가 누군지를 인터넷에서 본 기억이 있는데, 검색은 더 귀찮아서 안 하련다. 그 병사는 당연히 큰 포상을 받았다.

김 일성의 리무진은 대한민국의 국고로 귀속됐다. 김 일성은 차만 버렸지 차키까지 놔 두지는 않았겠지만, 그 시절의 옛날 차들은 지금 같은 첨단 이모빌라이저가 있는 것도 아니고, 스타터 모터의 배선만 연결하면 강제 시동 정도는 얼마든지 가능했을 것이다.

그런데 이 차가 그때 이후로 줄곧 한국에서 애지중지 보존되어서 반공 안보 교육(?) 아이템으로 쓰였느냐 하면 그렇지는 않다.
이 승만 대통령은 1951년, 미 8군 사령관이던 월튼 워커 장군의 부인에게 이 차를 선물로 줬다. 워커 장군은 잘 알다시피 1950년 12월에 크리스마스를 앞두고 교통사고로 한국 땅에서 순직했기 때문이다(교전 중 전사는 아니고..).

부인 되시는 분은 샌프란시스코에서 차를 인수했지만 차는 곧 고장 났다. 냉전 중에 미국에서 적성국인 구소련제 차량은 부품을 구해 유지 보수를 하기도 어려웠던 관계로, 그녀는 차를 또 처분해 버렸다. 그렇게 김 일성 리무진은 미국 땅에서 정처 없이 30년 가까이를 방황했다고 한다. 그 과정에서 차가 사고가 나고 폐차됐다면 김 일성 리무진은 세상에서 영원히 사라졌을 것이다.

그랬는데 사단법인 유엔 한국 참전국 협회라는 단체에서(대표: 지 갑종) 1970년대에 백방으로 수소문을 한 끝에 이 차의 소재를 미국에서 찾아 냈으며, 뉴저지에 소재한 어느 자동차 수집상으로부터 거금을 주고 1982년에야 그 차를 한국으로 도로 역수입을 해 왔다. 먼 나라로 수출되었던 포니가 20여 년 뒤에 드라마 촬영을 위해 도로 역수입된 것처럼. 그때 고맙게도 대우 그룹 김 우중 회장이 재정적인 지원을 해 줬다고 한다.

또한, 그때 이래로 지 회장이 러시아 엔지니어까지 초청해서 관리를 잘 한 덕분에, 김 일성 리무진은 현재도 간단한 정비만 하면 곧장 주행이 가능할 정도로 상태가 좋다고 한다. 이분은 6· 25 전쟁 휴전 60주년을 얼마 남기지 않았던 2013년 7월 16일, 차량을 전쟁 기념관에다 기증했다. 덕분에 우리는 전쟁 기념관에서 김 일성 리무진과 동시에 곧 소개할 이 승만 리무진도 나란히 관람할 수 있다.
참고로 6· 25 전쟁을 계기로 김 일성은 자기 애마뿐만 아니라 강원도 고성에 있던 자기 별장도 빼앗겼다.

4. 이 승만 리무진

김 일성 차량에 비해 이 승만 리무진은 설명할 게 훨씬 없다. 1956년에 미국 아이젠하워 대통령으로부터 선물받은 의전용 방탄 캐딜락이다. 그러므로 전쟁 중에 굴러다닌 건 아님. 애초에 이 승만은 6· 25 때 피난도 자차가 아니라 열차를 타고 갔다.

얘는 어차처럼 창덕궁에서 보관되어 오다가 2000년부터 전쟁 기념관으로 옮겨져 전시되었으며, 2013년경에는 역시 때 빼고 광 내는 부분적인 복원 작업을 거쳤다고 한다. 이 작업은 당연하지만 구한말 어차를 복원하는 것만치 힘들고 오래 걸리지는 않았다.
그래서 이 차 역시 당장 시동 걸고 주행이 가능할 정도로 정태를 넘어 동태보존 상태라고 한다.

Posted by 사무엘

텍스트를 입력· 편집하는 기능을 제공하는 에디터나 개발툴, 워드 프로세서에는 응당 텍스트를 검색하는 기능이 있다.
찾기 명령은 아무래도 바꾸기 명령과도 같이 쓰이는 경우가 많으니 이건 편집 기능의 일종으로 간주되며, 보통은 '편집' 메뉴의 하위 항목으로 들어가는 편이다.
그러나 편집 메뉴가 이미 다른 기능들로 너무 비대한 상태이거나, cursor를 원하는 조건대로 이동시키는 찾기/탐색 기능이 별도로 굉장히 전문적으로 발달해 있는 경우, '검색(Search)'이라는 메뉴가 따로 존재하기도 한다.

이 메뉴 구성은 프로그램들마다 제각각이다.
과거에 아래아한글은 1.x대까지 '찾기' 메뉴가 별도로 있다가 2.1부터 '편집'으로 들어갔다. 전반적으로 기능들이 메뉴에 많이 추가되면서 두 메뉴의 인수 합병에 정당성이 생긴 것이다.
Windows의 메모장은 9x 계열의 것은 '찾기' 메뉴가 존재하는 반면, 2000/XP의 것은 그렇지 않고 '편집' 메뉴에 있다.

<날개셋> 편집기는 1~2.x대까지는 찾기 기능이 '편집' 메뉴에 있었지만, 3.0부터는 별도의 '검색' 메뉴로 분리되어 지금에 이르고 있다. 검색과 관련된 기능들을 전부 편집에다가 몰아 넣으면 보기, 삽입, 도구 같은 다른 메뉴들에 비해 '편집'만 항목 수가 너무 많고 비대해지기 때문이다.
그렇다고 <날개셋> 편집기가 무슨 메모장만치 그렇게 기능이 적은 초소형 프로그램도 아니니.. 양 극단 사이에서의 고민 끝에 지금과 같은 메뉴 배치를 선택했다.

한편, 내 편집기에는 없지만 좀 기능깨나 있다 싶은 텍스트 에디터들은 Find in files 기능이 필수이다. 그런데 알고 보면 얘의 정체성도 약간 오락가락 하는 편이다.
아래아한글은 2.0에서 이 기능이 최초로 추가된 이래로 요게 '파일' 메뉴에 쭉 있어 왔으며, Visual C++ IDE도 옛날 버전에는 한동안 파일 메뉴에 있었다. 아무래도 한 문서를 편집한다기보다는 inter-file스러운 기능이라고 생각하고 그렇게 '파일'에다 분류했던 듯하다.

하지만 Visual C++의 경우 6인가 닷넷 이후부터 이 기능은 '편집' 메뉴로 이동했으며, IDE의 버전이 올라갈수록 요건 기존 '찾기' 기능의 자연스러운 연장선 형태로 인터페이스가 바뀌어 왔다는 게 주목할 점이다.
물론 '검색' 메뉴가 별도로 있는 에디터라면 Find in files는 응당 파일도 편집도 아닌 그 메뉴에 자리잡고 있다.

프로그램의 전반적인 옵션을 지정하는 명령이 요즘은 도구 메뉴의 맨 마지막에 있는 게 대세이지만, 한때는 preference라는 이름으로 파일 메뉴에 있기도 하고 Adobe Reader처럼 아예 편집 메뉴의 있기도 한 것과 비슷한 모습을 보는 것 같다. 옛날에는 역시 '옵션'이라는 메뉴가 별도로 있기도 했지만 프로퍼티 시트의 등장으로 인해 한 대화상자에서 엄청 많은 옵션들을 죄다 몰아서 지정하는 게 트렌드가 되면서 옵션만을 위한 메뉴는 요즘 UI 트렌드에서는 사라지는 추세이다.

끝으로, 이 검색 메뉴가 존재한다면 그 위치가 어디쯤인지를 살펴보고자 한다. 파일이야 맨 먼저 등장하는 것이 불문율이지만, '보기', '삽입(입력)' 같은 다른 메뉴와 비교했을 때 상대적인 순서가 어떻게 될까?
앞서 말했듯이 찾기 기능은 편집과 밀접한 관계가 있기 때문에 아무래도 편집 메뉴의 바로 다음에 오는 것이 가장 자연스러워 보인다.

그래서 실제로 검색 메뉴가 따로 존재하는 많은 프로그램들은 "파일-편집-검색-(보기)"의 순으로 메뉴가 구성되어 있다. NotePad++, Source Insight, 그리고 도스와 Windows용을 막론하고 볼랜드 IDE (Borland C++, C++Builder, 델파이), AcroEdit 등.

그런데 <날개셋> 편집기는 "파일-편집-보기-검색"으로, View 메뉴가 더 앞에 있다. 검색 메뉴가 처음으로 추가되었던 3.0 초창기 시절에는 "검색-보기"이었는데 나중에 모종의 이유로 인해 "보기-검색"으로 바뀌었다.
"검색-보기"가 적힌 과거의 흔적은 까마득히 먼 옛 버전을 기준으로 만들어진 프로그램 스크린샷 움짤들을 보면 확인할 수 있다.

"보기-검색"으로 순서를 바꾼 이유는 아마 본인이 옛날에 개발 과정에서 참고했던 EditPlus가 "보기-검색" 순이어서 그랬던 것 같다.
그리고 또 흥미로운 것은, 마소에서 만든 도스용 QBasic과 QuickBasic, 그리고 후대 버전인 QBX (MS Basic PDS 7), 도스용 비주얼 베이직 그쪽 라인은 역시 "보기-검색"이다.

그 반면, Windows 95와 그 이후에 새로 등장한 MS-DOS 에디터는 "검색-보기"로 돌아갔다. 대화상자에 선문자가 없는 그 프로그램 말이다.

원론적으로 따졌을 때 "검색-보기"가 더 자연스러우며 그 역순은 EditPlus와 QBasic 계열 같은 예외적인 프로그램에서밖에 존재하지 않는다는 점을 근거로, <날개셋> 편집기도 이번 8.4부터는 다시 "보기-검색"이 아니라 "검색-보기"로 복귀했다.
이 조치를 내리기 위해 저런 리서치와 고민이 있었음을 이 자리에서 밝힌다. ^^

Posted by 사무엘

자동차라는 물건은 차체의 크기와 엔진의 배기량 같은 전반적인 규모를 기준으로 분류할 수 있고, 같은 규모라면 사람을 태우는 것과 화물을 싣는 것을 각각 얼마만큼 비중을 뒀느냐에 따라서도 여러 종류로 분류할 수 있다. 사람에 초점을 두면서 덩치가 커지면 버스가 되고, 화물에 초점을 두면서 덩치가 커지면 트럭이 된다.
그런데 전문적인 트럭이나 버스로 불리기에는 작은 승용차급 크기에서도 생각보다 다양한 차종이 존재한다.

가장 흔한 건 5명이 타고 짐은 뒤의 트렁크에 싣는 '세단'이다. 세단은 객실과 화물칸이 완전히 분리되어 있어서 정숙성 면에서 좋다. 그러나 짐을 높이 쌓기 어려우며, 이런 화물칸에다가 성인용 자전거 같은 건 접지 않은 이상 아무래도 실을 수 없다.

옛날에는 해치백이라고 뒷부분에 위로 열리는 문이 달린 차량이 있었다. 우리나라 최초의 고유 모델 승용차라는 포니부터가 해치백이었고, 그 뒤에 르망이나 프라이드(초기 모델)도 해치백이었는데 요즘 국내에서는 해치백 승용차는 거의 찾을 수 없게 됐다. 해치백은 통상적인 승용차보다 더 큰 SUV의 전유물이 된 듯하다.
해치백은 세단처럼 뒤에 뭔가 돌출된 부위가 없다 보니, 유체역학적으로 볼 때 뒷유리에 먼지가 더 잘 쌓이고 더러워지기가 쉽다. 그래서 뒷유리에도 와이퍼가 달려 있다.

요런 5인승 승용차/SUV급 체형에다가 뒤에 트럭처럼 짐받이도 장착된 차량을 특별히 '픽업트럭'이라고 하는 것 같다. 미국 시골에서는 도시에 사는 사람들처럼 평범한 세단형 승용차가 아니라 픽업트럭이 자가용으로서 인기가 많다고 한다.
험지를 종종 달려야 하니 차체가 크고 튼튼할 필요가 있으며, 땅 넓고 길 넓고 단독 주택에 자기 차고도 있고, 기름값 싸고 배기량 규제도 없으니 큰 차 굴리는 것에 대한 부담이 없다. 그리고 한편으로 인건비가 비싸서 어지간한 가사노동은 스스로 해야 하기 때문에.. 이사 갈 때처럼 짐을 많이 실을 일 있을 때도 용달차를 부르기보다는 자차로 일을 직접 처리해야 한다.

이러니 미국의 시골 문화에는 큼직한 픽업트럭이 어울린다. 영화 <킬 빌>에서 빌의 동생 버드는 사막 한가운데의 어느 컨테이너에서 살았던 한편으로 자가용이 픽업트럭이었던 것이 기억에 남아 있다.

그에 반해 우리나라는 자동차 문화라는 것도 참 가난하고 열악하고 배고픈 여건 속에서 태동했다. 수출을 위해서 무작정 중공업을 육성했는데, 그래도 외화는 목숨 걸고 아끼려고 기름값에 세금 왕창, 자동차 배기량에 세금 왕창..;; 고위 공무원들의 관용차에도 4기통보다 더 큰 차는 금지시켰을 정도다. 또한, 소비자에게만 규제를 넣은 게 아니라 심지어 자동차 제조사에도 생산 가능한 자동차의 종류까지 규제를 했다.

그러니 국내에서 생계형 미니 용달 화물차는 기아 자동차의 전신인 기아 산업에서 만든 삼륜차부터 시작했다. 삼륜차는 내가 몇 차례 예전 글에서 소개한 바 있으니 이 자리에서 사진 첨부는 생략하겠다.
그 후 1974년에 기아에서는 잘 알다시피 '브리사'라는 승용차를 내놓았는데, 사실은 그 전 1973년 여름에 베타테스트 명목으로 브리사의 전신인 픽업 트럭을 먼저 내놓은 적이 있었다. 브리사는 상용차부터 출시된 뒤에 그걸 베이스로 나중에 만들어진 승용차였던 것이다.

현대 자동차에서 나온 포니 역시, 앞좌석까지만 동일하고 뒷부분은 짐받이로 대체된 픽업 트럭 에디션이 응당 있었다. 최대 적재는 400kg 남짓까지 가능했다.
포니나 SMC 덤프트럭 같은 옛날 차들을 보면 엔진룸은 요즘 자동차보다 더 길고 각지게 돌출돼 있는데, 정작 뚜껑을 열어 보면 들어있는 부품은 생각만치 조밀하지 않고 듬성듬성해 보이는 게 인상적이더라.

또한 화물차이긴 한데 천장이 있고 외형은 승용차와 동일한 일명 3도어 '밴' 에디션도 있었다.
포니 이후에 엑셀까지 밴 에디션이 있었던 걸로 기억한다. 사진 첨부는 귀찮은 관계로 생략하겠다.
엑셀은 포니와는 달리 원래 세단인데 밴은 해치백? 쿠페? 스타일이니 이것도 인상적이었다.

기아와 현대에서 픽업트럭을 내놓는 동안 대우 자동차도 가만히 있지는 않았다. 아래의 요놈은 휠 모양을 보아하니 맵시나 기반인 것 같은데 내가 어렸을 때 실물을 보지는 못했다.

사실은 이것보다도 내가 더욱 신기하게 여기는 추억의 자동차는 바로 이것이다.

얘는 승용차의 픽업트럭 파생 에디션이 아니라, 아예 트럭에 더욱 근접해 있는 형태이다. 앞부분은 엔진룸이 돌출돼 있고 좀 승용차처럼 생겼지만, 그래도 앞의 차체와 뒷바퀴 휀다는 짐받이와 완전히 분리되어 있어서 짐받이는 후면뿐만 아니라 측면까지 모두 열어 젖힐 수 있다. 일반 트럭처럼 말이다. 승용차로 치면 딱 봐도 그랜저/쏘나타급의 중대형의 덩치이고 적재 용량 역시 7~800kg에 달했다.

실제로 엔진의 배기량도 2000cc급이었고, 휘발유가 아니라 '디젤' 엔진 기반이었으니 더욱 트럭에 가깝다. 걍 1톤 트럭의 약간 마이너 버전이다. 크고 무거운 디젤 엔진을 승용차에다 얹으려다 보니 그 당시 기술로는 부득이하게 중앙이 불룩 튀어나온 전용 보닛이 필요해진 것이다.

새한/대우 자동차는 독일 오펠 사로부터 수입한 승용차용 디젤 엔진을 얹기도 했기 때문에 국내 자동차 역사에서는 디젤 승용차의 원조라는 기록을 보유하고 있다. 그 당시의 현대/기아 계열에서는 찾을 수 없는 기록이다. 그러니 픽업 트럭 역시 휘발유 에디션(흰 놈. 제미니/맵시나 기반)과 디젤 에디션(파랗고 더 크고 엔진이 불룩한 놈. 로얄 디젤 기반)이 모두 존재했다고 한다.

요놈은 그 당시 웬일로 '맥스'라는 차명이 붙었으며, 1988년까지 생산되다 단종됐다.
본인은 25년 가까이 전의 어린 시절, 집에서 피아노를 구입했을 때 피아노가 바로 이 맥스 픽업트럭의 짐받이에 실려서 오는 걸 본 기억이 있다. 그 차의 색깔도 딱 저런 파란색이었다. 그 피아노는 2016년 현재, 아직도 본인의 고향집에 있다.

그에 반해 요즘은 트럭은 기본이 1톤 단위로 시작한다. 그것보다 더 작은 '경상용차'는 국내 유일의 경상용차인 다마스와 라보가 사실상 독식하고 있는 걸로 안다. (적재 하중 550kg)
경차에게 주는 법적 혜택이 워낙 독보적인 관계로, 이 차량은 비록 자동차 회사 입장에서 마진이 남는 건 별로 없지만 그래도 생계수단 장사 밑천으로서 기본적인 판매 수요는 절대보장이다.

다만, 원가 절감을 위해 자동 변속기, ABS, 에어백, 자세제어, 그딴 거 하나도 없..다. 안전 테스트도 결과에 관계없이 단종돼서는 안 되는 차량이라고 꾸준히 열외· 면제-_-돼 왔고, 사고 시에 연료가 새는지, 디젤 엔진이 배기가스 기준을 충족하는지 이런 것만 검사를 받아 왔다. 뭐 현실이 그렇다.

그러고 보니 트럭 중에도 옛날에는 포터에 1.25톤짜리 바리에이션이 있었고, 기아의 점보 타이탄 중에는 1.4톤 모델이 있어서 오늘날 1톤과 2.5톤 사이의 간극을 메우고 있었는데 요즘은 그런 걸 찾을 수 없다. 엔진음이 여자 톤에서 남자 톤으로 바뀌는 과도기적인 체급이었던 걸로 기억한다.
이상. 오늘은 소형 트럭 쪽에서 특별히 픽업트럭를 중심으로 옛날 차들을 회상해 보았다.

Posted by 사무엘

1.
국내 고속도로계에서 독보적으로 낙후한 이단아이던 88 올림픽 고속도로는 지난 2015년 말에 드디어, 드디어 전구간이 4차선으로 확장되었으며 이름도 '광주대구 고속도로'라고 바뀌었다. 솔직히 이 도로는 착공· 건설 시기가(개통 시기가 아님.) 올림픽 유치에 성공한 시기와 비슷할지 몰라도, 지리적으로는 올림픽과 정말 아무 상관도 없었으니까..

중앙분리대조차 없이 2차선이던 이 고속도로는 설계 최대 속도도 100이 아닌 80km/h이었으며, 중앙선을 침범하여 앞차를 추월하다가 마주 오던 차와 정면 충돌하는 사고가 잦아서 교통사고 발생 빈도 내지 사고 사망률이 여타 고속도로들보다 몇 배로 더 높았다. 백괴사전에서는 "44(死死) 내림픽 저속도로"라고 개드립을 치면서 깠을 정도다.

주행 여건이 다른 고속도로들은 물론이고 어지간히 리모델링된 국도보다도 열악했던 관계로, 한국 도로 공사는 여기 구간의 통행료는 여타 고속도로의 반값 정도로만 징수했다. 서울 지하철이 '최소 거리 이용 추정의 원칙'에 의거하여 요금을 측정하듯, 고속도로 톨비 역시 비록 진입과 최종 진출 나들목 자체가 88 내부의 나들목이 아니더라도 경로상으로 88을 이용했을 만한 위치라면 그걸 감안하여 산정되지 않았을까 싶다.

그러다가 이 도로도 찔끔찔끔 선형 개선과 확장, 이설 공사를 되풀이했으며, 그게 드디어 작년 말에 종지부를 찍었다. 그리고 이와 동시에 오랫동안 존속해 온 통행료 특별 할인도 폐지됐다.

전국의 고속도로 나들목들 중 유일하게 평면교차+비보호 좌회전(고속도로에서!)이라는 엽기적인 형태로 남아 있던 '남장수 IC'는 해당 구간이 대거 이설되면서 없어졌다. 이를 대체하는 동남원 IC가 생기긴 했지만 저기서 서쪽으로 수 km 떨어진 곳이다. 남장수 IC가 없어진 건 철도로 치면 전국에서 유일하게 남아 있던 스위치백이라든가 통표 폐색 구간이 없어진 것과도 같다고 볼 수 있다.

사실 옛날에는 이 88 말고 다른 고속도로도 이름만 고속도로이지 2차선에 평면교차 같은 막장 시설인 경우가 종종 있었다. 호남 고속도로, 영동 고속도로 따위도 처음엔 그랬다.
심지어 1990년대에 대구와 원주를 잇는 중앙 고속도로조차도 처음엔 2차선으로 건설되고 있었는데 감사원에서 이를 잡아 냈다. "이렇게 만들었다간 99.9% 나중에 또 확장하느라 더 고생하고 돈과 시간을 더 낭비하게 된다. 지금이라도 설계를 갈아엎고 다시 만들어라. 그리고 이를 선례로 삼아 앞으로 새로 만드는 모든 고속도로들은 처음부터 반드시 4차선 이상 크기로 건설해라."라는 현명한 지시를 내려서 개선이 됐다.

저렇게 1990년대에도 2차선으로 건설될 뻔한 고속도로가 있었는데 1960년대 말 그 옛날에 처음부터 전구간 4차선으로 시작을 했던 경부 고속도로의 건설 과정이 문득 더 드라마틱하게 느껴진다. 출처는 정확히 알 수 없다만 그 시절에 박통이 이미 "내가 야당이 하도 반대해 대서 일단은 4차선으로만 건설하지만 경부 고속도로는 얼마 못 가 분명히 비좁아질 거다. 확장을 하게 될 테니 도로 주변에 건물 건설 허가를 내지 말고 준비를 해 둬라" 이런 예고까지 했다고 한다.

경부 고속도로가 유지 보수 비용이 결국 건설 비용만큼이나 더 들었다고 회자되긴 한다만, 그건 다른 고속도로들도 훗날 꾸준히 개선되어 온 건 대동소이했다. 허나 88은 박통도 아니고 나름 5공 시절인 1980년대에 건설된 주제에 오랫동안 개선되질 못해서 까임거리가 된 것이다. 영호남 화합? 실질적인 수요보다는 정치 논리에 따라 건설됐다 보니 리모델링의 우선순위도 뒷전으로 밀려 있을 수밖에 없었다. 그래도 이것도 이제 다 지나간 일이 됐으니 그나마 다행이다.

88 올림픽 고속도로에 이어, 철도 경전선도 올해는 대대적인 선형 개량 공사가 끝나서 여러 구간이 이설되고 여러 간이역들이 없어질 예정이다.
자, 다음부터는 철도 얘기를 주로 늘어놓도록 하겠다.

2.
과거에 20세기 말에 우리나라의 최하등급 열차는 비둘기호였다. 정선선에서 운행하다가 2000년 11월 14일을 끝으로 퇴역했다.
객차형 비둘기호는 너무 싸서 수지맞지 않은 운임 체계, 너무 낡고 노후화한 객차 같은 여러 이유로 인해(비산식 화장실, 수동 출입문, 별도의 발전차 없이 객차가 차축 연결해서 소규모 자가발전-_-, 에어컨도 없음..) 21세기에까지 존속하기란 도저히 불가능하긴 했다.

그 다음으로 통일호도 객차형은 차량이 비둘기호 만만찮게 열악했던지라 2004년 3월 31일, KTX 개통을 앞두고는 모두 퇴역했다. 근성열차라고 불리던 청량리-부전 통일호가 이때 사라졌고 경춘선도 통일호가 모두 무궁화호로 바뀌면서 사실상 운임이 강제로 일괄 인상된 효과도 났다.

나머지 디젤 동차형 통일호는 '통근열차'라고 이름이 바뀌었는데, 얘들은 진해선, 동해남부선, 군산선 등에서 명맥을 유지하다가 차근차근 무궁화호로 교체되면서 명줄이 위태로워졌다. 기관차-객차형처럼 차량이 완전히 다른 무궁화호 말고, CDC 객차 자체가 일명 RDC 무궁화호로 개조되기도 했다.

현재 통근열차의 최후의 보루는 서울에서 북쪽으로 가는 경의선과 경원선밖에 안 남았다. 허나 경의선에서는 이미 진작에 전철에 밀려 퇴출되었으며, 현재 전국에서 오리지널 CDC가 다니는 곳은 이제 소요산 이북의 경원선이 유일하다! 과거에 정선선 비둘기호와 비슷한 꼴이 된 셈이다. 비둘기호:정선선 = 통근열차:경원선 정도의 비례식임.

2019~2020년쯤에 수도권 전철 1호선이 약 빨고 더 연장되어 연천까지 가 버리면 이제 CDC는 완전히 역사 속으로 사라질 것이다. 더 북쪽의 잔여 구간은 지금 경의선이 그런 것처럼 안보 관광 열차가 대신 맡을 것이고.

물론 경원선 연장 구간은 전철이 들어간다고 해도 일단은 복선 노반만 확보해 놓은 '단선 전철' 형태로 운행될 예정이다. 그런데 복선 구간 운행이 너무 당연시되는 지하철 통근형 전동차가 갑자기 단선 구간에서 상하행 교행을 한다니 그것도 참 흥미진진한 구경거리가 될 것 같다. 하긴, 천하의 KTX도 과거에 광주 역을 드나들 때는 꼬불꼬불 단선 구간을 다니긴 했다.

3.
21세기 이래로 경기화학선, 세풍제지선, 화순선 등 여러 산업· 화물 철도들이 소리소문 없이 열차 운행과 관리가 중단되고 사실상 폐선 테크를 타 왔다.
하지만 화물 분야에서 철도가 마냥 몰락만 하고 있는 건 아닌지라, 지난 2010년 말에는 부산신항선이라는 걸출한 화물 철도가 개통했다. 그것도 복선으로. 여객이 아니고 항구 화물 전용 철도이다.

그리고 그로부터 5년쯤 뒤, 작년에는 이와 비슷한 맥락으로 평택에서 평택항으로 향하는 화물 철도가 또 신규 개통했다. 이름하여 평택선. 경부선과 연결하는 삼각선도 상하행으로 모두 만들어졌기 때문에 아무 방향으로나 통한다.

경부선 전철에서 성환-평택은 충청도와 경기도의 경계이기도 하고 역간거리가 무려 9km가 넘는다. 공항 철도를 제외하면 수도권 전철에서 역간거리가 가장 긴 구간임에도 불구하고, 사이엔 온통 들판에 소규모 마을밖에 없기 때문에 역이 만들어질 여지가 별로 없다.

평택 다음 성환 역에도 사이에 웬 지선 철도가 서쪽이 아닌 동쪽으로 뻗어 나간다. 이건 하행 방향으로만 있고 서울 상행 방향은 없는데, 다름아닌 성환읍 학정리의 야산 하나를 몽땅 차지하고 있는 거대한 군부대로 향하는 비밀 철도이다. 서빙고 역에서 미군 기지로 들어가는 그 철도, 그리고 호남선에서 논산 육군 훈련소 방면으로 가는 강경선 같은 걸 떠올리면 되겠다.

관련 신문 기사들을 검색해 보면 그 군부대는 탄약창인가 보다. 탄약은 굳이 사방으로 파편이 날리는 수류탄 같은 부류가 아니더라도, 내부에 다 화약이 들어있는 위험물이다. 한 탄약고가 공격을 받아 폭발하면 인근의 다른 탄약고까지 연달아 재귀적으로-_- 폭발하면서 Doom 2의 레벨 23 Barrels o' fun이 실사판으로 재연되는 참극이 벌어질 수 있다.

이런 스플래시 대미지를 예방하기 위해 탄약창은 최대한 넓게 띄엄띄엄 지어진다고 한다. 그래서 탄약창의 부지가 굉장히 크다. 다만 여기에 땅을 갖고 있던 사람들은 국가로부터 눈꼽만 한 보상밖에 못 받고 오랫동안 재산권을 제대로 행사하지 못하면서 꽤 고달프게 지냈다고 한다.

4.
그 밖에 작년에 있었던 의미 있는 사건으로 또 떠오르는 건.. 서울 역과 노량진 역에 정식 환승 통로가 개통했다는 것이다.
버스와는 달리 지하철은 내렸다가(=집표 구역 밖으로 나감) 다시 탔을 때 환승 할인이 없는 것이 원칙이다. 하지만 서울 지하철 9호선이 개통한 뒤에도 노량진 역에는 물리적인 환승 통로가 존재하지 않았으며, 공항 철도와 경의선도 기존 지하철 1· 4호선 서울 역과는 연결되어 있지 않았다. 그래서 거기는 수도권 전철 전체를 통틀어 예외적으로 철도끼리 내렸다가 30분 이내에 다시 타도 환승 할인이 인정되게 되었다. 일명 소프트 환승이다.

사실, 지금은 찍고 나간 동일 게이트에 5분 이내에 다시 들어가도 1회에 한해 기본 운임 재징수 면제라는 예외까지도 추가돼 있다. 이런 것들도 다 소프트웨어로 이론적으로는 얼마든지 다 구현 가능한 건데 굳이 일을 복잡하게 만들 필요가 없으니 막아 놓았던 것이다.

지금이야 5년도 더 전에 환승 통로가 개통했지만, 2010년 이전엔 '국철/중앙선' 청량리 역과 서울 지하철 청량리(1호선) 역도 마치 경의선 신촌과 지하철 신촌(2호선)만큼이나 환승이되지 않았고 별개의 역으로 취급되곤 했다. 또한 서울 지하철 6호선이 갓 개통했을 때에도 신당 역은 2호선과의 환승 통로가 아직 완공되지 않아서 몇 달간을 환승이 안 되는 역으로 영업을 했었다. 이때엔 소프트 환승 같은 건 없었다.

서울 역의 경우 지하철과 공항 철도가 정말 도를 지나칠 정도로 너무 멀리 떨어져 있었던 관계로, 수직 이동 삽질을 줄이고 수평 이동도 무빙워크로 도와 줄 환승 토로가 정말 절실했다. "현기증 난단 말이에요, 환승 통로 만들어 주세요" 급이었다. 그래서 작년 3월에 먼저 개통했다.
한편, 노량진은 민자역사의 건설과 맞물려서 환승 통로의 개통이 한없이 늦어졌다. 이건 마치 분당선 야탑 역과 인근 버스 터미널과의 통로 개통과도 비슷한 문제였던 것 같다. 둘 다 어른들의 사정 때문에 일이 늦어졌고 그 동안 승객들만 불편을 겪었다는 점에서 공통점이 있다. 그래도 작년 10월 말에 환승 통로가 생기긴 했으니 다행스러운 일이다.

이렇게 물리적인 환승 통로가 뚫린 덕분에, 그와 동시에 지금까지 두 역에만 존재하던 소프트 환승 예외 로직은 폐지되었다. 마치 88 올림픽 고속도로가 리모델링이 완료되면서 반값 통행료 제도가 없어진 것과 같은 이치다.

단, 서울 역에 있는 4개 전철 노선 중 경의선은 여전히 여타 노선들과 단절되어 있으며, 여기는 수도권 전철에서 유일하게 소프트 환승 예외가 계속 유지된다. 1시간에 1대밖에 안 다니는 마이너 지선에까지 굳이 환승 통로를 뚫을 필요를 느끼지는 않았기 때문이다. 서울-신촌은 아주 유니크한 구간으로 그렇게 명맥이 유지될 것 같다.

Posted by 사무엘

이건 개인적으로 오래 전부터 알고 있었던 사소한 옛날 추억 아이템인데, 지금까지 한 번도 공개적으로 언급한 적이 없었던 관계로 털어놓고자 한다.

Windows에 메모장은 1.0 시절부터 있었던 터줏대감 기본 프로그램이다. 기본 윈도우 프레임 껍데기에다 운영체제의 내장 에디트 컨트롤 하나만 달랑 얹은 극도의 최소주의 형태이다. 세월이 흐르면서 워드패드와 그림판은 리본 UI가 탑재됐고 계산기도 아주 화려한 UI로 리모델링된 마당에, 메모장만은 외형이 거의 바뀐 게 없다.

Windows 프로그래밍 공부를 한 사람이라면 메모장 정도는 하루 정도만 투자하면 동일 프로그램을 직접 만들 수도 있을 것이다. 아니, 있는 그대로 복제품만 만드는 건 너무 시시하고, MDI 정도는 지원하게 확장해서 만들기도 한다. 지금도 있는가 모르겠는데 비주얼 C++의 MFC 예제에는 MultiPad라고 실제로 메모장의 MDI 버전도 소스 코드와 함께 제공된 바 있다.

그런데 Windows 95부터 ME까지 9x 계열의 메모장은 '도움말'이라는 메뉴 명칭의 뒷부분에 출처를 알 수 없는 공백이 하나 더 들어가 있었다. 아래 스크린샷을 참고할 것. 계산기의 '도움말'과는 달리, 메모장의 '도움말'은 파란색이 조금 더 긴 게 보일 것이다.

더욱 신기한 건, 98과 ME로 버전이 올라가도 상황이 바뀐 게 없었다는 점이다. 그것도 한글판과 영문판 공히.
메모장이 아무리 최소주의 기본 프로그램이었다고 해서 그 시절 동안 변화가 전혀 없었느냐 하면 그렇지는 않았다. 보다시피 아이콘 모양이 바뀌었으며 본문의 글꼴을 변경하는 기능이 98에서 추가되었다. 코드뿐만 아니라 리소스 쪽도 검수할 기회가 있었는데 저 문자열의 뒤의 공백은 여전히 제거되지 않은 채 남았다.

그 반면, Windows 2000의 메모장은 그렇지 않다.

ME는 2000보다 나중에 나왔음을 감안한다면, 같은 메모장도 NT 계열의 것과 9x 계열의 것은 코드와 리소스가 정말로 한데 공유된 구석이 없었다는 걸 알 수 있다. 같은 소스에서 조건부 컴파일을 한 것조차도 아닌 듯하다.

심지어는 도움말도 둘 다 완전히 다르게 따로 만들어졌다. Windows ME의 메모장 도움말은

이라고 사용자에게 당장 필요한 task 지향적인(use, using) 설명 위주인 반면.. Windows 2000의 메모장 도움말은

이라고 프로그램의 정체성에 대해서 더 사무적이고 격식을 차린 문체로 시작한다.

메모장은 아주 단순한 프로그램이지만 9x 계열의 것과 NT 계열의 것이 기능상의 차이도 꽤 크다. 후자는 (1) 유니코드를 지원하며 (2) 64KB 이상 크기의 파일도 열 수 있다. 다시 말해 전자는 "파일이 너무 큽니다. 워드패드에서 여시겠습니까?" 이런 로직이 존재하며, 지금으로서는 상상하기 어렵지만 UTF8 방식 텍스트를 읽고 쓰는 것조차도 지원하지 않았다.

물론 운영체제의 에디트 컨트롤이라는 건 리치 에디트와는 달리 아주 방대한 텍스트를 편집하는 데는 최적화되지 않았던지라 단일 버퍼 기반이라는 한계는 NT 계열도 그대로 갖고 있었다.

또한 NT 계열의 메모장은 BOM이 없는 유니코드 텍스트 파일에 대해서 IsTextUnicode라는 휴리스틱 API를 호출해서 텍스트 파일의 인코딩을 판단했었다. 그런데 그게 좀 버그가 있어서 정상적인 영어 단어로만 이뤄진 짤막한 파일을 UTF16 방식으로 저장된 중국어 한자로 오판하곤 했다. 0x41, 0x42.. 이런 묶음이 코드값상으로는 한중일 통합 한자 내지 확장 A이다 보니.. -_-;;
이 버그는 보안 쪽 문제는 아니지만 그래도 사람을 성가시게 하는 문제인 관계로, 2000이던가 XP 즈음에 패치가 나와서 고쳐졌다.

Windows 9x에는 IsTextUnicode라는 함수 자체가 존재하지 않으니 9x 계열의 메모장이야 저런 문제가 존재할 여지조차 전혀 없었다.
끝으로, 메모장은 아마 Windows XP에서 '상태 표시줄'을 표시하는 옵션이 추가된 게 현재까지 외형상의 마지막 변화 사항이지 싶다. '자동 줄바꿈'을 사용하지 않을 때에 한해서 줄/칸 위치를 표시하는 깨알같은 기능이 추가된 것이다.

이런 Windows와 메모장의 유구한 역사 속에서 도스용 Windows 3.x 내지 NT 3~4의 메모장에는 '불필요한 공백'이 존재했었나 모르겠다.

Posted by 사무엘

도스와 유닉스 명령창 공히 디렉터리를 이동할 때는 cd 내지 chdir이라는 명령을 사용한다. 단, 도스는 드라이브 이름을 A~Z 알파벳 한 글자로 표현한다는 게 마치 날개셋의 수식 변수만큼이나 특이하며, Windows는 이 관행을 그대로 물려받았다. 파일명에 대소문자를 구분해서 표현은 하지만 유닉스와는 달리 이를 서로 다른 것으로 취급하지는 않는다. 또한 디렉터리 구분자가 /가 아니라 \(역슬래시)라는 것도 유닉스 계열과 다르다.

그 뿐만이 아니다. 도스는 cd라고만 치면 현재 디렉터리를 표시만 해 주는 반면, 유닉스는 cd라고 치면 그냥 자신의 홈 디렉터리, Windows로 치면 "C:\Users\계정명" 정도로 이동해 버린다. 도스가 유닉스의 다른 개념들은 다 따 왔어도, 이건 다중 사용자라는 개념이 없던 물건이다 보니 홈 디렉터리 같은 건 도입하지 않기 때문이다. 유닉스에서 지금 디렉터리를 표시하는 명령은 잘 알다시피 pwd라고 따로 있다.

그렇게 도스와 유닉스 계열이 차이가 나는 와중에도 . 가 현재 디렉터리를 의미하고 ..는 부모 디렉터리를 의미한다는 건 둘이 동일하다. cd ..를 하면 부모 디렉터리로 갈 수 있다. 다만, 문법이 둘이 완전히 동일한 건 아닌지라.. 도스는 cd..라고 둘을 띄지 않아도 됐던 반면, 유닉스는 둘을 띄워야 한다는 깨알같은 차이점이 또 있다.

그런데 Windows 9x의 도스창에서는 숨겨진 기능이 더 있었다. cd 다음에 점을 세 개 이상 늘어놓음으로써 두 단계 이상의 조부모 디렉터리로 이동이 가능했다. cd...처럼. 그럼 저건 cd ..\.. 를 의미한다. 네 개 이상 숫자를 얼마든지 늘어놓아도 된다.
게다가 이건 파일 시스템 차원에서 공식적으로 인식하기라도 하는지, 굳이 cd에서만 쓸 수 있는 게 아니다. dir ... 이라고 하면 두 단계 상위 디렉터리를 조회할 수 있고, Windows의 파일 열기/저장 대화상자에서도 "..."이라고 치면 동일 기능이 동작했다.

Windows 9x는 C:\Windows 디렉터리를 가 보면 readme 등 몇몇 '읽어 보세요' 문서가 html이나 doc나 rtf가 아니라 txt 파일로 들어 있었는데, 그 중엔 tips.txt가 있다. 그 파일에 cd...에 관한 언급이 존재한다.

위는 영문판 Windows ME, 아래는 한글판 Windows 95의 tips.txt 내용 일부이다.

이 기능은 이전의 도스 시절엔 존재한 적이 없었으며 Windows 95에서 처음으로 추가되었다는 것이 명시되어 있다. 또한 95의 문서에서는 ....로 디렉터리를 세 단계 건너뛰는 예를 제시하는 반면, 후대 98/ME의 문서는 ...로 두 단계만 건너뛰는 예를 제시한다. C:\로 바뀌는 건 cd\와 동일하기 때문에 예제를 바꾼 게 아닌가 싶다.
참고로 Windows의 한글판은 98부터 '디렉토리'라는 표기가 '디렉터리'로 바뀌고, 문서들의 문체가 반말에서 존댓말로 바뀌었다.

놀라운 사실은, 이 기능은 오늘날의 Windows NT 계열에서는 지원되거나 존재한 적이 전혀 없었고 오로지 95, 98, ME만의 관행이었다는 점이다.

The old new thing 블로그의 설명에 따르면 cd ...는 노벨 네트웨어(Novell NetWare)라는 네트워크 솔루션에서 제공하는 명령 문법과의 호환성 때문에 편의 차원에서 도입된 기능이라고 한다. 그땐 노벨 사의 IPX/SPX 프로토콜 기반으로 네트워크 구성요소들도 있었으니 수긍이 간다.

그리고 9x와 달리 NT에서 ...를 지원하지 않은 이유는, 윈NT가 사용하는 NTFS 파일 시스템에서는 '.'나 '..'와는 달리 '...'는 그 자체가 올바른 파일이나 디렉터리 이름이 될 수 있기 때문이다. 그렇기 때문에 NT 계열에서는 이런 기능을 앞으로 지원할 의향은 더욱 없다고 봐야 할 것이다. 그냥 cd..\..를 해야지, 약칭인 cd...는 IPX 프로토콜이 존재하던 Windows 9x 시절의 추억으로 old timer들에게 남을 것으로 보인다.

9x 시절에는 dir con\con이던가, '실행' 대화상자에서 con\con 이런 걸 치면 운영체제를 뻗게 하고 도스창을 강제 종료시키는 게 가능했다. 이건 꽤 유명한 버그였으며 ME에서야 보정을 통해 패치가 됐다. cd ...는 그것만큼이나 9x 시절에 파일 시스템과 관련해 흥미로운 고유 아이템 추억거리인 것 같다.

여담으로, 명령 프롬프트에서 공백은 여러 명령 인자 토큰들을 구분하는 역할을 한다. 그렇기 때문에 거기서 공백이 들어간 파일을 표시하기 위해서는 파일명 전체를 ""로 싸야 하며, 각종 프로그래밍 언어에는 따옴표 문맥을 인식하면서 공백 기준으로 명령 인자들을 파싱· 토큰화하는 라이브러리도 존재한다. 그러나 이 cd 명령만은 예외로 공백이 들어간 디렉터리도 CD Program Files 라고만 쳐도 인식되게 되어 있다. cd /?를 해 보면 이 사실을 확인할 수 있음.

그리고 cd에는 드라이브까지 같이 변경하는 명령이 한동안 존재하지 않았다. 도스 커맨드 셸의 대체제이던 4DOS 내지 NDOS에서는 자체적인 명령 확장을 통해서 그런 기능을 제공하곤 했는데, 오늘날 Windows에서는 /D 라는 별도의 옵션을 줘야만 드라이브도 변경 가능하다. 아마 드라이브를 변경하지 않는 게 보장된다는 무슨 호환성 때문에 옵션 형태로 기능을 추가한 것 같다. 참고로 /D는 9x의 도스창에는 존재하지 않으며, Windows NT 계열의 명령 프롬프트에만 있다. ...를 지원하지 않는 대신 /D가 있는 셈이다.

Posted by 사무엘

C++ 클래스에서 타입이 char나 int 같은 정수형 스칼라(배열이 아닌)인 static const 멤버는 선언 후에 별도의 정의를 따로 안 해 줘도 된다. 선언과 동시에 값을 지정할 수 있다. 본인은 이에 대해서 3년 전에도 한번 글을 썼던 적이 있다.

class foo {
public:
    static const int bar = 500;
};

하지만 멤버가 char나 int 같은 간단한(primitive) 타입이 아니고 다른 구조체이거나, 혹은 간단한 타입이라도 배열이라면 얘기가 달라진다. 아까처럼 즉석 초기화를 할 수 없으며, 반드시 정의를 해 줘야 된다.

//헤더 파일
class foo {
public:
    static const POINT bar1;
    static const int bar2[];
};

//소스 파일
const foo::bar1 = { 1024, 768 }; // .x, .y
const foo::bar2[] = { 1, 2, 100 }; // [0], [1], [2]

자, 여기까지는 뭐 당연한 사실이다. 그런데 얼마 전엔 회사에서 이와 관련된 기괴한 일을 하나 겪어서 이곳에다 소개하고자 한다.
static const int 형태로 상수를 하나 추가해서 사용했는데 컴파일러가 이걸 도무지 인식을 못 하고 링크 에러를 내는 것이었다. global scope에 선언된 const 야 C++에서는 static이 디폴트이기 때문에 extern을 명시적으로 지정해야 한다지만, 멀쩡한 C++의 static const 멤버를 왜 인식을 못 하지?
게다가 더 이상한 건 Visual C++과 xcode는 다 문제 없는데 안드로이드의 빌드 환경인 gcc만 저런다는 것이었다.

멀쩡한 코드를 고치고 재빌드 하면서 잠시 헤매긴 했지만, 문제 자체는 구글링을 통해 원인을 찾아서 곧 해결할 수 있었다.
답부터 말하자면, 저 위의 bar는 선언과 초기값 지정이 되어 있음에도 불구하고 const int foo::bar1; 이라고 몸체도 소스 코드 어딘가에 정의해 줘야 했다. 단, 500이라고 초기값을 지정하는 건 선언부와 정의부 중 한 곳에다가만 하면 된다. 마치 함수의 디폴트 인자를 선언부와 정의부 중 한 곳에만 주면 되듯이.

소스 코드에서 어떤 숫자에다가 명칭을 부여하기 위해서는 enum이나 전처리기 #define을 사용할 수 있다. 이에 비해 const는 위의 두 방법과는 달리 명시적인 타입을 가지며, & 연산자를 이용해서 값의 주소도 얻을 수 있다는 차이가 있다.

static const 멤버를 R-value로만 쓰는 것은 그때 그때 그 숫자를 말 그대로 상수 형태로 집어넣는 것과 같다. 그러니 enum이나 #define과 별 차이가 없으며, 굳이 이 변수의 실체(= 주소)가 없어도 된다.
그러나 이 값을 그대로 파일에다 쓴다거나 할 때는 값이 담긴 메모리 주소를 줘야 한다. 그리고 C++의 템플릿 라이브러리 중에도 일단 value가 아니라 참조자가 전달되는 함수에다가 static const 멤버를 넘겨주면 그 멤버의 주소가 필요해진다.

그리고 그렇게 값이 아니라 주소가 필요한 경우가 있다면, gcc는 비록 선언부에서 값이 지정된 static const 멤버라 해도 별도의 몸체의 정의가 있어야만 링크를 제대로 수행해 줬다. 이니셜라이저가 있는 것도 아니고, 그냥 선언부에 있는 변수를 거의 그대로 다시 써 주는 잉여일 뿐인데도 그게 꼭 필요했다. 그 반면 Visual C++ 등 타 컴파일러는 몸체 정의가 있건 없건 결과는 동일하게 나왔다. 어째 이런 차이가 존재할 수 있는 걸까?

한편으로 gcc는, 주소만 요구하지 않는다면 구조체나 배열까지는 아니어도 float, double 같은 부동소수점 스칼라 상수를 몸체 정의 없이 static const로 선언하는 것도 허용해 줬다.

class foo {
public:
    static const double bar4 = 0.0025;
};

이거야말로 비표준이며 일단 Visual C++ 등 여타 컴파일러에서는 허용되지 않음에도 불구하고 gcc는 이를 지원한다. 혹시 나중에 표준으로 등재됐다면 댓글로 알려 주시기 바람. 요즘 C++은 하루가 멀다 하고 급변하고 있어서.. 과거 C++이 98과 03 버전을 거친 뒤 갑자기 1x대부터 확 바뀌기 시작했는데, 이는 마치 마소가 2000년대에 닷넷 때문에 C++ 지원을 등한시하다가 2010년대부터 트렌드가 바뀐 것과도 분위기가 일치하는 것 같다.

enum은 정수형 타입만 지원하기 때문에 실수 상수를 정의하는 건 #define 아니면 const밖에 선택의 여지가 없는데 gcc처럼 할 수 있다면 편리할 것 같다.
다만 &foo::bar4가 필요하다면 gcc라도 물론 const double foo::bar4; 라는 몸체 선언이 추가로 필요해진다.
아무튼, static const 멤버와 관련하여 gcc의 특이한 면모를 다시 생각할 수 있는 시간이었다.

Posted by 사무엘

2010년대가 벌써 중후반기로 들어섰다.
세상은 3, 40년 전의 SF물들이 전망했던 것처럼 인간이 무슨 달과 화성에 식민지를 개척하는 식으로 발전하지는 못했다. 초음속기와 우주 왕복선은 퇴역했고, 컴퓨터에서 싱글코어 무어의 법칙은 유효기간이 끝났다.
그러나 그런 게 아닌 다른 쪽으로는 과학 기술이 여전히 꾸준히 발달해 왔다. 제품의 외형은 크게 변화가 없을지 몰라도 그 내부는 이곳 저곳이 발전했다.

대외적으로는 1년 남짓 전부터는 기름값이 웬일로 다시 2000년대 초 수준으로 내렸고, 대학가에서 2000년대에 잠시 주춤했던 컴퓨터/전산학 지망자가 다시 늘고 있다. 컴퓨터 얘기를 좀 더 늘어놓자면 2000년대에 한창 닷넷에 밀려 C++이 죽었네 마네 하고 있었지만, 지금은 오히려 닷넷이 시들시들하고 C++ 언어가 하루가 다르게 변모하고 있다.

1999년, 2012년 등 각종 시한부 종말 예언은 예나 지금이나 전혀 적중하지 않고 불발탄으로 끝났다. 북한은 새끼 돼지 휘하에서 예나 지금이나 체제가 잘-_- 유지되고 있다. 중동에는 소말리아 해적밖에 없는 줄 알았는데 웬 이상한 또라이 이슬람 막장 국가가 태동하여 2차 세계 대전 이래로 국제 세계를 하나로 단결시키고 있다. 이 과학 기술 내지 국제 정세라는 건, 한국어의 종결어미와도 같아서 정말 그때가 돼 보지 않고서는 스토리를 정녕 알 수 없는가 보다.

컴퓨터 CPU의 집적도와 코어 수가 올라가고, 저장 매체의 용량이 급격하게 증가한 것만큼이나 이 시대는 디스플레이 내지 조명 장치가 눈부시게 발달한 것의 혜택을 크게 입고 있다. 아무리 기가 막힌 저전력 고성능 초소형 CPU가 발명됐어도, 전자식이 아니라 기계식인 하드디스크는 근본적으로 진동과 충격에 약하기 때문에 걸어 다니는 사람의 주머니 속에서 동작하기는 영 무리일 수밖에 없을 것이다.
또한 디스플레이 장비가 브라운관밖에 없거나, 액정이라고 해 봤자 계산기의 흑백 액정 같은 것밖에 없었어도 지금과 같은 스마트폰이 만들어질 수 없었을 것이다.

토머스 에디슨이 살아 생전에 발명을 그렇게도 많이 했다지만, 그의 대표적인 발명은 축음기와 백열등 전구라는 양대 산맥으로 요약된다 해도 과언이 아니다.
그 중 백열등은 가히 세상을 바꿔 놨다. 성경이 말하는 "빛과 소금" 중에서 '빛'에 해당하는 발명이다. 전등은 깜깜한 밤에 빛을 얻기 위해 굳이 연료를 태워서 불을 피울 필요를 없게 만들어 줬다.

그에 반해 등잔, 양초, 등유 램프 같은 건 연기가 남고 화재의 위험이 있으며, 결정적으로 빛이 그렇게 밝지도 않다. 어느 못사는 집에서 전기료가 밀려 단전되는 바람에, 촛불을 켜고 자다가 촛불이 넘어지고 집에 불이 나서 일가족이 죽었다는 뉴스.. 21세기에도 가끔은 흘러나온다.
이 얼마나 불편했는가? 그에 비해 전등의 빛은 그 당시로서는 얼마나 우아하게 보였을까? 오죽했으면 에디슨이 죽었을 때 미국 전역에서 1분간 전등을 소등했을 정도였다.

다만, 오늘날의 관점에서 백열등은 전기로 빛을 내는 가~~장 단순한 방법이지만, 한편으로 증기 기관차만큼이나 가장 무식하고 비효율적인 방법이기도 하다.
어느 분야이든 전기를 에너지를 가장 단순한 방식으로 끌어 쓰는 방법은 V=IR 법칙에 의거하여 물리적인 저항을 만드는 것이다. 졸졸 흐르는 강물 내부에다 물레방아라는 저항을 설치해서 동력을 얻듯이. 전동차는 저항 제어 방식이 가장 먼저 등장했으며, 백열등 역시 근본 원리는 가느다란 필라멘트를 저향열로 달궈서 빛이 덤으로 나게 하는 것이다.

연료와는 달리 대놓고 아주 태워 버리는 게 아니라는 점이 다를 뿐이다. 그리고 에디슨은 필라멘트로 쓰기에 가장 좋은 재료를 찾기 위해서 수백~수천 번의 실패를 거듭하면서 근성을 발휘했다는 일화가 전해져 온다. 가장 무식하고 비효율적인 방식의 전등조차도 그냥 쉽게 만들어진 건 아니라는 뜻이다. 그 시절엔 동그란 곡면인 전구 모양의 유리조차도 사람이 입으로 불어서 힘들게 만들어야 했다.

단순 저항으로 전기를 활용하는 모든 방식의 문제는 열이다. 전기 에너지 중 일부만이 빛이나 동력 같은 인간에게 유익한 형태로 쓰이고, 나머지는 열로 다 빠져나간다. 대놓고 전열기를 만드는 게 아니라면 저건 좀 개선돼야 할 점이 아닐 수 없다.
오래 켜 놓은 전구는 사람이 만지면 화상을 입을 정도로 뜨거워진다. 그리고 과거의 저항 제어 전동차 역시 회생 제동조차 없던 시절엔 열로 손실되는 에너지 때문에 객실 내부까지 찜통으로 변하고 비효율과 고충이 장난이 아니었다.

나중에 발명된 형광등은 내부적으로 형광 물질을 사용하고 내부 구조도 백열등보다 더 복잡하다. 필라멘트가 있긴 하지만 그거 자체가 시뻘겋게 달궈져서 빛을 내는 형태는 아니기 때문에 열이 덜 난다. 등의 모양이 왠지 백열등보다 더 길쭉하고, 같은 전기를 쓸 때 광량도 더 많고 수명도 더 길다. 쉽게 말해 더 효율적이고 모든 면에서 백열등보다 더 나았다.

그런데 과거의 형광등들은 잘 알다시피 점등 딜레이가 있었기 때문에 "형광등 같다" 그러면 머리의 반응이 좀 더딘 사람을 상대로 좀 부정적인 비유에 쓰이곤 했다. 정작 만화 같은 매체에서는 아주 비효율적인 백열 전구가 뿅 켜지는 것이 번뜩이는 아이디어가 떠오르는 걸 나타내는 긍정적인 심상이었는데 참 대조적이다.

오늘날은 이런 전구에까지 반도체를 동반한 LED 방식이 대세가 돼 있다. 전력 소모와 광량에 관한 한, 형광등보다도 더 성능이 좋은 끝판왕이라고 한다. 단점은 반도체의 특성상 초기 제조 비용이 비싸고 열에 약한 것 정도가 고작이다.
생긴 건 꼬마전구마냥 자그마한데(형광등은 이 정도로 작게는 못 만들지 아마?) 거기서 백열등 전구로는 상상할 수 없는 아주 희고 강렬한 빛이 뿜어져 나오며, 발열도 별로 없다. 이게 그냥 이뤄진 게 아니다. 스마트폰에 내장된 손전등 기능도 응당 LED 기반이며, 24시간 가동되는 길거리의 신호등들도 다 LED 방식으로 교체되고 있다. 설치만 하면 얼마 못 가 설치 비용을 회수하고 이득이 나기 때문이다.

반도체라고 하면 으레 컴퓨터를 떠올리기 쉬우나, 반도체가 꼭 그런 데에만 쓰이는 물건은 아니다. 시계가 기계식 태엽을 쓰다가 건전지를 집어넣는 쿼츠 방식으로 바뀐 것도 반도체 기술이 가미된 것이다. 전자식 시계는 가격과 성능, 정확도 등 모든 면에서 기계식 시계를 처참하게 관광 태웠다.

또한 전동차가 VVVF 제어 방식으로 바뀐 것도 반도체 기술 기반이다. 동력 성능, 유지보수 난이도 등 모든 것이 종전의 저항 및 쵸퍼 방식보다 우위이다. 초기에는 시끄러운(?) 가속 구동음만이 유일한 단점으로 제기되었지만 철덕에게는 그건 아름다운 음악-_- 소리이지 단점이 전혀 아닐 뿐더러, 요즘은 소음 문제마저도 다 개선됐다. (소음이 인간의 가청 주파수 대역 이외로 금방 넘어가거나..)

형광등이나 LED등이 백열등과는 너무 압도적인 성능 차이가 나기 때문에 나라에서는 아예 백열등을 퇴출까지 시키려 할 지경이 됐다. 마치 컴퓨터계에서 IE6이나 제로보드 4를 퇴출시키려 하는 것처럼 지금 이상의 생산이나 수입, 판매를 금지한다. 백열등은 딱히 유연휘발유나 프레온 가스처럼 그 자체가 위험하거나 환경 문제를 일으키지는 않지만, 에너지 소비량 대비 효율이 너무 안 좋기 때문이다.

참고로 현재 지구상에서 현역으로 가장 오래 뛰고 있는 백열등은 미국에 소재한 '센테니얼 전구'라고 한다. 무려 since 1901이고 한 세기가 넘게 켜져 있었다고 한다. 소등 시간은 몇십 년에 한 번 꼴로 몇 시간이 고작임. 세계 최고령 전구라고 재조명과 주목을 받기 시작한 건 1970년대부터였다.

허나, 지금으로부터 먼 미래에는 형광등조차도 LED보다 효율이 낮으며 수은이라는 위험물질 문제도 있는지라 퇴출 수순을 밟을 가능성이 있다. 그리고 이런 식으로 전기· 전자 공학 기술이 계속 발전하다 보면 기술 트렌드가 어찌 보면 복고풍을 탈지도 모른다. 한때는 실용성이 다른 기술에 밀려서 사장됐다가 나중에 그 한계가 극복되면서 다시 조명받는 것 말이다.

대표적인 예는 전기 자동차이다. 한때는 기름 자동차보다 가볍고 구조가 간단하고 성능도 좋다는 장점(시속 100km도 먼저 돌파) 때문에 널리 보급되었지만, 배터리 충전 시간과 항속거리에 치명적인 발목이 잡혀서 굳이 석유 회사의 로비가 없이도 슬금슬금 밀려 사라졌다.

하지만 지금은 기름값과 환경 문제 때문에 전기 철도뿐만 아니라 전기 자동차도 다시 주목을 받고 있다. 새로운 유전이 자꾸 발굴되고 채굴 기술도 눈부시게 향상되었다지만 석유가 지구에 무한히 존재하지는 않을 것이다. 게다가 석유는 단순히 태우는 연료뿐만 아니라 플리스틱 같은 다른 화합물을 만드는 데에도 쓰인다. 자동차의 동력원이 앞으로 어떻게 바뀔지 알 수 없는 노릇이다.

그 뿐만이 아니다. 교류 전기에 밀려 사라진 고전압 직류 송전도 그 당시에 문제되었던 한계(송전 손실, 변압)를 반도체 기술로 극복하고 다시 부각되고 있는 것 같다. 솔직히 교류는 전기 공학을 우리 같은 사람이 감당하기엔 너무 복잡하고 어렵게 만드는 주범이긴 한데..;; 단점만 없으면 직류 위주로 가는 게 더 간단하고 좋긴 할 것이다. 그리고 이 직류 송전 기술의 배후에도 반도체 기술이 있다.

그나저나 무선 송전 기술은 정말 실용화가 가능한지 모르겠다. 이게 제대로 된 물건이 나오면 전기 문명에도 일대 혁신이 일어날 것이다. 철도에는 전차선까지는 몰라도 팬터그래프가 필요 없어지고 전기 철도 시설의 근간이 송두리째 흔들릴 것이다.

끝으로, 전기 쪽 잡다한 자료들을 찾다가 본인은 흥미로운 동명이인 과학자 pair가 있다는 걸 발견했다. 이를 소개하며 글을 맺겠다.

• 독일 브라운: 로켓(새턴 V), 전기공학(브라운관)
• 영국 플레밍: 미생물학(스코틀랜드 출신, 페니실린), 전기공학(잉글랜드 출신, 양손 법칙)

듣자하니 그 당시에 무선 통신의 선구자이던 이탈리아의 굴리엘모 마르코니는 브라운· 플레밍과도 같이 만나서 연구를 했다고 한다. 어느 브라운과 어느 플레밍인지는 더 설명이 필요하지 않을 테고.

Posted by 사무엘

운영체제가 기본 제공하는 프레임과 제목 표시줄이 있는 윈도우라면, 사용자가 그 제목 표시줄을 좌클릭+드래그 하여 창을 다른 곳으로 옮길 수 있다.
그런데, 그런 프레임이나 제목 표시줄이 없는 특수한 형태의 윈도우를 만들었다. (Custom 스킨이 씌워진 리모콘이나 TV 모양의 동영상 재생기 같은..) 사용자가 이 창의 아무 표면이나 특정 부위를 드래그 해서 창의 위치를 옮길 수 있게 하려면 어떻게 하면 좋을까?

(1) 가장 단순무식한 방법은 WM_LBUTTONDOWN, WM_MOUSEMOVE, WM_LBUTTONUP을 받아서 해당 기능을 직접 구현하는 것이다. 즉, LBUTTONDOWN 때 마우스를 캡처하고 마우스 포인터의 위치가 창의 화면 좌표에서 얼마나 떨어져 있는지를 파악한다. 그리고 캡처가 있는 상태에서 MOUSEMOVE가 오면 새 포인터의 위치에 상응하는 위치로 창의 위치를 옮긴다(SetWindowPos). 이 기능은 각각의 메시지 핸들러 함수에다 구현해도 되고, WM_LBUTTONDOWN 안에다가만 자체적인 message loop을 돌려서 구현해도 된다.

이건 드래그 앤 드롭 기능을 구현하는 절차와 비슷하다. 한 윈도우의 내부에서 그려지는 각종 그래픽 오브젝트에 대해서 드래그+이동을 구현하려면 저렇게 직접 코딩을 해 줘야 한다. 그러나 창 자체에 대해서 드래그+이동만을 구현하는 것은 사실 다음과 같이 더 간단한 방법도 있다. 이미 존재하는 기능을 운영체제에다가 요청만 한다는 것이 핵심 아이디어이다.

(2) 그 창에서 WM_NCHITTEST 메시지를 받아서 DefWindowProc의 리턴값이 HTCLIENT인 지점에 대해서도 HTCAPTION을 되돌린다.
그러면 운영체제는 이 창의 클라이언트 영역을 클릭+드래그 한 것도 제목 표시줄을 클릭+드래그 한 것과 동일한 것으로 간주한다. 그래서 드래그 시 창을 자동으로 이동시키게 된다.

이건 대부분의 경우에 굉장히 깔끔한 방법이긴 하지만, 창을 이동시키는 데 쓰이는(HTCAPTION으로 인식되는) 영역에 대해서 더 세부적인 제어를 하기가 어렵다는 게 흠이다. 즉, 거기를 우클릭 한다거나 더블클릭 한 것처럼, 이동과 관계 없는 다른 동작을 취한 것을 우리가 인식할 수 없다. 거기는 마우스 동작에 관한 한, 애초에 클라이언트 영역이 아닌 것으로 간주되어 버렸으니 말이다. 만약 그런 제어까지 해야 한다면 다음과 같은 또 다른 방법을 사용하면 된다.

(3) WM_LBUTTONDOWN이 왔을 때, 창을 이동시키는 기능에 해당하는 시스템 명령을 전달한다.
가장 간단하게 생각할 수 있는 방법은 PostMessage(m_hWnd, WM_SYSCOMMAND, SC_MOVE, 0); 이다. 이것은 Alt+Space를 눌러서 나오는 창의 시스템 메뉴에서 '이동'을 선택하는 것과 같은 효과를 낸다. 창에 제목 표시줄이나 시스템 메뉴가 없다고 해서 시스템 메뉴에 해당하는 기능 자체가 없어지지는 않기 때문이다.

단, 이것은 창을 끌어다 놓는 것과 정확하게 같은 기능은 아니다. 일단 마우스 포인터는 모양이 사방의 화살표 모양으로 바뀌고, 사용자의 key 입력을 기다리는 상태가 된다. 사용자가 ESC가 아닌 다른 key를 누르면 그때부터 마우스 이동으로 해당 창이 이동되는 모드가 된다. 심지어 좌클릭을 한 상태가 아니어도 된다.

SC_MOVE보다 더 직관적인 방법은.. 마소에서 정식으로 문서화하여 공개한 기능은 아니지만 사실상 공공연한 비밀이 돼 버린 기능을 사용하는 것이다. 좌클릭 메시지가 왔을 때 SC_MOVE (0xF010) 대신,
PostMessage(m_hWnd, WM_SYSCOMMAND, 0xF012, 0); 이라고 하면... 마우스를 누르고 있는 동안 창 이동이 아주 깔끔하게 구현된다. 직접 시도해 보시라. 이것이 SC_MOVE와 SC_MOVE+2의 차이이다.

시스템 명령 중에는 SC_MOVE나 SC_SIZE처럼 메뉴에 등재된 명령뿐만 아니라 해당 메뉴 명령을 누른 뒤에 부가적으로 실행되는 기능도 비공개 내부 ID가 부여돼 있다. 가령, SC_SIZE+1 (0xF001)부터 SC_SIZE+8 (0xF008)은 마우스 드래그로 창의 크기를 조절하는 명령을 바로 실행시킨다. 1부터 8까지 순서가 어떻게 되는가 하면 left, right, top, top-left, top-right, bottom, bottom-left, bottom-right이다. 해당 위치의 크기 조절 모서리와 대응한다는 뜻.
이거 배열 순서는 WM_NCHITTEST의 리턴값인 HTLEFT (10)와 HTBOTTOMRIGHT (17)와도 동일하다. 그러니 이해하는 데 어려움이 없을 것이다.

이 주제/테크닉과 관련하여 생각할 수 있는 다른 이야기들을 늘어놓자면 다음과 같다.

1. 추억.
과거에는 운영체제의 자체 기능을 사용해서 창의 위치를 옮기면, 창이 이동되는 동안에 창의 내용이 실시간으로 업데이트 되는 게 아니라 창의 경계 테두리만이 XOR 연산되어 그려졌다. 당연히 창을 일일이 다시 그리는 게 그 시절 옛날 컴퓨터로는 부담스러운 연산이었기 때문이다.
그러다가 1990년대 말, Windows 95를 넘어 98/2000으로 넘어갈 시기부터 창을 실시간으로 업데이트 하는 옵션이 추가되었고, 후대부터는 그게 당연한 관행이 됐다.

창의 테두리만 이동하고 있는 중에는 운영체제가 응용 프로그램으로 WM_MOVING (또는 WM_SIZING)이라는 메시지를 보냈는데, 이때 그냥 SetWindowPos로 창의 위치를 바꿔 버리면 운영체제의 옵션과 무관하게 '실시간 업데이트'를 시전할 수 있긴 했다.
하긴, 옛날에는 스크롤 막대조차도 스크롤 하는 동안 막대의 테두리만 이동하지 스크롤 대상 화면은 업데이트 되지 않는 경우가 있었다.

도스 시절도 마찬가지. 화면 전체의 업데이트가 키보드 연타 속도를 따라가지 못할 경우를 대비해서 일부 프로그램들은 화면을 표시하는 중에도 키보드 입력을 체크하곤 했다. 그래서 상하 화살표가 눌렸으면 화면을 다 업데이트 하지 않고 다시 스크롤을 했다. 그렇게 하지 않으면 나중에 키보드 버퍼가 꽉 차서 삑삑 소리가 났다.. ^^;;

2. Windows에는 이런 식으로 아기자기한 비공개 API가 더 있다.
캐럿의 깜빡임 주기를 나타내는 메시지 0x118는 흔히 WM_SYSTIMER이라고 표현하는 사람도 있는데, 어쨌든 유명한 유령 메시지이다. 이 메시지의 출현에 의존해서 동작하는 프로그램이 설마 있으려나 모르겠다.

또한,
::SendMessage( ::ImmGetDefaultIMEWnd(hWnd), WM_IME_CONTROL, 5, 0 );
이라고 하면 hWnd가 자신과 동일한 프로세스/스레드이든 불문하고 해당 창에 있는 Windows IME의 한영 상태를 얻어 올 수 있다고 한다. 리턴값이 1이면 한글, 그렇지 않으면 영문이다.
보통은 한영 상태를 얻으려면 해당 윈도우에 소속된 IME context 값을 ImmGetContext로 얻어 와야 하는데, 이거 내 기억이 맞다면 프로세스는 물론이고 스레드 경계도 넘지 못한다. 그런데 ImmGetContext나 ImmGetConversionStatus 호출 없이 저렇게 간단한 메시지로 한영 상태를 query할 수 있다니 신기한 노릇이 아닐 수 없다.

MSDN이고 Windows DDK고 어디든지 WM_IME_CONTROL을 찾아 보면, 거기에 문서화돼 있는 IMC_* 명칭들 중에 5라는 값을 가진 물건은 없다. 하지만 저 기능은 Windows 95 이래로 모든 운영체제에서 사용 가능하다. 게다가 5 대신 2를 주면 한영 상태를 바꿀 수도 있는 듯하다. (lParam에다가 새 값을 설정하고)
이런 것들은 마치 인터넷 지도에서 있는 그대로 표시되지 않고 숲으로 가려진 지대를 보는 듯한 느낌이다.

3.
창을 드래그 해서 옮기는 것이야 제목 표시줄을 단 1픽셀이라도 끌면 창이 바로 반응해서 움직인다.
하지만 일반적으로 텍스트나 아이콘을 '드래그 앤 드롭'을 해서 옮기는 건 그렇게 곧장 반응하지는 않게 돼 있다. 창의 위치만을 옮기는 것과는 달리, 일반적인 드래그 앤 드롭에는 파일을 복사하거나 옮기고 텍스트 문서의 내용을 변경하는 등 더 크리티컬한 결과를 초래하는 동작을 수반할 수도 있기 때문이다.

Windows에서 UI 가이드라인 상으로는, 마우스를 클릭해서 약 2픽셀이던가 그 이상 포인터가 가로 또는 세로로 실제로 움직였을 때.. 혹은 움직이지 않았더라도 클릭 후 1초 가까이 시간이 지났을 때에야 드래그가 시작되게 돼 있다. 드래그 인식을 위한 최소 한계치는 GetSystemMetrics(SM_CXDRAG) / SM_CYDRAG를 통해 얻을 수 있다.

허나, 이걸 일일이 코딩하는 건 드래그를 곧장 인식하는 것보다 굉장히 번거롭고 귀찮은 일이다. 그래서 Windows에는 아예 DragDetect라는 함수가 있다. WM_LBUTTONDOWN이 왔을 때 요 함수를 먼저 호출해서 OK가 오면 그때부터 드래그 모드로 진입하면 된다. DragDetect는 자체적으로 메시지 loop을 돌면서 마우스가 표준 규격 이상만치 움직였는지, 시간이 경과했는지, 사용자가 무슨 key를 눌렀는지 등을 총체적으로 판단해서 드래그 모드로 진입할지 여부를 알려 준다.
이런 함수도 있다는 걸 알면 GUI를 구현할 일이 있을 때 도움이 많이 될 것이다.

Posted by 사무엘

1. 영창 피아노 CF

"온 세상에 울리는 맑고 고운 소리~" (☞ 영창 피아노)
영창 피아노는 어째 군대의 징계 시설과 이름이 같은 바람에 이상한 개드립에 동원되기도 하는 브랜드이지만, 한 30년쯤 전부터 CM송 하나를 기막히게 만들어 퍼뜨린 덕분에 경쟁사인 삼익 피아노에는 없는 독자적인 인지도를 확보하고 있다.
1989~90년대 그 옛날에 소리와 영상으로 온몸으로 '자연의 소리' 컨셉을 CF에다 담으려고 참 애 많이 썼다.

영창 피아노는 한때는 무려 빈 소년 합창단을 초빙해서 CF를 찍기도 했다.
미국 NASA가 상업 우주 여행을 주선하지 않은 것만큼이나(러시아와는 달리. 하지만 앞으로는 NASA도 조만간 할 예정이라 함) 빈 소년 합창단도 원래는 상업 광고 따위에는 협조를 안 하는 고매한 단체이다. 하지만 그 당시 영창에서 피아노를 기증해 주기도 하고 어째 거래가 잘 성사되어서 자국도 아닌 동아시아 메이커 피아노의 CF에 출연하게 됐다.

원조 CF에서 피아노를 치는 소녀는 본인과 비슷한 또래의 '염 선희'라는 아이인데, 프로필과 스펙이 꽤 엄청난 사람이다. 저 나이 때 피아노 콩쿠르에서 입상해서 CF 모델로 뽑혔다. 그리고 아마 집도 꽤 잘사는 듯.
원래 음대에 가서 피아노까지 전공하고 싶었지만 손목 건강 문제 때문에 꿈을 접고, 미국으로 유학을 가서는.. 웬 뜬금없는 컴퓨터공학과를 선택했다.

하지만 대학에 입학하고 타지에서 부모 간섭에서 벗어난 지 몇 달이 채 되지 않아 스타크래프트에 파묻혀서 온게임넷 게임 자키를 하더니 숫제 한국으로 돌아와 여성 프로게이머로 활동했다. 한때는 같은 여자이고 특별히 미녀 게이머라고 이름을 날리던 서 지수와도 대결을 했을 정도였다.
재능도 재능이지만 처음엔 음대를 지망했다가 미국으로 대학 학부 유학(대학원 유학도 아니고)을 가고, 그 뒤에도 진로를 저렇게 뜬금없이 마구 바꾸는 건 집안이 경제적으로 받쳐 주지 않으면 가능하지 않았을 것이라 개인적으로 생각한다.

그런데 손목 부상 때문에 피아노를 접었으면서 왜 피아노 이상으로 손목을 혹사시키는 직업인 프로게어머를 선택했는지는 궁금한 점이다. 외국어도 영어 중국어 스페인어 다 구사하는 엄친딸이라는데 어문 쪽 진로를 선택해도 됐을걸.
그녀는 프로게이머를 오래 하지는 못하고 2년 남짓 있다가 2005년경에 역시 손목 건강 문제 때문에 은퇴했다. 그 뒤로 이 "영창 피아노 CF 출신의 프로게이머"는 온라인 상으로 근황이 전해지는 게 없다. 아무튼 특이한 인물이다.

다시 영창 CF 얘기로 돌아온다.
우리가 오해하지 말아야 할 것은, 저 CF에서 염 선희는 피아노를 치는 컨셉 연기만 했다는 점이다. 노래까지 저 애 목소리인 건 물론 아니며, 노래를 부르는 것처럼 보이는 장면은 립싱크라는 걸 화면을 조금만 보면 알 수 있다. 좀 앳된 느낌이 있지만 저 목소리는 진짜 아동이 아니라 성우나 전문 가수의 목소리이다.

영창 CF 노래를 부른 사람은 '신 해옥' 씨라고 수백, 수천 곡에 달하는 CM송과 만화 주제가를 부른 경력이 있는 '얼굴 없는’ 가수이다.
얼굴 없는 가수라 하니까 딱 그 직업을 배경으로 다루는 <미녀는 괴로워> 영화라든가 풀빵닷컴 박분자도 생각나네.
이분의 대표작으로 내 기억에 남아 있는 건 1990년대 MBC <그림 명작동화> (꿈길에 들었던 꿈길에 놀았던..)의 주제가이다. 영창 피아노 노래와는 달리 저건 꽤 가요풍으로 불렀다.

2. 사이버 가수

아담, 류시아, 사이다. 지금으로부터 무려 18~20년 가까이 전, 본인이 중딩~고딩이던 시절에 우리나라에서 만들었던 '사이버 아이돌' 가수 캐릭터이다. (☞ 링크 1, 링크 2)

일본에서 세계 최초의 사이버 가수라는 '다테 쿄코'를 데뷔시킨 것에 착안해서, 그리고 또 그 당시에 <툼 레이더> 게임과 함께 주인공 '라라 크로프트'가 전세계에서 초대박을 친 것에 영향을 받아서 국내에서도 사이버 캐릭터를 만들려는 시도가 있었다. 1990년대 후반엔 그게 트렌드였다.

<세상엔 없는 사람> 노래와 뮤직비디오를 내가 어째 이렇게 생생하게 기억하고 있나 옛날 기억을 더 추적해 보니..
아, 그 시절에 정품을 구입했던 거원 제트오디오 CD에 아담의 탄생, 주제곡 등 주요 뮤비 동영상 파일들이 들어있었다. 난 그걸 여러 번 감상했었다.

'아담'을 개발한 '아담소프트'는 3차원 CG 분야에서는 나름 잔뼈 굵고 기술 있는 IT기업이었다. 창업자가 카이스트 출신이었던가..?
당시에는 <마이크로소프트웨어>와 더불어 <프로그램세계>라는 프로그래밍 관련 잡지가 발간되고 있었는데, 본인은 거기서 아담소프트 소속의 엔지니어가 칼럼을 기고한 것을 본 적도 있다. 글쓴이의 이메일이 도메인이 adamsoft.com이었다.

아담 말고 여성인 류시아와 사이다는 제각기 다른 회사에서 개발한 모델이다. 류시아는 루시퍼+메시야의 합성어를 의도하기도 했다니 거 참..;;
왜 한 회사에서 여러 명을 만든 게 아니냐 하면, 일개 벤처/스타트업 기업으로서 모델 하나만 감당하기에도 자본과 기술이 벅찼기 때문이라고 생각하면 될 듯하다.

사이버 가수는 처음 등장했을 때는 워낙 신기하니까 언론으로부터 주목도 많이 받았다. 하지만 여러가지 이유로 인해 이게 오래 흥행하지는 못했다.
일단 CG 기술이 실사를 따라가기에 한계가 있었다. 그리고 캐릭터가 그렇게 충분히 잘생기거나 예쁘지 않았다.
이런 와중에 실존 인물이 아닌 가상 캐릭터가 무슨 영화나 게임 캐릭터처럼 액션도 없이 예능만으로 팬심을 사는 건 한계가 있었다.

오늘날까지 살아 있는 그나마 성공한 사이버 캐릭터인 라라 크로프트의 경우도, 말총머리 + 핫팬츠 + 쌍권총 같은 외형 특징을 본따서 홍보대사(?)를 모델 겸 체조 선수 출신의 실존 인물로 몇 기째 뽑아 왔을 정도이다. 영화도 당연히 안젤리나 졸리 같은 걸출한 실존 인물이 연기했고. (그나마도 리부트작이 나온 뒤부터는 기존 컨셉을 싹 갈아엎었다.) 어쨌든 오늘날까지도 어떤 형태로든 실존 인물이 없어서는 안 된다는 거다.

게다가, 1990년대 말 그 시절엔 CG를 만드는 것도 생각보다 굉장히 어려운 일었다고 한다. 시간과 비용이 억소리나게, 그냥 유명 실존 가수를 부르는 것 만만찮게 많이 들었다. 그냥 모션 캡처만 간단히 하면 장땡이 아니었던 듯하다.
어디 쇼 프로에 가상으로 출연시키려 해도 로봇 같은 엉성하고 경직된 모션을 보일 수는 없으니 1시간 분량의 동작과 입술 움직임을 아주 정교하게 만들어야 하는데 가히 억대의 돈이 깨졌다고 한다. 하지만 그 사이버 연예인이 음반 판매나 CF 촬영을 통해 그 이상으로 끊임없이 돈을 벌어 줄 능력이 있었느냐? 물론 그렇지 못했다.

아담소프트는 현란한 3D 그래픽 기술로 차라리 온라인 게임을 만드는 게 나았을지도 몰랐다. 리니지야말로 그 시절에 만들어진 게임인데 아직까지도 '린저씨'가 있을 정도이며, 개발사인 NC소프트 역시 건재하니까 말이다.

이 사이버 가수의 노래를 실제로 불러 주는 사람은.. 설마 보이스웨어-_-를 쓰는 건 아니고 역시나 얼굴 없는 가수를 고용한다. 사이버 가수의 신비주의를 책임지는 중요한 사람인 만큼 계약 기간 동안 자기 정체를 절~~~~~대로 대외적으로 까발려서는 안 된다고 단단히 약속을 한다.
하지만 사이버 가수의 개발사들이 이미 10몇 년 전에 망하고 다~ 지나간 일이 되니, 이제는 그 가수가 당당히 정체를 드러내는 지경까지 됐다. 다 지나고 보니 허무하기도 하다.

어디에서 유래되었는지 출처는 모르겠다만, "Video killed the radio star"라는 문구가 있다. 물론 자동차 운전사 같은 업종도 있으니 라디오가 싹 망하고 비디오에 몽땅 흡수되지는 않을 것이다. 그래도 어지간한 매체에서 비주얼을 이길 장사는 별로 없으며, 영화/드라마 배우와는 달리 성우나 연극 배우는 대우가 한 등급 낮은 게 현실이다. (재연 배우는 얼굴도 있고 엑스트라 단역도 아님에도 불구하고 처지가 좀 안습하다만..)

가수 업계에서는 CM 송, 만화 주제가 같은 걸 부르는 '얼굴 없는 가수'가 바로 그런 2류 등급에 속하는 것 같다. 그 사람들이 사회에 기여하는 바로 결코 작지 않지만 아무래도 대우가 인기 걸그룹에 비할 바는 못 된다.
그나저나 요즘은 걸그룹 트렌드에 밀려서 옛날과는 달리 여성 솔로조차도 찾기가 쉽지 않은 듯하다. 그 와중에 웬 트로트 <백세인생>(못 간다고 전해라...)의 갑작스러운 히트와 대박은 <참아 주세요>(뱀이다~ 개구리다~)에 이어 참 신선하고 이색적으로 느껴진다.;; 이런 식으로 중· 노년이 돼서야 인생에 리즈 시절이 뒤늦게 시작되는 사람도 있는 모양이다.

Posted by 사무엘