« Previous : 1 : ... 185 : 186 : 187 : 188 : 189 : 190 : 191 : 192 : 193 : ... 215 : Next »

추억의 간이역 서체들

이제는 갈수록 보기 어려워지고 있는 추억의 서체들을 보라.
서체 쪽으로 조금이라도 눈썰미가 있는 철도 매니아라면 저런 글씨체 보기만 해도 가슴이 쿵쾅쿵쾅 뛰고 감흥이 느껴지지 않는가?

사용자 삽입 이미지
사용자 삽입 이미지
사용자 삽입 이미지
사용자 삽입 이미지

그러다 1990년대 철도청 시절에는 HY울릉도가 각종 역명판 서체로 쓰였고, 21세기에 들어와서는 아시아폰트에서 제작한 코레일체라는 전속 서체로 또 한번 서체가 다 물갈이되었다.
HY울릉도는 둥글둥글하면서도 간판용으로 가독성이 무척 좋았기 때문에 건물 간판이나 도로 톨게이트 등에서도 많이 쓰였다.

내 기억이 맞다면, 2009년에 확인한 바로는 카이스트 기계 공학동 건물도 간판이 울릉도체였다.
그 반면 코레일체는 울릉도보다 좀 홀쭉하고 각진 느낌이 난다.

사용자 삽입 이미지
하긴, 그러고 보니 옛날에는 각종 제목이나 심지어 도로 표지판 서체도 동글동글한 게 대세였다. 그러던 게 산돌 도로표지판이 등장하고부터 완전히 고딕 컨셉으로 바뀐 것이다.

사용자 삽입 이미지

사라져 가는 추억의 간이역 역명판체가.. 디지털 서체로 부활한다면
과거 산돌에서 성경체(옛날 성경책 특유의 붓글씨 서체)를 개발한 것만큼이나 획기적인 업적이 되리라 생각한다. 특히 저 '서빙고' 체는 아마추어 티도 안 나고 굉장히 예쁘다.
하지만 과연 부활이 가능할까? =_=;;

Posted by 사무엘

2010/07/08 08:22 2010/07/08 08:22
, ,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/314

C++에는 namespace라는 엄청난 키워드가 존재한다.
namespace는 소스 코드에 존재하는 수많은 명칭(심볼)들로 하여금 이들이 통용되는 구획을 강제로 구분해 준다. (명칭의 decoration도 달라지기 때문에, 링크 때도 동명의 심볼들이 서로 구분 가능함)
방대한 프로그램을 짜고 특히 남이 만든 여러 라이브러리들을 한데 뭉뚱그려 관리하다 보면 함수나 전역 변수 이름, 심지어 매크로 같은 게 겹쳐서 링크 시 충돌이 있을 수 있다. 이때 namespace는 그런 문제에 대한 근본적인 해결책이 되어 준다.

C++은 C에 비해 scope이라는 개념이 더욱 발달했다.
여기서 말하는 scope이란, 단순히 전역 변수냐 지역 변수냐 하는 생명 주기 차원이 아니라, 어떤 심볼이 언어의 문맥 차원에서 인식되고 접근이 허용되는 범위를 일컫는다.
가령, C++ 클래스 내부에 있는 static 변수는 생명 주기로 말하자면야 C의 전역 변수와 다를 바가 없다. 그러나 단순 전역 변수와는 확연하게 다른 scope을 지니고 있다. 그래서 :: 같은 연산자도 생겼다.

예전에는, 특히 C 시절에는 global이라는 기본 namespace 하나밖에 없는 것과 마찬가지였지만 C++에서는 나만의 namespace를 정의할 수 있고, 심지어 이중 삼중으로 namespace 안에 또 namespace를 만들 수도 있다. 심볼들의 입체적인 관리와 구별이 가능해진 것이다.
사실 namespace는 90년대에 나중에 추가된 키워드로, 도스 시절의 볼랜드 C++ 같은 컴파일러에서는 지원도 되지 않는다. (MFC 역시 namespace는커녕 템플릿조차 없던 시절부터 만들어져 온 클래스 라이브러리인지라, namespace를 사용한 흔적이 없음)

그런데, namespace가 하는 일은 클래스가 하는 일과 좀 중복이 있어 보인다.
클래스도 그 자체가 이미 자신만의 새로운 scope을 만들어 낸 것이기 때문이다.
클래스 내부에 public으로 선언된 static 변수 내지 함수하고,
namespace 내부에 존재하는 전역 변수 내지 함수는 언뜻 보기에 위상이 완전히 똑같다.

밖에서는 클래스::이름, 또는 namespace::이름 이렇게 ::을 써서 호칭하는 것마저 동일하다.
클래스도 안에 클래스 내지 구조체가 중첩해서 존재할 수 있으며, 심지어 클래스 내부에서만 통용되는 enum이나 typedef를 선언하는 것도 가능하다.
그럼 도대체 namespace만의 특징은 무엇이 있을까? 아래의 코드를 생각해 보자.

namespace NS {
   class A {};
   void f( A *&, int ) {}
}

//void f(NS::A *&, int) {} //이게 뭘까?

class CS {
public:
   class A {};
   static void g( A *&, int ) {}
};

이렇게만 보면 NS라는 namespace에 소속된 클래스 A와 전역 함수 f,
그리고 CS라는 클래스에 소속된 클래스 A와 전역 함수 g는 서로 그게 그거 같고 정말 차이를 발견할 수 없어 보인다.
다만, class나 struct와는 달리 namespace는 뭔가 인스턴스화하는 자료형을 만드는 것이 아니기 때문에, 닫는 중괄호 뒤에 세미콜론을 붙일 필요가 없다. 뭐, 그 정도 차이는 존재한다.

이들 각 심볼을 외부에서 접근하는 방법도 완전히 동일하다. 아래 코드를 보라.

NS::A *pfm = NULL;
NS::f(pfm, 0); //하지만 바로 f(pfm, 0)만 해도 된다. 이유는 나중에 설명

CS::A *qfm = NULL;
CS::g(qfm, 0);

그런데, namespace는 클래스에 없는 부가 기능이 좀 있다.

첫째, 바로 ADL(Argument dependent name lookup)이라는 기법이다.
C++ 컴파일러는 함수의 argument의 타입으로부터 함수의 소속 scope를 자동 추론하는 기능이 있다.
namespace NS에 속해 있는 f를 호출할 때 굳이 NS::를 할 필요가 없다.
왜냐하면 f가 받는 함수 인자 중에 이미 NS에 소속된 자료형이 존재하기 때문에, 컴파일러는 이 f를 먼저 global scope에서 살펴봐서 없으면 NS namespace 안에서도 찾아보게 된다.

함수의 인자를 이용하여 함수를 추정한다는 점에서는 함수 오버로딩의 확장판이라고 볼 수도 있겠다.
사실, 위의 소스에서 주석을 쳐 놓은 global scope의 f 함수까지 정의한다면 컴파일러는 어느 f 함수를 선택해야 할지 모호하다면서 에러를 낸다.
이런 기능은 클래스에는 존재하지 않는다. g 함수를 호출할 때는 매번 CS::g를 해 줘야 한다.

둘째, using 키워드이다.
반복되는 타이핑을 좀 줄이고 싶어하는 건 프로그래머들의 공통된 희망 사항이다.
타입 선언을 좀더 간편하게 하기 위해서 C/C++에는 typedef라는 키워드가 있고, 베이직이나 파스칼에는 구조체 참조를 좀더 간편하게 하려고 With 같은 키워드가 있다.

그와 마찬가지로 C++에는 여타 namespace에 있는 명칭을 매번 :: 연산자 없이도 바로 참조 가능하도록 using namespace 선언을 제공한다. using namespace std; 처럼 말이다.
using namespace NS를 한번 해 주면, 그 뒤부터는 NS::A *pfm 마저도 A *pfm로 축약 가능해진다.
using의 용법으로는 또 다른 것도 있는데, 설명서를 읽어 봐도 잘 모르겠다. 정말 무진장 복잡하고 저런 걸 언제 어디서 써먹으면 될지 영 감이 안 잡힌다. =_=;;
다만, namespace가 아니라 클래스에 의해 만들어진 scope에 대해서는 그런 것 역시 지원되지 않는다.

