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

여러 기호(또는 문장 부호)들 중에서 따옴표는 컴퓨터로 입력할 때 좀 유별나게 처리되고 다뤄지는 면모가 있는 문자이다.
일단 따옴표는 기호가 쌍으로 붙은 큰따옴표와, 하나만 있는 작은따옴표로 나뉜다. 전자는 어떤 발언을 직접 인용할 때, 그리고 후자는 발성이 타인에게 실제로 들리지는 않는 혼잣말이나 생각을 인용할 때 통상 쓰인다.

그러나 이런 물리적인 구분이 명확하지 않은 경우도 있다. 재미있는 것은, 따옴표로 둘러싸인 인용문의 내부에 또 인용문이 또 등장할 때는 물리적인 구분과는 무관하게 맞은편 따옴표가 작은→큰→작은..의 순으로 번갈아가며 쓰인다는 점이다. 또한 따옴표들은 완전한 문장이 아니라, 문장 내부의 특정 단어를 단순히 강조하는 용도로도 쓰인다.

따옴표는 괄호와 마찬가지로 열고 닫는 구분이 있다. 그러나 타자기나 컴퓨터의 글자판에는 괄호와는 달리 여닫는 따옴표가 따로 배당되어 있지 않다. 방향 구분이 없는 "와 '가 각각 큰따옴표와 작은따옴표의 역할을 대신한다.

텍스트 에디터는 코딩용으로도 쓰이고 키보드에 배당된 아스키 문자가 그대로 입력되는 게 중요한 경우가 많기 때문에, 따옴표도 있는 그대로만 입력받는다. 그러나 워드 프로세서 정도 되면, 지금 입력하는 문맥에 따라 해당 문자를 여닫는 따옴표로 알아서 치환해서 입력해 준다. 여기서 아주 재미있는 차이가 존재하는데, 아래아한글은 전통적으로 이런 구분을 한글 글자판을 쓸 때만 하는 반면 MS 워드는 글자판 구분 없이 언제나 그렇게 동작한다.

글쎄, 한글 입력 방식에서는 세벌식 최종 글자판이 여는 큰따옴표와 닫는 큰따옴표가 따로 배당되어 있고 그걸로도 모자라 "까지도 있다. 이것은 컴퓨터에서는 다소 잉여스러운 설계인지도 모르겠다. 그 대신, 영미 문화권의 텍스트 문서에서는 tilde 글쇠의 아래에 있는 `가 종종 여는 작은따옴표로 쓰이고 기존 '(어퍼스트로피)는 닫는 작은따옴표로만 쓰이는 경우가 있다. 한국에서는 보기 힘든 관행인 듯.

얼마 전에 본인은 여닫이 구분이 없는 따옴표만 쓰인 빽빽한 영어 성경 텍스트의 따옴표들을 여닫이 구분이 있는 형태로 일괄 변환할 수 있겠느냐는 부탁을 주변으로부터 받은 적이 있었다. 그냥 "만 달랑 들어있으면 왠지 아마추어스러운 티가 팍 날 테니, 인쇄해서 책으로 낼 텍스트라면 그 정도 배려는 해 주는 게 좋을 것이다.

"를 계속 찾으면서 “와 ”로 번갈아가며 대치만 하는 걸로 일이 끝이면 얼마나 좋았겠냐만, 이거 패턴이 의외로 간단하지만은 않음을 알 수 있었다.
작은따옴표는 어퍼스트로피가 존재하기 때문에 닫는 따옴표의 개수가 더 많아진다. 더구나 s로 끝나는 단어의 뒤에 붙은 어퍼스트로피는 닫는 작은따옴표와 형태적으로 구분할 방법이 없다.

그리고 큰따옴표와 작은따옴표 모두, 인용문이 여러 문단에 걸쳐서 길게 반복되는 경우라면, 이전 문단에서는 닫는 따옴표로 마무리가 되지 않은 채 다음 문단에서 또다시 여는 따옴표가 나온다. 물론, 그렇지 않고 앞 문단에서는 여는 따옴표로 시작해서, 다음 문단에서는 닫는 따옴표로 곱게 끝나는 인용도 따로 있고 말이다.

