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

사용자의 마우스 클릭에 동작하는 GUI 요소들은 일단은 버튼의 down이 아니라 up 시점 때 반응을 한다. 모든 버튼(push, check, radio 공히)이나 하이퍼링크들이 이렇게 동작하며, 우클릭 메뉴도 오른쪽 버튼을 뗐을 때 튀어나온다. 그리고 이 타이밍 때 그 이름도 유명한 BN_CLICKED라는 notify 메시지가 부모 윈도우에 전달된다.

그에 반해, down 때 바로 반응을 하는 것은 스크롤 바나 슬라이더나 스핀(옆의 숫자를 증가시키거나 감소시키는 up-down 컨트롤)처럼 누르고 있는 동안 '연타'의 여지가 있는 버튼, 아니면 어떤 명령이 즉시 실행되는 게 절대로 아님이 보장되는 첫 단계 메뉴(파일, 편집, 보기) 정도로 국한된다.

그런데 이건 어떨까? 버튼인데, 사용자가 누르고 있는 동안만 풍선 도움말이나 다른 추가적인 정보가 튀어나오고, 버튼을 떼면 그것들이 사라진다. down과 up만 감지하면 되고 그 사이에 연타 개념은 없다.
이건 일단 Windows의 표준 컨트롤에는 없는 기능인 듯하다. 하지만 의외로 요런 UI가 쓰인 경우가 존재한다.

가장 먼저 떠오르는 예는 2007 버전이 나오기 전, 과거의 MS Excel이다. 선에 안티앨리어싱이 없는 건 그렇다 치더라도 색깔이 요즘 것에 비해서 우중충하고 덜 예뻐 보인다.

옛날에 엑셀에는 차트 마법사를 통해서 차트를 만들곤 했다. 1단계는 차트의 종류를 고르는 단계였는데, 아래의 길쭉한 버튼을 살포시 누르고 있으면 지금 사용자의 데이터가 어떤 형태의 차트로 표시되는지 preview를 잠시 볼 수 있었다.
버튼을 한번 눌렀다 뗄 때마다 preview 모드와 선택 모드가 toggle 형태로 바뀌는 게 아니라는 점을 주목하자. 상당히 독특한 UI가 아닐 수 없다. 왜 이렇게 만들었을까?

어지간하면 그냥 대화상자의 왼쪽에 차트의 type과 sub-type을 트리 컨트롤 같은 걸로 모두 때려박고, 오른쪽 전체에 preview 화면을 할당해도 될 듯하지만 그렇게 하기에는 오버헤드가 너무 크고, 또 차트의 타입 자체를 그림으로 표시하기 위한 공간도 많이 필요하니 이런 식으로 preview는 필요할 때 잠깐만 볼 수 있게 UI를 만든 듯하다.

참고로 Office 2007과 그 이후부터는 전통적인 차트 마법사가 없어지긴 했지만, 차트의 종류를 선택하는 대화상자 자체는 남아 있다. 단, 이렇게 버튼을 누르고 있는 동안 preview를 잠깐 보는 기능은 없어졌다.

원래 운영체제의 표준 버튼은 아까도 얘기했듯이 눌렀다 뗀 뒤의 BN_CLICKED 이벤트만 있지, 저렇게 눌러진 것에 대한 이벤트는 제공하지 않는다. 그러니 저런 기능을 구현하려면 일반적으로는 윈도우 프로시저를 서브클래싱하여 마우스 좌클릭과 Space/Enter 누름을 감지해서 좀 불편하게 구현해야 한다.
하지만 MS Office 제품 중에 Word와 Excel은 대화상자 컨트롤들을 운영체제 함수 대신 자체 GUI 엔진으로 구현했기 때문에 편법 없이 저런 기능들이 처음부터 자연스럽게 구현이 가능했을 것이다.

그리고 또 다른 예는 아주 최신 프로그램이다. 바로 Internet Explorer 11.

IE는 최신 버전이자 아마 마지막 버전이 될 것으로 보이는 11이 굉장한 쇄신을 한 것 같다. 예전보다야 가벼워지고 속도가 빨라지고, 텍스트 입력란이 TSF A급으로 바뀌고, 굴림체로 찍히던 기본 글꼴이 맑은 고딕으로 바뀌는 등 변화가 많다.

얘는 웹사이트 내부의 입력란에서 ID와 비번을 입력하기 시작했을 때 오른쪽에 자그마한 버튼이 뜬다. ID 입력란의 오른쪽 끝에는 X 버튼이 생겨서 이걸 누르면 ID가 싹 다 지워진다. 물론 지우는 동작은 눌렀다가 '뗐을 때' 행해진다.
그런데, 비번 입력란의 오른쪽에는 눈알 모양의 버튼이 생기며, 이 버튼을 누르고 있으면 동그라미로 표시되는 암호 문자열의 실제 문자열이 잠시 보인다. 이것 역시 마우스 버튼을 떼는 순간 원상복귀된다!

(1) 엑셀의 차트 미리보기와, (2) IE에서 비번 훔쳐보기가 이 동작에 상당히 적절하게 배치된 경우라고 생각된다. peek라는 동작을 표현한다고나 할까. 이것 말고 요런 동작이 유용하게 쓰일 만한 상황이나 이미 적용된 예가 무엇이 있는지 궁금하다.

마우스 포인터를 갖다대고 있는 동안 뭔가 도움말이나 추가 정보가 나타나는 UI는 그리 새삼스러운 물건이 아니다. 이미 20년 전부터 툴팁이라고 불리는 풍선 도움말이 그 역할을 하고 있으니 말이다.
단, 터치스크린에서는 click과 hover가 구분이 없기 때문에 저렇게 가리키고 있는 것을 표현할 수 없으니 누르고 있는 동안만 뭔가 추가 정보를 표시하는 기능이 더욱 필요할 것이다.

이렇게 글을 바로 맺기는 아까우니 MS Office에서만 볼 수 있는 독특한 UI를 두 가지 좀 늘어놓도록 하겠다.

1. 먼저, 탭 컨트롤의 각각에 Alt 액셀러레이터가 붙은 모양이다. 난 워드나 엑셀을 쓸 때마다 늘 신기하다고 생각해 왔다.

Alt 액셀러레이터는 IsDialogMessage라는 대화상자 전용 메시지 처리 함수가 구현해 주는 것이고, Alt는 윈도우 텍스트를 기반으로 한 윈도우당 한 글자씩만 배당된다. 그러므로 저게 정석적으로 가능하려면 각각의 탭 헤더가 마치 라디오 버튼처럼 독립된 윈도우를 구성하고 있어야 하나, 운영체제의 탭 컨트롤은 그런 구조를 하고 있지 않다.

Alt+단축키를 눌렀을 때 탭 컨트롤의 탭이 어떻게든 전환되게 하는 것 자체는 불가능하지 않다. 하지만 그러려면 윈도우 프로시저 수준이 아니라 해당 응용 프로그램의 메시지 loop 차원에다가 예외적인 처리가 필요하다. MFC로 치면 해당 대화상자의 PreTranslateMessage 함수를 굳이 새로 구현해야 한다.
그래서 본인은 MS Office의 저런 프로퍼티 시트 대화상자를 보면 신기하다는 생각이 든다.

2. 그리고, 라디오 버튼을 더블 클릭하면 대화상자가 OK(확인)으로 종료되는 것도 꽤 독특하다.
요즘 Office 프로그램들이야 워낙 기능이 방대하기 때문에 공간을 아끼기 위해 콤보 박스를 주로 쓰지, 라디오 버튼을 보기는 힘들지만.. 대표적으로 '화면 확대'라든가 탭의 종류를 고르는 화면에서 이를 확인할 수 있다.
아.. 그러고 보니 리스트 박스에서 아이템을 더블 클릭했을 때 대화상자가 재량껏 OK로 종료되는 건 생소하지 않다. 하지만 라디오 버튼을...? 한번 생각해 보시기 바란다.

Posted by 사무엘

1. 등산

서울 지하철 4호선의 북쪽 종점인 당고개 역의 주변을 보면 산들이 병풍처럼 둘러싸여 있는 게 참 인상적이다.
기왕 등산을 할 거면 그 산을 한번 올라 보고 싶다는 생각을 진작부터 했다.
결국은 같은 수락산이긴 한데 지난 3월엔 깔딱고개 근처까지 간 반면, 이번엔 귀임봉을 지났으며, '서울 둘레길'을 지나서 7호선 마들 역 근처로 귀환했다.
그리고 예나 지금이나 맥북은 나의 소중한 등산 동반자였다.

2. 중앙선 아신 역

이제 전동차의 운행 계통은 경의선과 중앙선이 통합되어 경의중앙선이라고 불리고 있긴 하지만, 그래도 경의선과 중앙선은 같은 수도권 광역전철임에도 불구하고 주변의 분위기가 아무래도 차이가 있다. 중앙선이 지나는 지역인 양평은 상수도 보호로 인해 태생적으로 개발 제한 봉인이 걸린 곳이 많으며, 개량된 중앙선 역시 강을 가까이 지나는 구간이 있기 때문이다.

여러 풍경 사진 중에서 역시 산과 강을 담은 것만 투척한다. 색감이 예뻐서. 한적한 경춘선이나 중앙선 전철역으로 나가서 코딩이나 독서를 하고 있으면 신선놀음이 따로 없다.

3. 그린벨트 마을 답사

방학+주말을 기념해서 등산만 했느냐 하면, 그렇지는 않고 차 끌고 여기저기 돌아다니기도 했다.

난 예전에도 한번 언급한 바와 같이, 서울 외곽의 야산과 그린벨트 지대 탐험에 대한 로망이 좀 있는 사람이다. 한번은 동부간선 → 지방도 23호선을 타고, 서울 공항 근처의 신촌동과 심곡동 마을을 드디어 밤에 몰래 답사했다. 여기 사는 주민은 어떤 사람들일까? 대대로 여기 살던 선조의 후손? 아니면 겁나게 부자들? 민통선 안에서 농사 짓는 사람들만큼이나 신기하게 느껴진다.
미처 카메라에 담지는 못했지만 전방에서 갑자기 굉음과 함께 거대한 수송기가 활주로에 내려앉는 모습을 보기도 했다. 서울 공항(=공군 기지)이 코앞이니까.

그 뒤 청계산로로 갈아탔다. 자연의 정취가 살아 있는 으슥하고 한적한 도로를 달리면서 대왕 저수지와 신구대학 식물원 일대를 구경했다. 여기는 바깥쪽 차선이 다 자전거 도로로 만들어져 있었다. 요런 데서 차 세워 놓고 혼자 자면 가히 야영 캠핑이 따로 없을 것 같았다.

계속 진행하자 길은 경부 고속도로를 나란히 지나면서 북쪽으로 가기 시작했으며, 말 그대로 청계산 등산로와 신분당선 청계산입구 역이 나왔다. 중간엔 서울 신원동의 새정이마을을 들러서 답사했다.

4. 경기화학선 폐선 부지

양재-서초 IC 사이는 잠깐 경부 고속도로 구간으로 건넜고, 다음으로 본인은 남부순환로를 타고 서울의 서쪽 끝으로 갔다. 남부순환로는 중간에 압박스러운 경사는 그렇다 치고, 중앙에 화단이 쭉 조성돼 있는 게 참 인상적이었다. 서울에서 이런 도로는 여기밖에 없는 듯. 도로 폭이 차선수를 홀수 개로 어정쩡하게밖에 만들 수 없는 규모이기라도 했나 보다.

