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

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

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에게도 임한 게 분명하다!!

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

최근에 이 사이트에서 해 본 테스트에서 본인은 절대음감 인증을 받았다. 그냥 대충 찍은 것도 많고, 좀 더 집중해서 문제를 풀었으면 더 높은 점수가 나올 수도 있었겠지만, 어쨌든 이 정도도 그리 나쁜 점수는 아니니까. 둘 다 36점 만점인데, 확실히 순수 싸인파가 피아노 소리보다 훨씬 더 분간하기 어렵다.

하긴, 유니클락 배경 음악을 들으면서도 난 이런 생각이 바로 들었다.
“이 곡 템포는 정확하게 ♩=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 사무엘

잘 알다시피 <날개셋> 한글 입력기는 Windows용 한글 IME이다(IME이기만 한 건 아니지만). 이 분야는 경쟁 프로그램이 거의 없다시피하기 때문에, MS가 직접 공급하는 IME를 제외하면 3rd party 한글 IME 중에서는 <날개셋> 한글 입력기가 가히 독주를 하는 중이다. 그 이유로는,

첫째, 모바일용도 아니고 PC용으로는 한글 입력 방식이 딱히 더 만들 게 없다고 여겨지고 있어서인 것 같다. 그리고 딱히 돈이 되는 것도 아니니까 말이다. 싸제 IME가 활발히 쓰이고 있는 중국어· 일본어 IME의 개발 환경과 비교했을 때 이것이 크게 다른 점이다.

그리고 둘째로는, 윈도우용 IME라는 게 여타 운영체제의 IME와 비교해 보더라도 그 아키텍처와 스펙이 미치도록 폐쇄적이기 때문이다. 비록 프로토콜이 공개돼 있는 건 있지만, 그것만 참고해서는 쌩쌩 잘 돌아가는 한글 IME를 절대로 만들 수 없다. 문서화되지 않은 무수히 많은 상황에 대한 대비를 해야 되는데 이걸 이제 와서 혼자 처음부터 만든다는 건 불가능에 가깝다.

그럼에도 불구하고 <날개셋> 한글 입력기 말고 ‘싸제’ 한글 IME가 전혀 없는 건 아니다. 본인은 MS가 개발하지 않은 한글 IME를 최소한 두 종류를 더 알고 있다.

※ 새나루

윈도우 DDK에 등재되어 있는 FakeIME라는 일본어 예제 IME를 고쳐서 만들어진 한글 IME이다. 오픈소스 진영에서 만들어진 프로그램답게 소스 공개이다. 개발자들은 본인처럼 아예 대놓고 국어 정보학 쪽으로만 발을 들인 것도 아닌데 이쪽으로 조예가 굉장히 깊은 고수 프로그래머이다.

싸제 IME답게 여러 실험적인 기능이 많아서 실속이 있으며, 그러면서도 <날개셋>보다 덩치 작고 가볍다는 이점이 있다. 특히 <날개셋>이 개발 방향의 특성상 의도적으로 더 지원하지 않는 다음 기능들 때문에 새나루를 선호하는 사람도 있다.

키보드 드라이버 차원에서 드보락 글자판과의 연동: 쉽게 말해, 단축키까지 드보락 식으로 나오면서 그 상태에서 한글 입력까지 지원.

글자가 아니라 단어 전체를 조합으로 잡아서 단어 단위로 한자 치환: 일부 한자 혼용론자가 무척 좋아하는 기능이라 한다. MS IME로는 이 기능은 TSF A급 프로그램에서만 가능하며, <날개셋> 한글 입력기 역시 훗날 이 기능을 추가한다 하더라도 MS IME처럼 TSF A급에서만 지원할 것이다.

이 외에도 잘은 모르겠지만, 안 마태 키보드 드라이버도 입력 스키마를 살짝 변조한 수준에 머물러 있는 <날개셋>보다 새나루가 좀 더 지원을 잘 하는 게 있는 듯하다.

다만, 새나루의 개발자는 <날개셋>의 개발자처럼 한글 입력기 하나에만 완전 목숨을 건 타입은 아니다 보니, 프로그램의 유지· 보수와 버전업이 <날개셋>만치 애착을 갖고 꼬박꼬박 되고 있는 건 아니어 보인다. 하긴, 무료 소프트웨어가 이 정도라도 개발되어 온 게 감지덕지지.

※ Unicode CJK IME

이건 아는 분이 얼마 없지 싶다. 이건 무려 남북 합작으로 개발된 프로그램이다. 주 개발은 북한의 평양 정보 센터(PIC)에서 했으며, 남한의 한국 과학 기술 정보 연구원과 고려 대학교 민족 문화 연구원은 프로그램을 설계하고 각종 한자 데이터베이스를 구축했다. PIC는 서체도 만들고 ‘단군’이라는 워드 프로세서도 개발한 적이 있을 정도로 문자 처리 쪽에 기술이 상당한 수준이다. 그러니 IME도 만들었다.

세벌식은 전혀 지원하지 않지만, 남북 합작 IME 답게 북한 두벌식을 지원한다. 그리고 한양 PUA 방식의 옛한글을 지원하며, 문자표, 부수로 한자 입력, 자체 한자 사전 등의 기능을 내장하고 있다.

제목에서 알 수 있듯, 이 제품은 한글 IME뿐만이 아니라, 동일한 UI 엔진 기반으로 개발된 중국어· 일본어 IME와 한 세트를 구성하고 있다. 북한에서 그런 것까지 만들었다. 하지만 이들 IME의 성능(사전 크기 및 어절 분할 정확도)은 본인이 판단하기에 운영체제가 기본 제공하는 중국· 일본어 MS IME보다 못하다.

이런 프로그램들과는 달리, <날개셋> 한글 입력기는 처음에는 전용 에디터로만 개발되고 있었다. 2.x 시절까지만 해도 본인은 내가 스스로 한글 IME를 만들 수 있을 거라고 생각도 못 하던 처지였다. 그랬는데 2003년은 참으로 드라마틱하게도 한글 IME 개발의 원년으로 등극하게 되었다.

새나루는 2003년 말에 첫 버전이 나왔다. 그리고 본인이 접한 Unicode CJK IME 역시 2003년 6월자 버전이었다(다만, 그 후로 유지 보수는 중단된 듯). 그리고 그 해 가을에 출시된 MS 오피스 2003은 한자 변환 기능이 크게 강화되어 단어 단위 한자 변환이 처음으로 도입된 버전이었다. 이게 다 우연인 걸까?

이런 일련의 사건을 계기로 본인은 운영체제의 IME 스펙을 처음으로 공부하기 시작했으며, <날개셋> 한글 입력기를 운영체제의 IME로 거듭나게 하려는 연구를 난생 처음으로 시작했다. 마침 2003년 하반기이면 <날개셋> 한글 입력기 역시 3.0이 개발 중이었고, 입력기의 내부 구조를 싹 뒤집어 엎고 있었다. 나의 대학 3학년 시절, 이때가 <날개셋> 한글 입력기의 미래를 결정하는 개발이 이뤄지던 시절이었으니, 흥미롭지 않을 수 없다.

그래서 <날개셋> 한글 입력기에 좀 이렇다 할 외부 모듈이 난생 처음으로 탑재된 건, 2004년 9월에 나온 3.02 버전이다. 한글 입력기를 표방하면서 정작 윈도우용 IME가 나온 것은 새나루나 남북 합작 IME보다 시기적으로 늦다.

첫 버전은 당연히 정말 불안정했고 볼품없는 퀄리티였다. 아직 운영체제의 IME 시스템의 내부 구조를 제대로 이해 못 한 상태에서 최소한의 글자 찍기만 가능하던 상태였다. 이 때문에 직후 버전인 3.1에서 당장 무더기 버그 패치가 이뤄졌으며, 그 후로 외부 모듈이 큰 안정화 단계를 마치기까지는 1년이 넘는 시간이 더 필요했다.

