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

<날개셋> 한글 입력기를 사용하는 프로그램들은 입력 설정을 바꾸는 UI인 '날개셋 제어판'을 꺼내는 기능이 들어있다. 그 프로그램으로는 편집기, 외부 모듈, 입력 패드, 그리고 타자연습 이렇게 4종류가 있는데, 제어판을 꺼내는 방법은 일반 메뉴, 입력 도구모음줄, 시스템 트레이 우클릭 메뉴, 대화상자의 버튼 이렇게 형태가 제각각 모두 다르다. 어째 이렇게 전부 다를 수 있는지도 궁금한 지경이다.

그런데 사실은 이 프로그램들이 내부적으로 제어판을 운용하는 방식도 전부 다르며, 미세한 차이가 존재한다. 본인은 이와 관련된 코드 리팩터링 작업을 하다가 차이점들을 글로 한데 정리해 보았다.

1. modality

중앙 집권적인 EXE 프로그램인 편집기와 입력 패드는 modeless 형태로 구동된다. 제어판 창을 띄워 놓은 채로 본문의 입력란으로 얼마든지 이동 가능하며, 제어판의 우측 하단에 '적용'이라는 버튼도 응당 존재한다.

그러나 외부 모듈과 타자연습은 modal이다. 외부 모듈의 경우 중앙 집권이 아니라 각각의 프로세스들에 붙어서 돌아가는 일종의 떨이이며, 제어판이 떠 있는 동안 자기가 담당하던 스레드가 없어지는 것을 포함해 갖가지 상황이 밖에서 벌어질 수 있다. 그렇기 때문에 상황 관리의 복잡도를 제어하기 위해서 제어판 창이 뜬 동안은 원래의 입력란으로 돌아갈 수 없게 했다.

타자연습은 외형은 중앙 집권이긴 하지만, 무슨 텍스트 에디터처럼 문자 입력이 상시 가동 중인 채로 제공되는 프로그램은 아니다. (타자 연습 화면은 메뉴에서 뭔가를 선택한 뒤에만 나타남) 그러니 제어판을 띄워 놓은 채로 타자 연습을 한다거나 메뉴로 돌아가는 상황은 생각하지 않으며, 자연스럽게 modal UI를 채택했다. 날개셋 제어판을 열었다면 이것부터 닫아야 이전 단계 화면으로 돌아갈 수 있다.

2. 입력 설정을 읽고 쓰는 방식

사실, 대화상자의 모달 여부나 다른 것보다도 이게 제일 중요하고 본질적인 차이점이다.

(1) 중앙 집권적인 편집기와 입력 패드는 형태가 제일 깔끔하고 단순하다. 그냥 공통 단일 입력 설정 하나만을 읽고 쓰는 걸로 끝이다.
공통 설정은 <날개셋> 한글 입력기 커널이 관리하며, 이걸 파일로 저장한 게 바로 imeconf.dat이다. 그러면 프로그램을 다음에 실행할 때도 예전의 입력 설정들이 고스란히 보존된다.

제어판을 '확인'으로 종료하면 메모리와 파일이 모두 업데이트된다. 그러나 '미저장 확인'이나 '적용'을 누르면 메모리만 업데이트된다. 이 두 버튼은 대화상자를 닫는지 여부의 차이만이 존재한다.

(2) 위의 두 프로그램과는 달리 타자연습은 imeconf.dat를 읽거나 쓰지 않으며, 사용자 계정에 있는 자체적인 입력 설정을 사용한다. 그렇기 때문에 공통 설정이라는 개념을 사용하긴 하지만 메모리 수준에서만 사용하지 imeconf.dat를 다루는 파일 수준은 사용하지 않는다. '확인'과 '미저장 확인'의 구분이 존재하지도 않는다.

(3) 끝으로, 외부 모듈은 타자연습과는 또 정반대다. 외부 모듈은 타자연습 같은 독자적인 원천이 있는 건 아니며 필요하다면 imeconf.dat 파일을 읽고 쓰기도 한다. 하지만 그걸 메모리에 보관할 때는 공통 설정을 사용하는 게 아니라 스레드별로 자신만의 고유한 storage를 사용한다.

다시 말해 외부 모듈은 공통 설정 파일만 사용하지 메모리를 사용하지는 않는다. 이렇게 설계된 가장 큰 이유는 외부 모듈이 자신과 동일한 날개셋 커널을 사용하는 프로그램 밑에서 동작하더라도 EXE/DLL 모듈간에 입력 설정 충돌을 일으키지 않고 서로 입력 설정을 따로 관리할 수 있게 하기 위해서이다. 외부 모듈 혼자만 이렇게 남을 알아서 피해 가면 되며, 다른 프로그램들은 굳이 이렇게 동작해야 할 필요가 없다.

외부 모듈에서 연 제어판은 앞서 언급한 이유로 인해 '적용' 버튼은 사용할 수 없다. 하지만 '미저장 확인'은 있는데, 이걸 누르면 지금 맞춘 입력 설정이 외부 모듈을 사용하는 모든 프로그램들에서 한데 동기화되는 게 아니라 지금 실행 중인 프로그램/스레드에서만 잠깐 사용 가능하게 바뀐다. 한글 표현 방식 옵션도 레지스트리에 영구적으로 기록되는 게 아니라 지금 메모리에만 반영된다. 이런 것도 외부 모듈이 스레드별로 독립된 storage를 갖고 있기 때문에 구현 가능하다.

아, 하나 더.. '미저장 확인'은 제어판을 입력 도구모음줄을 통해서 열었을 때에만 나타난다. 운영체제의 제어판/설정이 제공하는 메뉴를 통해서 연 것은 문자 입력 문맥이 아니기 때문에 '미저장 확인'이 가능하지 않으며, '확인'을 눌러서 파일에 기록하는 영구적인 저장만이 제공된다.

3. 외부 모듈과 패드 공통

편집기와 타자연습은 자체 구현된 전용 에디트 컨트롤에다가만 글자를 생성한다. 하지만 외부 모듈과 입력 패드는 타 프로그램에다가 글자를 생성한다. 그렇기 때문에 이들 프로그램에서는 제어판의 시스템 계층에 '한글 표현 방식'이라는 탭이 존재하며, 빠른설정이나 낱자 결합에서 옛한글을 지정하면 "한글 표현 방식부터 맞춰야 옛한글이 실제로 나타납니다"라는 안내문이 나타난다.

또한 텍스트를 보낼 수만 있지 읽어 오고 고칠 수 없는 환경에서는 이런 동작과 관련된 기능과 옵션들이 몽땅 사용 불가 상태가 된다. 앞 글자로 달라붙는 bksp 옵션이나 단어 단위 한자 변환이 대표적인 예이다.
입력 패드는 이런 기능들이 무조건 사용 불가이고, 외부 모듈은 TSF A급 환경에 한해서 그런 기능들을 사용할 수 있다.

4. 외부 모듈 only

외부 모듈에서 제어판을 띄웠을 때는 유일하게 시스템 계층에 '외부 모듈 관리' 탭이 나타나지 않는다. 그 대신 '고급 시스템 옵션'을 갖고 있다.
또한, 구현체들 중 유일하게 외부 모듈만이 Alt가 섞인 단축글쇠를 전혀 인식할 수 없기 때문에 단축글쇠 대화상자에서 Alt를 나타내는 슬라이더가 사용 불가 상태로 바뀐다.

지금까지 논의한 사항들을 또 표로 깔끔하게 정리하면 다음과 같다. 아래의 4개 항목은 자료구조· 알고리즘의 차이가 아니라 그냥 UI 처리 차원에서의 차이일 뿐이다. 타자연습은 특이사항이 거의 존재하지 않아서 단순하고, 외부 모듈은 동작 환경이 변화무쌍하다 보니 조건부로 동작하는 게 굉장히 많음을 알 수 있다.

Posted by 사무엘

1. 블레이크 스톤 (Blake Stone)

먼 옛날 기억을 되살려 보니, 본인은 1990년대 중반에 울펜슈타인이나 둠 같은 id 사의 게임 말고 다른 계열의 3D FPS 게임을 친구 집 컴퓨터에서 본 적이 있었다. Doom처럼 좀 SF스러운 분위기이지만 Doom은 아니고 그것보다는 기술 수준이 뒤떨어졌다. 열쇠가 없는 상태로 잠긴 문을 열려고 하면 깜찍한 소리로 문이 열리지 않는다는 피드백이 왔다. (울프와 둠에는 청각 피드백이 없음)

그리고 제일 결정적인 단서로는.. 체력이 막대기나 숫자나 주인공의 얼굴 상태로 표시되는 게 아니라 검은 배경에 초록색 파형인 심전도 그래프로 나타났다. 완전히 죽어 버리면 물론 심장 박동이 없어진다.
이 모든 조건을 만족하는 게임을 검색해 보니.. Blake Stone이다.

기술적으로는 얘는 울펜슈타인 3D 엔진을 기반으로 개발되었다. 그렇기 때문에 높이를 표현할 수 없으며 레벨 배경은 여전히 건물 안으로 제한된다. 그러나 얘는 울프와는 달리 (1) 바닥과 천장에도 텍스처를 얹어서 그래픽을 고급화했으며, (2) 시점에서 먼 곳은 살짝 더 어둡게 표시되는 걸 구현했다. 게다가 얘도 미래가 배경이기 때문에 높이가 없다는 것만 빼면 전반적으로 둠과 분위기가 비슷해 보인다.

얘는 분명 나쁘지는 않은 게임이었으나, 스케일과 기술 수준 등에서 둠의 적수가 될 수는 없었다. 게다가 너무 늦게 나왔다. 출시일이 1993년 12월. 얘가 발매되고 나서 겨우 1주일 뒤에 Doom이 출시되는 바람에 블레이크 스톤은 존재감이 싹 묻혀 버렸다.

2. 퀘이크 1의 베타 3

본인은 중학교 말년에 어느 이웃집 형이 가져온 불법복제 백업CD를 통해서 퀘이크라고 둠의 다음 세대 게임을 처음으로 접했다. 그때는 지금 같은 고속 인터넷망이 없었으니 어둠의 경로에서 소프트웨어 불법복제를 책임지던 매체는 CD였다.
요즘은 아무 컴퓨터에나 당연하게 달려 있는 CD 쓰기/굽기 기능도 그때는 고가의 기계를 따로 돌려야 할 수 있는 첨단 기능이었다. 어디 그 뿐이랴? 요즘은 인터넷, USB 메모리, 외장 하드의 발달로 인해 광학 드라이브의 필요 자체가 극도로 줄어들어 있으니 격세지감이 아닐 수 없다.

그렇게 본인은 오랫동안 도스용 퀘이크 1을 즐겼다. 486 66MHz짜리 컴퓨터로는 퀘이크는 기본 최저 해상도인 320*200/240대에서나 제대로 프레임이 나왔지 640*480으로는 도저히 제대로 할 수 없었다. 그러고 보니 동일한 영어 이니셜을 갖고 "그 FPS(1인칭 슈팅) 게임은 이런 사양의 컴터에서 FPS(초당 프레임 수)가 얼마나 나오냐?" 이런 드립을 치는 게 가능하구나.;;

세월이 흘러 2000년대 중반이 되었고, 본인의 컴퓨터는 퀘이크를 처음 접하던 시절보다 당연히 성능이 월등히 더 향상된 걸로 바뀌었다. 본인은 옛날 생각에 Windows용으로 포팅된 퀘이크를 고전 게임 사이트에서 구해서 돌려 봤다.
그런데 이 퀘이크는 내가 옛날에 하던 퀘이크와는 미묘하게 다른 게 많았다. 정자체에 가깝던 화면 글꼴은 bloody한 분위기를 내려는 듯 좀 흘리고 날린 형태로 바뀌었다. 메뉴를 꺼내면 뒤의 게임 배경이 단순히 팔레트만 바뀌는 게 아니라 시꺼먼 하프톤 점이 쫙 깔렸다.

각 에피소드별로 모아야 하는 아이템의 이름을 본인은 10여 년 가까이 sigil이라고 알고 있었는데 이 게임은 rune이라고 표현했다.
그 이름도 유명한 무기 파워업 아이템은 quake power이라고 알고 있었는데 그게 이 퀘이크에서는 quad damage였다.
새로 구한 퀘이크는 에피소드 2의 마지막 레벨은(비밀 레벨 말고) 물웅덩이를 중심으로 사방으로 이동해서 다리를 내는 형태였는데 내가 기억하는 맵이 아니었다. 또한 에피소드 3의 마지막 레벨의 끝부분에서 Vore 두 놈은 높은 곳에서 튀어나왔으나, 이 게임은 다리 아래 용암 바닥에서 튀어나왔다.

차이점은 이 뿐만이 아니다. 에피소드 1의 보스인 Chthon의 생김새도 내가 기억하던 모양이 아니었다. 내가 하던 퀘이크는 얼굴도 몸통과 비슷한 색깔이고 눈이 있었던 반면, 이 퀘이크는 딱히 눈 같은 게 없고 얼굴 전체가 세로로 난 입의 이빨 같은 것으로 둘러져 있었다.

결정적으로 게임 전체의 최종 보스인 Shub-Niggurath와 싸우는 마지막 레벨은 완전히 다른 맵으로 바뀌어 있었다.
내가 기억하는 마지막 맵은 요렇게 뭔가 에피소드 4의 비밀 레벨과 비슷한 분위기였다. 나중에는 천장이 청록색인 거대한 필드에 도달하고, Shub-Niggurath가 있는 곳까지도 갈 수는 있지만 여기서 더 보스를 죽이거나 게임을 진행해서 엔딩을 볼 수는 없었다. 적을 다 죽인 뒤에 어떻게 해야 할지를 몰랐다.
(그나저나 퀘이크는 다 뭘 참고해서 몬스터들의 이름을 지었는지, 스펠링이 다 읽기 힘든 형태이다.)

이렇게 내가 경험했던 퀘이크에 차이가 존재했던 이유는 이미 제목에 쓰여 있다. 내가 중딩 시절 옛날에 했던 퀘이크는.. 바로 퀘이크 정식 버전이 발매되기 불과 2주 남짓 전에 유출된 '0.8 베타 3 버전'이었기 때문이다. 그게 어째 어떤 복돌이가 만든 백업 CD에 포함되었던 것이다. 난 10년이 넘게 베타 버전 퀘이크가 정식 퀘이크인 줄로 알고 있었다.
그래도 이런 것도 이제 검색해 보면 구체적인 출시 내역을 다~ 알 수 있고.. 옛날 기억도 어지간한 건 다 복원 가능한 세상이 됐으니 참 대단하다.

beta 3 구버전의 구동 및 플레이 동영상을 짤막하게나마 유튜브로 다시 보니 감회가 새롭다. 구버전은 마지막 레벨을 클리어 하는 엔딩이 원래 존재하지 않았던 게 맞았다. 미완성이었다.
그에 반해 정식 버전은 적절한 타이밍에 순간이동 장치로 들어가서 Shub-Niggurath의 몸 속으로 '텔레프래깅'을 하는 방식으로 적을 죽여서 엔딩을 볼 수 있다.

더 생각나는 걸 열거하자면, 몬스터 Ogre가 톱질 하는 소리가 구버전 것은 정식 버전의 것보다 피치가 좀 더 낮았다. Vore가 쏘는 탄환이 구버전은 그냥 용암 fireball과 동일했지만 정식 버전은 보라색 공으로 바뀌었다.

또한, 주인공이 뭔가에 깔려 죽었을 때 구버전은 be crushed라는 말을 썼지만 정식 버전은 be squished라고 말을 바꿨더라. 본인은 crush라는 단어를 둠과 퀘이크를 통해서 알게 됐다. Doom 2에서도 레벨 6이 The crusher이기도 하고 말이다. 끝으로, 구버전에서는 Ogre 이상 몬스터들은 로켓 같은 무기로 오버킬을 당해도 결코 육편 피떡으로(gibbed) 변하지는 않았던 걸로 기억한다.

id에서 1990년대 중반에 개발했던 Doom과 Quake들은 묘사가 잔혹할 뿐만 아니라 오각형, 염소 뿔 등 의도적으로 오컬트나 사탄 숭배교를 표방하는 듯한 비주얼이 많이 들어가 있었다.
그래서 자국 내에서도 이런 비판을 많이 받았는가 보다. 파일로 제공되는 도움말 문서를 보면, FAQ 중 하나로 "Are you guys Satan-worshipers?"가 있고, 이에 대한 답변은 No 한 마디로 간단히 일축해 놓았다.

그런데, 이것도 구버전의 도움말 문서는 간단히 No만 있는 게 아니라.. "아니요, 우리는 그냥 오각형과 666을 좋아할 뿐입니다."라는 부연 설명도 들어있었다. 중고딩 시절에 분명히 읽었던 기억이 있다.
id는 전통적으로 종료 확인 메시지도 그렇고 말을 전반적으로 익살스러운 농담조로 하는 걸 좋아하긴 한데, 이 질문에다가도 답변을 그런 식으로 하면 기독교 단체 같은 데에다가 더 큰 논란과 어그로를 일으킬 것 같으니 저 말을 삭제한 듯하다.

3. 기타

10대 중반의 나이로 접했던 FPS들은 나의 가치관 형성에 많은 영향을 줬다.

요렇게 거의 270도 턴을 해서 미로처럼 꼬불꼬불 들어가게 돼 있는 건물 화장실을 이용한 적이 있었다.
벽면 텍스처도 규칙적인 형태인 게 무슨 둠 맵 같다. 문은 좌우로 열리는 게 아니라 셔터처럼 위로 열릴 것 같다.
이런 모양의 맵을 설계하면 bsp 파일이 어떤 형태로 만들어질까 이런 게 머리에 어른거린다. -_-;;

정확하게 1인칭 시점인 건 아니지만 툼 레이더도 있다.
선유도 공원을 가 보면 거긴 잡초가 낀 야외 콘크리트 구조물이 영락없이 툼 레이더 1 맵 같다.
손에 쌍권총 쥐고 옆으로 점프라도 하고 싶은데.. 그랬다가는 다치겠지.

말이 나왔으니 말인데, 내 생각에 적당히 스토리만 잘 짜 놓으면 우리나라 DMZ를 배경으로 툼 레이더 커스텀 레벨 얼마든지 만들 수 있다고 본다. GP에 들어가서 아이템 먹고 북한군을 때려잡는 식으로 진행될 것이다.
Demilitarized Zone 이름도 얼마나 근사하냐? ㅋㅋ