그리고 본인이 새벽에 간 곳은.. 오류동 역과 푸른수목원의 사이에 있는 경기화학선 폐선 부지였다. 세상에, 주거지 근처에 이렇게 풀이 무성하게 우거진 폐선을 보는 건 옛날 수인선 협궤 폐선 이래로 처음이었다. 게다가 여긴 엄연히 인서울 지대인데! 과연 철덕의 성지 순례 코스가 아닐 수 없었다.

서울 남서쪽 끝까지 먼 길을 찾아가서 철도 답사를 했는데, 여기를 들르지 않고 간다면 그건 철도에 대한 예의가 아니다.
서울 지하철 7호선 천왕 차량기지를 경건한 마음으로 한바퀴 빙 돌면서 성지순례를 했다. 자동차가 있으니 가능한 일이었다. 내가 여기를 직접 가 보는 날이 오는구나!

차량기지 중에는 도봉이나 개화처럼 아예 내부에 역이 있는 것이 있는가 하면(7호선 장암, 9호선 개화 역) 지축, 창동, 구로, 군자, 신내처럼 다른 전철역 근처에서 기지를 그럭저럭 볼 수 있는 것도 있다.
아니면 철도로는 접근을 못 해도 고덕이나 수서나 모란처럼 고속/고속화도로를 달리는 자동차의 차창 밖으로 어렴풋이 볼 수 있는 것도 있다.
하지만 천왕 차량기지는 그 어느 것에도 속하지 않기 때문에 차량기지들 중에 가장 존재감이 없고 접근이 상대적으로 어려운 곳이라고 여겨져 왔다.

여느 차량기지와 마찬가지로 대부분의 구간은 담장과 철조망이 쳐져서 은폐되어 있었지만 그래도 용케 요런 곳을 찾았다. SR001 전동차가 지상에 나와 있는 실물 사진을 건지는 데 성공했다. 허나, 내가 하는 행동은 남이 보기엔 영락없이 국가 기간 시설에서 어슬렁거리면서 무단 촬영이나 하는 수상한 간첩-_-처럼 보였을 듯..

이번 여행을 통해 그린벨트 마을 3군데와 경기화학선 철길, 그리고 천왕 차량기지 답사라는 수확을 거두고 돌아왔다. 자동차는 이런 데 활용하라고 만들어진 편리한 문명의 이기임을 실감했다.

Posted by 사무엘

고전 소프트웨어의 추억을 발굴하는 작업은 변함없이 계속된다.
몇 달 전엔 비트맵 그래픽 에디터 얘기를 했다. 구글링으로도 좀체 정보를 발견할 수 없던 Splash와 Image72를 찾아 냈다. 이어서 오늘은 도스용 셸 유틸리티 얘기를 해 보겠다. 출처를 도저히 알 수 없었던 한 외국산 프로그램의 정체를 또 파악하는 데 성공했기 때문이다.
그것은 이름하여 Packard Bell이다.

옛날 도스 시절엔 부팅이 끝나면 화면에 뜨는 건 시꺼먼 화면에 C:\ 프롬프트가 전부였다. 이런 인터페이스로는 초보자건 전문가건 컴퓨터를 제대로 활용하기가 몹시 불편했기 때문에, 컴퓨터에 존재하는 다른 프로그램들을 빠르고 편하게 실행시켜 주는 '셸'에 해당하는 프로그램이 별도로 여럿 만들어지곤 했다.

전문가를 위해서는 MDIR이나 노턴 커맨더처럼 파일 관리 유틸리티를 겸하는 셸이 쓰였다. 이런 프로그램들은 파일 정보만 표시하면 되니 보통 텍스트 모드에서 실행되었다.
그러나 초보자를 위해, 당시의 Windows 3.0에 준하는 GUI를 표방하면서 알록달록한 아이콘이 나오는 그래픽 셸도 있었다. 골치 아픈 단축키를 외울 필요 없이 마우스 클릭만 하면 원하는 프로그램을 실행할 수 있었다.

MS-DOS 버전 4인가 5부터 제공되었던 '도스셸'은 그래픽 모드에서 실행되는 것도 가능했지만 그래도 전자와 후자 중에서는 전자의 성격에 더 가까운 물건이었다. 그래도 GUI의 불모지인 도스에서 나름 마우스 드래그 드롭을 구현했고, 프로그램의 색상과 화면 모드를 다양하게 바꿀 수 있는 게 인상적이었다.

자, 그 와중에 저 '패커드 벨'이라는 프로그램은 우리 집 컴퓨터에 처음부터 있었던 프로그램은 아니고, 친구 집 컴퓨터에서 접했다. 그런데 GUI가 굉장히 고퀄이고 화면이 예뻤다. 16색 VGA에서 실행되는데 투박한 표준 팔레트를 쓴 게 아니라 보다시피 자체적으로 팔레트 색상을 재정의했으니 더욱 이색적인 느낌이 났다. 색상도 그렇고 글꼴도 그렇고, 알록달록한 아이콘까지, 뭔가 프로그래머가 대충 발로 그린 게 아니라 그래픽 전문가의 손길이 닿은 티가 났다. 어린 시절에 본인은 저렇게 "나만의 세계가 느껴지는 비주얼"을 보면 아주 사족을 못 썼다.

저 스크린샷에서는 안 보이지만, 원래는 마우스 드라이버가 있건 없건 마우스 포인터도 나타난다. 그런데 포인터도 운영체제가 그냥 기본으로 주는 작고 투박한 화살표가 아니라, 무려 살색의 사람 손가락 모양이다. 요즘으로 치면 웹 브라우저에서 링크를 가리킬 때 나타나는 그 마우스 포인터와 비슷하다.
화살표 키를 누르면 지금의 마우스 포인터 위치에서 그 화살표 방향으로 가장 가까이 있는 버튼으로 포인터가 이동하는데, 이것도 즉시 되는 게 아니라 부드럽게 궤적을 그리면서 이동한다. 이런 것까지 세심하게 신경을 썼다.

워드 프로세서나 그래픽 에디터가 아니고, 그렇다고 게임도 아니고.. 자체 한글 같은 것도 필요하지 않는 외국산 도스용 유틸리티가 그래픽 모드에서 가변폭 영문 글꼴 출력까지 구현한 것은 그 당시로서는 몹시 드문 일이었다.
도대체 이 프로그램은 누가 언제 어디서 만들었는지 알고 싶어서 뒤늦게 인터넷을 수소문했지만, 정보를 도저히 얻을 수 없었다.

본인은 이 프로그램의 이름이 Pen Bel(l) Desktop인 것으로 기억하고 있었다. 왕년에 베이직 프로그래머였으니 PB라고 하면 파워베이직의 이니셜이 가장 먼저 떠오르지만, 저 추억의 프로그램의 실행 파일에도 PB라는 문자가 포함되어 있긴 했다. 하지만 저 이름으로는 아무것도 검색이 되지 않았다.

이 프로그램에 대한 결정적인 단서를 얻은 곳은 IE is evil!로 유명한 이 사람의 GUI 갤러리 웹사이트였다.
도스는 말할 것도 없고 Windows 3.1 시절까지만 해도 기존의 허접 구닥다리 '프로그램 관리자'를 대체하는 싸제 셸 유틸이 수요가 있었다. 노턴 데스크톱, 그리고 MS의 흑역사 Bob 같은 프로그램들이 있는데.. 어? Packard Bell 내비게이터라는 프로그램이 있었다.

3.5 버전은 완전히 Bob처럼 그래픽 기반으로 바뀌었지만, 1.1은 보아하니 도스용과 완전히 같지는 않아도 색상과 외형이 웬지 도스용 프로그램과 관계가 있는 것 같다는 생각이 들었다.

튜토리얼, Support, your software처럼 큰 메뉴 구성이 꽤 비슷해 보이는 데다 자음 이니셜이 일치하기도 하니 동일 회사의 프로그램일 거라는 감이 강하게 들었다. 그래서 이 키워드로 구글링을 계속했다.. 그러나 일단 '패커드 벨'은 컴퓨터 제조 회사인지라 걸려 나오는 것은 온통 컴퓨터 사진밖에 없었다.

그랬는데 어느 국내 블로그에서 드디어 월척을 낚는 데 성공했다. 내가 찾던 바로 그 프로그램의 스크린샷이 나온 것이다. 프로그램과 개발사 이름이 동일하게 '패커드 벨'인 듯하다.
이 회사는 소프트웨어가 아닌 하드웨어가 주력 상품이고, 프로그램은 자기 컴퓨터에 번들로 설치되는 것 위주로만 개발한 듯하다. 소프트웨어만 전문으로 만든 게 아닌데도 1991년경에 도스와 Windows용 셸을 모두 그것도 상당히 뛰어난 퀄리티로 만든 것이 무척 대단하게 느껴진다.

그래서 이 도스용 '패커드 벨' 셸은 메뉴 구조가 좀 특이했다. ESC를 누르면 도스셸이나 '로터스 웍스' 같은 붙박이 고정 프로그램이 있고, 'Your software'을 골라야만 아까와 같은 프로그램 아이콘 리스트가 나타났다. 패커드 벨 컴퓨터에는 원래 '로터스 웍스'도 번들로 제공되었던 듯하다.

새로운 프로그램을 등록하는 화면이다. 아이템에 사용할 '아이콘', 밑에 표시할 텍스트, 그리고 실제로 실행할 프로그램 이렇게 세 가지 정보를 서로 다른 화면에서 지정해 줄 수 있다. 아이콘은 저 35종류의 기성 그림 중 하나만 선택할 수 있고 다른 외부 그림 파일을 사용할 수는 없다는 게 특이하고 한편으로는 아쉬운 점이다. 기성 그림들은 각각 어떤 컨셉으로 만든 건지는 잘 모르겠다.

그리고 저 스크린샷에서는 제대로 나타나지 않았지만, 원래 이 프로그램은 하드디스크에 존재하는 모든 실행 파일들을 아래의 리스트에다가 표시해 준다. 그래서 사용자는 일반적인 파일 열기 대화상자를 다룰 때처럼 매번 디렉터리를 오갈 필요 없이 한 목록에서 실행 파일을 곧장 선택할 수 있었다. 이건 사실 MS 도스 셸에도 있던 기능이다. 2~30여 년 전, 한 하드디스크가 크기가 수십~100수십 MB밖에 하지 않던 시절에나 가능했던 일이다.

지금 다시 저 프로그램을 접할 수 있다면 무척 감회가 새롭고 흥미진진할 것 같다.

도스 셸 하니까 생각나는데, 옛날에 MS-DOS 4.0은 우리가 아는 그 4.0만 있는 게 아니라 '멀티태스킹 에디션'이라고 유럽 쪽에서 주로 쓰인 다른 브랜치가 있었다고 한다. 16비트 Windows가 사용하던 New Executable 포맷도 사실은 이때 처음으로 제정되었다고 하고.

또한, 국내에서 개발된 그래픽 위주 도스 셸로는 먼 옛날(1993년쯤) 이 종하 씨가 개발한 '능금'이라는 프로그램도 있었다. 옛날에는 '파란연필'이라는 텍스트 에디터도 개발했던 분인데 본인은 요것들은 옛날 컴퓨터에서 다 직접 써 봤다.
'능금'은 셰어웨어였으며, 비등록 공개판은 등록할 수 있는 그룹과 프로그램 개수에 제한이 걸려 있었다.

그래픽 셸로서 '능금'이 지닌 가장 독특한 점은.. 한 아이템에 대한 아이콘을 최대 5개까지 연달아 지정해서 초보적인 수준의 '움짤'을 만들 수가 있다는 점이었다. 물론 외부 파일 사용 가능함. 저 스크린샷을 보면 '그래픽'의 경우 물결이 출렁거렸고, '게임'은 테트리스 블록이 내려가는 모습이 반복되곤 했다.
그래도 '능금'의 기본 팔레트 화면과 저 아이콘들은 '패커드 벨'에 비하면 좀 아마추어 같은 느낌이 들긴 한다. ^^

