날개셋 한글 입력기 9.1

1. 들어가는 말

2017년 6월에 날개셋 한글 입력기 9.0이 나온 지 4개월 만에 9.1 버전이 나왔다. 추석을 낀 10월 황금 연휴 기간까지 보낸 뒤에 드디어 공개되었다. 오랜 마음의 부담을 덜었다.
이번 버전은 이전 버전들과 달리, 오로지 '보조 입력 도구'의 기능을 크게 강화하는 것에 초점이 맞춰졌다. 비록 readme가 분량이 이례적으로 매우 짧으며 사실 넣고 싶은 기능을 다 넣지도 못했지만, 이번에도 내부적으로 1500줄이 넘는 코드가 새로 추가되고 많은 변화가 있었다.

이미 있는 입력 도구에 기능이 추가된 것부터 소개하자면,
(1) 먼저, 지난 7월에 소개한 것처럼 "화면 키보드"에 일종의 live preview 옵션이 추가되었다. 현재의 문맥을 기준으로 수식을 계산했을 때 입력되는 문자를 실시간으로 바꿔서 표시해 주기 때문에 복벌식이나 신세벌식 같은 복잡한(?) 입력 방식을 사용할 때 큰 도움이 될 것이다.

(2) 그리고 5.3에서 첫 도입된 이래로 변화가 전혀 없었던 "한손 입력기"에도 아기자기한 변화가 생겼다.
화면 키보드처럼 3단계 크기 조절이 가능해졌으며, 초성과 종성의 배치가 대칭이라는 점을 착안하여 초성· 종성을 우-좌로 배치할지, 좌-우로 배치할지를 변경할 수 있게 했다. 세벌식이니까 존재할 수 있는 절묘한 customization이다.

사용자 삽입 이미지

또한, 중성의 경우, 천지인 방식뿐만 아니라 나랏글 방식도 고를 수 있게 했다. ㅡ 글쇠가 따로 없기 때문에 얘는 ㅣ를 두 번 눌러서 입력하면 된다.
한손 입력기는 애초에 나랏글처럼 '가획' 글쇠가 있어서 자음에서 쓰이고 있다. 그러니 모음도 나랏글 방식을 지원하지 말라는 법이 없다. 이런 옵션으로 인해 한손 입력기의 활용의 폭이 더 넓어지기를 기대해 본다.

2. 휴대전화 입력기

이번 9.1에서 추가된 가장 대표적인 기능은 바로 이 입력 도구이다. 얘는 3*4 방식의 키패드를 통해 다양한 입력 방식을 제공한다.
한글, 영문, 숫자, 기호 이렇게 총 4가지 모드가 있다. 그 중 한글은 현재 지정되어 있는 키보드 입력용 글자판(= 입력 항목) 중 하나에서 0~9와 * # 자리를 그대로 빌려 쓴다.
즉, '한손 입력기'처럼 독자적으로 제공하는 입력 기능이 없이 기술적으로는 '화면 키보드'의 부분집합처럼 동작한다. 처음에는 구동 당시에 사용 중이던 글자판을 기준으로 동작하지만, 글자판을 딴 걸로 변경하고 나서 우클릭 메뉴에서 '동기화'를 선택하면 기준으로 삼는 글자판을 바꿀 수 있다.

(1) 이 입력 도구는 기존 입력 설정을 빌려 와서 동작하는 대신, 한번 참조해서 불러들인 글자판은 사용자가 딴 걸로 변경하더라도, 심지어 날개셋 제어판을 통해 기존 입력 설정을 싹 갈아엎더라도 절대불변으로 계속 갖고 있는다. 이것이 '화면 키보드'와는 다른 점이다.
그렇기 때문에 한번 천지인이나 나랏글 같은 입력 방식으로 동기화시킨 뒤엔, 다시 PC 키보드용으로 쓰기 편한 두벌식이나 세벌식을 쓰다가 마우스로만 모바일용 입력 방식을 같이 쓸 수가 있다.

(2) 또한 비트맵 글꼴을 사용하는 '화면 키보드'와 달리, 이 입력 도구는 나름 크기 조절이 가능한 운영체제의 글꼴을 사용한다. 게다가 조합을 통해 생성되는 한글 자모들을 모두 한데 표시해 준다. 나랏글의 경우 ㅏㅓ, 첫지인의 경우 ㄱㅋㄲ 이런 것을 한 글쇠에다 크기 조절까지 알아서 해서 표시한다는 것이다.

사용자 삽입 이미지

다만, 글쇠에 비문자 특수글쇠나 가상 낱자가 들어있다면 이렇게 프로그램이 글쇠 문자를 자동으로 찾아 준 결과가 썩 정확하지 않을 것이다. 이럴 때는 이 글쇠는 무슨 역할을 한다고 사용자가 그냥 직접 지정을 할 수 있다. 나랏글의 가획/쌍자음 같은 글쇠는 500이니 501이니 이런 내부 숫자가 아니라, 저렇게 사람에게 실질적인 의미를 갖는 별칭을 표시하는 게 훨씬 낫기 때문이다.

이런 정보를 읽어들이기 위해서 '휴대전화 입력기'는 글쇠배열의 '설명문'을 사용한다. 그 텍스트에 XML 시그니처가 존재한다면 그 뒤에 나오는 XML을 해석해서 거기에 지정된 이름을 출력한다~!
미래에 궁극적으로는 설정 파일 내부에 임의의 메타데이터를 저장하는 계층을 더 그럴싸하게 강화할 것이지만, 일단은 이런 임시방편을 동원했다.

<?xml version="1.0"?>
<info>
    <key pos="#" name="SEP" flag="1"/>
</info>

날개셋 한글 입력기가 예제로 기본 제공하는 천지인· 나랏글· SKY 입력방식들은 모두 '휴대전화 입력기' 도구와 연계해서 잘 동작하게 저런 정보가 추가되었다. 지금까지 타자 시퀀스를 구하는 용도로나 사용되던 이 예제들에게 더 그럴싸한 활용 방법이 생긴 셈이다.
천지인의 경우, 사용되지 않는 * 자리에 문장부호를 다중타로 입력하는 사용자 정의 조합이 추가되었으며, # 자리에는 음절 구분자 글쇠가 배당됐다.

(3) '휴대전화 입력기' 도구는 한글 모드에서만 저렇게 기존 입력 설정을 빌려다 쓰며, 나머지 입력 모드에서는 다 자체적인 고정된 입력 기능을 제공한다.
영문은 '모비언스'라는 국내 기업에서 개발한 SmallQwerty 방식의 다중타 입력을 제공한다. 무식하게 ABC 순이 아니라 영문 글자 빈도수와 기존 쿼티 글자판을 적절히 고려하여 글쇠를 배당했는데, 생각보다 편한 걸 알 수 있을 것이다.
0번 키를 눌러서 대소문자를 바꾼 것은 한 글자에 대해서만 적용되고, 우클릭 메뉴에서 대소문자를 바꾼 것은 영구적으로 적용된다는 차이가 있다.

(4) 숫자 모드는 다른 복잡한 기능 없이 말 그대로 12키 키패드를 숫자 입력용으로만 사용한다.
그런데 여기에도 재미있는 바리에이션이 있다. 위에서부터 아래로 123 순으로 배열된 '전화기' 모드와, 그렇지 않고 역순으로 배열된 '계산기' 모드가 모두 제공되어서 사용자가 이를 선택할 수 있다. 전화기 모드에서는 기호도 말 그대로 *와 #가 있지만, 계산기 모드에서는 .와 ,가 배당된다.

(5) 끝으로, 기호 모드는 기술적으로 영문 모드와 별 다를 바 없는 다중타 방식 문자표이다.
backspace, space, enter는 모든 모드에 공통으로 존재하는 글쇠이다.
그리고 mode 버튼은 좌측 하단을 누르면 한/영이 전환되며, 우측 상단을 누르면 숫자/기호가 전환된다.
3*4 크기의 글쇠배열에서 단일타라는 범위 안에서는 내가 생각할 수 있는 가장 창의적인 기능들이 한데 깔끔하게 구현되었다. 단일타라 함은 여러 버튼을 동시에 누르거나 드래그 하는 것까지는 생각하지 않는다는 뜻이다.

3. 글쇠배열 이름 표시

그리고 이번에는 문자를 직접적으로 입력시키지는 않지만 문자 입력과 관련된 편의 기능을 제공하는 입력 도구가 하나 또 추가되었다.
'글쇠배열 이름 표시'는 메뉴에서 선택하더라도 당장 화면에 뭔가 튀어나오는 게 없다. 그 대신 사용자가 한/영이나 Shift+Space 같은 걸 눌러서 글쇠배열을 전환하면 새로 바뀐 글쇠배열의 이름이 cursor 근처에 풍선 도움말 형태로 나타난다. 짜잔~

사용자 삽입 이미지

풍선 도움말은 2.5초 정도 표시됐다가 사라진다. 한/영 상태뿐만 아니라 Caps/Num/Scroll lock을 눌러서 램프 상태가 바뀐 것도 풍선 도움말(툴팁) 형태로 표시해 준다.
그리고 툴팁이 사라진 지 5초가 경과한 상태라면, 날개셋 한글 입력기를 사용하는 텍스트 입력란이 포커스를 새로 얻었을 때에도 현재의 글쇠배열을 자동으로 잠시 표시해 준다. 반대로, 툴팁이 떠 있는 동안은 키보드 포커스가 다른 윈도우로 이동하더라도 툴팁 역시 cursor 근처를 자동으로 따라다닌다.

그리고 사용자가 텍스트의 입력을 시작하면 이 툴팁 역시 화면을 가리지 말자는 차원에서 곧장 사라진다. (응용 프로그램이 직통으로 담당하는 키 입력 말고, 날개셋 입력기로 접수되는 문자 입력 한정) 이런 여러 이벤트들을 세심하게 신경 썼다.

본인은 날개셋 입력기에 한/영 상태를 화면에 별도로 표시하는 기능이 있으면 좋겠다는 요청을 수 년 전부터 일부 사용자로부터 받은 적이 있었다. 그게 이런 형태로 드디어 실현되었다.
Windows 8 이상의 Metro UI에서는 입력 도구모음줄이란 게 없는 관계로 윈도우 포커스를 얻었을 때 현재 글자판의 대표 아이콘을 잠깐 표시해 주는 기능이 이미 있다. 그것과 기능이 약간 겹친다고 볼 수 있다.

물론, 이 기능은 한계도 있다.
날개셋 한글 입력기가 구동되자마자 자동으로 동작하는 게 아니며, 사용자가 이 입력 도구를 골라서 구동을 해 줘야만 동작한다. 내 프로그램은 자동으로 특정 입력 도구를 곧장 구동하는 기능은 아직 없다.
또한, 편집기가 아닌 외부 모듈에서는 응용 프로그램에 따라 cursor의 정확한 위치를 기술적으로 얻을 수가 없어서 화면 가장자리의 엉뚱한 위치에 툴팁이 뜨기도 한다. 이 점을 감안할 필요가 있다.

그래도 '글쇠배열 이름 표시' 기능은 날개셋 편집기의 상태 표시줄 내지 운영체제의 language bar를 응시할 필요를 상당수 줄여 주는 유용한 기능이 될 것이다. 다음 버전에서는(아마 9.3쯤) 이런 기발한 입력 도구들이 몇 개 더 추가되어서 사용자의 문자 입력에 시각적으로 큰 도움을 줄 것이다.

4. 제공 자료

(1) 예제로 제공되는 신세벌식 유형 파일을 '신세벌식 공동 개발안'이라는 이름으로 세벌식 커뮤니티에 공개된 최신 파일로 업데이트 했다. 이것이 20여 년 전 PC 통신 시절에 신세벌식 입력 방식을 처음으로 제안했고 지금까지 '신 광조'라는 이름만 알려져 있던 원 제작자분이 직접 고친 최신 입력 방식이라고 한다.

(2) 그리고 쿼티, 드보락, 콜맥에 이어서 영문 글쇠배열도 Carpalx라는 타자 행동 분석 프로그램으로 계산한 최적의 배열(배열 중 하나)이라는 QGMLWY 배열을 추가해 넣었다. 여러 바리에이션 중, ZXCV는 Ctrl 단축키를 의식해서 기존 Qwerty의 것을 그대로 유지시킨 거라고 한다. 제2군, 제3군에 이어 제4군까지 내려가면 얼마나 마이너해지려나 모르겠지만, PC용 영문 글쇠배열도 오늘날까지 연구가 완전히 중단된 게 아니라는 걸 알 수 있다.

(3) 내 프로그램의 도움말 디렉터리에는 버전 히스토리 리스트뿐만 아니라 '한글 자모 목록' 레퍼런스 txt 파일이 있다. 거기에 인터넷에서 긁어 온 '훈민정음 서문'과 '용비어천가' 텍스트를 예제로 또 추가해 넣었다. 이 분야에서 워낙 상징성이 뛰어난 텍스트이기도 하니, 방점이 가미된 그럴싸한 옛한글 예문이 필요할 때 간단히 불러와서 활용할 수 있을 것이다.

5. 그 밖에

입력 도구 외의 변화 사항들은 일일이 언급할 필요를 느끼지 못할 정도로 사소한 것들만 있다. 그나마 리드미 말고 블로그 글을 통해서라도 언급할 만한 것으로는..

(1) 날개셋 편집기의 화면 인쇄 퀄리티를 크게 개선했다. 작은 배율에서는 비트맵이 안티앨리어싱이 적용되어 부드럽게 찍힐 뿐만 아니라, '고대비 검정' 같은 검은 배경에서도 작은 글자의 뭉개지는 픽셀들이 다 사라지지 않고 정상적으로 표시된다. 어려울 것도 없고 비트맵을 찍는 옵션 하나만 살짝 바꿔 주면 됐는데 10년이 넘게 방법을 모르고 있었다.

(2) 그리고 고급 입력기의 사용자 정의 조합을 편집하는 화면에서.. 현재 존재하지 않는 새로운 상태로 가는 조합을 정의한 뒤 그걸 마우스로 더블 클릭하면, 자동으로 그 상태 번호를 등록하고 거기로 이동하게 해서 사용자 편의를 약간이나마 강화했다.

6. 끝으로.. 휴대전화(모바일)용 입력 방식에 대한 추가 잡설

(1) 사실, 휴대전화용 입력기라고 해 봐야 옛날에나 12키 layout에 매여 있었지, 지금은 꼭 그렇지도 않다. 스마트폰은 글쇠 레이아웃의 제약이 없으니 qwerty처럼 익숙한 PC용 키보드 그림을 띄워서 그걸 터치하는 방식으로 문자를 입력하기도 한다.
다만, 키보드와 완전히 같지는 않고 거기에서 규모를 약간만 줄이곤 한다. Google 단모음 입력기가 이런 틈새시장을 잘 공략한 입력 방식이긴 하다.
4단 숫자까지 사용하는 세벌식에게 이런 모바일 환경은 일면 악재로 보인다. 하지만 그런 곳에서는 신세벌식 같은 방식으로 글쇠 수를 줄인 입력 방식이 각광받고 있다.

그리고 사실은.. 모든 모바일 기기들이 다 qwerty 배열을 통째로 화면에 띄울 수 있을 정도로 화면이 크지는 않다.
교통에서도 동일 면적에 차들을 너무 많이 집어넣어서 밀집도가 지나치게 올라가면 차들이 서로 부딪칠까봐 조심하느라 빨리 달리지 못한다. 정체가 시작되며 단위 시간당 차량 소통량이 오히려 감소하게 된다.

그것처럼 작은 화면에 글쇠들이 정확하게 누르기도 힘들 정도로 너무 조밀하게 많이 있으면, 원하는 글쇠를 한 번에 누를 수 있어서 편리한 것보다 오타 때문에 불편한 게 더 커진다.
이런 이유로 인해 본인 역시 스마트폰에서 qwerty 기반 두벌식을 잠깐 써 보다가 불편해서 다시 3*4 나랏글로 갈아탔다. 적당한 버튼의 면적과 수에 대한 HCI 관점에서의 연구가 필요해 보인다.

아울러, 3*4 같은 고정적인 글쇠 패러다임도 완전히 없어질 수는 없는 게.. 시각 장애인이 있기 때문이다. 점자는 물리적인 요철로 구현해야 하니 터치스크린으로 절대로 구현할 수 없다. 요즘 같은 비주얼한 세상에도 라디오가 망하지 않고 있는 게, 수많은 영업용 자동차 운전자 때문인 것과 비슷한 이치라 하겠다.

(2) 지금까지 고안된 수많은 모바일용 한글 입력 방식 중에는 한 글쇠에 자음과 모음이 중첩 배당된 게 있다. 신세벌식에서는 그나마 중성과 종성 중첩이라지만, 저런 입력 방식에서는 두벌식이기 때문에 한 글쇠가 문맥에 따라 초중종성 역할을 모두 담당하게 된다.

가령, 김 민겸 님(☞ 홈페이지)이 고안하신 입력 방식은 '으'에다가 ㅡ를 덧붙여서 ㅎ이 되는 동작이 있다..! 이건 워낙 특이한 동작이기 때문에 날개셋에서도 거의 7.x대 버전에서 0으로 만드는 특수 낱자까지 도입한 뒤에야 겨우 구현 가능해졌다. 그래도 복잡한 전용 특수 오토마타가 필요하며, 이렇게 너무 변칙적인 입력 로직은 내 프로그램에서 입력 순서 계산 같은 자동화도 제대로 못 해 준다.

그리고 웹사이트의 설명을 아무리 읽어 봐도.. 자음과 모음이 그렇게 중첩돼 버리면 음절 경계 구분은 어떻게 하는지, 초성은 그렇게 입력한다 쳐도 종성에서 '으으'와 '읗' 같은 건 어떻게 구분하는지, 뭔가 보편적인 규칙이 떠오르질 않았다. 내부 로직이 어떻게 돼 있는지 리서치를 할 시간이 없어서 본인은 그런 입력 방식들은 예제로 제공하지 못하고 있다.

사실, 모비언스에서도 영문뿐만 아니라 한글 입력 방식을 제안한 것이 있는데 거기서도 자음과 모음 중첩이 존재한다. 이 역시 비슷한 이유로 구현하지 못하고 내 프로그램에서는 영문 입력 방식만 얹었다.

Posted by 사무엘

2017/10/09 08:32 2017/10/09 08:32
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1414

Trackback URL : http://moogi.new21.org/tc/trackback/1414

Leave a comment

날개셋 타자연습 3.8

날개셋 프로그램의 개발 패턴은 십중팔구 입력기와 타자연습이 같이 버전이 올라가거나, 입력기만 바뀌는 형태였다. 본인에게는 아무래도 입력기가 비중이 더 높은 프로젝트이니 말이다.

하지만 오늘은 좀 이례적인 소식을 전하고자 한다. 입력기는 변화 없이 타자연습만 먼저 다음 버전이 완성· 공개되었다. 입력기 다음 버전(9.1)의 개발 일정은 많이 지연된 반면, 타자연습은 이미 2개월 가까이 전에 작업이 완료된 게임 관련 개선 말고는 추가 작업의 여지가 거의 없는 상태이기 때문이다. 둘의 릴리스 날짜를 동일하게 맞출 수 없게 됐다.

타자연습의 변화 사항은 저게 전부이다. 게임에서 방어력 업그레이드가 각 주인공별로 성능이 다른 장갑(armor)으로 바뀌었으며, 큰 글꼴 모드에서 1024*768 전체 화면이 정확한 해상도로 진입하지 않던 문제를 해결했다. 다른 변화 사항은 없으니, 게임을 하지 않는 분이라면 굳이 새 버전을 구할 필요가 없다.

새 버전은 3.7에 비해 절대적인 작업 분량이 많다고 보기 어렵다. 그러나 굉장히 오랫동안 동일하게 유지되었던 게임 시스템의 일부가 크게 바뀌었다는 상징성을 감안하여 3.7에서 0.01 대신 0.1을 올린 3.8로 버전을 정했다. 입력기와 타자연습이 나란히 0.1씩 올라가서 동시에 공개됐으면 참 좋았겠다만..
이제 게임을 하다가 armor를 지급받고 나면 HP 게이지 밑에 노란색의 armor 게이지도 추가로 생기는 것을 확인해 보시기 바란다.

올해도 벌써 8월이 다 지나고 아침과 저녁 날씨는 반쯤 가을처럼 돼 간다. 이랬는데 정작 9~10월엔 '늦더위 기승' 이러지나 않았으면 좋겠다.
지난 상반기 때는 여러가지 이룬 일들이 많아서 개인적으로 행복했다. 복합 낱자 입력 로직 생성기를 다 완성하고 예정에 없던 24픽셀 큰 글꼴 지원을 구현해서 입력기가 깔끔하게 9.0대에 진입했다. 거기에다 타자연습도 게임 시스템 개편을 이렇게 이뤘다.

하지만 이번 여름방학 기간은 2개월 간격으로 입력기 8.9와 9.0을 나란히 만들어 냈던 저 때와 달리, 솔까말 좀 슬럼프에 빠져서 생산성이 크게 떨어진 채로 보냈다.
뭐 핑곗거리를 만들자면 끝도 없겠지만, 무더위, 뒤숭숭한 나라 사정, 그리고 '자신감과 확신(confidence) 결핍'으로 인한 의욕 감퇴 때문에 유난히 방황했다.

외부적으로는 "이 와중에 이런 마이너한 프로그램 계속 만들어 봤자 니 신세가 펴지는 거 있나" 같은 무력감,
그리고 내부적으로는 지금 이 디자인이 정말 이보다 더 나을 수 없는 진짜 최적이 맞나.. 이런 고민이 본인을 압박했다. 일이 손에 잡히질 않았다. 9.0까지 실컷 잘 만들어 놓고는 갑자기 내가 왜 이러나 나 자신조차 알 수 없었다.

그러다가 여름 동안 컨디션 전환을 위해 여기저기 여행을 다니고, 특히 광복절 연휴 타이밍 때 강원도도 과감하게 다녀온 뒤에야 조금씩 컨디션이 회복됐다. 최적이 맞는지, 이대로 개발하면 되겠는지 승인과 결재를 기다리고 있던 머릿속 여러 밀린 proposal들이 드디어 처리됐다. 요 기능은 마침 저 아이디어와도 연계가 된다는 식으로 답이 딱딱 나왔다.

2017년 상반기에 저런 것들을 이뤘다면, 하반기의 키워드는 '입력 도구'이다. '화면 키보드, 부수로 한자 입력'처럼 마우스로 조작하는 보조 UI들 말이다. 이것들도 5.x 시절에 완성되고 나서 수 년 동안 변화가 거의 없었다.
제5의 '빠른설정'이 '복합 낱자 입력 로직 생성기'였다면, 제5의 '입력 도구'는 '휴대전화 입력기'가 될 것다. 이미 있는 화면 키보드와 기능이 일부 겹치기도 하지만 한편으로 자체적인 입력 방식과 독창적인 기능 구조를 갖췄다.

이것뿐만 아니라 입력에 도움을 주는 도구들을 몇 개 더 추가한 뒤, 현재 계획으로는 10월쯤에 입력기 9.1을 내놓을 계획이다. 원래는 이걸 지금 무렵까지 끝내고 싶었지만 그건 물 건너갔으니..
9.1 다음으로 대단원을 장식할 마지막 추가 기능이 무엇인지는 이미 여러 번 말한 적이 있었고, 또 떠벌리는 건 입만 아플 테니 이 자리에서는 언급을 생략하겠다.

