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

날개셋 한글 입력기 9.82가 어제, 9.81 이후 딱 두 달 만에 완성되어 나왔다. 딱히 원조가카의 서거 40주년에 맞춘 것은 아니다. 24일이나 25일에 완성을 못 했기 때문에 26일에 완성하게 됐을 뿐이다.

원래 생각 같아서는 아예 이 달 초 한글날쯤에 공개하고 싶었다. 그러나 답이 없는 지독한 버그(알고 나면 별것 아니지만..)와 컨디션 조절 실패 때문에 일정이 늘어져서 그보다 훨씬 더 늦게 나오게 됐다.

이번 버전은 눈에 띄는 기능 추가가 아니라 개선과 버그 수정 위주이다. 그러니 버전 번호도 0.01만치만 증가했다. 그리고 타자연습은 변화가 없으며, API 호환성도 달라지지 않았다.
그럼에도 불구하고 이번 9.82는 유의미한 변화를 열거하라면 꽤 많다. 특히 외부 모듈 내지 입력 도구 UI와 관련된 것이 많다.

1. 한자 변환 UI 관련

(1) 바로 직전 버전인 9.81부터는 MS Word의 우클릭 메뉴를 통해서 단어 단위로 한자 변환을 할 수 있게 되었다. 그런데 한자를 고르지 않고 ESC를 눌렀을 때 블록으로 잡힌 단어가 사라지는 문제를 비롯해 몇몇 사소한 glitch들이 있던 것을 바로잡았다. 오랫동안 본인의 심기를 건드려 온 찝찝한 문제였는데 드디어 해결되어 기쁘다.
또한, 단어의 앞부분 일부만 한자로 바꾼 뒤에 cursor가 다시 원래 있던 뒷부분으로 되돌아오는 것도 날개셋 편집기 내지 MS IME와 동일하게 처리되게 했다.

(2) 한자 변환 UI의 선택막대를 더 큼직하게 키웠다. 특히 간격이 하드코딩된 픽셀수로 지정되어 있어서 화면 DPI가 올라갈수록 실질적인 간격이 말도 안 되게 좁아지던 문제를 해결했다. 이제 high DPI 환경에서도 한자 변환 기능을 사용하기가 더 수월할 것이다.
아래 그림은 각각 100%와 150%배율에서 before와 after 모습이다.

(3) 그리고 키 동작 방식을 MS IME의 UI와 더 일치하도록 바꿨다.
가령, space로도 항목을 이동할 수 있으며, 화살표 키로 선택막대가 페이지의 시작이나 끝에 도달한 뒤에는 다시 끝이나 시작 지점으로 순환되게 했다. 또한, page up/down을 눌렀을 때는 선택막대가 해당 페이지의 맨 처음 지점에 가게 했다.

(4) 끝으로, 아까 저 한자 변환 UI 그림에서 '기사'의 위치를 보면 유추할 수 있듯, cursor의 아래에 나타나는 모든 UI들이(입력 도구).. 창 테두리가 아니라 창 내부 글자가 cursor의 바로 아래에 나타나도록 표시 위치를 조정했다. 아래 그림에서 위는 before이고, 아래는 after이다.

또한, 목록에도 불필요하게 여백이나 스크롤 영역이 생기지 않도록 초기의 창의 크기가 더 정확하게 계산되게 했다. 그 차이도 위의 그림에서 이미 묘사되어 있다.
옛날에는 이런 게 왜 눈에 들어오지 않았던가 모르겠다.

2. 엑셀에서 입력 도구의 특이한 오동작

날개셋 한글 입력기가 제공하는 입력 도구 중에는 GUI 요소에 콤보 상자가 들어있는 것이 있다.
'부수로 한자 입력'에서 부수의 획수를 고르는 UI, 그리고 '문자표'의 위쪽에서 글꼴과 문자표 종류를 고르는 UI 말이다.

그런데 MS Excel에서 날개셋 외부 모듈을 구동한 뒤, 여기서 저런 입력 도구의 콤보 상자를 눌러서 열고 나면 몇 초 못 가, 혹은 심지어 마우스 포인터를 살짝 움직이기만 해도 열었던 콤보 목록이 저절로 닫혀 버리곤 한다. 그래서 글꼴이나 획수 같은 걸 제대로 선택할 수 없다.
이건 다른 프로그램들은 괜찮고 오로지 엑셀에서만 발생하는 문제이다. MS Word에 black blank 문제가 있는 것처럼 Excel도 특이한 동작 방식이 존재하는 셈이다.

이것 때문에 본인은 며칠을 끙끙대며 헤맸으며, 그 과정에서 입력 도구 UI 엔진의 여러 미세한 버그들, 불필요한 코드 따위를 제거하는 부수적인 효과를 내긴 했다. 그러나 이 문제는 근본적으로는 엑셀이 굉장히 특이하게 동작하면서 날개셋 한글 입력기의 동작까지도 교란하기 때문에 발생한다.

심지어 마우스 휠을 굴렸을 때의 반응도 다르더라.
요즘 Windows에서는 입력 도구에서 마우스 휠을 굴리면 그게 입력 도구로 가는 반면, 엑셀에서만은 여전히 이전 버전 Windows처럼 휠 이벤트가 엑셀 창으로 간다.
내 추측으로는 쟤들도 마우스 관련 훅킹이라도 해서 마우스 포커스를 가로채는 것 같다.

엑셀에서 콤보 목록이 닫히는 문제는 엑셀의 버전에 따라 양상이 둘로 나뉜다.
첫째, 2007 초창기 버전과 그 이하의 구버전에서는 그냥 콤보 상자를 누르고 가만히만 있어도 몇 초 후에 목록이 닫힌다. 이건 근본적인 해결이 불가능하며, 저 예외적인 상황만 감지해서 어거지로 보정하는 것도 가능하지 않다.

둘째, 2007 SP3쯤과 2010 등 이후 버전에서는 콤보 목록을 연 뒤 마우스 포인터를 살짝 움직이면 목록이 닫힌다. 이건 다행히 내 프로그램에서 동작을 변경함으로써 해결 가능한 것을 확인했으며, 이번 9.82 버전에서 반영됐다. 최신 버전에서 해결 가능한 문제이니 이 문제는 사실상 해결된 것이나 마찬가지이다.

그리고 정사각형 문자표가 있는 입력 도구들(부수, 문자표, 이모지..)을 마우스로 클릭하고 잠시 있으면 확대된 글자를 잘 보라고 마우스 포인터가 사라지는데..
이때도 엑셀에서는 알 수 없는 이유로 인해 포인터가 사라지지 않곤 했다. 사라졌다가도 마우스 포인터를 살짝 움직이면 다시 나타났다.
그 문제를 이번에 덤으로 해결했다. 마우스 포인터를 숨기는 방법을 바꿨다. 이건 콤보 목록이 닫히는 문제와는 별개의 문제였다.

참고로, 당연한 말이지만 외부 모듈이 아니라 입력 패드에서 입력 도구들을 꺼내면 Excel에서도 아무 차이 없이 입력 도구들을 사용할 수 있다. 얘는 아예 별도의 프로세스에서 입력 도구를 구동한 것이기 때문이다.

3. 아래아한글에서의 미세한 문제

아래아한글은 MS Word와 달리 전통적으로 TSF를 지원하지 않는 불모지였다. 그런데 2018을 뒤늦게 써 보니 여기에도 변화가 느껴졌다. 비록 문서 본문은 변함없지만 대화상자의 텍스트 입력란에서는 TSF가 지원되기 시작했기 때문이다. 마소나 날개셋 한글 IME에서 단어 단위로 한자 변환을 할 수 있으며, backspace 달라붙기 같은 기능들이 모두 제대로 동작한다.

2010년대 중반이 되니 유니코드 5.2 방식의 옛한글 글꼴이 운영체제 차원에서 완전히 정착했고, 2010년대 후반이 되니 날개셋 말고도 TSF 기반의 한글 IME가 만들어져 나오고 심지어 TSF를 지원하는 텍스트 에디팅 엔진도 나오는구나 하는 생각이 든다. 뭐, 아래아한글의 경우, 문서 본문에도 TSF를 지원하는 건 여전히 쉽지 않을 것이다.

다만, 이렇게 아래아한글에 TSF 기반 텍스트 입력란이 구현되면서 날개셋 한글 입력기와도 충돌을 일으키기 시작했다. 버그 내지 오동작 의심 증상이 무려 세 가지나 있었는데, 이것 때문에 개인적으로 굉장히 힘든 나날을 보냈다.

• 첫째는 그냥 답이 없는 문제였다. 안 그래도 동작 방식이 A형 B형 둘로 나뉘어 있는데, 아래아한글은 이미 알려진 다른 유형인 B형으로 인위로 보정을 해 줘야 했다.
  
• 둘째는 프로그램이 뻗을 수도 있는 제일 치명적인 문제인데, 엄~밀히 말하면 내 입력기의 버그가 맞았다. 조합 상태가 아니면 그냥 조합을 완전히 해제해야 하는데 빈 조합으로 남겨 놓고 있었다. 하지만, 그런 결함이 있다고 실제로 이상한 문제를 외형적으로 일으키는 프로그램은 아래아한글이 처음이었다.
  
• 마지막 셋째는 도대체 왜 내 입력기를 쓸 때만 이상하게 동작하는지 알 길이 없었는데, 알고 보니 일반적인 상황에서는 발생할 일이 없는 문제라는 것을 최종 확인했다. 간단하게만 말하자면 날개셋이 제공하는 한자 변환 기능과, 아래아한글이 자체적으로 제공하는 한자 변환 기능이 충돌하는 문제이다.

세 문제가 원인과 해결책이 전부 저 정도로 제각각으로 달랐다. 그래도 어쨌든 다 해결되니 기쁘다.

4. 크롬과 에지

(1) 마소의 Edge 브라우저가 크로뮴 기반으로 재개발(?)되고 있으며, 현재 베타 버전이 공개돼 있다. 그런데 얘는 크롬과 동일한 엔진(크로뮴) 기반이어서 그런지 예전의 크롬과 동일하게 조합 중인 글자가 덧나는 버그가 있었다. 이에 대한 보정을 추가했다.

(2) 그리고 크롬도 최근에 버전 78로 업데이트가 됐는데.. 생뚱맞게도 자신이 Metro 앱이라고 IME에다가 알려주고 있었다.
Metro 앱 환경에서는 통상적인 데스크톱 GUI가 제공되지 않기 때문에 날개셋 제어판을 꺼낼 수 없다. 그렇기 때문에 이 환경에서는 내 프로그램 역시 제어판을 여는 버튼을 disable시켜 버린다.

그런데 본인이 확인해 본 결과, 크롬과 Edge 베타 모두 말은 그렇게 해도 데스크톱 GUI의 구동에는 문제가 없었다. 그렇기 때문에 이번 버전에서는 저 프로그램에서 제어판이나 각종 대화상자들을 변함없이 열 수 있게 보정을 추가했다.

5. 외부 모듈의 응용 프로그램별 수동 보정 옵션

이 기능은 오래 전부터 날개셋 한글 입력기에 도입할까 말까 망설였는데.. 크롬 버그 이후로 갈수록 증가하는 glitch 신고를 계기로, 더는 대세를 거스를 수 없겠다 싶어서 결국 구현하게 되었다.
무엇인고 하니, 날개셋 한글 입력기가 응용 프로그램마다 호환성 차원에서 일부러 다르게 보정해서 동작하는 세부 알고리즘을 외부에 노출하고, 사용자가 프로그램별로 이를 수동으로 customize 할 수 있게 하는 것이다. 내부에 하드코딩 되어 있던 보정 규칙 테이블이 이 기회에 개방되었다.

Windows용 한글 IME라는 건 단일 로직으로 모든 프로그램에서 정확하게 동작하는 것이 불가능하다는 것이 확실시되고 있다. 크롬 브라우저와 MS Word는 걔네들에게만 적용되는 고유한 보정이 존재하고, 그것 말고도 전반적이 통신 방식이 크게 A와 B라는 두 갈래로 양분되어 있다.
어느 방식으로 통신하나 잘 동작하는 프로그램도 물론 있고 그래야만 정상이지만.. >_< 현실에서는 둘 중 한 방식을 거부하는 프로그램도 있다.

특히.. 지난번 9.8 시절의 크롬 버그를 잡고 그 방법을 다른 프로그램에다가도 범용적으로 적용시켰더니.. 기껏 지금까지 잘 돌아가던 모 프로그램에서 부작용이 발생하더라는 연락을 개인적으로 받기도 해서 멘붕했다.
아, 여기서 버그나 오동작이라는 건 한글 입력 자체가 안 된다기보다는 IME의 문자 입력 이벤트에 응용 프로그램이 반응을 제대로 못 해서 글자가 덧난다거나, 조합 중인 문자열이 사라진다거나 하는 glitch들을 말한다.

이제 제어판의 '시스템 계층'을 보면 "한글 표현 방식"과 "고급 시스템 옵션"의 아래에 "프로그램 호환성"이라는 카테고리가 하나 더 추가되며, 지금 당장 실행돼 있는 프로그램을 대상으로 통신 방식과 몇몇 보정 방식을 변경할 수 있다.

'대상 프로그램'은 지금 날개셋 IME가 동작하고 있는 프로그램이 가장 먼저 제시된다. 하지만 콤보박스를 열어 보면 현재 실행돼 있는 프로그램 또는, 실행되지 않았더라도 보정 정보가 등록된 프로그램을 고를 수 있다. 프로그램은 그냥 실행 파일 이름으로 식별한다.

