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

바탕체, 명조라고 불리는 한글 서체는 우리가 책의 본문에서 수십 년 동안 무수히 접해 온 친숙한 글꼴이다. 요즘이야 맑은 고딕, 함초롬바탕, 나눔명조 같은 여러 본문용 글꼴 때문에 존재감이 작아지긴 했지만, 그래도 화면보다 더 보수적인 출판물에서는 어떤 형태로든(신명, 윤디자인, 산돌 등) 오리지널 명조가 여전히 본좌이다.

명조도 다 같은 명조가 아니다. 모니터나 프린터의 해상도가 낮고 컴퓨터의 메모리가 부족하던 시절에는 획 모서리의 세리프만 어설프게 흉내 내고 전반적인 자형은 굉장히 투박하고 엉성한 야메 명조밖에 볼 수 없었다. 그런 한계가 없어지면서 디자이너의 아날로그 원도와 별 차이 없는 미려한 명조체를 볼 수 있게 됐다.

1. 한글

PC에서는 아래아한글 2.x(전문용)와 Windows 95를 통해 한양 시스템 신명조가 가장 널리 퍼졌었다.
1993년에는 아래아한글 2.1이 출시되었는데, 이때는 한양 시스템뿐만 아니라 휴먼 컴퓨터에서 개발한 서체들이 대거 도입되었다. 그 중 '휴먼옛체'는 워낙 개성 넘치고 큰 인기를 끌었던 서체이며..

휴먼샘체, 팸체, 안상수체처럼 한글에 가변폭 글꼴이 등장한 것도 굉장히 파격적이었다. 1990년대에는 안상수체 같은 글꼴이 꽤 참신한 미래지향(?) 서체라고 각광받아서 간판이나 책 제목에 종종 쓰이곤 했다.
이런 것들을 PC에서 저렴한 가격으로 최초로 선보였던 아래아한글은 실로 대단한 일을 해냈었다. 비록 그 시절 물가로 거의 30만 원에 육박했던 전문용 에디션 한정이었지만 말이다.

이런 서체들에 비해, '휴먼명조, 휴먼고딕'은 아무래도 기존의 신명조, 중고딕(한양 서체)과 외관상 거의 분간이 안 되니 존재감이 미미했다. 그래도 한양 서체와 휴먼 서체는 완전히 똑같지는 않았으며, 미세하게 차이점이 있었다.

굳이 따지자면 휴먼명조가 한양 신명조보다 '약간 덜' 미려하고 완성도가 낮았다. 하지만 어차피 깨알같은 본문용 글자의 크기와 해상도에서 그 차이는 일반인에게 거의 분간되지 않는 미미한 수준이었다.
그러면서 휴먼명조는 그 대신 크기가 더 작고 래스터라이즈 부담이 더 적으며 저해상도 출력에도 더 최적화돼 있었다. 그래서 위의 그림에서도 작은 크기에서 휴먼명조의 '명, 조, 맥' 같은 글자가 한양보다 미세하게나마 더 깔끔하고 획이 균일하다.

애초에 한양 신명조는 한 글자씩 일일이 그린 완성형으로 2350자밖에 표현할 수 없는 반면, 휴먼명조는 조합형 구조여서 한글 11172자 전체를 표현할 수 있었다. 똠 햏 뷁 같은 글자를 표현하려면 싫어도 휴먼명조를 써야 했다.
이 정도면 그 당시에 휴먼명조의 존재가 충분히 가치가 있었을 것이다. 휴먼명조만 해도 Windows 3.1 시절의 투박한 바탕체(큐닉스..)에 비하면 훨씬 더 미려하고 외형과 성능을 모두 잡았었다.

그런데 1994년의 딱 아래아한글 2.5 (+ 어쩌면 그 다음 3.0까지도)에서는 어찌된 영문인지 한양 신명조가 아예 빠져 버리고, '신명조'를 고르건 '휴먼명조'를 고르건 무조건 '휴먼명조'가 선택되곤 했다. 즉, 목록상으로는 두 글꼴이 모두 있지만 둘의 차이는 나지 않는 것이다.

둘은 외형도 비슷하고 모든 글자들의 폭도 어차피 동일하니 일반인들이야 이런 일이 있었다는 걸 모를 것이다. 그 시절에 왜 그랬는지는 지금도 의문이다.
그러다가 나중에 한양 신명조와 휴먼명조는 다시 구분이 생겨서 오늘에 이르고 있다. 단지, 한양 신명조가 잠시 누락된 적이 있었던 것은 본인의 기억에 확실하게 남아 있는 역사 팩트이다....라고 썼는데,

오, 인터넷을 뒤져 보니 물증이 있다.
아래아한글 2.5의 예제 문서를 열어 놓은 스크린샷이 굴러다니는데, 저 때는 아예 대놓고 '휴먼명조 = 신명조'라고 쓰여 있다! 내 기억이 맞았다.

2. 영문

신명조에는 한글뿐만 아니라 그와 어울리는 영문 서체도 있다. 아래아한글에서 신명조, 그리고 Windows가 깔린 컴퓨터에서 '바탕'만 고르면 볼 수 있는 그 익숙한 서체 말이다.

그런데 얘는 미국 같은 영어권 국가에서 즐겨 쓰이는 서체는 아닌 것 같다. 걔네들은 책 본문은 Times Roman이 압도적인 본좌이며, 거기에다 Bookman, Century, Palantino (Book antiqua와 아주 비슷)가 가끔 꼽사리로 끼는 정도다. 그럼 '영문 신명조'는 원조가 무엇일까?

본인이 실물을 직접 보지는 못했지만 과거에 미국에서 여권을 발급받으면 이렇게.. “미합중국 여권만 있으면 (지구상에 못 가는 곳이 없고) 세계가 몽땅 님하의 것입니다!”라는 캐간지 안내문이 딸려 나왔다.
그런데 저렇게 천조국의 위상을 자랑하는 문구의 서체가 통상적인 유럽풍이 전혀 아니고 완전 빼박 한국 신명조 바탕인 적이 있다는 게 난 너무 신기했다. 바로 저거 말이다. 기울여 쓴 게 이탤릭도 아니고 오블리크다.. 설마 진짜 '바탕'을 써서 인쇄한 걸까? (지금은 딴 서체로 바뀐 듯함.)

그리고 한 1990년대 초반까지 옛날 미국 컴퓨터 잡지 같은 출판물을 보면 이런 신명조 풍의 서체를 생각보다 자주 볼 수 있었다.
본문 기사보다는 저렇게 광고 문구에 더 많았던 것 같다. 위의 그림은 잡지 제목은 기억 안 나고 워드퍼펙트가 Windows용으로 처음 출시됐다는 광고이니 시기가 대충 짐작이 될 것이다.

영미권에도 저런 서체가 분명 있긴 했다는 것이다. 그러니 저게 한글 신명조와 pair가 되기도 했고 말이다.
저건 누가 만든 무슨 이름의 서체일까? 본인은 아직 정보가 없고 궁금하다.
그 흔해빠진 명조 하나 갖고도 얘기할 게 생각보다 많이 있었던 셈이다.

Posted by 사무엘

※ 셸 프로그램

명령 프롬프트 하나만 달랑 떠 있는 게 아니라 최소한의 GUI를 갖춘 컴퓨터 운영체제에는 셸이라는 게 존재하며, 그 셸을 구동하는 역할을 하는 프로그램이 있다. 그것이 맥 OS는 Finder이고, 윈도우는 95 버전 이래로 Explorer(탐색기)가 셸 역할을 하고 있다.
리눅스는 저 두 상업용 OS만치 셸과 커널이 일심동체인 형태가 아니기 때문에, 딱 떨어지는 단일 셸 브랜드가 없다.

