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

1. 도스 시절 명령어

도스에서 파일(과 디렉터리)을 다른 곳에 복사하는 명령은 copy이다. 얘는 명령 셸인 command.com이 자체 지원하는 내장 명령이다.
그런데 도스에는 copy의 일종의 강화 버전이라 할 수 있는 xcopy라는 것도 있으며, 이건 별도의 프로그램을 통해 실행되는 외부 명령이다.

xcopy는 일반 copy와 달리 (1) 서로 다른 드라이브 사이에 서브디렉터리까지 재귀적으로 통째로 복사하는 걸 지원했으며, (2) 복사에 사용하는 메모리 버퍼 크기가 더 크고, 여러 개의 파일을 한꺼번에 읽은 뒤(대략 수백 KB 정도 크기까지) 타겟에다 쓰는 걸 지원했다. xcopy의 전치사 X는 일반적으로 cross라고 발음되었다.

지금 생각해 보면 이 둘은 차별화 요소가 전혀 될 수 없으며 굳이 분리할 필요가 없다. 그냥 copy가 원래 (2)처럼 동작하면 되고, (1)은 /s 같은 옵션을 추가해서 지원하면 될 일이다.
하지만 옛날에 xcopy가 외부 명령으로 존재했던 이유는 겨우 그 정도 고급 복사 옵션/기능마저도 command.com에다 상시 집어넣고 있기에는 메모리가 부족하고 아까웠기 때문이다. 옛날에는 베이직 인터프리터가 Ready 출력할 메모리조차 아까워서 프롬프트를 Ok로 바꾼 시절이 있었다는 것 기억하시는가? (단 3바이트를 아끼려고!) 검색을 해 보니 xcopy는 1987년, MS-DOS 3.2에서 첫 도입됐다고 한다.

하긴, 옛날에는 다단계 디렉터리를 재귀적으로 탐색하면서 뭔가를 하는 일이 쉽지 않아서 외부 유틸리티를 많이 이용해야 했다. 파일 찾기는 말할 것도 없고, 지우는 것도 옛날에는 deltree라는 명령이 따로 있었지 싶다. 그건 지금은 del에 /s옵션으로 통합됐지만 말이다.
유닉스 계열 셸은 내장과 외장 명령어 구분이 어찌 되나 모르겠다. cp, mv, rm은 외부 프로그램인 것 같던데 설마 pwd, cd 이런 것들도 다 외부 프로그램이려나?

그리고 옛날에는 플로피 디스크(일명 디스켓)란 게 쓰여서 파일 시스템 차원에서 완전히 똑같은 디스크 복제를 해 주는 diskcopy라는 외부 명령이 있었다. 얘는 굳이 외부 명령으로 만들 거면 디스크 이미지 파일을 만들거나 이로부터 복제 디스크를 만드는 기능도 같이 있었으면 좋았을 거라는 아쉬움이 남는다.

1.2~1.44MB짜리 디스크를 단일 드라이브에서 복사하려면 source와 target 디스켓을 여러 번 갈아 끼워야 했는데.. Norton Utilities 같은 다른 유틸리티들은 EMS 및 XMS 메모리를 활용하여 한 번만 갈아 끼우고 바로 복사가 된다는 걸 장점으로 내세우곤 했다. 프로그램을 하나 설치하려 해도 "제품의 이제 1~N번 디스크를 넣고 아무 키나 누르세요" 이러던 참 아련한 옛날 추억이다.

2. 16비트 Windows의 실행 모드

예전에 언급한 바와 같이, 1990년대 초중반에 Windows라는 운영체제가 32비트 플랫폼으로 처음 갈아타던 시절에는 Win32 API라는 것의 구현체가 Windows NT, Windows 95, Windows 3.1+Win32s라는 세 계통으로 나뉘었다. NT가 가장 이상적인 레퍼런스 구현체이고, Win32s는 제일 허접하다.

그리고 그 중간의 95는 비록 NT처럼 스레드도 지원하고 도스로부터 많이 독립했다고는 하지만, 도스로부터 완전히 독립했다기보다는 도스를 내부적으로 흡수· 합병한 것에 가깝다. Windows NT의 마이너 축소판이라기보다는 Win32s가 각종 한계 없이 제대로 구현된 형태라고 보는 게 더 타당하다.

그런데 95 계통의 전신이라 할 수 있는 Windows 3.0이 나왔을 때에는 동일 제품· 단일 바이너리 하에서 실행 모드가 세 갈래로 나뉘었다. 바로 8086 리얼 모드, 286 표준 모드, 386 확장 모드이다.
Windows NT 4가 가장 많은 아키텍처를 지원하는 32비트 운영체제였다면, Windows 3.0 (3.1 말고)은 실행 모드가 가장 다양했던 16비트 도스용 운영 환경(?)이었다.

원래 Windows 1과 2에서는 리얼 모드밖에 존재하지 않았으며, Windows는 진짜 도스 위의 덧실행 껍데기 그 이상도 이하도 아니었다. 리얼 모드에서는 메모리가 기본 640K밖에 없었으며, 그 번거로운 16비트 Windows 3.x보다도 프로그래밍 환경이 더 열악했다.

그러다 Windows 2.0의 후속 버전으로 2.1은 286 표준 모드를 도입한 Windows/286과, 386 확장 모드의 전신인 Windows/386 이렇게 두 갈래로 나왔다. 사실, 16비트 80286 프로세서에도 보호 모드가 있긴 했지만 프로그래밍에 애로사항이 많았는지 그걸 사용한 프로그램은 매우 소수였으며 여전히 거의 봉인돼 있었다. 그냥 EMS/XMS 같은 규격으로 메모리를 수백 KB 남짓 더 사용할 수 있다는 것에 의미를 둬야 했다. 386 확장 모드도 첫 버전답게 문제가 많았으며, 2.11이 더 나와야 했다.

그러다가 Windows 3.0은 리얼, 286 표준, 386 확장을 모두 통합하여 출시됐다. 이때는 DPMI 규격도 갓 제정되었기 때문에 2.x 시절보다 보호 모드 지원도 더 개선되었다.
이때는 3.0에다가 멀티미디어 API가 최초로 추가된 확장팩이 나왔으며, 3.1은 네트워크 API가 추가된 Windows for Workgroup 3.11, 그리고 중국어 입출력 지원이 추가된 3.2 이런 식으로 기능 확장팩이 많던 시절이었다. 지금처럼 인터넷을 통한 업데이트가 가능한 시절도 아니었으니 말이다.

Windows 3.1에서는 리얼 모드가 삭제되고 win /2 또는 /3을 통해 286 표준 모드만 지원하지만, 이것은 성능이 굉장히 많이 열화된 모드였다. 그리고 Windows 95부터는 표준 모드도 빠져서 기술적으로 언제나 386 확장 모드로만 동작하는 형태가 됐다.

이렇듯, Windows 3.x는 비록 순수한 32비트 운영체제는 아니지만 보호 모드라든가 도스용 프로그램을 내부에서 구동할 때처럼 일부 기능에서 80386 이상 CPU가 제공하는 가상화 기능을 사용하기 때문에 결과적으로 32비트 CPU가 필요했다. 386 확장 모드가 지원하는 기능이 그런 것이었다.
이는 과거에 존재하던 PIF 편집기가 확장 모드에서는 표준 모드에 비해서 지원하는 옵션이 얼마나 더 다양해지는지를 보면 얼추 짐작 가능하다. 286 표준 모드에서는 요게 전부이던 옵션이..

386 확장 모드에서는 XMS뿐만 아니라 EMS 규격, 그리고 멀티태스킹 우선권 등 다양한 옵션들이 별도의 대화상자와 함께 추가되는 걸 알 수 있다.

Windows 95 역시 순수 32비트 프로그램이 아니면 도스용 프로그램에 대해서만 제대로 된 가상 머신과 선점형 멀티태스킹을 지원했다. 16비트 Windows 프로그램을 강제 종료하면 운영체제와 얽혀 있는 스레드 동기화 오브젝트 같은 것이 얼어붙으면서 시스템의 안정성에 심각한 문제가 발생하곤 했다.

LimitEmsPages 이런 함수는 32비트가 아니라 이미 Windows 3.x 시절부터 deprecated돼 있었는데, 아마 리얼 모드 시절의 잔재이지 싶다.
Windows 1~2.x용 실행 파일은 후대 Windows와 실행 파일 포맷은 동일하지만(NE) 내부의 플래그로 구분되어 있어서 3.x에서 실행하면 "제대로 실행되지 않을 수 있음" 경고가 뜨곤 했다. 요컨대 Windows의 역사를 살펴보면, 16비트에서 32비트로 넘어갈 때만치 큰 변화는 아니지만, 같은 16비트 안에서도 1~2.x와 3.x 사이에 보호 모드가 도입되기 전과 후에는 기술적으로 나름 변화와 단절이 있었다고 볼 수 있다.

3. 외주로 제작되었던 보조 프로그램과 게임

Windows에 내장돼 있는 기본 프로그램들 중에는 마소에서 직접 만들지 않은 외주 프로그램도 있다. Windows 95 시절에 잠깐 있었던 하이퍼터미널이라는 터미널 접속 프로그램이 대표적인 예로, 스플래시 화면이라든가 각종 UI 외형이 대놓고 기존 마소 프로그램과는 어울리지 않아서 마소 자체 개발이 아니라는 걸 알 수 있었다.

또한 게임 중에서도 Windows XP에까지 제공되었던 3D 핀볼(시네마트로닉스 개발, 맥시스 유통)은 외부 프로그램이었으며, Vista/7 시절에 그래픽이 쇄신했던 지뢰찾기 등의 기본 게임들도 외주였다(Oberon games).

그런데 더 옛날에 Windows 3.1의 내장 프로그램들을 보면, 굉장히 단순하게 생겼고 이 정도면 자체 제작했을 법도 한 프로그램이 About 대화상자를 보면 외주인 경우가 은근히 더 있었다. 게다가 아래의 목록에서 보다시피 제작자/제작사가 프로그램마다 완전 제각각이었다.

• 계산기: Kraig Brockschmidt
• 터미널: Future Soft Engineering 사
• 레코더: Softbridge 사
• 지뢰찾기: Robert Donner & Curt Johnson
• 카드놀이: Wes Cherry

그러니 Vista/7 이전에 제공되던 기본 게임들도 알고 보니 외주였던 셈이다. 특히 지뢰찾기는 Windows 1.0부터 3.0까지 존재하던 Reversi(일명 오델로)를 대체할 목적으로 3.1에서 처음 선보였던 게임이기도 하다.
레코더의 경우 Windows의 역사상 거의 전무후무하게 존재하던 키보드· 마우스 매크로 유틸리티인데 95와 그 이후로는 결코 재등장하지 않았으니 희소성이 크다.

물론 이것들 말고 프로그램 관리자, 파일 관리자, 제어판이라든가 간판 앱인 문서 작성기(오늘날의 워드패드)와 페인트(오늘날의 그림판)은 외주가 아니라 내부 자체 제작이다.

4. 색깔의 미묘한 차이

말이 나왔으니 옛날 추억 회상을 더 해 보자면,
컴퓨터의 주메모리가 아니라 비디오 메모리가 딱 1MB이던 시절에는 Windows 3.1의 비디오 모드를 (1) 꼴랑 640*480 저해상도인 대신에 트루컬러, (2) 800*600에서 적당하게 하이 컬러, 아니면 (3) 1024*768에서 256색.. 셋 중 하나로 골라 쓰는 재미(?)가 있었다.

그리고 Windows 3.1은 원래는 우리에게 익숙한 짙은 파란색으로 윈도우의 굵은 틀을 표현했지만, 하이 컬러 이상부터는 어인 일인지 은은한 하늘색으로 색깔을 바꿔 표시했다. 왜 무슨 근거로 색깔을 바꿨는지는 모르겠지만 개인적으로 아주 신기하게 느껴졌었다.

그 이전 3.0은 슈퍼 VGA나 트루컬러로 진입할 일이 있긴 있었는지, 그래픽 드라이버가 개발되거나 3.1 것과 호환되긴 했는지에 대해 본인은 아는 바가 없으며, 이에 대해서 회의적이다.

Posted by 사무엘

날개셋 한글 입력기 같은 Windows용 프로그램을 개발하다 보면 여러 개의 COM 인터페이스를 한꺼번에 상속받아 구현한 단일 클래스를 구현하게 된다.

그런데 하루는 이런 의문이 들었다. 각각의 인터페이스들이 다 IUnknown을 상속받았는데 어떻게 어느 인터페이스로 접근하든지 AddRef, Release 같은 공통 인터페이스들은 중복 없이 동일한 함수 및 동일한 숫자 카운터 인스턴스로 연결될까? 데이터 멤버 없이 인터페이스 상속만 하면 this 포인터 보정이 필요 없이 다중 상속과 관련된 문제들이 상당수 깔끔하게 해결될까?

그래서 클래스 A, 이로부터 상속받은 B와 C, 그리고 B와 C를 다중 상속한 D 이렇게 네 개의 클래스가 있을 때 일명 ‘죽음의 다이아몬드’ 현상을 해소하는 방법이 무엇이 있는지를 정리해 봤다. C++의 다중 상속과 관련해서는 이제 더 글을 쓸 게 없을 줄 알았는데 내가 지금까지 생각하지 못하고 있던 요소들이 더 있었다.

1. 가상 상속

클래스에서 상속이라는 건 기술적으로 어떤 구조체에다가 부모 클래스의 컨텐츠(데이터 멤버)들을 앞에 쭉 늘어놓고 나서 그 뒤에 나 자신의 컨텐츠를 추가하는 것과 같다. 그러니 부모 클래스와 자식 클래스 포인터를 형변환 하는 건 그냥 프로그래밍 언어 차원에서의 의미 변환일 뿐, 메모리 주소가 바뀌는 것은 전혀 없다. 아주 쉽다.

그런데 가상 상속은 부모 클래스의 컨텐츠를 그렇게 나 자신의 일부로서 고정된 영역에 배치하는 게 아니라, 포인터로 참조하는 것과 같다.
부모 클래스를 ‘가상’이라는 방식으로 상속한 자식 클래스는 부모 클래스와 자식 클래스가 굳이 메모리 상에 연속된 형태로 있지 않아도 된다. 그러니 동일 부모를 공유하는 다수의 클래스가 다중 상속되더라도 이들이 공통의 유일한 부모 하나만을 가리키게 하면, 한 부모 클래스의 데이터들이 불필요하게 여러 번 상속되는 것을 막을 수 있다.

여기서 중요한 것은, D가 B, C를 ‘가상’ 상속하는 게 아니라는 점이다. 부모인 B와 C가 A를 미리 가상으로 상속해 놔야 한다.
가상 함수도 자식이 아닌 부모 클래스에서 미리 지정해 놔야 하듯 말이다.

그러니 클래스 라이브러리 개발자는 공통 부모를 공유하는 여러 클래스들이 사용자에 의해 다중 상속되겠다 싶으면 그 공통 부모를 virtual로 상속하도록 설계를 미리 해 놔야 한다. 특히 그 클래스(공통 부모 말고)가 순수 가상 함수 같은 걸 포함하고 있어서 상속이 100% 필수라면 더욱 그러하다.
앞의 A~D의 경우, 혹시 A가 default constructor가 없어서 B, C의 생성자에 모두 A를 초기화하는 인자가 들어있었다 하더라도, D의 A는 D의 생성자에서 제공된 인자만으로 딱 한 번만 초기화된다.

가상 상속을 한 자식 클래스는 굉장히 이색적인 특징을 하나 갖게 된다.
자식 클래스의 포인터에서 부모 클래스의 포인터로 형변환을 하는 것이야 너무 당연한 귀결이며, 반대로 부모에서 자식으로 가는 건 좀 위험한 일이긴 하지만 어쨌든 가능하다. 단일 상속에서는 말할 필요도 없고, 다중 상속이라 하더라도 그냥 고정된 크기만큼의 포인터 덧셈/뺄셈만 하면 된다.
그에 반해, 부모 클래스에서 자신을 virtual 상속한 자식 클래스로 형변환은 일반적으로 허용되지 않는다…!

A *pa = new D; //자식에서 부모로 가는 건 당연히 되고
B *pb = new D;
D *pd;
pd = static_cast<D*>(pb); //부모에서 자식으로 가는 건 요건 괜찮지만
pd = static_cast<D*>(pa); //요건 안 된다는 뜻..

