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

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

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 사무엘

아직도 삼성맨들은 다루고 지내는지 모르겠다만.. 우리나라에는 아래아한글과 MS 워드 다음으로 훈민정음이라는 워드 프로세서가 있다.

아래아한글이 대한민국의 도스용 워드 프로세서 시장을 석권하기 전,
도스 시절엔 보석글, 하나-_-, 신사임당, 심지어 21세기 같은 전설의 프로그램들이 있었다. 이런 건 컴퓨터 old timer라면 다들 기억할 것이다.

허나 Windows로 가면 어떨까? 윈도우용 아래아한글이 출시되기 전인 1990년대 초중반엔 아리랑, 글사랑, 파피루스 등 다양한 윈도우 3.x용 국산 워드 프로세서들이 존재했다. 그리고 삼성 전자에서 개발한 훈민정음도 그 중 하나였다.

아리랑: IT 벤처 핸디소프트에서 개발. 사장이 아마 카이스트 출신이었을 거다.
글사랑: (김사랑이 아님 ㄲㄲㄲ) 글꼴 개발로 유명한 휴먼컴퓨터에서 개발. 문방사우라는 DTP 프로그램을 개발한 기술도 있는 곳이니까..
파피루스: 한메 타자 교사와 한메 한글을 만든 한메소프트에서 개발. 나름 한글 처리 쪽 기술이 있는 업체이다.
훈민정음: 더 이상의 자세한 설명은 생략한다.

“이야, 우리나라에 그런 제품도 있었어요?” / “네, 있었습니다.”
물론 얘네들은 윈도우 95와 윈도우용 아래아한글 3.0의 등장을 전후하여 제대로 망하고 진정한 흑역사로 전락했다.. -_-;; 훈민정음을 제외하면 32비트 버전조차 개발되지 못했지 싶다.

심지어 금성(현 LG) 전자도 '윈워드'라는 워드 프로세서를 내놓은 적이 있다는 걸 아시는가? WinWord.. MS 워드의 실행 파일 이름과 동일하다. 하긴, 동일 회사에서 도스용으로 개발한 '하나 워드 프로세서'는, 학교와 관공서에서 정식 채택된 덕분에, 후진 기능에도 불구하고 1990년대 중반까지 살아남았다만, 윈워드는 정말 흔적도 없이 사라졌다. 특히 경쟁사의 제품인 훈민정음과 비교했을 때 말이다. -_-;;

자, 그럼 훈민정음 워드 프로세서 얘기를 더 하겠다.
얘는 나름 1992년부터 개발돼 왔고, 윈도우용 아래아한글 3.0이 나올 무렵엔 4.0대 버전으로 올라갔다.
본인이 가장 가깝게 접한 버전은 바로 4.5이다.
삼성에서 후원이라도 했는지, 1996년도 PC 경진대회 지역(경상북도) 예선 참가자들에게 훈민정음 패키지가 확장팩(각종 글꼴, 클립아트들)까지 통째로 경품 차원에서 배포되었기 때문이다. 득템~

이때는 잘 알다시피 시기적으로 윈도우 95 과도기였기 때문에 프로그램이 16비트용과 32비트용으로 따로 배포되었다. 기능은 거의 동일하지만 16비트용은 4.5 버전이었고, 32비트용은 95라고 불렸다.
아래아한글은 국내 최초+유일의 Win32s 기반 32비트 프로그램으로 개발되었고 MS Word는 연결 고리 없이 95부터 곧바로 32비트로 넘어가 버렸다면, 훈민정음은 나름 16비트와 32비트를 따로 만든 셈. 한 소스에서 별 잡음 없이 두 에디션을 만들 정도로 프로그램을 잘 짰던가 보다.

여담이지만, MS가 역사상 동일 버전의 제품을 16비트와 32비트로 따로 만든 것은 비주얼 베이직 4가 유일했지 싶다. 이는 이 자리에서 자세한 내역을 다 말하기는 곤란하지만, 비주얼 베이직의 제품 성격의 특이성 때문으로 추정된다. 비주얼 C++은 그냥 32비트용 4.0과 16비트용 1.52를 묶어서 배포했으니 동일 버전 제품은 아니니까 말이다.
또 덧붙이자면, MS는 Win32s를 만들어 놓고는 정작 자신들은 Win32s 기반 프로그램을 (전혀) 만들지 않았었다.
MS에서 개발한 프로그램 중에 MFC 사용하는 건 극소수인 것과 비슷한 맥락. -_-;;

지속적인 버전업이 되지 못하고 곧 망해 버린 여타 마이너 국산 워드 프로세서들과는 달리, 훈민정음은 삼성 기반이라는 탄탄한 돈줄 덕분에, 상업성을 완전히 상실한 후에도 꽤 오래 살아남았다. 들리는 말에 따르면, 이 건희 회장이 훈민정음에 애착을 꽤 두고 있었다고 한다. 당장 돈이 안 되더라도 자기 회사가 한글 처리 기술 및 워드 프로세서 개발 기술은 보유하고 있어야 한다고 특별한 지침을 내리기도 했다는데.

IMF 시절, 아래아한글이 MS에게 잡아먹혀서 ㅈ망할 뻔 했을 때(아래아한글 개발 중단 및 소스 인계-_-를 조건으로 MS로부터 자금 투자), 평소 한컴 및 아래아한글의 행보를 비판해 온 사람들은 차라리 이 기회에 아래아한글이 완전히 망해 버리고 훈민정음이 1인자로 등극했어야 했다고까지 말했다. 하지만 동작 방식이 아래아한글과는 완전히 다른 워드 프로세서에 국민들이 과연 그렇게 쉽게 호응과 적응을 할 수 있었을까? -_-

훈민정음은 1990년대 말까지 정음 오피스, 어린이 훈민정음, 남북 통일 워드 프로세서 등 여러 형태가 존재하다가 지금은 스마트폰 앱으로도 나오고 또 정음 Global 같은 솔루션으로도 명맥이 유지되고 있는 듯하다. 삼성 컴퓨터에 번들로 공급되지만 패키지 소프트웨어로도 아직까지 나오는 것 같다. 워드 프로세서의 핵심 개발 인력이 넥스소프트로 독립해 나가고, 그 중 넥셀은 지금 완전히 한컴으로 넘어갔을 텐데 아직까지 삼성 내부에 개발팀이 있기라도 한가 보다.

Posted by 사무엘

1990년대에 id 소프트웨어는 PC 환경에서 궁극의 최적화 기술을 선보이며, 1인칭 3차원 FPS 장르를 개척한 선두주자였다. 둠(Doom)은 두말 할 나위도 없이 불멸의 명작으로 기록되었고 수많은 매니아· 폐인들을 양산했다. id의 기술력은 그 후에도 Quake 시리즈로 이어지며 발전을 거듭했다. 후속작인 퀘이크는 이 장르에서 스프라이트가 아닌 100% 3D 폴리곤을 실현한 첫 작품이기도 하다.

음침한 던전과 곳곳에서 들려오는 몬스터들의 살벌한 울음 소리. 피떡이 된 몬스터 시체들;;
둠은 잔인성과 폭력성 면에서 논란의 대상이 되었으며, 특히 SF에다가 오각형, 염소 머리 등 지극히 오컬트· 사탄주의-_-를 가미한 세계관은 기독교 진영으로부터도 풍부한 까임거리를 제공했다.
“미국에서 총기 사고를 내고 자살한 어느 비행 청소년은 평소에도 Doom 중독자였으며, 게임을 하듯 사람을 죽이고 싶어했던 것으로 경찰 조사 결과 밝혀졌습니다”처럼. ㄲㄲㄲㄲ

