이 문서는 한손 자판과 아너림 자판, 소젯 키보드의 개발 과정을 처음부터 끝까지 정리한 것이다. 최종적으로 완성된 자판이 나오기까지의 과정을 상세히 기록함으로써 발전 과정은 물론이고 시행 착오와 중간 결과물까지 빠짐없이 기록했으며 심지어 개인적인 의견이나 개발중에 있었던 일화까지도 일일이 기록했다. 이런 기록이 없으면 과거에 했던 실수를 똑같이 반복할 위험이 있고 이미 고려 대상에서 제외된 것을 불필요하게 재고려하는 경우도 있다.

지극히 개인적인 기록이며 그다지 잘 정리되지 않았음에도 불구하고 이 기록을 공개하는 이유는 자판은 개인의 소유가 아니라 사용자 다수의 합의가 필요한 공적인 물건이기 때문이다. 개인적인 의견을 완전히 배제할 수 없지만 글쇠 하나의 배치를 위해 어떠한 고민을 했는지, 왜 저런 구조가 나왔는지에 대한 결정의 근거를 일일이 밝혀 놓는 것이 다음 작업자에게 소중한 정보가 되며 최종적으로 완성도 높은 키보드를 만들 수 있게 된다.

개발자의 잘못된 판단이 있었다면 마땅히 비판 받아야 하며 좋은 아이디어라면 계승, 흡수되어야 한다. 다소 부끄러운 면도 있지만 숨김없이 공개하였으므로 읽는 사람이 지혜롭게 취사를 결정하기 바란다. 개발 일자별로 정리되어 있으므로 순서대로 읽으면 개발 과정 일체에 대해 파악할 수 있다. 중간 중간의 오타까지도 의도적으로 그대로 내버려 두었으므로 목적 의식이 없으면 이 글을 읽기는 굉장히 따분하다.

태고적 버전

한손 자판의 최초 버전은 1989년 가을경 도스용 워드 프로세서 MITURI를 개조한 HANSON 프로젝트이다. MITURI는 그래픽 환경에서 실행되며 기본적인 한글 오토마타는 물론이고 폰트 변경, 크기 변경 등이 가능하며 인쇄까지 구현했었다. 나름대로 오랜 기간 작업하여 완성했으며 1990년 전국 컴퓨터 서클 연합(UNICOSA) 전시회에 출품하여 한겨레 신문에까지 발표되었고 이를 변형한 HANSON 프로젝트는 1990년 대학 서클 전시회에 출품하기도 했다. 그러나 본인의 군입대로 인해 개발이 무기한 중단되었으며 제대 후 결국은 드랍되고 말았다.

HANSON 프로젝트는 오른손은 전혀 사용하지 않고 왼손만으로 한글을 입력하는 자판이다. 어떠한 라이브러리도 사용하지 않았으며 100% 기계어(어셈블리도 아닌)로 제작했다. 당시 제작한 프로그램의 실행 파일과 소스가 아직도 백업되어 있다. 그러나 안타깝게도 허큘리스 그래픽 카드에서만 실행되기 때문에 현재는 이 프로그램을 실행해 볼 방법이 없으며 전시회 팜플렛 정도의 문서만 남아 있어 당시의 키 배치가 어떠했는지 알 방법이 없다.

결국 HANSON 프로젝트는 시도만 해 보고 결실을 내지 못한 프로젝트로 끝나고 말았다. 하지만 18년이 지난 후 그 경험은 새로운 프로젝트를 만드는데 긴요하게 사용되었다. 과거에 몰두해서 만들었던 기억과 집착은 시간이 지난 후에도 여전히 유효했다. 하룻밤 사이에, 불과 서너시간만에 한글 오토마타를 완성했는데 스스로도 놀랄 따름이다. 역시 경험이라는 것은 몸서리 쳐질 정도로 무서운 것이다.

07년 8월 14일

2007년 경 봄에 계속 생각만 하고 있다가 8월 13일 밤 잠이 안 와 이것 저것 생각하다가 갑자기 필을 받아 새벽 2시부터 작업했다. 가끔 살다보면 미친듯이 코딩이 잘 되는 날이 있는데 그날 새벽부터 다음날 새벽까지가 그런 날이었다. 늘 그렇지만 첫 번째 버전은 모습이 초라하다.

음소의 출현 빈도에 대한 정보없이 키를 마음대로 배치했기 때문에 Shift의 사용 빈도가 너무 높다. 그리고 한/영 변환, 수/언 변환키의 위치를 너무 좋은 곳에 배치하여 음소를 배치할 공간이 부족하다. 첫번째 버전으로서는 나름대로 성공적이었다.

07년 8월 15일

■ 음소의 출현 빈도를 조사하는 기능 작성하고 산출된 통계에 따라 키 재배치

■ 한/영, 수/언, Caps의 키를 위로 올림으로써 음소를 배치할 수 있는 여분의 공간 확보.

■ 음소의 키가 늘어남으로써 Shift의 사용 회수가 대폭 줄어듬. 그래서 Shift를 왼쪽으로 한칸 이동

■ 좌 자음, 우 모음 형태로 배치. 입력에 리듬감이 생김

■ Shift + Space에 BS 기능 및 Caps + Space로 Enter 기능 부여.

07년 8월 16일

■ 통계 기능을 더 정밀하게 구성, 고전 단편 소설로 통계를 뽑아 참조함

■ 한/영, 수/언은 Mode 하나로 통합. 음소키보다는 빈도가 떨어진다고 판단

■ 제일 윗열이 제거되어 손가락의 이동 거리가 획기적으로 짧아짐

■ 쉼표와 마침표를 글쇠에 포함시킴. 통계 결과 이 구두점은 글자만큼이나 자주 사용되므로 모드를 바꿔가며 사용하기에는 너무 번거롭다.

■ ㅑ, ㅕ, ㅛ, ㅠ 모음을 단모음 두 번 누르는 방식으로 변경

■ 기타 구조체 통합 및 화면 출력 가다듬음

07년 8월 17일

■ 더블 쉬프트 동작을 도입함으로써 키의 활용도가 더 높아짐.

■ Caps 키 제거, Mode가 대소 변환, Shift+Mode가 모드 변경. DShift+Space가 Enter

■ 된소리를 더블 쉬프트 위치로 옮김으로써 키 개수가 더 줄어듬. 총 15키

07년 8월 18일

■ 키를 너무 많이 줄여 불편해진 것 같아 하나 더 늘림. 총 16키.

■ Y키의 위치가 다소 불편해도 Shift를 누르는 것보다는 더 좋아 보임. 그리고 자판은 직사각형인 것이 가능 예뻐 보임

■ 새 키에 ㅁ 배정. ㅁ의 빈도가 생각보다 높음. 다음 순위인 ㅎ이 Shift로 남아서 아쉬움

■ 타수 출력 기능 추가. 키보드의 성능 테스트에 꼭 필요함. 타수는 2벌식과 동일한 비교를 위해 키를 누른 회수가 아니라 2벌식의 경우를 가정하고 계산함. 예를 들어 ㅑ 입력시 한손은 두 번 눌러야 하지만 2타로 계산하지 않고 1타로 계산한다. 그래서 타수가 다소 낮게 계산된다.

07년 8월 19일

■ Mode와 ㅁ의 위치를 바꿈. 아래쪽이 더 치기 쉽다고 판단했음. 커스텀 키보드에서 Mode키 자리는 Space옆으로 옮길 예정임. Y 자리에 음소 하나를 더 배치할 수도 있으나 이 자리는 치기가 그리 쉬운 자리가 아님. 그리고 PC 상의 연습 프로그램에서는 Mode 키가 따로 갈 데가 없으므로 이 자리를 남겨 두는 것도 대중화를 위해 의미가 있다고 판단.

■ 따옴표, 물음표, 느낌 표 등의 구두점도 더블 쉬프트로 포함시킴. 더블 쉬프트 자체가 그다지 편리하지는 않지만 모드를 바꾼 후 입력하고 다시 한글로 돌아오는 것보다는 훨씬 더 효율적임.

■ 양손 동시 지원 가능해짐. 이전에도 가능은 했었으나 중간에 키가 겹치는 부분이 있어서 왼쪽, 오른쪽 중 하나를 선택해야 했었음. 키의 겹침이 없어져 양손 모두 표시 및 지원할 수 있음

■ 입력기 옵션 설정. 최종 사용자를 위해서가 아니라 옵션을 바꿔 가며 테스트해 보기 위해. 이후 기능들을 넣었다 뺐다 할 것이 아니라 가급적이면 시도했던 모든 기능들을 옵션으로 작성할 예정임.

■ 통계 기능 개선. 미리 준비된 샘플 텍스트 및 손가락 부담률, 연타율 등도 뽑아 봄. 통계 결과 연타율은 10%가 조금 넘고 집게 손가락의 부담이 다소 높은 것 같다.

통계에 의해 조사된 빈도와 손가락 사이의 분담률 등을 고려하여 세 가지 모드의 키 배치를 만들었다. 전체 키배치는 다음과 같다.

■ 한글

모음은 여섯개밖에 없기 때문에 모두 Shift없이 입력할 수 있도록 배치했다. ㄴ,ㄹ이ㄱ,ㅅ보다 빈도가 조금 더 높지만 아래쪽에 배치된 이유는 바로 옆의 모음 ㅡ와 함께 쓰이는 경우가 많기 때문이다. "는","를","을" 조사가 특히 많이 쓰이며 "가" 조사를 치기에도 현재의 ㄱ위치가 더 적합하다고 판단했다.

ㄱ,ㄴ이 ㅅ,ㄹ보다는 빈도가 더 높아서 입력하기 쉬운 위치에 배치했다. 이렇게 되면 집게 손가락의 부담이 너무 커져 ㄱ,ㅅ을 바꾸고 ㄴ,ㄹ을 바꾸는 것도 고려해 보았으나 집게 손가락의 부담이 32%에서 31%정도밖에 줄지 않아 분담효과가 떨어졌다. 집게 손가락이 많은 키를 눌러야 하지만 원래부터 힘이 좋은 손가락이므로 이대로 두기로 한다.

더블 쉬프트 위치에는 텍스트와 함께 자주 입력되는 구두점을 배치했으며 이 배치는 영문에도 동일하게 적용된다. 그래서 입력중에 모드를 바꿀 필요가 별로 없다.

■ 영문

문자키가 13개이므로 26개의 알파벳을 모두 배치할 수 있다. 더블 쉬프트 위치에는 한글과 마찬가지로 텍스트 입력에 자주 사용되는 구두점들을 배치했다. 빈도에 따라 배치했다고는 하나 영문은 Q, Z를 제외하고는 대부분 빈도가 그리 낮지 않아 한손으로 입력하기에 문제가 많다. 쉬프트 비율은 대략 12%정도이다. 빈도대로 배치하면 집게 손가락의 부담률이 36%에 이르며 연타율은 20%나 된다. 그래서 빈도가 높은 O를 집게 손가락으로 분산시키고 I도 약지로 분산시켰다. 그 결과 집게 손가락 분담률은 33% 정도로 떨어지며 연타율도 1% 정도 떨어진다. 영문에 대해 좀 더 연구하여 연타율을 더 감소시킬 필요가 있다.

■ 숫자

숫자, 기호의 키배치는 빈도에 상관없이 찾기 쉽도록 배치했다. 한영 모드에 이미 포함된 키는 중복 배치할 필요가 없으므로 제외했다. 숫자키는 PC의 NumPad와 동일하게 배치했으며 숫자 옆에 PC의 숫자키에 있는 동일 문자를 배치했다.

PC 키보드상의 숫자, 기호키는 총 21이므로 총 42개의 문자가 있는 셈이다. 이중 한영 모드에 들어간 문자 12개를 제외하면 30개를 배치해야 한다. 문자키가 13개에 노말, 쉬프트에 각각 배치하면 26개가 되므로 나머지 4개는 어쩔 수 없이 더블 쉬프트 위치에 넣었다. 더블 쉬프트에 여유분 9개가 남아 있는데 유로, 엔 등의 추가 문자들이 더 할당될 수 있으므로 여유분을 남겨 두는 것도 의미가 있을 것 같다.

07년 8월 20일

한손 자판으로 계속 타이핑 연습을 해 봤으나 분당 100타 안팎 정도 밖에 안나옴. 최고로 숙달되어도 300타를 넘기가 어려울 것으로 판단됨. 그 이유는 Shift키를 자주 눌러야 하는 것도 있지만 좌우 교대로 치는 방식에 비해 한손만으로 쳐야 하는 단점이 있기 때문이다. 그래서 이때부터 두손식 자판을 고려하기 시작함. 두손을 고려하기 시작한 결정적인 이유는 한손으로 한글은 어느 정도 입력할 수 있지만 영문은 도저히 한손으로 입력하기 어렵기 때문이다. 영문이 너무 불편하면 키보드로서의 가치가 떨어질 수밖에 없다.

키의 개수를 줄이는 것도 중요하지만 빠른 입력과 편의성이 그보다 더 중요함. 어차피 사람 손은 두 개이고 타블렛 PC나 UMPC 정도면 두손 자판이 그리 부담스럽지는 않다. 그렇다고 해서 한손 자판의 존재 가치가 없는 것은 아니며 여전히 활용 용도가 있으므로 두 개의 키보드를 동시에 개발하기로 한다. 한손 자판은 장애인용과 핸드폰같은 장비에 여전히 활용 가치가 있다.

두손을 쓰므로 키의 개수가 늘어나 음소 배치에 다소 여유가 생겼고 가장 좋은 점은 손가락 하나당 담당키가 3개 밖에 안된다는 점이다. 집게 손가락이 옆으로 삐져 나올 이유가 없어졌다. 이후 두손식 개발에 전념하기로 하고 초안 배치 작성. 한손식과 코드를 최대한 공유할 수 있도록 소스를 대폭 수정 및 보완하여 두손식의 초안을 만들었으며 옵션으로 한손, 두손을 실시간 교체할 수 있도록 했다.

초안 배치해 본 결과 타이핑 속도는 한손식보다 월등히 빠르다. 주요 자음들을 모두 Shift없이 입력할 수 있으며 모음도 ㅐ, ㅔ 두 개가 더 늘어 복모음 입력 회수가 줄었다. 이로써 모음은 모두 2타 이하로 입력할 수 있다. ㅐ, ㅔ가 추가됨으로써 복모음 구성 방식에 상당한 변화가 생겼으며 내부 코드에도 엄청난 충격이 가해졌다. 연구 결과 모음은 최소 6개로도 가능하고 8개 이상 있을 이유가 없다.

2벌식과 거의 유사한 구조로 배치하여 암기하기도 어렵지 않다. 다만 ㅁ, ㅎ, ㅗ, ㅜ 등 2벌식과 다른 위치에 있는 키가 몇 개 있어 초반에는 오히려 더 헷갈리는 경향이 있는 것 같다. 한손식의 Space키에 기능이 중첩되어 있던 BS와 Enter를 별도의 키로 배정했다. 수정 및 개행이 문자 입력만큼이나 잦기 때문에 따로 키를 배정할만하며 이 두 키는 다른 용도로도 활용할 가치가 높다.

그러나 만들어 놓고 보니 2벌식의 영향을 너무 받은 것 같다. ㅇ,ㄴ,ㄹ의 우선 순위가 빈도와 맞지 않고 ㅓ,ㅏ도 마찬가지이다. 또한 왼쪽 아래열의 ㅂ,ㅅ,ㅎ,ㅁ은 영문과의 연계까지 고려하다 보니 저 순서로 나올 수밖에 없다. 한글, 영문의 기호 배치를 동일하게 하려다 보니 ㅃ,ㅆ이 붙어 있는 것이 좋기 때문이다. 빈도순으로 한다면 ㅂ,ㅎ,ㅁ,ㅅ순으로 하는 것이 옳다.

여기까지 작업해 본 후 기존 2벌식과의 연계를 과감히 끊을 필요가 있다고 판단했다. 어차피 키의 개수가 작아 암기의 편의성은 고려하지 않아도 될 듯하며 비슷해서 헷갈리는 것보다 아예 달라 버리는 것이 더 나을지도 모른다. 철저한 통계에 의해 빈도, 부담율, 연타율 등을 가급적 낮게 만드는 것이 합리적인 것 같으며 키 배치를 위해서는 더 정밀한 통계가 필요하다.

키의 개수도 아직 확정된 것은 아니다. Shift는 어차피 손가락 범위에 두어야 하고 개행도 잦으므로 Enter도 마찬가지이다. 그러나 BS와 Mode는 문자 입력과 직접적인 연관이 없으므로 밖으로 빼는 것도 가능하다. 이 경우 두 개의 키를 더 쓸 수 있어 된소리를 제외한 모든 키가 Shift없이 배치되고 영문도 V, K를 Shift없이 입력할 수 있다. 통계 산출 후 결정할 것이다.

다음은 두손 자판의 전체 키 배치도이다. 양손이 가운데로 모이므로 키보드에 수직이 아니며 따라서 윗열을 중앙으로 조금 기울였다. 키들은 바둑판식으로 배치하되 네추럴 키보드처럼 키패드 전체를 약간씩 회전시켜 배치하는 것도 좋다.

타블렛 PC에 키를 배치할 때는 LCD 좌우에 나누어 배치하되 이때 Space키는 오른쪽에 두는 것이 좋다. 아니면 중앙 아래쪽에 배치하되 가운데 터치 패드 등을 배치하여 두 키 사이를 적당히 띄워야 한다.

07년 8월 21일

정확한 키 배치를 위해서는 우선적으로 통계가 정확해야 한다고 판단하고 통계 기능을 대폭 보강하고 샘플 데이터도 다양한 종류의 문서를 취합하여 준비했다. 두손식도 통계에 포함시켰고 KeyMap을 변경하면 통계 정보가 수정된 맵을 참조하도록 하여 이후 키 배치를 신속하게 수행할 수 있는 준비를 했다. 영문 대소문자 비율도 구하고 행별 부담률 등도 구했다.

우선 한글에 대한 배치를 결정하기 위해 한글에 대한 빈도를 중점 조사했는데 샘플에 따라 빈도가 조금씩 달라진다. 하지만 큰 틀은 거의 변화가 없다. 다음은 한글 자음에 대한 빈도 조사 결과이다.

ㅇ

ㄴ

ㄹ

ㄱ

ㄷ ㅅ

ㅁ ㅎ ㅈ

ㅂ

ㅆ

ㅊ

ㅌ ㅍ

ㄲ ㄸ

ㅋ

ㅉ ㅃ

앞쪽의 ㅇㄴㄹㄱ의 순위는 샘플에 상관없이 겅의 동일하며 그 중 ㅇ의 빈도가 압도적으로 높아서 한글 음소만으로 따진다면 10%가 훨씬 넘는다. 5위 이후 같은 칸에 적힌 것은 빈도가 거의 비슷해서 샘플에 따라 엎치락 뒤치락 하는 것이되 위쪽에 적은 것이 조금 더 높다. 즉 ㄷ과 ㅅ은 빈도가 거의 비슷하며 ㅁ,ㅈ,ㅎ도 도토리 키재기이다. 모음의 조사 결과는 샘플에 상관없이 거의 동일하게 나온다.

ㅏ

ㅓ

ㅣ

ㅡ ㅗ

ㅜ

ㅔ ㅐ

ㅏ가 압도적으로 높고 다음이 ㅓ,ㅣ 순이되 이 둘의 빈도차는 심하지 않다. 나머지는 두개씩 비슷한 순위를 보인다. 자음과 모음을 합친 순위는 ㅇ,ㅏ,ㄴ,ㅓ,ㅣ,ㄹ,ㄱ 순이며 자음과 모음이 비교적 고른 비율을 보인다. 음소외에는 Space가 가장 높아서 ㅇ보다도 더 자주 발생하며 Upper는 ㄱ과 ㅅ사이의 빈도를 보이고 Enter는 모음보다는 낮고 ㅆ정도의 빈도를 가진다. 마침표의 비율은 Enter보다 조금 더 높고 쉼표는 ㅊ다음 순위 정도 된다. 다음은 인터넷에서 조사한 영문 알파벳의 출현 빈도이다.

ETAONSHRDLICUMFGWYPBVKJXQZ 순서이다. 직접 만든 통계 빈도와는 약간 차이가 있는데 샘플에 따른 차이인 것 같으며 영문은 별도의 통계를 뽑는 것보다 공식 통계를 참조하는 것이 더 나을 것 같다. 영문 배치는 일단 접어 두고 한글 먼저 배치하기로 한다.

이 비율을 참조하여 빈도가 높은 순위대로 치기 쉬운 위치에 배치했다. 빈도별 키의 우선 순위는 통계적으로 구할 수 없으므로 경험적으로 다음과 같이 메겼다. 가운데 행이 가장 좋고 다음 윗행, 다음 아래행 순으로 순위를 메겼다. 키의 순위는 사람에 따라 개인차가 발생할 수 있으므로 정확하다고 볼 수는 없다. 좌우 대칭이므로 왼쪽만 순위를 메겼다.

비교적 상식적인 순위이지만 5,6번과 7,8번의 순위는 거의 비슷해서 필요에 따라 키를 교환할 수 있다. 이 우선 순위에 따라 키를 재배치한 결과는 다음과 같다.

키 배치의 수정 외에도 몇 가지 변화가 보이는데 이 변화에 대해서는 결정의 근거를 분명히 남길 필요가 있을 것 같다. 우선 Shift키의 이름이 Upper로 바뀌었다. 원래 Shift라는 용어가 수동식 타자기의 용어이므로 컴퓨터 자판에는 어울리지 않으며 기능키 입력을 위해서는 진짜 Shift키가 따로 필요하기 때문이다. Upper외에 더 좋은 이름을 생각해 봤으나 Sub, Second, Hidden 등 마땅히 쓸만한 이름이 없었다.

제어키의 위치가 조정되어 반시계 방향으로 한바퀴 회전했는데 이렇게 한데는 아주 복잡한 이유가 있다. 한글키 배치의 큰 원칙은 자좌음, 우모음이며 그렇다보니 ㄲ,ㅆ같은 된소리가 전부 왼쪽에 있고 이렇게 되면 된소리 입력시마다 왼손이 연타를 쳐야 한다. 또한 기호 영역 확보를 위해 영문도 한글의 Shift위치에 같이 배치되므로 영문의 경우도 마찬가지다. 그래서 Upper가 오른쪽으로 이동했으며 나머지 키들도 자리 재 배치를 할 수밖에 없는 것이다.

Enter는 2벌식과 마찬가지로 오른쪽에 자리를 지키도록 했으며 BS는 왼쪽으로 가고 Mode가 좀 더 좋은 위치를 차지했다. 오른쪽 새끼 손가락의 분담률은 6.6% 정도로 적당하며 왼쪽 새끼 손가락의 분담률은 2% 미만이라 거의 부담이 없다. 다만 Mode를 얼마나 바꿀 것인가, BS를 얼마나 자주 누를 것인가에 따라 왼쪽 새끼 손가락의 부담률은 증가할 것이다. 문서가 복잡하거나 초보자라면 Mode, BS를 자주 사용하므로 왼쪽 새끼 손가락에 여유분을 고려했다.

이상의 변화외에 내부적인 소스 정리도 많이 수행했다. 키보드를 조금 기울어지게 그렸고 KeyMap 배열을 정리했으며 경고음 발생, Upper키가 없을 때 노말키로 변환 등의 기능도 추가했다. 다음 작업은 기능키를 배치하는 것이다. 한손식에 비해 두손식은 2벌식 키보드의 완전한 대체를 목적으로 하므로 큰 그림을 먼저 그릴 필요가 있다.

07년 8월 22일

문자키에 대한 작업은 잠시 보류해 두고 기능키에 대한 전반적인 기획을 해 보았다. 이 기획을 한 이유는 아무리 미니 자판이고 키가 적더라도 PC 키보드를 완전 대체할 수 있어야 한다고 생각했기 때문이다. 물론 키 개수에 제한이 있어 불편을 감수해야 하고 효율적이지도 못하지만 최소한 필요하다면 쓸 수 있는 가능성은 있어야 한다. 그리고 이 기획에 따라 문자키 배치나 최소 필요한 키의 개수가 결정되므로 우선적으로 작업할 필요가 있다고 생각했다.

문자키와 기능키를 구분하기 위해서는 최소한 Fun키가 하나 있어야 한다. 그리고 단축키 입력을 위해 Ctrl, Alt, Shift 조합키도 모두 필요하다. Fun을 누른 상태에서 문자키를 누르면 기능키 입력으로 해석한다. 각 문자키에 기능키를 배치해 본 결과 현재의 키 개수로는 모든 기능키를 배치할 수 없다. 그래서 커서 이동키 4개를 추가했고 이 키에 PgUp, PgDn, Home, End의 기능도 부여했다. 각 키의 기능키 배치는 다음과 같다.

Del	F1	F2	F3	F4	F5	F6	Ins
	F7	F8	F9	F10	F11	F12
Tab	Esc	PrtSc	NumLock	Win	Pause	한자	CapsLock

Upper와 Mode는 Fun키와 함께 사용해야 하므로 기능키를 부여할 수 없다. Win은 조합키로 사용되지만 조합키는 더 만들 여유가 없어 일반키로 만들었다. Scroll Lock은 잘 쓰이지 않으므로 제거했다. NumLock도 숫자 모드의 배치가 키패드와 유사해서 일단 제거했는데 원칙대로 하자면 넘패드의 스캔 코드가 일반 숫자키와는 틀리기 때문에 필요는 하다.

기능키 자체가 동작하지는 않지만 어떤 키가 눌러졌는지 알아내고 가상키까지 조사하도록 구조를 만들어 두었다. Fun+Ctrl키와 W키를 누르면 Ctrl+F1이 입력되었다는 것을 표시하기만 한다. 이 작업을 위해 굉장히 많은 코드를 작성했으며 구조도 상당히 많이 바뀌었다. 특히 Alt키 입력을 위해 시스템 키 메시지까지 처리하는 부분에서 애를 먹었다. 그래서 이 작업을 먼저 할 필요가 있었던 것이다. 몇 가지 버그가 있기는 하지만 기존 키보드의 완전 대체가 적어도 이론적으로는 가능함을 확인했다.

이외에 프로그램의 외관도 많이 수정했다. Shift 조합키가 도입되었으므로 Caps는 제거했으며 대신 기능키 구현에 필요한 키들이 쉬프트 양쪽으로 배치되었다. 메뉴, 상태란으로 전체적인 UI를 정리하고 사각형 대신 ApiEdit를 사용하여 캐럿 출력 및 이동 처리가 가능하며 중간에 삽입, 삭제도 된다. Del키는 그 전에 없었는데 일단 Upper+BS에 기능을 할당했다. ApiEdit는 단순히 출력용으로만 사용하므로 대부분의 기능을 막아두었다. 포커스도 받지 못하고 마우스 입력도 완전히 무시한다. 마우스로 키를 누르면 입력하는 기능도 추가했는데 이는 테스트 및 차후의 프리젠테이션을 위해서이다. 레지스트리에 최후 위치를 저장함으로써 테스트하기 더 편해졌다. 여기까지의 작업 결과는 다음과 같다. 커서 이동키를 가운데 그렸다.

전체적인 윤곽이 잡혔으니 다음은 키배치에 대해 고민해 볼 차례다. BS와 Mode를 과연 그대로 둘 것인지 아니면 이 자리에 문자키를 재배치할 것인지가 고민인데 아직 결정은 못했다. 한글 타자만 할 경우 Mode의 사용 빈도가 떨어지고 숙련자는 BS도 잘 쓰지 않으므로 차라리 이 자리에 문자키를 더 배치하는 것도 좋다. 다행히 바로 옆에 Caps와 Tab키가 있어 대체하기는 어렵지 않다. 이 두 키를 문자키로 바꾸었을 때의 장단점을 정리해 보면

장점	단점
한글의 ㅌ,ㅊ이나 ㅆ을 Upper없이 입력 가능 영문의 K, V도 Upper없이 입력 가능 Upper 회수가 줄어 전반적인 속도 향상 다른 나라로 이식할 때 키에 여유분이 더 생김 왼쪽 새끼 손가락의 분담률이 적절해짐	키가 두 개 더 늘어난다. 입력중에 손가락이 범위를 벗어나는 일이 생긴다. PC 상에서 키의 실제 위치가 너무 헷갈린다. 하단의 기능키 영역이 너무 번잡해진다.

결정하기 참 어려운데 바꿨을 때 실제 어떤 결과가 나올지 통계를 뽑아 보았다. 일단 바뀐 후의 모습을 보자. 소스에 키맵 배열이 잘 정리되어 있어 키 배치를 바꿔 보는데는 2분이면 된다. 역시 소스를 잘 정리하는 것이 중요하다.

Mode는 Space 왼쪽에 배치하여 왼쪽 엄지 손가락으로 누른다. BS는 오른쪽에 배치하여 Space와 마찬가지로 오른쪽 엄지 손가락으로 누른다. 물론 PC 상에서는 이런 구조가 될 수 없다. 바꾸기 전과 후의 통계를 비교해 보자.

	Mode, BS 분리전	Mode, BS 분리후
한글	왼쪽 새끼 분담률 : 1.69% Upper키 비율 : 4.5%	왼쪽 새끼 분담률 : 3.77 Upper키 비율 : 3.87%
영문	왼쪽 새끼 분담률 : 1.82% Upper키 비율 : 5.9%	왼쪽 새끼 분담률 : 3.68% Upper키 비율 : 4.49%

왼쪽 새끼 손가락의 분담률은 BS, Mode를 전혀 쓰지 않을 때를 가정한 것이므로 사실 큰 의미가 없다. 키가 늘어난만큼 Upper키의 비율은 떨어진다. 그리고 새로 할당된 키들의 입력도 편해진다. 한글의 경우 Upper에 있는 ㅌ(0.55%), ㅋ(0.4%), ㅆ(1.2%) 중 두 개를 새 키로 옮기면 대략 0.9~1.7% 정도 Upper 비율이 줄어든다. 영문도 1.3%정도 줄어든다.

생각보다 효과가 그리 크지 않다. 물론 실제 사용해 보면 늘어난 두 키의 위력이 좀 더 크게 실감될 것이다. 특히, 영문의 경우 대소문자 변환을 위해 Shift까지 쳐야 하므로 비록 비율이 낮더라도 Upper키 사용횟수는 최소화되어야 한다. 대문자 X를 입력하려면 Upper 누른 후 Shift누른 채로 X키를 눌러야 하니 엄청 불편하다. 영문만 생각한다면 아예 Mode, Bs 없애고 중앙의 1,2행에 두 개씩 더 배치하여 26개를 다 넣었으면 좋겠다. 그러나 이렇게 하면 자판을 만드는 의미가 없어지는 것도 사실이다.

이 문제는 좀 더 두고 생각해 보겠지만 일단은 원래의 모양을 유지하는 것으로 가닥을 잡고 있다. 어차피 PC 키보드를 완전 대체하지는 못하므로 애초의 제작 목적을 유지하는 것이 현명하다. 그리고 한글 입력만 편하면 됐지 굳이 영문 자판까지 눈치를 살필 필요는 없다. 26개의 키는 편리한 입력용으로는 개수가 너무 많다. 물론 내일이 되면 또 생각이 어떻게 바뀔지 알 수 없다.

07년 8월 24일

이틀간 지속적인 작업 끝에 또 다시 많은 변화가 생겼다. 키 배치의 변화는 빼고 기능상의 변화만 간략하게 정리한다.

■ Ctrl, Alt, Shift, Fun 키를 같이 누르는 것이 아니라 누른 후 문자키를 누르는 방식으로 변경. 같이 누르기도 어렵고 그럴 필요도 없다. 동일키를 여러번 입력할 때를 위해 더블 푸시하면 락하는 기능도 만들었다.

■ Fun키를 LCtrl로 옮겼다. Shift는 둘 다 필요하지만 Ctrl은 그럴 필요가 없으며 위치도 Ctrl이 더 좋다.

■ Fun 상태일 때 기능키 목록을 화면으로 출력한다. 아직 별로 예쁘지는 않다.

■ 통계 기능 향상 - 해시 검색, 메인의 선택된 키보드 기준, 빌더 기능 좀 더 향상.

■ Upper키도 더블 푸시하면 락을 걸었다. Del키를 여러번 입력하거나 %# 같은 기호 반복 입력 필요

■ 모음만 입력시 ㅇ삽입하는 걸 옵션으로. 모음만으로 된 글자를 완성형으로 변환 못하는 것으로 알았는데 알고 보니 초성의 필 코드를 채우지 않아서 생기는 버그였다.

■ 첫 영문자 대문자로 바꾸기

■ 옵션 대화상자 4개 깔끔하게 프로퍼티 시트로 정리

■ 모든 옵션 레지스트리에 저장

■ 여러개의 키맵 준비해 놓고 바꿔 가며 쓸 수 있도록 키맵 배열 정의

■ Mode에 액션 하나 더 추가.

■ 기타 소스 정리. PCH를 쓰도록 헤더 파일 구조 집중화시킴

이틀간 한 작업치고는 정말 양이 많다. 그러나 아직도 더 할일들이 많이 남아 있다. 다음은 자판 배치 상태에 대한 변화 과정이다. 한시간 이상 타이핑을 해 보면서 수정해 보고 또 테스트 해 보기를 반복하고 있으며 그 결과 자판은 여러 번 바뀌었다. 중간 과정을 일일이 기록한다.

우선 Mode와 Shift를 결국 아래쪽으로 내렸다. 이 두 키를 놔 두니 초보자들에게 오타가 너무 많이 발생한다. 원래 이벌식에 ㅁ, ㅂ 글자가 배치되어 있어 무심코 누르는 경우가 많은데 이 두 키는 단순 오타가 아니라 모드가 바뀌어 버리거나 이미 입력한 글이 지워지므로 부작용이 심각하다. 그래서 다음과 같이 재배치했다.

■ ㅋ대신 좀 더 빈도가 높은 ㅆ에세 자리를 내 줬다. ㅅ과 ㅆ을 따로 분리하면 "있습니다", "했습니다" 등을 입력할 때 연타율이 떨어지는 이점이 있다.

■ ㅡ, ㅣ를 인접 시킴. '의' 음절의 발생 빈도가 아주 높음. 좌에서 우로 인접하는 것이 좋다.

■ ㅗ,ㅜ와 ㅐ,ㅔ도 인접시킴. 비슷하므로 인접시키는 것이 외우기 쉽다.

■ Upper를 새끼에서 약지로 옮김. 약지가 힘이 더 좋고 Upper키를 자주 누르므로

-Enter를 아래쪽으로 내려 보기도 했다. 그러나 테스트 해 본 결과 별 개선이 없었다. 키가 하나 더 생겨 봐야 기껏 ㅌ이나 ㅊ 정도밖에 못 넣으며 Enter의 빈도가 낮기는 하지만 이게 빠지면 PC 상에서 진짜 Enter키를 눌러야 하고 손가락이 자판을 떠나는 일이 생기기 때문이다.

이 상태에서 오랜 시간 테스트 후 다시 한번 재배치했다.

■ Enter, Upper를 원래대로 되돌림. Upper가 중간에 있는 모양이 안좋고 숫자 모드에 숫자 배치가 넘패드 모양으로 나오지 않는 큰 문제가 있음

■ ㅗ와 ㅡ를 바꿈.

■ Alt와 Shift의 자리를 바꿈.

다음은 오늘의 최종 배치 상태이다. 엎치락 뒤치락 자주 바뀐다. 오른쪽은 변화가 없으며 왼쪽 자음 위치만 변했다.

■ ㅂ의 자리가 너무 안좋아 Q자리로 옮겼다. ㅆ은 Z자리로 옮겼고 ㅊ은 원래 ㅂ이 있던 X 자리로 옮겼다. X가 Q보다 더 치기 어렵고 헷갈린다.

■ ㅈ,ㅅ,ㄷ이 서로 자리를 바꾸었다. ㅅ,ㅋ보다 ㄷ,ㄸ의 빈도가 조금 더 높다. V와 E 자리는 비슷하나 E가 조금 더 쉽다. ㅈ은 ㅅ,ㄷ에 비해서는 빈도가 조금 떨어져 한칸 왼쪽으로 밀렸다.

■ 이렇게 만들고 나니 2벌식이랑 자음 상단 구조가 완전히 같아져 버렸다. 그러고 보면 2벌식도 그렇게 못 만든 자판은 아니다. 단 집게 손가락 위치에 ㄹ과 ㅓ를 둔 것은 좋지 않은 것 같다. 집게 위치는 누가 뭐래도 빈도가 가장 높은 ㅇ,ㅏ가 와야 한다.

자판 배치를 여러 번 바꾸어 보고 사용해 봤는데 어떻게 배치하더라도 모든 사람들의 마음에 들 수는 없다는 생각이 들었다. 그리고 나 자신이 매번 바뀐 자판에 익숙해져 가며 연습을 해 봐야 한다는 것도 너무 힘들다. 조금 익숙해지려다 바뀌면 자꾸 이전 자판의 기억이 남아 오타가 발생한다. 자판이란 자주 바꿀 수 있는 것이 아니므로 한번 결정되면 확실히 고정해야 한다. 또한 자판에는 옵션이 존재해서는 안된다는 생각이 들었다. 옵션에 따라 ㄱ,ㅅ과 ㅗ,ㅡ의 위치를 개인적으로 선택하도록 내버려 두어서는 안된다. 자판의 동작은 옵션일 수 있어도 배치 자체는 옵션일 수 없다.

당분간 자판 배치에 대해서는 잠시 보류할 예정이다. 자꾸 바뀌니까 너무 힘들고 통계나 프로그램의 기능도 미비하고 게다가 개발중의 버그와도 싸워야 하니 신경 쓸 게 너무 많다. 자판 배치를 정밀하게 테스트하기 위해서는 프로그램의 동작 환경이 편해야 하며 통계도 좀 더 정밀하게 작성해야 한다. 또 후킹이나 영문 입력같은 것도 전반적으로 고려해 볼 필요가 있다. 현재 Shift키에 대한 고려가 거의 없는데 영문 입력도 중요하고 Shift가 어쩌다가 한번씩 쓰는 키가 아니라는 점을 고려해야 한다.

어쩌면 Mode, BS를 내린 자리에 Shift가 다시 기어 들어갈 지도 모르겠다. Shift는 영문 입력시와 Fun 키와 함께 조합될 때만 사용된다. Fun키 상태에서는 한글 모드도 영문 알파벳으로 해석되므로 한글 모드에서 Shift는 전혀 필요치 않다. 그래서 영문 입력시만 ㅁ자리에 Shift를 배치하는 것도 괜찮을 것 같다.

자판 재배치는 코드를 좀 더 다듬고 배치할 준비가 되었을 때 하루나 이틀 정도 날 잡아서 할 계획이다. 소스 정리도 좀 더 깔끔하게 가다듬어 두고 완벽한 준비를 한 후 몰아서 해야겠다. 아마 다음 주 정도가 되지 않을까 생각된다.

07년 8월 26일

주말 이틀동안 거의 쉬지 않고 작업한 결과 상당한 양의 코드를 작성했다. 자판에 대해서는 일체 손대지 않았으며 기능 개선에만 치중했다.

■ 항상 전체 텍스트를 변환하여 ApiEdit에 넣었는데 한글자씩만 삽입, 삭제한다. ApiEdit의 buf와 HanSon의 buf가 완벽하게 동기화된다. 이로써 ApiEdit에서 위로 이동해도 캐럿 위치가 그래도 유지되며 전반적으로 속도가 빨라졌다.

■ 기능키 상태의 버튼 출력문 좀 더 예쁘게 개선

■ 통계 개선. 연타율 상위 n개 목록 만들어서 출력

■ 단어 연습 및 문장 연습 기능 추가. 연습용 데이터는 좀 더 넣어야 한다.

■ 두더지 게임 제작. 동작은 하는데 디테일이 좀 떨어진다. 잔손질이 더 필요하다.

■ 후킹 기능 초안 완료 - 일단 메모장 정도는 후킹할 수 있다. 그러나 문제가 많다. 조립중인 문자를 보여주지도 못하고 기능키 입력도 되는 것보다 안되는 게 더 많다. 이 기능을 굳이 만들어 본 이유는 키맵 배열에 추가로 더 필요한 것이 있나 알아보기 위해서인데 별 특별한 정보는 필요치 않은 것 같다. 기껏해야 스캔 코드 정도인데 이런 건 룩업 테이블 하나면 얼마든지 알아낼 수 있다.

■ 소스 정리 - 키보드 전체를 하나의 구조체로 정의하고 구조체 배열을 구성함으로써 자판을 얼마든지 정의할 수 있으며 실행중에 옵션 대화상자에서 바꿀 수 있다.

■ 옵션 대화상자에 자판 선택 페이지를 추가하고 한손 자판에 좌우 선택 옵션을 추가했다.

문장 연습 화면과 두더지 게임 화면이다.

이제 자판 배치를 바꿀 때 게임을 해 가면서 바꿀 수 있게 되었다. 코드를 너무 많이 뜯어 고쳐 아마 대량의 버그가 양산되어 있을 것이다. 내일은 디버깅을 하면서 자판 배치에만 몰두한다. 두 손으로 치는 새로운 18자판에 대해서 구상해 두었다.

07년 8월 27일

오늘부터 더 이상의 기능 추가 없이 디버깅과 자판 배치를 할 예정이다. 새로 구상한 자판은 이전의 33자판을 변형한 것이되 역시 변화가 많다. 직전의 35자판은 일단 폐기했으며 기능키의 배치를 우선적으로 결정했다.

-Mode 키는 35키와 마찬가지로 밑으로 내렸다. 아직 프로그램을 수정하지 않아 위치가 좀 맞지 않은데 왼손 엄지 손가락 위치에 놓을 것이다. Mode는 언어의 혼용이 많은 문서 입력을 위해 꼭 필요하되 글자 입력과 직접적인 연관이 없으므로 아래로 내렸다. 이 키를 굳이 왼손 엄지에 배정한 이유는 왼손 엄지가 하는 일없이 놀고 있기 때문이다.

■ Shift키를 글자판에 놓았다. 한글에서는 거의 쓸모가 없지만 영문에서는 빈도가 꽤 높으므로 고유의 자리를 배정하는 것이 좋다고 판단했다. 대략 5~7% 정도의 대문자가 필요하므로 글자판에 놓일 자격은 충분한 것 같다. 차후 좀 더 정밀한 통계를 산출한 후 위치를 재조정할 예정이되 일단 포함은 시킨다. Shift가 글자판의 별도키에 할당됨으로써 PC의 Shift키를 Fun키로 쓸 수 있게 되었으며 귀찮게 좌우키를 구분할 필요가 없어졌다.

■ BS키를 제거했다. 문장 수정을 위해서는 꼭 필요하지만 일단 숙련되면 빈도가 급격히 떨어진다는 점을 감안하여 별도의 키로 배치하지 않았다. 대신 한손식과 마찬가지로 Upper+Space를 BS로 사용하고 Shift+Space를 Del로 사용한다. Upper+Space가 BS라는 것은 상식과도 일치하고 입력하기도 어렵지 않다.

■ 21개 키에 문자들을 빈도별로 배치했다. 이번에도 ㅆ에 별도의 키를 할당했다. Upper와 함께 쓰는 키가 6개인데 영문 다섯자를 이 위치에 적절히 배치하면 될 것이다.

키배치를 위해 예전부터 심각하게 고민했던 것이 ㄲ,ㄸ,ㅃ,ㅆ,ㅉ을 과연 별도의 키에 할당해야 하는가인데 자음을 연타하는 방식으로 입력할 수도 있다. 일반적으로 Upper와 ㄱ을 누르는 것보다 ㄱ을 두 번 누르는 것이 훨씬 더 쉽고 빠르다. 다음은 아무 문제가 없는 경우이다.

ㅅ ㅅ ㅏ ㅇ ㅋ ㅏ ㄹ(쌍칼)

ㅇ ㅏ ㄱ ㅏ ㄱ ㄱ(아�A)

ㄱ ㄱ ㅓ ㄱ ㄱ ㄷ ㄷㅏ ㄹ ㅣ(꺾따리)

된소리가 음절의 처음에 오거나 끝 글자의 받침이면 아무 문제가 없다. 받침이나 두번째 글자의 초성이라도 앞글자의 받침과 명확히 구분되면 애매하지 않다. 그러나 글자 중간의 받침과 초성에 낄 때 문제가 발생한다. 다음 낱글자 순서대로 입력한다고 해 보자.

ㅇ ㅏ ㅅ ㅅ ㅏ(앗사, 아싸)

두 경우 모두 두가지로 해석할 수 있다. 뒤쪽 ㅅ은 의심할 여지없이 뒷글자로 가야 하지만 앞쪽 ㅅ은 앞 글자의 받침이 될 수도 있고 뒷글자의 초성이 될 수도 있다. 이 문제의 원인은 한글에 받침없는 글자가 있어 먼저 입력된 ㅅ이 양쪽 모두 갈 수 있기 때문이다. 두 번의 같은 자음을 앞글자와 뒷글자에 배분하는 규칙이 명확하지 않으며 동일한 음소 순서로 두 가지의 단어가 만들어지므로 애매하다. 앞 글자에 받침이 있어도 이 문제는 발생한다.

ㅇ ㅏ ㄴ ㅅ ㅅ ㅏ(안싸)

ㅇ ㅏ ㅅ ㅅ ㅅ ㅏ(앗싸, 았사, 앗ㅅ사)

안싸의 경우는 앞글자의 받침 ㄴ과 다음의 ㅅ이 복자음이 될 수 없으므로 애매하지 않다. 그러나 두 번째는 가운데 낀 ㅅ이 앞, 뒤 쪽에 모두 갈 수 있을 뿐만 아니라 별도의 음절을 구성할 수도 있어 애매하다. 한글은 초성만으로도 글자가 될 수 있어 세 가지 경우가 생긴다. 다음은 조금 더 심각한 경우이다.

ㅁ ㅏ ㄹ ㅅ ㅅ ㅡ ㅁ(말씀, �┰�)

ㅊ ㅓ ㅅ ㅂ ㅓ ㄴ ㅈ ㅈ ㅐ(첫번째, 첫�Ю�)

두 번의 ㅅ을 하나로 합치면 "말씀"이 되지만 각각의 음소로 인정하면 "�┰�"이 된다. ㅅ이 앞글자의 복자음으로도 사용되고 뒷글자의 된소리가 될 수도 있다. 다음도 마찬가지이다.

ㄷ ㄷ ㅏ ㄷ ㄷ ㅏ(�Q다, 따따)

근본적으로 글자를 누르는 순서만 가지고는 입력된 글의 음절을 결정할 수 없다. 그래서 순서외에 별도의 의사 표시가 더 있어야 한다. 문제 해결 방안으로 먼저 시간이라는 개념을 도입했다. 같은 자음을 더블 푸시하면 된소리로 인정하고 더블 푸시보다 더 긴 시간이 걸렸으면 각각의 음소로 분리한다. 다음 예시에서 +는 더블 푸시한 것이고 -는 조금 쉬었다가 입력한 것이며 아무 표시도 없는 것은 시간 간격에 상관없다는 뜻이다.

ㅇ ㅏ ㅅ-ㅅ ㅏ(앗사)

ㅇ ㅏ ㅅ+ㅅ ㅏ(아싸)

ㅇ ㅏ ㅅ-ㅅ+ㅅ ㅏ(앗싸)

ㅇ ㅏ ㅅ+ㅅ ㅅ ㅏ (았사)

ㅇ ㅏ ㅅ-ㅅ-ㅅ ㅏ(앗ㅅ사)

시간 간격만으로 모든 글자를 구분하여 입력할 수 있다. 그러나 "말씀"은 더블 푸시만으로는 해결할 수 없다. ㅅ을 아무리 빨리 눌러도 앞 글자에서 이미 ㄽ받침이 되어 버렸기 때문에 초성 된소리가 될 수 없다. "첫�Ю�"와 "�Q다" 도 마찬가지다. 앞 글자의 받침이 되어 버린 글자를 다시 뺏어와야 이 문제를 해결할 수 있다. 오토마타에 이런 기능을 작성할 수 있다. 같은 키를 더블 푸시했고 앞글자의 받침 마지막자와 새 자음이 된소리 음소(ㄱ,ㄷ,ㅂ,ㅅ,ㅈ)이면 둘 다 가지고 와 다음 글자의 된소리로 만드는 것이다.

ㅇ ㅓ ㅂ ㅅ-ㅅ ㅜ(없수)

ㅇ 어 ㅂ ㅅ+ㅅ ㅜ(업쑤)

이 방법외에 한글에서 기능이 없는 놀고 있는 Shift키를 활용하는 방안에 대해서도 생각해 보았다. Shift에 음절 완성의 의미를 부여하여 이 키를 누르면 앞, 뒤 글자를 강제로 찢어 놓는 것이다. ㅇ ㅏ ㅅ 까지 입력한 후 Shift를 누르고 ㅅ ㅏ 를 누르면 앞뒤의 ㅅ을 합치지 않는다. Shift를 누를 때 한글 조립 상태를 해제하는 것이다. 그러나 이 방법은 휴대폰에서 처럼 커서 이동키로 다음 위치로 이동하는 것과 같아 입력자의 의도적인 개입을 요구하므로 피로도를 증가시킨다. 또한 Shift를 누를 바에야 차라리 Upper를 누르는게 더 직관적이어서 이 생각은 결국 어줍잖은 아이디어에 불과하다.

더블 푸시와 오타마타의 기능 개선으로 이론상 모든 글자를 입력할 수는 있다. 그러나 글자를 입력하는데 시간차의 개념이 들어가야 하므로 약간씩 멈칫거리는 현상이 발생하며 오타 빈도도 높아질 수 있어 고속 타이핑에는 적합하지 못한다. 또한 3벌식 추종자들이 말하는 소위 도깨비불 현상이 더 심해지는 문제도 있다. 자판을 그냥 두들기기만 해서는 되지 않으므로 난이도도 높아진다.

그럼에도 불구하고 이 기능에 대한 미련을 버리지 못하는 이유는 두 가지가 있다. 첫번째는 문제 발생 빈도가 생각보다 훨씬 더 낮다는 것이며 두 번째는 사람들이 된소리를 하나의 음소로 인식하기 때문에 자연스럽게 더블 푸시를 할 수 있다는 점이다. 쌍시옷을 입력할 때는 초보자라도 ㅅ을 두번 빠르게 누르는 것은 얼마든지 가능하다. 이 기능이 과연 쓸만한지, 아니면 문제 투성이인지는 문제 발생 빈도에 대한 통계를 만들어 보고 개발자가 직접 피나는 연습을 해 보는 수밖에 없다.

이 기능의 채택 여부를 빨리 결정해야 하는 이유는 된소리에 키를 줄 필요가 없으면 ㄱ,ㄷ,ㅂ,ㅈ 위에 ㅋ,ㅌ,ㅍ,ㅊ을 배치하여 비슷한 글자끼리 합칠 수 있고 키가 남아 도는만큼 단순해지고 또 복모음을 배치할 수 있는 여유가 생기기 ��문이다. 오토마타의 동작은 옵션일 수 있지만 키의 배치는 옵션일 수 없다. 그래서 이 기능이 쓸만한지를 빨리 결정해야 한다. 문제가 될 수 있는 모든 경우의 수를 뽑아 보았다. 샘플 텍스트는 460K 짜리의 SampleHan.txt와 2.7M짜리 소설모음.txt 이다.

연속되는 자음	예	빈도
ㄱ ㄱ ㄱ	동백꽃, 아직까지 겪고, 묶고	36, 160
ㄱ ㅅ ㅅ	박씨, 쓱쓱	0, 49
ㄴ ㅈ ㅈ	10년째, 첫번째, 왼쪽, 반쪽, 진짜, 10분쯤, 앉자,	159, 574
ㄹ ㄱ ㄱ	것일까, 할까, 될까, 어떨까, 깔끔, 찔끔, 늙게, 읽고, 굵기, 낡고, 밝게	150, 1500
ㄹ ㅂ ㅂ	열뿌리, 살빼기, 있을뿐, 발뺌	8, 47
ㄹ ㅅ ㅅ	훨씬, 글쓰기, 몇일씩, 말씀	69, 682
ㅅ ㅅ ㅅ	갔습니다, 있습니다, 겠습니다, 덧씌워	55, 668
ㅂ ㅅ ㅅ	일곱씩, 몹쓸, 잽싸게, 휩쓸다, 좁쌀, 씁쓸, 없습니다.	12, 110
ㄱ ㄱ	적극, 먹고, 식구, 약간, 직관, 복구 뒤꿈치, 아까, 느낌, 합니까, 새끼, 가끔	368, 2396
ㄷ ㄷ	받되, 받도록, 듣다보니 여자때문, 어떤, 그때	2, 60
ㅂ ㅂ	급부상, 영업부, 답변, 웹브라우저, 예쁘다, 기쁘다, 재빨리, 바쁘다.	36, 185
ㅅ ㅅ	못생긴, 덧셈, 듯싶다, 못살게, 닷세, 귓속 으로써, 아저씨,	23, 290
ㅈ ㅈ	찾지, 잊지, 늦지, 빚쟁이, 갖지 어쩔수, 그쪽	8, 117

약 세 시간에 걸쳐 통계를 뽑아 보고 문제가 되는 단어를 조사해 본 결과 이 기능을 채택하기는 상당히 어렵다는 결론에 도달했다. 적극, 먹고, 예쁘다, 아저씨 같은 단어는 어쩌다가 한번씩 쓰는 것이 아니라 늘상 쓰는 것이다. 좀 빨리 두들겼다고 해서 저끅, 머꼬가 된다거나 조금 느리게 쳤다고 옙브고, 아젓시가 되어서는 곤란하다. 더블 푸시를 빨리 하는 것은 어렵지 않지만 더블 푸시를 하지 않고 기다리는 것이 어렵다.

더블 푸시 간격은 0.3초로 설정되어 있으며 비교적 합리적인 간격이다. 이 간격대로라면 분당 200번 이상 키를 두드리는 사람은 더블 푸시를 하지 않기 위해 기다려야 한다는 뜻이다. 분당 200번이면 대략 150타 정도 되는데 이 속도를 넘어서지 말아야 더블 푸시 전략이 제대로 먹힌다. 이래서는 고속의 타이핑에 쓸 수 없는 자판이 되고 만다. 숙달된 사람은 아무 생각없이 두들길 수 있어야 하며 현재로서는 별도의 키를 두는 수밖에 없다.

한가지 다른 대안은 글자의 배분이 잘못된 경우는 잘 쓰지 않는 문자들이므로 입력기가 맞춤법 검사기나 단어에 대한 DB를 보유하여 알아서 적당한 단어로 바꿔 주는 방법이 있다. �┰�, ��굼치, 늑김, 업씁니다 등은 누가 봐도 틀린 단어이므로 컴퓨터가 수정할 수 있다. 입력기가 좀 바빠지기는 하지만 컴퓨터의 연산능력을 충분히 활용할 수 있다는 면에서 고려해 볼만한 기능이다. 사실, 이 기능은 상용 워드 프로세서에 맞춤법 자동 검사 기능으로 이미 구현되어 있다.

연타로 경음을 입력하는 방법이 가능한 자판도 있다. 3벌식은 초성과 종성이 구분되므로 연타에 의해 애매한 문제가 없어 참 부럽다. 연타 된소리는 결국 채택하지 않기로 하되 속도가 느린 초보자들은 쓸 수도 있으므로 옵션으로 남겨 두기로 한다. 이 실험의 의미는 2벌식에서 연타 된소리 기능에 문제가 있다는 것을 확인했고 더 이상 미련이 없다는 것을 확실히 하는 것이다. 자판 배치외에 다음 코드 작업을 했다.

■ 자판의 역사에 대한 자료 수집. 과거를 알아야 미래를 설계할 수 있다는 생각에서 이전의 자판들에 어떤 것들이 있는지 조사해 보았다. 내가 알고 있는 상식과 크게 틀리지 않았다.

■ 자판에 설명을 달고 선택 대화상자에서 설명을 보임. 차후 손가락별 부담율, 좌우 부담율, 연타율 등의 좀 더 상세한 정보도 포함시킬 예정이다.

■ 권장 자판인 경우와 그렇지 않은 경우를 구분하고 시작할 때는 권장 자판으로만 설정한다. 비권장 자판은 어디까지나 연구용이므로 사용자들은 테스트를 해 볼 수는 있되 이 자판으로 연습을 해서는 안된다.

■ 영문 통계의 Shift 회수와 비율 계산, 대문자는 영문에서만의 비율이지만 Shift 비율은 전체 텍스트에 대한 비율이라는 점에서 대문자 비율과는 틀리다. 일반적으로 대문자 비율보다 Shift 비율이 더 낮게 나오며 대문자가 연속되는 경우에는 Caps Lock을 쓸 것이므로 실제로는 더 낮게 잡아야 한다. 대략 3~4% 정도 된다.

07년 8월 28일

어제 된소리 연타 연구에 진을 빼고 오후에 잠이 들어 새벽에 일어났다. 일어 나자 마자 자판 배치부터 바꿨다. 어저 자판은 별로 마음에 들지 않았는데 바꾸고 난 후에는 한결 더 마음에 든다.

■ Shift를 아래쪽으로 옮겼다. 저번에 Mode, BS를 없앴던 이유와 동일한데 너무 좋은 자리에 기능키를 배치해 뒀더니 2벌식 칠 때의 버릇이 남아 자꾸 쓸데없이 Shift를 누른다. 또 ㅁ,ㅂ의 자리가 안 좋아 원래 자리를 찾아 주기 위해 Shift가 자리를 양보했다. 영문에서 Shift 비율이 3% 정도밖에 안되고 그것도 소프트웨어의 자동화 기능 도움을 받을 수 있으므로 내려도 큰 문제는 없을 듯 싶다. 솔직히 이제 영문 눈치 보는게 질렸다. 내가 한국 사람이니 일단 한타가 편해야지 영문을 너무 고려할 필요는 없다.

■ Shift가 빠진 자리에 ㅁ을 옮기고 ㅁ이 빠진 자리에 ㅂ을 가져다 놓았다. 이 두가지만 해도 2벌식과 같아져 훨씬 더 쉬워졌다. 그리고 ㅂ이 있던 자리에 ㅆ을 일단 배치하고 동화책 한권을 다 타이프해 보았다. 대략 70타 정도 나오는데 그럭 저럭 괜찮은 것 같다.

■ 직접 타이프해 본 결과 ㅆ이 있는 X자리가 마음에 안들고 오른쪽에 떼어 놓은 ㅌ,ㅊ,ㅍ이 영 불편하다. 그래서 ㅎ위의 ?를 몰아내고 ㅋ,ㅍ을 왼쪽에 배치했다. 이 상태에서 ㅊ과 ㅆ을 바꿔 보기로 했다. ㅆ을 오른쪽으로 옮기기로 한 결정적 이유는 "있습니다", "했습니다" 같이 ㅆ이 받침에 들어가는 단어가 많아 좌우 연타율이 높아지기 때문이다. "있습"의 경우 좌우좌좌우좌 순인데 ㅆ을 옮기면 좌우우좌우좌 가 되어 균형이 좀 맞다. 그런데 이렇게 했더니 오른손 약지의 연타율이 높아져 다시 ㅆ과 ㅌ을 바꿨다. 통계치는 다음과 같다.

배치	통계
ㅆ(X), ㅊ(.), ㅌ(/)	좌우=46.59:53.41 손연타:30.6 손가락 연타:7.25
ㅊ(X), ㅆ(.), ㅌ(/)	좌우=46.56:53.44 손연타:29.9 손가락 연타:7.42
ㅊ(X), ㅌ(.), ㅆ(/)	좌우=46.59:53.41 손연타:29.9 손가락 연타:7.19

수치상으로는 그다지 큰 변화가 없지만 실제로 타이프를 해 보면 "있습니다"를 칠 때 훨씬 더 리듬감이 있고 부드럽다. ㅆ이 너무 변두리로 몰린 것 같지만 어차피 오른쪽에 두 칸이 남으므로 이 자리를 놀릴 수는 없는 셈이다. 그리고 오른손에 조금 더 부담을 옮기는 것이 합리적이므로 처음 보기가 이상해 보이더라도 일단 이 자리로 옮기기로 한다. 그외 한글 자모가 재배치됨에 따라 기호들의 위치도 조금 바뀌었다.

여기까지 작업한 결과를 보면 다시 2벌식과 비슷해졌다. 좌상단은 완전히 같은데 일부러 마춘 것이 아니라 통계에 따라 배치하다 보니 이런 결과가 나온 것이다. 그러고 보면 2벌식 자판도 꽤 잘 만든 자판이다. 가장 빈도가 높은 ㅇ과 ㅏ가 집게가 아닌 중지에 배치되어 있는 점이 조금 의아한데 이는 집게 손가락이 바로 옆의 ㅎ,ㅅ과 ㅗ,ㅛ까지 커버해야 하므로 부담이 너무 커서 그런 것 같다. 자리를 옮기는 손가락보다는 고정된 중지가 더 낫다고 판단한 것 같으며 상당히 합리적이다. 키 배치외에 자잘한 코드 작업을 몇가지 더 했다.

■ 키 배치 단위를 픽셀로 변경하고 임의의 위치에 배치할 수 있는 구조를 만듬. 스페이스와 Mode키를 전용 키보드의 예상 위치에 제대로 배치할 수 있게 되었고 커서 이동키도 조금 더 커졌다. 기능키 색깔을 회색으로 바꾸었더니 모양이 좀 이상해졌다.

■ 키보드에 여러 가지 통계 정보를 포함시켜 대화상자에 출력한다. 키보드 목록도 리스트 박스가 아닌 리스트 뷰로 바꿔 훨씬 더 보기 좋아졌다.

■ 단어, 문장 연습에 레벨 조정 기능을 만들고 Enter키 누를 시 재입력받도록 했다. 이전에는 Enter를 누르면 이상한 악보 모양이 찍혔었다.

■ 두더지 게임의 알고리즘 다수 수정. 레벨에 따라 동시 등장 가능한 두더지 개수를 조정하여 처음부터 너무 많이 나오지 않도록 했으며 하나도 없으면 바로 나오도록 하여 심심하지 않게 했다. 그리고 색상을 재조정하고 두더지의 이동 거리도 단어를 입력할만큼 충분한 시간을 주었다. 비트맵을 좀 예쁘게 만들었으면 싶기는 한데 예나 지금이나 디자인 실력이 꽝이라서 그냥 대충 두기로 했다.

07년 8월 29일

어제 오전에 도서관에 갔다가 문득 Shift키를 한글에서 사용하지 않으니 임시 기능키 전환용으로 쓸 수 있겠다 싶었다. Shift를 누른 채로 문자키를 누르면 커서 이동, 삭제 등을 하다가 Shift를 놓으면 원래 모드로 돌아오는 것이다. 전에도 Upper를 누른 채로 Space를 누를 때 Enter 입력으로 가정하는 코드를 짜 본적이 있는데 이 기능은 사실 문제가 있었다. 빨리 치다 보면 Upper와 Space를 뜻하지 않게 동시에 누르는 경우가 있었다. 그러나 Shift는 한글에서 전혀 쓰지 않는 키이므로 그럴 위험이 없다.

이게 가능해지면 커서 이동키를 따로 둘 필요가 없으므로 키도 줄어들고 그야말로 제자리에서 자판만 두들길 수 있다. 그래서 곧장 코드를 한바탕 뒤집어 엎었다. 간단해 보이지만 보기보다 훨씬 더 복잡하다. 왜냐하면 Shift를 누르고 있는 상태와 누른 것이 달라져야 하므로 Shift 처리를 KEYDOWN에서 처리하지 못하고 KEYUP에서 처리해야 하기 때문이다. 또 Shift 누른 채로 얌전히 그냥 놓았는지, 뭔가 다른 키를 눌렀는지도 판별해야 하고 Shift를 누르고 있을 때 기능키 목록도 화면에 출력해야 한다. 화면 출력은 1초 후에 타이머를 걸어서 하는 것으로 해결했다. 어차피 숙달되면 키보드는 안 보므로 좀 기다렸다 보여줘도 된다.

굉장히 조건이 복잡하지만 어쨌든 구현에는 성공했고 그럭 저럭 쓸만한 것 같았다. 문제는 Shift가 왼쪽에 있기 때문에 기능키를 오른쪽에만 둘 수 있다는 점이다. 왼쪽도 Upper와 함께 누르는 방안을 생각해 봤으나 과거의 경험상 좋지 않다는 것을 알고 있으므로 관 두기로 했다. Shift와 커서 이동, PgUp, PgDn만 해도 상당히 유용성은 있다.

커서 이동키가 문자키로 들어 왔으므로 나머지 기능키를 넣을 공간이 부족해졌다. 그래서 두 개의 기능 페이지를 만들고 Fun키로 3toggle해 보기도 하고 Fun, Edit 키를 따로 두는 방안도 모색해 봤으며 심지어 Fun을 아예 제거하고 Upper*Space로 3toggle하는 것도 고려했다. 그러나 너무 복잡해지는 것 같아 Fun키는 꼭 필요하다고 결론 지었다. 그때 왜 Fun 모드에서도 Upper를 쓸 수 있다는 생각이 들었다. 과거에 무슨 이유로 Upper키를 쓰지 않았었는데 아마 영문자가 모든 키에 할당되지 않아 Upper가 영문 선택에 사용되어야 한다고 생각했기 때문인 것 같다. 그러나 지금 생각해 보면 영문과 기능은 분명히 다른 모드이므로 Fun 모드에서 각 키당 두개씩의 키를 할당해도 상관없다.

그래서 또 한 바탕 뒤집어 엎었다. KeyMap을 확 까뒤집어 두 개씩의 가상키를 할당하고 Upper키로 위쪽의 키를 누르도록 했다. 아직 정확하게 모르겠지만 좀 불편하기는 해도 가능한 얘기인 것 같다. 여기까지 만든 후 테스트해 보니 일단 마음에 든다. 그런데 Fun키가 하는 일이 너무 적고 Shift에게 부담이 많이 가 있는 상황이라 동시에 누르는 것을 Shift가 아닌 Fun으로 바꾸는게 좋을 것 같았다. 그래서 또 엎었다. 마지막으로 Fun을 별도의 모드로 구분하지 않고 Mode 변수로 기억했다. 기존에 한, 영, 수와 별도로 다루었던 기능 모드를 합친 것이다.

enum eMode { HAN,ENG,NUM, FUN };

요렇게 되었다. 깔끔해 보이지만 여기에도 문제가 있는데 각 모드 사이를 어떻게 편리하게 네비게이션 할 것이냐는 것이다. 주로 한, 영을 위주로 쓰므로 이 둘을 토글하고 나머지는 Fun, Mode키로 잠시만 바꿔서 쓸 수 있도록 하는 것이 좋다. 현재 구현된 모드 변환 방법은 다음과 같다.

숫자에서 기능으로 전환하고 다시 돌아올 수도 있다. 그러나 현재 기능에서 숫자로 바로 가는 방법은 따로 없는 것 같다. 하도 복잡해서 나도 잘 모르겠다. 기획은 이렇지만 이대로 다 구현되는 것도 아니다. Upper가 제대로 잘 돌아오지도 않고 특정 상황에서는 동작이 좀 불안정하다. 삽집을 그렇게 해 댔건만 코드가 그다지 마음에 들지 않는다. 코드 정리를 한 판 해야 하며 디버깅도 꽤 많이 해야 할 것 같다. 현재 자판 모양은 다음과 같다.

Shift가 잠시 A 자리로 올랐다가 다시 내려왔으며 Mode가 Space 옆에 그려졌다. 그리고 커서 이동키가 일단 사라졌다. Fun 키와 같이 누르는 방식으로 커서를 이동시킬 생각이다. 기능키 자리에는 왠만한 키는 다 넣고도 아직 Upper위치에 자리가 남아 있다. 기능키 구현을 위해 키배치는 또 우선 순위가 밀려 버렸다. 오전 작업은 여기까지고 오후에는 키를 좀 더 조정해 볼 생각이다.

오후에 지속적으로 테스트 및 수정을 반복하여 키 배치를 일단락 지었다. 기존 배치도 통계를 바탕으로 했고 충분하지는 않지만 계속 검증을 해 왔으므로 약간씩만 수정했다.

■ Enter키를 결국 Space 오른쪽으로 옮겼다. 이로써 양쪽 엄지 손가락이 두 개씩의 키를 담당하는데 다른 손가락들에 비해서는 그래도 부담이 없고 좌우로 옮겨가며 치는 것이 그리 어렵지는 않으리라 생각된다. Enter 대신 빈도가 더 높은 BS를 넣을까도 고민했지만 BS는 숙달되면 그다지 필요치 않다는 점을 감안하여 키를 배치하지 않았다. Upper + Space는 BS이고 Upper + Enter는 Del이다.

■ Fun도 마찬가지로 Mode 옆으로 이사했다. Fun이 비킨 자리에 Ctrl을 두어 Ctrl과 Alt가 양쪽 모서리에 자리한다.

■ Enter가 비틴 자리에 ㅔ를 배치하고 ㅔ자리에 ㅊ을 데려오고 ㅊ자리에 ㅍ을 옮기고 ㅋ은 ㅅ위로 옮겼다. 자리 하나가 비면서 약간씩 이사를 했다.

■ 기호들은 12개를 포함하고 있는데 모두 문장 편집시 자주 사용하는 구두점이다. 그외의 구두점은 숫자 모드에 배치한다.

다음은 영문 자판 배치도이다. 그간의 배치를 완전히 무시하고 다시 배치했다.

웹 사이트에 공개된 공식 영문 통계를 바탕으로 배치했는데 빈도만 참조했을 뿐 연타율이나 좌우 분담률 등은 별로 고려하지 못했다. 직접 쳐 보고 배치를 요리 조리 바꿔 봐야 되는데 영문을 칠 일도 없고 영문 텍스트를 구하는 것도 귀찮아 대충 배치해 놨다. 키 22개가 있으므로 잘 안쓰는 4개만 Upper위치에 배치했다. 구두점들은 한글과 일치시켰다.

숫자 자판도 비교적 단순하며 전에 배치한 것과 크게 틀리지 않다. 한, 영 모드에 들어간 구두점 중 마침표와 쉼표는 중복 배치했는데 숫자 입력시에도 이 두 개가 자주 사용되기 때문이다. 남은 기호들은 오른쪽과 숫자의 Upper 위치에 적당히 골고루 배치했다.

숫자 0이 안보이는데 스페이스 자리에 숨어 있다. 차후 출력 루틴을 조금 수정하여 Space 대신 0이라고 분명히 표시해야겠지만 왠만하면 알아서 찾을 수 있을 것 같아 그냥 내버려 뒀다. 0을 이 자리에 배치한 이유는 컴퓨터의 키패드 구조와 맞추기 위해서이다. 3옆의 빈 자리도 있지만 0의 입력 횟수가 다른 숫자보다 월등히 많으므로 좀 더 입력하기 편한 곳에 두는 것이 더 나을 것 같다.

기능키는 오른쪽에 주로 편집 관련 기능을 넣고 왼쪽에 펑션키와 잘 안쓰는 기타키들을 배치했다. 오른쪽에 더 중점을 둔 이유는 Fun키를 왼손으로 누르므로 오른쪽에 있는 키가 더 접근하기 쉽기 때문이다. PC 상의 모든 키가 다 배치되었으며 아직도 남는 칸이 좀 있다. 그러나 Upper 자리에 있는 것들은 여전히 누르기 쉽지 않을 듯 하다.

키 배치를 하면서 간간히 보이는 버그도 같이 수정했는데 몇번씩 소스 정리를 했지만 아직도 코드가 그리 깔끔하지 못하다. 왜 그런가 하면 설계없이 덮어 놓고 개발부터 먼저 했기 때문이다. 그래서 도중에 완전히 바꾼 경우도 있고 애써 만든 코드가 폐기되기도 했다. 개발 방법론상 좋지 않은 방법인데 원칙대로 하자면 완전한 설계를 마친 후 코드를 짜야 한다. 그러나 이런 프로젝트는 짜 보지 않고서는 어떤 문제점이 있는지 알 수 없으므로 원칙대로 하다가는 얼마가 걸릴지 예측할 수 없다.

비록 구조가 그다지 좋지는 않지만 그래도 원하는 기능 대부분이 일단 구현되었고 어떤 문제점들이 있는지도 파악하고 있으므로 이런 프로젝트는 덮어 놓고 짜보기 전략이 더 좋다고 생각한다. 설계는 지금부터 다시 해야 한다. 한동안은 키 배치를 바꾼다거나 기능을 수정하는 일은 없을 것이다. 소스를 관리하고 지속적으로 사용해 보면서 문제가 있으면 기획서에 설계만 해 나갈 예정이다. 개인적인 일정상 이 작업을 너무 오래 할 수 없는 이유도 있지만 적당히 묵혀둘 필요도 있다. 하루, 이틀 정도 문서 작업과 코드 정리 작업을 한 후 다른 작업으로 전환할 예정이다. 16일동안 정말 신나게 코딩했다.

07년 8월 30일

당분간 자판에 손 안델려고 했는데 또 바뀌었다. 가만히 생각해 보니 한글 모드에 굳이 Shift키가 있어야 할 이유가 없다. 그래서 한글 모드에서는 없애 버리고 영문 모드에만 두었다. 대신 자리는 좀 좋은 곳에 배치해 주었다.

새로 생긴 빈칸에 어떤 문자를 배치할까 고민하다가 결국 ㅋ을 아래로 내렸으며 이로써 된소리를 제외한 모든 문자가 아래에 위치한다. ㅋ보다 빈도상으로 더 우선인 글자도 있다. 가장 고민했던 두 후보는 ㅕ와 머침표였다. ㅋ은 0.2% 빈도인데 비해 ㅕ는 1.4%이고 마침표는 1.3% 여서 훨씬 더 자주 나온다.

그러나 ㅕ는 ㅓ를 두번 누르는 것도 그리 나쁘지 않다고 생각하며 마침표도 영문과 일치시키는 것이 더 좋다고 생각했다. 한글 사이에 마침표가 들아거면 왠지 이물질이 낀 느낌이 들어서 거부감이 생긴다. 물론 워낙 빈도차가 심해 나중에 또 바뀔지 모르겠다. 오른쪽의 ㅆ자리도 약건 수정했는데 ㅣ,ㅐ와 손가락 위치가 틀려 연타 걱정이 없고 구석보다는 더 치기 쉽다. 기호들의 위치도 조금 바뀌었다.

영문 자판에는 Shift 대신 Capital이라는 키가 들아갔다. 이 키가 PC의 Shift키에 해당하는 키이되 영문에만 나타난다는 점이 다르며 더블 푸시에 의해 Caps Lock키의 기능도 겸한다. 사실 Caps Lock 자체는 거의 필요가 없는 키이다. 억지로라도 예를 들자면 전부 대문자이되 가끔 소문자가 나올 때나 필요하다. 그래서 기능 모드에 Caps Lock을 일단 두기는 하되 Upper 위치에 배치했다.

Shift가 없어지고 Capital이 생겼지만 또 다른 Shift키가 필요해졌다. 문자 입력에는 Shift가 필요없지만 기능키 조합에 필요하기 때문이다. Shift+F3이나 Shift+커서 이동키 등이 종종 사용되는 키인데 이런 키의 입력을 위해서는 별도의 조합키가 하나 더 필요하다. 그래서 Shift를 따로 두되 Ctrl, Alt와 함께 가운데 배치했다. 가운데 있다는 것은 이 키가 꼭 필요한 것은 아니라는 뜻이며 원한다면 없앨 수도 있다는 뜻이다. 기능키 모드에도 세 개의 조합키가 Z,X,C 자리에 중복되어 있다.

원한다면 키 자체에는 조합키를 없애 버리고 기능 모드에서 이 키들을 누르면 된다. 물론 이렇게 하면 열라 불편할 것이다. 그래서 왠만하면 조합키도 둘 수 있도록 했다. 이 외에 다음 작업들을 했다.

■ 숫자 대기 시간 0.5초로 감소

■ 상태란 정리

■ 마우스로 버튼 누를 때 KEYUP도 보내기

■ 아이콘 제작. 대충 만들었다.

■ 홈 페이지에 연결

오늘 작업 기록을 한손 자판으로 입력해 봤는데 영문, 기호가 웬만큼 섞여 있어도 칠만하다. 특히 잠시 모드를 바꿀 수 있는 기능이 아주 편한 것 같다. 속도가 좀 안나오지만 기능상의 문제는 없는 것 같다.

아직 키 배치가 완전히 완료된 것은 아니지만 그래도 일단락을 지을 필요는 있다. 그래서 지금까지 만든 자판 중 배치가 좋고 앞으로도 고려할만한 것들을 옵션으로 모두 포함시켰다. 다음은 두손 25키와 한손 17키이다. 이들은 권장 키 배치는 아니지만 여전히 고려대상이고 앞으로의 연구에도 지속적으로 필요할 것 같아 프로그램에 아예 내장시켰다.

이제 연구가 완료되었다고 치고 전체적인 구성을 기획해 본다. 이 상태로 출시한다면 영타 때문에 아무도 쓰지 않을 것이다. 초기 제품은 어쩔 수 없이 기존 제품과 호환되어야 한다. 제품으로 만들 경우를 위해 몇가지 변형된 형태를 미리 구상해 두었다.

28키 : 가장 간단한 형태는 현재 권장 배치인 31키에서 Ctrl, Alt, Shift를 뺀 28키 형태이다. 타블렛 PC나 UMPC 정도에서는 가급적 부피를 줄여야 하므로 이 형태가 사용될 가능성도 있다. 이론상의 키보드일 뿐 대중화를 위해서라면 채택할 수 없는 구조이다.

31키 : 권장 배치 그대로이다. 문자 입력은 모두 가능하며 기능키도 왠만큼 쓸 수 있지만 한영수 전환이 잦고 단축키를 자주 눌러야 하는 프로그래밍 환경에서는 조금 버겁다. 내가 최종적으로 바라는 키보드이지만 노트북 정도만 해도 이보다는 공간이 더 많으므로 적당히 키를 더 추가할 수 있을 것이다. 31키는 타블렛 PC 정도에 적합하며 액정 양쪽으로 나누어 배치할 수도 있다.

Ctrl, Alt, Shift는 적당히 빈 곳에 배치하면 된다. 손가락의 폭이 있어 액정의 폭이 제약을 좀 받는 편인데 그래도 키보드가 없는 것보다는 훨씬 더 나아 보인다. 키보드 아래위의 남는 공간에도 터치 패드나 여러 가지 키를 배치하여 활용할 수 있다.

중간에 생략된 TY,GH,BN 문자키를 추가하고 영문은 QWERTY 그대로 배치한다. 이 키들은 한글에서는 미사용이며 영문에서만 사용한다. 한타의 손가락 배치는 그대로 유지할 수 있으므로 추가된 키들이 별 방해가 되지는 않으며 양손의 간격을 적당히 벌리는 역할만 한다. 31권장키에서 이 구조로는 쉽게 변형할 수 있다. 소형 기기에는 적합하지 않으며 노트북 정도에서는 이 정도 배치가 가능할 것이다. 영문을 위해서는 이 배치도 바람직하다. 이 수준의 배치에서는 A 자리의 Capital 키를 빼야 하며 영문 모드에서의 Upper도 잠시 들어내야 한다. 물론 이 경우에도 31키의 영문 모드를 사용할 수 있으며 디바이스 드라이버에 영문 입력 방법을 선택하는 옵션이 있어야 한다.

펑션키, Esc, Tab 키들을 더 추가한다. 그리고 숫자키와 -=[];'/ 까지의 기호키들도 포함시킨다. 이렇게 되면 거의 기존 키보드의 구성 요소들을 모두 가진다. 위쪽으로 2행이 두 추가되어 키 수가 대폭 늘어나지만 확실히 편의성은 증가한다. 노트북 정도의 공간 여유가 있다면 이 수준까지 확장해 봄직하다. 커서 이동키만 빼도 면적은 그리 많이 증가하지 않을 것이다.

커서 이동키와 PgUp, PgDn, Home, End, Ins, Del, BS 등의 편집키 11개는 따로 배치할 수 있다. 이 경우 키가 늘어나는 것이므로 프로그램은 따로 수정할 필요가 거의 없다. 추가된 키들을 키 배열에 넣어 주기만 하면 된다. 31키 내에 이미 들어간 중복된 키 기능은 그대로 유지해도 별 상관없으며 오히려 편집중에 손가락을 옮기지 않아도 되므로 두는 편이 낫다. 이 키들의 추가 위치는 기기에 따라 달라질 수 있다. 이 수준까지 확장되면 Fun키는 사실상 필요가 없어진다. 오른쪽에 별도의 공간이 필요해지므로 데스크 탑 키보드가 아닌 한은 바람직하지 않다.

마지막으로 기존 키보드의 거의 모든 키를 그대로 다 가진다. 여기에는 양쪽에 두 개씩 있는 Ctrl, Alt, Shift 키도 포함되고 Caps Lock, 한글, 한자, Win, Menu 등도 포함된다. 그러나 우측의 넘패드까지는 필요치 않다. 넘패드 자체를 많이 사용하지 않으며 31 권장키의 숫자 모드가 넘패드와 동일한 배치를 가지므로 필요하다면 숫자 모드를 사용하면 된다.

권장 31키는 기능상의 문제는 없지만 초반 보급기에는 거부감이 심하다. 특히 한타는 몰라도 영타는 QWERTY에 너무 익숙해진 탓에 이 자판을 선뜻 사용할 생각이 들지 않는다. 그래서 자판의 기능은 그대로 유지한 채 정당히 확장해야 한다. 만약 초기 제품을 만든다면 키 배치는 아마 다음과 같아질 것이다. 넘패드와 요즘 새로 추가된 Win, Menu 등과 한글, 한자 키, 노트북별로 있는 Fn 키 들은 일단 제외했지만 필요하다면 언제든지 추가할 수 있다.

기존 키보드의 배치를 거의 그대로 가지고 스페이스 오른쪽에 Enter키를 하나 더 가지며 Mode, Fun키는 추가되는 것이다. Enter는 기존 Enter키와 동일한 스캔 코드를 가지면 되므로 별 문제가 없고 Mode, Fun은 별도의 스캔 코드를 할당하거나 아니면 기존의 가상 키 코드를 사용하면 별 문제가 없을 것 같다. Mode키는 한글키와 가장 잘 어울리고 Fun키는 한자키와 가장 잘 어울리므로 이 두 키의 가상 키 코드를 활용하는 것이 적절할 것 같다. 둘다 VK_HANGUL, VK_HANJA 가상 키 코드가 정식으로 할당되어 있다.

왼쪽손의 키보드를 우상향으로 기울였는데 이는 기존의 키보드와는 다르다. 기존 키보드는 한 손가락의 키보드가 우하향으로 기울어 있는데 외 이렇게 되어 있는지 솔직히 이유를 모르겠다. 오른손은 손가락이 뻗는 방향으로 되어 있지만 왼쪽은 손가락 방향과 거꾸로 되어 있어 손가락 방향대로 기울였다. 그런데 이게 기존 키보드에 익숙한 사람들에게는 또 다른 걸림돌이 될 지도 모르겠다. 만약 그렇다면 기존 키보드와 같은 방향으로 기울이든지 아니면 기울임의 정도를 조금 약하게 만들어야 할 것 같다.

이 정도 키보드를 제작하는데는 사실 큰 문제가 없을 듯하다. 키보드 제작사를 찾아가 만들어 달라고 하면 만들어 줄 것 같다. 버튼 몇 개 추가하는 정도는 그리 어려운 일은 아닐 것이다. 문제는 이 키보드에 맞는 디바이스 드라이버를 만들어야 한다는 점이다. 내가 개발자이기는 하지만 디바이스 드라이버를 만들어 본 경험은 없고 관련 자료를 구하는 것도 쉽지 않을 것 같다. 하드웨어만큼이나 소프트웨어도 중요한데 지금은 그게 더 걱정된다.

07년 8월 30일

아직 이 자판에 대한 정식 명칭을 붙이지 않았는데 애초의 코드명인 한손 자판이라는 명칭은 분명히 맞지 않다. 그래서 생각해 놓은 이름이 두 개 있다. 첫번째는 손가락이 자기 자리를 벗어 나지 않는다는 의미의 제자리 자판인데 이름이 아주 직관적이어서 키보드 자체의 동작방식을 설명하기에 그만이다. 두번째는 '아너림'이라는 고유명칭인데 가운데 행의 키를 좌우로 교대로 칠 때 이런 단어가 나온다. 고유명사라 좋고 키배치 자체를 이름으로 쓸 수 있다는 것도 장점이다. 영문 자판을 쿼티라고 부르는 것과 같다.

한손 자판은 물론 한손이라는 이름을 그대로 계속 사용하기로 한다. 생각해 놓은 이름 둘 다 붙여서 '제자리 아너림'이라고 부르는 것도 괜찮을 것 같다. 제품이 되려면 이름도 아주 중요하다. 개인적으로 아너림이라는 이름이 아주 마음에 든다. 물론 이 이름을 계속 사용하려면 현재의 키 배치에서 중앙행에는 더 이상 변화가 없어야 한다. 아침에 자판 배치를 조금 바꾸었는데 한글과 숫자 배치를 조금 손 보았다.

■ ㅌ,ㅍ의 자리를 맛바꾸었다. ㅌ,ㅍ의 빈도는 그야말로 도토리 키재기이지만 그래도 꼭 비교를 하자면 ㅌ이 조금 더(0.05%) 높다. 그래서 오른쪽 가장자리보다는 조금 더 치기 쉬운 왼쪽 약지 자리로 옮겼다. 이렇게 되면 왼쪽 아래의 ㅋ, ㅌ 자리도 2벌식과 같아져 처음 배울 때 조금 덜 헷갈린다. 일부러 맞추는 것도 아닌데 자꾸 2벌식과 닮아가는 것 같아 기분이 살짝 나빠질려고 한다.

■ 한글의 Upper 남는 자리에 기호들을 좀 더 초빙해 왔다. 가장 우선적으로 가져온 것은 ~인데 한글에서나 영문에서나 종종 많이 사용되는 문자이므로 모드 변환없이 입력할 수 있다면 편리할 것이다. 이왕 데려오는 김에 #, $, &도 오른쪽 아래로 데려왔다. 사실 이 문자들은 한글 환경에서는 거의 안 쓰이는 것인데 영문 환경에서는 가끔 필요하므로 가져온 것이다. 아직 두 개의 Upper 공간이 남이 있지만 마땅히 더 가져올 게 없어서 그냥 내버려 뒀다.

■ 몇 가지 기호가 한글 모드로 이사를 감으로써 숫자 모드의 배치도 변화가 생겼다. !, % 등 기존의 한글 모드에 있던 것들이 숫자 위에 중복 배치되었는데 두나 빼나 별 차이가 없으므로 모두 다 두기로 했다. 가장 큰 변화는 8위에 있던 *가 별도의 키를 차지했다는 점인데 왼쪽의 +-=과 마찬가지로 연산자이므로 숫자와 함께 신속하게 입력할 수 있어야 한다. 또 C 프로그래밍 환경에서 *기호가 굉장히 많이 사용된다는 것을 고려했다. 상대적으로 빈도가 낮은 |와 `는 8과 9위로 이동했다. 이로써 왼쪽의 Upper 위치는 텅 비고 오른쪽은 숫자 위쪽에만 기호들이 있어 모양이 단순해졌다. 그리고 @, ^ |, ` 외에는 모두 문자 모드에도 있어서 왠만해서는 Upper를 누를 필요가 없다.

■ 기능 모드에 한글키를 추가했다. 잘 쓰지 않고 이 자판에는 전혀 쓸모가 없지만 자리가 남아서 그냥 넣어둔 것이다. 그리고 빈도가 낮은 PrtSc도 Upper 위치로 옮기고 한칸은 비워 두었다. 빈 한칸은 다음에 유용하게 쓸 데가 있을 것 같다. 기능 모드를 좀 더 획기적으로 개선할 수 있는 방안에 대해서 고민중인데 마땅히 떠오르는 기가 막힌 방법이 없다. 현재 상태로는 쓰기가 너무 불편한데 뭔가 좋은 방법이 있지 않을까 계속 고민해 봐야겠다. 필요하다면 키를 하나 더 쓰는 한이 있더라도 말이다.

07년 9월 1일

■ Mode키의 동작 방식을 변경했다. 이전에는 Mode로 한영을 토글하고 Upper+Mode로 숫자로 전환했었는데 Upper를 누르는 것보다는 아무래도 더블 푸시가 더 편할 것 같다. 더블 푸시할 경우 일단 다른 모드로 바뀐 후 다시 숫자로 바뀌기 때문에 화면의 키보드 그림이 번쩍하는 부작용이 있기는 하지만 이는 연습 프로그램의 경우에만 그런 것이고 전용 키보드에서는 그런 문제가 없으므로 별 상관이 없다.

Mode를 처리하는 코드가 상당히 복잡해졌지만 변화의 효과는 긍정적인 것 같다. 숫자를 쓰려면 단순히 Mode를 더블 푸시하거나 아니면 Mode를 누른 채 입력하면 원래 모드로 잘 돌아간다. 하지만 아직까지도 4개의 모드를 전환하는 방식이 여전히 비직관적이고 특히 숫자와 기능 사이의 전환이 다소 복잡하다. 이상적인 모드 변환을 하려면 하나의 키가 더 필요할 것 같다. 언어간 토글하는 L, 숫자로 변환하는 N, 기능으로 변환하는 F가 있으면 명쾌하다.

한글과 영어를 합쳐서 언어라는 상태로 보고 이 내부에서는 L키로 왔다리 갔다리 한다. 숫자나 기호로 바꿀 때는 N,F 별도의 키가 있으므로 헷갈릴 위험이 없고 깔끔하다. 그러나 키 하나를 더 만든다는 것이 부담스럽고 새로 만든 키를 어떤 손가락에 할당할 지가 애매하다. 왼손 엄지 손가락이 세 개의 키를 담당한다는 것은 확실히 부담스러울 것이다. 그래서 또 이런 생각도 해 보았다. 손가락 하나로 세 개의 버튼을 누를 수 있는 좌우 이동 버튼을 만들면 된다.

버튼 중앙에는 홈이 파져 있어 이 홈에 왼손 엄지를 놓고 누르거나 좌우로 당기면 된다. 다른 손가락과는 달리 엄지 손가락은 키보드에 수직이 아니기 때문에 당기거나 미는 동작도 어렵지 않게 수행할 수 있어 버튼만 잘 만들면 충분히 가능할 것 같다. 민 채로 잠시 다른 키를 입력하고 다시 놓아 버리면 되므로 임시 전환에도 좋다. 그러나 이는 별도의 하드웨어를 만들어야 한다는 점에서 부담스럽고 기존 키보드와도 맞지 않아 실행에 옮기기는 어렵다. 다음에 시도해 볼 생각이다.

엄지 손가락이 맡을 수 있는 키의 최대 개수가 고작 두 개 정도뿐이므로 지금은 두 개의 키만 가지고 어떻게 잘 조합해 볼 수밖에 없다. 뭔가 쌈박한 아이디어가 더 나올 수 있지 않을까 계속 고민중이다.

■ 키보드 숨기기 옵션을 만들었다. 실제 사용해 보니 아래쪽의 키보드 그림을 자꾸 쳐다 보는 습관이 생겨 타이핑 실력이 늘지 않는다. 조금만 익숙해지면 키보드 배치를 다 외우게 되고 실제로 전용 키보드를 사용한다면 키보드 배치도 따위는 필요치 않으므로 키보드 영역을 빼고 편집 영역을 더 크게 볼 수 있는 옵션이 필요하다. 옵션 추가하고 약간의 코드만 수정하면 되므로 어렵지 않게 이 옵션을 추가했으며 단축키 F9도 부여했다.

■ ApiEdit의 기능을 대폭 보강했다. ApiEdit 자체는 완벽한 편집 컨트롤이지만 한손 프로그램은 이 컨트롤을 고작 출력 용도로만 사용한다. 애초에는 입력 테스트만 하면 된다고 생각했으나 프로그램의 기능이 하나 둘씩 완성되면서 이제 편집도 어느 정도 가능했으면 한다. 그래서 마우스로 캐럿을 옮기는 것과 선택 블록을 감싸는 것, 팝업 메뉴를 통한 클립보드 액션 등을 더 추가했다. 휠 마우스도 지원하며 블록을 드래그하여 옮기거나 복사할 수도 있다. 사실 추가한 게 아니고 원래 있던 기능을 사용 가능하게 풀어 놓기만 한 것이다.

그런데 막아 놨던 기능을 풀어 놨더니 여기 저기서 말썽이 많이 생겼다. 일단 ApiEdit는 절대로 포커스를 받지 못하도록 설계되어 있다는 점이 문제다. 메인이 키 입력을 독점해야 하므로 포커스를 컨트롤에게 줄 수 없고 그렇다 보니 캐럿 관리도 전적으로 메인이 해야 한다. 또 휠 마우스 메시지도 직접 받지 못하므로 메인이 받아서 포워딩해 줘야 하고 여러 가지 문제가 많다. ApiEdit의 잘 만들어진 코드를 쓰지 못하고 어색하게 변형할 수밖에 없다.

또 버퍼가 두 개 존재한다는 것이 구조적인 문제점이다. 입력은 조합형으로 받고 출력은 완성형으로 해야 하므로 어쩔 도리가 없는 것이다. 운영체제가 보내주면 메시지만 고분 고분 받아서 처리하던 놈을 키배치가 완전히 다른 조합형을 입력받도록 해야 하니 문제가 많을 수밖에 없다. 그래도 이전에는 한손에서 ApiEdit로 정보가 일방적으로 가기만 했지만 클립보드 액션 등이 가능해져 이제는 반대 방향으로도 정보가 전달되어야 하며 이 과정에서 양쪽의 buf를 동기화하는 것이 무척이나 골치 아프다.

대충 짜보고 에러가 발생하는 부분을 디버깅하여 얼기 설기 꿰매 놓았는데 일단은 원하는대로 동작한다. 하지만 이 이상 더 기능을 확장하기는 어려울 듯하며 이 정도만 할 생각이다. 그나마 다행인 것은 이 컨트롤을 만든 놈이 바로 나 자신이라 원하는대로 뜯어 고칠 수 있다는 점인데 2년전에 만든 코드도 그럭 저럭 생각이 나서 작업에 별 어려움은 없다는 점이다. 다음은 키보드를 없애고 텍스트를 붙여 넣어서 블록 선택한 모습이다.

꼭 메모장처럼 생겨 먹었다. 키보드가 숨겨져도 동작하는데는 아무 문제가 없다.

■ 기능 모드의 키 배치를 또 한번 뒤집어 엎었다. 펑션키보다는 편집키 위주로 배치했는데 어차피 노트북 정도되는 기기라면 펑션키를 따로 만들 것이므로 펑션키에 좋은 자리를 줄 필요가 없다는 것을 고려했다. 펑션키는 모두 Upper위치로 옮겨 누르기 조금 어려워졌다.

Alt와 Shift의 자리를 바꿨는데 Ctrl과 Shift는 같이 누를 일이 많기 때문이다. Cut, Copy, Paste 같은 기능도 넣었는데 이 키들은 엄밀히 말하면 가상키가 아니다. 하지만 키보드중에 이 버튼들을 제공하는 것들이 있으므로 가상키는 없지만 이 키들을 처리하는 표준적인 방법들은 정의되어 있을 것으로 생각된다. 또 윈도우즈 메시지중에 WM_CUT, WM_COPY, WM_PASTE 같은 것들도 있으니 이 메시지만 보내주면 될 것이다.

현재는 ApiEdit로 매크로 명령을 보내 클립보드 동작을 지시할 수 있다. 그리고 기능키 실행 코드를 수정하여 이동키 입력시 단순 이동뿐만 아니라 Ctrl, Shift 조합키의 상태에 따라 블록 선택, 단어 단위 이동도 가능하게 해 두어 기능 상태에서 왠만한 편집이 가능해졌다.

■ 위 그림에서 보다시피 CAS 조합키가 결국은 빠졌다. 기능 모드의 Z, X, C 치기 쉬운 세 곳에 CAS가 별도로 배치되어 있으므로 이 키들이 키조합에 꼭 포함될 이유가 없어졌으며 실제 사용해 보니 편집할 때도 기능키에 배치된 CAS에 손이 가며 손가락을 옮겨가며 키보드의 CAS를 누르지는 않는다. 그래서 빼 버렸는데 실제로 이렇게 하면 무척 불편할 것이다. 어차피 이 자판은 최소 세트를 기획한 것이고 실제 적용할 때는 적당히 확장할 것을 고려하고 있으므로 기본 세트에서는 빼는 것도 좋을 것 같다.

이렇게 해야 완전한 제자리 자판이 되며 엄지 2개씩 그외 3개씩의 키가 공평하게 분배된다. 중앙 자리에 키가 빠짐으로써 훨씬 더 단순해 보이고 보기에도 좋다. 다음에 또 포함시킬 가능성도 전혀 없지는 않지만 일단은 빼기로 한다.

오후에는 별도의 프로젝트를 만들어 후킹에 대해 좀 더 연구해 보았다. 현재 수준에서 후킹 가능한 프로그램은 메모장 정도가 고작이며 그나마도 문자만 겨우 입력되는 정도라서 후킹이 가능하다는 것만 확인했다. 후킹에 완벽하게 되면 디바이스 드라이버를 깔지 않아도 자판을 변경할 수 있으므로 보급과 테스트에 더 유리할 것이다. 그러나 예상했다시피 후킹으로 모든 키입력을 대신하기에는 여러 가지 한계가 많다.

키 입력 사건은 후킹할 수 있지만 이 입력을 원하는대로 조작하여 목표 윈도우에 전달하기가 쉽지 않다. 가장 큰 문제는 조작 대상이 분리된 프로세스라는 것인데 메모리 영역을 마음대로 건드릴 수 없으므로 입력 컨텍스트를 얻는다거나 조립 문자열을 설정할 수 없다. 후킹 DLL이 대상 윈도우의 주소 공간에 들어가 있으므로 IPC를 잘 하면 어찌 될 것도 같기는 한데 그다지 쉽지는 않다. 또 다른 문제는 조합키의 상태를 얻는 GetKeyState 함수를 내가 원하는 방식대로 동작하도록 바꿔야 한다는 점이다. 그렇지 않으면 Ctrl+X 같은 조합키 입력을 전달할 방법이 없다.

만약 후킹이 여의치 않는다면 결국은 디바이스 드라이버를 만들어야 할 것이다. 그러나 내가 이 분야에 경험이 전혀 없기 때문에 꽤 많은 연구와 공부가 필요할 것 같다. 완벽한 키보드 제작은 디바이스 드라이브까지 만들어져야 가능하다. 후킹이 원하는대로 되지 않으므로 당분간 아너림 자판은 연습 프로그램과만 쓸 수 있는 테스트용 자판으로 남을 전망이다.

통계 산출을 위한 샘플 파일들을 좀 더 정비했다. 신문, 소설, 인터넷 등 다양한 형태의 텍스트를 수집하여 약 2M가 조금 넘는 샘플 파일들을 만들었는데 이후 글쇠 배치는 이 파일을 기준으로 할 예정이다. 어차피 샘플 바꿔 봐야 통계는 거의 대동소이하므로 이것 저것 보는 것보다 하나만 참조하는 것이 나을 것 같다. 통계 파일에 따옴표가 " 로 되어 있지 않고 좌우가 구분된 DBCS로 되어 있는데 모조리 "로 바꾸었다. 좌우 구분된 따옴표는 워드 프로세서의 기능이므로 자판이 이를 지원할 필요는 없다. 또 샘플 텍스트가 지나치게 개행되어 있어 Enter의 비율이 너무 높게 나올 것 같은데 차후 이 사실을 참조해야겠다.

영문 샘플도 1.7M 정도 크기로 준비했는데 구할 수 있는 텍스트의 종류가 다양하지 않아 eBook을 주로 수집했다. 그래서 대문자가 좀 많은 편이며 일반적으로 많이 쓰지 않는 알파벳도 빈도가 높게 나타날 수 있다. 소설은 해리포터 1권만 포함시켰는데 이 파일만 보면 이상하게 H와 R의 빈도가 높게 나타난다. 역시 샘플별로 빈도 편차가 심하다는 것을 알 수 있다. 다음에 영문 배치를 할 때는 좀 더 다양한 자료를 구하든지 아니면 미리 조사된 정보를 참조해야겠다.

자판 배치에 대해서도 조금 더 생각해 봤다. 현재 자판의 최대 불만 또는 다른 사람이 보기에 문제가 될만한 부분이 바로 격음들이 키 하나씩을 다 차지하고 있다는 점이다. ㅊ, ㅋ, ㅌ, ㅍ 이 네 개는 다 더해도 발생 빈도가 1.7% 안팎에 불과하다. 자주 사용하는 문자중에 이보다 더 빈도가 높은 것이 딱 두 개가 있는데 하나는 모음 ㅕ이고 하나는 마침표이다. ㅕ는 1.4%의 빈도를 보이며 마침표는 1.1%의 빈도를 보인다. 천번을 두드릴 때 겨우 2번 나오는 ㅋ에 키가 할당되어 있는데 14번이나 나오는 ㅕ에 키가 없다는 것은 빈도만으로 보면 분명히 잘못된 것이다. 그래서 키 배치를 다음과 같이 수정해 보았다.

ㅊ,ㅌ은 밑에 두고 ㅋ,ㅍ은 Upper자리로 올렸다. 이렇게 하여 생긴 더 키에 ㅕ와 마침표를 배치했다. 이렇게 배치하는 것이 빈도상 훨씬 더 유리하고 쓰기에도 좋다. 그러나 막상 이렇게 바꿔 놓고 테스트해 보니 아예 동작하지도 않는다. ㅕ가 동작하지 않는 이유는 코드에서 복모음으로만 인식하기 때문인데 코드표에 아예 ㅕ라는 글자가 없다. 마침표가 동작하지 않는 이유는 모든 기호는 Upper 위치에 있다고 가정하고 있기 때문이다.

물론 코드를 약간만 손 보면 이 배치가 가능해지기도 한다. 그러나 당분간 이 배치는 고려만 하고 사용은 하지 않을 생각이다. ㅕ에 키를 할당하기 싫은 이유는 ㅓ를 두번 누르는 것이 손가락을 약간 밑으로 내려서 한번 누르는 것에 비해 그다지 불편하지 않다는 것과 ㅕ에 키를 할당했으면 ㅑ도 대칭적으로 할당해야 하는 문제가 있기 때문이다. 그러나 ㅕ에 비해 ㅑ의 빈도는 월등히 낮아서 0.2% 정도밖에 안되며 자음중 ㅋ과 거의 비슷하고 ㅊ,ㅌ,ㅍ보다도 낮아 키를 줄 수 없다. ㅕ가 굉장히 많이 쓰이는 것 같지만 ㅐ, ㅔ보다는 조금 낮은 수준이라 ㅐ,ㅔ 까지만 키를 배치하는 것이 이상적인 것 같다.

마침표의 경우는 영문과의 일관성을 위해 배치하지 않는 것이 좋다. 영문은 안그래도 자리가 부족해 영문자 4개를 Upper에 배치해야 하는데 마침표에 한 자리를 내주면 V나 K 중 하나가 또 위로 올라가야 한다. 대신 마침표를 Upper 위치 중에는 제일 좋은 왼손 집게 손가락에 배치해 놨으니 위쪽에 올려 놔도 그리 불편할 것 같지는 않다. 결국 한글 배치는 오늘 오전에 작업한 28키 배치를 당분간 계속 유지할 것 같다.

07년 9월 2일

오늘은 줄곧 문서 작업만 했다. 일요일에는 늘상 마누라가 놀러가자고 바가지를 박박 긁기 때문에 일할 생각이 없었는데 색시가 아파서 놀러 가지 못했고 그래서 저녁 먹으로 잠시 나간 것 외에는 집에서 문서 작업을 할 수 있었다. 일단 도움말을 먼저 만들었다. 아직 완성되지도 않은 제품에 대해 메뉴얼을 먼저 만드는 이유는 최종 사용자 입장에서 제품을 바라볼 수 있는 기회가 되기 때문이다.

간단한 사용법과 특징 등을 기술했는데 하루 종일 두들겨서 겨우 14페이지짜리 문서 하나를 만들었다. 초안이기는 하지만 그래도 적을 게 14페이지밖에 안되는지 다소 실망스럽기도 하다. 차후 점점 더 친절하고 상세하게 내용을 보강하고 앞으로 늘어날 기능에 대해서도 더 쓰면 그래도 50페이지 정도는 될 것 같다.

도움말 외에도 소개 페이지와 작업 일지 자체도 정비중이며 한글 오토마타 강좌도 기획중이다. 다음은 작업을 시작한 후 얼마되지 않아서 기존에 만들어진 자판은 어떤 종류가 있는지 조사해 놓은 것인데 상세하지는 않지만 여기에 기록을 남긴다. 과거를 알아야 미래를 알 수 있다는 생각에 대해서는 변함이 없으므로 이 기록들도 소중하게 관리할 것이다.

■ 쿼티(Qwerty)

Christopher Sholes라는 사람이 1873년에 발명했다. 수동식 타자기에서 키를 타격하는 막대가 엉키지 않도록 자주 사용되는 글자를 최대한 분산시켰다. 의도적으로 빨리 치지 못하도록 만들었다는 속설도 있다. 고속 타이핑에는 적합하지 않은데 출현 빈도가 끝에서 3번째인 J가 가장 치기 쉬운 오른손 집게 손가락 자리를 차지하고 있는 것만 봐도 이 자판이 얼마나 엉망인가를 알 수 있다.

컴퓨터에서는 막대가 엉킬 경우가 전혀 없지만 한번 대중화된 이후로 아직도 표준의 자리를 지키고 있다. 컴퓨터 키보드의 스캔 코드가 쿼티 배열의 글쇠순으로 되어 있을 정도다. 재미있는 것은 이 자판의 키들이 왜 이런 식으로 배치되었는가에 대해서는 기록이 전혀 남아 있지 않다는 것인데 숄즈는 만들어만 놓고 관리를 안한 모양이다.

■ 드보락

드보락(워싱턴대 교수)에 의해 1932년에 발명되었다. 배치가 쿼티 자판에 비해서 상당히 다름은 물론이고 숫자나 기호의 배치도 꽤 많이 다르다.

자주 쓰는 글자들이 중앙행에 배치되어 있어 70% 정도가 중앙행에서 입력된다. 쿼티는 중앙행 비율이 30% 정도밖에 안되며 한글 2벌식은 60%, 3벌식은 55%이다. 쿼티 자판보다는 30% 가량 더 속도가 빠르고 피로도도 덜하지만 늦게 만들어진 관계로 여전히 쿼티 자판에 비해 보급률이 저조하다. 쿼티와 함께 복수 표준으로 지정되어 있지만 한국의 세벌씩보다도 더 무시당하는 처지다. 한번 정해진 표준을 바꾸는 것이 얼마나 힘든 일인지를 여실히 보여준다.

■ 3벌식

공병우 박사님이 1949년 수동식 타자기로 만들었다. 초,중,종성으로 구성되어 있으며 우에서 좌의 순서로 타이핑한다. 외우기 어렵지만 익숙해지면 2벌식보다 더 빠르며 피로도도 덜 하다. 최대 장점은 초성과 종성의 키가 따로 있기 때문에 모아 치기가 가능하다는 점이며 고도로 숙달되면 순차적으로 입력해야 하는 2벌식보다 2~3배 정도 더 빠르다. 2벌식으로는 도저히 흉내낼 수 없는 부러운 기능이다. 도깨비 불 현상이 생기지 않는다는 것도 장점으로 내세우기는 하나 어차피 화면을 보고 치는 사람이 별로 없기 때문에 그다지 중요한 장점은 아니라고 생각된다.

표준으로 채택되지는 못했지만 워드 프로세서와 운영체제에 의해 지원이 계속되며 매니아들이 꽤 많다. 그러나 이 매니아라는 작자들의 배타성이 만만치 않은데 삼벌식이라고 부르면 화를 내고 2벌식 때문에 우수한 문자인 한글이 죽었다는 말도 안되는 주장을 펼치기도 한다. 벌은 수를 세는 단위이므로 이, 삼이 아닌 두, 세로 읽어야 한다고 하는데 틀린 얘기는 아니지만 언어의 현실성을 무시한 것 같다. 그럼 왕복 4차선 도로는 네차선이라고 읽어야겠네.

단점도 많은데 우선 키가 많아 외우기가 상당히 어렵다. 또 4열 숫자 위치까지 키가 배열되어 있어 운지 거리가 길고 좌우 비율이 56:44로 왼손 부담이 크다. 공병우 박사가 만든 것을 1991년에 개량한 것이 3벌식 최종이며 1990년 박흥호씨가 만든 세벌씩 390 자판은 쿼티 자판과 기호를 유사하게 배치한 것이다. 또 1990년 안종호씨에 의해 쉬프트를 전혀 사용하지 않는 순아래 자판도 있고 2003년에 안마태 신부가 개발한 안마태 자판도 있다. 안마태 자판은 3열만 사용하며 된소리를 바로 옆의 키와 함께 친다는 면에서 독득하다.

■ 5벌식

김동훈씨가 1959년 만들었으며 수동식임에도 글자가 네모 반듯하게 나온다. 자음 2벌, 모음 2벌, 받침 1벌이 있다. 당시 3벌식과 함께 사용되었으나 현재는 거의 사용하는 사람이 없다. 속도보다는 글자의 모양에 중점을 두고 개발된 자판이다. 수동식에서는 벌을 늘여서라도 좋은 글자를 찍는 것이 의미가 있지만 전자식에서는 컴퓨터가 글꼴을 알아서 선택하므로 의미가 없다.

■ 4벌식

자음 한벌, 모음 2벌(받침 있는 것과 없는 것), 받침 1벌로 총 4벌로 구성되어 있다. 69년 국무총리령으로 수동식의 표준이 되었으나 지금은 사용하는 사람이 없다. 박물관에나 가야 볼 수 있다.

■ 2벌식

4벌식을 전자식으로 개량한 것이다. 1982년 과기처에 의해 표준이 되었으며 현재까지도 가장 많이 보급된 자판이다. 모음과 자음 두벌만 있으며 컴퓨터가 초성과 종성을 자동으로 구별한다. 세벌식 사용자들은 이 자판에 대해 무수한 비난을 퍼붓지만 막상 비교해 보면 그리 못 만든 자판은 아니다. 빈도에 따라 적절히 잘 배치되어 있으며 외우기 쉽고 피로도도 적당하다. 자판에 대한 연구를 하면 할수록 2벌식이 꽤 잘 만든 자판이라는 생각이 든다.

이외에도 변형 자판들이 많다. 한국 최초의 자판은 1900년대 초에 이원익씨가 만들었다. 최근에는 노트북이나 이동식 기기에서 ㅆ에 별도의 키를 부여하는 식으로 자판을 약간씩 변형한 것들도 발표되고 있으나 2벌식의 범주를 벗어나지는 못하고 있다. 다음은 북한의 자판이다.

2벌식이라는 점은 우리나라와 같지만 배치가 상당히 다르다.

07년 9월 3일

■ 아너림이라는 명칭을 공식적으로 사용하기 시작했다. 아직 배치가 확정된 것은 아니므로 이 글판이 아너림이 될지 아닐지는 정확하게 알 수 없지만 웬만해서는 바뀔 것 같지 않으므로 이름을 확정했다. 만약 배치가 바뀌어 아너림이 안된다면 아너릭이 될 것이다. 아너릭은 빈도가 가장 높은 자음 ㅇㄴㄹㄱ과 모음 ㅏㅓㅣ를 순서대로 합친 것이므로 빈도순으로 만든 글판이라는 의미를 가지게 된다. 배치가 고정되어 아너림이란 명칭을 계속 사용할 수 있었으면 좋겠다.

이름이 참 동글동글하게 예쁜 것 같으며 웹 검색 결과 지금까지 누구도 사용하지 않은 명칭이다. 영문으로 하면 Anerim이 되며 도메인도 비어 있는 상태이다. 이름이 결정되었으므로 문서들도 전부 다시 조정했다. 그동안 제자리 글판이라는 이름을 사용했는데 이제 공식 명칭을 그냥 사용해도 무방할 듯하다. 소개 페이지와 도움말 페이지에 아너림이라는 이름을 사용했다.

그리고 홈 페이지에 이 문서들을 일단 올리되 아직 변동 사항이 있을 수 있으므로 드러내 놓지는 않았다. 홈페이지 왼쪽 메뉴 아래쪽에 점 하나 찍어 놓고 이 점에 링크를 걸어 놓았는데 웬만한 모니터에서는 보이지 않는다. 마우스로 선택한 상태로 스크롤해야 겨우 보일 정도로 얍삽하게 숨겨 놓았으므로 당분간은 아무도 그 존재를 모를 것이다.

그런데 아무도 못볼 문서를 왜 올렸을까? 그건 누군가에게 이 글판을 보여 줄 방법은 있어야 하기 때문이며 미리 올려 놓으면 검색 엔진들이 텍스트를 가져갈 것이기 때문이다. 이름이 바뀌었으므로 실행 파일의 이름도 Anerim.exe로 바꿨다. 그리고 아이콘도 글쇠위에 '아'자 하나 그려 넣었는데 역시 촌스럽다. HanSon은 이제 코드명으로만 남을 전망이다.

■ 기존 PC 키보드로 테스트하는데는 아무래도 한계가 많아 전용 키보드가 필요하다. 그러나 비용이 막대하게 들 것 같아서 감히 엄두를 내지 못하다가 좋은 생각이 있어 저번주에 미니 키보드 두 개를 인터넷으로 주문했다. 이 키보드를 조금 뜯어 고치면 전용 키보드 비스무리한 것을 만들 수 있을 것 같다. 금요일 주문했는데 오늘 아침에 마침 도착해서 작업에 돌입했다. 그런데 같이 주문한 MP3는 왜 안 온걸까? 4년 넘게 사용한 256M의 MP3도 한번 갈아치울 때가 됐는데... 수술에 들어가기 전 모습은 다음과 같다.

넘패드가 굳이 필요치 않으므로 미니급으로 주문했는데 들고 다니기도 편할 것 같다. 가격도 7000원밖에 안해 어찌하다 고장나도 별로 아까울 것 같지도 않. 하나는 LG것이고 하나는 KAPA라는 것인데 둘 다 마데인치나(Made In China)이다. 하긴 차이나니까 저런 착한 가격에 만들수 있겠지. 둘 중 LG것이 터치감이 조금 더 좋은 것 같아 타겟으로 결정하고 바로 작업에 들어갔다. 뒤에 나사 12개를 풀었더니 철판이 하나 나왔다. 그 철판의 나사 4개를 더 푸니 완전히 해체되었다. 그런데 이럴 수가! 키보드가 이렇게 단순하게 생겼을 줄이야.

글쇠들은 모두 플라스틱이고 그냥 구멍에 끼워져 있을 뿐이다. 글쇠 바로 밑에는 얇은 비닐이 두겹 겹쳐져 있는데 이 비닐이 스위치 역할을 한다. 비닐의 배선만 바꾸면 키의 배치는 얼마든지 조작할 수 있을 것 같다. 전자 부품은 왼쪽 위에 보이는 조그만 기판이 전부이며 여기에 LED가 달려 있다. 하긴 하는 짓이 단순하니 더 이상 복잡하게 생길 이유도 없을 것이다. 아니 근데 이딴 걸 7000원이나 받아 먹다니 완전 도둑놈들이다.

일단 키를 죄다 다 뽑았다. 뒤쪽에서 드라이버로 쿡쿡 찌르기만 하면 다 튀어 나온다. 이빨을 다 뺀 후 내가 원하는 위치에 다시 끼웠다. Mode와 Fun키가 따로 없으니 위쪽으로 전부 한칸 올리고 숫자키는 완전히 빼버렸다. 그리고 Space와 Enter 대신 1과 2를 끼워 주고 Mode와 Fun 대신 3과 4를 끼워 주었다. 필요치 않은 키는 아예 끼우지도 않았다. 그리고 분해의 역순으로 다시 조립했다. 최종 결과는 다음과 같다.

왼쪽이 손가락 방향으로 기울어지지 않아 조금 불만이기는 하지만 원하는 전용 키보드와 비스무리한 모양이 나오기는 했다. 스페이스 자리와 Mode 자리에 좀 폭이 넓은 걸 끼우고 싶었으나 구멍이 중앙에 있어 큰 걸 끼울 수가 없는 구조이다. 딴건 몰라도 스페이스만 좀 더 컸으면 딱 좋겠는데 말이다. 완전히 마음에 드는 것은 아니지만 아뭏든 너를 아너림 키보드 1호로 임명한다.

조립후에 끼워서 테스트해 보았다. 이런 경우를 위해 한칸 올림 글판도 미리 만들어 두었던 것이다. USB 키보드라 그냥 끼우기만 하면 된다. 키보드 두개를 동시에 달아 놔도 아무 이상없으며 그럭 저럭 원하는대로 잘 동작하는 것 같다. 한칸씩 올려 치는 게 조금 어색하기는 하지만 오른손으로 모드 변환과 Enter를 입력하는데는 별 무리가 없는 것 같다. Enter키를 스페이스 옆에 두는 건 정말 좋은 생각이다.

그런데 다 작업한 후 알았는데 키 배치를 위해 굳이 키보드를 뜯을 필요가 없었다. 드라이버를 키 밑으로 살짝 끼워 넣어 지렛대처럼 제끼기만 하면 툭 빠져 나오고 구멍에 맞춰 누르기만 하면 쑥 들어가는데 그걸 몰라 분해를 했던 것이다. 뜯어 보기 전에는 이렇게 간단할 지 몰랐으니 뭐 그냥 내부 구경이나 했다고 생각하자. 요 키보드로 앞으로 연습 좀 제대로 해야겠다.

■ 영문 쿼티 자판과 호환되는 글판을 만들어 봤다. 전에 만든 것은 글쇠의 개수가 작아 완전히 호환되지 않았는데 오늘은 거의 비슷한 형태로 만들었다. 펑션키와 Esc, Tab, BS 키도 추가하고 CAS 키도 추가했다. 키보드 영역이 좁아 크기를 줄이고 좌표를 일일이 조정하는데 시간이 좀 들었다.

영문은 쿼티와 완전히 동일하되 다만 대소문자 구분에 Shift를 쓰지 않고 Upper를 쓴다는 점만 다르다. 그것도 마음에 들지 않으면 언제든지 Shift키와 함께 입력하도록 수정할 수도 있다. 키의 개수가 대폭 늘어났지만 영문 이외의 모드에서는 추가된 키를 전혀 사용하지 않으며 그냥 빈 채로 남겨두었다. 이 정도면 프로그래밍이나 코딩 작업에도 무리없이 사용할 수 있지 않을까 생각된다.

제외된 키 그룹이 세 가지가 있는데 우선 넘패드는 당연히 빼야 한다. 다음으로 숫자키가 빠졌는데 Mode를 누른 채 입력할 수 있으므로 빼도 될 듯하다. 제일 애매한 것이 커서 이동키와 PgUp, PgDn 등의 편집키인데 이것도 Fun과 함께 누르는 것이 그리 불편하지 않을 것 같아 일단 뺀 것이다. 물론 필요하다면 포함시킬 수도 있다. 추가된 키들은 배치만 했을 뿐 아직 코드에서 지원하지는 않는다. 별로 어렵지는 않지만 어디까지나 시도에 불과하므로 코드까지 작성하고 싶지는 않다.

위 그림에 나와 있는 배치 외에 좌우를 쫙 벌리고 가운데 펑션키와 CAS, Esc, Tab 등을 배치하는 것도 좋을 듯하다. 좌우가 벌어지면 손목이 편해지고 키보드의 전체적인 높이가 감소되며 보기에도 뭔가 색달라 보이지 않을까. 좌표를 일일이 조정하는 것이 엄청난 작업이라 코드로 수정해 보기는 좀 그렇고 그냥 그림이나 하나 그려보자.

펑션키를 중앙에 4열 3행으로 배치하고 그 아래에 CAS키를 두었다. 좌우 대칭을 위해 Del키도 포함시켰다. 이 정도 구성만 해도 기존 글판은 얼마든지 대체가능할 것 같다. 영문을 위해 중앙에 여섯개의 키가 더 늘어났는데 이 키를 한글에서도 활용할 생각은 추호도 없음을 분명히 해야겠다. 키가 늘어 났으니 여기에 ㄲ이나 ㅕ 같은 자주 쓰는 문자를 배치하면 좋을 것 같아 보이기도 하지만 이것은 애초의 개발 의도와 전혀 맞지 않다.

한글은 현재의 23키로도 충분하며 세 개 정도 더 빼서 20키 정도만 해도 그리 불편하지 않다. 쿼티 호환 모드를 생각하는 이유는 영문 입력이 너무 불편하기 때문에 보급기의 중간 단계가 필요하다고 생각하는 것 뿐이다. 현행 2벌식은 너무 영문 키보드에 종속적인 것 같으며 한글은 꼭 필요한큼의 키만 사용하는 것이 좋다고 생각한다.

이상, 오늘 작업은 여기까지이다. 어제까지만 해도 그렇지 않았는데 기운이 하나도 없는 걸로 봐서 이제 지친 것 같다. 머리가 무겁고 아무 생각이 안난다. 역시 뭘 하든지 체력이 있어야 하는 법이다. 하도 일이 안되서 프리즌 브레이크라는 드라마를 봤는데 더 짜증난다. 창살은 엘리베이터에 묶어서 떼 버리면서 의무실 문 여는 건 왜 그렇게 고민을 했을까? 헬기탄 놈들이 왜 뛰어 다니는 놈을 못 잡을까? 그 여변호사는 죽을지 뻔히 예상되는데 왜 경찰에 신고를 했을까? 별로 마음에 안드는 드라마다. 하지만 한번 보기 시작한 건 다 보는 성미라 어쨌든 봐야 한다.

07년 9월 4일

아너림 글판의 글쇠가 28개밖에 되지 않아 기존 PC에 비해서는 수가 현격히 작기는 하지만 그래도 소형 기기에 적용하기에는 아직도 부담스러운 것이 사실이다. 예를 들어 타블렛 PC에 적용하려면 양옆에 4열씩 나열하고 엄지 손가락 분은 조금 더 튀어 나와야 하므로 꽤 많은 공간을 차지하는 셈이다. 대략 한쪽에 10Cm 정도의 공간이 필요해 현실성이 없다. 그래서 전에 두 키를 하나로 합쳐서 제작하는 것에 대해 생각해 본 적이 있다. 그림으로 그려 보면 다음과 같다.

중앙의 평평한 부분은 손가락을 놓는 곳이고 좌우로 손가락을 밀어서 두 개의 키를 입력하는 식이다. 좀 더 작게 만들려면 V자 모양으로도 만들 수 있겠지만 그러면 손가락이 쉴 곳이 없으므로 중립 지역을 둔 것이다. 이렇게 되면 키를 절반으로 줄일 수 있을 뿐만 아니라 양쪽의 키가 가림막 역할을 하므로 키간의 간격이 전혀 없어도 불편하지 않다. 타블렛 PC 양옆에 4Cm 정도의 공간이면 모두 배치할 수 있다. 이것도 그림으로 그려보자.

꽤 그럴싸해 보인다. 그러나 이 방법은 별도의 하드웨어를 제작해야 한다는 면에서 당장 실행에 옮겨 보기가 힘들어 계획만 해 두었다. 키가 절반으로 줄어들어 14개로도 모든 문자를 다 입력할 수 있으니 얼마나 멋진가? 내가 생각해도 괜찮아 보인다. 그런데 나중에 안 일이지만 이 설계는 꽤 많은 문제가 있다. 2키가 하나로 합쳐지면 손가락 두 개만 쓰므로 손가락의 배치가 달라져 버리는 결정적인 문제가 생기는 것이다. 이렇게 되면 데스크탑 PC에서 새빠지게 익힌 타자 실력이 완전히 무효가 되어 버릴 것이다.

하지만 이 설계로부터 새로운 아이디어가 떠올랐다. 오늘 새로 주문한 MP3가 도착했는데 그다지 썩 훌륭해 보이지는 않지만 그럭 저럭 쓸만한 것 같다. 골치도 아프고 MP3도 새로 산 기념으로 산책을 나갔다. 이어폰 끼고 음악 감상하며 동네를 어슬렁거리는게 취미라 새 MP3의 성능도 시험해 볼 겸해서 말이다. 이 MP3에는 조그 버튼이 달렸다. 마치 조이스틱의 방향 스틱같은걸로 노래를 선곡하는데 하나로 5개의 키 입력을 하는 셈이다. 키보드도 조그 버튼처럼 만들면 어떨까 하는 황당한 생각을 하다가 별로 좋지 않다고 느끼는 순간 전에 만든 2키 합체 버튼의 변형이 떠올랐다.

엄지 손가락을 제외한 다른 손가락들은 좌우로 트는 데는 익숙하지 않다. 하지만 아래위로 밀고 당기는데는 어느 정도 익숙하므로 상하로 버튼을 겹치는 것은 가능할 것 같다. 물론 엄지 손가락은 좌우로 미는 것에 더 능숙하므로 전에 생각해 두었던 2버튼 합체형이 더 유리할 것 같지만 말이다. 마침 아너림 글판은 3행으로 되어 있으니 3행을 다 합쳐 버리는 것이 가능하다. 또 그림으로 그려보자.

수평으로 합체한 것을 옆으로 돌려 놓은 것과 비슷한데 중앙의 평평한 부분도 하나의 키로 사용한다는 점이 다르다. 키를 구성하는 세 개의 조각은 각각 분리할 수도 있고 통합할 수도 있다. 분리하면 제작 비용이 비싸겠지만 누르기는 편해지고 통째로 제작하면 만들기는 쉽지만 손가락의 힘이 많이 들어가 누르기가 어려울 것이다. 제작 단가의 문제가 없다면 분리하는 것이 더 나을 것 같다.

버튼은 바닥에 수평으로 배치하지 않고 손가락쪽으로 약간 기울여 10도 정도 위로 쳐든 모양으로 만들며 새끼 손가락 분은 조금 더 밑으로 내린다. 손가락이 키보드에 완전히 수직이 아니므로 손가락과 수직이 되기 위해서는 키가 조금 위로 들어 올린 형태인 것이 좋다. 이 형태의 키를 '삼돌이'라 칭하기로 한다. 합체키, 트리플 키 등 다양한 이름을 떠올려 봤지만 마땅한 이름이 없으니 일단 삼돌이라는 이름이라도 붙여 주자. 뭐든지 이름이 있어야 한다.

삼돌이는 세 개의 키를 수직으로 닥지 닥지 붙인 것이되 아래, 위 키의 각도를 조금씩 중앙으로 들어올려 손가락을 살짝 내리거나 위쪽을 올려 찌름으로써 쉽게 누를 수 있는 구조로 이해하면 될 것이다. 이것이 가능한 이유는 아너림은 손가락의 위치가 확실히 고정되어 있어서 아래 위로만 움직이기 때문이다. 삼돌이 형태로 아너림 글판을 다시 만들어 보면 다음 그림과 같다.

막상 그려놓고 보니 모양이 조금 거시기하다. 단순해 보이지 않고 굉장히 복잡해 보이는데 이는 실제 키를 어떻게 만드는가에 달린 문제인 것 같다. 작고 예쁘게, 그러면서도 오타의 위험이 없을 정도로 확실하게 잘 동작한다면 부피를 줄이는데는 효과가 있다. 심지어 옆에 바로 붙어 있는 글쇠들도 간격을 띄울 필요가 거의 없다. 1mm 정도로 띄워 손가락들끼리만 부딪치지 않으면 된다.

삼돌이의 또 다른 장점은 운지거리가 지극히 짧아 더 고속으로 입력할 수 있으며 손가락이 제자리에서 까딱 까딱거리기만 하므로 피로도도 작다는 점이다. 굳이 단점을 들자면 글쇠의 스위치 구조가 복잡하므로 제작 비용이 증가할 것이라는 정도이다. 설계만 해 보았을 뿐 실제 제작 및 사용을 해 보지는 못했으므로 편의성에 대해서는 아직 평가할 단계는 아니다. 이 방식을 채택한다고 했을 때 타블렛 PC나 UMPC의 형태는 다음과 같아질 것이다.

액정이 전면을 다 차지하고 마우스 패드 정도를 놓을 공간이면 키보드 전체를 다 집어 넣을 수 있다. 이 정도 크기면 충분히 소형 디지털 기기를 위한 입력 장치라고 이름을 붙이기에 손색이 없다. 양쪽에 손가락을 턱하니 올려놓고 다다다다 타이핑을 하다가 마우스가 필요할 때만 중앙으로 약간 이동하면 된다. 이 구조로 분당 600타 정도만 나와 준다면 성공적이다.

07년 9월 5일

■ 새끼 손가락의 글쇠들을 조금씩 아래쪽으로 내려서 그렸다. 전용 키보드에 손가락 길이에 맞게 키를 배치할 예정인데 연습 프로그램에는 이런 것이 반영되어 있지 않아 분명히 표시하는 것이 좋을 듯하다. 겨우 5픽셀을 내렸을 뿐인데 키보드 전체가 둥그렇게 밑으로 조금 내려 온 모양처럼 보인다.

■ Fun 모드에서 Space와 Enter를 눌러도 아무 반응이 없는 버그를 수정했다. 이게 간단해 보이지만 조건이 굉장히 복잡하다. Shift+Space 따위의 키 입력도 있기 때문에 Space를 무조건 문자로 볼 수가 없다. 어떤 조건에서는 기능키가 되고 어떤 조건에서는 문자가 되기 때문에 처리할 부분이 마땅치 않은 것이다.

어떻게든 한곳에서 처리하기 위해 기능 처리 함수로 넘기지 않고 문자 처리 함수에서 모아서 처리하려고 시도해 봤는데 조건이 너무 까다로와 그냥 기능 처리 함수에서 별도로 처리했다. 막상 해보니 모드에 따라 Space의 동작이 확실히 달라지는 면이 있어 이게 맞는 것 같다. 문자 모드에서는 숫자 모드를 고려하여 0을 입력받기도 하는데 비해 기능 모드에서는 이런 처리가 필요없기 때문이다.

■ 한칸 올린 자판에서 영문 Capital의 위치가 잘못 표시되는 버그가 있다. 그 이유는 Capital이 무조건 기능키가 아니라 영문에서만 기능키로 동작하기 때문에 키맵에 정의되어 있지 않아서 이다. 그렇다보니 하드 코딩으로 가상 키 코드가 'A'인 키를 찾아 이 키 자리에 Capital이 있는 것으로 해 버렸고 한칸 올린 자판에서는 당연히 한칸 아래쪽에 나올 수밖에 없다.

이름으로부터 키의 인덱스를 찾는 IDX 함수를 수정하여 이 함수에서 Capital을 특별히 검색하도록 했다. 키맵에는 여전히 Capital이라는 기능키에 대한 기록이 없으며 하드 코딩으로 처리했다. 여러 종류의 자판을 한 프로그램에서 다루다 보니 하드 코딩을 피할 방법이 없으며 코드는 갈수록 걸레가 되어 가고 있는 중이다. 완벽한 일반화란 정말 비싸고 어려우며 지금은 그 비용을 치를 여력이 없다.

■ 두더지 게임에서도 마찬가지 문제가 있다. 스페이스는 언제나 고정일 것으로 가정하여 스페이스 입력을 VK_SPACE로 받았는데 한칸 올린 자판에서는 스페이스가 N의 자리로 이동하므로 이 가정도 틀려지는 것이다. 현재 자판의 구조에 맞게 스페이스를 찾도록 수정했다. 함수의 호출 시기도 달라지고 원형도 달라졌다.

■ 쿼티 호환 자판은 만들어만 놓고 아직 제대로 동작하지 않는다. 좀 더 코드를 작성하여 BS, Del, Tab 세 개의 키만 더 처리하도록 했다. 펑션키는 이 연습 프로그램 자체가 액셀러레이터로 사용하고 있어서 KEYDOWN 메시지가 오지도 않는다. 디바이스 드라이버가 아니다 보니 여러 가지로 한계가 많다.

영문 입력 방법에도 문제가 있어 수정했다. 모든 키에 알파벳이 할당되다 보니 Capital을 둘 수가 없고 그래서 Upper로 대소문자를 구분하도록 했다. 다행히 Upper는 알파벳 자리가 아니라 쿼티 호환에서도 자리를 그대로 지킬 수 있다. 그런데 이렇게 했더니 마침표나 괄호 조차도 찍을 수가 없게 되어 버렸다. 마침표 찍을 때마다 한글 모드로 전환한다는 게 말이 안된다.

그래서 Upper 대신 Shift키로 대소문자를 결정하도록 했는데 여기서 또 여러 가지 문제가 터져 나왔다. Shift가 눌러져 있으면 문자 입력으로 보지 않으므로 아예 영문 처리 함수로 제어가 가지 않는 것이다. 그래서 또 아주 복잡한 조건이 더 추가되었다. Shift 단독으로 눌렀을 때는 쿼티 호환일 때 조합키로 인정하지 않는 것이다. 물론 Ctrl, Alt 등과 함께 눌렀으면 당연히 조합키로 인정된다.

이 버그를 잡으면서 또 다른 버그도 하나 더 수정했는데 이전 버전에서는 Upper 락이 걸려 있을 때 영문과 숫자의 기호가 입력되지 않았다. 문자를 선택할 때 nUpper로 선택하도록 했기 때문인데 수정했다. 영문, 숫자는 락 걸어놓고 입력해 본 적이 한번도 없어서 이 버그를 아직까지도 발견하지 못한 것이다.

■ Enter나 Mode, Fun 키를 고정하지 말고 사용자의 키보드 상황에 맞게 선택할 수 있는 옵션을 추가하고자 했다. 현재 Mode는 Tab키에 Fun은 Caps Lock 키에 연결되어 있는데 이렇게 된 이유는 내가 쓰고 있는 IBM 키보드에 이 외의 키가 없기 때문이다. 요즘 키보드에는 스페이스 옆에 한글, 한자, 메뉴, 윈도우 키 등 다양한 키들이 더 있는데 이런 키를 활용하면 더 좋을 것 같다. 키보드의 모양이 제각각이므로 이는 키맵에서 선택할 것이 아니라 사용자의 키보드에 맞게 선택되어야 한다고 생각했다.

그러나 막상 작업해 보니 문제가 많다. 우선 한글과 한자키가 예상과는 달리 다른 키들과는 완전히 다른 방식으로 동작한다. WM_KEYDOWN만 오고 WM_KEYUP은 아예 오지 않는다. 또한 WM_KEYDOWN이 왔을 때도 가상 키코드가 오지 않고 VK_PROCESSKEY가 대신 오며 한글, 한자 여부는 스캔 코드로 구분해야 한다. 그뿐 아니라 오토 리프트를 의미하는 플래그가 일반 키와는 달리 무조건 오토 리피트인 것으로 되어 있는 문제도 있다. 가장 심각한 것은 GetKeyState가 이 키들의 눌림 상태를 전혀 조사하지 못한다는 것이다. GetAsyncKeyState는 구분해 내기는 하는데 다른 키와 비트 구조가 다르다.

좀 이상해서 테스트 예제를 만들어 봤는데 한글, 한자는 WM_KEYDOWN까지 오지도 않으며 시스템의 한글 토글 기능을 막지 못한다. 정 막으려면 메시지 루프를 가로 막고 TranslateMessage 함수로 이 키를 보내지 말아야 한다. 이 함수 내부에서 한글 모드 변환을 알아서 처리하는 것 같다.

이 두 키를 차후 전용 키보드 제작시 Mode와 Fun으로 활용할 예정이었는데 여기서 또 다른 기술적 난제에 부딪쳤다. Caps Lock, Num Lock도 일반키와 똑같이 동작하는데 유독 이 두 키만 다르게 동작하는 것이다. 또 윈도우 키도 응용 프로그램이 가로챌 수 없는 키이다. 응용 프로그램까지 KEYDOWN 메시지가 오기는 하지만 그 전에 운영체제의 시작 메뉴가 열려 버린다. 따라서 이 키도 임의의 용도로 사용할 수 없다.

테스트 결과 Mode, Fun 대신 사용할 수 있는 무난한 키는 Menu 키 하나밖에 없었다. 이 키 하나만 일반 키보드와 동일한 방식으로 동작한다. 하나밖에 없을 바에야 옵션을 만들 필요도 없으니 이 기능은 넣지 않는 것이 더 나을 것 같아 포기했다.

■ 몇일전부터 특허에 대해 알아보고 있다. 굳이 특허에 관심을 가지는 이유는 일단 고생해서 만들었으니 배타적 권리를 확보하는 것이 당연하기 때문이고 경제적 이유로 권리를 인정받기 위해서다. 그 외에도 무분별한 변형을 방지하기 위해 특허가 반드시 필요하다. 이러 저러한 복잡한 이유로 깊이 생각하고 고민하여 키 배치를 만들어 놨는데 아무나 키 배치를 바꿔서 변형을 만들어 낸다면 문제가 복잡해질 것이다. 사공이 많으면 배가 산으로 가므로 일단은 내가 총체적인 권한을 가질 필요가 있다. 또한 이 자판이 적어도 하나의 한글 자판으로 인정 받을 경우 최초 개발자로서의 공로도 인정받고 싶다.

그래서 특허청 사이트를 들락거리며 여러 가지를 조사해 봤는데 특허를 낸다는게 결코 간단한 일이 아니다. 예상은 했지만 절차가 너무 복잡하고 형식도 까다롭다. 반드시 정해진 서식에 맞게 명세서를 작성해야 한다. 차례가 정해져 있음은 물론이고 선의 두께, 그림 파일의 포맷, 제목을 붙이는 방법, 사용할 수 없는 단어 등의 세세한 것까지도 다 규정되어 있다. 이 형식을 조금이라도 어기면 특허 등록을 안해주겠다는 식이다. 특허 등록까지의 시간도 상당히 오래 걸려 최소한 1년은 더 걸린다고 한다.

또 다른 문제는 비용이다. 기본료 얼마, 청구항 한건당 얼마, 한 페이지 늘어날 때마다 얼마 추가, 신청료, 유지료 등등 온갖 비용을 다 지불해야 하는데 대략 몇 십만원 정도 되는 것 같다. 하긴 이 정도도 안 받으면 개나 소나 다 특허를 낼려고 덤빌 것이고 실제로 특허청 조직을 운영하기 위해서는 돈이 들 것이다.

오늘은 명세서 초안까지 일단 만들어 놓고 특허 사무실을 가 보기로 했다. 마침 춘천에도 특허 사무실이 몇 개 있어 상담을 좀 받아 볼까 하고 엠파스에서 검색하여 전화를 걸었다. 그런데 왠걸! 분명히 춘천 교동으로 전화를 걸었는데 왜 서울 서초동에서 받을까? 춘천에는 특허청이 없어서 특허 사무실은 전부 서울이나 대전에 있을 수밖에 없고 춘천에 있는 전화는 달랑 전화 하나만 있는 것이란다. 이러니 개나 소나 다 서울에서 살려고 하지.

아뭏든 상담을 받는데는 성공했다. 변리사라는 분이 아주 친절하게 상담해 주었다. 우연인지 몰라도 고향 사람이었다. 고향 삼거리 이름까지 정확하게 대는 걸로 봐서 가짜는 아닌 것 같고 말투도 진짜 고향 사람이다. 내가 궁금한 것들에 대해 비교적 상세하게 답변을 해 주었는데 결과는 다소 실망스러웠다. 혼자 하기 힘들 것 같아 비용을 감수하고라도 전문가인 변리사의 도움을 받아 볼까 했는데 대략 400 정도가 들 것으로 예상된다.

변리사 수수료가 120에 부가세 별도, 특허청에 납입할 돈이 대략 15만원, 등록 비용인 40만원 정도에다 등록 완료될 경우 사례금으로 120을 더 줘야 한다. 이건 공식적으로 드는 비용이고 중간에 뭐가 잘못되면 보정하는 비용에 왔다 갔다 교통비에 잡비까지 다 더하면 넉넉잡고 500은 준비해야 할 것 같다. 그래서 혼자 출원하는 것은 어떠냐고 물었더니 혼자 해서는 힘들다고 한다.

허걱, 500만원, 난 그 돈 없소이다. 지금 집에 쌀 살 돈도 까딱까딱 하는 처지에 웬 500만원. 정말 부담스럽다. 사실 돈 자체가 아까운 게 아니다. 지금 만들고 있는 이 자판이 돈이 될거리가 아닌 것이 더 문제다. 출력이 없는 기술이다 보니 투자도 망설여질 수밖에 없다. 꼭 우리 사무실로 오라는 친절한 고향 선배와의 통화를 마치고 고민에 빠졌다. 돈도 아깝고 시간도 아깝고 이걸 꼭 해야 하나?

하자니 번거롭고 안 하자니 꺼림칙하다. 애써 만들어 놨는데 누군가가 먼저 상품화를 해 버린다거나 자기가 만든 것처럼 한다면 곤란하다. 사실 그럴 확률은 지극히 낮지만 말이다. 그래서 홈페이지에도 올려만 놓고 링크를 걸지 못한 것이다. 등록은 안했더라도 일단 출원이라도 해 놔야 홈페이지에 공개를 할텐데 말이다.

그러다가 무료 변리 상담 사이트를 찾아 전화를 걸어 봤다. 국선 변호사처럼 공익 변리사라는 분들이 있는데 무료로 특허에 대한 도움을 주는 곳이다. 친절하게 상담해 주셨는데 덕분에 궁금했던 몇가지에 대한 정보를 얻었다. 곤란한 문제가 있으면 언제든지 전화하란다. 정말 좋은 분이다. 앞으로 종종 전화 드려야겠다.

몇일 전에 출원인 코드도 받아 두었고 명세서도 초안 수준으로는 작성되었으니 내일 서울 특허청에 가볼 생각이다. 당장 등록할 건 아니고 등록에 필요한 요건만 조사해 올 것이다. 마침 출판사에 갈 일이 생겨 겸사 겸사 가 보는 것이다. 만약 내일 일이 잘 풀리면 아예 등록까지 해 버릴 생각이다. 되든 안되든 일단 출원 자체에도 의미가 있다고 생각한다. 형식이 잘못되어 거절당하더라도 적어도 내가 이 자판을 처음 생각했다는 증거는 될 수 있을테니까 말이다.

뭔가 새로운 것을 만든다는 것은 참 어려운 일이다. 에디슨 아저씨는 어떻게 그 많은 것을 다 만들었을까? 오늘은 어째 주저리 주저리 말만 많이 늘어 놓은 것 같다. 빨리 일이나 하자.

■ 여러모로 테스트를 해 본 결과 코드를 대대적으로 정비할 필요가 있다고 느꼈다. 한 프로그램에 너무 많은 자판이 옹기 종기 모여 살다 보니 하드 코딩의 횟수가 많고 버그가 창궐할 여지도 많은 것이다. 여러 가지 시도를 해 보다 보니 이것 저것 자판의 종류가 많은데 빨리 하나를 확정하여 나머지 것들은 좀 분리해야겠다. 우선 한손 자판만 떼어 내도 상당히 가벼워질 것 같은데...

■ 이 글판의 운명에 대해 생각해 봤는데 솔직히 성공하리라는 생각은 들지 않는다. 오히려 절망에 더 가깝다고 느껴지는데 개발을 진행하면 할수록 더 비관적인 생각만 든다. 사람들의 굳어진 습성을 고치려면 10%나 50% 정도 더 좋아서는 어림도 없고 최소한 두 배 이상 좋아야 한다. 한글은 그렇다치고 아너림 글판의 영문 입력은 쿼티보다 훨씬 더 불편하다.

그래서 생각한 것이 모든 것을 그대로 두고 한글만 아너림으로 먼저 만드는 것이 어떨까 하는 것이다. 전용 키보드를 따로 만들 필요도 없고 호환성도 유지되므로 오로지 한글 입력 디바이스 드라이버만 만들면 된다. 영문은 키 배치가 똑같고 한글만 2벌식과 조금 틀리므로 재미 삼아 써 보기에도 적당할 것 같다. 이 방안이 조금이라도 사람들에게 다가갈 수 있는 최후의 방안이 될지도 모르겠고 어쩌면 최선의 방안일지도 모르겠다.

07년 9월 6일

■ 현재의 아너림 글판은 연습 프로그램 외에는 동작하지 않는다는 점이 큰 걸림돌이다. 결국에는 디바이스 드라이버를 만들어야겠지만 내가 가진 기술력이 아직 커버하지 못하는 영역이므로 더 많은 공부를 해야 할 것 같다. 그러다가 다른 자판들은 어떻게 하나 살펴 보기로 하고 안마태 자판을 연구해 보았다. 3벌식이기는 하지만 여러 모로 마음에 드는 기능들이 많다.

좌자 우모의 원칙을 잘 지키고 있고 아래쪽에 종성이 깔끔하게 배치되어 있다. 우측의 글쇠와 같이 누르면 된소리가 나타나는 것이 특징이다. 모아치기가 가능해 숙련되면 그야 말로 속도는 환상일 것 같다. 그런데 된소리 입력의 문제로 인해 가장 빈도가 높은 ㅇ이 집게 자리를 차지하지 못한 것이 안타깝고 ㄲ 입력을 위해 손목이 이동해야 한다는 점이 약간 문제인 것 같다.

많이 사용해보지도 않고 함부로 이 자판을 평가해서는 안될 것 같으므로 일단 평가는 보류하고 디바이스 드라이버의 동작 방식만 연구해 봤다. 홈페이지에서 압축 파일로 제공하는데 실행 파일하나 DLL 하나다. 딱 보니 후킹인 것이 분명하다. 이건 전에 나도 생각했던 방법이되 기술력 부족과 시간 부족으로 인하여 잠시 제껴둔 것인데 테스트해 보니 매끄럽게 잘 동작하는 것 같다. 다만 IME 방식이 아닌 프로그램에는 동작하지 않으며 웹 브라우저에서도 후킹이 안되 문제는 좀 있는 것 같다. 나의 후킹 코드는 다른 건 몰라도 웹 브라우저는 잘 되는데...

어쨋든 이 예를 보고 후킹도 그럭 저럭 쓸만하다는 판단을 하게 되었다. 종국에는 디바이스 드라이버를 만들어야겠지만 임시적인 방편으로 사용자에게 부담을 주지 않는다는 면에서는 훌륭한 것 같다. 빨리 시간나면 후킹이나 제대로 연구해 봐야겠다. 되는 걸 확인했으니 부지런히 가기만 하면 된다. 하긴 안될리가 없다. 후킹인데...

07년 9월 7일

■ 어제 특허 문서 초안 일단 완성. 오늘 특허청 방문하여 상담받고 출원할 생각이었으나 시간 부족으로 특허청 방문 못함. 서울에 갔었는데 다른 볼일 보다 너무 늦어짐. 좀 더 신중을 기한 후 따로 한번 더 갈 예정. 춘천은 서울에서 생각보다 멀다.

■ 한빛미디어 임성춘 팀장에게 처음 아너림을 보여줌. 반응은 보편적임. 팀장님이 이런 것에 별 관심이 없는 듯함

■ 기문이에게 보여줌. 반응 상당히 좋음. 사업거리가 될 것 같다고 하여 용기가 생김. 기문이가 특허에 대해 꽤 아는게 많음. 명세서를 좀 더 잘 써야겠다고 생각. 변리사 고용 문제는 아직 고민중이나 비용이 너무 부담스러움.

■ 홈페이지에 올렸던 자료들 일단 삭제함. 어차피 링크가 안걸려 아무도 못 보기는 하지만 특허 요건상 먼저 발표해서는 안된다고 함. 최대한 빨리 공개하여 의견 수렴을 받으려고 했는데 큰일날 뻔 했음

■ 시제품의 필요성을 느끼기 시작함. 최대한 기존 방식과 호환되어야 한다고 생각함. 아무리 좋아도 기존과의 호환을 무시하고 성공한 사례가 없음. 일단 드라이버 안깔고 쿼티 자판으로도 동작할 수 있어야 함. 키는 좌우 분리하고 왼쪽도 손가락 방향으로 기울일 것. 4행의 Enter, Mode, Fun 등만 원하는 위치에 있는 정도면 충분할 듯. 넘패드는 굳이 없어도 상관없음

07년 9월 10일

■ 조상님들 산소 벌초 작업으로 인해 사흘간 개발 잠시 중단. 벌초중에도 끊임없이 자판에 대해 연구하려 했으나 막상 벌초를 해 보니 택도 없는 생각이었음

■ 영문 글판의 재배치. 초안은 빈도에 따라서만 글쇠를 배치한 그야말로 날림 공사였다. 특히 양손의 연타율이 너무 높은 것이 가장 큰 문제다. 그래서 조금 더 개선하기 위해 기초 데이터를 수집하고 순서를 조금 바꾸었다. 영문은 알파벳뿐만 아니라 단어의 빈도도 아주 중요하다. 조사 결과 아래의 단어가 영어 문장의 60%를 차지한다는 정보를 얻었다.

a, about, after, all, an, and, any, are, as, at, be, been, but, by, can, could, day, dear, do, for, from, go, good, had, has, have, he, her, here, him, his, house, I, if, in, is, it, its, just, last, letter, make, may, me, more, my, night, no, not, now, of, on, one, or, other, our, out, over, please, say, send, she, should, sir, so, some, take, than, thank, that, the, their, them, then, there, they, thing, think, this, time, to, truly, two, up, very, was, we, week, were, what, when, which, who, will, with, work, would, write, you, your

이 단어들을 관찰하고 직접 입력해 본 결과 연타가 자주 발생하며 빈도가 높은 글자들의 순서 패턴들이 발견되었다. 자주 쓰는 단어에 나타난 것과 본인의 영어 실력을 바탕으로 분석해 본 결과 다음 글자들은 반드시 좌우를 분리하는 것이 바람직하다.

wh - who, where, what

th - they, then, there, this, the

ou - our, could, should, house

an - and, any, than, thank

이 글자들을 분리하기 위해 A와 O의 위치를 맛바꾸고 W와 H의 위치를 맛바꾸었다. 이외에도 ng나 st도 좌우 분리가 반드시 필요한데 이미 분리되어 있다. ST가 왼손 집게에 몰려 있어 S와 D를 바꾸고 EH의 연타율이 너무 높으므로 H와 L을 바꾸었다. 바꾼 후의 결과는 다음과 같다.

대충 쳐 봐도 이전보다는 나아진 것 같다. 물론 더 많은 연구가 필요하지만 영어가 모국어가 아닌 바에야 당장 실천하기는 어렵다. 어떻게 하더라도 연타는 발생할 수밖에 없으므로 최소화하는 방향으로 연구해야 하며 이는 좀 더 방대한 데이터와 분석을 필요로 한다. 초안은 이 정도 수준에서 일단 만족하고 후일을 기약한다.

■ 특허 신청 완료. 원래는 한 몇일 더 심사 숙고하고 명세서를 가다듬어 신청을 할 생각이었다. 그러나 다음 일정도 결코 한가하지 않은데다 심사 기간이 1년씩이나 걸린다고 하니 일단 신청을 해 놓는 것이 좋을 것 같아 새벽에 대충 정리만 했다. 명세서는 이미 만들어 두었으므로 청구항만 재편집했다. 그리고 아침에 그랜저를 몰고 서울로 향했다. 공익 변리사와 상담을 먼저 한 후 접수를 할 생각이었으나 통화 결과 공익 변리사는 서류까지는 봐 주지 않는단다. 그래서 특허청으로 바로 쳐들어갔다.

마침 특허청에도 상담을 받을 수 있는 공익 변리사가 상주하고 있었다. 그래서 용감하게 상담을 했는데 청구항이 엉망이라 이대로는 보나마나 거절이라고 한다. 휴게실로 돌아와 노트북을 펼쳐 청구항을 지시대로 다시 수정해서 가져갔다. 발명 내용에 대해 상세하게 설명을 하니 꽤 좋은 아이디어인 것 같다며 관심을 보이며 청구항의 예를 직접 작성해 주었다. 역시 전문가이다 보니 청구해야 할 내용을 잘 파악하는 것 같다.

변리사의 설명을 듣고 나름대로 청구항을 작성하는 요령을 터득한 후 다시 뜯어 고쳤다. 굉장히 많은 조언을 해 주었지만 시간 관계상 더 상세한 질문을 하지는 못하고 자의적으로 해석하여 내 주관대로 청구항을 다시 작성했다. 상담은 꽤 도움이 되었지만 받아들일 수 없는 조언도 있었다. 가급적이면 변리사를 구하여 대리를 맡기라고 하는 것은 비용상으로도 어렵지만 대기하는 시간이 너무 길어서도 안된다. 또한 삼돌이 방식의 글쇠에 대해서는 별도의 특허를 내라고 하는데 그러면 돈이 두 배로 들 것 아닌가?

그냥 변리사를 쓸까 싶기도 했지만 뭐 이거 해서 대단한 사업을 할 것도 아니고 성공 여부도 불확실한데 2~3백이나 하는 돈을 선뜻 쓰기도 싫고 변리사 만나러 왔다 갔다 하는 것도 적성에 맞지 않다. 국가의 문서이다 보니 요건이 쓸데없이 까다로운것 같아 맞추기가 무척 어렵지만 내 생각에는 적어도 최선을 다한만큼의 효과는 있으리라 기대한다.

마지막 20분 정도 동안 청구항을 다시 뜯어 고치고 곧바로 인쇄해서 접수를 했다. 출원인 코드는 이미 받아 두었으므로 접수는 금방이었다. 접수증과 돈 내라는 청구서를 받아왔다. 비용은 대략 30만원 정도이지만 개인은 70%나 할인해 주므로 8만원 정도의 비용밖에 들지 않았다. 죽이 되든 밥이 되든 일단 접수해 뒀으니 심사가 진행되는 동안 원고나 쓰면서 대기해야겠다. 물론 가급적이면 밥이 되었으면 좋겠지만....

이로서 거의 한 달에 걸친 아너림 개발은 일단락 짓는다. 이 것 외에도 해야 할 일들이 많이 밀려 있어 후킹이나 디바이스 드라이버 개발 등은 다음 기회로 미루기로 한다. 그런데 경험상 이렇게 우선 순위가 한번 밀리면 좀체 제 위치를 찾기가 어려웠던 것 같다.

~09년 2월

1년 반의 시간이 흘렀다. 특허 심사 청구하는 동안은 무작정 기다리기로 하고 그동안 다른 일들을 했다. 닷넷 프로그래밍 정복이라는 책을 출판했으며 모바일 회사에 다니며 윈도우 CE 개발을 했다. 바쁘게 사는동안 아너림은 나의 잠재 기억 저 아래쪽에 잠겨 버렸다. 이러다 프로젝트를 새로 시작하면 과연 기억이 날른지 의문스럽다.

특허 심사가 진행되는 동안 이 자판을 지인들에게 보여 주었다. 사람에 따라 평가가 좀 다른데 IT 직종에 종사하는 사람들은 썩 괜찮다는 평가를 했고 비IT 직종의 사람들은 도대체 이딴 걸 왜 만드냐고 했다. 가장 친한 고향 친구이자 처남(그러니까 마누라 오빠다)에게 보여 줬더니 괜찮아 보이기는 한데 사람들의 습관을 바꾸기가 쉽겠느냐고 한다.

맞는 얘기다. 나도 그걸 모르는 바 아니다. 그래서 서두르지도 않고 큰 기대도 하지 않는 것이다. 하지만 현재의 2벌식보다는 더 낫다는 확신이 있어 나는 끝까지 해 볼거다.

09년 2월 16일

드디어 특허 심가 결과가 등기로 도착했다. 노란 봉투를 받자 마자 우악스럽게 찢어 봤다. 결과는 거절도 아니고 등록도 아닌 어쩡쩡한 상태인데 일단은 거절이다. 그러나 완전 거절과는 좀 다른 상태인데 보정서와 의견서를 재출하면 재 심사해 주겠다는 것이다. 거절 이유는 청구항이 불명확다는 것인데 내가 보기에는 왜 불명확한지를 설명한 문장이 더 불명확했다. 도대체 뭘 어떻게 고치라는 건지 당췌 알아 먹을 수가 없다.

보정서를 재출하라니 다시 문서 작업을 해야겠는데 지금 하고 있는 프로젝트가 너무 바빠서 도저히 이전 프로젝트를 다시 시작할 엄두가 나지 않는다. 그래서 그냥 내 팽겨 쳐 두고 프로젝트에만 몰두했다. 먹고 살기 위해서는 어쩔 수 없다.

몇일 후에는 특허 사무소에서 DM이 발송되었다. 자기 사무실에 의뢰를 하면 특허를 받을 수 있도록 최대한 도와 주겠다는 것이다. 탁 까 놓고 얘기해서 광고인 셈이데 그래도 누군가가 관심을 가진다는 게 고마울 따름이다.

09년 4월 8일

보정서 제출 기한이 일주일 남았다. 이제 더 물러설 곳이 없으니 작업을 하는 수밖에 없다. 아침에 무작정 특허청으로 출근했다. 하루 그냥 투자하기로 하고 말이다. 정 안되면 1개월 연기를 하는 수도 있지만 어차피 1개월 후에도 한가해지지 않을 것 같으니 그냥 지금 하는 게 나을 것 같다.

공익 변리사와 보정서 제출 연기건에 대해 조금 물어 본 후 DM을 보낸 특허 사무실에 가 보기로 했다. 돈이 좀 들더라도 지금은 전문가의 도움이 필요하다는 판단이 들었고 마친 사무실이 특허청 근처에 있었다. 전화상으로 물어 보니 비용도 그다지 많이 요구할 것 같지 않았다.

변리사는 아주 점잖은 분위기로 신뢰를 팍팍 주는 외모였고 말도 꽤 잘했다. 그러나 상담 결과 변리사 의뢰는 하지 않기로 했다. 상담중에 중요한 사실을 알게 되었는데 특허 출원이 거절될 경우 배타적인 권리는 갖지 못하지만 최소한 방어 효과는 있으며 내가 최초의 고안자라는 것은 공인을 받게 된다는 것이다. 그 정도면 충분하다. 내가 특허를 출원한 목적이 바로 그것이므로 거절을 받는다 하더라도 출원의 의미는 분명히 있는 것이다.

또 변리사의 태도도 별로 마음에 들지 않았다. 나름 특허를 받을 수 있는 요건에 대해 친절하게 상담을 하려고 했지만 정작 특허의 주제인 아너림 자판에는 전혀 관심을 보이지 않는 것이다. 특허의 내용보다는 법률 요건을 갖추기 위해 문서를 그럴 듯하게 작성하는 것이 더 중요하다는 것을 강조했다. 그 말이 틀리지는 않았지만 특허 내용도 모르면서 요건을 어떻게 갖출 수 있다는 것인지 이해할 수가 없다.

그래서 다음에 또 올께요 거짓말을 하고는 나와 버렸다. 그리고 다시 특허청으로 가 공익 변리사를 1시간 이상 괴롭히며 보정서 작성 방법을 열심히 공부했다. 설명을 들어 보니 그럭 저럭 할 수 있을 것 같다. 필요한 서류를 챙겨 들고 춘천으로 돌아왔다. 그리고 꼬박 밤을 세서 보정서와 의견서를 꼼꼼하게 작성했다. 짧은 시간이지만 나름대로 최선을 다했다.

09년 4월 9일

출근하는 길에 특허청에 들러 어제 작성한 보정서와 의견서를 접수했다. 공익 변리사에게 잘 적었는지 봐 달라고 잠시 보여 줬는데 보정서 양식을 엉뚱한 걸로 썼다. 다행히 제출전에 발견해서 맞는 양식으로 교체했다. 양식만 바꾼 후 바로 재출해 버렸다. 접수비가 몇 만원 더 들어갔다.

이제 보정서를 제출해 놨으니 한 두어달은 프로젝트에 몰두할 수 있을 것이다. 다음 심사 결과는 어떻게 나와도 상관없다. 등록되면 좋은 거고 거절을 당하더라도 나의 처지에서는 최선을 다했으므로 더 불만이 없다.

보정서를 재출한 후 웹에서 검색해 보니 과연 내 특허 출원서가 공개 특허로 검색이 되었다. 이제 드디어 세상에 공개가 된 것이다. 공개 특허가 되었으니 홈 페이지에 공개해도 될 것 같아 미리 만들어 두었던 페이지의 링크를 걸었다. 이제 혼자가 아니라 여러 사람들의 도움과 의견을 받을 수 있을 것이다.

그나 저나 아너림 자판 실물도 만들어 보고 프로그램도 더 개선해야 하는데 언제쯤에나 짬이 날지 기약이 없다. 프로젝트를 두 건이나 진행하고 있는 상황이라 올해 일정은 벌써 꽉 차 있다. 늦어도 환갑전에는 시제품을 만들어 볼 수 있겠지.

12년 5월 12일

마지막 일지를 쓴지 3년이 지났다. 그동안 안드로이드, 윈도우폰 등 모바일 대세를 따르기 위해 이런 저런 모바일 프로젝트에 참여했고 안드로이드 프로그래밍 정복, 윈도우폰 프로그래밍 정복 등의 책을 저술하였다. 다행히 안드로이드 서적이 베스트셀러로 등극하여 먹고 사는데는 상당한 여유가 생겼다. 그러나 이어서 출판한 윈도우폰은 완전히 망해 버렸다. 대략 10개월 준비한 것 같은데 MS가 철저하게 나를 배신해 버렸다.

지금은 안드로이드 4.0 및 곧 발표될 5.0을 위한 개정판 작업을 준비하는 시점이다. 독자들과의 약속도 있고 계속 모바일 프로젝트를 할 것이므로 이 작업은 해야 한다. 지금은 5.0까지 기다려야 하는 상황이라 잠시 짬이 나서 다시 아너림 글판 작업을 조금 할 수 있게 되었다. 쉬는 동안 아주 중요한 사건이 발생했는데 드디어 특허를 받았다.

2009년 7월 6일날 받은 것으로 되어 있다. 삼성 갤럭시 S 개발팀에 참여하여 수원에 6개월동안 감금되어 있는 상태에서 받은 것이라 별다른 감흥을 느끼지도 못했다. 그냥 나왔구나 이런 생각만 들었다.

특허를 받은 후 시제품을 만들어 보려고 시도해 보았으나 막상 실천에 옮기자니 어디서부터 손을 데야 할 지도 모르겠고 비용도 만만치 않게 드는 것으로 조사되었다. 차일 피일 미루다 보니 흐지 부지 되었고 다른 일정에 밀려 무려 3년동안 별다른 작업을 할 수가 없었다. 그렇다고 해서 이 자판을 완전히 잊은 것은 아니었다. 언제나 생각은 하고 있지만 시간이 허락되지 않아 작업을 할 수가 없다.

중간에 몇몇 관심을 보이는 사람들로부터 메일을 받았다. 아이디어는 괜찮은 것 같은데 왜 시제품을 만들지 않느냐는 질문을 하는 분도 계셨고 시제품을 만들기 위한 방법을 알려 주는 고마운 분들도 있었다. 당시에는 수행중인 프로젝트가 우선이라 관심은 있지만 실천에 옮길 수가 없었다. 또한 작년, 올해에 양가 아버님이 차례로 돌아가시는 바람에 개인적으로도 어려운 시간을 보내 심적인 여유도 없었던 셈이다.

앞으로도 이런 사정은 크게 달라지지 않을 것 같다. 해야 할 일이 있고 당장 돈도 벌어야 하기 때문이다. 그러나 이 프로젝트를 결코 그만둘 생각은 없으며 늦더라도 반드시 소기의 결과를 내고 싶다. 최소한 시제품까지는 만들어 봐야 하지 않을까?

지금은 모바일 시대이다. 굳이 하드웨어를 만들지 않더라도 폰에서 자판을 구현해 볼 수 있으며 관련 자료나 소스도 공개된 것이 많이 있어 구현에 별다른 어려움은 없을 것 같다. 모바일까지 고려하여 설계도 좀 더 수정하고 비록 화면상이지만 실제로 사용할 수 있는 아너림 자판을 곧 제작해 볼 것이다. 다행히 안드로이드는 나름대로 전문가여서 혼자서도 구현해 볼 수 있다.

12년 5월 20일

약 일주일간 안드로이드 키보드 자판을 만들었다. 키보드 제작에 관련된 기술 문서는 거의 없으며 다만 구글에서 제공하는 SampleKeyboard라는 예제 하나만 달랑 있을 뿐이다. 그래도 꽤 많은 것을 알 수 있는데 일단 키보드가 디바이스 드라이버 형태가 아니라 서비스 형태로 작성된다는 것을 알았다. 입력이 필요할 때 OS가 서비스의 콜백을 호출하여 입력을 받는 형식이다. 예제는 자판의 키를 정의하는 방법과 키보드를 교체하는 방법 정도에 대한 소중한 정보를 제공해 주었다.

예제를 분석한 후 관련 클래스를 레퍼런스에서 찾아 죄다 인쇄한 후 읽었는데 항상 느끼는 거지만 구글은 MS에 비해 문서화는 정말 초등학교 수준도 안된다. 설명이 거의 없어 메서드나 인수의 이름으로 동작을 유추, 추리, 추측하고 코드 작성한 후 맞는지 확인하는 식으로 학습을 진행해야 한다. 다행히 예제는 어렵지 않게 분석되었고 비슷한 방식으로 동작하는 샘플 키보드와 강좌까지 써 두었다.

그러나 구글의 예제는 영문만 다루고 있어 한글 조립에 대한 정보는 얻을 수 없었다. 한글 조립에 대해서는 다행히 Kandroid에서 작성한 키보드 소스를 구해 많은 도움을 받았다. 한글 오토마타 구현 기술이야 어렵지 않지만 안드로이드가 조립 문자열을 다루는 방식을 이해할 수 있었다. 오토마타 코드는 너무 불필요한 코드가 많아 압축된 코드를 좋아하는 나의 성향과는 거리가 있었다. 그래서 죄다 다시 만들었다. 이런 소중한 소스를 공개해준 분께 정말 감사드린다. 자신의 소스를 아낌없이 공개하여 후배들에게 기술을 전파하는 것이 얼마나 중요한가를 세삼 느낄 수 있다.

구글 예제와 Kandroid의 예제 둘, 레퍼런스 등을 참조하여 아너림 키보드 초안을 만들었다. 한글 오토마타는 여러번 만들어 본 적이 있지만 조합형이나 완성형이 아니라 유니코드 기반이라 자료 구조를 완전히 새로 작성해야 했다. 뻔한 작업이지만 시간이 꽤 오래 걸렸으며 큰 어려움은 없었다. 조립중에 커서를 옮길 때 조립을 완성하는 부분에서 다소 헤맸는데 구글의 예제에 버그가 있으며 이를 따라한 다른 소스들도 똑같은 버그가 있었다. 결국 로그 찍어가며 현상을 관찰해 보고 대충 수정했다. 다음이 첫번째로 만든 아너림 키보드이다.

한 행에 8개의 키가 있으므로 10개인 쿼티보다는 많이 여유로울 것이라 생각했는데 막상 만들어 놓고 사용해 보니 그다지 여유있지는 않았다. 실제 장비에서 이 키보드로 입력해 보면 배치가 익숙치 않아서 그렇지 꽤 사용할만했다. Upper키도 똑같이 동작하면 더블 푸시하면 락하는 기능도 만들어 넣었다. 진동, 사운드 기능까지 넣어 꽤 사실감이 높으며 실제 키보드로도 사용할 수 있는 정도다. Mode 키를 누르면 영문으로 바뀌며 Mode를 더블 푸시하면 숫자로 바뀐다. 다음은 영문 배치 모습이다.

zqxj 키가 Upper에서 있어 좀 불편한 면이 있지만 빈도가 높지 않아 쓸만한 것 같다. 숫자 입력도 크게 불편하지는 않았다. 다만 입력중에 음소를 삭제할 때 Upper + Space를 두 번 눌러야 된다는 점은 무척 불편했다. 모바일 장비에서는 제자리에서 손가락만 누르는 것이 아니라 실제로 보고 눌러야 하는데다 오타가 많이 발생하므로 이 키만큼은 별도로 따로 만들어야 할 필요성을 느꼈다. 앞으로도 한참 더 작업해야 한다.

12년 5월 21일

초안으로 제작한 안드로이드 키보드를 하루동안 사용해 본 결과 많은 부분을 수정해야 함을 발견했다. 실제 사용해 보니 다음과 같은 불편함이 있다.

■ BS 키를 따로 배치할 필요가 있다. 손이 제자리에 고정된 상태에서 Upper+Sapce로 삭제하는 것은 굉장히 효율적이지만 모바일은 눈으로 보고 치므로 제자리 효과가 없다. 아무리 잘 만들어도 오타가 자주 발생할 수밖에 없는데 매번 두번 눌러야 하는 것도 무척 불편하다.

■ Space는 중앙에 있어야 하며 다른 키보다는 훨씬 더 커야 한다. 이유는 BS와 마찬가지로 제자리 자판이 아니기 때문이다. 오른손 엄지 위치에 맞출 필요가 없다.

■ 기능키에 F1~F12까지는 굳이 넣을 필요가 없다. 모바일 환경에서는 쓰지도 않을 뿐더러 데스크탑 환경에서도 실효성이 없다. 도움말 보려면 Fn 모드 변경, Upper 누름, F1키 누름 3개를 눌러야 하며 Ctrl이나 Shift와 조합하여 누르는 것은 거의 불가능하다. 결국 펑션키는 데스크탑용이며 별도의 키를 따로 만들어야 한다. 제일 윗열에 8개의 키를 따로 배치하고 Fn키와 같이 누르면 F9~F12 및 Play, Mute, VolumeUp, VolumeDown 기능을 할당할 예정이다. Num 모드일 때는 별도의 키를 더 할당해 넣을 수도 있다. 이 키는 아너림 필수는 아니며 옵션이다.

■ 이렇게 되면 Fn 키는 이름이 기능키가 아니라 편집키가 된다. Fn의 이름을 Edit로 바꾸기로 한다.

■ 펑션키가 들어가면 Ctrl, Alt, Shift 키도 같이 넣어야 한다. 같이 셋트로 묶어서 하나의 옵션 사항으로 정의하기로 한다. 제일 아래열은 다음과 같은 구조로 배치된다.

Ctrl Shift Edit Mode Space Enter Alt

Ctrl과 Shift는 같이 누를 경우가 많으므로 왼쪽에 같이 배치하고 Alt는 단독으로 누를 경우가 많으므로 오른쪽에만 배치했다. 여기서 Shift는 영문 대소문자 토글 등의 기능은 가지지 않는다. 다만 Ctrl+Shift+S 등의 단축키 입력에만 사용된다.

■ 키보드에 없는 문자들도 입력할 필요가 있다. 대표적인 예가 ♥ 인데 문자 보낼 때 하트 뿅뿅 날리는 사람들이 많다. 숫자 키보드에 Upper 정도로는 어림도 없고 여러 페이지가 필요하다. 다소 불편하고 육안 검색해야 하지만 어차피 외워서 치는 문자들은 아니다. 모바일에서는 키보드의 키 캡션을 실시간으로 바꿀 수 있으므로 문제가 되지 않으며 물리적 키보드는 기호표를 띄워 보여주는 형식으로 표시 가능하다.

■ 문자 키보드에 Upper가 빠지고 Page 개념이 들어가므로 훨씬 더 많은 문자를 넣을 수 있다. 그래서 한글, 영문 키보드의 Upper에는 공간을 좀 더 충분히 남기기로 한다. 유럽 언어 등을 위해 Upper 상태를 사용할 수 있도록 하고 12개의 자주 쓰는 구두점만 고정하기로 한다.

결국 모바일과 데스크탑 키보드의 배치는 다를 수밖에 없다는 결론에 도달했다. 문자를 입력하는 자세, 형태, 필요성 등이 모두 다르므로 어쩔 수 없다. 그렇다고 해서 통일성이 손상되는 것은 아니다. 외워서 쓰는 문자키의 배치만 일관되다면 문제는 없다. 그런데 실제 아너림 키보드를 모바일로 사용해 보니 2벌식보다 못한 치명적인 문제가 발견되었다. 데스크탑 키보드는 집게 손가락에 가장 많은 빈도를 할당하는데 이러다 보니 엄지만으로 치는 모바일 환경에서는 손가락이 자꾸 가운데로 몰리는 부작용이 있다. 어쩔 수 없는 문제인 것 같다.

아직 배치나 구조 등 한참 더 작업해야 하지만 중간 결과를 정리해 보자. 동작 방식도 일부 바뀌었고 키의 배치도 바뀌었을 뿐만 아니라 내부적인 알고리즘도 대폭 수정했다. 특히 한글 오토마타는 불필요한 구조를 다 걷어내고 가장 간략한 형태로 작성했다. 한글 키보드는 다음과 같다.

공백을 중앙에 크게 배치했고 제일 오른쪽에 Del키를 넣었다. Upper+Space도 물론 동작한다. Fn키는 이제 Edit로 이름을 바꾸었다. 키에 아이콘도 넣어 보았다. Upper 상태는 다음과 같다. 영문 키보드도 마찬가지이다.

빈자리가 많이 생겼는데 이는 일본어나 유럽 언어를 위해서이다. Upper에 기호를 너무 많이 넣어 놓으면 움라이트 등의 추가 문자를 넣을 공간이 없으므로 세계적으로 많이 쓰는 기호만 배치하고 나머지는 언어별로 알아서 기능을 할당하라는 뜻이다. 물론 구두점 등도 언어별로 따로 넣을 수 있지만 자주 쓰는 구두점은 자리를 확실하게 고정할 필요가 있다고 판단했다. 문자키는 다음과 같다.

첫 페이지는 Mode키를 누른 채(Hold Down)로 바로 입력할 수 있으므로 접근성이 굉장히 좋은 편이다. 두번째 페이지 이후는 문자 키보드로 전환한 후 Next키로 페이지를 전환해야 입력할 수 있어 불편하다. 특수 기호 등은 상관없지만 쿼티 키보드에 있는 ~@$^ 등이 두번째 페이지로 이동한 점은 참 아쉬운 점이다. 뭔가 다른 대안을 내야 할 필요가 있다. 편집 키보드는 다음과 같다.

F1~F12까지 기능키가 빠져 여유가 생겼으며 Upper는 없다. 한글 키도 제거했으며 표준 키보드의 모든 기능 키를 한 페이지에 다 넣고도 2개 더 여유가 생겼다.

여기까지 작업한 결과는 아직 별로 만족스럽지 못하다. Fn을 Edit로 바꾸고 Upper를 없앴다는 점, 임의의 기호 입력을 위해 숫자 키보드에 페이지 개념을 도입했다는 것등, Del키를 추가했다는 점 등의 큰 틀은 만족스럽지만 개별 문자의 배치는 별로 마음에 들지 않는다. 실용성도 없고 너무 억지스럽다. 아직 한참 더 고민을 많이 해야 한다는 뜻이다.

12년 5월 22일

■ 아너림은 결국은 데스크탑용 키보드이며 모바일용에는 썩 어울리지 않는다. 두손으로 제자리에서 치는 것을 가정하다 보니 화면 중앙의 빈도가 너무 높은 문제가 생각보다 치명적이다. 하지만 모바일용으로도 구색을 갖출 필요는 있고 과연 어떤 모습일까 궁금하기도 하고 모바일 환경도 미리 고려해 볼 필요가 있을 것 같아 안드로이드용으로 작성한 것이다. 이 정도 해 봤으면 일단락 짓고 데스크탑용으로나 열심히 개발해 봐야겠다.

데스크탑에서 기존 키보드를 대체하려면 펑션키와 CAS 조합키가 반드시 필요하다. 문서 작업, 컴파일 등의 작업에 Ctrl + F9 따위의 단축키가 종종 사용되므로 문자만 잘 입력해서는 아무 소용이 없다. 12개의 기능키를 다 넣을 필요는 없으므로 F8까지만 넣고 나머지는 Edit 키와 같이 입력받기로 한다. 모바일도 쓸모는 없지만 일관성을 유지해야 하므로 펑션키와 CAS 키를 넣어 보았다.

일관성을 위해 넣어 보자 한 것인데 막상 넣어 보니 진짜 못 봐 주겠다. 모바일 버전은 그냥 빼는 게 좋을 것 같다. 어차피 Del키 때문에 일관성은 이미 깨졌으니 모바일은 모바일답게 만드는게 나을 것 같다.

데스크탑에서 펑션키는 숫자 모드일 때 별도의 문자나 기능을 더 할당할 수 있다는 이점이 있다. Mode + F1키를 누름으로써 미리 정의한 기능을 수행할 수도 있고 자주 쓰는 문자를 편하게 입력할 수도 있다. 모바일 환경에서는 펑션키가 필수가 아니므로 여기에 문자를 할당하지는 않기로 한다.

■ 가운데 쏠림 현상이 예상외로 불편하다. 엄지 손가락이 자꾸 엉키는 듯한 느낌이 든다. 그래서 이 부분도 모바일 환경은 키 배치를 수정할 필요가 있다. 키의 폭을 1%씩 줄여 가운데를 넓게 띄워 보았다.

엄지 손가락이 부딪치는 현상은 많이 수정되었다. 그러나 가운데가 너무 휑하고 남는 공간도 아깝다. 이럴 바에야 가운데 많이 쓰는 키의 폭을 넓게 잡는 것이 더 좋을 것 같다. 키의 빈도에 따라 차등폭을 적용해 보았다. 차례대로 11, 12, 13, 14%의 폭을 주었으며 양쪽이 50%씩 딱 맞아 떨어진다.

훨씬 더 보기에 좋다. 그러나 좌우 구분이 너무 안되고 꽉차 보인다. 중간에 조금이나마 여백을 넣는 것이 심미적으로 낳을 것 같아 2%의 여백을 넣었다.

보기에는 딱 좋다. 그러나 2% 여백 부분을 터치하면 무시당하는 예상 못한 문제가 발생했다. 키를 눌렀는데 무시 당하는 것은 오타보다도 더 문제가 심각하다. 그래서 여백없이 차등폭을 적용하는 방식을 채택하기로 했다. 실 사용해 보니 균등폭보다는 훨씬 더 입력이 편하다.

■ 한글, 영문의 Upper 상태에 키들을 대폭 비워 두었는데 이는 다른 언어를 위한 배려 때문이었다. 글자 개수가 더 많은 나라들은 Upper 상태에도 문자를 배치해야 하기 때문이다. 과연 얼마나 더 많은 키가 필요한지 대충 조사해 보았다.

- 한국어 : 경음을 위해 4개의 키가 더 필요하다.

- 영어 : 빈도가 떨어지는 zqxj 키 4개가 더 필요하다. 우연의 일치겠지만 한국어와 필요한 키 개수가 같다.

- 독일어 : 알파벳 26자 외에 A, O, U 움라우트와 에스체트 4글자 영역이 더 필요하다. 제 2 외국어로 독일어를 공부해서 이건 좀 안다.

- 프랑스어 - e 위에 어포스트로피가 있는 괴상한 문자와 c 아래에 꼬리가 달린 문자가 있는 듯 하다. 몇개인지는 모르겠지만 아뭏든 꽤 여러개가 있다.

- 스페인어 - n위에 물결이 있는 모양 등 총 16개의 문자가 더 필요하다. 대부분 기본 알파벳에 액센트 기호가 추가된 정도라 별도의 키를 다 할당할 필요는 없을 것 같으며 accent 키 등으로 해결할 수 있을 듯 하다.

그 외 아랍어나 태국어 같은 문자들까지 연구해 보면 실제 필요한 키 개수가 훨씬 더 많을 것 같다. 일본어만 해도 한글 자모보다는 훨씬 더 많은 문자가 필요하다. 중국어는 더 말할 것도 없고 말이다.

모든 언어를 다 고려할 필요는 있지만 과연 한국, 미국 사람들에게 이 영역을 비워 놓는 것이 합당할까 하는 생각이 들었다. 한국 사람이 프랑스어를 자주 입력할 일이 없고 미국 사람들도 독일어를 입력할 일이 많지 않다. 그렇다면 Upper 영역에 최대한 많은 기호를 집어 넣는 것이 이 사람들에게 유리할 것이다. 그러나 이렇게 되면 다른 나라 언어의 문자는 기호키를 넣을 자리가 없다는 문제가 생긴다.

그래서 타협안으로 생각한 것이 가장 많이 사용하는 구두점인 .,"()? 여섯개만 자리를 고정하고 나머지는 Upper 상태에도 넣고 숫자의 Page2에도 중복 배치하는 것이다. Upper 문자가 작은 한국, 미국은 모든 기호를 편하게 입력할 수 있어서 좋고 Upper 문자가 많은 나라는 이 기호 영역에 다른 문자를 할당해도 Page2에서 문자를 입력할 수 있으므로 문제될 것은 없다. 물론 불편하지만 그것은 문자가 많은 자기 나라 사정이니 어쩔 수 없다. Upper 키를 다음과 같이 배치했으며 숫자 키보드도 약간 바뀌었다.

중앙열의 ",.()?는 일단 고정이고 나머지는 빈도에 따라 배치했다. 영문 Upper도 동일하다. 이 외에 {}[]<> 등의 괄호와 +-*/_` 등의 문자는 숫자 모드의 Page1에 있다. 따라서 표준 키보드에 있는 모든 기호들을 Upper나 숫자 키에서 입력할 수 있다. 사실 하나가 남는데 .의 경우 마침표로 사용되므로 Upper에도 있고 소수점으로도 사용되므로 숫자에도 있어 중복 배치되어 있다. 숫자 Page2는 다음과 같다.

Upper 상태의 비고정키들이 같은 위치에 배치되어 있으며 화폐 단위를 나타내는 기호들과 물음표 뒤집은 모양도 배치했다. 나머지 중앙의 영역은 빈도가 높은 기호를 위해 일단 비워 두었다. 차후에 표준 키보드의 문자 외에 자주 사용하게 될 문자를 여기다 배치할 것이다. Page3, 4는 다음과 같다. Page2가 중복된 문자를 가지게 됨으로써 이모티콘들을 위해 페이지를 하나 더 늘렸다.

이 페이지에 배치할 문자는 사실상 꼭 고정할 필요는 없으며 페이지 수도 얼마든지 조정할 수 있다.

■ 숫자 페이지의 Prev 버튼을 없애고 Next 버튼 하나만으로 순환하도록 했다. 앞뒤로 이동하는 경우보다 그냥 페이지를 바꾸는 것이 더 단순하다. 또한 Prev 버튼이 있으면 한글 Upper 상태에서 표준 기호 딱 하나를 넣을 자리가 부족하다는 것도 이유이다. 가장 빈도가 떨어지는 어포스트로피를 Page2에 배치했었는데 너무 모양이 안 좋은 것 같아 Prev를 없앴다.

Next 버튼은 현재 페이지를 캡션으로 보여 준다. 모바일 환경에서는 어차피 눈으로 보고 기호를 고르므로 문제되지 않는다. 데스크탑 환경에서는 사실 Page2로 갈 이유가 거의 없다. 혹시 갈 이유가 있다면 Next 버튼에 팝업창을 여는 기능을 작성하여 목록에서 기호를 고를 수 있도록 할 예정이다. 데스크탑은 물리적인 키보드의 캡션을 바꿀 수 없으므로 사실 이렇게 해야 한다. 만약 정 자주 입력하는 문자가 있다면 사용자 정의키에 할당할 수도 있다.

■ 편집 키보드에 RCtrl, RAlt 키를 넣었다. 표준 키보드에 Ctrl, Alt가 양쪽에 2개 있고 각 키의 스캔 코드가 다르므로 이 키도 입력 가능해야 한다. Esc와 Tab을 좀 더 접근성이 좋은 위치로 옮기고 그 자리에 2개의 키를 넣었다.

VirtualBox 등의 특수한 프로그램과 게임 등이 이 키를 사용하므로 표준 키보드로 가능한 모든 입력이 일단은 가능해야 한다. 너무 완벽을 기하는 것이 아닌가 싶기도 하지만 자리가 남으니 일단 채워 넣었다.

12년 5월 25일

데스크탑용 키보드 개발로 돌아오기 위해 몇년만에 비주얼 스튜디오를 설치했다. 이클립스만 쓰다가 비주얼 스튜디오를 오랜만에 쓰니 무척 어색하다. 이것 저것 생각해 보니 아직도 키 배치는 물론이고 키 개수조차도 확정하지 못한 상태이다. 고민, 작업, 테스트, 검증 등 갈길이 한참 멀다.

■ 프로젝트의 이름을 일괄 수정하기로 했다. 최초 프로젝트가 한손 자판이다 보니 프로젝트명이 HanSon이었는데 지금은 맞지 않다. 프로젝트는 그대로 두고 실행 파일명만 Anerim으로 바꿔서 사용했는데 여러 가지 문제가 생기고 운영체제별로 모든 프로젝트 이름이 Anerim이다 보니 헷갈린다. 다음과 같이 수정한다.

AnerimExercise - 윈도우용 아너림 키보드 연습 프로그램

AnerimKeyboard - 안드로이드용 아너림 글판 앱

AnerimDriver - 윈도우용 키보드 후킹 프로그램

비주얼 스튜디오 최신 버전으로 프로젝트를 새로 만들었다. 나머지는 키 배치를 확정한 후 수정할 것이다. 그리고 한손 키보드 관련 기능은 일단 모두 제거하기로 했다. 두손만 해도 복잡해 죽겠는데 한손까지 같은 프로젝트에 있으니 머리가 정말 아프다. 이전 실행 파일이 있으니 기획 의도는 살펴 볼 수 있으며 두손을 완성한 후 차후 따로 프로젝트를 만들기로 한다.

■ BS와 Num 키를 따로 넣을까 생각해 보았다. 모바일 버전에 BS 키를 막상 넣어 보니 Upper + Space보다는 분명 편리하고 BS 키의 빈도가 다른 어떤 키보다도 결코 낮다고 볼 수는 없다. 또한 Upper는 언어 입력을 위한 키이며 모든 언어에 필수적으로 존재하지도 않으므로 BS 조합키로 쓰기에도 부적합하다.

Num 키의 경우도 Mode키를 더블 푸시하는 방식보다는 별도의 키가 있는 것이 더 편리함은 물론이고 초보자가 보기에도 직관적이다. 더블 푸시가 좋은 방법이기는 하지만 자주 쓰기에는 불편하다. 그림을 그려 보면 다음과 같다.

엄지 손가락의 홈 포지션은 Space와 Mode이며 좌우로 까닥거려 키를 조작한다. 홈 포지션은 폭을 조금 크게 하고 나머지는 일반 문자키와 같은 크기이다.

이 경우 엄지 손가락이 3개의 키를 담당해야 하므로 엄지의 부담이 늘어난다는 면에서는 바람직하지 못하다. 또한 아래열에 이 키들을 넣을만큼 충분한 면적을 확보해야 한다는 부담이 있는데 좌우키를 적당히 띄울 것이고 인체공학적으로 약간 기울일 생각이라 가능은 할 것 같다.

■ 자판의 배치는 고정이라도 장비에 따라 필요한 키의 개수는 다르다. 데스크탑은 펑션키와 CASW키가 반드시 필요하지만 모바일에는 필요가 없다. 일관성도 중요하지만 장비의 특성에도 맞출 수 있어야 하고 더 넓은 면적이 허락된 경우에는 확장도 가능해야 한다. 그래서 필요한 키의 레벨을 설정하고 상황에 맞게 선택할 수 있도록 한다.

- Compact - 모바일을 위한 30키만 배치한다. 정확하게 손가락당 3개씩이며 이 영역에 문자를 입력 및 편집한다. 문자 입력 및 간단한 편집만 가능하다.

- Standard - 펑션키 및 CASW 키 12개 추가하여 42키 배치. 거의 모든 입력 가능하다. 개발이나 문서 편집 등의 단축키까지 고려하였다.

- Extended - 커서 이동 및 매크로 키 3개 추가하여 54키. 확장 기능까지 가능하다.

다음은 풀 배열인 Extended로 키를 배치해 본 것이다.

총 54키이며 웬만한 미니 키보드의 부피가 느껴진다. 이 중 오른쪽의 편집 및 매크로 키는 옵션이므로 제거 가능하다. 실제로 이 키가 없어도 Standard만으로도 모든 편집이 가능하므로 연습 프로그램에 이 키를 둘 필요는 없을 것 같다. 위쪽의 펑션키와 아래쪽의 CASW키도 모바일에서는 옵션이며 없어도 무관하다.

CASW키를 양손 새끼 손가락 위치에 배열하여 기존 키보드와 유사하게 배치했는데 아래열이 너무 번잡스러워 보인다. 아예 왼쪽에 Ctrl, Shift, Alt, Win 순으로 수직으로 따로 한 열을 구성하는 방법도 고려해 봤는데 나쁘지는 않은 것 같다.

오른쪽의 확장키 때문에 중앙에 맞지 않는 문제가 있는데 대칭을 위해 왼쪽 변에도 5행짜리 매크로 키를 배치할까 생각해 보았다. 매크로는 사용자가 임의로 정의할 수 있는 키이며 확장키에 이미 3개가 있고 Num 모드에서 F1~F8도 매크로로 사용할 수 있다. CASW와 매크로키 4개를 왼쪽에 2열로 놓는 방식도 괜찮아 보이는데 일단은 적용해 보지 않았다.

엄지에 3개의 키가 할당됨으로써 중앙에 빈 여백이 많이 생기는데 차후 이 영역에는 터치 패드를 삽입해도 될 듯하다. 그러기에는 좀 좁아 보이고 또 터치 패드는 팜레스트 중앙이 제자리인 것 같아 이것도 일단은 적용해 보지 않았다.

■ 편집 모드의 커서 이동키와 확장 키의 커서 이동키에 대한 배치는 다음 두 가지 방식을 생각할 수 있다.

두 방식의 장단점은 다음과 같다.

왼쪽 방식 : 오른손의 홈 포지션이 커서 이동키에 있으므로 Edit 홀드 다운 상태에서 손가락 이동없이 커서 이동이 편리하다. 그러나 PgUp, PgDn과 Home, End 등 쌍으로 사용되는 키가 떨어져 있어 불편하다.

오른쪽 방식 : 이동하려면 손가락을 아래로 일단 내려야 한다는 면에서 불편하지만 PgUp, PgDn과 Home, End 키들이 아래위로 인접해 있어 편리하다. 표준 키보드의 편집키와도 일치한다.

즉, 이 두 방식은 커서 이동을 더 자주 하는가 아니면 페이지 단위 이동을 더 자주하는가에 따라 선택되어야 할 문제이다. 지금까지는 커서 이동이 더 중요하다고 판단하여 왼쪽 방식을 선택했는데 확장키의 도입으로 인해 통일이 필요해져 오른쪽 방식으로 바꾸기로 한다. 기존 키보드의 확장키가 오른쪽 방식과 유사하게 되어 있고 확장키로 손이 갈 때 자연스럽게 아래쪽에 손가락이 맞춰지기 때문이다.

■ 연습 프로젝트 소스 정리. 여러 자판을 지원하다 보니 소스 구조가 정말 복잡함. 직접 만든 거지만 3년전에 작성했던거라 기억도 잘 안나고 가독성도 심하게 떨어진다. 한손 자판 모두 들어 내고 옵션도 최대한 자재하여 관리 가능하도록 거의 다시 작성했다. 특히 유연한 키 배치를 위해 자료 구조에 특히 많이 신경썼다.

■ 영문 Upper 상태에서 Capital 키가 누락되었음을 발견했다. 대문자 Z를 입력하려면 Capital을 먼저 누르고 Upper를 눌러야 하며 반대로는 입력할 방법이 없다. 한글 Upper 상태에는 이 자리에 \가 들어 있는데 영문 Upper와 맞추기 위해 이 자리를 비워야 한다. 그렇다고 한글 Upper 상태에 아무것도 두지 않을 수는 없어 빈도가 떨어지는 `를 배치했다. \는 ^ 자리로, ^은 | 자리로, |은 Num 1페이지의 `자리로 빈도에 따라 재배치했다. Num 2 페이지의 a 자리에도 `를 배치하여 한글 Upper 상태와 동기화하였다.

■ 연습 프로그램의 키보드 디자인을 다소 변경하였다. 색상도 좀 넣어 보고 캡션도 한글로 바꾸었다. 확장 구성의 편집키는 어차피 옵션이므로 연습 프로그램의 키 배치는 Standard로 작성하기로 한다. 키의 캡션을 현재값만 표시하고 Upper나 Capital 상태가 되면 캡션을 변경한다. 실제 키보드에서는 모든 캡션을 한꺼번에 표시해야 하지만 소프트웨어이므로 이것이 가능하다.

■ 데스크탑에서 수정한 사항을 다시 안드로이드 키보드로 옮겼다. 프로젝트 이름을 AnerimKeyboard로 바꾸고 4.0.3 기반으로 버전을 올렸다. 2.3과 특별히 기능상의 차이는 없지만 이후에는 4.0.3이 거의 표준이므로 이 버전으로 계속 개발하는 것이 좋을 듯하다. 제일 아래열에 Num 키를 추가 배치했다. 삭제키가 따로 있으므로 Upper + Space 기능은 제거했다. 키의 캡션도 보기 좋게 한글로 수정했다.

공백이 중앙이 아니라 좀 불만스럽기는 하지만 딱 네모지게 생겨서 안정감 있어 보인다. 4.0.3은 디폴트 에뮬레이터가 화면 키보드를 지원하지 않아 실장비로만 테스트해 볼 수 있다는 점에서 다소 불편하다.

12년 5월 26일

■ 글자 통계 기능의 버그 수정. 영문이 대문자 기준이었는데 소프트웨어적으로 캡션을 보여주는 방식으로 바꿈으로 인해 키값이 소문자가 되어 영문 통계를 잘못 뽑는 문제가 있었음.

■ 모드 전환 방식에서 문제를 발견. 숫자나 편집 모드에서 이전 모드로 돌아가도록 했는데 그러다 보니 이 상태에서 한영 버튼을 누르면 한글이나 영문이 아닌 모드가 되기도 한다. 예를 들어 한글-숫자-편집 모드로 전환했다면 편집 모드 전환시 이전 모드를 숫자로 기록해 두는데 이 상태에서 한영 버튼을 누르면 숫자 모드로 가 버린다. 한영 버튼은 한글이나 영문으로만 돌아오는 것이 맞을 것 같다.

편집, 숫자 모드로 전환시 이전 모드가 한글이나 영문이 아니면 PrevMode에 기록하지 않도록 했다. 그러나 편집, 숫자키를 홀드 다운한 상태에서 입력했거나 편집, 숫자키를 눌러 전환할 때는 정확한 이전 모드로 복귀해야 하므로 PrevEdit, PrevNum 변수는 여전히 필요하다. 숫자 상태에서 홀드 다운으로 잠시 편집했다가 다시 돌아오면 숫자 상태가 그대로 유지되어야 한다.

■ 안드로이드 키보드에 숫자 상태로 전환시 한글 조립이 풀리지 않는 버그가 있어서 수정함. 그리고 비록 간단하지만 아이콘 달아 줌. 뽀샵으로 회색 바탕에 아자 하나 그려 넣었는데 최소한 기본 아이콘보다는 더 낫다. 차후에 전문 디자이너에게 예쁘게 그려 달라고 부탁해야겠다.

귀찮아서 72*72 크기의 hdpi 밀도로 하나만 만들었다. 키보드는 서비스라 아이콘이 보이지 않지만 마켓이나 앱 목록에는 보이므로 최소한 알아볼 수 있게는 만들 필요가 있다.

■ 키 개수와 동작이 대충 정의되어 이제는 키 배치가 신경 쓰이기 시작했다. 우선 아래열의 격음들과 ㅆ의 위치가 거슬리는데 자음이 오른손에 있다 보니 좌자우모의 원칙상 맞지 않다. 자음이 더 많아 모음 자리에 배치될 수밖에 없지만 연타가 많이 발생한다는 문제가 있다.

다쳐 - 오른손만 4연타

위치 - 오른손 4연타

둬쒀 - 5연타일 뿐만 아니라 오른손 중지만 5연타이다.

있었다. 했었다 - 오른손 2연타가 연거푸 발생한다.

연타가 많이 발생하므로 리듬감이 떨어지고 속도에도 불리하다. 그래서 뭔가 개선이 필요해 보인다. 이 글자들의 출현 빈도는 다음과 같다.

ㅆ : 1.32 ㅊ:0.65 ㅌ:0.45 ㅍ:0.41 ㅋ:0.18

ㅆ이 조금 높으며 격음들은 다 더해도 고작 1.6퍼센트밖에 안된다. ㅋ은 500타에 한번 나올 정도로 빈도가 낮은데 현재 왼손에 배정되어 있다. 아래 열을 다음 둘 중 하나로 바꿔 보면 어떨까 생각해 보았다.

ㅌㅊㅎㅅ ㅡㅆㅍㅋ : 빈도가 높은 글자를 최대한 왼쪽에. ㅌㅊ의 빈도가 격음중에는 가장 높으므로 왼손에 배치하면 리듬감이 살아날 듯 하다. ㅋ은 빈도가 가장 낮으므로 오른손 구석에 둔다.

ㅊㅆㅎㅅ ㅡㅌㅍㅋ : ㅆ 빈도가 가장 높으므로 왼쪽에 두었다. 그러나 솔직히 왼손 약지보다는 오른손 중지가 힘이 더 좋아 연타율에만 유리할 뿐이다. "있었다"의 경우 LRRLRR이 LRLLRLLR로 바뀔 뿐 왼손 연타는 여전히 발생한다. 2벌식 사용자들은 왼손 연타에 더 익숙하고 음절의 경계라 좀 덜 어색해 보이는 것 뿐이다.

이 외에 좌자우모의 원칙 고수를 위해 격음에 대한 별도의 조합키를 두는 방식도 생각해 보았다. 격음은 보두 ㅂㅈㄷㄱ에 획을 더한 것이므로 별도의 키를 두고 ㅂㅈㄷㄱ과 연이어 누르는 방법도 생각해 볼 수 있다. 배치를 그려 보면 다음과 같다.

영문의 Capital 자리와도 일치하여 일관성이 있다. 격음을 누르고 ㄱ을 누르면 ㅋ이 입력되는 방식이다. 일단 격음 위치를 보통음의 위치로부터 연상할 수 있으므로 외우기 쉽다. 키 3개가 남는데 이렇게 되면 빈도가 높은 ㅕ에 별도의 키를 더 할당하고도 2칸이 남는다. ㅆ을 왼쪽 새끼 손가락 자리로 옮기면 완전한 좌자우모의 원칙도 확보할 수 있다.

하나의 배치 방법으로 고려해 볼만 하지만 별로 적용하고 싶지는 않다. 사용 방법이 너무 복잡해지는 것 같고 격음키로 인해 왼손 연타율이 똑같이 높아지는 문제가 있다. 남는 두 칸도 마땅히 사용할 곳이 없다.

현재의 격음 배치는 좌자우모의 원칙보다는 손가락의 힘에 따라 배치한 것으로 딱히 나쁜 구조는 아니다. 그러나 연타율을 고려하면 약간 수정할 필요는 있는 것 같다. 제일 아래열만 다음과 같이 배치를 바꾸었다.

격음끼리 왼쪽으로 한칸씩 로테이트한 것이다. 이것이 기존 배치보다 꼭 좋다는 것은 아니지만 바꿔서 연습을 해 볼 필요가 있다. 차후 기존 배치가 더 좋다 싶으면 언제든지 롤백할 수 있다.

■ 모음 ㅜ와 ㅡ의 배치도 논란거리이다. ㅜ의 빈도는 2.5%이고 ㅡ의 빈도는 4.7%여서 거의 2배나 차이가 난다. 둘 다 치기 쉬운 자리에 배정되어 있어서 제자리를 정하기가 정말 애매하다. 다음과 같이 두 문자의 자리를 바꾸어 보았다.

아래 위의 ㅗ와 ㅜ가 대칭적이어서 외우기에 직관적이고 보기에 좋다. 그러나 ㅡ가 위로 올라간 구조는 2벌식과 맞지 않으며 "의" 같은 글자를 칠 때 굉장히 어색한 느낌이 든다. 특별한 이유는 없지만 아무래도 이 건은 적용하지 않는 것이 좋을 듯 하다. 자판 배치에는 정말 정답이란 없다. 어떻게 만들어도 기존과 다르면 불평이 나올 수밖에 없으며 손이 자리를 완전히 기억하기 전까지는 불편을 감수해야 한다.

■ 한글과 숫자의 키 배치는 대충 완료되었다. 그런데 기호가 Upper와 Num에 나누어져 있어 무척 불편하다. 예를 들어 12:30분 같은 문자열을 쓸려면 모드를 여러번 바꿔야 한다. 키 개수가 적다 보니 어쩔 수 없는 문제이다. 고생해서 만들어 놔도 보급하기 정말 어려울 것이다. 이 문제는 차후 더 심각하게 고려해 보되 욕심 내지 말고 천천히 하자.

■ 실제 사용감이 어떤지 조사해 보려면 나부터 익숙해져야 하고 그럴려면 2벌식을 버려야 하는데 글 쓰는 직업을 가진놈이 그러기가 어렵다. 쓸만한 시제품을 먼저 만들어야 할텐데 2벌식 키보드로 연습하기 정말 어렵다. 차후 갤럭시 탭이나 슬레이트 PC같은 터치가 되는 걸로 실제 사이즈와 배치를 만들어 봐야겠다. 키 피치와 기울어진 각도까지도 마음대로 조정할 수 있으니 시제품 만들어 보기 전에 꽤 좋은 테스트가 될 듯 하다. 돈은 못 벌고 자꾸 돈 쓸 일만 생긴다.

■ 더 계속하기 전에 일단락을 짓기로 한다. 기존에는 버전의 개념이 없었지만 이전 버전을 0.90으로 정의하고 오늘까지 작업된 결과를 0.91로 정의했다. 배치는 그렇다 쳐도 아직 전반적인 구조와 동작 방식이 결정되지 못했으므로 1.0으로 버전을 메길 수는 없다. 키 개수가 결정되면 1.0을 릴리즈할 것이다.

오늘까지 작업한 결과를 홈 페이지에 올리고 안드로이드 버전은 소스도 공개하였다. 나도 샘플 소스의 도움을 받았으므로 누군가 키보드 제작에 관심이 있는 사람에게 조금이나마 도움이 되었으면 좋겠다는 뜻이다. 아직 완성된 소스는 아니지만 적어도 기법을 살펴 보는 정도에는 좋은 참고 자료가 될 것이다. 실행만 해 볼 사람은 bin 폴더의 apk 파일만 빼서 adb로 설치해서 사용해 보기 바란다. 설정에서 키보드를 Anerim으로 바꿔 주면 바로 사용할 수 있다. 소스에는 오토마타 구현에 관련된 주석을 나름대로 상세하게 작성해 두었다.

이후에도 키 배치에는 상당한 변화가 예정되어 있다. 자주 바뀌므로 안드로이드 버전은 당분간은 개발하지 않고 PC 연습 프로그램만으로 개발을 진행할 것이다. 두 가지를 동기화하려니 무척 어렵다.

12년 5월 28일

0.91버전을 릴리즈했으니 오늘부터는 당분간 기획만 하기로 했다. 생각이 떠오를 때마다 즉석으로 코드를 작성하고 테스트를 해 보니 시간도 오래 걸릴 뿐만 아니라 처음 생각했던 것이 터무니없는 것이거나 나중에 새로 나온 기획에 의해 덮여 버리는 문제가 있다. 즉, 헛수고를 많이 하고 있는 셈이다.

0.92버전은 오랫동안 장고를 한 후에 작성할 기능 목록을 만든 후 일괄적으로 코딩을 해서 테스트해 보기로 한다. 0.91 버전도 여러 가지 면에서 마음에 안드는 면이 많은 걸로 봐서 이 프로젝트는 아직도 한참 초반인 것 같다. 갈 길이 정말 멀다.

■ Num 키보드의 Pg1 키는 제거한다. 이모티콘은 모바일을 위해서는 꼭 필요하지만 데스크탑 환경에서는 굳이 필요치 않다. 설사 필요하다 하더라도 페이지 전환키를 문자키 중간에 둘 것까지는 없으며 보기에도 상당히 좋지 않다. Pg1키를 제거하면 `까지 Num 페이지에 모두 포함되므로 표준 키보드의 문자가 다 들어온다.

물론 이모티콘 자체는 꼭 필요한 기능이다. 모바일에서는 Num 키를 더블 푸시하여 이모티콘 모드로 전환하여 입력받을 수 있다. 데스크탑에서는 키보드 자체에 각인이 없으므로 페이지를 전환하는 것이 별 의미가 없고 대화상자나 별도의 문자표를 열어서 입력받는 방식이어야 한다.

■ 제일 윗열에 있는 펑션키가 눈에 거슬리기 시작했다. 이건 있는 것도 아니고 반토막짜리라 영 마음에 들지 않는다. 우선 펑션키 12개를 다 배치하는 것이 어떨까 하는 생각이 들었다. 이유는 다음과 같다.

- F9~F12까지를 Edit키와 함께 누르는 것이 무척 불편하다.

- 데스크탑 환경에서 키의 개수는 중요한 문제가 아니다.

- 문자키가 8열이지만 좌우를 벌리고 기울이기까지 하므로 위쪽에 공간이 있다.

- 멀티미디어 등의 확장 기능을 더 많이 배치할 수 있다.

- Num 키와 함께 사용하는 매크로도 12개나 정의할 수 있다.

대충의 배치를 그림으로 그려 보면 다음과 같은 모양이 나온다. 문자키를 벌리고 약간 기울일 것이므로 폭은 적당한 편이다. 표준 구성이 이렇고 확장 구성일 경우는 오른쪽에도 편집키가 들어가므로 거의 미니 키보드 수준이 된다.

키 개수가 46개로 늘어난다는 점은 다소 불만스럽다. 펑션키는 문자 입력중에 누르는 키가 아니고 컴파일이나 검색, 옵션 편집 등을 위해 주로 한손으로 누르므로 접근성이 좋아야 한다. 펑션키 개수는 좀 더 고민해 보되 아예 빼거나 넣을려면 12개를 다 넣어야 한다는 생각이다.

다음은 최초의 기획처럼 펑션키를 아예 빼는 방안에 대해 생각해 보았다. 별도의 Fn 키 하나를 배치하고 모드를 도입하면 키 11개를 줄일 수 있다는 유혹을 뿌리치기가 무척 어렵다. 이렇게 되면 표준 구성이 35키가 된다. 일반 사용자 입장에서는 몰라도 개발자 입장에서 펑션키의 사용 빈도가 결코 낮다고 볼 수 없어 고민스럽지만 일단 기획일 뿐이므로 제거 방안도 생각해 보자.

불편함을 감수하고 키의 개수를 줄이는 것이 과연 의미가 있을까 하는 생각이 든다. 데스크탑이나 노트북에서는 키의 개수가 중요치 않지만 휴대용 컴퓨터에서는 이 차이도 결코 무시할 수 없다. 한 두개가 아니고 무려 11개의 키를 줄일 수 있으니 말이다. 실제 판매하는 키보드중에도 해피해킹같은 경우에 펑션키가 없는 채로 출시되어 있으며 사용하는 사람들이 별 불평없이 쓰고 있기도 하다.

또 삼돌이식 키를 사용할 경우 거의 절반 이하로 줄어드는 듯한 느낌이 날 것이다. 펑션키를 위한 별도의 키가 따로 없으므로 Fn 키를 하나 더 추가해야 하며 이때 Fn키의 동작은 다음과 같이 정의한다.

푸시 : 기능이 없다. 쿼티의 Shift키와 마찬가지로 누르고 있을 때만 동작한다.

홀드 : Fn 모드를 적용한다. 놓으면 물론 원래 모드로 돌아간다.

더블 푸시 : Fn 모드로 전환한다.

펑션 모드일 때 문자키는 다음과 같이 키를 배정한다.

양손으로 누르기 편해야 하므로 Fn키가 왼쪽에 있을 경우 펑션키는 오른쪽에 있어야 한다. 좌에서 우로 위에서 아래로 순서대로 배치했다. 반대편에는 멀티미디어나 웹 브라우저의 키를 넣어둘 수 있으며 이중 일부는 사용자 정의도 가능하다. 만약 Fn키가 오른쪽에 있다면 키의 좌우 배치도 바뀌어야 한다.

그렇다면 Fn키는 과연 어디다 배치할까. 펑션키는 문장 편집중에 자주 누르는 키가 아니므로 제자리 원칙을 지킬 필요는 없다. 자세가 흐트러지더라도 누르기 편하고 모양이 그럴듯한 곳에 배치하면 된다. 다음과 같은 여러 가지 배치를 생각해 보았다.

① 문자키 왼쪽에 CASW키와 함께 배치한다. 문자 입력 영역이 심플해지는 효과가 있고 Ctrl키와 펑션키의 조합 입력이 용이하며 위쪽의 남는 공간에 Esc도 배치할 수 있다. 그러나 모양은 별로 예쁘지 않다.

차후 삼돌이 키와 기울임등을 고려하면 이 방식이 괜찮은 것 같다. 또 오른쪽에 확장키를 둔다면 문자키가 중앙으로 와 좌우 균형에도 유리하다.

② CSAW는 그대로 두고 Fn키만 왼쪽 바깥에 따로 빼 놓는다. 기능상의 문제는 별로 없어 보이지만 모양이 예쁘지 않고 혼자 외로워 보인다.

CS키 오른쪽에 약간의 공백을 활용하여 중간에 끼워 넣어 볼까 싶기도 하지만 그러면 Ctrl 키가 너무 바깥으로 삐져 나갈 것 같다. Ctrl이 왼손 새끼 손가락에 걸리는 것이 딱 좋다.

③ 가운데 빈 영역을 활용하여 중앙에 놓는다. 모양은 그럭 저럭 봐 줄만한데 Ctrl키와 멀리 떨어져 있기 때문에 Ctrl + F12 같은 조합키를 누르기가 골때린다. 중앙 영역에 터치 패드를 놓겠다는 생각과도 충돌이 발생한다.

④ Win 키를 제거하고 오른쪽에 Alt Fn 순으로 배치한다. 이 경우 펑션키들은 왼손으로 이동해야 한다. 사실 Win키는 임의로 추가된 조합키이며 필수키는 아니라 생략할 수 있는데 이러면 아쉬워하는 사람들이 많을 것이다. 또 Ctrl과 Fn의 거리가 너무 멀어 양손으로도 세 개 이상의 키를 누르기가 쉽지 않다.

⑤ 키를 늘리지 말고 Enter키 자리에 Fn 키를 배치하는 것은 어떨까. 개행은 Upper+Space에 기능을 부여하면 된다. 일단 모양은 제일 좋다. 그러나 Upper가 모든 언어의 공통키가 아니라는 문제가 있고 Enter의 빈도도 결코 낮지 않으며 초보자가 보기에 비직관적이라는 문제가 있다.

Ctrl + Shift + F1 식으로 누르는 조합키가 있어 CSF는 어쨌거나 떨어지기 어려운 키이다. 정말 마땅한 배치가 떠오르지 않는데 현재로서는 2번이 가장 나아 보인다. 더 고민해 보자.

펑션키를 꼭 없애야만 하는 것은 아니다. 구성에 따라 펑션키를 없앨 수도 있고 따로 배치할 수도 있다. Standard 구성에 Fn 키를 두고 펑션키를 옵션으로 장착하는 중간 구성을 새로 하나 더 만들면 될 듯하다. 펑션키가 따로 있더라도 Fn키는 그대로 둘 생각이다. 별도의 키가 없어도 펑션키 입력이 가능하다는 것을 보여주기 위해서이고 멀티미디어나 브라우저 키의 기능도 사용할 수 있기 때문이다.

■ 한영 키보드는 대충 됐다 치고 숫자, 기호키의 입력 편의성에서는 아직 많이 부족해서 근본적인 수술이 필요하다. 현재 키 개수와 제자리 원칙을 지키는 범위내에서 다양한 변형을 시도해 보고자 한다. 표준 키보드의 문자, 기호의 개수는 다음과 같다.

숫자 : 10개

Shift + 숫자 : 10개

기호키 : 11개

Shift + 기호키 : 11개

알파벳과 기능, 편집키를 제외한 기호키가 총 21개가 있고 각각 Shift에도 문자가 정의되어 있으므로 총 문자 개수는 42개인 셈이다. 이 기호들은 현재 다음과 같이 나누어져 배치되어 있다.

영문 Upper : 18개(한글에는 `포함 19개)

숫자 : 25개(Pg1 제거하고 공백의 0까지 합쳐서)

총 43개의 문자가 배치되어 있는 셈인데 이 중 마침표는 Upper에도 있고 소수점 형태로 Num에도 중복되어 있다. 결국 42개의 모든 기호가 빈틈없이 빽빽하게 배치되어 있는 셈이다.

일단 여유가 너무 없어 유로같은 자주 쓰는 특수 기호를 포함할 공간이 전혀 없으며 자소가 더 많은 다른 언어를 고려하지 못했다. 차라리 빈칸이 좀 있더라도 여유가 있는 편이 더 나을 듯 하다. 모드 변환키가 왼쪽에 있으므로 왼쪽에 빈칸을 많이 두는 것이 좋다.

더 심각한 문제는 기호들이 2페이지에 흩어져 있다 보니 프로그래밍 코드처럼 마구 섞인 문장을 입력할 때 심하게 불편해진다는 점이다..

a = b.c + ~d;

공백은 빼고라도 문자, 숫자, 문자, Upper, 문자, 숫자, Upper 문자 Upper 순으로 모드를 계속 바꿔 가며 타이프해야 한다. 더 복잡한 예도 얼마든지 들 수 있다. 여러 가지 문제점들을 발견할 수 있다.

- 원하는 기호가 Upper에 있는지 숫자에 있는지 먼저 판별을 하고 Upper나 Num키를 눌러야 한다. 이 문제는 손가락이 완전히 외우기 전까지 불편할 수밖에 없다.

- Upper는 자동 복귀 방식이고 Num은 홀드 다운 방식이라 동작이 무척 헷갈린다. 그렇다고 Num 누른 후 기호 입력하고 다시 Num 누르면 너무 느리다.

- Num키 홀드 다운의 경우 숫자는 좌우 손이 달라 편하지만 왼쪽키는 왼손 엄지와 왼손 다른 손가락을 같이 눌러야 하므로 자세가 불편하다.

이 문제는 정말 근본적인 해결책이 없다. 키의 개수가 24개에 불과하므로 키 개수를 더 늘리지 않는 한 42개나 되는 기호를 하나의 모드에 다 구겨넣을 방법이 없는 셈이다. 뭔가 획기적인 해결 방안을 위해 많은 고민이 필요하다. 몇일간에 걸쳐 코드는 작성하지 않고 여러 가지 방안에 대해 기획해 보았다. 기호들을 하도 이리 저리 옮겨 다녀야 하므로 아예 기호들을 딱지로 만들어 책상 위에서 배치했다.

맨날 종이에 써서 배치하다 보니 속도도 느리고 실제 배치 모양을 볼 수 없었다. 또 무슨 기호가 빠졌는지 맨날 찾아야 했는데 이 방법을 사용하니 개수와 종류가 명확하므로 다양한 시도를 해 볼 수 있어서 좋았다.

방안1

현재 구현도 익숙해지기만 한다면 그리 나쁜 방법은 아니다. 모드가 2개밖에 없어 익숙해지면 충분히 쓸만하다. Num 모드에 Pg1 키 대신 `만 넣어도 일단 모든 문자 입력이 가능은 하다. 골격은 유지하고 키의 배치만 조정하는 방법을 생각해 볼 수 있는데 앞서 언급한 단점들이 있다.

방안2

기호들만 모아서 별도의 Symbol 페이지를 하나 더 만든다. 대부분의 기호들을 하나의 페이지에 배치하면 덜 헷갈릴 것이다. 이를 위해서는 기호들을 용도에 따라 분류할 필요가 있다. 기호들은 다음 3가지로 분류된다.

구두점 6개 : .,"'?! 등 주로 문장과 함께 사용하는 구두점은 Upper에 배치

숫자 12개 : 0~9까지 10개 및 + -

기호 : 나머지 24개의 문자 배치

42개가 딱 맞게 배치된다. Upper 페이지의 배치는 다음과 같다.

꼭 필요한 구두점 6개만 배치하고 나머지는 타 언어를 위해 비워 두었다. 주로 문장 입력중에 사용하는 기호들이므로 외우기 쉽고 Upper와 함께 입력하기에도 편리하다. Upper가 오른쪽에 있으므로 연타 방지를 위해 왼쪽에 4개를 배치했다. 다음은 Num 페이지이다.

Num키가 오른쪽에 있으므로 숫자와 소수점, + - 를 모두 오른쪽에 배치했다. 소수점은 Upper 페이지와 여전히 중복이다. 공백 자리를 0으로 사용하는 방식은 차후 논란거리가 될 가능성도 있지만 빈도가 높으므로 특별한 예외를 계속 인정하기로 했다. 왼쪽 영역은 일단 비워 두되 사용자 정의 문자를 넣을 수 있도록 하면 될 듯 하다. 비워 두기는 뭣하므로 일단 디폴트 문자로 화폐 기호들을 채워 보았다. 다음은 Symbol 페이지이다.

오른쪽이 더 누르기 편하므로 오른쪽에 자주 쓰는 문자를 배치했다. 확정적인 것은 아니고 [ ] 괄호와 < > 괄호 정도는 바꿀 수 있다. C 개발자는 [ ] 괄호가 더 요긴하지만 웹 개발자는 < > 괄호의 자리가 너무 구석이라 불만일 듯하다. 배치는 앞으로도 한참 더 고민해야 할 문제이다.

새로 추가된 기호 모드를 위해 모드 변환키의 동작을 수정한다. 새로 키를 하나 더 만들 수는 없으므로 기존 키들을 잘 활용해야 한다. 엄지는 3개 이상의 키를 감당할 수 없다. 기호의 수가 더 많고 복잡하므로 좀 더 편의성을 줄 필요가 있다. Num 키를 Sym 키로 이름을 바꾸고 기호를 입력하는 용도로 사용한다.

키	푸시	홀드 다운	더블 푸시
Sym	기호 입력 후 복귀	기능 없음	기호 모드 전환
Mode	한영 전환	숫자 입력	숫자 모드 전환
Edit	편집 모드 전환	편집 입력	이모티콘 기능

Sym 버튼은 Upper나 Capital 키와 마찬가지 방식으로 동작하며 기호 하나를 입력하면 원래 모드로 자동 복귀하도록 했다. 기호를 연속으로 입력하는 경우가 흔치 않으므로 하나 입력한 후 원래 모드로 돌아 오는 것이 속도가 빠르다. 연타 방지를 위해 자주 쓰는 기호를 오른쪽에 배치해 두었으므로 리듬감도 있다.

숫자는 이전 방식대로 Mode키로 다시 옮겼다. 오른쪽에만 숫자가 있으므로 홀드 다운 상태로 입력해도 크게 불편하지 않다. 더블 푸시해서 숫자 모드로 바꿀 수 있지만 숫자만 왕창 입력하는 경우가 많지 않으므로 그럴 필요가 별로 없을 것이다. 숫자는 여러 수를 한꺼번에 입력하는 경우가 많으므로 자동 복귀 기능을 넣지 않았다.

만약 이 키보드가 한글을 지원할 필요가 없는 미국에서 사용된다면 이 경우 Mode키는 숫자와 영문 사이를 토글하며 더블 푸시는 지원할 필요가 없다. 드라이버의 옵션에 지원 언어 개수를 선택받고 하나이면 이 방식대로 동작하면 되고 2개이면 언어 토글 방식으로 동작하면 될 듯하다.

Edit의 더블 푸시는 모바일을 위한 이모티콘 전환 기능으로 사용한다. 모바일에서는 키보드를 바꾸되 데스크탑에서는 별도의 팝업 창을 띄우는 방식이 나을 것 같다. 꽤 오래 고민한 끝에 기획해 본 방식인데 장단점을 따져 보면 다음과 같다.

장점 : 구두점과 숫자 등만 제외하고 모든 기호가 Sym 모드에 있으므로 덜 헷갈린다. Upper 영역을 많이 비워 두어 다른 언어를 위한 여유가 생겼으며 Num의 왼쪽에도 공간이 생겼다.

단점 : 모드가 하나 더 생겨 복잡도가 증가하였다. 그러나 기호 분류가 합리적이어서 익숙해지면 최소한 헷갈리지는 않을 것이다. 아무 문자도 없는 빈칸이 존재한다는 것도 약간 마음에 안든다.

추가 : 늦게 떠 오른 생각인데 Num 모드의 왼쪽은 접근성이 좋지 않아 키가 많이 남는 상태이다. 비워두는 것보다는 공백과 쉼표 등을 중복해서 배치해 놓는 것이 숫자 입력에 유리하지 않을까 싶다. 공백키 자리에 숫자 0을 할당한 점은 좀 어색하지만 넘패드의 구조와 같고 숫자 0의 중요도로 볼 때 당연하다. 그러나 숫자 입력중에 쉼표와 공백을 입력하기 불편하므로 왼손의 가운데열 집게와 중지에 각각 공백과 쉼표를 할당하는 것이 좋을 듯 하다.

방안3

12개나 되는 펑션키를 적극적으로 활용한다. 펑션키에 기호들을 배치하면 모드를 추가하지 않고도 Num 모드에 모든 기호를 구겨 넣을 수 있다.

가용한 키의 개수 : 문자 24 + 공백 1 + 펑션 12 = 37개

Upper에 구두점 6개 배치, Num에 나머지 36개 및 소수점 중복 배치

Upper의 배치는 방안2와 동일하며 Num 모드의 배치는 다음과 같다. 물론 이것도 어디까지나 초안 배치일 뿐이다.

숫자는 여전히 오른쪽에 있고 왼쪽에는 자주 쓰는 기호들, 펑션키에는 빈도가 떨어지는 기호들을 배치했다. 이때 Num 키의 동작은 다음과 같이 정의한다.

푸시 : 하나 입력 후 복귀한다. 기호일 경우는 편리한데 숫자일 경우는 다소 불편할 수도 있지만 이 경우는 홀드 다운을 사용하면 된다.

홀드 다운 : 입력 후에 복귀한다.

더블 푸시 : 숫자 모드로 전환한다.

이 방법의 장점은 모드가 2개로 줄어 들어 구두점만 제외하고는 모두 Num에 있으므로 고민할 필요가 없어진다는 점이다. 구두점 6개 정도는 외우기 쉬우므로 구두점 외의 기호들은 일단 Num으로 전환한 후 누르면 되므로 고민할 필요가 없다.

하지만 이 방법은 정말 치명적인 단점이 있는데 바로 제자리 원칙을 위배했다는 점이다. 펑션키를 문자키 바로 위에 배열하더라도 손가락이 제일 윗열까지 올라가야 하므로 자세가 흐트러진다. 또한 펑션키가 없는 Compact 구성에는 이 방법을 적용할 수가 없다. 결국 이 방법은 하나의 방안으로서 기획해 본 것일 뿐 실제 적용하기는 굉장히 어렵다.

기호키들을 배치하면서 기존의 쿼티 키보드가 얼마나 엉망인가를 다시 한번 더 실감할 수 있었다. 몇 가지 예만 들어 보면

- 겹 따옴표의 빈도가 홑 따옴표 빈도보다 월등히 높은데 "가 Shift에 있다.

- ( ) 괄호의 빈도가 훨씬 더 높은데 Shift에 있고 빈도가 떨어지는 [ ] 괄호는 별도의 키에 할당되어 있다.

- `는 모든 기호중에 빈도가 가장 떨어지는 문자인데 독립된 키 하나를 배정 받았다. 그것도 왼쪽 모서리의 아주 좋은 자리에.

- BS 아래의 \ 키도 +나 *에 비해 빈도가 떨어진다.

빈도나 접근성 등에 대한 고려를 많이 하지 않고 그냥 대충 만든 키보드라는 것을 알 수 있다. 그나마 .과 ,가 문자 손가락 영역에 있는 점은 훌륭하고 () [] 등 관련된 기호가 인접해 있어 직관성은 높은 편이다.

사람들이 21개나 되는 쿼티 키보드를 별 불편없이 사용하고 있는 이유는 그만큼 익숙해져 있기 때문이다. 결국 키보드는 배치에 상관없이 익숙해지면 그냥 저냘 쓸 수 있는 물건이다. 다만 얼마나 빨리 익숙해질 수 있는지, 효율성의 차이가 얼마나 발생하는지 정도의 차이가 있을 뿐이다.

■ 잘 동작하는지, 사용감은 어떤지, 속도는 제대로 나오는지 테스트하려면 결국 샘플 키보드를 만들어 봐야 한다. 배치가 확정되면 실제 샘플 키보드를 만들어 볼 것이다. 쿼티 키보드에 정의된 키 중 일부만 사용하므로 샘플 키보드에 어떤 키를 배치할 것인가를 정해야 한다. 키로부터 입력된 값은 디바이스 드라이버에 의해 해석되지만 디바이스 드라이버 이전도 고려해야 하므로 어떤 키를 선택하는가에 따라 실제 발생시키는 스캔 코드가 달라지므로 이 점도 중요하다. 문자키는 대응되는 키가 있으므로 별 문제가 되지 않는다. Space, Enter, BS 등도 대응되는 키가 있고 CASW는 모두 왼쪽 키를 선택하면 된다. 그러나 쿼티 키보드에 없는 키들에 대해서는 선택이 필요하다.

Mode - 한글 키가 가장 적당한 후보이다.

Sym(또는 Num) - 대응되는 키가 없다. Tab 정도면 어떨까 싶다.

Edit - 역시 대응되는 키가 없다. Esc키 정도가 적당할 듯 하다.

Fn - ~ 키 정도를 쓸 수 있을 것 같다.

Caps Lock은 LED에 불이 들어오므로 적당하지 않은 것 같다. 차후 스캔 코드표를 뒤져 보고 더 적합한 키를 물색해 봐야겠다. 아무 키나 마음대로 골라도 되는 것인지도 아직 확실하지 않다. 어쩌면 별도의 스캔 코드를 직접 정의하는 것이 더 나은 방법일 수도 있다.

■ 전부터 생각했던 것이지만 스캔코드 직접 입력 기능이 필요하다. 부팅할 때 BIOS로 들어가기 위해 F2키를 누르는 메인 보드들이 있는데 키보드에 F2가 없으므로 디바이스 드라이버가 올라오기 전에 F2키의 스캔 코드를 입력할 방법이 있어야 한다. 또한 키의 개수를 줄였으므로 특정 스캔 코드를 발생하는 키가 아예 키보드에 없다. 예를 들어 쿼티의 가운데에 있는 tyghbn은 키 자체를 배치하지 않을 것이다.

특정 프로그램은 반드시 이 키를 요구할 수도 있다. 비록 불편하고 느리더라도 스캔 코드를 직접 입력할 수 있는 방법이 필요하다. 쿼티 키보드도 이 기능을 제공하는데 Alt 키를 누른 채로 넘패드의 숫자를 누르면 특정키가 입력된다. 마찬가지로 Menu와 Edit 키를 동시에 홀드 다운한채로 숫자키를 누르면 10진 스캔 코드를 강제로 발생시키면 될 듯하다.

이 기능은 디바이스 드라이버와는 무관하며 소프트웨어적으로 구현해 봐야 아무 소용이 없으므로 키보드 하드웨어에 직접 프로그래밍해 넣어야 한다. 차후 샘플 키보드를 만들 때 적용해볼 것이며 지금은 신경쓸 필요가 없다.

■ 하드웨어 키보드를 만들 때 어떤 문자를 키보드 표면에 각인할 것인지도 선택해야 한다. 현재 기획상으로만 해도 총 6개의 모드가 존재하며 또한 Upper 상태까지 고려하면 키에 새겨 넣어야 할 문자가 정말 엄청나다. 소프트웨어 키보드가 아니므로 런타임에 캡션을 바꿀 수도 없다. 쿼티 키보드의 F 자리를 예로 들면 다음과 같은 문자를 입력하고 기능을 수행한다.

한글 - ㅇ, Upper 상태에서는 .

영문 - T, Upper 상태에서는 .

숫자 - 공백

기호 - ]

편집 - Copy

Fn - Play

이 기호들을 다 새길 필요는 없고 그럴 수도 없다. Upper 상태는 여섯개밖에 안되므로 일단 제외한다. 알파벳 Upper의 4개가 표시되지 않아 좀 헷갈릴 것 같다. 숫자 모드도 외우기 쉬우므로 제외하고 Fn도 순서대로이므로 굳이 새길 필요가 없다. 한,영,기호, 편집 정도만 밝히도록 한다.

대충 이 정도 될 것 같다. 외우기 힘든 기호만 키에 새겨 놓고 나머지는 매뉴얼이나 도움말로 안내하는 것이 좋을 듯 하다. 아무 것도 새겨지지 않은 키보드를 쓰는 사람도 있는 지경이니 각인이 좀 심심해도 괜찮을 것이다.

■ 아너림은 제자리 방식으로 동작하므로 운지 거리가 짧다는 것이 장점이다. 이 장점을 극대화하려면 키피치가 최소화되어야 한다. 표준 키보드의 키 피치는 19미리인데 정확하게는 18.8미리이다. 아마도 남녀 누구에게나 손 크기에 상관없이 충분한 크기로 설정한 듯 하다.

수평으로는 대충 이 정도 키 피치를 유지하되 수직 키 피치는 15미리로 좀 더 줄이는 것이 좋다. 자리가 정해져 있으므로 헷갈릴 위험이 덜하고 손가락을 조금만 움직여도 되므로 속도에 유리하고 피로감도 덜할 것이다.

단, 처음부터 키피치를 표준과 다르게 만들면 상당한 거부감을 유발할 수도 있으므로 초기 시제품은 표준 키 피치를 유지하고 조금씩 익숙해지면 그때 키 피치를 축소하는 것이 좋을 것 같다. 대략 수평 18, 수직 15정도가 적당하다.

■ 문자키의 각도는 약간씩 기울일 생각이다. 좌우의 팔이 바깥쪽에 있고 손이 안쪽으로 모이는 자세이므로 손가락이 전체적으로 바깥쪽으로 기울어진 형태이다. 일자 형태의 현재 키보드는 손목을 꺽어지게 만들어 손목 터널 증후군같은 각종 질병을 유발하고 피로감에도 좋지 않다. 약간만 기울이면 훨씬 더 타이핑하기 편리할 것이다.

그러나 막상 기울이면 오랫동안 일자 키보드에 익숙해진 사람들이 어색해할 수도 있다. 또 실제로 손가락을 키보드위에 얹어 보면 집게가 길고 새끼가 �苡� 거의 일자 모양이 나오기도 한다. 손을 자연스럽게 뻗어 보면 집게에 비해 중지, 약지가 더 길어 정확하게는 일자도 아니고 반달 모양의 둥근 형태가 된다.

차후에는 피로도를 최소화할 수 있는 적당한 모양과 각도를 연구해 보되 당분간은 일자 형태를 유지하는 것이 바람직할 것 같다. 아너림은 좌우의 키보드가 벌어져 있어 손목이 심하게 꺽이지 않는다는 것도 그 한 이유이다.

12년 5월 29일

세상에는 똑같은 생각을 가진 사람들이 참 많다. 나처럼 좀 더 편리한 키보드를 만들어 보고자 하는 사람들도 많이 있으며 생각뿐만 아니라 이미 구현까지 마치고 상품화를 한 사람들도 있다. 새 키보드를 만들려면 과거에 시도했던 것들을 흡수 발전시켜야 할 필요가 있으므로 이미 발표된 키보드는 어떠한 것이 있는지 조사해 보았다.

■ 클러드 시스템

방향키의 5개 키만 사용하여 한글, 영문, 기호를 입력할 수 있는 시스템이다. 상하좌우 4개의 키와 중앙의 버튼까지 5개의 키로 모든 문자를 입력한다. www.clurd.com에서 상세한 사용 방법과 에뮬레이터를 다운로드받을 수 있다. 에뮬레이터의 모양은 다음과 같다.

ㄱ은 상우, ㄴ은 좌하 식으로 모든 키를 두 번씩 누른다. ㄲ, ㄸ 등의 경음은 두번째 키를 길게 누른다. 중우는 ㅏ 중좌는 ㅓ 중상은 ㅗ 중하는 ㅜ식으로 모음을 입력한다. 왼쪽의 T키는 모드를 바꾸는데 KOR,NUM,SYM,ENG,CUR 등이 있다. 모든 키를 2번 누른다는 원칙이 있고 기호의 모양으로 연상할 수 있도록 되어 있어 익숙해지면 한손으로도 꽤 쓸만할 듯하다. 특히 장애인들에게 상당히 유용해 보인다.

클러드 시스템은 Q SENN이라는 브랜드로 유명한 GP 전자의 GP-N4000이라는 모델로 실제 출시되었다. 넘패드 모양으로 생겼으며 각종 편집키들도 같이 포함되어 있다. 키 개수는 총 21키이다.

제작자에 평균 120타 정도가 나온다고 한다. 모든 음소를 2타씩 쳐야 하므로 다소 느리며 특이한 구조로 인해 어쩔 수 없이 학습 및 숙달은 필요하다. 2타씩 입력하는 것은 좋은데 경음의 경우 길게 누름이 있어 고속 입력에는 불리하다.

2009년경에 실제 출시되었던 제품이나 판매량이 그다지 많은 것 같지는 않으며 지금은 단종되어 구할 수가 없다. 가격이 얼마인지도 조사되지 않는다. 개발을 위해 많은 공을 들였겠지만 안타깝게도 현실의 벽을 넘지 못한 것 같다.

■ 로지텍의 게이밍 키보드 pk7이며 현재도 27000원 정도에 판매되고 있다. 게임에 꼭 필요한 키만으로 구성되어 있으며 문자 입력용은 아니다. USB로 연결하여 기존 키보드와 함께 사용할 수 있다. 모양이 상당히 특이해서 장식용으로도 쓸만해 보인다. 별도의 드라이버는 설치하지 않아도 바로 쓸 수 있는 모양이다.

사용기를 보아하니 게임용이지만 막상 게임에도 그리 편하지 않다고 한다. 키감은 괜찮다고 하는데 키 배치에는 약간씩 불만을 가지는 사용자들이 있다. 역시 키배치라는 것은 아무리 잘 만들어도 표준과 다르면 모두를 만족시킬 수 없다. 현재의 2벌식도 익숙해서 그럴 뿐이지 사실 키보드를 익힌다는 것은 무척 어려운 일이다.

■ 속기용 키보드. 일종의 자격증으로 공부하는 사람들이 많다. 자격증 취득 기간은 빨라도 10개월, 보통은 1년 정도가 걸린다. 키보드보다는 거의 자격증 장사를 하는 것 같다. 관련 정보를 검색해 보면 정보를 가장한 광고글들만 잔뜩 있어서 짜증난다. 속기사 자격증 따 봐야 10급 공무원으로 취직하며 연봉은 3000 정도 수준이라고 한다.

많이 쓰는 제품은 카스의 속기 키보드와 소리자바 2가지가 있는데 카스는 200만원, 소리자바는 270만원 정도 한다. 키보드뿐만 아니라 강의 비용까지 포함된 가격이라서 엄청나게 비싸다. 두 기종은 서로 호환되지 않으므로 처음 배울 때 신중하게 잘 선택해야 한다.

다음은 소리자바라는 제품이다. 원래 이름이 감퓨타, 퀵보드였었는데 지금은 소리자바로 이름이 바뀌었다. 속기를 하는데 키가 저렇게 많이 필요한가 의아하다. 그냥 녹음을 하면 될 것을 왜 속기를 하는지도 잘 이해되지 않는다.

다음은 카스 속기 키보드이다. 이 장비도 카스플러스 3, 스마트카스 등 여러번 버전업되었다. 좌우 손가락 모양이 분리되어 있고 기울어져 있는 것이 독특하다.

속기 키보드는 모두 3벌식을 사용한다. 왼쪽이 초성, 오른쪽이 종성, 아래쪽에 중성 모음이 있다. 좌우 손으로 초성, 중성 자음을 치고 양손 엄지 손가락으로 모음을 치는 방식이다. 리듬감있게 입력 가능할 듯한데 종성이 없는 경우가 많으므로 왼손의 부담이 훨씬 더 클 것이다.

속도는 익숙해졌을 때 대략 1200~1300타 정도 나오며 사람이 말하는 속도와 비슷하다. 문자를 그대로 입력하는 것이 아니고 단축키라는 약어를 많이 입력한다고 한다. 일반 키보드도 능숙한 사람은 800타 정도까지 나오니 약어를 제외하면 그다지 빠른 편은 아니다. 휴대폰용 키패드로도 490타까지 치는 사람이 있다고 한다. 아너림은 익숙해질 경우 1000타 정도는 무난하지 않을까 추측된다.

■ 플랙서블 키보드. 휘어지므로 둘둘 말아서 가지고 다닐 수 있다. 가격은 대략 3만원 수준이다. 키감은 거의 최악이라고 한다. 휴대성을 강조하면서도 넘패드를 달고 있는 것이 모순처럼 보인다. 들고 다니면서 과연 숫자를 입력할 일이 그렇게 많을까?

다음은 모바일용 키보드이다. 안드로이드의 TStore에 들어가면 모바일용 키보드들이 많이 발표되어 있다. 한글 키보드를 구해야 하므로 구글 마켓보다는 TStore에 더 많은 상품들이 있다.

■ 삼성 키패드 : 갤럭시 S에 내장된 키보드이다. 기본적으로 2벌식이며 영문은 당연히 쿼티이다. 한/영 토글키와 숫자 토글키로 모드를 바꾼다. 숫자 버튼으로 숫자 모드로 바꾼 후 다시 기호키를 눌러 기호 모드로 바꾸며 기호 모드에서 페이지를 바꿔 가며 이모티콘을 선택한다. 한글 상태에서 기호까지 가려면 숫자를 반드시 거쳐야 하는 불편함이 있고 모드에 따라 전환 버튼의 위치가 달라 헷갈린다. 이모티콘이 총 10페이지라 중간쯤에 있는 기호는 선택하기가 굉장히 어렵다.

음성 입력 기능도 있는데 100% 정확하지는 않지만 비교적 쓸만한 수준이다. 고유 명사들도 잘 인식되고 특히 숫자까지 인식되는 점이 놀랍다. 띄어쓰기는 약간씩 틀리는 부분이 있다. 웬만한 문자 메시지는 음성으로 입력해도 편리하게 입력 가능하다. 음성 인식 기술이 발전하면 키보드로 입력할 일이 상당히 줄어들겠지만 그래도 키보드는 여전히 문자 입력을 위한 궁극의 장치가 될 것이다.

■ TS 한글 입력기 : 디자인이 상당히 예쁘다. 키를 누를 때 색색의 원이 나타나 방금 어떤 키를 눌렀는지 보여준다. 한글은 천지인 방식을 기본으로 하며 영문은 쿼티이다. 한글의 자모 배치는 특별한 규칙없이 그냥 순서대로 죽 나열해 놓았다. 손가락 위치가 의미없으므로 이 방식이 오히려 더 깔끔한 것 같다. 키를 길게 누를 때 입력할 문자들도 각 키에 배치되어 있다.

한영 전환은 공백키를 좌우로 드래그하는 방식인데 별도의 모드 변환키없이도 밀어서 변환 가능하다. 숫자는 공백 왼쪽의 버튼으로 전환하며 3개의 페이지로 되어 있다. 자주 사용하는 이모티콘은 마침표를 길게 눌러 팝업창을 불러낸 후 입력할 수도 있다. 키보드위에 팝업창이 따로 열리므로 보기에 예쁘고 쓰기도 편하다.

위쪽의 멀티 툴바에는 후보창이 나타나는데 여기서 입력중인 글을 편집할 수도 있고 상용구를 입력할 수도 있다. 상용구는 직접 편집도 가능하다. 자체적으로 클립보드 액션 버튼을 제공한다. 쉬프트키를 길게 누르면 한자 입력도 가능하다. 음성 입력도 지원하는데 구글 라이브러리를 사용한다. 음성 인식률은 꽤 괜찮은 듯 하다. 키보드의 색상을 스킨으로 선택할 수 있고 키의 높이도 옵션에서 선택 가능하다.

무료 버전은 30일 후 일부 기능이 제한되며 유료 버전은 3000원이다. 기능이 굉장히 많고 디자인도 우수해서 돈 내고 쓸만한 키보드인 듯 하다. 유료 버전 판매수가 2000건 정도이므로 매출이 대략 600 정도다. 앱 만들어서 개발비를 회수하는 것은 참 어려운 일이다.

■ 참글자판 : 밀기 방식으로 입력하는 자판이다. ㄱㄴㄷㄹㅁㅂㅅㅇㅈ 까지의 한글 자음이 배치되어 있으며 누르면 모음이 나타난다. 누른 상태에서 좌우로 드래그하여 모음을 선택한다. 복모음은 두 번 이상 드래그해야 한다. 예를 들어 '와'를 입력하려면 ㅇ을 누른 후 위로 올려 ㅗ를 선택하고 다시 오른쪽으로 이동하여 ㅘ를 선택한다.

영문은 각 키당 3개씩의 문자가 할당되어 있으며 팝업에서 좌우 문자 및 대소문자를 선택한다. 숫자는 그냥 키를 누르는 방식이고 이모티콘은 4개의 페이지로 구성되어 있다. 진동이나 소리가 출력되지 않아 다소 심심한 편이다. 상단의 ㄱㄴㄷ은 위쪽 모음이 선택되지 않는 버그도 있다.

미는 방식은 꽤 좋은 아이디어인 것 같지만 실제로 사용해 보면 그다지 편리하지는 않다. 누른 후 계속 이리 저리 밀어야 하므로 복잡하고 배치를 외운다 하더라도 고속 입력에는 적합하지 못하다. 잘못 드래그했을 때 취소도 제대로 안되는 듯하다. 일단 입력한 후 지워야 한다.

■ 훈민 정타 : 특허 등록된 글판이다. 타자식, 밀기식 겸용이다. 모양이 상당히 독특하다. 한 버튼에 자음과 모음이 같이 들어 있는데 어떤 음소를 입력할 것인가는 프로그램이 자동으로 판단한다. 한 키에 자음과 모음이 모두 등록되어 있다. "길"이라는 글자를 입력하려면 가 키에서 시작히여 비까지 드래그하고 놓은 후 루 키를 누른다.

상당히 특이한 키보드이지만 사용 방법은 익숙해져도 쉽지 않을 듯 하다. 멀리 떨어진 키의 경우는 드래그 거리가 멀어 빠른 속도로 입력하기 어렵다.

■ 형통 한글 자판 : 키 개수만 조정한 일반적인 자판이다. 한글은 키 개수를 최소한으로 배치했으며 빈도가 떨어지는 글자는 중복 배치되어 있다. 경음은 더블 푸시하는데 시간차를 측정한다. 영문은 그냥 쿼티이고 숫자 자판도 평범하다. 사전을 내장하여 예측 제안하는 기능이 있다고 한다. 숫자 모드에 커서 이동키가 있는 점이 특이하다.

이 외에도 많은 키보드들이 발표되어 있는데 대부분 위 방식들의 변형이거나 조합이다. 유료 키보드는 굳이 돈내고 설치해 볼 필요까지 못 느껴서 받지 않았는데 디자인이 좀 더 우수한 것 같다. 모바일용 키보드는 키를 누르는 것 외에도 드래그, 팝업, 여러 번 누름, 오래 누름 등의 여러가지 기법을 사용할 수 있다는 이점이 있고 또 키의 캡션뿐만 아니라 배치까지도 조건에 따라 바꿀 수 있다는 점에서 응용의 묘미가 있다. 밀기 기능은 나름대로 머리를 잘 썼으며 숙달되면 아주 편리하다.

그러나 물리적인 키보드에 적용하기에는 별로 어울리지 않는 기능들이 많다. 밀기는 아예 불가능하고 오래 누르는 것은 가능은 하지만 고속 입력에는 어울리지 않는다. 하드웨어 키보드는 그저 무식하게 눌러야 제맛이고 손이 자리를 외우면 어떤 방법보다도 더 빠르고 머리가 별로 개입할 필요가 없으므로 피로도가 낮다. 또 모바일에서는 어려운 여러 키 동시 누름 등이 가능하다는 이점이 있다. 상황에 따라 문자 입력을 위해 쓸 수 있는 기능들이 각각 다름을 알 수 있다.

■ 오늘 문득 키보드를 보다가 이런 생각이 들었다. "Upper 키가 왜 저기에 있을까?" 문자키 중간에 위치한 기능키가 무척 생뚱맞아 보이고 차후 제품 발표시 많은 공격을 받을 빌미가 될 것 같았다. 그래서 Upper키에 대해 수술을 단행해 보기로 했다. 우선 Upper의 이름을 Up으로 바꾼다. 길게 쓸 필요없이 위쪽의 문자를 입력하는 용도로 사용되므로 Up이라는 짧은 이름을 쓸 수 있다. Shift와는 동작 방식이 다르므로 Shift라는 이름은 적당하지 않다. Shift라는 이름의 키는 따로 존재한다.

Up 키가 문자키 중간에 위치하게 된 이유는 최초 이 키보드를 설계할 때 엄지 손가락에 키가 2개밖에 없었기 때문이다. 그래서 엄지 영역에 Up을 둘 수 없었고 그러다 보니 문자키 중간에 자리했다. 문자 선택에 사용되는 키이므로 문자키 중간에 있어도 무관하며 다른 언어에는 불필요하다고 생각했지만 이 생각도 틀린 것 같다. 거의 모든 문자는 24개가 넘으며 따라서 Up은 모든 언어에 공통적으로 적용해도 무리가 없다.

그렇다면 Up을 과연 어디다 배치할 것인가? 이 문제는 더 고민할 필요도 없이 BS 자리이다. 공백 옆이고 엄지로 바로 누를 수 있으므로 접근성이 뛰어나다. BS는 애초의 설계대로 Up + Space로 기능을 대신한다. 바로 옆에 붙어 있으므로 누르기 쉽고 숙달되면 빈도가 급격히 떨어지므로 별도로 키 하나를 배정할 필요는 없을 것 같다. Up 키가 아래로 내려오면 전반적으로 많은 변화가 발생한다.

- 영문자 하나를 더 배치할 수 있다. 4개중에 나름대로 빈도가 높은 x나 j를 배치할 계획인데 아무래도 x가 더 유력하다. 둘 중 어떤 것이든 아래로 내려 오면 영문 키의 배치도 전면적으로 수정해야 한다. 정확한 배치는 통계를 다시 뽑아 보고 결정할 예정이다.

- 한글도 마찬가지로 하나를 더 배치할 수 있는데 현재 딱히 부족한 문자는 없다. 경음을 가지고 올 필요는 없을 듯 하고 모음 ㅕ에 별도의 키를 배정하는 것이 어떨까 싶다. 현재의 ㅆ 자리에 ㅕ를 배치하고 ㅆ은 Up 자리로 옮긴다. ㅓ와 ㅆ의 연타율이 낮아지는 효과가 있다.

- 기호나 숫자, 편집 모드는 Up 키가 제거되었으므로 영향을 받지 않는다. Up은 오로지 언어 입력에만 사용되는 키이다. 숫자에도 Up을 적용하면 Sym 페이지를 별도로 두지 않아도 될 것 같지만 3터치 이상이 되면 불편할 듯 하여 일단은 적용하지 않는다. 그러나 빈도가 지극히 떨어지는 기호라면 Up 위치에도 배치할 수 있고 여러 가지 다른 용도로도 활용할 수 있는 여지가 있다.

그렇다면 Up과 비슷한 입장인 Cap 키는 어떻게 할까? 이 키는 기존대로 문자키 중간에 있는 것이 옳다. 왜냐하면 대소문자는 영어에만 있는 것이고 한글에는 해당되지 않으므로 문자 페이지에서 알아서 해결해야 할 문제이다. 일본어의 히라가나/가타카나 전환, 유럽어의 움라우트, 액센트 적용 등의 기능도 문자키 24개 내에서 해결을 보아야 한다.

Cap은 여전히 문자키 중간에 배치하되 다만 Up 키가 내려감으로 인해 위치는 다소 조정될 가능성이 있다. 대문자 입력 빈도가 얼마나 되는가에 따라 결정해야겠지만 첫 자 대문자는 소프트웨어로도 가능하므로 그다지 높지는 않을 것이다.

12년 6월 2일

0.92 버전 기획을 몇일간에 걸쳐서 했다. 기획 중에는 따로 코드를 작성하지 않고 기획만 했는데 한 버전내에서도 기획이 자주 바뀌므로 이 방식이 훨씬 더 효율적이다. 기획을 대충 마무리한 후 코드에 적용했다. 상당한 양의 코드가 바뀌었지만 시간은 그다지 오래 걸리지 않아 대략 사흘 정도만에 코딩을 끝냈다. 실제로는 더 빨리 할 수도 있지만 현재 프로젝트의 구조가 그다지 좋지 못해 조정하느라 시간이 오래 걸린 것이다. 차후 강도높은 리팩토링이 필요하다. 이번 버전 구현 작업 내용은 다음과 같다.

■ 구성에 따라 키 개수를 동적으로 조정 가능하도록 하였다. 4개의 레벨을 정의하고 메뉴에서 구성을 선택하면 구성에 맞는 키만 나타난다. 다음은 레벨 4의 풀 배열이다.

레벨 3으로 줄이면 오른쪽의 확장키가 사라지고 레벨 2로 줄이면 펑션키가 사라지고 레벨 1로 줄이면 왼쪽 조합키가 사라지고 레벨 1로 줄이면 문자키만 남는다. 여러 구성을 테스트해 볼 수 있어서 좋다.

■ 쿼티 키보드로 이 구성을 제대로 테스트해 보기 어려워 한칸씩 올린 커스텀 키보드를 사용할 수 있는 옵션을 두었다. 문자표에 한칸씩 올렸을 때의 가상키 코드 멤버만 하나 더 추가하고 이 키를 입력받으면 된다.

■ 펑션키를 12개로 늘렸다. 애매하게 8개를 두는 것보다는 훨씬 더 나은 것 같다. 물론 구성에 따라 펑션키 자체를 제거할 수도 있다. 표준 구성일 때 Fn 모드는 다음과 같이 배치하였다.

오른쪽에 F1~F12를 배치하고 왼쪽에는 멀티미디어 확장키를 두었다. 왼쪽은 대충 넣은 것이라 재배치가 필요하다. Fn키는 앞서 고민했던 여러 방안 중에 2번을 선택했는데 보기에 좀 뭣하기는 하다.

■ Up키를 아래로 내렸다. 이번 버전에서 가장 많이 바뀐 부분이다. BS는 제거되었고 Up + Space로 사용한다. Up이 내려온 자리에 한글은 ㅆ을 배치하고 하나 남는 자리에는 모음 ㅕ를 배치했다. 영문은 Up 자리에 x를 배치했다. 기획대로 했는데 더 고민이 필요한 부분이다.

■ Sym 모드를 도입했다. Num키의 이름을 Sym으로 변경하고 Sym버튼을 누르면 Sym 모드로 전환한다.

모드 도입 자체를 중요시하다 보니 배치는 아직 더 고민해야 한다. 기호 하나를 누르면 자동으로 복귀하는 방식이다. 숫자는 Mode를 홀드한 채로 입력하거나 더블 푸시하여 모드를 바꾼다. 숫자에는 +, - 기호도 같이 배치하고 남는 자리에 화폐 단위 기호도 일단 채워 놓았다.

실제 사용해 본 결과 별도의 모드에 기호를 몰아 넣는 방식이 직관성이 더 높고 익숙해지면 별 불편함이 없다. 하지만 실제 키보드로 테스트해본 것이 아니라 엄지를 이용한 모드 변환이 얼마나 신속하고 편리한지는 정확하게 알기가 어렵다.

■ 좀 억지스럽기는 하지만 이모티콘 모드도 정의했다. 사실 데스크탑 환경에서는 이 모드를 따로 둘 필요가 전혀 없지만 모바일 환경을 위해서 정의해 둘 필요는 있다. Edit키를 더블 푸시하면 이모티콘 모드로 들어간다.

페이지 개수는 가변적이면 Prev, Next 키로 페이지 사이를 이동한다. 이모티콘 배치는 어디까지나 대충 해 둔 것이며 그나마도 2,3페이지는 숫자2와 3으로 가득 채워 놓아 자리만 예약해 두었다.

■ 기타 코드 리팩토링 작업도 했다. 이전 모드 상태를 기억하기 위해 여러 개의 변수를 사용했는데 그러다 보니 각 변수 이름을 외우기도 어렵고 상태가 너무 많다 보니 버그도 창궐했다. 그래서 모든 변수를 다 없애 버리고 모드의 변환 상태를 큐에 기록한 후 큐를 뒤져 이전 모드를 알아 내는 방식으로 바꾸었다. 키맵을 정의하는 자료 구조도 대폭적으로 수정되었고 도우미 함수들도 많이 만들었다. 그러나 아직도 코드의 구조는 상당히 질이 떨어지는 편이다. 다음 버전에서는 강도높게 리팩토링을 해야겠다. 시간이 꽤 많이 걸릴 듯하다.

이상 여기까지 작업한 버전을 0.92로 릴리즈했다. 완성된 버전도 아니고 버그도 상당히 많이 있지만 중간 기획 결과를 정리한다는 면에서 의미가 있는 버전이다. 키 배치도 완성되지 않은 상태이므로 아직 안정성이 큰 의미가 없다. 배치가 확정되지 않았으므로 안드로이드용 키보드는 같이 업그레이드하지 않았다.

12년 6월 3일

0.92 버전을 릴리즈한 후 별로 테스트도 해 보지 않은채로 바로 0.93버전 기획으로 들어간다. 아직도 마음에 안드는 부분이 많고 이런 저런 아이디어들이 많이 떠오르기 때문이다. 그제 회사 워크샵을 다녀왔는데 워크샵 중에도, 술에 취한 상태로 누워서도 키보드 생각밖에 나지 않았다. 그래서 대충 종이에 끄적거려 왔다. 이번에도 다양한 시도를 해 볼 것이다.

■ hot키 모드를 도입해 볼까 생각했다. CASW키를 이용한 단축키 입력은 빈도가 떨어지지만 개발이나 편집시에는 종종 사용하므로 제자리 원칙을 지킬 수 있는 것이 좋다. 또 4개의 조합키가 별도로 존재하는 것도 별로 마음에 들지 않는다. Hot키 모드를 도입하면 엄지 손가락의 키들을 CASW키로 대신 사용할 수 있다. 이 경우 왼쪽에 Fn, 오른쪽에 Hot키를 두면 된다. Standard 구성의 예상되는 배치는 다음과 같다.

핫키 모드에서는 왼손 엄지의 세 키가 CSA키의 역할을 한다. Ctrl + S, Ctrl + Shift + F 등의 핫키를 제자리에서 바로 입력할 수 있다. 핫키를 연속해서 입력하지는 않으므로 하나의 핫키를 입력한 후는 원래 모드로 자동 복귀한다. Up키는 위쪽에 있는 z, q, j에 대한 핫키를 입력하기 위해 그대로 존재해야 한다. Sp도 마찬가지로 Ctrl + Space 같은 핫키 입력을 위해 그대로 유지한다. Fn키는 펑션키 입력을 위해 역시 존재해야 한다.

모드키가 조합키가 됨으로써 모드 변경이 부자유스럽지만 핫키를 한글 자모에 대해 정의하지는 않으며 보통 알파벳과만 연결한다. 이렇게 하면 표준 구성이 훨씬 더 간단해진다는 이점이 있고 핫키까지도 제자리에서 입력 가능하다는 점에서 매력적이다. 그러나 실제 적용하려고 생각해 보니 상당한 문제점이 발견되었다.

- 모드가 하나 더 늘어남으로써 복잡도가 훨씬 더 증가한다. 사용 방법도 복잡해짐은 두말할 것도 없다. 익숙해져도 불편할 것 같다.

- 모드를 바꾸지 못하므로 Ctrl + 1이나 Ctrl + ] 같은 핫키는 입력할 방법이 없다. 모드를 미리 바꿔 놓고 핫키 모드로 들어가는 방법이 있지만 너무 어렵다.

- Win 조합키는 입력할 방법이 없다. 비록 Win 키가 표준도 아니고 임의 확장된 것이기는 하지만 이미 많이 사용되고 있으므로 무시하기는 애매하다.

- 이론적으로 가능은 하지만 압축의 정도가 너무 과도해서 초반 도입기에 까일만한 요소가 되기에 충분하다. 이게 뭐냐고 투덜거리는 사람이 분명히 있을 것이다.

이 방법은 잠시 기획은 해 보았지만 실제 적용은 하지 않기로 했다. 차후 더 쌈박한 방법이 생각난다면 다시 고려해 볼 것이다.

■ 풀 구성에 M1, M2, M3 키는 제거하기로 했다. 최초 이 키를 기획한 의도는 Ctrl + Z나 유로 문자 등 현재 구성에서 입력하기 어려운 핫키나 특수 문자를 자주 입력하는 사람들이 사용자 정의해서 쓰라는 의도였었다. 그러나 사용자 정의는 통일성에 위배되고 실제로 쓸 사람도 많지 않을 것 같다. 아무리 풀 구성이라고 해도 불필요한 키는 제거하는 것이 마땅하다. 자리도 훨씬 더 번잡스러워 보인다.

또 이미 사용자 정의 키로 Sym 모드에서 F1~F12까지의 키를 사용하는 방법을 미리 생각해 두었으므로 굳이 추가로 사용자 정의키를 더 할당할 필요는 없다.

■ 키 개수를 줄이는데 너무 연연하다 보니 사용법이 복잡해지고 불편함도 증가한다. 자주 사용하는 키는 역시 별도의 키가 있어야 하는데 가장 아쉬운 키는 Esc와 Tab, Prtsc 등이다. Insert 키는 사실상 거의 사용되지 않으며 Del이나 커서 이동키는 편집 모드의 좋은 자리에 있을 뿐만 아니라 풀 구성에는 별도의 키가 있으므로 문제가 없다.

Esc의 경우 신속한 취소를 위해 꼭 필요하다. 잘못된 명령을 내렸을 때 모드 변환없이 바로 누를 수 있어야 한다. 즉시 취소해야 하는데 Edit키를 누르고 오른손 귀퉁이의 버튼을 누르는 것은 너무 어렵다. 게임 등에도 Esc키는 종종 사용되므로 별도키가 있을만하다. 또 Ctrl + Esc는 윈도우의 시작 메뉴 단축키로 사용되므로 이 키도 즉시 누를 수 있는 자리여야 한다.

Tab키의 경우도 단독키로는 빈도가 꽤 높다. 대화상자에서 포커스를 옮기는 용도로 사용되며 Alt + Tab는 프로그램 전환 단축키이기도 하다. 문단 포맷팅에도 종종 사용되지만 편집키들이 자동으로 삽입해 주므로 직접 누르는 경우는 많지 않다. 이런 중요한 키를 모드 바꿔가며 입력하는 것은 불편함을 가중시키는 일이다. 이 두키를 포함하여 키를 다시 배치해 보면 다음과 같은 그림이 나온다.

CSAW를 하단에 배치하고 Fn 키의 위쪽에 이 두 키를 올려 놓는다. Shift 방향키로 블록 선택도 용이하고 Fn키와 Ctrl키를 같이 누를 수도 있다. Tab, Esc도 Ctrl과 조합되므로 누르기 편하다. 다만 자주 사용되는 Alt+Tab은 거리가 좀 멀지만 양손으로 누르므로 좌우 분담은 된다. 제자리는 아니지만 왼손 새끼 손가락으로 누를 수 있으므로 자세가 많이 흐트러지지 않으며 풀 구성일 때 좌우 구성도 어느 정도 맞아 보인다.

Tab, Esc는 Edit 모드에도 존재하는데 이 키는 빼도 되고 그냥 두어도 된다. Compact 구성에는 이 키가 없으므로 Edit 모드에 있어도 될 것 같지만 사실 그렇지도 않은게 Compact는 문자 입력만 가능한 구성이므로 아예 빼는 것도 괜찮을 듯 하다. 오른쪽 끝을 위에서부터 아래로 Pause, PrtSc, Insert 등으로 채우는 것이 좋아 보인다. 편집 모드 왼쪽의 남는 키에는 RShift나 넣어 주고 Sleep도 낑가 주자.

Tab키가 별도의 키로 들어가면 연습 프로그램에서는 더 이상 Tab키를 사용할 수 없다. 현재 연습 프로그램은 Tab을 Mode 전환키로 사용하는데 T나 G 키로 옮겨야 할 듯하다. 엄지 손가락의 모드 변환키에 해당하는 키가 쿼티 키보드에 없다 보니 이런 문제가 생긴다. 쿼티에서 가운데 안쓰는 키들에게 모드 변환 기능을 줄 수밖에 없다. 다음과 같이 키를 맵핑한다.

엄지 손가락으로 이 키들을 누르는 것은 사실 굉장히 어렵다. 아무리 연습 프로그램이지만 너무 억지스러워 보인다. 결국 편의성이나 효율성을 제대로 테스트하려면 샘플 키보드가 꼭 필요하다. 암만 생각해 봐도 쿼티 키보드의 스페이스키는 너무 넓게 만들어 놓아 자리를 지나치게 많이 차지하는 것 같다.

Tab과 Esc는 원래 자기키와 맵핑하고 Fn은 오른쪽에 적당한 키가 없으므로 어쩔 수 없이 Caps Lock과 맵핑한다. 우연이겠지만 수직 순서가 거의 맞다.

■ 숫자, 기호 모드를 재배치한다. 숫자 모드에는 숫자 외에도 + - 연산 기호가 포함되어 있는데 그 이유는 Up과 Sym 모드에 자리가 부족하기 때문에 어쩔 수 없이 2개를 가져온 것이다. 숫자와 연관된 기호라 숫자 모드에 있어도 좋다고 생각했었다. 그러나 왜 하필 + - 만 가져온 것일까? * / = 도 숫자와 연관이 있는 연산자인데 이것들은 Sym 모드에 따로 배치되어 있어 직관적이지 못하고 숫자와 함께 쓸 때 모드를 변환해야 하는 불편함이 있다. 차라리 숫자 모드에 숫자 관련 기호들을 다 모으는 것이 좋을 것 같다.

연산 기호 6개는 왼쪽의 집게, 중지 영역에 일괄 배치하고 숫자 오른쪽의 남는 3칸에는 공백, 마침표, 쉼표를 중복시킨다. 숫자 입력중에 공백을 입력하기 위해 모드를 전환해야 한다는 점이 상당히 불편했었는데 남는 영역을 잘 활용할 수 있어 다행이다. 중복된 키 3개가 같이 모여 있어 보기에도 나쁘지 않다.

가감승제, 대입, 퍼센트 기호까지 왼쪽 치기 쉬운 곳에 두었다. 화폐 기호 따위는 번잡해 보이므로 일단 지워 버리자. 이렇게 되면 Sym 모드에 4개의 자리가 남게 된다. 4개씩이나 비워둘 수는 없으므로 Up에서 ?와 !를 가져 오고 Up에는 .,"' 등의 순수한 구두점 4개만 왼쪽에 남겨 둔다. Sym 모드는 다음과 같이 재배치한다.

?!를 치기 좋은 자리에 두고 양손 새끼 손가락 자리는 비워 둔다. Up의 구두점 개수가 4개로 줄어 들었으므로 다른 언어를 위해 여유가 더 생겨서 좋고 연산 기호들이 모두 Num으로 이동했으므로 직관성도 높아진 듯 하다.

■ 한글 모드에 모음 ㅕ가 따로 자리를 배정 받았는데 이 키가 과연 따로 있는 것이 적절한가 하는 생각이 들었다. 빈도는 나름대로 높은 편이지만 ㅑㅛㅠ 등의 다른 복모음에 비해 입력 방법이 달라 일관성이 없고 ㅓ를 두번 누르는 것이 손가락을 내리는 것보다 딱히 편해 보이지도 않는다. ㅕ를 두어도 ㅓ를 두 번 누르면 여전히 ㅕ가 되어야 하므로 한 음을 입력하는 방법이 중복적으로 존재한다는 것도 마음에 들지 않는다.

ㅕ 자리를 비우고 ㅍㅋ을 왼쪽으로 한칸씩 옮긴 후 귀퉁이는 그냥 비워 두는 것이 차라리 깔끔한 것 같다. 빈 칸이 정 마음에 걸리면 ㄲ을 Up에서 가져와 내릴 수도 있다. 그러나 이 또한 다른 경음에 비해 일관성이 위배된다. 오른손 새끼 손가락 자리는 워낙 모퉁이라 누르기 쉽지 않다.

이 문제를 해결하기 위해서는 개별 음소들의 출현 빈도를 정확하게 구해야 한다. 현재 통계 프로그램은 ㅑㅕ같은 복모음의 출현 빈도를 따로 카운트하지 않고 ㅏ 2회, ㅓ 2회 식으로 뽑아 주므로 이 결정을 내리기에는 별 도움이 되지 않다. 또한 한손 자판까지 고려되어 있어 불필요한 정보가 많다. 우선 통계 프로그램부터 수정하여 모든 음소의 출현 회수와 키 누름 회수를 분리해서 통계를 뽑은 후 결정해야겠다.

그래서 하루 정도 시간을 내서 통계 프로그램부터 대대적으로 수술했다. 한손 자판과 관련된 코드는 모두 제거하고 두손 자판에 대해 통계를 뽑되 복모음, 복자음에 대해서도 통계를 산출했다. 음소의 출현 회수와 타수를 구분한 것도 중요한 개선 사항이다. 복모음의 경우 출현 회수 자체도 의미가 있지만 배치에 더 긴요하게 사용되는 정보는 타수이다. 예를 들어 ㅘ의 경우 ㅘ라는 음소는 출현했지만 키보드에는 이 문자가 없으므로 ㅗ와 ㅏ의 타수가 각각 1회씩 증가해야 한다. 이 정보까지 분석하여 배치를 결정하는 것이 합리적이다. 통계 프로그램을 수정한 후 0.92버전의 키보드에 대해 통계를 뽑아 보았다.

ㅓ와 ㅕ가 분리되어 있기 때문에 ㅓ의 빈도가 상대적으로 낮게 나온다. ㅕ의 빈도는 ㅐ와 ㅆ 사이에 존재하며 1.5%의 출현 빈도를 가지므로 낮다고 볼 수는 없다. 배치를 다음과 같이 수정한 후 다시 통계를 뽑아 보았다. ㅕ를 없애고 ㅍ과 ㅋ을 왼쪽으로 이동시켰다.

ㅓ의 타수 빈도가 3.85에서 6.57로 대폭 증가한다. ㅕ를 입력할 때마다 ㅓ를 두번씩 눌러야 하기 때문이다. 키 하나가 남아서 좀 아깝다는 생각이 드는데 여기에 배치할만한 다음 문자는 ㄲ이다. 그러나 ㄲ이라고 해 봐야 0.32%의 빈도밖에 안되므로 키를 배정한 효과가 높지는 않을 것 같다. 한글은 24개의 키가 다 필요없을 정도로 음소가 적은 우수한 문자라는 것을 세계 만방에 자랑하는 용도로 그냥 남겨 두기로 한다.

■ 영문 키 재배치 작업을 해야할 시점이다. 아주 오래 전에 현재 배치를 만들었었는데 급하게 만든 것이라 근거도 약하고 배치도 좋지 않다. Up이 비켜난 자리에 어떤 글자를 채울 것인지도 아직 제대로 결정하지 않았다. j나 x중 하나를 가져 와야 하는데 현재로서는 x가 선택되어 있지만 좀 더 생각해 봐야겠다. 0.92버전 기준의 키보드는 다음과 같은 통계를 보여준다.

같은 손 연타율 : 9.06

같은 손 연타율 : 43.09

좌우 분담률 : 40.35:59.65

행비율 : 29:36:18:15

연타율 상위 항목들 : en, el, fo, as, ac, rt, im

같은 손 연타율이 높은 것은 영어의 특성상 방지하기가 참 어렵다. 쿼티 키보드는 easter, create, steward 등의 단어가 전부 왼쪽에만 몰려 있는 지경이어서 골고루 분산이 잘 안된다. 영문 배치를 위한 기본 데이터부터 정리해 보자. 영문 배치를 위한 기준은 다음과 같다.

① 가장 중요한 것이 알파벳순 출현 빈도이다. 다음은 직접 작성한 통계 프로그램으로 조사한 것이며 공식적인 다른 통계와는 차이가 있다.

알파벳	비율	알파벳	비율
e	8.55	m	1.74
t	6.51	p	1.55
o	5.44	f	1.47
a	5.22	g	1.44
i	5.04	y	1.44
n	4.68	w	1.25
s	4.51	b	1.11
r	4.45	v	0.65
h	3.27	k	0.51
l	2.97	x	0.2
d	2.70	j	0.1
c	2.39	q	0.09
u	2.05	z	0.05

이 통계는 알파벳만을 대상으로 한 것이 아니라 일반적인 영어 문장을 대상으로 한 것이므로 총 비율의 합은 100%가 아니다. 알파벳 외의 빈도는 Space가 15.17로 압도적으로 높고 마침표는 3.07로 h 다음이며 Enter는 1.34로 y 다음이다. 대문자 변환 비율은 3.35 정도 된다. Up 자리의 jqz는 다 더해 봐야 고작 0.3%의 빈도밖에 안되므로 배치에 크게 영향을 줄 정도는 아니다.

통계란 샘플에 따라 들쭉 날쭉할 수밖에 없다. 다른 사람이 조사한 영문 알파벳 통계도 이와 크게 틀리지 않은데 다음은 한 외국 사이트의 조사 결과이다.

E, T, AINOS, H, R, D, L, U, CM, F, WY, GP, B, V, K, Q, JX, Z

E와 T가 압도적으로 높은 것은 분명한 사실이고 AINOS가 동률인 것도 같다. 이후에는 내가 만든 통계와 약간 차이가 있는데 H와 R, C와 U의 순서가 다르다. Q가 JX보다 더 높게 나왔는데 이는 좀 잘못된 듯 하다. 다른 통계를 보면 JX가 동률이고 QZ가 그 절반으로 동률인데 이게 맞는 것 같다. 다음은 캠브리지 백과 사전의 통계라고 한다.

eatinorslhdcmufpgbywvkxjzq

상위권에 T보다 A가 더 높게 되어 있고 중간 부분도 조금씩 틀리고 Q가 제일 꼴찌이다. 역시 통계라는 것은 샘플에 따라 찾이가 많이 날 수밖에 없는 자료이다. 어떤 문장을 치는가에 따라 빈도가 달라질 수 있으므로 정확한 통계라는 게 큰 의미가 없다. 대충의 빈도만 참조해도 대충 빈도에 따른 배치를 만들 수 있으므로 너무 빈도에 연연하지 말자. 그냥 내가 뽑은 자료를 기준으로 하고 다른 자료는 참고용으로만 써야겠다.

② 빈도만을 기준으로 한다면 글판 만들기가 정말 쉬울 것이다. 그러나 사람의 언어를 대상으로 하므로 자주 쓰는 조합에 대해서도 고려를 해야 연타를 방지할 수 있고 리듬감을 살릴 수 있다. 다음은 연타가 자주 발생하는 글자 또는 단어들이다.

고빈도 연타 : wh, th, sh, er, an, ou, ed

고빈도 단어 : to, in, the, and, that, of, is

고빈도 철자 : ing, ion, ent

모음 다음에 가장 자주 오는 자음이 n : 따라서 n의 모음과 같은 열에 있으면 안됨

일반적인 영어 단어에 많이 나타나는 글자 순서이므로 가급적이면 좌우를 분리하거나 최소한 손가락이라도 분리하여 연타율을 줄이는 것이 좋다. 또 자주 입력되는 쌍을 인접 손가락에 두면 리듬감에도 보탬이 될 듯하다.

③ 좌우손의 분담율도 중요한 고려 대상이다. 두 손이 번갈아 가며 입력해야 양손 입력의 장점을 최대한 살릴 수 있고 피로도도 감소된다. 현재 통계상으로 좌우 분담률이 균형이 맞지 않아 오른손에 너무 무리가 많이 가는데 45:55 정도 비율로 맞춰야겠다. 여기서 주의할 것은 오른쪽에 공백이 있으므로 실제 문자만의 분담율만 따지면 45:55가 거의 균형이라는 점이다.

④ 행 비율도 고려한다. 손가락이 아래 위로 이동하는 것보다 중앙에서 계속 입력하는 것이 더 빠름은 물론이다. 중앙행 비율이 50% 정도 되는 것이 좋다. 쿼티는 30%, 드보락은 70%, 2벌식이 60%로 조사되어 있는데 이는 엄지열을 제외한 통계라 실제로는 50%에 근접만 해도 훌륭한 것이다.

⑤ 중요한 기준은 아니지만 쿼티 자판과도 호환된다면 좋다. 비슷한 위치에 글자들을 배치하면 처음 배우는 사람들이 쉽게 익숙해질 수 있고 거부감이 덜할 것이다. 그러나 실제로는 호환을 유지하는 것이 어려울 수도 있고 오히려 효율적인 자판 배치에 방해가 될 수도 있다. 비슷한 것보다는 아예 확 달라 버리는 게 배우는 입장에서 더 나을 수도 있다.

배치를 하기 전에 먼저 결정해야 할 것은 Up의 빈 자리에 무엇을 가지고 올 것인가인데 ZQ는 의심할 여지없이 UP 자리에 있어야 하고 X와 J 둘 중 하나이다. 빈도상으로는 X가 J보다 2배 더 높게 나타나지만 통계에 따라서는 J가 더 높은 경우도 있다. 둘 다 넣을 수 있다면 참 좋겠는데 키 하나가 정말 아쉬운 상황이다. 잠깐동안 고심한 결과 애초의 결정대로 X를 선택하기로 하자.

본인이 개발자이다 보니 XML, DirectX, X Window 등의 단어가 자꾸 떠 오른다. 또 Ctrl+X 단축키가 잘라내기로 사용되므로 문자가 있는 것이 좋다. 그랬더니 다른 개발자들이 Java, JScript, JQuery는 어쩌냐고 항의하는 듯 하지만 둘 다 선택할 수는 없으니 어쩔 수 없다. 둘의 빈도가 거의 같으므로 차후에 바꾸려면 X와 J의 자리만 바꾸면 간단하게 번복 가능하므로 지금 너무 고민할 필요가 없을 것 같다.

각각의 모든 기준을 다 만족시킬 수는 없으므로 우선 순위를 두고 여러 가지 시도를 해 보자. 기준이 되는 배치 몇개를 만든 후 다른 조건을 추가 고려하여 변형함으로써 최적화한다. 빈도를 최우선으로 배치하면 다음과 같다.

치기 쉬운 자리는 2행-1행-3행순, 집게-중-약-새끼순, 우좌순으로 선택했다. etoa의 자리는 거의 확정적이고 마지막의 x 자리도 거의 확정적이다. Cap 자리도 고민거리인데 빈도에 비해서는 자리가 좋지 못하다. 대문자 변환 비율로 따지만 r과 h 다음인데 이 비율상으로 보면 너무 구석에 쳐박아 놓은 것 같다.

그러나 빈도가 높다고 해서 글자 중간에 변환키를 두는 것은 마땅치 않은 것 같다. 또 현재 자리가 쿼티의 Caps Lock과 유사하므로 여기다 두는 것이 좋을 것 같다. 이 자판으로 배치한 후의 통계는 다음과 같다.

손가락, 손 연타율 : 10%, 43%

좌우 및 행 비율 : 40:59 19:44:14:21

연타 상위 항목 : eh(28000회), es(23000회), ou(11900회), ac, am, rt, do, gi

오른손의 부담이 너무 높다. 빈도가 가장 높은 e와 o 등이 주로 오른쪽에 배치되어 있기 때문이다. 또 공백이나 Up까지 오른쪽에 있다 보니 오른손이 왼손에 비해 너무 가혹하게 작업을 하는 것 같다.

연타율을 낮추려면 한글처럼 자음과 모음을 찢어 놓는 것이 어떨까 하는 생각이 든다. 한글과는 다르지만 자음과 모음이 적당히 섞여서 나타나는 것은 영어도 마찬가지이다. 한글은 자음이 항상 먼저 오므로 자좌우모이지만 영어는 그럴 필요가 없으므로 좌모우자 형식으로 배치해 보자. 드보락이 그렇게 되어 있으므로 이 방법이 합리적일 듯 하다. 모음이 한곳에 몰려 있으면 외우기도 좀 더 쉬울 것이다.

좌모우자를 우선으로 하고 빈도를 다음으로 고려하였다. 아직 연타율까지는 생각하지 않았다. 오른손 부담이 조금 줄어 들었다.

손가락, 손 연타율 : 8.9%, 38%

좌우 및 행 비율 : 43:56 20:43:14:21

연타 상위 항목 : ht(35000회), fo(12900회), am, rt, oy, ad

다음은 최대한 쿼티와 호환된 배치를 만들어 보기로 한다. 쿼티가 비록 엉망이기는 하지만 사람들이 많이 익숙해져 있으므로 빈도를 고려하여 적당히 조정하면 빠르게 적응할 수 있다는 이점이 있다. 쿼티의 알파벳은 가급적 제자리를 지키고 빈 자리에 빈도별로 배치해 보았다.

통계치는 다음과 같다.

손가락, 손 연타율 : 9.94%, 45.62%

좌우 및 행 비율 : 41:58 30:33:14:21

연타 상위 항목 : in, de, ar, ce, tu, lo

연타율이 상당히 높고 좌우 균형도 잘 맞지 않다. 행 비율은 정말 거의 최악의 수준이다. 그러나 막상 이 키보드로 타이핑을 해 보면 편안하다는 느낌이 드는데 그것은 아마도 쿼티 키보드에 너무 익숙해서일 것이다. 시험삼아 만들어는 봤지만 채택하고 싶은 생각은 없다. 어차피 쿼티가 아니므로 헷갈리기는 마찬가지인데 이왕 헷갈릴 거 비슷하게 헷갈리는 것보다 왕창 헷갈리는 게 더 낫다. 결국 빈도나 좌모우자의 기본 형태를 조정해야 한다.

빈도별 배치는 너무 기계적이라 sh, the, ou 등의 연타가 많이 발생하고 좌우 분담률이 너무 오른손에 몰려 있다. 다음과 같이 배치를 조정해 보았다.

-sh, the, ou 연타 방지를 위해 h와 u의 자리를 바꾸었다.

-오른손의 부담을 경감시키기 위해 kp, wx를 각각 교체하였다.

변경후의 통계 변화는 다음과 같다.

손가락 연타율 : 10 -> 8.6

좌우 분담률 : 40:59 -> 42:57

연타 상위 항목 : es(23000회), ac(9000회)

문제가 되었던 연타는 사라졌지만 es의 연타율이 아직도 너무 높다. 좌우 분담률은 소폭 개선되었다. 그러나 아무리 개선해도 그리 썩 마음에 들지 않는다.

좌모우좌 형태는 연타가 좀 덜 심한데 그래도 th와 of의 연타가 자주 발생한다. the, that, of, for 등의 전치사 입력에 불리하다. 그래서 다음과 같이 1차적으로 조정했다.

-of, for 연타 방지를 위해 a와 o의 자리 바꿈. 빈도상도 o가 더 높다.

-th 연타 방지를 위해 h와 d의 자리를 바꿈.

-중앙행 비율을 높이기 위해 g와 w를 바꿈

변경 후의 통계 변화는 다음과 같다. 손 연타율과 좌우 분담률은 거의 변화가 없고 손가락 연타율이 많이 줄었다. mo, rt 등의 새로운 연타들이 생겼지만 기존의 35000회, 12000회에 비해 회수가 많지 않다.

손가락 연타율 : 8.9 -> 6.31

행 비율 : 20:43:14:21 -> 21:44:13:21

연타 상위 항목 : mo(8300회), rt(7563회), ho(4485회)

테스트 결과 wh, th, er 등 고빈도 연타나 is, for, of, the, ing 등 고빈도 단어에 연타가 전혀 발생하지 않는다. 비교적 만족스러운 수준인 것 같다.

오늘 작업은 여기까지이다. 영어를 할 줄은 알지만 모국어가 아니다 보니 실제로 타이핑해 보며 테스트해 보지 못해 글판 배치가 적절한지 판단하기가 참 어렵다. 조정된 글판을 몇일간 계속 사용해 봐야 할 듯 하다.

12년 6월 4일

영문 글판 배치 작업을 계속 하고 있다. 더 이상 글쇠 수가 바뀌지는 않을 것 같고 가급적 빨리 익숙해져야 하므로 배치를 최대한 빨리 확정하는 것이 좋다. 그래서 시간이 좀 들더라도 혼자 많은 연습을 해 보아야 한다. 우리말이면 애국가를 쳐 보겠는데 영어이므로 마땅히 쳐 볼만한 문장이 없다. 그래서 학창시절부터 외우고 있던 링컨 아저씨의 게티즈버그 연설문을 쳐 보기로 했다. 다 칠 필요는 없고 앞 부분 일부만 타이핑해 보기로 한다. 좀 어려운 문장이지만 대소문자도 적절히 섞여 있고 구두점도 중간 중간에 삽입되어 있다.

Four score and seven years ago our fathers brought forth on this continent a new nation, conceived in Liberty, and dedicated to the proposition that all men are created equal.

Now we are engaged in a great civil war, testing whether that nation, or any nation, so conceived and so dedicated, can long endure. We are met on a great battle-field of that war.

먼저 빈도별로 배치한 자판으로 입력해 보았다. so, any, war 등이 한손 연타가 발생하며 왼쪽 구석의 w 자리가 예상보다 훨씬 더 불편했다. 빈도에 비해 자리가 너무 안 좋은 것 같다. Up 자리의 알파벳은 q가 딱 한번 나오는데 빈도가 떨어지다 보니 입력하는데 별로 불편하지 않았다. 이외에 마침표와 쉼표가 몇 개 나오지만 역시 바로 입력 가능했다.

다음은 좌모우자 자판으로 입력해 보았다. 아직 자리를 외우지 않은 상태라 그런지 모음이 왼쪽에 모여 있다는 것이 상당히 직관적이었고 좌우로 배분이 잘 되어 있다. 자주 사용하는 다음 단어들이 좌우로 균등하게 잘 배분되어 있어 손 연타율이 낮고 리듬감이 있다.

is, are, on, to, and, but, that, the, at, can, for, no, not, so, with

am, you, of 등은 손 연타가 발생하지만 최소한 손가락 연타는 아니어서 그다지 불편하다고 느껴지지는 않았다.

다음은 이전 배치인 0.92 버전으로 입력해 보았다. 모든 글판을 다 외우지 않고 찾아서 치는 시점이라 그다지 불편하다고 느껴지지는 않았다. ion 같은 고빈도 철자가 한손 연타로 몰려 있어 리듬감에 좋지 않다. r같은 빈도 높은 글자가 아래열에 있고 구석에 b, k 같은 글자들이 있어 배치는 좋지 않은 편이다. 아랫열이 윗열보다는 확실히 접근성이 떨어진다. 이 자판에서 x의 자리는 너무 아깝다.

쿼티 키보드로도 입력해 보았다. 외우고 있으니 역시 빠르고 쉽다. 키보드를 보지 않고 칠 수 있으며 마침표나 쉼표를 바로 누를 수 있다는 것도 편리했다. 그러나 t, b 등 손가락이 제자리를 벗어나는 것이 무척 불편하게 느껴졌으며 a같이 빈도가 높은 글자가 새끼 손가락에 배정되어 있다는 점은 역시 단점이다. 대문자 입력을 위해 누르는 Shift도 익숙해서 그렇지 새끼 손가락인데다 자리를 벗어나 고속에는 불리하다. 또 Shift가 양쪽에 있지만 실제로는 F나 L이나 둘 다 왼쪽 쉬프트만 사용하고 있다. 개인적인 버릇이겠지만 굳이 양쪽에 있을 필요까지는 없어 보인다.

여기까지 연습 및 테스트해 본 결과 외우지 않은 상태에서 단기간에 문장 몇 개를 입력해 보고 글판 배치의 효율성을 판단하는 것은 거의 불가능하다는 것을 깨달았다. 기껏해야 좌우가 잘 분담되는지, 연타가 자주 발생하는지 정도만 볼 수 있을 뿐이다. 제대로 테스트해 보려면 자판을 다 외우고 고속으로 입력해 봐야 하는데 그러자면 먼저 자판을 확정해야 하는 재귀적인 문제가 있다.

장기적으로 더 테스트해 봐야겠지만 현재는 느낌보다는 데이터에 기반하여 배치할 수밖에 없다. 그러나 현재 데이터라고는 빈도와 연타율 정도밖에 없어 좀 더 상세한 정보가 필요하다. 통계 프로그램을 수정하여 최대한 많은 정보를 뽑아낼 수 있도록 수정해야겠다. 테스트하면서 다음 기능들이 필요하다고 느꼈다.

- 엄지를 제외하고 순수한 문자들에 대해서만 좌우 분담률 계산. 정확하게 50%씩 분담되는 것이 이상적이다.

- 행 비율도 4열을 제외하고 1,2,3행만에 대한 비율 따로 조사할 것. 중앙행 비율이 50%에 근접하는 것이 목표이다.

- 손연타가 자주 발생하는 철자들의 발생 빈도 조사. 연타는 어쩔 수 없는 문제이지만 6연타, 7연타까지 발생하는 것은 아무래도 비효율적이다. 통계를 통해 이를 적발해 내고 수정하고자 한다.

배치를 하다 말고 다시 코딩 작업에 들어갔다. 내가 개발자라는 것이 이럴 때는 참 편하다. 기획, 개발이 분리되어 있으면 회의를 해야겠지만 혼자 개발도 하고 기획도 하니 원하는대로 할 수 있어서 참 좋다. 코드 작성하는데 대략 2시간 정도 걸렸다. 새로 작성한 기능으로 뽑은 통계로부터 꽤 의미있는 분석 결과를 얻었다.

배치	빈도별	자모 분리
손가락 비율	6:7:10:17-21:15:11:7:2	4:8:11:19-21:13:10:7:3
1행:2행:3행:4행	19:43:15:21	21:44:13:21
1행:2행:3행	24:55:20	26:56:16
손가락 연타율	8.61	6.31
손 연타율	42.26	38.37
좌우 분담율	42:57	43:56
좌우 분담율(엄지 제외)	53:46	55:44
손가락 연타	es(23728) ac(9184) am(8552) su(7656) rt(7563) do(6994)	mo(8348) rt(7563) ho(4485) ei(3673) space-enter(3643) space-up(3000)
손연타 항목	rry(1305) art(888) dis(856) ant(804) all(786) eve(753)	you(1088) str(675) mme(458) ake(440) xam(294) tst(284)
4연타 이상	ally(437) deve(293) visio(268) tract(245) does(235) ggod(131) warranty(33) debugged(1)	make(45) xami(25) amou(24) huff(22) uaff(22) maximum(1) mommy(1) yahoo(1)

손가락 비율은 둘 다 중앙에 잘 집중되어 있으며 행 비율도 둘 다 합리적이다. 중앙행의 비율이 55%를 넘어가니 가운데 행에서 절반 이상을 입력할 수 있는 셈이다. 좌우 분담률도 대동 소이하며 둘 다 적당한 수준이다. 엄지를 포함하면 오른손에 부담이 많이 가지만 문자만으로 비교하면 역전된다. 사실 왼손 엄지도 놀고 있지는 않으므로 이 정도 비율이면 거의 50%씩 분담한다고 볼 수 있다.

아쉽게도 왼손 엄지가 얼마나 일을 많이 하는지는 문서나 입력 형태에 따라 천차만별이라 정확하게 계산할 수가 없다. 사실 오른손도 그런데 BS를 얼마나 자주 누르는가에 따라 빈도에 차이가 발생하기 때문이다. 그래서 분담률은 대충 맞으면 그냥 되는 것이다.

가장 차이가 많이 발생하는 부분은 연타율이다. 손가락 연타를 보면 빈도별 배치는 es가 23000회나 발생하는데 비해 자모 배치는 가장 높은 연타율을 보이는 mo도 8300회밖에 되지 않는다. 연타는 어쩔 수 없이 발생할 수밖에 없지만 회수상으로 보면 역시 자음과 모음을 분리한 쪽이 훨씬 덜하다.

손연타 항목의 결과는 더 심각하다. 자모 분리의 경우는 you와 str의 빈도가 높은 정도이지만 빈도별의 경우는 꽤 많은 철자들에서 손연타가 많이 발생한다. 4연타 이상의 경우를 보면 자모 분리의 경우 make가 가장 심각하지만 고작 45회에 불과하고 가장 심한 경우인 maximum은 빈도가 딱 1번 밖에 되지 않는다. 그러나 빈도별은 많은 단어에서 손연타가 발생하며 그것도 5연타, 6연타가 아주 흔하다. warranty는 무려 8연타나 되며 빈도도 적지 않다.

이 통계로부터 처음 예상과는 달리 빈도별로 글판을 배치하는 것이 무모하다는 소중한 결론을 도출했다. 인간의 언어 구조상 자음과 모음은 골고루 섞여서 나타나므로 이 두 부류를 좌우로 나누면 확실히 연타가 줄어들고 리듬감이 살아나는 효과가 있다. 즉, 글판을 배치하는 첫번째 원칙은 자음과 모음을 분리하는 것이고 두 번째 원칙이 빈도이다. 그리고 연타 방지와 리듬감 등의 세부 원칙을 적용하여 조정하는 것이 적합한 것 같다. 따라서 이후는 자모 분리형을 기본으로 해서 조정해 나갈 것이다.

그럼 지금까지 조사한 통계와 원칙들을 바탕으로 자판을 처음부터 차근 차근 단계별로 다시 배치해 보자.

1.Cap 자리는 왼손 집게로 고정한다. 이유는 앞에서 언급했었다.

2.남은 23개 키에 배치되지 못하는 글자는 빈도가 낮은 jqz로 확정하고 up 위치의 1열에 배치한다. 중앙은 구두점을 위해 비워 두어야 하므로 위로 갈 수밖에 없으며 Up과의 연타를 고려하면 왼쪽에 있어야 한다.

3.좌모우자의 원칙에 따라 모음을 배치하고 t도 같이 배치한다. 이들의 자리는 거의 확정적이다.

4.빈도가 떨어지는 bvkx는 새끼 손가락 모퉁이에 배치한다. 여기까지 확정된 키들은 다음과 같이 배치된다.

이 배치의 근거는 다음과 같다.

- 모음은 모두 왼쪽에 모은다. 가장 빈도가 높은 e가 가운데 집게 손가락이다.

- oaiu는 빈도에 따라 왼쪽에 배치한다. 이때 u는 1열 중지 자리가 더 좋지만 ou의 연타 빈도가 높으므로 3열 집게로 내렸다.

- 자음중 빈도가 가장 높은 t는 오른손 집게 자리를 내 준다. 다른 선택이 없다.

5. 다음 빈도인 nsrh는 접근성 순위에 따라 배치한다.

- n, s : 빈도에 따라 배치했다. 모음 다음에 가장 빈번하게 오는 자음이 n이므로 반드시 오른쪽에 있어야 한다. s도 마찬가지이다. n과 s는 빈도 차이가 얼마 나지 않으므로 필요에 따라 바꿀 수도 있다.

- r, h : h는 t와 함께 연타되는 경우가 많으므로 t와 다른 열에 있어야 하며 손도 분리하는 것이 좋다. r도 t와 함께 종종 사용되지만 접근성이 좋은 곳에 두었다.

6.다음 순위인 ldcum에서 u는 자리가 확정되었으므로 ldcm을 배치한다.

초안과는 다르게 접근성 위주로 배치했다. c가 새끼 손가락 위치이지만 2행이라 더 치기 쉽다고 판단했다. rt와 m, l과 n, d와 s는 모두 연타율이 높지 않은 철자이다.

7.마지막 남은 pfgyw를 다음과 같이 배치한다.

-w와 y는 영어에서 반모음이라고도 하고 반자음이라고도 한다. 분류상 모음이라고도 할 수 있지만 이 철자들이 사용되는 단어를 보면 yes, year, play, blow, world 등과 같이 모음과 이어지는 경우가 많다. 따라서 모음 자리보다는 자음 자리에 있는 것이 연타 방지에 바람직하다고 판단했다. s와 w는 연타 빈도가 높으므로 찢어 놓았다.

- f는 of, for 등의 전치사에서 o와 연타되는 경우가 많으므로 o와는 다른 열에 두어야 한다. g와 자리를 바꿀 수도 있다.

- p는 마지막 남은 한 자리를 채워 넣는다. op 연타도 있지만 그리 많은 것 같지는 않다. g와 자리를 바꿀 수도 있다.

여기까지 2차 수정한 결과의 통계 변화는 다음과 같다. 행 비율이나 연타율에서 약간 개선된 듯하다.

손가락 비율 : 4:8:11:19-21:13:10:7:3 -> 4:8:11:19 21:13:9:8:4 => 왼손은 거의 변화가 없고 오른손 약지와 집게의 비율이 조금씩 상승했다. c가 집게에 배치되어서 그런 듯 하다.

행 비율 : 26:56:16 -> 28:57:14 => 1행과 2행의 비중이 높아지고 3행의 비중이 조금 줄어 들었다.

손가락 연타율 : 6.31 -> 6.03 => 비록 근소하지만 연타율이 줄어들었다.

손 연타율 : 38.37 -> 38.31 => 별 변화가 없다.

좌우 분담률 : 55:44로 변화가 거의 없다.

연타율 : 제일 비중이 높았던 mo가 연타 목록에서 사라졌다. rt, ho는 그대로 있고 op(5486), ag(3797) 연타가 새로 등장했다.

손연타 : y가 오른쪽으로 감으로써 you가 손연타 목록에서 사라졌다. str은 그대로 있고 mme는 사라졌다. ffe(594)와 ugh(525) 연타는 새로 등장했다. 4연타짜리 make(45)는 사라졌지만 keep(16)이 새로 등장했다. system을 입력할 때 syst까지 4연타도 319회나 발생했다.

이 배치로 문장을 타이핑해 보니 ago가 왼손으로 연타되는 것이 마음에 안들고 c가 중앙행이지만 새끼 손가락 자리에 있어 접근이 용이하지 않았다. 하지만 전반적으로 좌우 교대가 잘 이루어져 있어 리듬감이 느껴졌다. 반자음을 오른쪽으로 옮긴 것은 탁월한 판단이었다.

tr과 ho 연타율이 여전히 높은 것이 거슬리지만 별다른 뾰족한 대책이 없다. 4.45%의 r을 2.97%의 l과 자리를 맞바꾸는 것은 접근성을 너무 많이 포기하는 것이다. 그래도 일단 바꾸어는 보았다. rt 연타는 사라졌지만 13:9 였던 두 손가락의 비중이 11:10으로 비슷해져 버리는 부작용이 나타난다. 그래서 원래대로 롤백했다.

h는 t와는 반드시 다른 손에 있어야 하고 이 정도 빈도의 접근성을 확보하려면 f와 바꾸는 수밖에 없는데 f가 h로 오면 of연타가 많이 발생할 것이다. 즉 하나를 해결하려고 자리를 바꾸면 또 다른 문제가 다시 생기는 식이다. 일종의 풍선 효과라고 할 수 있다.

b의 자리가 비록 외지기는 하지만 윗열이라서 접근성이 좋다. 이에 비해 빈도가 훨씬 더 높은 p가 아래열에 있어 불만이다. 그래서 p와 b의 자리를 바꾸되 b한테 p의 자리는 너무 아까운 것 같으므로 다시 g와 b를 바꾼다. 즉, bpg를 서로 한바퀴 돌리는 것이다. 결과는 다음과 같다.

통계상으로 op(5486) 연타가 사라졌다. 그러나 ab(3905) 연타가 새로 생겼다. 좌우 분담률이 55:44에서 54:45로 오른쪽이 조금 더 높아졌다. 나머지 통계는 큰 변화가 없다.

오늘 작업은 여기까지이다. 더 바꿔볼만한 부분이 많지만 지금 당장은 바꿔 봐야 다른 곳에서 또 다른 문제가 생길 것이므로 이 정도 배치해 두고 이제는 실제로 사용을 해 봐야겠다. 본격적인 타이핑 연습을 해야 할 때이다.

알파벳 A~Z까지 순서대로 쳐 봤는데 처음 치는데 33초가 걸렸다. 조금 연습하니 24초로 줄어들고 18초까지 단축되었는데 10초 내로 치는 것은 어렵지 않을 것 같다. 참고로 쿼티 자판의 경우 고작 3초면 다 칠 수 있다. 아너림 자판은 Up의 개념이 있고 테스트 키보드를 쿼티로 쓰고 있기 때문에 아직은 속도를 내기 어렵다.

12년 6월 6일

■ 이틀동안 영문 자판 테스트와 코딩을 열심히 수행했다. 내가 이렇게 편안하게 코딩에 임할 수 있는 것은 다 나라를 지키기 위해 자신을 희생하신 분들이 있기 때문이다. 코딩중에 10초간 묵념.

■ 확정된 것은 아니지만 영문 자판 배치가 진행되고 있으므로 연습을 계속 했다. 직접 배치한 자판이다 보니 자리는 어렵지 않게 외워진다. 그러나 머리가 외우는 것은 아무 짝에도 쓸모가 없는 모양이다. a를 칠 때 손은 자꾸 Cap키를 누르고 r을 누를 때 왼손 집게가 습관적으로 들썩거린다. 자판이란 결국 손가락이 외워야 하는 것이다. 적어도 일주일 정도 맹 훈련을 해 봐야겠다.

■ 이제 키 개수와 배치가 어느 정도 진행되었으므로 안드로이드 버전도 0.93으로 업그레이드 했다. 데스크탑에서와는 느낌이 어떻게 다른지도 알아 봐야 하고 외출했을 때도 자판 연습과 고민을 하기 위해 안드로이드 키보드도 같이 보조를 맞추어 업그레이드되어야 한다. 짧은 몇 일이지만 워낙 바뀐 것이 많다 보니 코딩양이 상당했다. Sym 모드가 새로 들어가고 숫자와 기호가 일괄적으로 이사를 다녔으며 모드를 변환하는 방법도 상당히 많이 바뀌었다. 완벽하지는 않지만 데스크탑 버전과 동일하게 동작하도록 모두 수정했다.

■ 그동안 발견된 버그도 수정했다. 편집 모드의 커서 이동키가 중앙에 있었는데 아래로 내리고 모드간의 전환이 부자연스러운 문제도 해결했다. 구글 마켓에서 Enter키를 눌러 검색이 안되는 버그도 있었는데 이 문제는 \r 코드를 보내서 해결되지 않으며 Enter키를 직접 눌렀다 떼는 코드를 실행해야 했다. 어려운 문제일 수도 있는데 다행히 샘플 예제에서 해결책을 찾아 적용했다.

데스크탑 버전과 완벽하게 똑같이 동작하도록 만드는 것이 좋겠으나 여러 가지 이유로 차이점이 있다. 모바일 키보드는 데스크탑에 비해 다음과 같은 특징이 있으며 그래서 별도의 해결책들이 필요하다.

1.제자리 특성이 없어서 Up + Space 입력이 무척 불편하다. 결국 BS 키는 꼭 필요하다. Del키를 추가하는 대신 Up + Space의 기능은 제거했다. Up 자리의 문자 입력은 투 터치라 그렇지 별로 불편하지는 않다.

2.키 홀드가 안된다. 숫자 입력하려면 숫자 모드로 바꾸고 입력해야 하므로 속도가 빠르지 못하다. 다른 모바일 키보드도 이 점은 마찬가지이되 대신 밀기나 오래 누르기 같은 기법을 사용할 수는 있다.

3.양손 엄지로만 치므로 빈도별로 배치한 것이 별 도움이 안된다. 오히려 손가락이 가운데로 몰려 엉키기만 한다. 그래서 중앙의 폭을 좀 더 넓게 잡아 주었다.

4.손가락 연타가 속도에 영향을 미치지 않는다. 오히려 운지 거리가 짧아져 고속 입력에 더 도움이 된다. 하지만 손 연타는 적을수록 양손 엄지가 교대로 입력하므로 리듬감이 있다.

결국 데스크탑과 호환되는 모바일 키보드를 제공한다는 것만 의미가 있을 뿐 다른 모바일 키보드에 비해 별다른 장점이 없는 셈이다. 누군가가 안드로이드의 아너림 키보드를 보면 "뭐 이딴게 다 있냐?"고 투덜댈 것이다. 수정된 키보드의 모습은 다음과 같다.

이 배치가 나온데도 복잡한 사연이 있다. Del키가 추가되어 있는데 자리가 정 가운데이다. 원래는 Del키를 제일 오른쪽에 두었는데 그러다 보니 Up키가 가운데를 차지했다. 이 상태에서 입력해 보면 구두점이나 ㄲ, ㄸ 등을 입력할 때 Up키를 누르는 손가락과 문자를 치는 손가락이 엉킨다. 데스크 탑에서는 Up과 문자키의 손가락이 달라 아무 문제가 없지만 모바일은 배정된 손가락이 따로 없기 때문에 위치가 비슷하면 더 불편해진다.

Up 키와 공백키의 순서를 바꾸는 방법도 생각해 봤는데 그러면 데스크탑 키보드와의 일관성이 깨져 버린다. 그래서 어쩔 수 없이 Del키가 가운데에 오게 된 것이다. 이 상태로 입력해 보면 Up이 약간 오른쪽으로 벗어나 있어 문자를 누르는 손가락과 겹치지 않았다. 또 하단 버튼의 폭을 배분하는데도 상당히 애를 먹었다. 원래는 공백과 한영수 버튼을 좀 더 길게 만들고 싶었는데 그랬더니 한글 모드의 버튼 폭이 다른 모드와는 달라지는 희한한 문제가 생겼다. 원인은 아직도 모르며 실수 절사의 문제가 아닌가 짐작되며 아무래도 안드로이드의 버그인 것 같다. 그래서 어쩔 수 없이 버그가 없는 쪽으로 폭을 맞춘 것이다.

■ 더블 푸시 간격을 조정했다. 안드로이드 프로젝트는 0.5초로 되어 있고 PC용 연습 프로그램은 0.3초로 되어 있는데 0.5초는 너무 길다. 실제 테스트해 보니 0.2초만 되어도 충분했다. 타자를 대충 빨리 치는 사람은 600타 정도 치는데 이 속도면 키 누르는데 0.1초밖에 걸리지 않는다는 얘기다. 따라서 한 키를 두 번 누르는 정도는 0.05초면 족하다. 0.2초로 해도 실제 사용하는데 불편은 없었다. 하지만 PC와 싱크를 맞추기 위해 0.3초로 조정해 두었다. 이 간격도 차후 정밀하게 튜닝해야 할 대상이다.

■ 대충 배치해 놓았던 이모티콘을 새로 배치했다. 현재 3페이지로 기획되어 있는데 배치할만한 이모티콘을 뽑아 보니 4~5 페이지는 충분히 될 것 같다. 그렇다고 무리하게 늘릴 필요는 없으므로 3페이지만 배치했다. 각 페이지의 이모티콘 배치는 다음 도표와 같다. Prev, Next 버튼이 있으므로 페이지당 22개의 문자를 배치할 수 있다.

페이지 1	★☆☎☏☞☜♨ ●○⊙◎■□▣ ♠♤◆◇♥♡♣♧
페이지 2	♩♪♬♭♀♂© 『』【】〔〕® ※∴∵∞•…‼§
페이지 3	£¥€₩₣‰℃ ←↑→↓↔⇔↕ ▲△▶▷▼▽◀◁
기타	①②③④⑤⑥⑦⑧⑨⑩ⅰⅱⅲⅳⅴ↖↗↘↙⇒∑ℓ

이모티콘 배치에도 몇 가지 문제가 있다. 유니코드 문자표에 있더라도 실제로는 제대로 나오지 않는 문자들이 몇 가지 있다. 이런 문자는 어쩔 수 없이 제외했다. 모양이 다르게 나오는 경우도 있는데 예를 들어 원 표시는 W에 가로줄 2개 그어진 형태이지만 안드로이드에서는 K에 가로줄로 나타난다. 또 다이아몬드 표시는 너무 작게 나타나 하트나 스페이드와는 크기가 다르다.

데스크탑 키보드의 이모티콘도 안드로이드와 동일하게 맞추었는데 제대로 표시되지 않는 문자들이 꽤 많다. 그렇다고 대체 문자를 찾아 넣기도 귀찮고 해서 일단은 ?를 대신 표시했다. 윈도우에서 이 문자들이 나오지 않는 이유는 정확하게 파악하고 있는데 현재 프로젝트가 ANSI 문자셋으로 되어 있어서 유니코드와는 표현 가능한 문자의 종류가 다르기 때문이다. 차후 프로젝트를 유니코드로 바꾸면 자연스럽게 해결될 문제이다.

데스크탑에는 이모티콘 기능을 아예 빼 버릴까 생각중인데 사실 하드웨어 키보드에는 이 기능이 전혀 쓸모가 없다. 모바일에서는 꼭 필요하기 때문에 일관성을 위해 넣어둔 것 뿐이다.

■ 연습 프로그램의 버그 수정. Up 상태에서 모드를 바꿀 때 Up이 풀리지 않는 문제, 모드 변경시 한글 조립이 풀리지 않는 문제 등을 수정했다.

■ 모드를 변경할 때 한글 조립, Upper 상태, 기호 락, 대문자 모드 등을 모두 해제하는데 이 중 대문자에 대해서는 예외를 적용했다. 임시적인 대문자 상태라면 모드 변경시 소문자로 돌리는 것이 맞지만 대문자를 고정한 상태라면 모드를 바꾸어도 계속 대문자 상태를 유지하는 것이 옳다.

■ 편집 모드의 배치에 중대한 논리적 오류를 발견했다. 쿼티 키보드에 있는 모든 키를 다 누를 수 있어야 하므로 Scoll Lock, Pause 같은 키까지 다 배치해 놓고는 정작 BS키를 빼 먹었다. BS가 있다가 Up + Space로 바뀌었는데 그렇다고 하더라도 BS키 자체를 누를 수는 있어야 한다. 또한 커서 이동 중에 바로 앞 글자를 지울 경우가 많은데 이때 Up + Space를 누를 수는 없으므로 BS키가 꼭 필요하다. 그래서 편집 모드의 키 배치를 조정했다.

커서 이동키 오른쪽에 BS키를 따로 배치했다. Insert는 위로 올라가고 Pause는 왼쪽으로 이동했다. 한자키를 제거했는데 그래도 되는지 모르겠다. 차후 필요하다면 Sleep을 �i아 내고 한자키를 다시 초빙해 와야겠다. BS를 넣어 보니 입력중에 오타 편집에 상당히 편리했다.

■ 이상 여기까지 안드로이드 키보드 개발은 다시 일단락 짓는다. 2가지 개발 환경을 왔다리 갔다리 하면서 개발해 보니 진짜 인간이 할 짓이 아니다. 프로젝트 구조도 다르고 변수명도 조금씩 틀리고 오토마타도 다르고 여러 모로 다른 점이 많아 무진장 헷갈린다. 개발툴의 단축키나 편집기 사용 방법도 조금씩 달라 작업을 스위칭할 때마다 머리가 아프다.

안드로이드 키보드는 어차피 메인이 아니므로 굳이 버전을 일일이 따라갈 필요는 없다. 큰 틀에서 비슷하게 만들어 놨으므로 약간의 디버깅만 한 후 0.93 버전 릴리즈할 때 일단락 지어 놓기로 한다.

■ 영타 연습을 꾸준히 진행하고 있다. 자꾸 치다 보니 오른쪽 새끼 손가락 자리가 무척이나 어색하다. 쿼티 키보드에 원래 문자가 없는 영역이고 / 기호도 자주 입력하는 영역이 아니라서 습관이 되어 있지 않다. 반면 왼쪽 새끼 손가락은 알파벳 z가 있고 Shift나 Ctrl키를 자주 누르므로 덜 어색하다.

연습 문장을 이것 저것 바꿔 보면서 해 보고 있는데 아무래도 연설문은 너무 고리타분한 것 같다. 그래서 팝송으로 바꾸었다. 지금 연습하고 있는 문장은 Yesterday 팝송 가사 앞부분이다. 약어가 많아 '의 비중이 무척 높고 대문자가 많이 나온다.

Yesterday all my troubles seemed so far away. Now it looks as though they're here to stay. Oh, I believe in yesterday.

Suddenly, I'm not half the man I used to be. There's a shadow hanging over me. Oh, yesterday came suddenly.

Why she had to go, I don't know, she wouldn't say. I said something wrong, now I long for yesterday.

they're나 I'm, don't 등에 어포스트로피가 자주 등장하는데 이 샘플을 보고 무척이나 긴장했었다. 그동안 어포스트로피가 기호중에 가장 빈도가 떨어지는 것으로 판단하고 제일 구석 자리를 배정했기 때문이다. 알고 보니 영문에서도 어포스트로피 대신 홑따옴표를 쓰는 것 같다. 홑따옴표는 Up 자리에 있으므로 천만 다행이다.

비틀즈의 음악을 들어 보면 저 가사를 다 부르는데 56초가 걸린다. 아너림으로 쳐 보니 576초가 걸리는데 10배가 더 넘는다. 오타를 다 수정하고 구두점까지 정확하게 입력했다. 물론 아직까지 연습이 안된 상태라 그렇다. 쿼티로 쳐 보니 96초 정도가 걸리는데 본인의 영타 실력이 그다지 탁월한 편은 아니어서 빠른 사람은 노래 가사를 충분히 받아 칠 수 있는 수준이다. 익숙해지면 아너림으로도 얼마든지 가능할 듯 하다.

though에서 5연타가 발생하는데 같은 손으로 5글자를 치니 살짝 기분이 나빠졌다. 확실히 5연타는 좀 심한 것 같다. 그런데 쿼티에서는 yesterday의 중간이 전부 왼손이라 무려 7연타도 발생한다. 가장 긴 쿼티 연타는 steardess로 무려 10연타이다. 역시 영어는 연타에 약한 언어이다. Shift, 홑따옴표 입력을 위해 손이 자주 홈 포지션을 벗어나며 BS나 엔터도 마찬가지이다. 그래도 손이 정확하게 제 자리로 잘 돌아오는데 그만큼 연습이 많이 되어 있다는 얘기이다.

여기까지 작업한 결과를 0.93으로 릴리즈한다. 완성되어서 릴리즈하는 것이 아니라 중간 중간의 변화 과정을 기록할 필요가 있기 때문이다. 아직 영문 자판은 한참 더 배치를 수정해야 한다.

12년 6월 7일

영타 연습을 계속 하던 중에 중요한 사실을 발견했다. 발견했다기 보다는 연습중에 느낌을 받았다고 하는 것이 옳겠다. 자꾸 연습하다 보니 처음 생각과 뭔가 다르다는 느낌이 왔다.

- 집게와 중지, 약지 세 손가락의 힘이나 숙련도는 예상과는 달리 별 차이가 없다. 물론 집게 손가락이 힘이 조금 더 좋은 것은 사실이지만 중지나 약지도 집게 못지 않게 힘이 좋고 타이핑에 무리가 없다. 반면 새끼 손가락은 확실히 힘이 떨어지고 엄지는 문자 타이핑 영도로 적합하지 않다. 현재 손가락 분담률은 다음과 같다.

왼손 = 4:7:11:19

오른손 = 13:9:8:4

집게 손가락에 너무 과중한 부담을 주고 있는데 이보다는 중지 약지에도 부담을 골고루 분산시켜 집게의 90% 정도를 분담하는 것이 더 좋다. 현재 구조에서 rl, hi 정도는 위치를 바꾸어도 무난하다. 집게 손가락이 힘이 더 쎄다고 생각한 근거는 쿼티나 2벌식에서 집게는 다른 손가락에 비해 무려 6개의 키를 담당하고 있기 때문이다.

- 행중에는 홈 포지션인 2행이 가장 치기 쉽고 유리함은 물론이다. 1행과 3행은 손가락이 이동해야 하므로 2행에 비해 속도가 느리고 치기도 어려운데 이 두 행을 지금까지는 거의 비슷하다고 생각했었다. 그러나 막상 실습을 해 보니 아래쪽의 3행보다는 위쪽의 1행이 훨씬 더 치기 쉬웠다. 손가락을 오므리는 것보다는 뻗는 것이 훨씬 더 쉽고 자연스럽기 때문이다. 물론 지금도 행 비율은 28:57:13으로 1행에 훨씬 더 비중이 높게 설정되어 있지만 집게 3행과 중지, 약지 3행의 접근성은 조정할 필요가 있다.

이 2가지 사실에 근거하여 각 손가락 위치의 접근성을 다시 평가해 보면 다음과 같은 결과가 도출된다. 손은 좌우 대칭이므로 오른손만 보이면 다음과 같다.

지존의 자리는 홈 포지션인 1번이며 다음은 2와 3이되 2, 3의 접근성 차이는 거의 없다. 4번까지는 순위가 같되 5번부터가 달라진다. 기존에는 집게 3행이 더 접근성이 높다고 생각했는데 지금은 중지 1행이 더 좋은 것으로 생각이 바뀌었다. 5, 6번의 접근성도 별로 큰 차이는 없다.

6번 다음 순위는 비록 새끼 손가락이지만 이동없이 제자리에서 누를 수 있는 새끼 2행이다. 집게 3행보다 접근성이 더 좋다고는 할 수 없지만 고속 입력에는 훨씬 더 중요한 자리이다. 다음 순위는 8, 9, 10이고 마지막으로 새끼 손가락의 1행, 3행순이다. 새끼 3행은 접근성이 가장 떨어지고 익숙해지기도 쉽지 않다.

연타에 대해서도 좀 더 근본적인 대책이 필요하다. 피하기 위해 자리를 바꾸면 또 다른 연타가 발생한다. 그래서 영문 연철 자체를 미리 조사할 필요가 있다. 통계 프로그램을 수정하여 연철이 자주 발생하는 철자들을 조사했다. 공백이나 구두점으로 분리된 단어들은 연철로 인정하지 않는다. 또한 tr, rt 연철은 순서에 상관없이 둘 다 연타가 되므로 두 순서의 발생 빈도를 합쳐서 조사할 필요가 있다.

이 모든 요건에 맞게 통계 프로그램을 수정하여 연철 조사 기능을 작성했다. 약간 시간이 걸리기는 했지만 이 정보도 배치에 꽤 유용하게 참조될 듯하다. 다음은 통계용 샘플에서 연타를 조사한 결과이다. 왼쪽은 순서별로 뽑은 것이고 오른쪽은 순서를 무시하고 뽑은 것이다. 이때 + 의 왼쪽은 정순서이고 오른쪽은 역순서이다.

연철이 가장 많이 발생하는 철자는 통계에서 보다시피 th이다. he와 in도 발생 빈도가 꽤 높으며 er과 re도 상위권이다. 순서를 무시하고 연철 순위를 뽑아 보면 er이 가장 높고 ht가 그 다음이다. 다행스러운 것은 대부분 자음과 모음의 연철이라 좌모우자만 잘 지켜도 상당수의 연타를 피할 수 있다. 이것이 안될 때는 손가락 연타라도 피하도록 배치해야 한다. 발생 회수 10000회 이상에서 자모 연철이 아닌 것은 다음과 같다.

자음 연철 : ht(36200), st(14200), dn(12000), gn(12000), nt(10300), ns(7900), rt(7700)

모음 연철 : ou(12000), io(8600), ae(6200), ai(5200), ei(3800), au(2100), iu(1400), eu(1000), eo(954), ao(580)

모음 연철은 ou가 조금 높을 뿐 나머지는 그리 심각하지 않다. 예쁜 iu는 1400밖에 안된다. 배치와는 상관이 없지만 통계를 뽑은 김에 낮은 순위도 살펴 보자.

0 회 발생 : xz, gx, vz, jl, oq 등등 주로 xzq 등의 저빈도 문자들

1 회 발생 : pz, fv, jk

이 통계로부터 좌모우자가 연타 감소에 얼마나 도움이 되는지를 확인했다. 모음의 경우 연타 방지를 위해서 o와 i, u는 반드시 다른 열에 있어야 하며 a, e는 연타 빈도가 떨어지므로 같은 열이어도 상관없다. a를 굳이 2행에 둘 필요없이 o위에 얹어도 연타에는 불리하지 않다.

왼쪽에 모음외에도 불가피하게 자음이 와야 하는데 어떤 자음을 어디다 배치할 것인지를 판단할 수 있는 여러 가지 정보들을 뽑아낼 수 있다. TNSR의 고빈도 자음은 물론이고 D, L 등의 중빈도 자음도 반드시 오른쪽에 배치해야 한다.

이 기준에 근거하여 자판을 처음부터 다시 배치해 보자. 배치의 원칙은 좌모우좌, 빈도에 따른 위치 할당, 연타율 최소화 등으로 이전과 동일하되 손가락의 접근성 순위가 바뀌었으므로 배치가 다소 변경될 것이다. 여러 가지 시도를 해 보았는데 중간 단계는 생략하고 결과로 나온 배치 순서만 보인다.

1.Cap과 자음 t자리는 고정. 모음 eoaiu 배치. 빈도가 가장 높은 e를 집게 자리의 가장 좋은 곳에 먼저 배치. oa의 연타율이 낮으므로 아래 위로 배치하고 i와 u는 o와 다른 열에 두었다. a가 어쩔 수 없이 1행으로 올라가고 e위쪽을 비웠는데 집게 손가락의 부담을 경감시키기 위해서다.

2.nsr을 배치한다. ns는 고빈도 문자이므로 별 고민없이 접근성이 좋은 자리를 순서대로 내 주었다. r의 경우 tr 연철이 7700이고 nr 연철이 1100밖에 안되므로 n위에 r을 둔다. 손가락 분배를 위해 t위쪽은 남겨 두었다.

3.h가 가장 고민이다. th의 연타가 워낙 높으므로 손 연타 방지를 위해 왼쪽에 둔다. he의 연철이 높고 왼손 집게의 부담이 크므로 e위에 둘 수는 없다. hi는 6900, ho는 4500이되 접근성이 좋은 i 위에 배치했다. hi 연타도 꽤 되지만 포기한다.

4.ldc를 모두 오른쪽에 배치한다. el이 14000, de가 22000, ce가 13000이어서 빈도가 꽤 높지만 e위에 놓기에는 모두 부적합하다. dt는 185, cs는 1600 정도밖에 안된다. l은 오른손 2행에 처음 놓은 것이어서 연타를 고려할 필요가 없다.

5.m은 t 밑에 놓는다. mt가 288, dm이 126이어서 연타가 거의 없는 좋은 자리이며 접근성도 좋다. m은 모음 다음에 많이 오므로 왼쪽에 놓기 어렵다.

6.다음 순위인 pf중 e 위에 놓기에는 f가 더 적합하다. ef는 3700, ep는 6800이다. p는 l위에 놓는다.

7.g는 남은 자리중에 제일 위치에 좋은 배치한다. ag, go의 연타율도 대략 3000 정도 되지만 지금은 연타 따질 단계가 아니다. ago가 1열 3연타라 좀 불만이다.

8.반자음인 wy는 오른쪽에 놓는다. sw 연타가 많을 것 같아 s 아래에 y를 두었는데 조사해 보니 sy 연타가 더 높다. 그래서 바꿔 봤는데 ry 연타도 만만치 않다. 그래서 그냥 원래대로 배치했다.

9.마지막 남은 bvkx를 접근성 순위에 따라 배치하되 v를 오른쪽에 둔다. have를 칠 때 왼손 4연타가 발생한다. 오른쪽 모서리밖에 남지 않아 좀 아쉽다.

하루 종일 이리 바꿔 보고 저리 바꿔 보고 온갖 시도를 다 해 본 끝에 나온 배치이다. 결과는 다음과 같다.

0.93 버전에 비해 절반 정도의 키 자리가 바뀌었다. 일단 0.93 버전과 비교한 통계부터 뽑아보자.

배치	자모 분리	조정된 자판
손가락 비율	4:8:11:19-21:13:10:7:3	4:8:13:16-21:11:10:8:5
1행:2행:3행:4행	21:44:13:21	22:45:10:21
1행:2행:3행	26:56:16	29:57:12
손가락 연타율	6.31	5.86
손 연타율	38.37	38.54
좌우 분담율	43:56	42:57
좌우 분담율(엄지 제외)	55:44	54:45
손가락 연타	mo(8348) rt(7563) ho(4485) ei(3673) space-enter(3643) space-up(3000)	hi(6894) ag(3797) ef(3706) lp(3633) go(3185) sy(1897)
손연타 항목	you(1088) str(675) mme(458) ake(440) xam(294) tst(284)	str(675) ffe(555) oug(510) bou(421) hag(371) type(294)
4연타 이상	make(45) xami(25) amou(24) huff(22) uaff(22) maximum(1) mommy(1) yahoo(1)	ough(312) syst(310) uage(302) figu(103) tryt(42) strcpy(1)

통계상으로 왼손 집게 손가락의 부담이 너무 높게 나타난다. 가장 빈도가 높은 e가 있어서 그런데 이 비율을 낮추기 위해 e위에 중빈도의 f를 배치했지만 그래도 다른 손가락보다 높다. 하지만 이는 영어 알파벳 구조 때문이 아니라 Up 자리의 마침표 때문이다. 마침표 비중이 3.34%나 되어 h와 빈도가 거의 같기 때문에 이 문자의 회수가 더해져서 그런 것이다. 더 조정할 필요가 없을 듯 하다.

좌우 분담률은 거의 균형을 이루고 있다. 오른손 엄지를 더하면 오른쪽이 높고 엄지를 빼면 왼쪽이 높은데 여기에 왼손 엄지를 고려하면 대충 50:50이 될 듯하다. 행 비율도 1,2행이 월등히 높아 대략 만족스럽다.

연타는 hi가 가장 높고 다음이 ag인데 이는 더 이상 조정하기 어려운 부분이다. 20000회가 넘는 연타 철자가 11개나 있는데 그것들 다 피한데 만족하자. hi가 비록 이 구조상으로는 제일 높지만 연철 순위로 따지면 44위에 불과하다. ago 연타는 사실 통계 프로그램이 안 뽑아 줘서 그렇지 손가락 3연타이지만 이도 참 피하기 어렵다. 손연타 부분은 그다지 심하지 않은 편이다.

영어 모드의 키배치를 전면 수정한 근거는 손가락의 접근성을 재평가했기 때문이다. 그렇다면 한글 모드의 키 배치도 새로운 기준에 맞춰 수정해야 하지 않을까? 자음의 경우 ㅂㅈㄷㄱ은 순서에도 맞고 2벌식과도 일치하므로 더 건드릴 필요가 없다. 문제는 모음인데 빈도가 4.73%인 ㅡ의 위치가 과연 1.77%인 ㅐ나 0.7%인 ㅆ보다 좋은가 생각해 보았다.

새로 계산한 접근성 순위에 따르면 ㅡ는 ㅐ나 ㅆ과 자리를 바꿔야 한다. 그러나 현재 ㅐㅔ의 자리는 2벌식과 호환되는 위치이고 비슷한 음소끼리 모아 놓은 것이라 바꾸기 싫다. 그렇다면 ㅆ의 자리는 어떤가? 비록 새끼 손가락이지만 이동없이 칠 수 있으므로 분명 ㅡ자리보다는 좋다고 할 수 있다. 그러나 이것도 하지 않는 것이 좋을 것 같다. 2열 새끼 손가락이나 3열 집게 손가락 자리나 도찐개찐이고 ㅢ 복모음을 칠 때 좌우가 아니라 우좌 역방향이 되어 느낌도 좋지 않기 때문이다. 결국 한글 배치는 이번에는 조정하지 않는다.

새로 배치한 영문 자판으로 또 다시 연습에 돌입했다. 연설문도 지겹고 팝송도 너무 긴 것 같아 간단한 영어 명언 몇 개를 구해서 쳐 보았다. 아직 자리도 외우지 못했으므로 긴 문장을 쳐 볼 단계는 아니다.

Success usually comes to those who are too busy to be looking for it.

성공은 대개 그것을 바랄 겨를도 없이 바쁜 사람에게 온다.

Everything is okay at the end. If it is not okay, then that's not the end.

결국 끝에는 다 괜찮아. 만약 괜찮지 않다면, 아직 끝이 아닌 것일 뿐

성공 명언을 치는데 최초 62초가 걸렸다. 조금만 연습하면 40초 내외로는 금방 들어올 수 있다. 새 자판으로 연습한 결과 받은 느낌은 다음과 같다.

- i가 Cap 바로 옆이어서 대문자 i를 치기가 편리하다. 1인칭 대명사로 자주 사용되는 중요한 단어인데 중앙행 왼쪽키를 두번 연달아 치면 된다.

- 영어에서는 홑따옴표 빈도가 굉장히 높은데 이는 미리 예측하지 못했던 것이다. 현재 자리가 별로 좋지 못한데 그렇다고 바꿀 생각은 없다. 한글에서는 잘 안 쓴다.

- 배치가 자꾸 바뀌어도 머리는 알아서 리셋되는 듯 하다. 이전의 자판도 자리를 꽤 많이 외웠는데 새 자판을 쳐 보니 이전 자판은 생각도 안난다. 역시 자판이라는 것은 머리가 외우는 것이 아니라 손이 외우는 것이다.

- 쿼티 자판의 잔상이 아직 남아서 비슷한 자리에서 자꾸 오타가 발생한다. 저번 자판에서는 i 자리에 l이 있었는데 모양이 비슷해서 자꾸 l을 쳤었다. 이번에는 l이 쿼티의 l자리 옆에 있는데 자꾸 그 자리를 두들긴다.

- 비슷한 위치인데도 왼손 새끼 자리 보다 오른손 새끼 자리가 훨씬 어색하다. 쿼티에 문자가 배정된 자리가 아니라서 그런가 보다. usually, seven 등을 칠 때 무척이나 버벅거린다.

하루 종일 키보드만 생각하다 보니 오늘이 마누라 생일인 것도 깜박했다. 1년동안 갈굼을 당할 뻔 했는데 저녁 늦게 베스킨 라빈스 아이스크림 케익으로 겨우 떼웠다.

12년 6월 8일

혼자 키보드를 만들다 보니 기획도 혼자, 구현도 혼자이다. 괜한 고집을 피우는 것은 아닌지, 너무 엉뚱한 기획이 아닌지 검증을 해 볼 필요도 있고 이제 누군가에게 보여주고 지혜를 모을 필요가 있다. 그래서 지인들 찾아 다니며 조언을 구하기로 했다. 먼저 후배 L이 근무하는 곳의 K 이사님을 찾아 뵈었다. 한글 글꼴 제작의 권위자이고 IT 산업 전반에 대해 꿰뚫고 계신 분이다.

서울 강남까지 가서 키보드 기획안을 짧게 보여 드렸다. 워낙 이해가 빠른 분이라 대략 10분정도만 설명을 해도 기획의 의도를 금방 파악하고 이런 저런 조언을 해 주셨다. 다음은 오늘 들은 조언들이다.

- 키보드의 키가 많은 것은 별 단점이 아니다. 사식업자들의 경우 원하는 모든 키를 원터치로 누를 수 있는 것을 좋아한다. 손이 제자리를 벗어났다가 다시 돌아오는데 오래 걸리지 않으며 별로 불편하지 않다. : 맞는 말이다. 이것 저것 모드 바꿔 가며 키를 누르는 것보다 원터치로 한번에 해결하는 것이 더 편리하다. 하지만 적어도 문자 입력만은 제자리에서 하는 것이 좋다는 것이 내 고집이다.

- 이것을 왜 만드느냐? 돈이 목적이라면 무척 힘들므로 말리고 싶지만 좋아서 하는 일이라면 찬성이다 : 분명히 돈을 벌고자 시작한 프로젝트는 아니다. 하지만 이걸로 돈을 벌기는 굉장히 어렵다는 것은 분명히 인지해야 할 듯하다. 오히려 돈을 쓰는 프로젝트이며 잘해봐야 연구비나 시제품 제작비 정도를 건질 수 있을 뿐이다. 전에도 그랬지만 앞으로도 욕심 내지 말고 순수한 마음으로 개발에 임하자. 내가 좋아서 하는 일임이 분명하다.

- 타겟이 분명해야 한다. 소형 디지털 장비를 위한 것인지 PC 키보드를 대체하기 위한 것인지 명확히 하고 타겟에 맞추어 개발해야 한다. : 무슨 말인지는 알지만 두 타겟 모두 의존성이 있다고 생각한다. PC 사용자들이 이 답답한 키보드를 선뜻 채택하기는 어렵고 공간이 좁은 휴대용 장비에서는 나름 경쟁력이 있다. 그러나 배치가 생소한 상태에서는 휴대용에서도 사용하기 어려우므로 먼저 PC 환경에서 어느 정도 보급이 이루어져야 한다. 단 1%라도 보급이 되어 있어야 소형 장비에서도 거부감없이 받아들일 여지가 있다.

- 사람의 습관을 바꾸는 것은 거의 불가능하다. 드보락이 아무리 좋아도 쿼티를 대체하지 못했으며 이 키보드도 마찬가지이다. : 잘 알고 있는 사실이다. 진짜 사람들은 웬만해서는 기존 지식을 버리지 않는데 하물며 몇 십년동안 잘 써온 키보드를 바꾸지는 않을 것이다. 성급한 결과나 성적을 기대하지 않는다. 커스텀 키보드 애호가들에게 하나의 대안으로 남을 수 있으면 되고 많은 키보드 중 하나가 되면 충분하다. 차후에 나와 똑같은 생각으로 비슷한 작업을 하는 사람들에 의해 계승, 발전되기를 바란다. 지금 내가 하는 작업은 성과없이 끝나더라도 그 분들에게 좋은 참고 자료가 될 것이다. 어쩌면 키보드 자체보다는 이 작업일지나 설명서가 최종 결과물일지도 모른다.

- 작은 크기로 나오고 싶다면 써 보고 싶다(후배 L) : 작은 키보드를 무척 좋아하는 후배이고 키보드에 투자를 아끼지 않는 후배인데 풀 구성 키보드보다는 작은 모양의 키보드에 매력을 느끼는 듯하다. 기존과 같아서는 어필하기 힘드므로 아예 작은 크기로 차별화를 하는 것이 더 좋을지도 모르겠다.

시제품 제작 방법에 대해서는 별다른 조언을 듣지 못했다. 키보드 제작에 대해 아는 사람이 거의 없는 실정이다. 오늘 PT 결과 크게 욕심 내지 말고, 서두르지도 말고 차분하게 천천히 최선을 다해 임하자는 생각이 들었다.

지금 내가 해야 할 일은 사실 키보드 제작이 아니라 안드로이드 관련 개정판을 집필하는 것이다. 책은 출판 시점이 굉장히 중요한데 젤리빈 출시 시점에 맞추려면 지금 부지런히 작업을 해 두어야 한다. 그러나 하고 싶은 일은 지금 하고 있는 키보드 제작이다. 해야할 일, 하고 싶은 일 이 둘이 불일치하는 상황이라 무척 난감하다. 이럴 때 나는 언제나 하고 싶은 일을 선택한다. 해야 할 일을 하지 않았을 때의 후회보다는 하고 싶은 일을 하지 못했을 때의 후회가 더 클 것이다.

12년 6월 9일

키의 개수나 배치가 아직도 진행중이며 이후에도 바뀔 여지가 많지만 이제 슬슬 실물 키보드를 만들어 볼 때가 되어 간다. 사용에 문제가 없는지 알아 보려면 실제 하드웨어 키보드로 타이핑을 해 봐야 정확하게 알 수 있다. 아마도 실제 키보드로 입력을 해 보면 뭔가 다른 문제점이 발견될 것이다.

샘플 키보드를 만들려면 배치를 확정해야 하고 만들어 사용해 보면 배치가 영향을 받을 수 있는 순환적인 문제가 있다. 어쩔 수 없이 1차 샘플 만들고 배치에 적용하고 다시 샘플 키보드를 수정하는 번거로운 과정을 거쳐야 한다. 돈과 시간이 많이 필요하고 연습도 꽤 많이 해 봐야 한다.

문제는 돈도 시간도 없다는 것인데 그래서 최대한 비용을 아낄 수 있는 방안을 생각해 보았다. 우선은 원하는 모양과 크기대로 종이에 그려 보는 것이다. 눌러지지는 않지만 최소한 손가락의 이동이 원활한지 자세가 제대로 나오는지 정도는 확인해 볼 수 있다. 파워 포인트로 다음 샘플 키보드 도면을 작성했다.

그냥 대충 그린 것이 아니라 치수를 정확하게 맞춘 것이다. 파워 포인트의 정렬 기능이 썩 좋지 못해 무척 어렵게 그렸다. 키 피치는 가로가 18미리, 세로가 16미리이다. 사람 손가락의 폭이 대략 16미리 정도 되며 약간 더 여유가 있어야 한다. 표준 키피치는 18.8미리로 조금 더 넓지만 아너림은 손가락 이동이 없으므로 조금 더 좁게 잡았다. 실제 소형 키보드는 18미리 키피를 가지는 것들이 있다. 수직 피치는 운지 거리를 최소화하기 위해 더 많이 줄였다. 아래 위로만 까딱 까딱하면 되므로 굳이 손가락 두께만큼의 피치를 가질 필요가 없다고 판단했다.

각 행은 4미리씩 어긋나게 배치했다. 손을 자연스럽게 키보드에 올린 상태에서 집게 손가락을 위로 뻗어 보면 바로 위가 아니라 4~7미리 정도 어긋나므로 수직으로 정렬하는 것보다 약간 어긋난 것이 편하다. 쿼티 키보드는 행간마다 어긋난 정도가 다른데 1행과 2행은 5미리, 2행과 3행은 9미리 어긋나 있고 1행과 숫자행은 10미리나 어긋나 있다.

쿼티의 키 구조가 왜 그런지는 잘 모르겠지만 분명한 것은 일관성도 없고 전혀 편하지도 않다는 것이다. 오른손은 그래도 뻗는 방향으로 어긋나 있지만 왼손의 경우는 오히려 뻗는 방향과 역방향으로 어긋나 있다. 쿼티의 F에서 바로 위의 R은 왼쪽으로 기울어져 있어 자연스럽게 뻗어서는 R을 누르지 못한다. 이는 아마도 R 옆의 T 자리까지도 집게 손가락이 커버해야 하기 때문일 것이다. 그러나 그렇게 보면 오른손 집게가 담당하는 Y는 어긋나도 한참이나 어긋나 있다.

또한 대표적으로 불편한 예는 왼손 집게의 우하방향에 있는 B이다. 이 자리는 왼손 집게와는 멀어도 한참이나 멀다. 그래서 한글의 모음 ㅠ도 치기 무척 어려우며 심지어 ㅠ만 오른손으로 치는 사람도 있다. 아너림은 뻗는 방향에 따라 적당히 기울여 놓았으므로 익숙해지면 아주 자연스러울 것이다.

한영수, 공백은 2행 키의 끝과 키의 중앙을 맞추었다. 손가락을 자연스럽게 오므려 보면 엄지의 위치가 집게의 안쪽변과 같기 때문이다. 한영수, 모드키는 자주 사용하므로 키 피치를 20미리로 약간 넓게 잡았다. 그러나 실제 사용해 보니 키 폭이 늘어난 만큼 Up 과 Sym 키가 엄지에서 멀어져 오히려 더 불편한 것 같다.

쿼티는 Shift, BS, Enter 등의 키를 문자키보다 넓게 만들어 놓았는데 이는 제자리 원칙이 없기 때문에 대충 움직여도 그 키를 치기 쉽도록 하기 위해서이다. 아너림은 공백이나 모드 변환같은 중요한 키도 자리가 명확하므로 굳이 넓을 필요가 없지 않나 싶다. 좀 더 테스트해 보고 불편하다 싶으면 이 두 키도 문자키와 동일한 폭을 가지도록 할 생각이다.

키보드의 전체 폭은 4행 엄지의 키가 맞닿을 정도가 되어야 한다. 엄지가 다른 손가락보다 안쪽에 있어서 문자키 사이가 벌어지는 효과가 나타나는데 공간이 좀 아깝기는 하지만 두 손을 적당히 띄울 수 있어 바람직하다. 차후 남는 공간에 터치 패드를 넣는 방안을 고려하고 있다.

다음은 일자형 배치를 약간 변형한 것인데 제작상의 어려움만 없다면 이 배치가 더 좋은 것 같다. 좌우의 키를 10도 정도 기울였다. 일자형 배치는 양쪽이 벌어져 있어도 어깨 넓이보다는 좁으므로 손목이 꺽이지만 이렇게 기울이면 손목의 모양이 자연스러워 자세가 좋아진다. 이른바 인체 공학적인 키보드라고 할 수 있다.

기울인 정도는 10도이되 이는 어디까지나 대충의 값이다. 실제값은 좀 더 정밀하게 측정해 보고 사람이 어느 정도의 각도를 편하게 느끼는지 조사를 해 봐야 하겠지만 일단은 기울이겠다는 기획만 한 것이다.

이 구조에서 각 행의 어긋난 정도는 약간 조정된다. 일자형일 때는 손가락을 뻗을 때 아래 위 차이가 많이 나지만 기울인 상태라면 차이가 줄어들 것이다. 그래서 절반인 2미리로 어긋난 정도를 조정했다. 만약 기울임의 각도가 늘어난다면 전혀 어긋나지 않게 직사각형 형태로 배치해도 될 듯 하다.

키의 각인은 전에 생각해 둔 대로 영문, 한글, 기호만 새겨 넣었다. 숫자나 편집키, Upper의 문자는 쉽게 외워지므로 굳이 새길 필요는 없을 것이다. 만약 꼭 필요하다면 키보드 아랫면에 조그마한 글씨로 새겨 넣는 방안을 고려해 보기로 한다.

이렇게 그린 키보드 그림을 프린터로 인쇄하면 정확한 치수대로 출력된다. 화면은 정확한 길이대로 출력하기 어렵지만 프린터에서는 이것이 가능하다. 종이에 키보드 모양을 인쇄한 후 사용 테스트를 수행했다. Up키가 기호키를 엄지로 누를 수 있어 테스트에 꽤 도움이 된다. 그러나 스트록이 없기 때문에 아무래도 좀 심심하고 밋밋하다. 눌러도 반응도 없고 재미도 없다.

테스트 결과 예상했던 대로 엄지의 키가 너무 넓다는 느낌이 들었다. 엄지는 좌우로 움직이는 폭이 넓다 보니 Up이나 Enter를 칠 때 운지거리가 너무 멀고 엄지를 많이 구부려야 한다. 그래서 수평 피치를 좀 줄이는 것이 좋다. 또 개인간의 엄지 손가락 길이 차이를 고려하면 수직 피치는 오히려 늘려야 한다. 결국 엄지에 걸리는 키들은 키 피치의 수평, 수직을 뒤집어 16*18로 맞추었다. 조정한 후의 모습은 다음과 같다.

엄지키의 폭이 8미리씩 총 16미리나 줄어 들었으며 좌우의 문자키들도 그 절반만큼 가까워졌다. 기울인 모양도 똑같은 방식으로 조정했다. 테스트해 보면 엄지 손가락의 키들을 누르기가 약간은 더 쉬워진 것 같다. 다음은 종이에 인쇄된 키보드에 본인의 양손을 올려 본 것이다.

손의 자세를 테스트하기에는 그럭 저럭 괜찮지만 눌러도 문자가 입력되지 않고 평평하다 보니 느낌이 어떤지를 평가하기는 어렵다. 역시 제대로 테스트하려면 실물 키보드 시제품을 만들어 봐야 한다.

그렇다면 실물 키보드는 과연 어떻게 만들 수 있을까? 우선 인터넷 동호회에서 관련 자료를 찾아 보았다. "커스텀 키보드"라는 검색식으로 찾아 보면 키보드를 마음대로 변형해서 사용하는 사람들이 꽤 많다는 것을 알 수 있다. 그러나 대부분 색상을 바꾸거나 조명을 달고 키캡을 바꾸는 정도에 불과하며 키의 배치까지 마음대로 바꾸는 경우는 아직 보지 못했다. 일반 키보드를 인체 공학 키보드로 만드는 정도가 가장 수준 높은 커스텀 작업인 듯 하다.

커스텀 키보드 제작용 툴 킷으로 아이콘(Aikon)이라는 것이 있다. 32비트 운영체제에서 동작하는 USB 컨트롤러이며 키맵을 자유롭게 조작할 수 있다. 기존 키보드 기판의 배선을 그대로 이용하며 기존의 row, col을 찾아 Aikon에 맵핑해 주는 방식이다. 문서를 읽어 보면 펌웨어니 부트로더니 오실레이터, 납땜 등의 용어가 등장하고 동판에 에칭을 한다는 둥, PCB 기판이 어쩌고, 전압이 어쩌고 하는데 소프트웨어 개발자에게는 참 생소해서 선뜻 접근할 엄두가 나지 않는다.

게시판의 글을 대충 읽어 보면 구형 키보드를 USB 형태로 개조하거나 키의 맵핑을 원하는대로 바꾸는 툴킷이 아닌가 추측된다. 좀 더 공부하고 알아 봐야겠지만 내가 원하는대로 키의 배치나 기울어진 각도까지 마음대로 바꿀 수 있는 툴킷은 아닌 것 같다.

아너림은 키뿐만 아니라 아예 기판부터 달라야 하므로 아마추어가 쉽게 만들 수 있는 키보드가 아니다. 공방이 있다고 하는데 그것도 아너림같은 구조의 커스텀 키보드를 만들어 주는 곳은 아닌 듯 하다. 커스텀 키보드 제작을 위한 몇 개의 툴을 검색해 봤지만 역시 내 용도에는 맞지 않은 것 같다.

만약 정 방법이 없다면 키보드 제작사로 찾아가서 제작을 의뢰하는 수밖에 없을 것이다. 키는 기존것을 쓴다 하더라도 기판을 완전히 새로 만들어야 하니 비용도 엄청나게 많이 들 것 같다. 어디까지나 시제품일 뿐이라 지금은 이 비용을 감당할 시점이 아닌 것 같다. 좀 다른 방법을 찾아 봐야겠다.

12년 6월 10일

K 이사님의 조언을 받은 후 기획이 다시 바뀌었다. 사람들의 습관을 바꾸는 것이 굉장히 힘들기 때문에 처음 도입기에는 어느 정도 타협을 할 필요가 있다. 아무리 이상적으로 좋아도 복잡도가 높으면 사람들이 쉽게 접근하지 못한다. 현재의 기획을 좀 더 단순화할 필요가 있다.

우선 제자리 원칙부터 일정 부분 포기하기로 했다. 손이 움직이지 않고 입력할 수 있다는 것은 분명 장점이다. 그러나 문자가 아닌 편집키나 펑션키에 대해서도 굳이 이 원칙을 지킬 필요는 없다. 제자리에서 투터치 보다는 손을 옮기더라도 원터치를 더 좋아하는 사람이 많고 지금까지 이런 방식에 너무 익숙해 있다. 손이 BS나 Enter로 가더라도 다시 정확하게 제자리로 돌아온다.

제자리 원칙은 아너림의 가장 중요한 철학이지만 문자 입력에 대해서만 이 원칙을 고수하고 나머지는 반쯤 포기하기로 한다. 편집은 풀 구성에 따로 키가 있으므로 굳이 제자리 원칙을 지킬 필요가 없다. 편집키는 30키 밖으로 추방하고 대신 BS 키를 다시 도입한다. 삭제를 하는데 Up + Space로 투터치를 해야 한다는 것은 초보자가 용납하기 어려운 부분이며 입력만큼이나 오타 수정도 중요하다.

Edit키가 제거되고 BS가 들어오되 구성원이 바뀌었으므로 배치도 여러 가지 형태로 생각할 수 있다. 가장 빈도가 떨어지는 Sym을 Edit 자리로 옮기는 것은 당연한 듯 한데 나머지 키의 순서가 애매하다. 다음 3가지 형태를 기획해 보았다.

Mode, Bs, Up 순 : 기존 배치를 그대로 유지할 수 있다. 그러나 공백은 오른손에 있는데 역공백은 왼손에 있는 구조가 직관적이지 못하다.

Mode, Up, Bs 순 : Up은 모드를 변경하는 효과가 있고 Bs는 Sp와 같은 부류이므로 직관적이다. 그러나 Up이 왼손으로 이동함으로써 구두점을 오른쪽으로 옮겨야 한다. 한글은 기존 경음 위치에 그대로 남아 있어야 하므로 왼손 2연타가 발생한다.

Up, Mode, Bs 순 : 모드를 변경하는 빈도와 Up 문자를 입력하는 빈도에 따라 이 배치가 더 나을 수도 있다. 미국 사람 입장에서 Mode키는 사실 별 필요가 없으므로 엄지의 홈 포지션을 내 주기 아깝다. 숫자의 경우는 Up 홀드 상태에서 입력받으면 되나 비직관적이다. 또 숫자 모드로 전환하려면 Mode 더블 푸시해야 하므로 복잡해 보인다.

이 부분은 좀 더 고민이 필요하되 당장은 배치를 좀 조정하더라도 Mode, Up, Bs가 더 좋아 보인다.

밀려난 Edit키는 어딘가로 이사를 해야 한다. 이 키와 Fn 키는 풀 구성일 때는 필요없다는 공통점이 있으므로 같이 왼손 하단에 모은다. 그러면 CSAW 조합키가 다시 자리를 내 줘야 하는 연쇄적인 문제가 생긴다. 조합키와 모드키의 전체적인 배치는 다음과 같이 수정한다.

Edit를 왼손 약지에 걸리도록 해 놓으면 자세가 약간 흐트러지지만 반쯤은 제자리 편집이 가능하다. 왼쪽이 너무 번잡해 보여 둘 중 하나를 오른쪽으로 옮기는게 어떨까 싶지만 둘 다 왼쪽에 있는 것이 맞다. 지금까지 사람은 오른손으로 커서를 옮겼으므로 Edit는 당연히 왼쪽에 있어야 하며 펑션키도 Ctrl + F1 조합을 위해 조합키와 같은 위치에 있어야 한다.

왼쪽이 너무 꽉 차 보이지만 풀 구성일 때는 Fn과 Edit를 뺄 수도 있으며 오른쪽에는 편집키 9개가 있으므로 좌우 균형은 그럭 저럭 맞는 셈이다. 표준 구성일 때도 생략된 다른키와 멀티미디어 키 때문에 두 키를 빼는 것은 좋지 않은 것 같다.

왼쪽 하단에 비해 오른쪽 하단이 비어 있어 뭔가 썰렁해 보이고 안정감이 없어졌다. 이 빈자리를 차후에 더 필요한 키로 채워 볼까 싶은데 당장 떠오르는 것은 Ctrl, Shift를 중복 배치하는게 어떨까 싶다. 한손으로 Shift + 왼쪽 키를 눌러 블록 선택을 한다거나 동영상 재생기의 재생 위치 조정 등에 편리하게 사용할 수 있을 것 같다. 그러나 키를 2개나 꽁으로 늘리는게 영 못 마땅하므로 일단은 비워 둔다.

이상 여기까지 기획만 해 보았으며 코드는 당분간 작성하지 않는다. 매번 생각이 떠오르는대로 구현을 해 보곤 했는데 자꾸 바뀌는 중이라 굳이 구현을 지금 해 볼 필요는 없을 것 같다. Up 키 자리가 여러번 바뀌었고 Bs는 계속 들락 날락 하는데 좀 더 숙고한 후에 작업하는 것이 좋겠다.

어제 그려본 키보드 도면에서는 좌우 문자키를 팔 뻗는 방향으로 살짝 기울여 보았는데 이것도 당분간은 하지 않는다. 인체 공학적이라고 하지만 초보자가 보기에 거부감이 들기도 하며 소프트웨어적으로나 하드웨어적으로나 제작상의 어려움도 있다. 거부감을 최소화하기 위해 키피치도 과격하게 줄이지 말고 표준과 유사하게 제작한다. 원하는대로 바꿔 보는 것은 다음에 해도 늦지 않다.

12년 6월 12일

■ 이틀에 걸쳐 키보드 랜더링를 코드를 수정했다. 지금 현 상태로도 화면상에 키보드를 보여주는대는 문제가 없지만 정확한 배치나 형태를 다양하게 테스트해 보기 어렵다. 종이에 매번 인쇄해서 눌러 보는 것도 효율적이지 못하므로 아예 화면상에서 배치 관련 변수를 변경할 수 있도록 했다.

또 실제 피치 크기나 들여쓴 정도를 정확하게 조정하기 위해 픽셀 단위가 아닌 밀리미터 단위를 사용했다. 현재 화면의 밀도에 따라 밀리미터를 픽셀로 계산하여 그린다. 이렇게 하면 터치가 되는 PC에서 소프트웨어적으로 키보드를 다양하게 바꿔 볼 수 있어서 차후 제작 비용을 절감할 수 있다. 조정 가능한 옵션은 다음과 같다.

좌우 문자키의 거리, 들여쓴 정도, 키의 크기와 간격 등을 실행중에 변경할 수 있다. 대화상자에는 없지만 펑션키의 크기, 엄지키의 크기도 지정할 수 있다. 대화상자에 UI가 없는 옵션은 코드에서 값을 직접 바꿔야 한다.

이 기능이 들어감으로써 키맵이 다시 대폭적으로 수정되었다. 그동안 키의 영역을 수작업으로 지정하던 RECT 구조체를 없애고 계산에 의해 키의 배치를 마음대로 조정할 수 있게 되었다. 코드는 복잡하지 않은데 산수가 좀 복잡해서 시간이 오래 걸렸다. 대화상자에서 값을 바꾸는 즉시 적용된다. 레벨 4의 배치는 다음과 같다.

전체적인 모습은 이전 버전과 비슷해 보인다. 펑션키와 엄지키 행을 문자키와 약간 간격을 두었다. 배치 관련 옵션은 실행중에도 조정할 수 있다. 다음은 관련 변수들을 조정하여 눈에 띄게 다르게 배치해 보았다.

키의 크기, 간격 등을 런타임에 조정할 수 있어 테스트하기 편리해졌다. 그러나 차후 배치를 바꾸려면 키맵만 수정해서는 안되고 코드를 손봐야 한다는 점은 오히려 더 부담이다.

키보드를 전체적으로 기울이는 것도 변수는 만들어 두었는데 적용은 하지 않았다. 거부감이 들기도 하지만 그보다는 구현하기가 어렵기 때문이다. GDI는 직접적으로 회전을 지원하지 않으며 GDI+를 사용해야 하는데 너무 대공사이다. 또 회전은 아래, 위 키의 크기에도 영향을 미쳐 복잡도가 증가한다.

■ 물리적인 키보드를 제작하기는 아직까지 어렵다. 비용도 많이 들 뿐만 아니라 확정도 되지 않은 상태에서 덜컥 만들어 볼 수도 없는 노릇이다. 그래서 소프트웨어적으로 최대한 원형을 테스트해볼 수 있는 방법을 고민하다가 터치 PC를 사용하기로 했다. 비록 눌러져지는 않지만 터치로 손의 자세 정도는 볼 수 있다.

연습 프로그램이 윈도우 기반으로 되어 있으므로 슬레이트 PC를 알아 보았다. 마침 집 근처 마트에 전시회 놓은 것이 있어서 만져 보았는데 이걸로는 제대로 테스트하기 힘들겠다는 느낌이 들었다. 화면 키보드로 입력해 보았는데 정전식인데도 화면 터치를 잘 인식하지 못하여 약간 힘있게 눌러야 제대로 인식되며 고속으로 누르면 키 입력을 하나씩 빼먹기도 한다.

가격도 비싸서 테스트용으로 구입하는 좀 무리이다. 좀 더 좋은 장비를 알아 보거나 아니면 안드로이드용 탭을 알아 봐야겠다. 자유도가 좀 떨어지지만 모양 정도는 테스트해 볼 수 있을 듯 하다.

■ 현재 Mode 키를 누르면 한글과 영어를 토글하며 더블 푸시하면 숫자로 전환한다. 그러나 이 구조는 우리나라 실정에만 맞으며 다른 나라에서는 맞지 않다. 일본의 경우는 당연히 일본어와 영어를 토글해야 할 것이다. 미국의 경우는 다른 언어를 쓸 필요가 없으므로 불편하게 더블 푸시해서 숫자 모드로 바꿀 필요가 없다.

또 우리 나라의 경우라 하더라도 한국어, 일본어, 영어 3개 언어를 동시에 바꿔 가며 사용할 필요도 있을 것이다. 그래서 Mode키의 기능을 고정하지 않고 지원 언어의 개수를 최대 4개까지 저장해 두고 순환하도록 했다. 지원 언어의 개수에 따라 Mode키의 동작은 다음과 같이 정의된다.

	1개 언어	2개 이상 언어
푸시	언어와 숫자 토글	언어끼리 순환
더블푸시	기능 없음	언어와 숫자 토글
홀드	임시 숫자	임시 숫자

지원 언어가 하나밖에 없을 때는 누를 때 숫자로 바뀐다. 3개 이상일 경우는 각 언어를 순환해 가며 사용할 수 있다. 이 옵션은 디바이스 드라이버에서 제공하며 후킹이나 연습 프로그램은 메뉴를 통해 언어를 선택한다. 아직 다른 언어에 대한 자판은 만들어 본 바가 없으므로 다음 3개의 조합만 가능하다.

디폴트는 한글/영어이되 한글만 지원하거나 영어만 지원할 수도 있다. 이 경우는 숫자 입력이 좀 더 편리해진다.

12년 6월 13일

■ 몇일간 기획했던 변화를 선별하여 코드에 적용하였다. 3행은 여러 가지 방안중에 Mode키를 그대로 두고 Edit 자리에 Sym을 놓고 Up을 Mode의 오른쪽에 놓았다. 기존의 Up 자리에는 BS가 배치되었다. 왼쪽 보드에는 조합키와 Esc, Tab을 2열로 배치하고 왼쪽 하단에는 Fn과 Edit키를 배치했다. 여기까지 작업한 결과는 다음과 같다.

키의 배치가 바뀜으로 해서 내부적인 기능도 상당히 많이 수정되었다. Up키가 왼쪽으로 이동함으로써 연타 방지를 위해 Up 상태의 구두점들이 모두 오른쪽으로 이동했다. 기존에는 집게와 중지에 2행으로 구두점을 배치했는데 제자리에서 이동없이 입력하는 것이 더 좋을 것 같아 가운데 행에 4개를 모두 배치했다. 한글 자판은 경음이 원래 자리를 지키고 있지만 영문 자판은 jqz도 오른쪽으로 이동시켰다.

BS 키가 별도로 들어감으로 해서 Up + Space의 기능은 제거했다. 언제든지 원터치로 삭제할 수 있다. 기존에는 숫자 모드에서 숫자를 잘못 입력했을 때 수정을 위해 Mode키를 놓거나 한영 모드로 다시 전환해야 하는 불편함이 있었는데 이제 그 문제가 깔끔하게 해결되었다.

Edit 모드의 오른손 3행 새끼 손가락 위치에 BS키가 배치되어 있었는데 이제는 필요가 없어졌다. 그래서 삭제하고 Pause를 BS 옮겼으며 원래 Pause가 있던 자리에는 한자키를 배치했다. 한자키는 일본에서 문자 위치에 들어가는 게 맞는 것 같은데 한글의 경우는 한자로 변환할 수도 있어야 하므로 일단 넣었다.

쿼티키의 맵핑도 약간 수정했다. 왼손 엄지에 걸리는 키를 각각 TGB로 맵핑하여 수직으로 세운 모양이라고 생각하면 된다. Fn, Edit는 할당할 키가 없어 숫자 1, 2를 맵핑했다. 물론 한칸씩 올린 키보드에서는 제 모양대로 맵핑된다.

왼쪽에 있는 Fn, Edit키가 꽤나 쌩뚱맞아 보이며 오른쪽에 대응되는 키가 없다 보니 대칭이 무너져 보기에 좋지 못하다. 사실 이 배치가 딱히 마음에 드는 것은 아니며 기획을 했으므로 일단 시도해 보기 위해 코드로 구현해 본 것이다. Edit를 제자리에서 뺀다는 생각은 일단은 맞는 것 같다.

코드는 작성해 놓았지만 시간 관계상 많이 테스트해 보지는 못했다. 이 배치가 얼마자 합리적인지는 실 사용을 해 봐야 알 수 있는데 지금 그럴 상황이 못 되므로 일단 만들어만 놓은 것이다. 당장 다른 배치가 떠오르는 것은 없으므로 여기까지 0.94 버전으로 릴리즈하기로 한다.

■ PC 키보드의 배치가 수정되었으므로 안드로이드 버전도 같이 동기화하기 위해 작업했다. 이전 버전에 원래 BS가 있었고 코드도 작성되어 있으므로 키 배치만 약간 수정하면 된다. 하단의 키는 편집키를 제거하고 6개가 되었는데 다시 이전 버전과 같은 구조로 돌아왔다. 다만 순서가 좀 바뀌었을 뿐이다.

편집키가 좀 아쉽지만 Compact 구성에 원래 없으므로 뺐다. 어차피 커서 이동은 터치로 수행하는 게 보통이므로 딱히 편집키가 있어야 할 이유는 없다. 그러나 이 키가 빠짐으로써 또 다른 문제가 발생했는데 이모티콘 모드로 들어갈 방법이 없다는 것이다. PC 키보드에서는 이모티콘이 아무 짝에도 쓸 모가 없지만 모바일에서는 필수적이다. 기존에는 편집키를 더블 푸시했는데 이제 다른 방법을 찾아야 한다.

그래서 고민끝에 Up + Sym을 이모티콘으로 들어가는 키로 정의했다. 숨겨진 기능이라 설명을 하지 않으면 절대로 찾지 못하는 문제가 있다. 별도의 이모티콘 키를 배치하는 방법도 있겠지만 PC와 외형적으로 일치시키는 것이 더 나을 것 같다.

기획이 바꿀 때마다 안드로이드 키보드도 같이 업데이트하는데 시간도 오래 걸리고 힘들다. 당분간 안드로이드 키보드는 더 이상 동기화하지 않기로 한다.

■ 안드로이드 키보드와 사용법을 일치 시키기 위해 이모티콘 모드 변환 방법을 Up + Sym으로 수정하였다. 차후 데스크탑 키보드에서는 제거할 기능이다.

■ 통계상의 버그 수정. 키보드 랜더링 코드를 수정하면서 손가락 번호를 일종의 좌표값으로 사용했는데 그로 인해 좌우 분담률이 무려 7:3으로 조사되었다. 멤버 하나 아낄려고 하다가 통계 프로그램이 완전히 엉망이 되었다. 배치에 사용되는 멤버를 따로 추가하고 랜더링 코드에서 이 값을 참조하도록 수정했다. Up 키가 왼쪽으로 이동함으로써 좌우 분담률에 변화가 생겼다.

영문 샘플 : 46:53, 엄지를 제외하면 53:46

한글 샘플 : 49:50, 엄지를 제외하면 54:45

Up 키가 왼손으로 간 대신 구두점과 jqz가 오른쪽으로 이동했으므로 이 부분에는 변화가 없지만 한글 경음이 여전히 왼손에 있으므로 왼손의 분담률이 조금 더 상승했을 것이다.

■ 수정된 배치대로 키보드 그림도 다시 조정했다. 현 단계에서는 별 의미가 없지만 말이다.

■ 여기까지 작업된 결과를 0.94 버전으로 릴리즈하였다. 홈 페이지의 사용법 문서도 같이 수정했다.

12년 6월 14일

■ 어제 릴리즈한 0.94 버전에서 영문 Up 상태의 구두점이 중복 배치된 사소한 버그를 발견하여 다시 릴리즈함. 릴리즈 날짜는 그냥 어제 날짜로 유지

■ 여러 사람 의견을 수용하고자 계속 노력하고 있다. 너무 많은 의견들에 휘둘려서는 안되겠지만 혼자만의 고집만으로 키보드를 만들 수는 없으므로 가급적 많은 평가를 받아들이고자 한다. 오늘 새벽에는 평소에 개발에 관해서 많이 의지하는 J형을 찾아갔다. 코딩에 관해서는 거의 신에 가까운 존재여서 J형의 의견은 꼭 묻고 싶었다. 핸드폰을 엉뚱한데 두어 문을 안 열어주는 바람에 불가피하게 30분이나 문밖에서 노숙을 했는데 나름 재미있었다. 전에도 이미 키보드를 보여 준 적이 있고 또 워낙 이해력이 빠른 사람이라 굳이 길게 설명할 필요는 없었다. 짧게 설명을 한 후 의견을 들었다. 다음은 아너림 키보드에 대한 J의 의견과 나의 생각이다.

- 너무 소형화에 집착할 필요가 없다. 소형 키보드는 한계가 있으므로 차라리 PC 키보드 대체용으로 개발하는 것이 좋다. 소형 장비에 장착할 수 있을만큼 작더라도 실제 글을 많이 쓰는 사람은 반드시 키보드를 들고 다니므로 별 의미가 없다. 그것보다는 고속 입력, 피로 최소화에 타겟을 두는 것이 좋다. => 맞는 얘기다. 아너림은 최초 소형화에 큰 비중을 두고 개발을 시작했지만 나 자신도 모바일 버전을 만들어 본 후 소형 장비에는 어울리지 않는다고 생각했다. PC 키보드를 완전히 대체할 수 없다면 소형 장비에도 채택되기 어렵다. 분명 소형 장비가 타겟이 될 수는 없지만 PC에서 어느 정도 보급된다면 소형 장비에도 장착 가능함이 하나의 장점이 될 수 있는 정도다.

- 키가 많아도 원터치가 더 편리하다. 모드 바꿔 가며 입력하는 것은 머리를 너무 피곤하게 만들므로 제자리 원칙을 지키는 것보다는 가급적이면 많은 키가 있는 것이 좋다. 손가락이 자리를 살짝 벗어나더라도 두 번 키를 누르는 것이 더 편리하며 사람들이 좋아한다. => 김이사님의 조언과 같으며 이 부분에 대한 조치는 0.94 버전에서 상당수 적용하였다. 현재보다 더 많은 키를 배치하라는 것인데 조언의 의도는 알겠지만 나는 완전히 동의할 수 없다. 나의 경우 숫자, 기호키는 손가락이 외우지 못하므로 눈으로 키보드를 보고 치는데 이때 속도의 저하가 발생하고 피로도가 증가한다. 모드를 바꾸는 것도 분명 피곤한 일이지만 익숙해지면 보지 않고도 입력할 수 있다는 이점이 있다. 사실 쿼티 키보드의 (나 { 문자도 투터치이지만 사람들은 아무 불편없이 입력하고 있다. 즉, 터치의 수는 어디까지나 습관과 익숙함의 문제일 뿐이다.

- 집게에 3개의 키만 할당하지 말고 쿼티 키보드처럼 가운데 2열을 더 두는 것이 바람직하다. 다른 것은 몰라도 알파벳 JQZ가 Up 위에 배치되어 있는 것은 아무리 봐도 거부감이 들며 쉽게 납득하기 어렵다. 자신의 이름에도 J가 들어가는데 한번에 못 누르는 것은 너무 하다. PC 대체용 키보드라면 30개의 문자키를 두고 모든 알파벳을 넣는 것이 좋다. => 이 부분에 대해서는 나도 공감한다. 알파벳이 전부 배치되지 못했으므로 거부감을 느끼는 것이 당연하며 Ctrl + Z 같은 단축키는 누를 방법이 없다. 하지만 제자리 원칙에 정면으로 위배되는 사항이라 쉽게 받아 들이기는 어렵다. JQZ의 출현 빈도는 0.3%밖에 안되며 투 터치라 하더라도 입력이 불편한 정도는 아니라고 생각한다. 알파벳 문자가 다 있어야 한다는 말은 절대적으로 옳으며 나도 그렇게 만들고 싶다. 그러나 다시 생각해 보면 그럴 바에야 쿼티 키보드와 다른 점이 없으며 아너림을 만들 이유도 없는 셈이 된다. 더 고민이 필요한 부분이다.

- 키는 중복되어도 많을수록 좋다. 좌우 문자키 중간에 스페이스 키도 크게 하나 더 배치하고 쉬프트키도 양쪽에 배치하고 엔터키도 편집키 옆에 하나 더 두는 것이 좋다. => 이 부분은 전혀 동의할 수 없다. 나는 넘 패드를 지긋 지긋하게 싫어하는데 중복된 키로 인해 좌우 균형이 깨지고 면적만 넓어진다. 필요하다면 문자에 키를 중복 배치하는 것은 가능하지만 키의 개수를 불필요하게 늘릴 필요는 없다고 생각한다. 쿼티키의 조합키들이 양쪽에 2벌이 있지만 대부분의 사람들은 한벌만 사용하면 양쪽을 다 사용하는 사람이 드물다.

- 후킹 방식으로도 완벽하게 동작하는 드라이버를 제작할 수 있으며 과거에 J가 직접 만들었던 속기 키보드 프로젝트를 보여 주었다. kbd_event 함수가 키보드를 완벽하게 흉내내 주므로 IME까지도 충분히 처리할 수 있다. 디바이스 드라이버는 굳이 만들지 않아도 상관없다. 만약 꼭 디바이스 드라이버를 제작하려거든 새나루라는 오픈 소스를 참고하라 => 이 부분은 큰 도움이 되었다. 맨날 연습 프로그램으로만 테스트를 하다 보니 실질적인 테스트가 부족했는데 후킹 코드가 완성되면 더 실질적인 사용 테스트를 할 수 있을 듯 하다. 배치를 좀 더 조정한 후 최우선적으로 후킹 드라이버를 만들 것이다.

- 시제품을 만들 수 있는 여러 가지 방법에 대한 조언을 들었다. 기계식 키를 목재나 아크릴판에 원하는 형태로 배치한 후 RS 232C나 시리얼 포트에 연결하여 키 입력을 인식하는 방법을 쓸 수 있다고 한다. 앞으로도 키의 배치가 수없이 바뀔 것이므로 테스트 툴킷을 먼저 만든 후 개발에 임하는 것이 좋다. 어떤 키를 배치할 것인가를 선택해야 하는데 스캔 코드는 드라이버와의 지역적인 약속일 뿐이므로 임의의 키를 선택하여 맵핑해도 상관없다. => 시제품을 제작하는 여러 가지 방법 중 하나로서 일러준 방법은 초기 제작이 어려워도 배치 변경이 쉬울 것 같아 솔깃하다. 이 부분은 앞으로도 더 많이 조사해 보아야 한다.

- 사람의 행동 동기는 쾌락이다. 즉 즐겁기 때문에 그 일을 하는 것이다. 어쩌면 제품의 완성보다는 그 과정이 즐거울 뿐이며 제작 과정을 즐기고 있는 것이다. 만약 제품이 완성되면 배포나 대중화를 위해 또 다른 고민을 해야 하므로 즐겁지 않을 것이다. 키보드는 절대로 돈을 벌 수 있는 품목이 아니다. 지금은 키보드를 만드는 것보다는 저술에 힘 쓰는 것이 더 많은 사람에게 도움이 될 것이다. 키보드 제작은 쉬엄 쉬엄 취미삼아 하는 것이 좋다. => 지금 내가 가장 고민하고 있는 부분이다. 만들어 놔 봐야 누가 쓸지도 모르는 키보드에 왜 이렇게 시간을 퍼 붓고 있는지 나도 의아하다. 너무 오래 시간을 끌어서는 안된다는 것을 나 자신이 스스로 잘 알고 있으며 조만간 일단락 지을 계획이다. 그러나 막상 일에 몰두하면 그게 잘 안된다는게 문제다. J형은 키보드의 사업성에 대해 부정적인 생각을 가지고 있으면서도 개발자인 나의 성향을 잘 알기 때문에 대 놓고 하지 말라고 말리지는 않는다. 역시 개발자끼리 통하는 부분인 듯 하다.

이 외에도 개발에 관련된 여러 가지 정담을 나누고 왔다. 다 받아들이지는 않지만 내 생각의 고정 관념 일부가 깨지면서 변화를 줄 수 있는 여지가 생겼다. 이래서 많은 사람들의 조언을 들어 볼 필요가 있다. 지금까지 조언을 구한 사람들이 모두 긍정적인 평가를 주지는 않았고 오히려 비판적이었지만 하나, 둘씩 도움이 될만한 의견을 내 주었다. 그 의견들 중 마음에 와 닿는 것들만 취합해도 최소한의 독단은 피할 수 있을 것이다.

■ J의 조언중에 가장 공감을 느낀 부분은 알파벳 키를 다 집어 넣으라는 것이다. 알파벳을 한번에 입력할 수 없다는 것이 얼마나 치명적인 단점인지를 잘 알고 있으며 사실 이 형태로 구현해 본 적도 이미 있다. 초기 제품을 만든다면 이 형태로 만들어야지라고 기획하기도 했으며 0.90 버전에는 쿼티 호환 키보드라는 이름으로 이 형태가 남아 있다. 당시의 기획과는 많이 달라졌으므로 전체적으로 디자인을 다시 해야 한다.

알파벳키를 다 집어 넣으려면 가운데에 2열을 더 삽입해야 하며 이렇게 되면 제자리 원칙을 어기는 것이 된다. 애초의 기획 의도와 너무 많이 벗어나는 셈이라 솔직히 쉽게 받아들이기는 어렵다. 하지만 최소한 시도는 해 보아야 한다고 생각한다. 현재의 배치에서 Up 상태의 3키를 가져 오고 나머지 문자의 배치를 조금 조정하면 될 것이다. 다음과 같이 배치해 보았다.

키가 30개이고 알파벳이 26자이므로 4개가 남는다. 각각 Cap과 마침표에게 할당하고 접근이 어려운 구석의 2자리는 비워 둔다. 한글의 경우는 가운데 추가열을 굳이 사용할 필요가 없다. 영문과 보조를 맞추기 위해 .은 같은 위치에 배치하고 ㅋ을 구석자리로 옮기면 된다.

마침표를 문자 영역 안으로 들여 왔는데 사실 마침표는 세계 공통으로 문장과 함께 사용되며 순위도 영문의 h와 l 사이의 3.16%이고 한글에서는 1.16% 여서 격음보다도 더 순위가 높다. 마침표 다음은 쉼표와 따옴표인데 2순위인 쉼표가 마침표의 1/4 수준이므로 마침표만 가져와도 Up을 누를 일이 대폭 줄어든다. 사실 위 그림의 마침표 자리는 나쁜 정도는 아니지만 빈도만으로 본다면 적절치 않으며 좀 더 좋은 자리를 배정할 수 있다. 저 자리에 배치한 것은 쿼티 호환을 위한 일종의 타협점이다. Up 위치에 남은 ,"'는 한칸씩 왼쪽으로 옮겨 좋은 자리를 배정해 준다.

이렇게 하면 영문만 제자리 원칙을 어길 뿐 한글은 여전히 제자리에서 입력 가능해진다. 숫자와 기호들의 배치도 그대로 유지하면 제자리 자판이라는 이름에 결코 큰 손상을 입는 정도는 아니다. 이 배치를 하다가 마침표의 위상에 대해 다시 생각해 보았는데 한글에는 어차피 하나가 남고 영문은 빈도가 낮은 x를 Up으로 옮길 수 있으므로 설사 2열을 추가하지 않더라도 마침표를 문자 영역으로 가져오는 것이 좋을 듯하다.

알파벳을 2열을 더 추가할지 말아야 할지는 앞으로도 한참 더 고민해 봐야 할 문제이다. 하지만 연습 프로그램에는 일단 2열을 추가한 상태로 작성하기로 했으며 차후 시제품을 만들더라도 이 키를 그대로 둘 생각이다. 키를 쓸 것인가 말 것인가는 소프트웨어가 결정할 수 있으므로 일단 만들어 놓고 필요없으면 안 쓰면 그만이다. 시제품에서 모자란 것이 문제가 되지 남는 것은 문제가 되지 않는다. 그렇다면 같은 의미로 오른쪽 하단에도 왼쪽의 Fn, Edit에 해당하는 빈 키를 2개 배치해 놓을 수 있고 왼쪽 확장키에도 3개의 키를 추가 배치하여 오른쪽 확장키와 동일한 형태로 대칭을 이룰 수도 있다.

최종 제품에는 빼더라도 시제품 단계에서는 이 키들을 두는 것이 합리적이다. 아직도 나는 알파벳이 다 들어가는 것보다는 Up 상태를 두고 제자리 원칙을 지키는 것이 더 유리하다고 생각한다. 추가 2열을 배치하고 알파벳을 배치하더라도 옵션으로 중앙 영역의 사용 여부를 토글하여 다양하게 테스트할 수 있으며 그렇게 하려면 시제품에 키가 일단은 있어야 한다. 최종 제품에는 배치 관련 옵션을 빼고 고정하겠지만 상당한 기간동안은 시제품일 것이므로 테스트의 유리함을 취해야겠다. 소프트웨어는 얼마든지 수정할 수 있기 때문이다.

■ 아직도 조합키가 너무 많아 불편하고 거부감이 드는데 Sym 모드를 없애 버리고 아예 문자키 위에 한 행을 더 얹을까 하는 과격한 생각을 해 보았다. 8개의 키를 더 넣으면 16개의 문자를 배치할 수 있다. 만약 여분 2열까지 고려하면 20개의 문자가 배치된다. 자주 사용하는 문자를 아래쪽에 두고 빈도가 떨어지는 문자를 Up 위치에 다음처럼 배치한다.

22개 중 남은 6개는 마침 숫자 모드에 공간이 있으므로 끼워 넣으면 딱 맞는다. 숫자와 연관이 있는 기호들만 골라 보았다.

이렇게 했을 때의 장점은 다음과 같다.

- 괄호나 세미콜론처럼 자주 쓰는 문자를 원터치로 입력할 수 있다.

- 물리적인 키가 있으므로 Ctrl + ] 같은 단축키 입력이 용이하다.

- 키의 개수가 늘어났으므로 문자가 많은 타 언어에 융통성이 생긴다. 숫자는 영문 모드에서만 입력받고 자국 언어에서는 다른 음소를 배치할 수 있다.

- 딱 보기에 거부감이 없고 훨씬 더 직관적이다.

물론 단점도 있다.

- 기호에 대해서는 제자리 원칙이 성립되지 않는다. 2칸 위를 누르는 것도 자세를 크게 흐트리지는 않지만 아래, 위로만 이동하는 것과는 수준이 다르다.

- 많이 쓰는 문자 8개만 원터치일 뿐 Up 위치의 문자는 여전히 투터치이며 오히려 더 입력하기 어렵다.

- 키의 개수가 많아져 전체적으로 간결함이 많이 감소된다.

모드 변경에 거부감을 가지는 사람이 많아 기획해 보았는데 당장 실천에 옮길 계획은 없다. 모드 바꿔 가며 제자리에서 입력하느냐, 손이 좀 움직이더라도 원터치로 입력하느냐의 차이인데 어떤 것이 더 편리한지는 장시간 사용해 봐야 검증할 수 있다. 기획안으로 생각만 해 두고 차후에 고려해 보기로 하자.

12년 6월 15일

어제 J의 조언도 듣고 나름대로 기획한 것도 많이 있어서 한꺼번에 구현했다. 전체 기획을 다 해 본 후 구현을 하는 것이 좋지만 구현해 봐야 다음을 결정할 수 있는 부분이 있고 성질도 급한 편이라 일단 닥치고 적용해 보았다.

■ 여분키를 추가로 배치하고 점선 형태로 그려 두었다. 시제품의 유연성 확보를 위한 키이므로 최종 제품에서는 제외될 수도 있으므로 흐릿하게 그렸다. 문자키 2열 뿐만 아니라 왼쪽 확장키, 3행 오른쪽 하단키까지 총 11개의 여분키가 배치되었다.

■ 여분키가 들어감으로써 왼손 엄지의 Sym, Mode, Up에 할당할 키가 없어져 버렸다. 그래서 숫자 3,4,5키를 배정했으며 오른쪽의 Enter, BS는 원래 자기키에 맵핑했다.

■ 여분키까지 들어가니 키보드의 폭이 너무 넓어져 버렸으며 고해상도 모니터가 아니면 한눈에 잘 보이지도 않는다. 그래서 줌의 디폴트를 100%에서 80%로 축소했다. 또 키의 캡션 출력에 사용되는 폰트에도 줌을 적용하였다.

■ 기획한대 마침표를 문자키 영역으로 가져왔다. 한글은 ㅋ이 자리를 내 주고 영문은 x가 Up으로 이동했다. Up 상태에 남은 3개의 구두점들은 한칸씩 왼쪽으로 이동하여 좀 더 치기 쉬운 자리를 배정했다.

■ 영문 알파벳을 여분키에 넣기 위해 bEnglishAtExtra 같은 옵션 변수를 만들고 이 옵션에 따라 xjqz키를 Up이나 여분키로 이동시키는 기능을 작성하려고 했다. 그런데 생각해 보니 굳이 이동할 필요없이 아예 여분키에 중복 배치해 놓으면 더 쉬울 것 같아 그렇게 했다. 원터치로 입력하고 싶으면 여분키를 누르면 되고 꼭 제자리에서 입력하고 싶으면 Up 상태의 키를 누르면 된다.

어제는 여분키를 활용하여 알파벳 하위권 문자들의 배치를 다시 조정하고 모서리의 빈자를 비우려고 기획을 했었는데 이 부분은 적용하지 않았다. 왜냐하면 현재 시도는 영문 원터치를 가능하게 하는 것일 뿐이지 여분키를 꼭 사용하겠다고 확정을 한 것이 아니기 때문이다. 그리고 집게 손가락 3행이라도 자리를 벗어나기 때문에 새끼 손가락 3행보다 반드시 자리가 더 좋다고 할 수도 없다.

■ 펑션키 4개 단위로 8미리씩의 간격을 삽입하였다. 키보드의 폭이 전체적으로 넓어졌으므로 12개를 빽빽하게 배치하는 것보다는 약간씩 여분을 두는 것이 보기 좋다.

■ 엄지의 Up과 Bs키는 약간 아래로 내렸다. 비록 종이에 인쇄된 자판이지만 테스트해 보니 엄지키는 바깥으로 뻗을 때 옆으로 이동하는 것이 아니라 아래쪽으로 비스듬하게 이동한다. 그래서 바깥쪽 두 키를 누르기 쉽도록 내렸다. 차후에는 엄지행 전체를 엄지행의 기울기에 맞게 기울일 생각도 있다.

■ 3행 양끝의 키들이 엄지키와 수직으로 정렬되어 있는데 이 키들은 엄지로 누르는 것이 아니라 새끼나 약지로 누르므로 문자키와 수직 정렬하는 것이 맞다. 그래서 수직 정렬을 위로 붙였다.

꽤 많은 작업을 했지만 키맵이 유연성있게 설계되어 있어 큰 어려움은 없었다. 몇 시간동안 코딩에 몰두했는데 역시 코딩은 참 재미있는 작업이다. 여기까지 작업한 결과는 다음과 같다.

여분키들은 흐릿한 점선으로 그려 필수키가 아님을 표시했다. 차후 시제품을 만들면 이 키들을 전부 포함시킬 것이다. 문자키 중앙에 2열이 삽입되었지만 원래 공간이 있었으므로 이 키들 때문에 폭이 늘어나지는 않았다.

추가된 여분키에 xjqz키가 중복 배치되었고 마침표를 문자키 영역 안으로 가져왔다. 한글도 같은 방식으로 수정했으며 Up 위치의 구두점들도 자리를 약간씩 조정했다. 마침표가 아래로 내려옴으로써 Up키의 빈도에 변화가 생겼는데 영문은 1.92%에서 1.54%로 감소되었고 한글도 1.97%에서 1.53%로 비슷한 비율로 감소했다.

펑션키가 4개씩 그룹화되었고 Up, BS가 약간 아래로 내려갔으며 3행의 양끝이 문자키쪽으로 붙었다. 비록 여분키 때문이지만 좌우가 정확하게 대칭이어서 보기에도 꽤 좋다. 그러나 수평으로 18키 정도가 있으며 키보드의 전체 폭이 너무 넓어져 거의 PC 키보드 수준이 되어 간다. 넘패드가 없는 텐키레스 키보드와 같은 폭이다.

12년 6월 16일

어제의 작업으로 인해 유연성이 대폭 증가하였다. 최종 제품에는 이 키들이 다 들어갈 것은 물론 아니지만 개발 단계에서는 유연성의 폭을 넓게 잡아 두고 다양한 시도를 해 보는 것이 옳다. 그래서 유연성을 더욱 극대화하기로 하였다.

■ 여분키가 들어감으로 해서 기존 쿼티 키보드의 모든 문자키가 아너림에도 존재한다. 이렇게 되면 각 언어의 배치를 옵션으로 선택할 수도 있게 된다. 단 여분 키그룹이 존재할 때만 이 옵션을 사용할 수 있다.

한글 : 아너림, 2벌식

영문 : 아너림, 아너림에 xjqz만 여분키로 옮긴 배치, 쿼티

이런 기획을 한 이유는 한글은 아너림이 좋은데 영문은 굳이 바꿀 필요성을 느끼지 못하는 사용자라면 영문은 계속 쿼티 배치를 사용할 수 있기 때문이다. 반대로 무척 드문 경우겠지만 한글은 2벌식으로 쓰고 영문은 아너림 방식으로 쓰는 것도 가능하다.

그러나 생각해 보면 한글 2벌식에 영문 쿼티를 쓰는 배치라면 굳이 기능을 제공할 필요도 없고 후킹을 하지 않으면 그만이다. 문자키 맵핑이 쿼티키와 동일하므로 운영체제의 드라이버에게 넘겨 버리면 된다. 문자키 바깥의 [ ] \ ' 등의 키는 존재하지 않으므로 이 기호를 입력할 방법이 없는 문제가 있는데 이 경우에는 간단하게 해결책을 제시할 수 있다. 이런 것까지 원한다면 그냥 쿼티 키보드를 쓰면 그만이다.

이 기획에서 실질적으로 실용적인 옵션은 한글 아너림 + 영문 쿼티 뿐이다. 영문을 쿼티로 쓴다는 것은 아너림의 기획 의도와는 일치하지 않지만 최소한 한글이라도 아너림 배치를 쓸 수 있다는 면에서 보급상의 가치가 있다. 전에도 생각해 놓은 적이 있는데 이런 것도 가능하다는 하나의 가능성으로만 남겨 두고 당장 구현은 하지 않기로 한다. 시제품 단계에서는 테스트를 위해서라도 필요한 기능이므로 차후에는 구현해 볼 것이다.

■ Edit와 Fn이 엄지키 영역을 벗어남으로써 이 모드들은 제자리 원칙에서 반쯤 제외되었다. 문자 입력 외에는 제자리 원칙을 굳이 지킬 필요가 없다는 판단에서였는데 생각해 보니 현재의 모드 키로도 이 두 기능을 구현할 수 있는 방법이 있었다. 전에는 없었는데 Up키가 왼손 엄지 영역으로 들어오고 숫자 임시 입력 기능이 Mode키 홀드로 옮겨지면서 이것이 가능해졌다. 엄지 영역의 3키에 대한 각 동작을 다음과 같이 정의한다.

키	푸시	홀드	더블
Up	Up 전환(자동 복귀)	Edit 모드	Up 고정
Mode	언어 순환	숫자 모드	숫자 고정
Sym	Sym 전환(자동 복귀)	Fn 모드	Sym 고정

Up키와 Sym키의 홀드 기능을 현재 미사용하고 있는데 이 두 키에 임시적인 모드 변환 기능을 정의하면 편집과 펑션키도 제자리 원칙을 고수할 수 있다. 이렇게 되면 Edit와 Fn키는 굳이 필요치 않다. 다만 Edit와 Fn 모드 상태로 고정할 수 있는 방법이 없어서 문제가 되는데 두 모드는 높은 구성에서 모두 별도키들이 있으므로 딱히 문제가 되지는 않을 것이다.

연습 프로그램에서 이 모드로 전환되지 않으므로 키 배치를 보일 방법이 없다는 것도 문제인데 이는 0.5초동안 홀드하고 있으면 잠시 보여주는 방식으로 해결할 수 있다. 아주 예전에 Mode키를 0.5초동안 누르고 있을 때 숫자 키보드를 보여주는 방식을 사용한 적이 있는데 그 방법을 그대로 사용하면 된다. 물론 물리적인 키보드에서는 각인에 세기기만 하면 될 뿐 이런 처리가 필요치 않다.

Up과 Sym의 홀드 다운에 대한 코드를 작성했는데 보기보다 문제가 많았다. 우선 키를 계속 누르고 있을 때 해당 키 배치를 화면에 보여주는 것이 문제였는데 실제 모드를 바꿔 버리면 이전 모드로 복귀하기가 어렵고 복귀할 것인지 아닌지를 결정하기도 쉽지 않다. 그래서 현재 모드는 Mode 변수에 그대로 두고 DisplayMode 변수를 새로 도입하여 이 변수만 바꾸는 식으로 문제를 해결하였다. OnPaint는 DisplayMode만을 참조하여 그리며 홀드 상태일 때 DisplayMode만 잠시 변경한다.

또 Mode, Up, Sym 세 키 모두 키를 누른 채로 뭔가 조작을 할 수 있으므로 키를 누르는 시점에 본 기능을 처리해서는 안되며 키를 놓을 때 처리해야 한다. 중간에 다른 키 입력없이 단독으로 눌렀을 때 본 기능을 수행하고 홀드한 채로 다른 키를 눌렀다면 표시 모드만 원래대로만 바꿀 뿐 별다른 다른 처리를 할 필요는 없다. 키다운, 키업, 타이머, 더블 푸시 등의 복잡한 동작을 매끄럽게 처리하기가 상당히 어려웠다. 다행히 세 키 모두 처리하는 논리는 같아서 하나만 제대로 작성한 후 나머지는 똑같이 적용했다.

테스트해 보면 그럭 저럭 잘 동작은 한다. 마우스로는 홀드 다운을 할 수 없다는 문제가 있는데 이 부분은 차후 터치 화면에서 테스트할 때 다시 작성해야 한다. 멀티 터치를 구현해야 하므로 현재로서는 작성하기 어렵다. 제자리에서 편집 및 펑션키 입력이 가능해졌다. 하지만 문서상으로 밝혀 놓지 않으면 사용자가 직관적으로 발견하기는 무척 어려우며 확장키가 있는 상태에서는 굳이 사용할 필요도 없는 기능이다. 다만 제자리 편집을 꼭 하려면 이런 기능을 쓸 수 있다는 정도의 의미가 있다.

Fn과 Edit는 이제 더 이상 키로 남아 있을 필요가 없다. 두 모드를 고정할 수 없는 문제가 있지만 어차피 풀 구성에서는 모드를 바꿀 필요조차도 없으므로 별 의미가 없을 것이다. 이 두키는 굳이 삭제할 필요는 없고 여분키로 돌려 놓으면 그만이다. Fn과 Edit의 자리가 비면 다시 CSAW키가 원래 위치로 돌아올 수 있다. 여기까지 작업한 결과는 다음과 같다.

조합키를 하단으로 다시 옮기면 왼쪽 확장키에는 Esc와 Tab만 남는데 여기다 PrtSc키를 추가했다. 사실 많이 안 쓰는 키이지만 책을 쓰는 입장에서 이 키는 꼭 필요해서 따로 빼 두었다. 그래도 여분키가 너무 많이 남아 있는데 그렇다고 마땅히 더 넣을 키도 없다. Insert는 키로 뺀다면 오른쪽 확장 영역에 들어가는 것이 옳고 Pause는 거의 사용되지 않으므로 그냥 편집 모드에 쳐박아 두자.

■ 편집 모드와 펑션키 모드를 재배치한다. Esc와 Tab이 확장키에 있지만 Standard 구성에서도 입력이 가능했으면 좋을 것 같아 다시 집어 넣기로 했다. 또 RWin키가 빠졌는데 이 키도 집어 넣기로 한다. 3개의 락키는 자리를 비켜 주기 위해 펑션 모드로 옮긴다.

펑션 페이지는 다소 많이 바뀌었다. 펑션키를 좌에서 우로, 위에서 아래로 배치했었는데 직관적이지만 숫자 키패드의 번호와 달라 외우기가 어렵다. 그래서 숫자 키패드와 가급적 일치시켰는데 F11, F12의 위치가 좀 애매해서 그렇지 더 직관적이지 않을까 생각된다.

왼쪽에는 멀티 미디어키와 인터넷 키, 그리고 편집 페이지에서 이사온 락 키들을 배치했다. 증가를 위에, 감소를 아래 배치하여 외우기 쉽도록 했는데 뭐 그래 봤자 도찐 개찐이다. 차후에 언제든지 바뀔 여지가 많지만 일단은 마음에 드니 이대로 유지하기로 한다.

■ 현재 구성이라는 개념으로 4가지 형태의 키 집합을 제공한다. 그러나 레벨이 순차적이어서 상위 단계는 하위 단계를 항상 포함하는 식이다. 그래서 펑션키는 빼고 오른쪽 편집키만 둘 수 없다. 단계적으로 되어 있는 구성 방식을 개별적인 카테코리로 정의하고 각 카테고리의 보임을 토글할 수 있도록 한다. 키의 카테고리를 다음과 같이 새로 정의한다.

키그룹	개수	설명
기본(basic)	30	문자키와 엄지키 30개. 문자 입력만 가능하다. 생략할 수 없다.
조합(Modifier)	4	CASW 조합키
왼쪽 편집(LeftEdit)	3	왼쪽의 편집키들. Esc, Tab, PrtSc
오른쪽 편집(RightEdit)	9	오른쪽의 편집키들
펑션(Function)	12	F1~F12
여분(Extra)	12	문자 2열, 왼쪽 확장키 6개

여분키를 어떻게 할당하는가에 따라 개수는 가변적이다. 총 키 개수는 현재 70개이며 여분을 제외하면 58개이다. 이제 각 그룹을 개별적으로 토글하여 조합을 취할 수 있다. 기존의 레벨이라는 개념은 일단은 유지하되 카테고리 조합에 대한 이름일 뿐이다. 기존 레벨에 여분을 포함한 Extra가 추가된다. 메뉴와 단축키에도 추가된 레벨을 정의하고 코드는 레벨이 아니라 카테고리의 보임 여부에 따라 동작을 결정한다.

12년 6월 17일

■ 외사촌 결혼식 참석. 아우가 요즘 뭐하냐고 묻길레 키보드를 만들고 있다고 대답했다. 아우가 대뜸 하는 말이 그걸 도대체 왜 만드느냐, 요즘 음성 인식이 얼마나 정교한데 키보드로 입력을 하느냐는 것이다. 기획 초기에도 이 키보드를 아우에게 보여준 적이 있는데 그때 반응도 비슷했다. 친동생이 이 정도니 대부분의 사람들 반응도 냉담한 것이 어쩌면 당연하다. 잘 사용하고 있는 키보드를 왜 또 새로 만드느냐고 반문하고 열심히 설명하면 친분상 대 놓고 말을 못할 뿐 거의 미친짓 취급을 받는다.

그러나 내 생각은 다른데 하긴 다르니까 이렇게 만들고 있는 것이다. 음성 인식이나 OCR 같은 입력 방법도 훌륭하고 편리하지만 정확도나 범용성 등에서 한계가 있으며 아무 상황에서나 쓸 수 없다. 지하철에서 음성으로 문자 메시지를 입력할 수 없는 노릇이며 그렇다고 소리샘 서비스를 사용하는 사람은 더 없다. 키보드는 가장 기본적인 입력 장치이면서도 궁극의 입력 장치여서 어떤 형태로든 키보드는 존재해야하는 필수품이다.

조언을 구하는 모든 사람들의 반응이 냉담한 것은 충분히 이해한다. 어떤 발명품이든 처음 만들 때는 다 천덕꾸러기였었다. 몇몇 메일로 관심을 표명한 소수의 사람들은 키보드에 관심이 많기 때문에 나를 이해해주는 것이다. 하지만 결국 나는 끝까지 만들 것이다. 모두의 마음에 들 자신은 없고 그럴 필요도 없지만 최소한 내 마음에 쏙 들 때까지는 만들어 볼 것이다.

■ 아너림 키보드의 가장 큰 원칙이면서 장점은 제자리 원칙이다. 자세를 유지한 채로 입력 가능하므로 여러 가지 이점이 있다. 사람들이 이 부분을 직관적으로 잘 인식하지 못하고 또 경험도 못해 봤기 때문에 혹독한 평가가 나오는 것이 아닌가 생각된다.

- 고속 입력이 가능하다.

- 오타 발생 빈도가 현저히 줄어든다.

- 피로도가 낮다

- 키보드를 보지 않고 입력 가능하다. 쿼티 자판은 아무리 익숙한 사람도 숫자, 기호는 슬쩍이라도 봐야 입력 가능하다. 보지 않고 칠 수 있으므로 장갑, 손잡이 형태로 변형 가능하며 응용의 여지가 많아진다. 소형화도 그 중 하나이다.

- 입력이 원활해지면 사고의 연속성이 확보되고 머리가 손으로부터 해방된다. 사람은 걸어가면서 머리속으로 딴 생각을 할 수 있고 말을 하면서도 다음 말을 생각한다. 머리가 다리를 통제하거나 발음 기관에 전혀 관여하지 않는다. 머리가 해방되면 타이프를 치면서 다음 문장이나 코드를 연쇄적으로 떠올릴 수 있다.

이 중 안보고 친다는 것과 사고의 연속성 확보는 실제 사용해 보면 상당한 편의성을 제공할 것으로 기대된다. 물론 키의 개수가 적음으로 인한 단점들도 있다. 원터치로 바로 입력할 수 없는 문자가 존재하며 상당한 연습과 익숙해짐을 요구한다. 단점과 장점의 대소를 비교해 보면 장점이 단점을 충분히 커버할 수 있다고 생각한다. 만고 내 생각인지 모르겠지만 말이다.

■ Up, Sym 홀드에 기능이 들어가다 보니 두 키를 오래 눌러 뜻하지 않게 이모티콘 모드로 들어가는 경우가 많다. Up 상태에서 Sym키가 이모티콘 전환으로 정의되어 있기 때문이다. 실제 키보드에서는 빼야 할 기능이지만 모바일 때문에 연습 프로그램에는 아직 남아 있는데 전환 방법을 좀 더 복잡하게 만들 필요가 있다. Up을 누른 후 0.5초 내로 Sym을 바로 눌러야 전환되도록 수정했다. 웬만해서는 연습 프로그램에서 우연히 이모티콘 모드를 보기 어렵다. 차후에는 뺄 것이다.

■ 현재 보이지 않는 키에 대한 입력은 받지 않는다. 예를 들어 편집키가 보이지 않으면 키보드의 커서 이동키는 아예 무시한다. 이 처리는 대부분의 키 입력 루틴에 작성되어 있지만 여분 영문키에 대해서는 아직 작성되어 있지 않다. 여분키에 할당된 xjqz키는 여분키가 보이지 않는 상태에서도 입력을 받는 문제가 있다. 모드나 구성에 상관없이 현재 보이지 않는 키는 모든 입력을 무시하도록 수정하였다. 아예 KeyDown에서 키 입력을 거부한다.

■ 더블 푸시 간격을 0.2초로 조정했었는데 실제 사용해 보니 숫자 모드로의 전환이나 Up 락이 쉽지 않음. 그래서 0.3초로 약간 더 늘려 주었다.

■ Up, Sym 홀드 상태로 편집 및 펑션키 입력이 가능토록 한 것은 무척 마음에 드는 개선 사항이다. 하지만 홀드 상태로 임시적인 입력만 가능할 뿐 해당 모드로 전환하여 고정할 수는 없다는 점이 마음에 들지 않았다. 확장키가 없는 구성에서 문서의 아래 위로 계속 이동하면서 읽으려면 Up 키를 계속 누르고 있어야 하는데 아무리 최소 구성이라 하더라도 너무 불편하다.

이를 개선하기 위한 방법을 기획해 보았다. Up 키를 누른 채로 오른손 엄지의 키 하나를 누르면 편집 모드로 전환하여 고정한다. 이후에는 Up 키를 놓아도 계속 편집 모드로 키를 누를 수 있다. 풀려면 Mode키로 언어 모드로 전환하면 된다. 오른손 엄지의 키에는 편집 모드에 특별한 기능이 없으므로 Lock키로 사용할 수 있다. 3개의 오른손 엄지키중 Enter가 가장 적합하다. 편집중에 공백이나 삭제는 종종 하지만 개행은 잘 하지 않는다. 만약 정 개행을 하려면 Up의 홀드를 풀고 개행해야 하는 어려움이 있다. Sym도 마찬가지로 Sym 홀드 상태로 Enter를 푸시하면 펑션키 모드로 락한다.

이 방법은 조작이 까다롭고 따로 외워 두어야 한다는 점에서 복잡도를 증가시킨다. 또한 풀 구성에서는 편집키와 펑션키가 따로 있으므로 굳이 이런 복잡한 방법까지 동원할 필요도 없다. 다만 Standard 구성에서도 모드를 락할 수 있는 방법을 제공한다는 데 의의가 있다. 엄지에 걸리는 6개 키의 조합을 잘 취하면 예상외로 다양한 조작이 가능한데 이를 응용하는 것이다.

기능을 작성한 후 잠시 사용해 봤는데 특별한 이점은 없는 것 같다. 그냥 꼭 하려면 가능하다는 정도다. 시제품을 풀 구성으로 제작할 것이므로 이 기능은 애써 공개할 필요가 없으며 일종의 숨겨진 기능으로 취급한다.

■ 편집 페이지의 오른쪽 끝에 Cut, Copy, Paste 클립보드 액션키를 배치한다. 현재는 Insert, Prtsc, Pause키가 배치되어 있는데 Insert는 Delete와 유사한 위치에 두기 위해서이고 나머지 두 키는 임의적으로 배치한 것이다. 클립보드 액션은 일종의 편집키이므로 편집키와 인접 배치하는 것이 좋다. 다음과 같은 작업이 편해진다.

koera

e와 r의 순서가 바뀌었다. 편집 모드로 간 후 e로 이동한 후 Shift+Left하여 e를 잘라내고 한칸 오른쪽으로 가서 Paste한 후 End를 누르면 수정된다. 복잡해 보이지만 실제 키보드에서도 이런 식으로 작업하며 전혀 불편해하지 않는다. 원래부터 굉장히 복잡한 동작이지만 그만큼 익숙해져 있는 것이다. 편집 모드 락 후 제자리에서 이 모든 편집이 가능하다.

이때 순서는 위에서부터 순서대로 Copy, Paste, Cut으로 한다. Cut의 빈도가 낮으므로 제일 구석에 배치하고 Cut, Paste와 Copy, Paste는 연속적으로 사용하는 쌍이므로 Paste를 중앙에 두는 것이 좋다.

사용해 보니 약간 실용성은 있는 것 같다. 그러나 역시 익숙해지기는 쉽지 않다. 확장키를 사용하면 조금 더 쉬워질 것이다.

12년 6월 20일

아직까지 아너림은 연습 프로그램에서만 실행된다. 그러다 보니 다양한 상황에서의 편의성을 테스트해 보지 못했다. 글만 입력하는 것이 아니라 소스 코드도 작성해 보고 인터넷 게시판에 글도 써보고 워드에서 문장도 입력해 봐야 한다. 그러기 위해서는 디바이스 드라이버를 만들거나 아니면 후킹이라도 해야 한다.

현재 제작되어 있는 후킹 코드는 활성 윈도우를 찾아 WM_CHAR 메시지를 보내는 수준밖에 안되어 제대로 동작하지 않는다. 겨우 메모장 정도만 후킹될 뿐이며 그나마도 한글 조립중인 상태는 제대로 보이지도 않는다. 그래서 후킹으로는 한계가 많으며 결국에는 디바이스 드라이버를 만들어야겠다고 생각했다. 물론 종착점은 디바이스 드라이버이지만 내가 아직 기술을 확보하지 못했다는 것이 문제다.

그런데 최근 화면 키보드를 관찰한 후 후킹도 디바이스 드라이버를 대체할만한 기술이라는 확신이 들었다. 화면 키보드에서 마우스를 클릭하여 입력하면 모든 프로그램에 키입력을 흉내낼 수 있다. 이것이 가능하다면 키보드를 후킹해서 디바이스 드라이버를 대체하는 것도 분명히 가능한 일이다. 당분간은 디바이스 드라이버를 만들지 않아도 상관없고 사용하기도 덜 부담스럽다.

그래서 후킹 코드를 작성하고 있는데 처음 예상했던 것보다 훨씬 더 난이도가 높았고 골치 아픈 문제들이 많았다. 후킹 자체는 이미 해 본 적도 있고 꽤 경험도 많은 편이지만 막상 테스트 코드를 작성해 보니 전혀 동작하지 않았다. a를 입력하면 b로 바꿔서 보내는 간단한 동작 조차도 제대로 되지 않았다. 거의 한나절동안 이런 저런 시도를 해 보았지만 원인조차 찾지 못했다.

디버깅도 해 볼 수 없는 상황이라 일일이 문자열로 기록한 후 로그를 봐야 한다. 후킹은 워낙 저수준에서 일어나는 동작이라 중단점을 걸어도 제대로 걸리지도 않을 뿐더러 컴파일러가 죽기도 하고 심할 경우는 운영체제가 블루 스크린을 띄워 버릴 정도다. 이럴 때 궁극의 디버깅 방법은 역시 텍스트 디버깅이다. 누워서 골똘히 생각해 보고 텍스트 디버깅까지 동원한 후에야 원인을 발견했다. 문제는 재귀 호출이다.

키 입력을 가로채는 것은 전역 후킹 DLL만 제작하면 되므로 아주 쉽다. 그러나 입력받은 키를 아너림에 맞게 바꿔서 다시 보내는 것이 어렵다. keybd_event 함수로 키 입력 메시지만 발생시키면 메모장으로 바꿔서 전달될 것이라 생각했는데 이 함수가 발생시킨 키 입력도 결국은 후킹 체인을 거쳐서 전달되므로 다시 아너림에게로 돌아와 버린다. 아너림은 b에 대해서는 뭔가 다른 문자로 바꿔서 다시 이벤트를 발생시키고 이 메시지도 다시 후킹 체인을 타는 것이다.

그러다 보니 최종 목적지인 메모장으로는 메시지가 전혀 가지 않고 아너림 혼자서 메시지 받고 지가 또 메시지 보내고 받기를 무한히 반복하는 것이다. 재귀의 고리를 끊기 위해서는 키보드로부터 발생한 메시지와 자신이 인위적으로 생성한 메시지를 구분해야 한다. 그러나 keybd_event가 키보드를 완벽하게 흉내내므로 이것은 원칙적으로 불가능하다. 실제 키보드로부터 발생한 메시지와 인위적으로 발생시킨 메시지를 구분할 수 있는 공식적인 방법은 없다.

2가지 정도 꽁수를 생각해 봤는데 첫번째는 키 입력 메시지 앞뒤로 F24의 누름, 놓음 입력을 보내 그 사이에 있는 메시지는 훅 체인으로 그냥 흘려 보내는 것이다. 그럭 저럭 잘 동작한다. 그러나 한글은 조립이 풀려 버리는 치명적인 문제가 있다. 두번째는 스캔코드를 0xff로 조작해서 보내고 이렇게 조작된 메시지를 훅 체인으로 보내는 방법인데 비교적 잘 동작한다. 하지만 스캔 코드를 참조하는 프로그램에게는 제대로 동작하지 않을 것이다. 이 문제는 차후 0xf0~0xff까지 스캔 코드를 조작한 후 체인으로 보낼 때 원래 스캔 코드로 복원해 주는 방법을 고려하고 있다.

이벤트의 재귀 문제를 풀고난 후에는 그럭 저럭 후킹이 동작하기 시작했다. 그러나 아직도 문제들이 굉장히 많다. 워드와 메모장의 문자 처리 코드가 달라 똑같은 후킹 코드라도 다른 결과가 나타난다. 또 다른 프로세서의 IME 모드를 조사하거나 바꾸는 것도 뜻대로 되지 않는다. 편집키나 펑션키, 조합키에 대해서도 정확한 메시지를 날리는 것이 생각처럼 쉽지가 않다.

후킹에 관련된 여러가지 문제를 연구하기 위해 HookTestForAnerim 예제를 만들고 필요한 테스트 코드를 하나 둘씩 만들어 가져오고 있는 중이다. 아너림의 기존 테이블과 코드를 사용하기 위해 조건에 따라 후킹 코드를 동작시키도록 작성하고 있는데 그러다 보니 소스는 점점 걸레가 되어 가고 있다. 키 입력과 후킹은 구조가 많이 다른데 키는 WM_KEYDOWN, WM_KEYUP이 각각의 메시지로 오지만 후킹은 lParam의 최상위 비트로 구분해야 한다. 그러다 보니 전체적인 함수 구조가 맞지 않아 다량의 if 문으로 버티고 있는 중이다. 차후 대대적인 코드 리팩토링 작업이 필요하다.

이렇게 문제가 많은데 다른 프로그램들은 어떻게 하는지 분석해 보기 위해 전에 구해 두었던 안마태 자판의 소스를 분석해 보았다. 안마태 자판의 드라이버도 비슷한 방식으로 제작되었다. 초기 버전이라 그런지 되는 것보다 안되는 것이 훨씬 더 많다. 한글 조립 후 공백 누르면 두칸씩 건너 뛰기도 하고 종성 입력 후 BS로 마지막 음소 지우고 다시 입력하면 한글 조립이 풀려 버기기도 한다.

자판 자체도 그다지 잘 배치된 것 같지 않다. 경음을 오른쪽 키와 동시에 누르는 방식은 나름 괜찮다. 그러나 격음을 ㅎ과 함께 누르는 방식은 영 아니올시다이고 게다가 ㅎ의 위치가 치기 힘든 곳에 있어 실용성이 떨어진다. 3벌식이라는 것도 편리함보다는 단점이 더 많은데 손 연타가 계속 발생할 수밖에 없는 구조다.

소스는 컴파일되지 않아 디버깅해 볼 수 없다. 길이는 그리 길지 않아 대충 읽어볼 수 있지만 그다지 참고할만한 내용은 없는 것 같다. 어차피 kbd_event나 SendInput으로 이벤트를 발생시키는 기본 구조는 동일하다. 소스를 공개해 준 것은 참 고마운일이나 제대로 동작하지 않는 소스이다 보니 참고할 마음이 들지 않는다. 더 최신 소스를 구해 봐야겠다.

후킹은 오토마타를 적용하지 않고 기존 드라이버의 키 입력을 조작하는 방식이다. 예를 들어 ㅇ을 누르면 2벌식의 ㅇ 자리에 해당하는 D 가상키를 보내 ㅇ을 입력한다. 2벌식에 대응되는 키가 있다면 맵핑만 바꿔 주면 된다. 그러나 아너림은 맵핑되지 않는 문자도 있는데 예를 들어 ㅏ를 2번 누르면 ㅑ로 바뀌어야 한다. 이것은 BS를 보내 앞의 ㅏ를 지우고 가상키 U를 다시 보내 ㅑ를 재입력하는 방법으로 해결했다. 훌륭하게 잘 동작한다.

그러나 기존의 2벌식 디바이스 드라이버에 기생하는 방식이라 명백한 한계가 있다는 것도 알게 되었다. 다음 문제들은 웬만한 방법으로는 해결하기 어렵다.

- 입력된 음소를 삭제하는 것을 아너림 방식으로 수행할 방법이 없다. "강"까지 입력된 상태에서 BS를 보내면 마지막 음수인 받침 ㅇ이 잘 삭제되며 "와" 같은 복모음 문자도 ㅏ만 삭제된다. 그러나 "여"를 입력한 상태에서 BS를 누르면 "어"가 되지 못하고 ㅕ가 통째로 삭제되며 ㅇ만 남는다. 아너림에서는 ㅕ가 ㅓㅓ로 정의되어 있고 복모음 취급하지만 2벌식은 그렇지 않기 때문이다.

- Shift키와 함께 문자를 입력할 때 Shift키의 동작을 막을 방법이 없다. 아너림은 위쪽 문자를 입력하기 위해 Up키를 사용하며 Shift는 단축키 입력 용도로만 사용한다. 연습 프로그램에서 Shift키와 ㄱ을 같이 누른다고 해서 ㄲ이 되지는 않는다. 하지만 후킹의 경우 ㄱ에 대한 가상키만 보내므로 Shift키를 누르면 ㄲ이 입력되어 버린다.

두 문제 모두 억지로 해결하자면 방법이 없는 것은 아니다. 복모음 삭제의 경우 IME의 조립 문자열을 읽어 음소를 분해하고 전 단계를 구해 대체하거나 조립중인 문자열을 내부적으로 관리하는 방법을 쓸 수 있다. 그런데 과연 ㅕ 상태에서 BS를 눌렀을 때 ㅓ로 돌아가는 것이 맞을까 하는 생각이 든다. 오토마타 구성상 복모음이지만 그냥 ㅕ를 다 지우는 게 차라리 낮지 않을까 싶기도 한데 이 경우는 연습 프로그램을 수정해야 한다.

Shift키의 경우 누르고 있는지 보고 그렇다면 억지로 Shift를 떼는 이벤트를 보내야 한다. 이렇게까지 할 거라면 차라리 디바이스 드라이버를 만드는 것이 더 나을 것 같다는 생각이 든다. 다행히 심각한 문제는 아니므로 노운 버그로 남겨두고 시제품 테스트까지만 하도록 하자.

몇 가지 문제가 있지만 그래도 어느 정도 동작한다는 것은 확인했다. 남은 문제들은 하나씩 각개 격파해야 하는데 상당한 시간이 걸릴 것 같다.

12년 6월 21일

■ 아직까지 연습 프로그램에서 IME의 모드를 조사하거나 변경하는 동작이 수행되지 않는다. 메모장은 한글 모드이지만 아너림은 영문 모드이면 보내는 가상키를 한글 음소로 인식하므로 엉뚱한 문자가 찍히고 반대도 마찬가지이다. 후킹중에는 메모장의 한영 전환키도 먹지 않아 후킹을 풀고 모드를 바꾼 후 다시 후킹을 걸어야 하며 메모장에서 워드로 포커스를 옮길 때도 마찬가지이다.

이 문제는 J에게 메일로 질문하여 도움을 받아 해결하였다. 코드를 주지는 않았지만 힌트를 주었다. 원래 잘 동작하는 코드이지만 프로세스간에 동작하지 않을 뿐이었다. 후킹 DLL은 후킹만 하고 모든 논리는 연습 프로그램이 수행하는데 그러다 보니 후킹 당하는 타겟 프로그램과 프로세스가 달라 동작하지 않은 것이다. IME를 조작하는 부분만 후킹 DLL로 옮기고 연습 프로그램과는 메시지와 리턴값으로 명령을 주고 받음으로써 IME 조작이 가능해졌다.

이제 타겟 프로세스의 IME모드를 알아내 모드를 동기화하고 Mode키를 누르면 한영 토글도 가능해져서 원활하게 한글과 영문을 입력할 수 있다. 그러나 새로 생성되는 윈도우에 대해서는 아직도 좀 문제가 있는 것 같다.

■ 어제 프로젝트 회의차 잠시 영등포 사무실에 들러서 친구 P와 후배 S에게 아너림 키보드를 보여 주었다. 같은 개발자들이라 이해도가 높은 편이었지만 역시 기존 키보드를 대체하는 것은 무리라는 의견을 주었다. 대신 고속 입력을 주요 타겟으로 두고 개발하면 글을 많이 쓰는 사람들에게 실용성이 있을 것이라는 조언을 주었다. 저녁에는 대학 친구 P를 만났는데 그냥 키보드 만든다는 얘기만 하고 보여 주지는 않았다. 좀 엉뚱하지만 너 같은 발명가도 꼭 필요하다는 격려를 해 주었다.

■ 후킹 프로그램에 여러 가지 잔버그들이 많은데 문제는 증상이 프로그램마다 달라진다는 것이다. 똑같은 후킹 코드라도 키보드 이벤트를 받아들이는 쪽에서 이벤트를 해석하는 방식에 따라 입력되는 결과 문자가 달라진다. 가상키를 보느냐, 스캔 코드를 보느냐에 따라서도 달라질 것이고 사소한 플래그 하나에도 결과가 달라질 수 있다. 현재 가장 큰 문제는 메모장에서 한글 조립중에 공백이나 마침표같은 문자를 입력할 때이다. 예를 들어 "아."을 입력해 보면 메모장과 당근은 각각 다음과 같이 입력된다.

메모장에서는 한글 조립이 풀리기전에 .이 한번 입력되고 조립을 푼 후에 한번 더 입력된다. 당근도 두 개의 점이 입력되는 것은 마찬가지인데 점이 둘 다 뒤쪽에 붙는다. 반면 워드나 비주얼 스튜디오, 웹 브라우저에서는 별 이상이 없다. 모든 프로그램에서 똑같이 입력을 받아들여야 한다.

어떤 차이점에 의해 이런 문제가 발생하는지 테스트 코드를 작성하여 원인을 분석해 보았다. 받은 이벤트, 보낸 이벤트를 일일이 점검해야 하므로 시간이 상당히 오래 걸리고 어려운데 이런 문제는 텍스트 로그를 남겨 분석하는 방법이 제격이다. 이후의 개발자에게도 참고가 될만한 내용이므로 간략하게 정리해 두기로 한다. 이벤트를 순서대로 보낼 때는 메모장도 잘 동작하지만 키입력을 받아 변형 후 보낼 때는 이상이 발생한다. 로그 출력 결과는 다음과 같다.

순서대로 보낼 때

키보드 입력을 받아 보낼 때

카운터=000001(0:12:38:26) keybd_event(D - Down) 카운터=000002(0:12:38:26) keybd_event(D - Up) 카운터=000003(0:12:38:26) keybd_event(K - Down) 카운터=000004(0:12:38:26) keybd_event(K - Up) 카운터=000005(0:12:38:26) keybd_event( - Down) 카운터=000006(0:12:38:26) keybd_event( - Up) 카운터=000007(0:12:38:26) OnKeyHook : 44(D),ff0001 - 되받아서 체인 전달 카운터=000008(0:12:38:26) OnKeyHook : 44(D),c0ff0001 - 되받아서 체인 전달 카운터=000009(0:12:38:26) OnKeyHook : 4b(K),ff0001 - 되받아서 체인 전달 카운터=000010(0:12:38:26) OnKeyHook : 4b(K),c0ff0001 - 되받아서 체인 전달 카운터=000011(0:12:38:26) OnKeyHook : 20( ),ff0001 - 되받아서 체인 전달 카운터=000012(0:12:38:42) OnKeyHook : 20( ),c0ff0001 - 되받아서 체인 전달

카운터=000001(0:13:28:96) OnKeyHook : 44(D),200001 - 키보드로부터 받음 카운터=000002(0:13:28:96) keybd_event(D - Down) 카운터=000003(0:13:28:96) OnKeyHook : 44(D),40ff0001 - 되받아서 체인 전달 카운터=000004(0:13:28:174) OnKeyHook : 44(D),c0200001 - 키보드로부터 받음 카운터=000005(0:13:28:174) keybd_event(D - Up) 카운터=000006(0:13:28:174) OnKeyHook : 44(D),80ff0001 - 되받아서 체인 전달 카운터=000007(0:13:28:548) OnKeyHook : 4b(K),250001 - 키보드로부터 받음 카운터=000008(0:13:28:548) keybd_event(K - Down) 카운터=000009(0:13:28:548) OnKeyHook : 4b(K),40ff0001 - 되받아서 체인 전달 카운터=000010(0:13:28:626) OnKeyHook : 4b(K),c0250001 - 키보드로부터 받음 카운터=000011(0:13:28:626) keybd_event(K - Up) 카운터=000012(0:13:28:626) OnKeyHook : 4b(K),80ff0001 - 되받아서 체인 전달 카운터=000013(0:13:28:891) OnKeyHook : 20( ),390001 - 키보드로부터 받음 카운터=000014(0:13:28:891) keybd_event( - Down) 카운터=000015(0:13:28:891) OnKeyHook : 20( ),40ff0001 - 되받아서 체인 전달 카운터=000016(0:13:28:985) OnKeyHook : 20( ),c0390001 - 키보드로부터 받음 카운터=000017(0:13:28:985) keybd_event( - Up) 카운터=000018(0:13:28:985) OnKeyHook : 20( ),80ff0001 - 되받아서 체인 전달

순차 이벤트는 keybd_event로 큐에 메시지를 죽 쌓아 놓고 한꺼번에 보내지만 키 입력을 받아 보낼 때는 키보드로 온 이벤트를 즉시 즉시 조작해서 보낸다는 차이점이 있다. 메모장이 받는 결과 이벤트가 중요하므로 이 순서가 다른 것은 별 의미가 없다. 그런데 잘 보면 메모장으로 전달되는 이벤트의 플래그가 다르다.

훅이나 WM_KEYDOWN의 lParam은 bit30에 키의 이전 상태(PrevState)를 전달하는데 이 값이 다르게 나타난다. 순차적으로 보낼 때는 눌렀다 떼는 Down-Up순이라 정상적이지만 키보드 입력을 받아 보낼 때는 Up-Down 순으로 온다. 가령 키보드의 A키를 눌렀다 뗀 경우를 보자.

A down 이벤트 발생

keydb_event(A down) 보내고 메시지는 먹음

A down 다시 받아서 메모장으로. 이때 이 메시지의 PrevState는 Down

A up 이벤트 발생

keydb_event(A up) 보내고 메시지는 먹음

A up 다시 받아서 메모장으로. 이때 이 메시지의 PrevState는 Up

키보드 입력을 받아 변형 후 keybd_event를 보낼 때 이 키의 이전 상태가 Down이었다고 보고된다. 메모장 입장에서는 새로 눌러지는 키이므로 Down을 받아야 하지만 후킹 프로그램에서 이 이벤트를 받을 때 키가 눌러져 있었으므로 keydb_event가 발생시키는 이벤트의 PrevState가 반대로 된다. 이전 상태가 Down이었으므로 지금 받는 키는 Up이라고 생각하는 모양이다. 놓을 때는 반대로 이전 상태가 Up으로 보고된다.

키보드에서 이미 눌러진 것을 되받아 보내는 형식이므로 이대로라면 keybd_event가 생성하는 플래그가 논리적으로는 맞다. 하지만 최종 타겟 윈도우가 이 플래그를 어떻게 해석하는가가 문제이다. 최종 이벤트를 받는 프로그램이 이 플래그를 참조하는가 아닌가에 따라 결과가 달라진다. 워드는 이 값을 보지 않는 것이고 메모장은 보는 것이다. 이 문제에 대한 해결책은 다음 3가지 정도가 있다.

1.키보드로부터 전달된 메시지를 큐에 모아 두었다가 Up이 올 때 keybd_event를 한꺼번에 보낸다. 키를 완전히 놓은 다음에 보내면 이전 상태가 제대로 전달될 것이다. Shift나 Mode, Up 처럼 홀드한 채로 누르는 키가 있어서 적용하기는 힘들 것 같다.

2.다시 받은 메시지의 PrevState 비트를 강제로 뒤집어서 체인으로 보낸다. 체인간에 파라미터 조작이 잘 안되는 듯 하여 기술적인 어려움이 있을 것 같고 무조건 보내는 것도 약간의 부작용이 있을 것 같다.

3.lParam을 직접 생성해서 보낸다. 이론상으로는 가능하지만 keybd_event는 가상키와 스캔, 플래그 등만 전달 가능하므로 lParam을 마음대로 조작하는 것이 가능한지 기술적인 검토를 먼저 해 봐야 한다. keybd_event의 마지막 인수로 보낼 수 있을 듯 하지만 이 인수는 타겟 윈도우가 GetMessageExtraInfo 메서드로 조사만 할 수 있을 뿐 후킹 프로시저까지는 오지 않는 듯하며 lParam과 직접적인 연관이 없다.

이 3가지 방법중에 제일 시도해 볼만한 방법은 2번이다. 이 방법이 가능하려면 훅 프로시저에서 파라미터 조작이 가능해야 한다. 다음 코드로 테스트해 보았다.

if (wParam == 'A') {

wParam = 'B';

lParam = (lParam & 0xff00ffff) | 0x00300000;

}

if (wParam == 'C') {

return 1;

}

A 키를 눌렀을 때 가상 키코드를 B로 바꿔 버리도록 했다. 그러나 이 코드는 제대로 동작하지 않는다. 혹시나 해서 스캔 코드까지 A의 0x1e를 B의 0x30으로 바꿔 봤는데 역시 안된다. 반면 C가 들어 왔을 때 리턴해 버림으로써 메시지를 먹어 버리는 것은 가능하다. 저수준 키보드 후킹을 쓰면 될까 해서 이것도 시도해 봤는데 방식만 다를 뿐 조작은 안된다.

여기까지 코드를 작성해 본 후 나의 후킹 관련 공부가 한참 부족하다는 생각이 들었다. 기본 예제는 다 만들어 봤지만 키보드 입력을 조작하는 예제는 만들어 본 적이 없고 검색을 해 봐도 비슷한 시도를 해 본 사람이 없는 듯 하다. 그래서 하던 작업 잠시 접어 두고 학습을 먼저 하기로 했다. 아는만큼 보이는 법인데 아는 것이 없으니 보이지 않는 것이다. 후킹 관련 자료를 죄다 인쇄해서 차분히 읽어 보았다.

문서 검토 결과 위 코드가 안되는 이유는 대충 짐작이 된다. 키보드 훅 프로시저는 타겟 윈도우가 GetMessage나 PeekMessage로 메시지를 꺼낼 때 호출된다. 이때 훅 프로시저는 wParam과 lParam으로 메시지를 모니터링할 수 있으며 다음 체인으로 보내기 전에 변경도 가능하다. 그러나 타겟 윈도우는 이미 큐에서 메시지를 꺼낸 상태이므로 훅 프로시저로 전달된 파라미터를 조작해 봤자 받을 수 없다. 자신이 큐에서 꺼낸 메시지를 읽을 뿐이다.

훅 프로시저는 메시지를 모니터링할 수 있고 다음 체인으로 보낼 파라미터를 조작할 수 있으며 0이외의 값을 넘겨 다음 체인으로나 타겟 윈도우로 메시지가 전달되지 않도록 할 수 있다. 하지만 타겟 윈도우가 이미 꺼낸 파라미터는 조작할 수 없다. 꼭 바꾸고 싶으면 메시지를 먹어 버리고 keybd_event로 새 이벤트를 발생시켜야 한다. 이론이 이러하므로 lParam의 PrevState를 인위적으로 조작하는 방법도 결국 쓸 수 없다.

이왕 공부를 한 김에 저수준 키보드 후킹도 연구해 보았다. 한번도 사용해 본 적이 없는데 저수준이라고 하니 고수준보다는 조작할 수 있는 범위가 더 넓지 않을까 기대된다. 문서상으로 저수준과 고수준의 차이가 명확히 기술되어 있지는 않은데 대충 정리해 보면 다음과 같은 차이점이 있는 것 같다.

-고수준 훅 프로시저는 메시지를 꺼낼때 호출되는 반면 저수준 훅 프로시저는 키보드 메시지를 큐에 붙일 때 호출된다.

- 고수준은 타겟이 꺼낸 메시지를 들여다 봐야 하므로 반드시 타겟 프로세스의 주소 공간에서 실행되어야 하지만 저수준은 시스템 메시지 큐에 넣을 메시지를 보므로 그럴 필요가 없다. DLL이 타겟 프로세스에 주입되지 않으며 대신 컨텍스트 스위칭만 잠시 발생한다.

-고수준은 지역 훅이 가능하지만 저수준은 원칙적으로 전역 훅만 가능하다.

-저수준은 DLL로 분리하지 않더라도 전역 후킹이 가능하다.

-고수준은 keybd_event로 발생시킨 이벤트와 키보드로부터 발생한 이벤트를 구분할 수 없지만 저수준은 플래그에 LLKHF_INJECTED 비트를 세트하여 인위적인 메시지인지를 구분할 수 있다.

-wParam, lParam으로 전달되는 정보가 다르다. 저수준은 wParam으로 메시지의 종류가 오고 lParam에는 가상키, 스캔 코드, 플래그, 시간, 여분 정보 등을 멤버로 가진 구조체가 온다.

두 방법 모두 모니터링만 가능하며 파라미터를 조작하는 것은 안되는 듯 하다. 저수준이라고 해 봤자 큐에 들어가기 전에 본다는 것 뿐이지 그다지 수준이 낮은 것은 아니다. 문서 검토를 마친 후 테스트 예제에 저수준 후킹을 해 보았다. 인젝트된 이벤트인지를 구분하는 플래그가 따로 있으므로 F24를 끼워 넣거나 스캔 코드를 조작하는 코드를 쓰지 않아도 재귀 호출을 막을 수 있었다.

그리고 PrevState 비트가 아예 없으므로 앞에서 문제가 되었던 이중 삽입이 발생하지 않아 애초에 목표했던 문제는 해결하였다. 그러나 산넘어 산이라고 또 다른 문제가 발생했다. 고수준은 타겟 프로세스의 주소 공간에서 실행되므로 타겟 윈도우의 모드를 자유롭게 전환할 수 있지만 저수준은 그렇지 않으므로 입력 모드를 변경할 수 없다. 한영 전환이 안된다.

여기까지 작업한 후 체력이 고갈되어 버렸다. 문제를 풀어도 자꾸 문제가 새로 나타나니 실제 프로젝트에 적용할 엄두가 나지 않는다. 이럴 때는 닥치고 쉬는거다.

12년 6월 23일

몇일째 후킹 코드 작성하느라 고군분투하고 있다. 개발자가 코드를 작성하는 것만큼 재미있는 일이 없지만 이런 작업은 정말 어렵다. 내부 동작도 정확히 모르고 디버깅도 안되고, 어디 물어볼 데도 없고 그냥 맨땅에 헤딩하는 수밖에 없다. 사소한 작업 일지이지만 요약적으로나마 정리하기로 한다.

■ 코드부터 정리했다. 저수준, 고수준이 섞여 있는 상태이고 이것 저것 시도를 많이 해 보다 보니 극도로 지저분해져 있다. 함수명부터 직관적으로 정리하고 불필요한 코드는 과감하게 삭제했다.

■ 저수준에서 모드 변환 문제도 여러 가지 방법이 있을 듯하다. 화면 키보드는 임의의 윈도우에 대해 입력 모드를 바꾸므로 분명히 임의 윈도우의 입력 모드를 조작하는 것이 가능할 것이다. 그러나 그 방법은 아직 알지 못하므로 다른 방법을 시도해 보았다. 입력 모드를 바꿀 필요없이 그냥 VK_HANGUL 가상키에 대한 이벤트를 발생시켜 "니가 알아서 바꿔라" 라고 명령하는 것이다. 예상했던 대로 이 코드는 잘 동작한다.

그러나 아너림과 맞지 않는 또 다른 문제가 발생했다. 아너림은 Mode키를 눌러 한영을 토글하지만 그 외에도 숫자, 기호 등의 모드가 더 있어서 토글보다는 현 상태에 맞게 절대적인 모드 지정을 해야 한다. 그러나 VK_HANGUL은 토글만 가능할 뿐 특정 모드로 바꾸라는 명령을 내릴 수 없다는 점이 문제다. 무조건 한글로, 무조건 영어로 지정할 수 없고 현재 상태를 반대로 뒤집을 수만 있을 뿐이다. 주소 공간이 분리되어 있으니 현재 모드를 조사할 수도 없다.

CBT훅에서 포커스가 바뀔 때마다 타겟의 모드를 새로 조사하여 동기화를 하고는 있다. 그러나 포커스가 바뀔 때만 동기화할 뿐이며 새로 생성되는 윈도우의 모드는 조사하지 않는다. 그러다 보니 일시적으로 타겟과 훅커의 모드가 불일치하는 현상이 발생한다. 예를 들어 메모장을 영어 모드로 두고 워드를 띄우면 워드는 한글 모드로 시작하지만 후커는 여전히 영문 모드이다.

이 상태에서 VK_HANGUL을 보내면 후커는 한글로 바뀌고 워드는 영어로 바뀌어 계속 불일치한 상태가 된다. 포커스를 다른 프로그램으로 가져 갔다가 워드로 다시 가져 오면 CBT 훅에 의해 동기화된다. 이 문제를 해결하기 위해 CBT의 HCBT_CREATEWND에 대해 스레드를 생성하고 1초후에 모드를 동기화했다. 좀 어설프기는 하지만 생성되는 윈도우에 대해서 일단 동기화가 되니 불일치는 많이 해소되었다.

■ 새로 만든 윈도우의 모드를 조사하는 부분에서 버그 발생. CBT가 모드 알림 -> 훅은 모드 동기화를 위해 VK_HANGUL을 다시 보냄 -> 타겟의 모드가 반대로 바뀜. 결국 재귀 변경의 문제이다. ChangeMode에 내가 모드를 바꾸는 것인지, 훅에 의해 모드를 동기화하는 것인지를 구분하는 인수를 두어 문제 해결

■ IME를 동기화한 후 그럭 저럭 쓸만한 수준까지 후킹이 잘 되며 메모장, 워드 할 것없이 일관되게 동작한다. 그러나 부정기적으로 다운되는 심각한 문제가 발생했다. 더 골치아픈 것은 운영체제가 뻗어 버리기 때문에 왜 죽는지, 어디서 죽는지를 도무지 알 수 없다는 것이다. 디버깅은 시작하자 마자 VS가 다운되므로 시도할 수도 없다. 후킹은 역시 개발하기 참 어렵다. 텍스트 디버깅에 의지하여 수없이 로그를 찍어 본 결과 어렵게 원인을 발견했다.

다운되는 이유는 WM_KEYDOWN과 훅 프로시저의 파라미터 차이에 의해서이다. 두 경로로 전달된 키 메시지를 ProcessKey 함수로 전달하여 처리하는데 고수준 후킹은 WM_KEYDOWN과 마찬가지로 wParam으로 가상키 코드를 전달하지만 저수준은 lParam의 구조체로 전달하는 차이점이 있다. 두 경우를 조건문으로 철저하게 구분하고 있지만 일부 누락된 부분에서 문제가 발생한 것이다. 문제가 될만한 부분을 모두 수정하여 안정성을 높였다.

워드, 메모장 등에서 모두 제대로 동작한다. 그러나 특정 프로그램에서는 여전히 다운되는 문제가 발생한다. 원인 분석 결과 시작할 때 후킹 프로시저로 WM_KEYUP이 하나 날라 오는데 이 코드에 대해 OnKeyUp을 호출하면 파라미터 차이로 인해 엉뚱한 메모리를 건드려 다운된다. 특정 프로그램에서 이 코드가 왜 날라오는지는 이유를 파악하기가 참 어렵다. 그냥 조건문으로 막기만 할 뿐이다.

자꾸 이런 문제가 발생하는 근본적인 이유는 한 프로그램에 후킹 하지 않을 때, 저수준 후킹, 고수준 후킹 코드가 혼재하기 때문이다. 차후 근본적으로는 연습 프로그램과 후킹 프로그램을 분리해야 문제가 깔끔하게 해결될 것이다. 지금은 이 작업을 할 시점이 아니다. 그냥 발견되는대로 해결하고 원인을 파악하여 공부를 해 놓는 수밖에 없다.

■ 후킹 상태에서 연습 프로그램으로 키 입력이 전달되면 무조건 무시해 버리도록 하였다. 연습 프로그램은 고유의 오토마타 논리를 가지고 있으므로 후킹 로직과는 충돌이 발생하여 후킹의 예외로 둘 수 밖에 없다.

■ 후킹 안내 메시지가 너무 썰렁하여 좀 더 상세하게 기술하였다. 모든 메시지를 타겟으로 전달한다는 안내를 달았다.

■ Cap 키에 의해 대문자 입력이 안되는 문제 수정. Cap키 처리를 ProcessEnglish로 옮겼는데 처리 후 Cap을 다시 리셋해 버려서 그럼. 코드 정리하다 괜히 잘못 건드린 예이다.

■ Shift키를 누른 채로 이동시 선택이 안되는 문제 발생. 수정했더니 한칸 올렸을 때 동작하지 않는 또 다른 문제 발생. 이유는 VK_SHIFT와 VK_LSHIFT, VK_RSHIFT의 차이로 인해 발생한 것이다. WM_KEYDOWN은 어떤 키를 누르나 VK_SHIFT로 오지만 훅은 좌우 키를 구분하여 가상키를 보낸다. 참 이상한 구조다. 키맵에는 왼쪽 기준으로 작성해 놓고 오른쪽 조합키는 무조건 왼쪽으로 바꿔 버리고 WM_KEYDOWN에는 좌우 구분없이 VK_SHIFT로 통일하여 문제 해결. Ctrl, Alt도 마찬가지이며 Win의 경우는 애초에 좌우 가상키만 있고 통합 가상키는 정의되어 있지 않다.

■ 올림 상태일 때 CSAW 조합키도 엄지 좌우로 배치하였다. 일반 문자키를 조합키에 맵핑했는데 우려와 달리 너무 잘 동작한다. 조합키라고 해서 키보드 자체가 특별한 처리를 하는 것은 아니고 다 소프트웨어가 처리하는 것이라 맵핑만 바꾸면 문제가 없다.

■ 후킹은 시스템 저수준 작업이라 테스트가 굉장히 어렵다. 텍스트 디버깅이 아니면 도저히 문제를 발견할 방법이 없다. 그래서 텍스트 디버깅을 최종 버전에까지 유지하기로 했다. 로그 파일을 루트에 생성했는데 실행 파일과 같은 폴더에 생성하여 루트를 더럽히지 않도록 했다.

■ 편집키에 대한 후킹 코드 정리. 거의 모든 편집키도 후킹하였다. 특별히 어려운 부분은 없었으나 코드를 조직화하는데 시간이 많이 걸렸다. 의도한 모든 편집키가 후킹되는데 VK_SLEEP만 안된다. 이 가상키는 코드만 보낸다고 해서 동작하는 것은 아니며 뭔가 조건이 더 필요하다. 특권을 줘 봤는데 그래도 안된다. 더 연구해 볼 것

■ 펑션키에 대한 후킹 지원. F1~F12까지의 펑션키는 물론이고 펑션 모드의 펑션키도 똑같이 동작한다. 멀티미디어 볼륨 조정, 웹 브라우저 새로 고침 같은 기능들도 훌륭하게 동작한다.

■ 조합키에 대한 후킹 지원. 다른 기능에 비해 이 기능이 어려운 이유는 모드에 상관없이 무조건 영문 가상키를 보내야 한다는 것이다. Ctrl + ㄱ 같은 조합키는 없으므로 눌러진 키의 영문 맵핑을 찾아 적용해야 한다. Ctrl + O로 파일을 열 수 있고 Ctrl + Shift + F3 같은 복잡한 단축키도 사용 가능하다. Win + D로 데스크탑으로 전환하는 기능까지도 된다. 이 정도면 이제 실제 사용할만한 수준이 된 것이라 생각된다.

■ 조합키 지원 후에 잘 되던 Shift + 이동으로 방향 선택하는 코드가 동작을 정지하고 파업해 버림. 원인 분석 결과 CASW가 눌러진 상태에서는 조합키 모드로 동작하는데 편집, 펑션에 대해서는 예외를 적용해야 한다. 편집 모드에서 Shift + Left는 영문 맵핑이 아니라 Left를 그대로 적용하도록 했다.

12년 6월 24일

■ 조합키들은 누르는 즉시로 어떤 동작을 하지는 않으며 반드시 다른 키와 함께 사용된다. 그래서 조합키의 상태는 배열에 저장만 할 뿐 타겟으로 보내지 않았다. 그런데 Ctrl과 Shift는 이것이 맞지만 Alt와 Win은 그렇지 않다. Alt는 단독으로 누를 때 메뉴를 여는 기능이 있고 Win은 시작 메뉴를 연다. 두 키는 타겟으로 이벤트를 보내 해당 명령을 수행하도록 했다.

■ 조합키는 항상 영문자를 기준으로 하며 한글에 대해서는 동작하지 않는다. Ctrl + ㄱ 이런 조합키는 쿼티 키보드에도 없다. 그래서 항상 눌러진 키의 영문 가상키를 읽어 타겟으로 보냈는데 한글의 경우는 이것이 맞지만 숫자의 경우는 쿼티 키보드에도 별도키가 있으므로 Ctrl + 1이 가능해야 한다. 또 자주는 아니지만 Ctrl + [ 같은 조합키를 사용하는 프로그램도 간혹 있다.

조합키는 기본적으로 가상키를 누르는 것이므로 모드에 상관없이 눌러진 키를 보내는 것이 맞다. 하지만 숫자나 기호의 경우는 쿼티 키보드에 키가 있으므로 모드를 고려하여 보내야 한다. 아너림 키보드만의 입장에서 본다면 사실 숫자키가 따로 없으므로 숫자 조합키는 맞지 않고 그런 면에서 보면 JQXZ 알파벳키도 조합키를 발생시킬 수 없어야 옳다. 그러나 쿼티 키보드 기준의 소프트웨어와 호환성을 확보하기 위해서는 꼭 필요하다.

그렇다면 모든 문자에 대해 조합키가 가능해야 하느냐 하면 그것도 아니다. 쿼티 키보드에도 Ctrl + ! 같은 조합키는 없다. 조합키는 문자가 아닌 키 기준이므로 Shift 상태의 문자에는 해당되지 않으면 알파벳의 대소 구분도 없다. 그러나 아너림은 각 문자가 따로 정의되어 있어 Ctrl + @ 같은 조합키도 생성 가능하다. 현재까지 나온 어떤 프로그램도 이런 조합키를 요구하지 않으므로 쿼티의 대응되는 키를 찾아 보내야 한다.

■ Shift키와 문자키는 단독으로는 조합키가 될 수 없다. Shift + A는 쿼티에서 대문자 A를 입력하라는 뜻이지 조합키가 아니다. 다만 Ctrl + Shift + A 식으로 Ctrl이나 Alt와 같이 조합되면 이때는 조합키가 된다. 현재 코드에서는 Shift + A 도 조합키로 인식하여 대문자 A가 나오는데 이는 맞지 않다. 아너림에서 Shift는 대소문자 선택용으로 사용하지 않으며 오로지 조합키 입력용으로만 사용된다.

상기의 문제들을 해결하기 위해 조합키 입력 방식을 새로 작성했다. 조합키를 일괄 처리하지 않고 각 모드별로 처리하되 한글은 영문으로 처리를 넘긴다. 조합키인가를 점검하는 조건에서 Shift 단독으로 누른 것은 제외했다. 숫자, 기호는 대응되는 쿼티 가상키를 찾아 보내되 Shift에 정의된 문자는 Normal 키의 가상키를 찾아 보낸다. 편집, 펑션은 또 다른 논리를 사용하는데 Shift키 단독으로 누른 것도 조합키로 인정한다. 그래야 Shift + F3, Shift + Left 같은 입력이 가능하다.

■ 여기까지 작성한 후 테스트해 보니 일반적인 작업에는 큰 무리가 없는 듯 하다. 그러나 조합키 입력에 또 다른 애매한 점이 있는데 Ctrl + Z를 입력하려면 영문 Up 상태로 가야 한다. 그기까지는 좋은데 Ctrl + Z를 입력한 후 Up이 풀려 버리므로 두번 취소하려면 Up Lock을 걸거나 아니면 계속 Up키를 사이 사이에 눌러 주어야 한다. 조합키 입력중에는 Up을 풀지 않는 것이 맞을 것 같다. 그러나 Ctrl + X를 생각해 보면 또 그게 아니다. 잘라낸 후 바로 붙여 넣을 것이므로 Up이 원래대로 복귀하는 것이 맞다. 이 문제는 참 애매해서 어찌할지 결정하기가 무척 어렵다. 일단은 그대로 두자.

■ 후킹이 완벽하지는 않지만 테스트 가능한 수준에 이르른 것 같다. 이제 시제품 제작을 위해 배치에 다시 신경을 좀 쓰기로 한다. 영문과 마찬가지로 한글도 Up 상태에 있는 경음들을 여분키에 배치했다. 어차피 남는 키이니 중복 배치해 놓고 테스트해 보기 위해서이다. 영문의 경우 xjqz의 총 빈도는 0.46%이지만 한글의 경음 빈도는 모두 0.8%이다. 얼마 안되는 것 같지만 분당 600타를 칠 때 대략 10초에 한번꼴로 눌러야 한다는 계산이 나오는 셈이다.

이렇게 배치해 놓고 연습을 해 보니 제자리가 훨씬 더 좋다는 느낌이 들었다. 집게 손가락이 자리를 벗어나 키를 누르는 것보다 엄지로 Up을 누르고 상단의 키를 누르는 것이 훨씬 더 빠르고 직관적이다. 제자리 투터치냐, 벗어난 원터치냐의 문제인데 암만 생각해 봐도 제자리 투터치가 더 나은 것 같다. 물론 실물 키보드에서 테스트해 봐야 어떤 쪽이 더 편리한지 정확하게 조사할 수 있을 것이다.

■ 후킹을 원활하게 테스트하려면 후킹 옵션을 자주 켰다 껏다 해야 한다. 이 명령이 메뉴에 있고 단축키도 정의되어 있지 않아 무척이나 불편하다. 그래서 좀 더 편리하게 옵션을 토글하기 위해 연습 프로그램에 툴 바를 달았다. 후킹 및 레벨 등을 툴바로 배치하고 단축키는 모두 제거했다.

비트맵이 좀 꾸질 꾸질하지만 테스트하기는 훨씬 더 편해졌다. Win32 툴바 정도야 쉽게 만들 수 있는 것이지만 너무 오랜만에 하다 보니 이것도 무진장 헷갈리고 할 일이 많다. 비트맵 만들고 상태 관리를 위해 OnIdle도 작성해야했다. 툴바가 들어감으로써 전체적인 레이아웃도 상당히 많이 바뀌었다. 다행히 윈도우즈 API 정복이라는 좋은 책이 있어 한나절만에 깔끔하게 달았다.

■ 테스트 하다 보니 후킹을 껐다 켰다 하는 경우가 아주 많은데 지금은 툴바의 버튼으로만 조정할 수 있어 테스트하기가 무척 까다롭다. 그래서 전역 단축키를 하나 만들고 신속하게 토글하면 어떨까 생각해 봤다. 그런데 마땅히 배정할 단축키가 없다는 게 문제다. 또 후킹이 완벽해지면 전환 빈도가 떨어질 것이고 토글 단축키가 있다는 것 자체가 후킹의 불완전성을 자인하는 꼴이라 하지 않기로 했다. 그나마 툴바에 버튼이 있는 것만해도 많이 편해진 것이다.

■ 구두점 중 마침표만 노말 위치에 와 있고 나머지 3개는 Up 위치에 있는데 이것이 무척 생뚱맞아 보인다. 그래서 구두점 하나를 더 가져오고 같은 키의 Up 위치에 나머지를 배치하는 방법을 생각해 보았다. 마침표와 쉼표를 한 키에 두고 따옴표와 홑따옴표를 한 키에 놓는다. 마침표는 약지 자리를 계속 지키고 따옴표는 오른손 중지 자리에 나란히 옆에 놓는다.

이렇게 되면 문자 위치 하나가 부족해지므로 하나씩 Up 위치로 이동해야 한다. 한글의 경우는 ㅆ을 왼손의 ㅅ 위에 놓는것이 가장 합리적이다. ㅆ보다 격음들의 빈도가 더 떨어지지만 ㅅ위에는 ㅆ이 제자리이고 직관적이기 때문이다. 영문은 노말 위치에서 가장 빈도가 낮은 k를 올리고 Up 위치에 5문자를 좀 더 접근하기 쉬운 곳에 배치한다. Up으로 이동하는 글자와 구두점들의 빈도는 다음과 같다.

문자	한글 모드	영문 모드
ㅆ	1.35
k		0.53
.	1.17	3.17
,	0.35	0.88
"	0.35	0.38
.	0.05	0.28

도표에서 보다시피 빈도상으로는 이 배치가 맞지 않다. ㅆ은 모든 구두점보다 빈도가 높고 노말 위치의 "와는 비교가 되지 않는 정도여서 Up으로 보내기가 상당히 아쉽다. 다른 경음인 ㄲ, ㄸ은 근소하게나마 "보다 빈도가 낮아 상관이 없다. 영문의 경우는 Up 위치로 올라가는 k가 쉼표보다는 낮고 따옴표보다는 약간 더 높아 빈도상의 문제는 별로 없되 알파벳 하나가 노말 위치에서 사라진다는 느낌상의 문제가 크다.

배치를 바꿔 볼까 말까는 한참 더 고민해 봐야할 문제이되 지금은 시도를 하고 있는 중이므로 일단 바꿔 보기로 했다. 테스트해 보고 아니다 싶으면 그냥 롤백하면 된다. 키맵을 대대적으로 다시 뜯어 고쳤다. 키맵 외에 한글 입력 오토마타도 약간 수정했는데 마침표에 대한 예외적인 처리를 1바이트 문자 전체로 확대했다. 한글 배치는 다음과 같다.

여분키 때문에 솔직히 좀 지저분해 보이는 경향이 있다. 이 상태로 테스트해 보니 역시 ㅆ을 입력하기가 조금 번거로운 감이 있다. 따옴표의 빈도가 그리 높지 않아 편의성이 오히려 감소한 느낌이다. 영문 배치는 다음과 같다.

" 키가 새로 들어오고 w는 b 자리로, b는 k자리로 이동했다. k는 Up 위치로 옮기되 가장 접근하기 좋은 곳에 두었다. 여분키도 빈도에 따라 조정했다. 테스트해 보니 wh와 by가 서로 인접해 있어서 연속으로 누르기가 편리해졌다. k가 올라간 것이 큰 문제이지만 장단점이 있는 것 같다.

이 배치가 완전히 마음에 들지는 않는다. 하지만 구두점 4개의 자리가 확정됨으로써 다른 언어를 위해 많은 여유키를 확보했다는 의미가 있다. 물론 구두점을 어디다 둘 것인가는 각 언어 자판에서 알아서 변경할 수 있다. 만약 구두점보다 훨씬 더 빈도가 높은 음소가 있다면 노말 위치에 음소를 두고 구두점 4개는 모두 Up 자리로 옮기면 된다.

당분간은 이 배치 상태로 테스트를 진행해 보기로 한다. 배치야 앞으로도 계속 바뀔 수 있는 부분이므로 다양하게 시도해 보도록 하자. 빈도가 높은 글자들의 위치는 여전히 원래 자리를 고수하고 있으므로 크게 헷갈리지도 않는다.

■ 새로 배치한 자판을 연습하던 중 따옴표의 위치가 마음에 안 들기 시작했다. 구두점 키 2개는 거의 문자와 같은 빈도를 보이므로 문자키에 배치되어 있되 중간에 배치되어 있어 뭔가 끼어들었다는 느낌이 든다. 구두점 키 2개를 오른쪽 끝에 모으면 훨씬 더 보기에도 좋고 쓰기에도 직관적이지 않을까? 게다가 원래 쿼티 자판의 따옴표는 한칸 벗어난 새끼 손가락 자리여서 호환성에도 유리하다. 문제는 빈도인데 따옴표와 교환될 문자의 빈도는 다음과 같다.

한글 : 따옴표(0.35), ㅋ(0.18)

영문 : 따옴표(0.38), v(0.67)

한글의 경우는 ㅋ보다 따옴표 빈도가 2배나 더 높아 빈도상 불리하다. 그러나 영문의 경우는 v가 따옴표보다 2배 이상 빈도가 높아 적절하다. 이 정도면 바꿔볼만한 충분한 이유가 된다. 그래서 또 바꿨다.

■ 마침표가 노말 위치에 있는 것은 당연하다. 그런데 따옴표가 노말 위치에 있는 것은 과연 적절한가 하는 생각이 들었다. 마침표 Up 자리의 콤마와 따옴표의 빈도를 비교해 보았다.

한글 : 콤마(0.35), 따옴표(0.35)

영문 : 콤마(0.38), 따옴표(0.88)

한글의 경우는 두 기호의 빈도가 같아 어떻게 배치해도 상관없다. 그러나 영문의 경우는 따옴표보다 마침표의 빈도가 2배 이상 더 높다. 이렇게 되면 콤마를 아래로 내리고 따옴표를 위로 올리는 것이 맞다. 키맵을 다시 조정했다.

마침표와 콤마가 나란히 있고 그 위에 따옴표와 홈따옴표를 배치했다. 쿼티에서는 콤마가 마침표 왼쪽에 있는데 아너림은 오른쪽에 있어 다소 헷갈릴만한 배치이다.

■ 배치가 전반적으로 수정됨으로 해서 또 다시 Mode키와 Up키의 위치가 고민되기 시작했다. ㅆ과 k가 Up 위치로 이동함으로써 Up의 빈도가 더 높아진 것처럼 보인다. 사실은 .과 ,가 아래로 내려와서 별 차이가 없지만 심리적으로 Up키를 더 많이 눌러야 하는 것처럼 느껴지며 Up에 알파벳 5글자나 배치되어 있다는 것은 상당한 거부감을 일으킨다.

또한 한영 전환은 나같은 개발자나 많이 사용하지 일반적인 사용자들은 그다지 많이 사용하지 않으며 미국 사람이나 유럽 사람에게는 거의 쓸 일이 없는 키이다. 국제화를 고려하면 빈도가 떨어지는 Mode보다는 Up이 엄지의 홈 포지션에 있는 것이 합당하다. 현재 이 두 키의 동작은 다음과 같이 정의되어 있다.

	푸시	홀드	더블
Mode	언어 순환	숫자 임시	숫자 고정
Up	Up 전환(자동 복귀)	편집 임시	Up 고정

두 키의 위치를 바꾸게 되면 홀드시의 기능도 같이 바꿔야 한다. 숫자를 입력하기 위해 Mode키로 손이 옮겨지면 불편하기 때문이다. 그러나 이렇게 될 경우 숫자 임시는 Up 홀드이고 숫자 고정은 Mode 더블이어서 뭔가 불일치가 발생하며 직관적이지 못하다.

전에도 이 문제를 고민한 적이 있는데 일단 바꿔 보기로 한다. 코드는 모두 작성되어 있으므로 바꾸는데는 그리 오랜 시간이 걸리지 않는다. 키맵의 두 키 위치를 바꾸고 홀드시 적용할 임시 모드를 조정하고 타이머에서 보여줄 키보드만 바꿔 주면 깔끔하게 수정된다.

지금까지 연습했던 습관을 바꿔야 하는 것이 좀 곤란한데 어차피 아직 완전히 익숙해지지 않은 상태이므로 감수할 수밖에 없다. 이 배치 변화에 대해서는 사실 확신이 서지 않는다. 실물 키보드 만들어 보고 다시 재고해볼 예정이다.

■ 안드로이드 버전도 동기화시켰다. 키맵만 수정하면 되므로 시간은 오래 걸리지 않는다. 배치 수정하고 Mode와 Up도 홀드 기능이 없기 때문에 위치만 바꾸면 된다. Up + Sym으로 이모티콘 모드로 바꾼 후에 다시 Mode 버튼을 누르면 이전 상태가 저장되어 있지 않아 Null Pointer 예외가 발생하는 문제를 확인하여 수정하였다. 키 배치 상태는 다음과 같다.

PC 버전과 배치는 같되 여분키가 없어 훨씬 더 시원스러워 보인다. 이클립스는 코드를 잘라내서 붙여 넣으면 넣는 곳의 문법에 맞게 인덴트를 조정해 주며 괄호를 열면 닫는 괄호도 자동으로 입력해 준다. 이 서비스에 익숙해 있다가 비주얼 스튜디오를 쓰면 그런게 없어 무척 짜증이 난다.

그런데 비주얼 스튜디오를 쓰다가 다시 이클립스를 쓰면 쓸데 없는 서비스를 해 주는 게 더 짜증난다. { 를 치면 }가 자동으로 입력되고 나는 습관적으로 }를 입력하므로 에러가 나는 것이다. 이런 예를 보면 사람이 습관에 얼마나 무섭게 길들여지는지를 알 수 있다. 둘 다 좋은 개발툴이라 어떤 것이 절대적으로 더 좋다고 단언할 수 없다. 키보드도 마찬가지가 아닐까?

12년 6월 25일

아직 잔버그들이 굉장히 많다. 연습하면서 벌레가 보이는 족족 잡고 있다. 다행히 큰 버그는 많지 않고 모두 간단한 것들이다.

■ 올림 상태에서 Alt,Win 키가 안되는 사소한 버그가 있어서 수정했다. 키맵에서 맵핑된 vk를 잘못 보냈음.

■ Up 홀드 상태에서 스페이스는 숫자 0을 입력해야 하는데 공백으로 잘못 입력된다. Up과 Mode를 바꾸면서 한 군데를 수정하지 않아 생긴 버그이다.

■ Mode + Enter키를 누르면 편집 모드로 고정하는 기능이 있었는데 키를 바꾸면서 잠시 기능이 정지되었다. 다시 복원시킴

■ 편집 모드의 R 조합키(VK_RCONTROL) 등을 누르면 조합키의 상태가 풀리지 않는 버그가 발견되었다. 조합키들은 보통 누를 때 기능이 동작하므로 누르는 처리만 되어 있는데 그러다 보니 R 조합키가 풀리지 않아 이후부터 타겟은 이 키들이 계속 눌러져 있는 것으로 오인하여 엉뚱한 동작을 한다. 그리고 조합키를 다른 조합키와 같이 누른다는 것도 말이 안되므로 이 키들은 조합키를 무시하고 단독으로 누르도록 했다.

아너림은 조합키가 1개씩밖에 없으며 좌우를 구분하지 않는다. 그래서 키맵의 모든 조합키는 왼쪽을 기준으로 작성되어 있다. 그러나 오른쪽 조합키도 굳이 누르려면 누를 수 있어야 한다. 버추얼 PC 같은 프로그램이 오른쪽 Alt키로 호스트 OS로 나오는 기능을 제공하기 때문이다. 그래서 편집 모드에 이 키들이 배치되었는데 뜻하지 않게 문제를 일으키고 있다.

그리고 이왕 작업하는 김에 모든 편집키에 대해서도 키업 메시지를 타겟으로 보내도록 하였다. 누를 때만 동작하므로 누르는 키만 보냈으려 그렇게 해도 별다른 부작용은 없는 것 같다. 하지만 원칙대로 누른 키는 풀어주는 것이 맞으므로 이벤트를 발생시켰다. 이 코드가 들어가나 마나 별다른 차이점은 없는 것 같다.

■ 키가 많아지다보니 자연적으로 축소된 형태로 그리는데 그러다 보니 키의 캡션이나 PC 맵핑된 키가 너무 작아 잘 보이지 않는다. 키의 캡션 폰트를 좀 더 크게 하고 맵핑키에 대한 설명도 좀 더 키웠다.

훨씬 더 보기 시원스러워졌다. 70%로 축소해 볼까도 생각해 봤는데 옵션에서 사용자가 직접 할 수도 있으니 그냥 두기로 했다.

■ 왼손 엄지의 키 맵핑이 현재 3,4,5로 되어 있는데 이 위치는 그냥 엄지 위치와 대충 비슷해서 선정한 것이다. 그러나 사실 엄지로 이 키를 누를 수도 있고 집게나 약지를 사용하게 된다. 그럴 바에야 중간에 두지 말고 1,2,3으로 왼쪽에 몰아 놓는게 나을 것 같다. 중간에 두니 오히려 더 헷갈린다. 그리고 왼쪽의 확장키는 현재 맵핑도 되어 있지 않은데 숫자 4~9까지 차례대로 맵핑을 해 주었다.

차후 시제품을 만들려면 어차피 맵핑된 키는 필요하므로 지금 확정하는 것이 나을 것 같다. 여분키는 이후 매크로로 사용할까 생각중이다.

■ 영문 대문자 상태에서 왼손 3열의 문자가 엉뚱하게 입력되는 버그 수정. 후킹 상태에서 키보드 올림 상태이면 BYUG를 차례대로 누를때 BUG가 입력된다. Y가 U로 바뀌고 U는 아예 나오지 않는 것이다. 출력 메시지 자체가 bug임을 잘 보여주는 희한한 예이다. 조사 결과 코드에는 문제가 없고 후킹시 보낼 가상키 테이블에 Y에 대한 가상키가 U로 잘못 입력된 오타였다.

■ 0.95 버전 기준으로 설명서를 다시 작성했다. 워낙 자주 바뀌니 설명서도 이번에 대판 바꾸었다. 모든 캡처를 다시 잡았고 키 개수도 변화가 생겼으며 모드를 바꾸는 방법도 많이 바뀌었다. 새로 들어간 여분키에 대해서도 상세한 설명을 달아 두었다.

■ 여기까지 작업한 버전을 0.95로 릴리즈한다. 아직 문제가 많고 더 손델 부분이 있다는 것은 알지만 후킹이라는 큰 기능이 들어 갔고 소스도 보관용으로 백업할 필요가 있으며 변화 과정을 기록하기 위해서라도 지금이 릴리즈해야 할 시점인 듯 하다. 대략 1시간 정도 테스트해 봤는데 U와 Y가 바뀌는 버그 외에는 다른 큰 문제가 없는 듯하다.

12년 6월 29일

■ 0.95 버전은 후킹 기능 작성을 위해 코드의 복잡도가 증가하였다. 뿐만 아니라 후킹안 할 경우, 저수준 후킹, 고수준 후킹이 섞여 있어 함수 구조도 지저분하다. 이제 0.95 릴리즈했고 소스 백업까지 해 두었으므로 사용하지 않는 고수준 코드는 걷어 내고 코드를 정리하기로 한다. 후킹 DLL 코드를 정리하던중 아찔한 코드를 보았다.

LRESULT CALLBACK KeyHookProcLL(int nCode, WPARAM wParam, LPARAM lParam)

{

LRESULT Ret;

if (nCode >= 0) {

Ret=SendMessage(hWndAnerim,WM_USER+1,wParam, lParam);

if (Ret == 0) {

return 1;

}

}

return CallNextHookEx(hKeyHook,nCode,wParam,lParam);

}

저수준 훅 프로시저인데 CallNextHook을 호출할 때는 고수준의 훅 체인으로 넘기고 있는 것이다. 이대로라면 다음 체인으로 전혀 넘어가지 않았을텐데 계속 동작한 것이 의아하다. hKeyHookLL로 수정한 후 테스트해 보니 별 이상없이 잘 동작한다. 저수준 후킹시에는 고수준 후킹은 아예 설치하지 않으므로 hKeyHook은 NULL이었던 셈이다.

그래도 이상없이 동작한 이유는 다음 체인으로만 넘기지 않을 뿐 타겟 윈도우로는 메시지가 제대로 전달되었기 때문이다. 만약 시스템에 키보드 훅 프로그램이 하나만 더 깔려 있었더라면 그 프로그램은 제대로 동작하지 않았을 것이다. 이런 어처구니없는 실수를 하고도 프로그램이 돌아갔던 것이 신기하다.

연습 프로그램의 코드도 대폭 수정하여 고수준 후킹 관련 코드를 모두 삭제했다. 훅 방법을 지정하는 변수도 필요없고 IME 모드 변경을 위해 리턴값을 조립하던 코드도 필요없어졌다. 키 이벤트를 발생시키는 함수 세트도 정리했다. 리팩토링만 한 것이므로 동작은 이전과 전혀 다를 것이 없다.

■ 연습 프로그램은 키맵과 후킹중 보낼 가상키를 찾기 위해 다량의 테이블을 참조하는데 이 테이블을 검색할 때 항상 순차 검색을 사용한다. 후킹에 의해 시스템 전반적인 속도가 느려지는데다 가장 느린 검색 알고리즘을 사용하여 더 느리다. 효율성 제고를 위해 최소한 이분 검색 정도는 도입하는 것이 바람직하다.

그러나 막상 이 작업을 할려고 생각했다가 그만 두었다. 순차 검색은 가장 느리지만 또 가장 확실하고 부작용이 없는 검색 방법이다. 키입력은 어차피 느려터진 사용자가 하므로 그다지 빠를 필요도 없고 괜히 최적화한다고 손 댔다가는 불필요한 버그만 양산될 것 같다. 게다가 개발 초기로 앞으로 어떻게 바뀔지 모르니 지금은 이대로 가는 것이 나을 것 같다. 차후에는 꼭 최적화를 해야 하는 부분이다.

■ 고수준 후킹 코드는 모두 삭제했지만 아직도 연습 프로그램에는 직접 키 입력을 받을 때와 후킹할 때의 코드가 뒤섞여 있어 불안정하다. 양쪽의 파라미터 구조 차이를 조건문만으로 구별하기에는 근본적인 한계가 있다. 현재 연습 프로그램이 훅을 거느리고 있는 상황인데 장기적으로 다음과 같이 바꿀 생각이다.

AnerimHook.dll : 이 프로그램이 메인이 되며 여기서 모든 키 입력을 받아 아너림 방식으로 바꾸어 타겟으로 전달한다. 키맵이나 오토마타 등도 모두 여기에 작성한다.

AnerimDriver.exe : DLL은 사용자에게 보이지 않으므로 제어 프로그램이 필요하다. 트레이에 상주하며 일시 정리, 종료, 옵션 등의 명령을 처리한다. 또 현재 입력 상태에 해당하는 LED창과 키보드 보이기/숨기기 기능도 제공해야 한다.

AnerimExercise.exe : 단순한 연습 프로그램일 뿐이며 훅으로부터 전달된 메시지를 받아 동작한다. ApiEdit는 더 이상 필요없으므로 Edit 컨트롤로 대체하고 오토마타도 가질 필요가 없다. 글쇠 연습, 낱말, 문장 연습, 두더지 게임 등을 제공한다.

DLL은 눌러진 키를 드라이버에게 전달하여 키보드에 표시하도록 하고 드라이버는 옵션값을 레지스트리에 기록한 후 DLL에게 변경 사실을 통지한다. 현재 프로젝트는 ApiEdit 때문에 ANSI로 작성되어 있는데 새로 작성할 때는 유니코드 기반으로 다시 작성한다. ANSI도 문제는 없지만 장기적으로 바람직하지 않다. 여기까지 기획을 해 놓고 막상 구현할려고 보니 몇가지 문제점이 발견되었다.

-일단 시간이 너무 많이 소모될 듯하다. 프로젝트야 깔끔해지겠지만 이거 말고도 할일이 많아 너무 많은 시간을 쓸 수 없다.

-통계창을 어디다 둘 것인가가 애매하다. 통계 작성을 위해서는 키맵이 있어야 하는데 DLL이 통계를 뽑을 수는 없는 노릇이다. 그렇다고 드라이버에 두는 것도 통신의 문제가 있고 별도 프로그램을 새로 만들자니 코드가 중복된다.

-차후 기획하고 있는 한손 자판을 위해서는 오토마타 커스터마이징이 여전히 필요하다. 구조를 이렇게 바꾸어 버리면 이후 DLL의 부담이 너무 커진다. 오토마타를 마음대로 주물러 보려면 역시 ApiEdit가 제격인 듯하다.

결국 현재는 이 구조를 유지할 수밖에 없는 듯 하다. 아직도 기획 단계이며 다양한 변형을 시도해 봐야 한다. 안정성도 물론 중요하지만 지금은 가능성을 확인하는 것이 급선무이므로 시간을 덜 쓰는 쪽으로 유지하는 것이 좋을 듯하다.

최종적으로는 디바이스 드라이버를 만들고 제어판에서 키보드 옵션을 조정하도록 완전히 다시 작성해야 한다. 이 작업까지 하려면 최소한 시제품까지는 만들어 보고 편의성을 확인한 후여야 한다.

■ 코드 정리중에 다음 2개의 간단한 버그를 수정하였다.

-Cap키는 오토 리피트를 무시한다. 플래그의 의미를 중간에 바꾸면서 코드에서 직접 조작하는 플래그를 수정하지 않았다.

-키보드 효과음을 내는 루틴이 ProcessKey에 있는데 후킹중에는 키 누를 때, 떨어질 때 2번 발생하는 문제 수정.

불필요한 코드 좀 더 정리하고 함수 및 변수 이름을 정리했다. 3100줄이 넘는 코드가 2800 후반대로 줄어들었다. 앞으로 또 한참 신나게 늘어나겠지만.

■ 0.95에서 구두점이 하나 더 문자 영역으로 내려 오고 Up키의 위치도 바뀌었으며 이로 인해 문자키들도 소폭 변화가 생겼다. 그래서 배치를 다시 정확하게 조정할 필요가 있는데 현재 통계 기능에 여러 가지 문제가 많다. 변화된 배치를 제대로 반영하지 못하고 엉뚱한 결과를 내 뱉는데 다음 문제들을 수정했다.

- 여분키에 배치된 알파벳을 우선적으로 참고한다. 여분키는 어디까지나 테스트를 위해 삽입된 것일 뿐인데 이 키를 우선 참조함으로써 Up키의 회수가 과소 평가된다. 그렇다고 빼기는 뭣하므로 여분키를 고려한 통계와 제외한 통계를 따로 산출하도록 옵션을 하나 더 만들었다.

- 원래 왼손 엄지에는 모드 전환 키밖에 없어 따로 통계를 뽑지 않았다. 그러나 이제 Up키가 들어감으로 해서 통계를 출력할 필요가 생겼다. 정확하게 통계를 뽑으려면 한영수 전환까지 고려해야 하지만 샘플에 따라 차이가 많아 이 부분은 제외했다. 오른손의 BS도 마찬가지다.

- 통계와는 직접적인 상관이 없지만 통계를 뽑는 시간이 너무 오래 걸리므로 프로그래스 바를 대화상자 하단에 배치하여 기다리는 시간을 지루하지 않도록 했다.

이 외에 통계 작성 후 대화상자가 메인 뒤쪽으로 숨는 문제가 있는데 별 문제가 아닌 것 같으므로 그냥 두기로 한다. 수정된 통계 기능으로 다시 조사한 통계는 다음과 같다.

항목	한글	영어	영어(여분 포함)
왼손 비율	5:8:12:19:2.5	5.9:10.0:12.6:12.8:1.6	5.9:10.1:12.7:13.7:0.6
오른손 비율	12:17:9:8:2.4	17.1:12.2:10.5:11.0:5.9	17.2:11.9:10.5:10.9;5.9
1행:2행:3행:4행	24:46:14:14	23:43:13:18	24:44:13:17
1행:2행:3행	28:54:17	29:54:16	29:53:16
손가락 연타율	7.37	8.10	8.55
손 연타율	26.9	42.93	43.25
좌우 분담률	49;50	43:56	43:56
좌우 분담률(엄지제외)	54:45	51:48	52:47
Up키 비율	2.53	1.64	0.66
영문 대소문자 비율	4.84:95.16
영문 손가락 연타	hi(6894), ag(3797), ef(3706), Sp-Ent(3643), lp(3633)
영문 손 연타	you(1075), str(640), ffe(555), ugh(513), hag(371), whe(311), uage(301)

- 여분을 포함한 통계와 제외한 통계가 별 차이가 없다. 여분키로 인해 집게 손가락의 부담이 좀 더 올라가야 하는데 오른손 집게 손가락은 오히려 내려갔다. 빈도가 높은 k가 왼쪽 집게 여분에 있어서 그런 듯 하다. 이 통계에서 보듯이 여분은 분담률에 거의 영향을 미치지 않으면서 키 개수를 늘리고 자세만 흐트러뜨리는 것을 알 수 있다.

- 한글의 왼손 집게가 너무 혹사를 당하는 느낌이다. 영문 왼손은 약중집이 10, 12, 12로 균등한데 비해 한글은 8:12:19로 집게에 너무 치중되어 있다. 그렇다고 ㄱ, ㅇ, ㅅ 중 하나를 다른 손가락으로 옮기는 것도 적절치 않아 보인다.

- 행 비율은 28:54:17로 적절하다. 엄지를 포함하면 엄지가 대략 18%를 분담하는데 모드 변환, BS로 오타 수정 등을 감안하면 대략 20% 정도 되는 듯하다. 이것도 적절해 보인다.

- 손가락 연타율은 둘 다 10% 미만이라 만족스럽다. 영문의 손 연타율이 43%에 달애 너무 높은 듯하다.

- 좌우 분담률은 심하지는 않지만 왼손에 좀 더 부담이 많이 가는 것으로 나온다. 모드 변환과 수정 회수에 따라 달라질 수 있는 부분이다.

- Up 키의 비율은 2.53%, 1.64%로 높지 않다. 여분키를 포함하면 한글 0.47, 영문 0.66으로 "와 '를 누를 때만 사용한다. 그러나 문자 입력시의 빈도만 계산해서 그렇지 숫자 입력을 고려하면 이보다는 훨씬 더 높다.

- 영문 손가락 연타율은 아주 만족스럽다. 가장 빈도가 높은 hi도 연철 순위로 치면 44위의 한참 뒤쪽에 있어 중요한 연철은 다 피한 셈이다.

- 영문 손 연타율은 좀 수정이 필요해 보인다. 많이 사용하는 you가 한손 연타이며 boy나 ugh 등도 전부 왼손 연타이다. whe 연타도 다소 신경 쓰인다.

현재 배치가 과연 칠만한지 몇 시간동안 계속 연습해 보았다. Yesterday 팝송을 쳐 보니 영문 k가 업 위치로 올라간 것이 상당히 아쉽지만 대신 쉼표가 문자 영역에 있어 쌤쌤이다. 속담들을 쳐 보니 역시 k가 아까운데 이것은 아마도 현재 연습 자판의 Up키가 누르기 쉽지 않아서가 아닐까 위안해 보았다.

you와 who 등의 철자가 손 연타라 아쉬운 면이 있는 막상 입력해 보면 손 연타이기는 하지만 왼손 세 손가락을 차례대로 누르면 되므로 리듬감이 있고 별로 거슬리지 않았다. 게티즈버그 연설문에서는 Up 위치의 문자로는 Q만 유일하게 한번 등장하고 어포스트로피가 몇번 등장한 정도이다.

후킹도 해 보고 한칸 올린 자판으로도 계속 연습해 봤는데 현재 배치가 결코 나쁘지 않다는 어느 정도의 확신이 들었다. 이 조악한 연습 키보드로도 이 정도 만족도가 나오는데 시제품만 제대로 만들어서 테스트한다면 꽤 괜찮지 않을까 싶다. 시제품 제작전에 배치를 먼저 확정해야 하므로 한번 더 영문을 더 배치해 보았다. 배치 원칙은 기존과 같아서 상위권에는 별 변화가 없고 하위권도 마찬가지이다. 중하위권의 문자 몇 개를 교환할 뿐이다.

다시 배치해 봐도 비슷하게 나올 수밖에 없다. p, g, w가 서로 한바퀴 자리를 바꾼 것 뿐이다. 결과 통계도 큰 변화는 없다. 빈도가 높지 않은 문자들을 교환한 것이라 좌우 분담률이나 손가락 비율의 변화는 미미하고 손가락 연타에 ow, aw 정도가 추가된 것만 다르다. 손연타도 별 변화가 없지만 ough 4연타가 사라졌다. 이 정도 변화로 키 배치를 바꾸는 것은 무리인 듯 하다.

다음은 한글을 재배치해 보기 위해 키보드를 자세히 관찰해 보았다. ㅂㅈㄷㄱ은 2벌식과 호환도 중요하고 그 자체로 빈도별로 배치된 것이라 건드릴 이유가 없다. ㅇ과 ㅏ는 가장 빈도가 높은 자음, 모임이므로 절대 저 자리를 양보하고 싶지 않다. ㄹ과 ㄴ은 살짝 바꿀 수 있을 것 같기는 한데 빈도상으로는 ㄴ이 훨씬 더 높고 이 두 글자를 바꿔 버리면 아너림이 아러님이 되어 버린다.

모음의 경우 ㅡ와 ㅜ 정도를 교환할 수 있는데 이 두 글자의 위치는 전에도 고민을 하다가 만 적이 있다. 더 이상 딱히 더 손델 곳이 없고 기껏 바꿔 봐야 하위권의 격음들을 조정하는 정도일텐데 그래봤자 통계상의 변화가 더 없을 것이 뻔하다. 결국 한글도 일단 이 배치를 계속 유지하는 것이 좋을 듯하다. 키 배치는 앞으로도 더 많이 고민해야겠지만 결국은 시제품을 만들어 본 후에야 의미있는 조정이 가능할 것이다.

■ 기호와 숫자 모드의 배치도 수정했다. 아직 많이 사용해 본 것은 아니지만 살펴 보고 사용해 보니 조정할만한 부분이 보인다. 기호 모드의 문자들을 다음과 같이 조정했다.

괄호들을 전부 오른쪽으로 모아 외우기 쉽도록 했다. 빈도가 가장 높은 ( )를 홈 포지션에 두고 코딩에 많이 쓰는 { } 괄호도 홈 포지션이다. 웹 괄호인 < >도 접근성이 좋은 곳에 배치했다. 왼손 3행에 2칸은 비어 있다. 왼손 1행도 조정되었는데 메일 주소에 사용되는 @을 좀 더 좋은 자리에 배치했다.

숫자 모드는 딱히 더 건드릴 부분은 없되 -와 *의 자리만 바꿨다. 기존에는 *가 왼손 중지 2행에 있었는데 -의 빈도가 월등히 더 높으므로 더 좋은 자리로 옮겼다.

■ 좌우의 확장 편집키들이 CASW키와 같은 수직 위치에 정렬되어 있는데 이를 한칸씩 위로 올려 보았다. 문자키에 정렬을 맞추면 입력중에 손이 수평으로 똑바로 옆으로 이동하면 되므로 훨씬 더 편리하고 편집 모드의 키들과 위치상 동기화되어 편의성이 증가한다. 또 위쪽이 휑하게 비는 듯한 느낌이 있었는데 좌우로 길게 일직선으로 배치되어 보기에도 좋은 것 같다.

이 변화는 꽤 괜찮아 보였는데 수직 피치를 차등화하면 펑션키열과 맛닿을 것 같아 일단은 보류이다. 만약 펑션키가 충분히 떨어진다면 이때는 위 방식대로 위치를 조정하는 것이 맞는 것 같다.

■ 이제 시제품을 만들어 봐야 할 단계이다. 그 전에 비용을 최대한 아끼고 한번에 완성도 높은 시제품을 만들기 위해서는 가급적 비슷한 배치를 미리 만들어 놓아야 한다. 현재는 그림을 그려 보는 것만이 유일한 방법이다. 파워 포인트로 키보드 그림을 세세하게 조정하여 그림을 그려 보았다.

시제품에 대한 일종의 프포토타입이다. 오늘 작업한 최종 결정본은 다음과 같되 중간에 수십번도 더 바뀌었다. 사소한 길이 하나까지도 일일이 바꿔 보고 캡션도 조정해 보고 여러 가지 시도를 해 보았다. 중간본은 굳이 볼 필요없겠지만 아뭏든 무시한 시도끝에 나온 결과물이다. 비록 종이이고 눌러지지도 않지만 최소한 손가락 위치가 적절한지는 이 방법으로 확인해 볼 수 있다.

다음은 이 그림이 나오기까지의 과정에 대한 설명이다. 차후에도 똑같은 고민을 계속 해야 하므로 상세하게 기록해 둘 필요가 있다.

- 키의 피치는 차등 크기를 적용했다. 최초 문자키는 18*16이었고, 엄지키는 좌우로 이동하며 누르므로 16*18이었다. 차등 피치란 2행은 18*16으로 크게 만들고 1, 3행의 수직 피치를 14로 줄이는 것이다. 수직 피치가 16인 것은 운지거리를 최소화하겠다는 뜻이다. 그러나 차등 피치를 적용한 것은 운지 거리보다는 부피 최소화가 주목적이다. 제자리에서 움직이므로 키가 굳이 클 필요가 없다고 생각했는데 다소 과격하고 거부감이 든다는 것은 알고 있다. 차후 키 크기에 대해 이견을 제시하는 사람이 있다면 롤백할 가능성도 있다.

-키의 크기는 피치보다 1미리 더 작게 만든다. 문자키의 경우 피치가 18*16이므로 키크기는 17*15가 되며 키간의 간격은 대락 1미리 정도가 되는 셈이다. 전에는 키간격이 2미리였는데 너무 벙벙해 보이고 공간을 낭비하는 것 같다. 쿼티 키보드의 경우는 키 간격이 1미리도 안되는 경우가 많다. 키 간격은 키끼리 부딪치지만 않으면 그만이다. 단, 키의 간격과 키 표면의 크기는 별개의 문제이다. 손가락이 닿는 키면적은 키 크기보다 더 좁게 만드는 것이 일반적이다. 이 면적에 대해서는 아직 고민해 본 바 없는데 위쪽은 두고 하좌우로 대략 2미리 정도는 더 작게 만들어야 하지 않나 싶다.

- 키의 들여쓰기를 4미리에서 2미리로 조정했다. 키 피치가 줄어들었으므로 운지거리가 짧아졌고 따라서 손가락을 아래위로 뻗었을 때의 거리 차이를 더 줄여야 한다. 최초 3미리로 줄인 후 타건해 보니 적당해 보였다. 그런데 기울어졌다는 것 자체가 중요할 뿐 정도는 그리 중요한 문제가 아닌 것 같다. 너무 많이 기울이면 손가락의 이동이 자연스럽지 못할 것 같아 2미리 정도로 약하게 들여썼다.

- 엄지의 키들을 곡선 형태로 배치했다. 엄지를 좌우로 움직여 보면 수평으로 나란히 움직이는 것이 아니라 회전하듯이 틀어진다. 각도를 제보니 25도 정도가 적당한 것 같다. 안쪽 버튼은 25도만큼 기울이고 중앙의 버튼은 곡선 형태로 배치했다. 차후 시제품 제작이 어려우면 다각형 형태로 제작할 수도 있다. 이 상태로 타건해 보니 꽤 그럴듯하다.

- 엄지키를 문자키와 더 많이 띄웠다. 원래는 4미리 띄웠었는데 7미리로 늘렸다. 수직 키피치가 2미리 줄어든만큼 엄지키와의 거리도 그만큼 멀어져야 한다. 이 수치의 도출 과정이 좀 복잡하다. 키피치 18.8미리의 쿼티 키보드를 기준으로 했을 때 2행 버튼의 정가운데와 공백키와의 거리는 9.6 + 18.8 = 28.4미리이다. 현재 아너림의 피치 구조로는 2행 키 중앙에서 하단까지 8미리, 3행의 수직 피치 13미리를 더하면 21미리가 된다. 0.4를 내림하면 7미리만큼 띄워야 쿼티 키보드의 가운데 열과 공백까지의 거리와 일치한다.

- 각인 폰트는 깔끔한 고딕체로 작성했는데 그러다 보니 영문자 I, 한글 모음 ㅣ, 논리 OR 기호 |가 거의 구분되지 않는다. 또 한글 자음 ㄴ과 영문 L도 비슷해서 헷갈린다. 그래서 세리프가 있는 명조체로 바꾸었다. 각인은 현재 한영수기 정도 표기되어 있고 영문의 경우 Up 위치의 문자까지 기록해 넣었다. 연습을 위한 키보드이므로 가급적 많이 넣었지만 실제 제품에서는 좀 더 간소화해야 한다.

이 도면대로만 시제품을 만들어도 테스트에 상당히 편리할 것 같다. 차후 시제품 제작시 설계 도면으로 사용할 것이다.

■ 새로 그린 도면을 연습 프로그램에도 적용했다. 직접 손으로 누르는 것이 아니라 사실 굳이 동기화할 필요는 없지만 최대한 같은 모양대로 그리는 것이 혼란을 방지할 수 있을 것 같다. 키보드 랜더링 코드가 잘 작성되어 있어 큰 어려움없이 화면상의 배치도 조정 가능하다.

먼저 랜더링 관련 옵션 변수명을 약간 조정했다. 엄지키를 3행으로 보고 k_vpitch3, k_3down 등으로 이름을 붙여 놓았는데 이 행은 4행으로 보는 것이 옳다. 코드에서는 zero base이므로 3행으로 취급되지만 1부터 시작하면 4행이 되므로 헷갈리지 않게 4행으로 변수명을 조정했다. 도면에서 조정한대로 들여쓰기는 2미리로 디폴트값을 바꾸고 3행 엄지키의 간격은 7미리로 조정했다. 변수값만 바꾸면 즉시 적용된다.

k_vpitch13이라는 이름으로 옵션 변수를 하나 더 선언하고 1, 3행의 높이는 이 값을 참조하도록 수정했다. 한 행의 높이가 바뀜으로 인해 배치 코드도 연쇄적으로 같이 조정되었으며 전체 키보드의 높이를 구하는 방법도 달라졌다. 키의 면적에 대한 옵션인 키간격은 1미리로 설정되어 있는데 이 값이 양쪽으로 적용되므로 실제로는 2미리 간격이 적용되었다. 옵션값은 그대로 두고 좌우에 절반씩의 간격을 더함으로써 1미리 떨어지도록 했다. 작은 값에 대해 연산을 하다 보니 실수 절사가 발생해 키끼리 너무 딱 붙는 문제가 생겨 실수 버전의 계산 함수를 따로 만들었다. 여기까지의 결과는 다음과 같다.

2행이 상대적으로 더 뚱뚱해 보이며 키끼리 너무 다닥 다닥 붙어 있는 듯한 느낌이 든다. 이 그림의 키 사각형은 키의 면적일 뿐이며 키 표면과는 다른 개념이라 느낌상 답답해 보이는데 어떻게 그리는가에 따라 달라 보일 것이다. 시제품 키보드에는 면적이 가운데로 축소되므로 답답하지 않을 것이다.

엄지키를 곡선 형태로 그리는 것은 하지 않기로 했다. 안쪽키가 이미 약간 내려가 있어 의도는 충분히 표현할 수 있다. 곡선 형태로 그리는 것 자체는 그리 어렵지 않지만 그렇게 되면 마우스 히트 테스팅을 리전으로 해야 하므로 번거로워진다. 굳이 그렇게 할 필요까지는 없어 보인다. 다음에 아주 시간이 많이 남으면 해 볼 것이다.

■ 도면에 캡션을 작성하면서 발견한 것인데 이 키보드의 영문 이름은 etonis가 된다. 한글로 아너림인 이유는 2행을 좌우 교대로 칠 때 나오는 글자대로 이름을 붙인 것이다. 영문의 경우 교대로 치면 etonis가 된다. 최소한 쿼티보다는 발음이 좋고 귀여운 것 같다. 혹시 etonis라는 단어가 있는지 쳐 보니 없다. 검색해 보니 분사형 변형 콘크리트의 일종을 개발한 적이 있는데 이 콘크리트의 이름이 etonis라고 한다. 그 외에 다른 뜻은 특별히 없는 것 같다.

■ 아너림은 좌우손에 할당된 키가 분명하고 엄지키가 안쪽까지 침범해 있어 중앙에 공간에 꽤 남는 편이다. 이 공간에 무엇을 넣을 것인가에 대해서는 예전부터 생각해 둔 것이 있고 또 기획도 해 두었었다. 바로 터치 패드이다. 터치패드를 넣고 그림을 그려 보면 다음과 같은 모양이 나온다.

중앙이 꽉 차 보여 좀 갑갑한 면이 있다. 그리고 터치 패드의 폭이 좀 넓은 편인데 좌우를 더 벌리면 필요한 공간을 더 확보할 수 있다. 소형 장비에는 확장 편집키가 없는 Standard 구성을 사용할 것이므로 폭이 더 넓어도 상관없다. 그 이상의 구성일 때는 터치패드가 부담스러우며 특히 여분키와는 공간상 충돌하므로 공존하기 어렵다.

터치 패드가 가운데에 있으면 문자 입력하다 마우스 조작이 필요하면 왼손 집게로 터치 패드를 드래그하고 오른손 집게로 클릭하면 된다. 키보드 아래쪽에 있는 것이 아니므로 걸리적거리지도 않고 오동작도 걱정할 필요가 없다. 이 아이디어는 남은 공간을 활용하는 것이므로 나 아니라 누구라도 생각할 수 있는 것이다. 그러나 한발 더 나아가 좀 더 편의성을 극대화할 수 있는 방안을 생각했다.

터치패드에 손이 닿아 있는 상태일 경우는 Up키를 왼쪽 클릭으로 사용하는 것이다. 오른쪽 클릭은 물론 Mode키가 된다. 이렇게 되면 왼손 집게만 터치패드로 가고 오른손은 홈 포지션에 죽치고 있어도 되므로 좀 더 편리하다. 단, 이 경우라도 클릭을 먼저하고 드래그할 때는 Up키를 사용할 수 없으므로 터치패드의 클릭 버튼은 별도로 따로 존재해야 한다. Up키는 다만 손가락이 터치 패드 위에 닿아 있을 때만 클릭으로 동작하며 이것도 불편할 수 있으므로 옵션으로 제공하는 것이 옳다.

터치 패드를 중간에 넣는 것은 꽤 그럴듯하지만 당장은 실행에 옮길 수 없다. 키보드 시제품도 제대로 만들지 못하고 있는 상태에서 터치패드라니. 이 아이디어는 기획만 해 두고 차후 키보드가 조금이라도 성공하면 그때 시도해 볼 것이다. 그런 날이 왔으면 좋겠다.

■ 시제품을 만들 때까지 테스트해볼 샘플 키보드가 필요하다. 다음은 3년전에 만들었던 샘플 키보드이다.

그동안 배치가 바뀌었기 때문에 3년전의 키 구조와는 상당히 달라졌다. 문자키의 개수는 변화가 없지만 엄지키가 하나 더 늘었고 좌우에 CASW키가 더 추가되었다. 그런데 뽑아놓은 키를 잃어 버려 다 채우지 못했다. 당장 없어도 테스트는 가능한데 끼워서 쳐 보니 그럭 저럭 잘 동작은 한다.

하지만 너무 싸구려 키보드이고 방치한지 오래되다 보니 키감이 영 좋지 못하다. 라벨에 붙은 문자들도 현재 키배치와는 맞지 않다. 왼손 문자키들의 기울임 방향이 반대로 되어 있어 느낌도 영 별로이다. 그래서 기울어는 방향을 조정하기 위해 2행과 3행을 오른쪽으로 이동시켜 보았다.

사다리꼴 모양이 나와 현재 배치와 많이 비슷해 보인다. 이 배치를 테스트하려면 올림 상태의 키맵도 같이 수정해야 한다. 막상 이 키보드로 테스트해 보면 왼쪽의 기울어짐이 너무 심해 도저히 입력을 할 수가 없다. 1행은 그나마 2행의 중간쯤에 걸려 있어 어느쪽으로 기울어지나 비슷하지만 3행은 2행과 너무 많이 어긋나 있어 아래쪽에 있다고 할 수가 없다. 기울어진 방향이 맞지 않아도 원래 구조가 쿼티 습관과도 맞고 치기도 더 편리하다.

이 키보드로 계속 테스트하려고 했는데 키감이 너무 좋지 않아 아너림 2호 키보드를 하나 더 제작하기로 했다. 키감이 좀 더 양호하고 휴대하기 용이한 녀석으로 선정했는데 마침 창고를 뒤져 보니 전에 삼성 프로젝트할 때 사용하던 무선 키보드가 발견되었다. 아너림 1호는 7천원짜린인데 비해 이 녀석은 무려 6만원짜리이며 트랙볼도 달려 있다. 멤브레인 방식이 아닌 팬터그래프 방식이라 키감도 양호한 편이다.

테스트 키보드에 무선이 뭔 필요한가 싶었는데 막상 사용해 보니 선이 없다는 것이 너무 너무 편리했다. 그냥 키보드 옆에 두고 필요하면 쓰윽 옆으로 당겨 사용하면 된다. 먼저 필요없는 키를 전부 뽑았다. 팬터그래프는 키를 빼기도 어렵지만 일단 빼고 나면 다시 복구시키는 것은 거의 불가능하다. 그래서 좀 망설여졌지만 어쩔 수 없다. 이빨을 다 뽑고 난 다음의 모습이다.

Standard 구성의 모든 키들을 남겨 두었고 펑션키와 오른쪽 확장키도 남겼다. 왼쪽 확장키의 Esc, Tab, Prtsc도 남겨 두었지만 위치가 여기 저기 흩어져있어 제대로 테스트하기는 어렵다. 아너림에 없는 키중 살아 남은 유일한 녀석은 Num Lock 딱 하나인데 이 키가 눌러지면 문자키가 숫자키가 되어 버리므로 끄기 위해서 필요하다.

X자형 지지대는 남겨둘까 하다가 지저분해 보일 것 같아 모두 뽑아 버렸다. 이제 이 키보드는 아너림 외에는 써 먹을 데가 없게 되었다. 키에 어떤 문자가 할당되어 있는지 라벨링도 깔끔하게 했다. 천원짜리 코팅 접착 견출지를 사서 글자를 펜으로 써 넣고 테이프로 코팅한 후 키에 붙였다. 정확한 크기대로 자르고 코팅까지 한 후 붙여야 하므로 꽤 시간이 걸리는데 거의 3시간 가량 걸린 것 같다.

뽑혀진 이빨이 좀 불쌍해 보이지만 샘플 키보드로는 아주 만족스럽다. 키감이 훌륭하고 무선이라 노트북 위에 살짝 올려 놓고 테스트하기에도 아주 그만이다. 그러나 키의 위치가 의도한 것과는 달라 역시 불편하다. 결국에는 시제품이든 목업이든 만들겠지만 그 공백을 잠시 메워주는 걸로 만족해야겠다. 이 녀석이 아너림 2호 키보드이다.

2호 키보드로 타이핑을 해 본 결과 형태가 다른 건 어쩔 수 없더라도 각인의 문제가 심각했다. 아직 다 외우지 못한 상태에서 한글, 영어, 기호 등을 다 새겨 놨더니 무진장 헷갈린다. 특히 알파벳 o와 한글 자음 ㅇ이 옆자리에 나란히 있어서 헷갈리며 모음 ㅐ와 알파벳 H는 떨어져 있어도 헷갈린다. 황당하게도 알파벳 T와 모음 ㅜ까지도 자리가 근처라 혼동이 된다는 것이다.

글자 자리를 다 외우고 쳐야 문제가 없을 것 같다. 차후에 다시 라벨링을 하려면 영문과 한글을 좀 더 분명히 구분할 수 있도록 위치를 다시 선정해야 할 것 같다. 알파벳은 좌상단에 쓰고 한글은 우하단에 써야겠다. 그리고 기호, 숫자들도 가급적 자재하는 것이 좋겠다. 숫자는 생략해도 될 듯 하며 기호는 키캡 아래쪽 비스듬한 면에 새겨 넣는 것이 좋을 것 같다. 외워야 쓸 수 있는 키보드이므로 각인은 절제하는 것이 바람직하다.

■ 키보드의 활용성을 테스트해 보기 위해 후킹 상태로 스타크래프트 게임을 해 보았다. 기능상으로는 큰 문제없이 무난히 잘 실행된다. 엔터키 누르고 show me the money를 입력하면 치팅도 잘 동작한다. 모든 단축키 잘 먹히고 공격, 이동, 선택도 다 제대로 된다. 딱 한가지 문제는 z키가 잘 입력되지 않는다는 점이다. 저글링을 만들어야 하는데 z가 Up 위치에 있어 두번 눌러야 하며 그것도 되다가 말다가 한다. 어떤 조건에서 안되는지 모르겠지만 아뭏든 사소한 문제가 있는 것은 분명하다.

채팅할 때 Up키와 함께 z가 잘 입력되는 걸로 봐서 입력 자체는 되는 뭔가 조건이 맞지 않은 것 같다. Up 더블 푸시해서 고정해 놓고 z를 누르는 것은 항상 잘 된다. 그렇다고 고정해 놓고 사용할 수는 없는 노릇이다. 스타크래프트 단축키는 주로 왼쪽에 있는데 아너림에서는 여기 저기 흩어져 있어 편의성이 떨어진다. 물론 이것은 스타가 쿼티를 기본으로 제작되었기 때문이다.

단축키 문제 외에도 여러 가지 불편한 점이 많다. 그룹 지정을 할 때 Ctrl + 1을 눌러야 하는데 Ctrl + Up + 1로 3개의 키를 동시에 눌러야 한다. 그룹 선택을 할 때는 그래도 Up + 1만 누르면 되지만 이것도 빠른 게임의 특성상 편리하다고 할 수는 없다. Up 홀드 상태에서 + -를 눌러 게임 속도를 조정하는 것, Edit 상태에서 Prtsc키를 눌러 화면을 캡처하는 기능 등은 잘 동작한다. 아너림으로 게임을 한다면 불편은 하지만 억지로라도 하려면 가능은 하다.

■ 가상 PC에서는 어떻게 동작할까 궁금해서 테스트해 보았다. Virtual Box로 테스트해 보려고 했는데 이 프로그램은 가상 머신을 만든 시스템에서 설치해 놓은 것만 동작하는 듯하다. 전에 데스크탑에서 만들어 놓았던 가상 머신 이미지를 노트북으로 가져왔더니 네트워크 카드가 틀리다는 에러가 발생한다. 가상 머신이 뭔데 외부 환경의 영향을 받는지 이해가 안된다.

그래서 어쩔 수 없이 Virtual PC로 테스트해 보았다. 결론은 사용할 수 없다이다. 궁금했던 것은 오른쪽 조합키가 제대로 먹히는지를 보려고 했는데 Virtual PC는 풀 화면 토글이 RAlt + Enter이다. 현재 아너림은 RAlt를 누를 수는 있지만 조합키로는 누를 방법이 없다. 매크로 기능 정도는 되야 이 기능을 지원할 수 있을 듯 하다. 불편하더라도 필요하다면 매크로 등록해 놓고 사용할 수는 있어야 한다.

풀 화면 토글 외에 후킹도 제대로 되지 않았다. 호스트 OS에 아너림을 띄워 놓고 Virtual PC 안에서 키를 입력해 보면 영향을 받기는 한다. 키맵에 정의되지 않은 키는 입력이 거부된다. 그러나 키맵에 있는 키는 맵이 바뀌지 않고 원래 키가 그대로 입력되어 버린다. Virtual PC 안에 아너림을 설치하고 후킹하면 내부에서는 잘 실행된다. 아무리 가상이라고 해도 그래도 PC 한대이고 자신의 디바이스 드라이버를 가지고 있으므로 이걸 후킹하는 것은 기술적으로 훨씬 더 난이도가 높은 것 같다.

12년 7월 1일

■ 편집 모드와 펑션 모드에 잡다한 키들이 꽤 많다. 최소한 쿼티 키보드에 있는 모든 키들은 입력 가능해야 한다고 생각하기 때문이다. 문제는 모든 키가 다 있는 것은 아니며 다 필요한 것도 아니라는 것이다. 잘 안쓰는 키는 적당히 없어도 상관없고 좀 불편해도 입력만 가능하면 있는 흉내라도 낼 수 있다.

그래서 전에 생각해 두었던 것이 스캔 코드를 직접 입력하는 방식이다. 모드에 상관없이 Shift와 Up을 홀드한 채로 숫자키를 사용하여 십진 스캔 코드를 입력받아 보내는 방식이다. 사실 이런 방식은 쿼티 키보드에도 이미 있는데 Alt키를 누른 채로 넘패드의 숫자키를 누르면 아스키 문자를 입력할 수 있다. 소프트웨어가 지원하는 것이 아니라 하드웨어가 지원하는 기능이다. 아너림도 디바이스 드라이버가 올라 오기전에 특정키를 누를 수 있어야 하므로 하드웨어적으로 이 기능이 필요하다.

이 기능을 넣으면 잡다한 키들은 일단 뺄 수 있고 정 필요하면 억지로나마 입력할 방법도 제공하는 셈이다. 문자열 버퍼를 하나 마련하고 키 입력시 Shift+Up 상태이면 이 버퍼에 모은다. 다른 키는 모두 무시하고 오로지 숫자키만 입력받아 모은다. Up을 처음 누를 때 코드를 리셋하고 적용한 후에도 리셋한다.

수집한 코드를 처리하는 시점은 Up키를 뗄 때이다. 수집한 코드가 있으면 이 코드를 스캔 코드로 바꾸어 타겟 윈도우로 보낸다. 테스트해 보니 대충 잘 동작한다. 이 방법으로 입력할 수 있는 주요 키의 스캔 코드는 다음과 같다.

CapLock : 58, Scroll Lock:70, NumLock:69

상하좌우 : 72, 80, 75, 77

RAlt : 184, RShift : 54, RCtrl : 157, Win:91, RWin:92, Menu:93

펑션키 : 59~, 공백 : 57, 엔터 : 28, BS:14, Esc:1

문자키 : Q:16~, A:30~, Z:44~, 1=2~

Pause : 197, 한자:157

대충 테스트해 보면 그럭 저럭 동작한다. 70 스캔코드를 보내면 키보드의 Scroll Lock에 불이 들어온다. 그러나 여러 가지 문제가 많다.

- 스페이스로 숫자 0을 입력할 수 없다. 이 문제는 현재 사용하고 있는 드라이버가 Shift+Space를 한영 전환키로 사용하고 있기 때문이다. 키보드 종류를 바꾸면 해결될 것 같은데 당장 입력할 방법이 없으니 Enter에도 0를 중복 정의했다. 차후 디바이스 드라이버 형태로 만들면 해결될 듯하다.

- 255 초과의 값을 입력하면 유니코드 문자를 직접 입력하는 기능도 작성하려고 기획했다. 그러나 구현 방법이 얼른 떠오르지 않는다. 포커스 윈도우로 WM_CHAR를 보내면 될 듯한데 1바이트 아스키 문자는 되지만 2바이트 문자는 안된다. 유니코드가 아닌 윈도우는 유니코드로 바꿔서 보내 줘야 할 것 같기도 하고 아뭏든 좀 더 연구가 필요하다.

- 메뉴 버튼은 제대로 입력되지 않는다. 이 버튼은 스캔 코드, 가상키 코드가 모두 93(VK_APPS)으로 조사된다. 스캔코드 93에 대해 MapVirtualKey 함수로 가상키 코드를 조사하면 엉뚱하게도 249가 나오며 이 값은 VK_EREOF라는 이상한 값으로 정의되어 있다. 일부 다른 키들도 제대로 입력되지 않는다.

한나절을 작업했는데 원하는 결과가 깔끔하게 나오지 않았다. 하지만 이 기획 자체는 채택하고 차후에 코드를 좀 더 보강하기로 한다. 정 안되면 스캔 코드말고 자체적인 키 번호를 만들어서라도 가능하게 만들 방법이 있다. 입력 안되는 키는 당분간 그냥 쌩까도 별 상관없을 듯 하다.

■ 매크로는 키입력 여러 개를 저장해 놓고 한꺼번에 실행하는 방법이다. 오래전부터 염두에 두었었는데 지금에서야 기획을 한다. 일종의 사용자 정의키라고도 할 수 있으며 아너림의 부족한 키를 메워줄 수 있는 좋은 방법이 될 것으로 기대하고 있다. 가령 Ctrl + Z가 꼭 아쉽다면 매크로키에 기능을 할당해서 쓸 수 있다. 당근 텍스트 편집기를 작성하면서 이미 만들어 본 적이 있어서 수월할 것이다. 큰 원칙은 다음과 같다.

- 복잡한 편집 대화상자같은 건 만들지 말고 스크립트 방식을 사용한다.

- 따로 부호화(컴파일)하지 않고 문자열을 바로 해석하면서 실행한다.

- 기본 문법은 동사 + 목적어 + 회수이다.

- 대소문자는 구분하지 않으며 모두 소문자로 바꾸어 해석한다.

- 문장은 ;으로 구분하되 편집할 때는 개행 코드로 보여준다.

키보드의 매크로이므로 키의 동작만 기억하며 마우스나 윈도우 관리 따위는 하지 않는다. 기본 문법은 다음과 같다. 일단 이정도로 하되 차후 더 고급한 사용 방법을 개발하여 계속 늘려갈 것이다. 변수를 도입하면 조건이나 반복 등도 가능할 것 같으며 거의 언어 수준이 될 것 같지만 너무 작업이 커지므로 기본부터 잘 만들어 보자.

동사	설명
down 키	키 누름
up 키	키 놓음
key 키 [회수]	키 눌렀다 놓음
modi casw+키 [회수]	조합키 누름
call 이름 [회수]	매크로 호출
sleep n	1/1000초 단위로 쉼
type 문자열	문자열 입력

문자열을 입력하는 type 명령은 문제가 많다. 문자에 따라 모드를 조정해야 한다. 한글인 경우 풀어쓰기 하여 가상키코드 목록을 생성한 후 보내야 한다. 기획에만 포함시켜 놓고 당장 구현하지는 않을 것이다.

모든 키에는 외우기 쉬운 고유한 이름을 붙인다. 그래도 목록을 다 외우기는 쉽지 않으므로 대화상자에서 간단한 도움말을 제공해야 할 것 같다. 차후 멀티미디어 키도 포함시킬 수 있다.

영문자 : a~z

숫자 : 1~0

펑션키 : f1 ~ f12

기호 : [ ] \ ; ' , . / ` - =

이동키 : left, right, up, down, pgup, pgdn, home, end, delete, insert

편집키 : space, bs, enter, esc, tab

조합키 : shift, rshift, ctrl, rctrl, alt, ralt, win, rwin

락키 : caplock, scrlock, numlock

기타 : menu, pause, prtsc

키의 이름으로부터 타겟으로 보낼 가상키를 찾는다. 결국 매크로는 디바이스 드라이버에 의해 실행되므로 타겟 윈도우가 받게 되는 쿼티키가 되는 셈이다. 차후 아너림 드라이버가 만들어지면 아너림의 키를 보내게 될 것이다.

매크로 키는 6개 정도를 계획하고 있다. 왼쪽 편집키 영역에 배치할 것이며 편집 모드에도 두기로 한다. Ctrl, Shift와 조합하면 총 18개를 사용할 수 있다. 조합키가 너무 많으면 편의성이 떨어지므로 Ctrl + Shift 동시 조합은 지원하지 않기로 한다. 6개의 매크로키는 디폴트로 다음 명령들을 가진다.

copy : modi c+c

paste : modi c+v

cut : modi c+x

swap : down shift;key left;up shift;call cut;key left;call paste;key right

sleep : key win, key right 2, key s

indent : key home;sleep 200;key tab;key down

매크로끼리 서로 호출도 가능하므로 모든 매크로는 유일한 이름을 가져야 한다. 매크로 추가시 macro1 식으로 일련 번호를 붙여 생성해 주고 사용자가 이름을 바꿀 수 있도록 한다. 매크로는 키를 당장 할당하지 않더라도 따로 생성해 놓을 수 있다. 여러 벌의 매크로를 만들어 두고 필요에 따라 키를 바꿔 가며 사용한다.

매크로 편집 대화상자는 목록에 매크로 이름, 할당된 키, 내용 등을 보여 주고 에디트에서 스크립트를 직접 입력 받는다. 키 할당은 언제든지 변경할 수 있다. 매크로 자체도 추가, 제거, 이름 변경이 가능하다. 편집된 매크로 세트는 이름을 주고 파일로 저장해 놓고 불러와 사용한다. 웹 작업용, 코딩용 등의 매크로 집합을 파일로 정의해 사용할 수 있으며 시스템 포맷시 즐겨 사용하던 매크로를 백업할 수도 있다.

이 기획대로 구현하는데 사흘 정도 걸렸다. 아무리 간단한 스크립트라도 해석해 가며 실행해야 하고 어느 정도는 에러 처리도 해야 하기 때문이다. UI 작업도 꽤 많이 들어 갔다. 만들어서 테스트해 보니 그럭 저럭 잘 동작한다. 물론 지금은 어디까지나 가능성을 보는 단계이므로 섬세하지 못하며 버그도 많이 있다. 차후 이 기능이 유용하다고 판단되면 더 정밀하게 다듬을 것이다.

매크로 편집 대화상자를 만들면서 직접 입력을 해야 하는데 후킹 상태에서도 가능한지 의아스럽다. 연습 프로그램이 후킹을 할 때는 어떠한 입력도 받지 않기 때문이다. 매크로만 따로 실행 파일을 만들어야 하나 잠시 고민했는데 통계 대화상자에서 테스트해 보니 후킹 중에도 대화상자는 잘 동작했다. 윈도우가 다르기 때문에 후킹 타겟이 될 수 있는 듯하다.

매크로 편집 대화상자는 다음과 같다. 리스트 뷰에 매크로 목록과 단축키 설정 상태, 그리고 간략한 내용을 보여주고 아래쪽의 버튼으로 첨삭 및 편집한다. 리스트 뷰가 좀 복잡해서 그렇지 대화상자 자체는 무척 심플하다.

편집 버튼을 누르거나 더블클릭하면 매크로 이름, 내용, 단축키를 변경할 수 있는 대화상자를 따로 열어 편집을 받는다. 대화상자 오른쪽에는 간단한 도움말을 텍스트로 표시해 두었다.

매크로 키는 왼쪽 편집키에 남은 여분 6개를 할당했다. 따라서 이제 이 키들은 더 이상 여분이 아니고 카테고리 2에 속하는 키가 되었다. 매크로와 스캔코드 직접 입력 기능이 들어감으로써 잡다한 키들은 이제 제거 가능하다. 오른쪽 조합키 정도는 매크로로 입력할 수도 있으므로 제거했다. Cut, Copy, Paste 키도 매크로로 가능하므로 디폴트 샘플 매크로에만 넣어두고 키는 제거한다. 편집 모드는 다음과 같이 재배치되었다.

좌우의 편집키가 그대로 편집 모드의 문자키 영역에 들어와 훨씬 더 직관성이 높아졌고 외우기도 쉬워졌다. Standard 구성에서도 키 하나를 더 누르거나 고정시켜야 하지만 이 모든 키들을 그대로 사용할 수 있다. 펑션 모드의 키들도 재정비했다.

매크로 기능이 과연 유용한지, 안정적으로 잘 동작하는지는 앞으로도 한참 더 테스트해 봐야 한다.

■ 숫자 모드의 문자들도 약간 조정했다. 오른쪽의 .과 ,의 자리를 바꾸었다. 소수점이 더 자주 사용되므로 치기 쉬운 곳에 배치했는데 넘 패드의 모양과 달라져서 좀 이상해 보이기도 한다.

이 두 문자를 바꾼 이유는 국제화를 위해서이다. 문자 영역에 구두점을 위해 키 2개를 도저히 할당할 수 없는 언어들은 숫자 영역의 .과 ,를 대신 사용할 수도 있다. 의도가 이러하므로 문자 영역의 '과 "도 숫자 영역에 중복 배치해 두었다. 좀 지저분해 보이기는 하다.

■ 비주얼 스튜디오에서 컴파일한 후 Ctrl + F5로 실행하면 Ctrl키가 눌러진 채로 시작하는 현상을 보인다. 이 키를 놓기 전에 프로그램이 실행되어 훅 프로시저를 설치하므로 Ctrl키는 계속 눌러져 있는 상태이다. 프로그램을 마치고 돌아가면 비주얼 스튜디오는 Ctrl이 눌러진 것으로 인식하고 클릭에 대해 단어를 선택하며 휠을 굴리면 폰트 크기가 바뀐다.

이럴 때마다 Ctrl키를 한번 더 눌러 풀어주곤 했는데 너무 불편하다. 그래서 후킹 옵션이 켜져 있을 경우 OnCreate에서 바로 후킹을 시작하지 않고 약간의 지연 시간을 두었다. 릴리즈는 0.2초, 디버그는 0.8초후에 후킹을 시작하며 이렇게 되면 Ctrl키를 놓는 이벤트가 비주얼 스튜디오로 전달된다. 단독 실행할 때는 별 문제가 없다.

12년 7월 2일

아너림 2호 테스트 키보드로 지속적인 연습을 해 보았다. 자리도 익혀야 하지만 실제 사용해 봐야 뭐가 불편한지 알 수 있기 때문이다. 일지도 쓰고 웹 게시판 들어가서 게시물도 써 보고 비주얼 스튜디오로 코딩도 해 봤다. 짧게 테스트할 때는 잘 몰랐는데 하루 종일 사용해 보니 많은 문제점들이 드러났다. 하나씩 순서대로 해결해야 할 문제들이다.

■ Up 상태에서 ㅆ을 입력하는 것이 예상외로 불편하다. 빈도상으로 콤마보다 훨씬 더 높은데 Up 위치에 있다는 것이 아깝고 영문 K도 아쉽다.

■ 숫자와 편집 홀드가 아직까지는 헷갈린다. 자주 바뀌다 보니 익숙하지 않은 것 같기도 하고 숫자 모드 전환은 Mode이되 임시 숫자 입력이 Up으로 분리되어 있어서 그런 것 같다. 쉽게 말해서 직관력 위배이다.

■ 아너림 2호에 라벨링 해 놓은게 오히려 더 헷갈린다. 특히 알파벳 O와 한글 자음 ㅇ이 옆에 나란히 있는데다 알파벳 O 자리가 2벌식의 ㅇ 자리라 더 그렇다. 차라리 라벨링 제거하고 안 보고 치는게 더 쉽다. 개념상 외워서 치는 키보드이므로 그렇게 해도 무방할 것 같다. 차후 각인을 새기려면 영문은 좌상단, 한글은 우하단에 세리프체로 확실하게 구분되도록 해야겠다.

■ 아너림 2호의 왼손 엄지 위치가 맞지 않다. 문자키가 좌로 기울어져 있어 엄지가 안쪽으로 쑥 더 들어와야 한다. 왼엄지 버튼을 한칸 더 왼쪽으로 옮기는 것이 좋을 것 같다. 이렇게 되면 Ctrl키가 밀려나 버리는 문제가 있다. 역시 시제품을 조속히 만들어야 할 것 같다.

■ 엄지키의 위치가 너무 안쪽에 있는 것 같다. 키보드 인쇄해 놓고 손을 얹었을 때는 맞는 것 같은데 막상 오랫동안 쳐 보면 엄지가 벌어져 자연스럽지 못하다. 그림 수정해서 좀 더 바깥쪽으로 이동시켜야겠다. 거의 2행 집게키 바로 아래가 맞는 듯 하다.

■ 영문, 한글 모드 싱크가 안맞는 경우가 가끔 있는데 주로 웹 브라우저가 그렇다. 한번 안 맞으면 토글해도 계속 안 맞아 메모장으로 가서 몇 자 치고 다시 돌아오거나 후킹 종료 후 재실행해야 한다. 절대 모드로 변경하는 방법을 연구해 보거나 다른 방법을 모색해 봐야겠다.

■ 코딩을 해 보니 기호 3개가 연속으로 나오는 경우가 자주 있다. );} 함수 호출하고 브레이스로 닫는 경우 등이 그렇다. 4개 이상인 경우도 물론 있을 것이다. Sym 키를 세번 누르기도 그렇고 이 정도 회수로 락을 하기도 애매하다.

■ 'c') != 구문을 쳐 보니 구두점, 기호, 숫자 등이 섞여 나타나 모드 변환을 자주 해야 한다. 한글까지 섞이면 더 심해질 것이며 이건 전용 키보드가 있고 익숙해진다 하더라도 힘들 것 같다. 현재 아너림 키보드의 가장 큰 문제이다. 키가 적다 보니 기호, 숫자, 구두점이 여기 저기 흩어져 있다. 그룹화를 잘 해 놨지만 역시 키가 따로 있는 것보다는 불편하다.

이 문제에 대해서는 전반적인 수술이 필요하다. 여분키 6개를 다 넣고 펑션 12개를 문자키 위에 얹어 기호를 배치해 볼까 생각해 보았다. 10개는 숫자에, 24개는 펑션키에, 나머지 8개는 문자 영역에 배치하면 기호 모드가 필요없어진다. 그러나 이렇게 해도 흩어져 있기는 마찬가지라 완벽하지는 않으며 펑션 모드 변환이 옵션이 아닌 필수가 되어 버린다. 한참 더 연구가 필요한 문제이다.

■ 몇일 연습해 본 결과 더 많은 키가 필요하고 더 많은 타협이 필요하다는 것을 느꼈다. 여러 사람들에게 보여 주고 받았던 조언을 들어야 할 것 같으며 고집을 부릴 사안이 아님을 인지했다. 아직은 시제품을 만들 단계가 아니다. 아너림 2호로 당분간 만족하고 더 장시간 투자하여 연구하자.

■ 연습중에 아직도 오타가 많이 발생하는데 주로 2벌식의 버릇이 남아서이다. 영문은 그나마 외운대로 치겠는데 한글은 정말 잘 안된다. 사람의 습관을 고치는 것은 예상보다 훨씬 더 어렵고 어쩌면 거의 불가능에 가까울지도 모른다. 아예 처음부터 배우는 세대는 몰라도 기존 세대가 키보드를 바꾸는 것은 기대하기 어렵다. 아주 쇼킹하게 좋지 않은 한 아무도 바꾸려고 하지 않을 것이다. 점진적인 이전을 유도할 수 있는 호환성 모드 같은 것이 필요하다고 느꼈다.

0.95를 릴리즈한 후 웬만큼 됐다고 생각했는데 막상 사용해 보니 아직도 한참 멀었다. 어쩌면 현재 구현은 기념으로 남겨 두고 완전히 새로 만들어야 할 지도 모른다. 위 문제점 중 현재 해결 가능한 것은 엄지키를 바깥쪽으로 약간 더 이동시키는 정도이다. 그림을 다시 그려 보았다.

비록 그림이지만 인쇄해서 눌러 보면 엄지 위치가 훨씬 더 자연스럽고 엄지 좌우의 키를 누를 때도 부담이 덜해졌다. 이런 점을 미리 알아 수정했으니 시제품을 만들 때 좀 더 완벽해질 것이며 그러기 위해서 테스트를 하고 있는 것이다. 그 외에는 라벨링을 제거하거나 모드 동기화 버그를 수정하는 작업 정도가 할만하다. 나머지는 훨씬 더 장기간에 걸친 연구를 해야 한다.

연습중에 발견한 문제들에 대해 한참동안 숙고를 했다. 안타깝지만 이 문제를 풀지 못하면 아너림 키보드는 존재할 가치가 없다. 그동안 연구, 구현했던 것을 아깝다고 생각하지 말고 과감하게 수술을 해야 할 단계이다. 그 중에 기호와 숫자가 섞여서 나타나는 경우 입력이 직관적이지 못하다는 것이 가장 심각하다. 다음 코드는 실제 아너림 소스에 나타나는 구문이다.

if (c != 3) { func("ok"); }

문자, 기호, 숫자 등이 골고루 나타난다. 결코 일부러 과장한 것이 아니며 코딩중에 일반적으로 사용하는 코드이다. 웹 소스는 아마 이보다 더 복잡하면 복잡했지 덜하지는 않을 것이다. 공백은 무시하고 한글은 없다 쳐도 엄청나게 복잡하다.

영문 상태에서 계속 Sym키를 누르고 Mode 홀드도 여러번 해야 한다. 뿐만 아니라 "는 문자의 Up 영역에 있어 Up키도 눌러야 하며 영문 k도 현재 up 위치에 있다. Sym 입력후 자동 복귀하는 방식이 나름 편리하지만 3회 이상 연속되면 불편하다. 모드를 바꿔가며 입력해야 하는 불편함보다 더 큰 문제는 기호냐, 숫자냐, 구두점이냐에 따라 어떤 키를 어떻게 눌러야 하는지가 달라진다는 점이다. 키보드를 완전히 외웠다 하더라도 머리가 계속 판단을 해야 하므로 결코 쉽지 않은 입력이다.

그렇다면 쿼티 키보드는 어떨까? 쿼티도 이 정도 문장이면 쉽게 입력되지는 않으며 사실 초보자들은 엄청나게 헷갈리는 구문이다. 그러나 모드 변경없이 Shift키만 제때 눌러 주면 되고 Shift를 누른 채로 연속으로 입력할 수 있는 문자들도 많다. 무엇보다 노말 상태가 아니면 그냥 무조건 Shift이며 딱 2가지 상태밖에 없으므로 어떻게 입력해야 할지 고민할 필요없이 단순하다는 것이 장점이다.

새끼 손가락으로 눌러야 하는 Shift는 자세를 흐트리고 누르기 어려운 키라고 생각했다. 그러나 Shift 문자 여러개를 입력할 때는 오히려 이 방식이 더 편리하고 직관적이다. 또한 Shift가 양쪽에 두 개 있는 것도 꽤나 도움이 된다. 하지만 $*같이 좌우로 흩어진 문자 입력시에는 역시 불편한 면이 있다. 좌우에 있다고 해서 Shift를 누른 손을 바꿔 다시 누르지는 않으므로 손이 아주 멀리 이동한다.

현재의 구조로는 이 문제를 해결하기는데 한계가 있다. 결국 대 수술이 필요하다는 얘기인데 설계부터 해 보자. 다 갈아 엎는 한이 있더라도 이 문제는 해결해야 한다. 다음과 같은 목표를 설정했다.

1.기호들은 여기 저기 흩어두지 말고 하나의 모드에 모아 어디에 있는지 고민할 필요가 없도록 만든다.

2.Sym키 푸시는 자동 복귀하고 홀드 상태에서는 계속 입력을 받는다. 연속 기호 입력이 좀 더 편해질 것이다. 더블 푸시에 의한 고정은 딱히 필요가 없으므로 제거한다.

이를 위해서는 더 많은 키가 필요하다. 여분으로 배치했던 집게 안쪽열의 6개키를 공식적으로 도입해야 할 것 같다. 집안열 대신 1행 위에 0행키 8개를 넣을까도 생각해 봤지만 접근성이 별로 좋지 못하고 자세가 더 많이 흐트러진다. 손가락이 2칸 위로 올라가는 것보다는 집게만 한칸 안쪽으로 들어가는게 훨씬 더 쉽다. 이왕 여분으로 6개의 키를 배치해 놓았으므로 이 키들을 적극적으로 활용한다. 집안열까지 포함해서 접근 편의성은 다음과 같이 평가했다.

홈포지션이 가장 높고 중앙행 2,3이 그 다음이되 2와 3의 차이는 거의 없다. 새끼 손가락 2행은 중앙행이더라도 1행보다는 낮고 3행 아래쪽보다는 높다. 손가락을 오므리는 것보다는 뻗는 것이 더 쉽다고 생각된다. 10번 다음에는 집게 안쪽인 11번이다. 이 위치는 2행이며 집게를 약간만 움직이면 되므로 4, 8번과 비슷하되 자세가 조금 흐트러지므로 조금 낮다. 다음은 새끼 1,3행이고 마지막이 집게 안쪽의 1,3행이다. 집게가 대각선으로 가야 하므로 자세가 많이 흐트러진다. 이 위치에는 극히 저빈도의 문자만 배치할 생각이다.

집안열 6키는 여분으로 기획에 포함되어 있지만 솔직히 썩 내키지 않는다. 손가락 개수에 키의 개수를 맞춘다는 최초의 의도에서 벗어난다는 점이 마음에 들지 않으며 이렇게 되면 제자리도 아니다. 그러나 저빈도 문자를 배치하는 용도로 활용하면 제자리 우선 원칙 정도는 되지 않을까 싶다. 기호 42개는 다음과 같이 나누어 배치한다.

구두점 : . , " 3개는 문장과 같이 사용되므로 언어에 놓는다. 오른손 3행의 중,약,새끼 손가락 위치에 모아 둔다. 한영, 모두 딱 맞게 배치된다.

숫자 : 넘패드 방식으로 입력하는 것이 외우기 쉬우므로 숫자 모드에 두고 . ,는 소수점과 단위 구분자로 사용되므로 중복 배치한다.

기호 : 남은 29개는 기호 모드에 모두 배치한다. 빈도순으로 배치하되 집안열에는 빈도가 떨어지는 문자를 배치한다. 하나 남는 키는 구두점 "를 중복 배치하여 문자가 많은 타 언어를 배려한다.

Sym키의 홀드 기능이 계속 입력으로 의미가 바뀌었으므로 펑션 모드로 전환할 방법이 없다. 왼쪽 확장키의 PrtSc 자리에 두거나 아니면 왼쪽 Shift 옆에 배치할까 생각해 봤는데 좌우 대칭도 맞지 않고 어색하다. 그보다는 숫자 영역의 기호들이 비었으므로 숫자 영역에 펑션키를 배치하는 것이 좋을 것 같다. 의미상은 어색하지만 같은 숫자라는 면에서는 약간 직관적이기는 하다. 펑션키 놓고도 자리가 남으므로 집안열에 멀티미디어 키도 배치할 수 있다.

여기까지의 기획대로라면 이제 Up키는 필요가 없다. 모든 알파벳과 한글 음소들이 기본 문자 영역에 다 들어오고 기호들도 골고루 다 배분되었기 때문이다. 그렇다고 Up이 개념적으로 완전히 사라진 것은 아니다. 만약 Up 상태가 꼭 필요한 언어라면 영문의 Capital처럼 문자 영역의 별도의 키를 배치해야 한다. Up키를 제거하면 Mode가 다시 중앙으로 와야 하고 편집 모드로는 들어갈 방법이 없어진다. 이를 위해 Up키가 없어진 자리를 Edit키가 대신 차지한다. 왼손 엄지의 세 키 기능은 다음과 같이 정의된다.

	푸시	홀드	더블
Sym	기호 하나 입력	기호 계속 입력	기능 없음(이모티콘)
Mode	언어 순환	숫자 임시	숫자 고정
Edit	편집 모드 전환	편집 임시	기능 없음

펑션 모드가 사라졌고 Up 상태가 없어졌으므로 왼손 엄지키의 동작들이 단순해졌다. 기호키와 편집키는 자리를 바꿀 수도 있다. 이 3키의 동작들은 사실 쿼티의 Shift 기능을 나누어 가진 것이다. Shift는 무조건 위에 있는 문자만 선택하지만 이 키들은 각 모드의 숫자를 선택한다는 면에서 세분화 되었고 푸시하면 고정도 가능하다는 점에서 기능이 확장되었다. Shift의 대문자 선택 기능은 영문의 Capital로 옮겨졌다.

여기까지의 기획은 비교적 괜찮은 것 같으며 마음에 든다. 구현해 보면 또 다른 문제가 나타나겠지만 일단은 시도해볼만하다고 생각된다. 각 모드에 문자를 배치해 보자. 모든 모드들이 완전히 다시 배치되어야 한다. 먼저 이번 변경의 주된 원인이 된 기호 모드이다.

배치의 근거는 빈도와 유사성이다. 오른쪽에는 괄호 종류와 연산자를 모아 두었다. 왼쪽에는 빈도순인데 영어에서 많이 쓰이는 홑따옴표를 집게 2행에 배치하고 그 위에 세미콜론, 콜론을 두었다. 구두점으로 빈도가 높은 ? !도 2행 좋은 자리를 주었으며 집안열에는 빈도가 떨어지는 문자들을 배치했다. 왼쪽 아래 구석 자리에 "가 중복 배치되어 있는데 이것은 문자 영역이 넉넉하지 않은 언어를 위해서이다. 다음은 숫자 모드이다.

기존의 숫자 모드와 펑션 모드를 합쳐 놓은 것이라고 보면 된다. 집안열 집게 3행(위 그림의 Play자리)에 숫자 0을 배치해 볼까 생각해 봤는데 빈도가 높은 문자라 좀 어색하더라도 공백 자리에 두는 것이 좋을 것 같다. 마침표와 콤마는 중복 배치되어 있되 두 기호의 자리를 잠시 바꿨다가 원래대로 다시 돌려 놓았다. 다음은 한글 모드이다.

기존 배치에서 기호 하나가 더 들어옴으로 해서 약간 변경했다. 기호의 콤마를 쿼티와 같은 자리로 옮기고 제일 구석에는 따옴표를 배치했다. 따라서 ㅋ이 집안열로 밀려났다. 경음들은 집안열에 배치하되 ㄱ, ㅅ옆에 ㄲ, ㅆ을 배치하여 직관성을 높였다.

영문 모드는 집안열을 좀 더 적극적으로 활용한다. 제자리를 벗어난다는 점에서 접근성이 떨어지지만 적어도 집게 손가락 바로 옆은 3행 새끼 손가락보다는 더 높은 접근성을 인정한다. 그외 집게 대각선 아래, 위는 접근성이 더 낮다고 보고 저빈도 문자를 배치한다.

상위권은 변화가 없고 중하위권의 배치가 조금 바뀌었다. 대충 배치한 것 같지만 이 배치에도 과거의 경험과 테스트 결과에 대한 고려들이 모두 적용되어 있다. 반모음 y가 오른쪽인 이유, though 손 연타 방지를 위해 g를 오른쪽에 둔 것, have 연타 방지를 위해 v가 오른쪽에 있는 이유 등이 그렇다.

마지막으로 편집 모드는 현행대로 그냥 유지하기로 한다. 집안열이 비어 있지만 마땅히 더 놓을 키도 없고 좌우 대칭이 정확히 맞으므로 현재로서도 나쁘지 않다. 비어 있는 키는 차후 용도를 더 찾아 보기로 한다.

이 기획대로 구현한다면 기호와 문자가 섞인 다음 문장을 입력하기 편해진다. 섞여서 나타나는 것은 마찬가지이지만 =이 기호로 들어가 한꺼번에 입력할 수 있으며 "가 문자 영역으로 들어가 Up키를 안 눌러도 된다. 아직도 복잡하지만 적어도 쿼티 키보드 수준의 편의성은 충분히 확보한 것 같다.

이 설계가 과연 얼마나 유용하고 편리한지는 아직 구현해 보지 않았기 때문에 정확하게 알 수 없다. 키가 더 늘어났으므로 편의성은 분명히 증가했을 것으로 생각되지만 제자리 원칙의 일부가 훼손되었다는 점은 다소 불만족스럽다. 이대로 구현하는데는 적어도 몇일은 소요될 것 같으므로 당장 성급하게 구현해 보지 말고 기획을 좀 더 손질해보자. 당장 이대로 입력해 볼 수는 없지만 종이에 그려서라도 입력해 보고 좀 더 고민해 볼 필요가 있다.

한 열이 더 들어감으로 해서 훨씬 더 번잡스러워졌다. 대신 캡션에 숫자 모드는 굳이 기록할 필요가 없으므로 기호만 적었다. 한글과 영문도 대각선으로 배치하여 헷갈리지 않도록 했다. 다행히 엄지행의 폭이 있어 중앙에 한열을 더 놓을 공간이 충분하며 키보드 자체의 폭에는 변화가 없다. 대신 가운데 터치패드를 놓겠다는 기획은 좌우를 아주 많이 벌리지 않는 한 이제 어려워졌다.

오늘한 설계에서 한가지 더 마음에 드는 점은 이대로라면 한글 2벌식, 영문 쿼티와 키 구조가 같아서 호환 가능하다는 점이다. 한글은 아너림으로 쓰되 영문은 쿼티로 쓰고 싶다면 그렇게 할 수도 있다. 내가 원하는 바는 물론 아니지만 게임처럼 꼭 쿼티가 필요한 프로그램에서는 이것이 가능해야 하며 초반 시제품의 활용도를 높여주지 않을까 기대된다. 적어도 거부감이 들지는 않을 것이며 아너림이 마음에 안들면 쿼티로라도 쓸 수 있다.

12년 7월 3일

특허 관리비 12만 8천원 납부했다. 7월 6일이 만기라 급하게 서둘렀는데 주소가 바뀌는 바람에 돈 내는 것도 쉽지 않았다. 이번에 한번만 더 내고 내년에는 더 연장하지 않을까 싶다.

12년 7월 5일

작년 가을에 아너림 키보드를 보고 O님이 메일을 주신 적이 있다. 소프트웨어 구현만 되어 있는 것 같은데 왜 시제품을 만들지 않느냐는 것과 필요하다면 도움을 주겠다는 고마운 내용이었다. 도움을 주겠다는 것도 물론이지만 관심을 가져 주는 사람이 있다는 것만 해도 너무 너무 고마운 일이다. 하지만 당시에는 프로젝트 중이어서 짧게 인사만 나누고 만나지는 못했다.

올해 봄부터 작업을 시작하여 이제 어느 정도 모양이 갖추어진 것 같아 시제품을 만들어 보기로 했다. 그래서 O님께 메일을 보내 도움을 요청했는데 전화 번호까지 가르쳐 주며 언제든지 오라고 했다. 오늘 마침 시간이 난 김에 문자를 보내 만나기로 했다. 집에서 그리 멀지 않은 곳이라 한달음에 달려갔다.

O님은 커스텀 키보드 제작에 관심이 많고 실제로 만들어 본 적도 있어서 많은 도움을 받을 수 있을 것 같았다. 일단 키보드에 대한 설명을 죽 드리고 몇 가지 코멘트를 받았다. 3벌식 사용자인데 위에 숫자행을 하나 더 얹어도 될 것 같다고 했다. 안그래도 그래 볼까 생각했었는데 3벌식 사용자가 익숙해지면 한행이 더 있어도 불편하지 않다고 하니 용기가 생겼다.

시제품 제작에 대해서는 여러 가지 방법을 일러 주었지만 내가 워낙 하드웨어 문외한이라 다 알아 들을 수는 없었다. 대신 공부를 할 수 있는 자료 위치를 알려 주어 차후 연구해 보기로 했다. 그리고 O님이 직접 만든 키보드도 보여 주었다. 이 키보드가 나에게 감동을 안겨 주었다.

내가 원하는 사다리꼴 모양이고 밀리미터 단위로 키를 정확하게 배치할 수 있다. 이 형태대로 만들려면 기판 도면을 그린 후 업체에 요청하면 만들어 준다고 한다. 기판을 원하는 형태대로 만든 후 기계식 스위치를 납땜해서 끼우고 키캡을 덮으면 된다. 컨트롤러는 Aikon을 사용했는데 이걸 쓰면 USB로 컴퓨터와 연결하여 키입력을 전달할 수 있다.

목업만 봐서는 구체적으로 어떻게 만들어야 할지 당장 감이 잘 안오지만 이런 키보드를 만들 수 있다는 것을 알았다는 것만 해도 희망을 얻었다. 기판 설계하는 방법부터 순서대로 배워야겠다. 하드웨어에 일자 무식이라 힘들 것 같지만 마음대로 배치를 해 보려면 넘어야 할 산이다.

키보드를 보여준 후 잠시 밖으로 나와 커피 한잔을 마시며 담소를 나누다 왔다. 사람들의 습관을 바꾸는 것은 아주 어려운 일이라는 것에 대해 다시 한번 확인했다. O님은 자신이 직접 사용하기 위해 키보드를 만든다고 한다. 나도 딴 생각하지 말고 내가 쓸 키보드나 열심히 만들어 보자. 아직은 배치가 다 결정되지 않아서 당장 시제품을 만들 단계가 아니지만 이런 것도 가능하다는 것을 확인한 것이 큰 소득이다.

12년 7월 6일

대규모 기획을 했으므로 이제 구현을 해야 하는데 너무 큰 작업이라 선뜻 엄두가 나지 않는다. 이왕 왕창 갈아 엎는 김에 프로젝트를 깔끔하게 아예 새로 만들까도 생각해 봤다. 현재 프로젝트가 너무 지저분하고 최종적으로 공개할만한 퀄리티가 안되기 때문이다. 그러나 시간이 너무 많이 걸리고 앞으로도 더 지저분해질 일이 많을 것 같아 그냥 현 프로젝트를 수정하기로 했다. 기능이 웬만큼 고정되면 그때 리팩토링하자.

설계한 내용에서 일부 몇 가지를 수정했다. 중간에 이것 저것 바꿔 정확하게 뭘 바꿨는지 기억이 잘 안난다. 가장 크게 변경된 점은 한글 입력 방식을 새로 설계한 것이다. 최초 경음들을 집안열에 배치했었는데 경음들의 위치를 따로 외워야 한다는 것이 너무 불편해 보여 다른 방식을 생각해 보았다.

경음 키를 오른쪽 새끼 손가락 위치에 배정하고 이 키를 누른 채로 ㄱㄷㅂㅅㅈ을 누르면 된소리로 입력하는 방식이다. 영문의 Capital에 해당하는 키라고 볼 수 있다. 가장 빈도가 낮은 ㅍ,ㅋ만 제자리를 벗어나되 그것도 집안열중에는 비교적 자리가 좋은 곳에 배정했다. ㅋ을 왼손 집게안열 1행에 두면 완전한 좌자우모가 되지만 접근성이 좋지 않아 예외적으로 모음 영역에 배치했다. 경음키가 오른쪽에 있는 이유는 손 연타를 줄이기 위해서인데 아주 옛날의 Up키가 있던 자리이다. 별도의 경음키가 들어감으로 해서 자판이 다소 여유가 생겼다.

한글 자판을 수정한 김에 영문 자판에도 변화를 주었다. 한글의 경음키가 오른손 새끼 손가락이므로 영문의 Capital도 같은 위치에 두는 것이 좋아 보인다. 그보다 더 중요한 이유는 쿼티 호환 모드를 제공하려면 쿼티의 문자가 있는 위치에는 Capital키를 둘 수가 없다. 다행히 오른 새끼 손가락 자리가 ; 이라 딱 맞다.

앞으로도 더 바뀌겠지만 일단은 이 기획대로 구현을 해 보았다. 키맵도 완전히 뜯어 고치고 변수의 구조도 바뀌었는데 기능은 둘째 치고 너무 많이 갈아 엎었더니 제대로 컴파일도 안된다. 버그는 관 두고라도 일단은 컴파일되게 만드는 것만 해도 상당한 시간이 소요되었다. 주요 작업 내용은 다음과 같다.

-집안열을 기본 카테고리에 포함하되 조금 흐릿하게 표시함.

-Up 버튼 제거하고 Edit로 바꾸고 왼엄지열 안쪽에 배치. Mode가 중앙

-Up 상태를 Capital 상태로 대신 사용함. 한글 경음이 내부적으로 대문자 취급됨

-한영 자판을 2가지 타입으로 정의하고 키맵에 글자 배치

-경음키 배치하고 2벌식 경음도 이 키로 입력받도록 함. 경음 손연타 사라짐

-영문 쿼티의 Capital을 오른손 새끼로 옮김. L과 자리만 바꿨는데 차후 조정 예정

-Sym키 기능 변경하고 기호 모드의 문자들 재배치

-숫자 모드에 펑션키 배치. 숫자는 Mode 홀드로 변경. MODE_FUN은 제거

-새로 추가한 Edit 버튼으로 편집 모드 전환

-더블 푸시 디폴트를 400으로 조정. 실제 사용해 보니 300은 좀 어려움

-한영 자판 선택 항목 대화상자에 배치하고 실행중에 변경 가능토록함

-옵션 대화상자 일체 정리. NoUpper2Normal 같은 필요없는 옵션들 제거

-한칸 올리기 옵션은 제거할려다가 일단은 그대로 둠. 차후 정리 예정

-한손, 두손, 자판 선택 대화상자들도 모두 없애 버림

-키맵을 배열에서 그냥 구조체로 변경하고 관련 참조문 전부 수정

-집안열이 추가되어 홈 포지션 헷갈림. 초록색으로 예쁘게 강조함

여기까지 작업한 후 문제가 된 구문을 입력해 보니 한결 더 편리하게 입력 가능해졌다. 더 테스트해 봐야겠지만 일단은 비교적 만족스러운 것 같다. 코딩 완료 후 다음 작업을 추가로 더 했다.

- 2벌식과 쿼티 자판을 쓸 수 있어서 나름 호환성이 확보되었다. 그러나 자판 배치만 호환될 뿐이지 완전히 같지는 않다. 대표적으로 대문자와 된소리 입력을 위해 Cap키를 사용해야 한다는 점이 다르며 Shift키는 지원하지 않는다. 과연 호환 모드라고 해서 Shift까지 지원해야 하는지 의문스럽기는 한데 일단 옵션으로 포함시켜 두었다. Shift까지 지원되므로 그냥 기존 자판 치듯이 치면 된다. Caps Lock 상태는 여전히 무시하며 ㅒ는 ㅐ를 두 번 눌러도 입력되는 점 등도 다르다.

여기까지 작업한 결과의 그림은 다음과 같다. 배치도 바뀌었지만 엄지 안쪽의 편집, BS의 각도도 25도에서 30도로 좀 더 기울였다. 그림상으로 테스트해 보니 25도보다 좀 더 기울여야 맞는 것 같다.

새로 배치한 자판으로 스타크래프트를 해 보니 이제 저글링도 잘 만들어진다. 모든 알파벳을 원터치로 누를 수 있으므로 게임도 가능은 하다. 다만 그룹 지정을 위해 Mode키를 누른 채로 숫자를 눌러야 한다는 점이 불편하다.

배치를 싹 바꾼 것은 좋은데 이제부터 아너림 2호 키보드는 더 이상 쓸모가 없어졌다. 중앙의 여분키를 다 뽑아 버려 테스트용으로 쓰기도 힘들다. 6만원이나 하는 건데 너무 성급하게 개조를 해 버린게 아닌가 싶다. 추가된 6개 키를 복원해 보되 잘 안되면 그냥 0.95 전용 버전으로 남겨 놔야겠다.

12년 7월 7일

새로 배치한 키보드의 미세 조정이 더 필요하다. 그러기 위해서는 연습도 많이 해 봐야겠지만 수치상의 변화를 알려 주는 통계 기능의 도움이 필요하다. 통계 기능은 이전 버전을 기준으로 되어 있기 때문에 현 자판의 정확한 수치를 제대로 보여주지 못한다. 집게 손가락의 부담률이 더 증가했고 Up키는 사라져 버렸으므로 통계에서 제외해야 한다.

새로 추가한 쿼티, 2벌식 호환 자판에 대해서도 통계를 조사하도록 했으며 집게 손가락 자리는 안쪽열도 조사하되 출력할 때는 통합하여 총 비율을 출력했다. 이를 위해 내부적으로 손가락 번호를 조정하였다. 이 외에 Mode, Sym 키의 출현 빈도도 조사하려고 했으나 예외가 많아 이번에는 하지 않았다. .," 같은 기호들은 중복되어 있어 모드가 바뀐다고 보기 애매하고 공백이나 개행은 모드 전환과는 무관하다. 이런 저런 예외 다 적용해서 작성하자니 시간이 너무 오래 걸릴 것 같아 다음으로 연기했다.

구조를 바꾸느라 시간도 오래 걸렸지만 작성한 후에도 여러 가지 잔버그들이 많이 발견되어 수정했다. 하도 자주 바뀌다 보니 코드가 좀 지저분해서 통계 결과를 저장하는 자료 구조가 깔끔하지 못다다. 아직 완전히 신뢰할 수는 없지만 대충은 돌아가므로 이걸로 통계를 뽑아 보았다. 호환 모드가 들어갔으므로 이제 기존 자판과도 비교해 볼 수 있다. 다음은 한글 자판 2개를 비교한 것이다.

항목	아너림	2벌식
왼손	5:8:12:20(19+0.5)	5:10:13:19(12+7)
오른손	17(17+0.2):10:8:4	17(10+6):8:8:4
행비율	27:55:16	27:59:12
손가락 연타	7.55	4.20
손연타	26.42	24.84
좌우 분담률	48:51	46:53
좌우 분담률(엄지제외)	55:45	53:46
손가락 연타 항목	ㄱㅇ(18000) ㅅㅇ(14000) ㅏㅗ(10600)	ㄱㅎ(6700) ㄴㅈ(6600) ㄱㄹ(6200)
손연타 항목	.""(619)	.""(445)

손가락 비율과 행비율은 둘 다 적당하고 근소한 차이만 보인다. 집게가 6개의 키를 담당함에도 불구하고 별 차이가 없는 이유는 2벌식에는 빈도가 높은 ㅇ, ㅏ가 중지로 분산되어 있기 때문이다. 아너림은 집안열의 비율이 0.7%에 불과하지만 2벌식은 13%나 되어 제자리를 잘 지키지 않는다.

2벌식의 2행 비율이 좀 더 높아 집중도가 좋다. 손연타율은 비슷하지만 손가락 연타율은 아너림이 훨씬 더 높게 나오는데 2벌식은 키가 골고루 분산되어 있기 때문이다. 좌우 분담률은 둘 다 비슷한데 아너림의 왼손 부담률이 좀 더 높은 편이다. 다음은 영문 자판을 비교해 보았다.

항목	etonis	qwerty
왼손	4:8:11:14(13+1.3)	5:6:14:16(7+9)
오른손	15(11+3.7):10:10:5	14(4+10):7:12:5
행비율	30:56:12	46:33:19
손가락 연타	8.82	10.57
손연타	49.19	48.02
좌우 분담률	40:60	43:56
좌우 분담률(엄지제외)	48:51	52:47
손가락 연타 항목	hi(6800) be(5600) bu(4177)	de(19800) ce(12800) rt(7500)
손연타 항목	ble(1200) oul(754) str(741)	you(2885) ect(844) ers(820)

쿼티는 손분담률부터가 완전히 엉망이다. 오른손의 경우 중지가 약지보다 분담률이 낮으며 집게의 분담률이 높지만 안쪽열이 오히려 더 높아 홈 포지션의 이점을 거의 살리지 못하고 있다. 행 비율도 윗열에 e, t, o, i 등 고빈도 문자들이 집중 배치되어 있어 손가락이 주로 위에서 논다. 영어의 특성상 손 연타는 둘 다 거의 50%에 육박하며 좌우 분담률은 비슷하다.

연타 항목을 보면 쿼티의 손가락 연타가 좀 심하다는 것을 알 수 있다. 영문의 경우 쿼티는 선점을 했다는 것 외에 정말 별로 내세울 게 없다. 물론 아너림도 문제가 있으므로 좀 더 정밀하게 조정할 필요가 있다. b가 집게에 배치됨으로 인해 연타가 많이 발생하는데 당장은 딱히 조정할 방법이 없어 보인다.

새로 뽑은 통계를 바탕으로 자판을 재배치해 보았다. 한글의 연타 항목을 보면 아너림의 ㄱㅇ과 ㅅㅇ 연타가 너무 높게 나타난다. 이에 비해 2벌식은 ㄱㅎ과 ㄴㅈ 정도의 연타만 다소 높을 뿐 손가락이 골고루 잘 분산되어 있다. 손연타는 둘 다 좌자우모의 원칙을 지키고 있으므로 그다지 심각한 문제가 없다. 이 통계에 의하면 아너림이 2벌식보다 우월한 점이 별로 없으며 2벌식도 정말 잘 만든 자판이라는 생각이 든다. 다음은 아너림에 구현된 2벌식 자판의 모습이다.

아너림은 제자리를 잘 지키고 있다는 것과 빈도에 좀 더 충실하다는 정도를 내세울 수 있다. ㅑㅕㅛㅠ를 두번 눌러 입력하며 ㅒ, ㅖ도 Shift없이 입력할 수 있다. 2벌식과 비교해 보니 통계적인 문제가 드러나는데 보완하기 위해 아너림의 배치를 다음과 같이 바꾸었다.

왼집게의 부담을 줄이기 위해 3.15%의 ㅅ과 0.7%의 ㅊ을 교환했다. 그리고 오른 집게의 부담 감소를 위해 4.36%의 ㅗ와 2.53%의 ㅜ를 교환했다. 통계상의 변화는 다음과 같다.

- 손가락 분담율 : 5:8:12:20 - 17:10:8:4 -> 5:12:12:16 - 16:11:8;4

- ㅇㅅ, ㅗㅏ 손가락 연타가 제거되었다.

양손 모두 집게가 좀 한가해졌고 손가락 연타도 2개 사라졌다. 이대로 놓고 연습을 해 보니 와, 워 복모음 입력시 손가락 연타가 발생하지 않으며 집게, 중지의 교대여서 리듬감이 있고 속도도 더 빨라졌다. 이 변화는 정말 바람직한 것 같다. 양성, 음성 모음을 찢어 놓는 것이 좋다는 것을 알게 되었는데 그래서 다양하게 배치를 많이 바꿔 봐야 한다. ㅅ을 변방에 쳐박아둔 감이 있지만 입력해 보면 중지 아래쪽도 감이 그렇게 나쁘지 않다. 경음 입력 방법이 왼손 Up에서 오른손 경음키로 이동하면서 ㅆ을 입력할 때도 손연타가 발생하지 않아 편하다.

집게의 부담을 좀 더 줄여 주고 싶은데 이 구조에서 더 이상 줄일만한 부분이 없다. 이 상태대로 좀 더 연습을 해 보기로 하고 한동안 써 보았다. 자판 자체는 그럭 저럭 마음에 드는데 이때부터 나 자신에게 심각한 문제가 나타나기 시작했다. 자판을 여러번 바꾸다 보니 헷갈려서 도저히 타이핑을 못하겠다. 하루 이틀 겪는 문제가 아니지만 이번에는 특히 심각하다고 느낀 게 2벌식으로 놓고도 헷갈리기 시작한 것이다. 20년 이상 익숙했고 손가락이 완전히 외우고 있음에도 말이다.

역시 한번 길들여진 습관을 바꾸는 것은 엄청나게 어려운 일이다. 아마 2벌식에 익숙한 다른 사람들도 마찬가지일 것이다. 그렇다면 2벌식도 못 만든 자판이 아닌데 아예 2벌식과 최대한 호환되도록 배치해 보면 어떨까 하는 생각이 들었다. 하루 종일 이 문제로 고민을 하다가 시도해 보기로 했다. 자판을 다음과 같이 다시 배치했다.

이 배치도 한번에 나온 것은 아니며 중간에 여러 과정을 거친 것이다. 특히 격음들 위치를 많이 바꾸어 보았는데 ㅋ, ㅊ, ㅍ의 자리를 고민했다. 좌자우모 원칙과 빈도대로라면 ㅋ이 오른손 집안열로 가는 것이 맞지만 2벌식과 최대 호환을 유지하기 위해 원래 자리에 두었다. 2벌식과 비교해 보면 웬만한 주요 음소는 원래 자리를 유지하고 있으며 집안열에 있던 음소들이 주로 이동하였다.

오른손 1행의 ㅗ, ㅜ는 ㅘ, ㅝ의 손가락 연타를 피하기 위해 양성, 음성을 갈라 놓았으며 중빈도의 ㄹ이 집게로 왔으므로 3행은 고빈도의 ㅅ을 다시 가져왔다. 2벌식에 비해 6개의 음소가 자리를 바꾸었고 4개의 음소는 사라졌다. 그래서 집안열의 4칸이 빈다. 통계상의 변화는 다음과 같다. 3개의 자판을 비교해 보았다.

항목	아너림	제자리	2벌식
왼손	5:12:12:16	4:10:15:16	5:10:13:19(12+7)
오른손	16:11:8;4	16:11:8:4	17(10+6):8:8:4
행비율	27:55:16	27:56:16	27:59:12
손가락 연타	7.55	6.03	4.20
손연타	26.42	26.65	24.84
좌우 분담률	48:51	46:53	46:53
좌우 분담률(엄지제외)