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

오랜만에 알고리즘 얘기.
정보 올림피아드 공부를 한 적이 있는 분이라면, 제목에 등장한 용어가 아주 친숙할 것이다. 앞으로 LIS라고 줄여 일컫겠다.

어떤 수열이 왼쪽에서 오른쪽으로 나열돼 있으면, 그 배열 순서를 유지하면서 크기가 점진적으로 커지는 가장 긴 부분수열을 추출하는 것이 목표이다.
가령, {3, 2, 1, 4, 5, 2, 3, 5, 3, 6, 4} 같은 수열이 있으면
1, 2, 3, 5, 6이 가장 긴 solution이 된다. {3, 2, 1, 4, 5, 2, 3, 5, 3, 6,  4} OK?
정렬만큼이나 알고리즘 기초를 다지는 데 도움이 되는 흥미로운 문제이다.

이 문제는 간단하게 생각하면 다이나믹 프로그래밍(동적 계획법)을 적용한 O(n^2)의 시간 복잡도로 풀 수 있다. 작은 set에 대한 답을 구한 뒤 그 결과를 저장해 놓고, 그 set의 크기를 차츰 키우면서 작은 solution들을 종합하여 최종 solution을 구하는 방식.

매 원소에 대해서 자기까지 왔을 때 존재 가능한 subsequence의 최대 길이와, 그 subsequence 상에서 자기 앞 원소의 위치를 적어 놓는다. 그러면 다음 원소 차례가 됐을 때는 자기 앞 원소들을 일일이 탐색하여, 자기보다 값이 작으면서 잠재적 subsequence 길이가 최장으로 설정되어 있는 원소에다 자기를 연결해 놓는다. 물론 자기의 subsequence 길이는 1 증가시켜 놓고 말이다.

위와 같은 표가 완성되고 나면, 그 후 개수가 5로 가장 큰 9번 오프셋부터 시작하여 이전 참고 위치를 따라 역추적을 하면 LIS가 구해진다.

그런데 이걸 구하기 위해서 꼭 O(n^2)이나 되는 계산량이 필요할까? 더 효율적인 알고리즘은 없을까?
답은 ‘있다’이다. 물론 메모리 복잡도도 아까처럼 O(n)으로 완전히 동일하고 말이다.
이 새로운 알고리즘은 역시 길이가 n인 버퍼에다가 작업을 하는데, 버퍼의 용도가 아까와는 살짝 다르다.

이 버퍼 A[i](1<=i<=n)의 의미는, 길이가 i인 LIS를 구한다고 쳤을 때 존재 가능한 가장 작은 LIS 마지막 원소(와 그 원소의 위치)이다. 즉, 이 버퍼는 구해진 LIS의 길이만큼만 사용된다.

위의 예제 수열에서 매 원소가 들어올 때마다 버퍼는 다음과 같이 바뀌게 된다. 뒤에 새로운 원소가 추가되거나 이미 있는 값의 업데이트만 발생하지(O(1)), 배열 원소들을 전부 하나씩 밀어야 하는 삽입이나 삭제(O(n))가 발생하지는 않음을 염두에 두기 바란다.
3: 3
2: 2
1: 1
4: 1 4
5: 1 4 5
2: 1 2 5
3: 1 2 3
5: 1 2 3 5
3: 변화 없음
6: 1 2 3 5 6
4: 1 2 3 4 6

즉, 버퍼가 가리키고 있는 것은 각 길이별로 가장 작은 수일 뿐이다. 그러나 버퍼가 가리키는 순서대로 배열을 참조하면 수열이 언제나 오름차순, 즉 정렬이 돼 있다는 게 보장된다.
최소값을 갱신할 위치를 찾는 것은 이분 검색(binary search)으로 할 수 있다. 이 덕분에 작업이 O(n^2)에서 O(n log n)으로 줄어들 수 있게 된다. 정확하게 말하면 O(n log k)(k는 LIS 길이)이니 더욱 빠르다. worst case로 증가 수열을 만들 수가 없는 내림차순 수열을 던져 주면, 거의 O(n)이나 다름없는 속도로 금방 실행이 끝난다는 뜻이다.

물론, 이 버퍼에는 각 길이별로 가장 작은 증가 수열을 구하는 힌트만 들어있을 뿐, 가장 긴 LIS를 추적하는 정보는 전혀 들어있지 않다. 그렇기 때문에 추적 순서는 역시 별도의 배열에다 따로 보관해 놔야 하며 이 역시 그리 어렵지 않게 구현할 수 있다. 심심하신 분은 이 알고리즘을 직접 코딩해 보기 바란다.

정보 올림피아드를 공부하던 시절엔 이런 유형의 문제도 재미있었다. 뭐, 본인은 머리싸움에 쥐약인 타입인지라 경시 부문에서는 별 재미를 못 보고, 대박은 공모 부문에서 다 냈지만 말이다.

- 양수와 음수가 뒤섞인 n개의 수열이 있을 때 합이 가장 큰 구간을 O(n) 시간 만에 구하기
- 위와 비슷한 예로, 0.x와 n.x가 뒤섞인 n개의 수열이 있을 때 곱이 가장 큰 구간을 역시 O(n) 시간 만에 구하기
- x*y 2차원 배열이 있을 때, 이런 조건을 만족하는 가장 넓은 면적을 구하기 (1999년도 IOI의 공항 건설 부지 찾기 같은)

알고리즘이라는 게 OR(operations research)과 밀접한 관계가 있는 것 같다. 선형 계획법, 동적 계획법 같은 개념도 원래는 그 분야에서 유래되었기 때문에 용어에서 그다지 전산학적인 어원은 찾을 수 없다.
덧. algorithm인데 왜 다들 알고리듬이라고 적지 않고 알고리즘(=algorism?)이 보편화해 있는 걸까?

Posted by 사무엘