95 이전 3.x 시절에 윈도우 운영체제의 셸은 도스 계열과 NT 계열 모두 그 이름도 유명한 '프로그램 관리자'(ProgMan.exe)라는 MDI 프로그램이었다. 알록달록한 32*32 크기의 16색 프로그램 아이콘들은 초등학생이던 본인에게 굉장히 아름다운 기억으로 남아 있다.

하지만 잘 알다시피 프로그램 관리자는 운영체제의 셸로서는 그리 잘 만들어진 프로그램이 아니었다. 기능이 무척 빈약하고 이것 자체도 여러 프로그램들 중 하나일 뿐, 운영체제 전체를 아우른다는 느낌을 사용자에게 못 줬다. 그룹 안에 다단계 그룹도 못 만들었고..-_-;;
또한 범용적인 파일 관리 유틸리티 기능이 전무했기 때문에 이건 또 '파일 관리자'라는 별도의 프로그램을 통해서 해야만 했다.

게다가 윈도우는 win.ini라는 환경 설정 파일에서 [boot] 섹션에 있는 shell=progman.exe라는 문장을 다른 것으로 고치면, 전통적인 프로그램 관리자 대신에 다른 것으로 셸 프로그램을 손쉽게 대체할 수 있었다.

그래서 윈도우 3.x는 프로그램 관리자를 대체하는 별도의 셸 유틸리티가 존재하기도 했다. 시작 메뉴, 내 컴퓨터, 탐색기 등을 통해 운영체제의 셸로서 explorer.exe의 지위가 확고해진 오늘날에는 이것은 꽤나 상상하기 힘든 모습이다.

당장 떠오르는 건 20여 년 전에 명성을 떨쳤던 Norton Desktop이라는 프로그램이다. 그 당시 도스용 노턴 유틸리티는 버전이 6~7 사이였고 노턴 커맨더라는 도스용 셸도 현역이었는데, 그 회사에서는 한편으로 윈도우용으로도 그런 걸출한 프로그램을 만들었다.

노턴 데스크탑은 화면 보호기도 자체적으로 운영하고 모든 프로그램들의 시스템 메뉴에다 특수한 기능을 추가하기도 했으며, 독자적인 바탕 화면을 구동하면서 윈도우 3.x를 전반적으로 매킨토시와 비슷한 형태로 만들어 줬다. 16비트 윈도우는 오늘날의 운영체제보다는 한 프로그램이 시스템 전체에 영향을 끼치가 훨씬 더 쉽기도 했으니 말이다.

※ 한컴 셸과 윈도우용 아래아한글 초창기 버전

국내에서는 1990년대 중반에 한컴에서 '한컴 셸'이라는 프로그램을 개발한 적이 있다. 화면의 한쪽 귀퉁이에 여러 프로그램들의 아이콘이 나열되는 게 마치 오늘날 맥 OS의 Dock과 비슷했다. 이것으로 기존 프로그램 그룹/폴더에 접근이 가능하고 제어판이나 탐색기도 띄우고, 운영체제를 종료할 수도 있었기 때문에 이것만 있으면 다른 셸 프로그램이 필요하지 않았다.

사진은 아래아한글 3.0b 기준이지만, 내 기억으로 아래아한글 97에도 한컴 셸이 있었다. 윈도우 95/NT4의 셸에 더 친화적인 기능들이 추가되고 버튼들도 90년대 말의 유행이던 flat 스타일로 바뀌었다. (마우스 포인터가 가리키고 있는 버튼에만 3D 테두리가 얇게 생기는 그 형태)

그런데 이 역시 97 초기판에만 있었고, 8· 15 특별판(1998)이나 국제판/기능 강화판(1999)에서는 사라졌다. 윈도우 9x 이래로 탐색기 셸 자체가 기능이 굉장히 강력해졌기 때문에 그때부터는 별도의 셸 유틸리티에 대한 수요와 의미가 없어졌기 때문일 것이다. 특히 IE4와 통합을 이루면서 윈도우 운영체제의 셸은 완전히 환골탈태를 했으니 말이다.

아마 아래아한글 3.0b나 기껏해야 96까지만 해당일 것이다.
그 당시 이 프로그램에는 한컴 셸 동반용으로 추정되는 나침반, 시계, 계산기처럼 워드 프로세서와 직접적인 관계가 없는 액세서리 프로그램도 포함돼 있었다. 지금의 운영체제에서는 제대로 실행이 안 되는 듯한데, 예전에 분명히 돌려 봤던 기억이 난다.

시간이 흐르면서 그런 것들은 거의 다 역사 속으로 사라졌다. 그나마 21세기에까지 장수한 보조 유틸리티는 아래아한글 97과 함께 도입된 '한컴 쪽지'가 유일하다. 그것도 윈도우 7부터는 스티커 메모라는 대체 프로그램이 운영체제 차원에서 생겼으니 필요가 없어진 상태.

옛날에 윈도우용 아래아한글 3.0은 Windows에서도 도도하게 완전 독자적인 GUI와 독자적인 GUI 글꼴, 독자적인 문자 입출력 체계를 쓴 데다, 기술적으로도 Win32s + 별도의 메모리 서버까지 요구하는 등 군계일학 유아독존 포스가 압권이었다.

도스용 아래아한글만 만들던 개발팀이 단기간에 프로그래밍 공부를 얼마나 해야 윈도우 운영체제의 구조를 완전히 마스터하여 방대한 도스용 프로그램을 윈도우용으로 그것도 그런 기술 수준으로 포팅할 수 있었을까? 혹시 공밀레?

이때는 한컴이 금방이라도 독자적인 운영체제를 새로 만들기라도 할 것처럼 보였다. 사실, 비슷한 타이밍 때 나왔던 큰사람의 이야기 7.0 도스용도 도움말을 잘 뒤져 보면 개발팀이 한국형 32비트 운영체제를 자체 개발하겠다는 포부를 밝힌 대목이 있었다. 지금 생각하면 그때 사람들이 참 순진/순수했던 것 같다.. ^^

물론, 윈도우용이 처음 나왔던 3.0, 그리고 에디팅 엔진을 다 갈아엎었던 워디안 때 아래아한글이 버그 때문에 정말 욕을 많이 얻어먹은 건 사실이다. 까일 건 까여야 마땅하지만 그 첫 삽을 뜨기가 얼마나 힘들고 어려웠을지 본인은 프로그래머로서 이해는 한다.

아, 아래아한글 3.0x가 사용했던 그 특유의 GUI 디자인은 이미 아시는 분도 있겠지만 NeXTSTEP에서 따 온 것이다. 아이폰이 나오기 훨씬 전부터 아래아한글이 나름 스티브 잡스 진영에서 만든 디자인을 수용한 적이 있다는 뜻 되겠다. 다만, 메뉴에 카테고리를 구분하는 separator가 없던 것은 좋은 디자인이 아닌 것 같다.

그리고 대화상자의 GUI 컨트롤 중엔, 콤보 상자와 용도가 비슷하지만 콤보 상자보다 더 static하면서 개수가 그리 많지 않은 컨텐츠 중 하나를 선택할 수 있는 '콤보 버튼'이 있다. 예를 들어 글꼴 리스트는 사용자의 컴퓨터에 설치된 글꼴이 무엇이냐에 따라서 dynamic하게 바뀔 수 있지만, 워드 프로세서가 제공하는 문단 정렬 방식 '왼쪽, 중앙, 오른쪽, 혼합' 같은 것은 수가 그리 많지 않으면서 내용이 절대 고정불변이지 않은가. 그런 것을 선택할 수 있다.

또한 스크롤 막대의 좌우, 상하 버튼이 한데 붙어 있는 것도 이 GUI의 특징 중 하나이다.

