본인은 박사 과정에 진학해서 수업을 다 듣고 종합 시험도 통과한 뒤, 지난 2년이 넘는 기간 동안 휴학을 했다. 그리고 그 기간 동안 날개셋 한글 입력기는 8.6에서 9.7까지 올라갔다.
입력기 연구의 연장선에다가 글꼴 연구도 새로 접목하는 것을 목표로 진학했었는데, 입력기 연구가 당초 계획보다 다소 오래 걸렸다.

이제 입력기는 파일 포맷과 엔진 구조를 다 뜯어고칠 정도로 너무 비현실적인 추상화(재설계나 리팩터링), 아니면 너무 이상적인 수준의 기능을 제외하고 어지간히 규칙 기반 한글 입력과 관련된 것들은 다 통달했으며 잘 실현됐다. 9.7도 특별히 심각한 문제 없이 아주 잘 만들어졌다.

다만, 날개셋은 TSF 기반의 한글 IME일 뿐만 아니라 반대로 타 IME들을 구동해 주는 텍스트 에디터이기도 하니.. 요즘은 편집기에서 타 IME를 구동하는 동작과 관련된 이슈들을 좀 살펴보고 있다.

1. 내 프로그램에서 9.7 이후로 개선된 사항

(1) 외부 모듈의 옛한글 조합을 여느 블록(selection)과 달리 취급

날개셋 편집기에서 입력 항목을 '빈 입력 스키마'로 고르면 앞서 언급한 바와 같이 자체 입력기가 아니라 다른 외부 IME들을 사용할 수 있다.
그런데 한글 IME로 현대 한글을 조합할 때는 깜빡이는 네모 cursor가 나타나는 반면, 옛한글을 조합할 때는 조합이 그냥 블록 형태로 잡힌다. 그래서 자체 입력기로 옛한글을 입력할 때와는 달리 이질적이고 아마추어스러운 느낌이 난다.

이건 일차적으로는 운영체제에서 옛한글처럼 내부적으로 2개 이상의 코드값으로 표시되는 한글에 대한 배려를 안 해서 그렇다. 조합 문자열이 한글로만 이뤄져 있을 때 응용 프로그램이 강제로 보정을 해서 깜빡이는 네모 cursor를 구현하라면 할 수도 있다.

내 프로그램에서는 그렇게까지는 안 하는 대신, 비록 블록처럼 보이더라도 진짜 블록이 잡힌 것처럼 복사/잘라내기 버튼이 켜지지도 않게 프로그램의 동작을 깨알같이 개선했다. 그건 블록이 아니라 조합을 표시하는 용도일 뿐이기 때문이다..

사용자 삽입 이미지

(2) 붙여넣기를 할 때 외부 모듈의 조합이 덧나지 않게

또한, 자체 입력기가 아닌 외부 IME로 한글을 조합하고 있던 중에 도구모음줄의 '붙여넣기' 버튼을 마우스로 누르면..
자체 입력기를 사용할 때와 마찬가지로 조합이 종료된 뒤에 클립보드 내용이 삽입되는게 정상이다.

하지만 지금까지는 그렇지 않았다. 조합이 중단되고 그 문자열이 사라지고서 클립보드 내용이 삽입되었다. 이 버그를 발견하여 고쳤다.

사용자 삽입 이미지

이 두 가지 사항은 언제쯤 다음 버전에 반영되어 나올지 모르겠다.

2. 내 프로그램과 무관한 운영체제의 버그

(1) IME 도구모음줄이 두 종류 모두 표시됨

Windows 10 1803 버전 기준으로..
IME의 구형 재래식 도구모음줄과 Windows 8 스타일의 간소화 도구모음줄이 다같이 동시에 뜨는 경우가 있다. 정확한 재연 조건은 잘 모르겠지만 컴퓨터를 절전 상태로 껐다가 다시 켰을 때 가끔, 그러나 확실하게 이런 현상이 발생한다.

사용자 삽입 이미지

"고급 키보드 설정"에서 "사용 가능한 경우 바탕 화면 입력 도구 모음 사용" 옵션을 건드려 주면 다시 둘 중 하나만 나타나게 개선되긴 한다. 하지만 이건 운영체제의 버그이니 나중에 업데이트를 통해 해결되어야 할 것이다. Windows 8은 물론이고 10도 초창기에는 이런 현상이 발생한 적이 없었다.

(2) 일본어 IME의 조합 관리 버그

날개셋 편집기 또는 IE/Edge 브라우저의 텍스트 입력 폼에서 Microsoft 일본어 IME를 구동하고, 히라가나 모드에서 일본어를 몇 자 입력한다.
space를 눌러서 그 일본어 문자를 변환은 하지 말고, 좌우 화살표 키를 눌러서 조합 영역을 빠져나간다. 그러면 조합을 나타내는 밑줄이 일시적으로 사라진다.

그 뒤에 caret이 기존 조합 영역으로 돌아오면 기존 조합이 다시 생겨야 되는데 그리 되지 않는다.
그 상태에서 다른 곳에서 Shift+화살표를 눌러서 블록을 만들어 보면 아까 조합하던 일본어 문자가 덧나서 잘못 삽입된다.

사용자 삽입 이미지

이 버그는 Windows 10의 16xx대 이전 버전에서는 발생하지 않다가 후대 버전에서 나타났다. 1803의 후대 버전에서는 어찌 되었나 모르겠다. 날개셋 편집기뿐만 아니라 MS에서 만든 TSF A급 웹브라우저에서 모두 동일하게 발생하니 내 프로그램만의 문제도 아니다.

단, 워드패드에서는 동일 운영체제와 동일 IME에서 저런 오동작이 발생하지 않는다. 서식을 지원하기도 하니 에디팅 엔진 차원에서 무슨 차이가 있어서 그런 것 같다.

(3) 옛한글 IME의 조합 영역 처리 버그

이건 Windows 8 이래로 계속 동일한 것 같은데..
마소에서 제공하는 옛한글 입력기는 초성이나 중성에 옛한글이 들어간 상태에서 종성의 첫 타를 입력하면.. caret 위치가 좀 이상하게 찍힌다. 내부적으로 표현되는 글자 수가 3자가 되었으니 0~3까지 모두 조합 영역으로 설정해야 하는데 종성이 입력되기 전처럼 0~2까지만 설정한다.
그래서 날개셋 편집기에서는 화면이 일시적으로 이렇게 표시된다. 종성 둘째 타 이후부터는 다시 괜찮아진다.

사용자 삽입 이미지

시각적으로 좀 이상한 것 말고 다른 오동작은 없다. 하지만 날개셋, 한컴 입력기 등 옛한글 입력을 지원하는 다른 모든  IME에는 이런 현상이 없고 MS IME만 저러니.. 이건 저 프로그램만이 단독으로 해결해야 할 문제로 보인다.

3. 단순 차이점 -- 옛한글 filler 글쇠

두벌식 옛한글 글자판에는 중성이 빠진 미완성 한글 내지 종성 단독 낱자를 입력하기 위해서 일명 filler라는 글쇠가 있다. 위치는 관례적으로 Shift+J로, 날개셋, 아래아한글, MS 옛한글 입력기가 모두 동일하다.

날개셋과 아래아한글에서는 이 filler라는 게 언제나 '중성 filler'를 의미한다. 이것만 있어도 초성이나 종성이 없는 글자는 입력 가능하기 때문이다.
하지만 MS의 경우, filler도 뭔가 두벌식스럽게 글자를 완전 처음 입력할 때는 빈 자리에다가 '초성 filler'를 흉내 내어 주는 것 같다. 굳이 그럴 필요가 없지만 말이다.

그래서 초기 상태에서 종성을 단독으로 입력하려면 filler를 한 번이 아닌 두 번 눌러야 한다. 본인은 처음엔 이런 차이를 몰라서 마소 옛한글 입력기로는 종성 단독 입력이 불가능한 줄 알았다.
초성 filler도 지원해 주는 게 사람에 따라서는 더 직관적으로 보일 수도 있다. 하지만 한글을 연속으로 입력하기 시작하면 filler는 어차피 사실상 중성으로만 동작해야 하기 때문에 굳이 저럴 예외를 둘 필요가 있나 싶다.

중요한 건 이런 동작조차도 표준으로 딱 정해진 게 없어서 프로그램마다 차이가 있을 수 있다는 점이다. 날개셋에서는 글쇠배열의 수식을 바꿔 주면 지금 동작(중성 고정)뿐만 아니라 MS IME의 동작도 물론 구현할 수 있다.

4. 원인을 알 수 없는 문제

다음은 본인의 개발 환경에서 아주 드물게 발생하는 것을 확인하긴 했지만 재연 조건을 전혀 몰라서 좀 난감한 지경에 있는 버그 아이템들이다. 이것들이 문제의 원인이 전적으로 내 프로그램의 귀책사유로 판명되어 해결된다면.. 위의 1번의 개선 사항까지 포함해서 다음 버전인 9.71이 지금이라도 당장 나오게 된다.

(1) 여전히 발생하는 랙

이번 9.7에서는 안 그래도 편집기의 에디팅 엔진과 관련된 몇몇 버그들이 잡히고 내부 동작 방식이 최적화 됐다. 그런데 편집기를 한번 띄워 놓고 며칠 이상 오래--특히 중간에 컴의 절전 모드와 복귀를 수차례 반복할 정도로-- 쓰다 보면, 어느 샌가 글자가 화면에 나타나는 속도가 내 타자 속도를 못 따라갈 정도로 랙이 걸리는 경우가 여전히 발생한다.

게다가 이게 참 악랄한 게.. 랙의 발생하던 당시에 발생 조건이 다음과 같이 가변적이었다는 것이다.

  • 오로지 날개셋 외부 모듈로 한글을 입력할 때만 느려짐 (MS IME, 자체 입력기 등등은 괜찮음)
  • 외부 모듈로 한글을 입력할 때만 느려짐 (날개셋, MS IME에서 랙. 자체 입력기는 괜찮음)
  • 아무 방식으로나 글자를 입력할 때 몽땅 느려짐

마지막으로 이 문제가 발생했을 때엔.. 처음엔 외부 모듈에서만 발생하는 것 같더니 이내 상황이 최악으로 바뀌었다.
특정 문서의 맨 마지막 줄에서 글자를 입력할 때만 극심한 랙이 걸리고, 그렇지 않을 때는 괜찮았다(타 문서 or 다른 줄). 심지어 그 문서에서 편집하고 있던 텍스트를 몽땅 지우고 새로 입력을 시작해도 랙이 사라지지 않았다.

이 랙이 발생하는 동안 내 프로그램의 내부에서는 무슨 일이 벌어지고 있고 도대체 어느 계층에서 뺑뺑이를 도는 건지 도무지 알 길이 없다. 그냥 평범하게 프로그램을 띄워서는 절대로 발생하지 않는다. 그나마 유력한 단서가 될 만한 현상은.. 이때 날개셋 편집기가 다음과 같이 memory leak이 발생해 있었다는 것이다.

(2) MS IME를 사용할 때 발생하는 괴이한 memory leak

날개셋 편집기와 작업 관리자를 같이 실행한다. 다음으로, 편집기에서 TSF 지원 옵션을 켠 상태에서 '빈 입력 스키마'를 고른다.
Microsoft 기본 한글 IME로, "세벌식 390/최종"(두벌식 말고)으로 "ㅇ.ㅇ.ㅇ.ㅇ." 처럼.. 한글 + 비한글 문자를 수십 회 쭈룩쭈룩 교대로 입력해 보라.

그러면 초기에 2~3MB대 안팎이던 프로세스 메모리 사용량이 계속해서 증가하는 게 관찰된다. 명백하게 memory leak이다.
COM 오브젝트 간의 reference count 같은 게 꼬인 것 같은데.. 이건 도대체 누구 잘못이라고 봐야 할까?

당연히, 디버그 빌드에서 단순 memory leak detector로는 문제가 전혀 감지되지 않는다. 내 프로그램은 10수 년에 달하는 짬밥을 자랑하며 얼마나 오랫동안 안정화가 돼 왔는데.. 소스 코드 상으로 무식한 결함이 있지는 않다.

더구나 날개셋, 한컴 입력기 등 "타 IME에서는 이런 현상이 없다." MS IME도 세벌식을 쓰고 있을 때만 저렇고 두벌식일 때는 문제 없다.
그리고 Windows Vista, 7, 10에서 이 현상을 확인했다. 구닥다리 XP에서는 MS IME+세벌식에서도 문제가 없다.

그럼 내 과실 0, 마소 과실 100을 입증하려면 날개셋 편집기 말고 다른 프로그램에서도 MS IME + 세벌식으로 저렇게 쳤을 때 동일한 memory leak이 발생한다는 걸 입증해야 하는데 그건 또 그렇지 않아 보인다~! 워드패드, MS Word, IE, Edge 등 TSF를 지원하는 프로그램들은 또 희한하게도 저런 현상이 발생하지 않는다.