Posted by 사무엘

이번 8.8은 이례적으로 다음 버전 개발 근황을 두 차례나 올리게 됐다. 분량을 나눠야 할만큼 작업이 활발하게 진행 중이라는 뜻이다. 번호를 9부터 시작해야 하나 싶은데.. 첫 근황을 올린 지 시간이 몇 주 정도 지났으니 다시 1로 리셋하도록 하겠다.
난 정말 날개셋 한글 입력기 코딩을 할 때가 제일 즐겁고 행복하다.

1. 사용자 정의 조합 편집 관련 기능 개선

10여 년 전 3.9 버전에서 '고급 입력기'가 첫 도입되었다. 원래 있던 '기본 입력기'의 지원 범위는 한글 한 글자의 조합인데(지금은 방점을 임시로 같이 묶어서 표현하는 것까지만 추가로 더 포함), 고급 입력기는 그 한계를 넘어서 한글이 아닌 글자의 조합도 표현하거나, 한글 하나를 여러 글자(한글 또는 비한글 모두)로 풀어서 표현하는 것을 지원한다. 전자를 위해서 '사용자 정의 조합'이 도입되었고, 후자를 위해서 '한글 출력 치환' 기능이 추가되었다. 이로써 조합 상태와 관련된 추상화 계층이 그럭저럭 완성됐다.

이번 버전에서는 그 중 '사용자 정의 조합' 쪽에 편의 기능이 추가되었다. 먼저, 제어판에서 사용자 정의 조합만 단독으로 파일로 저장하고 불러올 수 있게 했다. 바이너리 형태로 저장하는 것은 별 의미가 없다고 여겨져서 XML 형태만 지원한다.

그러니 이제 글쇠배열은 영문 쿼티로 그대로 두고, 알파벳을 기반으로 여러 방식으로 특수문자들을 입력하고 싶을 때 사용자 정의 조합 로직만 교체해서 문자 입력을 할 수 있게 됐다. 이 달 초에 소개했던 새 기능 중, 글쇠배열 이름뿐만 아니라 입력 스키마의 자체적인 이름을 부여하는 기능도 이런 맥락에서 도입된 것이다.

단, 비슷한 기능을 하는 한글 출력 치환은 여전히 단독 저장을 지원하지 않기 때문에 이건 형평성 문제가 될 수 있다. 그럼에도 불구하고 사용자 정의 조합에만 단독 저장과 불러오기 기능이 추가된 이유는.. 불러오기와 관련하여 큰 개선 사항이 또 생겼기 때문이다.

지금까지 사용자 정의 조합 로직을 설계하기 위해서는 w를 눌렀을 때 분기할 상태, 그 뒤에 a를 눌렀을 때 분기할 상태 등등을 숫자를 생각하면서 사용자가 일일이 설계해야 했다. 이런 불편을 덜기 위해 이번 버전에서는 이 프로그램이 내부적으로 사용하는 자료 구조를 그대로 노출하는 XML 스키마 말고, 사용자 친화적인 일명 '쉬운 문법' 스키마도 추가했다.

"wa = わ" 이런 쌍만 쭉 지정해 주면 w와 wa를 입력했을 때의 중간 과정과 상태 번호를 자동으로 매겨 준다는 것이다. 입력 파일 포맷을 구체적으로 어떤 형식으로 짜면 되는지는 물론 예제에다 소개해 놨다. 쉽게 말해 아래 그림에서 왼쪽처럼 만들어 놓으면 자동으로 오른쪽으로 만들어 준다는 뜻이다.

사실, 현재 예제로 제공되는 일본 문자 입력 로직은 히라가나/가타카나 테이블로부터 로직을 자동으로 짜 주는 툴을 내부적으로 돌려서 생성한 것이다. 사람의 손으로 60개가 넘는 state들을 알파벳 순으로 노가다로 생성한 건 물론 아니니까. 그 툴을 <날개셋> 한글 입력기 내부에 정식으로 포함시킨 거라고 생각하면 된다.

물론, 쉬운 문법은 내 프로그램이 인식하고 변환하는 걸 지원한다는 뜻이지, 프로그램이 내부적으로 사용하는 자료구조는 아니다. 그렇기 때문에 불러오기만 지원되지 저장은 안 된다. 쉬운 문법 원본은 사람이 따로 관리하고 갖고 있어야 한다.

또한 제어판 대화상자에서도 어떤 상태에 대해서 'called from 링크'를 찾아서 보여주는 기능을 추가했다. 30이라는 상태가 있으면 그 30이라는 상태로 분기하는 예전 상태.. 가령, 25번 상태에서 a를 누르면 30으로 간다는 걸 보여준다. 현재는 선택막대를 더블 클릭하면 앞으로 나아가는 calls to 링크만 지원되고, 뒤로 돌아갈 수는 없어서 불편했는데 이것 역시 개선됐다.

2. 단어 단위로 한자 변환

단어 단위로 한자 변환을 할 때 지금처럼 '뒤에서 앞으로 탐색'뿐만 아니라 '앞에서 뒤로 탐색'도 가능하게 옵션을 추가했다(제어판 - 편집기 계층). 예를 들어, '토선생'이라는 신조어에 대해서 한자 변환을 하면 '선생'이 아니라 '토선'이 블록이 잡힌 상태가 되며, '토선'을 변환한 뒤에 cursor는 다시 '생' 뒤로 되돌아온다.

지금까지는 조합 중인 글자나 cursor 바로 앞에 있는 글자가 반드시 단어의 마지막 글자에 포함돼 있어야 했지만 이제 그런 제약이 없어진 것이다. MS IME 내지 아래아한글이 동작하는 방식을 내 프로그램도 드디어 제대로 지원하게 됐다.

단어 단위로 한자를 변환하는 기능은 2012년에 나온 6.7 버전에서 '시범적으로' 추가되었다. 어차피 TSF A급 프로그램에서나 제공 가능한 기능이고(이건 MS IME도 마찬가지임), 그저 없는 것보다는 낫다는 차원에서 추가된 액세서리 기능일 뿐이기 때문에 동작 방식이 기존의 한 글자씩 변환하는 기능의 연장선 수준을 벗어나지 못했다. 저렇게 cursor가 통째로 앞으로 갔다가 변환 후에 되돌아오는 것은 <날개셋> 한글 입력기의 기존 프로토콜로 표현할 수가 없었다.

그러다가 그 내부적인 한계는 수 년 뒤, 작년에 나온 8.2에서 프로토콜을 확장함으로써 극복되었다. 입력 패드 구현체에다가도 한자 변환 기능을 구현하면서 작업을 싹 다시 했기 때문이다. 이때 테스트 차원에서 한자어가 굳이 cursor 바로 옆에 있지 않은 변환도 구현 가능한 것까지 확인했다.

하지만 이 코드는 말 그대로 테스트 코드일 뿐, 기존 한자 변환 코드와 융합 가능한 형태가 아니었기 때문에 조건부 컴파일로 기존 코드와 테스트 코드 둘 중 하나만 적용 가능했다. 게다가 테스트 코드는 중간에 ESC를 눌러서 한자 변환을 취소했을 때에도 cursor만 곱게 이동하는 게 아니라 변환 대상 텍스트를 불필요하게 덮어쓰는 등 한계도 있었다.

그러다가 8.8 버전에 와서야 오랜 숙제로 남아 있던 한자 후보 변환 관련 코드를 완전히 다시 작성했다. 한글 조합 상태일 때와 그렇지 않을 때를 불문하고 동일한 로직이 동작하게 했으며, 한 글자 한 글자 답답하게 앞으로 탐색하던 것을, 쿨하게 처음부터 맨 앞 글자들을 최대 30자 가까이 가져온 뒤 후처리를 하는 걸로 과정을 단순화했다. 그러면서 기존의 뒤-앞 탐색 부분에다가 옵션으로 seamless하게 병행하는 차원에서 앞-뒤 검색도 구현해 넣었다.
'초성 지향 도깨비불'(예: '간'을 '가ㄴ'으로)이나 호환용 낱자 변환으로 인해 당장 화면에 보이는 글자와 후보 변환 때 사용되는 글자가 서로 같지 않을 때의 보정 처리도 이 기회에 별도의 추상화 계층으로 싹 분리했다.

앞-뒤로 탐색했을 때 단어 단위 한글-한자 변환이 가능하지 않으면 그냥 지금 조합 중이거나 cursor 앞에 있는 한자 한 글자에 대한 한자 변환이 시도된다. 한글을 조합하던 중에 앞-뒤로 탐색하면 뒤-앞 방식으로 동작할 때와는 달리 지금 조합이 종료된다. 왜냐하면 cursor가 잠시 앞으로 이동해 버릴 수도 있으니 지금 조합 상태가 더 유지될 수 없기 때문이다. 그래도 한자로 변환될 예정인 부분이 블록으로 잠시 highlight가 되기 때문에(외부 모듈) 이 방식이 시각 피드백은 더 우수하다.

이런 뜻깊은 기능의 구현과 리팩터링 작업이 왜 이제 와서야 행해졌는지 모르겠다. 작업에 개인적으로 큰 보람을 느낀다.
그리고 이 작업을 하는 과정에서 덤으로 외부 모듈의 버그도 하나 발견해서 수정했다. TSF A급 프로그램에서 한글을 조합하지 않은 상태에서 한글 뒤에서 도구모음줄의 한자 버튼을 눌렀을 때.. 편집기와 같은 저런 한자 변환이 케바케로 되지 않는 문제가 있었다. 적어도 8.x 버전 내내 존재했으리라 여겨지는 문제이다.

3. 비주얼 관련

깨알같은 사소한 변화이긴 하다만, 지난 8.6에서 외부 모듈에서 추가되었던 '키보드 드라이버 변경' UI에다가 방패 아이콘을 추가했다. 이건 변경을 위해 관리자 권한이 필요하다는 걸 강조하기 위해서이다.
버튼에다가는 옵션 하나만 추가하면 문구 옆에다 방패 아이콘을 간단히 넣을 수 있지만, 콤보박스나 static 컨트롤에다가 방패 아이콘을 넣는 기능은 없는 것 같다. picture 컨트롤을 하나 더 집어넣어야 했다.

Windows는 IDI_ERROR, IDI_QUESTION 같은 몇 가지 기성 아이콘을 제공하기 때문에 응용 프로그램에서는 LoadIcon이나 LoadImage 함수를 통해 이것들을 가져올 수 있다. 메시지 박스에다가는 MB_ICON* 형태의 플래그를 지정해서 집어넣을 수도 있다.
그리고 Vista부터는 사용자 계정 컨트롤에 대한 시각 피드백을 제공하라는 취지로 방패 아이콘도 IDI_SHIELD라는 명칭으로 제공한다. 이들은 모두 내부적으로는 user32.dll의 리소스 형태로 존재한다.

IDI_SHIELD는 그 성격상 32*32 이상의 크기보다는 글자와 어울리는 16*16, 20*20 같은 아담한 형태로 훨씬 더 많이 쓰인다. 그런데 문제는 얘는 LoadIcon이나 LoadImage 같은 재래식 함수로는 제대로 그릴 수 없다는 것이다.

옛날부터 있었던 IDI_ERROR 같은 메시지박스 아이콘들은 최대 크기가 끽해야 48*48이 고작인 반면, 21세기에 추가된 IDI_SHIELD는 무려 256*256 크기까지 존재한다. 구조가 특이해서 그런지 LoadIcon은 물론이고 LoadImage로 크기를 지정해 줘도 작은 크기가 로딩되지 않고 제일 큰 놈으로만 그려진다. 큰 그림을 16*16, 20*20으로 강제로 줄이면 보기가 아주 흉측해진다.

그래서 방패 아이콘은 내 경험상 Vista에서부터 추가된 LoadIconMetric이라는 특수한 함수를 써야만 작은 크기로 보기 좋은 HICON을 가져와서 그릴 수 있다. 이 함수는 user32도 아니고 생뚱맞게 comctl32.dll에 있다. 세월이 흐르면서 API 설계의 일관성이 좀 깨지고 뒤죽박죽이 된 것 같다.

게다가 리소스에 있는 아이콘을 있는 그대로 read-only 공유 형태로 가져오기만 했다면 대개는 DestroyIcon을 할 필요가 없는데 저 함수의 리턴값은 언제나 소멸 처리도 해야 해서 더 불편하다. 뭐, Windows 프로그래밍에는 아이콘 나부랭이 하나 찍는 일에도 이런 복잡한 사정이 있더라.

그리고.. 진짜 사소한 거다만, 도움말에 있는 프로그램 스크린샷들을 드디어 Windows 10 기준으로 다 교체했다.

4. 옛한글 입력 설정이 되지 않았을 때의 알림 메시지

이제 더 고칠 게 없을 것 같은 입력 패드에도 improvement가 있었다.
트레이에 있는 입력 패드 아이콘을 마우스로 가리키고 있으면 현재 선택돼 있는 글자판의 이름이 툴팁으로 뜨는데, 이게 제어판의 실행으로 인해 글자판의 이름이 변경된 것은 같이 업데이트 되지 않는 걸 뒤늦게 발견하여 수정했다.

그리고 외부 모듈과 입력 패드는 옛한글을 입력하기 위해서는 제어판 시스템 계층의 '한글 표현 옵션'부터 먼저 설정해 줘야 한다는 공통점이 있다. 비트맵 자체 글꼴 전용 환경인 편집기와는 달리, 밖에서는 사용자가 옛한글을 지원하지 않는 글꼴을 사용하고 있을 수 있으며, 또 옛한글을 표현하는 방식도 역사적인 이유로 인해 여러가지가 존재하기 때문이다.

하지만 이런 사정을 모르는 사용자의 입장에서는 분명히 옛한글 입력으로 설정을 했는데 옛한글이 찍히지 않는다면 프로그램의 이상이라고 생각할 수 있다. 물론 제어판도 편집기가 아닌 타 환경에서 동작할 때는, 사용자가 빠른설정이나 낱자 결합 규칙을 옛한글과 관련된 것으로 변경할 때 "옛한글을 사용하려면 한글 표현 방식도 맞춰 주세요"라고 짤막한 메시지를 출력하긴 하지만 이것만으로는 좀 부족한 감이 있다.

입력 패드는 키보드 포커스를 건드리지 않고 시스템 트레이에다 말풍선 형태로 메시지를 찍는 아주 편리한 UI를 갖추고 있으니 이런 기능을 추가하는 게 아주 용이하다.

(layered window든 동영상이든 화면에 보이는 건 무엇이건 print screen으로 간단히 캡처하는 시대가 된 지 오래인데, 시스템 트레이의 말풍선 윈도우는 의외로 고전 테마에서는 print screen 캡처가 안 되더라..! DWM이 동작하는 AERO 테마를 띄워야 캡처가 됐음..)

참고로 지금까지 입력 패드는 입력과 관련된 기술적인 에러 메시지를 찍는 기능만 있었다. 권한 차이로 인해서 입력 패드가 메시지를 보낼 수 없는 윈도우일 때, 그리고 해당 윈도우가 IME 컨텍스트가 존재하지 않아서 문자 입력이 가능하지 않을 때 말이다.

다 외부 모듈/IME 말고 입력 패드에서만 존재하는 상황을 가리킨다. 외부 모듈은 애시당초 로그인 화면에서도 동작할 정도로 권한 걱정 따위는 할 필요가 없으며, IME 컨텍스트가 존재하지 않는 윈도우에서는 처음부터 버튼들이 다 흐리게 바뀌고 입력이 차단되기 때문에 사후에야 이런 상황을 알아채고 에러 메시지 처리를 할 일도 없기 때문이다.

다만, 옛한글 설정을 해 달라는 메시지는 입력 패드와 외부 모듈이 공통으로 출력할 명분이 있는 것들이다.
외부 모듈은 어떤 경우에도 시스템 트레이를 건드리지 않고 동작하기 때문에 다소 투박하긴 해도 그냥 메시지 박스를 이용한다.

외부 모듈은 TSF B급 프로그램에서 어쩔 수 없는 기술 한계로 인해 조합이 튕긴 것을 감지해서 메시지 박스를 찍어 주는 게 있었다(처음에 2글자 이상 길이의 조합을 만들 수 없음). 히스토리 문서를 보니 저건 그리 오래 되지도 않은 8.5 버전에서 추가된 기능이다. 이건 IME가 아닌 TSF 프로토콜을 취급하는 외부 모듈에서만 유일하게 발생하는 현상이다. 그런데 이제 이런 식으로 메시지를 찍어 주는 상황이 하나 더 추가된 것이다.

이런 식으로 예전에 만들어 뒀던 체계를 확장하여 유용한 UI가 간단하게 추가되는 건 참 뜻깊은 일이다.

Posted by 사무엘

우리나라에서 사람 인생에 큰 영향을 주며 이 때문에 부정행위도 많은 대표적인 전국구 시험은 수능과 토익이 아닐까 한다. 수능은 10여 년 전인 2004년 11월에 치러진 2005년도 시험에서 200여 명에 달하는 수험생이 조직적으로 컨닝을 한 게 뒤늦게 적발돼서 전국적으로 난리가 나기도 했다. 비슷한 시기에 벌어졌던 밀양 집단 성폭행 사건과 더불어 국가적인 흑역사가 아닐 수 없다.

수능 부정 적발은 뒤끝도 굉장히 오래 간 걸로 기억한다. 이미 대학에 갓 입학한 학생이 수능 무효로 인해 입학이 취소된 건 차라리 양반이다. 더 옛날에 그냥 넘어갔던 것까지 조사를 해 보니, 심지어 대학을 졸업하고 그 경력으로 학사장교로 들어가기까지 했는데 뒤늦게 수능 무효 → 대학 입학과 졸업 무효 → 학사장교도 무효로 테크트리가 모조리 아작난 사례도 있다. 이건 학력위조 적발로 인한 임관 무효 말고, 또 별개로 있었던 사례다.

저 부정행위의 여파로 인해 수능 시험엔 일체의 전자기기가 한 치의 자비심 없는 절대금기가 되었다. 특히 시험장에서 휴대전화란 마치 공항 세관에서 마약, 군대 훈련소에서 담배와도 같은 악의 축 취급을 받게 됐다. 굳이 벨소리가 나지 않아도, 끄고 배터리까지 분리해 놨더라도, 1교시 시작 전에 전화기를 제출하라고 곱게 말로 할 때 제출하지 않은 게 적발되면 무조건 각서 쓰고 퇴장이다. 묻지도 따지지도 않고, 부정행위 정황이 있건 없건 이번 수능은 무효가 되니 내년에 다시 쳐야 된다.