그리고 아까 얘기했던 중첩 인용도 문제가 될 수 있다. 열큰(여는 큰따옴표)와 작큰(작은 큰따옴표) 다음에 입력되는 큰따옴표는 여는 큰따옴표가 되어야 하는데, 이런 점을 고려하지 않고 기계적으로 따옴표를 치환하면 “(열큰) “(열큰) ”(닫큰) ”(닫큰)의 순으로 등장해야 할 따옴표가 “(열큰) ”(닫큰) “(열큰) ”(닫큰)으로 잘못 짝지어질 위험이 있다.

텍스트에는 최대 3단계의 중첩 인용이 존재하더라. 이거 생각보다 꽤 복잡하지 않은가?
텍스트 매크로, 찾기/바꾸기 등 여러 방법 중 과연 어느 것이 가장 적합할지 고민했는데 결국은 여러 차례의 바꾸기 기능을 사용하기로 결정을 내렸다. 여는 따옴표가 확실한 조건을 지정해 준 뒤, 나머지 따옴표는 모두 닫는 것으로 간주하는 게 가장 속 시원하다. 구체적인 절차는 다음과 같다.

1. 줄의 맨 첫 칸에 등장하는 따옴표는 반드시 여는 따옴표이다. 상식적으로 문단이 닫는 따옴표로 시작하지는 않을 테니 말이다. 그래서 줄의 처음을 의미하는 정규 표현식 ^를 사용하여, 첫 칸의 따옴표부터 다 여는 걸로 모두 바꾼다.

2. 그리고 공백(whitespace) 다음에 등장하는 따옴표는 반드시 여는 따옴표이므로 그렇게 바꿈.

3. 끝으로, 여는 따옴표의 다음에 등장하는 따옴표도 반드시 여는 따옴표이다. (여는 큰따음표 다음의 작은따옴표. 그리고 vice versa)

4. 위의 조건들을 만족하지 않고 아직도 방향이 결정되지 않은 따옴표들은 모두 닫는 따옴표이다. 치환.

이 작업을 큰따옴표/작은따옴표별로 다 해야 하기 때문에 '모두 바꾸기'를 무려 8번이나 해 줘야 한다.
그러나 <날개셋> 편집기에서는 '일괄 치환' 텍스트 필터에다가 다음과 같은 조건을 주면 일격에 상황 종료. 굉장히 유용하다.

"\n\"","\n“"
"\n'","\n‘"
" \""," “"
" '"," ‘"
“',“‘
"‘\"",‘“
',’
"\"",”

따옴표가 특별한 의미로 쓰이는 곳에서 따옴표 자체를 지정해야 하다 보니, 글자를 알아보기가 몹시 힘들다. 게다가 코딩용 폰트가 아닌 폰트는 여는 따옴표와 닫는 따옴표도 형태를 분간하기가 쉽지 않은 경우가 태반.
타자기 내지 컴퓨터 키보드에서 따옴표의 방향 구분이 별 의미 없다고 간주하여 괜히 없앤 게 아닌 듯하다.

아울러, 데이터베이스 같은 곳에서는 문자열 내부에 또 큰따옴표가 들어있을 때, 문자열의 시작을 '큰따옴표 두 개'로 표현하는 경우가 있다. 다음은 그런 문자열을 원래대로 복원하는 일괄 치환 조건이다.

"\"\"","\""
"\"",

그러고 보니 방향 구분이 없는 큰따옴표는 "위와 같음"(상등)을 의미하는 기호로도 쓰이며, 심지어 작은/큰따옴표가 각각 분과 초를 의미하는 단위로도 쓰인다. 신기하다. 본인은 이 경우까지 고려하지는 않았다.

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.

2012년이 다 저물어 가고 있다.
일단, 올해 하반기에는 문화· 정치적으로 모처럼 아주 기쁜 소식이 있었으니 그것부터 먼저 회고하고 넘어가야겠다.
바로 한글날이 22년 만에 다시 빨간날로 회복된 것! 그것도 미우나 고우나 이 명박 정권 때 이뤄졌다.
결정이 하도 지지부진하니 내년 달력을 만드는 업자들이 “이거 한글날은 빨간날로 해야 됩니까, 말아야 됩니까? 빨리 결정해 주세요!” 라고 독촉을 할 정도였다고 하는데.. 결국은 통과됐다.

