나빌입력기는 윈도우에서 동작하는 오픈 소스 한글 입력기 입니다. libhangul 자체를 윈도우에서 빌드하여 직접 사용하는 한글 입력기입니다. 그래서 한글 오토마타는 리눅스의 ibus, fcitx와 동일합니다. 모두 libhangul을 사용하니까요.

기존에 오픈 소스 윈도우 한글 입력기는 제가 조사한 범위에서는 새나루 입력기(https://kldp.net/saenaru/)가 유일했습니다. 새나루 입력기 역시 KLDP에서 활동하시던 개발자님들께서 만든 작품이지요. 새나루 입력기에 이어서 나빌 입력기는 사실상 두번째로 공개된 윈도우용 오픈 소스 한글 입력기입니다.

윈도우용 오픈 소스 한글 입력기 나빌 입력기

어쩌다가 시작하게 되었나...

지난 크리스마스 휴가 때 저는 기존 세벌식 자판을 연습하다가 도저히 적응하지 못하고 그냥 저 혼자 사용할 요량으로 3-18Na 자판(https://kldp.org/node/160815)을 만들었습니다. 그리고 만든 자판을 실제로 사용하기 위해서 리눅스용 입력기 3종 (scim, ibus, fcitx)를 수정해서 3-18Na 자판을 실사용 가능하도록 만들었습니다. 저는 이것만으로 충분했습니다. 왜냐하면 저는 한글 입력을 리눅스에서만 하거든요. 윈도우에서는 사실 한글 입력을 할 일이 별로 없었습니다.

다만, 윈도우에서 한글 입력을 할 일이 별로 없을 뿐이지 아예 없는 것은 아니니깐요. 어쩌다 한 번씩 윈도우에서 한글 입력을 하는데 이 때도 3-18Na 자판으로 입력이 하고 싶다는 생각이 갑자기 들었습니다. 무엇보다 더 큰 이유는 크리스마스가 지나도 새해까지 아직 휴가가 남아 있었기 때문이지요.. 이 때 그냥 독서나 하면서 휴가를 보냈어야 했습니다.

이 일이 이리 큰 삽질이 될 줄이야.. 그 땐 몰랐습니다.

새나루 입력기나 대충 고쳐서 구현하면 되겠지 했습니다...

저는 애초에 윈도우에서 새로운 입력기를 만들 생각이 아예 없었습니다. 리눅스에서 그랬던 것처럼 기존에 알려진 입력기를 수정해서 3-18Na 자판만 쏙 넣는 것으로 하루나 이틀 정도 작업하여 마무리 하려 했습니다.

그 첫번째 작업으로 윈도우용 한글 입력기가 뭐가 있나 조사해 봤습니다. 의외로 윈도우에서 한글 입력기는 종류가 많지 않았습니다. 아마도 윈도우의 기본 한글 입력기로도 불편함이 없이 충분히 쓸 수 있기 때문인것 같습니다. 가장 유명한 것은 당연히 윈도우 기본 한글 입력기입니다. 그리고 쉽게 찾을 수 있는 서드파티 한글 입력기는 새나루 입력기와 날개셋 입력기가 있었습니다. 이게 다 였습니다. 기본 입력기를 제외하면 딱 두 개 있더라구요.

새나루 입력기와 날개셋 입력기 중에 날개셋 입력기는 기능이 매우 많았습니다. 그런데 오픈 소스가 아니더라구요. 그래서 일찌감치 배제했습니다. 물론 날개셋 입력기의 커스텀 키보드 설정 기능으로도 저의 목적을 이룰 수는 있었으나 그냥 코딩으로 해결하고 싶었어요. 그래서 새나루 입력기의 소스 코드를 수정해서 간단히 목표 달성을 하려 했습니다만 결과적으로 이 선택은 저를 엄청난 삽질의 길로 인도했습니다.

어라.. 빌드가 안되네..

새나루 입력기의 소스 코드를 다운 받았습니다. 이 때만 해도 저는 윈도우의 입력기 시스템에 대해 아는 것이 전무했습니다. 그냥 대충 새나루 입력기 소스 고치면 되겠지 하는 생각으로 들이댄 것이지요. 일단 코드 수정의 시작은 빌드입니다. 빌드를 해야 저의 수정 작업을 테스트할 수 있으니까요.

파일 중에 makefile이 보이길래 일단 다짜고짜 make를 쳐 봤습니다. 당연히(?) 안되더군요. 그제서야 makefile을 텍스트 편집기로 열어서 내용을 읽어 봤습니다. 새나루 입력기의 makefile과 빌드에 관여하는 파일들을 통해서 저는 새나루 입력기를 빌드하려면 윈도우 DDK가 필요하다는 사실을 알았습니다. 문제는 여기부터 였습니다. DDK는 너무 오래된 것이라는 것이지요. 마이크로소프트에서 DDK를 WDK로 바꾼지도 십년이 훨씬 넘게 지났습니다. 이제 DDK는 다운로드 받을 수 조차 없는 이름만 남은 존재였던 것이지요.

그래도 저는 마이크로소프트라면 하위 호환성을 고려해서 WDK를 만들었을 거라 순진하게 생각했습니다. 그냥 새나루 입력기의 소스 코드를 WDK 프로젝트에 파일 단위로 뜯어서 때려 넣고 강제로 빌드해 봤습니다. 역시나 안되더라구요...

뒷목에 서늘한 기운이 스쳐지나갔습니다. 이러면 나가린데... 여기서 안되면 답없는건데... 에라이! 안해. 그냥 윈도우에서는 두벌식 쓰지 뭐.

TSF(Text Service Framework)

그날 밤, 자려고 누워서 그날의 삽질을 머릿속에서 리뷰하고 있었습니다. DDK라니... 새나루 입력기가 좀 오래되긴 했지... 개발 중단된지도 오래 되었고... 그래도 DDK 라니...

그러면서 핸드폰으로 윈도우에서 입력기를 어떤게 만드는지 가볍게 찾아봤습니다. 윈도우는 TSF(Text Service Framework)라는 이름으로 윈도우 XP 시절부터 입력기에 대한 운영체제 수준의 인터페이스를 만들어 놨더군요. TSF 만해도 발표된지 십 년이 넘은 물건이었습니다. 그래서 여전히 침대에 누운채로 TSF를 이용해 구현한 중국어나 일본어 입력기들 중 소스 코드가 공개된 것들이 있는지 찾아 봤습니다. 깃헙에서 몇 개 찾을 수 있었고 마이크로소프트에서 TSF 샘플 입력기 소스 코드도 공개해 놨네요. 오.. 그냥 얘네들 대충 고치면 될 것 같다는 생각이 듭니다. 그냥 생각만 하고 말았어야 했습니다....

여기서 그냥 하지 말았어야 했는데, 단지 궁금해서 조금 더 공부해 봤습니다. 윈도우의 입력기는 TSF 이전에는 IMM이라는 프레임워크가 있었다고 합니다. 그래서 다시 새나루 입력기의 소스 코드를 봤더니 놀랍게도 IMM과 TSF에 관계된 함수 콜이 둘 다 있었습니다. 아마도 처음에 IMM 기반으로 만들고 시간이 지나면서 TSF 관련 코드가 추가된것 같습니다. 키 입출력 관련 코드는 IMM 기반이었고 TSF 기반 코드는 윈도우의 시스템 트레이에 아이콘을 표시하는 코드가 전부였습니다. 이 시점에서부터 저는 새나루의 소스 코드를 참고하지 않았습니다. 왜냐하면 한글 오토마타 관련은 libhangul에 맡길 계획이었으므로 제가 필요한 코드는 입력기의 껍데기를 구성하는 코드이기 때문이었습니다. 그러니까 저는 윈도우의 입력기 껍데기만 만드는데 앞으로 이야기할 삽질을 한 것입니다.

아니.. 이건 인스톨을 어떻게 하는 거야?

가장 먼저 만져본 코드는 마이크로소프트에서 공개한 샘플 입력기 소스 코드였습니다. 마이크로소프트 사이트와 깃헙에서 구할 수 있습니다. 일단 소스 코드를 다운로드하고 바로 빌드해 봤습니다. 역시 마이크로소프트에서 공개한 것이라 그런지 비주얼스튜디오 무료버전에서도 빌드가 한 번에 잘 되었습니다. 결과로 나오는 파일은 dll이네요. 윈도우 입력기가 dll이라는 것을 처음 알았습니다...

이제 이 dll을 어떻게 시스템에 등록해야 입력기를 쓸 수 있는 건지 readme 파일을 읽어 보았습니다. 인스톨쉴드(installshield)를 이용해서 인스톨러를 만들어서 인스톨하라고 하네요. 수동으로 등록하는 방법에 대한 설명은 없었습니다. 문제는 비주얼스튜디오 무료버전은 인스톨쉴드를 쓸 수 없다는 것이었습니다. 이런 어처구니 없는 경우가 다 있나...

시스템에 입력기를 등록하는 방법을 모르니, 코드를 수정해서 빌드해도 테스트를 해 볼 수가 없는 상황인 것입니다. 이쯤에서는 이제 조금씩 오기가 올라오기 시작하더라구요.

중국어 입력기, 일본어 입력기

그러면 깃헙의 중국어나 일본어 입력기들은 인스톨을 어떻게 하는건지 찾아 봤습니다. 보통 소스 코드에 인스톨 방법을 설명하는 텍스트 파일을 같이 배포하니까요. 그것도 없으면 최소한 빌드 스크립트를 해석해서라도 수동으로 설치하는 커맨드나 방법 혹은 순서를 알아낼 수 있으니까요.

이 과정에서 마이크로소프트의 샘플 입력기과 중국어 입력기 두 개, 일본어 입력기 세 개 정도의 소스 코드를 봤습니다. 일단 모두 마이크로소프트의 샘플 코드를 기반으로 해서 만든 것이라는 것을 알 수 있었습니다. 파일 구성이나 클래스 이름, 반복되는 코드의 구성이 같았습니다. 어떤 코드는 아예 똑같았습니다. 그리고 모두 과도하게 복잡하고 파일이 많았으며 코드의 양이 많았습니다. 이게 모두 필요한 코드인가라는 생각이 끊임없이 들었습니다.

나중에 안 사실이지만 중국어 입력기나 일본어 입력기는 한글 입력기에 비해서 복잡할 수 밖에 없는 구조적 특징이 있더라구요. 그들에 비하면 한글 입력기는 더 적은 코드와 더 간단한 코드로 구현이 가능했습니다.

구글

이렇게 지난 삽질을 돌이켜 보고 있으니 초반에는 코딩보다 검색질을 더 많이 했네요. 이런저런 입력기 코드들을 계속 찾고 있었습니다. 그 중에 가장 구현이 단순하고 코드의 양이 적은 것을 찾는 것이 목표였습니다. 그러다가 우연히 구글이 크롬 프로젝트의 부분으로 다국어 입력기를 구현해서 코드를 공개해 놓은 것을 찾았습니다. 물론 코드의 양과 복잡도는 제가 찾아 본것 중 가장 복잡했습니다.

저는 이 구글의 입력기 소스 코드를 보지 않았습니다. 그러나 여기서 아주 중요한 정보를 얻었습니다. 바로 인스톨하는 방법이었지요. 구글 소스 코드의 텍스트 파일 중에 수동으로 인스톨하고 언인스톨하는 방법이 설명되어 있었습니다. 황당하게도 매우 간단했습니다. 대체 마이크로소프트는 이 간단한 커맨드를 왜 알려주지 않고 인스톨쉴드를 사용하는 방법을 적어 놓았을까... 지금도 이유를 모르겠습니다.

COM

한 십 몇년 전? 아니 얼추 이십년 정도 되었나? 서점가에 COM 개발 관련 책이 쏟아져 나오던 때가 있었습니다. Common Object Model의 약자던거 할거에요. 그 때나 지금이나 저는 윈도우용 프로그램 개발에는 딱히 관심이 없어서 용어만 알고 그게 뭔지 전혀 모르고 코드 타이핑하면서 잘먹고 잘 살아오고 있었습니다.

여러 윈도우용 입력기 소스 코드들을 보니 공통적인 파일과 함수 구성이 보였습니다. 동일하게 모든 입력기가 가지고 있는 코드 였지요. 그래서 그 파일과 함수의 이름으로 검색을 해 보았습니다. 그랬더니 이것들이 COM 라이브러리를 작성할 때 구현해야 하는 함수들이라는 겁니다.

그리고 그제서야 TSF가 COM 기반으로 만들어졌다는 글을 위키페디아에서 읽었습니다. 분명 이 삽질을 시작할 무렵에도 동일한 문서를 읽었는데 그 때는 눈에 들어오지 않았던 정보가 이제는 인식이 되는 재미있는 경험을 했습니다.

어쩌다 보니, 윈도우에서 COM의 구성 원리, 작동 원리, 작동 순서, 샘플 코드, 예제 테스트까지 다 하고 말았습니다. 그러고서야 COM을 이해할 수 있었습니다. 이 쯤해서는 내가 왜 이걸 하고 있는 목적 의식조차 흐릿해 지고 있었습니다.

그냥 바닥부터 뜯어서 만들자

COM을 이해하고 났더니 윈도우 입력기의 소스 코드의 실행 흐름에 따라 코드를 읽을 수 있게 되었습니다. 그러면서 기존 중국어, 일본어 입력기와 샘플 입력기(이것도 사실은 중국어 입력기)에서 TSF 관련 정보를 추출해서 용어를 찾을 수 있게 되었습니다. 이들 중에서 내가 필요로 한 것들과 필요로 하지 않는 것들을 구분해야 하기 때문이죠.

처음에는 샘플 입력기의 코드를 조금 고쳐서 이름을 바꾸고 아이콘을 바꾸는 것부터 시작했습니다. 그러나 어느 시점에서부터 코드 복잡도가 올라가더니 제가 생각했을 때 불필요한 요소를 떼어내기가 매우 어려워졌습니다. 샘플 입력기도 태생이 중국어 입력기다 보니 구조적으로 한글 입력에 불필요한 요소가 강결합되어 있었던 거죠.

그래서 개발 방향을 바꿨습니다. 그냥 제가 바닥부터 코딩을 하는 것이죠. 재료는 다 있으니 필요한 코드를 뜯어다가 재조립해서 한글 입력기를 구현할 요량이었습니다.

그래서 처음에는 그냥 새나루 입력기의 소스 코드를 살짝만 수정해서 하려했던 작업이 입력기를 처음부터 새로 만드는 삽질로 변질되어 버리고 말았습니다. 이참에 이름도 나빌 입력기 (Navil IME)로 지었습니다.

UI 드럽게 안되네

TSF 설명에 따르면 간단한 코드로 시스템 트레이의 입력기 아이콘을 클릭해서 메뉴가 나오게 할 수 있습니다. 관련 내용을 구현한 예제 코드도 있고요. 그런데 막상해보면 메뉴가 안나옵니다. 뭔짓을 해도 안나오더라구요. 생각할 수 있는 모든 옵션 조합을 시험해 봤는데도 실패 했습니다.

입력기 자체 UI를 통해서 키보드 레이아웃을 변경하는 UX를 구상했는데 물건너 갔습니다. 그래서 꽤나 리눅스스러운 방법으로 키보드 레이아웃을 설정해야 합니다. 어떤 방법이냐고요? 설정 파일을 텍스트 에디터로 수정하는 거죠 뭐.

컴포지션.. 컴포지션..

리눅스든 윈도우든 우리가 컴퓨터로 한글을 입력하면 지금 문자를 구성하고 있는 글자는 선택 영역으로 자동으로 선택되어 반전되어 보이고 커서는 잠시 사라지면서 한글 한 글자를 감싸는 네모가 깜박거립니다. 이 깜박이는 선택 영역 안에 있는 글자가 조합중인 (compositing) 글자 입니다. 중국어나 일본어의 입력기 UI는 이런식이 아닌지 제가 확보하고 있던 소스 코드들 모두 한글의 컴포지션 커서를 보이게 하는 코드가 없었습니다. 정말 수 많은 삽질 끝에 조합 중인 글자의 커서를 보이게 하는 옵션을 찾았습니다. 해결 방법은 몹시 간단하게도 설정값을 false에서 true로 바꿔 주기만 했더니 제가 의도한 대로 되더라구요.

만약 제가 참고 할 수 있는 윈도우 한글 입력기 소스 코드가 하나라도 있었다면 이 삽질은 안했을거라 생각됩니다. 그리고 그런점에서 나빌 입력기의 공개는 의미가 있다고 생각됩니다.

컴포지션 완료

지금 텍스트 에디터 아무거나 열고 한글을 입력해 보세요. 한글은 한 글자를 종성 혹은 중성까지 입력하고 다음 자모를 입력하기 전까지 글자의 완성 여부를 알 수 없습니다. 다음 글자의 초성을 입력해야 직전 글자의 완료 여부를 알 수 있는 것이지요. libhangul에서는 preedit과 commit이라는 이름으로 작성 중인 글자와 완료된 글자를 알려줍니다. 그래서 글자가 완성되면 입력기는 글자 두 개를 어플리케이션에 보내야 합니다.

이 부분에서 엄청난 삽질을 했습니다. 왜 인지는 모르겠으나 직관적인 방법은 동작을 하지 않더군요. 완성된 글자의 컴포지션이 완료되면서 다음 글자의 초성이 오른쪽에 붙어야 하는데 컴포지션 완료가 되지 않고 없어져 버리거나 아니면 다음 글자의 초성이 표시되지 않는 등 다양한 증상이 보였습니다. 이것 역시 원하는 동작을 만들기 위해서 조합 가능한 거의 모든 동작 조합을 코딩해서 테스트해 봤습니다.

결국 겉으로 보기에 원하는 동작을 구현하긴 했으나 이게 과연 정석인 방법인지 아직도 확신은 없습니다.

어플리케이션마다 다른 동작

입력기를 만들 때 테스트하는 가장 기본적인 어플리케이션은 누가 뭐래도 그냥 메모장입니다. 일단 메모장에서 다 되게 만든 다음 다른 어플리케이션에서 테스트하는 것이지요.

메모장에서는 별 문제 없이 동작하는데 워드패드에서는 TSF 콜백 인터페이스 함수의 호출 순서가 다른 현상이 있더군요. 이런것 하나도 통일되지 않은 시스템이라니..

파이어폭스의 구글 검색 입력창에서는 선택영역이 없어져 버리는 현상도 생겼습니다. 그래서 입력중인 글자가 풀어쓰기 마냥 쭉 늘어져 보이기도 했지요. 예를 들면, "나빌레라" 라고 입력하는데 보이는 것은 "나비빌레라" 이런식으로 나오는 겁니다.

이렇게 현 시점에서 확인 가능한 문제들 중 어플리케이션마다 다르게 동작하는 것들은 일부는 해결을 했고 일부는 해결을 못했습니다. 일단은 제가 쓰기 별 문제 없으면 현재는 고칠 생각도 의지도 없으니까요.

libhangul

나빌 입력기는 libhangul을 그대로 사용합니다. libhangul은 정말 훌륭한 프로그램입니다. 공식적으로 지원하지 않음에도 별다른 큰 노력없이 (물론 아주 조금 포팅 작업을 하긴 했습니다.) 윈도우에서 빌드가 되었습니다. 그래서 빌드되어 만들어진 lib 파일을 나빌 입력기에 링크해서 사용했습니다.

덕분에 저는 큰 노력 없이 나빌 입력기에서 3-18Na 자판을 비롯해 두벌식, 세벌식 3-90, 3-91, 옛한글 자판등 libhangul에서 지원하는 자판을 모두 지원 할 수 있었습니다.

더불어 지난번에 리눅스 입력기 작업을 할 때 libhangul의 소스 코드 버전이 깃허브 버전과 타르볼 버전이 달라 깃허브 버전 코드를 수정을 못했었는데 이번 기회에 libhangul의 깃허브 기준 최신 소스 코드 기반으로 3-18Na 자판을 추가하는 작업을 완료했습니다. 벼르고 있었는데 겸사 겸사 해 내니 기분이 좋군요.

수정한 libhangul의 코드는

https://github.com/navilera/libhangul

에서 볼 수 있습니다. 관심 있는 분들은 한 번 들어가서 보세요.

새나루 입력기의 유산

나빌 입력기는 새나루 입력기로부터는 코드 한 줄도 받아 오지 않은 프로그램입니다. 저는 그게 뭔가 아쉽더라구요. 뭔가 DNA를 이어가고 싶었는데 말이죠. 그래서 코드 대신 아이콘이라도 써야 겠다 싶어서 나빌 입력기의 메인 아이콘은 새나루 입력기의 아이콘을 그대로 사용했습니다.

왜 이런 긴 글을 써서 올리는가?

요즘같은 시절에 누가 이런 긴 글을 읽는다고 이리 긴 글을 써서 올리는가 하면, 제가 나빌 입력기를 사용할만한 수준으로 만들긴 했는데 테스팅이 턱없이 부족했습니다. 그래서 이왕 프로그램을 공개하는거 삽질기도 같이 공개할 겸, 3-18Na 자판 연습도 할겸, 또한 나빌 입력기 테스트도 할 겸해서 긴 글을 쓰고 있는 것입니다. 아직까지는 별 문제 없네요.

없는 기능

libhangul에서 지원하나 나빌 입력기에서는 지원하지 않는 기능이 있습니다. 바로 한자 입력 기능인데요. 일단 한자 입력을 만들려면 candidate UI라고 해서 꽤나 골치 아파 보이는 삽질을 해야만 합니다. 저는 정작 한자 입력을 전혀 쓰지 않는데도요.

제가 쓰지 않는 기능이니 일단 저는 만들지 않았습니다. 혹시라도 누군가 한자 입력 기능이 꼭 필요하신 분 있으면 만들어 주세요. 오픈 소스 좋다는 것이 이런것 아니겠습니까.

오픈소스 한글 입력기의 베이스 코드가 되길 바라며

저는 나빌 입력기가 널리 쓰여 세상을 이롭게 하거나(...) 엄청 흥한 오픈 소스 프로젝트가 되는 것을 기대하지 않습니다. 제가 바라는 것은 어쩌면 나중에 또 누군가가 윈도우에서 TSF로 한글 입력기를 만들려 도전할 때, 나빌 입력기의 소스 코드가 그들에게 훌륭한 기본 재료가 되었으면 하는 것입니다.

그래서 나빌 입력기는 꼭 필요로 하는 TSF 구성 요소만 사용했고 되도록 코드를 간단하게 작성하려 했으며, 테스트 결과 동작에 영향을 미치지 않는 것으로 판단되는 코드는 모두 삭제하여 정말 최소한의 코드로만 만들었습니다. 그래야 코드를 읽는 사람도 금방 이해 할 수 있으니까요. 제가 했던 삽질을 다른 사람은 하지 않았으면 하는 것이 저의 바람입니다.

나빌 입력기의 소스 코드는

https://github.com/navilera/NavilIME

에 공개했습니다. 혹시라도 관심 있는 분은 사용해 보시고 버그 리포트나 풀 리퀘스트 보내주세요. 환영합니다.