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

<날개셋> 한글 입력기의 개발자가 심층 분석한 MS 한글 IME 리포트.
버그를 나열하기 전에 먼저 독자의 이해를 돕기 위한 기술 설명부터 하겠다.

A. MS IME의 두벌식과 세벌식의 구현 차이 -- 오토마타

일단 좋은 말부터 꺼내자면, MS 한글 IME는 현존하는 한글 입력기들 중, 어떤 의미에서는 기본에 충실하게 가장 FM대로 만들어져 있다. 두벌식과 세벌식의 로직이 서로 확고하게 분리되어 있으며 구조가 완전히 다르다. 그리고 MS 버전의 두벌식 한글 입력기는 전산학적으로 볼 때 진정한 두벌식의 고증에 가장 충실하게 만들어져 있다.

무슨 말이냐 하면, 자음이라면 초성을 조합할 때와 종성을 조합할 때의 조합 규칙에 차이가 없다. 그래서 초성이 입력되는 상태에서도 ㄶ, ㄳ 같은 겹받침을 바로 입력할 수 있는 반면, ㄲ, ㅆ 같은 쌍자음은 연타가 아니라 반드시 Shift로만 입력할 수 있다. 이 동작 방식은 내가 알기로 윈도우 95 시절 이래로 시종일관 변함 없다.

<날개셋> 한글 입력기나 아래아한글의 두벌식 입력기는 그렇지 않다. 도깨비불 현상만 추가되었을 뿐 세벌식의 사고방식으로 두벌식을 덤으로 구현한 형태에 가깝다. <날개셋>의 경우, 이 점을 감안하여 지난 6.0 버전에서 초-종성 공유 낱자 결합 규칙이라는 개념이 추가되었으며, 이를 사용하면 두벌식 입력 방식을 좀 더 두벌식스러운 사고방식으로 설정할 수 있다.

뭐, 아래아한글도 1980년대 말에 1.0이 처음 개발되었을 때는 개발자들이 세벌식이 정확하게 뭔지 몰라서 자음만 한 벌 더 있을 뿐 여전히 도깨비불 현상이 존재하는 형태로 만들었다가, 고 공 병우 박사에게서 지적 받고 고쳤다는 일화가 전해지긴 한다만.

B. MS IME의 두벌식과 세벌식의 구현 차이 -- 글쇠 인식

표준 두벌식 글자판은 A부터 Z까지 딱 알파벳 글쇠 26개에만 한글이 배당되어 있고 나머지 글자들은 영문과 완전히 똑같다. 그렇기 때문에 MS 한글 IME는 두벌식일 때는 알파벳 글쇠만 가로채어 사용하며, 숫자, 기호, 공백 글쇠는 처리하지 않고 응용 프로그램으로 그대로 넘겨 준다.

세벌식은 그렇지 않다. 몇 가지 영문과 일치하는 기호가 있긴 하지만 일반적으로 공 병우 세벌식은 4단까지 독자적으로 사용하고 숫자와 기호 영역까지 침범한다. 그래서 MS IME는 세벌식에 대해서는 아예 공백까지 포함한 48개 글쇠 자리를 모두 가로채어 동작한다. <날개셋> 한글 입력기는 가로챌 글쇠 영역 자체를 필요에 따라 정밀하게 제어하는 옵션을 아주 최근의 6.5 버전에서야 추가했다.

이렇게 두 글자판의 구현이 제각각 따로라는 점 자체는 나쁘지 않다. 그러나 이는 MS IME에 두벌식을 쓸 때는 괜찮은데 세벌식을 쓸 때만 자잘한 버그가 존재하는 빌미를 제공하고 있다. 역사적으로 볼 때, 이런 버그는 더럽게 안 고쳐진다는 특징도 있었다. 두벌식과 세벌식의 넘사벽 급의 인지도 차이 때문이다.

10년도 더 전에 포트리스라는 대포 쏘기 게임이 인기였을 때, 세벌식으로는 한글 모드에서 Space로 대포 쏘기가 안 되어 채팅과 게임을 같이 하기가 불편하다는 이슈가 있었다. 두벌식에서는 Space가 응용 프로그램이 직접 접수한 공백이지만, 세벌식에서는 Space가 직접 오는 게 아니라, 한글 IME가 가공을 하고 보내 준 공백이라는 완성된 문자열이 오기 때문이다.

C. 윈도우 7에서의 변화

자, 앞에서 다룬 건 MS 한글 IME의 두벌/세벌 메커니즘의 차이이고, 지금 하는 얘기는 운영체제의 버전에 따른 디테일의 변화 쪽이다.

16비트 윈도우 시절에는 운영체제에 유니코드도, 국제화(I18N)도, 지역화(L10N)도 없었다. 동일 제품을 한중일 나라의 문자를 입출력할 수 있게 개량하는 것은 MS의 각 지사에서 완전히 독자 기술을 사용해서 알아서 재량껏 해야 했다.

그러다가 윈도우 95/NT4가 되면서 글꼴 쪽도 획기적으로 발전하고(내장 비트맵, 트루타입 컬렉션 등), 입력기 쪽도 한중일 통합 IME 프로토콜이 처음으로 제정되었다. 그리고 입력기 프로그램은 EXE가 아니라 여타 운영체제에서 유례를 찾기 힘든 독특한 형태인 DLL이 되었다. 그래서 윈도우만 입력기의 한영 상태가 각 프로그램별로(정확히는 스레드별로) 완전히 따로 놀지, 공유가 되지 않는다.

윈도우 2000부터는 추가 글꼴과 코드 페이지 데이터만 설치해 주면 세계 어느 나라 윈도우에서도 아무 나라 언어의 입력기를 설치할 수 있게 되었고, 윈도우 XP부터는 고급 텍스트 서비스라고 불리는 일명 TSF 기술이 도입되었다. 윈도우 비스타부터는 이제 전세계 언어의 입력기와 글꼴이 추가 설치를 할 필요도 없이 기본으로 제공되며, TSF 프로토콜이 주류가 되고 기존 IME 프로토콜은 호환성 계층을 통해서나 제공된다.

이로써 비스타에서 문자 입력 방식의 그랜드 슬램이 달성되고 해피엔딩이 된 것 같은데, 윈도우 7에 와서는 기능이 추가된 건 없으면서 뭘 또 잘못 건드렸는지 문자 입력 쪽의 안정성이 전반적으로 하락했다. MS 한글 IME만의 버그인 것도 있고 운영체제 자체의 버그인 것도 있다. 이 글에서는 지금까지 언급한 A~C를 염두에 두고, 2012년 현재 MS 한글 IME에 존재하는 것으로 알려진 버그들을 정리해 보았다.

1. 세벌식 최종 + 전각문자

맥 OS는 공 병우 박사(이분이 요즘 같았으면 전형적인 앱등이이셨다ㅋㅋㅋ)의 텃새 덕분에 전통적으로 세벌식 최종이 강세였으며, 세벌식이라 하면 곧 최종 자판을 가리켰다. 그러나 PC 쪽은 도스 시절 이래로 390이 강세였기 때문에 세벌식이라 하면 곧 390을 가리켰다. 최종은 아래아한글조차 97에 와서야 제공하기 시작했을 정도로 인지도가 미미했다.

윈도우 95 때 처음으로 세벌식 최종 글쇠배열이 있긴 했지만 그런 인지도 부족으로 인해 틀린 배열이 굉장히 많았다. 그게 98에서 좀 바로잡히긴 했지만 여전히 오류가 있었고, 그 오류는 윈도우 XP/오피스 2003에 가기까지 고쳐지지 않았다.

비록 최종 글자판은 참고표와 가운뎃점처럼 1바이트 아스키 영역에 없는 글자가 있는 게 특이점이긴 했지만, 윈도우 98부터는 어차피 한글 IME의 모든 내부 자료구조가 유니코드로 바뀌었기 때문에 큰 문제가 되지 않았다. 구조가 그러하니 내가 파워업을 개발해서 패치도 가능했던 것이고.

윈도우 비스타 + MS 오피스 2007에 와서야 드디어 100% 정확한 세벌식 최종 글자판이 제공되기 시작했다. 2003년 중반에 내가 한국 MS를 방문해서 수정을 강력하게 요청했던 것도 아마 작용하지 않았겠나 생각해 본다. 비록 그 해 가을에 발표된 오피스 2003에서 바로 반영되지는 못했지만 말이다.

그런데, 이 사람들이 일을 깔끔하게 처리하지 못했다. 전각 모드에서는 참고표와 가운뎃점이 제대로 입력되지 않는다. 얘들은 아스키 문자가 아니니 라틴 문자처럼 일괄적으로 0xFEE0를 더해서는 안 되는데 그거 처리를 추가하지 않은 듯하다. 윈도우 7+오피스 2010에서까지 변함없다. 물론 한국에서는 전각 문자를 거의 쓰지 않으니, 이건 심각한 문제는 아니다.