그러나 첫 진입 단계에서 이런 시행착오를 충분히 겪은 뒤엔, 워낙 탄탄한 자체 한글 입력 시스템을 갖추고 있던 <날개셋> 한글 입력기가 완성도 높은 윈도우용 IME로 완전히 자리잡게 되었다. TSF 인터페이스를 이용해 bksp 달라붙기 같은 <날개셋> 고유 기능까지 그럭저럭 재연해 냈고, 심지어 윈도우 95부터 오늘날의 7까지 모든 운영체제를 지원하는 최적화까지 덤으로 구현했기 때문이다.

<날개셋> 한글 입력기는 이런 내력을 거쳐 지금과 같은 모듈들이 잘 개발되었다. 하지만 IME(외부 모듈)이 첫 개발되던 그 시절을 본인은 지금도 잊을 수 없으며, IME 모듈의 개발에 영향을 끼친 위의 두 프로그램들에도 나름 애착을 갖고 있다.

Posted by 사무엘

예전 글에서는 지하철 회사별로 전동차 차량 기지가 있는 곳을 열거한 적이 있는데, 이번에는 회사들의 본부가 있는 곳을 나열해 보겠다. 차량 기지와 회사 본사는 일반적으로 다른 개념이다. 그리고 요즘은 민자 철도가 많아져서 회사 나열하기도 좀 복잡해져 있다.

1. 코레일 (국철들..)

코레일은 잘 알다시피 전국의 거의 모든 철도를 관할하는 거대한 기업이며, 광역전철은 내부의 일개 사업 파트일 뿐이다. 그래서 코레일의 본부는 국토의 중앙으로서 상징성이 높은 대전에 있다. 코레일의 전신인 철도청은 원래 정부 대전 청사의 내부에 있었지만, 공사로 바뀐 뒤에는 이제 정부 부서가 아니기 때문에 거기서 나왔다. 대전 역 근처에 철도 시설 공단과 나란히 쌍둥이 사옥을 완공하여 거기에 입주했다.

코레일은 여기 말고도 지역별 관할 기관이 있다. 서울 본부는 서울 역 북부에 있으며, 사실 광역전철 사업 본부도 이곳에 자리잡아 있다. 이 외에도 수도권 동부 본부는 잘 알다시피 신이문 역 근처에 이문 차량 기지와 같이 입주해 있으며, 수도권 서부 본부는 영등포 역 근처에 있다. 끝으로, 철도 교통 관제 센터는 구로 차량 기지 내부에 있다.

2. 서울 메트로 (서울 지하철 1~4호선)

최초의 서울 지하철이 강북 종로선이고 2호선도 강북의 신설동-종합운동장 구간이 가장 먼저 개통한 만큼, 관할 회사의 본부가 강북 사대문 안의 어딘가에 있을 것 같기도 하다. 하지만 그렇지는 않다. 현재 서울 메트로 본사는 사당 역 근처에 있다. 강북은 아니어도 나름 중요한 환승역이 있는 지점이고, 한때 지하철 4호선의 남쪽 종점이기도 한 곳이다.

서울 메트로는 원래 이름이 서울 지하철 공사였고, 그 전신은 지하철 건설 본부로 거슬러 올라간다. 이때는 본부가 서울 시청 내부에 있었지만, 지금처럼 건설과 운영을 분리한 별도의 운영 회사는 1981년에야 생겼다. 지금의 사당동 사옥은 지하철 2호선이 건설되고 있던 1983년에 완공되었다.

3. 서울 도시철도 공사 (서울 지하철 5~8호선)

서울 2기 지하철 중 5호선은 1996년에 가장 먼저 전구간이 개통했다. 1994년에 먼저 설립된 도철은 본부가 천호대로 근처에 있으며, 그 5호선 답십리와 장한평 역의 중간에 있다. 거기는 5호선 중에서도 가장 먼저 개통한(1995년 가을) 구간인 왕십리-상일동의 구간에 속하기도 한다.

이곳 인근에는 차량 기지처럼 생긴 시설이 있는데 이건 재미있게도 도철이 아닌 서울 메트로 관할의 군자 차량 기지이다. 2호선 지선의 용답 역의 이름이 처음에는 ‘기지’ 역이었다.
2007~08년 사이에는 5호선 전동차가 답십리나 장한평 역에 도착할 때 “5 6 7 8 서울 도시철도는 답십리/장한평 역 n번 출구 근처에 있습니다” 비슷한 멘트를 잠시 들려 주기도 했다.

4. 서울9호선운영 주식회사 / 서울시메트로9호선 주식회사 (서울 지하철 9호선)

여타 철도/지하철 회사와는 달리, 서울 지하철 9호선을 운영하는 회사는 민간 기업이다. 게다가 회사가 하나가 아니라 둘이다.
먼저, '메트로'라는 단어가 없는 서울9호선운영 주식회사는 프랑스의 다국적 대기업인 베올리아의 자회사가 상당수의 지분을(80%) 출자하여 설립한 일종의 외국 자본 회사이며, 이 회사가 서울시메트로9호선 주식회사라는 국내 중소기업에다 또 위탁을 줘서 9호선 전동차를 굴리는 형태라고 생각하면 될 것 같다. 뭔가 복잡하다.
9호선 운영사의 본사는 서쪽 종점인 개화 역, 아니 개화 차량 기지와 일체로 존재한다. 차량 기지와 운영 본부를 일체로 만든 첫 사례이다.

5. 코레일 공항 철도

건설 당시에는 공항 철도의 명칭이 '인천'의 이니셜을 딴 IREX이다가 나중에 AREX로 바뀌고, 다시 정식 명칭이 '코레일 공항 철도'로 바뀌었다(코레일의 자회사). 공항 철도의 운영사는 영종도로 가기 직전에 본토의 마지막 역인 검암 역 근처에 본사가 있다. 2차 개통 후에는 열차가 검암 행과 인천 공항 행이 번갈아가며 운행되고 있으니 여기가 일종의 중간 회차 지점이기도 하다.

6. 신분당선 주식회사

신분당선은 서울 디자인 정책의 영향도 없고, 요금까지 독자적으로 걷고 있어서 민간 사철의 성격이 가장 강한 노선이다. 이곳 역시 사업 운영자는 외국계 네오트랜스라는 회사이고 사업 시행자는 신분당선 주식회사로, 서울 지하철 9호선과 비슷한 이중 형태로 운영되는 중이다.
신분당선은 신규 개통 구간으로서 상징성이 높은 판교 역 근처에 본사가 있다. 이곳에서는 신분당선을 한창 DX Line이라고 홍보하는 중이다.

그나저나 얘들은 아직 독립적인 차량 기지도 없어서 전동차가 코레일의 분당 차량 기지에 아직 세들어 사는 중임.

7. 인천 교통 공사 (인천 지하철)
지하철 회사에 메트로나 도시철도 공사가 아니라 교통 공사라는 명칭을 쓰는 도시는 현재 부산과 더불어 인천 이렇게 둘이 있다.
인천 지하철을 관할하는 이 회사는 간석오거리 역 근처에 있으며, 따라서 동암 역하고도 비교적 가까운 편이다.

8. 대전 도시철도 공사
갑천 역 근처에 본사가 있다. 의외로 대전 지하철 1차 개통 구간에서는 좀 떨어진 곳이다. 그냥 정부 대전 청사 일대에 있을 법도 한데 말이다.

9. 대구 도시철도 공사 (대구 지하철 1~2호선)
1호선 서쪽 외곽의 상인 역 근처에 본사가 있다. 앞으로 모노레일 형태로 도시철도(지하철은 이제 아니니;;) 3호선이 건설될 예정인데, 이 노선 또한 이 회사가 운영하게 된다.

10. 광주 도시철도 공사
상무 역 근처에 있다. 이 역은 지하철의 1차 개통 당시에 서쪽 종점이기도 했다.

