« Previous : 1 : ... 7 : 8 : 9 : 10 : 11 : 12 : 13 : 14 : Next »

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

2010/12/17 08:54 2010/12/17 08:54
, , ,
Response
A trackback , 13 Comments
RSS :
http://moogi.new21.org/tc/rss/response/432

컴퓨터가 글자가 아닌 그림을 처리하기에는 능력이 한참 부족하던 시절에, 벌써부터 포인팅 장비라는 개념이 있는 게 사용자 인터페이스 차원에서 좋겠다는 생각을 한 선구자가 있었다. 그게 한 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 사무엘

2010/11/11 13:51 2010/11/11 13:51
, , , , ,
Response
A trackback , 10 Comments
RSS :
http://moogi.new21.org/tc/rss/response/409

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

여기서 음악 파일이란, 말 그대로 음표 정보를 기반으로 음악을 연주하는 데이터를 말한다. 과거의 컴퓨터는 어마어마한 양의 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 사무엘

2010/09/27 16:10 2010/09/27 16:10
, , , , , , , , , , , , , ,
Response
No Trackback , 14 Comments
RSS :
http://moogi.new21.org/tc/rss/response/380

삭제되었수다!
Old timer PC 유저라면 지금도 기억에 남아 있을 만한 전설의 게임이다.
이 게임의 내력에 대해서 전부 떠벌리자면 좀 복잡하다.
그러나, “모든 일을 맨 처음부터 완전히 이해한 본인이, 이 블로그의 구독자인 여러분에게 그 내막에 대해 차례대로 글로 써서 알리는 것이 좋을 것 같아서”(눅 1:3) 몇 자 좀 끄적이도록 하겠다.

사용자 삽입 이미지

이 게임은 본디 1994~95년경, 당시 카이스트 학생이던 김 동건, 이 은석 님의 작품이다. 물론 이분들은, 지금으로부터 10년 가까이 전에 이미 넥슨에 입사하여 지금은 데브캣 스튜디오를 지휘하는 베테랑급 게임 개발자가 되어 있다. 모교로부터 초청을 받아 강연도 한 유명인사이다.
매우 황공스럽게도, 본인 역시 대학 시절에 이분과 메신저로 얘기를 나눈 적이 있고 이분들 초청으로 넥슨에 견학 간 적도 있다! 그게 2002년 가을의 일이다.

이 게임의 컨셉의 제일 원조는 1980년대에 일본 KONAMI에서 개발한 <그라디우스>라는 횡형 스크롤 슈팅 게임이다. 인삼을 여러 개 먹은 후 다양한 파워업을 고르는 시스템의 원조가 저것이라고 한다.
그런데 KONAMI는 훗날 그 게임의 시스템을 익살스럽게 바꿔 놓은 <패러디우스>(패러디-_-)를 내놓았고, 카이스트의 저 두 분은 그걸 또 패러디해서 ‘패러디우스’에서 착안, <85되었수다>라는 패러디 슈팅 게임을 만들었다. ‘패러디’가 ‘파로되’로 바뀌다니, 환상적인 작명 센스. ㅠ.ㅠ

게임에 등장하는 두 주인공 중 하나인 ‘할 박사’가 설정상 85세 노인이다. 그래서 85되었수다. ㄲㄲㄲ 그리고 또 하나는 ‘산소’라는 할 박사의 손녀딸이며, 18세 미소녀이다. 원래 게임은 어땠는지 모르겠지만, 저 게임에서는 세계 정복을 꿈꾸는 살모사라는 미친 과학자(mad scientist) 악당이 반란을 일으키고 자기 직장이던 카이스트부터 쑥대밭을 만들어 놓는다. 그래서 게임 주인공이 나서서 학교를 구하고 세계-_-를 구하는 것이 이 게임의 목표이다.

사용자 삽입 이미지

게임 개발은 순조롭게 진행되었고, 아마 스테이지 1이 끝나고 2를 만들던 중이었는데...
<85되었수다!>의 개발팀에게 악재가 닥친다. 사고로 컴퓨터를 망가뜨리는 바람에, 개발 중이던 소스를 날렸다고 한다. 흠좀무;; 결국 <85되었수다!>는 미완성인 채로 당시 주요 PC 통신에 공개되었고 개발은 중단되고 말았다. 스테이지 2 중반부터 더 진행이 안 되는 작품임에도 불구하고 PC 통신 자료실이나 심지어 게임 불법복제 CD 등으로도 퍼져 나갔다.