그랬는데 일대일 대전 격투 게임 분야에도 Doom과 비슷한 위상을 차지하는 명작이 있다. 바로 모탈 컴뱃(Mortal Kombat).
그 장르의 게임으로는 의외로 미국산 게임이 별로 없다. 본인이 아는 건 삼국지 무장쟁패, 스트리트 파이터, 철권, 버추어 파이터 따위가 고작인데, 어느 것도 미국산이 아니다.

그에 반해 모탈 컴뱃은 미국산이다. 하지만 게임 로고에서부터 용의 그림이 등장하고 좀 동양스러운 느낌이 난다.
모탈 컴뱃은 1992년, 그러니까 울펜슈타인과 버추어 파이터 1하고 비슷한 시기에 첫 편이 나온 후, 오늘날까지 꾸준히 후속편이 출시되어 왔다. 제목에서 느껴지듯이 K 발음이 나는 C에 일부러 K를 집어넣었다. 코브라도 Kobra. 그렇게 적으니까 꼭 한국스러운 느낌이 나는구나(Korea? Corea?).

모탈 컴뱃이라는 말 자체는 격투 룰을 가리킨다고 한다. 마치 배틀 로얄(Battle Royale)처럼 말이다.
본인이 중딩 꼬꼬마이던 시절에, 주인공의 그래픽이 실사처럼 아주 큼직하고 정교하고, 마지막에 Finish him/her!이 나오는 격투 게임을 잠깐 본 적이 있었는데 그 게임이 바로 저 게임이었다.

그리고 스프라이트는 '실사처럼'이 아니고 '실사'가 맞다. 모탈 컴뱃은 1995년에 출시된 3편까지는, 비록 2D 도트이지만 액션 배우의 움직임을 그대로 촬영한 스프라이트를 써서 상당히 획기적인 그래픽을 선보였다. 실사 이미지로부터 잘 편집된 256색용 스프라이트를 얻는 게 보통일이 아니었을 텐데, 대단하다. 그야말로 엄청난 노가다였을 것이다.
(무려 1989년에 페르시아의 왕자의 스프라이트를 만들 생각을 했던 조던 메크너만큼이나 획기적인 시도이다. ^^)

말이 나왔으니 말인데, 본인은 옛날에 256색 모드에서 궁극의 팔레트 최적화도 엔지니어들의 어지간한 덕력과 근성이 아니었으면 엄두도 못 냈을 작업이라고 생각한다. 스타크래프트를 생각해 보라. 어떻게 그 그래픽에서 8종족 색깔별로 클록킹 유닛(알파 블렌딩)을 구현했으며, 퀘이크는 동적 광원을 구현했겠는가!

이 게임의 백미는 격투 말미에 다 죽고 헤롱헤롱하고 있는 상대편을 필살기로 끔살하는 일명 Fatality 기술이다.
퀘이크 3 아레나에 레일건이 있고, 카트라이더에 드리프트가 있으며, 스타크래프트에 스팀팩과 사이오닉 스톰이 있다면...
모탈 컴뱃에는 Fatality가 있다.

이게 정말 성경에 나오는 '인간의 상상하는 바가 원천적으로 악하다'(창 6:5, 8:21)는 걸 입증하는 것 같다. 사지를 각을 뜬다거나, 전기로 지지거나 산 채로 불태우거나 뭐 기타 등등...;;
주인공별로 가히 기상천외한 엽기적인 방법으로 상대편 캐릭을 작살을 낼 수 있다. 저런 현란한 비주얼을 어떻게 만들 생각을 다 했는지 모르겠다.
그런데 나도 그런 거 보면 쾌감이 느껴진다. 아담의 본성이다. -_-

그 후 모탈 컴뱃 4는 당대의 게임계의 추세에 따라 드디어 주인공이 3D 폴리곤으로 바뀌었다. 비록 그때는 현란한 각도 회전을 대가로, 예전의 2D 스프라이트가 뽐내던 도트 단위의 화려한 비주얼은 어느 정도 희생해야만 했다. 하지만 지금 3D 그래픽은 가히 실사나 다름없다. full 3D 게임이 처음으로 나오던 때는 버추어 파이터도 주인공이 가히 목각 인형에 불과했고, 퀘이크도 파티클은 그냥 사각형 픽셀로 처리될 정도로 허접했다.

동양스러운 느낌 하니까 생각나는데, 퀘이크 3 아레나도 싱글 플레이의 최종 보스인 Xaero는 사이보그 로봇이 아니고, 오크나 저그 같은 괴물도 아니다. 대머리에 중국 내지 티벳 승려 차림을 한 아저씨이다. 예전의 FPS 게임들의 최종 보스가 무식하게 높은 HP + 물량전 컨셉이었다면, 퀘3은 우리와 똑같은 인간이 마치 결투를 하듯 정밀도가 높은 레일건으로 플레이어와 승부한다. 이런 모습을 보고 본인은 퀘3을 처음 하던 시절에 무척 놀랐었다. FPS에다가 격투 게임 비슷한 디자인을 도입한 셈이다.

모탈 컴뱃은 툼레이더나 둠처럼 영화화도 되었다. 동양을 배경으로 말이다. 퀘이크에 매니아 계층인 '퀘이커'(개신교 교파인 퀘이커 말고-_-)가 있다면, 모탈 컴뱃도 '모탈리안'이라고 불리는 매니아 계층이 서양에는 굉장히 많다고 한다.
유튜브에 스타크래프트 실사판이 나돈 적이 있었는데-_- 이 양덕후 모탈리안들은 모탈 컴뱃 실사판도 만들어서 UCC랍시고 올린다. ^^;;

대전 액션 게임의 내레이션은 톤이 극도로 낮고 좀 사악한(?) 느낌이 나는 남자 목소리로 만들어지는 경향이 있다. “Fight one. Ready, go” / “Round one. Fight!” / “You win” 등. -_-

이렇게 본인이 갑자기 모탈 컴뱃에 대해서 글을 쓴 이유는...
고등학교 시절에 본인이 만들었던 오목 게임의 이름도 아마 모탈 컴뱃으로부터 알게 모르게 영향을 받은 것 같아서이다. ㅋㅋㅋㅋㅋ

Posted by 사무엘

비주얼 C++ IDE (정확히는 비주얼 스튜디오)에는 간단하게나마 위지윅 HTML 에디터가 내장되어 있다. 다만, 입력하는 내용에 따라 프로그램이 생성해 주는 HTML 코드가 굉장히 지저분한 편이어서(여백, 정렬 상태 등~) 본인은 이를 즐겨 사용하지는 않는다.

물론, 언어별로 IDE가 따로 놀던 비주얼 C++ 6의 IDE에는 HTML 편집기가 없었으며, 웹 편집은 비주얼 InterDev라는 프로그램이 따로 담당하고 있었다. 그 대신 비주얼 C++ 6은 OLE 기술을 이용하여 심지어 MS 오피스 문서를 자기 IDE 내부에다 가져와서 편집하는 기능이 있었다! 물론 MS 오피스가 설치되어 있는 경우에 한해서.

