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

<날개셋> 한글 입력기 6.8이 나온 지 벌써 두 달 정도 시간이 지났다. 이 버전은 잘 알다시피 외부 모듈까지 Windows 8을 정식 지원하기 시작한 첫 버전이라고 선전... 은 했는데, 그 후로 Win8 사용자들로부터 역시 여러 미흡한 점들이 보고되었다..

• IE의 주소 입력란 말고, 웹페이지 폼의 입력란에서 글자를 입력하는 중에 한/영 상태 버튼을 우클릭하면 메뉴 항목들이 disabled되어 나오는 것: 무척 괴이한 현상이지만 어쨌든 해결함
• Modern(Metro) UI의 IE에서는 데스크톱 모드에서 맞춰 놓은 입력 설정이 제대로 반영되지 않고 동작하는 것: 파일 읽기에 문제가 있는 듯
• 날씨(Weather) 같은 일부 자바스크립트 기반 앱에서는 <날개셋> 한글 입력기 커널 자체가 제대로 구동되지 못하고 영문만 입력되는 것: 역시 커널 DLL 파일에 접근하는 과정에 문제가 있는 듯. 권한 문제?

저것 말고 여전히 Windows 8의 Modern UI에서 <날개셋> 한글 입력기의 사용에 문제가 있는 분은 운영체제의 부팅 이후로 문제를 재연하는 모든 step을 마우스 클릭 단위로 상세하게 알려 주시기 바란다. 난 Windows 8 안 써서 그쪽 UI를 잘 모른다..;;더구나 데스크톱 앱과는 달리, Modern 앱들은 디버깅을 위해서 꼭 인터넷 접속을 해야 한다는 게 개인적으로 굉장히 불편하다. 정작 내 프로그램은 인터넷 같은 건 전혀 사용하지 않는데...

또한 근본적으로 Win8은 기존 데스크톱 환경과 Modern(메트로) 환경 사이에 장벽을 너무 많이 쳐 놨다. 그래서 데스크톱을 근간으로 하고 있으면서 Modern용 프로세스의 안에서도 서식해야 하는 외부 모듈에게 보안상 걸리는 제약이 너무 많다. 서로 memory mapped-file도 공유가 안 되고, Modern 프로세스 안에서는 대부분의 디렉터리에 접근도 안 되고.. 내 문서, ProgramData 다 안 된다.

Program Files와 Windows 디렉터리만 접근을 허용한다고 하는데, 전자는 32비트와 64비트가 따로 존재하기 때문에 사전이나 테이블 같은 공용 데이터를 놔 두기에는 적절하지 않은 위치이며 더구나 관리자 권한이 없으면 파일을 쓸 수도 없다. Windows\IME는 공식 설정상으로는 애초에 운영체제의 보급 IME들만이 사용하는 위치이다. 도대체 IME는 뭐 어떻게 동작하면서 Modern와 데스크톱 사이에 설정을 공유하라는 건지 모르겠다. 결국 레지스트리를 파일처럼 정보 공유 매체로 다루는 수밖에 없어 보인다.

뭐, 다음 버전을 개발하는 과정에서 이 이슈 말고도 다른 쪽으로도 <날개셋> 한글 입력기는 6.8 이래로 소스 코드가 많이 바뀌었다. 6.8은 다행히도 그 버전 자체만의 예기치 못한 버그가 들어있지 않으며 그럭저럭 잘 만들어졌다. 그래서 이 버전에 대한 유지 보수를 따로 할 필요가 없이 다음 버전인 7.0이 잘 개발되고 있는 중이다. 본인으로서는 다행스러운 점이다.

다음 버전 개발 근황을 좀 마이너한 아이템 위주로 늘어놓자면 이렇다.

1. 한컴 2바이트 코드와 한양 PUA 코드 변환과 관련된 모든 기능들은 드디어 <날개셋> 커널에서 완전히 삭제되었다. legacy 문자 코드에 대한 지원은 이미 4.8x대에서부터 차츰차츰 줄어들고, 커널에 있던 코드가 플러그 인 변방으로 이동하는 식으로 리팩터링이 진행되고 있었는데 그게 다 끝을 본 것이다. 이제 커널인 ngs3.dll에는 그런 문자 코드의 처리와 관련된 일체의 코드(프로그램)가 들어있지 않다.

2. 유니코드 문자열로부터 한글을 읽거나 쓰는 알고리즘을 미세하게나마 좀 더 최적화하고, 문자 인코딩을 자동 판단하는 알고리즘도 더 똑똑하게 개선했다. 한글이 없이 특수문자만 가득한 2바이트 인코딩을 제대로 판단을 못 하거나, 1바이트 아스키 문자 나열을 UTF16으로 오인하는 경우를 대폭 줄였다.
이 프로그램은 예나 지금이나 유니코드 UTF16, UTF8, 완성형(CP949), 그리고 조합형 코드(CP1361)을 자동 인식할 수 있다.

3. <날개셋> 편집기는 지난 3.0 시절부터 ‘기타 가져오기’ 기능을 통해 콘솔 프로그램의 출력 결과를 그대로 가져오는 기능이 있는데, 이 기능이 먼 옛날 버전부터 지금에 이르기까지 무척 비효율적으로 구현되어 있었음을 발견하여 대대적으로 개선했다.
언제든지 ‘취소’를 누르면 작업이 즉시 취소된다. stdout뿐만 아니라 stderr의 출력 결과도 가져온다. 그리고 프로그램의 실행이 끝난 뒤에도 작업 스레드가 정상적으로 끝나지 않고 강제 종료되고 있었던 것을 고쳤으며, 이 때문에 heap과 stack 메모리에서 발생하던 숱한 메모리 누수들도 덩달아 해결했다..

4. <날개셋> 편집기는 MFC를 쓰지 않고 자체 개발된 이래로 '창' 메뉴를 보면, 현재 선택되어 있는 문서 창의 항목에 체크가 표시되지 않는 버그가 있었다.. =_=;; 이걸 뒤늦게 인지하여 고침.

5. 외부 모듈의 경우 잘 알다시피 아이콘이 Windows 8 스타일의 흑백 배색으로 바뀌었는데, 표준 가이드라인에 따르면 겉의 테두리가 회색이 아니라 사실은 50% 알파가 적용된 검정이었다. 그것을 고쳤다.
그리고 사용 중인 글자판의 종류를 판단할 때, 비록 알파벳과 한글을 모두 입력할 수 있는 모호한 글자판이라도 한글(가/한) 판정이 후하게 나도록(A) 알고리즘을 살짝 고쳤다.

6. 외부 모듈은 제어판을 열어서 ‘확인’을 눌러서 종료하면 새로 바꾼 입력 방식이 모든 프로그램에서 곧바로 적용되어야 한다. 하지만 32비트 프로그램과 64비트 프로그램 사이에서는 이것이 동기화가 되지 않던 문제가 있었다. 새 버전은 이것을 해결했다. <날개셋> 한글 입력기가 64비트 플랫폼을 지원한 건 4.x시절 말기부터이고 시기적으로는 무려 5~6년이 지났는데 지금까지 이 점에 대해서는 전혀 생각을 못 하고 있었다.

7. 한글 로마자 입력 방식에서 표준 방식은 O+A로는 ‘ㅘ’가 되지 않고 오로지 W+A로만 ‘ㅘ’가 되게 규칙을 수정했다..

8. 일반적인 세로 스크롤용 휠뿐만 아니라 가로 스크롤 휠도 이제 드디어 지원한다. 일부 노트북 PC에서 터치패드 한쪽 끝을 가로로 드래그하면 이 메시지가 가는 경우가 있는데, 덕분에 편집기나 화면 인쇄 등 주요 화면에서 가로 스크롤이 가능해졌다.

<날개셋> 한글 입력기는 글쇠배열이나 오토마타 같은 걸 자유롭게 사용자 정의 가능하고 한글 입력과 관련된 거의 모든 아이디어들을 한데 기술할 수 있는 기반을 마련한 것으로 잘 알려져 있다. 하지만 그것 못지않게 이 프로그램의 독특한 면모는 바로 다양하고 개성 있는 구현체들이다. 문자 입력 기능을 제공할 수 있는 모든 형태의 구현체를 제공하기 때문이다.

편집기는 자체 한글 텍스트 에디터로, 문서 편집 창이 뜨는 일반적인 응용 프로그램과 가장 비슷한 형태이다. 전용 환경이다 보니 제공되는 기능이 가장 많고 특히 텍스트 필터를 써 볼 수 있는 사실상 유일한 구현체이다.
흔히 IME라고 불리는 외부 모듈은 EXE가 아니라 DLL이다. 범용성과 존재감이 가장 큰 구현체이다. 제공하는 기능의 양은 편집기보다 적지만, Windows 95부터 8까지의 모든 운영체제들의 특이사항을 커버하느라 코드의 양은 이게 편집기의 그것보다 더 많다.

변환기는 문자를 입력하는 기능은 없지만 한글의 표현과 관련된 호환성 유지를 위해 필요한 기능들을 한데 담은 유틸리티로, 간단한 대화상자 형태이다.
끝으로 입력 패드는 포인팅 장비를 이용한 문자 입력 기능만 제공하는 작은 프로그램으로, EXE 형태이지만 IME 내부 자료구조에 대한 훅킹을 통해 동작한다.

이런 모든 경우를 다 생각해서 개발되었다는 뜻이다. 이 구현체들은 심지어 도움말 내지 About 명령조차 서로 전부 제각각인 위치에 있을 정도로 사용자 인터페이스가 천차만별이다. (편집기는 프로그램의 도움말 메뉴, 외부 모듈은 입력 도구모음줄의 도움말 버튼, 변환기는 프로그램의 시스템 메뉴, 입력 패드는 시스템 트레이의 우클릭 메뉴)

개인적인 생각은 이들 프로그램의 아이콘도 마치 MS Office의 Word, Excel 등처럼 뭔가 한 제품에 속한다는 통일성이 느껴지는 형태로 바꾸고 싶다. <날개셋> 편집기의 지금 아이콘도 써먹은 지 벌써 10년이나 됐는데..

가끔은 까마득한 옛날의 1.x와 2.x버전을 꺼내서 실행해 본다. 내가 세상에 이런 완전 캐허접한 프로그램만으로 옛날에 정보 올림피아드 입상을 했구나 하는 생각이 든다. 1은 텍스트 에디터 하나 제대로 만들 기술도 없던 상태에서 그냥 세벌식 자판만을 위한 똘끼어린 최소한의 기술 데모일 뿐이었고 2는 버전 3을 만들기 위한 숱한 시행착오 단계였다.

3에서는 진짜 최소한의 뿌리와 기반이 갖춰지긴 했으나 아직도 허접한 UI와 외부 모듈의 안정성을 갖추기 위해 갈 길은 멀고도 험했다. 4는 버전 3이 경험한 시행착오들을 수습하면서 운영체제에 대한 독자적인 기술과 노하우가 차츰차츰 쌓이던 단계였고, 개발 8주년이 된 버전 5가 돼서야 내가 보기에 슬슬 쓸 만한 물건이 나오기 시작했다. 그리고 그 컨디션이 6에서 계속되는 중이다.

이 정도로 혼자 오래 꾸준히 개발한 프로그램이니, 내가 무슨 게임을 만든 것도 아닌데 이 프로그램에 대한 나의 애착과 중독성은 상당한 수준이다.
일단 결과물 자체부터 내가 매우 애용하고 있다. 비록 현실적으로는 외부 모듈이 가장 대중적으로 쓰이는 구현체일지 모르나 내가 가장 애용하는 구현체는 편집기이다. 자체적으로 문서를 편집하는 기능을 갖춘 일반적인 애플리케이션이며, 가장 먼저 개발되기도 했기 때문이다. 그냥 습관적으로 띄워서 뭐라도 글을 쓰고 한글 오덕질을 하고 싶은 생각이 절로 든다.

결과물뿐만이 아니라 도움말도 계속 읽어보고 싶고, 딱히 코딩을 안 해도 소스 코드를 꺼내서 뭐라도 리팩터링이나 최적화를 하고 싶다. 불행인지 다행인지 이 프로그램에 대한 모든 정체성과 권리는 본인이 혼자서 완전히 꽉 잡고 있기 때문이다. 1인 독재. <날개셋> 한글 입력기의 모든 바이너리들은 100% 자작 코드로만 이뤄져 있다.

그런데 여기에만 매여 있느라 다음 다른 연구도 제대로 못 할 정도인 건 문제인 것 같다.
이것과 관련된 개발 말고 다른 분야에는 도무지 관심이 생기질 않아서, 이걸 못 하고 덕업일치를 못 하느니 프로그래밍은 확실하게 취미 수준으로 접고 차라리 철도 같은 업종 전환도 고려할 정도로 진로가 좀 이상한(?) 방향으로 흘러가고 있다. 난 어지간한 다른 IT 분야 엔지니어들과는 애초부터 입문한 계기도 달랐고, 적성이나 취향도 다른 것 같다.