다음으로 지푸라기를 잡는 심정으로 날개셋 구버전까지도 구해서 써 봤다.
날개셋 8.0까지는 이 문제가 없고, 8.4부터 leak이 발생하더라. 8.2는 불명.. 그러니 이 버그는 대략 2016년부터 있어 왔다는 것이다.
이때 도대체 어떤 변화가 있었는지.. 본인은 프로그램 소스를 자주 백업하는 편이지만, 컴퓨터가 바뀌는 과정에서 지금으로부터 3년이 넘게 너무 오래된 소스는 갖고 있지 않아서 이 방법으로도 문제의 원인을 파악할 수 없었다. ㅠㅠ

난 Windows용 IME라는 물건을 개발하느라 지난 10여 년 동안 온갖 희한한 버그 신고들을 받고 기상천외한 지저분한 환경에서 디버깅을 했다. 그러면서 마치 교통사고 과실 비율 따지는 것 같은 현상들을 많이 경험했었다.
둘 다 스펙대로 100% 무결하게 구현된 건 아니었고(혹은 스펙 자체가 모호해서..) 둘 다 조금만 조심하면 됐는데 둘 다 무데뽀로 동작해서 운 나쁘게 문제가 발생하는 것.. 말이다. Windows용 IME라는 바닥은 무척 "구리다."

아무튼 현재로서는 저 memory leak의 원인과 해결 방법이 오리무중이다. 해결만 된다면 9.7 다음으로 9.71이 당장 나와야 할 것이다.

(3) 제어판 닫았을 때 프로그램 뻗나?

정말 민망하고 황당한 버그인데.. 올해 들어 두세 번인가 겪었다.
날개셋 편집기에서 제어판을 꺼내서 설정을 바꾼 뒤, 확인을 눌러서 닫았더니 편집기 프로그램이 그냥 대짜로 뻗어 버렸다.
한 번 발생했을 때는 그냥 재수없는 우연인가 싶었는데, 몇 주 전에 마지막으로 동일 문제를 겪었을 때는 '미저장 확인'을 누른 것만으로도 뻗었다.

물론 그 뒤로는 편집기에서 날개셋 외부 모듈을 또 얹고, 제어판에서 온갖 설정을 바꾸고 빠른설정을 띄우면서 지지고 볶아 봐도.. 동일 문제가 다시는 재발하지 않고 있다. 위의 랙도 몹시 드물게 발생하지만 이 crash는 그것보다 더 드물게 발생했다. 그래서 난감하다.

Posted by 사무엘

2019/03/31 08:30 2019/03/31 08:30
, , ,
Response
No Trackback , 6 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1603

우리나라에는 자동차 기반의 장거리 대중 교통수단으로 고속버스와 시외버스라는 이원화된 시스템이 존재한다.
사실, 법적으로는 이들은 일반형 시외버스, 직행형 시외버스, 고속형 시외버스라는 세 부류로 나뉘는데, 고속형 시외버스가 고속버스라고 여러 모로 특별 취급을 받는 구도이다. 그리고 나머지 시외버스들도 시대의 흐름에 따라 갈수록 직행화하고 고속버스와 형태가 비슷해지고 있다.

본인은 옛날 대학 시절에 경주에서 울진으로 가는 시외버스를 이용한 적이 있었다. 고속도로가 없이 국도만 타느라 울진까지 가는 데 4시간이 넘게 걸렸던 걸로 본인은 기억한다. 더구나 이런 지방 왕래 수요가 많을 리가 없으니, 버스도 무슨 완행 열차가 정차하듯이 온갖 시골 정류장들을 들쑤시고 다녔다. 그래야 수지가 맞을 것이다.

지방에서 시외버스는 원래 이런 식으로 운행되고 있다. 울진 같은 경북의 오지뿐만 아니라 당장 강원도의 전방에서 차가 없는 사람들의 이동을 책임지는 것도 시외버스가 유일하다. 화천· 양구 같은 곳에 철도가 있나, 공항이 있나? 동서울 터미널에 괜히 군인들이 우글거리는 게 아니다.

다만, 요즘은 집집마다 승용차를 굴리는 세상이며, 중소 규모 이상의 도시에는 철도 같은 대체제도 있다. 전국에 고속도로도 워낙 촘촘하게 많이 건설되고 있지 않은가?
그러니 버스도 경쟁력을 갖추기 위해서는 촘촘한 단거리 이동보다는 장거리를 어설픈 중간 경유 없이 승용차보다 더 빠르고 편하게 가는 것에 집중하게 되었다. 일반형 완행 시외버스는 저런 시골 지방 말고는 없어지는 추세이다. 철도로 치면 간이역들이 갈수록 없어지는 것과 비슷한 이치이다.

고속버스는 시외버스의 고급 특화 케이스이기 때문에 시외버스보다 노선이 훨씬 적다. 그 덕분인지 승차권 발매· 예매를 위한 단일 통합 전산망도 2000년대 초부터 시외버스보다 훨씬 더 잘 갖춰져 있었다. 과거 1980년대에 철도 승차권 전산 발매도 새마을호에 제일 먼저 적용되었던 것처럼 말이다.

현행법에 따르면 길이가 100km 이상이고, 전체 구간의 60% 이상을 고속도로로 달리는 노선에만 고속버스가 투입될 수 있다. 고속도로는 그 정의상 최대 속도가 100km/h 이상으로 정해진 곳이니 고속버스의 정의에는 속도와 거리에 모두 100이라는 숫자가 존재하는 셈이다.

경주-대구 사이에는 고속버스와 시외버스 노선이 모두 존재해서 서로 경쟁 중이다. 저기는 80km가 안 되는 짧은 거리이지만, 100km 이상 규정이 생기기 전부터 있었기 때문에 고속버스 노선이 여전히 존재하는 중이다. 마치 이화여대 초등교육과가 전국에서 유일하게 초등학교 교사를 양성하는 사립 기관이듯이 말이다. (국립 교육대들보다 먼저 존재했음)
뭐, 신경주 역에서 KTX를 타면 동대구 역까지 20분이 채 걸리지 않지만.. 운임과 역 접근성 때문에 버스도 여전히 경쟁력이 있다. (역이 시내에서 너무 멀므로..)

그리고 고속버스는 태생적으로 중간 정차가 거의 허용되지 않는다. 시점과 종점만 있는 시외버스라는 게 원래는 고속버스의 전유물이었다. 고속버스는 고속도로 휴게소에 두세 시간 간격으로 정차하고, 아니면 시점 또는 종점과 동일한 지역에 소재한 정류장에 딱 한 번만 추가 정차할 수 있다.

대표적인 예는 대구-서울 고속버스이다. 상행은 동대구 역 근처에 있는 터미널을 출발한 뒤에 서대구 정류장을 들렀다가 서울로 가며, 하행은 반대로 서대구 정류장을 들렀다가 터미널로 간다. 대구 시내 안에서 터미널과 정류장 사이만 왕복하는 용도로는 고속버스를 이용할 수 없다.

즉, 쟤들은 터미널을 출발하자마자 곧장 고속도로로 진입하지 않는다. 굳이 대구 시내를 횡단해서 서대구 정류장을 경유하느라 고속버스의 표정속도가 하락하는 건 개인적으로 아쉽게 느끼는 점이다.
이 정도만이 고속버스에게 허용된다. 이런 고속버스와는 달리, 동서울을 출발한 직행 시외버스는 경주에서 승객을 하차시킨 뒤 포항까지도 간다.

다음으로 운임의 측면에서 살펴보면, 고속버스는 시외버스보다 고급스럽고 사치스러운(?) 교통수단으로 간주되어 운임에다 부가가치세가 붙는다. 즉, 원가 대비 차삯이 더 비싸다. 하지만 겨우 고속버스가 사치품인 것은 무슨 1970년대에 경부 고속도로라는 게 처음 생겼고 버스 안에 안내양까지 탑승하던 시절의 사고방식에 지나지 않는다. 법리적으로 볼 때 부가세를 폐지하는 것이 옳다는 지적이 있어 왔다.

고속버스에는 1991년인가 92년부터 우등이라는 등급이 생겨서 좌석 수가 더 적고 넓고 큼직한 대신, 더 비싼 버스가 등장했다. 열차는 상위 등급이 정차역 수가 적고 더 빨리 가는 반면, 고속버스는 처음부터 중간 무정차를 표방했기 때문에 우등이라고 해서 더 빠른 건 아니다. 그 대신 버스는 그 구조상 한 차량 안에서 특실/일등석(!) 같은 구분은 없다.

새마을호에 종아리 받침대가 달린 한국 철도 역사상 최고급 좌석이 등장한 것도 비슷하게 1990년대 초인 것으로 본인은 기억하는데.. 우등 고속을 의식한 것인지, 아니면 반대로 우등 고속이 더 나중인지는 정확한 시기와 역학관계를 잘 모르겠다. 승차감과 좌석 앞뒤 간격은 철도인 새마을호가 더 낫고(특히 특실은!), 좌석과 팔걸이의 폭은 아예 2-1 배열인 우등 고속이 더 컸던 것으로 본인은 기억한다.

직행형 시외버스에도 우등형 좌석 차량이 있다. 단, 얘들은 앞뒤 간격이 우등 고속보다 약간 더 좁아서 28인승이 아닌 33인승이다.

고속버스 업계에서는 우등 고속이 생긴 지 25년 가까이 지난 2017년부터 우등보다도 더 고급스러운 21인승 프리미엄 우등이라는 것도 등장했다. 하지만 이건 서울-부산 같은 소수 장거리 노선 말고는 막 보급되기 어려울 듯하다. 우리나라가 무슨 1000km짜리 노선이 있는 것도 아닌데.. 속도의 향상 없이 내장재만 잔뜩 고급화해서 비싼 운임을 받는 건 타 교통수단 대비 경쟁력을 확보하기 곤란하다. 다만, 좌석에 콘센트나 폰 충전 단자가 있는 버스라면 개인적으로 귀가 약간 솔깃해지긴 한다!

지금이야 시대가 어느 시대인데 시외버스도 고속버스 못지않은 승차권 전산 발매 인프라를 갖췄고, 심지어 시내/광역버스처럼 교통카드 결제가 가능해지기도 했다. 줄 서서 창구에서 표 사는 번거로움을 덜기 위해 맨 처음에는 무인 예매 발권기라는 게 생겼고 2000년대 초반에는 홈티켓이 유행했는데, 이제는 그냥 모바일 승차권을 써도 된다.
그리고 고속버스도 무조건 한 차량으로 시점-종점만 고집하는 게 아니라, 휴게소 환승이라는 것도 이미 10여 년 전에 생겼다.

그 전에 옛날에는 고속버스의 승차권 전산 발매 시스템이 통합돼 있지 않아서 일부 지역은 kobus, 일부 지역은 이지티켓(easyticket)으로 별도의 사이트를 이용해야 했다. 그 시절에 동영상 코덱들이 난립하고 휴대전화 충전 단자들이 통일돼 있지 않았던 것처럼 말이다.

또한 대구는 대도시에 걸맞지 않게 고속버스 터미널이 회사별로 찢어져 있던 것으로 악명 높았다. 동부/서부 이렇게 정말 지리적으로 서로 멀리 떨어진 게 아니라, 똑같이 동대구이고 그냥 한 블록 간격인데 회사가 관할하는 행선지별로 터미널이 찢어진 것이다. 더구나 이게 전산 시스템에도 반영돼서 '대구 한진', '대구 동양' 같은 식으로 찢어졌으니 병크가 따로 없었다.

그러다가 대구에 드디어 동대구 역과 연계되고 기존 동부 시외버스 정류장과 백화점까지 통합한 동대구 통합 고속버스 터미널이 완공됐으니.. 참 오래 살고 볼 일이다. 진작에 그렇게 됐어야 했다.
이 추세라면 시외버스와 고속버스라는 두 체계는 궁극적으로 하나로 통합해도 되지 않나 싶다. 육군이 서부와 동부 전선 야전군(제1, 제3)을 통합해서 그냥 전방 담당 사령부를 만든 것처럼 말이다.

이제는 고속도로를 달리는 게 별다른 특권이 아니며 직행 시외버스와 고속형 시외버스의 경계가 굉장히 모호해졌기 때문이다. 고속버스만 타 시외버스와 다르게 취급할 이유가 별로 없다. 단일 시외버스 체계에서 시골 지방을 위한 완행 아니면 직행 구분만 하면 될 것 같다. 차량과 전산망 말고 터미널 건물은 요즘 모든 지역들이 고속과 시외 구분 없이 통합해서 만드는 게 대세가 된 지 오래다.

