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

이번에는 으레 관례적으로 하던 중간 보고(다음 버전 개발 근황) 없이 곧장 새 버전 소식을 전하게 되었다. <날개셋> 한글 입력기 8.6이 나왔다.
이번에도 예외없이 왜 2016년이 다 돼서 인제야 도입됐나 싶은 새로운 기능들이 많이 도입되었다. <날개셋> 한글 입력기는 8.5 때보다 더욱 완전함을 향해 나아가게 되었다.
앞으로 최대 두세 번 정도 더 버전업 해서 9.0 정도는 갈 수 있을 듯하다. 무슨 작업을 더 할지 로드맵은 이미 다 잡혀 있다.

※ IME와 연결되는 키보드 드라이버를 변경하는 기능

<날개셋> 한글 입력기에서는 글쇠배열 편집을 통해 드보락이나 콜맥 같은 다른 외국어 글자판을 같이 쓸 수 있다.
그러나 외부 모듈의 경우, 이것은 IME 방식으로 글쇠를 인식하지 않는 환경에서는 무용지물이다. 단축키나 암호 입력을 그런 영문 글자판으로 할 수는 없으며, 잘 알다시피 IME가 동작하지 않는 모드로서 '쿼티 자판' 내지 '빈 입력 스키마'가 언제나 반드시 추가돼야 했다. 이것 때문에 불편하다고 지금까지 사용자로부터 문의도 많이 들어왔었다.

물론 외부 모듈은 IME로서 자기 영역만 책임지면 되지 굳이 키보드 드라이버의 영역까지 개입할 필요는 없다. 하지만 이번 8.6 버전에서는 한글 IME와 연결되는 키보드 드라이버를 간단하게 바꿀 수 있는 UI가 추가됐다. native 빈 입력 스키마 상태에서 드보락 내지 콜맥을 한글 글자판과 병용하는 사용자에게 굉장한 유용한 기능이 될 것으로 보인다.

이제 외부 모듈에서 제어판을 연 뒤 "시스템 계층 - 고급 시스템 옵션"을 가 보면, "한글 IME와 연결할 영문 키보드 드라이버"라는 콤보 상자가 나타나 있다.
디폴트는 한국어 키보드 드라이버인 kbdkor로, 맨 앞에 있다. 자주 사용하는 걸로 판단되는 드보락과 콜맥은 곧장 2~3순위이며, 나머지 외국어 드라이버들은 이름의 알파벳 순으로 등재돼 있다. 운영체제에 존재하는 모든 키보드 드라이버 DLL들을 자동으로 탐색한 것이다.

이걸 변경한 뒤 제어판을 '확인'으로 닫으면.. 외부 모듈이 직접 레지스트리를 고치는 게 아니라 운영체제의 레지스트리 편집기를 통해서 간접적으로 고친다. HKEY_LOCAL_MACHINE 레지스트리 값을 변경하기 위해서는 관리자 권한이 필요한데, 외부 모듈은 자기가 독립적인 프로그램이 아니라 DLL이기 때문이다. (권한이 없을 수도 있음)

확인 질문에 '예'로 대답한 뒤 운영체제 로그인만 다시 하면 바뀐 글자판이 적용된다. 단, 당장 로그인 암호를 입력하는 기준 영문 글자판부터 바뀌기 때문에 절대 주의해야 한다. 잠시 암호를 없애거나 숫자 기반으로 변경할 것을 권함.

한국어 이외의 다른 외국어 키보드 드라이버에서는 (1) 한국어 키보드에 존재하는 고유한 한영/한자 글쇠를 인식하지 못하므로 단축글쇠 차원에서 Shift+Space 같은 다른 방법을 써야 한다.

(2) 또한, Windows XP 이전의 운영체제에서는 <날개셋> 한글 입력기의 기반 드라이버만이 바뀌지만 Vista 이후부터는 모든 한글 IME들의 기반 드라이버가 이걸로 바뀌어 버린다. 내 프로그램은 문제가 없지만 MS 한글 IME의 경우 한글 글쇠배열까지 영문 글쇠배열을 기준으로 뒤죽박죽 바뀌어 버리기 때문에 타 한글 IME를 사실상 제대로 쓸 수 없게 된다는 점을 주의하기 바란다.

※ 키보드 드라이버의 글쇠를 UI에서도 유동적으로 인식

위의 작업은 그 자체만으로는 그냥 일부 매니아 유저가 손으로 레지스트리를 일일이 고쳐야 했던 것을 더 편하게 해 주는 UI 껍데기를 추가한 것에 불과하고..
더 중요한 건 이제부터다. 이 김에 키보드 드라이버와 관련된 추가적인 연구를 진행했다.
<날개셋> 변환기가 콜맥 키보드 드라이버 드라이버를 불러오려 하면 리가처(일명 dead key) 테이블 쪽에서 버퍼 overflow가 나서 죽던데 이 문제를 해결했다. 해당 드라이버가 리가처들을 이례적으로 잔뜩 갖고 있어 보이긴 했지만, 내 프로그램도 어떤 경우든 당장은 죽지 않아야 하므로.

그리고 획기적인 건.. 제어판 포함하여 내 프로그램에서 글쇠배열를 보여주는 부분에서 기준 글쇠배열이 단순 쿼티 고정이 아니라 지금 사용 중인 드라이버의 배열을 보여주게 했다.
다음 그림을 보면 확실하게 감이 올 것이다. 사용자가 배당한 검은 글자 말고 위의 흰 글자들.. <날개셋> 한글 입력기 1.0 이래로 지금까지 이건 무조건 쿼티 고정이었다. 그러나 현재 키보드 드라이버가 드보락과 연결돼 있으면 이제는 드보락 배열로 표시된다. 세벌식 최종 기준으로 초성 ㅇ은 쿼티의 J 자리에 있지만 드보락에서는 H 자리이다.

키보드 드라이버라는 게 그 본질은 스캔코드와 가상 키코드 사이의 대응 규칙에다가 각종 dead key 조합을 담고 있는 '테이블'이다. 실행 가능한 기계어 코드나 매크로· 스크립트가 들어있어서 보안 문제를 걱정해야 하고, 신뢰성 보장을 위해 디지털 서명이라도 받아야 하는 그런 물건은 아니다. 그래서 Windows 9x 시절에는 키보드 드라이버는 실제로 *.kbd라는 형태의 그냥 데이터 파일이었다.

그러나 NT 계열에서는 키보드 드라이버는 그냥 static한 구조체 포인터를 되돌리는 함수를 구현한 DLL 형태이다. 무슨 다국어 UI DLL처럼 리소스/데이터만 들어있는 DLL도 아니고 엄연히 함수 실행 부분이 일단은 있다. 같은 테이블을 되돌리더라도 각 아키텍처에서 메모리로 직통으로 올릴 수 있게 구조체 멤버 같은 건 적절히 align/padding이 처리돼 있어야 한다.

그리고 바로 이런 이유에서.. 같은 32비트 x86용 드라이버라 하더라도.. 순수 32비트 OS용과, x86-64 OS에서 64비트하고 같이 운용되는 32비트 드라이버는 서로 호환이 되지 않는다. 본인은 이걸 이제야 알게 됐다. 후자는 비록 포인터가 4바이트이더라도 구조체의 포인터들은 32비트가 아닌 64비트 단위로 듬성듬성 padding돼 있어야 하더라. 어쩐지 그래서 콜맥 드라이버도 받아 보면 i386, amd64뿐만 아니라 wow64가 따로 있었구나. 통상적인 DLL을 만들 때는 그걸 구분할 필요는 없었는데 굉장히 흥미로웠다.

※ 단항 연산자

다음 버전에서 추가하네 마네 하면서 떡밥만 날렸던 ++ -- 단항 연산자를 그냥 이 기회에 추가해 버렸다. 덕분에 손 놓은 지 꽤 오래 됐던 복잡한 수식 해석 코드들을 다시 실컷 복습했다. 하지만 작업은 생각만치 복잡하거나 어렵지 않았다.
++얘는 문자열로 표현할 때 +가 두 개 있는 것과 형태를 구분하기 위해, 우선순위 조정이 아닌 다른 사유로 괄호가 필요한 첫 사례가 되었다.
물론 공백만 삽입해 줘도 되긴 하지만, 괄호로 확실하게 구분하는 게 더 보기 좋아서 괄호를 사용하기로 했다.

2008년부터 현재까지 쓰이고 있는 5.0 방식 입력 설정 포맷은 구조 확장으로 인해 더 쓰이지 않는 데이터 청크라든가, 호환성 유지를 위해 누더기 땜질식으로 확장된 청크가 늘어나고 있다. 특히 5.0 이후로 backspace 동작 관련 옵션들은 판이하게 확장되었으며 저장 방식도 바뀌어 왔다. 거기에다 연산자의 추가는 레거시 파일 포맷의 무질서도(?)를 더욱 키웠다.

하지만 파일 포맷을 또 변경하는 건 유니코드에 한글 자모가 더 추가되는 정도의 이변이 발생하지 않는 한, 아직까지는 최대한 억제하고 있다. 이건 우리나라 경제로 치면 화폐 개혁을 하는 것과 같은 급의 파격적인 변화이기 때문이다.
<날개셋> 변환기가 이제 오랜만에 대공사를 해야 할 것이다. 지금처럼 3~4.x를 5.x 포맷으로 바꾸는 게 아니라 5~8.x 포맷을 새 포맷으로 바꾸는 일을 해야 할 것이다.

※ UI

사소한 UI 쪽으로 가면, 모든 대화상자들의 외형을 총체적으로 재검토해서 버튼들의 크기와 간격을 최대한 일관성 있게 재조정했다.
마소에서는 Windows 표준 GUI 가이드라인 차원에서 명령 버튼들의 크기(특히 '확인'과 '취소')를 50*14로 할 것을 권하고 있다. (단위는 픽셀이 아니라 dlu라고 대화상자 내부에서만 쓰이는 추상적인 단위임) 내 프로그램은 그건 준수하지 않고 45*16을 쓰고 있으며, 이번에 크기를 다 그걸로 통일시켰다.

달랑 '확인', '취소' 두 글자.. 영어로 표현해도 OK와 Cancel에 불과한 그 단어를 집어넣기에는 50*14는 너무 납작하기 때문이다. 가로만 너무 길고 세로는 짧다. '맑은 고딕'은 그나마 글꼴 metric의 종횡비가 좀 개선됐지만, 과거 굴림의 경우 그 정도가 더 심하다.
요건 내 프로그램이 의도적으로 Windows 표준 GUI와는 약간 다른 정책을 취하는 부분임을 밝힌다. 사실, 국내에 애초에 그런 것까지 일일이 다 신경쓰고 만들어지는 Windows용 프로그램 자체도 별로 없지만.

그리고 오랫동안 암묵적으로 남아 있는 버그라면 버그인데..
잔상이 생기는 문제를 두 군데 해결했다.
하나는 날개셋 제어판 창을 가로로 쭉 키웠을 때, 날개셋 에디트 컨트롤에만 non-client의 테두리 부분에 남는 성가신 잔상이다. (아래 그림에서 오른쪽을 보라)

난 그리라는 이벤트가 왔을 때 그린 잘못밖에 없는데 왜 이런 현상이 생기는지는 개인적으로 잘 모르겠다.
그리고 또 하나는 일단은 고전 테마에서만 존재하는 문제 같은데, 대화상자 우측 하단에 있는 크기 조절 손잡이가 인근의 버튼 영역을 덮어써서 생기는 잔상이다.

근본 원인을 해결했다기보다는 그냥 경험적으로 문제를 피해 간 것에 가깝긴 하지만, 그래도 예전보다는 UI 경험이 더 개선됐을 것이다. 이 두 잔상은 기술적으로 문제를 피해 간 방식도 서로 완전히 달랐다.

※ high-DPI 지원, 기타

그리고 모든 구현체 프로그램들에 내부적으로 high-DPI aware 플래그를 추가했다. 이건 마소가 제시하는 표준을 준수했다는 점에서 장점이 될 수 있지만 일부 사용자에게는 단점 및 악재가 될 수도 있다.
125% 같은 high-DPI에서 대화상자들이 뿌옇게 확대+보정된 저해상도로 나오는 게 아니라 깔끔한 고해상도로 나올 테니 그건 장점이다. 하지만 편집기의 경우 어떤 DPI에서도 본문 글꼴이 무조건 16*16 픽셀로 찍히기 때문에 고해상도 + 대형 모니터에서는 이제 글자가 너무 작아서 알아보기 어려울 수도 있다.

이건 자체 비트맵 글꼴을 사용하는 내 프로그램의 근본적이고 고질적인 문제이므로 당장 쉽게 해결 가능하지는 않다. 요 특정 윈도우만 확대+보정해서 출력하는 기능이라도 써야 하지 않나 싶다. 호환성의 왕중왕인 Windows API 중에 뭔가 있을 것 같으나.. 높은 우선순위로 살펴보겠다고는 장담을 못 하겠다. 앞서 얘기했듯이 <날개셋> 한글 입력기는 문자 입력 관련 기능만 연구하기도 갈 길이 너무 먼 상태여서 말이다.

저것들 말고도..

• 외부 모듈에서 문자표 대화상자가 가끔 제대로 동작하지 않던 것을 개선했다.
• 기본 입력 스키마의 추가 인식 글쇠를 수정하면 처음에 날개셋문자 값이 무식한 10진수로 찍혀 나오는 엄청난 버그를 왜 인제 발견했는지.. 당장 고쳤다.
  
  
• 제어판의 글쇠배열 편집 페이지에서 '상태변수' 수식은 문법이 틀려도 종료 시에 에러가 찍히지 않게 했다. (어차피 설정 파일에 저장되지도 않고.. 창을 닫는 마당에 에러 체크 따윈 전혀 필요하지 않음)
• 언제부터 이런 어처구니없는 버그가 들어갔는지 모르겠는데.. 편집기가 0바이트인 파일을 아예 열지 못하고 에러 처리하던 버그를 모 사용자로부터 제보 받아서 즉시 개선했다.
• 현재 편집기는 파일을 저장할 때는 원래 있는 파일의 날짜와 크기를 체크해서 내 프로그램이 아닌 외부에서 변경되었으면 그걸 사용자에게 확인시킨다. 그런데 그 다음으로, 열었던 파일을 아무 변경 없이 그냥 닫더라도 파일이 외부에서 변경되었으면(날짜 크기 변경, 삭제) 재저장할지 사용자에게 확인시키게 했다. 단, 애초부터 읽기 전용으로 열지 않았고 하드디스크에 있는 파일에 한해서이다. (네트웍, 이동식 드라이브에서 연 파일은 제외)
• Google 단모음 키보드를 예제 입력 방식으로 추가했다. 기존 두벌식에서 겹자음과 ㅑㅕㅛㅠ만을 제거한 간소화 버전인데 나름 모바일에서의 가성비가 좋다. '하꾜'는 연속 입력이 되지만 '학교'는 중간 딜레이가 필요하다. 천지인처럼 모든 종성에서 타이머를 줘야 하는 게 아니라 ㅂㅈㄷㄱㅅ 요 자음에 대해서만 주면 되는데, 그 값을 글쇠배열 수식에서 소문자 변수를 통해 지정하게 했다.

이렇게 사소하게 고치고 더한 아이템들이 더 있다.
두벌식에서 글쇠 수를 지금보다 더 늘리지 않고 shift도 쓰지 않고 쌍자음 음절 경계 구분 문제를 해결하는 방법은.. 어쩔 수 없이 (1) 타이머를 쓰거나, 아니면 (2) 초성은 다음에 이어지는 모음의 특성을 추가로 이용해서 쌍자음을 구현하는 것 정도가 전부인 듯하다.

※ 타자연습

끝으로 타자연습의 경우, 입력기 프로그램들과 마찬가지로 high-DPI 플래그를 넣었으며 이 외에도,

• 도움말의 '세벌식 만물상 → 운영체제에서 두세벌식 전환을 어떻게 하죠?'에.. Windows 8~10 기준으로 글자판을 전환하는 방법이 지금까지 너무 오랫동안 빠져 있는 것을 확인하여 설명을 추가했다. 확실히 운영체제의 버전이 올라갈수록 전환하는 방법이 더 복잡해져 왔다.
• 좀 심각한 문제이던데, 타자연습을 종료한 뒤에도 잔여 프로세스가 완전히 사라지지 않고 남아 있던 문제를 해결했다. 구형 운영체제에서는 이런 일이 없는 것 같던데 10에서는 문제가 있었다. Windows에서 프로세스는 단순히 실행을 끝내고 리턴만 하는 게 아니라 ExitProcess를 호출해 줘야 어디서나 확실하게 종료되는 듯하다.
• 문장/글 연습에서 사용자가 추가한 디렉터리에 있는 연습글들은 우클릭했을 때 해당 연습글을 (1) 바로 편집하거나 (2) 파일이 있는 곳을 탐색기로 열어서 바로 찍어 주는 명령을 메뉴에 추가했다.

지난 3.5부터는 사용자 연습글을 추가하는 방식이 XML 기반에서 디렉터리-파일 기반으로 확 바뀌었기 때문에 이제 사용자가 연습글 리스트 XML을 직접 고칠 일은 거의 없을 것이다. 그렇기 때문에 인제 와서 큰 의미는 없겠지만, 이번 버전에서는 연습글 경로에서 내부 압축 꾸러미 이름을 식별하는 구분자를 @에서 *로 전격 변경했다.
별표는 파일 시스템 차원에서 절대로 들어갈 수 없는 문자이기 때문에 이제 *.tc 파일 자체가 경로 중간에 @가 섞여 있더라도 이제는 아무 문제 없이 취급 가능하다.

※ 맺는 말

<날개셋> 한글 입력기에 대해 대외적으로 들어오는 의견은 크게 다음과 같은 것들이 있다.

1. 일반 사용자: 타 플랫폼 포팅도 좀 해 달라.
2. 일반 사용자: 요런 요런 상황에서 외부 모듈이 제대로 동작하지 않는다. 심하면 뻑나기까지 한다.
3. 좀 컴덕후 기질이 있는 분들: 오픈소스화해 달라.

그런데 잘 알다시피 이것들은 모두 나로서는 전혀 현실성이 없으며, 예측 가능한 미래에 가능하지 않은 것들이다.

1. 리눅스, 맥 OS, 심지어 안드로이드까지 하나씩 골고루 다 요청을 받았었다. 특히 안드로이드는 그냥 화면 터치만 지원하는 게 아니라 외부 키보드를 연결할 수도 있다. 그렇기 때문에 PC 키보드 지향 입력 시스템인 내 프로그램도 이제 충분히 진입할 여지가 있다.
하지만 알다시피 <날개셋> 한글 입력기는 여러 플랫폼을 지원하는 프로그램이 아니라 반대로 단일 플랫폼에서 여러 구현체(편집기, 외부 모듈, 입력 패드)를 제공할 정도로 Windows에만 특화돼 있다. 한 플랫폼에 올인하면서 입력 기능 연구만 하기에도 본인은 시간이 부족하다. 포팅은 나 혼자서 할 수 있는 일이 아니다.

2. 이런 신고는 십중팔구가 내 자리에서 재연이 안 되는 것들이다. 내 프로그램도 외부 모듈의 짬밥이 이미 10년 가까이 돼 가는데, 기본적인 안정성은 이미 충분히 확보했다. 한글 입력이 전혀 안 되거나 아예 crash가 발생할 정도의 치명적인 문제는 내 프로그램 단독이 아니라 같이 돌아가는 백신이나 보안 프로그램과의 충돌 때문에 발생한다. 그리고 본인은 백신 같은 거 전혀 안 쓰는 사람이다.
내 프로그램이 디지털 서명이 된 채로 배포된다면 이런 문제가 더 줄어들 수 있겠지만 이 역시 아마추어 개인 개발자 차원에서 가능한 일은 아니다. 디지털 서명을 발급받으려면 돈이 드는 건 둘째치고라도 신원 보증을 위해 사업자 등록증 같은 것도 있어야 한다. =_=;;

3. 전에도 한번 입장을 밝힌 바 있지만, 무슨 전세계 오픈소스 진영의 해커 덕후들이 다 한글과 세벌식 자판을 쓰기라도 하지 않는 이상, 오픈소스화한다고 해서 누가 내 프로그램을 타 OS로 짠 포팅해 준다는 보장도 없다. 또한 내 노력에 대한 보상이 돌아오는 것도 아니다. 명예 보상쯤이야 지금 같은 클로우즈드 소스 체계에서도 이미 충분히 받고 있다.
내 프로그램은 심하게 갈라파고스화된 1인 독재 체제에서 폐쇄적으로 개발되고 있긴 하지만, 현실적으로는 이게 최선의 조치이다.

Posted by 사무엘

