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

삭제되었수다!
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

1.
지난 5월 말, 석가탄신일 연휴 때 고향에 가서 부모님께서 쓰시는 컴퓨터를 여러 군데 손 봤다. XP 정도나 돌릴 수 있는 구형 컴퓨터이다. 내가 없는 사이에 컴퓨터 A/S를 받아서 하드를 포맷하고 운영체제를 새로 설치했다고 하던데, 파일 시스템이 웬 생뚱맞게 FAT32로 되어 있어서 당장 NTFS로 바꿨다.

그리고 드디어 IE7을 설치했다. 부모님의 반응은 “서울 컴퓨터와 같은 인터페이스이구나”였다. 내가 있는 곳에서는 XP가 없고 비스타만 있기 때문이다. 탭을 지원하고 메뉴가 기본적으로 숨어 있는 IE7의 외형과, 그렇지 않은 IE6의 외형은 부모님이 보시기에도 차이가 명백했던 것이다.

때가 2010년인데 IE8이 아닌 IE7을 선택한 이유는 짐작하다시피 병맛 같은 국내 사이트 때문이다. 교사가 쓰는 컴퓨터에다 NEIS가 안 돌아가는 브라우저를 설치할 수는 없는 노릇이고, 본인 역시 IE8을 비스타 64비트에서 한번 설치해 봤다가 국민 은행 뱅킹이 에러 메시지도 없이 그냥 전혀 동작하지 않는 걸 보고, 혼비백산하여 곧바로 IE7로 복귀해야만 했다. 본인의 개인 노트북에만 IE8을 설치해 쓰는 중이다.

IE8이 IE7보다 그렇게도 가벼워지고 성능이 향상되고 ACID 지수도 올라갔다고 하는데 본인은 거기까지는 잘 모르겠다. 그저 탭의 윗부분 색깔이 colorful해졌다는 차이밖에 안 보인다. 세월이 흐르면서 본인은 얼리 어답터 기질은 다 죽어서 업데이트 같은 걸 귀찮아하는 타입. O<-<

그럼에도 불구하고 본인이 지금까지 서울 각지에서 이용해 본 PC방들은 어쩜 이리도 한결같이 IE6을 쓰고 있으니 과연 충격과 공포이다. 각종 통계에 잡히는 IE6 사용자들의 상당수가 PC방이 아닐까 하는 생각이 들 정도였다.
윈도우 XP sp3이면 어차피 IE8까지 돈도 안 들이고 업그레이드 가능한데 왜 이런 투자에 인색한 걸까?

여기서 IE의 역사를 좀 살펴보자. 1은 가히 듣보잡이고, 2는 윈도우 95 번들로 제공된 최초의, 그러나 정말 빈약한 버전이었다.
3은 드디어 넷스케이프 3과 맞장뜨기 시작한 버전인데, 넷스케이프의 플러그 인에 대응하여 ActiveX를 최초로 내장했다. IE3은 MS가 개발한 프로그램 중 전무후무하게 toolbar에 텍스처가 존재했으며, 마우스가 가리키고 있는 버튼에만 윤곽이 나타나는 소위 flat 스타일 toolbar를 최초로 도입한 프로그램이었을 것이다. 나름 산뜻한 외형을 지향했다는 뜻.

오늘날의 IE의 근간이 잡힌 건 4부터이다. HTML 도움말, 액티브 데스크톱 같은 갖가지 기술이 이때 첫 도입됐다. 5에서는 complex script, global IME 등 다국어 처리 능력이 크게 강화된 걸로 기억하며, 무려 윈도우 3.x를 지원한 마지막 버전이다. 그 이후의 버전에 대해서는 설명을 생략하겠다.

윈도우 XP와 같은 시기에 출시된 IE6이 수 년간 엄청 장수하고 독점적인 지위를 누리면서, MS에서는 이제 IE 팀을 해체할까 하는 생각까지 했다고 하는데 흠좀무. 그러던 차에 2004년 가을을 생생히 기억한다. 모질라 재단에서 파이어폭스라는 획기적인 브라우저를 내놓으면서 현재까지 IE의 독점 구도를 크게 무마하는 데 성공했다. 오늘날은 잘 알다시피 구글 크롬까지 빠른 속도를 강점으로 승부 중이다.

