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

이번 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 사무엘

* 옛날 2014년에 썼던 글을 관련 내용을 크게 보강하여 리메이크 한 것이다.

디지털 컴퓨터라는 게 0과 1, 2진법을 사용하다 보니, 2^n이라 하면 정보량과 관련해서 특히 컴퓨터쟁이들에게 아주 친근한 수이다.
그런데 2^n보다 1 더 크거나 작은 수가 소수라면 제각각 수학적으로 좀 독특한 의미를 갖게 된다.

1.
2^n-1 형태인 수를 메르센 수라고 한다. n층짜리 하노이의 탑의 원반을 옆으로 모두 옮기기 위해서는 이 메르센 수만치 지수함수적으로 증가하는 횟수만치 원반을 이동시켜야 한다. 그리고 메르센 수 중에서 소수인 놈을 메르센 소수라고 한다.
얘가 소수이려면 n도 반드시 소수여야 한다. n을 a와 b라는 두 자연수의 곱이라고 생각하고 2^ab - 1을 인수분해해 보면 그래야만 하는 구조적인 이유를 알 수 있다.

(2^ab는 (2^a)^b 와 같다. 2^(a+b)하고 혼동하지 말 것.)

n이 합성수여서 2 이상인 두 자연수 a, b의 곱으로 나타내어질 수 있다면 2^n-1은 빼도 박도 못하고 무조건 합성수가 돼 버린다. 전체 결과가 소수가 되려면 a는 1이고 b는 소수로 귀착되는 것밖에 가능성이 없다. 비록 이 조건이 만족된다고 해서 2^n-1이 언제나 반드시 소수가 된다는 보장은 없지만 말이다.
가장 작은 반례는 2^11-1이다. 11은 소수이지만 2047은 23*89로 소인수분해 되는 합성수이다.

메르센 수는 2^n에서 1이 부족한 형태라는 특성상 2진법으로 나타내면 모든 자리수가 1이다. 컴퓨터에서 취급이 간편하기도 하고, 또 n의 소수 여부를 판정한 뒤에 곧장 무려 2^n-1이라는 방대한 수를 취급할 수 있다는 특성상.. 컴퓨터로 가장 큰 소수를 찾는 프로젝트는 대개 메르센 수를 대상으로 진행되곤 한다. 물론 실제로는 메르센 수가 아닌 소수도 많이 있으며, 반대로 메르센 수 중에서도 메르센 소수는 매우 드물다는 점을 감안할 필요가 있다.

저런 거 찾는 건 거의 애니메이션 렌더링과 같은 급으로 상상을 초월하는 계산량으로 컴퓨터를 열받게 하고 혹사시키는 작업이다. 그나마 양만 많지 내부 과정 자체는 단순무식한 편이니 병렬화가 수월한 건 다행인 점이다.

메르센 소수는 짝수 완전수와 필요충분 관계로 정확히 대응하는 것으로 유명하다. (약수의 합이 자신과 같은 6, 28, 496 같은 수) 메르센 소수 2^n-1에다가 2^(n-1)을 곱하면 완전수가 나오기 때문이다. 괄호 순서에 유의할 것. 즉, 저기서 n에다 소수를 집어넣으면 된다. 천재 수학자 오일러가 모든 짝수 완전수는 이런 형태라는 것을 증명했다.
현재까지 메르센 소수는 약 50여 개가 알려져 있으나, 무한히 존재하는지는 불명이다.

2.
그럼, 다음으로 2^n+1의 경우를 생각해 보자. +1은 -1보다 더 자비심이 없다. n은 소수가 아니라 반드시 2의 거듭제곱 형태여야 그 값이 소수일 일말의 가능성이 생긴다. 이는 n의 소인수 중에 홀수가 절대로 존재해서는 안 됨을 의미한다. 아까 전과 비슷한 방식으로 2^ab + 1을 인수분해해 보면 그 이유를 알 수 있다.