한반도에 철도와 시내버스까지는 일제 시대에도 있었던 교통수단이다. 그러나 고속철은 말할 것도 없고 그 전에 고속도로와 고속버스라는 것은 그 시절을 넘어 할배 슬하의 1공화국 시절에도 없었다. 1970년대 박통 때에 와서야 등장했다.
사실, 일제 시대 경성 시내 사진을 봐도 길거리에 자동차와 노면전차까지는 다니지만, 길에 차선이 그어지고 신호등이 설치된 걸 본 적은 없을 것이다. 미국 LA는 1940년대 모습이 이미 우리나라의 1970년대 이상 같고 자동차의 모양만이 옛날 디자인 같은데.. 참 대조적이다.

그렇게 길거리에 교통 시설이 아무것도 없다시피했기 때문에 미군정은 1946년에 자기 재량으로 한반도에서 자동차의 통행 방향을 좌측에서 우측으로 곧장 변경할 수 있었다. 자동차가 극히 드물던 시절, 고속버스를 타는 것만으로도 지금으로 치면 비행기를 타는 것 같은 희소한 경험이던 시절에 사람들의 삶이 어떠했을지가 궁금하다.

또한 저것보다는 비교적 가까운 과거에 운전석 옆에 안내양이 앉는 작은 의자가 있던 시절, 그리고 우등 고속의 오른쪽 맨 앞자리(3번)에 냉장고와 이동식 공중전화가 비치되어 있던 시절, 현대도 대우도 아닌 아시아 자동차 버스가 있던 시절도 개인적으로 문득 그리워진다.

Posted by 사무엘

2019/03/28 19:33 2019/03/28 19:33
, , , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1602

스텐실 폰트

* 굉장히 오랜만에 폰트 분야에 글을 하나 추가하게 됐다.

지금은 실생활에서 좀 보기가 힘들다만.. 30대 이상의 나이가 좀 있으신 분들 중에는 요런 투박한 모양의 글자 내지 숫자를 각종 표지판이나 벽면, 차량의 외부에서 본 적이 있을 것이다. 양각· 음각 형태로 새겨지거나 오려 붙여진 게 아니라, 물감· 페인트로 칠해진 형태로 말이다.

사용자 삽입 이미지

이 글꼴의 컨셉은 글자가 가독성을 해치지 않는 한도 내에서 획의 일부가 규칙적으로 끊어지고 단절돼 있다는 것이다. 특히 O 대신 ()이고, ㅁ 대신 [] 모양이다.

미술· 디자인 쪽으로 조예가 있는 분이라면 이미 다 눈치 채고 아시겠지만, 이건 '스텐실'이라고 불리는 인쇄 내지 칠하기 기법에 맞춰진 글꼴이다.
투명한 필름지 같은 것에다가 도안을 그려서 선이나 면을 잘라내고, 그걸 종이 위에다 올린다. 그 뒤 필름에다가 칠을 하면 필름이 없어서 종이가 노출된 영역에만 색이 칠해진다. 이 필름지를 이용하면 동일한 그림도 여러 번 쉽게 찍어낼 수 있다.

판화와는 접근 방식이 다르다. 판화는 개념적으로 도장과 비슷하며, 찍는 과정에서 좌우가 바뀐다. 하지만 스텐실은 칠하는 방식이 다르니 그런 mirroring이 발생하지 않는다. 판화와 달리 칠을 더 다채롭고 다이나믹하게 할 수 있다.
그러나 스텐실은 판화에는 해당사항이 없는 한계도 존재하는데, 내부의 구멍을 구조적으로 표현할 수 없다. 그렇기 때문에 내부의 구멍이 존재하는 글자는 부득이하게 획의 일부를 끊어서 구멍 내부도 외부와 연결되게 해야 한다.

기왕 획의 일부를 끊었으니 이걸 일관된 개성과 컨셉으로 삼아서 스텐실용 글꼴을 만들어 보자는 발상은 서체 디자이너들이 누구나 할 수 있었던 생각이다.
저 영문 Stencil 글꼴에서 보듯, 획 굵기의 기복이 있는 세리프 계열 글꼴이 단절감이 덜하고 좀 더 어울린다. 어차피 획이 최대한 가늘어지는 곳에다가 단절을 시키면 되기 때문이다.

하지만 산세리프 계열에도 스텐실 글꼴이 얼마든지 존재한다.

사용자 삽입 이미지사용자 삽입 이미지

디지털 글꼴이 없던 옛날에 이런 글자들은 스텐실 기법으로 만들어지고 복제된 도안들이라고 생각하면 된다.

사용자 삽입 이미지

버스의 경우, 동일한 노선을 달리는 버스가 수십 대 이상 있었을 테니 이렇게 행선지를 인쇄하는 게 합리적이었을 것이다.

사용자 삽입 이미지사용자 삽입 이미지

옛날에 군부대 근처에 있던 "접근금지", "위험" 표지판도 다 이런 식이었던 것 같다.
지금이야 옛날 같은 투박함과 엉성함은 사라지고 스텐실 컨셉을 일부러 흉내 낸 깔끔한 글꼴을 골라 쓰는 시대가 됐지만 말이다.

일반적인 책과 문서에서는 Times 같은 평범한 본문용 서체를 쓰는 반면,

  • 타자기나 코딩용으로는 딱딱한 불변폭 서체를 쓰고,
  • 기계가 인식하기 편하라고 타자기와 비슷하면서 획을 간소화시킨 그 특유의 OCR용 서체도 만들고,
  • 멋을 내기 위해서는 기울이고 날리고 최대한 한붓그리기를 추구한 필기용 서체를 쓰고,
  • 열악한 디지털 기계에서는 8픽셀도 채 안 되는 높이 내지 7-segment 같은 극도로 단순한 형태로 문자 외형을 간소화도 하고,
  • 스텐실용으로는 이렇게 구멍이 없는 서체를 쓰는 등..
문자를 용도에 따라 다채롭게 활용 가능하게 하는 것이 타이포그래피의 묘미임이 틀림없다.

그나저나 오늘날 같은 디지털 인쇄와 복사 기술이 발달하기 전에 등사처럼 아날로그 판화· 인쇄술이 어떠했는지에 대한 의문과 관심이 문득 생긴다.

Posted by 사무엘

2019/03/26 08:36 2019/03/26 08:36
, , , , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1601

1. 32비트 컴파일러: 16비트 메모리 접근의 한계를 극복하기

예전에도 언급한 적이 있지만.. 1993년 말에 발매되었던 Doom 게임은 그야말로 충격적인 3차원 그래픽 덕분에 게임 업계에 큰 충격을 선사했다. 업계 종사자들은 기술 수준 자체뿐만 아니라 "얘는 어셈블리어를 거의 사용하지 않고 순수 C만으로 개발되었습니다"라는 존 카맥의 말에 더 큰 충격을 받게 됐다.

훗날(1997년) Doom의 소스 코드가 공개되면서 이 말은 사실임이 밝혀졌다.
Doom은 무슨 16비트 Windows 같은 쑤제 어셈블리어 튜닝 위주로 개발된 게 아니라, Windows NT처럼 굉장히 이식성 있게 개발되었다. 그러니 Doom 엔진 기반의 수많은 게임과 mod들이 온갖 플랫폼으로 이식되어 만들어질 수 있었다.

단지, 오리지널 도스용의 경우, 컴파일러를 그 당시에 흔하던 볼랜드나 MS 같은 16비트용을 쓴 게 아니라 Watcom이라는 다소 생소한 32비트 고성능 제품을 썼을 뿐이다.
그리고 어셈블리어를 안 쓰더라도 고정소수점이라든가, IEEE754의 특성을 이용해서 3차원 그래픽용 실수 연산(삼각함수, 제곱근, 벡터 정규화...)을 왕창 빠르게 수행하는 각종 tweak들은 응당 최대한 구사해서 성능을 끌어올렸다.

그러니 Doom은 아직 상대적으로 생소하던 32비트 컴파일러라든가 DOS/4G 도스 익스텐더 같은 물건의 인지도를 끌어올려 줬다. 이렇게 Doom을 통해 Watcom 컴파일러까지 알렸던 id 소프트웨어에서는 훗날 퀘이크를 만들어서 이번에는 오픈소스 진영의 걸출한 도스용 32비트 컴파일러이던 djgpp를 알리게 되었다.

운영체제 자체를 OS/2나 Windows NT처럼 통째로 32비트로 쓰기에는 아직 기계값이 너무 비싸고 특히 메모리가 부족했다. 그러니 도스에서 돌아가는 일부 대형/고사양 프로그램이 자체적으로 도스의 한계를 극복하고 보호 모드로 진입하는 솔루션을 내장했던 것이다.

생각해 보니 국내에서도 아래아한글 2.1이 전문용은 Watcom C/C++을 이용한 32비트 전용으로 만들어졌다. 얘는 발매 시기가 심지어 Doom보다도 3개월 남짓 더 앞섰다(1993년 9월 vs 12월). 그러니, 터보 C, 볼랜드 C++ 하던 그 시절에도 32비트 컴파일러에 대해서 알 사람은 이미 다 알기는 했던 모양이다.

다만, 아직도 286 똥컴이 많이 굴러다니고 서민용 운영체제들은 아직도 16비트 도스와 Windows가 주류인데, 내 프로그램을 386 전용으로 개발하는 것에 대한 득과 실을 신중하게 따져야 했다. 오죽했으면 아래아한글도 후속 버전인 2.5와 3.0에서는 일반용/전문용 구분이 없어지고 그냥 hwp86.exe와 hwp386.exe 두 에디션을 모두 내장하는 것으로 형태가 바뀌었다. 추가 글꼴과 사전 컨텐츠는 '확장팩'으로 분리되고 말이다.

아래아한글은 Phar Lap 도스 익스텐더를 사용했다. 아래아한글이 그 시절의 도스용 게임처럼 DOS/4G(W) 로고를 띄우면서 실행되었다면 무척 볼 만했을 것이다.
86과 386 에디션은 성능 말고는 덧실행 프로그램이 지원되는지의 여부가 가장 큰 차이점이었다. 덧실행은 16/32비트용이 따로 나오지 않고 32비트 전용이었기 때문이다.

화면 보호기들, 그리고 확장팩에서 제공되었던 프라임 영한사전도 다 덧실행 프로그램이었다.
먼 옛날 1.2 시절에는 별도의 액세서리로 테트리스 게임이 있었는데 나중에 그게 덧실행으로 컴백한 걸 보니 개인적으로 감회가 새로웠었다.

이렇게 1990년 중반에 도스용 프로그램들의 32비트화 추세와 달리, 마소는 진작부터 PC에서 도스를 Windows로 대체하려는 큰 그림을 갖고 있어서 그런지.. 도스용으로 32비트 컴파일러를 결코 내놓지 않았다. 정작 자기들은 그 기술을 내부적으로 보유하고 사용했으면서 말이다.
Visual C++ 1.5x는 16비트 도스/Windows 바이너리들을 빌드할 수 있었는데, 명령 프롬프트에서 돌아가는 컴파일러와 링커 같은 툴들은 그냥 32비트 프로그램이 아니라 32비트 PE 기반의 콘솔 프로그램이었다.

Windows NT 같은 데서는 직통으로 실행 가능하고, 도스에서 실행되면 stub으로 embed된 도스 익스텐더가 컴을 보호 모드로 진입시키고 CreateFile/GlobalAlloc 같은 Win32 API를 제공해서 프로그램을 실행했다.
스레드를 만들지는 못했겠지만 컴파일러· 링커가 사용하는 Win32 API야 뭐 파일이나 메모리 I/O 정도밖에 없었을 것이고, 이건 도스 익스텐더가 감당 가능했다. 결국 한 바이너리만으로 도스와 Windows에서 모두 사용 가능.

이건 뭐 콘솔 프로그램계의 Win32s나 마찬가지인 엄청난 기술인데.. 마소의 Visual C++에서 이런 이중 바이너리를 만드는 걸 end-user에게 지원한 적은 내가 알기로 없다.
마치 C# 네이티브 코드 컴파일러만큼이나 대외적으로 공개되지 않고 마소 내부에 봉인된 기술인 것 같다.

2. 슈퍼 VGA 라이브러리: 표준 VGA의 한계를 극복하기

IBM 호환 PC라고 불리는 물건에서 IBM이 주도하는 PC의 단일/표준 규격이라는 건 286 AT 이후로 없어졌다. 그러니 286 이후로 최초의 386 PC는 IBM이 아닌 컴팩에서 출시되기까지 했다.
그리고 그래픽 카드도 절대불변 단일 표준은 1987년의 구닥다리 VGA가 마지막이다. 표준 VGA는 800*600 해상도조차 지원하지 않았으며, 그나마 색깔이 아쉬운 대로 다양해진 256색은 겨우 320*200에서밖에 지원되지 않아서 업무라기보다는 그냥 게임 전용 모드로만 쓰였다.

그 뒤로 VGA보다 더 높은 해상도와 더 많은 색상을 지원하는 규격은 그야말로 온갖 싸제 SVGA 제조사들이 난립하면서 파편화 천국이 됐다. VESA 같은 규격이 괜히 필요해진 게 아니다.

