날개셋 한글 입력기 6.3

추석 연휴가 끝나자마자 <날개셋> 한글 입력기의 따끈한 새 버전 소식이 기다리고 있다. (만세 ㄲㄲ)
본인의 사정으로 인해, 6.2가 나온 지 한 달이 채 되지 않아 6.21도 아니고 이례적으로 6.3이 나오게 됐다. 원래는 10월쯤에 내놓으려고 했는데.

그 대신 이게 올해의 마지막 버전업이 되지 싶다.
이번 학기를 마친 뒤엔 드디어 종합 시험(논자시;;)을 봐야 하고, 또 이번에 듣는 과목은 지난 학기의 과목과는 달리, 국어학 배경이 빈약한 본인에게는 만만찮은 것들이다.
그래서 프로그램 개발부터 좀 마무리를 짓고 나서 그런 일들에 전념하고자 한다.

6.3은 +0.1 이상에 해당하는 기능 추가와 개선이 충분히 이뤄졌다.
외부 모듈이 TSF 환경에서 옛한글 같은 2글자 이상의 조합을 표현할 때 조합이 끊어지던 문제를 완전히 해결했고,
한글 표현 체계와 에디팅 엔진이 크게 바뀌었던 직전 버전에만 자잘하게 존재하던 여러 버그들도 잡았다. 편집기의 경우 화면 잔상이 남던 것부터 시작해 심하면 프로그램이 죽던 문제까지도 있었다. 더 구체적인 내역은 모방 범죄 예방을 위해 알리지 않겠다. ㄲㄲ

정 재민 님께서 보내 주신 글꼴 데이터를 반영하였으며, 유용한 텍스트 필터도 세 종류나 추가했다.
- 호환용 영역의 한자를 본디 형태로 바꾸는 필터 (정 재민 님 제안)
- 본문 중의 수식을 계산하고 숫자의 경우 진법을 싹 바꿔 주는 필터
- 패턴 치환 필터. 이건 프로그램 설치해서 도움말을 읽어 보기 바란다. 일괄 치환과 더불어 아주 유용한 기능으로, 이걸 쓰면 칼럼 단위의 데이터를 다루기 위해 엑셀 같은 별도의 프로그램을 쓸 일이 크게 줄어든다. <날개셋> 편집기는 키매크로나 칼럼 블록 기능을 제공하지 않지만, 대체 기능을 텍스트 필터의 형태로 꾸준히 제공하고 있다.

그리고 뭐니뭐니해도 6.3 버전의 가장 큰 특징은 Bksp 키를 다루는 체계를 싹 바꿨다는 점.
<날개셋> 한글 입력기는 1.0 시절부터 Bksp에 여타 한글 입력기에서는 찾을 수 없는 특수한 기능들을 제공해 왔다. 즉,

- Bksp와 Shift+Bksp의 용도를 구분하고,
- 조합 여부와 상관없이 한글을 낱자나 글자 단위 중 원하는 형태로 얼마든지 지울 수 있다.
- 그리고 한글이든 비한글이든 지금 글자가 다 지워진 후 그 앞에 또 한글이 있으면 그 한글에 달라붙어서 조합 상태가 재연된다. 앞 글자도 seamless하게 계속 낱자 단위로 지우거나 고치거나 빠진 낱자의 추가 입력이 가능하다.
- 게다가 이걸로도 모자라서, 두벌식 글자판의 경우 도깨비불 현상까지 고려해서 이전 상태를 복원해 준다. 일명 역도깨비불인데,

안해 → 않 (≠ 안해 → 안ㅎ → 안)
보끼 → 볶 (≠ 보ㄲ → 보ㄱ)

같은 동작도 지원된다는 뜻이다.

그리고 그 후 10여 년 뒤, 6.3 버전에서는, <날개셋> 한글 입력기의 간판 기능으로 손색이 없는 이 기능을 지정하는 방식이, 예전보다 훨씬 더 깔끔하고 체계적이고 전문적으로 바뀌었다.

사용자 삽입 이미지

스크린샷을 보면, 예전에 Bksp 동작 방식에 있던 서너 개의 체크 옵션이, 자주 쓰는 predefined configuration을 바로 가져오는 콤보 상자로 대체되었음을 알 수 있다. 자세한 설정은 말 그대로 '자세히' 버튼을 눌러서 나타나는 별도의 대화상자에서 해야 한다.

스크린샷에서 알 수 있듯, Bksp와 Bksp, 그리고 한글을 조합 중일 때와 그렇지 않을 때, 각 상황별로 한글을 무슨 순서대로 지울 것이며 이 글자가 다 지워졌을 때 앞의 한글에 달라붙을지를 일일이 사용자가 설정할 수 있다. 예전 버전에서는 기능 자체만 제공되었지 이 정도로 세밀한 설정은 가능하지 않았다.

또한 두벌식 역도깨비불 재현도 별도의 옵션으로 바뀌었다. 따라서 두벌식 자판을 쓴다고 하더라도 그냥 달라붙기 기능만 쓰지, 역도깨비불까지 원하지는 않는 사용자라면 해당 옵션을 끄면 된다. 이런 취사선택도 예전 버전에서는 가능하지 않았다.

과거의 3.0부터는 자그마한 옵션이 하나 추가되었는데, 입력 순서와 상관없이 하위 낱자부터 한 타씩 지우는 옵션이 그것이다.
ㅇ+ㅜ+ㅣ+ㄴ 순으로 입력했든 ㅇ+ㅜ+ㄴ+ㅣ 내지 ㅜ+ㅇ+ㅣ+ㄴ 순으로 입력했든, '윈'은 무조건 종성부터 역순으로 지워서 위-우-ㅇ이 되게 하는 기능인데, 이것이 바로 위의 스크린샷에서는 '최하위 낱자의 직전 한 타'이다. 이런 차이는, 당연한 말이지만 동일한 글자를 여러 가지 순서로 입력할 수 있는 모아치기가 가능한 세벌식 체계에서만 의미가 있다.

그에 덧붙여 이 새 버전에서는 '최하위 낱자 전체'라는 옵션도 추가됐다. 말 그대로 낱자 단위로 한꺼번에 지워 버리는 옵션으로, 아무리 복잡한 한글이라도 초· 중· 종성이 모두 갖춰져 있다면 세 타 만에 다 지워진다. '윈'을 지울 때 '위' 다음에 '우'를 안 거치고 바로 'ㅇ'이 된다는 뜻. 사실, PC용이 아닌 휴대전화용 한글 입력기의 Backspace는 다들 이런 방식으로 구현되어 있다.
여담이지만, 내부적인 구현 오버헤드는 최하위 낱자를 따지는 방식이, 고전적인 '직전에 입력된 한 타'보다 더 크다.

이쪽 기능을 대대적으로 손을 좀 봐야겠다고 거의 6.0 개발 초창기 시절부터 생각은 하고 있었는데 드디어 해내게 되어 무척 기쁘다. 진작부터 지원돼야 했을 기능들이다.
물론, 주변 글자를 자유자재로 다룰 수 없고 write-only만 가능한 TSF B급 이하 환경에서는 '달라붙음' 같은 기능은 전혀 쓸 수 없고, '조합 상태가 아닌 한글을 지우는 단위' 역시 오로지 글자 전체 단위로 제약을 받게 된다.

기능을 구현하는 과정에서 <날개셋> 한글 입력기의 내부 구조도 제법 바뀌었다. 하지만 더 합리적으로 바뀌었다. 그 내막을 살펴보면 이렇다.

지난 3.0 버전 이래로 Bksp 키는 입력 스키마가 '낱자 단위 지우기' 아니면 '글자 단위 지우기'라는 특수글쇠를 생성하는 형태로 내부적으로 처리되었다. 그리고 전자와 후자를 Bksp와 Shift+Bksp에다 각각 대응시킬지, 아니면 반대로 Shift+Bksp와 Bksp에다 대응시킬지를 '입력 스키마'의 옵션으로 지정 가능했다. 그게 끝이었다.

그러나 이제부터는 입력 스키마는 Bksp일 때 Bksp1, 그리고 Shift+Bksp일 때 Bksp2라고 언제나 고정적인 특수글쇠만을 생성한다. 이런 특수글쇠는 1부터 4까지 현재 네 종류가 예약되어 있는데, 이들 자체에는 어떤 특정 동작 방식이 규정되어 있지는 않다. 각 특수글쇠의 해석은 전적으로 그 아래의 '문자 생성기'만이 담당하게 된다. 그것이 바로 저 'Bksp 동작 방식' 옵션인 것이다.

그리고 그 추상적인 Bksp와는 별개로, 특정 방식대로 한글 낱자를 지워 주는 특수글쇠가 또 존재한다. 즉, 진짜배기 Bksp는 입력기의 옵션이 어떻게 지정됐냐에 따라서 낱자/글자 단위로 지우고 필요하다면 달라붙기나 역도깨비불까지 제공하는 반면, 그냥 낱자 단위, 입력 역순, 글자 전체(위의 스크린샷에 있는 네 옵션 중 하나) 삭제라는 고정불변 단편적인 Bksp 기능도 임의의 글쇠에다가 특수글쇠의 형태로 배당해서 쓸 수 있다는 뜻이다.

아시는 분이 있으려나 모르겠는데, <날개셋> 한글 입력기에는 0x10과 0x11에 '뒷글자 삭제'라고 해서 Del과 유사한 기능을 하는 특수글쇠가 이미 있다. 그것처럼 Bksp와 유사한 기능을 하는 네 가지 특수글쇠도 일관성 차원에서 추가된다고 이해하면 정확하다.

이들 특수글쇠는, 편집 환경만 지원된다면(TSF A급 같은), 이미 완성된 한글도 물론 낱자 단위로 자기 방식대로 지울 수 있다. 하지만 그런 이상적인 환경이 아니라면, 이미 완성된 글자는 건드리지 못한다. 사실 Bksp 키 자체가, 한글 입력기가 조종하는 것과 에디터 응용 프로그램이 조종하는 것이 공존하는 체계이다. 완성된 글자는 한글 입력기가 아니라 응용 프로그램이 지워 주며, 응용 프로그램은 일반적으로 '진짜' Bksp 키가 들어왔을 때만 그런 동작을 하기 때문이다.

이런 식으로 시스템 개편을 했는데, 솔직히 내가 생각했지만 내가 봐도 너무 멋있다..;; 이 맛에 프로그래밍 하는 거다.
이것저것 생각해 놓은 게 많아서 당분간은 새 버전의 Readme엔 '※ 한글 입력 체계' 카테고리가 쭉 있을 것으로 보인다. 한글 입력기 본분에 충실한 기능이 계속 강화되고 개선되고 있기 때문이다.

6.3 버전은 6.2와 API가 완전히 호환된다.
다음 버전은 내년 초에 6.5 정도가 목표이다. 버그 없이 프로그램을 잘 만들어서 가능하면 0.0x대로 내려가지는 말고 버전을 쑥쑥 크게 올려야겠다.

Posted by 사무엘

2011/09/14 08:29 2011/09/14 08:29
Response
No Trackback , 9 Comments
RSS :
http://moogi.new21.org/tc/rss/response/569