Posted by 사무엘

1. 하수도 시설

사람이 사는 환경에서 배설물의 처리는 생각보다 굉장히 골치 아프면서 결코 무시할 수 없는 중요한 문제이다.

오늘날과 같은 위생적인 상하수도 인프라가 없던 시절엔 정말 말도 못 할 정도로 상황이 열악했다. 건물들로 가득한 도시에서는 농촌과는 달리 퇴비로 활용할 수도 없으니, 오물을 그냥 바로 길거리에다 버렸다고 한다. 그럼 길거리는 대변 썩는 냄새로 진동하고 온갖 해충과 불결한 동물들이 들끓었으니 전염병이 돌기도 딱 좋았다. 길거리에서 똥을 안 밟으려고 하이힐이 만들어졌고, 구린내를 가리려고 향수가 발명되었다니 그 시절을 생각하면 무섭기까지 하다.

닥치고 기름 끼얹고 불태워 버리면 악취는 좀 줄어들지 않으려나 싶지만, 갓 배출된 대변은 수분이 상당히 많은 물질이어서 소각하기가 쉽지 않을 것이다. 또한 매번 그렇게 처분하기엔 비용도 많이 들고 이산화탄소-_- 배출 측면에서도 별로 좋을 것 같지 않다.

잘은 모르겠지만 다른 동물보다도 사람의 X이 유난히 더 독하고 구리다고 어디서 들은 것 같다. 성경에서도 이 점이 감안되어, 에스겔이 징징대자 하나님이 인분 대신 소똥을 말려서 연료로 쓰라고 대체제를 제안하신 장면이 나오는 게 아닐까? (겔 4:12-15)
또한 같은 인분이어도 요즘은 경제적으로 풍요로워지면서 육식 섭취가 늘면서 단백질 때문에 더 구려지기도 하지 않았나 싶다. 지금 이 문단에 나오는 말들은 다 개인적인 추측임을 밝힌다.

우리나라도 조선 구한말 때 한양에 인구가 크게 늘었을 때는 인구 대비 도시 기반 시설이 너무 열악했던 관계로 길거리에 굴러다니는 오물이 심각한 수준이었다고 한다. 조선이 미개하고 일제에 의해 망해도 할 말 없는 개막장이었다는 것을 강조하는 진영에서는 이런 사진도 제시하는 모양이다. 길바닥에 굴러다니는 붉은 원이 전부 X이라고 한다. 노면전차가 다닐 정도로 사대문 안의 최대 번화가인데도!

그리고 21세기까지 지구상에 존속하고 있는 최악의 생지옥인 북한에서는 다른 깡촌도 아니고 평양의 상류층 아파트에서까지 안습한 일이 벌어지고 있다고 전에 한번 얘기한 바 있다.
수돗물과 전기, 가스 따위가 제대로 공급되지 않아서 겨울에 이불 뒤집어쓰고 냉방으로 지내는 건 차라리 양반. 수십 층 위에서 노인들은 집 밖으로 나오질 못하고(계단!), 게다가 수세식 변기도 물을 내릴 수가 없어서 신문지 위에다 응가를 본 뒤 오물을 밤에 몰래 베란다에서 아래로 투척한다.

그런 짓을 하지 말라고 감시를 해도 주변에 남조선처럼 가로등 불빛이 있나, CCTV가 있나, 그 암흑천지 속에서 누가 몰래 갑자기 투척하는 걸 잡아 내는 건 불가능하다. 그게 크기가 아주 큰 것도 아니고..
그러니 매일 아파트 근처 바닥에 철퍼덕 떨어진 똥을 치우는 사람들이 고역이라고 한다. 심지어는 밤에 길을 지나가다가 똥벼락을 맞는 사람도 있다. 밤에는 아파트 근처에는 접근을 안 하는 게 상책이다.

우리나라는 그 정도까지 막장은 아니지만 철도 차량이 1980년대까지만 해도 대소변이 그대로 선로 밖으로 떨어져 나가는 '비산식 화장실' 객차가 다니곤 했다. 물론 지금은 그런 미개한 객차는 전국에서 완전히 자취를 감춘 지 20년 가까이 됐지만 말이다.

2. 극지와 험지, 특수한 직업

이런 상하수도 시설과는 별개로, 직업적으로 제때에 화장실에 갈 수가 없는 사람들이 있다. 가장 가깝게는 화장실이 없는 교통수단을 운전하는 택시/버스 운전사나 지하철 기관사이다. 지하철 기관사의 경우, 정말 급할 때는 소변 정도는 섬식 승강장역에 정차했을 때 승강장 쪽이 아닌 벽 쪽 문을 열고 몰래 처리하기도 했다고 한다.

여객기가 아닌 전투기 조종사는 장시간 임무를 수행해야 할 경우 별 수 없다. 기저귀를 챙긴다고 한다.

성경에도 지금으로 치면 야전에서 싸우는 육군 보병에게 적용되는 말이 있다. 필드에서 볼일을 보고 나면 삽으로 흙을 파서 오물을 잘~ 덮어서 은폐를 하라고(신 23:12-14) 말이다. 마치 옷을 입어서 신체의 부끄러운 곳을 가리듯, 더러운 배설물도 안 보이게 잘 가려 놓으면 하나님이 전쟁 중에 복을 주실 거라고까지 약속했다. 의외로 이런 시시콜콜한 얘기가 모세 율법에 기록돼 있다.

옛날에 아문센과 스콧 시절에는 어떠했는지 모르겠지만, 남극 조약까지 다 체결된 지금 남극을 탐험하는 팀은 사람이 안 사는 곳이라고 해서 주변에 무단 방뇨· 방변을 해서는 안 된다. 모든 인원의 배설물은 고이 회수해서 정화 처리를 한 후, 남극의 밖에다 버려야 한다. 쓰레기는 말할 것도 없고 인체의 생리 현상으로도 주변을 오염시키지 않아야 한다는 국제 협정이 맺어져 있기 때문이다.

과거에 달 포함 우주에 갔다 온 사람들도 자기 배설물을 감히 지구 밖으로 방출하지 않았다. 단, 이와 관련해서 황당하지만 마냥 웃을 수만도 없는 안습한 사건이 1969년 5월 말에 발사된 아폴로 10호 미션 때 있었다.

아폴로 10호는 달에 최초로 착륙을 한 11호의 직전 미션이었다. 달의 궤도에 진입하여 사령선과 착륙선이 분리를 하고, 착륙선이 달 표면 기준 15.6km 고도의 상공까지 내려갔다가 도로 사령선으로 합류한 뒤 지구로 돌아왔다.

달 탐사 우주선은 우주 정거장이 아니며, 화장실을 따로 만들 공간이 없다. 사람이 재량껏 엉덩이에다 봉지를 요강 삼아서 오물을 잘 담아야 한다.; 그런데... 사령선 안에서 누군가가 대변을 보는데 뒷처리를 제대로 못 한 모양이었다. 그래서 주인을 알 수 없는 똥이 그 좁은 우주선 안의 무중력 공간에서 둥둥 떠 다니는 참극(...ㅠ.ㅠ)이 벌어졌다!

승무원들 3명이 모두 자기가 싼 똥이 아니라고 주장하는 대화 내용이 고스란히 녹음되고 문서로 기록됐고=_=;;, 그게 수십년 뒤에 비밀이 풀려서 일반인에게까지 공개됐다. 예기치 않게 실수로 초대형 민폐를 끼친 당사자만이 그 똥이 누구 똥인지에 대한 진실을 죽을 때까지 혼자 간직하다 갈 것이다. =_=;;;

착륙선의 분리는 없이 최초로 달을 돌고 오는 것까지 성공했던 아폴로 8호 미션(1968년 크리스마스) 때는.. 창세기 1장 낭독 애드립이 있었다. 그 뒤 10호 미션 때는 저런 똥 해프닝이 있었다는 점이 흥미롭다.

3. 저격수 비유

본인은 예전에 군대에서의 전문직인 전투기 조종사와 저격수를 비교하는 글을 쓴 적이 있었다.
저격수의 경우 총만 기가 막히게 잘 쏜다고 해서 되는 게 아니다. 혼자 몰래 잠입해서 임무를 수행한다는 특성상 간첩, 무장공비, 공작원과 같은 성격도 지닌다.

이런 배경으로 인해 저격수는 수풀 속에서 위장을 한 후 목표물이 나타날 때까지 꼼짝도 안 하고 근성으로 기다리는 훈련을 한다. 공작원이 적진에서 비트를 파고 잠복하는 것과 비슷하다. 위장을 잘 하면 적군들이 자기 위를 밟고 지나가기도 한다.
그런데 그 긴 시간 동안 정말로 꼼짝도 안 하고 있을까? 밥과 물은 안 먹는다 쳐도 대소변은 어떻게 처리해야 할까?

지난 2011년 9월에는 MBC 시사매거진 2580에서 저격수 특수부대를 취재한 적이 있었다.

이런 게 인생이고 현실이며 실전이다. 현실의 전쟁은 스타크래프트가 아니며 저런 임무에도 간지 나고 아름다운 모습만 있는 게 아니다.
머뭇머뭇 쭈뼛거리면서 "정말 어려울 경우에는... 어쩔 수 없습니다..."라고 대답하는 저격수의 속사정은 무엇일까?

별 수 없다. 도저히 어쩔 수 없으면 결국은 바지에다 싼다는 얘기다.
그런 것까지 대비해서 저격수 훈련 중에 기저귀까지 미리 지급해 주는지는 난 모르겠지만, 결국 대놓고 직접 얘기를 안 할 뿐이지 뻔한 결말인 것이다.

자기 입으로 직접 말하기는 민망하지만, 직접 말 안 해도 결국 그 말이 그 말인 사례는.. 성경에도 많다.

• 가인은 누구와 결혼했는가? (여동생 중 하나와 결혼했다. 그 시절엔 근친 결혼이 이상한 짓이 아니었으니까.)
• 함은 술 취해 잠든 아버지 노아에게 무슨 짓을 했는가? (검열삭제를 했다)
• 입다는 자기 딸에게 결국 무슨 행동을 했는가? (결국 딸을 이삭 죽이듯이 죽였다)
• 6일 창조가 있기 전에 이전 세상에 무슨 일이 있었는가? (물의 넘침으로 멸망했다)
• 노아의 홍수 이전에 하나님의 아들들이 사람의 딸에게 무슨 짓을 했는가? (유전자가 교란된 반신반인 괴생명체가 태어나게 되는 짓을 함)
• 민수기 24장과 25장 사이에 발람이 무슨 짓을 했는가? (차마 입에 담을 수 없는 비열한 방법으로 하나님의 성품을 역이용해 이스라엘 백성들을 실족시켰다)

"에이, 저 멋진 정예 군인인 저격수가 바지에 똥을 쌀 리가 없어. 저건 문자적인 배설물이 아닐 거야, / 문자적인 3박 4일이 아닐 거야" 이런 반응을 할 게 아니라면, 성경에 기록된 엄연한 사건을 문자적으로 믿지 못할 이유는 없을 것이다. 하나님의 입장에서도 민망해서 굳이 일일이 디테일을 기록할 필요가 없고 정황상 안 봐도 뻔하니 간접적으로 기록을 해 놓은 것이다.

이상. 성경을 읽고 내용을 믿는 태도에 대해서 얘기하기 위해서 먼저 똥 얘기부터 장황하게 늘어놓게 되었다. ^^

Posted by 사무엘