File-New 대화상자를 보면 맨 오른쪽 탭에 MS 오피스(워드, 엑셀 등) 문서를 만드는 항목이 있었지만, 이 사실을 아는 사람은 아주 드물었을 것이고, 그 기능을 이용하거나 그렇게 OLE 친화적인 업무용 프로그램을 만드는 사람도 거의 없었다. 그래서 비주얼 스튜디오에서도 이후 닷넷부터는 그런 잉여 기능이 제외됐다. 내 기억이 맞다면 딱 하나, MS 오피스에 이어 아래아한글 2002가 그렇게 문서를 만드는 기능을 지원했다.

비주얼 스튜디오 닷넷은 잘 알다시피 모든 언어들의 IDE가 Microsoft Development Environment라는 이름으로 한데 통합했으며, 그래서 한 프로그램으로 소스 코드, 텍스트, 웹 문서 등을 모두 한데 만들 수 있게 되었다. 비주얼 스튜디오가 제공하는 웹 에디터는 아주 초보적인 수준이었다. 그냥 인터넷 익스플로러가 제공하는 에디팅 엔진을 그대로 차용했다.

본인은 비주얼 스튜디오가 제공하는 웹 에디터는 ‘진하게’를 왜 b가 아닌 strong 태그로 표현하고, ‘이탤릭’을 왜 I가 아닌 em으로 표현하는지 의아해했다. 200x년대에 사용하던 나모 웹에디터와 FrontPage는 b, I를 썼기 때문이다. 기능이 동일하면 더 짧은 표현이 좋기 때문에.. ㄲㄲ

물론 그 이유는 웹 표준의 개정 때문이다. HTML은 워드 프로세서 문서처럼 글자 비주얼이 아니라 문서의 논리적인 구조와 의미를 표현하는 용도로 유지하기 위해서 물리적인 비주얼을 표현하는 방식을 CSS 위주로 바꾼 것이다.

글씨체를 바꿨을 때 태그가 생성되는 방식은, 놀랍게도 비주얼 스튜디오의 버전마다 서로 다 다르다.
2003까지는 그냥 대놓고 <font face="무슨체"> 였다.
2005는 <span style="font-family:무슨체">가 되었다.
2008은? 아예 head 태그 내부에 그 서체를 지정하는 새로운 스타일이 등록되고 <span class="style1">이 생성된다.

똑같은 운영체제와 똑같은 IE 버전 하에서도 서로 다르게 동작하는 걸 보니, 이건 전적으로 비주얼 스튜디오의 버전별 차이로 보인다.

여기까지만 분석을 하고 말려고 했는데...
비주얼 스튜디오 2008은 웹 에디터가 뭔가 바뀌었다. 지금까지 전혀 눈치채지 못하고 있었다.

2003과 2005가 단순히 IE 기반인 것에 비해,
2008은 위지윅 에디터(소스 편집이 아닌 디자인 모드)의 윈도우의 클래스 이름이 FrontPageEditorDocumentView. 다시 말해 MS 오피스 2003 이후로 개발이 중단된 FrontPage의 에디팅 엔진을 얹었다는 뜻 되겠다! ㄷㄷㄷ;;;

덕분에, 2008 이전의 비주얼 스튜디오(VS) 내장 웹 에디터는 디자인 모드 아니면 소스 편집 모드 이렇게 두 가지 모드만 제공하였으나, 2008은 FrontPage처럼 한 화면에서 디자인과 소스를 한꺼번에 보고 편집하는 분할 모드도 같이 지원한다. 그리고 FrontPage처럼 태그 단위로 텍스트를 한꺼번에 선택하고 속성을 지정하는 정교한 편집 기능도 지원한다. 단순한 IE 기반 엔진만으로는 구현할 수 없는 기능임.

그런데 그런 것만 바뀐 게 아니라, VS 2008의 웹 에디터는 진하게/이탤릭 태그도 과거의 FrontPage처럼 b, i로 되돌아갔다. 이런?
VS 2010은 어떤지 모르겠다. 듣기로는 소스 코드 에디터도 완전히 새로 다시 짰다고 하니 또 바뀐 게 있겠지.

그래서 지금부터는 FrontPage 얘기를 좀 하겠다.
FrontPage는 여타 회사에서 개발되던 웹 에디터를 마이크로소프트가 인수하여 90년대 후반부터 개발을 시작했다. 그래서 초창기 버전에는 윈도우의 클래스 이름이라든가 생성된 HTML 코드의 generator 메타태그에 원래 회사의 이름 이니셜 같은 걸 찾을 수 있었다고 한다.

HTML 태그는 아무나 만지는 물건이 아니다 보니 웹 에디터 역시 워드, 엑셀 같은 전국민 필수품은 아니며, 아웃룩처럼 업무용 필수품도 아니다. 그러나 그렇다고 해서 이게 액세스라든가 비주얼 스튜디오 급의 전문 개발자 영역도 아니다 보니, 이런 프로그램이 차지하는 위상은 무척 어중간했다.

다이어그램을 그리는 프로그램으로 윈도우 3.x 시절부터 명성을 떨쳤는데 나중에 역시 MS에게 인수된 비지오(Visio)와 비슷한 위상 같다. FrontPage는 MS 오피스 제품군의 정식 멤버는 아니었지만 어째 오피스 XP 및 2003과는 동일한 타이밍에 버전업을 거쳤다.

FrontPage는 XP와 2003의 동작 방식이 서로 굉장히 달랐다. XP는 모든 html 코드를 자기 컨벤션대로(줄당 문자 수, 들여쓰기 등) 무조건 깔끔하게 정리하는 기능이 있었고, 심지어 html 코드 최적화 기능까지 있었다. 이게 잘 동작할 때는 무척 유용하지만, 자기가 이해하지 못하는 태그를 제멋대로 고쳐 버리기까지 해서 믿음직하지는 못했다.

그러던 것이 2003에 와서는 정책이 정반대로 바뀌어서, 이미 만들어진 코드는 최대한 건드리지 않고 수정된 부분에 대해서만 최소한의 변경만 가하는 방식이 되었다. 이것도 좋긴 하지만, 수정을 거듭하다 보면 앞서 말했듯이 코드가 무척 지저분해져서 싫다. 그리고 <li>, <ol>처럼 목록을 표현하는 태그에서 여닫기 처리를 제대로 못 하는 경우가 많다.

마치 휴대전화의 카메라 기능이 발전하면서 기존 디지털 카메라들은 아예 DSLR 같은 더 전문적인 영역으로 경쟁 구도가 바뀌었듯, 오늘날은 블로그가 발달하고 웹에서 바로 위지윅 html 에디터 내장 게시판을 쓰는 시대가 됐다. 로컬 환경에서 html 에디터를 쓸 일이 무척 줄었다.

그래서 FrontPage는 2003 버전을 끝으로, 더 전문적인 웹 디자인 솔루션인 MS Expression Studio에게 자리를 내어 주고 개발이 중단되었다. 그리고 그 FrontPage의 엔진이 비주얼 스튜디오의 2008에 전해져 오는 모양이다. ㅋㅋ

본인은 FrontPage를 내 홈페이지 편집과 프로그램 도움말 제작용으로 지금까지도 애용 중이다.
오히려 지금까지 Expression Studio를 쓰는 사람을 본 적이 없다. 그나저나 요즘 드림위버는 살아 있나?

Summary:
1. 위지윅 웹 에디터로 각종 아기자기한 클립아트를 넣으면서 자기 홈페이지를 만들던 시절이 그립다. ㅋㅋ
2. 여러분은 html 편집을 무엇으로 하십니까?

