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

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

본인은 윈도우 플랫폼용 한글 입력기의 개발자이다. 그런데 진짜 옛날 도스 시절, 텍스트 모드가 따로 있던 시절에 한글 입출력 바이오스 같은 건 어떻게 구현했는지가 무진장 궁금해질 때가 있다.
출력은 그렇다 치더라도 입력은 어떻게 구현했을까? 게다가 한글도 모자라서 한자 입력은?
그리고 한글 정도면 양반이지 도스 시절에 일본은 사정이 어땠을까? 한자 변환까지 포함한 일본어 입력이 가능했을까? -_-;;

IBM 호환 PC는 그렇게 그래픽에 최적화돼 있지도 않던 놈이었고.. 영어 아스키 코드밖에 모르는 이런 기계에다가 없는 문자를 찍기 위해서는 막대한 양의 오버헤드가 필요했다.

요즘은 잘 알다시피 사운드 카드, 랜 카드 따위는 마더보드에 통합되어 버린 지가 오래이고 GPU, PPU 같은 거나 별도로 부착하는 CPU 애드온이다. (그리고 이마저도 요즘은 본격 통합 기세-_-)
허나 한 25~30년 전에는 한글 카드라는 별도의 하드웨어가 있을 정도였다. '한글 도깨비'. 그때는 그만큼 컴퓨터의 성능이 열악했다.

한글 입출력 바이오스를 만들려면, 일단 바이오스의 글꼴을 다른 걸로 대체할 수 있을 정도로 하드웨어에 정통해야 했고 메모리 사용량이든 계산량이든 극도의 최적화 작업이 필수였다. 한글 모드에서는 텍스트의 스크롤 속도가 한 2, 30% 정도 감소하는 효과가 있었기 때문. -_-;; 더구나 기본 메모리 640KB는 그야말로 1K라도 아껴야 하는 귀중한 영역이기 때문에, 한자 글꼴 같은 건 XMS/EMS 같은 확장 메모리에다 저장하는 테크닉도 필수였다.

VGA의 기본 텍스트 모드는 잘 알다시피 가로 80글자, 세로 25글자이다. 그런데 아주 신기하게도 한 글자의 크기는 너무나 컴퓨터스럽게 잘 떨어지는 8*16이 아니라, 9*16이다. 그리고 화면 해상도는 640*400도, 640*480도 아니요 720*400이다. 정작 mode 12H 같은 그래픽 모드 중에는 640을 넘는 해상도가 없던 시절이었는데 왜 텍스트 모드만 한 글자의 폭이 8이 아닌 9였는지는 모르겠다.
한글 바이오스들은 16*16 크기의 한글· 한자 글꼴을 사용했으며 640*400 해상도의 텍스트 모드에서 동작했다.

그뿐만이 아니다. 그때 VGA 텍스트 모드에는 화면 전체의 테두리 색이라는 게 있었다! 베이직에서 COLOR문은 보통 글자색과 배경색을 의미하는 A,B만이 쓰이는데, 셋째 인자도 있어서 이걸 지정하면 화면의 테두리에도 색깔을 줄 수 있었다. 이런 기능을 누가 썼고 왜 만들었는지는 모르겠지만...
이건 DosBOX나 VMware 같은 에뮬레이터들도 지원 안 하고 있는 기능이다.
그 테두리가 차지하는 픽셀 수는 얼마나 됐을까? 이것까지 감안한 화면 해상도는 얼마였을지를 생각하면 옛날에 비디오와 관련된 하드웨어 제어는 심오함 그 자체였겠다는 생각이 든다.

텍스트 모드의 바이오스 글꼴을 다루는 테크닉을 구사한 프로그램은 흔치 않았다. 도스용 노턴 유틸리티(Norton Utility)는 이걸 환상적으로 조작해서 텍스트 모드에서 준 GUI 수준의 비주얼을 만들고 심지어 그래픽 모양의 마우스 포인터까지 구현하는 용자짓을 했다. 그리고 Screen Thief라는 캡처 프로그램은 당시로서는 흔치 않게 텍스트 모드를 색깔과 바이오스 글꼴까지 감안한 실제 그래픽 화면 픽셀 그대로 캡처하는 기능이 있었다.
뭐, 한글 바이오스가 구동된 상태에서 노턴 유틸리티 같은 프로그램을 GUI 모드로 동시에 실행했다간 '영 좋지 않은 곳에 하드웨어 접근이 일어나서' 대략 불상사가 발생했겠지만 말이다. "내 컴이 다운이라니!!"

그때는 마우스의 존재 여부를 알아오는 테크닉만큼이나 한글 바이오스의 존재 여부를 알아오는 테크닉도 있었고
이는 텍스트 모드에서 실행되는 프로그램이 선문자를 깨지지 않고 맞게 출력하기 위해서 필수였다. 도스용 V3이나 MDIR 같은 프로그램들 말이다.
그러고 보니 한글 모드에서는 아스키 번호 1~31번 제어 문자도 원래 얼굴 모양 등 각종 도형이던 게, 1바이트 선문자로 바뀌었던 것 같다.

당연한 말이지만, 한글 바이오스는 바이오스의 글자 크기가 8*16이기만 하면, 텍스트가 아닌 그래픽 모드에서도 물론 동작했다.
하지만 그래픽 모드에서까지 텍스트를 찍는 프로그램은 전혀에 가깝게 없을 테니 이건 그리 의미는 없는 기능이었다.
그래픽 모드에서 동작하던 프로그램이 crash가 발생하는 바람에 그 상태 그대로 도스로 빠져나가서 도스 프롬프트가 찍힌 게 아닌 이상 말이다.
텍스트 모드에서는 cursor가 아주 빠르게 깜빡거렸지만 그래픽 모드에서는 cursor가 깜빡이지 않는다는 중요한 차이가 있었다.

그럼, 말이 나온 김에 옛날에 접했던 도스용 한글 바이오스들을 추억 차원에서 몇 개 예나 좀 들어 보자.

1. 본인이 난생 처음으로 접했던 IBM 호환 PC는 대우 전자에 개발한 286 AT였는데, config.sys의 DEVICE 문을 통해 구동하는 자체(대우에서) 개발 소프트웨어 기반 한글 바이오스가 들어있었다. 즉, 일단 load된 후엔 메모리에서 제거하는 방법이 없어서 불편했다. (그 당시 sys 파일은 com 실행 파일과 기술적으로 비슷한 구조가 아니었겠나 싶다.)
Alt+한영을 누르면 한글 바이오스 메뉴가 떠서 영문 전용/조합형/완성형 같은 모드를 바꿀 수 있었고, Alt+한자를 누르면 일시적으로 영문 전용 모드로 전환할 수 있었다.
대우 전자에서 개발한 만큼, 조합형과 완성형뿐만이 아니라 당시 악명 높던 DH 완성형도 지원했는데, 얘는 알파벳 소문자+대문자를 묶어서 한글을 표현하는 경우도 있었던 걸로 기억한다. 물론 한글 코드의 표준화가 일단락되면서 깔끔하게 묻혀서 역사 속으로 사라졌지만.

