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

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

나의 영원한 친구는 비주얼 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 사무엘

맥 OS는 화면 상단에 붙박이로 메뉴가 있어서 모든 프로그램들이 동일한 메뉴 표시줄을 공유한다. 이게 Windows로 치면 응용 프로그램의 메뉴 겸 작업 표시줄의 시작 메뉴, 그리고 심지어 시스템 트레이의 역할까지 한다.
그러나 Windows는 각각의 창이 자신의 고유한 메뉴 표시줄을 갖는 구조이다. 이건 맥과 Windows가 무려 1.0 시절부터 서로 다르게 설계한 디자인이다.

그래서 Windows에는 응용 프로그램의 기본 메뉴뿐만이 아니라 어떤 창이라면 공통으로 갖는 창 자체에 대한 메뉴도 있는데, 이것을 '시스템 메뉴'라고 한다. 창 자체를 이동하거나 크기를 조절하고, 최소화/최대화를 시키거나 닫는 고정적인 명령들이 있다. 마우스로는 좌측 상단에 있는 해당 프로그램의 아이콘을 클릭하면 되고, 키보드로는 Alt+Space를 누르면 된다.

옛날에 3.x 시절에는 '작업 목록(지금으로 치면 작업 관리자와 비슷)'을 꺼내는 명령도 시스템 메뉴에 있었는데 그건 Windows 95부터 없어졌다. 그땐 시작 메뉴나 작업 표시줄 같은 게 없었기 때문에 Alt+Tab 외에 응용 프로그램간 전환을 하는 방법을 그런 식으로 마련해 놓을 필요가 있었던 것이다.

그런데 창의 시스템 메뉴는 기본 메뉴의 연장선의 성격을 지님과 동시에 한편으로 우클릭 팝업 메뉴의 형태로도 부를 수 있다. Alt나 F10을 눌러서 기본 메뉴를 열어서 좌우 화살표 키를 누르면 기본 메뉴와 더불어 시스템 메뉴로도 순환이 된다.
그러나 창의 제목 표시줄을 우클릭하면 창의 시스템 메뉴만 따로 우클릭 메뉴의 형태로 꺼낼 수 있으며, 이때는 좌우 화살표를 눌러도 기본 메뉴가 표시되지는 않는다. 사실, 시스템 메뉴를 우클릭 메뉴 형태로 꺼내는 건 Windows 95에서부터 추가된 새로운 UI이긴 하다.

그리고 Windows 95에서는 메뉴의 아이템들 중 하나를 default로 지정하여 진하게 강조되어 출력하는 UI가 추가되었다. 당장 시스템 메뉴에서 확인할 수 있는데, 이것은 디자인 컨셉상 우클릭 메뉴에서 쓰라고 도입되었다.
화면에서 어떤 개체를 더블 클릭했을 때 취해지는 default 동작이 해당 개체의 우클릭 메뉴에 포함되어 있다면, 그 동작에 해당하는 메뉴 아이템을 진하게 출력하면 된다.

그래서 파일 열기 대화상자에서 파일이나 디렉터리를 우클릭하면, 탐색기에서 파일/디렉터리를 우클릭했을 때는 없던 '선택/Select'라는 명령이 추가되고 이것이 진하게 표시된 것을 확인할 수 있다.
또한 똑같이 창의 시스템 명령을 꺼냈더라도 아이콘을 클릭했을 때는 '닫기'가 진하게 나오고, 제목 표시줄을 우클릭했다면 '최대화' 명령이 진하게 나오는 것을 알 수 있다. 창의 해당 부위를 더블 클릭하면 실제로 그 동작이 행해지기 때문이다. 우클릭 메뉴의 default 아이템에는 이런 의미가 있는 것이다.

그런데 운영체제의 이런 동작에는 버그가 있다.
최대화된 프로그램의 제목 표시줄을 우클릭하면 '이전 크기로'가 진하게 나와야 하고, 최대화되지 않은 프로그램의 제목 표시줄을 우클릭하면 '최대화'가 진하게 나와야 한다.
그러나 탐색기, IE, MS 오피스 프로그램, Media Player 등, 마소에서 개발한 프로그램들은 그렇게 동작하지 않으며, 언제나 '닫기'만이 진하게 나온다. 시스템 메뉴를 직접 꺼냈을 때처럼 말이다.
그 반면, 메모장이나 <날개셋> 편집기 같은 프로그램은 바르게 동작한다. 어찌 된 일일까?