본인도 중학생이던 그 시절, 이 게임을 해 봤다. 오프닝 음악과 게임 줄거리 정도는 지금도 생생히 기억한다. 살모사 박사가 수감됐다가 탈옥한 것, 출동하는 주인공을 향해 “그나저나 할 박사, 올해 연세가 몇이지요?” 질문이 뜨고, 이때 “85되었수다” 로고가 딱 뜨는 것까지도 기억한다. 게임이 끝까지 제대로 완성됐다면 정말, “이거 내가 혼자(많아야 둘이서) 만든 게임이에요!” 한 마디면 어느 게임 회사에서도 스카웃 제의 받고 바로 입사할 작품이 되지 않았을까 싶다. 뭐 어차피 개발자 분들은 자기 적성에 맞는 좋은 직장에 이미 잘 들어갔지만 말이다.

그렇게 <85되었수다!>는 마무리가 되었는데,
그로부터 몇 년 정도 시간이 지난 1997년, PC 통신 하이텔의 게임 제작 동호회(go GMA)에서 제 1회 아마추어 게임 공모전을 개최했다.
그런데 여기에는, 출품한 작품의 총용량이 압축했을 때 100KB 이내에 들어야 한다는 조건이 붙었다. 지금 생각하면 정말 상상도 할 수 없는 작은 공간이지만, 그때는 그것 갖고도 별 걸 다 만들었다.

이때 <85되었수다!>의 제작진이 옛날 레퍼토리를 리메이크했다. 소스를 날렸다고 했으니, 기존 게임의 리소스만 가져다가 코딩을 다시 한 모양이다. 그런데, 용량 100KB를 맞추느라 게임 데이터를 곳곳에서 가위질을 해야 했다. 그래서 게임의 제목이 또 패러디되어 바뀌었다. <삭제되었수다!>라고 말이다. ㅋㅋㅋㅋㅋ

그래서 옛날 게임 시스템과 리소스를 기반으로, ‘패러디에 패러디’를 거듭한 끝에 <삭제되었수다!>라고 나름 스테이지도 5개까지 있는 완성된 게임이 만들어졌다.
그 시절, 본인은 비록 완전 허접 눈팅 유령 회원이긴 했지만, 나름 하이텔 게제동의 회원이었고 그 공모전이 진행되던 과정을 모두 지켜볼 수 있었다.

이 게임은 의심의 여지 없이 다른 출품작들을 제치고 대상을 받았다.
기술적인 면이나 그래픽, 게임성이나 모든 것이 아마추어를 넘는 프로급으로 손색이 없었다.
공모전은 이듬해에 2회까지 한 후 그 후로 더 진행되었다는 소식을 못 들었다. 그 무렵부터 PC 통신 자체가 인터넷에 밀려 슬슬 빛을 잃기 시작하기도 했고 말이다. 그랬으니 1회의 당당한 대상 수상작인 <삭제되었수다!>가 더욱 부각되어 보일 수밖에 없었다.

다음으로, 조금 기술적으로 디테일한 부분을 얘기하고자 한다.
이 게임은 볼랜드 C++ 3.x로 빌드된 16비트 도스용 프로그램이다. 그런데 메모리, 그래픽, 사운드 등 모든 하드웨어 제어 루틴을 어셈블리로 다 자체 제작했다. 대체 하드웨어를 어떻게 제어하기에, 윈도우 95의 도스창에서는 실행할 수 없고 무조건 순수 도스로 빠져나가야 했다.

더욱 놀라운 것은 게임이 실행되는 모드이다. 본인은 1990년대의 도스용 게임들이 다 채택하던 VGA mode 13h 320*200 256색이라고 당연히 생각했는데, 그게 아니었다. 더 작은 256*200이었다. 가로· 세로의 aspect ratio가 좀더 균형 잡힌 모드를 의도적으로 선택한 건지는 모르겠는데, 문제는 저런 해상도는 쉽게 진입할 수 있는 모드가 아니라는 것. VGA mode X라고 해서 90년대 중반에 ID 소프트웨어의 마이클 압래쉬 같은 프로그래머나 특수한 용도로 사용했던 기법이 동원된 것이다.
그런 게임을 만든 사람이 나온 대학을 약 3년 남짓 뒤에 본인도 가게 되었으니 이 또한 감개무량했다.

참고로, 그 1997년도 대회에서 <삭제되었수다!>에 이어 금상을 받은 작품은 안 영기(SMgal) 님의 <대변 파이터>이다. 이것도 각종 PC 통신 자료실에 많이 퍼졌다. 이분은 파스칼/델파이 프로그래머로 날리던 분이어서 그 게임 역시 C/C++이 아닌 파스칼로 개발되었다. 하드웨어 제어라든가 게임 개발 쪽의 달인인 것도 매한가지인지라 이분도 지금까지 게임 개발 업종에 종사하고 있다. 나이나 경력이나 인상이 여러 모로 박 정만(옛날에 하이텔 세벌식 사랑 모임 동호회 대표) 님과 비슷한 분 같다.

