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

1.
예전에도 한번 이런 비유를 꺼낸 적이 있었는데.. 라면을 소프트웨어 플랫폼에다 비유하자면 봉지 라면은 PC, 사발면은 태블릿, 컵라면은 스마트폰 정도에 대응하는 것 같다. 그래서 한 플랫폼에서 잘나가던 라면이 다른 플랫폼으로 종종 포팅되곤 한다(카카오톡 PC 버전, 오피스 안드로이드 버전처럼). 비록 둘이 맛이 완전히 동일하지는 않지만 말이다.

식당에서 주문해서 먹는 라면은 집 밖의 거대한 다른 가게에 들어가서(서버 접속) 먹는 것이니 서버 사이드 웹 애플리케이션일 것이며..
분식점 같은 식당 납품을 목적으로 라면 제조사가 면이나 스프만을 대량으로 따로 파는 건 '엔진' 같은 미들웨어 컴포넌트 내지 라이브러리에 대응한다고 볼 수 있겠다.

2.
스마트폰은 컴퓨터와 달리.. (1) 특별한 일이 없는 한 24시간 켜져 있고, (2) 열받고 뜨거워질지언정 그래도 팬 돌아가는 소리가 안 나고, (3) 보조 기억장치가 있지만 하드디스크 돌아가는 것 같은 소리는 전혀 없다.
그래서 (2)와 (3)을 종합하면 스마트폰은 아주 조용하다. 게다가 얇기까지 하다.
어찌 보면 세상에 어떻게 이런 컴퓨터가 존재 가능해졌는지 신기한 노릇이 아닐 수 없다. 그것도 화면은 옛날 구닥다리 액정 같은 단색이 아니라, 고해상도 천연색 그래픽을 찍어 낸다. CPU뿐만 아니라 디스플레이나 메모리까지 총체적으로 왕창 발전했기 때문에 스마트폰이 만들어질 수 있었다.

옛날에는 뭔가 영상이 표시되는 기계 자체가 굉장히 미래 하이테크의 상징이었다. 집 현관을 표시해 주는 인터폰이나 자동차 내비 같은 거 말이다.
텔레비전이나 컴퓨터 모니터는 아날로그 신호에 둥그런 브라운관 형태로나마 진작부터 천연색을 표현할 수 있었다. 하지만 들고 다닐 수 있는 소형 텔레비전이나 인터폰, CCTV 같은 건 원가 때문인지 무엇 때문인지, 의외로 흑백 버전이 2000년대까지 쓰였다. 본인은 몇 차례 이사를 다니며 집을 옮긴 적이 있지만, 컬러 화면이 나오는 인터폰 실물을 태어나서 지금까지 한 번도 구경을 못 해 봤다.

그런데 어느 샌가 갑자기 CCTV의 화질이 급격히 향상되고 차량들이 개나 소나 내비에 블랙박스까지 달고 다니면서 블랙박스에 찍힌 사고 영상만 모아서 보여 주는 TV 프로가 큰 인기를 모을 정도가 됐다. 사진과 동영상을 즉각 생성해서 남들 보는 사이버 공간에 용량과 트래픽 걱정 없이 올리는 게 너무 금방, 쉽게 가능해졌다. 이건 1980년대의 SF물들이 제대로 상상하지 못한 너무 엄청난 변화임이 틀림없다.

그리고 컴퓨터 자체도.. 이젠 스마트폰 내부에서 가상 머신을 돌려서 도스는 말할 것도 없고 과거의 Windows 9x를 구동할 수도 있게 됐다. 머리만 비교하면 스마트폰의 CPU가 일반 데스크톱 PC의 CPU와도 성능이 호각이 됐으며, 단지 PC에 비해 부족한 건 입력 장치와 하드디스크 정도밖에 없다고 한다. 발열이나 전원의 한계는 차치하고라도 말이다.

모바일 플랫폼이 등장하면서 PC에서 x86 계열 CPU + Windows 계열 운영체제를 총칭하는 '윈텔' 독점 구도도 상당 부분 흔들리게 됐다. 완전히 새로운 형태의 시장 수요를 창출해 냈으니까. x86은 30년을 넘게 거슬러 올라가는 유구한 하위 호환성을 자랑하지만, 그 때문에 저전력 모바일에서 빠릿빠릿 움직이는 용도로는 상당히 부적합한 CPU가 돼 버려서 말이다. Windows도 마찬가지다.

다만, 단순히 이미 만들어진 정보들을 받아 보기만 하는 인터넷 단말기 이상으로, 뭔가 글쓰기나 코딩 같은 생산적인 활동을 하기에는 스마트폰은 문자 입력이 너무 불편한 게 흠이다. 구닥다리 타자기의 인터페이스를 답습하고 있지만 그래도 문자 입력 분야에서 키보드만 한 가성비를 제공하는 물건은 아직까지 없다.

예전에 그나마 전화기 버튼이라도 있던 시절에는 3*4 배열이라는 틀은 고정돼 있었는데..
요즘 스마트폰은 화면의 절대적인 크기나 종횡비까지 전부 그냥 흰 도화지 수준인 거 같다. 인간에게 가장 적합한 글쇠 scheme은 어떤 형태일까? 블루 오션이다 보니 먼저 연구해서 표준 틀을 정착시키는 사람이 그냥 장땡이 돼서 혼자 다 해먹을 수 있을 것 같은 생각이 드는데.. 난 잘 모르겠다. 난 한글 입력 쪽은 글쇠배열이 아니라 일단은 근본 메커니즘 연구가 주 관심 분야인지라..

글쇠 수가 너무 많으면 안 그래도 작은 화면에 너무 작은 글쇠 버튼을 잘못 찍어서 오타를 내기 쉽고, 반대로 글쇠 수가 너무 적으면 타수가 늘어나고 이것저것 모드를 바꾸는 빈도가 잦아져서 그것대로 또 입력이 불편해진다.
구글 단모음을 한동안 써 보다가 불편해서 다시 나랏글로 돌아왔다. ㅎ, ㅔ 같은 자모를 한 번에 바로 입력할 수 있어서 편한 것보다, 오타가 나서 불편한 게 더 크게 느껴졌다. 개인적으로는 나랏글을 거의 2004년부터 10년 넘게 쓰기도 했고 말이다.

3.
스마트폰이 폭발적인 인기를 끌면서 오늘날과 같은 사진· 동영상 업로드 문화를 만들어 낸 건 두 말할 나위 없이 '디지털 카메라' 기능까지 전화기 안에 쏙 들어간 덕분에 가능했다.
오늘날 폰의 카메라가 단순 화소수와 색감만 따지자면 어지간한 보급형 디카의 성능을 다 따라잡고도 남는다. 하지만 폰 카메라가 전용 디지털 카메라를 결코 따라잡지 못하는 게 크게 둘 있는데, (1) 줌과 (2) 부팅 속도이다.

근본적으로 카메라의 형태로 적합하게 설계되지 않은 그 얇은 몸체에다 두꺼운 다기능 렌즈까지 우겨넣는 건 아무래도 무리다. 그렇기 때문에 폰 카메라는 줌 기능이 전문적인 카메라의 적수가 될 수 없다. 시야각도 한계를 받기 때문에 이걸 극복하려면 별도의 파노라마 합성 앱 같은 것의 도움을 받아야 한다.

또한 디지털 카메라는 사진을 찍을 때에만 잠시 켰다가 끄는 걸 스마트폰보다 훨씬 더 간편하게 할 수 있기 때문에 밖에서 사진을 몇백 장씩 산발적으로 찍을 일이 있을 때 전력 소모 부담이 훨씬 덜하다. 부팅도 아예 범용 컴퓨터인 스마트폰보다야 비교할 수 없이 더 빨리 되며, 전원을 켜자마자 거의 곧장 촬영 ready 상태가 된다. 그 반면 스마트폰은 이런 특성을 전혀 갖고 있지 못하다.

하긴, 피처폰이 스마트폰으로 바뀌고 스마트폰에 온갖 복잡 다양한 기능들이 추가될수록 사용자가 알게 모르게 치르는 대가로는 배터리 시간이라든가 폰의 물리적 내구성 같은 게 있다. 이와 비슷한 맥락에서 스마트폰도 켠 직후에 수 초 이내로 바로 쓸 수 있는 게 아니라, PC에 준하는 급의 부팅이 필요하고 엄청난 양의 초기화와 캐싱, pre-fetching을 해 줘야 쓸 수 있는 물건이 되고 있다. 예전에 PDA나 공학용 계산기가 그렇게 부팅 시간이 긴 물건은 아니었으니 말이다. 부팅이 존재하고 악성 코드 걱정을 해야 하는 기기는 다른 전자 기기와는 성격이 근본적으로 다르며 훨씬 더 능동적인 물건이다.

한때는 이런 작은 화면에 찍히는 글자는 초간단 비트맵 글꼴 기반인 게 당연시되었는데 그게 힌팅까지 적용된 미려한 윤곽선 글꼴로 바뀌었다는 것 하나만으로도 소프트웨어적으로는 예전에 비해 그야말로 엄청난 부담이 추가된 거나 다름없다. 윤곽선 글꼴은 캐싱 없이는 도저히 쓸 물건이 못 되며, 캐싱이라는 건 굉장한 양의 메모리를 요구하기 때문이다.

오늘날 컴퓨터 프로그램들이 같은 일을 해도 예전보다 메모리와 CPU를 훨씬 더 많이 요구하는 이유는 유지 관리 차원에서의 범용성과 추상성을 높인 대신에 오버헤드가 더 커지고 성능 희생을 감수한 게 매우 크게 작용한다(가상 머신, 가상 함수, 등등등등). 스마트폰의 전력 소비나 부팅 속도도 그런 맥락에서 살펴볼 수 있을 듯하다.

Posted by 사무엘

1. 들어가는 말

오늘날의 거대하고 복잡한 운영체제와는 달리, 도스는 이니셜 D-_-가 암시하듯이 달랑 플로피디스크 한 장만으로 부팅이 가능할 정도로 참을 수 없이 작고 가벼웠다. 정말 필수불가결인 파일은 부팅에 쓰이는 io.sys, 그 뒤 셸 역할을 하는 텍스트 명령 해석기인 command.com이 전부다.
msdos.sys라는 파일도 있는데 얘는 정확하게 무슨 존재인지 모르겠다.

그리고 사실은 config.sys의 DEVICE 명령을 통해 실행되는 sys 파일과, com 실행 파일이 서로 무슨 차이가 있는지도 모르겠다. 마우스, 그래픽 카드 에뮬(simcga, msherc ^^), 사운드(sound, unsound) 같은 여러 램 상주 드라이버들은 com이었지만, 씨디롬 드라이브는 sys였으며 그것도 주 메모리를 꽤 많이 차지하는 드라이버였다. 단, 부팅 후에 sys 파일을 별도로 실행해 주는 유틸리티가 있기도 했다.

디스크로부터 파일을 읽으려면 파일 시스템이 정립돼 있어야 하며, 이건 운영체제가 하는 일 중 하나이다. 그런데 그 운영체제를 로딩하는 프로그램도 파일 형태로 저장돼 있다. 이런 '닭이 먼저냐 계란이 먼저냐' 딜레마를 해소하기 위해서는, 부팅에 쓰이는 운영체제 프로그램은 디스크에 단순히 파일 형태로만 존재하는 게 아니라, 컴퓨터 바이오스가 물리적이고 원초적으로 인식 가능한 첫 지점에 저장돼 있어야 한다. 이건 굳이 도스뿐만 아니라 어느 운영체제라도 마찬가지이다.

도스는 단일 사용자 단일 프로그램 구동 체계이다 보니, 한 프로그램이 그야말로 컴퓨터 하드웨어를 전부 있는 그대로 조종 가능하게 허용하는 백지수표, 열린 허허벌판 같은 환경이었다. 프로그램의 인터페이스도 명령 기반, TUI, GUI 등 제각각이었고 정말 창의적이었다. 요즘 프로그램들만치 UI가 획일화됐다는 느낌이 없이 형형색색 컬러풀했다.