※ 여담

하긴, 도스 시절에도 셸 유틸리티가 당연히 있었다. 이때의 셸은 윈도우처럼 초보자들을 위한 GUI 기능을 강화한 놈, 아니면 파일 관리 유틸리티에 더 특화된 놈으로 나뉘었다. 후자에 속하는 것이 바로 노턴 커맨더나 MDIR 같은 유명한 프로그램임.

도스 시절에는 아무래도 컴에 대한 접근성이 지금보다는 다소 떨어졌으며, 그래픽 셸을 찾아 쓸 정도의 사람이라면 이미 그래픽 셸이 필요치 않은 파워 유저였다. 그렇기 때문에 도스용 셸 유틸은 GUI보다는 아무래도 매니악한 파일 관리 기능 특화로 더 가는 경향이 있었다.

사실, MS-DOS 자체도 한 4.0부턴가 5.0부터 도스 셸이라는 잉여에 가까운 파일 관리 유틸리티가 있었다. 그냥 밋밋한 UI에 기능도 평범한 편이지만 나름 드래그 드롭 기능이 있었으며, 그리고 하드디스크에 존재하는 모든 파일들을 한 리스트로 뽑아 주는 기능은 윈도우 파일 관리자에도 없고 이놈만의 전매특허였다. 물론, 이건 하드디스크 전체에 존재하는 파일 수가 수천~수만 정도에 불과했던 옛날이니까 가능했던 일이다.

이런 맥락을 이어받아 오늘날의 GUI 시대에도, 비록 운영체제의 기본 셸을 대체하려는 프로그램은 맥이 끊어졌지만, 전문 파일 관리 유틸리티는 건재하다. 토탈 커맨더라든가 넥서스 파일 같은 프로그램이 있다. 여러 단축키를 통해 기본 셸 프로그램보다 원하는 프로그램이나 파일, 폴더에 훨씬 더 빨리 접근할 수 있고, 한 프로그램 안에서 압축 파일도 쉽게 다루고 FTP 연계도 되는 편리한 기능에 대한 수요가 없지 않기 때문이다.

끝으로, 옛날 글들을 보면 알 수 있듯, 난 한동안은 shell을 '쉘'이라고 표기해 왔다. 도스 시절부터 프로그램이나 PC 잡지들이 다 그렇게 표기했기 때문이다. 그때 쉘 대신 셸을 쓴 프로그램은 한글 MS-DOS가 제공하던 '도스 셸'밖에 없었다. 진짜 그거 딱 하나밖에 못 봤다.
그랬는데, 외래어 표기법상 '셸'이 맞다고 하니 이 글부터 시작해서 앞으로는 셸을 쓰도록 하겠다. 틀렸으면 고치면 되지. ㅎㅎ

Posted by 사무엘

오랜만에 <날개셋> 한글 입력기의 새 버전 소식을 전하게 된 것을 기쁘게 생각한다.
6.51 다음으로 6.7! 나의 대학원 석사 졸업 기념작이다.
나의 대학 학부 졸업 기념작은 까마득한 옛날인 2005년 여름에 나온 3.41이고,
4년 전 여름에 나온 5.0은 병특 만료 기념작이다.
작년에 6.2가 나온 뒤 거의 정확히 1년 만에 버전이 0.5만치 올라가게 되었다.

이번 버전은 비주얼 C++ 2010으로 개발된 첫 버전이다. 5.5부터 지난 6.51까지는 약 3년 동안 2008로 개발됐다.
더 옛날의 2.5부터 5.31까지는 거의 6년 동안 2003을 썼고 말이다. 그에 반해 VC++ 2005는 처음에 64비트 에디션을 빌드할 때만 잠깐 썼고 그다지 즐겨 사용되지 않았다.

버전 번호에 7이라는 숫자가 들어가는 것은 지난 12년간의 <날개셋> 한글 입력기의 개발 역사상 최초이다. 물론 6.x를 졸업하고 아예 메이저 버전이 7로 진입할 날도 얼마 안 남았고 말이다.
6.7은 여느 역대 버전들과 마찬가지로 다방면의 기능 추가와 개선을 거쳤다. 하지만 이번에도 시간과 여유의 부족으로 인해 원하는 기능, 넣고 싶었던 기능들을 모두 충분히 넣지 못했다. 그렇기 때문에 6.7까지는 안 하고 6.65, 심지어 6.66-_-으로 번호를 정하는 것도 이론적으로 충분히 가능하나, 국민 정서를 감안하여 그러지는 않았다.

한동안 <날개셋> 한글 입력기의 API에 큰 변화가 없었기 때문에 타자연습 3.3은 입력기 6.2부터 6.51까지 API 호환이 지켜졌으나, 이번 6.7에서는 클래스 가상 함수 한 군데의 프로토타입이 바뀌는 바람에 정말 어쩔 수 없이 API 호환이 깨지게 되었다.

타자연습은 1년 전이나 지금이나 바뀐 건 없고, 입력기 6.7의 API를 기준으로 재빌드한 프로그램만 다시 올렸다.
물론, 이제는 API 호환이 안 되는 버전의 <날개셋> 입력기 외부 모듈과 타자연습이 서로 같이 실행되어도 충돌이 없기 때문에, 굳이 타자연습에서 입력기 6.7에 새로 추가된 기능을 꼭 써서 타자 연습을 해야 할 분이 아니라면, 이미 설치된 타자연습 3.3을 또 재설치해야 할 필요는 없다.

이번 6.7에서 내세울 만한 변화는 다음과 같다.

1. 편집기의 에디팅 엔진 최적화

비록 눈에 당장 차이가 느껴지지는 않는 변화이긴 하나, 새 버전에서는 에디팅 엔진의 최적화가 최후 종결자 지점에 이르렀다.
텍스트의 여러 군데가 동시다발적으로 바뀌어서 구간별로 어디는 다시 그려져야 하고, 어디는 단순히 위로 몇 줄 스크롤하면 되고, 더 아랫부분은 반대로 아래로 스크롤되어야 할 때... O(n^2) 복잡도까지 감수하면서 구간별로 모든 가짓수를 100% 정확하게 파악하여 동작하게 했다. (물론, n이 너무 커지면 골치 아프게 그런 것 따질 필요 없이 그냥 화면 전체를 다시 그려 버리면 된다)

예전에는 그냥 최악의 상황을 가정하고 무조건 화면을 다시 그리게 하던 것이 지난 6.2 버전이던가 그때쯤에 크게 개선되었다. 그러나 그것도 동작이 지금 정도로 정교하지는 못했으며, 나중에 다시 생각해 보니 논리 자체에도 원천적으로 결함이 있어서 아주 특수한 상황에서는 여전히 화면 잔상이 남는 버그까지 있었다.

그 점이 찝찝했었는데 이번 버전에서는 드디어 작정하고 매달린 끝에 완전히 끝장을 내고 말았다. 만세! 새로운 기능 구현도, 단순 리팩터링도 아니고 최적화 작업을 끝냈을 때의 홀가분한 기분은 직접 구현해 본 사람만이 느낄 수 있을 것이다. 역시 좋은 프로그래머란, 모든 경우의 수를 논리적으로 잘 따지는 사람임을 느꼈다.

텍스트 에디터를 만들면서 이런 식으로 구간과 구간 사이의 여러 변화들을 한데 합성하는 알고리즘을 구현하는 게 굉장히 힘들었다. <날개셋> 편집기는 한글에만 초점을 맞추려고 complex script는커녕 글씨 크기 변경도 안 되고 가변폭 글꼴조차 지원 안 하는 아주 제한된 에디팅 엔진을 의도적으로 고수하고 있지만, 그 정도를 만드는 데도 지금까지 의외로 복잡하고 어려운 알고리즘이 제법 들어갔다. undo/redo를 관리하는 것도 그렇고.