코딩으로 먹고 사는 프로그래머 내지 소프트웨어 개발자에게 필요한 것은 단순히 새로운 코드를 스스로 잘 작성하는 능력뿐만이 아니라, 문제가 생겼을 때 디버깅을 잘 하고 남이 만들어 놓은 코드를 신속하게 읽고 분석하는 능력이다. 아니, 업계에서는 어찌 보면 후자가 전자 이상으로 더 중요한지도 모른다. 왜냐하면 오늘날은 뭔가 완전히 새로운 솔루션을 천재 프로그래머 한 명에서 밑바닥부터 새로 만들어 낼 일은 거의 없어졌기 때문이다.

나의 영원한 친구는 비주얼 C++이고, 비주얼 C++ IDE는 예로부터 굉장히 편리한 디버깅 기능을 제공해 왔다. (일례로 Shift+F5는 엉덩국 홍콩행 C언어 병맛 만화에도 나올 정도로 유명한 비주얼 C++ 단축키이다. 디버그 중단 =_=)
특히 IDE가 32비트임에도 불구하고 64비트 프로세스를 아주 seamless하게 디버깅 해 내는 건 아무리 생각해도 대단해 보인다. 물론 이를 구현하기 위해 내부적으로는 64비트 디버그 서버 프로세스를 따로 만들고, 걔가 IDE와 디버기 프로그램 사이를 중재하고 있긴 하다. 그렇게 하는 것 말고는 기술적으로 다른 방법이 없다.

다만, 여러 편리한 기능에도 불구하고 본인이 일말의 아쉬움을 느끼는 점들을 나열하자면 다음과 같다.

1.
소스 코드에서 breakpoint를 여러 곳에 지정해 놓고서
한 breakpoint(A)가 적중한 뒤부터 다른 쪽 breakpoint(B)를 지났을 때 프로그램이 멈추게 하는 게 지원됐으면 좋겠다.

디버깅을 하고자 하는 지점이 평소에도 자주 지나는 곳이긴 하지만, 특정 조건이 만족된 뒤부터 실제로 의미를 갖는다는 뜻이다.
이런 상황에 대비해서 n회 이상 적중했을 때 멈춤, 특정 변수값이 변했을 때 멈춤 같은 여러 breakpoint 옵션이 있긴 하지만..
다른 breakpoint의 hit에 의존하여 그 뒤부터 멈추게 하는 기능은 Visual C++에서 지금까지 못 본 것 같다. 이거 회사일을 할 때와 <날개셋> 개발 중에 자주 필요성을 느꼈다.

IDE 내지 디버거가 이런 기능을 지원 안 해 주면 결국 사람이 해당 기능을 직접 코드에다 써 넣어야 한다.
bool 타입의 전역변수(bkpoint)를 하나 만든 뒤 A에 해당하는 지점에서는 bkpoint=true를 지정하고,
B에 해당하는 지점에서는 extern bkpoint; if(bkpoint) DebugBreak() 를 호출하는 식이다.
이런 긴급/땜빵 코드를 집어넣을 때는 굳이 클래스 따위 생각할 필요 없이 global scope이 존재하는 C/C++이 편리하게 느껴진다.

하지만 조건을 지정하는 코드와 멈추는 코드가 서로 다른 모듈에 있는 경우(static LIB, DLL, EXE 등) 여러 모듈을 고쳐서 재빌드해야 하고 일이 골치아파진다. 그러니 코드를 건드릴 필요 없이 이런 기능 정도는 개발툴이 바로 지원해 주는 게 속 편하다.

사실, 이런 쪽의 기능이 계속 추가되다 보면 디버거도 전처리기나 빌드 시스템처럼 일종의 프로그래밍 가능한 독자적인 시스템이 될지도 모르겠다. 사실은 <날개셋> 한글 입력기의 개발에서는 todo list를 분류하고 체계화하는 것부터가 전략이고 프로그래밍이다.

2.
디버그 로그를 찍는 API 함수는 OutputDebugString이며, 얘는 문자열을 받아들이는 여느 함수들과 마찬가지로 W 버전과 A 버전이 있다. 그러나 얘는 실제로는 오늘날의 NT 계열 운영체제에서도 유니코드를 지원하지 않는다.
다른 함수들은 A 버전이 문자열을 변환한 후 W 버전을 호출하는 형태이지만, 이 함수는 뜻밖에도 W 버전이 문자열을 변환한 후 내부적으로 A 버전을 호출한다.

물론 99%에 가까운 상황에서 프로그래머가 필요로 하는 로그 문자열은 단순히 알파벳과 숫자만으로 이뤄져 있어도 하등 지장이 없으며 충분하다. 그러나 본인처럼 문자 입력기 내지 마이너한 유니코드 문자/글꼴 쪽을 종종 연구하는 입장에서는.. 그런 문자열을 디버거로 곧장 확인할 수가 없어서 불편을 겪은 적이 생각보다 자주 있었다.

디버거 쪽이 여전히 1바이트 문자열 기반 프로토콜이 관행이어서 유니코드를 도입할 수 없다는 말도 변명에 지나지 않는다. 그런 용도로 쓰라고 엄연히 utf8이라는 물건이 있기 때문이다. 소프트웨어 국제화의 혜택이 사용자 인터페이스뿐만이 아니라 이런 데에까지 도달해야 하지 않을지?
직접 확인해 보지는 않았지만 C++말고 C#이나 자바는 디버그 로그가 유니코드를 지원 안 할 리가 없으리라고 생각한다.

3.
최신 201x 버전에서도 가끔은 프로젝트를 빌드하는 데 쓰였던 멀쩡한 소스 파일이 디버거에서 인식이 안 되는 경우가 가끔 있다. F9를 눌러도 해당 라인엔 빈 동그라미○만 생기지 breakpoint가 성공적으로 만들어졌음을 의미하는 ●가 생기지 않는다.
DebugBreak()를 손수 집어넣어서 강제로 세우더라도 그 지점에서 call stack 리스트가 제대로 생성돼 있지 않다. 또한 breakpoint는 만들어지지만 심벌 테이블이 좀 맛이 갔는지 변수값 조회가 동작하지 않을 때도 있다.

본인은 이 현상에 대해 정확한 문제 재연 조건과 원인, 해결 내지 예방 방법을 아직도 정확히 모른다. 프로젝트 전체를 재빌드하고 Visual C++ IDE를 재시작하고 나면 해결되기도 하고 안 그럴 때도 있었던 것 같다. VC++ 6의 고질병이던 허접 인텔리센스 ncb가 깨지는 문제는 오늘날 더 볼 일이 없지만, 디버깅은 여전히 완벽하지 못하다.

그러고 보니 디버그 심벌 데이터베이스는 IDE의 인텔리센스 데이터베이스와는 커버하는 영역이 정확하게 같을 수가 없겠다는 생각이 들었다. 전자는 우리 프로젝트 밖에서 빌드되어 LIB, DLL들에 존재하는 소스 코드와 그쪽 심벌까지 모두 연계해서 동작해야 하기 때문이다. (인텔리센스 정보가 없는 곳)

4.
이 외에도,
함수 안으로 들어가긴 하는데(F11), 그 함수의 인자와 관련된 함수 호출들은 모두 무정차로 건너뛰고서 들어가는 step in이 있었으면 좋겠다. 즉, A(b(), c()) 줄에서 시작한다면 b()나 c()로 들어가는 게 아니라 바로 A()의 몸체로 들어간다는 뜻이다.

그리고 디버깅과 직접적인 관계는 없지만, 텍스트를 검색하는데 주석 내용은 빼고 검색하거나 주석에서만 검색하는 기능도 있으면 좋겠다. #if 0과는 달리 주석 영역을 파악하는 건 단순 텍스트 패턴 매칭이므로 그리 어렵지 않을 것이다.

Posted by 사무엘

1. 들어가는 말

이번 학기도 다 끝나고 여름방학이 시작됐다. 이젠 코스웍이 한 학기밖에 안 남았고, 슬슬 종합 시험과 학술지 논문 등 길고 긴 연구 모드로 들어갈 준비를 해야 한다.
그런데 아직 기말 과제가 다 안 끝났을 때, 방학이 되길 벼르고 벼르면서 타는 목마름으로 할것들을 적어 놓은 게 이미 한 트럭인지라, 방학이 된 뒤에도 별로 방학 같은 느낌이 안 든다.

이게 무슨 상황이냐 하면, 월급날이 돌아와 봤자 카드 명세서와 저축, 집 대출 이자 내지 자동차 구입 할부 등의 비소비 지출들이 한바탕 raid를 벌이고 나면, 여전히 가난한 것과 완전히 똑같다.

알람 안 맞추고 좀 원없이 자 보고 싶다.
하루에 최하 8시간 이상, "너무 자서 골병 들 거 같다. 이제 좀 그만 자야지" 생각이 들 때까지 자고 싶다.
코딩 노예 계약서를 화형에 처하고 싶다.
차 끌고 전국일주 여행 좀 가고 싶다. 그리고 여친도 좀 사귀고 싶다. -_-;;

내가 도대체 무슨 부귀영화를 바라고서 이 나이까지 이 짓을 하고 있나.. 그냥 빨리 돈 벌고 안정적으로 살려면 스펙 관리해서 코레일이나 철도 시설 공단에나 들어가면 되지 싶은 자괴감이 들긴 하지만,
뭐 어쨌듯 이런 와중에 <날개셋> 한글 입력기 8.0이 완성됐다. 그 다음 버전(8.x)까지 빨랑 다 만들어 버리고 완성된 모습을 좀 보고 싶다.

이번 8.0은 리팩터링 내지 내부 완성도 강화 작업이 많아서 readme에다가는 쓸 게 적은 편이었다. 하지만 내부적으로는 0.1을 능가하는 분량의 변화가 있었다.
지난 5월에 이미 언급했듯이 편집기에서 한글 정규화 규칙 강화, 수식의 상수에 원형 보존이라는 굵직한 변화가 있었으며, 또 '초성 지향 두벌식', 글쇠누름 날개셋문자 기능과 관련해서 조합 종료 처리가 불완전하던 것을 보강했다.

사소한 것으로는 한글 조합 중에 아무 자모 없이 H2, H3, H2J 이런 날개셋문자만 달랑 넘겨 준 경우 지금까지는 그냥 아무 일 없었다는 듯이 무시만 당했지만, 지금은 입력 중인 한글의 종류를 그걸로 변경되게 했다. 이것 말고도 아주 마이크로한 부분에서 프로그램의 완성도를 높이고 소스 코드 구조를 개선하는 작업들은 가시적인 작업 성과에 비해 난이도가 무척 높았다.

또한 도움말과 프로그램 소개 페이지에 있는 스크린샷들을 싹 다 최신 버전 기준으로, 특히 외형도 Windows 8 모양으로 교체했다. 알다시피 Windows 8이 비주얼이 더 단순하고 빈약한 덕분에 같은 화면이어도 스크린샷의 크기가 더 작아졌다. 이로 인해 도움말 크기가 몇만 바이트 감소하고, 프로그램 전체의 배포 패키지 크기도 아주 약간 더 작아졌다. 프로그램은 덩치가 조금 더 커졌는데도 말이다. 예기치 못한 긍정적인 효과이다.
이런 식으로 사소한 것들이 쌓이고 쌓였다는 뜻이다. <날개셋> 한글 입력기는 개발 15년째인 아직까지도 매 새 버전마다 새로운 역사를 쓰고 있다.

2. 입력 패드에 키보드 입력 모드 추가

이런 것 이후에 이번 <날개셋> 한글 입력기 8.0에서 추가된 큰 기능은..
편집기와 외부 모듈에 이어 제3의 구현체이던 입력 패드가 드디어 키보드 입력이 가능해졌다는 점이다.
Windows에서 정식 IME가 아닌 EXE 형태의 프로그램이 다른 프로그램에서 키보드 입력으로 한글을 입력해 넣는 게 가능해졌다.