물론 그건 거시적인 관점에서는 그리 효율적이지 못하다. 이런 빵빵한 컴퓨터 자원에서 여러 프로그램을 동시에 실행하고 작업 전환을 할 수 없다면 그것도 컴퓨터에 대한 예의-_-가 아니다.
그러니 운영체제가 더 강력하게 모든 걸 통제하는 지금 같은 환경으로 궁극적으로는 바뀌는 게 맞긴 하지만.. 인제 와서 도스가 다시 새삼스럽게 그리워질 때도 있다.

2. 역사

본인이 경험한 MS-DOS의 가장 옛날 버전은 학교 내지 컴퓨터 학원에서 봤던 3.2/3.3이다. 2.x 이하나 4는 실물로 구경을 못 해 봤다. 다만, 5.0과 6.2는 집 컴퓨터에 내장돼 있던 물건이다 보니 개인적으로 친숙하다.

1981년에 첫 출시되었다고 전해지는 MS-DOS 1.0은 그야말로 정말 골동품 폐물이었다고 한다. 그리고 Windows 1.0이 프로그램 창을 겹치게 배열하는 걸 지원하지 않았다면, DOS 1.0은 디스크에 서브디렉터리를 만드는 걸 지원하지 않았다..;;
그나마 도스가 최소한의 도스다운 틀을 갖춘 건 2를 거쳐서 3.x대에 와서부터이다. 특히 5.25내지 3.5인치 고밀도(1.2, 1.44MB) 플로피디스크를 지원하기 시작한 첫 버전이 이 버전이기 때문이다. 3.x에 와서야 좀 물건다운 물건이 나왔다는 점에서는 도스와 Windows가 역사가 서로 비슷한 것 같다.

그 다음 4.0의 아주 기념비적인 업적은 파일 시스템이 FAT12에서 FAT16으로 확장되어, 이론적으로 지원 가능한 디스크 볼륨의 용량이 2GB로 커진 것이다.
그 시절에 기가바이트는 가히 꿈의 규모였기 때문에 홍보 자료에서는 그냥 '제한이 없어졌다'라는 표현이 관용적으로 쓰였다. 참고로, FAT12 시절의 하드디스크의 용량 한계는.. 고작 32MB였다. =_=;;

또한 MS-DOS shell이라고 나름 드래그 드롭도 지원하고 Windows GUI를 어설프게 베낀 듯한 파일 관리자 셸이 추가된 것도 4부터이다. 하지만 MS-DOS 4는 구체적인 내역은 모르겠지만 불안정하고 버그가 많아서 좀 문제작으로 남았다고 한다.

도스 5.0에서 기념비적인 업적은 그 이름도 유명한 HIMEM.SYS와 DOS=HIGH일 것이다. EMM386은 4.0 때 SYS 버전이 있었지만 5.0부터는 EXE로 형태가 바뀌었다고 한다.
또한 이 버전에서는 과거의 불편하던 EDLIN을 대체하는 QBASIC 기반의 텍스트 에디터가 추가되었으며, 명령 프롬프트에서 cursor 이동을 자유롭게 할 수 있게 하고 히스토리 기능도 넣어 주는 DOSKEY 유틸도 이때 추가됐다.

지워진 파일을 첫 글자 이름을 집어넣어서 복구하는 undelete 역시 아마 6이 아닌 5에서 첫 추가됐지 싶다. 이건 PC-tools나 노턴 유틸리티가 먼저 제공하던 꼼수 기능이었는데 동일 기능을 도스에서 직접 수용한 것이다.

그 뒤 6.0은.. 변한 게 많았다.
가장 유명한 건 하드 디스크를 압축해 주는 '더블 스페이스'라는 유틸리티의 도입이다.
이건 무슨 요술을 부리거나 하드 디스크를 물리적으로 어떻게 하는 게 아니라, 그냥 파일 시스템 차원에서 데이터를 zip 같은 소프트웨어 압축을 적용하는 것일 뿐이다. 당장 용량 확보에는 도움이 되지만 디스크의 액세스 속도가 좀 느려지고 에러에 취약해지며, 하드웨어를 좀 험하게 다루는 일부 프로그램과는 트러블의 여지가 생긴다.

참고로 1993~1994년이면 Windows 3.1이 보급되고 어지간한 PC의 하드디스크는 몇백 MB 정도이던 시절이다.
더블 스페이스는 그렇잖아도 꽤 중요하고 민감한 간판 기능인데, 버그를 많이 잡고 안정화를 더 시켜서 6.2가 나왔다.
그런데 이게 '스태커'라는 타사의 제품을 무단 도용한 것으로 판결이 나서 '더블 스페이스'를 뺀 6.21이 나왔고, 저작권 문제를 해결하여 '드라이브 스페이스'를 대신 도입한 6.22로 6.x대가 마무리 되었다. 지금이야 마소에 대해서 IE 브라우저의 독점 소송이 유명하지만, 1990년대 중반엔 저거 저작권 침해 소송이 IT 업계에서 굉장한 화두였다.

압축 유틸리티 말고도 6.x대엔 멀티 부팅이라는 매우 유용한 기능이 추가됐다. 즉, C/C++의 조건부 컴파일처럼 사용자가 선택한 옵션 방식대로 디바이스 드라이버를 로딩하여 부팅할 수 있게 됐다는 것이다.
그리고 디스크 점검 scandisk, 조각 모음 defrag, 시스템 점검 msd, 주 메모리 확보 유틸리티 memmaker 등이 추가되고 PC-Tools로부터 라이선스 받은 안티바이러스 msav 같은 유틸도 도입됐다. 덕분에 노턴 유틸리티가 예전보다는 좀 덜 필요해졌다.

모든 내부/외부 명령에 /? 옵션을 줬을 때 도움말이 나오는 것도 처음부터 존재한 게 아니었다. 6이거나 아니면 5부터인데 그건 정확하게 기억이 안 난다. 옛날에는 도움말 텍스트를 일일이 내장시켜 줄 정도로 컴퓨터의 메모리나 디스크 용량이 충분하지 못했기 때문이다.

단독 제품으로서 MS-DOS의 역사는 1994년에 출시된 6.22가 끝이었다. 도스는 Windows 95/98/ME와 함께 7.0. 7.1. 8.0 버전으로 명맥을 유지하다가 2000년에 드디어 20여 년의 긴 수명을 마치고 역사 속으로 사라졌다.
도스 외부 명령어 중에서 몇몇 필요한 건 Windows 9x 계열에서는 Windows\command로 갔고, NT 계열은 그냥 system32 디렉터리에 있다. 그리고 NT 계열은 format이나 diskcopy 같은 유틸리티도 콘솔에서 실행될지언정 도스가 아니라 Windows용 프로그램이라는 차이가 있다.

3. 그 당시의 유사품/경쟁자

한편, 도스의 바리에이션으로는..
PC-DOS는 그냥 MS-DOS가 IBM 브랜드만 달고 나온 동일 제품이었다고 한다. 한동안 그러다가 6.x대부터는 서로 다른 길을 가기 시작했는데 이미 그때는 PC 환경이 Windows로 충분히 넘어가기 시작했으니 별 의미는 없다. 따지고 보면 IBM은 OS/2가 망한 데다, 도스 분야도 뒷북으로 끝나고 별 재미를 못 본 셈이다. "IBM 호환 PC"라는 걸출한 대인배 이름만 남긴 채 PC 시장에서는 철수했다.

DR-DOS는 MS-DOS의 전신인 CP/M을 직접 만든 게리 킬달이라는 엔지니어가 '디지털 리서치'라는 회사를 세워서 따로 만든 MS-DOS의 대항마이다. '디알'이지 '닥터 도스'는 아님.. 뭔가 기능이 MS-DOS보다 뛰어났다고 얘기는 들었는데 구체적인 내역은 잊어버려서 기억이 안 난다.
DR-DOS를 '노벨' 사가 인수하여 새로 내놓은 것이 '노벨 도스'이며, 이건 1990년대 초중반까지 나왔다.

한편, 4DOS는 커널을 처음부터 새로 만드는 건 아니고 명령 인터프리터인 COMMAND.COM만 대체하는 기능 확장판으로 컴덕들에게 많이 알려져 있었다. 이걸 시먼텍(Symantec) 사에서 인수하여 자신들이 인수한 다른 유명 솔루션인 '노턴 유틸리티'에다가 집어넣은 것이 NDOS이다. 각종 도스 명령들에서 2% 부족하던 것을 보완하는 편의 기능이 굉장히 많았던 걸로 기억한다. (가령, 중간에 파일이 사라져도 괜찮은 batch-to-memory 배치 파일)

그리고 8.3 짧은 파일 이름의 한계를 보완하기 위해, 내부적으로 descript.ion이라는 숨김 파일을 만들어서 파일명에 대한 '주석'을 표시하는 것도 4DOS의 작품이었다. 옛날에 MDIR도 이걸 지원했다. 파일이 복사· 이동· 개명· 삭제됐을 때 주석도 같이 관리하는 게 좀 번거로운 일이 됐으니까.. NTFS처럼 운영체제의 파일 시스템 차원에서 메타데이터를 관리하는 기능이 없으면 어쩔 수 없이 셸 유틸리티가 뒷감당을 해야 한다.

4. MS-DOS의 한글화

MS-DOS가 최초로 한글판이 나온 것도 2나 3 버전부터이지 싶다. 정말 먼 옛날에는 마소가 잠깐 동안 조합형 코드 기반으로 도스를 한글화화기도 했다는데 지금으로서는 거의 Windows 2.1의 한글판 같은 도시전설이 돼 간다.
허나, 1987년에 지금의 KS X 1001, 그 당시의 KS C 5601 완성형이 제정되자마자 표준을 잘 지키는 마소는 완성형으로 광속으로 갈아탔다. 그게 이미 도스 3 시절의 일이다. 마소는 그냥 표준을 따른 것일 뿐이지만, 결과적으로 조합형 코드를 죽이고 한글을 파괴한 원흉(?)으로 일부 진영으로부터 좀 지탄받곤 했다.

그런데 한글 MS-DOS가 텍스트 모드에서 한글 입출력을 구동해 주는 바이오스 유틸리티를 처음부터 내장하고 있지는 않았던 것 같다. 쉽게 말해 hbios와 그 특유의 바탕체 글꼴을 구경한 건 최소한 도스 5나 6부터이다. 3이나 4 시절에나 그런 게 없었으며, 한글 바이오스는 다른 프로그램으로 구동했었다. 이건 내 기억이 잘못됐을 수도 있음.

hbios는 Windows 95로 가면서 mshbios로 이름이 바뀌었으며, 그 당시의 고유 글꼴은 <날개셋> 편집기에 '마소바탕'이라는 글꼴을 통해 구경할 수 있다. 도깨비나 태백한글 같은 싸제 한글 바이오스들은 조합형/완성형, 두벌식/세벌식, 명조/고딕 등 글꼴과 글자판과 코드를 다 선택 가능했지만, 마소의 보급 바이오스는 당연히 완성형, 두벌식, 명조로 다른 선택의 여지가 없었다.

전에도 한번 얘기한 적이 있었지만, 마소에서 한글화한 프로그램들은 2바이트 문자에 대한 처리가 굉장히 잘 돼 있었다. 2바이트를 구성하는 앞뒤 문자 중 하나가 가려지거나 지워지면 다른쪽 문자도 반드시 같이 사라졌기 때문에 텍스트 모드에서 메뉴나 대화상자가 표시될 때도 문자가 깨지는 걸 보이는 법이 없었다. 이에 대한 처리가 세심하게 돼 있었다.

5. 도스 시절의 멀티태스킹

비록 그래픽은 아니고 텍스트 기반이긴 하지만, Windows 3.x 비스무리한 도스 기반 멀티태스킹 운영환경(운영체제는 아니고..)으로 DESQView 같은 프로그램이 있었다. 난 이름만 들어 보고 실제로 구경은 못 했다. 외국에서는 그럭저럭 쓰는 사람이 있었던 듯하지만 Windows의 등장 이후에는 조용히 역사 속으로 사라졌다.