셋째, namespace p = FS; 처럼, namespace에다 별명(alias)을 붙여 쓰는 것도 가능하다. 길고 복잡한 다단계 namespace를 손쉽게 축약하는 방법이다. 저런 문법도 있다니, 가히 충격과 공포.

끝으로, 이름 없는 namespace는 마치 C 시절의 static 전역변수/함수처럼, 해당 번역 단위(소스 코드; translation unit) 바깥으로 함수나 변수 심볼이 노출되지 않게 하는 역할을 한다는 것도 알아 두면 좋다.
이 정도 되면 namespace는 C++ 언어에서는 단순히 클래스 이상으로 자신만의 역할이 있다고도 볼 수 있겠다.

가장 먼저 언급한 ADL에 대해서는 비판은 있다. namespace에다가 일종의 예외 규정을 만드는 것이나 마찬가지이기 때문에 C++ 문법을 더욱 복잡하게 하고 컴파일러 만들기도 난해한 언어로-_- 만드는 데 일조했기 때문이다. 그러나 프로그래밍의 편의를 위해서 ADL은 어쩔 수 없이 꼭 필요하기도 하다. 이게 없으면 다른 namespace에 소속되어 있는 클래스의 오트젝트에 대해서는 연산자 오버로딩조차도 제대로 못 하게 되는 경우가 생길 수도 있기 때문이다.

참고로 자바나 C#처럼 C++보다 나중에 등장한 본격 객체 지향 언어들은 C++처럼 global scope이라는 게 존재하지 않는다. 전역 함수나 전역 변수라는 게 애초부터 존재하지 않으며 모든 심볼들은 무조건 클래스에다 소속되어 있어야 한다. 또한 이런 언어들은 C++ 같은 텍스트 include라든가 링크라는 개념이 없으며, 클래스가 곧 패키지요 namespace의 형태로 구조가 잘 짜여 있다. 그래서 C++처럼 namespace를 별도로 갖고 있지는 않다.

Posted by 사무엘

2010/07/07 08:44 2010/07/07 08:44
Response
No Trackback , 5 Comments
RSS :
http://moogi.new21.org/tc/rss/response/313

※ 메신저

상대방에게서 마지막 대화가 도착한 지 n초가 경과하기 전에는 ESC를 눌러도 대화창이 없어지지 않게 하는 옵션이 있으면 좋겠다. (과거 대화 내용을 보관하는 기능이 없을 때에 한해)
상대방에게서 말이 막 도착했는데 그걸 예상 못 보고 창을 확 닫아 버리면 대략 난감하다.

아울러, MSN 메신저는 이모티콘 변환을 좀더 지능적으로 했으면 하는 바람이 있다. 이모티콘 때문에 메신저로 프로그램 코드를 주고받을 때 상당한 애로사항을 경험한 사람들이 적지 않을 것이다. 지금은 안 그런데 옛날에는 심지어 (?) 조차도 이모티콘으로 바꾸는 어처구니없는 일이 있었다.
이모티콘 변환은 내가 직접 타이핑하는 문자열에 대해서만 적용하고, 복붙한 텍스트에 대해서는 안 하기만 해도 불편이 상당수 해결될 텐데..

※ 텔넷 클라이언트

서버로부터 특정 패턴의 문자열을 받았을 때 사용자에게 alarm 하거나, 이런 명령을 보내거나, 로컬 컴퓨터에서 뭘 실행하는... 그런 스크립트 기능이 있었으면 좋겠다.
즉, 패턴으로 현재 쉘의 프롬프트 문자열을 등록해 놓고 긴 빌드 명령을 내리면... (가령 안드로이드 OS 빌드 같은)

나중에 빌드가 다 끝나고 프롬프트가 떴을 때, 서버에서 빌드된 이미지를 곧바로 로컬 컴퓨터로 복사한다거나 하는 사용자 정의 이벤트가 실행되게 할 수 있다. 즉, 서버 컴퓨터와 내 클라이언트 컴퓨터의 연계가 가능해진다. 단순히 login 내지 password 요청이 왔을 때 로그인을 자동으로 해 주는 것 이상으로, 이 정도 수준의 자동화 기능은 PC 통신 프로그램도(이야기의 혼잣말 기능 같은) 제공한 걸로 기억한다. 하지만 PuTTY 같은 프로그램에는 아직 없는 듯.

※ 비주얼 스튜디오 2005

본인이 비주얼 스튜디오 2005를 처음 접했을 때의 인상은 무척 충격적이었다. 드디어 아이콘이 16색을 넘어섰고, 무엇보다도 메뉴와 도구모음줄의 외형이 시퍼런 MS 오피스 2003 스타일을 물려받지 않고 예전 버전(VS 2003 = 오피스 XP)을 변형한 형태로, 즉 자신만의 스타일로 갔기 때문이다.

2005는 컴파일러가 더욱 C++ 표준을 준수하고 여러 가지 면에서 기능이 향상된 게 많아 만족스러웠다. 하지만 같이 설치되는 플랫폼 SDK가 좀 이상해서 기본 설치한 환경에서는 <날개셋> 한글 입력기 빌드에 필요한 일부 운영체제 컴포넌트가 설치되지 않았다. 그리고 이 버전에서 제공된 Spy++은 윈도우 비스타 이상급에서는 이상하게 일부 프로세스가 목록에 나타나지 않고 검색도 되지 않았다.
왜 그런지 모르겠다. 2008은 말할 것도 없고 심지어 구버전인 2003도 그런 문제가 없었는데 말이다.

※ 그리고 기타 전반적으로

비주얼 스튜디오, Source Insight, 이클립스는 모두 유명하고 널리 쓰이는 개발 환경이다.
취소(Ctrl+Z), 열기(Ctrl+O), 복사(Ctrl+C)처럼 모든 응용 프로그램에서 거의 이질감 없이 일치하는 단축키가 있는 반면, 전혀 표준화가 안 돼 있고 응용 프로그램마다 제각각인 단축키도 있어서 굉장히 신경 쓰인다.

가령, Find previous/next match 기능은 본인은 F3/Shift+F3에 아주 익숙한 반면 그렇지 않은 프로그램도 있다. 이는 파일 비교· 병합 프로그램도 마찬가지. 심지어 왼쪽/오른쪽 병합 기능도 WinMerge, 아락시스, Beyond Compare 등 프로그램들이 전부 단축키가 다르다.
Undo와는 달리 Redo는 단축키가 일치하지 않는 경우가 많다는 것 역시 특이점. Ctrl+Y or Ctrl+Shift+Z처럼 말이다. 이건 비단 개발 도구뿐만 아니라 워드 프로세서인 아래아한글과 MS 워드의 대표적인 차이이기도 하다.

다음은 불만 내지 제안 사항은 아니고, 윈도우 운영체제 관련 trivia.

1.
윈도우 95, 98, 2000은 welcome 프로그램이란 게 있었다. 즉, 부팅이 끝난 후 곧장 실행되어, 이 운영체제의 새로운 기능을 소개한다거나 자습서를 꺼낸다거나 하는 가이드 프로그램이다. ME는 없었던 걸로 기억한다.
95의 경우, 아직 Did you know 같은 팁 인터페이스가 유행하던 시절이었고(무려, 비주얼 C++ 6에도 아직 있다!) 3.1에 비해 워낙 breaking change가 많았던지라 새로운 기능 팁 위주였다. 그 반면 98과 2000 버전은 팁은 없고 인터넷 연결과 제품 등록과 관련된 아이템이 있었다.

하긴, 윈도우 비스타는 그와 비슷한 개념으로 ‘시작 센터’를 표시하는 게 있긴 하다. 7은 있나?
윈도우 3.1과 95는 자습서까지 있었다. 비주얼 베이직으로 만든 프로그램이었던 걸로 기억.
98과 2000은 운영체제 도움말이 하드코어 chm 형태인 반면, ME는 hta (HTML Application!) 기반의 좀 인터랙티브한 도움말이 추가됐고, XP는 전무후무하게 아예 플래시 기반 자습서 겸 도움말까지 내장하고 있었다. 영어여서 한글판에서는 정식으로 이를 들려 주지는 않았지만 말이다.

