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

황금도끼 도스용 버전을 처음 해 본 게 초등학교 고학년이던 92년이었습니다.
그 후 무려 17년이 지나서 몇 달 전에.. 마메를 돌려서 오락실 아케이드 버전을 처음으로 해 봤습니다. -_-;;

둘을 충분히 해 보고서 내린 결론은
도스용과 오락실용의 차이는 아래아한글과 MS 워드의 차이와 비슷하다는 것. =_=;;;;
모든 동작 방식이 손에 익어 있고 예측 가능한 아래아한글과는 달리, MS 워드류는 영 적응이 안 되는 야생마 같습니다.

도스용은 눈에 띌 정도로 스프라이트 수가 엄청 감소(strip down)해 있다는 것을 알 수 있었습니다. 메모리가 부족해서 그런 거겠죠. 그리고 원본에 존재하던 다중 스크롤도 삭제되었고, 움직이던 독수리 눈도 도스용에서는 응당 정지해 있습니다.

때리는 프레임이 남자와 여자는 2프레임, 그리고 가장 날렵한 캐릭터인 난쟁이 할아버지는 단 1프레임이죠. 뛰기 전에 잠깐 다리를 굽히는 동작도 오락실에는 있지만 PC에는 없습니다.

하지만 이 덕분에 PC판이 주인공의 조작 반응성이 더 날렵-_-해진 것은 있습니다. 오락실은 타이밍을 놓쳐서 적이 나의 때리기 공격을 피하고 반격을 하는 게 가능하지만 PC는 거의 그런 게 없지요. 물론 나뿐만 아니라 적도 더 날렵해졌지만.. -_-;; 때리면 거의 무조건 맞거나 아니면 아예 피하거나 이뿐입니다.

1단계에 나오는 꼬리로 공격하는 괴물은 PC판보다 다루기가 훨씬 더 어렵고 불을 쏘는 용도 발사 후의 cooldown이 굉장히 길어서 운용하기 어렵습니다. 그거 발사한 후 뒤의 적에게 반격을 당하기 쉽습니다.
PC판은 용에서 한번 떨어지고 나면 용은 거의 즉시 달아나 버리는 반면, 오락실판은 그래도 관용이 좀 있더군요.

몬스터의 AI도 원판이 훨씬 더 강력합니다. 작은 몬스터도 점프 공격을 하며, 해골은 훨씬 더 똑똑하고 무섭고 공격 데미지가 강합니다. PC판은 해골은 남자 몬스터와 체력도 일치하고, 점프 공격을 할 줄 아는 것 외에 딱히 차이가 없거든요. 사실, 몬스터별 체력이라든가 데미지 체계도 PC판은 딱 정해져 있는 반면 오락실판은 이미 수십 판을 해 봤는데도 파악이 잘 안 되겠더군요.

몬스터는 PC판처럼 무조건 주인공을 향해 접근만 하는 게 아니라 근처에 용이 있으면 용부터 탑니다. 그리고 PC판처럼 x축부터 일치시킨 후 y축으로 접근하는 게 아니라, y축부터 일치시킨 후 달리기 박치기 시도를 굉장히 잘 합니다. 이런 이유로 인해 용 같은 걸 뺏어 타기도 PC판보다 더 어렵습니다.

그리고 무엇보다도 오락실판이 PC판보다 어렵고 전략 전술을 근본적으로 다시 짜게 만드는 원인은.. 바로 근거리 공격 때문입니다.
PC판은 모든 몬스터들은 주인공이 너무 바싹 붙어 있으면 일단 뒤로 물러나서 일정 거리를 확보한 후 공격합니다. 게다가 다른 AI가 전반적으로 무척 멍청하기 때문에, PC판으로는 한 대도 안 맞고 엔딩 보는 것도 가능합니다.

하지만 오락실판은 그렇지 않으며 얄짤없이 근거리에 있는 주인공은 곧바로 공격합니다. 매우 위험합니다. 게다가 큰 몬스터인 대머리 아저씨나 칼 든 기사는 주인공을 내던지기까지 하며, 원거리에서도 공격 성향이 더욱 짙습니다. 용 없이 기사 두 명을 피해 없이 상대하는 건 거의 불가능에 가깝습니다. (제가 보기엔) 큰 몬스터를 향해 날라차기를 해도 실패하고 반격 당할 확률이 훨씬 더 높고요.

다만, 오락실판에만 존재하는 필살기가 있더군요(마법 쓰는 것 말고). 뛰면서 위로 점프한 후, 칼을 아래로 내리찍기. 이게 데미지가 굉장히 커서 작은 몬스터는 한 방에 바로 골로 보내더군요.
PC판의 몬스터라면 100% 저게 성공일 텐데, 오락실판 몬스터는 그걸 피할 줄 압니다. PC판은 몬스터가 y축으로 왔다갔다 하는 걸 거의 볼 일이 없는 반면 오락실판은 y축으로 이동하여 필살 공격을 회피할 줄 압니다. 그래서 제일 밑으로 내려가서 회피를 못 하게 하고 때리면 성공률이 꽤 높습니다.

오락실판은 날라차기를 하다가 목표물을 맞으면 목표물이 힘을 받아 튕겨나가고 나는 추진력이 탁 떨어지기 때문에 타격감과 탄성을 느끼죠. 하지만 PC판은 목표물을 맞든 안 맞든 언제나 정해진 공식만큼 앞으로 나아갑니다. 기계적입니다. 오락실판은 도둑을 때려서 나온 물약병도 통통 튀지만, PC판은 그렇지 않습니다.

이런 것 말고도, 오락실판은 PC판에서 게임의 쾌감을 떨어뜨리던 그런 요인들이 없습니다.
가령, 열심히 때리고 한 몬스터를 집어 던지는 모션을 취하느라 uncontrollable한 도중에는 다른 몬스터가 나를 공격하지 않습니다. 저 경우를 따로 배려를 했다는 걸 단번에 알 수 있었습니다. PC판은 나도 반격을 당해 튕겨 나가고 잡혀 있던 몬스터도 같이 튕겨 나가는 어색한 상황이 벌어지죠.

난쟁이 도둑을 때리면 PC판은 완전 랜덤한 다른 위치로 도망가 버려서 일일이 쫓아다니며 또 때려야 하지만 오락실판은 원래 있던 곳에서 그렇게 멀리 나가지 않으며, 또한 도둑을 때리기도 훨씬 더 쉽습니다. 어지간히 날라차기를 해도 맞고, 불을 쏘는 용으로도 굉장히 쉽게 맞힐 수 있습니다. 도둑이 약병을 다 내 준 뒤에도 이따금씩 가만히 죽어 버려서 게임 진행을 더 못 하고 끝내야 하는 버그도 오락실판에는 전혀 존재하지 않죠.

또한 '해골 다구리'. 가끔 여러 해골들이 있는 상태에서 막다른 곳에 몰리면, 해골들이 나를 일어나서 반격할 틈도 안 주고 계속 점프 공격을 해서 결국 죽게 만드는 경우가 PC판에는 있습니다. 오락실판은 그런 식의 공격 패턴을 지니고 있지는 않거든요.
여러모로 PC판보다 더 신경을 쓰고, 쓸데없는 것 갖고 사용자를 짜증 나지 않게 설계가 돼 있다는 것을 알 수 있었습니다. 다만, 단거리 공격까지 틈을 조금도 안 주는 거는 너무 어렵습니다.