여러 프로그램들의 동작을 관찰해 보면, 차이는 단 하나뿐이라는 걸 알 수 있다.
바르게 동작하는 프로그램은 운영체제의 기본 메뉴를 사용하는 프로그램이다. 그 반면, 자체적으로 구현한 메뉴를 사용하느라 기본 메뉴를 사용하지 않는 프로그램은 제목 표시줄을 우클릭했을 때 default 아이템이 제대로 처리되지 않고 언제나 '닫기'만 진하게 나온다. 신기하지 않은가?

Windows라는 운영체제는 창을 생성할 때 또는 아예 창의 클래스를 등록할 때 메뉴 핸들을 같이 전달할 수도 있을 정도로 메뉴 처리를 각별히 신경 써서 만들어졌음에도 불구하고, 이젠 마소에서 자체 기본 메뉴를 구시대 물건으로 치부하고 매우 천대하고 있다. 이것은 어제오늘 트렌드가 아니다. 마소에서 직접 만드는 네임드급 프로그램들 중에 기본 메뉴를 사용하는 프로그램이라고는.. 거의 없다. 자체 메뉴를 쓰는 것도 모자라서 그걸 다 리본 UI로 대체하거나, 아니면 탐색기나 IE의 경우 Alt를 눌렀을 때에만 메뉴가 잠깐 나타난다. 그러니 제목 표시줄을 우클릭했을 때 '최대화'가 진하게 나오는 광경을 보기가 더욱 힘들어지고 있는 것이다.

게다가 본인이 확인한 바로는 이건 거의 Windows 98때부터 동일하게 이러고 있다. 크기 조절과 최소화· 최대화가 가능한 프로그램 윈도우치고 어떤 형태로든 메뉴가 없는 창은 보기가 힘들다. 그러니 이런 버그가 상대적으로 눈에 잘 안 띄었던 것인지도 모르겠다. Windows 95때는 컴의 성능도 열악하고, 그 시절에는 마소에서 만든 프로그램들도 거의 다 기본 보급 메뉴를 썼기 때문에 확인이 쉽지 않다.
아무튼 이거 굉장히 흥미로운 현상이다. 구닥다리 레거시 코드에 존재하고 딱히 심각한 문제도 아니니, 앞으로도 안 고쳐질지도 모르겠다.

Posted by 사무엘

• 용의자, 피의자, 피고(인), 범죄자
• 기소유예, 선고유예, 집행유예
• 구류, 금고, 징역
• 교도소, 구치소, 유치장, 소년원
• 밀입국, 불법체류
• 과태료, 범칙금, 과료, 벌금, 추징금
• 불법주차, 부정주차

법률 용어에는 비슷해 보이지만 관점이 서로 다른 개념들이 의외로 많다. 이 글에서는 자동차 운전과 관련된 것들을 좀 살펴보도록 하겠다.

신호와 속도는 딱히 악의적이지 않아도 운전자가 경미하게라도 종종 위반하기 쉬운 사항이다. 주변에 차가 없고 위험 요소가 보이지도 않는데, 고지식하게 기다리기 싫고 규정 속도대로만 가기가 싫은 것은 인지상정이다. 게다가 그놈의 노란불 딜레마 때문에 어영부영 하다가 본이 아니게 신호 위반에 걸리기도 하며, 이 때문에 면허 시험에서 떨어지기까지 하면 억울함과 짜증이 최악에 달할 것이다.

하지만 그렇다고 모든 교통법규 위반을 단순 경범죄 급으로 용인했다가는 도로가 난장판이 되고 교통사고가 폭증할 것이니 누군가는 이걸 단속도 해야 한다. 자동차는 우리가 생각하는 것보다 매우 무겁고 빠르고 단단하고 위험한 물건이기 때문이다.