2.
32비트에 이어 개인용 PC에도 64비트 시대가 도래하고 64비트 윈도우는 16비트 바이너리는 지원조차 안 하게 되었지만, 아직도 16비트 코드의 잔재가 고스란히 전해 내려오는 분야가 있다. 바로 fon 글꼴 파일인데(ttf 말고), 이제는 시스템 비트맵 글꼴로밖에 안 쓰이는 이 과거 유물은 여전히 16비트 dll 형태이다. 물론 코드는 전혀 없고 리소스 전용 dll이지만...
이 파일은 이제 실행 파일이 아니라 데이터 파일로 해석된다고 보는 게 더 타당하겠다. System, Fixedsys, Terminal 같은 비트맵 글꼴이 fon 파일 형태로 들어있다. 시스템 기본 글꼴조차 힌팅과 안티앨리어싱이 적용된 윤곽선 글꼴로 나오는 판국에 정말 낡은 유물이 된 셈이다.

Posted by 사무엘

2010/07/06 09:07 2010/07/06 09:07
,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/312

아무리 로딩 시간이 길고 덩치가 큰 프로그램이라 하더라도, 한번 실행했다가 종료한 후 그 프로그램을 즉시 다시 실행하면, 예전보다 훨씬 더 빨리 실행된다. 이때는 사실 디스크 액세스 자체가 거의 일어나지 않는다. 이는 상식적으로 알 수 있듯, 운영체제가 디스크 액세스에 대한 캐싱(cache)을 똑똑하게 잘 해 주기 때문에 그렇다.

컴퓨터 내부는 양극화 내지 80/20 법칙이 잘 통용되는 세계이다. CPU 명령이든 디스크 액세스든, 메모리 액세스든, 병목 현상은 꼭 일어나는 곳에서만 몰아서 집중적으로 일어난다. 한번 액세스된 자료는 다음에 또 액세스될 가능성이 높다. 그리고 그 인근의 자료가 덩달아 액세스될 가능성이 높다. 컴퓨터 아키텍처를 연구하는 사람들의 관심사 중 하나는, 이런 캐시 적중률을 높여서 컴퓨터의 성능을 끌어올리는 것이다.

그러나 지금은 당연시되고 있는 디스크 캐시가 옛날 도스 시절에는 전혀 당연한 개념이 아니었다. 아까 전이나 지금이나 동일한 파일을 읽고 쓰는 시간은 언제나 동일-_-했다. 캐시 프로그램은 별도의 램 상주 유틸리티로 제공되곤 했다. 사실, 그때는 메모리 값이 비싸서 디스크 캐시를 위해 수 MB의 메모리를 떼어 낼 여건이 되는 브루주아 계급 자체가 별로 많지 않았었다. ^^

디스크 캐시 유틸이 하는 일은 대략 다음과 같을 것이다.
1. 파일을 읽을 때 인접한 내용도 미리 읽어 둔다.
2. 한번 읽은 내용은 메모리에 저장해 놓고 나중에 디스크를 액세스하는 일이 없이 써먹는다.
3. 쓰는 것은 지금 몰아서 다 하지 않는다. 쓰기 작업을 다 완료하지 않았지만 일단은 다 했다고 빨리 응답해 주고, 나머지 작업은 CPU가 쉬고 있을 때 조금씩 한다.
그러니, 읽은 내용을 효율적으로 관리하는 것과, delayed writing 때문에 메모리와 디스크의 실제 상태가 일치하지 않을 때 이를 동기화하는 방식 같은 게 캐시 프로그램 개발의 핵심 기술이라 할 수 있다.

물론 읽기 캐시는 그렇다 쳐도, ‘delayed writing’라는 동작 방식은 위험할 수도 있다는 경고도 접했다. 메모리에 있던 캐시 내용이 디스크에 실제로 반영되기 전에 컴퓨터가 꺼져 버린다면? 흠좀무.

MS 도스는 SMARTDRV라는 유틸리티를 제공했으며, 윈도우 9x에도 이놈이 있다. 이 프로그램이 다른 경쟁 프로그램들과 비교했을 때 성능이 어땠는지는 모르겠지만 이 정도만으로도 마법과 같은 프로그램이었다. 하드웨어를 바꾸지 않고도 디스크 체감 액세스 속도가 엄청나게 빨라졌으며, 특히 크기가 작은 다수의 파일을 다룰수록 성능 향상 정도는 폭발적이었다.

심지어는 운영체제 설치하기 전에 smartdrv를 띄워 놔도 설치 시간이 단축되고 효과가 좋다고 명시가 되어 있다. 디스크 캐시는 가상 메모리라는 개념과 맞물려서, 현대 운영체제가 RAM의 속도와 하드디스크의 용량을 적절하게 잘 절충하여 사용자에게 최적의 성능을 제공하는 데 꼭 필요한 개념이 되었다.

윈도우 비스타(와 그 후속 포함)는 예전보다 더욱 과감하게 캐싱을 한다고 한다. 값싸고 풍부한 메모리를 디스크 캐싱용으로 적극 활용한다. 심지어 수십 MB짜리 비주얼 스튜디오 2008도 몇 번 껐다가 켜면 나중에는 디스크를 전혀 액세스하지 않고 실행된다. 마치 램드라이브처럼 말이다. 그러니 빨라졌다는 느낌이 들 수밖에 없다. 캐싱용으로 쓰는 메모리는 운영체제가 점유 중인 메모리 양으로 쳐 주지도 않는다. 사용자가 원하면 언제라도 용도 변경이 가능한 메모리이기 때문이다.

반대로, 램 용량이 부족하면 컴퓨터는 그야말로 지옥이 된다. 캐시 혜택은커녕, 이미 램으로 액세스하던 것도 전부 디스크 상의 스왑 파일로 다루게 되기 때문이다.

그러고 보니 과거에는 네트워크 드라이브도 아니고 아예 램드라이브라는 게 있었다. 비록 용량이 부족하고 저장 효과가 영구적이지도 못하지만, 이것이 광속으로 디스크를 액세스하는 효과를 내는 방법 중 하나이기도 했다. 지금은 그런 게 있으려나?

또 하드디스크를 write-protect하는 유틸리티도 있었다. ㅎㄷㄷ;; 그러나 이 역시 메모리와 디스크가 일체로 가상 메모리를 이루는 오늘날의 운영체제 하에서는 완전히 흑역사가 된 지 오래이고, 그 대신 얼추 비슷한 개념을 사용자 계정 컨트롤이 대신 담당하고 있다. 도스 시절 만세이다. ^^;;

Posted by 사무엘

2010/07/05 08:30 2010/07/05 08:30
, ,
Response
No Trackback , 4 Comments
RSS :
http://moogi.new21.org/tc/rss/response/311

2001년 9월 11일.
테러리스트에 의해 납치된 여객기가 저공비행 후 세계 무역 센터 건물에 자폭 충돌하는...
미국 건국 이래 초유의 대형 테러 참사가 벌어졌을 때의 일이다.

여객기를 이용한 테러였음을 인지한 미국 정부는, 당시 미국 영공을 날고 있는 모든 여객기들로 하여금 지금으로부터 3시간 이내에 인근의 공항으로 비상 착륙하라는 명령을 내렸다. 그 대상은 미국뿐만 아니라 캐나다 영공으로까지 확대되었으며, 이때 무려 5천여 대에 달하는 비행기들이 비행을 중단해야 했다고 한다.

이들은 긴급 명령을 받고서 인근 공항으로 허겁지겁 다 내려갔는데... 유독 태극 마크가 선명한 대한 항공 소속의 모 여객기만이 215명의 승객을 태운 채 명령을 씹고 나홀로 계속 날고 있었다. 흠좀무. 도쿄를 출발하여 앵커리지로 가던 보잉 747기였다.

이 때문에 테러를 당한 지역인 미국 동부뿐만 아니라 서부도 비상이 걸렸다. 중무장한 F-15 전투기 두 기가 즉시 출격했다. 초음속으로 날아가서 여객기를 따라잡고 바짝 붙었다. 미국 공군 사령관의 명령 한방이면 그 여객기는 테러리스트에게 장악 당한 걸로 간주되어 격추 당할 수도 있었고, 1983년의 피격 사건의 비극이 소련에 이어 미국에서 재연될 뻔했다.

