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

1. disabled 스타일 개론

소프트웨어 GUI에서 대화상자나 메뉴 같은 구성요소를 보면, 상태를 나타내는 속성 중에 논리값으로 enabled 여부라는 게 존재한다.
이게 false여서 disable된 물건은 비록 화면에 보이긴 하지만 흐리게 표시되며 완전히 없는 물건으로 취급된다. 사용자의 키보드나 마우스 조작에 반응을 하지 않으며 선택할 수도 없다.

Windows 운영체제에서는 윈도우에서 WS_DISABLED라는 스타일 비트가 이런 역할을 한다. 기본 스타일에 이 비트가 지정되어 있는 윈도우는 키보드 포커스를 받을 수 없으며, 거기에다 대고 마우스 포인터를 움직여도 통상적인 WM_MOUSEMOVE, WM_?BUTTONDOWN 같은 메시지가 오지 않는다.

즉, availability는 어느 정도 운영체제가 직접 관리를 해 주는 예약된 속성이다.
어떤 윈도우가 enabled인지 여부를 알려면 IsWindowEnabled 함수를 호출하면 된다.
IsWindowEnabled(hWnd)는 !(GetWindowLongPtr(hWnd, GWL_STYLE)&WS_DISABLED)와 동치라고 생각하면 된다.

enabled 여부를 설정하는 함수는 EnableWindow이다. 이때 대상 윈도우는 WM_ENABLE라는 메시지를 받음으로써 자신의 availability 속성이 바뀌었다는 통지를 받는다.
Get과 마찬가지로 SetWindowLongPtr를 통해 스타일을 수동으로 바꿔 줘도 거의 같은 효과를 낼 수 있다.
단, 이 방법은 간단히 전용 함수를 호출하는 것보다 번거로우며, 이렇게 속성이 바뀌면 대상 윈도우는 WM_STYLECHANGED만을 받지 WS_DISABLED 비트에 차이가 있더라도 WM_ENABLE 메시지가 오지는 않는다.

2. 화면에 그리기

대화상자 컨트롤이라면 WM_ENABLE 메시지가 왔을 때 자신을 화면에 다시 그리는 처리를 한다.
가령, 평소에는 COLOR_WINDOWTEXT라는 시스템 색상으로 글자를 찍은 반면, disable된 뒤부터는 COLOR_GRAYTEXT 색상으로 글자를 다시 찍는다.

지금이야 Windows 8 때부터 고전 테마라는 게 사라져서 점차 과거의 유물이 돼 가지만..
옛날에 Windows UI를 보면, 메뉴나 도구모음줄에서 사용할 수 없는 항목은 글자가 단순히 회색이 아니라 흰색 위에 회색이 깔려서 뭔가 음각 엠보싱처럼 그려지곤 했다.

그거 처리를 해서 disable 상태를 화면에 표현하는 건 DrawState라는 함수 호출 한 방이면 바로 된다. 이건 딱 회색 3D 대화상자 스타일이 도입된 Windows 95와 NT4에서 첫 추가된 함수이다. 게다가 텍스트와 비트맵(아이콘) 모두 그렇게 그리는 걸 지원한다.

비트맵의 경우, 마스크 비트맵을 바탕으로 엠보싱을 만들며, 이 테크닉은 지금도 그대로 쓰인다. 그렇기 때문에 요즘은 32비트 비트맵 내부의 알파 채널이 투명색을 대신하는 지경이 되었음에도 불구하고 DrawState 함수로 disable 상태의 엠보싱 아이콘을 그리려면 비트맵에 모노크롬 흑백 배경 마스크 비트맵도 넣어 줘야 한다.
뭐, 궁극적으로는 트루컬러 아이콘이라면 구시대스러운 비트 연산이 아니라, 투명도를 높이고 채도를 낮춰서 그림을 더 엷고 탁하게 만드는 '현대적인' 방식으로 disable 상태를 그려야 하겠지만 말이다.

3. disabled 윈도우의 또 다른 용도

그러면 이런 disabled 속성은 오로지 대화상자 내부의 컨트롤 같은 WS_CHILD급 윈도우에서만 쓰이는가 하면 그렇지 않다. 타 윈도우의 자식이 아니라 top-level이 될 수 있는 WS_POPUP급 윈도우도 WS_DISABLED 속성을 줘서 생성할 수 있다. 이 윈도우는 화면이 달랑 떠 있기만 하지 사용자가 포커스를 줘서 키보드 입력을 할 수가 없게 된다.

사실, 한 프로세스 안에서 child 윈도우는 클릭했다고 해서 딱히 포커스가 자동으로 거기로 옮겨지지는 않는다. 포커스가 가는 건 해당 윈도우가 WM_LBUTTONDOWN이 왔을 때 SetFocus를 자체적으로 호출했기 때문이다.
그러나 소속된 프로세스가 다른 top-level 윈도우의 경우, 클릭하면 일단 그 창으로 WM_ACTIVATE 메시지가 가고 컨텍스트 전환이 발생한다. 이것은 프로그램의 의사와 무관하게 운영체제가 일방적으로 하는 일이었는데, disabled 윈도우는 그걸 막을 수 있다.

물론 disabled 윈도우는 앞서 말했듯이 정상적인 마우스 메시지가 오지 않는데, 그래도 이것도 받는 방법이 있다.
disabled라고 해도 top-level 윈도우에는 기본적으로 마우스 포인터 설정을 위해서 WM_SETCURSOR 메시지 정도는 온다. 이 메시지의 lParam에는 이 윈도우에 원래 오려고 한 메시지가 담겨 있기 때문에 이를 토대로 비록 disable 상태이지만 마우스 동작에 반응을 하도록 프로그래밍이 얼마든지 가능하다. child 윈도우가 아닌 top-level 윈도우이기 때문에 이런 메시지가 온다.

disabled 편법을 쓰지 않고 '클릭해도 반응만 하지 포커스가 바뀌지는 않는 간단한 윈도우'라는 개념은 비교적 늦게 등장했다. Windows 2000부터 WS_EX_NOACTIVATE라는 확장 스타일이 정식으로 도입된 것이다. 이런 윈도우는 ShowWindow에다가도 단순히 SW_SHOW가 아니라 SW_SHOWNOACTIVATE를 줘야 한다.

4. 상태 변경과 관련된 연계 작업들

대화상자에서 컨트롤을 enable/disable시키는 상황은 크게 선천적인 것과 후천적인 것으로 나뉜다. 전자는 WM_INITDIALOG에서 단 한 번 enable 여부가 결정되고 그 뒤에 대화상자가 닫힐 때까지 그 상태가 바뀔 일이 없는 경우를 말한다.
후자는 한 컨트롤의 조작 여부나 값에 따라 다른 컨트롤의 enable 상태가 인터랙티브하게 수시로 바뀌는 경우를 가리킨다. 예를 들어 라디오 버튼이 특정 항목으로 맞춰져 있을 때만 조건부로 사용 가능해지는 하부 조건 체크박스 같은 것. UI 프로그래밍을 해 본 분이라면 이 분류가 수긍이 갈 것이다.

그런데 이렇게 컨트롤들의 상태를 바꾸는 건, 단순히 한 윈도우에 대해 EnableWindow를 호출하는 것 이상으로 이와 결합된 반복 패턴이 여럿 존재한다.

(1) 첫째, 대상 컨트롤의 이전에 있는 label 컨트롤을 같이 enable/disable시키는 경우이다. 대상 컨트롤이 버튼이라면--push, check, radio 모두 포함-- 그 자체가 &로 시작하는 Alt 액셀러레이터 글쇠를 갖는다. 그러나 나머지 edit, list, combo 박스 같은 것들은 자신의 액셀러레이터가 없으며 그 이전의 static 라벨로부터 액셀러레이터를 넘겨받는 형태이다.

따라서 그런 컨트롤이 disable됐다면 자기의 앞의 컨트롤도 같이 disable되는 게 이치에 맞다. 앞의 단순 label은 보통 독자적인 컨트롤 ID가 없이 그냥 IDC_STATIC인 경우도 많으므로 핸들값을 GetWindow(hCtrl, GW_HWNDPREV)로 얻어 오는 수밖에 없다.

(2) 둘째, 대상 컨트롤을 화면에서 감출 때에도 ShowWindow(hCtrl, SW_HIDE)만 할 게 아니라 disable을 시켜 줘야 한다. 왜냐 하면 enable 상태인 컨트롤은 비록 화면에 없더라도 Alt 액셀러레이터에는 반응을 해서 사용자가 여전히 기능 접근이 가능하기 때문이다.
본인은 개인적으로는 이게 바람직한 설계가 아니라고 생각하며, Windows가 왜 그렇게 동작하는지 알지 못한다. 하지만 어쨌든 Windows 95부터 8.1에 이르기까지, 조건부로 컨트롤들을 보였다가 숨겼다가 하는 UI의 경우, 감춰지는 컨트롤은 disable도 시켜 줘야 한다.

(3) 셋째, 지금 키보드 포커스를 받고 있는 컨트롤이 disable되는 경우, 포커스를 자신의 다음 컨트롤로 옮기는 일을 해당 프로그램이 수동으로 해 줘야 한다. 이걸 안 해 주면 그 컨트롤이 disable된 뒤부터 키보드 상태가 꼬여 버린다.
이 단서의 주된 적용 대상은 push-버튼이다. 대표적인 예로는 프로퍼티 페이지에 있는 '적용' 버튼. 이 버튼을 누른 순간 이 버튼은 사용 불가 상태가 되며, 사용자가 다른 설정을 또 건드려 줘야 다시 사용 가능해지니 말이다.

본인의 개인적인 생각은 이것도 역시 운영체제가 자동으로 처리해 줘야 하는 게 아닌가 싶지만, 현실은 시궁창이다. 생각보다 자비심이 없다..;;
대화상자에서 특정 컨트롤에다 포커스를 주는 건 SetFocus를 해서는 안 되며, 대화상자 부모 윈도우에다가 WM_NEXTDLGCTL 메시지를 보내는 방식으로 해야 한다. 그렇게 해야 대화상자의 default 버튼에 굵은 테두리가 그려지는 처리가 올바르게 된다.

그래서 본인은 위의 세 시나리오를 모두 감안하여 대화상자 컨트롤을 enable/disable시키는 함수를 별도로 만들어서 사용하고 있다.
그림을 좀 더 곁들이면 전반적으로 설명하기가 더 편하겠다는 생각이 드는데.. 귀찮아서 생략한다. ㄱ-

Posted by 사무엘

2014년의 끝을 앞두고 <날개셋> 한글 입력기가 새 버전이 나왔다.
그 어느 때보다도 다방면에서 리팩터링, 기능 추가, 버그 수정이 진행되어 프로그램의 완성도가 더욱 향상되었다. 이 글은 지난달에 썼던 GUI 개선 사항에다 또 덧붙여진 주요 변화 사항에 대한 설명이다.

※ 한글 입력 관련

1. 일부 특수글쇠의 '두벌식 종성' 지원 강화

'도깨비불', 그리고 '초· 종성 교환' 특수글쇠가 두벌식 종성까지 감안해서 동작하게 했다.
전자의 경우, 두벌식 종성 글쇠로 '않' 같은 글자를 입력하고 있었다면 '안ㅎ'에서 ㅎ이 초성이 아닌 종성 형태로 분리되어 나온다. 또한 지금까지 이 글쇠는 종성이 단독으로만 있을 때는 동작하지 않았지만, 이제는 종성 단독이더라도 ㄶ 자음끼리 분리가 가능할 때는 동작하게 알고리즘을 개선했다.

후자의 경우를 설명하자면 이렇다. '강'이라는 글자를 '악'이라고 바꿔 주는데, 애초에 글자를 두벌식 종성으로 입력하고 있었다면 이때에도 '악'을 지울 때 ㅇ은 비록 지금은 초성 모양이지만 처음에 종성으로 입력한 것처럼 재현을 해 준다. 이런 변칙적인 상황에 대한 배려를 추가했다. 두벌식은 역시 세벌식보다 근본적으로 처리가 복잡한 방식임을 알 수 있다.

2. 외부 모듈에서 글쇠를 인식하는 알고리즘 개선

사용자에게는 예전 것이나 지금 것이나 큰 차이가 안 느껴지겠지만, 이번 버전에서는 외부 모듈도 글쇠를 인식하는 뼈대 부분을 다시 구현했다.
이 과정에서 외부 모듈에서는 구조적으로 Alt 조합의 인식이 지원되지 않는다는 것을 UI 차원에서 확실하게 표시하게 했다. 외부 모듈에서 단축글쇠 추가/편집 대화상자를 꺼내면 Alt에 해당하는 슬라이더가 사용 불가능 상태가 된다.

또한 우리 프로그램이 가로채지 않는 글쇠는 조합이 있는 중에도 확실하게 가로채지 않게 동작을 개선했다. 예를 들어 space 같은 글쇠는 예전까지는 한글을 조합 중일 때 누르면 우리 프로그램이 언제나 가로채지만 다음 버전부터는 그걸 가로채지 않고도 모든 구현체에서 조합 종료 처리도 매끄럽게 된다.

3. 초-종성 공유 방식의 종성 결합에 대해 가상 낱자와 낱자 치환 규칙 자동 적용

글쇠 수가 매우 적은 휴대전화 입력 방식에서는 어지간한 거센소리나 된소리 계열 자모도 2타 이상의 합성으로 만들곤 한다. 그렇기 때문에 조합 과정에서 ㄴ+ㅇ, ㄱ+ㅆ처럼 현실에서 존재하지 않는 낱자를 특히 종성에다 임시로 풀어서 표현해야 하는 일이 생긴다.

앞부분을 표현하기 위해서는 기존 가상 낱자를 쓰면 되고, 현재 글자의 경계를 넘어가는 뒷부분을 표현하기 위해서는 지난 7.4 버전에서부터 고급 입력기에다 '낱자 치환' 규칙이 추가되어 현재는 이 문제가 깔끔하게 해결되었다.
그러나 ㄴ+ㅇ을 300 같은 가상의 낱자 결합으로 등록하고, 그 300에 대해서 ㄴ과 ㅇ에 대한 표현 규칙을 일일이 등록해 줘야 하는 번거로운 문제가 여전히 남아 있었다.