사실 이마저도 죄질이나 처벌 수위가 가장 약한 '규정 위반'에 속하기 때문에 이번 수능만 무효 처리되고 끝나는 거다. 하물며 대놓고 부정행위를 한 게 적발된다면 올해뿐만 아니라 1년간 추가로 수능 응시 자격 상실이 뒤따른다.
그런데 매년 전국에서 수~열몇 명 정도는 바보같이 휴대전화 규정이 걸려서 퇴장 당하는 안습한 사람이 꼭 나온다고 한다. 자기가 아니라 부모님이 넣어 놓은 휴대전화가 뒤늦게 발견된다거나..;;

시험 부정 행위는 크게 다음과 같은 네 카테고리로 나뉜다.

• 혼자: 시력, 컨닝페이퍼
• 다른 수험생과 짜고: 답안지 보여주기, 특정 동작으로 신호
• 다른 외부인과 짜고: 무선 통신, 대리 시험
• 시험 관계자와 짜고, 혹은 시험장 "밖에서" 혼자: 아예 문제와 답안 유출, 답안지 바꿔치기

'혼자' 테크닉을 봉쇄하기 위해 같은 문제지도 A형과 B형으로 막 나뉘어 배부된다. 같은 문제를 풀더라도 수험생이 마킹하는 답안이 제각각이 되게 말이다. 컴퓨터 프로그래밍으로 치면 소스 코드의 난독화 테크닉과 비슷하다.
그리고 컨닝페이퍼를 책상 주변에다 미리 만들어 놓으려는 시도를 분쇄하려고 학생들의 고사장 좌석도 랜덤화한다. 마치 Windows Vista에서 도입된 실행 주소 랜덤화 기법이 떠오른다.
옛날에 초딩 시절에도 도학력고사 같은 큰 시험은 아예 반을 싹 바꿔서 쳤던 걸로 기억한다.

수험생간에 필기구가 가리키는 방향, 기침, 시선 등으로 신호를 주고받는 건.. 물증이 없는데 감독이 어지간히 눈썰미가 있지 않으면 혐의를 어떻게 입증해서 어떻게 잡아 내는지 궁금하다. 주고받는 학생들도 언제 걸릴지 모르는데 완전 조마조마한 상태에서 어떻게 그 짓을 할지? 멘탈이 어지간히 강하지 않고서는 할 수 없을 것이다.

그래서 요즘 시험에서 부정행위를 저지르는 사람들은 위의 1~2단계는 제끼고 최소한 외부인과 공모하는 3단계부터 시작한다. 초소형 카메라와 도청 장치를 만드는 기술이 발달한 덕분이다. 덕분에 시험장에 출입할 때는(특히 중간에 화장실에 갔다 올 때) 애들을 공항에서 검문하듯이 X선 금속 탐지기라도 통과시켜야 할 판이다.
하긴, 굳이 시험이 아니어도 노름판 같은 데서도 이런 방식으로 사기 치는 놈들이 많긴 하다. 몰래 카메라로 상대방의 패를 다 본다거나, 밖에 있는 고수에게 바둑판을 보여주고 훈수를 듣는다거나.

차량은 시험장과 적당히 떨어져 있는 외부에서 통신을 주고받는 부정행위 공범에게 훌륭한 엄폐성과 주거성을 제공하는 도구이다. 그렇기 때문에 저 부정행위 사건 이후로는 시험 시간 동안엔 시험장 주변의 반경 200m 이내에는 차량의 주정차도 전면 금지되었다. 이건 단순히 소음 방지가 아니라 이런 보안을 고려한 측면이 있다. 소음이 문제라면 차량 통과 자체를 금지시켜야지?

아예 시험지나 답안지를 사전에 빼돌리는 건 방송으로 치면 어지간한 방송 사고를 넘어 전파 납치 같은 급의 엄청난 범죄가 된다. 굳이 관계자를 매수하는 것뿐만 아니라 혼자 건물에 침입하는(!!) 짓도 여기에 해당되는데, 우리나라는 최근에 이런 사건도 두 번이나 발생한 바 있다.

대표적으로 전국민을 충격에 빠뜨렸던 사건은 2013년 말에 발생했던 연세대 로스쿨 캐비닛 사건 되겠다. 문제의 그 학생은 변호사 시험도 아니고, 학교 내부 시험 문제를 빼돌리려고 교수 연구실에 몰래 침입해서 컴퓨터에다 해킹 프로그램을 설치하려 했다. 연구실 도어락의 비번은 그 교수가 문을 열고 있을 때 옆에서 몇 차례 몰래 훔쳐봐서 '시력'으로 익혔다고 한다.

그런데 으슥한 밤에 웬 학생이 혼자 교수 연구실에 들어가는 걸 동일 로스쿨의 다른 학생이 우연히 보고 수상하게 여겨서 경비 직원에게 신고했고, 경비원이 출동했다. 경비원들이 오는 소리가 들리자 그 대담한 학생은 근처의 캐비닛 안에 황급히 들어가 숨었지만... 결국은 덜미가 잡혔다. 들켰을 때의 심정이 어땠을까? "당신은 누구요?" 개쪽에 개망신에;;;

걔는 태어나서 지금까지 어디서든 1등이란 걸 놓쳐 본 적이 없었댄다. 물론 이전에 치른 시험들도 부정행위의 도움으로 1등을 한 게 있었겠지만 모든 성적이 송두리째 조작은 아닐 것이고, 그 친구도 기본적인 머리와 실력이 있으니 컨닝 없이도 올백· 올1등까지는 아니어도 최소한 상위권은 유지 가능했을 것이다.

학부는 당연히 서울대 졸업. 허나 로스쿨은 서울대를 못 가고 겨우 연세대에 그친(?) 것에 무척 애석해하면서 재수를 했지만 뜻을 이루지 못했다. 로스쿨은 어딜 가든 그야말로 전국에서 날고 기는 공부 기계 암기 괴물들의 집단이 아니던가? 법학 전공도 아닌 그에게는 서울대가 아니라 연세대 로스쿨도 감지덕지이고 엄청난 학업량을 따라가기가 버거운 곳이었다.

결국 그 친구는 수단과 방법을 가리지 않고 1등 강박관념을 유지하기 위해, 어찌 보면 지금까지 늘 해 오던 대로 저런 짓까지 감행하게 됐고 그게 이번에는 통하지 않았다. 그는 당연히 징계 제적을 당해서 짤렸으며 법조계 쪽으로는 영원히 발을 들일 수 없게 됐다. 몇 년 전에 고려대 의대생 성추행 사건 가해자가 출교 당하고 의료계에서 매장 당한 것과 같은 처지가 됐다.

이 소식을 접한 동기생들은 그를 그냥 '캐비닛'이라고 부르면서 혀를 차고 허탈해했다. "그럼 그렇지 어떻게 저렇게 시험만 쳤다 하면 올A+을 제조하는 천재일 수가 있나 싶었는데 역시 제 실력이 아니었구나. ㄲㄲㄲㄲ"
그는 최종적으로 징역 1년에 집행유예 2년이 선고됐다. 동기생 출신인 본인의 모 지인에게 듣기로는, 걔는 IT 쪽으로 뭔 사업을 시작했다고 한다. 헐.. 뭘 해도 근성과 끈기는 있으니 나쁜 짓만 안 하면 성공은 하겠다..;;

캐비닛 사건이 가라앉고 얼마 뒤엔(2016년 3월) 웬 공무원 지망생이 정부 서울 청사 인사혁신처에 몰래 침입해서 자기 점수를 고치고 합격자 명단 문서 파일에 자신을 올려 놓다가 결국은 잡혔다. 이 사람은 공부는 그 연세대 캐비닛만치 잘한 것 같지 않지만, 잔머리와 대담성은 어쩌면 캐비닛을 능가한다고도 감히 말할 수 있다. 도대체, 무슨 약 빨고 어떻게 그런 생각을 해서 그 정도로 실행했는지 그 엽기성과 대담함에 경의를 표하지 않을 수 없다..;;

정부 서울 청사는 나름 청와대와 같은 급의 보안 시설인데 내부 헬스장에서 직원의 출입증을 훔치고, 경비가 허술한 시간대에 여러 사람들 사이에 껴서 뒷문으로 들어가는 식으로 감시를 피했다. 게다가 캐비닛의 경우 강의동 건물 자체는 출입이 가능하니 훔쳐보는 걸로 방 비번을 알 수 있었지만, 저 공시생은 처음 들어가 보는 정부 청사 안에서 하필 청소부가 편의를 위해 버젓이 적어 놓은 비번을 이용해 방에 침입해 들어갔다고 한다. (직원이 출근하기 전에 미리 방에 들어가서 청소를 끝내 놔야 하므로)

게다가 이 사람도 과거 이력은 더 화려했다는 게 밝혀졌다. 꾀병으로 약시 진단서를 받고 기간을 위조까지 해서 각종 시험에서 응시 시간을 1.5배 더 받았다. 다음으로, 매 시험의 1배수 시간이 끝날 때마다 수능 문제의 정답이 인터넷에 공개된다는 점을 이용하여, 그때 화장실에 가서 사전에 잘 숨겨 놓은 휴대전화로 인터넷에 접속 후 답을 알아 와서 마킹을 했다. 이런 허점을 찾아냈다는 것 자체가 보통 잔머리가 아닌 거 같다~!
또한 대학 진학 후에 7급 공무원 시험의 지역 예선급 시험을 학원에서 칠 때는 대놓고 문제 유출까지 해서 압도적인 1등을 차지하기도 했다.

이러니 여죄를 수사한 경찰들부터가 경악하고 "얘는 국정원 같은 데에 특채 좀 시켜야겠다 ㄲㄲㄲㄲ" 이런 반응을 보였을 정도였다. 거기는 그야말로 위장과 조작이 직업인 곳이니, 혹시 사법 거래라도 하면 난폭운전 폭주족을 F1 서킷으로라도 보내는 인재 활용을 할 수 있을지는 모르겠다. -_-;;

그야말로 영화 Catch me if you can을 떠올리게 하는 행적이 아닐 수 없다. 그 영화의 배경에서는 그래도 사회 시스템이 전산화되기 전이었으니 그 짓이 가능했을 뿐이다. 지금은 서버 DB를 직접 해킹하지 않는 한, 어설프게 엑셀/워드 문서 몇 개에다 점수 조작하고 자기 이름 넣어 봤자, 없던 공무원 자리가 하나 더 뿅 생겨서 자기 신분이 성공적으로 조작될 리는 만무하다.

컨닝을 소재로 기가 막힌 첩보물 학원물 짬뽕을 만들 수 있을지는 모르겠다. 웹툰으로는 <빵점동맹>을 참 재미있게 봤는데, 재미는 있지만 그래도 현실과는 많이 동떨어진 허구라는 점을 감안해야겠다. 백 희지는 주토피아에서 토끼 주디 같고 남캐인 임 수영은 여우 닉 같은 느낌이 든다.

그렇게 정성껏 컨닝을 할 시간과 머리가 있으면 공부나 빡세게 하라고 다들 말한다. 하지만 차근차근 공부하는 데 필요한 지적 능력과, 정교하게 컨닝하는 데 동원되는 지적 능력이 같지는 않은 관계로.. 사람을 변별하는 중요 시험엔 지금 이 순간에도 누군가가 부정행위를 자행하고 있을 가능성이 높다. 이 각박한 경쟁 사회에서 앞으로 또 무슨 엽기적인 부정행위자가 적발되어 뉴스 사회면을 장식할지 알 수 없는 노릇이다.

* 여담

1. 이 글에서 자세히 언급하지는 않았지만 토익도 나라 망신을 시킬 정도의 대규모 부정행위가 몇 번 저질러지고 적발된 적이 있다. 그래서 이 때문에 다수의 선량한 토익 응시자들이 싸잡아 큰 불편을 겪어야 했다. 불법복제 때문에 정품 사용자가 도리어 피해를 입은 것처럼 말이다. (올라가는 구입 가격, 제품 인증 관련 번거로움)

2. 그러고 보니 정부 서울 청사는 더 전에 2012년에도 어떤 이상한 사람이 무단으로 뚫고 들어가서 투신 자살까지 했었다. 어째 그리 보안이 허술한지 그것도 질타 사항이다.

3. 예전에 '짜장면'이 표준어로 인정받게 됐을 때 '컨닝'도 같이 좀 등재됐으면 하는 아쉬움이 있다. 자장면만큼이나 커닝도 완전 현실성이 없지 않은가?

Posted by 사무엘

오늘날 Windows에서 실행되는 모든 프로그램들.. exe, dll 따위는 잘 알다시피 portable executable이라는 형식으로 만들어져 있다. 하지만 이 파일 포맷도.. 처음 만들어지던 당시에 여전히 컴퓨터에서 현역이던 도스와 최소한의 호환성을 유지할 필요가 있었기 때문에, 맨 앞에 MZ로 시작하는 16비트 도스 헤더를 여전히 갖추고 있다.

호환성이란 게 딴 게 아니고, 도스에서 Windows용 프로그램이 실행됐을 때 컴퓨터가 다운되는 게 아니라 "이 프로그램은 도스용이 아닙니다" 같은 짤막한 에러 메시지라도 뜨게 하는 것 말이다.

옛날에 Win32s가 제대로 설치되지 않은 상태에서 32비트 프로그램을 Windows 3.1에서 실행했더니.. "상위 버전에서 실행해 주십시오 / Win32s를 다시 설치해 주십시오" 이런 말이 메시지 박스 형태로 뜨는 게 아니라 황당하게 This program cannot be run in DOS mode라고.. 지금 시스템이 아예 Windows가 아닌 듯한 자비심 없는 메시지가 도스창에 떴다. 20여 년 전에 그 인상이 무척 강렬했었다. 요즘은 32비트 OS에서 64비트 exe의 실행을 시도해도 에러 메시지가 그 정도로 막나가는 형태는 아니다.

Windows용 프로그램들은 빌드할 때 그렇게 도스에서 잘못 실행됐을 때를 대비해 짤막하게 대신 실행해 줄 도스용 일명 "stub" 프로그램을 링크 옵션으로 지정할 수 있다. 이름하여 /STUB. 이걸 지정하지 않으면 아까 같은 저런 짤막한 에러 메시지 한 줄만 찍는 기본 stub 프로그램이 들어간다.
16비트 시절에 Visual C++ 1.5x를 보면 그 예제 stub 프로그램 자체가 winstub.exe라고 있었다. 하지만 그 이후부터는 디폴트 stub 프로그램은 그냥 링커 내부에 내장되어 버렸는지 그런 게 따로 있지는 않다.

프로그램을 특수하게 빌드하면 그런 stub을 아예 전혀 집어넣지 않는 것도 가능하다. 맨 앞에 MZ, 그리고 0x3C 오프셋에 PE 헤더가 있는 지점만 들어있으면 되고 나머지 칸은 몽땅 0으로 채움. 심지어 PE 헤더가 0x3C 오프셋보다도 전에, 도스 EXE 헤더가 있어야 할 지점에서 바로 시작하는 것도 가능하다.

미래에 마소에서 빌드하는 EXE/DLL들은 번거로운 This program cannot be ... 메시지를 떼어내고 이렇게 만들어져 나올지도 모른다. 물론 이런 프로그램은 Windows 환경에서 실행하는 건 문제 없지만 만에 하나 어느 레트로 변태 덕후가 그걸 굳이 도스에서 실행해 보면 컴퓨터가 어찌 되는지 책임 못 지는 상태가 될 것이다.

반대로 기본 stub 대신에 꽤 규모 있는 16비트 프로그램을 집어넣어서 동일 EXE가 도스에서도 그럭저럭 기능을 하고 Windows에서도 GUI를 띄우며 제대로 실행되는 프로그램을 만든 경우가 있다. Windows 9x 시절엔 레지스트리 편집기가 그러했다. 이건 Windows에서 보기 드문 하이브리드 universal binary 형태의 프로그램인 것 같다.
16비트 프로그램이 자기 자신 EXE를 열어서 PE 헤더를 파싱해서 리소스 같은 걸 읽어들이는 코드가 같이 빌드되었다면.. 도스 파트가 나중에 합쳐진 Windows 파트와 더불어 한 리소스를 공유하는 형태로 실행될 테니 이 역시 무척 흥미로울 것이다.

이 시점에서 문득 궁금해졌다.
링커가 얹어 주는 기본 stub 프로그램은 명령어가 겨우 몇 바이트밖에 되지 않는다. 얘들은 무슨 의미를 갖고 있는지, 혹시 옛날 16비트 NE 시대와 지금의 PE 시대에 stub 프로그램에 차이가 있는지..?
그래서 오랜만에 도스 API와 8086 어셈블리 명령어 레퍼런스까지 찾아서 stub 프로그램을 분석해 봤다.

stub 프로그램의 코드는 이게 전부이다.

(1), (2) 맨 앞의 PUSH와 POP은 데이터 세그먼트를 코드 세그먼트의 값과 맞추는(DS=CS) 일종의 초기화이다. 스택에다가 CS 값을 넣은 뒤 그걸 DS로 도로 가져오는 거니까.
지금 이 프로그램은 화면에다 찍을 에러 메시지도 기계어 코드와 정확하게 같은 영역에 있으므로 저건 수긍이 가는 조치이다.

(3) 그 다음으로 DX 레지스터에다가 16진수로 0xE, 즉 14를 기록한다. 저 stub 프로그램은 길이가 정확하게 14바이트이다. 이 값은 프로그램의 시작 지점을 기준(0)으로 해서 그로부터 14바이트 뒤에 있는 문자열을 가리킨다.

(4) AX 레지스터의 high byte에다가 9를 기록한다.

(5) 이렇게 기록된 AX와 DX 레지스터 값을 토대로 0x21 인터럽트를 날려서 도스 API를 호출한다. 도스 API 중 9는 DX가 가리키는 주소에 있는 문자열을 화면, 정확히는 표준 출력에다가 찍는 기능을 수행한다.
그런데 굉장히 기괴한 점이 있는데.. 얘가 받아들이는 문자열은 null-terminated가 아니라 $-terminated여야 한다!

믿어지지 않으면 아무 Windows용 EXE/DLL이나 헥사 에디터로 열어서 앞부분의 에러 메시지 텍스트가 무슨 문자로 끝나는지를 확인해 보시기 바란다.
왜 그렇게 설계되었는지 모르겠다. 파일이나 디렉터리 이름을 받는 도스 API들은 당연히 null-terminated 문자열인데 말이다.