참고로 한중일의 MS 오피스는 XP 버전부터 운영체제의 IME를 자기 것으로 패치하는 게 관행이 됐다. 일본어 IME는 운영체제의 것과 오피스의 것이 차이가 난다는 말도 있는 듯하지만, 한글 IME는 운영체제의 것이나 오피스의 것이나 차이가 거의 없음.

2. MS 워드 2007 이상에서 세벌식을 쓸 때만 나타나는 역상 현상

워드 2007 이상에서, 오피스 2007 이상 또는 윈도우 비스타 이상이 제공하는 한글 IME로 세벌식을 써서 한글과 숫자, 기호, 공백을 입력한다. 그 뒤에 IME를 날개셋이라든가 다른 일본어· 중국어 입력기로 바꾼 뒤 글자를 입력한다. 그러면 예전에 MS 한글 IME의 세벌식으로 입력했던 공백이나 숫자, 기호가 역상(검은 배경, 흰 글씨)으로 바뀐다!

굉장히 기괴한 버그이다. 이것은 워드에서만 나타난다는 점에서 워드의 문제이기도 하지만 세벌식으로 입력한 비한글 문자에 대해서만 나타난다는 점에서 MS IME의 문제이기도 하다. B에서 언급한 기술 차이를 생각해 보라.

이 역상은 문서의 내부 서식이 아니라, 문자의 중간 조합 상태를 표현하기 위해 문자 입력기가 임시로 부여하는 시각 효과이다. 일본어 입력 중에 나타나는 점선 밑줄 같은 것 말이다. 해당 문서를 저장한 뒤에 다시 불러오면 다행히 사라지긴 하지만, 그 상태에서 조치를 취하지 않으면 인쇄도 그대로 역상 모양으로 된다. -_-

더욱 기괴한 건, 오피스 2003 같은 예전 버전의 MS IME로는 세벌식을 쓰더라도 이런 현상이 발생하지 않는다는 점이다. MS 제품 자체의 버그가 확실하다. 윈도우 7/오피스 2010에서까지 고쳐지지 않았다.

3. 윈도우 7, 한글 입력 중에 바탕 화면을 클릭했을 때

윈도우 7에서 MS 워드 2007이나 2010을 실행하여 아무 한글 IME로나 한글을 입력한 상태로 있는다. 창을 최대화하지는 않은 채로 가령, ‘아’를 조합하고 있는다. 그리고 그 상태로 마우스로 바탕 화면을 클릭했다가, 다시 워드의 제목 표시줄을 클릭하여 돌아온다.

비스타에서는 동일한 절차를 수행하고 나면 ‘아’의 조합이 종료되어 커서가 ‘아’ 뒤에 가 있다. 그러나 7에서는 커서가 여전히 ‘아’를 조합하고 있지만 실질적으로는 조합이 끝난 상태이다. 받침 ㄴ을 입력하더라도 ‘안’이 되지 않고 ㄴ이 새로 조합된다.

윈도우 7은 한글 조합 중에 창의 포커스가 바뀌었을 때의 내부적인 처리가 갑자기 좀 이상하게 혹은 엄격하게 바뀌었다. 비스타나 XP 이전에는 아무 문제가 없던 게 7에서 갑자기 문제를 일으켜서 그에 대한 방어를 해야 했다. <날개셋> 한글 입력기도 과거의 5.51과 5.52 때 이와 관련된 버그 패치가 행해졌다.

4. 윈도우 7의 콘솔에서 세벌식으로 조합을 종료할 때 글자가 덧남

윈도우 XP/비스타에서는 해당사항 없고 7에서만 발생하는 구조적인 문제이다. 서비스 팩 1에서도 고쳐지지 않았다.
명령 프롬프트에서 세벌식 자판으로 한글을 입력하다가 온점이나 스페이스처럼 비한글 문자를 입력하면서 조합을 종료시키면, 조합 중이던 한글이 덧난다. 가령, ‘다.’를 입력하다 보면 ‘다다.’가 된다.

이건 꽤 황당하고 심각한 버그인데 왜 아직까지 안 고쳐졌는지 이해가 안 된다. 게다가 윈도우 7은 출시된 지 이제 무려 3년이 다 돼 가지 않는가.
왜 세벌식일 때만 그렇냐고? 이 역시 B에서 설명되었듯, 비한글 문자를 처리하는 방식이 두벌식과 세벌식이 다르기 때문이다. 문자 입력 프로그램이 아니라 운영체제의 구조적인 버그이기 때문에 윈도우 7에서는 MS IME든 날개셋이든 동일하게 발생한다.

5. IME 2010, 콘솔에서 한자 후보 목록이 곧바로 나타나지 않음

이것은 약간 불편할 수는 있지만 그렇게 심각한 문제는 아니다. 콘솔에서 한글을 조합하는 중에 한자 키를 눌러 보면, 원래 한자 후보가 콘솔 창의 하단에 곧바로 떠야 하는데 뜨지 않는다.
물론 이 상태에서도 번호를 누르면 해당 한자로 바로 변환이 되며, 좌우 화살표 같은 페이지 전환 키를 누르면 그제서야 후보 목록이 나타난다. 뭔가 코딩 실수가 들어간 듯하다.

이 버그는 윈도우 7의 기본 한글 입력기에서도 존재하지 않으며, 한글판 MS 오피스 2010과 함께 설치된 한글 IME 2010에서만 나타나는 문제이다. 즉, 운영체제의 것을 대체하는 오피스의 IME가 오히려 버그를 포함하고 있는 셈이다.
<날개셋> 한글 입력기에는 물론 이런 문제가 없다.

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 사무엘

윈도우 운영체제용 한국어 키보드 드라이버에는 type 3이라는 방식이 있다. 이게 왜 있는지 내력을 좀 설명하자면 이렇다.

한국에서 쓰이는 PC 키보드에는 한글/영문 입력 모드 전환을 위해 한영 키가 있고, 한자 변환을 위해 별도의 한자 키가 있다. 하지만 도스 시절에 이 키를 하드웨어적으로 인식하기란 쉽지 않았고, 당시 많은 자체한글 프로그램들이 실제로는 Shift+Space로 한영 전환을 하곤 했다. 그리고 한자 변환은 아래아한글의 관행인 F9가 대세였다.

한영 전환 글쇠에 대한 호불호는 사람마다 편차가 큰 것 같다. 한영 키가 직관적으로 그렇게 누르기 편한 위치에 있지도 않은 건 사실이다. 그 때문에, 이걸 굉장히 싫어하고 오로지 Shift+Space만 쓰는 사람도 있다. 오로지 한영 전환 글쇠 때문에 MS IME를 버리고 새나루나 <날개셋> 한글 입력기를 쓸 정도이니까.

그러나 반대로 Shift를 이용한 뒤에 진짜로 공백을 누르고 싶은데 실수로 글쇠 전환이 되어 버려서 그게 불편하다고 느끼는 사람도 있다. 본인은 후자에 가까운 타입이어서 그냥 한영 키를 쓰는 것을 선호한다.

마이크로소프트는 자사의 제품에서 원래 ‘정석대로’ 한영/한자 키만을 지원하였다. 그러나 도스 시절의 저 관행에 익숙한 사람들을 위해 Shift+Space를 한영 키로, Ctrl+Space를 한자 키로 드라이버 차원에서 인식하는 키보드 드라이버도 별도로 제공했는데, 이것이 바로 type 3이다.

이 드라이버는 반대로 기존 한영/한자 키는 Ctrl/Alt로 인식한다. 그래서 드라이버를 쓰면 Shift뿐만 아니라 Ctrl/Alt도 좌우를 구분할 수 있다. 그러나 Shift+Space와 Ctrl+Space를 원래 자체적인 용도로 쓰는 엑셀 같은 프로그램(행 또는 열 전체 선택)에서는 해당 글쇠를 사용할 수 없어지는 문제도 존재한다.

type 3 키보드를 사용하려면 제어판에 들어가서 키보드 드라이버를 업데이트해야 하는데, 수 단계에 걸친 마법사 질문들을 전부 일관적으로, 운영체제가 권장하지 않는(non-typical) 예외 옵션만 골라야 사용할 수 있다.

이런 키보드 드라이버가 있기 때문에 본인은 <날개셋> 한글 입력기를 도대체 어느 장단에 맞춰 춤을 추도록 만들어야 할지 모르는 고민에 빠지게 됐다. 일단 이 프로그램은 한영 전환과 한자 전환 글쇠를 마음대로 사용자 지정 가능하기 때문에, 드라이버 차원에서 글쇠를 변조해 주는 type 3 같은 드라이버는 사용하지 않길 권한다. 기존 type 1에서도 얼마든지 Shift+Space로 한영 전환이 가능하고 그게 기본값이다.