<대변 파이터>도 주인공이 비행기가 아니라 사람인 것만 빼면, 일종의 횡형 스크롤 슈팅 게임.
그러고 보니 1990년대 전설의 명작 국산 게임인 <그 날이 오면 3>도 횡형 스크롤 슈팅이고, <삭제되었수다!>나 <대변 파이터> 같은 명작 게임이 다 이 장르라는 게 무척 흥미롭다.

그러나 본인은 총알 피하는 건 영 소질이 없다. 특히 체력(hit point)이라는 게 없이 부딪치기만 해도 즉사하는 게임은 겁이 나서 원...
슈팅이라는 장르는 내 타입이 아닌 것 같다. 지인 중에는 반대로 총알 피하는 게임만 즐기는 친구도 있지만... ㅋㅋ <그날이 오면>, <-되었수다!> 모두 너무 어려워서 혼자서는 스테이지 2도 못 깬다.

본인은 게임은 하지도 않고 개발에도 그렇게 별 관심이 없다. 그냥 타자 게임 정도가 고작..;; 하지만 거기에 들어가는 배경지식과 스킬은 기회가 되면 익히고 싶다. 지금은 이제 운영체제가 기본으로 제공하는 카드놀이, 지뢰찾기 같은 게임마저도 3D로 만들고, 아예 GDI조차 Direct3D 계층 위에서 돌아가는 세상이 됐으니 말이다.

Posted by 사무엘

2010/08/24 08:44 2010/08/24 08:44
, , , , ,
Response
No Trackback , 5 Comments
RSS :
http://moogi.new21.org/tc/rss/response/355

인터넷 격세지감

1.
1996년이던 걸로 기억한다. 본인이 중학생이던 시절, 경기 과학 고등학교가 TV 방송으로 소개되는 걸 봤다.
'경곽'이라는 애칭으로 불리는 이 학교는 우리나라에서 최초로 개교한 과학고이기도 하다. (서울 과학고가 최초가 아니다)
그런데 그 당시 학교의 자랑이랍시고 흘러나온 멘트 중 하나가 무엇이냐 하면, "우리 학교는 인터넷 전용 회선이 갖춰져 있고 전교생이 인터넷 다룰 줄 안다" 였다. ㅜ.ㅜ "전교생이 이메일 계정 갖고 있다"란 말도 했던가?

1993-4년이 CD롬, 사운드 카드를 위시한 멀티미디어 시대였다면, 1996-7년이 이제 막 윈도우 95가 보급되면서 인터넷, 멀티넷 이러면서 제대로 떠들던 시절이었다. ^^;;
요즘은 "전교생에게 노트북 지급하고, 학교 전구역에서 무선 인터넷 된다" 정도는 돼야 자랑거리가 될 것이고, 그게 그렇게 큰 자랑거리도 못 될 것이다.

하긴, 본인도 전화(모뎀)가 아닌 전용선 인터넷 자체를 고등학교에서 처음으로 접했으며 이메일 계정이란 걸 처음 만든 것도 고등학교에 들어가서였다. 중학교 때 PC 통신, 고등학교 때 인터넷, 대학교 때 휴대전화 순으로 문명의 이기를 접해 왔다. 정보 사냥(검색) 대회라는 게 사라진 게 언제쯤이더라? ^^

2.
2002-3년 사이인 걸로 기억한다. 그 무렵에 TV 도전 골든벨 프로를 봤는데, 맨 마지막 50번 문제가 무슨 IT 용어를 묻는 것이었다. 마지막까지 남았던 여학생은 그 문제를 못 맞혔다.
그런데 그 문제의 답은 바로...

'블로그' 였다. ㅜ.ㅜ
그때까지 블로그라는 단어는 본인조차 듣도 보도 못한 생소한 용어였다. 지금은 블로그도 모자라서 트위터 같은 마이크로블로그까지 등장해 있는데도 말이다. ^^
저 때는 근성 충만한 IT계 초 얼리 어답터, 파워 유저들이나 블로그를 했지, 나머지 대다수는 나모 웹에디터 HTML 글자판때기 코딩으로 홈페이지를 만들거나, 아니면 싸이 내지 아이러브스쿨, 다모임 같은 것밖에 안 하던 시절이었다. 아울러, 소리바다가 아직 있던 시절.