입력 패드는 5.3버전에서 첫 도입된 이래로 약 6년 동안 마우스를 이용한 '입력 도구'의 구동만 가능한 반쪽짜리 구현체였다. 키보드까지 지원하는 것은 기술적인 난관 내지 구현 가성비 등을 감안했을 때 보류되어 있었고 연구 우선순위도 별로 높지 않은 상태였다. 당장 이번 8.0에서도 처음엔 딱히 고려 대상이 아니었는데...

그러나 화면 키보드에 '눌린 글쇠 표시'기능을 넣는 과정에서 입력 도구에도 키보드 입력을 연계하는 기능이 7.9와 8.0의 개발 과정에서 자연스럽게 구현되었다. 어떤 글쇠가 눌렸다는 통지를 받고, 원한다면 이 키 입력을 입력 도구가 가로채어 먹을 수도 있는 것이다.
그러니 아예 키보드 입력을 지원하는 것도 이 작업의 연장선 차원에서 지원 가능하겠다는 생각과 함께 불현듯이 개발이 진행되었다.

그냥 입력 패드를 실행하면 딱히 변화가 없다. 그러나 트레이를 우클릭해서 메뉴를 열면 "키보드 입력 사용"이라는 메뉴가 추가되어 있다. 이걸 선택해서 체크하면 키보드 입력이 가능해진다.

단, 입력 패드는 운영체제 IME가 동작하지 않는 틈을 타서 동작하며, 이미 제도권에서 돌아가고 있는 운영체제 IME를 대체하거나 그 동작을 바꾸지는 않는다. 운영체제 IME가 '영문 반자'로 켜져는 있으되 동작은 안 하는 상태여야 한다. 걔가 한글 모드일 때는 본 프로그램은 아무 동작도 하지 않는다. 또한 운영체제 IME가 자기 입력 모드를 바꿀 때 사용하는 한영 글쇠 같은 것도 가로채지 못하므로 Shift+Space나 우클릭 메뉴처럼 다른 전환 글쇠를 배당해야 한다.

또한 마우스만 지원하던 예전부터 마찬가지이긴 했지만, 입력 패드가 제공하는 입력 기능은 데스크톱 GUI 환경 전용이다. 명령 프롬프트나 Windows 8 이상의 메트로 UI에서는 동작하지 않는다. 거기서는 정식 외부 모듈만을 써야 한다.

입력 패드가 제공하는 입력 프로토콜의 수준은 TSF A급이 아니다. 조합을 만들고 완성된 문자열을 내보내는 것만 가능할 뿐, 조합이 끝난 인접 문자열을 알아 오거나 고칠 수는 없다.
입력 패드가 TSF를 지원하는 프로그램에서 TSF A급으로 동작하는 것은 이번 8.0의 개발 작업을 통해 기술적으로 '불가능한 건' 아님을 확인했다. 하지만 구현하는 오버헤드가 굉장히 크며, 편집기와 외부 모듈이 있는 상황에서 입력 패드가 굳이 그것까지 지원할 필요는 없다고 여겨져서 미지원 상태로 남겨 뒀다.
따라서 편집기는 전용 프로그램이다 보니 언제나 A급이 보장되고, 외부 모듈은 어느 프로그램에서 동작하느냐에 따라 A/B급이 유동적으로 바뀌는 한편, 입력 패드는 간편하게 동작한다는 특성상 언제나 B급이라는 차이가 존재한다.

끝으로, 편집기나 외부 모듈과는 달리 입력 패드는 한자 변환을 아직 지원하지 않고 있다. 키보드 입력이 지원되기 시작했기 때문에 앞으로는 이 한계가 이제 더욱 부각되어 보일 것이다.
이 역시 기술적으로 불가능한 건 아니고 단순히 해당 UI가 시간 부족-_-으로 인해 구현되지 않아서 지원되지 않은 것이다. 입력 패드에서 글자 조합 중에 한자/후보 변환을 시도하면 "해당 기능은 아직 지원되지 않습니다"라는 풍선 도움말이 뜬다.

3. 타자연습

타자연습은 프로그램에 변경 사항은 없으며 이번 입력기 8.0 버전도 예전의 7.9와 마찬가지로 타자연습 3.41하고 API가 호환된다. 그러므로 타자연습을 굳이 또 다시 받아서 설치하지는 않아도 된다. 다만, 이번에는 3.41을 다시 올리면서 연습글에다 "세스코 질문 답변 모음"을 추가했다.

"나는 바퀴벌레 제 1군단 장군이다. 우리는 너희 세스코를 적으로 간주하며 오는 12월 25일 크리스마스 선물로 너희 세스코 본사를 대대적으로 공격할 것이다." 뭐 이런 문장으로 연습을 할 수 있다.
'퀴'는 세벌식에서 치기 어려운 축에 드는 글자이니 연습 효과도 상대적으로 클 것으로 기대된다.;;
이 때문인지, 어지간한 연습글들은 분석해 보면 4단의 사용 빈도가 3~5%대인 반면, 세스코 글은 6%가량 된다. ^^

엔하위키(지금은 이름이 '나무'로 바뀌었지만)나 각종 인터넷 카페에서 <날개셋> 타자연습 프로그램에 대한 소개를 해 놓은 걸 보면 김 성모 유행어와 각종 인터넷 유행어가 연습글로 들어있는 게 역시나 반응이 아주 좋다. 이제는 시간이 너무 흘러서 그것조차도 유행이 다 지나려 하긴 한다만..
세스코도 비슷한 맥락으로 재미있는 연습글 역할을 할 수 있을 것이다.

4. 후속 과제

7.9에서 8.0은 지난번 7.7에서 7.9로 올라갈 때만치 양적 성장은 없지만 추가된 소수의 기능들이 제각각 매우 중요하고 여파가 크다. 버전에서 소수점이 아닌 1자리 숫자의 변화와 같이 일어나기에 적절한 것들이다.

사실은 이번 8.0에서는 최종 변환 규칙의 동작 방식을 변경하고, IME 관련 이벤트를 정형화해서 "변경된 글자판을 cursor 근처에다 잠시 표시해 주는 입력 패드"도 추가하려고 했다. 그러나 이것은 입력 패드의 키보드 입력 기능을 구현하느라 뒷전으로 밀려서 다음 버전의 과제로 남게 됐다.

사실, 입력 패드는 현재의 글쇠배열을 표시하는 UI가 어디에도 존재하지 않는다. 시스템 트레이의 아이콘을 가리키고 있어야만 툴팁으로 나온다. 그러니 입력 패드를 쓰고 있을 때는 저 UI가 더욱 필요할 텐데 시간 관계상 8.0에서 다 반영되지 못했다. 3개월 정도 시간이 지났고 이미 0.1 이상의 충분한 작업량이 쌓였으며, 7.9에 꽤 어이없는 버그가 있기도 하기 때문에 새 버전의 공개를 지금 시점보다 더 미룰 수는 없었다.

그러니 굳이 많은 기능들을 사용하는 헤비 유저가 아니더라도 이 글을 보시는 7.9 사용자라면 8.0으로 빠짐없이 업그레이드를 하고, 한번 입력 패드도 사용해 보시기 바란다.
생각 같으면 한 배포 패키지에서 32비트와 64비트별로 파일이 알아서 설치가 되고 편집기/외부 모듈/입력 패드 구현체들 중 사용자가 원하는 것만 선택해서 설치하는 옵션도 넣고 싶긴 하다.

과연 다음 버전 8.1이나 8.2는 신규 모아치기/동시치기 엔진까지 포함해 <날개셋> 한글 입력기의 종결자 버전이 될 수 있을까? 그건 나도 모른다. to be continued일 뿐..! 그래도 1년 전에 비해 task list가 눈에 띄게 가벼워진 것을 보면 감회가 새롭다. 느리긴 해도 노예 계약은 추가되는 것보다 이행되는 게 더 많으며, 꾸준히 청산하고 있는 중이다.

* 여담 1: 한중일 IME들의 제어판 UI의 구조

잘 알다시피 Windows에서 문자 입력을 위해 단순히 운영체제의 기성 코드 + 데이터 차원의 variant가 아니라 아예 제3자가 만든 IME라는 별도의 프로그램이 쓰이는 언어는 한국어(한글), 일본어, 중국어 간체, 그리고 중국어 번체 이렇게 4개이다.
그런데 Window에 내장돼 있는 중국어나 일본어 IME에서 환경설정 대화상자를 열면 그건 IME 프로그램 내부가 아니라 별도의 EXE 프로그램이 실행되는 형태로 열린다. 그 대화상자가 떠 있는 상태에서 예전에 글자를 입력하던 창으로 돌아가는 것도 가능하다.

환경설정뿐만 아니라 보조 입력 도구를 꺼내는 것도 IMEPADSV처럼 한중일 IME들이 한데 공유하는 별도의 프로그램을 써서 하며, 도움말도 통상적인 HtmlHelp API를 쓰는 게 아니라 HH 프로그램을 별도로 띄우는 방식으로 동작한다.
IME들은 자기가 돌아가는 프로세스에 끼치는 영향을 최소화하려고 의도적으로 그렇게 만들어진 것 같다. 뭔가 복잡한 GUI를 띄워야겠다 싶은 건 in-process로 구동하는 걸 기피한다.

내 프로그램의 경우 제어판은 규모가 상당히 크긴 하지만 그냥 in-process에서 modal 대화상자 형태로 돌아가며, 편집기나 입력 패드 같은 독립적인 구현체들 단위로 별도의 EXE가 만들어져 있지, 중간의 구성요소가 또 EXE이지는 않다. 쉽게 말해 <날개셋> 제어판이 그 자체가 독립적인 EXE로 존재하지는 않는다는 뜻이다.

MS 한글 IME는 운영체제의 제어판이 아닌 자기 자신만의 독자적인 UI에 환경설정을 꺼내는 명령이 아예 존재하지 않아서 두벌/세벌 전환조차도 하기가 불편하다. TSF가 도입되기 전, Windows 98~ME 시절에는 자기 도구모음줄을 우클릭해서 글자판을 아주 간편하게 바꿀 수 있었는데 그런 기능이 없어졌다.

* 여담 2: Windows 8.1의 MS 한글 IME

Windows 8때까지만 해도 이런 게 없었는데 난 이걸 비교적 늦게 발견했다.
8.1의 메트로 UI에서 MS 한글 IME로 한글을 입력하다가 글자를 지워 보면, 연달아 입력하던 단어까지는 계속해서 자모 단위로 지워지다가 그 뒤부터 글자 단위로 지워진다. 오, 신기한 기능이 추가됐다. 사실 이렇게 동작하는 게 일반적으로 훨씬 낫다. <날개셋> 한글 입력기의 경우 2년 전 버전 7.1에서 비슷한 옵션이 처음으로 추가되었다.

단어 전체를 조합으로 잡는지, 아니면 실시간으로 앞 글자를 얻어 오는지는 잘 모르겠지만, 세벌식에서 받침 ㄶ을 한 타로 바로 입력했는지 ㄴ+ㅎ로 입력했는지를 다 정확하게 기억하는 걸로 봐서는 아마 전자인 것 같다.

Posted by 사무엘

컴퓨터로 뭔가 input을 받아들여서 output을 내는 나만의 프로그램을 개발한다면, 그 결과물이 단순히 화면으로만 잠깐 나타났다가 사라지는 걸 원하지는 않을 것이다. 꼭 프린터로 출력까지는 아니더라도 파일로 저장하여 사용자의 컴퓨터에 (반)영구적으로 남는 정도는 가능해야 할 것이다.

