오늘날처럼 유니코드에 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 사무엘