이게 불과 1990년대 초반의 일이니, 앞에서 언급한 보호 모드가 어떻고 DPMI가 제정되던 때와 시기적으로 비슷하다. 하긴, 1990년에 나온 그 옛날 프로그램인 Deluxe Paint조차도 처음 실행될 때 맨 아래에 1024*768 256색 SVGA 모드가 있긴 했다. 물론 당대에 그걸 선뜻 고를 수 있을 정도의 금수저 컴퓨터를 소유한 사용자는 매우 소수였을 것이다.

마소의 베이직 컴파일러야 SCREEN 명령으로 SVGA 지원은 전무했다. API 구조가 완전히 다른 3rd-party 라이브러리를 구해서 써야 했다.
볼랜드의 경우는 상황이 약간 낫다. 비록 자체적으로는 VGA까지밖에 지원하지 않았지만, 일종의 그래픽 드라이버인 bgi 파일이 내부 스펙이 공개돼 있고 확장 가능했기 때문에 이걸 기반으로 SVGA 라이브러리를 만든 곳이 있긴 했다.

검색을 해 보니 Jordan Hargraphix 소프트웨어가 이 업계의 독자적인 큰손이었던 모양이다. 이미 1991년 무렵부터 유명했다.
바이오스를 거치지 않고 일명 VGA mode X라고 불리는 320*240, 400*300 같은 변형 모드까지 다 지원했다.
그때는 소프트웨어가 잘못된 명령을 내려서 컴퓨터만 뻗게 하는 게 아니라 모니터를 손상시키는 것도 가능했던 시절이다. (주사율 변조..) 옛날에 CGA도 160*100 같은 tweak mode가 있었다고 하는데 그것만큼이나 신기한 일이 아닐 수 없다.

다만, BGI라는 그래픽 API는 무려 1980년대 후반에 개발된 것이며, 아무리 bgi 드라이버를 새 하드웨어에 맞게 확장한다 해도 256색 이상의 색을 지원하는 것은 구조적으로 불가능했다고 한다. 트루컬러 SVGA를 지원하려면 완전히 새로운 독자 라이브러리를 써야 했다.
BGI는 색상을 관리하는 게 RGB값 기반이 아니라 팔레트 인덱스 기반으로 고정돼 있었던 모양인데, 16비트 시절에 이는 충분히 수긍이 간다. 쟤가 무슨 Windows GDI 급으로 하드웨어 통합과 추상화를 표방한 물건은 아니었으니 말이다.

도스용 아래아한글은 16비트 바이너리의 경우 Turbo/Borland 컴파일러로 개발되었다. 하지만 아주 초창기인 1.x 시절부터 그래픽 라이브러리를 독자 구현했는지, 볼랜드의 보급 BGI 라이브러리를 사용한 흔적이 전혀 없는 것이 매우 흥미롭다.
이건 비슷한 시기에 도스용 한메 타자 교사도 마찬가지다. 얘도 MS C로 개발되었지, 의외로 볼랜드 출신이 아니다.

Posted by 사무엘

2019/03/23 08:31 2019/03/23 08:31
, ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1600

제2중부 고속도로(37)는 중부 고속도로(35)의 서울-수도권 구간을 확장하는 과정에서 추가로 건설된 고속도로이다.
도로를 확장해야겠는데 기존 도로는 다들 평지가 아닌 고가 교량 형태여서 그걸 건드릴 수는 없다. 그래서 옆에 도로를 더 만들게 됐다.

그럼 보통은 기존 도로는 전부 하행, 새 도로는 전부 상행.. 이런 식으로 개편하는 게 자연스러울 것이나, 중앙분리대를 제거하고 각종 도로 표지판들을 변경하고 진출입로를 이설하는 작업마저도 여의찮았는지 결국 기존 도로는 하나도 안 건드리고 그대로 놔 두게 됐다. "새 도로 추가.. 그 대신 새 도로는 중간에 진출입로가 없는 직행" 컨셉으로 제2중부 고속도로가 만들어졌다. 그리고 이 결과는 운전자들에게 "중부냐, 제2중부냐" 하는 눈치 게임으로 전가됐다.

중부와 제2중부가 병행하는 구간, 그리고 그 이북으로는 휴게소가 다음과 같이 3개가 존재한다.

(1) 마장 프리미엄 휴게소

중부와 제2중부 고속도로 사이의 섬이라는 꽤 적절한 위치에 굉장히 거대한 규모로.. 거의 복합 쇼핑센터 컨셉으로 비교적 최근에 만들어졌다(2013). 도로들보다 나중에 생겼다는 점으로 인해 진출입로에 입체 교차로 같은 건 없다. 그래서 중부에서는 상행만(하남 방면), 제2중부에서는 하행(청주 방면)만 이 휴게소에 접근 가능하다.

즉, 두 고속도로에서 한 휴게소를 공유하지만 방향은 제각기 반쪽짜리이다. 그리고 방향별로 주차장이 서로 분리돼 있기 때문에 들어왔던 차량이 방향을 바꿔서 나갈 수는 없다.

(2) 이천 휴게소

상행과 하행 휴게소가 제각기 3km 가까이 떨어져 있다. 상행은 두 고속도로가 공유하며, 나갈 때 중부와 제2중부 정도야 도로를 바꿔치기 할 수도 있다.
하행은 마장 프리미엄 휴게소와 아주 가까이 있는데, 얘는 오로지 중부 고속도로의 하행만 접근 가능하고 제2중부는 해당사항 없다. 그쪽은 어차피 마장 휴게소로 가면 되기 때문이다.

정리하자면, 이 구간에서 중부+상행이라면 마장과 이천 휴게소를 모두 이용할 수 있다. 그러나 제2중부+상행과 중부+하행은 이천 휴게소만 이용 가능하며, 제2중부+하행은 마장 휴게소만 이용 가능하다.

(3) 하남드림(구 만남의 광장) 휴게소

경부 고속도로에 있는 '만남의 광장 휴게소'의 중부 고속도로 버전이다. 과거에는 실제로 이름도 동일하게 '만남의 광장'이었다고 한다.
다만, 얘가 경부 고속도로 만남의 광장과 다른 점은 다음과 같다.

  • 경부 만남의 광장은 그래도 과거에 톨게이트가 있었고 현재도 시내 도로와 고속도로의 경계인 지점에 있는 반면, 하남드림은 앞뒤로 여전히 차들이 쌩쌩 달리는 고속도로 상에 있다.
  • 경부 만남의 광장은 상행 방면에서는 진입할 수 없는 반면, 하남드림은 상행 방면에서도 지하도를 거쳐서 진입 가능하다.

그렇기 때문에 경부의 상행에서는 죽전 휴게소가 마지막 휴게소이지만 중부의 상행은 하남드림이 마지막 휴게소이다.
그리고 이 두 만남의 광장은 모두 서울/동서울 톨게이트를 지나고 요금제가 개방식으로 바뀐 구간에 존재한다. 그렇기 때문에 차들을 진행 방향별로 분리하지 않으며, 나갈 때는 상행이나 하행 아무데나 자유롭게 나가면 된다. 단지, 경부 만남의 광장은 들어오는 게 하행에서만 가능하다는 차이가 있을 뿐이다.

Posted by 사무엘

2019/03/21 08:31 2019/03/21 08:31
, ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1599

영화들 중에는 주인공이 극단적인 사고 또는 범죄를 당해서 특이한 위험한 장소에 갇히고 거기서만 이야기가 진행되는 형태인 것이 몇 가지 있다.
이런 장르는 촬영 영역이 아주 좁고 등장 인물도 적은 특성상, 대작을 만들기는 어렵다. 하지만 굉장한 저예산으로도 작품을 너끈히 만들 수 있으며, 잘 만들면 스케일 대비 소재와 설정이 참신하다고, 작품성이 훌륭하다는 칭찬도 들을 수 있다.

가장 먼저 떠오르는 예는 (1) <베리드(Buried)>(2010)이다. 주인공은 생매장-_-을 당해서 지하의 관짝 안에 있으며, 영화는 온종일 이 좁은 관 안에서만 진행되니 촬영 하나는 기가 막히게 단순하고 쉬웠을 것 같다. 관을 구성하는 직육면체 옆면 네 개 중에서 하나는 촬영을 위해서 뜯어냈을 것이고..

주인공은 유일한 희망인 휴대전화로 전화 통화를 하면서 외부 사람에게 자기 위치를 알려주고 구조 받으려 애쓰지만.. 거기 지역이 지역인지라 일이 영 쉽지 않다. 영화 자체는 공식적으로 열린 결말로 끝나지만, 주인공은 사실상 죽는 것이나 마찬가지이다.

주인공은 명을 단축하는 그 어떤 치명상도 입은 게 없다. 하지만 저렇게 좁은 관 안에서 누운 채 꼼짝달싹 못 하는 채로 목마르고 굶주리며 아주 서서히 죽는 건 단칼에 푹찍악 해서 죽는 것 만만찮은 비참한 죽음인 게 틀림없다. 당장 화장실도 못 가고 변을 그 자리에서 배출해야 한다는 걸 생각해 보자..;;

사람은 가만히만 있어도 언젠가는 죽는다. 허나, 아무리 사람이 물리적으로 연약하다 해도 그 명줄이란 게 호락호락 쉽게 금방 끊어지지는 않는다. 좀 민망한 얘기이다만, 자살하려는 사람들이 더 빨리 죽으려고 굳이 목을 매달거나 옥상에서 뛰어내리거나 번개탄을 피우는 등의 수고를 괜히 하는 게 아니다.

그러고 보니 옛날에 조선에서는 사도세자가 관은 아니고 뒤주에 갇혀서 저렇게 죽었다.
<킬 빌 2>(2004)에서는 잘 알다시피 버드가 주인공 키도를 제일 천천히 고통스럽게 죽여 주겠다면서 생매장을 해 버리는데, 이건 나름 머리를 쓴 조치였다. 물론 이 영화에서는 생매장 씬이 10여 개에 달하는 전체 스토리 중 극히 일부 에피소드만을 구성할 뿐이며, 결정적으로 주인공이 비현실적인 인간 흉기인 관계로... 정권으로 관을 때려부수고 무덤을 탈출한다는 차이가 있다.

<베리드> 얘기가 좀 길어졌는데, 이것 말고 (2) <화씨 247도>(2011)는 주인공 남녀 일행이 뜨거운 사우나 안에 갇혀 버리는 내용이다. 문의 자그마한 유리창을 주먹으로 쳐서 깬 덕분에 최소한의 환기와 냉각은 가능해졌지만, 사우나는 어차피 온도에 따라 화력이 자동으로 조절되고 있으며 세 명이나 되는 사람이 얼굴을 거기로 들이민 채로 잠을 잔다거나 할 수는 없다. 나름 실화를 바탕으로 만들어졌다는데, 결말에서는 남자 주인공이 결국 죽는다..;;

(3) <12피트>(2017)는 자매지간인 아가씨 두 명이 커다란 수영장 내부에 갇히는 내용이다. 수영장의 수면 위로 덮개가 쳐지는 바람에 물 밖으로 머리를 내밀고 있기가 극도로 어려워졌다. 이 상태로 수영장 관리자는 퇴근을 해 버리고, 그대로 불금 주말이 시작된다..;; 주인공들은 점점 지쳐 가고 체온이 떨어지는데..
다행히 수영장에 다른 사람이 들어오긴 하지만, 관객들 열불나게 하는 짓을 벌이면서 주인공들을 호락호락 구해 주지 않는다.

<화씨 247>은 짐작하다시피 사우나의 내부 온도를 나타내며(섭씨 거의 120도), <12피트>는 수영장의 깊이를 나타낸다(3.7미터). 둘 다 주인공들이 처한 극한 상황의 특성을 제목으로 뽑았다는 점이 흥미롭다.

이런 장르의 영화 소재를 앞으로 뭘 더 떠올릴 수 있을지 궁금해진다.
가령, 엘리베이터 안에 갇히는 건... 설마 했는데 (4) <데블>(2010)이라는 작품이 있다. 5명이 타고 있던 고층 건물 엘리베이터가 갑자기 고장 나는데, 무척 인위적이고 비현실적인 설정이긴 하다만 불이 잠시 나갈 때마다 엘리베이터 안에서 누군가 한 명씩 다치거나 죽는다.;;

밀실에서 범인이야 뻔한 노릇인데, 저 탑승자를 뒷조사 해 보니 저마다 사기꾼, 폭력 전과 등등 경력이 화려하다.
현실에서는 엘리베이터가 충분히, 너무 안전하게 만들어져 나오기 때문에 고증을 많이 무시하지 않고서는 저런 식의 영화화가 곤란할 듯하다.