텍스트 + 한글 모드일 때는 화면의 맨 아래에 자그마하게 현재 한글/영문 모드인지, 완성형인지 조합형인지 같은 상태가 파란 배경의 줄에다 떴다. (그래픽 모드일 때는 그런 거 없음) 텍스트 모드에서 그런 걸 어떻게 구현했는지 지금 생각하면 정말 신기하기 그지없다.
물론 아까 말했던 VGA 테두리도 그보다 더 아래에 표시되었다.

한글을 입력하다가 bksp를 누르면 그냥 바이트 단위로 지워졌다. 즉, '한'을 입력하다가 bksp를 누르면 '하'가 되는 게 아니라 그대로 조합이 끝나면서 KS 완성형 기준 '한'을 구성하는 %C7%D1 중 %C7만 남아서 깨진 문자가 보였다.
우연히 한글 초성만 입력해 놓고 한자 키를 누르니까 지금까지 듣도 보도 못한 온갖 특수문자들이 펼쳐져서 이것도 신비로움 그 자체였다.

2. 한글 MS-DOS를 판매한 MS도 응당 자체 한글 바이오스를 갖추고 있었다.
그런데 지금까지 생각해도 참 대단한 건, MS에서 만든 한글 제품은 텍스트 모드에서도 깨진 문자를 보여주는 법이 없었다.
조합 중인 문자든 조합이 끝난 문자든, 한글은 알아서 자동으로 2바이트씩 한꺼번에 지워졌다. 조합 중인 글자를 조합의 역순으로 차곡차곡 '한' -> '하' 식으로 지워 주기에는 도스 환경이 너무 열악했고, MS가 개발한 한글 바이오스는 그냥 한글을 한꺼번에 지웠다.

GWBASIC, QBASIC 같은 프로그램은 한글판이 따로 있었는데, 한글 바이오스를 구동하지 않고 한글판 프로그램을 실행하면 글자만 깨지는 게 아니라 그대로 컴퓨터가 다운됐었다!
그러나 텍스트 모드에서 GUI를 구현한 한글판 프로그램들을 잘 살펴보면, 메뉴 같은 게 배경에 있는 한글의 2바이트를 반으로 가르게 될 경우 나머지 1바이트도 알아서 지워서 표시해 줬다. 어떤 경우에도 깨진 한글의 잔해 바이트가 표시되는 일이 없었다.

아마 한글 바이오스뿐만이 아니라 응용 프로그램 차원에서 무슨 특수한 처리를 한 것 같긴 한데, 그 대신 당시 MS에서 만든 한글판 프로그램들은 한글 바이오스가 없으면 동작하지 않고, 속도도 느리고 이래저래 파워 사용자들에게서 욕 많이 먹었다. 특히 QuickBasic 한글판은 라이브러리 파일이 영문판과 호환되지 않는 등 최악의 제품이었다.

<날개셋> 한글 입력기는 현재 '마소바탕'이라고 하여 MS 한글 바이오스가 내장한 조합형 글꼴을 그대로 지원하고 있다. 조합 구조가 전통적인 8*4*4벌 도깨비 글꼴과는 다른데 이런 것까지 복원해 냈다.

3. 끝으로 태백한글이라는 프로그램이 있었다. 1994~95년까지 32비트 코드로까지 비교적 오래 개발되었고, 도깨비 글꼴을 그대로 지원한다는 점이 무척 좋았다. 얘는 아마 조합 중인 한글을 음소 단위로 지우는 기능이 있었지 싶다.

도스도 모자라서 영문 윈도우 3.x에서 한글을 구현해 냈다는 한메한글 같은 프로그램은 운영체제의 무슨 계층에서 훅킹을 해서 도대체 어떻게 만든 걸까? 파워 사용자 중에는 영문 윈도우+한메한글이 오히려 한글 윈도우보다 더 안정적이고 좋았다는 말을 할 정도였으니 말이다.
32비트 시대가 도래하기 전에 한글 IME는 DLL이 아닌 EXE이긴 했는데, 그때는 구체적으로 어떤 메카니즘을 썼는지 잘 모르겠다. 물론 그 시절에는 한 프로세스가 시스템 전체에 어떤 영향을 끼치기가 지금보다 훨씬 더 쉬웠을 테니까 그 원리가 그렇게 복잡하고 어려운 건 없었을 것이다.

이것저것 잡설이 길어졌는데, 추억에 공감하시는 분이 있다면 용자.

한글 윈도우 3.1은 실행 전에 언제나 아래와 같은 경고문이 떴었다.
보다시피 MS는 분명히 Hangeul이라는 명칭을 썼었다. 허나 지금 대세는 Hangul이 압도적으로 굳어져 버린 듯. <날개셋> 한글 입력기도 6.0부터는 표기를 Hangul로 바꿨다.

Warning: For correct execution of DOS Box in Hangeul Windows 3.1,
You should use Hangeul Windows 3.1 standard HBIOS.

Warning: Your DOS is not compatible with Hangeul MS-DOS. You may have
some problems when you use Hangeul Windows 3.1.

Press any key to continue...

Posted by 사무엘

오늘날, 어떤 데이터(개념상 Document라고 불리는)를 메모리에 완전히 읽어들여서 사용자가 그 데이터를 편집할 수 있는 업무용 프로그램에는... 거의 필수로 undo 기능이 있다.
이건 우리가 잘 실감을 못 해서 그렇지 사용자에게 심리적으로 굉장한 안정감을 주는 편리한 기능이다. 뭘 잘못해서 망쳐 놓더라도, '미리 저장 -> 지금 문서를 저장 안 하고 예전 문서를 다시 불러오기' 같은 뻘짓을 안 해도 Ctrl+Z만 누르면 만사 OK.

소프트웨어 GUI 가이드라인 교과서를 보면, 소프트웨어는 사용자에게 '용서'(forgiveness)라는 덕목을 발휘해야 한다는 말이 나온다. 사용자가 아무리 바보짓을 하더라도 이를 최대한 추스리고 수습하고 원상복귀 할 수 있어야 한다는 뜻.
컴퓨터 프로그램은 기독교의 하나님 같은 존재가 아니다. “자유 의지가 있으니, 하늘나라든 지옥이든 선택에 따른 책임도 전적으로 네 몫이다” 주의가 아니다. 그러니 인간의 삶에도 Undo가 있으면 참 좋을 텐데 현실은 그렇지 못하니 참으로 안습이다. 오히려 '말은 하고 못 줍는다', '엎질러진 물', '소 잃고 외양간 고친다' 같은 냉정한 속담만이 있을 뿐이다.