일단, 이 프로그램은 type 3에 대한 보정을 한다. 사용자가 Shift+Space를 누른 것을 드라이버가 한영이라고 fake로 알려 주더라도, 키의 스캔코드는 여전히 space이기 때문에 한영이 아닌 Shift+Space에 해당하는 단축글쇠를 참고한다. type 3은 Ctrl과 Alt의 좌우 구분은 가능하지만 한영과 한자 키를 전혀 인식하지 못하는 모드가 되는 것이다.

한자 키는 지금까지는 보정을 했는데 다음 버전부터는 보정하지 않을 것이다. 보정을 하기 때문에 Ctrl+Space는 말 그대로 한자가 아닌 Ctrl+Space로 type 3에서도 그대로 인식되며, 이 때문에 <날개셋> 한글 입력기의 설치 직후 기본 설정으로는 type 3 키보드로 한자 변환을 할 수 없었다. 보정을 하지 않게 되면 이 키는 Ctrl+한자 키로 인식된다.

그리고 다음 버전부터는 ‘한자’ 키뿐만이 아니라 ‘Ctrl+한자’도 한자 후보 변환으로 인식하는 값을 단축글쇠 테이블의 기본값으로 추가할 것이다. 이로써 동일한 기본 설정만으로 type 1과 type 3 모두 각각의 한자 키로 한자 변환이 가능해지는 것이다. 요컨대 한영 전환인 Shift+Space는 보정을 하지만, 한자 변환인 Ctrl+Space는 보정하지 않는다는 뜻이다.

한영 전환 글쇠와는 달리 한자 변환 글쇠는 매우 드물게 쓰이고 사용자별 편차도 거의 없으니, 그냥 이렇게 하는 게 더 나은 선택이겠다. 어차피 MS IME는 그냥 한자를 누르든 Shift+한자를 누르든, Ctrl+한자를 누르든 똑같이 동작하더라.

다만, <날개셋> 한글 입력기의 다음 버전에서는 후보 변환 기능이 세분화되어 Shift+한자는 제2 후보 변환으로 기본 설정이 바뀔 예정이다. 이것을 type 3 키보드는 제대로 인식을 못 할 것이다. 그렇기 때문에 <날개셋> 한글 입력기를 사용할 때는 글쇠를 임의로 변조하는 type 3 대신 글쇠를 있는 그대로 돌려 주는 기본 type 1을 쓸 것을 권한다.

여담이다만, 윈도우 운영체제의 한글 키보드는 한영 전환과 한자 변환 말고 전/반자 모드 전환이라는 또 다른 명령이 존재한다. 이건 완전히 듣보잡화한 상태이기 때문에 아는 사람이 거의 없을 것이다. -_-;; 키보드에 독립된 글쇠가 있지도 않고, 그 글쇠가 Alt+=로 정의되어 있다.

Posted by 사무엘

1.
겨울방학도 이렇게 끝이 보인다.
본인이 이번 방학 때 이뤄낸 가장 뜻 깊은 성과를 둘 꼽자면 하나는 <날개셋> 한글 입력기 6.5이고, 다른 하나는 HFT(아래아한글 전용 글꼴) 해킹 성공이다.

저 글꼴들을 MS 오피스 제품에서도 쓰고 PDF도 자유롭게 만들고, 무엇보다도 화면에 anti-alias가 된 부드러운 모습으로 보니 너무 좋다.. 근성의 reverse engineering 오덕질을 통해서 이뤄 낸 성과. ㅋㅋ 새로운 글꼴로 아무 글이나 마구마구 써 보고 싶다.

또한, 날개셋 6.5 버전은 아직까지도 프로그램을 크게 고친 부분이 없을 정도로 역대 최고로 손꼽히는 안정성과 완성도로 잘 만들어졌다. 대단히 만족스럽다. 그래서 당분간 안심하고 완전히 새로운 기능 연구와 논문 준비 등에 전념할 수 있을 것 같다.

2.
윈도우 7은 콘솔(명령창)에서 세벌식을 쓰면 '다다.' 이렇게 한글이 덧나는 버그가 있다. 왜 SP1에서도 안 고쳐진 걸까? 예전에도 언급한 적이 있지만, 이런 건 두고두고 디스를 좀 해 줘야 된다.
윈도우 운영체제는 NT 계열도 꼭 이런 이상한 버그가 역사적으로 하나씩 있었다.

과거 2000은 256색으로 들어갔다가 돌아오면 군청색 제목 표시줄의 색깔이 옅어지는 버그를 유일하게 갖고 있어서 SP4에서까지 안 고쳐졌고,
XP는 테마를 저장했다가 불러오면 Luna 모드에서도 메뉴가 클래식 모드처럼 표시되어 색깔이 이상해지는 버그가 있는데 역시 SP3에서까지 안 고쳐지고 저렇게 끝났다.

이런 이유로 인해 본인은 한글 IME 개발과 관련하여 까탈스럽고 안 좋은 추억 때문에 남들이 7 좋아하는 것만치 7을 좋아하지는 않으며, 남들이 비스타 싫어하는 것만치 비스타를 싫어하지도 않는다. -_-;; 뭐, 비스타도 희한한 버그 의심 증상이 하나 있긴 했으나, SP1에서 곧바로 고쳐짐.

3.
<날개셋> 편집기는 txt 확장자를 자기 프로그램으로 연결한다거나 하지는 않는다.
그렇기 때문에 이렇게만 놔 둬서는 윈도우 7의 jump list를 활용하지 못한다. (윈7 사용자 중에 jump list가 뭔지 모르는 분은 없으리라 생각되지만, 어쨌든 모른다면 검색 요망)

탐색기에서 txt 파일을 우클릭하여 '연결 프로그램 선택 → 찾아보기' 등을 골라서 <날개셋> 편집기를 한 번이라도 지정한 뒤(꼭, 기본 연결을 시켜 놓을 필요는 없고 이렇게만이라도), 나중에 <날개셋> 편집기의 열기 대화상자로 txt 파일을 열고 나면 그건 앞으로 jump list 에 등재되게 된다.

jump list를 좀 더 창의적으로 활용하면, 편집기는 당장 저런 기본 용도만으로도 충분할 것이고(최근 파일 열기),
변환기는 클립보드 변환 같은 자주 사용할 만한 task를 등록해 놓을 수 있겠으며,
입력 패드는 자주 쓰는 보조 입력 도구를 실행과 동시에 바로 꺼내 놓게 할 수 있겠는데 더 자세한 활용법에 대해서는 좀 더 시간을 두고 고민해 봐야겠다.

4.
얼마 전엔 드디어 <날개셋> 한글 입력기 프로젝트를 비주얼 C++ 2010용으로 정식으로 포팅해서 빌드해 봤다. 특이사항으로는,

- 사소한 컴파일 에러가 있었으나, 더 깔끔하고 분명한 코드를 만드는 데 도움이 되는 에러였으며 쉽게 잡았다.
- VS 2010의 빌드 시스템은 $(TargetPath) 변수의 값을 예전과는 다른 방식으로 부여하는 듯하다. 그래서 이걸 조정하는 노가다를 매 프로젝트들마다 좀 해야 했다.

이것 외엔 딱히 트러블이 없었으니 무리 없이 잘 갈아탔다.

동일한 옵션으로 빌드했지만 x86 바이너리(32비트)들은 VS 2008과 비교했을 때 크기가 살짝 더 커졌고, x64 바이너리(64비트)들은 살짝 더 줄어들었다.
같은 코드를 빌드했을 때 바이너리 크기가 조금씩 더 커지는 건, VC6 이래로 개발툴이 업데이트되면서 비교적 일관되게 관찰되는 추세였다. 최적화가 인라이닝 등 코드 크기를 더 키우는 쪽으로 행해져서 그런 것 같다.

비주얼 C++ 2010은 C/C++ 언어도 빌드 중에 'Linking...'이라는 말이 안 뜨고 generating code...에 링킹이 포함되는 듯하다.
똑똑한 인텔리센스는 부러운 점이긴 하다만, 너무 커진 덩치, 이질감이 생긴 GUI와 도움말 시스템 때문에 2010은 개인적으로 언제쯤 도입하게 될지 모르겠다. 다만, 리소스 에디터가 드디어 윈도우 비스타의 PNG 내장 아이콘(256*256)까지 제대로 표시해 주는 점은 마음에 든다.

5.
내 경험상 윈7은 USB 메모리(스틱 or 외장 하드) 매체의 제거를 예전 OS에 비해 더 관대하게, 더 빨리 허용해 주는 것 같다. 해당 드라이브를 사용하는 프로그램들을 다 껐는데도 '사용 중이기 때문에 제거 못 함' 꼬장 때문에 할 수 없이 아예 OS를 로그오프하거나 아니면 그냥 강제로 매체를 제거해 버린 일이 거의 발생하지 않았다.

