« Previous : 1 : ... 148 : 149 : 150 : 151 : 152 : 153 : 154 : 155 : 156 : ... 221 : Next »

마이크로소프트 Windows라는 운영체제는 GUI 요소인 '창'(window)에서 모티브를 따서 작명되었다. 그 이름이 암시하듯, Windows는 창을 만들고 제어하는 것이 프로그래밍에서 큰 비중을 차지하며, 창과 창끼리의 의사소통은 메시지라는 놈을 통해서 행해진다. 이건 프로그래머라면 이미 다 잘 아는 내용일 것이다.

메시지는 굳이 GUI를 만들지 않더라도 응용 프로그램간에 데이터를 공유하고 스레드 동기화가 갖춰진 통신을 하는 데 상당히 유용한 수단이다. 오늘날 같은 보호 모드 멀티태스킹/멀티스레드 환경에서도 과거의 16비트 시절 같은 직관적인 통신 메커니즘을 제공하기 위해 운영체제가 밑에서 알아서 신경 써 주는 게 많기 때문이다. 그래서 그 기능만 쓰라고 message-only 윈도우라는 것도 있다.

메시지는 자신이 어떤 메시지인지를 나타내는 정수와, 덧붙일 수 있는 추가 숫자 정보 두 종류로 구성된다. 일명 wParam, lParam인데, 16비트 시절에는 메시지, wParam, lParam의 크기가 각각 16, 16, 32비트였다. 그것이 32비트 기계에서는 모두 32비트 크기로 확장되었고, 64비트에 와서는 msg만 그대로이고 나머지 둘은 64비트로 더 커졌다.

이론적으로 아무 숫자나 담아서 메시지로 전달할 수 있다. 그러나 운영체제는 내부적으로 다음과 같은 방식으로 메시지의 용도를 정해 놓고 있다. 이는 마치 운영체제가 메모리 주소의 용도를 영역별로 나눠서 정해 놓은 것과 동일한 맥락이다. (MS-DOS 호환용, 응용 프로그램용, 커널용 등)

첫째, 0부터 WM_USER-1까지 총 1024개의 메시지는 시스템 메시지로서 그 의미가 예약되어 있다.
0인 WM_NULL은 의도적으로 아무 일도 하지 않는 메시지로 비워 놨지만, 그 뒤부터 WM_CREATE(1), WM_DESTROY(2) 같은 것은 아마 윈도우 1.0 시절부터 있었을 기초 메시지들이다..

글자 입력란에는 cursor라고 하여, 공식적으로는 caret이라고 불리는 반전 사각형이 깜빡거린다. 이건 WM_TIMER로 구현했을 법도 해 보이는데 Spy++ 같은 프로그램으로 확인해 보면 그렇지 않다. 메시지 코드는 0x118이고 winuser.h에 WM_* 형태로 문서화되지 않은 비공개 내부 메시지에 따라 동작한다. 신기하지 않은가? (그 주변의 0x117이나 0x119대엔 당연히 공개된 WM_*메시지들이 꽉 차 있음.) 게다가 의미가 뭔지는 모르겠지만 wParam과 lParam에도 그냥 0이 아니라 뭔가 메모리 주소처럼 보이는 값들이 있다.

사용자는 0x1000 이내의 영역에 있는 숫자에다가 나만의 의미를 부여해서는 안 된다. 지금은 쓰이지 않아도 나중에 운영체제가 찜할 가능성이 있다. 가령, 마우스 휠의 움직임을 감지하는 WM_MOUSEWHEEL은 윈도우 98에서 정식으로 새로 추가되었고, 터치스크린 입력을 감지하는 WM_TOUCH 같은 메시지는 윈도우 7에서 추가되었다.

이런 식으로 Windows가 버전업되면서, 메시지가 미래에 자꾸 추가될 수 있다. 개인적으로 최소한 4096개도 아니고 1024는 공간이 너무 부족하지 않나 하는 생각도 든다. 나중에는 이 공간이 메시지들로 다 차 버리고, 추가 메시지는 WM_EXTEND_MSG 같은 최후의 메시지 하에서 부가 정보는 wParam과 lParam에 담겨 오게 되지 않을까? =_=;;

운영체제 메시지 중에는 WM_SETTEXT, WM_GETTEXT이라든가 심지어 WM_COPYDATA처럼 포인터를 통한 데이터 전달이 필요한 것도 있다. 운영체제의 SendMessage 함수는 그런 메시지를 다른 프로세스에다가 보내라고 사용자가 요청할 경우, 자체적으로 공유 메모리를 생성하여 메모리 주소 변환을 하고, 텍스트의 경우 심지어 ANSI/유니코드 변환까지 자동으로 한다. 그러니, lParam을 포인터로 인식하는 시스템 메시지에다가 엉뚱한 숫자를 집어넣어서 보냈다간 큰일난다. 아울러 포인터를 전달해야 하는 메시지는 SendMessage로만 전달 가능하지, PostMessage로는 되지 않게 운영체제가 막는다.

또한 일부 메시지는 반드시 특정 방법만 이용하여 생성해야 하는 것도 있다. 가령, WM_PAINT는 invalidate region을 만드는 함수를 호출해서 운영체제가 생성하도록 해야 하지, 응용 프로그램이 메시지 자체만을 인위적으로 만들어 내서는 안 된다. 실제로 실험을 해 보지는 않았지만, 없는 WM_PAINT를 페이크로 사칭하여 생성하는 것은 운영체제가 아마 안전을 위해 금지하지 않을까 싶다.

요컨대 WM_USER 이내의 메시지는 용도가 운영체제에 의해 예정되고 그에 따른 특수 처리가 추가될 여지가 있는 영역이므로, 사용자가 사칭하거나 조작해서는 안 된다.

그 다음 둘째 계층은 WM_USER부터 WM_APP까지 3만여 개 남짓한 영역이다.
이 메시지는 각 윈도우들이 자체적으로 의미와 용도를 마음대로 정해서 쓸 수 있다. 즉, 윈도우 클래스(RegisterClass)별로 의미가 완전히 private하다.

내가 뭔가 새로운 커스텀 컨트롤을 개발해서 이 컨트롤을 조작하는 수단을 윈도우 메시지라는 형태로 제공하고 싶다면, 각종 커스텀 메시지들을 (WM_USER + xxx)의 형태로 정의하면 된다.
임의의 크기의 데이터를 다른 프로세스끼리 전달하려면 프로그래머가 알아서 주소 marshalling를 하든가, WM_COPYDATA로 주고받을 구조체 스펙을 정하든지, 아니면 짤막한 문자열만 잠시 주고받으려면 atom에다 등록하여 atom 번호만 주고받든지 해야 한다. 뭐, atom은 오늘날에 와서는 거의 구닥다리 메커니즘으로 전락하긴 했지만.

리스트 박스나 콤보 박스는 Windows 1.0 시절부터 있었던 워낙 붙박이이다 보니 LB_ADDSTRING이나 CB_GETCURSEL 같은 메시지는 놀랍게도 앞의 시스템 메시지 영역에 들어있다. 그러니 그 메시지는 값만 보고도 대상 윈도우가 뭔지 볼 필요도 없이 문맥 독립적으로 용도를 추측할 수 있다. 대상 윈도우가 무엇이든 간에 LB_ADDSTRING의 lParam에는 언제나 포인터가 들어있다고 가정할 수 있다.

그러나 사용자 메시지부터는 얘기가 달라진다. WM_USER+1이라는 값을 갖는 메시지는 어느 윈도우가 받느냐에 따라서 처리가 완전히 달라진다. 붙박이 시스템 컨트롤 말고, 32비트 시절에 나중에 도입된 공용 컨트롤도 이제는 아이템을 추가하고 삭제하는 등의 자신의 메시지들은 시스템 영역에 있지 않고 이 사용자 영역에 있다.

따라서 메시지가 하는 일에 따라 부가정보를 변조하는 hook 같은 걸 만든다면, 메시지의 값만 볼 게 아니라 그 메시지를 받는 대상 윈도우의 클래스 이름도 확인해야 한다. 이건 철저하게 문맥 의존적인 메시지인 셈이다.

운영체제(시스템) 메시지, 그리고 사용자 메시지 이렇게 둘이 갖춰지면 끝인 것 같은데 플랫폼 SDK를 보니 셋째 계층인 WM_APP라는 것도 있다. 이건 도대체 뭘까?
이것은 내부적인 처리 방식의 차이에 따른 구분이 아니라 그냥 용도에 따른 명분상의 구분이다.

결론부터 말하자면 이 계층은 응용 프로그램이 어떤 컨트롤에다 서브클래싱을 한 뒤, 응용 프로그램이 새로운 윈도우 프로시저에다 보내 주는 '반사'(reflect) 메시지를 여타 메시지들과 구분하기 위해 존재하는 영역이다. 에디트 컨트롤을 예로 들면, 글자색과 배경색을 바꾼다거나 25자리 제품 시리얼 번호를 입력받는데 5자리마다 '-'를 자동으로 추가하는 것 같은 자잘한 동작 방식을 변경하고 싶을 때 서브클래싱을 이용한다.

일반적으로 컨트롤은 어떤 일이 일어났다는 통지를 부모 윈도우에다 WM_COMMAND(붙박이 컨트롤)나 WM_NOTIFY(공용 컨트롤)의 형태로 보내 주는데, 그때 해야 하는 처리가 천편일률적으로 정해져 있기 때문에 부모 윈도우가 아니라 해당 컨트롤의 서브클래스 프로시저 자신이 도로 받아서 알아서 하게 하고 싶을 때가 있다.

이때 그 통지 메시지는 WM_APP 이후의 영역으로 더해서 보내고, 그 메시지에 대한 처리를 내 custom 윈도우 프로시저에다 넣으면 된다. 이 영역의 메시지는 WM_USER 영역의 메시지, 즉 기존 컨트롤의 메시지와 겹치지 않는다는 보장이 있기 때문이다.