2.
오늘날처럼 블로그나 트위터 같은 게 생기기 전, 너도 나도 나모 웹에디터 같은 프로그램으로 아기자기한 홈페이지 만들던 시절이 있었다. 딱 그런 옛날 스타일 홈페이지를 보면 감회가 새롭다. 애니메이션 gif, 아주 초보적인 수준의 플래시, 그리고 테크노트나 제로보드 기반 게시판들. 본인이 학창 시절 때 몇몇 선생님들이 만든 홈페이지가 아직도 그런 스타일이다. 옛날 생각이 난다.

본인이 인터넷이란 걸 처음 접한 게 1997년 말이다. 내가 저장해 놓은 적이 없는 새로운 글과 그림이 화면으로 쏟아져 나오는 게 이리도 신기할 수 없었다. 그때 조선일보던가 MBC던가.. 국내 언론사들은 웬 VivoActive player라는 듣보잡 ActiveX로 동영상도 보여주곤 했다. 물론 지금과는 비교조차 할 수 없는 열악한 화질이었지만 말이다. 그때는 RealAudio/Video도 있었으나, 컴퓨터와 네트워크 속도의 향상 덕분에 이내 mp3 등에 캐발리고 말았다. 그리고 얼마 안 가 넷스케이프도 IE에 완전히 발린다.

3.
맥 OS에는 애플에서 자체 개발한 사파리라는 브라우저가 기본 내장되어 있다. 비록 사파리는 크로스 플랫폼 프로그램이기는 하지만, 윈도우에서는 별 재미를 못 보고 있는 모양이다. <날개셋> 한글 입력기도 그렇게 윈도우, 맥, 리눅스를 다 날아다니는 프로그램이었으면 얼마나 좋을까?

그나저나 맥 OS 클래식은 9까지만 해도 메모리 보호와 선점형 멀티태스킹조차 지원되지 않았다니 대체 뭐야... 90년대 말까지 쓰이던 운영체제가 기술적으로는 그 허접한 윈도우 3.1과 다를 바가 없었다는 말인지? CPU가 16비트였는지 32비트였는지? PC 쪽과는 역사가 너무 다르니 그저 궁금할 따름이다. 어렸을 때부터 본인에게 매킨토시에 대한 이미지는, 전자 출판과 복잡한 그래픽 작업처럼 PC하고는 가히 넘사벽인 최고급, 최고가 컴퓨터였기 때문이다.

아울러 맥 OS X에는 그림판뻘 되는 간단한 그래픽 편집기를 내장하지 않고 있다는 것에도 깜짝 놀랐다. 워드패드와 메모장 둘의 역할을 훌륭하게 해 내는 TextEdit는 있지만 그림판에 대응하는 프로그램은 없다니... =_=

Posted by 사무엘

2010/06/18 08:55 2010/06/18 08:55
, ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/298

이 글에서 소개하는 두 게임은, 본인이 좋아한 장르가 아니고 즐겨 하지는 않았지만, 본인의 기억에 비교적 좋게 남아 있는 고전 게임이다.

1. LHX

헬리콥터 시뮬레이션 게임이다.
1992년 5월, 초등학교 4학년의 나이로 본인이 최초로 접한 개인용 컴퓨터가 286 AT급 기종이었다. 40MB짜리 하드디스크의 GAME 디렉터리 아래에 기본으로 깔려 있던 게임이 페르시아 왕자 1과 바둑(the many faces of go던가? 그 유명한 프로그램), 그리고 이놈이었다. 그러니 이 게임을 어찌 잊을 수 있으리요?

그 시절엔 단순한 화면 스크롤이나 스프라이트의 2차원적인 이동 말고 전체 화면급으로 프레임이 완전히 새로 바뀌는 애니메이션 자체를 보기가 쉽지 않던 시절이었다. 컴퓨터 성능이 뒷받침을 못 해 줬기 때문이다. 그런데 부동소수점 전용 프로세서조차 없던 그 열악한 기계에서 비록 허접하게나마(텍스처 같은 것도 없고 그저 solid color ^^) 3차원 공간이 구현되고 헬리콥터 조종석이 1인칭 시점으로 보이니 놀랍지 않을 수 없었다.

