동일한 기능을 하는 프로그램이 여러 CPU 아키텍처로 포팅된 실행 파일을 살펴보면...
우리에게 아주 친숙한 x86 아키텍처용 EXE는 크기가 가장 작다고 단정적으로 말할 수는 없지만 상당히 작은 편이다.
이보다 코드 사이즈가 더 작게 컴파일되는 아키텍처는 본인이 보기엔 찾기가 어렵다.
EXE 파일의 기계어 코드 부분을 헥사 에디터로 들여다봐도 코드 바이트가 좀 조밀조밀 있는 편이다. 그 반면 IA64나 MIPS 같은 아키텍처 EXE의 기계어 코드를 들여다보면, 4~8바이트 단위로 패턴이 느껴진다.

물론 인텔 아키텍처도 그나마 32비트와 64비트로 가면서 인스트럭션의 평균적인 크기가 길어져 오긴 했다. 그런데 초기의 16비트 명령 체계는 정말 아담했으며, 어셈블리 튜닝을 쓰면 오늘날의 컴퓨터 아키텍처로는 상상도 할 수 없는 작은 크기의 프로그램으로 온갖 큼직한 기능을 넣을 수 있었다. ^^;;
인텔 아키텍처는 하위 호환성을 최대한 존중하고 있으니, 옛날에 정한 1바이트짜리 코드 바이트가 다 선점되었으면 32비트나 64비트 때 추가된 명령은 탈출문자 접두사를 붙여서 5바이트~6바이트... 이런 식으로... 근본적으로 길어질 수밖에 없는 셈이다.

컴퓨터 아키텍처에 대해서 배운 전산 전공자라면, CISC 방식과 RISC 방식의 차이에 대해서는 익히 들어 봤을 것이며, 오늘날엔 이런 식의 단편적인 구분이 별 의미가 없어졌다는 것까지도 알고 있을 것이다.

옛날은 메모리가 아주 귀한 자원이던 시절이었다. 그래서 인텔 x86은 코드를 적재하는 데 필요한 기억장소의 크기를 최대한 아끼는 방향으로 설계되었다. 기계어 코드의 크기가 1바이트부터 시작해 아주 가변적이고, 각 명령 하나하나에 꽤 함축적으로 많은 뜻을 포함시킬 수 있다.

많은 뜻이라 함은, 명령을 내릴 때 상대 주소라든가 절대 주소라든가 실제 상수 같은 개념을 한 인스트럭션에다가 바로 표현할 수 있음을 의미한다. 다른 아키텍처라면 임시값을 또 레지스터에다 먼저 저장하고 전처리를 해서 여러 인스트럭션을 거쳐 표현해야 할 명령을, 한 인스트럭션만으로 표현할 수 있다는 뜻이다. 이것을 CISC 방식이라고 하며, 앞의 C는 complex를 뜻한다. 인텔 x86은 CISC 방식 아키텍처의 대표적인 예이다.

CISC 방식는 상술했듯이 코드 길이가 짧아진다는 장점이 있지만 이를 하드웨어적으로 해석하는 회로가 필연적으로 복잡해지고 만들기 어려워진다는 단점이 있다. 이는 전력 소모의 증가로까지 이어진다. CPU에서 실제로 명령을 실행하는 부분이 아니라 이게 무슨 명령인지 파악하는 부분부터가 오버헤드가 커진다는 뜻이다.

그래서 CISC 방식은 근본적으로 임베디드나 모바일 환경에는 적합하지 않다. 이런 이유로 인해, 오늘날 전세계적인 각광을 받고 있는 스마트폰에서는 ARM이라는 RISC (Reduced) 방식 아키텍처가 쓰이고 있다. ARM이 스마트폰 세계에서 거의 인텔 x86 같은 본좌 인지도를 차지한 것이다.

RISC는 설계 철학이 CISC와는 반대이다. 인스트럭션의 크기는 기계가 한 번에 인식하는 machine word 크기와 일대일 대응하거나 최소한 배수 단위이다. 인스트럭션을 fetch, decode하고 의미를 파악하는 절차가 아주 간편하다. 최소 의미 단위가 작은 대신에 임시 작업용으로 범용 레지스터를 CISC 방식 CPU보다 꽤 많이 준다.

이런 CPU는 심지어 구조체 멤버를 인식하는 단위에도 제약이 있다. 포인터의 오프셋이 machine word의 배수 단위로 딱 떨어지지 않고 사이에 걸쳐 있는데 그 주소를 참조시키면 CPU가 에러를 일으킨다. 성능과 효율을 위해, 이런 복잡한 상황은 과감하게 처리를 거부하는 방법을 택한 것이다.

인텔 x86은 그렇지 않다. 명령어의 실행부터가 워낙 지저분한 바이트 단위 fetching에 익숙한지라, 오프셋이 저런 경우에도 한 사이클만에 참조를 못 하더라도 여러 사이클로 나눠서 사용자가 원하는 데이터를 얻어 준다.

RISC 아키텍처에서 돌아가는 실행 파일을 들여다보면 기계어 코드가 진짜로 4바이트나 8바이트 패턴으로 쫘르륵 나열되어 있는 걸 볼 수 있다. 그리고 동일한 코드를 컴파일한 실행 파일 크기가 x86 같은 아키텍처의 것보다 더 크고, 실행 파일의 압축률도 더욱 높다(듬성듬성하다는 뜻). 다만 한 기능을 수행하는 데 드는 CPU 명령 수가 증가하고 그럴 수록 side effect라든가 복잡도도 더 증가하는 만큼, RISC 아키텍처 코드를 컴파일러가 최적화하기는 더욱 어려울 것이다.

이렇듯, 컴퓨터 아키텍처에서 CISC냐 RISC냐 하는 케케묵은 논쟁은 자동차로 치면 전륜 구동이냐 후륜 구동이냐, 철도 차량으로 치면 동력 분산식이냐 동력 집중식이냐 하는 차원의 재미있는 주제이다. 요즘은 x86 같은 CISC 방식 CPU도 내부적으로는 복잡하고 함축적인 명령을 다시 RISC 식 명령으로 나눠서 파이프라인을 수행함으로써 RISC의 장점을 취하려고 하고 있다.

그리고 문득 든 생각:
어느 기계에서나 이식 가능한 평범한 C/C++ 코드는 자연어로 치면 "나는 철수입니다" 같은 평이한 문장에다 대응시킬 수 있다.
그렇다면 도저히 포팅이 불가능한 인라인 어셈블리 코드는, 자연어로 치면 특정 언어의 음운 특성이나 특정 문화 배경에 대한 이해 없이는 도저히 이해할 수도, 문자 그대로 번역할 수도 없는 함축적인 유머나 언어 유희에다 비유할 수 있겠다.

Posted by 사무엘

2010/09/20 09:16 2010/09/20 09:16
, , , ,
Response
No Trackback , 6 Comments
RSS :
http://moogi.new21.org/tc/rss/response/376