요컨대 시스템 메시지는 그냥 닥치고 global, WM_USER 메시지가 RegisterClass에 종속이라면, WM_APP 메시지는 CreateWindow 종속이라고 생각하면 된다. WM_USER급 메시지의 경우, 해당 윈도우 클래스가 CS_GLOBAL 스타일이 있다면 그 윈도우를 사용하는 모든 프로그램들에서 global 종속이 보장될 것이다.

다음 넷째 계층은 RegisterWindowMessage 함수를 통해 등록된 custom 메시지들에 배당된다.
운영체제 전체를 통틀어서 uniqueness가 보장되는 나만의 고유 메시지를 만들고 싶으면 아무래도 숫자만으로는 무리가 있다. Windows 메시지가 무슨 방대한 128비트짜리 GUID급도 아니니 말이다. 그래서 문자열로부터 0xC000 ~ 0xFFFF 영역에 있는 숫자를 메시지 값으로 얻어 낸다. 아마 hash 연산 같은 걸 쓰겠지.

단, 같은 문자열을 등록하더라도 돌아오는 숫자는 그때 그때 다르다. 그렇기 때문에 RegisterWindowMessage의 리턴값은 프로그램의 컴파일 시점 때 하드코딩으로 박을 수 없다. C++ 언어로 치면 switch문으로 판단을 할 수 없으며 번거롭지만 if를 써야 한다. 하지만 한번 등록된 값은 운영체제가 부팅되어 있는 한 불변이므로, 전역변수의 초기값으로 지정하는 것 정도는 가능하다.

이 custom 메시지는 상당히 유용하다.
시스템 전체에다 메시지 hook을 걸어서 나만의 처리를 하는 프로그램을 만들었다고 치자. 그리고 hook을 건 응용 프로그램과 여타 프로세스의 주소 공간에 침투한 hook 프로시저 사이에 통신을 해야 하는데 이때 가장 효과적으로 쓰일 수 있는 수단이 바로 custom 메시지이다. 내가 만든 프로그램이니 나만 아는 문자열로 custom 메시지를 생성하고, 그걸로 EXE와 hook DLL이 통신을 하면 된다는 뜻이다.

뭐, EXE로 보낼 때야 그냥 WM_USER나 WM_APP급의 고정된 상수만으로 충분하겠지만, 다른 수많은 임의의 프로세스들을 상대하는 훅 DLL로 보내는 건 여타 메시지들과 전혀 충돌하지 않는 게 보장되는 고유 메시지를 써야 할 테니 말이다.

윈도우 95/NT4 초창기 시절에 WM_MOUSEWHEEL 메시지가 운영체제 차원에서 없었던 시절엔, 마우스 휠을 인식하는 드라이버 내지 추가 프로그램을 실행한 뒤, 휠이 굴렀다는 메시지 값을 RegisterWindowMessage(MSWHEEL_ROLLMSG)로부터 얻게 하던 시절이 있었다. 이 문자열의 값은 다음과 같았다.
#define MSWHEEL_ROLLMSG  _T("MSWHEEL_ROLLMSG")

그리고 오늘날 custom 메시지가 쓰이는 또 다른 대표적인 분야는 시스템 트레이라고 불리는 notification area이다. 트레이에다가 자기 아이콘을 추가하는 프로그램들은 _T("TaskbarCreated")라는 메시지를 받았을 때 아이콘을 다시 등록해 줘야 한다.

운영체제의 셸은 자기가 갖고 있던 아이콘들을 자체 보관하지 않는다. explorer 프로세스가 에러가 나서 뻗었거나 강제 종료되었다가 다시 실행되었다면, 아이콘들이 싹 다 날아가게 된다. 이때 셸은 모든 프로그램들을 대상으로 저 메시지를 보내서, 프로그램들로 하여금 알아서 트레이에다 아이콘을 다시 등록하게 한다. 마치 WM_PAINT 메시지를 받았을 때 창이 알아서 자기 내용을 다시 그려야 하듯이 말이다.

저건 너무 유명한 메시지가 되어 버렸기 때문에 장기적으로는 WM_TASKBAR_CREATED 같은 시스템 메시지로 승격이라도 돼야 하지 않나 싶다. 그리고 응용 프로그램들이 늘어날수록 이런 custom 메시지의 공간도 부족해지지는 않으려나 우려가 된다. 16000여 개만으로 충분하겠지? custom 클립보드 포맷이라든가 스레드별로 할당되는 TLS 슬롯의 개수와 비슷한 맥락으로 공간의 한계가 존재하는 영역이라고 볼 수 있다.

Objective C는 언어 차원에서 생으로 문자열 메시지를 객체들 사이에 주고받는 걸 지원한다. C++ 일반 멤버 함수를 호출하는 것보다 오버헤드는 당연히 훨씬 더 크지만, 함수 프로토타입이 하나 바뀌었다고 프로그램 모듈간의 바이너리 호환성이 박살 난다거나, 재컴파일을 해야 하는 그런 불편함은 없다. 내가 옵C를 잘은 모르지만 Windows의 custom 메시지를 보니 문득 옵C 생각도 났다.

이렇게 윈도우 메시지의 계층 4개를 모두 살펴보았다. 시스템 메시지만 1024개로 영역이 매우 좁아서 WM_USER의 영역이 넓은 편인 반면, 나머지 계층은 16비트 정수에서 1/4에 해당하는 16384개를 사이좋게 나눠 쓰고 있다.
그리고 메시지를 담는 공간 자체는 진작부터 32비트로 커졌지만, Windows는 16비트 크기의 범위를 벗어나는 영역은 여전히 예약만 해 놓고 쓰지 않고 있다.

허나, 개인적인 생각은 이들 중에서 그래도 custom(registered) 메시지가 16비트 이상의 범위로 확장되거나 이동하기 가장 용이한 영역이 아닌가 싶다.
일단 얘는 upper bound가 없는 가장 마지막 계층인 데다, MSG 구조체를 포함해서 메시지 값을 담는 모든 자료형이 32비트 UINT로 이미 다 확장되어 있고, custom 메시지는 언제나 함수가 되돌리는 변수값으로 활용하지 하드코딩이 없으니, 확장에 가장 유동적으로 대처 가능하기 때문이다.

Posted by 사무엘

2013/02/25 08:39 2013/02/25 08:39
,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/800

철도 사진 분석 퀴즈

1. 다음 사진은 보다시피 경의선 지하 가좌 역의 승강장 역명판이다. 이 역명판이 있는 승강장은 서울(홍대입구)과 문산(DMC) 중 도대체 어느 방면 승강장일까?

사용자 삽입 이미지

정답과 해설


2. 아래의 사진은 대략 언제 어디에서 촬영되었을까? 물론 국내이다. (힌트: 레일의 개수가 심상찮다)

사용자 삽입 이미지

정답과 해설


 

Posted by 사무엘

2013/02/22 15:26 2013/02/22 15:26
Response
No Trackback , 4 Comments
RSS :
http://moogi.new21.org/tc/rss/response/799

내가 타인을 따라서가 아니라 스스로 서울 여행을 하고 제 발로 지하철/전철을 이용하기 시작한 건 2001~2002년 사이부터이다.
그리고 서울 지하철 중에서 5호선은 전동차가 아주 중독성 있는 특이한 가속 구동음을 낸다는 걸 스스로 인지한 게 한 2003년쯤이다.

서울 지하철 5호선!
인간이 발명한 교통수단에서 어떻게 이런 구수한 소리가 날 수 있는지 나는 골똘이 생각하지 않을 수 없었다.
이건 자동차처럼 연료를 폭발시키는 소리도 아니고, 비행기처럼 공기를 뿜는 소리도 아니고.. 도대체 무슨 기계를 만들어야 이런 소리가 날 수 있을까?
나팔을 부는 듯한 관악기 소리에 가까운지, 아니면 현을 켜는 듯한 현악기 소리에 가까운지는 내 음악 지식으로는 판단을 못 하겠다.

그래서 내부 디테일을 좀 공부하다 보니 몇 가지 용어를 알게 됐다. 전동차의 동력비 변환 메커니즘은 저항 제어, 쵸퍼 제어에 이어 반도체를 이용한 최신 기술인 VVVF(가변 전압 가변 주파수) 제어 방식으로 변모해 왔는데, 바로 VVVF 초창기에 속하는 차량이 이런 독특한 소리를 내는 것이었다.

그리고 사실은 VVVF도 다 같은 물건이 아니다. 초기의 VVVF-GTO 방식은 윙~윙 하는 소음이 큰 편이지만, 나중에 등장한 VVVF-IGBT 방식은 구동음이 조용해진 편이다. 서울 지하철 5호선 전동차는 물론 GTO 방식이다. 이에 대한 더 자세한 설명은 이곳에서.. 그리고 또 이곳 설명도 꼭 봐라, 두 번 봐라.

철덕들이야 이 소리를 아주 좋아하지만, 일반인들은 5호선 열차가 주행 중에 너무 시끄럽다고 불만이 많은 편이었다.
자갈 대신 콘크리트 노반, 좁은 터널, 굴곡이 많은 선형 등 여러 다른 이유들도 있지만, 당시 첫 도입되었던 VVVF 인버터도 소음을 가중시키는 요인 중 하나이긴 했다. 게다가 5호선 차량의 인버터는 원래 지하도 아니고 지상 전철용 부품이 납품된 거라고도 하고.

그래서 5호선의 운영사인 도철에서는 장기적으로 5호선 전동차의 인버터를 더 조용한 것으로 차츰 교체하기로 계획을 세웠으며, 지금으로부터 1년쯤 전인 2012년 2월, 제 502편성 열차 하나를 시범적으로 독일제 VVVF-IGBT 인버터로 교체해서 굴리기 시작했다.

난 그 소식을 인터넷을 통해 접하기는 했다. 그러나 지금까지 그 열차와 마주칠 일은 없었다. 수십 편성짜리 열차 중에 달랑 하나만 바뀐 거니까 말이다.
그랬는데.. 며칠 전에.. 드디어 조우했다!

