윈도우 95 이전에 전세계를 석권하며 가장 성공한 운영체제(?)로 평가받았던 최후의 16비트 버전 윈도우는 바로 1992년에 출시된 3.1이다. 물음표가 붙은 이유는 물론 이 물건이 홀로 부팅 가능한 완전한 형태의 운영체제는 아니었기 때문.

그런데 그 3.1이 있기 전에는 3.0 버전이 있었다. 3.1이 너무 히트를 쳤기 때문에 존재감이 무척 덜해졌지만, 영미권에서는 1990년에 출시된 윈도우 3.0이 먼저 대박을 터뜨렸다. 시스템 폰트가 밋밋한 불변폭 Fixedsys이다가 가변폭으로 최초로 바뀌었으며, 흰 바탕 윈도우에다가 버튼에 최초로 은색 3D 효과가 추가되었다.

윈도우 3.0은 한글화가 된 최초의 버전이기도 하다는 점에서 더욱 의미가 있다. 2.0이던가 2.x는 한국 지사를 통해 국내에 최초로 소개된 버전이고, 3.0은 한글화까지 된 버전 되시겠다.

한글 윈도우 3.0과 한글 윈도우 3.1은 생각보다 차이가 많이 난다. 영문 윈도우 오리지널 3.0과 3.1 사이의 차이와는 좀 다른 구석이 있다. 그래서 이 점에 대해서 글을 좀 남겨야 할 필요를 느꼈다.

내가 태어나서 처음으로 접한 윈도우도 3.1이 아니라 3.0이다. 20여 년 전, 우리집 컴은 겨우 286 AT인데 이웃집 형의 컴퓨터는 386이고 아래아한글 2.0 전문용으로 화려한 윤곽선 글꼴을 찍어 내고 있었으며, Windows라는 꿈의 GUI 환경도 구동하고 있었다니, 초등학생 꼬마이던 본인은 감수성이 자극 받지 않을 수가 없었다. 알록달록한 아이콘과 컬러 그림들!

그때 처음 본 것은 3.1이 아니라 분명 3.0이었다.

사용자 삽입 이미지사용자 삽입 이미지
한글 윈도우 3.0의 부팅 스플래시 화면이다. 영문 원판과 마찬가지로 어두운 파란 배경이며, copyright이라든가 Microsoft까지 전부 우리말로 번역이나 음차를 해서 한글로 표기했음을 알 수 있다. 저작권 경고문은 영문 원판의 스플래시 화면에는 없는데 한글판에서만 새로 추가되었다.

파란 배색 때문에 나는 윈도우 3.0의 부팅 화면과, 한메 타자 교사의 시작 화면이 비슷하다는 생각을 오래 전부터 해 왔다. 여러분도 동감하시는가?

사용자 삽입 이미지
3.1의 부팅 스플래시는 3.0의 것보다야 훨씬 더 유명하니, 기억하시는 분들이 많을 것이다. 손으로 그린 듯한 저 동글동글한 한글 서체가 인상적이다. 3.1에서만 처음이자 마지막으로 볼 수 있다. 3.11은 한글화되지 않았으며, 95부터 MS는 제품명은 세계 어디서나 무조건 영문 원형 그대로 표기해 오고 있으니 말이다.
사용자 삽입 이미지
윈도우 3.0을 구동한 화면이다. 한글판은 한옥 문 무늬를 연상케 하는 mun.bmp가 설치 직후에 기본 배경 그림으로 지정되어 있다. 영문판은 당연히 그렇지 않음. 3.1은 프로그램 제목 표시줄의 배경색이 그냥 어두운 군청색인 반면, 3.0은 옅은 파랑이고 무엇보다도 solid color가 아니라는 점이 인상적이다.

프로그램 아이콘은 완전히 모노크롬은 아니지만 그래도 전반적으로 회색 톤이 짙어서 채도가 낮다. 좋게 말하면 차분하고 가라앉은 느낌을 주고, 나쁘게 말하면 칙칙하다. 오로지 그래픽 에디터인 그림판만이 3.1의 그것과 별 차이가 없는 고채도 색상의 아이콘인 듯.
3.1은 메뉴의 배경색이 프로그램 제목 표시줄의 배경색과 동일하게 군청색이지만, 3.0은 검정이다.