오락실용은 세 마리 정도는 죽고 엔딩을 봤습니다. 점수는 230점대, strength는 85점까지는 가 봤네요.

Posted by 사무엘

윈도우 비스타에서는 모르긴 몰라도 그래픽/사운드 기술과 관련된 계층이 굉장히 많이 바뀌었습니다.

※ 비디오 (그래픽)

예전에 글로 쓴 적이 있지만 제가 가장 먼저 인지한 큰 변화는, 이제 동영상 화면까지 Print Screen 키로 바로 캡처가 된다는 것. 그것도 Aero (desktop window manager)가 가동 중일 때뿐만 아니라 DWM이 돌아가지 않는 고전 모드일 때도 동일하게 잘 됩니다. 옛날에는 인터넷 같은 데서 웹브라우저 창을 옮기면 그 안에서 돌아가던 동영상은 위치가 이동하지 않거나 느릿느릿 굼뜨던 현상도 심심찮게 볼 수 있었는데 이 역시 비스타에서는 아련한 추억이 됐지요. 그래픽 카드와 운영체제의 발전에 힘입어, 드라이버 계층에서의 어떤 큰 변화가 생긴 게 틀림없습니다.

멀쩡하게 상위 계층의 윈도우 API만 썼다면 비스타라고 해도 안 돌아갈 이유가 없는데, VMware, 메이플, 비주얼 스튜디오 같은 프로그램들이 옛 버전이 비스타에서는 제대로 동작하지 않아 버전업을 해야만 하는 이유도 저런 ‘저수준에서의 미묘한 변화’ 때문이라고 풀이할 수 있겠습니다. XP와 비스타는 각종 하드웨어 드라이버들이 호환되지 않죠. 하지만 비스타와 7은 드라이버 차원의 호환이 유지될 것으로 알려져 있습니다.

윈도우 XP부터는 심지어 운영체제 설치 GUI나 안전 모드에서도 VGA 640*480 16컬러는 완전히 자취를 감추었고, 하이 컬러 이하로는 디스플레이 모드가 설정이 되지도 않습니다. 게임용 3D 그래픽 가속까지는 뒷받침을 원활히 못 하더라도, 최소한 1024*768 하이컬러 이상급의 그래픽 모드는 메인보드가 내장하는 VBE 규격만으로도 지원되게 컴퓨터 규격이 향상됐기 때문이지요. 물론 이것만으로는 비스타 체험 지수는 1밖에 나오지 못하며, 창을 끌어 보기만 해도 답답함이 느껴지기 때문에 비디오 카드 드라이버 업데이트는 필수입니다.

XP보다 전에 선보였던 윈도우 2000은 시대가 시대였으니만큼 여전히 16/256컬러의 잔재를 볼 수 있습니다. 하지만 설령 안전 모드의 16컬러 표준 VGA에서 실행될 때라 하더라도, 그래픽이 쉴 새 없이 변하고 있는 곳에 마우스 포인터를 가져갔을 때 포인터가 깜빡거리거나 사라지지 않습니다. 윈도우 9x 시절에는 상상도 할 수 없었는데! 이걸 보고도 저는 당시 2000은 보통 운영체제가 아니라는 생각을 했었습니다. 하드웨어 차원의 지원이 필요하거든요.

90년대 말, 윈도우 95급 컴퓨터 시절에만 해도(메인보드의 폼 팩터가 슬슬 AT에서 ATX로 넘어가던..), 운영체제의 표준 디폴트 포인터만 깜빡임 보호가 되었지 사용자 정의 포인터는 여전히 깜빡거렸습니다. 비디오 카드의 성능이 썩 좋지 못했다는 뜻이겠죠. 하지만 몇 년 사이에 이마저도 깜빡임이 완전히 사라졌습니다.

아, 그러고 보니 이것도 그래픽 체계의 변화와 관계가 있는지는 모르겠지만, 비스타는 알 수 없는 이유로 인해 콘솔을 전체 화면 모드에서 실행하는 기능이 사라졌고(무조건 창 모드만 가능), 콘솔에다가 파일이나 디렉터리 이름을 마우스로 드래그하여 떨어뜨리는 기능도 없어졌지요.

※ 오디오 (사운드)

지금까지 열거한 비디오 쪽뿐만 아니라 오디오 계층도 윈도우 비스타는 굉장히 많이 바뀌었습니다.
일단 윈도우 95부터 XP까지 큰 차이 없이 제공되던 볼륨 조절 유틸리티 sndvol32.exe가 없어지고 비슷한 기능을 sndvol.exe가 대신 담당하기 시작했는데, 인터페이스가 싹 달라졌죠.

옛날에는 컴퓨터 내부에 소리를 만들어내는 ‘장치’가 여럿 존재했고 윈도우 XP까지는 각 장치들을 멀티미디어 API를 써서 enumerate한 뒤, 장치별로 볼륨을 조절하는 구도였습니다. PC 스피커 따로, 애드립 소리를 내는 미디 따로, 오디오 CD 따로, 입력 단자 따로, 그리고 일반 wave 오디오 따로! (PC 스피커는 볼륨 조절이 되지 않는 게 보통이지만, 노트북 컴퓨터 중엔 그것도 조절되는 게 있었답니다.)

특히 CD롬 드라이브는 CPU와는 전혀 상관없이 자기가 직접 오디오 CD를 재생했습니다. 윈도우 95 시절의 CD 재생기는 그저 오디오 CD에다가 재생/정지/탐색 명령을 내리고, 드라이브로부터 트랙별 시간 정보를 가져와서 재생 지점을 업데이트해 주는 ‘시다바리’ 기능밖에 하지 않았었습니다. 당시 도스용 퀘이크 같은 게임은 오디오 CD 겸 CD롬 형태로 게임을 만들어서 게임 음악은 아예 오디오 트랙의 형태로 제공하기도 했지요.

그러나 지금은 시대가 바뀌었습니다. 사운드 카드는 이제 랜 카드와 더불어 메인보드의 일부로서 완전히 편입이 되어 버렸습니다. 그리고 소리를 내는 모든 장치는 가장 범용적인 매체인 wave 오디오로 통합이 되어 버렸습니다. 이는 전적으로 컴퓨터 성능이 좋아진 덕분입니다.

미디는 이제 어설픈 FM 사운드가 아니라, 소프트웨어적으로 노래방 수준 음향을 wave 오디오로 흉내 내어 주는 신시사이저가 재생합니다. 오디오 CD도 마찬가지. 컴퓨터가 디지털 음원을 일일이 추출, 파악해서 wave 오디오로 내보내는 건 요즘 필수입니다. 그래야 파형 visualization도 보여주고 mp3/wma 리핑 기능도 제공할 수 있을 테니까요.

사정이 이러하니 예전처럼 ‘장치’별 볼륨 조절은 완전히 무의미해졌습니다. 그건 한 프로그램이 어떤 장치를 꺼내서 소리를 출력하면 다른 프로그램은 그 장치를 이용할 수 없던, 쉽게 말해서 멀티웨이브조차 안 되던 윈도우 3.1~95 캐 암울하던 시절의 사고방식이죠. 그나마 wave 오디오의 멀티웨이브는 윈도우 98~2000급으로 넘어가면서 가능해졌지만, 여전히 애드립 미디 같은 다른 장치는 멀티웨이브가 되지 않았었습니다.