Posted by 사무엘

별개의 분야 이야기들이 또 한데 컬렉션 형태가 됐다.

1. Personalization of Windows

이건 아무나 쉽게 할 만한 건 아니지만, 아마 윈도우 파워 유저들은 한번쯤 시도해 봤지 싶다.

콘솔(명령창)의 글꼴 바꾸기
솔직히 나도 Terminal 기본 서체는 이제 지긋지긋해서.. 똥 묻은 파르페 다음으로 싫다.. -_- 과거 윈 9x는 도스 프롬프트의 코드 페이지를 영문 437로 바꾸면 Courier New나 Lucida Console이라도 나와서 괜찮았으나, 2000/XP의 콘솔 글꼴은 너무 단조롭기 그지없다.
특정 레지스트리 부위에다 00이라는 키를 추가해서 원하는 글꼴을 지정한 뒤 재부팅을 하면 된다고 하는데, 난 여러 사이트들에서 시키는 대로 해도 안 되더라...;; 잘 모르겠다.

XP의 경우, uxtheme 패치
자세한 배경 설명은 생략하고. 요지는.. XP의 트레이드마크라고 할 수 있는 Luna 테마 대신 다른 시각 테마를 쓰는 것이다. 그런데 테마를 바꾼다는 건 단순히 색깔이나 이미지 같은 데이터뿐만이 아니라 각종 화면 요소를 그리는 실행 코드 자체를 바꾸는 것이기 때문에, 운영체제의 안정성 및 보안에 영향을 끼칠 수 있다. 그래서 운영체제는 기본적으로 디지털 서명이 존재하는 테마만 고를 수 있게 돼 있다.
그러나, 개인 테마 제작자가 일일이 자기 작품에 대해서 $를 지불하고 번거롭게 디지털 서명 인증을 받는 건 쉽지 않은 노릇이고.. 결국 디지털 서명이 없는 테마도 지정 가능하게 아예 운영체제 자체를 크랙하는 테크닉이 나돌게 됐다. 아이폰으로 치면 탈옥 정도 되겠다.

난 XP의 파란 Luna가 예뻐서 거기에다 custom 글꼴 & 그림만 붙여서 잘 썼다. 테마를 바꿀 필요는 느끼지 않는다. 비스타로 갈아탄 지 3년이 넘었지만 여전히 XP Luna가 그리울 때가 있다. 하긴, 비스타에서 Luna 커스텀 테마를 일부러 구해다 쓰는.. 흠좀무스러운 사람도 있다고는 하더라...

2. Phone number as the hyperlink

남이 내게 문자 메시지로 다른 전화번호를 알려 줬다. 이렇게, 발신자 그 자체가 아니라 본문에 포함돼 있는 전화번호를 번거롭게 암기하거나 수첩에 적지 않고 그대로 저장하거나 전화를 걸 수는 없을까?
마치 http로 시작하는 문자열이 인터넷 주소이고 "@ ." 같은 패턴이 이메일 주소이듯, 전화번호를 나타내는 정규 표현식이 통용되어 이런 건 전화기가 마치 클릭 가능한 하이퍼링크처럼 본문에다 표시해 주는 기능이 있으면 좋겠다.

자동으로 링크를 못 만든다면 최소한 번호를 마우스로 긁어서 복붙 정도는 되어야겠지.
간단하기 때문에 스마트폰에는 이미 구비되어 있는 기능일지도 모르겠다?
아래아한글 도스용에 있던 전화번호부와 팩시밀리 기능이 불현듯 떠오른다. COM 포트를 통해 컴퓨터가 모뎀으로 전화를 걸어 주던 시절이었다.. ^^;;

3. 디렉터리 생성을 좀 더 똑똑하게

컴퓨터의 파일 시스템에서 지우기 명령에 하위 디렉터리를 재귀적으로 몽땅 다 지우는 기능이 있다면,
디렉터리 생성 명령에도 중간의 다단계 디렉터리를 한꺼번에 생성하는 기능이 있어야 한다.
또한, 디렉터리를 생성한 후 바로 거기로 가는(change directory) 기능 내지 옵션도 있으면 편하지 않을까?
이건 114로 치면 전화번호를 물은 후 그 전화번호로 바로 거는 기능에 해당한다.

다단계 디렉터리를 한꺼번에 생성하는 기능은 있지만 생성한 디렉터리로 바로 가는 기능은 프로그래밍 API라든가, 각종 유틸리티 프로그램이나 명령으로도 내가 본 기억이 없는 듯하다.
요즘은 옛날에 비해 디스크/파일을 다루는 유틸리티에 대한 필요성이 훨씬 덜해지긴 했지만.. 특정 디렉터리나 드라이브로 곧바로 이동 가능하고 특정 프로그램을 단축키 하나로 바로 실행해 주고 한 화면에서 압축 파일이라든가 FTP 연동이 바로 되는 유틸리티가 있으면 컴퓨터 생활이 정말 편해진다.

토탈 커맨더, NexusFile 같은 프로그램이 유명하긴 한데 본인은 단축키가 완전히 손에 익어 버려서.. 개발이 중단된 구닥다리 WinM을 못 버리고 있다.

4. DR만 들어가면 다 박사?

DR이라는 약어가 하도 '닥터'라고 통용되니까, 과거에는 이로 인해 재미있는 오해가 발생한 컴퓨터 소프트웨어가 있었다.
MS-DOS의 경쟁자 중 하나이던 DR-DOS는 그래도 다 대문자로 쓰고 MS-DOS도 '엠에스'라고 읽다 보니, '디알'이라고 통용되었던 것 같다. MS-DOS를 설마 '미스 도스'이라고 하지는 않잖아? 도스의 모에화ㄲㄲㄲㄲㄲ 훗날 나온 노벨 도스의 전신이 DR-DOS인 줄은 모르고 있었네..;;

그러나 그래픽 소프트웨어인 '닥터할로'는 답이 없다..;; Dr. Halo라고 쓰면.. 누구에게라도 영락없이 '할로 박사님'처럼 보일 수밖에 없지 않은가. 설마 개발자가 박사 학위 소지자이기라도... 한지는 모르겠지만 Dr은 그냥 '드로잉'을 줄인 말이라고 한다.

5. 스마트폰 OS 에뮬레이터

PC에서 안드로이드 에뮬레이터가 실행되는 속도는 실제 기계에 비해서... "꽤", 훨씬 더 느리다. 난 약간 느릴 줄 알았는데 이 정도까지 차이가 날 줄은 몰랐다.

하긴, 도스박스조차 200x년대의 컴에서 같은 x86 아키텍처용 도스용 프로그램을 펜티엄급으로밖에 실행을 못 하는데, x86와 ARM은 인스트럭션 구조가 근본적으로 다르다. 게다가 요즘 스마트폰은 CPU와 메모리로만 치면 이미 최하 윈도우 98/2000 정도는 너끈히 돌리는 성능이다. 무슨 고전 게임도 아니고, PC와의 격차가 의외로 높지 않으니 PC에서 에뮬레이팅이 버거울 수밖에 없다.
게다가 애플리케이션들은 그나마 네이티브 코드도 아니고 잘 알다시피 자바 기반.

그리고 마지막 복병이 있는데 바로 그래픽 가속이다. OpenGL 같은 통일된 인터페이스가 있다지만 그래픽 가속은 워낙 민감한 부위여서 그런지 가상화가 더디다. 가상 머신에서 돌아가는 윈도우 비스타/7이 Aero 효과를 내지는 못하며, 에뮬레이터에서 돌아가는 스마트폰 OS는 실물만치 현란한 비주얼을 선보이지는 못한다.

