Search Results for '2018/01/13'


1 POSTS

  1. 2018/01/13 다음 버전 개발 근황 2 by 사무엘

다음 버전 개발 근황 2

오늘은 날개셋 한글 입력기 9.3에서 팝업창 형태로 새로 추가되는 보조 입력 도구 두 가지를 소개하도록 하겠다.

1. 조합과 후보 자동 완성

이 입력 도구는 구동 직후에 화면에 뜨는 것이 없다. 그 대신, 사용자가 뭔가 한글 입력 같은 조합을 만들기 시작하면 짠 나타나서 지금 단계 이후에 진행 가능한 조합(왼쪽)과, 이 상태에서 변환 가능한 후보 문자열(오른쪽)들을 목록으로 쫙 표시해 준다.
사용자 정의 조합의 경우, 가령 A를 누른 뒤에 ' ` ^ -이런 것을 뭘 더 누를 수 있고, 그걸 누르면 문자가 무엇으로 바뀌며, 지금 상황에서 무슨 문자로 변환 가능한지 목록으로 미리 볼 수 있다.

사용자 삽입 이미지

위의 그림은 영문 쿼티에다가 글자별로 온갖 확장 부호들을 후보로 배당해 놓은 QwertyExt 예제를 불러온 뒤 =를 눌렀을 때 나타나는 목록이다. 비록 단어 단위가 아니고 글자 단위이긴 하지만, 일일이 한자 글쇠를 누를 필요 없이 곧장 후보 변환을 할 수 있다.

사용자 삽입 이미지

위의 그림은 각각 한글과 라틴 알파벳으로 일본어 히라가나 문자를 입력할 때 나타나는 목록의 모습이다. 지금 상황에서 저런 알파벳이나 한글 자모를 누르면 저런 문자가 계속 입력된다는 것을 알 수 있다. 검정보다 약간 옅은 회색 글자는 이 문자가 조합이 아닌 완성된 형태로 삽입된다는 것을 나타낸다.

사용자 삽입 이미지

일반적인 한글 조합은 사용자 정의 조합과는 달리, 기본적으로 테이블 기반이 아닌 '공식 기반'이니 직관적인 편이며, 조합 가능한 글자 수도 아주 많다. 그렇기 때문에 'PC+현대 한글' 같은 아주 널널한 경우라면 굳이 이런 식의 preview 기능이 필요하지 않을 것이다.

하지만 한글 입력도 옛한글을 다룬다거나 글쇠 수가 아주 적은 모바일 내지, 허용 한글 제약 기능이 있는 특수한 상황이라면 이 도구의 유용성이 크게 올라간다. ㄹ로 시작하는 옛한글 겹자음은 ㄷ으로 시작하는 옛한글 겹자음보다 훨씬 더 많다는 걸 알 수 있다.

사용자 삽입 이미지

ㄷ뿐만 아니라 '두'다음에 결합 가능한 옛한글 중성들도 저렇게 쫙 표시된다.

사용자 삽입 이미지

'복합 낱자 입력 로직 생성기'를 돌려서 KS X 1001 완성형 한글만 입력 가능하게 하고, 더 결합의 여지가 없는 단계에 도달하면 조합을 곧장 끊게 오토마타를 설정했다. 그랬더니 '바'와 '파'에 대해서 이렇게 서로 다른 결과가 나왔다. '파' 다음에는 '바'와는 달리 ㄷ, ㄺ 같은 받침이 붙지 못한다. '바'는 반대로 '파'에 있는 받침 ㅆ이 존재하지 않는다.

'박'은 '밖'이 결합 가능하며 '발'은 그 뒤로 '밝, 밟'이 존재하기 때문에 쟤들 둘만 회색이 아닌 검정으로 표시되어 있다. '밟'이 저 목록에 존재하지 않는 이유는 ㄼ이 단독 글쇠로 존재하지 않는 세벌식 390 글쇠배열을 기준으로 했기 때문이다.

사용자 삽입 이미지

이 입력 도구는 현재 사용 중인 키보드 입력 스키마뿐만 아니라 자체적인 입력 기능을 갖춘 타 입력 도구를 기준으로도 잘 동작한다. 한손 입력기는 저렇게 천지인 (또는 옵션을 바꿔서 나랏글) 모음에다가 5개 자음(초성 종성 따로)을 갖췄다는 것이 목록을 통해서도 확인된다.