우리는 C/C++ 언어에 대해 배울 때, 이 언어는 근본적으로 컴파일과 링크를 거쳐 결과물이 만들어지며, 이 과정에서 소스 코드가 obj 파일로 바뀐다는 말을 듣는다. 그런데 이런 중간 파일들의 내부 구조는 어떨지, 최종 결과물인 실행 파일의 형태와 중간 파일 사이의 관계는 어떨지 등에 대해서 궁금하게 생각해 본 적은 없는가?

물론 obj 파일에는 컴파일된 기계어 코드가 잔뜩 들어있을 것이고 lib는 그냥 이미 컴파일된 obj 파일의 컬렉션에 불과하다. 하지만 그걸 감싸는 컨테이너 포맷 자체는 필요할 것이다.
C++의 경우, 함수의 이름을 prototype대로 decorate하는 방식이 표준으로 제정된 적이 없어서 그 방식이 컴파일러마다 제각각인 것으로 악명 높다. 그렇다면 이런 obj, lib 파일 포맷도 언어마다, 혹은 컴파일러마다 제각각인 것일까?

결론부터 말하자면, 정답은 ‘No’이다. obj, lib 같은 파일 포맷은 실행 파일의 포맷과 더불어 굉장히 시스템스러운 포맷이고, 일반적인 응용 프로그램의 개발자가 거의 관심을 가질 필요가 없는 분야임이 틀림없다. 컴파일러를 만든다거나, 골수 해커 같은 부류가 아니라면 말이다.

이런 건 그렇게까지 다양한 파일 포맷이 존재하지 않으며, 다양하게 만들 필요도 없다.
인텔 x86 기계에서는 전통적으로 인텔 사가 고안한 OMF(object module format이라는 아주 평이한 단어의 이니셜) 방식의 obj/lib 포맷이 독자적으로 쓰였다. 굉장히 역사가 긴 포맷이며, 볼랜드, 왓콤, MS 등의 컴파일러에서 다 호환됐기 때문에 서로 다른 컴파일러나 언어로 만든 obj 파일끼리도 이론적으로는 상호 링크가 가능했다. 물론, 언어별로, 특히 C++의 경우 아까 언급했듯이 decoration 방식이 다르면 명칭이 일치하지 않아 혼용이 곤란하겠지만, 이건 파일 포맷 자체의 문제는 아니었다.

그런데, 32비트 시대가 도래하면서 사정이 약간 달라졌다.
machine word의 크기가 커지고 CPU의 레지스터 구조도 달라지고.. 그에 따라 obj/lib 파일의 포맷도 일부 필드의 크기가 확장되는 등 변화를 겪게 되었으며, 인텔 사에서는 OMF 포맷을 32비트로 확장한 업그레이드 버전을 내놓았다. 마치 지금 윈도우의 PE 실행 파일도 64비트에서는 기본적인 뼈대는 그대로 유지하되, 규격이 확장된 것과 같은 이치이다.

컴파일러들은 대체로 그 규격을 따르기 시작했으나, 이때 MS에서는 꽤 과감한 결정을 내렸다.
기왕 32비트로 갈아타는 김에, 자기네가 만드는(OS/2의 밑천으로? ㄲㄲ) 순수 32비트 운영체제인 윈도우 NT에서는 공식 사용하는 실행 파일과 obj/lib 파일의 포맷을 싹 바꾼 것이다.
어디 그뿐일까? 메모리가 귀하던 1990년대에 그때 이미 유니코드를 고려하여 딱 16비트 wide string을 내부 자료 구조로 채택했다. 본인이 보기에 윈도우 NT는 출발이 굉장히 대인배스러웠다.

새로운 포맷은 단순히 구조체 필드만 32비트에 맞게 키운 게 아니라, 더 보편적인 이식성과 확장성을 고려해서 설계되었다. 코드, 데이터 등 용도별로 다양한 chunk를 둘 수 있고, CPU 정보도 넣어서 굳이 x86뿐만이 아니라 어느 플랫폼 코드의 컨테이너로도 활용할 수 있게 했다. 또한 어차피 똑같은 기계어 코드가 들어있는 파일인데 obj/lib/exe 사이의 구조적 이질감을 낮춰서 일단 컴파일된 코드의 링크 작업을 더욱 수월하게 할 수 있게 했다.

그래서 MS는 32비트 컴파일러에서는 AT&T가 개발한 COFF(Common Object File Format) 방식을 약간 변형한 obj/lib를 사용하기 시작했고, 32비트 실행 파일은 잘 알다시피 COFF의 연장선에 가까운 PE(Portable Executable) 방식을 채택했다. 이 컨벤션이 오늘날의 64비트에까지 고스란히 전해 내려오는 중이다.

그렇게 MS는 과거 유물을 미련 없이 내버렸지만, 볼랜드 컴파일러는 32비트 윈도우용도 여전히 OMF 방식을 사용했고, 왓콤처럼 당시 16비트/32비트 도스/윈도우를 모두 지원하던 컴파일러는 OMF와 COFF 방식을 혼용까지 해서 당시 개발자들에게 상당한 혼란을 끼쳤다고 한다. 윈도우 운영체제가 16비트에서 32비트로 넘어가면서 이런 것까지도 정말 넘사벽에 가깝게 세상이 바뀐 것이다. 참고로 DJGPP는 도스용 컴파일러이지만 32비트 기반이고 COFF 방식 파일을 사용한다.

1985년에 나온 윈도우 1.0 이래로 16비트 윈도우가 사용하던 NE 포맷은 chunk 같은 게 없었다. 정보 자체를 식별하는 방법이 없이 요 정보 다음엔 무슨 정보, 다음에는 무슨 정보.. 딱 용도가 고정되어 있었고, 뭔가 확장을 할 수가 없었다. 상당히 원시적인 포맷이었다는 뜻. 개인적으로 그 시절에는 컴파일과 링크가 어떻게 이뤄졌고 DLL import/export가 어떤 방식으로 되었는지 무척 궁금하다.

또 생각나는 게 있는데, 과거에 똑같은 베이직 컴파일러이지만 MS가 개발한 퀵베이직은 굉장히 C언어에 가깝고, 파워베이직은 파스칼에 가까운 빌드 모델을 사용했다. 전자의 경우 헤더 파일을 인클루드하고 소스 파일을 obj로 컴파일하고, 각종 라이브러리와 링크하고... C와 똑같지 않은지? obj/lib 파일 포맷은 당연히 인텔 OMF 방식이었다.