2. 한글 입력 오토마타 차원에서의 기능 추가

이 달 초에 블로그 글을 통해 먼저 소개한 바 있는 종성 지향 두벌식은, 예전에는 없던 완전히 새로운 개념이 추가된 것이다. 같은 두벌식이라도 음절 경계에서 자음을 초성으로 볼 것인가, 종성으로 볼 것인가 하는 것을 이제 사용자가 직접 지정하는 것은, 한글 입력 전문 프로그램으로서 매우 중요한 기능이 아닐 수 없다.
종성 지향 두벌식과 맞물려 돌아가는 BKSP 옵션, 특수 키, 타수 복원 알고리즘 등등도 다 일관성 있게 동작하도록 로직의 수정과 보강이 이뤄졌음은 두 말할 나위가 없다.

그리고 오토마타에서는 현재 입력된 날개셋문자가 두벌식인지(종성 지향 포함) 세벌식인지를 나타내는 변수를 추가하여, 한 오토마타가 벌식에 따라 다르게 동작할 수도 있게 했다.

사실 이 두 기능은 내 학위 논문에도 들어가야 했을 아이디어인데 논문 학기가 다 끝난 뒤에야 생각이 나고 구현된 것이 좀 아쉽다. ^^;;

3. 단어 단위 한자 변환

<날개셋> 한글 입력기의 아주 오랜 숙원이 이번 버전에서 드디어 부분적으로나마 성취되었다. 만세!
드디어 '대한민국'에서 '국'을 조합 중이거나 '국'의 뒤에다 커서를 두고 한자 키를 누르면 단어를 한꺼번에 大韓民國로 바꿀 수 있다. 그리고 한자를 한글로 바꾸는 것도 최대 12글자까지 한꺼번에 할 수 있다.

이렇게 하기 위해서는 제어판의 '편집기 계층'에서 '단어 단위 한자 변환' 옵션을 켜 주면 된다. 그리고 이 기능은 아무데서나 쓸 수 있는 건 아니고, 자체 편집기나 TSF A급 프로그램(워드패드, MS 워드 등 몇몇)에서만 가능하다.

단, 이것은 아주 초보적인 수준으로만 구현된 것이기 때문에 한계도 적지 않다.
커서 바로 앞까지 끝나는 범위의 단어만 한자로 바꿀 수 있으며, 글자가 아닌 단어 영역에 대해서 블록 같은 시각적인 피드백이 없다.

그리고 이 단어 사전은 <날개셋> 한글 입력기가 자체적으로 갖추고 있는 게 아니다. MS 한글 IME의 한자 사전을 빌려다 써서 동작한다. 그래서 내 프로그램으로 단어 단위 한자 변환을 하려면 윈도우 비스타/7의 한글 IME가 설치되어야 있어야 한다. 자체 사전이 아니므로 사용자 사전 등록 기능 같은 것도 없다.

이번 버전은 그냥 최소한의 노력으로 <날개셋> 한글 입력기도 이제 제한적으로나마 단어 단위 한자 변환이 가능하다는 걸 맛만 보여 준다는 데 의미가 있다. 그러나 이렇게만 해도 정말 신기하기 그지없다.

4. 그 밖의 사소한 변화들

- <날개셋> 한글 입력기의 외부 모듈은 설치하여 구동하고 나면 language bar에 예닐곱 개의 아이콘들이 주렁주렁 달리는 편이었는데, 이번 버전부터는 잉여력이 꽤 강한 전/반각 모드, 텍스트 필터(극소수의 TSF A급 프로그램에서만 사용 가능), 문자표는 제외하고 기본적으로 4개의 아이콘(한/영, 한자, 제어판, 보조 입력 도구)만 표시되게 바꿨다. 나머지 아이콘들은 별도의 명령을 내려서 사용자가 표시하도록 해야 표시된다.

이렇게 하니까 훨~씬 깔끔하고 좋다. 외부 모듈이 개발된 지도 벌써 7~8년째인데 왜 지금까지 이렇게 정리를 할 생각을 안 했나 모르겠다.

- 그리고 <날개셋> 편집기에서 외부 모듈을 사용하면서 편집기의 도구-옵션 명령으로 프로그램의 GUI 언어를 변경한 경우, 외부 모듈의 도구모음줄 아이콘의 툴팁이나 명칭도 해당 언어로 바뀌게 했다. 크게 의미 있는 변화는 아니지만 프로그램간의 일체성을 향상시킨 조치이다.

- 외부 모듈의 한자 변환 후보 선택 중에 Ctrl+C를 누르면 선택된 한자를 클립보드에다 복사가 되게 했고, Shift+엔터/번호를 누르면 한(韓) 형태로, 그리고 Ctrl+엔터/번호를 누르면 韓(한) 형태로 삽입이 되게 했다. 저 기능도 언젠가 넣어야 할 필요를 느끼고 있었는데 이렇게 하는 게 제일 좋을 것 같다.
필요는 발명을 낳는 법. 단어 단위 한자 변환과 연계하면 더욱 편리해진다. '대한민국(大韓民國)' 같은 문구를 한번에 바로 삽입할 수 있으니 말이다.

- '한글을 소리 나는 대로' 필터가 받침 ㄷ계열(ㄷ, ㅅ, ㅌ 등)+ㄹ을 지금까지 ㄹㄹ로 동화시키고 있었는데 이를 ㄴㄴ 계열로 수정했다. 그런데 한국어에서 저렇게 동화가 일어나는 경우가 전혀에 가깝게 없기 때문에 <날개셋> 3.0 이래로 이에 대한 문제를 제기할 일이 없었다.

- '한글 낱자 종류 변환' 필터에 호환용 한글 자모 4개 나열로부터 표준 한글 자모나 한글 글자마디를 만드는 변환 기능을 추가했다. 이것은 우리나라 표준 문자 코드에 명시되어 있는 스펙이기 때문에 도입했다. (거의 사문 전락 수준이 아닌가 의심되긴 하지만.)

- 굳이 나열하기에도 구차한 여러 버그 수정들은 덤. 사용자는 거의 접할 일이 없겠지만.
- 그리고 이번 버전부터 후원 안내문이 프로그램 설치 화면과 도움말 구석에 추가되었다.

5. 제공 자료들

새로 추가된 한글 입력 기능을 활용하여 두벌/세벌 판별 변수를 활용한 복벌식용 모아치기 오토마타, 그리고 맥 OS의 세벌식 자판이 예제로 추가되었다. 종성 지향 두벌식을 사용하여 고증을 100% 살린 MS 두벌식도 예제로 제공된다.
그리고 6.7의 새로운 기능으로만 가능한 건 아니지만, 아래아한글 97이 과거에 제공하던 세벌식 semi-모아치기 오토마타도 예제로 추가했다.

아래아한글 97을 기억하시는가? 아래아한글 2.0 기반의 에디팅 엔진과 3.0 기반의 파일 포맷, 그리고 한컴 2바이트 코드를 사용하던 마지막 버전임과 동시에, 당대로서는 가장 완성도가 높았고 1990년대 말과 2000년대 중반까지 전국적인 사랑을 받았던 명작 워드 프로세서이다.

그 아래아한글 97은 세벌식 글자판에서 우리나라의 소프트웨어 역사상 전무후무한 한글 입력 로직을 갖고 있었다.
초성만 가장 먼저 입력한 뒤엔, 그 후의 중성과 종성은 아무 순서대로나 입력하면 된다. 아래아한글 97의 오토마타를 <날개셋> 식으로 기술해 보면 다음과 같은데...