이번 버전에서는 그 문제까지 싹 해결했다.
'고급 입력기'를 문자 생성기로 사용하고 '초· 종성 공유 낱자 결합' 옵션이 지정된 상태에서
종성 A+B=C에 해당하는 C라는 종성을 조합하는 상태가 됐고, C는 물리적으로 표현 가능한 낱자의 범위를 초과하는 값이고
C에 대해 다른 가상 낱자나 낱자 치환 규칙이 존재하지 않는다면...

이 복잡한 조건을 모두 만족할 경우 <날개셋> 한글 입력기는 자체적으로 C를 종성 A와 다음 글자 초성 B로 풀어서 표현해 준다.
그래서 당장 천지인, 나랏글 같은 예제 입력 방식에서도 300 이후의 수십 개의 종성 결합이 존재하지만 그에 대한 가상 낱자와 낱자 치환 규칙은 이제부터 삭제되었다. 이제 그런 추상적인 낱자는 낱자 결합 규칙에다가 한 번만 지정해 주면 되니, 휴대전화 입력 방식을 구현하기가 더욱 수월해졌다.

4. 수식 변수에 대소문자 구분 추가

예전에도 한번.. <날개셋> 한글 입력기의 글쇠 수식에서 변수의 용도 구분과 공간 부족이 앞으로 문제가 될 수 있다고 언급한 적이 있었다. 이 문제를 간단한 방법으로 깔끔하게, 완전히 해결했다. 변수는 여전히 알파벳 한 글자이긴 한데, 여기에다가 대소문자 구분을 추가함으로써 지원되는 변수의 개수를 종전의 두 배로 늘린 것이다.

그리고 이 프로그램이 버전업되어 입력 스키마 차원에서 여러 변수들이 추가로 제공되더라도, 프로그램은 언제나 오로지 대문자 변수만을 사용한다. 소문자 변수 26개는 사용자가 자신만의 내부 상태를 구현하는 용도로 얼마든지 사용하면 된다. 대소문자이니 형태를 구분하기도 아주 쉽다. 수식을 입력할 일이 있을 때 대소문자 상태만 좀 조심하면 된다.

고유한 내부 상태를 사용하는 복벌식 입력기 플러그 인은 글쇠배열에서 Q 대신 q 변수를 사용해서 수식을 생성하도록 수정되었다.

※ 동기화 관련

5. 타입간에 입력 설정 자료 보존

<날개셋> 한글 입력기의 오랜 숙원이 이뤄졌다.
빠른설정이나 예제 파일을 통해서 '기본 입력 스키마'와 '기본 입력기' 방식으로 어떤 입력 설정이 구축되었는데, 이것을 그대로 '고급 입력 스키마'와 '고급 입력기'에다 가져올 수는 없을까?

입력 항목의 기반 루틴을 넘나들면서 입력 설정을 가져오는 것은 지금 체계에서는 일반적으로 가능하지 않았다. 그래서 편법으로 입력 항목을 XML 방식으로 저장한 뒤, 텍스트 에디터로 object를 수동으로 고쳐서 다시 불러오는 것밖에 방법이 없었다. (어차피 기본이든 고급이든.. 공통 설정은 공통된 XML 형태로 저장을 하기 때문에 가능한 일)

이제는 사용자가 원한다면 이 일을 프로그램이 직접 해 준다.
입력 스키마나 문자 생성기를 변경하고 나면 '초기화' 버튼의 메뉴에 '예전 설정 가져오기'라는 명령이 사용 가능해진다. 그리고 이것을 선택하면 변경 전에 사용하던 입력 스키마/문자 생성기가 갖고 있던 설정을 지금의 입력 스키마/문자 생성기에다가 적용을 하게 된다.

앞으로 고급 입력 스키마와 고급 입력기가 많이 쓰이게 될 텐데 이것은 꼭 필요한 기능으로 자리잡을 듯하다.
당연히, 고급에서 쓰이던 설정을 기본으로 가져오는 것도 가능하다. 기본이 지원하지 않는 기능에 대한 설정치들은 물론 소실된다.

6. 처음에 무조건 지금 default로 지정되어 있는 입력 항목으로 구동

지금까지 외부 모듈의 '고급 시스템 옵션'에는 TSF 지원 확장 하나밖에 옵션이 없었는데, 다음 버전에서는 옵션이 두 개가 더 추가되었다. 하나는 위의 기능인데, 이것은 유용하다면 굉장히 유용한 옵션이다.

Windows 운영체제는 프로그램들의 GUI에 내부적으로 한영 상태를 관리하고 있다. 외부 모듈들은 그 상태를 따라 동작하며, 자신의 상태와 운영체제의 상태 중 어느 하나가 바뀌면 다른 한쪽도 알아서 동기화를 해야 한다. <날개셋> 한글 입력기 역시 외부 모듈 구현체는 그런 규격을 따르며 동작한다.
이런 공통 프로토콜이 스펙에 규정되어 있기 때문에 응용 프로그램은 자신이 지금 무슨 IME를 사용하고 있든지간에 소프트웨어적으로 한/영 상태 정도는 강제로 바꾸는 게 가능하다.

그런데 <날개셋> 한글 입력기 외부 모듈은 사용자가 직접 글자판을 강제로 전환하지 않았다면 자기가 먼저 운영체제의 상태는 절대로 바꾸지 않는.. 일종의 read-only 전략으로 개발되었다. 이것은 MS 한글 IME도 동일하게 따르는 정책이다.

그래서 입력 설정상으로 한글 글자판이 지정돼 있더라도 그 내부 상태가 영문이라면 <날개셋>도 자기 설정을 무시하고 빈 입력 스키마 계열을 기본으로 선택하며, 그런 게 없으면 자동으로 추가도 했다. 이런 동작 방식을 이상하다고 지금까지 사용자들로부터 문의도 엄청 많이 받았다.

하지만 "안 되면 되게 하라" 정신으로.. 이 옵션을 켜 주면 외부 모듈도 편집기처럼 무조건 설정대로 동작하며, 운영체제의 상태를 자신의 상태에다 강제로 맞춰 버린다. 프로그램이 실행되자마자 영문이 아닌 한글 모드에서 시작하는 것도 이제 가능하다. 운영체제의 여타 외국어 IME/글쇠배열을 <날개셋> 한글 입력기와 병행해서 쓰는 것도 좀 더 수월해질 것이다.

7. 응용 프로그램간에 <날개셋> 한글 입력기의 활성 입력 항목 동기화

Windows 8부터는 응용 프로그램간에 사용하는 키보드 로케일/IME와 내부 한영 상태가 모조리 자동 동기화되는 옵션이 추가되었으며 이 방식이 기본으로 지정되어 있다. 하지만 운영체제가 동기화해 주는 것은 한글 아니면 영문이라는 이분법적인 논리값인 반면, <날개셋> 한글 입력기는 3개 이상의 임의의 개수의 입력 항목을 가질 수 있다. '한글'이라고 분류되는 입력 방식 중에 세벌식, 두벌식, 드보락 같은 것은 여전히 응용 프로그램별로 따로 놀며, 동기화되지 않는다.

이 옵션을 켜면 <날개셋> 한글 입력기는 프로그램간에 자기가 사용하는 구체적인 입력 항목의 번호까지 동기화해 준다. 즉, 한 프로그램에서 입력 항목을 다른 걸로 전환하고 다른 프로그램으로 이동하면, 그쪽에서도 그걸로 동기화가 된다.
이 기능은 완전 만능 동기화 기능은 아니고 운영체제의 내부 상태가 맞아야만 동작하는 등 이것저것 단서와 제약이 있긴 하지만(도움말에 명시되어 있음), <날개셋> 한글 입력기를 Windows 8 스타일에 맞춰서 좀 더 매끄럽게 사용하는 데 큰 도움을 줄 것이다.

※ 기타 다른 개선

8. 버그 수정

Windows 8.1에서 권한 부족한 Metro 앱을 사용할 때, 단어 단위 한자 변환이 되지 않던 문제를 해결했다. 지난 7.4 버전에서 추가되었던 사용자 한자어 사전 연계 기능에 문제가 있음을 뒤늦게 발견했다.
권한 부족한 Metro 앱에서 동작이 실패할 때에 대한 처리를 해야 했는데 그걸 하지 않아서 내부적으로 프로그램이 죽었다가 다시 구동되곤 했다. 이런 실행 모드에서는 화면에 로그조차도 제대로 찍히지 않아서 디버깅을 상당히 특수한 방식으로 힘들게 해야 했다.

조금 더 심각한 문제로는 텍스트 조작을 온전하게 할 수 없는 TSF B급 프로그램에서 지금 글자 앞으로 이동하는 부류의 특수글쇠를 사용했을 때 단순히 거절만 되는 게 아니라 프로그램 전체가 무한 루프에 빠지는 문제가 있어서 이를 해결했다. 이 부분의 로직이 크게 바뀐 바로 직전 7.5에만 있던 문제이다.

그리고 편집기에 있는 '키 입력으로 붙여넣기' 기능이 언젠가 space를 제대로 처리하지 못해서 조합 중이던 한글이 덧난 채 붙여지던 문제를 해결했다. 이 역시 아마 이 부분 로직이 크게 바뀌었던 7.4때부터 생긴 버그가 아닌가 싶다.
Windows 7은 콘솔에서 세벌식을 사용할 때 '다다.' 이런 식으로 글자가 덧나는 문제가 있었는데 그런 것과 기술적으로 비슷한 문제이다.

이에 덧붙여 편집기의 '현재 편집 중인 문서의 경로 복사' 기능이 언제부턴가 텍스트를 클립보드에다 제대로 저장하지 않고 있던 문제, 그리고 아무 문자를 입력하지 않을 때에도 겹침 모드에서는 뒷글자를 무조건 하나씩 지우던 사소한 문제도 해결했다. 이것도 아마 7.4~7.5 사이에 슬며시 들어간 버그가 아니었나 싶다.

9. 제어판에서 설정 파일을 초기에 저장하는 위치

날개셋 제어판에서 글쇠배열, 유형, 전체 설정 등.. 뭔가 파일로 설정 데이터를 열 때는 처음엔 예제 데이터가 있는 디렉터리가 시작 위치로 표시된다. 그러다가 파일을 한번 저장하고 나면 마지막으로 저장했던 파일이 있는 디렉터리가 열 때에도 그대로 표시된다.

그런데, 최초로 저장을 할 때는 지금까지 기본 입력 설정 파일이 저장되는 생뚱맞은 이상한 디렉터리가 표시되곤 했다. 이것을 개선하여 이제는 사용자에게 친근한 '내 문서' 디렉터리가 표시되게 바꿨다. 지금까지 이게 상당히 불편한 점이었을 것 같다.
단, 전체 설정(set)은 제공되는 예제 데이터가 없기 때문에 저장뿐만 아니라 '열기'를 처음 할 때도 '내 문서'에서 시작한다.

10. 사용자 정의 후보 관련

7.0에서 첫 도입되었던 사용자 정의 후보 관련 기능에도 엔진이나 GUI에 이것저것 개선이 있었다.
(1) 외부 후보 파일을 불러왔을 때 설명문이 space 이후가 몽땅 잘려서 출력되던 어이없는 버그가 이제야 발견되어 고쳤다. (신고해 주신 분께 감사~)

(2) 그리고 후보 데이터를 추가하는 버튼을 Ctrl을 누르고 클릭하면... 후보 데이터를 한 덩어리로 등록하는 게 아니라 각 글자 단위로 독립적으로 한꺼번에 등록하는 기능을 추가했다. 즉, "☆★○●◎"이라고 입력하고 Ctrl+클릭을 하면 ☆, ★, ○, ●, ◎ 라고 5개의 후보 문자들이 떼어져서 등록되는 것이다.

(3) 이 외에도, 호환용 한글 자모 하나를 사용자 정의 후보의 key값으로 등록해 놓으면, 유니코드 표준 자모로도 그 key에 접근할 수 있게 했다.
초성 자음 중에 ㅉ은 한자 키 특수문자 변환이 전혀 존재하지 않는 유일한 낱자이다. 그리고 모음이나 종성 겹받침도 자리가 비어 있다. 그렇기 때문에 이런 자리에다가 사용자가 자주 사용하는 상용구나 특수문자를 제2 후보에 내장형으로든 외장형으로든 등록해 놓고, "한자 1 + 오름차순 포워딩" 또는 "한자 2 + 내림차순 포워딩"을 쓰면 기존 한자 변환과 내 custom 변환을 손쉽게 같이 쓸 수 있다.
물론, 낱자뿐만 아니라 한자 독음이 없는 한글, 가령 '바'나 '카' 같은 것도 유용하게 활용할 수 있다.

11. 사용자의 건의를 반영한 GUI 개선 추가분

제어판 대화상자가 대화상자 자체의 크기뿐만 아니라 좌우(분야 vs 각 항목)의 내부 크기 조절도 드디어 가능해졌다.
단, 좌우의 폭은 양쪽 모두 지금보다 키우는 것만 가능하지, 줄이는 것은 가능하지 않다.
좌우의 크기 조절이 가능하려면 먼저 대화상자의 폭부터 더 키워야 한다.

많은 사용자들의 요청에 힘입어, 글쇠배열 수식 대화상자도 가로로 크기 조절이 가능해졌다. 생각보다 길고 복잡한 수식을 고안해서 사용하는 분들이 많은 줄을 이제야 알았다. ㅎㅎ
3.0 버전 이래로 거의 10년간 S, P, N, L 등 알아보기 어렵게 돼 있던 인접글쇠 버튼들 역시 저렇게 깔끔하게 바꿨다.

12. 설명문 추가

<날개셋> 한글 입력기에서 XML 저장이 가능한 단위인 글쇠배열, 입력 항목(유형 ist), 전체 입력 설정(set)에 대해서..
자신만의 고유한 설명문을 집어넣는 기능을 추가했다. 그리고 옵션을 줄 경우, 사용자가 제어판에서 해당 파일을 불러왔을 때 그 설명문을 반드시 먼저 사용자에게 표시하게 할 수 있다.