이건 마치 무장 탈영병의 사살을 군대에서 허락하는 것과 비슷한 맥락이다. 탈영 자체는 비록 무겁긴 해도 사살할 정도로 죽을죄는 아니다. 그러나 개인 무장으로 무슨 짓을 할지 모르기 때문에 민간인의 피해를 최소화하기 위해, 저항하는 탈영병을 어쩔 수 없이 사살하는 것이다.

그런 것처럼 테러리스트에게 탈취 당한 비행기는 도심에서 추락하거나 사고를 치면 더욱 큰 피해를 끼칠 수 있다. 그 가능성을 원천 봉쇄하기 위해 조기에 격추하는 것이다. 작년(2009) 성탄절 때 미국 여객기 테러를 시도했던 빈 라덴 배후의 테러리스트도, 다른 때가 아니라 비행기가 딱 미국 시가지 상공에 진입하고 착륙 직전 상태가 됐을 때 폭탄을 터뜨리려 했음을 기억하기 바란다.

저런 사람이 버젓이 탑승 보안 검색대를 통과했다니, 911 때 당하고도 미국이 아직 정신을 못 차렸나 보다. 뭐, 이제 관광 비자도 면제되고 좀 편해지나 했는데, 우리 입장에서는 그 사람 덕분에 미국 가는 절차가 더욱 복잡하고 까다로워졌지만 말이다.

다시 본론으로 돌아오면..
그래도 다행히 비행기가 격추 당하는 일은 발생하지 않았다. 먼젓번의 관제 지시는 씹었지만 그래도 전투기의 “위로, 아래로” 같은 명령에는 순응했기 때문이다. 대한 항공 여객기는 영문을 모른 채 전투기의 인도를 받으면서 캐나다의 어느 작은 공항에 비상 착륙했다. 보잉 747 같은 초대형 여객기를 취급하기엔 좀 버거운 규모. 이미 다른 수많은 여객기들이 착륙하고 난 뒤였기 때문에 이 여객기가 앉을 공항을 찾기도 쉽지 않았다.

이때는 이미 대한 항공 여객기가 납치당했을지도 모른다는 소문이 쫙 퍼진 상태였던지라, 앵커리지는 물론이고 캐나다 공항 인근 주민들이 죄다 대피하는 소동까지 벌어졌다. 그러나 여객기는 무사히 착륙했고, 이 비행기를 끝으로 북미 영공은 일시적으로나마 완전 폐쇄 상태가 되었다.

비록 상황은 평화적으로 마무리되었지만 이 모든 소동과 오해의 원인은 너무 어처구니가 없었다.
우리나라 조종사가 영어가 딸려서 비상 착륙 명령을 못 알아들었던 것이다!

평소에 일상적으로 주고받는 교신이 아니라 처음 듣는 메시지가 긴급한 속도와 억양으로 흘러나오니 조종사는 어리둥절해했다. 게다가 메시지 도중에 hijack transponder 이런 단어가 나오니까 그걸 누르라는 소리인 줄 알고 ‘피랍’ 신고를 두 번이나 하는 센스. ㅠ.ㅠ

납치라는 단어가 뭔지도 모르고서 “납치됐니?” “납치됐어”라고 회신을 해 준 꼴이다. 그러니 미국으로서는 500% 테러리스트 피랍 인증으로 간주하고 전투기를 보낼 수밖에 없었다. 얼마나 아찔한 순간이었겠는가?

국제선 항공업계는 영어 못 알아들으면 영락없이 고문관 신세가 되는 분야임을 입증하는 계기였다.
그 최강의 엘리트 집단이라는 비행기 조종사라고 해서 다 영어 잘 하는 건 아니다. 한국과 일본이 특히 그런 불명예스러운 면모로 인해 영어권 국가들로부터 주목 대상이며, -_-;; 영어 실력이 어느 수준 이상 안 되면 조종사 뽑지 말라고 압력까지 받고 있다고 한다.

그러나 한국 같은 나라가 아니라 영어와 언어 구조가 비슷한 나라들끼리도, 같은 영어 표현을 알아듣는 방식이 서로 달라서 더 위험한 오해가 생기기도 한다. 테네리페 참사는 딱 그것 때문에 발생한 사고의 대표적인 예이다.

이 사건에 대한 더 자세한 설명이 나와 있는 사이트를 링크하며 글을 맺는다.
http://iloverossi.egloos.com/tag/911/page/1

다음은 덧붙이는 아이템들.
1. 고속버스 회사들은 고속도로 통행료를 도로 공사에다 지불한다. 여객 열차를 운영하는 코레일은 선로 사용료를 철도 시설 공단에다 지불한다. 이와 마찬가지로, 눈에 보이는 톨게이트만 없을 뿐이지 국제선 항공사들은 영공 통과료를 해당 경유 국가에다 꼬박꼬박 낸다. 이것도 기름값이나 주기료만큼이나 은근히 무시 못 할 비용이다.
한 국가가 걷은 영공 통과료 수입은 아까와 같은 그런 관제 업무에 쓰인다. 우리나라는 최근 천안함 사태 때문에 북한과 사이가 제대로 틀어지고 항공기들의 북한 영공 보이콧 결정이 났을 때, 잠시 북한 영공 통과료에 대한 얘기가 나온 적이 있다.

2. 국제선 비행기의 내부는 법적으로 도착 국가의 영토로 간주된다고 한다. 미국에서 태어난 아기가 누구라도 자동으로 미국 시민이 될 수 있다면, 미국 행 비행기 안에서 태어난 아기도 미국 시민이 된다는 뜻이다. 흥미로운 사실이다.

Posted by 사무엘

2010/07/03 08:55 2010/07/03 08:55
, ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/310

시스템 클럽과의 인연

2005년 초의 일이다. 그때 본인은 인터넷 상으로 짜증나는 소식을 하나 접했다.
고려 대학교의 한 모 교수(정확히는 이미 명예 교수 랭킹인)가 일본의 무슨 출판물에다가 “일제 식민 통치는 조선에게 축복”이었다고 기고를 했다고 한다. 한국인치고 상식적으로 이 한 줄만 딱 접하고서 열받지 않을 사람이 누가 있겠는가?

그런데 얼마 안 있어 이 사람을 옹호하고 나서는 사람이 등장했다. 본인도 그때까지만 해도 소위 친일파 문제라는 것에 대해서 평균적인 국민들이 생각하는 수준의 막연한 피해의식을 갖고 있었던지라, ‘누군지는 모르겠지만, 그쪽 패거리들이 또 고루고루 나서서 ㅈㄹ을 하는군.. 이번엔 대체 누구야?’ 정도의 생각 그 이상도 그 이하도 아니었다.

그뿐만이 아니었다. 하필 2005년에는 연초부터 일명 ‘박 정희 배틀’이 벌어졌다. <그때 그 사람들> 같은 영화도 개봉해서 고등학교 동기들과 여차여차 하다 보니 관람하게 됐고, <만화 박정희>라는 책도 나왔다. 박 정희 전대통령이 한글로 써 놓은 광화문 현판을 철거하느냐 마느냐를 두고 한글 진영 내부에서도 대립이 있었다. 다 비슷한 시기이다! 이게 다 우연일까?

게다가 압권이었던 것은 CBS 방송국에서 벌어진 공개 토론. 바로 이를 계기로 본인 역시 지 만원이라는 사람을 알게 됐으며, 시스템 클럽이라는 사이트에도 들어가 보게 됐다. 그런데 그 공개 토론을 계기로 지 박사는 젊은이들에게 완전히 미친 수꼴 개새끼로 확실하게 인증 받게 됐으니 참 안타까운 노릇이다. 사회자조차 그다지 중립적인 위치에 안 서고 진 중권 씨와 한 패가 되어 지 박사를 멸시하는 모습을 보이는 건 좀 보기 안 좋았다. (성공회대 교수라는데 성향 면에서 뭘 더 바라겠는가.)