0 → A ? 1 : B|C ? 2 : 0
1 → A ? 1 : B|C ? 2 : 0
2 → B|C ? 2 : 0

수식이 정말 심하게 단순하다!
<날개셋>의 표준 모아치기 오토마타는 초성을 나중에 뒤늦게 입력하는 경우를 고려하는 것도 있기 때문에 0부터 3까지 4상태이다. 그러나 아래아한글은 초성 아니면 중성/종성으로만 딱 칼같이 나눠서 겨우 3상태이고 수식도 더 간결하다.
거기에다가 아래아한글의 전통인 조건부 / 키만(초성 입력 직후에만 ㅗ, 나머지 상황엔 / 그대로) 수식으로 넣어 주면 100% 정확한 아래아한글 스타일 세벌식이 완성된다.

Mac OS의 세벌식에 이어 아래아한글 97의 세벌식 입력 오토마타를 구현해 보니 스스로 생각해 봐도 재미있다. 다 똑같은 한글 입력 방식 같아도 실제로는 100% 똑같지가 않다.

내가 예전 글에서 썼듯이, <날개셋> 한글 입력기는 그야말로 한글 덕후들의 지적 욕구를 충족할 수 있는 프로그램, 한글 덕후의 마음의 고향 같은 프로그램을 표방하며 개발되고 있다. 그리고 이번 6.7은 그 이상향에 더욱 근접했다고 볼 수 있으며, 글을 다 써 놓고 보니까 마음이 바뀌는 듯. 이 정도면 6.51에서 6.7로 충분히 버전을 올릴 만도 하다는 생각이 든다. ^^

Posted by 사무엘

한글 입력기에 이어 다음은 글꼴 쪽 소식이다.

이게 과연 가능할까 나 자신도 장담할 수 없었는데 결국은 해냈다.
스크린샷의 프로그램은, 아래아한글 2.0 전문용에 들어있는 영문 신명조 HFT 파일을 읽어서 거기에 있는 글자를 찍은 모습이다.
TTF로 존재하지 않는 아래아한글만의 독창적인 글꼴--공한체나 휴먼옛체, 강낭콩 등--을 인증샷으로 보여야 더 재미가 있을 텐데, 아래아한글 2.0 시절에는 독창적인 글꼴이 아직 흔치 않았었다.

궁극의 오덕질의 승리.
뭐, 아예 압축 파일 포맷을 혼자 Reverse engineering만으로 알아낸 사람도 있는데, 이 정도 가지고 내가 딱히 RE의 귀재이거나 한 건 아니다.

아래아한글 2.0은 윤곽선 글꼴이 도입된 첫 버전이었고(무려 1992년 발매!), 지금의 아래아한글이 사용하는 '통합 글꼴' 포맷이 완전히 제정되기 전이었다. 글꼴 파일 내부에 아직 이름이나 제조사 같은 정보도 없고, 파일 포맷도 별도의 추상적인 계층이나 미래 확장 대비 공간이 전혀 없이 아주 아주 단순했다. 헥스 에디터로 딱 들여다보면, 이건 글자별 글립 데이터 오프셋 정보, 이건 글자별 폭(영문 가변폭 글꼴 기준) 이런 식으로 구간이 나뉘어 있겠다는 게 눈에 들어왔다. 구간을 나누는 데 성공한 것만으로도 최하 30% 이상은 성공이었다.

글립 데이터를 들여다보고 있으니, 처음 부분은 고정된 헤더인 듯하다. 그 지점 이후부터 가변 길이의 인스트럭션들이 나오는데(직선을 그어라, 곡선을 만들어라, 다음 폴리곤으로 넘어가라, 등의 그래픽 명령) 이건 알기가 쉽지 않았다.
그래서 가장 간단한 글자인 중고딕 . I L - _ (다 사각형 하나만 달랑 나오는-_-)가 어떻게 돼 있는지 분석하는 걸 시작으로, + = / : 을 이어 추적했다.

가장 마지막으로 원리를 알아 낸 건 물론 곡선 부분이다. 다행히 이 HFT는 트루타입(TTF)보다는 구조가 훨씬 더 단순했다. TTF 정도의 복잡도만 돼도 나 혼자서는 포맷을 못 알아냈을 것이다.
내가 이미 TTF 같은 더 복잡한 글꼴 파일 포맷의 구조에 대해 어느 정도 알고 있고, 그러니 뭐가 나올지 어느 정도 예상을 하고 있으며, HFT는 그보다 단순할 거라고 예상도 했기 때문에 해킹에 성공할 수 있었다.

다음 관심사는, 물론 아래아한글 2.1부터 지금까지 쓰이고 있는 통합 글꼴이다.
아래아한글 2.x 확장팩 글꼴들을 ttf로 바꿔서 윈도우 다른 프로그램에서도 쓰는 게 소원이다. -_-;;
언뜻 들여다본 바로는, 2.0하고는 인스트럭션들의 포맷이 살짝 다른 듯하다.

같은 한양 시스템 글꼴을 2.0 것과 통합 글꼴 것을 대조해 보면 분석이 훨씬 더 쉽겠지만, 안타깝게도 현재 아래아한글의 한양 시스템 hft 글꼴은 빡세게 암호화되어 있어서 분석을 할 수 없다. 파일 크기와 처리 성능으로 미뤄 보건대 내가 보기엔 압축은 아니고, 그냥 단순 암호화이다. HFT 중에서도 암호화가 안 된 글꼴만이 추후 분석 대상임.

아마 나는 아래아한글의 소스를 본 적이 전혀 없는 사람 중에서는,
글자 입출력과 관련하여 아래아한글이 사용하는 각종 데이터 파일의 구조를 우리나라에서 제일 잘 아는 사람일 것이다.
당장 <날개셋> 한글 입력기에 역대 아래아한글이 사용한 모든 custom 글쇠배열 파일을 읽어들이는 기능이 있으며,
바탕, 가는샘물, 필기는 도스용 아래아한글의 화면용 글꼴 파일을 추출한 것이다.

1월 10일 추가:
오늘 새벽. 통합 글꼴 HFT도 뚫는 데 성공. 단, 이건 내 혼자 힘만으로 한 건 아니다.
인증샷 대상 글꼴은 '신명 신명조'이다.

Posted by 사무엘

서식을 지원하지 않는 단순한 텍스트 에디터를 워드 프로세서로 발전시키려면 무슨 작업이 필요할까?
뭐니뭐니해도 글자마다 서식을 달리 지정할 수 있어야 한다. (서체, 속성, 크기, 색깔 등등)
그런데 그걸 구현하는 과정에서 개념적으로 굉장히 중요한 결정을 내려야 하는 게 있다. 바로, 장치 독립적인(device-independent) 레이아웃을 구현하는 것이다.

장치 독립이란, 표시 화면의 해상도(=확대 배율)와 관계없이 글자들의 비율과 위치가 일정하게 유지되는 걸 말한다. 쉽게 말해 위지윅(WYSIWYG)이다. 요즘 워드 프로세서에서는 필수인 이 기능을 지원하기란 장치 종속 레이아웃보다 훨씬 더 어렵다.
우리에게 잘 알려져 있는 장치 종속 레이아웃과 장치 독립 레이아웃의 예는 다음과 같다.

장치 종속적 레이아웃: 웹브라우저 화면. MS 엑셀. MS 워드의 웹/개요 모드, Draft/normal view. 워드패드
장치 독립적 레이아웃: MS 워드의 인쇄 모드(print layout) view. 아래아한글, Acrobat PDF, 그리고 모든 프로그램들의 '인쇄 미리보기 (print preview)'

차이를 아시겠는가?

WWW
iiiiiiiiiiiii