앞으로 미묘하게 뭔가 잘 동작하지 않는 프로그램을 발견한 경우, 어지간해서는 '프로그램과 통신하는 방식'을 A에서 B로 바꿔 보시기 바란다. 응용 프로그램별 세부 보정은 해당 프로그램 외에서는 크게 쓸 일이 없을 것이다.

이로써 날개셋 한글 입력기는 글쇠배열은 말할 것도 없고 한글 입력 오토마타, 낱자 입력 규칙, 한영 전환 글쇠를 포함해 옛한글의 표현 방식에다 이런 응용 프로그램별 보정 방식까지도 customize 가능한 흠좀무한 프로그램이 되었다.

6. 나머지, UI 차원에서 사소하게 개선된 것들

(1) 편집기의 계산기에서 입력된 수식에 오류가 있는 경우, 에러 메시지를 더 구체적으로 표시하게 했다. 그리고 계산 결과를 무조건 10진법, 16진법 또는 상수 명칭 형태로 출력하는 게 아니라, 입력된 상수의 형태를 따라서 유동적으로 출력하는 모드를 추가했다. 100+100은 200이지만 0x100+100은 0x164이고, 'a'+3은 'd'가 되는 식으로 말이다. 이게 기본 상태이다.

사실, 계산기 기능이 아니라 날개셋 제어판 같은 다른 곳에서는 수식을 이렇게 더 자상하게 취급하는 기능이 이미 제공되고 있었는데 계산기로 도입이 다소 늦었다.
그리고 변수에는 언제나 값만 저장되지 대입된 상수의 형태가 저장되지 않는다. 그래서 'a'+1은 'b'라고 출력되지만, A='a'는 출력 방식이 특별히 지정되지 않은 한 그냥 97이라고 출력된다.

(2) 문자표 도구에서 "글꼴이 지원하는 모든 BMP 문자"를 지정했을 때 바탕, 굴림 같은 글꼴에서 공백(U+20) 미만의 제어 문자들이 앞에 표시되지 않게 했다. 그리고 영역 구분을 A 이상 B '미만'으로 해야 하는데 B '이하'로 하는 바람에 쓸데없이 깨진 문자가 하나씩 포함되던 문제를 이제야 발견해서 뒤늦게 해결했다.

(3) 부수로 한자 입력 도구에서 부수 목록은 화면의 확대 배율과 무관하게 언제나 한 줄에 5개씩 표시되게 했다. 150% 배율에서는 폭 계산이 이상하게 돼서 줄당 4개씩 표시되고 여백이 남아서 보기가 무척 안 좋았는데 이를 개선했다.

(4) 제어판의 '시스템 계층'에서 한자 출력용 글꼴을 수동 지정하는 콤보 상자에는.. 사용자의 선택을 돕기 위해 CJK 언어를 지원하는 글꼴들만 목록에 등록돼 표시된다.
그런데 이 목록에는 몇몇 글꼴이 누락되곤 했다. 가령, 한자 출력용으로 손색이 없는 Noto Sans CJK 같은 글꼴은 설치돼 있어도 표시되지 않았다. 정확한 이유는 알 수 없지만 운영체제가 얘를 평범한 트루타입 글꼴로 분류해서 조회해 주지 않았던 것이다.

이 문제를 해결하여 저런 글꼴도 목록에 등재되도록 했다. 다만, 목록 등재 여부를 떠나서 사용자가 이 글꼴 이름을 딴 데서 복사해서 강제로 지정해 주면 지금도 그 글꼴을 지정 자체는 할 수 있다.

(5) 날개셋 한글 입력기는 각종 단축글쇠에서 shift, ctrl, alt, win의 조합을 modifier로 지원한다. 다만, 편집기와 입력 패드 같은 자체 환경 말고 외부 모듈(IME)에서는 운영체제의 동작 특성의 차이로 인해 alt가 사실상 지원되지 않는다. 그래서 외부 모듈에서 단축글쇠 편집 대화상자를 꺼내면 alt를 조절하는 슬라이더는 disabled 상태로 나타났는데...

이번 버전에서는 그에 덧붙여 사용자가 alt를 할당할 경우 이렇게 풍선 도움말로도 추가적인 안내를 하게 했다.
프로그램에 따라서는 alt는 안 되면서 ctrl+alt 조합은 인식되는 경우도 있는데, 이것도 모든 프로그램에서 다 되는 건 아니다. 그러니 일반적으로 alt는 사용할 수 없다고 생각하는 게 속 편하다.

7. 나빌 한글 입력기와 3-18Na 입력 방식

지난 2000년대에는 '새나루'라고 Windows용 오픈소스 한글 IME 프로젝트가 있었다. 얘는 Windows XP 시절을 풍미하면서 활발하게 개발돼 왔지만 개발이 중단되고 2010년대부터는 맥이 끊어졌다.
그런데 바로 올해엔 어느 용자 능력자께서 '나빌'이라는 한글 IME를 개발하여 오픈소스 진영에 기여했고, 두벌식 글쇠배열 기반으로 신세벌식 원리(중성· 종성 중첩)를 적용한 자기 나름의 새로운 한글 입력 방식까지 제안해 놓았다. 컴퓨터 아키텍처 쪽으로 책도 쓴 유명한 분이던데..

내가 저분의 개발 후기를 읽으면서 정말 놀라고 감탄한 것은.. 세벌식 자판부터 시작해서 Windows 프로그래밍과 새로운 TSF 스펙, 예제 코드까지.. 나라면 몇 주 몇 달 이상을 끙끙대며 삽질했을 새로운 지식과 정보들을 단순히 잉여질(?)만으로 그 짧은 시간 만에 몽땅 습득하고 응용해서 새로운 결과물을 뚝딱 내놓았다는 점이다.
난 정말 무식하게 오래 질질 끌고 한 우물만 오래 팠기 때문에 이 정도 경험과 기술이 축적된 거지, 밑바닥부터 시작하면 절대로 저렇게 못 했을 것이다.

인간의 창의성과 지적 능력의 끝이 어디인지를 다시 생각하게 된다. 이번 버전에서는 3-18Na 입력 방식을 내 프로그램의 설정 예제로 구현해서 추가했다.

아이고 글이 또 왜 이리 길어졌나..? 아무튼, 이번 버전도 유용하게 사용하시기 바란다.
홈페이지의 트래픽을 관리하기 위해 64비트 바이너리는 여전히 Google Drive 링크로 제공하고 있다. 하지만 내 홈페이지에도 파일 자체는 올라와 있다. *_x86.msi 대신 *_x64.msi로 말이다.
그나저나 페이스북 의견 페이지가 왜 또 안 뜨고 있나 모르겠다.

Posted by 사무엘

날개셋 한글 입력기 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 사무엘

올해가 벌써 절반이 끝나 가는구나.. ㅠㅠ 오늘은 오랜만에 프로그램 개발 소식을 전하도록 하겠다. 날개셋 한글 입력기 9.8과 타자연습 3.9가 일단은 다음 달, 즉 7월 초/중순 쯤에 나올 예정이다.
4~5월쯤에 9.71 형태로 나왔어야 할 물건이었으나.. 온갖 곳에서 고치고 개선할 점들이 잔뜩 튀어나오는 바람에 일정은 한없이 늘어나고 버전도 0.1 더 오르게 됐다.

새 버전이 지금 나왔다는 말이 아니니 오해 없으시기 바란다. 이 글은 내부적으로 작업이 완료된 것들만 늘어놓은 것이다. 새 버전이 완성되어 실제로 업로드될 즈음에는 다른 개발 아이템들이 더 추가되어 있을 것이다. 난 예나 지금이나 날개셋 한글 입력기 코딩을 할 때 내가 살아 있음을 느끼고 삶의 의미와 목적을 느낀다.

1. 오동작· 안정성과 관계 있는 버그

(1) 날개셋 제어판에서 빠른설정을 적용하는 등 입력 설정을 이것저것 바꾼 뒤 닫을 때 프로그램이 가끔 뻗던 버그는 이미 지난 4월에 문제의 원인을 파악해서 해결했다.
지난 9.5쯤부터인가, 화살표 키로 제어판의 카테고리를 이동할 때 페이지가 곧바로 표시되지 않고 약간 뜸을 들인 뒤에 표시되기 시작했는데(UI 반응성의 향상을 위해), 그 동작의 부작용 때문에 그런 문제가 발생했던 것이었다. 문제의 정확한 발생 조건을 찾기가 굉장히 어려웠다.

(2) 아울러, 편집기에서 다른 TSF 방식 외부 모듈을 구동해서 한글 조합을 만들었다가 끊기를 반복할 때 memory leak가 발생하던 것도 비슷한 시기에 해결됐다. 원인은 내가 짠 코드의 COM object 관리 잘못 때문이라고 허무하게 판명되었다.
옛날 버전까지 다 구해서 추적해 보니 8.2 또는 8.4 버전쯤부터 슬며시 생겼던 문제이다. (8.0 문제 없음, 8.4 있음.. 8.2는 구해 보지 못함) 그러니 대략 2016년쯤에 작성한 코드에 버그가 들어간 셈인데, 너무 옛날이어서 내가 그 시절의 코드 스냅샷까지는 갖고 있지 않았다. 결국 에디팅 엔진을 통째로 다 뜯어내고 전수조사를 벌여야 했다.

내 프로그램 코드에서 어지간한 포인터들은 RAII 이념에 충실하게 몽땅 smart pointer 역할을 하는 클래스로 감싸 놨다. 그렇기 때문에 소멸자에서 알아서 해제가 되며, 무식한 memory leak 같은 게 발생할 여지는 거의 없다.
하지만 포인터가 타 구조체의 멤버로 들어있거나, 포인터를 얻는 함수로 종료 조건으로 삼아서 뺑뺑이를 돌 때(while, for문)는 이런 자동화의 혜택을 받지 못한다. 이번 버그도 그런 사각지대에 존재하고 있었다.;;

(*) 최근엔 크롬 브라우저에서 날개셋 한글 입력기가 제대로 동작하지 않고 프로그램이 뻗는다는 버그 신고가 곳곳에서 들어와 있다. 크롬이 버전 74쯤부터 과거에 존재하던 버그가 고쳐져서 뭔가 좀 개선이 됐나 싶었는데.. 그 대신 다른 문제가 생긴 것 같다.
특히 신세기 님께서 제작하신 세벌식 모아치기 설정을 사용했을 때 크롬이 뻗는 것은 본인도 확인했다. 하지만 뻗은 지점이 내 코드가 아니라 크롬의 코드인지라.. 원인이 정확하게 무엇인지, 문제를 피해 갈 방법이 무엇인지는 아직 잘 모르겠다. 혹시 타이머 때문인가 추측만 할 뿐이다.

(*) 똑같은 영문인데 어떤 프로그램에서는 글쇠를 IME가 가로채지 않고 그대로 넘겨 줘야 정상 동작하고, 어떤 프로그램에서는 반드시 가로채 줘야 정상 동작하는 경우가 있다.
얼마 전엔 인디자인에서 한글 조합 중의 space/enter 키 인식 문제 때문에 본인에게 문의를 하신 분이 있었다. 인디자인은 여전히 몇 년째 그 버그가 고쳐지지 않고 있는가 보다.

사실, 글쇠를 IME가 가로채든 그렇지 않든.. 원래는 문자 입력 기능의 동작에 차이가 있어서는 안 된다. 그리고 사실 어찌 보면, 일부러 다르게 동작하게 만드는 게 더 어렵다.
하지만 한중일 언어나 문자 따위 모르는 외국인의 입장에서는 IME 인식하며 동작하는 프로그램에 대한 지식이 부족하고 정상적인 동작 모습을 상상하기 쉽지 않을 것이다. 그러니 이건 해당 프로그램이 고쳐지기를 바랄 수밖에 없는 노릇이다.

2. 안정성까지는 아니지만 그래도 사소하지 않은 버그

(1) 언제부턴가 문자 생성기가 기본이 아닌 고급인 상태에서 타이머 설정 대화상자를 들어가 보면 기존 타이머 설정들이 제대로 설정되지 않던 문제가 있었다. 곧바로 고쳤다.

(2) 날개셋 편집기에는 문자 영역 검색 기능이 있다. 굉장히 옛날부터 제공되었고 지금까지 큰 변화도 없는데, A<=0xFF, A==0처럼 아예 0문자가 조건에 걸릴 수 있게 수식을 주면 텍스트 블록이 이상하게 잡히면서 프로그램이 오동작한다. 이 버그를 이제야 발견해서 즉시 고쳤다.

3. UI

(1) 모든 대화상자들에서 명령 버튼의 기본 크기를 45*16 DLU 대신 47*15 DLU로 소폭 수정했다. 마소가 권장하는 50*14 dlu와 완전히 같지는 않지만 그에 좀 더 근접하게 바꾼 것이다. 버튼의 높이가 16 dlu이면 다른 한 줄짜리 에디트 박스와 비교해 봐도 솔직히 너무 크긴 했다.

