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

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

2018년 여름 현재 날개셋 한글 입력기의 차기 버전인 9.5가 개발 중이다. 지금까지 수 차례 연기와 번복을 거듭해 왔지만, 9.5는 정말로 완전체 파이널 버전이 될 것이 명확해지고 있다. 작업해 놓은 것을 정리해 보니 분량이 이렇게 길어질 줄은 몰랐다.

9.5 이후로는 버전업을 하더라도 그 주기가 지금보다 더 길어질 것이며, 지금 같은 장기적인 개발 계획 없이 그때 그때 생긴 아이디어 반영이나 문제점 개선 위주로만 가볍게 새 버전이 나올 것이다. 2000년에 나왔던 1.0 이래로 18년이 지나서야 이제 좀 한글 입력기가 물건다운 물건이 완성된 것 같다.

1. '조합 안에 조합 생성' 입력 도구의 변화

날개셋 한글 입력기의 차기 버전에서는 9.3에서 첫 도입되었던 입력 도구의 모습이 이렇게 미묘하게 바뀌었다.

• 후보 목록이 언제나 입력란의 왼쪽 끝에 표시되는 게 아니라("한국어"), 실제로 삽입되는 위치("처리") 근처에 표시되게 했다.
• '한글 단어를 한자로' 변환 기능의 경우, 낱글자에 대해서는 한자의 훈도 표시되게 했다. (곳, 아내, 슬퍼할.. 등)
• 지금 변환 가능한 영역("처리")과 그렇지 않은 영역(그 이후 "학술대회")을 검정 vs 회색으로 구분해서 표시하게 했다.

눈에 띄지 않는 개선 사항은 다음과 같다. 한글 조합 상태와 관련해서 여러 미묘한 버그들을 발견해서 잡았다.

• 이미 한자로 변환되어 있는 곳으로 cursor를 옮기면 무조건 모든 한자들이 도로 한글로 돌아가는 게 아니라, 예전에 변환했던 단위로만 역순으로 복귀되게 했다. 예를 들어, 위의 그림과 같은 상태에서 마지막 한자인 '보(報)'를 건드리면 '정보'만 한글로 돌아가고 '한국어'는 아직 한자로 유지되어 있다.
• 평범한 왼쪽 화살표나 backspace 말고 특수글쇠(앞 글자 달라붙기 같은)의 기능으로 cursor를 움직여서 앞의 한자를 건드렸을 때는 한글 복귀가 제대로 되지 않던 버그를 잡았다.
• 저런 특수글쇠로 비한글 문자 사이를 왕래할 때 cursor가 일시적으로 사라지고 보이지 않던 버그를 잡았다.
• 한글을 조합하던 중에 글자판을 변경했을 때 조합이 종료되지 않던 버그, 맨 마지막 글자가 아니라 중간에서 한글을 조합하고 있다가 한자를 선택했을 때(예: '훈(민)정' 조합 중에 訓民) 변환이 제대로 되지 않던 버그를 잡았다.

2. '고급 입력 스키마 - 고급 글쇠 인식' 기능의 변화

지난 7.4에서 첫 도입되고 나서 별다른 변화가 없었던 '고급 입력 스키마'에 간단한 modifier key 필터링 기능이 추가됐다.
지금까지는 얘를 이용해서 D 같은 문자 글쇠에다가 입력 기능을 배당하고 나면, Shift+D는 말할 것도 없고, 심지어 Alt+D 같은 걸 눌러도 글쇠가 아무 구분 없이 인식하고 동작해 왔다. (Alt 인식이 불가능한 외부 모듈 구현체는 제외)

얘는 말 그대로 저수준 고급 글쇠 인식 기능이기 때문에, modifier의 인식 여부는 modifier 글쇠 자체가 눌렸을 때 변수와 수식을 이용해서 사용자가 알아서 처리하라는 게 취지이긴 하다. 하지만 저건 너무 고지식하다고 여겨져서 Shift, Ctrl, Alt에 대해서 인식 여부를 사용자가 지정할 수 있게 했다.

물론 이건 단축글쇠 규칙만치 세밀하지는 않기 때문에 modifier 글쇠의 좌우까지 구분하는 기능은 없다. 고급 입력 스키마는 A, S, D 같은 인접한 글쇠가 동시에 눌린 것, B를 길게 누른 것, C를 눌렀다가 뗀 것 같은 이벤트를 감지하는 것이 목적이지, 단축글쇠처럼 왼쪽 Shift+L, Ctrl+Win+X 이런 combination을 세밀하게 감지하는 게 일차적인 목표가 아니기 때문이다.

modifier key 필터링 여부를 지정하는 체크 박스는 on/off뿐만 아니라 indeterminate라는 제3의 상태도 있는데(위의 그림에서 Ctrl), 이게 바로 예전처럼 modifier가 눌렸든 안 눌렸든 따지지 않는다는 뜻이다. D와 Shift+D에 대해서 동작을 구분하고 싶다면 Shift는 indeterminate로 맞춰 놓고 별도의 변수로 상황을 구분하면 된다.

Shift는 몰라도 Ctrl과 Alt는 단축글쇠와 충돌하지 않으려면 사실상 언제나 off로 지정해 놓는 게 좋을 것이다. 단축글쇠 옵션에는 좌우 중 무엇을 눌렀는지 구분하지 않는다는 옵션이 있을 뿐, 아예 on/off 여부를 구분하지 않는 옵션이 있지는 않다. 이 역시 대조적이다.

modifier key 필터링은 key down에 대해서만 동작한다. key up은 key down 이벤트에 걸렸던 글쇠가 떼졌다면 그 당시의 modifier와 관계 없이 언제나 동작한다. 키보드가 무슨 마우스 버튼도 아닌데.. A키를 그냥 뗐을 때는 이렇게 동작하고, Shift가 눌러진 상태에서 뗐을 때는 이렇게 동작하는.. 그런 상황은 고려하지 않기로 한 것이다. 그런 기능을 굳이 구현해야겠다면 역시 변수와 수식을 이용해서 사용자가 직접 구현하면 된다.

3. '고급 입력 스키마' 기능의 변화

오랫동안 빈 공간이 많아 황량하고, 별로 자주 쓰이지도 않는 옵션밖에 없던 '고급 스키마 옵션' 탭에 유의미한 옵션이 하나 추가되었다. 바로 '비한글 문자가 입력되어도 기존 한글 조합을 일시적으로 보존'해 주는 기능이다.

타자를 빠르게 하다 보면, 한글을 조합하고 있고 한글 입력과 관련된 글쇠들이 미처 다 떼어지기 전에 space나 쉼표 마침표 같은 문자 글쇠가 먼저 눌러질 수 있다. 이 경우 "ㄷ.ㅏ", "르 ㄹ" 같은 오타가 생기기 쉽다.

허나, 이 옵션이 지정되면 입력 스키마가 이런 비한글 문자를 문자 생성기(한글 입력 오토마타)로 곧장 보내지 않고, 한글의 옆에다가 임시로 붙여 준다. 즉, "다."처럼 된 상태에서 "당. "으로 한글 조합을 계속할 수 있다.
그렇게 있다가 모든 글쇠에서 손이 떼어지고 나면 조합이 종료된다.