보다시피 요즘 운동을 빙자한 등산과 여행을 많이 다니느라 올해 상반기엔 프로그램 개발이 많이 더뎠다. 그래서 이번엔 4개월이라는 시간 동안에 버전을 0.1밖에 못 올렸다.
그 와중에도 개발 아이디어는 계속 떠올라서.. 8.x 중후반 정도까지 갈 것 같던 버전업 이정표가 9.0까지는 너끈히 갈 지경이 됐다. 이게 불행인지 다행인지.. 참 총체적인 난국이구나.

입력기와 타자연습의 변화 사항은 지난달에 공지한 것 그대로이고 더 변한 게 없다. 그러니 이전 글을 참고하면 된다. 이벤트 처리 수식은 글쇠배열의 추가 옵션으로 이렇게 깔끔하게 구현됐다. 옵션 3개밖에 없던 대화상자가 옵션이 8개로 늘면서 덩치가 제법 두툼해졌다.

그러니 여기서는 이벤트들 중 "문자 연속 입력 단절 감지하기"라는 개념에 대해서만 추가 설명을 좀 하겠다.

<날개셋> 한글 입력기는 지금까지 전통적으로 조합 상태 여부에 따라서 동일한 글쇠가 서로 다른 문자를 입력하거나(T변수), Bksp가 서로 다른 단위로 한글을 지우는(글자 or 낱자) 것을 지원했다.
그런데 이번 8.5에서는 이에 덧붙여, 굳이 한글이 아니더라도 일명 '타이핑'이라고 불리는 연속된 문자열 입력을 시작했는지, 아니면 그게 단절됐는지 그 타이밍을 알 수 있게 했다. 이것은 굉장히 의미심장한 새로운 기능이다.

연속 입력의 단절은 마우스 클릭이나 화살표 키로 cursor의 위치가 일괄 변경됐을 때, 윈도우의 키보드 포커스가 바뀌었을 때 같은 외부 요인에 의해 발생한다. 텍스트 에디터/워드 프로세서들은 undo도 연속된 문자열 입력은 한번에 없애 버리지만, 이런 단절이 일어나면 보통 undo 단위를 분리한다.
그러니 연속 입력이라는 건 이 undo 단위와도 완전히 같지는 않지만 얼추 비슷한 개념이다. 또한, 한글이 입력(=조합) 중이라면 응당 문자 연속 입력 중이지만, 문자 연속 입력 중이라고 해서 반드시 한글 조합 중인 것은 아닌 것으로 관계가 성립한다.

8.5에서는 Backspace 동작방식 설정 대화상자가 아래와 같이 바뀌었다. 제1동작과 제2동작을 세로로 배열하던 걸 가로 형태로 바꿨기 때문에 대화상자가 예전보다 좀 커졌다.

이번에 새로 추가된 기능은 '연속 입력 상태 여부'이다.
이전 버전까지는 오로지 '한글 조합 중 여부'에 따라서 제1동작(조합 중일 때)과 제2동작(그렇지 않을 때)을 구분했다. 거기에다가 '한 번 정해진 동작을 계속 적용'하는 옵션 하나만이 지원되었다. 이 옵션을 켜면 1과 2 중 한번 정해진 동작이 Backspace를 연타하는 동안 계속 유지되었고, 그렇지 않으면 이전 Backspace의 결과로 인해 한글 조합 여부가 달라지기만 해도 동작 방식이 바뀌었다.

그런데 상태 판단 기준을 '연속 입력 상태 여부'로 바꾸면, 조합 상태를 막론하고 연속 입력 중일 때는 제1동작이 선택되고, 그렇지 않으면 제2동작이 선택된다. 굳이 Backspace만을 연타하고 있지 않아도, 당장 한글을 조합 중이지 않아도 타이핑 중이라면 낱자 단위로 지우고 달라붙기 기능 같은 걸 쓰고 싶다면 이 기능이 굉장히 유용하게 쓰일 것이다. 즉, 한 Backspace 동작의 지속성은 '연속 입력 상태 여부'가 가장 길고, 그 다음이 '조합 여부 + 연타'이며 제일 짧은 건 그냥 '조합 여부' 옵션인 것이다.

그럼 이 '연속 입력 상태' 정보를 Backspace에서만 활용 가능한가 하면 물론 그렇지 않다. 지우기뿐만 아니라 입력에서도 활용 가능하다.
다만, 연속 입력 상태라는 아무래도 한 글자 입력이라는 단위를 초월하는 영역의 정보이다. 그렇기 때문에 이건 <날개셋> 한글 입력기를 사용하는 구현체가 공급해 주지, 한글 입력기가 직접 관리하고 있지는 않는다.

글쇠배열 수식에서 T 변수는 "지금이 조합 중인가?"를 나타내는데, 그런 것처럼 "지금이 연속입력 상태인가?" 같은 정보가 변수로 따로 주어지지는 않는다. 단지, 연속입력 단절이 발생했을 때 이벤트가 발생하고, 그 이벤트 때 특정 수식을 실행시킬 수 있다. 여기서 뭔가 사용자 변수(소문자)의 값을 변화시켜서 그 값의 변화를 감지함으로써 연속입력 단절을 간접적으로 알 수 있다. 이 수식은 글쇠배열의 추가 옵션 대화상자에서 설정 가능하다.

세벌식 글쇠배열과 관련해서 내가 당장 머리에 떠오르는 활용 방법은 최종 배열에 있는 쉼표와 마침표이다.
쉼표와 마침표는 평소에 문장 부호로 많이 쓰이지만 자리수 구분이나 소수점 때문에 숫자 입력 중에도 많이 쓰인다. 그렇기 때문에 Shift를 누른 상태에서도 계속 그대로 입력 가능한 게 좋다. 하지만 그런 제한된 경우 말고 평소에 쉼표와 마침표가 한 글쇠배열에 중복 등재되어 있는 것은 낭비이다.

마치 / 자리에 /와 ㅗ를 조건부로 모두 배당하는 것처럼, Shift+쉼표/마침표는 숫자를 연속 입력하는 중일 때에만 쉼표와 마침표가 찍히고, 나머지 상황에서는 다른 기호나 특수글쇠가 입력되게 할 수 있다. '공통 전처리'와 '연속 입력 단절 이벤트' 수식에다가는 어떤 소문자 변수 플래그를 끄고, 숫자가 입력된 직후에는 그 플래그를 켜게 해서 Shift+쉼표/마침표는 그 플래그의 존재 여부에 따라 서로 다른 문자가 입력되게 하면 된다.

이거 작업을 하면서 Backspace 설정을 저장하는 방식이 바뀌었다. 8.5에서 저장한 입력 설정은 8.4 등 이전 버전에서는 Backspace 옵션이 보존되어 있지 못할 것이다.
그럼 새 기능 소개는 이 정도로 마치고, 지금부터는 미래의 떡밥이랄까 썰이나 좀 나누고자 한다.

썰1. 제5의 빠른설정

<날개셋> 한글 입력기에 '빠른설정'으로는 두벌식/세벌식, 쿼티/드보락이라는 가장 널리 쓰이는 글쇠배열을 낱자 결합과 오토마타까지 한번에 세팅해 주는 '기본 글자판 설정'이라는 게 3.0 시절부터 존재했다. 그 뒤엔 복벌식· 신세벌식과 한글 로마자 입력 방식을 세팅해 주는 추가적인 빠른설정이 2006년에 나온 3.9에서 추가되어 이 형태가 지난 10년 간 유지돼 왔다. 그 뒤, 이번 8.5의 바로 다음 버전에서는 아주 중요한 빠른설정이 하나 더 추가될 예정이다.

내 프로그램 내부에서는 낱자 결합 규칙이라는 걸 오로지 A+B → C 한 형태만을 규정하고 있다. 그러나 한글 입력 방식에서 낱자 결합 규칙이라는 건 한 낱자를 만드는 미시적인 규칙과, 낱자와 낱자를 결합해서 겹낱자를 만드는 거시적인 규칙으로 구분되는 경우가 대부분이다.

PC에서야 키보드에 글쇠 수가 충분히 많으니 어지간한 낱자는 한 타 만에 바로 입력되고 미시적인 규칙은 별로 중요하지 않다. 그러나 글쇠 수가 매우 적은 모바일용 입력 방식에서는 ㅁ+가획 → ㅂ(나랏글), ㅇ+ㅇ → ㅁ(천지인) 같은 미시규칙이 제각각이고, 그 반면 거시규칙은 어느 입력 방식이나 차이가 없다. ㅂ이나 ㅅ 각각의 낱자를 어떤 방식으로 입력하건 겹받침 ㅄ의 입력은 가능해야 하며 ㅂ+ㅅ의 결합으로 ㅄ을 입력한다는 건 변함없다는 뜻이다.

그리고 도깨비불 현상은 미시규칙이 아니라 언제나 거시규칙 단위로 발생한다. ㅄ은 ㅂ과 ㅅ으로 분리되지만 ㅂ이 ㅁ과 가획으로 분리되지는 않으니 말이다. 그리고 휴대전화 입력기들은 backspace도 각각의 입력 단계가 스택에 저장되는 게 아니라 저 거시규칙 단위로 적용되는 편이다. 이런 미시/거시규칙 구분이 없이 정말 임의로 특수 도깨비불을 처리해야 하는 입력 방식은 한글 로마자 방식 정도밖에 없다(ch, l, x 등;;).

물론 <날개셋> 한글 입력기는 특수 도깨비불 규칙과 결합 축약 규칙들을 이용해 저런 동작들을 모두 구현할 수 있다. 그러나 사용자가 거시구조 단위에서 발생하는 파생 동작을 미시적으로 일일이 다 세팅을 해 줘야 한다. ㄶ, ㅀ의 입력을 구현하기 위해 나랏글이라면 중간의 ㄴ+ㅇ, ㄹ+ㅇ 같은 가상의 상태를 모두 넣어야 하고 그런 임시 낱자는 가상 낱자에다 한글 출력 치환까지 써서 표현하는 방법을 정해 줘야 한다. 일종의 노가다이다.

'초· 종성 공유 낱자 결합 규칙' 옵션을 쓰면 초성에는 미시규칙만 존재하고 종성에는 이를 바탕으로 최대 2단계의 거시규칙이 존재하는 일종의 'special case'에만 한해서 위의 작업들을 모두 자동화할 수 있다. 현대 한글을 입력하는 대부분의 휴대전화 입력 방식들이 이 기능의 혜택을 입을 수 있다.

그러나 옛한글까지 동원되면 어떨까? 초성과 종성에 서로 다른 거시규칙이 적용돼야 하고 그 단계수도 3단계까지 있을 수 있는데 이건 답이 없다.
이럴 때 미시규칙으로부터 거시규칙을 곱한 product들을 자동으로 관리하고 가상 낱자, 특수 도깨비불, 낱자 축약, 다단계 낱자 분리 등의 규칙들을 임시 낱자까지 감안하여 일관되게 자동으로 생성해 주는 것이 제5의 빠른설정이 하는 일이다.

제5의 빠른설정은 종성을 입력하는 중에 종성에 존재하지 않는 초성을 입력하려는 시도가 감지됐을 때(예: 옛한글의 정치음· 치두음) 이것을 종성에다 임시로 표현하거나 아니면 초성으로 옮겨 준다.
그리고 '허용 한글 범위' 제약에 걸리지만 중간 과정에서 불가피하게 입력되는 글자들을 자동으로 찾아 주며(예: '썅'을 입력하는 과정에서 '쌰'를 불가피하게 입력해야 하므로),
종성-초성 음절간 연속입력이 불가능한 경우는 말할 것도 없고 미시결합과 거시결합이 충돌하는 경우를 모두 찾아 준다(예: 천지인에서 ㅝ와 ㆌ는 입력 순서가 동일하기 때문에 충돌함)

그야말로 <날개셋> 한글 입력기가 지금까지 꾸준히 추가해 온 복잡한 고급 기능들을 총괄제어하는 끝판왕이 될 것이다.

썰2. 한자의 추가 지원 가능성

말이 나왔으니 말인데..
<날개셋> 한글 입력기는 공식적으로 유니코드의 BMP(기본 외국어 평면) 영역에 있는 28000여 자의 한자에 대해서 독음과 부수에 의한 입력을 지원한다. 한중일 통합 한자, 호환용 한자, 그리고 확장 A까지이다. 그 이상 확장 B부터는 지원하지 않고 있다.

물론 유니코드에 등록된 모든 한자들은 부수, 획수, 음 같은 기본적인 신상 정보가 Unihan이라는 이름으로 인터넷에 공개돼 있기 때문에 소프트웨어 개발자들이 이를 활용 가능하다. 그러나 <날개셋> 한글 입력기에서 유니코드의 모든 한자들을 그렇게 지원하는 것은 현실적으로 쉽지 않으며, 그래야만 할 필요도 없다.

그도 그럴 것이 확장 B부터는 코드 번호가 16비트 범위를 초과하는 surrogate 영역에 있기 때문이다. 이것까지 받아들이려면 한자 처리와 관련해서 16비트 크기를 전제하고 만들어진 파일 구조나 API를 여러 군데 확장해야 한다. 단순히 데이터만 추가로 집어넣어 주면 되는 게 아니라는 뜻이다.

그런데 그 확장 작업이 꼭 필요할 정도로 명분과 가성비가 성립하느냐 하면 그렇지 않다. 내 프로그램은 엄연히 중국어 입력기가 아니라 한글 입력기이고, 한국어 문화권에서는 이미 있는 BMP 영역의 확장 한자도 일상생활에서 거의 쓸 일이 없기 때문이다.
괜히 쓸데없이 한자 후보 목록만 복잡하게 만들고 목록을 불러오는 시간을 잡아먹는다고, 평상시에는 이미 있는 것조차도 오히려 숨기고 4888자 상용 한자만 불러오게 하는 옵션이 따로 있을 정도이다.

독음 입력의 경우 확장 B까지 추가되면 '가, 이, 사' 같은 음은 정말 헬게이트 수준으로 딸려 나오는 한자 후보가 너무 많아질 것이고, 무엇보다도 이런 한자들의 한국어 한자음은 누가 무슨 근거로 제정하느냐 하는 문제가 생긴다. 본인은 이와 관련된 자료를 지금까지 접하지 못했다. 이제 surrogate에 있는 한자들은 현대 중국어에서 막 쓰인다기보다는 그냥 옛 문헌에서나 아주 가끔 등장한 레어템 벽자(僻字)들이거나, 아니면 어디서 인명용으로 인위로 만들어진 듣보잡 글자들이 아닐까 생각도 한다.

다만, 한글 독음은 그렇다 치더라도 '부수로 한자 입력' 기능은 그래도 확장 B의 모든 한자를 입력할 수 있으면 좋긴 하겠다는 생각을 한다. 물론 이건 언제까지나 '한글' 입력과 관련된 다른 기능들이 모두 구현되고 완성된 뒤에나 해 볼 만한 생각이다. 우선순위가 아주 낮은 희망사항일 뿐이다.

한자는 현재 전세계에서 현역으로 쓰이고 있는 문자들 중 유일한 표의/표어문자이며, 정말 다른 문자들은 엄두도 못 낼 엄청난 양의 글자 수를 자랑하고 있다. 자세히 뜯어 보면 한자도 정사각형 안에서 뭔가 심오· 오묘한 제자 원리를 갖추긴 한 듯하지만, 근본적으로 배우기가 너무 어렵고 숫자로 치면 아라비아 숫자가 아니라 로마 숫자 같은 접근을 한 문자이다.
문자라는 게 정해진 유한한 틀과 체계가 없이 중구난방으로 임의 생성이 가능하다면 그건 엄밀히 말해 문자가 아니라 아직 그림의 범주를 못 벗어난 상태가 아니겠는가? 문자표에서 끝도 없이 펼쳐져 있는 한중일 통합 한자 리스트를 보면.. 뭔가 참 막막하다는 느낌이 든다.

썰3. 파일 포맷이 또 바뀐다면?

<날개셋> 한글 입력기가 현재 사용하는 입력 설정 파일 포맷은 2008년에 나온 5.0 버전 때 큰 틀이 잡혀서 지금까지 이어지고 있다. 3.0 방식이 나온 이후로 4년 만에 바뀐 것이다.
이 포맷은 압축을 하지는 않지만(어차피 무슨 이미지나 문서 포맷도 아니고 파일 크기가 굉장히 작음..) 날개셋문자 수식 같은 정보들을 최대한 조밀하게 기록하고 나름 확장성도 생각해서 설계되었다. 하지만 긴 세월이 흐르면서 새로운 chunk들이 덕지덕지 추가되면서 내부 구조가 좀 지저분해져 있긴 하다.

유니코드에 한글 자모가 더 추가되어서 내부 자모 순서가 재조정되는 이변이라도 발생하지 않으면 이 파일 포맷이 가까운 미래에 또 바뀔 일은 매우 희박하다.
만약 파일 포맷을 바꾸게 되면, 그때는 지저분한 chunk들을 정리하고 다음 사항을 반영하려 한다.

첫째, 내부에 저장되는 데이터 중 (1) 한글 입력기의 동작을 실제로 바꾸는 설정/옵션과, (2) 동작에 영향을 주지는 않지만 사용자에게 표시되는 데이터(후보 설명문 같은), (3) 제어판을 열지 않은 이상 사용자에게 전혀 보이지 않는 단순 주석 데이터(오토마타 상태 설명문 같은) 영역을 더 엄격하게 구분해서 필요하다면 (2)나 (3)은 손쉽게 생략 가능하게 할 것이다.

둘째, 이때쯤 수식에 ++와 -- 단항 연산자를 추가해 넣을 의향이 있다. C언어가 제공하는 것처럼 전위형과 후위형 모두 말이다. <날개셋> 한글 입력기의 수식은 C언어 스타일이지만 이런 단항 증가/감소 연산자를 현재 지원하지 않기 때문이다.
이 연산자가 제공되지 않은 이유는.. 단항 연산자는 프로그래밍에서 반복문을 구현할 때 사실 가장 많이 쓰이는데 내 프로그램의 수식은 그렇게 프로그래밍까지 가능한 환경이 아니기 때문이다. 그리고 사용자 변수라 하더라도 한도 끝도 없이 1씩 증가/감소시키는 것보다는 a=(a+1)%N처럼 순환을 전제로 하는 증가가 더 많이 쓰이기 때문이다. 이런 여건을 감안했을 때 ++와 -- 연산자는 딱히 유용하지 않다고 판단되어서 넣지 않았다.

사실, 먼 옛날에는 +=, -= 같은 합성 대입 연산자조차 지원하지 않았다가 지난 4.4 버전에서 10종이 대거 추가되었다. 가감승제 4, 나머지 1, 비트 3 (and or xor), 비트 좌우 이동 2 이렇게 총 10종류이다.
내 프로그램은 내부적으로 연산자의 식별 번호를 우선순위 순으로 부여하고 있는데 새로 추가된 연산자들은 메모리에 저장되는 코드값과 디스크에 이미 저장된 코드값이 달라서 번거롭게 보정을 해 줘야 했다. 마치 문자의 코드값과 사전 배열 순서가 동일하지 않게 되는 것처럼 말이다.

3.x 파일 포맷에서는 합성 대입 연산자들이 나중에 추가된 관계로 그런 보정이 존재했지만, 5.0에서 파일 포맷이 바뀔 때 연산자 저장 방식을 동기화시켰다. 지금 또 연산자가 추가되면 나중에 파일 포맷이 바뀔 때 새로운 순서가 반영될 것이다. ++와 --는 고려 대상이긴 하지만 위에서 언급한 이유도 있고 해서 우선순위가 막 높지는 않다.

썰4. 게임 체계의 개편

예전에 말한 적이 있나 모르겠는데.. 장기적으로는 현재 타자연습에 있는 게임도 체계를 크게 고치려 생각 중이다.
방어력 업그레이드를 없애고, 둠/퀘이크의 아머 내지 스타크래프트의 실드 같은 보조 맷집 정도만 넣지, HP와 관련하여 그 이상 더 복잡한 다단계 체계를 두지는 않을 것이다. 체력을 100 이상으로 비정상적으로 많이 비축해 놓을 수 없게 할 것이다.

그 대신 체력 보충 바이러스가 더 자주 나오고 위력이 강해진다. 한 번만 받아도 어느 주인공이든 전체 체력의 절반이나 전부가 곧장 회복된다. 어려운 레벨에서는 죽기 직전이 됐다가 바이러스 한 방 먹고 살아나는 스릴이랄까 '들쭉날쭉' 기복이 더 커진다. 이를 위해 어쩌면 레벨의 난이도를 지금보다 더 낮출 수도 있다.