끝으로, 좀 옛날 영화인 (5) <폰 부스>(2002)는 사건 전개 장소가 시내 한복판이니, 사우나나 수영장 같은 통상적인 감금의 범주에 들지는 않는다. 하지만 빌딩숲 어딘가에 숨어 있는 저격수를 설정해서 "그 전화를 끊는 순간 네놈 목숨도 끊어질 줄 알아라"로 주인공의 발을 꼼짝달싹 못 하게 묶어 놓는 게 흥미로운 설정이다.

Posted by 사무엘

2019/03/19 08:34 2019/03/19 08:34
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1598

조선어 학회 사건 때 투옥되기도 했던 교사 겸 국어학자 정 태진 선생, 그리고 미군 장성인 조지 패튼과 월튼 워커..
이 사람들은 1940~50년대에 모두 교통사고로 세상을 떠났다는 공통점이 있다.
그 당시의 비포장 도로 사정을 감안하면 차가 절대로 그렇게 빨리 달릴 수 없는 상황이었으며, 저 인물들이 당한 사고는 안전 벨트를 매고 있었다면 사람이 죽을 정도의 사고는 절대 아니었다. 더구나 보행자도 아니고 차량 탑승자가 말이다.

하지만 20세기 중반에 자동차에는 안전 유리 정도나 도입되었지, 안전 벨트 비스무리한 물건은 아직 비행기 조종석을 벗어나지 못한 단계였다. 사고가 나면 탑승자는 관성 때문에 앞으로 튕겨나가서 좌석이나 유리창과 부딪치고, 최악의 경우 밖으로 날아가서 땅바닥에 나뒹굴었다.
그러니 장성급 VIP라 해도 교통사고가 났다 하면 얄짤없이 사망 아니면 중상을 면할 수 없었다. 하물며 정 태진의 경우는 아예 군용 트럭 짐받이에 아슬아슬하게 낑겨 타고 있다가 차가 전복됐으니 원..

기술의 발달 덕분에 자동차가 예전보다 얼마나 더 안전해졌는지를 실감한다. 안전 유리조차도 없던 자동차 초창기엔, 믿어지지 않지만 겨우 시속 30~40km로 달리다가 정면 충돌이 나도 사람이 죽을 수 있었다. 8기통 5000cc로 자동차 최대 출력이 30~40마력이던 100년 전쯤 시절 얘기다.
한편으로, 쿨하게 벨트 따위 없이 빠르기도 엄청 빠른 고속철이라는 교통수단에 경이로움을 느낀다.

사람이 교통수단의 곁에서 얼쩡거리다가 죽거나 다쳤다고 하면, 보통은 저렇게 달리는 자동차에 치이는 교통사고를 떠올린다.
무겁고 딱딱한 쇳덩이인 자동차와 퍽 부딪치고 나서 딱딱한 아스팔트· 시멘트 바닥으로 내던져지면 사람은 신체 곳곳이 부러지고 꺾이고 긁힌다. 하지만 아예 신체가 차 밑으로 들어가서 바퀴에 깔리는 것보다야, 차라리 튕겨 나가서 내던져지고 구르는 걸로 끝나는 게 나을 것이다.

일반적인 자동차에 치인 결과가 이러한데, 하물며 훨씬 더 무거운 열차에 치이거나 깔리면 시체가 온전히 남지도 못할 것이다. 지하철 선로 투신은 이루 형언하기 어려운 끔찍한 자살 방법이다.
단, 철도에는 굳이 달리는 차량에 치이지 않고도 끔살 당하는 다른 고유한 방법이 있다. 바로 전차선에 감전되는 것이다..;;

열차가 너무 빠르게 지나가면 사람이 근처에만 있어도 빨려 들어가서 죽거나 다치듯, 고압 전차선은 굳이 완전히 접촉하지 않고 십수 cm 남짓 근처에만 도달해도 감전될 수 있다.
또한, 똑같이 감전사해도 그냥 말단 부위에 화상만 남기고 비교적 곱게 죽는 경우가 있는가 하면, 열을 너무 많이 받아서 온몸이 순식간에 새까만 숯덩이 가루가 되기도 한다.

전압과 전류, 신체 상태가 어떻게 맞물리면 저렇게 될 수 있는지 모르겠다.
우리나라 전철이야 다들 가공전차선(공중) 방식이니, 감전 사고가 나는 건 사람이 일부러 열차의 지붕으로 올라가는 뻘짓을 했을 때밖에 없을 것이다. 하지만 경전철은 제3궤조 집전식이니 그 바닥은 어찌 될지 알 수 없다. 서양에는 touch the third rail (왕창 위험한 짓을 함)이라는 관용구까지 있다.

한편, 비행기와 선박은 자동차처럼 곱게 바퀴만 굴리는 게 아니라, 주변의 유체(공기 또는 물)를 빨아들이고 뒤로 내뿜는 추진 장치가 밖에 돌출돼 있다. 그렇기 때문에 그렇기 때문에 주행 여부와 관계없이 시동이 걸려 있는 것만으로도 곁에 있으면 더욱 위험하다.

선박의 경우, 주변에서 작업하던 인부가 스크루에 빨려들어가 끔살 당할 수 있다. 이런 사고는 범선이나 심지어 증기 외륜선 시절에도 걱정할 필요가 없던 부류일 것이다.
헬리콥터의 경우, 커다란 메인 로터는 머리 위 높은 곳에서 돌아가니까 괜찮지만, 테일 로터에 사람이 부딪히는 사고가 날 수 있다. 선풍기 날개에 손가락을 다치는 것 정도와는 비교가 안 되는 심각한 부상을 야기한다.

그리고 이 바닥의 갑은 제트기의 팬에 빨려들어가는 것이다.
수십~100수십 톤에 달하는 대형 비행기를 그냥 밀어내는 정도가 아니라 공중에 띄우기까지 해야 하는데.. 엔진의 힘이 얼마나 돼야 하며, 단위 시간 동안 빨아들이고 팽창시켜 내뿜는 공기의 양이 얼마나 될지는 상상조차 하기 어렵다. 단순히 새 정도가 아니라 사람도 당연히 빨려들어갈 수 있다.

지난 2006년 1월 16일에는 미국 엘 파소 공항에서 항공 정비사가 보잉 737 국내선(컨티넨탈) 여객기의 팬에 빨려들어가는 사고가 실제로 난 적이 있다고 한다. 그리고 합성이나 주작이 아닌지 신빙성이 약간 의심은 된다만, 사고 현장의 사진도 검색해 보면 나온다. 해당 엔진 전체는 말할 것도 없고 주변 바닥까지 온통.. 사람은 뼈도 옷도 유품도 없고 형체가 전혀 없이, 그냥 시뻘건 피와 살점으로 범벅이 됐더라..;;

FPS 게임에 나오는 gib(피떡)라는 것의 더 잔혹한 실사판을 볼 수 있었다. 그냥 사람이 사지 잘리고 바닥에 피 흘리며 죽어 있는 어지간한 전쟁터나 교통사고 현장과는 차원이 다르다.
이렇게 사고가 난 뒤의 모습 말고, 심지어 옆 비행기에서 그 사람이 실제로 쏙 빨려들어가서 죽는 모습을 촬영했다는 동영상까지도 굴러다니는 게 있는데, 이건 합성 주작인 것 같다. 하지만 사건 자체는 실제로 일어난 게 맞다.

요약하자면..

  • 육상 교통수단은 그 특성상 움직이는 차체에 사람이 치이거나 깔리는 교통사고가 날 수 있다. 차와 차끼리도 서로 부딪칠 수 있다.
  • 그에 덧붙여서 철도는 전차선이 존재하는 유일한 교통수단이다 보니 차체의 운행 여부와 관계 없이, 아니 오히려 반대로 정지해 있을 때 감전 사고가 날 수 있다.
  • 다음으로, 땅 위에서 바퀴를 굴리는 형태가 아닌 교통수단들은(비행기, 선박) 추진 프로펠러에 빨려들어가는 사고가 날 수 있다.

Posted by 사무엘

2019/03/17 08:32 2019/03/17 08:32
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1597

* 2014년에 썼던 글을 보완하여 다시 올린다.

옛날에 도스 시절에는 일명 '외부 명령'이라 하여 별도의 프로그램 형태로 존재하는 명령들이 있었다. format.com, diskcopy.exe 같은 것들.
이것들은 자기가 소속된 도스 버전을 가려서 동작했다. 가령, MS 도스 5.0이 설치된 컴퓨터에다 도스 6.x에 존재하는 새로운 유틸리티를 복사해 와서 실행하면, 실행에 필요한 파일들이 다 있다 하더라도 '도스 버전이 다릅니다'라는 에러 메시지와 함께 프로그램이 그냥 실행되지 않았다. 이것은 운영체제의 버전을 가려 가며 실행하는 프로그램을 본인이 난생 처음으로 접한 사례였다.

Windows에도 자신의 버전을 알려 주는 API가 응당 존재한다. 하지만 이건 지금 구동 중인 운영체제가 무엇인지를 알려 주는 편의 기능을 구현할 때나 사용할 만한 기능이다. 일반적인 프로그램이라면 About 대화상자 같은 데서 말이다.
만약 프로그램이 운영체제의 버전을 가려 가며 실행해야 한다면, 단순히 운영체제의 버전을 갖고 판단하는 건 썩 좋은 방법이 아니다. 내가 실제로 사용하고자 하는 기능을 요청해 보고(CoCreateInstance, LoadLibrary/GetProcAddress 등), 그 요청의 성공 여부에 따라 실행 여부를 결정하는 게 바람직하다.

뭐, 지금은 아무 의미가 없는 예가 돼 버렸다만,
가령 내 프로그램이 유니코드 API를 사용하기 때문에 Windows 9x에서는 실행을 거부해야 한다고 치자.
그렇다면 CreateWindowExW건 RegisterClassW건 유니코드 API를 실제로 호출해 본 뒤, 그게 실패하고 GetLastError()==ERROR_CALL_NOT_IMPLEMENTED가 돌아올 때 실행을 거부하면 된다. 운영체제의 외형보다는 그 운영체제의 실제 실행 결과를 보고 판단하는 게 낫다는 게 바로 이런 의미이다.

그런 것도 다 필요 없고 운영체제의 버전 숫자를 정말로 정확하게 알아 와야 한다면,
그 경우를 위해 태초에 GetVersion()이라는 간단한 함수가 있었다. 얘는 버전과 관련된 여러가지 정보들을 비트 자릿수별로 묶은 32비트 정수를 되돌렸다.

그 정보의 의미를 C언어의 비트필드 구조체로 나타내 보면 대충 다음과 같다. 주석으로 표시된 숫자는 윈도 7 기준으로 반환되는 값들이다.
(최신 Windows 10 기준의 반환값을 소개하지 않은 이유는 후술하도록 하겠다)

union WINVERSION {
    DWORD dwValue;
    struct {
        UINT nMajorVer: 8; //6
        UINT nMinorVer: 8; //1
        UINT nBuildNumber: 15; //7601
        UINT bWin9xOrWin32s: 1; //0
    };
};

WINVERSION os;
os.dwValue = ::GetVersion();

이 함수는 아무 매개변수도 필요하지 않으며, 리턴값도 DWORD 달랑 하나이니 미치도록 가볍고 사용하기 편하다. Windows 9x와 NT 계열이 공존하던 옛날에, 지금 운영체제가 (1) NT 계열인지를 알고 싶다면 GetVersion()&0x80000000 (최상위 비트)만 하면 OK였다.
그 뒤, NT 3.x인지 4.0인지, 9x 계열의 경우 95인지 98인지 ME인지 같은 건 (2) major와 minor 번호를 보고 판별하면 됐다. (3) 빌드 번호는... 딱히 막 중요한 정보는 아닌 듯하다.

그러나 이 함수는 문제점과 한계도 보였다. 한눈에 봐도 각 비트로부터 의미 있는 정보를 추출하는 게 매우 지저분하고 번거로웠다. HIWORD, LOBYTE 삽질이 싫다면, 저런 비트필드 구조체는 프로그래머가 재량껏 알아서 만들어야 했으며, 응용 프로그램이 이 정보를 잘못 취급하는 경우도 많았다.

비교할 필요가 없는 필드까지 다 비교를 해 버리는 바람에, Windows 95 이상에서 모두 동작할 수 있는 프로그램이 Windows 95에서“만” 동작하게 고정돼 버리기도 했다. 혹은 Windows NT 4.0이 NT 3.51보다 낮은 버전으로 취급되는 촌극도 벌어졌다. (리틀 엔디언 기준으로 저 구조체를 보면, minor 버전이 major 버전보다 더 높은 자릿수에 놓여 있음)

더구나 운영체제의 정체성을 나타내는 정보는 단순히 버전 번호와 빌드 번호 이상으로 더욱 복잡해져 왔다. NT 계열의 경우 당장 서비스 팩이 있고, 이게 무슨 에디션인지도(홈? 서버? 워크스테이션? 등) 알 필요가 있는데 단순히 숫자 하나만 달랑 되돌리는 함수로는 그런 걸 알려 줄 수가 없었다.