알다시피 한글날은 원래 과거의 식목일처럼 공휴일인 기념일이었다. 그랬는데 노 태우 정권 때 공휴일에서 제외되어, 근처의 '철도의 날', '학생의 날'처럼 안 쉬는 여러 기념일 중 하나로 전락했다.
노 무현 정권 때는 국경일로 승격됐으나, 제헌절처럼 “안 쉬는 국경일”이라는 희대의 이상한 어정쩡한 날이 되었다.

그래서 한글 학회, 한글 문화 연대 같은 순수주의 어문 운동 단체에서는 수 년째 정부를 상대로 청원을 넣고 시민 계몽을 하고, 올해는 특히 온갖 기자 회견과 퍼포먼스를 연 끝에 드디어 승리를 쟁취해 냈다.
너무 무리하게 말을 순화하자는 식으로 약간 극단적인 주장에 모두 공감을 할 수는 없지만, 그래도 이 단체들이 정말 훌륭한 일을 해 냈다. 잘한 건 잘한 것으로 인정하고 이들의 열정을 칭송해 주자.

한글날 공휴일 지정을 가로막아 온 최종 보스는 역시나 경제 단체였다.
경제 단체들의 강력한 반발 때문에 산업 기능 요원 제도도 병무청이 단호하게 못 없앴다는 점을 감안하면, 얘들이 하는 짓이 다 병크는 아니다. 허나 공휴일이 너무 많다는 논리로 한글날 공휴일화를 반대하는 건 이미 안 통하는 논리이다. 안 그래도 우리나라는 노동자들의 근로 시간이 이미 세계 최상위를 다툴 정도로 길며, 우리나라는 대체 공휴일이라는 개념이 없기 때문에 날짜수만 평균 이상이지 실질적인 노는 날 수는 그리 많지 않다.

설령 공휴일이 정말 너무 많다면, 성탄절과 석가탄신일부터 칼질을 하는 게 순리일 것이다. 종교 공휴일 때 노는 나라는 주변의 CJK 중에서도 K밖에 없다. 이것도 합리적이고 이성적인 국민이라면 누구나 공감하는 바인데 왜 국민들 뜻대로 선뜻 안 되는 걸까?

“국경일 중에 삼일절 같은 날은 중요한 날이긴 하지만, 딱히 기쁜 날은 아니다. 그러나 한글날은 해당 국가의 정치나 종교와 관련이 없으면서 오로지 문화적으로 레알, 진정으로 경축할 가치가 있는 기쁜 날이다.” 이 점을 기억하자.
한글날도 공휴일이 됐는데 이제 사형 집행만 좀 부활하면 정말 잃어버려진 과거 회복이고 기쁜 일이 될 텐데...

2.

자, 그리고 비주얼 스튜디오 2012를 드디어 회사에서 깔아서 써 봤다.

외형이 또 심하게 달라졌다. 아무리 버전업이 돼도 3.x나 6.x나 아이콘 하나 안 바뀌고 외형이 심하게 변화가 없는 <날개셋> 한글 입력기에 비하면 MS의 변화를 위한 변화 저력은 정말 대단한 수준이 아닐 수 없다.
2012는 우중충한 군청+보라 배색이던 2010과는 달리, 은색· 회색· 흰색 배색으로 확 바뀌었으며, 2010과는 달리 non-client 영역에 일반적인 thick frame조차도 없다. 무슨 말이냐 하면 옛날의 아래아한글 97급으로 외형이 독자적인 형태가 됐다는 뜻이다.

16컬러풍으로 회귀한 아이콘 디자인, 그러데이션에서 단색(solid color)으로, 동그란 모서리에서 각진 사각형으로 회귀한 건 영락없이 10여 년 전의 VS .NET 첫 버전을 떠올리게 하는 외형이다. 아니, 윈도우 8 자체가 전반적으로 복고풍이다.
물론, 배색만 단순해졌을 뿐, 안티앨리어싱이 적용되어 아이콘의 색상 수 자체는 여전히 트루컬러급이다. 16컬러 “풍”으로 바뀌었을 뿐이지, 진짜 16컬러로 후퇴한 건 아님. ㅎㅎ

