※ 셸 프로그램

명령 프롬프트 하나만 달랑 떠 있는 게 아니라 최소한의 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 사무엘

2012/09/08 08:21 2012/09/08 08:21
, ,
Response
No Trackback , 5 Comments
RSS :
http://moogi.new21.org/tc/rss/response/730

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

Comments List

  1. 삼각형 2012/09/08 14:04 # M/D Reply Permalink

    까마득한 옛날 이야기 같네요. 저때 까지만 해도 UI의 개념이 겨우 잡혔을 텐데 지금은 UX라는 UI를 넘어서 동작에 관한 것 까지 신경쓰는 여유로운 시대가 되었습니다. 지금은 그때에 비하면 리소스가 넘처나니까 말입니다.
    어쩌면 지금 세대가 모바일 1세대로서 나중에 저런 식으로 과거를 회상하게 될 날이 올 지도 모르겠군요.

    저도 Shell을 쉘이라고만 알아서 처음 볼때는 '셸'이 뭔지를 고민했었습니다. 이런 외래어는 좀 예외로 인정해 줘야 할 것 같네요. ㅋ

    1. 사무엘 2012/09/08 23:44 # M/D Permalink

      네, 정말 까마득한 옛날 이야기가 맞습니다.
      아래아한글은 97 이후에 워디안을 만들 때 프로그램 엔진을 처음부터(특히 유니코드 기반으로) 다시 만드느라 또 처절한 공밀레를 경험했지요.
      워디안과 2002까지는 대화상자에 잠시 Windows 표준 GUI를 썼지만, 2004부터는 다시 97과 비슷한 기술 수준의 독자 GUI로 회귀했습니다. 스킨 변경 기능이 이때부터 도입됐으니까요.
      저도 아직까지는 쉘이 더 익숙합니다..;

  2. Lyn 2012/09/09 23:03 # M/D Reply Permalink

    전 윈도 Vista가 나온 이후 오랜 동반자엿던 토탈커맨더가 구석으로 밀려났습니다 =_ㅜ

    가끔 이름바꾸거나 할때만 쓰고 ..

    1. 사무엘 2012/09/10 16:04 # M/D Permalink

      비스타/7/8 시대라 해도, 여전히 손에 착착 달라붙는 단축키를 쓸 수 있는 파일 관리 셸 유틸 정도는 하나 갖고 있는 게 파워 유저들에게 편리하지요.
      원하는 파일이나 디렉터리로 곧장 빠르게 이동해서 원하는 프로그램으로 곧장 조작 가능하고, 압축 파일과 FTP가 자동 연계가 된다면 더욱 좋을 것 같습니다.

    2. Lyn 2012/09/11 12:41 # M/D Permalink

      탐색기도 FTP 지원 합니다 ^^;

Leave a comment

오랜만에 <날개셋> 한글 입력기의 새 버전 소식을 전하게 된 것을 기쁘게 생각한다.
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 사무엘

2012/08/27 08:20 2012/08/27 08:20
, ,
Response
No Trackback , 13 Comments
RSS :
http://moogi.new21.org/tc/rss/response/725

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