잡설이 길어졌다만,
역사적으로 Undo라는 개념이 허접하게나마 가장 일찍부터 존재한 분야는 그래픽 프로그램이었다.
걔네들은 원래부터 문화가 좀 독특해서 마우스의 비중이 매우 높으며, 우클릭이 Context menu의 의미로 쓰이지도 않을 정도이다.
그리고 근본적으로 마우스라는 게 키보드보다 실수를 훨씬 더 하기 쉬운 입력 장비이고, 한 번의 동작으로 수백· 수천 개의 픽셀이 한꺼번이 바뀔 수 있기 때문에 Undo가 없으면 안 된다.

문득 든 생각: 그래픽 프로그램을 이용해서 마우스로 Freehand drawing을 하는 도중에 bksp 키를 누르면.. 직전의 수 픽셀 단위로 곡선을 철회하는 기능이 있으면 좋을 것 같다. 정교한 도트 노가다 할 때 유용할 것 같다. 보통 Ctrl+Z 누르면 그렸던 선 전체가 한 방에 날아가 버리잖아?

물론 Undo라는 건 그렇게 쉽게 구현할 수 있는 기능이 아니며 메모리 오버헤드가 크다.
더구나, 과거에 Undo 기능이 있던 프로그램은 딱 한 단계밖에 취소가 되지 않았었다. Ctrl+Z를 누르면 직전 작업을 취소했다가, 다시 살렸다가 하기만을 반복할 뿐이었다. (메모장.. 정확히 말하면 윈도우 운영체제의 에디트 컨트롤도 딱 그 수준의 1단계 Undo를 지원한다.)
수십, 수백 단계의 작업을 고스란히 취소하고 취소 내역을 다시 철회(redo)까지 하는 command history 수준의 multi-level undo 기능은 1990년대까지만 해도 MS 워드 같은 소수의 상업용 대형 프로그램에서나 볼 수 있었다.

이런 프로그램은 Document의 내용을 변형하는 모든 명령들이 체계적으로 분류가 돼 있다. 그래서 편집 메뉴를 열어 보면 단순히 '실행 취소 / 재실행'이라고만 돼 있는 게 아니라 '삭제 취소 / 취소된 자동 완성 재실행'처럼, 무슨 명령이 직전에 취소되었고 무엇을 재실행할지 명령의 이름까지 메뉴에 친절하게 표시돼 있기도 한다.
그 반면, Undo/redo를 염두에 두지 않고 Document를 고치는 코드가 제멋대로 섞여 있던 프로그램에다가 어느덧 갑자기 multi-level Undo/redo 기능을 최초로 추가할 일이 생겼다면 아마 십중팔구 코드를 다 갈아엎는 대공사를 해야 할 것이다.

컴퓨터의 성능이 열악하던 도스 시절엔, Undo와 Redo가 모두 존재하는 프로그램은 매우 드물었다.
아래아한글 1.x는 좀 특이한 경우인데, 줄 끝까지 지우기· 단어 지우기 같은 몇몇 지우기 명령으로 인해 지워진 텍스트만을 1회에 한해 되살리는 Undo 기능이 있었다.
그 후 아래아한글 2.0에서 97은 그 Undo의 단계가 3회로 늘었을 뿐이었다. 내 기억이 맞다면, 이 기능은 최근 3회의 주요 지우기 단축키(메뉴에 등재되지 않은)에 의해 지워졌던 텍스트 중 하나를 골라서 커서가 있는 곳에다 삽입해 주는 기능에 불과했다. 원래 있던 위치에 되돌려 놓는 것도 아니고... -_-

Ctrl+X(오려두기)야 본문이 클립보드에 고스란히 들어가 있으니 별도의 Undo 버퍼에다 저장할 필요가 없고,
Ctrl+E(지우기)로 지워진 텍스트는 의도적으로 되살리기가 전혀 되지 않는다고 도움말에 친절하게 안내까지 돼 있었다. ^^;;
그것 말고 문서나 표 레이아웃을 잘못 건드려서 망쳤다거나 하는 더 중요한 기능에 Undo 따위는.. “Undo 뭥미? 그거 먹는겅미? 우걱우걱...”이었다. 그냥 이전 문서를 새로 불러오는 수밖에..
이런 불편한 프로그램을 옛날 사람들은 어떻게 쓰고 지냈을까?

그래서 아래아한글 2002는 256단계 undo가 지원된다고 잔뜩 광고를 하고 다녔었다. MS 제품들은 진작부터 지원한 기능인데도 말이다. 하긴, 그것 말고도 글자 크기 제한이 드디어 없어지고 글자색 제한이 없어진 것도 개인적으로 무척 마음에 들긴 했다. better late than never이다.

<날개셋> 한글 입력기의 편집기 프로그램은 1.x와 2.x 시절에는 Undo 비슷한 기능도 전혀 없었다. 3.0에 가서야 32단계의 multi-level undo가 추가되기는 했으나... 글자 하나, 한글 낱자 하나 입력되는 모든 단계가 histroy에 기록된지라 실용성이 시원찮았다.
그것이 지금의 형태로 개선되 것이 4.2 버전부터이다. 연속된 에디팅 동작뿐만이 아니라 불연속적인 에디팅 동작을 한 history로 통합하는 기능까지 추가되어, 여러 블록을 동시에 삭제한 것이나 Replace All 명령을 내린 것도 한 번에 취소가 가능해졌다.

사실 <날개셋> 편집기의 에디팅 엔진은 아직 좀 효율적이지 못한 구석이 있다. Undo/redo 명령을 내리면 그 부분이 아무리 사소하더라도 문서 전체의 레이아웃을 싹 다시 하고, 화면 전체를 새로 그린다. 그렇기 때문에 수~수십 MB짜리 텍스트를 연 뒤에 Ctrl+Z를 꾹 누르고 있기가 겁난다. 본인은 이 프로그램을 만든 사람이고 프로그램의 내부 디테일이 어떤지를 잘 알기 때문에 그러기가 더욱 꺼려진다.

2004년에 만든 3.0 이래로 그냥 brute-force 알고리즘을 그 부분만은 아직까지 최적화를 못 했다. 한글 입력 부분과 직접적인 관계가 없고, 딱히 크게 티가 나는 부분이 아니다 보니 지금까지 방치되어 온 것이다. <날개셋> 한글 입력기 6.0의 다음 버전은 이 부분을 개선하여, 이제 안심하고 Ctrl+Z를 꾹 누를 수 있는 프로그램이 될 것이다.

Undo 기능과 관련된 얘깃거리를 두 가지만 더 꺼내고 글을 맺겠다.