이런 속도· 신호 위반에 걸렸을 때 우리는 국가에게 돈을 뜯기는데, 그 형태가 하나만 있는 게 아니다. 범칙금 또는 과태료라는 두 형태가 존재한다.
범칙금은 경찰이 실운전자에게 직접 징계를 내리는 관점인지라 돈+벌점 형태이다.
그러나 과태료는 실제 운전자가 아닌 차량 소유주에게 행정부가 제재를 가하는 관점이다. 같은 위반 아이템에 대해서 액수가 범칙금보다 약간 더 높지만(+1만원) 벌점은 없다.

이렇게 체계가 이원화된 이유는 단순히 "너 벌금+벌점 같이 받을래, 아니면 돈 더 내고 벌점은 안 받을래? 골라" 차원이 아니라 더 깊은 사연이 있기 때문이다.
먼저, 도로 위에서의 경미한 위반을 일일이 다 단속하면서 운전자들을 사법부 차원의 형벌을 내려서 범죄자· 전과자로 만드는 것은 국가적으로도 그리 좋을 게 없기 때문이다. 그래서 그보다 아랫단에서 더 가볍고 뒤끝 없는(?) 처벌을 선택하는 길을 열어 놓은 것이다.

또한 더 근본적인 이유로는, 무인 카메라 단속에 걸린 건 현장에서 경찰에게 걸렸을 때와는 달리 면허증을 까고 실운전자의 신원을 제대로 파악할 수 없기 때문이다. 이때는 과태료 또는 범칙금 선택의 형태로 고지서가 날아온다. 교통법규의 위반에 대해서 실운전자를 파악할 수는 없지만 누군가는 책임을 져야 하니까.
이런 단속 방식과 관점, 단속 명의의 차이로 인해 범칙금과 과태료라는 두 체계가 공존하는 것이다. 뭐, 둘 중 하나만 고르라면 원래는 범칙금이 원칙이긴 하지만.

땅은 좁은데 차가 너무 많은 관계로, 운전을 마친 뒤엔 불법 주정차도 운전자들이 꽤 자주 저지르는 위반 사항이다. 이로 인해 정부 기관에게 단속을 당했다면 그때는 운전자가 현장에 없으니 선택의 여지 없이 차주에게 과태료가 부과된다. 하긴, 애초에 주정차 단속은 구청/시청 공무원이 하지, 경찰이 하는 것 같지는 않다. 그리고 주차 위반 과태료는 일찍 내면 원래 내는 금액의 20%를 깎아 주는 듯하다.

과태료(행정부)와 범칙금(경찰)의 관계는 이렇게 설명이 됐는데..
음주운전 단속에 걸렸을 때 뜯기는 돈은 과태료나 범칙금이 아니라 "벌금"이다. 이것은 집행 주체가 사법부이며(= 판사의 판결), 똑같이 돈을 내더라도 집행유예만큼이나 전과가 남는 대단히 무거운 처벌이다.
음주운전 정도면 사고 안 낸 초범이어도 액수부터가 수십~수백만 원급으로 나오니 단순 속도· 신호 위반 과태료와는 차원이 다르다. 또한 벌금형까지 받은 사람이라면 공무원 내지 직업 군인 진로에도 애로사항이 꽃피게 된다.

과료는 그냥 벌금의 다운사이즈 버전으로, 이 역시 과태료나 범칙금과는 성격이 다르다. 주로 쓰레기 무단 투기나 노상방뇨 같은 경범죄를 저지르다 걸렸을 때 부과되는데, 현실에서는 이것도 사법부 주관의 과료보다는 경찰 주관의 범칙금 형태로 대체되는 경우가 많다.

주차 얘기가 잠깐 나왔으니 말인데, 불법주차와 부정주차의 차이는 이러하다.

• 불법주차: 어떤 자동차라도 세워진 채 공간을 차지해서는 안 되는 곳이다. 다른 차의 교통 흐름에 지장을 주고 시야를 가려서 사고 위험을 높이기 때문이다. 대로변을 포함해 교차로, 횡단보도, 버스 정류장, 소화전의 근처는 더욱 그러하다.
• 부정주차: 차를 세울 수는 있는 곳이지만 그 차가 네 차는 아니다. ㄲㄲㄲㄲ 주로 거주지 우선 주차 구역이나 골목길, 아파트 단지 안이 이런 곳에 속한다.