그 반면, 파워베이직은 파스칼처럼 unit이라는 패키지를 만들고, 그걸 간단하게 use하는 것만으로 여타 모듈의 루틴을 사용할 수 있었다. 자바, C#, D 같은 요즘 언어들이야 비효율적인 인클루드(text parsing이 필요!) 방식이 아닌 패키지 import를 선호하는 추세이지만, 그 당시 파워베이직을 개발한 Bob Zale은 분명 파스칼 언어에서 이 아이디어를 따 왔을 것 같다. 물론 그렇다고 해서 파워베이직도 기존 obj 파일과 링크하는 방식이 없는 건 아니었다.
Bob Zale과, 터보 파스칼을 개발한 필리페 칸과는 어떤 사이일지 궁금하다.

C/C++에 전처리기가 있다면, 베이직이나 파스칼 같은 언어는 주석 안에다가 메타커맨드를 넣는 방식을 써 온 것도 흥미로운 점.
아울러, tpu, pbu 같은 저런 unit 파일은 분명 컴파일된 기계어 코드가 들어있는 라이브러리에 가깝지만, 당연히 컴파일러 vendor마다 파일 포맷이 제각각이다. 마치 퀵베이직의 QLB(퀵라이브러리) 파일이 아주 독자적이고 특이한 실행 파일인 것처럼 말이다.

Posted by 사무엘

컴퓨터가 글자가 아닌 그림을 처리하기에는 능력이 한참 부족하던 시절에, 벌써부터 포인팅 장비라는 개념이 있는 게 사용자 인터페이스 차원에서 좋겠다는 생각을 한 선구자가 있었다. 그게 한 196~70년대의 일이다.
포인팅 장비는 2차원 평면에서의 속도감 내지 곡률을 표현할 수 있기 때문에, 컴퓨터에서 키보드와는 또 다른 영역을 개척한 중요한 입력 장치이다.

마우스: x, y 축의 재빠른 이동과 클릭을 지원하는 대표적인 포인팅 장비. 옛날에는 버튼이 3개였으나 요즘은 2버튼으로 통일되었고, 대신 휠이 달려 나온다. 또한 볼 마우스이던 것도 다 광 마우스로 대체. 3버튼이나 트리플 클릭이 없는 것은 인간이 심리적으로 3회 이상의 동일 동작 반복을 싫어한다는 증거가 될 수도 있다. 마우스를 쓰는 프로게이머는 있어도 트랙볼이나 터치패드를 쓰는 변-_-태는 없다. 하지만 인체공학적으로 잘 만들어지지 못한 마우스를 오래 사용할 경우 사용자의 손목에 굉장한 무리를 주므로 주의 필요.

트랙볼: 볼 마우스의 볼을 직접 굴리는 방식으로, 마우스와 기능면에서는 동일하다. 마우스의 쾌적한 이동성은 다소 희생했지만, (1) 좁은 공간에서 사용 가능하고 (2) 손가락만 까딱이면 되지 손목 전체를 움직일 필요가 없어서 피로감이 덜하다는 장점이 있다. 그래서 노트북에 전통적으로 트랙볼 류의 포인팅 장비가 탑재되는 경향이 있었다.
트랙볼은 x, y뿐만 아니라 마우스로는 가능하지 않은 z축 이동을 이론적으로 표현할 수 있다. (볼 자체를 좌우로 굴리기!!) 나름 3차원 장비라는 뜻. z축을 휠로 사용해도 될 것 같은데.

터치패드: 역시 노트북용 마우스 대체 장비로 손가락을 마우스처럼 이동한다. 트랙볼의 장점을 어느 정도 가지면서 이동의 편의성이 트랙볼보다 낫지만 여전히 마우스보다는 못하며, 이동 중에 클릭이나 휠 조작을 동시에 하기가 어렵다는 단점이 있다. 터치패드에 영 적응을 못 해서 늘 마우스를 지참하는 노트북 사용자도 있으나, 본인은 터치패드로 스타도 할 정도로 이놈을 아주 능숙하게 다룬다. 노트북 사용 10+년 경력.

IBM 노트북에만 있는 거시기: 이름이 뭔지 모르겠다. 트랙볼보다도 더욱 홀쭉한 bar를 한 손가락으로 어루만지고 있으면, 손가락이 닿은 지점에 따라 마우스 포인터가 직선 내지 매끄러운 곡선 궤적을 그리면서 이동한다. 공간 활용성은 최적이고 어떻게 만들었는지 정말 신기하기 그지없는 물건이긴 하나, 이동성은 그리 좋지 못하다고 봐야겠다.

아울러, 마우스를 제외한 다른 대체 포인팅 장비들은 휠을 굴리는 것까지는 표현하는 방법이 있는 반면, ‘휠을 누르는’ 동작은 표현하지 못하는 경우가 많다. 보통 휠을 누르면 동그란 앵커가 포인팅 지점에 나타나면서 문서를 위나 아래로 자동으로 스크롤하는 모드가 된다. ^^;;

터치스크린: 이건 마우스와는 성격이 약간 다른 장비이기 때문에 마우스의 대체품이 되지는 못한다. 말 그대로 화면을 터치할 수 있는데 여러 곳의 동시 터치가 가능하고 장비에 따라서는 터치하는 압력을 표현할 수 있다. 그래서 여러 손가락을 동시에 써서 그림을 그리거나 문자를 입력하거나, 건반악기의 화음 표현까지도 가능하다.

다만, 터치스크린은 딱히 스타일러스 펜을 사용하지 않는다면 좌표의 정밀도가 크게 떨어지며, 마우스로 치면 늘 click이나 drag만 존재하지 포인터를 움직이기만 하는 hovering을 표현할 수 없다는 게 문제이다. 즉, UI 요소에 대해서 ‘이게 뭐지?’ 하는 tooltip을 구현하기 어렵다. 또한 좌클릭/우클릭 구분도 할 수 없기 때문에 마우스와는 근본적으로 다른 방식의 UI 설계가 필요하다.

