* 세벌식이어야 한다.
* 시프트 키를 사용하지 않고 한글 입력이 가능해야 한다.
* 두벌식 자판 사용자가 빠르게 학습 가능해야 한다.

3-18Na 자판은 기존 두벌식 자판 배열을 전혀 수정하지 않고 세벌식 자판을 구현한 자판입니다.

3-18Na 자판

그냥 서론

아무튼 입력기 소스 코드를 보다가 정말 오래간만에 다시 세벌식 자판에 대해 관심이 생겼습니다. 모든 한글 입력기에 다 세벌식 코드가 있으니까 새삼 다시 인지하게 된 것이지요. 그래서 세벌식 자판에 대해 찾아 보았습니다. 춘추전국시대를 떠올릴 만큼 다양한 자판이 개발되어 있더군요. 각 자판을 만든 사람들마다 공통적으로 현재 국가 표준 자판인 두벌식 자판을 비판하면서 세벌식 자판의 장점을 설명하고 거기에 덧붙여 본인이 만든 자판의 장점을 내세우고 있었습니다. 그럼에도 가장 보편적으로 많이 사용하는 세벌식 자판은 공병우 박사님이 만든 3-90 자판과 3-91 자판입니다. 3-91 자판은 세벌식 최종으로 불리기도 합니다. 실제로는 전혀 최종 자판이 아님에도 그렇게 불리고 있습니다.

3-90과 3-91 중에서 프로그래머들이 쓰기 좋은 자판은 3-90 자판이라고 하여, 한 일 주일 정도 3-90 자판을 열심히 연습했었습니다. 그러나 역시 거의 20년간 익숙하게 써오던 자판을 바꾸는 작업은 보통 작업이 아니었습니다. 매우 고통스러웠어요.

사람은 고통스러우면 생각이 많아지지요. 세벌식 3-90 자판이 세벌식 중에서도 많이 쓰이는 것이라 한들, 마이너 한 것은 마찬가지이고 내가 다른 사람의 3-90 자판으로 설정되어 있는 컴퓨터를 쓸일이 있을까? 아무리 생각해 봐도 없을 것 같습니다. 심지어 저는 다른 사람의 컴퓨터를 쓸 일도 별로 없습니다. 반대로 내 컴퓨터를 다른 사람이 쓸 일이 있을까? 마찬가지로 없습니다. 그리고 어차피 군웅이 할거하는 세벌식 자판 배열 전쟁터에 내가 하나 정도 더 추가한들, 그것도 그냥 내 맘대로 나 편한대로 만든들, 딱히 큰 사회적 물의를 일으킬 것 같진 않더군요.

많은 일들이 늘 이렇게 별것 아닌 이유로 시작하지요...

스터디

일단 세벌식 자판을 좋아하는 분들이 두벌식 자판의 단점으로 꼽는 것들 중 가장 자주 보이는 것이 도깨비불 현상이라는 것입니다. 구글에서 찾아보면 좋은 설명을 많이 찾을 수 있으므로 이 글에서 굳이 자세하게 설명하진 않겠습니다. 쉽게 말해 컴퓨터 화면에서 두벌식 자판으로 타이핑을 하면 타자가 의도하지 않은 중간 글자가 나타났다가 사라진다는 것입니다. 예를 들어 지금 이 문장도 두벌식으로 치면 "지금"이라는 글자를 완성하는 과정에서 "지 -> 직 -> 지ㄱ -> 지금" 이렇게 "직"이라는 타자가 의도하지 않은 글자가 화면에 나타났다가 사라진다는 것이지요. 이는 두벌식 자판이 초중종성으로 키를 구분하는 것이 아니라 자음, 모음으로 키를 구분하기 때문에 중성으로 쓰이는 모음 이후에 나오는 자음이 종성인지 다음 글자의 초성인지를 구분할 수 없어서 생기는 현상입니다. 저는 이 도깨비불 관련 내용을 읽으면서 이게 그렇게 불편한 문제인가? 하는 생각이 들었습니다. 그냥 컴퓨터 자판에서 생기는 고유의 현상으로 이해하고 넘어가도 되는 문제 아닌가? 하는 생각 말이지요.

다음으로 많이 보이는 두벌식 자판의 문제점은 바로 지나치게 많이 시프트 키를 사용해야 한다는 것이었습니다. 이 부분에 대해서는 저도 격하게 동감이 되었습니다. 초성, 종성의 쌍자음과 중성 ㅒ, ㅖ를 시프트 키로 입력해야 하죠. 이게 타자 속도 문제도 있는데 어차피 고속으로 타이핑 못하는 제게 타자 속도 문제는 그다지 크지 않았습니다. 그보다 큰 문제는 손의 피로 였습니다. 양쪽 시프트 키는 새끼 손가락으로 눌러야 하는데 이게 새끼 손가락만으로 되는 것이 아니라, 제가 손이 작아서 시프트 키를 누르려면 손목을 바깥쪽으로 꺽어야 한다는 것이 문제 였습니다. 이 것 때문에 장시간 많은 양의 타이핑을 할 때는 손목이 많이 피로함을 느꼈습니다.