Comments List

  1. 사샤나즈 2012/08/27 17:58 # M/D Reply Permalink

    잘 읽었습니다.
    이전 종성 지향 두벌식 글과 함께 읽고, 자음을 두 번 누르면 쌍자음으로 조합되도록 조합 규칙을 수정한 두벌식의 자판을 바꾸어 적용해 보았는데,

    1. 'ㅅㅅㅡㄹ' 의 순서로 '쓸' 을 입력하려 하면 'ㅅ슬' 이 입력됩니다. 기존 H2 타입에서 종성 위치에 자음이 있을 때 모음을 입력하면 나오는 결과와 같습니다만 해결법이 있나요?

    2. 자음이 표시되기는 초성 위치에 표시되더라도 실제 코드는 종성 코드기 때문에 오토마타에서 'D'로 초성 위치에 자음이 있는지 확인할 수가 없는 듯합니다. 해결책이 있을까요?

    또한 이번 윈도우8에서는 특정 가이드라인을 만족시키지 않는 입력기는 메트로 모드에서 쓸 수 없도록 했는데, 이 가이드라인에 날개셋 입력기를 대응시킬 계획을 갖고 계신가요? 또 현재는 윈도우8에서 language bar(태스크바와 완전히 통합되어 따로 떼는 옵션이 보이지 않네요)에 날개셋 로고 포함 아무 아이콘도 표시되지 않아 수정은 필요할 듯합니다.

    마지막으로, 좋은 입력기를 계속 개발해 주셔서 감사합니다. ^-^

    1. 사무엘 2012/08/27 22:23 # M/D Permalink

      안녕하세요?
      한글 입력기의 동작에 대한 질문은 막연한 문장만으로는 제가 상황을 짐작하기 어렵습니다. 제가 추측을 바탕으로 제시한 다음 답변들만으로 문제가 해결되지 않는다면, 현재의 입력 설정을 파일로 첨부하여 제게 메일을 보내 주시기 바랍니다.

      1. H2와 H2J 타입은 그런 동작 방식을 구분해 주는 개념이 아닙니다. 혹시 이번 버전에서 추가된 ‘MS 두벌식’ 설정을 고치신 것이라면, “ㅅ+ㅅ=ㅆ” 결합은 종성이 아니라 초성에다 추가해야 합니다. 그래야 ‘ㅅ슬’이 되지 않고 ‘쓸’로, ㅆ이 다음 글자의 초성으로 한꺼번에 넘어갑니다. 종성 결합은, 종성에서 결합은 되지만 도깨비불 현상이 일어날 때 “ㄱ+ㅅ=ㄳ”처럼 종성과 초성으로 갈라지는 규칙의 집합이거든요.

      왜 이렇게 동작하는가 하면, 이 입력 설정은 ‘초-종성 공유 낱자 결합 규칙’을 사용하기 때문입니다. 자세한 것은 프로그램 도움말에서 ‘초 종성 공유 낱자 결합 규칙’에 대한 설명을 참고하세요. 이 용어는 색인에도 바로 등록되어 있습니다.

      여담이지만 두벌식은 쌍자음은 원래 반드시 Shift+한 타로만 입력하는 것이 맞습니다. 종성 지향 두벌식은 진짜 초성과 종성의 문맥 구분이 없는 진정한 두벌식인데, “ㅅ+ㅅ=ㅆ”을 해 버리면 진짜 종성 ㅅ+초성 ㅅ을 연달아 입력할 수가 없어지기 때문입니다. 천지인 입력 방식이 ‘국가’와 ‘구카’를 구분할 수 없어서 어느 하나는 조합 종료 타이머를 쓰는 것처럼 말입니다.

      2. 예, 맞습니다. 종성 지향 두벌식으로 입력한 첫 자음은 누가 봐도 명백하게 종성이기 때문에 오토마타의 D 변수에 표시되지는 않습니다. 그리고 오토마타의 내부 상태 번호도 초성이 아닌 종성 상태입니다.

      그런 명목상의 자음은 오토마타 수식에서는 (!D && F && O&2)라는 조건으로 식별해야 할 것 같네요. “조합 중인 한글에 초성이 없고 종성만 있는데, 그 글자가 두벌식 한글인가?”라는 뜻입니다. O 변수는 이번 6.7 버전에서 추가된 유용한 플래그이고요. (자세한 것은 역시 도움말 참고)

      하지만 오토마타는 아주 특수한 녀석을 디자인하는 게 아니라면 가능하면 조합 중인 낱자를 끌어들이지 않고, 입력으로 주어진 낱자인 A~C만으로 동작하게 만드는 게 깔끔하고 좋습니다.

      끝으로, 윈도우 8의 지원을 위한 별도의 연구와 조치는 현재로서는 아직 계획된 바가 없습니다. 얼리어답터 분들께는 좀 아쉽겠지만, 개인 사정상, <날개셋> 한글 입력기의 윈도우 8 대처가 윈도우 8의 정발보다 더 이를 가능성은 높지 않습니다.

      입력기의 내부 메커니즘에 대해서 어려운 설명이 많이 나왔는데, 잘 이해가 되셨나 모르겠네요. ^^
      감사합니다.

  2. 까막눈 2012/08/28 10:30 # M/D Reply Permalink

    너무 좋은 프로그래 만들어주셔서 감사합니다. 며칠전에 다운받아서 설치하고 연습중인데요,
    편집기에서 세벌식 390을 추가해본 후에 자판을 보니, / 자리에 원래 ㅗ가 있어야 하는것 아닌가요??
    그냥 / 자리에 / 가 있네요??? 버그인것인지?? 그렇다면 어떻게 수정하면 되나요
    감사합니다.

    1. 사무엘 2012/08/28 11:22 # M/D Permalink

      반갑습니다.
      ‘왼’, ‘과’ 같은 글자를 입력하면서 /를 눌러 보시면 ㅗ가 정상적으로 입력될 겁니다. 이 글 본문에도 이미 언급돼 있듯이, 이것이 원래 세벌식 글자판의 스펙이며, 고증에 충실한 것입니다. 특히 아래아한글은 세벌식 390 글자판을 만드신 분이 관여하고 있는 제품이기도 하니까요.

  3. 까막눈 2012/08/28 11:48 # M/D Reply Permalink

    390에서 초성없이 그냥 / 키를 누르면 / 가 찍히는데, 초성이 있는 상태에서 누르면 ㅗ가 나오는군요!
    그래서 화면에서 키배치에서는 / 가 찍혔군요.. 경우에 따라서 다른게 행동하네요.. 하지만 9위의 'ㅜ'는 안그렇네요..
    몰랐습니다... 좋은 프로그램 만들어주셔서 감사합니다.

  4. 까막눈 2012/08/28 11:53 # M/D Reply Permalink

    최종에서는 그렇지 않고 ㅗ가 무조건 찍히는데 반해, 390에서는 조건부로 달라지네요??
    좋은것 같습니다.. 근데 이렇게하면 shift-G 로 누르는 / 는 불필요한 키배정같은데요..흠
    이건 좋은 아이디어 같은데, 그럼 390이 먼저나온걸로 아는데 최종(391)에서는 왜 그런 행동이
    없어졌는지 모르겠네요.. 뭐 딱히 질문은 아니고, 궁금해서 적어봅니다..
    무척 세심하게 만들어주신 프로그램, 정말 훌륭합니다.
    감사드리고 또 감사드립니다..
    건강하세요!

    1. 사무엘 2012/08/28 17:29 # M/D Permalink

      네, 맞습니다. 다른 이유는 없고요, 제 프로그램은 390에만 조건부 /를 적용해 주고 있습니다. Shift+G를 누를 일이 크게 줄어드는 것도 사실이죠.
      최종 같은 여타 세벌식에서도 /의 수식을 "T&&!E ? H3|O_ : 0x2F"로 수동으로 넣어 주면 조건부 /를 쓸 수 있습니다. 그리고 ㅜ가 들어있는 9는 어떤 경우건 조건부 글쇠의 대상이 아닙니다.

      그에 반해 아래아한글은 최종 같은 공 병우 세벌식에 모두 조건부 /가 가장 엄격히 적용되고 있고요.
      이중모음 정석은 아시지요? V, B 의 ㅗ,ㅜ로는 이중모음이 안 되고 9, /로만 되는 것?

      이것도 원래 세벌식 FM이라면 지켜 주는 게 마땅하고 도스 시절엔 그걸 지키는 에디터도 있긴 했는데, DOS 시절이 끝나면서 거의 구분이 없이 사문화한 규정이 됐습니다.
      세벌식 안에서도 이런 식으로 배리에이션이 제법 있습니다. 이런 것들을 수용하려는 목적으로 <날개셋> 한글 입력기가 개발되었는데 버전이 올라가면서 세벌식 뿐 아니라 두벌식 쪽 지원도 늘고 있지요.

      이는 뒤집어 말하면, 글쇠와 한글 자소 사이에 왜곡이 존재하는 두벌식이 처리 난이도가 더욱 높기 때문에 미래의 후대 버전에서야 지원이 제대로 되기 시작했다는 뜻으로도 풀이할 수 있겠습니다.
      프로그램을 유용하게 사용하시기 바랍니다. ^^

  5. 주의사신 2012/08/28 15:17 # M/D Reply Permalink

    여기에 지혜가 있으니 지각이 있는 자는 그 프로그램의 수를 세어 볼지니라. 그것은 프로그램의 역사에서 비롯된 수니, 그것의 수는 육점육십육이니라. (계 13 : 18 패러디)

    위 구절을 쓸 수 있을 뻔 했은데, 일부러 피해 가신듯 하군요. 그리스도인이 만든 프로그램에 붙이기에는 조금 난감한 숫자가 아닌가 하는 생각도 조금 듭니다.

    1. 사무엘 2012/08/28 17:30 # M/D Permalink

      악은 모양이라도 피하고 싶어서 말이지요.
      프로그램의 역사에서 비롯된 수라니... 센스가 쩌십니다. ㅋㅋㅋ
      이번 버전이 마음만 먹으면 6.66을 붙일 수 있는 초유의 기회였죠.

      이번 버전은 역대 버전들 중 커널인 ngs3.dll 크기와 설치 배포 패키지의 크기가 가장 커졌습니다.
      과거에는 기능 때문에 커널 크기가 커지다가도 리팩터링, 기능 분할 등으로 인해 크기가 종종 감소하기도 했거든요.
      그러다가 이제는 다시 최고점을 찍었고요. 게다가 VC 2010이 같은 소스 코드도 좀 더 크게 컴파일하기도 해서..
      msi 파일도 과거에 거대한 msvcr71.dll과 mfc71.dll을 직접 내장하고 있었던 3.1 이래로 최고 크기를 경신했습니다.

      단일 프로그램을 혼자서 1.0부터 6.7까지 만들었다니.. 덜덜~

  6. 다물 2012/08/28 20:12 # M/D Reply Permalink

    혹시 윈도우 8을 지원하는 제품인가요?

    1. 사무엘 2012/08/28 22:21 # M/D Permalink

      아니요, 위의 댓글에도 언급돼 있듯, 이번 버전은 아직 윈도우 8 지원과 관련된 작업은 진행된 것이 없습니다.
      그러고 보니 날개셋뿐만 아니라 파워업도 분명 8에서는 또 제대로 동작을 안 할 가능성이 높아 보이는데, 테스트를 해야겠군요.

  7. Lyn 2012/08/30 10:11 # M/D Reply Permalink

    석사 완전히 끝나신거군요. 축하드립니다

    1. 사무엘 2012/08/30 11:43 # M/D Permalink

      감사합니다. 내일 학위 수여식이 있답니다. ^^

Leave a comment

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

사용자 삽입 이미지
이게 과연 가능할까 나 자신도 장담할 수 없었는데 결국은 해냈다.
스크린샷의 프로그램은, 아래아한글 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 사무엘

2012/01/08 19:23 2012/01/08 19:23
,
Response
No Trackback , 15 Comments
RSS :
http://moogi.new21.org/tc/rss/response/624

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