비스타부터는 운영체제가 모든 사운드를 wave 오디오 하나로 통제하고 믹싱까지 담당합니다. 그래서 비스타의 볼륨 조절 프로그램을 살펴보면 예전과 같은 개념의 장치 구분은 완전히 사라지고, 현재 실행 중인 응용 프로그램별로 상대적 볼륨을 조절하는 게이지가 나와 있습니다. 이거야말로 윈도우 XP 이하에서는 상상조차 할 수 없던 일이었지 않습니까?

※ 윈도우 각 버전별 비교

Aero Flip3D를 보면서 신기해하던 게 엊그제 같은데 비스타와 오피스 2007이 나온 지도 벌써 2년이 넘었습니다. 제가 XP를 주 작업용 OS로는 ‘빠이빠이’ 한 지도 반 년은 넘은 것 같습니다. 이제는 윈도우 7이 나온다고 해도 비스타하고 시간 간격은 윈도우 95와 98 사이의 간격과 별 차이가 안 날 정도로 시간이 흐른 셈이군요. 그렇게 긴 시간이 지난 것 같지는 않은데.

비스타는 XP 이후로 꽤 긴 시간만에 출시된 데다 상당히 무거운 편인 컴퓨터 요구 사양, 그리고 이질적으로 바뀐 보안 정책, 일부 옛날 프로그램과의 호환성 문제 같은 여러 잡음 때문에 비스타는 그 기술적인 우수성에 비해서는 그렇게까지 환영 받지는 못한 것 같습니다. 그래서 MS도 7에다가 더 전략 가중치를 더 부여하고 있는 듯하기도 하고요.

약 2001~2002년경에 2000/ME/XP 이던 구도가 앞으로는 조만간 XP/비스타/7이 되지 않을까 싶습니다. 비스타는 ME와는 급이 다른 운영체제임에도 불구하고! 차라리 7로 갈아타면 탔지, XP는 앞으로도 한동안은 없어지지 않을 최장수 운영체제로 기억에 남을 것 같습니다.

저의 주 개발 분야인 문자 입출력 쪽만 보더라도 비스타는 일단 TSF를 주된 입력 프로토콜로 완전히 굳혀서 운영체제의 기본 입력기로 지정도 가능하게 했고(XP는 여전히 IME 모듈만 가능함), 일부 TSF A급 확장 프로토콜도 도입했으며 전세계 모든 언어 입력기와 글꼴을 다 내장하고 있습니다. XP로 치자면 ‘동아시아 및 complex script 지원’ 옵션이 선택의 여지 없이 무조건 켜져 있는 것과 같다는 뜻입니다.

한자 글꼴도 단순히 ‘한중일 통합 한자’뿐만 아니라 확장 A, 그리고 심지어 surrogate 영역의 확장 B까지도 Simsun-extB 같은 외국의 확장 글꼴까지 자동으로 대체 동원해서 운영체제 차원에서 제대로 표시해 주는 걸 보고 정말 놀랐습니다. 비스타에서는 굳이 ‘한컴바탕확장’이 없어도 이런 한자들을 어디서나 볼 수 있습니다. <날개셋> 다음 버전에서는 글꼴을 본뜰 때 이런 점도 감안하도록 수정할 예정입니다.

윈도우 ME는 잘 알다시피 태생이 9x 계열이기 때문에 95 이래로 변함없던 유니코드 API 부재, 지저분한 16비트 도스의 잔재에다 불안정한 커널, 64K 리소스 제한 같은 단점은 고스란히 갖고 있습니다. 그래서 비슷한 시기에 나온 2000보다는 95/98과 더 동일시됩니다. 안정성은 떨어지는 주제에 덩치만 더 무거워지고, 겉보기로만 도스로 빠져나가는 옵션은 또 없애 놓으니, 도스와의 호환성 때문에 9x 계열 운영체제를 찾는 파워 유저로부터조차도 외면 받을 수밖에 없었습니다.

하지만 ME도 98 SE에 비해서 장점이 없는 것은 아니어서, 부팅 속도가 매우 빠르고 최신 하드웨어 인식은 역시 98보다 확실히 더 탁월하여 2000급에 필적합니다. VMware로 각 운영체제들의 가상 머신을 만들어 보면 2000/ME 이상은 사운드가 자동으로 잡히는 반면, 95/98은 그렇지 않습니다. 또한 2000/ME부터가 미디 신시사이저를 기본 내장하고 있고 멀티웨이브 기능도 더 원활하게 잘 감지됐습니다. 외장 하드와 USB 메모리를 별도의 드라이버 설치 없이 바로 인식하고, ‘하드웨어 안전하게 제거’ 기능을 갖추고 있는 것도 2000/ME부터입니다.

Posted by 사무엘

아래아한글 2007은 2006년 한글날에 출시되었던 초창기 RTM 판을 어둠의 경로로나 잠깐 구해 쓰다가 다시 2005로 돌아와 버렸고, 저는 그 존재감을 1년이 넘게 잊고 지내 왔습니다.

그런데 얼마 전 한 지인께서 보내 주신 아래아한글 2007은 정말 사뭇 달라진 모습이었습니다.
사실 아래아한글이 그 때 이후로 3년에 가까운 시간 동안 아직까지 메이저 버전업이 없는 상태이긴 하지만 그래도 제품 개선은 정말 꾸준히 돼 오고 있었습니다. MS 식으로 표현하자면, 단순한 버그/보안 업데이트 수준을 넘어 서비스 팩 정도는 된다는 거지요.

각종 패치와 업데이트를 다 받고 나니 버전은 7.5.8.527이 되었습니다. 아래아한글도 날개셋과 마찬가지로 비주얼 C++ 2003 (7.1)로 개발되고 있는 건 여전하고요.
윈도우 비스타에서 “시스템 스타일” 테마를 쓰면드디어 Aero 반투명 프레임이 적용된 대화상자가 나오더군요. (2005는 그렇지 않았음.) 윈도우 XP 시절엔 MS 오피스 2003 테마가 그럭저럭 볼만 했으나 비스타에서는 아주 밍밍하고 보기 안 좋은 모양이 돼 버리기 때문에 차라리 아래아한글 2007 특유의 기본 블루 메탈 테마나 시스템 스타일 테마가 낫습니다.

지금까지 아래아한글은 대화상자에서 숫자만 입력 받는 에디트 컨트롤의 동작이 정말 기괴했습니다. 글씨 크기나 여백량 등. 세벌식 자판을 쓰고 있으면, 2004 이하에서는 Shift+알파벳의 고유 숫자도 동작을 안 하고, 0~9의 쿼티 숫자 배열도 동작을 안 해서 꼼짝없이 글자판을 바꾸거나 numlock 키패드만 써야 했습니다. 그러던 것이 2005에서는 Shift+알파벳 숫자는 인식되도록 개선됐고, 2007에서는 숫자 입력란에서는 아예 한글 글자판이 동작 안 하고 무조건 0~9 숫자만 인식하게 바뀌었던데 저는 차라리 이런 결정을 환영합니다. 정말 속 답답하던 동작 방식이었는데 무척 잘 했습니다.