그리고 두벌식 자판은 왼손을 지나치게 혹사 시킨다는 것이었습니다. 저는 솔직히 잘 모르겠더라구요. 타이핑 많이 하면 왼손, 오른손이 다 피곤하지 딱히 왼손이 더 피곤하다는 느낌은 없었거든요. 아무튼 그러하고 하니 그런가보다 하고 넘어 갔습니다.

한가지 더, 재미있는 사실이 있습니다. 저는 그 전부터 알고 있었는데요, 우리가 두벌식에서 자음은 왼손, 모음은 오른손으로 칩니다. 그런데 모음 ㅠ는 오른손으로 치지만 영문 자판에서 모음 ㅠ에 해당하는 B 키는 왼손으로 친다는 사실. 이게 우리는 훈련으로 그렇게 쓰고 있는 겁니다. 대단하죠.

세벌식은 도깨비불 현상도 없고 시프트 키도 두벌식에 비하면 적게 누른다고 합니다. 맞는 말입니다. 초중종성을 모두 자판에 배열했기 때문에 자음이 받침으로 갔다가 초성으로 휙 이동하는 현상은 생기지 않습니다. 다만 그래서 두벌식에 비해 많은 자판이 필요하고 때문에 키보드의 숫자키에 까지 한글 자모가 배정되어 있습니다. 저는 이게 너무 싫더라구요. 특히나 프로그래밍과 관련된 글을 쓸 때 숫자키와 숫자키에 배정된 특수문자를 쓸 일이 많기 때문에 숫자키와 숫자키의 특수문자는 제게 필요했습니다.

3-90, 3-91 자판을 비롯해 제가 인터넷에서 찾을 수 있는 세벌식 자판들은 기본적으로 3-90과 3-91 자판과 호환을 염두에 두고 만들어져 있었습니다. 그래서 공통적으로 초성이 오른손, 중성이 왼손, 그리고 종성도 왼손으로 타이핑하게 구성되어 있습니다. (안마태 자판 제외) 이게 왜 이렇게 되어 있냐면 오래전 기계식 타자기 시절까지 거슬러 올라가는 유서깊은 이유가 있긴한데, 그런 이유로 납득이 되진 않더라구요. 적응의 영역이었던 거죠. 그런데 저는 적응이 안되더라구요.

또한 세벌식 자판은 익숙해지고 나면 리듬감 있는 타이핑이 가능하다고 합니다. 초, 중, 종성이 자판의 오른쪽에서 왼쪽으로 순서대로 배치되어 있으므로 오른손에서 왼손으로 자연스럽게 손가락의 움직임이 이동한다는 것이지요. 그럴싸 했습니다. 그런데 그 경지까지 가려면 최소 일년은 빡세게 연습해야 할 것 같다는 생각이 들었습니다.

초중종성이 따로 배치되어 있기 때문에 키 세개를 한꺼번에 눌러서 한글 한 글자를 입력하는 모아치기가 가능한것도 세벌식 자판의 장점입니다. 네, 이것은 분명한 장점입니다. 그런데 마찬가지로 모아치기의 경지에 이르러면 얼마나 많은 수련이 필요할까요...

두벌식과 세벌식 포함해서 어떤 사람들은 자판 배열은 반드시 기계식 타자기로 개발이 가능해야 한다고 주장합니다. 그러나 저는 동의할 수 없었습니다. 이 원칙이 미국에서 국가 표준 자판을 정할 때의 원칙이었다는데, 뭐 저는 국가 표준 자판을 만들려고 하는 것이 아니니까요.

그래도 그냥 두벌식 개선해서 쓸까 하다가..

그러나 현실은 그러하지 못하지요. 사람들은 거의 다 두벌식 자판으로 키보드를 연습했고 지금도 대부분의 사람들은 두벌식 키보드를 사용하고 있습니다. 아직 세벌식은 국가 표준이 아니고 때문에 생산되는 키보드에는 두벌식이 인쇄되어 있고 사람들은 인쇄된 두벌식 키보드 자판의 한글을 보며 독수리 타법부터 컴퓨터 사용을 시작하니까요.

사실 두벌식 자판도 오토마타를 살짝 수정하면 시프트 사용을 많이 줄일 수 있습니다. 시프트를 이용해서 입력해야 하는 쌍자음이나 ㅒ, ㅖ를 그냥 연타로 처리해서 입력하게끔 입력기의 오토마타를 수정할 수 있거든요. 이정도만 해도 매우 훌륭합니다. 시프트 키의 사용이 아마 거의 반이상 줄어들 것이라고 생각됩니다. (과학적으로 실험해 보진 않았습니다.) 제가 이상한 바람이 불어서 세벌식에 꽃히지만 않았어도 그냥 이정도 수준에서 계속 두벌식 썻을지도 모릅니다. 그럼에도 "이니까요" 나 "어쩔 수 없는" 같이 초성이 쌍자음으로 시작하는 글자의 앞 글자가 받침이 없는 글자라면 "이닌가요", "엊절 수 없는"으로 글자가 완성되고 맙니다.. 안타까운 일이죠..