1.

이 블로그는 좀 특이한 구석이 있다.
보통, 덕력이 좀 높은 블로거는 전문 분야 블로그와 일상 잡담 블로그를 분리해서 운영한다.
하지만 본인은 그렇게 하지 않으며 모든 관심 분야에 대한 글을 한 블로그에다 몰아서 올린다.
블로그를 따로 운영해야 할 정도로 덕력이 아주 높은 것도 아니어서 말이다..... 어? ㄲㄲㄲㄲ

난 사람들이 자기 관심 분야 블로그에만 가는 걸 원하지 않는다.
내 근황이 궁금하고 나에 대해 알고 싶어서 내 블로그에 온 사람이라면, 좋든 싫든 프로그래밍 관련 글도 보고, 철-_-도 관련 글도 보고, 한글 관련 글, 기독교 관련 글도 보길 원한다.
독자 여러분은 어떻게 생각하실지 모르겠지만 어쨌든 본인은 내 식대로 이런 식으로 블로그를 운영해 나갈 것이다. ㅋㅋ
<날개셋> 한글 입력기 카테고리가 몇 달째 글이 없으니 오늘은 또 오랜만에 개발 근황을 전하도록 하겠다.

2.

<날개셋> 한글 입력기의 다음 버전은 6.2로 확정했다. 나흘 뒤인 8월 21일 아침에 나올 예정이다. 현재 코딩은 거의 마쳤고 테스트와 도움말 작성 중이다.
편집기를 안 쓰는 분에게는 그리 큰 해당 사항이 없겠지만, 6.2에 대해서는 지금까지 오랜 숙원이었던 에디팅 엔진의 최적화 소식부터 먼저 전해야겠다.
무려 7년 전, 3.0 시절 이래로 변함없이 남아 있던 에디팅 엔진을 뒤집어엎었다. 옛날 코드의 로직을 재구성하여 더 정교하게 다시 만드는 게 쉬운 일이 아니었다.

예전 버전이 얼마나 비효율적이었는지를 단적으로 설명하자면 이렇다.
수십만 줄에 달하는 텍스트를 불러와서 맨 앞줄에서 엔터를 눌러서 줄을 삽입하거나 텍스트를 붙여넣으면 그 줄부터 문서 끝까지 내부적으로는 행번호가 다 renumbering된다. -_-;;
그리고 undo 한번 할 때마다 그 텍스트 레이아웃이 전부 다시 짜진다.

이제는 아무리 큰 문서를 불러와도 텍스트 레이아웃과 재배치는 영향을 받은 문단에서만 일어나며, renumbering도 없어졌다. Ctrl+Z를 마음껏 눌러도 된다.
다른 작업 우선순위에 밀리고 또 밀려서 7년 동안 못 하고 있던 일을 이제야 해냈다.
3.0을 만들던 당시는 세벌식 모아치기와 새로운 한글 입력 오토마타에 치중하느라, 에디팅 엔진은 비록 구닥다리 2.x에 비해서야 혁신이었지만 그래도 시간 관계상 대충 발로 짠 부분이 있었던 것이다.

이번 버전은 파일 저장도 매 줄마다 디스크에 쓰는 게 아니라, 수 MB 단위로 버퍼에다 미리 저장한 후 한꺼번에 디스크에 쓰게 함으로써 속도를 크게 향상시켰다. 이렇게 하는 게 이 정도로 큰 차이를 만들 줄은 몰랐다.
<날개셋> 변환기의 파일 변환 속도도 훨씬 더 빨라졌다.
학교에서 실제로 수~수십 MB에 달하는 옛한글 말뭉치 파일을 다뤄 보고서야 성능을 개선할 필요를 느꼈다.

3.

그리고 <날개셋> 편집기는 이제 legacy format(한컴 2바이트 코드 및 한양 PUA)으로 클립보드를 읽고 쓰는 기능이 없어지고, 편집 메뉴에 '선택하여 붙여넣기'(Paste special) 기능도 없어진다. Paste special은 무려 <날개셋> 한글 입력기 2.0때부터 있었던 기능이지만, 이 프로그램이 텍스트에다 서식을 넣을 수 있는 워드 프로세서도 아니고 사실 필요 없는 기능이다. 유니코드 하나만 신경 쓰면 되니까 말이다.

그 대신 이 기능들은 <날개셋> 변환기로 이동한다. 다만, 지금까지 한컴 2바이트 코드를 읽는 것 말고 '쓰는' 기능은 제2수준 한자를 지원하지 않았었는데, '쓰는' 것도 가능해진다. 클립보드 변환 기능까지 그대로 지원되긴 하지만, 아래아한글 97이나 <날개셋> 무려 2.x와 텍스트 데이터를 변환하는 상황이 아니라면 이제 쓸 일은 없을 것이다. 그러니 호환성 유틸리티인 변환기로 기능 이전.
하지만 유니코드가 등장하기 전에 아래아한글이 국어 정보 처리에 끼친 영향력을 감안하면, 한컴 2바이트 코드 지원을 완전히 없애 버릴 수는 없다.;;

또한, 옛한글을 한양 PUA <-> 유니코드 5.2 형식으로 변환하는 기능은 '텍스트 필터'로도 들어가서 편집기나 외부 모듈이 즉석에서 사용 가능하게 된다. 한양 PUA의 인지도는 아직까지도 무시할 수 없기 때문에..;;
이걸 감안하면, 비록 편집기의 한양 PUA 지원 기능은 겉으로는 일관성 차원에서 사라지지만, 동일 기능이 더 유용한 다른 형태로 대체되는 셈이다.

덤으로, <날개셋> 변환기는 옛한글 변환은 지금까지 UTF16 방식의 파일밖에 지원하지 않았다가 이제 드디어 UTF8도 지원할 예정이다. 그리고 명령줄에서는 하위 디렉터리의 모든 파일을 재귀적으로 찾아서 변환하는 /S 옵션이 추가된다.

4.

이렇듯, <날개셋> 한글 입력기의 다음 버전은 편집기와 변환기가 바뀐 게 많고 외부 모듈은 변화 사항이 상대적으로 적다고 볼 수 있다. 그래도 외부 모듈이 바뀐 걸 나열하자면,

첫째, 한글 글자판을 찾을 때 무조건 맨 위의 0번부터 그 아래가 아니라, 6.0에서 추가된 개념인 '기본 입력 항목'부터 먼저 고려하기 시작했다. (진작에 이렇게 했어야지..)
둘째, 편집기와 외부 모듈을 같이 쓰는 경우, 편집기에서 프로그램의 UI 언어를 바꾸면 외부 모듈도 아쉬운 대로 그걸 따라가게 했다.

이 외에, 프로그램 전반적으로는
수식에서 ? : 연산자와 콤마 연산자가 변수를 되돌리면 거기에 바로 대입이 가능하게 문법이 확장되었으며,
정 재민 님의 제안과 도움 덕분에 몇몇 글꼴들이 최신 유니코드 규격대로 업데이트되었다.
그리고 천지인· 나랏글과 더불어 스마트폰의 3대 복수 표준 입력 방식 중 하나가 된 팬텍 SKY 방식도 예제 입력 설정 파일을 만들어서 추가했다.

텍스트 필터 중에 '일괄 치환 필터'라고, 여러 건의 바꾸기 작업을 한꺼번에 수행하고 심지어 줄바꿈 문자까지 찾기-바꾸기 문자열에 포함할 수 있는 강력한 필터가 있는데,
여기에 있던 사소한 버그를 잡고, 이 필터에 '반복 적용' 옵션을 추가했다.
이걸 잘 활용하면 [   a   ], [ b  ] 같은 문자열도 싹 다 [a], [b] 같은 식으로 일괄적으로 공백 정리를 할 수도 있다. 이런 기능을 넣을 생각을 지금까지 왜 안 했는지 모르겠다.
적은 노력에 비해서 무척 유용할 수 있는 기능을 찾아내서 구현하는 건 참 즐거운 일이다.

끝으로, 타자연습은,
문장 연습 중에 오타를 내고서 Ctrl+Z를 눌렀을 때, 텍스트가 없어진 뒤에도 텍스트 위의 오타 마크가 사라지지 않던 버그를 잡았다.
그리고 게임은 이제 레벨이 올라갔을 때 자동 저장을 해 주지 않는다. 게임 중에 사용자가 단축키를 눌렀을 때만 해당 단계의 점수, 방어력, 주인공으로 나중에 게임을 이어서 할 수 있게 그 상태가 저장된다. 따라서 해당 단계의 초반에 저장을 하든, 끝날 때가 다 돼서 저장을 하든 그건 상관없다.

<날개셋> 타자연습의 게임 저장 체계는 어찌 보면 페르시아의 왕자 1의 그것과 비슷해졌다고 볼 수 있다.
(레벨의 첫 시작 시점만 저장할 수 있고, 한 시점만 저장 가능하다는 점에서)

5.
끝으로 여담,
<날개셋> 편집기처럼 텍스트 에디터를 처음부터 새로 만든다는 건 결코 쉬운 일이 아니다.
특히 유니코드의 complex script를 완벽하게 지원하려면 이미 거의 워드 프로세서 수준에 도달한다. 커서 이동, 마우스 포인터 위치로부터 문자열 위치 판단, 문단 정렬 같은 기본 중의 기본 작업들조차 완전 어려운 작업이 되기 때문이다. 내 프로그램은 그런 자질구레한 건 개발의 주목적이 아니기 때문에 죄다 깔끔하게 무시하고 개발되는데도 이 작업만으로도 코드의 양이 만만찮다.

WinAPI.co.kr의 운영자로 유명한 김 상형 님은 이런 텍스트 에디터를 개발하는 튜토리얼을 제공하고 있으니 초보 개발자들에게 무척 유익하다. 요즘 세상에 저 정도 프로젝트를 대인배스럽게 공개하는 분은 정말 드문데... 관심 있으신 분은 참고하기 바란다.

<날개셋> 입력기와 타자연습의 다음 버전도 어김없이 예전 버전과의 API 호환성은 깨질 예정이다. =_=;;; 따라서 둘을 원활히 같이 쓰려면 둘을 모두 업데이트해야 한다.
이제는 좀 바꿀 일이 없겠지 싶은 요소들도 계속 바뀐다. 그만큼 <날개셋> 한글 입력기는 여전히 활발하게 개발이 진행 중이고 살아 있는 프로젝트라는 뜻이기도 하다.

당초 계획했던 한자 관련 기능을 추가 못 하고, 입력기 커널에 내가 원하는 기능을 여건상 못 넣었는데, 이건 올해 하반기에 나올 또 다음 버전에서 기약을 해야겠다.

Posted by 사무엘

2011/08/17 08:11 2011/08/17 08:11
,
Response
No Trackback , 11 Comments
RSS :
http://moogi.new21.org/tc/rss/response/556