그러다가 그 비슷한 시기에 네이버에서 지식(인) 검색이라는 걸 만들어서 대박을 냈고, 한국의 인터넷 문화를 뒤집어엎었다. 엠파스에서 자연어 처리 / 질문 문장 검색 비슷한 서비스를 하긴 했는데 그걸 네이버가 더욱 발전시킨 걸로 알고 있다. 야후, 알타비스타, 심마니 같은 초창기 검색 엔진들을 다 골로 보냈다.
나중에는 카페, 블로그 서비스까지 만들면서 네이버는 다음 같은 종합 포탈 사이트로 거듭난다. 맞춤형 홈페이지(myhome) 서비스는 꽤 오래 전에 중단했다.

2002-3년이면 아직 구글도 국내에서 파워 유저가 아닌 계층에서는 완전 듣보잡이던 시절이었다. 외국 사이트는 잘 찾았지만, 내 이름을 한글로 쳐 보면, 온갖 인명들을 검색에 걸리라고 일부러 수집해 놓은 쓰레기 성인 사이트들만 잔뜩 뜨던 걸 아직도 기억하고 있다. ^^;;

Posted by 사무엘

2010/07/31 16:20 2010/07/31 16:20
,
Response
No Trackback , 4 Comments
RSS :
http://moogi.new21.org/tc/rss/response/335

1. IE-only 사이트들

세상엔 아직도 크롬/파폭 같은 비 IE 브라우저에서는 웹사이트 레이아웃이 깨진다거나, 특히 플래시 메뉴 같은 걸 클릭해도 반응이 없는 안습한 웹사이트가 적지 않다.
사실은 플래시가 아닌 메뉴 중에도 비 IE에서는 동작하지 않는 게 있다.
이런 건 주로 무슨 표준을 안 지키고 뭘 잘못 만들어서 그런 건지 개인적으로 굉장히 궁금하다.
ActiveX 같은 걸 쓴 것도 아니고 순전히 자바스크립트 같은 다른 계층의 문제일 것이다. 네이티브 코드를 실행 안 하면 절대 안 되는 상황도 아니며, 코드를 약간만 수정해 주면 의외로 금방 문제를 해결할 수도 있어 보이는데 그저 안타까울 뿐이다.

2. 이런 메뉴 디자인은 최악

그리고 이건 브라우저 호환성 문제는 아니고 웹 디자인과 관련된 다른 얘기.
마우스로 어떤 메뉴를 가리키고 있으면 하부 메뉴가 아래에 뜨고, 그 하부 메뉴를 클릭했을 때 다른 웹페이지가 뜨는 구조인 플래시 메뉴를 생각해 보자. 우리에게 아주 익숙하다. 그런데, 하부 메뉴가 세로가 아니라 주 메뉴와 같은 형태인 가로로 길쭉하게 나타나는 사이트가 많다. 가령,

[ 회사소개 ] | 제품소개 | 커뮤니티 | 사이트맵
회사는  / CEO 소개 / CI 소개 / 조직 구성 / 찾아오시는 길

같은 식.
그런데 굉장히 불편할 때가 언제냐 하면,
마우스 포인터가 { 회사는 ... 찾아오시는 길 } 이라는 하부 메뉴 영역의 위나 아래로 조금만 벗어나도 그 하부 메뉴가 싹 사라져 버릴 때 말이다. -_-++++++;;;

자, [회사소개]를 가리켰다가 저 끝의 [찾아오시는 길]을 선택하는 게 아주 고역이 아닐 수 없다. 차라리 세로로 길쭉해서 하부 메뉴가 가로와 세로로 모두 충분히 공간이 있다면 모를까 저건 좀...;;;
[조직 구성]까지 갔다가 실수로 마우스 포인터를 아래로 옮기면 하부 메뉴가 사라져 버리고, 그럼 다시 [회사소개]를 가리키러 마우스 포인터를 옮기는 삽질을 해야 한다.
그런 메뉴는 좀 하루빨리 시정됐으면 좋겠다.

3. ActiveX

인터넷 세계에서 평생까임권을 획득한 존재이다. 물론 ActiveX의 존재라든가 취지 자체가 악의 축이라고 몰아붙이는 건 좀 억울한 면, 오해가 있는 면도 있다.
2000년대 초까지만 해도 인터넷 상으로 동영상 하나 보려고 해도, 아니면 게시판용 위지윅 HTML 에디터를 좀 붙이려고 해도 온갖 듣보잡 ActiveX 없이는 안 됐었다.
동영상이야 플래시가 2005년쯤부터 완전히 접수해서 여타 플레이어들을 발라 버린 덕분에 게임이 끝났다. 사실은 플래시 자체도 ActiveX이지만 이 녀석은 쓰임이 워낙 범용적이고 전세계 PC에 널리 퍼진지라 예외로 인정되는 인터넷 필수 구성 요소가 되었을 뿐이다.