Posted by 사무엘

1. 6.8 버전의 의미

<날개셋> 한글 입력기 6.8이 나왔다. 2013년에 나온 최초의 버전이다.
사실 6.71과 6.8의 변화량은 6.7과 6.71 사이의 변화량보다도 적을지도 모른다.
새로운 기능이 추가된 게 없고, 양 버전 사이의 바이너리 호환성이 깨진 것도 없다.

그러나 6.71의 다음 버전을 6.72 대신 6.8로 잡은 것은, 이 버전에서 드디어 외부 모듈이 Windows 8 운영체제를 정식 지원하기 시작했기 때문이다. 비록 내 주변에 Win8 쓰는 사람은 아직 한 명도 못 봤지만..;;;

원래 계획은 6.7의 바로 다음 버전을 6.8로 하고 Win8을 바로 지원하는 프로그램을 만드는 것이었다.
하지만 여건상 그렇게는 못 하고 중간에 6.71을 거치게 됐다. 일단 Win8과 관련하여 편집기의 당장 급한 이슈만 해결하고, 더 근본적인 연구가 필요한 사항은 다음 버전의 숙제로 미룬 것이다.

6.71은 0.01만 올리기에는 해 놓은 게 많지만 그 내역이 딱히 존재감이 없다.
그 반면, 6.8은 절대적인 양은 0.09만 한 변화는 아니지만 그게 바로 'Windows 8 지원'이라는 존재감 큰 변화이다.
그래도 지금 두 버전의 변화 사항을 합하면 6.7 이후로 0.1쯤은 충분히 올릴 명분이 된다.

2. 수익 모델

이번 6.8 버전은 지금보다 더 이른 1월 중에 나올 수도 있었다.
그러나 본인의 직장 스케줄이 다소 바빠지고, 거기에다 투잡 같은 일종의 부업까지 뛰느라 한동안 <날개셋> 쪽으로 연구 개발을 전혀 할 수 없었던 관계로 프로그램의 완성이 늦어졌다. 시간이 없고 너무 힘들어서 이제 앞으로 투잡 같은 건 당분간 안 하련다.

투잡이라는 게 내가 생활고-_-에 시달려서 하는 건 아니고, 이게 그나마 <날개셋> 한글 입력기의 기술로 금전적인 이득을 얻는 통로라는 의미와 명분이 있어서 종종 해 왔다. 내 프로그램은 엔진 그 자체는 일반인을 대상으로 유료로 판매하는 상업용 소프트웨어가 아니고 심지어 광고 노출로 돈을 버는 것도 아닌데, 대회 상금이 아니면 이게 이윤을 창출해 온 유일한 방법이다.

별 게 아니라, 바로 <날개셋> 한글 입력기로 구현할 수 있는 입력 방식을 떼어서, 날개셋이라는 브랜드를 떼어내고 해당 코드만 최적화 static link하여 고객이 원하는 문자 입력 솔루션을 외주 개발하는 것이다. 물론 핵심 루틴은 빌드가 가능한 static library 형태로만 주고 소스 공개 안 한다.

세상에 날개셋 같은 완전 universal한 솔루션도 직접적인 수익 모델이 없으며, 표준 두벌식 다음으로 가장 인지도가 높고 구조적으로 우수한 공 병우 세벌식 같은 글자판조차도 만년 듣보잡 신세를 면치 못하고 있는데.. 한글 입력 방식 그 자체만으로 이제 무슨 사업을 하고 수익을 낼 게 있는지에 대해서는 한글 입력기의 개발자인 나조차도 회의적이다. 그래도 프로그램 만들면 개발비를 준다고 하고, 노력 대비 수지가 맞다고 여겨지니까 한다.. ^^

아무래도 일반적인 입력 방식은 레드 오션이 된 지 오래이니 진입할 틈새가 없고, 장애인용이나 동시치기 속기 같은 특수한 마이너 분야를 노려야 하지 않을까 싶다. 모바일이 아닌 PC용이라면 더욱 그러하다.

다만, 난 예전에도 공언했듯이 이미 소속된 직장이 있는 데다, 자체적으로 글꼴 연구도 해야 하고 나만의 연구 개발도 여전히 계속해야 하는데... 자꾸 외부에서 부탁하는 걸 받아서 하면 내가 자기 계발을 할 시간을 빼앗기기 때문에 이것도 큰 딜레마이다. 외부로 품팔이를 하지 않고 내가 하는 일만으로 경제적으로 자립할 수는 없을까? 이것도 점점 생각하지 않을 수가 없음을 느낀다. 정 답이 없으면 난 농담 반 진담 반으로 한 10년쯤 뒤엔 그냥 철도로 업종을 바꿔 있을 수도 있다. ㅋㅋ

3. Windows 8 이모저모

자, 암울한 돈 얘기는 그만 하고, 다음 주제인 Windows 8로 넘어가겠다. Windows 8에서는..

(1) 32비트 시절 이래로 전통적이던 관행을 깨고, 모든 프로그램이 동일한 입력기를 공유하는 설정이 추가되었으며 이것이 기본으로 적용되어 있다. 단, 옵션을 바꾸면 예전처럼 스레드별로 따로 놀게 할 수도 있다.

(2) active 입력기와 default 입력기의 구분이 없어졌다. 한 프로그램에서 입력기를 바꾸면(active) 그게 곧 default가 되며, 다음에 실행되는 프로그램은 그 입력기를 기본으로 사용하고 있다. 이것은 예전 Windows 버전처럼 동작하게 하는 옵션이 없으며, 그냥 개념을 저렇게 간소화시킨 듯하다.

(3) language bar(입력 도구모음줄)가 극도로 단순해졌다. 시스템 트레이에 '입력기 아이콘'과, 이 입력기의 '상태 아이콘'이라는 단 두 개의 아이콘만이 고정되어 나타나며, 나머지 자질구레한 기능들은 '상태 아이콘'을 우클릭했을 때 나타나는 메뉴를 통해 선택하게 되어 있다. 단, 옵션을 바꾸면 예전의 전통적인 길쭉하고 버튼 많은 language bar 방식을 쓸 수도 있긴 하다.

Win8의 디자인은 사실 TSF가 도입되기 전에 윈도우 95~ME가 사용하던 internat.exe 기반의 indicator 방식으로 되돌아 간 것이나 마찬가지이다. 그때도 IME 아이콘은 시스템 트레이에 입력기 아이콘과 상태 아이콘 둘만 있었기 때문이다. 디자인이 돌고 돌아 복고풍이 채택된 것 같다.

<날개셋> 한글 입력기 6.8은 이제 이 새로운 상태 아이콘을 지원한다. 이 아이콘은 우클릭을 하면 전체 기능을 선택하는 메뉴가 나오고 좌클릭을 하면 글자판(한/영 상태 같은)을 전환하는데, 글자판을 전환하는 규칙이 예전의 글자판 전환 버튼과는 살짝 다르다.

Windows 운영체제는 내부적으로 한글 아니면 영문이라는 이분법적인 구도로 자체 상태를 정의한다. 그러나 <날개셋> 한글 입력기 엔진은 임의의 n개의 입력 항목을 가질 수 있다. 그래서 기존 글자판 전환 버튼은 입력 항목이 딱 2개 존재할 때만 toggle 방식으로 동작하고, 3개 이상일 때는 메뉴를 표시하여 무슨 글자판을 지정할지 사용자가 직접 선택하게 했다.

하지만 Windows 8의 새로운 상태 표시 겸 글자판 전환 버튼은 동작 방식이 약간 다르다. 메뉴를 선택해야 하는 동작은 전적으로 우클릭이 전담한다. 그리고 좌클릭을 했을 때는 언제나 직전에 사용하던 non-trivial 글자판과 trivial 글자판만을 toggle 형태로 왔다 갔다 한다. trivial이란 '빈 입력 스키마', 또는 '빈 입력 스키마와 호환되게' 옵션이 지정되어 아무 글쇠도 처리하지 않는 '영문' 모드이고, non-trivial은 그렇지 않고 글쇠를 자체 처리하는 '한글' 모드에 대응하는 입력 항목이다. 실제로는 한글 이외의 다른 문자를 입력하더라도 말이다.

내가 살펴보니 기존 데스크톱 말고 메트로(Modern UI) 모드에서는 별도의 IME 툴바 같은 것 자체가 화면에 나타나지 않다 보니, 문자 입력란이 포커스를 받으면 IME가 자신의 한/영 모드를 근처에다 잠깐 표시했다가 사라지는 기능까지 제공하는가 보다. <날개셋>의 이번 버전은 그것까지는 구현하지 않았다. 일단 동작하는 것 그 자체에 의의를 두련다.

4. 다음 버전 계획

이번 6.8 버전은 <날개셋> 한글 입력기 6.x대의 마지막 버전을 염두에 두고 있다. 물론 Win8 지원과 관련해서 미흡한 부분이 또 발견되거나 사소한 기능 개선들의 양이 일정 수준을 넘어선다면 부득이 6.8x가 또 나와야겠지만, 새로운 기능이 추가된다거나 하면 반드시 7.0으로 갈 것이다.

그리고 혹시나 해서 말인데, Windows 8을 쓰고 있지 않다면 6.71하고 6.8이 아무 차이가 없느냐 하면 그건 물론 아니다. 예전 글에서 언급되었던 버그들이 고쳐졌다. 특히 6.71은 버그 때문에 사용자 정의 조합을 편집할 수가 없으니, 이 기능을 사용한다면 6.8로 업그레이드가 필수이다.

Win8 지원 작업이 완료되고 나면, 그 다음 버전은 다시 오랜 숙제로 남아 있는 입력 엔진 쪽의 기능 추가에 초점을 맞출 것이다.

• 한자를 누르면 일반 한자 변환 모드가 되지만 Shift+한자를 누르면 사용자가 정의한 후보 리스트로 변환. 이를 위한 준비 작업은 이미 거의 5.x 버전 시절부터 해 놓았지 싶다. 한자 변환 명령을 4종류로 세분화했음.
• 입력 패드 쪽으로 다양한 새로운 기능 추가
• 임의의 글쇠뿐만 아니라 임의의 글쇠 동작까지 인식하는(동시치기, 길게 누르기 등등..!) '고급 입력 스키마' 완성

이게 다 갖춰지면 7.0 번호는 다 따 놓은 당상이리라.

5. 기타 잡설

(1) 세상에는 온갖 기괴한 한글 입력 방식이 존재한다. 그런 것들 중에는 정말 참신하고 의미 있는 발명인 것도 있다. 내부 메커니즘은 두벌식에 속하거나 세벌식에 속하거나 그 중간에 속할 수 있다.
그러나 공 병우 세벌식은 너무 직관적이고 평이하고 당연한 구조여서 딱히 튀는 게 없다. 그렇기 때문에 이건 다른 어떤 입력 방식보다도 더욱 의미 있고 fundamental한 발명이다.

세상에 기계간의 글자판 통일까지 염두에 두고서 사람 손으로도 이렇게 한글을 빠르고 편하게 잘 칠 수 있는 글자판은 공 병우 식 말고는 딱히 생각해 낼 수 없다. 한글교라는 종교가 있다면 이게 진짜 한글교의 핵심 교리 내지 이념이라 하지 않을 수 없다. 한글 입력기를 만든다면 이 방식부터 마스터를 한 뒤 더 복잡하고 편법이 필요한 물건으로 내려가는 게 순서일 것이다. 이것이 내가 예나 지금이나 공 병우 세벌식 덕후요 빠돌이인 이유이다.

(2) 텍스트 에디터라는 건 생각보다 굉장히 만들기 어려운 물건이다.
<날개셋> 편집기도 겉보기로는 시대에 너무 뒤떨어진 전/반각 비트맵 글꼴을 사용하고 있지만...
그 대신 MS Word 같은 다중 블록에다 세로쓰기도 지원하고, 다단계 undo까지 갖추고 있다.

또한 텍스트의 여러 군데가 동시다발적으로 변경되었을 때 필요한 부분만 문단을 다시 정돈하고, 딱 필요한 최소한의 구간만 화면을 업데이트하는 것은 <날개셋> 한글 입력기도 무려 6.x대 버전에 와서야 완벽한 구현체가 나왔을 정도이다. 타이포그래피 시스템을 그 정도로 제약하고 단순화하고도 절대로 호락호락 만들 수 있는 게 아니다.

하물며 텍스트 서식과 복잡한 유니코드 complex script를 지원하고, 장치 독립적인 레이아웃을 구현해야 하는 위지윅 워드 프로세서는 에디팅 엔진의 복잡도와 난해함이 어디까지 치솟을지 나조차도 선뜻 감을 못 잡겠다.

