날개셋 한글 입력기 8.9는 지난 8.8과는 달리 딱히 치명적인 버그가 발견된 게 없고 잘 만들어져 있다. 한편으로 다음 버전인 9.0은 현재 이렇게 순조롭게 개발되고 있다.
0. 한글 공식 명칭에서 <> 제거
이 시간부터 내 프로그램의 공식 명칭은 그냥 '날개셋 한글 입력기'임을 밝힌다. 날개셋이라는 단어를 감싸는 화살괄호(angle bracket)를 쓰지 않기로 했다. 프로그램의 모든 UI와 도움말, 각종 예제 파일, 홈페이지에서 이걸 이미 제거했다. 프로그램이 완성되는 날, 웹에다가도 업로드해서 반영만 하면 된다.
몇 년 전에 한번 얘기한 적이 있지 싶은데 검색하기가 귀찮다.
세벌식 최종은 타 한글 글쇠배열과는 달리 가운뎃점이 있으며, 화살괄호(컴퓨터에서는 그냥 부등호일 뿐이지만..)가 아랫글쇠(non-shift)에 있다. 하지만 날개셋 한글 입력기 1.0이 최초로 개발되던 시절에 여전히 많이 쓰이던 Windows 95는 비록 공식적으로 최종을 지원했음에도 불구하고 마소 직원의 무지(?)로 인해 기호의 배열에 틀린 게 굉장히 많았다. 그래서 화살괄호조차도 원래 의도했던 방식으로 입력할 수 없었다.
그래서 결국 허접하게나마 내가 입력기를 직접 만들고 나니 가운뎃점이고 참고표고 화살괄호고 다 제대로 입력이 가능했다. 그 당시엔 그것 하나만으로도 참 감격스러워서 뒷일을 별로 생각 안 하고 프로그램 브랜드명에다가도 화살괄호를 쌌다. 아래아한글이 고유명사에다가 옛한글을 쓴 것처럼 뭔가 튀어 보이는 효과는 덤이고 말이다. 그게 사건의 전말의 전부이다.
하지만 고유명사의 내부에 문장 부호가, 그것도 dash 정도의 작은 물건도 아니고 아예 여닫는 pair가 존재하는 놈이 끼어들어 있는게 그리 보기 좋지는 않다. 아래아한글도 옛한글을 표현할 수 없는 환경에서는 '한/글'이라는 대체 표기가 쓰이는데, slash는 그 자체가 디렉터리 같은 토큰 구분용으로 쓰이는 문자이기도 하니 이 역시 그리 보기 좋은 표기는 아니다.
또한 화살괄호는 컴퓨터 키보드로 칠 때는 의미가 완전히 다른 부등호가 돼 버리며, 명령 프롬프트에서는 도스와 유닉스를 막론하고 redirection 기호로 쓰여서 파일명에 들어갈 수 없고.. HTML 태그를 여닫는 기호이기도 해서 본문에 간단히 삽입할 수도 없다. 이 때문에 지금처럼 공식적으로 화살괄호를 제거하기로 결심하기 전부터도 내 프로그램의 명칭은 화살괄호가 빠진 형태로도 암묵적으로 많이 쓰이고 있었다. 이제 본인은 그렇게 간소화된 명칭만을 사용하기로 했다.
지난 7.0에서는 프로그램의 얼굴이라 할 수 있는 아이콘이 대거 바뀌어서 지금에 이르고 있는데, 그로부터 4년 뒤인 9.0에서는 프로그램의 이름 표기가 바뀌는 큰 변화를 겪게 되었다. 나름 의미 있는 변화이다.
1. 복합 낱자 입력 로직 생성기: 허용 한글 범위 제약 기능 + 오토마타 연동
복합 낱자 입력 로직 생성기는 날개셋 한글 입력기 8.x대 후반, 그리고 본인의 박사과정 연구 기간의 대미를 장식한 그야말로 엄청난 핵심 기능이다. 나로서는 정말 엄청난 시간과 노력을 들여서 구현해 냈고 논문도 썼다. 그래서 주요 기능들이 잘 완성됐으며 동작에 딱히 심각한 버그도 없긴 하지만, 이번 9.0에서는 '허용 한글 범위 제약' 기능과 연계하는 기능들이 또 추가되었다. 허용/금지 등 등급별로 분류된 글자들을 날개셋 한글 입력기의 오토마타와 연계하여 재미있는 오덕질을 하는 옵션인데, 다음과 같은 것이 있다.
(1) 먼저, 허용되는 글자 중에서 더 결합의 여지가 없는 단말(terminal) 글자에 도달한 경우 자동으로 조합을 종료하는 옵션이다.
예를 들어 '고'라는 글자는 ㅏ를 결합해서 '과'가 될 수 있고 종성과 결합해서 '곡', '공' 같은 글자가 될 수도 있다. '안'이라는 글자도 '앉'이나 '않' 같은 글자로 추가 결합이 가능하다. 그러나 '엌', '같' 같은 글자는 더 결합이 이뤄질 게 없다. '판'이라는 글자도 KS X 1001 하에서는 '안'과는 달리 겹받침이 붙을 수 있는 게 없다.
이런 글자를 terminal로 간주하며, 이게 만들어지는 순간 조합을 종료하는 것이 이 기능의 핵심이다. 조합을 미리 끊든 말든 사용자의 타자 행동이 달라지는 건 없지만, 이것이 지금 입력 체계 하에서 더 결합의 여지가 없는 단말 글자였다는 시각· 심리적인 피드백을 준다. 이런 것도 날개셋 한글 입력기로 구현 가능하다는 데모 차원에서 옵션을 구현했다.
'허용 한글 범위 제약' 기능을 사용하면 이 프로그램은 일단 입력 가능한 글자들을 받아서 입력을 위해 추가로 허용해야 하는 글자를 수집하고, 글자가 완성된 뒤에 연속 입력을 위해 다단계 분리 처리를 해야 하는 글자도 제3 그룹에다 수집해 준다. 이 글자들은 기존 허용 글자들의 밖에 존재하는 것들이다. (1은 무조건 허용되는 글자, 2는 무조건 실패하는 글자로 용도가 예약됨)
그런데 이 옵션을 사용하면, 기존 입력 가능 글자들 "중"에서 terminal에 속하는 글자들을 제4 그룹에다가 따로 모은다. 그래서 지금까지 오토마타에서 T==3에 대해 다단계 분리 -12를 적용하듯이 T==4에 대해서는 이미 있는 기능인 -3 (결합 후 조합 중단)만 지정하면 일이 깔끔하게 끝난다.
terminal 감지는 두벌식에서는 그렇게 의미 있는 기능이 아니다. 종성이 있는 글자는 그 종성의 일부나 전부가 다음 글자의 초성이 될 수도 있으니 도중에 조합을 끊어서는 절대로 안 된다. 하지만 종성이 없는 글자 중에서도 '긔, 꾜, 뀨, 눼, 댜, 듸, 쮸, 켸, 쿄' 등 terminal이 20여 자 있다. 이 글자들 이후에는 종성이 이어지는 게 전혀 없으니 두벌식에서도 조합을 바로 끊어 버려도 안전하다.
얘들은 '쌰, 쓔, 뢔, 쬬' 같은 고아 글자와는 성격이 정반대이다. 고아 글자들은 받침이 붙은 '썅, 쓩, 뢨, 쭁'은 KS X 1001에 있는데 받침이 빠진 형태가 빠진 경우이고, 모음 terminal 글자는 자신 이후로 아무 받침이 붙지 않는 경우이니 말이다. 어쨌든, 고아 글자를 찾는 기능이 있으니 terminal을 찾는 기능도 있어야 한다는 생각이 들어서 잠시 시간을 내어 이 기능을 구현하게 됐다.
세벌식으로는 terminal 감지 기능이 제 기능을 발휘할 수 있다. 그 극단적인 경우는 현대 한글 기준으로 모든 받침을 1타 만에 입력 가능한 최종(391) 글쇠배열이다. 받침을 찍는 순간 글자가 완성됨과 동시에 그냥 조합이 종료돼 버린다. 물론 이렇게 테이블을 참조할 필요조차 없는 일방적인 경우라면 아예 오토마타 수식을 고쳐 버려도 되지만 '안'일 때만 조합이 유지되고 '판'일 때는 조합이 끊어지게 하려면 이 기능을 사용하면 된다.
(2) 그 다음으로, 허용되지 않는 글자를 만드는 낱자는 다음 글자로 보내는 게 아니라 그냥 무시하는 옵션이 있다. '또+ㅁ'의 경우 ㅁ을 다음 글자로 보내는 게 아니라 그냥 무시한다는 뜻이다. 이 역시 두벌식에서는 종성에 대해서는 적용할 수 없고, 중성에 대해서만 적용 가능하다. T==2에 대해서 -1 (무시)을 되돌리게만 하면 간단히 구현 가능하다.
날개셋 한글 입력기의 완성도를 더욱 끌어올릴 아이디어가 하나 떠올라서 성공적으로 구현되니 좋다. 이제야 '복합 낱자 입력 로직 생성기는' 진짜로 더 만들 게 (현재로서는) 안 떠오르고 작업이 완전히 종결된 것 같다.
이 옵션이 추가됨으로써 '복합 낱자 입력 로직 생성기' 마법사의 2단계 대화상자는 너무 큼직하고 복잡해졌다. 사실, '허용 한글 범위 제약'은 통상적인 로직 생성 옵션과는 성격이 좀 다른 액세서리에 가깝다. 그렇기도 하니 이건 마법사의 별도의 단계로 분리해 버렸다.
 |  |