C/C++에는 ? : 라는 독특한 연산자가 있다. A ? B: C꼴로 표현되어 피연산자가 3개나 붙는 유일한 연산자이다.
이 연산자의 역할은 매우 단순하다. A가 참이면 연산자의 값은 B가 되고, 그렇지 않으면 C가 된다. 그래서 아예 if문의 역할을 간단히 대신할 수도 있으며, 콤마 연산자와 결합하면 어지간한 함수 호출마저도 한 연산식에다 박아 넣을 수 있다. 다만, 그게 너무 사악하다고 여겨졌는지-_-, C# 언어에는 콤마 연산자가 사라지고 콤마는 for 키워드 안에서만 제한적으로나 허용되지 싶다.

? : 는 &&, || 와 마찬가지로 C/C++에서 단축연산이 적용된다. A && B에서 A가 거짓이면 B는 실행이 전혀 되지 않고 전체 결과가 거짓이 되며, A || B에서 A가 참이면 B는 실행되지 않고 바로 전체 결과가 참이 된다. 그런 것처럼 ? :는 선택되지 않은 항에 대해서는 당연히 연산이 일어나지 않는다.

<날개셋> 한글 입력기는 짝퉁 C언어 문법 수식 해석기를 내장하고 있기 때문에, 이를 이용해 글쇠, 오토마타, 글자판 전환 글쇠 등에서 문자 입력 시스템의 자유도를 굉장히 높일 수 있다. 비록 튜링 완전한 수준은 못 돼도 말이다. 이때에도 ? : 연산자는 물론 매우 요긴하게 쓰인다.

? : 는 좌결합이 아니라 우결합이다. A ? B : C ? D : E는 (A?B:C) ? D : E가 아니라 A ? B : (C?D:E)로 결합한다. 그러므로 전자처럼 쓰려면 괄호를 넣어 줘야 한다.

? : 는 다른 연산 구문들을 포함하는 if문 대용처럼 쓰이는 만큼, 연산자의 우선순위가 상당히 낮다. 다른 평범한 연산자들이 다 결합한 뒤 나중에야 적용된다. 그게 합리적이다.
그러나 얘도 콤마와 대입 연산자보다는 순위가 높다. 그렇기 때문에 A = B ? C : D 라고 써 주면 알아서 A = (B?C:D)로 해석되어, A에는 B 조건의 충족 여부에 따라 C 아니면 D가 대입된다.

반대로, ? : 의 내부에 콤마 연산이나 대입 연산이 포함되어야 한다면 이들 연산은 무조건 괄호로 싸야 한다.

A ? (B=2): (C=5)
B에다가 괄호를 안 하면 = 가 ?와 :를 둘로 쪼개 버리는 효과가 나기 때문에 에러가 발생한다.
그리고 C에다가도 괄호를 생략할 수 없는데, 괄호를 안 하면 연산의 의미가 (A?(B=2):C)=5가 되어 버리기 때문이다. 우선순위의 특성상, =가 C항이 아니라 ? = 전체와 대응한다는 뜻 되겠다.

그리고 또 생각해 볼 것은, ? : 연산자의 값은 L-value가 될 수 있겠냐는 점이다. (대입 가능하겠냐)
<날개셋> 한글 입력기는 수식이 처음 도입된 3.0 이래로 지금까지 (조건 ? A:B)=100 과 같은 구문이 지원된 적은 없다. 그러나 이제 <날개셋> 6.0 이후의 다음 버전부터는 그게 가능해진다. 단, 2항과 3항 중 하나라도 변수에 연산자가 조금이라도 붙어서 A+2, -B 같은 형태가 되면 L-value 원칙이 깨지게 되는데, 그런 오류는 수식 입력 시점에서 프로그램이 자동으로 감지해 준다.

이게 지원되면 조건 ? (A=100): (B=100)보다야 구문을 더욱 간단하게 만들 수 있으니까 사용자의 입장에서 좋을 것이다. 더구나 콤마 연산자도 최후의 항의 변수 정보를 남겨 주기 때문에 (조건 ? (A=100,C): (B=50,D)) +=20 같은 복잡한 대입도 가능해진다. 저 식의 의미는 무엇일지 독자 여러분이 생각해 보기 바란다.

정작 이 연산자에서는 괄호가 필요하지 않다. 조건 ? A:B=100 이라고 하면 (조건 ? A:B)=100이 되며, 100 대입 연산은 3항의 B에만 연결되는 게 아니라 ? : 연산의 결과 전체에 걸린다. ? : 의 우선순위가 =보다 높기 때문에 =보다 먼저 계산되기 때문이다.

<날개셋> 한글 입력기로 복잡한 수식을 다뤄 본 분들은 이미 아시겠지만, 이 프로그램은 사용자가 입력한 수식을 어느 정도 자동으로 간소화를 한다. 상수 연산은 미리 계산을 해 버리며, 100/0나 2=A 같은 뻔한 에러는 미리 지적해 준다. 그리고 우선순위 규정상 굳이 칠 필요가 없는 괄호도 알아서 제거를 해 버린다.

(A+B)-C는 A+B-C로 바뀌며, 이와 비슷한 맥락으로 (조건 ? A:B)=100도 그냥 조건 ? A:B=100으로 바꾼다. 이건 프로그램의 오동작이 아니므로 놀라지 말고 수식을 사용하면 된다.

그런데 비주얼 C++ 같은 요즘의 C/C++ 컴파일러들은 ? :를 본인이 생각한 것처럼 취급하지 않는 것 같다.
A==100 ?B:C=400 라고 하면 =400은 3항의 C에만 붙지 B에는 붙지 않는다. (A==100 ? B:C)=400이라고 해 줘야 한다.
또한 ?와 : 사이에 있는 2항은 사이에 대입이나 콤마 같은 연산자(우선순위가 ? :보다 한참 더 낮은!)가 괄호 없이 연결되어 있어도 알아서 2항의 일부라고 인식해 주는 듯.
물론, 그렇다고 해서 A=조건 ? 2항: 3항 같은 문장이 있으면 A=까지 조건으로 끌어들이지는 않는다.

이런 세세한 동작 방식에 대해서 정보를 얻고 싶어서 비주얼 C++ 도움말을 찾아봐도, ? :는 대입 연산자보다 우선순위가 높다던가, 2항과 3항의 타입이 서로 다를 때 연산자 값이 정해지는 원칙 같은 원론적인 말밖에 없다. 그 말대로라면 무조건 내 프로그램처럼 괄호를 써야만 할 텐데 말이다.

그 간단한 ? : 연산자에도 의외로 복잡한 사연이 있다는 걸 알 수 있다.
어쨌든 내 프로그램은 ? : 안에 대입이나 콤마 연산을 포함시키려면 무조건 괄호를 써야만 하는 구조가 앞으로도 유지될 것이다.

Posted by 사무엘

2011/06/05 19:20 2011/06/05 19:20
, ,
Response
No Trackback , 4 Comments
RSS :
http://moogi.new21.org/tc/rss/response/521

날개셋 한글 입력기 6.0

※ 드디어 6.0 시대

5.8 이후 거의 5개월에 가까운 기간 동안 <날개셋> 한글 입력기가 발전한 결과물을 드디어 이렇게 선보이게 되어 대단히 기쁩니다. 무려 6.0!! 5.x에서 6.0이라는 이름이 전혀 아깝지 않을만치 변했습니다. 5.8 이후 소스 커밋은 약 60여 회(change set 개수)가 있었군요. 9개 모듈과 공용 라이브러리의 소스 코드 총합은 현재 약 6만 1천 줄.

초· 종성 공유 낱자 결합 규칙이 추가된 덕분에, 프로그램의 핵심이라 할 수 있는 한글 입력 오토마타 부분이 오랜만에 크게 바뀌었습니다. 아직 100% 완전체가 구현된 건 아니지만 이걸 쓰면 복잡한 두벌식 한글 입력 방식을 구현하는 게 눈물나게 수월해집니다. 그 구체적인 메카니즘은 도움말에 자세히 설명되어 있습니다. 진작부터 추가되어야 했을 기능인데 이제야 도입됐고요.

조합 자동 종료 타이머는 제어판에서 ‘입력 일반’ 항목에 수식의 형태로 깔~끔하게 추가됐습니다. 예제로 제공되는 삼성 천지인 입력 방식이 당장 이걸 사용합니다. A==3 ? 1000: 0 즉, 오토마타 상태가 3번(종성 입력)일 때 1초간 제한을 둬서 사용자가 다음 타를 입력하지 않으면 음절을 끊게 됩니다. 그냥 1000이라고만 입력하면 모든 조합 상태에서 1초 제한이 걸리겠죠.
한글 입력 상태는 A, 그리고 <날개셋> 고급 입력기의 사용자 조합 상태 번호는 B이므로 이들 변수에 대한 수식을 자유롭게 지정할 수 있습니다.

현재 사용할 입력 항목과, 프로그램이 시작될 때 처음으로 지정할 입력 항목을 따로 지정할 수 있게 되고, 입력 항목의 배열 순서를 숫자 직접 입력 및 up-down 컨트롤로 손쉽게 바꿀 수 있게 된 것도 개인적으로는 정말 멋진 변화 사항이라 생각합니다. 제어판 화면을 직접 보시면 압니다.

이 외에도 바뀐 것 많습니다.
외부 모듈의 안정성 관련 이슈는 MS IME의 소스를 직접 참고하지 않는 한 앞으로 6.x 시대에도 계속 나올 것 같고..

※ 타자연습

타자연습은 명목상으로는 바뀐 API 구조대로 프로그램을 재컴파일하고 연습글을 일부 고친 것 말고는 변화 사항이 없습니다. 그래서 버전을 올리지 않았습니다. 그러나 기능 변화가 없다고 입력기만 6.0으로 업그레이드하고 타자연습을 업그레이드하지 않으면, 타자연습 내부에서는 <날개셋> 한글 입력기 6.0 외부 모듈을 사용할 수 없게 됩니다. 자체 입력란 말고 일반 입력란에서는 한글을 입력할 수 없고 MS IME 같은 다른 IME를 써야 한다는 뜻입니다.

그러므로 <날개셋>을 윈도우용 IME로 사용하면서 타자연습도 동시에 사용하시는 분이라면 타자연습 프로그램을 반드시 업그레이드해야 합니다. 가능한 한 API 수준의 바이너리 호환성을 안 깨뜨리려고 노력하지만, 6.0은 한글 입력과 타자 재현 루틴 쪽이 많이 바뀌다 보니(타자연습도 핵심적으로 자주 사용하는 기능인데!) 어쩔 수 없이 호환성이 깨지게 됐습니다.

그래도 변화가 너무 없으면 재미없으니까..
연습글의 변화로는,
헌법 연습글에서 헌법 전문(preface)만 있던 걸 1장과 2장도 추가했습니다.
그리고 ‘재미있는 이야기에’ 주옥같은 김 성모 어록을 단문 연습글로 추가했습니다! “미안하다. 똥 싸느라 늦었다”, “더 이상의 자세한 설명은 생략한다”, “하지만 드라군이 출동하면 어떨까?” 등으로 세벌식 타자 연습을 즐겨 보세요!! ㅋㅋㅋㅋㅋㅋㅋㅋㅋ

연습글의 패치 정도는 정말로 자동 업데이트 시스템이라도 있으면 편하긴 하겠죠. 저도 그런 것의 필요성을 느끼고는 있습니다.

※ 몇몇 표기법 변경