11. 부산 교통 공사 (부산 지하철 1~4호선)
이름은 뭔가 범용적인 뉘앙스가 풍기는 '교통 공사'이지만, 이 회사는 여전히 지하철들만 관할하고 있다. 뭐, 이는 경전철인 4호선까지 포함한 것이고 그것만으로도 영역이 충분히 크긴 하지만 말이다. 1호선 범내골 역 근처에 본사가 있다.

12. 부산-김해 경전철 주식회사

부산-김해 경전철은 부산 지하철과는 격이 다르다. 신분당선이나 9호선과 같은 수준의 민영이다. 그래서 노인에 대해서 경로 승차권은 발급하지만 완전 무료는 아닌 독자적인 운임 체계도 쓰고 있다.
부산-김해경전철운영 주식회사와 부산-김해경전철 주식회사 이렇게 둘로 나뉘어 있는데, 운영 주식회사는 외국 자본 기반이 아니다. 70%의 지분을 다름아닌 '서울 메트로'가 가지고 있다.

본사는 서쪽 끝의 가야대 역에서도 더욱 외곽인 차량 기지 안에 같이 있다. 이 역시 9호선과 유사하다.

Posted by 사무엘

국가 원수가 사용하는 관용(官用) 교통수단 중 일부는 우리에게 잘 알려져서 친숙하다.

천조국인 미국은 Air Force One이라는 보잉 747 개조 비행기가 있는 걸로 유명하며 이걸 소재로 영화가 만들어진 적도 있다.
내 기억이 맞다면 2005년에 미국 부시 대통령 가족이 한국을 방문했을 때, 우리나라에서는 전투기까지 보내 에어 포스 원을 엄호하면서 서울 공항으로 안내를 해 줬다.

우리나라는 대통령 전용기가 없는 건 아니나, 덩치가 작고 한 번에 끽해야 동남아 정도까지밖에 못 간다고 한다. 그래서 대통령이 어디 멀리 나갈 일이 있을 때는 결국 대한 항공 여객기를 그때 그때 전세 내서 쓰고 있다고 본인은 들었다.

비행기 말고 자동차도 있다. 최고급 최고 성능 승용차인 건 말할 것도 없으며, 지뢰를 밟아서 터져도 내부 승객이 다치지 않을 정도로 튼튼한 장갑이 바닥에 장착되어 있다. 유리는 당연히 몇 겹으로 방탄 처리가 돼 있고, 차 내부에서는 밖이 보이지만 밖에서는 안이 보이지 않게 특수한 도장 처리가 되어 있다.
(그럼에도 불구하고 미국의 케네디 대통령은 그런 거 필요 없다며 서민적인 이미지 어필을 위해, 천장을 완전히 개방하고 신체를 노출한 채 차량 퍼레이드를 하다가, 어느 저격수의 총에 머리를 정통으로 맞고 세상을 떠났다.)

국가 원수가 이용하는 교통수단은 이런 하드웨어적인 보안 시설뿐만이 아니라 보안을 유지한 운영도 매우 중요하다.
동일한 차체를 둘 이상 보유하고 있는 건 필수. 둘의 스케줄을 서로 다르게 유지한다. 차량의 경우, 아예 동일한 차를 다섯 대씩 연달아 지나가게 하고 그 중 대통령은 완전 random한 차에 무작위로 탑승시키기도 한다.

실제로 일제 강점기 때, 우리나라의 모 독립 운동가 중에서도 이 테크닉 때문에 일제 요인의 암살에 실패한 사례가 있었다. 내 기억으로는 사이토 총독을 폭탄으로 암살하려다 실패한 강 우규 의사로 알고 있었는데, 자료를 다시 검색해 보니 내가 원하는 사건이 안 나온다. 정확히 누구인지는 잘 모르겠다.

아무튼, 이런 높으신 분이 탄 차는 세워서는 안 되고 끊임없이 움직이게 해야 한다는 게 중요하다. 그래야 안전하기 때문. 그래서 이런 관용차가 한번 납시면 당연한 말이지만 주변 도로를 다 틀어막고 관용차를 최우선순위로 통과시킨다.

비행기와 자동차까지 얘기가 나왔고 이제야 철도 차량 차례이다. 열차는 어떨까?
일단, 북한 뽀글이 아저씨가 중국 갈 때 맨날 열차를 애용했다는 게 잘 알려져 있는데, 그건 그냥 고소공포증이 있고 겁이 많아서일 뿐 그가 딱히 철덕이어서 그런 건 아니라는 것도 역시 잘 알려진 사실이다.

걔네들은 먼저 경호원의 열차가 지나간 후 2~30분쯤 뒤에야 김 정일이 탄 열차가 지나가고, 또 나중에 경호원의 열차가 또 지나가는 형태라고 한다. 열차 안은 미국의 에어 포스 원과 마찬가지로 어지간한 집무 환경이 다 갖춰져 있고, 요양/의료 시설도 있다.

철도는 역까지 가야 이용할 수 있고, 갈 수 있는 곳이 제한적이기 때문에 환승이 불가피하다. 국가 원수 정도 되는 인물이라면, 어지간하면 그냥 자동차나 비행기를 이용하는 게 훨씬 더 낫지 굳이 열차를 타야 할 필요는 없을 것이다. 청와대 밑으로 비밀 선로와 철도역이 놓여 있지 않은 한 말이다.

다만, 비행기를 띄울 수 없을 정도로 날씨가 너무 안 좋고 도로까지 마비된 상황이라면 열차도 좋은 고려 대상이 되겠다.
옛날에 6· 25가 터졌을 때 이 승만 대통령과 참모진은 열차를 타고 피난을 갔다. 그때는 고속도로도 없었고 포장 도로 자체가 거의 없던 시절이어서, 자동차로는 서울-대전만 해도 4시간~8시간씩 걸렸다. 그러니 그때는 철도가 가장 빠르고 편한 육상 교통수단이었다. 경부 고속도로가 완성되기 전까지는 박 정희 대통령도 관용 열차를 애용했었다.

이제야 이 글의 결론이 나온다.
대한민국에는 현재 대통령을 위한 관용 열차라는 게 있다. 그 열차의 이름은 ‘경복호’이다. 김 대중 정권 시절에 2001년에 한진 중공업(로템 통합 직전이었던 듯.)에 의뢰하여 만들어진 4량짜리 열차 2편성이 있다. 그때 막 남북한 철도 연결 떡밥이 나돌기도 했으니 말이다. 경의선 도라산 역이 개통했을 때 경복호가 김 대통령을 태우고 실제로 운행된 바 있다.

(사진 출처는 기억 안 남. 내가 찍은 건 당연히 아니고, 지금 인터넷에 나도는 저 포즈의 경복호 사진은 모두 동일 인물이 찍은 것임.)

경복호는 언뜻 보기에 전후동력형 새마을호 열차처럼 생겼다. 하지만 객차의 창문 모양을 보면 국내에 여객 열차로 존재한 적이 없는 형태임을 알 수 있다. 스펙에 대해서는 많은 것이 국가 기밀로 여겨지고는 있지만, 객차수가 적고 관용차 특유의 성능 튜닝을 한 덕분에, 기존 새마을호의 최고 속력이 140km/h인 반면 경복호는 선로가 좋은 곳에서 160km/h까지도 낸다고 알려져 있다.

철도 덕후라면 잘 알듯이 한국 철도 ‘로지스’ 사이트에서는 여객과 화물 공히 전국 모든 열차 운행 스케줄을 조회할 수 있다. 그래서 심지어 신규 개통 전철 노선으로 반입되고 있는 전동차까지 수송 경로를 추적해서 사진을 미리 찍는 철덕들까지 있다. 그럼에도 불구하고 경복호의 운행은 로지스에 당연히 뜨지 않는다. 이 열차의 스케줄은 코레일의 진짜 극소수 고위 간부만 알고 있다.