이런 문제를 해결하기 위해 Windows 95 내지 NT 3.5에서는 OSVERSIONINFO라는 구조체를 인자로 받는 GetVersionEx라는 함수가 추가되었다. major, minor 버전 번호와 빌드 번호, 운영체제 계열이 모두 독립된 구조체 멤버로 독립하였으며, (4) 서비스 팩 내역도 완전한 문자열 형태로 되돌려 주니 버전 정보를 다루기가 편해졌다.

이 구조체는 맨 앞에 자신의 크기를 써 주게 돼 있으며, 덕분에 추후 확장이 가능한 형태이다.
Windows 2000부터는 OSVERSIONINFOEX 구조체가 추가됐다. 확장된 구조체는 서비스 팩의 번호조차도 major와 minor 꼴로 받을 수 있으며, (5) 같은 NT 계열 중에서도 클라이언트 라인과 서버 라인을 구분할 수 있다(wProductType==VER_NT_WORKSTATION / VER_NT_SERVER). Windows XP와 Server 2003은 버전 번호가 5.1과 5.2로 서로 달랐지만, 후대 버전부터는 버전 번호는 동일하고 이걸로 구분을 해야 한다. (Vista / Server 2008, 10 / Server 2016 같은..)

그리고 클라이언트 라인은 XP 이래로 오늘날의 10까지 (6) home과 pro 에디션 구분이 거의 관행이 돼 있는데.. 이건 wSuiteMask 멤버의 비트 플래그 VER_SUITE_PERSONAL (0x200)의 존재 여부로 판별 가능하다. 저 플래그가 존재하는 게 home 에디션이다.
VER_SUITE_* 다른 플래그들 중에는 Windows XP의 embedded 에디션, enterprise 에디션 같은 걸 나타내는 것들도 있으니 참고하면 된다.

요컨대 9x/NT 이후로도 클라이언트/서버, home/pro 같은 복잡한 구분이 계속 이어지는 것을 알 수 있다. 그래도 GetVersionEx 한 방이면 모든 정보를 얻을 수 있다.

이걸로 모든 이야기가 끝이 났으면 좋겠지만.. 아이고, 끝이 아니다. GetVersionEx 함수는 2010년대 이후로 마소의 정책상 사용이 더 권장되지 않는 deprecate 판정을 받고, 시간이 정지해 버렸다.
이 함수는 아무런 단서가 없는 환경에서는 Windows 8, 즉 버전 6.2보다 더 높은 값을 되돌리지 않는 샌드박스가 되었다. 실제로는 이 컴퓨터에 Windows 8.1이나 10이 돌아가고 있더라도 말이다. 이와 관련된 더 자세한 정보를 원한다면 다음 URL을 참고하시기 바란다.

이제 이 함수는 응용 프로그램에게 그 응용 프로그램보다 나중에 출시된 운영체제에 대한 정보는 주지 않기로 작정한 듯하다. GetVersionEx가 샌드박스 없이 실제 자기 버전을 되돌리는 조건은 다음과 같다.

  • 응용 프로그램의 manifest XML에(compatibility-application-supportedOS) 그 운영체제의 GUID가 등록되어 있다.
  • 혹은 응용 프로그램의 PE 헤더에 OS의 최소 요구 버전이 최신 운영체제의 버전으로 맞춰져 있다. Windows 8.1의 경우 6.3, Windows 10이라면 10.0이 되겠다.

운영체제와 함께 제공되는 메모장 같은 기본 프로그램들은 후자의 조치를 취한 상태이다. 이렇게 빌드된 프로그램에서는 GetVersionEx가 해당 버전을 정확하게 되돌린다. 하지만 이런 프로그램은 이전 버전 운영체제에서는 아예 전혀 동작하지 않으므로, 3rd-party 응용 프로그램이라면 이런 방법을 쓰기 곤란하다. 그러니 매니페스트 등록을 해야 한다.

물론 마소에서 2015년의 Windows 10부터는 기존 버전 번호 자체를 10.0으로 동결시켜 버리고 더 바꾸지 않기로 작정했다. 그러니 버전 번호 변경으로 인해 GUID를 또 등록하는 식의 혼란은 앞으로 더 없을 것이다.

운영체제의 버전의 절대값을 되돌리는 GetVersionEx 대신 마소에서 사용을 권장하는 함수는... 지금 운영체제의 버전이 응용 프로그램이 제시하는 버전보다 상대적으로 높은지 안 높은지 여부만을 되돌리는 VerifyVersionInfo 함수이다. 그리고 이걸 기반으로 IsWindows10OrGreater 같은 helper 함수들도 만들어져 있다. (VersionHelpers.h)

하지만 이 함수들도 내부적으로 GetVersionEx의 결과값을 기반으로 비교를 하는 것이기 때문에 앞서 언급한 샌드박스의 제약을 받는 건 마찬가지이다.

샌드박스 없이 운영체제의 정확한 버전을 얻어 오는 함수는 크게 두 군데에 있다.
먼저, 의외로 네트워크 API이다. 그렇다고 소켓 API 같은 건 아니고, Windows에서 독자적으로 제공하는 함수 중에 내 로컬 컴퓨터를 포함하여 원격 컴퓨터에 설치된 운영체제의 버전을 얻어 오는 함수가 있다. 대략 다음과 같이 코드를 작성하면 된다.

#include <LM.h>
#pragma comment(lib, "netapi32")

WKSTA_INFO_100 *p;
::NetWkstaGetInfo(NULL, 100, (LPBYTE *)&p);
printf("%d, %d\n", p->wki100_ver_major, p->wki100_ver_minor); //10, 0
::NetApiBufferFree(p);

저기 100은 수효를 나타내는 게 아니며 각각의 숫자들이 별개의 의미를 지님에도 불구하고, 상수 명칭이 존재하지 않아서 그냥 생으로 100을 넘겨 줘야 한다.
운영체제 버전 하나 좀 얻자고 웬 생뚱맞은 분야의 API를 써야 하는 것도 삽질스럽지만.. 저 함수를 통해서는 그냥 major와 minor 버전 번호만 얻을 수 있다. 서비스 팩이나 빌드 번호 같은 세부 정보는 얻을 수 없다.

저거 말고 다른 대안으로는.. ntdll.dll에 있는 native API인 RtlGetVersion을 써도 된다.
OSVERSIONINFO(EX)의 포인터를 받아들이고 정수값을 리턴하므로 prototype이 기존 GetVersionEx와 거의 동일하다.
단, native API 버전은 성공한 경우의 리턴값이 0이다. 리턴 타입이 BOOL이 아닌 셈이다.

얘는 Windows 8.1 내지 10 같은 요즘 운영체제에서는 잘 동작하는데, 과거의 Windows 2000에서는 GetVersionEx와 달리 서비스 팩 정보를 되돌리지 않았던 것으로 기억한다. 구형 OS에서는 오히려 기존 함수를 쓰는 게 더 낫다. 거 참..;;
Windows가 지난 20년 동안 운영체제의 버전과 제품 종류를 얻는 그 단순한 절차만 해도 얼마나 복잡하고 지저분해져 왔는지를 확인할 수 있다. 관련 여담을 몇 가지 더 남기는 것으로 글을 맺고자 한다.

  • OSVERSIONINFOEX는 C++ 상속 문법 같은 걸 이용해서 선언된 게 아닌 관계로, OSVERSIONINFO와는 언어 차원에서 아무런 연결 고리가 없다. GetVersionEx에다가 전달할 때는 OSVERSIONINFO*로 reinterpret_cast를 해 줘야 된다.
  • 과거 Windows XP에는 media center 에디션 내지 태블릿 PC 에디션 같은 바리에이션이 있었는데.. 이거 여부를 얻는 건 GetVersionEx가 아니라 GetSystemMetric라는 다소 생뚱맞은 함수에 있었다. SM_MEDIACENTER, SM_TABLETPC처럼 말이다 .
  • 끝으로, Windows 10부터는 (7) 릴리스 연-월을 나타내는 4자리 숫자가 사실상 버전 번호가 됐으니 이걸 표시해 줘야 할 것이다. 그런데 이건.. 본인이 아는 방법은 그냥 무식한 레지스트리 조회가 유일하며, 공식적인 API가 따로 있지 않다.;;;

Posted by 사무엘

2019/03/14 08:36 2019/03/14 08:36
, ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1596

영화 항거 외

1. 영화

올해는 3· 1 운동 발발 100주년인 해답게 이 타이밍에 맞춰 유 관순을 소재로 한 영화가 적절하게 개봉했다. 말모이에 이어 또 일제 시대 배경 영화이긴 하다만, 이것도 명분이 충분하기 때문에 본인은 관람을 하고 왔다.

사용자 삽입 이미지

이 영화는 안 그래도 3· 1 운동 자체가 아니라 유 관순의 투옥 이후 시점을 주로 다루고 있다. 그렇기 때문에 서대문 형무소 역사관을 실제로 구경하고 나면 영화의 공간 배경을 이해하는 데 매우 큰 도움이 될 거라는 점을 가장 먼저 언급하고자 한다. 그러니 제대로 감상하고 싶은 분은 사전에 저기부터 가 보시기 바란다.

본인은 9년 전, 이 블로그가 처음 생겼던 2010년 초에 가 봤다. 일반 감방뿐만 아니라 유 관순이 말년에 실제로 격리 수용됐던 지하 독방까지 직접 볼 수 있다.

  • 유 관순은 서대문(경성) 형무소에서 옥사
  • 강 우규 의사는 서대문 형무소에서 사형 (유 관순이 투옥된 시기에 서울 역 광장에서 사이토 총독의 암살을 시도했던 노인)
  • 훗날 조선어 학회 사건 연루자 두 분은 함흥 형무소에서 옥사
  • 주 기철 목사는 평양 형무소에서 옥사

지역이 이렇게 대응한다.

그리고 이 영화는 이례적으로 흔치 않은 흑백 영화라는 것도 미리 염두에 두시기 바란다. 킬 빌처럼 일부 주요 장면만 흑백인 것도 아니다(녹엽정 전투..).
현실의 형무소 장면은 죄다 흑백이고, 일부 과거 회상 장면이 컬러이다. 보통은 그 반대인 것 같은데 이례적이다.

비슷한 시기에 또 항일 운동을 소재로 한 "자전차왕 엄 복동"도 개봉했다.
하지만 스포츠로 한국이 일본을 이긴 얘기를 극화하고 싶으면 차라리 손 기정 내지 홍 덕영 골키퍼 (해방 이후 월드컵 예선 한일전!)같은 사람이나 재조명할 것이지, 참신한 소재를 찾는답시고 자전거 도둑질도 전문이었던 사람을 소재로 삼은 게 논란이 됐다. 그 사람이 하다못해 친일파· 일본놈들만 상대로 의적(?)질을 한 것도 아니다.

소재부터가 삐걱거리는데 영화 자체도 그리 잘 만든 게 아니었고, 더 고퀄인 "항거"에게 팀킬 당하니 엄 복동 얘기는 예전의 "대장 김 창수"의 말로를 가면서 대차게 망했다. 뭐, 자전거 도벽은 아예 친일 변절이나 강도살인보다는 죄질이 상대적으로 가볍긴 하다만, 저 양반이 훔친 액수도 단순 생계형으로 실드 칠 수 있는 수준이 아니었다.

2. 3· 1 운동

그럼, 영화를 벗어나 3· 1운동 자체에 대해서도 얘기를 좀 해 보자.
냉정하게 생각해 보면, 솔직히 그까짓 만세 부른다고 해서 일제가 "아 그러셨어요~? ^^"물러가고 독립이 찾아올 리는 만무하다. 더구나 3· 1 운동은 주요 배경, 명분, 동기에 핀트가 근본적으로 안 맞는 게 있었다.

(1) 1910년대 일제 무단 통치에 대한 반감과 민생고(흉년, 물가 상승)는 그렇다 치지만 (2) 고종 독살 의혹은.. 글쎄, 고종이 무슨 세종대왕 급으로 추모 받을 성군이었는지는 잘 모르겠다. 결정적으로 어디서 주워 들었는지 모르겠지만, (3) 민족 자결주의는 1차 대전 승전국인 일본의 식민지인 조선에 적용되는 내용이 아니었다.

유 관순도 그 기백이 정말 대단하긴 하지만, 너무 무모하게 매를 벌지 말고, 1년 반 정도만 빵에서 살다가 나와서 공부 더 하고 더 오래 살았으면 더 큰 일을 할 수 있지 않았을까 아쉬움이 남는다.
그래도 만세 시위 때 자기 부모를 왜놈들한테 잃고 완전히 꼭지가 돌아 버렸을 테니, 그 뒤로 왜놈을 가족과 민족의 철천지 원수로 여기고 저놈들한테 절대로 고개를 숙이지 않겠다고 고집 부린 그 악바리와 깡과 근성은 충분히 이해가 된다.