n의 소인수에 홀수가 존재해서 그걸 b라고 설정하면 아까 -1일 때와는 부호만 미묘하게 다르게 저렇게 인수분해가 되며, 이 수는 100% 합성수임이 보장돼 버린다. (2^a - 1)이라면 a=1인 걸로 맞춰서 없앨 수라도 있지만, (2^a + 1)은 도저히 처분할 방법이 없다.

하긴, 고등학교 공통수학 수준의 인수분해 공식을 생각해 봐도, n이 홀수일 때에 한해서 (a^n + b^n)은 a+b로 나눠 떨어지며 인수분해가 된다. 나눠진 몫에 해당하는 항은 a^n에서 b^n으로 a와 b의 차수가 조금씩 늘고 줄고 부호가 교대로 바뀐다.
이를 일반화하면, n이 굳이 홀수가 아니더라도 6이나 10처럼 홀수 소인수가 포함돼 있으면(3, 5) (a^n + b^n)은 굳이 a+b가 아니더라도 (a^2+b^2) 같은 것으로라도 나눠 떨어지며 인수분해가 된다. 그렇지 않고 홀수 소인수가 전혀 없다면 +의 경우는 인수분해를 할 수 없다.

부연 설명 차원에서 인수분해된 식들이 전개되는 양상을 시각적으로 살펴보면 이러하다.
a^n - b^n은 n의 값과 관계없이 언제나 a-b로 나눠 떨어지며, 나눠진 몫의 항들은 부호가 모두 +가 유지된다. 전부 +인 항들이 한 칸 옆으로 물러간 채 -로 바뀌어서 전부 +/-가 상쇄돼 버리고 맨 앞의 +와 -만 남는다
++++
 ----
+...- (a-b)

하지만 a^n + b^n일 때는 +와 -가 교차하는 항들이 한 칸 옆으로 맞물려서 상쇄돼야 맨 앞과 뒤의 +가 남을 수 있다. 그러니 이때는 항이 홀수 개여서 양 끝이 +가 유지돼야 인수분해가 가능해지는 것이다.
+-+-+
 +-+-+
+....+ (a+b)

(쪼개고 쪼개도 분자 단위에서 계속 앞뒤로 + - 극을 갖는 자석 같아 보이기도 하고..;;)
이 두 경우를 모두 종합한 듯이 인상적인 상황은 (a^n - b^n)에서 n이 2의 거듭제곱 형태일 때이다. n=8인 경우를 예로 들어 보면, 이 식은 (a^4 + b^4)(a^2 + b^2)(a + b)(a - b)라고 아주 드라마틱하게 인수분해가 된다. n이 2의 거듭제곱이면 (a^n + b^n)은 -일 때와는 반대로 인수분해가 도저히 더 되지 않는 다항식계의 소수(?) 같은 존재가 된다.

그렇기에 2^n+1도 n이 반드시 2의 거듭제곱 형태여야만 구조적으로 인수분해가 되지 않고 소수일 가능성이 생기는 것이다. 그리고 2^(2^n)+1 형태인 수를 페르마 수라고 하며, 그 중 소수인 놈을 페르마 소수라고 한다. 간단하게 2^n-1로 정의되는 메르센 수와는 양상이 다르다.

그러니, 태생적으로 딱 봐도 페르마 소수는 메르센 소수보다도 더욱 드물 것 같이 생겼는데, 실제로 그러하다.
n에 비례해서 숫자가 넘사벽급으로 너무 폭발적으로 커지는 관계로, 페르마 소수는 n=0..4인 처음 겨우 5개밖에 알려져 있지 않다(3, 5, 17, 257, 65537). n이 아니라 2^n으로 계산한 것이다.