※ Fabrice Bellard (프랑스) 1972년생
http://bellard.org/
홈페이지를 보면, 주인장은 수학과 전산학, 전자 공학의 완전 덕후임을 알 수 있다.
파이 계산, 컴파일러, 게다가 IOCCC(국제 난잡한 C 코드 경연대회) 입상 경력.
관심 분야가 이쪽과 상당히 비슷한, 본인의 모 지인이 떠오른다. (누굴까? ㅋㅋㅋ)
이 사람은 1990년대 도스용 실행 파일 압축 프로그램인 lzexe의 개발자이기도 하다.
겨우 고등학생 나이 때 8086 어셈블러로 직접 짰다고 한다. 흠좀무...;;;;;;
그 당시, V3로 바이러스 검사를 해 보면, 압축된 실행 파일은 검사가 되지 않고 압축부터 풀어야 한다는 경고문이 떴다. lzexe와 더불어 pklite도 실행 파일 압축 프로그램이었다.

※ David Fotland (미국) 1957년생
http://www.smart-games.com/
The Many Faces of Go라는 바둑 게임의 개발자이며, 회사까지 차려서 20년 전이나 지금이나 바둑 AI를 열심히 밀고 있는 게임 인공지능 전문가이다. (도스, 윈도우, 모바일 기기) 그 프로그램을 혼자서 다 만들었다니.. 대단하다.
생각보다 나이가 지긋한 분이다. 캘리포니아 주 산호세에 거주 중.

※ Jean-loup Gailly (프랑스)
http://gailly.net/
gzip의 개발자이며, 데이터 압축 분야의 세계적인 권위자로 유명하다. 아래아한글도 2.1 시절부터 이 사람이 개발한 알고리즘을 라이선스하여 hwp 파일 내부 압축을 구현하고 있다. 현재는 스위스 취리히에서 살고 있으며, 구글에 입사했다. 나이가 좀 있어 보이는 분인데 정확한 생년은 모르겠다.
이 사람도 바둑 매니아이다. 개인 홈페이지를 보면 바로 위의 the Many Faces of Go 프로그램에 대해서도 응당 논평을 해 놓았다. AI가 세계 최강급은 아니지만 초보자를 위한 인터페이스가 무척 잘 돼 있다나?

※ Ken Silverman (미국) 1975년생
http://advsys.net/ken/
듀크 뉴켐 3D의 기술 기반인 빌드(Build라는 단어 자체가 고유명사) 엔진을 개발한 게임 프로그래머.
뼛속까지 프로그래머 근성이 철철 흐르는 한편으로 과학, 스포츠, 음악 등등 온갖 분야에 해박한 엄친아라는 게 느껴진다. 빌드 엔진 역시 학창 시절의 작품이다.
지금까지도 딱히 정식으로 소속된 직장이 없이, 프리랜서 프로그래머로만 일하는 모양이다.

※ Shawn Hargreaves (영· 미 이중 국적) 1975년생
http://www.talula.demon.co.uk/
Ken과 동갑이고 비슷한 업종에 종사 중인 게임 개발자이다.
도스 시절, 32비트 C/C++ 컴파일러로 왓콤과 맞장을 떴던 GNU 계열의 DJGPP를 기억하시는가? DJGPP용으로 소스까지 공개이던 걸출한 게임 그래픽 라이브러리 알레그로를 만든 사람이 이 사람이다.
음악에 특별히 조예가 아주 깊은 매니아이다. 지금은 쟝 아저씨의 구글 입사와 비슷한 시기에 마이크로소프트에 입사해서 XNA 기반 게임 개발에 푹~ 잠겨 있는 듯.

말이 나왔으니 또 덧붙이자면.
본인은 중· 고등학교 시절에 스크래블 게임을 컴퓨터용으로 개발했다.
국내에 그런 프로그램이 개발된 사례가 없었기 때문에 응당 외국의 동급 프로그램들을 여럿 구해다가 벤치마킹을 했는데.. 알고 보니 그런 게임의 개발자 중에도 졸라 프로그래밍 고수가 많았다.

※ Jim Homan (1950년대생)
미국 출신. CrossWise라는 걸출한 게임을 혼자 만든 사람으로, 컴퓨터 AI가 굉장히 뛰어나고 프로그램 UI도 매우 프로페셔널하게 잘 만들어졌다. 윈도우 3.1용으로는 보기 드물게 비주얼 C++ 1.x + MFC로 개발되었다.
이 사람은 옛날에는 자기 회사를 차려 사업을 했기 때문에 회사 홈페이지 아래에 얹힌 개인 홈페이지에 개인 프로필도 나와 있었다. MIT에서 컴퓨터 과학을 전공하고 성적도 엄청 좋았고, 접해 본 플랫폼과 관심 분야 등등도 화려하기 그지없었는데, 지금은 이 사람에 대해서 알 수 있는 곳이 없다.

※ Graham Wheeler (1960년대생으로 추정)
http://www.linkedin.com/in/grahamwheeler
WordsWorth라는 게임을 만들었다. 개발자는 완전 수학 덕후로, 학부에서 수학 전공하고 대학원에서 컴퓨터 과학으로 박사와 박사 후 연구원까지 마친 브레인이다. 국적이.. 남아프리카 공화국으로, 케이프타운 대학을 나왔다.
지금은 마이크로소프트에 입사. 프로필과 블로그를 보면 역시 뼛속까지 엔지니어를 넘어 골수 컴퓨터 과학자이다.

한 줄 요약: 세상은 넓고 덕후들, 고수들은 무진장 많다.

Posted by 사무엘

2010/08/20 09:03 2010/08/20 09:03
, , , , , ,
Response
No Trackback , 5 Comments
RSS :
http://moogi.new21.org/tc/rss/response/352

오늘날 쓰이고 있는 컴퓨터라는 기계의 이론적 근간을 마련한 사람으로는 앨런 튜링(영국)이라든가 폰 노이만(헝가리->미국) 같은 불세출의 천재 수학자가 있다. 그런데 영국에서는 튜링보다 먼저, 범용적인 계산 기계라는 개념을 떠올렸던 천재가 있었으니 바로 찰스 배비지(1792-1871)이다. 전산학도라면 배비지의 해석 기관에 대해 들어 보지 못한 사람이 없을 것이다.

그는 시대를 너무 앞서 간 괴짜 덕후였으며, 재정 부족과 당대의 기계 제작 기술의 부족 때문에 그의 꿈이 당장 완전히 실현되지는 못했었다.
참고로 창조 과학회에서는 배비지가 독실한 크리스천 과학자였다고 띄우고 있다. ㅋㅋ 링크를 소개한다. (그 반면 튜링은 동성애자인 데다 자살로 생을 마감했으니, 기독교 진영에서는 별로 좋아할 구석이 없겠다)
http://www.kacr.or.kr/library/itemview.asp?no=243

그런데, 이 시대에 영국에서는 배비지의 계보를 이을 천재 수학자가 또 태어났는데, 이번엔 여자였다. 그녀의 이름은 에이다(Ada Lovelace; 1815-1852). 인류 역사상 최초의 프로그래머라고 일컬어지는 먼치킨 엄친딸 공순이이다. 이 두 사람은 사진기가 발명되기 거의 직전의 시기를 살았던 사람인지라 사진은 전해지지 않으며, 초상화나 스케치로 그려진 모습만 전해 내려온다. 하지만 에이다는 상당한 미녀였다고 한다. Lovelace라는 성은 백작 작위를 얻은 남편의 성에서 딴 것.