프로그램의 모든 UI와 도움말, 그리고 타자연습의 경우 연습글에서 한국 인명의 1-2자 성명은 성과 이름을 붙여 쓰는 것으로 표기를 바꿨습니다. (공병우, 김용묵) 제 프로그램을 처음 접하는 사람에게 이질감을 줄이기 위해서 취한 조치입니다.
하지만 여타 길이의 인명은 여전히 띄어 씁니다. (김 구, 남궁 억, 김 에스더 등~)

한 10년 동안 일부러 표준 표기법을 안 지키다가 관행을 되돌렸으나, 제 느낌상 다시 생각해 봐도 성과 이름은 일관성 있게 띄어 쓰는 게 더 합리적입니다.
제 블로그는 저의 개인 공간이기 때문에 앞으로도 둘을 여전히 띄어 쓸 것입니다.

※ 안 마태 글자판

안 마태 한글 소리글판이 업데이트됐다는 소식을 들었습니다. 그런데 공식 홈페이지에 제대로 홍보가 안 돼 있고, 키보드 드라이버를 개발하시는 분이 블로그에 게시해 놓은 배열과 공식 홈페이지의 배열이 일치하지 않으며, 심지어 레이아웃이 일반 키보드의 모양과도 일치하지 않는 부분 등 여러 문제로 인해, 제 프로그램의 예제 데이터에는 아직 업데이트를 안 했습니다.

※ 다음 버전은?

이제 6.0 이후의 입력기의 다음 버전은 현재로서는 6.1이나 6.2 정도로 생각 중입니다. 시기는 올해 가을쯤? 이번에는 한글이 아닌 ‘한자 기능 강화판’ 컨셉이라는 생각이 들기에 충분할 겁니다.
단어 단위 한자 변환 기능이 드디어 추가되고,
자료가 확보되는 대로 surrogate(확장 B 이상) 영역의 한자에 대한 독음· 부수 입력 지원 등이 계획되어 있습니다.

아주 옛날스러운-_- 글쓰기를 좋아하는 분 중에, 단어 단위 한자 변환 기능이 있다는 이유로 새나루 입력기를 아주 좋아하는 분이 있죠. 참고로 제 편집기는 세로쓰기도 지원한다만... -_-;;;

뭐, 제가 한자 혼용론자의 수요를 의식하는 건 아니고요. 저런 쪽의 연구는 단순히 MS IME와의 기능 격차를 줄이고 제 프로그램의 기술 데모를 만든다는 성격이 더 강합니다. 단어 단위 한자 변환은 MS IME가 그런 것처럼 TSF A급 프로그램에서만 제공될 것입니다.

지금은 옵션이 달랑 3개밖에 없는 편집기 계층에 한자를 단어 단위로 변환할지 글자 단위로 변환할 지 선택을 할 수 있게 되며, surrogate 영역의 확장 한자까지 후보로 출력할지 설정하는 옵션도 추가됩니다. 솔직히 일반 사용자가 BMP 이외의 한자를 쓸 일은 거의 없고, 그런 것까지 그냥 추가해 버리면 한자 후보가 이제 너무 많아지기 때문이죠.
부수+독음(ㄱ~ㅎ이니셜 정도) 연동 한자 검색 기능 추가도 검토 중입니다. 꽤 유용할 것입니다.
물론 한자 관련 기능만 계획되어 있는 건 아니고요.

※ 잡설

이번 6.0은 제발 잔버그가(특히 새로 추가된 기능에서) 발견되지 않았으면 하는 바람이 간절합니다.
작업 완료에 앞서 도움말을 쭉 읽고 검토를 했는데, 좋은 의미로든 비아냥거리는 의미로든 이게 정녕 내가 내 머리로 만든 프로그램과 설명서가 맞나 하는 생각이 들더군요. 내가 지금까지 참 어지간히도 또라이 같은 짓을 했구나 하는 생각.. -_-;;

맥/리눅스로의 포팅, 프로그램 아이콘, 그리고 다국어 UI 번역 등 역할 분담의 필요성이 느껴집니다. 타자연습은 이미 도저히 내 혼자 개발을 할 수 없는 경지에 간 지가 오래이고..;; 저도 슬슬 개발자 마인드에서 벗어나 사장-_- 컨셉으로 가야 하지 않나 싶습니다.

타자연습의 경우, 생각 같아서는 10년 가까이 묵은 연습글들 대부분을 이제 좀 갈아엎어 버리고 싶답니다. -_-;; 그런데 그것도 제가 할 시간과 능력이 안 되고. 게임은? ‘더 이상의 자세한 설명은 생략한다’ 수준. 어쨌든 결론은 돈인데..;;
“내가 나루토를 보면서 느낀 건데, 사람을 쓰려면 돈이 존나 필요할 거 같아. 그런데 날개셋은 수익이 없잖아? 그러니까 우린 안 될 거야 아마..” ㅋㅋㅋㅋㅋ 뼈 있는 농담. -_-

뭐 그렇습니다.
유용하게 사용하시기 바랍니다. ^^

Posted by 사무엘

2011/04/28 11:24 2011/04/28 11:24
Response
No Trackback , 34 Comments
RSS :
http://moogi.new21.org/tc/rss/response/503

My Programming Life

1.

<날개셋> 한글 입력기는 동일한 입력기 커널을 공유하는 세 개의 프런트 엔드가 있다.
그 중에서 가장 존재감 있는 터줏대감은 전용 에디터인 편집기이고, 실질적으로 가장 널리 이용되는 프로그램은 윈도우용 IME인 외부 모듈이다. 한편, 편집기처럼 실행되어 마치 IME처럼 동작하는 포인팅 장치 입력 유틸리티인 입력 패드도 지난 5.3 버전에서부터 추가되어 제 3의 프런트 엔드 구실을 하고 있다.

그 중 가장 먼저 만들어진 ‘편집기’는... 프로그램을 만든 본인부터가 에디터로서 아주 유용히 사용한다.
차라리 외부 모듈은 디버깅 할 때 외에는 사용하지 않는다. 운영체제의 기본 IME로 지정되어 있으면 파일을 고칠 수가 없어서 디버깅을 못 하기도 하기 때문이다.

<날개셋> 편집기는 어떤 점에서는 아주 답답하다. 가변폭 글꼴이 지원 안 되고 글씨 크기 조절도 안 되고, ClearType 렌더링이라든가 OpenType 스펙 등 오늘날의 모든 최신 타이포그래피 기술로부터 완벽하게 소외된 외딴 섬이기 때문이다.

그러나 한편으로 <날개셋> 편집기는 아주 작고 가벼우면서도 윈도우 95 이래 어떤 OS에서나 동일하게 유니코드 5.2 옛한글을 마음대로 조합할 수 있고 한글을 내 마음대로 다룰 수 있는 우리집 안방 같은 공간이다. 내가 만든 프로그램이어서 자화자찬 차원이 아니라 정말로 그렇다.
입력 기능뿐만 아니라 다양한 텍스트 필터도 있고, 한글을 자모 단위로 찾고 입력기에다 넘겨주는 글쇠를 붙여넣는 것 같은 아기자기한 기능도 있다. 도스 시절 추억의 도깨비 한글 비트맵 글꼴을 볼 수 있는 건 덤이다.

예전에는 옛한글은 오로지 내장 글꼴로밖에 표현할 수 없었는데 5.3에서부터 임의의 조합 테이블과 추가 자모를 내장 가능한 자체 비트맵 글꼴 포맷을 제정함으로써 <날개셋> 한글 입력기의 커널은 나름대로 글꼴도 독립을 이뤘다. 아래아한글 1.x와 비슷한 글월 입력 환경을 윈도우 환경에서 재현해 낸 것이다.

완전한 텍스트 에디터 엔진을 처음부터 새로 만들었기 때문에, 앞으로 한글 표현 방식이 어떻게 바뀌든 이 구조에 맞춰 엔진을 마음대로 내가 고칠 수 있다.
리눅스나 맥 OS에서는 이런 게 언제쯤 상륙 가능할까? ㄲㄲ

2.

지금까지 <날개셋> 한글 입력기를 만드는 과정에서 그 당시엔 내가 방법을 전혀 몰라서 어려움을 겪던 고비가 몇 차례 있었다.
- 인스톨 패키지 만들기(2002~2003년): MSI 기반으로 완전히 해결
- 외부 모듈(2004~2005년): 3.x 초창기 버전 때 무수한 시행 착오를 겪으면서 결국 안정화 단계. 하지만 “아직까지도” 일부 극소수 몰상식-_-한 응용 프로그램에서 사소한 오동작 버그 신고가 올라오고 있음
- 64비트(2007년): 결국은 본인이 64비트 기계를 직접 장만하면서 지원에 성공.

3.

한 컴퓨터를 놔두고 세벌식 사용자인 본인과 두벌식 사용자인 지인이 같이 앉아 문서를 읽으면서 검토와 교정을 하고 있었다. 이때 복벌식 입력 방식을 아주 유용하게 사용했다. 글자판 전환을 할 필요 없이 서로 자기에게 익숙한 글자판으로 자기가 수정하고 싶은 곳에서 바로 글자를 입력하면 되니 이렇게 편할 수가 없었다. ^^

이거 하니까 세벌식 관련 다른 팁이 또 생각난다. 세벌식 숫자 배열이 익숙한 분이라면, numlock이 켜져 있을 때 오른손 숫자 자리가 non-shift 자리로 내려오게 하면 엑셀 같은 데서 숫자 입력을 아주 편리하게 할 수 있다. <날개셋> 한글 입력기로는 가능하다.

4.

버전 5.53 내지 5.65쯤부터 추가되었지 싶은데, <날개셋> 편집기로 프로그램이 아닌 문서 창(MDI)의 시스템 메뉴를 보면 해당 문서 파일의 ‘속성’ 창을 바로 꺼내거나, 탐색기를 꺼내거나 전체 경로를 복사하는 명령이 있다. ‘파일 경로 복사’를 고르면 되는데, 지금까지는 진짜 말 그대로 파일의 경로가 텍스트 형태로 복사되어 메모장에서만 그걸 붙여넣을 수 있었다.

그런데 탐색기에서 Ctrl+V를 누르면 해당 파일 자체가 실제로 복사도 되게끔 프로그램을 고쳐 봤다. 메모장과 탐색기는 클립보드를 사용하는 방식이 완전히 다르기 때문에 이 기능은 서로 충돌을 일으키지 않으며, 이렇게 하니까 아주 편하다. 5.8 버전에 이 기능이 반영되지 못해서 아쉽다.

5.8을 릴리즈한 후 현재까지 도움말의 오타 내지 로그인 화면· 아웃룩· vim 등에서의 사소하지만 쉽지 않은 외부 모듈 관련 버그가 몇 개 보고되어 있다. 하지만 다들 프로그램의 성능이나 안정성(죽는다거나-_-)과 관련된 건 아니다. MS IME의 소스를 직접 보지 않는 이상 이런 것까지 다 완벽하게 처리하는 버그 없는 IME란 제작 불가능하다. -_-

5.

다음은 <날개셋> 타자연습 이야기. 지금부터는 그림도 좀 곁들이겠다.