그리고 다른 얘기이다만, 윈도우 7은 Taskbar에 있는 각종 프로그램들 아이콘과 시스템 트레이의 아이콘을 드래그하여 마음대로 순서를 바꿀 수 있는 게 무척 인상적이다.
7에서 새로 바뀐 작업 표시줄은, 실행 중인 프로그램과(동일 프로그램이 중복 실행된 것 포함) 그렇지 않은 프로그램의 구분이 잘 되아 보이는 걸 개인적으론 안 좋게 생각했었다. 그러나 한동안 써 보니까 이게 그럭저럭 나쁘지 않은 디자인이라는 생각이 든다.

무엇보다도, 창을 몇 개씩 띄워 놔도 많이 띄웠다는 느낌이 심리적으로 안 드는 게 인상적임.
옛날에 윈9x의 전통적인 시작 메뉴 시절엔, 컴을 몇 년 쓰면서 수십 종류의 프로그램들을 설치하고 나니까 '프로그램' 메뉴 옆으로 프로그램 리스트가 두 칼럼 이상씩 차지하는 크고 아름다운 면적으로 주렁주렁 달렸던 거 기억하는가?

또한 인터넷 서핑하다가 브라우저 창이 열몇 개씩 넘어가니까 작업 표시줄 모습이 가히 가관으로 바뀌던 것도 기억하시는지? 윈도우 7은 복잡도를 제어하는 디자인에 무척 신경을 썼다..

6. 윈도우 비스타와 7 모두, 로그인 화면에서 암호를 입력하고 나면, 암호가 맞든 틀리든 일단 Welcome부터 출력하면서 설레발을 치다가 그 뒤에 암호가 틀렸으면 사용자 진입을 거부한다. “안 돼! / 돼!”도 아니고 츤데레도 아니고 이건 도대체 무슨 디자인일까?? -_-;;
암호가 맞을 때만 Welcome을 출력하게 개선되면 좋겠다.

7.
윈도우 9x는 프로그램을 조심해서 짜는 데에 도움을 준다.
NT 계열에서는 해제했던 메모리를 중복 해제하거나, 자원을 반납· 해제하는 걸 깜빡하는 식으로 대충 대충 짜도 당장 티가 안 나며 그냥 넘어간다. 그러나 9x에서 그랬다간 얼마 못 가 시스템 자원이 바닥난다거나 바로 뻗어 버리기 때문에, 이런 차이 덕분에 프로그램을 윈도우 9x에서 테스트하다가 버그를 발견하여 구조적인 문제를 해결한 경우가 지금까지 종종 있다.

아마 <날개셋> 한글 입력기도 한 2~3년 동안 윈9x에서 테스트를 안 한 채 개발을 계속하다가 버전이 1.0쯤 올라간 뒤에 다시 윈9x용으로 테스트하면, 여기저기서 원인을 알 수 없는 버그가 자꾸 튀어나와서 단순히 유니코드 API layer를 쓰는 것만으로는 윈9x를 결코 다시 지원할 수 없는 수준에 이를 것이다.
지금 <날개셋> 한글 입력기 소스가, 비록 같은 C++언어이지만 비주얼 C++ 6.0으로는 도저히 개발을 계속할 수 없는 이질적인 단계에 도달한 것처럼 말이다(각종 문법 차이 때문).

Posted by 사무엘

본인은 10여 년 전인 2000~2001년 사이에 세벌식 솔루션 3관왕-_-? 3총사를 차례로 최초로 개발하였다. 이 홈페이지 대문에 다 공개되어 있다.

하나는 주력 연구 작품인 <날개셋> 한글 입력기. 이건 사실 세벌식 글자판을 기본으로 삼아 한글 입력 체계에 대한 총체적인 연구를 목표로 하는 학술적인 프로그램이다. 이윤을 목표로 만드는 것도 아니고, 또 딱히 사용자 중심적으로 만드는 프로그램도 아니기 때문에, 여느 공개 소프트웨어에서는 찾을 수 없는 특이한 기능과 라이선스, 그리고 초심자가 언뜻 보기에 접근하기 어려워 보이는 복잡한 UI를 고수하고 있다.

뭐, 그래도 어쨌든 대부분의 일반 사용자들은 그냥 에디터가 하나 필요해서, 혹은 Shift+Space를 쓰거나 한글 로마자 글자판을 쓰려고, 혹은 세벌식 모아치기를 하려고, 또는 드보락 자판을 같이 쓰려고 이 프로그램을 사용한다. 하지만 그건 이 프로그램이 제공하는 기능의 완전 빙산일각일 뿐이다. 좀 외람된 비유이다만, 구원받아서 누리는 크리스천의 온갖 영적 복은 다 제끼고, 오로지 죽어서 지옥 안 가고 천당 가려고 예수 믿는 것과 비슷한 맥락이다. (엥?)

그리고 다음으로 잘 알다시피 타자연습 프로그램이 있다. 세벌식을 연습하려면 세벌식 사용자가 만든 세벌식에 최적화된 타자연습 프로그램이 있어야겠다는 생각을 해서 만들었다. 세벌식이 그냥 잉여 옵션이 아니라, 세벌식, 특히 최종 자판이 main인 프로그램.

사실, 아래아한글 워디안/2002가 리모델링된 한컴타자 유틸리티를 공개하기 전이던 2000년대 초엔, 세벌식 최종을 정식 지원하는 타자연습 프로그램은 박 정만 님이 개발한 '광타'밖에 없었다. 그리고 윈도우 운영체제와 아래아한글 97이 제공하던 최종 자판은 오류가 있었다. 그만치 최종 자판은 인지도가 안습하였다. 그런 와중에 세벌식 최종 전용 타자연습 프로그램인 <날개셋> 타자연습의 임팩트는 결코 작지 않았다.

타자연습은 잘 알다시피 한글 입력기의 한글 입출력 엔진을 빌려서 개발되었다. 비록 수 년 전부터는 입력기의 연구 개발에 밀려서 타자연습의 메이저 버전업이 중단된 상태이지만, 본인은 이 프로그램의 개발을 완전히 접거나 포기한 상태가 아니다. 껀수가 생기면 얼마든지 프로그램을 또 업데이트할 생각이다. 이 프로그램은 입력기보다는 훨씬 더 사용자 지향적으로 개발되고 있다.

다음으로 이 두 프로그램에 비해 인지도가 덜하고 <날개셋>이라는 브랜드도 붙어 있지 않으나, 또 아주 중요한 세벌식 솔루션이 마지막으로 있으니, 그것은 바로 세벌식 파워업이다.

세벌식 파워업은 세벌식과 관계가 있으나 <날개셋> 한글 입력기와는 무관한 프로그램이다. 이건 <날개셋> 없이 운영체제의 기본 IME만으로 세벌식을 쓰려는 사람에게 필요하다. 이 프로그램은 클릭 한 번으로 MS 기본 한글 IME의 두벌식/세벌식 설정을 간편하게 바꿔 준다. 이 외에도 화면에 세벌식 최종 글쇠배열을 띄워 놓는 기능과 한글 IME 제어판 설정을 바로 꺼내 주는 기능도 있어서 세벌식 사용자에게 무척 유용하다.

이 프로그램은 사실 <날개셋> 한글 입력기 1.0의 개발이 끝나고 정보 올림피아드도 끝났던 2000년 말에 처음으로 개발되었다. 레지스트리 설정을 바꿈으로써 윈도우 95/98/ME의 한글 IME를 대상으로는 잘 동작했으나, 2000에서는 동작하지 않았다. 하지만 이 기능만으로도 본인은 세벌식 사용자들에게서 칭찬과 감사의 말을 굉장히 많이 들었다.

그러다가 세벌식 파워업이 진짜로 ‘파워업’이 된 때는 2004년, <날개셋> 한글 입력기가 3.0으로 대폭 업그레이드된 그 시절이었다. 그때 두 가지 정말 큰일을 해냈다. 먼저 공유 메모리 패치 지점을 reverse engineering으로 찾아냄으로써, 드디어 2000/XP 등 모든 계열의 한글 IME에서 세벌식 자동 전환 기능을 동작시키는 데 성공했다. 그리고 다음으로, 당시 오류가 있던 MS 한글 IME의 세벌식 최종 글쇠배열을 아예 파일 차원에서 ‘패치’하는 엽기적인 기능을 추가했다!

그 당시는 <날개셋> 한글 입력기 3.0과 더불어 외부 모듈이 처음으로 개발되고 있었는데, 그러는 한편으로 MS IME 자체에 대한 연구도 진행되어, 그걸로 참고표와 가운뎃점을 찍는 방법을 찾아냈던 것이다. 이것 역시 <날개셋> 개발에 필적하는 쾌거였다.