(6) 그 다음, AX 레지스터에다가 0x4C (high)와 0x1 (low)을 기록하고..

(7) 또 도스 API를 호출한다. 0x4C는 프로그램을 종료하는 기능을 하며, 종료와 동시에 low byte에 있는 1이라는 값을 에러코드로 되돌린다. 정상 종료는 0인데 1은 뭔가 오류와 함께 종료되었음을 나타낸다.
사실, 도스 API 레퍼런스를 보면 AH 값으로 0도 프로그램을 종료시키는 역할을 하는 듯하다(도스 1.0때부터 최초). 하지만 모종의 이유로 인해 그건 오늘날은 사용이 별로 권장되지 않으며 0x4C가 원칙이라 한다(도스 2.0에서부터 추가됨).

이렇게 분석 끝. 정말 간결 단순명료하다.
참고로 도스 EXE에서 헤더를 제끼고 기계어 코드가 시작되는 부분은 0x8~0x9 오프셋에 있는 unsigned short값에다가 16을 곱한 오프셋부터이다. 가령, 거기에 04 00 이렇게 적혀 있으면 0x40 오프셋부터 디스어셈블링을 해 나가면 된다. EXE는 헤더에 고정 길이 구조체뿐만 아니라 가변 길이인 '재배치 섹션'이 나오고 그 뒤부터 코드가 시작되기 때문이다.

그럼 과거 16비트 Windows에서 쓰이던 stub은 어떻게 돼 있었을까?
거의 차이가 없긴 한데, 문자열이 들어있는 위치와 얘의 주소를 전하는 방법이 달랐다.

(1) 맨 먼저 JMP도 아니고 웬 CALL 인스트럭션이 나온다. 기계어로 표기할 때는 인자값이 0x53이어서 3바이트짜리 자기 자신 인스트럭션 이후에 0x53바이트 뒤로 가라는 뜻이 되는데, 영단어로 바꿔서 표기할 때는 자기 자신 원래 위치 기준으로 0x56바이트 뒤가 된다. 이 위치는 그냥 바로 다음 (2) 명령이 있는 곳과 같다.

(2) 함수 호출을 했는데 RET를 하는 게 아니라 스택을 pop하여 DX 레지스터에다 가져온다. 그렇다. 아까 그 call에 대한 복귀 주소에 문자열이 담겨 있으니, 아까 같은 하드코딩이 아닌 요런 방식으로 문자열 주소를 얹었다.

(3) (4) 이제부터는 아까처럼 DS = CS 해 주고,

(5)~(8) 아까와 동일. 문자열을 찍은 뒤 프로그램을 종료한다.

이런 초간단 초미니 프로그램은 exe가 아니라 com 형태로도 만들지 말라는 법이 없어 보인다. com은 그 어떤 헤더나 시그니처도 없이 첫 바이트부터 바로 기계어 코드와 데이터를 써 주면 되는.. 정말 원시적이기 그지없는 바이너리 덤프일 뿐이기 때문이다. 빌드 날짜, 버전, 요구하는 아키텍처나 운영체제 등등 그 어떤 부가정보도 존재하지 않는다.

요즘 프로그래밍 언어들이 기본 제공하는 런타임들의 오버헤드가 너무 크다 보니, 이에 대항하여 세상에서 제일 작은 "Hello world" 프로그램 이런 것에 집착하는 덕후들이 있다. Windows 프로그램의 경우 프로그램을 특수하게 빌드하여 CRT 라이브러리는 당연히 떼어내고, 코드와 데이터도 한 섹션에다 우려넣고, 거기에다 후처리까지 해서 단 몇백 바이트만으로 MessageBoxA(NULL, NULL, "Hello, world!", 0) 하나만 호출하는 프로그램을 만든 예가 있다.

그러나 이런 것들도 com 앞에서는 몽땅 버로우 타야 한다. 얘는 아예 파일 포맷 자체가 없으니까. 이 이상 더 줄일 수가 없다. com 형태로 만든 Hello world 프로그램은 겨우 20몇 바이트가 전부이다.
무슨 명령어를 내렸는지 기억은 안 나지만 컴퓨터를 재시작시키는 com 파일이 있었는데, 얘는 크기가 겨우 2바이트에 불과했다.

com은 exe처럼 코드/데이터 세그먼트 DS=CS 따윈 전혀 신경 쓸 필요 없이, 바로 본론부터 들어가면 된다. 그 대신 com은 16비트 단일 세그먼트 안에서 코드와 데이터 크기 한계가 모두 64K라는 치명적인 한계를 갖는다. 메모리 모델로 치면 그 이름도 유명한 tiny 모델 되겠다. 애초에 exe가 16비트 CPU에서 저 한계를 극복하고, 또 멀티태스킹에 대비하여 재배치도 가능하게 하려고 만들어진 포맷이기도 하다.

아, 아주 중요한 사항이 있다. com에서는 첫 256바이트, 즉 0x100 미만의 메모리 주소는 시스템용으로 예약되어 있어서 사용할 수 없다. 내 코드와 데이터는 0x100부터 시작한다. 그렇기 때문에 저 프로그램의 코드 크기는 12바이트이고, 문자열은 0xC 오프셋부터 시작하긴 하는데 거기에다가 0x100을 더해서 DX에다가는 0x10C를 써 줘야 한다.

Windows PE에다 비유하자면 0x100이 고정된 base address값인 셈이다. 그리고 DX의 값은 그냥 VA이지 RVA가 아니다.
과거에 굴러다니던 exe/com 상호 변환 유틸리티들이 하던 주된 작업 중 하나도 이런 오프셋 재계산이었다. 그리고 com에서 exe라면 모를까 더 넓은 곳에서 좁은 곳으로 맞추는 exe -> com은 아무 exe에 대해서나 가능한 게 물론 아니었다. (단일 세그먼트 안에서만 놀아야..) 과거 도스에 exe2bin이라는 외부 명령어가 있었는데 걔가 사실상 exe2com의 역할을 했다.

아무튼, 저 바이너리 코드와 문자열을 헥사 에디터를 이용해서 입력한 뒤, 파일을 hello.com이라고 명명하여 저장한다. 이걸 도스박스 같은 가상화 프로그램에서 도스 부팅하여 실행하면 신기하게도 Hello, world!가 출력될 것이다.
고급 언어를 사용하지 않고 컴파일러 나부랭이도 전혀 동원하지 않고 가장 원초적인 방법으로 나름 네이티브 실행 파일을 만든 것이다. 사용 가능한 코드와 데이터 용량이 심각하게 작다는 것과, 요즘 64비트 Windows에서는 직통으로 실행조차 할 수 없다는 게 문제이긴 하지만. (네이티브 코드라는 의미가 없다~!)

이런 식으로 컴퓨터에 간단히 명령을 내리고 램 상주 프로그램이나 바이러스 같은 것도 만들기 위해 옛날에는 debug.com이라는 도스 유틸리티가 요긴하게 쓰였다. 간단한 어셈블러/디스어셈블러 겸 헥사 에디터로서 가성비가 뛰어났기 때문이다. edlin 에디터의 바이너리 버전인 것 같다.

오늘날 어셈블리어라는 건 극소수 드라이버/컴파일러 개발자 내지 악성 코드· 보안· 역공학 같은 걸 연구하는 사람들이나 들여다보는 어려운 물건으로 전락한 지 오래다. 하지만 이것도 알면 디버깅이나 코드 분석에 굉장한 도움이 될 듯하다.
디스어셈블리 자체는 주어진 규칙대로 바이트 시퀀스를 몇 바이트씩 떼어서 명령어로 분해해 주는 비교적 간단한 작업일 뿐이다. 파서(parser)가 아니라 스캐너(scanner) 수준의 작업만 하면 된다.

하지만 디스어셈블리가 골치 아프고 귀찮은 이유는 코드의 첫 실행 지점을 정확하게 잡아서 분해를 시작해야 하며, 그래도 어느 게 코드이고 어느 게 데이터인지가 프로그램 실행 문맥에 의해 시시각각 달라지고 무진장 헷갈리기 때문이다. 데이터는 백 날 디스어셈블링 해 봤자 아무 의미가 없고, 오히려 코드의 분석에 방해만 된다. 이런 역공학을 어렵게 하기 위해서 디스어셈블러를 엿먹이는 테크닉도 보안 분야에는 발달해 있다.
하긴, 코드와 데이터가 그렇게 경계 구분 없이 자유자재로 변할 수 있는 게 "폰 노이만 모델 기반의 튜링 기계"가 누리는 극한의 자유이긴 하다.

Posted by 사무엘

난 소위 말하는 친일파· 민족 반역자라는 건 다음과 같은 세 그룹으로 나뉘며, 이들을 분명히 나눠서 생각할 필요가 있다고 본다.

• A: 매국의 대가로 일제로부터 예우 받고, 당대에나 지금까지도 일체의 참회 없이 대대로 금수저로 잘 쳐먹고 잘살고 있어서 어그로 (조선 말기의 일부 관료· 지주· 황족 출신과 그 후손)
• B: 일제 강점기 동안 독립운동가를 고문하고 때려잡는 짓을 해서 어그로 (악질 헌병· 경찰 복무자)
• C: 공인으로서, 지식인으로서 먹고 살려고 권력에 아부하고, 자기 인지도를 이용해서 신사참배 내지 황국신민 징병 권유 같은 짓을 해서 어그로

그리고 난 이들의 적극성과 죄질은 명백하게 A > B > C의 순이라고 생각한다. 비록 비주얼한 임팩트는 B가 가장 강하겠지만 실질적으로는 A가 앞선다. 시간적인 등장 순서도 A, B, C의 순에 가깝고, 해당되는 사람 수도 A < B < C로 갈수록 많아진다.
점점 더 당대 사람의 책임보다는 애초에 나라를 말아먹은 선조의 책임이 더 커지며, 죄질이 가벼워지고 정상 참작의 사유가 생기는 건 당연지사다. 단적인 예로, 내가 그 시절을 살았다고 가정하더라도 내가 C가 될 가능성은 조금 있지만 B나 A 같은 간 큰 짓을 할 가능성은 거의 없다.

일제 강점기 35년을 나치 치하에 한 몇 년만 점령당했던 프랑스하고 비교하는 사람들이 있는가 본데, 어디 비교할 걸 비교해야지..
세대가 바뀌어 버리니 한반도의 경우 해방 당시엔 태극기 모양을 기억 못 하는 사람이 있을 정도였고 어린애들은 "어? 우리나라(=일본)가 전쟁에서 졌는데 왜 어른들이 다들 기뻐해?" 이럴 정도였다. 프랑스가 나치 독일한테 이렇게까지 오래 점령당하고 세뇌당했었냐? -_-;;

이 완용· 송 병준 같은 놈들은 A이고, 노 덕술은 B, 김 활란 같은 사람은 C다. 박 정희가 B에 속한다고 생각하는 사람들이 많으나 그 증거는 없다. 그냥 평범한 도적을 잡는 일만 한 경찰이나 중공군하고만 싸운 군인이라면 난 문제삼지 않음.
그 시절에 일제 치하의 공무원(교사, 경찰, 헌병 등등)에 취업하려 한 것 자체는 요즘 애들이 전부 공무원, 대기업에만 몰리고 과학고 나와서 의대에만 몰리는 것하고 하나도 다를 바 없다고 여겨진다. 공부 잘하면 다들 남을 통솔하고 다스리는 안정적인 직업을 갖고 싶어하지, 너 같았으면 평생 농사만 짓거나 프롤레타리아 로동자 기술자로만 살았겠는가? 굳이 "조센징 엿먹어라"가 아니라 단순 출세욕 때문이라는 것이다.

난 죄질을 A > B > C의 순으로 판단하기 때문에.. 똑같은 일제 강점기 여주인공이 나오는 영화인데 C급인 <청연>은 친일 논란에 휩싸이면서 망한 반면, A급에 '준하는' <덕혜옹주>나 <명성황후>는 어째 항일투사로 미화되면서 필요 이상으로 흥행하는지 이해가 잘 안 된다. 비록 그 사람들은 적극적인 매국노와 같은 급은 아니지만, 그렇다고 잘한 것도 전~혀 없는데도 말이다.

그 시절에 이 완용 내지 을사오적 같은 특정 개인 몇 놈만 없었다고 해서 대세가 뒤엎어졌다거나 나라가 안 망할 수 있었다거나 한 게 아님은 주지의 사실이다. 다만, 이 완용이 진짜 개새끼인 이유는 매국 행위 자체가 아니라 그 뒤의 태도와 처신이 더 크게 작용했기 때문이다. 그건 정말로 그 어떤 실드의 여지도 없다.

A, B는 몰라도 C는 법적인 처벌까지는 아니고 도의적인 비판· 비난, 불이익 수준이 적절하다고 여겨진다. 음주운전 적발 경력 같은?
그 시절에 일제한테 그 정도 협조 내지 영혼 없는 립서비스조차 안 했으면 조선인이 기업을 경영하고 고급 기술을 그만치 만질 기회라고는 있을 수 없었을 거란 점을 감안해야 한다.

물론 그땐 그랬다 치더라도 해방 후에도 일말의 반성이 없이 고개 꼿꼿하게 세우고 잘나가고 있다면 그 꼴은 보기가 참 민망하겠지만, 그래도 C 욕하는 그 의협심 강한 깨시민들도.. 자기가 그런 위기에 처하면 걔네 역시 십중팔구 변절하고 깃발 바꿔 달 거라는 건 내가 절대 장담한다. -_-;; 지금 중국에 대한 태도만 봐도 안 봐도 비디오, 안 들어도 오디오다.

신사참배 갖고 한국 교회가 썩었네 어쩌네 하는 좌독들이 있다. 물론 신사참배 결의는 한국 교회의 치욕적인 흑역사인 건 사실이다. 또한, 이 역시 외압에 굴복하여 신사참배를 결의한 것 자체보다도, 해방 후에까지 곧장 참회하지 않고 뻣뻣한 목을 유지한 것이 더 큰 죄악이긴 하다.

허나, 한편으로는 지들은 그 상황에서 과연 꼿꼿하게 버텼을까? 일제가 그땐 가족까지 인질로 잡아서 얼마나 치사하고 악독하게 협박과 회유를 일삼았는데? 흔히 생각하는 단순히 부정부패 때문에 굴복한 거 아니다! 그런 것들을 감안해서 판단한다. 저건 비판받을 사항이긴 하나, 자기가 도덕적으로 우월한양 정죄를 일삼고 교회 정체성을 부정할 정도는 명백히 아니다.

우리나라가 건국 초기에 반민특위의 해체와 친일 군경· 관리 재등용 때문에 문제가 되고 좌빨들에게 두고두고 꼬투리를 잡히고 있는 것 역시 사실이다. 이건 C보다는 수위가 높은 B 때문에 그런 것이다. 그런데 그들이 아마 롤모델로 삼고 있을 북한조차도 B들을 재등용해서 쓴 건 동일할 뿐만 아니라, 내가 늘 말하지만 그건 정말 전적으로 불가피하게 그렇게 된 것이다. 인재가 부족해서 말이다.

"친일 군경들이 해방 후에 그대로 옷만 갈아입고 반공투사로 변신"
내가 분명히 말하는데 이건 절~대로 부정적이기만 한 현상이 아니다! 그땐 그런 반공투사라도 없으면 안 됐다! 그 시절에 불가능했던 일을 이루지 못했다고 자꾸 이상한 피해의식 망상 집어넣는 선동질에 속지 마라.

우리나라는 건국 당시에 대통령과 내각 등 브레인들이야 당연히 다 독립운동가에 광복군 출신이었다. 단지, 말단에서 궂은일 하는 중하급 군경 간부들 중에는 일제 부역자들이 있었다. 이거는 램 4MB에서 돌아가는 Windows 95가 32비트 껍데기 밑에 불안정한 16비트 도스 코드가 부득이하게 호환성 때문에 여전히 포함돼 있던 것과 하나도 다를 바 없는 이유 때문이었다.
대한민국 건국 당시의 백성들의 컴퓨터 사정은 Windows NT 따위는 절대로 돌릴 수 없는 여건이었으니 말이다.

자, 그럼 마지막으로 남는 A급 잔당들은?
일일이 색출해서 재산 몰수했으면 좋겠지만 워낙 극소수이기도 하고 B급과 겹치는 놈도 있고, 그 혼란한 와중에 일일이 죄질을 파악해서 공산당 식으로 일을 처리하기 어려웠다. 이런 놈들이 일부 오늘날까지 호의호식하고 있는 건 안타깝고 화가 나긴 하지만, 정말로 예외적인 경우일 뿐이지, 대다수 평범한 사람들이 세상 비관하고 탓할 정도는 절대 아니다.

2010년이던가, 산낙지 살인 사건 기억하는가? 이건 단순 사고가 아니라 보험사기를 노리고 남자가 여친을 살해한 악질 살인이 거의 확실해 보이는 모든 심증 정황이 있었다. 그럼에도 불구하고.. 결정적인 증거가 없고 피해자인 여자애가 일찍 화장되어 없어져 버리는 바람에 용의자는 증거불충분으로 덜컥 무죄 선고를 받아 버렸다! 그런 것과 비슷하다. 세상엔 그런 분통 터지는 일도 있다. 무고한 사람을 막 빨갱이로 몰아가서 억울한 피해자를 만든 '유죄 추정의 원칙'만큼이나, '무죄 추정의 원칙'도 이런 식으로 한계와 부작용이 있는 법이다. 100% 만능이 아니다.

또 다른 예로는, 가평과 춘천 사이에 있는 남이섬 유원지가 A급 친일파 반역자 민 모 씨 가문의 후예 소유라고 알려져 있다.
물론 직접적으로 일제로부터 향응 차원에서 남이섬을 하사받기라도 한 건 아니다. 그랬으면 해방 후에 국가에서 정말 0순위로 몰수했어야지. 반쯤은 자기들이 원래부터 한국은행장도 배출할 정도로 출세하기도 했고, 그래서 1970년대에 자기 돈 내고 전주인으로부터 남이섬을 통째로 산 거라고 한다. 이 정도면 어디까지가 친일매국의 댓가이고 어디부터가 개인 사유재산권 추구인지 따지기가 솔직히 모호한 구석이 있다.