가변폭 글꼴로 두 줄에 W와 i를 비슷한 폭이 되는 개수로 찍은 뒤(당연히 i의 개수가 훨씬 더 많아짐),
화면 배율을 아주 작게 줄였다가 아주 크게 확대해 보라.
W와 i의 폭의 편차가 크면 장치 종속적인 레이아웃이고,
대체로 전반적인 배율은 잘 유지되지만 그 대신 작은 크기에서 i들끼리의 픽셀 간격이 들쭉날쭉하다면(저해상도에서 보정을 위해 어쩔 수 없이) 그건 장치 독립적인 레이아웃이다.

엑셀을 실무에서 오래 써 본 분들은 이미 아시겠지만, 엑셀은 심지어 Page layout view에서도 위지윅이 전혀 보장되지 않기 때문에 화면에서 보는 글자의 폭과 인쇄해서 보는 글자의 폭의 차이를 유의해야 한다.
화면으로 보기 좋게 글자수나 폭을 맞춰 놓은 것은 인쇄를 하거나 심지어 확대 배율만 바꿔 봐도 모조리 어긋나 버리기 때문이다.
편집 화면이 아니라 오로지 '화면 인쇄'만이 장치 독립성이 보장되는 결과를 보여준다.
엑셀은 대용량의 데이터를 수월하게 다루기 위해서, 성능상의 이유로 위지윅 편의는 희생한 셈이다.

요즘 워드 2007은 처음 시작했을 때 인쇄 모드 view로 시작하지만, 옛날, 한 97~2000 버전까지만 해도 print layout이 아니라 normal view가 기본 모드였다. 아래아한글은 비슷한 개념으로 '쪽윤곽' 옵션이란 게 있어서 둘의 차이는 화면에 용지의 여백이 나타나 보이는지의 여부가 고작이지만, 워드의 normal view는 print layout view보다 훨씬 더 이질감이 컸다. 그림이나 표 같은 틀이 제 위치에 표시되지 않고 다단(column)이나 세로쓰기 같은 건 아예 무시되었으니까...;; 그리고 근본적으로 normal view는 앞서 말했듯이 위지윅이 보장되지 않는다.

이런 view가 기본 mode였던 이유는 두말 할 나위도 없이.. normal view가 문서를 훨씬 덜 정교하게 대충 렌더링하기 때문에, 처리 속도가 훨씬 더 빠르기 때문이었다.
normal에서 신나게 긴 글을 편집하고 있다가 print layout으로 처음으로 모드를 바꾸면, 워드는 “페이지를 정돈하고 있습니다. 잠시 기다려 주십시오”라고 뜸을 들이곤 했다.

장치 독립적인 레이아웃에서는 여백이나 글자 크기 따위를 나타낼 때 픽셀이 아니라 어느 매체에서도 동일한 절대적인 단위가 쓰인다. 그래서 아래아한글이라든가 PDF 같은 문서 파일 포맷 스펙을 보면 그런 개념을 찾을 수 있으며, 아래아한글의 경우는 1/n 인치가 최소 단위였지 싶다.

운영체제 API는, 해상도가 서로 넘사벽급으로 다룬 모니터와 프린터를 모두 동일 코드만으로 수월하게 다루기 위해서 다양한 추상적인 좌표계와 확대 배율을 지원하며, WM_PAINT뿐만이 아니라 WM_PRINT 같은 (잘 알려지지 않은) 메시지도 제공하고 있다.
MFC가 OnPaint말고 OnDraw라는 화면· 프린터 통합 메소드를 제공하는 것 역시 다 이유가 있어서인 것이다
.
흠, 그러고 보니 나도 포스트스크립트나 '텍' 같은 전자 조판 언어를 공부하고 싶긴 한데, 접할 기회가 없구나.;;

Posted by 사무엘

※ 서울 3대 전철 회사들의 전동차에서 방영되는 동영상의 주된 테마

서울 메트로: 2005년부터 도입된 2호선 신형 차량을 주축으로 하여, 차내 동영상 방송 트렌드를 가장 주도적으로 이끌었다. 자기네가 전국에서 역사가 제일 긴 지하철 회사라는 걸 강조하면서 옛날 흑백 사진도 보여주고, 지금까지 수송 거리 n억 킬로미터, 수송 인원 n백억 명.. 같은 걸 자랑한다.
그리고 대국민 캠페인을 제일 열심히 한다. 무리해서 승차하지 말라, 내릴 사람은 전역에서 미리 내릴 준비를 하라, 두 줄로 서라 등.. 테러· 화재 시의 대처 요령 같은 걸 계속해서 방영한다. 이런 분위기는 오로지 서울 메트로 구간에서만 경험할 수 있다.

코레일: KTX를 운행하는 전국구 회사인 만큼, 철도 자체가 친환경 녹색 교통수단이라는 걸 귀가 따갑도록 강조한다. '서울에서 부산까지 KTX를 이용하면 나무 n그루를 심는 효과가 있습니다' 드립. 그러면서 가끔 철도 안전 캠페인도 틀어 준다. 컬러 모니터는 1호선 같은 주류 노선에서는 보기 힘든 편이며, 중앙선· 경춘선· 경의선· 광명 셔틀 같은 곳에서 더 쉽게 접할 수 있다.

도철(SMRT): 역사가 가장 짧고 구세대 LED 전광판을 가장 먼저 도입한(당대엔 이게 롤지나 플랩 표지판에 비해서 최신형이었음) 회사인 만큼, 컬러 모니터의 도입은 가장 늦다. 하지만 요즘 심심찮게 컬러 모니터로 시설이 교체되고 있는 중이다. 도철이 보여주는 건 맨날 자기네 기술력 자랑뿐이다. 자체 전동차 SR-001은 절대 빠지지 않으며, 음 사장님이 인건비 절감 고효율 경영을 위해 이런 기술을 개발하고 이런 시스템을 도입했다는 걸 홍보하느라 바쁘다.
도철은 과거에 지하철 벽 프로젝션 광고를 가장 먼저 시도했고, 심지어 주행 중 터널 홀로그램 광고라는 엽기적인 시스템도 도입했으며, 서울 3대 전철 회사 중 스크린도어를 가장 먼저 전구간 완성한 회사이기도 하다.

Excercise: 서울 1기 지하철(1~4호선)과 비교했을 때, 2기 지하철(5~8호선)에서 처음으로 도입된 시스템을 모두 고르시오.
(1) ATC 신호 시스템
(2) LED 전광판
(3) VVVF 인버터
(4) 1인 승무
(5) 직· 교류 겸용 전동차
(6) 콘크리트 노반
(7) 장대 레일

※ ABB? ABBA?

잘 알다시피 서울 지하철 5호선 전동차의 VVVF 인버터는 ABB라는 유럽계 회사(스웨덴)의 제품이다.
그런데 묘하게도 1970년대의 유명 팝송인 Dancing Queen을 부른 가수 그룹의 이름은 ABBA이고 이들의 국적은 스웨덴!
Dancing Queen과 서울 지하철과의 묘한 연결 고리가 생기는 게 느껴지지 않는가? ㄲㄲㄲㄲㄲㄲ

※ 아래아한글 2007

아래아한글 2007은 2006년 한글날에 출시된 후 2010년 3월에 차기작인 2010이 출시될 때까지 3년 반 가까이 지냈던 메이저 버전이다. 그렇다 보니, 두 버전 사이의 간극은 MS 오피스 2003과 2007의 간극에 맞먹는다(2003년 가을 ~ 2007년 초).
그 동안 2007은 업데이트가 굉장히 많이 뿌려졌으며, 2007 RTM과 지금의 2007은 가히 어마어마한 차이가 존재하게 되었다.