여기서 페르마란 "페르마의 마지막 정리" 내지 추측을 제시했던 17세기 프랑스의 그 엄친아 변호사 겸 아마추어 수학자를 가리키는 거 맞다..
페르마 자신은 저런 형태로 생성된 모든 수들이 소수일 거라고 1637년에 추측하였으나, 그로부터 100여 년 뒤인 1732년, 오일러가 n=5인 2^32+1은 소수가 아니라고 반증을 해 버렸다. 아까 그 메르센 소수와 완전수 관계를 증명한 그 오일러 말이다.
지금이야 그 정도 크기의 수는 컴퓨터로 소수 여부를 아주 간단히 판별할 수 있지만 오일러는 컴퓨터도 없던 시절에 저걸 도대체 어떻게 알아낸 걸까? 찰스 웨슬리가 찬송시 And can it be that I should gain을 쓰기도 전의 일이다(1738).

제곱근인 65536 이내의 모든 홀수들을 브루트 포스 식으로 일일이 주판 돌려서, 제자들까지 멀티코어로 동원해서 나눠 본 건 물론 아니고..
2^32 + 1의 소인수는 반드시 64k+1 의 형태라는 것을 어떤 계기로 알아내고는 찾았다고 한다. 범위를 많이 좁힌 것이다.
실제로 2^32 + 1은 641 * 6700417인데, 이는 (64*10+1)*(64*104694+1)이다.
그는 이를 일반화하여 페르마 수의 소인수는 반드시 "2의 거듭제곱의 a배 + 1"이라는 사실까지 정립했다.

n=5에 속하는 2^32+1에 이어 n=6 (2^64 + 1)의 경우도 합성수라는 게 추가로 밝혀진 건 오일러 이후로 또 100년이 넘게 지난 무려 1855년의 일이다(by Thomas Clausen). 나머지 페르마 수들도 대략 32까지 구해 보니 줄줄이 다 합성수라는 것이 계산을 통해 밝혀졌다. 페르마의 예상과는 정반대로 흘러간 셈이다.
그러니 65537을 끝으로 페르마 소수는 더 존재하지 않는 게 아닌가 추측되고 있으나, 이 역시 홀수 완전수의 존재 여부만큼이나 정식으로 증명된 것은 아니다.

메르센 소수가 짝수 완전수와 동치 관계이듯, 페르마 소수 역시 굉장히 의외의 곳에 큰 의미를 지니고 있다. 이것은 작도 가능한 정다각형의 특성과 관계가 있다. 변의 개수의 소인수가 2 and/or 페르마 소수들로만 이뤄진 정다각형은 눈금 없는 자와 컴퍼스를 이용해 작도 가능하다. 작도 가능한 수는 아무래도 사칙연산과 '제곱근'만으로 기술 가능한 수이니, 제곱근만을 연달아 적용하는 건 2의 거듭제곱만치 또 거듭제곱을 하는 것과 심상면에서 비슷해 보이긴 한다.

그렇기 때문에 작도 불가능한 최초의 정다각형은 정칠각형이며, 반대로 정17각형은 절차가 굉장히 복잡하고 까다롭긴 해도 작도 가능하다. 17은 페르마 소수이니까. 이걸 발견하여 증명한 사람은 오일러...는 아니고 18세기 독일의 천재 수학자인 가우스이며, 그것도 굉장히 어린 나이에 발견했다. sin 1도가 초월수가 아니라 대수적인 수이듯, cos 2*PI/17 역시 형태만 복잡할 뿐, 대수적인 수임을 의미한다.

(그림의 출처: 나무위키)
뭐, 이론적으로만 가능하다는 거지, 실제로 해 보면 누적되는 오차와 지저분한 보조선들 때문에 감당이 어려울 것이다. 하물며 정257각형과 심지어 정65537각형은? 이것도 이론에서나 작도 가능하다는 얘기다.

자, 지금까지 한 얘기들을 요약하면 다음과 같다.