글꼴을 고르는 콤보 박스가 화살표 키 선택만 가능한 게 아니라 이름을 입력도 해서 빠르게 찾을 수 있게 된 것은 매우 환영할 만한 기능. 비주얼 C++ IDE는 2003에서 2005 이후로 넘어가면서 이런 점에선 오히려 퇴보했죠. (물론 글꼴이 주류인 프로그램은 아니지만.)

그리고 운영체제 한글 IME로 비완성형 문자가 ?로 바뀌고 제대로 입력되지 않던 버그.. 드디어 고쳐진 것을 확인했습니다. 이제 아래아한글로도 <날개셋> 한글 입력기를 띄워서 각종 확장 한자나 옛한글까지 그대로 입력할 수 있습니다.

어떤 프로그램이 유니코드를 얼마나 잘 대비해서 만들어졌는지 측정하는 좋은 척도 중 하나는 파일 이름 인식인데요.
제가 보기엔 아래아한글은 아직도 윈도우 9x를 지원하느라, 혹은 TCHAR 같은 범용 자료형으로 Unicode-prepared된 코드를 작성해 놓지를 못해서... 하이튼 이 둘 중 한 이유로 인해 과감하게 스위치를 유니코드로 바꿔서 빌드 못 하고,
당장 유니코드 문자 지원이 절대적으로 필요한 부분에다가만 유니코드 함수를 임시방편으로 끼워넣은 거라는 인상을 받습니다. 윈도우 XP sp2 이상만 지원하는 MS 오피스 2007과는 달리, 한컴 제품은 똑같은 2007이 무려 윈도우 98 이상을 지원한다고 명시하고 있지요.. 물론 날개셋은 윈도우 95/NT4까지 다 지원.. 그러고도 유니코드도 100% 지원하죠.

임시방편이라고 생각하는 근거를 말씀드리자면..
영문 윈도우에서 HWP 파일은 한글이 섞인 파일도 잘 불러옵니다. 한글이 섞인 디렉터리 이동도 되고 파일 열기도 대화상자와 drag/drop 방식 모두 잘 되더군요. 이것만 해도 크게 개선된 것입니다. 하지만 HWP가 아닌 TXT 파일은 열리지 않았습니다. 더구나 “다른 프로세스가 파일을 사용 중이어서 열 수 없습니다”라고 에러 메시지도 ‘잘못’ 나오고요.따로 처리할 이유가 전혀 없는데도 파일 타입에 따라 유니코드 API 사용 여부를 따로 처리하고 있으니, 일관성 있는 처리가 아니라 HWP에다가만 임시방편 처리를 추가한 거라는 결론을 잠정적으로 내린 것이죠. 또한 ‘열기’ 대화상자라든가 타이틀에 뜨는 문서 파일 이름이 여전히 ???? 로 바뀌어 나온다는 것도 개선돼야 할 것입니다. 진짜로 여기서는 Ansi, 저기서는 유니코드 API를 섞어 쓴 것입니다.

한편, 아래아한글도 드디어 2007 나중판에서는 문서를 PDF로 저장? 인쇄? 하는 기능이 자체 포함되었습니다. 예전에 별개의 제품으로 팔던 PDF converter 엔진이 그대로 포함되어, 자체 글꼴인 HFT까지도 깔끔한 PDF로 바꿔 줍니다! 2.5 확장팩 시절의 추억의 신명 시스템 글꼴과 3.0/96 때의 #로 시작하는 수많은 글꼴들을 이제 깔끔한 PDF로 만날 수 있어 무한 감개무량하며 앞으로 아래아한글 쓸 일이 더욱 늘 것 같습니다.

단, 하나 옥의 티를 찾았는데요.
HFT 영문 이탤릭 글꼴이 PDF로 제대로 인쇄되지 않고 그냥 normal 글꼴을 기울인 형태로 바뀌어 버리더군요.
아래아한글이 내장하고 있는 신명조와 윈도우 운영체제가 내장하고 있는 바탕은 둘 다 ‘한양 시스템’에서 제작했으며 원도가 거의 일치합니다. 물론 후자가 영문의 폭이 좀더 크긴 하지만 비슷하죠.

하지만 둘의 큰 차이를 하나 꼽자면 전자는 영문에 이탤릭 전용 글꼴이 있다는 것입니다.
더구나 아래아한글 2.5 정도에서 추가된 걸로 기억하는 수식 전용 글꼴은 당시 교과서와 문제집 같은 출판물에서나 볼 수 있던 그 자형을 재현한 것이어서 더욱 의미가 컸습니다. 이것도 이탤릭체가 없으면 거의 무용지물이죠. 이것이 PDF로 만들면 여전히 되살아나지 않으니 개선이 필요하다고 봅니다.

끝으로 이건 극소수 매니아 계층 이외에게는 거의 의미가 없을 내용이지만 제품의 완성도 차원에서 하나 언급하겠습니다. 아래아한글의 한자 코드 체계와 관련이 있는 내용입니다.
아래아한글 2.0 이후에서부터 추가된 약 11000여 자의 제 2 수준 한자는 유니코드 BMP 영역에 대부분 이미 존재하지만(A급), 어떤 건 BMP에 없고 무려 surrogate 영역(B급)까지 가야 하는 것도 있으며 어떤 건 아예 유니코드 자체에 아직 정식 등재되지 않은 것(C급)도 있습니다. 물론 유니코드 버전이 계속 올라가면서 C급 한자라는 집합은 완전히 사라질 수도 있지요. 지금도 C급 한자는 거의 10여 자 남짓밖에 안 됩니다.

아래아한글은 이미 제 2수준 한자와 유니코드 사이의 변환 테이블도 다 갖추고 있고 이를 문자표에다 제공하고 있습니다. 하지만 정작 한컴 2바이트 코드로 저장된 파일을 가져와 보면 아래아한글이 지금처럼 유니코드 surrogate를 정식 지원하기 전에 워디안/2002 시절에 임시로 사용하던 변환 테이블을 여전히 수정하지 않은 것 같습니다.
가령 B급 한자에 속하는 0x531C는 한중일 통합 한자 확장 B인 U+20850 (surrogate 영역)이지만 이 글자를 한컴 2바이트 코드로 저장하여 불러와 보면, 옛날의 임시 주소인 U+A700이라는 엉뚱한 문자가 되지요.

아래아한글은 97에서 워디안으로 넘어갈 때 정말 큰 진통을 겪긴 했지만 그래도 그때 고비를 잘 넘긴 것 같습니다. 그때 HWP 파일 포맷이 딱 바뀐 이후, 지금은 아랍 어, 세로쓰기, 문서 워터마크 등 문서의 뼈대 구조를 결정하는 굵직한 기능이 엄청 많이 추가되었음에도 불구하고 워디안부터 2007까지 파일 포맷이 근본적으로 바뀌는 일 없이 하위/상위 호환성이 잘 유지되고 있으니까요.

다음 버전(아마 2010)은 지금 MS 오피스 다음 버전이 추구하고 있는 것과 마찬가지로 ODF 스펙 구현이 몰두 중이라고 합니다. 개인적인 생각은 아래아한글도 어서 워드처럼 개체가 사각형이 아닌 모양으로 본문을 감싸는 기능이 지원돼야 한다고 생각합니다. 앞서 지적했지만 유니코드 지원도 강화돼야 할 것이고, 좀더 욕심을 부리면 워드처럼 TSF A급 프로그램으로 발전하고 한양 PUA가 아닌 유니코드 낱자 결합 방식으로 옛한글을 지원해야 할 텐데, 참 가야 할 길이 멀군요!

