김 용묵의 절대공간 - 블로그

<날개셋> 편집기는 내부 에디팅 엔진이 TSF를 완벽하게(A급으로) 지원하게 할지 지정하는 ‘TSF 지원’이라는 도구-옵션 대화상자에 있다. 프로그램이 TSF A급으로 동작하면 그 밑에서 구동 중인 외부 모듈이 에디터의 텍스트를 자유롭게 다룰 수 있고 MS 한국어 IME는 단어 단위 한자 변환도 가능하며, 일본어 IME의 경우 Natural Input 모드로(커서 위치에 따라서 조합/비조합 모드가 자유자재로 왔다갔다) 동작도 가능하다.

그러나 이런 편의에는 속도와 메모리 사용량 같은 tradeoff가 응당 있다. TSF A급으로 동작하기 위해서는 프로그램이 커서 하나가 움직일 때에도 운영체제의 TSF 시스템에다가 일일이 통보를 해 줘야 한다. 그래야 연동이 제대로 된다.

그런데 이 TSF 시스템이라는 게 돌아가는 모습이 못마땅할 때가 있다. 내 프로그램이 문서 전체처럼 꽤 많은 영역의 블록을 잡고 있으면, 이따금씩 운영체제는 블록 텍스트가 무엇이 있는지 수 MB에 달하는 데이터를 일일이 요청한다. 그것도 키 하나 누를 때마다, 커서가 움직여서 블록 영역이 조금이라도 바뀔 때마다 말이다. 그 텍스트 얻어 와서 도대체 뭘 하는지는 모르겠다. 그 요청을 거절할 수도 없는 노릇이고, 거 참.

이 때문에 <날개셋> 편집기로 20MB 이상 대용량의 텍스트를 열고, 새로운 글자 입력보다는 오리고 붙이기 같은 편집이 주 사용 목적이라면 ‘TSF 지원’ 옵션을 끄고 프로그램을 다시 실행하는 게 성능 면에서 낫다. TSF A급을 유지하면서 지금보다 성능을 더 끌어올릴 수 있는 방법이 현재로서는 떠오르지 않는다.

대용량 파일을 수월하게 다루는 전문적인 에디터를 개발하는 게 목적이라면, 별도의 전문적인 메모리 관리자도 쓰고 더욱 심도 있게 성능 최적화를 할 수 있다. 그러나 <날개셋> 편집기의 1차적인 개발 목적은 잘 알다시피 그냥 입력 엔진의 기술 데모일 뿐이기 때문에, 그런 세세한 것까지 신경 쓰지는 않는다.

하지만 한편으론 아주 작고 가볍고 최적화 잘 되고 빠른 에디터도 어느 정도 지향하고 있다. 그런 컨셉의 프로그램이 덩치에 어울리지 않게 에디팅 엔진이 너무 비효율적이고 느리면 그것도 영 보기 안 좋다. 그래서 이 프로그램은 버전업을 거듭하면서(특히 5.x 후반과 6.5 사이에) 내부적으로 최적화도 상당히 많이 되었으며, 몇십 MB짜리 파일 정도는 부담 없이 편집하고 저장할 수 있는 프로그램이 되었다.

혹시 MS에서 만든 다른 TSF A급 프로그램은 사정이 어떨까 궁금했다. 워드패드를 살펴봤는데, <날개셋> 편집기보다 성능이 더 안 좋다. 아까보다 더 작은 수 MB짜리 파일을 열어도 프로그램이 감당을 못 하고, 역시나 커서 한 칸만 움직여도 프로그램이 몹시 굼뜬다. Select All 명령을 내리니 아예 프로그램이 뻗는 듯. Windows는 기본 제공하는 프로그램들 중 에디터가 몹시 부실하다는 게 이 자리에서도 다시 한 번 입증되었다. TextEdit(맥)나 gedit(리눅스)는 그렇지 않다.