첫째, 예전에 한번 언급한 적이 있듯이, 프로그램들이 Undo는 거의 예외 없이 Ctrl+Z로 정착해 있는 반면 Redo는 단축키가 프로그램마다 일치하지 않는 경우가 있다. MS의 관행은 Ctrl+Y인 듯하지만 Ctrl+Shift+Z인 프로그램도 있다.
아래아한글은 도스 시절에 Ctrl+Y가 지우기 명령의 일종이기 때문에 주의해야 한다. Redo를 생각하고 눌렀다가는 Redo는커녕 텍스트를 지우면서 후폭풍으로 기존 Undo history까지 모두 날려 버리기 때문이다!

둘째, Multi-level undo를 잘 구현한 프로그램이라면, 문서의 modified 플래그 처리도 잘 되어야 한다. 무슨 말이냐 하면, 문서를 저장했다가 어딘가를 건드린 후(= modified 플래그 켜짐), Ctrl+Z를 눌러 그 작업을 철회한다면 문서는 당연히 다시 unmodified 상태로 바뀌어야 한다.
그리고 반대로, 저장한 문서에 대해서 Undo를 해서 modified 상태가 됐더라도, 그걸 다시 Redo로 철회했다면 문서는 unmodified로 되돌아가야 한다. 논리적으로 당연한 얘기이다. <날개셋> 편집기는 multi-level undo가 처음으로 지원되기 시작한 3.0 때 이거 하나는 아주 철저하게 잘 구현해 뒀다.

비주얼 C++ 에디터, 그리고 국산 에디터인 EditPlus는 이 플래그 처리가 잘 된다. MS 오피스 제품도 마찬가지.
그러나 AcroEdit는 이게 되지 않아서 불편하며, 아래아한글도 2007은 처리가 되지 않는다. WordPad 역시 지원 안 함.

Undo나 Redo 같은 Command history 기능은 문서의 modified 상태까지 예전으로 되돌리는 명령이기 때문에 문서를 건드리는(modified 플래그를 언제나 켜는) 동작보다 상위에서 돌아가야 할 텐데, 이 점을 미처 고려를 못 한 것 같다. Undo나 Redo나 문서를 고치는 기능인 건 매한가지이기 때문에 무조건 modified 상태로. ^^

Posted by 사무엘

본인은 IT인에게 필수라는 얼리 어답터 기질이 별로 없다. 옛날엔 있었는데 지금은 사라진 듯.. -_- 1990년대 중반의 인터넷 트렌드를 받아들인 것 역시 굉장히 더뎌서, 개인 홈페이지도 2001년이나 돼서야 개설했을 정도이다. 그 기질이 지금도 고스란히 이어지고 있으니, 일례로 본인이 몇 년쯤 뒤에나 스마트폰을 쓰게 될지 모르겠다. 10년 전이나 지금이나, 걸어다니면서 노트북으로 MP3 듣는 것까지 똑같으니 원.. ㅎㅎ
그 대신, 옛날에 얼리 어답터 기질이 있던 시절에 대한 복고풍 향수병이 좀 있다.

1. 소프트웨어 UI의 문체와 표기

난 20년 가까이 컴퓨터를 사용해 오면서, UI에서 반말, 그것도 단순히 ‘해라’체가 아니라 완전히 구어체 반말 쓴 소프트웨어는 딱 하나 기억난다.
이거 기억하는 사람은 엄청 old timer일 텐데, 고 호석이라는 분이 개발한 <Hot Time>이라는 마작 게임이다. 나중에 VGA 용으로 만든 버전 말고, 무려 허큘리스에서 돌아가던 것.

초딩이던 본인은 마작 같은 건 할 줄도 모르고 관심도 없었다. 그때 할 줄 알았던 건, “돈 놓고 돈 먹기”라고 심심풀이 땅콩으로 제공하던 사다리 도박 게임이었는데, 본인이 사다리 게임이라는 개념 자체를 그때 난생 처음으로 접했었다.
대화상자에서 Yes/No 조차 ‘응(아니면 “그래” 던가?)/아니’라고 적혀 있던 프로그램은 저것 이후로 본인은 전혀 보지 못했다. 요즘은 게임이라 해도 UI는 정중한 합쇼체가 필수인데 말이다.

지금은 작품 이름이나 개발자 이름으로 구글 검색을 해도 관련 정보가 전혀 뜨지 않는.. 그 정도로 묻힌 추억의 옛날 소프트웨어(특히 국산은 더욱 정보가..)가 여럿 있는데 때로는 그런 게 그립다.

MS 사의 제품 중 윈도우는 3.1을 포함해서 95까지 도움말은 ‘하라/해라체’ 반말로 적혀 있었다. 이것도 기억하는 분이라면 old timer임;; 그러다가 IE 4.0이 나올 무렵부터 완전히 존댓말로 바뀌었다. 국가를 막론하고 자기네 회사와 제품 이름은 대외적으로 무조건 영문 원어로만 표기하기로 정책을 확정한 것도 아마 그 무렵일 것이다.

말이 나왔으니 말인데, ‘한글’의 로마자 표기에 대해서 여러분은 어떻게 생각하시는지? 마치 한국 MS도 도스 완전 초창기 시절에는 조합형 코드를 사용한 적이 있었듯이(20년도 더 전, 거의 2~3.x 시절), 그때에 한글 MS 도스가 분명히 Hangeul을 사용한 걸 본인은 봤다. 그 기억이 있고 그게 현행 한글 로마자 표기법에 맞기도 해서 <날개셋> 한글 입력기도 지금까지 그걸 사용해 왔으나...
현실은 Hangul이 훨씬 더 대중적으로 많이 퍼져 있는 것 같다.

2. 90년대의 3D FPS 게임

울펜슈타인 3D와 둠은 1990년대 초· 중반에 ID software에서 차례로 내놓은 전설적이고 선구자적인(특히 PC 환경에서!) 3D FPS 게임이다.
둠이 전작인 울펜슈타인에 비해 기술적으로 월등히 발전했다. 잘 알다시피 고저 차이 표현, 사각형 격자가 아닌 임의의 각도의 평면, 초보적이나마 광원, 천장과 바닥의 텍스처, 오르내리는 지형과 애니메이션 텍스처 등 많다.

그런데 그런 굵직한 것 말고 이런 차이도 있다는 걸 최근에 뒤늦게 발견했다. 아래의 두 그림을 보자.