단순히 보안 패치 같은 보이지 않는 안정성 차이뿐만이 아니라..
F4 구역을 잡은 상태에서 Ctrl+Home/End가 동작하냐 안 하냐
키매크로와 스크립트 매크로가 동작하냐 안 하냐 같은 당장 눈에 띄는 기능 차이도 적지 않다.
그렇기 때문에 아래아한글 2007과 관련된 문제를 해결하려면 “님, 버전 번호가 뭔가요? 최신 패치는 설치하셨나요?”부터 물어 봐야 할 지경이다.
About 화면에 아직도 (c) 2006이라고 적혀 있는 아래아한글 2007을 보면 한숨만 나온다.

※ 원격 터미널 클라이언트

컴퓨터 프로그램에는 크게 다음과 같은 유형이 있다.
1. CPU 사용량의 편차가 크지만, 어쨌든 오랫동안 끊임없이 켜져 있고 돌아가야 하는 프로그램: 서버
2. 끊임없이 CPU를 혹사하면서 실시간으로 결과를 만들어 내는 프로그램: 게임, 시뮬레이션
3. 사용자에게 클라이언트 상으로 뭔가를 오랫동안 표시하고 보여주는 게 목적인 프로그램: 프레젠테이션, 동영상
4. 로컬 환경에서 사용자의 응답에만 그때 그때 반응하는 프로그램: 대부분의 GUI 기반 애플리케이션

일반적으로 개인이 PC에서 다루는 프로그램의 유형은 4가 대부분이다 보니, 컴퓨터는 사용자가 오랫동안 키보드나 마우스를 건드리지 않으면 화면 보호기를 돌리고, 더 시간이 흐르면 컴퓨터의 전원을 부분적으로 차단하게 되어 있다. 이것은 대부분의 경우 나쁘지 않은 전략이며, 절전과 환경 보호까지 달성할 수 있어서 더욱 좋다. 전세계에서 동작 중인 수많은 컴퓨터들이 잡아먹는 전기는 가히 엄청난 양이며, 이래서 IT 산업이 친환경적이지 못하다는 비판마저 제기되고 있는 실정이다.

그런데 1~3이 돌아가고 있다면 사용자가 건드리지 않더라도 컴퓨터가 꺼져서는 안 된다. 특히 3은 CPU 부하는 그리 크지 않은 것에 비해 모니터가 절대로 꺼져서는 안 된다는 특이점이 존재한다. 윈도우 운영체제에서 3과 같은 역할을 하는 프로그램이라면 WM_SYSCOMMAND의 SC_MONITORPOWER와 SC_SCREENSAVE 메시지에 별도로 응답하여, 내가 실행되고 있는 동안은 화면 보호기나 절전 모드가 동작하지 않도록 운영체제에다 요청을 해야 한다.

FTP나 웹브라우저 같은 프로그램은 다운로드가 진행 중일 때는 모니터는 끄더라도 컴퓨터는 안 꺼지도록 해야 한다. 그렇다면 PuTTY 같은 원격 터미널은 어떨까? 통신 기능은 있지만 딱히 대용량 파일 전송에 최적화돼 있지는 않다. 그냥 프롬프트에서 놀고 있을 때는 장시간 무응답 시 접속을 끄고 컴퓨터도 끄게 할 수 있지만, 서버 접속하여 명령줄로 한창 긴 빌드를 걸어 놓은 상태인데 컴퓨터가 그렇게 정신줄을 놓아 버려서는 안 될 것이다. 이 두 상태를 구분하는 방법이 있어야 할 것 같다.

※ 미묘한 개념 차이

퍼센트는 비율을 나타내는 매우 유용한 단위이다.
그런데 60%라는 수치가 30% 증가하면 78%가 될까, 90%가 될까?
퍼센트에도 퍼센트가 적용된다고 보면 60%의 30%에 해당하는 18% 증가가 될 수 있다.
그러나 퍼센트 수치가 문자 그대로 덧셈으로 증가했다는 차이를 나타낼 때는 '퍼센트 포인트'라는 단위를 쓴다. 속도로 치면 가속도에 해당하는 개념 되겠다.

따라서 2%이던 실업률이 3%가 되었다면, 실업률은 겨우 1% 포인트 증가한 것이지만,
무려 50%나 증가한 것이라고 볼 수도 있다.
통계는 수학적이고 객관적이지만, 이를 이용한 말장난 숫자놀음에 놀아나지는 말아야겠다.
'흉악 범죄자 싸이코패스들은 100% DHMO라는 위험한 약물에 중독되어 있으며 이걸 매일 마시지 않으면 못 산다' 같은 루머조차도 과학의 이름으로 퍼뜨릴 수가 있지 않은가.

그리고 또 비슷한 예가 있다.
우리나라에서 성경을 많이 찍어낸다고 들었는데, 성경뿐만 아니라 외국의 화폐도 굉장히 많이 찍어서 수출한다.
우리나라가 6· 25 당시에는 일본에서 임시로 돈을 찍어서 쓰기도 하였으나, 지금은 우리나라의 조폐 기술이 가히 세계 최고 수준이다. 듣자하니 EU 유로화 화폐를 거의 전량 한국에서 만든다고 함.

그런데, 돈을 얼마짜리만치 만들어서 수출했다고 하면, 이건 우리나라가 챙긴 액수(제조 원가+이윤)를 말하는 걸까, 찍어낸 돈 자체의 액면가를 말하는 걸까?
이것도 마치 퍼센트와 퍼센트 포인트의 차이 같은 미묘한 개념 차이가 발생하는 영역이 아닐 수 없다.

Posted by 사무엘

아래아한글이 윈도우 비스타부터 키매크로를 지원 안(못) 하는 이유는?
(관련 글: 아래아한글의 키매크로 )
이것과 관련하여 갑자기 떠오른 생각이 있어서 글을 남긴다. 본인은 한컴에 입사한 개발자도 아니고 아래아한글의 소스 코드를 본 적도 없지만, 본인이 보기에 이것 때문이 거의 확실하다.

윈도우 훅 중 WH_JOURNALRECORD와 WH_JOURNALPLAYBACK 훅이 비스타에서부터는 보안 강화를 이유로 차단되었기 때문이다. MSDN을 보면 알 수 있지만 저건 완전 키매크로를 구현하라고 만든 훅이다.
(관련 글: 훅킹 프로그래밍 )
실패 사유를 나타내는 에러 코드는 5(access denied)가 들어온다.
심지어는 프로그램을 관리자 권한으로 실행해도 차단은 풀리지 않는다. 이건 좀 너무 심하지 않았나?

물론, 키매크로를 구현하는 방법이 저 훅만 있는 건 아니기 때문에 다른 키보드/마우스 훅을 사용하여 동일 기능을 우회 구현할 수도 있다. 하지만 이래저래 개발자에게는 귀찮고 짜증나는 일이 하나 더 생긴 게 틀림없다.

참고로 이렇게 차단을 하는 주체는 사용자 계정 컨트롤(UAC)이다. 그렇기 때문에 이걸 끄면 비스타도 XP와 완전히 동일하게 동작은 한다. 하지만 보안상으로는 위험하기 때문에 개발자가 사용자에게 UAC를 끌 것을 강요해서는 안 된다.
UAC는 안전을 위해 프로세스 간 의사소통을 하는 메커니즘에도 상당한 제약을 부과했다. 단적인 예로, 권한이 낮은 프로그램이 권한이 높은 프로그램에게 임의의 메시지를 보낼 수 없다.