영화에서 유 관순의 감방 동료로 나오는 권 애라와 김 향화(배우 이름이 아닌 배역 이름)는 실존 인물이다. 특히 김 향화는 수원에서 활동한 기생이다. 이 시절에 기생은 우리가 흔히 생각하는 야시꾸리한 직업 종사자가 아니라, 요즘으로 치면 스튜어디스 급은 되는.. 단순 서비스 접대 이상으로 지와 미와 예능을 갖춘 사람이었다.

2차 세계 대전 태평양 전선에서는 미국이 일본놈들한테 학을 떼면서 뭐 저런 상또라이들이 있나(반자이 어택, 카미카제..) 경악했었다. 하지만 더 옛날에는 일본도 조센징들을 보곤 뭐 저렇게 지독하게 말을 안 듣는 독종 또라이들이 있나 멘탈 대미지(반자이 트라우마..)를 입고 충격을 먹었던 모양이다. 그래서 1920년대에는 문화 통치 유화책이 나오게 되었다.

흔히 호남 지역을 비하하면서 저기가 3· 1 운동 참가자 내지 투옥자가 제일 적었다는 통계를 제시하는 경우가 있다. 하지만 거기는 3· 1 운동 이전에 1890년대의 동학 운동과 1900년대의 의병 때문에 항일 인사들이 몽땅 토벌되고 씨가 마른 상태이기도 했다는 것을 감안할 필요가 있다. 통계 자체에 대한 조작과 왜곡 가능성은 고려하지 않았을 때 말이다.

3. 혹시나 했지만 역시나..

이 영화와 배경 내용에 대해서 말할 거리는 이 외에도 더 있지만, 일단 기독교 신앙이 의외로 꽤 자주 언급되는 게 인상적이고 좋았다. 유 관순은 실제로 교인이기도 했으니까..
"행함이 없는 믿음은 죽은 믿음", "시험을 면하게는 하지 않아도 이길 힘을..", "기도하는 수밖에 없음", "예수님은 바보여서 저렇게 십자가에 매달려 죽으신 줄 아냐" 무려 이 정도 분량이 대사에 포함돼 있다.

신앙 쪽으로 왜곡 없는 중립· 긍정적인 묘사 덕분에 본인은 처음엔 영화에 대한 호감도가 슬슬 올라갔다. 그러나 결말부를 보고는 기분이 완전히 잡쳐 버렸다.
정작 유 관순이 최후를 맞이하는 장면은 너무 얼렁뚱땅 대충 자막으로 때워 버리고는, 그 뒤에 어설프게 또 이상한 친일파 드립과 반일 프레임 엮기.. "혹시나 했더니 역시나였군.. ㅉㅉ" 싶었다.

정 춘영인지 누군지 출신과 생몰 시기도 모르는 웬 듣보잡 조선인 헌병이 있어서 유 관순을 내내 괴롭혔다고 한다.
이놈은 친일 부역 행적이 탄로나서 해방 후 반민특위에 의해 기소되었으나, 그 이름도 찬란한 모 할배의 특별 배려(!)로 사면되고 제대로 처벌받지 않았다. 이걸 말이라고 자막을 떡 걸어 놨으니 나도 꼭지가 돌아 버리겠다. 하지만 실상은 유 관순이 교인이었던 것만큼이나 할배도 교파까지 같은(감리교) 교인이었으며, 유 관순이 독립 운동가인 것만큼이나 반민특위를 불가피하게 해체한 배후 인물(애산 이 인)도 똑같이 항일 독립 운동가였다.

어디 '정춘영 유관순 고문'이라고 검색을 해 보아라. 정확한 기록 같은 건 없고, 같이 걸려 나오는 건 유 관순이 무슨 미꾸라지 고문을 당하고 코가 잘리고 머리 가죽이 벗겨졌다는 얘기, 아니 도시전설 괴담밖에 없다.
그렇게도 친일 부역자 조선인 헌병을 개새끼로 만들고 싶으면 영화에다가도 미꾸라지 고문 씬을 넣지 그랬냐? 일본 제국주의 악마들이 겨우 손톱 뽑기 내지 캐비닛 안에 선 채로 며칠 감금 정도만 했을 것 같은가?

그리고 크레딧 롤이 올라가는 동안이나 작품 결말부에서 주인공이 죽기 전에.. 그 이름도 유명한 "내 손톱이 빠져나가고 내 귀와 코가 잘리고 내 다리가 부러져도 그 고통은 이길 수 있사오나, 나라를 잃은 그 고통만은 견딜 수가 없습니다" 이 출처불명의 비장한 유언도 좀 나왔어야지? 안 그런가?

삼일 운동 그 자체가 조국의 독립을 가져오지는 못했지만 이 항거는 외국에까지 소개되어서 조선의 독립 의지를 알리는 데 도움이 됐다는둥, 그 정신이 지금 우리나라 헌법에도 명시돼 있다는둥, 유 관순 말고 다른 여학생· 기생의 의거도 많이 벌어졌다는둥.. 클로징 멘트로 다른 좋은 말을 얼마든지 골라 넣을 수 있었을 텐데.. 마무리를 의도적으로 저 따구로 지은 저의가 뭐냐!? 매우 유감스럽고 씁쓸했다.

4. 3· 1 운동 때 투옥된 뒤에도 천수를 누린 다른 여성

옛날에 우리나라엔 '추계 최 은희(1904-1984)'라고 무려 1920년대에 조선일보에 입사해서 여성으로서는 거의 국내 최초로 기자라는 직업에 종사한 분이 있었다.

사용자 삽입 이미지

보다시피 유 관순보다 약간 어릴 뿐 거의 같은 연배이다. 3· 1 운동에 가담하다가 붙잡혀서 세 주 남짓 옥고를 치르면서 험한 꼴을 봤지만, 그 뒤엔 풀려나서 학교를 무사히 졸업하고 기자도 됐다. 덕분에 방송을 타고 비행기도 타 보는 등, 일제 시대 조선 여자로서는 상상하기 힘든 진귀한 경험을 많이 할 수 있었다.
(참고로 3· 1 운동 당시의 소속이 유 관순은 이화학당, 저분은 경성여고보)

이분의 호인 '추계'는 추계 예술 대학교의 설립자하고는 관계 없다. 그 추계는 황 신덕(1898-1983)이라는 다른 사람의 아호인데, 저분 역시 최 은희와 동시대를 살았던 신여성이며, 3· 1 운동에 가담했고 기자 커리어까지 있는 것이 서로 굉장히 비슷하긴 하다. 아마 서로 아는 사이였지 않을까?

호 다음으로 '최 은희'라는 이름은 국내에서는 영화 배우의 이름으로 훨씬 더 유명하다. 이런 이유로 인해 두 단어를 합친 '추계 최 은희'라는 사람은 인지도가 낮으며, 언론 쪽 종사자가 아니면 잘 모를 것이다. 하지만 언론인 출신 최 은희가 영화 배우 최 은희보다 훨씬 더 무시무시하고 위대한 인물이다. 추계 최 은희는 대학을 설립한 게 아니라 자기 이름을 딴 '최은희 여기자상'이라는 것을 제정했다.

저분은 결혼 후에는 기자 커리어가 중단되었다. 허나, 1남 2녀를 낳아서 세 명 모두 박사까지 공부 시키고 유학도 보내고 전부 대학 교수로 키웠다.;; 그 중 막내딸은 이화여대 국문과 교수를 역임한 이 혜순으로, 2000년대 중반에 정년 퇴임했다.

본인은 먼 옛날에 "유쾌한 구두쇠들"(1994)이라는 책을 통해 저런 사람이 있다는 걸 알게 됐다. 공 병우 박사, 남 기심 교수, 이 혜순 교수(두 교수 다 국문과이구나.. 세부 전공은 다르지만) 등 17명의 유명인사가 공동 집필한 책인데, 다들 비범하고 사회적으로 성공하고 돈도 엄청 많이 번 사람들이다.

그런 사람들이 일상생활은 서민들 이상으로 정말 둘도 없이 검소하게 효율적으로 하면서, 옳은 일 큰 일에 아낌없이 돈을 쾌척한 얘기들이 실려 있다. 지금은 시대에 맞게 저 책 내용이 웹툰으로 각색되어서 연재되면 어떨까 싶다.
다만, 저자 중에 지금은 완전히 몰락한 방송인 서 세원 씨까지 포함돼 있는 게 참 묘하다.

이 혜순 교수는 저 책이 나온 지 10년이 넘게 지나고 나이 70을 바라보는 명예교수가 된 뒤에도 개인적으로 가장 존경하는 인물은 변함없이 자기 어머니라고 회고했다. (☞ 관련 링크)
뭐, 인생 한번 짧고 굵게 살다 가는 것도 나쁘지 않지만, 유 관순 같은 인물이 형무소를 살아서 출소해서 공부 더 하고 후세도 남겼으면 인생이 최 은희와 비슷해지지 않았을까 싶은 생각이 문득 들었다.

Posted by 사무엘

2019/03/11 08:36 2019/03/11 08:36
, , , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1595

날개셋 한글 입력기가 올해 최초의 새 버전이 나왔다. 우연히도 3· 1 운동 100주년과 비슷한 타이밍에 말이다. 올해 초까지만 해도 이제 날개셋 한글 입력기는 당분간 더 만들 게 없을 거라고 예상했었지만 결국은 9.7까지 또 잘만 올라가게 됐다. 마치 석유가 이제는 고갈된 것 같아도 자꾸 더 채굴되는 것처럼 말이다.

물론 9.5 이후로 완전히 새로운 기능의 추가나 대규모 개편 같은 작업은 없다. 다만, 지금 체계 하에서 이미 있는 기능들의 완성도를 높이는 작업 아이템은 여전히 종종 발견되고 떠오르고 있고, 그게 버전 번호를 올려 주고 있다. 그래도 날개셋 10.0이 내 학위논문보다 먼저 나오는 일은 없었으면 좋겠다. ㅠㅠ

이번 9.7에서는 이전 글에서 언급했던 것처럼 마우스 휠의 인식 방식을 개선했으며, 글꼴 본뜨기 스크립트에 한중일 확장 한자 C/D도 추가했다. 그것 말고 프로그램의 완성도를 강화하는 변화로는 다음과 같은 것들이 있다.

1. 수정 가능한 공용 파일의 접근성 강화

날개셋 한글 입력기 프로그램이 사용하는 데이터 파일 중에는 모든 사용자가 공유하면서 사용자가 내용을 수정할 수도 있는 텍스트 형태의 파일이 있다.

  • 편집기가 사용하는 상용구 리스트(qidiom.txt)
  • 글꼴 본뜨기 절차 리스트(fontextr.txt) -- 16픽셀용과 24픽셀용이 서로 별개
  • 날개셋 제어판이 사용하는 custom 내정값 XML (scheme.xml) -- 각 언어별로 서로 별개

그런데 문제는.. 이 파일들은 여느 데이터 파일들과 마찬가지로, 관리자 권한이 없이는 내용을 변경할 수 없는 형태로 설치된다는 것이다.
본인은 이 파일들을 읽기/쓰기 겸용을 의도했지만 실제로 사용자들은 제대로 변경해 가며 활용을 할 수 없었다.

고민 끝에 이제 이렇게 조치를 취했다.
이 파일들은 처음에는 .txt.$라고 확장자 뒤에 $가 추가된 형태로 설치된다.
그리고 날개셋 프로그램에서 이 파일이 필요할 때 동일 명칭의 .txt와 .txt.$ 파일을 모두 살펴보고, .txt가 없거나 .txt.$보다 날짜가 과거이면 .txt.$를 .txt로 덮어쓰기 복사를 한다. 그래서 새로 생성된 .txt 파일을 사용한다.

ProgramData 디렉터리는 Program Files 같은 읽기 전용 디렉터리가 아니며, 응용 프로그램이 파일을 새로 생성하는 것은 가능하기 때문이다. 그리고 그렇게 일반 권한으로 동적으로 생성된 파일은 사용자가 얼마든지 고칠 수 있다.
이렇게 하면 사용자가 실수로 .txt 파일을 지워 버리더라도 .txt.$로부터 원래 파일이 자동으로 복원되는 효과도 얻을 수 있다. 그러니 더욱 좋으며, 이게 최선의 문제 해결 방식이라고 생각된다.

2. 입력 패드에 /S 옵션이 제대로 동작하지 않는 문제 해결

날개셋 입력 패드의 경우, 입력 도구를 띄웠다가 모두 닫아서 입력 도구가 하나도 없게 됐을 때 프로그램도 자동으로 종료하는 /S 옵션이 있다. 입력 패드를 특정 입력 도구만 띄우는 목적으로 간단히 활용할 수 있게 하기 위해서 이런 옵션을 제공한다.