그 자식 클래스의 주소와 부모 클래스의 주소 사이에는 컴파일 타임 때 결정되는 관계 내지 개연성이 없기 때문이다.
자식에서 부모로 거슬러 올라가는 게 단방향 연결 리스트를 타는 것과 다를 바 없게 됐는데, 저런 형변환은 단방향 연결 리스트를 역추적하는 것과 같으니까 말이다.

물론, 가상 상속이라 해도 현실에서는 D라는 오브젝트 내부에서 A가 배치되는 오프셋은 고정불변일 것이고 컴파일러가 그 값을 계산하는 게 불가능하지 않을 것이다. 모든 자식 클래스들과 연속적으로 배치되지만 않을 뿐이다.
static_cast를 어거지로 구현하라면 구현할 수는 있다. 하지만 이 A가 반드시 D에 속한 A라는 보장도 없고, 포인터에 무엇이 들어있는지 확신할 수 없는데.. C++ 컴파일러가 그런 어거지 무리수까지 구현하지는 않기로 한 모양이다.

2. 가상 함수로 이뤄진 추상 클래스(인터페이스)들만 상속

죽음의 다이아몬드를 해소하기 위해서 요즘 프로그래밍 언어들은 C++ 같은 우악스러운 수준의 다중 상속을 허용하지 않고, 잘 알다시피 데이터 멤버 없고 가상 함수로만 구성된 추상 클래스들의 다중 상속만 허용하곤 한다.
그러면 문제의 복잡도가 크게 줄어들긴 한다. 효과가 있다. 하지만 그게 전부, 장땡은 아니다.

명시적인 데이터가 없는 클래스라 하더라도 가상 함수가 들어있는 클래스를 상속받을 경우, 2개째와 그 이후부터는 클래스 하나당 vtbl (가상 함수 테이블 v-table) 포인터만치 클래스의 덩치가 커지게 된다.

단일 상속 체계에서는 this 포인터의 변화가 전무하니 상속을 제아무리 많이 하더라도 한 vtbl의 크기만 커질 뿐, 그 테이블을 가리키는 포인터의 개수 자체가 늘어날 필요는 없다.
그러나 다중 상속에서는 D 같은 한 객체가 상황에 따라 클래스 B 행세도 하고 클래스 C 행세도 하면서 카멜레온처럼 변할 수 있어야 한다. 그렇기 때문에 A, B, D일 때의 vtbl, 그리고 C일 때의 vtbl 이렇게, 테이블과 테이블 포인터가 둘 필요하다.

클래스 D에 속하는 인스턴스 포인터(가령, D *pd)를 부모 C의 포인터로 변환해서 전달할 때는 pd는 A, B, D 같은 직통 상속 계열 vtbl이 아니라 C의 vtbl을 가리키는 형태로 오프셋이 보정된다. 그리고 여기서 가상 함수를 호출하면.. this 포인터가 C가 아닌 D를 기준으로, 보정 전의 형태로 복구된 채로 함수에 전해진다. 이 함수는 애초부터 C가 아닌 D에 소속된 함수이기 때문이다.

즉, 다중 상속에서 가상 함수를 호출하면 비록 겉으로 this 포인터는 바뀐 게 없지만 내부적으로 vtbl을 찾는 것을 부모와 자식 클래스가 완전히 동일하게 수행하기 위해서 보정이 일어나고, 그걸 함수에다 호출할 때는 보정 전의 값을 전하도록 일종의 thunk 함수가 먼저 수행된다.
한 클래스 오브젝트에서 여러 인터페이스 함수를 자유자재로 호출하는 polymorphism의 이면에는 이런 비용 오버헤드가 존재하는 셈이다. 무슨 숫자나 문자열로 메시지를 전하는 게 아닌 이상, 서로 다른 클래스에 존재하는 가상 함수는 vtbl의 종류와 오프셋으로 구분할 수밖에 없다.

3. 멤버로만 갖기

다중 상속의 지저분함을 회피하는 방법 중 하나는.. 원하는 기능이 들어있는 클래스를 내 아래로 상속하지 말고 그냥 멤버 변수로 갖는 것이다. 상속하더라도 걔만 따로 상속해서 확장 구현을 한 뒤에 그걸 멤버 변수로 갖는다. 이 개념을 유식한 용어로는 aggregation이라고 한다.

이 방법은 다중 상속의 각종 오버헤드는 피할 수 있지만 그만큼 다른 방면에서 불편을 야기한다. 그 클래스가 동작하는 과정에서 내 클래스의 함수 및 데이터를 빈번하게 참조해야 한다면(결합도 coupling가 높은 관계..) 그 통로를 억지로 트는 게 더 불편하며 코드를 지저분하게 만든다. 또한 서로 다른 클래스 간에 중복 없이 동일한 기능을 제공하는 일관된 인터페이스를 만드는 게 다중 상속이 아니면 답이 없는 경우도 있다.

이게 경험상 딱 떨어지는 답이 있는 문제가 아니다. 복잡한 클래스 계층이 필요한 대규모 개발을 한 경험이 없는 프로그래머라면 이런 부류의 문제는 배경을 이해하는 것조차 난감할 것이다. 그렇기 때문에 다중 상속이 무조건 나쁘기만 한 건 아니며, 그걸 억지로 우회하다 보면 결국 다른 형태로 불편함과 성능 오버헤드가 야기될 거라며 다중 상속을 옹호하는 프로그래머도 있다.

이상.
객체지향 프로그래밍 언어에서 다중 상속은 사람마다 취향 논란이 많은 주제이다. 비록 C++이 이걸 지원하는 유일한 언어는 아니지만, 네이티브 코드 생성이 가능한 유명한 언어 중에서는 C++이 사실상 대표격인 것처럼 취급받고 있다.

어떤 기능이 절대적으로 나쁜 것만 아니다면야 없는 것보다는 있는 게 좋을 것이다. 상술했다시피 다중 상속이 가능해서 아주 편리한 경우도 물론 있다. 한 오브젝트로 다수 개의 기반 클래스 행세를 자동으로 하는 것과, 그 오브젝트 내부의 구현 함수에서는 여러 기반 클래스를 넘나드는 게 동시에 되니까 말이다.

하지만 다중 상속은 가성비를 따져 보니 그 부작용과 오버헤드, 삽질을 감수하면서까지 굳이 구현하고 지원할 필요가 있나 하는 게 PL계의 다수설 대세로 흐르고 있다. this 포인터의 보정이라든가, 복수 개의 기반 클래스들이 또 공통의 기반 클래스를 갖고 있을 때 발생하는 모호성의 처리 등.. 템플릿 export만치 막장은 아니지만 컴파일러 개발자와 PL 연구자들의 고개는 설레설레 저어지곤 했다.

그래서 C++ 이후에 등장한 더 깔끔한 언어인 D, C#, Java 등은 다중 상속을 지원하지 않는다. 그 대신 다중 상속을 우회하고 복잡도를 완화하기 위해, 적어도 가상 상속만은 할 필요가 없게끔 static 내지 가상 함수 선언만 잔뜩 들어있는 인터페이스에 대해서만 다중 상속을 허용하는 것이다. Java는 두 종류의 상속을 extends와 implements라고 아예 구분까지 했다.

물론 이런 패러다임 하에서는.. 프로그램 구조가 간단해서 가상 함수로 만들 필요가 없는 것까지 일단은 인터페이스부터 만들어 놓고 구현 클래스를 내부적으로 또 만드는 식의 오버헤드 정도는 감수해야 한다. 하지만 Java는 final이 아닌 함수는 기본적으로 몽땅 가상 함수일 정도로.. 디자인 이념이 애초에 성능 대신 극도의 유연성이니, 그 관점에서는 그건 별 상관이 없는가 보다.

가장 대중적인 기술이 알고 보면 레거시 때문에 굉장히 지저분하고 기괴하기도 하다는 것은 CPU계에서 x86이 그 예이고, 프로그래밍 언어에서는 C++이 해당되지 싶다. 전처리기(+생짜 파일 기반 인클루드), 다중 상속, 클로저 없이 특유의 pointer-to-member 기능 같은 것 말이다. 후대 언어에서는 저런 게 결코 도입되지 않고 있다.

본인은 다중 상속을 굳이 의도적으로 기피하면서 코딩을 하지는 않는다. 다중 상속이 필요하고 당장 편하겠다 싶으면 한 클래스에다 막 엮었다. 그 상태로 막 복잡한 pointer-to-member나 람다를 구사하면서 컴파일러를 변태적으로 괴롭히지는 않을 것이고, 컴파일러가 그냥 this 포인터 보정을 알아서 해 주는 것만 원했으니까 말이다.

하루는 ", public"라고 검색을 해서 날개셋 한글 입력기의 소스 코드 내부에도 혹시 다중 상속을 쓴 부분이 있나 찾아 봤는데.. 그래도 2017년 현재 날개셋 한글 입력기의 소스 코드에는 데이터 멤버가 존재하는 클래스를 둘 이상 동시에 상속받은 부분은 없었다. 추가적인 상속처럼 보이는 것은 COM 인터페이스 내지, 내가 콜백 함수를 대신해서 내부적으로 만들어 놓은 추상 클래스 인터페이스들이었다.

한두 번 썼을 법도 해 보이는데.. 이 정도 규모의 프로그램을 만드는 데도 실질적인 다중 상속을 사용한 부분이 없다면 그건.. 정말로 가성비 대비 불필요하게 지원할 필요는 없을 법도 해 보인다.

Posted by 사무엘

1.
과거 2010년대 초에는 제로보드 4를 쓰지 말자, IE6을 쓰지 말자, ActiveX를 퇴출시키자 이런 운동이 벌어졌다. 그때는 같은 PC 안에서 Windows에 종속되지 말고 맥, 리눅스까지 잘 지원하는 웹 표준을 지키자는 게 아젠다였다.

그러다가 2010년대 중반부터는 구시대 관행들이 추가적으로 없어지는 게 눈에 띈다. 웹 상으로 주민 등록 번호 13자리 전체를 수집하는 게 금지되었으며, 기술적으로는 영원불변할 것만 같던 플래시마저 웹에서 퇴출 수순을 밟고 있다. 이건 PC 운영체제 간의 연동이 아니라, PC와 모바일이라는 상이한 플랫폼 간의 연동이 아젠다이다. (플래시 없이 현란한 광고 애니메이션은 어째 만드나 싶다.)

사실, 기술과 이론만 따지자면야 모바일에서도 플래시를 지원하지 못할 이유는 없다. 그러나 플래시는 근본적으로 현란한 벡터 애니메이션을 출력하려고 만들어진 물건이니 설계 이념이 딱히 화면 작고 전력 소비에 민감한 모바일과는 친화적이지 않다. 기기와 무관한 접근성의 보장이라는 웹 표준과도 어울리지 않는다.

더구나 플래시도 따지고 보면 그 본질은 3rd-party plug in이고 IE의 용어로 표현하자면 ActiveX의 일종이긴 했다. 플래시를 집어넣을 때 쓰는 태그가 여느 ActiveX 컨트롤을 집어넣을 때 사용하는 태그와 다를 바 없다. 다만, 얘는 독보적으로 너무 유명하고 널리 쓰이다 보니 타 ActiveX와는 지위가 다른 예외적인 물건으로 취급되어 왔을 뿐이다.

그러니, 좀 웹 표준을 어겨도 PC에서는 큰 문제가 되지 않던 것이 완전히 차원이 다른 컴퓨팅 환경인 모바일에서는 더욱 부각되게 되었다. 거기에다 보안 문제도 불거지고, 또 모종의 이유로 인해 아이폰 제조사인 애플과 플래시의 제조사인 어도비가 사이가 나빠지는 악재까지 겹치면서 플래시는 인터넷에서 퇴물로 전락했다. 급속도로 몰락의 길을 가게 됐다.

플래시가 독자적으로 제공하던 고급 기능들은 그냥 웹브라우저가 직통으로 지원하는 HTML5 표준으로 몽땅 이동했다. 인터랙티브하게 싹 나타났다가 사라지는 웹사이트 메뉴, 인터랙티브한 게임, 간단한 이미지 편집 등등이 몽땅 말이다.
Chrome 브라우저의 경우 플래시는 자동 실행은 개뿔 물 건너 갔으며, 사용자가 수동으로 켜 줘야만 실행되는 legacy가 됐다. 음.. 예전에 흑역사로 사라졌던 MS Office의 길잡이를 보는 듯한 느낌이다. 웹 환경이 이렇게 변할 줄이야..

2.
인터넷 IPv4 주소 고갈과 주소 할당 중단은(이미 2011년의 일임!) 마치 유니코드에서 BMP 영역의 고갈과 비슷한 성격의 현상 같다.
결국 요즘 사람들은 대부분 공유기를 사용해서 인터넷을 하고 고정 IP라는 개념이 사실상 없어졌는데,
공인 IP와 사설 IP가 따로 노는 것 때문에 계층이 좀 헷갈리고 복잡해지고 골치 아파진 것도 있다. 이건 마치 분당선 서현 역이 지하철 출구 번호(안)와 백화점 출구 번호(밖)가 서로 완전히 따로 놀아서 위치 식별이 어려운 것과 비슷한 양상이다.

초기에 설계되었던 공인 IP 주소 영역들을 보면 class A~C 이런 거 말고도 공유기를 위한 영역을 따로 떼어 놓은 게 있는데.. 이게 유니코드로 치면 UTF-16에 존재하는 surrogate와 개념상 정확하게 일치한다. (처음엔 유니코드에 UCS2만 있었지 UTF-16 같은 게 있지는 않았듯이, IP 주소도 처음부터 공유기 영역에 있지는 않았었다.)
아니, 애초에 유니코드가 없던 시절에 지원 글자 수를 늘리려고 사용하던 multibyte, lead byte, tail byte 따위와도 비슷한 개념이라 볼 수 있다.
또는 16비트 시절의 far pointer하고도 비슷하고 말이다.

결국 32비트, 64비트, IPv6처럼 본질적으로 더 우월하고 넉넉하고 나은 것, 완전한 것이 오기 전에 컴퓨터에서 불완전한 것으로 임시땜빵을 하는 방법은 분야를 불문하고 방법론이 다 비슷해 보인다~!

3.
예전에 PC에서는 ICQ, MSN, 그리고 국내 한정으로 네이트온 같은 온라인 메신저가 있었다. 얘들은 시대가 시대이다 보니 PC 전용이었는데, 2010년대 들어서는 다들 망하고 스카이프만이 MS에 인수되어 살아 있는 듯하다.
2010년대에는 카카오톡이 스마트폰 앱과 PC 통합으로 메신저 시장을 사실상 평정했다. PC는 사람이 기계가 있는 곳으로 가서 기계의 전원을 넣어야만 쓸 수 있는 반면, 스마트폰은 365일 24시간 내내 켜져 있으며 사람이 늘 들고 다닌다. 이런 결정적인 차이로 인해 카카오톡은 과거의 메신저와는 달리, 자기 상태를 표시하는 기능이 없다~! (available, away, out to lunch 같은)

카카오톡은 PC용이 있기 때문에 PC와 모바일을 지원한다.
한편, SNS 웹사이트로 출발한 페이스북도 메신저 기능이 있으니, 모바일과 '웹'을 지원하는 셈이다.
예전에 잠시 있었던 Google Talk은 PC용 프로그램, 모바일용 앱에다가 gmail 같은 Google 계열 사이트에서 실시간 대화도 지원하여 드물게 PC, 모바일, 웹을 모두 커버했던 걸로 기억한다.
이렇게 애플리케이션들이 실행 양상이 다양해지고 있는 게 흥미롭다.

그리고 2010년대부터는 웹 자체도 사용자 상호작용과 반응성이 워낙 좋아진 관계로 PC용 네이티브 프로그램까지는 몰라도 모바일 앱의 정체성을 크게 위협하고 있다..
물론 기기의 물리적인 기능에 아주 특화된 기능이라든가 방대한 게임 같은 건 모바일 기기에서 직통으로 돌아가는 프로그램이 필요하겠지만, 단순 서버와의 교신과 정보 공유, 조회, 열람이 목적이면 웹 페이지와 자바스크립트 자체를 그냥 기계와 운영체제를 초월한 통합 GUI 플랫폼으로 쓰지 말라는 법이 없게 되는 셈이다.