경복호는 통행 우선순위가 최상이며, 한번 떴다 하면 동일 운행 경로에 있는 열차들은 다들 깨갱+대피이다. 노 무현 대통령은 퇴임 후 고향 귀환을 KTX로 한 걸로 잘 알려져 있지만, 재임 중에 경남 지방으로 휴가도 경복호를 타고 몇 차례 떠난 적이 있었다고 한다. 그때 비슷한 구간을 달리던 여객 열차는 영문도 모른 채 괴열차를 먼저 기다렸다 보내 주느라 10~20분가량 지연을 먹어야 했다고 전해짐. 이때도 경복호 하나만 달랑 달린 게 아니라 선두와 후미에는 호송인 열차가 있었으며, 호송 열차 역시 겉모양은 PP형 새마을호이다.

어째, 경복호와 관련된 이야기는 보수 진영에서 좀 싫어하는 대통령들하고만 얽혀 있구나.
KTX만 해도, 대통령까지는 아니어도 1급 요원들이 몰래 타는 공간이 있는 KTX 모 편성 얘기가 철덕들 사이에서 나돌았는데, 아예 관용차가 있다는 얘기는 다소 생소할 것이다. 경복호는 코레일 직원들도 모르는 경우가 태반이다.

Posted by 사무엘

요즘 학교나 관공서의 전산망에서는 인터넷 접속을 위해서 특정 보안 솔루션 ActiveX들과 그것도 모자라서 바이러스 백신까지 무조건 설치하라고 강요하는 걸 볼 수 있다. 그걸 안 하면 사이트 접속이 되질 않게 해 놓았다.  허나 본인은 그런 보안 솔루션들에 대해 정서적으로 굉장한 반감을 갖고 있으며, 그것들을 몸서리치게 싫어한다.

여러 보안 솔루션 중 키보드 보안 프로그램이 하는 역할은 아마도 사용자의 키 입력(비밀번호 같은)을 메시지 훅킹으로 가로챌 수 없게 하고, 반대로 없는 키 입력을 소프트웨어적으로 생성할 수 없게 하는 일일 것이다(온라인 게임에서 오토의 실행 차단). 또한, 은행 돈거래 관련 정보가 담긴 패킷은 정보가 유출되더라도 의미 파악이나 변조가 거의 불가능하게 아주 복잡한 계산을 동원한 암호화/해독이 클라이언트에서 행해져야 할 필요가 있을 것이다. 그런 기술적인 필요를 본인은 모르는 건 아니다.

다만, 웹 표준만으로 도저히 구현할 수 없는 운영체제 커널 기술 수준의 보안이 불가피하게 필요하다면, 차라리 무리해서 웹 애플리케이션을 만드는 걸 포기하고 깨끗하게 로컬 환경에서 돌아가는 exe 형태의 프로그램과 배포 패키지를 만들었으면 좋겠다.

nProtect 부류의 이상한 프로그램들은 웹브라우저를 끈 뒤에도 계속 메모리 차지하면서 남아 있는 것 정도나 보기 싫은 수준이고 그나마 ‘낫다’. 하지만 이놈의 빌어먹을 백신은 답이 없다. 바이러스나 악성 코드에 걸리지 말라고 설치하는 솔루션들이, 깔고 나면 악성 코드나 그 이상 수준으로 민폐 끼치면서 컴퓨터 성능을 쪽쪽 갉아먹기 때문이다. 좀 심하게 표현하면 컴을 완전히 병신으로 만들어 놓는다.

마치 치안과 국방을 담당해야 할 자국의 정규군이나 경찰이 하라는 일은 안 하고 자기네들부터 민폐 끼치고 민간인들을 등쳐 먹는다거나, 반공을 빌미로 공권력이 심심하면 멀쩡한 생사람을 빨갱이로 몰아서 잡아 죽인다거나 하는 상황을 생각하면 되겠다.

맥북 이전 4대 노트북을 쓰던 시절의 일이다. 본인이 다니는 학교는 내부에서 와이파이로 인터넷에 접속할 때 NetCare인지 뭔지 하는 보안 ActiveX와 바이로봇 백신을 반드시 설치하도록 강요를 하고 있다. 둘 중 하나라도 설치를 안 하면, 몇몇 사이트는 아예 접속이 되지 않거나 쿠키가 저장되지 않아서 로그인을 할 수가 없으며, 되는 사이트도 보안 솔루션들을 설치하라고 협박하는 문구가 든 프레임이 웹사이트에 제멋대로 추가되어 나오곤 했다.

그래서 본인은 어쩔 수 없이, 울며 겨자 먹기로 마지못해 깔라는 것들을 다 설치해 줬다. 그러자 저런 성가신 현상이 모두 없어지고 인터넷은 잘 되기 시작했다. 그러나 그 뒤부터 내 컴에서는 끔찍한 헬게이트가 시작되었다.

부팅 직후에 시스템이 시작 메뉴 구동 같은 각종 조작에 응답하는 속도가 눈에 띄게 느려졌고, 웹브라우저가 페이지를 여는 속도, 전반적인 파일 액세스 속도도 인내심의 한계를 느끼는 수준이 되었다. 최대 절전 모드에서 복귀하는 시간까지 예전보다 훨씬 더 길어졌다. 멀쩡하던 컴퓨터가 진짜 만신창이 장애인이 된 느낌이었다. 평상시에 운영체제의 메모리 사용량도 예전보다 수십 MB가량 늘었다.

나는 운영체제의 업데이트들은 목록만 자동으로 받게 한 뒤, 다운로드와 설치는 내가 지정한 것만 수동으로 하게 해 놓고 있었다. 그랬는데 그 보안 솔루션은 나의 설정을 씹고, 인터넷만 됐다 하면 마구잡이로 온갖 업데이트들을 제멋대로 받아서 설치했다.

언제부턴가 MS 오피스가 SP2이던 게 느닷없이 SP3으로 바뀌어 있었다. 프로그램이 버전업되어서 좋은 게 아니라 도리어 부아가 치밀었다. “이 자식, 지금까지 왜 이리 느리고 쓸데없이 디스크 액세스를 하는가 했더니, 그 수백 MB짜리 업데이트를 내 동의도 없이 제멋대로 설치하느라 그랬군.” 하는 생각에 말이다.

참다못해 하루는 넷케어고 백신이고 전부 다 모조리 지워 버렸다. 요즘은 백신도 용량이 몇백 MB 수준으로 뭘 하느라 그리도 커졌는지 모르겠다. 이것들을 다 지우고 나자 내 컴퓨터는 거짓말처럼 평화가 찾아왔다. 모든 성능이 예전 상태로 돌아갔다. 보안 솔루션들이 그들의 퇴치 대상인 악성 코드가 하는 짓을 동일하게 하고 있음이 입증된 순간이었다.

이제 맥북을 사용하면서 뜻하지 않게 얻은 큰 수확이 있다. 보안 솔루션 제약은 Windows 운영체제에만 적용되며, 맥에서는 그런 게 전혀 없이도 인터넷을 곧바로 자유롭게 이용할 수 있다는 것. 야호! 빌어먹을 넷케어니 바이로봇 따위를 설치하지 않아도 된다. 맥OS가 날 구했다. 스잡빠니 애플빠니 난 그딴 건 모르지만, 어쨌든 이거 덕분에 맥OS 호감도가 급상승했다.

한편, 고향에서도 비슷한 일을 최근에 겪었다. 고향집 컴퓨터가 언제부턴가 병신 중의 상병신이 돼 있었다. 부팅 후에 시작 메뉴를 눌러도 한참 동안 반응이 없고, 웹브라우저를 띄운 뒤에 창이 나타나기까지 몇 분이 족히 걸리고 있었다. 레지스트리나 파일 디렉터리를 살펴봐도 딱히 악성 코드에 걸린 것 같지는 않은데 영문을 모를 노릇이었다.