(2) 고급 입력 스키마의 '고급 글쇠 인식' 페이지는 각 글쇠별로 down/up 상황에 대해 복잡한 수식을 설정하는 곳이다. 글쇠를 추가하거나 편집하는 UI를 별도의 대화상자로 만들어도 됐을 것 같으나.. 어쩌다 보니 동일 페이지에서 몽땅 설정한 뒤에 '추가'를 누르는 형태가 됐다.
한창 수식을 편집하고 있다가 왼쪽의 글쇠 리스트에서 다른 걸 찍는 순간 그 임시 데이터들은 몽땅 날아가 버린다. 이것이 직관적이지 못하다고 여겨진지라, "편집하던 내용을 반영/저장할까요?"라는 질문을 표시하게 했다.

(3) 외부 모듈(입력 패드도 포함)은 전용 환경인 편집기와 달리 한글 표현 방식을 따로 설정하는 곳이 있다.
이걸 옛한글이 아닌 현대 한글로 맞춰 놓은 상태에서 옛한글의 입력을 시도하면 지금까지는 간단한 주의· 경고문이 나타났다. 한 번 나타난 뒤엔 다시 나타나지 않지만, 현재 프로그램이 실행돼 있는 동안만으로 한정이고, 그 다음부터는 또 나타난다.

옛할글이 온전히 표시되지 못하고 첫 자음이나 모음만 나타나도 괜찮으니, 일부러 이런 설정을 일시적으로 사용하는 사람도 있다는 점을 감안하여.. 메시지 박스에다가 "다음부터 이 메시지를 표시하지 않음" 체크를 넣었다. 이걸 체크하면 최소한 다음에 제어판을 열어서 한글 표현 방식 옵션을 변경하기 전까지는 동일 메시지가 나타나지 않게 된다.
그리고 메시지를 '확인'이 아닌 '예/아니요' 형태로 바꿔서 그냥 즉석에서 설정을 옛한글을 사용하도록 변경할 수도 있게 했다.

(4) 제어판의 '시스템 계층'을 가 보면 다음에 편집기나 외부 모듈 같은 구현체 프로그램이 실행될 때 자동으로 띄워 놓을 입력 도구들을 선택하는 체크 상자가 있다.
이것은 지난 9.3 버전부터 추가된 옵션이다. 지금까지는 체크들을 모두 없애는 버튼만 있었는데.. 사실은 지금 사용자가 띄워 놓은 도구들을 그대로 다음에도 자동으로 띄우도록 하는 버튼도 있는 게 사용자의 입장에서 좋다.

그래서 그 버튼이 이번 9.8에서 추가되었다. 이걸 구현하기 위해서는 제어판 대화상자가 자신을 호출한 호스트와 통신하는 방식이 확장되고 고쳐져야 했다. 이 과정에서 코드가 더 깔끔하게 바뀌긴 했지만 타자연습도 API 호환이 깨졌다. 그래서 최신 버전을 쓰려면 입력기도 반드시 최신 버전을 써야 하게 됐다.

4. 입력 도구들의 깨알같은 개선점

(1) '휴대전화 입력기'의 숫자 모드에서 표시 형식을 전화기가 아닌 계산기를 선택했을 때.. 0과 그 주변의 숫자 배치를 실제 계산기에 더 가깝게 변경했다. 무성의한 , 0 . 대신 0 00 . 로 바꿨다.
글쎄, 콤마가 사라진 건 아쉽지만 계산기라면 0이 왼쪽에 가 있고 00이 있긴 해야 할 듯해서 말이다. 00이야 날개셋문자의 '다중 문자' 타입으로 간단히 구현 가능하다.

(2) '화면 키보드'에서 '눌린 글쇠 표시' 옵션을 켜면, Caps lock의 경우 램프가 켜진 것도 글쇠배열에 반영되어 보이게 했다. 이 간단하고 당연한 동작을 왜 지금까지 구현하지 않고 있었나 모르겠다.

(3) '조합 안에 조합 생성'의 '영문 T9 방식 입력'을 위한 DB가 지금까지 8~9글자짜리 짧은 단어밖에 없어서 불편했는데.. 이번에 최대 15자짜리 긴 단어도 대폭 추가했다. 그래서 DB의 내장 어휘 수와 파일 크기도 거의 2배 가까이 증가했다. international 같은 단어를 예전보다 더 편하게 입력할 수 있을 것이다.

(4) 예제로 제공되던 "천지인, SKY, Google 단모음 입력 방식"에 종성뿐만 아니라 초성도 시간차로 경계를 구분하는 로직을 추가했다. 이들 입력 설정에는 오토마타에 "B ? 2 : 0"라고 중성의 입력만 받아들이는 새로운 상태가 추가되었다. 초성만 입력된 상태에서 타이머가 경과하면 이 상태로 진입하게 된다. 임시 변수를 동원해서 글쇠배열 수식을 고치는 방식으로도 동일 기능을 구현할 수 있긴 하지만 그냥 오토마타를 고치는 게 더 단순하다.
그리고 '내부 입력 상태 표시' 도구에서.. 수식 계산만 하고 별도의 날개셋문자를 보내지 않는 타이머가 경과했을 때 변수 상태를 업데이트 해서 보여주지 않는 버그를 발견하여 이것도 고쳤다.

5. '한글 낱자 재결합'의 기능 개선과 강화

텍스트 필터 중에 '한글 낱자 재결합'이라고, 블록으로 잡은 한글을 낱자 단위로 분해한 뒤 다시 조합시키는 기능이 있다. 얘는 사용하면 동일한 타자 시퀀스인 한글을 모아쓰기/풀어쓰기, 복합 낱자/기본 낱자 등의 형태로 변환할 수 있다. '문자열을 글자판 입력으로 → 글자판 입력을 문자열로' 필터를 연달아 적용한 것과 비슷하지만, 얘는 한글이 아닌 문자를 제거한다거나 초중종 결합 여부와 순서를 더 세밀하게 지정할 수도 있다.

한글을 재결합하기 위해서는 먼저 분해부터 해야 하는데.. 지금까지는 그냥 평범하게 현재 입력 설정을 바탕으로 타자 순서를 구하는 식으로 분해했다.
그러니 세벌식의 경우, ㄻㅄㄲ처럼 글쇠가 별도로 존재하는 겹받침들은 더 분해되지 않았다. 그리고 지금 입력 설정에서 타자 순서를 구할 수 없는 낱자는 분해가 불가능하니 그 낱자를 그냥 통째로 취급했다. 가령, 현대 한글 입력 방식을 사용하면서 옛한글을 재결합 시켰을 때 말이다.

이번 버전에서는 '결합'은 현재 입력 설정을 따라서 하지만, '분해'는 입력 설정과 무관하게 그냥 그 한글 낱자의 기본 낱자 형태로 직관적으로 하는 옵션을 추가했다. 자음은 ㄱ~ㅎ과 ㅿㆆㆁ, 정치· 치두음, 모음은 ㅏ~ㅣ와 ㅐㅔㅒㅖ, 아래아 단위로 분해한다.

그래서 ㄻㅄㄲ은 초· 종성과 현재 입력 설정을 불문하고 언제나 ㄹㅁ, ㅂㅅ, ㄱㄱ의 형태로 분해된다. 낱자 결합 규칙과 오토마타가 전혀 없는 입력 설정에서 이 방식으로 한글 낱자를 분해하고 재결합하면 한글을 기본 낱자들로 늘어놓을 수 있다. 이건 회사 사람에게서 제안 받은 아이디어인데 꽤 의미 있고 유용한 기능인 것 같다.

그리고 다음으로, 예전과 같이 '타자 순서'대로 한글을 분해할 때, 종성 두벌식 방식의 한글이 제대로 처리되지 않던 문제를 해결했다. 예전에는 '한' 같은 글자를 재결합하면 ㅎ이 곧이곧대로 종성으로 인식되어서 중성 다음에 ㅏㅎㄴ 같은 식으로 결합됐는데.. 이 동작이 개선되었다.

6. 타자연습

(1) 다소 엽기적인 연습글인 이 상의 '오감도', 그리고 '영화 클레멘타인 감상평'을 연습글로 추가했다. "13인의아해가거리로질주하오"라든가.. "남친 집에서 클레멘타인 DVD를 발견했고, 결혼을 결심했습니다" 같은 문장으로 타자 연습을 할 수 있다.

(2) 예전엔 이런 현상이 없었던 것 같은데.. 게임을 창 모드에서 하다가 Alt+Enter를 눌러서 전체 화면으로 진입하면 첫 프레임은 화면이 전체적으로 몇 픽셀 offset되어 잘못 렌더링 되다가 그 다음부터 제대로 된다. 화면이 수시로 업데이트 되는 게임 중이면 별 상관 없지만, 첫 프레임이 "레벨 n 시작합니다" / "게임을 그만 할까요?" 같은 메시지 화면일 때는 다소 부자연스러운 glitch가 된다.
이 현상을 수정했다. 아마 Windows 8/10쯤에서 새로 발생한 부작용 같다.

(3) 그 외에 댓글로 올라온 의견과 제안을 반영하여 도움말의 일부 오타를 고쳤다. 그리고 게임에서 저장 가능한 상태 또는 이미 저장된 상태를 사용자에게 더 분명하게 알려주게 했다.
저장은 사용자가 게임에서 한 레벨 이상을 직접 깨서 다음 레벨로 진입한 다음부터 가능하다. 단, 레벨 2는 너무 낮고 쉬운 레벨이기 때문에 제외다. 저장되는 대상은 시작 레벨과 주인공 종류, 체력과 장갑, 점수이다. 게임 도중의 중간 상태는 저장되지 않으며, 저장 슬롯 자체도 단 하나만 만들 수 있다.

저장 기능 자체는 오랫동안 지원돼 왔으며 딱히 버그도 없었다. 단지 저장이 가능한 레벨이 시작되었을 때는 게임 시작 안내 화면의 우측 하단에 "F4: 저장"이라는 말을 작게나마 출력하게 했으며, 이때도 저장을 할 수 있게 했다. 그리고 게임 중에 사용자가 F4를 여러 번 누르면 "이 레벨의 시작 지점이 이미 저장돼 있습니다"라는 안내도 나오게 했다.

Posted by 사무엘

본인은 박사 과정에 진학해서 수업을 다 듣고 종합 시험도 통과한 뒤, 지난 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 사무엘

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

1. 새 노트북과 새 폰

본인은 2010년대 초중반까지 노트북은 맥북을, 폰은 삼성 안드로이드 폰을 사용해 왔다. 그랬는데 노트북은 이제 성능이 너무 뒤쳐졌으며 배터리 용량도 너무 감소했다.

그리고 폰도 하필 약정이 끝날 무렵부터 배터리가 급격히 빨리 줄어들기 시작했으며, 그로부터 몇 달 되지 않아 걸핏하면 툭툭 꺼지기 시작했다. 폰이 꺼지지 않도록 잘 간수하는(?) 게 마치 옛날에 집안 불씨가 안 꺼지게 간수하는 것 같은 일이 됐다. 서비스센터를 방문해 보니 배터리나 전원 단자 문제가 아니라 순전히 메인보드의 문제라는 말을 들었다.

이런 이유로 인해 본인은 2019년 초의 비슷한 시기에 전화기와 노트북을 모두 교체하게 됐다. 폰은 고맙게도 남아도는 준중고 기기를 그냥 주신 분이 직장에 계셔서 본인은 신규 개통도, 번호 이동도 아닌 기기 변경이란 걸 했다. 그리고 졸지에 생각지도 않았던 아이폰 유저의 대열에 합류했다.
그 반면, 노트북은 맥OS를 굳이 더 쓸 필요를 느끼지 않아서 오랜만에 국산 일반 Windows 기계로 복귀했다. 예전과 반대로 전화기를 애플 것으로 쓰게 된 셈이다.

내가 원하는 노트북 컴터는..
굳이 그렇게 무리하게 얇거나 가볍지는 않아도 된다. 화면 해상도도 그냥 Full HD 1920*1080 급이면 넉넉하고 충분하다. 굳이 2000 안 넘어가도 된다.

또한, 요즘은 무선 인터넷 인프라가 워낙 널리 깔렸으니 광학 드라이브나 유선 랜 단자쯤은 본체에 안 달려도 크게 불편하지는 않은 지경이 된 거 같다.

다만, 램은 8기가가 뭐야 8기가.. 장난하나? 안 그래도 추후 확장하기도 어려운 주제에..
뭐, 저걸로도 Windows 10 깔고 작업 자체는 가능하다. 하지만 개발툴, 가상 머신, 5개 이상 탭을 열어 놓은 크롬 브라우저, 문서 작업을 위한 오피스 등등을 한꺼번에 너끈히 구동하면서 5년 정도 버티려면 요즘은 정말 못 해도 12기가 이상은 달아야 된다.

(메모리가 부족해서 프로그램을 그렇게 많이 한꺼번에 돌리지 못하면? 고성능 CPU라든가, 요즘 놋붉들이 그렇게도 강조하는 큼직한 화면이 별 의미가 없다. 그 넓은 화면에다가 여러 프로그램들을 도배하려 해도 메모리에서 결국 병목이 걸린다!)

Windows 7 이래로 10까지 Windows의 최소/권장 사양의 메모리 용량이 계속 똑같이 1GB/2GB(64비트 기준)인 건.. 개인적으로 좀 사기극이고 허위 과장 광고라고 생각한다. 전혀 현실적이지 않다.