그 당시의 컴퓨터 성능의 한계상 안티앨리어싱이 안 되어서 텍스처의 점이 다 보이는 건 어쩔 수 없다 치는데, 둠은 가까이서 비스듬히 본 벽면의 텍스처 도트가 원근법에 의해 ‘사다리꼴’ 모양으로 보이는 반면... 울펜슈타인은 어떤 각도에서 보더라도 모든 도트가 무조건 x, y 축에 수직인(orthogonal) 직사각형 형태로 보인다는 걸 알 수 있다. 오호라, 286 AT에서 실시간 3차원 텍스처 렌더링을 구현하기 위해서 이런 꼼수를 부렸다는 것.

그래도 꼼수를 부린 것치고는 비주얼 상으로 의외로 그렇게 큰 티는 안 난다. 계단 현상은 그저 화면과 텍스처의 해상도가 낮아서 그러려니 하면서 은근히 그냥 넘어가게 되기 때문이다.

진짜 100% 폴리곤 3D 세상은 1996년, 둠의 후속작인 퀘이크가 개막하게 된다. true 3D를 구현한 것뿐만이 아니라 로켓과 함께 다이나믹하게 바뀌는 광원도 굉장히 신기했다.
이거 하나의 시스템 요구 사양이 윈도우 95와 비슷했다. 그것도 나름 그 사양에서 돌아가게 만들려고 폴리곤 개수와 맵 크기에서 상당히 절충을 해서 얻은 결과물이다.

둠과 퀘이크 모두, 게임 개발자가 무슨 game mechanics를 표방했는지는 모르겠지만 최고 강한 몬스터는 로켓 런처의 스플래시 데미지에는 반응하지 않는다는 규칙이 있었다. 그래서 둠의 Cyberdemon와 Spider mastermind, 그리고 퀘이크의 Shambler는 로켓 런처로는 유난히도 잘 죽지 않았다.
이게 스타로 치면 유닛의 크기별로 데미지를 받는 등급을 달리하는 소형, 중형, 대형과 진동형, 일반형, 폭발형 같은 개념이라 할 수 있는데... 왜 대형 몬스터가 로켓 런처에 더 강하게 만들었는지는 잘 모르겠다.

3. 옛날 에디터의 단축키

요즘이야 윈도우 운영체제의 영향으로 인해, Shift+화살표는 어디서나 selection, 즉 블록을 잡는 동작으로 통용되고 있다. 아래아한글은 이뿐만이 아니라 도스 시절의 잔재인 F3 블록도 여전히 지원해 주고 있는데, F3 블록을 잡으면 블록 옆에 있는 커서가 여전히 깜빡이고 있고 Shift를 안 눌러도 화살표 키로 계속 블록을 잡을 수 있다는 차이가 존재한다.

그런데 터보 C 2.0의 IDE, 그리고 이 인터페이스의 영향을 받은 과거 도스 시절 PC 통신 에뮬레이터 이야기의 텍스트 에디터는 Ctrl+K,B(시작점), Ctrl+K,K(끝점)이라는 괴악한 방식으로 블록을 만드는 걸 지원했다.

이건 한편으로는 직관적이지 못하고 불편하다. 비슷한 맥락에서, 파일 ‘오려두기’ 동작도 UI 심리상 인간에게 직관적인 느낌을 못 준다고 함. 그러나 커서 위치와 블록의 시작점 내지 끝점이 완전히 따로 놀 수 있으며 시작점만 잡아 놓고 한참 딴짓을 하다가 끝점을 나중에 잡을 수 있다는 특성상, 이 기능은 매크로 같은 걸 만들 때 굉장히 편리할 수 있겠다.
가령, 본문에서 [ ] 로 둘러싸인 문자열만을 몽땅 찾아 지운다고 할 때 저런 식으로 블록을 잡을 수 있다면 매크로로 깔끔하게 해결이 가능하다.

4. 알툴즈

위의 예에 비해서 그렇게 고전 소프트웨어는 아니지만.
본인, 지인에게 한 몇백 MB짜리 ZIP 압축 파일을 전해 준 적이 있었다. 그런데 그게 지인 컴퓨터에서는 압축이 풀리지 않았다고 한다.
그러나 파일은 지인의 다른 컴퓨터에서는 압축이 풀렸고.. 나중에 알고 보니 압축이 안 풀린 컴퓨터에 깔린 프로그램은 알집 7이었고 풀린 곳은 WinRAR이던가 아무튼 다른 프로그램이었다. 흠좀무..;;

이래서 알집이 악명 높았나 싶었다.
물론 본인은 지금은 알툴즈 안 쓴다. 하지만 FileZilla로 갈아타기 전에는 수 년 동안 알FTP로--그것도 최신 버전 업데이트를 꼬박꼬박 한 것도 아니고..-- 거의 모든 홈페이지 관리를 해 왔으며, 지금까지 딱히 사고를 겪은 적은 없었다. 그런데 알고 보니 알FTP는 알집보다 더 악명이 높던데..?? -_-

언제부턴가 이런 공짜 압축 프로그램의 등장으로 말미암아, WinZIP이나 WinRAR 따위 안 쓰고, 사용 압축 포맷도 알고리즘이 완전히 공개되어 있는 zip 아니면 7z 정도만 쓰게 된 것 같다. zip은 MS 오피스 문서 파일이라든가 게임 롬 파일 같은 여타 포맷의 컨테이너로도 진짜 널리 대중화하긴 했다. 그보다 좀 더 나은 유료 포맷이 있다고 해도 어차피 거기서 거기이고, 지금이 무슨 PC 통신 시절처럼 1바이트라도 더 깐깐하게 줄여야 하는 시절도 아니니까 말이다.

그나마 ZIP이 옛날에 RAR, ARJ 같은 방식에 비해 큰 약점이 있던 게 플로피 디스크 복사를 위한 분할 압축이 지원되지 않는다는 점이었으나... 요즘은 거의 필요 없는 기능이 됐다. 전혀 필요 없는 잉여 기능은 물론 아니지만..;;

알집 처음으로 구경한 게 10년 전에 4.8 때부터였는데 참 많이 컸다. 새 폴더며, 각종 익살스러운 문구가 많은 게 인상적이긴 했다.

Posted by 사무엘

※ 메신저

상대방에게서 마지막 대화가 도착한 지 n초가 경과하기 전에는 ESC를 눌러도 대화창이 없어지지 않게 하는 옵션이 있으면 좋겠다. (과거 대화 내용을 보관하는 기능이 없을 때에 한해)
상대방에게서 말이 막 도착했는데 그걸 예상 못 보고 창을 확 닫아 버리면 대략 난감하다.

아울러, MSN 메신저는 이모티콘 변환을 좀더 지능적으로 했으면 하는 바람이 있다. 이모티콘 때문에 메신저로 프로그램 코드를 주고받을 때 상당한 애로사항을 경험한 사람들이 적지 않을 것이다. 지금은 안 그런데 옛날에는 심지어 (?) 조차도 이모티콘으로 바꾸는 어처구니없는 일이 있었다.
이모티콘 변환은 내가 직접 타이핑하는 문자열에 대해서만 적용하고, 복붙한 텍스트에 대해서는 안 하기만 해도 불편이 상당수 해결될 텐데..

