날개셋 한글 입력기는 2018년 3월쯤 완성 목표로 9.3 버전이 개발 중이다.
프로그램의 전체 소스 코드가 이제 8만 줄을 돌파했다. 참고로 7만 줄은 2015년에 8.2 버전을 개발할 때 달성됐으며, 6만 줄은 2011년에 6.0 버전을 개발하는 과정에서 달성되었다.
※ 버그 수정
1. 후보 변환 관련 문제
지난 9.0과 9.1이 기능 추가 말고 '개선' 사항이란 게 없다시피했기 때문에, 이제 이 프로그램은 기존 기능들이 충분히 안정화가 됐다고 여겨졌다. 그래서 본인은 오랫동안 안심하고 새 기능 구현에만 집중하면 되겠다고 생각했다.
그러나, 얄밉게도 9.1을 공개한 지 얼마 되지 않아 후보(한자) 변환 쪽에서 총체적으로 꽤 난감한 버그가 발견되었다. 옛한글 내지 미완성 한글처럼 내부적으로 단일 코드 포인트로 표현되지 않는 한글을 조합 중인 상태에서 한자 키를 눌러 보면 된다.
'제1후보 변환' 기능에 문제가 있어서 "마지막 낱자(from) + 아무 후보가 없는 상태(to)"로 후보 선택창이 이상하게 뜬다.
사용자 정의 후보에서 from을 옛한글이나 미완성 한글로 지정하더라도 조합 중에는 변환이 되지 않는다.
그리고 조합을 마치고서 post-mortem 변환을 하더라도 cursor 이동 계산이 이상하게 돼서 글자가 정상적인 위치보다 앞에 삽입 되는 식의 오동작이 발생한다.
이건 후보 변환 관련 버그 수정이 마지막으로 행해졌던 8.9시절부터 계속 남아 있었던 문제로 보인다. 9.0이나 9.1때도 버젓이 있었던 문제이다. 그게 지금까지 왜 발견하지 못하고 있었는지, 버그인지 아니면 아예 미구현 미완성이었는지, 왜 그때 코드를 이 따위로 작성했는지 자괴감이 든다. 뭐, 버그를 발견 즉시 사살하긴 했다.
2. MS Word에서의 수식 중복 수행 문제
그리고, MS Word에서 특정 상황 조건이 만족되었을 때(가령 bksp를 누른 뒤), 글쇠를 한 번만 눌렀는데 그 글쇠에 대한 수식이 두 번 수행되어 오동작이 발생하는 문제를 해결했다.
이 문제는 3년 전에 나온 7.7 버전에서 다뤄진 적이 있었지만 그 당시의 해결책이 온전하지 못했다. 추가적인 문제는 내가 발견한 건 아니고 사용자의 제보를 통해 파악했다.
기술적인 관점에서 보면, MS Word와 워드패드는 TSF 인터페이스를 잘 지원하는 프로그램이긴 하지만 얘들만 글쇠를 좀 이상하게 인식하고 요청하는 문제가 있어서 이들 프로그램에 대한 보정이 필요했다. 워드패드는 혼자 다른 프로그램들과 정반대의 순서로 key 입력을 전해 주며, Word는 순서는 문제가 없는데 동일한 key 입력을 중복 전달하는 경우가 있다.
이게 버그가 아니라 사용자가 진짜로 같은 key를 반복해서 누른 것일 수도 있기 때문에 보정도 앞뒤 상황을 봐 가면서 조심스럽게 해야 한다. 여러 모로 골치아프다.
게다가 중복 전달을 2중이 아니라 아예 3중으로도 하는 경우가 있는데, 내 프로그램은 이에 대한 대비는 돼 있지 않았다. 이를 확인하여 개선했다.
※ 보조 입력 도구 기능 추가
그럼, 버그 수정 내역 말고 기능 추가 내역을 소개하겠다. 이번 9.3도 지난 9.1과 마찬가지로 '보조 입력 도구' 가 새로운 것들이 추가되고 있다. 특별히 한글 입력기(문자 생성기)의 내부 상태를 시각적으로 진단· 확인하는 데 도움이 되는 것들이다.
1. 수식 계산 기록
이건 꽤 이색적인 보조 입력 도구이다. 얘를 띄우고서 글자판을 바꾸거나 한글을 입력하거나 각종 기능을 조작하면 그 과정에서 내부적으로 실행된 글쇠배열, 오토마타 등의 수식이 화면이 쭉 뜬다. 그 수식 중 하나를 클릭하면 어느 설정에서 유래된 수식이고 초기에 공급된 변수값들이 무엇이 있는지, 실행 후에 대입 연산으로 인해 변경된 변수가 있는지, 수식의 계산 결과는 무엇이 나왔는지가 화면 우측에 조목조목 나타난다.
그러니 이 기능을 사용하면 내가 만든 입력 설정이 기대했던 대로 동작하지 않을 때 수식과 변수에 무슨 문제가 있는지 추적을 아주 편리하게 할 수 있다.
수식은 날개셋 한글 입력기의 설정을 기술하는 핵심 구성 요소이다. 하지만 이게 어떤 방식으로 동작하는지를 사용자에게 시각적으로 알기 쉽게 보여주는 편의 기능이 없어서 사용이 불편했던 게 현실이다. 이 입력 도구는 그 불편을 크게 개선해 주리라 기대된다.
2. 내부 입력 상태 표시
얘도 '수식 계산 기록'와 비슷하지만 관점이 미묘하게 다른 입력 도구이다. 조합을 만들어 낸 문자 생성기의 내부 상태만을 표시해 줄 뿐 자신이 뭔가 입력 기능을 제공하는 건 없는 read-only 도구이다. '내부 입력 상태'는..
(1) 조합 문자열이 생기면 그 조합을 생성한 주체, 문자 생성기의 오토마타 상태 번호, 그리고 조합의 종류를 표시한다. 대부분의 경우 조합을 소유한 주체는 그냥 지금 키보드 입력을 담당하는 입력 스키마이지만, 자체적인 문자 생성기를 가진 보조 입력 도구가 주체가 될 수도 있다(휴대전화, 한손 입력기 같은..). 조합의 종류도 한글 또는 고급 입력기의 사용자 정의 조합 이렇게 두 종류가 존재한다.
(2) 입력 스키마 휘하에 있는 사용자 변수들이 현재 갖고 있는 값들을 출력한다. '수식 계산 기록'은 수식 계산이 행해질 때마다 각각의 계산 내역들을 '목록' 형태로 관리하며, 프로그램이 제공하는 대문자 변수의 값도 다 출력해 준다. 그 반면, 얘는 모든 처리가 끝난 뒤에 글쇠배열과 오토마타 등이 공유하는 소문자 사용자 변수들의 최종적인 값만 실시간으로 업데이트 하여 보여준다. 사용자 변수의 변화만 추적할 때는 '내부 입력 상태 표시' 도구를 사용하는 게 더 편리할 수도 있다.
(3) 그리고.. 현재 발동된 타이머들을 모두 표시해서 "지금으로부터 타이머 N이 1.x초 후에 발동 예정" 이거 카운트다운을 실시간으로 보여준다. 한 타이머가 반복해서 작동되었으면 hit 횟수까지 카운트 해 준다. 물론 타이머를 발동한 근거 수식이나 그때 입력된 날개셋문자를 확인하려면 '수식 계산 기록' 도구의 도움을 받아야 하지만, 타이머의 작동 현황을 실시간으로 파악하려면 이렇게 다른 관점에서 만들어진 입력 도구를 같이 사용하는 것이 좋다.
※ UI 개선
1. '한글 표현 방식' 탭의 변신
외부 모듈(+ 입력 패드)에서 날개셋 제어판을 열면 시스템 계층에 잘 알다시피 '한글 표현 방식'이라는 거창한 탭이 제공되는데..
한번 만들어 놓은 뒤부터 오랫동안 불변이던 이 탭이 이번에 정말 획기적으로 크게 달라졌다.
(1) 처음 열었을 때는 내정값 말고 나머지 복잡한 설정들은 보이지 않게 디자인을 바꿨다. "세부 옵션 보기"를 클릭해야만 이전부터 있던 옵션들이 나타난다.
다만, 이전에 사용자가 맞춰 놓은 설정이 내정값 중 하나로 떨어지는 상태가 아니었다면 역시 처음부터 detailed view 상태로 대화상자가 뜬다.
(2) 그리고, 이 방식의 옛한글을 표시하려면 무슨 글꼴이 필요하네 뭐네 장황하고 잡다하던 설명을 다 집어치우고.. 그냥 백문이 불여일견을 구현했다.
자체 비트맵 글꼴로 예문을 레퍼런스로 제시한 뒤, 바탕, 맑은고딕 등 사용자의 컴에 있는 주요 글꼴로 지금 옵션대로 옛한글을 찍은 결과를 직접 보여주게 했다~~!
아.. 속이 다 후련하다. 이 대화상자를 진작부터 왜 이렇게 만들 생각을 안 했나 모르겠다.
물론 지금은 무려 2018년이 코앞이고 옛한글 표현 기술은 유니코드 5.2 표준이 완전히 정착했다. 이제 한글 표현 방식을 변경하는 건 "현대 한글 전용" 아니면 "유니코드 5.2" 내정값 이 둘밖에 없으며, 나머지는 그냥 legacy일 뿐이다.
그러니 이 '한글 표현 방식' 탭은 제공되는 옵션들을 처음부터 사용자에게 몽땅 미주알고주알 보여줄 필요가 없으며, 특수한 이유가 있는 게 아니라면 이건 오히려 건드리지 않는 게 좋다고 먼저 안내해야 한다. (1)은 이런 생각을 구현한 것이다.
지금 이 기능을 새로 구현한다면 '한글 표현 방식'을 선택하는 건 별도의 탭을 만들지 않고 시스템 계층의 다른 대화상자에다가 콤보 상자와 버튼 하나로 간단하게 구현됐을 수도 있다.
하지만 이게 처음 도입된 건 날개셋 4.x대 후반, 2007년인가 08년경이었기 때문에 아직 그럴 상황이 아니었다. 유니코드 5.2가 정식 제정되기 수 년 전이었으며, 한양 PUA나 유니코드 1.1 같은 절충안이 여전히 유효하던 때였다. 그러니 무슨 방식을 선택하느냐에 따라서 주의 사항을 출력할 것이 많기도 했다.
이번에 새로 구현된 미리보기 기능은 스크린샷에서 보다시피 현대 한글 자모와 글자, 유니코드 1.1 수준의 자모와 글자, 한양 PUA 문헌에 있는 옛한글과 그렇지 않은 옛한글, 유니코드 5.2 전용 옛한글을 일목요연하게 찍어서 보여준다.
그러니 사용자는 낱자들이 풀어지거나 깨지거나 벌어지지 않고 레퍼런스 렌더링인 비트맵 글꼴과 가장 비슷하게 찍히는 글꼴을 찾아서 그걸로 옛한글을 입력하면 된다.
2. '코드 번호로 변환' 텍스트 필터의 UI 변화
날개셋 한글 입력기에는 '코드 번호로 변환'이라는 텍스트 필터가 있어서 문자를 유니코드 또는 여러 multibyte 인코딩 번호로 풀어 쓰거나 그걸 반대로 재합성하는 기능을 제공했다. 리드미를 찾아보니 8년 전의 5.31 때 첫 도입되었는데, 임의의 유니코드 문자열을 소스 코드나 URL로 풀어 써야 할 때 무척 유용하게 활용 가능한 기능이다.
문자를 숫자로, 또는 숫자를 문자로..
그리고 유니코드 코드 포인트, 또는 특정 인코딩으로.. 이 2*2=4가지 변환을 모두 지원한다.
문자를 유니코드 번호로 변환하는 기능은 어느 문자를 변환할지 수식, 문자 코드 페이지(이 코드 페이지에 없는 것), 글꼴(이 글꼴에 없는 글자) 이렇게 세 조건 중 하나로 지정할 수 있다. 그렇기 때문에 별도의 '조건' 대화상자를 여는 버튼이 지금까지 있었다.
그러던 것이 다음 버전부터는 조건 대화상자가 없어지고 그 조건이 동일 대화상자 화면의 아래에 바로 표시된다. 단계가 더 간단해졌다. 위의 스크린샷에서 보는 바와 같다.
그리고.. 문자를 유니코드로 바꾸는 것 말고 인코딩 바이트로 바꾸는 기능에도 "추가로 변환할 문자"를 지정하는 입력란이 추가되었다.
이 기능은 아스키 127번 이하의 문자는 코드값이 불변이기 때문에 0x나 %로 변환을 하지 않는다. 한글· 한자처럼 진짜로 변환해야 하는 문자, 숫자나 접두사와의 혼동을 피해야 하는 문자만 변환해 준다.
하지만 문자열을 URL 같은 데에 전달할 목적으로 변환하다 보면.. +, &, ?처럼 특수한 용도로 예약된 문자도 강제로 변환해야 할 때가 있다. 유니코드 번호로 변환하는 기능이야 수식을 지정할 수가 있지만, 여기서는 문자의 종류가 끽해야 몇십 종류밖에 안 되니 굳이 수식을 넣을 필요는 없고, 부득이하게 강제로 번호로 변환해야 하는 문자를 사용자가 수동으로 지정할 수 있게 했다.
이런 자그마한 기능 추가와 함께 UI 개선, 소스 코드 리팩터링도 같이 진행하니 굉장히 훌륭한 결과가 나왔다. 변환 형태 4가지를 선택하면 그 아래의 화면은 네 가지가 하나도 같은 게 없이 제각각 동적으로 바뀐다. '유니코드 번호를 문자로' 바꾸는 기능이 옵션이 제일 적어서 썰렁하다. '번호 표현 형태'를 고르는 것밖에 남지 않기 때문이다.
※ 나머지 얘기
1. 사소한 변화들
데이터: 9.0에서 첫 도입되었던 24픽셀 옛한글 글꼴이 외형이 지금보다 더 예쁘게 보이게 일부 수정· 개선되었다. 그리고 제공되는 비한글 입력 예제인 Qwerty/Latin Ext가 최신 유니코드를 기준으로 후보 데이터가 더 방대해졌다. 이것들은 정 재민 님께서 수고해 주셨다.
타자연습: 큰 기능 추가는 없으나, 입력기의 API 구조 변경의 영향을 받아서 타자연습도 새 릴리스가 나오긴 할 것이다. main 화면에서 Alt+1~6을 누르면 '시작'부터 '통계' 탭까지 곧장 이동하게 비밀 단축키를 추가했다. 마우스 없이 키보드만으로 프로그램을 사용하기가 좀 더 편리해질 것이다.
2. 고민: 보안 프로그램과의 충돌 문제
날개셋 한글 입력기가 보안 프로그램과 충돌하는 건 2000년대 중반쯤부터 인터넷 뱅킹 사이트 위주로 신고가 들어오곤 했다. 그때는 ActiveX 형태로 동작하면서 키보드 드라이버 계층에서 날개셋으로 전달되는 입력을 차단하여 내 프로그램 동작을 먹통으로 만드는 게 문제였다. 즉, 프로그램이 아닌 사이트가 문제였다.
또한, 그때는 엄밀히 말해서 3rd-party IME를 쓰는 게 문제가 아니라 세벌식을 쓰는 게 문제인 경우도 있었다. 한글을 입력하라고 알파벳 글쇠만 허용해 놨는데 세벌식은 4단 숫자와 기호 자리까지 사용하니 그것만으로 충분치 못한 것이다.
요즘은 온라인 게임에서 내 프로그램이 잘 동작하지 않는다는 문의가 종종 들어온다. 조합이 덧난다거나 하는 사소한 문제가 아니라 (1) 아예 글쇠가 인식되지 않고 한글이 아닌 영문만 입력된다거나, (2) MS IME로는 문제가 없는데 날개셋만 그런다면 그건 내 프로그램에서 딱히 해결책이 없을 가능성이 90% 이상이다. 해당 게임, 더 정확히는 그 게임이 사용하는 보안 솔루션이 날개셋 한글 입력기의 동작을 차단하지 않아야 한다.
사실, 내 프로그램이 디지털 서명이 없어서 각종 백신이나 보안 프로그램으로부터 의심받는 것도 문제이긴 하다. 현재로서는 뾰족한 대책이 없어서 그냥 넘기고 있지만, 이 때문에 사용자의 불편이 크다면 어찌 해야 할지 고민된다. 요즘은 안 그래도 어지간한 프로그램들은 웹브라우저에서 몽땅 띄우고 네이티브 프로그램의 다운로드와 설치는 점점 기피되는 추세인데, 이런 불편까지 끼치는 것은 참 민망한 일이 아닐 수 없다.
Posted by 사무엘