외형뿐만 아니라 2012는 기능도 무척 강화되어, IDE 에디터에서는 사용자가 선언한 명칭이 청록색으로 따로 표시되고, 굳이 Ctrl+Space를 누르지 않아도 첫 타부터 인텔리센스 자동 완성이 슝슝 튀어나온다. 오오~~

그리고 성능 분석과 프로파일링 기능이 더욱 강화되었으며, 소스 코드 정적 분석 기능이 드디어 추가되어 고품질 코드를 만드는 데 더욱 기여하게 되었다. 정적 분석 기능은 이전 버전의 VS에서도 있긴 했으나, 제일 비싼 엔터프라이즈급 버전에만 있었기 때문에 개인 인디 개발자가 접하기는 어려웠다.

<날개셋> 당장 다음 버전은 여전히 VS 2010으로 빌드할 예정이나, 이 버전의 사용 기간은 의외로 짧아질지도 모르겠다. 그리고 정적 분석을 돌려서 소수나마 코드에 존재하는 몇몇 논리적인 문제를 해결하기도 했다.

3.

지난 12년간 <날개셋> 한글 입력기를 통해 얻은 것은

• 수능, 내신 다 씹어먹고 대학 진학 성공
• 한글 연구 진영에서는 절대부동의 인지도 확보. 병역특례 TO도 사실상 그것 덕분에 얻은 거나 마찬가지
• 인디 소프트웨어 개발자(개인 개발자) 커뮤니티에서의 인지도 확보
• 보수적으로 잡았을 때 국내외에 몇천 명 정도로 추정되는 사용자와 잠재적 지지자. 국내는 물론이고, 생각지도 못했던 나라의 현지인이나 교포에게서 한글 로마자 입력 방식, 신세벌식, 세벌식 무한 낱자 수정 등등을 고맙게 잘 쓰고 있다는 연락 받았을 때 굉장한 보람 느꼈음.
• 몇 차례의 대회/소프트웨어 공모전 입상을 통한 통산 몇백만 원 정도의 상금 수입
• 거기 들어간 기술의 일부를 떼어 주는 개인 개발 용역으로 통산 1천몇백 만원 정도의 수입 (그리 큰 액수는 아니지만, 상대적으로 쉽고 재미있게 덕업일치를 이루면서 번 돈이라는 게 중요)
• 학부 시절, 졸업/개별연구 명목으로 5학점 정도의 전공 학점 기여. 학술지 논문 1회 게재
• 석사 논문 주제와 학위

그리고 무엇보다, 한글을 내가 원하는 어떤 방식으로도 입력하고 다룰 수 있으면서도 마치 기계식 타자기를 컴퓨터로 옮겨 놓은 듯한 한글 오덕질용 작고 가벼운 에디터. 그리고 Windows 운영체제에서는 거의 만렙을 찍은 한글 IME가 내 컴퓨터에 있다는 것에 대한 자부심과 정신적 만족감. 그걸 내가 혼자 다 만들었다는 것에 대한 성취감. 이로부터 파생되는 한글에 대한 자부심, 애국심 등등이다.

다음으로 잃었거나 어쨌든 줄어든 것은..

• 적절한 대학 GPA (ㅋㅋㅋㅋㅋ)
• 의대, 공무원, 대기업, 공기업 등에 들어가기 위한 스펙 쌓을 기회 (정말 하나도 거들떠보지도 않았다..)
• 여타 분야나 IT 기술에 대해 관심을 갖고 익힐 여유
• 연애와 결혼 기회 (...)

이 정도면 수지 맞는 장사이려나..? ㅋ

4.

내가 개인적으로 아쉬움을 느끼는 것은, '한국어 공학'에 비해서 '한글 공학'의 위상이 굳건하지 못하다는 점이다.
한국어 공학과 한글 공학은 목표는 비슷하지만 다루는 대상과 방법은 상당히 다르다.
그리고 내 관심분야는 '한국어 공학'이 아니라 '한글 공학' 쪽이다.

