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

1. 단품 판매되는 DOS

(1) 197, 80년대에는 컴 단말기가 아니라 개인용 컴퓨터라는 건 이제 막 정립되고 있었고, 소프트웨어도 하드웨어와 함께 딸려 나오는 게 아니라 독립된 제품이라는 인식이 이제 막 정립되던 중이었다.
그래서.. 마소에서 만들었던 MS-DOS도 말이다. 1.0부터 4.x에 이르기까지는 다들 PC와 함께 OEM 형태로만 공급됐다. 도스 자체가 단품 패키지로 개별 소비자에게 retail 판매되기 시작한 건 1991년, 무려 5.0부터였다고 한다. himem.sys와 DOS=HIGH가 첫 도입됐던 그 역사적인 물건 말이다.

아 글쎄.. Windows 1.x 시절이던 1986년에 3.2 버전도 단품 패키지가 있긴 했다. 하지만 이때는 이 방식이 오래 지속되지는 못한 듯하다.

현실적으로 대다수 사용자들이 패키지 판매를 기억하는 건 아무래도 끝물인 6.x버전이지 싶다. 이 무렵에 마소는 IBM과 사이가 단단히 틀어져서 PC-DOS와 MS-DOS의 격차도 벌어지고, Windows와 OS/2도 격차가 벌어졌었다.
1990년대 들어서 MS-DOS는 이렇게 독립을 했는데, 매크로 어셈블러(Macro Assembler)는 그 무렵쯤에 반대의 길을 갔다. 단독 독립 제품으로서는 단종이고, MS C/C++이나 Visual Studio 같은 더 큰 제품에서 제공되는 유틸리티로 흡수되었다.

(2) MS-DOS가 대기업의 PC와 함께 공급되던 시절, 대략 쌍팔년도 정도까지는 한글 MS-DOS에 내장돼 있던 한글 바이오스도 PC 제조사들별로 제각각이었다.

• PC 제조사: 대우, 금성, 현대, 삼보 등
• 제3자 써드파티: 도깨비, 한메, 태백 등
• 마소 자체 개발: hbios, mshbios. Windows 3.1 + MS-DOS 6부터.

한글 바이오스 만드는 게 첨단 시스템 프로그래밍이던 시절이 있었다니.. 추억 돋는다. =_=;;
기능이 제일 많고 성능도 뛰어나던 건 역시 써드파티 제품들이었다. 조합형도 지원하고, 다양한 폰트와 글자판(세벌식까지)도 지원했지만.. 역시 1990년대 중후반쯤부터는 개발의 맥이 끊겼다.
현재 한글 바이오스가 돌아가는 중인지를 무슨 API를 호출해서 어떻게 판별했는지 궁금하다.

(3) MS-DOS는 버전 1부터 4까지는 OEM이었고 5~6 사이에 잠깐 독립 제품.. 그리고 마지막 7~8 버전은 Windows 9x에 포함된 채로 제공.. 이렇게 역사가 정리된다.
그 중에 OEM 끝자락이던 MS-DOS 4는 DOS shell이 처음 도입되었고 FAT16 파일 시스템의 개편으로 하드디스크 용량을 2GB까지 인식할 수 있게 하는 큰 변화가 있었다(종전에는 꼴랑 32MB까지만.. =_=) 하지만 4.0은 버그가 너무 많아서 곧 4.01로 패치가 돼야 했다.

이건 마치 버그가 너무 많아서 온갖 서비스 팩들이 덕지덕지 나와야 했던 Windows NT 4의 행로와도 비슷해 보인다.
그리고 개발툴 중엔 Visual Studio .NET 첫 버전(2002, 7.0)이 금세 묻혀 버렸던 것과도 처지가 비슷하다.

(4) 끝으로.. MS-DOS의 대체품으로 DR-DOS라는 게 있기도 했고, 그걸 한때 네트워크 솔루션으로 유명했던 어느 기업에서 인수하여 노벨 도스로 계승되었다.
한편, MS-DOS의 셸만 대체해서 강화한 제품으로 4DOS라는 게 있었다. 그걸 노턴 유틸리티에서 인수해서 더 발전시킨 게 NDOS...이다. 노벨 도스와 이니셜이 같지만 이들은 서로 다른 제품이다.

2. Rational

옛날에 Rational이라는 이름을 가진 컴퓨터 소프트웨어 회사가 둘 있었다.

(1) Rational Software는 소프트웨어공학 툴이라고 해야 하나.. 딱 정확하게 개발툴, IDE나 컴파일러는 아니지만 어쨌든 소프트웨어 설계· 개발과 관련이 있는 전문 도구를 개발해 왔다. 콕 집어 코딩, 프로그래밍이라기보다는.. 더 거시적인 소프트웨어 개발 말이다.
Rose라는 툴이 유명했다. 꽃하고는 별 관련 없고, 다른 단어들의 이니셜이 저렇게 된 거지 싶다. 내 기억으로 Visual C++ 6 시절에 엔터프라이즈 에디션에는 Rose의 데모 축소판이 번들로 제공됐던 적이 있었다.

얘의 제조사는 2003년에 IBM에 인수됐다. IBM이 PC용으로 소프트웨어를 만든 게 지금은 망한 운영체제 OS/2, 그리고 유구한 역사를 자랑하는 통계 패키지 SPSS 정도밖에 없는 줄 알았는데.. 지금은 Rose도 IBM 휘하로 넘어갔는가 보다.
하긴, 엑셀에 대항하여 넥셀이 있고, AutoCAD에 대항하여 캐디안이 있는 것처럼.. Rose의 저렴한 국산 대체제로 StarUML이라는 제품도 있다.

개인적으로는 직장에서 보고서 쓸 때 각종 UML 다이어그램 그리는 용도로 사용해 봤다.;; 클래스 관계 모식도라든가 각종 시퀀스 다이어그램 따위..
하긴, 그 비싼 프로그램에 겨우 다이어그램을 그리는 기능밖에 없으면 그냥 Visio 같은 벡터 드로잉 툴과 아무 차이가 없을 것이다. 그럴 리는 없고, 여기서 만든 설명대로 Java 클래스 파일을 생성하고 문서를 생성하는 기능도 있었던 걸로 기억한다.

(2) 그 다음으로 Rational Systems라는 곳이 있었다. 얘는 1980년대부터 DOS extender만 전문으로 개발해 왔다. 16비트에 640KB 메모리에 쩔어 있던 도스 환경에서 보호 모드를 구현하고, 메모리를 골치 아픈 제약 없이 32비트 그대로 접근하게 해 주는 획기적인 런타임 말이다.

사실, DOS extender라는 걸 처음으로 개척한 회사는 Phar Lap이었다. 워크스테이션에서나 돌릴 만한 거대한 업무용 프로그램을 PC용으로 포팅할 때 원래 Phar Lap의 extender가 주로 쓰였다. 옛날에 도스용 아래아한글도 전문용 내지 32비트 에디션은 얘를 사용했다.

그러나 Rational Systems에서는 DOS/4G라는 제품을 개발하고, 이걸 Watcom C/C++ 컴파일러에 DOS/4GW라는 번들 버전으로 아주 저렴하게 공급해 줬다. 1993년 말에 Doom이라는 게임이 딱 이 솔루션을 사용해서 출시되면서 DOS/4GW라는 32비트 extender는 세계적인 히트를 치게 됐다.

환상적인 그래픽을 선보였던 Doom이 어셈블리어를 거의 쓰지 않고 이식성 높은 C 코딩으로만 구현될 수 있었던 비결엔 이런 신기술이 있었던 것이다. 물론 그래픽을 제대로 보려면 그 당시로서는(1993~1995) 아직 가격이 부담되는 고성능 컴터이던 486급이 필요했지만 말이다.

그리고 Doom은 이 장르에서 하드웨어 가속이 없이 CPU 연산/소프트웨어만으로 동작한 마지막 게임이기도 했다. ^^ 이렇게만 동작해서는 320*200보다 더 높은 해상도에서 3D 폴리곤 그래픽이 실시간 애니메이션으로 나오기란 굉장히 무리였을 것이다. 뭐, 그래픽의 하드웨어 가속에도 더 높은 데이터 대역폭이 필요할 것이고, 32비트 버프가 기여했다고 볼 수 있다.

1990년대 중후반까지 덩치 큰 도스용 게임들은 처음 실행될 때 DOS/4GW 로고가 뜨는 게 무척 많았다. 이게 무슨 흥행 보증수표처럼 느껴질 정도로..;;
PC 역사에 한 획을 그었던 이 개발사는 훗날 Tenberry Software이라고 이름이 바뀌고 2000년대 초반까지는 살아 있었다. 하지만 도스 시절이 끝난 뒤엔 없어졌는지 근황을 모르겠다.

요컨대, 두 Rational들은 분야는 다르지만 과거에 뭔가 비범한 소프트웨어들을 개발하곤 했다. ^^.

3. 옛날에 C++ 코딩 환경

난 왕년에 이런 시퍼런 화면에서 코딩을 해 봤다. -_-;;

쌍팔년도를 넘어서 1990년대가 되자.. 이제 막 C가 아니라 C++ 직통 컴파일러라는 게 처음으로 등장했다. 그리고.. IDE의 텍스트 에디터에 syntax coloring이라는 게 제공되기 시작했다.
코드에서 예약어는 진하게 표시하고, 전처리기는 별도의 색깔로, 상수 리터럴이나 주석도 별도의 색깔로.. 이거 말이다. 하긴, 1990년대는 이제 막 VGA와 컬러 모니터가 보급되었던 시절이고, 286이니 386이니 하던 컴터 성능도 실시간 컬러링을 구현해도 될 정도로 향상됐다.

그 당시 도스용 컴파일러의 본좌는 볼랜드...였는데, Turbo C++ 3.0 버전부터 IDE에서 컬러링이 지원되기 시작했다. 1과 2 시절엔 저런 게 아직 없었다.
오 그런데... 말로만 듣던 Turbo C++와 Borland C++가 차이가 있었나 보다. 난 Turbo C++ 것만 어린 시절에 직접 봤었다.
일반 명칭은 초록색, 문자열 상수는 빨강, 전처리기는 저렇게 청록색 바탕, 기호가 노란색 말이다.

그러나 Borland C++은 보니까 일반 명칭이 노랑, 문자열 상수는 청록, 전처리기가 초록, 기호는 하양이다.
난 도스용 볼랜드 개발툴 IDE에서 C++의 컬러링이 저렇게 되는 건 직접 본 적이 없고, 구글 검색을 통해서 난생 처음 본다. 비슷한 시기에 동일 회사에서 내놓았던 Borland Pascal과 더 비슷해졌다. 우와..

사실, Turbo와 Borland의 차이는 Visual Studio로 치면 standard 에디션(개인용)과 enterprise 에디션(기업용) 같은.. 에디션 급의 차이와 비슷하다.
아.. 옛날에.. 볼랜드 IDE를 따라 djgpp 진영에서 개발했던 rhide는.. C/C++ 코드에 대한 컬러링이 Turbo가 아니라 Borland C++ 스타일이었다. 자, 난 저런 것도 기억하는 세대다. -_-;;;;

프로그래밍, 코딩이라는 건 30년 전이나 지금이나 재미있다.
참고로, 코딩 하다가 .이나 ->를 찍었을 때 멤버가 쫘르륵 나오고 명칭이 자동 완성되는 기능은..
1990년대 "말"이 돼서야 제공되기 시작했다. 그건 그만큼 구현하기 더 어려운 기능이었고, PC가 못해도 펜티엄 2 이상급으로 성능이 좋아진 뒤에나 쓸 만했다.

요즘은 이 기능이 없으면 너무 불편해서 코딩을 못 할 것이다. 옛날에 텍스트 에디터가 불편하고 컴퓨터 메모리가 부족하던 시절에는 각종 함수 명칭을 아주 짧고 암호 같이 붙이는 게 관행이었지만..
지금은 코드 양이 너무 방대해지고 저런 자동 완성 기능도 발달하니 길게 길게 풀어서 써 주는 편이다. setmemmgr() 대신에 SetMemoryManager() 같은 식.

4. PowerBasic

198~90년대에.. BASIC이라는 프로그래밍 언어는 입문하기 간편한 대신, 인터프리터 방식 위주이고 실행 속도가 느리다는 게 상식 겸 통념이었다. 즉, 언제까지나 교육용이지, 실무용은 "영 아니올시다"였다. 그러나 BASIC에 대해 그 통념을 정면으로 도전하고 반박하는 이단아 제품이 있었으니, 바로 PowerBasic(파베)이었다.

얘는 BASIC이라는 언어에다가 C/C++ 같은 이념을 접목했다. 마소처럼 느린 P-code 갖고 깨작거리거나 비주얼 RAD 툴 컨셉을 씌우는 게 아니라, 최적화되고 단독 실행 가능한 네이티브 코드 컴파일을 추구했다. 그렇다, 이 컴파일러 엔진을 만든 주 개발자는 그야말로 x86 어셈블리어에 정통한 smaller, faster 최적화 덕후 장인이었다.

PowerBasic은 마이너 비주류 제품군이지만 나름 존재의 의미는 있었다. 베이식 언어로 C/C++ 급의 작고 빠른 프로그램을 생성해 줬기 때문이다. 자기 자신의 덩치도 Visual Studio에 비하면 그냥 깃털 같은 수준이니 아주 실용적이었다.

얘는 16비트 도스에서 32비트 Windows까지는 잘 갈아탔다. 하지만 그 이후의 시대 변화에는 따라가지 못한 채, 2020년대에 와서는 명줄이 사실상 끝난 상태이다.
일단, 주 개발자인 Bob Zale 할아버지가 별세한 지가 이미 10년이 넘었다. 적절한 후임 개발자를 양성하지 못했는지, 파베는 x64건 arm64건 일단 64비트 버전이 못 나오고 있다.