그리고 이 모든 걸 떠나서, 3.0 한글판의 한글 서체는 3.1 한글판의 한글 서체보다 훨씬 더 못생기고 허접해 보인다는 걸 알 수 있다.
뭐, 한글뿐만 아니라 영문 서체도 엄청 엉성하다. 영문 윈도우 3.0의 영문 서체는 3.1의 그것과 동일하지만 한글 윈도우 3.0의 영문 서체는 그렇지 않다. 3.1에 가서야 일치가 이뤄졌다.

메뉴 단축키가 영문이 아니라 한글인 게 인상적인데, 이건 제어판에서 설정을 바꾸면 된다. 한글 윈도우 3.0과 3.1은 메뉴 단축키를 한글로 바꾸는 특이한 옵션이 존재했었다. 파일 메뉴가 ㅍ에 배당되어 있으니, 두벌식 기준으로 Alt+V를 누르면 되는 식이다. 이런 옵션은 윈도우 95 이후부터는 물론 완전히 사라졌으며, 결코 다시 도입되지 않았다. 일종의 흑역사.

사용자 삽입 이미지
세상에, 한글 윈도우의 한글 서체 이름은 처음부터 바탕, 돋움이 아니었다. 한글화 첫 버전인 윈도우 3.0에서의 명칭은 아직 명조와 고딕이었다. 개인적으로 굉장히 놀랐다. 엄청 옛날에는 MS에서 조합형 코드를 사용한 한글 도스를 만들기도 했다는데 마치 그런 걸 보는 느낌이다. 궁서와 굴림은 아직 있지도 않았고 겨우 2종.

윈도우 3.0은 아직 트루타입 글꼴이 없던 시절이었다. 그러니 New가 붙은 Courier New나 Times New Roman 같은 서체도 없었고, 글꼴 대화상자에 보다시피 볼드/이탤릭 옵션 같은 것도 없다.

한글 윈도우 3.0은 트루타입 글꼴 기술이 영문 윈도우 3.1보다 먼저 도입되었다고는 하지만, 운영체제가 기본 제공하는 글꼴이 윤곽선 트루타입 글꼴은 아니었다. 여전히 비트맵이다.

그리고 화면 하단에 드디어 한글 IME 도구모음줄이 보이시는가? 이것이 한국 마이크로소프트가 최초로 개발한 윈도우용 한글 IME이다. 저 도구모음줄은 드래그로 위치 이동이 되지 않았다.

사용자 삽입 이미지
날 더욱 놀라게 만든 건 도움말.
한글 윈도우 3.1과 한글 윈도우 95 초창기 제품들은 도움말이 해라체, 즉 반말이다. 그러나 한글 윈도우 3.0의 프로그램들의 도움말은 합쇼체, 즉 존댓말이다!
반말 도움말이 다시 존댓말로 복귀한 건 IE 4.0이 나오던 시기인 1997년쯤부터이다.

게다가 저 도트 노가다 이미지로 급조해 넣은 색인, 뒤로, 훑어보기 등의 버튼들은 도대체 뭐냐! 하긴, 영문 원판도 3.0은 저 버튼들이 이미지이긴 했다.

사용자 삽입 이미지
한글을 조합 중일 때는 비록 에디트 컨트롤처럼 기술적으로 IME-aware인 환경이라 할지라도 화면 하단에 조합 중인 글자(저기서는 ‘짝’)가 따로 또 뜨곤 했다. 이것이 3.1에서는 개선되었고, 윈도우 95에서는 조합 중일 때 커서가 네모 깜빡이로 변하는 수준까지 발전을 이뤘다.
사용자 삽입 이미지
윈도우 3.1 이래로 지금까지 운영체제의 기본 게임 중에서는 지뢰찾기가 지존의 폐인 양성 게임에 등극해 있지만, 1.0부터 3.0까지는 일명 오델로라고도 불리는 리버시 게임이 내장되어 있었다.
사용자 삽입 이미지사용자 삽입 이미지
게임과 마찬가지로 굳이 한글판에만 적용되는 차이는 아니겠지만..
윈도우 운영체제가 기본 제공하는 프로그램들은 About 대화상자가 원래 천편일률적으로 똑같다. 동일한 ShellAbout 함수에다가 아이콘과 프로그램명만 달리해서 호출하기 때문이다.