그러니 불법주차는 길에 대해서 public한 성격이 강한 반면, 부정주차는 어떤 공간에 대해서 private한 성격이 강하다. 하지만 지방 정부가 거주자 우선 주차 구역을 정하기도 하기 때문에 공공기관이 불법뿐만 아니라 부정 주차를 단속하기도 한다.

구석에 주황색 실선이 그어진 도로는 원래 주· 정차가 모두 금지되는 곳이지만 현실에서는 불법 주차된 차들이 많고 관례적으로 단속도 없이 그 관행이 묵인되는 곳도 왕왕 있다.

단, 위의 모든 규정에는 예외가 있다. 긴급 자동차를 비켜 주는 등 지극히 정당한 사유로 인해 정지선을 넘고 신호를 좀 위반한 거라면, 상황 입증만 가능하면 과태료 부과는 당연히 면제된다. 이와 마찬가지로 주차 위반도 정당한 사유로 인해 불가피하게 한 것이 인정되면 마찬가지로 구제 방법이 있으니 더 자세한 사항은 인터넷을 검색해서 찾아 보면 된다.

Posted by 사무엘

성경에서 예수님에게 향유를 부은 여인 이야기는 사복음서에 모두 등장한다. 그러나 이것은 오병이어나 십자가 사건과는 달리 동일한 공통 사건이 아니다. 도대체 어느 게 어느 사건인 걸까?

보다시피 우리에게 혼선을 주는 요소는 딱 두 가지이다. (1) 인명 '시몬'의 정체가 오락가락하고, (2) 머리와 발 부위 묘사만 다른 카테고리와 다른 방식으로 분류된다는 것.

하지만 사복음서에 기록된 사건의 큰 그림을 육하원칙에 의거해서 비교해 보면, 아무래도 누가복음만 다른 사건이고 마태· 마가는 동일 사건이라고 결론을 내릴 수 있다. 머리와 발에 모두 향유를 부었다고까지는 취합이 가능할지 모르나, 시몬이 바리새인 겸 나병 환자인 동일 인물이고 마리아가 과거가 추잡하기도 한 여자이고, 예수님이 한 장소와 한 시간대에 자기 장사 얘기와 "마리아 너의 죄가 용서되었다" 말을 동시에 하셨을 가능성은 아무래도 희박하다.

요한은 마태· 마가와 상당히 비슷한 사건이긴 하지만 궁극적으로는 다른 듯하다. 하지만 똑같이 300데나리온 드립이 나오고 예수님이 같은 이야기를 두 번이나 하셨다는 걸 생각하니 좀 이질감이 느껴지긴 한다.

다음에 교회에서 <내게 있는 향유 옥합 주께 가져와> 같은 찬양을 부를 일이 있을 때 참고하도록 하자. 가사를 분석해 보면, '깨뜨린다'는 마가복음에 있고, '발 위에 입맞추고 붓는다'는 내용은 누가복음에 있다. 여러 사건을 한데 살짝 뭉뚱그려 놨다는 뜻이다.

Posted by 사무엘

외국인 중에서 한글에 대해서 정말 경이로운 체계를 가진 우수한 문자라고, 심지어 라틴 알파벳보다도 더 훌륭하다고 극찬을 늘어놓은 석학들이 있다. 개중엔 재레드 다이아몬드처럼 언어학이 아니라 단순히 다른 인문학 분야를 전공한 사람도 있지만, 언어학을 본격적으로 전공한 학자, 그것도 레알 엄청난 괴수 중에도 한글 예찬론자가 있다.

이것 자체는 기록이 다 남아 있고 출처 검증도 가능한 엄연한 팩트이므로 더 의심하지 않아도 된다. "무슨 소수 민족에게 한글 보급"과 같은 급의 루머가 아니다.
또한, 창조과학은 생물학이나 지질학, 천문학을 직접 전공하지 않은 타 분야의 공학 박사나 의사들이 민다고 까이는 반면, 한글 예찬론은 일부나마 실제 현업 언어학자들로부터 지지를 받고 있으니 성격이 좀 다르다.