순수 웹 애플리케이션은 서버 주소만 알려주면 앱스토어 심사 같은 것도 필요 없고 곧장 배포가 가능하다. 웹 전체를 검열하는 빅 브라더 같은 건 세상에 존재하지 않으니 말이다.
그러나 웹을 기반으로 안드로이드와 iOS를 모두 통합하고, 부분적으로 각 모바일 플랫폼에 종속적인 코드를 끌어다 쓸 수 있는 형태인 '하이브리드' 앱이 있다. 그리고 그런 걸 만들어 주는 프레임워크도 있다. qt가 PC에서 Windows/리눅스/macOS 통합이라면, 아이오닉 같은 모바일 프레임워크는 안드로이드/iOS 통합인 셈이다.

'아이오닉'은 하이브리드 자동차의 이름이기도 한데 컴퓨터에서도 나름 하이브리드 모바일 프레임워크의 이름이구나(비록 영어 철자는 차이가 있지만). 디스크와 드럼(브레이크 vs 메모리 기술), 엑셀(자동차 이름 vs 스프레드시트 이름)처럼 들린다.

4.
웹은 기계와 CPU 아키텍처에 구애받지 않는 정말 universal한 프로그래밍 환경이다. 그 누구도 처음에 상상하는 것조차 쉽지 않았다.
인터넷에서 다른 형태의 프로토콜로 제공되는 서비스들도 거의 다 웹이 몽땅 독식해 버렸다. 글과 그림과 하이퍼링크만 있는 문서에 불과하던 웹은 한 2, 30년쯤 전의 옛날 얘기이고, 지금은 이게 그냥 인터넷의 알파와 오메가요, 문서와 코드의 짬뽕인 광활한 프로그래밍 환경이다. 그러니 웹 프로그래밍을 하나 잘 공부해 놓으면 그야말로 모든 기계에서 똑같은 결과가 나오는 프로그래밍 스킬을 얻게 된다.

웹이 그런 공룡 같은 거대한 환경으로 발전하는 과정에서 브라우저, 언어 등 각종 규격들이 찢어졌다가 표준화된 과정도 살펴보면 참으로 격세지감이 느껴지는 한편으로, 인간 사는 바닥은 어디든 다 정치와 밥그릇 싸움, 돈지랄이 있구나 하는 병맛스러움이 느껴진다.

HTML4의 지저분함을 참다못해 1990년대 말에 엄격한 XHTML이 제정되었지만, 결국 망하고 HTML5가 다시 옛날 관행 기반에서 제정된 건.. 1990년대 말에 IA64가 너무 과격한 변화를 추구하다가 망하고 기존 x86 호환성을 유지한 amd64로 64비트 컴퓨팅의 판도가 기운 것과 비슷해 보인다. 시기도 서로 비슷한 편이다.

또한 Windows 10이 2015년 가을에 나온 첫 판이 지금까지 그대로 유지되고 있는 게 절대 아니듯, HTML5도 보아하니 한번 정하고 영원히 고정이 아니라 찔끔찔끔 계속 뭔가 추가되고 있긴 한 모양이다. 그렇기 때문에 전통적인 ACID 테스트 말고 또 2017년 현재까지 만점을 받은 브라우저가 전혀 없는 다른 HTML5 점수 테스트 사이트도 있다.

한편으로 HTML4 이래로 무려 15년 가까이 뒤에야 HTML5가 제정되고 HTML이 급격히 발전하고 있는 건 C++98 내지 C++03 이후로 C++이 2000년대에 정체돼 있다가.. C++1x 이후로 C++이 함수형 패러다임도 받아들이고 네이티브 코드 생성 언어가 갑자기 약 빤 듯이 발전하고 있는 양상과 비슷해 보인다.

웹이 MS Office 문서라면 자바스크립트는 VBA 매크로와도 같은 물건이다. 그리고 내가 HTML, CSS, JS를 삼권분립과 비슷한 구도라고도 비유한 바 있다. 게임 개발에다 비유해도 기획자, 디자이너, 개발자에 착착 잘 대응하는 것 같다.
아 그래..! 옛날에는 이런 스크립트 자체가 단일화되지 않아서 HTML 주석 안에다가 스크립트 코드를 몰래 집어넣어야 했다. 마치 프레임만큼이나 "이 웹페이지를 제대로 표시하려면 자바스크립트를 지원하는 브라우저가 필요합니다" 이런 말이 출력되도록 참 기괴하게 HTML 문서를 작성했었다. 이거 도대체 언젯적 얘기냐..;;

또한, 웹 프로그래밍에 스크립트는 클라이언트 쪽만 있는 게 아니라 서버 쪽도 있다. 클라이언트는 처리가 빠른 대신 대외적으로 프로그램 소스 코드가 몽땅 공개돼야 한다. (뭐, 난독화는 가능하지만) 서버 쪽은 소스가 노출되지 않지만 데이터 입출력에 서버와 네트워크 트래픽을 감수해야 한다. 이것도 컴퓨터 한 대에서만 돌아가는 프로그램을 만들 때에는 고려할 필요가 없는 흥미로운 면모이다.

이런 와중에 마소는 20여 년 전 1990년대 중반에 Bob이라든가 MSN 이런 거 만들면서 좀 삽질을 했었다. Windows 95를 만들어서 개인용 PC의 운영체제는 자기 뜻대로 세계정복을 했지만, 인터넷까지 자기 서비스만으로 호락호락 세계를 정복할 수 있으리라 생각했던 건 큰 오판이었다. 그래서 잘 알다시피 IE를 수단과 방법을 가리지 않고 운영체제에다 끼워넣어서 웹 브라우저의 전면무료화 관행을 정착시켜 버리기도 했다. 하지만 IE 자체는 경쟁 브라우저와 모바일 환경 때문에 세계정복까지는 이루지 못했다.

또한 마소는 2000년대 말에 와서는 PC에 너무 안주하고 모바일 환경에 대해서도 대수롭지 않게 예상하다가 스마트폰 플랫폼의 주도권을 안드로이드와 iOS에 완전히 뺏겨 버렸다. 그 시기에 LG전자가 피처폰에 안주하다가 지금 같은 처지가 된 것과 비슷한 실수이다.
그런데 2000년대 중후반엔 나조차도 솔직히 말해 사고의 구조가 "그냥 디카 쓰면 되지 폰에다가 카메라를 왜 얹어?" 이러던 수준이었다. 어지간한 전문가라도 스마트폰이 이렇게 뜨고, 그 스마트폰 OS를 오픈소스로 전세계에 뿌려 버리는 괴수 용자 대인배가 등장할 거라고는 예상할 수 없었다.

즉, <미래로 가는 길> 같은 베스트셀러 책을 이미 1990년대 중반에 썼던 천하의 빌 게이츠조차도 웹과 모바일에 대한 전망이 다 적중하지는 못했다. 뭐, "손가락 끝으로 모든 정보를" 같은 큰 그림이야 물론 적중했지만, 그런 기술이 언제나 자기가 원하는 형태로 보급되고 마소 주도적으로 이뤄지지는 않았다는 것이다.

그나저나, IA64 하니까 떠오르는데.. 소프트웨어 업계에서는 2000년 가을쯤 Windows ME와 아래아한글 워디안도 비슷하게 세기말의 흑역사 삽질을 좀 했다는 공통점이 있다.

Posted by 사무엘

오늘은 기초 전산학/컴공 상식을 좀 복습해 보고자 한다.

※ 지금과 같은 컴퓨터의 근간이 갖춰진 과정

1. 순 전자식

이로써 인간이 발명한 계산 기계는 엔진 달린 주판 수준을 넘어서 자신의 모든 내부 상태를 전자 신호만으로 광속으로 표현할 수 있게 됐다. 에니악이 순 전자식 컴퓨터로서는 거의 최초 원조라 여겨진다. 이거 이후로 컴퓨터는 진공관, 트랜지스터, IC, (V)LSI 회로 순으로 그야말로 엄청난 공간 워프를 거듭하면서 작아지고 빨라지기 시작했다.

전자식이 아니라면? 컴퓨터도 엔진이나 모터가 달린 채로 만들어졌을 것이다. 19세기에 영국의 수학자 찰스 배비지는 '프로그래밍 가능한 보편적인 계산 기계'인 '해석 기관'이라는 걸 제안하고 만들려 했다. 시대를 아득히 앞서 간 물건이었는데, 그걸 가동하기 위해서 무려 증기 기관을 접목할 생각까지 했었다. 지금 같은 눈부신 전자 공학 기술이 없던 시절이니 당연히 기계식밖에 선택의 여지가 없었던 것이다.

그리고 1940년대 초에 에니악 이전에 등장했던 '하버드 마크 1'이라는 기계는 '전자식 계산기'라기보다는 '전동식 계산기'에 더 가까웠다. 복잡한 배선과 릴레이뿐만 아니라 4마력짜리 모터가 달려 있었다. 이건 냉각팬 모터가 아니며 하드디스크 같은 기계식 보조 기억장치용 모터도 아니고, CPU의 실제 계산 동작을 위한 모터였다..;;

2. 2진법 기반

사람이나 열 손가락이 달려 있으니 10진법이 편하지, 기계는 단순한 2진법이 더 편하다. 컴퓨터가 전자식으로 바뀐 뒤부터는 그 차이가 더욱 두드러졌다.
하지만 극초창기에는 숫자 진법을 변환하는 것조차 쉬운 작업이 아니었고, 정수가 아닌 부동소수점으로 가면 숫자를 표현하는 난이도가 더 올라갔다. 더구나 컴퓨터는 처음부터 포탄 탄도 예측, 풍동 실험, 일기예보 시뮬, 모의 핵실험처럼 천상 실수 연산이 잔뜩 필요한 과학 영역에서 쓰였다.

그러니 에니악 같은 컴퓨터는 10진법 기반으로 만들어졌다. 4비트를 한 자리로 묶어서 0~9를 표현하는 BCD 코드 기반이었지 싶다. 하지만 10진법 숫자를 처리하기 위해서 어차피 2진법 기반의 각종 논리 연산 회로를 구현해야 했을 것이고, 후대의 컴퓨터들은 얼마 가지 않아 native 2진법 기반으로 다 바뀌었다.

3. 튜링 완전

프로그램이 하드코딩된 고정된 변수가 아니라 메모리에 기록된 값을 토대로 또 임의의 위치의 메모리를 읽고 쓸 수 있고(= 배열, 포인터 등을 이용한 복합 자료형. 공간 확장),
런타임 때 결정되는 값의 조건에 따라 반복과 분기가 가능하다면 (= 시간 확장)
그런 계산 모델은 Turing-complete하다고 여겨진다. 즉, 단순 계산기를 넘어 뭔가 본격적으로 프로그래밍이 가능해진다는 것이다.
그 열악한 에니악조차도 설계 구조는 튜링 완전한 형태였다고 한다.

4. 프로그램 내장형

컴퓨터에게 시킬 작업을 변경하기 위해 매번 회로 배선을 뜯어고치고 바꾸는 게 아니라, 한 메모리에서 코드와 데이터를 일체로 내장시킨다. 이 개념까지 정립됨으로써 비로소 컴퓨터는 정말 유연하고 무한한 확장성을 지닌 물건으로 변모했으며, 컴퓨터에서 하드웨어와 별개로 '소프트웨어'라는 것이 존재할 수 있게 됐다.
또한, 메모리가 컴퓨터의 성능에서 차지하는 비중이 아주 커졌다. 프로그램을 메모리에다 처음으로 입력시킬 때는 과거엔 천공 카드 같은 불편한 매체가 쓰였지만, 나중에는 더 간편한 키보드로 대체됐다.

저 아이템들 하나하나가 그야말로 병아리가 알을 깨고 세상으로 나오는 급의 대격변이고 혁신이었다.
인류 역사상 이런 네 조건을 모두 만족하는 컴퓨터가 발명되고 등장한 지 아직 100년이 채 지나지 않았다. 자동차와 비행기의 역사는 100년을 넘었지만 컴퓨터는 아직 그렇지 않고 오히려 2차 세계 대전 이후 냉전 때부터 발전해 왔다.
그 짧은 기간 동안 컴퓨터가 인류 역사상 유례가 없이 세상을 바꿔 놓은 걸 보면.. 정말 전율이 느껴지지 않을 수 없다.

※ 메모리 계층

컴퓨터는 모름지기 정보를 다루는 기계이다. 그리고 앞서 언급했던 프로그램 내장 방식의 특성상, (1) 실행할 코드와 (2) 그 코드가 처리할 데이터가 모두 메모리에 담겨 있어야 한다. 쉽게 말해 정보를 담을 그릇이 필요하다.
그런데 컴퓨터가 취급하는 메모리라는 게 여러 종류가 있고, 이들은 속도와 용량, 단위 용량당 가격이 극단적으로 반비례하는 관계이다. 그렇기 때문에 종류별로 일종의 '메모리 계층'이 존재한다.

1. 레지스터(수십~수백 byte)

CPU 구성요소의 일부이다. 당연히 CPU 차원에서 최고속으로 직통으로 값을 읽고 쓸 수 있다.
현재 프로그램이 실행되고 있는 지점(메모리 위치), 수만 번씩 실행되는 for 문 loop 변수, C++ 함수의 경우 this 포인터, 산술 연산 명령에 쓰이는 피연산자와 연산 결과 같은 정~말 원초적인 값들이 이곳에 저장된다.
실행되는 스레드의 context가 바뀌면 레지스터의 값도 자기 상태의 것으로 바뀐다.

2. 캐시 메모리(수백 KB~수 MB)

CPU 자체는 아니지만 여전히 CPU의 연장선 격이며 접근 속도가 매우 빠르다. CPU가 사람 두뇌이고 레지스터가 손의 손가락이라면 캐시는 의수 정도는 된다.
얘는 CPU 속도와 메모리 속도의 격차가 커지면서 메모리로 인한 병목을 줄이기 위한 버퍼 차원에서 도입되었다.

캐시도 레벨 1, 레벨 2로 나뉘긴 하는데, 인텔 x86 CPU에서 제일 원초적인 L1 캐시는 80486 때 8K짜리가 도입된 것이 최초이다. 반대로 펜티엄 2이 나왔던 시절에 셀러론 프로세서는 L2 캐시를 제거하거나 용량을 팍 줄인 저가형 모델이었다.

3. 일반 메모리(수십 GB)

CPU의 외부에 있기 때문에 위의 것들보다는 느리지만, 그래도 보조 기억장치보다는 여전히 훨씬 빠르다. 이들 메모리는 전원이 끊어지면 내용이 다 지워지는 휘발성 메모리이다. 이제 신체 접근성으로 치면 의수를 넘어서 핸들과 버튼으로 따로 조작하는 로봇 팔과 비슷하다고 볼 수 있겠다.

4. 하드디스크(수 TB)

디스크부터는 보조 기억장치이기 때문에 이건 CPU의 명령만으로는 직접 접근조차 할 수 없다. 운영체제라는 소프트웨어가 구현해 놓은 파일 시스템에다 해당 운영체제 API를 통해 요청해야만 데이터를 읽고 쓸 수 있다. 파일 시스템은 열고 닫는 상태를 따로 보관하고 관리해야 하며, 프로그램의 입장에서는 여는 작업이 실패하는 상황에 대한 대비가 필요하다.
사람으로 비유하면 내 손으로 뭔가를 직접 조작하는 게 아니라, 남에게 말로 부탁을 해서 간접적으로 뭔가를 요청하고 움직이는 형태가 된다.

그 대신 보조 기억장치는 전원이 끊어진 뒤에도 기록을 남기고 보존할 수 있다. persistency를 보장하려다 보니, 하드디스크는 컴퓨터에서 전자식이 아닌 기계식으로 동작하는 얼마 안 되는 부품 중 하나가 돼 있다. 플래시 메모리는 '일반 메모리'의 성격에 더 근접해 있는 기억장치이지만, 가격과 용량 문제 때문에 하드디스크를 완전히 대체하는 구도는 못 된다.

