보다시피 요즘 운동을 빙자한 등산과 여행을 많이 다니느라 올해 상반기엔 프로그램 개발이 많이 더뎠다. 그래서 이번엔 4개월이라는 시간 동안에 버전을 0.1밖에 못 올렸다.
그 와중에도 개발 아이디어는 계속 떠올라서.. 8.x 중후반 정도까지 갈 것 같던 버전업 이정표가 9.0까지는 너끈히 갈 지경이 됐다. 이게 불행인지 다행인지.. 참 총체적인 난국이구나.
입력기와 타자연습의 변화 사항은 지난달에 공지한 것 그대로이고 더 변한 게 없다. 그러니 이전 글을 참고하면 된다. 이벤트 처리 수식은 글쇠배열의 추가 옵션으로 이렇게 깔끔하게 구현됐다. 옵션 3개밖에 없던 대화상자가 옵션이 8개로 늘면서 덩치가 제법 두툼해졌다.
그러니 여기서는 이벤트들 중 "문자 연속 입력 단절 감지하기"라는 개념에 대해서만 추가 설명을 좀 하겠다.
<날개셋> 한글 입력기는 지금까지 전통적으로 조합 상태 여부에 따라서 동일한 글쇠가 서로 다른 문자를 입력하거나(T변수), Bksp가 서로 다른 단위로 한글을 지우는(글자 or 낱자) 것을 지원했다.
그런데 이번 8.5에서는 이에 덧붙여, 굳이 한글이 아니더라도 일명 '타이핑'이라고 불리는 연속된 문자열 입력을 시작했는지, 아니면 그게 단절됐는지 그 타이밍을 알 수 있게 했다. 이것은 굉장히 의미심장한 새로운 기능이다.
연속 입력의 단절은 마우스 클릭이나 화살표 키로 cursor의 위치가 일괄 변경됐을 때, 윈도우의 키보드 포커스가 바뀌었을 때 같은 외부 요인에 의해 발생한다. 텍스트 에디터/워드 프로세서들은 undo도 연속된 문자열 입력은 한번에 없애 버리지만, 이런 단절이 일어나면 보통 undo 단위를 분리한다.
그러니 연속 입력이라는 건 이 undo 단위와도 완전히 같지는 않지만 얼추 비슷한 개념이다. 또한, 한글이 입력(=조합) 중이라면 응당 문자 연속 입력 중이지만, 문자 연속 입력 중이라고 해서 반드시 한글 조합 중인 것은 아닌 것으로 관계가 성립한다.
8.5에서는 Backspace 동작방식 설정 대화상자가 아래와 같이 바뀌었다. 제1동작과 제2동작을 세로로 배열하던 걸 가로 형태로 바꿨기 때문에 대화상자가 예전보다 좀 커졌다.
이번에 새로 추가된 기능은 '연속 입력 상태 여부'이다.
이전 버전까지는 오로지 '한글 조합 중 여부'에 따라서 제1동작(조합 중일 때)과 제2동작(그렇지 않을 때)을 구분했다. 거기에다가 '한 번 정해진 동작을 계속 적용'하는 옵션 하나만이 지원되었다. 이 옵션을 켜면 1과 2 중 한번 정해진 동작이 Backspace를 연타하는 동안 계속 유지되었고, 그렇지 않으면 이전 Backspace의 결과로 인해 한글 조합 여부가 달라지기만 해도 동작 방식이 바뀌었다.
그런데 상태 판단 기준을 '연속 입력 상태 여부'로 바꾸면, 조합 상태를 막론하고 연속 입력 중일 때는 제1동작이 선택되고, 그렇지 않으면 제2동작이 선택된다. 굳이 Backspace만을 연타하고 있지 않아도, 당장 한글을 조합 중이지 않아도 타이핑 중이라면 낱자 단위로 지우고 달라붙기 기능 같은 걸 쓰고 싶다면 이 기능이 굉장히 유용하게 쓰일 것이다. 즉, 한 Backspace 동작의 지속성은 '연속 입력 상태 여부'가 가장 길고, 그 다음이 '조합 여부 + 연타'이며 제일 짧은 건 그냥 '조합 여부' 옵션인 것이다.
그럼 이 '연속 입력 상태' 정보를 Backspace에서만 활용 가능한가 하면 물론 그렇지 않다. 지우기뿐만 아니라 입력에서도 활용 가능하다.
다만, 연속 입력 상태라는 아무래도 한 글자 입력이라는 단위를 초월하는 영역의 정보이다. 그렇기 때문에 이건 <날개셋> 한글 입력기를 사용하는 구현체가 공급해 주지, 한글 입력기가 직접 관리하고 있지는 않는다.
글쇠배열 수식에서 T 변수는 "지금이 조합 중인가?"를 나타내는데, 그런 것처럼 "지금이 연속입력 상태인가?" 같은 정보가 변수로 따로 주어지지는 않는다. 단지, 연속입력 단절이 발생했을 때 이벤트가 발생하고, 그 이벤트 때 특정 수식을 실행시킬 수 있다. 여기서 뭔가 사용자 변수(소문자)의 값을 변화시켜서 그 값의 변화를 감지함으로써 연속입력 단절을 간접적으로 알 수 있다. 이 수식은 글쇠배열의 추가 옵션 대화상자에서 설정 가능하다.
세벌식 글쇠배열과 관련해서 내가 당장 머리에 떠오르는 활용 방법은 최종 배열에 있는 쉼표와 마침표이다.
쉼표와 마침표는 평소에 문장 부호로 많이 쓰이지만 자리수 구분이나 소수점 때문에 숫자 입력 중에도 많이 쓰인다. 그렇기 때문에 Shift를 누른 상태에서도 계속 그대로 입력 가능한 게 좋다. 하지만 그런 제한된 경우 말고 평소에 쉼표와 마침표가 한 글쇠배열에 중복 등재되어 있는 것은 낭비이다.
마치 / 자리에 /와 ㅗ를 조건부로 모두 배당하는 것처럼, Shift+쉼표/마침표는 숫자를 연속 입력하는 중일 때에만 쉼표와 마침표가 찍히고, 나머지 상황에서는 다른 기호나 특수글쇠가 입력되게 할 수 있다. '공통 전처리'와 '연속 입력 단절 이벤트' 수식에다가는 어떤 소문자 변수 플래그를 끄고, 숫자가 입력된 직후에는 그 플래그를 켜게 해서 Shift+쉼표/마침표는 그 플래그의 존재 여부에 따라 서로 다른 문자가 입력되게 하면 된다.
이거 작업을 하면서 Backspace 설정을 저장하는 방식이 바뀌었다. 8.5에서 저장한 입력 설정은 8.4 등 이전 버전에서는 Backspace 옵션이 보존되어 있지 못할 것이다.
그럼 새 기능 소개는 이 정도로 마치고, 지금부터는 미래의 떡밥이랄까 썰이나 좀 나누고자 한다.
썰1. 제5의 빠른설정
<날개셋> 한글 입력기에 '빠른설정'으로는 두벌식/세벌식, 쿼티/드보락이라는 가장 널리 쓰이는 글쇠배열을 낱자 결합과 오토마타까지 한번에 세팅해 주는 '기본 글자판 설정'이라는 게 3.0 시절부터 존재했다. 그 뒤엔 복벌식· 신세벌식과 한글 로마자 입력 방식을 세팅해 주는 추가적인 빠른설정이 2006년에 나온 3.9에서 추가되어 이 형태가 지난 10년 간 유지돼 왔다. 그 뒤, 이번 8.5의 바로 다음 버전에서는 아주 중요한 빠른설정이 하나 더 추가될 예정이다.
내 프로그램 내부에서는 낱자 결합 규칙이라는 걸 오로지 A+B → C 한 형태만을 규정하고 있다. 그러나 한글 입력 방식에서 낱자 결합 규칙이라는 건 한 낱자를 만드는 미시적인 규칙과, 낱자와 낱자를 결합해서 겹낱자를 만드는 거시적인 규칙으로 구분되는 경우가 대부분이다.
PC에서야 키보드에 글쇠 수가 충분히 많으니 어지간한 낱자는 한 타 만에 바로 입력되고 미시적인 규칙은 별로 중요하지 않다. 그러나 글쇠 수가 매우 적은 모바일용 입력 방식에서는 ㅁ+가획 → ㅂ(나랏글), ㅇ+ㅇ → ㅁ(천지인) 같은 미시규칙이 제각각이고, 그 반면 거시규칙은 어느 입력 방식이나 차이가 없다. ㅂ이나 ㅅ 각각의 낱자를 어떤 방식으로 입력하건 겹받침 ㅄ의 입력은 가능해야 하며 ㅂ+ㅅ의 결합으로 ㅄ을 입력한다는 건 변함없다는 뜻이다.
그리고 도깨비불 현상은 미시규칙이 아니라 언제나 거시규칙 단위로 발생한다. ㅄ은 ㅂ과 ㅅ으로 분리되지만 ㅂ이 ㅁ과 가획으로 분리되지는 않으니 말이다. 그리고 휴대전화 입력기들은 backspace도 각각의 입력 단계가 스택에 저장되는 게 아니라 저 거시규칙 단위로 적용되는 편이다. 이런 미시/거시규칙 구분이 없이 정말 임의로 특수 도깨비불을 처리해야 하는 입력 방식은 한글 로마자 방식 정도밖에 없다(ch, l, x 등;;).
물론 <날개셋> 한글 입력기는 특수 도깨비불 규칙과 결합 축약 규칙들을 이용해 저런 동작들을 모두 구현할 수 있다. 그러나 사용자가 거시구조 단위에서 발생하는 파생 동작을 미시적으로 일일이 다 세팅을 해 줘야 한다. ㄶ, ㅀ의 입력을 구현하기 위해 나랏글이라면 중간의 ㄴ+ㅇ, ㄹ+ㅇ 같은 가상의 상태를 모두 넣어야 하고 그런 임시 낱자는 가상 낱자에다 한글 출력 치환까지 써서 표현하는 방법을 정해 줘야 한다. 일종의 노가다이다.
'초· 종성 공유 낱자 결합 규칙' 옵션을 쓰면 초성에는 미시규칙만 존재하고 종성에는 이를 바탕으로 최대 2단계의 거시규칙이 존재하는 일종의 'special case'에만 한해서 위의 작업들을 모두 자동화할 수 있다. 현대 한글을 입력하는 대부분의 휴대전화 입력 방식들이 이 기능의 혜택을 입을 수 있다.
그러나 옛한글까지 동원되면 어떨까? 초성과 종성에 서로 다른 거시규칙이 적용돼야 하고 그 단계수도 3단계까지 있을 수 있는데 이건 답이 없다.
이럴 때 미시규칙으로부터 거시규칙을 곱한 product들을 자동으로 관리하고 가상 낱자, 특수 도깨비불, 낱자 축약, 다단계 낱자 분리 등의 규칙들을 임시 낱자까지 감안하여 일관되게 자동으로 생성해 주는 것이 제5의 빠른설정이 하는 일이다.
제5의 빠른설정은 종성을 입력하는 중에 종성에 존재하지 않는 초성을 입력하려는 시도가 감지됐을 때(예: 옛한글의 정치음· 치두음) 이것을 종성에다 임시로 표현하거나 아니면 초성으로 옮겨 준다.
그리고 '허용 한글 범위' 제약에 걸리지만 중간 과정에서 불가피하게 입력되는 글자들을 자동으로 찾아 주며(예: '썅'을 입력하는 과정에서 '쌰'를 불가피하게 입력해야 하므로),
종성-초성 음절간 연속입력이 불가능한 경우는 말할 것도 없고 미시결합과 거시결합이 충돌하는 경우를 모두 찾아 준다(예: 천지인에서 ㅝ와 ㆌ는 입력 순서가 동일하기 때문에 충돌함)
그야말로 <날개셋> 한글 입력기가 지금까지 꾸준히 추가해 온 복잡한 고급 기능들을 총괄제어하는 끝판왕이 될 것이다.
썰2. 한자의 추가 지원 가능성
말이 나왔으니 말인데..
<날개셋> 한글 입력기는 공식적으로 유니코드의 BMP(기본 외국어 평면) 영역에 있는 28000여 자의 한자에 대해서 독음과 부수에 의한 입력을 지원한다. 한중일 통합 한자, 호환용 한자, 그리고 확장 A까지이다. 그 이상 확장 B부터는 지원하지 않고 있다.
물론 유니코드에 등록된 모든 한자들은 부수, 획수, 음 같은 기본적인 신상 정보가 Unihan이라는 이름으로 인터넷에 공개돼 있기 때문에 소프트웨어 개발자들이 이를 활용 가능하다. 그러나 <날개셋> 한글 입력기에서 유니코드의 모든 한자들을 그렇게 지원하는 것은 현실적으로 쉽지 않으며, 그래야만 할 필요도 없다.
그도 그럴 것이 확장 B부터는 코드 번호가 16비트 범위를 초과하는 surrogate 영역에 있기 때문이다. 이것까지 받아들이려면 한자 처리와 관련해서 16비트 크기를 전제하고 만들어진 파일 구조나 API를 여러 군데 확장해야 한다. 단순히 데이터만 추가로 집어넣어 주면 되는 게 아니라는 뜻이다.
그런데 그 확장 작업이 꼭 필요할 정도로 명분과 가성비가 성립하느냐 하면 그렇지 않다. 내 프로그램은 엄연히 중국어 입력기가 아니라 한글 입력기이고, 한국어 문화권에서는 이미 있는 BMP 영역의 확장 한자도 일상생활에서 거의 쓸 일이 없기 때문이다.
괜히 쓸데없이 한자 후보 목록만 복잡하게 만들고 목록을 불러오는 시간을 잡아먹는다고, 평상시에는 이미 있는 것조차도 오히려 숨기고 4888자 상용 한자만 불러오게 하는 옵션이 따로 있을 정도이다.
독음 입력의 경우 확장 B까지 추가되면 '가, 이, 사' 같은 음은 정말 헬게이트 수준으로 딸려 나오는 한자 후보가 너무 많아질 것이고, 무엇보다도 이런 한자들의 한국어 한자음은 누가 무슨 근거로 제정하느냐 하는 문제가 생긴다. 본인은 이와 관련된 자료를 지금까지 접하지 못했다. 이제 surrogate에 있는 한자들은 현대 중국어에서 막 쓰인다기보다는 그냥 옛 문헌에서나 아주 가끔 등장한 레어템 벽자(僻字)들이거나, 아니면 어디서 인명용으로 인위로 만들어진 듣보잡 글자들이 아닐까 생각도 한다.
다만, 한글 독음은 그렇다 치더라도 '부수로 한자 입력' 기능은 그래도 확장 B의 모든 한자를 입력할 수 있으면 좋긴 하겠다는 생각을 한다. 물론 이건 언제까지나 '한글' 입력과 관련된 다른 기능들이 모두 구현되고 완성된 뒤에나 해 볼 만한 생각이다. 우선순위가 아주 낮은 희망사항일 뿐이다.
한자는 현재 전세계에서 현역으로 쓰이고 있는 문자들 중 유일한 표의/표어문자이며, 정말 다른 문자들은 엄두도 못 낼 엄청난 양의 글자 수를 자랑하고 있다. 자세히 뜯어 보면 한자도 정사각형 안에서 뭔가 심오· 오묘한 제자 원리를 갖추긴 한 듯하지만, 근본적으로 배우기가 너무 어렵고 숫자로 치면 아라비아 숫자가 아니라 로마 숫자 같은 접근을 한 문자이다.
문자라는 게 정해진 유한한 틀과 체계가 없이 중구난방으로 임의 생성이 가능하다면 그건 엄밀히 말해 문자가 아니라 아직 그림의 범주를 못 벗어난 상태가 아니겠는가? 문자표에서 끝도 없이 펼쳐져 있는 한중일 통합 한자 리스트를 보면.. 뭔가 참 막막하다는 느낌이 든다.
썰3. 파일 포맷이 또 바뀐다면?
<날개셋> 한글 입력기가 현재 사용하는 입력 설정 파일 포맷은 2008년에 나온 5.0 버전 때 큰 틀이 잡혀서 지금까지 이어지고 있다. 3.0 방식이 나온 이후로 4년 만에 바뀐 것이다.
이 포맷은 압축을 하지는 않지만(어차피 무슨 이미지나 문서 포맷도 아니고 파일 크기가 굉장히 작음..) 날개셋문자 수식 같은 정보들을 최대한 조밀하게 기록하고 나름 확장성도 생각해서 설계되었다. 하지만 긴 세월이 흐르면서 새로운 chunk들이 덕지덕지 추가되면서 내부 구조가 좀 지저분해져 있긴 하다.
유니코드에 한글 자모가 더 추가되어서 내부 자모 순서가 재조정되는 이변이라도 발생하지 않으면 이 파일 포맷이 가까운 미래에 또 바뀔 일은 매우 희박하다.
만약 파일 포맷을 바꾸게 되면, 그때는 지저분한 chunk들을 정리하고 다음 사항을 반영하려 한다.
첫째, 내부에 저장되는 데이터 중 (1) 한글 입력기의 동작을 실제로 바꾸는 설정/옵션과, (2) 동작에 영향을 주지는 않지만 사용자에게 표시되는 데이터(후보 설명문 같은), (3) 제어판을 열지 않은 이상 사용자에게 전혀 보이지 않는 단순 주석 데이터(오토마타 상태 설명문 같은) 영역을 더 엄격하게 구분해서 필요하다면 (2)나 (3)은 손쉽게 생략 가능하게 할 것이다.
둘째, 이때쯤 수식에 ++와 -- 단항 연산자를 추가해 넣을 의향이 있다. C언어가 제공하는 것처럼 전위형과 후위형 모두 말이다. <날개셋> 한글 입력기의 수식은 C언어 스타일이지만 이런 단항 증가/감소 연산자를 현재 지원하지 않기 때문이다.
이 연산자가 제공되지 않은 이유는.. 단항 연산자는 프로그래밍에서 반복문을 구현할 때 사실 가장 많이 쓰이는데 내 프로그램의 수식은 그렇게 프로그래밍까지 가능한 환경이 아니기 때문이다. 그리고 사용자 변수라 하더라도 한도 끝도 없이 1씩 증가/감소시키는 것보다는 a=(a+1)%N처럼 순환을 전제로 하는 증가가 더 많이 쓰이기 때문이다. 이런 여건을 감안했을 때 ++와 -- 연산자는 딱히 유용하지 않다고 판단되어서 넣지 않았다.
사실, 먼 옛날에는 +=, -= 같은 합성 대입 연산자조차 지원하지 않았다가 지난 4.4 버전에서 10종이 대거 추가되었다. 가감승제 4, 나머지 1, 비트 3 (and or xor), 비트 좌우 이동 2 이렇게 총 10종류이다.
내 프로그램은 내부적으로 연산자의 식별 번호를 우선순위 순으로 부여하고 있는데 새로 추가된 연산자들은 메모리에 저장되는 코드값과 디스크에 이미 저장된 코드값이 달라서 번거롭게 보정을 해 줘야 했다. 마치 문자의 코드값과 사전 배열 순서가 동일하지 않게 되는 것처럼 말이다.
3.x 파일 포맷에서는 합성 대입 연산자들이 나중에 추가된 관계로 그런 보정이 존재했지만, 5.0에서 파일 포맷이 바뀔 때 연산자 저장 방식을 동기화시켰다. 지금 또 연산자가 추가되면 나중에 파일 포맷이 바뀔 때 새로운 순서가 반영될 것이다. ++와 --는 고려 대상이긴 하지만 위에서 언급한 이유도 있고 해서 우선순위가 막 높지는 않다.
썰4. 게임 체계의 개편
예전에 말한 적이 있나 모르겠는데.. 장기적으로는 현재 타자연습에 있는 게임도 체계를 크게 고치려 생각 중이다.
방어력 업그레이드를 없애고, 둠/퀘이크의 아머 내지 스타크래프트의 실드 같은 보조 맷집 정도만 넣지, HP와 관련하여 그 이상 더 복잡한 다단계 체계를 두지는 않을 것이다. 체력을 100 이상으로 비정상적으로 많이 비축해 놓을 수 없게 할 것이다.
그 대신 체력 보충 바이러스가 더 자주 나오고 위력이 강해진다. 한 번만 받아도 어느 주인공이든 전체 체력의 절반이나 전부가 곧장 회복된다. 어려운 레벨에서는 죽기 직전이 됐다가 바이러스 한 방 먹고 살아나는 스릴이랄까 '들쭉날쭉' 기복이 더 커진다. 이를 위해 어쩌면 레벨의 난이도를 지금보다 더 낮출 수도 있다.
현재의 게임 체계는 레벨 1부터 시작해서 체력과 방어력 업그레이드를 무슨 경험치처럼 채워야만 상위 레벨에서 버티기가 더 수월해지는 구조이다. 이걸 타파하려 한다.
주인공들 중 '한별'은 오타 페널티가 있는 대신 저렇게 맷집을 축적하는 게 가장 유리한 주인공이었다. 그 메리트가 없어지는 대신, 점수가 가장 높다거나 다른 방법으로 보상을 줄 생각이다.
한별은 어려운 대신에 잘 다루면 가장 강력한 주인공이고, 미르는 오타를 내도 되는 대신에 다른 페널티가 큰 주인공, 그리고 아름은 그 중간.. 이 구도는 변함없이 유지된다.
그런데 떨어지는 단어를 쳐서 없애는 게임에서 현실적인 변수는 저런 타자의 용이성과 체력 맷집밖에 없는데.. 체력 맷집 체계를 단순화· 평준화시키고 나니 다른 방법으로 주인공별 차별화를 어떻게 시킬지가 고민이다.
현재로서는 머리가 아파서 구상 단계에 머무르고 있다. 아이고~ =_=;;
Posted by 사무엘