태블릿: 옛날에 본인이 어렸을 때는 디지타이저라고 배웠던 것 같다. 웹툰 작가 같은 그래픽 디자이너에게 필수인 물건이다. 모니터가 아니라 종이처럼 생긴 납작한 물건 위에다가 펜으로 그린다. 그래픽용으로 쓰는 물건인 만큼 압력을 표현할 수 있다.

※ 덧붙이는 말

1. 도스 시절에는 마우스를 모뎀과 같은 COM port에다 꽂았다. 추억의 mouse.com 프로그램. 무슨 인터럽트 서비스를 호출해 주면 하드웨어? 차원에서 아주 자그마한 마우스 포인터가 나타났었다. 그런데 마우스 포인터를 유지하는 게 도스 시절엔 꽤 부담스러운 일이었다. 화면을 고칠 때마다 포인터를 숨기고 다시 그려 줘야 했기 때문이다. 안 그러면 화면에 잔상이 남음.

1990년대 중반에 그래픽 카드의 성능이 발달하면서 윈도우 3.1 시절부터 flicker-free 포인터가 나타나기 시작했다. 하드웨어 차원에서 마우스 포인터의 모양을 입체적으로 보존해 준다는 뜻이다. 그것도 처음에는 시스템 기본 포인터라든가 monochrome(단색) 포인터만 지원되던 것이 2000년대부터 아무 포인터에 대해서도 OK가 되기 시작한 것이다.
윈도우 2000은 안전 모드로 부팅해서 허접한 일반 VGA 16컬러 모드에서 구동될 때도 마우스 포인터가 flicker-free가 보장되는 게 인상적이었다. 9x는 그렇지 않기 때문에.

2. 초창기에 마우스를 지원하던 프로그램은 마우스 포인터라는 게 없었고, 위· 아래로 마우스를 움직이면 선택 막대가 움직이는... 오늘날로서는 아주 기괴한 인터페이스를 제공하기도 했다.

3. 그나저나 마우스 휠이라는 건 1997년 무렵에 MS가 적극적으로 홍보하면서 널리 퍼졌다. WM_MOUSEWHEEL이라는 메시지가 운영체제 차원에서 추가된 것은 윈도우 98부터이다.
그때는 나중에 휠이 연속적이고 부드러운 rolling도 표현 가능할 것을 염두에 두고 메시지의 스펙을 설계했지만 지금 휠이 실제로 그런 방향으로 바뀐 것 같지는 않다.

일반적으로 마우스 휠 메시지는 다른 마우스 메시지와는 달리, 마우스 포인터가 가리키고 있는 윈도우가 아니라 현재 키보드 포커스를 받고 있는 윈도우로 날아간다. 그래서 원래 휠 메시지는 마우스 포인터가 어디 있든지 관계없이 받을 수 있는데 예외가 있다. 웹브라우저 창에서 굴리는 휠은 키보드 포커스도 있고 포인터 역시 그 창에 있어야 인식된다. 한 브라우저 창 안에 여러 프레임이라든가 심지어 글자 입력란처럼 여러 윈도우가 존재할 수 있기 때문에 그렇게 디자인된 것 같다.

4. 옛날 컴퓨터에는 컴퓨터의 동작 전체를 멈출 수 있는 pause 키가 존재했다. 그리고 컴퓨터가 동작 중일 때 키를 자꾸 눌러서, 처리되지 못한 키 버퍼가 꽉 차면 컴퓨터 차원에서 ‘삑삑’ 경고 beep음이 났다. 이거 기억하는 분 계시는가?

이 경고음을 마지막으로 들은 게 언제인지 기억도 안 난다. 하긴, 윈도우 9x의 BSOD도 아련한 추억이 돼 간다. 그 시절엔 그만큼 컴퓨터도, 운영체제의 구조도 단순했으며 컴퓨터의 전체 자원을 특정 프로그램이 순식간에 전부 장악하는 게 가능했다. 일부 게임을 실행하면 하드웨어를 이상하게 제어해서 pause 키가 안 먹히고 ctrl+alt+del도 안 먹히고, 심지어 caps/num lock 같은 키의 램프의 toggle도 안 되게 바뀌기도 했다.
지금은? 그렇게 한 프로그램에게 덥석 줘 버리기에는 컴퓨터의 성능과 자원이 너무 커졌고, 또 그걸 과거 컴퓨터와의 하위 호환성까지 최대한 유지하면서 제공하느라 구조가 더욱 복잡하기 짝이 없게 돼 있다.

Posted by 사무엘

본인이 학부를 졸업한 후, 카이스트는 서 남표 총장을 주축으로 하여 내부 시스템이 굉장히 많이 바뀌었다. 나 같은 학생에게 굉장히 불리하게 바뀐 제도도 꽤 되기 때문에, 병특도 휴학이 아니라 일찌감치 졸업을 해 버리고 간 것을 본인은 천만다행으로 생각한다. -_- (본인은 최 덕인· 홍 창선 원장에서 시작해서 러플린 총장으로 끝난 세대이다.)

본인의 전공인 전산학과의 경우, 시간이 흐르면서 그때 조교수였던 분이 부교수가 되고 부교수가 드디어 정교수로 진급해 있는 것을 홈페이지를 통해 보곤 했다. 또한 ICU가 진통 끝에 카이스트와 결국 합병되면서, 그쪽 인력의 유입으로 인해 예전에 못 보던 교수들 얼굴이 크게 늘었다. 정보통신부가 없어진 게 크게 작용했으리라.

200X년도에 스탠퍼드, MIT 등 굴지의 학교에서 박사 학위를 받은 뒤 곧장 카이스트로 온 젊은 신임 교수들을 보면 부럽기 그지없다.
하지만 이제는 교수가 돼도 정년 보장이 옛날만치 쉽지 않고, 주변에 온통 널린 게 천재들 뿐이니 연구 실적에 대한 스트레스도 만만찮을 것이다. 서 총장이 학생뿐만 아니라 교수들도 엄청 쪼아대고 있다는 소문은 익히 들었다.