한글 자체만으로 오덕질을 할 거리가 전혀 없고, 더 발전할 거리가 보이지 않았다면 나도 그냥 사전학, 코퍼스 언어학, 자연 언어 처리 같은 데 관심을 뒀을 수도 있다.
아니, 언어학 쪽에 관심을 둘 필요조차 없이 그냥 자동차나 컴퓨터, 심지어 철도만 연구하는 평범한 공돌이의 길을 갔을 가능성이 높다.
그러나 문자가 저렇게 있는 걸 보니, 그걸 연구하지 않고서는 다른 분야는 도저히 못 파겠다..

물론, 지금 분위기를 이해를 못 하는 건 아니다.
지금이 옛날 같은 타자기나 XT/286 컴 시대도 아니고 문자 기계화 자체만으로 뭘 더 연구할 게 있는지 의아해할 만도 하다.

그래서 '한글 공학'은 문과 계열보다 오히려 언어학을 전공하지 않은 여타 분야 이공계(특히 입력기 쪽)나 디자인 분야(당연히.. 글꼴 쪽) 종사자들이 더 연구하는데.. 그쪽에서는 반대로 언어학 기반이 없으니 연구의 깊이에 한계가 있다.

그러나 한글은 주변의 한자나 라틴 알파벳이나 일본 가나와는 구조가 확연히 다른 문자이고, 그 조합 원리 자체만을 이용해 얼마든지 오덕질을 하고 입출력 기능을 더 다양하게 확장할 수 있다. 내가 늘 말하지만 한글은 두벌식으로만 입력하기에는 너무 아깝고 천편일률적인 정사각형 네모꼴로만 쓰기에도 너무 아까운 문자이다. 그래서 그런 학문 경계들을 허물고, 한글 입력과 출력 모두에서 새로운 솔루션을 만드는 게 꿈이긴 하나...

대학원의 박사 진학은 일단 좌절되었다.
나는 정말 이 분야를 가고 싶고 특정 교수의 학풍을 계승하고 싶은데 실력이 부족해서 떨어진 것이라면, 몇 번이고 입시에 재도전을 했겠지만, 나는 그런 경우가 아니니 내 연구 주제를 감당이나 지도를 못 하겠다고 교수님들이 날 받아 주지 않았다.

내 연구 주제는 특정 단과에 맞아 떨어지는 게 아니기 때문에, 딱 석사를 마쳤던 대학원에서 박사를 안 받아 주면 나는 딱히 다른 대학원을 갈 데도 없다. 그러니 난 최종 학력은 그냥 석사로 만족해야 할 듯하다.
논문 쓰는 게 힘든 한편으로 재미있었고 이런 걸 또 쓰라면 쓰겠는데, 그걸 하지 말라니 어쩔 수 없지. 이해를 하며, 원망은 안 한다.

한편으로는 이게 밥벌이가 돼야 할 텐데 하는 우려도 좀 든다. 당장 내가 몇 달 안으로 생각하고 있는 건,

• 날개셋 마이너 업데이트 (6.7x. 다음 달 초-중순쯤 나올 예정)
• 지금까지 내가 만들어 놓은 것들에 대한 문서를 재정비. 홈페이지와 프로그램 도움말 주요 내용을 영작
• 날개셋 메이저 업데이트 (6.9? 7.0? 윈도우 8용 IME 온전히 완성)

정도. 이미 내가 벌여 놓았고 관성 때문에 계속 진행해야 하는 일들은 이 정도에서 몇 개월 안으로 슬슬 끝을 볼 생각이다.
그 다음으로는 공부가 너무 소홀했던 IT 여타 분야 기술과 지식도 좀 독학하고, 무엇보다도 글꼴로 체제 변환을 하여 비밀 프로젝트를 몇 년간 진행할 예정이다.

그 결과물을 학계와 업계에 발표했는데도 이와 관련된 다른 일자리나 추가 수입이나 반향이 없다면..
2015년쯤 이후부터는 본인도 한글 관련 연구는 다 접고, 그냥 회사에서 시키는 일만 하는 소프트웨어 개발자로 돌아가거나 심지어 철도 업종으로 전업을 하거나, 공무원/고시 준비생-_-으로 돌아갈지도 모르겠다.