하지만 다른 사람도 아니고 명백한 친일파 후손이 남이섬을 우리나라 안의 딴 세상 '나미나라 공화국'처럼 꾸며 놓았다는 걸 알면 그게 마냥 재미인 것 같지는 않아 보인다.;; 잠재적 내란죄? 남이섬이 평범한 국공립 유원지라면 마케팅을 그런 식으로 할 리는 절대 만무하지 않겠는가?
거기서 한 해 벌어들이는 입장료 수입이 어마어마하다던데, 이 문제에 양심이 민감한 분이라면 남이섬 관광 같은 건 안 가는 게 바람직할 것이다.

이상이 맨날 말도 많고 탈도 많은 친일 청산 문제에 대한 나의 생각이다.
지금까지 살펴보았듯, 친일파라는 건 용어의 정의 내지 범위는 오락가락 하는데 빨갱이와 더불어 한국 사회에서 남을 인격 모독하고 억울하게 매장할 수 있는 마법의 단어 양대산맥이다.

자기도 감당하지 못했을 '의로운' 잣대를 강요하면서 남을 정죄하고 쓸데없이 세상 비관하는 건 옳지 못한 자세이다. 하지만 반대로 C급만 부각시키면서 단순 가담자와 악질 주동자를 한데 싸잡아 "그땐 누구나 다 그랬을 것"이라는 양비론으로만 퉁치는 것 역시 옳지 못하다. (1) 나라도 그땐 그럴 수밖에 없었겠냐 (2) 동족을 괴롭히고 등쳐먹는 등 물질· 정신적으로 악한 영향을 적극적으로 끼쳐서 사익 챙겼냐 (3) 그 뒤에 참회· 반성하고 있냐 정도를 잣대로 판단하면 큰 오류에 빠질 일은 없으리라 여겨진다.

참고로 아래의 부류들은 이 글에서 진지하게 다루는 부정적인 심상의 '친일파' 라인이 아니므로 오해 없도록 하자.

• 김 옥균: 매국 의도 제로. 정말 악의 없이 일본을 선하게 보고 걔들로부터 도움을 받으려 했던 옛날 사람일 뿐이다.
• 오덕: 그냥 비정치적으로 일본 문화만을 좋아하는 사람.
• 김 완섭: 그냥 책 팔아먹으려는 관심병자 또라이 생계형 친일파일 뿐이다. 이 승만 대통령이 잘못한 게 부정선거 야당 탄압 독재 등등 많은 흑역사 과오들을 제치고 평화선을 그어서 독도를 빼앗은 것이라고 말하는데 더 일고의 가치가 있겠나? 국가 정체성에 아무 위협이 되지 않으며 다른 사람들에게 위화감을 끼치지도 않는다. 그런데 이런 사람이 5 18 민주화 운동 유공자랍시고 국가로부터 예우와 혜택도 받고 있다.

• 일본과 일제 강점기에 대해 필요 이상으로 긍정적으로 말하는 편인 일부 우파 논객: 진짜 일본과 커넥션이 있고 자기 재산 지키고 싶고, 한편으로 우리나라가 망하길 바라는 개XX라면 절대로 저런 짓 안 한다. 얼굴 내밀고 소신 발언 하면서 어그로 끄는 멍청한 짓 따윈 절대 안 한다. 일부 과격 극단으로 치우친 견해가 있더라도 진짜 북한과 커넥션이 있고 지령도 받고 있는 종북 좌빨보다야 비교가 무의미할 정도로 해롭지도 위험하지도 않은 사람들이다.

Posted by 사무엘

오옷, 지금까지 내 블로그에서 데이터베이스에 대한 얘기가 거의 없었던 것 같다.
오늘날 정보화· 컴퓨터 세상의 근간을 담당하는 핵심 소프트웨어 기술을 꼽자면 (1) 운영체제(!!), (2) 컴파일러(컴퓨터에서 돌아가는 모든 프로그램들을 생성..), (3) 손실/무손실 압축 알고리즘, 그리고 (4) DB엔진이지 싶다. 딱히 무순으로 나열한 것임.

요즘은 전국민의 신분 근황, 학생들의 모든 학적 정보, 카드 거래 내역, 병원 진료 내역 등등등~ 모든 기록과 행적이 전산화됐다.
그리고 저기서 전산화라는 건 곧 DB화를 의미한다. DB 엔진 없이는 이 복잡한 세상이 돌아갈 수 없는 지경이 된 지 오래다. 또한 key-value 개념부터 시작해 삼라만상의 정보들을 다 표와 표를 융합해서 구축한다는 '관계형'이라는 모델, 그리고 정규화 계층 같은 DB 이론도 깊이 들어가면 생각보다 굉장히 심오하고 복잡하다.

똑같이 총이라 해도 권총부터 시작해 소총, 중기관총, 대포까지 다양한 크기가 있듯이 DB 엔진이라는 것도 스케일이 생각보다 매우 다양하다.
네트워크를 통해 들어오는 수백~수만~수백만 건의 동시 접속 트랜잭션을 소화하면서 방대한 양의 데이터를 극도의 안정성(그 대신 성능 오버헤드도..)을 보장하면서 처리하는 대형 DB 엔진이 있다.
이런 건 일반 사용자가 개인용 PC에서 돌릴 일은 없는 물건이다. 오라클 내지 MS SQL Server 같은 프로그램의 제일 고급 에디션이 이 범주에 해당할 것이며 이런 건 가격도 왕창 비싸다.

MySQL은 저 정도로 방대한 스케일은 아니지만 원격· 다중 접속을 지원하고 로컬 내지 중소규모 웹 서버에서 굴리는 용도로 가성비가 아주 좋다. 게시판이나 블로그 엔진들이 컨텐츠를 얘를 기반으로 구축하곤 한다.

MS Office에 포함돼 있는 Access 정도로 가면 다중 접속은 이제 없고, 서버가 아닌 클라이언트 지향 DB가 된다. 개인용 컴퓨터에서 엑셀로 처리하기엔 좀 방대한 양의 데이터를 엑셀보다 더 프로그래밍 지향적으로 전문적으로 처리하는 도구로 격이 더 낮아진다. 예전에 Visual C++ 책을 봐도 DB 관련 API는 꼭 한 챕터가 할당돼 있었으며, ODBC는 큰 DB, DAO는 좀 작은 DB라고 봤었다.

개인적으로는 성경을 DB로 구축하니 좋았다. 성경은 신구약 전체가 31000구절쯤 되고 역본을 10여 개 갖고 있으면 구절 수가 몇십만 개에 달한다. 그리고 내가 원하는 구절만 쿼리를 날려서 찾는 건 아무래도 스프레드 시트보다는 응당 DB가 제격이다.

또한, 먼 옛날에 컴퓨터 학원에서 dBase III+를 배우던 추억이 떠오른다. 얘도 그 당시로서는 Access에 준하는 체급의 개인용 DBMS라 볼 수 있겠다. SQL이 아닌 독자적인 문법 기반이었고, 명령 프롬프트 모드도 있고 메뉴를 띄워서 DB 파일을 관리하는 assist 모드도 있어서 UI가 독특했다. 또한 dBase가 생성하던 DBF 파일은 도스 시절에 아래아한글도 전화번호부에서 사용하고 DB Viewer를 제공할 정도로 옛날에 꽤 대중적인 파일 포맷이었다.

여느 워드 프로세서나 스프레드 시트와는 달리, DB 프로그램에서는 각 데이터에 속하는 속성들을 자료형과 크기까지 꽤 까다롭게 미리 지정해 놓고 데이터를 넣어야 한다. 프로그램 코딩을 할 때 말고 '자료형'이라는 개념을 따지고 생각해야 하는 분야는 아마 DB밖에 없지 싶다.

사실은 프로그래밍 언어 중에도 자료형이 엄격하지 않고 귀걸이 코걸이 식으로 변할 수 있는 언어가 있다. 그리고 DB 자료형은 엔진에 따라 다르긴 하지만 프로그래밍 언어의 그것과는 달리 딱히 기계 친화적으로 지정하지 않아도 되는 경우가 있다. 숫자형의 표현 범위를 2진법이 아닌 10진법 기준 자릿수로 지정하는 것처럼 말이다.
전화번호는 절대로 숫자형으로 지정하지 말고 문자열형으로 지정해서 넣어야 한다고 학원 선생님에게서 들은 기억이 남아 있다.

"명령줄 기반 + UI + 반쯤 절차형 프로그래밍 환경"이라는 점에서는 이런 DB 프로그램은 매쓰매티카 같은 수학 패키지와도 구조가 비슷한 구석이 있는 것 같다. 아무나 함부로 접근하기는 어렵다는 공통점도 있고 말이다.

그에 비해 엑셀은 어떤가? 대용량 데이터를 취급하는 성능은 DBMS보다 뒤쳐지고, 수식 계산은 수학 패키지에, 비주얼과 레이아웃 기능은 워드 프로세서에 밀린다. 엑셀은 심벌 연산이나 임의 자릿수 계산 기능이 없으며(수학 패키지), 성능을 위해 위지윅(워드 프로세서)도 포기했다.

그럼에도 불구하고 엑셀은 이들 이념을 어중간하게 절충해서 얻은 접근성과 성능, 가성비 덕분에 일반 사용자에게 최고의 업무 처리 앱이 되었다고 볼 수 있다. 일종의 포지셔닝을 잘해서 승리자가 됐다. 한 값이 바뀌었을 때 관련된 셀의 값들이 연달아 쫙 바뀌는 동적인 문서를 손쉽게 만들 수 있는 게 최고의 강점인 듯하다. 또한 피벗테이블/차트는 SQL 같은 거 하나도 몰라도 SELECT 쿼리에서 특히 GROUP BY를 적절하게 구현해 줬다고 볼 수 있다.

DBMS는 굳이 사람만 쓰는 건 아니고 다른 컴퓨터 프로그램이 로컬에서 내부적으로 사용하기도 한다. 에.. 그러니까, 사람이 관리하는 데이터 말고 프로그램이 자기 혼자만 취급하는 데이터를 관리할 목적으로 말이다. 이런 데에 미들웨어 컴포넌트처럼 쓰이는 DB 엔진은 덩치가 더욱 작고 백업· 응급 복구 같은 안전 기능이 없는 대신, 크기· 성능 오버헤드가 더욱 작고 빠르다.

예전에 파일 포맷에 대해서 글을 쓴 적이 있었다. 내 프로그램이 테이블 형태이고 수정이 빈번한 몇백만 개의 대용량 데이터를 다루는데, 파일 포맷을 새로 만들기는 심히 귀찮고 그렇다고 단순 선형적인 바이너리/텍스트 컨테이너 포맷을 쓰기에는 성능이 우려된다면, 범용성으로 인한 약간의 오버헤드를 감수하고라도 저런 내장형 소형 DB를 얹는 게 좋은 선택이 될 수 있다.

괜히 파일 내부에서 골치 아픈 청크가 어떻고 헤더가 어떻고 데이터를 바이너리 비트 수준에서 신경 쓸 필요 없이, 그냥 테이블 스키마.. 이건 프로그래밍 언어로 치면 C/C++ 쓰던 게 아주 고수준 언어로 바뀐 것과도 같다. DB 구조 자체가 일종의 파일 시스템에 대응하니까.

특히 데이터 전체를 무식하게 메모리에 다 올려서 작업하는 형태가 아니라면 DB의 가성비가 더욱 올라간다. 요즘 시대에 다 차려져 있는 밥상인 검증된 오픈소스 솔루션을 놔두고 개발자가 B+ 트리 같은 거 일일이 구현하면서 삽입 삭제 수정 케이스를 일일이 테스트 할 이유가 없기 때문이다.

이런 컴퓨터지향적인 DB는 DB가 하는 본연의 작업에다가 비교/정렬/데이터 변형 알고리즘 같은 일부 핵심 작업만 내가 custom으로 작성한 함수로 대체할 수 있어서 대단히 강력하고 편리하다. 당연히 C/C++로 작성하여 네이티브 코드로 빌드한 함수로 말이다. 파이썬이나 Lua처럼 C/C++ glue에 뛰어난 고급 언어가 있듯, glue에 최적화된 DBMS도 응당 있다.

Visual Studio의 경우 인텔리센스 엔진이 ncb 자체구현 DB를 쓰던 것이 2010부터는 자사의 SQL Server "Compact Edition" DB 기반으로 바뀐 것으로 유명하다. 그런 건 DB를 사용하기 꽤 적절한 용례로 보인다. C++ 문법이란 건 앞으로 또 뭐가 생기고 어떻게 변할지 모르는데 그런 것에 대응하는 것도 파일보다는 DB 지향이 더 유리하겠다.

MS 것 말고도 이 바닥의 유명한 오픈소스 소형 DBMS로는 SQLite가 있다. 리처드 힙이라는 아저씨가 만들었는데, 그냥 오픈소스로도 모자라 골치아픈 LGPL, MIT 라이선스 그딴 것조차 거부하고 소스를 걍 public domain으로 뿌렸다..;;; 그러면서 "님이 받은 만큼 님도 남에게 베풀어 주세요"를 저작권 notice랍시고 적은 게 전부이고.. 천재에다 신자이고 굉장한 대인배이신 듯하다.

모질라 재단의 이메일 클라이언트 유틸인 ThunderBird는 워낙 대용량 편지함을 관리하다 보니 내부 파일이 SQLite DB인 듯하며, 안드로이드 OS에서도 얘를 적극 활용 중이라고 한다. 그러고 보니 소형 DB들은 MS것과 오픈소스 모두 제품명에 compact, lite라는 '꼬마'를 나타내는 단어는 꼭 들어가 있다.

본인도 회사에서 SQLite를 좀 다룰 일이 있었다.
SQLite는 코드가 다양한 플랫폼에서 다양한 문자 인코딩(UTF-8, UTF-16 빅/리틀/디폴트)에 대비하여 API가 굉장히 세심하게 설계된 게 인상적이었다. 하긴, 인코딩에 따라 한글 같은 건 글자 수가 달라져 버리니 정보량에 매우 민감한 DB에서 그걸 민감하게 다루지 않을 수가 없다. 간단하게 단일 문자열로 통합· 추상화가 가능하지 않다는 얘기다.

콜백 함수는 자신이 받고 싶은 문자열의 형태를 지정해 줄 수 있으며, 콜백 함수 자체의 인자는 char도, wchar_t도 아닌 const void*로 돼 있다.
그리고 DB 내부에서 사용하는 문자열뿐만 아니라 열고 싶은 DB 파일을 지정하는 것도 16비트 문자열형 버전이 따로 있는데, 이건 Windows처럼 16비트 문자열을 네이티브로 쓰는 OS에서 CreateFileW 같은 W API를 쓰면서 제 성능을 낼 수 있게 한 배려로 보인다.

다음은 DB와 관련된 여러 문자열 처리 관련 잡설들이다.

1. 정렬

프로그래밍 언어들이 제공하는 문자열 비교는 정말 단순무식하게 숫자 비교의 연장선으로서 각 문자들의 코드값 비교 그 이상도 이하도 아니다. 허나 실생활에서는 오름차순/내림차순부터 시작해 대소문자 구분, 언어 정보를 고려한 비교 같은 복잡다양한 옵션이 필요하다.

대중적이고 자주 쓰이는 옵션은 SQL에서도 언어 차원에서 (1) 옵션을 제공한다. 하지만 좀 더 복잡한 정렬을 위해서는 값을 그대로 비교하는 게 아니라 (2) 사용자가 변조한 값을 비교한다거나 (3) 아예 비교 함수 자체를 customize할 수 있어야 한다.
물론 (3)만 있어도 (1)과 (2)는 다 처리가 가능하니 C 언어의 qsort 함수는 비교 함수만 인자로 받는다. 그러나 파이썬의 정렬 함수는 (1)~(3)까지 다양한 방식으로 운용 가능하다. SQL은 collation이라는 개념으로 정렬 알고리즘 자체를 customize할 수 있다.

2. 토큰화

구분자를 사이에 두고 여러 문자열들이 뭉쳐 있는 문자열을 토큰화해서 문자열(단어)들의 리스트로 뽑아내는 건 탈출문자 인코드/디코드만큼이나 이 바닥에서 굉장히 흔하게 행해지는 작업인 것 같다. 파이썬의 경우 split이라는 메소드가 있다.

그런데 토큰화라는 게 두 부류가 있다. 하나는 구분자가 whitespace 부류이기 때문에 "A    B"나 "A B"나 똑같이 A와 B로 분간되는 것이다. A와 B 자체는 빈 문자열이 될 수 없다.
다른 하나는 구분자가 콤마나 세미콜론 같은 부류이며, 한 구분자가 정확하게 한 아이템만을 분간한다. A,,,B라고 쓰면 A와 B 사이에 빈 문자열이 두 개 더 걸려 나온다..

C가 제공하는 오리지널 strtok는 컨텍스트를 받는 인자가 없어서 (1) 토큰 안에서 또 토큰 구분을 할 수 없으며 멀티스레드 환경에서 사용하기에도 위험하다. 그뿐만이 아니라 얘는 (2) whitespace형 토큰화만 지원하기 때문에 콤마형 토큰화에는 사용할 수 없다는 것도 단점이다. 그래도 뭔가 문자열을 또 복사하고 생성하는 게 없고 성능 하나는 나쁘지 않기 때문에 컨텍스트 인자만 추가해 주면 여전히 유용한 구석은 있다.

DB를 텍스트 형태로 덤프 백업하면 그냥 csv 형태로만 뱉는 게 아니라, 그대로 SQL을 실행만 하면 DB의 재구성이 가능하게 INSERT INTO xxx VALUES가 붙은 형태로 백업되는 것도 많다. DB 스키마는 그냥 CREATE TABLE ... 형태가 될 것이고.
코드와 데이터의 경계가 모호하다. DB 백업도 뭔가 JSON 같은 포맷과 연계 가능하지 않을까 하는 생각이 잠시 들었다.

3. 검색어의 전처리

SQL로 문자열을 검색하고 싶으면 그 이름도 유명한 LIKE 연산자를 쓰면 된다. 어지간한 프로그래밍 언어라면 함수 형태로 구현되었을 기능이 SQL에서는 연산자이다.
얘는 정규 표현식과 같지는 않은데 반쯤은 정규 표현식을 닮은 문법을 지원하여, A LIKE B는 A가 B라는 패턴을 만족하는지 여부를 되돌린다. 0개 이상의 임의의 문자열을 뜻하는 와일드카드가 *가 아니라 %이다. XXX로 시작하는 문자열, 끝나는 문자열, 중간에 XXX가 포함된 문자열 같은 게 다 이걸로 커버 가능하다.