그리고 사실은 더 발전된 멀티태스킹 운영체제를 마소에서 직접, 그것도 Windows나 OS/2와는 별개로 만들려는 시도를 한 적이 있었다. 무려 1986년, Windows조차 이제 막 개 허접한 1.0이 나왔던 시절에 MS-DOS 3을 기반으로 일명 '멀티태스킹 MS-DOS 4.0'이 계획되었던 것이다. 이것은 앞서 언급한 그 도스 4.0과는 무관한 새로운 개발 브랜치였다.

멀티태스킹 MS-DOS 4는 제품이 나오기는 했고 의도도 나쁘지 않았지만, 1980년대 중반에 시대를 너무 앞서간 문제작이었다. 그 옛날에 그 열악한 하드웨어 환경에서 도대체 뭘 더 바라겠는가? 컨셉에 비해 상품성이 떨어졌다.
게다가 그 당시 마소는 지금처럼 독자적인 불특정 다수용 유명 소프트웨어를 독점 판매하는 공룡 기업이 아니었으며, 여전히 하드웨어 제조사에다 소프트웨어를 납품하면서 먹고 사는 기업이었다. 즉, 지금으로서는 상상이 잘 안 되지만, 업계에서의 위상이 '갑'이 아니라 '을'이었다.
프로젝트를 발주했던 IBM이 이 물건을 더 구입해서 사용하지 않겠다고 선언하자 프로젝트는 흑역사가 되었고, 이 멀티태스킹 MS-DOS 4는 오히려 유럽의 일부 컴퓨터에 OEM 형태로 공급되는 걸로 개발 계보가 끝났다.

멀티태스킹 MS-DOS 4는 비록 GUI 환경은 아니지만 Windows의 전유물로만 알려졌던 NE (new executable) 실행 파일도 지원하고 지금으로서는 무척 신기한 면모가 많았다고 한다. 정작 NE를 사용하던 Windows는 NT가 등장하기 전에는 콘솔 모드라는 게 없었는데, GUI 기반이 아니던 멀티태스킹 도스가 NE를 어떤 형태로 사용했는지 궁금하다.

6. 맺는 말

도스 시절에 메모리 관리를 하는 건 요즘으로 치면 연봉별로 돈 관리하는 요령과 비슷했다. 램이 1MB 이하일 때, 2MB일 때, 4MB일 때, 8MB 이상일 때... HIMEM.SYS와 EMM386을 세팅하는 법, 기본 메모리를 최대한 확보하는 법, 메모리가 왕창 많이 있다면 램 드라이브와 디스크 캐시를 운용하는 요령 등.. 그런 게 1990년대 컴퓨터 잡지들이 고급 정보랍시고 많이 다룬 정보였다.
지금으로서는 그저 격세지감이 느껴질 뿐이다. 그 당시에 기본 메모리라는 개념은 돈에다 비유하자면 당장 손에 있는 현금이고, 나머지 확장 메모리는 통장 잔고나 신용카드 같다는 생각도 든다. =_=;;

MS-DOS의 역사를 살펴보면 많은 걸 느낀다. 금수저 출신의 독종에 천재에 똘끼와 운, 엔지니어 기질과 사업가 기질을 모두 갖고 있는 사람이라면 무슨 여건에다 던져 놔도 결국은 성공했겠다 싶다. 공부만 계속했어도 교수나 변호사가 됐을 사람이 결국은 소프트웨어의 황제로 등극해서 교수· 변호사보다 더한 억만장자가 됐으니까.

물론 빌 역시 그 과정에서 언제나 실력만으로 정정당당하게 승부하지는 않았으며, 경쟁자 치사하게 죽이기 같은 짓을 전혀 안 했다는 건 아니다. MS의 모든 기술과 제품이 100% 빌의 머리에서 비롯된 원천기술인 건 아니며, 그가 미래에 대해 예측한 것이 전부 적중한 것도 아니었다. 그래도 그는 자기보다 더 똑똑한 엔지니어들을 한데 통솔하고 이끌어서 시너지 효과를 잘 낼 줄을 알았다. 그리고 실수를 하고 병크를 저지르더라도, 회사를 완전히 말아먹을 정도로 치명적으로 하지는 않았으며 곧 수습했다.

한편, 게리 킬달은 뭔가 스티브 워즈니악 같은 포스가 느껴지는 공돌이로 보이는데, 실력에 "비해" 빛을 못 보고 좀 어이없게 훅 가 버린 게 안타깝게 느껴지기도 한다.
기술만 있고 너무 고지식하기만 하면 저렇게 되기 쉬운데, 나부터가 딱 그런 스타일이라는 게 문제임.. -_-;;

Posted by 사무엘

오늘날이야 우리들의 눈을 현혹하는 온갖 사진과 짤방, 동영상들이 인터넷을 통해 컴퓨터로 현기증 날 정도로 범람하고 터져 나가는 시대이다.
하지만 불과 2~30년 전만 해도 PC는 글이 아닌 그림을 처리하기에는 용량과 성능이 꽤 버거운 물건이었다. 컴퓨터로 뭔가 실사 사진 자체를 구해다 보기가 쉽지 않았다. PC 통신으로 인기 연예인 사진을 단 한 장 다운로드 해서 보는 것조차도 단단히 작정하고 기다릴 준비를 하고서 해야 했다. 그리고 그것도 출처는 종이 화보나 필름 사진 스캔, 또는 아날로그 TV 화면 캡처였다..

21세기에 태어난 애들이 이런 얘기를 듣는 건.. 우리 세대가 부모님에게서 1950, 60년대에 나라가 얼마나 폐허였고 못살았는지를 듣는 것과 비슷한 느낌일 것이다. 아아~ 나도 이런 식으로 올드 타이머 꼰대의 대열에 합류하는구나..;;
그래도 난 옛날 컴퓨터 환경 회상이 좋다. 그러니 얘기를 계속하겠다.

그 시절엔 bmp, pcx를 넘어 gif 정도만 돼도 디코딩이 만만한 작업이 아니었다. 아래아한글 도스용에서 그림을 삽입해 보면 gif는 유독 렌더링이 더뎠다. 그런데 하물며 jpg는... 전용 뷰어가 필요하고 386에 램 얼마 이상, 부동소수점 코프로세서는 필수 이런 걸 요구하는 엄청난 포맷이었다. png 역시 그 당시로서는 신생인 만만찮게 무거운 포맷이었고.

이런 이유로 인해 도스에서 그래픽 뷰어는 나름 단순 텍스트/헥스 뷰어 이상의 유니크함과 전문성(?)을 지녔고 또 그래픽 에디터와는 별개의 입지를 가진 프로그램이었다. GUI 운영체제의 셸이 제공하는 기본 중의 기본, 필수 중의 필수 기능이 그때는 그렇게나 특별한 기능이었다. 도스까지 갈 것도 없이 무려 Windows 95 시절, 웹 브라우저 같은 게 없던 때엔 운영체제 차원에서 jpg 파일을 바로 볼 수 있지 않았다. 그림판은 bmp/pcx 전용이었으니까.;;

그래픽 뷰어는 완전 상업용 제품이라기보다는 셰어웨어로 만들기에 좋은 소재였다. 디렉터리 이동 + 파일 리스트 선택 기능을 구현한 뒤, 사용자가 엔터를 누르면 그 그림을 표시해 주는 게 기본 형태이다.
그런데 그것만으로는 좀 단조로우니 그래픽 뷰어에는 여러 장의 그림을 슬라이드 쇼처럼 보여주는 기능이 응당 추가됐다. 현란한 화면 전환 효과는 덤이고. 요즘 같으면 화면 보호기와 역할이 비슷해졌다.

비주얼 쪽 말고 다른 방면으로는.. 파일 관리 기능이 있다는 점에 착안하여 단순히 뷰어 이상으로 많은 그림 파일들을 일괄적으로 포맷을 변환하고 크기를 보정하고 효과를 주는 기능이 들어갔다. 이건 전문적인 그래픽 에디터와도 기능이 겹치는 구석이 있지만, 이쪽은 드로잉 기능이 없으며 한 파일이 아니라 여러 파일들에 대한 일괄 편집에 더 최적화되었다.
이런 분야에 속하는 프로그램으로 본인은 현재까지 다음과 같은 제품들을 기억하고 있다.

1. Graphic Workshop

모 컴퓨터 잡지/서적을 통해 알게 됐다. 1990년대 초인 꽤 옛날부터 개발되어 온 프로그램이며, 내 기억이 맞다면 GIF를 굉장히 일찍부터 지원해 온 걸로 유명했다.
스크린샷을 보면 알 수 있듯, 전반적으로 셸은 파란 배경의 단순한 텍스트 모드에서 동작했고 단순 표시뿐만 아니라 포맷 변환, 크기 조절 같은 그림 파일 관리 기능도 갖추고 있었다.

1989년에 처음 개발됐는데 91년에 벌써 버전이 6을 넘어간 건 도대체 개발과 버전업이 어떻게 돼 왔다는 뜻인지 모르겠다. MS Word는 다른 제품과 번호를 맞추기 위해서 2에서 바로 6으로 넘어가긴 했다만..;;
개발사인 Alchemy Mindworks라는 회사는 지금도 살아 있으며, 이 프로그램은 Windows용으로 계속 개발 중이다.

2. SEA

그래픽 뷰어 중에서는 느낌이 굉장히 인상적이었다. 일단, 왓콤 C/C++ 32비트 에디션으로 만들어진 덕분에, 게임도 아닌 것이 첫 실행 때 DOS/4GW(도스 익스텐더) 로고가 떴다.
성능면에서는 jpg 파일의 디코딩이 경쟁 프로그램들 중 가장 빠르다고 자처했다. 그림뿐만 아니라 소리 파일 재생이 됐으며, 동영상도 AVI 중에 1990년대 중반 런렝쓰 정도의 간단한 방식으로 압축 된 건 바로 재생 가능했다.

스크린샷을 보면 알 수 있듯 일괄 변환과 슬라이드 쇼 기능 정도는 물론 갖추고 있었으며,
이 모든 것에 더해서 전반적인 GUI 껍데기도 NextStep 운영체제를 흉내 낸 듯한(바탕에 검정 제목 표시줄) 상당한 고퀄이었다.
여러 모로 인상이 좋고 장인 정신이 느껴지는 잘 만든 프로그램이었다. 비등록 셰어웨어 버전도 첫 실행 때 '등록 해 주세요. press any key'가 뜨는 것 말고는 별다른 제약이 없어서 상당한 대인배이기까지 했다.

3. ACDSee

운영체제에 gif/jpg/png급 그림 파일을 보는 기능이 자체적으로 없던 Windows 95~98/2000 시절에는 개인적으로 이 프로그램을 유용하게 썼다. 이름이 똑같이 '씨'인데 앞의 도스용 프로그램은 sea이고 요 프로그램은 see이다.
얘도 한때는 내가 운영체제를 새로 설치한 뒤에 MDIR만큼이나 곧장 설치하는 필수 프로그램 중 하나였다. 굉장히 유용하게 썼다. SEA의 Windows 버전이나 마찬가지였는데, 해당 기능을 운영체제가 흡수한 뒤에는 정말 자연스럽게 존재감이 싹 없어져 버렸다.

그 첫 신호탄은 Windows에 IE 웹브라우저가 포함돼 들어가면서 기본적인 그래픽 뷰어 문제는 사실상 제공되기 시작한 사건이다. 월드 와이드 웹이라는 게 글과 그림으로 이뤄져 있으며 웹브라우저는 그 자체가 훌륭한 단백질 공급원은 아니고 훌륭한 그래픽 뷰어였기 때문이다. 단, IE는 옆 파일을 바로 열람하는 기능조차 없고 진짜 보는 것 하나만 가능하기 때문에 전문 뷰어/슬라이드 쇼 프로그램이 여전히 존재 의미가 있었다.