Posted by 사무엘

지난해 말에 <날개셋> 한글 입력기 6.71이 나온 지도 벌써 두 주가 넘게 지났다.
한 열흘 동안은 프로그램 소스를 고칠 일이 없이 나도 새 버전을 잘 썼다. 한글 입력과 관련하여 내가 속으로 구상하고 있는 최소한의 기술적 기반을 아주 탄탄히 갖춰 놓은 이 프로그램에 만족하면서 지냈다.

그러나 세월이 흐르면서 역시 프로그램에는 약점, 버그 내지 개선할 점이 발견된다.
그리고 지금 추세대로라면 다음 달쯤에 6.72 정도의 마이너 업그레이드 버전이 또 나와야 할 것 같다.
이 글에서는 2013년 1월 현재의 <날개셋> 한글 입력기의 개발 소식을 좀 전하도록 하겠다.

1. 사용자 정의 조합 제어판 UI에 프로그램이 뻗는 버그가 있음

먼저, 좀 어이없고 치명적인 버그가 발견되었다.
6.71은 제어판에서 '<날개셋> 고급 입력기'의 관할에 있는 '사용자 정의 조합'의 데이터를 조합 로직이든 후보 데이터든 고칠 수가 없다. 그걸 고치고 나면 데이터가 쓰레기값으로 바뀌고 프로그램이 죽는다.

본인은 한번 만들었던 코드를 그냥 내버려 두는 게 아니라 끊임없이 최신 코딩 스타일로 리팩터링을 하는 편인데, 그 과정에서, 해제해서는 안 되는 메모리를 부적절한 타이밍에 먼저 해제해 버리는 실수가 들어갔다.
이런 버그가 생긴 것을 유감-_-스럽게 생각한다.

2. 외부 모듈, 한글 첫 타가 덧나거나 끊기는 문제

<날개셋> 한글 입력기 외부 모듈은 특정 응용 프로그램에서 한글 조합 첫 타가 덧나거나 조합이 끊어지는 등, 제대로 인식되지 않는 문제가 종종 있었다. MS 오피스의 엑셀이나 파워포인트 등, 평상시에는 텍스트 편집 모드가 아닌데 한글 입력과 동시에 cursor가 나타나고 텍스트 편집 모드로 진입하는 프로그램의 경우 이런 오동작이 있는 편이었다.

그리고 최근에는 유명 공개 소프트웨어인 Paint .NET의 텍스트 입력 도구에서도 첫 타가 제대로 처리되지 않는다는 버그 신고가 있어서 이를 확인했다.
분석을 해 보니, 문제를 해결하는 방법은 간단하다. 이미 알려져 있는 방법론을 적용하면 된다. 그런데 문제는, 그 방법론은 다른 프로그램에서는 또 다른 오동작을 일으킨다는 것이다.

모든 프로그램에서 정확하게 잘 동작하는 해결책은 본인은 MS 한글 IME의 소스를 보지 않은 이상, 난 알지 못한다. 이게 사실은 IME의 개발과 관련해서 굉장히 골치 아픈 문제이기도 하다. 결국 현재 IME를 사용 중인 응용 프로그램의 이름에 따라 일부러 서로 다르게 동작하는 지저분한 꼼수를 동원할 수밖에 없었다.

그래서 Paint .NET에서 발생하는 그 문제를 어쨌든 해결은 했다. 그러고 보니 네이티브 코드 프로그램이 아닌 닷넷 기반 프로그램을 디버깅한 건 이번이 처음인 것 같다. .NET 프로그램은 EXE의 PE 헤더로는 x86용 32비트 프로그램이라고 명시되어 있어도, 64비트 운영체제에서는 결국 64비트 IME가 동작한다는 걸 알 수 있었다. 신기한 환경이다.

하지만 근본적인 문제를 해결한 게 아니라 응용 프로그램별로 인위적으로 문제를 피해 가게 한 것일 뿐이기 때문에, 앞으로 또 특이한 프로그램에서는 한글 첫 타와 관련된 문제가 여전히 있을 수 있다.
내가 나름 <날개셋> 편집기라는 에디터까지 다 만들어 봤지만, IME가 아닌 응용 프로그램의 관점에서 어떻게 해야 “첫 타를 그렇게 특이하게 처리하는 프로그램”을 만들 수 있는지를 모른다. 그래서 IME도 그렇게 불완전하게 만들 수밖에 없음을 밝힌다.

3. 윈8 지원은?

그리고 많은 사용자들이 기다리고 있을 Windows 8 환경의 지원에 대해서도 얘기를 하겠다.
결론부터 말하자면 잘 되고 있다.

윈8의 문자 입력 시스템은 이전 버전과 비교했을 때 크게 두 가지가 바뀌었다.
첫째, 스레드 단위로 모든 프로그램이 제각각 서로 다른 입력 언어와 한영 상태를 갖던 전통 관행을 깨고 모든 시스템이 동일한 입력 언어와 입력 상태를 공유하는 옵션이 추가되었다.
둘째, 입력 언어당 한/영 상태 같은 오로지 한 개의 버튼만을 갖는 극단적인 간소화 모드가 추가되었다.
이 두 옵션은 모두 기본적으로 “켜져 있다”.

거기에다 갑자기 무슨 바람이 들었는지 IME의 아이콘들의 배색을 전부 black & white 배색으로 바꿔 버린 건 부가적인 사항이고.

일단 개인적인 평을 말하자면 '둘째'의 경우 왜 지금과 같은 체계로 바꿨는지가 불만이며 좀 이해가 안 간다.
기존의 TSF language bar에도 개념적으로 간소화 모드는 있었다. IME는 도구모음줄에다 버튼들을 등록할 때, 간소화 모드에서도 표시되어야 하는 정말 중요한 아이콘에 대해서는 별도의 옵션 플래그를 주게 할 수 있었다.

그래서 도구모음줄을 우클릭한 뒤 '작업 표시줄에 아이콘 추가' 옵션을 끄면 중요한 아이콘만 표시되는 간소화 모드가 된다. 사실 이건 사용자를 오도하기에 충분할 정도로 말을 굉장히 이상하게 번역해 놓은 것이다.

뭐 아무튼.. 이것만 활용하면 아무 문제가 없을 텐데,
윈8은 또 자체적인 간소화 모드를 구현하기 위해서 IME가 별도의 카테고리 등록을 하고 아이콘을 추가로 등록해야만 하는 등, 굉장히 비생산적이고 번거로운 절차를 추가했다.

그래도 어쩔 수 있나.. 까라면 까야지. 어쨌든 윈8만의 간소화 모드를 지원하게 해서 데스크톱 모드에서 도구모음줄이 나오게 했고, 그리고...

메트로 앱에서 Win+Space로 입력기를 전환하여 <날개셋> 한글 입력기를 구동한 모습 인증샷이다. 올레!
나는 평가판을 쓰고 있어서 그런지, 디지털 서명을 안 해도 동작을 하긴 한다.
윈8 지원이 잘 되면.. 6.72가 아니라 8자에 맞춰서 다음 버전을 그냥 6.8로 올려 버릴 수도 있다.

사실, '메트로'라는 단어는 윈8이 나오기 전에 잠깐 쓰이다가 폐기된 용어이고 현재 MS에서 공식적으로는 Modern UI라고 부른다. 하지만 난 '모던 UI'보다 '메트로'가 훨씬 더 직관적으로 잘 와 닿는데 어떡하지? 마치 notification area vs '시스템 트레이'처럼 윈도우 운영체제에는 공식 명칭과 비공식 명칭이 따로 노는 요소가 몇 가지 더 있다.

전체 화면에서 돌아가고 단축키를 외워야 하는 등, 메트로 앱은 어찌 보면 옛날 도스용 프로그램으로 회귀한 듯한 느낌이다. 단지 도스 시절보다 하드웨어의 성능이 훨씬 더 좋고 앱 프로그래머가 직접 하드웨어를 저수준에서 제어해야 할 필요가 없을 뿐이다.

4. 기타

사소한 사항이지만, 도움말과 UI의 용어를 추가로 좀 교정한 게 있다.
그리고 도구모음줄이 세로로 길쭉한 작업 표시줄에 embed되어 있어서 버튼 아이콘들이 여러 줄에 걸쳐서 나열될 때, 아이콘들이 언제나 순서대로 위에서 아래로 순서대로 잘 표시되게 로직을 개선했다. 이것도 원래는 스펙대로만 만들면 운영체제가 보장을 잘 해 줘야 하는 건데 좀 사소한 잡음이 있었다.

지난 6.7 이래로 6.71의 다음 버전도 실질적인 '새로운 기능의 추가'는 없이 버그 수정, 최신 운영체제 지원, 데이터와 도움말의 개선 같은 변화만 있을 듯하다.

Posted by 사무엘

2012년의 끝을 앞두고 <날개셋> 한글 입력기의 새 버전이 나왔다.
원래 6.8을 계획했으나 그만치 개발은 못 하고 6.71로 마무리 지었다. 여기에는 이번 버전에서 윈도우 8 메트로 UI용 IME를 아직 못 만들었다는 이유가 가장 크게 작용했다. 데스크톱용도 윈도우 8이 제시하는 새로운 규격대로 맞춰진 건 없으며(흑백 아이콘, 새로운 표시 상태 등), 달라진 것도 없다.

MSDN에 개발 관련 정보가 뜨질 않으니 내가 뭘 더 할 수가 없다. “윈도우 8에서는 이런 점이 달라지니까 IME 개발자들은 여기에 대비해야 한다. 더 자세한 스펙은 추후에 게재될 것이다”라고 해 놓고 아직까지 게재가 되지 않고 있다.

1.
그럼에도 불구하고 이번 버전은 나온 시기가 시기인 만큼, 가장 먼저 윈도우 8에 대한 지원이 부분적으로 강화되었다. 사실, 수 년 전에 윈도우 비스타나 7이 나왔을 때도 <날개셋> 한글 입력기는 수차례 해당 최신 OS에서만 발생하는 문제를 해결하느라 패치가 몇 번 나와야 했다. 바뀔 게 없을 것 같은 분야여도 매번 은근히 바뀌는 게 많다.

그래서 이번 버전에서는.. 윈도우 8에서 편집기를 실행해서 제어판을 열고 '외부 모듈 관리'로 갔는데 IME들이 하나도 뜨지 않던 문제를 해결했으며,
편집기에서 빈 입력 스키마(운영체제의 문자 입력 프로그램 사용) 모드로 한글 윈도우 8이 내장하고 있는 옛한글 입력기로 옛한글을 입력하는데 글자가 종종 제대로 입력되지 않고 오동작이 발생하던 문제를 해결했다. <날개셋> 편집기는 자체 입력기와 운영체제 입력기를 모두 잘 수용하는 것을 목표로 하니까 말이다.

윈도우 8의 옛한글 입력기는, 옛날 MS 오피스 200x 시절에 한글판 plus pack이 제공하던 옛한글 입력기와는 동작 방식이 좀 달랐다. 단순히 유니코드 5.2를 지원하는 것 이상으로, 지금까지는 고려할 필요가 없던 특이한 상황에 대한 동작을 요청하는 게 있어서 내 프로그램의 에디팅 엔진을 보강했다. 뭐, 엄밀히 말하면 내 프로그램이 지금까지 TSF 인터페이스를 제대로 구현 못 했던 것이니 말이다.

다만, 3글자를 커버해야 하는데 2글자를 커버하는 것은 정황상 MS IME의 버그로 보인다. 내 프로그램에서 고쳐야 할 부분이 없다. 겉으로 보기만 좀 이상할 뿐 다른 문제는 없으므로 안심해도 됨.

2.
제어판의 GUI가 운영체제의 최신 GUI 요소를 반영하도록 몇몇 군데 개선되었다. 사소하지만 주목할 만한 개선 사항이다. 예를 들어, 제어판은 이미 개념적으로 split 버튼을 사용해 오고 있었는데 운영체제가 제공하는 진짜 split 버튼을 사용하도록 하는 조치가 이제야 취해졌다. split 버튼 자체는 이미 윈도우 비스타에서부터 있었는데도 말이다. 아울러 트리와 리스트의 모양도 좀 더 예뻐졌다.

3.
<날개셋> 편집기는 텍스트 파일을 열 때 유니코드 UTF16/UTF8, 그리고 한글 완성형/조합형 코드에 대해서는 자동 감지를 한다. 그러나 그 외의 인코딩은 자동 감지를 못 하고 사용자로부터 수동 확인을 받는다.