그런데 탈출문자/와일드카드가 존재하는 모든 문자열 체계가 그렇듯이 그 탈출문자 자체는 어찌 표현하느냐가 또 문제가 된다. 이를 위해 SQL에서는 A LIKE B 다음에 ESCAPE C라고, '필요한 경우' 탈출문자를 사용자가 지정해 줄 수 있다. 그래서 \%, \_ 이런 식으로 와일드카드 자체를 표현할 수 있다. 탈출문자 자체는 역시 그 탈출문자를 두 번 찍으면 표현 가능.
탈출문자로는 C/C++처럼 역슬래시를 써도 되지만, 다른 걸 지정해 줘도 된다. SQL은 의외로 이런 데에 유도리가 있다. LIKE는 뒤의 ESCAPE와 합쳐져서 삼항 연산자 역할도 한다고 생각하면 되겠다.

다음으로, SQL에서 문자열 상수(리터럴)는 작은따옴표 또는 큰따옴표로 모두 표현 가능하다. 문자열 내부에 작은따옴표가 있으면 큰따옴표로 둘러싸면 되고, 그 반대의 경우를 사용해도 된다. 그런데 고약하게 문자열 내부에 두 종류의 따옴표가 모두 존재한다면 그 따옴표 자체는 따옴표를 두 번 찍어서 표현하면 된다. 이건 LIKE 연산자가 아니라 SQL 파서 자체에서 인식하는 탈출문자이므로 LIKE 연산자가 인식하는 탈출문자와는 성격이 다르다. C/C++로 비유하자면 위상이 \ 탈출문자와 printf % 탈출문자와의 관계와도 같다.

쿼리 내부에서 따옴표 탈출문자의 처리는 매우 철저하게 해야 한다. 안 그러면 이건 SQL injection이라는 보안 취약점이 되기 때문이다. SELECT ... WHERE id='A' 이런 식으로 쿼리를 작성했는데 A 내부에 또 작은따옴표가 존재해서 문자열 상수를 종결해 버리고, 사용자가 입력한 문자열이 쿼리의 실행에 영향을 줄 수 있다면.. WHERE 절을 언제나 true로 만들 수 있고 DB 내용을 몽땅 유출할 수 있기 때문이다. 이런 사건이 대외적으로는 '해킹' 내지 '개인정보 유출'이라고 보도된다.

Posted by 사무엘

2016년 12월 현재, <날개셋> 한글 입력기 8.8이 한창 개발 중이다. 내년 2~3월쯤에 나올 예정이다.

1. 제어판에 가상 키코드 변환 기능

지금으로부터 10년도 더 된 먼 옛날, <날개셋> 한글 입력기가 3.41 버전에서 지금과 같은 트리 구조의 제어판이 도입된 이래로, '입력기 계층' 탭은 오랫동안 별다른 UI나 기능이 없는 잉여 공간이었다.
어느 글자판(입력 항목)을 사용하건 공통으로 적용되는 옵션이나 기능들은 '편집기 계층'에 있었지, 딱히 입력 항목들만을 한데 싸잡아서 무슨 공통된 명령을 내릴 만한 건 없었기 때문이다.

그러다가 5.0이 나오면서 이 탭이 잠시 쓰인 적이 있었다.
5.0부터는 입력 설정 데이터의 파일 포맷이 바뀌었다. 그래서 이제 지원되지 않는 옛(3~4 버전용) 설정 데이터가 감지되면 제어판은 그 데이터를 읽지 않고 일단 프로그램 설치 직후의 기본 입력 설정을 내놓은 뒤, 처음에 이 '입력기 계층' 탭을 가리키게 했다. 그리고는 이 탭의 빈 공간에다가 "사용자의 예전 입력 설정은 구버전 방식이기 때문에 변환을 해야 불러올 수 있습니다" 이런 메시지를 임시로 출력시켰다.

5.0의 과도기가 지난 이후로 지금까지 파일 포맷이 또 변경된 적은 없다. 그렇기 때문에 이제는 저런 메시지를 볼 일이 없을 것이다. 그러나 먼 미래에 포맷이 바뀐다면 '입력기 계층' 탭은 또 그런 용도로 쓰일 여지가 남아 있다.

입력기 계층 탭이 이런 legacy 포맷 안내문 말고 일상적인 설정 기능을 갖게 된 것은 7.7 버전부터이다. 글쇠배열(key), 입력 설정(ist), 종합 설정(set)라는 세 계층별로 설명문을 넣을 수 있는데, 종합 설정 단위의 설명문을 넣는 기능이 입력기 계층에 들어갔기 때문이다. 여기에다가는 등록되어 있는 각 입력 항목들의 용도와 의미, 글자판 전환 글쇠들의 로직 같은 총체적인 설명을 집어넣으면 된다.

물론 그래도 하이퍼링크 형태로 '설명문 지정' 한 줄 달랑 들어간 게 전부였으니.. 입력기 계층 탭은 여전히 아주 초라해 보이는 건 사실이었다.

그러다가 이번 8.8 버전부터 이 탭에 그럴싸한 명령이 하나 더 추가되었다. 입력 설정들 중에 가상 키코드가 지정된 것들의 배열을 일괄 변환하는 기능이다. 이 기능이 도입된 배경을 설명하자면 다음과 같다.

<날개셋> 한글 입력기는 지난 8.6 버전을 계기로 운영체제의 어떤 키보드 드라이버와도 잘 연계해서 동작하는 기능이 강화되었다.
기본 입력 스키마가 제공하는 글쇠배열은 그 밑에 쿼티 드라이버를 쓰건 드보락을 쓰건 콜맥을 쓰건 47개 글쇠들의 자기 위치가 불변으로 잘 고정되어 있다. 그러나 그 47키 글쇠배열 말고 다른 방식으로 글쇠를 인식하는 기능들은 가상 키코드 기반이기 때문에 키보드 드라이버의 영향을 받는다.

기본 입력 스키마가 제공하는 '추가 글쇠 인식 기능', 고급 입력 스키마가 제공하는 '고급 글쇠 인식', 그리고 편집기 계층에 있는 단축글쇠들도 다 그러하다. 그렇기 때문에 S라는 글쇠를 인식하라고 하면 쿼티에서는 왼손의 A 오른쪽에 있는 글쇠이지만, 드보락에서는 오른손 새끼손가락으로 누르는 글쇠가 된다.

이 문제를 해결하기 위해서는 굳이 글쇠의 인식 방식을 바꾸는 모험을 하기보다는 모든 입력 항목들의 설정에 대해서 저렇게 가상 키코드에 의존하는 부분을 다른 글쇠배열의 동일한 위치 기준으로 값을 변환해 주는 기능을 넣는 게 좋겠다는 결론을 내렸다. 그리고 이 기능이 들어가기 딱 좋은 위치가 바로 '입력기 계층' 탭인 것이다.

내가 지금 드보락 드라이버를 사용하고 있는데 입력 설정은 쿼티 기준이다 싶으면, '변환' 버튼을 누른 뒤 글쇠배열을 '한국어/Korean'이나 'US Qwerty' 같은 걸 선택하면 된다. 즉, from과 to 중에 from만 지정하면 된다. to는 지금 <날개셋> 제어판을 구동한 프로그램이 사용하고 있는 글쇠배열로 자동으로 결정된다.
그리고 to뿐만 아니라 from에 해당하는 글쇠배열도 운영체제에 설치돼 있어야 한다. 이 프로그램은 운영체제가 제공하는 기능을 사용해서 변환하기 때문이다.

이거 한 방이면 입력 항목들뿐만 아니라 편집기 계층의 단축글쇠까지도 변환된다. from이 쿼티, to가 드보락이라면 A,S,D,F 라는 글쇠는 드보락에서 동일 위치에 해당하는 A,O,E,U로 바뀐다. 반대로 from이 드보락, to가 쿼티라면 H,T,N이 J,K,L로 바뀐다. 이런 식이다.

설명문도 마찬가지이지만, '입력기 계층' 탭에서 건드리는 범위는 편집기 계층을 일부 포함할 수도 있다. 그러나 입력기 계층까지 명백하게 포함하는 개념이기 때문에 이것은 편집기 계층 대신 입력기 계층으로 분류된다.

옛날에는 텅 비어 있었지만 지금은 그럭저럭 공간이 채워진 탭들의 선례를 살펴보면 다음과 같다.

(1) 사실은 입력기 계층뿐만 아니라 '편집기 계층'과 '시스템 계층' 탭도 다른 탭들에 비해 널널하긴 마찬가지이다.
편집기 계층은 한자 후보 변환 관련 기능만 빼면, cursor의 이동 방식이라든가 '삽입/겹침' 같은 건 따지고 보면 1.0부터 있었던 기능이 전부이다. 이 방면으로 딱히 기능이 더 추가될 여지가 없었던 듯하다. '단축글쇠'와 '최종 변환'이라는 세부 카테고리 역시 3.0 이래로 지금까지 더 추가된 게 없다.
다음으로 시스템 계층도 글꼴 본뜨기 같은 액세서리밖에 없다가 최근에는 키보드 드라이버 보정 기능이 여기에 추가돼 들어갔다.

(2) 기본 입력 스키마의 '글쇠 인식 옵션' 탭.
오랫동안 유의미한 옵션이라고는 사실상 '빈 입력 스키마와 호환되게' 옵션밖에 없던 안습의 극치였다. 몇 가지 옵션들을 구상해서 넣은 건 있었으나 실제로 구현되지 않아서 사용불가 상태였다. 그러니 탭을 없애고 글쇠배열 탭에다 합병을 해 버려도 할 말이 없었으나... 그 옵션 자체는 엄연히 글쇠배열이 아닌 입력 스키마의 영역이었고, 미래의 기능 추가에 대비해서 탭을 유지하고 있었다.
실제로 후대 버전에서는 변수 인식과 관련된 여러 옵션들이 추가되었으며, 결정적으로 임의의 단축글쇠 리스트를 꾸미는 기능도 추가되면서 이 페이지 역시 꽉 차게 되었다. 옛날에 구상했던 기능들은 대부분 고급 스키마의 형태로 오늘날 실현되었다.

(3) 외부 모듈의 '고급 시스템 옵션' 탭.
4.82 버전에서 'TSF 지원 확장' 옵션 딱 하나가 추가된 걸로 아주 초라하게 시작했으나, 그 뒤로 각종 한영 상태 동기화 옵션과 기본 IME 지정 명령처럼 <날개셋> 외부 모듈이 IME로서 운영체제/타 프로그램과 소통하는 방식을 지정하는 고유한 옵션들이 많이 추가됐다.
최근에는 자신과 연결할 키보드 드라이버를 지정하는 옵션까지 추가되어 페이지가 빈틈이 없이 꽉 찼다. 나중에 옵션을 한두 개 더 추가하려면 'TSF 지원 확장'에 딸려 있는 안내문을 없애거나 분량을 줄여야 할 것이다.

가상 키코드 변환 기능 덕분에 인제 '입력기 계층' 탭은 별도의 독립된 도움말 페이지도 할당받았고 버튼도 두 개나 생겼다.
미래에는 이 탭이 지금보다 더 풍성해지는 날이 오기를 기대해 본다.

2. 글쇠배열의 이름과 별도로 입력 스키마에도 고유한 이름

얘기가 갑자기 딴길로 많이 샜구나. 다시 본론으로 들어오도록 하겠다.
3.0대 버전 이래로 지금까지 굉장히 어정쩡한 관계이긴 했는데.. 어떤 입력 항목에 대해서 '글쇠배열의 이름'과는 별개로 입력 항목 차원에서 고유한 이름을 사용자의 필요에 따라 지정할 수 있게 했다. 입력 항목의 이름이란, <날개셋> 한글 입력기의 여러 구현체들에서(편집기, 외부 모듈 등) '한글 세벌식', '영문 쿼티'처럼 "글자판을 선택하세요" 목록 내지 메뉴에 나타나는 이름들을 가리킨다.

지금까지 입력 항목의 이름이란, 곧 입력 스키마가 갖고 있는 글쇠배열의 이름과 동일했다. 어떤 입력 방식에서 글쇠배열이 차지하는 비중이 워낙 큰 게 사실이니 이런 접근 방식이 지금까지 큰 문제는 없었다.

그러나 글쇠배열은 여느 한글 또는 영문 배열과 다를 바 없고 오토마타나 사용자 정의 조합만 달리해서 여러 입력 방식을 만들어 낸다면 지금 같은 체계는 좀 문제가 있다. 글쇠배열을 바꾼 건 없는데 글쇠배열 탭에 가서 이 입력 방식 특성을 표현하는 이름을 입력해야 하기 때문이다.

이제 8.8버전부터는 제어판을 열어서 입력 항목을 가리키면, 지금까지 읽기 전용이던 이름 입력란에다 이름을 입력할 수 있다.
이게 공란이면 예전처럼 글쇠배열의 이름이 입력 항목의 대표 이름으로 유지된다(회색 글자). 그러나 저기에 문자열이 입력되면 그 문자열이 대표 이름이 된다.

그러므로 쿼티 영문 글자판을 기반으로 한글 로마자 입력 방식을 구현했거나 사용자 조합 기능을 추가해서 다른 문자 입력 체계를 구현했다면, 그걸 나타내는 새로운 이름을 입력 항목 차원에서 써 주면 된다. 이렇게 하면 글쇠배열의 이름을 굳이 건드리지 않고도 자기가 만든 입력 방식이 대외적으로 식별되는 명칭을 새로 지정할 수 있다.

입력 항목의 대표 이름은 설명문과 비슷한 형태로 저장된다. '빈 입력 스키마'는 원래부터 아무 옵션이 없고 아무 동작도 안 하는 스키마이기 때문에.. 설명문과 대표 이름을 모두 지정할 수 없으며, 대표 이름도 그대로 '빈 입력 스키마'로 언제나 고정된다.

저걸 구현하느라 난생 처음으로 에디트 컨트롤에다 EM_SETCUEBANNER 기능을 써 봤다. 이게 지원되지 않는 운영체제에서는 그냥 저 회색 디폴트 텍스트가 나타나지만 않고 다른 영향은 없다. 원래 cue banner는 '여기에 이름을 입력하세요' 같은 고정된 UI 가이드/힌트를 출력하라고 있는 텍스트이기 때문에 저렇게 런타임 가변적인 텍스트를 찍는 건 약간 이질적인 활용이긴 하다.

저 기능이 최초로 추가된 건 Windows XP의 공용 컨트롤 6.0부터다. 수식의 변수 도움말을 출력하기 위해 진작부터 사용해 온 풍선 도움말(balloon text)과 도입 시기가 동일하다. 그런데 참 희한하게도 이 기능은 한중일 동아시아 언어권 에디션 또는 MUI 팩이 설치된 XP에서는 버그로 인해 동작하지 않았다고 한다. 우리 같은 사람은 Vista와 그 이후에서나 cue banner를 구경할 수 있게 됐다.
반대로, Windows XP에 도스용 QBasic이 영미권에서는 삭제됐지만 동아시아 에디션에서는 있었다고 하니 이것도 신기한 노릇이다.

3. 문자표

문자표 대화상자에도 약간의 변화가 생겼다.
맨 위에 '종류'라는 콤보박스가 추가되어, 단순히 글꼴이 존재하는 모든 문자들을 코드값 순으로 나열하기만 하는 게 아니라 다른 임의의 문자표를 제공할 여지를 마련했다. 사실, 이 용도로는 MS Word나 아래아한글의 문자표 대화상자처럼 탭 컨트롤을 쓰는 것도 좋으나 그것보다 더 구현하기 쉽고 만만한(..) 콤보박스를 사용했다.

이것이 예전 무려 3.0 시절부터 있던 'KS X 1001 문자표' 체크박스를 대체했다.
사실, 완전히 다른 문자표를 출력하는 기능이 무슨 옵션인 것처럼 체크 형태로 있던 건 굉장히 이상한 UI 디자인이긴 했다.
마치 성별을 입력받는 UI가 남/녀 라디오나 콤보박스로 있는 게 아니라, "[X] 여자" 체크박스로 달랑 주어지는 것처럼 말이다. 내부적으로 표현되는 정보량이 1비트라고 해서 체크박스가 모든 상황에서 적합한 건 아니다.

체크박스가 콤보박스로 바뀌었는데 문자표가 여전히 두 종류밖에 없으면 좀 심심하니 "모든 한글 자모"라는 문자표를 하나 더 넣었다. 이것은 유니코드에 존재하는 모든 한글 낱자들을 초중종별 사전 순으로 표시해 준다. 여러 영역에 뿔뿔이 흩어져 있는 한글 자모들을 한데 열람하고 옛한글을 문자표로 입력할 때 큰 도움이 될 것이다.

이제 사용자가 별도의 리스트로 작성한 custom 문자표를 뒤에 줄줄이 추가하는 기능도 생각할 수 있으나, 일단 미래의 과업으로 미루기로 한다.

4. 방점 지원

<날개셋> 편집기가 드디어 한글의 뒤에 붙은 방점(U+302E, U+302F)을 한글의 왼쪽에다 제대로 표시해 준다. 또한 cursor의 이동· 삭제 단위를 판별할 때 방점은 앞의 한글과 같이 한 묶음으로 처리된다. 안 그래도 <날개셋> 편집기는 세로쓰기도 지원하니, 방점이 이렇게 세로로 찍혀 나오면 문서가 더욱 볼 만할 것이다.

다만, 방점은 자신만의 고유한 폭을 차지하는 게 아니라 한글 16*16 공간 안에 같이 삽입된다. 그렇기 때문에 한글 글꼴 자체가 큼직하다면 방점이 제대로 보이지 않을 수 있다. 방점과 잘 어울리는 약간 홀쭉한 옛한글 글꼴이 좀 있어야 할 것 같다. 그나마 '한메가는본문'이 이런 범주에 드는 글꼴 같지만 얘는 옛한글을 지원하지는 않는다.

한글 한 글자를 구성하는 덩어리에 초중종성에 이어 방점까지 옵션으로 붙을 수 있다니 이건 무슨 픽셀에서 RGB에 이어 알파채널까지 붙는 것과 비슷해 보인다. 그렇다고 이거 지원을 위해 <날개셋> 한글 입력기의 내부에서 한글 하나를 나타내는데 제4의 성분을 통째로 다 집어넣은 건 아니다. 그런 무모한 짓을 한 건 아니고 그냥 한글 입력 오토마타의 내부 구조만 살짝 확장했다.