현재의 게임 체계는 레벨 1부터 시작해서 체력과 방어력 업그레이드를 무슨 경험치처럼 채워야만 상위 레벨에서 버티기가 더 수월해지는 구조이다. 이걸 타파하려 한다.
주인공들 중 '한별'은 오타 페널티가 있는 대신 저렇게 맷집을 축적하는 게 가장 유리한 주인공이었다. 그 메리트가 없어지는 대신, 점수가 가장 높다거나 다른 방법으로 보상을 줄 생각이다.

한별은 어려운 대신에 잘 다루면 가장 강력한 주인공이고, 미르는 오타를 내도 되는 대신에 다른 페널티가 큰 주인공, 그리고 아름은 그 중간.. 이 구도는 변함없이 유지된다.
그런데 떨어지는 단어를 쳐서 없애는 게임에서 현실적인 변수는 저런 타자의 용이성과 체력 맷집밖에 없는데.. 체력 맷집 체계를 단순화· 평준화시키고 나니 다른 방법으로 주인공별 차별화를 어떻게 시킬지가 고민이다.
현재로서는 머리가 아파서 구상 단계에 머무르고 있다. 아이고~ =_=;;

Posted by 사무엘

<날개셋> 한글 입력기 8.4의 다음 버전은 8.5이다. 6월 말쯤에 나올 예정이다. 아울러, 타자연습도 3.5가 나올 예정이다.

8.5의 변화 사항들은 대부분 GUI 등 사소한 것들이다. 그러나 예전보다 센스 있게 동작하도록 기능이 추가되거나 변경된 건 있어도, 지난 8.4에서 뭔가 크게 잘못 동작하던 것이 바로잡혔다거나 버그가 고쳐진 것은 없다. 그만큼 8.4는 완성도 높게 잘 만들어졌으며 <날개셋> 한글 입력기도 '더 고칠 게 없는' 안정화 고정 단계에 근접한 듯하다.

8.5의 존재 의미라 할 수 있고 한글 입력 엔진 차원에서 바뀐 유일한 과업은 바로 '이벤트 핸들러'의 구현이다. 사실, 8.4에서 들어가려 했으나 이론 검증과 확신이 서지 않아서 차마 마무리를 못 하고 한 버전 더 거쳐 가게 됐다.
입력 스키마(현재 사용 중인 놈 한정)와 보조 입력 도구는 한글 입력 엔진으로부터 다음과 같은 상황에서 7종류의 이벤트를 받아서 이때 자신만의 처리를 할 수 있다. 주로 사용자(소문자 a~z) 변수를 초기화하는 수식이 실행된다.

(1) 시스템: <날개셋> 한글 입력기를 사용하는 프로그램 전체가 활성/비활성화됐을 때. 그리고 외부 모듈의 경우, 해당 UI 스레드 차원에서 IME가 날개셋으로 바뀌었거나 해제됐을 때. on/off 경우에 모두 호출된다. 단, 입력 패드는 언제나 시스템 차원에서 global하게 구동 중이므로 이 이벤트를 따로 보내지 않는다.

(2) 포커스: 한 프로그램 안에서 <날개셋> 한글 입력기를 사용하는 창의 포커스가 여기서 딴 데로 바뀌었을 때. 그리고 외부 모듈의 경우 창 포커스는 여전하더라도 내부적으로 사용하는 컨텍스트가 바뀌었을 때(HIMC). 역시 on/off 때 모두 호출된다.
포커스/컨텍스트가 바뀌었으며 잃었다가 얻었다는 사실 자체만 알 수 있지, 구체적으로 그 값을 구분해서 인식할 수 있지는 않다.

(3) 입력 항목(글쇠배열) 전환: 원래 있다가 교체되는 놈(off)과 새로 지정되는 놈(on)이 모두 이벤트를 받는다. 또한, 제어판을 구동하여 입력 설정이 바뀐 뒤에도 디폴트로 지정된 입력 항목은 처음에 on 이벤트를 받는 게 보장된다.
보조 입력 도구에는 요런 통지를 받는 게 이미 있다. 그래서 '화면 키보드' 도구가 지금 사용 중인 글쇠배열을 실시간으로 업데이트 해서 표시해 준다.

(4) 외부에 의한 조합 강제 종료: 한글 입력 중에 마우스 클릭, 포커스 변경, 우리 입력 스키마가 처리하지 않는 글쇠 등의 이유로 조합이 종료되었을 때 이벤트를 받는다. on/off 개념은 없고 그냥 단일.

(5) 문자 연속 입력 단절: 조합 강제 종료와 비슷하지만 이와 완전히 동일하지는 않은 개념이다. 굳이 조합을 만들지 않더라도 문자를 계속 입력하거나 bksp 하고 있었는데 갑자기 비문자 글쇠나 마우스 클릭, 포커스 변경 등이 감지되면 이 이벤트가 한번 날아온다.

지금도 "bksp 연타 시 한번 정해진 동작을 계속 적용" 옵션이 이 이벤트 비슷한 개념을 사용하고 있다. 그런데 이를 개념적으로 더 확장하여, 굳이 한글 조합 중일 때가 아니라 연속 입력 중일 때에 '낱자 단위로', 연속 입력이 끊어졌을 때는 '글자 단위로' 한글을 지우도록 할 수도 있게 했다.

(6) 변수값 변화: 입력 스키마의 글쇠배열 내지 문자 생성기의 오토마타에서 수식 계산으로 인해 변수값이 바뀐 것을 보조 입력 도구가 알 수 있게 한다.
그래서 보조 입력 도구를 이용해 변수값 디버거를 만들 수 있게 된다. 그리고 '화면 키보드' 도구가 아예 context-sensitive하게 지금 입력되는 문자를 화면에다 업데이트 가능하게 된다. 즉, 복벌식 입력기라면 내부 변수값에 따라 두벌/세벌 모드가 됐을 때 글쇠배열 전체가 두벌식이나 세벌식 모양으로 바뀐다.

(7) 타이머: 지금은 천지인 모바일 입력기처럼 특정 상황에서 일정 시간이 경과했을 때 조합을 강제 종료시키는 기능을 구현할 때 타이머가 제한적으로 지원되고 있다. 타이머는 그 기능을 더 일반화해서 겉보기로 조합은 유지하더라도 오토마타의 내부 상태만 바꾸는 것, 임의의 글자를 입력시키는 것, 타이머를 1회가 아니라 계속 동작시키는 등 더 다양한 처리를 할 수 있게 된다.

이렇듯, 통합적인 이벤트 핸들러는 한글 입력기의 아키텍처에서 매우 중요한 기능이다. 오랫동안 필요성만 인지하고 있었을 뿐 작업을 할 엄두를 못 내고 있던 곳에 대대적인 수정이 가해졌다. 이 기능 하나에다가 다른 UI 쪽의 변화 사항들을 합치면 +0.1 버전업은 충분한 가치와 의미를 지닌다.
이벤트 핸들러 수식을 지정하는 UI는 글쇠배열의 추가 옵션을 지정하는 대화상자에 들어갈 예정이다. 어차피 글쇠배열 내부에서 쓰이는 변수들을 초기화하는 수식이 들어갈 테니 말이다.

이것 말고 가볍게 읽을 만한 새 버전 변화 사항들은 다음과 같다. 8.5가 어서 완성됐으면 좋겠다.

1. 한글 낱자 종류 변환에 filler를 안 집어넣는 옵션

텍스트 필터 중에 '한글 낱자 종류 바꾸기'라는 게 있는데, 이건 호환용 한글 자모(U+31??)와 표준 한글 자모(U+11???) 사이를 변환하는 나름 중요한 기능이다.
표준 한글 자모에는 정규화 규칙이라는 게 적용되기 때문에 자음 하나, 모음 하나만 있을 때에도 초/중성의 빈 자리에는 채움 문자(filler)가 꼭꼭 들어간다. 하지만 채움 문자 없이 호환용 자모를 문자 그대로 표준 한글 자모로 일대일 치환만 해 주는 옵션이 이번 버전에서 추가되었다.

이 옵션을 사용하면 정규화 규칙에 어긋나는 문자열을 생성할 수도 있지만, 한편으로 "ㅎㆍㄴ" 같은 풀어 쓴 호환용 자모로부터 모아 쓴 옛한글을 곧바로 만들어 낼 수 있다. 채움 문자가 없으니 각 자모가 그대로 한 글자를 구성하게 됐기 때문이다.

2. 외부 모듈에서 문자표 대화상자의 동작 방식 변경

<날개셋> 편집기와 외부 모듈은 모두 문자를 입력하는 프로그램이니 키보드에 없는 특수문자를 입력하는 '문자표' 기능이 있다.
편집기야 내부의 모든 데이터 입출력이 100% 자가통제가 가능하기 때문에 문제될 게 없지만 외부 모듈은 문자표로부터 받은 문자를 응용 프로그램에서 보내는 것만 가능하고 그 프로그램이 실제로 문자를 접수하는지를 완벽하게 알 수는 없다.

그래서 문자표라는 대화상자가 키보드 포커스를 얻어 있는 상태에서 본문 창에다가 계속해서 문자를 보내는 게 기술적으로 가능한 프로그램도 있고 가능하지 않은 프로그램도 있었다. 즉, 외부 모듈에서 문자표 대화상자는 사실상 반쪽짜리 기능이었던 것이다. 텍스트 필터가 TSF A급에서만 사용 가능한 반쪽짜리 기능인 것처럼 말이다. 이런 이유로 인해, 이 버튼은 프로그램을 처음 설치했을 때는 기본적으로 도구모음줄에 나타나 있지도 않았다.

이 점을 감안하여 이번 버전에서는 외부 모듈의 문자표의 동작 방식을 바꿨다. 연속 입력 기능을 희생시켰다. 엔터를 누르면 문자표 대화상자는 곧장 닫혀 버린다.
그 대신 글자 단 하나를 입력하더라도 그 기능만은 IME, TSF A/B 등을 가리지 않고, 또 BMP와 surrogate를 가리지 않고 모든 프로그램에서 제대로 동작하게 정책을 바꿨다. 동작을 차라리 이렇게 바꿔 버릴까 오랫동안 고민했는데 결국 이제야 결정을 내렸다.

문자표를 꺼내 놓은 채로 여러 문자를 입력하고 싶으면, 이런 대화상자가 아니라 '보조 입력 도구' 중 하나인 문자표를 사용하면 된다. 얘는 반대로 문자표 내부에서 키보드 조작을 할 수는 없지만, 키보드 포커스를 차지하지 않기 때문에 창이 떠 있는 상태에서도 다른 프로그램의 UI에 영향을 주지 않는 게 가능하다.

3. 문자표에 Ctrl+클릭

요즘은 그냥 클릭에 뭔가 2% 부족한 면모가 있을 때 Ctrl+클릭을 추가하는 게 새로운 UI 트렌드인 것 같다.
후보 데이터를 추가할 때 Ctrl+클릭을 하면 입력된 문자열이 각각의 글자 단위로 따로 후보로 추가된다. 그리고 낱자 결합 규칙에서도 Ctrl+클릭을 하면 추가 후에 입력란의 값과 키보드 포커스가 그냥 클릭과는 다르게 바뀐다.
외부 모듈의 후보 목록에는 Ctrl+클릭(Ctrl+엔터 포함)뿐만 아니라 Shift+클릭도 있어서 단순히 한자 변환뿐만 아니라 한글(한자) 또는 한자(한글) 형태를 지정할 수도 있다.

이와 같은 맥락에서, 문자표에도 Ctrl+클릭 동작을 추가했다.
그냥 '추가'를 누르면 선택된 문자가 본문에 삽입되고 대화상자가 그대로 남아 있는 반면, Ctrl+클릭을 하면 이제 문자가 삽입됨과 동시에 대화상자가 닫히게 했다. 이 기능이 있으니 정말 편하다. 물론 애초부터 연속 입력이 가능한 편집기의 문자표 같은 곳에서 말이다.

4. 글자가 많이 존재하는 부수는 진하게 표시 (부수로 한자 입력 기능)

오늘날 수만 자에 달하는 한자들을 분류하는 데는 부수라는 게 쓰인다. 부수는 총 214개가 존재하는데, 한자에 식견이 있는 분이라면 다 아시겠지만 이 부수들이 골고루 쓰이는 게 아니다. 분포가 전혀 균일하지 않으며, 소수의 특정 부수에만 쏠림이 매우 심하다.

예를 들어 요일을 나타내는 한자들(火, 水, 木, 金 같은. 단 月은 제외), 人, 車, 言, 鳥처럼 만만하고 보편적인 뜻을 가진 부수에는 한자가 수백~심지어 1000개가 넘게 들어있고 새로운 글자가 또 만들어지기도 한다. 그러나 匕, 至, 臣, 牙, 首, 父, 龜, 鼠 같은 나머지 대부분의 부수들은 듣보잡이다. 그 제부수자 자체는 首, 父, 高, 非, 長처럼 아주 기초적이고 친숙한 반면, 거기서 파생된 한자는 거의 없는 경우도 있다.

이 점을 감안하여, 다음 버전에서는 "부수로 한자 입력" 도구에 한자가 매우 많이 들어있는 상위 10% 정도의 부수는 약간 진하게 표시해서 사용자의 눈에 미묘하게 더 잘 띄게 했다.
이것도 시각 피드백을 어떻게 줄지 무척 고민했다. 색깔을 달리 하는 건 제일 간단하긴 하지만, 실험 결과가 좋지 않아서 관뒀다. 이미 색깔로 변별하는 다른 요인들도 있는데(한자의 등급, 현재 선택된 부수와 획수가 같은 부수) 거기에다 색깔 변화를 더 주면 비주얼이 너무 튀고 더 혼란스러워졌다.

그 다음으로 생각한 건, 글자 크기에 변화를 주는 것이었다. 하지만 이 역시 결과가 별로 좋지 않아서 최종적으로는 '볼드' 속성이 낙찰됐다. 요렇게 해 주니 딱 봤을 때 너무 튀지 않으면서도 자주 쓰이는 메이저 부수만 빨리 찾는 데 확실히 도움이 된다. 나만 그렇게 생각하는 게 아니었으면 좋겠다만..;;

5. 타자연습: 계정 import/export, 그리고 파일 기반 custom 연습글

타자연습에는 로그인 화면에서 계정 파일을 다른 디렉터리로 내보내거나 거기서 계정 파일을 가져오는 import/export 기능을 추가했다.
단순한 파일 copy 기능에 지나지 않지만, 사용자 계정을 컴퓨터끼리 옮길 수 있게 하는 건 진작부터 필요했던 기능인데 이제야 도입됐다.
궁극적으로는 서버를 통한 동기화도 지원해야 할 텐데 그건 내 혼자 할 수 있는 일은 아니고..

그리고 거의 10년 가까이 유지되던 연습글 목록 관리 방식이 바뀌었다.
XML 파일 기반인 것은 변함없지만, 이것은 프로그램이 기본 제공하는 고정 붙박이 연습글에만 적용된다.
이전처럼 사용자가 XML 리스트를 직접 고치는 것은.. 이제는 더 권장되지 않는 지저분한 관행으로 deprecate됐다. 프로그램 UI에는 예전과 같은 '연습글 추가/삭제' 같은 버튼과 기능이 사라졌다.

그 대신, 사용자의 custom 연습글은 특정 디렉터리에다가 txt 파일들을 갖다 놓기만 하고 '새로 고침'을 누르면 거기에 있는 것들을 프로그램이 알아서 추가로 등록해 주는 형태로 바뀌었다. 하위 디렉터리가 있으면 물론 그것까지 알아서 찾기 때문에 재귀적인 트리 구조를 만들 수 있다. 디렉터리는 꾸러미, 파일은 연습글로 그대로 대응되는 거다.

custom 연습글은 크게 두 종류가 있다. (1) 이 컴퓨터를 사용하는 모든 사용자가 똑같이 공유하는 놈, 그리고 (2) 현재 사용자 계정에서만 보이는 놈.
(1)의 위치는 답정너로 고정돼 있다. "운영체제의 공용 문서\YmSoft\NgsType"이다. 여기에다가 txt 파일들을 심어 놓으면 <날개셋> 타자연습에서 어느 계정으로 로그인 하건, 아니 로그인하지 않고 익명으로 사용하더라도 연습글들을 볼 수 있다.

또한, 여기에 덧붙여 임의로 지정된 디렉터리를 하나 더 동일한 방식으로 수색하게 할 수 있다. 이 위치는 각 계정별로 달라질 수 있다.
기본 제공되는 보급 연습글은 맨 위에 표시되며 꾸러미가 예전처럼 자주색이다. 그러나 (1) 공용 custom 연습글은 꾸러미가 밝은 분홍색이며, (2) 개인용 custom 연습글은 꾸러미가 파란색이다.

"문장/글 연습" 탭에 가 있는 상태에서 '환경설정' 버튼을 누르면, 예전에는 '외형'과 '타자 연습'이라고 탭이 2개 있는 대화상자가 떴는데, 이제는 '추가 연습글'이라는 제3의 탭이 추가되었다. 여기에서 공용 연습글 디렉터리가 어디인지 정확한 경로를 확인하고 그 창을 탐색기로 열어 볼 수 있다. 그리고 개인 연습글 디렉터리는 위치도 사용자가 지정하고 탐색기로 여는 것도 가능하다. 이제 나만의 연습글을 추가하는 건 이런 식으로 하면 된다.

여담이지만, 이번 버전에서는 기본 제공되는 연습글들도 좀 현실화했다.
잉여도가 너무 높아 보이던 옛한글 연습글을 삭제하고, 성경도 잠언과 요한복음만 남겼다. 잠언은 '슬기로운 이야기' 카테고리에 있던 것을 '영적 생활'로 옮겼다.
우리말 우리글 카테고리에 있던 글들을 삭제하고 '한글 노래' 하나만 남겨서 '마음의 양식' 카테고리에다 옮겼다.
그래도 <날개셋> 타자연습은 안 창호 선생의 글과 김 성모 화백 어록, '어둠에다크에서'가 한 자리에 놓여 있는 타자 연습 프로그램이다. 제작자가 인터넷 병맛 개그를 좀 좋아하기 때문에..;;

* 그 밖에,

(1)
 <날개셋> 편집기는 상태 표시줄(status bar)에 있는 글자판(입력 항목)을 우클릭하면 글자판을 선택하는 메뉴가 나타난다. 그래서 한영 내지 Shift+Space 같은 단축글쇠를 안 누르고도 마우스로 입력 모드를 전환할 수 있다.
그 중 '빈 입력 스키마'는 아시다시피 <날개셋> 한글 입력기가 제공하는 특정 입력 모드가 아니라 그냥 운영체제가 제공하는 IME를 그대로 받아들여서 문자를 입력하는 모드이다.

빈 입력 스키마를 사용하고 있는 상태에서 이 메뉴를 통해 동일한 빈 입력 스키마를 또 선택하면 그때는 운영체제의 한영 상태를 전환하는 기능을 추가했다. 중국어나 일본어 IME를 사용하고 있다면 해당 언어의 자국 문자 모드와 영문 모드가 전환된다.

(2)
대화상자에서 리스트 박스의 아이템을 더블 클릭하면 그 아이템을 고치거나, 그걸 선택한 채로 '확인'을 바로 누르는 shortcut 동작이 수행되곤 한다. 그에 비해 라디오 버튼의 더블 클릭은 잘 알려져 있지 않지만, 이 역시 MS가 권장하는 UI 동작이다. 대표적인 예가 MS Office 프로그램에서 화면 확대 대화상자인데, 100, 200같은 퍼센트를 라디오 버튼으로 선택하고 그걸 더블 클릭하면 곧바로 대화상자가 종료된다.

<날개셋> 한글 입력기는 다음 버전부터 주요 UI에 라디오 버튼의 더블 클릭이 지원될 예정이다. 라디오 버튼의 선택이 해당 대화상자의 동작 방식이나 옵션을 거시적으로 결정하는 대화상자들이 그 대상이다. 대소문자 전환(전환 방식), 기본 입력기 빠른설정(사용할 글자판) 등등에서 아이템을 더블 클릭하는 것만으로 대화상자를 확인 종료할 수 있게 된다.

(3)
Windows의 한글 IME 지원 체계에는 좀 이상한 문제가 있다.
TSF를 응용 프로그램이 직접 지원하는 A급 환경 말고, 그냥 IME 호환 계층을 통해 지원하는 B급 환경에서는..
처음에 2글자 이상의 조합을 만들면 조합이 그냥 끊어져 버린다. 이건 이유는 모르겠지만 운영체제가 한글 IME에 대해서 거의 일부러 강요하는 동작이다. 9x/XP 시절, IME 모듈조차도 안 이랬는데 말이다.