살상가상으로.. PowerBasic 컴파일러 자체부터가 통짜 어셈블리어=_=;;;로 개발됐고, 코드가 호락호락 maintainance 가능한 구조가 아니라고 한다. 이러면 뭐 과거의 OS/2나 dBASE 같은 꼴 나면서 죽는 건 시간 문제지..
그렇게도 성능에 목숨 걸었다지만, 최신 멀티코어 프로세서나 GPU에 맞춰진 컴퓨팅을 잘 지원한다는 얘기도 난 못 들었다. 이러면 머신러닝 스크립트인 파이썬의 용도를 대체하기도 대략 곤란해진다.

지금 생각하면 PowerBasic이 뭔가 슈퍼컴 Cray 같은 물건이라는 생각도 든다. 고전적인 성능 덕후 장인이 애지중지 만들었지만 시 대에 뒤쳐지고 도태됐다는 점에서 말이다.
글쎄, 쟤는 그 성능빨에다가.. 마소에서 버린 자식인 클래식 Visual Basic 6 코드를 지원하는 후속 써드파티 개발툴을 표방하고 나섰으면.. 마르지 않는 고객 수요를 확보하고 절대로 망할 일이 없었을 것 같은데 말이다. 그렇지 않은가? 이렇게 사라지기에는 아깝고 아쉽다.

쌍팔년도 시절에 볼랜드와 마소가 PC용 베이식, C, 파스칼 컴파일러 시장을 꽉 잡고 있긴 했다. 하지만 그 컴파일러들은 처음부터 그 회사에서 만든 게 아니었다. 다들 다른 사람이나 영세업체의 제품을 인수한 것에서부터 개발을 시작했다.

• BASIC/Z by Bob Zale --> Turbo Basic (요게 PowerBasic의 전신)
• Wizard C by Bob Jervis --> Turbo C 1.0 in 1987
• PolyPascal by Anders Hejlsberg --> Turbo Pascal
• Lattice C --> Microsoft C

Posted by 사무엘

예전에 했던 말도 있지만.. 암튼 지난 30여 년에 달하는 컴퓨터의 역사를 곱씹어 보는 건 재미있다~!

1. 인텔 CPU

(1) 인텔 8086은 유구한 x86 시대의 서막을 연 기념비적인 16비트 CPU이다(1978). 나중에 출시된 8088은(1979) 거기에서 외부 데이터 버스만 8비트로 낮춰서 성능을 약간 디버프 했지만 가격도 낮췄다.
80186의 존재감은 비행기에서 보잉 717의 존재감과 아주 비슷하게 듣보잡이다. -_-;; 애초에 PC보다는 임베디드용으로 만들어진 8086의 변종이었다.

(2) 80286의 제일 큰 존재 의의는 보호 모드의 첫 지원이지만.. 이게 많이 부족하고 불완전해서 역시 듣보잡으로 묻혔다. CPU로서 80286은 그냥 클럭 속도 더 빨라진 8086이나 다름없고, 현실적으론 컴퓨터 완성품으로서 AT (286 기반)가 XT (8088 기반)보다 나아진 점이 훨씬 더 많이 와 닿곤 했다. 2HD 고밀도 디스켓, 배터리 기반 시계, 키보드 속도 조절 등..
그에 비해 101키 키보드, VGA 컬러 그래픽이나 하드디스크는 XT에도 일단 장착 가능은 했던 구성요소이다.

(3) 80386은 드디어 32비트 CPU이다. 32비트 정도는 돼야 어지간히 큰 정수라든가 부동소수점을 원활히 표현할 수 있고, 메모리 주소 공간도 넉넉히 확보해서 보호 모드 가상 메모리 같은 것도 구현할 수 있다.
오리지널 DX는 외부 데이터 버스와 메모리 주소 버스도 모두 32비트인 반면, 염가 다운그레이드 에디션으로 나중에 출시된 SX는 이게 각각 16비트, 24비트였다. 과거 8086과 8088의 관계와 거의 동일하다.

(4) 80486도 DX와 SX 구분이 있었는데, 이때는 단순히 부동소수점 코프로세서가 기본 내장된 게 DX이고, 안 그런 게 SX였다. 거기에다 486은 DX조차도 클럭 속도를 더 끌어올린 DX2, DX4 이런 구분이 있었다.
이때 'VESA 로컬 버스' 규격 갖고 많이 떠들곤 했다. 천상 486 전용 규격으로 쓰이다 말았지만..
그리고 캐시 메모리라는 게 들어가기도 하고.. 486이 386에 비해 많이 발전하긴 했었다.
1990년대 중반, 486? 펜티엄쯤부터 컴퓨터 본체의 모양이 모니터 아래에 가로로 놓는 게 아니라 모니터 옆에 세로로 놓는 형태로 슬슬 바뀌어 정착했다.

(5) 펜티엄은.. 외부 데이터 버스가 CPU의 레지스터보다도 더 큰 64비트로 확장됐다. 물론 그렇다고 펜티엄이 아키텍처 차원에서 64비트 CPU인 건 아니었다.
인텔 셀러론의 초창기 버전은 펜티엄 2에서 L2 캐시 메모리가 없는 보급 염가판이었다. 그런데 이게 아예 전혀 없으니까 성능이 너무 떨어져서 나중에는 캐시가 약간이나마 장착되기도 했다.

이렇듯, 컴퓨터의 성능에는 클럭만 영향을 끼치는 게 아님을 알 수 있다.
그리고 한때는 옵션으로 주어졌던 요소들이 나중엔 다 기본으로 포함돼 들어가고 다른 새로운 기능이 옵션으로 도입된다.

2. Windows 운영체제

• Windows 3.0은 MDI 창, VGA와 본격적인 컬러 지원을 위한 장치 독립 비트맵(DIB), WinHelp(!!!) 같은 획기적인 기능을 도입했고, 3.1에서는 OLE, 트루타입 글꼴, 공용 대화상자를 도입함으로써 현대의 Windows 근간을 닦았다.
• 거기에다 Windows 3.0은 386 확장 모드라는 걸 도입해서 80386 이상 CPU에서 지원되는 보호 모드 멀티태스킹 기능을 일부 사용하기도 했다. 하지만 앱이 전반적으로 돌아가는 건 다 16비트 기반이다.
• Windows NT는 저렇게 도스 진흙탕인 기존 Windows와는 달리, 미래를 바라보며 개발됐다. DEC Alpha라는 64비트 CPU용 에디션이 있기도 했으나.. 이때는 컴퓨터의 메모리도 4GB보다 훨씬 모자랐고 Windows 역시 그냥 32비트 모드로 동작했다고 한다. 포인터 8바이트니 INTPTR이니 그런 거 없었다는 뜻..

그렇기 때문에 Windows의 역사상 최초의 진정한 64비트 프로그래밍을 개막한 아키텍처는 IA64였다.
그 전 20세기의 NT4 시절에는 DEC Alpha뿐만 아니라 PowerPC네 MIPS네 여러 자잘한 아키텍처를 지원하다가 말았고, 2000년대부터는 x64와 ARM64가 살아남았으니 2000년대 초가 중대한 전환점이었다.

허나, 그 전환점의 중심에 서 있던 IA64는 좋은 타이밍을 날리고 장렬히 자폭했다... =_=;; 사실은 IA64가 채택했던 VLIW라는 설계 방식부터가 성능 대비 단점과 위험 부담도 너무 큰 방식었다. 마치 자동차 엔진에서 통상적인 왕복 엔진이 아니라 로터리 엔진처럼 말이다.
이런 사연으로 인해 Windows 2000은 NT 계열의 개발 역사상 전무후무하게 오로지 x86 전용으로만 출시되는 이변이 벌어졌었다. 무슨 9x처럼 말이다.

• Windows 98은 마우스 휠과 멀티모니터를 최초로 공식 지원하기 시작했다.
• Windows 2000/ME에서는 일부 마우스의 옆구리에 달려 있는 추가 버튼을 L, R 말고 X-button이라는 이름으로 최초로 지원하기 시작했다. 아마 전통적인 상하 스크롤 말고 좌우 스크롤 휠도?
• Windows 7은 SSD와 멀티터치 디스플레이를 최초로 공식 지원하기 시작했다.

아울러,

• USB 메모리를 별도의 드라이버 설치 없이 자체적으로 인식하기 시작한 건 2000/ME부터다.
• XP/Vista 어느 때쯤부터 이제 와이파이도 별도의 프로그램/드라이버 설치 없이 자체적으로 잡기 시작했다.
  무슨 프로그램 띄워서 모뎀 전화를 걸어서 인터넷 접속하고, 그 뒤부터 연결 시간이 올라가던 게 1990년대 말쯤 일이었는데.. 참 격세지감이다.

3. 하드웨어의 발전 양상

성능 증가

• 1990년대 동안은 클럭 속도가 뻥튀기 하듯 폭증했다.
• 1990년대 후반부터는 메모리 양이 폭증했다. Windows 95~98 사이 말이다.
• 2000년대 이후부터는 무선 인터넷 네트웍 속도가 폭증해 왔다.

64비트화

• 워크스테이션/슈퍼컴 쪽은 모르겠고, 개인과 가정 레벨에서는 1990년대 말에 게임기부터 가장 먼저 64비트 CPU를 도입했다. 내 기억으로 닌텐도64..;;
• PC는 2000년대 초에 IA64가 대차게 망하는 바람에 한 타이밍을 완전히 놓쳤고, 2000년대 중반쯤 램 용량이 실제로 4GB를 넘긴 뒤에야 64비트가 대중화됐다. Windows 2000/XP가 아니라 Vista/7 타이밍이다.
• 스마트폰 업계는 2010년대 중반쯤에 슬슬 64비트로 전환이 시작돼서 2010년대 말엔 32비트 앱에 대한 지원을 끊네 마네 하는 상태가 된 것 같다.

오늘날 경전철이라고 해서 협궤를 쓰는 게 아니듯, 주머니에 넣어 다니는 작은 모바일 컴퓨터라고 해서 16/32비트 따위를 쓰지는 않는다. 커다란 화면에다 현란한 천연색 3D 그래픽과 고화질 동영상을 찍으려면 64비트 고성능 CPU는 필수이다. 물론 고성능 CPU는 전기도 많이 먹으니 고성능 배터리도 필수..

4. 그래픽

(1) 그래픽 가속이라고 하니까 게임용 3차원 그래픽 렌더링이라든가 동영상 코덱 같은 것만 떠올리기 쉬운데.. 사실은 2D 기반의 통상적인 GUI 구현을 위해서도 작은 수준의 하드웨어 가속이 오래 전부터 쓰여 왔다.
마우스 포인터라든가(깜빡이지 않는 것, 마우스 포인터 자취 표시, 포인터 주변의 그림자).. 화면 스크롤도 다 가속의 결과물이다. CPU 연산 기반으로 도트를 옮기는 수작업이 아니다.

(2) Windows의 그래픽 API (GDI)는 너무 범용적이고 장치 독립적으로 만들어졌다 보니, 당장 화면에 그려지는 픽셀 도트 값을 알아 내거나 색깔 바꾸기, 메모리 내용을 그대로 비트맵으로 간주해서 뿌리기 같은 간단한 작업조차도 오버헤드가 크고 일이 쉽지 않았다.
비디오 메모리에다 숫자 하나만 쓰면 끝날 일을 뭐 펜을 만들고 브러시를 만들고 DC에다 select시키고.. 운영체제 차원에서 직통 접근을 허용하지 않았던 것이다.

그러던 것이 Windows 3.0에서 DIB가 도입됐고, Windows 95 내지 NT 3.5에서 CreateDIBSection 계열 함수가 추가됨으로써.. 메모리 내용을 비트맵으로 그대로 뿌리는 일은 그럭저럭 가능해졌다. 옛날 WinG가 제공했던 기능도 다 이런 것들이었다. ‘비트맵 고속 전송’
다른 3D 가속 같은 거 전혀 없이 이거 하나만으로 Windows에서 Doom을 포팅하고 돌릴 수 있게 됐다.;;

Doom은 3D 전용 가속 기능이 없이 CPU와 초보적인 그래픽 가속만으로 만들어진 마지막 3D FPS였던 셈이다.
이거 마치 인어공주가 CG 없이 100% 셀 애니로만 만들어진 마지막 디즈니 애니인 것과 비슷한 느낌이다.

(3) 하긴, 옛날에는 그래픽 파일의 압축이라는 것도 원시적인 run-length 방식이 고작이었다. 더 빡세게 압축된 GIF나 PNG 파일 하나 열려면 386급 이상 컴퓨터가 필요했고, 디코딩도 훨씬 더 오래 걸렸었다. 하물며 JPG는 뭐 말할 것도 없고..
동영상조차도 1990년대 초중반에 Video for Windows 이러면서 나돌던 AVI는 쌩 run-length 압축인 게 많았다. 화질이나 압축률은 완전 허접 수준이었다.

WinAMP로 486/펜티엄 급 Windows 95 PC에서 128kbps짜리 mp3을 하나 재생하면 CPU 사용률이 10~20%까지 치솟았는데.. 이 역시 아련한 추억이다.
지금 우리가 전화기로도 당연하게 감상하는 디지털 멀티미디어 데이터들이 불과 2~30년 전에는 이렇게 가볍게 다뤄지던 물건이 전혀 아니었다. 그나마 가볍게 다루려면 기술 수준이 더 낮은 아날로그 매체만으로 만족해야 했다.;;

5. 나머지

(1) 64비트와 멀티코어는 서로 다른 별개의 분야이지만 거의 같은 시기에 태동해서 동시에 도입됐다(Core 2 Duo). plug & play와 USB하고 비슷한 관계인 것 같다. Win95/98 시절엔 USB 없이 직렬 포트에다가 프린터나 스캐너를 연결하고는 "새 하드웨어 발견.." 이러기도 했었다는 것 기억 나시는가? =_=;;
아울러, 모니터가 와이드 화면이 대세가 된 것도 2000년대 중반쯤으로 64비트니 멀티코어니 하던 때와 시기가 아주 비슷하다.;;