그리고.. 본인은 아재 사고방식이어서 그런지, SSD를 영 미덥지 않게 생각해 왔다. 빠른 건 좋지만 용량이 너무 부족하기 때문이다. 하지만 세월이 흐르니 SSD의 가격도 놀라울 정도로 많이 떨어지고 512GB급 물건도 나오다니 기술의 발달에 경이로움을 느낀다.
기계식과 전자식의 차이는 확연히 드러난다. SSD가 아니면 이 정도 성능과 용량을 자랑하는 노트북 컴이 이렇게 조용하고 가볍고 빠르게 돌아갈 수가 없을 것이다.

2. 새 컴파일러

컴퓨터를 새로 세팅하면서 Visual C++도 드디어 최신 버전을 깔아 봤다. 전에도 얘기한 적이 있지만 IDE, 플랫폼 SDK, 그리고 컴파일러 툴킷이 서로 완전히 분리되고 제각기 따로 노는 게 가능해진 것은 매우 바람직한 변화이다. 그리고 IntelliSense DB를 저장하는 방식이 예전의 MS SQL Server Compact Edition (*.sdf)에서 SQLite (*.vc.db)로 바뀌어 있더라.

날개셋 한글 입력기의 소스를 빌드해 보니 다음 사항들만 '경고'로 걸리고 나머지는 문제 없이 컴파일 된다.

(1) GetVersionEx 함수를 사용하는 부분이 deprecated로 처리됐다. Windows 8.1 내지 10부터는 운영체제의 세부 버전을 체크하는 방식이 이 함수를 사용하지 않는 다른 쪽으로 바뀌었기 때문이다. 다만, 옛 함수가 strcpy 내지 gets처럼 보안 위험 때문에 deprecated 된 건 아니다.

(2) C++에서는 포인터를 정수형으로 typecast 하기 위해서 잘 알다시피 reinterpret_cast 연산자를 사용하는데, 포인터형보다 작은 크기인 char, short, UINT(64비트 환경 한정)로 바꾼다면 언제나 경고가 뜨게 됐다. 이건 static_cast로 형변환을 한 단계 더 거쳐야 된다.

(3) delay-load 콜백 함수의 포인터를 보관하는 전역변수가 보안 강화를 위해 const 형태로 바뀌었다. 이 변수는 이제 실행 도중에 값이 변경될 수 없으며, 우리 코드에서 이 변수를 정의하면서 단 한 번 주소를 지정해 줄 수만 있다.
const PfnDliHook __pfnDliNotifyHook2 = _DelayDLLNotifyHook; 이런 식으로 말이다.
이 변수는 실행 파일의 read-only 영역에 보관되기 때문에 const_cast 같은 연산자를 이용해서 값을 강제로 변경하려 하면.. 그냥 crash가 발생하게 된다.

1은 그냥 어쩔 수 없고, 2는 경고가 안 뜨도록 코드를 고치고, 3은 조치를 취했다.

3. 날개셋 한글 입력기의 개선 사항

이렇게 개인용 컴퓨터가 바뀌고 개발 환경이 바뀌자, 날개셋 한글 입력기에 고칠 점이 몇 가지 눈에 띄기 시작했다. 요런 것들을 반영하면 또 0.01 정도 버전 숫자를 올릴 수 있을 것 같다.

(1) 이제 Windows 10이 세상을 평정했으니.. About 대화상자에 표시되는 운영체제 버전 정보에서도 10일 때는 년/월 형태의 세부 버전 번호(1709, 1809 같은)가 나타나게 했다. 아래 그림의 위/아래가 before과 after이다.

(2) 입력 패드는 지금 떠 있는 도구들을 모두 닫으면 프로그램을 곧장 종료하게 하는 /S 옵션이란 게 있는데.. 이게 프로그램 내부 구조를 개편하는 과정에서 언제부턴가 제대로 동작하지 않게 된 것을 뒤늦게 발견했다. 다음 버전에서는 고쳐질 예정이다.

(3) 글꼴을 본뜰 때 CJK 확장 한자 B뿐만 아니라 그 뒤의 C, D도 추가로 본뜨게 했다. 지난번 emoji에 이어서 글꼴 본뜨기 스크립트가 또 바뀌었다.

이쪽 SIP(보충 한자 평면) 한자들은 글자 수가 너무 많은데 일상생활에서 별로 쓰이지 않는 것들이고, BMP(기본 다국어 평면)보다 지원 시기가 훨씬 더 늦은 점으로 인해.. 지원하는 글꼴들도 통상적인 BMP 영역 한자용 글꼴과는 달리 비트맵 글립이 들어있지 않은 편이다.
그래서 16픽셀 글꼴은 썩 보기 좋지 않으며, 24픽셀은 돼야 볼 만하다.

(4) Vista 이래로 줄곧 그랬는지 아니면 8/10에서 보안이 강화돼서 그런 건지는 모르겠지만.. UAC를 켜 놓은 상태에서 ProgramData 디렉터리에는 새로운 파일을 생성할 수는 있지만 프로그램이 설치해 놓은 파일을 사용자가 임의로 고치는 건 안 되는가 보다.

본인은 거기에 있는 파일은 사용자가 마음대로 수정할 수 있다고 가정하고 글꼴 본뜨기 스크립트 같은 일부 파일은 사용자가 곧장 열어서 사용할 수 있게 했었다. 그런데 그렇게 할 수 없다면... 데이터 파일을 운용하는 방식을 바꾸든가 해야 할 것 같다. 비슷한 문제를 날개셋 타자연습의 연습글 목록 xml에서 이미 한번 겪은 바 있다.

(5) 지금까지 사용자에게서 옛한글 관련 동작 때문에 예기치 않은 오동작 의심 증세 문의를 많이 받았다. 옛한글은 일상생활에서는 안 쓰이다시피하니.. 다음 버전에서는 프로그램을 기본 설치했을 때 '세벌식 옛한글'을 아예 빼 버릴까도 고민 중이다.
장기적으로는 한글 표현 옵션 탭에서도 한양 PUA 내지 유니코드 1.1 레거시는 더 꽁꽁 숨겨 놓고 접근하기 어렵게 할 계획이다. 이제 쓰일 일이 없어졌으니 말이다.

(6) 그리고 좀 더 유의미한 변화로.. 휠 내지 노트북 터치패드를 아주 미세하게 굴렸을 때의 스크롤 동작을 개선했다. 이에 대해서는 다음 항목에서 더 자세히 설명하도록 하겠다.

4. 세밀하게 움직이는 휠

마우스 휠이란 게 PC에 도입된 지 20년이 넘었다. 휠이 도는 단위는 기본적으로 칸 단위로 구획이 나뉘어 있으며, 한 칸 돌 때마다 WHEEL_DELTA (120)이라는 값이 전달된다. 120이라는 값은 약수가 많아서(2*2*2*3*5) 다양하게 쪼개기 편한 수라는 이유로 선택된 것이다.

마소에서는 지금은 마우스 휠이 칸이라는 덩어리 단위로 돌아가지만, 미래에 연속된 단위로 아주 부드럽고 세밀하게 돌아가는 휠도 등장할 수 있을 거라고 예상했다. 그래서 단순히 움직인 칸 수가 아니라 거기에 delta를 곱한 값을 되돌리게 여유를 두고 메시지를 설계했다.

저게 1990년대 중후반의 일이다. 하지만 본인은 부드럽게 세밀하게 돌아가는 마우스 휠은 아직까지 구경하지 못했다. 그 대신 그 동작은 노트북의 터치패드/트랙패드가 물려받았다. 처음에는 손가락의 궤적을 따라 마우스 포인터를 옮기는 기능밖에 없었지만 나중에는 패드의 오른쪽 끝을 수직으로 문지른다거나, 아무 곳이나 두 손가락으로 수직으로 문지르는 것을 스크롤로 따로 인식하게 된 것이다.

그 스크롤 요청을 하는 방식이 예전에는 그 윈도우에 대해서 SetScrollInfo/Pos 함수를 호출하고 WM_H/VSCROLL 메시지를 생성하는 것이었다. 화면 캡처 프로그램이 제공하는 스크롤 캡처 기능이 어떻게 구현됐겠는지를 생각하면 된다.

그랬는데 요즘은 WM_MOUSEWHEEL을 보내는 게 대세이다. 터치패드의 종류에 따라 동작이 케바케이긴 하지만, 이때 옛날 동작과의 호환을 유지하기 위해 WHEEL_DELTA의 배수 단위로 스크롤 요청을 하는 경우도 있고, 아니면 문지른 속도에 따라 그 이하의 값을 보내는 경우도 있다. 2010년대부터는.. 스크롤 하다가 손을 급격하게 확 떼면 스크롤도 마치 관성을 받은 듯이 한동안 지속되다가 멈추는 동작까지도 구현돼 있다.

스크롤 요청을 받은 윈도우가 그림이나 웹페이지처럼 원래 픽셀 수준의 부드러운 스크롤을 지원하고 있다면 WHEEL_DELTA로부터 산출한 비율만치 자연스럽게 스크롤을 하면 된다.
하지만 픽셀이 아닌 글자 줄 수 단위로 이산적이고 각진(?) 스크롤을 지원하는 윈도우는 사정이 다르다. 너무 작은 delta 값은 나눗셈 과정에서 아예 0으로 버려지고 없어져서 스크롤이 전혀 처리되지 않을 수 있다. 내부적으로 델타 값을 보관하고 있다가 그 합이 양수나 음수로 WHEEL_DELTA의 배수가 됐을 때 줄을 옮기도록 다소 번거로운 조치를 취해야 한다.

그런데 동일한 각속도로 굴렸어도 120 단위만 지원하는 휠을 굴렸을 때와, 그 이상 정밀한 휠을 굴렸을 때 들어오는 delta값의 규모가 서로 같지 않다. 휠의 종류를 얻을 수 있는 API는 내가 알기로 없다. 그렇기 때문에 그 종류는 WM_MOUSEWHEEL 메시지 때 날아오는 값들을 보며 얼추 짐작을 해야 한다. (120보다 작은 값이 들어오질 않는가?)

Windows의 리스트 박스에서 마우스 휠을 굴려 보면, 처음에는 목록이 한 줄 정도는 픽셀 단위로 답답하게 굼뜨면서 스크롤 되다가 그 뒤 나중에는 줄 단위로 비교적 빠르게 스크롤 되는 걸 볼 수 있다. 이게.. 휠의 종류와 동작 방식을 감지하는, 한번 "간보는" 동작이 아닌가 개인적으로 생각한다.

날개셋 한글 입력기에서 이런 정밀한 휠을 지원하도록 조치가 취해진 곳은 날개셋의 고유한 에디트 컨트롤, 문자표 리스트, 그리고 편집기의 화면 인쇄(300% 이상의 배율로 확대했을 때)창이다. 사실, 내 것이 아닌 어떤 노트북 PC에서 날개셋 편집기에서 휠 스크롤이 잘 안 된다는 걸 오래 전부터 어렴풋이 경험하긴 했는데 그 당시에는 그다지 문제 의식을 못 느끼고 넘어갔던 것 같다.

처음에는 휠을 굴렸을 때 키보드 포커스를 받고 있는 창이 스크롤 됐지만 Windows 8인가 10부터는 마우스 포인터가 놓여 있는 창이 스크롤 된다. 그리고 저렇게 정밀한 휠이 도입되고, 세로 스크롤뿐만 아니라 가로 휠 스크롤 메시지도 도입되니.. 휠도 마치 고해상도 dpi만큼이나 지금까지 은근히 많이 변했다.

Posted by 사무엘

1. 3차원 그래픽 시연 프로그램의 개편

지난 2003년부터 2005년 사이, 본인의 대학 재학 시절에 만들어진 뒤 10년이 넘게 버전업이 없었던 '3차원 그래픽 시연 프로그램'이 정말 오랜만에 업데이트 되었다. 무엇이 바뀌었냐 하면.. '시선 고정' 모드란 게 추가됐다.

이 프로그램은 지금까지 3D FPS 게임처럼 앞뒤 좌우 상하로 움직이는 것에만 최적화돼 있었는데, 시선 고정 모드에서는 카메라가 어디 있든지 시선이 언제나 기준점을 향해 고정되게 된다.
시선이 고정되니, 이때는 통상적인 좌우 화살표나 page up/down을 이용한 시점 변경이 동작하지 않는다. 끄덕끄덕(pitch)/설레설레(yaw) 말고 시선에 영향을 주지 않는 갸우뚱(roll)만 동작한다.

그리고 좌우 게걸음인 ZX와 상승/하강인 QA를 누르면 그냥 움직이는 게 아니라 기준점과 같은 거리를 유지하면서.. 기준점 주변을 상하 좌우로 돌게 된다.
요것이 본인이 원하던 바였다. 사실, 3차원 그래픽 편집 프로그램에서는 FPS 게임 같은 움직임보다는 이렇게 시선이 고정된 '빙글빙글' 앵글 이동을 더 흔히 볼 수 있었을 것이다. 이 동작을 내 프로그램도 뒤늦게 지원하게 됐다.

F를 누르면 시선 고정 모드를 켜거나 끌 수 있다. 아래의 상태 표시줄에 기준점의 좌표가 같이 나타난다.
그리고 D를 누르면 지금 카메라가 있는 위치를 기준점으로 지정한다. 초창기에는 (0, 0, 0) 원점이 기준점이다.
기준점을 파란색 동그라미 같은 별도의 부호로 표시해 주면 사용자에게 도움이 될 수 있겠지만.. 일단은 그런 걸 생략했다.