목표

* 세벌식이어야 한다.
* 시프트 키를 사용하지 않고 한글 입력이 가능해야 한다.
* 두벌식 자판 사용자가 빠르게 학습 가능해야 한다.

결론적으로 저는 이 세 가지 목표를 모두 달성했습니다. 지금 이 글도 제가 만든 자판으로 두드리고 있습니다. 저는 이 자판을 학습하는데 딱 5분간 연습했습니다. 그리고 장문의 글을 쓸 수 있는 수준으로 사용할 수 있게 되었습니다. 물론 아직 두벌식과 헷갈려서 오타가 자주 나는 편이지만 3-90 자판을 연습할 때에 비하면 학습 속도는 비교할 수 없을 정도로 빨랐습니다.

소개

3-18Na 자판은 기존 두벌식 자판 배열을 전혀 수정하지 않고 세벌식 자판을 구현한 자판입니다. 이 자판은 기계식 타자기로 구현이 아마 불가능 할 겁니다. 인간의 능력은 무한하므로 아마 구현 하는 사람이 있을지도 모르겠으나 지금은 아마 구현이 안될 거라 생각됩니다. 3-18Na 자판은 도깨비불 현상을 용인합니다. 하지만 두벌식 수준으로 종성이 나타났다가 다음 글자의 초성으로 획 이동하는 그런 수준의 도깨비불 현상은 아닙니다. 종성이 보이되 그 모양이 종성을 유지한채 바뀌는 수준의 도깨비불 현상입니다. 이 문서를 통해 이후에 자세히 설명하겠습니다.

3-18Na 자판은 기존 두벌식 자판 배열을 전혀 고치지 않으면서 시프트 키의 사용을 없애기 위해서 연타를 적극 이용합니다. 대부분의 자판 연구가들은 연타가 손가락의 피로를 가중하고 타수를 떨어뜨린다고 말합니다. 그러나 그렇다고만 말하고 어디에서도 근거를 찾을 수 없었습니다. 연타가 타수를 떨어뜨린다는 말은 경험적으로 보아 그럴 것 같긴 합니다만, 손가락의 피로를 가중시킨다는 말은 받아들여지지 않았습니다. 그래서 근거를 찾았으나 없었습니다. 모두들 그렇다 하니 다들 그런가보다 하는듯한 느낌이었습니다. 근거의 여부를 떠나서 저는 연타보다 시프트 키가 더 큰 악영향을 준다고 판단했습니다. 그래서 연타를 통해 시프트 키의 사용을 없앴습니다. 이미 기존의 두벌식 자판 오토마타에서 적용된 기법이라 더이상의 설명은 안해도 될것 같습니다. 아무튼 초성과 중성의 시프트 키 사용은 연타로 해결했습니다.

남은 것은 종성을 어떻게 할 것이냐 입니다. 저는 신세벌식이라는 자판에서 도입한 갈마들이라는 기법을 사용하기로 했습니다. 원리는 이러합니다. 자음은 초성과 종성에 쓰이지만 모음은 중성에만 쓰이므로 모음이 중성으로 한 번 입력된 후에는 해당 키가 다시 눌린다 하여도 글자 조합에는 관여할 수 없습니다. 예를 들어 "ㄱ + ㄱ + ㅗ" 이렇게 두드린다면 연타로 쌍자음을 만든다고 했을 때 "꼬"가 완성됩니다. 초성은 두 번 눌려도 글자를 계속 만들 여지가 있다는 말입니다. 그러나 "ㄱ + ㅜ + ㅏ" 이렇게 입력을 하면 "구ㅏ"로 입력될 뿐입니다. 이중 모음으로 정해진 자모를 제외하면 모음 키를 연타해서 종성을 입력하는 것이 가능하다는 말입니다.

3-18Na 자판 배열

그렇게 완성된 3-18Na 자판의 배열은 위 그림과 같습니다. 이제부터 왜 이런 자판 배열을 만들었는지 설명하겠습니다. 이것이 이 글의 목적인데 서론이 정말 길었네요.