캐시 메모리에서 캐시 미스가 나서 더 느린 일반 메모리까지 내려가서 데이터를 가져오는 게, 아래의 운영체제의 가상 메모리 체계에서 페이지 폴트가 발생해서 디스크의 페이지 파일에서 데이터를 가져오는 것과 비슷한 구도이다. 메모리 공간 자체가 CPU의 일부는 아니지만, 보호 모드 가상 메모리 구현을 위한 주소 변환은 CPU 차원의 지원을 따로 받아서 이뤄진다.

메모리가 비싸고 귀하고 부족하던 옛날에는 가상 메모리라는 게 디스크를 메모리 보충분처럼 사용하는 메커니즘이기도 했다. 비록 속도는 안드로메다로 가 버리지만, 그래도 아예 안 돌아가는 것보다는 나으니 better late than never이다. 요즘 운영체제들은 memory mapped file이라고 디스크를 반쯤 메모리 다루듯이 포인터로 접근시켜 주는 API를 제공하는데, 가상 메모리를 구현하면서 내부적으로 구현된 기능을 사용자도 적절하게 활용하라고 떼어 준 것에 가깝다.

또한, 가상 메모리와는 별개 개념으로.. 레지스터와 메모리 사이에 '캐시 메모리'가 있듯이, 메모리와 디스크 사이에 '디스크 캐시'라는 계층이 존재한다. 이게 잡아먹는 메모리 양이 만만찮지만 도스 시절에 smartdrv 유틸로 수백 KB~2MB 남짓만 캐시를 잡았어도 체감 성능 향상 효과가 장난이 아니었다. 이거 없이 곧이곧대로 찔끔찔끔 디스크에 접근해서는 오늘날의 방대한 컴퓨터 시스템이 돌아가질 못한다. 그만치 메모리와 디스크 사이의 속도 격차 병목이 엄청나다는 뜻이다.

5. 자기 테이프(수백 TB~수 PB)

아주 극단적인 보조 기억장치이다. 느리고 랜덤(임의 위치) 접근이 안 된다는 엄청난 단점이 있지만, 용량이 가히 압도적이고 가격이 저렴하다. 그렇기 때문에 서버 전체 내지 매일 생성되는 방송국 동영상 같은 엄청난 양의 데이터를 오로지 백업· 보존만 할 목적으로 일부 연구소나 기업에서 테이프가 여전히 사용되고 있다. 마치 국제 화물 운송에서 선박이 차지하는 위상(느리지만 엄청난 수송량)과 비슷하고, 프린터계에서 도트 프린터의 먹끈 카트리지(원시적이지만 타의 추종을 불허하는 저렴함)와 비슷하다.

메모리야 컴퓨터 프로그램들이 맨날 하는 짓이 저걸 건드리는 것이고, 보조 기억장치는 파일을 읽고 쓰는 운영체제 API를 통해 사용 가능하다.
레지스터의 경우, C/C++ 언어에는 특정 정수 변수를 가능한 한 저기에 얹어 달라고 컴파일러에게 요청하는 register이라는 키워드가 있다. 함수에 inline이 있다면 변수는 저게 있는 셈이다. for문 loop 변수가 레지스터에 올라가면 좋다.
물론, inline 함수는 재귀호출을 해서는 안 되며, 레지스터 등재 변수는 주소 참조(단항 & 연산자)를 해서는 안 된다.

이렇게 타 메모리나 디스크나 레지스터와는 달리, 캐시 메모리만은 적중률을 올리기 위해 소프트웨어가 직접 접근하고 개입하는 방법이 딱히 존재하지 않는다. 멀티코어 병렬화를 위해서는 CPU 직통 명령인 인트린식 같은 것도 있는데 캐시는 활용 방식이 소프트웨어가 아닌 오로지 CPU의 재량인가 보다.
이렇게 존재감이 없음에도 불구하고 캐시 메모리의 양과 성능은 클럭 속도 다음으로 컴의 속도에 직접적인 영향을 끼치는 요인이다.

※ 인텔 x86

인텔 x86은 전세계의 PC 시장을 완전히 석권한 기계어 아키텍처이다. 애플 맥 진영이 x86으로 갈아탄 지 이미 10년이 넘었고, 슈퍼컴퓨터조차도 Cray 같은 슈퍼컴 전용 아키텍처가 진작에 다 망하고 x86이 코어 수를 늘려서 야금야금 파고들고 있다.

하지만 x86은 CPU를 만들던 기술과 방법론이 지금과 같지 않던 초창기, 특히 메모리 가격이 왕창 비싸던 시절을 기준으로 기반이 설계되었으며 16, 32, 64비트로 올라가는 과정에서도 하위 호환성을 잘 유지하고 있다. 그래서 넘사벽급의 범용성과 시장 경쟁력은 확보했지만, 내부 구조가 갈수록 왕창 지저분해지고 스마트폰용 ARM 같은 후대의 최신 CPU들의 유행과는 영 동떨어진 형태가 됐다.

• 범용 레지스터 수가 유난히 매우 적음. R## 이렇게 수십 개씩 번호가 붙는 게 아니라 EAX EDX ESI EBP 등 꼴랑 8개로 끝인 건 x86이 예외적이고 특이하기 때문이다. 함수에다가 매개변수를 올리는 주 방식도 x86은 당연히 레지스터가 아닌 스택 기반이다. 이 때문에 컴파일러 백 엔드를 개발하는 방법론이 x86 타겟 계열과 타 아키텍처 계열은 서로 완전히 다르며, x86은 오늘날 컴공과에서 컴파일러 제작 교육용 교보재로 쓰이기에는 영 좋지 못한 타겟 아키텍처이다.
• 메모리를 조밀하고 compact하게 쓰는 대신에, 디코딩이 복잡하고 더 어려운 CISC 가변 길이 방식으로 명령어를 기술한다. 한 인스트럭션으로 연산에다 메모리 조작까지 몽땅.. 이런 식으로 많은 지시를 함축하고 있는 편이다. 자동차 엔진으로 치면 회전수가 낮은 대신 실린더의 스트로크가 긴 디젤처럼..
• machine word align이 맞지 않은 메모리 주소의 값을 fetch하는 것을 굉장한 비효율(여러 클럭수 소모)을 감수하고라도 CPU 차원에서 아무 문제 없이 잘 처리해 준다. 요즘 CPU 같았으면 그냥 예외 날리고 끝이었을 텐데.. 이 역시 메모리를 아끼기 위한 조치이다.

레지스터가 부족하면 나중에라도 더 보충하면 되지 않냐고?
레지스터는 추가로 더 꽂기만 하면 되는 메모리가 아니라 CPU 그 자체이다. 그걸 뒤늦게 확장한다는 건 CPU의 아키텍처, 세부 설계와 생산 라인이 다 바뀐다는 뜻이다. 컴파일러도 그에 맞춰 바뀌고 프로그램도 몽땅 다시 빌드되어야 추가된 레지스터 덕을 볼 수 있다. 사람으로 치면 가방 크기를 더 키우는 게 아니라 생물의 유전자 차원에서 손의 크기, 손가락 개수를 더 키우고 늘리는 것과 같은 엄청난 변화이다.

x86이 너무 지저분하다는 건 제조사인 인텔도 누구보다 잘 알고 있었기 때문에 과거 2000년대 초, 64비트 CPU를 내놓는 김에 애플처럼 하위 호환성을 싹 버리고 현대적인 디자인 트렌드를 따라 과감한 물갈이를 하려 했다.
마소 역시 새천년 Windows 2000에 맞춰 64비트 에디션을 당당히 내놓으려고 벼르고 있었다. Windows SDK 헤더 파일에서 INT_PTR, INT64 이런 typedef가 등장하고 GetWindowLong이 GetWindowLongPtr로 감싸진 게 이 시기의 준비 작업이었다.

하지만 모두의 예상을 깨고 IA64 Itanium라는 새 아키텍처는 CPU와 컴파일러 개발이 제대로 되지 않고 호환성도 안습했기 때문에 철저히 망하고 실패했다.
결국 지금은 기존 x86을 그대로 수용하면서 Itanium보다 훨씬 더 현실과 절충한 x86-64라는 다른 아키텍처를 기반으로 64비트 컴퓨터가 쓰이게 됐다. 이 아키텍처는 인텔이 아니라 경쟁사인 AMD가 최초로 개발했다.

Windows 2000은 과거 NT 3~4 시절에 지원했던 한물 간 구형 CPU들의 지원은 다 끊었고(Alpha, PowerPC, MIPS 등), IA64는 베이퍼웨어이고, 지금 같은 ARM이나 x64는 아직 안 나왔다 보니 NT로서는 이례적으로 사실상 x86 전용으로만 출시되어야 했다.

그런데.. 인텔 x86이 저렇게 메모리 아끼려고 CPU 본연의 효율까지 희생하면서 헝그리하게 설계된 건 과거 PC의 역사를 살펴보면 충분히 이해가 된다.
32비트 80386 CPU가 이미 1985년에 개발됐는데도 Windows NT, OS/2 같은 이상적인 32비트 운영체제의 도입과 보편화가 10년 가까이 너무 늦었고 Windows 9x 같은 요물이 몇 년간 쓰여야 했던 이유는 32비트 가상 메모리를 운용하고도 남을 정도로 컴의 메모리가 충분치(못해도 수~십수 MB) 못했기 때문이다. (CPU 말고 그래픽 카드는 1987년에 VGA가 개발되자 못해도 2~3년 안으로 프로그램들이 다 지원하기 시작함)

64비트로 넘어갈 때도 마찬가지다. IA64가 개발되던 1990년대 말엔 아직 가정용 컴의 메모리는 100~200MB대에 불과했다. 32비트를 벗어나야 할 이유가 전혀 없었다. 64비트 CPU는 대용량 데이터 처리 분야에서 속도가 좀 더 올라갈지는 모르지만, 같은 명령과 데이터를 수행하더라도 메모리 소모가 훨씬 더 많아지는 건 피할 수 없었다. 이러니 가정용 PC에서 64비트의 대중화는 Windows 2000/XP 시기는 어림도 없고, 본격적으로 램 용량이 4GB를 넘어선 2000년대 후반 Vista/7급은 돼서야 이뤄지게 됐다.

Posted by 사무엘

1. Windows 부팅

Windows 8 내지 10부터던가.. 요즘 Windows에서는 예전까지 오랫동안 쓰이던 통상적인 부팅 전 F8 메뉴가 사라졌다. 하긴, 메뉴가 여럿 있긴 했지만 고르는 건 안전 모드(F5) 또는 네트워크 되는 안전 모드 둘 중 하나밖에 없긴 했다.
그 대신, 부팅 후에 컴을 팩토리 리셋 초기화시키는 메뉴가 곧장 들어간 것은 일단 꽤 유용하며, F8을 눌러야 할 필요를 이걸로 상당수 대체하긴 했다.

하지만 뭐가 꼬여서 애초에 부팅이 안 되고 있을 때는 이 기능에 접근할 수 없어서 더 불편해졌다. 부팅 전의 OS 재설치 및 복구 UI는 사용자가 특정 글쇠를 눌렀을 때 바로 뜨는 게 아니라, 수차례 컴퓨터를 혹사시키면서 부팅이 실패한 것을 얘들이 인지했을 때에 그제서야 슬그머니 띄워 준다. 로직을 왜 이런 식으로 만들었나 모르겠다.

전에도 얘기했듯이, 본인은 업데이트를 받은 뒤에 운영체제가 꼬이고 커널 패닉 뜨는 걸 몇 번 겪은 뒤부터는 진절머리가 나서 업데이트 받는 걸 레지스트리까지 조작해서 강제로 끊어 버렸다. 지금 네트워크는 유료 종량제이니 니 멋대로 함부로 업데이트 받아서 설치하지 말라고 말이다.

CPU와 메모리와 네트웍 트래픽 잡아먹고 하드디스크 용량 잡아먹고, 컴퓨터를 꺼야 할 때 바로 곧이곧대로 꺼지질 않고.. 민폐가 너무 심한 데다, 그런 민폐가 시도 때도 없이 너무 자주 발생하고.. 설치 후에도 뭐가 크게 달라지고 좋아지기는커녕 저런 부작용만 있으니 이 상황에서 누가 업데이트 꼬박꼬박 받고 싶은 마음이 들겠는가?

그거 안 하고도 내 컴은 악성 코드고 뭐고 지금까지 보안 문제 같은 건 하나도 없었다. 이러다가 업데이트에 대해서조차도 현대 서양 의학 불신, 백신 불신 같은 이상한 풍조가 생기지는 않으려나 모르겠다만.. 브라우저를 선택할 권리 운운하면서 웹 표준 외치는 것만큼이나, 필요하지 않은 업데이트를 안 받거나 원하는 타이밍에만 받을 권리도 좀 보장됐으면 좋겠다.

2. 바이오스

뭐, 이건 운영체제 얘기였고 그 전에 롬에 탑재된 컴퓨터 고유의 소프트웨어 계층을 일명 BIOS라고 부른다. 이것도 2010년대에 와서는 UEFI라는 새로운 규격으로 바뀌었다.
운영체제 부팅 전에 BIOS 셋업(CMOS 셋업이라고도 불렀던 듯..)을 들어가려면 ESC, F2, F10, Del 이런 글쇠를 죽어라고 누르곤 했는데, 이 글쇠도 좀 Ctrl+Alt+Del 재부팅처럼 통일이 됐으면 하는 생각이 든다. 바이오스는 어차피 만드는 업체도 피닉스나 아메리칸 메가트렌드 요렇게 아주 소수이지 않던가?

살면서 BIOS setup으로 들어가야 하는 상황은 몇 년에 한 번꼴로 운영체제 변경· 재설치를 위해 부팅 매체 선택 순서를 변경할 때.. 혹은 하이퍼-V 가상화 같은 옵션을 켜고 끌 때 정도이지 싶다. 살다가 병원이나 법원, 경찰서, 주민센터 같은 델 들르는 빈도와 비슷한 격이다.

옛날에는 컴퓨터를 켠 직후에 숫자가 쫘르륵 올라가면서 주 메모리 테스트를 하는 게 관행이었는데 그 광경도 참 오래 전에 사라졌다. 램의 용량이 수백 MB 수준으로 넘어간 시기, 대략 21세기 초쯤부터 없어진 것 같다. 글쎄, 카운트만 안 보여줄 뿐, 내부적으로 여전히 테스트는 하는 걸 수도 있음.

그리고 요즘 컴퓨터는 바이오스 셋업 화면도 텍스트가 아닌 그래픽 모드로 바뀌었고 마우스가 지원된다. 저기는 한글화의 영원한 불모지라고 여겨졌는데 이젠 그것도 아니다. 마소처럼 11172자 완성형 글립을 다 때려박은 게 아니라 이야기체 같은 8*4*4 조합형 비트맵 글꼴을 쓴 것도 있어 더욱 반갑다.

바이오스 차원에서 하드디스크에 predefined type이 40몇 가지 정도 있던 시절도 있었는데.. 안 변하는 것 같아도 이 바닥도 하드웨어의 발전을 따라서 많이 변하고 있다.
그나저나 애플 제조 컴퓨터들은 바이오스 계층도 자체 개발인 거겠지? (켠 직후에 흰 화면에 빵~~! 소리, 그리고 alt 눌러서 부트캠프 동작..)

3. 글꼴

수 년 전부터 개인적으로 '감지'는 했던 현상인데, 어떤 컴퓨터는 글꼴 대화상자를 열어 보면 황당하게도 Times New Roman이나 Courier New 같은 필수 기본 글꼴이 목록에서 빠져 있고 선택 가능하지 않았다. 물론 그 컴퓨터에 실제로는 해당 글꼴이 멀쩡하게 잘만 설치돼 있다.
게다가 더 황당하게도 MS Word 같은 프로그램에서는 그 글꼴을 선택할 수 있었고 메모장이나 워드패드에서만 안 나왔다. 내 경험상 이건 컴퓨터마다 케바케로 발생하는 듯하고 Windows 7 이상 2010년대부터 종종 보였다.

처음엔 글꼴 목록에 영향을 끼치는 악성 코드가 있기라도 한지 의심을 했다. 하지만 알고 보니 이 현상에 대한 해답이 따로 있었다.
"제어판-글꼴-글꼴 설정"으로 들어가서 "언어 설정에 따라 글꼴 숨기기" 옵션을 끄면 사라졌던 Times, Courier 같은 글꼴을 다시 선택할 수 있다. (Designed for your language settings)