Posted by 사무엘

※ 1기: 1.x 커널

아래아한글 1.x 시절의 에디팅 엔진입니다. 잘 알다시피 단순한 plain text에다가 약간의 서식만 붙은 것 같은 초보적인 형태였죠.
글씨의 크기 조절은 가로 확대/세로 확대만 되고 가변폭 글꼴은 사실상 지원되지 않았으며, 문단 여백도 그냥 칸 수로 지정하던 시절이었습니다. 표는 선그리기 기능으로 그려야 했습니다.
문서의 파일 포맷은 최소한 1.0, 1.1, 1.2 이렇게 세 방식 이상이 존재했던 것 같습니다. 아래아한글 1.5x는 1.2 방식과 문서 파일 포맷이 동일하며, Alt+V (새 이름으로 저장)를 누르면 과거 1.1 방식으로 저장도 할 수 있습니다.

※ 2기: 2.0 커널

1992년에 출시된 2.0부터 97까지 굉장히 장수하여 안정화한 한컴 2바이트 코드 기반의 에디팅 엔진입니다. 글씨 크기를 포인트로, 여백은 mm 같은 단위로 지정할 수 있게 되고 색깔도 8종류 중 하나로 지정할 수 있게 됐습니다. 가변폭 글꼴의 표현이 가능해지고 그림, 표 같은 각종 개체를 넣을 수 있게 됐습니다. 개요, 스타일 같은 개념도 생겼죠.

문서 파일 포맷은 2.0, 2.1, 3.0으로 나뉩니다. 사실 아래아한글 2.1은 기능면에서는 2.0과 그렇게 큰 차이가 없으나, 글꼴 쪽으로 굉장히 많은 변화가 생겼고 또 2.1에서 문서 압축 저장이 추가됐기 때문에 포맷이 바뀐 것으로 기억합니다. 아래아한글 2.5는 파일 포맷의 변동이 없었기 때문에 2.1과 포맷이 동일합니다.
3.0은 하이퍼텍스트라든가 자체 벡터 드로잉 기능, 그리고 윈도우 OLE 데이터 같은 것을 저장해야 하는 데다, 때마침 2.1 방식 문서 파일의 암호가 크랙되어서 큰 논란을 겪기도 했기 때문에 바뀌었지 싶습니다.

※ 3기: 21세기 커널

정말 많은 우여곡절을 겪은 워디안 때부터 지금까지 큰 변화 없이 이어지고 있는 에디팅 엔진 겸 파일 포맷입니다. 아마 아래아한글은 앞으로 이 방식에서 더 바뀔 일이 없을 것 같습니다.
문자 인코딩이 시대의 조류를 따라 드디어 유니코드로 바뀌고 글씨라든가 용지의 크기 제한이 완전히 사라졌습니다. 색깔도 RGB 어느 색으로나 줄 수 있게 되었으며, 여러 쪽에 걸치는 표처럼 MS 워드의 앞선 기능을 대폭 수용하여 2.0 시절 커널과는 비교가 되지 않는 많은 기능들이 추가됐습니다.

더구나 워디안 이후로 아래아한글은 과거에 없던 여러 기능이 추가되고 있음에도 불구하고 예전과는 달리 파일 포맷의 하위 호환성은 비교적 잘 유지되고 있는 것 역시, 처음에 파일 포맷 설계를 확장성 있게 잘 한 덕택이라고 볼 수 있습니다.
아래아한글도 이제 open xml 기반 문서 파일 포맷도 적극 도입해야 하지 않나 싶습니다만 과연 실현될지?

- MS 워드의 경우 97~2003 커널이 가장 보편적으로 널리 쓰이다가 2007에 와서는 에디팅 엔진과 파일 포맷이 또 크게 바뀌었지요. 95 그 이전 기수는 잘 모르겠네요.
개인적으로 워드보다도 엑셀에서, 편집 가능한 셀 수가 크게 증가하고 색깔 제한이 없어진 것을 매우 환영합니다.

Posted by 사무엘

한메 타자 교사(HTT).
정말 전설적인 타자 연습 프로그램이며, 이후에 등장한 동일 분야 프로그램들의 근간을 제공했습니다.

아래아한글 1.x와 비슷한 연배의 프로그램이죠. 90년대 초반에 개발된 도스용 응용 프로그램들이 90% 이상 볼랜드 터보 C 2.0 기반이었고 그래픽 모드 동작을 위해 BGI 라이브러리를 사용한 것과는 대조적으로 HTT는 MS C 6.0 기반입니다. (비주얼 C++ 6.0이 아님!)

  당시에 통용되던 프로그램들을 좀더 살펴보면,
페르시아의 왕자도 1, 2 모두 MS C로 개발되었고 볼랜드 계열 빌드가 아닙니다.
아래아한글은 16비트 바이너리들은 전통적으로 볼랜드 컴파일러를 써 왔지만, BGI 라이브러리 기반은 물론 아니지요.

HTT는 제가 두벌식을 쓰던 시절과 맥을 함께 했습니다. 세벌식 연습은 도스용 한컴 타자 연습으로 주로 했고 HTT를 쓰지 않았거든요. 390에서 최종으로 갈아타던 시절에는 박 정만 님이 개발한 <광타>의 도움을 받기도 했습니다. 그때가 얼마나 불모지였냐 하면 390 말고 최종 연습을 정식으로 지원하는 프로그램이 “없었습니다.” 윈도우 운영체제는 말할 것도 없고 아래아한글 97이 제공하던 최종 자판에도 오류가 있었습니다. 지금이야 워디안 때부터 최종 자판이 제대로 지원되기 시작했고, 윈도우용 한컴 타자 연습에도 최종 배열이 추가되긴 했지만, <날개셋> 타자연습이 첫 등장하던 시절엔 정말 제 프로그램의 지위가 더욱 독보적이었었습니다.

한메 타자는 일부러 이렇게 만들기라도 했는지 문장 연습하는 감이 묘하게 좀 좋지 않았습니다. 키를 계속 누르고 있으면 글자가 생기는 느낌이 더디고 좀 latency가 느껴집니다. 아마 이것 때문에 그 당시 세벌식 연습을 한메 대신 한컴으로 사용하지 않았던가 생각됩니다.

두벌식으로는 단문도 700 이상은 정말 무리였지만 지금 세벌식으로 연습해 보니 800 넘는 것도 가뿐하군요. “드는 정은 몰라도 나는 정은 안다.”라는 문장은 완전 세벌식 최적화 문장이어서 1000을 넘기기도 했습니다.

그리고 베네치아 게임을 오랜만에 해 보니,
<날개셋> 타자 게임의 혹독하기 그지없는-_- 지옥 훈련에 단련돼 있는 저한테는 정말 애들 장난도 아니었습니다. 떨어지는 속도도 느리고 단어도 훨씬 더 짧고 쉬운 것들이고..!
1단계부터 시작해 보니 2만점대의 점수로 끝탄을 깼습니다. 껑충 바이러스가 두 번이나 걸렸습니다.