도대체 지 만원이라는 사람은 어디서 갑툭튀한 사람인가? 당사자에게는 좀 죄송한 얘기지만, 솔직히 인상이 좀 얍실한 족제비-_- 같고 영화로 치면 주동 인물보다는 반동 인물, 진짜 친일파처럼 보이긴 했다. O<-<
궁금해졌다. 그래서 시스템 클럽 글을 읽고 그의 프로필을 찾아보았다. 외부로도 보도가 되어 그의 이미지를 더욱 골수 수꼴로 굳히는 데 일조한 글로는,

<민족, 외세만 아는 바퀴벌레들>: 공산주의, 좌익, 운동권에 대한 무조건적인 혐오감
<역대 대통령의 자질 추이>: 이 승만, 박 정희, 전 두환만 우왕ㅋ굳ㅋ이었고  그 후대 대통령들은 타락일로

이런 것도 있다.
그러나...
그는 친일파가 결코 아니며 그런 글들을 쓰는 것이 애국심에서 우러나온 것임을 본인은 느낄 수 있었다. 김 완섭 같은 싸이코 부류가 절대 아니다! 일본 내지 친일파 후손하고는 일면식도 없는 사람이며, 군 복무도 월남전 참전까지 하면서 명예롭게 마쳤다. 공부도 정말 열심히 해서 미 해군 대학원에서 응용 수학 박사 학위를 받고, 그의 말마따나 자신만의 정리와 알고리즘을 만들었다. 일평생을 자기 계발과 교양 수련에 투자하고 살았으며, 말과 행동이 일치하고 정말 대쪽같은 분이다. 본인은 진 중권 씨는 그런 사람이라고 생각하지 않는다. 사상적으로 지 박사의 반대편에 선 사람 중에, 저 정도로 대인배가 있으면 나와 보라고 해라.

지 박사는 20세기까지만 해도 시스템 공학자 내지 군사 평론가를 비롯해 자기 전문 분야의 프리랜서로 자유분방하게 살고 있었는데 이놈의 김 대중 정권 때부터 나라에서 하는 짓을 보니까 이 반역 행위를 도저히 용납할 수 없어서 본격적으로, 한 2002년부터 본업을 버리고 시사 논객으로 악역을 자처하며 활동하기 시작했다. 전혀 청렴하지도, 도덕적이지도 않은 민주화 패거리 저질 정치인들이.. 능력면에서는 자기보다 훨씬 더 뛰어났던 옛날 정치인의 도덕성(?)을 욕하면서 그들이 만들어 놓은 나라 기강을 송두리째 파괴하는 걸 그냥 보고만 있을 수 없었던 것이다.

그래, 살짝 수구 극우 성향이고 시국에 대해 지나치게 민감하게, 음모론스럽게 확대 해석하는 면모가 좀 있긴 하다. 그러나 그 정도는 사상의 자유가 있는 우리나라에서 허용할 만한 수준이다. 음모론이야 반대편 진영도 어차피 만들어 내기는 마찬가지이다. 천안함에 대해서, 미국에 대해서 등등등.. 지 박사의 주장이 선동조라면, "우리가 읽는 성경에서 13구절이나 통째로 삭제되고 무려 6만 개의 단어가 변개됐다"는 주장도 충격적이고 선동조이긴 마찬가지이다.

고려대 교수의 문제의 발언도 “조선이 러시아에게 안 먹히고 일제에게 먹힌 게 그나마 다행이었다”는 요지였다. 그에 대해서 “차라리 러시아가 낫지 일제는 훨씬 더 막장이었다”라고 정당한 반론을 할지언정, 앞뒤 문맥 다 떼어내고 “자립할 능력이 없는 조센징을 일제가 보살펴 준 건 축복이었다”고 말을 완전히 곡해하여 사람 매장하는 건, 인간이 해서는 안 될 짓이지 않은가!

본인은 예전에 “그나마 숙군 작업부터 한 뒤에 6 25가 터진 건 천만다행이었다”라고 글을 쓴 적이 있다. 이걸 마치 “김 용묵이라는 작자는 동족상잔의 비극인 6 25가 터진 게 잘 되었고 다행스러운 일이었다고 떠벌리고 다닌다”라고 왜곡하는 것과 똑같은 맥락인 것이다. 난독증의 결과는 이렇게 무섭다.

본인은 지 박사의 행적에서 공 병우 박사의 정신을 새삼 느꼈다. 본업을 버리고 생뚱맞은 분야로 뛰어든 점, 공권력의 탄압을 받은 점(공 박사는 남산으로, 지 박사는 광주로. -_-)이 말이다. 특히 지 박사가 5 18 사태에 대해서 야사를 캐고 자료 모으는 건, 공 박사 버전으로 치면 과거 글자판 제정 과정의 흑역사를 추적하는 수준과 맞먹는다.

물론 본인은 이 승만과 박 정희에 대한 견해 외에 너무 전문적인 분야에 대해서는 그의 견해에 다 동감하지는 않는다. 솔직히 말해 잘 모르며, 별로 알고 싶지도 않다. 단지 그의 자세를 높게 사고 존경할 뿐이다. 요즘 세상에 색깔 구분을 명확하게 하고서 ‘빨갱이를 빨갱이라고 하지 않는 자가 바로 빨갱이이다’ 같은 사고방식을 지닌 사람이 얼마나 될까? 비록 빨갱이의 기준에 대해서는 논란의 여지가 있지만 저렇게 분명한 흑백논리 자체는 성경적으로 매우 바람직한 사고방식이다. 빨갱이 대신에 죄나 지옥 같은 개념을 집어넣어 봐라. (게다가 지 박사는 예수 믿는 사람도 아닌데!)

일제 강점기가 ‘러시아 강점기에 비해서’ 축복이었는지는 잘 모르겠지만, 본인은 아직 이 나라에 지 만원 박사 같은 분이 있다는 것은 정말 큰 축복이라고 자신 있게 말할 수 있다. 심지어 북한 주민 중에도 지 박사를 알고 존경하는 사람이 다수 있다는 건 상식. 지금 내가 이 정도 수준으로 지 박사를 지지하고 존경하는 티를 공개적으로 낸 것만으로도 본인을 싫어하게 되고 떠나고, 심지어 <날개셋> 사용마저 보이콧한 사람이 좀 있다. ^^;;; 지 만원 박사의 사상이 뭐가 그렇게도 악하나? 정말 이해가 안 되는데... 얘기나 좀 들어 보고 싶지만, 그들은 그런 대화조차도 원하지 않을 정도로 마음을 꽉 닫아 놓고 있을 것이다. 그럼 평생 그렇게 살지어다!

Posted by 사무엘

2010/07/02 08:30 2010/07/02 08:30
, , ,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/309

본인은 외가가 의성군 춘산면에 있다. 지금은 외조부모님이 모두 돌아가셨기 때문에 본인에게 그렇게 큰 의미는 없지만, 어머니는 고향인 거기를 굉장히 그리워하시며, 본인 역시 최근까지도 어머니와 함께 이제 외갓집은 아니지만 외조부모님의 산소를 찾아 그쪽 근방으로 드라이브를 한 적이 있다.

그런데, 요 몇 년 전부터는 외가로 가는 길목에 무슨 추모비 같은 게 새로 생겨 있었다. 국도 35호선을 타고 청송까지 가다가 의성 춘산면 방면으로 서쪽으로 꺾은, 청송과 의성의 경계 지점이다. 외가에서 걸어서 찾아가기에는 좀 멀지만 자전거 정도만 있어도 갈 만한 곳인지라, 본인에게 그렇게 생소하게 느껴지지 않는 곳이었다. 그런데 그건 다름아닌 지난 2003년의 대구 지하철 화재 참사 때 희생된 어느 학생을 기려서 만들어진 거라고 한다.

추모비는 꽤 오래 전인 2004년에 세워졌고 본인 역시 그 사실을 몇 년 전부터 어머니에게서 들어서 알고 있었지만, 지금까지 그걸 별로 대수롭지 않게 여기고 넘겨 왔다. 그런데 어쩌다 보니 우연히 호기심이 생겨 인터넷 검색을 해 봤다. 고인의 동상도 세워졌다고 하는데, 위치가 너무 외진 곳이고 고인이 그렇게 유명 인사는 아니어서 그런지 인터넷 상으로 사진 같은 건 찾을 수 없다.