• a^n-b^n은 언제나 a-b로 나눠 떨어지며 2^n-1 역시 그런 꼴의 수이므로, 얘를 소수로 만들려면 a-b가 반드시 1인 상황을 만들어야 한다. 그리고 메르센 수에서 그 경우란 n이 소수인 경우밖에 없다.
• 그리고 2^n+1의 일반형인 a^n+b^n은 아까처럼 한쪽 인수를 1로 만드는 게 불가능한 대신에, 인수분해 가능 여부가 n의 차수에 따라 조건부로 결정된다. 소수를 만들려면 물론 애초에 인수분해를 할 수 없는 상황을 만들어야 하며, n은 단순히 짝수인 정도를 넘어 소인수에 홀수가 전혀 없어야 한다. 그래서 n 자체가 2의 거듭제곱 형태인 것만 남는다.

그러고 보니 페르마뿐만 아니라 메르센도 17세기 동시대를 살았던 프랑스 사람이기 때문에 둘이 공통점이 있다. 메르센은 블레즈 파스칼의 스승이기도 했다. 프랑스, 독일 그쪽은 수학· 과학 쪽으로 그때로부터 지금까지 한가닥 하고 있는 대단한 동네이다.

* 소수 관련 여담

(1) 소수 자체가 안 그래도 수가 커질수록 (log n) / n 급의 스케일로 자연수에서 등장 빈도가 극도로 드물어진다. 그런데 그 소수들 중에서도 굉장히 까다로운 조건을 만족하는 메르센 내지 페르마 소수 같은 것들은 한계치 최대치가 존재한다 해도 이상할 게 없을 것이다. 굳이 수 자체가 특이한 게 아니더라도 2 간격으로 나란히 존재하는 쌍둥이 소수 쌍(5와 7, 11과 13, 17과 19..) 같은 것도 말이다. 그런데 한계치가 있다면 그 최대값이 알려져 있어야 할 텐데 그것이 수수께끼이다.

(2) 오일러의 업적 중에는 소수와 관련해서도 정말 살떨리는 것들이 많다. 자연수의 제곱의 역수의 무한합이 원주율과 관계 있는 수로 수렴한다는 것을 규명했을 뿐만 아니라 이건 소수의 분포와도 관계가 있기 때문에 임의의 두 수가 서로 소일 확률과 같다고 입증한 건 뭐.. 할 말을 잃게 만든다. 예전에 본인의 블로그에서 다룬 적이 있다.

(3) 또한 그는 소수의 개수가 무한한 건 말할 것도 없고, 소수의 역수의 무한합이 무한대로 발산한다는.. 거의 충격과 공포 안드로메다급의 명제도 증명했다. 물론 속도는 이중 로그(로그에다 또 로그) 급으로 끔찍하게 느리니 기대하지 말자. 그냥 자연수의 역수의 합만 해도 얼마나 느린데 하물며 소수의 역수는! 쉽게 말해 10에다 0을 10의 20승개만치 붙인 영역만치 소수의 역수를 더하면 합이 20이 될까말까 한다는 뜻이다. 쟤가 도대체 제곱의 역수의 무한합보다 뭐가 더 나은 구석이 있다고 발산을 하는 걸까?

단, 쌍둥이 소수들의 역수의 합은 유한으로 수렴한다고 한다. 쌍둥이 소수가 유한하다면 당연히 유한 수렴이겠지만, 무한하다 하더라도 얘는 발산하지 못한다고.. 구체적인 값은 모르겠지만 추세가 그렇게 된다는 큰 그림만 증명을 한 것이다. 어떻게 증명했는지는 나한테 묻지 마시길.

(4) 가우스, 오일러 등 인류 역사상 수많은 괴수 천재 수학자들이 초월적인 업적을 남기고 갔지만, 어떤 형태로든 소수 생성 규칙을 표방하는 모든 예측· 추측은 지금까지 하나도 완벽하게 적중한 게 없었다. 저 페르마의 추측처럼 말이다.
소수를 생성하는 규칙을 무슨 정보 검색이나 패턴 매칭에다가 비유해서 설명하자면, 정밀도와 재현율(precision & recall) 어느 것 하나라도 확실하게 잡는 규칙이 지금까지 발견된 적이 없다는 것이다. 정밀도가 100%라면 모든 소수를 커버하지는 못해도 일단 이 규칙이 생성하는 수는 다 소수임이 보장되는 것이고, 재현율이 100%라면 종종 소수가 아닌 놈(false alarm)이 섞여 있더라도 소수는 하나도 빠짐없이 커버한다는 뜻이다.