예전까지는 프로그램 실행 직후 자동으로 열리는('이전에 편집하고 있던 문서 기억' 옵션) 파일이나, '파일' 메뉴에 있는 '최근 파일' 명령으로 파일을 열 때도 매번 인코딩 확인 대화상자가 떴다. 그러나 이번 새 버전에서는 자동 감지가 되지 않는 파일을 다시 열 때는, 사용자가 무슨 인코딩으로 열었는지를 기억하게 했다. 중국어나 일본어, 유럽어처럼 한글도 유니코드도 아닌 인코딩으로 파일을 자주 편집하는 사용자에게는 이 조치가 굉장히 편리하게 와 닿을 것이다.

단, 아무 문제 없이 제대로 연 파일에 대해서만 인코딩을 기억한다.
<날개셋> 편집기는 이 프로그램에서 그대로 다시 저장을 했을 때 정보가 손실되는 파일에 대해서는 파일을 연 직후에 경고문을 띄운다. null 문자가 있어서 뒷부분은 모조리 잘렸다거나, 줄바꿈 문자가 일치하지 않는 부분이 있거나, 혹은 인코딩이 잘못 지정되어서 유니코드로 변환이 안 된 코드 바이트들은, 도로 저장할 때 원형이 보존되지 않고 소실되기 때문이다.

불러오는 과정에서 그런 문제가 있었던 파일이라면 사용자가 어차피 인코딩을 잘못 지정했을 가능성이 높으므로, 인코딩을 기억하지 않는 것이 훨씬 더 합리적이다.

4.
예제 데이터에도 변화가 생겼다. 예전 글에서 밝혔듯이, 네벌식이 정식 유형 파일로 들어갔으며, 일명 '강화 세벌식'이라고 불리던 세벌식 무한 낱자 수정 입력 방식 역시 <날개셋> 한글 입력기의 상징적인 기능인 만큼 유형 파일로 승격되었다. 한편, 팥알 님이 고안하신 세벌식 3-2012 글자판이 글쇠배열 파일로 추가되었다.

5.
그리고 끝으로, <날개셋> 타자연습은 크게 두 가지를 개선했는데,
첫째, 게임을 전체 화면에서 실행할 때 점수 숫자가 올라가는 게 뭔가 랙이 걸린 듯이 이상하게 업데이트되던 버그를 고쳤다. CPU 탓인지 GPU 탓인지는 모르겠지만, Core 2 Duo급 컴에서는 문제가 없었는데 i5 이상 되는 더 좋은 컴퓨터에서는 이런 현상이 종종 있었다.
그리고 둘째, 좀 어이없는 버그이고 언제부터 들어갔는지는 모르겠지만, 연습글 분석을 시키자 프로그램이 뻗던 버그를 고쳤다.

입력기와 타자연습을 모두 사용한다면 모두 업데이트를 할 것을 권장한다.
아, 그리고 잊을 뻔 했는데, 두 프로그램 모두 이번에 도움말을 처음부터 끝까지 다 읽어 보면서 내용을 교정하고 싹 고쳤다. 이것도 읽어 보시면 좋을 것이다.

Posted by 사무엘

1.

<날개셋> 한글 입력기는 제어판에서 불러다가 곧장 쓸 수 있는 20여 개의 다양한 예제 입력 방식들을 덩달아 제공하고 있다.
6.7 이후 다음 버전에서는 예제 데이터에 아래와 같은 여러 변화가 생길 예정이다.

- 6.7에서 잘 알다시피 종성 지향 두벌식을 활용하여 'MS 두벌식'이라는 유형 파일이 추가되었는데.. 여기에다가 한글 자모 외의 숫자와 기호는 글쇠를 먹지 않게 하는 입력 스키마 설정도 추가했다. (지난 6.5에서 추가된 글쇠 인식 customize 기능으로) 어차피 시스템의 영문 글자판과 똑같은 글자는 IME가 입력시키는 게 아니라 아예 글쇠 자체를 가로채지 않고 응용 프로그램으로 넘겨 준다는 뜻.
이것까지 갖춰 주면 진짜 MS IME와 고증이 100% 일치하게 된다. 특히 외부 모듈에서 말이다.

- 네벌식이 글쇠배열 *.key이 아니라 오토마타와 낱자 결합 규칙을 갖춘 유형(*.ist) 파일로 승격되었다.
받침을 입력하려면 모음을 아무 모음이나 써도 되는 게 아니라 타자기 설계 차원에서 받침용으로 의도된 모음을 써야만 하며, 그렇지 않으면 받침은 다음 글자로 튕긴다.

모음의 용도를 구분하는 건 다양한 방법으로 할 수 있다. 비받침용 모음은 0으로 대응하는 가상 받침을 같이 입력되게 하여 여타 받침과의 결합을 차단시킬 수도 있는데, 본인의 경우 두벌식 모음과 세벌식 모음으로 구분하여 오토마타가 O 변수를 써서 구분하도록 하는 방법을 썼다.

이 외에도 네벌식 오토마타는 초+중(+종)과 중+종은 허용하지만, 초에서 바로 종은 허용하지 않게 설계되어 있다. 97 이전의 도스용 아래아한글이 이런 오토마타를 갖추고 있었다. 또한 ㅒ, ㅖ가 바로 입력 가능하지 않다는 특성상 ㅑ+ㅣ, ㅕ+ㅣ로 해당 모음을 입력할 수 있게 했다.

네벌식은 그나마 옛날 타자기 표준이라는 역사적인 의미가 있고, <날개셋> 기능 활용면에서 의미가 있어서 추가했을 뿐, 타자 관점에서 효율적인 입력 방식은 절대로 아니다. 특히 공 병우 세벌식에 비하면 이런 허접하고 불편한 타자기로 한글 입력을 해야 했을 옛날 타자수들을 생각하면 그저 안구에 습기가 찰 뿐이다.

- 일명 '한소프트 세벌식'과, '드보락 호환 두벌식' 글쇠배열은 효용성이 떨어진다고 판단하여 삭제했다.
특별히 '한소프트 세벌식'에 대해 보충 설명을 하자면, 정체가 불분명하고 원문 자료를 제공하던 사이트도 운영이 중단되어 접속이 불통된 지가 이미 수 년이 지난 상태이다. 글쇠배열도 어차피 그리 잘 만들어진 것도 아닌지라 퇴출을 결정했다. 특히 숫자를 저렇게 Shift를 누른 채 양손으로 입력하게 해 놓으면 도대체 어쩌라는 건지? -_-

2.

현재 '세벌식 순아래' 글쇠배열이라는 게 있어서 예제 파일도 아니고 아예 프로그램에 내장되어 있는 배열 중 하나이다.
그러나 이것은 장기적으로는 *.key 급으로 격하될 예정이다. 내장 데이터로 쳐 주기에는 너무 듣보잡화해 있기 때문이다.

공 병우 박사의 이념을 물려받은 권위와 정통성 있는 세벌식 연구 기관에서--한글 문화원이라든가, 한글 문화원이라든가...-- 앞으로 390과 최종을 통합하는 새로운 세벌식 표준안을 제정한다면, 그 새 배열이 지금 순아래가 있던 자리를 대체하게 될 것이다.

그리고 그 통합안은 더 장기적으로는 390을 또 대체하게 될 수도 있다. 과거에 390이 389를 대체했듯이 말이다.
통합안은 기호 문제 때문에 최종보다는 390에 훨씬 더 가깝게 만들어질 것이다.
그 반면 2000년대부터 세벌식을 접한 사람들은 390보다는 최종이 더 많다. 본인도 최종 사용자.
최종은 27개 겹받침 모두 수록이라는 궁극의 아킬레스건이 있기 때문에 상징적인 의미가 크며, 통합안이 나온 뒤에도 별도로 존속할 가능성이 높다.

이런 이유로 인해, 기존 390 사용자들만 통합안으로 갈아타면, 최종과는 달리 390은 존재의 의미를 상실하여 역사 속으로 사라지게 될 것이다. 이것이 나의 짧은 생각이다.

3.

내 프로그램에는 역사적으로나 설계 방식면에서 의미가 있는 세벌식 글쇠배열 몇 개가 key 파일로 제공되고 있다. 세벌식 389는 받침 배열이 390과 최종의 짬뽕 같으면서도 숫자가 노트북 PC의 키패드 배열과 일치한다는 특징이 있으며, '송 영상'(닉: 길동무)이라는 분이 고안한 영상 세벌식은 세벌식계의 떡밥인 왼쪽부터 시작하는 세벌식을 나름 독창적으로 구현한 배열이다.

누가 만들었는지 모를 왼손/오른손 세벌식은 no shift로도 모자라서 진짜 말 그대로 한 손으로 타자를 치는 것에 특화되어 있다. 내가 알기로 영문 드보락 자판에도 이런 왼손/오른손 변종 배열이 있다. 아마 옛날에 도스용 에디터 같은 데서 이것저것 수집한 자료이지 싶다.

이런 것들은 역사적인 의미 외에 실용적으로 쓰일 가능성이 높지 않으며, 오토마타나 낱자 결합 규칙 같은 것도 그냥 일반적인 PC용 한글 입력기의 설정을 그대로 가져와 쓰는 것만으로도 충분하기 때문에, 유형 파일이 아니라 글쇠배열 형태로만 간단히 제공된다.

4.

현재 프로그램이 기본 제공하는 예제 입력 방식이 20여 개가 있다지만, 파일 하나가 겨우 몇백~몇천 바이트밖에 하지 않으니, 다 합쳐도 크기는 3만 바이트가 채 되지 않는다.
본인은 <날개셋> 한글 입력기의 사용자가 만든 UCC..는 아니고 UCI (user-created input methods) 데이터를 받는다.
마음에 드는 건 프로그램의 다음 버전에다 같이 수록도 흔쾌히 해 줄 것이다. 사실은, 이런 데이터만 공유하는 커뮤니티가 좀 있으면 좋겠다.

선정 기준은 다음과 같다. 하나 이상을 잘 만족하면 된다.

- 아이디어가 기술적으로 독창적일 것: 복벌식이나 신세벌식 같은 것. 이런 식으로 <날개셋>의 조건부 수식과 오토마타, 가상 낱자, 더 나아가 특수 글쇠 따위를 잘 활용하여 두벌식과 세벌식 사이를 왔다 갔다 하는 독창적이고 기발한 한글 입력 방식은 얼마든지 웰컴이다. 수록 0순위임. 다만 한 아이디어 당 한 개, 많아야 두 개로 국한임.

- 역사적 가치가 있거나, 인지도· 권위가 있을 것: 역사성이라 함은 앞서 언급했던 여러 legacy 세벌식 글쇠배열 말이다. 아니면 다수가 쓰거나 명목상의 표준이기라도 해야 한다.
북한 국규 표준은 나름 그쪽에서 권위를 가지고 통용되는 입력 방식이니, 통일을 대비해서라도 예전에 key로만 제공되던 것을 최근에 완전한 유형 형태로 격상했다. 아래아한글 97과 맥 OS, MS 두벌식 같은 기존 메이저 소프트웨어가 미묘하게나마 차이가 존재하는--그것도 오토마타 차원에서!-- 독창적인 한글 입력 방식을 제공하는 것도 바람직한 일이다.

휴대전화용 3대 표준 입력 방식(천지인, 이지한글, SKY-II)은 기술적 독창성과 권위를 모두 갖추고 있으니 두 말할 나위도 없이 수록이다. 사실 이것들을 포인팅 장비로 써 볼 수 있는 보조 입력 도구(패드)도 만들어야 하는데, 아직 6.7에서는 숙원을 못 풀었다.

- 타자 행동 관점에서 아주 효율적이거나 독창적일 것: 모바일용 입력 방식은 워낙 기술적인 메커니즘이 많은 반면, PC용 입력 방식은 딱히 그런 trick은 없이 그냥 글쇠배열 논쟁으로 흐르는 경향이 있다.
역사적인 뿌리나 인지도가 없고 그렇다고 기술적인 독창성도 없는 마이너 글쇠배열이 <날개셋>의 예제로 등재되기 위해서는 진짜 타자 효율이라도 압도적으로 좋다는 증거가 있어야 한다. 그게 아니면 순아래/한손 배열처럼 장애인 접근성 분야라도 파든가.

'영상 세벌식'은 타자 능률까지는 모르겠지만 왼쪽에서 오른쪽으로 흐르는 세벌식이라는 점이 독창성을 인정받아 예제 데이터로 수록되어 있다. 앞서 말한 기술적인 독창성 말고, 배열 자체가 독창적이라는 뜻이다.

- 한글 입력과 관련된 실생활에서 유용할 것: <날개셋> 한글 입력기는 기본적으로 한글 입력에 특화되어 있기 때문에 예제 데이터도 한글 입력 방식을 우대함을 원칙으로 한다. 한글이 아닌 문자는 한국 문화권에서 한글과 같이 즐겨 쓰이는 문자들로 국한한다.

