Making of NewSwipe - Part 2: NewSwipe 단모음 배열의 개발 과정

안녕하세요, Alternative입니다.

한글날을 맞아, 새로운 한글 입력 시스템 NewSwipe를 출시하였습니다.

https://github.com/TechTree-Alt/NewSwipe

GitHub - TechTree-Alt/NewSwipe: Modern, lightweight, and comfortable Korean Input System.

 

이번 글에서는 NewSwipe에 기본 탑재된 'NewSwipe 단모음' 배열이 어떻게 탄생했고, 어떤 특징을 가지는지에 대해 설명하고자 합니다.

 

---

 

기본이 되는 단모음 키보드

단모음 키보드는 한글의 특성을 잘 활용해 키의 수를 줄여 작은 스마트폰 화면에서 오타를 크게 줄인 키보드입니다. 구글코리아에서 개발하여 2010년 한글날 구글 한글 입력기에 처음으로 도입되었습니다.

 

두벌식에서 변경된 주요 특징으로는

- 사용률이 낮은 ㅣ계 이중모음(ㅑㅕㅛㅠ)을 위한 키를 없애고, ㅏㅓㅗㅜ를 두 번 연달아 입력하면 ㅣ계 이중모음이 입력되게 함.

- 된소리(ㅃㅉㄸㄲㅆ)를 쉬프트 + 자음 입력이 아니라 자음을 두 번 연달아 입력하면 입력되게 함 (Shift 제거)

입니다. 

직관적이고 두벌식에서 적응이 비교적 편하다는 장점을 내세워 빠르게 보급되었고, 현재 대체 배열 키보드 중에서 높은 사용률을 보이고 있습니다.

 

그러나 단모음에도 단점이 있습니다.

- 종성-초성 겹침 문제. 자음을 두 번 연달아 입력하면 된소리가 입력되다 보니, 의도치 않게 된소리가 입력되는 경우가 있습니다. 대표적으로 '학교'를 입력하려 할 때 '하꾜'로 입력됩니다.

- 자·모음 불균형 문제. 자음 키의 갯수(14개)가 모음(8개)보다 많아 왼손이 자음을 전부 입력하기 어렵습니다. ㄱ, ㅅ, ㅎ을 입력하기 위해서는 왼손가락을 길게 뻗거나, 오른손가락으로 자음을 입력해야 합니다. 언듯 듣기에는 큰 문제가 아니지만, 실제 타이핑 시 손가락의 이동 거리와 유휴시간, 리듬을 고려하면 왼손은 자음, 오른손은 모음으로 고정하는 것이 가장 효율적입니다.

종성-초성 겹침의 경우에는 연속 입력(=된소리 입력)으로 판정하는 시간을 따로 두거나 아래로 밀어 된소리를 입력하는 등의 방법으로 어느 정도 해결할 수 있지만, 자·모음 불균형은 배열을 바꾸어야 근본적으로 해결되는 문제입니다.

따라서 자음-모음 불균형을 해소하기 위해 NewSwipe에 넣을 새로운 배열을 찾기로 했습니다.

이러한 노력을 한 배열 중 가장 유명한 것은 '무이 단모음(128) 키보드'입니다.

 

무이 단모음(128)