인트로 화면에서 LHX 글자와 ■●▲ 도형이 뱅글뱅글 돌아가는 애니메이션도 아주 인상적이었다. 캐드 프로그램 같다. 본인이 먼 훗날에 3차원 그래픽 시연 프로그램을 직접 만들 수 있게 됐을 때도 둠, 퀘이크와 더불어 이 장면이 떠오를 정도였다. 아 이제야 나도 저런 프로그램을 만드는 이론적인 배경을 터득했구나!

꽤 현실감을 추구했던 만큼, 헬리콥터의 체력은 단순히 hit point 하나로만 표현되는 게 아니라, 속도계의 일부가 깨지거나 어느 부품이 날아가거나 무슨 기능이 박살나는 것처럼 무척 세세한 묘사가 지원되었다. PC 스피커로 나오는 소리 역시 백미. 본인은 도스 시절에 하드웨어 제어 프로그래밍 경험이 전혀 없이 32비트 윈도우 운영체제로 바로 넘어간 세대이기 때문에, 옛날에 그런 걸 갖고 놀았던 시절이 무척 신기하게 느껴진다.

LHX의 개발자는 Brent Iverson이다. 프로필을 보니 예술 쪽과 전산학 내공을 두루 갖춘 굉장히 탁월한 프로그래머인 것 같다. 과거에 유명한 2D 그래픽 프로그램이던 딜럭스 페인트의 도스용 포팅을 한 사람이기도 하다.
(상업용 게임들이 320*200 256컬러 VGA에서 돌아가던 시절에는 딜럭스 페인트가 오늘날의 포토샵 정도로 스프라이트 만들 때 필수 툴이었다. ^^;;)
듣기로는 군 복무 경력도 있는 듯? 그러니 저런 사실적인 군사 미션 게임도 만들 수 있었을 것이다.

다음은 LHX 화면 녹화 동영상이다.
http://www.youtube.com/watch?v=rbgJGg5yd1A (인트로 화면)
http://www.youtube.com/watch?v=VC3OUrgf1Lg (게임 플레이)

2. 대항해시대 2

대항해시대 시리즈 중에서 가장 명작이었다고 평가 받는 작품. 본인에게는 국산 게임인 <그 날이 오면 3>만큼이나, 음악이 아름다워서 기억에 남는 게임이다.
오프닝부터... 툭툭툭툭 툭툭툭툭.. 빠암 빠암.. 빠암 빠암.. 빠 밤 빰... ^^;;
그리고 비록 3D와는 관계가 없고 16컬러이기까지 하지만, 그래픽 역시 16컬러치고는 색상이 미려하고 고해상도의 장점을 살려 깔끔한 편이다.

다음은 이 게임의 오프닝 동영상이다.
http://www.youtube.com/watch?v=EM143YYEdEg

일본물에 조예가 깊은 분이라면 이미 알겠지만, 이 게임의 음악들을 작곡한 사람은 칸노 요코라는 40대 중반의 여성 음악가이다. 초등학교에 들어가기도 전부터 작곡을 했다는 음악 신동이라 한다. 캐릭터 선택 음악, 항해 중 음악 등등... 아주 낭만적이다.
이 사람은 유수의 게임뿐만 아니라 우리나라의 몇몇 드라마 주제곡도 작곡했으며, 한국에도 팬이 많다.

이 게임은 한글화도 되어 나왔다. 요즘처럼 유니코드도 없고 문자 처리의 국제화와 관련된 그 어떤 표준도 존재하지 않던 시절에 localizing은 상당한 고역이었을 것이다.
특히 이름을 입력할 때 쓰이는 한글 입력 루틴은 어떻게 만들었을까? 키보드를 이용한 두벌식 한글 입력 같은 건 당연히 존재하지 않았으며, 한글 자모를 화살표로 일일이 선택한 후 조합해야 했다.