가령, 일본어 문자는 아무래도 아랍· 태국-_- 문자보다야 한국에서 더 친숙하며, <날개셋> 고급 입력기의 사용자 정의 조합 기능을 이용해서 간단히 커버 가능한 예이기 때문에 히라가나와 가타카나가 모두 수록되어 있다. 구결도 마찬가로 국어 정보학 분야에서 유용하기 때문에 수록이다.
콜맥 글자판은 한글 입력과 관계가 없는 영문이지만, 드보락 다음으로 나름 인지도가 있는 마이너 배열인지라 영문 배열은 딱 하나만 선택해서 넣었다.

이상으로 내가 예제 입력 데이터를 선별하여 수록하는 대원칙을 공지했다.
저런 조건 중 하나 이상을 만족하고 기존 예제들과도 완전히 다른 입력 방식이 과연 얼마나 있을지는 잘 모르겠지만, 내 프로그램을 통해 여러 창의적인 한글 입력 방식이 많이 만들어지고 쓰이면 좋겠다.

<날개셋> 한글 입력기는 한글 입력과 관련된 그런 지적 재산들을 모두 구현하고 관리할 수 있는 프로그램이니 말이다.
그런 기반을 마련하기 위해 초창기엔 가장 엄밀한 극단이라 할 수 있는 공 병우 세벌식부터 추구한 뒤, 점차 더 generic한 쪽으로 내려오고 있는 중이다.

여담이지만, '한글 로마자 입력 방식'처럼, 그 자체가 한 입력 방식이 아니라 특정 포괄적인 아이디어 하에서 세부적으로 다양한 입력 방식이 파생되어 나올 수 있다면, 그건 유형 파일이 아니라 아예 별도의 '빠른설정'이라는 플러그 인 프로그램이 담당하게 된다.

Posted by 사무엘

지난 8월말에 잘 알다시피 <날개셋> 한글 입력기 6.7이 완성되고 공개됐다. 내가 만들었지만 나 자신도 잘 쓰고 있다. 의미심장한 중요한 기능들이 많이 추가되어 아주 만족스럽다.

프로그램의 한 버전이 완성된 후, 조금 시간이 흐르면 버그 수정이나 새로운 아이디어 구현, 기능 추가를 위해서 결국 프로그램 소스를 또 건드리게 되고, 내가 쓰는 개발 중간 버전과 직전 완성 버전 사이에는 차이가 생기게 된다. 그 첫 차이가 생기기까지 걸리는 시간은 생각보다 길지 않다.

이번 6.7도 그 점에서는 예외가 아니다. 벌써 다음 버전 작업이 시작되었다. 프로그램 내부의 버그가 발견되었거나 새로운 기능이 떠오른 건 아니고, 단지 운영체제의 특성과 관련된 enhancement가 불가피하게 생기게 됐다. 그 내역은 다음과 같다.

1. 테마가 적용된 옅은 파랑 선택막대

<날개셋> 한글 입력기의 외부 모듈에서 한자 선택 UI를 꺼내면 외형이 윈도우 7 기준으로 지금까지(up to 6.7)는 왼쪽과 같았다. 그렇던 것을 다음 버전부터는 오른쪽처럼 나오게 수정했다.

highlight 색상이 너무 옅었던 것을 좀 더 진하게 하고, 아이템의 크기를 약간 더 키웠다. 예전보다 보기가 훨씬 더 좋아졌다. 크기를 약간 키웠는데도 MS IME의 목록이 <날개셋>의 그것보다 여전히 더 크다.

잘 알다시피 MS에서는 소프트웨어의 GUI에서 highlight된 항목을 표시하는 방법을 슬금슬금 교체해 오고 있다.
전통적인 방법은 파란 바탕 solid color에다가 하양 글씨였다. 그 이름도 유명한 GetSysColor(COLOR_HIGHLIGHT) 말이다. 아니면, 컨텐츠 자체에 여러 색깔이 서식 형태로 들어갈 수 있는 워드 프로세서 같은 곳에서 블록 같은 걸 표시하는 방법은 흰 바탕을 검정으로 바꾸는 XOR 반전색이 통용되어 왔다.

그러나 요즘 MS에서 밀고 있는 방법은 배경에다 그냥 옅은 파랑을 씌우는 것이다. 이 기법의 원조는 사실 MS 오피스 2000의 '엑셀'로 생각보다 오래 됐지만, 워드에서까지 블록이 전통적인 반전색 대신 옅은 파랑으로  표시되기 시작한 건 오피스 2007부터이다.

윈도우 XP부터는 리스트 컨트롤에서 드래그 사각형을 점선 사각형 대신 옅은 파랑으로 대체하는 LVS_EX_DOUBLEBUFFER 스타일을 도입하였으며, 비스타부터는 메뉴와 운영체제의 공용 컨트롤(리스트 뷰, 트리)에서 선택 막대까지 반전색 대신 알록달록 옅은 파랑 그러데이션이 도입되었다.

그리고 이 테마 색상은 운영체제의 시스템 색상의 영향을 받지 않는다.
Aero를 사용 중일 때에는 잘 알다시피 GPU가 합성해 내는 glass 프레임의 색깔만 바꿀 수 있지, 기존 시스템 색상은 바뀌지 않는다. 어찌 보면 시스템 색상도 점점 과거의 유물처럼 돼 간다는 뜻 되겠다.

그런데 본인은 그 옅은 파랑이 윈도우 비스타나 7이나 동일한 줄로 지금까지 알고 있었는데, 그렇지 않다. 똑같은 Aero 기반이지만 비스타가 약~간 더 옥색에 가까웠고 7이 좀 더 파래졌다.

또한 그 색상도 알고 보면 짙고 옅은 구분이 존재한다. 7은 옅은 색과 짙은 색의 차이가 비스타 시절보다 더 커졌다(위 그림에서 왼쪽의 상하 한 쌍이 비스타 것,, 오른쪽의 한 쌍은 7 것). 그래서 이를 조정함으로써 이제는 비스타와 7에서 모두 보기 좋은 색상이 나오게 되었다. 지금까지 사용하던 채색 방법은 비스타에서는 어차피 별 차이가 없던 반면, 7에서는 너무 옅게 나온다는 문제가 있었다.

2. 윈도우 8 지원

시기가 시기인 만큼 <날개셋> 한글 입력기의 다음 버전은 여건이 허락하는 한 윈도우 8의 지원 강화가 계획되어 있다.
<날개셋>은 지금까지 윈도우 2000에서 발생하는 특수한 문제 해결(아직 윈98이 대세이던 시절), 외부 모듈 첫 개발, 64비트 지원 등 외부적인 큰 환경 변화를 몇 차례 대면했었는데, 윈도우 8 지원도 상당히 도전적인 과업이 될 것 같다.

우선, 윈도우 8을 접한 소감부터 좀 말하자면, 이제 얘들은 XP, 비스타 같은 이름을 일일이 짓기가 귀찮아졌는지, 연도도 아니고 숫자를 버전과 아무 관계 없는 브랜드명으로 쓰기로 작정을 한 모양이다. 윈8의 내부 버전은 6.2이다. (비스타가 6.0, 7은 6.1)

GUI가 동글동글하던 것이 전반적으로 다시 각진 컨셉으로 바뀌고, 그러데이션이 단색(solid color)으로 바뀌는 등, 좀 더 검소해지고 단순해졌다(simplify). 의외이다.

컴덕후라면 이미 익히 알듯이 데스크톱 모드에 이어 메트로 모드라는 게 생겼으며, 메트로 모드는 확실히 과거와의 호환성을 버리고 좀 더 '새끈하고' 스마트폰 앱과 더 친화적인 응용 프로그램 환경을 추구한 듯하다.
근데 데스크톱 모드에 도대체 시작 버튼을 무슨 생각으로 없애 버렸는지는 잘 모르겠다.

윈8에서는 문자 입력기 쪽 인터페이스가 완전히 바뀌는 바람에 기존 한글 IME들은 메트로 모드에서는 동작하지 않으며, 데스크톱 모드에서도 기존 IME 도구모음줄(language bar)가 누락된 채 거의 반쪽짜리 상태로 동작한다. 특히 메트로 모드에서 동작하려면 IME 프로그램이 반드시 디지털 서명이 돼 있어야 한다고 그런다.

무엇보다 심각한 문제는, 기존 API로는 운영체제에 설치되어 있는 IME 프로그램들이 전혀 조회가 되지 않는다는 점이다. 또한 상태 표시 아이콘 쪽도 알다시피 크게 바뀌었기 때문에 이에 대한 대처를 하려면 적지 않은 시간과 수고가 필요할 것 같다.

세벌식 파워업은 수동으로 두벌/세벌 전환을 한번 해 준 뒤에 돌리면 자동 글자판 전환이 다행히 잘 된다. 그러나 IME 설정 대화상자를 꺼내기가 굉장히 불편해졌는데(일일이 제어판으로 들어가야 함. 예전처럼 우클릭만으로 되지 않는다) IME 설정 대화상자를 곧바로 꺼내는 기능이 동작하지 않기 때문에 이에 대한 패치는 해야겠다.

이렇듯, 프로그램 자체의 기능과는 전혀 무관하게 프로그램을 또 고쳐야 할 부분이 몇 군데 생겼다. 그러나 이번 6.7은 그것만 빼면 현재까지는 여전히 버그가 발견된 게 없고 최고의 완성도로 만들어져 있다..

참고로 윈8은 명령 프롬프트에서 '다다.' 글자가 덧나는 버그는 고쳐져 있었다. 그리고 모든 프로세스에서 사용 중인 IME의 종류와 상태가 한데 공유된다! IME가 각 프로세스의 스레드별로 따로 기어들어가는 게 아니라, 별도의 전용 프로세스를 통해 IPC를 써서 응용 프로그램들과 소통하는 것 같다!

※ 여담

- 난 내 컴퓨터로 서식이 없는 글을 쓸 때 무슨 프로그램을 써서 할지가 고민된다.
일단 윈도우에서는 내가 만든 <날개셋> 편집기가 심리적으로 마치 우리집 안방에 있는 것 같은 편안함과 가벼움을 선사한다. 정다운(?) 비트맵 글꼴과 화려하기 그지없는 고급 입력 기능들을 그대로 쓸 수 있으니 이것도 좋다.

한편, 맥 OS의 텍스트 편집기는 비록 한글 입력기의 자유도는 뒤쳐지는 반면, 찍히는 글꼴의 품질이 윈도우와는 넘사벽급으로 차이가 나고 너무 우수하니 이 또한 글 쓰는 즐거움을 선사하는 요인이다.
두 장점을 하나로 합치려면 결국 <날개셋> 한글 입력기가 맥용으로도 나와야 할 텐데 말이다.;;

- 요즘 모바일용 입력 방식 중에는 그냥 버튼을 눌렀다 떼는 게 아니라 특정 제스처를 취했을 때 초성과 중성이 동시에 입력되게 되어 있는 한글 입력 방식이 있다. 이런 로직을 <날개셋> 한글 입력기로 구현하는 건 일도 아니다. 날개셋문자는 애초에 여러 낱자를 한꺼번에 배당을 할 수 있는 구조이기 때문이다. 그걸 글쇠 수가 충분한 편인 PC 키보드에서는 잘 활용을 안 할 뿐.

'가'를 ㄱ+ㅏ로 입력했을 때와 한꺼번에 입력했을 때 종성의 조합 여부를 달리 지정하는 것도 가능하다. 오토마타가 통상 A ? 1: B ? .. 같은 식으로 지정되어 있는 것을 A && B ? 라고 하여 동시 입력 여부에 대한 상태 분기도 직접 지정하면 되기 때문이다. 어지간한 변칙적인 한글 입력 방식에 대한 대비는 <날개셋>이 다 해 놓고 있다.

그렇기 때문에 본인은 어떤 새로운 한글 입력 방식이 있으면 그게 손이 편하냐, 빨리 칠 수 있냐 하는 것보다는 그 입력 방식을 구성하는 기본 동작과 로직이 어떠한지를 보는 편이다. 그게 나의 연구 주제이기 때문이다.

- <날개셋> 한글 입력기의 다음 버전은 6.x대의 마지막 버전이 될 것이다. 이 글에서 언급된 이슈 말고 또 무슨 변화가 생길지는 아직 미지수이다.

그런데 개인적으로 난 윈8은 너무 급격한 변화들 때문에 비스타 꼴 날 것 같은 생각이 든다. -_-;; 왜 자꾸 익숙한 UI를 쓸데없이 바꾸고, 게다가 보안을 빌미로 응용 프로그램 실행엔 번거로운 제약만 자꾸 추가하는지 모르겠다. 2000/ME와 비스타가 망하고 XP와 7이 무진장 장수했는데, 8은 아무래도 오른쪽보다는 왼쪽 계열로 갈 것 같다.

Posted by 사무엘