(2) 2000년대 초중반, 사운드 카드가 '인텔 사운드맥스'인지 뭔지 아무튼 메인보드에 내장돼 들어갔다. 그래픽 카드도 어지간히 까다로운 게임을 하는 게 아니라 기본 기능은 그냥 메인보드 내장으로 퉁쳐졌다.

(3) 요즘 노트북이나 스마트폰은 너무 얇아져서 뭔가를 꽂는 단자조차 너무 간소화되는 것 같다. 이건 개인적으로 좀 불편하게 느낀다.;;
가령, 구형 맥북은 큼직한 USB-A를 바로 꽂을 수 있지만 요즘 맥북은 그렇지 않고 C형만 꽂을 수 있다. 그리고 구형 갤럭시는 컴터용 이어폰을 바로 꽂을 수 있는 반면, 요즘 갤럭시는 그렇지 못하다.

(4) 범용적인 컴퓨터 말고 다른 기계들의 사정은 어떨까?
가정용 게임기, 업소용 오락기.. 이 둘도 차이가 있을 것 같고 내비게이션, 노래방 기계, 그리고 VR 게임기에 쓰이는 컴퓨터도 평범한 가정용 CPU 기반은 아닐 것 같은데.. 심지어 x86 계열이 아닐지도..??
요즘은 폰에 밀려서 디지털 카메라라는 물건이 많이 도태했지만, 그래도 부팅이 엄청 빨리 되는 것과 zoom이(= 렌즈빨) 더 뛰어난 건 디카만의 독자적인 장점이다. 그런 기기를 프로그래밍 하는 건 아무래도 임베디드 영역이지 싶다.

Posted by 사무엘

1. 자연어 처리

우리나라 헌법 전문은 무진장 길고 복잡한 만연체인데, 결국 핵심은 "대한국민은 헌법을 개정한다"이다. ㄲㄲㄲㄲㄲㄲ
자, 문장 구조를 파악하기 위해 프로그램 코드처럼 들여쓰기를 적용해 주면 얼추 다음과 같다.

다만, 이런 요지의 문장 자체는 제헌헌법 시절부터 있었다고 한다. 따지고 보면 국민 교육 헌장이 기존 헌법 전문으로부터 영향을 받은 것이다.

2. AI

Posted by 사무엘

컴퓨터의 정보 기억장치는 다음과 같은 속성에 따라 분류 가능하다.

(1) 배열처럼 아무 지점이나 O(1) 시간 복잡도로 즉시 접근 가능한가? 아니면 링크드 리스트처럼 순차적으로만 접근 가능한가?
Random Access memory라는 건.. 아무렇게나 읽고 쓰기가 가능하다는 뜻이 아니라, 임의 지점 접근이 가능하다는 뜻이다.
물론 오늘날은 테이프 같은 극단적인 물건 말고는 RAM이 당연시되고 있다. 테이프는 임의 접근이 안 되니 번거로운 감기 기능이 필요했지만.. CD는 아무 트랙이나 바로 갈 수 있다.

(2) 읽고 쓰기 가능한가, 아니면 읽기 전용인가?
ROM이라고 불리는 물건들은 RAM의 속성을 지니면서 동시에 ROM인 셈이다. ROM은 RAM의 엄밀한 반의어가 아니니 유의할 것.
CD 같은 광학 디스크는 요즘 기술로 '쓰기' 자체는 가능하다. 하지만 아무 부작용이나 부담 없이 자유자재로 아무렇게나 쓸 수 있는 건 아니다.

(3) 휘발성인가, 비휘발성인가
아주 중요한 속성이다. 전원이 끊어지면 내용이 싹 다 날아가느냐, 아니면 그 뒤에도 내용이 남아 있느냐? 읽기 전용 메모리는 당연히 비휘발성이어야 할 테니 이건 읽쓰 겸용 메모리가 대상이다.
반도체 기반의 주메모리는 속도가 빠른 대신 전자이고, 나머지 보조 기억장치들은 느린 대신 용량 많고 후자의 속성을 지닌다.

(4) 매체와 reader/writer가 쉽게 분리 가능한가? 아니면 붙박이인가?
이거 무슨 철도 차량으로 치면 기관차-객차 vs 동차 같은 차이점 같다.

(5) 그리고.. 어떤 기술 배경에 따라 만들어졌는가?
다음과 같이 세 계열로 나뉜다.

1. 자기장: 테이프, 디스켓 // 디스크, 드럼.

매체 분리형에서는 테이프만이 무슨 방송국이나 데이터센터 급의 백업/아카이빙 용도로 쓰이고 있고 나머지는 도태했다. 디스켓이고 zip드라이브고 뭐고 다 망했으니까. 붙박이형은 디스크만이 '하드'의 형태로 남고 다 도태했다.
1950년대에 슈퍼컴퓨터 용으로 무려 5MB짜리 하드디스크를 지게차에다 조심스럽게 실어 나르던 시절을 보면 참 격세지감의 극치가 따로 없다.

여기는 전통적인 트랙이니 섹터니 하는 구조 구분과 '포맷'이라는 게 통용되는 기억장치이다. 하드디스크는 실린더라는 것도 있었고 말이다.
똑같은 디스켓이라도 운영체제에서 소프트웨어적으로 공간 구획을 구분하고 인식하는 방법이 다르다. 과거에는 플랫폼과 운영체제에 따라 이런 파편화가 더 심했기 때문에 디스켓들이 포맷되지 않은 채로 판매되곤 했다. 물론 IBM PC와 MS-DOS가 천하를 평정한 뒤부터는 디스켓들이 다 미리 포맷되어서 나오기 시작했다.

하드디스크는 전원이 끊어질 때 안전을 위해 파킹이라는-_- 마무리 동작도 권장되곤 했다. 물론 훗날 자동 파킹이 지원되면서 별도의 파킹 유틸리티는 화면 보호기만큼이나 별 필요 없는 눈요기 잉여로 전락했다.

2. 반도체: USB 스틱, SD카드 // SSD

메모리 반도체는 100% 전자식으로만 동작하는 물건이다. 빠른 대신에 비싸고, 무엇보다도 그 특성상 전기가 끊어지면 내용도 다 날아가는 '휘발성 메모리' 전용이었는데.. 기술의 발달로 보조 기억장치 역할도 가능한 메모리 반도체가 등장했다.
얘 덕분에 기존의 테이프나 디스켓이 완전히 전멸해 버렸다. 그리고 SSD도 가격 내려가고 용량 올라가면서 기존 기계식 하드디스크의 입지를 상당수 위협하고 있다.

SSD는 조각 모음이 필요하지 않으며, 동작하는 특성이 기존 디스크와는 많이 다르다.
USB 스틱은 매체와 구동부가 일체형인 반면, SD카드는 매체와 구동부가 분리돼 있다. (별도의 reader가 필요)
옛날 8비트 시절에 게임용으로 쓰였던 롬팩 카트리지도 1번이 아니라 2번 반도체 기반이었던 거지..??

전자기기에서 캐퍼시터(축전기)와 본격적인 화학 전지의 관계가 반도체 메모리와 타 보조 기억장치의 관계하고 비슷해 보인다~!!
전자는 충전· 방전이 아주 빠르고 용량이 아주 작으니까. 그리고 캐퍼시터를 용량을 왕창 키워서 배터리처럼 사용하려는 연구가 진행 중이기도 하다.

3. 광학(레이저)

얄팍하고 비까번쩍 빛나고 뭔가 하이테크스럽게 생긴 원반이다. 1990년대에 첫 등장했을 때는 얼마나 간지 뽀대 났겠는가.

얘는 그 특성상 붙박이라는 게 존재하지 않고 드라이버와 매체가 분리돼 있다. 기억장치들 중 디지털 방식의 음반· 영상매체와 가장 친화적이라는 특징도 있다. (그 반면, 테이프는 '아날로그' 방식의 매체..)
얘는 '쓰기'와는 그렇게 친화적이지 않다. 디스크에다가 작정하고 새로 기록 추가만 가능하며, 한번 새겨 버린 내용을 자유자재로 덮어쓸 수 없다. 평범한 디스크 저장이 아니라 종이에다 인쇄하는 것과 얼추 비슷하다고 생각해야 한다.

디스크의 영어 스펠링은 disk와 disc가 혼용되는 듯한데.. disc는 특별히 대놓고 원반 모양인 광학 매체에 한정되어 쓰이는 것 같다. 가령, 하드는 hard disk이지만, CD는 compact disc이다.
그리고 CD(+ DVD, 블루레이)는 지름이 12cm인 반면, 과거에 있었던 레이저 디스크는 지름이 12인치였다는 아주 흥미로운 차이점이 있다. 뭐, 거기에다 미니CD라고 지름 8cm짜리 규격도 있긴 하고 말이다.

한때 광학 기억장치는 용량이 방대하다는 장점이 있었지만 오늘날은 빛 바랜 장점이다. 이제는 컴퓨터에서 광학 드라이브 자체가 거의 퇴출되었고, 운영체제 설치도 그냥 네트워크나 USB로 다 되는 세상이 됐다.
그래서 DVD의 다음 규격인 블루레이는 용량이 더 방대함에도 불구하고 오늘날 존재감이 매우 미미하다. 블루레이에다가 수십 GB짜리 패키지 게임을 담아서 판매하는 시대도 아니니 말이다.

옛날에는 뭔가 레이저를 사용하는 컴퓨터 주변기기는 가격이 억소리 나게 비쌌던 걸로 악명 높았다. 레이저 프린터, 그리고 씨디 라이터.. 그게 어쩌다가 가격이 확 떨어지고 개인용 컴퓨터에 씨디를 굽는 기능까지 내장되어 들어갔는지.. 경이롭기 그지없다.
기껏 들어갔던 기능이 이제는 필요 없어져서 퇴출되는 지경이고..

※ 여담 1: 옛날 추억 더

• 1990년대에 VGA 이후로 SVGA 그래픽 카드들이 표준 규격 없이 난립했던 것처럼.. 확장 디스켓도 표준 규격 없이 너무 난립했던 것 같다. 더구나 USB니 plug & play니 없던 시절에는 하드나 디스크 드라이브를 하나 더 장착하는 것도 엄청나게 어렵고 컴퓨터 하드웨어 지식이 많이 필요하던 과업이었다. 그러니 그런 싸제 물건들이 성공적으로 보급되기가 어려웠다.
  
  
• 그나저나 이 바닥은 자동차 브레이크 말고도 '디스크와 드럼'을 쌍으로 구경할 수 있는 또 다른 분야인 게 신기하다. '자기 드럼'은 어떤 형태로 동작하는 물건이었을까..?? 개인적으로 무척 궁금하다.
  
  
• 옛날에는 테이프나 디스크에 물리적인 쓰기 방지 탭이나 딱지 같은 게 붙어 있기도 했지만.. 요즘은 그런 관행을 찾을 수 없다. (운영체제 셸이 그런 데다가도 메타데이터나 썸네일 캐시 같은 걸 임의로 써 넣곤 함)
  
  
• 옛날에는 광자기 디스크라는 것도 있었던 것 같은데.. 뭐지? 1번과 3번의 하이브리드인가 싶다.

카세트 테이프(자기장)나 롬 카트리지(반도체)는 8비트의 산물이다. 16비트 IBM 호환 PC급에서 저런 것들을 취급하는 사례는 내가 아는 한 없다.
그 대신 디스켓 FDD는 컴퓨터 붙박이 형태로 16비트 이후 시대를 풍미했다가 64비트 시대에는 사실상 전멸했다.
CD-ROM은 16비트 도스 시절에도 존재하긴 했지만 mscdex니 뭐니 하는 굉장히 무거운 드라이브를 실행해야 사용 가능했다. 그리고 386, 486급 이상 PC의 전유물이었다.
그 뒤로 USB 메모리는 도스와의 유의미한 접점이 없다. ^^

아무리 생각해도 1990년대 중후반에 plug & play와 USB는.. 2000년대 중후반의 64비트와 멀티코어하고 굉장히 비슷한 관계인 것 같다.
서로 담당하는 분야는 다르지만 결국 비슷하고 관련 있는 성격의 기술이었다는 점에서 말이다.

※ 여담 2: 정보 저장이라는 관점에서 성경 본문 고찰

성경에는 뭔가 정보 기록 매체를 암시하는 얘기가 있다. 가령, 요한복음의 21장 25절 제일 마지막 구절은 이렇다.
"예수님께서 행하신 다른 일들도 많으므로 만일 그것들을 낱낱이 기록한다면 심지어 이 세상이라도 기록된 책들을 담지 못할 줄로 나는 생각하노라."

"그 크신 하나님의 사랑"이라는 찬송가의 3절 가사는 이렇다.
"하늘을 두루마리 삼고 바다를 먹물 삼아도 한없는 하나님의 사랑 다 기록할 수 없겠네"

흠, 책이 아니라 SD카드라면 어떨까? 자기 테이프라면 어떨까..??
혹시 생명책이 실제로는 책이 아니라 무슨 SQL 서버가 돌아가는 IBM 메인프레임인 건 아닐까?

Posted by 사무엘

본인은 내 연배 사람들의 평균 이상으로, 심지어 나보다 나이가 더 많은 사람들 이상으로 레트로 컴퓨팅에 관심이 많다. 그 이유는.. 글쎄, 그 시절 당대엔 너무 비싸서 만져 볼 엄두를 못 냈던 최신 최고급 최첨단 하드웨어와 소프트웨어들이 지금은 너무 값싸지고, 싸구려를 넘어 역사 속의 퇴물이 된 게 경이롭고 신기하게 느껴지기 때문인 것 같다.

어린 시절에 굶주림을 겪었던 기성세대들이 지금 이렇게 먹거리가 싸고 풍부해진 뒤에도 늘 절약하고 비상시를 생각하고 많이 쌓아 놓는 습관을 평생 못 버리는 편이라지 않는가?
그런 것처럼 본인은 어린 시절에 저런 식으로 최신 문물의 이기에 대한 욕구불만(?)을 겪었던 게 지금 이런 추억과 집착으로 표출되는 것 같다. 나 자신에 대해 스스로 생각해 보니 그렇게 느껴진다.