한글 조합에 대해서 진행 가능한 조합 단계는 (1) 가장 최근에 입력된 낱자에 대해서 더 적용 가능한 낱자 결합 규칙을 모두 먼저 표시한 뒤, (2) 바로 다음 입력 단계(가령, 중성 다음엔 종성)에 해당하는 글쇠들 중 글쇠배열에 있는 것을 표시하는 식으로 동작한다.
즉, 낱자 결합 규칙과 글쇠배열을 기본적으로 활용하되, 이 중에서 오토마타 수식과 한글 입력 범위 제약 검사를 통과한 것만 한정해서 가나다 순으로 출력한다.

이 도구는 오로지 현재 조합 중인 문자(열)에만 관심이 맞춰져 있다. 그렇기 때문에 종성을 입력하고 있을 때 다음 글자의 초성이나 중성(두벌식 기준)까지 미리 제시해 주지는 않는다. 사용자의 요청이 많고 그것까지 고려하는 게 충분히 유용하다면 다음 버전에서는 반영될지 모르겠지만 현재로서는 제외했다.

그리고 이미 제공되는 후보 변환 UI와는 달리, 숫자를 눌러서 항목을 바로 선택하는 기능도 제공되지 않는다. 얘는 후보 변환 UI보다는 개발툴의 에디터 같은 데서 제공하는 "자동 완성 목록 UI"를 표방하여 설계됐기 때문이다. 키보드를 사용하려면 설정 대화상자에서 옵션을 지정해야 하며, 이 경우 상하좌우 화살표와 Page up/down으로 선택막대를 이동시킬 수 있다. 엔터와 ESC는 덤이고.

이 도구는 '글쇠배열 이름 표시'와 마찬가지로 원래는 cursor의 바로 아래에 표시돼야 한다. 하지만 구현체의 상황에 따라서는 기술적으로 위치를 알 수 없어서 불가피하게 화면 한구석 같은 엉뚱한 곳에 표시될 수도 있다.
심지어 EditPlus 3.x는 이 도구를 띄워 놓으면 조합 문자열이 계속 같은 곳에서 덮어 써지면서 입력이 제대로 진행되지 않았다. 후대 버전에서는 고쳐졌나 모르겠다.

이 프로그램이 근본적으로 없는 길을 트는 방식으로 동작하며, 한 프로그램에서 되게 하는 방법이 다른 프로그램에는 부작용을 일으키곤 한다. 그렇기 때문에 EditPlus 한 프로그램에서만 부작용이 발생하는 걸 더 어찌할 수는 없어 보인다. 일단 개발 과정에서 이런 일이 있었음을 밝힌다.

2. 조합 안에 조합 생성

날개셋 한글 입력기는 말 그대로 한글을 입력하는 게 핵심인 입력기이다.
한글 IME는 조합하고 있는 한 글자만 신경 쓰면 되지 중국어나 일본어 IME처럼 단어· 문장을 통째로 조합을 잡을 필요가 없다. 길다란 조합 문자열 내부에서 또 가상의 caret을 이동한다거나 구간별로 영역을 달리하여 점선이나 실선으로 표시할 필요도 없다. 그건 내 프로그램의 관심 분야가 아니라고 도움말의 '일러두기'에다가 명시까지 해 뒀다.

개발자인 본인의 시간과 체력은 매우 한정돼 있는데, 이 와중에 관심 분야를 대책없이 이것저것 문어발처럼 뻗치다 보면 프로그램의 정체성이 죽도 밥도 안 되는 이상한 산으로 가 버릴 위험이 있다. 더구나 편집기 같은 전용 프로그램이라면 모를까 외부 모듈이라면, 한글 IME에서는 어차피 운영체제가 조합을 그렇게 일본어· 중국어 IME처럼 표시하는 기능을 애초에 지원해 주지도 않는다.

그럼에도 불구하고 내 프로그램도 기왕이면 타 언어 IME들이 할 수 있는 일을 다 할 수 있으면 좋지 않나 하는 생각을 본인은 아주 오래 전부터 해 왔다. 기약 없는 먼 미래의 일이지만 장기 과제로 염두에 두고 있었다.
그리고 2017년 겨울~그리고 올해 초 사이에 바로 그 꿈이 실현되는 미래가 찾아왔다.
글자 단위로 동작하는 기존 문자 생성기를 내부 버퍼에다 감싸서 단어· 문장 단위로 통째로 변환 후보를 제시하고 변환하는 기능들에 대해 공통 인터페이스를 제시하고, 이걸 '입력 도구'의 형태로 제공하기로 한 것이다.