앞서 말한대로 중성과 종성은 한 키에 배치해도 서로 꼬이지 않습니다. 이중 모음만 피하면 말이죠. 음운학적으로 이중 모음은 ㅑ,ㅕ,ㅛ,ㅠ,ㅒ,ㅖ,ㅘ,ㅙ,ㅝ,ㅞ,ㅢ 이지만 저는 키보드에서 모음을 두번 타이핑해서 만드는 모음만을 고려 대상으로 하겠습니다. 그러면 ㅒ,ㅖ,ㅘ,ㅙ,ㅝ,ㅞ,ㅢ가 대상이 됩니다. ㅒ,ㅖ는 연타로 입력을 하고 나머지는 두 키를 눌러서 입력기가 조합하여 만들어 내는 자모입니다. 이들의 공통점을 도출하면 ㅏ, ㅓ, ㅣ 그리고 ㅐ와 ㅔ로 조합이 완료된다는 것입니다. 이점이 왜 중요하냐면, 이들 다섯개 키에는 종성을 배치할 수 없기 때문입니다. 예를 들어 ㅣ키에 ㄹ 받침을 배치했다면 "의"를 두드릴 때와 "을"을 두드릴 때의 차이를 오토마타가 구분할 수 없기 때문입니다. 물론 "으->의->을"의 변화를 거치도록 오토마타를 만들 수 있겠지만, 같은 이유로 "을"과 "읠"을 구분할 수 없게 됩니다. 그래서 복잡도를 줄이기 위해 이중 모음을 완성하는 키에는 종성을 배치하지 않기로 결정을 했습니다.

그러면, 종성 배치가 가능한 키는 ㅛ, ㅕ, ㅑ, ㅗ, ㅠ, ㅜ, ㅡ 이렇게 7개입니다. 겹받침을 조합으로 입력한다 해도 필요한 종성은 ㄴ, ㄹ, ㅇ, ㄱ, ㅅ, ㅁ, ㅂ, ㅎ, ㅌ, ㄷ, ㅍ, ㅈ, ㅊ (사용 빈도순) 이렇게 14개입니다. 이중 ㄱ 과 ㅅ 은 쌍자음이 받침으로 사용됩니다. "갂" 과 "갔" 같은 글자 말이죠. 그래서 (ㄱ, ㄲ), (ㅅ, ㅆ)을 하나로 묶어서 배치하는 것이 타당해 보입니다. 그러면 남은 키는 5개, 남은 종성은 12개입니다. 앞서서 (ㄱ, ㄲ) 과 같이 한 키에 종성을 두 개 배치했으므로 다른 키에도 종성을 두 개 씩 배치해 보겠습니다. 그러면 남은 5개 키에는 종성을 최대 10개 까지만 넣을 수 있습니다. 2개가 남습니다. 선택을 해야 했습니다. 키 두 개를 선정해서 종성을 세 개 배치할 것인가 아니면 특수 문자 키를 사용할 것인가에 대한 선택이죠. 저는 두 번째 안을 선택했습니다. 우리가 키보드에 열 손가락을 얹어 놓은 모습을 보면 오른손 새끼 손가락에만 글자가 아닌 특수 문자인 세미콜론(;)이 있습니다. 그리고 세미콜론은 한글 문서 작성에서 거의 사용하지 않는 문자이기도 합니다. 때문에 다른 세벌식 자판에서도 이 세미콜론 키는 모두 다 글자를 할당해서 쓰고 있었습니다. 그러면 6개 키에 12개의 종성을 넣을 수 있습니다. 이제 키는 확보되었으니 어디에 배치할 지를 결정하는 일만 남았습니다.

세미콜론 키를 제외한 ㅛ, ㅕ, ㅑ, ㅗ, ㅠ, ㅜ, ㅡ 모음 키는 오른손 검지와 중지로 누르는 키입니다. 열손가락 중에서 가장 힘이 쎈 키라고 할 수 있지요. 다른 세벌식 자판도 되도록이면 빈도가 많은 글자를 검지와 중지에 배정하는 경향을 보였습니다. 이는 당연한 생각이라 여겨집니다. 3-18Na 자판에서는 모든 종성이 오른손 검지와 중지로 눌리므로 종성 중에서도 빈도가 높은 글자를 되도록 검지에 배치하고 가장 빈도가 낮은 종성은 무조건 세미콜론 자리로 배치했습니다. 그래서 ㅈ 과 ㅊ은 자연스레 세미콜론 자리로 갔습니다.

가장 빈도가 높은 ㄴ 종성부터 배치하도록 하죠. 당연히 손가락의 이동거리를 최소화 하는 위치에서 검지로 누르는 키에 배치했습니다. 바로 ㅗ 키이죠. 대기 시간에 오른손 검지는 영문자 J 키에서 대기하므로 빈도가 높은 ㄴ 받침은 J 바로 옆에서 누를 수 있게 했습니다.

그다음 빈도가 높은 ㄹ 받침은 기본 위치 기준 이동거리가 같은 ㅕ와 ㅜ 중에 골라야 했습니다. 여러번 눌러보니 손가락을 펴서 누르는 ㅕ보다 손가락을 굽혀서 누르는 ㅜ가 더 편했기에 ㅜ에 받침 ㄹ을 배치했습니다. 딱히 과학적인 이유는 아닙니다. 어차피 저 혼자 쓰려고 만든건데요 뭐.

지금까지 기준이라면 이제 ㅕ 위치에는 다음으로 사용 빈도가 높은 ㅇ 받침이 와야 겠지만 (ㅅ, ㅆ)을 배치했습니다. 왜냐하면 ㅅ 종성을 연타해서 완성하는 ㅆ 받침이 우리말에서 정말 많이 쓰이기 때문이지요. 당장 이 글만 해도 "있습니다.", "했습니다"가 정말 많이 나오지요.