이 현상의 주범은 바로 V3 Lite였다. 이놈을 당장 지우자 컴퓨터는 운영체제를 갓 설치한 직후처럼 아주 쌩쌩해졌다! 그러니 난 도대체 진짜 악성 코드란 어떤 놈인지 가치관의 혼란을 겪을 수밖에 없었다.

바이러스가 묻은 메일 첨부 파일을 클릭한 것도 아니고, 이상한 사이트를 돌아다니다가 ActiveX 설치에 ‘예’를 누른 것도 아니었다. 이 V3은 어머니께서 집에서 인터넷으로 업무를 보시기 위해 어쩔 수 없이 설치한 것이었다. 이거랑 무슨 희한한 듣보잡 ActiveX들을 설치하지 않으면 직장의 업무 자동화 시스템에 접속이 되질 않기 때문이었다.

이런 일련의 사건을 겪은 뒤, 나는 더욱 더 백신 따위는 죽어도 절대로 쓰지 말아야겠다는 생각을 굳게 하게 되었다. 옛날처럼 백신이 그냥 사용자가 요청할 때만 파일이나 메모리를 스캔하면서 바이러스 검사를 해 주던 시절이 그립다. 저런 거지 같은 잉여 쓰레기 프로그램을 얹고도 작업을 원활하게 하려면, 가히 정말 최신식 최고급 컴퓨터를 써야겠다. 아니, 내 컴퓨터가 아무리 빠르고 메모리가 썩어 넘친다 해도 저런 프로그램에게 컴퓨터 자원을 내어 주기는 싫다.

보안을 빌미로 원치 않는 프로그램의 설치를 강요하는 이런 못돼먹은 풍조가 좀 없어졌으면 하는 바람이 있다. 이런 일이 계속될수록 이에 대한 반발 심리로 나의 컴퓨터 보안 위협 불감증은 더욱 커질 것이다.

Posted by 사무엘

지난 3월 24일, 맥북 프로 13인치형 모델이 본인의 제 5대 개인용 노트북 PC로 취임했다.
본인이 고등학교 시절부터 노트북 PC를 사용한 이래로 14년 만에 애플 계열 컴퓨터를 개인용 컴퓨터로 장만하게 되었다.

지금까지 사용하던 제4대 노트북은 2008년 5월에 도입되었고 윈도우 비스타 + 코어2 Duo 기종이었다. 오늘날의 PC 기준으로는 완전히 구닥다리로 전락한 셈.
좀 나중에 석사 졸업 기념으로 컴을 바꿀 생각이었지만, 마침 고향에서 부모님께서 새 컴퓨터가 필요하다고 하여 지금 내가 쓰던 걸 고향으로 보내고 나는 새 컴을 예정보다 더 일찍 장만하게 됐다.

초대 노트북은 분실, 2~3대 노트북은 고장 폐기였던 것에 비해, 4대 노트북은 약 4년에 가까운 임기를 마친 후 비교적 명예롭게, 그리고 예상보다 살짝 더 일찍 은퇴했다. 빠진 키캡 정리와 하드디스크 정리, 사소한 접촉 불량 수리 같은 정비를 받은 후, 고향으로 갔다.

지금까지 정말 유용하게 잘 사용해 왔고 키보드와 터치패드의 모든 감도가 손에 착 익은 정든 놈이긴 하지만, 이제 성능이 너무 뒤쳐졌고 액정 화면도 슬슬 누렇게 뜨는 등 노후화의 기미는 피해 갈 수 없었다. 물론 이것도 고향에 있는 컴퓨터보다는 훨씬 더 좋은 기종이다. 지금까지 부모님께서 쓰시던 컴은 이제 정말로 갖다 버릴 때가 됐고.. ㅜㅜ

구입한 새 노트북에 대해 스펙 차원에서 좀 아쉬움을 감수한 것은,
운영체제를 두 개나(윈도우와 맥 모두) 쓰는 것치고는 좀 부족한 감이 있는 하드디스크 용량.
그리고 지금 노트북보다 화면 해상도 픽셀수가 가로와 세로 모두 떨어진다는 점이다.
게다가 4:3이 아닌 요즘 대세인 와이드 화면을 쓰는 만큼, 이제 task bar를 가로가 아닌 세로로 배열해야겠다.
이질적인 키보드· 마우스 사용법은 덤.

Windows 운영체제는 내가 알아서 장만이라도 해서 깔아야 하는지 우려됐는데(OS 자체의 설치는 그렇다 치더라도 각종 드라이버들은 어떻게 잡으라고!!), 다행히 웃돈만 주면 판매처에서 아예 알아서 설치까지 한 채로 제품을 준다고 해서 안심을 했다.

Windows에다가는 단골 18번지 프로그램들을 설치해서 내가 늘 하던 일만 쭉 하고, 오픈소스 크로스 플랫폼 형태로 존재하는 프로그램들은 가능한 한 맥용으로 설치하는 방법으로 맥OS에 차츰 적응을 해 나갈 생각이다. 물론, 단골 18번지 프로그램들이 다들 단순 취향을 넘어서 내 생업과 관련된 일들을 하기 때문에, 나는 Windows를 아주 떠나서 살 수는 없다.

당장 개발툴만 예로 들어 보면, Windows에다가는 비주얼 스튜디오를, 맥에다가는 xcode와 Eclipse를 설치했다. 이클립스를 굳이 윈도우에다가 설치할 필요는 없으니까. 나도 드디어 윈도우 7 + 비주얼 스튜디오 2010으로 완전히 갈아탔다. 거기에다 호환성 차원에서 2003도 여전히 설치.

나는 <날개셋> 한글 입력기를 혼자서 만들었을 정도로 Windows 환경 개발에 정통한 것에 '비해서'는 여타 운영체제를 너무 안 다뤄 봤고 너무 모른다. 가령, 그 정도 기술 수준의 프로그램을 만들 줄 알면서 유닉스 명령을 나 정도로 모르는 사람은 별로 없지 싶다. 지금까지 쓸 일이 없었으니까. 오로지 Windows 독식이었다.

그런 와중에 이번 맥북 장만은 약간 risk도 감안하면서 내린 결정이긴 하다만, 15년에 가까운 나의 Windows 독점 풍토에 뭔가 새로운 바람을 수혈해 넣을 거라는 기대를 해 본다.
비록 나는 이제 예전에 맨대가리 헤딩으로 프로그래밍에만 매달려서 윈도우 API를 공부했듯이 맥OS API를 새로 처음부터 공부할 수 있을 것 같지는 않지만... 그래도 사람 미래라는 건 알 수 없으니까 말이다.

같은 데스크톱급 PC로도 모자라서 스마트폰은...;; 글쎄다. 이것도 언젠가는 안드로이드든 아이폰이든 써 보면 좋을 것 같지만, 딱히 길 안내 기능 말고는 그 돈까지 주면서 일부러 앞장서서 사서 쓸 매력을 느끼지는 않는다. PC에서 벌여 놓은 일이 너무 많아서 이것저것 다 쫓아가다간 다 놓친다. pruning이 필요함.

컴퓨터를 새로 세팅하다 보니, 이제 운영체제와 각종 소프트웨어들을 온통 업데이트해 줘야 하고, 맥 기반 개발툴들도 다 인터넷을 통해서 구해야 한다. 고로 수백~수 GB에 달하는 트래픽이 예상되는데, 언제 날잡아서 안정적인 유선 네퉉으로 해치워야겠다는 생각이 든다.

Posted by 사무엘

현재 윈도우 운영체제의 GUI는 잘 알다시피 윈 2000/ME까지 유지되던 고전 테마, 그리고 XP 테마와 비스타/7 테마가 서로 따로 논다.
MS 오피스도 XP/2003/2007이 따로 놀고,
거기에다가 비주얼 개발툴의 디자인도 2005/2008/2010이 다 달라진다.