요즘은 어지간한 프로그램들은.. 심지어 복잡한 게임조차도 번거롭게 받아서 하드에 설치할 필요 없이 웹페이지에서 바로 구동하는 게 대세가 됐다.
자체 폰트를 사용하는 편집기라든가 타자연습, 타자 게임은 자바스크립트로 돌릴 수 있을 것이다. 하지만 운영체제용 IME는 그 특성상 여전히 철저히 local 환경에서 네이티브 코드 기반으로 돌아가는 영역으로 남지 싶다. Windows 운영체제 자체가 싹 다 뒤집어 엎어지지 않는 한 말이다.

이렇게 눈에 보이는 새 기능 말고, 내부의 리팩터링 쪽도 욕심이 생기는 게 있다. 본인이 지금까지 다음과 같은 사항들 얘기를 한 적은 없었지 싶다.

(1) 현재 내 프로그램 내부에서는 입력 스키마가 문자 생성기를 포함하는 형태로 구현돼 있다. 그래서 제어판에서 한 입력 항목의 '입력 스키마'를 딴 걸로 바꾸면 입력 스키마뿐만 아니라 문자 생성기도 같이 바뀌기도 한다.
하지만 지금 프로그램을 다시 만든다면 두 계층을 명백하게 분리해서 입력 스키마와 문자 생성기를 한데 묶은 '입력 항목'이라는 계층 더 명확히 할 것이다. 심지어 한 입력 항목에 입력 스키마와 문자 생성기 말고 다른 개체가 붙을 수도 있게 말이다. 이건 유니코드에 한글 자모가 더 추가되고 날개셋 설정 저장 파일 포맷이 2008년 이래로 또 바뀌는 정도의 대격변이 불가피해진 먼 미래에나 화폐 개혁하듯이 추진할 것이다.

(2) 문자 생성기는 오토마타나 낱자 결합 테이블 같은 입력 설정 '데이터'와, 스택이나 조합 상태 같은 '내부 상태' 정보 계층을 완전히 분리할 것이다.
날개셋 한글 입력기를 설계할 때 처음부터 이 정도 추상화 수준을 생각하지 못한 게 아쉬움으로 남는다. 이 역시 (1) 만만찮게 거의 2020년대 이후에 버전 10.0대의 초장기 과제로나 실현 가능할 듯하다.

이런 썰들을 길고 두서없이 남기며 타자연습 새 버전을 조촐히 기념하고자 한다. 어서 입력기도 다음 버전이 완성되기를..

Posted by 사무엘

2017/08/30 19:35 2017/08/30 19:35
Response
No Trackback , 5 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1399

Trackback URL : http://moogi.new21.org/tc/trackback/1399

Comments List

  1. 김선호 2017/09/03 18:07 # M/D Reply Permalink

    안녕하세요. 좋은 프로그램 감사히 잘 사용하고 있습니다.

    다름이 아니라.. 제가 예전 날개셋 8.0버전을 사용하다가 어제 9.0으로 업데이트를 했습니다. 그런데 날개셋 편집기에서 완성형 글꼴(굴림, (굵은)바탕체)만 사용할 수가 있습니다.
    조합형 글꼴들이 많은데 텍스트의 저장 형식을 utf-8이나 ansi, 조합형 등으로 해도 완성형 글꼴로만 변경이 되지 조합형 글꼴이 나타나지 않습니다. 프로그램을 재설치 해봐도 마찬가지입니다. 이거 어떻게 해야 되는 건가요?

    1. 사무엘 2017/09/03 20:57 # M/D Permalink

      안녕하세요?
      UTF-8이나 조합형 같은 텍스트의 인코딩은 글꼴의 형태와는 아무 관계 없는 개념이고요,

      편집기의 '편집 화면 설정' 대화상자에서 "완성형(W)" 글꼴을 맨 위에 있는 "사용 안 함"으로 지정해 보시기 바랍니다.
      그럼 그 위의 "한글(H)"에 지정돼 있는 조합형 글꼴만 표시될 것입니다.
      이건 8.0 9.0 버전 차이와는 무관한 동작 방식입니다.

  2. 김선호 2017/09/03 21:24 # M/D Reply Permalink

    아아 감사합니다. 완성형 글꼴 부분을 사용안함으로 했더니 이상없이 나옵니다. 이렇게 간단한 것을!
    좋은 저녁 되세요~

  3. 동영 2017/10/07 20:15 # M/D Reply Permalink

    긴 연휴 기간 중 소리소문없이 업데이트!
    잘 쓰겠습니다. 감사합니다!

    1. 사무엘 2017/10/07 21:32 # M/D Permalink

      앗, 빠른 확인에 감사드립니다. ^_^
      이번 9.1은 사실상 보조 입력 도구 쪽밖에 변화 사항이 없고 그나마도 넣고 싶었던 기능을 다 넣지 못한 버전이지만 그래도 내부적으로 굉장히 많은 게 바뀌고 추가됐답니다.
      한글날에 새 버전의 자세한 소개글이 올라올 예정입니다.

Leave a comment

다음 버전 개발 근황

날개셋 한글 입력기 9.0과 타자연습 3.7이 나온 지 한 달 정도가 돼 간다.
다음 버전은 입력기 9.1과 타자연습 3.71 또는 3.8이 될 듯하다. 현재는 입력기보다 타자연습의 작업이 더 많이 진행되었으며, 타자연습의 다음 버전은 다른 변화는 없이 "게임 업그레이드"가 될 가능성이 높아져 있다. 그 구체적인 내역은 다음과 같다.

1. 타자 게임의 체력· 방어력 시스템 개편

본인은 컴퓨터 소프트웨어의 여러 분야들 중 게임은 하는 것과 만드는 것 모두 별 소질이나 인연이 없다. 하지만 그럼에도 불구하고 나름 게임 개발자 겸 기획자의 코스프레라도 한 경험을 말하자면 날개셋 타자연습의 게임을 설계· 개발한 이력을 내세우겠다.

날개셋 타자연습의 게임을 구성하는 현재와 같은 12개 레벨과 이들의 난이도· 컨셉, 그리고 엔딩까지 대략 20분에 달하는 플레이 컨텐츠는 지금 생각해도 충분히 잘 만들어졌다고 생각된다. 더 고칠 필요가 없다. 특별히 4단 자리(맨윗자리)와 겹받침 글쇠를 집중 공략하는 레벨 9~11의 지옥훈련은 정말 세벌식 전용 타자연습이니까 볼 수 있는 특징이다.
오타 페널티가 있는 놈(한별. 잠시 동안 타자를 할 수 없음), 그와는 정반대로 정확도가 100%가 아니어도 단어가 인식되는 놈으로(미르) 주인공을 차별화한 것도 마음에 든다.

하지만 게임의 모든 시스템이 만족스러운 건 아니다. 각 레벨별로 더 다양한 색상의 배경을 넣었어야 했는데 레벨 3~5는 그 당시 뭔 생각을 하고 배경을 디자인 했는지, 하늘과 땅 컨셉을 너무 많이 우려먹어 있다.
그리고 배경에도 애니메이션이 좀 있어야 하는데 그걸 구현하지 못했다. 가령, 레벨 2는 별들이 반짝이거나 '우주 여행' 화면 보호기처럼 쓱쓱 입체적으로 날아다니는 게 원래의 내 의도였다. 텍스처 비트맵 배경은 텍스처가 조금씩 스크롤되고, 다른 그러데이션 무늬 기반 배경은 허접한 팔레트 스크롤 같은 거라도 넣어서 움직이게 말이다.

그래픽 다음으로 음악은? 레벨별로 분위기를 고려해서 지금과 같은 여섯 곡을 오랫동안 고민한 끝에 선정했으며, 이 역시 큰 틀에서는 후회가 없다. 명곡이긴 하지만 다들 유행 지난 1990년대의 너무 오래된 곡인 게 문제일 뿐..
딴 걸로 교체하려 해도 mp3 음원이 대세가 된 요즘 세상에 미디 파일을 구하기란 몹시 힘들 듯하다.

그래픽이나 사운드 같은 외형적인 요소 말고 게임 메카닉 알고리즘 차원에서 내가 제일 문제 의식을 느끼고 우선적으로 고치고 싶었던 건 주인공의 HP와 방어력 시스템이다. 의도는 "오타에 취약해서 다루기 힘든 주인공에게 그에 상응하는 맷집을 더 줘서 어려운 레벨에서 더 오래 버틸 수 있게 한다."이긴 하지만, 체력(HP) 시스템이 주인공별로 쓸데없이 너무 복잡하게 만들어졌다는 게 오랜 세월 동안 느껴졌다.

타자 게임을 처음 만들던 당시에는 스타크래프트의 방어력 업글 시스템에서 착안하여 지금과 같은 5단계 업글을 도입했었다. 게임을 첫 레벨에서부터 차근차근 시작하면 대략 레벨 8 무렵부터 방어력이 5단계로 풀업 되는 식이었다.
그러나 앞으로는 요 시스템을 갈아엎고, Doom/Quake의 시스템에서 착안한 armor(장갑/갑옷) 기반 방어력 시스템을 도입할 것이다.

세 주인공은 초기 체력과 최대 축적 가능 체력이 100으로 모두 동일하게 맞춰진다. 그리고 없애지 못한 단어로 인해 입는 대미지 역시 기본적으로 동일하며, 체력 회복 바이러스를 맞았을 때 늘어나는 체력의 양도 동일하다.
현재 아름은 시간이 흐르면 100까지 체력을 서서히 자동 회복하며, 한별은 레벨을 클리어 했을 때 체력이 50 미만이면 일부를 보상하는 기능이 있다. 한편, 미르는 점수가 일정 간격에 도달했을 때 체력을 보상하는 기능이 있다. 이런 보상 시스템은 괜히 복잡하고 게임에서 실질적으로 별 도움이 안 되어 보이는 관계로, 모두 폐지할 예정이다.

그럼 세 주인공이 차이가 나는 부분이 무엇이냐 하면 딱 하나, armor point가 있을 때의 작용 효과이다.
예전에 '방어력 n단계 업그레이드'라는 효과를 내던 바이러스는 'armor 보충'으로 바뀌며, 이때 armor는 언제나 100으로 '만땅' 상태가 된다.

armor가 있는 상태에서 대미지를 입으면 한별의 경우, armor는 (1) 현재 남아 있는 armor 양과 (2) 전체 대미지의 1/3 둘 중 최소값만치 깎인다. armor가 음수가 될 수는 없으니까.. armor는 자기가 깎이는 양의 3배에 달하는 대미지를 커버하고, 그 과정에서 체력은 그 전체 대미지의 40% 남짓만치만 감소하게 한다. 즉, 체력 대미지(5/12)와 armor 대미지(1/3)를 합해도 3/4이니, 전체 합이 원래 대미지보다 더 작다. armor가 몸빵에 굉장히 큰 기여를 하는 셈이다.

특성이 세 주인공의 중간에 속하는 아름은 armor와 체력이 그냥 정확하게 반반씩 깎이니 armor는 그야말로 추가적인 보조 체력 그 이상도 이하도 아니다.
미르는 타자 편의가 가장 뛰어난 대신 armor의 운용 효율이 가장 떨어진다. armor를 먹어도 체력 방호 효과는 1/3 남짓에 불과하고, 체력 대미지와 armor 대미지를 합하면 1보다 크다. 오랜 고민 끝에 이런 식으로 시스템을 개편하기로 잠정 결론을 내렸다.

그러므로 이제부터 날개셋 타자 게임에서는 방어력 업그레이드 단계 같은 건 존재하지 않는다. 그 대신 게임을 하면서 hit(health) point뿐만 아니라 armor point도 마치 스타에서 미네랄과 가스처럼 이중으로 신경 쓰게 된다. 가스가 없으면 고급 유닛을 만들 수 없듯, 체력이 아무리 많아도 armor가 없으면 피격 때 체력을 훨씬 더 빠르게 급격히 잃게 된다. armor의 양은 체력 막대 밑에 노란식으로 표시된다.

어떤 주인공이든 대미지를 입었을 때 armor의 감소량은 체력보다 더 적으면 적지 많지는 않다. 하지만 armor 보충 바이러스는 체력 보충 바이러스보다 등장 빈도가 낮다. 그리고 armor가 아무리 많이 남아 있어도 체력이 0이 돼 버리면 말짱 도루묵이고 게임 오버이니, 죽기 직전에 당장 더 중요한 것은 armor보다는 체력이다. 이렇게 게임의 양상이 이전보다 다채롭게 변할 것이다. 이 관계를 표로 정리하면 다음과 같다.

  체력 장갑
처음 시작할 때는 만땅(100)임 없음(0)
보충 바이러스 절반(50)씩, 하지만 더 자주 등장 단번에 만땅(100) 보충
맷집 장갑 없을 때 입는 대미지 양은 모든 주인공 동일 장갑의 방어력은 주인공마다 차이 있음
중요도 아무리 장갑이 많이 남아 있어도 체력이 0이 되면 게임 끝, 말짱 도루묵 optional. 하지만 장갑 없이 체력만으로는 상위 레벨에서 오래 버티기 힘듦

이전에는 주인공이 최고의 맷집과 방어력을 갖추려면 체력도 150이니 120이니 하는 최대치로 축적해 놓고 방어력 업그레이드도 여러 레벨들을 거치면서 5단계까지 해 놔야 했다. 하지만 새로운 시스템에서는 원래 체력 상태에서 'armor 보충' 바이러스 한 번만 받으면 이론적인 최대의 맷집과 방어력 상태가 갖춰진다. 아주 단순해진다.

물론 축적 가능한 체력의 절대적인 양은 예전 시스템 때에 비해 감소했다. 그 대신, 체력 회복 및 armor 보충 바이러스가 이전보다 약간 더 자주 등장하고, 회복시켜 주는 양도 이전보다 더 많다. 체력 회복은 세 주인공 공통으로 50으로, 전체의 절반을 그냥 준다. 축적에 의존하지 말고 그때 그때 바이러스에 의한 보급 뽀록에 의존하는 가중치가 더 커진다.
이렇게 시스템을 개편해 놓고 내가 몇 판 게임을 해 보니 끝탄을 깨거나 못 깨고 죽는 빈도는 그럭저럭 별 차이 없는 것 같다.

안 그래도 타자 게임은 또 건드리기가 민망한 굉장한 레거시 코드가 돼 있다. 내 게임이 사용한 DirectDraw, DirectMusic 이런 라이브러리도 완전 한물 간 레거시 기술들인 거 본인도 잘 안다. =_=;;
하지만 지난번 날개셋 한글 입력기 9.0에서 24픽셀 비트맵 작업을 하는 과정에서 먼지 쌓였던 타자 게임 쪽 코드를 오랜만에 건드리게 되었는데, 여기에서 동기와 자극을 받아 오랜 숙제로 남아 있던 체력· 방어력 시스템 개편을 해치웠다. 이건 그래픽· 사운드와는 무관하게 0순위로 꼭 갈아엎고 싶었기 때문이다.

2. 그 외의 게임의 변경· 개선 사항

(1) 150% (144dpi) 이상 배율에서 게임이 1024*768 해상도의 "전체 화면"에서 실행됐을 때, 화면이 정확하게 모니터 전체에 꽉 차지 않고 어중간하게 부분적으로만 차던 문제를 해결했다. 원인을 한참을 찾아 보니, 운영체제가 전체 화면 해상도까지 쓸데없이 high-DPI scaling을 해서 그런 것이었다. 그래서 제멋대로 1024*768보다 약간 높은 해상도로 바꿔서 전체 화면을 들어갔었다.

기존 3.7의 경우, EXE 파일에 대한 속성 열어서 호환성 탭 - "높은 DPI 설정에서 디스플레이 배율을 사용하지 않음" 옵션을 수동으로 켜 주면 문제가 해결되고, 다음 버전에서는 이게 exe 차원에서 자체적으로 적용되게 했다.
저 옵션 자체는 high-DPI scaling이 존재하지 않는 구닥다리 Windows 7에도 있던데, 이전 OS에서는 무슨 기능을 했는지 궁금하다.

(2) 이 기회에 비트맵 글꼴 말고 게임에서 출력되는 다른 한글 문장들의 글꼴을 너무 식상한 굴림 대신 '맑은 고딕'으로 바꿨다. 이런 것도 노력 대비 프로그램의 낡은 이미지의 쇄신에 기여하는 바가 크다.
다만, 맑은 고딕은 잘 알다시피 같은 크기라 해도 상대적인 크기, 줄 간격이라든가 종횡비 같은 글꼴의 기본적인 metric이 굴림· 바탕류와는 완전히 다르다. 그래서 불러들이는 글꼴 이름만 달랑 바꾼다고 되는 게 아니고 전반적인 문자 배치 방식도 다같이 보정하고 바꿔 줘야 했다.

3. 화면 키보드의 live preview

날개셋 한글 입력기가 제공하는 보조 입력 도구 중에는 '화면 키보드'가 있다.
얘는 단순히 현재 선택돼 있는 입력 항목의 글쇠배열을 static하게 보여주는 기능만 있다가, 2년쯤 전에는 실제로 눌러지거나 떼어진 글쇠를 시각적으로 highlight해 주는 옵션이 추가되었다. 그 뒤로는 큰 변화가 없이 오늘날에 이르렀다.

그러다가 이번에는 '실제 입력 문자 표시'라는 꽤 재미있는 옵션이 우클릭 메뉴에 추가되었다. 얘는 글쇠의 입력이 끝날 때마다 글쇠배열들의 수식을 현재 변수값을 기준으로 재계산한다. 그래서 지금 이 글쇠를 눌렀을 때 실제로 입력되는 문자가 화면에 정확하게 표시되게 한다.

두벌식을 사용하고 있었다면 중성을 입력하는 순간부터 자음들 모양이 초성에서 종성으로 바뀌며, 조합이 종료되거나 초성을 입력하기 시작했을 때 다시 초성으로 돌아온다. 세벌식 390의 경우 / 자리는 ㅗ를 입력 가능한 문맥에서는 ㅗ가 됐다가 다시 /로 돌아온다.

복벌식이나 신세벌식처럼 상황에 따라 여러 글쇠들의 의미가 완전히 달라지는 입력 방식을 쓰고 있을 때는 이 옵션을 켜고 화면 키보드를 사용하는 게 굉장히 큰 도움이 될 것이다. 처음인 왼손과 오른손에 세벌식과 두벌식의 자음이 모두 표시되어 있지만, 두벌이나 세벌로 타자가 시작되면 모든 글쇠배열이 두벌이나 세벌 기준으로 싹 바뀌며, 조합이 종료되면 배열이 다시 초기 상태로 돌아오기 때문이다!
본인은 이런 기능의 필요성을 이미 수 년 전부터 느끼고 있었지만, 보조 입력 도구 쪽 기능을 강화하기 시작한 이번 버전에서야 이 기능을 구현해 넣을 수 있었다.

입력기는 현재 이 아이템 하나만 작업이 됐다. 예전의 8.8 버전에서는 '빠른설정'이 하나 더 추가됐는데 다음 9.1에서는 새로운 '입력 도구'들이 여러 개 더 추가될 것이다.
보조 입력 도구는 먼 옛날 5.3~5.5x 버전 시기에 화면 키보드, 한손 입력기, 문자표, 부수 한자 입력 이렇게 4개가 추가된 이래로 지금까지 아무 변화가 없었다. 지금까지의 통상적인 기능 추가와는 성격이 다른 분야에 모처럼 사용자의 입력에 시각적인 피드백과 각종 편의를 제공하는 기능들이 잔뜩 도입될 것이다.

Posted by 사무엘

2017/07/09 08:30 2017/07/09 08:30
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1379

Trackback URL : http://moogi.new21.org/tc/trackback/1379

Comments List

  1. 신세기 2017/07/17 22:23 # M/D Reply Permalink

    타자연습게임이 업그레이드 되는군요! 항상 아름이로 하면서 레벨 마지막이나 무중력 바이러스에서 최대한 시간을 끌면서 HP를 채우곤 했는데 이젠 시간을 끌지 않아도 되겠네요!

    1. 사무엘 2017/07/18 07:25 # M/D Permalink

      네, 그렇습니다. 다음 버전에서는 그럴 필요가 없어집니다. ^^
      진작에 했어야 할 개선 작업이 드디어 이뤄질 예정입니다.

Leave a comment

1.
바로 며칠 전에 날개셋 한글 입력기 9.0과 함께 공개된 타자연습 3.7의 경우, 명목상 변화 사항은 (1) 프로그램 명칭 표기의 변경과 (2) 144dpi 24픽셀 글꼴 지원이었다. 프로그램 UI가 전반적으로 적절하게 150% 확대될 뿐만 아니라 이때는 게임도 잘 알다시피 640*480이 아닌 1024*768 해상도에서 실행되게 했다.

이것 말고 프로그램 기능의 변화는 전무하다. 그러니 타자연습 3.7은 입력기에 적용된 변화를 그대로 같이 수용한 것만이 전부가 될 것이라 여겨졌다.
그러나 작업을 마친 후 타자연습을 테스트를 해 보니, 굳이 직전 버전에만 국한되지 않는 여러 잡다한 문제들이 보였다. 그래서 6월 13일 정식 공개 후에도 불가피하게 프로그램을 몇 차례 고쳐서 재업로드를 해야 했다. DirectDraw 구동하는 낡아빠진 코드를 도대체 얼마 만에 재복습을 한 건지 원...;;

과거 Windows 7 이하 시절에는 안 이랬던 것 같은데, Windows 10 기반의 4K~5K 대형 모니터 컴에서 타자 게임을 전체 화면에서 돌려 본 결과, (1) 점수와 HP가 출력되는 화면 아랫부분이 의도했던 흰색이 아니라 그냥 시꺼멓게 칠해지는 문제가 있었다. 창 모드에서는 이상 없음.
이 문제는 뭐 텍스트를 찍고 색칠을 하는 방법을 바꿔서 해결했다.

그리고 이건 좀 심각한 문제인데, (2) 전체 화면으로 게임 진행 중에 Alt+Tab, win 등으로 프로그램 창을 빠져나갔다가 돌아오는 과정에서 가끔 오류가 발생했다. 소실했던 surface를 복원하는 과정에서 문제가 있었던 것 같다. Windows 7 이하에서는 가끔 배경 화면이 다시 그려지지 않던 것이 Windows 10부터는 그냥 씨크하게 곧장 오류와 crash로 이어졌다.
이 문제도 단순 실수로 추정되는 코드 몇 줄을 정리하고 나니 바로 해결되었다.

끝으로, 미처 생각하지 못했던 괴이한 문제가 하나 더 있었다.
기존의 640*480 해상도는 어느 모니터에서나 그럭저럭 화면이 꽉 찬 형태로 실행되었으며, 요즘 같은 와이드 화면에서는 좌우에만 모니터 차원에서 사용되지 않는 검은 사각형 영역이 생겼다.
그러나 1024*768은 그렇지 않더라. SetDisplayMode로 분명히 1024*768을 지정했음에도 불구하고 실제로 비디오 카드 차원에서는 (3) 1280*960 정도로 추정되는 더 큰 화면이 설정된다. 그리고 게임 화면의 오른쪽과 아래에 흰 여백이 불필요하게 생기는 것이었다.

단순히 제어판의 디스플레이 설정에서 1024*768로 맞췄을 때는 이렇지 않고 화면이 꽉 찬 채로 저해상도로 바뀐다. 그런데 DirectDraw를 통해 1024*768로 맞추면 왜 저렇게 되는지, 다른 구형 게임들도 다 저런지 잘 모르겠다.
예전엔 이런 현상을 본 적이 없었는데 최신 운영체제에서 새로 발생하는 문제인 것 같다. 위의 세 이슈 중 (3)만은 이렇다 할 원인과 해결책을 파악하지 못했다.