한 디렉터리 안에 있는 그림 파일들을 IE 창에서 쭈욱 열람하기 위해서 그 디렉터리를 기준으로 <img src="...."/> 태그를 쭈욱 나열하는 html 파일을 '생성하는 프로그램'을 짜서 개인적으로 활용했던 기억이 있다. 물론 이건 썸네일만 읽어들이는 게 아니라 파일들을 몽땅 한 페이지에다 읽어들이는 것이니 성능면에서는 좀 안습한 짓이긴 하다.

그리고 둘째 확인사살은 Windows XP이다. 얘부터는 탐색기 내부의 파일 리스트에서 그림 썸네일을 보는 편의 기능이 크게 강화되었으며, 그럭저럭 가볍고 괜찮은  그래픽 뷰어까지 내장됐기 때문이다. 그러니 별도의 싸제 그래픽 뷰어 프로그램에 대한 필요는 거의 사라졌다. 이런 이유로 인해 기존의 그래픽 뷰어들은 생존을 위해서 포토샵 같은 이미지 보정 기능을 더 강화한다거나 디지털 카메라 사진 관리 같은 더 차별화되고 전문적인 영역으로 넘어갔으며, 내 기억 속에는 현업에서 다들 물러나고 추억의 영역만 남게 되었다.

한때는 Paint Shop Pro에 내장돼 있는 Browse 기능도 유용하게 썼던 것 같은데 지금은 그냥 MS Office에서도 2003부터 Picture Manager라는 유틸리티가 생겨 있다. 예전에는 희귀했던 기능들이 지금은 다 기본으로 내장되고 대중화가 된 것이다.
단, Windows XP의 기본 그래픽 뷰어는 애니메이션 GIF를 재생하는 것까지도 지원했는데 Vista 이후부터는 그 기능은 없어졌다. 왜 빠졌는지는 알 길이 없다.

여기까지가 그래픽 뷰어 프로그램에 대해 본인이 갖고 있는 추억이다.
하긴, 음악을 듣는 것도 한때 꽤 먼 옛날엔 거원 제트오디오, WinAmp 같은 프로그램을 따로 썼다. 그러다 언제부턴가 그냥 WMP만 쓰지 다른 건 안 쓰게 됐다.
그래도 동영상은 WMP가 코덱과 자막 등 부족한 구석이 많이 있어서 팟/곰 같은 제3자 프로그램이 여전히 살아 있다. 내가 알기로 마소에서 WMP도 거의 IE11만큼이나 이제 더 만들 게 없는지 별로 육성은 안 하는 것 같다.

Posted by 사무엘

텍스트를 입력· 편집하는 기능을 제공하는 에디터나 개발툴, 워드 프로세서에는 응당 텍스트를 검색하는 기능이 있다.
찾기 명령은 아무래도 바꾸기 명령과도 같이 쓰이는 경우가 많으니 이건 편집 기능의 일종으로 간주되며, 보통은 '편집' 메뉴의 하위 항목으로 들어가는 편이다.
그러나 편집 메뉴가 이미 다른 기능들로 너무 비대한 상태이거나, cursor를 원하는 조건대로 이동시키는 찾기/탐색 기능이 별도로 굉장히 전문적으로 발달해 있는 경우, '검색(Search)'이라는 메뉴가 따로 존재하기도 한다.

이 메뉴 구성은 프로그램들마다 제각각이다.
과거에 아래아한글은 1.x대까지 '찾기' 메뉴가 별도로 있다가 2.1부터 '편집'으로 들어갔다. 전반적으로 기능들이 메뉴에 많이 추가되면서 두 메뉴의 인수 합병에 정당성이 생긴 것이다.
Windows의 메모장은 9x 계열의 것은 '찾기' 메뉴가 존재하는 반면, 2000/XP의 것은 그렇지 않고 '편집' 메뉴에 있다.

<날개셋> 편집기는 1~2.x대까지는 찾기 기능이 '편집' 메뉴에 있었지만, 3.0부터는 별도의 '검색' 메뉴로 분리되어 지금에 이르고 있다. 검색과 관련된 기능들을 전부 편집에다가 몰아 넣으면 보기, 삽입, 도구 같은 다른 메뉴들에 비해 '편집'만 항목 수가 너무 많고 비대해지기 때문이다.
그렇다고 <날개셋> 편집기가 무슨 메모장만치 그렇게 기능이 적은 초소형 프로그램도 아니니.. 양 극단 사이에서의 고민 끝에 지금과 같은 메뉴 배치를 선택했다.

한편, 내 편집기에는 없지만 좀 기능깨나 있다 싶은 텍스트 에디터들은 Find in files 기능이 필수이다. 그런데 알고 보면 얘의 정체성도 약간 오락가락 하는 편이다.
아래아한글은 2.0에서 이 기능이 최초로 추가된 이래로 요게 '파일' 메뉴에 쭉 있어 왔으며, Visual C++ IDE도 옛날 버전에는 한동안 파일 메뉴에 있었다. 아무래도 한 문서를 편집한다기보다는 inter-file스러운 기능이라고 생각하고 그렇게 '파일'에다 분류했던 듯하다.

하지만 Visual C++의 경우 6인가 닷넷 이후부터 이 기능은 '편집' 메뉴로 이동했으며, IDE의 버전이 올라갈수록 요건 기존 '찾기' 기능의 자연스러운 연장선 형태로 인터페이스가 바뀌어 왔다는 게 주목할 점이다.
물론 '검색' 메뉴가 별도로 있는 에디터라면 Find in files는 응당 파일도 편집도 아닌 그 메뉴에 자리잡고 있다.

프로그램의 전반적인 옵션을 지정하는 명령이 요즘은 도구 메뉴의 맨 마지막에 있는 게 대세이지만, 한때는 preference라는 이름으로 파일 메뉴에 있기도 하고 Adobe Reader처럼 아예 편집 메뉴의 있기도 한 것과 비슷한 모습을 보는 것 같다. 옛날에는 역시 '옵션'이라는 메뉴가 별도로 있기도 했지만 프로퍼티 시트의 등장으로 인해 한 대화상자에서 엄청 많은 옵션들을 죄다 몰아서 지정하는 게 트렌드가 되면서 옵션만을 위한 메뉴는 요즘 UI 트렌드에서는 사라지는 추세이다.

끝으로, 이 검색 메뉴가 존재한다면 그 위치가 어디쯤인지를 살펴보고자 한다. 파일이야 맨 먼저 등장하는 것이 불문율이지만, '보기', '삽입(입력)' 같은 다른 메뉴와 비교했을 때 상대적인 순서가 어떻게 될까?
앞서 말했듯이 찾기 기능은 편집과 밀접한 관계가 있기 때문에 아무래도 편집 메뉴의 바로 다음에 오는 것이 가장 자연스러워 보인다.

그래서 실제로 검색 메뉴가 따로 존재하는 많은 프로그램들은 "파일-편집-검색-(보기)"의 순으로 메뉴가 구성되어 있다. NotePad++, Source Insight, 그리고 도스와 Windows용을 막론하고 볼랜드 IDE (Borland C++, C++Builder, 델파이), AcroEdit 등.

그런데 <날개셋> 편집기는 "파일-편집-보기-검색"으로, View 메뉴가 더 앞에 있다. 검색 메뉴가 처음으로 추가되었던 3.0 초창기 시절에는 "검색-보기"이었는데 나중에 모종의 이유로 인해 "보기-검색"으로 바뀌었다.
"검색-보기"가 적힌 과거의 흔적은 까마득히 먼 옛 버전을 기준으로 만들어진 프로그램 스크린샷 움짤들을 보면 확인할 수 있다.

"보기-검색"으로 순서를 바꾼 이유는 아마 본인이 옛날에 개발 과정에서 참고했던 EditPlus가 "보기-검색" 순이어서 그랬던 것 같다.
그리고 또 흥미로운 것은, 마소에서 만든 도스용 QBasic과 QuickBasic, 그리고 후대 버전인 QBX (MS Basic PDS 7), 도스용 비주얼 베이직 그쪽 라인은 역시 "보기-검색"이다.

그 반면, Windows 95와 그 이후에 새로 등장한 MS-DOS 에디터는 "검색-보기"로 돌아갔다. 대화상자에 선문자가 없는 그 프로그램 말이다.

원론적으로 따졌을 때 "검색-보기"가 더 자연스러우며 그 역순은 EditPlus와 QBasic 계열 같은 예외적인 프로그램에서밖에 존재하지 않는다는 점을 근거로, <날개셋> 편집기도 이번 8.4부터는 다시 "보기-검색"이 아니라 "검색-보기"로 복귀했다.
이 조치를 내리기 위해 저런 리서치와 고민이 있었음을 이 자리에서 밝힌다. ^^

Posted by 사무엘

이건 개인적으로 오래 전부터 알고 있었던 사소한 옛날 추억 아이템인데, 지금까지 한 번도 공개적으로 언급한 적이 없었던 관계로 털어놓고자 한다.

Windows에 메모장은 1.0 시절부터 있었던 터줏대감 기본 프로그램이다. 기본 윈도우 프레임 껍데기에다 운영체제의 내장 에디트 컨트롤 하나만 달랑 얹은 극도의 최소주의 형태이다. 세월이 흐르면서 워드패드와 그림판은 리본 UI가 탑재됐고 계산기도 아주 화려한 UI로 리모델링된 마당에, 메모장만은 외형이 거의 바뀐 게 없다.

Windows 프로그래밍 공부를 한 사람이라면 메모장 정도는 하루 정도만 투자하면 동일 프로그램을 직접 만들 수도 있을 것이다. 아니, 있는 그대로 복제품만 만드는 건 너무 시시하고, MDI 정도는 지원하게 확장해서 만들기도 한다. 지금도 있는가 모르겠는데 비주얼 C++의 MFC 예제에는 MultiPad라고 실제로 메모장의 MDI 버전도 소스 코드와 함께 제공된 바 있다.

그런데 Windows 95부터 ME까지 9x 계열의 메모장은 '도움말'이라는 메뉴 명칭의 뒷부분에 출처를 알 수 없는 공백이 하나 더 들어가 있었다. 아래 스크린샷을 참고할 것. 계산기의 '도움말'과는 달리, 메모장의 '도움말'은 파란색이 조금 더 긴 게 보일 것이다.

더욱 신기한 건, 98과 ME로 버전이 올라가도 상황이 바뀐 게 없었다는 점이다. 그것도 한글판과 영문판 공히.
메모장이 아무리 최소주의 기본 프로그램이었다고 해서 그 시절 동안 변화가 전혀 없었느냐 하면 그렇지는 않았다. 보다시피 아이콘 모양이 바뀌었으며 본문의 글꼴을 변경하는 기능이 98에서 추가되었다. 코드뿐만 아니라 리소스 쪽도 검수할 기회가 있었는데 저 문자열의 뒤의 공백은 여전히 제거되지 않은 채 남았다.

그 반면, Windows 2000의 메모장은 그렇지 않다.

ME는 2000보다 나중에 나왔음을 감안한다면, 같은 메모장도 NT 계열의 것과 9x 계열의 것은 코드와 리소스가 정말로 한데 공유된 구석이 없었다는 걸 알 수 있다. 같은 소스에서 조건부 컴파일을 한 것조차도 아닌 듯하다.

심지어는 도움말도 둘 다 완전히 다르게 따로 만들어졌다. Windows ME의 메모장 도움말은

이라고 사용자에게 당장 필요한 task 지향적인(use, using) 설명 위주인 반면.. Windows 2000의 메모장 도움말은

이라고 프로그램의 정체성에 대해서 더 사무적이고 격식을 차린 문체로 시작한다.