예제 데이터들 중에서는 구(sphere)가 제일 볼 만할 것이다. 이 구는 그렇잖아도 원점이 중심으로 만들어져 있다. 구에서 적당히 떨어진 뒤 시선 고정 모드를 켜고 QA/ZX를 누르면 우리가 인공위성이라도 된 것처럼 구 주변을 빙글빙글 돌게 된다.
그에 비해 토러스(torus)는 원점을 기준으로 만들어져 있지 않은 듯하니(구체적인 값은 기억이..) 적당히 다른 점을 기준으로 설정해야 튜브 안을 이탈하지 않고 빙글빙글 돌 수 있다.

지난 2016년에는 삼각형 오심 그리는 프로그램을 오랜만에 업데이트 했는데.. 이번에는 3차원 그래픽 프로그램을 손보게 되니 감회가 새롭다. '옛날 자료실'에 있는 프로그램들도 이런 식으로 최소한의 유지 보수는 여전히 하는 중이다.

2. 날개셋 개발 관련 미스터리

본인은 하루는 키보드 보안 ActiveX를 사용하는 어느 사이트에서 날개셋 한글 입력기 외부 모듈이 뻗는 걸 발견했다. 한글만 연달아 입력하는 것은 문제가 없는데, 그렇게 조합을 만들었다가 숫자나 마침표 같은 기호를 찍어서 조합을 중단하면.. 에러가 나고 브라우저 창이 다시 열리곤 했다.

마소 IME 같은 타 프로그램에서는 괜찮고 내 프로그램에서만 100% 재연 가능한 문제가 뻔히 발견되었는데.. 그렇다면 이 문제는 독 안에 든 쥐나 마찬가지이고 곧바로 원인을 추적해서 해결되어야 할 것이다. 그런데 믿어지지 않지만 도저히 그러지를 못했다. 디버깅에 필요한 모든 절차와 방법론을 IE와 보안 유틸리티가 원천봉쇄하고 있었기 때문이다.

exception handler를 지정해서 뻗었을 때 덤프 파일을 만들려고 해도, 윗선에서 예외 이벤트를 가로채기라도 하는지 덤프가 만들어지지 않았다. (덤프는 프로그램이 뻗은 지점이 소스 코드상으로 어디이고 그 당시 함수들의 호출 계층이 어떠한지에 대한 정보를 담고 있음. 원인 추적에 매우 중요!)

입력란이 떠 있는 IE 프로세스에다가 디버거를 붙이면.. 보안 유틸이 이를 감지하고 디버거를 끄라고 요구하면서 동작을 거부했다.
뻗었을 때 디버거를 붙여도 문제의 프로세스는 상황을 확인할 틈도 없이 혼자 싹 종료되어 버렸다.

결국은 무식하게 키 입력이 감지됐을 때.. 등 의심되는 모든 곳에다가 화면/파일로 로그를 찍어서 테스트를 해 봤다.
그런데 이거 뭐 내가 짠 코드는 모조리 정상 통과한 뒤에 이상한 데 엄한 데서 에러가 발생하는 것이었다.

이건 정황상 키보드 보안 유틸과 3rd-party IME와의 충돌이긴 하지만 내가 아는 방법으로는 도저히 문제의 원인이나 해결책을 파악할 수 없어서 이번 9.61 버전에서도 부득이하게 해결되지 못했다. 언젠가 여유가 있으면 그 보안 유틸의 개발사와도 협조를 구해서 합동 수사 공조라도 해야 하지 않을까 싶다.

3. 스레드

어느 플랫폼에서든 프로그램을 짜다 보면, 백그라운드 스레드에서 뭔가를 열심히 수행한 뒤에 결과값을 표시하는 마무리 작업은 반드시 main UI 스레드에서 실행해야 할 때가 생긴다. 이에 대해서 본인은 예전에 글을 쓴 적이 있다.

요즘 프로그래밍 언어들은 언어 차원에서 별도의 블록을 분리해서 이 블록 안의 코드는 별도의 스레드에서 비동기적으로 실행되다던가, main UI 스레드에서 실행시키는 식으로 간편하게 제약을 가할 수 있다. 요런 걸 macOS의 Objective C에서도 보고 Java, C# 등에서도 봤던 것 같다.
그런 게 지원되지 않는 언어나 플랫폼에서는 해당 기능을 직접 구현하게 되는데.. Windows라면 메시지를 보내는 것과 일맥상통한다. main UI 스레드라면 그 정의상 message loop을 돌리고 있을 것이기 때문이다.

그런데 Windows용 IME는 자기가 만들지 않은 남의 프로그램 창, 남의 스레드, 남의 message loop을 기반으로 돌아가기 때문에 거기에다가 자신만의 메시지와 자신만의 메시지 핸들러를 슬쩍 얹기가 좀 난감하다.
그나마 옛날에 프로토콜이 IME 방식이던 시절에는 IME가 제각기 자신만의 보이지 않는 윈도우가 있었기 때문에 내부적으로 custom 메시지를 얼마든지 처리할 수 있었다. 하지만 TSF로 바뀐 뒤에는 그런 윈도우가 존재하지 않는다.

IME는 키보드 포커스를 받는 남의 윈도우에다가 WM_USER+* 이상한 메시지를 함부로 보내서는 안 되고, 타이머 ID도 함부로 선점하지 않아야 한다. 그러면 윈도우 핸들 없이 콜백 함수를 바로 호출하는 타이머밖에 선택의 여지가 없는데.. 그렇게 하면 SetTimer를 호출하는 자신과는 다른 스레드 문맥에서 처리되는 타이머를 생성할 수가 없다.

이게 생각보다 굉장히 난감한 문제이다. 결국은 타 스레드에서 main UI 스레드 문맥으로 특정 코드를 실행하기 위해 본인은 TSF 모듈도 임시로 나만의 message-only 윈도우를 main UI 스레드에서 생성하고, 이 윈도우가 특정 메시지를 받았을 때 그 코드가 실행되도록 프로그램을 작성했다. 메시지라는 게 알고 보면 스레드 간 교통 정리에 큰 기여를 하고 있는 셈이다.

사실 스레드, 특히 콘솔 프로그램이 아니라 main UI가 있는 프로그램에서 스레드를 쓰는 건 십중팔구 사용자 입장에서 프로그램의 반응성을 올려 주기 위해서 하는 게 대부분이다. 일시불로 프로그램이 잠시 멈추고 뜸을 들이는 게 싫으니 이자를 감수하고라도 찔끔찔끔 할부를 선택하는 것이다.

스레드 그 자체는 메모리를 더 잡아먹고 컨텍스트 스위칭 오버헤드 때문에 전반적으로 CPU가 할 일을 더 늘리고 성능을 떨어뜨린다. 하지만 스레드를 만들어서 컴퓨터가 더 많이 고생할수록 사용자의 입장에서는 더 편리한 기능이 많이 구현되는 것이 사실이다.

4. 날개셋 외부 모듈과 입력 패드의 동작 차이

날개셋 한글 입력기의 구현체 프로그램 중에서 편집기는 오로지 자기 혼자서만 돌아가는 프로그램이니 다른 고민의 여지가 없는데.. 외부 모듈과 입력 패드는 본격적으로 타 프로그램에다 문자를 보내기 때문에 다양한 환경에서 최대한 동일한 동작을 보장해야 한다. 그게 불가능한 경우 불가능한 한계에 대해서 사용자에게 미리 고지를 해야 한다.

Windows용 IME의 입장에서 좀 별종인 환경은 전통적으로 (1) 로그인(잠금) 화면, 그리고 (2) 명령 프롬프트가 있다. 그리고 Windows 8/10부터는 (3) Metro UI도 추가됐다.
입력 패드는 원래 명령 프롬프트에서는 전혀 동작하지 못하다가 Windows 7에서부터는 동작 가능해졌다.

외부 모듈은 Metro UI에서는 조합 중인 한글을 보내는 일반적인 동작은 가능하지만 tab, enter 같은 글쇠 입력을 보내지는 못한다(날개셋문자 또는 각종 입력 도구의 버튼을 통해서).
그 외에 Metor UI에서는 프로그램이 외부의 데이터 파일을 참조하지 못해서 입력 설정이 데스크톱 환경과 동기화되어 있지 않다거나, 문자표 같은 입력 도구들도 제대로 동작하지 않는 한계가 있다. 입력 도구를 X 버튼을 눌러서 닫을 수도 없다. (우클릭 메뉴를 이용해야..)

한편, 입력 패드는 외부 모듈과 달리 자신이 독립된 프로세스이기 때문에 파일을 못 여는 한계는 없다. 단지, 반대로 Metro UI로 조합 문자 같은 입력 동작을 보낼 수 없을 뿐이지..;;
그런데 굉장히 의외로 글쇠 입력을 보낼 수는 있다. 가령, 화면 키보드에서 ㄱ, ㅏ 같은 한글 조합 글쇠는 못 보내지만 tab, enter 버튼을 누른 것은 전해진다는 뜻이다. 외부 모듈이 할 수 없는 일을 입력 패드가 예외적으로 할 수 있으니 흥미로운 차이점이다.

외부 모듈에서 글쇠 입력을 못 보냈거나 입력 패드에서 자체 입력을 못 보냈을 때, 못 보냈다는 에러 메시지라도 출력할 수 있으면 좋겠지만 일단은 방법이 없어 보인다.

외부 모듈과 입력 패드에는 이것 말고도 흥미로운 차이점이 더 있다.
외부 모듈은 Windows 메시지를 직접 받지 못한다는 특성 때문에 alt가 섞인 단축글쇠를 전혀 인식할 수 없다. 원래 alt는 운영체제 차원에서의 단축키나 메뉴 구동용으로 쓰이지 IME 같은 데서 가로챌 여지가 없기도 하고 말이다.

그 반면, 비록 프로토콜을 제대로 지원하는 소수의 프로그램 한정이긴 하지만 그래도 편집기와 다를 바 없는 온전한 A급 동작을 보장 가능한 것도 외부 모듈이다. 입력 패드로는 완성된 한글을 낱자 단위로 지우거나 달라붙는 자유자재 동작까지 지원하지는 못한다. 서로 일장일단이 있는 셈이다.

Posted by 사무엘

날개셋 한글 입력기 9.6이 나온 지 한 달 정도가 지났다.
이 블로그에서 날개셋 카테고리에 속하는 예전 글들을 읽어 보니 수 년 전.. 7.x, 8.x 시절에만 해도 이 프로그램에 그런 기능조차 아직 갖춰지지 않았었고 별 희한한 버그가 있었다니 큰 격세지감이 느껴진다. 지금까지 참 먼 길을 갔고 그래도 소원의 대부분이 이제 이뤄졌다.

특히 9.6에서 새로 도입된 필기 인식 기능은 참 흥미롭다. 본인도 종종 꺼내서 이것저것 글자를 쓰면서 잘 갖고 놀고 있다. 물론 한글을 빠르게 입력하는 용도로는 고전적인 세벌식 자판만 한 물건이 없음이 틀림없다. 하지만 필기 인식은 아예 AI 기술이 접목된 기능이며, 운영체제의 기존 기능을 이런 식으로 날개셋 한글 입력기에다가 최초로 연결해 낸 것 역시 큰 의의가 있다.

그럼에도 불구하고 9.6 이후로도 한 달 만에 입력기를 또 소폭 업데이트 하게 됐다. 0.01 단위의 업데이트는 7.11 이래로 5년 만에 처음이다. 그리고 이 기회에 타자연습도 같이 버전업을 했다.
이제는 프로그램을 더 고칠 일이 정말 없으면 좋겠다.. 둘 모두 버전이 올라갔지만 타자연습은 API가 여전히 9.5 구버전과도 호환된다. 먼저 입력기의 변화 내역은 다음과 같다.

(1) 필기 인식 입력 도구에 마우스 포인터의 모양 및 동작과 관련하여 개선· 변경 사항이 좀 생긴 게 있다. 이 점에 대해서는 이 달 말쯤에 프로그래밍 관련 글에서 추가적으로 다뤄질 것이다.

(2) 날개셋 한글 입력기는 단어 단위로 한글을 한자로 변환할 수 있으며, 한자를 탐색하는 방향을 앞 글자부터 뒤로 설정하는 옵션이 지난 8.x 버전에서부터 추가됐다. 그런데 이건 앞에서부터 탐색한 결과 최소한 2글자 이상의 한자어가 존재할 때에만 동작했다.
이제는 맨 앞 1글자 단독으로도 한자 변환이 가능하다면 뒤에서부터 탐색하는 게 아니라 여전히 앞에서부터 찾게 동작을 수정했다. 기존 MS-IME나 아래아한글이 동작하는 것과 동일하게 맞췄다.

(3) 설치 프로그램에서 "날개셋 한글 입력기를 기본 IME로 지정할까요?"라고 묻는 부분을 삭제했다. 어차피 Windows 2000~7 사이에서만 유효한 옵션이고, 오늘날 널리 보급된 10에서는 아무 의미가 없기 때문이다. 그리고...

※ '외부 모듈 관리' 페이지의 리모델링

날개셋 제어판 시스템 계층의 '외부 모듈 관리' 페이지를 싹 뜯어고쳤다. 3.0 이래로 거의 15년째 변함없이 리스트박스 기반의 요런 모양이던 것을..

이렇게 리스트뷰 공용 컨트롤 기반으로 쌔끈하게 고쳤다!