Comments List

  1. 소범준 2012/01/08 23:19 # M/D Reply Permalink

    1. <날개셋> 뿐만 아니라 글꼴 쪽까지도 도전하고 계시니, 형제님의 한글 관련 연구 범위는 과연 어디까지인지... ㅎㄷㄷ;;

    2. 요샌 포털사 네이버도 지난번 한글날(2011/10/9) 즈음부터 새 폰트를 제작.발표하여 일반에 공개하여 배포하고 있습니다. 그 때 관련 방송 프로그램에서 '글꼴도 한글 경쟁력을 뒷받침하는 한 축'이라는 말을 들었던 적이 있습니다.

    3. 옛날 도스 시절의 아래아한글도 그 윈도 3.1 짜리의 구닥다리 아버지 노트북 쓸 때 살짝 써 본 적이 있습니다.
    그게 2.0이었다면 형제님이 글에서 언급하신 것과 동일할 겁니다. 전체 폰트가 명조체인 게 인상 깊군요.

    ※ 참고로 서울메트로 1호선 현대정공 VVVF 및 4호선 대우산 내부 안내기가 명조체를 사용합니다.ㅋ

    1. 사무엘 2012/01/09 09:21 # M/D Permalink

      1. 딱 저 두 개가 전부입니다. 더 없어요. ㅎㅎ 각각 입력과 출력이죠.

      2. 글꼴 '도'가 아니라 글꼴 '이야말로' 진짜 한글의 경쟁력을 뒷받침하는 한 축입니다.
      <날개셋> 한글 입력기는 세벌식 이념을 아는 사람에게만 적극적인 appeal이 가능하지만, 글꼴은 한글을 쓰는 누구에게라도 영향을 줄 수 있습니다.

      3. 그런 전광판에 있는 서체들은 명조이긴 하지만, 조합 테이블이 아래아한글의 그것과 완전히 100% 일치하는 명조는 아닐 겁니다. 뭐, 그래봤자 겨우 16*16 크기에서 차이는 미미하지만 말이죠.

  2. 주의사신 2012/01/09 09:40 # M/D Reply Permalink

    1. 전 도저히 16진수로 된 binary 파일 못 읽겠더군요. 아마 많이 안 읽어서 그런가 봅니다.


    2. StackOverflow라는 유명한 프로그래밍 관련 질의응답 사이트가 있습니다.

    이것 만드신 분들이 꼭 프로그래밍만 할 것은 없다라는 생각에 이것저것 사이트를 늘릴 수 있도록 해 놨습니다. 그러다 보니 요즘에는 별 게 다 있습니다. 성경 관련된 것도 있습니다. 두 개나!

    목록 보기
    http://stackexchange.com/sites

    이 사이트들은 아래 사이트에서 준비가 되어서 시작이 되게 됩니다.

    http://area51.stackexchange.com/

    처음에 질문이랑 follower를 모으고, '열심히 참여하겠습니다' 서명 운동(?)을 하는 commiter를 모은 후에 beta로 들어갑니다.

    한국어 질문하고 답하는 사이트도 준비 중이더군요. follower 12명 더 모으고, committing 시작해야합니다.

    http://area51.stackexchange.com/proposals/31223/korean-language-usage

    올 해 안에 될까 궁금합니다. 중국어, 일본어는 벌써 beta가 있는데, 한국어는 관심 있는 사람들이 별로 없는가 봅니다. 글꼴 뿐만 아니라 이런 거 생기는 것도 나라의 언어의 경쟁력인데...ㅜㅜ

    1. 사무엘 2012/01/09 19:21 # M/D Permalink

      자기가 주로 다루는 분야의 파일의 내부 구조에 대한 context만 알면, 16진수 코드 들여다보는 건 그리 어렵지 않게 감이 생깁니다.

      개인적으론, 해커와 리버스 엔지니어를 위한 잘 만들어진 헥스 에디터가 없나 궁금합니다.
      이 지점부터 스캔 시작했을 때 특정 구조체에 차는 값, 이 지점이 가리키는 오프셋에 있는 값 등, view를 사용자가 마음대로 사용자 지정할 수 있고, 값을 고쳐서 데이터의 길이가 달라졌을 때, 오프셋 계산을 다시 한다거나 하는 것 말이죠.
      텍스트 에디터야 워낙 먼치킨급의 상용 프로그램이 많습니다만, 헥스 에디터 분야는 잘 모르겠습니다.

      StackOverflow는 물론 저도 잘 알고 있죠. 네이버에 지식인이 있다면, 구글은 거기 커뮤니티의 Q&A 검색 결과를 잘 찾아 주는 편이어서 프로그래밍 관련 의문을 해결하는 데 큰 기여를 하고 있습니다.
      한국 사람이 그런 세계구 커뮤니티에 기여를 잘 못하는 이유는, 뭐 각박한 사회 구조 때문보다는 영어가 딸려서인 게 더 크게 작용하겠죠. -_-;; 말만 통한다면야 무한 잉여력이 발산되지 않겠어요? ㄲㄲ

  3. 자랑쟁이 2012/01/10 04:20 # M/D Reply Permalink

    정말 대단하십니다.

    최근에 이것 저것 공부를 하다가 내용이 용묵님 블로그에서 걸리는 일이 많아 몇번을 보면서 대단한 사람이다.. 라고 감탄하고 갔는데(개인적으론 주유구는 정말 재미있게 읽었습니다), 이 글까지 보니 댓글을 안남기고는 못배기겠네요.

    저도 제 컴퓨터를 처음 갖으면서 세벌식을 쓰려고 했었는데, (개인적으론 한달동안 160타로 올렸던 2벌식에서의 타수가 삼벌식으로 2주만에 300타가 나온 경험이 있습니다.), 다른 사람의 컴터를 쓸때 바보가 되는 느낌을 받아서 포기했던 기억이 있습니다. 사실 개인적으론 왜!!!! 세벌식이 아니라 2벌식이 표준이 됐는지 아직도 이해가 안갑니다...
    워낙에 학부때 한글과 타이포그래피에 관심이 많아서, 이런 쪽에 관심이 많았는데... 정말 재미있네요. 전 지금까지 서체가 암호화 되어 있으리라고 생각조차 해본적이 없었거든요. (물론 저는 디자이너라... 그것까지 생각할 일은 별로 없습니다만.. ^^)

    여튼 앞으론 영묵님 블로그에서 글을 읽게 되면 다녀갔다는 흔적이라도 남겨야 겠다는 생각을 했습니다.
    좋은 포스팅 감사드립니다. ^^

    1. 사무엘 2012/01/10 10:32 # M/D Permalink

      악.. 오덕질 자랑하는 글에 '자랑쟁이' 닉을 쓰시는 분께서?? ㅋㅋㅋ

      반가운 손님께서 댓글 남겨 주셔서 대단히 고맙습니다.
      네, 저도 어릴적에 한글, 타이포그래피, 글자판 이런 쪽에 완전 꽂혀 지냈고, 미래엔 그게 접목된 논문도 쓰려 합니다.
      여러가지 이력이 독특하신 분 같네요. 자세한 얘기는 제가 거기에 올리도록 하겠습니다.

  4. 사무엘 2012/01/10 10:58 # M/D Reply Permalink

    통합 글꼴 HFT도 부분적으로 뚫어서 인증샷을 추가했다. 이건 레퍼런스를 좀 보고 뚫은 것임.
    이로써 암호화되지 않은 HFT는 장기적으로 TTF로 변환할 수 있는 기반이 마련됐다. goodbye HFT -_-;;

    통합 글꼴은 자체적인 코드 페이지, 더욱 세밀한 서체 메타정보, 섹션(미래의 확장에 대비 가능한 영역)이 추가되는 등, 전반적으로 TTF에 더 가까워지고 구조도 더욱 복잡해졌다. 사실, 통합 글꼴이 제정되는 당시엔 국내의 폰트 엔지니어들도 TTF의 존재는 알고 있었을 것이다.
    어쨌든, 이 때문에 예전처럼 하드코딩된 오프셋만 디비보는 방법만으로는 모든 HFT 파일을 커버할 수 없다.

    또한, HFT는 암호화되지 않은 인스트럭션도 명령이 아니라 좌표 체계 내부에 비트 단위 꼼수가 추가되어 분석하기 더 까다롭다. 파일을 더 compact시켜서 크기를 줄이려는 의도로 보인다. 통합 글꼴에 비하면 이전의 과도기적 2.0 HFT가 정말 간단하기 그지없었던 구조임.

    2.0 HFT야 20년 전의 아래아한글 2.0에서만 딱 한 번 쓰이고 말았던 임시 legacy 포맷이다만,
    통합 글꼴은 상용 제품인 아래아한글이 계속 지원하는 포맷인 만큼, 더 자세한 정보는 저작권 보호를 위해 밝히지 않으련다.

  5. 다물 2012/01/12 10:06 # M/D Reply Permalink

    글꼴 원 저작사와 충돌이 생길지도 모른다고 생각합니다.
    잘 알아보고 하심이 좋을 것 같네요.
    한/글에 포함된 글꼴을 한/글에서 쓰는건 가능하지만 그 밖에 다른 곳에서 쓰면 문제가 될 수 있고 다른 용도로 쓰는건 문제가 될 수 있습니다.

    1. 사무엘 2012/01/13 13:43 # M/D Permalink

      이런 15년 전의 구닥다리 서체에 집착하는 사람도 없을 것이고,
      그때 HFT 공급했던 서체 회사들 중에 망하거나 합병되지 않고 지금까지 남아 있는 회사도 별로 없을 겁니다.
      물론 그렇다고 해서 저작권 침해 해도 된다는 소리는 아니지만, 저도 위험한 짓은 안 합니다. ㅎㅎ

  6. 비밀방문자 2014/09/14 22:21 # M/D Reply Permalink

    관리자만 볼 수 있는 댓글입니다.

    1. 사무엘 2014/09/15 09:23 # M/D Permalink

      저도 해킹이나 RE 전문가인 건 아니고 딱히 어디서 배워서 분석하지는 않습니다. 글꼴이라는 해당 분야 자체에 관심이 많다 보니 그냥 '감'으로 어째어째 하다가 운이 좋아서 성공한 것일 뿐이지요.
      그리고 포맷을 안다고 해서 바로 TTF로 바꿀 수 있는 건 아니기 때문에 개인적으로는 후반부 작업에도 굉장히 애를 먹었습니다. :)

  7. ㅇㅇ 2014/11/18 22:08 # M/D Reply Permalink

    신명 중명조를 개인적으로 굉장히 좋아하는데 저도 PDF를 통해서 어찌어찌 추출해 보려 했으나 잘 안 되서 아쉽네요... 신명 중명조를 한글 이외의 프로그램에서도 쓰고 싶은데... 컴퓨터에 대해 아는 건 잡지식밖에 없는데 작성자님처럼 되려면 얼마나 많이 배워야 할까요 +_+

    글 잘 읽고 갑니당 ㅠㅜ

    1. ㅇㅇ 2014/11/18 22:11 # M/D Permalink

      아 그리고 만약 추출할 수 없다면 이 글꼴만 따로 사고 싶은데... 한컴께 문의 드리면 나올려나요..

    2. 사무엘 2014/11/19 09:12 # M/D Permalink

      안녕하세요? 저도 신명 신명조/중명조의 완전 중독자랍니다. ^^ 정말 고퀄이죠.
      재래식 HFT는 아래아한글 개발사에서도 이제는 더 개발이나 지원을 안 하는 완전히 legacy가 됐습니다. (안티앨리어싱조차 없이 출력되니 화면 품질 안습)
      신명 글꼴은 현재는 SM 글꼴로 바뀌어서 '직지소프트'라는 후속 기업이 여전히 저작권을 갖고 정식 판매를 하더군요. 물론 TTF 형태입니다. http://www.smfont.com 정식 구매를 원하시면 이쪽으로 알아보시는 게 좋을 듯합니다. :)

  8. ㅇㅇ 2014/12/12 19:14 # M/D Reply Permalink

    감사합니다 ㅠㅠ 근데 단일폰트 구매는 힘들다는데 가격이 걱정되네요...