이 입력 방식은 언제 누가 만들었고 버전과 저작권이 어떻게 되며 제작자와 연락은 어떻게 하는지 등의 정보를 설명문에다 간단히 기재해 넣을 수 있다.
또한 복잡한 글쇠배열의 수식 로직 해설을 메모해 두는 용도로도 쓸 수 있으니 여러 모로 유용하다.

Posted by 사무엘

나 같은 컴퓨터쟁이 코더에게는 '통역(사)'라고 하면 컴파일러의 반의어인 인터프리터가 바로 떠오르는 동시에, 니콜 키드먼이 통역사로 연기하는 10년 전쯤의 영화 인터프리터도 생각난다.

성경에서는 단순히 풀이/해석 말고 진짜 외국어 통역을 뜻하는 interpret은 창세기에서 이집트 총리가 된 요셉과 자기 형들 사이의 대화, 그리고 저 멀리 신약 성경에서.. 통역해 주는 사람이 없으면 외국어 방언 쓰지 말고 “그 입 다물라”라고 권면한 것 정도가 등장한다.
아울러 우리 교회의 담임목사님이 통번역 대학원 출신의 스페인어 박사급 전문가이시다. 그래서 왕년에 대학 강단에 서기도 하고 국가적으로 꽤나 높으신 분들 행사의 통역에 동원된 경력이 있으며, 관련 국가고시 문제 출제에도 참여한 적이 있으시다.

통역은.. 문자 언어를 비교적 충분한 시간 동안 고퀄리티로 옮기는 '번역'과는 다소 다른 개념이다. 오프라인 렌더링과 실시간 렌더링의 차이랄까..
그런데 통역도 방식이 크게 두 갈래로 나뉜다. 화자 먼저 한 문장을 말하고서 쉬는 동안 통역이 말하는 '순차통역'은 그나마 양반이다. 그 반면, 듣는 사람은 헤드폰을 끼고 있고 화자는 쉬지 않고 계속 말하는 걸 통역사가 딴 장소에서 부랴부랴 옮기는 '동시통역'이 있다.

당연히 동시통역이 훨씬 더 정신없고 어려우며 보수가 더 높다.
게다가 순차인 경우, 화자는 바로 옆에 있는 통역사를 의식해서 더 또박또박 천천히 말을 하는 편이며, 통역사 역시 잘 못 알아들으면 화자에게 “뭐라고요?” 이럴 기회라도 있는 반면..
동시통역의 경우 화자와 통역사는 격리되어 있으며, 화자는 통역사의 존재를 전혀 의식하지 않고 진짜 자비심 없이 자기 할 말만을 쏟아내기 때문이다.

영화 인터프리터에 나오는 것처럼 UN 회의를 동시통역하는 정도이면.. 난이도와 중요도가 정말 톱 중의 톱이며, 그야말로 최고의 정예 통역사가 최고의 보수를 받으며 일한다고 봐야 할 것이다. 물론 그 대신, 오역 때문에 무슨 국가적으로 중대한 일이 틀어지기라도 했다가는 사고를 낸 통역사는 교도소에 갈 각오도 해야 할 것이고.
단순 관광 가이드 통역 수준이 아니라, 각종 전문 분야 설교나 연설의 동시통역을 하려면 양 외국어 자체만 기똥차게 잘한다고 되는 게 아니며, 통역 이론과 방법론에 대한 추가적인 학습이 필요하다고 한다.

우리나라는 군대도 미군과의 의존성이 높다는 특성상 어학병이라는 보직이 존재한다. 물론, 날고 기는 영어 귀재들에 비해 TO는 바늘 구멍 수준이지만 말이다. 카투사야 어느 정도 이상의 공인 영어 점수만 받고 나면 그 뒤부터는 추첨이지만, 어학병이 되려면 정말로 토익 정도는 만점에 가깝게 나와야 하며, 겨우 본토에서 머리로만 주입한 수준을 초월하는 영어 실력이 필요하다. 그래도 통역을 해도 순차이지, 일개 군인이 설마 동시통역까지 맡을 일은 없을 것이다.

얼마 전에 박 근혜 대통령이 미국 의회에서 영어로 연설을 할 때 방송사들은 한국인이 구사한 영어를 동시통역해서 연설 내용을 생방송으로 내보냈었다.
아, 그나저나 먼 옛날엔 국내 방송사에서 아침 7시 뉴스를 하기 전에 '세계 뉴스'라고 해서 CNN, NHK 등 주요 외신의 하이라이트 한 토막을 자막 내지 더빙으로 내보낸 적이 있었다. 생방송은 아닐 테니 동시통역까지는 아니었을 테고. 인터넷으로 어중이떠중이 다 세계 뉴스에 접근이 가능해진 오늘날 다시 생각해 보면 정말 아련한 추억이다.

어쨌거나 외국어 잘하는 사람이 참 부럽다.

Posted by 사무엘

1. 오목은 선수(흑돌)가 굉장히 유리한 반면, 윷놀이는 잡히는 것 때문에 선수가 그다지 유리하지 않다는 게 굉장히 흥미로운 차이점이다.
특히 보드에 처음 놓이는 말이 기존 말을 잡는 거는.. FPS로 치면 개념적으로 spawn으로 인한 텔레프래깅과 동일하다.

2. 윷놀이는 자동차가 발명되기 한참 전에 고안된 게임이겠지만 말의 주행 패턴이 자동차 수동변속기와 굉장히 닮은 것 같다.
도-개-걸-윷-모는 1~5단, 빽도는 후진 1단

3. '지옥'은 윷놀이의 랜덤함과 사행성을 더욱 배가시켜 놓은 요소임이 틀림없다.

4. 옛날에.. 한 1992~94년 사이이던가..? 어떤 은행원 아저씨가 윈도 3.1용으로 윷놀이 게임을 만든 게 있어서 했던 기억이 있다. 아마추어 프로그래머일 텐데 파일 구성상으로는 비주얼 베이직은 아니고.. 나름 쌩 Windows API를 써서 C언어로 만들었지 싶다.
나름 자기 아들이 윷을 던지는 동영상까지 들어있었는데.. 그 시절에 그런 개발 환경과 동영상 촬영 장비를 생각하자면 보통 집안은 아니었던 것 같다.

5. 프로그래머의 관점에서 생각해 보자면, 윷놀이 컴터 AI를 만드는 거 생각보다 재미있을 듯하다. 일단 윷말 놓는 방식이 가짓수가 굉장히 많으며, 굽는 것, 다음에 잡힐 확률, 그리고 각 말이 빽도가 걸렸을 때 후진하는 방향 state 같은 것들도 은근히 처리하기 까다롭기 때문이다.
5m + 4n + 3 = 10 or 12 이런 거 어쩌면 선형계획법으로 모델링할 수 있을지도 모른다.
다변수 정수 연립방정식 푸는 건 지뢰찾기를 풀 때도 써먹곤 했는데 어쩌면 그것과 비슷한 논리인지도..;;

* 펜티엄 4 + 윈도 XP 초 구닥다리 똥컴에서는.. 페이스북처럼 자바스크립트가 왕창 돌아가는 페이지는 IE8로는 먹통 수준으로 너무 느려서 도저히 열람을 할 수가 없고..
역시 크롬이 정답이다.

Posted by 사무엘

1.
비교적 최근에 알게 된 건데..
C/C++에서 default문은 굳이 case의 맨 마지막에 있지 않아도 된다. =_=;;;
그래서 case 1: .. default: ... case 2: 이런 식으로 라벨들이 따라오고 일부 항의 끝에 break까지 생략되어 있다면 생각보다 꽤 기괴한 로직을 구현할 수도 있다.

뭔가 발상의 전환이 느껴진다. 어떻게 활용 가능한지는 더 생각을 해 봐야겠다.
물론 파스칼의 case else문은 그렇지 않으며, 반드시 맨 마지막에 와야 한다.

2.
컴퓨터에서 부동소수점은 연산을 하는 게 까다로워서 하드웨어적인 도움을 진작부터 받아 왔다. 하지만 연산뿐만 아니라 이미 있는 수를 10진법 형태의 문자열로 나타내거나 문자열로부터 역변환하는 것도 생각보다 몹시 어렵다. 에니악 같은 초창기 컴퓨터가 괜히 굉장한 비효율을 감수하고라도 10진법 기반으로 설계되었던 게 아닌가 싶다.