이거 간단한 발상이지만 생각보다 꽤 유용하다. 오동작 부작용도 거의 없고 말이다. (물론 공백까지 저렇게 보정이 되게 하려면 '글쇠 및 변수 옵션'의 '추가로 인식할 글쇠'에다가 space도 0x20으로 추가해 줘야 한다.)
스크린샷에서 보다시피, 여는 괄호 계열에 속하는 (<[{ 이런 것은 같이 눌러졌을 때 한글의 뒤가 아니라 '앞'에 붙도록 별도의 옵션을 줄 수도 있다.

이미 옆에 붙은 글자가 있는 상태에서 또 비한글 문자가 입력되면, 이 기능은 그것까지 추가로 붙여 주지는 않는다.
단지, 이미 붙었던 글자를 없애고 새로 들어온 문자로 대체하도록 할 수는 있다. '중복 입력 허용' 옵션은 그렇게 동작 방식을 바꾸는 역할을 한다.

이 기능은 여러 글쇠의 keydown과 keyup을 감지해서 동작하기 때문에 고급 스키마에서 담당하고 있으며, 한편으로 한글과 비한글이 섞인 가변 길이의 조합을 표시하기 때문에 문자 생성기도 '고급 입력기'와 연계해서 동작한다. 정말 말 그대로 고급스러운 기능인 셈이다. 기본 입력기만 사용하고 있을 때는 이 옵션이 사용 불가 상태로 표시된다.

4. 한글 입력 엔진 쪽의 변화

(1) 오토마타 중에서 'xxx 처리 후 조합 중단'을 의미하는 -6, -9 같은 마이너한 기능들이.. 조합이 완료된 한글 뒤에 쓰레기 문자를 삽입하기도 하던 버그를 고쳤다.
그리고 마지막 두 타의 입력 순서를 교환하는 꽤 어려운 -11도 복잡한 상황에서 제대로 동작하지 않던 버그를 고쳤으며, 이 기능은 더 전문적인 특수글쇠에다가도 구현해 넣었다.

(2) 오토마타의 O 변수는 지금까지 입력 글쇠 또는 현재 조합 중인 한글의 종류가 두벌식인지 여부를 비트 1|2 플래그 형태로 갖고 있는데, 이 뿐만이 아니라 지금 한글 조합이 처음부터 사용자의 타자로 입력된 건지 아니면 프로그램에 의해 자동 재현되었는지(4)에 대한 정보도 추가했다.

달라붙었거나 특수글쇠 같은 걸로 재구성된 조합에는 O 변수에 4라는 비트값도 추가되어서 나온다. 그래서 사용자가 처음 한글을 입력할 때는 모아치기 오토마타를 사용하는데, 달라붙은 한글에 대해서는 더 세밀하게 무한 낱자 수정을 사용한다거나 식으로 오토마타를 구성할 수 있다.

(3) C0|0x23이라고 직전 두 글쇠의 입력 순서를 교환하는 특수글쇠를 추가했다.
이건 더 말이 필요하지 않다. 'ㄷ.ㅏ'를 '다.'로, 특히 두벌식 자판에서는 '뭥미'를 '뭐임'으로, '생리'를 '새일'로, 'ㅇ버'를 '업'으로 바꿔 준다. 물론 앞 글자의 조합 상태를 마음대로 넘나들고 바꾸기 위해서는 날개셋 편집기나 MS Word 같은 환경이 필요하다.

두벌식 자판은 구조적으로 동시치기를 구현하기 힘들다 보니, 순서가 뒤바뀐 오타는 이런 식으로 강제 보정하는 것밖에 방법이 없다. 내가 테스트를 해 보니.. 순서가 뒤바뀌는 오타가 날 정도이면 그 오타 이후에도 타자가 여러 타가 진행되어 버리는 편이기 때문에 이런 보정 특수글쇠를 적절한 타이밍에 누르는 것도 그리 쉽지 않을 것 같다. 하지만 이 기능이 없는 것보다는 있는 것이 나으리라고 본다.

이전에 추가되었던 C0|0x22도 원래는 이걸 의도했었으나, 기술적인 난이도 때문에 기능을 온전히 구현하지 못했다. 그래서 글쇠의 교환이 아니라 글자 전체의 위치 교환 수준에 그쳤었다.

5. 편집기의 미세한 버그 수정

이제 더 고칠 게 없을 거라 여겨지는 편집기에서 의외로 버그가 몇 개 발견되어 고쳐졌다. 그것도 직전 버전에만 있던 게 아니라 꽤 오래된 버그들이다.

• 이전 글에서 언급한 대로, 24픽셀 글꼴을 사용하고 있는데 일본어· 중국어 IME의 조합을 나타내는 밑줄(점선이나 실선..)이 여전히 16픽셀 기준 높이로 취소선처럼 잘못 표시되던 문제를 해결했다.
• 아주 미묘하고 발견하기 어려운 버그이긴 한데, 도구모음줄의 세로 폭이 실제보다 더 크게 잘못 계산되어서 아랫부분이 제대로 갱신되지 않고 가로줄 모양의 잔상이 생기는 걸 보신 분이 있으려나 모르겠다. 그런 현상이 절대로 발생하지 않게 조치를 취했다.
• 이건 사용자의 데이터를 파괴할 수 있는 치명적인 버그이다. UTF-16LE가 아닌 다른 인코딩으로 파일을 저장할 때 크기가 수MB(대략 2MB) 정도를 넘어가면 그 2MB 정도의 경계에 속하는 줄이 낮은 확률로 사라질 수 있는 문제가 있었다. 언제나 발생하는 건 아니고 좀 복잡한 조건이 우연히 충족됐을 때만 발생하기 때문에 문제가 이제야 발견되었다.

6. 사소한 UI 개선 사항

(1) 날개셋 제어판에서 어떤 글자판(입력 항목)에 어떤 입력 스키마와 어떤 문자 생성기를 배당할지--빈/기본/고급-- 지정하는 부분의 명칭은 지금까지 아주 오랫동안 "이 입력 항목의 기반 루틴"이었다.

허나, '루틴'이라는 말이 엔지니어가 아닌 일반 사용자 입장에서는 굉장히 어색하고 생뚱맞아 보여서 이걸 '기능 수준'이라고 바꿨다. '빈/기본/고급'이 기능의 수준을 결정하는 것이기 때문이다.
이것 말고 '기술 기반', '기술 수준' 등의 용어도 고려하다가 최종적으로는 "기능 수준"이라고 말을 정했다.

또한 날개셋 한글 입력기가 제공하는 날개셋문자의 종류로는 일반 문자, 세벌식/두벌식 한글 등이 있는데.. 특수글쇠의 명칭이 '특수 코드'라고도 혼용되고 있어서 이를 없앴다. 그냥 '특수글쇠'로 통일했다.

(2) 굉장히 사소한 변화이다만.. 날개셋 편집기에서 다수의 블록을 잡은 뒤 날개셋 외부 모듈로 텍스트 필터를 사용할 때, 블록이 4개까지만 인식되고 5개째 이상부터는 필터 변형이 되지 않던 문제를 해결했다.
이것도 거의 10년 가까이 전부터 변함없이 존재하던 문제였지만, 여파가 워낙 미미하기 때문에 지금까지 방치돼 있었다. 애초에 외부 모듈에서 텍스트 필터는 TSF A급 프로그램이 아닌 곳에서는 사용조차 할 수 없기 때문에 더욱 존재감이 없다..

이 문제를 해결하기 위해 날개셋 편집기가 바뀌어야 할지, 아니면 외부 모듈이 바뀌어야 할지는 난 정확하게 잘 모르겠다. Windows의 TSF 스펙이란 게 한 치의 모호성 없이 명확하게 정의돼 있지 않기 때문이다. 하지만 외부 모듈이 문제를 피해 가는 것이 당장 더 간단하기 때문에 그것부터 조치를 취했다.

일단 내가 주변에서 보는 텍스트 에디터나 워드 프로세서 중에서 불연속적인 다수의 블록을 잡을 수 있는 프로그램 자체가 날개셋 편집기와 MS Word밖에 없다. 하지만 Word는 여전히 외부 모듈에다가 자기가 갖고 있는 모든 블록의 내용을 넘겨주지 않기 때문에 이 기능이 직통으로 동작하는 프로그램은 같은 계열의 날개셋 편집기밖에 없다. 레퍼런스로 삼을 프로그램이 이것밖에 없으니 편집기와 외부 모듈 중 무엇을 고쳐야 할지를 판단하기가 더욱 어려웠다.

(3) 이것도 아주 사소한 변화이긴 하다만, 프로그램이 제공하는 모든 대화상자들을 꼼꼼히 검토했다. 그래서 버튼들만 쭉 나열돼 있는 곳에서 좌우 화살표를 누르면 성격이 같은 것들끼리 포커스가 순환되게 했다. 여기서 버튼이라는 건 '확인/취소' 같은 누르는 버튼뿐만 아니라 라디오· 체크 버튼까지 포함이다.
옛날에 이걸 한번 정비한 적이 있었지만 세월이 흐르면서 그 규칙이 깨진 부분이 다시 많이 생겨 있었다.

(4) 편집기의 '삽입-기타 가져오기' 대화상자도 해당 기능이 처음으로 도입됐던 3.0 이래로 변화가 없다시피했을 텐데..
콘솔 프로그램을 골랐을 때는 파일 경로와 인자, URL일 때는 주소.. 이렇게 각 방식에 필요한 추가 정보만 그때 그때 화면에 표시되게 외형을 바꿨다. 그 결과 대화상자의 크기도 약간 더 작아졌다.

7. 날개셋문자의 0문자 처리

끝으로.. 말이 나온 김에 이번 기회에 규약을 확실하게 정했다.
한글, 일반 문자, 특수글쇠 등.. 각 종류별로.. 종류만 그렇게 정하고 내부 코드값은 아무것도 없는 0인 날개셋문자를 줬을 때 어떤 일이 일어나느냐 하는 것이다.

물론 뭔가 크게 대단한 일이 발생하는 건 아니다. 다만, 한글을 조합 중인 상태에서 0번 일반 문자가 입력되면 조합만 종료된다. 그도 그럴 것이 일반 문자는 그 정의상 한글 조합을 무조건 종료시키고, 0번 문자는 '문자 없음'을 의미하기 때문에 조합만 종료되는 효과가 나는 것이 자연스럽다.

한글 기반이면서 초중종 세 성분이 모두 0인 날개셋문자는 한글 조합을 전혀 건드리지 않고 그 상태를 유지시킨다. 다만, 조합 중이던 한글의 타입은 바뀔 수 있다. 가령, 두벌식으로 '각'을 입력하고 나서 세벌식 기반의 0문자를 입력하면 조합 중이던 문자의 외형은 동일하지만 내부적인 속성이 두벌이 아닌 세벌로 바뀐다. 그렇기 때문에 다음에 두벌식 모음 'ㅏ' 같은 걸 입력하더라도 도깨비불 현상이 일어나서 '가가'가 되지 않고 그냥 '각ㅏ'가 된다.

이런 경우와 달리, 특수글쇠 0문자는 그 어떤 side effect 없이 언제나 현행 조합 유지인 것이 반드시 보장되게 했다.
글쇠 수식에서 조건부로만 무언가가 입력되고 조건이 충족되지 않을 때는 지금 입력을 그대로 놔두고 싶으면 특수글쇠 0문자를 의미하는 C0|0을 배당하면 된다. 단, 텍스트 에디터의 입장에서는 아무 동작도 안 하는 게 아니라 조합 문자열을 덮어쓰는 동작이 발생하기 때문에.. 외형상 텍스트가 바뀐 게 없더라도 텍스트가 변경됐다는(modified) 판정을 받을 수 있다.

Posted by 사무엘

0. 들어가는 말

날개셋 한글 입력기 9.3이 나온 지 벌써 50일 가까이 지났다.
올해 초, 이걸 만들던 당시에는 정말 머리를 쥐어뜯으면서 힘든 나날을 보냈다. '조합 안에 조합 생성', '조합과 후보 자동 완성' 같은 새로운 입력 도구들을 세세한 외형부터 시작해서 이들이 내부에서 입력 엔진과 통신하는 인터페이스를 완전 무에서 처음 창조해 내야 했으니 말이다.

단순히 당장 기능이 동작만 하게 만드는 게 아니라, 앞으로 두고두고 후회가 없을 정도로 최상의 성능과 최적의 확장 가능성을 현실적으로 잘 절충하여 구현한 거라고 개인적으로 확신을 갖는 것이 매우 어렵고 힘든 일이었다.
하지만 다 만들어 버리고 나니 언제 힘든 일이 있었냐는 듯 아무렇지도 않고 세상은 그저 평온하기만 하다.

본인은 2010년대 이래로 현재, 날개셋 한글 입력기의 개발 todo list의 분량이 역대 최저인 시기를 살고 있다. 그만치 마음의 부담을 많이 덜었다.
하지만 대단원을 장식할 그 마지막 기능을 과연 어떻게 설계하고 구현할지가 만만찮은 상태이고, '저것까지만 다 만들어 놓으면 뭐 어떻게 되겠지' 그렇게 생각하던 당시와 비교했을 때 세상이나 내 상태가 그렇게 확 달라진 것 같지는 않다. 이건 당연한 귀결인 건가..;; 아무튼.. 개발 근황 소식을 전하도록 하겠다.

1. 24픽셀 글꼴 추가

날개셋 한글 입력기는 지난 9.0 버전부터 150% (144dpi) 이상의 화면 확대 배율에서 24픽셀 비트맵을 지원하기 시작했다.
이건 굉장히 뜻깊은 과업이었으나, 24픽셀은 16픽셀에 비해 글꼴이 훨씬 적고 부족하다는 게 못내 아쉬움으로 남았다. 옛날에는 이게 화면용이 아니라 도트 프린터 인쇄용 크기였기 때문이다.

그랬는데.. 이때 본인의 머리를 스친 것은 1990년대에 PC 통신을 통해 한창 굴러다니던 아래아한글용 공개 글꼴들이었다. 이런 것들은 비록 비트맵이지만 문서에다 넣고 인쇄도 할 목적으로 쓰이므로 24픽셀, 그리고 심지어 레이저용 40픽셀 글립까지 있다. 내가 이것들 생각을 왜 지금까지 못 했을까?

본인도 중학교 시절까지는 글꼴에 완전 꽂혀서 수십여 종의 공개 글꼴들을 받아서 쓴 적이 있었다. 전문 업체에서 만든 글꼴의 퀄리티에 비할 바는 못 되었지만 저마다 개성이 담겨 있었다.
이것들은 아래아한글 1.0 ~ 1.2 시절, 비트맵 글꼴 에디터가 있던 시절에 근성의 도트 노가다를 통해 만들어진 물건이었다.

2.x도 아니고 1.5쯤 되면서 아래아한글은 자체적으로 조합 로직을 정의할 수 있는 한글 글꼴 포맷까지 제정했으나, 정작 예전처럼 사용자가 고정된 조합 로직 틀에서라도 한글 글꼴을 customize할 수 있는 통로는 완전히 막아 버렸다.
그리고 1.5, 그리고 2.0까지만 해도 보급 글꼴 말고 새로운 글꼴을 구해다 쓰는 건 마치 Doom 2에서 custom WAD 맵을 얹어서 플레이 하는 것만큼이나 번거롭고 귀찮고 어려웠다.

그때까지만 해도 아래아한글은 새로운 외부 글꼴을 등록해서 쓰는 것을 고려하여 설계되지 않았으며, 심지어 글꼴 파일 내부에 자기 이름이나 제조사 같은 메타정보도 들어있지 않았었다. 2.0 전문용에서 첫 도입됐던 한양 시스템의 윤곽선 글꼴조차도 말이다. 그 파일들은 나 같은 사람이 내부 포맷 분석에도 금세 성공했을 정도로 그냥 무식한 벡터 이미지 덩어리 그 이상도 이하도 아니었다.

그 와중에 과거에 만들어졌던 싸제 한글 비트맵 글꼴을 쓸 수 없어서 현기증 난다는 사용자들의 원성이 빗발치자.. 한컴에서는 이미 만들어진 글꼴들을 아래아한글 2.x 같은 후대 버전에서 사용할 수 있게 간단한 파일 포맷 변환 유틸 정도나 만들어서 던져 줬을 뿐이었다.

이렇게 상황이 열악하다가 그나마 1993년에 출시된 아래아한글 2.1은 잘 알다시피 통합 글꼴 포맷을 최초로 도입하고 글꼴 시스템 전용 환경설정 프로그램(fontcfg)까지 도입하면서 이 바닥 시스템이 크게 개선되었다. 뭐, 과거 회상은 이 정도까지 하기로 하고..

본인은 아래아한글이 제공했던 모든 HFT 폰트 파일들을 지금도 갖고 있지만, 그 시절에 추가로 받아서 썼던 공개 글꼴들은.. 너무 옛날 것이어서 그런지 컴퓨터가 바뀌는 과정에서 소실된 듯했다. 남아 있는 게 없었다.
그래도 인터넷 각지에 있는 고전 프로그램 자료실을 뒤진 끝에.. 현재까지 날개셋에 16픽셀로만 존재하던 다음 글꼴의 24픽셀 버전을 구해서 추출하는 데 성공했다. 굽은샘물, 손글씨, 타자기, 파도.. 4종이다.

특히 '손글씨'는 16픽셀에서는 획이 거칠고 별로 보기 좋지 않은데 24픽셀이 훨씬 더 보기 좋다.
굽은샘물은 언뜻 보기에는 예쁘게 생겼지만 '게'와 '계'가 분간되지 않는 등 결함이 몇 군데 있다. 그런데 24픽셀에서도 완전히 똑같은 결함이 남아 있다는 게 아쉬운 점이다.

명조 고딕, 거기에 기껏해야 필기체 일색이던 시절보다 글꼴 부족 문제가 좀 개선됐으면 좋겠다.
뭐, 한글뿐만 아니라 영문 글꼴도 아주 부족하긴 하지만.. 이건 더 답이 없는 문제인 듯하다.

2. 글꼴들의 내부 구조 최적화

그리고, 이렇게 글꼴 관련 작업을 하는 과정에서.. 내부적으로 조합형 한글 글꼴(*.hfn) 파일을 생성할 때 사용하는 빌드 툴을 대대적으로 손질하여 다시 만들었다. 그리고 꼼꼼한 최적화 기능을 추가했다.

최적화라는 게 무슨 말인가 하면...
샘물· 타자기 같은 글꼴들은 벌수가 적고 내부 구조가 굉장히 간단하다. 하지만 8*4*4 도깨비처럼 기존의 범용적인 조합 로직에 끼워 맞춰 글꼴을 만들다 보면 결국 같은 모양의 글자를 여러 벌에서 쓰도록 복붙을 해야 하고 중복 정보가 발생하게 된다.

먼 옛날, 날개셋 한글 입력기 5.3과 함께 본인이 처음으로 작성한 hfn 생성 툴은 사용자가 작성해 준 스크립트대로 곧이곧대로만 파일을 만들었다. 하지만 다음 버전에 들어가는 hfn 파일들은 크기가 약간이나마 더 작아져 있을 것이다.

 물론 지금 제공되고 있는 샘물 계열 글꼴들은 이미 손으로 직접 최적화한 굉장히 단순한 조합 로직 기반이기 때문에 16픽셀용이 크기가 4~5KB 남짓에 불과할 정도로 작다.
그런데 수동으로 최적화하면서 지금까지 생각하지 못했던 것이 바로.. 종성 그룹을 굳이 받침이 있는 경우와 없는 경우로 분류할 필요가 없다는 것이었다. 샘물 계열은 그 정의상 애초에 그거 구분이 필요하지 않은 글꼴이니까 말이다.

바로 이런 헛점을 프로그램이 추가적으로 찾아 줬기 때문에 종성의 그룹 수가 하나 더 줄어들었다. (group size → group reduced to)

아래아한글이 옛날에 제공하던 '가는샘물'과 '필기'는 나름 자체적인 조합 로직을 갖추고 있는 파일이다. 그럼에도 불구하고 최적화 검사를 해 보니 사용하지 않는 자모 그룹, 중복되는 벌이 존재하여 파일 크기를 몇백 바이트나마 더 줄일 수 있었다(16픽셀 버전 기준). 물론 겉으로 드러나는 글자 출력 모습은 하나도 변함없고 말이다.

2000년대 중반에 마소에서 Office Plus pack을 통해 제공했던 옛한글 글꼴은 일단 6*2*4벌 구조이다. 하지만 굴림과 바탕 말고 돋움과 궁서는 시간에 쫓겨서 대충 만들었는지 종성의 벌수가 실질적으로 더 적다. 궁서는 구조적으로 아주 정교한 글꼴인데도 종성이 두 벌로밖에 이뤄지지 않았으니 왠지 엉성해 보일 수밖에 없을 것이다. (날개셋 한글 입력기에 포함돼 있지는 않음)

아래아한글이 제공하던 24픽셀 명조도.. 중성의 벌수가 10개이던 것이 9개로 더 줄어들었다.
오히려 화면용 16픽셀 명조는 11개인데.. 더 큼직한 공간에서 더 미려하게 만들어야 할 인쇄용 글꼴이 미세하게나마 구조가 더 단순한 것을 알 수 있었다.

이건 뭐.. 최적화 기능을 구현하면서 테스트 용으로 사용했던 극단적인 예제이다.
벌과 그룹 수가 최적화 결과 얼마나 드라마틱하게 줄어드는지, 한편으로 아래아한글에서 쓰이던 24픽셀용 '타자기'체가 얼마나 비효율적인 형태로 저장돼 있었는지를 알 수 있다.

그리고.. 이미 만들어져 있는 다른 글꼴 파일을 바이너리 수준에서 변환만 할 때는 신경 쓸 필요가 없지만, 순수하게 텍스트 포맷의 스크립트로부터 조합형 한글 글꼴을 빌드할 때 해결해야 하는 문제가 하나 있다.
바로, 문자열 형태의 벌 명칭을 서로 겹치지 않고 중간 공백(slack) 낭비도 없이 최대한 조밀하게 번호로 대응시키는 알고리즘이다. 모든 벌이 한 성분(초중종 중 하나)의 모든 낱자를 사용하고 있다면 신경 쓸 필요가 없지만, 여러 벌들이 듬성듬성 부분적인 낱자 그룹을 사용할 때는 문제가 복잡해진다.

이 문제는 곧이곧대로만 푼다면 시간 복잡도가 그냥 NP 완전이 된다.. =_=;; 그런데 (1) 지도에서 여러 점들의 주변에 지명을 서로 겹치지 않고 최대한 많이 적절하게 배치하기, (2) 여러 지점들의 최단 순회 경로 구하기, (3) 컴파일러의 코드 최적화 과정에서 제한된 레지스터 공간에 구간별로 주요 지역 변수들을 적절히 등재하기, (4) 수직· 수평으로만 움직일 수 있는 여러 자동차들이 좁은 부지 안에 세워져 있고 이 차를 빼기 위해서 저 차를 빼야 되고 다른 차를 원상복구 시키는 복잡한 상황에서 특정 차를 빼내는 순서 구하기 등.. 실생활에서는 이런 부류의 intractable한 휴리스틱 문제들이 의외로 많이 존재한다.

모든 벌에 대해서 그냥 심벌 테이블을 부여하고 번호가 아니라 문자열로 벌을 식별한다면 slack 걱정을 할 필요가 없긴 하다. 하지만 겨우 날개셋이 사용하는 글꼴 파일이 그런 것까지 사용할 정도로 구조가 복잡하지는 않기 때문에 그냥 숫자 기반 인덱스 체계를 채택한 것이다. 컴퓨터에서 문자열로 아이템을 식별하는 건 포인터와 동적 메모리 등.. 단순 숫자보다 성능 비용이 더 크다.

이로써 조합형 한글 글꼴 빌드 절차는 데이터 읽기 → (글립 최적화 → 조합 로직 테이블 최적화 → 명칭 순서 최적화) → 출력의 순으로 절차가 깔끔하게 완성됐다. 컴파일하는 기능뿐만 아니라, 반대로 빌드된 hfn 파일을 다시 텍스트 기반 스크립트로 환원하는 디컴파일 기능도 이 참에 넣어서 관련 기능을 완전히 끝장을 봤다.

좋은 tool이 완성됐으니, 이제 도스 시절을 풍미했던 아래아한글용 공개 비트맵 글꼴들을 애타게 기다린다. 혹시 지금까지 갖고 계시는 분들은 본인에게 제보해 주시면 좋겠다. 이제 글꼴 분석과 빌드 툴이 완벽하게 갖춰졌고 무엇이건 내 프로그램에 반영 가능하다.

3. 한글 로마자 입력기

끝으로, 10여 년째 기능에 변화가 거의 없던 한글 로마자 입력기 빠른설정에 '공업진흥청 방식'이라는 새 템플릿이 추가되었다.
이건 macOS에서 전통적으로 지원되어 온 로마자 입력 방식인데, 정작 날개셋 한글 입력기가 제공하는 기존 템플릿 5개와는 일치하는 게 없는 독자적인 입력 방식이었다.

ㅓ, ㅡ는 표준 표기법처럼 eo, eu로 입력하지만 ㅇ은 x로 입력하고 ㅚ는 oe로만 입력하며, Shift로 쌍자음을 입력하는 게 마치 여러 입력 방식을 짬뽕한 것 같다.
공진청 방식을 실제로 즐겨 사용한다는 외국인에게서 요청을 받아서 이 기회에 템플릿을 추가했다.

이로써 로마자 입력기 중에서 쌍자음을 1타(Shift도 포함)로 입력 가능한 템플릿은 북한 방식, Korean Writer 방식, 그리고 공진청 방식 이렇게 세 종류가 존재하게 됐다.
지금까지는 ㄸ, ㅉ, ㅃ가 종성에도 들어갈 수 있게 수식이 만들어졌다. 하지만 다음 버전에서는 이를 수정하여 이 낱자들은 언제나 초성에만 입력되게 할 것이다. 로마자 입력 방식이 딱히 옛한글을 염두에 둔 입력 방식은 아니기 때문이다.

4. 나머지

(1) 홈페이지에서 날개셋 한글 입력기를 소개하는 컨텐츠를 더 추가했다.
"첫 화면"에는 한국어가 아니라 한글 차원에서 연구했다는 개발 이념을 더 강조했고, "전반적인 특징"에도 기능 소개 스크린샷을 잔뜩 추가했다.
그리고 입력 도구, 빠른설정, 텍스트 필터만을 소개하는 "입력 보조 기능 소개"라는 페이지를 새로 추가했다. 내가 지금까지 이 바닥으로 참 어지간히도 많은 기능들을 꾸역꾸역 집어넣었다는 생각이 들었다.

(2) 24픽셀 상태에서 날개셋 편집기로 일본어· 중국어 IME를 사용해 보면(빈 입력 스키마), 조합 상태를 나타내는 밑줄이 여전히 16픽셀 기준으로 찍혀서 밑줄이 아니라 취소선처럼 나타나는 버그를 뒤늦게 발견했다. 9.0 이래로 지금까지 계속 이런 버그가 있었다는 뜻인데, 이제야 발견되어서 고쳤다. 심지어 세로쓰기일 때도 이런 문제가 없는데 요건 9.0 작업 당시에 코딩 실수가 있었던 모양이다.

요건 현재까지 날개셋 한글 입력기에서 발견된 거의 유일한 버그이다. 프로그램이 죽는다거나 하는 문제도 아닌 외형적인 실수이다.

5. 맺는 말

(1) 예전에도 한번 말한 적이 있을 것이다. 본인은 사실 생각 같아서는 기능 구현뿐만 아니라 API 구조도 마음에 안 드는 것들을 다 갈아엎고 싶고, 지금의 set/ist의 파일 포맷도 다 바꿔 버리고 싶다. 저 기능들을 처음 구현하던 시절이랑, 지금 이렇게 실물이 완성된 뒤에 본인이 생각하는 날개셋 한글 입력기의 내부 구조 및 전체 그림이 서로 같지 않기 때문이다. 지금이 당연히 더 추상적이고 체계가 더 잡혀 있다.

하지만 그건 사용자의 눈에는 띄는 게 전무한 리팩터링에 불과하기 때문에, 내부 구조가 깔끔해지는 것 말고 들이는 시간과 노력 대비 단기적으로 드러나는 성과가 너무 없고 리스크도 크다.
그런 것까지 무리하게 욕심 내서 다 추진하다가는 내가 학교 졸업을 도저히 할 수 없어지니.. 그건 하더라도 졸업 후에, 날개셋 버전이 10 정도로 확실하게 넘어갔을 때의 매우 장기적인 과제로 남기고자 한다. 이미 지금도 당초 계획보다 이미 1~2년 정도 지연이 발생해 있다. 당초 계획이 없던 기능들도 이것저것 막 구현하는데 나의 귀차니즘과 슬럼프, 능력 부족까지 겹쳐서..

어쨌든, 내 근황과 신상에 큰 변화가 생기지 않은 지금 여건 하에서... 적어도 2010년대 동안은(18~19) 날개셋 한글 입력기는 잠정적으로 9.5x 정도가 마지막 버전이 될 것이다.
9.5 이후로 당분간은 새 버전이 나오더라도 사소한 기능 추가나 버그 수정 위주로만 나올 것이다. 운전에다 비유하자면, 저단에서 고rpm으로만 계속 가속하는 데 한계를 느낀다. 나도 고단으로 변속 좀 해야지..

(2) 당연하다면 당연한 얘기인데, 요즘 문자 입력기들의 추세는 확실히 언어 데이터를 기반으로 자주 사용하는 단어, 앞으로 또 나올 가능성이 높은 문구를 미리 제시해 주는 것이다.
Windows에 내장된 한국어나 중국어 IME는 15년 전이나 지금이나 동작이 크게 달라진 것이 없는 반면, 일본어 IME는 그렇지 않다. Windows XP에서는 TSF의 새로운 기능을 활용해서 조합(composition)을 만들고 있는 중에도 cursor가 조합 안팎을 자유자재로 드나들 수 있는 natural input mode라는 걸 도입했다.

그리고 Windows 8이나 10쯤에서는 전통적인 "발음 입력+space → 단어를 나눠서 구간별로 변환"이라는 동작에서 탈피하여.. 구간 구분 없이 대충 말을 입력하다 보면 다음에 입력할 걸로 예상되는 말이 같이 후보 리스트에 뜨면서 한꺼번에 뭔가 '스마트'하게 동작하는 걸로 재미있게 바뀌어 있었다.

한글과 영문은 단어 단위 조합은 모바일에서만 존재하며, PC에서는 그런 계층이 없다. 일본어는 기왕 단어와 문장이 조합창을 몽땅 거치다 보니, 거기서 할 수 있는 모든 언어적인 변환은 다 끌어들이는 것 같다.
그 반면 한글은 기본적으로 글자 단위+rule 기반의(data 기반이 아닌) 간단한 조합만 거친다. 이런 구조에서 할 수 있는 온갖 기괴한 응용 기능은 지금까지 날개셋 한글 입력기의 주된 관심사요 개발 아이템이었다.

하지만 거시적으로는 한국어의 입력도 그런 기능에다가 어절 단위의 더 큰 규모의 조합과 접목할 필요가 있다. 이를 염두에 두고 이번 9.3에서는 "조합 안에 조합 생성"이라는 입력 도구가 추가되었다. 이것은 날개셋 한글 입력기의 개발 역사상 매우 의미심장한 기능이다.
내 여건이 허락하는 한, 날개셋 한글 입력기는 한글 같은 문자를 기반으로 하여 생각할 수 있는 모든 입력 기능을 구현할 수 있고, 이를 토대로 세벌식 자판의 장점도 덤으로 부각시킬 수 있는 입력 엔진으로 굳건히 성장할 것이다. 그리고 그 결과물이 프로그램과 논문으로 더 나오게 될 것이다.

Posted by 사무엘

0. 들어가는 말

날개셋 한글 입력기가 약 4개월 간의 작업 끝에 9.1에서 또 9.3이 완성되어 나왔다.
내부적으로 4200줄에 달하는 코드가 추가되었다. 먼 옛날에 프로그램을 처음부터 다시 만들었던 2.0이나 3.0 같은 시절 이후로, 지난 10여 년간 한 버전 단계에서 이렇게 많은 분량의 코드가 추가된 적은 없었다. 물론 요즘은 예전처럼 리팩터링을 하지 않고 외형적인 새 기능이 계속 추가되고 있으니, 새로운 클래스와 리소스 심벌 같은 비실행문도 많이 추가되고 그 덕분에 코드의 증가폭이 예전보다 더 커지기도 했다.

원래는 3월쯤에 새 버전을 내놓을 생각이었으나, 입력 도구의 작업이 완료된 것까지만 일단 공개해 버리기로 했다.
비록 원래 만들려던 기능들을 다 구현하지는 못했지만, 날개셋 개발이 늘 그래 왔듯이 예기치 못했던 다른 기능이나 개선 사항이 대신 추가된 것도 적지 않다. 그것만으로도 지금 프로그램은 버전을 0.2 정도는 충분히 올릴 자격이 된다. 짧게는 수 개월, 길게는 무려 수 년 동안 내 머릿속에만 나뒹굴던 아이디어들이 깔끔한 클래스 형태로 구현되고, 사용자들이 직접 써 볼 수도 있는 기능이 됐다니 참 감개무량하다.;

1. 조합 안에 조합 생성

이번 9.3 버전에서 가장 중요한 부분은 단연 입력 도구이다. '수식 계산 기록', '내부 입력 상태' 같은 것은 지난번 개발 근황글에서 이미 소개된 바 있으며, '조합과 후보 자동 완성' 도구도 이때 같이 다뤄졌다.
마지막으로 '조합 안에 조합 생성'은 근황글을 쓰던 당시에는 아직 미완성 상태였기 때문에, 그냥 개념 설명만 늘어놓는 걸로 그쳤다.

하지만 사실은 이거야말로 제일 획기적인 물건이다. 입력 도구가 고유한 문자 조합을 생성해서 응용 프로그램으로 보내는 것은 진작부터 구현돼 있었으나.. 더 나아가 응용 프로그램이 받는 그 조합 결과를 입력 도구가 가로채서 변조하는 것은 지금까지 선뜻 떠올릴 수 있지 않았기 때문이다. 그 기술적인 통로를 마련하는 것도 굉장히 어려운 작업이었다. 그것도 편집기, 외부 모듈, 입력 패드까지 세 군데 모두에서 말이다.

그런데 그걸 하고 나니 한글 입력과 관련하여 구조적으로 난감하던 문제를 굉장히 쉽게 해결할 수 있었으며, 이를 이용한 굉장히 창의적인 활용을 할 수 있었다.
이 입력 도구는 사용자가 입력한 문자열을 어떤 방식으로 변환할지를 자체적인 설정을 통해 지정할 수 있다.

(1) 먼저, 한글 독음을 단어 단위로 한자로 변환할 수 있다.

물론 기존 문자 생성기도 단어 단위 한자 변환을 지원한다. 하지만 그 기능은 매번 번거롭게 '한자' 글쇠를 눌러야만 호출할 수 있으며, 지금 변환을 몇 글자 단위로 할지를 단일 목록에서 유동적으로 고를 수 없다. 그리고 결정적으로 편집기 내지 TSF를 온전히 지원하는 환경이 아닌 곳에서는 기능이 동작하지 않으니 그냥 반쪽짜리이다.

이때 '조합 안에 조합 생성' 도구와 이 변환기를 동원하면, 마치 중국어 IME로 병음을 입력해서 변환하듯이 번호만 찍으면서 붙여 쓴 긴 한자어 합성어를 차근차근 한자로 아주 빠르고 편하게 변환할 수 있다.
아무 구현체에서나 동일하게 동작한다는 것도 큰 장점이다. 조합창을 띄우는 걸 운영체제에 맡기는 게 아니라 그냥 내가 독자적으로 처리해 버리고, 운영체제에다가는 완성된 문자열만 보내는 식으로 동작하기 때문에 가능한 일이다.

(2) 다음으로, 한자를 한글 새김을 통해 입력할 수 있다.

이 입력 방식은 타자를 많이 해야 하는데 정작 한자는 한 글자씩밖에 입력하지 못하니 불편하다. 하지만 훈이 같은 한자들, 다시 말해 뜻이 유사한 한자들을 한 목록에서 뽑을 수 있기 때문에 일면 대단히 편리하고 유용한 기능이 될 수도 있다. '마을, 나라, 새, 빛, 어조사' 같은 걸로 한자를 찾아보면 아마 놀랄 것이다.

물론 이 프로그램은 이 훈이 체언(+조사)인지 용언(+어미)인지를 구분해 주지는 않는다. 그러니 '돌'이라고 찾으면 stone이 걸릴 수도 있고 '돌다'라는 뜻의 글자가 걸릴 수도 있다. '새'는 '새 이름으로 저장' 개드립에서도 알 수 있듯이 bird와 new가 모두 걸린다. 그래도 이 정도 모호성쯤은 새김으로 한자 입력 기능의 효용성을 본질적으로 폄하하지 못한다.

(3) 그리고 끝으로, 한글이 아닌 영문을 대상으로 T9 변환 입력 방식을 제공한다.

숫자 키패드의 부족한 글쇠만으로 라틴 알파벳을 입력하려면 한 글쇠에 필연적으로 2개 이상의 알파벳이 중첩 배당돼 있어야 한다. 그리고 한 글쇠 그룹에 속한 알파벳은 그 글쇠를 여러 번 눌러서(다중타) 선택하곤 한다.

그런데 후순위에 속한 알파벳을 일일이 여러 번 눌러서 입력하는 건 참 불편하다. 그렇기 때문에 다중타 없이 그냥 그 글쇠를 쭉 입력하더라도, 글자가 아닌 단어 레벨로 가면 별다른 중의성 없이 빠른 입력이 가능하다.
한자를 변환할 때도 '단', '어', 같은 글자 단위로 일일이 하면 느릴 뿐만 아니라 후보 수도 엄청 많지만, '단어'라고 검색하면 '單語' 말고는 다른 선택의 여지가 없듯이 말이다.

요런 입력 방식을 T9이라고 부르는가 보다. 당장 위의 예제 그림을 보면 {ADZ}, {TUY}, {OP}, {ILJ}, {EWQ}라는 조합 중에서 실제로 유의미한 단어를 구성하는 건 DUPLE(X) 이런 것밖에 없음을 알 수 있다.
스마트폰이 보급되기 전에도 일부 버튼식 전화기에는 숫자 밑에 알파벳이 ABC, DEF, GHI... 이런 식으로 배당돼 있는 게 있었다. 단, Q와 Z가 PQRS, WXYZ 이렇게 붙은 8키 버전이 있는가 하면 QZ가 따로 분리된 9키 버전도 있었던 것 같다.

이번에 제공되는 T9 변환기는 또 고유한 환경설정 기능이 있어서 이런 알파벳 그룹을 사용자가 지정할 수 있다. 전통적인 T9 구성뿐만 아니라, 알파벳을 얼추 빈도수를 고려하면서(자주 등장하는 글자를 적은 다중타로 곧바로) PC Qwerty 배열과도 얼추 일치시킨 나름 창의적인 layout인 모비언스의 SmallQwerty도 내장값으로 제공한다. 얘는 9.1에서 추가된 '휴대전화 입력기'의 영문 모드로 이미 제공되고 있으니 곧장 연계 사용 가능하다.

T9을 '휴대전화 입력기' 말고 키보드로 써 보기 위해서는 해당 입력 스키마가 빈 입력 스키마 계열이 아니어야 한다. ('빈 입력 스키마와 호환되게 옵션도 포함') 그도 그럴 것이 글쇠를 날개셋으로 보내지 않고 응용 프로그램으로 줘 버리면 이 입력 도구가 글쇠를 받아서 동작할 수 없기 때문이다. 글자판을 그런 입력 스키마로 바꾸면 조합이 취소되며 이 입력 도구가 동작할 수 없다고 이렇게 에러 메시지가 나올 것이다. 이번 기회에 '입력 도구'들이 내는 에러 메시지 창도 키보드 포커스를 침범하지 않는 형태로 깔끔하게 다시 만들었다.

T9을 구현하기 위해.. 먼 옛날에 본인이 컴퓨터용 Scrabble 게임을 개발할 때 쓰였던 단어 DB 엔진이 동원되었다. 정확히는 현재 버전이 아니라 차기 버전에서 도입할 새 엔진이었으나, 그 게임 프로그램은 3.x대에서 더 버전업이 되지 못하고 현재 개발이 중단됐다. 현재 탑재된 DB도 게임용 사전인지라, 고유명사나 대문자 이니셜 없고 오로지 전체 대문자 또는 전체 소문자인 일반적인 단어들만 있다.

그리고 스크래블이 타일 수가 7개이다 보니.. 단어가 길어야 9~10글자짜리만 있고 막 긴 단어들이 있지는 않다. T9이란 이런 거구나 맛보기 시연을 보이는 정도로만 있다. 영문 입력이나 DB 구축이 내 프로그램의 주된 개발 대상이 아니니 현재 버전에서는 이 정도로만 넣었다.
사실, 버튼 배치의 제약이 없는 스마트폰에서는 어지간히 작은 화면에서도 T9 대신 그냥 Qwerty 배열을 통째로 집어넣는 게 대세이긴 하다. 영미 문화권에서 기어이 Qwerty 키보드를 버튼 형태로 주렁주렁 집어넣은 블랙베리 스마트폰이 괜히 오랫동안 인기를 끌었던 게 아니니 말이다.

아무튼, '조합 안에 조합 생성' 입력 도구와 변환기가 도입된 덕분에 지금까지 날개셋 한글 입력기가 문자 단위의 기본 글쇠배열만 제공하던 것에다가 뭔가 더 유의미한 변환 기능이 덧붙을 수 있게 됐다. 이것까지 지원하는 건 아니지만 일본어 글쇠배열에다가 실제로 한자 변환 기능이 들어갈 수 있으며, 한글 발음이나 영문 병음으로 실제 중국어를 입력할 수도 있다. 이것이 이번 9.3 버전의 가장 큰 의의이다.

'조합 안에 조합 생성' 도구와 '조합과 후보 자동 완성' 도구는 서로 좋은 상호보완 관계 겸 대조군을 형성한다. 동작하는 관점이 서로 다르다. 동시에 사용할 수도 있지만 목록 창이 뜨는 위치가 비슷하고, 둘 다 화살표 같은 글쇠를 사용하기 때문에 충돌이 발생할 수 있다는 점을 유의하시기 바란다.

전자는 언제나 키보드를 사용하지만 후자는 키보드 사용이 옵션이다. 전자는 1~9 숫자로 목록을 바로 고르는 기능이 있지만 후자는 없다. 전자는 실제 후보 변환을 표방하는 기능이지만 후자는 개발툴이나 웹브라우저 입력란에서 제공하는 자동 완성 기능을 표방하기 때문이다.

2. 제어판 시스템 계층의 개편 + 입력 도구의 자동 구동 기능

이번 9.3에서는 '한글 표현 방식' 탭에 이어(작년 12월에 공개) 그 상위의 '시스템 계층' 탭도 외형이 크게 바뀌었다.
가장 먼저, 즐겨 사용하는 입력 도구는 구현체 프로그램(편집기, 외부 모듈, 입력 패드)이 실행될 때 자동으로 같이 뜨게 하는 기능을 추가했다.

이 기능이 가장 유용하게 쓰일 구현체는 외부 모듈이다. 외부 모듈은 기본적으로 자신을 구동하는 프로그램의 스레드 단위로 전부 제각각 따로 돌기 때문에 한 곳에서 입력 도구를 띄운 게 다른 프로그램에서는 전혀 동작하지 않기 때문이다. '글쇠배열 이름 표시' 같은 건 이렇게 자동으로 뜨게 해 놓으면 앞으로 새로 실행되는(이미 실행된 건 말고) 모든 프로그램에서 '글쇠배열 이름 표시' 기능이 동작하게 되므로 매우 편리할 것이다.

물론 이건 입력 도구들을 띄워 주기만 할 뿐, 각 프로그램에서 돌아가던 입력 도구들의 내부 설정과 창 위치, 크기 같은 걸 한데 동기화까지 하지는 않는다. 하지만 띄워 주는 기능만으로도 충분히 유용할 것이다.

입력 도구 목록을 집어넣을 큰 공간이 필요해진 관계로.. 지금까지 널널하던 시스템 계층 탭은 각종 UI 컨트롤들의 배치가 조밀해졌다.
공간을 잔뜩 차지하던 각종 설명문과 안내문들을 다 뺐다. 가령, 시스템 계층의 설정은 파일에 저장되지 않는다는 안내문이 지금까지 상단에 있었는데, 이건 시스템 계층 내지 그 하위 탭에서 '가져오기/내보내기'를 실제로 시도했을 때 한 번만 별도의 메시지 박스로 안내를 하게 동작 방식을 바꿨다.

다음으로, 글꼴 본뜨기에 대한 긴 설명도 그냥 도움말 링크로 대체했다.
이미 한자 글립이 존재하고 글꼴 본뜨기가 돼 있으면 본뜨기를 "다시" 수행한다고만 말이 나온다. 하지만 한자 글립이 없고 본뜨기를 한 적이 없다면 본뜨기를 "반드시" 해야 된다고 강한 어조로 말이 나오며, '글꼴 본뜨기'라는 버튼의 글자도 더 진해진다.
그리고 지금까지 글꼴 본뜨기 스크립트를 바로 불러와서 편집하는 기능은 없었는데 이것도 사용자의 편의를 위해 '절차 편집'이라고 추가했다.

UI가 굉장히 그럴싸하게 잘 바뀐 것 같다.
참고로, 타자연습이야 입력 도구를 전혀 운용하지 않는 프로그램인 관계로, 거기서 제어판을 열어서 시스템 계층으로 들어가면 입력 도구 목록 부분은 전부 공란으로 대체되고 아무것도 뜨지 않는다.

날개셋 한글 입력기에서 체크 list box라는 GUI 컨트롤이 쓰인 건 이번이 처음이다.
이게 사실은 Internet Explorer 4도 아니고 3에서부터 도입된 물건이긴 한데(공용 컨트롤 버전 4.70), IE가 없거나 1~2인 초짜 Windows 95에서는 GUI가 제공되지 않기 때문에 역시 이 목록이 나타나지 않는다..;;

3. 데이터: 글꼴

'한컴타자'라는 16픽셀 한글 조합형 글꼴을 추가했다. 다음과 같이 생겼다.

우리가 지금 '한컴 타자연습'이라는 이름으로 알고 있는 프로그램은 내력이 생각보다 굉장히 긴 프로그램이다.
얘는 '한(아래아)글타자'라는 이름으로 1995년경에 도스용으로 최초로 개발되었다. 이때는 프로그램이 아래아한글 3.0 Windows용이 사용하던 기본 글꼴(일명 시스템, 9포인트)과 비슷한 모양의 글꼴을 사용했는데, 이번에 날개셋에 추가된 글꼴은 바로 이것이다.

도스용 mshbios가 사용하는 글꼴이 Windows의 바탕체 원판과 완전히 동일한 형태는 아니고 약간 열화된 버전이듯이, 이 글꼴도 아래아한글 글꼴 원판과 동일하지는 않다. 일부 글자가 미묘하게 엉성해 보이기도 하지만 그래도 도저히 사용하지 못할 퀄리티는 아니다. 고유한 조합 로직을 갖고 있지도 않고 그냥 도깨비 8*4*4벌인지라 추출하는 데 아무 어려움이 없었다.

지금 다시 보니 '가는돋움'이라는 기존 서체와 비슷해 보이기도 하지만, 그거보다야 더 홀쭉하고 획이 둥글기 때문에 충분히 서로 다른 느낌이 난다.
1996년 무렵부터는 '한글타자'는 '한컴타자'로 이름이 바뀌고 본문의 글꼴도 평범한 명조로 바뀌어서 이 독특한 글꼴은 더 찾아볼 수 없게 되었다.

그러다 200x년대, 아래아한글 워디안과 2002 시절에 드디어 그래픽이 일신한 Windows용 버전이 나왔으며, 한번 만들어졌던 게 별다른 개선 없이 아래아한글 2007까지 갔다. 도스용은 회색 배경에다 단조로운 텍스트 위주 구조였는데 이 버전은 배경이 나무 재질로 바뀐 게 인상적이었다.

그 뒤 아래아한글 201x 타이밍에 와서야 한컴타자는 완전히 다시 개발되었으며, 이번에는 시대의 흐름에 걸맞게 온라인 타자 대련 기능까지 추가되어 오늘날에 이르고 있다. 온라인 연계는 날개셋 타자연습에 대해서도 게임의 3D화와 더불어 본인이 갖고 있는 희망사항이지만.. 혼자 감당할 여력이 안 되니 희망사항으로만 머무르고 있다.

아무튼 날개셋 편집기라는 한글 비트맵 글꼴 박물관에 역사적인 작품이 하나 추가됐으니 관심 있는 분은 사용해 보시기 바란다.

4. 기타

(1) 이 밖에 '세벌식 12키'라는 입력 유형을 예제로 추가했다. 그 좁은 12키에다가 왼쪽에서 오른쪽으로 초중종성을 배치하고, 중앙 하단의 0은 가획 글쇠를 배당했다. 글쇠 수가 부족한 관계로 두벌식보다 평균적인 타수가 늘어나는 건 불가피하지만 그래도 음절 경계 모호성이니 도깨비불이니 하는 문제는 일체 없다. 12키용 세벌식도 이 정도 실험적인 시도는 의미가 있다고 여겨진다. 이것도 물론 '휴대전화 입력기' 입력 도구에다가 가져와서 써 볼 수 있다.

입력 방식을 설계할 때 아까 영문 T9도 그렇고 다중타를 가능한 한 기피하는 게 추세인 것 같다. 안드로이드용 세벌식 입력기로 유명한 '세나'도 12키보다는 글쇠 수를 더 늘리고, 중첩 배당된 낱자는 다중타가 아니라 한 버튼을 클릭 후 '사방으로 드래그'하는 방식을 채택해 있다. 개인적으로는 그게 익숙하지 않아서 그런지 좀 불편하긴 하다.

(2) 타자연습은 지난 3.8 이후로 변화 사항이 없지만, 이번 대대적인 입력기 개발로 인해 바이너리 호환성이 깨졌다. 그래서 같은 버전을 다시 올렸다.
이미 타자연습을 잘 쓰고 계신 분은 프로그램을 굳이 다시 설치할 필요까지는 없다. 하지만 입력기의 커널과 타자연습의 커널이 서로 다르면 타자연습에서 '고급 입력 스키마나 고급 입력기' 같은 걸 사용할 수 없어지기 때문에 업데이트를 하는 것이 좋다.
딱~ 하나, 프로그램 main 화면에서 Alt+1~6을 눌러서 탭을 바로 오가는 기능만이 추가됐다.

참고로 타자연습은 '입력 도구'를 구동하는 기능을 전혀 갖추고 있지 않은 구현체이다. 키보드 연습만 하지 전문적인 텍스트 입력을 표방하지는 않으니까..
그렇기 때문에 9.3에서 새로 추가된 각종 입력 도구 기능들을 만나 볼 수 없으며, 거기서는 날개셋 제어판을 띄우더라도 시스템 계층에 '입력 도구 자동 실행' 같은 옵션도 전혀 나타나지 않는다.

(3) 요즘 알다시피 보안을 빌미로 검열이 강화되고 있는 관계로, 웹에서 exe든 msi든 네이티브 바이너리를 덥석 배포하는 게 갈수록 껄끄러워지고 까다로워지고 있다. 이 와중에 내 프로그램은 디지털 서명이 없고, 내 웹사이트는 인증서(https..) 같은 것도 없다 보니 이 난관은 어떻게 극복해야 할지 모르겠다.

본인은 바이러스 백신, 보안 프로그램을 전혀 사용하지 않기 때문에 그런 프로그램의 개입으로 인해 날개셋이 설치되지 않거나 차단되는 문의에 대해서는 어찌 대처해야 할지 아는 게 전혀 없다. 요즘 그런 문의가 계속해서 와서 내가 그런 건 도와 줄 수 없다고 다운로드 페이지에다가 미리 양해를 구해 놨다.

글쎄 내 프로그램까지 굳이 찾아서 쓸 정도의 사용자라면 컴퓨터에 대해서 전혀 모르는 초짜도 아닐 것이고, 이렇게만 써 놔도 이해는 할 것이다. 하지만 좀 궁색해 보이니 더 근본적인 해결책을 찾긴 해야 할 것이다.

5. 맺는 말

지난 2016년 말부터 2017년 상반기까지 본인의 날개셋 개발 관심사는 '복합 낱자 입력 로직 생성기'였다.
두벌식(세벌식이 아니라), 옛한글(현대 한글이 아니라), 모바일(PC가 아니라), 일부 글자만 입력(전체가 아니라) 같은 복잡하기 그지없는 상황에서도 원하는 글쇠배열과 결합 규칙에 따라 세부 한글 입력 로직을 전부 자동으로 구성해 주고 중간에 낱자와 글자 경계에서 발생할 수 있는 각종 충돌이나 모호성을 다 감지하고 회피해 주는 입력 로직 설계 시스템을 개발했다. 이걸로 논문도 썼다.

이 과업을 마무리 지은 뒤 2017년 봄~여름 사이에는 편집기의 에디팅 엔진에도 손을 봐서 화면 스크롤 관련 10몇 년 묵었던 고질병 버그를 하나 잡기도 했다.
그리고 150% 이상의 고배율 화면에서는 16 대신 24픽셀 글꼴 표시 기능을 오랜 작업 끝에 도입하여, 1.0 이래로 16픽셀에 묶여 있던 한계를 거의 16년 만에 극복했다.

그 뒤 2017년 하반기부터.. 9.x 버전에서 지금까지 본인이 집중적으로 개발하고 있는 분야는 '입력 도구' UI들이다. 앞서 살펴보았듯이 이 바닥도 알고 보니 연구하면 연구할수록 노다지이더라. 공통 인터페이스 하나만 잘 뚫어 놓으면 그걸 토대로 클래스 상속 받아서 사용자의 문자 입력에 큰 도움을 줄 수 있는 기능들을 잔뜩 추가할 수 있다.

지금까지는 화면 키보드, 문자표 같은 밍숭맹숭한 기능들만 있었지만, 입력 도구들이 문자 입력 상태나 현재 cursor 위치 같은 걸 세밀하게 모니터링 해서 조합 및 후보 변환 자동 안내 내지, 한글을 다른 문자를 입력하는 메타문자로 사용하는 변환 도구를 다 구현해 냈다.

예정에 없던 작업들이 계속 추가되는 바람에 몇 년째 늦춰지고 또 늦춰졌지만,
이제 9.3 다음으로 올해는 진짜로 세벌식이 타자기에서나 빠르지 PC에서는 두벌식과 별로 차이 안 난다는 말을 완전히 반박할 수 있는 동시치기 관련 기능을 넣고, 이걸로 입력기의 큰 기능 줄기 연구는 접으려 한다. 그리고 여기까지 연구한 걸로 발표논문 정도는 하나 더 써서 2016년 때처럼 학회 갈 생각이다.

등산으로 치면 지금은 몇천 m 짜리 거대한 산의 정상을 저 멀리 앞두고, 정상 다음으로 제일 높은 둘째 봉우리에 도달해 있는 것과 비슷하다. 정상으로 가려면 능선 타고 가서 마지막 암반 봉우리를 오르는 것만 남았다.
석사 졸업 이후로 지금까지 연구했던 것 쫙~ 종합하고 살 붙이고, 추가 실험 결과 넣고.. 그러면 뭐 논문 나오겠지? 졸업은.. 30대 넘기기 전까지만 하면 될 듯.

전에도 말한 적 있듯이, 그냥 한글이라는 문자가 있고 컴퓨터라는 기계가 있으면 입력과 관련하여 이론적으로 할 수 있는 오덕질이 몽땅 가능한 통합 시스템을 구축하는 게 목표이다. 한글 갖고 어떤 형태로든 응용을 해 보려면 내 프로그램을 쓰지 않을 수 없는 구도를 말이다.

Posted by 사무엘

오늘은 날개셋 한글 입력기 9.3에서 팝업창 형태로 새로 추가되는 보조 입력 도구 두 가지를 소개하도록 하겠다.

1. 조합과 후보 자동 완성

이 입력 도구는 구동 직후에 화면에 뜨는 것이 없다. 그 대신, 사용자가 뭔가 한글 입력 같은 조합을 만들기 시작하면 짠 나타나서 지금 단계 이후에 진행 가능한 조합(왼쪽)과, 이 상태에서 변환 가능한 후보 문자열(오른쪽)들을 목록으로 쫙 표시해 준다.
사용자 정의 조합의 경우, 가령 A를 누른 뒤에 ' ` ^ -이런 것을 뭘 더 누를 수 있고, 그걸 누르면 문자가 무엇으로 바뀌며, 지금 상황에서 무슨 문자로 변환 가능한지 목록으로 미리 볼 수 있다.

위의 그림은 영문 쿼티에다가 글자별로 온갖 확장 부호들을 후보로 배당해 놓은 QwertyExt 예제를 불러온 뒤 =를 눌렀을 때 나타나는 목록이다. 비록 단어 단위가 아니고 글자 단위이긴 하지만, 일일이 한자 글쇠를 누를 필요 없이 곧장 후보 변환을 할 수 있다.

위의 그림은 각각 한글과 라틴 알파벳으로 일본어 히라가나 문자를 입력할 때 나타나는 목록의 모습이다. 지금 상황에서 저런 알파벳이나 한글 자모를 누르면 저런 문자가 계속 입력된다는 것을 알 수 있다. 검정보다 약간 옅은 회색 글자는 이 문자가 조합이 아닌 완성된 형태로 삽입된다는 것을 나타낸다.

일반적인 한글 조합은 사용자 정의 조합과는 달리, 기본적으로 테이블 기반이 아닌 '공식 기반'이니 직관적인 편이며, 조합 가능한 글자 수도 아주 많다. 그렇기 때문에 'PC+현대 한글' 같은 아주 널널한 경우라면 굳이 이런 식의 preview 기능이 필요하지 않을 것이다.

하지만 한글 입력도 옛한글을 다룬다거나 글쇠 수가 아주 적은 모바일 내지, 허용 한글 제약 기능이 있는 특수한 상황이라면 이 도구의 유용성이 크게 올라간다. ㄹ로 시작하는 옛한글 겹자음은 ㄷ으로 시작하는 옛한글 겹자음보다 훨씬 더 많다는 걸 알 수 있다.

ㄷ뿐만 아니라 '두'다음에 결합 가능한 옛한글 중성들도 저렇게 쫙 표시된다.

'복합 낱자 입력 로직 생성기'를 돌려서 KS X 1001 완성형 한글만 입력 가능하게 하고, 더 결합의 여지가 없는 단계에 도달하면 조합을 곧장 끊게 오토마타를 설정했다. 그랬더니 '바'와 '파'에 대해서 이렇게 서로 다른 결과가 나왔다. '파' 다음에는 '바'와는 달리 ㄷ, ㄺ 같은 받침이 붙지 못한다. '바'는 반대로 '파'에 있는 받침 ㅆ이 존재하지 않는다.

'박'은 '밖'이 결합 가능하며 '발'은 그 뒤로 '밝, 밟'이 존재하기 때문에 쟤들 둘만 회색이 아닌 검정으로 표시되어 있다. '밟'이 저 목록에 존재하지 않는 이유는 ㄼ이 단독 글쇠로 존재하지 않는 세벌식 390 글쇠배열을 기준으로 했기 때문이다.

이 입력 도구는 현재 사용 중인 키보드 입력 스키마뿐만 아니라 자체적인 입력 기능을 갖춘 타 입력 도구를 기준으로도 잘 동작한다. 한손 입력기는 저렇게 천지인 (또는 옵션을 바꿔서 나랏글) 모음에다가 5개 자음(초성 종성 따로)을 갖췄다는 것이 목록을 통해서도 확인된다.

한글 조합에 대해서 진행 가능한 조합 단계는 (1) 가장 최근에 입력된 낱자에 대해서 더 적용 가능한 낱자 결합 규칙을 모두 먼저 표시한 뒤, (2) 바로 다음 입력 단계(가령, 중성 다음엔 종성)에 해당하는 글쇠들 중 글쇠배열에 있는 것을 표시하는 식으로 동작한다.
즉, 낱자 결합 규칙과 글쇠배열을 기본적으로 활용하되, 이 중에서 오토마타 수식과 한글 입력 범위 제약 검사를 통과한 것만 한정해서 가나다 순으로 출력한다.

이 도구는 오로지 현재 조합 중인 문자(열)에만 관심이 맞춰져 있다. 그렇기 때문에 종성을 입력하고 있을 때 다음 글자의 초성이나 중성(두벌식 기준)까지 미리 제시해 주지는 않는다. 사용자의 요청이 많고 그것까지 고려하는 게 충분히 유용하다면 다음 버전에서는 반영될지 모르겠지만 현재로서는 제외했다.

그리고 이미 제공되는 후보 변환 UI와는 달리, 숫자를 눌러서 항목을 바로 선택하는 기능도 제공되지 않는다. 얘는 후보 변환 UI보다는 개발툴의 에디터 같은 데서 제공하는 "자동 완성 목록 UI"를 표방하여 설계됐기 때문이다. 키보드를 사용하려면 설정 대화상자에서 옵션을 지정해야 하며, 이 경우 상하좌우 화살표와 Page up/down으로 선택막대를 이동시킬 수 있다. 엔터와 ESC는 덤이고.

이 도구는 '글쇠배열 이름 표시'와 마찬가지로 원래는 cursor의 바로 아래에 표시돼야 한다. 하지만 구현체의 상황에 따라서는 기술적으로 위치를 알 수 없어서 불가피하게 화면 한구석 같은 엉뚱한 곳에 표시될 수도 있다.
심지어 EditPlus 3.x는 이 도구를 띄워 놓으면 조합 문자열이 계속 같은 곳에서 덮어 써지면서 입력이 제대로 진행되지 않았다. 후대 버전에서는 고쳐졌나 모르겠다.

이 프로그램이 근본적으로 없는 길을 트는 방식으로 동작하며, 한 프로그램에서 되게 하는 방법이 다른 프로그램에는 부작용을 일으키곤 한다. 그렇기 때문에 EditPlus 한 프로그램에서만 부작용이 발생하는 걸 더 어찌할 수는 없어 보인다. 일단 개발 과정에서 이런 일이 있었음을 밝힌다.

2. 조합 안에 조합 생성

날개셋 한글 입력기는 말 그대로 한글을 입력하는 게 핵심인 입력기이다.
한글 IME는 조합하고 있는 한 글자만 신경 쓰면 되지 중국어나 일본어 IME처럼 단어· 문장을 통째로 조합을 잡을 필요가 없다. 길다란 조합 문자열 내부에서 또 가상의 caret을 이동한다거나 구간별로 영역을 달리하여 점선이나 실선으로 표시할 필요도 없다. 그건 내 프로그램의 관심 분야가 아니라고 도움말의 '일러두기'에다가 명시까지 해 뒀다.

개발자인 본인의 시간과 체력은 매우 한정돼 있는데, 이 와중에 관심 분야를 대책없이 이것저것 문어발처럼 뻗치다 보면 프로그램의 정체성이 죽도 밥도 안 되는 이상한 산으로 가 버릴 위험이 있다. 더구나 편집기 같은 전용 프로그램이라면 모를까 외부 모듈이라면, 한글 IME에서는 어차피 운영체제가 조합을 그렇게 일본어· 중국어 IME처럼 표시하는 기능을 애초에 지원해 주지도 않는다.

그럼에도 불구하고 내 프로그램도 기왕이면 타 언어 IME들이 할 수 있는 일을 다 할 수 있으면 좋지 않나 하는 생각을 본인은 아주 오래 전부터 해 왔다. 기약 없는 먼 미래의 일이지만 장기 과제로 염두에 두고 있었다.
그리고 2017년 겨울~그리고 올해 초 사이에 바로 그 꿈이 실현되는 미래가 찾아왔다.
글자 단위로 동작하는 기존 문자 생성기를 내부 버퍼에다 감싸서 단어· 문장 단위로 통째로 변환 후보를 제시하고 변환하는 기능들에 대해 공통 인터페이스를 제시하고, 이걸 '입력 도구'의 형태로 제공하기로 한 것이다.

한글을 글자 단위로 곧장 내보내지 않고 묶어서 내보내는 것은..

• 과거 도스용 아래아한글에서 잠시 제공하던 새김 단위로 한자 입력
• TSF를 지원하지 않는 프로그램에서도 단어 단위로 한글-한자 변환. 특히 매번 한자 키 안 누르고 곧장 변환하기
• 한글 발음으로 일본어나 중국어 입력 (당연히 단어· 문장 단위로 한꺼번에 변환)
• 스마트폰에서 볼 수 있듯이, 자주 사용되는 단어의 자동 완성

이렇게 잠재적인 활용 가능성이 매우 높다. 그냥 공통 인터페이스를 상속받아서 각 기능별로 후보를 제시하는 알고리즘만 달리하면 된다. 구현할 가치가 매우 높다고 판단되어 날개셋 한글 입력기의 구조를 전반적으로 다 뜯어고치고 확장하는 공사를 진행했다. 그리고 그만큼 보람을 느낀다.

'새나루' 입력기에는 날개셋 한글 입력기가 개발 방향의 컨셉· 차이로 인해 제공하지 않던 기능이 두 가지쯤 있었다. 하나는 드보락이나 콜맥 같은 임의의 영문 키보드 드라이버를 한글 IME(= 새나루 자신)와 연결하는 기능이다. 이건 내 프로그램도 지난 8.6 버전 때부터 드디어 도입됐다. 임의의 키보드 드라이버와 연계 가능하게 프로그램 구조가 싹 개선되면서 두 입력기 간의 차이가 없어졌다. 내 프로그램은 그에 덧붙여 키보드 드라이버의 동작을 보정하는 옵션까지 갖추고 있다.

그리고 다른 하나는 한자 변환 관련이다. 새나루는 한글, 영문처럼 '한자'라는 입력 모드가 있어서 (1) 매번 한자 키를 누르지 않아도 한자 후보가 한글과 함께 곧장 떠서 변환할 수 있었으며, '단어 단위 조합 생성'이라는 옵션이 있어서 (2) TSF가 지원되지 않는 환경에서도 2글자 이상의 단어 단위로 한자를 변환할 수 있었다. (1)과 (2)를 동시에 사용하면 타 한글 입력기를 쓸 때보다 한자 변환을 훨씬 더 빠르고 편하게 할 수 있기 때문에 한자 혼용론자 진영(!!)에서는 자기들끼리 새나루의 사용을 권장할 정도였다.

그에 반해 내 프로그램의 개발 이념에 비춰 보면, 단어 단위 한자 변환은 그냥 이미 있으니까 덤으로 제공하는 보조 기능에 가깝다. 한글을 단어 단위로 조합을 잡는 것은 고려 대상이 아니다. 딱히 개발자가 한글 전용 소신을 갖고 있어서 의도적으로 제공 안 하는 건 아니고, 그냥 개발 방향과 맞지 않기 때문에 지원하지 않았다. 세벌식 모아치기가 아니라 그런 기능이 필요하면 날개셋 대신 그냥 새나루 쓰라고 말이다.

그랬는데 먼 훗날, 결국 내 프로그램도 새나루에서만 제공되던 기능을 더 범용적인 형태로 수용하고 구현하게 됐다. (1)은 '조합과 후보 자동 완성' 입력 도구를 띄워서 후보 목록만 표시하게 설정하면 된다. 그리고 (2)는 '조합 안에 조합 생성' 입력 도구를 띄워서 단어 단위 한자 변환 기능을 설정하면 된다.
지금까지는 그런 변환 기능이 날개셋 한글 입력기 내부에서 어떤 위상과 계층을 차지해야 하는지 확신이 서지 않아서 구현하지 못했는데... 이제는 '입력 도구'라는 이론적 근간이 마련됐기 때문에 구현됐다.

한글 말고 영문의 경우도 T9 같은 모바일용 입력 방식에서는 단어 단위 조합이 필요하다. 한 글쇠에 여러 글자가 배당되어 있고 사용자가 multi-tap 없이 각 대표 글쇠만을 눌렀을 때, 사용자가 의도한 실제 단어가 무엇인지 유추하고 자동 완성 후보를 제시하려면 변환 엔진이 단어 전체를 살펴볼 수 있어야 할 테니 말이다.
이 '조합 안에 조합' 입력 도구는 '휴대전화 입력기' 내지 '조합과 후보 자동 완성' 입력 도구와도 연계해서 사용하기 좋다.

이렇게 보조 입력 도구의 내부에서 '조합 안에 조합'이 생성되고 있을 때는 문자 입력 기능에 기술적으로 다음과 같은 제약이 걸린다.

1. 빈 입력 스키마(호환 옵션 포함) 계열의 글자판을 사용할 수 없으며, '글쇠 누름' 계열의 날개셋문자로 문자를 입력할 수 없다. 그건 태생적으로 글쇠를 IME가 가로채지 않고 응용 프로그램 내부로 보내는 기능이기 때문에 '조합 안에 조합'을 생성하거나 건드릴 수 없다. 한글이야 애초부터 IME가 글쇠를 가로채지 않으면 입력할 수 없는 문자이기 때문에 별 문제될 게 없는 반면, 영문이나 숫자를 입력할 때 주의할 필요가 있다.

2. 이 상태로 또 글자 단위 후보 변환을 할 수 없다. '조합 안에 조합' 입력 도구를 사용하는 이유는 단어 전체를 한꺼번에 다른 문자열로 변환하기 위해서이다. 그러니 그 안에서 또 글자별 후보 변환을 하는 상황은 생각하지 않기로 한다. 외부 모듈이 원래 고유하게 갖고 있던 후보 변환 UI와, 조합 안의 조합이 요청할 수 있는 후보 변환 UI 사이의 충돌 등, 상황이 너무 복잡해지기 때문이다.
그때도 굳이 한자 변환을 하고 싶다면 '조합과 후보 자동 완성' 입력 도구를 미리 꺼내 놓고 사용하면 된다.

이런 제약은 날개셋 한글 입력기의 구현체가 전용 텍스트 에디터인 '편집기'밖에 없다면 굳이 존재하지 않을 제약이다. 하지만 외부 모듈과 입력 패드에서는 내가 가로채는 글쇠뿐만 아니라 응용 프로그램이 처리하는 글쇠도 고려해야 하고, 운영체제와 통신하는 부분도 고려해야 하기 때문에 그런 만능 범용성을 보장할 수 없다.

'조합 안에 조합'은 저렇게 제약과 불편한 점만 있는 게 아니며, 그 특성상 고유한 장점도 있다.
외부 모듈(대부분의 환경)이나 입력 패드는 편집기처럼 주변의 텍스트를 자유자재로 조작할 수 없기 때문에 조합이 끝난 글자를 낱자 단위로 지운다거나 다시 조합 상태로 돌아가는 것이 불가능하다.
하지만 '조합 안의 조합' 입력 도구는 자기가 자체적으로 텍스트를 갖고 있으니, 구현체를 불문하고 어떤 환경에서도 동일하게 텍스트를 자유롭게 조작하는 기능을 제공한다.

* 결론

이로써 날개셋 한글 입력기가 제공하는 입력 도구들은 오랫동안 4개만 있던 것이 10개로 크게 늘었다. 이들의 특성을 표로 정리하면 다음과 같다.

입력 도구의 동작은 다음과 같이 나뉜다.

• 자체 조합 입력: 입력 도구가 자신만의 고유한 문자 생성기를 갖추고 조합 문자열을 입력시킨다. 한손 내지 휴대전화 입력기가 이 범주에 속한다.
• 자체 입력: 굳이 문자 생성기의 조합 없이, 완성된 비조합 문자를 간단히 입력시킨다. 한자 부수 및 문자표가 이 범주에 속한다.
• 기존 입력 스키마: 현재 사용 중인 입력 스키마와 문자 생성기를 기준으로 날개셋문자를 보낸다. 화면 키보드가 이 범주에 속한다.
• 읽기전용: 현재 사용 중인 입력 항목의 상태를 표시만 할 뿐, 자기 자신은 아무런 입력 기능이 없다. 글쇠배열 이름 표시라든가 수식 계산 기록 같은 도구가 이 범주에 속한다.

입력 도구의 외형도 다음과 같이 다양하게 분류된다.

• 대화상자: 제목 표시줄을 갖추고 크기 조절도 되며, 리스트 박스, 콤보 박스 같은 사무적인(?) 컨트롤들이 나타나 있다. 클래식 데스크톱 UI에 가깝다.
• 창: 대화상자와 같은 형식을 갖추지 않고 큼직한 버튼 위주로만 구성돼 있다. Metro UI에 가깝다.
• 팝업: 평소에는 화면에 보이지 않다가 글쇠 같은 특정 이벤트가 발생했을 때에만 잠시 cursor 주변에 나타난다. 그리고 일정 시간이 흐르거나 조합이 종료되면 창이 도로 사라진다.

아울러 9.3 버전에서는..

• 대화상자형 입력 도구들 중에 도움말이 제공되는 것은 제목 표시줄의 오른쪽 끝에 [X]뿐만 아니라 [?] 버튼도 추가했다.
• 그리고 '입력 도구 선택' 대화상자의 목록에서 이미 켜 놓은 입력 도구는 앞에 *(별표)가 덧붙여져 있게 했다. 평소에 나타나 보이지 않는 '팝업형' 입력 도구도 존재한다는 것을 이를 통해 확인할 수 있다.

기타: ㄹ+한자 특수문자 변환 테이블의 오류 수정

ㄹ을 입력하고서 한자를 누르면 아시다시피 여러가지 단위 기호가 나타나는데, 넷째 후보로 Ｆ가 있던 것을 °로 변경했다. 이건 다음과 같은 여러 정황상 후보 변환 테이블의 오류로 추정되기 때문이다.

• 아마 화씨 온도 단위를 의도한 것 같으나, ℉는 뒤에 따로 또 있다.
• 단순 전각 F는 ㅍ+한자에도 이미 있기 때문에 중복 등재이다. 그 반면 °은 지금까지 KS X 1001 특수문자 중 유일하게 초성+한자 어디에도 배당되어 있지 않았다.
• 넷째 다음으로 다섯째와 여섯째에는 분, 초 ′ ″ (프라임, 더블 프라임)이 있기 때문에 도-분-초 순서가 자연스럽게 연결된다.
• °은 KS X 1001 2바이트 코드가 A1C6이다. Ｆ는 A3C6으로 서로 비슷하다면 비슷하기 때문에 혼동하기 쉬운 관계이다.

확인해 보니 Windows 95, 아니 3.1 이래로 MS 한글 IME는 줄곧 ㄹ+한자에 Ｆ가 있긴 했다. 참 유구한 전통이긴 하지만 오류가 명백하기에 날개셋은 Ｆ를 °로 변경하기로 결정을 내렸다.
저 오류는 본인이 최초로 찾아낸 게 아니라 역시 정 재민 님의 제보가 출처이다. 도대체 이런 걸 어떻게 발견해 내는지..

하긴, Windows 98 시절엔 ㄹ 자리에 유로화 기호가 추가되었으며, Vista 타이밍엔 ㅁ 자리에 우편번호 기호가 추가되기도 했으니, 이 변환 테이블이 20년째 완벽한 고정불변도 아니긴 했다.
참고로 유로화 기호(U+20AC)는 2바이트 코드로 역변환이 가능한 반면, 우편번호 기호(U+327E)는 그렇지 않다.

Posted by 사무엘

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

1. 들어가는 말

2017년 6월에 날개셋 한글 입력기 9.0이 나온 지 4개월 만에 9.1 버전이 나왔다. 추석을 낀 10월 황금 연휴 기간까지 보낸 뒤에 드디어 공개되었다. 오랜 마음의 부담을 덜었다.
이번 버전은 이전 버전들과 달리, 오로지 '보조 입력 도구'의 기능을 크게 강화하는 것에 초점이 맞춰졌다. 비록 readme가 분량이 이례적으로 매우 짧으며 사실 넣고 싶은 기능을 다 넣지도 못했지만, 이번에도 내부적으로 1500줄이 넘는 코드가 새로 추가되고 많은 변화가 있었다.

이미 있는 입력 도구에 기능이 추가된 것부터 소개하자면,
(1) 먼저, 지난 7월에 소개한 것처럼 "화면 키보드"에 일종의 live preview 옵션이 추가되었다. 현재의 문맥을 기준으로 수식을 계산했을 때 입력되는 문자를 실시간으로 바꿔서 표시해 주기 때문에 복벌식이나 신세벌식 같은 복잡한(?) 입력 방식을 사용할 때 큰 도움이 될 것이다.

(2) 그리고 5.3에서 첫 도입된 이래로 변화가 전혀 없었던 "한손 입력기"에도 아기자기한 변화가 생겼다.
화면 키보드처럼 3단계 크기 조절이 가능해졌으며, 초성과 종성의 배치가 대칭이라는 점을 착안하여 초성· 종성을 우-좌로 배치할지, 좌-우로 배치할지를 변경할 수 있게 했다. 세벌식이니까 존재할 수 있는 절묘한 customization이다.

또한, 중성의 경우, 천지인 방식뿐만 아니라 나랏글 방식도 고를 수 있게 했다. ㅡ 글쇠가 따로 없기 때문에 얘는 ㅣ를 두 번 눌러서 입력하면 된다.
한손 입력기는 애초에 나랏글처럼 '가획' 글쇠가 있어서 자음에서 쓰이고 있다. 그러니 모음도 나랏글 방식을 지원하지 말라는 법이 없다. 이런 옵션으로 인해 한손 입력기의 활용의 폭이 더 넓어지기를 기대해 본다.

2. 휴대전화 입력기

이번 9.1에서 추가된 가장 대표적인 기능은 바로 이 입력 도구이다. 얘는 3*4 방식의 키패드를 통해 다양한 입력 방식을 제공한다.
한글, 영문, 숫자, 기호 이렇게 총 4가지 모드가 있다. 그 중 한글은 현재 지정되어 있는 키보드 입력용 글자판(= 입력 항목) 중 하나에서 0~9와 * # 자리를 그대로 빌려 쓴다.
즉, '한손 입력기'처럼 독자적으로 제공하는 입력 기능이 없이 기술적으로는 '화면 키보드'의 부분집합처럼 동작한다. 처음에는 구동 당시에 사용 중이던 글자판을 기준으로 동작하지만, 글자판을 딴 걸로 변경하고 나서 우클릭 메뉴에서 '동기화'를 선택하면 기준으로 삼는 글자판을 바꿀 수 있다.

(1) 이 입력 도구는 기존 입력 설정을 빌려 와서 동작하는 대신, 한번 참조해서 불러들인 글자판은 사용자가 딴 걸로 변경하더라도, 심지어 날개셋 제어판을 통해 기존 입력 설정을 싹 갈아엎더라도 절대불변으로 계속 갖고 있는다. 이것이 '화면 키보드'와는 다른 점이다.
그렇기 때문에 한번 천지인이나 나랏글 같은 입력 방식으로 동기화시킨 뒤엔, 다시 PC 키보드용으로 쓰기 편한 두벌식이나 세벌식을 쓰다가 마우스로만 모바일용 입력 방식을 같이 쓸 수가 있다.

(2) 또한 비트맵 글꼴을 사용하는 '화면 키보드'와 달리, 이 입력 도구는 나름 크기 조절이 가능한 운영체제의 글꼴을 사용한다. 게다가 조합을 통해 생성되는 한글 자모들을 모두 한데 표시해 준다. 나랏글의 경우 ㅏㅓ, 첫지인의 경우 ㄱㅋㄲ 이런 것을 한 글쇠에다 크기 조절까지 알아서 해서 표시한다는 것이다.

다만, 글쇠에 비문자 특수글쇠나 가상 낱자가 들어있다면 이렇게 프로그램이 글쇠 문자를 자동으로 찾아 준 결과가 썩 정확하지 않을 것이다. 이럴 때는 이 글쇠는 무슨 역할을 한다고 사용자가 그냥 직접 지정을 할 수 있다. 나랏글의 가획/쌍자음 같은 글쇠는 500이니 501이니 이런 내부 숫자가 아니라, 저렇게 사람에게 실질적인 의미를 갖는 별칭을 표시하는 게 훨씬 낫기 때문이다.

이런 정보를 읽어들이기 위해서 '휴대전화 입력기'는 글쇠배열의 '설명문'을 사용한다. 그 텍스트에 XML 시그니처가 존재한다면 그 뒤에 나오는 XML을 해석해서 거기에 지정된 이름을 출력한다~!
미래에 궁극적으로는 설정 파일 내부에 임의의 메타데이터를 저장하는 계층을 더 그럴싸하게 강화할 것이지만, 일단은 이런 임시방편을 동원했다.

<?xml version="1.0"?>
<info>
    <key pos="#" name="SEP" flag="1"/>
</info>

날개셋 한글 입력기가 예제로 기본 제공하는 천지인· 나랏글· SKY 입력방식들은 모두 '휴대전화 입력기' 도구와 연계해서 잘 동작하게 저런 정보가 추가되었다. 지금까지 타자 시퀀스를 구하는 용도로나 사용되던 이 예제들에게 더 그럴싸한 활용 방법이 생긴 셈이다.
천지인의 경우, 사용되지 않는 * 자리에 문장부호를 다중타로 입력하는 사용자 정의 조합이 추가되었으며, # 자리에는 음절 구분자 글쇠가 배당됐다.

(3) '휴대전화 입력기' 도구는 한글 모드에서만 저렇게 기존 입력 설정을 빌려다 쓰며, 나머지 입력 모드에서는 다 자체적인 고정된 입력 기능을 제공한다.
영문은 '모비언스'라는 국내 기업에서 개발한 SmallQwerty 방식의 다중타 입력을 제공한다. 무식하게 ABC 순이 아니라 영문 글자 빈도수와 기존 쿼티 글자판을 적절히 고려하여 글쇠를 배당했는데, 생각보다 편한 걸 알 수 있을 것이다.
0번 키를 눌러서 대소문자를 바꾼 것은 한 글자에 대해서만 적용되고, 우클릭 메뉴에서 대소문자를 바꾼 것은 영구적으로 적용된다는 차이가 있다.

(4) 숫자 모드는 다른 복잡한 기능 없이 말 그대로 12키 키패드를 숫자 입력용으로만 사용한다.
그런데 여기에도 재미있는 바리에이션이 있다. 위에서부터 아래로 123 순으로 배열된 '전화기' 모드와, 그렇지 않고 역순으로 배열된 '계산기' 모드가 모두 제공되어서 사용자가 이를 선택할 수 있다. 전화기 모드에서는 기호도 말 그대로 *와 #가 있지만, 계산기 모드에서는 .와 ,가 배당된다.

(5) 끝으로, 기호 모드는 기술적으로 영문 모드와 별 다를 바 없는 다중타 방식 문자표이다.
backspace, space, enter는 모든 모드에 공통으로 존재하는 글쇠이다.
그리고 mode 버튼은 좌측 하단을 누르면 한/영이 전환되며, 우측 상단을 누르면 숫자/기호가 전환된다.
3*4 크기의 글쇠배열에서 단일타라는 범위 안에서는 내가 생각할 수 있는 가장 창의적인 기능들이 한데 깔끔하게 구현되었다. 단일타라 함은 여러 버튼을 동시에 누르거나 드래그 하는 것까지는 생각하지 않는다는 뜻이다.

3. 글쇠배열 이름 표시

그리고 이번에는 문자를 직접적으로 입력시키지는 않지만 문자 입력과 관련된 편의 기능을 제공하는 입력 도구가 하나 또 추가되었다.
'글쇠배열 이름 표시'는 메뉴에서 선택하더라도 당장 화면에 뭔가 튀어나오는 게 없다. 그 대신 사용자가 한/영이나 Shift+Space 같은 걸 눌러서 글쇠배열을 전환하면 새로 바뀐 글쇠배열의 이름이 cursor 근처에 풍선 도움말 형태로 나타난다. 짜잔~

풍선 도움말은 2.5초 정도 표시됐다가 사라진다. 한/영 상태뿐만 아니라 Caps/Num/Scroll lock을 눌러서 램프 상태가 바뀐 것도 풍선 도움말(툴팁) 형태로 표시해 준다.
그리고 툴팁이 사라진 지 5초가 경과한 상태라면, 날개셋 한글 입력기를 사용하는 텍스트 입력란이 포커스를 새로 얻었을 때에도 현재의 글쇠배열을 자동으로 잠시 표시해 준다. 반대로, 툴팁이 떠 있는 동안은 키보드 포커스가 다른 윈도우로 이동하더라도 툴팁 역시 cursor 근처를 자동으로 따라다닌다.

그리고 사용자가 텍스트의 입력을 시작하면 이 툴팁 역시 화면을 가리지 말자는 차원에서 곧장 사라진다. (응용 프로그램이 직통으로 담당하는 키 입력 말고, 날개셋 입력기로 접수되는 문자 입력 한정) 이런 여러 이벤트들을 세심하게 신경 썼다.

본인은 날개셋 입력기에 한/영 상태를 화면에 별도로 표시하는 기능이 있으면 좋겠다는 요청을 수 년 전부터 일부 사용자로부터 받은 적이 있었다. 그게 이런 형태로 드디어 실현되었다.
Windows 8 이상의 Metro UI에서는 입력 도구모음줄이란 게 없는 관계로 윈도우 포커스를 얻었을 때 현재 글자판의 대표 아이콘을 잠깐 표시해 주는 기능이 이미 있다. 그것과 기능이 약간 겹친다고 볼 수 있다.

물론, 이 기능은 한계도 있다.
날개셋 한글 입력기가 구동되자마자 자동으로 동작하는 게 아니며, 사용자가 이 입력 도구를 골라서 구동을 해 줘야만 동작한다. 내 프로그램은 자동으로 특정 입력 도구를 곧장 구동하는 기능은 아직 없다.
또한, 편집기가 아닌 외부 모듈에서는 응용 프로그램에 따라 cursor의 정확한 위치를 기술적으로 얻을 수가 없어서 화면 가장자리의 엉뚱한 위치에 툴팁이 뜨기도 한다. 이 점을 감안할 필요가 있다.

그래도 '글쇠배열 이름 표시' 기능은 날개셋 편집기의 상태 표시줄 내지 운영체제의 language bar를 응시할 필요를 상당수 줄여 주는 유용한 기능이 될 것이다. 다음 버전에서는(아마 9.3쯤) 이런 기발한 입력 도구들이 몇 개 더 추가되어서 사용자의 문자 입력에 시각적으로 큰 도움을 줄 것이다.

4. 제공 자료

(1) 예제로 제공되는 신세벌식 유형 파일을 '신세벌식 공동 개발안'이라는 이름으로 세벌식 커뮤니티에 공개된 최신 파일로 업데이트 했다. 이것이 20여 년 전 PC 통신 시절에 신세벌식 입력 방식을 처음으로 제안했고 지금까지 '신 광조'라는 이름만 알려져 있던 원 제작자분이 직접 고친 최신 입력 방식이라고 한다.

(2) 그리고 쿼티, 드보락, 콜맥에 이어서 영문 글쇠배열도 Carpalx라는 타자 행동 분석 프로그램으로 계산한 최적의 배열(배열 중 하나)이라는 QGMLWY 배열을 추가해 넣었다. 여러 바리에이션 중, ZXCV는 Ctrl 단축키를 의식해서 기존 Qwerty의 것을 그대로 유지시킨 거라고 한다. 제2군, 제3군에 이어 제4군까지 내려가면 얼마나 마이너해지려나 모르겠지만, PC용 영문 글쇠배열도 오늘날까지 연구가 완전히 중단된 게 아니라는 걸 알 수 있다.

(3) 내 프로그램의 도움말 디렉터리에는 버전 히스토리 리스트뿐만 아니라 '한글 자모 목록' 레퍼런스 txt 파일이 있다. 거기에 인터넷에서 긁어 온 '훈민정음 서문'과 '용비어천가' 텍스트를 예제로 또 추가해 넣었다. 이 분야에서 워낙 상징성이 뛰어난 텍스트이기도 하니, 방점이 가미된 그럴싸한 옛한글 예문이 필요할 때 간단히 불러와서 활용할 수 있을 것이다.

5. 그 밖에

입력 도구 외의 변화 사항들은 일일이 언급할 필요를 느끼지 못할 정도로 사소한 것들만 있다. 그나마 리드미 말고 블로그 글을 통해서라도 언급할 만한 것으로는..

(1) 날개셋 편집기의 화면 인쇄 퀄리티를 크게 개선했다. 작은 배율에서는 비트맵이 안티앨리어싱이 적용되어 부드럽게 찍힐 뿐만 아니라, '고대비 검정' 같은 검은 배경에서도 작은 글자의 뭉개지는 픽셀들이 다 사라지지 않고 정상적으로 표시된다. 어려울 것도 없고 비트맵을 찍는 옵션 하나만 살짝 바꿔 주면 됐는데 10년이 넘게 방법을 모르고 있었다.

(2) 그리고 고급 입력기의 사용자 정의 조합을 편집하는 화면에서.. 현재 존재하지 않는 새로운 상태로 가는 조합을 정의한 뒤 그걸 마우스로 더블 클릭하면, 자동으로 그 상태 번호를 등록하고 거기로 이동하게 해서 사용자 편의를 약간이나마 강화했다.

6. 끝으로.. 휴대전화(모바일)용 입력 방식에 대한 추가 잡설

(1) 사실, 휴대전화용 입력기라고 해 봐야 옛날에나 12키 layout에 매여 있었지, 지금은 꼭 그렇지도 않다. 스마트폰은 글쇠 레이아웃의 제약이 없으니 qwerty처럼 익숙한 PC용 키보드 그림을 띄워서 그걸 터치하는 방식으로 문자를 입력하기도 한다.
다만, 키보드와 완전히 같지는 않고 거기에서 규모를 약간만 줄이곤 한다. Google 단모음 입력기가 이런 틈새시장을 잘 공략한 입력 방식이긴 하다.
4단 숫자까지 사용하는 세벌식에게 이런 모바일 환경은 일면 악재로 보인다. 하지만 그런 곳에서는 신세벌식 같은 방식으로 글쇠 수를 줄인 입력 방식이 각광받고 있다.

그리고 사실은.. 모든 모바일 기기들이 다 qwerty 배열을 통째로 화면에 띄울 수 있을 정도로 화면이 크지는 않다.
교통에서도 동일 면적에 차들을 너무 많이 집어넣어서 밀집도가 지나치게 올라가면 차들이 서로 부딪칠까봐 조심하느라 빨리 달리지 못한다. 정체가 시작되며 단위 시간당 차량 소통량이 오히려 감소하게 된다.

그것처럼 작은 화면에 글쇠들이 정확하게 누르기도 힘들 정도로 너무 조밀하게 많이 있으면, 원하는 글쇠를 한 번에 누를 수 있어서 편리한 것보다 오타 때문에 불편한 게 더 커진다.
이런 이유로 인해 본인 역시 스마트폰에서 qwerty 기반 두벌식을 잠깐 써 보다가 불편해서 다시 3*4 나랏글로 갈아탔다. 적당한 버튼의 면적과 수에 대한 HCI 관점에서의 연구가 필요해 보인다.

아울러, 3*4 같은 고정적인 글쇠 패러다임도 완전히 없어질 수는 없는 게.. 시각 장애인이 있기 때문이다. 점자는 물리적인 요철로 구현해야 하니 터치스크린으로 절대로 구현할 수 없다. 요즘 같은 비주얼한 세상에도 라디오가 망하지 않고 있는 게, 수많은 영업용 자동차 운전자 때문인 것과 비슷한 이치라 하겠다.

(2) 지금까지 고안된 수많은 모바일용 한글 입력 방식 중에는 한 글쇠에 자음과 모음이 중첩 배당된 게 있다. 신세벌식에서는 그나마 중성과 종성 중첩이라지만, 저런 입력 방식에서는 두벌식이기 때문에 한 글쇠가 문맥에 따라 초중종성 역할을 모두 담당하게 된다.

가령, 김 민겸 님(☞ 홈페이지)이 고안하신 입력 방식은 '으'에다가 ㅡ를 덧붙여서 ㅎ이 되는 동작이 있다..! 이건 워낙 특이한 동작이기 때문에 날개셋에서도 거의 7.x대 버전에서 0으로 만드는 특수 낱자까지 도입한 뒤에야 겨우 구현 가능해졌다. 그래도 복잡한 전용 특수 오토마타가 필요하며, 이렇게 너무 변칙적인 입력 로직은 내 프로그램에서 입력 순서 계산 같은 자동화도 제대로 못 해 준다.

그리고 웹사이트의 설명을 아무리 읽어 봐도.. 자음과 모음이 그렇게 중첩돼 버리면 음절 경계 구분은 어떻게 하는지, 초성은 그렇게 입력한다 쳐도 종성에서 '으으'와 '읗' 같은 건 어떻게 구분하는지, 뭔가 보편적인 규칙이 떠오르질 않았다. 내부 로직이 어떻게 돼 있는지 리서치를 할 시간이 없어서 본인은 그런 입력 방식들은 예제로 제공하지 못하고 있다.

사실, 모비언스에서도 영문뿐만 아니라 한글 입력 방식을 제안한 것이 있는데 거기서도 자음과 모음 중첩이 존재한다. 이 역시 비슷한 이유로 구현하지 못하고 내 프로그램에서는 영문 입력 방식만 얹었다.

Posted by 사무엘

날개셋 프로그램의 개발 패턴은 십중팔구 입력기와 타자연습이 같이 버전이 올라가거나, 입력기만 바뀌는 형태였다. 본인에게는 아무래도 입력기가 비중이 더 높은 프로젝트이니 말이다.

하지만 오늘은 좀 이례적인 소식을 전하고자 한다. 입력기는 변화 없이 타자연습만 먼저 다음 버전이 완성· 공개되었다. 입력기 다음 버전(9.1)의 개발 일정은 많이 지연된 반면, 타자연습은 이미 2개월 가까이 전에 작업이 완료된 게임 관련 개선 말고는 추가 작업의 여지가 거의 없는 상태이기 때문이다. 둘의 릴리스 날짜를 동일하게 맞출 수 없게 됐다.

타자연습의 변화 사항은 저게 전부이다. 게임에서 방어력 업그레이드가 각 주인공별로 성능이 다른 장갑(armor)으로 바뀌었으며, 큰 글꼴 모드에서 1024*768 전체 화면이 정확한 해상도로 진입하지 않던 문제를 해결했다. 다른 변화 사항은 없으니, 게임을 하지 않는 분이라면 굳이 새 버전을 구할 필요가 없다.

새 버전은 3.7에 비해 절대적인 작업 분량이 많다고 보기 어렵다. 그러나 굉장히 오랫동안 동일하게 유지되었던 게임 시스템의 일부가 크게 바뀌었다는 상징성을 감안하여 3.7에서 0.01 대신 0.1을 올린 3.8로 버전을 정했다. 입력기와 타자연습이 나란히 0.1씩 올라가서 동시에 공개됐으면 참 좋았겠다만..
이제 게임을 하다가 armor를 지급받고 나면 HP 게이지 밑에 노란색의 armor 게이지도 추가로 생기는 것을 확인해 보시기 바란다.

올해도 벌써 8월이 다 지나고 아침과 저녁 날씨는 반쯤 가을처럼 돼 간다. 이랬는데 정작 9~10월엔 '늦더위 기승' 이러지나 않았으면 좋겠다.
지난 상반기 때는 여러가지 이룬 일들이 많아서 개인적으로 행복했다. 복합 낱자 입력 로직 생성기를 다 완성하고 예정에 없던 24픽셀 큰 글꼴 지원을 구현해서 입력기가 깔끔하게 9.0대에 진입했다. 거기에다 타자연습도 게임 시스템 개편을 이렇게 이뤘다.

하지만 이번 여름방학 기간은 2개월 간격으로 입력기 8.9와 9.0을 나란히 만들어 냈던 저 때와 달리, 솔까말 좀 슬럼프에 빠져서 생산성이 크게 떨어진 채로 보냈다.
뭐 핑곗거리를 만들자면 끝도 없겠지만, 무더위, 뒤숭숭한 나라 사정, 그리고 '자신감과 확신(confidence) 결핍'으로 인한 의욕 감퇴 때문에 유난히 방황했다.

외부적으로는 "이 와중에 이런 마이너한 프로그램 계속 만들어 봤자 니 신세가 펴지는 거 있나" 같은 무력감,
그리고 내부적으로는 지금 이 디자인이 정말 이보다 더 나을 수 없는 진짜 최적이 맞나.. 이런 고민이 본인을 압박했다. 일이 손에 잡히질 않았다. 9.0까지 실컷 잘 만들어 놓고는 갑자기 내가 왜 이러나 나 자신조차 알 수 없었다.

그러다가 여름 동안 컨디션 전환을 위해 여기저기 여행을 다니고, 특히 광복절 연휴 타이밍 때 강원도도 과감하게 다녀온 뒤에야 조금씩 컨디션이 회복됐다. 최적이 맞는지, 이대로 개발하면 되겠는지 승인과 결재를 기다리고 있던 머릿속 여러 밀린 proposal들이 드디어 처리됐다. 요 기능은 마침 저 아이디어와도 연계가 된다는 식으로 답이 딱딱 나왔다.

2017년 상반기에 저런 것들을 이뤘다면, 하반기의 키워드는 '입력 도구'이다. '화면 키보드, 부수로 한자 입력'처럼 마우스로 조작하는 보조 UI들 말이다. 이것들도 5.x 시절에 완성되고 나서 수 년 동안 변화가 거의 없었다.
제5의 '빠른설정'이 '복합 낱자 입력 로직 생성기'였다면, 제5의 '입력 도구'는 '휴대전화 입력기'가 될 것다. 이미 있는 화면 키보드와 기능이 일부 겹치기도 하지만 한편으로 자체적인 입력 방식과 독창적인 기능 구조를 갖췄다.

이것뿐만 아니라 입력에 도움을 주는 도구들을 몇 개 더 추가한 뒤, 현재 계획으로는 10월쯤에 입력기 9.1을 내놓을 계획이다. 원래는 이걸 지금 무렵까지 끝내고 싶었지만 그건 물 건너갔으니..
9.1 다음으로 대단원을 장식할 마지막 추가 기능이 무엇인지는 이미 여러 번 말한 적이 있었고, 또 떠벌리는 건 입만 아플 테니 이 자리에서는 언급을 생략하겠다.

요즘은 어지간한 프로그램들은.. 심지어 복잡한 게임조차도 번거롭게 받아서 하드에 설치할 필요 없이 웹페이지에서 바로 구동하는 게 대세가 됐다.
자체 폰트를 사용하는 편집기라든가 타자연습, 타자 게임은 자바스크립트로 돌릴 수 있을 것이다. 하지만 운영체제용 IME는 그 특성상 여전히 철저히 local 환경에서 네이티브 코드 기반으로 돌아가는 영역으로 남지 싶다. Windows 운영체제 자체가 싹 다 뒤집어 엎어지지 않는 한 말이다.

이렇게 눈에 보이는 새 기능 말고, 내부의 리팩터링 쪽도 욕심이 생기는 게 있다. 본인이 지금까지 다음과 같은 사항들 얘기를 한 적은 없었지 싶다.

(1) 현재 내 프로그램 내부에서는 입력 스키마가 문자 생성기를 포함하는 형태로 구현돼 있다. 그래서 제어판에서 한 입력 항목의 '입력 스키마'를 딴 걸로 바꾸면 입력 스키마뿐만 아니라 문자 생성기도 같이 바뀌기도 한다.
하지만 지금 프로그램을 다시 만든다면 두 계층을 명백하게 분리해서 입력 스키마와 문자 생성기를 한데 묶은 '입력 항목'이라는 계층 더 명확히 할 것이다. 심지어 한 입력 항목에 입력 스키마와 문자 생성기 말고 다른 개체가 붙을 수도 있게 말이다. 이건 유니코드에 한글 자모가 더 추가되고 날개셋 설정 저장 파일 포맷이 2008년 이래로 또 바뀌는 정도의 대격변이 불가피해진 먼 미래에나 화폐 개혁하듯이 추진할 것이다.

(2) 문자 생성기는 오토마타나 낱자 결합 테이블 같은 입력 설정 '데이터'와, 스택이나 조합 상태 같은 '내부 상태' 정보 계층을 완전히 분리할 것이다.
날개셋 한글 입력기를 설계할 때 처음부터 이 정도 추상화 수준을 생각하지 못한 게 아쉬움으로 남는다. 이 역시 (1) 만만찮게 거의 2020년대 이후에 버전 10.0대의 초장기 과제로나 실현 가능할 듯하다.

이런 썰들을 길고 두서없이 남기며 타자연습 새 버전을 조촐히 기념하고자 한다. 어서 입력기도 다음 버전이 완성되기를..

Posted by 사무엘

날개셋 한글 입력기 9.0과 타자연습 3.7이 나온 지 한 달 정도가 돼 간다.
다음 버전은 입력기 9.1과 타자연습 3.71 또는 3.8이 될 듯하다. 현재는 입력기보다 타자연습의 작업이 더 많이 진행되었으며, 타자연습의 다음 버전은 다른 변화는 없이 "게임 업그레이드"가 될 가능성이 높아져 있다. 그 구체적인 내역은 다음과 같다.

1. 타자 게임의 체력· 방어력 시스템 개편

본인은 컴퓨터 소프트웨어의 여러 분야들 중 게임은 하는 것과 만드는 것 모두 별 소질이나 인연이 없다. 하지만 그럼에도 불구하고 나름 게임 개발자 겸 기획자의 코스프레라도 한 경험을 말하자면 날개셋 타자연습의 게임을 설계· 개발한 이력을 내세우겠다.

날개셋 타자연습의 게임을 구성하는 현재와 같은 12개 레벨과 이들의 난이도· 컨셉, 그리고 엔딩까지 대략 20분에 달하는 플레이 컨텐츠는 지금 생각해도 충분히 잘 만들어졌다고 생각된다. 더 고칠 필요가 없다. 특별히 4단 자리(맨윗자리)와 겹받침 글쇠를 집중 공략하는 레벨 9~11의 지옥훈련은 정말 세벌식 전용 타자연습이니까 볼 수 있는 특징이다.
오타 페널티가 있는 놈(한별. 잠시 동안 타자를 할 수 없음), 그와는 정반대로 정확도가 100%가 아니어도 단어가 인식되는 놈으로(미르) 주인공을 차별화한 것도 마음에 든다.

하지만 게임의 모든 시스템이 만족스러운 건 아니다. 각 레벨별로 더 다양한 색상의 배경을 넣었어야 했는데 레벨 3~5는 그 당시 뭔 생각을 하고 배경을 디자인 했는지, 하늘과 땅 컨셉을 너무 많이 우려먹어 있다.
그리고 배경에도 애니메이션이 좀 있어야 하는데 그걸 구현하지 못했다. 가령, 레벨 2는 별들이 반짝이거나 '우주 여행' 화면 보호기처럼 쓱쓱 입체적으로 날아다니는 게 원래의 내 의도였다. 텍스처 비트맵 배경은 텍스처가 조금씩 스크롤되고, 다른 그러데이션 무늬 기반 배경은 허접한 팔레트 스크롤 같은 거라도 넣어서 움직이게 말이다.

그래픽 다음으로 음악은? 레벨별로 분위기를 고려해서 지금과 같은 여섯 곡을 오랫동안 고민한 끝에 선정했으며, 이 역시 큰 틀에서는 후회가 없다. 명곡이긴 하지만 다들 유행 지난 1990년대의 너무 오래된 곡인 게 문제일 뿐..
딴 걸로 교체하려 해도 mp3 음원이 대세가 된 요즘 세상에 미디 파일을 구하기란 몹시 힘들 듯하다.

그래픽이나 사운드 같은 외형적인 요소 말고 게임 메카닉 알고리즘 차원에서 내가 제일 문제 의식을 느끼고 우선적으로 고치고 싶었던 건 주인공의 HP와 방어력 시스템이다. 의도는 "오타에 취약해서 다루기 힘든 주인공에게 그에 상응하는 맷집을 더 줘서 어려운 레벨에서 더 오래 버틸 수 있게 한다."이긴 하지만, 체력(HP) 시스템이 주인공별로 쓸데없이 너무 복잡하게 만들어졌다는 게 오랜 세월 동안 느껴졌다.

타자 게임을 처음 만들던 당시에는 스타크래프트의 방어력 업글 시스템에서 착안하여 지금과 같은 5단계 업글을 도입했었다. 게임을 첫 레벨에서부터 차근차근 시작하면 대략 레벨 8 무렵부터 방어력이 5단계로 풀업 되는 식이었다.
그러나 앞으로는 요 시스템을 갈아엎고, Doom/Quake의 시스템에서 착안한 armor(장갑/갑옷) 기반 방어력 시스템을 도입할 것이다.

세 주인공은 초기 체력과 최대 축적 가능 체력이 100으로 모두 동일하게 맞춰진다. 그리고 없애지 못한 단어로 인해 입는 대미지 역시 기본적으로 동일하며, 체력 회복 바이러스를 맞았을 때 늘어나는 체력의 양도 동일하다.
현재 아름은 시간이 흐르면 100까지 체력을 서서히 자동 회복하며, 한별은 레벨을 클리어 했을 때 체력이 50 미만이면 일부를 보상하는 기능이 있다. 한편, 미르는 점수가 일정 간격에 도달했을 때 체력을 보상하는 기능이 있다. 이런 보상 시스템은 괜히 복잡하고 게임에서 실질적으로 별 도움이 안 되어 보이는 관계로, 모두 폐지할 예정이다.

그럼 세 주인공이 차이가 나는 부분이 무엇이냐 하면 딱 하나, armor point가 있을 때의 작용 효과이다.
예전에 '방어력 n단계 업그레이드'라는 효과를 내던 바이러스는 'armor 보충'으로 바뀌며, 이때 armor는 언제나 100으로 '만땅' 상태가 된다.

armor가 있는 상태에서 대미지를 입으면 한별의 경우, armor는 (1) 현재 남아 있는 armor 양과 (2) 전체 대미지의 1/3 둘 중 최소값만치 깎인다. armor가 음수가 될 수는 없으니까.. armor는 자기가 깎이는 양의 3배에 달하는 대미지를 커버하고, 그 과정에서 체력은 그 전체 대미지의 40% 남짓만치만 감소하게 한다. 즉, 체력 대미지(5/12)와 armor 대미지(1/3)를 합해도 3/4이니, 전체 합이 원래 대미지보다 더 작다. armor가 몸빵에 굉장히 큰 기여를 하는 셈이다.

특성이 세 주인공의 중간에 속하는 아름은 armor와 체력이 그냥 정확하게 반반씩 깎이니 armor는 그야말로 추가적인 보조 체력 그 이상도 이하도 아니다.
미르는 타자 편의가 가장 뛰어난 대신 armor의 운용 효율이 가장 떨어진다. armor를 먹어도 체력 방호 효과는 1/3 남짓에 불과하고, 체력 대미지와 armor 대미지를 합하면 1보다 크다. 오랜 고민 끝에 이런 식으로 시스템을 개편하기로 잠정 결론을 내렸다.

그러므로 이제부터 날개셋 타자 게임에서는 방어력 업그레이드 단계 같은 건 존재하지 않는다. 그 대신 게임을 하면서 hit(health) point뿐만 아니라 armor point도 마치 스타에서 미네랄과 가스처럼 이중으로 신경 쓰게 된다. 가스가 없으면 고급 유닛을 만들 수 없듯, 체력이 아무리 많아도 armor가 없으면 피격 때 체력을 훨씬 더 빠르게 급격히 잃게 된다. armor의 양은 체력 막대 밑에 노란식으로 표시된다.

어떤 주인공이든 대미지를 입었을 때 armor의 감소량은 체력보다 더 적으면 적지 많지는 않다. 하지만 armor 보충 바이러스는 체력 보충 바이러스보다 등장 빈도가 낮다. 그리고 armor가 아무리 많이 남아 있어도 체력이 0이 돼 버리면 말짱 도루묵이고 게임 오버이니, 죽기 직전에 당장 더 중요한 것은 armor보다는 체력이다. 이렇게 게임의 양상이 이전보다 다채롭게 변할 것이다. 이 관계를 표로 정리하면 다음과 같다.

이전에는 주인공이 최고의 맷집과 방어력을 갖추려면 체력도 150이니 120이니 하는 최대치로 축적해 놓고 방어력 업그레이드도 여러 레벨들을 거치면서 5단계까지 해 놔야 했다. 하지만 새로운 시스템에서는 원래 체력 상태에서 'armor 보충' 바이러스 한 번만 받으면 이론적인 최대의 맷집과 방어력 상태가 갖춰진다. 아주 단순해진다.

물론 축적 가능한 체력의 절대적인 양은 예전 시스템 때에 비해 감소했다. 그 대신, 체력 회복 및 armor 보충 바이러스가 이전보다 약간 더 자주 등장하고, 회복시켜 주는 양도 이전보다 더 많다. 체력 회복은 세 주인공 공통으로 50으로, 전체의 절반을 그냥 준다. 축적에 의존하지 말고 그때 그때 바이러스에 의한 보급 뽀록에 의존하는 가중치가 더 커진다.
이렇게 시스템을 개편해 놓고 내가 몇 판 게임을 해 보니 끝탄을 깨거나 못 깨고 죽는 빈도는 그럭저럭 별 차이 없는 것 같다.

안 그래도 타자 게임은 또 건드리기가 민망한 굉장한 레거시 코드가 돼 있다. 내 게임이 사용한 DirectDraw, DirectMusic 이런 라이브러리도 완전 한물 간 레거시 기술들인 거 본인도 잘 안다. =_=;;
하지만 지난번 날개셋 한글 입력기 9.0에서 24픽셀 비트맵 작업을 하는 과정에서 먼지 쌓였던 타자 게임 쪽 코드를 오랜만에 건드리게 되었는데, 여기에서 동기와 자극을 받아 오랜 숙제로 남아 있던 체력· 방어력 시스템 개편을 해치웠다. 이건 그래픽· 사운드와는 무관하게 0순위로 꼭 갈아엎고 싶었기 때문이다.

2. 그 외의 게임의 변경· 개선 사항

(1) 150% (144dpi) 이상 배율에서 게임이 1024*768 해상도의 "전체 화면"에서 실행됐을 때, 화면이 정확하게 모니터 전체에 꽉 차지 않고 어중간하게 부분적으로만 차던 문제를 해결했다. 원인을 한참을 찾아 보니, 운영체제가 전체 화면 해상도까지 쓸데없이 high-DPI scaling을 해서 그런 것이었다. 그래서 제멋대로 1024*768보다 약간 높은 해상도로 바꿔서 전체 화면을 들어갔었다.

기존 3.7의 경우, EXE 파일에 대한 속성 열어서 호환성 탭 - "높은 DPI 설정에서 디스플레이 배율을 사용하지 않음" 옵션을 수동으로 켜 주면 문제가 해결되고, 다음 버전에서는 이게 exe 차원에서 자체적으로 적용되게 했다.
저 옵션 자체는 high-DPI scaling이 존재하지 않는 구닥다리 Windows 7에도 있던데, 이전 OS에서는 무슨 기능을 했는지 궁금하다.

(2) 이 기회에 비트맵 글꼴 말고 게임에서 출력되는 다른 한글 문장들의 글꼴을 너무 식상한 굴림 대신 '맑은 고딕'으로 바꿨다. 이런 것도 노력 대비 프로그램의 낡은 이미지의 쇄신에 기여하는 바가 크다.
다만, 맑은 고딕은 잘 알다시피 같은 크기라 해도 상대적인 크기, 줄 간격이라든가 종횡비 같은 글꼴의 기본적인 metric이 굴림· 바탕류와는 완전히 다르다. 그래서 불러들이는 글꼴 이름만 달랑 바꾼다고 되는 게 아니고 전반적인 문자 배치 방식도 다같이 보정하고 바꿔 줘야 했다.

3. 화면 키보드의 live preview

날개셋 한글 입력기가 제공하는 보조 입력 도구 중에는 '화면 키보드'가 있다.
얘는 단순히 현재 선택돼 있는 입력 항목의 글쇠배열을 static하게 보여주는 기능만 있다가, 2년쯤 전에는 실제로 눌러지거나 떼어진 글쇠를 시각적으로 highlight해 주는 옵션이 추가되었다. 그 뒤로는 큰 변화가 없이 오늘날에 이르렀다.

그러다가 이번에는 '실제 입력 문자 표시'라는 꽤 재미있는 옵션이 우클릭 메뉴에 추가되었다. 얘는 글쇠의 입력이 끝날 때마다 글쇠배열들의 수식을 현재 변수값을 기준으로 재계산한다. 그래서 지금 이 글쇠를 눌렀을 때 실제로 입력되는 문자가 화면에 정확하게 표시되게 한다.

두벌식을 사용하고 있었다면 중성을 입력하는 순간부터 자음들 모양이 초성에서 종성으로 바뀌며, 조합이 종료되거나 초성을 입력하기 시작했을 때 다시 초성으로 돌아온다. 세벌식 390의 경우 / 자리는 ㅗ를 입력 가능한 문맥에서는 ㅗ가 됐다가 다시 /로 돌아온다.

복벌식이나 신세벌식처럼 상황에 따라 여러 글쇠들의 의미가 완전히 달라지는 입력 방식을 쓰고 있을 때는 이 옵션을 켜고 화면 키보드를 사용하는 게 굉장히 큰 도움이 될 것이다. 처음인 왼손과 오른손에 세벌식과 두벌식의 자음이 모두 표시되어 있지만, 두벌이나 세벌로 타자가 시작되면 모든 글쇠배열이 두벌이나 세벌 기준으로 싹 바뀌며, 조합이 종료되면 배열이 다시 초기 상태로 돌아오기 때문이다!
본인은 이런 기능의 필요성을 이미 수 년 전부터 느끼고 있었지만, 보조 입력 도구 쪽 기능을 강화하기 시작한 이번 버전에서야 이 기능을 구현해 넣을 수 있었다.

입력기는 현재 이 아이템 하나만 작업이 됐다. 예전의 8.8 버전에서는 '빠른설정'이 하나 더 추가됐는데 다음 9.1에서는 새로운 '입력 도구'들이 여러 개 더 추가될 것이다.
보조 입력 도구는 먼 옛날 5.3~5.5x 버전 시기에 화면 키보드, 한손 입력기, 문자표, 부수 한자 입력 이렇게 4개가 추가된 이래로 지금까지 아무 변화가 없었다. 지금까지의 통상적인 기능 추가와는 성격이 다른 분야에 모처럼 사용자의 입력에 시각적인 피드백과 각종 편의를 제공하는 기능들이 잔뜩 도입될 것이다.

Posted by 사무엘

1.
바로 며칠 전에 날개셋 한글 입력기 9.0과 함께 공개된 타자연습 3.7의 경우, 명목상 변화 사항은 (1) 프로그램 명칭 표기의 변경과 (2) 144dpi 24픽셀 글꼴 지원이었다. 프로그램 UI가 전반적으로 적절하게 150% 확대될 뿐만 아니라 이때는 게임도 잘 알다시피 640*480이 아닌 1024*768 해상도에서 실행되게 했다.

이것 말고 프로그램 기능의 변화는 전무하다. 그러니 타자연습 3.7은 입력기에 적용된 변화를 그대로 같이 수용한 것만이 전부가 될 것이라 여겨졌다.
그러나 작업을 마친 후 타자연습을 테스트를 해 보니, 굳이 직전 버전에만 국한되지 않는 여러 잡다한 문제들이 보였다. 그래서 6월 13일 정식 공개 후에도 불가피하게 프로그램을 몇 차례 고쳐서 재업로드를 해야 했다. DirectDraw 구동하는 낡아빠진 코드를 도대체 얼마 만에 재복습을 한 건지 원...;;

과거 Windows 7 이하 시절에는 안 이랬던 것 같은데, Windows 10 기반의 4K~5K 대형 모니터 컴에서 타자 게임을 전체 화면에서 돌려 본 결과, (1) 점수와 HP가 출력되는 화면 아랫부분이 의도했던 흰색이 아니라 그냥 시꺼멓게 칠해지는 문제가 있었다. 창 모드에서는 이상 없음.
이 문제는 뭐 텍스트를 찍고 색칠을 하는 방법을 바꿔서 해결했다.

그리고 이건 좀 심각한 문제인데, (2) 전체 화면으로 게임 진행 중에 Alt+Tab, win 등으로 프로그램 창을 빠져나갔다가 돌아오는 과정에서 가끔 오류가 발생했다. 소실했던 surface를 복원하는 과정에서 문제가 있었던 것 같다. Windows 7 이하에서는 가끔 배경 화면이 다시 그려지지 않던 것이 Windows 10부터는 그냥 씨크하게 곧장 오류와 crash로 이어졌다.
이 문제도 단순 실수로 추정되는 코드 몇 줄을 정리하고 나니 바로 해결되었다.

끝으로, 미처 생각하지 못했던 괴이한 문제가 하나 더 있었다.
기존의 640*480 해상도는 어느 모니터에서나 그럭저럭 화면이 꽉 찬 형태로 실행되었으며, 요즘 같은 와이드 화면에서는 좌우에만 모니터 차원에서 사용되지 않는 검은 사각형 영역이 생겼다.
그러나 1024*768은 그렇지 않더라. SetDisplayMode로 분명히 1024*768을 지정했음에도 불구하고 실제로 비디오 카드 차원에서는 (3) 1280*960 정도로 추정되는 더 큰 화면이 설정된다. 그리고 게임 화면의 오른쪽과 아래에 흰 여백이 불필요하게 생기는 것이었다.

단순히 제어판의 디스플레이 설정에서 1024*768로 맞췄을 때는 이렇지 않고 화면이 꽉 찬 채로 저해상도로 바뀐다. 그런데 DirectDraw를 통해 1024*768로 맞추면 왜 저렇게 되는지, 다른 구형 게임들도 다 저런지 잘 모르겠다.
예전엔 이런 현상을 본 적이 없었는데 최신 운영체제에서 새로 발생하는 문제인 것 같다. 위의 세 이슈 중 (3)만은 이렇다 할 원인과 해결책을 파악하지 못했다.

이런 뜻하지 않은 문제 때문에 타자연습의 작업량이 예상보다 더 많아졌다.
그 밖에 혹시 타자연습을 오래 많이 써 보신 분은 경험적으로 이미 아실지도 모르겠는데..
오타를 낸 뒤 그 뒤의 한글을 조합하다가 그대로 home, ctrl+왼쪽 화살표 등으로 cursor를 급격하게 앞으로 옮기면 앞, 또는 조합 중이던 글자에 대한 오타 처리가 일시적으로 제대로 되지 않는 경우가 있다. 이 문제도 이 기회에 같이 해결했다. 이래저래 한글 입력기뿐만 아니라 타자연습도 나름 의미심장한 버전업을 달성했다.

2.
아래 그림은 날개셋 한글 입력기가 제공하는 옵션들을 모두 사용했을 때 backspace 글쇠가 동작하는 방식을 순서도로 나타낸 것이다. 로직을 이런 식으로 그림으로 표현할 생각을 지금까지 안 하고 지냈는데, 한번 그려 보니 굉장히 그럴싸해 보인다.

요즘이야 순서도는 "코끼리를 냉장고에 넣는 법", "정신승리법"처럼 뭔가 병맛스러운 절차를 기술할 때에나 개그 목적으로 참 안습하게 쓰이는 경우가 많다만.. 이것도 나름 20세기 중반쯤에 국제 표준 규격이 제정되어서 전세계에서 동일하게 통용되는 물건이다. 대표적으로 둥근 사각형은 단말(시작과 끝), 직사각형은 처리, 마름모는 분기.. 이런 식으로 말이다.

재래식 순서도는 한눈에 봐도 참으로 GWBASIC의 GOTO스럽게 생겼다. 그래서 NS 흐름도라고 스파게티 코드 분기를 지양하고, 열고 닫고 갔다가 되돌아오는 거.. 코드로 치면 들여쓰기를 그대로 시각화해서 구조화 프로그래밍의 논리 순서를 더 깔끔하게 그릴 수 있게 한 물건도 있다.

그래도 어느 것이든 튜링 기계로서 계산 능력은 서로 동등하다. 종료 조건이 실행 중에 결정되는 분기가 가능하고, 포인터(메모리 어느 값을 읽고 쓸지를 또 메모리로부터 읽어서 결정할 수 있는..)를 구현할 수 있다면 말이다.

3.
맥용으로 날개셋 한글 입력기가 최소한의 핵심 엔진 엑기스만 포팅해서 만들어진다면..
보조 입력 도구나 방대한 제어판 GUI, 비트맵 글꼴 기반 텍스트 에디터 같은 건 몽땅 제낀다.
시스템 계층과 편집기 계층도 빼고 ist 파일을 불러들여서 '한 입력 항목'의 입력기 계층만 제공하는 간단한 macOS용 한글 IME부터 시작하게 되지 싶다. 범위를 이렇게까지 좁혀도 Windows에 특화돼 있는 미세한 키보드 조작 제어라든가 타이머 같은 건 어떻게 구현할지 아직까지는 답을 모르겠다.

게다가 Windows와 맥(그리고 어쩌면 타 OS도)은 가상 키코드 체계도 서로 완전히 다르다. 기본 입력 스키마의 글쇠배열이야 가상 키코드에 구애받지 않는 절대적인 문자 글쇠만을 인식하니까 상관없지만, 추가적인 글쇠 인식 옵션이나 고급 스키마는 가상 키코드를 직통으로 사용하기 때문에 이런 것들을 어떻게 보정할지 생각을 해야 한다. 장기적으로는 입력 설정 파일의 메타데이터 내지 헤더에 이 가상 키코드의 문맥 정보도 들어가야 할 것으로 보인다.

4.
예전에도 몇 차례 글로 밝힌 적 있지만, 본인은 이 바닥을 판 지 15년이 훌쩍 넘었으며 이 바닥 사정을 그럭저럭 잘 안다.
한글에 대해서, 한국어에 대해서 그리 많은 걸 바라지는 않는다. 비현실적인 환상은 조금씩 내려놓기 시작했다.
미군 철수와 대남적화를 걱정하게 생긴 와중에 한글이 감히 무슨 세계 언어를 받아 적는 문자로 등극하는 걸 바라지는 않는다. 넘사벽급의 돈줄과 연구 인프라, 학술용어와 정보 데이터를 갖추고 있는 국제어 영어의 지위와 인지도를 타 언어가 흔들 수 있을 거라고 생각하지는 않는다.

심지어 미국이 경제· 군사적으로 몰락한다 해도 영어만은 아마 몰락할 일이 없지 싶다. 정작 언어학자· 전공자 전문가들은 민감한 사항이라면서(문화 상대주의? 언어 제국주의?) 이런 언급을 금기시하고 꺼리긴 한다만, 내 개인적으로 생각하기에는 라틴 알파벳과 영어는 여타 언어들에 비해 구조적으로 더 기계 친화적이고, 덜 지저분하고 경쟁력 있고 더 우수한 구석이 있다고 본다.

기왕 우리는 영어를 외국어로서 힘들게 학습해야 하는 처지로 태어났고, 국제어 영어와는 구조가 너무나 다른 군소언어를 쓰는 문화권을 갖게 돼 버렸는데 그럼 이 상태에서 우리가 할 수 있는 게 무엇일까? 결국 어설프게 남을 따라가고 뒤쫓는 연구만 해서는 절대 남을 앞설 수 없다. 안 그래도 시작점도 다르고 투입되는 자금의 규모도 쨉이 안 되는데 무슨 승산을 바라는가? 결국 남과는 완전히 다르고 이 처지에서 우리만이 할 수 있는 솔루션을 만들고 개척해야 한다.

우리는 알파벳처럼 쭈욱 글자를 있는 대로 늘어놓기만 하는 풀어쓰기 문자가 아니라, 어쩌다 보니 낱자 구분과 음절 경계 구분이 있고 모아쓰기를 하는 한글 같은 문자를 쓰게 됐다. 그리고는 그런 특성이 있으니 한글이 참 우수하다고 자랑을 늘어놓는다.

그러면 단순히 모아쓰기를 기계적으로 구현해 주는 한글 오토마타만 만들어 넣는 것으로는 충분치 않다. 그런 경계 구분 계층이 있고 IME라는 소프트웨어가 필요한 걸 괜히 거추장스러운 부담, 오버헤드로만 여겨서는 안 된다. 기왕 그런 게 있다면 이를 이용한 더 창의적이고 편리한 활용을 할 수 있어야 한다. 글쇠배열 연구나 언어 사전 자동 완성 같은 방법론은 타 언어를 기준으로도 동일하게 적용 가능한 것이니 한글의 구조만을 이용한 고유한 improvement가 있어야 한다.

그리고 이 분야에서 진짜 창의적인 기능을 넣으려면 결국 궁극적으로 두벌식이 아닌 세벌식 글자판을 써야 한다. 이미 1950년대에 공 병우 박사라는 희대의 천재가 기계식 타자기를 기준으로 한글 기계화의 큰 물꼬를 터 놨다. 세벌식이 타자기에서는 직관적인 입력과 기계간 글자판 통일을 실현했다면, 컴퓨터에서는 단순 모아쓰기 입력을 넘어서 동시치기와 더 수월한 입력· 수정을 실현할 수 있다.

이것이 날개셋 한글 입력기의 일관된 개발 이념이다. 괜히 한글 갖고 타 언어나 문자에다 오지랖을 부리는 건 내 관심사가 아니고, 그저 우리가 자국어를 입력할 때부터나 make the most out of를 하자는 것이다.
이런 게 있으면 아무리 현실에서 영어가 더 중요하더라도 한국어와 한글이라는 게 존재하는 게 그저 거추장스러운 잉여처럼 느껴지지 않을 수 있고 뭔가 존재의 의의를 찾을 수 있지 않겠는가? 더 나아가 이 좁아터진 나라와 민족 정체성에 대해서도 일말의 자부심이 더 생기지 않을까?

5.
전국민이 개인 전화기 겸 디지털 카메라를 들고 다니는 오늘날로서는 도저히 상상이 안 되겠지만.. 1990년대까지는 증명 사진을 하나 찍으려 해도 사진관에서 일단 사진을 찍은 뒤, 화학 반응을 수반하는 필름 인상(현상)이 끝날 때까지 몇 시간을 기다렸다가 다시 방문해서 사진을 찾아 가야 했다. 무슨 세탁소에 빨래를 맡겼다가 찾아 가듯이 말이다. 그리고 사진관들 출입문과 쇼윈도에는 'xx분 만에 초고속으로 사진 완성' 이런 문구가 적혀 있곤 했다.

그러나 지금은 그런 게 어딨냐..;; 사진관에서도 필름을 구성하는 감광 물질에다 화학 반응을 가해서 상(像)을 만들어 내는 게 아니라, 즉석에서 생성된 전자 디지털 이미지 정보를 그냥 고급 종이에다가 고해상도 컬러 인쇄를 해 줄 뿐이다. 세상이 이렇게 바뀌었다.
소프트웨어 개발을 develop이라고 하지만, 생물학에서 말하는 '발생'도, 사진의 '인화'도 develop이라고 한다. 날개셋 한글 입력기도 세포 분열이 일어나고 사진에 상이 쓰윽 생기듯이 개발 완료에 스르륵 근접하는 중이다. ^_^

Posted by 사무엘