일반적인 텍스트/그림 파일뿐만이 아니라 내 프로그램만이 인식할 수 있는 고유한 파일 포맷을 제정하고, 그 포맷이 널리 쓰이게 되는 것은 분명 해당 파일 포맷을 만든 사람에게는 기분 좋은 일일 것이다. 새로운 이미지 파일 포맷이라든가 압축 파일 포맷처럼 말이다. 본인의 경우는 <날개셋> 한글 입력기의 글쇠배열/입력 설정 파일이 이런 창조물의 범주에 속하게 됐다.

파일 포맷이라는 건 지금 당장 공간 낭비 없이 읽고 쓰기 빠르게 만드는 효율도 중요하지만, 범용성과 확장성도 대단히 중요하다. 지금 만들고 있는 프로그램이 구조와 기능이 앞으로 어떻게 바뀔지 알 수 없기 때문이다. 마치 프로그래밍 언어가 하드웨어 친화와 사용자 친화라는 양 이념 사이의 tradeoff로 떨어지듯, 파일 포맷도 위의 두 이념 사이의 tradeoff를 고려하여 제정된다.

또한 파일 포맷은 거의 필수적으로 앞부분에 헤더가 들어간다. 이 파일이 요런 파일 포맷으로 된 파일이라는 것을 나타내며, 헤더가 일치하지 않으면 파일을 더 읽지 말고 에러를 출력하라는 일종의 배려이다. 헤더의 앞에는 식별자가 있는데, 요것이 또 파일 포맷마다 아주 개성이 넘쳤다. 도스 실행 파일(EXE)은 MZ, ZIP 압축 파일은 PK 등.

도스에서 파일의 내용을 보여주는 type 명령은 end-of-file을 나타내는 아스키 문자인 0x1A를 만나면 뒷부분에 텍스트가 더 있어도 표시를 멈췄기 때문에, 파일 시그니처의 끝에다가도 저 문자를 넣어 주는 게 일종의 센스쟁이 관행이었다. 딱 HWP Document File v3.0 요까지만 출력하고 멈추게 할 수 있으니까 말이다. 0x1A는 10진수로 26인데, 이것이 바로 지금도 copy con 다음에 종결을 위해 입력하는 Ctrl+Z와 대응한다. Z는 알파벳 26째 마지막 문자이니까 말이다.

PNG 그래픽 파일은 이 시그니처를 상당히 머리를 써서 만든 것으로 잘 알려져 있다. 마냥 텍스트 파일로 오인하지 않게 의도적으로 맨 앞은 0x89라고 128보다 큰 문자를 집어넣고, 그 다음 PNG를 찍고 줄 바꿈 문자를 찍은 뒤 0x1A로 종결시킨다.

옛날에 아래아한글이 도스용으로 1~2.x 버전이던 시절엔 이런 미래 확장 가능성을 꼼꼼히 설계를 안 했는지 파일 포맷이 수시로 바뀌어서 하위 호환성이 깨지곤 했다. 뭐, 2.1 때는 최초로 압축 저장 기능이 생겼고 도중에 암호 체계가 뚫리는 해프닝이 있어서 불가피하게 포맷이 바뀌어야 하기도 했지만 말이다.
그나마 3.0 포맷이 도스와 Windows 공용으로 무려 97 버전까지 변경 없이 잘 쓰이다가 그래도 지금은 무려 워디안 이래로 포맷이 바뀌지 않고 꿋꿋이 잘 나가고 있다. 안정화가 됐다.

그런 최소한의 융통성을 갖춘 파일 포맷을 만들려면, 결국 어떤 용도의 포맷을 만들든지간에 버전 정보를 남기고 섹션, 구획(혹은 chunk)을 설정하는 정도의 추상화는 공통으로 필요하다. 내가 아는 chunk의 정보만 읽어들이고 모르는 건 무시할 수 있게, 하위 호환이 되게 말이다. PE라고 불리는 Windows용 실행 파일에서도 이런 구획이 있고(text, rdata, data, rsrc 등), TTF 폰트 파일에도 내부에 구획이 있다(cmap, glyf, head 등). 미디(mid) 음악 파일도 온갖 구획들이 합쳐진 컨테이너 포맷이다.

그렇게 외부에서 구획을 표현하는 방식은 파일 알멩이 포맷 이전에 껍데기 '컨테이너' 포맷이라는 공통 규격으로 바뀌는 게 요즘 추세이다. 매 프로그램마다 GUI 프로그래밍을 제각각 할 필요가 없듯, 껍데기를 일일이 새로 만들 필요는 없으니 말이다. 무손실 압축 파일 포맷도 컨테이너와 압축 알고리즘을 분리해서 생각하는 건 상식 중의 상식이고, 손실 압축 알고리즘의 각축장인 동영상/소리 파일 포맷도 컨테이너와 내부 컨텐츠 포맷은 계층이 분리돼 있다.

컨테이너는 아예 human-readable한 텍스트 방식과, 그것보다는 성능을 더 중요시한 바이너리 방식 둘로 나뉜다.
텍스트는 xml이 대세를 평정하는가 싶었는데 요즘은 json도 급부상하고 있다. json은 프로그래밍 언어에서 배열이나 튜플 같은 복합 자료형을 표기하는 방식을 그대로 가져왔다는 점이 무척 참신하다. 배열스러운 나열과 key-value 형태의 데이터를 모두 표기할 수 있으며, 그 덕분에 바이너리 덤프 같은 것도 xml보다는 덜 부담스럽게 집어넣을 수 있고 공간 효율도 더 좋다.

바이너리 차원에서의 컨테이너 포맷으로 요즘 굉장히 많이 쓰이는 건 zip 압축 포맷이다. 수많은 압축 알고리즘들이 존재하지만 역시 오픈소스 앞에서는 답이 없다. zip이 세상을 평정했다. 가장 친숙하게는 MS Office 2007 이후의 문서 파일 포맷, 그리고 오픈오피스 문서 파일 포맷이 내부적으로는 zip 압축 파일이다. Java의 jar 라이브러리, 그리고 안드로이드 adb 패키지도 zip이다.

다만, 저런 프로그램들은 zip 안에다가 자기 방식으로 고유한 메타데이터도 집어넣곤 한다. 그렇기 때문에 이들 파일의 압축을 풀었다가 다시 압축을 했다고 해서 그것들이 해당 오피스 문서나 패키지로 인식되지는 않는 경우가 많다.

멀티미디어 파일 포맷 중에는 avi/wav가 동일하게 RIFF(리소스 교환 파일 포맷)라는 컨테이너 기반이다.
한편 Windows 세계에서는 의외로 많이 쓰이는 공용 바이너리 컨테이너 포맷이 있는데.. 그것은 바로 OLE Compound Binary이다. 이름에서 알 수 있듯이 바이너리 규격에서 여러 프로그래밍 규격들의 통일을 시도했던 OLE/COM 기술과 역사를 같이하는 포맷인 것 같다. 난 잘 모르겠지만 아마 이 파일을 읽고 쓰는 I*** 하는 인터페이스 API도 있으리라 여겨진다.

이 방식의 파일은 D0 CF 11 E0 A1 B1 1A E1이라는 8바이트짜리 시그니처로 시작한다. 의도적으로 128 이하의 텍스트나 제어 문자는 제외한 듯하다. 그리고 앞부분엔 0xFF 문자가 수십~수백 개 나온다.
MS Office가 2007 버전이 등장하기 전에 재래식 doc/xls/ppt가 이 컨테이너 하에서 자기 데이터를 저장하곤 했다. 그리고 지금도 일반적으로는 xml+zip 기반의 docx/xlsx/pptx이지만 암호를 걸어서 저장하면 여전히 예전처럼 이 compound binary를 사용한다. 이건 그리 널리 알려져 있지 않을 것이다.

엑셀의 경우 대용량의 데이터를 빠르게 저장하기 위해 예외적으로 xml 대신 바이너리 포맷을 쓰는 xlsb도 지원하긴 하는데, 이때에도 컨테이너는 여전히 zip이다.
하지만 암호를 걸면 xls든 xlsb든 동일하게 컨테이너가 저 OLECB 방식으로 회귀한다.

OLECB는 Office 문서에서만 쓰이는 게 아닌 범용적인 컨테이너 포맷이기 때문에 Windows의 내부에서는 thumbs.db에서도 쓰이고 심지어 msi 패키지도 이 방식으로 만들어져 있다.
국내에서는 아래아한글이 워디안 이후 새로운 hwp 포맷이 이 컨테이너를 사용하는 중이다. 몇 년 전에 hwp 파일의 포맷이 부분적으로나마 공개되면서 요 방식도 같이 주목받은 편이었다. 워디안의 개발 당시에 OLECB를 사용하기로 한 것은 21세기에 아래아한글의 향후 행로를 결정한 매우 중대한 결정이었을 것이다.

파일 포맷이란 건 한번 정해지고 그게 대중화돼 버린 뒤에는 마치 전기 전압이나 교통수단의 통행 방향처럼 다른 방식으로 덥석 고치기가 거의 불가능하다. 프로그램의 구조가 아주 간단하고 기능 구현만 빨랑 해야 할 때는 숫자/문자열 몇 개를 덥석 텍스트 형태로 덤프하거나, 구조체가 차지하는 메모리 형태를 파일로 통째로 써 버렸을지 모른다. 하지만 그 파일을 남과 주고받게 되고 프로그램을 지속적으로 발전시켜야 한다면 본격적으로 파일 포맷을 고민해야 하는 날이 온다.

이걸 처음에 신중하게 생각을 안 하면 파일 포맷은 legacy들이 가득한 누더기가 돼 가고, 참다못해 파일 포맷을 다 갈아엎게 되고 그러면서 사용자들로부터 욕도 먹을 것이다. 컴터쟁이 프로그래머로서 파일 포맷은 참 재미있는 주제인 것 같다. 그 어떤 파일 포맷이라도 결국은 튜링 기계가 인식할 수 있는 형식 언어와 문법에 속하는 방식으로 귀착된다는 점 역시 생각할 점이고 말이다.

Posted by 사무엘

1.
1993년 가을에 서해훼리(페리) 호 침몰 사고 때의 일이다. 탑승자들을 구조하고 수색하는데 웬일인지 이 배의 최고 책임자인 선장이 행방이 묘연해 보였다. 그런 와중에 일각에서는 "선장이 혼자 살아서 배를 탈출하여 몰래 튀는 게 목격됐다"라는 카더라 루머가 나돌았고, 언론은 이것을 확인도 안 하고 냅다 물어서 동네방네에 소문을 냈다.
이에 경찰조차 별 의심 없이 이 말을 믿게 되었으며 선장을 대문짝만 하게 공개 수배하고 가족들을 압박하여 선장더러 자수를 권유하게 했다.

그러나 결말은? 선장은 수색 닷새 만에 기관장과 함께 배 안에서 시신으로 발견됐다. 서해훼리호의 선장은 세월호의 선장 같은 급의 인간말종은 아니었던 것이다.
이제 예전의 선장 생존 보도는 국내 언론 역사에 길이 남을 오보 흑역사로 전락했다. 그리고 그 기자들은 선장의 유가족을 찾아와서 싹싹 빌었다. 범죄자를 숨겨 주고 있다는 누명을 이제야 벗은 유가족들은 "당신들이 선장이 살아 있다고 말했으니 이제 그 선장을 살려내 보시오"라고 그들을 꾸짖었다.

2.
1996년 가을, 강릉 무장공비 침투 사건 때에는 싸리비를 만들기 위해 싸리나무를 벌목하러 혼자 나갔던 표 종욱 일병이 덜컥 실종됐다. 군에서는 제대로 수색도 안 하고 이걸 전시 무단 탈영으로 단정짓고 탈영병을 찾는다는 방송을 전국에 내보냈다. 그의 집엔 헌병대 사람들이 와서 표 일병 내놓으라고 마치 사채업자가 빚독촉 하듯이 수시로 온갖 민폐를 끼쳤다.