파워업 프로그램이 마지막으로 큰 변화를 겪은 때는 그로부터 2년 반쯤 뒤에, 윈도우 비스타와 MS 오피스 2007이 나왔을 때이다. 이제야 정신을 차린 MS가 세벌식 최종 글쇠배열 오류를 고쳐 준 덕분에, 패치 기능은 이제 더 필요하지 않았다. 하지만 글자판 자동 전환 기능이 동작하려면 바뀐 메모리 변경 지점을 알아야 했기에, 그때는 VMware로 윈도우 비스타를 급히 설치하고, 아주 가벼운 개발툴인 비주얼 C++ 4.2 (무려 1996년 프로그램!)를 설치하여 그거 디버거를 이용해 메모리 변경 지점을 알아냈다.

윈도우 7/오피스 2010의 한글 IME는 윈도우 비스타/오피스 2007의 그것과 구조가 거의 같기 때문에 파워업의 추가적인 알고리즘 패치가 필요하지 않다. 하지만 파워업을 관리자 권한으로 실행하고 나면 한글 IME 설정 대화상자가 뜨지 않으며(그쪽에서 의도적으로 실행을 거부함), 관리자 권한으로 실행된 프로그램은 파워업의 글자판 전환 기능이 통하지 않는 문제가 있었다.
새로운 이슈가 발견된 셈인데, 글자판 전환 기능이 안 되던 문제는 최근에 다행히 간단한 조치 끝에 해결하여 패치를 등록하였다. 관심 있으신 분은 받아서 사용하기 바란다.

내가 왕년에 무슨 생각으로 무슨 똘끼를 발휘하여 이런 세벌식 솔루션을 세 종류나 만들어 버렸는지 모르겠다. 세벌식을 극도로 활용한 전문적인 한글 입력기, 그리고 세벌식 beginner를 위한 타자연습, 그리고 단순 세벌식 light user를 위한 파워업. 제각기 커버하는 영역이 있다!.

공교롭게도 이 세 프로그램은 유니코드 API를 지원하는 방식도 제각기 다 다르다. 입력기는 잘 알다시피 자체 제작한 호환 레이어가 있어서 유니코드 기반 바이너리로도 9x 계열 운영체제에서 동작 가능한 가장 정교하고 바람직한 구조로 되어 있다. 타자연습은 ANSI/유니코드 에디션이 제각각 빌드되어 있고, 파워업은 그냥 ANSI 빌드로만 배포된다. 한편, 64비트 바이너리가 따로 빌드되어 배포되고 있는 건 입력기가 유일하다.

본인은 이 프로그램들이 지난 10여 년 동안 세벌식의 보급에 큰 기여를 해 왔을 거라는 자부심을 갖고 있다. 고인드립이 될까 봐 조심스럽게 하는 말이지만, 공 병우 박사님이 5~10년 정도만 더 살아 계셨으면(1995년 타계) <날개셋> 한글 입력기가 개발되는 것도 보고 가셨을 텐데 하는 약간의 아쉬움도 있다.

내가 지금까지 왜 이런 짓을 했을까? 글쎄다. 딴 게 아니고 한글 같은 문자는 컴퓨터에서 두벌식으로만 쓰기에는 너무 아깝다는 막연한 관념이 있어서였다. 그리고 한글 기계화 이념에 관한 한은 세벌식만이 살 길이라는 강한 확신이 들어서이다. 그 생각은 10년 전이나 지금이나 변함이 없다. 좀 심하게 표현하자면 이렇게까지 말할 수 있다. “그 불편한 두벌식을 쓰면서 어떻게 한글이 우수한 문자라는 말을 할 수 있을까?”

지금은 세월이 흘러, 나의 감성을 건드리는 영역은 철도에게 자리를 많이 내 줬다. 세벌식 쪽은 그냥 워낙 오래 전부터 내가 전문적으로 연구해 온 분야이기 때문에 지금까지 그저 관성만으로 덕-_-력이 유지되고 있는 것도 있다.

그러나 세벌식은 그래도 너무 매력 있는 한글 글쇠배열이며, 동시에 한글 기계화의 근간을 이루는 교리이다. 요즘은 컴퓨터도 다들 멀티코어가 대세인데, 세벌식은 내가 예전에 글로 쓴 적이 있듯이 사람 손의 병렬화-_-에 유리한 방식이다. 이 글을 보시는 분들도 다들 이 기회에 세벌식으로 글자판을 바꿔 보시길 바란다. 터치스크린이 주류인 모바일에서는 세벌식은 동시치기를 통한 활로를 적극적으로 모색되어야 하지 않을까 싶다.

Posted by 사무엘

오늘날처럼 유니코드에 OpenType, subpixel 렌더링(ClearType 같은) 등의 최신 문자 처리 기술이 컴퓨터에 보편화해 있고 심지어 스마트폰조차 화면 해상도가 1000을 넘어서서 큼직한 윤곽선 글꼴로 글자를 찍는 세상에,

<날개셋> 한글 입력기의 편집기 프로그램은 20년 가까이 전의 유물인 구닥다리 8*16, 16*16 비트맵 글꼴을 여전히 고수하고 있다.
그 많은 시간과 노력을 들여서 에디팅 엔진을 따로 만들고, 그것도 그런 초라한 자체 한글 출력 시스템 기반으로 만들어야 할 특별한 이유가 있는 것일까?

여기에는 여러 정황상의 이유가 있다. 지금은 그 명분이 다소 약해진 것도 있지만, 큰 방향은 변하지 않았다.

첫째, <날개셋> 한글 입력기가 처음 개발되던 1999년 말~2000년 초에는 아직 PC 환경이 굉장히 열악했다.
당시의 주류 운영체제이던 윈도우 95/98은 내부적으로 아직 유니코드 기반이지 않았기 때문에, 운영체제의 기본 GUI로는 영문 윈도우에서 한글이 찍혀 나오지 못했다. 운영체제의 언어하고 다른 언어의 IME를 설치할 수도 없어서 Global IME 같은 별도의 특수한 프로토콜이 따로 있을 정도였다. 지금 생각하면 얼마나 격세지감인가?

그렇기 때문에 그 당시에 나름 한글 관련 기능으로 유명세를 탄 아래아한글, 이야기 같은 프로그램은 32비트 Windows 환경에서도 여전히 '자체 한글' 에디팅 엔진을 사용하곤 했다. 운영체제의 언어를 불문하고 한글 입출력 환경을 제공하기 위해서이다. 이 추세를 <날개셋> 한글 입력기 역시 따른 것이다.
뭐, 아래아한글만 빼면 나머지 자체 한글을 지원하던 이야기, 새롬 데이타맨, Token 2는 어차피 전통적으로 고정폭 글꼴이 강세인 터미널 접속 프로그램이기도 했고 말이다.

둘째, Windows 환경은 저런 국제화나 유니코드 이슈를 떠나서라도, 맥(TextEdit)이나 리눅스(gedit)에 비해 전통적으로 에디터 프로그램이 부실했다. 가령, 운영체제가 기본 제공하는 에디터 중에는(메모장+워드패드) syntax coloring이 제공되는 놈이 없고, 특히 MDI를 지원하는 놈도 없다.

운영체제의 에디트 컨트롤을 그대로 사용하는 메모장은 윈9x 시절엔 아예 64KB 메모리 제한이 있었다.
지금의 메모장은 비록 명목상의 메모리 제한은 없지만 내부적으로 단일 버퍼 구조인 건 변함없기 때문에, 몇백 KB 이상의 큰 파일을 여는 덴 여전히 부적합하다. 로딩 시간이 굉장히 길 뿐만 아니라 앞부분에다 글자를 삽입하거나 지우는 오버헤드가 굉장히 크다. 직접 해 보면 안다.
이런 와중에 에디터 프로그램을 하나 만들어 보는 것도 나쁘지는 않겠다는 생각이 자연스럽게 들게 된 것이다.

셋째, 글꼴 관련 문제 때문이다.
수많은 글꼴들이 범람하는 시대이지만, 영문과는 달리 한글은 화면 본문으로 쓸 만한 글꼴이 오늘날까지도 대단히 드물다.
인제 와서 맑은 고딕을 시작으로 ClearType에 최적화된 글꼴이 좀 개발되어 상황이 아주 약간 나아졌다만,
정말 15년 전이나 지금이나 화면용 글꼴은 굴림, 바탕 일색이다.

이럴 바에야, 좀 아마추어 냄새가 나긴 해도 옛날에 개발되었던 수십 종의 비트맵 글꼴들을 그대로 살려 쓸 수 있는 자체 한글 체계가 일종의 참신함과 매력을 줄 수도 있다.
하지만 이 장점은 도스 시절 비트맵 글꼴을 경험하지 못한 세대가 늘면서 점차 사라질지도 모르겠다. -_-;;