내가 처음에 한글을 입력할 때야 그 조합 내부에다가 방점을 같이 넣을 수 있지는 않다. 방점은 입력되는 순간 한글 조합을 종료시켜 버린다. 단지, 이미 방점이 곁들어진 한글에다 달라붙을 때 그 방점을 임시로 유지한 채로 자모를 고치거나 추가로 입력할 수만 있게 했다.
그리고 이 상태에서 bksp를 누르면 언제나 방점부터 먼저 지워지고 그 뒤에 한글 자모가 지워진다. cursor가 이동하는 단위하고 bksp로 글자를 지우는 단위, 그리고 앞에서 뒷글자를 지울 때와 뒤에서 앞글자를 지울 때 동작에 차이가 발생할 수도 있어서 꽤 어려울 수도 있는 작업이었는데 결국 문제를 이런 식으로 깔끔하게 해결했다.

5. 텍스트 필터 추가

"한글 형태 정규화" 필터에는 NFC와 NFD 정규화 둘만 있었는데, 거기에다가 "NFD부터 적용 후 NFC"라는 제3의 동작 옵션을 추가했다.
이렇게 하면 '가ㅿ'처럼 종성이 없는 현대 한글 자모 + 채움 문자 없는 종성 한글 낱자가 한데 이어져서 정규화가 잘못되어 있던 한글이 현대 한글 또는 옛한글로 한데 합쳐진다.

예전 방식으로 이런 문자열을 NFC 정규화 하면 '가'는 그대로 있고 ㅿ는 채움 문자가 추가되어 두 글자가 서로 완전히 분리되곤 했다. 새로 추가된 옵션은 그보다 더 융통성 있게 동작할 것이다.

사실, 텍스트 필터들은 옛날에 6.x 버전 때 잔뜩 추가되고 나서 그 뒤로 변화가 거의 없었다. 그런데 이번엔 "문자 코드값 산술 치환"이라는 새로운 필터가 추가됐다.
그냥 모든 글자들에 대해 코드값을 나타내는 변수 A에 대한 수식을 실행해서 그 수식값으로 문자를 바꿔 준다. 0을 지정하면 그 문자를 지운다. surrogate는 자동으로 처리되기 때문에 A>=0x10000이라고 생각하면 된다.

쉽게 말해 이 기능은 <날개셋> 편집기에 이미 들어있는 '문자 영역 찾기' 기능의 '바꾸기' 버전이라 할 수 있다. 앞뒤 글자를 가리키는 P와 N 변수를 사용할 수 있으며, 여기서 글자를 변경했다고 하더라도 뒷글자의 수식에서 P변수에는 바뀌기 전 앞글자의 코드값이 들어간다.
A - (A>='a' && A<='z' ? 32:0) 이런 수식을 주면 알파벳 대문자를 소문자로 바꿀 수 있으며 전/반각 변환도 그냥 수식으로 처리할 수 있다. 그리고 정규화된 한글 낱자에서 특수 처리를 위해 외형상 잘 보이지 않는 채움 문자만 제거하고 싶을 때도 이 필터를 사용하면 된다.

6. Windows 10 + 구글 크롬에서 발생하는 외부 모듈의 이상한 문제

본인은 근래에 한 사용자로부터 아주 괴이한 현상에 대한 신고를 받았다.
Windows 10 (일단은 64비트) + 구글 크롬의 주소창에서 한글을 입력한다. 그리고 조합이 있는 상태에서 그대로(예: '가' 입력 중) 마우스로 그 주소 입력란을 클릭한다. 그러면 외관상 당연히 조합이 종료돼야 한다.
그런데 그 상태에서 한글을 입력하면 아까 조합 중이던 한글이 덧나서 '가강' 내지 '가가ㄴ'처럼 된다.

<날개셋> 한글 입력기가 개발 짬밥이 몇 년인데 저런 미개하고 원시적인 버그가 있다는 건 말이 안 되는데? 게다가 다양하게 실험을 해 보니 이 버그는 다음 조건 중 하나만 만족해도 발생하지 않는다. 혹시나 해서 말인데, 모든 테스트는 64비트 기준임.

• 일단 날개셋 말고 MS IME는 어디서든 별 이상 없음.
• 크롬에서 '가능한 경우 하드웨어 가속 사용' 옵션을 끄면 날개셋 역시 저런 문제 없이 조합 종료 처리가 옳게 됨. 아놔 웹 페이지 렌더링에서 가속을 받는 것하고 IME 프로그램의 동작이 도대체 무슨 상관이냐? -_-;;
• Windows 10 중에서도 1주년 업데이트를 갓 받은 버전 1607, 빌드 14393.xx대에서만 확실하게 발생하며, 그 이전(버전 1511, 빌드 10586) 내지 이후(버전 1607, 빌드 14971) 버전에서는 발생하지 않는 듯함.

크롬에서 발생하는 문제이긴 하지만 날개셋 + 운영체제 + 크롬이 삼박자로 모두 정밀한 조건을 기가 막히게 만족할 때만 발생하기 때문에 이건 도대체 어떻게 처리해야 할지 모르겠다. Windows 10은 시도 때도 없이 업데이트가 너무 자주 되고 있기 때문에, 만약 후대 빌드에서 문제가 발생하지 않는다면 이건 그냥 '알려진 문제'에다 언급만 하고 넘길 가능성이 높다.

7. 예제 데이터와 도움말

예제 입력 데이터도 몇 개 더 추가하고 Samples 아래에 디렉터리를 더 세부적으로 구분했다. key와 ist 중 한글 입력과 관계 있는 것은 Hangul로, 한글 입력이 아닌 것을 Non-Hangul로 나눴다.
그리고 아직은 예제가 각각 하나씩밖에 없지만 후보 데이터는 Candidate로, 한글 표현 영역 데이터는 Range로 이동해서 배치했다. 확장자가 다 같은 txt이어서 분간이 안 되기도 하니 말이다.
이제 Samples 디렉터리 자체에는 제어판 내장값 예제 데이터인 scheme.xml만 있다. 여기에는 용도가 고정된 파일들만 있을 것이다.

Non-Hangul들은 평범하게 글쇠배열이나 오토마타 수식이 아니라 '날개셋 고급 입력기' 문자 생성기가 제공하는 기능들을 활용해서(사용자 정의 조합과 후보, 출력 치환) 외국 문자나 각종 알파벳 변형 문자들을 입력한다. 알파벳+성조 번호로 성조가 붙은 알파벳을 입력하는 한어병음, X를 덧붙여서 악센트 부호 알파벳을 찍는 에스페란토, 심지어 베트남어 VIQR 입력 방식까지 있다. 내가 만든 건 아님.

그리고 도움말엔 부록의 "한글 낱자 코드 참조표 - 자음" 부분과, 기본 자료 구조의 "한글이 표현되는 방식"에 설명을 보강했다. KS X 1026에서 종성 ㅇ 겹받침이 옛이응 겹받침으로 전격 변경된 것과 관련된 내용을 추가했으며, 현행 한글 코드에 대한 비판에 대한 해명도 넣었다. 한글 11172자와 수백 자의 옛한글 낱자가 유니코드에 일일이 배당된 것이 뭔가 잘못된 것처럼 생각하는 분들이 있는데 본인은 그렇게 생각하지 않는다고 말이다.

이렇듯, 개발 2개월째를 맞는 차기 버전 8.8은 핵심 기능을 제외하고도 겉의 UI와 데이터에 유의미한 변화들이 잔뜩 추가되었다. 다음으로 타자연습 얘기를 하겠다.

8. 타자연습

(1) <날개셋> 타자연습은 현재 최신 버전(입력기 8.6 + 타자연습 3.51)에 중대한 버그가 있다는 걸 이 자리에서 먼저 밝힌다. ‘글쇠 익힘’에서 ‘글자 단위 연습’을 사실상 할 수가 없다. 상자에 있는 글자를 그대로 따라 쳐서 완성하는 순간 프로그램이 뻗어 버리기 때문이다.

이건 타자연습은 잘못이 없고 입력기가 한창 새 기능들이 추가되던 와중에 어이없는 실수가 들어갔기 때문이다. 처음부터 있었던 버그는 아니고 8.5~8.6쯤에서 들어간 것으로 추정된다. 세벌식 커뮤니티에서는 오래 전부터 나돌던 이슈였던 것 같은데 본인은 지금까지 이걸 알지 못했다.

(2) 오랫동안 존재했을 것으로 추정되는 굉장히 어처구니없는 버그를 사용자의 제보 덕분에 발견하여 수정했다. <날개셋> 타자연습에는 사용자 계정 이름을 변경하는 기능이 있는데 그게 사실상 거의 쓸 수 없는 무용지물이었다. 계정을 갓 생성한 직후에는 개명이 가능하지만, 나중에 그걸로 본격적으로 로그인을 한 뒤에는 개명 기능이 동작하지 않았기 때문이다. 이 문제 역시 확인된 즉시 해결했다.

(3) 지난 3.5버전부터 연습글을 관리하는 체계가 리스트 xml이 아닌 디렉터리 기반으로 간소화되었는데.. 이 때문에 지금까지 제공되던 성경 본문 tc 파일을 곧장 사용하는 게 불가능해졌다.
다음 버전에서는 사용자가 지정한 연습글 디렉터리에다 tc 파일이 있으면 그 tc 파일에 있는 모든 연습글들을 별도의 꾸러미에다 자동으로 몽땅 등록해 주는 기능이 들어갈 것이다. 골치 아프게 ProgramData\YmSoft\NgsType 이런 디렉터리 찾을 필요 없이, 자기가 쓰는 연습글 디렉터리에다가 파일을 넣기만 하면 문제가 해결된다.

(4) 문장 연습 중에 현재 사용 중인 글자판의 이름을 표시하는 기능이 추가되었다. 연습 중에는 어차피 화면 좌측 하단의 ‘환경설정’ 버튼에 접근할 수가 없어지니 이 버튼을 아예 숨겨 버리고 여기에다가 <날개셋> 편집기의 상태 표시줄처럼 글자판의 이름이 표시되게 했다.

<날개셋> 타자연습은 세벌식 최종 전용 타자연습(= 한글 전용)을 표방하고 있어서 전통적으로 이런 쪽을 신경쓰지는 않고 있었는데, 이것도 표시하는 기능이 없는 것보다는 있는 게 좋아 보인다. 게임의 경우 글자판이 바뀌면 바뀐 글자판 이름이 화면 좌측 하단에 잠시 떴다가 사라진다.
사실은 앞서 언급했던 입력 스키마 이름과 글쇠배열 이름을 분리하는 기능 역시, 타자연습의 이 작업을 하던 중에 아이디어가 떠올라서 추진한 것이다.

이 정도면 타자연습의 다음 버전도 단순히 3.52 수준이 아니라 3.6 정도로 너끈히 갈 수 있을 듯하다.

Posted by 사무엘

1. 북한에서 수뇌부가 거주하는 곳은?

우리나라야 대통령이 근무하는 관저는 북악산 기슭에 있는 '청와대'이다. 대통령은 출퇴근 이동을 하지도 않으며, 잘 알다시피 보안을 위해 아예 이 캠퍼스 안에 가족이 다 눌러앉아서 지낸다.
그럼 한편으로 북한에서 청와대에 해당하는 건물은 무엇일까?

일명 주석궁이라고 불리는 평양의 그 거대한 건물을 떠올리는 분들이 많을지 모르겠다. 본인 역시 오랫동안 그렇게 생각했는데.. 사실은 그렇지 않다는 사실을 최근에 알게 됐다.
주석궁은 2~30년 전, 김 일성이 살아 있던 시절에는 '금수산 의사당'이라고 불리면서 김 일성이 거주하고 집무하는 관저로 쓰인 게 맞다. 그러나 저 사람이 죽고 나서는 그 궁전 전체가 무슨 성경에 나오는 지성소 같은 성역이 되어 버렸다. 이름도 '금수산 기념 궁전'로 바뀌었다가 지금은 '금수산 태양 궁전'이 됐다.

우리나라의 경우 전직 대통령이 서거하면 현충원에 묻어 준다. 그것처럼 김 일성 역시 개인적으로는 북한의 현충원뻘인 '대성산 혁명렬사릉'에 묻히길 원했으나.. 독재자를 한도 끝도 없이 우상화해야만 체제가 유지될 수 있는 북한에서 바랄 걸 바라야지. 그 유언은 상큼하게 씹혔다. (베트남에서는 호치민의 유언도 그렇게 씹혔음.)

그 큰 주석궁 전체가 예전에는 프로토스 넥서스에 해당했는데 이제는 시타델 오브 아둔 같은 역할로 바뀌었다. 김 일성의 미라가 들어갔으며 나중에는 김 정일의 미라까지 추가로 들어갔다. 그리고 근처의 지하철역이던 광명 역은 보안 강화를 위해 폐역되고 열차가 무정차 통과하게 됐다. 달랑 미라 두 구만 보관하기에는 아무래도 너무 큰 건물인데.. 다른 공간은 어떻게 바뀌었나 모르겠다.

어쨌든 이런 이유로 인해 금수산 태양 궁전은 일종의 박물관 내지 왕릉 같은 곳이 됐기 때문에 지금 김 정은이 거기에 늘 상주하지는 않는다. 김 일성이 죽은 뒤 오늘날까지 김씨 가문이 사용하는 관저 내지 아지트는 평양, 신의주, 원산, 심지어 백두산 근처 등 여러 곳에 흩어져 있다. 평양 근처에 있는 걸로 알려진/추정되는 아지트도 시내에서 상당히 떨어진 외곽 모처이며, 위성 첩보 사진으로 위치를 추측할 뿐이다.

요컨대 거기는 워낙 폐쇄적이고 비밀도 많은 집단이다 보니.. 대한민국의 청와대, 미국의 북악관 같은 딱 떨어지는 단일 집무 공간이라는 개념이 현재 공식적으로 없는 셈이다. 더구나 그런 아지트들의 지하에는 무슨 거미줄 같은 네트워크가 깔려 있을지 생각하면 의문은 더욱 커질 수밖에 없을 것이다.

2. 김 정일의 카게무샤(대역)

우리나라 육군에는 KCTC(육군 과학화 전투 훈련단)이라는 훈련장이 있으며, 거기엔 '전갈 대대'라고 타 부대를 상대로 북한군 코스프레를 하면서 가상의 적군 역할을 전문적으로 수행하는 부대가 있다. 얘들은 마치 버추어 파이터의 듀랄 컨셉 같아 보인다고 본인이 예전에 언급한 바 있다. 여느 군부대 사격장이나 각개전투장에서 볼 수 있는 북한군 차림의 인형(?) 표적만으로는 실전 같은 훈련을 하기에 충분치 못하니 군대에서 저런 것까지 도입한 것이다.

그런데 우리나라는 북한군 코스프레만 하는 게 아니다. 북한 김돼지의 코스프레를 전문으로 하는 북한 전문가를 몰래 양성해서 운용하기도 했다. 요즘도 있는지는 모르겠지만 과거에는 그런 게 확실하게 있었다는 것이 김 달술 씨 같은 전직 코스프레 요원의 증언을 통해 알려져 있다.

그런 사람을 왜 두냐고? 북한의 고위 관료나 심지어 김돼지를 직접 만날 예정인 우리나라 측의 대통령 내지 고위 관료를 비밀리에 교육· 훈련시키기 위해서라고 한다. 언어는 일단 같은 한국어를 쓰는데 현실적으로는 일본보다도 위험한 반국가단체 빨갱이들의 수괴요 적장이고.. 그런데 또 대놓고 적대시만 하기에는 좀 민망한 존재이니.. "직접 만나서 얘기를 나누게 되더라도 절대로 기선제압 당하지 말고 쫄지 마라."라는 취지에서 우리 내부에서 모의 훈련을 할 만도 해 보인다. 이건 북파 공작원을 양성하는 것과도 목적이 완전히 다르다.

김돼지 등 북한 역할을 하는 사람은 무슨 공작원처럼 인간흉기로 양성되지는 않는다. 단지, 자고 일어나면 맨날 역대 로동신문과 평양 방송을 송두리째 흡입하면서 북한 정세를 학습하고 김돼지의 말투와 몸짓, 요즘 관심사, 머리에 든 것 따위를 숙지했다고 한다.

당연한 말이지만 단순히 정치 드라마에서 김돼지 연기만 하는 배우와는 차원이 다른 양의 공부를 해야 한다. 그런데 남한 내부에서 북한의 사고방식을 룰 기반으로 정공법으로 익힐 수는 없으니, 결국 통계 기반으로 북한에 대한 빅데이터 머신 러닝 딥 러닝을 몸으로 실행하는 셈이다. 또한, 마치 음란물 자동 탐지 필터를 개발하는 엔지니어가 직업적으로 맨날 음란물에 파묻혀 지내야 하듯, 저 아저씨는 합법적으로 맨날 이적표현물에 파묻혀서 산다고 볼 수 있다.

북한 내부에서는 쿠데타나 암살에 대비해서 가짜 김돼지가 예비용으로 돌아다닐 법도 한데, 어쨌든 남한에서는 뭔가 다른 용도로 김돼지의 코스프레가 이런 식으로 그것도 몇 대에 걸쳐 비밀리에 양성되어 왔다는 게 신기하다. 인간을 화성으로 보낼 생각으로 지구의 하와이 모처에다가 화성 같은 환경을 꾸며 놓고 우주인들에게 몇 개월 동안 생존 훈련을 시키는 것과 비슷한 관행으로도 보인다.

우리가 자체적으로 이런 짓을 해 봤자 도대체 어디로 튈지 모르는 북한 사람과 만나는 데 무슨 도움이 됐겠냐 싶지만... 카더라 통신에 따르면 큰 도움이 됐다고 한다. 실제로 김 정일이 만나서 거론한 것, 질문한 것은 남한에서 자체적으로 준비해 간 예상 문제의 범위를 별로 벗어나지 않았으며 적중률도 대단히 높았다고 한다. 특히 우리나라 역사상 북한 수뇌를 최초로 직접 대면한 김 대중의 경우 70대 중반의 고령에도 참모진들이 준비해 준 대응 매뉴얼을 일일이 숙지하면서 답변을 아주 잘한 것으로 알려져 있다.

북한 때문에 이 나라에서는 안 그래도 지금까지 곳곳에 비밀도 많고 비리도 많고 숨겨진 게 너무 많은 채로 돌아갔던 게 사실이며, 저 카더라 통신도 한쪽에서 일방적으로 발표한 것이니 전적으로 믿을 수 있을지는 미지수다. 그렇게 기껏 철저히 준비하고는 김돼지를 만나고 와서 이뤄진 열매가 겨우 이 모양이라면 말이다.
김 대중 대통령이 집권하자마자 국정원을 싹 뒤집어엎고 북파 공작원들의 신원을 북쪽에다 넘겨 줘 버렸다는 말까지 나도는데.. 그것도 내가 직접 확인할 수는 없는 노릇이고.