Windows 7부터 등장한 옵션은 맞아 보인다. 그런데 멀쩡한 글꼴을 선택할 수 없게 만드는 옵션은 대관절 도대체 왜 도입됐는지 모르겠다. 그런 옵션을 굳이 넣을 거면 글꼴 선택 대화상자 내부에다가 넣거나 show all 같은 버튼이라도 넣어야지 왜 제어판 깊숙한 곳에다가 짱박아 놓았는지도 알 길이 없다.

4. PNG

한때 GIF라는 그림 파일 포맷이 있어서 웹에서 정말 많이 쓰였다. 압축률 좋고 투명색과 애니메이션, progressive 렌더링 같은 독보적인 장점 기능이 많았다. 그러나 GIF는 내부의 압축 알고리즘에 특허가 걸려 있어서 아무나 활용하기가 곤란했다.

물론 이미 만들어진 그림 파일을 보기만 하는 사용자 입장에서는 제약이 걸리는 게 전혀 없고, GIF 파일을 생성하거나 디코딩하는 프로그램을 상업용 제품에다 직접 얹는 제조사의 입장에서 로얄티 같은 게 들었던 것 같다. 휴대용 MP3이나 WMA 재생기를 만들 때처럼 말이다. 전자는 프라운호퍼 연구소에, 후자는 마소에 특허든 저작권이든 뭐든 걸려 있다.

그래도 이 특허는 저작권 자체의 보장 기간(70년)보다는 기간이 훨씬 짧았던 모양이다. 2005년경에 특허가 풀리긴 했다. 그러나 gif는 트루컬러를 지원하지 못한 채 256색에서 발전이 멈춰 버렸기 때문에, 오늘날은 대체제인 PNG에 밀려 서서히 사장되는 중이다. 웹에서 사진용 손실 압축은 JPG가, 그 밖의 범용적인 비손실 이미지는 PNG가 시장을 나란히 양분하는 중이다.

PNG는 GIF보다 압축률이 더 좋고 트루컬러도 지원하며, 단순 color key 기반 투명보다 더 발전한 알파채널도 지원한다. 심지어 고화질 아이콘을 저장하는 컨테이너로도 이용되고 있다.
그러니 GIF의 대체물이 되기에 손색이 없다. 다만, 알파 채널은 1990년대 PNG의 첫 버전과 동시에 등장한 게 아니라 나중에 추가된 확장 규격이기라도 한지, 제대로 지원하는 프로그램이 여전히 적어서 아쉽다.

또한 PNG도 애니메이션 기능은 없다. APNG라는 규격이 있기는 하지만 웹 표준이 아니기 때문에 파이어폭스 같은 극소수의 브라우저 말고는 지원하지 않는다. 플래시가 없어지고 브라우저 자체의 동영상 코덱 규격조차 표준화가 논의되고 있는 와중에 애니메이션용 이미지도 더 늦기 전에 표준이 마련되고 모든 브라우저들이 지원해 줘야 하지 않나 생각이 든다. 하긴 옛날에는 동영상도 코덱 파편화가 무진장 심해서 '통합 코덱' 이러면서 혼란이 말도 아니긴 했었다.

5. high DPI 관련

Windows에서 high DPI 지원 정책은 한번 만들어 놓은 걸로 끝이 아니고 버전을 거듭할수록 마개조를 거듭하고 있다. 심지어 같은 Windows 10에서도 새 업데이트에서는 새 기능이 들어갔다.

8.1에서인가 그때부터 per-monitor high DPI이라는 게 도입된 걸로도 모자라서 이제는 아예 스레드별로 high DPI-aware 여부를 지정하고 그걸 on-the-fly로 변경하는 기능까지 추가됐다.
DPI의 변경은 너무 파격적인 변화여서 원래는 재부팅이 필요했으며, Windows Vista 시절에는 믿어지지 않지만 관리자 권한까지 필요하던 작업이었다. 그리고 어차피 제대로 대비가 돼 있는 유연한 프로그램도 매우 드물기 때문에 변경이 권장되지 않기도 했다.

그랬는데 그게 그래픽 카드의 성능 발달 덕분에 실시간 변경이 가능한 기능으로 서서히 바뀌어 간다. 그래도 마소는 레거시 호환성에도 목숨을 거는 곳이니, DPI 변화의 대비가 안 돼 있는 레거시 프로그램은 그냥 가상화 샌드박스빨로 통째로 속이고 말이다. Windows의 역사상 동일 기능이 위상이 이렇게 드라마틱하게 변한 다른 예는 찾기 어려울 것이다.
원래 화면 해상도나 색깔수를 바꾸는 것조차 먼 옛날에 Windows 3.x 시절에는 재부팅이 필요한 작업이었지만 9x/NT부터는 실시간 변경이 가능해졌지 않던가? DPI 변경도 그렇게 바뀌었다.

그도 그럴 것이, high DPI라는 게 원래는 시력 나쁜 사람을 위한 장애인 접근성에 가까운 잉여 기능이었다. 하지만 21세기에 모니터의 해상도가 급격히 올라가면서 이건 모든 사람에게 필요한 편의 기능이 됐다.

이 점에서 high DPI는 마치 자동차의 자동 변속기와도 비슷한 구석이 있다. 원래 자동 변속기 전용 면허는 왼발용 페달, 오른손용 다기능 스위치, 시청각 장애인용 볼록 거울처럼 장애인의 운전을 위한 여러 면허 조건 중 하나였다. 자동 변속기가 운전하기가 훨씬 더 쉬우니 장애인에게도 더 유리하니까 말이다. 그랬는데 자동 변속기가 워낙 대중화되고 나니 자동 전용 면허만은 1997년부터 일반인도 취득 가능하게 바뀐 것이다.

원래 화면 확대 배율이 기본값인 동시에 최소값일 때의 DPI 값은 96이었다. 이건 사실상 하드코딩된 채 쓰여 온 값인데, 언제부턴가 Windows SDK 헤더 파일을 보니 요게 USER_DEFAULT_SCREEN_DPI 라는 상수 명칭으로 추가되었다. 마치 마우스 휠의 기준값인 WHEEL_DELTA (120)과 성격이 비슷해 보이는데, 아무튼 GetDeviceCaps(hDC, LOGPIXELSX)의 리턴값과 저 96의 비율을 계산하면 확대 배율을 얻을 수 있다.

그런데 Windows가 존재하는 한 LOGPIXELSX와 LOGPIXELSY의 값이 서로 달라질 일은 설마 없겠지..?
모니터가 일부러 종횡비가 더 큰 와이드 화면으로(4:3 → 16:9) 바뀐 와중에, 논리적인 화면 종횡비를 또 보정해야 하는 건 옛날 CGA 640*200이나 허큘리스 720*348 해상도 시절 이래로 이제 없으리라 여겨진다.

옛날에는 멀티 모니터조차 예견을 못 하고 WM_CONTEXTMENU 메시지에서 마우스 클릭이 아닌 키보드 글쇠는 x, y 좌표가 모두 -1인 것으로 구분하게 스펙을 설계한 적이 있었는데.. 그때와 지금은 참 격세지감이다.
또한, 해상도 차이가 많이 나는 모니터를 둘 이상 연결해서 사용할 때를 대비해서, 이제는 두 모니터가 DPI 설정이 서로 다른 것까지 다 지원해야 한다. 그러니 high DPI를 제대로 지원하는 일이 더욱 복잡해진 것이다.

6. 네트워크가 안 될 때

집에서는 이런 현상이 없는데 회사에서는 가끔씩 멀쩡히 랜선이 꽂혀 있는데도 유선 인터넷이 안 되는 경우가 있다. 이때는 ipconfig /renew를 해 주면 문제가 해결되는 편이다.
때로는 /release도 해야 하고, 한번은 '설정'(제어판 말고)으로 들어가서 네트워크 관련 메뉴 맨 아래의 '전면 초기화'+재부팅까지 한 뒤에야 문제가 해결된 적이 있었다. 그 당시에 무엇이 정확하게 문제였는지 나로서는 알 길이 없지만, 아마 공유기 쪽 문제인 듯하다.

7. USB 메모리 관련

USB 메모리를 꽂아 쓰다 보면.. 분명히 작업을 마쳤고 관련 프로그램들을 다 종료한 뒤, 메모리를 빼려고 하는데 안전하게 분리가 안 된다고 운영체제가 꼬장을 부려서 난감해지는 경우가 있다.
Windows 2000 시절에만 해도 USB 메모리를 무단으로 뽑으면 경고 메시지가 나왔지만, 그게 그렇게까지 위험하지는 않고 괜히 사용자를 불안하게 만들 필요는 없다고 판단되었는지 XP와 그 이후부터는 경고 메시지가 사라졌다. 그러나 그렇다고 해서 무단 분리가 전혀 위험하지 않다는 얘기는 아니다.

USB 메모리를 분리하는 명령은 시스템 트레이에만 있는 게 아니라 의외로 해당 드라이브의 셸 우클릭 메뉴에도 존재한다. 마치 CD롬 드라이브의 우클릭 메뉴에 '디스크 꺼내기' 명령이 있는 것처럼 USB 메모리 드라이브도 우클릭하면 'eject'가 있으며, 이 명령을 이용해서 분리하면 트레이 메뉴 명령보다 성공률도 더 높다고 그런다.

경험상 macOS는 지금까지 쓰면서 USB 메모리 제거가 바로 안 되는 경우를 거의 못 본 거 같다.
그런데 pkg 파일을 열어서 설치하는데.. USB 메모리의 것을 바로 여니까.. insert the "(null)" disc to continue installation 이러면서 설치가 제대로 되지 않았다.
저건 %s 포맷 문자열에다가 null 포인터를 주기라도 했는지 메시지의 형태도 비정상일 뿐만 아니라, 배포 패키지 파일이 깨지고 문제가 있을 때에나 나타날 법한 메시지이다.

하지만 파일이 실제로 깨진 건 전혀 아니었으며, pkg 파일을 하드디스크에다 복사한 뒤에 설치하니까 아무 문제 없이 됐다.
왜 저런 현상이 있는지는 잘 모르겠다.

8. USB가 없던 시절의 컴퓨터 단자

그러고 보니 먼 옛날에.. USB 포트가 없던 시절에는 컴퓨터에 주변기기를 인식시키는 용도로 직렬 포트와 병렬 포트라는 게 있었다.
정확하게 뭐가 직렬 내지 병렬이어서 이런 명칭이 붙었고 서로 어떤 장단점이 있는지 잘 모르겠다. 라디오에 AM과 FM, 인터넷 프로토콜에 TCP와 UDP처럼 일장일단이 있는 관계가 아닌가 생각된다.

직렬 포트는 COMn 이런 이름이 붙어서 주로 마우스나 모뎀이 연결되었다. 그리고 병렬 포트는 LPTn 이런 이름과 함께 프린터나 스캐너 같은 기기가 연결되었으며, 과거에 쓰이던 하드웨어 방식 불법 복사 방지 장치 '락'도 대체로 병렬 포트에다 꽂는 형태였던 것 같다.

으음.. 그럼 외장 하드는 어디에다 꽂았지? 옛날에 하드 디스크끼리 꽂아서 데이터를 복사하는 건 정말 아무나 할 수 있는 일이 아니었다.;;
꽂고 나서는 바이오스 설정을 들어가서 이게 무슨 기기인지 설정을 수동으로 해 줘야 했다. plug and play 그런 건 없었다. 코덱이 너무 난무해서 동영상 보는 데 애로사항이 꽃폈고, 유니코드가 없어서 문자 인코딩이 어느 장단에 맞춰 춤을 춰야 할지 알 수 없던 그런 열악하던 시절의 추억이다.

Posted by 사무엘

본인은 평소에는 15년 넘게 개발하고 있는 날개셋 한글 입력기의 개발에 대부분의 역량이 집중되기 때문에 타 유명 프로그래머 고수들에 비해 타 플랫폼· 언어· 최신 프로그래밍 기술에 대한 개인적인 관심은 덜한 편이다. 뭐, 자주 언급을 안 할 뿐이지 직장에서는 아무래도 갑님이 시키는 대로 해야 하니, 무엇이건 업무와 생존에 필요한 최소한의 맛보기 정도는 한다. 다만 그런 생소한 분야는 본인이 특장점이 없이 그냥 여느 평범한 프로그래머 A, B의 역량과 다를 바 없다.

먼 옛날에 Windows API와 MFC, Visual C++를 처음으로 공부할 때 그러했고, macOS나 안드로이드 개발을 처음으로 익힐 때도 마찬가지이다. 코드와 리소스가 어떤 방식으로 연결되는지 감을 잡는 게 참 어려웠다. 이건 그야말로 프로그래밍 언어뿐만 아니라 각 플랫폼별 바이너리 실행 파일(DLL/EXE)의 구조, 개발툴의 기능에 대한 총체적인 이해가 필요한 부분이니까 말이다.

그래도 리소스(대표적으로 대화상자/화면 레이아웃)의 기술을 위해 XML을 쓰는 요즘 플랫폼에 비해, Win32 API의 rc 파일은 정말 구닥다리이구나 싶은 생각이 든다. 뭐, resource.h와 R.java처럼 개념상 일말의 공통점이 발견되는 것도 있다(개발툴이 자동으로 생성해 주는 리소스 ID 리스트).

또한 안드로이드의 경우, 굉장한 뒷북이긴 하다만 Eclair니 Froyo니 하던 시절과 비교했을 때 개발 환경이 몇 년 사이에 정말 엄청나게 달라져 있었다. 여전히 이클립스를 쓰는가 했더니 Android Studio라고 전용 개발툴로 진작에 갈아탔으며, 무엇보다 에뮬레이터도 x86과 arm이라는 엄청난 CPU 구조 차이를 어떻게 극복했는지 속도가 꽤 빨라졌다.
그도 그럴 것이 그 구글 내부에서 안드로이드 OS에만 달라붙어 있는 세계구급 날고 기는 프로그래머 엔지니어들이 도대체 얼마나 되며, 이들이 매일 생산하는 코드의 양은 또 얼마나 될까?

2010년대 이후에나 등장한 IDE가 copyright이 왜 엄청 옛날인 2000부터 시작하는지 궁금해서 검색을 해 봤더니.. 이건 그 옛날부터 개발되어 온 타 회사의 IDE를(이클립스 말고) Google이 인수해서 자체적으로 발전시킨 것이어서 그렇다고 한다. 으음..

이럴 때마다 늘 드는 생각인데, 새로운 문물이나 지식을 아주 빨리빨리 잘 익히고 남에게 가르치는 것까지 가능할 정도로 머리가 좋은 사람들이 개인적으로 굉장히 부럽다. 난 굳이 말하자면 애초에 남이 안 하는 짓을 골라서 하는 일에 일가견이 있다. 그래서 정보 올림피아드도 공모 부문에서만 입상하고, 코딩과 논문으로 그럭저럭 지금까지 지내 왔다.
그게 아니라 남과 똑같은 조건에서 뭔가를 빨리 달달 외우고 응용하는 능력이라면 본인은 남들 평균보다 못하면 못하지 결코 뛰어나지는 않다.

컴퓨터 쪽에 우글거리는 수많은 고수 괴수들 중에.. 김 상형 님이라고 한때 winapi.co.kr 이라는 사이트를 운영했고 지금은 '소프트웨어 공학'을 일본어 스타일로 축약한 '소엔'이라는 사이트로 여러 유용한 프로그램 개발 정보를 무료로 공유 중인 대인배가 계신다.
사이트 이름에서 유추할 수 있듯 한때 이분의 전문 분야는 Windows API였다. 텍스트 에디터를 그냥 C++만으로 혼자서 처음부터 끝까지 다 만들었고, 그 테크닉을 소스까지 통째로 책을 출간한 바 있다..;;

한 분야의 기술만 통달하기에도 벅찬데 이분은 안드로이드, HTML, 자바스크립트 등 온갖 분야를 다 탐독해서 책을 쓰고 학원 강사로 뛰고 있다.
그냥 위에서 내려오는 회사 업무나 감당하기 위해서 여러 기술들을 찔끔찔끔 서바이벌 수준으로 익히는 게 아니다. 그야말로 남을 가르치고 책을 쓸 정도로 전문가가 되기 위해서 혼자서 도대체 공부를 어떤 방식으로 얼마나 한 걸까? 비결이 궁금해지지 않을 수 없다.