이제 남은 키는 ㅛ, ㅑ, ㅠ, ㅡ 입니다. 배치할 받침은 ㅇ 입니다. ㅛ, ㅠ 는 검지로 누르는 키입니다. ㅑ, ㅡ 는 중지로 누르는 키입니다. 검지로 누르긴 하지만 ㅛ는 이동 거리가 깁니다. ㅠ는 심지어 원래 오른손으로 누르는 키가 아닙니다. 차라리 이동 거리가 짧은 ㅑ, ㅡ가 더 나은 선택으로 보입니다. 중지는 손가락이 길어서 인지 펴서 누르는 ㅑ가 ㅡ보다 좀 더 편하더라구요. 그래서 ㅑ에 받침 ㅇ을 배치했습니다. 순전히 내 개인적인 경험적 결정입니다. 참 과학적 근거 없는 자판 배열이라는 생각이 듭니다. 뭐 때로는 직관이 더 훌륭한 답일 때도 있으니까요.

이제 (ㄱ, ㄲ)을 ㅡ에 배치할지, ㅛ에 배치할지 결정해야 합니다. 여러번 실험해 봤더니 재미있는 현상이 발견되었습니다. 오른손으로 두드리는 종성의 위치가 무의식적으로 왼손으로 입력하는 자음 배치를 따라 간다는 것이었습니다. 받침 ㄱ 혹은 ㄲ을 두드려야 겠다고 마음 먹은 순간 오른손 검지가 자판의 위쪽 배열로 이동하더라는 겁니다. 왜냐하면 왼손 자음 배치에서 ㄱ이 ㅅ옆에 윗 쪽 배열에 있기 때문입니다. 놀라운 발견이었습니다. 그래서 ㅛ 키에 (ㄱ, ㄲ)을 배치했습니다.

남은 받침은 ㅁ과 ㅂ입니다. 빈도가 더 높은 ㅁ을 ㅡ 키에 배치했습니다. 왜냐면 ㅠ키가 비록 검지로 누르는 키이긴 하지만 원래 왼손으로 누르는 키이기 때문에 ㅡ가 실제로는 누르기 더 편할거라고 생각했기 때문입니다. 그리고 남은 ㅠ에 ㅂ을 배치했습니다.

이제 남은 종성 자모는 사용 빈도가 비교적 낮은 ㅎ, ㅌ, ㄷ, ㅍ, ㅋ 입니다. ㅊ은 이미 ㅈ과 함께 세미콜론에 배치했습니다. 남은 종성 자모를 배치함에 있어 겹받침의 조합을 고려해야 합니다. 현대 한글 겹받침은 ㄲ, ㅆ, ㄳ, ㄵ, ㄶ, ㄺ, ㄻ, ㄼ, ㄾ, ㄿ, ㅀ, ㅄ, ㄽ 이렇게 13가지 입니다. ㄲ 과 ㅆ은 이미 배치했습니다. 그러므로 남은 11개 겹받침의 조합을 고려해서 배치해야 합니다. 이중 ㄳ, ㄵ, ㅄ 은 이미 배치한 종성으로 조합되는 겹받침이므로 역시 고려 대상이 아닙니다. 그러면 ㄶ, ㄺ, ㄻ, ㄼ, ㄾ, ㄿ, ㅀ, ㄽ 이렇게 8개가 남네요.

ㄶ을 먼저 보겠습니다. ㄴ은 이미 배치되어 있습니다. 그러면 ㅎ의 자리를 정해야 합니다. 받침 ㅎ은 단독 받침외에도 ㄶ과 ㅀ의 조합을 완성하는 글자이기도 합니다. 따라서 ㄴ과 ㄹ 받침과 겹받침을 만들 때 서로 간섭하지 않는 글자와 같은 키를 사용해야 합니다. 저는 ㅇ을 선택했습니다. 한글 제자 원리로 보더라도 ㅇ과 ㅎ은 가까운 글자입니다. 그리고 도깨비불 현상을 봐도 "행" -> "햏" 으로 변하는 과정이 시각적으로도 손으로 글씨를 쓰는 듯한 자연스러운 변화 이므로 (물론 손글씨를 쓸 때는 ㅎ의 머리를 먼저쓰긴 하지만 아무튼 ㅇ과 ㅎ은 모양이 비슷하니까요) 시각적으로도 거부감이 덜 합니다. 오토마타 측면에서 보더라도 ㄹ+ㅇ, ㄴ+ㅇ의 겹받침은 없으므로 ㅎ이 단독 받침으로 쓰일 때도 키 두 번 눌러서 입력이고 겹받침으로 쓰일 때도 오토마타가 조합이 없는 ㅇ은 건너 뛰고 바로 ㅎ을 인식해서 키 두 번 눌르는 것으로 입력이 됩니다.