오랜만에 <날개셋> 한글 입력기의 새 버전 소식을 전하게 된 것을 기쁘게 생각한다.
6.51 다음으로 6.7! 나의 대학원 석사 졸업 기념작이다.
나의 대학 학부 졸업 기념작은 까마득한 옛날인 2005년 여름에 나온 3.41이고,
4년 전 여름에 나온 5.0은 병특 만료 기념작이다.
작년에 6.2가 나온 뒤 거의 정확히 1년 만에 버전이 0.5만치 올라가게 되었다.

이번 버전은 비주얼 C++ 2010으로 개발된 첫 버전이다. 5.5부터 지난 6.51까지는 약 3년 동안 2008로 개발됐다.
더 옛날의 2.5부터 5.31까지는 거의 6년 동안 2003을 썼고 말이다. 그에 반해 VC++ 2005는 처음에 64비트 에디션을 빌드할 때만 잠깐 썼고 그다지 즐겨 사용되지 않았다.

버전 번호에 7이라는 숫자가 들어가는 것은 지난 12년간의 <날개셋> 한글 입력기의 개발 역사상 최초이다. 물론 6.x를 졸업하고 아예 메이저 버전이 7로 진입할 날도 얼마 안 남았고 말이다.
6.7은 여느 역대 버전들과 마찬가지로 다방면의 기능 추가와 개선을 거쳤다. 하지만 이번에도 시간과 여유의 부족으로 인해 원하는 기능, 넣고 싶었던 기능들을 모두 충분히 넣지 못했다. 그렇기 때문에 6.7까지는 안 하고 6.65, 심지어 6.66-_-으로 번호를 정하는 것도 이론적으로 충분히 가능하나, 국민 정서를 감안하여 그러지는 않았다.

한동안 <날개셋> 한글 입력기의 API에 큰 변화가 없었기 때문에 타자연습 3.3은 입력기 6.2부터 6.51까지 API 호환이 지켜졌으나, 이번 6.7에서는 클래스 가상 함수 한 군데의 프로토타입이 바뀌는 바람에 정말 어쩔 수 없이 API 호환이 깨지게 되었다.

타자연습은 1년 전이나 지금이나 바뀐 건 없고, 입력기 6.7의 API를 기준으로 재빌드한 프로그램만 다시 올렸다.
물론, 이제는 API 호환이 안 되는 버전의 <날개셋> 입력기 외부 모듈과 타자연습이 서로 같이 실행되어도 충돌이 없기 때문에, 굳이 타자연습에서 입력기 6.7에 새로 추가된 기능을 꼭 써서 타자 연습을 해야 할 분이 아니라면, 이미 설치된 타자연습 3.3을 또 재설치해야 할 필요는 없다.

이번 6.7에서 내세울 만한 변화는 다음과 같다.

1. 편집기의 에디팅 엔진 최적화

비록 눈에 당장 차이가 느껴지지는 않는 변화이긴 하나, 새 버전에서는 에디팅 엔진의 최적화가 최후 종결자 지점에 이르렀다.
텍스트의 여러 군데가 동시다발적으로 바뀌어서 구간별로 어디는 다시 그려져야 하고, 어디는 단순히 위로 몇 줄 스크롤하면 되고, 더 아랫부분은 반대로 아래로 스크롤되어야 할 때... O(n^2) 복잡도까지 감수하면서 구간별로 모든 가짓수를 100% 정확하게 파악하여 동작하게 했다. (물론, n이 너무 커지면 골치 아프게 그런 것 따질 필요 없이 그냥 화면 전체를 다시 그려 버리면 된다)

예전에는 그냥 최악의 상황을 가정하고 무조건 화면을 다시 그리게 하던 것이 지난 6.2 버전이던가 그때쯤에 크게 개선되었다. 그러나 그것도 동작이 지금 정도로 정교하지는 못했으며, 나중에 다시 생각해 보니 논리 자체에도 원천적으로 결함이 있어서 아주 특수한 상황에서는 여전히 화면 잔상이 남는 버그까지 있었다.

그 점이 찝찝했었는데 이번 버전에서는 드디어 작정하고 매달린 끝에 완전히 끝장을 내고 말았다. 만세! 새로운 기능 구현도, 단순 리팩터링도 아니고 최적화 작업을 끝냈을 때의 홀가분한 기분은 직접 구현해 본 사람만이 느낄 수 있을 것이다. 역시 좋은 프로그래머란, 모든 경우의 수를 논리적으로 잘 따지는 사람임을 느꼈다.

텍스트 에디터를 만들면서 이런 식으로 구간과 구간 사이의 여러 변화들을 한데 합성하는 알고리즘을 구현하는 게 굉장히 힘들었다. <날개셋> 편집기는 한글에만 초점을 맞추려고 complex script는커녕 글씨 크기 변경도 안 되고 가변폭 글꼴조차 지원 안 하는 아주 제한된 에디팅 엔진을 의도적으로 고수하고 있지만, 그 정도를 만드는 데도 지금까지 의외로 복잡하고 어려운 알고리즘이 제법 들어갔다. undo/redo를 관리하는 것도 그렇고.

2. 한글 입력 오토마타 차원에서의 기능 추가

이 달 초에 블로그 글을 통해 먼저 소개한 바 있는 종성 지향 두벌식은, 예전에는 없던 완전히 새로운 개념이 추가된 것이다. 같은 두벌식이라도 음절 경계에서 자음을 초성으로 볼 것인가, 종성으로 볼 것인가 하는 것을 이제 사용자가 직접 지정하는 것은, 한글 입력 전문 프로그램으로서 매우 중요한 기능이 아닐 수 없다.
종성 지향 두벌식과 맞물려 돌아가는 BKSP 옵션, 특수 키, 타수 복원 알고리즘 등등도 다 일관성 있게 동작하도록 로직의 수정과 보강이 이뤄졌음은 두 말할 나위가 없다.

그리고 오토마타에서는 현재 입력된 날개셋문자가 두벌식인지(종성 지향 포함) 세벌식인지를 나타내는 변수를 추가하여, 한 오토마타가 벌식에 따라 다르게 동작할 수도 있게 했다.

사실 이 두 기능은 내 학위 논문에도 들어가야 했을 아이디어인데 논문 학기가 다 끝난 뒤에야 생각이 나고 구현된 것이 좀 아쉽다. ^^;;

3. 단어 단위 한자 변환

<날개셋> 한글 입력기의 아주 오랜 숙원이 이번 버전에서 드디어 부분적으로나마 성취되었다. 만세!
드디어 '대한민국'에서 '국'을 조합 중이거나 '국'의 뒤에다 커서를 두고 한자 키를 누르면 단어를 한꺼번에 大韓民國로 바꿀 수 있다. 그리고 한자를 한글로 바꾸는 것도 최대 12글자까지 한꺼번에 할 수 있다.

이렇게 하기 위해서는 제어판의 '편집기 계층'에서 '단어 단위 한자 변환' 옵션을 켜 주면 된다. 그리고 이 기능은 아무데서나 쓸 수 있는 건 아니고, 자체 편집기나 TSF A급 프로그램(워드패드, MS 워드 등 몇몇)에서만 가능하다.

단, 이것은 아주 초보적인 수준으로만 구현된 것이기 때문에 한계도 적지 않다.
커서 바로 앞까지 끝나는 범위의 단어만 한자로 바꿀 수 있으며, 글자가 아닌 단어 영역에 대해서 블록 같은 시각적인 피드백이 없다.

그리고 이 단어 사전은 <날개셋> 한글 입력기가 자체적으로 갖추고 있는 게 아니다. MS 한글 IME의 한자 사전을 빌려다 써서 동작한다. 그래서 내 프로그램으로 단어 단위 한자 변환을 하려면 윈도우 비스타/7의 한글 IME가 설치되어야 있어야 한다. 자체 사전이 아니므로 사용자 사전 등록 기능 같은 것도 없다.

이번 버전은 그냥 최소한의 노력으로 <날개셋> 한글 입력기도 이제 제한적으로나마 단어 단위 한자 변환이 가능하다는 걸 맛만 보여 준다는 데 의미가 있다. 그러나 이렇게만 해도 정말 신기하기 그지없다.

4. 그 밖의 사소한 변화들

- <날개셋> 한글 입력기의 외부 모듈은 설치하여 구동하고 나면 language bar에 예닐곱 개의 아이콘들이 주렁주렁 달리는 편이었는데, 이번 버전부터는 잉여력이 꽤 강한 전/반각 모드, 텍스트 필터(극소수의 TSF A급 프로그램에서만 사용 가능), 문자표는 제외하고 기본적으로 4개의 아이콘(한/영, 한자, 제어판, 보조 입력 도구)만 표시되게 바꿨다. 나머지 아이콘들은 별도의 명령을 내려서 사용자가 표시하도록 해야 표시된다.

이렇게 하니까 훨~씬 깔끔하고 좋다. 외부 모듈이 개발된 지도 벌써 7~8년째인데 왜 지금까지 이렇게 정리를 할 생각을 안 했나 모르겠다.

- 그리고 <날개셋> 편집기에서 외부 모듈을 사용하면서 편집기의 도구-옵션 명령으로 프로그램의 GUI 언어를 변경한 경우, 외부 모듈의 도구모음줄 아이콘의 툴팁이나 명칭도 해당 언어로 바뀌게 했다. 크게 의미 있는 변화는 아니지만 프로그램간의 일체성을 향상시킨 조치이다.

- 외부 모듈의 한자 변환 후보 선택 중에 Ctrl+C를 누르면 선택된 한자를 클립보드에다 복사가 되게 했고, Shift+엔터/번호를 누르면 한(韓) 형태로, 그리고 Ctrl+엔터/번호를 누르면 韓(한) 형태로 삽입이 되게 했다. 저 기능도 언젠가 넣어야 할 필요를 느끼고 있었는데 이렇게 하는 게 제일 좋을 것 같다.
필요는 발명을 낳는 법. 단어 단위 한자 변환과 연계하면 더욱 편리해진다. '대한민국(大韓民國)' 같은 문구를 한번에 바로 삽입할 수 있으니 말이다.

- '한글을 소리 나는 대로' 필터가 받침 ㄷ계열(ㄷ, ㅅ, ㅌ 등)+ㄹ을 지금까지 ㄹㄹ로 동화시키고 있었는데 이를 ㄴㄴ 계열로 수정했다. 그런데 한국어에서 저렇게 동화가 일어나는 경우가 전혀에 가깝게 없기 때문에 <날개셋> 3.0 이래로 이에 대한 문제를 제기할 일이 없었다.

- '한글 낱자 종류 변환' 필터에 호환용 한글 자모 4개 나열로부터 표준 한글 자모나 한글 글자마디를 만드는 변환 기능을 추가했다. 이것은 우리나라 표준 문자 코드에 명시되어 있는 스펙이기 때문에 도입했다. (거의 사문 전락 수준이 아닌가 의심되긴 하지만.)

- 굳이 나열하기에도 구차한 여러 버그 수정들은 덤. 사용자는 거의 접할 일이 없겠지만.
- 그리고 이번 버전부터 후원 안내문이 프로그램 설치 화면과 도움말 구석에 추가되었다.

5. 제공 자료들

새로 추가된 한글 입력 기능을 활용하여 두벌/세벌 판별 변수를 활용한 복벌식용 모아치기 오토마타, 그리고 맥 OS의 세벌식 자판이 예제로 추가되었다. 종성 지향 두벌식을 사용하여 고증을 100% 살린 MS 두벌식도 예제로 제공된다.
그리고 6.7의 새로운 기능으로만 가능한 건 아니지만, 아래아한글 97이 과거에 제공하던 세벌식 semi-모아치기 오토마타도 예제로 추가했다.

아래아한글 97을 기억하시는가? 아래아한글 2.0 기반의 에디팅 엔진과 3.0 기반의 파일 포맷, 그리고 한컴 2바이트 코드를 사용하던 마지막 버전임과 동시에, 당대로서는 가장 완성도가 높았고 1990년대 말과 2000년대 중반까지 전국적인 사랑을 받았던 명작 워드 프로세서이다.

그 아래아한글 97은 세벌식 글자판에서 우리나라의 소프트웨어 역사상 전무후무한 한글 입력 로직을 갖고 있었다.
초성만 가장 먼저 입력한 뒤엔, 그 후의 중성과 종성은 아무 순서대로나 입력하면 된다. 아래아한글 97의 오토마타를 <날개셋> 식으로 기술해 보면 다음과 같은데...

0 → A ? 1 : B|C ? 2 : 0
1 → A ? 1 : B|C ? 2 : 0
2 → B|C ? 2 : 0