아~ 고치고 나니 너무 좋다. 이렇게 고칠 생각을 왜 지금까지 못 하고 있었나 모르겠다.
리스트뷰 컨트롤을 쓰니 탐색기 쓰듯이 IME 목록을 저렇게 다양한 형태로 표시할 수 있다.
IME들을 언어별로 딱 그룹을 나누었으며, 활성화되지 않은 IME도 뒤에 격리되어 표시되게 했다.

그리고 '정보'를 눌렀을 때 나타나던 것들도.. 온갖 GUID와 이상한 상수들은 개발자의 입장에서도 별 영양가나 의미가 없다고 여겨져서 빼 버리고 크게 간소화했다.
그냥 해당 바이너리의 전체 경로와 버전, 그리고 혹시 파워유저가 관련 레지스트리를 건드릴 때나 참고하라고 HKL 코드값과 클래스 ID, 프로필 ID 정도나 나오게 했다.

지금 선택된 입력기가 TSF 모듈인지 IME 모듈인지 같은 것은 '기술 정보' 내지 '자세히' 모드의 '비고'란에서나 간략하게 확인할 수 있다.
다만, 디폴트 입력기는 저렇게 '비고'란에다가만 '기본'이라고 달랑 써 놓는 게 아니라, 마치 프린터로 치면 '기본 프린터'처럼 기존 아이콘에다가 체크 무늬 오버레이 같은 걸 씌우는 방식으로 표시를 하고 싶긴 하다.

리스트뷰 컨트롤에 그룹을 지정하는 기능, 그리고 일명 tile view라고 불리는 제5의 보기 모드는 Windows XP 공용 컨트롤 6에서 도입된 가히 신의 한 수인 것 같다. 날개셋 한글 입력기에서 저 UI를 활용해 보는 건 이번이 처음이다.

※ 타자연습

입력기의 변화 사항은 이 정도이고, 다음으로 타자연습의 변화 사항을 소개하도록 하겠다.

1. 게임 배경 그림 개편

작년에는 날개셋 타자 게임에 체력과 실드 체계가 개편되었다. 그 뒤 이번에는 게임의 밸런스나 진행과는 무관하지만 중요도가 매우 높은 '시각적 요소'가 오랜만에 바뀌었다. 바로, 10수 년 동안 변함없이 유지되었던 전반부 레벨(3~6)들의 배경 그림이 바뀌고 제목도 바뀐 것이다.

레벨들의 예전 배경은 크게 그러데이션(전반부) 아니면 텍스처(후반부)로 구성되었는데, 전반부 그러데이션들은 하늘 컨셉을 너무 많이 우려먹은 게 사실이었다. 본인이 디자인을 알지 못하는 공돌이인 걸 감안하더라도 너무 촌스럽고 '성의가' 없어 보였다.

바꾼다고 해도 전용 텍스처를 사용하고 있는 후반부의 어려운 레벨들과 너무 위화감이 느껴져서도 안 되니, 여기 레벨들은 삼각형과 사각형이 동원된 간단한 기하학 무늬 위주로 배경을 바꿨다.
그래서 예전과 같은 단순 수평선 그러데이션을 사용하는 레벨은 맨 처음 1과 맨 마지막 12밖에 없게 했다. 이 정도면 단조로움이 많이 줄어들었을 것이다.

비주얼의 변화는 직접 확인해 보시라는 취지에서 스크린샷 첨부를 생략하겠다. 타자연습 페이지에는 레벨 3(새 제목: 에메랄드)이 어떻게 바뀌었는지가 나와 있다.
이 개편과 함께, 이번 버전부터는 256색 전체 화면 지원을 제외했다. 그리고 256색 지원을 위해 필요했던 번거로운 팔레트 처리 관련 루틴을 제거했다.

타자 게임을 처음으로 개발하던 2000년대 초에는 이 옵션이 필요했다. 속도가 1GHz가 채 안 되고 Windows 98/2000이나 그럭저럭 돌리던 컴은 비디오 카드도 덩달아 구닥다리인 경우가 많았다. 트루컬러 전체 화면에서는 게임 진행이 너무 느렸으며, 가상 머신에서 타자연습을 돌릴 때는 이게 지원되지 않기도 했다. 256색은 그런 성능 말고는 별다른 차이가 없다.

하지만 후대에 와서는 이건 전혀 필요하지 않은 옵션으로 전락했으며, 최신 컴퓨터에서는 아예 이 옵션을 일부러 숨기기까지 하는 지경이 됐다. 그래서 기왕 타자 게임의 배경 그래픽을 개편할 때 얘를 완전히 빼는 조치를 취했다.

2. 세벌식 글쇠배열 표시 유틸

아아.. 이건 지난 새 버전에서 같이 반영됐으면 좋았을 텐데 참 아쉽다만..
타자연습에 동봉돼 있는 세벌식 글쇠배열 표시 프로그램을 오랜만에 리마스터링(?)했다. '시작' 탭에서 '세벌식 글쇠배열' 버튼을 눌렀을 때 글쇠배열 창을 띄워 주는 그 프로그램 말이다.

타자연습의 주 개선 사항이 high DPI 지원 강화이었거늘, 타자연습과 함께 제공되는 이 유틸(3bfview)은 그거 대비가 전혀 돼 있지 않았다. 그래서 high DPI에서 실행하면 저해상도 픽셀이 강제로 확대되면서 얘는 내용이 뿌옇게 표시되곤 했다. 그걸 개선했다. 아래 그림에서 위와 아래의 차이를 주목하라.

사실은 '세벌식 파워업' 프로그램에도 동일 기능이 있다. 타자연습에 들어있는 유틸은 파워업의 소스 코드를 기반으로 일부 기능만 따로 떼어내서 만들어진 것이다.
그런데 지금까지 제공되었던 물건은 2012년경 파워업을 기준으로 한번 업데이트 한 뒤, 6년째 업데이트 없이 그대로 쓰여 왔다. 글쇠배열 하나 달랑 띄워 주는 기능이 크게 바뀔 여지가 없긴 하지만, 그나마 high DPI 지원만은 반드시 손 봐야 하게 됐다.

Posted by 사무엘

2018년도 벌써 끝이 얼마 남지 않았다.
그 사이에 날개셋 한글 입력기는 파이널 버전인 9.5가 나온 지 70일 남짓 지났고, 본인의 근황에도 여러 변화가 생겼다. 내 인생에 한글 입력기 TODO list가 비어 있는 나날도 이렇게 오는구나 싶다.

뭐, 정말로 TODO가 전혀 없는 것은 아니다.
생각 같아서는 이미 여러 번 얘기했듯이 입력 설정 파일 포맷을 뜯어고치고 싶고 엔진 구조를 다시 설계하고 싶고, 도움말을 몽땅 영작도 하고 싶다. 허나, 그런 것들은 지금 도저히 추진 가능하지 않을 정도로 너무 거창한 것들이고 비용 대비 효과가 미미하기 때문에, 굳이 지금 같은 학생 신분에서 졸업을 더 늦추면서까지 욕심을 내지는 않는 것이다. 9.5를 넘어 10.0이라는 대망의 버전 번호는 그 날을 위해 비워 두는 것일 수도 있다.

그래도 거창한 것 말고 GUI, 보조 기능, 데이터 쪽에 아주 자잘하게 바뀐 것은 있다. 이것들을 일단 9.6 정도로 정리하고자 한다.

1. 필기 인식!

날개셋 한글 입력기는 지난 9.3 버전 이래로 총 10개의 입력 도구를 제공하고 있다. 그런데 9.6에서는 기존 도구들과는 성격이 매우 다른 물건이 하나 더 추가되어 11개가 되었다.
바로 필기 인식이다. 현재의 글쇠배열이나 날개셋 입력 설정과는 아무 관계 없이, 글자의 모양을 사용자가 마우스로 그리고 프로그램이 이를 인식하여 문자를 입력시킨다. 기술적으로는 '온라인 필기 인식'이다.

필기 인식은 MS IME에서는 아주 오래 전부터 갖추고 있지만 날개셋 한글 입력기에는 없는 기능 중 하나였다. 뭐, 애초에 내 프로그램의 존재 목적과 전문 분야는 세벌식 관련 특수 기능, 키보드 인식 관련 customization, 옛한글과 복합 낱자 처리.. 따위이지, 그런 AI 분야가 아니니까 말이다.

하지만 내가 필기 인식 엔진을 직접 구현까지는 하지 않더라도, 기존 API를 통해서라도 날개셋에서 필기 인식 기능을 제공할 수는 없으려나 하는 아쉬움이 있었다. 그래서 본인은 방법을 찾아 봤는데.. 다행히도 방법을 어렵지 않게 발견할 수 있었다.

과거에는 Windows CE 내지 XP 태블릿 에디션 같은 일부 제품군에만 그런 API가 있었다고 한다. 하지만 이제는 데스크톱용 Windows에도 필기 인식 기능을 다 사용할 수 있더라.
그리고 API 형태가 XP 시절과 Vista 이후가 서로 좀 달라졌다. 이 시점에서 굳이 legacy API를 지원할 필요는 없으니, 내 프로그램의 필기 인식 기능은 후자만 지원하는 형태로 개발되었다.

필기 인식 덕분에 날개셋 한글 입력기의 다음 버전이 9.51이 아니라 당당하게 9.6으로 매겨질 수 있게 됐다. 자체 기능이 아니라 운영체제의 API를 빌려서 동작하는 기능이 한자 단어 사전과 더불어 하나 더 추가됐다. 필기 인식이야말로 키보드 대신 포인팅 장비만으로 문자를 입력하는 기능의 백미 진수가 아닌가 싶다.

위의 스크린샷에서 보듯이 필기 인식 도구는 (1) 글자를 그리는 공간인 정사각형 입력란, (2) 인식된 글자 후보 목록, 그리고 (3) 주요 도구 명령(획 지움 등)과 (4) 자주 쓰이는 키보드 글쇠 버튼들로 평범하게 구성되어 있다.

"부수로 한자 입력"이나 "문자표" 같은 입력 도구들은 키보드에 없고 평소에 자주 쓰이지 않는 특수문자 몇 자를 입력하는 게 목적인 반면, "필기 인식"은 일상적으로 자주 쓰이는 linguistic한 문자들을 연달아 많이 입력하는 용도로 쓰인다.
그렇기 때문에 전자 문자표들은 리스트의 항목을 더블 클릭해야 글자가 입력되지만, "필기 인식"은 한 번 클릭하는 것만으로도 글자가 곧장 입력되게 했다.

그리고 이 입력 도구는 중요한 옵션이 두 종류 있다. 첫째, UI 모드이다.
위의 스크린샷처럼 입력란이 하나만 있고 글자 후보 선택을 수동으로 할 때는 타이머도 옵션으로 지정할 수 있다. 마지막 획을 긋고 나서 별다른 조치 없이 2초 정도 있으면 1순위 글자가 자동으로 본문으로 삽입된다. 매번 '인식 완료'를 누르거나 목록에서 글자를 찍을 필요가 없다. 아니면..

이렇게 입력란을 2개를 꺼내서 쓸 수도 있다. 왼쪽의 입력란에다가 글자를 그린 뒤에 곧장 오른쪽 입력란에다 글자를 그리기 시작하면 왼쪽에서 인식된 글자가 곧장 본문에 삽입되는 것이다. 창이 세로로 길쭉한 크기이면 두 입력란도 좌우로 가로가 아닌 상하로 세로로 자동으로 배열된다.

입력란이 2개 있을 때는 space나 엔터를 누르는 것도 먼저 인식 결과를 본문으로 보내고 난 뒤에 수행한다. 글자를 그리고 있고 후보 목록이 뜬 상태가 일종의 composition 상태라고 생각하면 된다.

둘째로, 사용할 필기 인식 엔진의 언어이다.
필기 인식 엔진이란 건 범언어 세계 공통 형태로 존재하는 게 아니라 각 언어별로 제각기 나뉘어 있다.
그래서 한글은 오로지 한국어 엔진에서만 인식 가능하며, 히라가나· 가타카나는 일본어 엔진에서만 인식된다. 중국에서만 쓰이는 간체 한자를 인식하려면 중국어 엔진을 사용해야 한다.

어느 언어에서나 동일하게 인식 가능한 문자는 숫자, 알파벳, 아스키 기호와 한중일이 완전히 동일하게 사용하는 공통 한자들뿐이다. 한글을 알아보지 못하는 중국 및 일본어 엔진에서는 '튽'을 입력하면 다들 長이 1순위로 제시되는 걸 볼 수 있다.

이 입력 도구는 기본적으로 한국어 엔진을 사용하지만, 컴퓨터에 한중일에 속하는 언어가 2개 이상 설치되어 있다면 원하는 언어의 엔진을 우클릭 메뉴에서 선택할 수도 있다. 프로그램 제목 표시줄에도 현재 사용 중인 언어가 나타나 있다.
Windows 10 기준으로 설정 - 언어 옵션에 들어가면, 각 언어별로 언어 팩이나 IME와는 별개로 필기/음성 데이터를 받는 버튼이 있다. 거기서 한중일 언어의 필기 데이터를 받으면 그 기능을 내 프로그램에서 활용할 수 있게 된다.