뭐, 그 정도의 최악의 상황까지도 각오는 하고 있다. 그러나 나의 20대와 30대 초반을 정말 건전하고 뜻있는 일을 하는 데 정열을 바쳤다는 사실에는 어떤 경우든 후회가 없다.

Posted by 사무엘

문화 체육 관광부와 국립 국어원에서 2009년부터 해마다 <국어 정보 처리 시스템 경진대회>라는 걸 개최하여 올해로 4회째를 맞이했는데, 올해는 예전의 인서울 관행을 깨고 부산 영도에 있는 한국 해양 대학교에서 개최되었다. 개최 일자는 지난 10월 12일. 공교롭게도 한글 운동 단체들에서 열심히 밀고 있는 조선어 학회 수난 70주년 추모 행사와 겹치는 날짜였다. 그건 서울 경복궁에서 열렸고 저 경진대회는 부산에서 열렸다.

말은 경진대회이지만 사실 참가자들이 동일한 조건에서 시험을 치면서 기량을 겨룬다거나 하는 건 아니기 때문에 사실은 '공모전'이 더 정확한 명칭이다. 일차적인 개최 목적은 21세기 세종 계획(1998~2007) 때 구축된 세종 말뭉치를 이용하여 한국어 분석과 관련된 의미 있는 데이터 처리를 하는 싸제 프로그램의 개발을 독려하는 것이다. 하지만 그 외에도 한국어와 한글의 기계화 및 교육과 관련된 유용한 소프트웨어라면 무엇이든 괜찮다. 본인은 독자 여러분도 잘 알다시피 작년(3회) 대회 때 <날개셋> 한글 입력기 6.3을 출품하여 은상을 받았다.

주최 측에서는 이 대회를 꽤 의욕 있게 밀고 있다. 내년에도 내후년에도 끊임없이 계속해서 대회를 주최할 것이라는 의지를 밝힌 바 있으며, 작년부턴가 기존의 <한글/한국어 정보 처리 학술대회>와 이 경진대회를 아예 병행해서 개최하기 시작했다. 그리고 올해에는 심사에 앞서 오전에 부스를 만들어서 일반인과 심사위원이 모두 참관 가능한 작품 전시(데모) 세션을 추가했으며, 게다가 작년 대회 입상자 중에도 원하는 분은 올해 대회의 데모 세션에 같이 참여해 달라고 초청장을 보냈다.

내 프로그램을 홍보할 기회가 왔으니 나는 초청을 거절할 이유가 없었고, 지난 10월 12일엔 회사에 휴가까지 내어 오랜만에 부산에 좀 갔다 왔다.
경부선 막차인 밤차를 타고 부산에 도착한 건 새벽 4시 반이 덜 돼서였다. 미리 봐 놓은 지하철과 시내버스 경로로 대회 장소엔 예정보다 훨씬 일찍 도착했다. 다만, 세월이 세월인지 밤샘은 이미 엄두를 못 내는 지경이 됐고 밤차도 더는 피곤해서 못 탈 것 같다. 피곤이 밀려오기 시작한지라 책상에 엎드려서 자면서 시간을 보냈다. 밤차는 교통비(굳이 비싼 고속 교통수단을 쓸 필요 없음)와 숙박비(차에서 잠을...)를 아낄 수 있는 저렴한 방법이지만, 제일 피곤한 방법이기도 하다.

부스 개방 시각이 다가오자 대회 주최 측에서 직원이 와서 각종 장비들을 세팅해 줬다. 나는 간단히 준비해 온 유인물과 프레젠테이션 슬라이드로 부스를 꾸몄다. 작년 대회 입상자가 나 포함 3명이 온다고 했는데 역시나 내가 예상했던 대로 대상, 금상, 은상 수상자가 나란히 왔다. 울산대 팀은 그렇잖아도 최고 등급인 대상을 받은 데다 부산은 지리적으로 거리도 별로 안 멀고, 이 대회만 작정을 하고 미는 연구실이 있으니 이런 자리엔 거의 확실히 오리라고 예상했다.