수식이 정말 심하게 단순하다!
<날개셋>의 표준 모아치기 오토마타는 초성을 나중에 뒤늦게 입력하는 경우를 고려하는 것도 있기 때문에 0부터 3까지 4상태이다. 그러나 아래아한글은 초성 아니면 중성/종성으로만 딱 칼같이 나눠서 겨우 3상태이고 수식도 더 간결하다.
거기에다가 아래아한글의 전통인 조건부 / 키만(초성 입력 직후에만 ㅗ, 나머지 상황엔 / 그대로) 수식으로 넣어 주면 100% 정확한 아래아한글 스타일 세벌식이 완성된다.

Mac OS의 세벌식에 이어 아래아한글 97의 세벌식 입력 오토마타를 구현해 보니 스스로 생각해 봐도 재미있다. 다 똑같은 한글 입력 방식 같아도 실제로는 100% 똑같지가 않다.

내가 예전 글에서 썼듯이, <날개셋> 한글 입력기는 그야말로 한글 덕후들의 지적 욕구를 충족할 수 있는 프로그램, 한글 덕후의 마음의 고향 같은 프로그램을 표방하며 개발되고 있다. 그리고 이번 6.7은 그 이상향에 더욱 근접했다고 볼 수 있으며, 글을 다 써 놓고 보니까 마음이 바뀌는 듯. 이 정도면 6.51에서 6.7로 충분히 버전을 올릴 만도 하다는 생각이 든다. ^^

Posted by 사무엘

<날개셋> 한글 입력기를 오래 써 본 분들은 아미 아시겠지만, 이 프로그램에서 두벌식 글자판의 자음 글쇠는 내부적으로 다음과 같은 수식으로 표현된다.

T<=1 ? 초성: 종성

그래서 ㄱ을 예로 들면,

T<=1 ? H2|G_: H2|_G

그 반면, 세벌식 글쇠는 간단하게 해당 자모 하나로 끝이다.

H3|G_ (초성 ㄱ) 아니면
H3|_G (종성 ㄱ)

H3은 세벌식 자모를, 그리고 H2는 두벌식 자모를 뜻하는 날개셋문자 접두사이다. G는 ㄱ을 뜻한다. 다만 알파벳 한 글자만 있으면 변수와 구분이 되지 않기 때문에 부득이 뒤에 _가 추가되었다.

종성은 앞에 _를 추가하는 것으로 초성 명칭과 구분한다. 그리고 이렇게 하는 것만으로 명칭의 길이가 두 글자를 넘어섰으므로 뒤에 별도로 또 _를 추가하지는 않는다. <날개셋> 한글 입력기의 헤비 유저라면 이 정도 수식은 이미 다 익숙할 것이다.

두벌식에서 번거롭게 수식이 추가된 이유는 한 글쇠가 상황에 따라 초성 역할도 하고 종성 역할도 해야 하기 때문이다. 오토마타에서 1번 상태는 통상 초성을 첫 입력받은 상태이기 때문에 그때까지는 ㄱ을 초성으로 내보내고, 중성이나 종성이 입력된 뒤부터는 종성으로 내보내라는 뜻이다. 한 마디로 말해 두벌식 타자기에 존재하던 ‘받침’ 글쇠를 이 수식이 담당한다고 생각하면 된다.

세벌식이 아닌 두벌식 자모는 종성을 처리할 때 세벌식 자모에 비해 다음과 같은 두 가지 추가 작업이 행해진다. 두벌식 글자판에서 한글이 입력되는 과정을 생각해 보면 자명한 것들이다.

두벌식을 세벌식에다가 추가적인 처리를 덤으로 하는 관점에서 한글 입력기를 설계하면 대체로 이런 식의 구현체가 나온다. <날개셋> 한글 입력기도 그렇고 아래아한글도 그렇고, 심지어 맥 OS의 한글 입력기도 그러하다.

특히 맥 OS는 두벌식과 세벌식의 낱자 결합 규칙이 완전히 동일하다. 초성은 쌍자음을 원시 자음의 연타로 입력할 수 있는 반면 종성(ㄲ, ㅆ)은 그렇게 할 수 없는 것이 둘 모두 똑같다. 초성의 결합 규칙과 종성의 결합 규칙이 분명히 구분되어 있으며, 두벌식에서 다음 음절로 이어진 첫 자음도 응당 초성으로 간주된다.

그런데 ‘초성’이 아닌 ‘종성’ 관점의 두벌식 한글 입력 방식도 생각할 수 있으며, 사실 이것이 초성과 종성의 구분이 없는 진정한 두벌식다운 두벌식이라 할 수 있다. 이 사상이 반영된 구현체는 마이크로소프트 Windows의 한글 IME가 유일하다.

MS IME의 두벌식은 초성과 종성의 구분이 없고 자음 입력은 어떤 경우에든 종성 문맥으로 간주된다. 그렇기 때문에 모음 없이 자음을 바로 입력할 때도 ㄳ, ㄻ 같은 겹자음을 만들 수 있다. 심지어 그 상태에서 ‘ㄱ (ㅏ) 가 (bksp) ㄱ (ㅅ) ㄳ (ㅗ) ㄱ소’ 같은 자유로운 입력도 가능하다.

이것은 <날개셋> 한글 입력기에서는 지금까지 가능하지 않았다. 수식 없이 H2|_G 같은 기존 두벌식을 종성만 배당하면, 모음 없이 당장 겹자음을 만드는 것을 비슷하게 흉내는 낼 수 있다. 그러나 완전히 똑같게는 못 한다. 계속해서 다음 음절로 입력되는 자음은 어차피 종성이 아니라 초성이 되어 버리고, 종성의 낱자 결합 규칙이 적용되지 않기 때문이다.

또한 두벌식 종성으로 자음, 그 다음으로 모음을 입력한 뒤 Bksp를 눌러 보면, 첫 타에 해당하는 자음은 종성이 아니라 초성으로 바뀌어 있는 것도 볼 수 있다. 내부적으로 두벌식 종성과 두벌식 중성 사이에는 도깨비불 현상이 한번 일어나서 종성이 초성으로 넘어간 걸로 간주되기 때문이다.

이 문제를 해결하고 종성 위주 두벌식을 도입하기 위해, 본인은 <날개셋> 한글 입력기의 어느 부분을 개량하면 좋을지 굉장히 많이 고민했다. 기존 패러다임과 새 패러다임을 어떻게 조화시킬까?
어느 구조체를 확장할까, 어느 API에다 옵션 플래그를 추가할까, 아예 날개셋문자에다가 새로운 타입을 추가할까..? 이런 결정을 내려야 할 때가 정말 내가 엔지니어로서 현역이고 살아 있음을 느낀다.

API 호환성을 깨뜨리지 않고 가장 후폭풍이 적은 방법을 며칠간 고민하던 중, 결국은 날개셋문자에다 타입을 추가하는 게 가장 바람직하겠다는 결론을 도출하였다. 그래서 H2에 이어 일명 H2J라는 타입이 도입되었다. 일명 ‘두벌식 종성’ 타입. <날개셋> 한글 입력기 다음 버전인 6.7에서 바로 볼 수 있을 예정이다.

현재 한글 입력과 관련된 날개셋문자 타입은 H3과 H2 말고도 H3의 자매격에 해당하는 다중 자모가 둘 더 있다. <날개셋> 한글 입력기는 기존 H3만으로도 ‘ㅏ+종성ㄴ’ 같은 다중 자모를 배당할 수 있다. 초성 ㄱ을 입력 중에 저걸 누르면 곧바로 ‘간’이 되고, ‘오’를 입력하던 중에 저걸 누르면 곧바로 ‘완’이 된다. 다중 자모는 동시치기 같은 것과는 전혀 다른 개념이므로 그런 것과는 절대로 혼동하지 말라.

그런데 디폴트인 H3은 ‘초-중-종’을 순서대로 적용하는 반면, 여타 다중 자모는 ‘중-종’만 적용 후 음절을 끊고 다음 글자 초성을 또 입력시키거나 ‘종’만 적용 후 ‘초-중’은 다음 글자로 넘긴다. 세벌식은 음절 경계와 관련된 변칙적인 처리가 없으니 이런 다중 자모까지도 생각할 수 있는 반면, 두벌식은 다중 자모까지는 갈 수 없고 음절 경계 처리에만 치중한 파생 타입만을 생각할 수 있는 셈이다.

‘두벌식 종성’ 타입으로 입력된 종성은 도깨비불 현상이나 결합 실패로 인해 다음 글자로 넘어갈 때 초성으로 바뀌는 게 아니라 종성이 그대로 유지된다. 그리고 그 상태에서 중성을 입력하더라도 종성은 초성으로 바뀌지 않고 종성 상태로 그대로 보존된다.

이 타입을 쓰면 두벌식으로도 자음을 배당할 때, 골치 아픈 수식을 쓸 필요 없이 언제나 마치 세벌식처럼 H2J|_G라고 언제나 종성 형태만 넘겨 주면 끝이다. 다만, <날개셋> 편집기처럼 초-중-종성의 형태를 완벽하게 보존하는 한글 글꼴 체계에서는 처음에 초성을 입력했는데 초성이 아니라 종성이 나타나기 때문에 마치 도깨비불 현상만큼이나 보기가 어색할 것이다.

이 어색함은 표준 한글 자모를 호환용 한글 자모로 치환해서 표시해야 덜해진다. 즉, 애초에 초성과 종성의 구분이 없는 글자판은 역시나 초성과 종성의 구분이 없는 글자 코드와 글꼴을 동반해야 자연스럽다는 뜻. 실제로는 한글의 구성 원리를 어기고 전혀 자연스럽지 않은 처리가 추가로 행해지는 셈이다. 오버헤드는 ‘세벌식 < 기존 세벌식 관점에서 추가로 구현된 두벌식 < 새로 도입된 종성 지향 두벌식’의 순으로 많아진다.

H2J 타입을 쓰면 <날개셋> 한글 입력기로도 MS IME의 두벌식과 완전히 동일하게 동작하는 입력 방식을 구현할 수 있다. 사실 내 프로그램은 세벌식 자판과 관련된 응용 기능들은 거의 1.x 시절부터 제공해 온 반면, 두벌식을 두벌식답게 지원하는 편의 기능들은 훨씬 나중에 도입되어 왔다. 특수 도깨비불 규칙(3.9부터)이라든가, 초-종성 공유 낱자 결합 규칙(6.0)에 이어, 종성 지향 두벌식(6.7)의 순이다.

알면 별로 어려울 것 없는 내용인데 이 글 내용을 제대로 이해한 분이 얼마나 되려나 모르겠다. <날개셋> 한글 입력기는 올해로 개발 12주년이고 무려 7.0을 바라보는 시점인데 아직도 한글 입력의 본질과 관련된 새로운 기능이 추가되고 향상된 게 있다는 게 내게는 무척 흥미롭고 의미심장하게 느껴진다.

Posted by 사무엘

잘 알다시피 <날개셋> 한글 입력기는 Windows용 한글 IME이다(IME이기만 한 건 아니지만). 이 분야는 경쟁 프로그램이 거의 없다시피하기 때문에, MS가 직접 공급하는 IME를 제외하면 3rd party 한글 IME 중에서는 <날개셋> 한글 입력기가 가히 독주를 하는 중이다. 그 이유로는,

첫째, 모바일용도 아니고 PC용으로는 한글 입력 방식이 딱히 더 만들 게 없다고 여겨지고 있어서인 것 같다. 그리고 딱히 돈이 되는 것도 아니니까 말이다. 싸제 IME가 활발히 쓰이고 있는 중국어· 일본어 IME의 개발 환경과 비교했을 때 이것이 크게 다른 점이다.

그리고 둘째로는, 윈도우용 IME라는 게 여타 운영체제의 IME와 비교해 보더라도 그 아키텍처와 스펙이 미치도록 폐쇄적이기 때문이다. 비록 프로토콜이 공개돼 있는 건 있지만, 그것만 참고해서는 쌩쌩 잘 돌아가는 한글 IME를 절대로 만들 수 없다. 문서화되지 않은 무수히 많은 상황에 대한 대비를 해야 되는데 이걸 이제 와서 혼자 처음부터 만든다는 건 불가능에 가깝다.

그럼에도 불구하고 <날개셋> 한글 입력기 말고 ‘싸제’ 한글 IME가 전혀 없는 건 아니다. 본인은 MS가 개발하지 않은 한글 IME를 최소한 두 종류를 더 알고 있다.

※ 새나루

윈도우 DDK에 등재되어 있는 FakeIME라는 일본어 예제 IME를 고쳐서 만들어진 한글 IME이다. 오픈소스 진영에서 만들어진 프로그램답게 소스 공개이다. 개발자들은 본인처럼 아예 대놓고 국어 정보학 쪽으로만 발을 들인 것도 아닌데 이쪽으로 조예가 굉장히 깊은 고수 프로그래머이다.

