바야흐로 2015년, <날개셋> 한글 입력기 개발 15주년과 더불어 7 다음 8.0으로 도약할 준비를 하고 있는 프로그램 개발실의 근황을 전하도록 하겠다.
1. 편집기의 한글 정규화 방식 수정
<날개셋> 한글 입력기는 첫 버전인 1은 차치하고라도 지금까지 보면, 피보나치 수열에 해당하는 버전에 첫 진입할 때 편집기의 에디팅 엔진에서 한글 처리와 관련된 중요한 변화가 생기곤 했다.
1.0은 2바이트 조합형 코드 기반이었는데 2.0은 한컴 2바이트 코드로 바뀌었다. 그러다 3.0은 유니코드 + 비표준 정규화 방식을 썼으며 5.0은 유니코드 5.2 체계로 바뀌고 비표준 관행이 완전히 없어졌다.
그러니 5.0의 이후부터는 한글 코드 같은 기본적인 부분은 더 바뀔 일이 없을 것 같았는데 사실은 그렇지 않았다. 이번 8.0은 KS X 1026-2가 규정하는 한글 정규화 규칙을 반영하는 알고리즘이 추가되었다. 현대 한글은 오로지 U+AC00 이후의 글자마디로만 표현 가능하고, U+1100대의 자모의 조합으로 표현하는 것은 허용하지 않게 했다. 자모 조합은 미완성 한글이나 옛한글일 때만 가능하다.
Windows Vista와 7은 이전 버전인 XP와는 달리 자모 조합으로 표현된 현대 한글을 글자로 묶어서 표현해 줬는데 이 기능이 8부터는 도로 없어졌다. 사실은 다 똑같이 묶어서 표현해 주는 게 컴퓨터의 입장에서도 처리하기가 더 편하지, 'all 현대 한글 case'만 또 따로 걸러내는 건 불편한 오버헤드가 추가되는 일이다.
하지만 한 한글은 오로지 한 가지 방식으로만 표현되게 하기 위해서 일부러 이런 정규화 규칙이 도입되었다. 그래서 똑같이 U+11??자모를 썼는데 '갬'은 한데 모이지 않지만, 개+ㅁㄱ 옛한글은 한데 모인다. '한'은 모이지 않지만 '아래아 한'은 모이게 되었다.
Windows도, 날개셋도 다 버전 8부터 이 표준을 반영하기 시작했다는 것이 흥미롭다.
2. 수식에서 상수의 원형 보존
<날개셋> 한글 입력기는 먼 옛날 3.0에서부터 64비트 정수의 수식이 도입되어 글쇠배열, 오토마타, 입력 항목(글자판) 전환 같은 여러 용도로 쓰이고 있다.
수식은 크게 상수, 변수, 연산자로 구성되며 상수는 10진수, 16진수, 작은따옴표로 둘러싸인 문자 하나, 그리고 명칭이라는 네 가지 형태 중 하나로 표현할 수 있다.
사용자가 입력한 수식은 내부 데이터 구조로 바뀌어 저장되며, 이 내부 데이터는 지금까지 사용자가 입력한 상수의 형태에 대한 정보를 갖고 있지 않았다. 즉, 모든 상수를 저 네 형태 중 하나로만 획일화하여 표현했다.
그러던 관행이 오는 8.0에서부터 드디어 개선된다. 글쇠배열 수식을 예로 들면, 어떤 글쇠는 0xAC00이라고 입력하고 다른 글쇠는 '가'라고 입력했다면 사용자가 입력했던 각각의 형태가 드디어 보존된다.
서로 형태가 다른 상수와 상수끼리 연산이 수행된다면, 연산 결과를 나타내는 상수의 타입은 대부분 왼쪽 먼저 등장한 상수의 형태를 따른다. 그래서 100 앞에다가 0x0+을 붙여 주면 아무 효과가 없는 0은 없어지고, 100을 16진수인 0x64로 바꿀 수 있다. 그리고 앞에 'a'-'a'+를 붙이면 아스키 번호 100에 해당하는 'd'로 100의 표현 형태를 바꿀 수 있다. 이런 표현 형태는 내부적인 수식의 값 계산 성능에는 전혀 영향을 주지 않는다.
글쇠배열에 e==10 ? 0xAC00: 0xAC11 같은 수식이 있다고 생각해 보자. 10은 유니코드 문자나 날개셋문자와는 관계가 없고 다른 의미를 갖는 상수이기 때문에 굳이 16진수로 표시되어야 할 필요가 없다.
지금까지는 이 10도 싹 다 16진수로 바뀌어서 0xA로 표현되었지만, 이제부터는 사용자가 처음에 10진수로 입력한 상수는 저장도 10진수로 된다.
이런 식으로 작지만 큰 변화가 버전이 7에서 8로 바뀔 때 실현되기 적절한 변화라고 여겨진다. 새로운 정보가 추가되었기 때문에 8.0의 제어판에서 만들어서 바이너리 방식으로 저장한 입력 설정 파일은 이제 이전 버전에서 거의 읽지 못하게 될 것이다.
음수는 16진수, 명칭, 문자 등 다른 모든 형태를 무시하고 언제나 10진법으로만 표현된다. 그리고 왼쪽 피연산자 상수의 형태를 따르지 않는 예외 연산자는 다음과 같다.
- 콤마: 연산들을 좌에서 우로 순서대로 나열하는 역할만 하고 최종 계산값은 맨 뒤의 값이 되므로, 왼쪽이 아니라 오른쪽의 형태를 선택한다. 즉, (10, 'A', 0x10)+1은 0x11로 최적화된다는 뜻이다.
- 조건 연산자: A ? B:C 연산은 B와 C중 값으로 채택된 놈의 형태를 따른다.
- 참/거짓만을 되돌리는 논리 연산자들: 비교, 동등, 논리 AND/OR/NOT은 좌우 피연산자의 형태에 관계없이 언제나 지금 수식이 사용하는 기본 표현 형태를 따른다. 어차피 0 아니면 1밖에 안 돌아오며 (A==B)*100 이런 변태적인 활용을 하는 일은 없으니 별 의미도 없을 것이다.
이런 시스템을 하나씩 설계하는 게 프로그래머로서 참 재미있는 일이다.
3. 미흡했던 부분 개선
(1) 조합 도중에 출력하는 글자와 그 상태로 조합이 종료됐을 때 표시하는 글자가 다를 수 있는 상황에 대한 처리를 이제 거의 완벽하게 마쳤다. 이 작업이 특별히 중요한 이유는 지난 7.9에서 추가된 '글쇠 누름' 날개셋문자와, 고급 입력기의 '초성 지향 도깨비불'이라는 두 가지 기능 때문이다.
전자의 경우 한글 입력과 관계가 없는 글쇠가 눌러짐으로써 한글 조합이 종료되어야 하며, 후자는 중간에는 '하ㄴ'처럼 조합을 표시하다가 나중에는 '한'으로 바꾸면서 조합을 끝내야 하기 때문이다.
이 작업은 편집기, 외부 모듈, 입력 패드의 각 구현체별로 다 따로 해 줘야 했으며 굉장히 어려운 작업이었다.
프로그램이 처음에 설계될 때부터 이런 것까지 다 고려해서 만들어졌으면 얼마나 좋았겠느냐만, 그 시절에 이것저것 다 따져야 했으면 프로그램이 애초에 제대로 만들어질 수가 없었을 것이다. 그래서 <날개셋> 한글 입력기는 개발된 지 15년이 지난 지금까지도 소스 코드의 이곳저곳이 공사중이다. 예전에 대충 만들었던 코드를 엄밀하게 다시 작성하는 작업이 태반이다.
(2) 외부 모듈: 이번 7.9에서는 아시다시피 Windows 8 이상에서 동작할 때 [한0], [A1] 같은 상태 아이콘의 글자 주변에 검은 테두리가 쳐졌는데.. UI 디자인 가이드라인의 하나만 보고 둘은 몰랐다. 테두리는 검은색이기만 한 게 아니라 반투명 알파값이 적용되어야 하더라..;; 그래서 이것도 마저 적용했다.
(3) 텍스트 필터: '코드 번호로 변환' 필터는 문자를 접두사를 붙여서 해당 글자의 다양한 인코딩 번호 형태로 바꾸는 기능을 제공한다. 알파벳이나 숫자는 원래는 변환 대상이 아니지만 바로 앞의 문자가 인코딩 번호로 바뀌었다면, 또 숫자나 알파벳이 연이어 등장하는 것을 막기 위해서 예외적으로 바꾼다. 다시 말해 '0'은 변환하지 않지만 '가0'은 '\xAC00\x30'처럼 바꾼다는 뜻이다.
그런데 이런 유도리가 유니코드 코드포인트로 바꿀 때에만 적용되었고, 다른 인코딩의 바이트 번호로 바꿀 때에는 적용되지 않았었다. 이것을 모 사용자에게서 지적받고 고쳤다.
4. 버그 수정
(1) 외부 모듈 A: 이번 7.9는... 혹시 눈치 채신 분이 계신지 모르겠는데, 외부 모듈에서 제어판을 이용한 뒤 '미저장 확인'이 동작하지 않는 귀찮은 문제가 있었다. 으윽.. 곧바로 버그 잡음. 편집기나 입력 패드는 상관 없다.
<날개셋> 한글 입력기는 한번 만들고 더 고칠 일 없이 끝이다 싶은 부분도 심심하면 여기저기 파내면서 리팩터링 공사를 하고 있다. 그러면서 불행히도 예기치 못한 실수가 들어가곤 한다.
(2) 외부 모듈 B: 이것은 직전 버전뿐만이 아니라 상당히 오랫동안 존재하던 버그라면 버그이다.
편집기의 경우, 조합이 끝난 한글을 한 글자씩 한자로 바꾸거나 한자를 하나씩 한글로 바꾸면, 글자가 바뀜과 동시에 cursor도 뒤로 밀려났다. 그래서 다음 글자도 연달아 바꿀 수 있다. 그 반면, 두 글자 이상의 글자가 한꺼번에 바뀌면 cursor가 뒤로 밀려나지 않는다.
그런데, 외부 모듈은 편집기와 동일하게 동작이 가능한 TSF A급 환경에서는 한 글자 단위로 변경을 했을 때도 cursor가 뒤로 밀리지 않았다. 안 밀릴 이유가 없는데 구현체별로 동작이 다른 것을.. 꼼꼼한 전체 코드 검증 테스트 끝에 발견하여 수정했다.
또한, 워드패드 같은 일부 TSF A급 구현체에서 0xF 특수글쇠를 이용해 앞 글자를 조합하는 상태로 갔다가 바로 다음다음 글자로 갔을 때, 글자가 생기는 곳과 cursor가 생기는 위치가 어긋나던 문제도 같은 원인 때문이었다. '알려진 문제'라고 오랫동안 도움말에도 등재돼 있던 사항이었는데 드디어 해결되었다.
(3) 입력 패드: '문자표'나 '부수 한자 입력'처럼 콤보 박스가 있는 도구를 꺼낸 뒤, 콤보 박스에서 뭔가를 고르고 나면 프로그램이 바로 뻗었다..;; -_-;; 7.9에만 있는 문제이다. 7.91 패치를 만들기라도 해야 하나 싶은 자괴감이 들었다.
(4) 편집기: 프로그램 창을 최소화시킨 상태에서 시스템 테마 같은 게 바뀌었을 때, 혹은 창의 폭을 아주 작게 한 상태에서 가끔은 텍스트의 문단 정렬 알고리즘에 오동작이 발생해서 프로그램이 무한 루프에 빠지는 심각한 버그가 있었다. 그냥 뺑뺑이만 도는 게 아니라 줄을 나타내는 메모리를 한없이 할당하면서 뻗었다.
굉장히 드문 상황에서 발생하는 문제이고 7.9만의 문제가 아니라 아마 6~7 이전의 굉장히 오래 전 버전부터 존재했던 문제이긴 한데, 이번에 뒤늦게 발견되어 버그를 저격하는 데 성공했다.
Posted by 사무엘