이렇게 운영체제가 기본으로 제공하는 About 대화상자는 프로그램의 이름, 운영체제의 이름과 버전, 남은 메모리와 리소스, 사용자와 제품 번호 같은 걸 보여준다.

하지만 윈도우 3.0은 프로그램 관리자, 파일 관리자, 제어판 같은 관리 성격이 강한 프로그램만이 공용 About을 쓰고, 메모장이나 문서작성기 같은 보조 프로그램들은 자기네 약식 About 대화상자를 출력하고 있다.

윈도우 3.0과 3.1 사이에는 생각보다 차이가 많이 존재한다는 걸 실감할 수 있었다.

Posted by 사무엘

2012/12/23 08:39 2012/12/23 08:39
, ,
Response
No Trackback , 3 Comments
RSS :
http://moogi.new21.org/tc/rss/response/773

<날개셋> 한글 입력기의 개발자가 심층 분석한 MS 한글 IME 리포트.
버그를 나열하기 전에 먼저 독자의 이해를 돕기 위한 기술 설명부터 하겠다.

A. MS IME의 두벌식과 세벌식의 구현 차이 -- 오토마타

일단 좋은 말부터 꺼내자면, MS 한글 IME는 현존하는 한글 입력기들 중, 어떤 의미에서는 기본에 충실하게 가장 FM대로 만들어져 있다. 두벌식과 세벌식의 로직이 서로 확고하게 분리되어 있으며 구조가 완전히 다르다. 그리고 MS 버전의 두벌식 한글 입력기는 전산학적으로 볼 때 진정한 두벌식의 고증에 가장 충실하게 만들어져 있다.

무슨 말이냐 하면, 자음이라면 초성을 조합할 때와 종성을 조합할 때의 조합 규칙에 차이가 없다. 그래서 초성이 입력되는 상태에서도 ㄶ, ㄳ 같은 겹받침을 바로 입력할 수 있는 반면, ㄲ, ㅆ 같은 쌍자음은 연타가 아니라 반드시 Shift로만 입력할 수 있다. 이 동작 방식은 내가 알기로 윈도우 95 시절 이래로 시종일관 변함 없다.

<날개셋> 한글 입력기나 아래아한글의 두벌식 입력기는 그렇지 않다. 도깨비불 현상만 추가되었을 뿐 세벌식의 사고방식으로 두벌식을 덤으로 구현한 형태에 가깝다. <날개셋>의 경우, 이 점을 감안하여 지난 6.0 버전에서 초-종성 공유 낱자 결합 규칙이라는 개념이 추가되었으며, 이를 사용하면 두벌식 입력 방식을 좀 더 두벌식스러운 사고방식으로 설정할 수 있다.

뭐, 아래아한글도 1980년대 말에 1.0이 처음 개발되었을 때는 개발자들이 세벌식이 정확하게 뭔지 몰라서 자음만 한 벌 더 있을 뿐 여전히 도깨비불 현상이 존재하는 형태로 만들었다가, 고 공 병우 박사에게서 지적 받고 고쳤다는 일화가 전해지긴 한다만.

B. MS IME의 두벌식과 세벌식의 구현 차이 -- 글쇠 인식

표준 두벌식 글자판은 A부터 Z까지 딱 알파벳 글쇠 26개에만 한글이 배당되어 있고 나머지 글자들은 영문과 완전히 똑같다. 그렇기 때문에 MS 한글 IME는 두벌식일 때는 알파벳 글쇠만 가로채어 사용하며, 숫자, 기호, 공백 글쇠는 처리하지 않고 응용 프로그램으로 그대로 넘겨 준다.