환승을 위해 겨우 두 정거장 구간밖에 이용을 못 해서 구동음을 충분히 감상하지는 못했지만, 내 기억이 맞다면 지금 2-3-9호선 신형 전동차보다도 더 조용한 듯하다. 그쪽 계열 소리가 아니다. 첫음은 G와 G# 중에서 G에 더 가까웠지 싶다.
내가 지난 10년간 탔던 5호선답지 않게 전동차의 구동음이 너무 조용해져서 적응이 안 된다.

마치 예전에 6호선에서 잠깐 다니던 전설의 609편성을 보는 듯한 느낌이다.
그것처럼 지금 5호선에는 혼자 구동음이 튀는 열차가 하나 다니기 시작해 있다.
이런 식으로 이제 5호선의 마스코트인 ABB사 기존 구동음도 점점 듣기 어려워질 수 있으니, 이제 서둘러서 녹음하려면 녹음하고 구동음을 실컷 감상해 둬야겠다.

어쨌든 철도는 이렇게 아름다운 구동음을 내면서 달리는 전동차도 있으니, 참 웰빙 교통수단임이 틀림없다.

Posted by 사무엘

2013/02/20 08:39 2013/02/20 08:39
, , , ,
Response
No Trackback , 6 Comments
RSS :
http://moogi.new21.org/tc/rss/response/798

여러 기호(또는 문장 부호)들 중에서 따옴표는 컴퓨터로 입력할 때 좀 유별나게 처리되고 다뤄지는 면모가 있는 문자이다.
일단 따옴표는 기호가 쌍으로 붙은 큰따옴표와, 하나만 있는 작은따옴표로 나뉜다. 전자는 어떤 발언을 직접 인용할 때, 그리고 후자는 발성이 타인에게 실제로 들리지는 않는 혼잣말이나 생각을 인용할 때 통상 쓰인다.

그러나 이런 물리적인 구분이 명확하지 않은 경우도 있다. 재미있는 것은, 따옴표로 둘러싸인 인용문의 내부에 또 인용문이 또 등장할 때는 물리적인 구분과는 무관하게 맞은편 따옴표가 작은→큰→작은..의 순으로 번갈아가며 쓰인다는 점이다. 또한 따옴표들은 완전한 문장이 아니라, 문장 내부의 특정 단어를 단순히 강조하는 용도로도 쓰인다.

따옴표는 괄호와 마찬가지로 열고 닫는 구분이 있다. 그러나 타자기나 컴퓨터의 글자판에는 괄호와는 달리 여닫는 따옴표가 따로 배당되어 있지 않다. 방향 구분이 없는 "와 '가 각각 큰따옴표와 작은따옴표의 역할을 대신한다.

텍스트 에디터는 코딩용으로도 쓰이고 키보드에 배당된 아스키 문자가 그대로 입력되는 게 중요한 경우가 많기 때문에, 따옴표도 있는 그대로만 입력받는다. 그러나 워드 프로세서 정도 되면, 지금 입력하는 문맥에 따라 해당 문자를 여닫는 따옴표로 알아서 치환해서 입력해 준다. 여기서 아주 재미있는 차이가 존재하는데, 아래아한글은 전통적으로 이런 구분을 한글 글자판을 쓸 때만 하는 반면 MS 워드는 글자판 구분 없이 언제나 그렇게 동작한다.

글쎄, 한글 입력 방식에서는 세벌식 최종 글자판이 여는 큰따옴표와 닫는 큰따옴표가 따로 배당되어 있고 그걸로도 모자라 "까지도 있다. 이것은 컴퓨터에서는 다소 잉여스러운 설계인지도 모르겠다. 그 대신, 영미 문화권의 텍스트 문서에서는 tilde 글쇠의 아래에 있는 `가 종종 여는 작은따옴표로 쓰이고 기존 '(어퍼스트로피)는 닫는 작은따옴표로만 쓰이는 경우가 있다. 한국에서는 보기 힘든 관행인 듯.

얼마 전에 본인은 여닫이 구분이 없는 따옴표만 쓰인 빽빽한 영어 성경 텍스트의 따옴표들을 여닫이 구분이 있는 형태로 일괄 변환할 수 있겠느냐는 부탁을 주변으로부터 받은 적이 있었다. 그냥 "만 달랑 들어있으면 왠지 아마추어스러운 티가 팍 날 테니, 인쇄해서 책으로 낼 텍스트라면 그 정도 배려는 해 주는 게 좋을 것이다.

"를 계속 찾으면서 “와 ”로 번갈아가며 대치만 하는 걸로 일이 끝이면 얼마나 좋았겠냐만, 이거 패턴이 의외로 간단하지만은 않음을 알 수 있었다.
작은따옴표는 어퍼스트로피가 존재하기 때문에 닫는 따옴표의 개수가 더 많아진다. 더구나 s로 끝나는 단어의 뒤에 붙은 어퍼스트로피는 닫는 작은따옴표와 형태적으로 구분할 방법이 없다.

그리고 큰따옴표와 작은따옴표 모두, 인용문이 여러 문단에 걸쳐서 길게 반복되는 경우라면, 이전 문단에서는 닫는 따옴표로 마무리가 되지 않은 채 다음 문단에서 또다시 여는 따옴표가 나온다. 물론, 그렇지 않고 앞 문단에서는 여는 따옴표로 시작해서, 다음 문단에서는 닫는 따옴표로 곱게 끝나는 인용도 따로 있고 말이다.

그리고 아까 얘기했던 중첩 인용도 문제가 될 수 있다. 열큰(여는 큰따옴표)와 작큰(작은 큰따옴표) 다음에 입력되는 큰따옴표는 여는 큰따옴표가 되어야 하는데, 이런 점을 고려하지 않고 기계적으로 따옴표를 치환하면 “(열큰) “(열큰) ”(닫큰) ”(닫큰)의 순으로 등장해야 할 따옴표가 “(열큰) ”(닫큰) “(열큰) ”(닫큰)으로 잘못 짝지어질 위험이 있다.

텍스트에는 최대 3단계의 중첩 인용이 존재하더라. 이거 생각보다 꽤 복잡하지 않은가?
텍스트 매크로, 찾기/바꾸기 등 여러 방법 중 과연 어느 것이 가장 적합할지 고민했는데 결국은 여러 차례의 바꾸기 기능을 사용하기로 결정을 내렸다. 여는 따옴표가 확실한 조건을 지정해 준 뒤, 나머지 따옴표는 모두 닫는 것으로 간주하는 게 가장 속 시원하다. 구체적인 절차는 다음과 같다.

1. 줄의 맨 첫 칸에 등장하는 따옴표는 반드시 여는 따옴표이다. 상식적으로 문단이 닫는 따옴표로 시작하지는 않을 테니 말이다. 그래서 줄의 처음을 의미하는 정규 표현식 ^를 사용하여, 첫 칸의 따옴표부터 다 여는 걸로 모두 바꾼다.

2. 그리고 공백(whitespace) 다음에 등장하는 따옴표는 반드시 여는 따옴표이므로 그렇게 바꿈.

3. 끝으로, 여는 따옴표의 다음에 등장하는 따옴표도 반드시 여는 따옴표이다. (여는 큰따음표 다음의 작은따옴표. 그리고 vice versa)

4. 위의 조건들을 만족하지 않고 아직도 방향이 결정되지 않은 따옴표들은 모두 닫는 따옴표이다. 치환.

이 작업을 큰따옴표/작은따옴표별로 다 해야 하기 때문에 '모두 바꾸기'를 무려 8번이나 해 줘야 한다.
그러나 <날개셋> 편집기에서는 '일괄 치환' 텍스트 필터에다가 다음과 같은 조건을 주면 일격에 상황 종료. 굉장히 유용하다.

"\n\"","\n“"
"\n'","\n‘"
" \""," “"
" '"," ‘"
“',“‘
"‘\"",‘“
',’
"\"",”

따옴표가 특별한 의미로 쓰이는 곳에서 따옴표 자체를 지정해야 하다 보니, 글자를 알아보기가 몹시 힘들다. 게다가 코딩용 폰트가 아닌 폰트는 여는 따옴표와 닫는 따옴표도 형태를 분간하기가 쉽지 않은 경우가 태반.
타자기 내지 컴퓨터 키보드에서 따옴표의 방향 구분이 별 의미 없다고 간주하여 괜히 없앤 게 아닌 듯하다.

아울러, 데이터베이스 같은 곳에서는 문자열 내부에 또 큰따옴표가 들어있을 때, 문자열의 시작을 '큰따옴표 두 개'로 표현하는 경우가 있다. 다음은 그런 문자열을 원래대로 복원하는 일괄 치환 조건이다.

"\"\"","\""
"\"",

그러고 보니 방향 구분이 없는 큰따옴표는 "위와 같음"(상등)을 의미하는 기호로도 쓰이며, 심지어 작은/큰따옴표가 각각 분과 초를 의미하는 단위로도 쓰인다. 신기하다. 본인은 이 경우까지 고려하지는 않았다.

Posted by 사무엘

2013/02/18 08:28 2013/02/18 08:28
,
Response
No Trackback , 10 Comments
RSS :
http://moogi.new21.org/tc/rss/response/797

C++의 for each, in 키워드

심각한 뒷북인지 모르겠는데,
본인은 비주얼 C++에서 이런 문법이 가능하다는 걸 아주 최근에야 알게 되었다.

DATA container[N];

for each(DATA elem in container) {
    do_with(elem);
}

저건 언어 차원에서 제공하는 새로운 문법이기 때문에 STL <algorithm>의 for_each 함수와는 다르다.

배열을 순회하기 위한 별도의 임시 변수(일회용 int i나 거추장스러운 포인터)를 선언할 필요 없이, 코드를 굉장히 깔끔하게 만들 수 있어서 좋다. 이것의 주 용도는 C++을 상당한 고수준 언어로 끌어올린 C++/CLI 환경이지만, 네이티브 환경에서도 정적 배열과 STL 컨테이너 정도에서는 아주 요긴하게 쓰일 수 있다.