1. 메모리

16비트 컴퓨터는 8비트보다야 훨씬 더 풍족한 환경이다. 특히 한글· 한자 같은 복잡한 문자까지 실용적인 해상도로 표현할 수 있을 정도로 성능이 받쳐 주는 마지노 선이기도 하다. CPU 속도뿐만 아니라 메모리(폰트..)나 그래픽(해상도)에서도 말이다.

하지만 컴퓨터 성능이 좀 더 향상되자 16비트도 금세 한계를 보였다. 16비트는 그 특성상 가깝게는 64KB, 그리고 x86 PC 기준 거시적으로는 1MB / 640KB의 한계에 매여서 이걸 극복하느라 온갖 지저분하고 복잡한 편법이 동원되어야 한 암울한 환경이기도 했다.
세그먼트가 어떻고 메모리 모델이 어떻고 far 포인터가 어떻고..;; 그리고 EMS는 뭐고 XMS는 뭐냐. x86 PC 말고 다른 16비트 CPU 동네에서는 상황이 어땠는지 개인적으로 매우 궁금하다.

EMS는 뭔가 특수한 방법으로 접근하는 부가적인 메모리를 장착해서 1MB 이상의 물리 메모리를 확보하는 방식이었다. 글쎄, EMM386이라는 도스 드라이버 이름이 암시하는 것과는 달리, 얘가 XT 시절부터 먼저 등장했다.
그러다가 80286 CPU의 기능을 활용해서 XMS라는 규격이 추가로 등장했다. 얘가 진짜로 더 자연스럽고 직관적인 방식으로 주 메모리의 연장선상으로 메모리를 더 확장해 준다.

MS-DOS 5.0에서 himem.sys라는 드라이버가 추가됐는데 이건 그냥 이유 불문하고 필수 로딩 드라이버였다. 그리고 DOS=HIGH니 LOADHIGH (LH)니, 뭔가 HI/HIGH가 붙은 게 그야말로 640KB 기본 메모리를 확보하기 위한 마법의 주문인 것처럼 컴퓨터 잡지에서 소개되곤 했다.
1MB 이상 메모리를 확보하는 것 자체는 가능했지만 현실에서 컴퓨터가 정보를 직통으로 취급하는 최소 단위는 여전히 64KB였고, 그나마도 접근성이 제일 좋은 영역은 1MB에서 그나마 384KB를 떼어낸 하위 640KB였기 때문이다. 뭐가 이리 복잡해..

정리하자면 EMS가 먼저 등장했고, 그 다음이 XMS이다. EMS는 확장 메모리를 반쯤 파일처럼 취급하는 방식인 반면, XMS에서는 같은 16비트이지만 286 CPU의 기능을 활용해서 확장 메모리에 CPU가 직통 접근 가능해졌다. 그리고 기존 도스용 프로그램이나 드라이버를 640KB 이후의 상위 영역에다가 올려 놓는 기법도 XMS와 함께 등장했다.
메모리 운용 방식이 까탈맞은 게임 중에서는 emm386 구동 절대 금지, 또는 반대로 EMS 필수.. 이러는 경우가 있었다. 이러니 config.sys 내용이 걸레짝처럼 복잡해질 수밖에 없었다. 도스 6.0에서는 멀티부팅이라는 기능까지 등장했고 말이다.

물론 어떤 경우에든 640KB 이전 기본 메모리를 최대한 많이 확보해 놓는 건 필수였다. 이게 마치 Windows 3.x 리소스 퍼센티지와 비슷한 개념이었다. 부팅 직후에 580~600KB 정도 남아 있으면 최적화를 아주 잘 한 것이었는데.. 한글 바이오스, 씨디롬, 디스크 캐시 같은 것들을 띄우다 보면 메모리가 금세 뚝뚝 줄어들었다.

이런 복잡한 메모리 삽질은 386 이상 CPU에서 제공하는 보호 모드, 가상 메모리 기능과 함께 역사 속으로 사라졌다. DPMI는 EMS/XMS 따위보다 더 상위 기술을 명시하는 규격이다. 32비트 도스 extender가 그 시절엔 정말 구세주 소리를 듣지 않을 수 없었다. 1990년 중반대의 도스용 게임을 실행할 때 DOS/4G 시그널이 뜨는 게 정말 간지 그 자체였다. ^^

2. 도스용 디바이스 드라이버(sys)

도스 시절에는 컴퓨터에 어떤 하드웨어를 인식시키기 위해서 해당 장치의 드라이버를 실행해서 올리는 절차가 있었다. config.sys라는 시작 스크립트에다가 DEVICE=어쩌구저쩌구 드라이버 파일 경로를 지정해 주면 됐다. 이건 무려 MS-DOS 2.0 시절부터 있었던 전통이라고 한다.

여기서 개인적으로 의문이 들었다. DEVICE로 로딩되는 *.sys 드라이버들은 분명 컴파일된 기계어 코드가 들어있는 실행 파일의 특수한 형태일 텐데.. 얘는 어떻게 만드는 걸까?
옛날 자료를 뒤져 보니 1980년대에 MS C 4.0 (!!! Visual C++ 4가 아님!)과 매크로 어셈블러를 써서 빌드하고 만든 경우가 있었다고 한다. ㄲㄲㄲㄲㄲㄲ
com과 비슷한데 그래도 자그마한 헤더가 들어있으며, 나름 한 sys 파일 안에 2개 이상 여러 드라이버가 있을 수도 있었나 보다.

config.sys는 부팅 때 단 한 번만 실행됐다. 부팅이 끝난 뒤에 얘들을 다시 실행하거나, 실행된 디바이스 드라이버를 제거할 수 없었다. 그러니 다루기가 좀 불편하다.
그 시절엔 부팅 후에 sys 파일을 실행해 주는 별도의 유틸리티가 있었다. 얘는 어떤 원리로 동작했는지 모르겠다만, 개인적으로 유용하게 썼던 기억이 남아 있다.

그리고 시스템을 건드리는 유틸이 처음엔 sys 형태로 개발되었지만 나중에 exe 형태로 바뀐 경우도 종종 있었다.
emm386 드라이버가 대표적인 예이고(DOS 4.0에서는 sys, 5.0 이후부터 exe), 디스크 캐시라든가 램 드라이브, 각종 한글 바이오스 소프트웨어도 1980년대엔 sys이다가 나중에 com/exe 기반의 램 상주 프로그램으로 바뀌었다.
마우스 드라이버는 sys였던 적이 없이 전통적으로 mouse.com이었던 것 같고..;; 그때는 msherc나 simcga처럼 그래픽 카드를 흉내 내는 램 상주 드라이버도 있었다.

나중에 Windows 9x 시절에는 vxd라는 드라이버가 있었는데 NT 계열부터는 소리 소문 없이 사라졌다.
도스용 아래아한글이나 이야기(PC통신!!)에서 쓰였던 덧실행 프로그램도 뭔가 특수하게 빌드된 프로그램이지 싶은데..
이렇게 기계어 코드를 생성하는 계층이랑, 껍데기 실행 파일을 생성하는 계층이 같지 않으니 컴파일러와 링커의 계층이 구분되었던 것 같다. 마치 압축 알고리즘과 컨테이너 구조의 차이와 비슷하다.

3. PC 스피커로 현실 사운드 흉내 내기

오늘날 우리가 사용하는 PC의 원조인 IBM PC라는 건 원래 업무용으로 개발됐다. 이 때문에 그래픽이나 사운드 쪽 지원은 원가 절감을 위해 우선순위에서 밀렸으며, 당대의 타 컴퓨터들에 비해 스펙이 뒤쳐졌다.
그래픽이야 초창기 CGA니 EGA니 하던 IBM 보급품이 얼마나 열악했는지는 더 설명이 필요하지 않고.. 사운드도 상황이 다르지 않았다. PC 스피커라고 불리던 IBM 보급품은 그냥 삑삑 띡띡거리면서(beep) 오류가 발생했을 때 최소한의 자기 상태만 청각 피드백으로 전달할 수 있는 정말 원시적인 물건이었다.

자연에서 발생하는 소리는 아무래도 부드러운 삼각함수 곡선의 합성으로 표현된다. 허나, 이 PC 스피커는 얼마나 단순했으면 생성 가능한 소리의 파형이 최대값 아니면 최소값으로 이산적-_-이었다. 음량을 나타내는 진폭조차 조절이 안 되고.. 진짜 그 특유의 날카롭고 투박한 비프음밖에 내지 못한 것이다. 자연스러운 삼각함수이면 소리굽쇠나 전화기 신호음 비슷한 소리라도 났을 텐데, 그렇지도 않다. ^^

그런데 1980년대 말에는 RealSound라고 PC 스피커를 극한까지 튜닝해서 얘만으로 최소한 단음 멜로디보다는 더 정교한 소리를 내는 기법이 개발되어 쓰였다고 한다. 단순투박한 비프음이라도 다양한 주파수로 아주 잘게 쪼개고, 이것들을 합성해서 또 다른 소리를 만들어 내는 거다. 이미지에서 디더링의 사운드 버전이나 마찬가지다.

이렇게 해서 표현 가능한 음질은 채널은 당연히 모노 한정이고, sampling rate는 11khz와 22khz의 중간인 18khz 남짓이었다고 한다. 그 시절 컴퓨터 사양을 감안하면 나쁘지 않았다.
다만, 문제는 표현 가능한 음색이랄까 이거 구분이 6비트밖에 안 됐다는 거..

아까 오리지날 PC 스피커는 최대값 아니면 최소값 2단계뿐이니 1비트인데, 이걸 딱 32배까지 늘리는 게 한계였다.
실용적인 사운드 카드에서는 최저 음질이 8비트부터(256) 시작이고 CD급 음질이라면 16비트가 보통인데 6비트는 확실히 자연스러운 소리를 재현하기에는 부족한 음질이었다.

이걸로 청취 가능한 사람 목소리를 낼 수는 있었다. 하지만 칙칙한 금속 기계음이 섞인 저음 남자 목소리 정도나 내며, 유선 전화기보다도 음질이 안 좋았다. 그냥 전용 사운드 카드로 음질 더 좋은 사운드를 내보내는 것보다 CPU에 걸리는 부하도 더 컸을 것이다.

하지만 비싼 사운드 카드 없이 보급 PC 스피커만으로 삑삑 단음이 아니라 사람 목소리 비스무리한 거, 툭툭 소리, 비트가 가미된 테크노 BGM이 흘러나오는 것만으로도 어디냐. (☞ 예시 1 / 예시 2)
PC 스피커로 사운드 카드 흉내를 내는 기술은 소수의 게임이나 유틸에서 알음알음 전수되어 쓰였던 것 같다. 그래픽 분야로 치면 VGA mode X라든가 CGA 160*100 16컬러 같은 꼼수와 비슷해 보인다.

4. 텍스트 모드 폰트

1980년대에 PC의 그래픽 카드는 CGA, EGA를 거쳐 VGA로 업그레이드 됐다. 그 과정을 거치면서 그래픽 모드의 해상도가 올라가고 지원되는 색깔 수가 늘었다.
덕분에 그래픽이 아닌 텍스트 모드에서도 자그마한 8*8 폰트를 동원해서 종전의 25줄이 아니라 43/50줄을 표시할 수 있게 됐다.
하긴, 요즘이야 큼직한 화면에서 70~80줄도 한번에 보면서 코딩을 하는데.. 꼴랑 25줄은 화면이 작아도 너무 작다.;;;

이렇게 색깔과 해상도가 올라간 거야 수긍이 가는 변화인데, 이것 말고 EGA/VGA가 과거의 CGA에 비해 향상된 게 더 있었다. 바로 텍스트의 폰트를 customize할 수 있게 된 것이다.
CGA에서는 그 알량한 폰트가 ROM에 박혀 있었던 반면, EGA/VGA에서는 이게 가변적인 RAM 영역으로 옮겨졌다. 정확하게는 자기네 ROM으로부터의 복사본이겠지만..

이 덕분에 몇몇 창의적인 프로그램들은 비록 텍스트 모드에서 돌아가지만 128번 이후의 특수문자들을 마개조해서 GUI 비주얼을 얼추 구현할 수 있었다. 도스용 Norton 유틸리티가 대표적인 예다.

체크나 라디오 버튼, 스크롤바 버튼을 그럴싸하게 그려 넣는 건 기본이고, 더 압권인 건 마우스 포인터까지 그래픽 모드처럼 구현했다는 것이다. 당장 위의 스샷을 보시라~! 지금 저건 텍스트 모드인데도 말이다!!
마우스 포인터가 차지하는 4개 영역에는 기존 문자에다가 마우스 포인터를 위치별로 합성한 4개 문자를 실시간으로 생성해서 그때 그때 바꿔 준 것이다. 이게 그 당시 하드웨어로 어떻게 가능했는지 모르겠다.;;

이런 비디오 마개조는 한글 바이오스 같은 프로그램과는 당연히 상극이었기 때문에 같이 사용할 수 없었다. 그러고 보니..

• VGA에서 텍스트 모드의 해상도는 640*400이 아니라 720*400이었다. 폰트는 8*16 것을 쓰지만 글자 사이에 1픽셀 여백이 있었다. 단지, 몇몇 선문자는 예외적으로 그 여백 부분까지 픽셀을 채웠기 때문에 선이 한데 이어져서 보였을 뿐이다.
• VGA 텍스트 모드에서는 글자색은 16개가 지원됐지만 배경색은 기본적으로 어두운 계열 8개만 지원됐다. 그러고 글자색을 깜빡거리게 하든지, 아니면 깜빡이지 않는 대신 밝은 계열 배경색 8개를 추가로 사용할지를 무슨 API를 통해 지정할 수 있었다. 참 신기한 형태의 설계이다.
• VGA가 아니라 모노크롬 MDA 시절에는 색깔이 없는 대신 글자에 진하게, 밑줄 같은 속성을 줄 수 있었고..ㄷㄷㄷ
• 그런데 개인적으로 텍스트 모드에서 이런 색깔 장난질을 할 수 있었던 언어는 베이식밖에 없었다. C/파스칼엔 텍스트 색깔 지정과 관련된 표준 API가 없었기 때문이다. (3rd party 라이브러리를 써야..)