그러고 보니 오늘날처럼 터치 스크린이나 포인팅 장비가 대중화하기 전부터도, 아주 제한된 key만으로 한글이든 로마자든 글자를 입력해야 하는 환경이 있었다. 게임, 특히 오락실 게임에서 말이다. 알파벳과 숫자 정도야 그냥 A부터 Z까지 위 아래 화살표로 고르고, 대소문자마저 무시하고서 이니셜만 입력하게 해도 되지만 한글은 그보다는 복잡한 과정이 필요할 것이다.

그러나 한글은 그래도 그런 환경에서 입력을 구현이라도 할 수 있지, 일본어와 한자로 가면 정말 답이 안 나온다. 일본이 다른 소프트웨어 중에서도 오직 게임 산업이 발달한 것은 그나마 가장 locale-neutral한 분야여서 그렇다고 하는데 사실인지?

우리나라가 한글 처리에 특화된 아래아한글이라는 워드 프로세서가 강세이듯,
일본도 외국 기업이 흉내 내기 어려운 수준의 일본어 처리 능력을 자랑하는 이치타로(일태랑)라는 토종 워드 프로세서가 있다고 한다. 하지만 아래아한글만치 독자적인 영역을 확보하지는 못하고 결국 MS 워드에게 발리고 있는 듯? 하긴, 일본은 IME마저 패키지 소프트웨어로 팔리는 나라이니, 문자 사정이 한국과는 마치 지구와 금성의 차이만큼이나 극단적으로 다르다. 그래도 한국에도 <날개셋> 같은 3rd-party 입력기가 있다. ^^;;

.
.
.

갑자기 얘기가 문자 쪽으로 새었다. 다시 게임 얘기로 돌아오자면..
풍부한 리소스와 하드웨어 환경만이 명작 게임을 반드시 보장하지는 않는 것 같다.
개나 소나 3D를 써야 하는 오늘과는 달리, 옛날에는 오히려 제한된 자원의 특성을 이용해서 더욱 창의적인 방식의 게임이 많이 시도되었다. 레밍즈나 테트리스 같은 게임이 3D로 컨버전된 후 완전 ㅈ망이지 않았던가.
또한, 그야말로 불멸의 명작으로 평가 받는 스타크래프트도 3D가 전혀 아니며, 무려 윈도우 95에서 실행 가능하고 640*480 256컬러로 돌아가는.. 초 구닥다리이다.

본인은 온라인 게임류를 별로 안 좋아해서 품질 좋은 패키지 게임을 선호하는 편이지만,
게임 업계의 현실은 불법 복제 걱정이 없는 온라인밖에 답이 없는 모양이다.
마치 노트북도 4:3 화면을 선호하는데 온통 와이드 화면밖에 안 나오는 것처럼 말이다.

Posted by 사무엘

2010/06/17 09:04 2010/06/17 09:04
, ,
Response
No Trackback , 6 Comments
RSS :
http://moogi.new21.org/tc/rss/response/297

윈도우 비스타/7에서는 아래아한글의 키매크로가 지원되지 않는다는 걸 며칠 전에야 처음으로 확인했다. 메뉴가 흐려져 있고 아예 선택이 되지 않더라. XP를 졸업한 지 2년이 넘었는데 몇 년째 이 사실을 왜 모른 채 지냈는지 모르겠다. 키매크로는 도스용 1.x 시절 이래로 아래아한글 고급 사용자의 최강의 애용 기능이었는데도 말이다.

아니 그럼 도움말에다가 언급이라도 해 놓지 왜 아무 설명도 없이 메뉴 접근만 막아 놨는지? 그 이유는 인터넷을 검색한 뒤에야 알 수 있었다. 물론 어느 정도 짐작은 했지만 말이다.
(아래아한글 2005는 비스타/7에서는 수 차례의 패치를 안 받으면 에러가 나고 아예 동작을 하지 않으며, 2007도 패치를 받아야 Aero가 적용된 운영체제 표준 모양 스킨을 쓸 수 있다. 비스타에서 키매크로 메뉴를 막은 것도 2005의 패치부터 그렇게 된 거라 함.)