어디 그뿐인가. 현재 운영체제의 configuration에 따라 테마가 나타나는 모양도 달라져야 한다. 가령, 오피스 2003은 전반적으로 파란 색상이지만 운영체제가 회색 고전 테마일 때는 은색이 깔림. 그 반면 오피스 2007은 독자적인 배색 컨셉이기 때문에 운영체제의 상태에 관계 없이 여전히 은은한 하늘색 색상이 되는 게 맞다.

이런 세세한 알고리즘은 reverse engineering이라도 해서 알아내야 할 텐데, GUI 툴킷 만드는 일은 정말 장난 아니게 어려울 것 같다. 아래아한글의 스킨을 개발하는 팀도 고생 무지하게 했을 거라는 생각이 든다. 차라리 운영체제 GUI를 완전히 생까던 9x  시절이나, 반대로 잠시 100% 운영체제 표준 GUI만 따르던 워디안 시절이 나았겠다.

자, 이렇게 GUI 비주얼들이 난립하고 기존 MFC는 이런 수요를 충족하지 못한 채 시간만 자꾸 흐르고 있었다. 그러던 차에 MS는 결단을 내렸다. 바로 비주얼 C++ 2008 플러스 팩. MFC42 시절 이래로 MFC에 대대적으로 기능을 추가하여 역대 오피스와 비주얼 툴들의 UI, 그리고 심지어 리본 UI까지 MFC에다 넣어 줬다.

MFC의 새단장 소식이 전해지던 당시, 많은 개발자들은 MS가 자기네 오피스 팀이 개발한 오리지널 GUI 소스를 리팩터링해서 전해 줄지 무척 기대했었다. 하지만 아쉽게도 그건 아니고, 이미 BCG라는 러시아 회사에서 개발하여 판매 중이던 제3자 라이브러리를 MS라는 브랜드만 넣어서 제공하는 형태가 되었다. MS의 GUI는 MFC를 써서 개발된 것도 아니고, 모듈 구조를 보아하니 외부에 선뜻 떼어 줄 만한 상태가 아닌 모양이다.

이 작업의 결과로 MFC DLL은 덩치가 정말 크고 아름다워져서, 1MB 초반이던 게 4MB를 훌쩍 넘어갔다. CWinApp, CFrameWnd는 새로운 GUI 기능과의 연동을 위해, Ex라는 접미사가 붙은 CWinAppEx, 그리고 CFrameWndEx라는 파생 클래스가 추가되었다.

그런데, MS가 제3자 중에서도 왜 하필 BCG 라이브러리를 선택했는지에 대해서 불만을 제기하는 사람이 있다. 김 민장 님이 굉장히 옛날에 쓰신 개념글을 하나 읽어보자.

특히 메뉴의 글씨의 크기가 작은 것은 비주얼 C++ 2008/2010에서까지 그대로 이어져 오고 있는 걸 본인 역시 확인했다. 이건 꽤 심각한 문제인데? (왼쪽이 good, 오른쪽이 bad)

도대체 왜 이렇게 동작하는 걸까? 궁금해서 MFC의 소스를 들여다봤다. 내가 발견한 문제점은 두 가지이다.

afxglobals.cpp를 보면 MFC의 GUI 구성요소들이 한데 공유하는 GDI 오브젝트들이 한데 모여 있으며, 그 중에는 글꼴 오브젝트도 응당 있다. 그런데 여기 생성자를 보면,

m_bUseSystemFont = FALSE;

로만 되어 있고, SystemFont라고 MFC 소스 전체를 검색해 봐도 이 값을 바꾸는 멤버 함수 같은 건 어디에도 나오지 않는다. 메뉴의 글씨체는 운영체제의 시스템 글꼴로 나오는 게 일반인데(한글 윈도우의 고전 테마에서는 그냥 ‘굴림’처럼), 저게 TRUE가 아닌 FALSE인 한은 운영체제 한글 윈도우 고전 테마 + 오피스 구버전 테마 모드에서도 메뉴의 글꼴은 Segoe 내지 Tahoma로 자기의 독자적인 글꼴로 출력된다.

그리고 더 큰 문제는 UpdateFonts 함수에 있다. Adjust font size라는 주석 하에

if (nFontHeight <= 12)
    nFontHeight = 11;

라는 글꼴 보정 코드가 있다. 그런데 이 잘못된 보정 때문에 BCG 툴킷이 정상보다 글씨가 작게 찍힌다. 도대체 이 코드가 왜 들어갔는지 모르겠다. 12픽셀이던 걸 11픽셀로 줄이면, 한글· 한자가 가장 잘 찍히는 9포인트보다 글자 크기가 한 단계 더 작아져 버린다. 아마 영문 오피스 2007의 글꼴이 여타 비주얼에도 획일적으로 적용되는 듯하다.

한눈에 봐도 MS 원본 프로그램과는 UI가 다르게 찍히는 GUI 툴킷을 최소한의 보정도 없이 MS가 자기 이름으로 어떻게 MFC에다 내장시켜서 내놓은 걸까? 물론 이런 시도조차 없는 것보다는 낫지만, 역시 네이티브 C++ 개발자로서 꽤 안타까운 일이다. 차라리 제3자 라이브러리 시절에는 소스를 고쳐서 라이브러리를 새로 빌드할 수라도 있지만, 그 거대한 MFC의 내부에 내장이 되어 버린 코드는 고칠 수도 없는 노릇이고.

김 민장 님의 블로그에 나와 있듯, BCG보다는 Codejock이라는 미국 회사에서 개발한 Extreme Toolkit이라는 GUI 라이브러리가 원본과의 고증(?)이 더 잘 돼 있고 품질이 좋다고 그런다.

이렇듯, MS는 자기네가 처음으로 구현한 기능을(뭐, 오피스 팀이니, VS 팀과는 다른 부서이지만) 외부 회사로부터 구현체를 사 오는 기묘한 방법으로 집어넣어서 MFC를 확장했다. 일단 MS 내부에서 MFC를 자기네 프로그램의 개발에 거의 안 쓴다는 점을 염두에 둘 필요가 있겠다. -_-;; 진짜로 워드패드와 그림판을 빼고는 거의 없다.

본인 역시 일단 중요 제품인 <날개셋> 한글 입력기를 MFC 없이 순수 API + 간단한 싸제 라이브러리만으로 개발하기 시작했으니, MFC와는 직접적으로 결별했다. 하지만 C++과 윈도우 플랫폼이 살아 있는 한, MFC의 중요성과 의의는 그리 금방 격하되지 않을 것이다.

다만, 덩치가 커져도 너무 커져 버린 건 진짜로 아쉬운 점이다. 그렇게 살이 뒤룩뒤룩 찐 네이티브 환경을 쓰느니, 차라리 훨씬 더 생산성 좋은 닷넷이 그 역할을 조금씩 대체하고 있는 게 아닐까 싶다.
그리고 여담이지만, 윈도우, 오피스, VS는 앞으로도 또 비주얼이 완전히 확 바뀌는 일이 있을지 궁금하고 기대-_-되기도 한다. ^^

Posted by 사무엘

옛날에 비주얼 C++의 역사에 대해서는 거창한 글을 쓴 적이 있는데 MFC 자체에 대해서는 의외로 블로그 개설 이래로 글을 쓴 적이 없었던 것 같다. 그래서 오늘은 이 주제로 한번 칼럼을 써 보겠다.

MFC는 잘 알다시피 C 언어 기반인 윈도우 API를 C++로 얇게 포장하는 한편으로, C++의 특성을 살려 더욱 생산성 있고 편리한 윈도우 응용 프로그램 개발을 목표로 만들어진 C++ 라이브러리이다. C 언어로 API만 쓸 때에 비해 네이티브 코드 프로그램 개발이 넘사벽급으로 훨씬 더 편리해진다는 건 부인할 수 없는 사실이다(특히 message map 덕분에! ㅋㅋ).