(5) partition number라는 게 있다. f(2)라면 1+1, 2 이렇게 2가지, f(3)이라면 1+1+1, 2+1, 3 이렇게 3가지, f(4)라면 1 1 1 1, 2 1 1, 2 2, 3 1, 4 이렇게 5... 뭔가 테트리스 조합처럼 올라가는데, 이 수열이 2 3 5 7 11 (15 22...) 이렇게 앞부분은 소수와 굉장히 비슷한 양상으로 시작한다. 무슨 파이의 그럴싸한 근사값을 보는 듯한 느낌이나, 얘는 실제로는 소수와는 수학적으로 아무런 관련이 없는 놈이다.

n에 대해서 f(n)의 값을 구하는 건 다이나믹 프로그래밍으로 해결 가능하다. 피보나치 수열 구하는 것보다는 어렵고 꽤 재미있는 프로그래밍 excercise이므로 관심 있으신 분은 도전해도 좋다. 참고로 점화식 함수 내지 테이블은 보기와는 달리 1변수로는 안 되고 2변수 형태로 짜야 한다.

Posted by 사무엘

오늘은 미풍양속에 어긋나는 다소 민망한 주제 이야기를 이것저것 나열하고자 한다. 작년과 재작년에도 이 주제와 관련된 글을 1년에 하나씩은 쓴 적이 있었는데.. 관심 있으신 분은 '투신'이라는 키워드로 검색을 해 보면 나온다.

1.
2012년과 2013년에는 아파트에서 투신 자살하는 사람에게 다른 사람이 깔려 죽는 사고가 한 건씩 있었다. 물론 피해자만 죽은 건 아니고 가해자도 나란히 사망. 자동차 위에라도 떨어졌으면 보통은 살던데 겨우 사람은 자신이 충격을 받고 깔렸다고 해서 투신 자살 가해자를 살릴 정도로 실드 역할을 하지는 못한다.

그런데 동일한 패턴의 사고가 그로부터 3년쯤 뒤인 2016년에 또 반복됐다.
5월 31일 저녁, 광주 북구 오치동에서는 퇴근한 남편, 부인, 6살짜리 아들 이렇게 일가족이 아파트 단지 입구로 들어가는 중이었는데, 처지를 비관하여 동일 아파트의 20층에서 뛰어내린 한 20대 청년이 세 명 중 가장인 남편을 덮쳤다.
뉴스 보도에 따르면 뛰어내린 그 사람은 현장에서 즉사했고, 깔린 40대 남성은 치명상을 입고 급히 병원으로 옮겨졌지만 약 3시간 만에 숨졌다고 한다.

누군가가 투신 자살한 것은 '사건'이지만, 투신 자살자에게 다른 사람이 깔려 죽은 건 '사고'이다.
안타까운 음주· 졸음운전 교통사고가 해마다 반복되는 것처럼, 이런 사고도 교통사고만치 잦지는 않지만 어째 이렇게 반복되나 모르겠다.

가해자는 공시를 준비 중인 공무원 지망생이었다고 한다. 허나, 잘 알다시피 살인적인 경쟁률을 자랑하는 그 시험에서 호락호락 좋은 결과가 나올 리는 없었을 것이고, 이 때문에 열등감, 무력감, 비관의식 등에 사로잡혀 극단적인 선택을 했으리라 여겨진다. 자살 말고 다른 극단적인 선택을 한 어떤 사람은 아예 정부 청사에 침입해 들어가서 어설프게 성적을 조작하려 하기도 했다. 어느 경우든 다 멘탈이 정상적인 상태는 아니다.