에이다는 ‘자고 일어나 보니 유명해졌더라’ 같은 어록으로 유명한 시인 바이런의 외동딸이었다. 아버지가 희대의 바람둥이었다고 하는데 딸 역시 머리가 비범했고 나중에는 도박에 빠졌다고 하니 평범한 인생을 살지는 못했으며, 그러다 자궁암 때문에 30 중반의 나이로 요절하여 세상을 짧고 굵게 살다 갔다.

그녀는 남들이 도무지 이해를 못 하던 찰스 배비지의 해석 기관의 원리를 간파하고 그 기계의 무한한 가능성을 알아차린 당대의 극소수 덕후 중 하나였다. 오늘날 절차형 프로그래밍 언어의 기본 골격이라 할 수 있는 루프, 조건문, 서브루틴 같은 개념을 떠올렸다. 그것을 처리하는 기계를 만들고 그 틀을 바탕으로 프로그램을 짜서 돌리면, 기계로 음악도 작곡하고 그림도 그리게 할 수 있다고 상상했다. 무려 19세기에 말이다!

배비지 역시 에이다의 재능과 글빨에 큰 감명을 받았다고 한다. 그녀는 기계가 숫자를 처리하기 위해서는 10진법이 아닌 2진법이 유리하다는 발상을 했으며, 베르누이의 수를 구하는 ‘프로그램’을 해석 기계를 기반으로 실제로 작성하기도 했다. 그래서 최초의 프로그래머이다. ㅎㄷㄷ;;; (베르누이는 유체 역학에서 배우는 베르누이의 원리를 발견한 그 과학자 겸 수학자이다. H2O가 뭔지 정도야 '문과 출신'도 알겠지만, 베르누이의 수가 뭔지는 어지간한 이과 출신도 들어 보지 못했을 것이다.)
http://www.bernoulli.org/

그로부터 100년 남짓한 시간이 지나고 전자식 컴퓨터가 실제로 발명되었을 때, 한 절차형 프로그래밍 언어는 바로 이 여성 프로그래머를 기려, 그녀의 이름을 따서 Ada라고 명명되었다. 프로그래밍 언어의 이름에다가 전설적인 프로그래머의 이름을 붙였으니 매우 고무적인 현상이라 하지 않을 수 없다.

Ada 언어는 1983년에 첫 제정되었으며, 이는 시기적으로 C++의 탄생 시기와 일치한다. C++의 고안자가 스웨덴 사람인 반면, Ada의 초창기 핵심 고안자는 프랑스 사람이었다. Ada는 당시 난립하던 프로그래밍 언어들의 통합을 목적으로 미국 국방성으로부터 강력한 후원을 받으며 만들어졌다. 그래서 그쪽 바닥--무기를 가동하는 전산 시스템 같은--에서는 지금까지도 표준 언어로 쓰이고 있다고 한다.

본인은 에이다 언어에 대해서 잘은 모르지만, 이 언어의 문법은 일단 파스칼과 얼추 비슷하다. 암호스러운 기호들보다는, 타이핑을 더 하더라도 깔끔하게 영어 단어 표기를 선호한다. 패키지 단위로 빌드가 이루어지는 것도 C/C++보다는 파스칼 방식이다. (참고로 베이직 언어의 경우, MS의 퀵베이직은 include에 컴파일/링크까지 C언어의 빌드 모델을 그대로 이어받은 반면, 파워베이직은 파스칼과 비슷한 방식을 쓰고 있다는 것이 흥미로움.)

Ada에 대해서도 예제 코드를 보면 이해가 빠를 것이다. 미리 말하지만 C/C++의 사고방식보다는 파스칼의 관점에서 보면 굉장한 동질감을 느낄 수 있다. 심지어 대소문자 구분이 없는 언어라는 것까지도 똑같다. 비록 요즘 C++의 영향을 받은 자바나 C# 같은 언어들의 추세는 대소문자 구분이지만 말이다. 더 자세한 것은 http://www.adahome.com/ 참고.
아니, 그러고 보니 Ada는 수학자의 이름을 따서 지어진 것까지 파스칼과 일치하는구나.

Ada는 기존 언어들의 통합을 목적으로 만들어진 만큼, 이것저것 여러 언어 요소들을 집어넣느라 표현의 자유가 굉장히 넓으며, 제공되는 언어 요소가 많다.
무슨 말이냐 하면, 가령 다차원 배열(a[2,5])과 배열의 배열(a[2][5])을 구분하여 모두 표현할 수 있고,
단축연산이 지원되는 논리 연산자와(and also나 or else), 그렇지 않은 연산자(그냥 and나 or)가 모두 제공된다.

파스칼처럼 0..100 같은 식의 subrange도 당연히 지원되고, 똑같은 정수형이라도 int 같은 기본 자료형과 완전히 호환되는 단순 alias/typedef인지, 아니면 int와 호환되지 않는 별개의 타입인지도 지정 가능하다. 타입 하나는 C/C++과는 비교도 할 수 없이 정교하고 엄격하게 만들 수 있어서 좋다.
함수 안에다 함수도 당연히 만들 수 있고, while이나 for 같은 loop 자체에다가 label 이름을 붙여서 다중 loop을 goto문 없이 바로 탈출하는 것이 가능하다.

이런 것들만 있는 것도 아니고, 어쨌든 Ada는 처음 발표되었을 때는 문법이 필요 이상으로 너무 복잡하고 컴파일러로 다 구현하는 데 난감하다는 불만도 있었다고 한다. Quicksort의 고안자께서도 그렇게 불만을 제기한 사람 중 하나였다고 함. 하지만 오늘날은 C++도 가히 복잡성 면에서는 타의 추종을 불허하는 경지에 도달한 것 역시 사실이다.

그다지 여성향을 느낄 수 없는 것 같은 전산학 분야에도 이런 사연이 있는 여성의 이름을 딴 프로그래밍 언어가 존재한다는 것이 흥미롭다. 여성 프로그래머 모에~ 이다. 하하. =_=;;
참고로 성경에는 Ada와 가장 비슷한 이름으로 유대 왕국의 왕 Asa가 있으나, 물론 성별부터가 다르다.

에이다가 살아 있던 19세기에 우리나라는 뭘 하고 있었는가? 딱 흥선대원군 시절이다. 그런데 본인은 그 시절 조선의 역사에 대해서 좋은 기억이 도무지 없다. 19세기 하면 홍 경래의 난, 전 봉준 동학 운동, 게다가 명성황후 시해 등... 나라는 점점 탐관오리 부정부패와 외세의 침략에 휘말려 막장으로 치닫다가 이내 일제에게 주권을 빼앗기고 만다. 그런데 그 시절에 영국은 저런 상상을 초월하는 학문적 성과가 속속들이 발표되고 있었으니... 오옷 역시 킹 제임스 성경과 철도를 만들어 낸 나라! 괜히 전세계를 호령한 선진국이 아니다.