그러나 PC+에뮬레이터가 디스크 I/O만은 실물보다 훨씬 더 빠르게 수행한다.
이런 식으로 스마트폰 앱은 에뮬레이터에서 돌릴 때와 실물에서 돌릴 때의 성능 편차가 의외로 크며, PC에서 개발하더라도 수시로 실물에서 올려서 확인이 필요하다고 한다.

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 사무엘

간단한 IT계 역사 메모부터 남기고 새해를 시작한다.

95: 최초로 100% 32비트 코드로 제작되고, 각종 UI에서 운영체제의 공용 컨트롤을 적극 활용함.
Caption bar에 검정-파랑 그러데이션이 있었고, Microsoft가 고딕+이탤릭이었음. 나름 non-client 영역의 painting을 95 특유의 방식으로 처리했으며, 이게 당대에 출시된 윈도우 95 프로그램들의 유행이 되기도 했다. 아직은 16비트 프로그램을 32비트로 단순히 포팅만 했다는 느낌이 강하던 시절.

97: 메뉴와 도구모음줄이 모두 자체 제작 컨트롤로 대체됨. flat style 도구모음줄 + 도구모음줄 아이콘이 병기되어 있는 메뉴가 유행이 됨. Office 길잡이가 최초로 도입됨!
내부 문자 체계가 유니코드(정확히 말하면 wide string)로 바뀜. 당대로서는 굉장히 혁신적이던 벡터 그래픽 라이브러리가 도입됨(3차원 그림자 등).
윈도우 NT 3.x를 지원한 마지막 버전.

2000: 오늘날 오피스의 근간이 된 기능이 많이 도입되었다. Windows Installer 도입. 최초로 프로그램들 아이콘이 프로그램별로 고유색을 지닌 픽토그램 형태로 바뀜.
Word는 MDI 형태를 탈피하고, Excel은 블록이 검은 반전색이 아닌 옅은 파랑으로 생기기 시작. Word의 Plus pack에 한양 PUA 기반 옛한글 입력기 제공.
두 줄로 걸친 Toolbar와 personalized 메뉴, HTML 도움말(97은 HLP 기반이었음!). 윈도우 95를 지원한 마지막 버전.

XP (2002): 메뉴와 도구모음줄이 회색 3D 모양을 탈피하여, MS스럽지 않은 산뜻한 비주얼로 탈피함. Task pane 도입. TSF 문자 입력 시스템 도입. 이때부터 MS 오피스는 윈도우 운영체제와는 별개의 자체 IME를 제공하는 게 관례가 됨.
GDI+를 사용하여 벡터 그래픽에 안티앨리어싱. Word는 불연속적인 블록을 여럿 잡는 게 가능해짐. 스마트 태그. Plus pack의 옛한글 입력기가 유니코드 표준 방식으로 개선됨.
마이크로소프트 사의 개발 정책 변경으로 인해 이 버전부터는 이스터 에그가 완전히 사라졌다. 윈도우 98/ME/NT4를 지원한 마지막 버전.

2003: 윈도우 XP 기준으로 메뉴와 도구모음줄에 전반적으로 파란 비주얼. Word에 읽기 모드 view 추가. 리서치 탭. OneNote와 InfoPath라는 새로운 프로그램 도입. 프로그램이 새로 추가된 것 외에 기존 Word, Excel 같은 프로그램이 크게 바뀐 것 같지는 않다.
이 버전은 2004라고 불릴 수도 있을 정도로 꽤 늦가을에 출시되었다. 윈도우 2000을 지원한 마지막 버전.

2007: 맑은 고딕. 리본 인터페이스. 새로운 XML+ZIP 압축 기반 문서 파일 포맷 도입. Live preview 등, UI가 굉장히 많이 바뀜.
Word는 자체 수식 편집기가 추가됨. Excel은 편집 가능한 시트 크기가 더욱 커지고, 드디어 천연색을 표현할 수 있게 됨. 97 이래로 큰 변화가 없던 벡터 그래픽 및 글자 꾸미기 라이브러리의 기능이 크게 향상됨. (PowerPoint의 화려한 비주얼에 일조)
서비스 팩 및 추가 패키지를 설치하면 ODF 읽기/쓰기와, PDF 저장도 프로그램 차원에서 자체 지원함.

2010: 드디어 x64 바이너리 출시. 그리고 또..?

Posted by 사무엘

1. 망했어요

사례 1: USB 플래시 메모리를 ‘안전하게 제거’하지 않고 그냥 뺌 → 어느 날 그걸 꽂으니까 “뭘 스캔해서 수정하시겠습니까?”라고 물음 → 예 → 뭐 오류가 있는 파일 조각을 따로 정리했다고 하는데, 그 후 작업하던 문서 파일이 날아가 버림

사례 2:자기가 작업하던 파일을 인터넷에 올림 → 다른 컴에서 그걸 그대로 엶 (인터넷 임시 파일 디렉터리에서) → 작업을 임시 파일에다 마저 다 해 놓고 저장 → 나중에 그 파일을 찾아보니 없음

이번 학기에 학교에서 주변에 실제로 있었던 낭패 사례이다. 조심하자. 본인이 겪었다는 건 아니고. -_-
PC가 발전하는 걸 도스 시절부터 그 디테일을 쫙 봐 오지 않은 사람이라면 쉽게 저지를 만도 한 실수인 것 같다. 디스크 캐시와 flush의 필요성, 인터넷 임시 파일의 개념과 원리에 대한 이해가 필요하니까 말이다.

USB로 연결하는 플래시 메모리의 경우, 평소에 그냥 쑥 제거해도 별 문제가 없는 듯하다가 어느날 갑자기 FAT 구조가 망가졌다고 그러면...;; 정말 사용자들 패닉에 빠뜨리기 딱 좋을 것 같다.
안전하게 제거를 하지 않는 것은 과거에 플로피 디스크 드라이브에 불이 들어와 있는데 디스크를 강제로 꺼내는 것이라든가, 하드디스크를 파킹하지 않는 것만큼이나 위험할 수가 있다.

다만, CD롬은 일단 쓰기가 없는 읽기 전용 매체인 데다가, eject 버튼을 누르면 아무 때나 디스크를 물리적으로 꺼내는 게 아니라 자기가 꺼낼 준비를 다 마치고 나서 eject를 시켜 주기 때문에 다소 예외적인 존재이다.

2. 하드디스크 파킹의 추억

옛날에 컴퓨터에 하드디스크라는 게 처음으로 등장하던 시절엔(도스+윈도우 3.x) 컴퓨터를 끄기 전에 하드디스크 파킹이 안전을 위해 필수적인 절차였다. 파킹을 하지 않는 것 자체가 문제는 아니지만, 파킹을 하지 않은 채로 나중에 하드디스크가 외부로부터 충격이라도 받았을 때, 헤드가 자기 아래의 디스크 영역을 건드리거나 긁는 게 문제가 되었기 때문이다. 헤드와 디스크 사이의 간격은 아마 몇 마이크로미터 정도밖에 되지 않았지 싶다. 하드디스크는 그 당시로서는 그만치 첨단 정밀 기기였던 것이다.