고인이 누구냐 하면 이 현진 양이다(1984-2003). 본인하고 나이 차이도 별로 안 난다. 대구 외고 출신의 서울대 예비 03학번이었다.
고인은 사망도 아니고 실종으로 공식 처리됐다. 시신 수습도 못 할 정도로 처참한 최후를 맞이했다는 뜻이다.
http://daegusubway.or.kr/lost_detail.html?no=734&page=10
http://www.imaeil.com/sub_news/sub_news_view.php?news_id=12577&yy=2004

보통 불행은 꼭 가난하고 못 사는 집안에 터지는 경우가 많은데(일단 그런 사람이 숫자도 더 많으므로), 일단 이 양의 가정은 그렇지는 않은 것 같다. 아버지가 당당한 대구 시청에서 직급도 높은 공무원이고, 고인의 남동생도 나란히 대구 외고에 진학한 상태였다. 그런 데다가 고인이 서울대 입학까지 앞두고 있었으니 이 양만이 비슷한 다른 또래의 희생자보다 언론에 더욱 안타까운 죽음으로 부각된 게 아닌가 하는 생각도 든다. 저 가정은 대구 토박이인 것 같은데, 의성 내지 청송 쪽으로는 무슨 연고가 있어서 저기에 추모비가 세워졌는지는 잘 모르겠다. (어머니 왈, 고인이 어머니의 대학 동창의 질녀였다고 함.)

사용자 삽입 이미지
무덤은 허묘인 건가?
근처엔 고인의 모교인 대구 외고 교장의 추모사, 서울대 정 운찬 전총장의 애도사(우리 서울대는 이 현진 양을 서울대 입학생으로 결코 잊지 않을 것입니다), 고인의 생전 일기, 그리고 고인의 친구들이 돈을 모아 만들었다는 동상이 기념물로 놓여 있다.

대구 지하철 화재는 한 정신병자의 미친 짓부터 시작해서 지하철 당국의 병맛 나는 사건 수습 등 여러 악재들이 겹친 덕분에, 단일 화재 한 건 당 사망자(실종 포함) 수로는 전세계의 대형 사고들 중에서도 톱클래스에 드는 끔찍한 참사로 기록되었다. 192명 사망에 148명 부상은 심지어 1971년의 대연각 호텔 화재의 사상자마저도 능가하는 규모이다. 최초로 화재가 발생한 전동차보다도, 아무것도 모르고 반대편에서 진입한 전동차가 불이 옮겨 붙고 기관사가 그 상태로 문을 잠근 채 튀는 바람에 승객들만 몰살을 당했다. 이런... 마른 하늘의 날벼락이 따로 없다.

내 기억이 맞다면, 사상자 명단 중에 본인의 고등학교 동기하고 성명과 생년이 완전히 일치하는 사람이 있었다! 게다가 걔도 당시 경북 대학교 재학 중이었으니 대구 거주. 그러니 그 친구는 그 날 안부를 묻는 연락 때문에 전화기 트래픽이 폭주크리를 먹었다고 한다.

대구 지하철 화재 참사는 전국민에게 휴대전화가 보급된 21세기에 터졌다. 그래서 불타는 전동차 안에 갇힌 채 연기에 질식해 죽어가면서 희생자가 남긴 애절한 통화와 문자 기록들이 네티즌들의 심금을 더욱 울렸다. 비행기나 선박에서 난 사고가 아니기 때문에 이런 게 가능했다. 이것도 의미심장하지 않은지? 사실, 일본에서조차도 지하철 내부에서는 휴대전화가 안 터진다.

(과거 1985년 8월에 일본의 JAL123기 추락 사고 때는 승객이 흔들리는 기내에서 여권 여백에다가 유서를 간신히 쓴 게 남아 있음을 기억하라. 그때는 대구 지하철 참사와는 대조적으로, 비행기가 추락만 하고 다행히 화재는 발생하지 않아서 그런 유서가 전해질 수 있었다.)

대구 지하철 화재 참사의 여파는 오늘날의 서울 지하철에서도 쉽게 찾을 수 있다. 바로, 딱딱한 불연재로 완전히 개조된 좌석이다. 당시 노 무현 대통령의 특별 지시로 거의 2~3년만에 인테리어가 싹 물갈이가 되었다. 그리고 2007년 즈음부터는 스크린도어까지 급속도로 보급됨으로써 서울 지하철의 외관은 예전과는 완전히 달라진다.

대구 지하철 화재 참사는 딱히 부실 공사 같은 부류는 아니다. 단지 직원들이 군기가 빠질 대로 빠져서 비상사태에 대처를 못 하고 병크를 잔뜩 터뜨려서 긁어 부스럼을 낸 것이다. 지하철 탑승객에게 비행기 수준의 보안 검색을 강요할 수는 없는 노릇이므로(휘발유를 소지하고 타는지-_-), 앞으로 사회에 불만이 있는 저런 싸이코가 또 나오지 않으라는 법은 없다. 그러더라도 저 때보다야 시민들이나 승무원이 대처를 잘 해서 다시는 이 정도의 참사가 발생하지 않길 바란다. 다음에 외조부모 산소를 찾을 일이 있으면 이 현진 양의 추모비가 세워져 있는 곳에 예전보다 더 세심하게 눈길이 갈 것 같다.

끝으로 비슷한 사건이 또 떠올라서 사족 하나.
2003년 그 무렵이면 이 지선 씨가 인터넷 상의 유명인사로 한창 등극하던 시절이었다. 2000년경에 음주 운전 뺑소니 교통사고를 당하는 바람에 여자의 생명인 얼굴에 중화상을 입고 안면 장애 인증을 받은 그분 말이다. 그런 와중에 생명에는 지장이 없었고 더구나 컨택트 렌즈가 녹아내리지 않은 건 천만 다행이었다고 함. <지선아 사랑해>라는 신앙 간증 도서는 베스트셀러로 등극했고 본문의 일부는 본인이 개발한 타자연습 프로그램에도 실려 있다. 지금도 이분의 개인 홈페이지는 잘 운영되고 있는 모양이다.

Posted by 사무엘

2010/07/01 09:29 2010/07/01 09:29
, ,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/308

곡선 승강장, 승강장의 확장

서울 지하철을 포함해 수도권 전철역들 중, 승강장이 굉장히 심하게 굽은 곡선역으로는 무엇이 있을까?

가장 깊은 역이라든가 환승이 짧거나 긴 역에 대해서는 지금까지 충분한 연구가 이뤄져 있다.
또한 역이 아니라 노선 중의 급커브 구간에 대해서도 1호선 시청-종각을 비롯해 이미 답이 다 나와 있다.
하지만 승강장이 자체가 커브 모양인 역에 대해서는 본인도 지금까지 충분히 생각을 안 해 본 것 같다.

일단 급커브 승강장은 서로 건설 시기가 다른 두 노선의 환승역에 생기는 경향이 짙다. 신길 역이 아주 좋은 예이다.
1호선과 5호선을 무리하게 만나게 하느라 5호선은 노선 자체가 상당한 굴곡이 생겼으며, 1호선은 원래 커브이고 켄트(열차의 회전 주행 시 발생하는 원심력을 상쇄하려고 선로 한쪽을 기울이는 것)마저 상당하던 선로 위에다 역을 만든 티가 농후하다. 두 노선 모두 승강장의 모양이 꽤 곡선이 되어 있다.

4호선 동대문역사문화공원(구 동대문운동장) 역은 딱 커브 위에 환승역이 지어지는 바람에, 서울 지하철에서 손꼽히는 급커브 승강장이 되었다. 이 점에서는 7호선 고속터미널 역도 비슷하다.