사용자 삽입 이미지
요즘도 실력 유지를 위해 타자 연습을 안 하는 건 아닌데,
주옥같은 연습글을 만들었다. 다음 버전에 추가할지 진지하게 고민 중이다. ^^;;

공 병우 세벌식은 10년을 넘게 써도 한글의 위상을 끌어올린 정말 위대한 발명품임이 느껴진다. 그 반면 저 불편한 현행 두벌식 글자판은 어떻게 쓰는지 그걸로 빨리 치는 사람들이 대단하기 그지없다. 세벌식의 단점--기껏해야 글쇠 수 좀 많고 4단 쓰는 것--에 비해 두벌식의 단점은 훨씬 더 치명적이다.

사용자 삽입 이미지
2008년부터 2010년까지 존재하는 본인의 게임 점수판은 전부 ‘승리’(12단계 깨고 엔딩)이다. 본인이 사무엘이라는 이름을 쓰기 시작한 건 2008년 말부터임.
<날개셋> 타자 게임은 과거의 한메 타자 베네치아보다 훨~씬 더 어렵지만 요즘은 한글 타자가 워낙 일상화했기 때문에 본인 말고도 엔딩 보는 사람이 꽤 있을 것이다.

6.

끝으로, 10년 전에 만들었던 WordTech 엔진(컴퓨터 자동 대국 기능)을 요즘 완전히 새로 다시 짜고 있다. 스크린샷은 기존 WordTech와, 새 엔진(GUI를 갖다붙이지 않은 콘솔 프로그램)끼리 서로 검증 대국을 시키는 모습이다.

사용자 삽입 이미지
본인은 <날개셋> 한글 입력기를 만들기 전엔 국내에서 거의 최초로 크로스워드 게임 엔진을 만든 바 있으나... 그 당시의 작품은 지금의 관점에서 보면 기술적으로 개허접.. ㄲㄲㄲㄲ

요즘은 워낙 컴퓨터가 똑똑해진 덕분에, 굳이 이것보다 더 빠르고 메모리를 덜 쓰는 크로스워드 게임 엔진을 만든다는 게 큰 의미는 없지만... 이번에 새로 짠 코드는 메모리 사용량, 계산량, lexicon의 자료구조와 알고리즘, 코드의 깔끔함과 재사용성 등 모든 면에서 10년 전의 구닥다리 코드와는 비교가 되지 않는다. 참으로 아름답다. ^^;;

사실, 이렇게 만들면 된다는 이론적 기반은 이미 수 년 전에 완성되었지만 <날개셋> 개발 때문에 뒷전으로 밀려서 지금까지 작업을 못 하고 있었을 뿐이다.
WordTech도 버전업 좀 하고 싶은데.. ㅠㅠ 컴퓨터과학과 대학원 수업에서 무슨 과목으로든 프로젝트로 좀 할 기회라도 있었으면 좋겠다. 이 엔진 얹으면 버전 4.0으로 가는 건데.;;

콘솔은 만국의 공통 인터페이스이다 보니(표준 입출력 스트림^^), 엔진을 비주얼 C++뿐만이 아니라 오랜만에 DJGPP로도 컴파일해서 도스에서 돌려 봤다. 똑같이 32비트이기 때문에 별 어려움 없이 돌아간다. 지금도 DJGPP가 버전업이 되고 있는지는 모르겠지만 내가 보유하고 있는 건 무려 1997년에 설치한 버전. 혹시 bool 키워드가 지원되지 않나 확인해 봤는데 다행히 지원한다.

10년 전에는 DJGPP의 그 느린 빌드 속도가 무척 거슬렸으나 지금은 그마저도 전광석화. 별도의 도스박스 같은 에뮬뿐만이 아니라 그냥 윈도우 운영체제의 NTVDM에서도 잘 돌아간다.
단, printf의 포맷 지정자로 %c만 인식하고 %C는 인식하지 않는다. 대문자를 찍는다는 생각에 %X와 %x(16진수 숫자)를 구분하듯 습관적으로 %C를 지정해 줬는데 인식이 안 되더라. 뭐, 어차피 찍을 때 chCode+'A' 식으로 대문자를 지정하기 때문에 %c와 %C는 전혀 구분할 필요가 없고 %c만 지원해도 충분하긴 하다.

이상으로 본인의 programming life 잡설 끗.

Posted by 사무엘

2010/12/29 16:46 2010/12/29 16:46
, , , , , ,
Response
No Trackback , 12 Comments
RSS :
http://moogi.new21.org/tc/rss/response/440

※ 아래의 세 버그는 해당 기능이 처음으로 추가된 5.31버전부터 지금까지 1년이 넘는 시간 동안 존재하다가 이제야 발견하고 고쳐졌습니다.

- "코드번호로 변환" 텍스트 필터의 설정을 고쳤는데 번호 표현 형태(format)가 사용자의 설정대로 제대로 적용되지 않던 버그
- <날개셋> 편집기의 "계산기"에서 '사용할 상수'를 바꿔 줬는데도 해당 분야에 속하는 상수가 제대로 인식되지 않던 버그

- 외부 모듈: <날개셋> 한글 입력기는 TSF A급 프로그램에서는 bksp 키를 눌렀을 때 앞 글자로 달라붙는 기능을 사용할 수 있습니다. 그런데 언제부턴가--한 5.3x 정도부터로 추정-- 완성된 글자를 처음으로 지울 때는 달라붙는 게 동작하지 않는 문제가 있더군요. 아마 입력 패드 같은 기능이 처음으로 추가되면서 들어간 side effect 같습니다. 이걸 발견하여 버그를 고쳤습니다.

※ 아래의 버그는 현재의 최신 버전인 5.65에만 있다가 고쳐졌습니다.

- <날개셋> 편집기를 중복 실행을 허용하지 않은 상태에서 또 중복 실행하면, 예전 인스턴스에서 새 문서도 같이 만들어져야 하는데 되지 않는 것
- <날개셋> 제어판의 '낱자 처리' 탭에서 낱자 결합 규칙의 내정값으로 "유니코드 5.2 옛한글"을 골랐는데도 유니코드 5.2에서 새로 추가된 초록색 옛한글 낱자들이 로딩되지 않던 문제
- 낱자 결합 규칙 리스트에서 비사이클 -> 사이클이 있는 결합 규칙을 대상으로 Ctrl+클릭을 했을 때 프로그램이 무한 루프에 빠지고 죽는 버그 (Ctrl+클릭 기능 자체가 5.65에서 새로 추가된 것임)

※ 다음은 사소한 개선 사항들입니다.

편집기 UI: 프로그램을 종료(Exit)할 때나 창을 한꺼번에 모두 닫을 때(Close All), 저장되지 않은 문서가 둘 이상 있으면 "저장할까요?" 대화상자와 더불어 "다음부터 이 질문을 하지 않음" 체크 상자가 뜹니다. 그래서 이걸 체크하면 여러 문서들을 한꺼번에 저장하거나 단번에 무시하고 버릴 수 있게 했습니다.
단, 이 UI는 윈도우 비스타 이상에서부터만 지원됩니다.

변환기 UI: 클립보드의 옛한글 텍스트 표현 방식을 자동으로 감지하는 버튼을 추가하고, 이에 덧붙여 원본 형식과 대상 형식을 switch하는 버튼을 추가했습니다. 아래아한글 200x와 2010, 그리고 MS 오피스 200x의 옛한글은 모두 표현 방식이 다릅니다. 변환기를 사용하면 각 방식을 손쉽게 교환할 수 있습니다.

편집기: 수천-수만 줄, 수 MB에 달하는 대용량 텍스트를 블록으로 잡아 복사할 때의 성능을 크게 개선했습니다. 예전에는 이때 잦은 메모리 재할당으로 인해 디스크 thrashing이 일어나면서 동작이 멈출 때도 있었지만, 이제는 전체 메모리를 한 번만 미리 잡아놓고 복사가 매우 신속하게 수행됩니다.

입력 패드와 외부 모듈도 편집기의 한글· 영문 비트맵 글꼴 설정을 따라갑니다.

정 재민 님이 추가로 제공해 주신 비트맵 글꼴을 적용하고, 임 정택 님이 제공해 주신 신세벌식 입력 설정을 적용했습니다. 그리고 예제로 제공되던 천지인 입력 방식을 복잡한 받침까지 완전한 일치하는 형태로 개선해 넣었습니다.

※ 다음은 알려진 문제입니다.

1. 현재 <날개셋> 한글 입력기 5.65와, <날개셋> 타자연습 3.21은 저의 부주의로 인해서 버전 충돌이 있습니다. 그래서 타자연습에서 입력기 외부 모듈이 동작하지 못합니다.
이 문제는 앞으로 입력기가 5.80으로 버전업되고 덩달아 타자연습도 버전업되었을 때, 이 둘을 모두 최신 버전으로 업데이트하면 해결될 예정입니다. 불편을 끼친 것에 양해를 구합니다.

2. <날개셋> 한글 입력기를 기본 IME로 지정한 후 gvim (7.3 기준)을 실행하여 A를 눌러 편집 모드로 들어가면, 영문이던 한영 상태가 느닷없이 한글로 바뀌는 현상이 있습니다. 참고로 TSF 모듈에서만(= 윈도우 비스타/7급) 나타납니다.

이것은... 운영체제의 동작 방식에 대한 정보 미비로 인해 해결이 어려울 것 같습니다. 그 프로그램에 맞게 동작을 고쳐 놓으면, 다른 프로그램에서 side effect가 생기는 식의 현상이기 때문입니다. MS 워드나 파워포인트가 처음 실행될 때 영문이 아닌 한글 모드로 시작하게 하는 옵션과 완전히 동일한 맥락이기 때문에, 제 프로그램이 gvim의 한글 모드 전환만 예외적으로 봐 줘야 할 명분이 없습니다.
물론 MS IME에는 그런 현상이 없죠. 그건 소스나 정확한 스펙이 공개되어 있지 않는 걔네들 방식대로만 가능한 것이기 때문에 제가 그 이상 더 정확한 동작을 구현할 수 없습니다.

3. 윈도우 7, 스타크 2에 이어 비주얼 스튜디오 2010에서도 한글 입력이 잘 안 되는 문제가 보고되어 있으며, 이 역시 해당 프로그램의 버그로 추정됩니다. MS IME에서도 동일하게 발생합니다. 갑자기 최신 소프트웨어들에서 IME 쪽으로 자질구레한 버그가 왜 이리 자꾸 발견되는지 모르겠습니다. 한번 짜고 나서는 고칠 일도 없고 버그가 들어갈 일도 없을 것 같은데.

Posted by 사무엘

2010/11/07 11:23 2010/11/07 11:23
Response
No Trackback , 8 Comments
RSS :
http://moogi.new21.org/tc/rss/response/406

직업병

1.
레크리에이션 시간에 하는 OX 퀴즈 말이다. 이거 완전 퀵 정렬스럽다는 느낌이 들지 않는지?
퀴즈는 PIVOT값이다. 정말 알쏭달쏭해서 사람들이 O와 X로 반반씩 갈려야 좋은 문제이고,
너무 쉽거나 해서 사람들이 한데 쏠리면 그건 난감하다. 퀵 정렬도 완전 똑같다. ㅋㅋ