세벌식은 그렇지 않다. 몇 가지 영문과 일치하는 기호가 있긴 하지만 일반적으로 공 병우 세벌식은 4단까지 독자적으로 사용하고 숫자와 기호 영역까지 침범한다. 그래서 MS IME는 세벌식에 대해서는 아예 공백까지 포함한 48개 글쇠 자리를 모두 가로채어 동작한다. <날개셋> 한글 입력기는 가로챌 글쇠 영역 자체를 필요에 따라 정밀하게 제어하는 옵션을 아주 최근의 6.5 버전에서야 추가했다.

이렇게 두 글자판의 구현이 제각각 따로라는 점 자체는 나쁘지 않다. 그러나 이는 MS IME에 두벌식을 쓸 때는 괜찮은데 세벌식을 쓸 때만 자잘한 버그가 존재하는 빌미를 제공하고 있다. 역사적으로 볼 때, 이런 버그는 더럽게 안 고쳐진다는 특징도 있었다. 두벌식과 세벌식의 넘사벽 급의 인지도 차이 때문이다.

10년도 더 전에 포트리스라는 대포 쏘기 게임이 인기였을 때, 세벌식으로는 한글 모드에서 Space로 대포 쏘기가 안 되어 채팅과 게임을 같이 하기가 불편하다는 이슈가 있었다. 두벌식에서는 Space가 응용 프로그램이 직접 접수한 공백이지만, 세벌식에서는 Space가 직접 오는 게 아니라, 한글 IME가 가공을 하고 보내 준 공백이라는 완성된 문자열이 오기 때문이다.

C. 윈도우 7에서의 변화

자, 앞에서 다룬 건 MS 한글 IME의 두벌/세벌 메커니즘의 차이이고, 지금 하는 얘기는 운영체제의 버전에 따른 디테일의 변화 쪽이다.

16비트 윈도우 시절에는 운영체제에 유니코드도, 국제화(I18N)도, 지역화(L10N)도 없었다. 동일 제품을 한중일 나라의 문자를 입출력할 수 있게 개량하는 것은 MS의 각 지사에서 완전히 독자 기술을 사용해서 알아서 재량껏 해야 했다.

그러다가 윈도우 95/NT4가 되면서 글꼴 쪽도 획기적으로 발전하고(내장 비트맵, 트루타입 컬렉션 등), 입력기 쪽도 한중일 통합 IME 프로토콜이 처음으로 제정되었다. 그리고 입력기 프로그램은 EXE가 아니라 여타 운영체제에서 유례를 찾기 힘든 독특한 형태인 DLL이 되었다. 그래서 윈도우만 입력기의 한영 상태가 각 프로그램별로(정확히는 스레드별로) 완전히 따로 놀지, 공유가 되지 않는다.

윈도우 2000부터는 추가 글꼴과 코드 페이지 데이터만 설치해 주면 세계 어느 나라 윈도우에서도 아무 나라 언어의 입력기를 설치할 수 있게 되었고, 윈도우 XP부터는 고급 텍스트 서비스라고 불리는 일명 TSF 기술이 도입되었다. 윈도우 비스타부터는 이제 전세계 언어의 입력기와 글꼴이 추가 설치를 할 필요도 없이 기본으로 제공되며, TSF 프로토콜이 주류가 되고 기존 IME 프로토콜은 호환성 계층을 통해서나 제공된다.

이로써 비스타에서 문자 입력 방식의 그랜드 슬램이 달성되고 해피엔딩이 된 것 같은데, 윈도우 7에 와서는 기능이 추가된 건 없으면서 뭘 또 잘못 건드렸는지 문자 입력 쪽의 안정성이 전반적으로 하락했다. MS 한글 IME만의 버그인 것도 있고 운영체제 자체의 버그인 것도 있다. 이 글에서는 지금까지 언급한 A~C를 염두에 두고, 2012년 현재 MS 한글 IME에 존재하는 것으로 알려진 버그들을 정리해 보았다.

1. 세벌식 최종 + 전각문자