그 반면 HTML 에디터는 무척 놀랍다. 블로그의 등장과 이것 때문에 평범한 양민이 HTML 코딩으로 홈페이지 만들 일이 완전히 없어졌으며, 덕분에 로컬 환경에서 네이티브로 동작하는 웹에디터는 떡실신하고 만 것이다. 간단한 HTML 위지윅 에디터는 심지어 비주얼 스튜디오 같은 개발툴조차 내장하고 있다. 그러니 기존 웹에디터는 아예 웹사이트 관리자 아니면 HTML 기반 도움말 저작도구로 더 전문적으로 변모하지 않으면 안 되게 구도가 바뀌었다.
요즘은 게시판 하나 만들려고 해도 HTML 에디터는 필수이다. 그런 점에서 그냥 plain text 입력 폼만 덩그러니 뜨는 제로보드 4는 엄청 캐안습 구닥다리이다.

웹에서 돌아가는 위지윅 HTML 에디터가 정착해 가던 과도기에는 이랬다. 그나마 조금 배려를 했다는 사이트는 IE에서는 full feature 위지윅 에디터가 뜨고, 여타 브라우저에서는 그냥 plain text만 입력할 수 있는 에디터가 떴었다. 본인의 주 메일 계정인 드림위즈의 이메일 작성 UI가 한 2, 3년 전까진 딱 그랬었다. plain text only -> IE만 위지윅 에디터 -> 다 위지윅 에디터의 식으로 발전하여 요즘은 어디서나 위지윅 에디터 제공.

요즘은 저렇게 동영상에, 위지윅 에디터에, 어지간한 암호화까지 웹 표준이 커버하는 분야가 크게 늘어난 덕분에 웹 상으로 굳이 네이티브 코드를 소환할 일은 점점 줄어들고 있다. 인터넷 상으로 내 컴퓨터 시스템 정보를 표시해 준다거나, 진짜로 키보드 드라이버 차원의 보안을 구현한다거나, 설치되어 있는 소프트웨어 정보를 레지스트리 정보를 통해 파악한다거나.. 그 정도가 아니라면 말이다.

2000년에 처음 개발된 <날개셋> 한글 입력기 1.x는 무려 ActiveX로 만들어졌었다! -_-;;;
아직 정식 인스톨러 패키지도 없던 시절에 도스창에서 regsvr32 해 주고 <날개셋> 편집기를 구동해서 세벌식 모아치기를 쓰던 시절을 기억하거나 겪어 본 분이 독자 중에 얼마나 있을까? ㅋㅋㅋㅋ
그때 본인은 <날개셋> 자체 에디트 컨트롤을 ActiveX로 만들면 비주얼 베이직이나 심지어 웹브라우저에서도 그대로 연동 가능하다고 해서 그냥 시범삼아 그 테크닉을 써 본 것이다. 그때는 아직 인터넷 상으로 ActiveX 컨트롤 자체를 보기 힘들었고 그게 지금처럼 악의 축으로 문제되기도 전이었다. 오픈웹 운동 나부랭이 따위도 없었다. 그랬는데... 세월 참 많이도 흘렀다.
그러다 2.0부터는 그냥 일반 윈도우 컨트롤로 바뀜.

4. 운영체제 재설치

본인은 가상 머신이 아닌 실제로 사용하는 개인용 컴퓨터의 운영체제를 마지막으로 재설치한 건... 무려 2007년 초쯤이다. 3년이 넘게 윈도우 설치 화면을 볼 일이 없이 지냈으며 앞으로도 당분간 볼 일이 없을 것이다. 본인 노트북은 꽤 오래 전부터 CD롬 드라이브가 고장났으나, 이것도 쓸 일이 없으니 고칠 일도 없었다. 요즘 컴퓨터는 아예 USB 메모리로도 부팅 가능하다고 하는데, 아무리 그래도 그렇지 부팅이 가능하려면 파일 시스템 차원에서 프로그램 파일이 아주 특수하게 기록되어 있어야 하지 않나? 어떻게 그게 가능한지 궁금하다.