다만 김 대중· 노 무현 같은 친북 성향의 정권이 설령 악의가 없었다고 하더라도 결국은 북한에 엄청난 거금을 퍼 주고도 북한은 하나도 바뀌지 않았으며 전화· 서신 왕래 하나 제대로 이뤄진 게 없었다. 가만히 놔두기만 하면 붕괴했을 북한 정권은 이 돈으로 원래 계획했던 핵을 무난히 개발하는 쾌거를 이뤘다. 철도 연결이나 이산가족 상봉 깜짝쇼쯤은 도박판에서 돈 다 날리고 받은 위로금 개평 수준?

남북 경제 협력 명목이랍시고 이뤄 냈다는 개성 공단을 온갖 이상한 논리와 궤변으로 옹호하는 사람들이 있는데.. 그들은 양심이 있다면 박통 시절에 노동자들의 열악한 근무 여건(특히 전 태일 열사)을 같이 논해서는 안 될 것이다. 박통 시절에 아무리 노동자 인권이 열악했어도 임금의 90%를 체제 충성 비용으로 국가가 떼어 가던가?

이래도 햇볕 정책이 악의적이지 않은 실책일 뿐이라고 별다른 비판 없이 넘어간면, 그렇다면 6· 25 때 이 승만 정권의 한강교 폭파와 인명 살상이야말로 훨씬 더 악의적이지 않은 실책일 뿐이라고 실드 치고 넘길 수도 있겠다. 이게 전체 그림의 진실인 것이다.

정치색 들어간 얘기는 이쯤에서 접고 다시 본문으로 돌아오면..
이렇듯 국가 대표로서 적성국가 사람과 대면하는 건 어지간히 힘든 일이 아니다. 옛날에 이 후락 중앙정보부장도 몰래 북한을 방문했을 때, 거기서 무슨 일을 당할지 모르니 만약을 대비해 언제든지 즉시 자폭 가능하게 독약 앰플을 준비해 갔을 정도였다.

그리고 같은 전방에서도 상대적으로 낙후해 있는 동부 전선 강원도 산간지대 말고.. 서울과 가까운 평지이고 판문점도 있는 서부 전선이 훨씬 더 엄선된(체력· 사상 모두) 정예 군인들이 배치된다. 여기 일대는 민통선과 DMZ의 구분이 좀 므흣해서 북한군과 직접 대면하기 쉽고 각종 높으신 분들도 많이 오며, 덩달아 어느 지역보다도 월북 가능성이 높기 때문에 여기가 그야말로 노다지 진급 코스이다. 육사 졸업생은 바로 이런 데에서 소대장으로 첫 근무를 시작한다.

3. 탈북자가 가는 곳

북한 주민들이 탈북을 하는 경로는 신분과 지위에 따라 다양하다. 외국에 파견 나가 있다가 별안간 망명을 신청하기도 하고, 천신만고 끝에 중국 국경으로 넘어간 뒤 다른 나라를 거쳐 한국으로 오기도 한다. 배를 타고 넘어오거나 국경에서 근무 중인 군인이 별안간 남쪽으로 오는 경우도 있다.

이렇게 남쪽으로 넘어오는 북한 주민들은 명목상으로는 반국가단체의 지배 하에 있다가 탈출해 온 '대한민국 국민'이다. 그렇기 때문에 우리나라의 입장에서는 자유 대한의 품에 안긴 그들을 최대한 인간적으로 대우한다. 그러나 한편으로는 탈북자로 위장 행세를 하는 간첩도 있기 때문에, 대접을 하기에 앞서 이들에 대한 최소한의 의심과 검증은 거친다. 탈북했다가 별안간 "나 마음이 바뀌었으니 북으로 다시 보내 주쇼" 하고 떼쓰는 이상한 아줌마도 있는데 이건 99.9% 간첩이다.

필요 이상으로 이상하게 북한을 자주 방문하는 사람도 굉장히 의심해야 한다. 그런 놈들은 북에 가서는 돈 왕창 바친 뒤 또 지령 받아서 되돌아오기 때문이다. 정치· 종교 쪽으로 유명한 사람이 북에서 자기 지위와 관련된 약점을 한번 잡힌 뒤부터는(마약이나 성 스캔들 같은) 북에 대해서 소신 발언은 끽소리도 못 하는 친종북 인사가 돼 버린다.

뭐 이런 경위가 있기 때문에, 탈북자라고 주장하는 사람이 접수되면 곧바로 하나원 같은 정착 지원 시설로 가는 게 아니다. 이들은 정확한 신원 파악을 위해 먼저 탈북자 전용 신문 센터에 며칠간 수용되어 정밀 조사를 받는다. 이건 국정원 자체는 아니지만 국정원에서 관할하는 시설이며, 시흥시 수인로라는 대로변에 자리잡아 있다. 당연히 아무 이정표도 없고, 밖에서 봐서는 이런 시설이 있는지 일반인은 전혀 알 수 없다.

정밀 조사를 통해 이들이 정말로 북한에서 왔고 악의가 없는 탈북자가 맞는지를 최종 확인한다. 우리나라도 정부 수립 이래로 지금까지 탈북자가 한두 명 쌓인 게 아니고 이 바닥 장사를 하루 이틀 하는 게 아닌데, 수많은 탈북자들의 증언을 바탕으로 교차 검증 가능한 데이터쯤이야 왕창 쌓여 있다. 정말로 북한의 그 지역에서 그 당시를 살았던 사람이라면 모를 수가 없는 내용을 거듭 질문해서 제대로 대답하는지 확인한다.

검증을 통과한 뒤 탈북자들은 하나원에서 총 12주간 남조선 사회 제도에 대한 교육을 받은 뒤, 각종 정착 자금을 받고 사회로 배출된다. 게임에서 튜토리얼을 한 뒤, 캐릭터가 본게임 필드에 스폰돼서 처음엔 깜빡거리는 실드 모드이다가 그 뒤부터는 실드 모드가 꺼지는 것과 같다.
세월이 흐르면서 탈북자가 워낙 많아지고 이들을 받아들이는 게 '귀순 용사'로 일일이 띄울 필요도 없는 일상적인 일과가 되자.. 하나원 역시 2010년대에 와서는 화천군에 멀티를 또 만들었다. 본원은 안성 품곡마을 근처에 있다.

하나원과 신문 센터 모두 법적으로 '가급 보안 시설'이고 지도에는 전혀 나와 있지 않다. 북한이 위치를 알아서 좋을 게 하나도 없는 시설이니까. 국정원 본원 자체도 코렁시설이지만 신문 센터라든가 국가 정보 대학원 같은 추가적인 연계 코렁시설도 있다는 점이 흥미롭다.
그나저나 서독산과 수리산의 사이에 있는 안양 박달동은 보아하니 산지 같은데 산 전체가 몽땅 온갖 군부대로 가득하구나. 예비군 훈련장도 당연히 있고. 산 전체가 탄약고인 천안 성환읍 학정리를 보는 듯한 느낌이다.

Posted by 사무엘

1. 도움말 시스템

Visual C++ (지금의 Visual Studio)이 개발된 이래로 IDE가 제공하는 도움말 및 API 레퍼런스 시스템은 다음과 같이 변모해 왔다.

• 1세대 1.x~2.x: 그냥 평범한 WinHelp 기반 hlp
• 2세대 4.x, 5: 리치 텍스트(RTF) 기반의 자체적인 도움말 시스템이 IDE 내부에 통합되어 제공. 같은 컴퓨터 사양에서 RTF 기반 엔진은 이후에 등장한 IE+HTML 기반 엔진보다 텍스트 표시와 스크롤 속도가 훨씬 더 빨랐다.
• 3세대 6: RTF 대신 HTML 기반의 외부 도움말로 갈아탐. MSDN이라는 명칭 정립.
• 4세대 200x (.NET ~ 2008): HTML 기반이지만 CHM 말고 다른 컨테이너를 사용하는 Document Explorer. 도움말을 IDE 내부에 구동할 수도 있고 외부에 구동할 수도 있음. 융통성이 생겼다.
• 5세대 201x: Help Viewer 도입. 버전도 1.0부터 리셋 재시작.

하긴, 비주얼 C++의 프로젝트 파일 포맷도 이와 거의 비슷한 단계를 거치며 바뀌어 왔다. vcp(1세대), mdp(2세대), 3세대(dsw/dsp), 4세대(sln/vcproj), 5세대(sln/vcxproj)의 순. 단, 비주얼 C++ 5는 2세대 도움말 기반이지만 프로젝트 파일은 예외적으로 3세대 6.0과 동일한 dsw/dsp기반이다.

본인은 지금의 일명 5세대 도움말 시스템을 별로 좋아하지 않았다.
일단 5세대 시대를 처음으로 시작한 Visual Studio 2010은 후대 버전은 안 그런데 얘만 유독 무겁고 시동 속도가 무척 느렸다.
그리고 같이 내장된 Help Viewer 1은 '색인' 탭으로 가면 심한 랙이 걸려서 몹시 불편했다. 재래식 4세대 도움말에 비해 기능 차이는 별로 없는데 느리고 무거워지기만 해서 학을 뗐다.

그나마 2012부터는 IDE가 가벼워지고 도움말의 랙도 없어진 듯하다. 그 대신 2010에는 없던 다른 사이드 이펙트가 생겼다.
첫 구동되어서 Help Viewer 스플래시 화면이 뜰 때 마우스 포인터가 움직이지 않을 정도로 컴퓨터가 잠시 stun(멈칫)된다. 구닥다리 내 컴에서만 그런 줄 알았는데 회사의 초고성능 최신식 컴퓨터에서도 동일한 현상이 발생한다.

먼 옛날의 불안정한 유리몸이던 Windows 9x도 아니고 엄연히 7~10급의 최신 OS에서 하드웨어를 도대체 어떻게 건드렸길래 마우스 포인터조차 움직이지 않는 상태가 되나?

잘 알다시피 요즘 Visual Studio IDE는 평범한 Win32 API로 GUI를 만드는 게 아니라 닷넷 + Windows Presentation Foundation 기반으로 특수하게 하드웨어 가속도 받으면서 아주 뽀대나는 방식으로 그래픽을 출력한다.
글자를 찍는 계층도 뭐가 바뀌었는지, 텍스트 에디터에는 트루타입 글꼴만 지정되지 FixedSys 같은 비트맵 글꼴을 사용할 수 없게 바뀌었다. '굴림'은 트루타입이니 사용은 가능하지만 embedded 비트맵이 대신 찍히는 크기에서도 ClearType이 적용되어 색깔이 살짝 바뀌어 찍히며, 같은 글자끼리도 폭이 좀 들쭉날쭉하게 찍힌다.

이렇듯, 재래식 GDI API로 글자를 찍었다면 절대로 나타나지 않을 사이드 이펙트들이 좀 보인다.
그런 특수한 그래픽/GUI를 사용하기 위해서 마치 게임 실행 전처럼 하드웨어 초기화가 일어나고, 그때 마우스 포인터가 살짝 멈추는가 하는 별별 생각이 든다.

2. GDI API 설명은 어디에?

요즘(2010년대) Visual Studio의 MSDN 레퍼런스엔 왜 GDI API들이 누락돼 있는지 궁금하다. BitBlt, SetPixel 같은 것들. desktop app development에 해당하는 몇백 MB짜리 도움말을 분명히 설치했는데도 로컬 도움말에 포함되지 않아서 저것들 설명은 느린 인터넷 외부 링크로 대체된다.

VS 2010에서는 GDI 관련 API들이 색인으로는 접근 가능하지만 목차에서는 존재하지 않아서 접근불가였다. 그리고 MFC 레퍼런스도 단순한 API wrapper의 경우(가령 CDC::MoveTo) See also 란에 자신의 원래 API 함수에 대한 링크(가령 MoveToEx)가 있는데, 요건 내부 링크가 아니라 인터넷 MSDN 사이트의 외부 링크로 바뀌어 있었다.

즉, 그때부터 GDI API의 설명은 제외될 준비를 하고 있었던 듯하다. 그 뒤로 2012인가 2013 이후부터는 그것들이 색인에서도 제외되고 완전히 없어졌다. 2015도 마찬가지인 걸 보니 GDI의 누락은 단순 지엽적인 실수가 아니라 의도적인 계획인 것으로 보인다.

kernel32, user32, advapi32 등 나머지 API들은 다 남아 있는데 왜 GDI만 없앴는지, 얘는 정말로 완전히 deprecate 시킬 작정인지 알 길이 없다. Windows NT 3.1 초창기 때부터 20년이 넘게 운영체제의 중추를 구성해 온 놈인데 그걸 호락호락 없애는 게 가능할까? 게다가 BeginPaint, GetDC처럼 GDI를 다루지만 실제로는 USER 계층에 속해 있는 기초 필수 API조차 언급이 누락된 것은 좀 문제라고 여겨진다.

이런 것 때문에 본인은 Visual Studio는 옛날 Document Explorer 기반이던 200x도 여전히 한 카피 설치해 놓고 지낸다.
옛날에는 또 Visual C++ 2005의 MSDN만 TSF API 레퍼런스도 없고 뭔가 나사가 빠진 듯이 컨텐츠가 왕창 부실해서 내가 놀랐던 기억이 있다. 2003이나 2008은 안 그랬고 걔만 좀 이상했었다.

3. 프로젝트에 소속되지 않은 소스 코드도 심층 분석

Visual C++. 2013인지 2015인지 언제부턴가 프로젝트에 등재되지 않은 임의의 C/C++ 소스 코드를 열었을 때도 이 파일을 임시로 파싱해서 인텔리센스가 동작하기 시작했다. 이거 짱 유용한 기능이다.
전통적으로 프로젝트 소속이 아닌 파일은 문맥을 전혀 알 수 없으며 빌드 대상도 아니기 때문에 IDE에서의 대접이 박했다. 정말 기계적인(문맥 독립적이고 명백한) 신택스 컬러링과 자동 들여쓰기 외에는 자동 완성이나 인텔리센스 따위는 전혀 제공되지 않았다. 전혀 기대를 안 하고 있었는데 이제는 걔들도 miscellaneous file이라는 범주에 넣어서 친절하게 분석해 준다.

4. Spy++

Visual C++에는 프로그램 개발에 유용하게 쓰일 만한 아기자기한 유틸리티들이 같이 포함돼 있다.
'GUID 생성기'라든가 '에러 코드 조회'는 아주 작고 간단하면서도 절대로 빠질 일이 없는 고정 멤버이다.
옛날에는 'OLE/COM 객체 뷰어'라든가 'ActiveX 컨트롤 테스트 컨테이너'처럼 대화상자가 아닌 가변 크기 창을 가진 유틸리티도 있었는데 OLE 내지 ActiveX 쪽 기술이 인기와 약발이 다해서 그런지 6.0인가 닷넷 이후부터는 빠졌다.

그 반면, 기능이 제법 참신하면서 1990년대부터 지금까지 거의 20년 동안 변함없이 Visual C++과 함께 제공되어 온 장수 유틸리티는 단연 Spy++이다.
얘는 제공하는 기능이 크게 변한 건 없었다. 다만 아이콘이 초록색 옷차림의 첩보요원(4.x..!), 분홍색 옷차림(6.0~200x), 검정색 옷차림(2010~현재)으로 몇 차례 바뀌었으며, 운영체제의 최신 메시지가 추가되고 도움말이 hlp에서 chm으로 바뀌는 등 외형만이 최소한의 유지보수를 받아 왔다.

아, 훅킹을 사용한다는 특성상 2000년대 중반엔 64비트 에디션이 따로 추가되기도 했다. 하지만 GUI 껍데기는 x86용 하나만 놔두고 64비트 프로그램에 대해서는 내부적으로 64비트 서버 프로그램을 실행해서 얘와 통신을 하는 식으로 프로그램을 개발하면 더 깔끔했을 텐데 하는 아쉬움이 남는다. 그러면 사용자는 겉보기로 한 프로그램에서 32비트와 64비트 구분 없이 창을 마음대로 들여다보고 훅킹질을 할 수 있을 테니 말이다.

실제로 <날개셋> 입력 패드도 그런 식으로 동작하며, 당장 Visual C++ IDE도 내부적으로 64비트 IPC 서버를 따로 운용하기 때문에 IDE 자체는 32비트이지만 64비트 프로그램도 아무 제약 없이 디버깅이 가능하다. 하지만 안 그래도 훅킹을 하느라 시스템 성능을 잡아먹는 프로그램인데.. 성능 문제 때문에 깔끔하게 64비트 에디션을 따로 빌드한 것일 수도 있으니 Spy++ 개발자의 취향은 존중해 주도록 하겠다.

Spy++는 워낙 역사가 긴 프로그램이기 때문에 초창기 버전은 창/프로세스들의 계층 구조를 전용 트리 컨트롤이 아니라 리스트박스를 정교하게 서브클래싱해서 표현했다. 쉽게 말해 과거 Windows 3.1의 파일 관리자가 디렉터리 계층 구조를 표현한 방식과 비슷하다. 사실은 리스트박스에서 owner draw + user data로 계층 구조를 표현하고 [+/-] 버튼을 눌렀을 때 하부 아이템을 표시하거나 숨기는 건 1990년대 초반에 프로그래밍 잡지에서 즐겨 다뤄진 Windows 프로그래밍 테크닉이기도 했다.

그러다가 VC++ 2005인가 2008 사이쯤에서 Spy++은 운영체제의 트리 컨트롤을 사용하는 걸로 리팩터링이 됐다. 사용자의 입장에서는 기능상의 변화가 없지만 내부적으로는 창을 운용하는 방식이 완전히 바뀐 것이기 때문에 이건 내부적으로 굉장히 큰 공사였으리라 여겨진다.

그런데 VC++ 2010과 함께 제공된 Spy++는 일부 단축키들이 동작하지 않는 버그가 있었다. 전부 먹통인 것도 아니고 창 찾기 Alt+F3, 목록 새로 고침 F5, 속성 표시 Alt+Enter 같은 게 동작하지 않아서 프로그램을 다루기가 불편했다. 이 버그는 잠깐 있었다가 다시 2012 이후에 제공되는 Spy++부터는 고쳐졌다.

Posted by 사무엘