2.
수업 시간에 각 학생들에게 설문지를 돌리거나 과제물을 나눠 준다. 내게도 서류 뭉치가 왔는데, 이게 어디서 왔는지 모르겠고 내가 살펴본 뒤에 다음으로 이걸 어느 방향에다가 넘겨줘야 할지 잘 모를 때가 있다.
이건 C++로 치면 iterator이다. 서류 뭉치는 모든 학생들을 한 번씩 순회하는데, ++itor; 명령이 수행되려면 지금의 순회 위치로부터 다음 순회 위치를 알 수 있어야 한다. 트리 구조를 순회한다면, 각 노드마다 부모 노드 포인터도 갖추고 있어야 한다는 뜻.

3.
요즘 존재하는 수많은 웹사이트들 중, html 수작업으로 만들어진 것들은 로컬 환경으로 치면 기계어로 짠 네이티브 프로그램이고, 블로그 엔진 기반은 닷넷처럼 일종의 상부 계층 위에서 돌아가는 프로그램에다 비유할 수 있을 것 같다.
개인 사용자가 나모 같은 에디터로 홈페이지를 만들 일이 없어졌다는 건, 윈도우 환경에서 어셈블러 수작업으로 프로그램을 만들 일이 없어진 것과 비슷한 맥락이 아닌가 싶다.
하지만 Win32 API 같은 네이티브 계층 자체가 완전히 없어지는 날은 과연 올까?

4.
외솔관에 있는 대학원생 독서실에 있다가 위당관으로 수업을 들으러 간다. 두 건물의 뒤쪽엔 높은 언덕이 있기 때문에 3층과 4층이 뒷문으로 연결되어 있으며, 이 경로를 이용하면 건물 사이를 왕래할 때 번거롭게 1층까지 내려갔다가 다시 올라갈 필요가 없다.
바깥에 비해 상대적으로 어두운 건물 복도를 걸으면서 지하철 터널을 떠올리는 것은 어렵지 않다. 그러다가 잠시 밖으로 나가면, 지하철이 강을 건너거나 서울 지하철 8호선의 복정-산성 구간 같은 곳을 지나느라 잠시 지상으로 나온 것 같은 느낌이 든다.

5.
교회에서 성가대 연습을 한다. 노래를 부르는데 반주자가 악보를 넘기느라 잠시 피아노 반주가 중단되었다. 그래도 노래는 박자나 음정의 어긋남이 없이 계속 잘 이어진다.
이것은 절연 구간을 지나느라 전동차에 전원 공급이 잠시 중단되더라도 차가 관성으로 계속 달리는 것과 같은 맥락으로 풀이할 수 있다. 아울러, 바닷물과 민물을 넘나드는 연어는 교류-직류 겸용 전동차의 예표이다.
일상생활 속에서 철도 패턴을 찾기는 어려운 일이 아니다.

6.
대학 학부까지만 학업을 마치고 취업을 한 건, 지금 생각해 보니 학업이라는 지하철이 서울 시계까지만 건설된 뒤 노선이 끊어졌던 듯한 느낌이다. 학부를 졸업한 지 5년이 지나서야 대학원에 들어가니, 그 선로를 이어서 장거리 광역전철을 건설하는 것 같다.

7.
<날개셋> 한글 입력기 5.65를 공개한 후, 소스를 대대적으로 뒤집어엎었다.
null-terminate 스트링의 write 버퍼를 받는 모든 함수에는 버퍼의 크기에 대한 정보를 추가하고, sprintf 같은 함수 호출도 버퍼 오버런을 일으키지 않게 다 손질했다.
파일을 읽고 쓰는 과정에서 에러 처리를 더욱 강화하고, 범용적인 dll 모듈은 thread-safe하도록 고쳤다.
좀 비효율적이고 불합리하게 만들어져 있던 라이브러리 API를 뜯어고쳤다.

그래서 다음 버전으로 잠정 계획 중인 <날개셋> 한글 입력기 5.8은 5.5 시절부터 비교적 잘 유지되어 왔던 API 하위 호환성이 모두 깨질 예정이다.
타자연습도 덩달아 버전업된다. 입력기에 적용된 프로그래밍 테크닉이 그대로 적용되고, 그리고 연습글을 좀 정리할 생각이다.

6만 줄에 달하는 <날개셋> 한글 입력기 소스 코드를 들여다보노라면 정말 나만의 세계, 나만의 건축물, 나만의 철도 노선에 들어온 느낌이다. 의존도라고는 Win32 API와 몇몇 Ansi C 함수밖에 없으며, 나머지 코드들은 100% 자체 제작이다. 다른 프레임워크나 오픈소스 작품 같은 거 쓴 것이 전혀 없다.

누구에게 돈이나 시간 면에서 단 한 치도 얽매인 게 없이, 전적으로 개인 취미 생활로 개발하는 것이다 보니,
단순히 기능만 되게 하는 게 아니라 소스 코드의 질에도 굉장히 신경을 쓴다.
비록 한 줄에 100칼럼을 꽉꽉 채우느라 겉보기로는 코드가 좀 지저분해 보여도, 구조는 의외로 깔끔한 편. ㅋㅋㅋㅋ

코드에 무슨 공통된 패턴이 반복되는 게 발견되면 함수로 따로 떼낸다거나, 모듈 간의 공통된 기능을 한 기반 클래스로 빼낸다거나.. 이런 식으로 "리팩터링"을 수시로 진행한다는 뜻이다.
이런 거 공사 하나 잘 해서 추상적인 클래스가 하나 탄생하고 상속 계층이 한 단계 올라간다거나 하면,
어려운 버그를 잡은 것만큼이나 기쁘다.

Posted by 사무엘

2010/10/17 18:08 2010/10/17 18:08
, ,
Response
No Trackback , 4 Comments
RSS :
http://moogi.new21.org/tc/rss/response/393

안경이 제아무리 시력을 강화해 주고 눈을 보호해 주고 얼굴 외모를 살려 주고 온갖 좋은 액세서리 기능이 있다고 해도, 안경 쓸 필요가 없는 건강한 눈보다 좋지는 못하다.

휠체어가 제아무리 푹신한 웰빙 좌석이 있고 심지어 컴퓨터도 달려 있고, 전동이어서 이동도 힘 안들이고 편리하게 된다고 하더라도 사람의 건강한 다리 자체를 대신할 수는 절대 없다.

이것은 본인이 컴퓨터에서 일본어를 입력해 보면서 느낀 점이다.
자, 이제 본인이 무슨 얘기를 꺼낼지 눈치 빠른 분이라면 상상이 될 것이다.

일본어 입력기는 뭔가 휠체어 같은 존재라는 느낌이 든다.
제아무리 일본어 IME에 일본어 사전이 통째로 들어있고 환상적인 한자 변환, 전/반각 변환, 히라가나/가타카나 변환에 상용구, 맞춤법 검사기 기능까지 워드 프로세서에나 있을 법한 기능을 죄다 옮겨 놓았다고 해도..
IME 자체가 아예 필요 없이, 치는 대로 아무 제약 없이 곧바로 입력이 접수되는 알파벳/숫자 입력만치 편리할 수가 있을까?

글자 하나로도 모자라서 어절 전체를 본문에다 바로 넘겨주지도 못하고 조합 영역으로 잡고, 또 변환하고, 잘못 변환한 게 있으면 교정하고, 사전 업데이트해서 신조어 등록하고..;

수분이 몸을 무겁게 하는 것보다도 한자는 문자 생활을 더욱 무겁게 한다. 문자를 처리하는 인간의 시간을 낭비하고 비효율을 초래한다.
뭐, 한자라는 문자가 만들어진 것 자체가 인류 역사의 비극이고 한자는 당장 없어져야 할 개 쓰레기라는 식의 초딩스러운 주장을 하겠다는 게 아니다. 본인은 한자의 그 무한한-_- 제자 원리에 담겨 있는 오묘함을 인정하며, 인류가 오랜 시간 동안 한자를 이용해서 축적한 동양 문화 자산의 가치도 존중한다.
다만, 오늘날처럼 PC· 노트북도 모자라서 스마트폰까지 등장한 정보화 시대에 한자는 너무나 거추장스러운 legacy로 전락해 있다는 객관적인 현실만을 얘기하고자 할 뿐이다.

출처는 잘 모르겠다만 누군가가 말하길, 일본의 경쟁력을 떨어뜨리는 3N 중의 하나가 이런 일본어 정서법이라고 '카더라'. (일본의 무슨 메이저 통신 회사, 나리타 공항, 그리고 일본어-_-)
MS 연구소에서 근무하는 어떤 엄청 똑똑한 사람이.. 일본의 문자 입력 체계는 진짜 ㅂㅅ 장애인급이라고 혹평을 한 글을 썼다는 소식도 본인은 들은 기억이 있다.

이런 점에서 보면 한국과 일본은 태양계의 행성 중 마치 지구와 금성처럼 지리적으로는 굉장히 가깝지만, 문화적으로나 특히 문자에 관한 한은 정말 지구와 금성의 대기 구성의 차이만큼이나 극과 극인 것 같다.

물론, 아무리 눈이 건강한 사람이라도 눈을 보호하기 위해 필요하다면 가글이나 선글라스를 써야 하고,
아무리 다리가 정상인 사람이라도 빨리 이동하려면 다른 교통수단을 이용해야 한다.
<날개셋> 한글 입력기는 한글 문자 입력이라는 분야에서 휠체어 같은 존재가 아니라, 오토바이나 자동차 같은 존재이고 싶다. 이것이 본인이 생각하는 개발 철학이다.

원래 한글은 글꼴과 글자판과 코드 체계만 약간 튜닝을 하면 로마자처럼 직결식--중간 조합 상태가 존재하지 않으며 치는 대로 곧바로 찍히는-- 입력이 가능하다. 풀어쓰기가 아니라 모아쓰는 체계를 유지하면서도 말이다. 세벌식 타자기가 그 예이며 그 원리를 발견해서 처음으로 실용화한 분이 잘 알다시피 공 병우 박사이다.

하지만 그렇게까지 극단적인 튜닝을 일상화하기에는 현실이 못 따라 주는 만큼(네모 글꼴, 음절 단위 한글 인코딩, 두벌식 글자판 등), 한글 IME라는 계층이 일단 컴퓨터에서 필요는 하다. 물론 그래 봤자 중국· 일본어 IME에 비해서 한글 IME의 동작 구조는 훨씬 더 간단하긴 하다. (또한, 전화기 같은 환경에서는 워낙 글쇠 수가 적다 보니, 사실은 영문조차도 다중타 같은 IME 계층을 거쳐서 입력하며, 심지어 사전을 이용한 단어 자동 완성 기능이 존재하기도 한다.)

"기왕 IME라는 계층을 넣을 거면 IME 없이는 도저히 할 수 없는 편리한 한글 입력 기능도 넣어 보자. 세벌식은 원래 직결식 입력도 가능한 체계인데, 굳이 그 가벼움을 포기하고 이왕 중간 조합 상태를 만들 것이라면 세벌식으로만 가능한 편의 기능을 넣어 보자. 흔히 세벌식 하면 글쇠 수가 많은 걸 단점으로만 보는 경향이 있는데, 초중종 글쇠가 모두 따로 있음으로써 더 편리해지는 점도 있을 것이다."