이런 이유로 인해 TSF B급 프로그램에서는 한글 조합은 반드시 1글자짜리 호환용 한글 자모로 시작해야 하고, 2~3글자짜리로 정규화된 표준/옛한글 자모로 시작할 수 없다. 첫 타 이후에 다음 타로 인해 계속된 조합의 길이가 2글자 이상으로 가는 건 괜찮다.
이번 새 버전에서는 TSF B급 프로그램에서 2글자 이상의 조합을 만들려 해서 조합이 끊어졌다면 이를 감지해서 이 현상에 대한 간단한 안내 메시지와 도움말 링크를 표시하게 했다. 그래서 이건 설정 문제이지 프로그램의 버그가 아님을 사용자가 알 수 있게 했다.

(4)
좀 어이없는 실수이긴 한데..
드보락이라는 영문 글쇠배열을 만든 사람은 미국의 교육심리학자인 '어거스트 드보락' 박사이다. Dvorak Simplified Keyboard라는 이름으로 이 글쇠배열이 공표된 것은 1932년이고 특허를 얻은 것은 1936년이다.
하지만 지금까지 <날개셋> 한글 입력기의 빠른설정 UI와, 타자연습 도움말의 '세벌식과 드보락의 관계는?'에는 이게 '안톤 드보락이 1930년에 고안한 글쇠배열'이라고 잘못 소개되어 있었다.

이 사람의 이름은 체코의 작곡가 이름인 '안토닌 드보르작'과 매우 혼동되는 편인데, 그거 영향을 받은 것 같다.
우연히 간단한 구글링을 하다가 이 사실을 발견하고는 바로잡았다. <날개셋> 한글 입력기와 타자연습의 다음 버전에서 반영될 것이다.
이거 실수의 근원을 추적해 보니.. 어이없게도 아래아한글의 도움말이었다. 2007 버전만 해도 글자판 소개에서 드보락 설명을 보면 "쿼티 글자판의 단점을 보완하여 1930년 안톤 드보락 박사가 고안한 글자판"이라고 설명되어 있기 때문이다.

Posted by 사무엘

<날개셋> 한글 입력기 8.2가 나온 지 거의 4개월 만에 또 새 버전인 8.4가 나왔다.
이번 버전도 짬밥이 어디로 간 게 아니라 정말 많은 부분이 개선되고 중요한 기능들이 많이 추가되었으므로 많이 사용하시기 바란다.

API 구조의 변경으로 인해 타자연습도 3.45로 살짝 업데이트가 됐다.

1. 사용자 정의 후보 문자열에 @ 탈출문자 추가

지난 7.0 버전에서는 사용자 정의 후보 기능이 추가되었다. 덕분에 고급 입력기의 사용자 정의 조합이 아니라 일반적인 한글을 입력하고 있을 때도 한자 키를 눌렀을 때 나타나는 변환 문자들을 사용자가 임의로 정할 수 있게 되었으며, 원래 있던 한자 변환 기능과도 병용이 가능해졌다.

한자 후보에 대해서 한자의 훈과 음이 나오듯이 사용자 후보에 대해서도 사용자가 설명문을 기재할 수 있다. 그런데 어떤 문자에 대해서 들어갈 만한 설명 정보라는 게 뻔할 뻔 자인 경우가 많은 관계로, 이번 버전에서는 그 절차를 간편하게 해 주는 탈출문자를 추가했다. 후보 문자열이 딱 한 글자로만 구성되어 있다면 탈출문자를 사용할 수 있다. 기본 입력기의 사용자 정의 후보와 고급 입력기의 사용자 정의 후보에서 모두 동일하게 쓸 수 있다.

탈출문자는 @로 시작한다. @N은 이 문자의 유니코드 번호이다. 그리고 문자가 BMP 영역에 있는 경우, 문자의 유니코드 명칭을 나타내는 @C를 사용할 수 있다. 이건 내 프로그램이 아니라 운영체제로부터 얻어 오는 명칭이다.
다음으로 @H는 이 문자가 BMP 영역의 한자인 경우 훈과 음이다. @ 자체를 표현하려면 @@이라고 쓰면 된다.

사용자 정의 후보의 설명문과 관련하여 뭔가 2% 부족한 게 있다고 지금까지 생각해 왔는데 그걸 탈출문자를 통해서 해결하게 됐다.
그러면 이제 여러 후보들에 대해서 설명문을 획일적으로 [@N] @C/@H 이런 식으로 지정할 필요도 생기는데, 이것도 대화상자 UI 차원에서 가능해졌다. 후보 목록에서 1개 이상의 후보 문자열들을 선택한 후, 위의 ‘후보 문자열 입력란’은 비우고 설명문만 입력한 뒤 ‘추가’를 누르면 선택된 후보들의 설명문이 모두 동일하게 바뀐다.

2. Alt+=를 끄는 보정 기능 추가

지난 8.2에서는 시스템 계층에 ‘키보드 드라이버의 동작 보정’ 기능이 추가되어서 type 1 키보드에서도 오른쪽 Ctrl/Alt를 인식할 수 있으며 반대로 type 3에서도 Shift+Space와 한영을 구분해서 인식할 수 있게 되었다. 이번 버전에서는 그에 덧붙여 Alt+=도 전/반각이 아니라 있는 그대로 인식하는 기능이 추가되었다.

전통적으로 Windows의 한국어 키보드 드라이버는 Alt+=를 전/반각 전환 글쇠로 인식해 왔다. 하지만 오늘날은 이건 거의 안 쓰다시피 하는 잉여 기능이며, 오히려 자기도 모르는 사이에 저걸 누른 뒤에 알파벳과 숫자가 엉뚱하게 입력되어서 사용자를 놀라게 하는 경우가 많다.
이 보정 기능을 켜면 <날개셋> 외부 모듈에서 Alt+=가 눌려도 전/반각 전환을 하지 않게 만들 수 있으며, 편집기 같은 다른 구현체에서는 거기에다 아예 다른 기능을 배당할 수도 있게 된다.

단, 보정 기능은 언제나 택일 형태이기 때문에 이 기능을 기존 type 1/3 한영 관련 보정과 같이 사용할 수는 없다.

3. 다단계 입력 분리

두벌식 글자판에서 음절 경계에 도달했을 때 앞글자 종성과 뒷글자 초성을 구분하는 방법은 여러가지가 있다.
보통은 자음은 종성에 최대한 붙을 수 있는 데까지 결합시켰다가 안 되면 다음 글자로 넘어가고, 모음은 직전에 입력되었던 종성 한 타만 다음 글자의 초성으로 이동하는 '도깨비불 현상'을 일으킨다. 그것보다 더 세밀한 제어가 필요하다면 크게 다음과 같은 방법들을 사용하면 된다.

• 특수 도깨비불(3.9에서): 중성이 입력되어 도깨비불 현상이 일어날 때, 종성 입력 순서와 무관하게 아무 종성과 초성으로 쪼개지게 한다. 한글 로마자 입력기에서 ch, l, x 같은 건 이걸로 구현하는 게 제일 무난하다.
• 초· 종성 공유 낱자 결합(6.0에서): 종성을 2개의 초성을 합성하여 입력하는 구도로 만들어 준다. 낱자 결합 규칙을 훨씬 더 간단하게 만들어도 후속 처리를 프로그램이 알아서 해 주며, 도깨비불도 오른쪽 초성 덩어리 단위로 떼어서(치는 데 몇 타가 들었든) 해 주니 매우 편리하다. 휴대전화 입력 방식은 이걸로 구현하면 된다.
• 조합 종료 타이머(6.0에서): 특정 오토마타 상태에서 일정 시간 이상 동안 타자를 안 하고 가만히 있으면 자동으로 조합이 끊긴다. 천지인 같은 입력 방식에서 '국가/구카' 구분을 위해 사용하면 된다.

그 뒤 이번 버전에서는 "다단계 입력 분리"라는 제4의 메커니즘이 추가되었다.
이것은 도깨비불과는 달리, 초중종 등 동일한 성분의 낱자가 계속 N-1단계까지 입력되었는데.. 제 N째 낱자가 기존 낱자와 결합이 불가능할 때, N만 다음 글자로 빼는 게 아니라 M<N을 만족하는 임의의 M~N단계의 낱자 결합을 몽땅 다음 글자로 옮기고 앞글자는 1~M-1단계까지만 남기는 역할을 한다.
쉽게 말해 ㄺ 다음에 ㅅ을 입력했는데 ㅩ으로 갈 수는 없을 때, ㄺ+ㅅ으로 있는 그대로 분리되는 게 아니라 느닷없이 ㄹ+ㄳ으로 가게도 해 준다.

도깨비불은 두벌식 종성이 입력된 상태에서 두벌식 "중성"이 입력되었고 이로써 오토마타가 0으로 바뀌었을 때 발생한다. 하지만 저건 초중종 같은 성분의 낱자가 입력됨으로써 낱자 결합이 65531이라는 낱자로 도달했을 때 발생한다. 조합 중인 낱자를 0으로 만드는 역할을 하는 65530에 이어 또 다른 특수 낱자가 추가된 것이다.

그런데 세벌식이나 '종성 두벌식'이 아니라 일반 두벌식 형태의 종성이 분리되었을 때는 다음 글자는 종성이 아니라 초성으로 바뀐다. 그렇기 때문에 다단계 입력 분리로 할 수 있는 일의 일부가 바로 도깨비불과 동일하지는 않지만 비슷한 형태의 '두벌식 음절 경계 구분'이 된 것이다. 개념적으로 종성과 다음 글자 초성을 동시에 결합시키는 날개셋문자와도 좀 비슷하나, 형태가 간편한 대신에 자유도가 그것만치 높지는 않다.

현대 한글에서 초성 ㅃㄸㅉ, 옛한글에도 정치음· 치두음 같은 건 초성에만 존재한다. 이걸 초성과 종성에 공통으로 존재하는 낱자의 결합으로 입력할 수 있는데 두벌식으로 종성을 결합하는 도중에 인위적인 음절 구분(조합 종료) 없이 자동으로 초성으로 넘어가는 형태로 입력하고 싶다면 딱 이 기능을 사용하면 된다.

예전 같았으면 '한글 출력 치환'을 이용해서, 여전히 조합이 끊어지지 않은 종성 상태이지만 겉보기로는 정치· 치두음 초성이라고 글자를 임시로 표시해야 했다. 그 뒤 모음이 입력됐을 때 특수 도깨비불 현상 같은 걸로 정치· 치두음 부분을 떼어냈겠지만 지금은 좀 더 직관적인 방법도 생겼다. 자세한 설명은 프로그램의 도움말에 나와 있다. 연속 입력 가능성 판별 기능도 다단계 입력 분리까지 감안해서 동작하도록 알고리즘이 수정되었다.

요건 원래 개발 계획에는 없던 아이디어였는데 꽤나 무겁고 중요한 기능이 되어 버렸다. 이런 기능이 지금까지 없었다. 예정에 없던 기능 때문에 한 달에 가까운 시간이 그냥 훅 가 버렸지만..ㅠㅠ 투자한 시간이 아깝지는 않다.

4. 허용 한글 범위 관련 처리

아무 한글이나 조합이 되지는 않게 하는 '허용 한글 제약'과 관련하여 여러 기능들이 추가· 강화됐다.
먼저, '다단계 입력 분리'가 이 기능과도 연계된다. 가령, '쌰'를 조합할 수 없는 'KS X 1001 완성형 제약'을 사용하고 있는데 ㅑ를 ㅏ+가획으로 입력해서 '쌰'를 만들려고 시도했다면.. '가획'만 넘어가는 게 아니라 "ㅏ+가획"이 한꺼번에 다음 글자로 넘어가게 할 수 있다. 이전까지는 그게 가능하지 않았기 때문에 이 상황에서 그냥 '싸'와 함께 조합이 중단돼 버리곤 했다.

65031 낱자 결합을 통해 일어나는 다단계 입력 분리와는 달리 저 분리는 별도의 옵션이 지정되어 있을 때만 수행된다. 그리고 앞의 분리는 A+B+C+D와 C+D가 모두 가능하다면 A부터 시작해서 최대한 많은 타수를 분리하는 반면, '허용 한글 제약' 관련 분리는 C+D처럼 최대한 적은 타수를 분리한다. 분리의 성격이 서로 다르기 때문이다.

단순히 낱자 결합 규칙이 더 존재하지 않아서 결합 불가일 때랑, 허용 한글 범위 제약에 걸려서 결합 불가일 때를 구분 인식이 가능해진 것은 예전 글에서 이미 언급했으므로 참고하시고..

끝으로, <날개셋> 한글 입력기가 제공하는 "문자열을 글자판 입력으로" 필터는 '허용 한글 범위 제약' 기능을 전혀 감안하지 않고 동작한다. 즉, '똠'이라는 문자를 조합할 수 없는 상태에서도 '똠'을 입력하는 순서를 구해 준다.
그 동작을 약간 변경하여, 이걸 부분적으로 감안하여 동작하게 로직을 바꿨다. 이제는 KS X 1001 제약이 적용된 상태에서는 '똠'은 입력할 수 없는 글자로 간주하여 입력 순서를 찾아 주지 않는다.

그러나 이 기능은 중간 과정에서 생성되는 모든 글자들을 일일이 체크하지는 않는다. 즉, '썅'은 중간의 '쌰'를 입력할 수 없음에도 불구하고 최종 결과물이 입력 가능하기 때문에 입력 순서를 찾아 준다.

5. Backspace 3과 4 지원

<날개셋> 한글 입력기는 한글 입력 과정에서 사용되는 Backspace와 후보(≒ 한자) 변환이라는 명령을 내부적으로 특수글쇠의 일종으로 취급한다. 그런데 그게 하나만 있는 게 아니라 각각 4종류씩 있다.

먼저 후보 변환의 경우, 지난 7.0 버전에서 4개의 용례가 완전히 정착했다. 1은 고정적으로 제공되는 한자 및 특수문자 변환이며 2와 3은 각각 입력기 계층에서 제공되는 내장 및 외장형 후보 변환이다. 4번은 편집기 계층에서 제공되는 공통 후보 변환이며 형태는 내장과 외장 어느 것이든 될 수 있다.
후보 변환 데이터의 성격에 따라(공통인가, 아니면 특정 입력 방식에 종속인가?) 원하는 변환 방식을 고를 수 있다. 그리고 어떤 단계에서 후보가 존재하지 않을 때 이전 단계로(1) 갈 것인지 다음 단계로(4) 갈 것인지 포워딩 방식도 지정할 수 있게 했다. 이런 식으로 후보 변환과 관련해서 생각할 수 있는 customization 방식을 모두 구현했다.

이번 버전에서는 후보 변환에 이어 Backspace에 대해서도 손을 봤다. 예전부터 Bksp 1은 통상적인 bksp 글쇠에 대응하고 Bksp 2는 Shift+bksp에 대응한다는 관행이 정착해 있었지만, 3과 4는 영역이 배당만 됐고 실제로 쓰이지 않았다.
이제는 Bksp 동작 방식에서 '자세히'를 누르면 1, 2뿐만 아니라 3, 4도 다 제각기 동작 옵션들을 지정할 수 있다. 그리고 아무 글쇠에나 Bksp 3/4를 뜻하는 C0|0x8A 또는 0x8B를 배당하면 그 옵션대로 Bksp가 동작한다.

원래 Backspace는 한글 입력기(IME 프로그램)와 응용 프로그램이 공용하는 글쇠이다. 한글을 조합하는 중일 때는 IME가 Bksp를 가로채지만, 조합 중이지 않고 앞 글자에 딱히 달라붙거나 할 필요도 없을 때에는 IME가 Bksp를 가로채지 않고 그냥 응용 프로그램으로 넘겨 준다. 그렇기 때문에 A나 1 같은 문자 글쇠에다가 Backspace 1 같은 걸 배당하면 평소에는 글자가 지워지는 게 아니라 A나 1이 입력되어 버린다. 앞 글자를 지우고 싶으면 이런 고수준의 Backspace n 특수글쇠를 배당하는 게 아니라, Backspace가 수행하는 저수준 동작인 '한 타 지우기, 마지막 단계의 낱자 전체 지우기, 입력 순서와 관계 없이 마지막 단계의 낱자 한 단계 지우기'를 배당하는 게 보통이다.

Backspace 3과 4는 저런 오동작이 없다. 언제나 글쇠를 가로채며, 구현체의 기술적인 한계로 인해 앞 글자를 건드릴 수 없을 때는 그냥 아무 동작 없이 가만히 있기만 한다. 입력기 차원에서 조합 바깥의 앞 글자를 직접 지울 수 없는 환경에서는 T ? C0|0x8A: KY|8 이렇게.. 한글을 조합하고 있을 때만 bksp 3, 아니면 수동으로 bksp 생성(응용 프로그램이 글자를 직접 지우게) 이렇게 bksp 기능을 혼용해도 된다. 이런 방식으로 bksp가 아닌 자리에 bksp의 기능을 독자적인 동작 옵션으로 온전히 이식이 가능하다.

6. 글쇠배열 편집 UI에 시각 피드백 추가

<날개셋> 한글 입력기는 잘 알다시피 기본 입력 스키마에 글쇠배열을 편집하는 기능이 있다. 그런데 상위 옵션의 영향으로 인해, 여기서 글쇠배열을 아무리 고쳐도 그게 실제 입력 때 반영되지 않는 경우가 있다.

• 첫째, '빈 입력 스키마와 호환되게' 옵션이 켜져 있고 현재 편집기가 아닌 외부 모듈/입력 패드 구현체를 사용 중일 때. 이때는 해당 입력 항목은 의도적으로 모든 글쇠를 처리하지 않고 넘기는 '빈 입력 스키마'와 동일하게 동작하므로 자신의 모든 입력 설정들이 무효가 된다.
• 글쇠 인식 옵션에서 기존 글쇠배열의 문자· 숫자· 기호 47개 자리의 일부를 지정하여 다른 용도로 사용하고 있을 때. 여기에는 가로채지 '않게' 하는 것도 포함된다.

이제는 이런 상황에 속하는 글쇠들은 회색으로 흐리게 표시되며, 전부 또는 일부 글쇠가 이런 이유 때문에 동작하지 않는다는 설명문까지 잠시 표시된다. 그러므로 글쇠배열을 고쳤는데도 그게 동작하지 않고 왜 그런지 사용자가 이유를 알지 못하는 상황을 예방할 수 있다.

'빈 입력 스키마와 호환되게'의 영향을 받는 구현체에서 해당 옵션을 켜면 추가 글쇠 인식 옵션이라든가, 고급 입력기의 고급 글쇠 인식 옵션도 다 흐리게 표시되어서 값 편집 불가 상태가 되게 했다. 어차피 이런 기능들이 동작하지 않는 상태가 되기 때문이다. 이번 버전에서는 이런 UI도 추가했다.

7. 그 밖에 사소한 개선과 버그 수정

(1) 편집기에는 한 글자만을 찾는데 찾는 조건을 수식을 이용해서 세밀하게 지정하는 '문자 영역 찾기'라는 기능이 있다.
거기에다가 앞글자 P와 뒷글자 N이라는 변수도 추가해서 사실상 최대 3글자까지 연달아 찾을 수 있게 했다. 마침표가 이어지지 않는 '다'를 찾는다거나, 한글 다음에 이어지는 한자를 찾는 식으로 활용이 가능하다. 문단의 앞에서는 P는 0, 문장의 끝에서는 N은 0이 된다.
또한 내정값으로도 한글 낱자 중에 유니코드 5.2 새 낱자만 찾는 수식도 추가했다.

(2) "한글 낱자 정규화" 텍스트 필터에 꽤 황당한 버그가 있는 것을 발견하여 고쳤다.
NFC 정규화를 시켜서 현대 한글이 옛한글처럼 자모 형태로 풀어져 있는 것을 바로잡고 나면, 그 뒤에 등장하는 옛한글들은 이상한 쓰레기 문자로 바뀌곤 했다.
한글의 정규화 방식이 바뀐 지난 8.0 버전에서부터 존재한 버그였다. 내가 스스로 찾아 낸 건 아니고 사용자의 제보를 통해 확인했다.

(3) <날개셋> 한글 입력기는 영문 UI에서 '한글'을 표기할 때 과거에는 Hangeul을 쓰다가 나중에 Hangul로 바꿨다. 당장 유니코드의 영역 이름에도 Hangul이 쓰이고 외국에서는 eu보다 u가 훨씬 더 널리 퍼져 있다고 판단되어서다.
그런데 프로그램 UI 중 특별히 콤보 박스 안의 항목이라든가, xml에 들어가는 내정값 같은 데에서 여전히 eu 표기가 남아 있는 것을 뒤늦게 자체적으로 확인하여 고쳤다.

(4) <날개셋> 제어판의 낱자 결합 탭에서 '낱자 결합 규칙'을 등록하는 UI에서..
'추가'를 그냥 클릭하면 지금까지 그런 것처럼 새 항목이 추가되고 입력 포커스는 A+B=C 중에 A의 위치로 간다.
하지만 Ctrl+클릭을 하면 A와 C의 값이 서로 뒤바뀌고 포커스는 A가 아닌 C에 가게(교환으로 인해 A의 값을 갖게 된) 했다.
그래서 A+B=C에 이어서 역으로 돌아오는 C+B=A라든가, C+B=D처럼 연타에 의한 후속 조합을 지금보다 더 수월하게 등록할 수 있게 했다.