출처: pxd story (https://story.pxd.co.kr/)

 

무이 단모음의 개발자는 한글 각 자소의 입력 빈도를 확인해 이에 기반한 배치를 하였습니다.

주요 특징으로는

- 사용률이 낮은 거센소리(ㅋㅌㅊㅍ) 중 일부를 다른 거센소리 키에 통합하여 자음 키 수를 12개로 줄임.

- ㅂ을 3행으로 내리고 ㅈ, ㄷ, ㄱ, ㅅ를 왼쪽으로 한 칸씩 옮겨 사용률이 높은 ㄱ, ㅅ를 엄지손가락으로 입력하기 편하게 함. (→ 자·모음 불균형 문제 일부 해결)

- 모음을 일관적인 규칙을 두고 배열하여 자연스럽게 인식할 수 있게 함.

이 있습니다.

ㅌ과 ㅍ을 다른 키에 통합시키고 Shift 키 자리까지 쓴 덕분에 무이 단모음 키보드는 총 7열이 되어 키 하나의 크기가 더 커졌고, 자·모음 불균형도 어느 정도 해소되었습니다.

 

그러나 무이 단모음을 직접 써 본 결과, 기존 두벌식이나 단모음에서 넘어가기에는 적응을 어렵게 하는 요소가 네 가지나 있었습니다.

- ㅂ을 아래로 내린 것 때문에 ㅂ의 위치뿐만 아니라 나머지 1행의 ㅈㄷㄱㅅ의 위치도 전부 바뀌어 사용량이 높은 자음들이 크게 헷갈립니다.

- ㅌ을 ㅊ에, ㅍ을 ㅎ에 통합시켰는데 이 두 쌍은 서로가 아무런 음운적·원리적 연관성이 없습니다. 그저 빈도가 낮은 것이 빈도가 높은 것에 흡수되었을 뿐입니다. ㅌ이나 ㅍ을 입력해야 할 때 인지부하가 크게 걸립니다.

- 사용량이 꽤 높은 모음(ㅗㅡ)의 위치가 바뀌어 헷갈립니다.

- 지우기 키의 위치가 오른쪽 아래에서 오른쪽 위로 바뀌어 오타가 난 후 지울때조차 오타가 납니다.

이 네 가지 문제는 모두 기존 두벌식이나 단모음에 익숙해져 있는 상황에서 발생하는 것이고, 배열을 처음부터 새로 배운다고 하면 이 문제는 대부분 사라집니다. 즉, 배열 자체의 문제는 아닙니다.

그러나 두벌식, 단모음에 익숙한 사람이 많은 현실에서 무이 단모음은 학습 시간이 꽤 걸리는 키보드입니다. 저의 경우 이틀 동안 시도했지만, 키보드만 보면 머리가 아프고 답답해지는 바람에 학습을 그만두었습니다. 

 

이 경험을 바탕으로, 기존 두벌식이나 단모음 사용자도 최대한 불편함 없이 적응할 수 있으면서도 7열(자음 4열, 모음 3열)로 하고 자 · 모음 균형을 챙길 수 있는 배열이 무엇인지 고민하기 시작했습니다.

우선은 자음의 갯수를 줄이기 위해 사용률이 확연히 낮은 거센소리를 빼서 자음을 12키 이하로 만들어야 한다는 것까지는 무이 단모음과 유사했습니다. 그러나 뺀 거센소리를 어떤 식으로 입력할지에 대한 고민, 그리고 기존 단모음 키보드에서 배열에 어떠한 변화를 얼마나 주어야 할 지에 대해서 깊이 생각해보았습니다.

 

---

 

자음의 배치

우선 거센소리입니다. 아래 단모음의 히트맵을 보면 다른 키들에 비해 거센소리(ㅋㅌㅊㅍ)의 사용량이 극히 낮기 때문에 거센소리를 빼는 것이 논리적이라는 결론까지는 무이와 같았습니다.

출처: pxd story (https://story.pxd.co.kr/) 그

그러나 어떤 거센소리를 어떻게 남길지가 달랐습니다.

ㅋ의 빈도는 0.02에 불과하지만, 모바일 입력의 특성상 굉장히 빈도가 높은 ㅋ 연속 입력 초성체를 무시할 수 없었습니다. 만약 ㅋ을 다른 자음과 공유한다면 ㅋ을 연속으로 입력할 때 굉장히 불편해질 수 밖에 없습니다. 그래서 ㅋ은 독립된 키로 남겨 두기로 했습니다.

그에 반해 ㅌ, ㅊ, ㅍ은 빈도도 낮고, 기반으로 하는 연속 입력 초성체도 거의 없습니다. 다른 키에 통합되어도 무방할 것이라고 생각했습니다.

자음 4열에는 아직 거센소리를 하나 더 넣을 수 있는 공간이 있기 때문에 어떤 거센소리를 고를 지 고민되었습니다. 빈도 상으로는 미미하게 높은 ㅌ을 넣는 게 맞지만, 우선은 빠진 거센소리를 어떻게 입력할지에 대해 생각해보기로 했습니다.

거센소리는 기반이 되는 예사소리에 ㅎ이 겹쳐 들어가며 나는 강한 유기음입니다. 외관 상으로도 ㅋ의 기반은 ㄱ, ㅌ의 기반은 ㄷ, ㅊ의 기반은 ㅈ임을 쉽게 알 수 있습니다. 그러나 외관 상으로 보았을 때, ㅍ의 기반이 ㅂ이라는 것은 조금 연상시키기 어려웠습니다. 다른 거센소리의 경우 1획 추가라는 일관성이 있지만, ㅍ의 경우는 ㅂ에서 전체적인 형상과 모습이 크게 바뀌는 편입니다.

그래서 ㅌ은 ㄷ과, ㅊ은 ㅈ과 키를 공유하고, 인지 부하를 줄이기 위해 ㅍ을 독립된 키로 남겨 두기로 했습니다.

그 다음은 ㄷ, ㅈ에서 ㅌ, ㅊ을 어떻게 입력할지에 대해 생각했습니다. 기존 단모음의 원리(그리고 천지인 자판의 원리)를 따라 ㄷ을 두 번 누르면 ㅌ이 되고 세 번 누르면 ㄸ이 되는 방식이 직관적이긴 하지만, 된소리 입력까지의 과정이 너무 길고 종성-초성 겹침 문제가 남아 있습니다. 이를 해결하기 위해 NewSwipe에서는 기존에 종성-초성 겹침 문제를 해결하기 위해 있었던 아래로 밀어 된소리 입력 방식을 발전시키기로 했습니다.ㅌ, ㅊ은 각각 ㄷ, ㅈ에서 가로획 하나가 추가된 것입니다. 따라서 ㄷ과 ㅈ 키를 오른쪽으로 밀어서 ㅌ과 ㅊ을 입력하는 게 가장 직관적이고 인지 부하가 적을 것이라고 생각했습니다. 된소리인 ㄸ, ㅉ은 ㄷ, ㅈ을 아래로 밀어서 입력하는 것으로 했습니다. 기존 밀어서 된소리 입력 방식을 따라간 것이기도 하지만, 된소리 입력 후 자음 영역 위에 손가락이 남아 있으려면 가장 편한 것이 아래로 밀기라는 생각이기도 했습니다. ㄷ과 ㅈ의 경우도, 후에 서술할 배치를 한다면 오른쪽으로 밀어도 자음 영역 위에 손가락이 남아 있게 될 것입니다.

이제 어떤 자음 키들을 배치할지와 사라진 거센소리들을 어떻게 입력할지를 정했으니, 자음 키를 배치할 시간입니다.

우선 무이 단모음 키보드를 시도했을 때의 경험을 떠올려, 자주 누르는 키들은 최대한 기존 단모음의 배열에서 벗어나지 않으려 했습니다. 그래서 1열의 ㅂㅈㄷㄱ과 2열의 ㅁㄴㅇㄹ는 유지하기로 했습니다.
ㅋ은 연속 입력으로 자주 사용하게 되므로, 기존 단모음 키보드와 같은 위치인 3행 2열을 유지하였습니다.
그러면 ㅍ, ㅅ, ㅎ이 남는데, 가장 빈도가 적은 ㅍ을 엄지가 많이 움직여야 하는 3행 1열로 뺐습니다.

이제 ㅅ, ㅎ을 각각 3행 3열과 4열에 어떻게 배치할지에 대해서 생각했습니다. 이 둘은 입력 빈도가 0.12, 0.07로 낮지 않은 것에 비해 크게 움직이므로, 잘 배치하는 것이 중요했습니다.
ㅎ-ㅅ으로 하는 것과 ㅅ-ㅎ으로 하는 걸 둘 다 만들고 사용해 보았는데, 결론적으로는 기존 단모음에서 ㅅ 입력 시 엄지손가락을 가장 멀리 뻗었어야 했다는 Muscle memory를 살려 ㅅ을 3행 4열에, ㅎ은 ㅅ보다는 손가락을 적게 뻗어도 되었다는 걸 살려 ㅎ을 3행 3열에 배치하였습니다.

마무리된 자음 배치는 아래와 같았습니다.

 ㅂ  ㅈ  ㄷ  ㄱ
 ㅁ  ㄴ  ㅇ  ㄹ
 ㅍ  ㅋ  ㅎ  ㅅ

ㅈ에서 ㅊ, ㄷ에서 ㅌ이 나오는 것은 충분히 연상이 가능하다고 생각되어서, 키에 따로 표시는 하지 않기로 결정했습니다.

 

모음의 배치

자음의 배치에 꽤 많은 공을 들인 것과 달리, 모음은 그냥 기존 단모음의 배열을 그대로 유지하기로 했습니다.

이유는 두 가지입니다.
1. 자음의 배치 변경사항이 작지 않은데, 모음의 배치까지 변경하면 학습 피로도가 급격히 올라갑니다.
2. 다양한 배치를 강구해 보아도, 3행의 구조를 깨지 않는 한 명확히 논리적이거나 필연적인 배치는 없었습니다.

새로운 배열은 최대한 기존 단모음에서 넘어오기 어렵지 않게 하는 것이 핵심이었기 때문에, 모음까지 바꾸는 것은 포기하였습니다.

대신 여전히 남아 있는 자음과 모음 간 영역 차이(자음은 4열, 모음은 3열)를 줄이기 위해, 자·모음 균형 레이아웃을 고안하였습니다. 자음 영역과 모음 영역의 넓이를 같게 만드는 것입니다. 기존 단모음에서는 자음이 5열이나 되었기 때문에 두 영역을 같게 만들면 자음 키가 너무 작아졌지만, 자음이 4열이 된 키보드에서는 두 영역을 같게 만들어도 키의 크기 차이가 크지 않고, 왼쪽 엄지손가락의 Reachability도 크게 늘어날 수 있었습니다.

 

결과

결론적으로 완성된 키보드의 배열은 아래와 같았습니다.

 ㅂ  ㅈ  ㄷ  ㄱ |  ㅗ   ㅐ   ㅔ
 ㅁ  ㄴ  ㅇ  ㄹ |  ㅓ   ㅏ   ㅣ
 ㅍ  ㅋ  ㅎ  ㅅ |  ㅜ   ㅡ   ⌫

 

기존 단모음과의 유사성이 자음의 경우 66%, 모음의 경우 100%이기 때문에 적응이 어렵지 않습니다.

저의 경우 약 3일 후 적응을 완료했습니다.

 

확실히 느껴지는 장점으로는 키 크기, 특히 모음 키 크기가 커졌기 때문에 장시간 타이핑 시 피로도가 확실히 덜해졌습니다.

특히 거센소리(그 중에서도 ㅊ, ㅌ)가 포함되지 않은 85%의 단어/문장을 타자 칠 때 종전보다 확연히 빠른 속도로 타자가 가능해졌습니다.

또한 왼손가락은 자음, 오른손가락은 모음으로 역할이 확실히 정해지다 보니 리드미컬한 타이핑이 가능해져 빠르게 타자를 칠 때 순서가 꼬이는 일이 많이 줄었습니다.

ㅅ, ㅎ을 누를 때 훨씬 편해진 점도 은근히 체감되는 부분이었습니다.

 

단점으로는 아무래도 ㅊ, ㅌ이 포함된 단어를 칠 때 초반에 멈칫거리게 되고, 오른쪽으로 미는 동작이 어느 정도 익숙해진 다음에도 흐름이 끊기는 느낌이 듭니다. 특히 ㅊ, ㅌ이 없는 단어를 칠 때의 타이핑 속도가 올라갔다 보니 상대적으로 체감이 되는 부분으로, 마치 과속방지턱을 넘는 느낌이 듭니다.

된소리 5인방 중 ㅅ만 맨 아래로 이동했다 보니 ㅆ을 입력할 때 조금 어색하게 느껴지는 부분도 있었고요.

기존 단모음에서는 빈 자리로 비워놓았던 ㅋ 왼쪽에 ㅍ이 생겼는데, 원래 빈 자리였어서 그런지 ㅍ을 사용하려 할 때 멈칫하게 되는 것도 체감이 꽤 됩니다.

(의외로 ㅅ, ㅎ의 바뀐 위치는 빠르게 적응할 수 있었습니다.)

 

---

 

지금까지 NewSwipe 단모음을 만들기까지의 생각 과정이었습니다.

기존 단모음 방식을 최대한 유지하려고 한 만큼, 타이핑이 확연히 빨라졌다거나 동선이 고도로 최적화된 배열은 아니지만 적응하기 편하면서도 이득이 있는 배열이라고 생각합니다.

이러한 개발 기록이 누군가에게 도움이 되었으면 좋겠습니다!