그런데 이 옵션이 지금까지 다음과 같이 제대로 동작하지 않는 걸 뒤늦게 발견했다. 그래서 고쳤다.

  • 각 입력 도구의 자체 UI(X 버튼 또는 우클릭 메뉴) 명령을 통해서 닫아서 모두 없어진 것만을 감지했다. 입력 패드 프로그램의 트레이 우클릭 메뉴를 통해서 입력 도구를 모두 닫았을 때는 프로그램이 자동 종료되지 않았다.
  • 그리고 개수를 체크하는 코드 자체도 언제부턴가 프로그램의 소스 코드 구조가 바뀌었을 때 같이 바뀌었어야 하는 부분이 바뀌지 않았다. 그래서 1개에서 0으로 줄었는지를 확인하는 게 아니라 2개에서 1개가 됐을 때를 체크하게 잘못 동작하고 있었다.

3. 에디팅 엔진의 미묘한 버그 수정

날개셋 한글 입력기에서 완전 기초 기본 기능에 속하는 편집기의 에디팅 엔진 쪽에 아직까지도 버그가 발견되고 고칠 게 있다는 게 본인 역시 실감이 안 가지만.. 이번에 그런 게 있었다. 물론 평소에 대다수 사용자에게는 거의 티가 안 나기 때문에 10년이 넘는 세월 동안 본인에게도 발견되지 않을 수 있었다.

날개셋 편집기의 장점 중 하나는 운영체제의 TSF 인터페이스를 온전히 지원한다는 것이다. 그래서 IME들이 자기 조합 문자열뿐만 아니라 주변 텍스트 내용에 모두 접근해서 읽고 쓸 수 있다.
그러기 위해서 날개셋 편집기 역시 운영체제의 요청이 있으면 편집 중인 텍스트를 되돌리고 수정하고, 현재 블록이 잡힌 영역을 알려 준다. 또한, 텍스트가 자체적으로 수정되었다면 어디가 얼마만치 수정되었는지를 운영체제에다가 알려 주기도 한다.

문제가 발견된 곳은 내 프로그램에서 수정된 영역을 운영체제에다가 알려 주는 부분이다. 이걸 제때 해 주지 않으면 오동작이 발생한다는 건 오래 전부터 경험적으로 체득되어 있었다.
다만, 내 프로그램도 수정된 내역에 따라서 문단 정렬을 다시 하고 cursor의 좌표를 수정하고 그럭저럭 내부 정리를 완료한 뒤에 통지를 해야 하는데 그러지 못하고 착오가 있었다. 그래서 일부 특수한 조건이 만족되는 상황에서는 틀린 좌표를 알려 줬다.

운영체제가 수정 영역 정보를 어떤 용도로 참고하는지 알 길이 없으니 Windows XP 시절에는 저렇게 동작하고도 별 탈이 없었던 것 같다. 그런데.. 올해 초에 장만한 새 노트북에서는 곧장 문제가 발생했다.
운영체제는 틀린 정보를 토대로 역시나 내 프로그램을 상대로 잘못된 요청을 했다. 현재 텍스트에 존재하지 않는 행과 열에 접근하게 되었다. 담당 함수는 뻗지 않고 false를 되돌렸지만 내 프로그램은 그 상황에 대비가 되지 않았으며, 결국 초기화되지 않은 변수를 갖고 후속 처리를 하게 됐다.

이로 인해 확인된 이상 증세로는.. 길고 빽빽한 문서의 뒷부분을 작성할수록 속도가 느려지는 것, Ctrl+Z Undo의 수행 속도가 느려지거나 심지어 무한 루프에 빠지는 것이다. 논리적으로 꽤 치명적인 결함이고 crash가 발생해도 이상하지 않은데.. 이 버그는 의외로 많은 컴퓨터에서 외형적인 이상은 별로 일으키지 않았다. 괜히 늦게 발견된 게 아니었다.

어쨌든 문제를 발견하여 해결했으며, 이 참에 여러 군데의 텍스트가 동시에 수정되었을 때(찾기-모두 바꾸기, undo/redo, 여러 블록에 대한 지우기 및 텍스트 필터) 각 영역을 일일이 통지하는 게 아니라 영역을 모두 합성해서 한 번만 통지하도록 동작 방식을 수정하기도 했다.

4. -lock (caps, num, scroll) 글쇠에 램프 상태 유지 옵션 추가

날개셋 한글 입력기는 임의의 글쇠에다가 글자 입력이나 글자판 전환 같은 기능을 배당해서 쓸 수 있는데, 그 중에는 자체적인 켬/끔 램프가 존재하는 caps, num, scroll lock 글쇠도 포함된다.
이렇게 -lock 계열 글쇠를 customize해서 누를 경우, 날개셋에서 지정한 기능만 수행되고 램프 상태는 바뀌지 않게 하는 옵션이 추가되었다!

사용자 삽입 이미지

이 옵션은 편집기 계층의 단축글쇠, 또는 기본 입력 스키마가 제공하는 추가 인식 글쇠 배당 대화상자에서 볼 수 있다. 거기서는 각 글쇠별로 옵션을 지정할 수 있다.
그리고 추가적으로 고급 입력 스키마의 옵션에서도 지정할 수 있는데, 이건 한 곳에서만 지정하면 caps, num, scroll 글쇠를 customize할 때 모두 일률적으로 지정된다. 램프를 사용하는 글쇠가 딱 세 개밖에 없으며, 그렇게 자주 쓰일 만한 글쇠도 아니기 때문이다.

이들 램프가 켜지거나 꺼지는 건 키보드 하드웨어 차원에서 동작하는 강력한 기능이기 때문에 원래는 소프트웨어가 이래라저래라 제어할 수 없다. 램프 상태를 유지시키는 옵션은 날개셋 한글 입력기가 내부적으로 그 글쇠를 또 보내서 다시 꺼 버리는 식으로.. 좀 유치한 편법을 동원해서 동작한다. 하지만 그것 말고는 내가 알기로 IME 수준에서 할 수 있는 일이 없다. 키보드 드라이버 수준이라면 모르겠다만..

키보드에서 caps lock은 영문이 아닌 한글 입력 중엔 완전 잉여인 게 사실이다. 그러니 이걸 다른 용도로 사용할 수 없을지 고민하는 분들이 좀 계셔 왔는데.. 램프를 고정하는 옵션이 있으면 caps lock을 재활용하기 한결 수월해질 것이다.

5. 한글 표현 방식 탭.. 더 간소화

이건 실질적인 기능 추가나 버그 수정은 아니지만.. 지난 9.3 버전에서 크게 바뀌었던 한글 표현 방식 탭의 구조가 더 간소화됐다.
일반적인 환경에서는 진짜 씨크하게 현대 한글이냐 옛한글이냐 둘 중 하나만 고를 수 있게 했다.

사용자 삽입 이미지

여기서 '비표준 옵션도 표시'를 눌러야 한양 PUA니 유니코드 1.1이니 하는 레거시 옵션을 고를 수 있고, 거기서 또 '세부 옵션 표시'를 눌러야 종전의 세부 옵션들을 볼 수 있게 했다.

이번 새 버전도 많이 유익하게 사용되었으면 좋겠다. 올해 초까지 변함없이 후원도 해 주신 분이 계신 것에 감사드린다.
타자연습은 바뀐 것이 없지만, 이번에 한글 입력기의 소스 코드를 정리하는 과정에서 거의 쓰이지 않는 잉여 가상 함수를 하나 삭제하는 바람에.. 클래스 라이브러리의 바이너리 호환이 깨지게 됐다. 그래서 부득이하게 업데이트 됐다.

그럼 이제부터는 컴퓨터/프로그래밍 관련 여담을 좀 늘어놓고자 한다.

A. 키보드

뭐, PC 키보드에 존재하는 3대 lock 글쇠 중에서 존재감이 제일 없는 잉여는 두 말할 나위 없이 scroll lock일 것이다. 본인은 조금이라도 이걸 구분해서 동작하는 프로그램을 엑셀 말고는 지금까지 좀체 보지 못했다.
맥 계열 컴퓨터의 키보드에는 이게 존재하지도 않는다. 어지간한 노트북 키보드에서는 fn을 눌러야 접근 가능한 식으로 봉인됐다. pause 키처럼 말이다.

옛날 도스 시절에 하드웨어를 좀 특수하게 제어하는 게임은 caps/num/scroll lock을 눌러도 램프 상태가 변하지 않고, pause를 눌러도 컴퓨터 진행이 정지하지 않으며, ctrl+alt+del을 눌러도 시스템이 재부팅되지 않게 무슨 lock 같은 걸 걸어 놓고 돌아가긴 했었다. 그 옛날에 만들어진 황금도끼 도스용도 그런 프로그램 중 하나였었다. 그런 건 어떻게 구현했는지가 문득 궁금해진다.

GUI 환경에서 '복사'의 단축키로 워낙 잘 쓰고 지내긴 하지만 명령 프롬프트에서는 Ctrl+C가 프로그램의 실행을 중단하도록 인터럽트를 발생시키는 단축키였다. Ctrl+Pause(Break)는 Ctrl+C보다 수위가 더 강한 글쇠였고 말이다. 이건 소프트웨어적인 이벤트이기 때문에, 이 글쇠에 반응할지 말지를 지정하는 기능은 아마 도스 API 수준에서 있었지 싶다.

B. 명령 프롬프트에서의 문제

Windows용 한글 IME의 개발자로서 Windows의 명령 프롬프트는 참 기묘한 환경이다.
기본적으로야 운영체제가 기본 제공하는 TSF라는 인터페이스를 그대로 적용할 수 있지만 정확하게 들어맞지는 않는다. 다른 프로그램에서는 스펙에 명확하게 규정되지 않은 문제에 대해서 어떤 방법을 적용해도 동작하는데, 저기서만 미묘한 오동작이 발생해서 해결책을 찾느라 골머리를 썩인 적이 몇 번 있었다.

가령, 한글을 조합하고 있다가 다음 한글로 넘어갈 때 말이다. 지금 조합을 종료한 뒤 뒷글자 조합을 새로 시작할 수 있는가 하면, 지금 조합을 뒤에다 길이 0짜리 문자열로 유지한 뒤 그걸 재활용해서 뒷글자를 표현할 수도 있다. 마치 빈 문자열이냐 NULL이냐의 차이와 비슷한데, 어지간한 프로그램이라면 무슨 방법을 쓰든 동작이 동일해야 한다.

그런데 어떤 프로그램에서는 전자로만 해야 하고 후자 방법을 쓰면 조합이 씹히거나 끊긴다. 다른 프로그램에서는 후자로만 해야 하고 전자 방법을 쓰면 안 된다. 문제의 해결 방법이 프로그램별로 서로 다르기 때문에 IME의 소스를 더욱 지저분하게 만드는 주범 역할을 한다.
명령 프롬프트의 경우, 조합을 반드시 끊어야 하더라. 안 그러면 기존 글자가 지워지고 뒷글자로 덮어 써진다.

'새나루'는 본인이 개발한 날개셋과 더불어 오랫동안 3rd-party 한글 IME의 한 축을 담당해 왔지만 2010년대 이후로 버전업이 없이 개발이 사실상 중단됐다. 그 대신, 웬일로 한컴에서 Windows용 IME를 만들어서 아래아한글 2018에서부터 제공하기 시작했다. 한컴 IME도 명령 프롬프트에서 동일한 문제가 발생하던데, 난 이 문제를 겪어 봤기 때문에 원인을 안다.

C. 음절문자의 글쇠배열은?

한글이나 알파벳은 음소문자이다. 그렇기 때문에 글쇠배열을 적절히 만들면 양손이 각각 자음과 모음을 담당해서 최소한의 규칙성과 리듬감을 갖춘 형태로 타자를 할 수 있다.
그런데 자음· 모음 구분 없고 수십 종류의 음절이 제각기 서로 다른 글자로 배당돼 있는 일본어 히라/가타카나 또는 주음부호는 글쇠배열이 어떤 형태로 돼 있을까? 긴 글을 타자하는 경험은 어떠할까?

하긴 요즘은 대만에서도 주음부호 대신 한어병음을 더 가르치며 일본 역시 사람들이 어지간해서는 그냥 로마자로 발음을 입력하지, 골치 아픈 일본어 문자 전용 글쇠배열은 잘 쓰지 않는다고 듣긴 했다. 이거 뭐 삼성에서 훈민정음을 포기하고 Word로 갈아탔다는 것과 비슷한 얘기를 듣는 느낌이다.

Posted by 사무엘

2019/03/08 08:35 2019/03/08 08:35
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1594


블로그 이미지

그런즉 이제 애호박, 단호박, 늙은호박 이 셋은 항상 있으나, 그 중에 제일은 늙은호박이니라.

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2019/03   »
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31            

Site Stats

Total hits:
2634925
Today:
1723
Yesterday:
1754