날개셋 한글 입력기 9.8, 그리고 타자연습 3.9가 4개월이 넘는 긴 공백기를 거친 뒤 드디어 완성되어 나왔다. 이번 버전은 버그를 엄청 많이 잡은 걸로는 역대 그 어떤 버전에도 뒤쳐지지 않지 싶다. 물론, 버그만 잡은 게 아니라 자잘하게 새로운 기능도 여럿 들어갔다.
한시름 놓긴 했지만 쉴 틈은 없다. 또 작업할 것들이 잔뜩 생기는 바람에 9.9는 무조건 나와야 하게 생겼다. 올가을쯤에 말이다. 박사 졸업하기 전까지 10.0은 없다는 게 내 당초 계획인데 계획이 간당간당해졌다. 당장 이번 9.8에도 새로운 작업 내역으로 인한 부작용과 결함이 발견되지 않길 바랄 뿐이다.
※ 외부 모듈
1. 악명 높던 크롬 버그
Chrome 브라우저의 버전 75 정도의 최신 버전에서부터 갑자기 한글 입력이 제대로 되지 않고 브라우저가 뻗기까지 하던 그 버그를 일단 해결했다.
처음엔 잘 동작하다가 나중 버전에서 문제가 발생했으면 그건 일차적으로 내 프로그램이 아니라 크롬의 문제이지, 왜 나만 갖고 그러는지-_-;; 본인으로서는 억울한 노릇이었다. 허나, 크롬은 워낙 널리 쓰이는 세계구급 프로그램이고, 마소 입력기나 심지어 아래아한글 2018과 함께 제공되는 한컴 입력기는 별 문제가 없는 듯하니 역시나 내 프로그램에 대해 유죄 추정의 원칙을 적용해야 했다.
이게 정말 난감한 문제이고 7월 중순이 다 돼서야 새 버전이 나올 수 있었던 이유는.. 크롬에게 맞게 내 프로그램을 수정하고 나면, 이미 맞게 동작하고 있는 다른 프로그램에서 교묘한 부작용과 문제가 발생했기 때문이다. 내 경험상 Windows에서 단일 로직만으로 모든 프로그램에서 잘 동작하는 외부 모듈을 만드는 건 거의 불가능하다. 답이 없다.
2. 암호 입력란 지원
크롬과 파이어폭스 브라우저에서 표시된 웹 페이지의 암호 입력란에서, 내 입력기가 영문 전용 모드로 바뀌지 않고 한글 입력이 된다는 것을 사용자 제보로 접수받아서 수정했다.
난 IE 말고 타 브라우저들은 크로스 플랫폼이고 에디트 컨트롤도 운영체제 보급이 아니라 자체 구현했을 정도이니.. 암호 입력란에서 IME가 동작하는 것 역시 일부러 그렇게 만든 것인 줄로 오랫동안 생각해 왔다. 그런데 얼마 전에 버그 신고가 들어온 걸 확인해 보니 내 입력기만 그렇게 동작하는 듯했다.;;
원인을 찾아보니, 영문 전용 모드로 동작하는 방법이 하나만 있는 게 아니었다. IE가 사용하고 날개셋도 인식하는 방법은 IME의 컨텍스트를 아예 지정하지 않는(null) 것이다. 그러나 크롬과 파이어폭스가 사용하는 방법은 컨텍스트를 주기는 하고, 거기서 disable이라는 속성을 추가로 주는 것이었다.
으음.. 이것도 표준 스펙이라고 명시는 돼 있지만, 이건 지난 10년이 넘는 세월 동안 날개셋 한글 입력기가 3.x 버전부터 외부 모듈이 개발된 이래로 단 한 번도, 전혀 지원한 적이 없던 프로토콜이었다. 지원 안 해도 어지간한 타 프로그램들에서 문제가 없었기 때문이다. 그랬는데 이 프로토콜을 사용하는 프로그램을 거의 처음으로 마주치게 됐다.
3. 조합 종료 처리
일부 TSF 기반 프로그램 내부에서 한글 조합 중에 여러 외부 요인에 의해 조합이 종료돼야 하는데 제대로 되지 않던 문제를 해결했다. 날개셋 편집기 내부에서 '빈 입력 스키마'를 골라서 날개셋 외부 모듈을 사용하는 상황을 가정한다.
한글을 조합하는 중에 (1) 마우스로 프로그램 바깥을 클릭하거나 Alt+tab을 눌러서 딴 프로그램으로 갔을 때, (2) 도구모음줄로 '새 파일', '찾기/바꾸기' 같은 걸 눌러서 포커스가 바뀌었을 때, (3) '찾기/바꾸기' 대화상자에서 '찾을 문자열'을 열심히 입력하고 있던 중에 Alt+N을 눌러서 그 입력란의 텍스트가 전부 블록 잡혔을 때에 대해서 개선 작업이 행해졌다.
(1)과 (2)의 경우.. 조합을 종료하는 것 자체는 기술적으로 가능했다. 하지만 저것만 되게 만들어 놓으면 엑셀 같은 프로그램에서 한글 첫 타가 씹히고 조합이 끊어지는 부작용도 같이 발생하는 게 문제였다. 그래서 두 조건을 모두 만족하면서 MS IME와 동일하게 동작하는 방법을 알지 못해서 조합 종료도 포기하고 그냥 놔 뒀었는데, 요 최근에 두 조건을 모두 만족시키는 깔끔한 방법을 다행히 발견해 냈다.
(3)은 외부 모듈이 아니라 날개셋 자체 에디트 컨트롤 쪽이 동작이 개선됐다. 그 상황에서는 날개셋이 생성한 조합뿐만 아니라 운영체제의 외부 모듈이 생성한 조합도 종료시키도록 조치를 취했다.
그리고..
2글자 이상 단어 단위 한자 변환이 가능한 TSF 기반 환경에서 한자 키를 누른 상태에서 다른 프로그램으로 갔다가 돌아왔을 때..
블록이 잡혀 있던 그 한글 단어가 지워져 버리던 버그도 발견하여 고쳤다. 처음부터 이렇지는 않았는데 Windows 후대 버전부터 발생하기 시작한 것 같다.
※ 나머지 기능 강화/개선
4. 입력 도구의 내부에서도 마우스 휠 지원
과거에 Windows에 마우스 휠이 처음 도입됐을 때는 휠이 굴렀다는 메시지가 키보드 포커스를 받고 있는 윈도우로만 전해졌다. 그런데 입력 도구들은 태생적으로 키보드 포커스를 받지 않는 윈도우이니, 마우스 휠과는 인연이 전혀 없을 것으로 여겨졌다.
하지만 Windows 8인가 10부터는 마우스 휠 메시지가 키보드 포커스 윈도우가 아니라 여느 마우스 메시지처럼 마우스 포인터가 놓여 있는 윈도우에 전해지도록 동작이 수정되었다. 그래서 입력 도구도 휠 메시지를 받을 수 있게 되었기 때문에 이에 대한 처리를 추가했다.
이제는 문자표, 부수로 한자 입력, 한자 변환 UI 등에서 휠을 굴려서 목록을 스크롤 할 수 있기 때문에 해당 기능들을 사용하기가 더 편리할 것이다. 단, 휠을 누르는 건 지원하지 않고 굴리는 것만 지원한다.
5. 편집기: 토씨 자동 교정 기능의 강화
한국어에서 '야'는 여러 품사를 넘나들면서 모양도 카멜레온처럼 변하는 형태소이다.
- "이건 분명한 팩트야" (종결어미)
- "논리야 놀자" (호격조사)
- "바다야 평소에도 워낙 파도가 많이 치는 곳이니 논외로 하고.." (보조사)
그런데 얘는 '토씨(조사) 자동 교정' 옵션을 구현할 때 복병으로 작용한다. 호격조사일 때는 받침 있는 단어 뒤에서 '야'가 '아'로 바뀐다. 그러나 나머지 품사일 때는 '이야'가 되기 때문이다.
'을/를', '이/가', '와/과' 같은 것은 형태가 명백하고 규칙도 단순하지만, '야'는 '아'로 바꿀지 '이야'로 바꿀지를 자연어 처리 없이 텍스트 형태만 봐서는 판단할 수 없다.
날개셋 편집기의 바꾸기 기능은 전통적으로 '야'를 호격조사로만 취급해 왔는데, 이번 버전에서 다음과 같은 조치를 추가했다.
- 호격 조사의 치환은 조사 다음에 한글이 이어지지 않고 그걸로 어절이 정확하게 끝날 때만 하도록 했다. 즉, '해야 솟아라'는 '태양아 솟아라'로 바뀌지만, '해야솟아라'는 '태양야솟아라'로 남아 있는다.
- 그리고 '야' 다음에 윗첨자 1을 첨가한 '야¹'는 '이야¹'로 바뀌게 했다. '한글을 소리 나는 대로' 텍스트 필터에서는 발음 변환 방식에 변화를 주기 위해 힌트 부호를 사용하고 있는데, 비슷한 개념을 바꾸기 기능에도 도입한 것이다. 이건 굳이 어절의 끝이 아니어도 동작한다.
'야'뿐만 아니라 '요'도 비슷하게 중의적이다. '이요'와 '이오'는 윗첨자 ¹²를 덧붙여서 상호 교환되게 했다.
- "1킬로그램요" (보조사) 형태 변함없음
- "나는 길이요 진리요.." (연결어미) 이요/요
- "주동자는 나요" (종결어미) 이오/요
'이요' 말고도 많은 조사와 어미들이 받침 여부에 따라서 중간에 '이'가 삽입되거나 생략되는데.. (-이여, -이야, -이나마, -이랑, -이란...) '예요/이에요'도 지금까지 처리되지 않다가 이번에 조건을 추가했다.
6. 편집기: 대화상자 외형
문서의 인코딩을 선택하는 대화상자의 외형과 동작을 살짝 고쳤다. UTF-8의 경우 BOM을 집어넣을지 여부를 지정하는 옵션이 오랫동안 아래에 별도의 체크 상자로 존재했지만.. 이번 버전부터는 그냥 목록에 별도로 뜨게 바꿨다.
오랜만에 이 바닥을 손대는 김에 UTF16-"BE"(빅 엔디언)라든가, UTF32 지원도 추가할까 생각했다가 그냥 관뒀다.
먼 옛날에 김 경석 교수 연구실에서 개발한 도스용 '나랏말씀' 에디터가 문자를 빅 엔디언 방식으로 저장했다. 그래서 그걸 읽을 때는 UTF16-BE를 지원하는 MS Word를 불가피하게 이용하긴 했었다. 하지만 요즘은.. 빅 엔디언 자체가 컴퓨터 메모리에서(파일 말고) 보기가 극도로 힘들어져 있다.
UTF32도.. 메모리가 아닌 파일로는 볼 일이 없다시피할 것이다. UTF7이 완전히 듣보잡이 된 것처럼 말이다.
하긴, 인코딩 말고 줄 바꿈 문자도 구형 매킨토시에서 쓰이던 \r only는 완전 듣보잡 방식이 되긴 했다. \r\n 아니면 \n만 살아남았다.
그리고 '기타 가져오기' 대화상자에서 있는 파일 내지 URL 입력란에.. auto complete 기능을 추가했다.
이제는 매번 별도의 버튼을 눌러서 파일 열기 대화상자를 꺼내지 않고도 파일의 전체 경로를 오타 없이 빠르고 편하게 입력할 수 있을 것이다.
7. 데이터: 이모지 본뜨기용 글꼴 변경
이건 프로그램의 기능 변화는 아니고 단순히 기본 제공 설정의 변화이다만..
지난 9.6 버전부터 글꼴 본뜨기 스크립트에서 이모지 영역을 본뜨는 지시가 추가되었다.
본뜨는 대상 글꼴이 처음엔 Segoe UI Symbol이었는데, 이번 버전부터 이모지 전용 글꼴인 Segoe UI Emoji로 변경했다.
이 글꼴이 16픽셀과 24픽셀 모두 훨씬 더 큼직하고 시원스럽고 보기 좋다.
제어판의 시스템 계층에서 글꼴 본뜨기를 강제로 다시 한 뒤, 문자표에서 U+1F300대 글자들 모양을 비교해 보시기 바란다.
※ 자잘한 버그
8. 날개셋문자를 받아들이는 수식에서 32비트 범위를 넘는 큰 임의의 수가 저장되지 않던 문제 해결
글쇠배열 수식에서 ? : 연산자를 사용해서 어떤 조건에서는 H3|_R을, 다른 조건에서는 H3|R_을 되돌리게 하는 상황을 생각해 보자. "조건 ? H3|_R: H3|R_" 같은 수식을 곧장 떠올릴 수 있을 것이다.
그런데 얘는 좌변과 우변에 공통으로 H3이 있으니 사람에 따라서는 "H3|(조건 ? _R:R_)" 이런 형태도 떠올릴 수 있다.
물론 수식을 그렇게 쓰는 건 별로 효율적이지 않다. 전자는 H3|_R이 합쳐져서 내부적으로 하나의 상수로 처리되지만 후자는 | 연산이 굳이 따로 행해지기 때문이다. 또한 _R과 R_ 부분에서 접두사 H3이 분리되면 프로그램이 이것들을 상수 명칭으로 가려서 보여주지 않고 내부 값을 노출해 버린다. 즉, 사람이 알아보기 어려워진다.
하지만 그와 별개로 사용자가 그런 수식을 지정했으면, 지정한 대로 저장하고 불러오는 건 똑바로 돼야 할 텐데 지금까지 그게 제대로 되지 않았다. 종성은 32비트 범위를 넘어서 32~48비트대에 저장되는데, 접두사가 없으면서 내부적으로 32비트 영역을 넘어가는 큰 수는 프로그램이 저장하지 않았기 때문이다. 그냥 날아갔다.
날개셋문자 수식에서 접두사가 없는 숫자는 그냥 일반 유니코드 문자 하나로 처리되는데, 잘 알다시피 현재 유니코드의 코드값 한계는 32비트는 고사하고 21비트 남짓밖에 안 되니.. 그건 그냥 짤라먹어도 상관없다고 판단했던 것이다. 하지만 그 숫자가 밖에서 다른 접두사와 결합해서 한글이 될 수도 있다는 것을 지금까지 고려하지 않았다. 이 문제를 발견하여 해결했다.
9. 타자연습
계정을 새로 생성하면서 사용할 글자판을 세벌식으로 지정했는데.. 그게 전혀 반영되지 않고 그냥 날개셋 편집기를 설치 직후 처음 실행했을 때와 같은 한영 글자판 두 쌍과 빈 입력 스키마가 지정되던 문제를 발견하여 해결했다. 꽤 오랫동안 존재했던 문제이나, 새 계정 등록이라는 게 일상적으로 자주 벌어지는 일이 아니니 버그가 생긴 줄 모르고 있었다.
이로써 타자연습은 게임 관련 개선, 이 버그 수정, 그리고 연습글 몇 편 추가로 새 버전의 명분이 충분히 갖춰지게 됐다. 장정 10여 년 만에 3.x 버전을 졸업할 때가 됐다.
※ 여담
(1) TSF 구현체
이번 버전에서는 개인적으로 임의로 만들어 사용해 온 'TSF A급'이라는 용어를 프로그램 도움말에서 모두 삭제했다. 그 대신, 그냥 'TSF 기반, TSF 지원'이라고 표현을 더 자연스럽게 바꿨다. 즉, 한글 입력만 가능한 게 아니라 단어 단위 한자 변환이 지원되고 이미 완성된 글자까지 자유자재로 고칠 수 있는 환경을 그냥 'TSF 기반'이라고 일컫기로 한 것이다.
과거에, 대략 Windows XP처럼 운영체제의 프로토콜이 IME에서 TSF로 바뀌던 과도기에는 TSF A급뿐만 아니라 B급이라는 개념도 있었다. 이건 TSF 방식으로 개발된 외부 모듈을 지원하긴 하지만 기술 수준이 여전히 IME 수준밖에 안 되는 환경으로, MS Office 중 워드 말고 엑셀, 파워포인트 같은 프로그램이 여기에 속했다.
그러나 Windows Vista부터는 IME 프로토콜이 사실상 폐지되고 모든 프로그램이, 심지어 재래식 WM_IME_* 메시지밖에 모르는 레거시 프로그램이라도 운영체제 차원에서 호환성 layer을 통해 반쪽짜리로나마 trivial하게 TSF 모듈을 구동한다. 그렇기 때문에 TSF B급이라는 프로그램을 따로 구분할 필요가 전혀 없어졌다. 이제는 TSF를 native하게, non-trivial하게 온전히 지원하는 프로그램만을 간편하게 'TSF 기반'이라고 부르면 충분하다고 여겨진다. 굳이 'A급'이라는 말을 붙일 필요가 없다는 것이다.
지난 10여 년이 넘는 기간 동안 이런 TSF 기반 입력 환경은 MS Word, 워드패드, 날개셋 편집기 같은 극소수 프로그램만의 전유물로 여겨져 왔다. 하지만 2010년대 중후반부터는 마소가 아닌 타 진영에서 만들었고 크로스 플랫폼 형태이기까지 한 프로그램에서도 TSF 기반의 텍스트 입력란을 종종 보게 되었다. 흥미롭고 고무적인 현상이다.
파이어폭스 브라우저는 놀랍게도 어느 샌가 온전한 TSF 기반으로 바뀌었다. 크롬도 cursor 이동이 제대로 처리되지 않고 여전히 공식적으로는 온전한 TSF 기반이 아닌 것으로 인식되지만, 언제부턴가 인접 글자가 무엇인지 얻어 오는 것은 되어서 한자 변환이 단어 단위로 된다. 이런 분야를 작업하는 사람들은 미국보다는 역시나 대부분 중국· 일본의 프로그래머라고 한다.
하지만 마소가 공식적으로 문서화하고 있는 TSF 스펙은 온갖 복잡한 상황에서 IME의 세밀한 동작을 규정하고 있지는 않다. 그렇기 때문에 또 온갖 파편화된 TSF 구현체들로 인해 자잘한 오동작과 버그, 무질서함은 IME 스펙만 있던 시절에 비해 더욱 올라갈 가능성이 높다. 앞으로 제2, 제3의 크롬 버그가 또 발생하지 말라는 법이 없어 보인다. -_-;;
(2) 페이스북 메신저의 회신 지연
본인은 날개셋 한글 입력기 관련 연락 통로를 이메일(비공개), 그리고 프로그램 다운로드 사이트에 같이 딸려 있는 페이스북 플러그인(공개) 이렇게 둘을 운영하고 있다.
페이스북 플러그인이 뜨는 곳에다가 "문의는 이곳(공개적으로) 또는 제 개인 메일(사적으로)로 해 주십시오. 페이스북 쪽지는 거의 확인하지 않기 때문에 대응이 늦어집니다"라고 써 놓았다.
하지만 최근에 우연히 쪽지를 확인하다가 거의 4개월, 6개월 전에 발송됐던 프로그램 문의 쪽지를 보고는 망연자실해서 해당 발신자 분에게 사과와 함께 답장을 보냈다.
페이스북은 모르는 사람에게서 온 쪽지는 왔다고 안내를 띄워 주지를 않더라. 그래서 쪽지가 온 줄도 모르는 채로 시간이 그렇게 가 버리는 것이다.
이 자리를 통해 다시 당부드리지만 프로그램 관련 문의는 메일이나 페이스북 플러그인, 아니면 하다 못해 이런 글의 댓글을 이용해 주시기 바란다. 방명록은 그런 용도로 있는 공간이 아니고, 페이스북 쪽지는 내가 언제 확인한다는 장담을 할 수 없기 때문이다.
Posted by 사무엘