게다가 전자기학의 대부인 마이클 패러데이(1791-1867), 제임스 맥스웰(1831-1879), 그리고 나중엔 찰스 다윈(1809-1882)이 전부 동시대를 살았던 영국의 과학자들이다! 이 정도면 충격과 공포가 아닐까? 맥스웰도 마찬가지이지만 패러데이는 다윈의 진화론을 단호하게 반박하고 부정한 것으로 유명한 사람인데( http://www.kacr.or.kr/library/itemview.asp?no=644&orderby_1=subject 참고), 에이다로부터 연애편지를 받고서 사랑의 힘으로 더욱 분발(?)하여 전자기력  관련 실험을 성공적으로 마칠 수 있었다 ‘카더라’. 그러고 보니 패러데이는 찰스 배비지와 거의 동갑이니 흠좀무.

끝으로, 잘 알려지지 않은 사실인데, 에이다 부인은 암 치료 과정에서, 당시 통용되던 bleeding (또는 bloodletting) 시술 중에 사망했다. 쉽게 말해 피를 빼내는 작업이다. 옛날 사람들은 병에 걸리면 환자의 혈액에 독소가 차기 때문에 그걸 제거하면 병이 나으리라고 믿었던 모양이다. 마치 체했을 때 손가락 끝을 따는 것처럼? 그런데 그렇게 바늘로 찔러서 몇 방울 따는 것과는 비교도 못 할 정도로 피를 많이 퍼내다가 오히려 환자를 탈수와 쇼크로 인해 죽게 한 경우도 많았다고.

미국의 초대 대통령이며 세계 최초로 자기 임기만 마치고 권좌에서 물러난 지도자인 조지 워싱턴도 bleeding 중에 죽었다. 문헌을 찾아보니 그는 은퇴 후 노후로 인한 폐렴· 천식· 독감 합병증에 걸렸는데, 의사가 치료랍시고 허약한 노인의 피를 5 pint... 거의 2리터가 넘게 빼냈던 것이다. 성인 인체의 전체 혈액이 5리터 남짓이라 하며 헌혈만 해도 아주 건장한 성인 남자를 대상으로 많이 채혈할 때가 3~400ml 정도 하는데, 그의 5배가 넘는 양을 뽑아냈으니 환자의 명을 재촉하는 행위밖에 더 되었겠는가? 그 당시는 혈액에 면역 시스템이 있다는 걸 모르던 시절이었고, 육체의 생명이 피에 있다는 걸(레 17:11) 실감을 못 했었다.

http://gwpapers.virginia.edu/articles/wallenborn.html
http://www.av1611.org/amazing.html

Posted by 사무엘

2010/07/29 08:36 2010/07/29 08:36
, , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/333

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

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

컴퓨터 구조를 공부하면서 배우는 기본 개념 중 하나는, ‘컴퓨터 내부에서 숫자가 표현되는 원리’이다.
부호 있는 정수는 소위 말하는 ‘2의 보수’ 형태로 표현되는데, 이것은 모든 비트가 1인 숫자는 -1이 되는 형태이다. 이런 방식을 쓰는 이유는 연산 회로를 설계할 때, 뺄셈을 덧셈의 변형만으로 매우 손쉽게 구현할 수 있는 체계이기 때문이다.

베이직 언어는 다른 언어들과는 달리 TRUE의 값이 -1인데, 그 이유가 바로 이런 컴퓨터의 구조와 관련이 있다. 베이직은 비트 연산자와 논리 연산자의 구분이 없기 때문이다.
0 아니면 1밖에 모르는 디지털 컴퓨터는 연속이나 무한 같은 개념을 표현할 수 없다. 숫자도 정수만 다루는 데 익숙하다. 그러나 현실 세계에서 발생하는 문제를 해결하려면 소숫점이 동반된 실수를 다뤄야 할 일도 매우 자주 발생한다.

소수를 표현하는 가장 간단한 방법은 소위 ‘고정소수점’이다. 가령 32비트 고정소수점의 경우, 정수와 완전히 똑같은 방법으로 숫자를 표현하되 실제로는 그 수의 의미를 정수를 16비트 크기만큼(65536) 나눈 것으로 인식하는 것이다. 즉, 수의 정밀도만 1이 아닌 1/65536으로 기계적으로 높아지는 셈.

고정소수점은 일단 덧셈· 뺄셈· 비교 연산을 정수와 완전히 동일한 방식으로 할 수 있어서 처리 속도가 매우 빠르며, 곱셈과 나눗셈을 할 때만 약간 주의해서 자릿수 정돈을 하면 되니 편하다. 실제로 일부 벡터 그래픽이나 글꼴 쪽 분야에서는 이런 고정소수점 방식이 잘 쓰이고 있다. 그러나 표현 가능한 수의 범위가 매우 심각하게 제한을 받기 때문에 범용성은 떨어진다.

자리수의 제약을 받지 않고 소수점을 좀더 자유롭게 표현하려면, 유효숫자와 자릿수를 따로 둘 필요가 있다. 그게 훨씬 더 실용적이다. 부동(floating)이라는 개념이 여기에서서 나왔다. 제일 큰 자리수의 숫자가 무엇이며 그 뒤에 0이 몇 개 붙느냐가 중요한 것이다.

이런 체계에서는 10.5에서 0.5는 제대로 표현할 수 있지만, 10000000.5에서 0.5는 손실될 가능성이 커진다. 그리고 한 숫자를 결국 두 수의 조합으로 표현해야 하므로, 각종 연산이 단순 정수보다 훨씬 더 느리고 힘들어진다.

옛날에는 이런 부동소수점 계산을 하드웨어 회로 차원에서 바로 해 주는 코(보조)프로세서가 별도로 존재했다. fdiv, fmul 같은 인스트럭션. 심지어는 제곱근이나 삼각함수 값까지 바로 구하는 명령이 있다!
하지만 시중에는 그런 게 없는 컴퓨터도 있다는 얘기이기 때문에, 1990년대에 상업용으로 쓰이던 어지간한 컴파일러들을 보면 소프트웨어적으로 부동소수점 계산을 흉내 내는(엄청 느리지만-_-) 코드를 추가할지를 지정하는 옵션도 있었다.

그런데 부동소수점을 표현하는 방식 자체가 통일돼 있어야 그 기준에 따라 코프로세서를 만들든지 말든지 할 수 있을 것이다. 그 표준 규격이 바로 IEEE754이다. 1985년에 제정되었다.

이 규격은 좀 정밀도가 떨어지지만 처리 속도가 더 빠른 32비트와, 용량이 넉넉하지만 역시 속도의 압박이 있는 64비트로 나뉜다. CPU 단위가 16비트이고 부동소수점을 소프트웨어적으로 처리하는 게 보편적이던 옛날에는, 아예 컴파일러 재량으로 소프트웨어적으로 구현한 48비트(6바이트-_-.. 파스칼에서 Real) 실수와 80비트(C/C++에서 long double) 실수도 존재하였으나 지금은 완전히 흑역사가 되었다. 요즘은 화면 픽셀 크기도 24비트는 존재하지 않으며 32비트이다. 죄다 컴퓨터가 처리하기 편한 단위로 그냥 확장된 듯하다.

제일 간단하게 말하자면, 32비트 실수에서는 1비트는 이 수의 부호를, 다음 8비트는 지수를, 다음 나머지 23비트는 유효숫자를 나타낸다. 64비트 실수에서는 그 비율이 1:11:52이다.
컴퓨터가 사용하는 부동소수점의 지수의 밑은 너무 당연한 말이지만 10이 아니라 2이다. 따라서 2의 거듭제곱의 역수가 아닌 모든 소수들은 끝자리가 잘린 ‘순환소수’가 된다! 0.25, 0.125, 0.5 같은 수가 아닌 다른 모든 수들.. 0.1, 0.2, 0.3 이런 것들은 화면에서는 적당하게 근사되어 표현되었다 할지라도 실제로는 그 수의 100% 정확한 형태로 저장되지 않은 셈이다. 부동소수점의 한계를 분명히 알고 있어야 한다.

어쨌거나.. 2^23과 2^52에다 base가 10인 로그를 씌워 보면 32비트 실수의 유효숫자 정밀도는 약 7자리, 그리고 64비트 실수의 정밀도는 약 15자리라는 걸 알 수 있다. 그리고 표현할 수 있는 자리수의 범위는 32비트는 약 38자리, 그리고 후자는 약 308자리이다(비트가 3개 더 늘어서 2^3인 8배가 더 늘었으므로). 소수점 밑으로도 그만치 내려갈 수 있다.

까놓고 말해 이런 공용체를 통해 부동소수점을 쉽게 해부할 수 있다.

union REAL {
   float fValue;
   struct {
      unsigned sign: 1; //부호
      unsigned expo: 8; //지수부
      unsigned mantissa: 23; //가수부
   };
};

공용체와 비트 필드가 존재하는 C/C++ 만만세. ㄲㄲ
단, 우리가 쓰는 인텔 CPU는 little endian이므로 sign, expo, mantissa 순이 아니라 반대로 mantissa, expo, sign으로 멤버 순서만 바꿔 주면 된다. 쉽죠?

그런데 지수부와 가수부 사이에 아무런 제약을 가하지 않을 경우 동일한 숫자를 여러 방법으로 표현할 수 있게 되어 문제가 생긴다. 4를 2의 2승, 4의 1승 이런 식으로 표현하듯이 말이다. 그래서 IEEE754는 가수부는 가장 큰 자리수의 비트값이 무조건 1인 것만 인정하게 하고 그 1은 명시적인 표기를 생략했다. 이를 ‘정규화’된 형태라고 한다.

거두절미하고, 32비트 부동소수점에서 구조체의 각 멤버로부터 부동소수점 값을 다시 얻어 오는 식은 다음과 같으므로 참고하자. 식에서 23과 24는 가수부의 자릿수 23비트와 관계가 있으며, 126은 지수부의 크기 8과 관계가 있다. 2의 8-1승보다 2 더 작은 값이다. 1<<23이 바로 생략된 최대 자리수인 셈이다.
그저 의미를 알 수 없는 블랙박스 같던 부동소수점이 좀더 친근하게 와 닿을 것이다.

pow(2.0, (double)( (int)a.expo-24-126))* ((1<<23)|a.mantissa) * (a.sign ? -1:1)

IEEE754에는 이외에도 무한대를 표현하거나 불능을 뜻하는 규격이 있다. 정수를 0으로 나누면 CPU 차원에서 바로 exception이 일어나지만 부동소수점은 에러는 안 나고 저런 특수한 숫자가 돌아온다.
또한 정규화를 해서 자리수를 강제로 늘리는 바람에 표현할 수 없게 된 일부 극히 작은 수를 별도로 표현하기 위해 내부적으로 심지어 ‘고정소수점’ 방식을 임시로 사용하는 규정조차 갖추고 있다. 마치 퀵 정렬이 작은 구간에서는 삽입 정렬을 사용하기도 하는 것처럼 말이다. 이에 대한 더 이상의 자세한 설명은 생략하겠다.

참고로,
1. IEEE754 부동소수점에는 구조적인 한계로 인해 0이 +0과 -0 이렇게 두 개 존재한다.
2. 역사상 최초의 전자식 컴퓨터로 일컬어지는(논란의 여지는 좀 있지만) 에니악은 10진법을 사용했다! 전자 신호 4비트(=16)로 10진법 숫자 하나를 표현했을 것이고 매우 비효율적으로 동작했을 것이다. 하지만 그 당시엔 이 기계로 탄도 계산도 하고 풍동 실험도 하고 심지어 일기 예보도 했었다.

Posted by 사무엘

2010/04/22 22:53 2010/04/22 22:53
, ,
Response
No Trackback , 7 Comments
RSS :
http://moogi.new21.org/tc/rss/response/251

컴퓨터 쪽 잡설

1.
요즘 스마트폰 프로그램 개발 플랫폼:
- 안드로이드: 자바
- 아이폰: 오브젝티브 C
- 윈도우 모바일: C/C++
아주 언어까지 가지각색 제각각이네. =_=;;;
생각해 보면 각각 데스크톱 PC에서 리눅스, 맥OS, 윈도우 진영이 그대로 형태만 바뀐 게 아닌가 싶다.

그래서 이런 기기 프로그램 개발하는 회사들.. 특히 문자 입력 솔루션을 개발하는 회사들이 고역이라고 한다. 서로 극단적으로 다른 분야인지라, 동일한 제품을 만들어도 플랫폼별로 프로그래머를 따로 고용해야 하기 때문에.

2.
64비트 윈도우에는 32비트 모듈과 64비트 모듈이 서로 철저하게 분리되어 있으며 시스템 디렉터리가 둘 존재한다.
그런데, SysWOW64는 32비트 dll이 들어있는 곳이고, system32가 64비트 dll이 들어있는 곳이다. 헷갈리지 말자.
이름에 들어있는 숫자하고 실제 숫자가 서로 일치하지 않는다는 게 아이러니이다. ^^;;;

3.
윈도우 7은 비스타와 비슷한 기술 계층 위에서 UI가 굉장히 세련되게 많이 바뀌어서 호평 받고 있다. 그 중엔 창을 화면 한구석으로 끌면 자동으로 창을 최대화하거나 좌우 반쪽을 꽉 채우게 바꾸는 기능이 있다. 대부분의 상황에서 그건 편리한 기능이긴 한데, 그래도 정말로 창을 그렇게 구석으로 살짝 치우기만 하고 싶고 최대화를 시키고 싶지는 않을 때는 어떡하는지가 좀 의아하다.
툴바를 도킹할 때처럼 ctrl 키를 누르고 있으면 채우지 않게 한다거나 하는 기능이 필요하지 않을까?

4.
윈도우 7 얼터밋 같은 상위 에디션에는 윈도우 XP 가상 머신이 추가되어 있다. 이것은 단순히 VMware 같은 가상 머신 유틸이 추가된 게 아니라 아예 윈도우 XP 모드로 웹브라우저를 다른 7 응용 프로그램들과 동일한 위상으로 돌려 주는 기능도 제공한다. 이걸 보고 적지 않게 놀랐다. XP 가상화 모드로 실행된 IE는 Aero 적용도 받지 않고, XP 스킨을 그대로 유지하고 있다. 하지만 다른 프로그램과 동일하게 다루는 게 가능하다.
그런데 그렇게 XP 가상화 모드로 실행된 프로그램의 윈도우의 클래스 이름이 RAIL_WINDOW이다. rail이 난간, 울타리라는 뜻이 있으니 그런 이름이 붙은 것 같다.

전에도 글로 썼듯이, 본인은 집이나 회사에서나 온통 비스타밖에 안 쓴다.
하지만 바깥에서는 차라리 XP를 쓰면 썼지 비스타 구경하기는 굉장히 힘들어져 있다. 온통 7 쓰니까. ^^;;

5.
본인은 초딩· 중딩이던 시절엔 제발 더 좋은 컴퓨터 좀 장만해 달라고 부모님을 진짜, 엄청 속 썩였는데
이제는 정반대로 지나칠 정도로 이쪽으로는 무덤덤해져 버렸다.
그때야 XT, AT, 386, 486.. 컴의 성능이 한 단계 한 단계 올라갈수록 당장 돌릴 수 있는 프로그램의 스케일이 극단적으로 달라지고 그야말로 천지개벽의 변화가 있었던 반면,

이제는 어지간한 넷북 수준의 컴퓨터에서도 비주얼 스튜디오 깔아서 프로그램 개발하는 덴 별 지장이 없으니, 업그레이드의 필요성을 별로 안 느끼게 된 것이다.
그래서일까? 명색이 IT 업계 종사자 소프트웨어 개발자라면서 본인은 우리 회사에서 최고령 휴대전화를 쓰고 있다. ^^;; 자동차로 치면 아직까지 포니, 스텔라, 엑셀 같은 차를 몰고 있는 것이다.

튼튼하고 배터리 오래 가고 통화· 문자만 되면 된다. 잃어버리거나 고장나지 않는 이상 도무지 전화기를 바꿀 필요를 느끼지 않는다. 본인에게는 인터넷이 되는 작은 전화기보다, 인터넷 안 되더라도 정상적인 타이핑이 가능한 휴대용 컴퓨터가 훨씬 더 필요하다.
오히려 부모님이 나보고 폰 좀 바꾸라고 성화일 정도이니 세상이 과연 극과 극으로 바뀌었다. ^^;;

그나저나 20~30년 전에 비해 다른 모든 분야의 물가는 2배~3배 가까이 뛴 반면(버스비, 라면· 우유값, 자장면 값 따위를 생각해 보라), 컴퓨터는 성능이 그야말로 넘사벽 충공깽 급으로 향상됐음에도 불구하고 가격은 예나 지금이나 여전히 수십만~100수십만 원..;; 보편적인 물가를 역행해도 한참 역행하고 있다. 정말 신기한 노릇이다!!

Posted by 사무엘

2010/04/05 09:28 2010/04/05 09:28
, ,
Response
No Trackback , 9 Comments
RSS :
http://moogi.new21.org/tc/rss/response/234

손전화의 추억

나온 지 거의 30년 가까이 된 계몽사 학습 그림 과학의 <내일의 과학> 편에서 묘사된 미래의 모습과 지금을 대조해 본다.
우주 개발이라든가 토목 분야는 상당수가 불발탄이 되었고 여전히 실현되지 않았다.
또한 자동차의 주 연료는 아직도 화석 연료 이외의 다른 것으로 바뀔 기미가 보이지 않으며 지금도 기껏해야 하이브리드 위주이다.
 
하지만 정보 통신과 관련된 기술들은 역시 초과 달성되었다.
손목 텔레비전, 텔레비전 전화, 휴대용 번역기, 벽걸이 TV, 터미널 기반 지식 검색 등 별별 걸 그때 상상하였으며 오늘날 비슷한 형태로 실현된 것도 적지 않은데, 전국민이 주머니에 전화기를 가장한 초소형 컴퓨터를 갖고 다니며 살게 될 거라고는 왜 생각을 못 했을까? 특히 저 기능들이(벽걸이 TV 말고) 한 기계로 모두 가능해질 거라고 말이다. 흥미로운 사실이 아닐 수 없다.
 
본인의 기억이 정확하다면, 1980년대 말~90년대는 가정에서 다이얼을 돌려서 전화를 걸던 게 버튼으로 바뀌어 가던 때였고, 무선 전화가 이제 막 등장하고 있었다. 버튼식은 다이얼이 빙글빙글 도는 걸 기다릴 필요가 없이 전화를 더 빨리 걸 수 있고, 버튼을 누른 반응을 번호별로 톤이 다른 전자음으로 들을 수 있어서 좋았다. 이제는 그 전자음도 역사 속으로 사라져 간다. 절대음감 소유자는 그 전자음의 톤만으로 번호를 바로 분간할 수 있었다는데...
 
그때에도 휴대 전화가 아주 없는 건 아니었다. 물론 아예 선원이나 남극 세종 기지 대원 같은 사람을 위해 엄청 비싼 위성 전화라는 것도 있었으나, 그것 말고도 우리나라에 이미 1988년엔가부터 손전화라고 불리는 물건이 나온 적이 있었다. 하지만 단말기는 거의 벽돌짝 같은 크기이고 가격 역시 여전히 서민이 엄두를 못 낼 수준이었다. 시도 때도 없이 거래처와 연락을 주고받아야 하는 넥타이 부대 영업맨이 아닌 이상 그런 게 필요하지도 않았다.
 
그렇기 때문에 그때 손전화는 카폰이라 하여 주로 고급 승용차의 초호화 액세서리 정도의 위상을 차지했던 걸로 기억한다. 우리나라에 우등 고속버스가 등장한 게 90년대 초부터인데, 우등을 타면 앞자리에 공중전화가 고급 서비스라고 있기도 했다.
 
90년대 중후반에 정보 올림피아드 공모 부문 심사를 받으러 갔을 때도 대회 진행 요원들이 애들을 통솔하고 바깥의 다른 관계자와 연락을 주고받을 때... 무려 '무전기'를 이용하는 걸 본 기억이 생생하다. 폰이 안 터지는 첩첩산중 오지에 있는 것도 아니고 무슨 극비 군사 작전도 아닌데.. 흠좀무. 지금 같으면 그런 통신은 일도 아닐 텐데 말이다.
 
본인이 초등학교 고학년 내지 중학교 정도 나이일 때 한창 쓰였던 게 삐삐. 하지만 본인은 PC 통신은 경험했어도 삐삐는 전혀 소지한 적이 없고 남을 호출한 적도 없다.
그러다가 90년대 말부터 인터넷 검색 엔진과 포털 사이트라는 개념이 생기고 그와 비슷한 시기에 휴대 전화도 급격하게 보급되어 오늘날과 같은 1인 1손전화 시대가 도래하게 되었다.
 
초창기에만 해도 휴대 전화의 통화 요금은 굉장히 비싸서 공중전화로 일반 유선 전화를 걸 때하고 휴대 전화를 걸 때 돈이 줄어드는 속도의 차이가 가히 기겁할 수준이었는데 요즘은 대중화 덕분에 굉장히 많이 저렴해진 것이다. 모르긴 몰라도 전국에 기지국 설치하느라 든 초창기의 어마어마한 투자 비용을 다 회수하고도 남을 정도로 이익을 챙겼다나 어쨌다나..
 
그리고 이것 기억하는가? 지금은 당연시되고 있는 발신자 번호 표시 기능도 한때는, 기술적으로는 문제가 없으나 사생활 침해 때문에 시행하네 마네 논쟁의 대상이었으며, 숫제 추가 요금을 받고 해 주는 부가 서비스로 취급되던 시절이 있었다.
 
손전화가 보편화하면서 이 물건은 단순히 전화기의 수준을 넘어 개인 종합 정보 복합기 노릇을 하면서 PDA, MP3, 전자 사전 등 기존 소형 휴대용 전자 기기들을 위협하기 시작했다. 가지고 다니는 초소형 컴퓨터가 됐다. 기계의 성능 때문보다는, 절대적인 사이즈가 너무 작아서 사람이 뭔가 정교하고 빠른 타자를 할 수가 없기 때문에 기존 데스크톱 컴퓨터와는 별도의 독립적인 위상을 지키고 있을 뿐인 것이다. 요즘 살면서 휴대전화를 반드시 꺼야 할 때란 비행기 탈 때나 시험 칠 때 정도밖에 없지 싶다.
 
이제 12키는 숫자만 입력하는 게 아니라 문자를 입력하는 소형 글자판이 되어서 이를 두고 문자 입력 솔루션 연구 기업 내지 발명가들이 수없이 생겨났다. 계산기처럼 단색 액정이던 화면은 잠시 256색을 거쳐서 트루컬러가 되고, PC 스피커 같던 벨소리도 애드립/미디를 거쳐서 이제는 자연 사운드가 나오기 시작했다. 글자조차도 비트맵 글꼴이 쓰이다가 지금은 일반 PC와 똑같은 트루타입 글꼴로 바뀌었다.
 
정말 격세지감이다. 카세트 테이프, VHS 비디오 테이프도 역사 속으로 사라지고 아날로그 TV 방송과 2세대 휴대 전화도 단종이 수 년 앞으로 다가왔다. 사람들이 전화번호를 외우거나 수첩에 적어 놓고 찾아야 할 필요가 없어진 지도 오래 됐고 디지털 치매라는 용어마저 생겨 있다. 이제 사람이 머리로 꼭 기억해야 하는 건 디지털 세상에서 자기를 식별하는 유일한 수단인 각종 아이디/패스워드 정도가 아닌가 싶다.
 
컴퓨터와 전화기! 비록 1970년대 이후로 인류가 달에 또 가지는 못해도, 서울-부산이 초고속 자기 부상 열차로 1시간만에 연결되지는 못해도, 손전화와 디지털 카메라, 블로그, 유튜브, UCC, 트위터 같은 것이 2, 30년 전의 공상 과학 문학가조차 상상하지 못한 양상으로 세상을 뒤바꿔 놓았다는 것은 아무도 부인하지 못할 것이다.
* 에 그런 의미에서.. 조금 딴 얘기이지만, 국내 포털 사이트들 중 보안 쪽으로 제일 미개한 드림위즈는 반성 좀 요망..
싸이나 구글 같은 일부 사이트는 강력한 암호/약한 암호 체크를 하는 기능까지 추가됐는데
드림위즈만은 1999년에 처음 생겼을 때 이래로 지금까지도 암호를 최대 8글자까지밖에 지정을 못 한다. -_-;;

Posted by 사무엘

2010/03/11 18:59 2010/03/11 18:59
, , ,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/208

본인은 컴퓨터 가상화 프로그램으로 VMware와 도스박스(DOSBox)를 애용하고 있다. 순수 도스와 윈도우 3.x까지를 돌리는 데는 도스박스가 독보적인 솔루션인 반면, 윈도우 9x부터 시작해 여타 NT급 운영체제, 리눅스 등을 구동할 때는 VMware를 사용한다.

둘은 구동하는 방식이 근본적으로 다른데 이 차이를 세세히 논하기 위해서는 나도 잘 모르는 CPU 계층에서의 난해한 개념 설명이 필요하다. 하지만 다 모르더라도 이 사실 하나만 기억하면 된다. VMware(와 기타 동급의 가상화 프로그램)는 CPU가 하드웨어 차원에서 자체 제공하는 가상화 기능을 적극 활용하여 동작하며 이는 32비트 윈도우 NT급 운영체제가 아주 허접하게 호환성 에뮬레이션 계층으로 제공하는 NTVDM도 마찬가지이다. 하지만 도스박스는 CPU 동작 자체를 포함해 모든 하드웨어 동작을 소프트웨어적으로 흉내 낸다.

그 결과 둘은 제각기 일장일단을 갖게 된다. D는 동작 방식의 특성상, 태생적으로 성능은 V보다 꽤 뒤쳐진다. 오늘날의 1~2GHz급 초고성능 컴퓨터에서 겨우 90년대 중반, 윈도우 95 출현 직전의 486~펜티엄급 PC의 성능을 낸다. 사실, 도스의 수명은 거기가 끝이었으므로 그 정도만 동작해도 D는 제 할 일 충분히 해 낸 셈이다. 32비트 보호 모드도 지원하여 둠 정도까지는 도스용을 잘 실행해 내지만, 퀘이크까지 되면 차라리 윈도우용으로 포팅된 퀘이크를 돌리는 게 낫다는 뜻.

하지만 D는 소프트웨어 계층이 담당하는 일이 많은 덕분에, V의 방식으로는 상상도 할 수 없는 다양한 옛날 하드웨어를, 호스트 컴퓨터의 성능만 좋다면 얼마든지 재현해 낼 수 있으며 컴퓨터 구동 속도도 세밀하게 제어할 수 있다.

V의 경우 PC 스피커 소리가 제대로 나지 않으며, 위험한 데이브는 너무 빠르게 돌아가고 금도끼(도스용)는 너무 느릿느릿 실행된다. 이것은 V의 방식으로는 소프트웨어적인 방법으로 제어를 할 수 없다. 윈도우 3.x를 설치는 할 수 있으나 guest extension(VMware tools)을 제공하지 않으며 겨우 16컬러 VGA에서밖에 사용할 수 없다. 사실 V는 근본적으로 16비트 구닥다리 플랫폼 에뮬이 주된 목적인 제품이 아니다.

그 반면 D는 어떤가? 아예 PC 스피커 소리와 옛날 애드립 소리를 사운드카드로 흉내 내어 준다. 그냥 비프음뿐만 아니라, 하드웨어를 교묘하게 제어하여 PC 스피커로 얼추 사운드카드 소리를 내던 기법까지 완벽하게 재현된다! 화면/동영상/음성 캡처야 요즘 가상화 프로그램들이 거의 필수로 갖추고 있는 기능이지만, 아예 프로그램이 내리는 미디 명령을 캡처하여 게임 음악의 미디 악보를 저장하는 기능은 하드웨어를 소프트웨어적으로 흉내 내지 않고서는 구현할 수 없는 기능인 것이다.

없는 하드웨어를 소프트웨어로 다 만들어 준다. 일일이 autoexec나 config.sys 튜닝을 하지 않아도 EMS, XMS 같은 메모리 세팅도 다 자동으로 해 주고, 과거의 베사 SVGA 비디오나 미디 카드, 마우스, 심지어 모뎀 따위도 프로그램이 필요로 하면 다 잡아 주니 V와는 비교가 안 되는 그야말로 도스 천국이 아닐 수 없다. 옛날 잡동사니 드라이버 파일을 뒤지면 윈도우 3.x도 그래픽/사운드 잡아서 쓸 수 있다. 더구나 D는 무려 윈도우 9x에서도 돌아간다!

아무튼 D는 참 대단한 프로그램임이 틀림없다.
그러고 보니 굳이 NT 계열로 운영체제가 완전히 넘어가기 전부터도 윈도우 9x 시대가 되면서 디렉터리의 파일들을 정렬-_-해 주는 유틸리티, 그리고 파일 첫 글자를 입력하여 지운 파일을 살리는 undelete 유틸리티는 아련한 추억 저편으로 사라진 것 같다. FAT32를 도입한 윈도우 95 OSR2가 이를 더욱 가속화한 게 아닌가 싶다. 요즘 NT 계열에서 쓰이는 NTFS는 아예 구조적으로 파일이 자동으로 정렬이 유지되는 파일 시스템이다.

그 전의 FAT16은 하드디스크 크기를 겨우 2GB까지밖에 인식 못 했었다. 요즘은 하드가 아니라 램 크기가 수 GB인데! ㅎㄷㄷㄷ FAT16이 MS 도스 4.0에서 처음 도입되어서 그때는 그걸 갖고 “하드디스크 용량 제한이 ‘없어졌다’”라고 말을 붙이곤 했다. (과거의 FAT12는 한술 더 떠서 하드디스크를 32MB까지밖에 인식 못 했음)
하지만 윈도우 9x는 FAT32로도 100수십 GB 이상의 하드는 제대로 인식 못 하니 어차피 요즘 컴퓨터에서는 쓰지도 못한다.

참고로, VMware에다 과거 윈도우 운영체제를 설치해 보면, 2000/ME부터는 사운드를 자동으로 인식하고 멀티웨이브까지 되는 반면 95/98은 그렇지 못하다. USB 메모리를 안전하게 제거하는 트레이 메뉴가 추가된 것도, 그리고 미디에 소프트웨어 신시사이저가 기본 내장된 것도 2000/ME부터이다.

이런 맥락에서 보면 윈도우 ME는 같은 9x 계열 중에서 그저 나쁘기만 한 게 아니라 최신 하드웨어의 지원 면에서는 98 SE보다 나아진 점도 분명 있다. 하지만 괜히 도스로 부팅하는 기능만 쏙 빼서, 도스 지원 때문에 윈도우 9x 계열을 일부러 선호하는 사용자들로부터도 외면 받았고, 1년 남짓 XP가 출시되는 바람에 아주 짧은 시간만에 묻혀 버린 비운의 마지막 9x 계열 운영체제로 역사에 기록된 셈이다.

98도 마찬가지. 처음 나왔을 때는 윈도우 95+IE4 통합일 뿐이라고 비아냥거림이 많았지만, 95는 마우스 휠, USB, 멀티 모니터라는 개념 자체가 없었던 캐 구닥다리였다. 그런 것들이 도입되고 IME의 문자 입력 프로토콜이 유니코드로 확장된 것만으로도 98은 정말 숨통을 튼 것이었다. 98 SE는 윈도우 9x 계열 중에서는 정말 최장수 안정판이었음도 주지의 사실이다.

Posted by 사무엘

2010/01/19 21:10 2010/01/19 21:10
, , ,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/150

지금은 오나전 아련한 추억이 됐죠. ㄱ-

1. 포트 충돌이 일어나면 모뎀과 마우스를 동시에 못 쓰던 것. ㄲㄲㄲㄲㄲㄲㄲㄲ
(시스템 종료 후 컴이 자동으로 꺼지기 시작,
마우스 휠과 USB 포트, 키보드와 마우스 단자가 PS 포트로 변경...
한 97~99년을 전후해서 다 그렇게 바뀐 것 같더군요.)

2. 도스를 완전히 못 벗어난 윈도우 9x 특유의 블루 데드 스크린과
64KB 리소스 제약..
이건 지구상의 어떤 운영체제에도 없던 이상한 제약이 아니었나 싶습니다.
16비트에서는 도스, 아니면 풀 32비트에서 유닉스, OS/2급의 빵빵한 운영체제 이런 구도였지, 둘을 저렇게 짬뽕한 OS는 윈도우 9x 부류가 유일했으니까요. MS가 고객 수요에 맞춰 장사를 정말 잘 한 것입니다.

3. 물론 이건 운영체제라기보단 드라이버 탓이 더 크겠지만
윈도우 98 시절까지만 해도 멀티웨이브 안 되던 컴도 많았어요. -_-;;
사운드 카드가 동시에 한 프로그램밖에 쓸 수 없는 자원이었던 캐암울한 시절도 있었습니다. ㄱ-

윈도우 2000/ME로 넘어오면서부터

- 소프트웨어 시뮬만으로 미디 신시사이저 지원
- 멀티웨이브 본격 지원
- 메모리 스틱, 외장하드 등 어지간한 USB 기억장치를 자동 인식. "이 장치를 안전하게 제거" 메뉴 자체가 생김 (98 SE는 아직 그런 거 없음.)

꽤 많은 변화가 생겼던 것 같습니다. 과거의 제약이 차츰 사라졌죠.
윈도우 ME는 비록 악명은 높지만 최신 하드웨어 인식 잘 하는 건 98보다 뛰어나다는 걸 확실히 인정함.

그리고 마우스 포인터.
제 기억이 맞다면, 아마 윈도우 2000은 VGA 640*480 16 컬러에서 돌아갈 때도 마우스 포인터가 그래픽이 바뀌는 곳에서 깜빡거리지 않을 거에요. 그거 보고 무척 놀랐던 기억이 납니다.
XP부터는 이제 안전 모드에서도 VGA 16컬러는 볼 일이 없어졌고... ㄱ-

하드웨어 지원을 받아서 마우스 포인터가 깜빡거리는 게 없어진 것이 한 90년대 중반부터인데, 이때도 지원이 완전하지는 못해서 흑백 monochrome 기본 커서가 아닌 커스텀 포인터는 여전히 깜빡거리기도 했었습니다.

CD롬 부팅 후 곧바로 운영체제 설치가 가능해진 것도 2000부터이죠?
NT에 그런 기능 있었을 리는 없고,
9x 계열에도 그런 거 없습니다. 그래서 vmware에서 세팅할 때도 먼저 도스 + fdisk 파티션부터 만들어야 합니다.

Posted by 사무엘

2010/01/10 23:21 2010/01/10 23:21
, ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/34

« Previous : 1 : ... 5 : 6 : 7 : 8 : 9 : Next »

블로그 이미지

철도를 명절 때에나 떠오르는 4대 교통수단 중 하나로만 아는 것은, 예수님을 사대성인· 성인군자 중 하나로만 아는 것과 같다.

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2021/10   »
          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
31            

Site Stats

Total hits:
1674376
Today:
38
Yesterday:
622