이런 뜻하지 않은 문제 때문에 타자연습의 작업량이 예상보다 더 많아졌다.
그 밖에 혹시 타자연습을 오래 많이 써 보신 분은 경험적으로 이미 아실지도 모르겠는데..
오타를 낸 뒤 그 뒤의 한글을 조합하다가 그대로 home, ctrl+왼쪽 화살표 등으로 cursor를 급격하게 앞으로 옮기면 앞, 또는 조합 중이던 글자에 대한 오타 처리가 일시적으로 제대로 되지 않는 경우가 있다. 이 문제도 이 기회에 같이 해결했다. 이래저래 한글 입력기뿐만 아니라 타자연습도 나름 의미심장한 버전업을 달성했다.

2.
아래 그림은 날개셋 한글 입력기가 제공하는 옵션들을 모두 사용했을 때 backspace 글쇠가 동작하는 방식을 순서도로 나타낸 것이다. 로직을 이런 식으로 그림으로 표현할 생각을 지금까지 안 하고 지냈는데, 한번 그려 보니 굉장히 그럴싸해 보인다.

사용자 삽입 이미지

요즘이야 순서도는 "코끼리를 냉장고에 넣는 법", "정신승리법"처럼 뭔가 병맛스러운 절차를 기술할 때에나 개그 목적으로 참 안습하게 쓰이는 경우가 많다만.. 이것도 나름 20세기 중반쯤에 국제 표준 규격이 제정되어서 전세계에서 동일하게 통용되는 물건이다. 대표적으로 둥근 사각형은 단말(시작과 끝), 직사각형은 처리, 마름모는 분기.. 이런 식으로 말이다.

재래식 순서도는 한눈에 봐도 참으로 GWBASIC의 GOTO스럽게 생겼다. 그래서 NS 흐름도라고 스파게티 코드 분기를 지양하고, 열고 닫고 갔다가 되돌아오는 거.. 코드로 치면 들여쓰기를 그대로 시각화해서 구조화 프로그래밍의 논리 순서를 더 깔끔하게 그릴 수 있게 한 물건도 있다.

그래도 어느 것이든 튜링 기계로서 계산 능력은 서로 동등하다. 종료 조건이 실행 중에 결정되는 분기가 가능하고, 포인터(메모리 어느 값을 읽고 쓸지를 또 메모리로부터 읽어서 결정할 수 있는..)를 구현할 수 있다면 말이다.

3.
맥용으로 날개셋 한글 입력기가 최소한의 핵심 엔진 엑기스만 포팅해서 만들어진다면..
보조 입력 도구나 방대한 제어판 GUI, 비트맵 글꼴 기반 텍스트 에디터 같은 건 몽땅 제낀다.
시스템 계층과 편집기 계층도 빼고 ist 파일을 불러들여서 '한 입력 항목'의 입력기 계층만 제공하는 간단한 macOS용 한글 IME부터 시작하게 되지 싶다. 범위를 이렇게까지 좁혀도 Windows에 특화돼 있는 미세한 키보드 조작 제어라든가 타이머 같은 건 어떻게 구현할지 아직까지는 답을 모르겠다.

게다가 Windows와 맥(그리고 어쩌면 타 OS도)은 가상 키코드 체계도 서로 완전히 다르다. 기본 입력 스키마의 글쇠배열이야 가상 키코드에 구애받지 않는 절대적인 문자 글쇠만을 인식하니까 상관없지만, 추가적인 글쇠 인식 옵션이나 고급 스키마는 가상 키코드를 직통으로 사용하기 때문에 이런 것들을 어떻게 보정할지 생각을 해야 한다. 장기적으로는 입력 설정 파일의 메타데이터 내지 헤더에 이 가상 키코드의 문맥 정보도 들어가야 할 것으로 보인다.

4.
예전에도 몇 차례 글로 밝힌 적 있지만, 본인은 이 바닥을 판 지 15년이 훌쩍 넘었으며 이 바닥 사정을 그럭저럭 잘 안다.
한글에 대해서, 한국어에 대해서 그리 많은 걸 바라지는 않는다. 비현실적인 환상은 조금씩 내려놓기 시작했다.
미군 철수와 대남적화를 걱정하게 생긴 와중에 한글이 감히 무슨 세계 언어를 받아 적는 문자로 등극하는 걸 바라지는 않는다. 넘사벽급의 돈줄과 연구 인프라, 학술용어와 정보 데이터를 갖추고 있는 국제어 영어의 지위와 인지도를 타 언어가 흔들 수 있을 거라고 생각하지는 않는다.

심지어 미국이 경제· 군사적으로 몰락한다 해도 영어만은 아마 몰락할 일이 없지 싶다. 정작 언어학자· 전공자 전문가들은 민감한 사항이라면서(문화 상대주의? 언어 제국주의?) 이런 언급을 금기시하고 꺼리긴 한다만, 내 개인적으로 생각하기에는 라틴 알파벳과 영어는 여타 언어들에 비해 구조적으로 더 기계 친화적이고, 덜 지저분하고 경쟁력 있고 더 우수한 구석이 있다고 본다.

기왕 우리는 영어를 외국어로서 힘들게 학습해야 하는 처지로 태어났고, 국제어 영어와는 구조가 너무나 다른 군소언어를 쓰는 문화권을 갖게 돼 버렸는데 그럼 이 상태에서 우리가 할 수 있는 게 무엇일까? 결국 어설프게 남을 따라가고 뒤쫓는 연구만 해서는 절대 남을 앞설 수 없다. 안 그래도 시작점도 다르고 투입되는 자금의 규모도 쨉이 안 되는데 무슨 승산을 바라는가? 결국 남과는 완전히 다르고 이 처지에서 우리만이 할 수 있는 솔루션을 만들고 개척해야 한다.

우리는 알파벳처럼 쭈욱 글자를 있는 대로 늘어놓기만 하는 풀어쓰기 문자가 아니라, 어쩌다 보니 낱자 구분과 음절 경계 구분이 있고 모아쓰기를 하는 한글 같은 문자를 쓰게 됐다. 그리고는 그런 특성이 있으니 한글이 참 우수하다고 자랑을 늘어놓는다.

그러면 단순히 모아쓰기를 기계적으로 구현해 주는 한글 오토마타만 만들어 넣는 것으로는 충분치 않다. 그런 경계 구분 계층이 있고 IME라는 소프트웨어가 필요한 걸 괜히 거추장스러운 부담, 오버헤드로만 여겨서는 안 된다. 기왕 그런 게 있다면 이를 이용한 더 창의적이고 편리한 활용을 할 수 있어야 한다. 글쇠배열 연구나 언어 사전 자동 완성 같은 방법론은 타 언어를 기준으로도 동일하게 적용 가능한 것이니 한글의 구조만을 이용한 고유한 improvement가 있어야 한다.

그리고 이 분야에서 진짜 창의적인 기능을 넣으려면 결국 궁극적으로 두벌식이 아닌 세벌식 글자판을 써야 한다. 이미 1950년대에 공 병우 박사라는 희대의 천재가 기계식 타자기를 기준으로 한글 기계화의 큰 물꼬를 터 놨다. 세벌식이 타자기에서는 직관적인 입력과 기계간 글자판 통일을 실현했다면, 컴퓨터에서는 단순 모아쓰기 입력을 넘어서 동시치기와 더 수월한 입력· 수정을 실현할 수 있다.

이것이 날개셋 한글 입력기의 일관된 개발 이념이다. 괜히 한글 갖고 타 언어나 문자에다 오지랖을 부리는 건 내 관심사가 아니고, 그저 우리가 자국어를 입력할 때부터나 make the most out of를 하자는 것이다.
이런 게 있으면 아무리 현실에서 영어가 더 중요하더라도 한국어와 한글이라는 게 존재하는 게 그저 거추장스러운 잉여처럼 느껴지지 않을 수 있고 뭔가 존재의 의의를 찾을 수 있지 않겠는가? 더 나아가 이 좁아터진 나라와 민족 정체성에 대해서도 일말의 자부심이 더 생기지 않을까?

5.
전국민이 개인 전화기 겸 디지털 카메라를 들고 다니는 오늘날로서는 도저히 상상이 안 되겠지만.. 1990년대까지는 증명 사진을 하나 찍으려 해도 사진관에서 일단 사진을 찍은 뒤, 화학 반응을 수반하는 필름 인상(현상)이 끝날 때까지 몇 시간을 기다렸다가 다시 방문해서 사진을 찾아 가야 했다. 무슨 세탁소에 빨래를 맡겼다가 찾아 가듯이 말이다. 그리고 사진관들 출입문과 쇼윈도에는 'xx분 만에 초고속으로 사진 완성' 이런 문구가 적혀 있곤 했다.

그러나 지금은 그런 게 어딨냐..;; 사진관에서도 필름을 구성하는 감광 물질에다 화학 반응을 가해서 상(像)을 만들어 내는 게 아니라, 즉석에서 생성된 전자 디지털 이미지 정보를 그냥 고급 종이에다가 고해상도 컬러 인쇄를 해 줄 뿐이다. 세상이 이렇게 바뀌었다.
소프트웨어 개발을 develop이라고 하지만, 생물학에서 말하는 '발생'도, 사진의 '인화'도 develop이라고 한다. 날개셋 한글 입력기도 세포 분열이 일어나고 사진에 상이 쓰윽 생기듯이 개발 완료에 스르륵 근접하는 중이다. ^_^

Posted by 사무엘

2017/06/18 08:34 2017/06/18 08:34
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1371

Trackback URL : http://moogi.new21.org/tc/trackback/1371

Leave a comment

바야흐로 날개셋 한글 입력기가 개발 17주년을 앞두고 있고 9.0 버전에 진입했다. 지금까지 참 멀고도 긴 길을 가 왔다.

일단 계획대로라면 9.x는 지금 내 처지가 크게 바뀌지 않은 상태에서 진입하는 마지막 버전대가 될 것이다.
9.0 이후의 다음 버전은 가을쯤에 나올 9.1을 목표로 하고 있다. 8.8 이후로 계속 0.1씩 찔끔찔끔 올라가는구나. 오랜만에 새로운 분야인 ‘보조 입력 도구’ 분야의 기능 개선과 강화를 진행한 뒤, 그 다음 버전, 아마 9.3쯤이 세벌식 관련 총체적인 동시치기 시스템을 구현한 버전이 될 것이다.

그때쯤 되면 드디어 핵심 필수 기능 개발 to do 리스트가 비게 될 것이고, 그 뒤엔 나도 박사 졸업도 하고 결혼 같은 다른 거사도 치뤄야 되니, 지금 같은 가중치를 둔 프로그램 개발은 당분간 쉴 것이다. 완전 새로운 입력 기능 추가나 대규모 리팩터링은 뒤로 미루고, 버그 수정, 보안 패치, 그때 그때 생각나는 마이너 버전업만 할 것이다.
아무튼.. 지난달에 한번 9.0 개발 근황을 공개한 적이 있었는데, 그때 이후로 9.0에는 또 여러 새로운 기능들이 또 들어갔다.

1. 24픽셀 글꼴 표시 지원

이번 9.0은 지난 1.0부터 8.x에 이르기까지 오랫동안 많은 사용자들이 바라고 있었지만 전혀 이뤄진 적이 없었고, 안타깝지만 프로그램 구조의 한계상 앞으로도 당분간 이뤄질 일이 없을 거라고 부정적으로 못을 박았던 기능이 하나 드디어 극적으로 실현되었다.

바로.. 16픽셀 비트맵 글꼴의 한계를 아쉬운 대로 깨고 더 큰 글꼴을 지원하게 된 것이다! 종전보다 50% 더 큰 24픽셀 비트맵 글꼴이다. 이 소식을 전하게 된 것을 본인은 기쁘게 생각한다. 시기적으로도 딱 적합한 숫자인 9.0 버전에서 실현됐다.

그냥 한글 입력 엔진 쪽으로 원래 계획했던 기능들만 구현했으면 그것만으로도 8.9에서 0.1 정도의 변화는 충분했으며, 5월 말쯤에 9.0 버전이 나올 수 있었다.
그러나 과거에 상상할 수 없었던 고해상도 디스플레이는 거스를 수 없는 대세가 된 지 오래이고, 세 주 남짓 부랴부랴 진행된 추가 작업은 내 프로그램이 그런 고해상도 디스플레이에 대응하는 뜻깊은 밑거름이 될 것이다.

24픽셀은 글자를 표현할 공간이 16픽셀보다 두 배 이상 더 넉넉하다. 복잡한 옛한글이나 한자를 더 선명하고 깔끔하게 표현할 수 있으며, 알파벳과 현대 한글 정도면 가로· 세로가 모두 2픽셀인 진한 글꼴도 무리 없이 만들 수 있다.

그럼에도 불구하고 이 크기는 화면 출력용으로 오랫동안 대중적으로 쓰인 16픽셀에 비해 글꼴이 매우 부족하다. 그리고 16픽셀은 너무 작은 크기이기 때문에 앗싸리 쑤제 도트 노가다로 정교하게 만들어진 비트맵 글꼴이 많지만, 24는 비트맵으로 일일이 찍기에는 좀 크고 그렇다고 윤곽선 방식만으로 그리기에는 정교한 힌팅 없이는 여전히 보기 안 좋다.

그래서 이번 9.0에서 곧장 들어간 24픽셀 한글 글꼴은 일단 아래아한글 1.x 도트판에서 추출한 인쇄용 명조· 고딕· 샘물· 필기 4종이다. 과거에 인쇄용으로 쓰던 글꼴을 이제 화면에서 일상적으로 보게 되는 셈이다.

그리고 도스용 태백한글에도 8*4*4 도깨비 형태로 크기만 더 키운 명조· 고딕 글꼴이 있어서 이를 탑재했으며, ‘굴림· 궁서 옛한글’로부터 옛한글 비트맵도 추출해서 내 프로그램에서 쓸 수 있는 조합형 한글 글꼴을 만들었다. 디렉터리는 종전의 Font에 이어 Font24가 또 추가되었다.
글꼴 본뜨기를 하면 기본 한글 글꼴인 바탕· 돋움· 굴림· 궁서 정도는 물론 완성형 글꼴 형태로 추가되며, 영문 중에서는 16픽셀 시절과 마찬가지로 Courier New, Lucida Console, 그리고 중국어· 일본어 불변폭 글꼴의 영문 글립도 추가된다.

기본 내장 글꼴은 기존 16픽셀 버전을 기계적으로 확대한 뒤, 급한 대로 손으로 최소한의 보정만 한 것이다. 여건이 허락하는 대로 퀄리티를 차차 개선해 나갈 것이다. 둥근모, 한솔바탕, 이야기체 이건 꽤 잘 만든 글꼴 축에 드는데 24픽셀 버전이 같이 좀 있으면 좋겠다.
일부 도스용 프로그램들이 제공하는 인쇄용 글꼴들은 한글과는 달리 영문 글꼴을 사용할 만한 것이 의외로 드물었다. 높이는 24픽셀이지만 폭은 12가 아닌 14픽셀이라거나 해서 아귀가 좀 안 맞았기 때문이다. (일일이 야메로 수정하기엔 시간 부족..)

큰 글꼴은 현재 시스템의 DPI가 150% (또는 144dpi) 이상이면 자동으로 채택되며, 100%나 125% 같은 낮은 DPI에서는 언제나 여전히 종전의 16픽셀 글꼴이 쓰인다. 한 프로그램에서 두 크기의 글꼴이 동시에 쓰이거나 실시간으로 전환되지는 않는다.
요컨대 이 기능은 눈으로 보이는 글자 크기를 적극적으로 키워 주는 기능이 아니다. 단지, high DPI 환경에서 비트맵 글꼴이 터무니없이 너무 작게 보이는 것을 막아 줄 뿐이다. 고해상도를 지원하기 위해 필요한 정말 최소한의 방어적인 조치만을 최소한의 시간 동안 취한 것이다.

단, 24픽셀 글꼴 지원을 추가한 주 이유가 high-DPI에 대한 대응이므로, 주요 아이콘과 도구모음줄 비트맵에 대한 확대 작업은 같이 행해졌다.
특히 타자연습은 UI 곳곳이 수정되어서 150% DPI에서 24픽셀 글꼴로 편하게 사용이 가능하게 되었으며, 버전은 3.61에서 3.7로  올라갔다. 기능이 바뀐 것은 전혀 없고 (1) 프로그램 명칭 표기에서 화살괄호를 제거, (2) 큰 글꼴로 high-DPI 지원 이 두 가지가 전부이지만, 그것만으로도 버전을 올릴 명분은 충분하다.

게임의 경우 24픽셀 글꼴 하에서는 드디어 640*480 대신 역시 1.5배가량 더 높은 1024*768 해상도에서 실행된다.
이것도 오늘날 기준으로는 여전히 참 민망한 퀄리티이다. 하지만 (1) 게임을 최신 3D 그래픽 기반으로 처음부터 다시 만들고 (2) 게임 시스템을 좀 전반적으로 개편하는 날이 올 때까지.. 그 날을 기약 없이 무작정 기다리기만 할 수는 없으니 당장 필요한 최소한의 조치를 취했다. 적극적으로 개선을 못 하고 있을 뿐이지 타자연습 역시 2017년 현재까지 찔끔찔끔 유지보수 중인 살아 있는 프로그램이긴 하다는 뜻이다..

타자연습은 날개셋 엔진 dll이 포함돼 있기 때문에 비록 글꼴과 도움말이 없고 '고급 입력기/스키마'를 사용할 수 없을지언정 타자연습만 설치해도 프로그램이 실행은 된다.
그러나 이 상태로는 24픽셀 글꼴을 사용할 수 없다(기본 내장 글꼴도 없음). 그렇기 때문에 입력기를 반드시 설치해야 한다.

본인은 오랫동안 복합 낱자 입력 로직 생성기의 알고리즘을 생각하면서 끙끙거렸으며, 입력 스키마와 문자 생성기에다 새 기능을 추가하느라 지금까지 머리에 쥐가 날 지경이었는데.. 이런 24픽셀 글꼴 지원은 한글 입력 동작과는 아무 관계 없으며 학술적인 의미도 딱히 없다. 그냥 기계적인 구조 확장과 리팩터링, 도트 노가다만이 있을 뿐이다. 하지만 프로그램 자체에 대한 내부 구조를 고치고 확장하고, 당장 사용자의 입장에서 실용성이 높은 기능이었다.

성격이 완전히 다른 개발 작업을 몇 주 하고 나니 머릿속 분위기가 싹 달라졌다. 손 놓은 지 오래 돼서 긴가민가하던 비트맵 관련 API들 다루는 법도 감이 완전히 되살아났다. 그래도 이런 걸 좀 하고 나니 내가 살아 있는 것 같고 삶의 목적과 존재의 의미가 있는 것 같다.

2. 타이머

그럼, 다음 소식으로 한글 입력 엔진 얘기로 돌아간다.
한글 입력기는 단순히 사용자의 키보드· 마우스 입력에만 반응하는 게 아니라, 마지막 입력 후 일정 시간 동안 반응이 없으면 뭔가를 자동으로도 할 수도 있다.

지금으로부터 6년 전, 6.0 버전에서 '조합 중단 타이머'라는 이름으로 아주 초보적인 수준의 타이머 기능이 도입된 적이 있었다. 주 용도는 천지인이나 Google 단모음 같은 글쇠배열에서 음절 경계 구분을 하는 것이다. 두벌식은 모바일에서는 말할 것도 없고 옛한글 또는 No shift라는 조건이 추가되면 십중팔구 종성과 초성 사이에 모호성이 생기기 때문이다.

그런데 단순히 조합을 무조건 끊기만 하는 기능은 별로 유용하지 못하며, 100점 만점에 70점밖에 안 된다. 음절 경계 구분을 선별적으로 할 수 없기 때문이다.
가령, Google 단모음에서 '박' 다음에 ㄱ을 입력했다면 시간 간격에 따라 '밖' 또는 '박ㄱ'이 되어야겠지만, ㅏ를 입력했다면 시간 간격과 무관하게 언제나 '바가'가 되는 게 바람직하다. '박ㅏ'을 원하는 사용자는 거의 없을 것이다.

천지인도 마찬가지이다. '안'을 입력하고 나서 또 ㄴ을 입력했다면 시간 간격에 따라 '알' 또는 '안ㄴ'이 되어야겠지만, 중성은 말할 것도 없고 ㅈ도 타이머와 무관하게 언제나 '앉'으로 모아 주는 게 바람직하다. 얘까지 '안ㅈ'로 일부러 끊을 필요는 없다. 요컨대 진짜로 모호성이 발생하는 종성과 초성이 만났을 때만 구분을 해 주고, 나머지 입력에 대해서는 평소처럼 처리하면 된다.

그러니 타이머로 음절 구분을 선별적으로 하기 위해서는, 타이머 이벤트가 발생했을 때 그냥 조합을 끊기만 하는 게 아니라 여느 글쇠를 눌렀을 때처럼 임의의 날개셋문자를 보낼 수 있도록 이거 구조부터 좀 확장하게 됐다. 뭐, 예전처럼 조합을 끊으려면 C0|0xE라는 '조합 중단' 특수 코드를 보내면 되고, 아니면 '상태 전이'나 특별한 의미를 갖는 가상 낱자 결합, 소문자 변수값 변경 + 글쇠 수식 같은 걸 사용하면 앞서 얘기했던 선별적인 음절 구분을 구현할 수 있다.

타이머를 사용하기 위해서는 '자동 입력 타이머' 옵션을 켠 뒤, 설정을 눌러서 별도의 대화상자에서 타이머의 발동 조건과 시간, 적중 시에 보낼 날개셋문자 수식 등을 지정하면 된다.
게다가 타이머를 하나도 아니고 용도가 다른 것을 최대 3개까지 동시에 지정할 수 있다. 예전처럼 굳이 조합 상태일 때만 켤 수 있는 것도 아니며, 원한다면 조합 상태가 아니고 그냥 아무 글쇠를 누른 뒤부터 자동으로 켤 수도 있다.

사용자 삽입 이미지

사용할 타이머의 종류, 각 타이머의 작동 조건, 타이머 적중 시에 입력할 문자, 타이머 중단 조건을 아주 세밀하게 지정 가능하다.
타이머를 일회용으로만 지정할지, 아니면 다회용으로 계속 굴릴지 선택할 수 있고, 또 겉으로는 아무 변화가 없더라도 이 타이머가 적중했을 때는 삑 소리로 청각 피드백을 주게 할 수도 있다.

다회용 타이머는 반쯤 자동 입력 매크로처럼 활용도 가능하다. 타이머가 왔을 때 '글쇠 누름' 날개셋문자를 보내게 하면 ESC, 엔터, Ctrl+?? 같은 특수글쇠를 반복해서 보낼 수 있기 때문이다. 거기에다 난수 R변수까지 사용하면 더욱 예측불허의 동작을 만들어 낼 수 있다.

입력 중에 발동된 타이머는 사용자가 글쇠배열을 변경하거나 키보드 포커스를 다른 창으로 바꾸는 등 외부 이벤트가 발생하면 취소된다. 하지만 그것 말고 지금 글자의 조합이 종료됐을 때(타이머의 여파가 지금 조합의 범위를 벗어나지 않게 해야 할 때.. 주로 일회용 타이머용), 그리고 사용자가 화살표 키나 마우스 같은 걸로 cursor를 옮겼을 때(주로 다회용 타이머용)에도 타이머를 취소시킬 수 있다.

타이머라는 기능에 존재할 만한 옵션을 이런 식으로 분류하고 저런 대화상자에다 정리하고 지금과 같은 형태로 구현하는 게 과연 '최선'이라 할 수 있는지 확신이 안 서서 오랫동안 괴로웠는데 드디어 모든 고민이 깔끔히 해결됐다. 지금 구현된 형태는 개인적으로 매우 만족스럽다. 좀 더 일찍 진작부터 이렇게 만들어지지 못한 게 아쉬울 뿐이다.