한편, 작년에 금상을 받은 최 시영 선생님은 1인 기업 사장이랄까 프리랜서랄까, 어쨌든 조직에 매여 있지 않은 분이기 때문에 이런 데에 가는 데 제도적인 제약이 없는 분이다. 최근엔 data-p라는 프로그래밍 언어도 하나 고안해서 대외적으로 뭔가 알려야 할 게 많은 처지이기도 하다(실제로 나중에 컴퓨터공학 교수들 앞에서 data-p 얘기 많이를 늘어놓으셨다). 그러니 올 거라 생각했는데 역시 오셔서 나하고 반갑게 인사를 나눴다. 말동무가 하나 늘었다.

저분은 프로필을 보아하니 서울대 법대 출신의 엄청난 엄친아인데 독특한 웹 기반 세종 말뭉치 검색 도구를 만들어서 이런 대회의 상위권에 입상하고, 최근에는 전산학에까지 관심을 뻗치고 계신다. 뭘 하시는 분인지가 궁금해지지 않을 수 없다.
그에 반해, 대학원이나 일반이 아닌 학부생들은 아무래도 이런 좁고 전문적인 분야의 대회에서 상위권에 입상하는 작품을 만들기가 현실적으로 어려울 것이며, 입상하더라도 또 중간고사를 앞두고 먼 길을 가서 이런 대회의 데모 세션에 참여할 처지는 못 될 것이다. 이런 나의 모든 예상은 적중했다.. ^^

공식적인 데모 세션은 2시간이었다. 나야 ISEF에 참가하던 고딩 시절 이래로 이런 건 한두 번 하는 게 아니긴 하지만, 여전히 다른 사람들에게 내 프로그램의 본질에 대해서 설명해 주기란 참 쉽지 않았다. 세벌식, 무한 낱자 수정, 오토마타, Bksp 없이 오타 고치기, 텍스트 필터, 에디터와 IME 등등등... 무슨 얘기부터 할까? 이런 것들이 어느 하나만 알아서는 context를 이해할 수 없는 유기체를 구성하고 있다. C밖에 모르는 사람에게 어느 세월에 C++의 클래스, 상속, 오버로딩, 가상 함수 개념에 대해서 설명해 주고 그것도 모자라서 템플릿이라든가 람다 함수에 이르기까지 그 필요성과 장점을 가르쳐 줄 수 있겠는가?

확실히 한국어 공학에 비해서 “한글 공학”은 인지도가 미미한 것 같다. 우리나라의 사회 문화 분위기가 한국어와 한글의 구분이 상당히 모호하고 오락가락 하는 건 사실이지만, 결국 어차피 그 말이 그 말이고 반드시 구분해야 할 필요가 없는 상황에서 병적으로 둘은 완전히 독립적이고 무관한 개념이라고 집작하고 몰고 가는 것도 또한 보기 좋지 않은 모습인 듯.
비록 내 프로그램은 올해의 대회 출품작이 아니기 때문에 심사 대상도 아니지만, 심사위원 중 한 분은 “님 프로그램은 우리 대회보다 규모가 더 큰 일반적인 소프트웨어 공모전에도 출품해 보셈”이라고도 말씀하셨다.

데모 세션이 끝날 무렵에 웬 반가운 손님이 한 명 왔다. 올해에 본인의 석사 졸업 대학원 학과에 석사로 새로 입학한 파릇파릇한 석사 후배. 학교에서 내 얘기를 이미 들었는지 나에 대해서 어느 정도 이미 알고 있었다. 나는 대학원 재학 시절에 석사 신입생이라고는 좀체 구경을 못 했다(한두 명 합격한 지원자는 있었으나, 등록을 안 하고 그걸로 끝). 그러다 겨우 논문 학기가 다 돼서야 여학생 후배 두 명을 본 게 전부인데, 남자 후배라니 반갑지 않을 수 없었다. 말동무가 셋으로 늘었다.

부스 전시는 정오 무렵까지 그럭저럭 잘 했다. 이제 느긋하게 앉아서 올해 입상작들의 발표와 심사 장면 구경만 하면 된다.
주최 측에서는 데모에 참여한 작년 입상자들을 예우 차원에서 경진대회 관객으로 자동 등록을 시켜 줬으며, 점심과 저녁 식사는 물론, 생각도 안 했던 여비까지 챙겨 줬다.