한글을 글자 단위로 곧장 내보내지 않고 묶어서 내보내는 것은..

  • 과거 도스용 아래아한글에서 잠시 제공하던 새김 단위로 한자 입력
  • TSF를 지원하지 않는 프로그램에서도 단어 단위로 한글-한자 변환. 특히 매번 한자 키 안 누르고 곧장 변환하기
  • 한글 발음으로 일본어나 중국어 입력 (당연히 단어· 문장 단위로 한꺼번에 변환)
  • 스마트폰에서 볼 수 있듯이, 자주 사용되는 단어의 자동 완성

이렇게 잠재적인 활용 가능성이 매우 높다. 그냥 공통 인터페이스를 상속받아서 각 기능별로 후보를 제시하는 알고리즘만 달리하면 된다. 구현할 가치가 매우 높다고 판단되어 날개셋 한글 입력기의 구조를 전반적으로 다 뜯어고치고 확장하는 공사를 진행했다. 그리고 그만큼 보람을 느낀다.

'새나루' 입력기에는 날개셋 한글 입력기가 개발 방향의 컨셉· 차이로 인해 제공하지 않던 기능이 두 가지쯤 있었다. 하나는 드보락이나 콜맥 같은 임의의 영문 키보드 드라이버를 한글 IME(= 새나루 자신)와 연결하는 기능이다. 이건 내 프로그램도 지난 8.6 버전 때부터 드디어 도입됐다. 임의의 키보드 드라이버와 연계 가능하게 프로그램 구조가 싹 개선되면서 두 입력기 간의 차이가 없어졌다. 내 프로그램은 그에 덧붙여 키보드 드라이버의 동작을 보정하는 옵션까지 갖추고 있다.

그리고 다른 하나는 한자 변환 관련이다. 새나루는 한글, 영문처럼 '한자'라는 입력 모드가 있어서 (1) 매번 한자 키를 누르지 않아도 한자 후보가 한글과 함께 곧장 떠서 변환할 수 있었으며, '단어 단위 조합 생성'이라는 옵션이 있어서 (2) TSF가 지원되지 않는 환경에서도 2글자 이상의 단어 단위로 한자를 변환할 수 있었다. (1)과 (2)를 동시에 사용하면 타 한글 입력기를 쓸 때보다 한자 변환을 훨씬 더 빠르고 편하게 할 수 있기 때문에 한자 혼용론자 진영(!!)에서는 자기들끼리 새나루의 사용을 권장할 정도였다.

그에 반해 내 프로그램의 개발 이념에 비춰 보면, 단어 단위 한자 변환은 그냥 이미 있으니까 덤으로 제공하는 보조 기능에 가깝다. 한글을 단어 단위로 조합을 잡는 것은 고려 대상이 아니다. 딱히 개발자가 한글 전용 소신을 갖고 있어서 의도적으로 제공 안 하는 건 아니고, 그냥 개발 방향과 맞지 않기 때문에 지원하지 않았다. 세벌식 모아치기가 아니라 그런 기능이 필요하면 날개셋 대신 그냥 새나루 쓰라고 말이다.

그랬는데 먼 훗날, 결국 내 프로그램도 새나루에서만 제공되던 기능을 더 범용적인 형태로 수용하고 구현하게 됐다. (1)은 '조합과 후보 자동 완성' 입력 도구를 띄워서 후보 목록만 표시하게 설정하면 된다. 그리고 (2)는 '조합 안에 조합 생성' 입력 도구를 띄워서 단어 단위 한자 변환 기능을 설정하면 된다.
지금까지는 그런 변환 기능이 날개셋 한글 입력기 내부에서 어떤 위상과 계층을 차지해야 하는지 확신이 서지 않아서 구현하지 못했는데... 이제는 '입력 도구'라는 이론적 근간이 마련됐기 때문에 구현됐다.

한글 말고 영문의 경우도 T9 같은 모바일용 입력 방식에서는 단어 단위 조합이 필요하다. 한 글쇠에 여러 글자가 배당되어 있고 사용자가 multi-tap 없이 각 대표 글쇠만을 눌렀을 때, 사용자가 의도한 실제 단어가 무엇인지 유추하고 자동 완성 후보를 제시하려면 변환 엔진이 단어 전체를 살펴볼 수 있어야 할 테니 말이다.
이 '조합 안에 조합' 입력 도구는 '휴대전화 입력기' 내지 '조합과 후보 자동 완성' 입력 도구와도 연계해서 사용하기 좋다.