시카고 대학교의 제임스 맥콜리 교수는 잘 알다시피 한글날은 전세계의 언어학계가 다함께 경축해야 하는 날이라면서 10월 9일엔 휴강을 했던 것으로 유명하다.
연세 대학교가 배출한 가히 세계적인 언어학 석학인 김 진우 교수도 학부 모교로 돌아와서 석좌교수 명목으로 잠시 강의를 하던 때엔, 2학기에 한글날이 낀 주엔 문자의 역사 강의를 했다. 내가 수업을 듣던 시절에도 종종 한글 감탄을 늘어놓았으며, 한글날이 국경일이 아닌 것은 정말 통탄할 일이라고 말씀을 하셨다. (2011년, 아직 국경일이 아니던 시절에)

물론 꼭 그렇게까지 감흥을 느끼지는 않는 학자들도 있으며, 오히려 저런 식의 생각을 문화 제국주의니, 한글 쇼비니즘이니 뭐 이상한 꼬리표를 붙여서 불쾌하게 받아들이는 사람들 역시 없지는 않다.
이런 와중에 미천한(?) 본인이 한글이 우수하네 어떻네 하는 오래 된 고리타분한 논쟁에 불을 추가로 지피고 싶지는 않다. 그러나 관찰을 통해 발견할 수 있는 분명한 팩트를 하나 지적하고자 한다.

"한글은 뭔가 천재들을 매료시키고 오덕질 거리를 제공하기에 충분한 특성은 갖추고 있는 것으로 보인다."
그렇지 않고 단순히 한글이 한국어만 잘 표기해 내는 세계의 여러 평범한 문자들 중 하나일 뿐이라면, 한국어가 모국어가 아닌 외국의 언어학 석학 중에 한글 예찬론자가 나타날 수가 없었을 것이다.
또한 공 병우 박사처럼 언어와는 거의 관계 없는 전공이던 천재 공돌이 의학자가 갑자기 하필이면 한글 덕후 타자기 덕후로 돌변할 수도 없었을 것이다.

그래서 지금 있는 한글 자모나 한글 맞춤법 체계에 만족하지 못하고 한글을 외국어의 다른 음성을 표기하는 용도로도 쓸 수 있게 확장해야 한다고 주장하는 분들이 여럿 있다. 이 역시 주장자 중에는 이공계 박사나 의사 등, 스펙이 비범하긴 하지만 언어학만을 깊게 공부하지는 않은 사람이 있는가 하면, 음성· 음운론을 통달한 저명한 언어학자도 있다. 이 현복 교수 같은 엄청난 분도 그 중 하나이니까.. 그러니 이것은 단순히 비전문가 한글 덕후의 마이너한 재야 학설 정도로 마냥 치부할 문제도 아니다.

지금의 암호 같이 배배 꼬인 IPA 부호보다 더 체계적이고 알아보기 쉬운 음성 부호 체계가 한글의 제자 원리를 바탕으로 만들어진다면 그건 나름 의미있는 일일 것이다. 단, 거기에는 여러 전제조건과 단서가 붙어야 하고 현실적인 한계를 감안해야 할 것이다.

1. 당연한 말이지만, 그것은 지금 한국어를 표기하는 한국어 정서법(일명 한글 맞춤법)과는 완전히 별개로 따로 가는 체계가 되어야 한다. 한글의 표기 능력 같은 걸 떠나서 한국어에는 영어 F나 TH 같은 음가 따위는 존재하지 않는다. R과 L을 똑같이 ㄹ로 적는 이유는 한글을 모독하기 위해서(?)가 아니라 그게 한국어에서 음운론적인 변별 요소가 아니며, 고로 굳이 구분해서 적을 필요가 없기 때문이다.
과거에 조선어 학회가 무단으로, 혹은 심지어 일제와 결탁까지-_-해서 옛한글 자모를 없애고 훈민정음을 한글로 절뚝발이로 만들어 버렸다고 얘기를 하는 분을 보면.. 으음, 숨이 탁 막힌다. 나머지 뒷부분의 주장까지 신뢰성이 팍 깎이게 된다.