맥 OS는 공 병우 박사(이분이 요즘 같았으면 전형적인 앱등이이셨다ㅋㅋㅋ)의 텃새 덕분에 전통적으로 세벌식 최종이 강세였으며, 세벌식이라 하면 곧 최종 자판을 가리켰다. 그러나 PC 쪽은 도스 시절 이래로 390이 강세였기 때문에 세벌식이라 하면 곧 390을 가리켰다. 최종은 아래아한글조차 97에 와서야 제공하기 시작했을 정도로 인지도가 미미했다.

윈도우 95 때 처음으로 세벌식 최종 글쇠배열이 있긴 했지만 그런 인지도 부족으로 인해 틀린 배열이 굉장히 많았다. 그게 98에서 좀 바로잡히긴 했지만 여전히 오류가 있었고, 그 오류는 윈도우 XP/오피스 2003에 가기까지 고쳐지지 않았다.

비록 최종 글자판은 참고표와 가운뎃점처럼 1바이트 아스키 영역에 없는 글자가 있는 게 특이점이긴 했지만, 윈도우 98부터는 어차피 한글 IME의 모든 내부 자료구조가 유니코드로 바뀌었기 때문에 큰 문제가 되지 않았다. 구조가 그러하니 내가 파워업을 개발해서 패치도 가능했던 것이고.

윈도우 비스타 + MS 오피스 2007에 와서야 드디어 100% 정확한 세벌식 최종 글자판이 제공되기 시작했다. 2003년 중반에 내가 한국 MS를 방문해서 수정을 강력하게 요청했던 것도 아마 작용하지 않았겠나 생각해 본다. 비록 그 해 가을에 발표된 오피스 2003에서 바로 반영되지는 못했지만 말이다.

그런데, 이 사람들이 일을 깔끔하게 처리하지 못했다. 전각 모드에서는 참고표와 가운뎃점이 제대로 입력되지 않는다. 얘들은 아스키 문자가 아니니 라틴 문자처럼 일괄적으로 0xFEE0를 더해서는 안 되는데 그거 처리를 추가하지 않은 듯하다. 윈도우 7+오피스 2010에서까지 변함없다. 물론 한국에서는 전각 문자를 거의 쓰지 않으니, 이건 심각한 문제는 아니다.

참고로 한중일의 MS 오피스는 XP 버전부터 운영체제의 IME를 자기 것으로 패치하는 게 관행이 됐다. 일본어 IME는 운영체제의 것과 오피스의 것이 차이가 난다는 말도 있는 듯하지만, 한글 IME는 운영체제의 것이나 오피스의 것이나 차이가 거의 없음.

2. MS 워드 2007 이상에서 세벌식을 쓸 때만 나타나는 역상 현상

워드 2007 이상에서, 오피스 2007 이상 또는 윈도우 비스타 이상이 제공하는 한글 IME로 세벌식을 써서 한글과 숫자, 기호, 공백을 입력한다. 그 뒤에 IME를 날개셋이라든가 다른 일본어· 중국어 입력기로 바꾼 뒤 글자를 입력한다. 그러면 예전에 MS 한글 IME의 세벌식으로 입력했던 공백이나 숫자, 기호가 역상(검은 배경, 흰 글씨)으로 바뀐다!

사용자 삽입 이미지
굉장히 기괴한 버그이다. 이것은 워드에서만 나타난다는 점에서 워드의 문제이기도 하지만 세벌식으로 입력한 비한글 문자에 대해서만 나타난다는 점에서 MS IME의 문제이기도 하다. B에서 언급한 기술 차이를 생각해 보라.

이 역상은 문서의 내부 서식이 아니라, 문자의 중간 조합 상태를 표현하기 위해 문자 입력기가 임시로 부여하는 시각 효과이다. 일본어 입력 중에 나타나는 점선 밑줄 같은 것 말이다. 해당 문서를 저장한 뒤에 다시 불러오면 다행히 사라지긴 하지만, 그 상태에서 조치를 취하지 않으면 인쇄도 그대로 역상 모양으로 된다. -_-

더욱 기괴한 건, 오피스 2003 같은 예전 버전의 MS IME로는 세벌식을 쓰더라도 이런 현상이 발생하지 않는다는 점이다. MS 제품 자체의 버그가 확실하다. 윈도우 7/오피스 2010에서까지 고쳐지지 않았다.