타이머는 기능의 성격이 문자 생성기와 입력 스키마에 반반쯤 걸쳐 있는 이상한 물건이다. 입력 단위인 날개셋문자를 새로 생성한다는 점에서는 입력 스키마와 비슷하지만.. 조합 상태와 깊숙히 관여하고 있고 글쇠배열 자체보다 로직에 가깝다는 점은  문자 생성기와 비슷하다.

안 그래도 다음 버전에서는 이렇게 문자 생성기뿐만 아니라 입력 스키마나 보조 입력 도구도 타이머를 지정하는 기능이 도입될 것이다. 그러니 이번 타이머의 구조 확장은 다음 버전에 대한 준비 작업이라는 의미도 갖는다.

이렇게 새 기능이 구현되었지만, 복합 낱자 입력 로직 생성기 빠른설정이 저렇게 타이머와 연계한 선별적인 음절 구분까지는 지원하지 않을 예정이다. 저건 글쇠배열 차원에서 변수를 써서 구현하는 게 낫지만, 이 빠른설정은 일단은 문자 생성기 계층의 설정만 고치는 것을 지향하고 만들어졌기 때문이다. 그냥 지금처럼 모호성이 발생하는 자음 pair 그룹을 찾아서 보여주는 일만 한다.

예제로 제공되는 삼성 천지인 입력 방식은 k, l, m이라는 사용자 변수 세 종류를 사용하여 '안ㄴ'과 '안ㅈ'을 구분하는 음절 경계 타이머를 구현해다. 현재 입력된 글쇠가 이전에 입력된 글쇠와 동일하고(k==l), 타이머가 경과하여 m=1이 됐을 때는 다음 자음이 종성이 아니라 언제나 초성으로 입력되게 함으로써 음절을 구분하는 것이다.

그에 반해 Google 단모음은 타이머가 적중했을 때 이제 아무 낱자의 결합도 받지 않는 별도의 오토마타로 상태 전환을 시켜서 음절을 구분하게 바뀌었다. 이런 식으로 타이머를 활용하는 방법이 더욱 다양해진 것이 9.0의 의의이다.

3. 고급 입력 스키마

지금까지 고급 입력 스키마에는 한 글쇠의 연타를 감지하는 것과 관계 있는 I~K 변수가 있었는데, 이번에는 동시에 누른 글쇠의 개수를 감지하는 V, W 변수가 추가되었다.
'고급 글쇠 인식'에 등록되어 있는 글쇠 중 여러 개가 동시에 눌러진 게 있다면 그 개수만큼 V의 값이 증가한다. 그리고 한 순간에 가장 많은 글쇠가 눌러진 최대값이 W에 보관되고 업데이트된다. W는 모든 글쇠에서 손이 떼어진 뒤에도 남아 있다가, 다음에 한 글쇠가 단독으로 새로 눌러졌을 때 다시 1로 되돌아간다.

이 변수를 통해 사용자는 어떤 글쇠가 눌러지거나 떼어졌을 때 자기 말고 다른 글쇠도 눌러진 것이 있는지 확인할 수 있다. Shift나 Ctrl의 경우 대부분 다른 글쇠와 결합해서 쓰이는 modifier 글쇠인데, 자기 혼자만 단독으로 길게 누르거나 뗐을 때에만 특수한 처리를 하고 싶다면.. 저 변수를 활용하면 된다.

또한 글쇠배열에 공통 전처리· 후처리가 있는 것처럼, 그렇게 날개셋문자를 결정하기 전에 임의의 글쇠가 눌러졌을 때에 한해서(keyup 말고 keydown 때만) 공통으로 실행할 수식도 지정할 수 있게 했다. 이건 고급 글쇠 인식에 등록된 글쇠와 그렇지 않은 글쇠를 달리 지정할 수 있다. 이를 통해서도 여러 글쇠를 동시에 눌렀을 때 혹시 딴 글쇠가 같이 눌러졌는지를 판별할 수 있다.

이를 계기로 고급 입력 스키마도 제어판에 자신의 고유한 옵션을 지정하는 탭이 하나 추가되었다. 이전까지는 고급 인식 글쇠 리스트를 지정하는 탭 하나만 있다가 9.0부터 2개가 된 것이다.
기본 입력 스키마와 기본 문자 생성기가 탭이 각각 2개와 3개인데, 고급 스키마와 고급 생성기도 자신만의 탭을 각각 2개, 3개씩 갖고 있다. 그러니 고급 스키마와 고급 스키마를 사용할 경우 탭의 개수는 총 10개로, 5개에 비해 정확하게 2배로 늘게 된다.

물론 고급 입력 스키마의 옵션 탭은 아직 아이템이 매우 적어서 화면이 썰렁하다. 그러나 타이머, 눌러진 글쇠 개수 파악, 그리고 별도의 옵션 탭들이 모두... 머지않아 세벌식에 특화된 동시치기 기능 추가를 위한 준비 작업이다. 위에서 언급했던 모든 기능들과 오토마타까지 다 연계해야 구현 가능할 것으로 보인다.

입력 스키마와 문자 생성기가 모두 "빈-기본-고급"이라는 3단계 계층이 싹 갖춰져서 보기 좋다.
사실, 잉여력이 조금만 더 충분하다면 이것도 좀 다른 관점에서 새로 설계해서 '꼬마 스키마' 내지 '꼬마 입력기'를 또 만들어 보고 싶긴 하지만.. 여건이 허락하지 않는다.

4. 기타

(1) 지난 8.9 버전은 버그가 발견된 게 '거의' 없었다. 덕분에 이번 9.0은 변화 사항 문서에 '개선' 카테고리에 해당하는 항목이 일단은 없다.
단, 편집기에서 텍스트에다 블록을 4개 이상 잡고서 '도구-분량 계산'을 하고 나면 프로그램이 그냥 무한 루프에 빠지면서 응답을 멎는 문제가 있어서 고쳤다. 정말 황당하고 어처구니없는 실수 때문이며, 뻗거나 메모리 폭주를 하는 게 아니라 그냥 무한 루프에만 빠진다.

이건 워낙 간단한 기능이기 때문에 해당 기능이 한번 구현된 뒤에 딱히 고쳐질 일은 없으며, 따라서 8.9에만 있는 문제는 아니다. 오랫동안 발견되지 않고 남아 있다가 이번에 발견되어 고쳐졌다.

(2) bksp 동작 방식.. 이를테면 글자부터 낱자까지 지우는 단위라든가 앞 글자 달라붙기+역도깨비불 시도 여부 같은 것을 지금처럼 단순히 고정된 옵션이 아니라 이것도 수식으로.. 앞 글자가 실제로 무엇이고 소문자 변수 값이 무엇이냐에 따라 사용자 정의 가능하게 하는 기능을 추가했다.
실생활에서 bksp를 이 정도로 변태적으로 제어해야 할 상황은 거의 없겠지만 그래도 completeness 유지 차원에서, 혹시나 해서 추가했다.

(3) 날개셋 브랜드에 속하는 프로그램은 아니지만, 이번 high DPI 작업 추세에 맞추어 '세벌식 파워업' 프로그램도 2015년 이후 2년 만에 잠수함 패치를 했다.
수행할 기능을 선택하는 라디오 버튼을 더블 클릭만 해도 해당 명령이 바로 실행되게 했고, 글쇠배열 그림이 high DPI에서는 그에 상응하는 비율로 더 크게 나오게 했다.
실질적인 기능이 바뀌거나 버그가 고쳐진 건 없다. MS 한글 IME가 글쇠배열 정보를 저장하는 방식은 Windows Vista 이후로 딱히 바뀌지 않고 있다. 덕분에 새로운 알고리즘이 추가돼야 할 일은 없었다.

Posted by 사무엘

2017/06/15 08:30 2017/06/15 08:30
Response
No Trackback , 5 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1370

Trackback URL : http://moogi.new21.org/tc/trackback/1370

Comments List

  1. 사무엘 2017/06/16 00:34 # M/D Reply Permalink

    음~ 문제가 발견되어 한글 입력기와 타자연습을 6월 16일 0시 30분경에 다시 올렸다.

    입력기는 프로그램 코드 상의 문제는 없는데 조합형 한글 글꼴 '바탕, 돋움, 샘물, 필기' 4종이 ㄾ과 ㄿ 모양이 서로 뒤바뀌어 잘못 만들어져 있었다.

    타자연습은 게임을 전체 화면에서 실행했을 때 예전에는 안 그랬는데 화면 아래쪽이 검은색으로 칠해지는 문제가 최신 운영체제에서 발견되어 이걸 해결했다.

    그 밖에 도움말의 일부 문장 말투를 다듬고 도구모음줄 비트맵 일부를 살짝 다듬었다.
    15일과 그 이전에 한글 입력기 9.0과 타자연습 3.7을 받으신 분은 번거롭지만 프로그램을 삭제 후 다시 받아서 설치하시기 바란다. 불편을 끼친 점에 대해 사과드린다.

  2. boolsee 2017/06/16 08:33 # M/D Reply Permalink

    9.0 버전의 완성을 감축드립니다.
    너무나 잘 사용하고 있습니다. 설명하신 내용을 어찌하면 더 잘 사용하는 것인지 모르는 것은 저의 능력이 부족한 탓입니다. 고맙습니다.

    :)

    1. 사무엘 2017/06/16 09:32 # M/D Permalink

      다른 건 몰라도 24픽셀은 당장 실질적으로 제감 가능한 기능이지요. ^^
      (타자연습이나 편집기를 사용하지 않는다면 별 의미 없겠지만)
      제 프로그램을 유용하게 사용해 주셔서 저 역시 대단히 감사드립니다~!

  3. 정 용태 2017/06/17 03:27 # M/D Reply Permalink

    항상 고생하십니다! 버전업 축하드립니다(__)
    일본어 윈도우 등 타국어 윈도우를 사용할 일이 자주 있는데 편집기와 입력기 도움을 많이 받고 있습니다.
    항상 감사한 마음 갖고 사용하고 있습니다. 고해상도, 실행시켜 보니 정말 보기 좋더라! 네요 ^_^

    1. 사무엘 2017/06/17 10:26 # M/D Permalink

      정 용태 님, 정말 오랜만에 뵙네요. 반갑습니다! ^^ 코딩과 철도 활동은 변함없으신지요?
      제 프로그램을 유용히 사용해 주시는 것에도 거듭 감사드립니다.

Leave a comment

다음 버전 개발 근황

날개셋 한글 입력기 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 사무엘

2017/05/16 08:31 2017/05/16 08:31
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1360

Trackback URL : http://moogi.new21.org/tc/trackback/1360

Comments List

  1. 세벌짱~ 2017/05/29 21:04 # M/D Reply Permalink

    세벌식 너무 좋은거 같네요
    날개셋 덕분에 익숙해져서 좋습니다.
    좋은 프로그램 무료로 배포해주셔서 정말 감사하네요~

    1. 사무엘 2017/05/30 04:33 # M/D Permalink

      네, 한글은 두벌식으로만 입력하기에는 너무 아까운 문자이고 세벌식으로 바꾸면 타자 경험이 완전히 달라지지요.
      제 프로그램을 사용해 주셔서 대단히 고맙습니다. ^^

Leave a comment

1. 외부 모듈 핵심부의 EXE 분리

오래 전부터 조금씩 풀었던 썰이긴 한데, 마침 최근에 회사에서 유사 개발 업무를 한 적도 있고 해서 다시 얘기를 꺼내 보겠다.
Windows는 타 OS들과는 달리 IME가 EXE가 아닌 DLL 형태이다. 한 프로세스의 주소 공간에 완전히 속해 있는 덕분에 성능이 좋다는 장점이 있겠지만, 한영 상태가 스레드들마다 제각각 따로 놀고 거기에다 memory-mapped 방식으로 로딩된다는 특성까지 겹쳐서 IME의 on-the-fly 업데이트가 몹시 난감하다.

EXE라면 업데이터 하나 띄워서 자신을 종료한 뒤 업데이트 된 놈으로 재시작만 하면 간단하게 끝났을 일인데 Windows용 IME는 업데이트 하려면 자신을 사용하는 프로그램들을 몽땅 종료해야 하고, 그게 여의치 않으면 그냥 운영체제를 재시작/로그오프 해야 한다. 거기에다 32/64비트까지 모두 신경 써야 한다.

그래서 <날개셋> 한글 입력기 외부 모듈도 인제 와서 처음부터 다시 만드는 건 무리이겠지만, 앞으로 덩치 큰 IME를 만들 일이 있으면 DLL은 거의 업데이트 할 일 없는 껍데기만 남겨 놓고 실질적인 문자 조합은 EXE 기반의 '서버'에 담당시키면 어떨까 생각을 해 왔다. 업데이트도 IME가 통신하는 EXE만 하고 말이다.

이렇게 하면 모든 IME들의 설정과 상태 동기화는 자동으로 이뤄진다. 서버와는 함수 호출이 아니라 메시지와 memory-mapped file 같은 간접적인 방법으로 통신을 하니 서버는 굳이 바이너리 구분을 할 필요 없다. 64비트 OS에서는 64비트 서버 하나만 띄워 놓으면 32비트와 64비트 IME가 모두 통신이 가능하니 더욱 좋다.

실제로 실험용 IME를 만들어 본 결과는 흥미로웠다. 서로 다른 프로세스끼리 메시지를 주고받을 때는 단일 스레드끼리 메시지를 주고받을 때에 비해 고려해야 할 점이 더 많았다. 받는 쪽에서 자체적으로 대화상자 같은 걸 출력하고 그 상태로도 자체 메시지를 처리하지 못하는 block 상태가 되지 않으려면 대화상자는 modal이 아니라 반드시 modeless 형태로 만들어야 했다.

SendMessage와 PostMessage를 조심해서 가려 써야 하며, 리턴값을 꼭 받기 위해 Send를 하면서도 신속한 반응성을 보장하기 위해서는 지금까지 머리로만 알고 있던 ReplyMessage 같은 함수를 난생 처음으로 써 보기도 했다. 특히 호스트가 클라이언트로부터 Send된 메시지를 받은 뒤에 대화상자 같은 modal UI를 띄운다면 말이다.

여기까지 생각을 하긴 했으나.. IPC 기법들은 근본적으로 IME들이 쓰라고 만들어진 메커니즘이 아니다 보니 한계도 많다.
가장 먼저 권한 문제가 걸리니, IME 서버는 번거롭게 관리자 권한으로 실행하거나 아니면 애초에 운영체제의 서비스 같은 급으로 만들어야 한다. 메트로와 데스크톱 앱 사이의 소통도 문제이고..
IME가 글쇠 입력을 받은 것을 서버로 요청을 보내는 건 그럭저럭 할 만하나, 반대로 서버가 IME로 문자 입력 요청을 하는 것은.. IME가 제각각 스레드 동기화 오브젝트나 윈도우를 만들어야 가능할 것이다.

서버는 자신과 접속하거나 종료하는 클라이언트들을 파악하고 있어야 하는데 자고로 프로세스라는 건 강제 내지 비정상 종료될 때도 있다. 그렇기 때문에 모든 프로그램들의 근황을 언제나 정확하게 파악하고 있는 것도 훅킹이라도 동원하지 않으면 의외로 쉽지 않더라.

이것저것 가성비를 생각해 보니 서로 장단점이 있고 근본적으로 한 방식이 다른 방식을 완전히 대체 가능해 보이지는 않았다. 안 그래도 날개셋의 경우 EXE 기반의 입력기 개발 실험은 입력 패드를 만들면서 이미 그럭저럭 하기도 했다. Windows에서 어떤 DLL이 타 프로세스에 합법적으로 침투할 수 있는 양대 통로는 미우나 고우나 훅킹 아니면 IME이다.

다만, 지금 MS 일본어 IME가 이미 그런 것처럼 제어판 대화상자만은 EXE로 분리하는 게 나은 점도 있다.
실행되는 응용 프로그램에 따라서는 공용 컨트롤.. 특히 6.0 이상에서만 지원되는 syslink나 split button, 에디트 컨트롤의 풍선 도움말(cue banner) 같은 게 초기화되지 않은 경우가 종종 있어서 내 날개셋 제어판도 그거 영향을 받아 제약을 받기도 하기 때문이다.

뭐 그건 그렇고..
기존 데스크톱 앱인 '제어판' 말고 메트로 앱인 '설정'에서 돌아가는 환경설정은 어떻게 만드는지 모르겠다. MS 한글 IME에는 그런 게 있던데..;;

2. 설치 시스템 개편

예전에도 여러 번 언급한 바와 같이, <날개셋> 한글 입력기는 Visual Studio가 기본 제공하는 Windows Installer 기반 msi 패키지 형태로 배포되고 있다. 이 솔루션은 MS 본가에서 만든 만큼, 프로그램을 설치하거나 제거하는 본연의 성능은 일정 수준 이상의 퀄리티가 보장된다. 프로그램 디렉터리 어딘가에 uninstall stub 프로그램 같은 게 덕지덕지 붙어 있을 필요도 없고 아주 seamless + 깔끔하다. 하지만 개발툴이 제공하는 GUI 템플릿은 customize가 매우 제한적이고 불만족스러운 점이 많기 때문에 다른 솔루션을 써 볼까 생각도 자주 해 왔다.

이상적인 설치/배포 솔루션은 다음과 같은 조건을 만족해야 한다. 다른 프로그램이라면 몰라도 <날개셋> 한글 입력기에 대해서는 내가 보다시피 욕심이 좀 많다.

  1. CPU 통합: 한 exe 파일 단독으로 32비트와 64비트 OS에서 잘 동작하고, 32비트에서는 당연히 64비트 바이너리를 설치하지 않아야 한다. EXE처럼 32/64비트 중 사용 가능한 상위 바이너리 하나만 설치하면 되는 파일은 선별이 옳게 돼야 한다. 필요한 디스크 공간 계산도 이 모든 변수를 감안해서 돼야 한다.
  2. 언어 통합: 한 exe 단독으로 운영체제의 기본 언어가 한국어이면 한국어, 그렇지 않으면 자동으로 영어로 설치 프로그램의 UI가 출력되어야 한다.
  3. 유니코드 통합: 평상시에 유니코드 API를 사용하는 건 너무 당연한 얘기이고, 그럼에도 불구하고 구닥다리 Windows 9x에서도 유니코드만 포기하고 기본적인 실행이 돼야 한다. 이것도 물론 단일 파일로 말이다. <날개셋> 한글 입력기 본제품이 Windows 95/NT4부터 꼬박꼬박 다 지원하는 프로그램이기 때문이다.
  4. known 폴더: 또한 아무 액세서리 없는 깡통 Windows 95 RTM에서 실행되더라도 IE 4~5 이상에서 첫 도입된 ProgramData (Application Data)같은 known 디렉터리를 인식해서 파일을 제 위치에 설치해야 한다.
  5. 원활한 제거: Windows용 IME는 그 특성상 on-the-fly로 업데이트나 제거가 꽤 난감한 물건인데, 당일 제거를 못 했으면 재부팅 요청 같은 후처리를 적절히 수행해야 한다.
  6. 그 밖에: 관리자 권한 드립 치는 UAC 화면은 setup을 실행하자마자 뜨는 게 아니라, 실제로 설치가 시작되어 관리자 권한이 정말로 필요해졌을 때 직전에 뜨는 게 바람직함.

진짜 유명한 세계구급 소프트웨어인 경우, 설치 프로그램이 언어를 선택받는 대화상자부터 띄우는 경우가 있다. 하지만 날개셋의 경우 그렇게 유명한 물건은 아니니 그냥 운영체제의 기본 GUI 언어가 한국어가 아닐 때에만 영어로 동작하는 걸로도 충분할 듯하다. 날개셋은 GetSystemDefaultLangID() 함수를 써서 판별하는데, 이게 GetUserDefaultLangID와 차이가 무엇이 있는지는 개인적으로 궁금하다.

msi는 (1)과 (2)는 전혀 만족하지 않는 것으로 보여서 문제다.
그러나 (3)과 (4)는 Windows installer runtime (non-Unicode 9x용 에디션)자체만 미리 설치하면 그럭저럭 어렵지 않게 충족된다. 2.0 런타임은 의외로 깡통 Windows 95에서도 깔끔하게 설치 가능하다. 이것 때문에 <날개셋> 한글 입력기가 MSI 외에 다른 배포 솔루션으로 갈아타기가 어렵다.

"HKCU 또는 HKLM"\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders라는 레지스트리를 참조하면 known 폴더 위치를 얻을 수 있다. MSI가 이런 것까지도 생성해 준다. 이렇게 레지스트리를 수동으로 뒤지는 방법은 오늘날에는 마소에서 권장하지 않는 방법이지만, The old new thing 블로그의 설명에 따르면 아직도 여기를 참조하는 고집쟁이 옛날 어플 때문에 어쩔 수 없이 호환성 차원에서 레지스트리를 계속 지원해 주는 거라고 한다. 사실, IE 4~5가 없고 SHGetSpecialFolderPath 함수가 존재하지 않는 골동품 Windows 95 환경에서는 여기를 뒤지는 것밖에 선택의 여지가 없기도 하다.

다음으로 (5)의 경우 msi는 딱 기본만 수행한다. "다음 프로그램들이 요 DLL을 사용하고 있습니다" 대화상자도 찍어 주고, 뭔가 못 건드린 파일이 있으면 "재부팅 하시겠습니까?"라는 여운을 남기기도 하는데, 가끔은 안 그럴 때도 있는 듯하다.

msi 말고 3rd party installer 중에서는 오픈소스이기도 한 NSIS가 세계적으로 제일 유명하다. WinAmp는 역사 속으로 사라졌고 개발사인 Nullsoft도 없어졌지만, 그래도 NSIS만은 유용성 덕분에 오픈소스 진영에서 살아남아 있다. Nullsoft의 개발자들이 왕년에 불멸의 작품 하나로 이름을 남겼다.

얘는 어떤가 하면..
(1)과 (2)는 기술적으로 일단 가능하다. msi보다 분명 우월한 점이다. 그러나 그냥 '가능하다'에서 끝일 뿐, 막~ 적극적으로 지원되고 깔끔하고 편한 형태로 가능하지는 않아 보인다.

단적인 예로, 생성되는 installer에 붙는 런타임 바이너리가 기본적으로 32비트 기반이다 보니, 거기 스크립트 언어에서 기본 제공하는 등록 명령만 이용해서는 64비트 DLL에 대해서 DllRegisterServer(시스템 등록) 호출을 할 수 없다. 뭐, 운영체제가 제공하는 regsvr32 /s를 이용하면 되긴 하지만, 사용자가 직접 저렇게 외부 유틸리티나 플러그 인을 끌어들일 필요 없이 NSIS가 내장 명령어 차원에서 저걸 지원하면 더 좋을 것이다.
홈그라운드 운영체제의 지원빨이 있는 msi에서는 반대로 DLL의 등록쯤은 전혀 걱정할 것 없는 사항이다. 64비트용 msi라면 64비트 DLL이건 32비트 DLL이건 불문하고 등록이 깔끔하게 잘 처리되기 때문이다.

(3)은 NSIS가 한동안 정식으로 지원하지 않아서 Unicode NSIS라는 별도의 프로젝트 브랜치가 나돌 정도이다가 비교적 최근에 NSIS가 3.x 버전에 진입하고 나서야 유니코드를 정식으로 수용하게 됐다.
그러나 NSIS는 기술 수준이 그냥 이미 있는 Windows API를 감싸는 정도를 벗어나지 않기 때문에 유니코드와 Windows 9x를 동시에 지원한다거나, 구버전 OS에서 신버전의 known 디렉터리를 만들어 주는 정도의 과잉 친절을 베풀지는 않는다.
(5)의 경우는 NSIS가 어디까지 자비롭게 대처하는지 아직 제대로 확인을 못 해 봤다.