DATA가 int 같은 아주 기본적인 자료형이라면 그냥 저렇게 써 주면 되고, 개당 수십~수백 바이트씩 하는 무거운 구조체라면 const DATA&를 하면 된다. 그리고 순회 중인 배열 자체의 데이터를 루프 안에서 고쳐야 한다면 물론 DATA&라고 써 주면 된다.
저건 C++11 같은 급도 아니고, 생각보다 굉장히 오래 된 비주얼 C++ 2005에서부터 지원되기 시작했다고 한다.

컴파일러가 언어 표준에 없는 변칙 문법이나 키워드를 지원하는 것은 특정 CPU나 운영체제에 종속적인 기능을 추가로 제공하기 위해서이다.
하지만 for each는 그런 범주에 속하지 않으며, 전통적인 C/C++ 언어의 토큰 나열과 비교했을 때 문법도 굉장히 이질적이다. 그럼에도 불구하고 비주얼 C++이 이것을 제공하는 것이 신기하기 그지없다.

그리고 또 하나 생각할 점은, 저기서 each와 in은 문맥 의존적인 임시 예약어(키워드)라는 것이다. for 다음에 이어졌을 때만 키워드이며, 다른 곳에서는 사용자가 each나 in을 일반적인 변수/함수명으로 얼마든지 쓸 수 있다는 뜻.

언어 설계 차원에서 C/C++은 원래 임시 예약어라는 게 없는 언어이다. 한번 예약어로 찜해진 단어는 그 어떤 곳에서도 명칭으로 결코 쓰일 수 없다. 다른 구문이나 수식을 파싱하는 데는 문맥 의존적인 어려운 문법이 많지만, 예약어 식별만은 단순하게 만들려고 했는가 보다.

그 반면, 파스칼은 begin, end, if, for 같은 단어야 절대적인 예약어이겠지만 forward(함수 전방 선언용)를 포함해 몇몇 키워드는 일정 문맥에서 별도의 의미를 갖는 임시 예약어이다. 그리고 객체지향 개념이 추가된 오브젝트 파스칼의 경우 virtual 같은 함수 modifier, 그리고 클래스 내부에서 public/protected 같은 멤버 접근성 modifier도 임시 예약어이다. C++은 그렇지 않다.

비주얼 C++은 for each, in뿐만 아니라 abstract, override, delegate 등 몇몇 비표준 임시 예약어를 더 두고 있기도 한데, 이것은 대개가 C++/CLI용이고 네이티브 환경에서는 쓰일 일이 별로 없다. 일반적인 경우라면 비표준 확장 예약어는 앞에 __를 붙여서 명칭 충돌의 여지를 없앤 뒤에 절대적인 예약어로 추가하는 게 관행일 텐데, 저것들은 그렇게 하지 않았다.

끝으로, for each, in에다가 2차원 배열을 넘겨 주면 어떻게 될까 궁금해서 시도를 해 봤는데, 이때도 각 원소들이 하나씩 순서대로 순회되더라.
각 배열을 배열의 포인터로 받으면서 1차원적으로 순회되지는 않는가 보다.

비주얼 C++ 2010은 인텔리센스 컴파일러와 실제 컴파일러의 동작이 서로 다르기라도 했는지, IDE에서는 이때 each 변수가 2차원 배열과 서로 호환이 되지 않는다고 빨간줄 에러를 뱉은 반면, 실제 컴파일은 됐다.
2012에서는 그것이 개선되어 IDE에서도 빨간줄이 생기지 않는다.

Posted by 사무엘

2013/02/16 08:17 2013/02/16 08:17
, , ,
Response
No Trackback , 4 Comments
RSS :
http://moogi.new21.org/tc/rss/response/796

불편하지만 외면할 수 없는 진실
지 만원 지은 <제주 4·3 반란 사건>을 읽고

난 어린 시절부터 근대로 갈수록 우리나라 역사를 좋아하지 않는 편이었다. 임진왜란 이후로 우리 민족이 뭔가를 발명하고 정복하고 성공하고 백성들이 태평성대를 누렸다는 식의 좋은 기록을 거의 찾을 수 없었기 때문이다.

현실에서는 백성들은 탐관오리의 학정에 줄곧 고통받았으며 개혁은 한계에 부딪혀 실패하기만 했다. 나중에는 좋든 나쁘든 한 나라의 왕비라는 사람이 외국 침입자에게 살해당하는 희대의 치욕을 당하기까지 하고, 궁극적으로 주권이 외세에 완전히 빼앗기는 것으로 역사의 한 페이지가 끝난다. 빼앗긴 주권을 훗날 극적으로 되찾기는 하지만 이것도 우리 힘으로 스스로 이룬 것이 아니며, 덕분에 이념 대립과 국토 분단, 동족상잔 같은 또 다른 비극이 이어진다.

그래도 알고 보니 우리나라 역사에는 비극만 있는 게 아니었고 지도자 복이 없기만 한 것도 아니었다. 정말 하늘이 내려 준 은인이라고밖에 볼 수 없는 지도자가 그 가난하고 열악하고 위험하던 여건 속에서 한반도의 공산화를 반쪽만이라도 필사적으로 막고 올바른 이념으로 국가를 세웠으며, 미국을 든든한 우방으로 만들었다. 그리고 이 기반 위에서 우리 민족은 기적적인 경제 성장까지 이뤘다. 이 정도면 상식적이고 정상적인 국가관과 역사관을 지닌 사람이라면 자기네 나라의 내력에 충분히 자부심을 가질 만하지 않은가?

하지만 있는 그대로 가르쳐지고 대대로 전수되어야 할 대한민국의 역사는 불행히도 심한 공격을 당하고 있다. 공이 과를 객관적으로 월등히 압도하는 지도자가, 역사를 몰라도 너무 모르는 후세에 의해 저열한 중상모략과 부관참시를 당하는 꼴을 본인은 그냥 넘어갈 수 없었다. 피아식별을 제대로 할 수 없는 상황에서 불가피하게 벌어진 민간인 오폭이 조직적인 민간인 학살로 와전되고, 반역자가 소위 민주화 투사로 둔갑하는 것을 보니, 이건 정치색을 떠나서 정말 뭔가 한참 잘못되고 있다는 생각을 떨칠 수 없었다.

과거 일제의 만행에 그렇게도 분노하던 사람들이 북한이 더 최근에 저지른 잔학한 테러, 무력 도발, 민간인 학살을 왜 그토록 쉽게 잊어버리는가? 사람의 자유를 빼앗고 도덕과 정신을 무참히 파괴하는 사악한 북한의 사회 시스템을 왜 그리도 만만하게 생각하는가? 우리가 이렇게 편하게 인터넷을 하면서 북한 김 정은 정권을 비웃을 수 있는 게 누구 덕분이고 무엇 덕분인지 혹시 진지하게 생각해 본 적은 정녕 없는가?

이런 일이 벌어진 것은 우리 국민들이 사상이 글러먹어서 북한 정권을 직접 지지하기 때문이 결코 아닐 것이다. 단지, 가슴으로만 애국을 할 뿐 머리와 시스템적인 안목으로 애국을 못 해서 극소수 불순분자가 벌이는 역사 왜곡과 선전 선동, 시체 장사에 속아 넘어갔기 때문이다.

북한은 남한을 예전처럼 무력으로는 도무지 무너뜨릴 수 없기 때문에 남한의 정신 기강부터 먼저 무너뜨리고 있음을 우리는 잊지 말아야 할 것이다. 그들은 우리나라의 발달된 인터넷 인프라를 이용하여 유언비어를 퍼뜨리고, 우리 사회의 치부만을 편파적으로 들추고, 정부과 국민 사이에 극심한 불신풍조를 조장한다. 국가에 몸바쳐 충성한 애국자를 수구꼴통으로, 반역자를 민주투사로 바꾸는 역사 왜곡은 덤이다. 이것은 남을 교묘하게 쓰러뜨리려는 모든 '악의 무리'들이 분야를 불문하고 공통적으로 취해 온 전략이다.

제주 4·3 사건도 그런 예에 속한다.
책의 저자는 이 사건을 조명하기 위해, 해방 직후에 한반도가 분단된 과정은 두 말할 나위도 없고 아예 일제 강점기 때 한반도에 공산주의 사상이 처음으로 들어온 배경부터 면밀히 파헤쳤다. 그 내역을 보노라면 한반도가 공산화되느니 차라리 일제 치하에 있는 게 더 낫겠다는 생각이 들게 된다. 이왕 먹힐 거면 소련이 아니라 일본에게 먹힌 게 오히려 축복이라는 말이 괜히 나온 게 아니다.

미국· 일본 등 그 당시에 나름 선진국 축에 들던 나라들은 전염병처럼 퍼지고 있던 소련 발 공산주의 때문에 골치를 썩고 있었다. 그들이 내세우는 프로파간다는 마치 이단 종교 교리처럼 무지한 사람들을 현혹하고 선동하기 매우 좋은 형태였기 때문이다. 이런 현실적인 배경을 모른 채 오늘날의 북한은 공산주의하고는 무관하다는 식으로 안일하게 생각하는 것은 잘못임을 이 책은 알려 준다.

한반도 본토에서 떨어져 있던 제주도를 공산주의 체제로 뒤엎으려는 계획은 일제 강점기 때부터 진행되고 있었다는 점에서 본인은 놀라움을 감출 수 없었다. 또한 박 헌영은 6·25를 사주한 것 이상으로 4·3 사건에 대해서도 대한민국에 씻을 수 없는 반역죄를 저질렀음을 이 책을 통해 알게 되었다. 이 사건이 좌익과 우익이 모두 연루된 처절한 피의 비극으로 끝난 데는 일차적으로는 '빨갱이'들의 교묘한 위장 전술과 잔학성, 피아식별의 어려움, 그리고 다음으로 상대편 진영에 대한 극심한 불신과 증오, 보복 심리라는 요인이 작용했다.