메모장은 아주 단순한 프로그램이지만 9x 계열의 것과 NT 계열의 것이 기능상의 차이도 꽤 크다. 후자는 (1) 유니코드를 지원하며 (2) 64KB 이상 크기의 파일도 열 수 있다. 다시 말해 전자는 "파일이 너무 큽니다. 워드패드에서 여시겠습니까?" 이런 로직이 존재하며, 지금으로서는 상상하기 어렵지만 UTF8 방식 텍스트를 읽고 쓰는 것조차도 지원하지 않았다.

물론 운영체제의 에디트 컨트롤이라는 건 리치 에디트와는 달리 아주 방대한 텍스트를 편집하는 데는 최적화되지 않았던지라 단일 버퍼 기반이라는 한계는 NT 계열도 그대로 갖고 있었다.

또한 NT 계열의 메모장은 BOM이 없는 유니코드 텍스트 파일에 대해서 IsTextUnicode라는 휴리스틱 API를 호출해서 텍스트 파일의 인코딩을 판단했었다. 그런데 그게 좀 버그가 있어서 정상적인 영어 단어로만 이뤄진 짤막한 파일을 UTF16 방식으로 저장된 중국어 한자로 오판하곤 했다. 0x41, 0x42.. 이런 묶음이 코드값상으로는 한중일 통합 한자 내지 확장 A이다 보니.. -_-;;
이 버그는 보안 쪽 문제는 아니지만 그래도 사람을 성가시게 하는 문제인 관계로, 2000이던가 XP 즈음에 패치가 나와서 고쳐졌다.

Windows 9x에는 IsTextUnicode라는 함수 자체가 존재하지 않으니 9x 계열의 메모장이야 저런 문제가 존재할 여지조차 전혀 없었다.
끝으로, 메모장은 아마 Windows XP에서 '상태 표시줄'을 표시하는 옵션이 추가된 게 현재까지 외형상의 마지막 변화 사항이지 싶다. '자동 줄바꿈'을 사용하지 않을 때에 한해서 줄/칸 위치를 표시하는 깨알같은 기능이 추가된 것이다.

이런 Windows와 메모장의 유구한 역사 속에서 도스용 Windows 3.x 내지 NT 3~4의 메모장에는 '불필요한 공백'이 존재했었나 모르겠다.

Posted by 사무엘

도스와 유닉스 명령창 공히 디렉터리를 이동할 때는 cd 내지 chdir이라는 명령을 사용한다. 단, 도스는 드라이브 이름을 A~Z 알파벳 한 글자로 표현한다는 게 마치 날개셋의 수식 변수만큼이나 특이하며, Windows는 이 관행을 그대로 물려받았다. 파일명에 대소문자를 구분해서 표현은 하지만 유닉스와는 달리 이를 서로 다른 것으로 취급하지는 않는다. 또한 디렉터리 구분자가 /가 아니라 \(역슬래시)라는 것도 유닉스 계열과 다르다.

그 뿐만이 아니다. 도스는 cd라고만 치면 현재 디렉터리를 표시만 해 주는 반면, 유닉스는 cd라고 치면 그냥 자신의 홈 디렉터리, Windows로 치면 "C:\Users\계정명" 정도로 이동해 버린다. 도스가 유닉스의 다른 개념들은 다 따 왔어도, 이건 다중 사용자라는 개념이 없던 물건이다 보니 홈 디렉터리 같은 건 도입하지 않기 때문이다. 유닉스에서 지금 디렉터리를 표시하는 명령은 잘 알다시피 pwd라고 따로 있다.

그렇게 도스와 유닉스 계열이 차이가 나는 와중에도 . 가 현재 디렉터리를 의미하고 ..는 부모 디렉터리를 의미한다는 건 둘이 동일하다. cd ..를 하면 부모 디렉터리로 갈 수 있다. 다만, 문법이 둘이 완전히 동일한 건 아닌지라.. 도스는 cd..라고 둘을 띄지 않아도 됐던 반면, 유닉스는 둘을 띄워야 한다는 깨알같은 차이점이 또 있다.

그런데 Windows 9x의 도스창에서는 숨겨진 기능이 더 있었다. cd 다음에 점을 세 개 이상 늘어놓음으로써 두 단계 이상의 조부모 디렉터리로 이동이 가능했다. cd...처럼. 그럼 저건 cd ..\.. 를 의미한다. 네 개 이상 숫자를 얼마든지 늘어놓아도 된다.
게다가 이건 파일 시스템 차원에서 공식적으로 인식하기라도 하는지, 굳이 cd에서만 쓸 수 있는 게 아니다. dir ... 이라고 하면 두 단계 상위 디렉터리를 조회할 수 있고, Windows의 파일 열기/저장 대화상자에서도 "..."이라고 치면 동일 기능이 동작했다.

Windows 9x는 C:\Windows 디렉터리를 가 보면 readme 등 몇몇 '읽어 보세요' 문서가 html이나 doc나 rtf가 아니라 txt 파일로 들어 있었는데, 그 중엔 tips.txt가 있다. 그 파일에 cd...에 관한 언급이 존재한다.

위는 영문판 Windows ME, 아래는 한글판 Windows 95의 tips.txt 내용 일부이다.

이 기능은 이전의 도스 시절엔 존재한 적이 없었으며 Windows 95에서 처음으로 추가되었다는 것이 명시되어 있다. 또한 95의 문서에서는 ....로 디렉터리를 세 단계 건너뛰는 예를 제시하는 반면, 후대 98/ME의 문서는 ...로 두 단계만 건너뛰는 예를 제시한다. C:\로 바뀌는 건 cd\와 동일하기 때문에 예제를 바꾼 게 아닌가 싶다.
참고로 Windows의 한글판은 98부터 '디렉토리'라는 표기가 '디렉터리'로 바뀌고, 문서들의 문체가 반말에서 존댓말로 바뀌었다.

놀라운 사실은, 이 기능은 오늘날의 Windows NT 계열에서는 지원되거나 존재한 적이 전혀 없었고 오로지 95, 98, ME만의 관행이었다는 점이다.

The old new thing 블로그의 설명에 따르면 cd ...는 노벨 네트웨어(Novell NetWare)라는 네트워크 솔루션에서 제공하는 명령 문법과의 호환성 때문에 편의 차원에서 도입된 기능이라고 한다. 그땐 노벨 사의 IPX/SPX 프로토콜 기반으로 네트워크 구성요소들도 있었으니 수긍이 간다.

그리고 9x와 달리 NT에서 ...를 지원하지 않은 이유는, 윈NT가 사용하는 NTFS 파일 시스템에서는 '.'나 '..'와는 달리 '...'는 그 자체가 올바른 파일이나 디렉터리 이름이 될 수 있기 때문이다. 그렇기 때문에 NT 계열에서는 이런 기능을 앞으로 지원할 의향은 더욱 없다고 봐야 할 것이다. 그냥 cd..\..를 해야지, 약칭인 cd...는 IPX 프로토콜이 존재하던 Windows 9x 시절의 추억으로 old timer들에게 남을 것으로 보인다.

9x 시절에는 dir con\con이던가, '실행' 대화상자에서 con\con 이런 걸 치면 운영체제를 뻗게 하고 도스창을 강제 종료시키는 게 가능했다. 이건 꽤 유명한 버그였으며 ME에서야 보정을 통해 패치가 됐다. cd ...는 그것만큼이나 9x 시절에 파일 시스템과 관련해 흥미로운 고유 아이템 추억거리인 것 같다.

여담으로, 명령 프롬프트에서 공백은 여러 명령 인자 토큰들을 구분하는 역할을 한다. 그렇기 때문에 거기서 공백이 들어간 파일을 표시하기 위해서는 파일명 전체를 ""로 싸야 하며, 각종 프로그래밍 언어에는 따옴표 문맥을 인식하면서 공백 기준으로 명령 인자들을 파싱· 토큰화하는 라이브러리도 존재한다. 그러나 이 cd 명령만은 예외로 공백이 들어간 디렉터리도 CD Program Files 라고만 쳐도 인식되게 되어 있다. cd /?를 해 보면 이 사실을 확인할 수 있음.

그리고 cd에는 드라이브까지 같이 변경하는 명령이 한동안 존재하지 않았다. 도스 커맨드 셸의 대체제이던 4DOS 내지 NDOS에서는 자체적인 명령 확장을 통해서 그런 기능을 제공하곤 했는데, 오늘날 Windows에서는 /D 라는 별도의 옵션을 줘야만 드라이브도 변경 가능하다. 아마 드라이브를 변경하지 않는 게 보장된다는 무슨 호환성 때문에 옵션 형태로 기능을 추가한 것 같다. 참고로 /D는 9x의 도스창에는 존재하지 않으며, Windows NT 계열의 명령 프롬프트에만 있다. ...를 지원하지 않는 대신 /D가 있는 셈이다.

Posted by 사무엘

* 꽤 오래 전인 블로그 개설 초창기에 썼던 글을 리메이크 한 것이다.

※ 1.0부터 9x/ME까지
가난하지만 파이가 가장 큰 16비트 도스 진영을 특별히 공략한 전용 제품이다. 그러니 x86 전용. 가난한 컴에서 리소스를 최대한 짜내야 했던 관계로 코드는 쑤제 어셈블리어가 가득했으며, 어차피 이식성도 없었다.

※ NT 3~4
9x 같은 현실 절충이 아니라, 이상과 이식성을 추구한 컨셉을 살려 x86뿐만 아니라 Alpha, MIPS를 지원했다. 특히 NT 4의 경우 PowerPC까지 지원하여 지원하는 아키텍처가 가장 많았다. 실행 파일 포맷의 이름을 괜히 Portable Executable이라고 지은 게 아니었다.
Alpha의 경우 64비트 아키텍처이긴 했지만, Windows 자체는 여전히 32비트로만 동작했다. 물론 그때는 메모리 용량상으로 64비트는 어차피 전혀 의미가 없었으며, 단지 같은 클럭으로 32비트보다 대용량 데이터를 더 빠르게 처리한다는 점에서만 의의를 둘 수 있었을 것이다.

참고로 OS/2는 Windows NT에 준하는 귀족 된장(?) OS임에도 불구하고 이식성이 없이 x86 전용이었다. 이식성 있는 코드 위주로 개발되지 않았기 때문이다.

※ 2000
NT 계열이지만, 이제 한물 가고 망했다고 간주되는 아키텍처들에 대한 지원을 대거 끊어서 사실상 x86 전용이 됐다. 인텔에서 발표 예정인 IA64 Itanium 아키텍처와 연계하여 최초의 레알 64비트 OS로 거듭나려 했지만 CPU의 출시가 늦어지는 바람에 제대로 성사되지 않았다.

※ XP
이제야 x86 (32비트)과 Itanium (64비트) 에디션이 동시에 발매되었다. 하지만 Itanium는 알고 보니 정말 대차게 망한 관계로, 얘를 정식으로 지원하는 Windows는 XP가 처음이자 마지막이 됐다. -_-;;
그 대신 x86과 잘 호환되는 x64 내지 x86-64라는 새로운 아키텍처가 64비트 PC의 대세가 되었다. PC도 이제 메모리가 슬슬 4GB 방벽에 걸릴 타이밍이 되기도 했고.

그래서 2005년, 이미 SP2까지 출시되고 나서야 Windows XP는 x64용 에디션이 나왔다. 허나 정말 존재감 없이 지나가 버렸으며, XP는 대외적으로 여전히 싱글 코어 + 32비트 OS의 상징이라는 이미지가 압도적으로 더 강하다.

※ Vista와 7
Itanium은 칼같이 짤렸고 그 대신 x86 (32비트)과 x64 (64비트) 패턴이 나란히 정착했다. 7부터는 서버 에디션은 이제 32비트가 없이 64비트 에디션만 나오고 있다.

※ 8과 그 이후
저기에다가 모바일용 CPU인 ARM 에디션이 새롭게 추가됐다만, 이 에디션은 키보드 달린 일반 컴퓨터에서 볼 일은 딱히 없을 것 같다. 이 구도가 당분간 계속 이어질 듯.