이렇게 강의와 저술만으로 먹고 사는 데 지장 없는 분들은 굳이 회사 들어가서 조직에 매일 필요가 없다. 물론 프리랜서는 월급쟁이보다야 소득이 훨씬 불안정하고 복불복이 심하다. 보통은 자기 친구들에게도 "걍 회사에서 월급 받으며 지내는 게 짱이야, 아무리 엿같은 동료나 상사가 있더라도 어지간해서는 거기서 절대로 뛰쳐나올 생각 마라" 이렇게 권유를 할 정도라고는 하지만..
이것도 자기 하기 나름이다. 엄청난 능력자라면 을임에도 불구하고 여러 기업들을 상대로 갑질을 하면서 자유롭고 편하게 일을 할 수도 있을 것이다.

그리고 컴퓨터가 나왔으니 영어도 빠질 수 없다.
지금보다 자료 접근성이 훨씬 열악했던 옛날에 독학으로 이를 악물고 영어를 마스터해서 198, 90년대에 이미 유명 영어 교재의 저자로 등극한 사람들이 참 대단하다는 생각이 든다.
최 은경 어린이 영어, 오 성식 생활 영어/pops English, 김 인환, 정 철 ... 그리고 최근에는 Arrow English로 유명한 최 재봉 이런 분들.

난 무슨 영문과 교수나 영어 교사, CNN 리포터-_-;; 이런 거 지향하는 게 아닌 이상, 국내에서 영어 때문에 스트레스 받을 일은 없는.. "반도 토박이치고는 뭐 그럭저럭 하네" 딱 그 정도까지만 영어가 된다. 자막 없이 영화를 다 알아듣거나, 토익 만점 이런 경지는 아니다. 그리고 그마저도 나이는 자꾸 먹고 있는데 영어를 당장 쓸 일은 없으니 감이 점점 쇠퇴-_-하는 중이다.
도무지 들리지가 않는 것, 그리고 아무리 머리를 짜내도 독해 속도를 도저히 더 올릴 수 없는 건 그냥 내 머리의 한계인 것 같다.

영어를 잘하려면 뭐 영어식 사고방식과 어순 감각을 익혀야 되고 무슨 발상의 전환을 해야 하고.. 이런 것들은 그냥 기초가 없고 첫 단추부터 완전 잘못 끼운 생짜 영어 포기자한테는 꽤 유효한 조언일지 모른다. 영어 점수 2~30점을 6~70점으로 올리는 데는 도움이 될 것이다.

하지만 90점을 95점으로 올리는 건 무리임. 저런 기초적인 문법과 어순 감각은 이미 다 갖춰져 있고, 거기서 상위권에서 최상위권으로 가려면 그냥 닥치고 영어라는 빅데이터에 수시로 많이 노출돼서 감을 유지하는 것밖에 답이 없다. 외국 어학 연수는 개나 소나 아무나 가는 게 아니라 딱 이 정도 기초가 갖춰진 애들이 가야지 효과가 높아진다.

그런데, 저런 여러 영어 전문가들이 공통으로 말하는 영어 마스터 비결은.. 학창 시절에 영어 교과서 텍스트들을 몽땅 통째로 암송· 암기했다는 것이다. 사실 인간의 언어에는 굉장히 무작위하고 arbitrary하고, 그냥 문맥이 곧 용례를 결정하는 그런 정보가 많다. 암송· 암기는 학습자에게 괴로운 과정이긴 하지만 그래도 그거 효력은 확실한가 보다.
나도 테이큰의 전화 통화 대사 40초 분량은 통째로 줄줄 외우고 있긴 하다만.. -_- I don't know who you are ... I will find you. And I will kill you. 같은 거.. 그런데 영어를 잘하려면 그런 거 암기를 더 많이 해야 한다.

일본은 개개의 국민들이 다 영어를 못 하더라도 국가 차원에서 번역을 엄청 많이 잘 해 놨다고 그런다. 하지만 우리나라는 모든 국민들이 다 영어를 잘하는 것도 아니고, 번역을 깔끔하게 잘한 것도 아니니 뭔가 문제가 있어 보인다.

끝으로, 어려운 과목의 끝판왕인 수학이 있다. 수학은 영어와 달리 유행을 별로 안 탄다. 한편으로는 노력한 만큼 그대로 결과가 나오는 참 정직한 과목 같으면서도, 한편으로는 타고난 머리 지능빨을 타니 불공평한 면모가 느껴지기도 하는 과목이다.
수학에는 '정석' 책 하나로 그야말로 억만장자가 되고 우리나라에서 최고로 성공한 사람이 있다. 물론 이분 역시 머리가 공부벌레 괴수급이었으며, 굳이 책 안 쓰고 학원과 과외 강사료만으로도 그 옛날에, 겨우 20대 나이로도 왕창 잘나갔을 정도로.. 비범했다.

그런 정석의 저자가 말하는 수학 잘하는 비결은.. 수학은 처음에 느리고 시간이 걸리더라도 직접 계산해 보고 손으로 일일이 쓰면서 감을 익혀야 한다는 것이다. 그런 감이 생겨 있지 않은 사람이 눈으로만 보고 넘어가서는, 그리고 덥석 해설과 풀이를 봐서는 진짜배기 수학 실력이 절대 늘 수 없다고.. 참 너무 원론적이고 당연한 조언을 한다. 그건 게임으로 치면 그냥 무한 맵에 치트키 쓰는 것이나 마찬가지니까.

그리고 저 말을 프로그래밍에다가 적용하자면.. 일일이 직접 코딩해 보고 돌려 봐야 실력이 는다는 말과 일맥상통한다. 그 점은 본인 역시 적극 동의한다.
아무 감도 없는 사람이라면 노가다 코딩이라도 해 봐야 된다. 그런 경험을 많이 해 봐야 노가다 코딩을 왜 '노가다'라고 부르는지 그것부터 좀 알게 된다.

개발자, 프로그래머로 먹고 살려면 솔까말 트리 구조 순회 같은 재귀호출을 스택 배열로 직접 구현하기, 포인터 조작으로 연결 리스트의 원소 배열을 역순으로 바꿔치기 정도는 머릿속에서 로직이 어느 정도 암산이 돼야 하고, 굳이 컴퓨터가 없이 화이트보드 앞에서도 의사코드를 쓱쓱 적을 수 있어야 하지 않는가?

사실, 유수의 IT 업체들이 학-석사 급의 엔지니어를 뽑을 때 코딩 면접도 딱 이 정도 수준의 난이도가 나온다. 무슨 "B+ 트리를 구현하시오, 동영상 압축 알고리즘의 모든 과정을 설명하시오"가 아니다. 그리고 크고 유명하고 재정 넉넉한 기업일수록 당장 현업에서 쓰이는 HTML5니 자바스크립트니 언어 문법 지식보다는 저런 미래의 잠재성과 응용력, 새로운 기술을 더 본다. 능력 함수에서 현재의 f(x) 값보다 도함수 f'(x)를 말이다.

다시 말해, 최신 자바스크립트나 HTML5 API 지식이 필요하지 않으니까 당장 그런 걸 모르는 사람도 OK 하고 뽑는 게 아니다.
오히려 그 반대로.. 하나도 모르는 상태로 입사했더라도 현업에서 그런 것쯤은 30분 만에 즉석에서 공부하고 숙달될 능력이 있으니까 뽑는다는 뜻이다. 요구 사항이 훨씬 더 고차원적이다.

컴공과 수학의 관계는 어떨까? 물론 완벽하게 동치는 아니다. 기하 알고리즘을 구현하고 있는데 삼각형 넓이나 세 점의 방향을 구하는 공식, 3차원 공간에서 두 벡터에 대한 나머지 기저를 구하는 세부적인 외적 공식 같은 거야 당연히 까먹을 수 있다. 하지만 기억이 안 나면 당장 검색이라도 할 수 있으면 아무 문제될 것 없다.

단지, 수학은 그렇게 문제를 쓱쓱 풀어 나갔던 경험, 단 한 가지 경우라도 놓쳐서는 안 되고 논리적으로 완벽해야 한다는 그 관념이 나중에 프로그램을 짜는 데 낯설지 않은 정신적 자산으로 작용할 수 있다고 본다.
물론 그런 관념이 오로지 반드시 학창 시절의 수학 문제 풀이를 통해서만 형성될 수 있다는 건 아니겠지만 말이다. 기본적인 머리가 있고 필요를 느끼면 결국은 나중에 다른 경로를 통해서라도 적응은 하게 돼 있다.

어휴.. 나도 말은 이렇게 써 놨지만.. 당장 어떻게 풀어야 할지 모르는 어려운 문제를 대면하면 이게 도대체 지금까지 수업 시간에 배웠던 기본 수학 공식이나 법칙과 무슨 관계가 있고 무엇부터 적용해야 할지 막막한 게 많다. 맨날 이런 기억과 경험만 쌓이다 보면 그 누구라도 수학이 싫어질 수밖에 없고 수학을 포기할 수밖에 없을 것이다.. -_-;; 세상에는 나랑 나이 차이도 별로 안 나던 시절에 그런 문제를 생각해 내고 '만든' 사람도 있구만.. 참 자괴감이 든다~!!

Posted by 사무엘

컴퓨터 프로그램이 뻗는 방식을 분류하면 크게 다음과 같이 정리된다.

1. 아무 뒤끝 없이 그냥 뻗음(crash)

제일 단순하고 흔한 형태이다. 코딩을 잘못해서 잘못된 메모리에 접근하다가 튕긴 것이다. 그 예로는 null 포인터(null로부터 유도된 인근의 잘못된 주소 포함), 초기화되지 않은 포인터, 초기화되지 않은 배열 첨자 인덱스, 이미 해제된 메모리 포인터 등 참 다양하다.
혹은 애초에 메모리를 할당하는데 할당량에 엉뚱한 값이 들어와서 뻗은 것일 수도 있다. 가령, 음수만치 할당은 저 문맥에서는 대체로 부호 없는 정수로 바뀌면서 도저히 감당 불가능한 엄청난 양의 메모리 요청으로 바뀌기 때문이다.

2. CPU 사용 없는 무한루프

단독으로 돌아가는 프로그램이 제발로 이렇게 되는 경우는 잘 없다. 이건 스레드 내지 프로세스 간에 서로 아귀가 안 맞는 상호 대기로 인해 deadlock에 걸려서 마취에서 못 깨어난 상황이다. 그러니 엄밀히 말해 무한루프보다는 무한대기에 더 가깝겠다.
굳이 커널 오브젝트를 직접 취급하지 않고 윈도우 메시지를 주고받다가도 이렇게 될 수 있다. 가령, 스레드 A가 타 프로세스/스레드 소속의 윈도우 B에다가 SendMessage를 해서 응답을 기다리고 있는 중인데, B는 또 스레드 A가 생성한 윈도우에다가 SendMessage를 했을 때 말이다. 요 데드락을 해소하려고 ReplyMessage라는 함수가 있다.

3. CPU 쳐묵과 함께 무한루프

종료 조건을 잘못 명시하는 바람에 loop에서 빠져나오지 못하는 경우이다. 부호 없는 정수형으로 변수를 선언해 놓고는 while(a>=0) a--; 이런 식으로 코딩을 해서 무한루프에 빠지는 경우도 있다. 얘는 그래도 다행히 메모리 관련 문제는 없는 상황이다.

4. stack overflow와 함께 뻗음

이건 단순 뺑뺑이가 아니라 재귀호출을 종료하지 못하고 비정상적으로 반복하다 이 지경이 된 것으로, 컴에 메모리가 무한하다면 3번 같은 무한루프가 됐을 상황이다. 하지만 현실에서는 물리적인 자원의 한계가 있고, 또 컴이 취급 가능한 메모리 주소 자릿수 자체도 무한하지 않기 때문에 언젠가는 뻗을 수밖에 없다.

재귀호출도 반드시 A-A-A-A-A... 이렇게 단일 함수만 쌓이는 게 아니라 마치 유리수 순환소수처럼 여러 함수 호출이 주기적으로 쌓이는 경우도 있다.
스택은 다음에서 다룰 heap 메모리와는 달리, 그래도 그 정의상 할당의 역순으로 회수되고, 회수가 반드시 된다는 보장은 있다.

5. 메모리 쳐묵과 함께 뻗음

이건 heap memory의 leak을 견디다 못하고 프로그램이 뻗은 것이다. loop 안에서 계속해서 leak이 발생하면 꽤 골치아프다. 또한, 금방 발견되는 leak은 그나마 다행이지, 프로그램을 몇 주, 몇 달째 돌리다가 뒤늦게 발견되는 것은 더 답이 없고 잡기 어렵다. 프로그램이 뻗은 지점이 실제로 문제가 있는 지점과는 전혀 관계 없는 곳이기 때문이다. 뭔가 컴파일 에러와 링크 에러의 차이와도 비슷한 것 같다.

요약하면, 메모리 쪽 문제는 가능한 한 안 마주치는 게 낫고, 마주치더라도 프로그램이 곧장 뻗어 주는 게 디버깅에 유리하다. 1과 5는 포인터를 대놓고 취급하지 않는 C/C++ 이외의 언어에서는 프로그래머가 직접 볼 일이 드물다.
요즘은 그래도 디바이스 드라이버 급이 아닌 평범한 양민 프로그램이라면 메모리 문제로 뻗는 경우 전적으로 혼자만 뻗지, 컴퓨터 전체를 다운시키는 일은 없으니 세상 참 좋아졌다. 이게 다 가상 메모리와 보호 모드 덕분이다.

Posted by 사무엘

1. 트리플

• 저그 해처리 레어 하이브 : 학사 석사 박사
• 워드 엑셀 파워포인트 : 서울 지하철 1호선 2호선 3호선 (힌트: 색깔의 유사성)
• 크레용-크레파스-파스텔 : 짜장면-짜파게티-스파게티
• 레코드 SP EP LP : 그래픽 카드 CGA EGA VGA =_=;;

세상에는 3개로 이뤄진 진영이 속성이 서로 다 동일하거나 제각기 다 다른 경우가 있다.
스타크래프트의 플토, 테란, 저그가 좋은 예이다. 미네랄과 가스, 서플라이를 사용하며 기본적인 공방 업그레이드가 3단계씩 있는 건 공통이지만, 건물을 짓는 방식이나 각종 스킬 같은 건 전부 제각기 다르다. 두 종족은 완전 공통인데 한 종족만 다른 경우는... 일단 없다.

요런 체계를 모델링한 세트(Set)라는 아주 재미있는 머리 싸움 보드 게임도 있다. 4가지 속성(색깔, 도형 개수, 채움 패턴, 도형 모양)이 전부 같거나 전부 다른 카드 트리플을 빨리 찾는 게 목적이다. n개의 카드가 있을 때 세트가 하나라도 존재할 확률 내지 전혀 존재하지 않을 확률도 구할 수 있을 텐데 내 수학 지식으로는 모르겠다.

필기 내지 그리기 도구로서 색연필-크레용-크레파스-파스텔-콩테로 갈수록 특성이 어떻게 달라지나 모르겠다. 파스텔은 그냥 딱딱한 분필 같고, 크레파스는 왁스가 들어가서 그런지 좀 끈적거렸던 것 같다.
콩테나 목탄 같은 건 본 적 없다. 목탄화는 <플란다스의 개>의 주인공이 화가 지망생이라 쓰던 물건이라는 것 정도만 알고 있다.

2. 트윈

• 지하철역 중에서 종로3가와 종로5가는 영락없이 삼겹살과 오겹살을 떠올리게 한다. -_-
• 농사에 비닐하우스가 있다면, 야구에는 돔구장이 있는 듯..
• 서울 강북에 청와대 뒷산인 북악산이 있다면 강남에는 국정원 뒷산인 대모산이 있다. 그리고 강북에 거대한 군사 시설인 용산 미군 기지가 있다면, 강남에는 국군정보사가 있어서 서초대로에 길이 끊겨 있고 gap이 존재한다. 서로 비슷한 심상이 느껴지는데, 얘들은 가까운 미래에 서울 밖으로 이전할 계획이 잡혀 있다.
• 스타크래프트에나 있어야 할 옵티컬 플레어의 실사판: 공중으로 쏘는 레이저 포인터(특히 녹색), 육지 자동차에는 HID 불법 개조.
  