그리고 사실 이보다 더 큰 이유는 완전한 조합형 기반 세벌식 한글 표현 때문이다. <날개셋> 한글 입력기는 무려 2008년이던 과거 5.0 시절에 최초로 유니코드 5.2 옛한글을 앞서 도입했는데, 이 역시 독자적인 한글 입출력 시스템을 사용하기 때문에 가능했던 일이다.

굳이 옛한글이 아니더라도 가령 초성 ㄱ과 종성 ㄱ을 구분하고, ㄱ+종성ㄴ이나 ㅏ+종성ㅇ 같은 중간 형태 역시, 자체 한글 체계로는 아주 쉽게 표현할 수 있는 반면 Windows 제도권(?) 글꼴 시스템으로는 그럴 수 없다.
<날개셋> 한글 입력기의 특장점 중 하나가 초성만 쏙 지우고 모아치기를 하고 무한 낱자 수정을 하는 등, 그런 미완성 중간 한글을 남발하는 기능들이다! 그런데 그런 걸 화면으로 표현을 못 하면 어떡한단 말인가?

이건 프로그램의 본질적인 정체성이 달려 있는 문제이다.
극소수 옛한글 표현이 가능하게 설계된 글꼴로는 제도권으로도 저런 것들 표현이 가능하지만, 글꼴 파일 덩치가 심하게 크고 아름답다.. (한자가 같이 들어있는 경우가 많기도 하고)

글꼴이라는 게 오늘날 체계가 굉장히 복잡해져 있다. 그 이유 중 하나는 글립 인덱스 개수 한계 때문이다. 단일 글꼴만으로 유니코드 전영역의 글자를 담는 게 불가능하다. 글립 인덱스는 파일 포맷만 확장한다고 간단히 해결되는 게 아니라 이와 얽힌 각종 운영체제 API나 내부 구조체와도 연계가 되어야 해서 문제 해결이 더욱 어렵다.

그런 데에 얽매일 바에야 속 시원하게 <날개셋> 한글 입력기 같은 단순한 전· 반각 문자 체계가 유리한 점도 있다. 어차피 유니코드 영역의 대다수를 차지하는 주범은 한자이고, 한자는 전각으로 처리 가능한 아주 단순한 문자이니까 말이다. -_-;;

본인이 독자적인 에디팅 엔진과 글꼴 시스템을 개발한 마지막 이유로는, <날개셋> 한글 입력기는 단순히 입력기만을 지향하는 프로그램이 아니라는 점을 생각할 필요가 있다.

<날개셋> 한글 입력기는 '한글 IME' 계층과, 이 IME와 통신하면서 글자를 입력받고 수정하는 편집기 계층 사이의 통신 프로토콜까지 독자적으로 생각하고 구현한 시스템이다. 통신이 왜 필요하냐 하면 이미 있는 글자도 낱자 단위로 고치고 다시 조합을 재현해야 하기 때문이다. 그러니 이걸 모두 시연하려면 에디터를 직접 만들어야 한다. 이걸 만들면서 Windows 운영체제의 문자 입력과 관련된 표준 프로토콜을 모두 공부하고 구현하는 효과까지 달성했다.

<날개셋> 한글 입력기는 텍스트 필터라 하여 한글 입력 기능을 일괄 처리와 자동화하는 기능까지 제공하고 있다. 텍스트를 변형하는 기능을 제공하는 플랫폼 역시 자체적인 에디터 말고는 선택의 여지가 없다. 뭐, 텍스트 필터만 시연하는 게 목적이라면 기존 에디트 컨트롤만 끌어다 써서 만드는 것도 나쁘지는 않겠지만 말이다.

그래서 본인의 프로그램은 에디터를 제공하지만, 그렇다고 해서 전문적인 여타 프로그래머용 에디터를 표방하면서 개발되는 건 결코 아니다. 애초에 그런 부류와 경쟁하려고 만들어진 프로그램이 전혀 아니다.
오히려 <날개셋> 한글 입력기는 자체 에디터가 있고, Windows용 IME가 있고, 여타 프로그램 내부에서 IME를 훅킹하여 동작하는 입력 패드가 있어서 한글 입력기로서 존재할 수 있는 front end가 세 종류이다. 입력기가 존재할 수 있는 모든 경우를 상위 계층에서 생각하여 구현했다.

본인은 <날개셋> 한글 입력기가,
덩치 작지만 깊은 철학과 굉장한 활용 가능성이 있는 프로그램,
사람에게 휠체어가 아니라 자전거 같은 요긴한 도움을 주는 프로그램, (자동차급은 아니어도)
세벌식 기계식 타자기를 컴퓨터로 그대로 옮겨 놓은 듯한 고성능 고효율 프로그램,
한글을 마음껏 입력하고 싶은 생각이 절로 들고 한글 덕후에게 마음의 고향 같은 인상을 주는 프로그램이 될 것을 지향하며 개발하고 있다.

솔직히 내가 만들었지만 내가 생각해도 이 프로그램은 긍정적인 쪽과 부정적인 쪽 모두 좀 똘끼가 굉장히 충만한 프로그램이다. 어떻게 이런 걸 만들 생각을 했는지.. -_-

따라서 이 글의 결론을 한 줄로 요약하면,
<날개셋> 편집기는 앞으로도 글씨 크기 조절 기능을 제공할 가능성은 전혀에 가깝게 없을 것이다. ㅋㅋㅋㅋㅋ

Posted by 사무엘

6.5 버전! 이 얼마 만의 버전업인가.
몇 달간 마음의 부담으로 남아 있던 작업들을 상당수 이뤄 내서 매우 기쁘다. (☞ 받으러 가기)
편집기· 변환기· 내부 엔진· 외부 모듈 등 거의 모든 분야에서 골고루 많은 발전이 있었다.
내일(1월 7일) 공개라고 계획을 잡고 문서에도 다 그렇게 썼지만, 그냥 기분상-_- 하루 당겨 버렸다. ㄲㄲ

1.
지금 윈도우 7 + <날개셋> 6.3 이하 버전 사용자라면, <날개셋> 한글 입력기를 윈도우용 IME로 지정한 후 <날개셋> 한글 입력기의 About 대화상자를 꺼내 보기 바란다. 이 About 대화상자에는 키보드 포커스를 받는 컨트롤이 개발자 홈페이지를 여는 링크 컨트롤, 그리고 대화상자를 닫는 '닫기' 버튼 이렇게 두 개가 있다. 전자는 IME 입력을 받으나(비록 IME 입력이 아무 의미가 없긴 하지만), 후자는 버튼이기 때문에 받지 않는다.

두 컨트롤을 탭을 누르면서 반복해서 왕래해 보라. 그런데 포커스가 '닫기' 버튼에 있을 때 <날개셋> IME의 버튼들이 사용 불가(disable) 모양으로 흐리게(grayed) 바뀌는가, 그렇지 않은가? (흐려져야 맞음. MS IME와 동작을 비교해 볼 것)

깜짝 놀랐고 내 눈을 의심했다.
윈도우 7이 출시된 지가 2년이 넘었는데 이런 버그가 아직까지 있는 줄은 꿈에도 몰랐다.
혹시 예전에는 없었다가 새 버전에서 추가되고 바뀐 기능 때문에 새로 갑작스럽게 생긴 버그이진 않은가 해서, 5.3대의 엄청 옛날 버전을 깔아서 이걸로도 확인해 봤다. 그러나 동일 증상이 여전히 발견됐다.

이 정도면 고질적인 버그를 하나 찾아내서 잡은 것이기 때문에 readme에다가도 적지 않을 수가 없다. 후대 버전에서 몰래 생긴 버그라면 문서 기록 따위는 남기지도 않았을 텐데. 비스타는 해당사항 없고 오로지 7에만 존재하는 문제이다. (이번 6.5에서 해결됨)

그 많고 많은 윈도우 7 사용자 중에 왜 이 기본적인 버그를 지적하는 사람은 지금까지 없었을까?
윈도우 7은 IME 쪽이 생각보다 굉장히 많이 바뀌어서, 예전에는 이 정도까지만 적당히 짜 주면 됐던 게 거기서만 이상하게 까탈스럽게 구는 게 많다. 전반적으로는 좀 엄격하게 바뀐 것 같다. 이것 때문에 <날개셋> 한글 입력기도 5.5 때는 5.51, 5.52 같은 자질구레한 패치가 나와야만 했다..

2.
개인적으로는 근래에 패턴 치환 필터를 정말 유용하게 썼다.
엑셀에서 복사하여 탭으로 구분되어 있는

A B C D E

형태의 데이터를

insert into Table1 values('A', 'B', 'C', 'D', 'E');

형태의 SQL 쿼리로 직통으로 바꾼다거나,

제목
1 문장A
2 문장B