파킹은 하드디스크의 헤드를 디스크가 아닌 다른 안전한 위치로 옮기는 동작을 말하는데, MS 도스 인터럽트를 날려 주면 수행되었다(INT 13, 19h). 286 AT급 이상부터 추가된 명령이다. 도스 시절에 컴퓨터의 C:\Util에 가 보면 park.com/exe는 꼭 한둘씩 있었다.

그런데 이 파킹 유틸리티의 비주얼이라는 게, 오늘날로 치면 마치 화면 보호기의 비주얼만큼이나 아주 잉여스럽게 발달했다.
그냥 파킹만 하면 재미없으니까 좋아하는 볼거리, 미소녀 그림-_- 따위가 뜨는 파킹 프로그램들이 우후죽순처럼 등장한 것이다.

당시 여러 파킹 프로그램이 있었지만 본인의 기억에 가장 남는 건 일명 Princess maker 파킹이라고 아래와 같은 소녀 그림이 나오는 프로그램이었다. 어렸을 때는 정말 환상적이기 그지없는 그림이었다.

본인은 도스 시절에 하드웨어 제어 프로그래밍을 경험한 적은 없지만, 그때는 각종 인터럽트 레퍼런스가 지금으로 치면 윈도우 API 레퍼런스나 마찬가지였다. ^^;; 그걸로 마우스를 직접 제어하고, 한글 바이오스가 설치돼 있는지 감지하는 등의 작업을 했는데 오늘날은 다 필요 없어진 셈.

또한, 전원이 끊어지는 순간에 자동으로 파킹이 되는(auto-parking) 하드디스크가 이내 등장하고, 도스에서 윈도우로 PC 환경이 바뀌고, 또 요즘 같은 복잡한 운영체제는 아무 때나 바로 끄면 안 되고 어차피 시스템 종료라는 걸 요구하게 되면서 customized 파킹 프로그램이라는 유행은 역사 속으로 사라지게 됐다. 지금은 파킹 프로그램뿐만 아니라 화면 보호기도 LCD 모니터가 대세가 되면서 취지가 무색해지긴 했다.

3. 당신이 사용하는 소프트웨어는?

서식 없는 텍스트 작성
컴 초보: 메모장이나 일반 워드 프로세서로 낑낑댐
나: EditPlus나 AcroEdit, <날개셋> 편집기^^ 잘 다룸
전산과 덕후: vim, emacs 등..;;

서식 있는 텍스트
컴 초보: 닥치고 아래아한글
나: 아래아한글이나 워드를 평균 이상으로 그럭저럭 활용
전산과 덕후: TEX이나 그냥 메모장으로 html 코딩..;; 리눅스 용자는 OpenOffice를 쓰기도 함 ㅋㅋㅋ

뭔가 자동화 작업을 반복 수행할 때
컴 초보: 직접 손으로..;; 아니면 프로그램 검색하거나 남에게 부탁
나: 적당한 프로그램이 없으면 그냥 비주얼 C++로 프로그램 자작
전산과 덕후: 파이썬이나 쉘 스크립트

위의 것보다는 더 규모 있고 성능이 중요하고 남에게 실행 파일을 전달해 주는 프로그램을 짠다면?
컴 초보: 그냥 선생이 지정해 준 툴로... 과제만 내고 나면 다 잊어버림
나: 닥치고 비주얼 C++ 짱
전산과 덕후: 커맨드 라인에서 gcc -_-;;

난 소프트웨어 개발자치고는 MS의 종속도가 높으며, 전산과 덕후의 문화를 너무 모른다. -_-;;;

Posted by 사무엘

컴퓨터가 글자가 아닌 그림을 처리하기에는 능력이 한참 부족하던 시절에, 벌써부터 포인팅 장비라는 개념이 있는 게 사용자 인터페이스 차원에서 좋겠다는 생각을 한 선구자가 있었다. 그게 한 196~70년대의 일이다.
포인팅 장비는 2차원 평면에서의 속도감 내지 곡률을 표현할 수 있기 때문에, 컴퓨터에서 키보드와는 또 다른 영역을 개척한 중요한 입력 장치이다.

마우스: x, y 축의 재빠른 이동과 클릭을 지원하는 대표적인 포인팅 장비. 옛날에는 버튼이 3개였으나 요즘은 2버튼으로 통일되었고, 대신 휠이 달려 나온다. 또한 볼 마우스이던 것도 다 광 마우스로 대체. 3버튼이나 트리플 클릭이 없는 것은 인간이 심리적으로 3회 이상의 동일 동작 반복을 싫어한다는 증거가 될 수도 있다. 마우스를 쓰는 프로게이머는 있어도 트랙볼이나 터치패드를 쓰는 변-_-태는 없다. 하지만 인체공학적으로 잘 만들어지지 못한 마우스를 오래 사용할 경우 사용자의 손목에 굉장한 무리를 주므로 주의 필요.

트랙볼: 볼 마우스의 볼을 직접 굴리는 방식으로, 마우스와 기능면에서는 동일하다. 마우스의 쾌적한 이동성은 다소 희생했지만, (1) 좁은 공간에서 사용 가능하고 (2) 손가락만 까딱이면 되지 손목 전체를 움직일 필요가 없어서 피로감이 덜하다는 장점이 있다. 그래서 노트북에 전통적으로 트랙볼 류의 포인팅 장비가 탑재되는 경향이 있었다.
트랙볼은 x, y뿐만 아니라 마우스로는 가능하지 않은 z축 이동을 이론적으로 표현할 수 있다. (볼 자체를 좌우로 굴리기!!) 나름 3차원 장비라는 뜻. z축을 휠로 사용해도 될 것 같은데.

터치패드: 역시 노트북용 마우스 대체 장비로 손가락을 마우스처럼 이동한다. 트랙볼의 장점을 어느 정도 가지면서 이동의 편의성이 트랙볼보다 낫지만 여전히 마우스보다는 못하며, 이동 중에 클릭이나 휠 조작을 동시에 하기가 어렵다는 단점이 있다. 터치패드에 영 적응을 못 해서 늘 마우스를 지참하는 노트북 사용자도 있으나, 본인은 터치패드로 스타도 할 정도로 이놈을 아주 능숙하게 다룬다. 노트북 사용 10+년 경력.

IBM 노트북에만 있는 거시기: 이름이 뭔지 모르겠다. 트랙볼보다도 더욱 홀쭉한 bar를 한 손가락으로 어루만지고 있으면, 손가락이 닿은 지점에 따라 마우스 포인터가 직선 내지 매끄러운 곡선 궤적을 그리면서 이동한다. 공간 활용성은 최적이고 어떻게 만들었는지 정말 신기하기 그지없는 물건이긴 하나, 이동성은 그리 좋지 못하다고 봐야겠다.

아울러, 마우스를 제외한 다른 대체 포인팅 장비들은 휠을 굴리는 것까지는 표현하는 방법이 있는 반면, ‘휠을 누르는’ 동작은 표현하지 못하는 경우가 많다. 보통 휠을 누르면 동그란 앵커가 포인팅 지점에 나타나면서 문서를 위나 아래로 자동으로 스크롤하는 모드가 된다. ^^;;

터치스크린: 이건 마우스와는 성격이 약간 다른 장비이기 때문에 마우스의 대체품이 되지는 못한다. 말 그대로 화면을 터치할 수 있는데 여러 곳의 동시 터치가 가능하고 장비에 따라서는 터치하는 압력을 표현할 수 있다. 그래서 여러 손가락을 동시에 써서 그림을 그리거나 문자를 입력하거나, 건반악기의 화음 표현까지도 가능하다.