그러나 이 역시 결말은? 그는 무장공비에게 살해당했음이 나중에 밝혀졌다. 이건 부끄럽게도 군 당국이 스스로 적극적으로 수색해서 찾은 게 아니라, 사살한 무장공비에게서 노획한 '일기'에서 의심스러운 점을 발견하여 그걸 토대로 추적한 덕분에 찾은 것이었다. 그 무장공비는 위장을 위해 표 일병에게서 국군 군복을 빼앗은 상태였으며, 그 대신 표 일병은 시신 발견 당시 속옷 바람이었다.

상황이 이렇게 되자 헌병대 관계자들은 표 일병의 유가족 앞에서 그야말로 석고대죄하고 손이 발이 되도록 빌었다. 생사도 알 수 없는 치욕스러운 탈영병과, 현충원에 묻히는 영예로운 전사자는 그야말로 한 끗발 차이에 지나지 않았다. (더구나 전시 탈영은 평시 탈영보다 처벌이 훨씬 더 무겁다!)

무장공비는 그를 결박하고 목을 졸라서 살해했다. 총은 시끄러운 데다 걔네들 입장에선 안 그래도 총알 한 알이 극도로 아까운 지경일 텐데 당연히 총을 썼을 리는 없다.
또한, 생지옥 북한에서 태어나서 거기서 혹독한 훈련을 받으며 남파 간첩이나 무장공비까지 됐을 사람이라면 목표를 위해서는 수단과 방법을 가리지 않고 인간성이라고는 그야말로 완전히 제거된 인간 흉기나 마찬가지였을 것이다. 잠수함을 좌초시키고 비밀 작전에 실패했다고 동지들끼리도 무자비하게 처형을 했는데, 하물며 자신을 발견해 버린 민간인도 아니고 적군을 살려 둘 이유는 전혀 없었을 것이다. 생포해서 인질극 협상을 벌일 수 있는 처지도 아니고.

기록을 찾아 보니 표 일병은 군 복무 당시 계급이 이미 일병이었다.
“이제 일병을 달고 군생활에도 적응이 되었지만 원인모를 한숨과 동경이 계속되고 있다. 언제까지 이 신세타령을 해야 하는지 내자신도 한심하다.” (고인의 일기 중)

그럼 전사자니까 이제 공식 매체에서는 '표 상병'이라고 불러야 하지 않겠는가? 제설을 하다가 사고로 죽어도 작전 중 순직이기 때문에 1계급 특진 추서인데.
탈영 중으로 잘못 알려졌을 때의 계급이 너무 깊게 인식돼 버려서 그런 것 같다. 이런 점에서 거짓 선동이라든가 오보의 해악은 더욱 큰 셈이다. 한번 생긴 사람의 편견은 쉽게 고쳐지지 않으니까.

* 그러게 사람이 없어진 듯이 보이면 덮어놓고 악한 추측부터 좀 하지 말았으면 좋겠다.
하긴 출애굽기 32장의 금송아지 사건도 따지고 보면 그런 심성을 바탕으로 벌어졌다. 이때 모세는 시신이 발견된 게 아니라 멀쩡히 살아 돌아오기도 했고 말이다.

Posted by 사무엘

예전에 한번 다윗과 미갈 이야기를 한 적이 있었는데 정작 이스라엘의 초대 왕인 사울 자체에 대해서는 지금까지 얘기를 한 적이 없었다. 그래서 오늘은 이 주제 얘기를 작정하고 좀 늘어놓아 보겠다.

구약 성경을 좀 읽은 분들이라면 이미 아시겠지만, 이스라엘 백성은 가나안 땅에 들어간 직후에는 왕도 아니고 대통령도 아니고 사사(재판관)라고 불리는 정치· 종교 지도자가 백성을 통치했다.
정치 삼권 중에서 입법과 행정이 빠진 사법이 부각되어 나오는 점이 특이하다. 입법은 이미 모세의 율법이 있으니 더 건드릴 필요 없고 행정은 글쎄.. 하나님이 알아서 하시니 너희 인간들은 이미 있는 법대로 사람을 판단하고 법의 집행만 하라는 뜻인 듯하다.

그러니 이 시절의 사사는 말 그대로 판관 포청천 같은 위상이었다. 다만, 본업인 재판만 한 게 아니라 때로는 전쟁을 지휘하고 민족을 외세 식민 통치로부터 해방시키기도 했다. (혼자 블레셋 사람들을 다 때려잡은 삼손도 사사였으니) 하지만 호화로운 궁전에서 산해진미를 먹고 수많은 종과 상비군을 거느리면서 산다거나 하지는 않았다. 다른 민족들의 왕과 비교했을 때 '가오'가 안 났다.

이스라엘 역사상 마지막 사사 겸 첫 대언자는 '사무엘'이었다. 그의 시대 때 백성들은 드디어 자기에게 왕을 달라고 요구하기 시작했다(삼상 8:5). 이것은 일차적으로는 우리도 이방 민족들처럼 절대권력 국왕 휘하에 일사불란하게 움직여 보고 싶지, 하나님 특유의 '그때 그때 달라요' 식의 믿음 행사가 필요한 통치를 원하지 않는다는 반역의 영으로 인한 결과였다.

한편으로는 사무엘의 아들들이 하는 꼬라지를 보니, 안 그래도 걸핏하면 전쟁에 외세 식민지인데 권력이 부족한 사사 통치 체계로는 나라의 앞날이 영 불안하다는 심리가 작용한 것도 있었다. "그때에 이스라엘에 왕이 없었더니"란 표현이 사사기에 도대체 몇 번 나오던가? 사무엘은 인생이 다 좋았는데 자녀 교육만은 그리 성공적이지 못했다는 것이 안타까운 점이다.

하나님은 백성들의 이런 요구를 듣고는 불쾌한 반응이었지만 "이제 올 것이 왔구나. 거스를 수 없는 대세이긴 하지" 차원에서 그들의 요구를 들어 주셨다. 애초에 율법도 이스라엘 백성들이 훗날 왕정으로 전환할 때 왕이 지켜야 할 덕목에 대해 언급을 하고 있기도 했다. "율법 말씀을 필사해서 부지런히 묵상해라", "권력의 상징이라고 해서 사치품인 동물 말을 너무 많이 장만하지 말라" 같은. 신명기 17장을 읽어 보면 참 절묘함이 느껴진다.

단, 하나님은 왕을 가져 본 적이 없던 백성에게 세상에 공짜는 없다는 평범한 진리를 거듭 확인시켜 주셨다. 간지 넘치고 뽀대 나는 왕권을 유지시키는 원천은 전~~부 죄다 너희들의 노동력과 세금이라는 것을 말이다.
얘들은 안 그래도 율법에 따라 종교적으로 바쳐야 하는 헌물들이 장난이 아닌데, 거기에다가 정치적인 세금 수탈까지 추가되면 도저히 견디지 못할 지경이었다. 이 때문에 이스라엘에서 왕정이 유지되는 동안 안식년은 사문이 되고 한 번도 지켜지지 않았다고 성경은 말한다. 끊임없이 생산하고 또 생산해야 감당이 되니까.

그때 가서 너무 힘들어 죽겠으니 도로 왕을 없애자고 하소연해 봤자, 대통령도 아니고 한번 왕좌에 앉아서 절대권력의 맛을 봐 버린 왕이 호락호락 하야해 줄까? 천만의 말씀. 역성혁명, 쿠데타 급의 일이 터져서 수많은 사람들이 죽지 않는 이상 정세가 그렇게 바뀌지 않는다. 하나님의 경고는 단순히 "어쭈? 네놈들이 내 통치를 원하지 않는다고? 괘씸한 것들! 어디 엿먹어 봐라" 같은 보복성 공갈 협박이 아니라 정말 진심으로 하는 조언이었던 것이다(삼상 8:18). 성경은 생각보다 정치 분야의 통찰도 많이 담긴 책이다.

(그리고 여담이지만, 본인은 "우리에게 왕을 주소서"라는 그 시절의 역사가 지금으로 치면 "우리에게 자가용을 주소서"와 비슷하게 읽힌다. 차가 있으면 이동이 정말 편리해지고 주변 사람들에게 간지와 뽀대도 많이 난다. 그러나 차도 일단 장만하고 나면 유지비가 도대체 얼마나 깨지던가? 그야말로 그 사람의 생활 패턴과 경제 양상이 확 달라지게 된다. 빚 내 가며 차 잘못 샀다가 도로 무를 수도 없고 손가락만 빨며 카푸어로 전락한 사람 많다.)

아무튼, 이런 우여곡절 끝에 이스라엘은 역사상 전무했고 현재까지도 다시 없는 왕정 체제가 시작되었다. 베냐민 지파의 사울이 이스라엘의 초대 왕으로 선출되었다. 성경의 사무엘기, 열왕기와 역대기는 이스라엘 민족의 역사 중에서 이런 특이한 시기를 다루고 있다는 점에서 의미심장하다.

사울은 키 크고 잘생긴 미남이었다(삼상 9:2). 군사 영도력도 훌륭했고(삼상 14:47-48), 재임 기간 전체를 통틀어 봤을 때 후임인 다윗과 같은 수준의 큰 병크를 저지른 것도 없었다(밧세바 간음, 인구 조사). 하지만 성경에서의 평가는 다윗과 너무 차이가 난다 싶을 정도로, 지나치다 싶을 정도로 바닥을 긴다.

사울은 영적으로 점점 타락했다. 다윗이 자신의 위험한 정치 라이벌이라는 망상에 사로잡혀서 그를 정당한 이유 없이 죽이려 했으며, 다윗을 신고하지 않고 보호해 줬다는 이유로 하나님의 제사장들을 막 죽이는 일까지 서슴지 않았다. 그리고 나중에는 자기가 금지해 놓고는 위급하니까 결국 부리는 영을 지닌 무당을 찾아가서 점괘를 구할 정도로 심각한 막장의 나락으로 떨어졌다.

이런 행적에 대해서 본인은 이렇게 평가한다. 그는 정말 불신자스러운 '적당히' 세상적인 사고방식의 관점에 아주 충실했다. 세상의 정치판에서 성공하는 데는 이런 유도리 타입이 딱 적절하다.
그는 하나님께 대놓고 반역을 한 게 아니었고, 발람처럼 교묘하게 잔머리를 굴리는 사악한 타입도 아니었다. 하지만 하나님께 자기 마음을 전적으로 드린 건 아니었다. 다윗처럼 하나님의 마음과 완전히 일심동체가 되고 하나님의 심정을 경험하는 그런 영성이 없었다는 것이다. 그리고 불행히도 저런 부분적인 순종과 온전하지 않은 마음은 우리가 흔히 생각하기 쉬운 것보다 하나님이 광장히 싫어하시는 사고방식이었다.

그래서 아말렉 족속을 진멸하라는 잔인하고 부정적인 명령에 온전히 순종하지 않았다. 나름대로 하나님께 헌물로 바친답시고 가축들을 살려 갖고 왔다. 사무엘이 이를 지적하며 "순종이 제사보다 낫다"라는 그 유명한 말로 책망을 했지만, 그는 여전히 상황 파악을 못 한 듯 회개하지 않고 변명을 늘어놓았다. 그러면서 "먼저 혼자 휙 가 버리시면 전 뭐가 됩니까? 백성들 앞에서 가오가 안 서니, 같이 좀 나가시죠, 네?"(삼상 15:30)라고 자신의 정치 생명과 체면치레 걱정만 했다.