이 사건은 친북 세력이 일으킨 반란임이 너무 명확하기 때문에 그 어떤 좌편향 인사라도 감히 북한 쪽을 일방적으로 두둔하지는 못한다. 그럼에도 불구하고 좌파 성향의 정권 때 반란의 주동자가 명예가 회복되고 훈장이 추서되기까지 했다고 한다. 사건의 피해자인 당시의 제주도민들조차도 이것은 불순분자가 일으킨 무장 반란일 뿐 남북 북단을 반대하는 항쟁(?)이라고는 여기지 않았었는데 말이다. 사건이 그렇게 왜곡되어 재해석되고 있는 것은 심히 우려스러운 일이 아닐 수 없다.

책을 덮으면서 두 가지 의문이 들었다.
하나는 이것이다. 이런 불편한 진실을 파헤치는 책을 왜 현업에 종사하는 역사학자가 아니라 응용수학을 공부한 시스템공학 박사가 썼을까? 이 책을 쓰기 위해 막대한 기회비용을 감수하면서 얼마나 많은 문헌들을 읽고 공부해야 했을까?

희극인지 비극인지는 모르겠으나, 내가 관심을 갖고 있는 다른 분야에도 이런 예가 종종 있어 왔다. 세벌식 한글 타자기를 발명한 천재인 공 병우 박사는 안과 의사였고, 오늘날 흠정역이라고 성서 공회 성경보다 더 나은 우리말 성경을 만들어 보급하고 있는 분은 기계공학을 전공한 공대 교수이다. 머리가 시대를 앞서 가는 선각자들이 맑은 영혼과 양심의 자유를 추구하면서 좁은 길을 먼저 간 덕분에, 다른 국민들도 더 똑똑해지고 삶이 더 윤택해져 왔다. 어느 분야든 그 맥이 부디 끊어지지 않기를 바랄 뿐이다.

그리고 다음으로는 세계적으로 유례를 찾기 힘든 비정상적인 국가인 북한이라는 나라의 정체성이 더욱 궁금해졌다.
숙주가 완전히 죽어 버리면 바이러스 자신도 죽는데, 북한은 왜 하필 다른 공산주의 국가들조차 가지 않은 최악의 길만 골라서 가 있을까? 북한도 처음에는 그래도 여러 당이 존재하고 주민들을 먹여 살릴 최소한의 생각은 하고 있었는데 어쩌다가 주민은커녕 군인들마저 못 먹여 살릴 정도로 나락으로 떨어졌을까? 북한 수뇌부들은 지금 머릿속에 무슨 생각을 하고 있는 걸까? 그들은 아직까지도 그렇게도 남한을 못 잡아먹어서 안달이고 그게 가능하다고 생각하고 있을까? 많은 생각이 들지 않을 수 없었다.

이 책의 저자는 정치색이 굉장히 강한 논객으로 세상에 알려져 있고, 사람마다 사상적인 호불호가 극명히 갈리는 분이다. 그러나 저자의 일부 극단적인 평론이나 주장에 공감하지 못하여 선뜻 받아들이지는 않을 수 있어도, 친일하고는 아무 관계 없는 프로필을 가진 멀쩡한 군사 평론가를 친일파로 몰고 가는 것은 여론 조작과 선동의 결과로 풀이할 수밖에 없다.

또한 북한의 비열하고 집요한 대남 도발사는 지구가 둥글다는 사실만큼이나 객관적으로 입증되어 있다. 이것이 정면으로 뒤집히고 반박될 일이란 나라가 망하지 않는 한 없을 터이며 4·3 사건에 대한 기록도 그러할 것이다. 팩트가 정치색으로 매도되지 않으면 좋겠고, 저자에 대한 편견 하나 때문에 진실까지 가려지는 일도 발생하지 않기를 바란다. 정말 만에 하나 이 책이 정치색을 띠고 있다고 할지라도, 그 정치색은 무슨 불확실한 음모나 들추고 국가에 대한 피해의식과 불신을 조장하는 게 아니라, 우리나라에 대한 감사와 애국심을 북돋우는 건전한 정치색일 것이다.

우리나라에 아직 지 만원 박사 같은 분이 있는 것은 과거에 조선이 러시아 대신 일제에게 먹힌 것보다는 훨씬 더 큰 축복임이 틀림없다. 대한민국의 역사만 제대로 알아도 자부심은 충분히 생기며, 환단고기 같은 위서로 대리 만족을 얻어야 할 필요조차 없다. 이런 책이 널리 읽혀서 전쟁을 겪은 적이 없는 세대에게 공산주의의 해악이 알려지고 자유와 안보의 소중함이 전파되고, 북한의 대남 도발사가 있는 그대로 폭로되며 내 조국은 이런 위태로운 와중에도 오뚝이처럼 굳게 일어선 나라라는 사실이 널리 퍼졌으면 좋겠다.

Posted by 사무엘

2013/02/13 19:26 2013/02/13 19:26
, , , , ,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/795

날개셋 한글 입력기 6.8

1. 6.8 버전의 의미

<날개셋> 한글 입력기 6.8이 나왔다. 2013년에 나온 최초의 버전이다.
사실 6.71과 6.8의 변화량은 6.7과 6.71 사이의 변화량보다도 적을지도 모른다.
새로운 기능이 추가된 게 없고, 양 버전 사이의 바이너리 호환성이 깨진 것도 없다.

그러나 6.71의 다음 버전을 6.72 대신 6.8로 잡은 것은, 이 버전에서 드디어 외부 모듈이 Windows 8 운영체제를 정식 지원하기 시작했기 때문이다. 비록 내 주변에 Win8 쓰는 사람은 아직 한 명도 못 봤지만..;;;

사용자 삽입 이미지

원래 계획은 6.7의 바로 다음 버전을 6.8로 하고 Win8을 바로 지원하는 프로그램을 만드는 것이었다.
하지만 여건상 그렇게는 못 하고 중간에 6.71을 거치게 됐다. 일단 Win8과 관련하여 편집기의 당장 급한 이슈만 해결하고, 더 근본적인 연구가 필요한 사항은 다음 버전의 숙제로 미룬 것이다.

6.71은 0.01만 올리기에는 해 놓은 게 많지만 그 내역이 딱히 존재감이 없다.
그 반면, 6.8은 절대적인 양은 0.09만 한 변화는 아니지만 그게 바로 'Windows 8 지원'이라는 존재감 큰 변화이다.
그래도 지금 두 버전의 변화 사항을 합하면 6.7 이후로 0.1쯤은 충분히 올릴 명분이 된다.

2. 수익 모델

이번 6.8 버전은 지금보다 더 이른 1월 중에 나올 수도 있었다.
그러나 본인의 직장 스케줄이 다소 바빠지고, 거기에다 투잡 같은 일종의 부업까지 뛰느라 한동안 <날개셋> 쪽으로 연구 개발을 전혀 할 수 없었던 관계로 프로그램의 완성이 늦어졌다. 시간이 없고 너무 힘들어서 이제 앞으로 투잡 같은 건 당분간 안 하련다.

투잡이라는 게 내가 생활고-_-에 시달려서 하는 건 아니고, 이게 그나마 <날개셋> 한글 입력기의 기술로 금전적인 이득을 얻는 통로라는 의미와 명분이 있어서 종종 해 왔다. 내 프로그램은 엔진 그 자체는 일반인을 대상으로 유료로 판매하는 상업용 소프트웨어가 아니고 심지어 광고 노출로 돈을 버는 것도 아닌데, 대회 상금이 아니면 이게 이윤을 창출해 온 유일한 방법이다.

별 게 아니라, 바로 <날개셋> 한글 입력기로 구현할 수 있는 입력 방식을 떼어서, 날개셋이라는 브랜드를 떼어내고 해당 코드만 최적화 static link하여 고객이 원하는 문자 입력 솔루션을 외주 개발하는 것이다. 물론 핵심 루틴은 빌드가 가능한 static library 형태로만 주고 소스 공개 안 한다.

세상에 날개셋 같은 완전 universal한 솔루션도 직접적인 수익 모델이 없으며, 표준 두벌식 다음으로 가장 인지도가 높고 구조적으로 우수한 공 병우 세벌식 같은 글자판조차도 만년 듣보잡 신세를 면치 못하고 있는데.. 한글 입력 방식 그 자체만으로 이제 무슨 사업을 하고 수익을 낼 게 있는지에 대해서는 한글 입력기의 개발자인 나조차도 회의적이다. 그래도 프로그램 만들면 개발비를 준다고 하고, 노력 대비 수지가 맞다고 여겨지니까 한다.. ^^

아무래도 일반적인 입력 방식은 레드 오션이 된 지 오래이니 진입할 틈새가 없고, 장애인용이나 동시치기 속기 같은 특수한 마이너 분야를 노려야 하지 않을까 싶다. 모바일이 아닌 PC용이라면 더욱 그러하다.

다만, 난 예전에도 공언했듯이 이미 소속된 직장이 있는 데다, 자체적으로 글꼴 연구도 해야 하고 나만의 연구 개발도 여전히 계속해야 하는데... 자꾸 외부에서 부탁하는 걸 받아서 하면 내가 자기 계발을 할 시간을 빼앗기기 때문에 이것도 큰 딜레마이다. 외부로 품팔이를 하지 않고 내가 하는 일만으로 경제적으로 자립할 수는 없을까? 이것도 점점 생각하지 않을 수가 없음을 느낀다. 정 답이 없으면 난 농담 반 진담 반으로 한 10년쯤 뒤엔 그냥 철도로 업종을 바꿔 있을 수도 있다. ㅋㅋ

3. Windows 8 이모저모

자, 암울한 돈 얘기는 그만 하고, 다음 주제인 Windows 8로 넘어가겠다. Windows 8에서는..

(1) 32비트 시절 이래로 전통적이던 관행을 깨고, 모든 프로그램이 동일한 입력기를 공유하는 설정이 추가되었으며 이것이 기본으로 적용되어 있다. 단, 옵션을 바꾸면 예전처럼 스레드별로 따로 놀게 할 수도 있다.

(2) active 입력기와 default 입력기의 구분이 없어졌다. 한 프로그램에서 입력기를 바꾸면(active) 그게 곧 default가 되며, 다음에 실행되는 프로그램은 그 입력기를 기본으로 사용하고 있다. 이것은 예전 Windows 버전처럼 동작하게 하는 옵션이 없으며, 그냥 개념을 저렇게 간소화시킨 듯하다.