이렇듯, Windows는 운영체제의 버전이 바뀌면서 지원 플랫폼도 은근히 자주 바뀌어 왔다. 이 외에도 운영체제 별 문자 입력 시스템의 변천사라든가 다국어 글꼴 시스템의 변천사를 다뤄도 무척 재미있을 것 같다.

다국어 하니까 짚고 넘어갈 사항으로는..
Windows NT는 3.51부터 한글화되어 나왔다. 그러나 한글판이 나온 건 1996년, 이미 95도 나오고 NT 4.0이 나오기 몇 달 전이었던지라 3.51의 한글판은 별로 주목받지 못했다. 그러니 NT 3.51이 윈도 3.x의 셸 기반이었다고 해서 NT 3.51의 한글판이 한글 윈도 3.x의 투박한 비트맵 바탕체를 썼다거나 하지는 않았다.

Windows 자체가 한글판이 나온 건 무려 2.1때부터라고 한다. 하지만 1980년대 말에 우리나라 IT 인프라에서 뭘 그리 바랄 게 있겠는가..? 이 역시 3.0이 나오기 얼마 전일 정도로 시기가 매우 늦기도 해서 존재감은 거의 부각되지 않고 싹 묻혔다. 저 광고 말고는 스크린샷이고 기록이고 뭐고 아무것도 없다.

Posted by 사무엘

문자· 문서를 처리하는 기계의 역사를 살펴보면 기계식 타자기가 발명된 뒤 나중에는 전자식 타자기가 만들어지고, 그게 더 나중에는 컴퓨터가 달린 휴대용 워드 프로세서 기기 형태로 발전했다.

그 뒤 특정 장치에 구애받지 않고 범용 컴퓨터에서 동작하는 워드 프로세서 소프트웨어도 개발되긴 했지만 이 역시 특정 컴퓨터 내지 프린터 번들의 성격이 강했다. 아무래도 워드 문서의 최종 목적지는 인쇄였던지라 프린터의 입김에서 자유로울 수 없었으니 말이다. 게다가 윤곽선 글꼴이 없었으니 글꼴부터가 애초부터 프린터의 해상도에 따라 도트판/레이저판으로 나뉠 수밖에 없었다.

이런 척박한 여건에서 옛날 도스 시절에 '한글'을 처리할 수 있는 워드 프로세서가 몇몇 컴퓨터 선구자들에 의해 개발되었다. 그래픽 모드에서 실행되었던 도스용 한글 워드 프로세서로 제대로 살아남은 건 아래아한글밖에 없다.
관공서에서 많이 쓰였던 '하나' 내지, 삼보 컴퓨터 번들로 제공되었던 '보석글'(엄밀히 말하면 순수 국산 프로그램은 아님)은 그래픽 기반이 아니었기 때문에 편집 중에 각종 속성들은 태그 부호로 표시되었다는 한계가 존재한다..

0. 하나

1995년까지 금성이 아닌 LG 소프트웨어라는 브랜드로도 생각보다 오랫동안 개발됐다. 95년이면 아래아한글은 이미 Windows용까지 나왔을 정도였으니 시대에 너무 뒤쳐지긴 했다. 물론 금성/LG 소프트웨어에서도 그 시기에 다른 팀을 꾸려서 Windows용 '윈워드'라는 제품을 개발했으며 이걸 2.0까지도 만들긴 했지만... 더 오래는 못 갔다.

‘하나’도 아래아한글처럼 문서 확장자가 hwp였다. 하지만 둘은 동일한 포맷은 물론 아니었다. 아래아한글이 하나 문서를 읽거나 쓰는 건 ‘공용(공통) 파일’이라는 이름으로 최소한 아래아한글 2.5나 3.0 등 도스용 에디션의 막바지 시절에야 추가됐다. 자기 hwp와 구분을 위해 확장자는 일부러 kwp라고 했다.

하나와 아래아한글 모두 관공서에서 사랑받은 프로그램답지 않게 한때 보안이 좀 허술했다. 하나의 경우 암호를 걸어서 저장해도 암호가 문서 파일의 헤더에 평문으로 버젓이 저장되었는지 군대에서 이렇게 암호를 뚝딱 풀어서 중대의 영웅으로 추앙받았다는 분의 무용담이 전해진다.

한편, 1994년경엔 아래아한글 2.1 (2.1과 2.5 공용) 파일 포맷의 암호도 어느 서울대 출신의 천재 해커에 의해 뚫려서 화제가 됐는데..
이건 이적행위 증거를 찾으려고 지금의 국정원, 당시의 안기부에서 작정을 하고 해커를 고용해서 뚫은 것이었다고 한다. 개발사인 한컴이 이적행위를 했다는 건 물론 아니고, 사용자 중에 불온문서를 만든 사람이 있었다는 뜻.
단순한 오덕질이나 사적 이익 때문이 아니었다는 점이, 그리고 또한 단순히 한 특정 문서의 암호만 brute force 방식으로 대입해서 알아낸 게 아니라 전반적인 암호화 알고리즘 자체를 파악하고 예측하는 데 성공해 버렸다는 점이 무척 놀랍다.

그 당시 한컴은 2의 32승 운운하면서 “암호를 걸었던 사람이 암호를 잊어버리면 우리조차도 암호를 풀 수 없다. 암호를 뚫으려면 130년은 족히 걸릴 것”이라고 언론 보도까지 내면서 아주 자신만만한 모습이었다. 그런데 그것이 실제로 일어나자 망연자실할 수밖에 없었다. 다음 3.0 버전에서는 즉시 암호화 알고리즘을 변경해야 했다.

그럼 다음부터는 자체한글 '그래픽' 모드에서 실행된 프로그램 얘기를 하겠다.
본인은 오래 전에 윤곽선 글꼴로 한글을 찍는 기능이 어떤 형태로든 있었던 도스용 프로그램을 주목하여 몇 가지 예를 든 적이 있다.
아래아한글 2.x를 제외하면 그래픽 에디터 내지 배너 프로그램이 걸려들곤 했는데, 그것들 말고 아래아한글과 비슷한 급의 상업용 워드 프로세서로는 다음 두 프로그램이 있다. 단, 본인은 어렸을 때 이들 프로그램을 직접 써 보지는 못했다.

1. 사임당

난 10여 년 전에 우리나라에서 5만원권 지폐를 신권 형태로 첫 발행했을 때 이 프로그램이 떠올랐다. 지폐에 들어간 모델 때문이긴 하지만, 그래도 써 본 적도 없는 프로그램을 어떻게 그렇게 분명하게 기억하고 있었는지는 모르겠다.

사임당은 윤곽선 글꼴, 위지윅, 컬러 지원, 그래픽 처리 등의 기술적인 면에서는 아래아한글 2.x 초반대 버전보다 더 뛰어나면 뛰어나지 절대로 못하지는 않았던 매우 우수한 프로그램이었다. 그런 기능들은 따지고 보면 오히려 아래아한글이 도입 타이밍이 더 늦거나 전문용에만 오랫동안 봉인돼 있었다. GUI만 봐도 뭔가 비범한 구석이 느껴지지 않는지?

저기 '무른연모'라는 글자를 보아하니 휴먼샘체/팸체(안상수체는 아님) 같은 한글 가변폭 글꼴도 잘 지원하고 있었다.
사임당은 분명 시대를 앞서갔던 프로그램이었지만, 위키백과의 설명에 따르면 비싼 가격과 강경한 복제 방지 정책 때문에 그리 많이 보급은 못 됐으며 아래아한글을 실질적으로 위협하지 못하고 사라졌다고 한다.

사임당의 개발사인 한컴퓨터 연구소/주식회사도 오늘날의 한글과컴퓨터 못지않은 워드 프로세서 개발 전문 기업이었다. 예전부터 사임당의 전신인 '한글 2000'이라는 프로그램을 만들었고, 사임당 말고도 저가 보급형 프로그램인 '쪽박사, 글박사' 같은 프로그램을 따로 개발했다. 글박사의 경우 본인도 초딩 시절에 컴퓨터 잡지에 소개된 걸 본 기억이 있다. 무려 1992년에! 하지만 이 역시 실물을 직접 써 보지는 못했다.

사임당, 글박사 등의 스크린샷을 보면 저기서 만든 워드 프로세서들은 전통적으로 세로획도 1픽셀인 고딕 계열 글꼴을 UI 표시용 한글 글꼴로 써 왔다. 세로획이 2픽셀인 명조 계열 글꼴을 사용한 아래아한글과는 대조적이다.

2. 21세기 워드

아래아한글과 사임당으로도 모자라서 도스에서 한글 윤곽선 글꼴을 지원했던 그래픽 워드 프로세서가 더 있었다. 그것은 바로.. 지금은 알집과 카발(온라인 게임)로 유명한 그 회사가 먼 옛날 초창기에 만들었던 제품이다.

본인은 실물을 써 보지는 못했지만 컴퓨터 잡지에서 광고를 한 건 봤다. 글꼴을 가지고 대놓고 아래아한글을 디스하고 있었다.
모 제품은 가격이 8만 8천원이나 하는데도 글꼴이 꼴랑 다 깨지는 비트맵 명조로밖에 안 나오는 반면,
우리 21세기 워드는 그거 거의 반값으로도 아주 미려한 윤곽선 글꼴 신명조가 나온다고...;;

디스 당한 모 제품은 뭔지 직접적으로 언급은 안 돼 있지만, 누가 봐도 아래아한글 2.0이던가 2.1의 일반용인 건 뻔한 노릇이었다.
이를 의식해서인지 아래아한글도 2.5 버전에 와서야 일반용/전문용 구분을 없애고 16비트 컴퓨터에서도 컬러와 윤곽선 글꼴을 실현시켰지만.. 때가 좀 늦은 조치였다.

21세기 워드는 글자 크기 조절과 윤곽선 글꼴을 빼면 나머지 워드로서의 기능은 아래아한글 1.5x와 크게 차이가 나지 않았다고 한다. 화면을 딱 봐도 색상이나 글꼴은 아래아한글 1.5x를 대놓고 오마주한 것 같지 않은가? ㅎㅎ
단, 한글의 비트맵 글꼴 명조체는 아래아한글 1.5x가 사용하던 그 명조와는 다르다. 아래아한글은 custom 3차원 조합 테이블을 사용한 약간 더 정교한 글꼴인 반면, 21세기는 그냥 그 당시에 널리 통용되던 초중종 8*4*4벌 도깨비 조합 규칙으로 구현된 명조이다.

어떻게 아냐고? 다 방법이 있다.
도깨비 조합형은 세로줄형 모음에서 받침 ㄴ일 때와 이외의 다른 모음일 때의 구분이 없다. 그래서 '편'(집)일 때와 (입)'력'일 때 ㅕ가 길이가 똑같아서 받침 ㄴ일 때 아래 공간이 약간 허해 보인다.
그 반면, 지금 <날개셋> 편집기의 '바탕'으로 채용돼 있는 아래아한글의 명조는 받침 ㄴ일 때 세로 모음들이 딱 1픽셀 더 길어서 아주 조금 더 균형이 잡혀 보인다. 이런 작은 차이가 존재한다.

사소한 글꼴 디테일 얘기는 그렇고.
그 당시 이스트소프트는 파릇파릇한 공대생 몇 명이 갓 창업한 벤처/스타트업 수준에 불과했기 때문에 기술과 영업 역량에 한계가 있었다. 물론 그 여건에서 천재 프로그래머 몇 명이 이 정도를 뚝딱 만든 건 정말 대단한 일인 건 맞지만, 그런 몇 가지 차별화 요소만 갖고 아래아한글이라는 기득권 아성을 무너뜨릴 수는 없는 노릇이었다.

21세기 워드는 사임당 정도의 엘리트주의로 간 것 같지는 않지만, 어쨌든 그렇게 망하고 역사 속으로 사라졌다. 이걸 계기로 이스트의 창립자분은 뭔가 깨달은 게 있었는지, "그냥 기술적으로 뛰어나기만 한 제품"이 아니라 "사용자에게 잘 어필되고 실질적으로 팔리는 제품"을 만들어야겠다는 실용주의 노선으로 생각을 급선회하게 됐다고 한다. 하긴, 에디슨도 처음엔 자기 오덕질대로만 외곬스러운 발명을 하다가 나중에야 그렇게 깨닫는 계기가 있었다고 들었다.

