날개셋 한글 입력기가 올해 최초의 새 버전이 나왔다. 우연히도 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 사무엘