마지막으로 윈도우를 재설치하던 3년 반 전에는 XP를 쓰고 있었는데, 그때는 운영체제가 확실하게 맛이 가 있었다. 딱히 악성 코드나 바이러스에 걸린 것도 아니었는데 언제부턴가 제어판의 일부 구성 요소가 제대로 안 나오고, 뭔가 전반적인 성능이 떨어진 느낌이 들고.. 내가 아무리 컴퓨터 유지 보수를 귀찮아하는 게으른 타입이라 해도 이건 인간적으로 OS를 정말 재설치해야 한다는 신호라는 느낌이 팍팍 들었다. 그래서 하드를 포맷해 버렸다.

하지만 점점 운영체제의 자가 관리 능력이 향상되면서 하드를 포맷하고 운영체제를 재설치해야 할 일은 줄어들고 있다는 느낌이 든다. 아직 비스타를 3년이 넘게 써 보지는 못했으나, 굉장히 안정적이라는 건 느낀다.
다만, 각종 업데이트와 패치를 설치하면서 디스크 용량이 줄어드는 건 어쩔 수 없는 듯.
윈도우를 새로 설치하면 그때까지 누적되어 있던 온갖 업데이트, 서비스 팩들도 다 원점으로 돌아가니 안습이다. 업데이트 내역만 쉽게 export/import하는 방법이 있었으면 좋겠다.

Posted by 사무엘

2010/07/27 08:37 2010/07/27 08:37
, , , , ,
Response
No Trackback , 9 Comments
RSS :
http://moogi.new21.org/tc/rss/response/331

그동안 폐쇄적인 파일 포맷 정책 때문에 욕 많이 얻어먹고 있던 한컴에서 최근에, 한 지난달 말부터 꽤 놀라운 결정을 내렸다. 아래아한글의 파일 포맷(.hwp)을 드디어 정식 공개한 것이다. (뭐, 그렇다고 해서 한컴도 먹고 살아야지, 그런 회사에게서 MS나 구글 정도의 대인배 기질을 바라는 것도 세상 물정 모르는 개념 없는 소리이긴 하다.)
워디안 시절부터 지금까지 쭉 사용되어 오고 있는 소위 5.0 포맷과, 지금은 이미 완전 역사 속의 유물이 되어 버린 과거의 97 방식(3.0 포맷) 이렇게 둘을 공개했다.

본인이 아래아한글에 대해서 무척 대단하게 생각하고 있는 면모는, 지금의 파일 포맷이 미래 확장성을 대비해서 정말 대인배스럽게 잘 설계돼 있다는 점이다. 아래아한글 2010 정도면  MS 따라 hwpx-_- 같은 새로운 파일 포맷을 도입해도 이상할 게 없을 거라고 생각했는데 여전히 10년 전 포맷 그대로이다. 이 정도면 과거 MS 워드가 97부터 2003버전까지 사용한 구식 doc/xls/ppt 포맷의 짬밥을 훨씬 능가한다.

그 10년 동안 아래아한글엔 세로쓰기를 비롯해 문서의 기본 골격을 완전히 바꾸는 새로운 기능들이 상당수 추가되고, 무엇보다도 문자 인코딩이 마구 바뀌어 왔다. 유니코드 surrogate가 지원되기 시작한 게 2004부터이고, 아랍/히브리 complex script가 지원되기 시작한 게 2005부터이다. surrogate 지원 전에는 Yi 문자 같은 영역에다가 아래아한글 특수문자를 제멋대로 집어넣기도 했다.

특히 문제는 한자. 아래아한글이 과거의 한컴 2바이트 코드에서 자체 제공하던 제 2수준 한자 중에는 유니코드 BMP 영역의 한중일 통합 한자에 존재하지 않는 녀석이 극소수 있었다. 그건 처음엔 사용자 정의 영역으로 가 있었는데 일부는 나중에 surrogate에 있는 유니코드 “한중일 통합 한자 확장 B/C”에서 정식 추가되기도 했다. 흠좀무..;; 끝으로, 2010 버전부터는 옛한글도 과거 10년간 이용해 비표준 한양 PUA를 버리고 드디어 유니코드 5.2 표준으로 돌아갔다!

이 정도면 문자 인코딩도 버전 관리를 해야 할 지경이지 않은지? 또한 이제 워디안 시절의 10년 전 파일 포맷은 효율이 상당히 떨어졌으며, 굳이 하위 호환성을 지키려 애쓰는 것도 무의미해지지 않았나 하는 생각이 든다.
뭐, 비록 워디안은 너무 불안정해서 사용자들로부터 완전히 발렸지만, 2002는 아직도 관공서 같은 곳에서 쓰는 사람이 있지 싶다-_-. 특히 2002 SE는 윈도우 운영체제로 치면 마치 98 SE 같은 안정화 버전이었기 때문이다.