Posted by 사무엘

마이크로소프트는... 하버드 나와서 겨우 교수나 변호사나 대기업 사원이나 쳐 하며 썩기에는 너무 똑똑하고 똘끼 넘치던 젊은 컴덕 악동 몇 명이 1975년에 설립한 소프트웨어 개발 기업이다.
마소는 처음에는 대기업 하드웨어에 같이 들어가는 프로그램을 납품하며 근근이 먹고 살았다. 그러나 결국은 전세계 PC에서 운영체제와 오피스 소프트웨어를 평정해 버렸다. 자기 소프트웨어 단독으로 먹고 살 수 있게 된 것이다.

이 시절에 컴터 프로그래밍은 16비트 x86 어셈블리 프로그래밍이 필수였다. 어셈블리어를 읽을 뿐만 아니라 직접 짤 수도 있어야 했다~! 하드웨어를 직접 제어하고, 귀한 메모리를 1바이트라도 아끼고, CPU 클럭을 1사이클이라도 아끼기 위해서다.
설립자인 빌 게이츠 자신이 베이식 인터프리터.. 일종의 가상 머신을 어셈블리어로 처음부터 끝까지 몽땅 아니면 대부분을 직접 코딩했었다. 수식 파싱, 메모리 관리, 각종 기하와 수학 알고리즘까지 전공 서적 찾아가면서 직접..

그는 천재 괴짜에 엄청난 워커홀릭이었다. (뭐, 컴터 업계에 빌만 그런 건 아니었겠지만) 그래서 결혼도 나이 40이 다 돼서야 했다. 물론, 억만장자 갑부가 됐으니 나이 따위는 결혼에 아무런 영향을 주지 않는 처지였다. 결혼식 때 호텔 하나를 통째로 전세 냈다.

그는 자기부터가 그런 기질이니, 초창기엔 부하 직원들도 왕창 쪼고 갈구고, 작업 결과물에 헛점이 보이면 고함 지르고 쌍욕 퍼부으면서 개X랄을 떨었던 걸로 악명 높았다. 경쟁사의 잡스만 성질이 더러운 게 아니었다.
그런 데다 빌은 회장 대표이사라면서 거의 말단 직원의 직속상사 급으로 부하들의 업무 디테일을 다 꿰뚫고 있는 괴수였다. 이 사람의 손바닥을 빠져나갈 방법은 전혀 없었다.

전직 마소 출신 직원이 지은 “조엘 온 소프트웨어”라는 책에 1990년대 초의 일화가 짤막하게 소개돼 있다.
직원들이 “이 양반.. 나이 30 중반이 되고 나니 그래도 갈굴 때 쌍욕(F***)이 좀 줄어들었네..”라고 회장 뒷담화를 한 것 말이다. ㄲㄲㄲㄲㄲ

Windows 3.0이 대성공을 거둬서 마소가 그럭저럭 먹고 살 만해지고 Windows NT에다 COM/OLE이라는 걸 처음 만들 때.. 더 나아가서 ActiveX라는 컴포넌트까지 만들던 90년대 초-중반이 마소의 입장에서는 기술적인 중흥기 리즈 시절이 아니었나 싶다.
빌 회장님의 애환이 깃든 Visual Basic 자체를 COM 기반으로 완전히 싹 다시 만들고(버전 4).. 얘는 내가 생각하기에 가장 토종 마소스러운 기술인 것 같다. 후대의 .NET이야 볼랜드 출신의 그 엔지니어의 입김이 많이 들어갔겠지만 말이다.

이렇듯, 빌 게이츠는 엔지니어와 사업가 자질이 둘 다 두루 탁월했던 사람이다. 그는 컴퓨터를 그냥 오덕질이나 자아실현, 그냥 극한 시험용으로 쓰는 게 아니라, 이걸 전세계 남녀노소의 모든 민간인들에게 팔아먹고 그 짓을 하기 위한 보편적인 소프트웨어를 만들 생각을 했다.
소수의 빠, 매니아 위주로 신비주의 마케팅을 했던 애플 진영과 대비되는 면모이다. 그렇기 때문에 빌은 잡스와 달리 그냥 장사꾼 같지, 무슨 ‘교주’ 같은 인상은 별로 없다. -_-

빌은 장사꾼으로서 소프트웨어 불법복제에 대해 민감하게 반응했고 오픈소스 진영과는 적대적이었다. 2000년대 이후로는 스팸 메일을 특별히 싫어해서 이런 거 거르는 솔루션의 개발에 몸소 친히 관여하기도 했었다. 그는 이렇게 말했던 적이 있다.
“저도 여느 사람들과 마찬가지로 스팸 메일을 왕창 많이 받습니다. 저보고 부자 되는 방법을 알려준다느니, 대출 많이 쉽게 받는 방법을 알려준다는 거예요. 웃기지 않는다면 거짓말이겠죠” ㄲㄲㄲㄲㄲㄲㄲ

빌 휘하에서 마소는 생존과 성장을 위해 대기업 IBM을 통수 쳤고 애플과도 으르렁댔으며, 여러 경쟁업체들을 로비와 독점으로 비열하게 고사시킨 이력이 있다. -_-;; IE 브라우저 독점뿐만 아니라 도스 시절에 Stacker사 Double space 저작권 침해 사건을 기억하는 분이 있으면 완전 아재일 테고.. ^^

그리고 내부적으로는? 요즘도 그런지는 모르겠지만, 마소는 1990년대까지만 해도 매년 근무 성적 하위 5%인 직원은 꾸준히 짤랐다고 전해진다. 빌뿐만 아니라 사장인 스티브 발머도 엘리트 출신에 완전 “오로지 1등”주의였다고 한다. 꽤 살벌한 기업이었다.

그래서 “마소 직원들은 애플이나 구글과 경쟁하는 게 아니라 사내 팀과 경쟁한다” 이런 말이 있었을 정도래나.. 이거 무슨 일본군 육군과 해군의 대립도 아니고.
안에서는 직원을 왕창 갈아넣고, 대외적으로는 저런 짓을 한 것이다. 그게 과거 마소의 놀라운 성장 비결이었다.

아~~ 그래서 그 시절에 Windows 9x와 NT 간에 API가 따로 놀기도 했었고, 한동안 오피스 팀이 파일 열기 대화상자를 Windows 것을 안 쓰고 따로 만들었고.. C 런타임 라이브러리도 Windows 팀과 Visual C++ 팀이 연계가 안 돼서 따로 놀고 그랬구나..!! 싶다.

그랬는데.. 마소는 2000년대 중반부터 성장이 멈추고 몰락의 기미가 보였다.
Windows XP에서 Vista 사이에 이례적으로 시간을 오래 끌었고.. 심지어 IE (브라우저) 팀을 없애고 Windows 팀으로 합치려고도 했다. 그렇게 우왕좌왕 하는 사이에.. 얘들은 모바일에는 완전히 적응을 못 하고 주류에서 밀려났다.

사실, 빌 아저씨도 선견지명이 없는 건 아니었다. 1990년대에 이미 "미래로 가는 길, information at your fingertip" 이라는 비전을 제시했었다.
단지, 그걸 인터넷이 아니라 MSN이라는 독자 독점 프로토콜의 네트워크로 실현하려 했을 뿐이다. 그 시도는 실패했다.

그리고 2010년대에 와서는 뒤늦게 Windows Phone/Mobile을 보급하려 했지만 역시 실패했다. 노키아를 뒤늦게 인수해서 구글과 애플에 맞섰지만 역부족이었다. 주변의 자기 직원조차 아이폰을 쓰고 있는 걸 보자 스티브 발머가 노발대발했었던 건 유명한 일화이다.
이런 뒤숭숭한 와중에 출시된 Windows 8은 괴작으로 시장에서 크게 실패했다. 2000년대에 Windows ME가 실패했던 것과는 좀 다른 방식으로 실패했다.

이런 시기에 빌 게이츠와 스티브 발머 같은 “싸우자 독점하자 이기자” 1세대 경영진이 마소에서 완전히 물러났으며, ‘사티아 나델라’라는 인도 출신의 완전히 새로운 피가 들어왔다. 이를 계기로 오늘날의 마소는 과거의 마소와는 완전히 다른 분위기의 기업으로 변화했다.
돈 안 되는 모바일 사업부는 포기하고, 영원한 원수 같던 오픈소스 진영을 포용하고, 마소가 Windows와 Office만 만드는 회사라는 편견을 깨뜨리려 하는가 보다.

다들 아시다시피 github를 인수하고 한때 빌도 하려 했지만 결렬됐던 id 소프트웨어를 인수하고(정확히는 그 모회사), 심지어 블리자드까지 인수하고.. 각종 옛날 자기네 제품들의 소스를 공개하고. 가히 놀랄 노 짜이다.
앞으로 마소에서 만든 소프트웨어에서도 About 대화상자나 도움말 acknowledge 같은 걸 살펴보면.. 사용된 오픈소스 목록이 쭈루룩~ 나오고 "LPGL 라이선스에 의거해서 우리 제품에서 변경한 소스 부분을 공개합니다"
이런 문구를 보는 날이 올지...?? 내 개인적으로 무척 궁금하다. ^^

대외적으로는 그렇고 사내에서도 “직장 동료는 그저 경쟁하고 싸우는 대상이 아니라, 다같이 발전시켜야 할 대상이다.. 많이 아는 게 아니라 많이 배우는 게 좋은 거다~ 실패를 두려워하지 말라.. 너는 남의 성공에 얼마나 기여했는가?” 뭔가 주토피아 Try everything스러운 사고방식을 회사 차원에서 전파하는 중이라고 한다. 과거의 악랄· 사악했던 이미지를 벗으려고 많이 노력하는가 보다. (그래서 MSDN도 LEARN.microsoft.com으로 바뀐 듯..^^)

일단은 이게 긍정적인 반응을 일으키는 중이며, 마소의 주가도 10년 전에 비해 크게 올랐다.
솔직히 Explorer 브라우저가 독점하던 시절이랑, 이제는 마소에서 자체 Edge 브라우저조차 포기하고 그냥 크롬과 동일한 엔진으로 갈아탄 현 시국은.. 소프트웨어 생태계가 너무 다르다. 당연히 변해야만 살아남을 수 있을 것이다.

다만, 배고프던 시절에 빌이나 발머 같은 1세대 경영자들이 마음 독하게 먹고 지저분한 짓, 욕 먹을 짓을 감행하면서 당장 마르지 않는 돈줄을 확보해 놨기 때문에 후대 경영자가 좋은 여건에서 저렇게 상생 운운하면서 다음 전략을 내놓을 수 있게 됐다는 것도 감안할 점이다. 단지, 언제까지나 1세대 사고방식만 고수하면서 살 수는 없을 뿐이다.

과거에 마소의 킬러 앱들도 1.0 시절부터 100% 순수 오리지널 창작이었던 것은 극히 드물었다. 엑셀 스프레드시트 정도나?
MS-DOS야 CP/M에서 시작됐고 Visual C++의 먼 전신인 MS C는 Lattice C의 소스에서 시작됐으며, IE야 모자이크 브라우저가 원조이다만.. 그것들을 원본보다 크게 발전시킨 것도 능력이다.

뭐, 빌도 인간이다 보니 모든 미래 예상이 적중하지는 않았으며 실패도 했다. 그래도 회사를 말아먹을 정도로 큰 손해를 끼치지는 않을 만큼만 실패했다. 이 역시 옛 경영진의 탁월한 능력이었음이 사실이다. (빌 아저씨는 너무 사용자 친화적인 마케팅 요소에만 집착하다 보니 1990년대 중후반엔 Bob이라든가 Office 길잡이처럼 너무 깜찍한 흑역사;;를 만들었던 적도 있다. ㅎㅎ)

이렇게 시대가 바뀌고 경영진이 바뀌긴 했는데.. 그 뒤부터는 이젠 PC와 Windows가 예전 정도로 중요한 밥줄이 아니어서 그런지..
마소 제품들에서 2, 30년 전에는 상상도 못 했던 나사 빠진 듯한 버그들이 종종 눈에 띄는 중이다. -_- 이게 좀 새로운 부작용인 것 같다. "일단 만들어서 배포부터 한 뒤에 문제가 발견되면 나중에 패치하면 되지..." 이런 군기 빠진 마인드가 마소라고 해서 예외가 아닌 건지도 모르겠다.

※ 여담

(1) 이렇듯, 마소의 운영체제 독식과 브라우저 독식을 종식시킨 것은 스마트폰 모바일 환경, 그리고 오픈소스 진영의 약진이지 싶다. 2004년 파이어폭스, 2008년 크롬은 그야말로 컴퓨팅 환경의 물줄기를 바꿔 놓았다.

(2) 은행 공공기관에서 IE가 완전히 필요 없는 세상은 도래하긴 한 건가? activeX의 대체제인 exe 프로그램은 기술적으로 나은 게 없다고 한때 논란이 많았는데 말이다. 난 여전히 edge+ie 모드에 의존 중이다.
이런 보안 분야는 여전히 웹 표준이 100% 감당이 안 되는가 보다. 오히려 스마트폰 은행 앱은 이 기기를 다른 사람이 쓸 일이 없다고 가정을 해서 그런지 돈 보내는 절차가 더 간단하다.

(3) 1990년대 후반부터 Windows 9x가 완전히 명줄을 다하고 16비트/도스 시절이 완전히 종식되는 데 큰 기여를 한 것은.. 바로 RAM이다. 메모리가 엄청 용량이 늘고 저렴해졌기 때문이다.
win95 나오던 시절에만 해도 램 8~16MB 갖고 빌빌대던 게.. 겨우 98 때 갑자기 64~128MB로 뻥튀기 된 건 정말 경이로운 현상이다. PC의 발전사에서 클럭 속도뿐만 아니라 메모리의 증가도 중요하게 다뤄야 한다. 인텔뿐만 아니라 삼성 전자도 이 시기에 큰 혁신이 있었음이 분명하다.