크리스천들이 하나님에 대해서는 그분이 우리가 원하는 것을 주시는 게 아니라 우리에게 "필요한" 것, 우리에게 유익한 것을 주신다고 믿는다.
허나, 사람에 대해서는 능력껏 벌어서 "필요한" 만큼 가져가는 세상은 필연적으로 다같이 망하고 거지 되는 세상을 부른다.
이것이 신과 인간에 대해서 '필요'라는 개념이 작용하는 방식의 차이점이다. 이건 성악설이 성립하는 한 반박 불가능할 것이다.

그리고 한편, 컴퓨터와 관련해서는..

• 옛날에 컴퓨터를 다루던 사람들은 디스크의 배드 섹터를 걱정했지만 요즘 사람들은 모니터의 불량 화소를 신경 쓰는 듯하다.
• 옛날 사람들은 컴퓨터를 오래 쓰면 Windows 3.x 내지 9x의 리소스 퍼센티지가 줄어드는 걸 보고 바싹 긴장했지만, 요즘 사람들은 스마트폰의 배터리 퍼센티지가 줄어드는 걸 보고 바싹 긴장한다.

3. 부정적인 예

• C++ 템플릿의 문제(소스 코드가 노출된 채 모든 번역 단위에 매번 인클루드 돼야 함)를 해결하려고 고민했는데 기껏 나온 게 export
• 남북이 통일하랬더니 기껏 나온 게 고려연방제 (1국가 2체제.. 그냥 전쟁만 없는 반쯤 적화통일)
• ActiveX를 없애라고 하자 나온 게 EXE 프로그램

이들이 무슨 공통점이 있는지는 설명이 필요하지 않을 것이다. 본질적인 문제는 전혀 해결하지 않은 채 그냥 눈 가리고 아웅일 뿐이다.

4. 긍정적인 예

• 건축업계· 학계에서는 '철근 + 콘크리트'가 신이 건축· 재료공학계에 내린 천혜의 재료 궁합이라고 그런다. 열팽창 계수가 거의 같아서 혼합 가능하면서도 서로 장점을 부각시키고 단점은 보완하면서 최고의 건축 자재 역할을 하기 때문이다.
• 항공업계에서는 하필 여객기의 최적 순항 고도에 제트 기류라는 게 존재하는 게 기적적인 행운이라고 한다.
• 1970년대에 인류가 우주 개발을 하고 있을 때 마침 태양계 행성들이 가까이 일렬로 배열돼 있어서 보이저 2호는 단독으로 천왕성과 해왕성을 동시에 탐사하는 대박을 경험할 수 있었다. 이것도 못해도 백수십 년 만에 한 번 찾아오는 기회였다고 그런다.

이런 예가 더 있을지 궁금하다. 혹시 반도체를 만드는 데에도 무슨 천혜의 자연 광물 특성이 활용되는 게 있지 않을까?

5. 예상치 못한 대박

예전에 교통수단 관련 글을 쓰면서 한 번씩 언급한 적이 있는 내용이긴 하지만 복습 차원에서..

• 서울 지하철 9호선은 잠재적 수요를 인정받은 덕분에 서울 3기 지하철 중 거의 유일하게 얘 혼자만 노선 계획이 온전히 살아남아서 건설되고 개통되었다. 그런데 한편으로는 국가에서는 이거 만들어 봤자 지상의 올림픽대로를 달리는 자동차들의 적수가 못 될 것이고 공기수송 적자이면 어쩌나 지금의 입장에서는 참 쓸데없는 걱정을 했다. 그래서 전동차도 달랑 4량으로 편성하고, 최대한 메리트를 끌어올리려고 급행도 만들었다. 그랬는데, 실제로 뚜껑을 열어 보니 9호선은 초대박을 쳐서 최악의 가축수송 혼잡도를 보이는 노선이 됐다.
• 지난 1960년대 말, 보잉 사에서는 유럽에서 초음속 여객기 콩코드가 개발되는 걸 예의주시하면서 "이거 초음속 여객기가 대박을 치면 어쩌나" 생각을 했다. 그래서 자기들도 초음속기인 보잉 2707을 개발 준비만 하면서 간을 보는 한편으로, 이미 개발 중이던 보잉 747 아음속 여객기는 주류에서 밀려날 경우 화물기로 언제든지 개조 가능하게 만반의 대비를 해 놓았다. 그러나 뚜껑을 열어 보니 초음속기는 가성비가 심각하게 부족했고 오일 쇼크와도 맞물려 영 재미를 못 봤다. 그 대신 747은 대형 여객기로 수십 년간 엄청난 성공을 거뒀다.

6. 2단계 계층

컴퓨터 프로그램 내지 알고리즘을 보면 작업을 수행하는 양상이 명백하게 독립된 두 phase로 나뉘는 것이 있다.

• 힙 정렬: 정렬 알고리즘 중에는 얘가 꽤 독특하다. 배열을 기반으로 heap을 생성하는 단계와, 그 heap으로부터 최종적으로 정렬된 리스트를 하나씩 뽑아내는 단계로 나뉜다.
• 컴파일러: 소스 코드를 구문 분석을 해서 내부 representation으로 변환하는 프런트 엔드, 그리고 이를 토대로 최적화와 기계어 코드 생성을 하는 백 엔드로 단계가 분명하게 나뉜다.
• 일본어 IME: 일본 문자 자체를 입력하는 방식과, 그 일본어 문자열을 NLP 관점에서 분석해서 어절을 나누고 한자 변환 후보를 제시하는 것은 서로 완전히 별개의 단계이다. 그러니 전자와 후자를 분리해서 일부 파트만 서로 다른 알고리즘 내지 DB 제품으로 교체해서 사용할 수 있지 않나 싶다.

그리고 데이터 압축이 있다. 흔히 간과하기 쉬운데, 압축이라는 절차도 두 단계로 나뉜다. 먼저, 원소나열법을 간단한 조건제시법으로 바꿀 만한 규칙성, 반복 패턴을 찾아서 더 간결한 방식으로 표현 방식을 바꾸는 것이 전자이다. 전자를 수행하는 방법은 그야말로 무궁무진하며, 손실 압축과 비손실 압축도 이걸 수행하는 방식의 차이에 지나지 않는다. 압축된 데이터는 데이터 + 탈출문자 + 약어에 대한 번문 명령(expansion instruction) + 사전 참조 오프셋 같은 게 뒤죽박죽 섞여 있다.

그 다음으로, 이런 인코딩 결과를 정보 이론 관점에서 빈틈 없는 아주 compact한 형태로 물리적인 표현 방식을 바꿔서 최종 출력하는 것이 후자이다. 후자는 이론적인 압축률의 한계도 다 증명돼 있고 전자에 비해 더 발전할 게 별로 없는 상태이다.
압축 알고리즘이라 하면 이 둘을 싸잡아서 한데 일컫는 경향이 있으나, 이 두 단계는 엄연히 용도와 성격이 다르다. 가령, jpg 이미지 포맷의 경우 이산 코싸인 변환은 전자요, 결과를 허프만 코딩으로 출력하는 것은 후자에 대응한다.

요즘은 보기 힘든데 1990년대에 Windows Installer가 아직 없던 시절에는 마소에서는 확장자가 cab이던가? 독자적인 압축 파일 포맷을 써서 프로그램을 배포했다. 더 옛날에는 원본 디스크를 보면 설치되는 파일들이 확장자만 다 _xe, _ll 혹은 ex_, dl_ 이런 식으로 바뀌고 안에 내용은 어설프게 압축되어 있곤 했다. Lempel-Ziv 같은 알고리즘으로 압축되긴 했는데, 코딩 방식을 조밀화하는 '후처리'는 하지 않아서 가끔씩 원본 파일에 들어있는 문자열이 드문드문 보이곤 했다.

파일을 압축하면 기본적으로 전자 과정을 거쳐서 크기가 줄어드는데, 후처리까지 거치면서 크기가 좀 더 감소할 뿐만 아니라 이때 진짜 난수표 같은 뒤죽박죽 비트 나열로 바뀐다. 둘은 마치 사이다에서 (1) 단 맛을 내는 향신료와 (2) 탄산, 에어컨에서 (1) 온도를 낮추는 압축기와 (2) 송풍기하고 얼추 비슷한 관계가 아닌가 싶다.

7. 혈액형과 상속 개념

코딩 하니까 드는 생각인데..
중등학교 때 혈액형과 수혈 가능성에 대해 배울 때 우리는 객체지향 프로그래밍에서 말하는 상속이라는 개념을 어렴풋이 접했다고 볼 수 있을 듯하다. 수혈 가능성은 형변환 가능성이고.

O형이 베이스 클래스이고 A, B형은 O형으로부터 상속이며 AB는 A와 B 다중 상속이다.
A형과 B형이 O형을 가상 상속을 한 건지는 잘 모르겠다.
하지만 현실은 그렇게 매끄럽지가 않기 때문에 어지간해서는 반드시 같은 유형끼리만 수혈을 하지, A/B계열형에다가 O형 피를 수혈하고 AB형에다가 A나 B형 피를 수혈한다거나 하지는 않는다고 한다. 이런 얘기는 어렸을 때 과학 책이나 교과서에서 접하지 못했다.

아무쪼록 다중 상속은 포인터의 형변환이 이뤄질 때 오프셋 보정이 필요하게 하며, pointer-to-member도 포인터 하나 형태로 간단하게 구현할 수 없게 만드는 주범이다.
다중상속 받은 한 클래스의 포인터를 다른 상속 파생 클래스의 포인터로 바꾸는 건 굉장히 조심해서 해야 한다. 이럴 때 C-style cast는 reinterpret_cast와 개념적으로 다를 바 없어지기 때문에 반드시 static_cast를 써야 실수를 예방할 수 있다.
그러니 혈액형간 typecast도 가능한 한 안 하는 게 좋아 보인다. 아무래도 위험해 보인다.

Posted by 사무엘

C 언어는 가히 프로그래밍 언어계의 라틴어라 해도 과언이 아닌 대중적인 언어가 돼 있다. 얘는 알골(Algol), 그 다음으로 B라는 언어의 뒤를 이어 단순하게 C라고 명명되었으며 1972년에 만들어졌다. 이걸 보면 컴퓨터계에서 3.0 버전이 흥행 대박 친다는 법칙은 언어 분야에서도 유효한 것 같다.

C 언어의 고안자는 '데니스 리치'이다. 이 사람은 지난 2011년 가을에 마침 스티브 잡스와 거의 1주일 간격으로 나란히 작고했다(잡스가 먼저). 그래서 컴퓨터쟁이들 사이에서는 둘 중 덜 유명한 사람이 사실은 컴퓨터계에 훨씬 더 큰 공헌을 했다는 요지의 글을 올리곤 했다.

C는 기본적으로 컴파일 형태로 빌드되는 언어이며, 1990년대를 전후해서 16비트 도스 시절엔 볼랜드라는 회사에서 개발한 터보 C 컴파일러가 아주 대중적으로 쓰였다.
그러나 터보 C보다 이전에 IBM PC용으로 최초로 등장한 C 컴파일러는 Lattice C라고 다른 회사 제품이었다. 1982년인가 그렇다. 이게 그 먼 옛날에 타 플랫폼용으로 개발된 프로그램들을 도스용으로 포팅하는 데 중요한 선구자적 역할을 했다. 얘가 당대의 다른 후속 경쟁사 컴파일러들에 비해 코드 생성 성능도 좋았다고 한다.

사실은 Microsoft C도 Lattice C를 기반으로 개발되었다. 그러다가 1985년에 개발된 MS C 3.0부터 마소가 완전히 독자적인 컴파일러 개발 라인을 구축했다고 영문 위키백과를 보면 나온다. 브라우저에다 비유하자면 IE의 소스에서 모자이크의 소스를 완전히 떼어낸 것과 비슷한 격이겠다.

Windows의 경우 1.0은 처음에 파스칼로 개발되었으며, 이거 영향으로 실행 바이너리들을 들여다보면 export 심벌들의 명칭은 대소문자 구분이 없고 문자열도 앞에 길이가 기록된 형태로 저장되었다고 한다. 대소문자 구분이 없는 건 확실하게 본 기억이 있는 반면, 후자는 잘 모르겠다.

물론 초창기에도 파스칼이 아닌 C언어 기반의 Windows SDK가 있긴 했다. Windows 1.0 SDK의 경우 바로 저 초창기의 MS C 3.0까지는 아니고 4.0과 연계해서 동작했던 걸로 기억한다. 운영체제(?)의 개발과 컴파일러의 개발이 나름 병행되었던 셈이다. 그래도 뭐, 파스칼의 흔적이 어떤 형태로든 과거에 존재했기 때문에 PASCAL이라는 calling convention 명칭도 오늘날까지 legacy로 버젓이 전해지는 아닌가 싶다.

그러다 Lattice C는 1980년대 후반에 개발사가 타사에 인수되었으며 물건 역시 MS, Borland 같은 후발주자 대기업(?) 제품에 밀려서 역사 속으로 사라졌다. C를 제외하면 볼랜드는 파스칼을 민 반면, 마소는 빌 게이츠의 입김과 추억이 담긴 Basic을 밀었다. 베이직이 Quick-을 거쳤다가 나중에 폼 디자인 기능이 탑재된 Visual Basic이 되었다면, C 계열은 Quick-을 거쳤다가 C++ 언어에 MFC까지 탑재하여 Visual C++이라는 공룡으로 거듭났다. 물론, 그래도 VC에 지금과 같은 IDE의 프로토타입이라도 갖춰진 물건은 또 한참 뒤인 4.0 (1995)부터이다.

도스 시절에는 Turbo/Borland라는 브랜드로 볼랜드 컴파일러가 심지어 마소의 컴파일러조차도 따돌리며 리즈 시절을 구가했다. 1990년대 중반이 되면서 32비트 도스라는 틈새시장을 겨냥해서 Watcom, DJGPP 같은 제품이 꼽사리로 꼈을 뿐이며, 정작 마소와 볼랜드는 32비트 도스 플랫폼 지원은 상대적으로 미흡했다.

허나, Windows 95/NT가 널리 퍼지면서 주력 C/C++ 컴파일러는 Visual C++로 판도가 급격히 기울었다. Lotus 1-2-3이 하루아침에 급격히 밀리고 Excel이 천하를 평정했으며, 넷스케이프가 90년대 말에 정말 급격히 몰락한 뒤 IE 세상이 된 것처럼 말이다. 컴파일러는 브라우저처럼 무슨 끼워팔기 독점 같은 게 있지도 않았는데 어쩌다 상황이 바뀌었는지 모르겠다. (옛날엔 플랫폼 SDK와 함께 제공되던 공짜 컴파일러는 상용 Visual C++와 동급의 고성능 컴파일러가 아니었음)

자, 그럼 다음으로 C에 이어 C++도 언어와 컴파일러 역사를 회고해 보겠다. C++은 1970년대 말에 C with Classes라는 가칭으로 개발되었다가 1983년에 지금의 이름으로 첫 발표되었다. C++의 고안자는 덴마크 사람이다. 그리고 초기의 몇 년 동안(1980년대 중반) C++은 인지도가 안습했던 관계로 독자적인 컴파일러가 존재하지 않았다.

오늘날 C++의 위상과 지위를 생각하면 저런 시절이 존재했다는 게 믿어지지 않는다만, 그때는 C++ 코드를 C 코드로 변환해 주는 Cfront라는 전처리기 형태로 C++의 구현체가 명맥을 이었다. 말은 전처리기라고 했지만 소스 코드를 완전히 분석하고 변환하는 것이기 때문에 기술 수준은 엄연히 전처리기를 넘어 컴파일러의 front end급은 된다.

그러다가 C++ 직통 컴파일러가 등장한 것은 1980년대 말~1990년대 초이다. 메이저한 개발사인 볼랜드와 마소에서 C++ 컴파일러를 내놓은 것은 역시나 빨라도 1990년과 그 이후부터이지만, 1980년대 말에.. 그래픽 카드로 치면 VGA의 등장과 비슷한 시기에 C++ 직통 컴파일러를 내놓은 제조사도 있었다.
IBM PC/도스용으로는 Zortech C++가 그런 선구자 축에 든다. 딱 우리나라가 올림픽 하던 시절과 얼추 비슷하게 첫 작품이 나왔다.