그나저나, 아래아한글은 같은 문서를 저장해도 파일 크기가 은근히 굉장히 커져 왔다. 가령, 과거 아래아한글 2002에서 작성한 hwp 파일을 2007에서 열어서 아무 수정 없이 그냥 다시 저장만 해도, 파일 크기가 꽤 커진다. 특히 더 옛날의 97 방식 hwp와 비교해 보면, 지금 hwp 파일은 진짜 비교도 안 될 정도로 크기가 더 커졌으며, MS 워드의 doc나 docx와 비교해도 마찬가지이다.
아무 서식이나 고급 기능을 안 쓰고 글만 빽빽한 문서를 작성했는데도 파일 크기가 너무 커졌다는 느낌을 지울 수 없다. 압축을 물론 했는데도 그 정도.

사실 이건 MS 오피스 제품도 마찬가지여서 똑같은 doc/xls/ppt도 2003에서 작업한 파일을 2007에서 불러와서(물론 호환성 모드) 다시 저장하면 크기가 꽤 커진다. 2003에서는 인식되거나 사용되지 않는 여러 메타 정보가 추가되어서 그런 것 같다.
그나저나 참고로, 2007 방식이라고 해도 암호가 걸린 문서 파일은 xml+zip 압축 포맷이 아니며, 과거 2003 같은 복합 바이너리 포맷으로 저장된다.

본인은 아래아한글을 버릴 수 없는 처지에 있는 사람이다. 도저히 적응이 안 되는 MS 워드의 기괴한 동작 방식, 그리고 손에 너무 익어 버린 단축키, 그리고 과거의 수많은 hwp 문서와 절대로 버릴 수 없는 hft 글꼴들 때문에 아래아한글은 탄탄한 기득권을 갖추고 있다. 또한 한컴도 이윤을 창출해야 하는 기업이라는 것 역시 모르는 바 아니다. 앞으로도 너무 심한 병크만 터뜨리지 말고 아래아한글을 잘 유지 보수해 줬으면 좋겠다.

Posted by 사무엘

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

1. undelete (노턴 유틸리티의 unerase)

그렇다. 도스 시절에는 지금처럼 휴지통이라는 개념이 없었다. FAT 파일 시스템에서 파일 삭제는 파일 이름의 첫 글자만 ?로 바꿔서 지워진 것처럼 속이는 작업이었기 때문에, 그런 파일을 찾아내어 첫 글자를 지정해 주면 지워진 파일을 살릴 수 있었다.

그러나 이것은 100% 완전히 복구된다는 보장이 없었다. 본디 파일이 있던 위치에 다른 파일이 덮어써지면 파일이 소실되거나 심지어 다른 파일 내용과 충돌이 일어날 수 있었다. 이건 또한 보안상으로도 굉장한 허점을 남기는 위험한 일이며, 옛날 도스 시절에 운영체제나 파일 시스템이 지금보다 훨씬 더 단순할 때나 통용되던 편법에 불과했다.

2. sort (노턴 유틸리티의 ds)

요즘 우리가 매일 사용하는 탐색기나 여타 파일 관리 유틸리티들은 파일 목록을 보기 좋게 잘 정렬해서 보여주지만 DIR을 쳐서 나타나는 파일 목록은 그렇지 않았다. 말 그대로 디스크에 저장된 순서대로 저장된 파일 목록을 보여줄 뿐이었다. 그래서 디스크에 보관되는 파일 목록 자체를 ABC 순으로 정렬해서 재기록해 주는 별도의 유틸리티가 있었다. 그것도 하위 디렉토리들까지 재귀적으로 알아서 말이다.

하지만, 오늘날 윈도우 NT 계열이 사용하는 NTFS 파일 시스템은 자체적으로 파일 목록을 알아서 ABC 순으로 무조건 정렬해 놓으므로 그런 유틸리티가 무의미하고 불필요해졌다. 내부적으로 단순 연결 리스트가 아니라 tree 같은 자료 구조를 쓰는 듯하다. 과거의 윈도우 9x와 윈도우 NT는 아무 디렉터리에서나 DIR만 쳐 봐도 결과가 차이가 났던 것이다.

지금도 FAT32를 쓰는 플래시메모리를 꽂아서 DIR를 해 보면 차이를 알 수 있다. 하드디스크는 파일 목록이 ABC 순으로 출력되는 반면, 플래시메모리는 그렇지 않다.

3. 디스크 검사 (노턴 유틸리티의 NDD)