21세기 워드를 만들었던 회사는 그로부터 6, 7년쯤 뒤 21세기가 실제로 임박하자, 이번엔 '새 폴더'를 비롯해 아주 익살스러운 외형의 압축 프로그램을 무료로 뿌리면서 컴백했다. 본인은 2000년 말, 알집을 4.8대 버전 때 처음으로 접했다. 그런 식으로 잘나갈 수도 있었고 "개인에게만 무료, 기업은 유료" 정책도 나쁘지 않은 것 같았는데.. 프로그램이 압축 본연의 기능이 탄탄하지 않다는 나쁜 소문이 2000년대 초중반에 워낙 퍼지면서 안 쓰게 됐고.. 지금은 빵집을 거쳐서 반디집이 국민 압축 프로그램 타이틀을 물려받았다. 빵집은 퀄리티가 나쁘지는 않았으나 보다시피 개발이 중단됐으니 말이다.

워드 얘기를 하다가 갑자기 딴 얘기가 길어졌네.
아무튼, 저 두 프로그램들은 아래아한글에 밀려 역사 속으로 사라졌다. 그로부터 20여 년 뒤, 도스가 아닌 Windows 얘기이긴 하지만 지난 2014년 가을엔 삼성조차 1992년 이래로 개발돼 왔던 훈민정음을 완전히 포기하고 MS 워드로 복귀를 선언했다. 훈민정음은 처음부터 Windows용으로 개발됐고, 버전 4.5 시절엔 마치 Visual Basic 4처럼 16비트용과 32비트용이 동시에 따로 출시된 탄탄한 제품이기도 했는데 말이다.

훈민정음이 GG를 쳤는데 그럼 아래아한글은? 지금까지 쌓인 인프라가 워낙 많고, 또 아래아한글과 워드는 내부 구조가 서로 너무 다르다 보니 사용자가 하루아침에 전멸하고 쫄딱 망할 것 같지는 않다. 그러나 '갈라파고스화' 알박기 덕분에 겨우 연명하고 있는 비중도 크며, 학교· 군대· 관공서가 아닌 사기업에서 HWP의 입지는 이미 눈에 띄게 줄어들었다는 것을 감안해야 할 것이다. 그리고 결정적으로, 이젠 워드, 엑셀 같은 너무 흔한 필수 프로그램은 그냥 다 공짜로 뿌리는 거나 다름없는 세상이 되기도 했고.
그러니 이스트도 결국은 돈 되는 건 게임이라고 생각하고 진작부터 과감하게 카발을 개발한 것 같다. 이 컴퓨터 소프트웨어 업계가 앞으로 어찌 되려나 참 눈 돌아가겠다.

Windows의 개발 역사에 대해서는 현직 마소 고참 개발자인 레이먼드 챈 아저씨가 The Old New Thing이라는 개인 블로그에서 10년이 넘게 오늘날까지도 구수한 입담으로 그때 그 시절 이야기를 하고 있다. 그것처럼 개인적으로는 아래아한글 1.0부터 현재까지의 역사를 몽땅 꿰뚫고 있는 어떤 개발자가 아래아한글 내지 그 시절 경쟁 워드 프로세서들의 역사를 구구절절 회상하는 코너가 좀 있으면 좋겠다. 필기체가 개발된 사연, 1.2 버전에서 테트리스 게임이 개발된 사연, 한컴 2바이트 코드의 제정 경위, 옛날 공 병우 박사와의 인연 등등 얘기가 엄청 많을 것 같은데..!

Posted by 사무엘

고전 소프트웨어의 추억을 발굴하는 작업은 변함없이 계속된다.
몇 달 전엔 비트맵 그래픽 에디터 얘기를 했다. 구글링으로도 좀체 정보를 발견할 수 없던 Splash와 Image72를 찾아 냈다. 이어서 오늘은 도스용 셸 유틸리티 얘기를 해 보겠다. 출처를 도저히 알 수 없었던 한 외국산 프로그램의 정체를 또 파악하는 데 성공했기 때문이다.
그것은 이름하여 Packard Bell이다.

옛날 도스 시절엔 부팅이 끝나면 화면에 뜨는 건 시꺼먼 화면에 C:\ 프롬프트가 전부였다. 이런 인터페이스로는 초보자건 전문가건 컴퓨터를 제대로 활용하기가 몹시 불편했기 때문에, 컴퓨터에 존재하는 다른 프로그램들을 빠르고 편하게 실행시켜 주는 '셸'에 해당하는 프로그램이 별도로 여럿 만들어지곤 했다.

전문가를 위해서는 MDIR이나 노턴 커맨더처럼 파일 관리 유틸리티를 겸하는 셸이 쓰였다. 이런 프로그램들은 파일 정보만 표시하면 되니 보통 텍스트 모드에서 실행되었다.
그러나 초보자를 위해, 당시의 Windows 3.0에 준하는 GUI를 표방하면서 알록달록한 아이콘이 나오는 그래픽 셸도 있었다. 골치 아픈 단축키를 외울 필요 없이 마우스 클릭만 하면 원하는 프로그램을 실행할 수 있었다.

MS-DOS 버전 4인가 5부터 제공되었던 '도스셸'은 그래픽 모드에서 실행되는 것도 가능했지만 그래도 전자와 후자 중에서는 전자의 성격에 더 가까운 물건이었다. 그래도 GUI의 불모지인 도스에서 나름 마우스 드래그 드롭을 구현했고, 프로그램의 색상과 화면 모드를 다양하게 바꿀 수 있는 게 인상적이었다.

자, 그 와중에 저 '패커드 벨'이라는 프로그램은 우리 집 컴퓨터에 처음부터 있었던 프로그램은 아니고, 친구 집 컴퓨터에서 접했다. 그런데 GUI가 굉장히 고퀄이고 화면이 예뻤다. 16색 VGA에서 실행되는데 투박한 표준 팔레트를 쓴 게 아니라 보다시피 자체적으로 팔레트 색상을 재정의했으니 더욱 이색적인 느낌이 났다. 색상도 그렇고 글꼴도 그렇고, 알록달록한 아이콘까지, 뭔가 프로그래머가 대충 발로 그린 게 아니라 그래픽 전문가의 손길이 닿은 티가 났다. 어린 시절에 본인은 저렇게 "나만의 세계가 느껴지는 비주얼"을 보면 아주 사족을 못 썼다.

저 스크린샷에서는 안 보이지만, 원래는 마우스 드라이버가 있건 없건 마우스 포인터도 나타난다. 그런데 포인터도 운영체제가 그냥 기본으로 주는 작고 투박한 화살표가 아니라, 무려 살색의 사람 손가락 모양이다. 요즘으로 치면 웹 브라우저에서 링크를 가리킬 때 나타나는 그 마우스 포인터와 비슷하다.
화살표 키를 누르면 지금의 마우스 포인터 위치에서 그 화살표 방향으로 가장 가까이 있는 버튼으로 포인터가 이동하는데, 이것도 즉시 되는 게 아니라 부드럽게 궤적을 그리면서 이동한다. 이런 것까지 세심하게 신경을 썼다.

워드 프로세서나 그래픽 에디터가 아니고, 그렇다고 게임도 아니고.. 자체 한글 같은 것도 필요하지 않는 외국산 도스용 유틸리티가 그래픽 모드에서 가변폭 영문 글꼴 출력까지 구현한 것은 그 당시로서는 몹시 드문 일이었다.
도대체 이 프로그램은 누가 언제 어디서 만들었는지 알고 싶어서 뒤늦게 인터넷을 수소문했지만, 정보를 도저히 얻을 수 없었다.

본인은 이 프로그램의 이름이 Pen Bel(l) Desktop인 것으로 기억하고 있었다. 왕년에 베이직 프로그래머였으니 PB라고 하면 파워베이직의 이니셜이 가장 먼저 떠오르지만, 저 추억의 프로그램의 실행 파일에도 PB라는 문자가 포함되어 있긴 했다. 하지만 저 이름으로는 아무것도 검색이 되지 않았다.

이 프로그램에 대한 결정적인 단서를 얻은 곳은 IE is evil!로 유명한 이 사람의 GUI 갤러리 웹사이트였다.
도스는 말할 것도 없고 Windows 3.1 시절까지만 해도 기존의 허접 구닥다리 '프로그램 관리자'를 대체하는 싸제 셸 유틸이 수요가 있었다. 노턴 데스크톱, 그리고 MS의 흑역사 Bob 같은 프로그램들이 있는데.. 어? Packard Bell 내비게이터라는 프로그램이 있었다.

3.5 버전은 완전히 Bob처럼 그래픽 기반으로 바뀌었지만, 1.1은 보아하니 도스용과 완전히 같지는 않아도 색상과 외형이 웬지 도스용 프로그램과 관계가 있는 것 같다는 생각이 들었다.

튜토리얼, Support, your software처럼 큰 메뉴 구성이 꽤 비슷해 보이는 데다 자음 이니셜이 일치하기도 하니 동일 회사의 프로그램일 거라는 감이 강하게 들었다. 그래서 이 키워드로 구글링을 계속했다.. 그러나 일단 '패커드 벨'은 컴퓨터 제조 회사인지라 걸려 나오는 것은 온통 컴퓨터 사진밖에 없었다.

그랬는데 어느 국내 블로그에서 드디어 월척을 낚는 데 성공했다. 내가 찾던 바로 그 프로그램의 스크린샷이 나온 것이다. 프로그램과 개발사 이름이 동일하게 '패커드 벨'인 듯하다.
이 회사는 소프트웨어가 아닌 하드웨어가 주력 상품이고, 프로그램은 자기 컴퓨터에 번들로 설치되는 것 위주로만 개발한 듯하다. 소프트웨어만 전문으로 만든 게 아닌데도 1991년경에 도스와 Windows용 셸을 모두 그것도 상당히 뛰어난 퀄리티로 만든 것이 무척 대단하게 느껴진다.

그래서 이 도스용 '패커드 벨' 셸은 메뉴 구조가 좀 특이했다. ESC를 누르면 도스셸이나 '로터스 웍스' 같은 붙박이 고정 프로그램이 있고, 'Your software'을 골라야만 아까와 같은 프로그램 아이콘 리스트가 나타났다. 패커드 벨 컴퓨터에는 원래 '로터스 웍스'도 번들로 제공되었던 듯하다.

새로운 프로그램을 등록하는 화면이다. 아이템에 사용할 '아이콘', 밑에 표시할 텍스트, 그리고 실제로 실행할 프로그램 이렇게 세 가지 정보를 서로 다른 화면에서 지정해 줄 수 있다. 아이콘은 저 35종류의 기성 그림 중 하나만 선택할 수 있고 다른 외부 그림 파일을 사용할 수는 없다는 게 특이하고 한편으로는 아쉬운 점이다. 기성 그림들은 각각 어떤 컨셉으로 만든 건지는 잘 모르겠다.

그리고 저 스크린샷에서는 제대로 나타나지 않았지만, 원래 이 프로그램은 하드디스크에 존재하는 모든 실행 파일들을 아래의 리스트에다가 표시해 준다. 그래서 사용자는 일반적인 파일 열기 대화상자를 다룰 때처럼 매번 디렉터리를 오갈 필요 없이 한 목록에서 실행 파일을 곧장 선택할 수 있었다. 이건 사실 MS 도스 셸에도 있던 기능이다. 2~30여 년 전, 한 하드디스크가 크기가 수십~100수십 MB밖에 하지 않던 시절에나 가능했던 일이다.

지금 다시 저 프로그램을 접할 수 있다면 무척 감회가 새롭고 흥미진진할 것 같다.