8단계부터 시작하니 클리어 시 보너스가 더욱 붙어 47000점대의 점수를 획득했습니다. 물론 단 한 번도 HP를 소모한 적이 없었으므로 재건 바이러스는 아무 의미가 없었죠.

<날개셋> 타자연습의 게임은 베네치아를 전혀 어려움 없이 가뿐하게 엔딩 보는 개발자 본인도 만신창이로 간신히 다 클리어할 정도로 월등히 더 어렵게 짜여 있습니다. 옛날 버전은 지금보다도 더 어려웠어요. -_-;; 난이도와 각종 주인공 밸런스들은 거의 05~06년 이후로는 더 수정 없이 완전히 정착한 듯합니다. 지금 이 상태가 딱 적당하며, 더 어렵게도, 더 쉽게도 만들 필요 없을 것 같습니다. 지금은 타자를 치는 인구가 훨씬 더 늘었으니 국민 평균 실력도 영어 실력만큼이나 더욱 상향 평준화해 있을 거라는 점, 모아치기 같은 세벌식 고급 입력 기능을 십분 활용할 수 있다는 점을 감안하면 말이죠.

옛날에 두벌식 쓰던 시절엔 베네치아도 6~8단계 정도만 되면 글자 떨어지는 게 무서워서 차마 못 할 정도였는데 정말 격세지감입니다. 그나저나 “에이즈 바이러스 퇴치!”와 “지뢰 바이러스”는 도대체 뭘 하는 놈이고 왜 넣었는지 모르겠습니다. 전자는 아무 효과 없는 꽝인 것 같고, 후자는 글자들이 지뢰에 부딪히면 점수가 깎이는 것 정도밖에 모르겠네요.

<날개셋> 타자연습 1.x를 개발하던 초창기 시절엔 한메, 한컴, 광타는 물론이고 신의 손, 번개손, 천타를 꿈꾸며 같은 당대의 경쟁(?) 프로그램들을 많이 참고했습니다. 개인적으로는 도스용 <신의 손>이 정말 완성도가 높다고 인정하며, 그 열악한 640*480 16컬러에서 어지간한 게임을 방불케 하는 비주얼 디자인을 연출해 낸 것에 최고의 점수를 주고 싶습니다. 게임도 나름 테마를 갖춰서 무척 잘 만들었죠.

아무튼, 한메 타자 연습을 보니 이런 저런 여러 생각이 들었답니다. 그리고 세벌식 만세입니다. =_=;;;

Posted by 사무엘

아무리 MS 워드가 다른 기술이 월등하고 훨씬 더 프로페셔널하고 무엇보다도 파일 포맷이 국제적으로 널리 통용되고 다 좋다고 하나, 아래아한글의 비장의 무기들.

글자 모양/문단 모양을 구분할 수 있는 속성 복사 Alt+C

그리고 Alt+B 키매크로. MS 제품에도 심지어 비주얼 스튜디오에는 키매크로가 있습니다. Visual Basic 기반의 더 복잡하고 전문적인 매크로 이전에 이런 게 없나 궁금합니다. 키매크로는 차라리 과거의 도스용 아래아한글만한 시절이 없었죠.
사실 매크로, 핫키 정도는 과거 윈도우 3.1의 “레코더”처럼 운영체제 차원에서 유틸이 하나쯤 있어야 합니다. 너무 초보자 위주의 마우스 GUI에만 치중하다 보니 GUI 운영체제들은 컴퓨터를 정말로 효율적으로 활용하게 해 주는 자동화, 프로그래밍, 일괄 처리 기능이 너무 미약하죠.

하나 더, 특정 스타일을 바로 지정하는 Ctrl+숫자 단축키. 이거 정말 워드에는 없나 궁금합니다.
사실 이따금씩은 도스 시절의 잔재인 “글꼴 단축키”가 아쉽기도 합니다. 블록 잡고 Alt+L, K, T, C, D 끗. (한글 폰트를 ‘견명조’로 바꾸기 ^^)

단축키가 더욱 빛을 발하는 또다른 분야는 표입니다. 저는 비슷한 난이도의 표 문서를 아래아한글과 워드로 모두 작성해 봤습니다. 셀 블록 잡기, 병합, 분할, 서식 지정 등등.
지켜보는 사람도 말하더군요. “님은 아래아한글 쓸 때는 대부분 양손이 키보드에 가 있고 단축키로 하는데, 워드는 꼭 스타 하는 것처럼 마우스 움직임이 복잡하고 많네. ㄳ”

워드 2007에서 표 작업 정도 하려면 ‘아래에다 셀 삽입, 셀 제거’ 같은 자주 쓰는 기능을 간추려서 Quick Access Toolbar에다가 옮겨놓기부터 먼저 해야 합니다. Home, Table 이런 리본들 왔다갔다하다 보면 정신 없습니다.

물론 워드가 훨씬 더 합리적으로 기능 잘 제공하는 것도 많습니다. 가령, 여러 아이템을 클립보드에다 복사해서 골라가며 붙이는 게 실무에서 이렇게 유용한 줄은 몰랐습니다. 오피스 2000부터 추가된 기능이죠.

아래아한글은 기본적으로 2.0 시절부터 표를 그림이나 문자 같은 동일한 개체라는 개념으로 봐 왔습니다. 그래서 여러 페이지에 걸치는 표는 2002에서 에디팅 엔진을 새로 디자인할 때에야 드디어 가능해졌습니다. 하지만 워드는 애초부터 표는 레이아웃의 일종으로 구현되었으며, 아래아한글처럼 표 전체를 한 글자처럼 취급하는 기능이 없습니다. 이건 HTML의 구조와도 비슷하죠.

아래아한글이 2.0 이래로 별다른 변화 없이 제공해 온 개체 배치 방식은 저는 완전히 이해하여 프로그램과 제가 일심동체가 되어 있는 반면, MS 워드가 개체를 배치하는 방식은 저는 나름 97 이래로 워드를 쓰고도 아직도 알쏭달쏭입니다. 내가 이렇게 바꾸면 프로그램이 이렇게 딱 동작할 거라는 확신이 없습니다. ㅜㅜ

서식 지정하는 방식, 특히 불릿/개요 같은 문단 속성도 마찬가지. 아래아한글은 딱 프로그래머스럽게 동작하는 반면 워드는 정말 제멋대로.. 그 미묘한 감각 차이는 아래아한글처럼 독학 자습만으로는 도저히 습득을 못 하겠습니다.

워드와 아래아한글은 서로 정말 극과 극에 가까운 다른 철학으로 디자인된 프로그램이라는 건 두 프로그램을 모두 중급 이상 활용하는 분이라면 누구나 공감할 것입니다. 저는 이미 초등학교 고학년 때 그림, 표, 메일 머지, 목차, 각주, 스타일, 개요 등등 아래아한글 2.X 전기능을 마스터한 반면 워드는 성인이 된 지금도 아직까지 그 동작 알고리즘이 뿌옇게 흐리게만 보입니다. 한 프로그램의 철학에 익숙한 사람이 다른 프로그램에도 능숙해지기는 어려운 장벽이 있습니다. 그래서 두 프로그램 중 하나가 쉽게 없어지지는 않을 것입니다.