출품된 프로그램들은 로컬, 웹, 앱을 골고루 커버하는 다양한 형태였다. 로컬 프로그램 중엔 정통 MFC 기반 프로그램은 없었고, 모두 닷넷 프레임워크 기반이었던지라 세대 차이를 실감했다. 하긴, 업무용 프로그램이야 어떤 형태로든 RAD가 지원되는 툴로 만드는 게 능률과 생산성 면에서 나을 테니 말이다.
말뭉치가 어떻고 태깅이 어떻고 하는 구체적인 내용은 나도 그것만 전문적으로 판 게 아니니 잘 모르겠다. 발표 중간엔 다시 몰려오는 잠의 쓰나미를 주체할 수 없어서 잠시 졸았다.

올해는 KAIST 전산학과에서 NLP 연구의 선두주자이신 최 기선 교수님 연구실에서 작품을 출품하여 대상을 받았다. 그러고 보니 나는 나름 한글 입력기를 연구한다면서 학부 시절에 '한국어'와 관계가 있는 연구를 하는 교수님은 한 번도 안 마주치고 졸업을 해 버렸으니 이것도 기이한 일이다. 저분을 포함해 박 종철 교수, 시 정곤 교수(이분은 전산학과가 아닌 인문사회과학부 소속) 같은 분들 말이다. 박 교수님은 이번 대회 행사에서 개회사를 하셨는데, 국어의 위상을 화폐 단위의 위상에다 빗대어 말씀하시는 걸 들어 보니 생각보다 국어 사랑 정신이 투철한 전산학자이시라는 게 느껴졌다.

서울을 벗어난 장소에서 올해는 작년 입상작 개발자까지 초청하여 데모 세션을 연 것은 바람직한 시도라고 느껴져서 기분이 좋다. 사실, 옛날에 정보 올림피아드도 그런 식으로 공모 부문 입상자끼리의 교류와 전시 행사가 좀 있으면 좋겠다고 난 예전부터 생각해 왔었다. 참가 작품수가 늘어나고 대회의 권위와 위상이 더 올라가면, 심사와 시상 기준을 다음과 같이 더욱 세분화도 해야 할 텐데 이런 욕심까지 부리는 건 아직은 좀 이른지도 모르겠다.

- 분야: 말뭉치 도구, 교육용 소프트웨어, 또는 기타 유틸
- 부문: 대학 학부, 대학원, 개인 인디 개발자, 또는 기업
- 내력: 첫 개발인가, 아니면 동일 아이디어 하에서 예전 출품/입상작의 꾸준한 개선 내지 리메이크인가

그런데 이 대회를 앞으로 적극 육성하겠다면서 올해는 뽑는 입상작 수가 더 줄었다. 작년에 9명이던 것이 올해는 7명. 게다가 이미 작년도 재작년에 비해서는 지급되는 상금의 총액이 좀 줄어든 것이었다. 이것부터 좀 개선해야 할 문제가 아닌가 싶다. ^^;;

작년과 마찬가지로 올해도 주최 측에서 참석자 전원에게 저녁까지 쏘는 대인배 대접을 했다. 나도 늦게까지 얘기를 나누면서 교제할 사람이 주변에 여럿 있었지만 나는 선약을 잡은 상태였던지라 눈물을 머금고 먼저 자리를 떴다. 완전히 풀코스를 뛰었으면 영도를 완전히 빠져나가는 시각은 밤 8~9시 사이가 됐을 것이고, 남의 차를 얻어 타고 부전이나 부산 역까지 도착하는 시각은 그보다 더 늦어졌을 터이니, 진짜 부산에서 진한 하루를 보내게 됐을 것이다.

자가용을 가져갔으면 시간과 장소 제약이 없이 인근의 태종대 같은 부산 구경을 더욱 자유롭게 하고 돌아갈 수 있었을지 모르나 이 경우 주차나 유류비 같은 다른 문제 때문에 골치가 아프게 됐을 수도 있다. 게다가 난 그렇잖아도 대중교통만 이용하고도 피곤해서 이 고생을 했는데, 운전까지 해야 했으면 어찌 됐겠는가?

어쨌든 부산에서 기억에 남는 즐겁고 유익한 추억을 남겼다.  이 글에서 다 못 한 주변 이야기는 다음에 올라올 부록에서 이어질 예정이다.

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