(3) language bar(입력 도구모음줄)가 극도로 단순해졌다. 시스템 트레이에 '입력기 아이콘'과, 이 입력기의 '상태 아이콘'이라는 단 두 개의 아이콘만이 고정되어 나타나며, 나머지 자질구레한 기능들은 '상태 아이콘'을 우클릭했을 때 나타나는 메뉴를 통해 선택하게 되어 있다. 단, 옵션을 바꾸면 예전의 전통적인 길쭉하고 버튼 많은 language bar 방식을 쓸 수도 있긴 하다.

Win8의 디자인은 사실 TSF가 도입되기 전에 윈도우 95~ME가 사용하던 internat.exe 기반의 indicator 방식으로 되돌아 간 것이나 마찬가지이다. 그때도 IME 아이콘은 시스템 트레이에 입력기 아이콘과 상태 아이콘 둘만 있었기 때문이다. 디자인이 돌고 돌아 복고풍이 채택된 것 같다.

<날개셋> 한글 입력기 6.8은 이제 이 새로운 상태 아이콘을 지원한다. 이 아이콘은 우클릭을 하면 전체 기능을 선택하는 메뉴가 나오고 좌클릭을 하면 글자판(한/영 상태 같은)을 전환하는데, 글자판을 전환하는 규칙이 예전의 글자판 전환 버튼과는 살짝 다르다.

Windows 운영체제는 내부적으로 한글 아니면 영문이라는 이분법적인 구도로 자체 상태를 정의한다. 그러나 <날개셋> 한글 입력기 엔진은 임의의 n개의 입력 항목을 가질 수 있다. 그래서 기존 글자판 전환 버튼은 입력 항목이 딱 2개 존재할 때만 toggle 방식으로 동작하고, 3개 이상일 때는 메뉴를 표시하여 무슨 글자판을 지정할지 사용자가 직접 선택하게 했다.

하지만 Windows 8의 새로운 상태 표시 겸 글자판 전환 버튼은 동작 방식이 약간 다르다. 메뉴를 선택해야 하는 동작은 전적으로 우클릭이 전담한다. 그리고 좌클릭을 했을 때는 언제나 직전에 사용하던 non-trivial 글자판과 trivial 글자판만을 toggle 형태로 왔다 갔다 한다. trivial이란 '빈 입력 스키마', 또는 '빈 입력 스키마와 호환되게' 옵션이 지정되어 아무 글쇠도 처리하지 않는 '영문' 모드이고, non-trivial은 그렇지 않고 글쇠를 자체 처리하는 '한글' 모드에 대응하는 입력 항목이다. 실제로는 한글 이외의 다른 문자를 입력하더라도 말이다.

내가 살펴보니 기존 데스크톱 말고 메트로(Modern UI) 모드에서는 별도의 IME 툴바 같은 것 자체가 화면에 나타나지 않다 보니, 문자 입력란이 포커스를 받으면 IME가 자신의 한/영 모드를 근처에다 잠깐 표시했다가 사라지는 기능까지 제공하는가 보다. <날개셋>의 이번 버전은 그것까지는 구현하지 않았다. 일단 동작하는 것 그 자체에 의의를 두련다.

4. 다음 버전 계획

이번 6.8 버전은 <날개셋> 한글 입력기 6.x대의 마지막 버전을 염두에 두고 있다. 물론 Win8 지원과 관련해서 미흡한 부분이 또 발견되거나 사소한 기능 개선들의 양이 일정 수준을 넘어선다면 부득이 6.8x가 또 나와야겠지만, 새로운 기능이 추가된다거나 하면 반드시 7.0으로 갈 것이다.

그리고 혹시나 해서 말인데, Windows 8을 쓰고 있지 않다면 6.71하고 6.8이 아무 차이가 없느냐 하면 그건 물론 아니다. 예전 글에서 언급되었던 버그들이 고쳐졌다. 특히 6.71은 버그 때문에 사용자 정의 조합을 편집할 수가 없으니, 이 기능을 사용한다면 6.8로 업그레이드가 필수이다.

Win8 지원 작업이 완료되고 나면, 그 다음 버전은 다시 오랜 숙제로 남아 있는 입력 엔진 쪽의 기능 추가에 초점을 맞출 것이다.

  • 한자를 누르면 일반 한자 변환 모드가 되지만 Shift+한자를 누르면 사용자가 정의한 후보 리스트로 변환. 이를 위한 준비 작업은 이미 거의 5.x 버전 시절부터 해 놓았지 싶다. 한자 변환 명령을 4종류로 세분화했음.
  • 입력 패드 쪽으로 다양한 새로운 기능 추가
  • 임의의 글쇠뿐만 아니라 임의의 글쇠 동작까지 인식하는(동시치기, 길게 누르기 등등..!) '고급 입력 스키마' 완성

이게 다 갖춰지면 7.0 번호는 다 따 놓은 당상이리라.

5. 기타 잡설

(1) 세상에는 온갖 기괴한 한글 입력 방식이 존재한다. 그런 것들 중에는 정말 참신하고 의미 있는 발명인 것도 있다. 내부 메커니즘은 두벌식에 속하거나 세벌식에 속하거나 그 중간에 속할 수 있다.
그러나 공 병우 세벌식은 너무 직관적이고 평이하고 당연한 구조여서 딱히 튀는 게 없다. 그렇기 때문에 이건 다른 어떤 입력 방식보다도 더욱 의미 있고 fundamental한 발명이다.

세상에 기계간의 글자판 통일까지 염두에 두고서 사람 손으로도 이렇게 한글을 빠르고 편하게 잘 칠 수 있는 글자판은 공 병우 식 말고는 딱히 생각해 낼 수 없다. 한글교라는 종교가 있다면 이게 진짜 한글교의 핵심 교리 내지 이념이라 하지 않을 수 없다. 한글 입력기를 만든다면 이 방식부터 마스터를 한 뒤 더 복잡하고 편법이 필요한 물건으로 내려가는 게 순서일 것이다. 이것이 내가 예나 지금이나 공 병우 세벌식 덕후요 빠돌이인 이유이다.

(2) 텍스트 에디터라는 건 생각보다 굉장히 만들기 어려운 물건이다.
<날개셋> 편집기도 겉보기로는 시대에 너무 뒤떨어진 전/반각 비트맵 글꼴을 사용하고 있지만...
그 대신 MS Word 같은 다중 블록에다 세로쓰기도 지원하고, 다단계 undo까지 갖추고 있다.

또한 텍스트의 여러 군데가 동시다발적으로 변경되었을 때 필요한 부분만 문단을 다시 정돈하고, 딱 필요한 최소한의 구간만 화면을 업데이트하는 것은 <날개셋> 한글 입력기도 무려 6.x대 버전에 와서야 완벽한 구현체가 나왔을 정도이다. 타이포그래피 시스템을 그 정도로 제약하고 단순화하고도 절대로 호락호락 만들 수 있는 게 아니다.

하물며 텍스트 서식과 복잡한 유니코드 complex script를 지원하고, 장치 독립적인 레이아웃을 구현해야 하는 위지윅 워드 프로세서는 에디팅 엔진의 복잡도와 난해함이 어디까지 치솟을지 나조차도 선뜻 감을 못 잡겠다.

Posted by 사무엘

2013/02/10 19:32 2013/02/10 19:32
Response
No Trackback , 13 Comments
RSS :
http://moogi.new21.org/tc/rss/response/794

국내 마이너 철도 탐방

우리나라 철도에는 경부선, 호남선처럼 하루에도 수십 회 이상의 전철이나 고속철이나 무궁화호급 이상의 일반열차가 다니는 메이저 간선 노선이 있는가 하면, 여객 열차가 정기적으로 다니지 않고 아예 화물 전용인 마이너 지선 철도도 있다. 그리고 철덕이라면 이런 마이너한 철도에도 큰 관심을 갖게 된다.

이 글은 본인이 근래에 철도 영업거리표를 펴서 공부한 마이너 철도 중, 인상적이라고 느낀 노선들을 열거한 것이다. 다들 사철은 아니고 엄연히 코레일 소속이다.

1. 우암선

경부선이 남쪽 종점인 부산을 앞두고 바로 앞의 부산진 역에 진입하기 직전에, 경부선으로부터 분기하여 뻗어 나가는 형태이다. 여객 열차가 다니지 않는 화물 전용 지선임에도 불구하고 선로가 무려 복선이다.
그도 그럴 것이, 바닷가를 따라 감만동의 항구를 지나면서 우리나라를 먹여 살리는 컨테이너들을 실어 나르는 화물 수송의 비중이 워낙 크기 때문이다. 다만, 복선이기만 하고 전철화가 돼 있지는 않다.

중간엔 우암 역과 신선대 역이 있는데, 둘 다 중요한 '보통역' 등급이다.
그리고 그 두 역 사이 구간을 인터넷 지도로 보면 모자이크 내지 풀숲으로 가려진 듯한 구역이 있는데, 거기는 국군 수송 사령부 항만 운영단이다. 그래서 보안상 가려져 있는 것이다.
이 컨셉의 철도가 생긴 건 무려 1950년대이지만, 그때보다 더 외곽으로 이설되어 지금과 동일한 선형의 우암선이 생긴 건 1984년이다.

2. 부산신항선

이런 철도가 있다는 걸 뒤늦게 알게 되어 난 굉장히 놀랐다. 경남 김해에 있는 경전선상의 진례 역에서 시작하여 부산 강서구의 부산신항 역을 잇는 화물 전용 철도이다. 즉, 정체성에 관한 한 앞서 소개한 우암선과 비슷하다. 사실은 진례 역 자체도 원래는 없었는데 부산신항선과의 연계를 위해 신설된 역이다. 길이는 21.3km로, 지선치고는 그렇게 짧은 것도 아니다.

그런데 이 철도는 무려 2010년 말, KTX 2차 구간과 비슷한 시기에 개통한 따끈한 21세기 최신 철도이다. 21세기에 화물 취급용 철도가 새로 생긴 게 있다니! 그리고 현대 철도답게, 여객 취급을 하지 않음에도 불구하고 복선에다 전철화까지 돼 있다. 지상으로 길을 내기 어려운 곳은 과감하게 지하로 터널도 팍팍 뚫었다.