그런데 저 사람의 경우, 자기가 죽으면서 결과적으로는 자신의 워너비에 속하는 다른 '공무원'을 같이 죽게 했으니 이 아이러니를 말로 어찌 표현해야 할지 모르겠다. 그 가장은 전남 소재의 어느 도청에서 근무하는 공무원이었기 때문이다(집은 광주). 부인 되시는 분은 그냥 남편도 아니고 최고로 안정적인 직장에 다니던 남편을 하루아침에 잃은 충격과 대미지가 차마 감당 가능한 수준이 아니었을 것이다. 게다가 둘째 아이를 임신까지 한 상태였는데! 그 자살자 때문에 저 가정도 완전히 파탄 나고 말았다.

2.
이제 좀 옛날 이야기를 하겠다.
우리나라는 해방 후 아직 어수선한 미군정 시절이던 1947년 5월 1일, 에블린 맥헤일(Evelyn McHale)이라는 20대 초반의 아가씨가 여느 아파트도 아니고 엠파이어 스테이트 빌딩의 전망대에 올라가서 무려 86층, 거의 300m에 달하는 높이에서 뛰어내렸다. 1940년대 당시엔 그 건물이 세계에서 가장 높은 건물이었다.

이 사람은 무슨 모델이나 연예인, 유명인사도 아니고, 정말 평범하게 월급쟁이 직장인 생활을 하다가 평범하게 남친 사귀고 약혼까지 하고.. 정황상 자살할 만한 이유가 전혀 없던 사람이었다. 머릿속으로 도대체 무슨 생각을 하고 있었는지.. 단지, 약간 성깔 부리는 완벽주의자 성향은 좀 있었던 것 같으며, 유서를 보면 그런 기질이 더욱 느껴진다. (☞ 이 사건에 대한 더 자세한 정황 설명)

그녀는 운명의 그 날엔 별안간 집을 나와서 "남친에게서 결혼 프러포즈를 받았지만 난 좋은 아내가 될 자신이 없다. 난 어떤 남자에게도 좋은 아내가 못 될 것 같다. 그이는 내가 없으면 더 잘 살 것이다. 나는 가족· 타인을 불문하고 아무에게도 내 모습, 내 존재를 더는 노출하고 싶지 않다. 내가 죽더라도 제발 장례식 같은 거 치르지 말고 시신을 화장해서 완전히 없애 달라" 라는 요지의 꽤 염세적인 논조의 유서를 썼다. 그러고 나서 그 높은 곳에서 아래로 뛰어내렸다.

건물 아래는 사람과 차들로 가득한 뉴욕 시내 한복판이었다. 그녀는 사람이 아닌 어느 리무진 승용차 위에 떨어졌다. 워낙 높은 곳에서 떨어지는 바람에 자동차는 굉음을 내며 박살이 났지만, 차가 그렇게 충격을 받아 주고도 그녀는 목숨을 부지하지 못하고 현장에서 즉사함으로써 생을 마감했다.

단, 자신의 존재를 세상에서 완전히 지우고 없애고 싶었던 그녀의 바람은 전혀 이뤄지지 못했다. 오히려 나 같은 사람조차 인터넷 검색을 통해 알 정도인 유명한 사람이 되고 말았다.
그 이유는 떨어진 직후의 모습 때문이다. 시신은 마치 "잠자는 숲속의 미녀"처럼 300m 미터 높이에서 투신 자살한 사람이라고는 도저히 믿을 수 없을 정도로 양호하고 평온했다.

마침 현장 근처를 지나던 어느 사진학도가 굉음을 듣고 투신 지점으로 달려왔는데.. 이거 보통 모습이 아님을 직감하고 현장 보존 상태에서 사진을 남겼다. 이건 인위로 연출한 장면이 아니며.. 섬뜩하지만 "세상에서 가장 아름다운 자살"이라는 타이틀이 붙었다.

에블린 맥헤일의 투신 모습 보기