사실, 위지윅이나 서식 지정 같은 기능이 전혀 없는 에디터라 해도, 유니코드에 따른 다국어를 제대로 지원하려 한다면 개발 난이도가 안드로메다 급으로 급상승한다. 바로 아랍· 히브리 지원 때문이다. Complex script 체계에서는 같은 글자라 해도 앞뒤에 무슨 글자가 있냐에 따라서 모양이 달라질 수 있고, 커서가 움직이는 단위와 문단을 나누는 기준이 시시각각 달라진다. 특수한 유니코드 제어 문자 처리도 해야 한다. 한 줄에 L2R 문자와 R2L 문자가 공존할 때 커서 위치는 어떻게 계산할 것이며, 게다가 세로쓰기라든가 자동 줄바꿈 옵션과의 연계는 어떻게 할 것인가? -_-

Uniscribe라는 API가 있다지만 그게 다루는 각종 개념을 공부하는 것부터가 쉬운 일이 아니다. 사실 저런 문자의 처리는 심지어 전문적인 상업용 워드 프로세서인 아래아한글조차도 2005 버전이 돼서야 지원하기 시작했으며, 프로그래머용 에디터에서는 그리 필요하지도 않은 기능이다.

EditPlus는 지금 최신 버전은 어떤지 모르겠는데 3.1x대 버전을 살펴본 기억으로는 아랍어의 매끄러운 처리를 제대로 지원하지 않았었지 싶다. 엄밀히 말하자면, 내부 문자 단위 크기만 ansi에서 wide char로 바꾼다고 해서 완벽한 유니코드 지원이 되는 건 아니다. 비록 화면으로 보기 좋게 찍히지만 않을 뿐, 정보 손실은 없겠지만 말이다.

그래서 <날개셋> 편집기는 복잡한 다국어 글꼴 처리 쪽은 아예 깨끗하게 접고(무시하고/포기하고)-_- 신경을 안 쓴다. 입력이라는 분야에만 초점을 맞춰 그쪽의 전문성만을 유지하며 개발되고 있다. 오히려 아랍· 히브리 문자는 깔끔하게 깨진 문자로 메모리 순서대로 단순하게 표시해 주니, 각 글자의 코드 포인트를 확인할 일이 있을 때는 유용하기도 하다. -_-

이렇듯, 텍스트 에디터를 하나 만들더라도 프로그래머용 기능 특화냐, 아니면 입력기와 유니코드 글꼴 쪽으로 특화냐 같은 개발 패러다임이 나뉠 수 있다. <날개셋> 편집기는 TSF 지원 같은 입력기 특화이고, 정확히 말하면 여타 어느 프로그램도 시도한 적이 없는 ‘한글 입력’ 특화이다. 하지만 글꼴 쪽의 전문적인 지원은 없다. 또한, Syntax highlighting기능조차도 없을 정도로 프로그래머 특화는 아니지만, 그래도 다양한 자동화 기능을 염두에 둔 텍스트 필터도 제공하기 때문에 전문 기능이 아주 없는 건 또 아니다. 일종의 패러다임 짬뽕인 것 같다.

Posted by 사무엘

1.
겨울방학도 이렇게 끝이 보인다.
본인이 이번 방학 때 이뤄낸 가장 뜻 깊은 성과를 둘 꼽자면 하나는 <날개셋> 한글 입력기 6.5이고, 다른 하나는 HFT(아래아한글 전용 글꼴) 해킹 성공이다.

저 글꼴들을 MS 오피스 제품에서도 쓰고 PDF도 자유롭게 만들고, 무엇보다도 화면에 anti-alias가 된 부드러운 모습으로 보니 너무 좋다.. 근성의 reverse engineering 오덕질을 통해서 이뤄 낸 성과. ㅋㅋ 새로운 글꼴로 아무 글이나 마구마구 써 보고 싶다.

또한, 날개셋 6.5 버전은 아직까지도 프로그램을 크게 고친 부분이 없을 정도로 역대 최고로 손꼽히는 안정성과 완성도로 잘 만들어졌다. 대단히 만족스럽다. 그래서 당분간 안심하고 완전히 새로운 기능 연구와 논문 준비 등에 전념할 수 있을 것 같다.