이와 관련된 정보는 printing float numbers 같은 키워드로 구글링을 하면 얻을 수 있다.
이 작업은 어떤 f * 2^e에 대해서 f' * 10^e' <= f * 2^e < (f'+1) * 10^e'가 성립하는 최소의 f'/e'를 찾는 것인데, 결국 컴퓨터 프로세서가 기본 단위로 처리 가능한 범위를 넘는 big number 연산까지 필요할 정도라고 한다.

2진법 부동소수점은 1/2^n이 아닌 사실상 거의 모든 소수들이 순환소수로 표현되어 뒷부분이 잘린다. 0.1, 0.3 이런 소수도 컴퓨터에서 표현되는 형태는 순환소수라는 뜻이다. 순환소수를 화면에 출력할 때는 그래도 10진법 유한소수인 것처럼 표시하는 것이니 컴퓨터에서 부동소수점은 본질적으로 100% 정확한 정밀도가 보장되지 않는 셈이다.

3.
Visual C++ 201x는 200x에 비해서 매우 강력해진 인텔리센스, 새로 디자인된 IDE, C++1x 언어 기능 같은 게 부각되는 편이다. 하지만 그것 말고도 IDE가 매우 편리해진 면모가 최소한 둘 있는데...
이제 IDE의 버전이 올라갈 때마다 프로젝트 파일을 매번 강제로 업그레이드 하지 않아도 되고, 그리고 컴파일러 툴킷을 직접 고를 수 있게 된 점이다.

이로써 IDE가 개별 프로젝트나 빌드 툴과는 좀 더 독립한 구도가 됐다.
이것은 딱히 새로운 기능 추가가 아님에도 불구하고 옛날에 도스 시절에 멀티부팅 기능이 추가된 것만큼이나 매우 편리해진 조치이다. (autoexec.bat / config.sys에 일종의 조건부 실행 로직을 추가하여, 부팅 configuration을 직접 고를 수 있는 것)

4.
본인은 예전에 precompiled header에 대해서 글을 쓴 적이 있다. 그때에도 언급했지만, 본인은 성질이 좀 급한 관계로 PCH 없이 소스 코드가 엄청난 분량의 인클루드 반복 때문에 컴파일 속도가 굼뜨는 걸 못 참는다.
그런데, 프로젝트 전체를 분석하면서 중복 인클루드로 판단되는 파일들을 자동으로 감지해 주는 기능이 있으면 좋지 않을까? 그것들을 stdafx.h로 대체하고 그 파일에다가 인클루드들을 몰아 넣는 것이다. 물론, 빈번하게 인클루드되긴 하지만 수정도 빈번하게 되는 편이기 때문에 pch에다 넣어서는 안 되는 것 판단은 사람이 하면 된다.

이건 마치 데이터베이스에서 테이블과 쿼리들을 분석하면서 자주 쓰이는 테이블 내지 애트리뷰트는 인덱스를 넣는 최적화 기능과 비슷한 구석이 있는 것 같다.

5.
자동차의 특성이 컴퓨터 소프트웨어의 특성과 매우 비슷하다고 여겨지는 점이 몇 가지 있다.

• 내릴 때 실내등이나 각종 라이트가 완전히 꺼졌는지 확인하고, 블랙박스는 장시간 주차시 자체 전원 차단 기능이 켜져 있는지 확인해야 한다. → 메모리 leak 예방과 개념적으로 일치한다.
• 급발진: 아주 희귀한 상황에서 갑자기 발생하는 치명적인 버그에 해당한다.
  
• 자동 vs 수동 변속기: 옛날이라면 컴파일러가 자동 생성한 코드 vs 수제 어셈블리 코드.. 정도와 대응하고, 지금이라면 managed vs native 코드와 대응하는 듯하다. 요즘은 자동 변속기도 어지간한 수동 조작에 뒤쳐지지 않을 정도로 효율이 굉장히 좋아졌으니 말이다.

6.
세상에는 분야를 불문하고 여러 단체가 공동으로 뭔가 통합 작품이나 프로토콜을 만드는 경우가 있다. 따지고 보면 킹 제임스 성경도 성공회와 청교도가 연합해서 작업한 그런 통합 작품이다.
하지만 그런 통합 작품이 실질적인 통합을 이루지 못하고 그냥 기여를 가장 많이 한 단체의 전유물로 전락해 버리는 경우도 있다. 그런 예를 몇 가지 들어 보자면 다음과 같다.

• HFT 통합 글꼴: 지금은 아래아한글밖에 안 쓰는 완전 옛날 유물이 됐다.
• 공동번역 성서: 에큐메니컬 성경이라지만 현실은 역시 천주교 전용 성경일 뿐이다.
• 타이젠 OS: 당초 취지와는 달리, 컨소시엄을 구성하던 협력사들은 다 빠져나가고, 사실상 삼성 전자밖에 관심이 없는 모바일 OS가 됐다.

삼성은 예전에도 아래아한글과 MS 워드가 뻔히 있음에도 불구하고 수익성과는 별개로 훈민정음을 오랫동안 밀었다.
그런 것처럼 모바일 OS 하나 정도는 우리가 자체 기술을 갖고 있어야 한다는 차원에서 타이젠을 꾸준히 미는 듯하다. 안드로이드와 iOS의 텃새에도 불구하고 정말 막대한 자금을 투자하여 타이젠 앱 프로그래머를 육성하는 중이다.

7.
비주얼 C++이 컴파일러, IDE, 디버거 등 모든 차원에서 64비트를 완벽하게 자체 지원하기 시작한 건 2005부터이다.
그런데 나는 그 시절부터 굉장히 궁금했던 게...
devenv IDE는 예나 지금이나 32비트 프로그램임에도 불구하고 어떻게 64비트 바이너리를 아무 제약 없이 바로 디버깅 하고 메모리 내부를 잘도 들여다볼 수 있느냐 하는 것이었다.

운영체제 차원에서 64비트와 32비트가 서로 얼마나 격리되어 있는지는 이 바닥에 짬밥깨나 있는 프로그래머라면 누구나 잘 알 테고. 그러니 결론은 하나. 별도의 64비트 EXE를 띄워서 IPC(프로세스 간 통신)를 하지 않고서는 이 정도의 자연스러운 연계는 절대 가능하지 않다는 것이었다.

확인해 보니 이 예상이 맞는 듯하다. 32비트 프로그램을 디버깅 할 때는 안 그러는데 64비트 프로그램을 디버깅 할 때는 msvsmon이라는 일종의 64비트짜리 원격 디버그 호스트 프로그램이 같이 뜬다. 그리고 디버깅이 끝나면 얘도 실행이 종료된다. EXE 크기가 수MB에 달하는 결코 작지 않은 프로그램이긴 한데, 얘가 뭔가 하는 일이 많은 것 같다.

8.
끝으로.. 시간 복잡도, 공간 복잡도라고 하면 전산학에서나 다루는 무슨 뜬구름 잡는 개념처럼 들리기 쉬운데, 현실에서도 의외로 간단한 예가 있다.

먼저, 자전거를 잠그는 자물쇠로는 열쇠 방식이 있고 숫자 다이얼 방식이 있다.
전자는 열쇠만 있으면 금방 자물쇠를 딸 수 있다. 후자는 번거로운 열쇠를 챙기지 않아도 되지만 원하는 숫자까지 다이얼을 맞추고, 다시 잠김 모드로 옮기는 시간이 오래 걸린다.

나는 프로그래머로서 이걸 경험할 때마다 시간/공간의 tradeoff라는 생각이 들곤 한다. 열쇠 자물쇠는 열쇠라는 공간이 필요하고 열쇠를 분실하지 않게 주머니 관리를 잘 해야 하지만, 열고 잠그는 건 배열 테이블을 참조하듯이 O(1) 시간 만에 즉시 끝낸다.
숫자 자물쇠는 열쇠가 없어도 되어 심리적으로 편하지만, 다이얼을 맞추기 위해 마치 매번 탐색을 하고 연결 리스트의 노드를 찾듯이 O(n) 시간 작업을 매번 해야 하기 때문이다.

옛날에 브라운관 모니터가 어느 수준 이상의 대형화가 도저히 불가능하고 LCD 모니터에 밀려 도태한 주 이유가..
바로 화면 크기 n에 따른 공간 복잡도가 O(n^3)이나 되었기 때문이다. 무게나 가격까지 그 정도로 급격하게 증가했고.
색감이 좋다고는 하지만, 그래도 전자총을 뒤에서 화면 크기만큼이나 거리를 두고 쏴 줘야 하니, 화면의 크기가 커질수록 어마어마한 양의 공간을 잡아먹는 것을 감당할 수가 없었다.

그리고 지구본(지구의)도 생각난다.
알 만한 분들은 이미 다 아시겠지만, 메르카토르 도법 평면 지도에는 아프리카 대륙은 실제보다 굉장히 작게 나오고, 그린란드 내지 러시아는 말도 안 되게 면적이 부풀려져 있다.

왜곡 없이 둥근 지구 위에서 세계 각국의 위치에 대한 실질적인 공간 감각을 키우는 데는 지구본 만한 게 없다. 그리고 지구본이 비치된 책상 앞에서 누가 머리 싸매고 있으면 왠지 간지 나고 멋있어 보이기도 하나..

지구본 얘도 크기에 따른 공간 복잡도가 O(n^3)인 부피를 차지하는 물건이고, 안 쓸 때 딱히 접거나 분해해서 부피를 축소시키는 방법도 여의치 않다 보니 실용성이 떨어진다.
현실적으로는 입체 효과까지 지원하는 구글 어스 같은 지도 어플이 대안이지만.. 그래도 이런 건 실물이 아쉽기도 하다. (어플은 여러 사람이 한 지구의 여러 지점을 한데 공유하면서 서로 비교할 수 없음)

다시 프로그래밍 얘기로 돌아오자면, 현실에서는 단순무식한 알고리즘이 O(n^2) 정도의 복잡도가 나오는 게 약간 머리를 굴림으로써 O(n log n) 정도로 최적화되는 경우가 많은 듯하다. 정렬이 대표적인 예이고, 그 외에도 빠른 푸리에 변환이라든가 최장 증가 수열 찾기 문제도 이런 범주에 속한다.

그리고 단순무식하게 접근했을 때 지수함수 복잡도가 되는 게, 다이나믹 프로그래밍으로 중간 계산 결과를 저장함으로써 메모리 복잡도 O(n^2), 시간 복잡도 O(n^2) 내지 O(n^3)이 되는 경우가 많다.
아예 O(n)으로 간단하게 줄어드는 건 피보나치 수열이나 팩토리얼을 구하는 것처럼 문제 자체가 극도로 단순한 경우밖에 없을 것이다.

Posted by 사무엘

오늘은 원래는 있었는데 국토 분단으로 인해 기능이 상실되고, 게다가 6· 25 때 흔적도 없이 사라져서 터만 남은 비운의 철도역을 심층 탐방해 보겠다. 오오오~ 흥미진진 두근두근~!
얘들은 황량한 부지만 달랑 있고 건물 실체가 없는 관계로, 주소도 도로명 주소 같은 게 없이 여전히 지번 기반이다. 이름도 '역'이 아니라 그냥 '역지'이다. 황룡사가 아니라 황룡사지인 것처럼 말이다.

1. 경의선 장단 역

장단 역은 원래는 1906년 4월에 경의선이 개통했던 당시부터 영업을 시작한 창립 멤버이다. 그때는 같은 창립 멤버인 문산 역의 바로 다음이 장단이었다. 지금 문산 이북에 있는 운천, 임진강, 도라산 같은 역은 먼 훗날 이뤄진 남북 경의선 철도 연결 작업의 산물이다. (더구나 운천은 그저 임시승강장일 뿐이고.)

장단 역이 유명해진 건 잘 알다시피 인근 선로에 반세기 동안 버려져 있던 녹슨 증기 기관차 때문이다.
1950년 12월 31일, 고 한 준기 기관사는 평양 방면으로 화물 열차를 운전하고 있었는데, 그 때는 중공군의 인해 전술로 인해 국군과 UN군은 후퇴 중이었다(서울을 북한군에게 도로 빼앗긴 1· 4 후퇴의 불과 닷새 전이었다). 그래서 이 열차는 더는 북상할 수가 없게 되었으며, 장단 역에는 전차대 같은 게 없어서 진행 중인 열차의 방향을 남쪽으로 돌릴 수도 없었다.

결국 이 열차는 북한군에게 노획되는 걸 방지하기 위해 차라리 동작 불능 상태로 파괴 대상이 되었다. 이에 명령을 받은 미군 병사들은 소총을 난사하여 기관차를 벌집으로 만들고 또 탈선까지 시켰다. 한씨는 다른 하행 열차를 갈아타고 후퇴했다. 김 재현 기관사 때처럼 열차가 무슨 북한군의 공격을 받아서 벌집이 된 건 아니다.

그렇게 긴급 상황에서 버려진 증기 기관차 화통은 2005년에 임진각으로 옮겨졌고, 녹을 벗겨내는 대공사를 거쳐서 2009년부터 임진각에 전시되고 있다. 하지만 그 난리 중에 장단 역 자체는 완전히 파괴되어 흔적도 없이 사라졌다.
위치 자체도 38선, 지금의 군사 분계선과도 너무 가까운지라 복원이나 관광지 조성 같은 건 요원하다. 민통선도 아닌 완전 비무장지대에 있으니 말이다.

장단역지의 공식 주소는 “경기도 파주시 장단면 동장리 198”이다. 지도 사이트에서 주소를 입력하면 위치가 정확하게 나온다. 도라산리도 아니고 동장리이기 때문에 도라산 역에서 1km가 넘게 북쪽으로 멀찌기 떨어져 있고, 군사 분계선이 몇백 m 코앞이다.
이 일대의 항공 사진을 보면 4차선 도로의 옆으로 경의선 단선 철길이 지나고, 주변은 온통 숲이다.
예전에 기관차가 임진각으로 옮겨지기 전에 시뻘겋게 녹슨 채 내팽개쳐져 있던 시절의 사진을 보면.. 여기 어딘가의 경의선 선로 옆에 나란히 있었던 것 같다.

남북 분단 전의 리즈 시절엔 장단 역은 제법 컸다고 그러는데 지금 저 지형을 봐서는 도저히 믿어지지 않는다. 또한 '죽음의 다리'라고 불리는 교량이 장단 역 남단 300m쯤에 지금도 있다고 하는데 항공 사진으로는 짐작을 못 하겠다.

2. 경원선 철원 역 외

철원은 남북 분단 이전에는 지금의 춘천에 맞먹는 큰 도시였으며, 철원 역도 무려 1912년에 개통한 경원선의 창립 멤버역으로서 대단히 중요한 교통 요지였다. 게다가 금강산선의 분기역이기까지 했으니 역의 덩치도 당시의 경성 역만큼이나 컸다고 한다.
철원 역 일대는 분단 직후에는 북한 치하에 있다가 6· 25가 발발하면서 건물과 시설이 모조리 초토화되었다. 그러나 이 지역은 대한민국이 수복한 후, 다행히 터와 최소한의 흔적은 건졌다. 위치도 DMZ는 아닌 단순 민통선 내부인지라 개인이 그럭저럭 찾아가서 답사하는 것도 가능하다.

안보 패키지 관광을 이용해서 이 지역을 방문하면, 철원 역은 아무래도 건물 실체가 짝퉁 형태로라도 남아 있는 월정리 역보다는 비중 있게 다뤄지지 않는다. 관광버스가 정차하지도 않고 가이드가 그냥 차창 밖으로 “여기가 철원 역 부지입니다”라고 설명하는 걸로 넘어간다.

그렇기 때문에 여기를 직접 땅밟기를 하고 살펴보고 싶으면 평일에 개인이 자가용을 끌고 민통선 안으로 들어가 봐야 한다. 물론 사전에 군부대에 연락해서 허가를 받고서 말이다. 다른 방문자의 경험담을 보자면, 원래부터 그 지대의 출입증을 갖고 있는 지역 주민으로부터 초대를 받고 같이 들어가는 게 아닌 경우(외지인의 단독 방문), 감시하는 군인이 동승· 동행을 한다고 그런다.

"사람이 가득하던 도시가 어찌 외로이 앉았는가! ..." (애 1:1)
성경의 이 애가(lamentation) 구절이 철원역지를 보면 저절로 읊어질 것 같다.
경원선은 경의선과는 달리 남북이 연결되지 않았다. 그러니 지도를 펴 놓고 옛 철길 궤적을 한번 추적해 보도록 하자.

이 그림 한 장으로 모든 게 설명된다.
좌측 최하단의 '묘장로' 인근에 있는 붉은 점은 바로 지금의 경원선 종점인 백마고지 역이다.
그리고 근처의 오른쪽 위에 있는 점은 옛 철원 역으로, 지금은 민통선 안에 빈 터만 남아 있다.
더 위로 들판과 산지의 경계에 있는 붉은 점은 월정리 역이다.

지도에 표시되어 있는 남한 쪽의 논밭 들판들은 거의 다 민통선 내부라고 생각하면 정확하다.
단, 월정리 역은 원래는 민통선 지대를 넘어 더 북쪽의 DMZ 내부에까지 걸쳐 있었으나 좀 덜 위험한 곳으로 살짝 옮겨져서 복원된 것이다.
그리고 철원 역도 지금은 국도 3호선에 딱 붙은 지점에 복원되었지만 원래 있던 곳은 그보다는 좀 더 떨어져 있었다.

그리고 북한으로 넘어가서 홀로 덩그러니 남아 있는 붉은 점이 바로 가곡 역으로 추정되는 지점이다. 북한의 월정리 역에 해당하는 버려진 역이다! 선로는 없고 역사 흔적만 있다.
다음으로 '평강군'에 걸쳐 있는 점은 평강 역으로, 오늘날 경원선의 북한 구간은 여기서부터 시작된다. 북한에서는 자기 구간을 강원선이라고 부른다.

우리나라 쪽에 있는 푸른 점은 철원에서 금강산선의 궤적이 남아 있는 곳이다. 각각 한다리, 대위교, 그리고 전선 휴게소 인근에 있는 교각이다. 위의 자료가 정확하다면, 철원 역에서 분기한 금강산선은 남쪽으로 좀 내려간 뒤에 동쪽을 향해 간다는 걸 알 수 있다.

끝으로, 군사 분계선 인근의 분홍색 점은 제2 땅굴 입구가 있는 지점인데 참고로 첨가해 넣었다.

위의 점들이 다 철길로 연결되는 날이 온다면 얼마나 아름답고 행복할까?
본인은 경주 출신임에도 불구하고 황룡사지보다도 철원역지, 장단역지 같은 이름을 들었을 때 더욱 가슴이 뭉클하고 뭔가 울컥함을 느낀다. 분단된 철도의 아픔은 곧 나의 아픔이기에.

미국의 로스엔젤레스는 잘 알다시피 '천사의 도시'라는 뜻이고, 이스라엘의 수도 예루살렘은 '평화의 도시'라는 뜻이다. 그런데 평화와는 별 관계가 없는 짓을 하는 북한 같은 또라이 반국가단체가 '평강, 평양' 등 '평'자가 들어간 지명을 갖고 있다는 건 참 역설적인 것 같다. 북한은 자기들의 악한 체제의 유지를 위해 주민들에게 절대로 자유를 주지 않으며 눈과 귀를 강제로 틀어막고 지내고 있음을 우리는 잊지 말아야겠다.

한편, 경의· 경원 라인과는 달리, 동해중부선 쪽은 일제가 한창 공사를 하다가 패망해 버렸다. 그렇기 때문에 그쪽에는 영업을 하다가 우여곡절을 겪고 파괴되고 없어진 역 같은 건 없다.

Posted by 사무엘

오랜만에 또 <날개셋> 한글 입력기의 다음 버전 개발 근황을 올릴 때가 됐으니 관련 소식을 전하도록 하겠다.
이제 <날개셋> 한글 입력기는 7.x 후반이나 8.0에서 진짜로 고정판, 최종 완성판에 도달하는 걸 목표로 하고 있다. 고지가 얼마 안 남았다. 그 뒤로는 그냥 그때 그때 생각 난 기능이나 버그 수정 정도로만 유지 보수가 될 것이다. 그리고 신규 기능 개발보다는 이미 만들어 놓은 기능에 대한 홍보와 문서화, 포팅에 더 비중을 둘 것이다.

지난 7.4와 7.5는 한글 입력 엔진 쪽을 갈아엎느라 GUI 부분을 살펴볼 여유가 상대적으로 부족했다. 그래서 7.5를 공개하자마자 지체없이 다음과 같은 작업이 진행되었다.

1. 다국어 UI 지원 체계 개편

<날개셋> 한글 입력기가 허접하게나마 다국어 GUI를 지원한 건 2.32 버전부터였다. 그러나 영어 한 언어로 한정이었고 편집기 프로그램만 임시방편으로 지원하는 것이었다.
그러다가 2007년에 나온 4.55 버전부터 자체적인 다국어 UI 컬렉션 파일과 함께 임의의 언어를 지원하는 길이 열렸다. 물론 구조만 그렇게 만들어 놨지, 지금까지 실질적으로 제공된 외국어는 영어 하나뿐이긴 했지만 말이다.

하지만 그 구조는 완전하지 못했다. 고유 포맷을 사용하는 다국어 UI 컬렉션 파일은 자작한 툴을 이용해서 비교적 복잡한 과정을 거쳐야만 생성할 수 있어서 비효율적이었다. 그리고 그 파일에 모든 외국어 UI가 들어가는 건 아니었으며, 기존 Help, Dic 같은 데이터 디렉터리에 다국어 구분이 필요한 파일과 그렇지 않은 파일이 섞여 있었다.

프로그램 디렉터리 한 곳에다가 압축만 쭉 풀어 줌으로써 중국어나 일본어 같은 새로운 언어를 손쉽게 추가할 수 있게 하는 게 내 목표였는데.. 실질적으로는 그렇게 되지 못했다.
그래서 다 바꿨다.

일단 언어 식별을 kor, eng 같은 자체적인 명칭으로 하는 게 아니라, 1033 (영어 미국), 1042 (대한민국) 같은 운영체제가 사용하는 숫자를 그대로 따르도록 하고, 'lang/숫자' 아래에.. Help나 Dic 같은 디렉터리를 다시 둬서 언어 구분이 필요한 파일들이 들어가게 했다. 언어 구분을 파일 이름으로 하는 게 아니라 한 디렉터리 아래에서 한꺼번에 되게 한 것이다.

그리고 고유 포맷을 사용하는 파일을 버리고 각 모듈별로(ngs3, ngsedit 등) 역시나 전통적인 리소스 DLL을 사용하게 했다. 리소스 DLL은 비주얼 C++ 같은 툴에서나 손쉽게 고치고 생성할 수 있다.
이걸 뜯어고치는 과정에서 프로그램 내부의 여러 부분을 리팩터링하고 잠재적 버그들을 고쳤다. 특히 프로그램의 주 인스턴스 핸들과 리소스 DLL 핸들 사이의 구분이 더욱 엄밀하게 바뀌었다. 예전에는 별도의 파일을 썼으니 그 정도 구분이 필요하지 않았기 때문이다.

단적인 예로, 대화상자를 생성할 때 별 생각 없이 넘겨 주던 인스턴스 핸들은 리소스 DLL이 아니라 자기 프로그램의 인스턴스를 넘겨 줘야 한다. 안 그러면 자기 프로그램이 만든 내부 custom control (CS_GLOBALCLASS가 지정되지 않은 것)조차도 생성되지 않는 참사가 벌어진다.

언어 구분이 없는 리소스이기 때문에 FindResource만 쓰면 되는 부분과, FindResourceEx로 반드시 구분을 해야 하는 곳도 용례를 다시 살펴봤다. FindResource는 어찌 된 일인지 함수 인자가 모듈, 이름, 카테고리의 순인 반면, Ex 버전은 "모듈, 카테고리, 이름"으로 순서가 더 자연스럽게 바뀌기도 했다. LOAD_LIBRARY_AS_DATAFILE 옵션을 주고 불러온 DLL은 그저 훌륭한 데이터 셔틀일 뿐이긴 하다.

이걸 뜯어고치는 것은 결과적으로 <날개셋> 한글 입력기 소스를 더욱 질서정연하게 만든 나름 즐거운 작업이었다.
덤으로, 지금까지 제어판의 '외부 모듈 관리'에서 중국어 입력기들의 언어를 간체/번체를 구분 못 하던 버그도 잡았다. 3.0 이래로 sub-language가 지금까지 제대로 처리되고 있지 않은 듯했다. 한 작업 덕분에 여기저기서 관련 버그들이 일망타진된 것이다.

2. 작은 차이이지만..

날개셋문자를 입력받는 대화상자에서..
한글 자모를 구성하는 타입을 지정하면 아래의 그림과 같이 한글 자모를 입력받는 콤보 박스가 초중종 순으로 나란히 뜬다.

그런데, '한글 중종/초'나 '한글 종/초중' 타입을 지정했을 때는 그 콤보 박스도 초중종 순이 아니라 중종초나 종초중 순으로 뜨게 했다. 이들 날개셋문자는 세 성분을 그렇게 두 음절에 걸쳐서 문자 생성기로 전달하기 때문이다.
문득 생각이 떠올라서 구현해 봤는데 이렇게 하는 게 훨씬 더 직관적이고 좋다.

3. 단축글쇠 규칙

편집기 계층의 단축글쇠 규칙과, 기본 입력 스키마의 추가 글쇠 규칙 리스트에서..
아이템들을 선택한 후 드래그 드롭으로 순서를 조정할 수 있으며, 헤더를 클릭한 경우 정렬이 되게 했다.

리스트 컨트롤의 아이템들을 정렬하는 메시지는 LVM_SORTITEMS인데, 나중에 LVM_SORTITEMSEX도 추가되었다. 그 이유로는.. LVM_SORTITEMS는 정렬 비교용 콜백 함수에다가 LVITEM에 있던 lParam값만을 달랑 넘겨 줬기 때문이다.

그렇기 때문에 lParam만으로는 각 아이템이 원래 갖고 있던 문자열 같은 걸 참조할 수 없었으며, 이 때문에 lParam이 아니라 아예 아이템 인덱스 값을 넘겨주는 EX 버전이 윈도 98 즈음에 추가되었다. API 내력이 다소 안습하다.
단, qsort와는 달리 콜백 함수에 사용자가 지정한 user data도 같이 넘어오게 되어 있는 것은 바람직한 디자인이라 여겨진다. 이것은 EX뿐만 아니라 오리지널 버전도 처음부터 그랬다.

인덱스 번호를 받았다 하더라도 매번 2개의 LVITEM 구조체를 세팅하는 건 상당히 번거로우니, 정렬 비교를 위한 클래스를 따로 만들어서 LVITEM 구조체를 세팅해 놓고(mask, pszText, cchTextMax 따위), 비교 함수 호출 때는 인덱스 번호(iItem)만 세팅한 뒤에 곧바로 LVM_GETITEM를 호출하는 게 효율적일 것이다.

그리고, 트리 및 리스트 컨트롤에서 아이템의 드래그 드롭을 구현하는 것은 굉장히 노가다스러운 작업으로 Windows 프로그래밍 업계에서 악명이 높았다. 운영체제는 그저 아이템 드래그가 시작되었다는 이벤트만 날려 줄 뿐, 그 뒤부터 실질적인 드래그 드롭 처리는 전적으로 프로그래머가 알아서 해야 한다.

그 처리는 뭔가 패턴이 있는 것 같으면서도 상황별로 제각각 customize해야 하는 것도 미묘하게 있어서 더욱 까다로운데, 본인은 이미 드래그 드롭이 구현되어 있는(입력 항목의 이동 및 복사) '분야' 트리의 코드를 적극 재활용했다.

공통된 부분은 클래스로 만들고, 드래그 이미지를 생성하는 부분, 마우스 포인터로부터 hit test, 특정 아이템을 드래그 타겟으로 지정하는 부분처럼 customize가 필요한 부분만 가상 함수로 빼냈다. 그리고 트리 컨트롤의 HTREEITEM이든 리스트 컨트롤의 int 인덱스이든 구애받지 않는 추상적인 인덱스 자료구조를 설계했다.
드래그 함수는 드래그 중에 복사의 허용 여부 (0. 불능, 1. Ctrl 눌렀을 때 가능, 2. 읽기 전용 컨텐츠이기 때문에 무조건 복사)를 인자로 받아서 타겟 아이템과 복사 여부를 되돌린다.

이번 글은 기능 설명뿐만이 아니라 유난히 코딩 디테일 설명이 많은 듯한데, 아무튼 그런 과정을 거쳐 해당 기능이 깔끔하게 잘 구현됐다.

4. 입력 설정 테스트 대화상자

제어판의 시스템 메뉴에 딸려 있는 '입력 설정 테스트' 기능에다, 현재 사용 중인 입력 항목을 표시하고 굳이 단축글쇠 없이도 손쉽게 바꾸는 기능을 추가했다.
이 대화상자의 입력란은 <날개셋> 편집기 같은 다른 프로그램과는 별도의 컨텍스트에서 동작하기 때문에 내부적인 입력 상태를 알 방법이 없어서 불편했는데.. 이걸 추가해 주니 아주 편하다.

5. 수식 입력란에 풍선 도움말

그리고 이건 번개같이 아이디어가 떠올라서 집어넣었다. Bravo!
이 간단한 풍선 도움말을 왜 지금까지 넣을 생각을 안 했는지 모르겠다~!

암호 같은 각종 수식들에서 최소한 사용할 수 있는 변수들이 무엇이고 그게 의미하는 값이 뭔지는 간단히 바로 알 수 있게 했다.
그래도 연산자라든가 날개셋문자 notation (H3, C0, G_, BS 등등..)에 대해서는.. 지면이 부족해서 도저히 실을 수 없으니 추가적으로 도움말을 보고 공부를 해야겠지만..
이런 간단한 도움말이라도 있는 게, 없는 것보다는 백만 배 낫지 않으신지..?? ^^;;

풍선 도움말은 수식 입력란이 포커스를 받는 순간 나타나며, 한 세션당 총 3회만 나타난다. 매번 무조건 뜨는 것도 번거로울 수 있으니까.

6. 단축글쇠 규칙을 편집할 때의 날개셋문자-특수글쇠 목록

글쇠배열처럼 날개셋문자를 받는 수식 입력란에는 근처에 날개셋문자를 만드는 대화상자를 꺼내는 버튼이 따로 있다. 글쇠배열뿐만 아니라 편집기 계층의 단축글쇠 규칙에도 글자판(입력 항목) 전환뿐만 아니라 날개셋문자를 보내는 기능이 있기 때문에 날개셋문자 생성 대화상자를 여는 기능이 사용자 편의 차원에서 마련돼 있다.
그런데, 단축글쇠 규칙을 통해서 날개셋문자 대화상자를 열고 나면.. '특수글쇠(특수 코드)' 용도로 갔을 때 특수글쇠가 bksp나 후보 변환 같은 아주 기본적인 것 몇 개밖에 있지가 않다.

이것은 특수글쇠가 원래는 편집기 계층이 아니라 입력기 계층 아래에 있는 문자 생성기의 관할에 있기 때문이다.
글쇠배열이야 입력 스키마 계층이고 자신에게 연결된 문자 생성기를 바탕으로 지원되는 특수글쇠를 얻어 오면 되지만, 편집기 계층에서는 이 단축글쇠가 무슨 문자 생성기와 연결될지 알 수 없기 때문에 아무 문자 생성기에나 공통적으로 적용되는 것만 가져오게 했기 때문이다.

이것이 불편한 점으로 인식되어 다음 버전에서는 개선이 이뤄졌다.
단축글쇠 규칙을 통해 날개셋문자 대화상자를 연 경우, 현재 '활성화돼 있는' 입력 항목을 기준으로 그 문자 생성기가 지원하는 특수글쇠들을 모두 가져온다.
따라서 빈 입력기나 영문 쿼티/드보락 같은 걸 사용하다가 제어판을 열면 예전처럼 기본적인 것밖에 있지 않을 것이고, 한글 입력을 기준으로 제어판을 열면 <날개셋> 기본 입력기가 지원하는 특수글쇠들을 모두 보면서 고를 수 있게 된다.

편집기 계층에다가 단축글쇠로 날개셋문자를 강제 입력할 정도라면 일반적인 평범한 문자보다는 조합 강제 종료 같은 특수글쇠일 가능성이 높은데 이런 조치를 통해 프로그램을 사용하기기 더 편리해질 것이다.

7. 제어판 편집기 계층 탭의 GUI 일부 개선

이것도 사소하다면 사소한 것이지만..

<날개셋> 한글 입력기는 1.0 시절부터 한글 조합 중에 Del/화살표 키가 입력됐을 때 cursor 이동을 어디를 기준으로 할지를 지정하는 옵션이 존재했다.
1.0부터 지금까지 그 옵션은 체크 형태로 어설프게 존재하였으나.. 이번 버전에서는 드디어 이렇게 콤보 박스로 바뀌었다.
아무리 이분법적인 간단한 옵션이라고 해도.. 남자 여자 성별을 고르는 UI를 체크 박스로 처리할 수는 없는 노릇 아닌가.

Posted by 사무엘

마태복음 뒷부분을 읽으면서 먼 옛날, 예수님이 배반 당하고 악의 무리들에게 체포되고 '답정너' 어거지 재판을 받은 후 십자가에 달리시는 장면을 곰곰이 묵상해 보았다.

성경을 알면 알수록.. 이 십자가 사건은 도저히 일어날 수 없는 이상하고 기괴한 이벤트만 골라서 벌어진 끝에 가능했음을 알 수 있다.
비록 예수님이 가끔은 자신을 아버지 하나님과 동일시하는 발언 때문에 어그로를 끌긴 했지만, 일단은 기적 때문에 대중적으로 최소한의 인기와 지지를 확보하고 있었다. 백성들 눈치를 보는 '높으신 분'들은 예수님께 함부로 손을 댈 수가 없었다. 이런 이유로 인해 명절에는 체포와 처형을 더욱 피하려고 했는데.. 그런데 현실에서는 최악의 상황만 실제로 일어난 것이다.

가룟 유다를 보고는 예수님께서 “니가 이제 뭘 하려는지 난 뻔히 알고 있지만, 이건 짜고 치는 고스톱이니 니 할 일 하러 가라”와 다름없는 제스처를 취하면서 유다를 밖으로 보내 주셨다. 적들과 내통하러 나가는 건데도 어찌나 곱게 보내 줬으면, 그때 다른 제자들은 유다가 다른 돈이나 물건을 챙기는 심부름을 하러 나가는 줄 알았을 정도였다.
그 뒤, 군중이 붙어 있지 않은 한밤중에 예수님이 거의 “옜다, 나 잡아 가슈” 급으로 일부러 한적한 바깥에 나가서 낚여 줬다. 그 덕분에 체포가 가능했다.

제아무리 악의 무리라 해도 예수님이 선한 일을 한 것.. 즉, 병을 고치고 죽은 자를 살린 걸 트집잡을 수는 없는 노릇이었다. 다른 어설픈 거짓 증언들은 같은 상황에 대해서 자기들끼리도 진술이 일치하지 않아서 법적 효력이 발생하지 않았다.

그나마 트집 중의 하나가 뭐냐 하면 '성전 사흘 재건' 떡밥인데... 이건 처음 등장하는 곳이 원래는 요 2:19이지만 '카더라' 명목으로 마 26:61에서 먼저 미리 등장한다.
솔로몬이 기도를 한 내용이 있기도 하니 유대인들은 물리적인 성전 건물에 대한 애착이 굉장히 컸던가 보다. 그런데 그 엄청난 성전을 걸고 저런 충격적인 말을 예수님이 하셨으니 그게 예수님의 트레이드마크가 된 모양이다.

물론 앞뒤 문맥 행간 다 짤라먹고 사람을 사회적으로 매장하는 찌라시 기레기들의 수법은 지금이나 그 시절이나 다를 바 없었다. “예수, 성전 폭파 발언 충격 일파만파”처럼 말이다.

예수님은 다른 그 어떤 거짓 고소 개드립에도 대꾸할 가치를 느끼지 않아서 침묵으로 일관했지만, 자신의 정체성을 묻는 질문에는 즉각 대답하셨다. 대제사장 앞에서든(마 26:63-64), 빌라도 앞에서든(마 27:11) 말이다. 그것이 당장 자기 신변을 불리하게 만드는 답변이더라도 말이다.
예전부터도 예수님은 시종일관 사람들로 하여금 자기가 누구인지를 정확하게 알기를 원하셨다. “그러나 너희는 나를 누구라고 하느냐?” (마 16:15)

다른 사람들은 마태복음 22장에서 볼 수 있듯이 정치, 종교, 시사 등 온갖 주제로 예수님께 질문을 했지만 예수님은 그냥 즉문즉답이었다. 오히려 그런 것들은 별로 중요한 주제가 아니니 제끼고, 그분이 카운터어택으로 딱 하나 바리새인들에게 질문하셨던 것은 “그리스도는 다윗의 자손인데 왜 선조인 다윗이 자기 후손을 보고 주님이라고 불렀을까?” 정체성 질문 하나뿐이었는데.. 그것만으로도 그들은 떡실신했다.

그러니 이런 패턴을 아는 예수님의 적들이 트집을 잡은 방법은 역시나 100% 걸려들 수밖에 없는 종교라는 형이상학적인 영역을 악용하는 것이었다. 다니엘을 모함한 대신들이 다니엘을 행실로는 트집 잡을 수 없으니 기도라는 종교 관습으로 올가미에 넣었듯이 말이다. 다니엘도 그냥 그 30일 동안은 그냥 문 닫고 골방에서 몰래 기도할 수도 있었지만, 일면 고지식한 바보 같이 일부러 흉계에 걸려들었다.

이처럼 예수님도 자기 정체성만은 당당하게 드러내셨다. 대제사장은 드디어 명목상 신성모독이라는 중대한 껀수를 하나 잡았으니 이렇게 기쁠 데가. 하지만 겉으로는 옷을 찢고 오버하면서 “oh my god!! ㅠ.ㅠ 어머나 세상에 제 입으로 제 발로 하나님을 사칭하는 놈이 있다니 이런 참람할 데가! 이 이상 무슨 증거가 더 필요하단 말이냐? 이 새퀴는 뒈져야 마땅하다”라고 짜여진 각본대로 아주 생지X(비속어 죄송~~)을 해 댔다. 옛날에 악의 무리들이 나봇을 신성모독죄 누명을 씌워 인민재판을 벌이고 죽였을 때처럼 말이다.

이것은 정말 충격적인 사건이 아닐 수 없다. 온 우주 만물을 창조하고 인간을 창조한 그 창조주가 현신했는데 피조물들로부터 따귀를 맞고 침뱉음, 조롱, 학대를 당한 것이다. 왜? 무엇 때문에? 성경의 가르침에 따르면 그 피조물 인간의 죄를 사하기 위해서이다.

이런 예수님의 이해할 수 없는 행동 때문에 제자들은 실족하고 멘붕에 빠지고 도망쳤다. 5천 명의 군중을 먹이고, 물 위를 걷고, 중병을 고치고 마귀들을 내쫓고 죽은 사람까지 살렸던 자기 스승이 언제부턴가 고난, 죽음 얘기를 하면서 분위기에 찬물을 끼얹더니.. 왜 이렇게 너무 나약하게 험한 꼴을 당하는 걸까?

베드로는 의욕이 넘쳐서 처음엔 예수님의 적들을 향하여 용감하게 칼까지 휘두를 정도였지만.. 예수님이 자기 기대와는 너무 딴판으로 행동하자 제풀에 기가 죽었고.. 결국은 예수님의 예언대로 위급한 상황에서 그분을 세 번 부인하는 인생일대의 실수를 저지르고 말았다.

유대인 종교 지도자들은 예수님을 반역죄 신성모독죄로 몰아서 죽이고 싶었지만, 자기들도 로마 제국의 식민지인 판에 자체적으로 사형 집행을 할 수 없었다. 그래서 결국은 그분을 제거하기 위해 자신들의 정치적 원수인 외세까지 끌어들이는 비열한 짓도 서슴지 않았다. 나중에는 “우리에게는 카이사르 외에는 왕이 없나이다” 이러기까지 한다. 일제 강점기로 치면 조센징들이 “우리에게는 덴노 외에는 왕이 없나이다” 이런 짓을 한 거나 마찬가지이다! 이걸로도 모자라서 자기 무덤을 스스로 파 버린 확인사살 크리티컬은 “저 사람의 피가 우리와 우리 자손에게 돌아올지어다”이고 말이다.

하지만 빌라도도, 헤롯도 예수님을 찬찬히 살펴보니 저 사람은 딱히 사형을 당할 만한 중죄인이 절대 아니었다. 헤롯은 예수님을 그냥 해롭지 않은 미치광이 정도로 치부한 듯하나 빌라도는 예수님이 보통사람이 아니란 걸 직감했다. 목숨을 전혀 구걸하지 않고 태연한 그분의 포스에 자신이 오히려 압도당하고 초조해졌다. “다.. 당신은 왜 아무 말도 없느냐? 주변에서 온통 당신을 고소하는 말이 들리지 않느냐? 나에게는 너를 처벌하거나 풀어 줄 권한이 있는데 왜..? 으응..??” 같은 식.

빌라도는 예수님을 풀어 주고 싶었지만 이미 민심은 광기로 치닫고 있었다. 종교 지도자들로부터 선동을 당했는지, 아니면 무기력한 예수님의 모습에 실망했는지 백성들조차 폭도 바라바를 석방하라고 요구하고 예수님에 대해서는 그야말로 최악의 흉악범에게나 집행되는 십자가형을 요구했다. 그리고 빌라도는 자기 정치 생명 보존을 위해 이를 허락해 버렸다. 그것도 명절 기간에..;; 이때 같이 들러리로 끌려나와 갑자기 십자가형을 당한 죄수 두 명은 날벼락이 따로 없었을 것이다.

온갖 기적을 베풀며 당장이라도 자기 민족을 로마 제국으로부터 해방시킬 것 같던 슈퍼스타 예수가 하루아침에 너무도 무기력하고 나약하게 십자가형을 당하자.. 무지한 군중들은 그분에게 온갖 야유를 퍼부었다. '성전 사흘 재건' 떡밥도 다시 나온다. (마 27:40)
“성전을 헐고 사흘 만에 다시 짓겠다더니 당신 꼴 좋다~!”
“중이 제 머리는 못 깎는다더니 저 사람은 자기 자신은 못 구하네? ㅋㅋㅋㅋㅋ 당신이 정말 하나님의 아들 & 유대인의 왕이라면 한번 그 십자가에서 내려와 보시지? ㅋㅋㅋㅋ”

그러나 이때 예수님의 기도는 정말 비장하고 숙연하기 그지없었다! “아버지여, 저들을 용서하여 주옵소서. 저들은 자기들이 하는 일을 알지 못하나이다.” (눅 23:34)
십자가에 같이 매달린 두 강도들도 처음에는 같이 예수님을 조롱하고 욕했었다. 제 코가 석 자인 주제에.
그러나 누가복음의 진술에 따르면 둘 중 하나는 나중에 회개하고 예수님을 주님이라고 부르는.. 정말 드라마틱하고 놀라운 회심을 했다. (눅 23:42)

그 뒤의 결말은 여기서 굳이 길게 각색해서 쓸 필요가 없을 것이다.
예수님은 십자가형을 당한 여느 죄수들과는 달리 불과 몇 시간 만에 일찍 숨이 끊어졌다. 요한복음에 따르면 이것은 생물학적으로 불가피한 죽음을 맞이한 게 아니라 자기 스스로 생명을 내어놓은 거라고 한다. 십자가형은 참수나 화형과는 달리 죽을 때까지 죄수를 내버려 두는 형벌이기 때문에 역설적으로 저런 행적이 나올 수가 있다.

그러나 예수님은 장사되고 묻힌 지 사흘 만에 부활했으며, 이를 본 제자들은 그야말로 가슴이 터질 듯 기쁨으로 용기백배하여 담대한 복음 전도자로 바뀌었다. 그 어떤 난관이나 심지어 죽음과 순교도 이들의 증언을 꺾지는 못했다. 그래서 기독교가 태동할 수 있었다. 지구상에 존재하는 종교들 중 신이 인간을 먼저 사랑했고 인간을 위해 고난을 당하고 피흘려 죽었지만 부활까지 했다고 가르치는 유일한 종교이다!

국내에는 송 명희 시인이 예수님의 고난을 뭔가 인간적인 애틋한 심상으로 그리는 데 일가견이 있었다. <얼마나 아프실까>, <우리의 어두운 눈이 그를>, <누구 때문에> 같은 찬양 말이다. 물론 예수님의 고난과 죽으심은 단순히 국가를 위해 목숨을 바친 애국지사나 여느 순교자 같은 성격은 아니다. 또한 무슨 도살장에서 도축 당하는 짐승을 불쌍해하듯이 인간의 입장에서 무작정 동정할 만한 성격도 아니다. 하지만 하나님이 우리에게 베푸신 사랑은 뭐랄까 정말 엄청나고 대단한 일인 건 틀림없다.

예수님이 부활한 것으로도 모자라서 봉인까지 아무 문제 없이 뚫고 무덤을 탈출하자, 기존 악의 무리들은 보초병들을 매수하여 여론 조작을 시도했다. 보초병들이 조는 사이에 제자들이 무덤에 침입해서 예수 시체를 훔쳐 갔다는 거짓 소문을 퍼뜨리는 걸로 대응했다.
그 시절에 로마 군인이 근무 중에 졸다가 적발되었다? 이건 중대 군기 문란죄이며 당사자는 그야말로 끔살을 면치 못했다. 또한 죄수 같은 걸 놓쳤다면 지키던 간수가 자기 목숨을 대신하여 책임을 져야 했다. (행 12:19 베드로를 놓친 감옥 간수들의 최후. 행 16:27 감옥이 지진으로 파괴되자 간수는 곧장 자결하려 함)

아무리 유대교 종교인들이 돈을 많이 주고, 또 졸았던 것에 대해서 자신들이 적극 변호하고 실드를 쳐 주겠다고 약속은 했어도... 졸다가 예수 시체를 도둑맞았다는 소문을 로마 군인이 퍼뜨린다는 건 어지간해서는 자충수에 가까운 짓이었을 텐데 싶은 생각이 든다. 뭐, 고의성이 있든 없든 예수님 시신을 놓친 군인들은 어떤 경우든 신변이 좀 걱정되는 처지가 되었겠지만.

우리는 종교 지도자들의 앞뒤가 안 맞는 행적을 좀 더 살펴볼 수 있다.
자기가 내리는 결정에 대해서 절대적인 옳고 그름을 따지는 게 아니라, 백성들 눈치를 보고 그들의 예상 반응을 시뮬레이션하고, 서로 의논을 하면서 잔머리를 굴린다. “요한의 침례가 어디로부터 왔느냐?”에 대한 대답도.. 예 아니면 아니요라고 하면 될 것을 그들은 어떻게 대처했던가? (마 21:25-27)

또한 온갖 율법을 어기면서 예수님을 거짓 고소하고 추악한 짓은 다 했으면서... 가룟 유다로부터 반환받은 돈은 제 딴에 더러운 돈이라고 성전의 보고에다 안 넣고 율법 따지면서 종교적인 행세를 한다(마 27:6).

그들의 또 다른 위선적인 면모는 예수님께서 “화 있을진저”라고 그들을 맹렬하게 책망하시는 23장에 기록되어 있다. 마 23:29-33을 보면.. 한 마디로 이런 내용이다. “우리 선조들은 참 병신 같아서 하나님께서 보내신 참 대언자들을 핍박하고 죽였어요. 우리가 그 시대를 살았다면 안 그랬을 겁니다.”
허나, 이들이 얼마 안 있어 예수님을 제거하려는 음모를 꾸몄다는 걸 생각한다면 피식 웃음이 나오지 않는가?

물론, 우리라고 해서 예수님과 동시대를 살았다면 과연 예수님의 진면모를 영적으로 파악하고 그분의 길을 따랐을지.. 아니면 역시나 육신적인 선동에 혹해서 그분을 정죄하는 일에 동참했을지 알 수 없는 노릇이다.

성경은 인간이라면 바다가 갈라지고 홍해 중앙을 멀쩡히 건너는 넘사벽 기적 체험을 하고도 딱 사흘 뒤엔 목 말라 죽겠다고, 이딴 식으로 고생하면 뺑이 칠 거면 걍 이집트로 돌아가자고 하나님께 불평을 늘어놓을 수 있다고 말한다.
그리고 자기 영웅 예수님이 입성하는 걸 흥분해서 환영하던 인파들도 며칠 뒤에 태도가 180도 돌변하여 “폭도 바라바를 풀어 주고 예수라는 저 무능한 꼰대는 십자가에 못 박으시오!” 하는 것도 얼마든지 가능하다고.. 인간이 생각보다 굉장히 변덕이 심하고 간사하다고 말하는 책이다. 당신이라고 해서 안 그럴 것 같은가? “천만에”다.

바리새인들은 나름대로 바빌론 포로 귀환 이래로 이제 절대로 우상 숭배 안 하고 최소한 구약 성경 유일신만 믿기로 작정을 한 종교 꼴통들이다. 그리고 서기관들은 구약 성경을 필사하고 보존해 온 종교 전문직 종사자들이다.

이들이 비록 예수님 당대에 전반적으로 영적으로 좀 맛이 가 있긴 했어도 이들만이 마치 악의 축인 양 싸잡아 정죄하는 것은 성경 독자로서 옳지 못한 태도이다. 세상에는 바리새인만도 못한 인간들 역시 엄청 많다는 걸 알아야 하며, 특히 예수님을 죽인 민족이라고 크리스천이라는 사람이 유대인들을 핍박하고 반유대주의 풍조에 동조하는 건 절대로 성경적인 자세가 아님을 명심해야 한다.

결국 글이 굉장히 길어져 버렸는데.. 맺기 전에 하나만 더, 빌라도와 가룟 유다에 대해서 좀 생각을 해 보겠다.
먼저 빌라도. 그는 현장에서 저렇게 우유부단하고 고뇌하던 모습으로 인해, 그저 운 나쁘게 저 현장에 있었을 뿐이고 악의적이는 않았던 나약한 보신주의자라는 식으로 실드 치는 해석이 있다. 그러나 빌라도를 필요 이상으로 긍정적으로 볼 필요는 없을 것 같다. 어쨌거나 그는 이 사건을 계기로 헤롯하고도 다시 친해졌을 정도로(눅 23:12) 결국 예수님의 대적들 편에 확실하게 섰기 때문이다. “진리가 무엇이냐?”(요 18:38) 이건 진지한 구도적인 질문이 아니라, 대답을 기대하지 않고 그냥 한 마디 툭 던진 립서비스일 뿐이었다. “ㅉㅉ 이 상황에서 뭔 놈의 얼어죽을 진리 타령이냐?”에 가깝다.

원쑤지간이던 빌라도와 헤롯이 과연 무엇을 매개체로 화해했을지도 생각해 보면 뻔한 노릇이다. 까놓고 말해 술자리에서 술안주로 예수님을 같이 씹으면서 친해진 게 아니면 무엇이겠는가! “내가 보니 그 사람 완전 바보 싸이코더구만! ㅋㅋㅋ” “그러게? ㅋㅋㅋ 사실은 나도 똑같이 생각했지!” 그는 예수님을 대면하면서 양심이 좀 찔리던 기억은 이런 식으로 잊어버리고 훌훌 털어내 버렸다.

그리고 유다는 인간적으로는 예수님의 제자였다가 한 순간에 대실수를 저지르고 그걸 자살이라는 방법으로 수습하여 비참한 최후를 맞이한 사람 정도로 여겨진다. 하도 부정적으로만 평가되다 보니 마치 원 균을 재평가하듯이 유다도 최대한 개인 상황을 감안하여 긍정적으로 재평가하는 신학 해석도 있을 정도이다.

그러나 유다는 단순히 사람이 아니라 동정의 여지가 없이 성육신한 마귀라는 해석이 있다. “그 중의 하나는 마귀이니라” (요 6:70)가 비유가 아니라 평이한 사실 진술이라고 생각하는 것이다. 또한 행 1:25에서도 베드로가 유다는 단순히 죽은 게 아니라 자기 처소로 돌아갔다고 얘기하는 게 뭔가 저 사람 정체가 예사롭지 않다는 걸 암시한다.

그렇다면 예수님이 성육신하고 나서 얼마 있지 않아 마귀 역시 짝퉁 성육신해서 훗날 예수님의 제자로 위장해 들어갔다는 뜻이 되는데.. 사실이라면 많이 무섭다. 성경에는 유다 자체가 마귀라는 말뿐만 아니라 “유다에게 사탄이 들어갔다”(눅 22:3), “사탄이 유다에게 이상한 생각을 넣었다”(요 13:27) 같은 상이한 진술이 모두 들어있다.
이것은 마치 다윗의 잘못된 인구 조사의 배후에 무슨 일이 있는지에 대해서 성경이 상이하게 진술하는 것과 비슷한 맥락이다(삼하 24:1, 대상 21:1). 동일한 사건을 다른 각도에서 조명한 것으로 보인다.

유다는 예수님을 배반했다가 나중에 목을 매어 자살했는데, 이 사건은 마태복음에만 기록되어 있다. 사도행전의 증언을 보면 그는 내장이 튀어나오며 상당히 끔찍하게 죽은 것 같다. (행 1:18)
단, 사도행전 1장에서 언급되는 피 밭과, 마태복음 27장에서 언급되는 피 밭은 개념상 서로 다른 장소이다.
전자는 유다가 개인적으로 비축해 둔 돈으로 산 자기 땅이다. 그러나 후자는 따로 토기장이의 땅을 사서 조성한 공동묘지이기 때문이다.

Posted by 사무엘

1.
20세기 초· 중반이 배경으로 나오는 영화나 드라마를 찍는다면 그 당시 길거리를 달리던 옛날 자동차들도 재연되어야 한다. 이런 '올드카'들은 상업적인 임대 수요가 있으며, 이를 대여해 주는 업체도 응당 존재한다.
하지만 국내에서 원하는 올드카를 못 구하면, 외국으로 진작에 수출된 옛날 국산차를 다시 역수입해 와서 쓰기도 한다. 우리나라에서는 진작에 처분된 차들이 외국에서는 아직까지 현역으로 뛰고 있기도 하기 때문이다.

다만, 1990년대 이전의 옛날 자동차는 지금의 자동차하고는 당장 연료가 호환되지 않을 텐데 그런 건 어떻게 극복했나 모르겠다. 당장 휘발유만 해도 유연과 무연의 차이가 존재하며 경유 역시 유황 성분이 더 줄어들고 이것저것 변화가 있었기 때문이다.

최악의 경우는.. 어차피 화면에는 올드카의 외형만 비치면 되니까 엔진은 요즘 차량의 것으로 싹 갈아 버릴 수도 있다.
요즘 관광용으로 일부러 도입해서 굴리는 증기 기관차는 겉모양만 증기이지 석탄이 아닌 석유로 물을 끓인다거나, under the hood는 아예 내연 기관이 달린 디젤 기관차인 경우가 대부분이듯이 말이다.
하지만 자동차의 경우 엔진 교체는 쉽게 가능한 일이 아니며, 엔진이 다른 것으로 교체되어 버리면 엔진음은 옛날 차의 것이 그대로 재연되지 못할 것이다.

본인은 지난 올해 상반기 중에 서울 시내에서 포니 2를 한 대 구경한 적이 있다.
그렇게 한 차를 20년, 30년씩 굴린 차주들은 당연히.. 주변에서 “그랜저를 줄 테니, 그 포니를 내게 파시오.” 식으로 제안하면 절대로 응하지 않는다.
하다못해 머리카락이나 손톱을 엄청나게 길게 길러서 기네스북급의 기록을 갖고 있는 사람들만 해도 돈을 아무리 많이 준다 해도 그걸 안 자른다. 하물며 자기 인생을 함께한 올드카 애마를 돈 몇 푼에 처분하겠는가?

우리나라의 올드카 수집가로 유명한 사람은 이걸로 아예 직업을 삼은 금호 상사의 대표 백 중기 씨이다. 금호 렌터카와 혼동하지 말도록. 이미 1970년대부터 길거리에서 소리없이 사라져 가는 올드카에 대한 경각심을 느끼고 시발 자동차 택시, 기아 삼륜차, 이 승만· 박 정희 대통령의 관용차 등 까마득한 올드카들을 수집해 왔다고 한다.

단종되고 제조사로부터 A/S가 더 없고 부품을 정상적인 통로로 구할 수 없는 자동차는 소프트웨어로 치면 지원이 완전히 종료된 abandonware나 마찬가지이다. 저분은 수백여 대의 올드카를 보유하고 있다는데 단순 정태보존인지, 아니면 운전이 가능한 동태보존의 비율은 얼마나 되는지 모르겠다. 그리고 세금· 보험료 같은 굴레 없이 수집이 가능했는지도 궁금하다.
거기에다 평상시에 보존· 유지를 위해 물리적으로 깨지는 비용을 생각하면 올드카 임대를 통해 그렇게까지 많이 수지 맞는 장사를 해 온 건 아니라고 함. 아무튼 덕업일치에 좋은 일을 해 온 대단한 분이다.

2.
그리고 올드카 얘기 하나 더.
예전에 이 블로그에서 새한 자동차 시절의 구닥다리 8.5톤 덤프 트럭을 소개한 적이 있었다. 그런데 그것보다 더한 자동차계의 노인학대가 존재한다는 정보를 엔하위키를 통해 전격 입수했다.

바로 미국의 제너럴 모터스에서 생산한 바퀴 10개짜리 카고트럭.
무려 1940년대 중반에 생산된 군용차인데, 현역에서는 1970년대에 물러나고 민수용으로 풀린다.
그런데 그런 차가 충북 내지 강원도의 오지에서 적어도 2000년대 중후반까지 혹사당하고(?) 있다고 한다.

이 차의 애칭은 '제무시 트럭'이다. GMC를 일본식으로 읽으면 '지-에무-씨'가 되는데 그걸 줄여서 '제무시'라는 기괴한 명칭이 된 것.
군용차는 무겁고 완전 기름 먹는 하마 급의 연비를 자랑하지만, 그만큼 어마어마하게 튼튼하며 어지간한 트럭이 지나갈 엄두를 못 내는 험지나 오르막도 거뜬히 오른다.
시간이 정지한 듯한 이 트럭의 활약기를 살펴보시기 바란다.

3.
세워진 자동차에 주차료가 부과되는 것만큼이나 공항에 세워져 있는 비행기에는 시간에 비례하여 주기료가 부과된다. 이거 생각보다 꽤 비싸다. 인천 공항에 보잉 747 여객기를 세워 놓는 비용은 하루 기준으로 거의 100만원이 조금 넘는다. (지금은 더 올랐을지도 모름)

물론 보잉 747은 어마어마하게 공간을 많이 차지하는 거대한 물건이긴 하나, 어쨌든 금액의 스케일이 10분당 1천원 꼴로 주차료를 받는 서울 시내의 좀 비싼 유료 주차장의 임률도 아득히 초월하는 셈이다. 게다가 인천 공항 정도면 주기료가 합리적이지, 공항 이용 비용이 악랄하게 비싼 축에 드는 공항도 아니다.
비행기는 하늘을 날면서 승객과 화물을 나를 때는 돈을 벌어다 주지만, 그렇지 못할 때에는 돈 먹는 하마로 전락하고 만다는 걸 알 수 있다.

그런데 수 년 전엔 인천 공항의 주기장 한쪽 구석에는 태국, 이란 등 운영이 제대로 못 되고 있다가 사실상 망한 항공사의 여객기가 최대 4대 무단 방치된 적이 있었다. 2년 넘게 방치된 비행기는 당장 운용을 할 수 없을 뿐만 아니라 주기료도 수억원 대가 넘게 밀렸을 텐데... 2010년대 이후로는 뉴스 기사가 더 보도되지 않는 걸로 보아 지금쯤은 인천 공항 측에서 그런 흉물을 임의로 압류· 매각을 해서 처리하지 않았나 싶다.

우리나라도 남북 관계가 안 좋아져서 개성 공단이 가동이 몇 달 중단된 동안 기계들이 다 망가졌다고 공장주들이 울상이었다. 자동차만 해도 한 달 정도만 안 몰고 있으면 상태가 어찌 될지 알 수 없는데 기계라는 게 참 그런 특성을 가진 물건인 것 같다. 장기간 가동을 안 할 거면 연료를 빼내고 장기 보존 가능한 특수한 처리라도 해야 할 터.

4.
미국 캘리포니아 주의 모하비 사막에는 '모하비 공항'이라는 생소한 공항이 있다. 얘는 세관· 검역 시설을 갖춘 국제공항도 아니고 정기 운항 비행기도 없이 사막에 덩그러니 놓인 듣보잡 공항일 뿐인 것처럼 보이나, 다른 공항에는 없는 특별한 속성이 두 가지가 있다.

하나는 정식 타이틀이 단순 airport가 아니라 air and space port라는 것. 즉, 여기는 단순 항공기뿐만 아니라 민간 우주선(Spaceship One 같은)이 이착륙하기도 한다.
그리고 여기는 바로 민항기의 양로원 내지 무덤이다. 건조하고 땅값 저렴한 사막이다 보니 전세계에서 퇴역한 항공기, 혹은 망한 항공사로부터 매각된 항공기들이 여기에 수두룩하게 쌓인다. 아직 현역으로 구를 만해서 다른 항공사로 저렴한 중고로 팔려간다면 다행이지만, 상품성을 상실할 만큼 심하게 노후한 항공기는 여기서 폐기되어 부품이 뜯겨 나간다.

5.
그리고 캘리포니아 주 근처(근처..래 봤자 수백~천수백 km 떨어져 있지만)에 있는 아리조나 주의 데이비스 몽선(Davis-Monthan) 공군 기지 인근에는 '노후 전투기 보관소'가 있어서 수천 대에 달하는 퇴역 군용기들이 보존되어 있다. 미 해군, 공군, 해병대가 쓰다가 퇴역시킨 군용기들은 거의 다 여기에서 최후를 맞이하는 셈이다.

여기에 남아 있는 항공기들은 대략 70%가량은 약간의 수리를 거친 뒤 다시 비행이 가능한 정도라고 한다.
모하비 공항은 인근에 에드워즈 공군 기지가 있긴 하지만 공항 자체는 민간 공항이다. 하지만 여기는 주 보존 대상도 군용기들이고 엄연한 공군 시설 내부이다.

이 보관소의 항공 사진을 보노라면 “전투기는 많지만 조종사가 없습니다(부족합니다)!”라고 하는 영화 <인디펜던스 데이>의 대사가 고증에 굉장히 충실하게 만들어졌다는 걸 알 수 있다. 여러 조종사가 한 비행기를 굴리가면서 타는 게 일반적이지, 전투기가 조종사보다 더 많다니 이게 말이나 되는 소리인가? 과연 show me the money 국가인 미국이니까 가능한 스케일이다.

Posted by 사무엘

여러분은 다음과 같은 서로 완전히 다른 분야의 관행들에서 공통된 패턴이 존재한다고 생각하시는가? 만약 존재한다면 공통점이 무엇일까?

• 컴퓨터에서 각종 계정의 암호를 설정하는데, 암호는 무조건 n글자 이상에 대소문자와 숫자 등이 반드시 골고루 섞여야 한다고 프로그램이 사용자에게 강요를 한다.
• 출퇴근 시간엔 서울 지하철 사당 역은 2호선과 4호선 사이의 지름길 직통 환승 통로를 폐쇄하고 먼 우회 통로로만 환승이 가능하게 만든다. 또한 사람이 지나치게 많이 몰리는 행사가 열리면 가까운 지하철 역이 통째로 폐쇄되고 열차가 무정차 통과한다.
• (종교 얘기. 비기독교인은 skip해도 좋음) 예루살렘에서 성령이 강림한 후 신약 기독교회가 갓 태동했다. 그러나 하나님은 역설적으로 그 기독교 성지에서 맹렬한 기독교 박해와 스데반의 순교를 허락하셔서 신자들을 뿔뿔이 흩어 버렸다.

내가 생각하는 이것들의 공통점은... 한데 몰려서는 안 되는 곳에 사람들이 지나치게 많이 몰릴 때 “그 몰리는 선택지 자체를 없애 버려서 분산을 강제로 유도”했다는 점이다. 그리고 이로써 집단 내부의 잠재적 부작용이나 병폐를 해결했다.

먼저 종교의 경우다. 먼저 믿고 구원받은 크리스천은 주님의 명령대로 세상 방방곡곡에 흩어져서 복음을 전해야 하는데 그게 말처럼 쉽지 않다. 어지간하면 그냥 신자들끼리만 기득권을 형성하고 교제라는 명목의 친목질만 하면서 고향에서 편하게 살고 싶다. 그러니 하나님이 저런 역경을 허락하신 것이다. 물리적으로만 보자면 그건 자기 신자를 줄이고 세력을 약화시키는 팀킬인데 기독교는 오히려 그런 역경을 통해서 역설적으로 잡초처럼 더 강해지고 널리 퍼져 온 것이다.
(단, 그렇다고 해서 기독교 박해 행위 자체를 정당화할 생각은 하지 마시길.)

교회사뿐만 아니라 바벨 탑 사건도 비슷한 맥락으로 사람들을 강제로 뿔뿔이 흩어 버린 경우에 속한다. 온 인류가 단일 민족 단일 언어이면 지금처럼 복음 전할 때에도 “아프리카 원주민이나 세종대왕, 이 순신 같은 사람도 다 예수 전해듣지도 못했는데 지옥 갔냐?” 이런 쓸데없는 질문을 받을 일이 없었을 텐데.. 하나님이 왜 그런 비효율적인 자충수를 일부러 두신 걸까?

두 말할 나위도 없이 인류가 단일 언어 단일 체계이면.. 다같이 하나님을 믿는 것보다 다같이 순식간이 부패하고 타락하고 썩어 버리는 게 훨씬 더 빨리 진행되기 때문이다. 다 합당한 이유가 있다.
그 대신, 교회가 태동하던 무렵에는 복음이 빨리 퍼져 나가라고 바벨 탑 사건 때와는 정반대로 언어 장벽을 잠시 극복해 주신 것이다. 그게 바로 '방언 은사'이라는 거다. 성경의 방언은 알아들을 수 있는 외국어이지, 울랄날따따따 잡소리가 절대 아니다.

자 그건 그렇고, 교통 얘기로 오면..
사람이 한 장소에 너무 몰리면 꼼짝달싹 못 하고 아무도 이동을 못 하게 될 뿐만 아니라 압사 사고 등 안전상의 위험도 매우 커진다. 제일 가까운 지하철역을 폐쇄하는 것은 사람들을 더 먼 곳까지 강제로 이동시킴으로써 밀집도를 낮추는 효과를 내며, 우회 환승 통로 역시 환승 승객을 수용할 공간을 확보하여 밀도를 낮춰 준다.

새해에 타종 행사를 하고 나면 종각/시청 일대의 지하철역이 폐쇄되고 불꽃 축제가 있을 때는 여의도 근처의 지하철역이 폐쇄되는 이유가 이로써 설명된다. 지난 여름에 교황이 왔을 때에도 광화문, 시청 근처의 지하철역은 당연히 폐쇄크리를 먹었다. 정말 상상을 초월하는 수의 인파가 몰렸기 때문이다.

서로 가깝고 같은 기간에 동일한 십자형으로 건설된 천호 역은 환승 거리가 짧은 반면, 군자 역은 거리가 일부러 꽤 길게 만들어져 있다. 7호선이 8호선보다 더 수요가 많고 혼잡하기 때문일 것이다.
그런데 천호도 마냥 짧기만 한 건 아니다. 천호에서 8호선을 타는 승객의 압도 다수가 잠실 역에서 내리는데, 환승 지점은 열차의 뒷부분이고 잠실에서 빨리 갈아타려면 암사 방면 열차의 맨 앞까지 이동을 해야 한다. 이것 때문에 사람들이 많이 걷는다. 지하철 8호선이 만들어질 때 이런 것까지 다 지능적으로 고려를 했는지는 모르겠다.

자, 그 다음으로 암호 얘기를 하겠다.
모든 사람들이 정말 정보 엔트로피가 높은 완전 무작위한 숫자· 문자를 암호로 사용한다면..
저런 제약은 오히려 암호 공격자에게 좋은 단서로 작용할 수 있다. 비록 암호 조합 문자열이라는 파이 전체에서 차지하는 비중은 여전히 미미하겠지만, 어쨌든 n글자 이하는 절대로 거들떠보지 않아도 되고, 한 종류의 문자만으로 이뤄진 문자열은 처음부터 탐색 대상에서 제끼면 되니까 말이다.

그런데도 굳이 저런 제약이 존재하는 건.. 불행히도 매우 많은 사람들이 저 작은 표본을 벗어나지 않는 범위에서 암호를 허술하게 만들고, 그게 공격자에게 왕왕 털리기 때문이다.
password, qwerty, q1w2e3, asdf, letmein, love 등...;;
그러니 차라리 그 표본을 명시하고서 사용자들로 하여금 강제로 배제하게 하는 게...
공격자에게 새 발의 피 정도의 단서를 던져주고서 전체 보안은 넘사벽급으로 훨씬 더 강화하는 효과를 낸다. 내 발뒤꿈치를 주고 상대방의 머리를 공격하는 전략 되겠다.

암호라는 건 마치 캡챠만큼이나 서로 모순되는 두 이념을 적당히 잘 충족해야 한다.
캡챠가 사람은 쉽게 알아보고 컴퓨터는 못 알아보는 그림이라면, 암호는 공격자--공격자의 주 도구인 컴퓨터도 포함--는 유추하기 무진장 어려우면서 당사자는 기억하기 쉬워야 한다.
주인이 기억하기 쉬우려면 결국 주인은 자기 개성을 표현하는 문자열을 떠올리게 되는데, 이렇게 되면 암호 공격은 거의 사회과학의 영역으로까지 확장되게 된다.

(더 극단적으로는, 기계적으로 완전 철통같은 암호라 해도 암호를 아는 사람을 돈이나 미인계로 매수한다든지, 혹은 아예 물리적으로 잡아 족침으로써 어이없게 뚫어 버리는 예도 있다.;; brute force 테크닉 그딴 것도 필요 없다. 성경에도 삼손의 지인들이 삼손의 수수께끼를 어떻게 풀었던가? 삿 14 참고)

일반적으로 컴퓨터 소프트웨어의 암호 입력란은 IME가 동작하지 않아서 영문· 숫자 이외의 문자를 입력할 수 없다. 이건 여러 모로 바람직한 조치라 여겨진다.
암호는 무슨 문자를 입력하느냐보다는 결국 무슨 keystroke를 입력했느냐가 더 중요하며, 지금 입력하는 글자가 일반적으로 화면에 보이지 않기 때문에 복잡하게 입력 모드 같은 걸 따질 처지가 못 된다.
또한 암호 입력란에서 IME 같은 별도의 소프트웨어 계층이 동작할 경우, 암호 문자열을 악성 프로그램이 가로채는 보안 문제가 커질 수도 있다.

하지만 이런 점에도 불구하고, 운영체제의 자체 GUI를 쓰지 않는 프로그램 중에는 IME가 동작하는 암호 입력란을 가진 경우도 있다. 굳이 한글로 입력을 안 하고 영문 자판에서 한글 입력을 하면.. 무질서도가 상당히 높은 알파벳 문자열이 생성되기 때문에 외국인 공격자가 알아내는 데는 애로사항이 꽃핀다. 이 사용자가 한국인이라는 단서가 없다면 말이다.
특히 세벌식은 사용자가 매우 적은 데다가 자체적으로 4단의 숫자· 기호까지 일부 활용하기 때문에 이런 보안 면에서 아주 좋다. Mac OS가 악성 코드가 별로 안 들끓는 이유도 딴 거 없고 사용자가 심히 적어서 해커들에게 별로 돈이 안 되기 때문이다. 간단하다.

아무도 모르고 내가 기억하기 쉬운 문자열이라는 특성상, 국가를 막론하고 욕설을 암호로 사용하는 사람도 있다. 뭐, 나쁠 것 전혀 없는 발상이긴 하지만 너무 대중적인(?) 욕설은 공격자들도 이미 다 파악하고 있으니 이 역시 조심해야 한다.

암호는 닥치고 20글자 이상으로 엄청 길면.. 무질서도가 기하급수적으로 치솟는다. 어지간히 단순무식한 형태의 암호라고 해도 엄청나게 긴 것에는 답이 없다. 글자수가 몇 자 늘어날 때마다 0.n초이던 예상 공격 시간이 그야말로 수천, 수만 년 이상으로 뻥튀기된다. 그러니 암호라는 건 pass-word가 아니라 최하 phrase나 sentence 정도의 규모로 만드는 게 좋다.

Microsoft Iphone 내지 언어학의 Colorless green ideas sleep furiously처럼 서로 개연성이 없는 생뚱맞은 단어들(저 문장 자체는 절대 쓰지 말 것! ㅋㅋ), 내가 좋아하는 무리수나 엄청 방대한 소수의 x~y째 자리수의 base64 인코딩 등을 섞으면 공격자가 뚫기 대단히 어려운 암호를 만들어 낼 수 있다. 그리고 까먹었더라도 그 암호를 생성하는 공식을 기억하고 있으니 나중에라도 컴퓨터를 돌려 언제든지 다시 만들 수 있다.

그리고 굳이 저런 식으로 머리를 안 굴리더라도, 본인 같은 사람은 직업 특성상 맨날 숫자와 특수문자와 알파벳이 뒤죽박죽 섞인 문자열을 취급하는 게 일이니... 저런 조건을 모두 만족하는 진짜 암호스러운(cryptic) 암호(password)를 의외로 금방 떠올릴 수 있었다.
요즘은 암호 관리자 전용 앱도 많이 나와 있는데, 이런 식으로 암호 생성기가 같이 연계되고 각 포털 사이트별로 암호 변경 주기를 관리도 해 주는 똑똑한 앱이 있으려나 궁금하다.

터치스크린 입력 방식이 시각 장애인에게 악재인 것만큼이나(점자!)..
PC와는 구조적으로 다른 스마트폰의 문자 입력 방식은 무질서도가 높은 암호를 입력하는 데 악재인 것 같다.
작은 화면에서 알파벳, 숫자, 특수문자를 섞어서 수월하게 입력하는 게 압도적으로 불편하고 까다롭기 때문이다.
물론 그 때문에 거기에는 패턴 제스처 같은 다른 암호 입력 방법도 등장했겠지만, 아무래도 문자 입력만치 보안이 강력하지는 못하다.

끝으로 글을 맺으며 든 생각이 있다.
우리말은 엄연히 다른 개념인 password와 encrypt/cryptic이라는 두 의미가 '암호(화)'에 모두 담겨 있다.
이건 어찌 보면 '다른'에 different와 another가 모두 포함돼 있고, 조사 '과/와'에 and뿐만 아니라 with가 섞여 있으며
단순히 시계의 표시 시각이 이르거나 늦은 것까지 다 '빠르다/느리다'로 표현하는 것만큼이나..
일면 좀 부정확하고 어정쩡하게 들린다.

하지만 한국어만 저렇게 한데 싸잡아 표현하는 건 아닌 듯하다.
또한 '암호'는 정보에 대한 접근 가능 여부 자체를 binary로 통제하는 것이고 '암호화'는 정보에 접근했더라도 해독을 못 하게 하는 것인데.
암호화를 해독하기 위한 암호가 있기도 하니, 목표면에서는 굳이 서로 떼어서 생각할 필요가 없는 비슷한 개념인지도 모르니까 말이다.

Posted by 사무엘