3. 윈도우 7, 한글 입력 중에 바탕 화면을 클릭했을 때

윈도우 7에서 MS 워드 2007이나 2010을 실행하여 아무 한글 IME로나 한글을 입력한 상태로 있는다. 창을 최대화하지는 않은 채로 가령, ‘아’를 조합하고 있는다. 그리고 그 상태로 마우스로 바탕 화면을 클릭했다가, 다시 워드의 제목 표시줄을 클릭하여 돌아온다.

비스타에서는 동일한 절차를 수행하고 나면 ‘아’의 조합이 종료되어 커서가 ‘아’ 뒤에 가 있다. 그러나 7에서는 커서가 여전히 ‘아’를 조합하고 있지만 실질적으로는 조합이 끝난 상태이다. 받침 ㄴ을 입력하더라도 ‘안’이 되지 않고 ㄴ이 새로 조합된다.

윈도우 7은 한글 조합 중에 창의 포커스가 바뀌었을 때의 내부적인 처리가 갑자기 좀 이상하게 혹은 엄격하게 바뀌었다. 비스타나 XP 이전에는 아무 문제가 없던 게 7에서 갑자기 문제를 일으켜서 그에 대한 방어를 해야 했다. <날개셋> 한글 입력기도 과거의 5.51과 5.52 때 이와 관련된 버그 패치가 행해졌다.

4. 윈도우 7의 콘솔에서 세벌식으로 조합을 종료할 때 글자가 덧남

윈도우 XP/비스타에서는 해당사항 없고 7에서만 발생하는 구조적인 문제이다. 서비스 팩 1에서도 고쳐지지 않았다.
명령 프롬프트에서 세벌식 자판으로 한글을 입력하다가 온점이나 스페이스처럼 비한글 문자를 입력하면서 조합을 종료시키면, 조합 중이던 한글이 덧난다. 가령, ‘다.’를 입력하다 보면 ‘다다.’가 된다.

이건 꽤 황당하고 심각한 버그인데 왜 아직까지 안 고쳐졌는지 이해가 안 된다. 게다가 윈도우 7은 출시된 지 이제 무려 3년이 다 돼 가지 않는가.
왜 세벌식일 때만 그렇냐고? 이 역시 B에서 설명되었듯, 비한글 문자를 처리하는 방식이 두벌식과 세벌식이 다르기 때문이다. 문자 입력 프로그램이 아니라 운영체제의 구조적인 버그이기 때문에 윈도우 7에서는 MS IME든 날개셋이든 동일하게 발생한다.

5. IME 2010, 콘솔에서 한자 후보 목록이 곧바로 나타나지 않음

이것은 약간 불편할 수는 있지만 그렇게 심각한 문제는 아니다. 콘솔에서 한글을 조합하는 중에 한자 키를 눌러 보면, 원래 한자 후보가 콘솔 창의 하단에 곧바로 떠야 하는데 뜨지 않는다.
물론 이 상태에서도 번호를 누르면 해당 한자로 바로 변환이 되며, 좌우 화살표 같은 페이지 전환 키를 누르면 그제서야 후보 목록이 나타난다. 뭔가 코딩 실수가 들어간 듯하다.

이 버그는 윈도우 7의 기본 한글 입력기에서도 존재하지 않으며, 한글판 MS 오피스 2010과 함께 설치된 한글 IME 2010에서만 나타나는 문제이다. 즉, 운영체제의 것을 대체하는 오피스의 IME가 오히려 버그를 포함하고 있는 셈이다.
<날개셋> 한글 입력기에는 물론 이런 문제가 없다.

Posted by 사무엘

2012/06/24 08:34 2012/06/24 08:34
, , , , , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/699

잡다한 생각들

1. Shrink는 압축이 아니다

파일 단위로 문서(document)를 취급하는 대부분의 응용 프로그램들은 파일 내용을 메모리로 전부 읽어들여서 처리를 하며, 저장도 내용 전체를 한꺼번에 한 파일로 쓴다.
뭐, 개발툴 같은 경우 여러 파일을 묶어서 프로젝트라는 개념을 도입하기도 하지만, 그래도 개개의 파일을 읽어들여 편집하는 건 전체 단위이다.