이것의 역사는 윈도우 3.x 시절이던 1992년 무렵으로 거슬러 올라간다. 이때는 MS의 주력 운영체제가 도스에서 윈도우로 바뀌고, 주 개발 언어가 C에서 C++로 이제 막 바뀌던 매우 중요한 과도기였다. 당시 볼랜드의 터보 C의 인지도에 압도적으로 밀리고 있긴 했지만, 마이크로소프트도 MS C라는 컴파일러를 개발해서 팔고 있었고, 이게 7.0 버전부터는 C++ 언어도 지원하기 시작했다.

MFC는 바로 MS C/C++ 7.0부터 도입되었으며, 그 다음부터는 제품명이 그 이름도 유명한 비주얼 C++ 1.0으로 바뀌게 되었다. 당시에는 라이브러리에 Microsoft Foundation Classes라는 거창한 정식 명칭이 없었기 때문에, 그냥 Application Frameworks라고 불렸다. 이것이 바로 AFX의 어원이다.

그래서 오늘날까지도 MFC의 핵심 인클루드 파일 이름은 mfc.h가 아니라 afx.h / afxwin.h이다. 또한 AfxGetApp(), AfxMessageBox() 같은 함수명과, AfxWnd##, AfxFrameOrView##처럼 MFC가 자체적으로 생성하는 윈도우 클래스 이름에도 AFX라는 약어를 찾을 수 있다.

비록 16비트 시절부터 존재하긴 했지만 MFC가 본격적으로 볼랜드 사의 컴파일러와 걔네들 라이브러리를 누르고 인기를 누리기 시작한 건 32비트로 넘어오면서이다. MFC가 첫 도입되었을 때는 C++ 개념을 구현하는 데 드는 특유의 오버헤드가 성능 면에서 문제가 되지 않을까 하는 회의적인 시각이 많았었다. 가령, code bloat으로 인한 용량 증가를 비롯해, 가상 함수 호출이라든가, 윈도우 핸들을 C++ 개체로 연결하기 위한 비용 같은 것 말이다.

워낙 옛날에, C++이 지금과 같은 규격으로 확장되기 전에 개발되던 것이다 보니 MFC는 RTTI를 자체적인 메커니즘으로 구현했으며, 컨테이너 클래스를 템플릿 없이 자체적으로 여러 구현체로 만든 게 있다. CPtrList, CObList 같은 것 말이다. MFC가 처음 개발되었을 때는 C++에 아직 템플릿이란 게 없었기 때문이다. 그리고 그 흔한 namespace조차 쓰지 않았다. 당연히 그때는 namespace가 없었기 때문.

MFC가 드디어 어느 정도 안정화를 이뤄 낸 것은 비주얼  C++ 4.2에서 도입된 MFC 4.2이다(MFC42.DLL). 비록 후속 버전인 비주얼 C++ 5와 6에서 개선과 기능 추가가 있었지만, 이것은 하위 호환성이 완벽하게 유지되는 변화이기 때문에 파일 이름이 동일했고, 이것이 MFC42.DLL이 윈도우 98 이래로 모든 윈도우 운영체제가 기본 내장하고 있는 표준 MFC DLL이 되었다.

오늘날 운영체제가 제공하는 MFC42.DLL은 이제 비주얼 C++ 6.0이 제공하던 클래식 MFC42.DLL과 하위 호환성만 유지되는 superset으로, 비주얼 C++과는 별개로 운영체제가 관리하는 DLL이다. 가령, 윈도우 7의 워드패드와 그림판은 명목상 MFC42.DLL을 사용하지만, 원래 VC6에는 없던 리본 인터페이스를 자기네 MFC42.DLL로부터 가져와서 사용하고 있다.

16비트에서 32비트로 넘어가면서 MFC는 일부 내부 자료구조가 바뀌었다. 특히 handle map은 스레드마다 서로 따로 돌아가기 때문에, 서로 다른 스레드끼리 핸들을 주고받을 때는 MFC 개체가 아닌 핸들을 직통으로 주고받아야 안전하다.

뭐, 이뿐만이 아니라 자체 구현으로 표시하던 toolbar와 status bar가 윈도우 95/NT 3.5부터는 common control이라고 운영체제에 정식으로 편입되었기 때문에, 그걸 그냥 끌어다 쓰는 걸로 내부 구현이 바뀌었다는 것도 첨언하겠다.

비주얼 C++ 6에서 닷넷으로 넘어가면서는 CString 같은 기초 자료형이 MFC가 아닌 ATL이라는 다른 라이브러리로 내부 관할이 바뀌고, 완전히 템플릿 기반으로 바뀌어서 한 코드로 ansi string과 wide string을 모두 다룰 수 있게 되었다. 그리고 DLL의 배포 방식이 변화를 겪기도 했다.

그 뒤 MFC는 2000년대에 들어와서는 이렇다 할 큰 변화가 없었고, 하루가 다르게 발전하는 C# 언어와 닷넷에 비해 MS가 네이티브 개발을 너무 홀대하는 게 아니냐는 우려의 목소리가 나올 정도였다. 특히 MS는 오피스 제품을 주축으로 독자적인 화려한 GUI(메뉴, 툴바 등)를 선보였고 오피스 2007부터는 리본 UI라는 완전히 새로운 물건까지 선보여 왔는데, 이를 모방하여 구현해 주는 MFC 기반 싸제 GUI 라이브러리가 제3자에 의해 미들웨어로 전문적으로 개발되어 판매될 정도가 되었다. 이름하여 GUI 툴킷.

과거 오피스 97/2000까지만 해도 프로그램 비주얼이 운영체제의 그것과 그렇게 큰 차이는 없었다. 그러나 오피스 XP부터 운영체제 기본 프로그램의 비주얼과 그런 오피스(?)급 프로그램의 비주얼은 이질감이 확 생겨 버렸다. 사실은 오피스 XP의 그 하얗고 깔끔한 2D같은 GUI가 윈도우 XP의 전반적인 GUI 디자인이 될 예정이었는데, 그 계획이 수틀리는 바람이 그 오피스 계열하고 운영체제의 알록달록 둥글둥글(?)한 디자인 계열은 따로 놀게 된 거라고 한다.

다음 하편에서는 이 GUI 툴킷과 관련된 MFC의 변천사 이야기를 계속하겠다.

Posted by 사무엘

지난 3월 12일에 본인은 출근길에서부터 충격적인 소식을 들으며 월요일 하루를 시작했다.
딱 정확하게 본인이 타려는 지하철이 앞 역에서 웬 인명 사고가 발생해서 열차 운행이 한동안 중단됐기 때문이다.
이런 일은 처음이었다. 게다가 요즘은 스크린도어까지 버젓이 있는데 웬 인명 사고가 난단 말인가? 이 때문에 난생 처음으로 지하철 지연 증명서(난 뭐 지연이라기보다는 열차 탑승을 애초에 포기한 경우이지만)라는 걸 구경했다.

그런데 사고의 사망자는 놀랍게도 일반 승객이 아니라 지하철 회사의 직원이고, 역무원도 아닌 기관사인 것으로 밝혀졌다. 선로로 접근이 가능한 내부 직원이 마음먹고 자살을 하려 든다면, 제아무리 스크린도어가 갖춰져 있어도 애시당초 소용이 없을 것이다.

철도 공기업에서 승무직으로 일할 정도이면 연봉 빵빵한 건 말할 것도 없고 정년도 보장되기 때문에 겉으로 보기엔 아주 부러운 지위에 속하는 사람이다. 군대로 치면 제일 중요한 전투 병과요, 게임 개발로 치면 딱 프로그래머에 해당하지 않는가. 최소한 경제적인 문제로 인해 자살할 이유는 없다.