선로는 곡선이어도 직사각형 모양의 열차는 엿가락처럼 외형을 바꿀 수 없다. 그렇기 때문에 곡선 승강장은 열차 출입문과의 간격이 벌어진다. 그만큼 승· 하차 과정에서 사고의 위험이 커진다. 이런 이유로 인해서 전철을 건설할 때 곡선역은 가능한 한 안 만들려고 하지만 그렇다고 해서 그런 역이 아주 안 생길 수는 없다. 꼭 환승역만 곡선 승강장은 아니며, 지상의 도로가 굽었다면 그 아래의 역도 응당 곡선역이 된다. 5호선 아차산 역이 비환승역으로는 좋은 예이며, 5호선 김포공항 역도 역과 인근 선로가 모두 굉장히 급격한 커브이다.

사실 수도권 전철의 역사상 최악의 곡선 승강장 기록 보유자는 다름아닌 경원선(현재 운행 계통상으로는 중앙선) 옥수 역이었다고 한다.
경원선 자체야 역사가 매우 길지만 옥수 역은 서울 지하철 3호선과 함께 환승 목적으로 개통하여 역사가 짧다. 환승 목적으로 개통했다는 말은, 타 노선과의 환승 편의를 위해 원래 역을 만들려고 의도하지 않았던 지점에 역을 무리하게 만들었을 수도 있다는 뜻이다. 앞에서 언급한 신길 역처럼 말이다.

일단 3호선 옥수 역도 신길 만만찮은 곡선 승강장이 되었다. 그런데 과거의 경원선 옥수 역은 3호선 역보다도 한술 더 떠서 열차 출입문과 승강장 사이의 거리가 무려 40cm에 달했다고 한다. 어린이 동반 승객은 어린이를 안고 풀쩍 뛰어넘어서 타야 했고 성인이라도 부주의했다간 그 간격 사이에 발이 쑥 빠져 버릴 수 있었다. 유모차나 휠체어로는 열차에 탈 수조차 없을 지경. 옛날 옥수 역 사진을 좀 보고 싶은데 인터넷 검색을 해도 잘 안 나온다.

게다가 옥수 역 근처를 보면 잘 알겠지만 주변은 온통 자동차 도로이다. 경원선 옥수 역의 위치가 인근 도로를 확장하는 데도 장애가 되었던 모양이다. 이런 몇 가지 이유로 인해서 1999년에는 3호선 역은 놔두고 경원선만 아예 선로를 남쪽으로 이설하면서 곡선을 완화하는 공사가 행해졌고, 이때 경원선 역도 예전보다 더 남쪽으로 옮겨졌다. 공사는 2001년에 끝났으며, 이로 인해 두 노선의 환승 거리는 좀더 길어졌다.
인근의 응봉 역도 좀 곡선이고 열차와 승강장 사이의 간격이 넓었던 걸로 기억하는데, 지금 다시 사진을 보니까 그렇게 심한 곡선도 아니다.

이렇듯 지상은 그래도 지하 구간보다는 승강장의 이설· 확장이 쉬우며 심지어는 선로조차 이설이 가능하다. 승강장 확장을 예로 들어 보자. 과거에 섬식으로 건설되었던 승강장(선로 폼 선로)이 승객 증가로 인해 맞은편에 또 승강장이 생기는 수가 있는데(선로 폼 선로 폼), 1호선 신도림 역과 외대앞 역이 그 예이다. 일단 선로는 최대한 건드리지 않고 승강장을 확장하는 방법을 쓴 것이다.
그 반면 1호선 석계 역은 아예 선로까지 이설해 가면서 섬식 승강장 자체를 확장한 흠좀무스러운 내력도 있다(2004년 공사 완료). 상대식 승강장보다 확장을 하기 훨씬 더 어렵다.

섬식 승강장은 양 선로 사이로 승강장이 비집고 들어간다는 특징 때문에 그 자체가 노선에 살짝 곡선을 만들기도 한다. 6호선 응암이라든가 2호선 삼성 역이 그 예이다. 특히 삼성 역이 처음 건설되었던 1980년대에는 거기 일대는 가히 허허벌판이었다. 그런 곳에다가 그토록 크고 아름답기 그지없는 승강장을 만들어 놓았으니, 당시엔 예산 낭비라고 언론에서 대차게 깠다.
그러나 지금 삼성 역이 이용객 수에 비해서 너무 크다고 욕하는 사람은 없을 것이며, 오히려 서울 시민들은 그 옛날에 오늘날의 서울의 형태를 결정해 버린 큼직한 2호선 순환선을 구상한 구 자춘 전 서울 시장의 선견지명을 칭송하는 단계가 되었다. (그러니, KTX 광명이나 천안아산 역도 오로지 지금만 내다보고서 예산 낭비라고 까기만 하지는 말고 좀더 기다려 보자.)

Posted by 사무엘

2010/06/30 08:30 2010/06/30 08:30
, ,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/307

※ CreateFont

받는 인자가 무려 14개나 되어, Win32 API 전체를 통틀어 손꼽힐 정도로 받아들이는 인자가 많다. MSDN 레퍼런스 없이는 함부로 꺼내 쓰지도 못한다.
그렇다고 해서 딱히 포인터를 전달한다거나, 결과값을 받는다거나 하는 것도 아니고 인자들은 다 단순한 int 아니면 문자열들이다. 이 값들을 LOGFONT라는 구조체에다 담아서 한꺼번에 전달하는 CreateFontIndirect라는 함수가 별도로 있기도 하다.

하지만 실제로 쓰이는 인자는 글꼴 이름과 크기(가중치 100), 그리고 아주 가끔 빌드/이탤릭 여부(가중치 20) 정도가 진짜 전부이다.
전문적인 워드/그래픽 프로그램이 아니고서야 장평값이 다르다거나 기울여진 상태로 글자를 찍을 일이 있기나 할까? 운영체제가 기본으로 지정한 퀄리티(안티앨리어싱 여부) 말고 다른 걸 지정할 일도 거의 없기는 마찬가지. 좀더 간단한 형태의 함수가 있었으면 좋겠다. MFC의 CFont::CreatePointFont()처럼 말이다.

※ CreateProcess

인자 개수 10개. 프로그램을 실행하는, 좀더 정확히 말하면 프로세스를 생성해 주는 가장 저수준 함수이다.
실생활에서는 파일 이름과 매개변수(가중치 100)만 있으면 거의 다 통용되고, 거기에다 초기 시작 디렉터리와 윈도우 초기 배치 방식을 나타내는 SW_* 값 정도만 있으면 될 것이다(가중치 20).

하지만 이 함수 역시 사용하기는 무진장 까다롭다. 파일 경로를 나타내는 버퍼는 read only여서는 안 되고 write 가능한 영역에 있어야 한다. 운영체제가 이 문자열을 그대로 strtok 스타일로 tokenize를 했다가 다시 원래 형태로 되돌려 주기 때문이다. null 문자를 잠시 삽입하므로 이는 버퍼를 수정하는 행위임.
디버거 붙일지 여부, 각종 보안 설정, 환경 변수 값, 심지어 멀티모니터 환경에서 프로그램을 초기에 띄울 모니터 위치 등등.. 별별 정보를 다 지정 가능하기 때문이다.

게다가 리턴값으로는 새로 생긴 프로세스 및 스레드의 식별자와 핸들 같은 것도 돌아오는데, 그 핸들은 이 함수를 호출한 프로세스가 알아서 Close 해 줘야 된다. 여간 손이 많이 가는 게 아니다.
MS는 프로그램을 실행할 때 16비트 시절의 잔재인 WinExec 함수를 사용하지 말고 이 함수를 사용할 것을 권하나, WinExec의 간편함(달랑 명령줄과 윈도우 배치 방식만 넘겨주면 됨!)의 유혹을 뿌리치기는 쉽지 않을 것이다. 사실 WinExec도 이제는 내부적으로 CreateProcess를 호출하는 방식으로 실행된다.

※ CreateFile