이런 텍스트에서 제목은 삭제하고 숫자와 탭으로 구분된 문장만 다 뽑아내는 것,

그리고 심지어

0xAC, 0x50, 0xB7

같은 숫자 배열을

"\xAC\x50\xB7"

처럼 문자열 상수 형태로 바꾸는 것도 패턴 치환으로 다 가능하다. 패턴 치환과 더불어, 일괄 치환 기능도 익혀 놓으면 아주 유용하다.

<날개셋> 편집기가 겉보기로는 정말 허름한 에디터 같아도, 한글 입력 기능뿐만 아니라 보조 입력 도구와 텍스트 필터를 생각하면 결코 만만하지 않을 것이다. 비록 저런 기능이 <날개셋> 한글 입력기의 주 개발 목표는 아니며, 편집기가 매크로 기능을 직접 제공하지는 않지만, 저런 게 매크로 자동화 기능이나 마찬가지이다.

3.
다음 버전은, 이젠 진짜로 한자 관련 시스템을 제발 업그레이드 좀 해야겠다. 번호는 6.7로 계획했다. <날개셋> 한글 입력기 개발 역사상 최초로 버전 번호에 7이 들어갈 예정.

일대일로만 가능하던 한자 후보 변환을 다대다로 확장하여 단어 단위 한자 변환 기능을 넣고, BMP 영역만 취급 가능하던 각종 한자 처리 시스템을 surrogate까지 지원하도록 확장한다.
지금 옵션이 달랑 3개밖에 없어서 황량한 '편집기 계층' 제어판 대화상자에는, '가능하면 글자 대신 단어 단위로 한자 변환', 그리고 'BMP뿐만 아니라 surrogate 영역 한자도 사용' 이라는 한자 관련 옵션이 최소한 두 개 더 추가될 예정이다.

그리고 다중 candidate를 도입한다. 이건 이번 6.5에서도 터닦기 작업은 해 놨다.
특수글쇠를 보면 한자 후보 기능 글쇠가 예전처럼 하나만 있는 게 아니라 4개가 존재하는데,
1번 default candidate은 전통적인 한자나 초성 특수문자인 반면, 2번부터 4번까지는 customize 가능한 다른 후보 변환을 할 수 있게 하는 것이다. 가령, 한자 변환 대신 구결 변환을 넣는다거나 하는 식으로 활용이 가능하다.

'<날개셋> 고급 입력기'뿐만이 아니라 기본 입력기도 후보 데이터의 사용자 정의의 폭이 크게 넓어진다는 뜻이다. 물론 이미 후보 데이터 편집 기능을 갖추고 있는 '고급 입력기' 역시 늘어난 후보 개수에 맞게 그 구조가 확장되어야겠지만 말이다.

한자 키는 예전과 같은 1번 candidate이지만, Shift+한자는 2번 candidate를 배당하면 된다. 아직 터닦기만 해 놓고 그 기능이 실제로 구현되지는 않은 6.5에서는, 여전히 1번 candidate만 사용 가능하다.

끝으로, 장기적으로는 <날개셋> 편집기의 한자 변환 대화상자도 지금의 외부 모듈과 같은 UI로 바꾸려는 계획이 세워져 있기도 하다.

이런 식으로 한자 시스템 업그레이드는 여러 대규모 작업들이 한데 얽혀 있는 '군'(group; family)을 이루고 있다. 작업의 일부만 해내도 프로그램 버전이 최하 0.1 이상은 충분히 올라갈 수 있다.
치밀한 계획을 세워야 하고, 프로그램 API가 크게 바뀔 수도 있는 장기전을 감수해야 할 수도 있기 때문에, 이걸 지금까지 선뜻 추진하지 못한 것이다. 이제 6.5 다음 버전에서는 할 수 있겠지.

그리고 부가적으로는 보조 입력 도구 쪽도 편의 기능을 강화할 예정.
예를 들어, 화면 키보드에서 마우스 클릭만으로 Shift 윗글쇠를 입력할 수 있게 하는 것 말이다.
다음 버전인 6.7(가칭)의 개발 방향· 테마는 이런 식으로 이미 다 잡혀 있다.

Posted by 사무엘

1. 정렬 기능

컴퓨터에서 문자열 정렬은 아주 중요한 작업이다.
문자라는 게 디지털 컴퓨터에서는 0과 1의 조합인 숫자로 표현되는 만큼, 코드 번호 값의 대소로 문자를 비교하는 게 가장 직관적이고 당연하고 가장 합당하긴 하지만... 현실은 시궁창.

유니코드의 역사가 워낙 길어지면서 빈 영역 여기저기에 온갖 잡다한 문자들이 추가되었고, 이 때문에 단순 코드값 비교에 따른 정렬은 옛날에 비해 의미가 상당수 퇴색했다. 결국은 비교를 위한 별도의 테이블이나 알고리즘을 또 가지고 있어야 할 지경이 됐으니 말이다.
한글도 옛한글 자모가 몇 차례 나뉘어 추가되어서 좀 지저분해졌다. 그래도 유니코드 5.2 이후로 또 변화가 있을 것 같지는 않으니, 그 이상은 내 관심사 밖이다.

정렬을 할 때는 대소문자 구분을 하지 않는 게 보통이다.
그런데 <날개셋> 한글 입력기가 제공하는 정렬 필터는 한 걸음 더 나아가, 대소문자를 구분하지 않은 두 문자열이 동일하다면, 원래 형태대로 비교를 다시 해서 대소를 가리도록 로직이 다음 버전부터 수정될 예정이다. 경우에 따라서는 이렇게 해 주는 게 유용할 수도 있을 것 같아서이다.

정렬 전	그냥 대소문자 무시 정렬	대소문자 무시+2순위 고려
Base CASE SAFE Vase base safe vase Safe BASE Case case	Base base BASE CASE Case case SAFE safe Safe Vase vase	BASE Base base CASE Case case SAFE Safe safe Vase vase

그래서 WORD, Word, word라는 단어가 모두 존재하면, 똑같은 word라 해도 오름차순에서는 언제나 저 순서가 유지되게 된다. 대소문자뿐만 아니라 전/반각, 한자 독음 비교 같은 다른 옵션에 대해서도 동일한 원칙이 적용된다.

하지만 본인이 아는 유명 프로그램들 중 저걸 배려하는 프로그램은 전혀 없다. 아래아한글, MS 워드, 엑셀, EditPlus, AcroEdit 등... 대소문자 구분을 안 시키면 그 내부에서는 word, WORD, Word 순서는 전혀 지켜지지 않는다.

그뿐만이 아니라 다음 버전에서는 문자열 중의 숫자를 natural order로 비교하는 옵션이 추가된다. 쉽게 말해, A100을 A9보다 나중에 오게 하는 것 말이다. 1은 9보다 먼저 오지만, 100은 9보다 더 큰 수이기 때문.

구현해 놓고 써 보니, 이거 생각보다 굉장히 유용한 기능이다. 왜 진작에 이런 기능을 안 넣었는지 모르겠다. “작은 코딩, 큰 만족”이 프로그래밍 덕질의 아드레날린이며 중독성의 원천이다.

숫자 비교는 자릿수가 더 많은 놈부터 먼저 쳐 주는 로직만 넣으면 끝날 것 같지만, 00100과 101 같은 훼이크도 조심해야 하고, 마이너스와 소숫점까지 생각하면 알고리즘이 의외로 복잡해진다.

현재 정렬 필터는 내부적으로 Quick sort를 사용하지만(unstable 알고리즘), 각 아이템들의 원래 배열 순서도 비교할 때 고려해 주기 때문에, 동일한 아이템끼리도 안정성(stability)이 보장된다. 유니코드 5.2 기준 모든 옛한글의 순서를 정확하게 비교해 내고 아래아한글처럼 종성부터 비교하는 옵션이 있을 뿐만 아니라, 저런 면까지 나름 꼼꼼하게 고려해서 구현되어 있다. ^^;;

2. 아이콘

다음 버전부터는 <날개셋> 변환기와 입력 패드의 아이콘이 바뀔 예정이다.
변환기는 뭔가 변환 메커니즘을 나타내는 회전 화살표가 담긴 아이콘이며,
입력 패드는 그 용도답게 태플릿+스타일러스가 그려진 아이콘이다.

요즘은 인터넷에 예쁜 아이콘들 갤러리가 넘쳐나니, 아이콘도 직접 그리는 것보다는, 이미 그려진 걸 찾아서 찜하고 필요하다면 구입하는 게 나은 세상인 듯하다. 맞춤복보다는 기성복 구도?
물론 아이콘의 출처는 프로그램 도움말의 '일러두기' 란에 명시될 예정이다.

<날개셋> 편집기의 아이콘인 빨간 수첩^^;;은 과거 비주얼 C++이 예제로 제공하던 아이콘이 그 전신이다. EditPlus도 동일 컨셉이긴 하나, 수첩을 펼친 방향이 <날개셋> 편집기의 그것과는 정반대이다.