사용자 삽입 이미지

이렇게 보조 입력 도구의 내부에서 '조합 안에 조합'이 생성되고 있을 때는 문자 입력 기능에 기술적으로 다음과 같은 제약이 걸린다.

1. 빈 입력 스키마(호환 옵션 포함) 계열의 글자판을 사용할 수 없으며, '글쇠 누름' 계열의 날개셋문자로 문자를 입력할 수 없다. 그건 태생적으로 글쇠를 IME가 가로채지 않고 응용 프로그램 내부로 보내는 기능이기 때문에 '조합 안에 조합'을 생성하거나 건드릴 수 없다. 한글이야 애초부터 IME가 글쇠를 가로채지 않으면 입력할 수 없는 문자이기 때문에 별 문제될 게 없는 반면, 영문이나 숫자를 입력할 때 주의할 필요가 있다.

2. 이 상태로 또 글자 단위 후보 변환을 할 수 없다. '조합 안에 조합' 입력 도구를 사용하는 이유는 단어 전체를 한꺼번에 다른 문자열로 변환하기 위해서이다. 그러니 그 안에서 또 글자별 후보 변환을 하는 상황은 생각하지 않기로 한다. 외부 모듈이 원래 고유하게 갖고 있던 후보 변환 UI와, 조합 안의 조합이 요청할 수 있는 후보 변환 UI 사이의 충돌 등, 상황이 너무 복잡해지기 때문이다.
그때도 굳이 한자 변환을 하고 싶다면 '조합과 후보 자동 완성' 입력 도구를 미리 꺼내 놓고 사용하면 된다.

이런 제약은 날개셋 한글 입력기의 구현체가 전용 텍스트 에디터인 '편집기'밖에 없다면 굳이 존재하지 않을 제약이다. 하지만 외부 모듈과 입력 패드에서는 내가 가로채는 글쇠뿐만 아니라 응용 프로그램이 처리하는 글쇠도 고려해야 하고, 운영체제와 통신하는 부분도 고려해야 하기 때문에 그런 만능 범용성을 보장할 수 없다.

'조합 안에 조합'은 저렇게 제약과 불편한 점만 있는 게 아니며, 그 특성상 고유한 장점도 있다.
외부 모듈(대부분의 환경)이나 입력 패드는 편집기처럼 주변의 텍스트를 자유자재로 조작할 수 없기 때문에 조합이 끝난 글자를 낱자 단위로 지운다거나 다시 조합 상태로 돌아가는 것이 불가능하다.
하지만 '조합 안의 조합' 입력 도구는 자기가 자체적으로 텍스트를 갖고 있으니, 구현체를 불문하고 어떤 환경에서도 동일하게 텍스트를 자유롭게 조작하는 기능을 제공한다.

* 결론

이로써 날개셋 한글 입력기가 제공하는 입력 도구들은 오랫동안 4개만 있던 것이 10개로 크게 늘었다. 이들의 특성을 표로 정리하면 다음과 같다.

명칭 도입 시기 동작 외형
한손 입력기 5.3 (2009) 자체 조합 입력
화면 키보드 5.3 (2009) 기존 입력 스키마
부수로 한자 입력 5.51 (2009) 자체 입력 대화상자
문자표 5.52 (2010) 자체 입력 대화상자
휴대전화 입력기 9.1 (2017) 자체 조합+기존 스키마
글쇠배열 이름 표시 9.1 (2017) 읽기전용 팝업
수식 계산 기록 9.3 (2018) 읽기전용 대화상자
내부 입력 상태 표시 9.3 (2018) 읽기전용 대화상자
조합과 후보 자동 완성 9.3 (2018) 기존 입력 스키마
팝업
조합 안에 조합 생성 9.3 (2018) 기존 입력 스키마 팝업