요약하면, 완전한 스크립트 기반인 NSIS가 당장 자유도가 뛰어나 보이기는 하지만, 그래도 레거시 운영체제 지원이나 시스템 차원에서의 융통성은 그래도 msi가 나은 게 있어서 한 솔루션이 다른 솔루션을 완벽하게 대체하지는 못하는 실정이다.
NSIS의 스크립트는 무슨 파이썬이나 Lua 급으로 복잡한 연산식이나 복합 자료구조를 지원하는 본격적인 고급 언어가 아니다. 스크립트의 문법은 반쯤 어셈블리어에다가 C언어의 전처리기를 얹은 것 같은 구조이며 생각보다 제약이 많다.

어셈블리어 같은 문법인데 CPU 인스트럭션이 들어가는 게 아니라 Windows API의 함수와 각종 속성 명칭이나 상수들이 들어간다는 점만 다르다. if-then-else, switch 같은 조건 판단과 분기조차도 언어의 키워드가 아니라 그냥 분기문을 표현하는 매크로 형태로 구현되었을 정도이다.
그나저나, 파일 경로를 많이 다루고 역슬래시를 필연적으로 많이 쓴다는 특성상 \ 자체는 탈출문자로 쓰지 않고 $를 붙여서 $\n으로 개행문자를 표현하는 건 인상적이었다.

설치 스크립트도 당장 필요한 기능만 주먹구구식으로 구현하는 게 아니라 치밀하게 잘 만들려면 끝이 없겠다.

  • 한 스크립트로 몇몇 스위치만 달리하여 동일 제품의 여러 파생형이나 변형 에디션(가령, 셰어웨어 데모/정식 같은)을 조건부 컴파일로 간단히 감당 가능
  • 한 제품에서는 아까 말한 언어와 아키텍처를 단일 출력 바이너리만으로 모두 커버 가능
  • 모든 문자열 값들은 언어 중립적인 값과 언어 종속적인 값으로 나눠서 관리 가능하고, 제품 이름 같은 건 한 곳에서 값을 바꾸면 등장하는 모든 곳에서 값이 알아서 바뀌어야 함
  • 컴퓨터의 상태 파악을 알아서 해야 함. 처음 실행됐을 때 지금이 첫 실행인지, 동일 버전, 구 버전, 또는 동일 버전의 바리에이션이 이미 설치돼 있는지, 이전에 설치를 하다가 만 상태인지, 심지어 자신이 중복 실행됐는지 같은 걸 사용자가 수동으로 파일이나 레지스트리 삽질 안 해도 알아서 감지해야 함
  • 설치할 파일과 삭제할 파일을 NSIS는 수동으로 일일이 써야 하는 것 같던데, 마치 C++ 개체 선언하듯이(생성자, 소멸자) 설치하는 파일, 추가하는 레지스트리 같은 걸 한 곳에다만 명시하면 역순의 제거 작업 역시 자동으로 파악돼야 하며, 작업을 실제로 수행하기 전에 예상 디스크 공간 계산 같은 것도 알아서 돼야 함.
  • 서로 다른 소프트웨어 제품이 동일한 파일을 설치하고 사용하는 경우, 그런 공용 파일은 reference counting을 해서 그 제품들이 모두 제거되었을 때에만 최종적으로 삭제되게 해야 함.
  • 그리고 uninstall 시엔 사용자가 생성한 데이터처럼 이 프로그램이 초기에 설치하지 않은 파일이나 레지스트리도 필요하다면 싹 제거하는 메커니즘이 제공돼야 함. (조건 범위 지정)
  • 최종 생성된 msi 내지 exe 파일에 대한 디지털 서명 후처리도 언어 내지 툴 차원에서 명시해서 자동 처리하기.

오픈소스 프로젝트에 기여한 것도 없는 주제에 불평만 길게 늘어놓은 것 같다만.. 이게 NSIS를 좀 써 보고 개인적으로 느꼈던 아쉬운 점이다. 오죽했으면 반디소프트에서 개발하고 있는 유명 파일 압축 유틸리티인 반디집도 6.0부터는 NSIS 대신 자체 개발한 인스톨러로 갈아탔다. 다만, NSIS는 저 정도 꽤 적지 않은 기능을 제공하고도 exe에 붙는 자기 런타임 stub 크기가 겨우 몇만 바이트에 불과할 정도로 작은 건 굉장히 인상적이었다.

그냥 간단한 파일 몇 개만 복사하고 끝나는 게 아니라 컴퓨터를 좀 깊게 제어하는 설치/제거 패키지를 만든다면 이걸 만드는 툴도 GUI 위주의 가벼운 툴이 아니라 그냥 핵심 기능만 SDK 형태로 만들고, 자주 쓰는 프로그램 패턴은 Visual C++의 프로젝트 마법사 형태로 구축하는 것도 나쁘지 않을 것 같다. 배포 패키지 자체를 그냥 C/C++로 만들라고 말이다. 그러면서 파일 압축 풀어서 복사하거나 지우는 등의 정말 핵심적인 공통 기능만 라이브러리를 쓰라고..

근데 생각해 보니 애시당초 그러라고 만들어진 라이브러리가 Windows Installer이긴 하다. 쟤도 사실은 단순 GUI 껍데기가 아니라 라이브러리가 본질이니까. 하지만 저 라이브러리도 구조가 워낙 복잡하고 설치, 제거, 롤백이 어떻고 알아야 할 사전 배경지식이 많다 보니 그 저수준 함수를 직통으로 쓰면서 배포 패키지를 만들 일이라곤 없을 듯하다.

Posted by 사무엘

2017/05/01 08:30 2017/05/01 08:30
, ,
Response
No Trackback , 4 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1355

Trackback URL : http://moogi.new21.org/tc/trackback/1355

Comments List

  1. kippler 2017/05/03 13:30 # M/D Reply Permalink

    오늘도 재미있는 글 잘 봤습니다. ^^
    몇가지 사족을 달자면,

    GetUserDefaultLangID() 사용자 언어 설정 값을 가져오고, GetSystemDefaultLangID() 는 시스템 언어 설정을 가져옵니다만, 실제로 NSIS 는 GetUserDefaultUILanguage()를 사용하고 있습니다.
    생각난 김에 테스트 해 보았는데, 사용자 입장에서 각각의 값을 바꾸고 방법이 조금씩 다 다르네요.

    인스톨러 만들 때 Win9x 지원은 쉽지 않은 문제로 보이네요. 일단 MBCS로 프로그램을 짜면, 언어 선택 화면에 각각의 언어로 언어 선택을 보여주기도 힘들고, 한국어 OS 사용자가 일본어를 선택하면 일본어가 깨지는 등의 문제가 발생하기 때문에 이 부분은 해결이 쉽지 않아 보입니다.

    그리고 언급하신 것처럼 NSIS 플러그인 사용할 때 32/64 비트 플러그인 DLL 호출이 자유롭지 못하기 때문에, 작은 외부 exe를 만들어서 플러그인에서 exe 를 호출하는 방식을 종종 사용했는데, 문제가 요즘 AV 프로그램의 휴리스틱엔 진은 덩치 작은 EXE를 너무 심하게 의심하더군요. 간단한 유틸 EXE를 만들어서 설치할 때 호출하는 방식을 선호했는데 나중에 이 문제가 너무 심해서 포기하고 말았습니다.

    1. 사무엘 2017/05/03 14:11 # M/D Permalink

      소환에 응해 주셔서 대단히 고맙습니다. ^_^

      1. 저도 그럼 System 대신에 User을 쓰는 게 낫겠네요. 어쩐지 외국인 중에서 편집기의 대화상자 UI가 한국어로 나오는 걸 문의하는 경우가 종종 있었는데, User는 영어이지만 System이 한국어여서 그런 것 같습니다.

      2. 당연히 Win9x 지원한다고 해서 프로그램 기반을 MBCS로 만들지는 않습니다. NT 계열에서는 원래 지원되는 언어 선택 ui가 모두 나오고, 9x에서는 영어 아니면 해당 운영체제 언어(영어가 아닌 경우) 둘 중 하나만 고를 수 있겠지요.

      3. 헐.. AV 휴리스틱 문제도 있는지는 몰랐네요. 디지털 서명 해도 막무가내로 의심하는가 봅니다.
      하긴, installer가 설치/제거 중에 잠깐 압축 풀어서 실행만 하고, 실제로 사용자의 컴에 설치는 안 되는 용도의 임시 EXE/DLL 및 데이터 같은 개념도 installer 엔진이 정식 지원해야 할 것 같습니다. feature list에 하나 추가입니다. ^^

  2. kippler 2017/05/04 12:07 # M/D Reply Permalink

    헐... 그냥 인스톨러 이야기 인줄 알았는데, 댓글 보니 인스톨러 만드시나 보네요. 응원합니다. ^^

    1. 네, 이 부분은 GetUserDefaultUILanguage() 가 제일 정확한듯 합니다. 저도 어제 궁금해서 여러가지 테스트를 해 봤는데, 영문 OS에 캐나다 언어팩을 설정하면 아래처럼 리턴값이 나옵니다. 한국, 일본, 중국 정도는 1:1 매치가 되어서 딱히 문제가 없는데, 스페인어처럼 다양한 국가에서 쓰이는 언어인 경우 GetUserDefaultUILanguage()를 써야 그나마 복잡도가 덜해 지더군요.
    GetSystemDefaultLangID () 1033 0x409 English ENGLISH_US
    GetUserDefaultLangID() 4105 0x1009 English ENGLISH_CAN
    GetUserDefaultUILanguage() 2057 0x809 English ENGLISH_UK

    2. 생각해보니 W계열 함수가 98에서도 다 작동했던 것 같기도 하고… 오랜만이라 기억이 가물 가물 하네요. (생각해 보니 작동을 하기는 하는데 내부에서 MBCS 로 다시 바꿔서 작동하기 때문에 일부 함수는 버그가 있었던 것 같기도 하고…) ㅎㅎ 어쨌거나 이거 다 고려하면 정말 쉽지 않은 작업이네요.

    1. 사무엘 2017/05/04 21:40 # M/D Permalink

      1. 아, "인스톨러를 만약 직접 만든다면 아무리 그래도 그렇지 MBCS를 쓰지는 않을 거다"라는 뜻이었습니다. 실제로 직접 만든다는 얘기는 아니고요. 그러기에는 제가 시간과 여유가 부족합니다. ^_^

      2. 네, 저도 관련 함수들을 검색하면서 그걸 알게 돼서 호출하는 함수를 교체했습니다.

      3. 9x 계열에서 W 계열 함수를 지원하는 건 MessageBoxW, TextOutW, GetTextExtentPoint32W처럼 최소한의 에러 메시지 출력 내지 글자를 찍고 픽셀 크기 측정하는 기본 함수 정도가 전부입니다. 아, 95 말고 98부터는 imm32 관련 함수들도 예외적으로 W를 지원하기 시작했고요. 물론 MessageBoxW는 내부적으로 문자열 변환 후 A를 호출하는 형태입니다.
      그러니 9x 시절에는 일반적인 함수들은 A를 써야 하는데 COM 내지 IME 관련 함수들과는 유니코드 문자열을 주고받으니 그게 또 프로그래밍을 골치 아프게 하는 요인이었습니다.

Leave a comment

날개셋 한글 입력기 8.9 -- 下

<날개셋> 한글 입력기 8.9는 지난 8.8 버전에서 첫 도입되었던 "복합 낱자 입력 로직 생성기"에 '허용 한글 범위 제약'을 연동하는 기능이 추가되었으며, 이 기능의 구현을 위해서 기존 '허용 한글 범위 제약' 기능의 제공 형태도 약간 변경되었다.

이전 버전에서 복합 낱자 입력 로직 생성기 대화상자의 2단계 페이지는 그렇잖아도 뭔가 2% 부족하고 텅 비고 허전해 보였다. 그러던 것이 이제는 UI가 더 추가되면서 아래와 같이 더 빵빵하게 바뀌었다.

사용자 삽입 이미지

그럼, 이미 있던 기능에 대해서 복습부터 해 보자.
'허용 한글 범위 제약'이란 말 그대로 특정 문자 집합에 속하는 한글만 조합을 허용하고, 이 조건을 만족시키지 않는 낱자는 다음 글자로 보내거나 무시하는 등의 처리를 하는 기능이다. 가령, KS X 1001에 정의된 한글 2350자만 조합을 허용하고 '똠, 아햏햏' 같은 글자는 조합되지 않게 할 수 있다. '또ㅁ, 해ㅎ'으로 끊어진다.

이런 기능 자체는 <날개셋> 한글 입력기가 먼 옛날, 거의 2.x 시절부터 갖추고 있었다. 2.x는 한컴 2바이트 코드 기반이었는데, 얘는 일부 옛한글을 완성형으로 표현했다. 그러니 테이블에 등록되어 있지 않은 옛한글은 애초에 조합을 거부하고 입력되지 않게 하는 기능이 반드시 들어있어야 했다.

오늘날이야 유니코드에다 문자열 + 글꼴 처리 기술의 발전 덕분에 저런 한계가 진작부터 없어졌다. 인코딩 차원에서의 한글 표현 한계로 인해서 '허용 한글 범위 제약' 같은 기능이 동원되어야 할 필요는 없다. 그러나 이런 기능은 필요에 따라서는 지금도 여전히 유용하게 쓰일 수 있다.

가령, 일본어나 중국어 같은 외국어를 한글로 입력한다고 치자. 이들 언어는 종성이 매우 적으며, 소리를 표기하는 데는 한글 음절이 수십~수백 종류면 충분하다. 그러니 두벌식으로 종성 문맥에서 ㄹ을 입력하는데, '어+ㄹ' 같은 실제로 쓰이는 글자에 대해서만 '얼'이 입력되고 나머지 상황에서는 그냥 초성 ㄹ로 빠진다면 불필요한 도깨비불 현상이 발생하지 않으니 좋을 것이다. 두벌식으로도 반쯤 세벌식 같은 효과를 낼 수 있으며 초성 검색 자동 완성을 구현할 때도 더 편하다.

이런 건 아주 간단한 예에 불과하다. KS X 1001 완성형 2350자는 워낙 역사적인 상징성이 큰 문자 집합이니 진작부터 존재해 왔거니와, 저런 식의 활용을 염두에 두고 사용자가 작성한 임의의 텍스트 파일에 있는 한글들의 입력만 허용하는 '허용 한글 범위 지정 기능'도 지난 7.9 버전에서부터 추가된 바 있다.

그런데 문제는...
이렇게 닥치고 금지하고 조합을 끊기만 하는 기능은 완성도와 유용성이 100점 만점에 70점밖에 안 된다는 것이다. 그리고 그나마 PC니까 괜찮지 모바일로 가면 70점은 택도 없고 영 못 쓸 수준이 돼 버린다. 허용되는 글자를 입력하는 도중에 금지 글자를 예외적으로 거쳐 가는 것에 대한 대비가 없기 때문이다.

대표적인 예는 KS X 1001에서 '쓩'이다. 이 글자는 허용이지만 그 중간 과정의 '쓔'는 금지인 것으로 잘 알려져 있다. 그러니 무턱대고 '쓔'를 금지했다가는 허용 글자인 '쓩'도 입력할 수 없게 된다.
PC용 두벌식 + KS X 1001 기준으로는 이런 고아 글자가 5자 정도 알려져 있는데, 모바일로 가면 이런 예가 더욱 많아진다. 프로그램을 짜서 조사해 보면 수백 개에 달한다. 가령, 천지인에서는 ㅇ을 거쳐서 ㅁ을 입력한다는 특성상 '틈'을 입력하기 전에 금지 글자인 '틍'을 거친다. '폈'을 입력하기 위해서는 금지 글자인 '폇'을 거쳐야 한다.

그러니 범용적인 '허용 한글 범위 제약' 기능을 매끄럽게 구현하려면 허용-금지 문자 집합뿐만 아니라 지금 입력 방식을 총체적으로 분석해서 pre-compute된 메타정보를 갖고 있어야 한다. 부득이하게 입력을 허용해야 하는 중간 단계 글자가 무엇인지가 그 입력 방식의 구조에 따라 달라지기 때문이다.

이번 8.9의 로직 생성기는 '지정된 파일에 들어있는 한글' 범위(입력 일반 탭)가 읽어들이는 것과 동일한 형태의 텍스트 파일을 줘서 허용 한글 범위를 지정할 수 있다. 단, KS X 1001은 워낙 유명하고 프로그램 내부에 테이블이 들어있기도 하기 때문에 별도의 파일 지정이 필요 없다.

그 뒤 중간 과정 글자의 표현 방식을 지정할 수 있다. '쌰' 같은 중간 글자를 (1) '샤'나 '썅'과 다를 바 없는 온전한 형태로 그대로 표시할지, (2) 아니면 끊어진 것처럼 풀어서 표시하되 조합은 다 유지하고 있게 할지, 혹은 (3) 나랏글에서 대결합 ㅜ+ㅏ를 ㅝ로 바로 자동 완성해서 표시하는 것처럼 '쌰'만으로 목적지인 '썅'을 자동 완성할지를 고르면 된다.

그러면 이 프로그램은 기본으로 규정된 한글 문자 집합 데이터에다가 추가로 허용돼야 하는 중간 글자들을 덧붙인 문자 집합 데이터 파일을 추가로 생성하고, 이 데이터를 '허용 한글 범위'로 사용하는 입력 설정을 생성해 준다. 그리고 중간 글자를 표현하는 방식 중에서 (2)와 (3)은 <날개셋> 한글 입력기의 '고급 입력기'가 제공하는 글자 단위 출력 치환을 이용해서 구현한다.

(3)의 경우 목적지가 둘 이상 존재 가능하여 하나로 딱 떨어지지 않으면 (1) 타수가 더 짧은 놈, (2) 목적지가 사전 오름차순 정렬에서 먼저 등장하는 놈의 순으로 선택된다. 가령, 천지인의 경우 '쌋'이라는 중간 문자는 추가 입력을 통해 '쌌'이 될 수 있고 '쌓'도 될 수 있다. 이 경우 타수가 더 짧은 '쌓'이 먼저 제안되며, ㅅ을 끝까지 계속 눌러서 실제로 '쌌'을 입력해야 글자가 바뀐다.

사실 두벌식은 종성과 초성 사이의 연속 입력 문제--종성의 마지막 소결합이 다음 글자의 초성으로 고스란히 넘어갈 수 있음-- 때문에 허용 한글 범위 제약 기능을 구현하기가 더욱 어렵다.
어떤 초성+중성 다음에 받침 ㄱ이 허용된다면 ㄱ으로부터 해당 입력 방식에서 소결합 차원에서 파생 가능한 ㅋ, ㄲ 같은 것도 원칙대로라면 몽땅 다 허용해 줘야 한다. 그래야 해당 자음을 다음 글자에서 연속 입력할 수 있기 때문이다.

그런데 그렇게 해 버리면 모바일 입력 방식의 경우 추가적으로 허용되는 글자가 너무 많아진다. '액'이 된다는 이유만으로 '앸', '앢'도 다 허용해야 하고 '밟' 이후로 '밢' 같은 것도 허용해야 각각 'ㅋ, ㄲ, 발ㅍ' 같은 연속 입력을 할 수 있게 된다.

그렇기 때문에 두벌식의 자음 연속 입력을 위한 미래형 도깨비불은 기본적으로 '초성 분리' 형태로 행해지게 했다. '액'에서 ㅋ, '밟'에서 ㄿ로 넘어가는 순간에 ㅋ과 ㅍ은 다음 글자로 넘어가 버리고 그 자음이 ㄱ이나 ㅂ을 순환하게 된다. 그래서 연속 입력을 가능하게 하는 동시에 앞 글자에서 중간 단계의 종성을 붙들고 있어야 하는 가짓수를 줄였다.

물론 그런 파생되는 글자 중에 붙잡고 있어야 하는 글자가 존재한다면 분리시키지 않고 붙잡고 있는다. 예를 들어 '각' 다음에 '갘, 갂'은 건질 만한 게 없으니 분리되지만 '박' 다음에 '밬'은 분리되지 않고 전체 조합이 유지된다. 나중에 '밖'이라는 허용 글자가 만들어질 수 있기 때문이다. 이거 제어하는 기능이 얼마나 까다로운지 알 수 있다.

'허용 한글 범위 제약'이 제대로 돌아가려면 이 정도로 복잡하고 정교한 세부 기능이 필요하다는 것을 10여 년 전에도 본인이 모르지는 않았다. 그래서 2003~04년, <날개셋> 한글 입력기가 무려 3.0이 개발되던 시절에는 구체적으로 어떻게 구현할지는 아직 모르겠지만, 어쨌든 문자 집합을 고른 뒤에는 이와 관련된 '세부 동작'을 어떻게 할지도 지정하는 UI가 제공되었다.

사용자 삽입 이미지

'가까운 글자로 근사'가 앞서 소개한 자동 완성과 같은 개념이며, '풀어 쓴 상태로 조합'도 이해하기 어렵지 않을 것이다. 이런 개념들을 다~ 먼 옛날부터 생각은 하고 있었다. 단, '롤백'은 무슨 '빠꾸' 기능 같은데 무엇을 의도하고 집어넣었던 것인지 잘 모르겠다만..
저건 아직 지원되지 않는 기능이라고 (x)가 쳐진 채 오랫동안 잉여 UI로 전락해 있었다. 그러다가 이건 가까운 시일 내에 구현이 영 무리이겠다는 판단 하에 UI가 언제부턴가 완전히 삭제되고 오늘날에 이르렀다.

이 오랜 숙제가 8.9 버전에서 해결되었다. '쌰'만 입력했는데 '썅'이 자동으로 완성되게 하는 이론적인 근거를 마련하는 건 결코 쉬운 일이 아니었다. 지금 있는 입력 설정을 사전에 총체적으로 분석해서 pre-computed된 메타정보를 넣어 준 뒤에야 간신히 구현되었다.
자체 에디트 컨트롤의 스크롤 막대에 치명적인 문제가 있던 것도 무려 15년 묵은 버그였고 오랜 숙제들이 여럿 해결되었으니 뜻깊은 일이 아닐 수 없다. 그래서 번호도 상징성이 큰 9.0으로 정하고 싶었으나.. 뭐 8.9에서 미리 선보이게 됐다.

이런 기능들을 구현하기 위해 '허용 한글 범위 제약' 기능은 단순히 한글의 허용 여부를 예/아니요로만 지정하는 게 아니라 허용하더라도 등급을 줘서 허용할 수 있게 구조를 확장했다. 그리고 '다단계 낱자 분리'를 오토마타 차원에서 지정 가능하게 했다.

자, 지금까지 늘어놓은 개념들을 요약하면, 단순히 허용/불허 글자 지정 기능을 넘어서 (1) 중간 과정 글자 챙기기, (2) 두벌식 연속입력 가능성 챙기기 기능이 빠른설정에 도입됐다. 그리고 이를 뒷받침하기 위해 (3) 한글 범위 제약 + 다단계 낱자 분리 기능 + 오토마타 사이의 연계 강화까지 유기적인 작업이 이뤄졌다. 먼저 소개했던 버그 수정 + 사소한 기능들과는 완전한 딴판인 분야 얘기이다.

거기에 덧붙여서 본 빠른설정에는 (4) 낱자 최적화 기능도 추가되었다. 옛한글을 사용하긴 하는데 사용하는 낱자나 글자 수는 일부에 불과한 경우, 대결합을 옛한글 전체로 주더라도 한글 데이터를 쭉 분석해 본 뒤, 실제로 쓰이는 한글의 것만 결합 규칙에다 집어넣어 주는 기능이다. 이것도 시작과 끝부분에서만 안 쓰이는 것을 커트해 주는 것과, 기존 낱자들의 입력 방식이 바뀌더라도(더 짧아짐) 안 쓰이는 낱자를 중의성이 발생하지 않는 한도 내에서 짤라 버리는 더 적극적인 최적화로 옵션 지정이 가능하다.