(5) 끝으로 낱자 결합 규칙, 각종 사용자 정의 조합/후보 목록 등, <날개셋> 제어판에서 Windows 폰트가 아니라 자체 비트맵 글꼴로 출력되는 모든 UI들은..
뭔가 아이템을 추가/삭제하거나 순서를 조정하고 나면 지금까지는 스크롤 위치가 엉뚱하게 바뀌고 선택 막대도 화면 맨 아래에 어설프게 걸친 위치로 바뀌곤 했다. 이것 때문에 지금까지 무척 불편했는데 이걸 드디어 원천적으로 개선했다. 스크롤이 필요 없으면 스크롤이 발생하지 않으며, 선택 막대도 언제나 화면 안에 온전히 출력되게 했다.

Posted by 사무엘

<날개셋> 한글 입력기는 사용자가 어떤 글쇠를 눌러서 만들어 낸 입력 단위를 ‘날개셋문자’라는 계층으로 추상화해서 표현한다. 영문 같은 간단한 글쇠배열이라면 A~Z까지 입력하는 문자 자체가 그대로 입력 단위이겠지만, 한글 입력은 그 이상의 계층이 또 필요하기 때문이다.

먼 옛날 1.x 시절에는 <날개셋> 한글 입력기는 그냥 조합형이라는 1 또는 2 multibyte 기반이었으며, 기본 입력 단위의 크기는 16비트였다. 그 16비트 숫자가 한글 자모라면 그건 한글을 조합하는 입력이고, 그렇지 않으면 조합을 만들지 않는 비한글 입력이니 아주 단순한 구조였다.
그 시절에도 특정 성분을 바로 지우고 앞뒤로 빼내는 ‘특수글쇠’라는 개념이 있었지만 그건 일반 자리에는 배당이 가능하지 않았고 Ctrl 조합에다가만 따로 배당할 수 있었다. 지금 생각해 보면 정말 원시적이고 미개하기 그지없었다.

그 뒤 2.x에 와서는 입력 단위의 크기가 32비트로 확장되었고 초중종성 성분의 크기도 5비트에서 8비트로 커졌다. 덕분에 옛한글과 간단한 가상 낱자도 표현할 수 있게 됐다. 입력 단위는 문자 아니면 특수글쇠(비문자)라는 이분법적인 구분이 생겼다. 하지만 여전히 내부 체계는 1.x와 별 다를 바 없을 정도로 빈약했다.

뭔가 지금과 같은 체계가 잡힌 것은 3.x에 온 뒤부터이다. 문자 코드는 완전히 유니코드 기반으로 바뀌었고, 날개셋문자라는 명칭이 정립됐으며 그 크기도 64비트로 넉넉하게 커졌다.
같은 문자도 한글과 비한글이라는 구분이 생겼다. 한글을 조합하는 데 쓰이는 ㅏ와, 단순히 있는 그대로 입력시키는 U+1161짜리 문자인 ‘ㅏ’를 구분할 수 있게 됐다는 뜻이다.

게다가 종전에는 글쇠배열의 벌식 정보가 글쇠배열 전체에 일괄적으로 적용되는 속성이었던 반면, 3.x부터는 각각의 날개셋문자가 자체적으로 두벌/세벌 정보를 갖게 했다. 도깨비불 현상은 두벌 속성을 지닌 날개셋문자 종성에다가 역시 두벌식 속성을 가진 중성이 결합할 때에만 일어난다. 따라서 한 글쇠배열에 세벌식으로 동작하는 글자(가령, ㅃ, ㅉ, ㄸ)와 두벌식으로 동작하는 글자(가령, ㅂ, ㅈ, ㄷ)가 자연스럽게 공존 가능하다.

3.x에서는 한글의 경우 여러 성분을 한꺼번에 배당해서 입력하는 것도 가능해졌다. 초성+중성 내지 중성+종성 같은 것 말이다. 그리고 자주 쓰이지는 않지만 굳이 한글 자모를 실제로 입력하지 않고도 오토마타의 내부 상태를 강제로 바꾸는 ‘상태 전이’라는 날개셋문자 타입도 추가했다.

그래서 ‘일반 문자, 한글 세벌식, 한글 두벌식, 특수글쇠, 상태 전이’ 이렇게 5종류의 날개셋문자 타입이 정립됐다. 카테고리를 더 나누자면 ‘한글, 비한글, 비문자’ 정도로 요약된다. 그리고 backspace와 한자(후보) 변환은 특수글쇠의 일종인 형태로 개념이 세워졌다.
이 정도면 버전 1~2 시절에 비하면 엄청난 발전을 이룬 것이었다.

그 뒤 날개셋문자에 타입이 또 추가될 일은 거의 없었다. 그러다가 2010년, 5.65 버전에서 다중 입력과 관련된 새로운 타입이 세 종류가 더 추가됐는데, 이것은 모두 나름대로 의미가 있는 것들이었다.

첫째, ‘다중 문자’이다. 기존의 ‘일반 문자’는 문자 하나의 유니코드 포인트 번호를 갖고 있으므로 일종의 UTF-32 스타일이다. 그러나 다중 문자는 UTF-16 방식으로 표현된 유니코드 문자를 최대 6바이트까지 저장하고 있는다.

일반 문자는 숫자 하나로 표현된다는 대표성이 있으며, 최종 변환이나 글쇠 치환등 각종 치환의 영향을 받는다. 그러나 다중 문자는 다수 개의 유니코드 포인트로 표현되는 합자, 옛한글, ‘000’ 같은 문자를 간편하게 표현할 수 있으며, 입력기 내부에서 다른 치환의 영향을 받지 않고 언제나 1~3개의 문자를 있는 그대로 입력하는 역할만 한다. 그러므로 존재의 의미가 충분하다고 볼 수 있다.

둘째, <날개셋> 한글 입력기가 복수 개의 한글 자모를 입력할 수 있다는 점에 착안하여, 그 자모들이 한 글자가 아니라 두 글자에 걸쳐서 입력되게 하는 날개셋문자가 추가되었다. 즉, 초+중+종이 아니라 종부터 입력한 뒤 음절을 끊고 초+중을 입력하는 놈, 그리고 중+종을 입력한 뒤 음절을 끊고 초성을 나중에 입력하는 놈 두 종류가 있다. 얘는 도깨비불과는 무관하므로 세벌식의 파생형이다.

덕분에 2010년대부터는 <날개셋> 한글 입력기가 제공하는 날개셋문자 타입은 8종류로 늘었는데.. 2012년, 버전 6.7에서는 잘 알다시피 두벌식에도 파생형이 하나 추가되었다. 바로 ‘종성 두벌식’ 되시겠다.
C++에서 new operator와 operator new가 서로 다른 용어이듯이, ‘종성 두벌식’과 ‘두벌식 종성’은 <날개셋> 한글 입력기의 내부에서 의미가 다른 개념이다.

지금까지 <날개셋> 한글 입력기가 제공한 두벌식 방식의 날개셋문자는 ‘초성 두벌식’이었다. 종성이 도깨비불 현상을 통해 다음 글자로 넘어갔을 때 초성으로 승격이 됐기 때문이다. 그러나 종성 두벌식은 다음 글자로 넘어갔을 때도 종성이 계속 유지된다.

순서를 바꿔서 ‘두벌식 종성’이라고 하면, 타입이 ‘초성 두벌식’이든 ‘종성 두벌식’이든 무관하게 어쨌든 두벌식이고 종성에 nonzero 값이 있는 날개셋문자를 가리킨다. “두벌식 종성과 두벌식 중성이 만나야 도깨비불 현상이 일어난다. 그런데 그 종성의 타입이 ‘초성 두벌식’이냐 ‘종성 두벌식’이냐에 따라 그 종성은 다음 글자에서 각각 초성이나 종성으로 등록된다.” 이렇게 관계가 정리된다.

세벌식과 두벌식에 대해 각각 이런 파생형 타입을 고안해 낸 것은 개인적으로 굉장히 뜻깊은 업적이라고 생각된다. 전에는 가능하지 않았던 한글 입력기의 새로운 기능이 추가된 것이기 때문이다. 특수글쇠 내지 타자 입력 순서 계산 같은 부수적인 기능들까지 중성 두벌식의 컨셉과 맞춰서 정확하게 동작하도록 로직을 강화하는 작업은 7.x대 중반 버전까지 내부적으로 계속되었다.

그리고 현재까지 <날개셋> 한글 입력기에 마지막으로 추가된 날개셋문자 타입은 바로 2015년 초, 7.9 버전에서 추가된 “글쇠 입력”이다. 비한글과 한글에 이어 ‘비문자’ 분야에도 타입이 또 추가된 것이다.

A라는 글쇠에다가 B를 누르는 날개셋문자를 추가한다면, A를 누른 것 자체는 <날개셋> 한글 입력기가 가로채어지며 응용 프로그램으로 전달되지 않는다. 그러나 이로 인해 B를 누른 동작이 인위로 생성되며, 이것은 <날개셋> 한글 입력기가 처리하지 않고 언제나 응용 프로그램으로 가는 것이 보장된다.

이 기능을 이용하면 간단한 단축키 조작을 할 수도 있고 영문과 숫자의 경우 IME가 아니라 키보드 직통으로 응용 프로그램으로 전달할 수도 있다.
키보드 입력을 생성하는 것 자체를 별도의 날개셋문자 타입으로 독립시키겠다는 생각을 어떻게 하게 됐나 정말 신기하다. 이 타입은 한글 입력과 관계가 있는 게 아니므로 굳이 ‘기본 입력기’가 아니라 ‘빈 입력기’에서도 제약 없이 사용할 수 있다.

이런 긴 과정을 거쳐서 <날개셋> 한글 입력기에는 현재 한글 세벌식 3종류, 두벌식 2종류, 비한글 문자 2종류, 비문자 3종류 이렇게 총 10종류의 날개셋문자 타입이 존재한다. 3.0 시절에 비해 정확하게 두 배로 증가한 것이다.

<날개셋> 한글 입력기의 구현체에 대해 논하자면 1.0때 처음부터 개발되어 온 에디터(since 2000), 2.5 과도기를 거쳐서 3.02때부터 개발된 외부 모듈(since 2004), 그리고 5.3 때부터 등장하여 최근에 많이 발전한 입력 패드(since 2009) 세 종류가 있으며 이들은 특징이 제각각이다.
그런 구현체의 종류 이상으로 <날개셋> 한글 입력기가 입력 단위로 받아들이는 날개셋문자의 타입도 종류가 다양하며 제각각 내력이 있다. 과연 미래에 제11째 타입이 등장할 일이 있을지 궁금해진다.

Posted by 사무엘

<날개셋> 한글 입력기 8.2는 기념비적인 작품이었다. 내부적으로 이것저것 개선 사항이 많았으며, Windows 10 지원에다 후보 변환 프로토콜 관련 작업은 아주 뜻깊은 결실이기 때문이다.

8.2는 한글 조합과 관련된 쪽보다는 키보드 입력을 인식하는 쪽에서 이례적으로 새로운 기능이 많이 추가되었다. 오른쪽 alt/ctrl을 지원하는 것에 대해서 몇 번 건의를 받긴 했지만 지금까지 별 생각을 안 하고 지냈다. 그랬는데 이것을 키보드 드라이버 보정이라는 새로운 기능으로 통합하면 되겠다는 생각이 들자, 결국 예정에 없던 신규 기능으로 들어가게 됐다.
여기에다가 키보드/키패드 구분과 scroll lock 인식 같은 것도 아주 신선한 기능이다.

그 뒤, 8.2의 다음 버전은 8.4로 설정되어 있으며, 이번엔 다시 입력기 내부의 아키텍처를 개편하는 어려운 작업이 한창이다. 내년 2월 말쯤에 내는 것을 목표로 하고 있다.

1. 최종 변환 규칙의 개편

가장 먼저 수술대에 오른 기능은, 지난 3.0 이래로 거의 변화 없이 형태가 동일하게 유지돼 왔던 편집기 계층의 '최종 변환 규칙'이다. 최종 변환 규칙은 수식값을 만족하는 번호에 해당하는 입력 항목에 대해서 아스키 문자의 전/반각을 바꾼다거나 한글 자모를 호환용 자모로 바꾸는 것 같은 간단한 변환을 수행한다.
다음 버전에서는 최종 변환 규칙이 적용되는 조건과 방식이 더 깔끔하게 바뀔 예정이다.

첫째, 수식이 없어진다. A<=2 (첫 세 개의 글자판만), A&1 (짝수 번째 글자판만) 이런 식으로 적용 대상을 지정하는 게 강력하긴 하지만 실제로 쓰이는 경우가 거의 없다고 판단되어서이다. 또한 이런 번호가 붙어 있지 않고 보조 입력 도구가 제공하는 입력 항목에 대해서는 최종 변환 규칙을 적용할지 의문이 생기기도 한다.

그래서 이제는 최종 변환 규칙을 지정하면 모든 입력 항목에 일괄적으로 그 규칙이 적용된다. 수식 같은 거 생각할 필요가 없다. 그 대신, 각각의 입력 항목에서 '기본 입력기' 이상 등급부터는 최종 변환 규칙의 적용을 원하지 않는 경우 옵션을 지정할 수 있다. No라고 옵션이 지정되지 않은 모든 문자 생성기들은 기본적으로 최종 변환 규칙을 적용 받으며, 특히 '빈 입력기'는 그런 옵션도 없기 때문에 규칙이 무조건 적용되게 된다(입력 스키마조차 '빈 스키마'인 경우는 물론 제외. 문자 생성기가 아예 동작하지 않는 상황이므로).

둘째, 조건이 완화된 대신, 적용 범위는 더 좁아진다. 최종 변환 규칙은 (1) '일반 문자' 타입의 날개셋문자, 또는 (2) 한글의 경우 두벌/세벌/종성 두벌식 등등 무엇이건 상관은 없지만 초중종 낱자가 단 하나만 있는 경우에만 한해서 적용된다. '다중 문자' 타입에는 적용되지 않으며, 날개셋문자가 아닌 방식으로 생성된 raw 문자열에도 적용되지 않는다. raw 문자열이란 후보 변환 내지 '고급 입력기'의 '사용자 정의 조합' 같은 걸 말한다.

애초에 반각/전각 변환이나 한글 자모 종류 변환 같은 간단하지만 보편적이고 전역적(global)인 변환만을 의도했던 것이기 때문에 이렇게 범위를 좁히는 게 최종 변환 규칙의 취지를 살리는 데 더 도움이 될 것으로 보인다. 가령, 더 복잡한 형태의 한글을 다른 형태의 문자로 바꾸려면 아예 '고급 입력기'의 '한글 출력 치환'을 사용하면 될 테니 말이다.

이런 이유로 인해 이제는 최종 변환 규칙을 통해 반각을 전각으로 바꾸는 설정을 넣었다 하더라도 '일반 문자' 날개셋문자 외에 다른 방식으로 입력하는 문자/문자열에 대해서는 그런 변환이 일어나지 않는다. 그것들은 언제나 있는 그대로만 입력될 것이다.

2. 오토마타에 T 변수 추가

글쇠배열 수식에서는 잘 알다시피 T라는 변수가 오토마타 상태 번호를 나타낸다. 그런데 이제는 오토마타에도 O에 이어 T라는 변수가 추가되었다. 이것은 한글 조합을 더 계속할 수 없어졌을 때 왜 더 계속할 수 없는지에 대한 추가 정보를 담고 있다.

잘 알다시피 오토마타는 입력된 글쇠의 초중성 정보가 A~C라는 변수에 담겨 있고, 지금 상태에서 무슨 상태로 분기할지를 그 변수 값으로부터 결정하는 수식의 집합이다.
그런데 오토마타상으로는 결합이 계속 가능함에도 불구하고 결합이 가능하지 않은 경우가 크게 두 가지가 있다.

첫째는 말 그대로 낱자 결합 규칙이 더 존재하지 않을 때이다. 가령, ㅋ 다음에 ㅁ을 누른다거나 하면 일단은 답이 없다. 그리고 둘째는 흔한 경우는 아니지만 '허용 한글 제약'에 걸렸을 때이다. KS 완성형 2350자만 조합 가능하게 해 놓은 상태에서 "또" 다음에 받침 ㅁ을 시도한다면 더 진행을 할 수 없다.

이럴 때는 한글 입력기는 A~C에 모두 0을 넣어서 동일 오토마타 수식의 값을 다시 구한다. 이때 수식은 반드시 양수가 아니라 0 이하의 값을 되돌려야 한다. 10여 개의 0 이하 코드값들은 "다음 글자로 자연스럽게 넘어가기", "이 입력을 무시", "무한 낱자 수정" 등 여러 용도로 의미가 예약돼 있다.

A~C 중 적어도 한 성분에 nonzero가 있는 정상적인 상황일 때는 T는 0임이 보장된다. 그러나 오토마타 이외의 사유로 조합을 할 수 없어서 A~C가 0인 상태로 수식이 다시 계산될 때는, T는 1(낱자 결합 불가) 또는 2(허용 한글 제약)가 들어온다.
즉, A|B|C와 T==0은 동치이기 때문에 A~C 낱자 값을 일일이 살펴보기 전에 지금이 정상/비정상 중 어느 상황인지부터 판단하고 싶으면 T 값을 먼저 살펴보면 된다.

T 값을 판단해 보면, '똔' 다음에 '똔ㅁ(받침ㅁ. ㄴ+ㅁ 결합은 없음)으로 가는 것은 허용하지만(0. 다음 글자로) '똠'은 입력되지 않고 ㅁ이 아예 무시되게(-1. 이 입력 무시) 할 수 있다. 두 상황을 구분해서 인식할 수가 있게 되는 것이다. '허용 한글 제약' 기능을 좀 더 창의적으로 활용할 수 있을 것이다.
참고로 진짜로 세 성분 중 단 하나도 nonzero가 없는 빈 한글 날개셋문자는 오토마타에 전달되지 않는다. 새로운 조합을 만들거나 지금 조합을 종료시키지도 않음이 보장된다.

3. 서로 다른 문자의 개수 계산

<날개셋> 편집기에는 블록으로 잡은 텍스트에 대한 간단한 분량 통계를 내는 기능이 도구 메뉴에 존재한다.
줄 수와 UTF16 기준 글자 수는 쉽고 직관적인 통계이고 거기에다 ANSI 인코딩으로(UTF-8도 포함) 변환했을 때의 바이트를 출력해 주는데, 이번에는 텍스트 내부에 존재하는 서로 다른 문자의 수도 추가했다. 즉, "ABCADE"는 글자 수는 6이지만 서로 다른 문자의 수는 5이다.

그래픽 에디터에 이 selection 내부에 존재하는 서로 다른 RGB 색상수가 몇인지 출력하는 기능이 있는 것에 착안하여 저 기능을 구현해 넣었다.
특정 문자 집합으로만 구성되거나 중복되는 문자가 없어야 하는 데이터 테이블을 검증할 때, 혹은 이 문서에 쓰인 서로 다른 한글이나 한자가 총 몇 자인지 궁금할 때 이 기능을 활용하면 된다. 생각보다 요긴할 것이다.
계산 기준은 surrogate까지 감안하여 철저하게 유니코드 코드 포인트이다. 그렇기 때문에 옛한글은 글자 단위가 아니라 낱자 단위로 종류가 계산된다.

4. 정렬 기능의 대소문자 비교 방식 개선

지금으로부터 거의 4년 전에 나온 6.5버전에서는 대소문자 구분이 없이 텍스트를 정렬할 때 문자열을 비교하는 알고리즘을 개선한 바 있다. 동일하게 간주되는 텍스트끼리라도 걔네들 사이에서는 대소문자 기준으로 서열을 둬서 ABCabc가 아니면 AaBbCc가 보장되게 했다. 대소문자 구분을 안 한다고 해서 aABbcC 이렇게 뒤섞이지 않게 했다는 뜻이다.

그런데 그때 작성한 알고리즘에는 좀 문제가 있었다. 그건 같은 문자열들 중에서는 AB Ab ab라고 순서를 딱 보장해 줬지만, AD와 ab를 비교할 때는 여전히 AD를 앞으로 보냈다. 왜냐하면 첫 글자 A와 a 중에서 A가 먼저 처리되기 때문이다.
난 "AB, Ab, ab, AD"를 기대했고 당연히 그렇게 나올 줄 알았는데 실제로 나오는 결과는 "AB, Ab, AD, ab"였다.
왜 이런 문제가 이제야 발견됐는지, 내가 왜 그때 그런 실수를 했는지를 통탄하면서 어쨌든 문제를 고쳤다. 문자열 비교에도 생각보다 교묘한 곳에 복병이 있다.