도스 셸 하니까 생각나는데, 옛날에 MS-DOS 4.0은 우리가 아는 그 4.0만 있는 게 아니라 '멀티태스킹 에디션'이라고 유럽 쪽에서 주로 쓰인 다른 브랜치가 있었다고 한다. 16비트 Windows가 사용하던 New Executable 포맷도 사실은 이때 처음으로 제정되었다고 하고.

또한, 국내에서 개발된 그래픽 위주 도스 셸로는 먼 옛날(1993년쯤) 이 종하 씨가 개발한 '능금'이라는 프로그램도 있었다. 옛날에는 '파란연필'이라는 텍스트 에디터도 개발했던 분인데 본인은 요것들은 옛날 컴퓨터에서 다 직접 써 봤다.
'능금'은 셰어웨어였으며, 비등록 공개판은 등록할 수 있는 그룹과 프로그램 개수에 제한이 걸려 있었다.

그래픽 셸로서 '능금'이 지닌 가장 독특한 점은.. 한 아이템에 대한 아이콘을 최대 5개까지 연달아 지정해서 초보적인 수준의 '움짤'을 만들 수가 있다는 점이었다. 물론 외부 파일 사용 가능함. 저 스크린샷을 보면 '그래픽'의 경우 물결이 출렁거렸고, '게임'은 테트리스 블록이 내려가는 모습이 반복되곤 했다.
그래도 '능금'의 기본 팔레트 화면과 저 아이콘들은 '패커드 벨'에 비하면 좀 아마추어 같은 느낌이 들긴 한다. ^^

Posted by 사무엘

컴퓨터로 뭔가 input을 받아들여서 output을 내는 나만의 프로그램을 개발한다면, 그 결과물이 단순히 화면으로만 잠깐 나타났다가 사라지는 걸 원하지는 않을 것이다. 꼭 프린터로 출력까지는 아니더라도 파일로 저장하여 사용자의 컴퓨터에 (반)영구적으로 남는 정도는 가능해야 할 것이다.

일반적인 텍스트/그림 파일뿐만이 아니라 내 프로그램만이 인식할 수 있는 고유한 파일 포맷을 제정하고, 그 포맷이 널리 쓰이게 되는 것은 분명 해당 파일 포맷을 만든 사람에게는 기분 좋은 일일 것이다. 새로운 이미지 파일 포맷이라든가 압축 파일 포맷처럼 말이다. 본인의 경우는 <날개셋> 한글 입력기의 글쇠배열/입력 설정 파일이 이런 창조물의 범주에 속하게 됐다.

파일 포맷이라는 건 지금 당장 공간 낭비 없이 읽고 쓰기 빠르게 만드는 효율도 중요하지만, 범용성과 확장성도 대단히 중요하다. 지금 만들고 있는 프로그램이 구조와 기능이 앞으로 어떻게 바뀔지 알 수 없기 때문이다. 마치 프로그래밍 언어가 하드웨어 친화와 사용자 친화라는 양 이념 사이의 tradeoff로 떨어지듯, 파일 포맷도 위의 두 이념 사이의 tradeoff를 고려하여 제정된다.

또한 파일 포맷은 거의 필수적으로 앞부분에 헤더가 들어간다. 이 파일이 요런 파일 포맷으로 된 파일이라는 것을 나타내며, 헤더가 일치하지 않으면 파일을 더 읽지 말고 에러를 출력하라는 일종의 배려이다. 헤더의 앞에는 식별자가 있는데, 요것이 또 파일 포맷마다 아주 개성이 넘쳤다. 도스 실행 파일(EXE)은 MZ, ZIP 압축 파일은 PK 등.

도스에서 파일의 내용을 보여주는 type 명령은 end-of-file을 나타내는 아스키 문자인 0x1A를 만나면 뒷부분에 텍스트가 더 있어도 표시를 멈췄기 때문에, 파일 시그니처의 끝에다가도 저 문자를 넣어 주는 게 일종의 센스쟁이 관행이었다. 딱 HWP Document File v3.0 요까지만 출력하고 멈추게 할 수 있으니까 말이다. 0x1A는 10진수로 26인데, 이것이 바로 지금도 copy con 다음에 종결을 위해 입력하는 Ctrl+Z와 대응한다. Z는 알파벳 26째 마지막 문자이니까 말이다.

PNG 그래픽 파일은 이 시그니처를 상당히 머리를 써서 만든 것으로 잘 알려져 있다. 마냥 텍스트 파일로 오인하지 않게 의도적으로 맨 앞은 0x89라고 128보다 큰 문자를 집어넣고, 그 다음 PNG를 찍고 줄 바꿈 문자를 찍은 뒤 0x1A로 종결시킨다.

옛날에 아래아한글이 도스용으로 1~2.x 버전이던 시절엔 이런 미래 확장 가능성을 꼼꼼히 설계를 안 했는지 파일 포맷이 수시로 바뀌어서 하위 호환성이 깨지곤 했다. 뭐, 2.1 때는 최초로 압축 저장 기능이 생겼고 도중에 암호 체계가 뚫리는 해프닝이 있어서 불가피하게 포맷이 바뀌어야 하기도 했지만 말이다.
그나마 3.0 포맷이 도스와 Windows 공용으로 무려 97 버전까지 변경 없이 잘 쓰이다가 그래도 지금은 무려 워디안 이래로 포맷이 바뀌지 않고 꿋꿋이 잘 나가고 있다. 안정화가 됐다.

그런 최소한의 융통성을 갖춘 파일 포맷을 만들려면, 결국 어떤 용도의 포맷을 만들든지간에 버전 정보를 남기고 섹션, 구획(혹은 chunk)을 설정하는 정도의 추상화는 공통으로 필요하다. 내가 아는 chunk의 정보만 읽어들이고 모르는 건 무시할 수 있게, 하위 호환이 되게 말이다. PE라고 불리는 Windows용 실행 파일에서도 이런 구획이 있고(text, rdata, data, rsrc 등), TTF 폰트 파일에도 내부에 구획이 있다(cmap, glyf, head 등). 미디(mid) 음악 파일도 온갖 구획들이 합쳐진 컨테이너 포맷이다.

그렇게 외부에서 구획을 표현하는 방식은 파일 알멩이 포맷 이전에 껍데기 '컨테이너' 포맷이라는 공통 규격으로 바뀌는 게 요즘 추세이다. 매 프로그램마다 GUI 프로그래밍을 제각각 할 필요가 없듯, 껍데기를 일일이 새로 만들 필요는 없으니 말이다. 무손실 압축 파일 포맷도 컨테이너와 압축 알고리즘을 분리해서 생각하는 건 상식 중의 상식이고, 손실 압축 알고리즘의 각축장인 동영상/소리 파일 포맷도 컨테이너와 내부 컨텐츠 포맷은 계층이 분리돼 있다.

컨테이너는 아예 human-readable한 텍스트 방식과, 그것보다는 성능을 더 중요시한 바이너리 방식 둘로 나뉜다.
텍스트는 xml이 대세를 평정하는가 싶었는데 요즘은 json도 급부상하고 있다. json은 프로그래밍 언어에서 배열이나 튜플 같은 복합 자료형을 표기하는 방식을 그대로 가져왔다는 점이 무척 참신하다. 배열스러운 나열과 key-value 형태의 데이터를 모두 표기할 수 있으며, 그 덕분에 바이너리 덤프 같은 것도 xml보다는 덜 부담스럽게 집어넣을 수 있고 공간 효율도 더 좋다.

바이너리 차원에서의 컨테이너 포맷으로 요즘 굉장히 많이 쓰이는 건 zip 압축 포맷이다. 수많은 압축 알고리즘들이 존재하지만 역시 오픈소스 앞에서는 답이 없다. zip이 세상을 평정했다. 가장 친숙하게는 MS Office 2007 이후의 문서 파일 포맷, 그리고 오픈오피스 문서 파일 포맷이 내부적으로는 zip 압축 파일이다. Java의 jar 라이브러리, 그리고 안드로이드 adb 패키지도 zip이다.

다만, 저런 프로그램들은 zip 안에다가 자기 방식으로 고유한 메타데이터도 집어넣곤 한다. 그렇기 때문에 이들 파일의 압축을 풀었다가 다시 압축을 했다고 해서 그것들이 해당 오피스 문서나 패키지로 인식되지는 않는 경우가 많다.

멀티미디어 파일 포맷 중에는 avi/wav가 동일하게 RIFF(리소스 교환 파일 포맷)라는 컨테이너 기반이다.
한편 Windows 세계에서는 의외로 많이 쓰이는 공용 바이너리 컨테이너 포맷이 있는데.. 그것은 바로 OLE Compound Binary이다. 이름에서 알 수 있듯이 바이너리 규격에서 여러 프로그래밍 규격들의 통일을 시도했던 OLE/COM 기술과 역사를 같이하는 포맷인 것 같다. 난 잘 모르겠지만 아마 이 파일을 읽고 쓰는 I*** 하는 인터페이스 API도 있으리라 여겨진다.

이 방식의 파일은 D0 CF 11 E0 A1 B1 1A E1이라는 8바이트짜리 시그니처로 시작한다. 의도적으로 128 이하의 텍스트나 제어 문자는 제외한 듯하다. 그리고 앞부분엔 0xFF 문자가 수십~수백 개 나온다.
MS Office가 2007 버전이 등장하기 전에 재래식 doc/xls/ppt가 이 컨테이너 하에서 자기 데이터를 저장하곤 했다. 그리고 지금도 일반적으로는 xml+zip 기반의 docx/xlsx/pptx이지만 암호를 걸어서 저장하면 여전히 예전처럼 이 compound binary를 사용한다. 이건 그리 널리 알려져 있지 않을 것이다.

엑셀의 경우 대용량의 데이터를 빠르게 저장하기 위해 예외적으로 xml 대신 바이너리 포맷을 쓰는 xlsb도 지원하긴 하는데, 이때에도 컨테이너는 여전히 zip이다.
하지만 암호를 걸면 xls든 xlsb든 동일하게 컨테이너가 저 OLECB 방식으로 회귀한다.

OLECB는 Office 문서에서만 쓰이는 게 아닌 범용적인 컨테이너 포맷이기 때문에 Windows의 내부에서는 thumbs.db에서도 쓰이고 심지어 msi 패키지도 이 방식으로 만들어져 있다.
국내에서는 아래아한글이 워디안 이후 새로운 hwp 포맷이 이 컨테이너를 사용하는 중이다. 몇 년 전에 hwp 파일의 포맷이 부분적으로나마 공개되면서 요 방식도 같이 주목받은 편이었다. 워디안의 개발 당시에 OLECB를 사용하기로 한 것은 21세기에 아래아한글의 향후 행로를 결정한 매우 중대한 결정이었을 것이다.

파일 포맷이란 건 한번 정해지고 그게 대중화돼 버린 뒤에는 마치 전기 전압이나 교통수단의 통행 방향처럼 다른 방식으로 덥석 고치기가 거의 불가능하다. 프로그램의 구조가 아주 간단하고 기능 구현만 빨랑 해야 할 때는 숫자/문자열 몇 개를 덥석 텍스트 형태로 덤프하거나, 구조체가 차지하는 메모리 형태를 파일로 통째로 써 버렸을지 모른다. 하지만 그 파일을 남과 주고받게 되고 프로그램을 지속적으로 발전시켜야 한다면 본격적으로 파일 포맷을 고민해야 하는 날이 온다.

이걸 처음에 신중하게 생각을 안 하면 파일 포맷은 legacy들이 가득한 누더기가 돼 가고, 참다못해 파일 포맷을 다 갈아엎게 되고 그러면서 사용자들로부터 욕도 먹을 것이다. 컴터쟁이 프로그래머로서 파일 포맷은 참 재미있는 주제인 것 같다. 그 어떤 파일 포맷이라도 결국은 튜링 기계가 인식할 수 있는 형식 언어와 문법에 속하는 방식으로 귀착된다는 점 역시 생각할 점이고 말이다.

Posted by 사무엘