그런데 정확하게는 모르겠지만 내 경험상, Microsoft의 한중일 기본 IME가 제공하는 필기 인식이랑, 저 official한 필기 인식은 따로 노는 별개의 기능인 것 같다. 마소의 일본어/중국어 IME는 '확장 입력기 애플릿'을 통해 자체적으로 필기 인식 기능을 제공하지만, 내 프로그램에서는 여전히 일본어/중국어 필기 인식 엔진이 존재하지 않는 것으로 인지하는 경우도 있다.

의외로 Windows Vista는 CD 대신 DVD로 출시되고 전세계 다국어가 기본 내장되기 시작한 첫 버전이어서 그런지..
중국어· 일본어 IME를 끄집어낸 적 없고 Office조차 설치하지 않은 한국어판에도 중국어와 일본어 필기 인식 엔진이 다 기본 내장돼 있는 듯했다. 그것도 Ultimate 말고 Home premium급이 말이다. 아무튼..

한중일 언어의 필기 인식은 이렇게 정사각형 격자에서 글자를 하나씩 인식하는 방식으로, 마치 학창 시절의 칸 공책처럼 동작한다. 하지만 라틴 알파벳은 길쭉한 4선지에다가 단어를 한붓그리기 하듯이 필기체로 날려 쓰는 형태로 동작한다. 즉, 프로그램의 UI 자체가 서로 다르다.
요즘 Windows 10급 컴퓨터에 영어 필기 인식 엔진은 기본으로 다 깔려 있고 이 기능을 활용할 수도 있지만.. 내 프로그램에서는 그건 보류하고 일단은 형태가 더 간단한 한중일 위주로만 구현을 했다.

이런 식으로 필기 인식뿐만 아니라 음성 인식(받아쓰기)도 보조 입력 도구로 구현됐으면 좋겠는데.. 기존 API를 공부하는 것만 해도 필기 인식보다는 훨씬 더 어려울 것 같다. 동아시아 언어는 지원이 아직까지 훨씬 미비하기도 하고 말이다.

2. 글꼴 본뜨기/본뜬 글꼴 삭제 기능

날개셋 한글 입력기는 내부적으로 전용 비트맵 글꼴을 사용하는 부분이 있다. 그렇다고 유니코드의 모든 문자의 글립을 직접 내장해서 제공하지는 않으며, 그럴 수 없고 그럴 필요도 없다.
한자 같은 글자는 그냥 사용자의 컴퓨터에 들어있는 운영체제 글꼴로부터 비트맵을 추출하라고 글꼴 본뜨기라는 기능이 있다. 유니코드 영역별로 여기는 무슨 글꼴을 이용해서 추출하라는 간단한 절차 스크립트 파일도 있다.

날개셋 제어판의 '시스템 계층'으로 가 보면 글꼴 본뜨기를 하고, 필요하다면 절차 스크립트를 편집하고, 본떴던 글꼴 파일을 삭제하는 기능이 있는데.. 이번 9.6에서는 이 글꼴 본뜨기 관련 기능들이 크게 개선되었다. 다음과 같은 변화가 생겼다.

(1) 예전에는 글꼴 본뜨기 버튼을 누르면 그냥 무조건 모든 본뜨기 작업을 처음부터 새로 했다. 하지만 이제는 이미 본뜨기가 돼 있는 파일은 또 건드리지 않고 넘어가며, 변화가 생긴 항목에 대해서만 본뜬다.
만약 모든 항목이 본뜨기가 돼 있어서 파일이 생성된 게 하나도 없으면 "모든 항목이 본뜨기가 돼 있습니다. 혹시 이것들을 무시하고 본뜨기를 처음부터 다시 하시겠습니까?"라고 확인 질문이 나오며, 여기서 사용자가 '예'를 누르면 이전처럼 본뜨기를 처음부터 새로 하게 된다.

(2) 글꼴 본뜨기를 한 뒤, 절차 스크립트에 명시된 영역과 겹치는 파일이 남아 있으면 그건 자동으로 제거하게 했다.
예를 들어 스크립트에 0~300, 500~800이 명시돼 있었고 이렇게 본뜨기를 했다고 치자. 나중에 500~800을 400~800이나 500~900으로 바꿔서 본뜨기를 하게 됐다면.. 이 영역과 충돌하는 이전의 05000800.16/8 같은 파일은 이 프로그램이 알아서 제거해 준다는 것이다. 충돌이 발생하지 않게 해 준다.

(3) 본뜬 글꼴 삭제 기능은 스크립트에 명시돼 있는 파일을 삭제하는 것과 스크립트에 명시되지 않은 잔상을 삭제하는 것을 취사 선택 가능하게 했다. 물론 둘 다 싹 다 없애는 것도 가능하다.

(4) 또한, 글꼴을 본뜨거나 삭제하기 전에, 이미 날개셋 한글 입력기 프로그램이 로딩해서 열어 버린 글꼴 파일들이라도 모두 닫게 했다. 그래서 정상적으로 덮어쓰거나 삭제할 수 있다.
이제는 본뜬 글꼴을 삭제해 버리면 한자 글꼴이 존재하다가도 다시 한자가 표시되지 않는 상태로 되돌아가는 게 가능해졌다. 이전 버전에서는 그게 가능하지 않았었다.

(5) 끝으로, 본뜨기 스크립트의 내부 구조도 개편했다.
SYMBOL, HANGUL, LATIN이라고 섹션을 구분하여 SYMBOL 영역에서는 예전과 동일하게 본뜰 문자 영역을 명시하면 된다.
HANGUL과 LATIN에서는 예전처럼 번거롭게 AC00~AC00, 00~FF을 써 줄 필요 없이, 이미 선언된 글꼴 ID만 써 주거나.. 아니면 새로운 글꼴을 선언만 하면 자동으로 완성형 한글이나 영문 글꼴을 본뜨도록 했다.

스크립트에서 글꼴 ID도 예전에는 고정된 배열을 기반으로 5~63 사이만 지정할 수 있었으나, 이제는 쿨하게 아무 숫자로나 지정 가능하게 했다(32767 이내). 그리고 완성형 한글이나 영문에서 재사용 없이 글꼴을 일회용으로만 선언할 때는 번호를 지정할 필요조차 없이 그냥 0만 줘도 된다.

한글 입력 엔진과는 무관한 그냥 UI 기능인데, 뭔가 프로그램의 완성도를 향상시키는 여러 작업들이 한데 행해졌다.

3. 이모지(emoji) 입력

2010년대부터 유니코드의 확장 평면에는 한자뿐만 아니라 이모지(Emoji)라고 불리는.. 이모티콘이 아니라고는 하지만 웹과 모바일에서 실질적으로 이모티콘처럼 쓰이는 온갖 그림문자들이 추가되고 있다.
유니코드 위원회는 출처와 근거가 명확하지 않은 임의의 문자를 제멋대로 넙죽 받아들이고 추가해 주는 곳이 절대 아니다. 그럼에도 불구하고, 일본에서 임의로 이런 그림문자들을 오랫동안 많이 사용해 온 덕분에 이들도 전세계에서 통용되는 유일한 코드 번호가 주어지게 되었다.

BMP를 벗어나 확장 평면이라는 제2군, 2루에 추가되는 문자들은 일상생활에서 쓸 일이 없는 듣보잡 벽자 한자나 고대 문자, 악보 기호 등이 고작이었는데.. 웬일로 채팅에서 활발히 쓰이는 그림문자가 이 영역에 대거 추가되었다.
그래서 유니코드의 버전이 10에 도달한 무려 2010년대까지도 모든 글자가 16비트 코드 포인트 하나로 감당 가능하다고 안일하게 생각하고 UTF-16의 대비가 제대로 돼 있지 않던... 구닥다리 글꼴 엔진이나 텍스트 에디터들이 이제야 부랴부랴 수정되어야 했다고 한다. 뭐, 출처를 알 수 없는 카더라 통신이다.

폰트는 근본적으로 흑백 벡터 이미지밖에 표현을 못 하니, 인쇄를 염두에 둔 워드 프로세서에서는 이런 이모지들이 그냥 U+26??대의 그림문자와 별 다를 바 없는 외형으로 찍힌다. 하지만 전문적인 채팅 앱이나 스마트폰의 텍스트 입력란에서는 이것들이 컬러 그림으로 표시된다. 이 정도면 마치 한자만큼이나 글자와 그림의 경계가 모호해지는 것이나 마찬가지로 보인다. 서식(글꼴, 글자색, 크기 변경 등) 없는 텍스트 입력란 하나만 만드는데도 온갖 유니코드 문자 처리뿐만 아니라 이제는 사실상 그림 출력까지 감당해야 할 듯하다.;;

2010년대에 나온 최신 중국어· 일본어 IME를 보면 이런 이모티콘을 입력하는 전용 문자표나 입력 모드가 꼭 존재하더라. 이런 거 입력도 뭔가 피할 수 없는 대세가 되어 가는 듯한 느낌이다.
하지만, 내 프로그램은 모든 유니코드 문자를 고르는 범용적인 문자표 외에, 분야별 전용 문자표 같은 것은 딱히 고려 대상이 아니다. 현재로서는 말이다.
또한 편집기도 일반 문자들조차 흑백 비트맵 나부랭이로 출력하는 주제에 이모지를 컬러 이미지로 출력해야 할 이유는 없다.

날개셋 한글 입력기가 이모지의 지원과 관련하여 할 만한 최소한의 조치는 글꼴 본뜨기 스크립트에다가 이 영역을 반영해 주는 것이다. Windows의 경우 Segoe UI Symbol이라는 글꼴이 이모지 출력용으로 쓰이고 있어서 이걸로 U+1F300부터 U+1F6FF 정도를 전각으로 본뜨면 된다. 문자표의 영역명에는 이 영역도 이미 등록돼 있다.

이건 아주 간단한 조치이니 지난 9.5에도 반영돼 들어갔으면 좋았겠지만..;; 인제 생각이 나 버렸으니 뭐 어쩔 수 없다. 이제 9.6을 설치한 뒤 글꼴 본뜨기를 다시 해 주면 편집기에서 이모지 글꼴들을 볼 수 있다.

4. '조합 안에 조합 생성' 입력 도구의 개선

'조합 안에 조합 생성' 입력 도구는 지난 9.3과 9.5 버전 시절에 도입되었던 핵심 기능들 중 하나이다. 이제 더 고칠 게 없을 거라 여겨졌지만 미세한 개선 사항과 버그들이 더 발견되어서 9.6에서 다들 고쳤다.

• numlock 키패드로도 후보를 선택할 수 있게 했다. 안 그래도 세벌식 자판은 키보드의 1~0은 문자가 배당돼 있는데 Ctrl+숫자뿐만 아니라 numlock 키패드도 지원된다면 아무래도 더 도움이 될 것이다.
• 한글을 조합하는 중에 capslock 또는 이에 준하는 조합 종료 글쇠를 누르면 원래는 아무 반응이 없어야 정상이다. 그런데 외부 모듈은 지금 조합이 덧나면서 조합이 종료되는 문제가 있었다. 편집기, 외부 모듈, 입력 패드에서 모두 아무 반응이 없게 일관되게 조치를 취했다.
• 편집기와 입력 패드는 입력 도구를 꺼내는 과정에서 대화상자를 꺼내고 창 포커스가 바뀌기 때문에 이런 일이 원천적으로 발생할 수 없는데 외부 모듈은 현재 조합을 그대로 유지하면서 입력 도구를 열거나 닫을 수 있다. 이미 조합이 있는 상태에서 저 도구를 꺼내거나 닫으면 여러가지 문제가 발생할 수 있던 것을 다 해결했다.

Posted by 사무엘

날개셋 한글 입력기 9.5, 그리고 타자연습 3.81이 나왔다. 9.3 이후 반 년을 넘어 거의 200일 만이다.
지금으로부터 두 달쯤 전의 개발 근황글에서 예고한 바와 같이, 이번 9.5는 '파이널' 버전이다. 수 년치 분량의 TODO 리스트를 갖고 작정하고 새 아이디어, 새 기능을 구현하고 리모델링 리팩터링을 하던 것은 여기까지이다.

그 과업이 다 이뤄졌다! 내 인생에 이런 날이 오다니 감개무량하면서도 한편으로는 그저 담담하다. 9.5 이후부터는 장기 계획 없이 소규모 유지보수만 소규모로 진행될 것이다.

작년 여름에는 나라 사정 때문에 슬럼프에 빠졌던 게 많았던 반면, 올해 여름은 그런 외부 요인이 개발 컨디션에 심하게 영향을 끼친 건 없었다. 그래도 폭염이 너무 심하긴 했다..;;
또 이 정도면 정말 '완결 파이널'이라고 내 양심과 역사와 국가와 민족 앞에서 정말 단언할 수 있을지 확신이 서지 않아서 테스트만 하다가 긴 시간을 그냥 보내 버리기도 했다. 그래도 올여름은 넘기지 않고 끝을 보게 됐다.

1. 동시치기

이번 9.5 버전에서 제일 핵심적인 새 기능은 초보적인 수준의 동시치기이다.
지금까지 날개셋 한글 입력기가 세벌식 자판의 고급 응용 기능 명목으로 제공해 온 것은 오토마타를 통한 모아치기나 무한 낱자 수정 정도였다. 이건 일면 편리하지만 현재 글자를 최대한 붙이고 유지시켜 주는 것에만 최적화돼 있다. 다음 글자로 분리되어야 하는 상황의 대비가 미흡한 반쪽짜리이다.