썰 0. 작곡과 편곡의 관계

우리가 폰이나 컴퓨터에서 매일 듣는 노래 내지 음악 음원이 만들어지기 위해서는 작사, 작곡, 편곡이라는 세 가지 작업이 필요하다.
가사를 쓰는 건 일단은 음악이 아닌 문학 소양으로 가능한 일이다.
작곡은.. 아무나 할 수 있지는 않겠지만 그래도 음악 이론 안 배워도 창의력 똘끼 충만한 사람이면 절대로 못 할 일은 아니다.

나라도 5분만 해골 굴리면 지금 내 감정을 담은 짤막한 멜로디 자체는 만들어 낼 수 있다. 단지 Looking for you 같은 급의 선율을 만들 수 없을 뿐이지.
그런데 작사· 작곡 그 자체만으로 만들 수 있는 음원은 혼자 무반주로 흥얼거리는 쌩목소리 노래 녹음뿐이다.
그 선율에다가 온갖 다채로운 화음과 반주, 비트를 만들어 넣어야 한다. 그걸 넣는 작업이 바로 편곡이다.

편곡이라 했을 때 흔히 떠올리는 연주 형태 변경은 재편곡에 가까우며, <엘리제를 위하여>를 3/8박자 못갖춘마디에서 4/4박자 갖춘마디로 주선율 자체를 바꾼다거나 하는 건 개념상 아예 리메이크에 더 가깝다. 편곡의 가장 좁은 의미는 주선율이라는 뼈대에다 반주라는 살을 붙이는 작업을 말한다.
편곡은 작곡과 같은 급의 창작은 아니지만 그래도 주선율에 대한 편곡자의 해석과 창작이 들어갈 수 있으며, 매우 다양한 편곡이 나오는 게 가능하다. 또한 편곡이야말로 본격적으로 음악· 화성 이론과 각종 악기 구성에 대한 지식을 갖춰야만 할 수 있는 일이다.

그리고 따지고 보면 한글 입력 방식을 설계 구현하는 것도 이렇게 작곡에 속하는 영역과 편곡에 속하는 영역이 서로 구분되어 있다.
천지인 가획 원리로 모음을 입력한다든가, 요런 순서대로 ㄱ~ㅎ을 배당하는 것은 작곡이다.
그러나 그렇게 기본 자모의 입력법이 정립된 뒤에 이를 토대로 복합 낱자들을 입력하는 규칙을 생성하고, 그 과정에서 발생할 수 있는 내부/음절 경계의 모호성을 해소하고, 오토마타라든가 backspace 동작 등을 세밀히 customize하는 것은 편곡의 영역에 속한다.

한글 입력은 알파벳처럼 key 글자들을 주루룩 늘어놓기만 한다고 끝이 아니기 때문이다. 아시다시피 종성 ㄱ과 초성 ㄱ은 다르고 심지어 ㄱㄱ도 ㄲ과 같지 않다. 한글 입력 오토마타가 뭔가 해석을 할 여지가 남아 있다.
음악에 대해서 주선율만 만들면 나머지 반주는 별 존재감 없이 자동으로 따라온다고 생각하기 쉬운 것처럼, 한글 입력 방식도 주선율에 해당하는 부분만 만들면 나머지 mechanical한 요소는 자동으로 따라온다고 생각하기 쉽다. 하지만 실상은 그렇지 않고 훨씬 더 복잡하다.

날개셋 한글 입력기 8.8은 "복합 낱자 입력 로직 생성기"라는 빠른설정이 도입됨으로써 단순히 한글 입력 방식이라는 음악을 작곡만 가능한 게 아니라 편곡까지 자동화해 주는 도구로 수준이 올라갔다. 그리고 8.9에서는 '한글 조합 범위 제약'과 연계된 기능이 더 추가되어 완전체에 도달한 것이다.

썰1. 두벌식 옛한글 글자판의 원조는?

PC에서 옛한글 글자판이라 함은 현대 한글에 맞춰진 기존 글쇠배열을 약간 변형해서 아래아, 여린이응 등을 집어넣은 글쇠배열을 말한다. 이것도 두벌식과 세벌식이 모두 존재한다.

두벌식은 세벌식보다 글쇠 수가 적어도 되지만 낱자와 음절의 경계 구분이 잘 안 되는 관계로 모음 filler와 조합 종료라는 비문자 특수 글쇠가 두 종류 필요하다. 전자는 종성 단독 같은 미완성 한글의 입력을 위해, 그리고 후자는 모호성 해소를 위해서이다. 이게 있어야 세벌식과 동등한 표현력을 발휘할 수 있다.
세벌식은 현대 한글과 별 차이 없는 직관적인 입력이 가능하지만, 글쇠가 워낙 많이 필요하다 보니 숫자 글쇠 위치를 차지하는 것도 모자라서 이제 숫자 자체를 포기해야 한다는 단점이 있다.

다음으로 낱자 결합 규칙의 관점에서 살펴보자면.. 현대 한글에서는 ㅃㄸㅉ이 종성에 등장하지 않는 초성 전용이었다.
옛한글은 표현 범위가 더 넓어져서 저것들도 받침으로 올 수 있는 반면, 잘 알다시피 정치음과 치두음이라는 새로운 초성 전용 낱자가 등장한다.

세벌식 옛한글은 부산 대학교 김 경석 교수가 390 글쇠배열을 변형하여 고안한 글쇠배열이 저서 <컴퓨터 속의 한글 이야기>(1993)에 소개된 게 있다. 아래아한글과 내 프로그램에서 이걸 오늘날까지 그대로 지원한다. 그 뒤로 이 분야의 후속 연구는 없다시피하니 말이다. (세벌식만으로도 얼마나 마이너한데 옛한글까지?)

그러나 두벌식 옛한글 배열은 누가 공식적으로 연구해서 논문을 발표하기라도 한 게 있는지 궁금하다. 표준 두벌식은 윗글쇠에 빈 자리가 워낙 많기도 하니 그냥 비전문가 개발자가 적당히 옛한글 자모를 야메로 집어넣기라도 했는지?

오늘날 두벌식 옛한글 글쇠배열을 구경할 수 있는 프로그램은 역시나 날개셋과 아래아한글에다가 MS 옛한글 입력기(Windows 8부터, TSF A급 전용)이다.
현재 내 프로그램은 전통적으로 Shift+ㄴ에 쌍니은, Shift+ㄹ에 쌍리을, 그리고 Shift+ㅣ에 쌍ㅣ(??)이 배당돼 있다. Shift에 더블(!) 버전이 들어있는 ㅂㅈㄷㄱㅅ 자리의 관행을 따른 것이다.

하지만 아래아한글은 그 자리에 각각, ㄶ, ㅀ, ㆌ가 들어있으며 내 프로그램도 옛한글이 처음으로 지원된 2~3.x 초창기 버전은 아래아한글과 동일했다. 사실, 쌍ㅣ는 유니코드 1.1 내지 날개셋 3~4 시절에는 있지도 않던 자모였다.
내가 언제 무슨 생각으로 배열을 왜 변경했는지는 잘 모르겠다. 세벌식도 아닌데 ㄶ, ㅀ 같은 걸 한데 배당할 필요가 있는지, 저게 초성 단독으로 중세 국어 문헌에서 많이 쓰였는지도 잘 모르겠다. 중세 국어 말뭉치를 살펴보면 옛한글의 자모 사용 빈도 통계도 뽑을 수 있을 텐데.

어쨌든 내 프로그램과 아래아한글이 두벌식 옛한글 배열이 Shift 쪽에 차이가 있다는 걸 알게 됐다. 참고로 MS 입력기는 Shift+저 자리에 딱히 다른 낱자가 배당돼 있지 않은 것 같다.

끝으로, 그러고 보니 현재 두벌식 옛한글과 세벌식 옛한글은 방점의 위치가 Shift+Y/U로 서로 동일하다는 것도 처음 알았다. 지금까지 한 번도 진지하게 생각해 본 적이 없었는데 흥미로운 사실이다.

썰2. 수록할 세벌식 글쇠배열/입력 설정 파일 모집

<날개셋> 한글 입력기는 실용성, 역사성, 구현 원리의 독창성 등의 의미를 갖는 수십여 종의 입력 방식들을 예제 차원에서 내장하고 있다. 예전에도 이에 대해 언급한 바 있다.
한글의 경우 지금까지 두벌식과 세벌식을 기발한 방법으로 절충한 입력 방식, 혹은 두벌식에서 음절 경계 구분 문제를 독창적인 방법으로 해결한 입력 방식 같은 걸 주로 수록해 왔다.

하지만 그런 것에만 신경 쓰다 보니 정작 순수 세벌식 분야의 예제의 수록에는 다소 소홀한 감이 있었다. 왼손/오른손 세벌식, 맥OS/아래아한글 97 세벌식 같은 역사적 자료 말고 뭔가 본격적으로 실용적인 성능을 염두에 둔 최근 자료는 내 기억이 맞다면 팥알 님이 먼 옛날에 제작하신 '세벌식 3-3012'이 전부이다. 그 뒤로 딱히 업데이트를 한 것도 없다.

2010년대부터 소위 세벌식 진영 내부의 파편화가 두드러지게 진행되어 온 듯하다. 글쇠배열에 관심 좀 있는 분들이 다들 자기만의 글쇠배열을 만들어서 세벌식 사용자 커뮤니티 내지 자기 홈페이지에다 홍보를 하고 있다. 특히 신세벌식 패러다임은 일부 희소 낱자에만 한정해서 적용한다 하더라도 확실히 피할 수 없는 요즘 대세인 듯하다. 모든 작품들을 예제로 넣을 수는 없겠지만 그래도 제작자들에게서 제작 의도를 들어 보고, 현행 세벌식 390을 대체할 만한 가치가 있는 것을 한두 개 정도 더 수록했으면 좋겠다.

뭐, 세벌식 입문자에게는 날개셋이고 한글 기계화고 뭐고 골치아픈 건 싹 다 무시하고 당장 어디서나 설정만 바꿔서 사용 가능한 세벌식 390이나 최종부터 현실적으로 권해야 하는 건 변함없다. 그러나 좀 더 편리한 글쇠배열을 연구하는 시도 자체를 혼란을 야기한다는 이유로 백안시해서는 안 될 것이다.

Posted by 사무엘

2017/04/11 08:37 2017/04/11 08:37
Response
No Trackback , 12 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1348

Trackback URL : http://moogi.new21.org/tc/trackback/1348