그래서인지 어느 샌가 카이스트를 떠난 교수도 보인다.
얼마 전엔 우연히 졸업생 조회 웹사이트에서 본인의 이름을 검색해 봤다.
그랬는데, 본인의 학부 졸업 논문 지도교수였던 분이 지금은 카이스트 교수 명단에서 보이지 않았다.

뭐, 학부 졸업 논문은 진짜 형식적이었고, 교수님이 내 리포트를 읽어는 봤을까 싶은 생각이 들 정도로 얼렁뚱땅 통과가 되긴 했다. 그래서 요즘은, 학부 수준에서는 졸논을 좀더 실무 위주인 현장 실습이나 졸업 프로젝트로 대체하는 게 카이스트를 비롯한 국내 대학들의 전산과의 추세이다.
처음에 본인의 지도교수는 다른 분이었는데, 나중에 졸논을 쓸 무렵에 여차여차 하다 보니 저 교수로 바뀌었다. 어째서 하필 그분으로 배정됐는지는 그 과정에 대해서는 지금은 기억이 가물가물하다.

좀더 검색을 해 보니까, 그 교수님은 고려대로 전근을 가 계셨다. 오홋;;;
호기심에 옛날 교수들 검색을 더 해 봤는데, 굉장히 놀라운 결과를 발견했다.

성균관대에 전직 카이스트 교수가 네 명이나 있었기 때문이다. 2008~09년 무렵에 한꺼번에 저기로 간 것이었다. 본인은 학부 시절에 그 교수 4인 중 3인의 수업을 들은 적이 있다.

어이쿠, 게다가 이것도 나 혼자 뒷북이었다. 성균관 대학교는 스마트폰 열풍 속에서, (그리고 아마도 이 건희 본좌님의 입김으로) 소프트웨어학과를 신설하기로 결정을 내렸다. 하드웨어인 반도체에 이어서 소프트웨어까지 특성화?? 본격 IT 대학으로 거듭나려는 듯. 그리고 그 과정에서 성대는 카이스트 전산학과 교수를 한꺼번에 네 명이나 스카웃해 갔으며, 이것은 이미 그 당시에도 큰 뉴스거리로 떠올랐다고 한다.

아마 대전 생활에 신물을 느꼈거나, 서 총장의 정책이 마음에 안 들거나, 반대로 성균관대의 파격적인 처우 제안에 끌렸거나... 그런 이유로 인해서 그분들이 전근 간 게 아닌가 싶다.

덧붙이는 말:

1.
본인은 군대를 현역으로 갔다 오지 않았고 병특 중에도 딱히 군대와 관련된 안 좋은 일을 겪은 적은 없기 때문에, 군대에 다시 끌려가는 꿈-_-;;; 같은 건 안 꾼다.
하지만 한때는 아래와 같은 판타지 같은 꿈도 자다가 몇 번 꾸긴 했다.
- <날개셋> 한글 입력기로 ISEF에 또 출전하는 꿈 (10년 도 더 전 일을..;; ㅋㅋㅋ)
- 병특을 마친 뒤에 카이스트로 3년 만에 복학하여 졸업 이수 요건 채우느라 고민하는 꿈 (아놔 나 3년 전에 졸업했어-_-)

2.
본인은 주임 교수가 국문과 소속인 협동 과정 대학원에 갔지만 학위 논문의 지도교수는 국문과가 아닌 컴퓨터과학과(전산과의 연세대 학과 명칭) 교수가 될 공산이 크다. 그래서 이곳의 교수들은 어떤 분이 있는지 틈틈이 찾아보고 있다. 본인의 코스와는 정반대로 학부는 연세대에서, 석· 박사를 카이스트에서 마친 교수가 한 분 계시는구나. 뭐 학번 차이는 본인과는 이미 까마득한 수준이지만 말이다.;;
내년부터는 국어학뿐만 아니라 컴퓨터과학과의 대학원 수업도 들을 예정이다. 본격 공학관에도 드나들게 되겠구나.

3.3.
그나저나 내 홈페이지 메인의 공개 사진을 바꿀 때가 되긴 했다. 공중파 TV에 출연한 화면이고, 분장도 아주 잘 돼 있는 데다 자막 내용-_-까지 여러 모로 아주 간지나는 모습이긴 하나.. 벌써 5년도 더 되어 너무 오래 됐고, 결정적으로 본인은 이제 카이스트 학생이 아니기 때문이다.
내가 TV에 출연한 게, 2006년에 한글 관련 다큐에 출연한 게 마지막이니, 다음엔 철도 관련 다큐에서.. (ㅎㄷㄷㄷ) 자막은 당당하게 '연세대 언어정보학과'라고 말이다. 그런 화면이라도 하나 만들어야 할 듯.

그래도 대전과 카이스트도 언제까지나 내게 제 2의 고향과 같은 곳으로 남을 것이다. 일반 대학들에서는 경험할 수 없는 카이스트만의 그 학교 분위기와 프라이드(불이 꺼지지 않는 연구실-_-)는 개인적으로 참 좋아했다.

Posted by 사무엘

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

여기서 음악 파일이란, 말 그대로 음표 정보를 기반으로 음악을 연주하는 데이터를 말한다. 과거의 컴퓨터는 어마어마한 양의 waveform 데이터를 실시간으로 읽어들여(심지어 압축을 풀면서) 재생하면서 게임까지 원활하게 돌릴 정도의 성능을 갖추지 못했다. 그렇기 때문에 이런 가벼운 음표 기반 음악 파일이 각광을 받았다. 이런 파일은 크기가 아주 작은 데다, 또 음악은 반복되는 멜로디나 리듬이 많다는 특성상 압축률도 높았다.

※ 애드립 ROL, IMS

일명 FM(주파수 변조 방식) 사운드이다.
sound.com, unsound.com, 그리고 CGA 640*200이라는 흠좀무스러운 그래픽 모드에서 실행되던 애드립 Visual Composer (무려 1987년도 프로그램이다!).
standard.bnk, 이야기, implay 이런 것들을 기억한다면 당신은 진정 old timer 인증이다.