워드에는 아래아한글처럼 매 언어별로 글꼴의 상대 크기와 장평, 자간을 세밀하게 맞추는 기능이 아쉽고, 아래아한글에는 워드처럼 사각형이 아닌 개체의 실제 모양대로 글자가 흐르는 어려운 기능, 아주 정교한 서식들(덧말, 첫 글자 자동 키우기 등, 아래아한글에도 없지는 않으나 글자 배치가 워드에 비해 완성도가 떨어짐) 같은 게 아쉽습니다.

아래아한글이 2004에서야 surrogate를 지원하기 시작하고 2005부터 아랍/히브리 문자를 제대로 지원하기 시작한 건 굉장히 늦은 감이 있지만 바람직한 향상이라 생각됩니다. 그나저나 2005는 2007에서 잘 쓰던 과거 신명 시스템 글꼴들을 왜 인식을 못 하나 모르겠습니다. 태 시스템 것만 인식되네요. (태 가는 헤드라인) ㅜㅜ

Posted by 사무엘

지금은 오나전 아련한 추억이 됐죠. ㄱ-

1. 포트 충돌이 일어나면 모뎀과 마우스를 동시에 못 쓰던 것. ㄲㄲㄲㄲㄲㄲㄲㄲ
(시스템 종료 후 컴이 자동으로 꺼지기 시작,
마우스 휠과 USB 포트, 키보드와 마우스 단자가 PS 포트로 변경...
한 97~99년을 전후해서 다 그렇게 바뀐 것 같더군요.)

2. 도스를 완전히 못 벗어난 윈도우 9x 특유의 블루 데드 스크린과
64KB 리소스 제약..
이건 지구상의 어떤 운영체제에도 없던 이상한 제약이 아니었나 싶습니다.
16비트에서는 도스, 아니면 풀 32비트에서 유닉스, OS/2급의 빵빵한 운영체제 이런 구도였지, 둘을 저렇게 짬뽕한 OS는 윈도우 9x 부류가 유일했으니까요. MS가 고객 수요에 맞춰 장사를 정말 잘 한 것입니다.

3. 물론 이건 운영체제라기보단 드라이버 탓이 더 크겠지만
윈도우 98 시절까지만 해도 멀티웨이브 안 되던 컴도 많았어요. -_-;;
사운드 카드가 동시에 한 프로그램밖에 쓸 수 없는 자원이었던 캐암울한 시절도 있었습니다. ㄱ-

윈도우 2000/ME로 넘어오면서부터

- 소프트웨어 시뮬만으로 미디 신시사이저 지원
- 멀티웨이브 본격 지원
- 메모리 스틱, 외장하드 등 어지간한 USB 기억장치를 자동 인식. "이 장치를 안전하게 제거" 메뉴 자체가 생김 (98 SE는 아직 그런 거 없음.)

꽤 많은 변화가 생겼던 것 같습니다. 과거의 제약이 차츰 사라졌죠.
윈도우 ME는 비록 악명은 높지만 최신 하드웨어 인식 잘 하는 건 98보다 뛰어나다는 걸 확실히 인정함.

그리고 마우스 포인터.
제 기억이 맞다면, 아마 윈도우 2000은 VGA 640*480 16 컬러에서 돌아갈 때도 마우스 포인터가 그래픽이 바뀌는 곳에서 깜빡거리지 않을 거에요. 그거 보고 무척 놀랐던 기억이 납니다.
XP부터는 이제 안전 모드에서도 VGA 16컬러는 볼 일이 없어졌고... ㄱ-

하드웨어 지원을 받아서 마우스 포인터가 깜빡거리는 게 없어진 것이 한 90년대 중반부터인데, 이때도 지원이 완전하지는 못해서 흑백 monochrome 기본 커서가 아닌 커스텀 포인터는 여전히 깜빡거리기도 했었습니다.

CD롬 부팅 후 곧바로 운영체제 설치가 가능해진 것도 2000부터이죠?
NT에 그런 기능 있었을 리는 없고,
9x 계열에도 그런 거 없습니다. 그래서 vmware에서 세팅할 때도 먼저 도스 + fdisk 파티션부터 만들어야 합니다.

Posted by 사무엘

MDIR은 도스 시절에, 특히 컴퓨터 깨나 하는 사람들의 거의 필수품인 쉘 겸 통합 유틸리티 프로그램이었습니다.

작고 가벼운 크기에 굉장히 편리한 인터페이스. 단축키에 중독되고 나면 이거 없이는 불편해서 못 살았죠. 기본적으로 텍스트 영문 모드였지만 한글 바이오스도 인식하고 나중 버전은 윈도우 95 아래에서 긴 파일 이름도 그럭저럭 잘 인식했습니다.

도스 시절엔 더 말할 필요도 없었고
한 확장자를 상대로 단일 연결 프로그램밖에 바로 실행 못 하는 윈도우 쉘과는 달리,
압축 파일 내용 바로 보는 기능, 드라이브를 바로 바꾸는 단축키(Shift+C, D), 특정 프로그램을 바로 실행하는 펑션 키 연결, 노턴 유틸리티 NCD를 필요 없게 만든 F10 MCD, 그리고 특정 단축키로 바로 디렉토리를 바꾸는 QCD, 그리고 두 창 열어서 보는 기능.

간단합니다.
원하는 디렉토리로 빨리 가고,
선택된 파일에 대해서 다양한 조작을 하는 다양한 프로그램을 키 조작만으로 바로 실행하는 것.

저도 처음부터 M 사용자는 아니었는데 94~95년경에 M 거의 광신자인 한 친구의 영향을 받아 쓰게 됐습니다. 아주 편리하더군요.
등록판으로 바꿔 주는 크랙도 한동안 쓰고 지냈지만, 98년에 그렇잖아도 도스용으로는 마지막 버전이 된 3.10이 나왔을 때 나름대로 돈 주고 정품을 구입했습니다.

등록판은 About 화면의 강제 딜레이가 없으며 서로 다른 드라이브로 디렉토리 통째 복사가 가능하고, 보라/mcopy 같은 보조 유틸들을 제대로 사용할 수 있었습니다.

알 만한 사람은 다 알지만 MDIR은 컴을 잘 못 다루는 개발자의 여자친구를 위해 개발되었던 걸로 유명합니다. 실제로 그 두 사람은 결혼했다고 전해집니다.

하지만 MDIR은 여자친구의 전유물로 그치지 않고 꾸준히 개발된 끝에, 01년 말에는 드디어 윈도우용도 나왔고, 개인 명의가 아닌 회사 제품으로 개발되기 시작했습니다.
솔직히 MDIR 정도면 EditPlus처럼 세계적으로 셰어웨어로 내놓고 팔아먹어도 손색이 없다고 느껴집니다. 미국 같은 데서는 솔직히 제가 지금까지 개발한 프로그램보다도(날개셋, WordTech 등) 규모가 작은 프로그램도 당당히 개인 개발자로서 이름 걸고 홈페이지 운영하면서 셰어웨어로 팔아먹는 경우가 많습니다.

이 정도 프로그램을 만들려면 운영체제 쉘 구조부터 시작해서 상당 수준의 하드웨어 지식, 인내심과 노가다 코딩까지 통달해야 했을텐데 놀랍기 그지없었죠.