하지만, 부분적인 수정이 빈번히 발생하고 매번 파일 전체를 메모리로 읽고 쓰기에는 용량이 너무 커질 수 있는 자료구조는 위와 같은 단순한 방식으로 다뤄지지 않는다. 데이터베이스라든가, 이메일 클라이언트의 편지함, 그리고 가상 기계 프로그램이 만들어 내는 가상 디스크 같은 건, 프로그램 메뉴를 살펴보면 Compact 내지 Shrink라는 명령이 반드시 존재하는 걸 볼 수 있다.

이런 데이터들은 오래 사용하다 보면 파일 내부에 fragmentation이 필연적으로 발생하며 그 양이 누적된다. 그렇기 때문에 주기적으로 shrink를 해 줘야 파일 크기가 실제 내부 데이터가 차지하는 크기와 비슷하게 최적화되며, 데이터를 다루는 performance도 좋아진다.

사실은 오늘날 컴퓨터에 존재하는 파일 시스템 자체부터가 이와 비슷한 발상으로 관리되며, 그래서 '조각 모음'이 필요한 형태이다. 윈도우 비스타 이상부터는 그걸 운영체제가 서비스(시스템이 내부적으로 돌리는 프로세스) 차원에서 주기적으로 알아서 돌려 준다. 뭐, random access에 최적화되어 있는 SSD 메모리는 그런 패러다임조차 바꿔 놓긴 했지만 말이다.

그런데 데이터베이스나 관련 프로그램들이 그 기능을 '압축'이라고 번역해 놔서 나를 몇 차례 굉장히 혼동시키곤 했다. shrink의 결과가 파일 용량 감소인 건 사실이지만, 재배치 내지 정리와 훨씬 더 가까운 개념이 어떻게 압축이라 불릴 수 있는가? 서랍 정리와 방 정리를 군대식으로 잘 해서 방이 예전보다 넓어 보이는 게 어떻게 물건을 압축한 결과라 볼 수 있겠는가?

전산학, 컴퓨터, IT 쪽에 최소한의 감각이 있는 사람이 압축이라 하면 바로 떠올리는 개념은, 무손실이든 손실이든 압축 알고리즘이며, 결과물의 크기는 줄어드는 대신 데이터를 읽고 쓰는 cost가 커지는 그런 tradeoff이다. 그러니 데이터베이스를 압축하겠다고 하면 개념에 굉장한 혼란이 생길 수밖에 없다. 차라리 과거 도스 시절에 존재했던 Stacker, DoubleSpace, DriveSpace 같은 디스크 압축 프로그램은 진짜로 그런 의미의 압축이 맞았다.

그럼 비판만 하지 말고 대안을 제시해야 하는데, shrink 내지 compact를 어떻게 번역하면 우리말로 더 잘 와 닿을지 고민된다. 한 단어로는 어려울 것 같고 끽해야 내부 메커니즘을 표현한 '파일 내부 구조 재정리'라는 뜻이 담긴 표현을 써야 하지 않겠나 싶다.

2. Everett

미국 북서부의 워싱턴 주, 시애틀 근교에는 Everett(에버렛)이라는 도시가 있다. 그런데,

- 윈도우 프로그래머로서: 비주얼 스튜디오 2003의 코드명이 이것이었다.
- 교통· 항공· 우주 매니아로서: 이곳에 보잉 사의 세계 최대 규모의 비행기 조립 공장이 있다. 항공 덕후라면 이 사실이 바로 떠오를 것이다. ㅋㅋ

VS 닷넷 초기인 2002/2003이 버그가 많다고 욕 많이 얻어먹긴 했다. 하지만, <날개셋> 한글 입력기 개발을 6년간 VS 2003으로 해 본 본인으로서는 그게 그 정도로 나쁘지는 않았다. 닷넷이 아닌 Win32 native의 관점에서 봐도 오히려 VS 6.0보다 향상된 기능이 많고 UI가 깔끔해져서 반갑게 잘 쓰며 지냈다.