※ 텔넷 클라이언트

서버로부터 특정 패턴의 문자열을 받았을 때 사용자에게 alarm 하거나, 이런 명령을 보내거나, 로컬 컴퓨터에서 뭘 실행하는... 그런 스크립트 기능이 있었으면 좋겠다.
즉, 패턴으로 현재 쉘의 프롬프트 문자열을 등록해 놓고 긴 빌드 명령을 내리면... (가령 안드로이드 OS 빌드 같은)

나중에 빌드가 다 끝나고 프롬프트가 떴을 때, 서버에서 빌드된 이미지를 곧바로 로컬 컴퓨터로 복사한다거나 하는 사용자 정의 이벤트가 실행되게 할 수 있다. 즉, 서버 컴퓨터와 내 클라이언트 컴퓨터의 연계가 가능해진다. 단순히 login 내지 password 요청이 왔을 때 로그인을 자동으로 해 주는 것 이상으로, 이 정도 수준의 자동화 기능은 PC 통신 프로그램도(이야기의 혼잣말 기능 같은) 제공한 걸로 기억한다. 하지만 PuTTY 같은 프로그램에는 아직 없는 듯.

※ 비주얼 스튜디오 2005

본인이 비주얼 스튜디오 2005를 처음 접했을 때의 인상은 무척 충격적이었다. 드디어 아이콘이 16색을 넘어섰고, 무엇보다도 메뉴와 도구모음줄의 외형이 시퍼런 MS 오피스 2003 스타일을 물려받지 않고 예전 버전(VS 2003 = 오피스 XP)을 변형한 형태로, 즉 자신만의 스타일로 갔기 때문이다.

2005는 컴파일러가 더욱 C++ 표준을 준수하고 여러 가지 면에서 기능이 향상된 게 많아 만족스러웠다. 하지만 같이 설치되는 플랫폼 SDK가 좀 이상해서 기본 설치한 환경에서는 <날개셋> 한글 입력기 빌드에 필요한 일부 운영체제 컴포넌트가 설치되지 않았다. 그리고 이 버전에서 제공된 Spy++은 윈도우 비스타 이상급에서는 이상하게 일부 프로세스가 목록에 나타나지 않고 검색도 되지 않았다.
왜 그런지 모르겠다. 2008은 말할 것도 없고 심지어 구버전인 2003도 그런 문제가 없었는데 말이다.

※ 그리고 기타 전반적으로

비주얼 스튜디오, Source Insight, 이클립스는 모두 유명하고 널리 쓰이는 개발 환경이다.
취소(Ctrl+Z), 열기(Ctrl+O), 복사(Ctrl+C)처럼 모든 응용 프로그램에서 거의 이질감 없이 일치하는 단축키가 있는 반면, 전혀 표준화가 안 돼 있고 응용 프로그램마다 제각각인 단축키도 있어서 굉장히 신경 쓰인다.

가령, Find previous/next match 기능은 본인은 F3/Shift+F3에 아주 익숙한 반면 그렇지 않은 프로그램도 있다. 이는 파일 비교· 병합 프로그램도 마찬가지. 심지어 왼쪽/오른쪽 병합 기능도 WinMerge, 아락시스, Beyond Compare 등 프로그램들이 전부 단축키가 다르다.
Undo와는 달리 Redo는 단축키가 일치하지 않는 경우가 많다는 것 역시 특이점. Ctrl+Y or Ctrl+Shift+Z처럼 말이다. 이건 비단 개발 도구뿐만 아니라 워드 프로세서인 아래아한글과 MS 워드의 대표적인 차이이기도 하다.

다음은 불만 내지 제안 사항은 아니고, 윈도우 운영체제 관련 trivia.

1.
윈도우 95, 98, 2000은 welcome 프로그램이란 게 있었다. 즉, 부팅이 끝난 후 곧장 실행되어, 이 운영체제의 새로운 기능을 소개한다거나 자습서를 꺼낸다거나 하는 가이드 프로그램이다. ME는 없었던 걸로 기억한다.
95의 경우, 아직 Did you know 같은 팁 인터페이스가 유행하던 시절이었고(무려, 비주얼 C++ 6에도 아직 있다!) 3.1에 비해 워낙 breaking change가 많았던지라 새로운 기능 팁 위주였다. 그 반면 98과 2000 버전은 팁은 없고 인터넷 연결과 제품 등록과 관련된 아이템이 있었다.

하긴, 윈도우 비스타는 그와 비슷한 개념으로 ‘시작 센터’를 표시하는 게 있긴 하다. 7은 있나?
윈도우 3.1과 95는 자습서까지 있었다. 비주얼 베이직으로 만든 프로그램이었던 걸로 기억.
98과 2000은 운영체제 도움말이 하드코어 chm 형태인 반면, ME는 hta (HTML Application!) 기반의 좀 인터랙티브한 도움말이 추가됐고, XP는 전무후무하게 아예 플래시 기반 자습서 겸 도움말까지 내장하고 있었다. 영어여서 한글판에서는 정식으로 이를 들려 주지는 않았지만 말이다.

2.
32비트에 이어 개인용 PC에도 64비트 시대가 도래하고 64비트 윈도우는 16비트 바이너리는 지원조차 안 하게 되었지만, 아직도 16비트 코드의 잔재가 고스란히 전해 내려오는 분야가 있다. 바로 fon 글꼴 파일인데(ttf 말고), 이제는 시스템 비트맵 글꼴로밖에 안 쓰이는 이 과거 유물은 여전히 16비트 dll 형태이다. 물론 코드는 전혀 없고 리소스 전용 dll이지만...
이 파일은 이제 실행 파일이 아니라 데이터 파일로 해석된다고 보는 게 더 타당하겠다. System, Fixedsys, Terminal 같은 비트맵 글꼴이 fon 파일 형태로 들어있다. 시스템 기본 글꼴조차 힌팅과 안티앨리어싱이 적용된 윤곽선 글꼴로 나오는 판국에 정말 낡은 유물이 된 셈이다.

Posted by 사무엘

아무리 로딩 시간이 길고 덩치가 큰 프로그램이라 하더라도, 한번 실행했다가 종료한 후 그 프로그램을 즉시 다시 실행하면, 예전보다 훨씬 더 빨리 실행된다. 이때는 사실 디스크 액세스 자체가 거의 일어나지 않는다. 이는 상식적으로 알 수 있듯, 운영체제가 디스크 액세스에 대한 캐싱(cache)을 똑똑하게 잘 해 주기 때문에 그렇다.