하지만 2003년경, MDIR이 소속되어 있던 회사는 경영수지 악화로 인해 없어졌고, 개발자 역시 그 회사를 나와서 이제는 완전히 "은퇴"하고 말았습니다. MDIR의 소스는 갖고 있으되 공개할 의향은 없고, 그렇다고 해서 얘를 유지보수할 여건은 안 되고.. 한 마디로 그렇게 개발이 중단되고 묻혀 버린 것입니다.
개발자는 MDIR 개발만 중단한 게 아니라 IT계에서 완전히 은퇴했고, 이제 완전히 다른 사업을 하면서 산다고 합니다. (안습)

MDIR은 상당히 이색적으로 C/C++이 아닌 파스칼(볼랜드)로 개발된 것으로 잘 알려져 있습니다. 윈도우용은 자연히 델파이로 개발됐죠. 도스용은 EXE 파일이 아주 빡세게 암호화-압축돼 있기 때문에 일반적인 분석 방법으로는 빌드 개발툴을 알 수 없는데, 저는 처음에 이 정보를 어디서 얻었는지 모르겠습니다.

16비트 EXE이기 때문에 메모리 제약이 좀 있었고, 특히 MCD에서 1000개가 넘는 디렉토리를 표시할 수 없고, 한 디렉토리에서 2000개가 넘는 파일을 표시할 수 없는 게 아쉬운 점이었습니다. 후자는 단순히 파일이 다 안 보이는 걸로 끝이지만 전자는 디렉토리 스캔하다가 프로그램이 뻑났거든요. 도스용도 32비트 컴파일러로 재개발됐으면 참 좋았을텐데, 쉘 유틸리티의 특성상 하드웨어에 종속적인 명령이 많아서 개발툴을 바꾸기가 쉽지 않았을 것 같습니다.

윈도우용은 32비트이다 보니 메모리 제한은 없지만, 이제 유니코드를 지원하지 않는다는 아쉬움이 남습니다. 5.0에서 추가될 기능 중 하나이기도 했는데, 5.0은 끝내 나오지 않은 채 MDIR의 개발은 중단됐습니다.
이 때문에 MDIR 정식 등록자들이 무척 좌절하고 허탈해했습니다. 하지만 반대로 생각해 보면 MDIR의 개발자도 극심한 불법복제의 피해자이기도 했습니다.

등록판을 불법복제 하려면 최소한의 부끄러운 줄은 알고 혼자 조용히나 쓸 것이지 대놓고 개발자한테 시리얼 번호 알려 달라고 메일 보내는 골빈녀석도 부지기수였다고 하더군요.

MDIR 역시 뭐 복사방지 락이라도 달고 나온 건 아니고, 전적으로 소프트웨어적인 방법만으로 등록판 판별을 해야 했기 때문에, 등록판 판별 방식을 여러 번 변경하고, EXE의 리버스 엔지니어링을 막기 위해 복잡한 방법으로 실행 파일 암호화/압축을 거쳤던 것입니다.
  (개인적으로 도스용 게임 Titus Fox이 컴퓨터별로 레벨 코드 생성을 어떤 원리로 하는지가 무척 궁금하기도 합니다.)

윈도우 비스타에서도 WinM이 돌아가긴 합니다. 하지만 32비트 어플의 특성상, 64비트 윈도우 시스템 디렉토리 같은 곳엔 접근이 되지 않습니다. 32비트 윈도우 시스템 디렉토리로 그냥 리다이렉션 돼 버리죠. (속임수)

어쨌거나 컴퓨터 세계는 이제 진짜로 기술이나 아이디어만으로는 자본력을 도저히 못 당해 내게 흘러가는 것 같습니다. 그리고 이 컴퓨터의 힘을 입어 컴퓨터뿐만 아니라 다른 업종도 다 저렇게 바뀌고 있습니다.

Posted by 사무엘

※ 1.x 시절

윤곽선 폰트라는 개념이 없던 시절엔 도트용과 레이저용이라는 기묘한 구분이 있었습니다.
레이저용이라고 해 봤자 겨우 300dpi짜리 프린터였는데, 그때는 그 고해상도 비트맵 글꼴만 해도 제작 비용이라든가 컴퓨터 상의 처리 부담이 만만찮았습니다.
레이저 프린터용 자형의 존재 여부가 한 프로그램의 에디션을 구분하고 복사 방지장치 장착 여부를 결정한 것이나 다름없습니다.

※ 2.0, 2.1

일반용과 전문용으로 구분했습니다. 가격 차이는 거의 2.5배 정도.
글씨를 자유롭게 확대할 수 있게 되었기 때문에, 일단 레이저 프린터용 비트맵 자형도 일반용에 기본 내장은 되는 '거저 먹는' 양상이 되었습니다.
아래아한글 2.0은 우리나라 소프트웨어 역사에 그야말로 획기적인 한 획을 그었습니다.
하지만 컬러 인쇄와 윤곽선 글꼴, 맞춤법 검사기 같은 기능은 전문용에만 있었지요. 윤곽선 글꼴이 없었으니 일반용은 글씨 크기 조절이 사실 별 의미가 없었습니다.
전문용은 락이 걸렸습니다. 그리고 2.1 전문용은 386 전용 코드로 개발되었습니다.

※ 2.5

드디어 2.5에서 일반용과 전문용이란 구분도 없어지고, 대신 86, 386 코드 에디션 구분이 생겼습니다. 86 에디션은 제 기억으로 덧실행, 맞춤법 같은 기능이 없는 거 빼고 문서를 만드는 기능상으로는 거의 차이가 없습니다. 286 AT 기종에서도 드디어 컬러 인쇄와 윤곽선 글꼴을 구현해 냈습니다. 눈물나게 감동스럽습니다.
다만, 2.5부터는 영한사전, 추가 확장 글꼴 같은 '확장팩'이란 개념이 생겼고, 확장팩에만 락이 걸렸습니다. 락이 없으면 영한사전 메뉴는 비활성화됐고, 신명시스템 글꼴은 아무 말 없이 그냥 동작하지 않고 명조로 대체되어 나왔죠. "한글과컴퓨터 2"라는 폰트 드라이버 자체가 락이 걸렸던 것 같습니다.

※ 몇 가지 중요한 사실

- 아마 2350자에 없는 비완성형 한글에 대해 최초로 동작한 윤곽선 글꼴은 2.1에서 추가된 휴먼 안상수체 계열의 조합형 글꼴입니다.
- 신명조가 비완성형 한글과 옛한글까지 윤곽선화한 건 2.5나 3.0때부터입니다. 제 2수준 한자가 윤곽선화한 것과 시기가 비슷합니다.
- 1.X 시절부터 있던 샘물과 필기체는 정확하게 2.5에서 윤곽선화했습니다.

- 윈도우용 아래아한글 3.x에서부터 2.5 확장팩 글꼴이 락이 풀린 형태로 제공되기 시작했습니다. 윈도우용 버전은 기존 도스용 2.5의 락이 걸린 확장팩 글꼴도 바로 읽어들였을 뿐만 아니라, 3.0용 확장팩 자체도 락이 풀려서 도스용 2.5에다가 복사하면 바로 읽을 수 있는 형태로 글꼴이 들어있었다는 뜻입니다. 사용하는 폰트 드라이버가 "한글과컴퓨터 2" 대신 일반 "한글과컴퓨터"로 바뀌었습니다.

Posted by 사무엘