비록 겉으로는 저렇게 평온해 보여도 신체 내부는 다발성 골절, 장기부전, 폐출혈 등으로 다 망가졌을 것이다.
아무리 자동차가 충격을 흡수해 주고 공기 저항까지 있었다 하더라도, 기본적으로 수십 kg에 달하는 '인간'이 낙하산도 없이 워낙 높은 곳에서 떨어졌으니..

하물며 그냥 콘크리트 바닥에 떨어졌다면 300미터보다 훨씬 더 낮은 곳에서 투신해도 시신은 절대로 온전히 남아나지 못한다. 피 튀고 뼈 꺾이고 심하면 머리가 깨져서 뇌수가 새어나오기도 한다. 즉사할 정도의 높이에서 떨어졌다면 그 어떤 자세로 떨어지더라도 결국은 머리에까지 어떤 형태로든 충격이 전해지기 때문이다.
아무렇게나 아파트에서 뛰어내리는 사람은 절대로 저런 우아한 자세로 죽지 못하며, 시신 수습하고 청소하는 사람들한테 큰 민폐만 끼친다는 걸 명심해야 할 것이다.

또한, 에블린은 무슨 실연을 비관해서 자살한 게 절대 아니니 오해 없기 바란다. 오히려 멀쩡히 약혼/청혼까지 다 성사된 상태에서 자살했기 때문에 결과적으로는 자기가 반대로 남친에게 큰 충격과 상처를 남긴 꼴이 됐다. 그녀는 몇 개월 안으로 임박한 결혼이 자기 인생을 완전히 얽어매고 속박한다고 생각한 것 같다. 죽기 직전까지는 아무것도 튀는 게 없는 삶을 살았는데 도대체 머릿속으로 무슨 생각을 하고 있었는지 알 수 없는 노릇이다.

이 사건 이후로 엠파이어 스테이트 빌딩의 전망대에는 자살 방지를 위해 쇠로 얽히고 섥힌 난간이 설치되었다.

3-1.
공교롭게도 에블린 맥헤일 이전에도 죽은 모습이 칭송의 대상이 된 여인이 또 더 있었다.
1880년대 말, 프랑스 센(Seine) 강에서 어떤 소녀가 익사한 채로 발견되었다. 그런데 옛날이어서 그녀가 어디에 사는 누구인지 신원이 전혀 밝혀지지 않았다고 함. 외관상의 상처는 전혀 없었기 때문에 실족사가 아니면 자살로밖에 볼 수 없었다.

그런데 죽은 것치고는 얼굴이 아름답고 표정도 굉장히 평온하고 순수하고 행복해 보였던지라 이 시신을 검시한 어떤 사람은 즉시 데스마스크를 만들어 시신의 형상을 남겼다. 예술가들도 감탄했을 정도라고 한다. 저 소녀는 자기가 죽고 나서 몸이 저렇게 칭송받고 데스마스크가 만들어질 걸 과연 예상했을까 싶다.

L'Inconnue de la Seine

3-2.
한편, 에블린 맥헤일은 같은 미국에서 의문의 참혹한 죽음을 당한 엘리자베스 쇼트(Elizabeth Short), 일명 '블랙 달리아'라는 아가씨와 거의 동갑내기이다. 둘 다 1923~1924년생이고, 엘리자베스의 시신이 발견된 때는 1947년 1월 15일로 같은 1947년이다.

저 사람은 본격적인 할리우드 배우 지망생이었다. 시신이 발견되기 약 1주일 전부터 연락이 두절된 실종 상태였는데 이때 어디서 누구에게 무슨 일을 당했는지 알 길이 없다고. 하지만 이 사람이 옷이 다 벗겨지고 전신 피멍에 허리가 두 동강 나고 혈액과 장기 적출로도 모자라 입이 양쪽으로 귀까지 찢어진 정말 끔찍하고 처참한 모습으로 발견되어야만 할 정도로.. 누군가에게 원한을 살 정황은 전혀 없었다. 금전 쪽으로든 치정 쪽으로든. 사람 입이 찢겼다는 얘기는 "나는 공산당이 싫어요" 이 승복 이후로 처음 듣는다.. ㄷㄷㄷㄷㄷ