이제 남은 겹받침은 ㄺ, ㄻ, ㄼ, ㄾ, ㄿ, ㄽ로 모두 ㄹ과 조합하는 겹받침입니다. 그리고 아직 배치를 완료 못한 종성 자모는 ㅌ, ㄷ, ㅍ, ㅋ 입니다. 이중 ㄹ과 겹받침을 만들지 않는 글자는 ㄷ, ㅋ 입니다. 이 둘 중 하나가 ㄹ과 한 키에 배치되어야 합니다. 왜냐하면 ㄹ과 조합하여 겹받침을 만드는 글자가 ㄹ과 같이 있으면 타자가 의도한 글자가 나오지 않기 때문입니다. 예를 들어 (ㄹ, ㅍ)이 한 키에 배치되어 있다면, "릎'을 입력하고 싶은데 "르->를->릂"이 되어 버리기 때문입니다. 물론 오토마타에서 처리하여 한 번 더 같은 키를 누르면 "르->를->릂->릎"이 되게 할 수는 있으나 오토마타를 복잡하게 하면서까지 ㄹ과 조합하여 겹받침을 만드는 글자를 ㄹ과 같은 키에 배치해서 얻을 수 있는 이득이 별로 없습니다. 그래서 ㄹ과 겹받침을 만들지 않는 ㄷ이나 ㅋ을 ㄹ과 같은 키에 배치하면 오토마타도 단순화하고 글자를 완성하는데 누르는 키의 횟수를 줄일 수 있습니다. 결론적으로 (ㄹ, ㅋ)을 배치했는데 (ㄹ, ㅋ)이 된 이유는 얘네들 보다 (ㅁ, ㄷ)의 이유가 더 큽니다.

(ㅁ, ㄷ)으로 결정된 가장 큰 이유는 시각적 효과 때문입니다. 처음에는 크게 의도하지 않았는데, 자판 개발 과정에서 도깨비불 현상을 되도록 긍정적으로 최대한 적극적으로 이용할 수도 있을 거란 생각이 들었습니다. 이왕 생기는 현상인데 시각적 효과를 이용해보잔 발상이었죠. 예를 들어 (ㅇ, ㅎ) 같은 경우죠. (ㄱ, ㄲ)이나 (ㅅ, ㅆ) 도 마찬가지로 도깨비불 현상 덕에 오히려 더 손으로 글자를 쓰는 듯한 느낌이 들었습니다. 우리가 ㅆ을 손으로 쓸 때 ㅆ을 한 번에 못 쓰잖아요. ㅅ 한 개 쓰고 그 옆에 ㅅ을 써서 ㅆ을 만들 듯 키보드를 두드리면서도 "잇->있"으로 받침 ㅆ이 만들어지는 과정이 시각적으로 표현되는게 괜찮아 보였습니다. (ㅁ, ㄷ)을 엮었을 때 제가 원하는 모습은 "칟 -> 침" 으로 획이 증가하는 방향으로의 변화였지만 ㅁ과 ㄷ은 빈도수의 차이가 너무 크기에 순서를 바꿔서 얻는 것보다 손해가 더 크다고 판단되어 비록 획이 감소하는 방향의 변화이긴 하지만 되도록이면 시각적 효과를 고려해 (ㅁ, ㄷ)을 엮기로 결정했습니다.

마찬가지로 "ㄹ->ㄷ" 보다는 "ㄹ->ㅋ"이 시각적으로 더 자연스러워 보이기도 하고요.

이제 남은 종성 자모는 ㅌ과 ㅍ입니다. 두 글자 모두 ㄹ과 조합되어 겹받침을 만드네요. 그러면 두 글자 중 빈도수와 시각적 효과를 고려해서 ㅌ이 ㄴ과 같은 키를 쓰게 되었고 ㅍ이 ㅂ과 같은 키를 쓰게 되었습니다.

문제는 ㅍ입니다. 같은 키를 쓰는 ㅂ도 ㄹ과 겹받침을 만들고 ㅍ도 ㄹ과 겹받침을 만듭니다. 원칙대로라면 ㅊ과 자리를 바꾸어 (ㅂ, ㅊ), (ㅈ, ㅍ)으로 구성해야 하지만, ㅈ과 ㅊ이 너무도 강력한 관계라는 것이 문제였습니다. 한글 제자 원리 상으로 보나 시각적 효과로 보나 (ㅈ, ㅊ)은 도저히 떠어 놓을 수 없었습니다. 저는 할 수 없었습니다....

다행히 우리말에서 ㄿ은 "읊다" 할 때 (읊조리다 등) 밖에 쓰지 않습니다. 정말 단 한글자 읊을 표기하기 위해 존재하는 겹받침입니다. 거의 쓸일이 없기에 부득이 하게 "을->읇->읊"으로 변화하는 오토마타로 처리하도록 할 수 밖에 없었습니다. 지금도 아쉬움이 남는 결정입니다. (ㅈ, ㅊ)은 참으로 깨뜨리기 싫은 완결성에서 오는 그 어떤 심리적 저항감 같은 것이 있습니다.