5. 외부 모듈의 우클릭 메뉴 형태 변경

Windows 8 이래로 외부 모듈은 이제 우클릭 메뉴를 이용해서 입력 항목(입력 모드, 글자판..)을 전환할 일이 많아질 텐데..
입력 항목이 10개보다 적을 때는 입력 항목을 우클릭 메뉴 첫 단계에서 바로 고를 수 있게 했다. 아래 그림에서 왼쪽을 오른쪽으로 바꿨다는 뜻이다. 이렇게 하니까 시각적으로 내지 심리적으로 훨씬 더 좋아 보인다.

'입력 패드'는 키보드 입력도 이제 가능하긴 하지만 그래도 입력 도구가 여전히 더 중요하다 보니, 입력 도구를 우클릭 메뉴의 첫 단계에서 바로 고를 수 있고 글자판은 하위 메뉴에서 고른다.
'외부 모듈'은 반대로 글자판을 첫 단계에서 바로 고르고, 입력 도구는 하위 메뉴에서 고른다. 이런 관계가 딱 정립되었다.

6. 단축글쇠 리스트에서 이동뿐만 아니라 복사도 지원

날개셋 제어판의 설정 중에는 단축글쇠를 관리하는 기능이 편집기 계층에 있고 기본 입력 스키마의 추가 옵션에도 있다. 여기에 등록한 단축글쇠는 딱히 정렬 기준이 있거나 중복 등록 체크를 하지 않으며, 지난 7.7 버전부터는 마우스 드래그로 항목을 이동할 수도 있게 했다. 복수 개의 아이템을 선택해서 끌면 그 아이템들이 한꺼번에 위나 아래로 이동한다.

그에 이어 이번 버전에는 Ctrl+드래그로 복사도 되게 했다.
이미 왼쪽의 입력 항목 트리는 이동과 복사가 모두 지원되고 있었는데 그게 단축글쇠 리스트로까지 범위가 확대된 것이다. 글쇠나 수식이 비슷한 단축글쇠를 여럿 등록할 일이 있을 때 복사를 한 뒤에 다른 부분만 고치는 식으로 편집하면 단축글쇠를 지금보다 더 편리하게 등록할 수 있을 것이다.

이 외에도,
(1) "빈 입력 스키마와 호환되게" 옵션을 지금까지는 '기본 입력 스키마'에서만 지정할 수 있고 '고급 입력 스키마'에는 지정할 수 없었는데, 그 제약이 없어졌다.

(2) 편집기에서 '자동 줄바꿈' 옵션을 끈 상태로 임의의 파일을 열거나, 혹은 스크롤 바가 생기지 않을 정도로 아주 짧은 파일을 연 경우 초기에 문서의 전체 줄 수가 실제 줄 수가 아니라 1로 잠시 잘못 표시되던 버그를 잡았다. 이것 말고도 자체 에디트 컨트롤의 코드를 전반적으로 좀 최적화를 했다.

(3) 지난 7.9 버전부터는 조합 중인 두벌식 한글을 도깨비불 현상이 미리 적용된 형태로 표시하는 옵션이 '고급 입력기'의 '한글 출력 옵션'에 추가되었다. 그래서 일명 '초성 지향 도깨비불'이라는 걸 구현 가능해졌는데, 문제는 "가ㅁ" 상태일 때는 '감'에 해당하는 한자 변환을 할 수 없었다. 지금까지는 그게 가능하지 않다가 이제 다음 버전부터는 글자 단위와 단어 단위로 모두 한자 변환이 가능해졌다.
저 상황에서 예외를 둬서 저것만 가능하게 하는 것은 어렵지 않지만, 더 탄탄한 이론적 근간을 마련해서 문제를 완전히 해결하는 게 쉽지 않아서 지금까지 문제 해결을 보류하고 있었다.

(4) 고급 입력기의 사용자 정의 조합을 이용하여 비한글 외국어 문자를 입력하는 예제로 지금까지 제공된 건 히라가나/가타카나라는 일본어 자료가 거의 유일했는데, 이번에는 일명 'Qwerty Extension'이라는 걸 추가했다.

일본어 자료는 조합 로직 자체가 유의미한 반면, 얘는 후보 데이터들이 본좌이다. 알파벳, 숫자, 기호 등 거의 모든 문자가 곧장 입력되는 게 아니라 조합 형태로 입력되며, a를 조합하는 상태에서 한자 키를 누르면 a에 그야말로 상상할 수 있는 온갖 액센트/변형 부호가 붙은 것들을 선택할 수 있다. -에 대해서는 N-dash, M-dash, 하이픈 등 온갖 바리에이션이 들어있는 식이다.
생각보다 무척 유용하며 예제 입력 데이터로서의 의미도 큰데, 왜 지금까지 이런 게 없었는지 궁금하다. 정 재민 님께서 제공해 주셨다. 설명문 때문에 파일이 생각보다 덩치가 크다.

Posted by 사무엘

<날개셋> 한글 입력기가 8.0이 나온 뒤 거의 4개월 만에 8.2로 버전이 올라갔다. 1.0 이래로 개발 10주년을 자축한 지가 엊그제 같은데 벌써 15주년이 됐다. ㄷㄷㄷㄷ 이번에도 여느 버전업 때와 마찬가지로 온갖 부분에서 자잘한 개선과 변경 사항이 생겼다. 이 8.2는

• 1.0 이래로 개발 15주년 돌파
• 전체 소스 코드가 7만 줄 돌파
• 32비트 msi 배포 패키지가 정확히 2MB 돌파
• 32비트 ngs3.dll 커널 크기가 700KB 돌파

라는 여러 기록을 보유하게 되었다.

타자연습은 변화 사항이 없지만 API 구조와 폰트 로딩 방식의 변경 때문에 불가피하게 재컴파일 업데이트를 하게 됐다. 입력기는 8.2인데 타자연습은 구버전을 계속 사용한다면, 실행은 되겠지만 이제 글꼴 리스트에 글꼴들이 제대로 표시되지 않을 것이며, '고급 입력 스키마/입력기'는 로딩이 되지 않을 것이다. 그러니 타자연습도 부득이 같이 업데이트를 해야 한다.

1. Windows 10 지원

이번 8.2는 Windows 10에서 정식으로 테스트된 최초의 버전이다.
Metro UI에서는 제어판이나 텍스트 필터처럼 데스크톱 GUI를 사용하는 기능들을 모두 사용할 수 없게 막았다. 이건 뭔가 새로운 기능을 추가한 것도 아니고, 지금까지는 굳이 필요하지 않던 안전 체크 오버헤드만이 추가된 것일 뿐이다. 본인은 개인적으로 Metro UI는 왜 존재하는지 모르겠다.

명령 프롬프트에서 한글 입력이 더 진행되지 않던 문제를 고쳤고, 그 상태에서 제어판이 동작하지 않던 문제도 해결했다. (명령 프롬프트는 Metro 앱이 아니기 때문에 제어판 접근이 가능해야 한다.) 두 문제 모두 Windows 10의 명령 프롬프트는 예전 버전과는 영 다른 방식으로 동작하기 때문에 발생했었다.

이 정도 보완만 해 주면 되는 듯하나, Edge 브라우저에서 페이스북의 댓글란에 한글 입력이 제대로 안 되는 것은 기술적으로 해결 불가능한 문제로 남았다. 도대체 입력 문자를 어떻게 넘겨 줘야 MS IME 와 동일하게 동작할 수 있는지 현재로서는 알 수 없다. Edge의 버그에 더 가까운 것 같다.

늘 느끼는 것이지만, Windows에서 한글 입력기를 만드는 일은 프로토콜이 IME에서 TSF로 바뀌면서 무질서도와 난관이 한 10배 가까이 뛰고 더 복잡하고 어려워졌다. 예전에는 뭔가 static하고 write-only이기만 하던 고정 프로토콜에다가 문자열을 넣어서 메시지만 쏴 주면 됐지만 지금은 스레드 동기화부터 시작해서 온갖 복잡한 COM 객체 관리, 게다가 레거시 프로그램에 대한 호환 유지, 스펙대로 동작하지 않는 프로그램에 대한 보정.. 등 지저분함이 이루 말로 표현할 수 없다.
극소수 프로그램에서 드디어 텍스트의 임의 조작이 가능해진 것은 분명 큰 발전이지만, 그것 말고 똥싸 놓은 걸 치워야 하는 것도 많다.

2. 입력 패드에 후보 변환 기능 추가

요 근래엔 <날개셋> 한글 입력기의 제3의 구현체인 입력 패드가 장족의 발전을 거듭해 왔다.
7.9에서는 '화면 키보드' 기능에 눌린 글쇠 표시 기능이 추가되었으며, 이 작업을 발전시켜 8.0에서는 입력 패드가 여타 구현체와 대등한 수준으로 키보드 입력이 가능해졌다. 그리고 이번 8.2에서는 조합 중인 글자 하나에 한해서 한자 후보 변환까지 가능해졌다. 그리고 이 기능을 구현하기 위해 후보 변환 프로토콜을 전반적으로 재설계· 확장하는 대공사가 선행되었다.

지금까지 <날개셋> 한글 입력기가 내부적으로 사용하는 프로토콜은 중간에 후보 변환 요청이 있는 경우, 사용자가 무슨 후보로 변환할지 완전히 응답을 해야(취소하는 것도 포함해서) 다음 단계로 진행이 되는.. 일종의 순차· 동기적인 진행만을 지원했다.

이것은 편집기처럼 한자 후보 목록이 별도의 modal 대화상자로 출력되는 구현체에는 곧장 적용 가능한 만한 반면, 외부 모듈처럼 (1) 후보 목록이 뜬 채로 key 입력을 계속 받아들여야 하는 구현체에는 적합하지 않은 구조였다. 그렇기 때문에 동일 코드의 중복 같은 지저분한 편법이 필요했다. 그런데 외부 모듈과 비슷하게 동작하는 구현체(= 입력 패드)가 또 추가되고, 적합하지 않은 프로토콜을 여기에 또 적용할 수는 없기 때문에 이 기회에 리팩터링을 왕창 하게 되었다.

또한, 기존 프로토콜은 한자 후보 선택을 받은 뒤에 cursor를 이동시키거나 텍스트를 조작할 수만 있었지, (2) 반대 순서의 동작을 시킬 수는 없다는 한계도 지니고 있었다. cursor를 이동시켜서 다른 위치에 있는 글자에 대해 후보 변환을 할 수가 없었다.

아래아한글이나 MS IME에서 '토선생'이라는 단어를 입력해서 '생'을 조합하고 있는 상태로 한자 키를 누르면.. 앞의 '토선'이 선택되고 土船이 후보로 제시된다. 그거 변환을 하고 나면 cursor는 다시 '토선'이 아니라 '생'의 뒤로 딱 되돌아온다.
그러나 <날개셋> 한글 입력기는 cursor 위치는 변함이 없고 뒷부분의 '선생'이 선택되고 先生이 후보로 제시된다. 전자와 같은 동작은 프로토콜 차원에서 근본적으로 구현할 수 없기 때문이었다.

8.2부터는 드디어 이런 한계가 없어졌다. 내 프로그램 역시 MS IME와 완전히 동일한 방식으로 자유자재로 텍스트를 조작하면서 원하는 때에 후보 변환 UI를 modal 형태든 그렇지 않은 형태든 꺼낼 수 있다. 단, 실제로 MS IME와 동일한 방식으로 동작하는 기능 자체는 당장 반영되지 않았고 <날개셋> 한글 입력기의 소스 내부에 #ifdef ... #endif의 형태로 막혀 있다. 일단은 이론적으로 구현 가능해졌다는 것만 입증하고 넘어갔다.

<날개셋> 입력 패드에 후보 변환 기능은 이런 최신 프로토콜을 기반으로 구현되었다. 외부 모듈에 존재하는 후보 선택 UI를 그대로 가져다 쓰는 것을 고려했지만 현실에서의 여러가지 문제점으로 인해 그렇게 하지 않고 또 자체 구현을 했다. 외부 모듈의 후보 선택 UI는 운영체제의 프로토콜과 맞물려서 패드에는 필요하지 않은 오버헤드가 너무 많기 때문이었다.

입력 패드의 후보 선택 UI는 <날개셋> 한글 입력기의 GUI 엔진이 자체 제공하는 리스트박스 컴포넌트를 이용하여 최대한 간결· 단순하게 구현되었다. 외부 모듈의 것과 거의 동일하지만 확장 모드(tab 키)는 지원되지 않으며, 세로쓰기 모드의 지원도 기술적으로 불가능하지는 않으나 구현을 과감히 생략했다.

그 대신 입력 패드의 후보 리스트는 스크롤 막대를 마우스로 누르거나 끌어 보면, 줄 단위 스크롤이 가능하여 좀 더 직관적이라는 차이가 존재한다. 외부 모듈의 그것은 언제나 페이지 단위 스크롤만 된다. 물론 마우스가 아니라 키보드 화살표로 선택막대를 움직이면 페이지 단위로 스크롤된다. 페이지 단위로 이동 후 1~9 숫자를 선택하는 동작도 여전히 고려했기 때문이다.

후보 UI를 구현할 때 같이 구현돼야 하는 중요한 요소 중 하나는 후보 윈도우를 어디에다 표시할지를 결정하는 것이다. cursor 근처 아래에다가 표시해 주는 게 원칙인데, 이걸 hook 프로시저를 통해 알아 와야 한다. 이때는 IME 쪽 인터페이스만 사용하는 게 아니라 오버헤드를 감수하고라도 정확도의 향상을 위해 TSF 인터페이스도 사용한다. 훅킹으로 응용 프로그램에서 TSF edit session까지 요청해 보는 것은 처음이어서 프로그래밍이 굉장히 흥미로웠다. 32비트와 64비트를 구분 없이 모두 잘 지원하는 건 물론이고.

단, 이미 사용하고 있는 시스템의 IME가 한영 내지 한자 키를 가로채고 있으면 키보드 입력 모드에서도 이 입력 패드가 그 key들을 가로챌 수 없다. 그러므로 입력 패드에서 한자 변환을 하려면 F9 같은 다른 위치에다가 C0|0x82 같은 후보 변환 기능을 배당해 놓고 있어야 한다.

3. 글꼴 쪽의 변화

'한메가는본문'이라고 타자기 자형처럼 생긴 한글 글꼴이 지금까지 있었다. 개인적으로는 이것과 Lucida Console 영문 글꼴이 같이 잘 어울린다고 생각했는데, 이번 8.2에서는 이것과 같은 계열인 '한메굵은본문'이 추가되었다. 도스용 한메한글이 출력하던 글꼴을 그대로 재현한 것이다.

한메 계열 글꼴은 초성 5, 중성 2, 종성 3벌로 되어 있어서 도깨비 8*4*4보다 구조가 더 간단하다. 특히 '고'의 ㄱ과 '공'의 ㄱ이 동일해서 더욱 타자기 글꼴 같은 느낌이 나지만, 그렇다고 진짜 샘물이나 타자기 계열만치 과격한 모양은 아니다. 또한, '한솔바탕'과도 좀 비슷해 보이지만 그래도 엄연히 차이가 느껴진다.

그리고 이번에 굵은본문을 분석하고 추가하는 과정에서, 기존 가는본문의 조합 규칙이 몇 년째 잘못되어 있던 것도 같이 발견하여 고쳤다. 당장 '메' 자를 보면 차이를 발견할 수 있다.

잘 알다시피 <날개셋> 한글 입력기는 컴퓨터에서 한글을 '입력'하는 모든 아이디어와 기술을 구현하는 기반 시스템이다. 그런데 편집기는 다른 구현체와는 달리 독자적인 한글 글꼴 출력 시스템도 갖추고 있으며, 특별히 과거에 존재했던 다양한 독창적인 비트맵 글꼴들을 몽땅 한데 재현하는 일에도 덤으로 관심을 두고 있다. 아래아한글, Windows 3.x, mshbios 등. 입력 방식뿐만 아니라 글꼴도 보존 가치가 있는 옛날 데이터가 또 발견된다면 얼마든지 채택되고 추가될 것이다.

그리고 이번 버전에서는, 겉으로 차이가 느껴지지는 않겠지만 글꼴의 전반적인 로딩 방식을 memory-map 기반으로 바꿨다. 그래서 여러 프로그램에서 <날개셋> 한글 입력기 외부 모듈을 사용하고 있고 여러 프로그램들이 동일한 한자 글꼴 같은 걸 중복해서 로딩하더라도, 메모리가 제각각 따로 할당되는 게 아니라 1파일 1메모리가 보장되어 더 효율적으로 동작하게 했다. 뭐, 요즘처럼 메모리가 넘치는 환경에서는 겨우 16*16 비트맵 글꼴 나부랭이는 중복 로딩을 한다 해도 별 부담이 되진 않겠지만 말이다.

4. 변수 N의 의미 확장

기본 입력 스키마가 글쇠배열에다 제공하는 변수로는 P (caps lock 여부), N (num lock 여부), T (오토마타의 조합 상태), D~F (입력 중인 한글 자모)가 있다. T, D~F는 정수인 반면 P와 N은 일종의 0 아니면 1의 boolean값이었다.
그런 키보드 램프의 상태에 따라 서로 다른 문자를 되돌리고 싶으면 해당 변수 값을 토대로 ? : 조건부 수식을 지정하면 된다. caps lock은 그렇다 치더라도 num lock의 경우, 세벌식 글쇠배열의 숫자 자리를 키패드처럼 바꾸는 용도로도 활용할 수 있어서 매우 편리하다.

본인은 이 생각을 아주 오래 전부터 했기 때문에 저건 <날개셋> 한글 입력기의 1.0때부터 있던 기능이었다. 단지 그때는 지금 같은 입력 스키마와 문자 생성기의 계층 구분이 없었기 때문에, 그 기능이 입력 스키마의 변수가 아니라 그냥 입력 옵션 중 하나로 제공되었을 뿐이다.

그런데 이번 버전에서는 옵션을 추가로 줄 경우, N에 num lock (비트 1)뿐만 아니라 scroll lock (비트 2)도 같이 줄 수 있게 했다. 이 옵션이 지정되어 있으면 N은 앞으로 키보드의 상태와 관련된 다른 유의미한 비트 플래그가 도입될 경우 4, 8, 16 같은 식으로 의미가 계속 추가될 것이다.

scroll lock은 사실 굉장한 잉여 램프로 전락해 있으며 caps lock만치 문자 입력에서 중요한 역할을 하지는 않는 게 현실이다. 그렇기 때문에 별도의 독립된 변수를 할당하지는 않고 기존 N에서 비트만 추가하는 것으로 의미를 정했다.
그래도 기능을 일단 만들어 놓으면 이것도 아주 창의적으로 활용하는 사용자가 분명 있으리라고 생각된다.

따라서 이 옵션을 켠 상태에서 num lock만 인식하려면 글쇠 수식을 N ? A: B 이렇게 작성할 게 아니라 번거롭지만 N&1 ? A: B라고 써 줘야 한다.
세벌식 키패드 수식을 생성해 주는 빠른설정 기능은 여기에 맞춰 &1이 추가되도록 알고리즘이 수정되었다.

5. 키보드 드라이버 보정

이번 버전에서는 입력기나 편집기 계층이 아니라 시스템 계층에서 꽤 참신한 기능이 하나 또 추가되었다. 바로 키보드 드라이버의 글쇠 인식을 인위적으로 변조하는 기능이다.
내 프로그램의 내부에는 Shift+Space를 '한영'으로 바꿔서 인식하는 type-3 키보드의 동작을 도로 무효화하는 보정이 있었다. 그런데 이 로직이 편집기와 외부 모듈과 패드의 구현체에 몽땅 중복으로 존재하며, 이것도 켜거나 끌 수가 있게 해야겠다는 생각에 별도의 계층으로 빼냈다.

그리고 type-3 보정뿐만 아니라 type-1 보정도 추가했다. 바로, 오른쪽 Ctrl/Alt를 한영/한자가 아니라 있는 그대로 인식하는 것 말이다. 이로써 한국어 키보드에서도 Ctrl/Alt의 좌우 구분이 가능해졌다. 물론, 아무 보정을 하지 않는 것도 가능하고 말이다. 왜 이런 유용한 기능을 진작에 넣지 못했나 하는 아쉬움이 느껴진다.

그리고 여기서 키보드 드라이버 보정을 한 것은 물론 응용 프로그램이 아니라 <날개셋> 한글 입력기 내부에서만 통용된다. type-1 보정을 했다고 해서 오른쪽 Alt로 응용 프로그램의 메뉴를 바로 열 수 있는 건 아니다.