비스타 이상부터는, 아래아한글이 키매크로를 구현할 때 쓰이는 기능 내지 테크닉이 운영체제의 보안에 영향을 끼친다고 간주되어 그걸 운영체제 차원에서 막아 버린 모양이다. UAC 끄고 관리자 모드로 실행해도 별 소용 없다.

사실, 도스가 아닌 윈도우 같은 이벤트 위주 환경에서 키매크로 같은 걸 구현하기는 쉽지 않다. 도스처럼 한 프로그램이 모든 하드웨어 자원을 장악하고 독점하고 일괄 처리를 하는 환경이 아니기 때문이다.
아래아한글이 윈도우용으로 처음으로 포팅되었던 3.0B 시절에는 기능은 분명 화려해졌다. 드디어 아래아한글에다가 윈도우용 TTF에다가 여타 프로그램의 OLE 개체를 집어넣는 게 가능해졌다니.. 그리고 도스용 아래아한글과 정보 손실 없이 파일 공유까지 가능하다니!

하지만 윈도우용에 매크로 기능은 응당 포팅이 안 돼 있었다.
Win32s에, 95에, NT까지 다 신경써야 하던 시절에 그렇게 하드웨어에 민감한 고급 기능을 넣기는 현실적으로 곤란했을 것이다. 내 기억이 맞다면 96까지도 아직 없었다.
그러다가 97에 와서야 프로그램이 Win32s를 제낀 체제로 개편되고 매크로 기능도 다시 생겼다.

그랬는데 한 가지 굉장히 신기한 것은, 매크로를 기록하는 파일 포맷이 9x 계열과 NT 계열이 서로 달랐다는 것이다. 아래아한글 사용 안내문에서 분명히 본 문장이다. 즉, 똑같은 97을 쓰는데, 윈도우 9x에서 녹화하여 저장한 매크로 파일을 NT4에 설치된 97에다 가져와서 쓸 수는 없으며 동일한 매크로를 해당 플랫폼에서 다시 만들어야 했다는 뜻이다.

도대체 무슨 데이터를 저장하기에 똑같은 x86 계열 컴퓨터에서 저장한 매크로 파일이 왜 서로 호환이 안 됐을까? 단순한 키 시퀀스를 저장한 게 아니라 아래아한글의 매크로 구현 방식이 아주 특이했을 거라는 짐작만을 해 볼 뿐이다.
본인은 나름 한컴사전의 노클릭 단어 인식 기능도 어떻게 구현했을지 대략 짐작할 정도이지만, 매크로에 대해서는 여전히 알쏭달쏭 갸우뚱이다. 노클릭 단어 인식도 훅 DLL이 9x과 NT 계열이 서로 별도로 존재하며, 심지어 16비트 프로그램용 훅 DLL까지 들어있다.

그렇게 아래아한글은 윈도우에서도 키매크로를 살려 내기는 했지만, 도스 시절 같은 빠른 속도까지 회복하지는 못했다. 전광석화처럼 화면이 깜빡이며 돌아가는 도스 매크로에 비해 윈도우는...;;
그냥 화면에 그림만 그리는 도스 시절의 대화상자와, 수십/수백 개의 개체로 이뤄진 윈도우 대화상자가 뜨는 오버헤드는... 서로 비교가 안 될 것이다.
게다가 Alt+L, K, T, A, D (블록으로 잡은 텍스트의 한글 서체를 궁서로 바꾸기) 같은 궁극의 단축키 신공도 느릿느릿 마우스 위주인 윈도우에서는 그대로 재현할 수 없게 됐다.

도스든 윈도우든 키매크로 자체를 구현할 정도라면, 매크로가 실행되는 중에 화면 업데이트를 안 하게 하는 옵션을 넣는 것도 불가능하지는 않을 것 같은데, 그것만 해도 매크로의 실행 속도를 무척 향상시킬 수 있지 않을까 싶다.