다만, 터치스크린은 딱히 스타일러스 펜을 사용하지 않는다면 좌표의 정밀도가 크게 떨어지며, 마우스로 치면 늘 click이나 drag만 존재하지 포인터를 움직이기만 하는 hovering을 표현할 수 없다는 게 문제이다. 즉, UI 요소에 대해서 ‘이게 뭐지?’ 하는 tooltip을 구현하기 어렵다. 또한 좌클릭/우클릭 구분도 할 수 없기 때문에 마우스와는 근본적으로 다른 방식의 UI 설계가 필요하다.

태블릿: 옛날에 본인이 어렸을 때는 디지타이저라고 배웠던 것 같다. 웹툰 작가 같은 그래픽 디자이너에게 필수인 물건이다. 모니터가 아니라 종이처럼 생긴 납작한 물건 위에다가 펜으로 그린다. 그래픽용으로 쓰는 물건인 만큼 압력을 표현할 수 있다.

※ 덧붙이는 말

1. 도스 시절에는 마우스를 모뎀과 같은 COM port에다 꽂았다. 추억의 mouse.com 프로그램. 무슨 인터럽트 서비스를 호출해 주면 하드웨어? 차원에서 아주 자그마한 마우스 포인터가 나타났었다. 그런데 마우스 포인터를 유지하는 게 도스 시절엔 꽤 부담스러운 일이었다. 화면을 고칠 때마다 포인터를 숨기고 다시 그려 줘야 했기 때문이다. 안 그러면 화면에 잔상이 남음.

1990년대 중반에 그래픽 카드의 성능이 발달하면서 윈도우 3.1 시절부터 flicker-free 포인터가 나타나기 시작했다. 하드웨어 차원에서 마우스 포인터의 모양을 입체적으로 보존해 준다는 뜻이다. 그것도 처음에는 시스템 기본 포인터라든가 monochrome(단색) 포인터만 지원되던 것이 2000년대부터 아무 포인터에 대해서도 OK가 되기 시작한 것이다.
윈도우 2000은 안전 모드로 부팅해서 허접한 일반 VGA 16컬러 모드에서 구동될 때도 마우스 포인터가 flicker-free가 보장되는 게 인상적이었다. 9x는 그렇지 않기 때문에.

2. 초창기에 마우스를 지원하던 프로그램은 마우스 포인터라는 게 없었고, 위· 아래로 마우스를 움직이면 선택 막대가 움직이는... 오늘날로서는 아주 기괴한 인터페이스를 제공하기도 했다.

3. 그나저나 마우스 휠이라는 건 1997년 무렵에 MS가 적극적으로 홍보하면서 널리 퍼졌다. WM_MOUSEWHEEL이라는 메시지가 운영체제 차원에서 추가된 것은 윈도우 98부터이다.
그때는 나중에 휠이 연속적이고 부드러운 rolling도 표현 가능할 것을 염두에 두고 메시지의 스펙을 설계했지만 지금 휠이 실제로 그런 방향으로 바뀐 것 같지는 않다.

일반적으로 마우스 휠 메시지는 다른 마우스 메시지와는 달리, 마우스 포인터가 가리키고 있는 윈도우가 아니라 현재 키보드 포커스를 받고 있는 윈도우로 날아간다. 그래서 원래 휠 메시지는 마우스 포인터가 어디 있든지 관계없이 받을 수 있는데 예외가 있다. 웹브라우저 창에서 굴리는 휠은 키보드 포커스도 있고 포인터 역시 그 창에 있어야 인식된다. 한 브라우저 창 안에 여러 프레임이라든가 심지어 글자 입력란처럼 여러 윈도우가 존재할 수 있기 때문에 그렇게 디자인된 것 같다.

4. 옛날 컴퓨터에는 컴퓨터의 동작 전체를 멈출 수 있는 pause 키가 존재했다. 그리고 컴퓨터가 동작 중일 때 키를 자꾸 눌러서, 처리되지 못한 키 버퍼가 꽉 차면 컴퓨터 차원에서 ‘삑삑’ 경고 beep음이 났다. 이거 기억하는 분 계시는가?

이 경고음을 마지막으로 들은 게 언제인지 기억도 안 난다. 하긴, 윈도우 9x의 BSOD도 아련한 추억이 돼 간다. 그 시절엔 그만큼 컴퓨터도, 운영체제의 구조도 단순했으며 컴퓨터의 전체 자원을 특정 프로그램이 순식간에 전부 장악하는 게 가능했다. 일부 게임을 실행하면 하드웨어를 이상하게 제어해서 pause 키가 안 먹히고 ctrl+alt+del도 안 먹히고, 심지어 caps/num lock 같은 키의 램프의 toggle도 안 되게 바뀌기도 했다.
지금은? 그렇게 한 프로그램에게 덥석 줘 버리기에는 컴퓨터의 성능과 자원이 너무 커졌고, 또 그걸 과거 컴퓨터와의 하위 호환성까지 최대한 유지하면서 제공하느라 구조가 더욱 복잡하기 짝이 없게 돼 있다.

Posted by 사무엘

오늘의 얘깃거리는 컴퓨터와 음악이다. 이 두 분야와 관계가 있는 옛날 소프트웨어들에 대한 추억도 곁들어질 것이다. 쓰다 보니 글이 꽤 길어졌다. ㄲㄲ

여기서 음악 파일이란, 말 그대로 음표 정보를 기반으로 음악을 연주하는 데이터를 말한다. 과거의 컴퓨터는 어마어마한 양의 waveform 데이터를 실시간으로 읽어들여(심지어 압축을 풀면서) 재생하면서 게임까지 원활하게 돌릴 정도의 성능을 갖추지 못했다. 그렇기 때문에 이런 가벼운 음표 기반 음악 파일이 각광을 받았다. 이런 파일은 크기가 아주 작은 데다, 또 음악은 반복되는 멜로디나 리듬이 많다는 특성상 압축률도 높았다.

※ 애드립 ROL, IMS

일명 FM(주파수 변조 방식) 사운드이다.
sound.com, unsound.com, 그리고 CGA 640*200이라는 흠좀무스러운 그래픽 모드에서 실행되던 애드립 Visual Composer (무려 1987년도 프로그램이다!).
standard.bnk, 이야기, implay 이런 것들을 기억한다면 당신은 진정 old timer 인증이다.

피아노, 바이올린, 색소폰 같은 현실의 악기와 비교했을 때는 분명 모자란 게 있지만 이 FM 음악은 나름 자신만의 개성과 색깔이 있었다. 단적인 예로, 과거 <그 날이 오면 3>의 환상적인 애드립 음악을 아직도 못 잊는 분들이 적지 않다.

FM 음악의 음색은 뱅크 파일에 별도로 담겨 있었다. 수백 개의 악기 음색이 100~200KB대 크기에 담겨 있던 걸로 기억한다. 음악에서의 악기는 문자 문서에서 일종의 폰트와 같은 존재인 셈이다.
PC 통신의 음악 자료실에는 최신 유행가, 팝송, 게임 음악 따위의 ROL/IMS 파일들로 넘쳐났다. 누군가가 악보를 구해다가 노가다로 열심히 입력해서 만들었을 것이다. IMS 파일은 당시 PC 통신 프로그램의 최강자이던 <이야기>가 지원했으니 인지도 면에서 더 말이 필요없었다.