컴퓨터 내부는 양극화 내지 80/20 법칙이 잘 통용되는 세계이다. CPU 명령이든 디스크 액세스든, 메모리 액세스든, 병목 현상은 꼭 일어나는 곳에서만 몰아서 집중적으로 일어난다. 한번 액세스된 자료는 다음에 또 액세스될 가능성이 높다. 그리고 그 인근의 자료가 덩달아 액세스될 가능성이 높다. 컴퓨터 아키텍처를 연구하는 사람들의 관심사 중 하나는, 이런 캐시 적중률을 높여서 컴퓨터의 성능을 끌어올리는 것이다.

그러나 지금은 당연시되고 있는 디스크 캐시가 옛날 도스 시절에는 전혀 당연한 개념이 아니었다. 아까 전이나 지금이나 동일한 파일을 읽고 쓰는 시간은 언제나 동일-_-했다. 캐시 프로그램은 별도의 램 상주 유틸리티로 제공되곤 했다. 사실, 그때는 메모리 값이 비싸서 디스크 캐시를 위해 수 MB의 메모리를 떼어 낼 여건이 되는 브루주아 계급 자체가 별로 많지 않았었다. ^^

디스크 캐시 유틸이 하는 일은 대략 다음과 같을 것이다.
1. 파일을 읽을 때 인접한 내용도 미리 읽어 둔다.
2. 한번 읽은 내용은 메모리에 저장해 놓고 나중에 디스크를 액세스하는 일이 없이 써먹는다.
3. 쓰는 것은 지금 몰아서 다 하지 않는다. 쓰기 작업을 다 완료하지 않았지만 일단은 다 했다고 빨리 응답해 주고, 나머지 작업은 CPU가 쉬고 있을 때 조금씩 한다.
그러니, 읽은 내용을 효율적으로 관리하는 것과, delayed writing 때문에 메모리와 디스크의 실제 상태가 일치하지 않을 때 이를 동기화하는 방식 같은 게 캐시 프로그램 개발의 핵심 기술이라 할 수 있다.

물론 읽기 캐시는 그렇다 쳐도, ‘delayed writing’라는 동작 방식은 위험할 수도 있다는 경고도 접했다. 메모리에 있던 캐시 내용이 디스크에 실제로 반영되기 전에 컴퓨터가 꺼져 버린다면? 흠좀무.

MS 도스는 SMARTDRV라는 유틸리티를 제공했으며, 윈도우 9x에도 이놈이 있다. 이 프로그램이 다른 경쟁 프로그램들과 비교했을 때 성능이 어땠는지는 모르겠지만 이 정도만으로도 마법과 같은 프로그램이었다. 하드웨어를 바꾸지 않고도 디스크 체감 액세스 속도가 엄청나게 빨라졌으며, 특히 크기가 작은 다수의 파일을 다룰수록 성능 향상 정도는 폭발적이었다.

심지어는 운영체제 설치하기 전에 smartdrv를 띄워 놔도 설치 시간이 단축되고 효과가 좋다고 명시가 되어 있다. 디스크 캐시는 가상 메모리라는 개념과 맞물려서, 현대 운영체제가 RAM의 속도와 하드디스크의 용량을 적절하게 잘 절충하여 사용자에게 최적의 성능을 제공하는 데 꼭 필요한 개념이 되었다.

윈도우 비스타(와 그 후속 포함)는 예전보다 더욱 과감하게 캐싱을 한다고 한다. 값싸고 풍부한 메모리를 디스크 캐싱용으로 적극 활용한다. 심지어 수십 MB짜리 비주얼 스튜디오 2008도 몇 번 껐다가 켜면 나중에는 디스크를 전혀 액세스하지 않고 실행된다. 마치 램드라이브처럼 말이다. 그러니 빨라졌다는 느낌이 들 수밖에 없다. 캐싱용으로 쓰는 메모리는 운영체제가 점유 중인 메모리 양으로 쳐 주지도 않는다. 사용자가 원하면 언제라도 용도 변경이 가능한 메모리이기 때문이다.

반대로, 램 용량이 부족하면 컴퓨터는 그야말로 지옥이 된다. 캐시 혜택은커녕, 이미 램으로 액세스하던 것도 전부 디스크 상의 스왑 파일로 다루게 되기 때문이다.

그러고 보니 과거에는 네트워크 드라이브도 아니고 아예 램드라이브라는 게 있었다. 비록 용량이 부족하고 저장 효과가 영구적이지도 못하지만, 이것이 광속으로 디스크를 액세스하는 효과를 내는 방법 중 하나이기도 했다. 지금은 그런 게 있으려나?

또 하드디스크를 write-protect하는 유틸리티도 있었다. ㅎㄷㄷ;; 그러나 이 역시 메모리와 디스크가 일체로 가상 메모리를 이루는 오늘날의 운영체제 하에서는 완전히 흑역사가 된 지 오래이고, 그 대신 얼추 비슷한 개념을 사용자 계정 컨트롤이 대신 담당하고 있다. 도스 시절 만세이다. ^^;;

Posted by 사무엘

오늘은 설치 프로그램이라는 주제로 이야기 보따리를 풀어 보겠다.

과거 도스+윈도우 3.1 공존 시절에는
도스용 프로그램들은 어떤 소프트웨어의 설치 프로그램의 이름은 대개 install이었던 반면,
윈도우용 프로그램들은 어찌 된 영문인지 다들 setup이었다.
그리고 그 시절에 윈도우용 설치 프로그램들은 전체 화면으로 파랑-검정 그러데이션이 배경으로 쫙 깔리는 게 유행이었다. 그러면서 화면 좌측 상단엔 큼직한 흰색 글씨로 "무슨무슨 프로그램 설치/Setup"이 떴지. (짤방은 귀찮아서 생략-_-)
이걸 기억한다면 당신은 진정한 old timer.

그러다가 윈도우 95가 보편화하면서 전체 화면 배경은 그냥 옥색(cyan) solid로 바뀌었다.
MS 오피스 97과 아래아한글 97의 설치 프로그램이 그런 모양이었다.

그러나 그때와 지금의 근본적인 차이는.. 이제 설치 프로그램은 더는 전체 화면을 점유하는 형태로 실행되지 않는다는 것이다. 유행이 확 바뀌었다. 그냥 간단한 마법사 대화상자 하나만 달랑 뜨는 형태로 극도로 간소화됐다. 소프트웨어 설치가 무슨 게임 실행도 아니고... 그 정도로 유세 부릴 프로세스는 아니게 되었다는 의미.

MS 제품의 경우 Windows Installer 기술이 최초로 도입된 오피스 2000부터 설치 프로그램 UI가 싹 바뀌었으며, 아래아한글 역시 2002부터는 설치 프로그램이 마법사 대화상자 하나만 달랑 나올 뿐 전체 화면으로 뜨지 않는다.