(4) 과거에 공룡 기업 IBM은 메인프레임 장사가 너무 잘 돼서 그런지 현실에 안주하는 편이었고, PC라고 불리는 개인용 컴터 시장에 대처를 제대로 못 했다. 덕분에 이쪽 주도권을 마소에게 빼앗겨 버렸다.
그런데 그로부터 20년쯤 뒤엔 공룡 기업 마소가 PC의 Windows와 Office에만 안주하다가 스마트폰 모바일 시장에 대처를 제대로 못 했다. 덕분에 그거 주도권은 안드로이드와 iOS 진영에게 완전히 빼앗겨 버렸다.
굉장히 비슷한 패턴의 역사가 반복된 것 같다.

(5) 그러고 보니 2010년대에 애플도 잡스가 죽으면서 최고 경영자가 바뀌었고, 야후에서는 잠시 새로운 여성 CEO가 들어왔다가 나가기도 했다. 그 뒤로 아이폰과 갤럭시 폰은 갈수록 서로 비슷해지며 수렴 진화 중이고, 야후는 여전히 비주류로 밀려난 듯하다.
마리사 메이어는 먹튀 논란이 있긴 했지만.. 그 당시 야후는 어떤 CEO가 들어가더라도 수습이 안 될 정도로 상태가 너무 안 좋기도 했다. 야후 코리아가 없어진 지도 벌써 10년이 넘었구나~!

Posted by 사무엘

1. 격세지감

요즘은 컴퓨팅 환경에서 웹과 모바일이 차지하는 비중이 워낙 커지다 보니..
맨날 컴퓨터를 끼고 살면서도 통상적인 드라이브 - 디렉터리 - 파일이라는 개념을 이해하지 못하는 젊은 세대가 늘고 있다고 그런다. 내 컴 하드의 Program Files 디렉터리 밑에다가 프로그램을 복사해 넣는다는 개념을 알지 못한다.

요즘 꼬마들이 전화기 픽토그램(☎)을 보고 이게 뭔지 이해를 못 한다거나, 플로피디스크를 보고는 저장 아이콘 3D 프린팅이라고 생각한다는데.. 그건 약과다.
얼라들이 아니라 이공계 석박사급 대학원생조차 그런 경우가 있다고 말이다. 물론 전공이 컴공이 아니고, 그저 배우지 않았기 때문에 모를 뿐이다. 머리는 다 갖춰져 있으니 조금 가르쳐 주면 금세 깨우친다.

지난 1980년대부터 컴퓨터라는 게 그저 정부 기관과 기업, 연구소에서나 사용하는 비싸고 귀한 물건에 머물지 않고, 개인별로 구비 가능한 업무 도구 내지 장난감 수준으로 대중화됐다.
8비트 시절엔 얘는 그냥 베이식 프로그래밍 환경 아니면 혼자 하는 게임기였다. 그러다가 16비트 시절엔 게임에 덧붙여 워드(아래아한글) 내지 PC 통신 단말기가 됐다.

이제는 인터넷 단말기 내지 온라인 게임기로 변모한 것 같다. 그 역할도 단순히 유튜브 보거나 음악 듣고 위키 읽고 은행 돈거래 하는 정도는 폰이 흡수해 버렸고, PC는 복잡한 키 조작이 필요한 업무나 게임 전담이다.
이런 와중에 파일 시스템이라는 걸 모르고 정보 저장 매체 실물이란 걸 모르는 세대도 등장했다는 게 참 흥미롭다. ㄲㄲㄲㄲ

2. 스마트폰이 PC와 다른 점

• 노트북 PC보다 더 고도화된 첨단 배터리, 디스플레이, CPU 기술이 모두 융합한 덕분에야 탄생한 물건이다.
• 1년 365일 24시간 내내 켜져 있고 사용자가 늘 갖고 다닌다. 카카오톡 메신저에 PC용 메신저처럼 이 사용자는 "오프라인, 바쁨, 부재" 이렇게 상태를 표시하는 기능이 없다는 걸 생각해 보자.
• 냉각팬이 없다. PC와 완전 동급의 범용적인 컴퓨팅은 못 한다. 이 때문에 동영상 같은 것도 하드웨어 차원에서 특화된 전용 포맷만을 원활하게 재생할 수 있다.
• 마우스 포인터 hovering이라는 인터페이스가 없다. PC에서는 아주 흔한 툴팁이라는 UI 요소가 있을 수 없다.
• 프린터나 유선 랜과의 접점이 없다. 하물며 물리적인 보조 기억장치와는 더욱..
• USIM이라고 붙박이 사용자 정보가 있다. 이거 덕분에 사용자 인증 절차가 PC에 비해 더 단순해질 수 있고, 모바일 뱅킹이 PC 인터넷 뱅킹보다는 덜 번거롭다.
• 프로그래밍 세계가 PC보다는 지저분한 레거시가 훨씬 없고 깔끔하다. 8비트/16비트 같은 건 경험한 적 없다. 그건 모바일이 아니라 아예 임베디드겠지.

3. 무선 인터넷의 통신 모드 전환

요즘 전화기로 인터넷을 할 때는.. 와이파이를 쏴 주는 친숙한 장소에서는 그 와이파이에 붙어서 교신을 하고, 그렇지 않은 임의의 장소에서는 자기가 가입한 요금제대로 데이터를 까서 교신을 하는 게 보통이다. 후자는 LTE니 5G니 하는 기술 이름으로 불리기도 한다.
전화기 역시 등록된 와이파이가 잡히는 곳에서는 거기에 자동으로 접속한다. 하지만 주인님이 밖으로 이동하는 바람에 거기 신호가 너무 약해지고 가망이 없어지면 자기 데이터를 깐다. 그러다가 다시 와이파이가 잡히면 모드가 거기로 바뀐다.

그런데.. 사람에 따라서는 와이파이에서 데이터로 넘어가는 민감도가 너무 낮은 게 불편하게 느껴질 때가 있다.
한 10초~20초 이상은 인터넷이 먹통이 된 뒤에야 뒤늦게 "모바일 데이터에 접속합니다" 이러기 때문이다.

"가능하면, 기본적으로 와이파이를 쓰되, 와이파이가 조금이라도 헬렐레 거리면 바로 데이터 써라~~"
"최대한 데이터 요금을 아껴라~ 한 30초는 기다렸다가 정말 연결이 구리는 게 확실시될 때만 데이터 써라~~"
이게 사람마다 취향이 다를 수 있다. 뭔가 설정을 통해 customize 가능했으면 좋겠다..

이건 자동차 운전으로 치면 자동 변속기의 변속 타이밍/알고리즘과 비슷한 것 같다.
"낮은 rpm에서도 고단으로 최대한 빨리 변속해라. 도저히 가속이 안 되고 차가 못 버틸 때만 불가피하게 저단으로 내려가라. 나는 연비가 중요하다"
"ㄴㄴ~ 밟았을 때 차가 빨리빨리 잘 튀어나가고 잘 가속되는 게 절대적으로 중요하다. 회전수를 3000rpm 이상은 올라갔을 때에나 고단으로 변속해라."

이런 것처럼 말이다.

4. 기타

• 각종 쇼핑몰들은 웹사이트가 있긴 하지만.. 거길 폰으로 접속할 경우, 꼭 자기 전용 앱을 깔아서 보라고 권유하는 편이다.
  그런데 이런 게 PC로 치면 ActiveX나 마찬가지 아니겠는가? 정확히 같은 개념이다~! 그리고 이건 귀찮다. -_-;;
  
  
• 꼬불꼬불 유선전화기는 가정용으로는 퇴출됐지만 인터폰이나 회사 사내 전화기로는 유효하다.
  비슷하게 사용자 상태가 표시되는 PC용 메신저도 가정용으로는 스마트폰 메신저에 밀려 퇴출됐다. (away, offline 상태 표시 없음) 하지만 사내 업무용 메신저는 전통적인 형태가 여전히 유효하다.
  
  
• 웹페이지를 열어 놓고 딴 앱을 쓰다가 한참 뒤에 그 브라우저로 돌아왔을 때.. 쓸데없이 reload를 좀 안 해으면 좋겠다. 그냥 예전에 표시해 놨던 페이지를 다시 보여줄 수 없나?
  
• 스마트폰의 메모장 같은 텍스트 편집 UI에는 undo 기능이 없는지 궁금하다.;;
  
  
• 로그인 기능이 있는 각종 웹사이트들은 id가 틀렸는지 비번이 틀렸는지 따로 정확하게 좀 알려줬으면 좋겠다. "ID 또는 비번이 잘못됐습니다" 이러지 말고. =_=;; id를 입력하자마자 바로 튕기는 건 바라지도 않으니.. 저런다고 특별히 보안이 위험할 것 같지는 않은데 말이다.
  
  
• 텔레비전과 유튜브의 화질이 정말 상상을 초월하게 향상되고 있는 와중에, 전화기의 음성 통화는 예나 지금이나 음성에만 특화된 8000hz급의 초저화질이다. 뭐, 전화 통화하면서 주변 음악을 들려줄 일이 딱히 있지는 않지만.. 그래도 의외의 면모인 것 같다.
  
  
• 은행 사이트들은 언제쯤 IE 외의 브라우저에서도 접속이 가능해질까? 차라리 폰이 나은 지경이 되고 있다.

Posted by 사무엘

1. 자동차

1930년대에 일본군 장성인 야마모토 이소로쿠가 미국으로 여행인지 출장인지를 갔는데..
시골 깡촌의 평범한 소녀가 공구를 들고 와서 자동차가 퍼진 걸 뚝딱 수리하는 걸 목격했다.
그는 이거 하나만으로도 천조국의 저력을 직감하고 경악했으며, 일본은 이런 나라와 전쟁을 벌여서는 이길 수 없다고 확신하게 됐다고 한다.

참고로, 옛날에 성경 번역자 틴데일은.. 시골에서 소 모는 꼬맹이 조무래기라도 교황보다 성경을 더 많이 알고 자국어로 성경을 암송할 수 있는 세상을 만들겠다고 포부를 밝혔었다. 근데 이 미친 나라는 어떻게 듣보잡 시골 처자조차 기계를 이렇게 잘 다루느냐 말이다.

2. 컴퓨터

한편, 1940년대인가 50년대인가, 컴퓨터 과학자 폰 노이만은 거의 인간 컴퓨터 급의 큰 수 암산이 가능했으며, 그냥 머릿속으로 기계어 코드를 쭈룩 읽고 쓰는 게 가능했던 천재 괴수로 유명했다.
자기 제자들이 컴파일러는커녕 어셈블러를 만드는 것조차 별로 달갑지 않게 봤을 정도였다. 프로그램을 짜고 싶으면 사람이 그냥 직통으로 0 1 쑤제 암산 기계어 코딩을 하면 되지, 엔지니어가 지 한 몸 편하자고(!!) 그 비싸고 거대하고 귀한 컴퓨터를 갖고 무슨 자원 낭비 잉여짓을 하느냐고, 그렇게 힐난을 가했었다.

하긴, 폰 노이만은 컴퓨터에 대해서 '프로그램 내장형 모델'이라는 개념 자체를 최초로 만든 사람이었다..!!!
컴퓨터가 해야 할 일을 일일이 진공관 배선을 바꾸고 천공 카드를 교체하는 식의 물리적인 노동으로 지정하는 게 아니라, 이 지시사항 역시 프로그램이 취급하는 데이터와 동급으로 메모리 상의 정보 중 하나로 간주시키는 발상이다.

요즘처럼 키보드 코딩만으로 간편하게 컴퓨터 프로그래밍이 가능해진 것 자체가 이런 개념이 도입된 덕분이다.
그러니, 자기가 이 정도로 프로그래밍 환경을 개선했으니, 더 편한 요행 꼼수를 바라지는 마라~~ 그런 생각을 했던 건지도 모르겠다.

3. 저격총

역시 2차 세계 대전 때.. '시모 해위해'라고 적군 수백 명을 사살한 핀란드의 전설적인 저격수가 있었다.
그는 저격 잘 하는 비결이랍시고 번거로운 조준경 따윈 없는 게 낫다는 말을 씨부려서 다른 사람들을 경악시켰다(!!). 지 혼자 시력이 2.0 3.0을 넘기라도 하는지.. 아무도 이해하지도 이행할 수도 없는 비현실적인 조언을 조언이랍시고 진지하게 남겼던 것이다.

하긴, 그 시절엔 레이더도 없거나 뒤늦게 개발됐었다. 그렇기 때문에 전투기 폭격기 조종사 역시 시력이 좋은 게 지금보다 아득히 유리하게 작용하긴 했었다.

이것들은 대단한 일화인 것이 사실이다. 하지만 저 시대 사람들이 오늘날과 같은 급의 자동차를 수리하거나 요즘 컴퓨터와 운영체제 같은 여건에서 기계어 코딩을 한 건 아니라는 점 역시 감안할 필요가 있다.
당연히 지금 자동차나 컴퓨터는 정말 저 때와는 비교조차 할 수 없을 정도로 훨씬 더 복잡하고 정교하다. 그렇기 때문에 사람이 호락호락 직접 만지고 고칠 수 있지 않다.

제 아무리 천재 괴수 폰 노이만이라 해도, 그 시절에 컴퓨터라는 건 핵 실험이나 탄도 계산, 일기예보 시뮬레이션을 위한 거대한 계산 기기 그 이상도 이하도 아니었다. 국가 기관· 연구소만의 전유물이었으며, 국민의 세금으로 운용되는 엄청 비싸고 귀하신 몸이었다.

그는 2차 세계 대전을 겪었고, 미국의 원자폭탄 개발에 참여했을 뿐이었다. 일반 양민들이 개나 소나 그 거대한 컴퓨터보다 성능이 더 뛰어난 스마트폰을 주머니에 넣고 다니는 시대를 살았거나 그걸 예측한 건 아니었다. 그러니 컴퓨터 자원에 대해서 극도로 아껴 쓰고 절약하자는 마음이 뼛속까지 몸에 배겼으며, 그런 사고방식이 자신의 천재적인 두뇌와 결합했기 때문에 '쓸데없이 어셈블러 따위'라는 갈굼이 나온 것이었다. =_=;;;