3. 강경선

호남선의 강경 역에서 분기하여 그 이름도 유명한 논산 육군 훈련소 방면으로 가는 짤막한 철도이다. 단, 분기가 호남선의 상행에만 맞춰져 있고 삼각선이 없기 때문에, 서울에서 논산으로 내려온 열차는 강경선에 진입하려면 기관차의 방향(= 열차의 진행 방향)을 바꿔서 분기해야 한다. 불편한 점이다.

강경선의 종점은 연무대 역인데 이것도 사실은 두 버전이 있다. 종점에 덜 가서 먼저 나오는 '구 연무대' 역은 그나마 일반인의 접근이 가능하고 근처에 시멘트 공장이 있어서 거기서도 역을 이용하는 반면, 진짜 선로의 끝에는 '신 연무대' 역은 군용 승강장이어서 일반인이 접근할 수 없다. 선로는 연무 초등학교 근처에 국도 1호선의 코앞에서 딱 끝난다.

참고로 육군 훈련소 입소 대대는 신 연무대 역으로부터 남쪽으로 거의 1km 가까이 떨어져 있다. 입소 대대도 국도 1호선상에 있다.
강경선은 '단선 전철'이다. 복선을 굴릴 만한 수요가 있는 철도일 리는 없지만 어쨌든 2004년에 전철화는 되었다.

4. 삼척선

동해 역에서 분기하여 남쪽의 삼척 쪽으로 가는 지선이다. 강릉에서 삼척으로 내려오는 방향만 있지, 청량리에서 삼척으로 바로 가는 선로는 없다(삼각선 없음).
비록 삼척선은 무궁화호, 새마을호 같은 정기 여객 열차는 없지만, 강릉-삼척 간 전용 관광 열차인 CDC 개조형 '바다 열차'가 다니고는 있다. 또한 삼척선은 바다 경치를 보여주는 관광 이상으로 시멘트를 수송하는 산업선으로서도 묘하게 존재감이 있다.

앞으로 포항 이북으로 영덕과 울진에 동해선이라는 철도가 들어온다면, 그 철도는 응당 삼척선과 연결될 것이고, 그러면 삼척선은 지선이 아니라 엄연히 간선의 일부 구간으로 편입될 것이다. 지금은 단선 비전철이지만 그때쯤이면 삼척선도 복선 전철화가 논의되어야 할 것이고, 그 과정에서 선형이 개량되고 외곽으로 선로가 이설될지도 모른다.

이 외에도,

5. 부산뿐만 아니라 동해남부선의 태화강(구 울산) 역에서도 항구 방면으로 몇 개의 지선 철도가 분기해 나간다. 그런 지선에 있는 대표적인 역은 장생포 역(장생포선)과 울산항 역(울산항선)이 있는데, 주변에는 온통 석유/화학 공장들로 가득하다. 그리고 인터넷 지도를 보면 지역의 위성 사진은 다 모자이크나 흐리게 처리가 되어 있다. 이 역에는 일반인이 함부로 접근할 수 없다.

태화강보다 몇 역 더 아래로 가면 남창이라는 역이 있고, 거기서 온산선이 분기해 나간다. 온산선은 온산 산업 단지 내부에 있으며, 역 주변에는 역시나 무시무시한 화학 공장들이 즐비하다. 역시 고해상도 위성 사진은 인터넷에 공개되어 있지 않다.
용도는 역시 화물 수요 위주이다. 근로자를 위한 통근 열차를 굴리려는 계획이 없지는 않았지만 수지가 안 맞아서 성사되지 않았다고. 차라리 통근 버스나 자가용을 몰고 말지, 철도만으로는 교통이 불편한 건 사실이다.

Posted by 사무엘

2013/02/08 08:33 2013/02/08 08:33
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/793

자동차 운전 관련 이야기

※ 자차를 굴리면서 예전에 겪은 에피소드들을 한데 엮었다. SNS에다가는 꽤 옛날에 올렸음. 본격 사무엘 님 차덕 인증글. ㄲㄲ

1.

동부 간선 도로는 의정부에서 시작하여 중랑천을 따라 서울 지하철 7호선과 비슷한 선형으로 쭉 내려가다가 한양대 근처에서 강변북로와 합류하는 걸로 끝난다.
그러나 사실은 그게 전부가 아니다. 잠시 강변북로를 따라 동쪽으로 가다가 청담 대교로 빠지는 곳부터 다시 동부 간선 도로가 계속된다. 이 길은 잘 알다시피 분당-수서 고속화도로와 직결되어 성남, 분당, 판교 방면으로 간다.

동부 간선 도로(서울)와 분당-수서 고속화도로(경기도 성남)는 딱히 구분 없이 동일한 길인 것 같지만 주변을 잘 관찰해 보면 차이를 발견할 수 있다. 딱 복정 교차로를 지나고부터 행정구역이 서울에서 성남으로 바뀐다. 그리고 서울 구간은 최대 시속이 80km이던 것이 성남부터는 90km로 상향 조정된다.

그뿐만이 아니다. 밤에 몰아 보면 두 도로는 가로등의 색깔도 서로 다름을 알 수 있다! 서울 구간은 불빛이 흰색 계통인 반면, 경기도 구간은 노란(혹은 오렌지색) 나트륨등이다. 그리고 밝기도 서울 구간이 더 밝아서 지역이 바뀌면 도로 주변의 분위기까지 달라지는 느낌이다.

흰색 불빛이 노란색 불빛으로 바뀌는 경험이 웬지 낯익고 익숙한 것 같아서 기억을 더듬어 보니, 잠재의식 속에 서울 지하철 5호선이 떠올랐다. 일반 지하철 터널 내부엔 흰 형광등이 있지만 하저 터널(마포-여의나루, 광나루-천호) 내부엔 노란 나트륨등이 있기 때문이다. 자동차를 운전하면서도 이런 것을 보니 광경이 꽤 낯익고 친숙했다. 운전대를 잡고 있는 동안에도 철도는 언제나 나의 기억을 지배하고 있다!

2.

그건 그렇고 난 올겨울은 차에서 자는 데 재미 붙이며 보냈다. 운전하는 것 자체만큼이나 이것도 좋다.
밖은 영하 10도를 오르내리는 동장군이 기승을 부리지만, 차 안에서 옷 껴 입고 이불 뒤집어쓰고 뒷좌석에 누우면 따스함과 아늑함 그 자체이다. 날씨가 추울수록 더욱 차에서 지내고 싶어진다.

게다가 요즘은 차에서 지내도 땀으로 흠뻑 젖을 걱정, 모기에 물릴 걱정을 안 해도 되니 얼마나 고맙고 좋은지 모른다.
차는 내 이동식 텐트(장막??)이고 아지트이고 내 사무실이기도 하다. 독서와 프로그래밍, 웹서핑도 차에서..

3.

작년 말엔 주유를 한 뒤 한 달 동안 소비한 기름의 양과 차가 달린 거리를 토대로, 내 차의 평균 연비를 한번 계산해 봤다.
일주일에 한두 번 운전하는 꼴이고, 37리터를 주유해서 370km를 좀 덜 갔기 때문에, 어림잡아도 리터 당 거의 9.5~10km 가까이가 나왔다.
이것은 차가 도로 정체 때문에 제대로 못 가고 삽질한 것, 주차장에서 뺑뺑이 친 것, 골목길을 헤매던 것 등 말 그대로 차가 겪었던 모든 상황을 감안한 전체 연비이다.

그런데 경차급이 아닌 크기의 휘발유 차로 전체 연비가 그만치 나왔다고 내가 얘기하자, 회사 사람들은 모두 깜짝 놀랐다.
“너 정말 곱게 몰고 천천히 가고, 정속 주행만 했나 보구나?”라고 내게 물었다.

내가 차를 몰고 가는 목적지는 대부분 교회나 회사이다. 이때는 대부분의 구간을 강변북로와 분당-수서 고속화도로라는 자동차 전용 도로에서 정체 시간대를 최대한 피해서 딱 시속 80~90km을 유지하며 쌩쌩 달린다. 평균 이상의 연비는 이런 데서 다 나왔음이 틀림없다.

물론 나도 누울 자리를 보고 다리 뻗지, 민폐 끼치면서까지 무작정 천천히만 가는 건 아니다. 하지만 최대한 급가속· 급제동을 안 하고 부드럽게 출발하고, 언제든 관성을 이용하려 애쓴다. 어지간해서는 엔진 rpm을 2000을 안 넘기려 한다.
아무튼, 내 운전 습관이 좋았다는 걸 연비를 통해 입증할 수 있어서 기분이 좋다.

4.

그리고 차를 몰면서 피할 수 없는 주차 문제.
하루는 회사에서 퇴근하면서, 구청 직원이 불법 주차 단속을 하는 장면을 처음으로 직접 목격했다.
저녁 7시 무렵이었는데 이 시간대에도 실제로 이렇게 불시에 단속을 하는구나.

유니폼도 안 입고 겉으로는 전혀 티가 안 나는 중년 남자 두 명이 PDA를 두드리고 휴대용 프린터로 과태료 고지서를 즉석에서 인쇄하더니, 차 와이퍼에다 끼워 놓는 것이었다. 그리고 디카로 위반 장면 인증샷을 찍어 갔다.
길가에 세워져 있던 10여 대의 차들이 모조리 다 과태료크리를 맞았다. 승용차는 4만원. 하지만 빨리 내면 20%가 감경되어 3만 2천원.

나도 지하 주차장에 들어가기 귀찮아서 차를 한번 길가에다 한 3시간쯤 댔는데 결국 과태료를 먹은 적이 있었던지라 한편으로 씁쓸한 기분이 들었다. 교차로나 횡단보도, 버스 정류장이야 가중 처벌을 해도 시원찮을 주차 금지 구역이지만, 한적하고 어차피 주변 차량 통행에 지장 안 주는 곳은 좀 봐 주면 안 되나 싶기도 하고.. -_-;;;