2.
윈도우 7은 콘솔(명령창)에서 세벌식을 쓰면 '다다.' 이렇게 한글이 덧나는 버그가 있다. 왜 SP1에서도 안 고쳐진 걸까? 예전에도 언급한 적이 있지만, 이런 건 두고두고 디스를 좀 해 줘야 된다.
윈도우 운영체제는 NT 계열도 꼭 이런 이상한 버그가 역사적으로 하나씩 있었다.

과거 2000은 256색으로 들어갔다가 돌아오면 군청색 제목 표시줄의 색깔이 옅어지는 버그를 유일하게 갖고 있어서 SP4에서까지 안 고쳐졌고,
XP는 테마를 저장했다가 불러오면 Luna 모드에서도 메뉴가 클래식 모드처럼 표시되어 색깔이 이상해지는 버그가 있는데 역시 SP3에서까지 안 고쳐지고 저렇게 끝났다.

이런 이유로 인해 본인은 한글 IME 개발과 관련하여 까탈스럽고 안 좋은 추억 때문에 남들이 7 좋아하는 것만치 7을 좋아하지는 않으며, 남들이 비스타 싫어하는 것만치 비스타를 싫어하지도 않는다. -_-;; 뭐, 비스타도 희한한 버그 의심 증상이 하나 있긴 했으나, SP1에서 곧바로 고쳐짐.

3.
<날개셋> 편집기는 txt 확장자를 자기 프로그램으로 연결한다거나 하지는 않는다.
그렇기 때문에 이렇게만 놔 둬서는 윈도우 7의 jump list를 활용하지 못한다. (윈7 사용자 중에 jump list가 뭔지 모르는 분은 없으리라 생각되지만, 어쨌든 모른다면 검색 요망)

탐색기에서 txt 파일을 우클릭하여 '연결 프로그램 선택 → 찾아보기' 등을 골라서 <날개셋> 편집기를 한 번이라도 지정한 뒤(꼭, 기본 연결을 시켜 놓을 필요는 없고 이렇게만이라도), 나중에 <날개셋> 편집기의 열기 대화상자로 txt 파일을 열고 나면 그건 앞으로 jump list 에 등재되게 된다.

jump list를 좀 더 창의적으로 활용하면, 편집기는 당장 저런 기본 용도만으로도 충분할 것이고(최근 파일 열기),
변환기는 클립보드 변환 같은 자주 사용할 만한 task를 등록해 놓을 수 있겠으며,
입력 패드는 자주 쓰는 보조 입력 도구를 실행과 동시에 바로 꺼내 놓게 할 수 있겠는데 더 자세한 활용법에 대해서는 좀 더 시간을 두고 고민해 봐야겠다.

4.
얼마 전엔 드디어 <날개셋> 한글 입력기 프로젝트를 비주얼 C++ 2010용으로 정식으로 포팅해서 빌드해 봤다. 특이사항으로는,

- 사소한 컴파일 에러가 있었으나, 더 깔끔하고 분명한 코드를 만드는 데 도움이 되는 에러였으며 쉽게 잡았다.
- VS 2010의 빌드 시스템은 $(TargetPath) 변수의 값을 예전과는 다른 방식으로 부여하는 듯하다. 그래서 이걸 조정하는 노가다를 매 프로젝트들마다 좀 해야 했다.

이것 외엔 딱히 트러블이 없었으니 무리 없이 잘 갈아탔다.

동일한 옵션으로 빌드했지만 x86 바이너리(32비트)들은 VS 2008과 비교했을 때 크기가 살짝 더 커졌고, x64 바이너리(64비트)들은 살짝 더 줄어들었다.
같은 코드를 빌드했을 때 바이너리 크기가 조금씩 더 커지는 건, VC6 이래로 개발툴이 업데이트되면서 비교적 일관되게 관찰되는 추세였다. 최적화가 인라이닝 등 코드 크기를 더 키우는 쪽으로 행해져서 그런 것 같다.

비주얼 C++ 2010은 C/C++ 언어도 빌드 중에 'Linking...'이라는 말이 안 뜨고 generating code...에 링킹이 포함되는 듯하다.
똑똑한 인텔리센스는 부러운 점이긴 하다만, 너무 커진 덩치, 이질감이 생긴 GUI와 도움말 시스템 때문에 2010은 개인적으로 언제쯤 도입하게 될지 모르겠다. 다만, 리소스 에디터가 드디어 윈도우 비스타의 PNG 내장 아이콘(256*256)까지 제대로 표시해 주는 점은 마음에 든다.