지금이야 한낱 작업자의 편의 때문이 아니라 업무 생산성 때문에라도 프로그래머들에게 고급 툴과 컴파일러는 듬뿍 쥐어 줘야 한다. 폰 노이만이라도 Windows용 exe 실행 파일을 맨땅에서 만들지는 못할 것이며, 근본적으로 그래야 할 필요가 없다.
키가 3m인 인간흉기 골리앗, 특수부대 할아버지라 해도 현대의 전장에서 총 맞으면 죽는 건 똑같기 때문이다.

시모 해위해도 기술이 훨씬 더 향상된 오늘날의 저격 소총을 보면 조준경 불필요 소신을 바꾸게 됐을지도 모르겠다.
이 사람은 전장에서 수백 명의 적군을 조준경 없이 저격 사살하긴 했지만, 그 대신 저격 거리도 km급이 아니고 우리 생각보다 짧았다고 한다(2~300m). 그만큼 더 위험하게 임무를 수행했다.

4. 비행기

20세기 중반의 천조국 기준으로.. 컴퓨터 업계에 폰 노이만이 있다면, 항공 업계에는 '켈리 존슨'(1910-1990)이라는 정말 전설적인 괴수 엔지니어가 있었다.
이 사람은 평생을 비행기를 조종하는 일이 아니라 비행기를 설계하고 만드는 일에 뼈를 묻었다. 이 사람도 조종을 안 한 건 아니지만, 평범한 여객이나 군용 조종이 아니라 새로 만들어진 기체의 안정성을 극한까지 시험하는 '테스트 파일럿' 명목이었다. ㄲㄲㄲㄲㄲ 즉, 여느 파일럿과는 급이 다르다.

이 사람은 록히드에서 일하다가 미국의 최신 항공 우주 기술의 산실인 스컹크 웍스의 수장을 역임했고.. 네바다 주에 그 비밀 실험 기지인 AREA 51을 직접 구상하고 만들기도 했다.;;
전투기 P-38, 최초의 제트 전투기 F-80 슈팅스타 쌕쌕이, 마하 2를 최초로 돌파한 F-104, 고공 정찰기 U-2와 SR-71 등..

컴퓨터도, 캐드도 없던 시절부터 이 사람은 인간 컴퓨터나 인간 백과사전이 아니라, 그냥 걸어다니는 풍동 실험실이었다.
"비행기를 이렇게 만들고 날개의 모양과 크기와 각도를 이렇게 만들어서 저렇게 조종하면 실제로 이렇게 날아갈 것이다, 성능과 안정성이 이럴 것이다.. 이 디자인은 요런 비효율과 문제가 있으니 얼추 이 정도로 고쳐야겠다.."

동료 엔지니어들은 낑낑대며 복잡한 수학 계산을 통해 예측을 했지만, 저 사람은 머릿속에서 직감적으로 바로 시뮬레이션이 됐다. 구체적인 숫자까지 제시한 게 굉장히 정확하게 적중했다. 이게 진짜 무서운 면모였다.;;; 동료 엔지니어들은 "저 괴수는 공기의 움직임이 눈에 보이기라도 하나?" 하며 혀를 찼다. 이 정도면 비행기의 폰 노이만 급이 아닐지? ㄷㄷㄷ

참고로 비슷한 시기에 보잉 사에서 재직했던 '조(조셉) 서터'(1921-2016)도 전설적인 비행기 개발자였다. 보잉 7x7 프로젝트에 모두 관여하면서 짬을 쌓다가 궁극적으로는 747의 팀 리더가 되어 20세기 최대 크기의 전설적인 여객기를 설계하고 개발하게 됐기 때문이다.

글쎄, 현대의 CPU 설계 중에서는 독보적이고 전설적인 장인 엔지니어가 없나 모르겠다.
CPU는 자동차나 비행기와 달리 애초부터 사람 손으로 만드는 게 가능하지 않은 물건이긴 하다만.. 그래도 미시세계에서도 회로를 이렇게 설계하면 발열이나 전력 소모가 너무 심해진다느니, 몇 마이크로초 단위의 손실이 생긴다느니 뭐니 이런 직관이 발휘될 여지가 있는지 궁금하다.

Posted by 사무엘

1. 비트필드

C언어의 구조체에는 다른 언어에서는 거의 찾을 수 없는 비트필드라는 물건이 있다.
얘는 굉장히 편리하고 강력한 프로그래밍 요소이다. 바이트 경계에 딱 떨어지지 않는 숫자를 일반 숫자 다루듯이 읽고 쓰게 해 주니 이 얼마나 대단한가? IEEE754 부동소수점이라든가, 과거 2바이트 조합형 한글 같은 건 비트필드 구조체를 잘 만들어서 내부 구조를 쉽게 분석해 볼 수 있다.

다만, 비트필드와 관련해서 언어 문법 차원에서 다음과 같은 점이 보완되거나 강화됐으면 좋겠다는 생각이 개인적으로 오래 전부터 들었다.

(1) 지정 가능한 자료형은 그냥 unsigned 아니면 signed 둘 중 하나로 굳혀 버리고, 나머지 쓰잘데기없는 키워드들은 몽땅 거부하고 에러 처리했으면 좋겠다. 어차피 이 필드의 크기는 뒤의 비트수에 의해서 결정될 텐데.. int니 char이니 long이니 하는 건 전혀 불필요하고 쓸데없는 정보이기 때문이다. 괜히 unsigned char _field: 10; 이런 거 체크해서 10이 8보다 더 클 때만 에러 처리하는 건 잉여스러운 짓이다.

사실 본인은 비트필드에서 부호 "있는" 자료형이 쓰이기는 하는지, signed조차도 필요는 한지 그것도 굉장히 회의적이다. 차라리 enum이 쓰일 가능성은 있을지 모르겠다.

(2) 비트필드에서 공간을 배치하는 순서는 결국 타겟 플랫폼의 비트 endianness의 영향을 받는다. unsigned member : 4 라고 해 주면.. little endian에서는 하위 0~3비트가 할당되며, big endian에서는 상위 4~7비트가 할당된다.
더구나 비트필드라는 건 결국 2~4바이트짜리 커다란 정수 하나를 잘게 쪼개기 위해 존재하는 물건인데, 쪼개는 순서 자체가 비트 endianness에 따라 달라진다.

결국 비트필드를 사용해서 특정 파일 포맷이나 패킷 구조를 기술해 놓은 구조체 선언을 보면.. 빌드 환경의 endianness에 따라 조건부 컴파일을 시켜서 little일 때는 같은 멤버를 abcd 순으로 배치하고, big일 때는 이를 dcba 순으로 무식하게 배열해 놓곤 한다.

이게 정형화된 패턴이니 프로그래머가 쓸데없는 삽질을 할 필요 없이, 언어 차원에서 문법을 지원을 좀 했으면 좋겠다.
"이 비트필드들은 16/32비트 기준으로 큰/작은 자리부터 순서대로 분해하는 것이다. 그러니 타겟 아키텍처의 endianness가 이와 정반대이면 컴파일러가 알아서 멤버들의 배치 순서를 뒤집어라" 이렇게 힌트를 준다.

이런 일이 컴파일러가 하기에는 너무 지저분하다면 #pragma 같은 걸로 빼내서 전처리기 계층에다 담당시켜도 된다.
핵심 요지는.. 똑같은 멤버를 프로그래머가 순서만 바꿔서 다시 써 주고 조건부 컴파일을 시키는 무식한 짓만은 좀 없어져야 한다는 것이다.

비트필드가 쓰일 정도의 상황이면.. 아마 이 공간 전체를 거대한 숫자 한 덩어리로 같이 취급하게도 해 주는 union, 그리고 구조체 멤버 배치를 어느 플랫폼에서나 비트 단위로 일치하게 강제 동기화시키는 #pragma pack도 같이 쓰이고 있을 가능성이 매우 높다.
#pragma pack과 #pragma once는 진짜로 사실상의 표준이니 C/C++에서 정식 표준으로 좀 등재시켜야 하지 싶다. char32_t / char16_t 같은 게 결국 built-in type으로 받아들여지고 정식 표준이 된 것처럼 말이다.

참, 당연한 얘기이다만.. 구조체 템플릿에서는 비트필드의 크기를 나타내는 숫자도 템플릿 인자로 공급해 줄 수 있다.
비트필드의 크기는 구조체 멤버에 들어있는 배열의 크기와 위상이 거의 같으니 말이다. 구조체의 크기에 영향을 주는 숫자이며 컴파일 시점에서 값이 상수로 결정되어야 한다.

template<size_t N> struct XXXX {
    unsigned _member: N;
};

아주 C스러운 요소와 C++스러운 요소가 한데 만난 것 같다. ㄲㄲㄲㄲㄲ 비트필드의 크기를 템플릿 인자로 지정할 일은 극히 드물 것이다.;;

교통 분야에서 좌측· 우측 통행이 국가별로 찢어져 있다면, 디지털 컴퓨터에서는 비트의 배치 순서 endianness가 통행 방향과 비슷한 개념이며 아키텍처별로 찢어져 있는 듯하다.
네트워크 표준은 big endian이지만, 컴퓨터들은 x86이 주류이다 보니 little endian이 주류이다. 이건 세계적으로 자동차 도로 우측 vs 좌측과 비슷한 비율이며, 안드로이드 vs iOS와 비슷한 비율인 것 같다. 본인은 big endian을 native로 사용하는 컴퓨터를 평생 한 번도 구경해 본 적이 없다.

2. C의 단순 평면성

C++에 비해, C는 마소에서 거의 아오안 취급을 하기 때문에 컴파일러의 버전이 바뀌어도 달라지는 게 거의 없다. 다만..

• C99에서 추가된 가변 길이 배열이 Visual C++에서는 지원되지 않는다.
• 구조체의 가장 마지막 멤버를 구조체 자체의 크기를 차지하지 않는 명목상의 멤버로.. char data[] 내지 data[0] 같은 형태로 선언해서 구조체의 뒷부분을 가변 길이로 활용하는 게.. 여전히 일부 컴파일러의 편법일 뿐, 정식 표준이 아닌 것 같다.
  
• 대소문자를 무시하고 문자열을 비교하는 함수가 의외로 표준이 아닌 것 같다. stricmp와 strcasecmp 부류가 혼재해 있다. C는 라이브러리 함수가 ANSI니 POSIX니 하면서 의외로 파편화된 게 좀 있어서 플랫폼 간의 이식성을 저해하는 중이다.
  

C는 클래스와 상속 계층이 없을 뿐만 아니라, 각종 명칭에 다단계 계층 scope이란 것도 없다. namespace나 using 같은 걸 신경쓸 필요 없이 모든 명칭이 오로지 local 아니면 global.. 그도 아니면 매크로 함수밖에 선택의 여지가 없다. 클래스라기보다는 번역 단위 자체가 클래스와 비슷하며 static이 외부로 노출되지 않는 private 역할을 얼추 담당한다.

그러니 뭔가 아주 단순하며, 입체적인 게 아니라 '평면적이고' 깔끔해 보이기는 하는데.. 한편으로 너무 중구난방이고 명칭이 충돌하기 쉽다.
새로 짓는 이름은 접두사에 목숨을 걸어야 할 것 같다. 이런 언어로 초대형 라이브러리를 만들고 대형 프로그램을 관리하는 데는 한계가 있을 수밖에 없다.

또한 매크로 함수를 너무 사악하게 남발 남용할 경우, 어지간히 복잡하게 꼬인 C++ 템플릿 이상으로 코드가 알아보기 어려워진다. 특히 전처리기의 존재를 알지 못하는 디버거는 매크로 함수와 완전히 상극이다.

매크로 함수 내부의 코드를 한 단계씩 실행할 수 없고, 또 ## 연산자에 의해 새로 생긴 토큰 명칭들은 어지간한 IDE에서 자동으로 파악도 못 해 준다. 이렇게 IDE와의 괴리가 커지고 붕 떠 버린 코드는 사람 입장에서도 짜증이 나서 제대로 들여다보고 유지 보수하기가 싫어진다. 이는 결국 생산성의 저하로 이어진다.
이런 게 C의 어쩔 수 없는 한계인 것 같다. -_-

3. C언어의 강력하고 자유로운 면모

• 지역 변수, 전역 변수, heap 등 어디든지 가리킬 수 있는 포인터
• 한 함수 안에서 어디로든 분기할 수 있는 goto문
• type이고 뭐고 다 씹어먹고서 메모리를 조작할 수 있는 memcpy, memmove (malloc, free 같은 생짜 수동 메모리 관리는 덤)
• 무슨 토큰이건 다 치환할 수 있는 전처리기 매크로

하지만 위의 요소들은 위험성과 복잡도도 너무 키운다. 저런 저수준 조작이 잔뜩 쓰인 복잡한 코드에서 버그를 찾아내야 된다면.. 정말 머리에서 연기가 피어오를 것이다.
오늘날의 프로그래밍 언어에서는 저것들은 최대한 금기시되고 봉인되고, 다른 형태로 대체되고 있다.

goto는 아무리 사악하다고 하지만 이중 for 문을 한꺼번에 빠져나가기, 그리고 switch와 while/for문을 한꺼번에 빠져나가기 같은 건 너무 아쉽다. 자기보다 뒤로만 goto가 가능하게 제한하는 것도 나쁘지 않을 것 같은데 말이다.
한편, 개발툴에서 define 전개된 결과 기준으로 문자열을 find in files 하는 기능이 있으면 좋겠다는 생각이 가끔 든다.

4. 전처리기 #if 의 동작 방식