피아노, 바이올린, 색소폰 같은 현실의 악기와 비교했을 때는 분명 모자란 게 있지만 이 FM 음악은 나름 자신만의 개성과 색깔이 있었다. 단적인 예로, 과거 <그 날이 오면 3>의 환상적인 애드립 음악을 아직도 못 잊는 분들이 적지 않다.

FM 음악의 음색은 뱅크 파일에 별도로 담겨 있었다. 수백 개의 악기 음색이 100~200KB대 크기에 담겨 있던 걸로 기억한다. 음악에서의 악기는 문자 문서에서 일종의 폰트와 같은 존재인 셈이다.
PC 통신의 음악 자료실에는 최신 유행가, 팝송, 게임 음악 따위의 ROL/IMS 파일들로 넘쳐났다. 누군가가 악보를 구해다가 노가다로 열심히 입력해서 만들었을 것이다. IMS 파일은 당시 PC 통신 프로그램의 최강자이던 <이야기>가 지원했으니 인지도 면에서 더 말이 필요없었다.

이에 덧붙여 ISS라고 해서 가사 파일이란 게 국내에서 제정되었는데, 곡이 진행되면서 글자색이 점진적으로 변하게 할 수 있었기 때문에 일종의 노래방 효과도 낼 수 있었다. 동영상으로 치면 자막 파일과 같은 존재이다.

※ 모듈 S3M, MOD

모듈 음악 파일은 기본적으로 음표 정보 기반 음악 파일 포맷이긴 한데, FM 방식과는 중요한 차이가 있다. 악기의 음색이 waveform 오디오 형태로 파일에 내장되어 있다는 것. 문서로 치면 폰트를 일일이 내장하고 있는 셈이다. 그래서 평균적인 파일 크기는 기본이 수백 KB는 먹고 들어가기 때문에 mid나 애드립 사운드보다는 큰 편이지만, 당시로서는 가격 대 성능비가 아주 우수하고 음질이 좋은 음악을 만들어낼 수 있었다.

다만 모듈 음악은 여전히 음악보다는 컴퓨터 지향적인 방식이고, 미디처럼 세계 균일 표준으로까지 승격되지는 못해서 오늘날은 WinAmp나 VLC 같은 일부 매니악한 프로그램이나 재생을 지원하는 마이너 포맷으로 명맥을 유지하게 됐다.

애드립 음악에 Visual Composer가 있다면, 모듈 음악 분야에는 Scream Tracker라는 금색 UI를 갖춘 유명한 소프트웨어가 본좌이다. 그리고 재생기로는 Inertia player이라고 전설적인 도스용 프로그램이 있었다. 개발자가 밝히기를 100% 어셈블리만 써서 작성했다고 하니 흠좀무.

※ 대세는 미디

그 반면 오늘날 대세는 역시 국제 표준인 미디이다. 본인은 윈도우를 쓰기 전에 도스 시절에는 애드립이나 모듈 음악만 접했지 미디 파일도, 재생기도 전혀 접하지 못했다. 하지만 미디라는 표준 자체는 굉장히 오래 전에 제정된 것이다.

심지어 1989-90년대를 풍미했던 페르시아의 왕자의 midisnd.dat 같은 파일을 들여다 봐도, 내부는 윈도우 미디어 플레이어로 재생 가능한 표준 미디 파일들의 모음이다! 그래서 인트로/엔딩 음악, 죽었을 때의 음악 따위를 쉽게 추출할 수 있다.

도스용 둠 1, 2의 배경 음악도 내부적으로는 미디 포맷이다. 사실, 그 전작인 울펜슈타인 3D도 데이터 파일을 들여다보지는 않았지만, 음악을 딱 들어 보면 미디인게 티가 난다.

미디에는 구체적인 음색에 대한 규정은 전혀 없기 때문에, 과거 애드립으로 허접하게 재생되던 음악도 미디인가 하면 오늘날 최첨단 노래방 기기에서 코러스까지 곁들여져 나오는 음악도 죄다 미디이다. 과거에는 미디 음악을 컴퓨터에서 제대로 들으려면 미디 카드가 필수였지만, 컴퓨터의 성능이 향상되면서 2000/ME부터는 윈도우 운영체제가 좀 그럴싸한 미디 신시사이저 소프트웨어를 내장하게 되었다.

하지만 요즘 게임들은 음악도 닥치고 wav나 mp3 통째로 내장이다. DirectMusic이 괜히 개발이 중단된 게 아니다. 현업 게임에서 쓰이질 않고 있는 컴포넌트이기 때문.

※ 애드립 음악 관련 추억: 옹 컴포저

1998년의 일이다. 옹 언욱 씨라고, 본인보다 나이는 한 학년 위이고 당시 고등학생이던 분이 <옹 컴포저(Ong Composer)>라는 프로그램을 개발했다. 쉽게 말해 애드립 음악 파일 편집기이다. 그런데 이분은 프로그래밍은 물론이고 음악, 그래픽까지 두루 본인과는 비교가 안 되는 진정한 엄친아였다. 그 열악한 16비트 볼랜드 C++로 슈퍼 VGA 그래픽(선 그리기, 점 찍기, 비트맵 -_-)과 사운드 제어 루틴을 어셈블리로 다 자체 제작하고 GUI 라이브러리에 심지어 스킨까지 혼자 다 만들었다... ㅎㄷㄷㄷㄷ;; 난 그런 쪽은 쥐뿔도 실력이 없으니 전적으로 공개 라이브러리에 의존했는데 말이다. ㅋㅋ

참고로, 컴퓨터 음악 프로그램은 Noteworthy Composer처럼 작정하고 위지윅에 최적화된 프로그램이 아닌 이상, 우리가 흔히 생각하는 것처럼 오선지에 콩나물을 그려 넣는 형태가 아니다. 스프레드시트에다가 가로줄 길이로 음표를 표현하는 아주 기계 친화적인 모습을 하고 있다. 아까 언급한 Visaul Composer나 Scream Tracker도 마찬가지. 이는 프로그래밍 언어 소스 코드에 우리가 종이에다 쓰는 수학식이 그대로(근호, 분수 등) 들어가는 게 아닌 것과 같은 이치이다.