그리고 마지막으로 (ㅈ, ㅊ)에 의해서 자리를 빼았긴 세미콜론은 시프트+L로 갔습니다. 그러다보니 시프트+J와 시프트+K도 뭔가를 채우고 싶어서 손가락이 많이 이동해야 해서 두드리기 어려운 ㅄ과 ㄺ을 각각 넣었습니다. ㅄ과 ㄺ은 시프트를 누르지 않고도 입력할 수 있기 때문에 타자의 취향에 따라 사용하면 됩니다.

이렇게 해서 3-18Na 자판의 구성 이유를 모두 설명했습니다. 저는 이 글을 3-18Na 자판으로 쓰고 있습니다. 꽤 긴 글임에도 확실히 두벌식보단 좀 나은것 같다는 생각은 듭니다. 두벌식과 초중성이 완전히 같은 자판 배열을 사용하기 때문에 학습이 매우 빠르다는 장점이 있지만 반대로 계속 두벌식과 헤깔린다는 단점도 있네요. 그런데 두벌식과 헤깔리는 것은 다른 세벌식 자판을 연습할 때도 두벌식 사용자가 경험하는 현상이기 때문에 향후에 제가 3-18Na 자판에 익숙해진 다음에도 계속 두벌식 자판과 헤깔리는 현상이 나타나는지 확인해 봐야 할 문제입니다. 아직은 저도 초창기라 모르겠습니다.

이 자판은 자판 전문 연구가들이 보기에 지적하고 싶은 부분이 매우 많은 자판일 거라 생각됩니다. 그러나 제가 다른 세벌식 자판을 연습하면서 제가 느낀 불편함과 납득할 수 없던 설계 요소를 나만의 방식으로 해결했습니다. 저는 매우 잘 사용하고 있지요. 그러한 연유로 나는 딱히 3-18Na 자판이 널리 사용되길 바라는 마음이 있지도 않습니다. 다만, 저의 시간과 노력을 투입해 만들었고 과정 중에 많은 오픈 소스 소프트웨어를 수정했으므로 이왕 이렇게 된 김에 공개하는 것이 나와 비슷한 사람에게 도움을 줄 수 있을 꺼라 생각하여 공개를 결정했습니다. 그래서 3-18Na 자판을 쓰건 말건 그것은 이 글을 읽는 사람의 마음입니다. 그리고 지적이나 비판, 비난은 정중히 삼가합니다. 이미 확정된 자판 배열로 연습을 거의 다 했는데, 또 어떤 지적으로 자판 배열을 바꾸어야만 하는 고민을 하거나 유혹을 받고 싶지 않습니다.

입력기 삽질기

uim-벼루

저는 스킴 언어를 모르기 때문에 가장 큰 난관은 스킴 언어의 문법을 빠르게 학습하고 uim-벼루의 소스 코드 중에 고쳐야 할 부분을 찾아서 어떻게 고쳐야 할 지 파악하는 것이었습니다.

지금 저는 uim-벼루를 입력기로 설정해서 3-18Na 자판으로 이 글을 쓰고 있습니다. 실 사용에 문제가 없다는 말이지요. 그럼에도 저는 아직도 uim-벼루의 소스 코드를 전부 이해하지 못하고 있습니다. 그저 소스 코드의 패턴을 파악해서 자료 구조를 이런 식으로 바꾸면 되지 않을까 하는 추정을 기반으로 코드를 고치고 테스트하는 과정을 반복해서 uim-벼루에 3-18Na 자판을 적용했습니다.

제가 스킴 언어를 끝내 터득하지 못하여 오토마타를 건들이질 못하고 자료 구조 수정만으로 어느 정도 작업을 완료 했습니다. 그래서 "을->읇->읊"으로 변화하는 오토마타를 uim-벼루에서 구현하지 못했습니다. 하는 수 없이 시프트 키를 사용해서 ㄿ을 입력하도록 했습니다. 누군가 능력자가 계시면 도와주세요. 스킴은 너무 어렵더군요. 더불어 자료 구조 수정만으로 꽤나 상이한 동작 원리의 자판들이 모두 동작하게 만든 uim-벼루의 개발자님, 존경합니다.

제가 사용하는 리눅스 민트 18.2 버전에서 사용하는 uim은 왠지 github에 공개되어 있는 최신버전 소스 코드보다 오래된 버전으로 보입니다. 그래서 github에 있는 uim 코드를 포크해서 수정하려니 기계적 머지로는 뭔가 딱 들어 맞는 느낌은 아니었습니다. 그래도 일단 https://github.com/navilera/uim 에 제가 변경한 코드를 올려 놓긴 했습니다. 여기에 있는 코드는 최신 코드를 수정한 것이어서 배포판에는 직접 사용했을 때 무슨일이 생길지 알 수 없습니다. 우분투나 민트를 사용하신다면 https://github.com/navilera/318Na_HangulKeyboard/tree/master/Bin/uim-byeoru 에 있는 파일을 사용해 주시기 바랍니다. 다른 배포판을 사용하시는 분은 해당 파일과 배포판에서 사용하는 uim의 버전을 보고 적절히 수정을 해서 사용해야 할지도 모릅니다.