Comments List

  1. boolsee 2017/04/12 08:35 # M/D Reply Permalink

    글을 읽다보니 이것은 거의 제2의 한글 창제 같습니다. 고맙습니다. 세벌식 만세~~

    1. 사무엘 2017/04/12 13:32 # M/D Permalink

      설마 무에서 문자를 새로 만들고 기계식 타자기를 창조해 낸 공로에 비할 바 못하겠지만.. ^_^ 그래도 기왕 컴퓨터 같은 기계가 있고 한글 같은 문자가 이미 있는데 이 프로그램이 둘을 접목하는 도구 역할을 수행했으면 좋겠습니다.
      올해 말까지 9.x쯤에는 세벌식 글자판과 직접적인 관계가 있는 타자 편의 기능이 추가될 것입니다. 한글은 두벌식으로만 활용하기에는 너무 아까운 문자입니다. ^^

  2. baeba 2017/04/24 15:19 # M/D Reply Permalink

    대학교 전공교수님께 한글학회 회원이셨는데.
    PL 시간에 3벌씩을 사용하라고 하셔서 3벌씩을 현재 사용하고 있는중입니다.
    제 주위 사람들중에 3벌씩 사용하고 있는 사람을 본적이 없네요.
    블로그 가끔 방문해서 잘 보고 있습니다.
    화이팅입니다~~~~

    혹시 맥용 버전 개발은 안하시나요? ^^;;;

    1. 사무엘 2017/04/24 16:45 # M/D Permalink

      우와, PL 가르치는 컴공 교수가 세벌식에 한글학회와 연이 있으면 후보군이 굉장히 좁혀지는데요. 대충 누구신지 감이.. ^^
      감사합니다. 저는 많이는 안 바라고 컴퓨터라는 기계가 있고 한글이라는 문자가 있으면(굳이 한국어가 아니어도) 이론적으로 존재 가능한 모든 기술과 아이디어를 구현 가능한 한글 오덕질 환경을 만들고 싶습니다.
      맥과 모바일용은 필요성은 느끼고 있으나 제가 시간과 능력이 부족해서 못 만들고 있습니다.

  3. baeba 2017/05/01 10:15 # M/D Reply Permalink

    교수님께서 상대나오셔서 유학가서 CS로 박사학위를 받으셔서
    다른 교수님들의 강의와는 좀 차이가 있었어요..
    밑줄 쫙.. 이런 스탈..

    그리고 교수님들 스타일들이.. 학부생들 C도 잘 모르는데.
    알고리즘 숙제를 내주시고...
    도스환경에서 윈도우즈 프로그래밍 숙제를 내주질 않나 !!

    Visual C++ 1.0 나올때 교수님이 이거 뜬다고 1학년 2학기 프로젝트를
    쌩판 모르는 윈도우즈 프로그램을 하라고 해서
    동기들 전부 크리스마스 직전까지 학교에 남아서 프로그래밍 했던 기억이 있습니다.

    그 이후로 Visual C++ 을 계속해서 사용하고 있습니다만..
    제 주위에 C개발해서 먹고 사는 사람은 이제 별로 없네요.

    저는 세벌식, 와이프는 2벌식 을 쓰고 있기 때문에
    집에서 사용하고 있는 PC에서는 서로 쓰다 보면 불편할때가 많습니다.
    혹시 단축기 하나로(?) 세벌식->2벌식을 쉽게 바꿀수 있는 그런 기능을 추가해주실 수 있으신가요?

    1. 사무엘 2017/05/01 10:37 # M/D Permalink

      1. 와 VC 1.0이면 1992~93년 까마득한 옛날인데 그 교수님은 무려 그때부터 시대를 앞서 가셨던 분이군요. 대단하십니다.
      2. 그리고 단순 글자판 전환 용도로는 굳이 날개셋까지 사용할 필요 없이 세벌식 파워업이 있습니다. ^^
      http://moogi.new21.org/prg1.htm
      날개셋 내부에서는 복벌식을 쓰거나 단축글쇠 재정의로 글자판 전환이 가능하니까요.

  4. baeba 2017/05/02 10:27 # M/D Reply Permalink

    더 간단한 프로그램이 있었군요^^

    감사합니다.

    이제 조금더 편하게 쓸수 있어서 좋네요~~~

  5. 신세기 2017/05/08 13:22 # M/D Reply Permalink

    안녕하십니까 사무엘 님, 장미가 피는 5월이 되었습니다. 요즘 잘 지내시고 계십니까?

    날개셋 입력기가 이제 어느덧 9.0을 바라보고 있군요, 좋은 프로그램을 이렇게 꾸준히 개발하여 주셔서 감사드립니다.
    2010년대 들어서 갑자기 종류가 많아진 세벌식 자판들에 대해서는, 세사모 카페 회원·세벌식 이용자 분들께서 나무위키
    ( https://namu.wiki/w/세벌식/자판종류 )에 자판 종류를 정리해 놓고 있습니다.
    이 페이지를 참고해보시면 어떠실지 하는 생각이 듭니다. 혹시 이미 알고 계시는데도 제가 말씀드린 것이라면 죄송합니다...


    p.s. 나무위키에 '날개셋 입력기'도 잘 설명이 되어 있군요.( https://namu.wiki/w/<날개셋>%20한글%20입력기 ) 사무엘 님께서 프로그램을 개발하시는 데에 보람이 크실 것 같습니다.

    1. 사무엘 2017/05/08 15:54 # M/D Permalink

      신세기 님, 오랜만에 뵙네요. 반갑습니다. ^^ 요즘 날씨는 참 좋은데 미세먼지가 그 좋은 날씨 다 망치고 있죠? ㅜㅜ
      날개셋 한글 입력기는 일단 오는 6월 말쯤 공개를 목표로 9.0이 개발 중이며, 블로그 글 하나 분량을 차지하는 작업 내역이 이미 쌓여 있습니다.

      제가 생각한 것보다 세벌식 글쇠배열 내지 입력 방식 파생형이 굉장히 많이 나와 있고, 그걸 한데 정리해서 나무위키 같은 데에 올리는 분도 계시니 참 고맙네요. 저는 바쁘고 힘들어서 계속 만들고 개발하는 일밖에 못 하는데 프로그램을 활용하는 걸 알려 주시는 분들이 계셔야 세벌식의 인지도와 저변도 더 확대될 수 있을 겁니다.

  6. 신세기 2017/05/10 09:55 # M/D Reply Permalink

    안녕하십니까 사무엘 님. 어제 저녁에 황사가 물러간 듯하여 공기 상태는 이제 다행인 것 같습니다. 어제 한국 내 기독교인의 실제적인 비율에 충격을 받아 답글이 늦어졌습니다, 죄송합니다...

    벌써 9.0을 위한 많은 작업이 진행되어 있었군요, 이렇게 열정적으로 만들어주셔서 감사합니다. 저희 같은 이용자들도 날개셋 입력기 홍보에 힘써야 되겠군요! 부디 날개셋 입력기와 세벌식의 입지가 더욱 확대되기를 고대합니다. 계속 응원드리겠습니다, 사무엘 님.

    1. 사무엘 2017/05/10 11:33 # M/D Permalink

      네, 말씀하신 대로 요 근래에 날씨는 참 좋았는데 미세먼지가 최악이었죠. 나라 사정은 더 나빠졌고.. 이미 을사조약을 겪었는데 한일병합은 이미 막을 수 없는 대세이니 저는 어느 정도 각오는 하고 있었습니다.
      게다가 그게 신자들의 지지와 기여까지 크게 보태어져서 이뤄진 것이니 정말 치욕스러운 역사로 기록될 겁니다. 기독교는 없어지지 않습니다. 단지 변질될 뿐이라는 걸 느낀 하루였습니다.

      신앙의 자유, 코딩의 자유가 박탈되는 날이 온다면 날개셋 한글 입력기는 저의 유작으로 남게 되겠지만, 저는 숨이 붙어 있고 개발할 거리가 있는 한 최선을 다하렵니다. 세벌식 관련 특화 기능도 하반기 이후쯤부터는 도입될 겁니다. ^^

  7. 신세기 2017/05/11 23:16 # M/D Reply Permalink

    사무엘 님의 열정이 정말 멋지십니다 ^^ 사무엘 님의 혼이 형통함같이 형통하고 건강하시기를 기도드리겠습니다! 이 나라도 '사람'이 아닌 '하나님'을 갈망하는 나라로 변화되기를 기도합니다...

Leave a comment

날개셋 한글 입력기 8.8이 나온 지도 두 달 남짓한 시간 만에.. 새 버전을 공개하게 되었다.
원래 내 계획은 새 기능 추가에만 계속 전념하다가 올해 6월 말쯤에 깔끔하게 9.0을 공개하는 것이었다. 그러나 지금까지 발견되고 수정된 버그들만 해도 꽤 중요하고 만만찮은 것들이 잔뜩 쌓이면서.. 결국 원래 구현하려던 주요 기능 하나만 작업을 마친 뒤에 8.9를 한번 더 거쳐 가기로 결정을 내렸다. 그 긴 시간 동안 심혈을 기울여 완성했던 8.8마저도 완벽한 물건이 아니었다.

원래 이 글도 새 버전 소개가 아니라 그냥 다음 버전 개발 근황 정도를 소개하는 글이 됐을 예정었으나, 글의 성격이 바뀌었다. 분량이 매우 긴 관계로, 이번 상편에서는 버그 수정과 작은 기능 얘기부터 먼저 하고, 중요한 기능 추가분은 다음 시간에 소개하겠다.

1. 오랜 버그: 스크롤 막대 딜레마 문제

이번 새 버전에서는 <날개셋> 한글 입력기의 전용 에디트 컨트롤에 존재하던 "아주 오랜 지병"이 하나 극적으로 치료되었다. 그 지병은 바로 스크롤 막대와 관계가 있다.
이건 편집기에 '자동 줄바꿈'이라는 기본 옵션이 제공된 이래로.. 3도 아닌 자그마치 2.x 시절부터 지금까지 근 15년 가까이 전혀 고쳐지지 않고 고스란히 남아 있던 문제였다. 가끔 이런 문제가 발생한다는 것이 경험적으로 알려져 있긴 했지만 그 빈도가 매우 낮으며 정확한 재연 조건을 알 수 없었다.

가끔 재연되는 케이스를 발견했을 때에도 스크롤 막대 관련 코드를 대충 건드려 보는 것만으로는 원인과 해결책을 알 수 없었다. 그래서 더 추가적인 작업 없이 프로그램은 이런 버그가 잔류한 채로 2.x에서 무려 9 직전까지 버전이 올랐다.

문제가 뭐냐 하면, "자동 줄바꿈 + 스크롤 막대"를 켜 놓고 새 문서를 텅 빈 상태에서 차근차근 작성해 보면 된다. 문서가 차지하는 영역이 가로와 세로로 적당히 한 화면의 크기를 초과할 즈음이 되면 스크롤 막대가 생긴다.

사용자 삽입 이미지

위의 그림처럼 '가나 다라'를 중간의 공백이 줄 사이에 걸치게 입력한다. 그러면 공백 때문에 가로 스크롤 막대가 생기는데, 그 상태에서 엔터를 계속 눌러서 줄 수가 늘어나서 세로 스크롤 막대가 생기게 해 볼 것. 그러면 뜻밖에도 편집창 화면의 테두리가 갑자기 저렇게 깨진다. 기술 용어를 동원하자면, non-client 영역의 표시가 맛이 간다.

사용자 삽입 이미지

이 현상은 계속 엔터를 눌러서 줄수가 늘어나면 없어지긴 한다. 하지만 도대체 저 현상이 왜 발생하는지 근본적인 원인을 알 길이 없었다. 한때는 참 당돌하게도 이건 가로· 세로 스크롤 막대 설정이 미묘하게 꼬였을 때 발생하는 운영체제의 버그이려니 하고 안일하게 생각하고 넘기기도 했다. NT 계열이 아닌 Windows 9x에서는 이때 프로그램이 아예 통째로 뻗기까지 했는데도 말이다.

이 문제의 원인은 내가 '스크롤 막대 딜레마'라고 이름을 붙인 아주 기묘한 현상 때문이었다.
처음에는 가로 스크롤 막대만 있는데, 줄 수도 늘어서 세로 스크롤 막대가 추가되었다. 그러면 세로 스크롤 막대가 차지하는 공간 때문에 편집창도 폭이(클라이언트 영역의 가로 크기) 감소한다. 자동 줄바꿈 옵션이 켜져 있다면 새로운 폭을 기준으로 텍스트의 문단 정렬이 다시 행해진다.

이제 스크롤 막대가 가로와 세로에 모두 생겼다. 그런데 편집창의 폭이 감소하면서 지금까지 가로로 한 칸 툭 튀어나오던 공백이 다음 줄로 완전히 이동했다. 가로 스크롤 막대가 필요 없어진 것이다. 그래서 최종적으로는 세로 막대만 남는 것 같은데...

이것도 끝이 아니다. 가로 스크롤 막대가 없어지니까 편집창의 높이가 증가했다. 그 결과 텍스트의 모든 줄이 한 화면에 표시가 가능해지고 세로 스크롤 막대조차 필요 없어진다. 그러니 모든 상황은 스크롤 막대가 전혀 없던 원점으로 돌아오는데...

세로 스크롤 막대가 없어지고 편집창의 폭이 원래대로 돌아오자 아까처럼 공백이 다시 줄 경계에 걸려서 가로 스크롤 막대가 필요해지는 상황으로 되돌아온다.
이솝 우화로 치면 당나귀에다 아들(가로 스크롤)만 태워도, 아버지(세로 스크롤)만 태워도, 둘 다 태워도, 둘 다 걷게 해도 어떻게 해도 사람들이 욕을 하는 것과 같은 상황이 되는 것이다.

WM_SIZE 메시지를 처리하는 과정에서 스크롤 막대의 상태가 바뀌고, 그게 또 WM_SIZE를 중첩 생성한다. 이건 이론적으로는 무한 루프에 빠지지만 실제로는 함수의 호출 깊이가 한없이 증가하기 때문에 스택 overflow로 이어진다. 다만, 대놓고 내가 짠 함수로만 스택이 깊어지는 게 아니라 message loop이 중첩해서 쌓이기 때문에 상황을 곧장 파악하지 못했을 뿐이었다.

이 문제를 해소하기 위해 WM_SIZE 메시지와 스크롤 막대 처리 함수가 일정 깊이 이상으로 종료 없이 중첩 호출되는 것을 감지하는 코드를 추가했다. 이런 꼬인 상황에서는 양방향 스크롤 막대를 깔끔하게 모두 제거시켰다. 이로써 문제를 해결했다.

사용자 삽입 이미지

2.x 때부터 있었던 지병이 9.0을 바라보는 타이밍에서야 고쳐졌다는 게 참 감개무량하다. 이건 버그가 아니라 지병에다 비유하고 싶었다. 또는 몇십 년 전에 전사한 무명용사의 유해를 이제야 DNA 감식을 통해 다시 찾아내고 신원까지 파악한 듯한 느낌에다가도 비유할 수 있겠다.

15년 전부터 존재하던 버그가 뒤늦게 고쳐지기도 하니 이 쾌감에 내가 코딩 중독에서 빠져나올 수가 없는 거다. 이걸 고칠 생각을 하게 된 건 우연한 계기 때문이었다. 지난 8.8에서 해치운 작업들을 다 삭제하고 to do list를 정리하고 있었는데, 하필 이 문서가 스크롤 막대 딜레마 오류를 일으키고 있었기 때문이다.

세월이 흐르면서 본인의 절대적인 프로그래밍 실력...이라기보다는 일단 품질을 보는 눈이 예전보다 높아졌다. 예전에는 대충 적당히 만들었던 것을 지금 꼼꼼하게 다시 개량하는 게 개발 트렌드가 됐다. 과거의 철도가 자갈 노반 나무 침목 단선 비전철이라면 지금은 콘크리트 노반과 침목에 복선 전철이 기본인 것처럼 말이다.

2. 조금 거시기한 버그: 타자연습에서 또 외부 모듈을 사용할 때의 충돌

이건 입력기 엔진의 직접적인 문제는 아닌데..
<날개셋> 타자연습에서 외부 모듈(IME)를 또 구동할 때 외부 모듈에서 플러그 인의 기능들을 사용하지 못하는 충돌 문제가 꽤 오래 전부터 있었다. 그걸 사용자의 버그 신고 덕분에야 인지하여 문제를 해결했다.

사실, 외부 모듈이 이미 <날개셋> 한글 입력기를 사용하고 있는 편집기나 타자연습 같은 프로그램(호스트)의 밑에서 돌아가는 상황에 대한 대비 자체는 오래 전부터 돼 있었다. 호스트가 자신과 바이너리 호환이 되지 않는 날개셋 엔진을 사용할 경우, 외부 모듈은 자기에게 맞는 엔진을 따로 로딩하게 했으며, 한 프로세스에 디렉터리 위치만 다른 ngs3.dll이 동작하더라도 문제가 없게 조치를 취했다.

저것 자체는 늦어도 지난 2010년대 초에 이미 다 이뤄진 일이다. 하지만 이번 문제는 그것과는 별개인 또 다른 문제였다. 동일한 ngs3.dll이 두 번 로딩되었는데 플러그 인은 한 군데밖에 없다 보니 한 프로그램에서는 내부 구조의 문제로 인해 플러그 인을 사용할 수 없었다.
이런 문제가 존재할 거라고 전혀 생각을 못 하고 있었는데 결국은 ngs3.dll을 불러들이는 방식을 변경해서 불가피한 경우가 아니면 중복 로딩이 되지 않게 했다.

3. 그럭저럭 내력이 있는 버그: 부팅 전후 외부 모듈의 crash 문제

8.8을 공개한 뒤에 의외로 외부 모듈의 안정성과 관련된 결함이 몇 군데 발견되어 해결되었다. <날개셋> 한글 입력기를 운영체제의 기본 IME로 지정한 뒤 Windows 7 기준으로,
(1) 처음 부팅을 하면 explorer 프로세스에서 오류가 발생할 수 있다.
(2) 시스템을 로그아웃/종료할 때 taskhost 프로세스에서 오류가 남.

(1)의 경우 일반적인 상황에서는 발생하지 않고 날개셋 커널이 로딩되지 못해서 외부 모듈도 아무런 제공 기능 없이 시체 상태로 동작할 때에만 그런다. IME라는 게 live 업데이트가 쉽지 않은 프로그램이다 보니, 설치 후에 재부팅을 제대로 하지 않고 뭐가 꼬이면 커널과 외부 모듈의 버전이 서로 안 맞아서 아주 드물게 저런 상황이 발생할 수 있는 듯하다.
이유야 어쨌든 날개셋 외부 모듈은 시체 상태이더라도 최소한 프로그램을 뻗게 하지는 않아야 하므로, 이는 의도하지 않은 버그이긴 하다.

그리고 (2)는 지난 8.5 버전에서 각종 이벤트 통지 기능이 추가되면서(프로그램 활성화, 글자판 전환 등) 민감한 곳을 건드리다가 생긴 버그이다. 저렇게 짜도 다른 프로그램들은 아무 문제 없는데 유독 저 프로세스만 탈을 일으켰다.
지금까지 잘만 돌아가다가 왜 그 상황에서 있어야 할 오브젝트가 온데간데없이 사라졌고 NULL인지는 정말 '귀신이 곡할' 노릇이고 도무지 알 수 없다. 그냥 결과론적인 안전 점검 루틴을 추가하는 것밖에 대처 방법이 없었다.

게다가 평범하게 문제가 발생하는 게 아니라 로그아웃/시스템 종료를 하는 순간에만 잠깐 발생하고, 그때는 종료를 취소하고 디버거를 띄울 수도 없었기 때문에 더욱 난감했다. 그래도 다행히 그때 예외 처리기 분기와 덤프 파일 생성이 됐기 때문에 이 정보와 pdb 파일을 토대로 당시 스택 프레임을 재구성하고 문제 발생 지점을 찾아낼 수 있었다.

(1)과 (2) 모두 문제가 발생한 곳은 의외로 구닥다리 레거시 imm32 프로토콜 기반의 IME 계층 쪽이었다. TSF 쪽이 아님.

4. 직전 버그: 외부 모듈에서 초성 조합 중에 특수문자 변환이 되지 않는 문제

이번엔 고질병과는 반대로 직전의 8.8 버전에만 존재하는 버그 얘기이다.
개발 연혁이 15년이 훌쩍 넘어가는 프로그램에서 더는 이런 어처구니없는 실수가 없어야 정상이겠지만 안타깝게도 그런 예가 하나 발견되어 이 자리를 통해 알리도록 하겠다.
8.8 버전은 외부 모듈에서 ㄱ~ㅎ 같은 자음을 조합하고 있는 상태에서 후보 변환(한자 같은)을 눌러 특수문자를 입력하는 기능이 제대로 동작하지 않는다.

더 구체적인 문제 발생 조건은, 자음을 호환용 한글 낱자로 바꿨을 때(외부 모듈 환경 또는 최종 변환 규칙을 통해서)이다. 그렇기 때문에 편집기에서 최종 변환 규칙 없이 그냥 자음을 단독으로 입력하고 있을 때는 문제가 없다.

이것은 8.8에서 새로 추가된 '앞에서 뒤로 탐색하여 단어 단위 한자 변환' 기능으로 인해 발생한 부작용이다.
새 기능인 '앞에서 뒤로 탐색'(즉, '토선생'을 변환하면 '선생'이 아니라 '토선'이 먼저 제안되는 것)을 선택했을 때는 그런 부작용이 없고, 예전부터 지원되던 동작인 '뒤에서 앞으로 탐색' 또는 단어 단위 한자 변환을 사용하지 않으면 저렇게 초성+한자 특수문자가 동작하지 않게 된다.

메모장은 TSF 확장 옵션을 사용하지 않으면 어차피 단어 단위 한자 변환이 동작하지 않는 환경인데도 저런 옵션의 영향을 받는다.
사소한 버그이기 때문에 다음 버전에서는 문제가 곧장 고쳐졌다.

5. 기능 추가: 외부 모듈에 키보드 드라이버 배열 미리보기

외부 모듈의 '시스템 - 고급 시스템 옵션' 제어판 페이지에는 지난 8.6때부터 "한글 IME와 연결할 영문 키보드 드라이버" 지정 기능이 추가되었는데, 사용자가 선택한 키보드 드라이버의 글쇠배열을 간단하게 미리 들여다보는 기능이 추가되었다.
<날개셋> 한글 입력기에 키보드 드라이버를 바로 불러오는 기능은 무려 10년 전 4.4 버전부터 존재했다. 그러니 그 기능을 여기에다 연계하지 못할 이유가 없다.

사용자 삽입 이미지

'보기' 링크를 누르면 글쇠배열 그림이 별도의 modal 대화상자의 형태로 뜬다.
좀 더 욕심을 내자면, 옛날에 MS Excel에서 차트 미리보기 기능처럼 뭔가를 누르고 있는 동안만 preview가 뜨고, 버튼에서 손을 떼는 순간 그림이 사라지는 게 내 본래 의도이다.

하지만 그런 기능이 운영체제의 표준 GUI에는 존재하지 않고, 또 키보드 드라이버 변경 기능이 한글 입력과 직접적인 관계가 있으면서 많이 쓰이는 기능은 아니라고 생각되어 그냥 이 정도 기능만 넣는 것으로 그쳤다.

6. 그 밖에

(1) 외부 모듈과 변환기에는 유니코드 5.2 옛한글을 호환성 차원에서 1.1 과거 방식으로 풀어서 표시하는 옵션 내지 기능이 있는데.. 8.8 버전에서는 이 부분의 코드가 리팩터링 되던 과정에서 더 풀어서 표시해야 하는 낱자를 풀지 않고 잘못 표시하는 문제가 들어갔음을 뒤늦게 발견했다.
가령 ㅗㅒ는 ㅗㅑㅣ로 더 풀어야 하고 중성엔 ㅛㅐ, ㅠㅐ, ㅣㅖ, ㅡㅔ, ㅣㅒ, ㆍㅔ 같은 예가 더 있다.
오늘날이야 유니코드 1.1 옛한글은 한양 PUA보다도 인지도가 없고 거의 쓸 일 없으니 당장 대다수 사용자에게는 별 여파는 없는 문제이긴 한데, 이런 문제 자체가 있다는 건 밝힌다. 이번 새 버전에서 곧장 해결되었다.

(2) Metro 앱에서 시스템 계층의 키보드 드라이버 보정 기능이 동작하지 않던 것을 동작하게 했다. (연결되는 키보드 드라이버 자체를 변경하는 것은 여전히 지원 불가) 그리고 지금까지 Internet Explorer 11 내부의 텍스트 입력란(주소 입력란 말고)에서 외부 모듈의 글자판 동기화가 되지 않고 입력 패드도 동작하지 않던 문제를.. 우연한 계기로 드디어 해결했다.
IE는  IME 개발자의 입장에서 굉장한 요물이고 뭔가 자체적인 샌드박스 같은 환경을 갖춘 것 같았는데 메트로만치는 아니어도 어느 정도 샌드박스가 있긴 했다. 이런 부류의 문제들이 하나하나 해결돼 가는 걸 보는 건 내 인생의 낙이다.

(3) 오랫동안 '외장형 후보' 예제 데이터 파일로는 구결밖에 없었는데, 정 재민 님의 제안으로 대법원 제정 인명용 한자 목록 8000여 자를 추가했다. 제1후보를 대체하는 물건으로 활용 가능하다.
이게 의외로 종이 문서나 이미지로만 존재하거나, 글자별 조회만 가능하지 전체 목록을 뽑기가 쉽지 않았는데 일일이 목록을 만든 분이 국내도 아니고 일본에 있었다. (☞ 출처) 참고로 인명용 한자는 한번 정하고 끝이 아니라 계속 추가되는 편이다.

(4) 타자연습의 게임은.. 아예 운영체제의 표준 GUI만 사용하는 다른 연습 UI보다는 비주얼이 낫겠지만, 그래도 요즘 게임 트렌드에 비해서는 기술적으로 너무 뒤쳐진 구닥다리가 됐고 게임 시스템도 좀 바꿔야 할 때가 됐다.
하지만 전면개편을 하기에 앞서..;; 또 사소한 UI를 좀 고쳤는데,

게임 화면 하단은 시스템의 색상과(특히 고대비 검정 같은) 관계없이 언제나 흰 배경에 검은 글자로 찍히게 했다.
그리고 컴퓨터 속도가 2GHz를 넘어간다 싶으면 "256색 전체 화면" 옵션을 없애고 표시하지 않게 했다.
옛날에 Windows 2000/XP 초창기에는 256색 전체 화면이 트루컬러 전체 화면보다 속도가 더 빠르고 진행이 원활한 경우가 있어서 저 옵션을 넣은 것이었지만, 오늘날이야 당연히...;; 아무 차이가 없어졌기 때문이다.
게임도 창 모드로 실행될 때는 자기 별도의 창을 띄우는 게 아니라 프로그램 main 창 내부에서 돌아가게 하고 싶긴 하다.

추신: 외부 모듈이 IME 목록에 나타나지 않는 이유는?

<날개셋> 한글 입력기를 설치하고 나면 외부 모듈도 일부러 제외하지 않은 한 같이 설치되고 운영체제 IME로서 등록된다.
그런데 <날개셋> 한글 입력기가 한 번도 설치된 적이 없던 완전히 새 컴퓨터에다 프로그램을 처음 설치한 경우, IME 목록에 내 프로그램이 제대로 뜨고 있는지 궁금하다.

IME 목록에 곧장 나타나지 않는 경우도 종종 있어서 말이다. Windows 8/10에서 특히 그러하다. 이 경우, 입력 언어 제어판을 꺼내서 '한국어 - 추가'를 누르면 거기에 <날개셋> 한글 입력기가 숨어 있곤 한다. 이걸 수동으로 꺼내야 사용 가능하다.

이것은 기술적으로는 입력 언어의 enable/disable 상태 차이 때문에 그렇다. 그런데, 새로 등록된 내 IME를 enable시키려면 이러이러한 함수를 호출하면 된다고 MSDN에서 시키는 대로 다 했는데도 일부 컴퓨터에서는 설치 직후에 <날개셋> 한글 입력기가 곧장 나타나지 않는 듯하다.
현재로서는 이유를 알 길이 없다. 그럴 때는 딱히 해결책이 없으며, 사용자가 수동으로 내 입력기를 추가해 주면 된다고 도움말에다 써 놓기만 했을 뿐이다.

(下에서 계속됨)

Posted by 사무엘

2017/04/08 08:38 2017/04/08 08:38
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1347

Trackback URL : http://moogi.new21.org/tc/trackback/1347

Comments List

  1. boolsee 2017/04/10 08:39 # M/D Reply Permalink

    날개셋 정말 잘 사용하고 있는데 이제 벌써 9.x 를 바라보고 있네요? 좋은 프로그램 만들어 주셔서 대단히 고맙습니다.

    1. 사무엘 2017/04/10 09:14 # M/D Permalink

      본격적으로 졸업 준비 모드로 들어가기 전까지 올해 중으로 9.x 정도까지는 가게 되겠습니다.
      격려의 말씀에 대단히 감사드립니다. ^_^

Leave a comment

0. 들어가는 말

<날개셋> 한글 입력기와 타자연습이 개발 17년째에도 변함없이 온갖 새로운 기능들로 무장하여 새 버전이 나왔다. 4개월 동안 정말 많은 기능들이 추가되고 개선되었다. 지금까지 올라온 개발 근황글 시리즈만 봐도 이번 버전은 뭔가 심상찮다는 것을 알 수 있을 것이다.

정상적인 개발 사이클이라면 지금보다 더 전에 새 버전이 나오고도 남았을 텐데 이번 버전만 이례적으로 중간 개발 근황글이 많아진 이유는..
8.8의 개발 완료 조건은 따로 있었는데 그게 너무 어려워서 오랫동안 충족되지 못하는 동안, 다른 분야에서 새 기능들이 잔뜩 추가되고 개선 사항이 생겼기 때문이다.

그것들이 새 버전 형태로 석방(release)되지 못한 채 장기간 갇혀 있었다. 지금 새 기능 리스트를 다시 읽어 보면 나로서는 "아니 이건 언젯적 작업 내역인데 8.6에서는 아직 반영이 안 된 상태였구나. 내 프로그램 사용자들은 작년 10월 이후로 시간이 정지해 있었구나!" 싶은 것들이 많다. 그걸 이제야 훌훌 털어내고 밖으로 내보내게 되어 참 기쁘다.

이 글에서는 이번 8.8 버전에서 궁극적으로 추가하려고 했고 시간적으로 제일 마지막에 구현된 '복합 낱자 입력 로직 생성기'에 대해서 소개하도록 하겠다. 이것은 <날개셋> 한글 입력기가 제공하는 '빠른설정' 중의 하나이다.

1. 빠른설정

빠른설정이란 어떤 입력 항목에 대해서 사용자가 선택한 옵션대로 입력 스키마와 문자 생성기를 곧바로 세팅 해 주는 보조 GUI의 총칭이다. 지금 이미 지정돼 있는 입력 설정을 보완· 변경할 수도 있고, 그건 싹 무시하고 완전히 새로운 입력 설정으로 덮어쓸 수도 있다.

요런 개념과 기능은 먼 옛날, <날개셋> 한글 입력기 3.0에서 처음으로 도입됐다. 그리고 역사상 최초로 도입된 빠른설정은 '기본 글자판 설정'이었다. 두벌식, 세벌식, 쿼티, 드보락처럼 사용자가 가장 자주 사용하는 한글과 영문 글자판을 묻지도 따지지도 않고 곧바로 맞춰 주는 중요한 역할을 한다. 한글의 경우 옛한글 사용 여부, bksp의 동작 단위 같은 옵션을 받기도 한다.

그러다 지난 2006년, 3.9 버전에서 빠른설정이 3개가 더 추가되어 4개가 되었으며, 빠른설정은 이렇게 4개가 거의 10여 년 동안 변경 없이 그대로 유지돼 왔다.
먼저, 한글 로마자 입력기. 얘는 기반 영문 글쇠배열(쿼티 or 드보락)과 로마자-한글 매핑 방법 같은 몇 가지 옵션을 받아서 로마자 입력 방식을 설정해 준다. 한글 로마자 입력 방식이라는 건 딱 한 가지만 존재하는 게 아니라 어떤 공통된 사상, 이념, 컨셉에 속하는 다양한 입력 방식들을 찍어 내는 '메타 입력 방식'에 가깝다. 그러니 이런 건 '빠른설정'이 커버하기에 적합하다.

한글 로마자 입력기는 한국어· 한글을 배우는 외국인에게 매우 유용하다. 그래서 <날개셋> 한글 입력기의 영문 페이지는 프로그램의 모든 기능을 영어로 소개하지는 못하는 대신, 입력 설정을 로마자 입력 방식으로 바꾸는 방법만을 간단히 안내해 놓았다.

나머지 빠른설정은 주어진 세벌식 글쇠배열을 표준 두벌식 배열과 합성해 주는 '복벌식 빠른설정', 그리고 한 글쇠에서 초성과 종성이 아니라 중성과 종성을 수식으로 구분해서 합성한 '신세벌식 빠른설정'이 있다. 이들 역시 두벌식과 세벌식을 절충하는 훌륭한 메타 입력 방식이므로 빠른설정 형태로 구현했다.
전자는 타자가 처음에 왼손으로 시작됐으면 두벌식, 오른손으로 시작됐으면 세벌식으로 인식해 준다. 후자는 도깨비불 현상이 없으면서 4단도 사용하지 않는 입력 방식이라는 의의가 있다.

'기본 글자판'과 '한글 로마자 입력기'는 완전히 새로운 입력 환경을 맞춰 주는 빠른설정이지만 복벌식과 신세벌식 빠른설정은 기존 입력 설정에다가 변형을 가하는 형태로 동작한다.
그러다가 제5의 빠른설정인 '복합 낱자 입력 로직 생성기'가 거의 10년 만에 또 추가되었다. 얘 역시 기존 입력 설정을 변형하는 형태로 동작한다. 단, 글쇠배열 같은 입력 스키마 설정은 직접 건드리지 않으며, 문자 생성기 계층의 설정을 건드린다. 뭐, 글쇠배열을 직접 고치지는 않더라도, 필요한 경우 요런 글쇠를 사용자가 직접 배당해서 쓰라고 안내를 해 주긴 한다.

이 로직 생성기는 단순한 편의 기능 이상으로 <날개셋> 한글 입력기의 아주 중요한 핵심 기능이다. 이거 하나만 코드의 양이 2천 줄을 넘어가며, 기존 4개 빠른설정들의 코드를 다 합한 것보다도 분량이 2배 이상 많다.

2. 본 기능 소개

복합 낱자 입력 로직 생성기가 하는 주된 일은.. 초중종성의 낱자 결합 규칙을 편의상 '대결합'과 '소결합'으로 또 나눠서 대결합을 소결합 노가다만으로 몽땅 자동 생성해 주는 것이다.

좀 formal하게 표현하자면, 기존 설정(소결합)과 우리 빠른설정 자체의 설정(대결합) 사이의 cartesian product를 구한다.
그리고 이와 연동해서 같이 움직이는 가상 낱자, 특수 도깨비불, 심지어 한글 치환 규칙을 다 자동으로 맞춰 주며, 대결합과 소결합 사이에 논리적으로 충돌이 있는 것도 감지해서 보여주고 회피해 준다.

PC용 한글 입력 방식이라면 낱자 결합 규칙을 굳이 대결합과 소결합으로 나눌 필요가 없다. 하지만 글쇠 수가 왕창 적은 모바일에서 옛한글 같은 복잡한 한글 입력 방식을 구현한다고 생각하면 저런 추가적인 추상화가 반드시 필요하다.

ㅎ 같은 기본 자모를 "ㅇ+가획"(나랏글) 내지 "ㅅ+ㅅ"(천지인)의 합성으로 입력하는 건 소결합이다. 그러나 ㄴ+ㅎ으로 ㄶ을 입력하고 ㄹ+ㅎ으로 ㅀ을 입력하는 건 대결합이며 어느 입력 방식이든 동일하다. 그러면 이 로직 생성기는 소결합과 대결합을 토대로 ㄶ과 ㅀ을 입력할 때 필요한 중간 상태인 ㄴㅇ, ㄹㅇ도 날개셋의 기존 기능으로 다 표현해 준다는 것이다.

이런 예가 옛한글로 가면 얼마나 많겠는가? 게다가 두벌식의 경우는 한 낱자를 다 입력한 뒤에도 아직 안심할 수 있는 상황이 아니다. 나랏글 기준으로 ㄽ이라는 겹받침을 입력한 뒤에도 ㄹㅈ, ㄹㅉ, ㄹㅊ 같은 임시 낱자를 고려해 줘야 ㄹ 다음에 ㅈ 계열 자음들을 연속 입력을 할 수 있다.

요런 식의 자동화를 종성에 한해서 찔끔 간단하게 구현해 준 것이 바로 6.x 버전 시절에서 추가된 '초-종성 공용 낱자 결합'이었다. 하지만 임시 낱자들의 처리는 여전히 사용자가 해야 하고 한계가 많았다. 그러다가 복합 낱자 입력 로직 생성기가 추가됨으로써 <날개셋> 한글 입력기는 한글 엔지니어링의 영역을 한 단계 넓혔다.

3. 예제

사용자 삽입 이미지

위의 그림은 천지인 입력 방식을 설정한 뒤, 대결합과 소결합 사이의 관계 분석을 통해 종성-초성 사이에 연속 입력이 안 되는 pair들을 프로그램이 찾아 준 것이다. 천지인은 모든 종성에 대해서 연속 입력이 안 되는 초성이 적어도 하나 이상 존재한다. 그 반면, Google 단모음 입력기라면 ㄱ, ㅅ뿐만 아니라 쌍자음이 존재하는 ㄺ, ㄽ, ㅄ 같은 일부 자음만이 이런 조건에 걸린다.

'글자판 입력을 문자열로' 텍스트 필터에는 사용자가 입력한 문자열에 대해서 연속 입력 가능 여부를 판별하는 기능이 있는데, 이 빠른설정은 아예 구조적으로 연속 입력이 불가능한 모든 경우의 수를 찾아 준다는 차이가 있다.

사용자 삽입 이미지

천지인과는 달리 나랏글은 구조적인 모호성이 없기 때문에 로직 생성 결과가 깔끔하다. 나랏글은 소결합을 담당하는 글쇠(가획, 쌍자음)와 대결합을 만드는 타 한글 자모 글쇠가 완전히 분리되어 있기 때문이다. 다만, 생성되는 임시 낱자 수는 나랏글이 천지인보다 더 많다.

중성을 보면 나랏글에서 ㅝ를 입력하기 위해 중간에 거치는 ㅜ+ㅏ를 이 프로그램이 자동으로 처리해 줬다는 말이 뜬다. 사용자가 일일이 대결합에 등록하지 않았더라도 말이다. 그리고 이 경우, ㅜ+ㅏ까지만 입력해도 화면에는 절차를 단축해서 자동으로 ㅝ를 띄워 준다. (대결합의 마지막 단계가 확정되어 다른 선택의 여지가 없을 때)
또한 중성에는 쌍자음(501) 글쇠가 결합용으로 전혀 쓰이지 않았다는 것도 알려 준다.

사용자 삽입 이미지

이건 좀 더 엄청난 장면이다. 천지인의 모음 입력 방식을 옛한글에다가도 적용했을 때 입력 순서가 동일해져서 충돌이 발생하는 쌍을 모두 찾은 것이다. 천지인의 경우 음절 경계에만 모호성이 있는 게 아니라 한 성분 내부에서도 ㅡㆍㆍㅡ를 ㅝ(2:2)로 보느냐 ㆌ (3:1)로 보느냐 같은 문제가 존재하기 때문이다. 단, 이건 세벌식이라도 구조적으로 얼마든지 존재할 수 있는 모호성이다.

인위적인 모호성 보정이 없다면 이 프로그램은 언제나 대결합보다 소결합을 우선시하기 때문에 2:2(ㅝ)가 아닌 3:1(ㆌ)이 채택된다. 이때 모호성은 2가지 방법 중 하나로 회피할 수 있는데, (1) 먼저 사전 구분이다. 2타까지 치고 'ㅜ+보정'을 누르면 이 ㅜ는 ㅠ로 넘어가는 ㅜ가 아니라 ㅜ+ㆍ, ㅜ+ㅓ 등 대결합 경계가 바뀌는 임시 낱자 ㅜ로 바뀐다. 즉, 임시 낱자도 입력을 위한 것과 모호성 보정을 위한 것 두 종류로 나뉜다.

(2) 그리고 사후 변환을 할 수 있다. 이미 ㅠ 또는 ㆌ가 된 상태에서 이 변환을 누르면 ㅜㆍ 또는 ㅝ를 왔다갔다 할 수 있다.
이 프로그램은 입력 순서가 동일한 낱자들에 대해 일정 시점에서 구분자를 넣어서 상태를 분기하는 것을 일종의 binary tree 형태로 표현해서 관리하는데, 사전 구분은 그렇게 가지를 뻗는 것이고 사후 변환은 자신의 가장 가까운 sibling을 왔다갔다 하는 것으로 정의한다.

(1) 또는 (2), 그리고 (1)과 (2)를 모두 사용하는 것도 가능하다. 이 프로그램은 마치 나랏글의 가획/쌍자음처럼 저런 사전/사후 보정용 낱자를 초중종성 공용으로 하나 설정한 뒤, 수식을 생성해서 사용자에게 다음과 같이 안내도 해 준다.

입력 중에 낱자 결합 모호성을 해소하려면 다음 수식을 글쇠배열에 배당하여 사용하십시오.
- 사전 구분:
  F ? H2|0x25800000000 : E ? H2|0x2580000 : D ? H2|0x258 : 0
- 사후 변환:
  F ? H2|0x25900000000 : E ? H2|0x2590000 : D ? H2|0x259 : 0


또한 사후에라도 대결합 적용 방식이 바뀌는 것조차 처리해 준다. 현대 한글에서는 굳이 저렇게 보정을 하지 않아도 ㅠ 다음에 ㅣ가 입력됐을 때 ㅝ로 바로 넘어가게 할 수 있다. ㆌ가 쓰이지 않으므로 모호성이 없기 때문이다.
옛한글의 경우 위의 스크린샷에서 보다시피 소결합 단독으로 처리되던 ㅖ에서 옛한글 ㅕㅑ로 자동으로 넘어가는 것, ㅜㅡ에서 ㅡㅗ로 자동으로 넘어가는 것 등 그런 예가 더 많다.

한글 입력 방식의 고안자는 소결합 수준에서 기본 한글 자모를 입력하는 방법만 생각하면 된다. 이로부터 복합 자모를 입력하고 오류를 찾는 온갖 복잡한 노가다는 이제 컴퓨터 프로그램이 알아서 해 준다!

비록 한글 타자는 마치 알파벳 풀어쓰기처럼 sequential하게 이뤄지지만 한글은 구조적으로 ㄱㄱ과 ㄲ이 동일하지 않고 초성 ㄱ과 종성 ㄱ이 같지 않은 문자이다. 자체적으로 낱자 경계가 있고 음절 경계가 있는데 이것 구분을 한글 입력 오토마타가 implicit하게 자동 처리하게 된다. 이와 관련해서 생각할 수 있는 거의 모든 자동화 절차를 이 빠른설정이 담당해 준다.

작년에 본인이 부산 학회에 가서 발표한 논문(한글 및 한국어 정보 처리 학술대회)이 바로 이런 시스템의 구현에 관한 것이었다. 본인은 박사 졸업 이수요건 충족을 위해 중간에 이렇게 한글 자체에 지극히 특화된 연구를 해서 논문을 투고하고 발표하게 된 것에 자부심을 느낀다.

4. 옵션 대화상자

'복합 낱자 입력 로직 생성기'는 이례적으로 마치 설치 프로그램처럼 단계가 휙휙 진행되는 마법사 형태로 UI가 구현되었다. 1단계는 대결합을 지정하는 단계이며, 마지막 3단계는 지금까지 봐 온 결과 로그 화면이다.
운영체제가 제공하는 마법사 UI는 대화상자의 크기 조절을 지원하지 않기 때문에 마법사 UI를 불가피하게 자체 구현했다. 로그가 분량이 상당할 수도 있기 때문에 크기 조절 기능이 없으면 안 된다. 그리고 마법사 UI는 자체 구현하는 것도 그리 어려운 일은 아니니..

사용자 삽입 이미지

그리고 위의 그림은 바로 중간의 2단계인 옵션 지정 화면이다. 복합 낱자 입력 로직과 관련하여 이 옵션들을 생각해 내고 구현하는 게 지금까지 정말 머리 쥐어 뜯도록 힘든 일이었고, 개념을 도움말에다 설명하는 것도 어려웠다. 내가 누구만치만 머리가 빨리빨리 잘 돌아가기만 했어도..;; 단지 나보다 똑똑한 사람들은 이런 프로그램을 만들 생각 자체를 안 하겠지..

'글쇠배열 종류'를 두벌식이 아닌 세벌식으로 지정하면 음절 경계 체크라든가, ㅂㅉ, ㅂㅊ처럼 종성 연속 입력을 위한 임시 낱자 생성이 생략된다. 세벌식에서는 그런 걸 고려할 필요가 없으니까.

그리고 '옛한글 자모 사용' 옵션을 '끄면', ㄸㅃㅉ 같은 건 종성에 등장이 허용되지 않고 자동으로 다음 글자 초성으로 넘어간다. 이런 지저분 자질구레한 처리까지 가상 낱자와 한글 출력 치환을 이용해서 이 빠른설정이 알아서 다 세팅해 준다.
옛한글을 사용하더라도 정치· 치두음 같은 건 어차피 초성 전용이니 그런 게 종성에 등장하지 않게 처리된다.

'미리 분리' 옵션은 "(갇) ↔ (가ㄸ)" 왕복을 하느냐 "(갇) → 가(ㄸ) ↔ 가(ㄷ)" 왕복을 하느냐 차이를 결정한다. 이런 자음들을 그냥 다음 글자로 보내 버리면 종성에 생성되는 임시 낱자의 개수가 상당수 줄어든다. 세벌식에서는 초성 전용 자음을 처리할 때를 빼고는 이런 옵션이 필요하지 않다.

또한 세벌식에서는 아까 나랏글 중성 ㅜㅏ → ㅝ 단축처럼 종성도 ㄴㅇ까지만 입력하더라도 ㄶ으로 자동으로 단축이 가능하다. 단지 두벌식에서는 허용되지 않을 뿐이다. 진짜 받침 ㄴ + 초성 ㅇ을 의도한 것일 수도 있기 때문이다. 이런 세밀한 처리까지 다 고려해서 동작한다.

로직을 생성해 보니 결합 모호성이 존재하는데도 '모호성 해소 방식' 두 옵션 중 적어도 하나 이상이 선택돼 있지 않으면 일부 낱자는 모호성 때문에 입력할 수 없을 거라고 경고문이 끝에 나온다.
단, "짧은 소결합으로 연장 결합 지원" 옵션을 켜면 일부 낱자는 입력 가능해질 수도 있다. 아까 ㅠ에서 ㅝ로 자동으로 넘어가는 것처럼 말이다.

옵션들에 대한 더 자세한 설명은 대화상자에서 F1을 누르면 볼 수 있다.
8.8의 다음 버전은 올해 6월쯤에 나올 9.0 정도로 잡고 있다. 9.0에서는 이 빠른설정에 '허용 한글 범위' 제한 기능과 연계하는 새로운 기능이 더 추가될 예정이다.

* 마지막 썰: 프로그램 관련 문의는 둘 중 한 곳으로

'복합 낱자 입력 로직 생성기'는 이번 버전의 워낙 독보적인 끝판왕이다 보니 이거 하나만 간략하게만 소개했는데도 글 분량이 벌써 이만치가 됐다. -_-;;
기능 자랑은 이 정도로 하고, 이제 프로그램 관련 공익 광고(?)를 덧붙이며 글을 맺고자 한다.
본인은 여건상 개발자와 사용자 사이의 소통을 위해서 딱히 <날개셋> 한글 입력기 공식 게시판이나 카페 같은 걸 운영하고 있지는 않다. 프로그램 관련 문의는

  1. 공개적으로 하려면 프로그램의 다운로드 페이지에 있는 페이스북 플러그 인
  2. 비공개로 몰래 하려면 본인의 개인 메일(gmail)

둘 중 한 곳으로 하는 것을 가장 권장한다.

블로그에 올라오는 날개셋 한글 입력기 새 버전 공지글의 댓글로는 가능한 한 새 버전에 대한 의견만을 가장 권장한다. 하지만 이전 버전부터 보편적으로 있던 기능에 대한 문의가 올라오는 걸 명시적으로 금지할 것도 없기 때문에 받아들일 뿐이다.

다음으로 블로그 방명록이 있다. 여기도 프로그램 문의 게시판은 아니다. 그렇기 때문에 거기엔 내 블로그 방문 소감이나 안부 인사만 권하지 프로그램 문의는 원하지 않는다. 뭐, 문의글이라고 해서 무슨 스팸 광고글 쓰레기는 아니니, 게시판의 원래 성격에 맞지 않은 글이라고 해서 내가 매정하게 무시 또는 삭제한다거나 하지는 않는다. 답변을 하긴 하지만 그래도 원래 취지와 권고 사항은 저렇다는 거다.

페이스북 플러그 인을 열면서 동시에 내 페이스북 계정도 노출되었는데.. 요 몇 년 간 지켜보니 페이스북 쪽지로 프로그램 문의를 하는 분도 있었다. 하지만 쪽지로는 보내지 마시기 바란다.
페친이 아닌 모르는 사람이 보낸 쪽지는 페이스북이 알림창으로 안내를 하지 않기 때문이다. 그래서 쪽지가 왔다는 것을 내가 즉시 알아채기가 거의 불가능하다. 거의 몇 달 뒤에야 뒤늦게 발견해서 답변을 허겁지겁 했거나 아니면 그 사이에 질문자가 계정을 삭제하여 답변을 못 하게 된 일이 몇 번 있었다.

아무튼, 이 점을 염두에 두고 프로그램 관련 문의는 페이스북 플러그 인 또는 메일 중 한 곳을 이용해서 하셨으면 한다.

Posted by 사무엘

2017/02/15 08:28 2017/02/15 08:28
Response
No Trackback , 17 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1327

Trackback URL : http://moogi.new21.org/tc/trackback/1327

Comments List

  1. 김경록 2017/02/15 15:18 # M/D Reply Permalink

    ㅊㅋ 드립니다. 8.8이 드디어 나왔군여. 이제 크롬에서도 조금 더 편하게 사용할 수 있겠군여.
    잘 쓰고 있습니다. 2009년부터 9년째 쓰고 있네요 ㅎㄷㄷ

    1. 사무엘 2017/02/15 15:56 # M/D Permalink

      네, 유용하게 사용하시기 바랍니다. ^^
      이전 글에서 언급했듯이, "조합을 자체 처리하는 프로그램에서만 동작" 옵션을 켜 주면 크롬 브라우저에서 한글 조합 덧나는 문제도 같이 해결됩니다.

  2. qwerty 2017/02/16 22:24 # M/D Reply Permalink

    항상 감사드립니다

    1. 사무엘 2017/02/17 07:16 # M/D Permalink

      앗, 첫 근황글 올라오던 시절에 뵈었던 분이군요. 반갑고 고맙습니다. ^^
      새로운 기능들이 마음에 드셨으면 좋겠습니다.

  3. spartan10 2017/02/18 22:04 # M/D Reply Permalink

    우왕! 날개셋은 아직도 업뎃되고 있군요!! 컴터 파일정리 하면서 예전에 유용하게 사용했었던 아토(ietoy)가 보이길래 개발자님 블로그 가보려 했더니 폐쇄되고 없더라고요.. ㅠㅠ 용묵님 블로그에도 와봤더니 아직도 건재하시니 참 반갑습니다~^^ 항상 화이팅 입니다~~^^

  4. spartan10 2017/02/18 22:15 # M/D Reply Permalink

    저 근데.. 블로그 방명록이 어디에 있지요..?? 뭔가 글을 하나 남기고 싶은데~.~; 여튼 대단하십니다!! 전문가 클라스

    1. 사무엘 2017/02/19 02:33 # M/D Permalink

      네. ^^ 아직도 만들 아이템들은 계속 있는데 제 시간과 체력과 지능이 따라가지를 못해서요. ㅠㅠ 9.0, 그 뒤 9.2 정도.. 올해 중에 두 번 정도 더 기능 추가 버전업은 확실하게 계획돼 있습니다.

      그거 다음부터는 한동안 버그 수정 같은 마이너 유지만 될 듯합니다. 다른 이유 때문이 아니라 저도 학위논문 준비를 해야 돼서.. 그건 날개셋 말고 다른 거 연구한 걸로 쓸 거거든요. 하지만 입력기 연구로 학위논문 이전의 연구 실적과 졸업 이수요건은 채우고 있습니다.

  5. ntalds 2017/02/28 14:46 # M/D Reply Permalink

    인터넷에서 세벌식 관련 자료를 보던중 알게되어 설치했는데
    세벌식390 자판에서 /(ㅗ)자리의 "ㅗ" 입력이 안됩니다. 수정 부탁드립니다.
    세벌식390 자판의 ist파일 찾아서 설치 할까 했지만 구할 수가 없습니다.....

    1. 사무엘 2017/02/28 15:18 # M/D Permalink

      입력 설정을 고쳐 보세요.
      날개셋 제어판에서 해당 입력 항목의 '글쇠배열' 탭으로 가서 / 자리에 H3|O_ 라는 수식을 배당해 보세요. (해당 자리에서 space 누르거나 마우스 더블 클릭)
      혹은 '불러오기 ▼'에서 역삼각형 부분 버튼을 눌러서 '세벌식 390'을 가져와도 됩니다.

  6. ntalds 2017/03/02 10:17 # M/D Reply Permalink

    감사합니다.
    바로 알려주셔서 세벌식390을 복벌식으로 설정했습니다.
    세벌식은 ㅎ.ㄴ글 정품을 구입하면서 그 안에 있는 문서에 과학적인 글이라는 것을 보고 익히게 되었는데
    391은 복잡하고 익히기 어려웠고 390이 숫자 사용도 편해서 390으로 사용한지 30년이 되었는데 인터넷을
    하다 날개셋과 세벌식이 종류가 많다는 것을 알고 사용해 볼려고 했지만 손이 굳어서 그런지 390을 벗어
    나질 못하네요. 만약 바꾼다면 그래도 신세벌식M 이 접근하기 가장 쉬워 보입니다.
    좋은 프로그램을 만들어 주셔서 고맙습니다.

  7. jk 2017/03/19 00:41 # M/D Reply Permalink

    날개셋 8.8을 설치하니까 부팅할 때마다 0x271b37b2에 있는 명령이 0x00000004의 메모리를 참조했습니다. 메모리는 read될 수 없었습니다. 라면서 explorer.exe가 자꾸 죽네요. 날개셋을 지우니까 증상이 사라지긴 했는데 8.8 이전 버전 구할수 없을까요?

    1. 사무엘 2017/03/19 13:14 # M/D Permalink

      설마 그런 문제가 있는가 했는데, 운영체제 기본 IME로 지정 후 부팅 실험을 몇 번 해 보니 동일 문제가 재연되네요. 단, 8.8에서 바뀐 부분 때문에 발생하는 문제는 아닌 듯하고 좀 특수한 경우에서만 발생하는 것이어서 추가적인 재연 조건 확인이 필요한 상태입니다.

      일단 불편을 끼쳐서 죄송합니다. 다만, 저도 이전 버전을 모두 보존해 두지는 않기 때문에 직전 버전에 대한 다운그레이드 지원은 공식적으로 제공되지 않습니다. 가까운 시일에 0.0x대 새 버전을 내놓는 쪽으로 하겠습니다.

    2. 사무엘 2017/03/20 13:57 # M/D Permalink

      explorer가 죽는 건 일반적인 상황에서는 나타나지 않는 것 같고, 아마 프로그램이 8.6에서 8.8로 업데이트가 제대로 되었는지 궁금합니다.
      외부(IME) 모듈 자체와 날개셋 커널의 버전이 달라서 커널이 로딩되지 못한 상태에서 날개셋이 기본 IME로 지정된 채로 부팅이 되면 그런 현상이 나타나더군요.

      그러니 일차적으로는 운영체제 기본 IME를 딴 걸로 바꾸고 나서 날개셋 구버전을 제거하고, 로그오프나 재부팅까지 한번 한 뒤에 8.8을 clean 설치하시면 이런 현상이 없을 것 같습니다.
      물론 이상 상황에서도 특정 프로세스가 뻗는 일은 없어야 하므로 그건 제 프로그램 쪽에서 해결해야 할 버그입니다.
      일단 이렇게 문제가 해결 가능한지 확인 부탁드립니다.

  8. ntalds 2017/03/21 16:50 # M/D Reply Permalink

    좋은 프로그램 잘 사용하고 있습니다.
    세벌식 390을 사용하다 요즘 신세벌식으로 연습하던중 복모음 타이핑이 390과 달라서 왼손이 부담이 크고 장시간 타이핑하면 아프기 까지...... 바꿔야하나 고민중에 안마태 세벌식을 알게되어 사용해 볼려고 했지만 날개셋에서 설정파일을 구할수가 없어서 요청드립니다.

    날개셋에서 안마태세벌식 설정파일 ntalds@daum.net로 부탁드립니다.

    1. 사무엘 2017/03/22 04:39 # M/D Permalink

      안녕하세요?
      제가 4년 전에 했던 답변과 동일한 답변을 드리게 되겠네요.
      http://moogi.new21.org/tc/817 (이수동 님의 댓글에 대한 답변)
      안마태 글자판에 대해서는 따로 사업을 하려는 분과 계약을 맺고 그쪽으로 솔루션을 납품했기 때문에 제 프로그램에서 더 정식으로 지원을 하지 않습니다. 단, 4년이 지난 지금은 거기서 키보드 판매나 프로그램 보급이 원활히 진행되지 않고 있는 것 같습니다.

      또한 그런 계약이나 저작권 문제가 없는 임의의 입력 방식인 경우,
      제가 개인적으로 필요나 흥미를 느껴서 먼저 제작하는 것이 아니라 그냥 타인으로부터 의뢰를 받아서 개인적인 용도로만 제공하는 것이라면 유료 제작이 원칙이라는 것도 덤으로 말씀드립니다. http://moogi.new21.org/tc/921
      감사합니다.

  9. jk 2017/03/21 23:30 # M/D Reply Permalink

    날개셋 지우고 재부팅하고 8.8 깔고 재부팅하고 제어판에서 기본 IME를 날개셋으로 바꾸고 확인을 누르는 순간 같은 증상이 반복되네요. 다행히 예전에 받아둔 8.4를 찾아서 쓰고 있는데 이건 재부팅 안하고 바로 바꿔도 이상 없고요. 8.6은 써본적이 없어서 모르겠네요.

    1. 사무엘 2017/03/22 04:40 # M/D Permalink

      앞서 말씀드렸듯이 저도 explorer가 죽는 현상 자체는 확인했지만 발생· 재연 조건이 jk 님과는 다르며, 또 문제를 발견하고 해결한 곳이 굳이 8.4와 현 버전이 차이가 있다고 보기 어려운 부분이어서 님께서 말씀하시는 바로 그 문제가 해결됐다고 볼 수 있을지는 모르겠습니다.

      - 사용하시는 운영체제가 정확하게 무엇인가요? (10의 경우 "Windows 정보" 대화상자에 뜨는 버전 번호 빌드 번호를 모두 알려 주세요. 세부 버전별로 기술적인 편차가 굉장히 큰 편입니다.)
      - 혹시 디버그 코드가 추가된 8.8 버전을 개인적으로 받으셔서 문제가 해결됐는지, 아니면 여전히 죽는 문제가 있을 경우 생성된 메모리 덤프 파일을 제게 보내 주실 수 있겠습니까? (구체적인 방법은 물론 추후 모두 안내해 드림) 이메일 주소를 여기서 알려 주시거나 제게 메일을 보내 주십시오.

Leave a comment
« Previous : 1 : 2 : 3 : 4 : 5 : ... 11 : Next »

블로그 이미지

철도를 명절 때에나 떠오르는 4대 교통수단 중 하나로만 아는 것은, 예수님을 사대성인· 성인군자 중 하나로만 아는 것과 같다.

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2017/10   »
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:
863122
Today:
226
Yesterday:
535