이미 아시는 분도 있겠지만 <날개셋> 한글 입력기는 5.3부터 입력 패드라는 프로그램을 제공하고 있다. 윈도우 IME 훅킹을 통해, 정식 외부 모듈이 아니면서도 외부 모듈의 동작을 흉내 내어 주는 프로그램인데, 이 프로그램을 제대로 사용하려면 관리자 모드로 실행해 줘야 한다. 그렇지 않으면 입력 패드보다 권한이 높은 프로그램(관리자 권한으로 실행된)에다가는 글자 입력을 할 수 없게 된다.

그런데, UAC 하에서도 예외적으로 실행 중인 모든 프로세스의 윈도우에다가 메시지를 보낼 수도 있고 심지어 봉인된 WH_JOURNAL* 훅까지 구사할 수 있는 만능 권한 등급이 없는 건 아니다. MS에서는 대표적인 예 중 하나로 장애인의 UI 접근성 개선을 위해 쓰이는 프로그램에게나 그런 만능 권한을 주고 있다.
예를 들어 화면 키보드 같은 프로그램이야 권한을 초월하여 아무 프로그램에게나 문자 입력 메시지를 전달할 수 있어야 하고 심지어 운영체제 로그인 UI에도 존재해야 하기 때문이다. (ID/패스워드 입력할 때)

단지 그 권한을 얻기가 더럽게 까다로워서 문제이다. 만능 권한을 얻을 수 있는 프로그램은 사용자의 컴퓨터에 반드시 관리자 권한으로 정식으로 설치되어 EXE 파일이 Program Files 같은 특정 경로에만 존재해야 한다. 잘 알다시피 UAC 하에서는 평소에는 Program Files 디렉터리 밑에다가 파일을 만들지도 못한다.

또한, 결정적으로 EXE 내부에 디지털 서명이 되어 있어야 한다. 과거에 마치 ActiveX를 배포할 때 안전한 코드 인증을 받는 것처럼 말이다. 이거 서명을 받으려면 $이 필요하고, 무엇보다도 사업자 등록 번호가 있어야 한다. 즉, 듣보잡 개인 개발자는 서명을 받지도 못한다는 뜻.
따지고 보면 <날개셋> 입력 패드도 일종의 화면 키보드처럼 UI 접근성 개선 프로그램의 성격이 강하기 때문에 저런 권한이 있어야 할 텐데... 그러지는 못하고 있고 그저 사용자가 알아서 충분히 높은 권한을 줘서 프로그램을 실행해 주길 바랄 뿐이다.

이래저래 보안이 안전을 빌미로 세상을 많이 복잡하게 만들고 있다.
(관련 글: 프로그램의 권한 )

Posted by 사무엘

그동안 폐쇄적인 파일 포맷 정책 때문에 욕 많이 얻어먹고 있던 한컴에서 최근에, 한 지난달 말부터 꽤 놀라운 결정을 내렸다. 아래아한글의 파일 포맷(.hwp)을 드디어 정식 공개한 것이다. (뭐, 그렇다고 해서 한컴도 먹고 살아야지, 그런 회사에게서 MS나 구글 정도의 대인배 기질을 바라는 것도 세상 물정 모르는 개념 없는 소리이긴 하다.)
워디안 시절부터 지금까지 쭉 사용되어 오고 있는 소위 5.0 포맷과, 지금은 이미 완전 역사 속의 유물이 되어 버린 과거의 97 방식(3.0 포맷) 이렇게 둘을 공개했다.

본인이 아래아한글에 대해서 무척 대단하게 생각하고 있는 면모는, 지금의 파일 포맷이 미래 확장성을 대비해서 정말 대인배스럽게 잘 설계돼 있다는 점이다. 아래아한글 2010 정도면  MS 따라 hwpx-_- 같은 새로운 파일 포맷을 도입해도 이상할 게 없을 거라고 생각했는데 여전히 10년 전 포맷 그대로이다. 이 정도면 과거 MS 워드가 97부터 2003버전까지 사용한 구식 doc/xls/ppt 포맷의 짬밥을 훨씬 능가한다.

그 10년 동안 아래아한글엔 세로쓰기를 비롯해 문서의 기본 골격을 완전히 바꾸는 새로운 기능들이 상당수 추가되고, 무엇보다도 문자 인코딩이 마구 바뀌어 왔다. 유니코드 surrogate가 지원되기 시작한 게 2004부터이고, 아랍/히브리 complex script가 지원되기 시작한 게 2005부터이다. surrogate 지원 전에는 Yi 문자 같은 영역에다가 아래아한글 특수문자를 제멋대로 집어넣기도 했다.

특히 문제는 한자. 아래아한글이 과거의 한컴 2바이트 코드에서 자체 제공하던 제 2수준 한자 중에는 유니코드 BMP 영역의 한중일 통합 한자에 존재하지 않는 녀석이 극소수 있었다. 그건 처음엔 사용자 정의 영역으로 가 있었는데 일부는 나중에 surrogate에 있는 유니코드 “한중일 통합 한자 확장 B/C”에서 정식 추가되기도 했다. 흠좀무..;; 끝으로, 2010 버전부터는 옛한글도 과거 10년간 이용해 비표준 한양 PUA를 버리고 드디어 유니코드 5.2 표준으로 돌아갔다!

이 정도면 문자 인코딩도 버전 관리를 해야 할 지경이지 않은지? 또한 이제 워디안 시절의 10년 전 파일 포맷은 효율이 상당히 떨어졌으며, 굳이 하위 호환성을 지키려 애쓰는 것도 무의미해지지 않았나 하는 생각이 든다.
뭐, 비록 워디안은 너무 불안정해서 사용자들로부터 완전히 발렸지만, 2002는 아직도 관공서 같은 곳에서 쓰는 사람이 있지 싶다-_-. 특히 2002 SE는 윈도우 운영체제로 치면 마치 98 SE 같은 안정화 버전이었기 때문이다.

그나저나, 아래아한글은 같은 문서를 저장해도 파일 크기가 은근히 굉장히 커져 왔다. 가령, 과거 아래아한글 2002에서 작성한 hwp 파일을 2007에서 열어서 아무 수정 없이 그냥 다시 저장만 해도, 파일 크기가 꽤 커진다. 특히 더 옛날의 97 방식 hwp와 비교해 보면, 지금 hwp 파일은 진짜 비교도 안 될 정도로 크기가 더 커졌으며, MS 워드의 doc나 docx와 비교해도 마찬가지이다.
아무 서식이나 고급 기능을 안 쓰고 글만 빽빽한 문서를 작성했는데도 파일 크기가 너무 커졌다는 느낌을 지울 수 없다. 압축을 물론 했는데도 그 정도.

사실 이건 MS 오피스 제품도 마찬가지여서 똑같은 doc/xls/ppt도 2003에서 작업한 파일을 2007에서 불러와서(물론 호환성 모드) 다시 저장하면 크기가 꽤 커진다. 2003에서는 인식되거나 사용되지 않는 여러 메타 정보가 추가되어서 그런 것 같다.
그나저나 참고로, 2007 방식이라고 해도 암호가 걸린 문서 파일은 xml+zip 압축 포맷이 아니며, 과거 2003 같은 복합 바이너리 포맷으로 저장된다.

본인은 아래아한글을 버릴 수 없는 처지에 있는 사람이다. 도저히 적응이 안 되는 MS 워드의 기괴한 동작 방식, 그리고 손에 너무 익어 버린 단축키, 그리고 과거의 수많은 hwp 문서와 절대로 버릴 수 없는 hft 글꼴들 때문에 아래아한글은 탄탄한 기득권을 갖추고 있다. 또한 한컴도 이윤을 창출해야 하는 기업이라는 것 역시 모르는 바 아니다. 앞으로도 너무 심한 병크만 터뜨리지 말고 아래아한글을 잘 유지 보수해 줬으면 좋겠다.

Posted by 사무엘

Posted by 사무엘

Posted by 사무엘