싸제 IME답게 여러 실험적인 기능이 많아서 실속이 있으며, 그러면서도 <날개셋>보다 덩치 작고 가볍다는 이점이 있다. 특히 <날개셋>이 개발 방향의 특성상 의도적으로 더 지원하지 않는 다음 기능들 때문에 새나루를 선호하는 사람도 있다.

키보드 드라이버 차원에서 드보락 글자판과의 연동: 쉽게 말해, 단축키까지 드보락 식으로 나오면서 그 상태에서 한글 입력까지 지원.

글자가 아니라 단어 전체를 조합으로 잡아서 단어 단위로 한자 치환: 일부 한자 혼용론자가 무척 좋아하는 기능이라 한다. MS IME로는 이 기능은 TSF A급 프로그램에서만 가능하며, <날개셋> 한글 입력기 역시 훗날 이 기능을 추가한다 하더라도 MS IME처럼 TSF A급에서만 지원할 것이다.

이 외에도 잘은 모르겠지만, 안 마태 키보드 드라이버도 입력 스키마를 살짝 변조한 수준에 머물러 있는 <날개셋>보다 새나루가 좀 더 지원을 잘 하는 게 있는 듯하다.

다만, 새나루의 개발자는 <날개셋>의 개발자처럼 한글 입력기 하나에만 완전 목숨을 건 타입은 아니다 보니, 프로그램의 유지· 보수와 버전업이 <날개셋>만치 애착을 갖고 꼬박꼬박 되고 있는 건 아니어 보인다. 하긴, 무료 소프트웨어가 이 정도라도 개발되어 온 게 감지덕지지.

※ Unicode CJK IME

이건 아는 분이 얼마 없지 싶다. 이건 무려 남북 합작으로 개발된 프로그램이다. 주 개발은 북한의 평양 정보 센터(PIC)에서 했으며, 남한의 한국 과학 기술 정보 연구원과 고려 대학교 민족 문화 연구원은 프로그램을 설계하고 각종 한자 데이터베이스를 구축했다. PIC는 서체도 만들고 ‘단군’이라는 워드 프로세서도 개발한 적이 있을 정도로 문자 처리 쪽에 기술이 상당한 수준이다. 그러니 IME도 만들었다.

세벌식은 전혀 지원하지 않지만, 남북 합작 IME 답게 북한 두벌식을 지원한다. 그리고 한양 PUA 방식의 옛한글을 지원하며, 문자표, 부수로 한자 입력, 자체 한자 사전 등의 기능을 내장하고 있다.

제목에서 알 수 있듯, 이 제품은 한글 IME뿐만이 아니라, 동일한 UI 엔진 기반으로 개발된 중국어· 일본어 IME와 한 세트를 구성하고 있다. 북한에서 그런 것까지 만들었다. 하지만 이들 IME의 성능(사전 크기 및 어절 분할 정확도)은 본인이 판단하기에 운영체제가 기본 제공하는 중국· 일본어 MS IME보다 못하다.

이런 프로그램들과는 달리, <날개셋> 한글 입력기는 처음에는 전용 에디터로만 개발되고 있었다. 2.x 시절까지만 해도 본인은 내가 스스로 한글 IME를 만들 수 있을 거라고 생각도 못 하던 처지였다. 그랬는데 2003년은 참으로 드라마틱하게도 한글 IME 개발의 원년으로 등극하게 되었다.

새나루는 2003년 말에 첫 버전이 나왔다. 그리고 본인이 접한 Unicode CJK IME 역시 2003년 6월자 버전이었다(다만, 그 후로 유지 보수는 중단된 듯). 그리고 그 해 가을에 출시된 MS 오피스 2003은 한자 변환 기능이 크게 강화되어 단어 단위 한자 변환이 처음으로 도입된 버전이었다. 이게 다 우연인 걸까?

이런 일련의 사건을 계기로 본인은 운영체제의 IME 스펙을 처음으로 공부하기 시작했으며, <날개셋> 한글 입력기를 운영체제의 IME로 거듭나게 하려는 연구를 난생 처음으로 시작했다. 마침 2003년 하반기이면 <날개셋> 한글 입력기 역시 3.0이 개발 중이었고, 입력기의 내부 구조를 싹 뒤집어 엎고 있었다. 나의 대학 3학년 시절, 이때가 <날개셋> 한글 입력기의 미래를 결정하는 개발이 이뤄지던 시절이었으니, 흥미롭지 않을 수 없다.

그래서 <날개셋> 한글 입력기에 좀 이렇다 할 외부 모듈이 난생 처음으로 탑재된 건, 2004년 9월에 나온 3.02 버전이다. 한글 입력기를 표방하면서 정작 윈도우용 IME가 나온 것은 새나루나 남북 합작 IME보다 시기적으로 늦다.

첫 버전은 당연히 정말 불안정했고 볼품없는 퀄리티였다. 아직 운영체제의 IME 시스템의 내부 구조를 제대로 이해 못 한 상태에서 최소한의 글자 찍기만 가능하던 상태였다. 이 때문에 직후 버전인 3.1에서 당장 무더기 버그 패치가 이뤄졌으며, 그 후로 외부 모듈이 큰 안정화 단계를 마치기까지는 1년이 넘는 시간이 더 필요했다.

그러나 첫 진입 단계에서 이런 시행착오를 충분히 겪은 뒤엔, 워낙 탄탄한 자체 한글 입력 시스템을 갖추고 있던 <날개셋> 한글 입력기가 완성도 높은 윈도우용 IME로 완전히 자리잡게 되었다. TSF 인터페이스를 이용해 bksp 달라붙기 같은 <날개셋> 고유 기능까지 그럭저럭 재연해 냈고, 심지어 윈도우 95부터 오늘날의 7까지 모든 운영체제를 지원하는 최적화까지 덤으로 구현했기 때문이다.

<날개셋> 한글 입력기는 이런 내력을 거쳐 지금과 같은 모듈들이 잘 개발되었다. 하지만 IME(외부 모듈)이 첫 개발되던 그 시절을 본인은 지금도 잊을 수 없으며, IME 모듈의 개발에 영향을 끼친 위의 두 프로그램들에도 나름 애착을 갖고 있다.

Posted by 사무엘

<날개셋> 편집기는 내부 에디팅 엔진이 TSF를 완벽하게(A급으로) 지원하게 할지 지정하는 ‘TSF 지원’이라는 도구-옵션 대화상자에 있다. 프로그램이 TSF A급으로 동작하면 그 밑에서 구동 중인 외부 모듈이 에디터의 텍스트를 자유롭게 다룰 수 있고 MS 한국어 IME는 단어 단위 한자 변환도 가능하며, 일본어 IME의 경우 Natural Input 모드로(커서 위치에 따라서 조합/비조합 모드가 자유자재로 왔다갔다) 동작도 가능하다.

그러나 이런 편의에는 속도와 메모리 사용량 같은 tradeoff가 응당 있다. TSF A급으로 동작하기 위해서는 프로그램이 커서 하나가 움직일 때에도 운영체제의 TSF 시스템에다가 일일이 통보를 해 줘야 한다. 그래야 연동이 제대로 된다.

그런데 이 TSF 시스템이라는 게 돌아가는 모습이 못마땅할 때가 있다. 내 프로그램이 문서 전체처럼 꽤 많은 영역의 블록을 잡고 있으면, 이따금씩 운영체제는 블록 텍스트가 무엇이 있는지 수 MB에 달하는 데이터를 일일이 요청한다. 그것도 키 하나 누를 때마다, 커서가 움직여서 블록 영역이 조금이라도 바뀔 때마다 말이다. 그 텍스트 얻어 와서 도대체 뭘 하는지는 모르겠다. 그 요청을 거절할 수도 없는 노릇이고, 거 참.

이 때문에 <날개셋> 편집기로 20MB 이상 대용량의 텍스트를 열고, 새로운 글자 입력보다는 오리고 붙이기 같은 편집이 주 사용 목적이라면 ‘TSF 지원’ 옵션을 끄고 프로그램을 다시 실행하는 게 성능 면에서 낫다. TSF A급을 유지하면서 지금보다 성능을 더 끌어올릴 수 있는 방법이 현재로서는 떠오르지 않는다.

대용량 파일을 수월하게 다루는 전문적인 에디터를 개발하는 게 목적이라면, 별도의 전문적인 메모리 관리자도 쓰고 더욱 심도 있게 성능 최적화를 할 수 있다. 그러나 <날개셋> 편집기의 1차적인 개발 목적은 잘 알다시피 그냥 입력 엔진의 기술 데모일 뿐이기 때문에, 그런 세세한 것까지 신경 쓰지는 않는다.

하지만 한편으론 아주 작고 가볍고 최적화 잘 되고 빠른 에디터도 어느 정도 지향하고 있다. 그런 컨셉의 프로그램이 덩치에 어울리지 않게 에디팅 엔진이 너무 비효율적이고 느리면 그것도 영 보기 안 좋다. 그래서 이 프로그램은 버전업을 거듭하면서(특히 5.x 후반과 6.5 사이에) 내부적으로 최적화도 상당히 많이 되었으며, 몇십 MB짜리 파일 정도는 부담 없이 편집하고 저장할 수 있는 프로그램이 되었다.

혹시 MS에서 만든 다른 TSF A급 프로그램은 사정이 어떨까 궁금했다. 워드패드를 살펴봤는데, <날개셋> 편집기보다 성능이 더 안 좋다. 아까보다 더 작은 수 MB짜리 파일을 열어도 프로그램이 감당을 못 하고, 역시나 커서 한 칸만 움직여도 프로그램이 몹시 굼뜬다. Select All 명령을 내리니 아예 프로그램이 뻗는 듯. Windows는 기본 제공하는 프로그램들 중 에디터가 몹시 부실하다는 게 이 자리에서도 다시 한 번 입증되었다. TextEdit(맥)나 gedit(리눅스)는 그렇지 않다.

사실, 위지윅이나 서식 지정 같은 기능이 전혀 없는 에디터라 해도, 유니코드에 따른 다국어를 제대로 지원하려 한다면 개발 난이도가 안드로메다 급으로 급상승한다. 바로 아랍· 히브리 지원 때문이다. Complex script 체계에서는 같은 글자라 해도 앞뒤에 무슨 글자가 있냐에 따라서 모양이 달라질 수 있고, 커서가 움직이는 단위와 문단을 나누는 기준이 시시각각 달라진다. 특수한 유니코드 제어 문자 처리도 해야 한다. 한 줄에 L2R 문자와 R2L 문자가 공존할 때 커서 위치는 어떻게 계산할 것이며, 게다가 세로쓰기라든가 자동 줄바꿈 옵션과의 연계는 어떻게 할 것인가? -_-

Uniscribe라는 API가 있다지만 그게 다루는 각종 개념을 공부하는 것부터가 쉬운 일이 아니다. 사실 저런 문자의 처리는 심지어 전문적인 상업용 워드 프로세서인 아래아한글조차도 2005 버전이 돼서야 지원하기 시작했으며, 프로그래머용 에디터에서는 그리 필요하지도 않은 기능이다.

EditPlus는 지금 최신 버전은 어떤지 모르겠는데 3.1x대 버전을 살펴본 기억으로는 아랍어의 매끄러운 처리를 제대로 지원하지 않았었지 싶다. 엄밀히 말하자면, 내부 문자 단위 크기만 ansi에서 wide char로 바꾼다고 해서 완벽한 유니코드 지원이 되는 건 아니다. 비록 화면으로 보기 좋게 찍히지만 않을 뿐, 정보 손실은 없겠지만 말이다.

그래서 <날개셋> 편집기는 복잡한 다국어 글꼴 처리 쪽은 아예 깨끗하게 접고(무시하고/포기하고)-_- 신경을 안 쓴다. 입력이라는 분야에만 초점을 맞춰 그쪽의 전문성만을 유지하며 개발되고 있다. 오히려 아랍· 히브리 문자는 깔끔하게 깨진 문자로 메모리 순서대로 단순하게 표시해 주니, 각 글자의 코드 포인트를 확인할 일이 있을 때는 유용하기도 하다. -_-

이렇듯, 텍스트 에디터를 하나 만들더라도 프로그래머용 기능 특화냐, 아니면 입력기와 유니코드 글꼴 쪽으로 특화냐 같은 개발 패러다임이 나뉠 수 있다. <날개셋> 편집기는 TSF 지원 같은 입력기 특화이고, 정확히 말하면 여타 어느 프로그램도 시도한 적이 없는 ‘한글 입력’ 특화이다. 하지만 글꼴 쪽의 전문적인 지원은 없다. 또한, Syntax highlighting기능조차도 없을 정도로 프로그래머 특화는 아니지만, 그래도 다양한 자동화 기능을 염두에 둔 텍스트 필터도 제공하기 때문에 전문 기능이 아주 없는 건 또 아니다. 일종의 패러다임 짬뽕인 것 같다.

Posted by 사무엘