C/C++에서 원래 있는 if문 말고, 전처리기의 #if에서는 소스 코드에 있는 변수들을 당연히 전혀 사용할 수 없다. 오로지 #define 심벌과 상수, 기성 연산자만이 사용 가능하며, #define 심벌들은 매크로 치환 후에 다들 상수로 바뀌어야만 한다.

변수나 type이라는 개념이 없기 때문에 대입 관련 연산자는 당연히 전혀 사용할 수 없으며 포인터도 아웃이요, sizeof 연산자도 지원되지 않는다. 그 대신, 어떤 심벌이 #define돼 있는지의 여부를 판별하는 defined라는 고유한 bool값 연산자가 있다.

sizeof는 피연산자가 값이 아닌 타입 명칭일 때는 피연산자를 ( )로 싸지 않아도 된다.
이와 비슷하게, defined도 피연산자가 다른 수식이 아니라 명칭 달랑 하나이기 때문에 ( )가 없어도 된다.

그리고 나도 지난 25년 가까이 전혀 몰랐던 특성이 하나 있는데..
#if 문에서는 정의되지 않은 아무 명칭/심벌을 들이대도 에러 처리되지 않는다. 그런 듣보잡 심벌은 그냥 곱게 상수 0과 동급으로 간주된다~!

무슨 포인터 역참조 할 때 if(ptr && *ptr==1) 이러듯이 #if defined SYMBOL && SYMBOL==1 같은 defined 가드를 설치할 필요가 없다.
SYMBOL 자체가 #define돼 있지 않다면 #if SYMBOL==1은 어차피 자동으로 false로 처리된다.
겨우 이런 사소한 사항 때문에 전처리기가 까탈스럽게 에러를 뱉지는 않으니 걱정하지 않아도 된다.

5. 특수한 코딩 요소

(1) 빌드 configuration이 맞지 않는다면 코드가 아예 빌드되지 않고 고의로 에러가 유발되게 하고 싶을 때가 있다. 이때는 일부러 무식하게 C/C++ 문법에 어긋난 문자열을 늘어놓을 필요가 없이 #error라는 전처리기 지시문을 쓰면 된다.
컴파일러에 따라서는 에러가 아니라 경고 메시지만 흉내 내고 빌드는 계속 진행되게 하는 #pagma message도 표준에 준하는 기능으로 쓰인다. deprecated API를 사용을 권장하지 않는다고 표시하는 것처럼.. 이런 건 언어 차원의 지원이 필요해 보인다.

(2) 파싱과 문법 체크만 할 뿐, 실제 코드를 생성하지 않고 아무 일도 하지 않는 허깨비 유령 함수라는 것도 필요하다. 디버그 로그를 찍는 함수를 조건부로 숨길 때, 템플릿 클래스에 인자가 제대로 주어졌는지 체크할 때 등(static_if 나 컴파일 타임 assert와 비슷)..
이건 _noop라는 컴파일러 인트린식 형태로 제공되는 편이다. 마치 인라인이나 매크로 함수처럼.. 외형은 함수이지만 실제로는 자기 주소가 존재하고 매개변수의 push/pop이 행해지는 함수가 아닌 셈이다.

(3) 내용을 깡그리 무시하고 컴파일러가 파싱하지 않게 하는 영역은 '주석'이라고 불리며, 이건 모든 프로그래밍 언어에 존재한다.
C/C++에서는 /* */ 와 //뿐만 아니라 전처리기를 이용한 #if 0 / #endif도 사실상 주석처럼 쓰일 수 있다.
게다가 얘는 /* */ 와 달리, 중첩이 가능하다. #if 0으로 막혀 있는 구간이라도 전처리기의 #if #else 로직은 무시되지 않기 때문이다. 그래서 중간에 또 #if 0이 섞여 있는 코드라도 한번에 싹 막았다가 해제할 수 있어서 편리하다.

Posted by 사무엘

1. 옛날 자동차와 컴퓨터의 성능 수동 조절 버튼

요즘으로서는 실감이 안 가지만 30여 년 전 엄청 옛날 1990년대에 286이나 386급 컴퓨터에는 자신의 클럭 속도를 저/고로 조절하는 버튼이 본체에 있었다. 일명 '터보' 버튼..
그래서 컴퓨터 본체에 달린 버튼이 전원, 리셋, 터보.. 요렇게 3개였다.

(아 맞다, 그러고 보니 옛날 컴터는 본체에 저렇게 현재의 클럭 속도가 숫자로 표시되어 나오기도 했고,
하드디스크 동작 램프도 저렇게 있었다.. 완전 까먹고 있었다!! ㄲㄲㄲㄲㄲ 하드 동작 램프는 SSD 시대가 되면서 완전히 구시대 유물로 전락한 듯하다.)

단, 터보에 대해서 오해하지 말아야 할 것이 있는데..
터보를 켰을 때 컴터가 무슨 애프터버너.. 아니, 오버클럭 모드로 진입해서 평소보다 더 빠르게 동작하는 게 아니었다. 정반대..
터보를 끄면 리미터가 걸려서 제 성능보다 느리게 돌아가고, 터보를 켰을 때 원래 속도대로 동작했다.

그리고 이런 저속 모드가 존재했던 이유는 무슨 발열이나 전력 소모 같은 이유 때문이 "아니었다". 느린 컴터를 기준으로 돌아가는 기존 프로그램과의 '호환성'을 제공하기 위해서였다.

일례로, 프레임 수 조절을 정교하게 안 하는 일부 옛날 게임은 클럭이 빠른 컴퓨터에서는 너무 빠르게 돌아갈 수 있었다. 매번 현재 시각을 측정하면서 컴터 클럭과 무관하게 프레임 수 조절을 정교하게 하는 것도 "1클럭이 아까운 CPU 자원을 소모하는 번거로운 '일' "이었기 때문이다. 그래서 그런 작업을 생략했던 것이다.;;

겨우 이런 호환성 유지를 위해 꼴랑 16MHz짜리 286 컴퓨터를 도로 8이나 12MHz 클럭으로 동작하게 하고, 56MHz짜리 386 컴퓨터를 33MHz로 너프 시켰다니.. 옛날은 참 암울하던 시절이었다.

그에 비해 요즘은 노트북 컴퓨터가 배터리만으로 동작할 때 화면 밝기와 CPU 속도를 살짝 낮추는 옵션이 있는 정도이다. 절전을 위해서..
요즘 자동차가 연비를 굉장히 신경 써서 만들어지는 것만큼이나 요즘 컴퓨터는 고성능에다 전력 소모와 발열을 굉장히 신경 써서 만들어진다.

하긴, 486은 아키텍처야 386과 동일하지만 그래도 캐시 메모리라는 게 처음으로 도입되고 부동소수점 코프로세서가(80387) 옵션 액세서리가 아니라 완전히 포함돼 들어갔고, 저런 터보 나부랭이도 완전히 없어졌다. 아마 냉각팬도 이때쯤 들어갔나?
생각해 보니 단순히 클럭만 빨라진 게 아니었고 386 대비 바뀐 게 생각보다 많았다.

이렇듯.. 옛날 컴퓨터에 터보 버튼이 있었다면, 동시기의 자동 변속기 초창기 차량에는 파워/이코노미, 오버드라이브 따위의 버튼들이 있었다.
이때는 자동 변속기가 꼴랑 4단까지밖에 지원되지 않았고, 변속 알고리즘이 지금만치 똑똑하고 효율적이지 못했다. 킥다운이나 락업 클러치, 스포츠 모드 같은 기능의 구현도 미숙했다.

그래서 이때는 파워 버튼을 눌러서 차가 평소보다 높은 rpm까지 저단을 더 오래 유지하다가 고단으로 넘어가라고 동작 방식을 강제로 바꿀 수 있었다. 당연히.. 앞차를 추월할 때, 노란불 켜진 교차로를 필사적으로 통과해야 할 때 등, 수동 몰듯이 저단에서 일부러 확 밟아야 할 때 쓰는 용도였다.
옛날 자동차, 옛날 컴퓨터에만 있었던 추억의 '모드 전환' 버튼이 문득 떠올라서 회상을 늘어놓아 보았다.

2. 쌍팔년도 PC의 그래픽 카드

- IBM에서는 CGA (320*200 4색), EGA (640*350 16색), VGA (640*480 16색, 320*200 256색)의 순으로 표준 그래픽 카드를 내놓았다.
그러나 한글· 한자 때문에 글자 높이가 최하 16픽셀급이 돼야 하는 한중일에서는 모노크롬 허큘리스 다음으로 곧장 컬러 VGA로 갈아탔다. 허큘리스는 3rd파티 싸제 규격이었다.

- 하긴, 8비트 컴퓨터는 비디오 쪽 성능이 많이 딸려서 저런 고해상도 그래픽을 표현하기가 난감했다. 우리나라에서 국가 차원에서 컴퓨터들을 교통정리를 할 때 8비트를 일찌감치 배제하고 최하 16비트부터 선택한 이유도 이 때문이었다.
16비트가 지금까지 사용되는 PC의 외형 근간을 완성했다면, 32비트는 넉넉한 주소 공간과 보호 모드 지원 덕분에 멀티태스킹/멀티스레딩/가상 메모리를 최초로 구현 가능하게 했다. 64비트는 32비트 구조에서 4G 한계만 극복한 것이고..

- CGA EGA VGA 하면 개인적으로 늘 같이 떠오르는 게.. 레코드의 규격 SP EP LP이다..;;;

- 각 그래픽 카드별로 뭔가 비공식 변조 모드가 있었다.
CGA는 해상도를 무려 160*100이라는 극악으로 떨어뜨린 16색 그래픽 모드를 지원했는가 보다.
VGA는.. mode X라고 해서 320*240, 400*300 같은 해상도를 지원했다. 마이클 압래시라는 사람이 이런 걸 발견하고, 도스용 퀘이크에서 이걸 적용해서 많이 알려졌다.

- VGA는 그 이전의 CGA,EGA와 달리.. 그래픽 카드와 모니터를 연결하는 단자가 D-sub라고 원래 아날로그 기반이었다. 그 시절의 기술로 그 해상도와 색상, 주사 횟수를 구현하려다 보니 디지털로는 버거움을 느꼈던 것 같다. 하지만 후대에는 DVI나 HDMI 단자가 등장하면서 다시 디지털로 돌아왔다.
그 시절에 주류였던 두툼한 브라운관 모니터도 아날로그 신호와 더 친했지 싶다. 브라운관은 아무 해상도에나 픽셀 뭉개짐 없이 유동적으로 대응 가능한 유일한 디스플레이 기술이다.

- 각 그래픽 모드를 소프트웨어적으로 흉내 내어 주는 램 상주 프로그램이 있었다. simcga라든가, msherc 따위.. 단, simvga는 공식 프로그램이 아니라 낚시 악성코드였다.;;

- 1988년에 출시됐던 Splash! (Spinnaker software)라는 그래픽 에디터는 최신 VGA 저해상도 256색 그래픽을 채용한 거의 초창기 프로그램이었다. VGA는 1987년에 출시됐고, 그때는 아주 값비싼 최신식 그래픽 카드였으니까..
참고로 87~88년이면.. C++을 C로 전처리 거치지 않고 직통으로 번역하는 컴파일러가 업계 선구자에 의해 거의 최초로 등장했던 시기이기도 하다. 업계에서는 C++은 아직 듣보잡이었으며, C와 어셈블리가 당연시됐었다.

- 퀵베이식에서는 SCREEN 13 한 줄만으로 VGA 256색 모드로 바로 진입 가능한 반면, 그 당시 볼랜드의 개발툴(Turbo C/Pascal)이나 파워베이식은 그 당시 게임 프로그래밍에서 필수였던 이 mode 13h에 대한 지원이 유난히 인색했다. 그 이유를 난 아직도 모르겠다.

- 이 VGA 이후로 800*600 16색이라든가, 640*480 256색, 1024*768, 심지어 트루컬러 같은 발전된 모드는 IBM에서 더 중재를 하지 않고 업계 재량으로 넘어갔다. 사실, IBM은 XT/AT 이후에 80386부터는 표준 PC에도 더 관여하지 않고 손을 놨고, 운영체제 역시 OS/2가 Windows에 밀리면서 PC 시장과는 점차 인연이 멀어지게 됐다.

3. 전통적인 컴퓨터의 명가

• 크레이: 슈퍼컴
• IBM: 메인프레임
• 썬: 워크스테이션??
• HP: 서버

이들과 달리, PC는 뭔가 독보적으로 접수하고 있는 업체가 없다. 마소와 인텔?? 얘들은 물론 컴퓨터 완제품이 아니라 CPU와 운영체제 제조사이니 위의 예들과는 성격이 좀 다르다. 이제는 슈퍼컴이나 워크스테이션 같은 컴퓨터의 영역이 PC에 많이 흡수되기도 했고..

4. 하드웨어의 발전

(1) 마우스 포인터: 그림이 계속 그려지고 있는 곳에 마우스 포인터를 가져가도 포인터가 깜빡거리지 않게 됐다.
이건 뭐 30년 전 Windows 3.x 시절부터도 비디오 드라이버를 적절하게 잡으면 실현됐던 사항이다. 그 시절의 그래픽 카드도 마우스 포인터 정도의 스프라이트를 하드웨어 차원에서 직통 처리하는 기능은 제공했기 때문이다.
Windows 2000부터는 그래픽 카드를 잡지 않은 VGA 16색 안전 모드에서도 마우스 포인터가 깜빡거리지 않기 시작했다. 9x는 그렇지 않았다.

(2) 사운드: Windows 98쯤부터 여러 프로그램에서 사운드를 동시에 재생할 수 있게 됐다. 그 전에는 정말 믿어지지 않지만 사운드도 무슨 파일처럼 한 프로그램에서 열면 다른 프로그램에서 접근할 수 없는 리소스였다.;; 멀티웨이브 믹싱이 지원되지 않았던 것이다.

(3) 화면: print screen 키를 눌러서 동영상 재생 화면도 캡처가 가능해졌고, 일반 그래픽과 아무 차이가 없어졌다. 이건 나름 Windows Vista에서부터 실현된 기술 발전이다.

Posted by 사무엘