매크로는 일반적인 워드 프로세서 사용자보다 더 전문적인 컴덕후들이 즐겨 사용하는 텍스트 에디터에서는 더욱 필수인 기능이다. 비주얼 스튜디오의 경우 긴 매크로가 실행 중일 때는 트레이에 풍선 도움말도 뜨고, 이걸 건드리면 실행 중인 매크로를 손쉽게 중단도 시킬 수 있다. 아래아한글에도 이런 배려가 있었으면 좋겠다.

윈도우 환경에서는 도스 시절 같은 기계적인 키매크로의 의미가 여러 모로 퇴색한 만큼, 아래아한글도 최신 버전부터는 스크립트 기반 매크로를 지원하고 있다. 과거 PC 통신 에뮬인 이야기에 혼잣말 기능이 있었듯이. 키 조작이 아니라 키 조작이 의미하는 명령을 기록함으로써 좀더 똑똑하고 효율적인 매크로를 구현하고 간단한 프로그래밍 로직과 분기까지 구현한 것이다. 이 정도로 매크로가 능동적인 존재가 되고 나면, 슬슬 매크로의 보안도 따져야 할 필요가 생길 것이다.

스크립트 매크로는 키매크로와는 내부 구현 방식이 다른 듯하며, 아래아한글도 앞으로는 키매크로를 빼고 스크립트 매크로만 지원할 것으로 보인다.
그런데 스크립트 매크로를 이용하여 키 입력을 녹화해 봤는데 이상한 에러와 함께 실행이 안 돼서리...;;;
급하게 매크로를 수만 번 실행해야 할 일이 있는데 결국은 VMware 아래의 윈도우 XP에다가 아래아한글을 설치해서 키매크로 뺑이를 돌려야 했다. 아놔이런....;;;;;;;;

HWP.EXE의 속성-호환성 탭을 이용해서 운영체제의 버전을 일부러 낮춰 주면 매크로 메뉴를 사용은 할 수 있게 되나, 반복 실행이 되지 않았다. Alt+번호로 개개 실행도 속도가 매우 느렸다. 앞서 말했듯이 아래아한글의 키매크로는 어떻게 구현됐는지 정말 궁금할 따름이다.

제대로 된 매크로를 응용 프로그램이나 운영체제가 지원해 준다면, 매크로를 실행 중인 프로그램은 매크로 실행 결과를 실시간으로 업데이트 하든 안 하든, 최소한 응답이 없이 죽어서 ghost 윈도우가 되는 일은 없어야 하며, 언제든지 중단도 시킬 수 있어야 할 것이다. 그리고 다른 프로그램에서 사용자가 키 입력을 하든 말든 자기는 자기 일만 잘 하고 있어야 할 것이다.

그런데 아래아한글은 그렇지는 못한 것 같다. 매크로를 돌리고 나서 한참 컴퓨터를 가만 놔뒀더니, 화면 보호기가 갑툭튀 실행된 후로 프로그램 창은 거의 ghost 윈도우처럼 아무 응답이 없고, 게다가 그때부터 키보드 입력이 엉뚱한 곳으로 갔는지 매크로가 제대로 실행되어 있지 않았다. 이런 망할 화면 보호기.. -_-

요즘 사람들은 컴퓨터를 안 쓸 때도 그냥 켜 놓는 경우가 워낙 많기 때문에 컴퓨터 설계자들은 idle 상태일 때 전기를 최대한 아끼는 방법을 연구하는 게 당연지사이다.
그런데 가끔씩은 컴퓨터를 서버 용도로 쓸 때도 있고, 프레젠테이션 발표용으로 쓰기도 하고, 윗글처럼 일괄 처리를 시켜 놓는 경우도 있다. 그럴 때는 오랫동안 키보드 입력이 없다고 해서 컴퓨터가 함부로 툭 꺼져 버려서는 안 된다. 이 둘이 마치 교통수단의 이동성과 접근성처럼 동전의 양면 같은 면모가 아닐까 한다.

Posted by 사무엘

2010/05/20 08:32 2010/05/20 08:32
, ,
Response
No Trackback , 5 Comments
RSS :
http://moogi.new21.org/tc/rss/response/274

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

블로그 이미지

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

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2024/04   »
  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:
2676637
Today:
1205
Yesterday:
2124