요즘 애들은 디스크 드라이브가 A부터 시작을 안 하고 왜 C부터 시작하는지 이유를 모를 것이다. 옛날 A와 B를 차지하고 있던 플로피디스크는 용량 적고 느린 건 둘째치고라도 물리적인 에러가 정말 잘 났다. 이 디스크 에러 내지 데이터 에러는 도스가 간단히 에러 메시지만 뱉고 끝내는 게 아니라 꼭 A중단, R재시도, I무시 같은 더 끈질긴(?) 인터페이스로 대응했기 때문에 더욱 무섭기도 했다.

그래서 그 시절에 디스크 검사 유틸리티는 필수였다. 물리적인 에러가 난 부위는 bad sector로 처리하여, 거기를 건드리다가 운영체제가 에러 메시지를 뱉는 일이 없도록 조치를 취해 줘야 했다.

과거에 하드디스크 용량이 한 수백 MB대일 때까지는 하드디스크도 NDD를 돌려볼 만했다. 그러나 그 이후부터는 디스크 검사라는 게 의미가 없어졌다. 에러가 거의 없어지기도 했고, 또 디스크 용량도 너무 커졌기 때문이다.

4. 디스크 조각 모음 (노턴 유틸리티의 SPEEDISK)

오늘날 존재하는 디스크의 모든 파일 시스템들은 어떤 형태로든 정기적인 조각 모음(defragmentation) 작업이 필요하다. 데이터베이스 파일도 그렇고, 가상 머신 이미지 파일도 그러하다. 그렇기 때문에 조각 모음은 과거 도스 시절만의 잔재는 아니며, 윈도우 XP까지도 별도의 시스템유틸리티가 존재했다.

비스타부터는 idle time 때 조각 모음을 운영체제가 알아서 지능적으로 찔끔찔금 하는 형태로 바뀌어, 덕분에 사용자가 이런 걸 신경쓸 필요가 사실상 없어졌다. 지금은 옛날 같은 방식으로 조각 모음을 하기에는 하드디스크 용량이 커져도 너무 커졌고, 또 SSD 같은 디스크는 아예 내부 특성상 전통적인 의미의 조각 모음을 해서는 안 되는 물건이기도 하다. 세상이 그만치 많이 변했다.

윈도우 95를 설치해 놓고 도스용으로 만들어진 디스크 조각 모음을 실행하면 긴 파일 이름이 싹 다 날아가고 대략 패닉이 벌어졌다.
그뿐만이 아니라 그 상태에서 undelete라든가 디렉터리 정렬 같은 저수준 작업을 시도하면 emm386 같은  메모리 드라이버가 에러를 내면서 컴퓨터가 그냥 다운되어 버리기도 했다. 오늘날은 과거 노턴 유틸리티의 DISKEDIT 같은 무식한 저수준 유틸리티가 돌아가는 건 절대 권력 운영체제가 허락하지 않을 것이다.

도스와 윈도우 9x 시절의 잔재라 할 수 있는 FAT 파일 시스템의 역사를 간략하게 소개하며 글을 맺는다.

FAT12: MS 도스 초창기에 도입. 플로피디스크용이며, 인식 가능한 하드디스크 용량은 최대 32MB.
FAT16: MS 도스 4.0(무려 1988년)에서 도입. 디스크 용량의 이론적 한계치가 2GB로 증가

FAT32: 윈도우 95 OSR2에서 도입(1996년). 최대 용량이 테라바이트급으로 늘긴 했으나, 파일 하나의 최대 크기는 여전히 4GB 제약을 받으며 디스크 용량이 수십, 수백 GB에 육박하면 슬슬 불안정해진다. NTFS로 갈아타는 게 낫다.
exFAT: 윈도우 비스타 SP1에서 도입(2008년). 플래시메모리 구조에 최적화되었고 파일 1개의 4GB 제약도 없어졌다고 함.

Posted by 사무엘

2010/07/14 11:09 2010/07/14 11:09
, ,
Response
No Trackback , 4 Comments
RSS :
http://moogi.new21.org/tc/rss/response/320

※ 메신저

상대방에게서 마지막 대화가 도착한 지 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 사무엘

2010/07/06 09:07 2010/07/06 09:07
,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/312

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

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

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

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

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

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

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

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

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

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

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

Posted by 사무엘

2010/07/05 08:30 2010/07/05 08:30
, ,
Response
No Trackback , 4 Comments
RSS :
http://moogi.new21.org/tc/rss/response/311

« Previous : 1 : ... 7 : 8 : 9 : 10 : 11 : 12 : 13 : 14 : Next »

블로그 이미지

그런즉 이제 애호박, 단호박, 늙은호박 이 셋은 항상 있으나, 그 중에 제일은 늙은호박이니라.

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2024/11   »
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30

Site Stats

Total hits:
2989268
Today:
828
Yesterday:
1477