일단 우분투나 리눅스 민트는 byeoru.scm과 byeoru-custom.scm 파일을 /usr/share/uim 으로 복사합니다. 그리고 시스템을 재부팅하면 3-18Na 자판을 uim-byeoru의 설정 윈도우에서 설정해서 사용할 수 있습니다.

libhangul

한글 레이아웃 추가

libhangul은 구조상 아스키 키코드 값 한 개에 한글 자모 한 개를 연결합니다. 그래서 3-18Na 자판의 핵심 컨셉인 연타로 자모를 변경하는 기능을 쉽게 추가할 수가 없습니다. 부득이하게 자료구조를 하나 새로 추가해야 합니다.

오른손 키보드는 각 키마다 최대 3개의 자모(중성, 종성1, 종성2)를 가질 수 있으므로

typedef struct _KeyMultiKeyTable {
	ucschar firstKey;
	ucschar secondKey;
	ucschar thirdKey;
} KeyMultiKeyTable;

간단한 자료구조를 선언해서 기존의 자판 정보를 등록하는 자료구조에 끼워 넣습니다.

uim-벼루를 작업했을 때의 트릭을 그대로 이용해서 중성 ㅐ를 두 번 눌러 ㅒ를 입력하는 것과 ㅔ를 두 번 눌러 ㅖ를 입력하는 것은 쌍자음과 이중모음 및 이중받침을 처리하는 자료 구조만 수정해서 처리합니다. 여기까지 하면 전체 작업의 반 정도를 완료한 셈이 됩니다.

연속입력으로 종성 바꾸기

간단히 KeyMultiKeyTable 자료구조로 선언된 테이블 데이터를 읽어다가 중성 자모의 입력 여부를 검사하고 자모 조합 테이블의 조합 성사 여부를 검사하여 적절한 자모를 오토마타로 전달해 주는 함수를 작성했습니다. 그런 다음 뒤에 쓸 fcitx와 ibus에서 테스트를 했습니다. 잘 되더군요.

어? 이런..

간단한 수정이었으면 눈으로만 보고 머지했을텐데, github 버전 소스 코드와 tar 버전 소스 코드 사이에 변경점이 많아서 일단은 그냥 제가 작업한 옛날 버전 코드를 제 레파지토리에 올렸습니다. (https://github.com/navilera/318Na_HangulKeyboard/tree/master/libhangul) git의 장점을 잘 활용하지 못하는 것 같아서 조금 속상합니다..

소스 코드는 나중에 참고용으로 github에 올려두고 필요하신 분은 첨부한 so 바이너리 파일을 사용하시기 바랍니다. 바이너리 파일은 https://github.com/navilera/318Na_HangulKeyboard/tree/master/Bin/libhangul 에 있습니다.

우분투나 민트 리눅스는 libhangul.so.1.0.0 파일을 /usr/lib/x86_64-linux-gnu/ 로 복사하면 됩니다.

fcitx

제가 고친 코드는 https://github.com/navilera/fcitx-hangul 에 올려 두었습니다. 다만 제가 사용하는 민트 리눅스의 무슨 문제 때문인지 fcitx는 설정이 계속 디폴트 값으로 되돌아 가는 통에 부득이하게 기본 설정을 수정해 버리고 말았습니다. 이점 염두해 두시길 바랍니다.

우분투나 민트 리눅스 쓰시는 분은 제가 만든 바이너리를 사용 할 수 있습니다. https://github.com/navilera/318Na_HangulKeyboard/tree/master/Bin/fctitx-hangul 에서 바이너리 파일을 구할 수 있습니다. fcitx-hangul.so 파일을 /usr/lib/x86_64-linux-gnu/fcitx 로 복사합니다. 그리고 fcitx-hangul.desc 파일을 /usr/share/fcitx/configdesc로 복사합니다. 그런 다음 시스템을 재부팅하고 fcitx-hangul의 설정 윈도우에서 3-18Na 자판을 고르면 됩니다.

IBus

뻘소리 하나

fcitx는 배포판의 설정 문제인지 설정 윈도우가 잘 안나오고 설정이 자꾸 풀려서 디폴트 설정으로 되돌아가는 문제가 있더라구요. 그래서 불가피하게 기본 설정값을 수정해서 3-18Na를 적용할 수 밖에 없었습니다.

ibus는 한동안 만족스럽게 쓰고 있었는데, 바로 이 글을 쓰는 과정에서 원인을 모르겠는데 조합중인 글자가 그냥 사라져 버리는 현상이 생기더라구요. 나중에 시간나면 한번 고쳐보고 싶습니다.

uim이 그나마 지금까지 별 문제없이 잘 동작하고 있고 제 개인적인 느낌일 수도 있는데 묘하게 반응속도도 조금 더 빠른것 같습니다. 그래서 다시 uim으로 설정을 조금 전에 바꾸고 이 글을 마무리 하고 있습니다.

뻘소리 둘