복합 낱자 입력 로직 생성기가 쓰라는 의도로, "오토마타에 '0번 상태에서 모든 실패 상황을 처리"라는 옵션을 추가했다.
정상적인 한글 입력에 따른 상태 분기와는 달리, 실패 상황의 상태 분기 방식은 지금 오토마타 상태와 무관하게 언제나 동일한 경우가 많다. T가 3이면 -12, T가 4이면 -1 이렇게 T라든가 I~K의 값에 따라 달라질 뿐, 성공 상황처럼 매번 처리 방식이 들쭉날쭉해지는 건 매우 드물다.
이 점에서 착안하여, T==3 ? -12 : T==4 ? -1: 0 같은 수식은 초기 상태에서 A ? 1: B ? 2: C: 3 : (!!) 다음에 한 번만 추가하면 모든 오토마타 상태에서 동작하게 했다.
- 8.8: 복합 낱자 입력 로직 생성기 첫 도입
- 8.9: 그 기능에다 '한글 허용 범위 제약' 기능 연계 추가
- 9.0: '한글 허용 범위 제약' 연계 기능에다가 '오토마타'와의 연계를 또 추가. 이제 진짜 끝?
2. 그 밖에 복합 낱자 입력 로직 생성기의 사소한 개선 사항
- '낱자 최적화' 알고리즘이 좀 더 개선되어서 글쇠에 등장하지 않고 쓰이지 않는 낱자 결합 군더더기를 더 잘 걸러내게 했다.
- 매우 드문 상황이겠지만, 로직 생성 작업이 아무 메시지 없이 깔끔하게 끝났다면 "작업을 완료했습니다"라는 말 한 마디라도 출력해서 사용자가 심리적으로 혼동하지 않게 했다. PC용 세벌식+현대 한글처럼 복잡한 처리가 필요하지 않은 설정에서는 드물게 이런 일이 있을 수 있다.
- 초성 문맥이 전혀 존재하지 않는 종성 두벌식 날개셋문자를 사용하더라도 초성에 등장하는 것 자체는 가능하니 이를 감안하여 동작하게 했다. 물론 원래 소속이 종성이니 이 낱자들은 초성 '대결합'은 전혀 처리하지 못한다는 걸 사용자가 염두에 둬야 한다.
그리고, 입력 데이터를 검증할 때 현재는 대결합의 결과값이 소결합의 시작과 결과값에 또 등장하는 것을 금지시키고 에러로 처리하는데, 9.0은 여기에 덧붙여 대결합의 결과값이 자신이나 다른 대결합의 과정값에도 등장하지 못하게 조건을 강화했다. ㅂ+ㅅ → ㅄ이 있다고 해서 ㅄ+ㄷ → ㅵ를 줘서는 안 되고 반드시 매번 ㅂ+ㅅ+ㄷ → ㅵ로 해야 한다는 뜻이다. 그렇게 해야 대결합을 실제로 expand할 때 동일 input으로부터 a+b → x와 a+b → y가 동시에 등장하는 식의 논리 오류를 방지할 수 있다.
이런 제약을 가한 대신, ㅂ+ㅅ+ㄷ → ㅵ에서 ㅅ+ㄷ → ㅼ이라는 다른 대결합이 존재하고 ㅼ이 글쇠에 존재해서 한 타 만에 입력 가능한 경우, 이 프로그램이 ㅂ+ㅼ → ㅵ이라는 결합도 자동으로 찾아서 생성하게 했다.
3. 기본 글자판 설정에 두벌식 관련 고급 옵션 추가
날개셋 한글 입력기가 제공하는 빠른설정들 중에 '기본 글자판 설정'은 대중적이고 기본적인 입력 기능만 사용하는 분들이 가장 자주 사용할 만한 빠른설정이다. 처음으로 개발된 이래로 별다른 변화 없이 10년이 넘게 존속해 왔다.
본인은 다른 대화상자들이라면 몰라도 얘만은 프로그램 내부 구조 지향이 아니라 사용자 지향· 사용자 친화적으로 만들려 애썼다. 복잡한 각종 옵션들을 어지럽게 한 화면에 몽땅 노출하지 않고 새끈하게(?) 보이게 하려고 단계별 마법사 UI를 쓸까 생각도 했다. 대화상자를 보면 좀 마법사 UI처럼 생겼지 않는가?
그런데 실제로 개발을 해 보니 기본 글자판 설정이란 게 굳이 몇 단계짜리 마법사까지 동원할 정도로 구조가 복잡하지는 않아서 '다음' 단계 대신 그냥 '고급' 버튼만 넣는 걸로 퉁쳤다.
마법사 UI는 먼 훗날에 '복합 낱자 입력 로직 생성기' 빠른설정이 대신 찜했다. '기본 글자판 설정'보다 기능이 훨씬 더 많고 복잡하니 처음에 3단계 마법사로 시작했고 이번 9.0부터는 4단계로 더 늘었다.
이런 사정을 거쳐, 기본 글자판 설정엔 현재까지 '고급' 옵션이라는 게 세벌식 자판과 관련된 것 네 종류만 있었다. 그러나 이제는 표준 두벌식을 골랐을 때도 '고급' 옵션을 사용할 수 있으며, 여기에는 두벌식에만 적용되는 고유한 고급 옵션이 몇 가지 들어갔다.
먼저, '자음의 처리 방식'이다. '초성과 종성 따로'는 일반적인 동작 방식이고, '초성 지향'은 '날 - 나라' 대신 '나ㄹ - 날'이 되는 동작을 말한다. '종성 지향'은 초성도 일단 종성 문맥으로 입력되었다가 나중에 중성을 받았을 때에야 초성으로 바뀌는 동작이다.
기술적으로야 초성 지향은 '고급 입력기'의 옵션을 사용해서 동작하고 종성 지향은 '종성 두벌식'이라는 별도의 날개셋문자를 사용해서 동작한다. 구현 방식이 서로 완전히 다르지만 이 빠른설정에서는 한데 선택할 수 있다는 것에 의의가 있다.
그리고 표준 두벌식은 오로지 알파벳 26개 자리에만 한글 글쇠가 있고 숫자와 기호를 사용하지 않는다는 특성상, 숫자와 기호는 굳이 입력기가 가로채지 않고 응용 프로그램으로 보내도록 하는 옵션을 빠른설정에서 곧장 선택할 수 있게 했다.
이로써 두벌식과 세벌식 모두 빠른설정에서 오로지 자신만의 고유한 고급 옵션을 갖게 됐다. 단지 세벌식의 고급 옵션들은 3.x 완전 초창기 때부터 존재했지만, 두벌식의 고급 옵션들은 다 6~7.x에 가서야 도입됐고 빠른설정에 반영은 훨씬 늦었다는 것이 차이점이다.
4. 토씨 자동 교정
한글 입력과 직접적인 관계가 있지 않고 평생 다시 볼 일이 없을 거라고 생각했는데, 토씨 자동 교정 알고리즘을 우연한 계기로 재검토해서 정확도를 조금 올렸다.
토씨 자동 교정 기능은 동작이 은근히 복잡하다. 은/는, 을/를, 과/와 같은 거야 아주 쉬운 케이스이다. 그러나 (으)로는 유일하게 ㄹ 받침도 무받침과 동급으로 간주해야 한다는 예외가 있으며, '이'는 처리하기가 훨씬 더 어렵다. '이나마, 이랑, 이라'처럼 받침 유무에 따라 '이'를 넣거나 생략해야 하는 것들이 많기 때문이다. '이다'의 경우는 받침이 없더라도 반드시 생략할 필요는 없다.
이것들부터 먼저 검토한 뒤, 한글이 또 등장하지 않아서 명백하게 주/보격 조사인 '이'에 한해서 '이/가' 처리를 해야 한다. 하긴 중세 국어에서는 조사 '가'가 없었다고 하더라만..
'이'만 처리가 이렇게 복잡한 이유는 한국어의 매우 독특한 단어 '이다'의 정체성과 밀접한 관계가 있다.
한국어의 어절(띄어 쓰는 단위)에서 관형어나 부사· 감탄사, 기능어 등등 잡다한 거 빼고 내용어를 구성하는 것은
딱 (1) '체언+조사' 계열, 아니면 활용을 하는 (2) '용언+어미'라는 두 계열로 나뉜다.
그런데 '이다'라는 단어는 정말 요물이다. 얘는 문법적으로 무엇으로 분류해야 할지 쟁쟁한 국어학자 문법학자들 사이에서도 의견이 오랫동안 일치하지 않았다.
마치 영어에서 be 동사가 여느 다른 동사들과는 문법적으로 다르게 취급되는 동사이듯, 쟤도 평범한 용언은 아니다.
오늘날 표준 국어 대사전 + 학교 문법에서는 '이다'를 서술격조사로 본다. '이었다' 등 영락없이 용언처럼 생긴 물건이 조사라니.
그래서 '이니', '이고', '이면'처럼 '이다'의 활용형도 다 별개의 접속조사이고, 일단 사전에 일일이 단독으로 등재돼 있다.
이것도 많은 고민 끝에 내린 결론이겠지만 이게 합리적인 결정이라고 볼 수 있는지는 모르겠다.
하긴, '귀신이다', '불이야'처럼 체언에 잘도 척척 달라붙는 동사나 형용사가 다른 예가 없긴 하다. (공부하다 이런 건 논외. 그때의 '-하다'는 접사임.)
체언과 용언을 파동과 입자에다 비유하자면, '이다'는 진짜 빛처럼 두 성질을 모두 지닌 이상한 물건이다.
그리고 이 '-이' 때문에 '찾기/바꾸기'에서 한글 토씨 자동 교정 기능도 구현하기 꽤 복잡하고 어려워져 있다.
끝으로, '야'의 경우 호격조사 '아' 또는 보조사 '이야'가 모두 가능한데, 이것은 용례 domain이 겹치기 때문에 글자만 보고 구분하기가 불가능하다. 토씨 자동 교정 알고리즘의 구조적인 한계가 될 수밖에 없는 점이다.
5. 기타 사소한 것들
(1) 도움말 부록의 자음 참조표에서 ㅁㅂㅅ의 순서가 잘못 기재되었던 오타를 지적해 주신 분이 있어서 고쳤다. 78이 빠지고 79가 두 번 들어가 있었다. 이 오타는 굉장히 오랫동안 발견되지 않고 지금까지 잘도 숨어 있었다. 오죽했으면 5년 전, 2012년에 발행된 본인의 석사 학위논문의 부록에도 동일한 오타가 그대로 들어갔다!
(2) 편집기에는 프로그램의 중복 실행이 감지된 경우 인스턴스를 또 생성하지 않고 기존 인스턴스에다 새 문서창을 열게 하는 기능이 있다. 그런데 기존 인스턴스가 어떤 이유로 인해 응답이 없고 뻗은 상태라면 그 옵션이 지정되어 있더라도 예외로 그냥 새 인스턴스에서 실행되게 하여 동작에 융통성을 더했다.
(3) 날개셋 편집기를 비롯해 내 프로그램이 내부에서 자체적으로 사용하는 빨랫줄 모양 옛한글 비트맵 글꼴의 중성 자형을 일부 수정했다. 그래서 ㅣㅛ, ㅓㅛ, ㅕㅗ 등, ㅗ/ㅛ가 포함돼 있는 겹모음들이 위의 초성과 더 잘 포개져서 조화롭게 보이게 했다.
(4) 두벌식 옛한글의 Shift+H(ㅗ) 자리에 지금까지 ㅗㅜ가 배당돼 있던 것을 ㅗㅗ로 변경했다. 기왕 내 프로그램은 Shift 자리에는 다른 자모와 겹치지 않는 한 아랫자리에 있는 낱자의 double(쌍) 버전을 넣는 것으로 컨셉을 잡았으니 저렇게 하는 게 더 일관성이 있을 것 같다. 아래아한글의 영향을 받아서 내 프로그램도 까마득한 2.x 옛날 버전부터 ㅗㅜ이긴 했는데, 그냥 breaking change(하위 호환성이 깨지는 단절적인 변화)를 만들었다.
ㅜ와 ㅡ도 double 버전이 있긴 하지만 쟤들은 Shift 자리에 다른 글쇠가 정해져 있기 때문에 double 버전을 넣을 수 없다. 두벌식은 옛한글 배열이라 해도 숫자· 기호 자리를 침범하지 않는 게 일종의 불문율이긴 하다.
Posted by 사무엘