하긴 2004년, 본인이 아직 대학 재학 중이던 시절엔 대구 과학고의 1회 졸업생이고 카이스트 기계공학과를 졸업한 어떤 사람이 대구 지하철 기관사로 취직한 게 신문에 보도된 적도 있었다. (☞ 관련 기사 클릭 )

그땐 카이스트라는 스펙에 비해 저학벌(?) 직업을 선택한 이례적인 사례로 그 사람이 소개되었지만, 저게 과연 그렇게 만만한 직업일까? 요즘은 SKY급 대학 나오고도 공기업, 공무원엔 말단으로라도 들어가려는 사람들이 줄을 서 있을 텐데. 이런 트렌드와는 무관하게 나도 2007년에 서울 도시철도 공사에서 공채를 하던 시절에 원서를 넣긴 하고 싶은 마음이 있었다. 철도 차량 운전 면허가 없으니 승무직은 못 하더라도 다른 부서로라도 말이다. 그때 난 병특 중이었기 때문에 애당초 지원을 할 수가 없어서 못 했을 뿐이다.

다만, 지하철 기관사의 근무 여건은 그리 좋다고 보기 어렵다. 우선, 근무 시간이 불규칙적이고 교대를 돌면서 주기적으로 주말을 반납할 각오를 해야 한다. (일요일에 교회에 가야 하는 사람에겐 큰 마이너스) 아니, 승무직은 입사 지원할 때부터 주말 교대 근무에 동의한다는 각서를 제출한다. 비록 버스 기사처럼 교통 체증과 복잡한 도로, 매연, 차멀미로 인한 데미지는 없어서 좋지만, 몇 시간째 햇빛을 못 보면서 어두컴컴한 터널만 돌아다니는 것도 정서에 좋을 리가 없다. 자세한 건 예전 글을 참고할 것.

그래서 본인은 기관사가 그런 극단적인 방법으로 스스로 생을 마감할 정도이면, 근무 환경에 적응을 못 해 극도의 우울증에 시달렸거나, 아니면 정신적으로 문제가 있어서 사내에서 왕따이거나 대인 관계에 심각하게 문제가 있어서 그럴 거라고 생각했다. 이 사고에 대한 후속 뉴스 보도를 보니 내 추측이 얼추 맞는 것 같다.

특히 도철은 1인 승무를 국내 최초로 도입한 지하철 회사이기 때문에 그 점이 노조로부터 두고두고 까여 왔으며, 이번 기관사 자살 사건을 계기로 그게 또 부각되었다. 하지만 차량 상주 승무원 수의 최소화는 철도 기술의 엄연한 트렌드이기 때문에 그 자체가 근본적인 까임거리가 될 수는 없을 듯. 도철은 1990년대 중반에 1인 승무로도 모자라서 아예 무인 운전까지 시도한 적이 있는 과감한 회사이긴 하다만 말이다. (운전실이 없는 완전 무인 운전인 신분당선 전동차에도 승객들과 부대끼는 진짜 승무원이 객실에 한 명 있긴 함.)

난 우리나라 지하철의 스크린도어를 보면 무척 놀라움을 느낀다. 오죽했으면 국가에서 천문학적인 돈을 들여서 2009~2010년을 전후하여 서울 지하철의 거의 모든 역들에다 스크린도어를 도배해 버렸을까? 수백 개에 달하는 그 많은 지하철역들에다 스크린도어를 이렇게 단기간에다 모두 설치한 나라는 세계에서도 유례를 찾기 어려울 것이다. 거의 기네스북 감이 아닐까?

그만치 지하철 자살 러시가 심각한 사회 문제로 대두되고 있었기 때문에 정부가 그런 무리수를 둔 것이다. 뉴스 기사들을 검색해 보면, 당장 본인이 이용하는 집 근처의 지하철역에서만 해도 최소한 3명이 각각 2004년, 2007년, 2008년에 선로 투신으로 목숨을 끊은 적이 있다는 기록이 나온다. 그나마 스크린도어가 설치되면서 2008년 기록이 마지막이 된 것이다.

지난 2010년 8월 23일, 분당선 태평 역에서 발생한 인명 사고에도 본인은 직접적인 영향을 받았다. 이건 사람이 죽지는 않아서 큰 사고로 보도되지는 않았지만, 대학원 입학을 앞두고 사람 만날 일이 있어서 분당에서 학교로 가는 길이었는데 열차 지연으로 인한 불편을 겪었다. 분당선에서 태평과 야탑 역은 2012년 3월 현재까지도 아직 스크린도어가 없다. 다만, 공사 중이긴 하다.

직접 겪어 보지도 않고 남이 처한 상황을 폄하하고 싶지는 않다만..
저렇게 작정하고 자살하려는 사람을 치는 사고를 낸 기관사는 하나도 잘못이 없는데 왜 그 정도까지 충격과 정신 공황을 겪는지 잘 모르겠다.

사람이 끔살 당하는 장면을 라이브로 본 것에 대한 정신적 데미지는 있겠지만, 자기가 살인을 저질렀다는 식의 생각엔 제발 안 빠졌으면 좋겠다. 이건 불의의 사고로 사람이 죽은 것도 아니고, 작정하고 자살하려는 사람이 죽은 것이다. 사형 집행관만큼이나 하나도, 전혀 죄책감 가질 필요가 없다. 일본처럼 죽은 사람 유족에게 민폐에 대한 책임으로 벌금을 때리지 않은 걸 고맙게 여겨야 할 판.

그나저나 작년 12월엔 공항 철도에서 정말 어이없는 사고가 난 적이 있다. 막차 운행이 아직 안 끝났는데도 끝난 줄 알고, 선로 보수 인부 여러 명이 선로로 들어갔다가 전동차에 치여 끔살 당한 것이다. 한밤중인 데다 요즘은 전동차가 기술이 좋아서 워낙 조용하게 달리기 때문에, 저런 상황에서는 답이 없다..;; 기관사도 갑툭튀한 사람들 보고 간이 떨어질 정도로 얼마나 놀랐을까? 이건 승강장 자살도 아니고..! 텅 빈 막차를 몰고 저기까지만 가면 오늘 근무 끝이고 들어가서 잘 일만 남았을 텐데!

원래 그런 건 다 규정이 있다. 지하철의 경우, 심야에 업무를 위해 선로 내부로 들어가는 직원은 열차 운행 영업이 종료된 정도가 아니라 아예 전차선(전깃줄)이 완전히 단전된 걸 확인하고 들어가야 한다. 사탄의 인형 처키는 건전지 없이도 움직였지만-_-, 현실의 전동차는 그렇지 않으니까. -_-;; 선로 보수· 청소 차량들은 애시당초 전기가 아닌 기름으로 움직인다.
그러니 내가 보기엔 저 사고는 일차적으로는 일종의 근무 기강 문제이다. 거기에다 또 선로 보수 인력이 외주 용역이다 보니 앞뒤 손발이 안 맞은 것일 수도 있겠고.

그랬는데, 고의적인 자살이 아니면서 사람이 여럿 죽는 사고가 나 버리는 바람에, 내 기억이 맞다면 애꿎은 전동차 기관사도 일단은 잡혀 들어갔다. 경적을 안 울리고 완벽한 수준의 안전 조치를 안 취했다고... 구속인가? 한국은 법을 적용하는데 동기나 과정보다 결과를 더 우선시하는 풍토가 있어서..;; 안타까운 일이다. 기관사의 입장에서는 저건 정말 운이 없어서 이런 신세로 전락한 것이나 마찬가지이다.

물론, 하루에 전철이 수송하는 승객 수가 얼마나 엄청나고 방대한지를 감안하면, 그에 비해 저 정도로 예외적인 급으로 발생하는 사고는 정말 극소수이고 새 발의 피도 안 된다는 것이 분명한 사실이다. 철도는 정말 수송 효율이 좋고 안전한 교통수단이 맞다. 오늘도 수도권 시민들의 운송을 책임지는 지하철/전철 기관사님들 힘내시길.

Posted by 사무엘