2. 옛한글 자모는 어떻게 활용할 것이며 한국어에 없는 소리를 어떤 규칙대로 새로운 글자에다 대응할지.. 통일이 잘 돼야 한다. 허나, 국내에 계신 한글 확장 연구가들은 내가 알기로 제각각 정말 개성 넘치고 자기 지론과 고집이 강한 분들이다. 과연 호락호락 합의가 가능할까? 아래아의 음가조차도 정확하게 모르는 마당에 하물며 다른 글자들은.. 글쎄다.
또한 한글이 기본적으로 제공되는 모음이 풍부한 건 사실이지만, 발성 기관의 모양을 본뜬 자음과는 달리 모음은 기하학적인 수직· 수평선과 점뿐이다. 이런 제자 컨셉만으로 단순히 이중모음이 아니라 IPA의 온갖 이상한 모음들을 다 그려낼 수 있을지에 대해서도 생각해 봐야 한다.

3. 알다시피 유니코드가 제정되고 BMP 영역은 마치 IPV4 주소만큼이나 사실상 고갈이 임박한 이 시점에서..
인제 와서 컴퓨터에서 예전에 없던 문자를 새로 만들어 통용하는 건 굉장히 부담이 큰 모험이다. 더구나 조합을 해서 상황에 따라 달리 표현하는 건 거의 불가능에 가까워졌다고 봐야 한다. 새로운 한글 확장 부호가 겨우 PUA 영역에만 머무르는 듣보잡이 아니라 정식으로 등재되어 쓰이려면, 국가 표준이든 대중적인 표준이든 정말 갈 길이 멀다. 그런데 그것이 과연 가능할까.

4. 새로운 한글 입력법을 같이 제안하는 분도 있다. 단, 이들도 PC에서의 표준 두벌식 글자판과 대놓고 싸우지는 않는다.
그나마 표준 두벌식 다음으로 인지도가 제2순위로 높고 모든 데스크톱 운영체제에서 이미 지원까지 되고 있는 가장 이상적이고 합리적인 대안이 바로 공 병우 세벌식인데.. 이마저도 전체 사용자 수는 1%가 채 안 된다.

그러니 하물며 이것보다도 더 마이너들은 동일한 조건에서는 전혀 승산이 없다고 봐야 한다. 그 대신 다른 차별화 요소를 통해 틈새시장을 공략하는데, 크게 (1) 모바일, (2) 장애인 접근성, (3) 지금까지 얘기했던 외국어 표기를 위한 다른 정서법으로 나뉜다. 허나 내가 보기엔 이것들도 이젠 그 많은 연구자들이 아웅다웅 다투기에는 그릇 크기가 너무 작은 레드 오션이다.

마치 이족 보행 로봇이 창작물이 아니라 현실에 등장할 가능성만큼이나 이건 녹록치 않은 문제이다.
그래서 나는 없는 정서법을 새로 만들려는 시도는 감히 하지 않는다.
개인적인 생각으로는, 음성 부호 연구보다는 이미 있는 한글 체계에 대해서 세벌식 글자판 연구나 훨씬 더 중요하게 국가 차원에서 진행했으면 좋겠다. 한국어+한글 기성 체계만으로 domain을 한정하더라도 입출력 기술 쪽으로 한글의 고유한 특성을 활용해서 새로 개발해야 할 것이 즐비하다. 그리고 그것이 나의 관심사이다. 자세한 사항은 아직 기밀이다만.

각 사람들이 자기 오덕 기질과 똘끼를 발휘하여 한글을 응용한 솔루션을 내놓고, 그것이 자연스럽게 시장의 선택을 받아서 채택되거나 도태한다면 나쁠 게 없는 현상이다. 허나 시장이라는 게 그렇게 건전하게만 돌아가는 게 아니고, 또 얼치기 한글 장사꾼이 나랏돈 타서 병크를 다 저질러 놓음으로써 나중에 동일 분야의 후학에게 돌아갈 혜택과 지원까지 막아 버린다면.. 이건 좀 큰 문제이고 비극인 것 같다. 이 문제를 어찌하면 좋을지 고민된다.

한 줄 요약: 한글은 독창적이고 과학적이고 충분히 우수한 문자인 건 틀림없다. 허나, 한글의 우수성을 살리고 싶다면 솔까말 음성 부호 연구보다는 지금 상황에서는 세벌식 연구가 훨씬 더 필요하고 절실하다.

Posted by 사무엘