Leave a comment

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

2011/08/19 09:03 2011/08/19 09:03
, , , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/557

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

Leave a comment

분야별 여러 잡설

※ 서울 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 사무엘

2011/05/27 19:48 2011/05/27 19:48
, , , , , ,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/517

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

Comments List

  1. 삼각형 2011/05/27 22:40 # M/D Reply Permalink

    그런 문제점 대문에 Type 3 프로그램이 아닌데 Type 3처럼 쓰려고 하면 프리젠테이션 중 대기모드로 전환되는 참사가 벌어질 수가 있죠. 웹브라우저를 전체화면 모드로 해서 프리젠테이션처처럼 써먹으려는 서비스들이 몇몇 있는데 그런 문제는 해결 되었는지 모르겠습니다.

    동영상 인코딩(Type 2) 시켜놓고 나갔다오니 대기모드로 들어가 있던 황당한 상황도 있었죠.

    DHMO 드립, 백괴사전에 따르면 한국어로는 '일산화 이수소'라네요. 현대 과학과 논리의 모순을 꼬집으려는 분들이지 진짜로 믿는다고는(-_-) 생각하지 않습니다.

    1. 사무엘 2011/05/28 09:38 # M/D Permalink

      네, 말씀하신 상황도 그렇고(웹브라우저로 프레젠테이션), 가상 머신이나 원격 터미널로 가도 상황이 좀 복잡해집니다. 터미널 서버로 빌드를 걸어 놓고는 밥 먹고 왔는데 컴이 최대 절전 모드로 들어갔다거나. -_-;;
      컴퓨터나 응용 프로그램이 스스로 자기가 절전 모드로 들어가도 되는지 판단하는 것에는 한계가 있을지도 모른다는 생각이 드네요.

Leave a comment

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

윈도우 훅 중 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 사무엘

2010/09/13 18:34 2010/09/13 18:34
, , ,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/372

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

Comments List

  1. 플레이어 2010/09/14 00:16 # M/D Reply Permalink

    저도 비슷한 경험을 겪습니다. 관리자 권한으로 실행시킨 프로그램으로는 드래그앤드롭이 안되는일이 있죠. 예로 팟플레이어를 관리자권한으로 실행하고 바탕화면에서 동영상을 드래그해서 놓아도 재생이 안 되더라구요. 이땐 explorer.exe를 관리자권한으로 실행시켜도 안되대요? 꼭 비관리자권한으로 실행시켜야 드래그앤드롭이 제대로.... ㅎㅎ

    1. 사무엘 2010/09/14 10:52 # M/D Permalink

      맞아요. 권한이 다른 프로그램끼리는 드래그 드롭도 잘 안 되더군요. 그것도 이유가 있었네요. =_=

Leave a comment