이 컨셉으로 큼직한 트루컬러+알파 채널 아이콘까지 그려 주신 분은 옛날 인터넷 세벌식 사랑 모임의 운영자이던 이 정민 님이다. 그게 벌써 2003년의 일인데 3.0 시절부터 8년이 넘게 동일 아이콘을 쓰고 있는 셈.

이것 말고도, 마치 지금의 상명 대학교의 로고타입처럼 한글 자모를 세로로 풀어 써서 <날개셋> 자체를 형상화한 '기본 아이콘'도 있는데, 이건 외부 모듈이 사용하고 있다.

외부 모듈은 편집기나 입력 패드처럼 다른 여러 응용 프로그램들하고 비교되는 게 아니라, Microsoft IME처럼 이미 같은 입력기들과 비교된다. 그러니 이 프로그램이 IME라는 건 누구나 다 알고 있고 <날개셋>이라는 브랜드가 중요하므로, 프로그램의 기본 아이콘으로 이걸 그냥 쓰는 것이다.

<날개셋> 기본 아이콘의 컨셉은 1.0 만들 때 본인이 구상한 것이다. (당연히 상명 대학교의 로고타입을 모르는 상태에서 디자인한 것임. 우연의 일치. ㄲㄲ) 이를 트루컬러 이미지로 각색하신 분 역시 이 정민 님이다.
참고로, 외부 모듈은 파란 기본 아이콘이고, <날개셋> 타자연습은 여러분도 다 잘 알다시피 초록색 기본 아이콘을 쓰고 있다.

프로그램의 아이콘에 이어 도구모음줄의 각종 아이콘도 트루컬러나 256색화할 때가 되긴 했다만, 흠.. 귀찮다.;;
이렇게 프로그램 UI에 들어가는 각종 이미지들의 기술 수준이 상승했건만, 비주얼 C++의 자체 IDE가 제공하는 아이콘 편집기는 트루컬러+알파 채널, 심지어 요즘 같은 PNG 이미지가 embed된 아이콘을 제대로 열지 못한다. 그런 거 하나 만들려면 이제 별도의 '싸제' 그래픽 에디터를 써야 하니 불편하다.

VC++ 6.0 시절에는 트루컬러 이미지 자체를 열질 못했다. 그런데 256색까지밖에 읽어들이질 못하는 주제에, 내 기억이 맞다면 VC6의 IDE는 JPG 파일을 열 수는 있었다. 그리고는 JPG 사진을 256색으로 '디더링'-_-해서 표시해 줬다. 흠좀 많이 무섭죠? -_-

3. 찾기/바꾸기 대화상자

<날개셋> 편집기의 다음 버전은 찾기/바꾸기 대화상자의 디자인이 살짝 바뀔 예정이다.
'뒤로 검색'은 별도의 옵션으로 존재하지 않으며 버튼 자체가 '다음 찾기'와 '이전 찾기'로 따로 존재함으로써 탐색 방향을 결정하게 된다.

그리고 '처음부터 찾기' 옵션이 별도로 추가되며('이전 찾기'를 하면 문서 끝부분부터 찾게 됨), F3/Shift+F3으로 찾기를 계속하다가 문서의 끝부분에 도달했을 때는 자동으로 첫 부분으로 돌아가서 다시 찾게 할 수 있다.
'처음부터 찾기' 옵션을 지정하고서 '모두 바꾸기'를 누르면 지금 커서 위치에 상관없이 문서 전체에서 찾기/바꾸기를 일괄적으로 수행할 수 있다.

예전에는 '뒤로 검색'을 선택하면 F3이 역방향 검색, Shift+F3이 그 반대인 순방향 검색이었으나,
이제는 F3은 언제나 순방향 검색, Shift+F3이 역방향 검색이 된다..

4. 기본 IME로 지정 옵션

마치 웹브라우저에 자신을 운영체제의 기본 브라우저로 지정하는 옵션이 있듯,
드디어 추가되었다.
'TSF A급 확장 옵션'만 달랑 남아있던 '고급 시스템 옵션'에 이게 들어갔다.

사실 원래 의도했던 건, 프로그램을 설치할 때 “<날개셋> 한글 입력기를 기본 IME로 지정” 옵션을 추가하는 것이었다. 이게 아주 자연스럽지 않은가?
하지만 Windows Installer가 도대체 프로그램을 어떤 환경에서 구동하는지, 그때는 기본 IME 지정이 죽어라고 되지 않아서 어쩔 수 없이 설치 후에 사용자가 이렇게 하는 걸로 디자인을 바꿨다.
이것만으로도 운영체제 제어판을 일일이 꺼내는 것보다 마우스 클릭질을 상당히 줄일 수 있다.

물론, 이미 기본 IME로 지정이 된 상태라면, 버튼은 disable된다.

5. 이 외에도 이번 6.5에서는 드디어 기본 입력 스키마의 '글쇠 인식 옵션'에, 기존 47개 글쇠 94개 자리뿐만이 아니라 임의의 단축글쇠에다가 글쇠를 배당하는 기능이 추가되어 Shift+Capslock을 모아치기/이어치기/풀어쓰기 변환을 한다거나, Numlock 상태의 키패드에다가 한글 입력 방식을 구현한다거나 하는 활용이 가능해진다. 이것도 지금까지 꽤 오랜 숙원이었다. 쉽게 말해 지금 편집기 계층에 있는 '단축글쇠 테이블'이 입력기 계층으로도 일부 내려온 거라고 생각하면 된다.

단타를 하나 인식하는 것까지가 '기본 입력 스키마'가 하는 일이고, 그 이상 더 변칙적인 입력... 가령 동시치기라든가 한 글쇠를 눌렀다가 떼거나 오래 누르거나 하는 것은 '동시입력' 같은 별도의 스키마가 담당하게 될 것이다.

또한, 임의의 글쇠를 인식하는 것과는 반대로 이미 인식하는 글쇠도 인식을 하지 않게 할 수 있다.
예를 들어 표준 두벌식 글자판은 A~Z까지 알파벳 26개 글쇠만 영문과 다를 뿐 나머지 숫자와 기호는 영문과 동일하다. 그래서 MS IME가 동작하는 걸 보면, 두벌식에서는 숫자와 기호는 IME가 아예 가로채지 않으며, 응용 프로그램에는 IME 메시지가 아니라 일반적인 키보드 메시지가 전달된다. 세벌식일 때만 모든 글쇠를 가로챈다.
이것을 <날개셋> 한글 입력기도 이제 사용자가 지정함으로써 구현 가능해진다는 뜻이다. 숫자나 기호 글쇠를 등록한 뒤, '글쇠 독점하지 않기' 옵션을 지정하면 된다.

6. <날개셋> 한글 입력기의 외부 모듈은 TSF A급 환경에서는 전용 편집기와 비슷한 독자적인 텍스트 조작을 지원했다. 이미 조합이 끝난 한글도 낱자 단위로 지우고, 앞 글자에 조합 상태로 달라붙는 기능 말이다. 하지만 현대 한글과는 달리, 2글자 이상의 조합으로 표현되는 옛한글에 대해서는 그런 기능을 제공하지 않았다(못했다). 글꼴과 코드, 운영체제 차원에서 프로토콜 지원 미비, 응용 프로그램마다 동작 방식의 차이 등 여러가지 기술적인 이유 때문이다. 이는 앞으로 Windows 운영체제가 개선되어야 할 사항이다.

하지만 이번 6.5 버전에서는 비스타/7의 TSF 확장 모드에 한해서... 다시 말해 확장 옵션이 켜진 상태에서 웹브라우저의 입력란과 메모장(일반 에디트 컨트롤)에서 유니코드 옛한글의 고급 조작을 시범적으로 enable해 보았다.
TSF 확장 모드 자체가 아직 상당히 불안정하고 오동작이 많은 모드이긴 하지만, MS 워드나 워드패드 같은 원조 TSF A급 환경에서는 고급 조작이 “아예 불가능했다”.

제한적이나마 이제 옛한글도 낱자 단위로 지우고 달라붙어지는 게 신기하다.
사실, <날개셋> 편집기도 이론적으로는 <날개셋> 외부 모듈의 고급 조작을 완벽하게 지원한다. 하지만 그건 어차피 홈그라운드이고, 외부 모듈 말고 자체 입력기도 쓸 수 있는 환경이니, 별 의미는 없다.

이것 말고도 이번 6.5는 내부적으로 프로그램 완성도가 강화되고 각종 버그가 수정된 게 엄청 많다.
2012년의 첫 글은 아주 희망적인 글로 시작했다. 새 버전이 몹시 기대된다.

Posted by 사무엘

Posted by 사무엘