그런데 내가 과태료를 먹었던 위치에는 나중에 가 보면 또 다른 차들이 세워져 있고 또 어김없이 단속을 당해 과태료 고지서가 끼워져 있곤 했다. 다른 차들이 쭈욱 세워져 있는 걸 보고는, 나도 되는 줄 알고 세웠다가 싹 다 큰코다치는 일이 반복된다. 한 운전자의 경험이 다른 운전자에게 전수가 안 되니, 이게 국가 세수의 증가에는 도움이 되는구나.

그래도 과태료만으로 끝나는 게 일반 커피라면, 아예 견인까지 당하는 건 TOP이다.. -_- 차량 보관소까지 찾아가는 데 드는 교통비와 시간, 견인비, 보관료 등등.. 마치 집행유예 기간에 또 범죄를 저지르다 걸려서 형량이 늘듯이, 깨지는 돈과 스트레스와 멘탈 붕괴 정도가 왕창 뻥튀기되기 때문이다.

Posted by 사무엘

2013/02/06 08:21 2013/02/06 08:21
,
Response
No Trackback , 3 Comments
RSS :
http://moogi.new21.org/tc/rss/response/792

우리나라의 국토 분단과 관련된 몇 가지 용어에 대해 살펴보자.

1. 우선, 38선과 오늘날의 휴전선은 다르다.
38선은 일제의 패망 이후 미국과 소련이 한반도를 나눠서 지배하기 위해, 지형을 고려하지 않고 지리적인 위도 38도를 기준으로 땅을 수평 분할한 선이다.

사용자 삽입 이미지

그 반면 오늘날 남한과 북한 사이의 실질적인 국경 역할을 하고 있는 휴전선은 6· 25가 휴전/정전으로 끝나면서 나중에 생겼다. 꼬불꼬불한 곡선 형태로 38선 시절에 비해 서울이 북한과 더욱 가까워진 반면, 강원도 쪽 영토는 남한이 훨씬 더 많이 수복하여 속초와 고성이 남한 땅이 되었다.

휴전선은 일명 군사 분계선(MDL)이라고도 불린다. 그리고 미터법이 대세인 우리나라에서 그 길이가 유독 마일이라는 단위로 일컬어지는 흔치 않은 존재이다. (155마일) 왜 그런지는 잘 모르겠다.

2. 흔히 휴전선 하면 이런 모습을 떠올리기 쉽다.

사용자 삽입 이미지

그러나, 최전방 GOP라 불리는 곳에서 근무하는 국군 병사들이 곁에 바싹 붙어서 순찰하고 정비하는 그 철조망은.. 한반도를 딱 반으로 가르는 그 '휴전선'이 아니다. 이것은 마치 민족 대표 33인이 서울에서 벌인 3· 1 만세 운동과, 그 후에 유 관순이 음력 3월 1일에 천안 아우내 장터에서 벌인 만세 운동만큼이나 서로 혼동하기 쉬운 개념이다.

국군 병사들이 지키는 철조망은 휴전선 이남의 '남방 한계선'을 나타내는 철조망이다. 물론 북한 쪽에는 '북방 한계선'이 있다. 이것은 실제 휴전선과는 명목상 2km정도 떨어져 있으나, 그게 칼같이 지켜지는 건 아니어서 2km보다 더 가까이 있는 경우가 많다.

어쨌든 남과 북의 군인이 동일한 단일 철조망을 공유하면서 진짜 코앞에서 총부리를 겨누고 있는 건 아니라는 뜻이다. 그렇게 하기에는 피차 너무 위험하기 때문에 각자 자기 진영의 철조망을 갖고서 서로 거리를 두고 있다.

그리고 휴전선을 포함하여 남북 양쪽의 한계선 사이의 공간이 바로 천연 자연의 보고라고 불리는 그 이름도 유명한 비무장지대(DMZ)이다. 금강초롱과 끈끈이주걱까지 서식한다고 하나, 거기는 지뢰도 엄청 많이 묻혀 있는 위험한 지대이다. -_-

동쪽 강원도 쪽으로 갈수록 DMZ는 첩첩산중 지형이 되지만 서쪽 경기도는 DMZ가 평지이다. 판문점이 있는 공동 경비 구역(JSA)은 DMZ에 속하며, 대성동 마을도 이례적으로 JSA 인근 DMZ 내부에 있는 마을이다. 그리고 DMZ는 마치 뉴욕 한가운데의 UN 본사처럼 UN의 관할에 있는 땅이니, UN 본사를 판문점으로 옮기겠다는 허 경영의 공약(?)은 완전히 터무니없는 발상은 아닌 듯하다. -_-;;

남방 한계선과는 달리, 진짜 오리지널 휴전선(군사 분계선)은 극소수 육로로 월북이나 귀순을 하는 용자 말고는 접근하는 사람이 없다시피하다. 그렇기 때문에 대부분의 구간은 진짜 60여 년 전 휴전 당시에 만들어진 철조망이 시뻘겋게 녹슨 형태로 방치돼 있거나, 아예 애초에 철조망도 없이 낡은 표지판만이 남아서 여기가 군사 분계선임을 나타내고 있다.

사용자 삽입 이미지
요컨대 남북의 군인들이 전방에서 매일 철통같이 순찰하고 정비하는 철조망은 휴전선이 아니라 거기에서 파생된 남방 한계선임을 기억하자. DMZ 내부까지 들어가는 병사는 JSA에서 근무하는 권총 든 헌병이라든가 GOP보다도 안의 GP 순찰병 정도밖에 없다.
이런 위험한 곳에까지 들어가는 병사는 체력 좋고 사상이 확실하게 건전한 사람만을 엄격하게 가려서 뽑는다.

3. 끝으로, 민간인은 남방 한계선까지라도 선뜻 갈 수 있는 게 당연히 아니다. 남방 한계선보다 더 수 km 남쪽으로는 드디어 민통선이라고 불리는 민간인 통제선이 있다. 민통선은 무슨 남방 한계선처럼 전구간이 살벌한 철조망이 둘러져 있는 건 아니지만, 그래도 자동차 도로는 마치 청와대 근처처럼 헌병 초소로 가로막혀 있으며, 아무나 드나들 수 없다.

민통선 내부 구간을 방문하려면 사전에 방문 신청을 하고 군인들로부터 신원 확인을 받는 등 여러 번거로운 절차가 필요하다. 도라산, 제진, 월정리 역은 바로 민통선 내부에 있는 철도역이다. 그래도 여기는 DMZ와는 달리, UN 관할이 아닌 엄연히 대한민국 영토인 건 맞다. 휴전 직후에는 민통선 구간이 남방 한계선으로부터 무려 10~20km가까이나 떨어져 있기도 했으나, 세월이 흐르면서 점점 다시 북쪽으로 많이 올라갔다. 통제가 완화되었다는 뜻이다.

※ 별첨

우리나라에는 현충원 같은 묘지만 있는 게 아니라, 사실은 '적군 묘지'도 있다. 스펀지 같은 데에 소개될 만한 아이템이 아닌가 싶다.

경기도 파주시 적성면 답곡리 산 55에 소재한 적군 묘지에는 6·25 이래로 우리나라에서 죽은 북한군, 중공군, 무장공비, 테러범들이 묻혀 있다. 찾아와 줄 유족이 있을 리 없는데도!
1968년 김 신조 무장공비 침투 사건 때 사살된 공비들, 1987년 대한항공 여객기 폭파범 김 현희의 파트너(자살)까지 다 묻혀 있다고 하니 놀랍기 그지없다. 자세한 건 링크 참고.

제아무리 제네바 협약 같은 게 있다지만, 적군에게까지 이런 예를 갖추는 우리나라는 정말 인심 좋은 나라이다.
하긴, 해방 직후에 일본 민간인들이 권력을 잃고 본토로 쫓겨날 때도, 한국인들이 폭동· 약탈 하나 없이 고이 보내 줘서 걔네들이 무척 감탄했다는 일화도 전해지는데.. (그런데 저 나쁜놈들은 우키시마 호 폭침 사건으로 은혜를 끝까지 원수로 갚았고..)

그런데 더욱 경악할 만한 안타까운 사실이 있다. 저 적군들은 그래도 북한의 입장에서는 나름 자기네 나라로부터 명령을 수행하다가 순직/순국한 호국영령들이다. 미국의 경우, 자국 군인이 죽으면 지구 끝까지 추적해서라도 유해를 찾아 오는 걸로 익히 유명하며, 한국도 나름 그 원칙을 수행하려 노력 중이다.

허나 북한은 한 번도 우리나라에 자국 병사의 유해 인도를 요청하거나 제의한 적이 없다. 특히 각종 지저분한 테러 공작의 경우, 공작원의 시신 인도를 요청했다간 그 행위를 자기가 저질렀음을 공식적으로 인정하는 꼴이 되니 절대로 안 한다.

인권이고 예우고 뭐시고 없는 북한 정권은, 이용 가치가 끝난 병사나 공작원은 자기네 인력이라도 철저히 무시하고 토사구팽하는가 보다. 남과 북이 사이가 좋던 시절에 판문점을 통해 쌀과 소와 관광객이 오고 가긴 했어도, 북한군 유해가 갔다는 소식은 여러분도 지금까지 들어 본 적이 없을 것이다.

1996년의 강릉 잠수함 무장 공비 침투 사건 때 사살된 북한군의 유해는 북한으로 송환된 적이 있다. 그러나 이는 북한이 자기들이 벌인 만행에 대해서 “유감 표명”까지 했을 정도로 예외적인 경우이다.

Posted by 사무엘

2013/02/03 08:18 2013/02/03 08:18
, , ,
Response
No Trackback , 6 Comments
RSS :
http://moogi.new21.org/tc/rss/response/791

« Previous : 1 : ... 148 : 149 : 150 : 151 : 152 : 153 : 154 : 155 : 156 : ... 221 : Next »

블로그 이미지

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

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2024/12   »
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:
3049016
Today:
36
Yesterday:
2142