그동안 폐쇄적인 파일 포맷 정책 때문에 욕 많이 얻어먹고 있던 한컴에서 최근에, 한 지난달 말부터 꽤 놀라운 결정을 내렸다. 아래아한글의 파일 포맷(.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 사무엘

2010/07/19 09:03 2010/07/19 09:03
,
Response
No Trackback , 16 Comments
RSS :
http://moogi.new21.org/tc/rss/response/324

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

Comments List

  1. 삼각형 2010/07/19 14:17 # M/D Reply Permalink

    전 egg 포맷 공개(를 가장한 컨테이너와 공개와 unegg.dll 비상업 공개) 때 처럼 hwp뷰어가 금방 나올 줄 알았는데 의외로 아무 소식이 없더군요. 사전 허가 관련 문구도 지웠고 한데 말이지요.

    특히 리눅스 진형에서는 hwp에 원수진 집단이라 아주 허접한(텍스트만 뽑아주는 한이 있더라도) 뷰어/변환기라도 나올 줄 알았는데 말입니다.

    요즘 오피스로 작업한 문서를 보면 이제 FDD로는 오피스 문서 하나 못옮기는구나 하는 생각이 듭니다.(물론 txt라면 충분하겠지만요.)

    pptx나 docx는 확장자를 zip으로 바꾸면 풀리는데 hwp는 그렇지는 않더군요. 문서 내부만 zlib로 압축하는 것 같습니다.

    1. clue 2010/07/19 14:23 # M/D Permalink

      이제 3주일밖에 안 됐는데 뷰어가 뚝딱 나올리가 없지요. 1년 넘게 만들어야 완성도가 있을만한 수준이 나올 겁니다. 게다가 사전허가 문구는 없어졌지만 여전히 이상한 조건은 남아 있어서 리눅스에서 많이 쓰는 GPL이나 LGPL 라이선스로 프로그램을 만들 수가 없어요.

    2. 사무엘 2010/07/19 20:41 # M/D Permalink

      네. 오피스 2007의 *.???x 문서(암호가 걸리지 않은)는 zip 압축 파일의 일종이기 때문에 일반 압축 유틸리티로 그 내용을 볼 수 있습니다. 이는 OpenDocument 파일도 마찬가지입니다. 그러나 그 파일의 압축을 풀었다가 그 내용을 일반 압축 유틸리티로 다시 그대로 압축해서 만든 파일은 해당 오피스 프로그램에서 인식이 안 됩니다. 일반 압축 유틸리티에서는 넣어 주지 않는 자신만의 고유 식별자나 다른 정보가 들어가는 것 같아요.
      아래아한글은 말씀하신 대로 내부의 일부 데이터만 쟝 루프 게일리가 만든 zlib로 압축할 뿐, hwp 파일 자체는 zip 파일과 전혀 호환되지 않습니다. 나름 압축을 하는데도 파일 크기가 너무 큽니다. 압축을 안 하는 MS 오피스 97-2003 방식 문서 파일과도 비교가 됩니다.

  2. 김 민규 2010/07/21 21:44 # M/D Reply Permalink

    너무 심한 병크 ㅋㅋ 읽다가 웃음이 터졌네요.
    용묵 님 홈페이지에 계속 새로운 글이 올라와도, 느낌만은 그대로이군요.

    워드가 절대 한·글을 따라올 수 없는 부분들이 몇 개 있죠. 한·글에는 착착 붙는 맛이 있다고나 할까요.
    저도 그래서 메모장이나 날개셋 편집기를 넘어가야 되는 문서를 만들 때는 한·글을 사용합니다.
    하지만 다른 사람한테 제출하거나 그래야 되는 문서를 만들 때는 어쩔 수 없이 워드로 만듭니다.

    1. 사무엘 2010/07/22 00:21 # M/D Permalink

      민규 님, 오랜만에 뵙습니다. ^^ 요즘 어떻게 지내세요?
      ‘착착 붙는 맛’에 100% 적극 공감합니다.

  3. 김 민규 2010/07/25 22:15 # M/D Reply Permalink

    아이구;; 블로그 덧글인데 이런 걸 쓰려고 하니까 조금 이상하기도 합니다.
    저는 방학한 지 대략 한 달이 지났는데, .... ㅠㅠ 게임하고 만화 본 것 정도밖에 기억이 없습니다.
    이럴 때 여행도 다니고 책도 많이 읽고 그러라고 많은 사람들이 일관되게 말했는데,
    (말이 너무 웃긴가요? ㅋㅋ 하지만 저는 일관된다는 말을 좋아합니다. 우리말로는 아마 없는 것 같은데요, consistent)
    그렇게 못 해서 아주 후회하고 있습니다. 나머지 방학은 그러지 말아야겠죠.

    오늘 처음 봤는데, 블로그 들어오기 전에 반가운 이름이 있더라고요! 이거 진짜인가요?
    다음 학기엔 건물 안에서, 아니면 캠퍼스 안에서 용묵 님과 마주칠 수도 있는 건가요? ㅋㅋ

    1. 사무엘 2010/07/26 06:55 # M/D Permalink

      큭;; 그걸 이제 보셨다니.. ㅋㅋ 대문에다가는 써 놓은 지 한 달도 더 됐지요. 합격 확인하자마자 바로 고쳤으니까요. ㅋ
      블로그에도 진학을 암시하는 멘트를 한두 번 남기긴 했는데, 여긴 워낙 글이 많이 올라와서 곧 묻혀서 못 보신 듯.
      과가 너무 잘 맞아서 그 학교 말고는 선택의 여지가 없더군요.
      9월 입학이랍니다. 마곡 역에 이어 신촌에서 또 만나요. ^^
      (그 문맥에서 '일관되게'에 대응하는 순우리말로는 '줄곧'이 괜찮을 듯합니다.)

  4. 김 민규 2010/07/26 16:55 # M/D Reply Permalink

    변명이지만, 저는 한 달 전에 잠을 못 자고 교양과목 시험 들어가서 잠을 자는 정말 못된 짓을 저질렀습니다. 학부인데도 학생들을 못살게 구는 바람에 말 그대로 3학년이 아닌 '사망년' 생활을 했습니다. 그땐 책도 못 읽고, 게임도 못 하고, 해서 글도 제대로 읽지 못했습니다.
    요즘 올리신 글들은 거진 다 읽었지만, 어쨌든 오늘 RSS 추가라는 걸 했으니 이제 더 잘 읽을 수 있을 것 같습니다. 그런데 RSS는 받아서 읽는 것만 가능하고, 덧글을 쓸 수는 없군요. 이거 웹 계정에 괜한 트래픽만 소모하게 하는 것 같아서 걱정이 되네요.

    1. 사무엘 2010/07/26 20:18 # M/D Permalink

      저런..;; 방학 때 내일로 티켓 철도 여행이라도 가 보세요. ㅎㅎ
      그나저나 RSS가 되긴 되는가 보군요. 저는 그런 쪽은 전혀 몰라서..
      이 블로그 세팅을 도와 준 모 후배 녀석의 말에 따르면, 이 홈페이지 계정이 개떡 같아서 그렇다고 합니다. -_- 지금은 이런 서비스가 신규로 존재하지도 않으며, 기존 이용자의 서비스 기간 연장만 가능하지요.
      저 역시 저렴한 요금에 성능이 좋아서 꽤 오래 사용 중인데, 그 후배 말에 따르면 이렇게 소프트웨어 환경이 후진 걸 감안하면 그리 실속 있게 저렴한 것도 아니라고 하네요.

  5. shin 2013/02/16 19:44 # M/D Reply Permalink

    한컴2바이트 코드에 대해 궁금한 점이 있어 질문을 올립니다.
    한컴 2바이트 코드에서 다른 나라의 2바이트 문자, 예를 들어 한자나 특수기호 등은 2바이트로 그대로 출력되야되는데
    한글은 초성,중성,종성 5비트씩 결합되는데 그걸 구별하는법을 알고싶습니다.
    또 문자셋 등 코드를 저장해 놓을때 다른건 2바이트로 저장되있는데
    한글만 5비트씩 저장할수 있는지도 궁금합니다.

    1. 사무엘 2013/02/17 05:40 # M/D Permalink

      안녕하세요?
      한컴 2바이트 코드는 말 그대로 모든 문자가 내부적으로 2바이트입니다. 한글도 마찬가지죠. 한글의 경우, 초중종성은 5비트로 총 15비트를 차지하지만, 추가적으로 이 문자가 한글임을 나타내는 최상위 1비트가 추가되어 딱 16비트, 즉 2바이트를 이룹니다. 일부 완성형 옛한글도 존재하지만, 최상위 비트만은 공통으로 1이구요.
      이 때문에 최상위 비트가 1인 0x8000부터 0xFFFF는 한글 영역이고, 그 아래의 문자들은 비한글입니다. 특히 0x4000부터 0x7FFF는 한자 영역이죠.
      다만, 한컴 2바이트 코드는 오늘날 공식적으로 전혀 쓰이지 않는 죽은 문자 코드이기 때문에 살펴보시는 게 의미는 거의 없습니다.

  6. shin 2013/02/21 21:43 # M/D Reply Permalink

    아, 의외로 간단했었네요...
    정말 감사합니다.
    그런데, 그것외에도 2바이트 조합형의
    문자셋에서 다른것은 다 결합된 채로 2바이트씩 저장되어있는데,
    유독 한글만 초성,중성,종성이 5바이트씩 할당되게 할 수 있나요?
    (그리고 죽은 문자 코드이지만 단순히 호기심으로 찾아보는 것입니다. 그냥 궁금해서요ㅎㅎㅎ)

    1. 사무엘 2013/02/22 14:54 # M/D Permalink

      앞서 설명드렸듯, 한컴 2바이트 코드가 이미 그런 구조입니다. 또 무슨 가능/불가능 여부가 궁금하다는 것인지 질문 내용이 이해되지 않네요. (5비트를 5바이트라고 잘못 적은 거라 생각합니다.)

  7. cwryu 2013/10/27 00:50 # M/D Reply Permalink

    진짜 hwpx 포맷이 나왔습니다. 성지...

  8. ChickenHead 2013/10/27 02:27 # M/D Reply Permalink

    소문듣고 왔습니다.

    아래아한글 2010 정도면 MS 따라 hwpx-_- 같은 새로운 파일 포맷을 도입해도 이상할 게 없을 거라고 생각했는데 여전히 10년 전 포맷 그대로이다.

    .. 대박 ..

    > 표준 파일 형식 지원
    - HWP 문서의 콘텐츠 표현에 대한 *****KS 표준*****인 HWPX 형식을 지원하며 ... ( 2013.10.27 http://shop.hancom.com/goods/content.go )

  9. 사무엘 2013/10/27 14:29 # M/D Reply Permalink

    cwryu, ChickenHead:
    오.. 3년도 더 된 옛날 글을 기억하고 찾아 주셔서 감사합니다. 반갑습니다.
    어디 다른 커뮤니티에서 hwpx가 거론됐나 보네요. ^^;;

Leave a comment
윈도우 비스타/7에서는 아래아한글의 키매크로가 지원되지 않는다는 걸 며칠 전에야 처음으로 확인했다. 메뉴가 흐려져 있고 아예 선택이 되지 않더라. XP를 졸업한 지 2년이 넘었는데 몇 년째 이 사실을 왜 모른 채 지냈는지 모르겠다. 키매크로는 도스용 1.x 시절 이래로 아래아한글 고급 사용자의 최강의 애용 기능이었는데도 말이다.

아니 그럼 도움말에다가 언급이라도 해 놓지 왜 아무 설명도 없이 메뉴 접근만 막아 놨는지? 그 이유는 인터넷을 검색한 뒤에야 알 수 있었다. 물론 어느 정도 짐작은 했지만 말이다.
(아래아한글 2005는 비스타/7에서는 수 차례의 패치를 안 받으면 에러가 나고 아예 동작을 하지 않으며, 2007도 패치를 받아야 Aero가 적용된 운영체제 표준 모양 스킨을 쓸 수 있다. 비스타에서 키매크로 메뉴를 막은 것도 2005의 패치부터 그렇게 된 거라 함.)

비스타 이상부터는, 아래아한글이 키매크로를 구현할 때 쓰이는 기능 내지 테크닉이 운영체제의 보안에 영향을 끼친다고 간주되어 그걸 운영체제 차원에서 막아 버린 모양이다. UAC 끄고 관리자 모드로 실행해도 별 소용 없다.

사실, 도스가 아닌 윈도우 같은 이벤트 위주 환경에서 키매크로 같은 걸 구현하기는 쉽지 않다. 도스처럼 한 프로그램이 모든 하드웨어 자원을 장악하고 독점하고 일괄 처리를 하는 환경이 아니기 때문이다.
아래아한글이 윈도우용으로 처음으로 포팅되었던 3.0B 시절에는 기능은 분명 화려해졌다. 드디어 아래아한글에다가 윈도우용 TTF에다가 여타 프로그램의 OLE 개체를 집어넣는 게 가능해졌다니.. 그리고 도스용 아래아한글과 정보 손실 없이 파일 공유까지 가능하다니!

하지만 윈도우용에 매크로 기능은 응당 포팅이 안 돼 있었다.
Win32s에, 95에, NT까지 다 신경써야 하던 시절에 그렇게 하드웨어에 민감한 고급 기능을 넣기는 현실적으로 곤란했을 것이다. 내 기억이 맞다면 96까지도 아직 없었다.
그러다가 97에 와서야 프로그램이 Win32s를 제낀 체제로 개편되고 매크로 기능도 다시 생겼다.

그랬는데 한 가지 굉장히 신기한 것은, 매크로를 기록하는 파일 포맷이 9x 계열과 NT 계열이 서로 달랐다는 것이다. 아래아한글 사용 안내문에서 분명히 본 문장이다. 즉, 똑같은 97을 쓰는데, 윈도우 9x에서 녹화하여 저장한 매크로 파일을 NT4에 설치된 97에다 가져와서 쓸 수는 없으며 동일한 매크로를 해당 플랫폼에서 다시 만들어야 했다는 뜻이다.

도대체 무슨 데이터를 저장하기에 똑같은 x86 계열 컴퓨터에서 저장한 매크로 파일이 왜 서로 호환이 안 됐을까? 단순한 키 시퀀스를 저장한 게 아니라 아래아한글의 매크로 구현 방식이 아주 특이했을 거라는 짐작만을 해 볼 뿐이다.
본인은 나름 한컴사전의 노클릭 단어 인식 기능도 어떻게 구현했을지 대략 짐작할 정도이지만, 매크로에 대해서는 여전히 알쏭달쏭 갸우뚱이다. 노클릭 단어 인식도 훅 DLL이 9x과 NT 계열이 서로 별도로 존재하며, 심지어 16비트 프로그램용 훅 DLL까지 들어있다.

그렇게 아래아한글은 윈도우에서도 키매크로를 살려 내기는 했지만, 도스 시절 같은 빠른 속도까지 회복하지는 못했다. 전광석화처럼 화면이 깜빡이며 돌아가는 도스 매크로에 비해 윈도우는...;;
그냥 화면에 그림만 그리는 도스 시절의 대화상자와, 수십/수백 개의 개체로 이뤄진 윈도우 대화상자가 뜨는 오버헤드는... 서로 비교가 안 될 것이다.
게다가 Alt+L, K, T, A, D (블록으로 잡은 텍스트의 한글 서체를 궁서로 바꾸기) 같은 궁극의 단축키 신공도 느릿느릿 마우스 위주인 윈도우에서는 그대로 재현할 수 없게 됐다.

도스든 윈도우든 키매크로 자체를 구현할 정도라면, 매크로가 실행되는 중에 화면 업데이트를 안 하게 하는 옵션을 넣는 것도 불가능하지는 않을 것 같은데, 그것만 해도 매크로의 실행 속도를 무척 향상시킬 수 있지 않을까 싶다.

매크로는 일반적인 워드 프로세서 사용자보다 더 전문적인 컴덕후들이 즐겨 사용하는 텍스트 에디터에서는 더욱 필수인 기능이다. 비주얼 스튜디오의 경우 긴 매크로가 실행 중일 때는 트레이에 풍선 도움말도 뜨고, 이걸 건드리면 실행 중인 매크로를 손쉽게 중단도 시킬 수 있다. 아래아한글에도 이런 배려가 있었으면 좋겠다.

윈도우 환경에서는 도스 시절 같은 기계적인 키매크로의 의미가 여러 모로 퇴색한 만큼, 아래아한글도 최신 버전부터는 스크립트 기반 매크로를 지원하고 있다. 과거 PC 통신 에뮬인 이야기에 혼잣말 기능이 있었듯이. 키 조작이 아니라 키 조작이 의미하는 명령을 기록함으로써 좀더 똑똑하고 효율적인 매크로를 구현하고 간단한 프로그래밍 로직과 분기까지 구현한 것이다. 이 정도로 매크로가 능동적인 존재가 되고 나면, 슬슬 매크로의 보안도 따져야 할 필요가 생길 것이다.

스크립트 매크로는 키매크로와는 내부 구현 방식이 다른 듯하며, 아래아한글도 앞으로는 키매크로를 빼고 스크립트 매크로만 지원할 것으로 보인다.
그런데 스크립트 매크로를 이용하여 키 입력을 녹화해 봤는데 이상한 에러와 함께 실행이 안 돼서리...;;;
급하게 매크로를 수만 번 실행해야 할 일이 있는데 결국은 VMware 아래의 윈도우 XP에다가 아래아한글을 설치해서 키매크로 뺑이를 돌려야 했다. 아놔이런....;;;;;;;;

HWP.EXE의 속성-호환성 탭을 이용해서 운영체제의 버전을 일부러 낮춰 주면 매크로 메뉴를 사용은 할 수 있게 되나, 반복 실행이 되지 않았다. Alt+번호로 개개 실행도 속도가 매우 느렸다. 앞서 말했듯이 아래아한글의 키매크로는 어떻게 구현됐는지 정말 궁금할 따름이다.

제대로 된 매크로를 응용 프로그램이나 운영체제가 지원해 준다면, 매크로를 실행 중인 프로그램은 매크로 실행 결과를 실시간으로 업데이트 하든 안 하든, 최소한 응답이 없이 죽어서 ghost 윈도우가 되는 일은 없어야 하며, 언제든지 중단도 시킬 수 있어야 할 것이다. 그리고 다른 프로그램에서 사용자가 키 입력을 하든 말든 자기는 자기 일만 잘 하고 있어야 할 것이다.

그런데 아래아한글은 그렇지는 못한 것 같다. 매크로를 돌리고 나서 한참 컴퓨터를 가만 놔뒀더니, 화면 보호기가 갑툭튀 실행된 후로 프로그램 창은 거의 ghost 윈도우처럼 아무 응답이 없고, 게다가 그때부터 키보드 입력이 엉뚱한 곳으로 갔는지 매크로가 제대로 실행되어 있지 않았다. 이런 망할 화면 보호기.. -_-

요즘 사람들은 컴퓨터를 안 쓸 때도 그냥 켜 놓는 경우가 워낙 많기 때문에 컴퓨터 설계자들은 idle 상태일 때 전기를 최대한 아끼는 방법을 연구하는 게 당연지사이다.
그런데 가끔씩은 컴퓨터를 서버 용도로 쓸 때도 있고, 프레젠테이션 발표용으로 쓰기도 하고, 윗글처럼 일괄 처리를 시켜 놓는 경우도 있다. 그럴 때는 오랫동안 키보드 입력이 없다고 해서 컴퓨터가 함부로 툭 꺼져 버려서는 안 된다. 이 둘이 마치 교통수단의 이동성과 접근성처럼 동전의 양면 같은 면모가 아닐까 한다.

Posted by 사무엘

2010/05/20 08:32 2010/05/20 08:32
, ,
Response
No Trackback , 5 Comments
RSS :
http://moogi.new21.org/tc/rss/response/274

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

Comments List

  1. 다물 2010/05/24 15:55 # M/D Reply Permalink

    키매크로는 아시는대로 일부러 막았습니다.(MS가 공개해준 자료만 가지고는 정상 동작이 안된다고 하더군요.)
    스크립트 매크로 오류가 나는건 적어주신 글만 가지고는 자세히 알기 어렵습니다.
    좀 더 자세한 내용 적어 주시면 확인해 보겠습니다.

    1. 사무엘 2010/05/25 02:17 # M/D Permalink

      function OnScriptMacro_script3()
      {
      HAction.Run("MoveParaEnd");
      }

      같은 이런 간단한 문장 하나만 넣고 실행해도

      "스크립트 분석에 오류가 발생했습니다.
      설명: (null)
      줄 수: 0"

      이러고 매크로 실행이 전혀 안 된답니다.
      나름 copyright 2010이라고 찍힌 최신 패치가 다 적용된 아래아한글 2007인데..
      뭐가 문제인지 모르겠습니다.

    2. 다물 2010/05/25 13:38 # M/D Permalink

      2010은 잘 되는데 2007은 안되네요.
      좀 더 알아보고 답변 적겠습니다.

    3. 다물 2010/05/26 16:47 # M/D Permalink

      초기화를 해 보세요.

      제품 설치 후 다른 여러가지 요인으로 인해서 제품에 필요한 dll 파일 등록이 제대로 되지 않을 수 있다고 합니다.
      [한글과컴퓨터 기본 설정]을 실행시킨 후 처음 상태로 돌린 후에 확인 해 보세요.
      (답변 적은대로 안되면 전화나 메신저 주세요 - 지금은 메신저 접속 안되어 있으시네요.)

    4. 사무엘 2010/05/29 07:55 # M/D Permalink

      앗, 신기하네요.
      ‘처음 상태로 돌리기’를 체크하지도 않고
      그냥 ‘한글과컴퓨터 기본 설정’을 한번 실행만 해 준 뒤, 프로그램을 다시 실행하니까 매크로가 되기 시작합니다.
      키매크로든 스크립트 매크로든, 아래아한글의 매크로 구현 방식은 신기하게 그지없습니다.
      그래도 다물 님께서도 동일 현상을 확인하셨을 정도라면, 저 오류도 해결돼야 할 사소한 버그가 아닌가 생각됩니다.

Leave a comment

아래아한글 2010과 함초롬체

드디어 한컴 오피스 2010이 출시됐다. 2006년 한글날에 2007이 나온 지 3년 반 가까이 지나서이다. 하양+파란 컨셉이던 2007과는 달리 빨간 컨셉이 무척 인상적이었다.
2010 버전은 개발 중엔 코드네임이 '보난자'였다. bonanza.. 어원이 영어인 것 같지 않으나 영어이며, '노다지, 수지 맞는 일'이라는 뜻이다.

2007까지만 해도 국내 관공서 환경을 고려하여 윈도우 9x를 지원하고 비주얼 C++ 2003으로 빌드했는데 이제는 VC++ 2008로 완전히 탈바꿈했고 지원 플랫폼도 상향 조정되었다.
그리고 MS 오피스 2007의 리본에다가 기존 메뉴 인터페이스를 혼합한 나름 상당히 독창적인 인터페이스를 도입한 것을, 베타 시절부터 확인할 수 있었다. MS 오피스에서는 2007 SP2때부터 도입된, OpenDocument 스펙 지원도 아래아한글 차기 버전에서 약속된 사항 중 하나이기도 했다.

(2009년 여름 그때가 넥셀의 이름을 바꾸려고 막 고민하던 시절이었다. 베타테스터 신청만 해 놓고 활동은 거의 안 한 것에 대해서는 좀 송구스럽지만. -_-)

아래아한글 그쪽 제품은 지금까지 가정용으로는 상당히 비싼 가격 때문에 원성이 많았다.
물론 주 고객이 어차피 정부, 관공서이다 보니 그쪽으로는 비싼 가격으로 납품이 가능했겠지만, 아예 모든 개인 사용자를 잠재적인 불법 사용자로 간주하고 고객에서 배제하는 정책 때문에 한컴에 그나마 호의를 갖고 있던 사용자마저 잃은 것도 사실이다. 이를 의식해서인지 한컴 오피스 2010의 가격은 가정용과 기업용이 서로 굉장히 차이가 많이 난다.

이번 한컴 오피스 2010에서는, 아래아한글의 한글 입출력 체계가 워디안 이래로 거의 10년만에 크게 바뀌었다. 그 중심에는 새로 추가된 함초롬체가 있다. 한글 입력기의 개발자이며 글꼴 쪽으로 관심이 많은 본인은 이것도 당장 살펴보지 않을 수 없었다. 글꼴의 제작사는 윤디자인.

글자 모양이야 딱 맑은 고딕이나 네이버 나눔명조, 서울남산 같은 요즘 트렌드를 반영한 깔끔한 모양이다. 그러나 더 놀라운 점은 그 뒤에 있다.

결론부터 말하자면, 이제 아래아한글도 10년 가까이 고수해 온 한양PUA 대신 유니코드 5.2 표준으로 돌아왔다. 즉, <날개셋> 한글 입력기 5.x와 옛한글을 그대로 주고받을 수 있다. 받침 ㅃ이나 ㅗㅑ 같은 모음까지 다 포함해서 말이다. 이제 아래아한글까지 이 대열에 합류한 이상 한양PUA의 입지는 더욱 좁아지게 될 것이다.

오픈소스 쪽의 작품은 잘 모르겠지만, 유니코드 5.2 자모가 모두 들어있는 최초의 상업용--비록 일반 개인 PC 사용자에게는 무료 배포이지만-- 한글 글꼴이 바로 함초롬이 아닌가 한다.

과거 MS에서 도입한 한양 시스템 글꼴은 6*2*4벌로 옛한글을 매우 제한적으로 조합 가능했던 반면, 함초롬체는 옛한글 자모도 초성의 경우 15벌 가까이 디자인된 것도 있고 일반 현대 한글과 별 차이가 없을 정도로 매우 정교하게 잘 만들어져 있다. 이 어마어마한 옛한글 자형들을 그것도 볼드까지 모두 만들어 낸 서체 제작자에게 경의를 표한다. 함초롬은 옛한글 자모의 품질까지 크게 향상시켰다.

다만, 함초롬체는 매우 큰 약점이 있다.
옛한글의 조합은 아래아한글 내부에서만 된다!! ㅜ.ㅜ
옛한글 조합을 과거 MS의 서체처럼 GSUB, GPOS 같은 표준 오픈타입 기술로 구현한 게 아니며, 그 세부적인 조합 메카니즘은 여전히 아래아한글이라는 프로그램 내부에만 숨겨져 있다. 쉽게 말해 웹으로 치면, RIA 표준 기술 대신 액티브X를 썼다는 소리.

사실 그걸로 한글 특유의 정교한 3차원 조합 테이블을 오픈타입 스펙만으로 기술하기란 너무 복잡하고 어려운 면도 있을 것이다.
다른 프로그램에서는 옛한글 자모가 그냥 빨랫줄/직결식 글꼴처럼 모아쓰기 형태로 알아볼 수나 있는 최소한의 모양으로만 찍힌다.
뭐 그것도 없는 것보다는 훨씬 낫긴 하나, 옛한글 표현에 관한 한 포맷만 TTF이지 거의 아래아한글 전용 서체처럼 된 건 분명 아쉬운 점이다. 간단하게라도 오픈타입 테이블도 내장해 주면 참 좋았으련만.

그래도 이런 서체가 생긴 것만으로도 날개셋 도움말이라도 업데이트 할 사유가 생겼다.

Posted by 사무엘

2010/03/02 14:31 2010/03/02 14:31
, , ,
Response
No Trackback , 4 Comments
RSS :
http://moogi.new21.org/tc/rss/response/202

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

Comments List

  1. 부르심 2010/03/09 21:40 # M/D Reply Permalink

    며칠 전에 한컴오피스2010에 나온 걸 알았는데 홈에디션 가격이 저렴해서 이번에 하나 구입했어. MS오피스처럼 디자인이 많이 변경되었더라. 쓰기는 편할 듯 ^^

  2. 사무엘 2010/03/09 23:56 # M/D Reply Permalink

    잘 했다 ^^ (별 일 없이 잘 지내고 있지?)
    그게 리본 컨셉이긴 한데 키보드 매니아에게 편한 메뉴도 같이 넣은 게 무척 참신하더군.
    그나저나 2007 때부터 도입한 파란 스킨은 2010에서도 계속 도입하려는 듯이 보이고.
    우리는 이제 MS 오피스 스타일 안 따라가고 우리만의 비주얼을 고수하겠다는 기싸움이 아닌가 싶다. ^^

    나도 지금까지 한컴의 정책이 다 마음에 드는 건 아니었지만 --가령 대표적인 예로 HWP 뷰어--
    컴퓨터 깨나 하는 파워 유저들 중에 여전히 한컴에 대해 안티 성향인 사람이 많은 건 좀 안타까움.

  3. 이기황 2010/11/03 21:25 # M/D Reply Permalink

    한국텍학회에서 오픈타입 자질을 만들어 넣었습니다.

    http://faq.ktug.or.kr/faq/%C7%D4%C3%CA%B7%D2%C3%BC/GSUB

    1. 사무엘 2010/11/03 23:27 # M/D Permalink

      와.. 결국은 이런 작품도 나왔군요. 멋집니다!
      (선생님, 여기서 뵙다니 제가 영광입니다. ^^;;;;)

Leave a comment

벌써 10년 전의 일이군요. ㅎㄷㄷㄷ
완전 책을 만들어서 출품했었습니다. 아래아한글 97 이용.

사용자 삽입 이미지

사용자 삽입 이미지
사용자 삽입 이미지
사용자 삽입 이미지

Posted by 사무엘

2010/01/13 01:18 2010/01/13 01:18
, ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/129

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

Leave a comment

블로그 이미지

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

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2019/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:
1219085
Today:
307
Yesterday:
625