5.
내 경험상 윈7은 USB 메모리(스틱 or 외장 하드) 매체의 제거를 예전 OS에 비해 더 관대하게, 더 빨리 허용해 주는 것 같다. 해당 드라이브를 사용하는 프로그램들을 다 껐는데도 '사용 중이기 때문에 제거 못 함' 꼬장 때문에 할 수 없이 아예 OS를 로그오프하거나 아니면 그냥 강제로 매체를 제거해 버린 일이 거의 발생하지 않았다.

그리고 다른 얘기이다만, 윈도우 7은 Taskbar에 있는 각종 프로그램들 아이콘과 시스템 트레이의 아이콘을 드래그하여 마음대로 순서를 바꿀 수 있는 게 무척 인상적이다.
7에서 새로 바뀐 작업 표시줄은, 실행 중인 프로그램과(동일 프로그램이 중복 실행된 것 포함) 그렇지 않은 프로그램의 구분이 잘 되아 보이는 걸 개인적으론 안 좋게 생각했었다. 그러나 한동안 써 보니까 이게 그럭저럭 나쁘지 않은 디자인이라는 생각이 든다.

무엇보다도, 창을 몇 개씩 띄워 놔도 많이 띄웠다는 느낌이 심리적으로 안 드는 게 인상적임.
옛날에 윈9x의 전통적인 시작 메뉴 시절엔, 컴을 몇 년 쓰면서 수십 종류의 프로그램들을 설치하고 나니까 '프로그램' 메뉴 옆으로 프로그램 리스트가 두 칼럼 이상씩 차지하는 크고 아름다운 면적으로 주렁주렁 달렸던 거 기억하는가?

또한 인터넷 서핑하다가 브라우저 창이 열몇 개씩 넘어가니까 작업 표시줄 모습이 가히 가관으로 바뀌던 것도 기억하시는지? 윈도우 7은 복잡도를 제어하는 디자인에 무척 신경을 썼다..

6. 윈도우 비스타와 7 모두, 로그인 화면에서 암호를 입력하고 나면, 암호가 맞든 틀리든 일단 Welcome부터 출력하면서 설레발을 치다가 그 뒤에 암호가 틀렸으면 사용자 진입을 거부한다. “안 돼! / 돼!”도 아니고 츤데레도 아니고 이건 도대체 무슨 디자인일까?? -_-;;
암호가 맞을 때만 Welcome을 출력하게 개선되면 좋겠다.

7.
윈도우 9x는 프로그램을 조심해서 짜는 데에 도움을 준다.
NT 계열에서는 해제했던 메모리를 중복 해제하거나, 자원을 반납· 해제하는 걸 깜빡하는 식으로 대충 대충 짜도 당장 티가 안 나며 그냥 넘어간다. 그러나 9x에서 그랬다간 얼마 못 가 시스템 자원이 바닥난다거나 바로 뻗어 버리기 때문에, 이런 차이 덕분에 프로그램을 윈도우 9x에서 테스트하다가 버그를 발견하여 구조적인 문제를 해결한 경우가 지금까지 종종 있다.

아마 <날개셋> 한글 입력기도 한 2~3년 동안 윈9x에서 테스트를 안 한 채 개발을 계속하다가 버전이 1.0쯤 올라간 뒤에 다시 윈9x용으로 테스트하면, 여기저기서 원인을 알 수 없는 버그가 자꾸 튀어나와서 단순히 유니코드 API layer를 쓰는 것만으로는 윈9x를 결코 다시 지원할 수 없는 수준에 이를 것이다.
지금 <날개셋> 한글 입력기 소스가, 비록 같은 C++언어이지만 비주얼 C++ 6.0으로는 도저히 개발을 계속할 수 없는 이질적인 단계에 도달한 것처럼 말이다(각종 문법 차이 때문).

Posted by 사무엘