인자 개수 7개. C 표준 함수에 있는 fopen처럼 파일 이름과 용도(많지도 않다. 읽기 아니면 신규 생성)만 있었으면 좋겠지만, 역시 운영체제 API이다 보니 보안 관련, 파일 공유 여부 같은 잡다한 정보들이 엄청 많이 들어간다. 파일을 그저 문서의 열기/저장 기능 구현 용도로나 쓴다면 대부분의 세부 옵션들은 필요하지 없으며, 그냥 디폴트만 넘겨 주면 된다.
사실 이 함수는 디스크 상의 파일뿐만 아니라 파일의 형태로 표현 가능한 각종 운영체제 오브젝트들을 생성할 수도 있는 상당히 다재다능한 녀석이다. 피타고라스는 세상만물이 수라고 말했다면, 유닉스에서는 모든 게 파일이라고 한다. 윈도우 운영체제도 그런 철학이 아주 없지는 않다.

※ GetOpenFileName

우리에게 친근한 파일 열기 대화상자를 꺼내 주는 함수. 이제 얘는 인자로 일일이 입력 정보를 받는 방식을 애초부터 포기하고, 대신 크고 아름다운 구조체만을 받는 형태이다. C++로는 응당 클래스를 만들어 쓴다. MFC의 CFileDialog처럼.

하지만 실제로 자주 쓰이는 정보는 열기/저장 여부, 시작 디렉터리, 파일 포맷 필터 말고 있나? (가중치 100)
거기에다가 아주 가끔씩 파일 복수 선택 여부라든가 '읽기 전용으로 열기' 같은 자잘한 옵션만.. (가중치 30)
이렇게 굳이 구조체 만들 필요 없이 간단하게 실행이 끝나는 함수도 좀 있었으면 좋겠다는 생각을 꽤 자주 하곤 했다.

※ TaskDialogIndirect

너무나 클래식한 API인 MessageBox 함수를 대체하는 새로운 UI 대화상자 함수로, 윈도우 비스타에서 처음으로 추가된 걸로 잘 알려져 있다.
다른 건 '메시지 박스' 그대로 쓰면 되는데 "다음부터 이 메시지 표시하지 않음" 체크 같은 딱.. 2% 아쉬운 면모만 보충하고 싶을 때... 이 함수가 가히 구세주이다. 참고로 이 함수를 쓰려면 공용 컨트롤 6.0 매니페스트가 필수라는 걸 잊지 말자.

물론 얘는 TaskDialog와 TaskDialogIndirect로 아예 두 버전으로 나뉘어 있고, 쓸데없이 괜히 함수 프로토타입만 복잡한 게 아니라 진짜로 사용자가 실제로 쓸 수 있는 기능이 엄청 많은 게 맞다. 최근에 만들어진 만큼 API를 비교적 잘 설계했다는 생각이 든다. 하지만 정확하게 기억은 안 나는데 TaskDialog에는 정작 내가 꼭 써야 하는 customize 기능이 빠져 있어서 어쩔 수 없이 훨씬 더 복잡한 TaskDialogIndirect 함수만 써야 했던 것 같다. 그건 아쉬운 점.

대화상자의 제목, 큰 제목, 본문, 각 버튼의 모양, 링크, 라디오 상자 등등등...
이건 구조체가 아니라 아예 대화상자 생성 스크립트(XML 기반)를 받게 해도 이상할 게 없어 보인다.
최신 MFC에는 이 task dialog를 감싸는 클래스가 "당연히" 추가되어 있으며, 각종 상업용 GUI 패키지들에는 XP 이하 운영체제에다가도 task dialog를 자체 구현한 솔루션이 있기도 하다.

Posted by 사무엘

2010/06/29 08:53 2010/06/29 08:53
,
Response
No Trackback , 3 Comments
RSS :
http://moogi.new21.org/tc/rss/response/306

C++의 typename 키워드

C++ typename 키워드의 용법은 크게 두 가지이다. 그러나 주된 목적은 동일하다. 다음에 나오는 명칭이 변수도 될 수 있고 변수의 타입 이름이 될 수도 있는 문맥일 때, 이것이 명백하게 후자임을 알려 주는 것이다.

먼저, typename은 잘 알다시피 템플릿 인자를 선언할 때 class 대신 쓸 수 있다.

template<class T> void Swap(T& a, T&b );
template<typename T> void Swap(T& a, T&b );

위의 두 줄은 의미상 완전히 동일하다.
템플릿이 C++ 언어에 처음으로 추가되었던 당시에는 typename이라는 키워드가 없었고 템플릿 인자를 선언할 때에도 class를 썼던 것이다.
그러나 이것은 의미상으로 문제가 있었다. 아래의 예를 보자.

template <class T, int N>
class MyClass {
public:
    T data[N];
};

MyClass<int, 20> obj;

템플릿 인자로는 잘 알다시피 자료형 이름 내지 정수 숫자가 올 수 있다.
그런데 int N에 해당하는 템플릿의 인자로는 마치 일반 함수의 인자처럼 int 값에 해당하는 20이 쓰였다. 그런데, class T에 해당하는 첫째 인자는 그럼 T라는 클래스에 속하는 개체가 쓰인단 말인가?

전혀 그렇지 않다. 여기서는 진짜로 특정 type에 속하는 20 같은 값이 아니라, type 자체가 인자로 와야 하기 때문이다.
그래서 의미상 완전히 다르다는 걸 표현하기 위해 typename이라는 키워드를 class 대신 사용할 수 있게 되었다. 매우 바람직한 조치이다. class라는 키워드는 이제 진짜로 새로운 클래스를 선언할 때만 쓰도록 하자.

그리고 다음 용법이 개념상으로 진짜 중요하다. scope resolution과 관계가 있다.
A가 클래스 이름일 때 A::B라는 표현을 썼다면, C++의 특성상 B는 A의 멤버 변수일 수도 있고, A 클래스 내부에 선언된 다른 타입(클래스, 구조체 따위)의 이름일 수도 있다. 그 클래스 내부에 무엇이 선언돼 있냐에 따라서 해석이 달라진다. 처리가 어렵다.

그런데 설상가상으로 A 자체가 실제로 무슨 타입이 들어올지 모르는 템플릿 클래스의 인자라면? B에 대한 해석은 그야말로 귀에 걸면 귀걸이, 코에 걸면 코걸이가 될 수밖에 없어진다. A의 실체가 무엇이건 B의 정체는 컴파일 시점 때 다 결정되어야 하는데 말이다.

그럴 때 typename A::B를 써 주면, B는 A가 무엇이건 상관없이 변수가 아니라 말 그대로 type 이름으로 처리되어야 함을 컴파일러에게 알려 준다. 이 키워드는 절대적인 모호성 해결보다는, C++의 문법 해석의 복잡성을 좀 줄이고 컴파일러 개발을 더 수월하게 만들려는 목적이 더 크다고 보면 정확하다.
자, 이번에도 이해를 돕기 위해 예제 코드를 보자.

template<typename T>
class MyClass {
public:
    struct MYSTRUCT {
    };
    static MYSTRUCT dat;

    typename T::COMP pp;
};

struct SAMPLE {
    struct COMP {
    };
};

MyClass<SAMPLE> obj;

바로 이런 식으로 MyClass가, 자신의 템플릿 인자 T가 내부적으로 또 갖고 있는 COMP라는 구조체를 이용하기 위해서는 pp를 저렇게 typename을 줘서 선언해야 한다. COMP를 자료형 이름임을 명확하게 해 줄 필요가 있다.

비슷한 이유로 인해,

template<typename T>
typename MyClass<T>::MYSTRUCT MyClass<T>::dat;

템플릿 클래스 내부에 있든 구조체 형태로 된 static 멤버를 밖에서 또 정의해 줄 때, typename을 넣어 줘야 한다.
똑같이 MyClass<T>::로 시작하는 명칭이지만 typename이 선행된 MYSTRUCT는 자료형이고, dat는 멤버 변수로 인식되는 근거가 여기에 있는 것이다.
늘 생각하는 것이지만 C++의 세계는 참으로 심오하다. -_-;;

Posted by 사무엘

2010/06/28 08:56 2010/06/28 08:56
,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/305

« Previous : 1 : ... 185 : 186 : 187 : 188 : 189 : 190 : 191 : 192 : 193 : ... 215 : Next »

블로그 이미지

그런즉 이제 애호박, 단호박, 늙은호박 이 셋은 항상 있으나, 그 중에 제일은 늙은호박이니라.

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2024/05   »
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31  

Site Stats

Total hits:
2690097
Today:
710
Yesterday:
1238