사실 사울은 예전에도 위급한 상황에서 사무엘이 좀 도착이 늦어진다 싶으니까 자기가 제사장 행세를 하면서 하나님께 헌물을 바친 적이 있었다. 성직과 관련된 절차와 규율이 제멋대로 문란해지는 걸 하나님이 얼마나 싫어하시는지는 구약 성경 역사서 곳곳에서 용례를 찾을 수 있다. 이때에도 사울은 제대로 회개하지 않았다. 그는 하나님의 성품 내지 하나님과 친밀하게 교제하는 것 같은 영적인 일에 전반적으로 관심이 별로 없는 딱 세속 정치가 타입이었다.

이렇게 사소하다면 사소하지만 근본이 글러먹은 사고방식으로 인해 하나님은 사울에게서 완전히 학을 떼 버리신 것이다. 이것이 사울이 간음과 살인방조죄를 저지른 다윗보다도 하나님으로부터 엄청나게 저평가되고 있는 이유이다. "내가 이렇게 비참해지면 하나님도 나를 불쌍히 여겨 주실 것이다"(삼하 16:11-12)라고 말한 다윗하고는 달라도 너무 다르지 않은가. 예수 믿는 크리스천은 이 점을 교훈으로 삼아야 할 것이다. 하나님이 무슨 거지이기라도 해서 사람으로부터 헌물을 받아야만 하고 사람이 하나님을 '위해서' 뭔가를 해 줘야 할 처지가 전혀 아니란 말이다!

자, 사울이 몰락한 이유에 대해서는 이렇게 충분히 분석과 설명이 됐다. 그럼 다음 이야기를 좀 꺼내 보겠다.
사울은 블레셋과의 최후의 전투를 앞두고 그야말로 사면초가 신세가 됐다. 다윗은 자기가 쫓아낸 상태이고 사무엘은 죽고 없으며, 하나님은 그에게 아무 응답도 주지 않으셨다. 그러니 얼마나 답답했을까?

이것은 하나님이 변덕쟁이여서가 아니라 사울이 여전히 자신의 나쁜 버릇을 안 고치고 "흐음.. 대충 기도해 보고 이래도 응답이 없으면 마지막 카드로 점이라도 쳐야겠다" 같은 불순하고 이중적인 마음을 품은 상태였기 때문이다. 그래서 하나님께서 응답하지 않으셨으며, 대상 10:13-14에서는 사울이 하나님께 애초에 여쭌 게 아니었다고 진술을 달리하고 있는 것이다.

그런데 여기에서 문제가 있다.
엔돌의 무당이 불러 낸 사무엘은 진짜 사무엘이었을까? (삼상 28:7-14)

나도 옛날에, 한 15~20년쯤 전에는 무당이 불러낸 사무엘이 진짜 사무엘이 아닐 거라고 생각했다.
그도 그럴 것이, 일개 무속인이 그렇게 죽은 사람의 혼을 불러낼 능력이 있을 리 없다는 생각이 그 당시로서는 합리적인 생각이었으며,
또 진짜 사무엘이라면 지금이라도 사울과 다윗을 화해시키려고 노력했겠지, 저렇게 잔인하고 매정하게 사울을 멘붕시키고 죽게 만들지는 않았을 거라는... 인간적이고 '사람을 살리는' 사고방식이 당시에 더 우세했기 때문이다. 마치 입다의 딸이 설마 진짜 죽었을 리는 없다고 생각하는 것과 비슷한 맥락으로.

물론 지금은 진짜 사무엘이라고 생각이 바뀐 지 오래다.
무당은 평소에 하는 것처럼 사무엘 행세를 하는 부정한 영이나 하나 불러내려고 푸닥거리를 했는데.. 하나님이 그 타이밍에 맞춰 레알 사무엘을 소환시켜 주셨다. 돌발 예외상황이 발생하는 바람에 무당은 깜짝 놀라 자빠지고, 자기에게 온 고객이 무려 이 나라의 왕인 것도 알아채게 됐다.

그 사무엘이 진짜 사무엘인 가장 성경적인 이유는.. 인간적인 거 나발이고 다 필요 없고,
사무엘의 예언이 다음날 정말 문자 그대로 정확· 정밀하게 적중했기 때문이다. 비록 마귀에게도 예언을 적중시킬 능력이 전혀 없는 것은 아니고 모호하게 한 예언이 어쩌다 부분적으로 적중할 수도 있지만, 일단 저 문맥에서 사무엘이 가짜라고 생각하기에는 "예언의 성취"라는 건 성경 전체에서 일관되게 너무 너무 긍정적으로 흐르는 심상이다.
욥의 행동에 대해 사탄이 예언한 것, 이스라엘을 말아먹은 거짓 대언자들의 온갖 거짓 예언들 등등과 비교했을 때 말이다. "예언의 성취 여부"만이 중요하지 그 예언에 담긴 메시지가 긍정적인 내용이냐 부정적인 내용이냐는 전혀 고려 대상이 아니다.

이런 것들이 성경을 많이 읽으면 자연스럽게 사고방식이 성경의 저술 분위기대로 바뀌는 현상이다.
다른 예로, 한때는 예수님이 그저 인간적인 감정 때문에 피땀 흘리면서 울부짖었고, 동정과 연민 때문에 울었을 거라고 나도 실제로 생각했다. 하지만 성경을 제대로 많이 읽고 나면.. 그보다 훨씬 더 고차원적인 이유 때문에 그런 행동을 하셨다는 게 납득이 되게 된다. 그런 것과도 같은 이치이다.

끝으로, 사울은 죽어서 어디로 갔을까 하는 문제가 있다. 말년에 너무 타락했고 자살까지 했는데 도저히 하늘로 갔을 것 같지 않지 않다고 생각하는 분들도 계신 듯. 성경에서도 사울은 신약에 전혀 언급되어 있지 않기 때문에 정확한 단서를 얻을 수도 없다.

단지, 하나님께서 구원조차 못 받은 사람을 이스라엘의 초대 왕으로 세우지는 않았을 것이라는 생각, 그리고 아무래도 사울도 구원받은 사람인 사무엘 내지 요나단과 같이 있을 거라는(= 낙원에) 언질이 있으니(삼상 28:19) 굳이 따지자면 사울도 구원은 부끄럽게나마 받았을 것이라는 추측이 일단은 지배적이다.
신약에 부끄러운 구원의 상징으로 아나니야와 삽비라가 있다면, 구약에서는 사울이 그와 비슷한 급이 아닐까 싶다.

관심 있는 분은, 사울 왕과 관련된 의문을 더 자세하게 다룬 윤 성목 목사님의 글을 참고하시라.
난 아시다시피 '새마을'과 발음이 비슷하다는 이유로 '사무엘'이라는 이름을 닉으로 쓰고 있다. ㅎㅎ

Posted by 사무엘

1.
"프란시스" 쉐퍼(섀퍼) (1912-1984)는 유명한 복음주의 기독교 신학자, 철학자, 장로교 목사이며 국내에서도 <그러면 우리는 어떻게 살 것인가> 같은 영성 쪽의 여러 유익한 신앙 서적들을 통해 잘 알려져 있다.

저 책의 제목인 How should we then live는 성경에서 겔 33:10의 표현을 딴 것이다.
출판 시기는 1976년이다. 정치적으로는 냉전, 공산당 혁명과 월남전, 그리고 과학 기술 분야로는 초음속기와 우주선, 대중 문화로는 비틀즈와 락 음악 같은 그야말로 격변의 시기에 말 그대로 어떤 가치관을 갖고 사는 것이 바람직한지에 대한 의문을 던지면서 그 해답을 성경적 세계관에서 찾았다.

물론 현대만 다루는 게 아니다. 부제가 The Rise and Decline of Western Thought and Culture이니만큼, 로마 제국, 중세, 종교 개혁, 산업 혁명 등을 모두 다루면서 서양사를 전반적으로 고찰했다.
그렇게 살펴봤는데 역시 사회의 문제는 절대적인 진리를 거부하고 절대적인 선과 악이 없다고 주장하는 상대주의에서 유래되곤 했다. 그 결과 무정부주의가 나오고, 이로부터 야기된 혼돈을 바로잡으려고 또 다른 극단인 피의 독재자가 등장하여 학정을 하곤 했다.

영국의 명예 혁명과 미국의 독립 혁명에 비해, 프랑스의 혁명과 러시아의 혁명은 좋지 못한 결말로 끝났다. 공산당식 혁명은 언제나 끔찍한 피의 비극과 독재 학정으로 마무리 되곤 했다.
하지만 반공 우파스러운 주장만 있는 게 아니다. 다른 나라들에 비해 그나마 성경적인 가치관이 심어져 있던 영국도 산업 혁명 이후에 부의 제대로 된 분배에 교회가 제 역할을 못 해서 공산주의가 등장할 빌미를 줬다. 미국은 크리스천들이 흑인 노예의 인권에 소홀하여 오점을 남겼다고도 글쓴이는 지적한다.
또한, 저런 정치 해석뿐만이 아니라 미술사· 음악사 얘기도 나온다.

방대한 책을 다 읽을 시간이 없는 사람들을 위해, 쉐퍼의 책은 그 이듬해에 10부작 다큐멘터리 영화로도 출시되었다.
바로 그의 아들인 프랭크(혹은 Y가 붙어서 프랭키) 쉐퍼 (1952-)가 영화 감독, 시나리오 작가, 연설가였으며, 20대 중반의 나이로 자기 아버지가 자기 저서에 대한 나레이션을 하는 영화를 만든 것이다. 나름 굉장히 잘 만들었다. 제5편 혁명의 시대 때는 시도 때도 없이 단두대가 내려오는 장면이 나온다. ㅎㅎ

이 영화는 현재 유튜브에서 바로 검색해서 볼 수 있다. 다만, 한국어 자막이 없기 때문에 유튜브의 혜택을 볼 수 있는 사람이 그리 많지는 않을 것 같다.

2.
"프란시스" 메크너(1932-)는 심리학자이다. 위키백과를 보면 1960년대부터 이미 학계에서 날고 기었던 것으로 소개된다.
그런데 그의 아들이 바로 조던 메크너 (1964-)로.. 비디오 게임 개발자, 시나리오 작가, 영화 감독이다. 프란시스 쉐퍼의 아들과 비교했을 때 영화학도라는 공통점이 있는데, 물론 메크너 쪽은 종교 쪽으로는 안 가고 게임업계로 갔다. 그리고 조던 메크너는 그 이름도 유명한 "페르시아의 왕자" 게임을 20대 중반의 나이 때 만들어 냈다.

그 게임 특유의 던전 구조와 메카닉, 왕자의 움직임 같은 것이야 그 옛날에 조던의 머리에서 나온 천재적인 발상이다. 그리고 코딩 역시 그 사람이 애플 II 어셈블리 언어를 독학하여 직접 했다. 하지만 전반적으로 볼 때 <페르시아의 왕자>는 가족의 도움으로 만들어졌다.
모션을 촬영할 때 연기는 남동생을 시켜서 이리저리 굴리며 했고, 무엇보다도 게임의 음악은 심리학자인 저 아버지가 전부 작곡해 줬기 때문이다. 빰 빠빠빰 빰빰 하는 그 음악을 말이다.

게임을 그저 죄악시 금기시하는 우리나라 풍토와 비교했을 때, 그것도 1980년대에 조던 메크너의 집안이 시대를 얼마나 앞선 천재 집안이었는지를 짐작할 수 있다. 게임을 하는 정도가 아니라 그런 게임을 만들어 냈다. 그것도 본인과 본인의 아버지, 동생이 힘을 합쳐서 말이다.

쉐퍼든 메크너든, 위키백과에 대대로 이름이 등재돼 있는 '프란시스' 부자들엔 이렇듯 굉장히 의미심장한 패턴이 있다.

Posted by 사무엘