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

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

윈도우 운영체제용 한국어 키보드 드라이버에는 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 사무엘

본인은 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 사무엘