는 것이 10년 전의 <날개셋> 한글 입력기 1.0 시절부터 지금까지 변함없는 철학이었다. 모아치기, 특정 낱자 바로 지우기, 앞 글자로 자동 달라붙기 등..! 그리고 그걸 연구하는 과정에서 덤으로, 한글 입력 방식을 범용적으로 기술하는 데 필요한 요소들을 체계적으로 정리하고 계층을 나누게 된 것이다. 여기까지 생각을 안 해 본 사람이라면, 무슨 게임이나 업무용 소프트웨어도 아니고 한글 입력기 같은 간단한(?) 프로그램이 어떻게 정올에서 입상을 했는지, 내 프로그램이 정확하게 무슨 의미가 있는 프로그램인지도 잘 이해를 못 할 것이다.

그런데, 만들고 만들고 또 버전업을 거듭하고도 <날개셋> 한글 입력기는 계속 더 만들 게 생기고, 넣고 싶은 기능이 떠오르는지 모르겠다. 지금까지 10년을 연구한 것처럼 앞으로 또 10년은 더 투자해야 정말 한글 입력기로서는 더 개선할 게 없는 완전체가 나오려나? 앞으로 두고볼 일이다.

끝으로 생각해 볼 게 있다.
그런 후진 문자를 쓰는 일본도 과학이야 그렇다 치더라도 노벨 문학상까지 배출한 상태인데 왜 우리나라는 그 우수한 문자를 갖고도 해 놓은 게 없냐는 것이다.
기술이 있는 것과 그 기술을 바탕으로 자본과 산업 인프라가 탄탄히 '축적'되어 있는 것은 다르다.
단순히 함수 f(x)의 값이 큰 것과, 그 f(x)의 값들이 꽤 긴 구간 동안 적분된 것은 차원이 다른 개념인 것이다.

제아무리 한글이 우수한 문자여도 한국어로 만들어진 고차원적인 철학 사상이나, 과학 기술 용어가 없으니 무용지물이다. 그걸 이제 와서 살려 보려고 해도 답이 별로 없다. =_=;;
아래아한글이 혼자서 제아무리 날고 기는 워드 프로세서라고 해도 워드· 엑셀· 파워포인트가 한데 뭉쳐 있는 오피스 스위트슈트를 이길 수는 없으며(실제로 아래아한글이 그런지와는 별개의 문제),
고대인들이 아무리 과학 기술이 뛰어났어도 오늘날처럼 자동차와 컴퓨터, 인터넷을 만들어내지는 못했음이 자명한 것과 비슷한 맥락이 아닐까 한다.

Posted by 사무엘

2010/10/11 09:09 2010/10/11 09:09
, , , ,
Response
No Trackback , 17 Comments
RSS :
http://moogi.new21.org/tc/rss/response/389

2000년 7월 27일
반 년이 넘는 시간 동안 개발해 온 <날개셋> 한글 입력기 1.0 프로젝트를 완료하고 프로그램과 설명서를 교육청에 제출했다.

2000년 8월 30일
밤 11시 20분경, 기숙사 사감 선생님이 나를 불러 집에 전화가 왔다고 전해 주셨다. 그리고 무슨 대회 예선을 통과했다고 하는 일종의 힌트도 덧붙였다. 집에 전화해서 보니 아니나다를까 어머니께서 ICC(당시 정보 문화 센터.. KOI 주최 기관)에서 연락이 왔다고 전해 주셨다. 결과는 물론 합격이었다.
오! 이제까지 코딩한다고 겪은 고생과, 그 고통보다 더 컸던 기다림의 고통이 단번에 사라지는 순간이었다.

2000년 9월 1일, 7교시 수업을 듣고 바로 가방을 싼 뒤 담임 선생님을 만나고 나서 집으로 돌아갔다. 2차 심사 준비를 해야 하니까. 2년 전의 기적이 재현됐으니 난 뛸 듯이 기뻤다.

그리고 9월 2일, 오전 6시에 출발하는 서울 행 고속버스를 타고 나는 어머니와 함께 서울로 떠났다.
97, 98년때와는 달리 이번에는 2차 심사가 대학교가 아닌 ICC 본관에서 열렸다. 건물은 새로 지어져 있었고 무척 깔끔했다. 1년 반쯤 전에 여기 왔을 때와는 사뭇 다른 모습이었다.

넓은 홀에 도착했을 때는 아직 아침이었다. 몇몇 사람이 먼저 와서 기다리고 있었고, 나는 거기서 잠시 눈을 붙였다. 그러고 나서 나는 어머니와 점심을 먹었다. 오후 2시 20분이 되어서 나는 대기실로 들어가서 진행위원의 지시를 들었다. 특별히 하는 일 없이 몇 시간이 금방 흘러갔다.

나는 심사받는 15명 중 가장 먼저 심사받는 조에 걸렸다. 수험표를 받고 심사장으로 들어갔다. 카이스트, 고려대 교수를 비롯한 다섯 명의 교수들이 컴퓨터를 빙 둘러싼 가운데 설명을 해야 했기 때문에 약간 떨리긴 했지만, 난 준비한 슬라이드를 보여주면서 진지하게 프로그램 소개를 했다.

교수들이 주로 질문한 내용은 두벌식 자판에 대한 내 입력기의 호환성이었다. 나는 망설이지 않고 내 입력기의 장점을 강조하면서, 한글 기계화는 세벌식으로 가는 것이 타당하다고 말을 이었다.
곧이어 심사 위원들은 이 프로그램을 무슨 언어로 짰는지 묻고, 여기에 대한 지식을 언제부터 쌓아 왔는지 물었다. 난 물론 사실대로 대답했다.

이런 식으로 10분짜리 심사가 끝나고 나는 귀가하게 됐다. 그동안 조금도 떨지 않았고, 심사위원과 아주 평범하게, 부담없이 얘기를 나눴다. 시간이 내가 느낀 것보다 훨씬 빨리 갔음을 느낄 수 있었다.

2000년 9월 4일
아침 조회가 끝난 직후에 부랴부랴 ICC 홈페이지에 접속해 봤지만 별다른 소식은 없었다. 그런데 4층으로 올라가자 담임 선생님께서 내게 대상을 받았다고 전해 주셨다. 날 보더니 악수를 청하면서 “용묵아, 축하한다. 대상이더라.” 하고 말씀하셨다.
아니, 내가 컴퓨터실에 가 있던 사이에 선생님께서 먼저 교실에다 소식을 전하신 모양이었다. 급우들도 나를 보자 곧바로 축하 인사를 건네고, 이제 카이스트에 그냥 갈 수 있냐고 다그쳐 물었다.

-- 이 날은 네게 기념일이 될지니 네가 이 날을 평생 명절로 지키고 규례에 따라 그것을 영원토록 명절로 지킬지니라.
-- 보라, 김 용묵의 남은 행적 곧 그가 코딩을 하고 정올에서 입상한 과정은 그의 일기에 기록되어 있느니라.

당시 17회 대회 때 고등부에서는 총 92편의 작품이 출품되었다. 그 중 15편이 2차 심사 대상자가 되었다.
참고로, 대회 결과가 발표된 지 얼마 안 되어 ICC 홈페이지엔 이런 글도 올라와 있었다.

"공모는 대리 출품이 가능하다."라는 잘못된 인식;;

17회 공모 면접을 보신 분들은 2~3명만 빼고는 모두 망연자실한 표정으로..-_- 면접실을 나갔습니다.
다들..진이 빠진 상태에서;; 심사위원님들의.. 해박함에 질려서;;
또.. 몇 개월 동안 밤샘해서 만든 자기 프로그램이..심위분들 앞에서 일순간 쓰레기가 되어 버린 것에 대한;; 황당함;; 때문에 말이죠.

아는;; 수상자님께서;; 면접 끝나고 나서;; 대기실에 있는 제게 오시더니 "그들은 모든 걸 알고 있어.."라고 하시더군요;;

그렇습니다;; 심위님들은.. 모든 걸 알고 있죠..--; 무슨 얘기냐 하면
어설프게 다른 프로그램 베끼거나..대리 개발해서 출품한 작품은
3분 내에 뽀록납니다.
작품과 관련된 배경 이론들을 모조리 물어보시며.. 우선.. 나쁘게 말해서-_- 작품을 무시하고 들어갑니다..
어떻게든 출품자를 당황하게 만드는 게; 최고 미션인 듯;;하더군요-_-
심지어는.. 열심히 작품 설명하고있는데.. 딴 데 쳐다보시고..
심위님들끼리 딴 얘기 하시고..--; 중간에 말 끊고;; 이건 기본이구,

저는 맨 마지막쯤에..면접을 봐서리, 또 설치 중에 문제가 많아서 다른 분들 면접하시는 걸 거의 다 봤는데요..
거의 모든 분들 면접할때..심위님들 입에서 나오는 말이..
"그래서 되는 게 뭔데? 빨리 보여 달라니깐.."
"그럼 그게 뭐야? 이미 있는 거잖아? 좋을 게 뭔데?"
"뭐야? 아무 필요 없는 건데?"
"다 하는 거네.."
이런..--;성격의 것들이죠;

심위님들 앞에서 절대 거짓말 못 합니다.-_-
모르는 것 아는 체 못 하구요-_- 대리 개발작..바로 뽀록납니다..


본인은 심사 받으면서 저런 일을 전혀 겪지 않았으며(2~3명 중의 하나였군), 아주 무난하고 자연스럽게 내 프로그램 소개를 하고 질문에 답변도 하고 왔다. 또한 조원들 중에 가장 먼저 심사를 받았기 때문에 다른 사람들의 심사 장면은 보지도 못했다. 가히 best 케이스...;;
솔직히 말해서 내 프로그램은 대리 개발을 할래야 할 수가 없는 아이템이었으니 말이다.

대회 결과가 나오긴 했는데.. 문제가 있었다.
카이스트는 다른 대학보다 전형을 굉장히 일찍 하기 때문에, 본인은 이 대회의 결과를 아직 모르는 상태에서 원서를 '일반 지원자'로 제출해 버린 상태였다.

그런데.. 카이스트는 추후에 발표된 이 대회 결과를 받아들였고, '일반 지원자'이던 본인의 등급을 '지정 대회 우수 입상자'로 업그레이드해 줬다. (지금은 그런 대인배스러운 제도는 이미 옛날에 없어졌음. ㄲㄲ)
나중에 카이스트에서 본인의 고등학교로 1차 서류 전형 합격자 명단을 팩스로 보내 줬는데, 그때 본인의 이름은 인쇄체가 아니라 맨 끝에 손글씨로 적혀 있었다는 전설이 전해진다.

그리고 그 <날개셋> 한글 입력기 1.0은 2, 3, 4를 거쳐서 10년이 지난 지금은.. 5.65까지 버전이 올라갔다. 5.65 버전이 일종의 개발 10주년 기념작이다. 소스 코드 줄 수는 10년 전에 비해서 5배가 넘게 불어났고, 기술 수준은 당연히 그때와는 비교가 되지 않는다.