그런데 본인도 응시했던 1998년 제 15회 정보 올림피아드 공모 부문에서 옹 컴포저는 입상을 못 했다. 이런 어마어마한 프로그램이 왜 입상을 못 했는지는 모르겠다. 그러나 이듬해, 16회 대회에서 이분은 옹 컴포저를 윈도우용으로 포팅한 옹 컴포저 2를 출품하여 금상을 받는다. 그 후의 이분 근황은 본인도 알지 못한다. 프로그래밍에다가 탁월한 예체능(그래픽/음악) 쪽 재능을 갖춘 전문가이다 보니, 게임 개발에 뜻이 있는 분이던 걸로 기억한다.

덧붙이자면 15회와 16회 대회 때는 고등부에 대상 수상작이 없었다. 그 후 17회에서 본인이 출품한 한글 입력기 1.0 버전이 대상을 차지했다.

※ 모듈 음악 관련 추억: BWSB 라이브러리

BWSB (Bells, Whistles, and Sound Boards)라고 어느 영국의 프로그래머가 개발한 프로그래밍 라이브러리가 있었는데, 이게 정말 물건이었다. 퀵베이직, 파워베이직, 볼랜드 C/C++, 볼랜드 파스칼 등에서 모듈 음악을 재생해 줬다. 셰어웨어이긴 하지만 공개용도 프로그램 종료 시에 copyright 메시지가 뜨는 것 말고는 별다른 제약이 없었다. 굉장히 잘 만들었고 문서화도 서양식 유머가 가미된 재미있는 문체로 되어 있었다. "이런 주의사항을 지키지 않으면 외계인이 쳐들어와 당신의 컴퓨터를 가져가 버릴 것이다" 식.

이 분야에서는 거의 독보적인 라이브러리가 아니었나 싶다. 하지만 왓콤이나 DJGPP 같은 32비트 컴파일러를 지원하지 못했던 게 아쉬운 점으로 남아 있다. 어셈블리 튜닝 코딩이 많다 보니, 소스의 이식성이 떨어져서 포팅이 어려웠던 듯하다.
하긴, DJGPP용으로는 알레그로라는 만능 게임 라이브러리가 있긴 했는데 이건 모듈 음악은 지원 안 하고 미디만 지원했다. 알레그로도 영국 사람이 만들었다.

Posted by 사무엘

지난 9월 13일, 본인은 손전화를 교체함과 동시에 전화번호도 드디어 010 기반으로 바꿨다.
스마트폰은 아니지만 인터넷, 카메라 등 될 건 다 되는 햅틱 급의 터치폰이 본인의 제 4대 손전화로 취임했다. (참고로 노트북도 현 기종이 제 4대이다)
고등학교를 졸업한 직후인 2001년 초에 처음으로 개인용 휴대전화를 접한 이래로, 지금까지 폰을 총 세 번 바꿨다는 뜻이다.

본인은 전화번호는 개인적으로 가깝게 지내고 아는 사이인 사람에게만 공개하지, 홈페이지 같은 공개적인 장소에서는 알리지 않음을 밝힌다. 불특정 다수에게는 메일 주소만 공개하며, 이 블로그에서도 전화번호 자체는 공개하지 않고 전화번호가 바뀌었다는 사실만 알리는 것이다. 혹시 본인의 지인이면서 전화번호가 바뀌었다는 문자 연락을 받지 못한 분이 있다면 본인에게 알려 주기 바란다.

1990년대에는 PC의 발전 속도가 가히 폭발적이었다. XT/286급 컴퓨터가 무려 윈도우 98/2000을 돌리는 성능으로 발전하면서 20세기가 끝났다. 우유, 라면 값이나 버스 요금, 공중전화 요금 따위는 20년 전에 비해 지금이 3배 이상 올랐고 심지어 자동차 가격도 인플레의 영향을 받았지만, 컴퓨터의 가격만은 보편적인 생필품 물가를 역행해도 한참 역행해 왔다.

이와 같은 맥락으로 2000년대에는 전화기가 무서운 속도로 발전했다. 전국민이 손전화를 소지하면서 삐삐는 마치 인터넷 앞에서 PC 통신이 도태하듯이 역사 속으로 사라졌다. 공중전화도 마치 우체통만큼이나 아주 없앨 수는 없지만, 경영자의 입장에서는 천덕꾸러기 같은 존재가 됐다. 자동차용 고급 액세서리이던 카폰도 닥버하게 됐다.