Zortech C++은 훗날 1993년경에 Symantec C++ 이라고 브랜드 이름이 바뀌어서 6~7.x 버전까지 개발되었다. 도스와 OS/2, Windows (16/32비트)를 모두 지원하는데 역시나 볼랜드, 마소, 왓컴 같은 다른 브랜드에 밀려서 인지도는 그리 높지 못했던 듯하다.
본인은 먼 옛날에 어둠의 경로를 통해서 이 컴파일러 자체는 접한 적이 있다. Hello, world!만 출력하는 프로그램을 빌드해 봤는데 exe의 크기가 꽤 작게 나왔던 걸로 기억한다.

그리고 Zortech / Symantec C++ 컴파일러의 개발자는 Walter Bright이라고.. 프로그래밍 언어 연구와 컴파일러 개발에만 뼈를 묻은 유명한 아저씨이다. 원래 전공은 전산· 컴공도 아닌 기계공학인데 프로그래머로 전업 후, 컴공에서 최고로 어려운 분야 축에 드는 컴파일러를 곧장 파기 시작했다는 게 대단하다.
이 사람이 D 언어의 고안자이기도 하다는 걸 본인은 최근에 알게 됐다. D에 대해서는 개발자 개인이 아니라 Digital Mars라는 개발사의 이름만 알고 있었기 때문이다.

C++ 컴파일러를 개발하는 현업에 수십 년 종사했으니 그는 C++의 언어 구조와 빌드 과정에 존재하는 구조적인 비효율과 단점에 대해서 누구보다도 잘 알고 있을 것이다. 그러니 자신의 경험과 노하우를 집약해서 네이티브 코드 컴파일 언어이면서 C/C++의 단점을 보완한 새로운 언어를 직접 만드는 지경에 이르렀다. 하지만 D의 지지자· 사용자들이 어떻게든 똘똘 뭉쳐서 언어의 인지도를 끌어올리는 데 목숨을 걸어도 시원찮을 판에, 런타임 라이브러리가 Phobos와 Tango로 분열되고 커뮤니티가 폭파되는 큰 악재를 겪기도 한 모양이다.

거기에다 C++ 자체도 2010년대부터는 부스터를 단 듯이 언어와 라이브러리가 모두 하루가 다르게 미친 듯이 발전하는 중이다. 이게 과연 내가 알던 그 C++가 맞나 싶은 생각이 들 지경이며, 오죽했으면 같은 C++로도 이런 새로운 패러다임을 잔뜩 도입해서 코딩을 하는 걸 Modern C++이라는 비공식 명칭으로 따로 일컬을 정도이다. 이대로 가면 인클루드의 단점을 개선하는 import/패키지 기능까지 가까운 미래에 C++에 도입될 추세다. 그러니 "호환용 레거시가 너무 지저분하다"처럼 태생적으로 어쩔 수 없는 것 빼고는 단점들이 의외로 많이 해소되었다.

그걸로도 모자라서 다른 대기업이나 오픈소스 진영에서도 Rust처럼 네이티브 기반이면서 독특한 패러다임을 담고 있는 언어를 내놓고 있으니 D 역시 자신만의 메리트와 경쟁력을 확보하기 위해서는 갈 길이 아직 먼 것 같다.
C에서 파생형 언어 명칭을 만든 게 C++, C#뿐만 아니라 D라니 참 재미있다. C++뿐만 아니라 C#도 고안자가 덴마크 사람이라니 저 나라도 의외로 전산 강국인 듯하다.

(여담이지만 Walter Bright 아저씨는 컴파일러 개발자 겸 PL 연구자로 이름을 날리기 전인 1970년대부터 이미 Empire이라는 턴 기반 전략 시뮬 게임을 만들기도 했다. 워낙 너무 옛날이니 오늘날과 같은 컴퓨터에서 컬러 그래픽이 나오는 형태의 게임은 아니었겠지만, 아주 어린 시절부터 정말 비범한 분이었다는 건 확실해 보인다. 게다가 저 작품은 전략 시뮬 장르에서 맵의 전체 시야를 노출해 주지 않는 fog of war라는 개념을 첫 도입한 선구자이기도 하다고 한다.)

Walter Bright 말고, 또 볼랜드나 마소 계열도 아니면서 C++ 골수 덕후인 컴파일러 제조사가 하나 더 있다. 바로 Comeau. C++98이던가 03 시절에 그 악명 높은 템플릿 export 키워드를 유일하게 손수 다 구현한 이력도 있는 대단한 용자이다. 얘들 역시 1989년 초에 곧장 C++ 컴파일러를 내놓았으며, 그때부터 도스와 OS/2 등 다양한 플랫폼을 지원했는데, 거기 내부엔 또 어떤 출신과 배경을 가진 컴파일러/PL 괴수가 기업을 이끌고 있나 궁금해진다.

Comeau 컴파일러는 오늘날은 프런트 엔드로는 Edison Design Group의 제품을 사용하여 동작한다. 그럼 저 업체와는 어떤 관계인지 궁금하다. 그리고 프런트가 그런 관계이면 쟤들은 최적화와 타겟 코드 생성 같은 백 엔드 쪽에 차별화 요소가 있어야 할 텐데.. 백 엔드로는 아예 CPU 제조사라는 결정적인 텃새가 있는 인텔 컴파일러도 강세 아니던가? 그런 제품과 경쟁이 되려나 모르겠다.

이상. 이 글은 볼랜드나 마소 같은 유명 대기업 계열이 아니고 그렇다고 gcc 같은 오픈소스 진영도 아니면서 C/C++ 컴파일러를 상업용으로 제일 먼저 PC에다 구현했던 선구자들이 누군지를 문득 생각하면서 끄적여 보았다.

Posted by 사무엘

* 과거 내지 현재의 컴퓨터와 관련하여 개인적으로 궁금한 것들 컬렉션이다.

1.
요즘 길거리나 건물 근처에서 쏘는 와이파이를 보면 처음에 접속하는 건 암호가 없는 public 형태이지만, 접속한 뒤에는 무슨 주소를 입력하더라도 로그인/요금 결제 페이지로만 포워딩되는 형태인 것들이 많다. 사실은 학교 와이파이도 보안 ActiveX 등등을 안 깔면 설치 요구 페이지로만 연결된다.

그런데 이 상태에서도 페이스북이나 유튜브에 접속하는 건 바로 되는 경우가 종종 있다. 얘들만 교신을 하는 방법이나 프로토콜이 달라서 그런지(https라든가.. 서버가 외국에 있어서?) 무슨 이유 때문인지는 모르겠다.

사실, 웹서버가 뭔데 내 컴퓨터의 운영체제와 브라우저라면 몰라도(http 헤더에 에이전트 정보가 들어가므로), 보안 솔루션의 설치 여부는 뭘 보고 판단하는지 모르겠다. 프록시인지 뭔지를 써서 warning.or.kr를 우회해서 각종 금지 사이트에 접속하는 것도 어떻게 하는지? 난 웹 쪽은 아는 게 거의 없음. 그 바닥은 너무 골치 아프다.

2.
디카나 폰을 PC에다 연결했을 때 보통은 여느 USB 메모리를 꽂은 것처럼 드라이브 문자가 하나 더 추가되고 해당 기기의 메모리 내부 파일 시스템에 접근이 가능해진다.
그런데 어떤 건 꽂으면 뭔가 파일 시스템이 생기기는 하는데 드라이브 문자가 추가되는 형태가 아니다. 여기는 탐색기로만 접근 가능하지, 어지간한 다른 프로그램에서 파일을 바로 열고 내용을 볼 수 없다. 하드디스크에 복사한 뒤에야 내용을 확인할 수 있다.

그러니 사용자의 입장에서는 불편한데, 오히려 더 나중에 등장한 디카나 폰이 PC와 연결됐을 때 더 이러는 경향이 있다.
이건 기술적으로 무슨 규격이나 프로토콜을 써서 동작하는 건지 모르겠다. 그리고 드라이브 문자가 추가되는 것보다 무슨 장점이 있어서 저렇게 동작하는지도 모르겠다. 혹시 보안?

3.
컴퓨터의 USB 포트에 어떤 기기를 연결하면 인식이 곧장 될 때가 있지만 "인식 실패" 에러가 뜨면서 잘 안 될 때도 있다. 폰이나 USB 메모리 부류 말고 외장 하드 같은 묵직한 물건은 전력이 부족해서 안 될 때도 있다. 이런 건 (1) 컴퓨터, (2) 케이블, (3) 해당 기기 중 어느 게 문제인 걸까..?
컴퓨터라는 건 절대적으로 확실하고 예측 가능한 결과만 나오는 물건일 텐데, USB 포트만은 뭔가 상황에 따라 복불복인 결과가 나오는 면모가 있다.

4.
이제 슬슬 레거시 얘기를 꺼내겠다.
요즘 아직도 빅 엔디언을 쓰는 컴퓨터가 현역으로 돌아가는 게 있는지(코볼 프로그램도 돌아가는 마당에 빅 엔디언이 하루아침에 전멸할 리는 없겠지만.. 엔드 유저가 실감 가능한 영역에 있는가?),
그리고 IA64 아이테니엄 컴퓨터가 아직 살아서 운용 중인 게 있는지 궁금하다.

1990년대 말과 2000년대 초에 인텔이 IA64, 그리고 펜티엄 4의 넷버스트 아키텍처 때문에. 그야말로 세기말과 새천년기에 컴퓨터계의 판도를 바꿀 정도로 큰 삽질을 하긴 했다. 물론 덕분에 경쟁사인 AMD는 큰 이득을 볼 수 있었다.
공교롭게도 이 시기가 무어의 법칙이 슬슬 약발이 다해 가는 시기이기도 했다. (싱글 코어 기반 클럭 속도 향상) 그러니 CPU 제조사의 입장에서는 미래를 내다보고 모험을 감수하고라도 판도를 근본적으로 바꾸는 큰 결정을 내려야 했을 것이다.

다음으로 엔디언 얘기를 하자면, 스마트폰용 최신 CPU는 아예 어느 엔디언으로도 네이티브 구동이 가능한 bi-endian 구조라고 하지만, 굳이 big 모드에서 실행될 일은 별로 없을 것 같다.
오늘날 빅 엔디언의 잔재는 예전에도 언급했듯이 트루타입 글꼴 파일, 그리고 네트워크 표준 스펙 정도에나 남아 있는 듯하다. 유니코드 텍스트도 UTF-16LE 아니면 차라리 UTF-8이지 UTF-16BE가 쓰일 일이 있나 싶다. 난 지금까지 한 번도 못 봤음.

5.
옛날 도스 시절에 상당수 프로그램들의 종료 단축키는 Alt+X였다. 아래아한글, 이야기, 그리고 Q-edit 계열이 이런 관행을 유지해 왔다.
지금 Windows에서는 Alt+F4가 단순히 대화상자 창을 닫는 ESC의 상위 호환이다. 대화상자만 닫는 게 아니라 응용 프로그램의 main window도 닫고 궁극적으로 시스템 종료까지도 가능하다. 하지만 도스 시절에 Alt+F4로 종료하는 프로그램은 본인은 정말로 MS DOS Shell밖에 못 봤다.

게임들은 대부분 ESC만 눌러도 원큐에 종료 가능했지만 페르시아의 왕자는 혼자 Ctrl+Q라는 독특한 단축글쇠로 종료했다(2편에서는 Alt+Q도 추가). 페르시아의 왕자 원판이 처음에 애플 기종용으로 개발되었고, 그쪽은 Cmd+Q가 종료이니 그거 영향을 받은 게 아닌가 싶다. 맥의 Cmd+Q는 창을 닫는 기능이 없이 그냥 원큐에 프로그램을 종료하는 용도로만 쓰인다. 그리고 내 기억이 맞다면 포토샵처럼 맥에서 이식된 프로그램은 Windows에서도 Ctrl+Q 종료 단축글쇠를 갖고 있었다.

그 외에 마소에서 만든 옛날 도스용 프로그램 중에는 웬 F3이 종료인 물건도 드물게 있었다. 주로 Windows 3.1 내지 9x 계열의 설치/setup 프로그램이 그랬던 것 같다. 이 관행은 오래 이어지지 못했다.

6.
옛날 자동차만큼이나 개인용 컴퓨터계에서도.. IBM 호환 PC라는 게 세상을 평정하기 전에 있었던 특히 1980년대의 8비트 구닥다리 컴퓨터들에 대해서 요즘 갑자기 좀 관심이 생겼다. 기계들 계보를 분류해 보고 싶다. 어떤 건 기계 자체의 명칭이지만 어떤 건 규격의 명칭이기도 하다. 이 당시 CPU의 제조사도 여럿 있었을 텐데.. 시간 나는 대로 인터넷 찾아 가며 차근차근 공부할 생각이다.

먼저 애플 II~III부터가 8비트였고 국산 컴퓨터로는 삼성 SPC-1000, 금성 패미콤이 있다. MSX는 특정 기종 이름이 아니라 규격명일 테고. Commodore 64에서 64는 메모리가 64KB라는 뜻이다 CPU는 64비트가 전혀 아니며 8비트임.
요런 컴퓨터들은 그냥 켜면 롬에 내장돼 있던 베이직 인터프리터가 떴고, 카트리지를 꽂으면 게임을 할 수 있었다. 테이프는 개인적으로 구경 못 해 봤다.

삼성의 경우 살인적인 공밀레에 공밀레를 거듭한 끝에 1983년 말에 최초의 국산 메모리 반도체인 64K D램을 개발하는 데 성공했다.
팀원: "저 다음 주에 결혼할 예정이어서 휴가 좀.." / 팀장: "야 왜 하필 이렇게 바쁜 와중에 결혼을 (쳐)하는 거야! 버럭"
거의 이런 분위기에서 개발한 것이었다. -_-;; 과장이나 주작이 아님. 저렇게 팀원을 실제로 갈궜던 당시 팀장이 신화창조던가 다큐에서 출연해서 증언을 했으며, 지금 생각하니 그 팀원에게 너무 미안하다고 회고했다.

더 부가가치가 높은 비메모리 반도체를 선점하지 못한 건 아쉬운 점이지만 일단은 그 열악한 환경에서 메모리 반도체 하나라도 저렇게 잡은 걸 다행으로 여겨야 할 듯하다. 그런데 삼성 전자에서 같은 1983년에 컴퓨터까지 만들었다는 게 대단하게 느껴진다. 그 옛날부터 이미 미래에 나라를 먹여 살릴 산업을 예견하고 리스크를 감수한 투자를 아낌없이 한 것이다.

나도 "IBM 호환 PC"에 속하는 컴퓨터를 접하기 전에 아주 잠깐 소위 8비트 컴퓨터라는 걸 집에서 접한 적이 있었다. 그건 정확하게 무슨 기종에 속한 물건이었을지 궁금하다.
프롬프트가 Ok 대신 READY라고 나오고, 입력한 문장에 문법 에러가 있으면 비프음과 함께 SYNTAX ERROR이라고 나왔는데.. 롬 베이직 인터프리터가 뜬 모습은 지금 생각해 보면 커모도어 64의 그것과 제일 비슷해 보인다. 하지만 실제로 그게 맞는지는 알 길이 없다.

넥슨 컴퓨터 박물관에서 이런 물건을 발견했다. 모니터는 내가 옛날에 집에서 써 봤던 그 기계와 정확하게 일치한다. 확실하다. 검은 테두리에다 오른쪽에 저렇게 작은 다이얼이 3개 있었고..  하긴, 옛날 아날로그 모니터들은 밝기 같은 걸 조절하는 게 저렇게 물리적인 다이얼 형태로 존재했었다. 검색을 해 보니 "금성 패미콤".. 아하, 메이커가 금성사였구나.

아무튼, 이런 원시적인 물건을 통해서 나는 프로그래밍이라는 행위의 짜릿함을 경험했고 무한한 신기함과 흥미를 느꼈다. 그래서 지금의 내가 있게 됐다. 어렸을 때 접한 컴퓨터가 처음부터 지금의 컴퓨터처럼 성능이 너무 좋고 시스템이 복잡하고 사용자가 개입할 여지가 없다시피한 형태였다면, 난 컴퓨터 말고 다른 진로를 갔을 가능성이 높다.

Posted by 사무엘