시스템 계층 설정에는 지금까지 글꼴과 관련된 설정과 기능 몇 가지만 있었는데 '보정 없음, type 1, type 3'이라는 세 항목 중 하나를 선택하는 UI도 추가되었다.
시스템 설정의 내용은 사용자 컴퓨터의 레지스트리에 저장되지, ist/st 같은 파일에는 저장되지는 않는다. '미저장 확인'을 누르면 해당 프로그램이 실행되어 있는 동안만 유효하니, '확인'을 눌러야 레지스트리에까지 저장되어 다음에 프로그램을 재실행할 때도 반영된다.

6. 키패드 글쇠와 키보드 글쇠의 구분 기능

Scroll lock 지원과 키보드 드라이버 보정. 이번 버전엔 어쩌다 보니 키 입력 인식과 관련된 기능이 여럿 추가됐는데, 이것만 들어가기에는 좀 아쉽다.
이번 8.2에서는 <날개셋> 한글 입력기의 개발 역사상 최초로 일부 글쇠에 대해 키패드 글쇠와 키보드 글쇠를 구분해서 인식할 수 있게 되었다.

그 대상은 바로 상하좌우 화살표(4) + Home/End/Pg Up/Pg Dn(4) + Ins/Del(2) + 엔터 이렇게 총 11개이다.
단축글쇠 배당 대화상자를 열어서 이들 키를 누르면.. 오른쪽에 종류를 묻는 콤보 상자가 추가로 뜬다. 사용자는 종전처럼 "구분 없이 아무 거나 인식"을 선택해도 되고, 키보드 것만 혹은 키패드 것만 인식하게 설정할 수 있다. 문자 키와 키패드 사이에 따로 몰려 있는 구역도 '키보드' 영역이다.

그리고 고급 입력 스키마에서는 바로 N 변수에서 1(num lock), 2(scroll lock)에 이어 4가 이 글쇠의 변별을 담당한다.
Windows의 키보드 메시지에서 extended key 플래그가 바로 여기에 전달된다. 다른 글쇠들은 키보드 글쇠일 때 플래그가 켜져 있지만, 엔터만 유일하게 키패드 글쇠일 때 플래그가 켜져 있다. 여기에는 사연이 좀 있다.

extended key란 예전의 84/86키 키보드에는 없다가 지금과 같은 101/103키 키보드에서 중첩되어 새로 추가된 key를 나타내는데, 예전에는 키패드에 엔터가 없다가 나중에 키패드에 새로 추가됐기 때문이다.
그 반면, 나머지 home, end 같은 건 원래 키패드에만 있다가 나중에 별도의 구역이 또 추가된 것이기 때문에 '키보드'에 속하는 구역의 글쇠들이 extended이다.

아무튼 이런 옵션과 변수를 통해서 단축글쇠와 고급 입력 스키마에서 모두 키보드와 키패드를 구분해서 글쇠를 인식할 수 있다.

7. 보조 입력 도구

끝으로, 사소한 사항으로는..
보조 입력 도구인 '부수로 한자 입력'에서 부수나 한자를 우클릭했을 때 해당 글자를 클립보드에 복사하는 명령을 추가했다. 지금까지는 이 명령이 문자표에만 있지 부수 한자 입력에는 없었다.

그리고 문자표에는 알다시피 문자를 운영체제의 특정 글꼴로 출력하거나 내장 비트맵 글꼴로 출력하는 옵션이 있는데, 제어판의 시스템 계층에서 설정된 그 후보 출력용 글꼴을 지정하는 옵션도 추가했다. 지금까지 이런 기능이 왜 없었는지 모르겠다.
이들 보조 입력 도구는 지금으로부터 5~6년 전, 5.5x 시절에 처음으로 도입되었다. 참 격세지감이다.

위의 신규 기능들을 구현하는 과정에서 꽤 황당한 버그가 오랫동안 남아 있던 것을 발견했다.
원래 날개셋 제어판을 열었다가 '확인'을 눌러서 닫으면 입력 설정만 저장되는 게 아니라 모든 플러그 인들의 설정도 파일로 저장된다. 텍스트 필터들의 내부 설정들이 여기에 포함되며, 문자표는 사용자가 예전에 선택한 글꼴과 view 모드를 이 방식으로 기억하고 있는다.
그런데 64비트 에디션은 그런 플러그 인 기능들을 설정을 변경한 뒤 사용하고, 날개셋 제어판을 '확인'을 눌러서 닫았는데도 해당 프로그램(편집기 같은..)을 재실행했을 때 예전 설정이 보존되어 있지 않았다. 파일 오프셋과 관련된 착오가 있는 것을 확인해서 즉시 고쳤다.

Posted by 사무엘

1. Windows 10

그 이름도 유명한 Windows 10을 본인도 드디어 입수했다. Mac OS와 Windows 모두 10을 최종 메이저 버전으로 설정했다는 게 무척 흥미롭다.

개인 컴은 물론이고 회사 컴도 평소에 활발하게 쓰던 물건은 "Windows 10 다운로드 준비가 끝났는데 설치할까요?"가 진작부터 뜬 반면,
평소에 잘 안 쓰고 "여기에나 한번 10을 깔아 볼까?"라고 정작 비워 놨던 컴은 한참을 기다려도 Windows 10 설치 말이 없었다. "준비되면 알려 주세요"를 몇 번이나 클릭했는데도 감감 무소식. 이것도 평소에 로그인 횟수나 네트워크 트래픽을 감안해서 업데이트 순서를 짠 건지는 모르겠다.

참다못해 Windows 10 설치 프로그램을 직접 다운로드 해서 실행한 뒤에야 운영체제를 7에서 10으로 바꿀 수 있었다. 다운로드와 설치는 물론 금방 끝난 건 아니지만, 그렇다고 Windows 8.1을 설치하던 시절보다 터무니없이 오래 걸리지는 않았다.

설치 직후에는 바탕 화면의 personalize가 되지 않았다. 인증이 필요하대서.. "으잉? Windows 10은 완전 무료 아니었나? 자동 업데이트를 안 하고 수동 설치를 해서 그렇나?" 어리둥절했는데 재부팅을 한번 하고 나니 인증은 저절로 패스 됐고, 까맣던 배경 그림은 10을 설치하기 전의 모습으로 되돌아왔다.

비주얼에 대한 소감은..
프로그램의 제목이 가운데가 아니라 왼쪽 정렬로 돌아왔으며, 글씨 크기도 약간 더 크다가 다시 메뉴 글씨 크기와 동일하게 돌아왔다. 또한 화면을 부분만 차지하는 시작 메뉴가 되돌아왔으며 프로그램 창 주변에 그림자 그러데이션이 생긴 것은 일면 과거의 Windows Vista/7 시절로의 회귀를 떠올리게 한다.
창의 최소/최대화와 닫기 버튼이 굉장히 커지긴 했는데 정작 _ □ X 모양은 너무 대충 그려 넣은 듯. -_-;;

명령 프롬프트가 가로폭 조절이 가능해진 것이 무척 인상적이다. 하지만 글꼴은 여전히 제대로 customize가 안 된다. 하다못해 먼 옛날 9x 시절에는 코드 페이지가 무엇이냐에 따라 Courier New나 Lucida Console이라도 볼 수 있었는데 너무 칙칙한 글꼴은 오히려 NT 계열이 9x보다도 퇴보했다.

운영체제를 업데이트 한 직후, 이전까지 사용하던 프로그램들은 10에서도 거의 그대로 곧장 사용이 가능했다. 그러나 <날개셋> 한글 입력기는 편집기만 남아 있고 외부 모듈은 운영체제의 IME 목록에서 사라졌다.
허나 이건 프로그램을 재설치만 하면 해결되니 그리 심각한 문제는 아니다. 또한 지금까지 파악한 바로는 Windows 10은 문자 입력에 관해서 딱히 기술적으로 크게 바뀐 게 보이지 않는다. 심지어는 세벌식 파워업도 10의 MS 한글 IME를 대상으로 잘 동작한다.

2. <날개셋> 한글 입력기에서 발견된 문제

다만, <날개셋> 한글 입력기가 Windows 10에 대비하여 개선해야 할 사항은 크게 두 가지가 발견됐다.

(1) 첫째, Windows 10은 Metro 앱도 데스크톱에서 뭔가 일체형으로 연계하며 동작하게 된 듯하다. Windows 10의 상징이라 해도 과언이 아닌 엣지(Edge) 브라우저도 기술적으로는 Metro 앱이다. Metro 모드에서는 클래식 데스크톱 GUI를 사용하는 기능들이 동작하지 않는다. 고로 <날개셋> 제어판이나 About 대화상자 같은 것도 못 띄운다. (그걸 시도하면 그냥 씹히거나 프로그램 전체가 그냥 튕긴다)
8 시절에는 메트로 앱들은 데스크톱의 입력 도구모음줄에 접근을 할 수 없으니 신경 쓸 필요가 없었는데, 이제는 메트로 모드에서는 이런 기능들을 건드릴 수 없도록 도구모음줄 버튼이나 메뉴를 흐리게 처리해 줘야겠다.

날개셋 말고 다른 IME들은 이 문제를 어떻게 해결했느냐 하면 한글 IME는 아예 대화상자가 출력되는 명령들을 모조리 없애 버렸다. 심지어 8에는 있던 About 명령조차도 없앴다. 일본/중국어 IME는 GUI가 나오는 기능들은 몽땅 다른 프로그램을 통해 실행되게 되어 있다.

사실, 한글 IME도 부수/획수 한자나 필기 인식 같은 보조 입력 도구는 별도의 프로그램을 통해 구동한다. 그러나 내 프로그램은 이런 것들이 다 in-process 형태로 구동된다. 그래서 Metro 모드 같은 데서는 여러 제약이 걸리는 것 같다. 금방 해결 가능한 문제는 아닌 것 같고 프로그램 구조를 앞으로 어떻게 유지할지 생각을 해 봐야겠다.
참고로, 엣지 브라우저 자체는 크롬의 마소 버전이라고 생각해도 좋을 정도로 "빠르고" 산뜻해서 느낌이 굉장히 좋았다. 그거 하나는 인정한다.

(2) 둘째, 엣지에서 페이스북에 접속해서 댓글을 써 보니, 한참 글자를 입력하다가 비한글 문자를 입력하는 순간, 예전에 입력 중이던 글자가 몽땅 사라지는 문제가 있었다. "가을에." -> "에."만 남는 식.
또한 명령 프롬프트에서도 내 프로그램으로 한글을 입력해 보면, 조합하던 글자가 덮어써진다. "가" "가을" "가을에"가 되는 게 아니라 "가" "을" "에". 신기하게도 MS IME로 한글을 좀 입력하다가 다시 날개셋으로 돌아오면 명령 프롬프트는 이 문제가 없어짐.

100% 재연 가능하고, MS IME는 안 그런데 내 프로그램만 그렇고.. 현상 자체는 완벽하게 파악이 됐지만 이건 또 MS가 무슨 농간을 부린 건지 허무한 생각이 든다. 아마 둘 다 같은 원인 때문일 거라고 추측만 하는데.. 제일 골치 아픈 부류의 문제이며 해결이 쉽지 않을 수도 있다.

3. key의 인식 방법과 관련된 customization

이건 Windows 10과는 관계가 없는 다른 얘기이다.
<날개셋> 한글 입력기는 한글을 생성하기에 앞서서 key 입력을 인식하는 방식 자체를 사용자화 가능하다. 크게 다음과 같은 시나리오가 있다.

(1) 원래는 먹던 특정 key를 먹지 않게 할 수 있다: 표준 두벌식의 경우 오로지 A~Z 26개 key만 사용하기 때문에 나머지 숫자와 기호는 따로 IME가 가로채는 게 아니라 그냥 응용 프로그램으로 넘겨서 숫자나 기호를 입력하게 한다.

(2) 원래는 먹지 않던 특정 key를 IME 입력으로 바꿀 수 있다: space의 경우, 굳이 IME가 처리할 필요가 없는 key이다. 하지만 인디자인 버그 같은 걸 해결하기 위해서 IME가 굳이 가로채어 공백을 되돌리게 할 수 있다.

(3) 특정 key를 IME 입력 대신 다른 key로 바꿀 수 있다: 내 프로그램으로 드보락 글쇠배열을 사용하는 경우, 보통은 드보락 방식대로 IME가 알파벳을 보내게 한다. 하지만 글쇠 누름 날개셋문자를 사용하면 아예 해당 알파벳 key 입력을 응용 프로그램에다가 보내게 할 수도 있다.

쉽게 말해 비한글 알파벳이나 공백 같은 문자를 IME 방식으로 보내느냐, 그렇지 않고 더 원초적인 key 메시지 형식으로 보내느냐를 제어할 수 있다는 뜻이다.
단축키 같은 것은 key 입력 메시지 형태로 온 것만 인식되지 IME 방식으로 전달된 문자로는 인식되지 않는 경우가 많기 때문이다. MS Excel의 경우, 영문을 key 입력 형태로 입력했을 때에만 함수의 목록 자동 완성이 처리되지만 IME 방식으로 입력된 것에는 반응하지 않는다.

(1)과 (2)는 6.5 버전에서 기본 입력 스키마에 해당 기능이 추가되고 구현됐다. 한편, '글쇠 누름' 날개셋문자는 비교적 최근인 7.9 버전에서 추가되었다.
현재 개발 중인 8.2 버전은 (3)이 소개하는 '글쇠 누름' 날개셋문자의 사용을 홍보하기 위해, 제어판의 글쇠배열 편집 창에서 숫자/문자를 입력하는 '일반 문자' 날개셋문자를 그에 상응하는 '글쇠 누름' 날개셋문자로 자동으로 모두 바꾸는 기능을 추가했다.

그리고 더 간단히, 사용자가 누른 key에 해당하는 글쇠 누름 날개셋문자를 자동으로 입력시키는 모드도 추가했다. 예전에는 세벌식 한글, 두벌식 한글, 이동, 영문 알파벳 같은 모드가 있었는데 그런 것처럼 새로운 모드를 넣었다는 뜻이다. 아주 자연스럽게 기능 확장이 가능하다.

또한 (2)를 더 쉽게 설정할 수 있게 하기 위해, 단축글쇠를 입력받는 대화상자에다가는 지금 누른 가상 키코드의 문자값에 해당하는 '일반 문자' 날개셋문자를 자동으로 배당하는 기능도 추가했다.
알파벳이나 숫자를 key 입력으로 보내는 것과 IME 문자열로 보내는 것의 차이에 대해서는 도움말에다가도 더 자세한 설명을 넣을 예정이다.

4. 고기 먹고 싶음 -_-

아직 어쩔 수 없는 여름이긴 하지만 그래도 날씨가 예전보다 덜 더워져서 무척 좋다.
난 어릴 때부터 왜 태양이 긍정적인 심상이고 그늘이 부정적인 심상인지를 이해를 못 했을 정도로 몸에 열이 많고 더위를 싫어했다.

이제 좀 가을이 되고 나면 날씨 탓할 일 없이 더 집중해서 코딩을 진행하고 싶은데.. 프로그램 완성의 꿈은 요원하기만 하다.
도깨비불 현상 없는 입력 방식이 심리적으로 무척 도움이 된다. 세벌식은 없어질래야 없어질 수 없고 없어져서는 안 되는 한글 입력 방식이다. 뭐 그건 그렇고..

나만 저렇게 생각하는 게 아니었구나.
돼지는 훌륭한 단백질 공급원이고, 단백질은 훌륭한 스트레스 해소원이다.

그래서 위대한 령도자 세종대왕도 약을 빨거나 한 건 아니고 고기를 드시면서 한글을 창제하시였다. 한글이 없었으면 내 프로그램도 없었겠지.
(다만, 그 덕분에 저분은 세자 시절부터 굉장한 비만이었으며, 당뇨 같은 성인병도 평생 달고 살았다고 함. 본인도 키에 비해서는 좀 과체중인 상태..;;)

Posted by 사무엘

요즘 날씨는.. 최악의 불볕과 최악의 찜통은 별개 개념이라는 걸 온몸으로 입증해 보이는 듯하다. 미치겠다.;;
이렇게 이번 여름방학도 벌써 절반이 넘게 지났고 <날개셋> 한글 입력기 8.0이 나온 지도 역시 한 달이 좀 넘었다. 그 동안 서적 번역 등 다른 일에 관심이 쏠려 있어서 방학 전반부 동안은 사소한 이슈 말고 굵직한 기능을 설계하고 구현하는 코딩은 거의 못 하고 지냈다.

그래도 지금까지 지켜본 바로는 8.0은 별다른 새로운 버그 없이 높은 완성도로 잘 만들어졌다. 이 프로그램도 가까운 미래에는 꿈에도 그리던 전체 신규 기능 개발 완료와 고정· 정착 단계에 진입하는 게 아주 요원한 꿈은 아닐 것 같다.
국민 교육 헌장을 보면 "안으로 자주독립의 자세를 확립하고, 밖으로 인류 공영에 이바지할 때"라고 나와 있는데, 실상은 "안으로는 약 빨고 밖으로는 외계인 고문을 일삼으면서" 결과물을 내야 할 거 같다.

본인은 석사를 졸업한 지 이제 3년이 지났다.
내 석사 논문은 아시다시피 저 입력기의 이론적 배경과 구조, 주요 기능이 주제였다. 지금 동일 주제로 논문을 다시 쓰면 그때보다 수십까지는 아니어도 10수 페이지 정도는 더 써 넣을 분량이 있다.

가령, 다음 글자로 넘어갔을 때도 초성이 아니라 변함없이 종성 문맥으로 동작하는 '종성 지향 두벌식'은 6.7 버전에서 첫 도입되었으며 <날개셋> 한글 입력기의 역사에서 무척 중요한 위치를 차지하는 기능이지만, 논문이 다 완성되고 졸업하자마자 그 직후에야 추가된 기능이다. 그러니 논문엔 못 들어갔다.

7.9와 8.0대에서는 종성 지향 두벌식의 정반대 이념이며 두벌식 연구자의 떡밥이던 '초성 지향 두벌식'까지 추가되었다. '살 → 사라'가 아니라 반대로 '사ㄹ → 살ㅈ' 이런 식으로 되는 입력 방식 말이다.
전자는 별도의 날개셋문자 타입으로 구현된 반면, 후자는 '고급 입력기'가 제공하는 낱자 치환 옵션의 일환으로 구현되었다. 기술 계층이 서로 완전히 다른 것이다.

또한 그때 이후로 키보드 입력이라는 물리적인 프로세스 자체에 대한 기술적 이해도가 더 깊어진 덕분에, 키 입력을 흉내 내는 기능이 독립된 날개셋문자 타입으로 추가되었다. 최근에는 입력 패드 구현체가 그런 키보드 입력이 드디어 지원되기 시작한 쾌거도 이뤘다.
이런 것들이 논문에 더 들어갈 수가 있었다는 뜻이다. 박사 졸업 이수 요건에 속하는 학술지 소논문에 이런 걸 적절히 투고할 방법이 있으면 좋겠다. 엄연히 국어 정보학과 관련된 개인적인 연구 실적이니까.

1. 한글의 고유한 특성과 활용 가능성: 한글은 IME가 필요한 복잡한 스케일의 문자이지만 중국· 일본어처럼 문장 단위가 아니라 1글자 단위로만 조합을 잡으면 된다. 이렇게 한글 같은 문자만이 처해 있는 특수한 상황에서 IME만이 제공할 수 있는 여러 편의 기능이 있을 것이다.
2. 세벌식의 우수성: 두벌식은 자음 종류 구분과 음절 경계 구분을 위한 온갖 테크닉이 필요하다. 그러나 세벌식은 그게 기본적으로 되기 때문에 타자기나 두벌식에서는 불가능한 다른 응용 기능을 언어 의존적인 데이터 없이 바로 구현할 수 있다. PC에서 세벌식 입력 방식이 없다는 건 말이 안 된다.
3. 이 시스템의 엔진의 독창성: 한글 입력 방식을 규정하는 모든 세부적인 동작을 customize할 수 있으며, 그 과정에서 두-세벌의 중간에 속하는 입력 방식도 구현 가능하다.
4. 이 시스템의 구현체의 독창성: 이 엔진을 편집기, IME, 입력 패드라는 다양한 기술적인 구현체를 통해 제공한다.

지금 논문을 다시 쓴다면 내가 주장하고자 하는 바를 위와 같은 네 카테고리로 더 분명하게 구분해서 깔끔하게 결론이나 초록을 썼지 싶다. 뭐 그건 이미 다 지난 일이고...
난 다음 박사 논문을 위해서는 "한글의 고유한 특성과 활용 가능성"이라는 기본 명제는 동일하지만, 입력이 아닌 출력에 속하는 한글 글꼴과 관련된 연구를 할 생각이다. 그러니 입력기는 빨리 마무리를 좀 지어야 한다.