사실 소프트웨어의 규모가 복잡해지고 한 제품도 온갖 버전 구분이 존재하게 되면서,
제대로 된 설치 프로그램을 만드는 것도 굉장히 골치 아프고 까다로운 일이 돼 있다.
단순히 파일을 복사했다가 지우는 것 이상이다. 예를 좀 들자면,

- 동일 제품의 여러 버전이 공존하고 이들이 다 한데 공유하는 파일이 있는데 이 파일은 언제 제거해야 하나? 그런 거 체크 리스트를 어떤 자료구조로 구축해야 하나?
- 그런 자료구조가 깨졌을 때 최대한 복구는 어떻게 하면 좋을까? 그리고 확장자 연결 복구는?
(사용자는 1.0과 2.0 중 어느 걸 먼저 설치할 수도 있고, 그 후 2.0과 1.0 중 어느 걸 먼저 제거할 수도 있다. 프로그램 설치/제거는 획일화된 스택이나 큐 구조가 아님. ㅋㅋ)
- 지금이 이전에 설치를 진행하다가 중단된 상태였는지 판단은?
- 지금 당장 건드릴 수 없는 파일을 건드려야 돼서 그걸 다음 재부팅 때 하도록 예약해 놓은 게 있나?

글 쓰면서 당장 떠오르는 복잡도만 생각해도 저 정도이다.
특히 재부팅 때 건드릴 파일을 예약하는 기법이나, 지금 실행돼 있는 프로그램 목록을 얻는 방법은.. 설치/제거 프로그램을 만들 때 반드시 필요한 동작임에도 불구하고 과거에 윈도우 9x과 NT 계열이 테크닉이 서로 완전히 달랐다. 유니코드 지원 여부 같은 차이도 존재하고.. 그러니 짜증 두 배.. -_-

예전에도 글을 쓴 적이 있지만, uninstall 프로그램을 만들 때 필요한 것이, 바로 자기 자신을 제거하는 기법이다. 윈도우 운영체제는 그 특성상 실행 중인 EXE/DLL은 운영체제가 memory-mapped file로 대응시켜 잡고 있기 때문에, 자신을 제거할 수 없다.
하지만 배치(일괄 처리 bat) 파일은 DEL 명령으로 자신을 제거할 수 있다. 그래서 EXE를 제거한 뒤 자기 자신을 제거하는 비밀 배치 파일을 만들어 실행하는 기법으로 자신을 제거하곤 한다. 리눅스나 맥은 사정이 어떤지 모르겠다.

이런 저런 사항도 있고, 아무튼 프로그램 설치/제거 및 버전 관리 기법은 어느 소프트웨어에서나 공통적으로 쓰이는 개념/테크닉만 뽑아내서 운영체제 차원에서 책임을 져 준다거나 어느 잘 만들어진 미들웨어를 쓰는 게 효율적이다.
그래서 진작부터 프로그램 설치/제거 솔루션이 나와 있었다. 가장 역사가 긴 녀석은 역시 InstallShield이다. 지금은 비록 위상이 옛날 만하지는 않고 Windows Installer의 단순 wrapper 수준처럼 된 것도 있지만.. 그래도 대형 상업용 소프트웨어에서 이게 여전히 쓰이고 있기도 하다.

InstallWise도 아마 윈도우 3.x 시절부터 건재했던 외산 솔루션이고, 국산 프로그램인 InstallFactory는 <날개셋> 한글 입력기의 2.0~2.4 시절에 잠시 도입된 적이 있다.
DeployMaster라는 제품도 있고, 아.. 그나저나 요즘 전세계적으로 가장 널리 쓰이는 솔루션은 역시 Nullsoft의 NSIS인 것 같다.
소프트웨어의 설치 프로세스라는 건 단순 파일/복사나 버전 체크 같은 아주 공통적이고 범용적인 동작도 있지만, 또 각 소프트웨어가 필요로 하는 customize 수준도 천차만별이라는 특성도 존재한다. 그러니 그런 것도 잘 살려 줘야 하면서도 최대한 배우기 쉽고 구조가 간단해야 한다.

<날개셋> 한글 입력기는 2.5 이후 버전부터 지금까지는 그냥 비주얼 스튜디오가 기본 제공하는 msi 생성 프로젝트를 이용하여 배포 패키지를 만들고 있다. AppLocale 버그(이건 뭐 MS가 만든 프로그램들끼리 충돌하는 문제-_-)도 있고, 다국어 UI도 지원 안 되는 등 좀 마음에 안 드는 면모가 없는 건 아니나, 일단 7년에 가까운 세월 동안 설치/제거 자체가 딱히 큰 트러블 없이 되는 게 검증이 되어 왔기 때문에 쓴다. 민감한 부위인 외부 모듈까지도 말이다.

또한 MSI 런타임 2.0은 윈도우 95/NT4에서도 무난하게 잘 동작한다는 점도 큰 이점이다.
사실 Application Data 같은 일부 known 디렉터리는 IE4 이전의 윈도우 95 초창기에는 없던 개념인데, MSI 런타임 2.0은 설치 과정에서 그런 디렉터리에 대한 정보도 레지스트리에다 넣어 준다. (<날개셋> 한글 입력기의 동작에 필요)

다만, 본인도 InstallShield와 Windows Installer에 대해서 그렇게 좋은 인상을 갖고 있지 않다는 점을 밝히며 글을 맺는다.
99%까지 게이지가 금세 꽉 찬 뒤, 그 뒤로 몇 분째 꼼짝도 안 하는 훼이크성 대화상자에 짜증 게이지가 확 치솟아서이다. ㅆㅂ.. 도대체 설치도 아니고 설치 준비 작업이 뭐 이렇게 오래 걸리나 모르겠다.

개발툴인 비주얼 스튜디오 2005도 2003보다 제품의 완성도는 올라갔다지만, 설치에 관한 한 정말 답이 안 나오는 제품이다.
서비스 팩 1 설치하는 시간이 2005 자체를 첫 설치하는 시간보다 더 길면 길지, 절대로 더 짧지 않다. 도대체 그 시간 동안 뭘 하는지 모르겠다.
거기에다가 윈도우 비스타 내지 7에서 쓰려면 SP1에다가 또 운영체제 패치도 설치해야 한다. 이거 뭐 해처리 → 레어 → 하이브로 올리는 정도의 시간이 걸린다.

비스타/7부터는 그냥 닥치고 2008 이상을 쓰라는 소리. 비주얼 스튜디오 2008이 나오자마자 바로 갈아탔다.
사용자에게 좋은 첫인상을 주는 설치 프로그램을 만드는 것도 중요하다.

Posted by 사무엘

Posted by 사무엘