그래서 새 버전에서는 한글 입력 중에 일정 간격을 두고 마지막 두 타가 이전 타보다 충분히 빠르게 입력됐다면, 이건 다음 글자에 대한 동시입력으로 간주하고 그 두 타를 뒤로 같이 보내는 로직을 구현했다.

마지막 두 타를 한꺼번에 다음 글자로 보내는 동작 자체는 이전 버전에서부터 구현돼 있었다. 그걸 후대 버전에서 드디어 본격적으로 활용하게 된 것이다.
이 기능을 사용하면 세벌식 자판에서도 명목상 도깨비불 현상 같은 동작이 발생할 수 있다. 물론 그래도 종성이 초성으로 바뀐다거나 하지는 않고 그냥 위치만 이동한다.

동시치기는 시간 주기부터 시작해서 세밀한 동작 옵션이 존재할 여지가 많은 기능이고 이것만 전담하는 빠른설정이 존재해도 이상할 게 없다. 본인도 그걸 의도하기도 했다. 동시치기는 특정 입력 방식이 아니라 안 마태건 공 병우건 세벌식 입력 방식에 적용 가능한 일종의 범용적인 패러다임이니까 말이다.

하지만 9.5 버전은 그 정도까지 구현하지는 못하고, 그냥 '동시치기 테스트.ist'라는 예제 파일만 넣어서 공 병우 세벌식 글자판을 기준으로 이런 기능도 구현 가능하다는 맛보기를 시연하는 선에서 그쳤다.

해당 파일을 열어 보면 설명문에 오토마타 로직이 세밀하게 설명돼 있는데, 핵심은 이렇다.
고급 입력 스키마의 옵션을 바꾸서 동시치기 타이밍 변수를 제공하게 한다(고급 스키마 옵션 - 한글 동시치기 타이밍을 오토마타 Q 변수에 전달).

그 뒤, 실제로 두 타를 옮기는 것은 두 타가 가리키는 (1) 한글의 성분이 서로 다르고(초성+중성, 중성+종성 등..), (2) 두 타를 떼어내더라도 앞 글자가 최소한 초성과 중성을 갖추고 있을 때에만 떼어낸다.
이 두 조건을 체크하기 위해서 오토마타에 s, r, u, v 같은 복잡한 변수와 수식들이 있는 것이다. 별로 어려울 것 없다.

이 입력 방식에서는 '아'를 친 뒤에 'ㅣ+ㄱ'을 빠르게 입력하자 글자가 처음에는 무한 낱자 수정 때문에 '이'가 됐다가 다시 '아'로 바뀌면서 '아기'가 입력되는 것을 볼 수 있다. 물론 그냥 단순히 순차적으로 빠르게 칠 때 예기치 않은 부작용도 발생하지 않게 타협점을 찾으려 했다.

이 정도는 돼야 두벌식이나 세벌식이나 컴퓨터에서는 성능과 편의성 차이가 별로 없다는 말을 완전히 반박할 수 있지 않을까? 세벌식은 타자기에서 이미 기본적인 온전한 입력이 되고 컴퓨터로 가면 오타 수정이 더 편하게 되고 타이밍 오차 보정까지 되는 입력 방식을 구현할 수 있으니 말이다. 그것도 언어 데이터 없이 그냥 원초적인 수준에서 말이다.

지난번 개발 근황에서 먼저 소개되었던 한글 조합 유지 기능은 한글과 비한글끼리의 순서를 보정하는 기능이고, 이번에 완결된 기능은 한글과 한글끼리의 순서 내지 음절 경계를 보정하는 기능이다. 이런 기능이 타자에 실질적으로 얼마나 도움이 되었는지를 입증하는 실험 데이터가 좀 있으면 좋겠다.

참고로 지금으로부터 10여 년 전, 4.x 버전 시절에 '고급 스키마'의 전신격인 동시입력 스키마라는 게 날개셋 한글 입력기에 이미 도입된 적이 있었다. 옛날 자료를 찾아보니 2개 이상의 한글 글쇠가 동시에 눌렸을 때 '중간 상태'로 진입하고, 모든 글쇠가 떼어지면 '종결 상태'로 넘어갔다. 종결 상태에서는 '고+ㅏ'나 '고+ㄴ'처럼 평소에 조합 가능한 입력이라도 더 결합을 거부하고 다음 글자로 가게 해서 음절을 구분했었다.

동시치기의 원론적인 동작에 정말 충실하게 로직을 구현하긴 했지만, 이 상태로 실제로 쳐 보면 생각보다 불편하다.
특히 기존의 이어치기 방식으로 타자를 빠르게 하면 오동작도 많이 겪게 된다. 동시치기 내지 동시치기에 준하는 빠른 타자가 행해지는 동안에는 음절 경계의 타이밍의 차이로 물리적인 음절 경계를 구분하는 게 더 낫다.

옛날 '동시입력 스키마' 시절에도 'ㅇ.ㅏ' 오타를 보정하고, keyup 타이밍 때 비한글 문자를 뱉는 옵션은 구현돼 있었다. 비록 한글 조합 중에 그 비한글 문자가 같이 보이지는 않지만 말이다.

2. 입력 도구들의 개선

9.3은 참신한 입력 도구들이 대거 추가된 버전이었다. 그리고 지난번에 다음 버전 개발 근황을 전한 뒤에도 입력 도구에 대한 개선 작업이 더 진행되었다. 구체적인 변화 내역은 다음과 같다.

'조합 안에 조합 생성' 입력 도구가 제공하는 변환 기능 중, '새김을 한자로'도 한번에 여러 한자의 훈을 한꺼번에 입력해서 여러 개의 한자로 순차적으로 변환할 수 있게 했다. 더구나 새김을 끝까지 다 입력하지 않아도 된다.
가령, "땅불바람물마음"이라고 한꺼번에 친 뒤에 한자를 하나씩 골라서 "地火風水心"을 곧장 입력할 수 있다. 이전 9.3에서는 이런 게 가능하지 않았으며, '땅'까지만 치고 나서 변환을 직접 한 뒤에 다음 글자를 입력해야 했다.

그리고 '조합과 후보 자동 완성' 입력 도구도 여러가지가 개선됐다.
(1) 먼저, 목록에서 오른쪽에 작게 표시되는 보조 문자열(조합 목록에서 글쇠 문자, 후보 목록에서 설명문)이 한 줄에 가지런히 맞춰서 출력되게 해서 미관을 개선했다.

(2) 조합이나 후보가 출력될 게 아무것도 없는 상황에서는 해당 목록이 작게만 공간을 차지하는 게 아니라 아예 화면에서 사라지게 했다. 좌측 상단에 있던 자그마한 기본 버튼들만 남아있다.

(3) 다른 프로그램에서는 별 문제가 없는데 MS Word에서는 이 입력 도구가 cursor 주변에 표시되지 않고 화면의 좌측 상단에 잘못 표시되는 문제가 있었다. 쟤만 유독 까탈스럽게 동작하는 게 있어서 문제를 꽤 번거로운 방법으로 우회해야 했지만.. 어쨌든 버그를 고치긴 했다.

(4) 이 도구를 띄워 놓은 상태에서 운영체제의 테마나 색깔 배색을 변경하고 나면 보조 문자열의 글꼴이 깨져서 굴림체로 바뀌어 버리던 문제를 해결했다. 그 이벤트가 발생했을 때의 처리 절차에 논리적으로 구멍이 있기 때문이었는데, 이를 총체적으로 싹 손 봤다. 공통으로 사용하는 글꼴 같은 리소스를 반드시 초기화부터 한 뒤에 입력 도구들이 이벤트를 받게 했으며, 이 순서가 꼬이는 일이 없게 했다. 심지어 날개셋 편집기와 외부 모듈을 동시에 구동했을 때에도 말이다.

(5) 이 외에도.. 프로그램을 이 정도로 변태같이 사용하는 경우는 현실적으로 극히 드물겠지만,
날개셋 편집기에서 또 외부 모듈을 구동하고, 두 구현체가 제각각 '조합과 후보 자동 완성' 도구를 구동했을 때.. 그리고 TSF가 아니라 이제는 사실상 사용되지 않는 9x~XP까지의 구형 IME 프로토콜로 동작할 때, 여러 오동작이 발생하던 문제들을 해결했다.
과거의 9.3을 개발하던 당시에 시간에 쫓기느라 이런 극한이나 레거시 환경에서까지 꼼꼼히 테스트를 하지 못해서 문제가 남아 있었다. 단지 그게 크게 부각되는 주요 문제가 아니었을 뿐이다.

3. 그 밖의 UI 개선

(1) 날개셋 제어판에서 '분야'를 선택하는 트리 컨트롤을 키보드로(주로 상하 화살표) 조종하면.. 그 분야에 해당하는 제어판 페이지가 곧장 뜨는 게 아니라, 중간에 0.2초 정도 지연을 넣었다.
키 입력이 일정 시간 이상 안 들어올 때에만 화면을 갱신하는 것이다. 화살표 키를 빠르게 연타하거나 꾹 누르고 있을 때, 일일이 제어판 페이지를 준비하느라 프로그램의 반응성을 떨어뜨리지 않기 위해서이다.

사실, Windows의 제어판은 오래 전부터 이미 이렇게 동작하고 있다.
디렉터리를 표시하는 트리는 마우스 클릭에는 즉각 반응하지만 키보드의 화살표 키에는 그렇게 하지 않는다. 잠시 뜸을 들이고 있다가 사용자가 키보드에서 손을 완전히 뗀 뒤에 그 디렉터리의 내용을 옆의 리스트 컨트롤에다가 표시해 준다. 매번 한 디렉터리의 파일 목록을 얻는 건 힘들고 시간이 많이 걸리기 때문이다.

트리 컨트롤이 이렇게 키보드에 대해서 지연 인식을 하는 건.. 정형화된 동작이고 여러 곳에서 쓰일 만한 기능인데, 어째 운영체제 공용 컨트롤 차원에서 제공되는 건 없는지 궁금하다(스타일, 플래그 형태로). 그런 게 있다는 소식을 들은 적이 없기 때문에 본인은 해당 동작을 수동으로 직접 구현했다.

(2) 그리고 또 사소한 것..
날개셋 한글 입력기의 대화상자 UI 중에는 파란색 밑줄이 쳐진 하이퍼링크가 있다. 가령, About 대화상자에 있는 홈페이지 주소라든가 '후원 안내' 말이다.
이전 버전까지는 마우스로 클릭한 것만 인식됐지만, 이제는 거기에 포커스를 옮기고 space를 누른 것도 인식되게 동작을 개선했다. 마우스 없이도 링크 클릭 명령을 내릴 수 있다. 원래 이렇게 되는 게 맞다.

4. 타자연습

끝으로, 타자연습은 딱히 새로운 기능이 추가되거나 동작이 바뀐 것은 없다. 하지만 API 호환이 깨졌기 때문에 입력기 9.5 엔진에 맞춰 다시 빌드되었으며, high DPI에서 실행되었을 때 발생하던 각종 glitch들을 잡았다. 이것 분량이 버전을 0.01 정도는 올릴 수준이 된다고 여겨지기 때문에 버전을 올리게 되었다.

• 프로그램의 시작 화면에 나타나 있는 탭(시작, 글쇠 익힘, ... 통계)들이 지금보다 더 큼직하고 시원스럽게 배치되게 했으며, high DPI에서 한글의 아랫부분이 보기 흉하게 짤리던 문제를 해결했다.
• DPI가 200%인가 225%를 넘어간 상태에서 샌드위치 내지 상하 대조 방식으로 긴글 연습을 하면 줄 전체에 꽉 차는 긴 문장이 제대로 찍히지 않고 뒷부분이 씹혔다. 새 버전에서는 이 문제를 해결했다. 물론 날개셋 한글 입력기의 비트맵 글꼴은 150% 배율까지만 크기가 보장되기 때문에 확대 배율을 너무 높게 잡으면 프로그램을 제대로 사용하기 곤란해지긴 한다..;;
• '글쇠 익힘'과 '낱말 연습'에서 쓰이는 손가락 위치 선택 리스트 박스가 high DPI에서도 너무 작게 찍히던 문제를 해결했다.
• '긴글 연습' 화면의 아래에 나타나 있는 도구모음줄(앞/뒤쪽..)도 high DPI에서 버튼들이 너무 비좁고 조밀하게 찍히던 것을 개선했다.

위의 그림에 묘사된 before/after에서 보다시피, 타자연습뿐만 아니라 편집기도 high DPI 환경에서 도구모음줄 아이콘들이 전반적으로 더 큼직하게 찍히게 했다. 편집기의 경우, 계산기 대화상자의 계산 결과 리스트가 high DPI의 글자 크기보다 너무 좁은 줄 간격으로 찍히던 문제도 있어서 이를 해결했다.

한편, 다시 타자연습으로 돌아오면.. 고대비 검정 모드에서 긴글 연습을 하면 disable된 도구모음줄 버튼들이 자기 고유한 형체가 없이 이렇게 사각형으로 뭉개져서 찍히곤 했다. 이를 정상적인 형태로 개선했다(위 vs 아래). 도구모음줄이 상시 표시되어 있는 날개셋 편집기에서는 진작부터 이런 처리를 하고 있었는데 타자연습에서는 지금까지 그 생각을 못 했었다.

이 정도..
이번 새 버전은 이제 정말로 더 고칠 것 없이 오랫동안 잘 쓰였으면 좋겠다.

Posted by 사무엘