단색 액정 화면은 컬러로 바뀌고 단색 멜로디는 애드립 멜로디를 거쳐 자연적인 사운드로 바뀌었다. 전화기에 웬 카메라 기능이 추가되고 영상 통화가 가능해지고 인터넷 접속이 가능해졌다. 비트맵 글꼴도 윤곽선 글꼴로 바뀌었다. 나중에는 아예 프로그램을 자유자재로 만들고 설치할 수 있는 스마트폰까지 등장하면서 지금까지 존재하던 각종 개인용 정보 열람/처리 기기의 기능을 흡수하게 되었다.
(관련 글: http://moogi.new21.org/tc/208 )

본인은 안드로이드와 아이폰의 싸움이 앞으로 어떻게 될지 좀 더 지켜본 뒤에 다음 전화기는 스마트폰으로 도입할 계획이다. -_-;;

초대 손전화 시절에 본인의 번호는 017이었다. 그러던 것이 대학 시절에 제 2대 손전화를 도입하면서 번호를 016 기반으로 바꿨고, 이 번호를 2003년부터 2010년까지 거의 7년 반 동안 사용했다. 그러니 본인이 애착이 갈 만도 하지 않은지? 2대와 3대 전화기는 한글 입력이 모두 나랏글 방식이었기 때문에 본인은 7년이 넘게 사용한 나랏글 방식에 아주 능숙하다.

이미 아시는 분도 있겠지만 본인은 전임인 3대 전화기(LG 싸이언)를 거의 집착에 가까운 수준으로 오래 썼다. 2004년 말부터 지금까지 거의 5년 9개월을 사용했다. 2년을 채 못 쓰고 분실한 2대 전화기와는 아주 대조적이다. 왜냐하면 본인은 손전화로는 오로지 통화와 문자밖에 안 쓰고 부가적으로 알람이나 주소록 정도밖에 사용하지 않기 때문에, 기능이 복잡한 전화기는 전혀 필요하지 않았기 때문이다. 다른 정보 처리 기능은 늘 들고 다니는 노트북을 이용하는 것으로 충분했다.

그래서 나중에는 이 구닥다리 전화기는, 자동차로 치면 마치 아직까지 포니나 스텔라 같은 차를 몰고 다니는 것과 비슷한 것처럼 보이게 되었다. “쟤 전산학 전공한 친구 맞어?” 경악이 나오기에 충분할 정도. 요즘 IT계에서는 안드로이드나 아이폰 개발자가 없어서 일손이 부족해 난리라는데, 본인은 그런 것과는 전혀에 가깝게 관계가 없는 삶을 살아 왔다.

그러다가 결국은 전화기를 바꾸게 됐다. 그건 전적으로 전임 전화기가 낡고 고장이 나서 전화기로서의 기능을 제대로 못 하고, 수리를 받아도 별 진전이 없기 때문이었다. 일종의 자연사인 셈이며, 정말로 불가피한 이유 때문에 바꾼 것이었다. ^^;;

언제부턴가 갑자기 전화 연결이 잘 안 되고, 통화 중에 전화가 끊어지고, 문자도 받는 건 잘 되는데 보내는 게 되지 않았다. 툭하면 ‘통화권 이탈’ 에러가 났다. 나 혼자 불편한 건 상관이 없는데, 이 때문에 본인에게 연락을 하는 다른 사람이 불편을 겪을 수 있기 때문에 단호하게 조치를 취한 것이었다.

10년 가깝게 폴더를 펼치는 일에 익숙해져 있다가 버튼 누르기, 화면 길게 누르기(터치폰을 activate하는 방식) 동작을 하는 것이라든가..
예전 폰으로는 꽤 금방 꺼냈던 기능을 지금 폰으로는 몇 차례 터치를 더 해야 되는 것에 대해서 좀더 연습이 필요해 보인다.
마치 도스용 아래아한글의 달인이던 사람이 윈도우용 아래아한글이나 MS 워드의 각종 마우스 동작에 적응하는 과정과 비슷한 맥락인 것 같다.

문자 메시지는 시간이 오래 걸리는 본문부터 먼저 입력하고 나서 수신자 번호를 입력받는 것이 심리적으로 무척 안정감을 줘서 좋다. (예전 폰은 수신자 번호 다음에 본문 순서여서 불편했음)

드디어 개인용 기계에서 천지인 입력 방식을 쓰게 됐는데... 모음을 분해하는 과정이 좀 복잡한 것, 그리고 음절 모호성 때문에 자음 연속 입력이 안 되는 경우가 있는 게 무척 불편하긴 하다.
하지만 나랏글도 일부 자음은 가획이 만만찮게 복잡하고, 그런 게 천지인에서는 반대로 편하게 되는 것도 있으니 일장일단이 있는 듯하다. 게다가 나랏글은 * #까지 12키를 모두 사용하지만, 천지인은 10개만으로 문자를 입력하고 * #키는 문장 부호 입력용으로 쓴다는 특징도 있다.

전화기를 개통해서 나오니까 꼭 자가용을 한 대 뽑아서 몰고 나오는 기분이었다. 교통 수단 대신 통신 수단이라는 차이만 있을 뿐.

다음은 관련 잡설들이다.

1. 본인 전화기의 컬러링이나 벨소리는 Looking for You, Oh Glory Korail 같은 걸로 했으면 좋겠다. ㅋㅋㅋ

2. 본인은 무선 인터넷이란 걸 접한 게 2003년에 학교 안에서였다. 그러던 게 불과 몇 년 사이에 무선 인터넷이 폭발적으로 보급되고 대중화했으며, 성능마저도 과거의 어지간한 유선 인터넷 회선의 속도를 따라잡았다. 손전화와 무선 인터넷이 없던 시절에 대학 캠퍼스 생활은 과연 어땠을까 상상이 안 된다.

3. 본인은 01x 번호에다가 3G 전화 서비스 같은 건 바라지도 않았다. 아직까지 기계 대체나 번호 변경에 관심이 없는 사람들은 그냥 있는 2G 전화만으로 만족하고 잘만 쓰려는 사람들이다. 단지, 개인의 선택권인 번호나 제멋대로 바꾸지 말고 이미 있는 서비스나 잘 제공해 줬으면 좋겠다.
사실상 4천만 명이 넘는 전국민이 손전화에 가입해 있는데 010 번호+겨우 8자리는 공간이 많이 모자라지 않나 하는 생각도 든다.

4. 오늘날 지메일은 구글이 2006년 만우절에 거짓말처럼 서비스를 시작한 이래로, 웹메일 서비스의 지존의 위치를 차지하고 있다. 지메일에 익숙한 사람은 다른 포털 사이트 메일은 너무 불편해서 못 쓴다는데, 본인은 10년도 더 전에 가입한 드림위즈 메일 계정을 아직까지 사용 중이다.
뭐, 본인도 지메일 계정이 없는 건 물론 아니다. 그 당시에 지메일은 초대장을 퍼뜨리는 방식으로 자기네 서비스를 홍보하고 사용자를 끌어모았던 걸로 기억한다. 한 사람당 기가바이트 급의 계정 용량을 준다고 했고 지금은 그 용량이 더욱 커져 있기도 하다.

Posted by 사무엘

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

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

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

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

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

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

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

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

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

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

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

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

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

Posted by 사무엘

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

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

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

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

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

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

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

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

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

Posted by 사무엘

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Posted by 사무엘

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Posted by 사무엘