운영체제의 코드명인 시카고(윈도우 95), 휘슬러(윈도우 XP), 롱혼(윈도우 비스타) 등과는 달리, 개발툴은 아무나 쓰는 제품이 아니다 보니 코드명이 잘 알려져 있지 않다. 하지만 그런 것들도 코드명이 있긴 하다.
비주얼 스튜디오 2005의 코드명은 Whidbey, 2008의 코드명은 Orcas이다. 단, 오피스 제품이 코드명이 있다는 얘기는 지금까지 못 들었다.

이 글 쓰는 과정에서 미국 지리 공부를 좀 했다. 미국의 행정 수도인 워싱턴 D.C.는 말 그대로 미국의 초기 역사가 담긴 동부 끝자락에 있는 반면, 워싱턴 주는 전혀 동쪽에 있지 않으며 그 반대이다. 워싱턴 주와 워싱턴 D.C.는 지리적으로 아무 관계가 없으니, 뉴욕 주와 뉴욕 시의 관계처럼 생각해서는 절대 절대 안 된다. ^^;;;
마이크로소프트 본사가 있는 곳은 시애틀. 고로 이곳 근처이며 역시 서쪽 끝 되겠다.

이름도 비슷하고 옛날에 윈도우 95의 임팩트가 크기도 했으니, 난 한동안 MS가 시카고에 있는 줄 알았으며, 고로 실리콘 밸리와 마이크로소프트는 마치 칼텍과 MIT 사이만큼이나 엄청 멀리 떨어져 있는 줄 알았다. 게다가 빌 게이츠는 하버드 중퇴이기도 하니 웬지 그의 주 활동 영역도 동부였을 것 같지 않나? -_-;;; 하지만 그렇지 않다.

빌 게이츠가 2008년 6월 27일에 은퇴했으니, 나 병특 마치기 딱 사흘 전에 은퇴했다.
나는 이제야 군필자가 되어서 한국에서 제약 없는 사회 생활을 시작하기 직전이었던 반면, 그 양반은 그때 기업 경영자로서 완전 만렙 찍고 은퇴했다. ㄷㄷㄷ

3. 김 명호

우리나라에 김 명호라는 이름은 여러 동명이인이 존재하는데, 다들 IT나 최소한 이공계에서 쟁쟁한 실력자들이다.

- 한국 마이크로소프트의 최고 기술 임원인 김 명호 상무. IT 매니아라면 이름 안 들어 본 사람이 없을 것이다.

- 카이스트 전산학과의 김 명호 교수. 우리나라에서 얼마 안 되는 데이터베이스 전문가이다. 아, 그러고 보니 카이스트 황 규영 교수도 DB 쪽은 가히 만렙 찍은 분이 아니던가(빡센 강의 커리큘럼 때문에 학부생들로부터 별명이 '황디비'..). 카이스트는 DB에 강하다. ㄲㄲ

- 그리고, 성균관 대학교의 수학과 교수였고, “석궁-_- 테러”로 유명한 김 명호 박사. 좋게 말하면 정말 머리 좋고 유능한 학자이고, 좀 삐딱하게 말하자면 너무 강직하고 현실과 타협을 못 하고 일종의 똘끼도 보이는 천재 타입의 인상? 그 근성이 지나쳐서 교수 재임용에 탈락하고 나중엔 살인 미수 혐의로 징역까지 몇 년 살다 2011년 초에 출소했다.
세상 부적응형의 천재 타입이라면 정말 교수가 아니면 할 일이 없을 텐데, 그 연세에 범죄자로 전락하여 교도소 나와서 앞으로 뭐 하고 사시려나 좀 걱정되기도 한다.

Posted by 사무엘

2011/12/10 19:27 2011/12/10 19:27
,
Response
No Trackback , 6 Comments
RSS :
http://moogi.new21.org/tc/rss/response/611


블로그 이미지

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

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2020/02   »
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29

Site Stats

Total hits:
1332555
Today:
127
Yesterday:
430