논문 얘기가 너무 길어졌는데, 어쨌든 <날개셋> 한글 입력기의 다음 버전에서 만날 수 있는 사소한 변화들을 늘어놓으면 다음과 같다.

1. 이제는 프로그램을 설치할 때, 원하는 구현체만 선택해서 설치할 수 있게 했다.

세 구현체들의 특징은 다음과 같이 표로 일목요연하게 정리된다.

항목	편집기	외부 모듈	입력 패드
형태	EXE (32/64비트 하나만)	DLL (32/64비트 모두)	EXE+DLL (각각 32/64비트 모두)
도스용 프로그램에 비유	자체한글 에디터	한글 바이오스 (입력 부분만)	램 상주 키보드 인터럽트 유틸리티
기능 지원 범위	오로지 자기 내부	자기를 사용하는 타 프로그램 내부	실행 중인 모든 프로그램들
TSF A급	O	△ (동작 환경에 따라 다름)	X
Alt 지원	O	X	O
특이사항	자체 옛한글 글꼴, 텍스트 필터, 키 입력으로 붙여넣기. 성능 오버헤드가 가장 작음	명령 프롬프트 및 Metro UI에서 유일하게 동작 가능	구현체들 중 크기가 가장 작고 가벼움. 키보드 모드는 옵션으로 제공

2. 웹 브라우저 같은 외부 프로그램의 텍스트를 <날개셋> 편집기의 빈 문서 창에다가 drag & drop을 하고 나면 가끔 편집기의 프레임이 고전 테마 형태의 이상한 모양으로 일시적으로 바뀌는 문제가 있었다. 개인적으로는 운영체제의 버그에 가깝다고 생각하는 현상이지만 Windows Vista부터 8.1까지 일관되게 발생하는 현상이고, 또 문제를 회피하는 방법도 있으므로 그걸 적용했다.

3. 도움말에서 "외부 모듈 → 알려진 버그" 부분에, 키보드 보안 프로그램으로 인한 오동작 가능성을 더 자세히 언급했다. 이런 문제가 있을 수 있는 프로그램은 크게 "IE 브라우저"뿐만 아니라 요즘은 "온라인 게임"이 더 중요하다. IME도 나름 키보드 입력을 가로채는 프로그램이다 보니, 디지털 서명이 없는 날개셋 같은 프로그램을 여타 보안 프로그램이 차단할 수도 있다.
5년 전에 스타크래프트 2가 출시 직후에 이와 관련된 대표적인 문제를 일으켰었는데, 앞으로 다른 게임에서 이런 부류의 문제가 계속 보고될 수도 있다.

4.
얼마 전, 인디자인 9에서 한글 입력과 관련된 귀찮은 문제가 출판 디자인 업계에서 거론된 적이 있었다. 한글 조합 중에 space, tab 등의 글쇠를 누르면 원래는 한글 조합도 중단되고 해당 글쇠 문자도 뒤에 입력이 돼야 한다. 그런데 인디자인은 이때 조합만 중단되고 해당 글쇠는 씹히기 시작했다. 그것도 예전엔 안 그러다가 최신 버전에서 갑자기 그러기 시작했다. space/tab이 아니라 IME가 인위적으로 처리를 하는 비한글 문자는 씹히는 문제가 없었다(세벌식 자판의 숫자처럼).

그런데 이와 비슷한 문제가 MS Word에서도 부분적으로 발생한다는 것이 최근 확인되었다. "고급 입력기"가 제공하는 사용자 정의 조합이나 한글 출력 치환 기능을 이용해서 평범한 알파벳이나 숫자를 조합하는 상태를 만들고 나면, space, tab을 눌렀을 때 조합만 종료되고 해당 글쇠는 씹힌다. 그 반면, 한글이나 전각, 특수문자, 2글자 이상의 긴 조합을 만들고 있을 때는 그런 현상이 없다! 간단히 "일본어 히라가나/가타카나" 예제 유형만 MS Word에서 사용해 봐도 확인 가능하다.

TSF를 지원하는 다른 모든 프로그램들은 안 그러는데 오로지 MS 워드만 왜 저러는지 나로서는 알 길이 없다. 아니, 애초에 왜 그 타가 씹힐 수가 있는지도 이해가 안 되지만.. 문제의 증상과 해결(회피) 방법이 인디자인과 Word가 동일하기 때문에 도움말에 동일한 항목으로 보충 설명을 넣었다.

5.
끝으로, 시대가 시대이다 보니 About 대화상자에 Windows 10을 인식하는 데이터도 추가했다.
그리고 외부 모듈에서 옛한글을 사용하는 것과 관련된 추가 설명을 UI나 도움말에 넣었다. (시스템 계층에서 한글 표현 방식도 제대로 설정했는지 확인하라, 옛한글 글쇠배열을 가져오기만 하는 것과 빠른설정으로 총체적으로 맞추는 건 다르다 등)
지금까지 두벌식으로 옛한글 글쇠배열을 설정하면 4단 아랫자리에 있는 한쪽이 길쭉한 반치음들은 종성까지 입력 가능한 형태로 배당되었는데, 이제는 그걸 없애고 초성으로만 배당되게 했다. 이들 자음은 어차피 초성 형태밖에 존재하지 않기 때문이다. 종성 표현은 <날개셋> 편집기 내부에서 사용자 정의 영역 글자를 이용해서 편의상으로나 존재한다.

현대 한글 두벌식을 사용할 때는 ㄸ, ㅃ, ㅉ이 받침이 존재하지 않기 때문에 언제나 초성으로만 입력된다.
옛한글 두벌식일 때는 이들은 종성으로도 입력 가능하고 그 대신 반치음들이 그런 형태를 이어받게 되는 것이다.

Posted by 사무엘

1. 들어가는 말

이번 학기도 다 끝나고 여름방학이 시작됐다. 이젠 코스웍이 한 학기밖에 안 남았고, 슬슬 종합 시험과 학술지 논문 등 길고 긴 연구 모드로 들어갈 준비를 해야 한다.
그런데 아직 기말 과제가 다 안 끝났을 때, 방학이 되길 벼르고 벼르면서 타는 목마름으로 할것들을 적어 놓은 게 이미 한 트럭인지라, 방학이 된 뒤에도 별로 방학 같은 느낌이 안 든다.

이게 무슨 상황이냐 하면, 월급날이 돌아와 봤자 카드 명세서와 저축, 집 대출 이자 내지 자동차 구입 할부 등의 비소비 지출들이 한바탕 raid를 벌이고 나면, 여전히 가난한 것과 완전히 똑같다.

알람 안 맞추고 좀 원없이 자 보고 싶다.
하루에 최하 8시간 이상, "너무 자서 골병 들 거 같다. 이제 좀 그만 자야지" 생각이 들 때까지 자고 싶다.
코딩 노예 계약서를 화형에 처하고 싶다.
차 끌고 전국일주 여행 좀 가고 싶다. 그리고 여친도 좀 사귀고 싶다. -_-;;

내가 도대체 무슨 부귀영화를 바라고서 이 나이까지 이 짓을 하고 있나.. 그냥 빨리 돈 벌고 안정적으로 살려면 스펙 관리해서 코레일이나 철도 시설 공단에나 들어가면 되지 싶은 자괴감이 들긴 하지만,
뭐 어쨌듯 이런 와중에 <날개셋> 한글 입력기 8.0이 완성됐다. 그 다음 버전(8.x)까지 빨랑 다 만들어 버리고 완성된 모습을 좀 보고 싶다.

이번 8.0은 리팩터링 내지 내부 완성도 강화 작업이 많아서 readme에다가는 쓸 게 적은 편이었다. 하지만 내부적으로는 0.1을 능가하는 분량의 변화가 있었다.
지난 5월에 이미 언급했듯이 편집기에서 한글 정규화 규칙 강화, 수식의 상수에 원형 보존이라는 굵직한 변화가 있었으며, 또 '초성 지향 두벌식', 글쇠누름 날개셋문자 기능과 관련해서 조합 종료 처리가 불완전하던 것을 보강했다.

사소한 것으로는 한글 조합 중에 아무 자모 없이 H2, H3, H2J 이런 날개셋문자만 달랑 넘겨 준 경우 지금까지는 그냥 아무 일 없었다는 듯이 무시만 당했지만, 지금은 입력 중인 한글의 종류를 그걸로 변경되게 했다. 이것 말고도 아주 마이크로한 부분에서 프로그램의 완성도를 높이고 소스 코드 구조를 개선하는 작업들은 가시적인 작업 성과에 비해 난이도가 무척 높았다.

또한 도움말과 프로그램 소개 페이지에 있는 스크린샷들을 싹 다 최신 버전 기준으로, 특히 외형도 Windows 8 모양으로 교체했다. 알다시피 Windows 8이 비주얼이 더 단순하고 빈약한 덕분에 같은 화면이어도 스크린샷의 크기가 더 작아졌다. 이로 인해 도움말 크기가 몇만 바이트 감소하고, 프로그램 전체의 배포 패키지 크기도 아주 약간 더 작아졌다. 프로그램은 덩치가 조금 더 커졌는데도 말이다. 예기치 못한 긍정적인 효과이다.
이런 식으로 사소한 것들이 쌓이고 쌓였다는 뜻이다. <날개셋> 한글 입력기는 개발 15년째인 아직까지도 매 새 버전마다 새로운 역사를 쓰고 있다.

2. 입력 패드에 키보드 입력 모드 추가

이런 것 이후에 이번 <날개셋> 한글 입력기 8.0에서 추가된 큰 기능은..
편집기와 외부 모듈에 이어 제3의 구현체이던 입력 패드가 드디어 키보드 입력이 가능해졌다는 점이다.
Windows에서 정식 IME가 아닌 EXE 형태의 프로그램이 다른 프로그램에서 키보드 입력으로 한글을 입력해 넣는 게 가능해졌다.

입력 패드는 5.3버전에서 첫 도입된 이래로 약 6년 동안 마우스를 이용한 '입력 도구'의 구동만 가능한 반쪽짜리 구현체였다. 키보드까지 지원하는 것은 기술적인 난관 내지 구현 가성비 등을 감안했을 때 보류되어 있었고 연구 우선순위도 별로 높지 않은 상태였다. 당장 이번 8.0에서도 처음엔 딱히 고려 대상이 아니었는데...

그러나 화면 키보드에 '눌린 글쇠 표시'기능을 넣는 과정에서 입력 도구에도 키보드 입력을 연계하는 기능이 7.9와 8.0의 개발 과정에서 자연스럽게 구현되었다. 어떤 글쇠가 눌렸다는 통지를 받고, 원한다면 이 키 입력을 입력 도구가 가로채어 먹을 수도 있는 것이다.
그러니 아예 키보드 입력을 지원하는 것도 이 작업의 연장선 차원에서 지원 가능하겠다는 생각과 함께 불현듯이 개발이 진행되었다.

그냥 입력 패드를 실행하면 딱히 변화가 없다. 그러나 트레이를 우클릭해서 메뉴를 열면 "키보드 입력 사용"이라는 메뉴가 추가되어 있다. 이걸 선택해서 체크하면 키보드 입력이 가능해진다.

단, 입력 패드는 운영체제 IME가 동작하지 않는 틈을 타서 동작하며, 이미 제도권에서 돌아가고 있는 운영체제 IME를 대체하거나 그 동작을 바꾸지는 않는다. 운영체제 IME가 '영문 반자'로 켜져는 있으되 동작은 안 하는 상태여야 한다. 걔가 한글 모드일 때는 본 프로그램은 아무 동작도 하지 않는다. 또한 운영체제 IME가 자기 입력 모드를 바꿀 때 사용하는 한영 글쇠 같은 것도 가로채지 못하므로 Shift+Space나 우클릭 메뉴처럼 다른 전환 글쇠를 배당해야 한다.

또한 마우스만 지원하던 예전부터 마찬가지이긴 했지만, 입력 패드가 제공하는 입력 기능은 데스크톱 GUI 환경 전용이다. 명령 프롬프트나 Windows 8 이상의 메트로 UI에서는 동작하지 않는다. 거기서는 정식 외부 모듈만을 써야 한다.

입력 패드가 제공하는 입력 프로토콜의 수준은 TSF A급이 아니다. 조합을 만들고 완성된 문자열을 내보내는 것만 가능할 뿐, 조합이 끝난 인접 문자열을 알아 오거나 고칠 수는 없다.
입력 패드가 TSF를 지원하는 프로그램에서 TSF A급으로 동작하는 것은 이번 8.0의 개발 작업을 통해 기술적으로 '불가능한 건' 아님을 확인했다. 하지만 구현하는 오버헤드가 굉장히 크며, 편집기와 외부 모듈이 있는 상황에서 입력 패드가 굳이 그것까지 지원할 필요는 없다고 여겨져서 미지원 상태로 남겨 뒀다.
따라서 편집기는 전용 프로그램이다 보니 언제나 A급이 보장되고, 외부 모듈은 어느 프로그램에서 동작하느냐에 따라 A/B급이 유동적으로 바뀌는 한편, 입력 패드는 간편하게 동작한다는 특성상 언제나 B급이라는 차이가 존재한다.

끝으로, 편집기나 외부 모듈과는 달리 입력 패드는 한자 변환을 아직 지원하지 않고 있다. 키보드 입력이 지원되기 시작했기 때문에 앞으로는 이 한계가 이제 더욱 부각되어 보일 것이다.
이 역시 기술적으로 불가능한 건 아니고 단순히 해당 UI가 시간 부족-_-으로 인해 구현되지 않아서 지원되지 않은 것이다. 입력 패드에서 글자 조합 중에 한자/후보 변환을 시도하면 "해당 기능은 아직 지원되지 않습니다"라는 풍선 도움말이 뜬다.

3. 타자연습

타자연습은 프로그램에 변경 사항은 없으며 이번 입력기 8.0 버전도 예전의 7.9와 마찬가지로 타자연습 3.41하고 API가 호환된다. 그러므로 타자연습을 굳이 또 다시 받아서 설치하지는 않아도 된다. 다만, 이번에는 3.41을 다시 올리면서 연습글에다 "세스코 질문 답변 모음"을 추가했다.

"나는 바퀴벌레 제 1군단 장군이다. 우리는 너희 세스코를 적으로 간주하며 오는 12월 25일 크리스마스 선물로 너희 세스코 본사를 대대적으로 공격할 것이다." 뭐 이런 문장으로 연습을 할 수 있다.
'퀴'는 세벌식에서 치기 어려운 축에 드는 글자이니 연습 효과도 상대적으로 클 것으로 기대된다.;;
이 때문인지, 어지간한 연습글들은 분석해 보면 4단의 사용 빈도가 3~5%대인 반면, 세스코 글은 6%가량 된다. ^^

엔하위키(지금은 이름이 '나무'로 바뀌었지만)나 각종 인터넷 카페에서 <날개셋> 타자연습 프로그램에 대한 소개를 해 놓은 걸 보면 김 성모 유행어와 각종 인터넷 유행어가 연습글로 들어있는 게 역시나 반응이 아주 좋다. 이제는 시간이 너무 흘러서 그것조차도 유행이 다 지나려 하긴 한다만..
세스코도 비슷한 맥락으로 재미있는 연습글 역할을 할 수 있을 것이다.

4. 후속 과제

7.9에서 8.0은 지난번 7.7에서 7.9로 올라갈 때만치 양적 성장은 없지만 추가된 소수의 기능들이 제각각 매우 중요하고 여파가 크다. 버전에서 소수점이 아닌 1자리 숫자의 변화와 같이 일어나기에 적절한 것들이다.

사실은 이번 8.0에서는 최종 변환 규칙의 동작 방식을 변경하고, IME 관련 이벤트를 정형화해서 "변경된 글자판을 cursor 근처에다 잠시 표시해 주는 입력 패드"도 추가하려고 했다. 그러나 이것은 입력 패드의 키보드 입력 기능을 구현하느라 뒷전으로 밀려서 다음 버전의 과제로 남게 됐다.

사실, 입력 패드는 현재의 글쇠배열을 표시하는 UI가 어디에도 존재하지 않는다. 시스템 트레이의 아이콘을 가리키고 있어야만 툴팁으로 나온다. 그러니 입력 패드를 쓰고 있을 때는 저 UI가 더욱 필요할 텐데 시간 관계상 8.0에서 다 반영되지 못했다. 3개월 정도 시간이 지났고 이미 0.1 이상의 충분한 작업량이 쌓였으며, 7.9에 꽤 어이없는 버그가 있기도 하기 때문에 새 버전의 공개를 지금 시점보다 더 미룰 수는 없었다.

그러니 굳이 많은 기능들을 사용하는 헤비 유저가 아니더라도 이 글을 보시는 7.9 사용자라면 8.0으로 빠짐없이 업그레이드를 하고, 한번 입력 패드도 사용해 보시기 바란다.
생각 같으면 한 배포 패키지에서 32비트와 64비트별로 파일이 알아서 설치가 되고 편집기/외부 모듈/입력 패드 구현체들 중 사용자가 원하는 것만 선택해서 설치하는 옵션도 넣고 싶긴 하다.

과연 다음 버전 8.1이나 8.2는 신규 모아치기/동시치기 엔진까지 포함해 <날개셋> 한글 입력기의 종결자 버전이 될 수 있을까? 그건 나도 모른다. to be continued일 뿐..! 그래도 1년 전에 비해 task list가 눈에 띄게 가벼워진 것을 보면 감회가 새롭다. 느리긴 해도 노예 계약은 추가되는 것보다 이행되는 게 더 많으며, 꾸준히 청산하고 있는 중이다.

* 여담 1: 한중일 IME들의 제어판 UI의 구조

잘 알다시피 Windows에서 문자 입력을 위해 단순히 운영체제의 기성 코드 + 데이터 차원의 variant가 아니라 아예 제3자가 만든 IME라는 별도의 프로그램이 쓰이는 언어는 한국어(한글), 일본어, 중국어 간체, 그리고 중국어 번체 이렇게 4개이다.
그런데 Window에 내장돼 있는 중국어나 일본어 IME에서 환경설정 대화상자를 열면 그건 IME 프로그램 내부가 아니라 별도의 EXE 프로그램이 실행되는 형태로 열린다. 그 대화상자가 떠 있는 상태에서 예전에 글자를 입력하던 창으로 돌아가는 것도 가능하다.

환경설정뿐만 아니라 보조 입력 도구를 꺼내는 것도 IMEPADSV처럼 한중일 IME들이 한데 공유하는 별도의 프로그램을 써서 하며, 도움말도 통상적인 HtmlHelp API를 쓰는 게 아니라 HH 프로그램을 별도로 띄우는 방식으로 동작한다.
IME들은 자기가 돌아가는 프로세스에 끼치는 영향을 최소화하려고 의도적으로 그렇게 만들어진 것 같다. 뭔가 복잡한 GUI를 띄워야겠다 싶은 건 in-process로 구동하는 걸 기피한다.

내 프로그램의 경우 제어판은 규모가 상당히 크긴 하지만 그냥 in-process에서 modal 대화상자 형태로 돌아가며, 편집기나 입력 패드 같은 독립적인 구현체들 단위로 별도의 EXE가 만들어져 있지, 중간의 구성요소가 또 EXE이지는 않다. 쉽게 말해 <날개셋> 제어판이 그 자체가 독립적인 EXE로 존재하지는 않는다는 뜻이다.

MS 한글 IME는 운영체제의 제어판이 아닌 자기 자신만의 독자적인 UI에 환경설정을 꺼내는 명령이 아예 존재하지 않아서 두벌/세벌 전환조차도 하기가 불편하다. TSF가 도입되기 전, Windows 98~ME 시절에는 자기 도구모음줄을 우클릭해서 글자판을 아주 간편하게 바꿀 수 있었는데 그런 기능이 없어졌다.

* 여담 2: Windows 8.1의 MS 한글 IME

Windows 8때까지만 해도 이런 게 없었는데 난 이걸 비교적 늦게 발견했다.
8.1의 메트로 UI에서 MS 한글 IME로 한글을 입력하다가 글자를 지워 보면, 연달아 입력하던 단어까지는 계속해서 자모 단위로 지워지다가 그 뒤부터 글자 단위로 지워진다. 오, 신기한 기능이 추가됐다. 사실 이렇게 동작하는 게 일반적으로 훨씬 낫다. <날개셋> 한글 입력기의 경우 2년 전 버전 7.1에서 비슷한 옵션이 처음으로 추가되었다.

단어 전체를 조합으로 잡는지, 아니면 실시간으로 앞 글자를 얻어 오는지는 잘 모르겠지만, 세벌식에서 받침 ㄶ을 한 타로 바로 입력했는지 ㄴ+ㅎ로 입력했는지를 다 정확하게 기억하는 걸로 봐서는 아마 전자인 것 같다.

Posted by 사무엘