이에 덧붙여 ISS라고 해서 가사 파일이란 게 국내에서 제정되었는데, 곡이 진행되면서 글자색이 점진적으로 변하게 할 수 있었기 때문에 일종의 노래방 효과도 낼 수 있었다. 동영상으로 치면 자막 파일과 같은 존재이다.

※ 모듈 S3M, MOD

모듈 음악 파일은 기본적으로 음표 정보 기반 음악 파일 포맷이긴 한데, FM 방식과는 중요한 차이가 있다. 악기의 음색이 waveform 오디오 형태로 파일에 내장되어 있다는 것. 문서로 치면 폰트를 일일이 내장하고 있는 셈이다. 그래서 평균적인 파일 크기는 기본이 수백 KB는 먹고 들어가기 때문에 mid나 애드립 사운드보다는 큰 편이지만, 당시로서는 가격 대 성능비가 아주 우수하고 음질이 좋은 음악을 만들어낼 수 있었다.

다만 모듈 음악은 여전히 음악보다는 컴퓨터 지향적인 방식이고, 미디처럼 세계 균일 표준으로까지 승격되지는 못해서 오늘날은 WinAmp나 VLC 같은 일부 매니악한 프로그램이나 재생을 지원하는 마이너 포맷으로 명맥을 유지하게 됐다.

애드립 음악에 Visual Composer가 있다면, 모듈 음악 분야에는 Scream Tracker라는 금색 UI를 갖춘 유명한 소프트웨어가 본좌이다. 그리고 재생기로는 Inertia player이라고 전설적인 도스용 프로그램이 있었다. 개발자가 밝히기를 100% 어셈블리만 써서 작성했다고 하니 흠좀무.

※ 대세는 미디

그 반면 오늘날 대세는 역시 국제 표준인 미디이다. 본인은 윈도우를 쓰기 전에 도스 시절에는 애드립이나 모듈 음악만 접했지 미디 파일도, 재생기도 전혀 접하지 못했다. 하지만 미디라는 표준 자체는 굉장히 오래 전에 제정된 것이다.

심지어 1989-90년대를 풍미했던 페르시아의 왕자의 midisnd.dat 같은 파일을 들여다 봐도, 내부는 윈도우 미디어 플레이어로 재생 가능한 표준 미디 파일들의 모음이다! 그래서 인트로/엔딩 음악, 죽었을 때의 음악 따위를 쉽게 추출할 수 있다.

도스용 둠 1, 2의 배경 음악도 내부적으로는 미디 포맷이다. 사실, 그 전작인 울펜슈타인 3D도 데이터 파일을 들여다보지는 않았지만, 음악을 딱 들어 보면 미디인게 티가 난다.

미디에는 구체적인 음색에 대한 규정은 전혀 없기 때문에, 과거 애드립으로 허접하게 재생되던 음악도 미디인가 하면 오늘날 최첨단 노래방 기기에서 코러스까지 곁들여져 나오는 음악도 죄다 미디이다. 과거에는 미디 음악을 컴퓨터에서 제대로 들으려면 미디 카드가 필수였지만, 컴퓨터의 성능이 향상되면서 2000/ME부터는 윈도우 운영체제가 좀 그럴싸한 미디 신시사이저 소프트웨어를 내장하게 되었다.

하지만 요즘 게임들은 음악도 닥치고 wav나 mp3 통째로 내장이다. DirectMusic이 괜히 개발이 중단된 게 아니다. 현업 게임에서 쓰이질 않고 있는 컴포넌트이기 때문.

※ 애드립 음악 관련 추억: 옹 컴포저

1998년의 일이다. 옹 언욱 씨라고, 본인보다 나이는 한 학년 위이고 당시 고등학생이던 분이 <옹 컴포저(Ong Composer)>라는 프로그램을 개발했다. 쉽게 말해 애드립 음악 파일 편집기이다. 그런데 이분은 프로그래밍은 물론이고 음악, 그래픽까지 두루 본인과는 비교가 안 되는 진정한 엄친아였다. 그 열악한 16비트 볼랜드 C++로 슈퍼 VGA 그래픽(선 그리기, 점 찍기, 비트맵 -_-)과 사운드 제어 루틴을 어셈블리로 다 자체 제작하고 GUI 라이브러리에 심지어 스킨까지 혼자 다 만들었다... ㅎㄷㄷㄷㄷ;; 난 그런 쪽은 쥐뿔도 실력이 없으니 전적으로 공개 라이브러리에 의존했는데 말이다. ㅋㅋ

참고로, 컴퓨터 음악 프로그램은 Noteworthy Composer처럼 작정하고 위지윅에 최적화된 프로그램이 아닌 이상, 우리가 흔히 생각하는 것처럼 오선지에 콩나물을 그려 넣는 형태가 아니다. 스프레드시트에다가 가로줄 길이로 음표를 표현하는 아주 기계 친화적인 모습을 하고 있다. 아까 언급한 Visaul Composer나 Scream Tracker도 마찬가지. 이는 프로그래밍 언어 소스 코드에 우리가 종이에다 쓰는 수학식이 그대로(근호, 분수 등) 들어가는 게 아닌 것과 같은 이치이다.

그런데 본인도 응시했던 1998년 제 15회 정보 올림피아드 공모 부문에서 옹 컴포저는 입상을 못 했다. 이런 어마어마한 프로그램이 왜 입상을 못 했는지는 모르겠다. 그러나 이듬해, 16회 대회에서 이분은 옹 컴포저를 윈도우용으로 포팅한 옹 컴포저 2를 출품하여 금상을 받는다. 그 후의 이분 근황은 본인도 알지 못한다. 프로그래밍에다가 탁월한 예체능(그래픽/음악) 쪽 재능을 갖춘 전문가이다 보니, 게임 개발에 뜻이 있는 분이던 걸로 기억한다.

덧붙이자면 15회와 16회 대회 때는 고등부에 대상 수상작이 없었다. 그 후 17회에서 본인이 출품한 한글 입력기 1.0 버전이 대상을 차지했다.

※ 모듈 음악 관련 추억: BWSB 라이브러리

BWSB (Bells, Whistles, and Sound Boards)라고 어느 영국의 프로그래머가 개발한 프로그래밍 라이브러리가 있었는데, 이게 정말 물건이었다. 퀵베이직, 파워베이직, 볼랜드 C/C++, 볼랜드 파스칼 등에서 모듈 음악을 재생해 줬다. 셰어웨어이긴 하지만 공개용도 프로그램 종료 시에 copyright 메시지가 뜨는 것 말고는 별다른 제약이 없었다. 굉장히 잘 만들었고 문서화도 서양식 유머가 가미된 재미있는 문체로 되어 있었다. "이런 주의사항을 지키지 않으면 외계인이 쳐들어와 당신의 컴퓨터를 가져가 버릴 것이다" 식.

이 분야에서는 거의 독보적인 라이브러리가 아니었나 싶다. 하지만 왓콤이나 DJGPP 같은 32비트 컴파일러를 지원하지 못했던 게 아쉬운 점으로 남아 있다. 어셈블리 튜닝 코딩이 많다 보니, 소스의 이식성이 떨어져서 포팅이 어려웠던 듯하다.
하긴, DJGPP용으로는 알레그로라는 만능 게임 라이브러리가 있긴 했는데 이건 모듈 음악은 지원 안 하고 미디만 지원했다. 알레그로도 영국 사람이 만들었다.

Posted by 사무엘