입력 도구의 동작은 다음과 같이 나뉜다.

  • 자체 조합 입력: 입력 도구가 자신만의 고유한 문자 생성기를 갖추고 조합 문자열을 입력시킨다. 한손 내지 휴대전화 입력기가 이 범주에 속한다.
  • 자체 입력: 굳이 문자 생성기의 조합 없이, 완성된 비조합 문자를 간단히 입력시킨다. 한자 부수 및 문자표가 이 범주에 속한다.
  • 기존 입력 스키마: 현재 사용 중인 입력 스키마와 문자 생성기를 기준으로 날개셋문자를 보낸다. 화면 키보드가 이 범주에 속한다.
  • 읽기전용: 현재 사용 중인 입력 항목의 상태를 표시만 할 뿐, 자기 자신은 아무런 입력 기능이 없다. 글쇠배열 이름 표시라든가 수식 계산 기록 같은 도구가 이 범주에 속한다.

입력 도구의 외형도 다음과 같이 다양하게 분류된다.

  • 대화상자: 제목 표시줄을 갖추고 크기 조절도 되며, 리스트 박스, 콤보 박스 같은 사무적인(?) 컨트롤들이 나타나 있다. 클래식 데스크톱 UI에 가깝다.
  • : 대화상자와 같은 형식을 갖추지 않고 큼직한 버튼 위주로만 구성돼 있다. Metro UI에 가깝다.
  • 팝업: 평소에는 화면에 보이지 않다가 글쇠 같은 특정 이벤트가 발생했을 때에만 잠시 cursor 주변에 나타난다. 그리고 일정 시간이 흐르거나 조합이 종료되면 창이 도로 사라진다.

아울러 9.3 버전에서는..

  • 대화상자형 입력 도구들 중에 도움말이 제공되는 것은 제목 표시줄의 오른쪽 끝에 [X]뿐만 아니라 [?] 버튼도 추가했다.
  • 그리고 '입력 도구 선택' 대화상자의 목록에서 이미 켜 놓은 입력 도구는 앞에 *(별표)가 덧붙여져 있게 했다. 평소에 나타나 보이지 않는 '팝업형' 입력 도구도 존재한다는 것을 이를 통해 확인할 수 있다.

사용자 삽입 이미지

기타: ㄹ+한자 특수문자 변환 테이블의 오류 수정

ㄹ을 입력하고서 한자를 누르면 아시다시피 여러가지 단위 기호가 나타나는데, 넷째 후보로 F가 있던 것을 °로 변경했다. 이건 다음과 같은 여러 정황상 후보 변환 테이블의 오류로 추정되기 때문이다.

  • 아마 화씨 온도 단위를 의도한 것 같으나, ℉는 뒤에 따로 또 있다.
  • 단순 전각 F는 ㅍ+한자에도 이미 있기 때문에 중복 등재이다. 그 반면 °은 지금까지 KS X 1001 특수문자 중 유일하게 초성+한자 어디에도 배당되어 있지 않았다.
  • 넷째 다음으로 다섯째와 여섯째에는 분, 초 ′ ″ (프라임, 더블 프라임)이 있기 때문에 도-분-초 순서가 자연스럽게 연결된다.
  • °은 KS X 1001 2바이트 코드가 A1C6이다. F는 A3C6으로 서로 비슷하다면 비슷하기 때문에 혼동하기 쉬운 관계이다.

확인해 보니 Windows 95, 아니 3.1 이래로 MS 한글 IME는 줄곧 ㄹ+한자에 F가 있긴 했다. 참 유구한 전통이긴 하지만 오류가 명백하기에 날개셋은 F를 °로 변경하기로 결정을 내렸다.
저 오류는 본인이 최초로 찾아낸 게 아니라 역시 정 재민 님의 제보가 출처이다. 도대체 이런 걸 어떻게 발견해 내는지..

하긴, Windows 98 시절엔 ㄹ 자리에 유로화 기호가 추가되었으며, Vista 타이밍엔 ㅁ 자리에 우편번호 기호가 추가되기도 했으니, 이 변환 테이블이 20년째 완벽한 고정불변도 아니긴 했다.
참고로 유로화 기호(U+20AC)는 2바이트 코드로 역변환이 가능한 반면, 우편번호 기호(U+327E)는 그렇지 않다.

Posted by 사무엘

2018/01/13 08:35 2018/01/13 08:35
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1447


블로그 이미지

그런즉 이제 애호박, 단호박, 늙은호박 이 셋은 항상 있으나, 그 중에 제일은 늙은호박이니라.

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2018/01   »
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31      

Site Stats

Total hits:
2672527
Today:
759
Yesterday:
1354