학부 시절엔 이 프로그램 개발과 관련된 연구만으로 5학점을 먹었다. 3학점짜리 학부 졸업 논문과 1학점짜리 개별 연구 두 건(TSF 모듈 개발, 그리고 3.0 아키텍처 연구). 이제 대학원에 가서도 써먹을 예정이다. 왜냐 하면 학부 졸업 후에도 또 논문 쓸 만치 연구 실적은 추가로 쌓였기 때문이다. 그리고 사실은 <날개셋> 말고도 전산 기술을 접목시킨 다른 한글 관련 연구 주제도 생각하고 있는 게 있다.

프로그램 개발하면서 나름대로 아래와 같은 손발리 오그라들 것 같은 말도 들었다. 앞으로도 <날개셋> 한글 입력기의 무궁한 발전을 위하여, 버전 6.0을 향하여 "cheers!"를 외쳐 본다.

-- 그 프로그램은 "날개셋 한글입력기 3.02" 이다. 세벌식의 무한한 가능성을 확신할 수 있게 만들어 준것이 바로 이 위대한 발명품(나는 그렇게 평가하고 싶다)이다.
정말 단순히 손목이 부담이 없고, 속도나 좀 더 빠르게 나올수 있다는 정도라면 나는 결코 세벌식 자판과 이 프로그램을 추천하지 않았을 것이다. (…)

-- 그냥 쓸 때는 잘 모릅니다. 하지만 날개셋을 써 보면 왜 세벌식 최종이 좋은 지 알 수 있으실 겁니다..
무궁무진한 응용을 할 수 있죠..  “한글이 컴퓨터와 이리도 잘 어울리다니”하는 생각마저 들 정도입니다. ^^

-- 용묵님은 우리나라 역사에 꼭 남을 인물이라고 생각합니다. 적어도 문화사에는요.

-- 저는 이미 용묵씨의 <날개셋>은 영원한 한민족의 유산이 되었다고 생각합니다. 더구나 앞으로 올 발전을 생각하면 가슴마저 뻐근할 정도의 감동을 느끼곤 합니다.

-- 이 프로그램은 프리웨어라는 것을 믿을 수 없을 정도로 방대한 기능을 가지고 있다.

-- 10年前、高校生がこれだけ高度なIMEを??で開?するなんて、さすがはIT先進?の韓?。
10년 전에 고등학생이 이만큼 고급 IME를 독학으로 개발하다니, 과연 한국은 IT 선진국이다. (일본인 중에 내 프로그램 사용자)


 

Posted by 사무엘

2010/09/03 08:30 2010/09/03 08:30
, ,
Response
No Trackback , 6 Comments
RSS :
http://moogi.new21.org/tc/rss/response/364

한글 낱자 입력 컨트롤

<날개셋> 한글 입력기는 한글 입력 설정을 전문적으로 다루는 프로그램이다 보니, 여타 프로그램에서는 찾을 수 없는 독특한 UI를 갖추고 있다.

그 중 대표적인 예는 한글 낱자만 하나 입력 받는 컨트롤 윈도우이다.
제어판에서 입력 항목 설정으로 들어간 후, "낱자 처리"에서 어렵지 않게 구경할 수 있다. 바로 이렇게 생긴 놈이다.

사용자 삽입 이미지

<날개셋> 1.x 시절에는 그런 게 없었고, 그냥 글자 입력+콤보가 결합된 일반 표준 컨트롤을 썼다.
어차피 옛한글도 지원 안 되고 고를 수 있는 게 초성 ㄱ부터 ㅎ까지 19개, 중성 21개, 종성 27개가 전부였으므로 이렇게만 UI를 만들어도 아무 문제될 게 없었다.

사용자 삽입 이미지

그러던 게 <날개셋> 2.x 시절에는 상황이 약간 달라졌다.
옛한글이 지원되기 시작했기 때문에, 운영체제가 시스템 차원에서 표시할 수 없는 한글 낱자도 그려야 할 필요가 생겼다. 그래서 owner-draw(항목 내용을 응용 프로그램이 직접 그리는) 콤보박스로 UI가 바뀌었다.

사용자 삽입 이미지

그러나 그 대신 원하는 낱자를 한글 글자판으로 바로 입력하는 기능은 사라졌기 때문에, 설정을 바꾸기 위해 매번 콤보박스를 열고 스크롤을 해서 낱자를 클릭해야 하게 되어 번거로워졌다.
자음이 2~30개가 채 안 넘던 게 옛한글 포함 134개로 폭증했으니 스크롤 양도 증가했을 것이고, 가상 낱자까지 포함해 256개나 되는 항목이 한 줄에 겨우 한 개씩만 표시되는 것도 매우 불편한 점이었다.

지금과 같은 형태의 독자적인 낱자 입력 컨트롤은 <날개셋> 3.0과 함께 첫 도입되었다.
2.x 시절의 불편도 해소해야 하거니와 3.0부터는 가상 낱자의 공간이 8비트 크기인 255를 넘어 아예 16비트 크기로 확장되었기 때문에, 예전과 같은 UI 자체를 전혀 사용할 수 없게 되었기 때문이다. 콤보박스에다 아이템을 65500개 추가하리?

낱자 입력 컨트롤은 에디트 컨트롤과 콤보박스 컨트롤을 혼합한 형태로 만들어졌으며 한글 낱자 하나만 입력하는 데 생각할 수 있는 최대한의 편의를 보장한다. 마치 그래픽 편집 프로그램이 자신만의 전용 색깔 선택 컨트롤을 구현해 놓은 경우가 많듯, 한글 입력기는 응당 자신만의 한글 낱자 선택 컨트롤을 갖춘 셈이다. 아래의 설명을 잘 읽어보기 바란다.

먼저, 이 컨트롤은 <날개셋> 한글 입력기의 입력 커널을 그대로 공유한다.
<날개셋> 편집기에서 글자판을 전환한 것이 이 낱자 입력 컨트롤에서도 그대로 적용된다. 그래서 지금 세벌식 최종 자판을 쓰고 있다가 초성 입력란에서 ㄱ~ㅎ 중 하나를 누르면 그 낱자가 바로 입력된다.

한글만 입력 가능한가? 그렇지 않다. 숫자를 입력하면 해당 낱자 번호에 해당하는 낱자가 바로 입력되며, 이때 숫자는 세벌식 자판의 숫자 패드라든가 numlock 키패드 숫자를 모두 인식한다. 쉽게 말해 낱자 입력 컨트롤은 한글과 숫자를 이중으로 입력받는 체계를 갖춘 셈이다. 숫자로는 물리적인 한글 낱자로 대응하지 않는 가상의 낱자를 입력할 수 있다.
숫자를 입력하고 있을 때는 오른쪽의 숫자가 빨간색이 되어 모드가 바뀌었음을 알려 준다.

여기에 덧붙여 지금이 한글이 아닌 영문 입력 모드인 경우, 그 영문 이니셜로 시작하는 낱자로 바로 이동이 된다. 즉, G를 눌러서 ㄱ, ㄲ 등을, N을 눌러서 ㄴ을 선택할 수 있고 I를 눌러서 ㅣ로 바로 갈 수도 있다.

그리고 화살표 키를 쓸 수 있다. 상하 화살표를 누르면 코드 번호가 1씩 증가하거나 감소하고, 좌우 화살표를 누르면 잡다한 옛한글들을 건너뛰고 ㄱㄴㄷㄹ 순으로 빠르게 이동이 가능하다.

어디 그 뿐이랴? 지금 입력 중인 낱자를 복사하거나 붙여넣을 수도 있다. Ctrl+C, X, V 단축키가 있으며 심지어 우클릭 메뉴도 구비되어 있다. 숫자를 복사하거나 한글 낱자를 하나 복사해서 붙여넣으면 그 낱자가 바로 입력된다.

이 컨트롤을 마우스로 클릭하거나, 포커스가 있는 상태에서 F4를 누르면 콤보박스가 나타난다. 이것은 운영체제의 콤보박스와 동작 방식이 같다. 그러면 선택 가능한 모든 한글 낱자가 문자표 형태로 한 화면에 쭉 나타나며(스크롤 같은 것 없음), 원하는 낱자를 마우스로 클릭하면 된다. <날개셋> 한글 입력기 5.0은 지원하는 한글 낱자 개수가 더욱 늘어나 있다. 한글 낱자들은 색깔이 제각각 다른데, 그 의미는 다음과 같다.

- 검정: 현대 한글 (초성 19, 중성 21, 종성 27)
- 파랑: KS 완성형 코드에 낱자 형태로 등록되어 있는 기초 옛한글로,
- 분홍: 유니코드 1.1과 아래아한글 2.0이 전통적으로 지원해 온 옛한글 (U+11xx대)
- 초록: 한동안 한양 PUA에만 존재했고 유니코드 5.2와 <날개셋> 5.x에서 표준으로 정식 추가된 옛한글
- 회색: 초성이나 종성 중 한 곳에만 존재하는 자음을, <날개셋>만이 내부 편의를 위해 다른 쪽에도 비표준 방식으로 구현한 것

한글 낱자를 마우스 포인터로 가리키고 있으면 해당 자모의 유니코드 이름과, 영문 변수명이 풍선 도움말로 뜨기 때문에 외국인에게도 도움이 될 것이다. F3을 누르면 사전 순이 아닌 등급 순으로 낱자들이 정렬된다. 즉, 검은색 현대 한글이 ㄱ부터 ㅎ까지 뜬 후, 그 뒤 옛한글이 뒤따른다는 뜻.

윈도우 운영체제가 제공하는 콤보박스의 약점 중 하나는, 현재 선택된 아이템에서 인접한 아이템으로 한 번 클릭만으로 손쉽게 이동하는 게 없다는 것이다. 그런 약점을 보완하기 위해 슬라이더라든가 up-down 컨트롤을 옆에 덧붙이는 경우도 있다. 그러나 한글 낱자를 선택하는 건 무슨 연속된 영역을 선택하는 게이지도 아니고, 무슨 글꼴 선택 콤보박스처럼 이것저것 살펴봐야 하는 부류도 아니기 때문에 그런 UI는 넣지 않았다.

이런 점에서 <날개셋> 한글 입력기의 낱자 입력 컨트롤은 <날개셋> 한글 입력기만의 고유한 UI로 불리기에 손색이 없다. 걸출한 고유 UI로는 글쇠배열 편집기도 있는데, 이 UI 역시 써 본 분들은 알겠지만 <날개셋> 입력 커널을 공유하기 때문에 내가 당장 쓰는 글쇠배열로 다른 글쇠배열을 손쉽게 만들 수 있다. 아울러, 낱자 입력 컨트롤의 콤보박스 부분은, 문자표에서 볼 수 있는 문자표 컨트롤의 코드를 공유한다.

Posted by 사무엘

2010/08/21 15:33 2010/08/21 15:33
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/353

« Previous : 1 : ... 8 : 9 : 10 : 11 : 12 : 13 : 14 : 15 : Next »

블로그 이미지

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

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2026/07   »
      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:
3940701
Today:
1369
Yesterday:
2118