범행 용의자는 영국의 잭 더 리퍼처럼 신체 해부와 외과 수술에도 식견이 있는 어느 싸이코패스일 거라고밖에 볼 수 없는데 이건 결국 영구미제 사건으로 남았다. 21세기도 아니고 1940년대에 워낙 엽기적인 사건이다 보니, 오히려 자기가 블랙 달리아를 죽인 범인이라고 뜬금없는 거짓 자수를 한 관심병 미친놈들만 몇십 명이나 나와서 수사에 혼선을 끼쳤다고 한다. 고문이나 강압 수사도 없었는데 웬 허위 자백이냐..;;

4.
투신 자살과 관련하여 마지막으로 떠오르는 사례는 일본의 '오카다 유키코'(1967-1986)이다.
검색을 통해 사진과 프로필을 보면.. 예쁘고 공부도 잘하고 다 잘하는 엄친아 연예인 지망생 그 자체. 데뷔 후엔 실제로 인기가 아주 좋아서 1980년대 중반을 풍미한 일본 아이돌계의 떠오르는 샛별 소리를 들었다.

그런데 보아하니 이 아가씨도 너무 완벽주의자였던 것 같다. 그야말로 살인적인 스케줄 강행군을 소화하면서 연예인 활동을 했는데.. 치정 스캔들 때문인지, 악성 루머 때문인지, 소속사와의 불화 때문인지, 자기 자신에게 만족하지 못하고 인생에 회의를 느꼈는지, 아무튼 하나로 딱 떨어지는 원인이나 정황 없이 그녀는 1986년 4월 8일, 별안간 소속사 건물의 창문 밖으로 뛰어내림으로써 생을 마감했다. 아, 당일엔 투신 자살에 앞서 가스를 피워서 자살을 시도하다가 저지당하기도 했다.

오카다 유키코는 배를 땅으로 향하는 자세로 콘크리트 바닥에 쓰러졌다. 그리고 고인에게는 참 안타까운 일이지만 죽은 모습이 미국의 에블린 맥헤일의 경우와는 달리, 저질 옐로우 저널리즘의 먹잇감으로 전락해 버렸다. 일본의 찌라시들은 겨우 고삐리 연예인이 죽은 모습을 바닥에 튄 핏자국까지 그대로 모자이크 처리 하나 없이 사진으로 찍고 내보냈기 때문이다. (겉으로 욕하면서도 결국은 다 사서 보거든 ㄲㄲㄲㄲㄲ)

이런 선정적인 보도 때문인지, 이 아이돌의 자살로 인해 당시 일본 내부에서는 그야말로 수십~수백 명에 달하는 팬들이 같이 자살했다고 하니 더욱 섬뜩하지 않을 수 없다. 한번 유명해지고 나면 자기 혼자 곱게 세상에서 뿅 없어지는 것조차도 자기 마음대로 안 된다. 그러니 정말 입과 몸을 사리면서 행동해야 할 것 같다. 자살 이것도 정말 어지간한 멘탈로 가능한 게 아닐 텐데..! ㅠㅠ

* 아 진짜 마지막으로 하나만 더..
별도의 번호까지 또 할당해서 소개하기는 좀 뭣하다만.. 2011년에 우리나라에서는 어떤 40대 여성이 25층에서 투신 자살했는데 하필..;; 맨홀 뚜껑을 정확하게 강타하고 그 구멍 아래로 떨어져 숨지기도 했다. 다른 인명이나 차량 피해가 없는 것은 다행스러운 점이다만, 이건 뭐 멀쩡히 길거리를 가던 행인이 땅이 쑥 꺼지고 맨홀로 빠진 것만큼이나 황당한 소식이다.

Posted by 사무엘