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

1. 요즘은 회사나 학교도 아니고 내가 사는 집안의 무선 인터넷이, 10년 전 학교의 고정 IP 유선 인터넷보다 더 빠르다.
그때는 1초에 1MB가 넘는 속도로 파일이 네트워크로 전송되는 걸 보고 ‘세상에!’ 하면서 깜짝 놀랐었는데 이제는 무선 인터넷으로 FTP 파일 전송이 초당 3~5MB씩인 것도 본다. 유선은 당연히 10MB급 이상이 된 지 오래이고...;;;

대학교 때 처음으로 무선 인터넷이란 걸 봤다. 불안정하고 자주 끊어지고 전송 속도도 300~500KB대로 지금의 10분의 1 수준이었다. 그랬으나 지금 무선 인터넷 인프라의 수준은? ㄲㄲ 격세지감이다.
본인의 초대 노트북은 모뎀만 있지 랜 카드라는 게 전혀 없었고, 2기 노트북은 유선 랜만 있어서 무선 랜 카드는 따로 달아야 했다. 3기 노트북부터는 유선· 무선 랜을 모두 구비해 있고 무선 인터넷은 이제 노트북의 필수 요소가 돼 있다.

물론 유선도 개선이 이루어져, 2004년 7월 22일부터는 그 전까지 연구실만 100Mbps(바이트가 아니라 bit)이던 네트워크 속도가 드디어 기숙사 전체까지 10Mbps에서 100Mbps로 승격됐다. 정확한 날짜가 적혀 있는 일기 짱.
하긴, 내가 딱 졸업한 뒤부터 대전에 지하철도 생기고, 학교는 기숙사 방에 에어컨도 장착되고, 재수강비가 폭등하고.. 좋든 싫든 변화가 엄청 많이 생기긴 했다.

2. 파워포인트를 잘 다루는 사람의 슬라이드를 보면, 이미 있는 디자인 템플릿을 쓴 게 아니라 정말 참신한 디자인에다가 플래시를 방불케 하는 현란한 애니메이션까지 보는 사람을 정말 놀라게 만든다.
본인이야 MS 오피스 제품은 10년도 더 전부터, 거의 97 시절부터 써 왔으며, 사실 그런 제품을 다루는 스킬은 프로그래머나 전산학 전공자에게는 자기 소개서에 쓸 거리조차 못 되는 기본적인 스킬이다.

그런데 기본 스킬이라고 해서 만만하게만 봐서는 큰코다치겠다. 제아무리 2007 버전부터 각종 현란한 이펙트가 추가되었다 하더라도, 이미 다 만들어져 있는 디자인 템플릿과 진짜 프로가 만든 나만의 디자인은 차이가 나는 법. 주변에도 정말 멋진 문서, 멋진 프레젠테이션을 적지않게 봤다.
본인도 10년 전부터 이런 제품을 썼다고 하지만 10년 전이나 지금이나 해당 제품에 대한 활용도나 이해도는 별 차이가 없다. 워드/파워포인트 실무 책도 만만하게만 보지 말고 고급 기능을 위주로 공부할 필요도 좀 있지 않나 싶다. 또한 단순 디자인 테크닉뿐만 아니라 매크로 언어 같은 것도 말이다.

참고로 육군 훈련소에 있을 때 각종 시청각 CBT 교육 자료들은 파워포인트로 만들 법도 한데 그건 진짜로 플래시로 만들어져 있었다. 뭘 근거로 플래시라고 판단했는지는 지금 기억이 안 나지만, 어쨌든 플래시였다.

3. 배불뚝이 뽀글이 아저씨의 근황이 최근 심심찮게 매스컴을 탔다.
어디서 들었는지 출처는 지금 기억이 안 나지만, 저 사람은 테러를 두려워하는 것도 있어서 외국으로 나갈 때 비행기보다는 안전한 철도를 극단적으로 더 선호한다고 한다. 그래서 맨날 열차를 탄다.

북한의 수도인 평양에도 지하철이 있다. 그것도 서울 지하철보다 1년 남짓 더 일찍 개통했다. 부산 3호선 만덕 역보다도 훨씬 더 깊다.
외국인들 관광 용도로 역 내부는 아주 으리으리한 궁전처럼 꾸며져 있지만, 에너지가 부족해서 전동차라든가 에스컬레이터 가동을 잘 못 하고 있다.

지하철 건설 과정에서 두만강 밑으로 하저 터널을 지으려 한 적이 있었는데, 뜻밖에도 실패했고 사고로 여러 명이 죽거나 다쳤다고 한다. 땅굴 파는 데 이골이 나 있을 친구들일 텐데 뜻밖이다.

정말로 어떤 통치 이념으로 나라가 세워졌느냐에 따라 이 좁은 땅덩어리의 남북이 어떻게 극단적으로 달라졌는지를 실감할 필요가 있다. 남한은 일단 민주주의에 대통령제인 건 둘째치고라도 세계 각국과 정상적으로 교류를 한다. 국민이 외국 여행을 아무 거리낌 없이 가며, 대통령이 지금 무슨 스케줄을 수행 중인지, 나라가 올림픽· 월드컵도 개최하고 각종 통계나 사건도 외국에다 아무 통제 없이 알리고 지낸다.
그 반면 저쪽은? 한 나라 지도자의 행적도 오리무중이요, 무슨 미사일이나 발사체를 쏜 것도 외국이 다 추측을 해야 한다. 우리나라는 일기예보를 할 때 북한 쪽 자료는 일본으로부터 얻어 와서 활용한다.

말이 나왔으니 말인데, 천안함 격침이 북한 소행이라면 이건 정말... 보복 전쟁이라도 불사해야 하지 않나 싶다. 아무리 우리가 반쪽만으론 작고 살기 어려워도, 역대 독재자들이 아무리 안보를 빌미로 나쁜 짓 많이 했어도, 저런 막돼먹은 깡패 집단과는 통일 나부랭이 따위 해서는 절대 안 된다. 지금까지 오로지 ‘우리 민족끼리, 북한에다 오로지 사랑으로 퍼 주자’ 하면서 미국 욕만 하느라 정신없던 친구들은 요즘 정말 닥치고 버로우 타야 할 때가 아닌가 싶다. 미군 장갑차 압사 사건은 아직까지도 우려먹는 진영이 있는 반면, 제2 연평해전은 왜 이리도 쉽게 잊어버리는가?
(하지만 현시창. 내가 보기엔, 아마 어디 소행인지 못 밝혀내고 그냥 미제 사건으로 마무리될 것 같은 분위기이다. -_-)

4. 본인은 충분히 피곤하고 잠이 쏟아지는 상태라면 주변이 어지간히 시끄러워도 잠이 잘 드는 편이다. 키보드 소리, 컴퓨터 팬 소리, 자동차 엔진음 등. 사실 전동차 구동음이라든가 비행기 소리(이륙할 때만)를 이렇게 좋아하는 걸 보면 난 태생적으로 기계음과 친숙한 건지도 모르겠다.

그런데, 음악 소리나 내가 알아들을 수 있는 말소리는 조금만 들려도 거기에 신경이 확 쏠려 버려서 잠을 절대 못 잔다. 피곤해 죽겠는데 잠들질 못하면 그건 고문..;; 아무 의미가 없는 소음은 괜찮은데 저런 음향에는 민감하다는 뜻이다.
사실은, 주변이 너무 조용해도 딴생각이 자꾸 생겨나서 잠에 금방 못 드니, 숙면과 주변 소리와의 관계는 참 미묘한 것 같다.

아, 그러고 보니 코 고는 소리도 나를 잠 못 들게 만드는 소음 중 하나. 훈련소에 갔을 때 가장 유용했던 물건은 손목시계보다도 싸제 귀마개였다. 귀마개가 없었으면 내무실에서 밤에 잠드는 데 정말 애로사항이 꽃폈을 것이고, 잠을 충분히 제대로 못 자면 다음날의 훈련의 괴로움도 더욱 커졌을 것이다. 물론 귀마개는 사격 훈련 때도 요긴하게 썼지만 말이다.

울 아버지는 누워서 TV를 보다가 곧잘 주무시는 편이다. 사람 말소리와 음악으로 온통 가득한 게 TV인데, 나의 잠버릇대로라면 저건 정말 있을 수가 없는 행동 패턴이다.

음냐.. 네 개의 글감이 서로 완전히 다른 분야와 주제의 글이 돼 버렸는데..
귀찮아서 일단 잡담 카테고리에다 한데 올린다.
네 글 중 아무 분야에나 공감되는 주제가 있다면 댓글 얼마든지 환영.

Posted by 사무엘

그림을 보면 알겠지만 동일한 실험을
a. 윈도우 3.1+Win32s
b. 윈도우 9x
c. NT급 윈도우

에서 모두 해 봤다. (요즘 버전의 비주얼 C++로 그 구닥다리 Win32s에서도 동작하는 프로그램을 만들려면, 컴파일/링크 옵션을 상당히 특이하게 바꿔야 한다. ㄲㄲ)

Win32s의 한계를 절실히 느낄 수 있을 것이다.
CPU의 가상 메모리 기능을 적극 활용하여 각 프로세스마다 자신만의 주소 공간이 절대 보장되는 윈도우 NT에서는,
같은 프로그램은 아무리 동시에 여럿 실행하더라도 자기 주소가 0x400000으로 고정 불변임을 알 수 있다. 심지어 윈도우 9x조차도 그건 보장된다.

그러나 Win32s는 프로그램을 실행할 때마다 프로그램의 인스턴스 핸들이 제각각이며, 지역 변수와 전역 변수의 주소조차도 완전히 달라진다. 시스템의 모든 프로그램들이 단일 주소 공간을 공유한다는 게 바로 저런 의미인 것이다.

Win32s는 모든 메모리 주소가 0x80000000 위의 상위로 잡혀 있는 것도 매우 신기하다.
9x나 NT급 윈도우에서는 그런 주소는 사실상 커널에서나 볼 수 있기 때문이다.
16비트 운영체제에다 아주 특수한 임시방편으로 32비트를 구현한 Win32s의 동작 방식을 짐작케 한다.

또 하나 재미있는 차이를 발견할 수 있는 것은 인스턴스 핸들과 포인터와의 관계이다.
9x/NT에서는 인스턴스 내지 모듈 핸들이 곧 포인터이기 때문에, 0x400000 같은 값에 해당하는 메모리 주소를 들여다보면 EXE 파일이 통째로 로드된 흔적을 고스란히 찾을 수 있다. 즉 MZ 같은 EXE 헤더가 바로 나타난다는 뜻이다. 그리고 전역 변수의 주소는 역시 근처의 0x40????대로 잡힌 것을 볼 수 있다.

그러나 Win32s의 인스턴스 핸들은 포인터와 아무 관계가 없는 임의의 16비트 정수일 뿐이다. 이는 원래부터 포인터가 서로 아무 관계가 없던 16비트 윈도우의 인스턴스 핸들과 개념을 일치시키기 위한 조치로 보인다. 제아무리 32비트 프로그램이라 하더라도 16비트 운영체제 내부에서는 16비트 규모로 식별이 가능해야 하기 때문이다.

끝으로, 공유 메모리의 주소도 흥미로운 결과가 나와 있다. 오로지 윈도우 9x만이 세 프로그램이 가리키는 주소가 모두 일치해 있다.
이는 윈도우 9x만의 메모리 사용 방식 때문이다. 0x80000000~0xC0...에 해당하는 영역에다 모든 프로그램들이 공유하는 운영체제 시스템 DLL과 공유 메모리를 올려 놓는다. 즉, 이 영역은 윈도우 9x에서는 아무 프로그램이나 바로 접근할 수 있는 단일 주소 공간이나 마찬가지이기 때문에 어느 프로그램에서나 의미가 동일한 셈이다.

NT는 그렇지 않다. 비록 실질적으로 가리키는 물리 메모리는 동일한 위치인지 모르나 이를 가리키는 응용 프로그램의 주소는 완전히 제각각이다. 이렇게 하는 게 훨씬 더 안전하고 보안 관점에서도 유리하기 때문이다.

Win32s는 공유건 응용 프로그램의 코드건 데이터건 가리지 않고 무조건 0x80... 상위 메모리 주소가 뒤죽박죽으로 쓰이는데, 공유 메모리마저 9x와는 달리 제각각인 주소가 배당되는 건 좀 의외이다. 9x는 공유 메모리만 상위 메모리 주소가 쓰였고 NT는 보다시피 상위 메모리 주소가 전혀 등장하지 않는다. 사용자 계층과 커널 계층이 엄격하게 잘 분리되어 있음을 뜻한다.

※ 덧붙이는 말

1. 유니코드

일단 Win32s와 9x는 운영체제의 내부적으로는 유니코드 기반이 전혀 아니다. 그래도 9x는 GDI 계층 차원에서 유니코드 문자를 폰트로부터 인식하고 찍는 건 지원하며 98부터는 유니코드 IME 프로토콜까지도 지원한다. 그 반면 Win32s는 운영체제의 한계 때문에 그런 게 전혀 없다. 운영체제 차원에서 임의의 유니코드 문자를 출력할 방법이 없다는 뜻이다.
오늘날까지 살아남은 NT는 무려 1993년에 나온 3.1 버전부터 애초에 100% 유니코드 지원을 염두에 두고 16비트 wide string을 기본으로 설계했으니 과연 대인배. 물론 이렇게 하려면 메모리가 더 많이 필요하다.

9x는 TextOutW, ExtTextOutW, GetTextExtentPoint32W 같은 GDI 함수는 NT와 기능이 동일하다(비록 surrogate는 지원 안 하지만). 그리고 MessageBoxW도 지원한다. 에러 메시지 뱉고 죽는 최소한의 동작만은 유니코드 함수로도 가능하게 배려했다는 뜻이다.
이외에 리소스를 찾는 FindResourceExW, 명령 인자 옵션을 얻어오는 GetCommandLineW 같은 함수가 유니코드 버전도 간단히 구현돼 있다. 비록 문자열을 ansi 문자열로 변환해서 A 함수를 그냥 호출해 주는 수준이지만.

Win32s는 그런 거 없다. MessageBoxW도 지원하지 않으며, 오로지 WideCharToMultiByte(와 그 역함수) 처럼 문자열 변환 함수만 지원되고 나머지 W 함수는 전혀 지원되지 않는다.

2. GDI/User 계층의 32비트

NT는 순수한 32비트 운영체제인 반면 9x 계열은 아직 상당수의 코드가 16비트로 존재했다. 이런 이유로 인해 9x는 대표적으로 GDI의 좌표계가 16비트 크기로 제한되어 있었으며, NT는 GDI 함수의 실행이 실패했을 때 GetLastError() 에러값이 온 반면, 9x 계열은 그렇지 않은 경우가 많았다. 그 에러값은 32비트 코드 계층에서 설정되는 값이기 때문이다.

과거 16비트 윈도우(Win32s도 당연히 포함)에서는 어떤 GDI 오브젝트 자체와 그 오브젝트가 따로 동적으로 할당하는 메모리의 양이 모두 GDI 힙 64KB 내부에 매여 있었다면,
9x는 일단 할당 가능한 오브젝트의 개수는 64KB의 제약을 받으나 각 오브젝트가 추가로 할당하는 메모리는 ‘별도의 제약이 없는 32비트 범위’인 식으로 제한 조건이 완화된 경우가 많았다. 가령, 복잡한 path나 region 같은 경우 추가 메모리 사용량이 만만찮으리라 예상 가능하다.

제약이 완화되기는 했으나 그래도 9x는 공포의 ‘리소스 제한’이 여전했던 것이다. 리소스 퍼센티지를 아직 기억하시는 분 계시려나?
NT는 역시 애초부터 그런 개념이 없었다. 모든 게 자유로운 32비트 공간이고 지금은 64비트로 자연스럽게 확장되어 있기까지 하다. ^^;;

Posted by 사무엘

동부 간선 도로는 서울 지하철 7호선의 강북 구간과 비슷한 노선으로 서울 동부를 관통하는 자동차 전용 도로이다. 중랑천을 나란히 끼고 달리며, 노원구, 중랑구, 광진구 등을 경유한다.

한강을 끼고 달리는 올림픽대로와 강변북로는 주행해 봤지만, 저쪽으로는 지금까지 갈 일이 도통 없었다. 그러다 요 며칠 전에 노원구 일대까지 드라이브를 했는데, 역시 자동차가 막히지만 않으면 지하철보다 확실히 빠르다는 걸 알 수 있었다. 서울 북부도 지금까지 생각했던 것보다 은근히 더 빨리 갈 수 있었다.

이 도로는 상행과 하행이 하천의 이쪽과 저쪽으로 완전히 분리되어 있다는 점이 매우 특이하다. 다른 도로에서는 한쪽은 평지이고 다른 쪽은 그 옆에 강 위의 고가와 같은 식으로 건설된 경우는 있다. 그런데 그것도 아니고... 한강으로 치면 올림픽대로는 동쪽으로만 가고, 강변북로는 서쪽으로만 가는 것이나 마찬가지이다. 그래서 도로에 진입한 후, 하천 건너편에 있는 방면으로 들어가려면 긴 다리를 빙 돌아서 건너야 한다.

달리다 보면 차창 밖으로 코레일 동부 전동차 사무소를 볼 수도 있다. 그리고 수백 m 간격으로 철길 두 개가 위로 교차하는 것도 볼 수 있는데, 본인은 처음엔 ‘중앙선이 상행과 하행이 이렇게 긴 간격으로 분리되어 있지는 않을 텐데 뭐지?’ 하고 처음엔 궁금했다.
하지만 답은 간단하다. 교각이 분홍색으로 칠해져 있는 하나는 중앙선이고, 다른 하나(빨간색)는 경춘선이다. 앞으로 경춘선은 망우 역에서 분기하게 되므로 옛 선로 교각은 없어질 것이다. 이는 앞으로 성북 역은 경춘선 열차 취급 기능을 상실할 것임을 의미하기도 한다.

내 기억이 맞다면 동부 간선 도로는 편도 3차선인 총 6차선 도로이다. 진출입로가 입체 교차로로 정말 거미줄처럼 복잡하게 만들어져 있어서 초행자는 내비 없이는 찾아가기 정말 힘들겠다는 생각이 들었다.

여기뿐만 아니라 워커힐, 구리, 남양주, 양평 등도 언젠가 국도를 타고 철도 중앙선 노선을 따라 드라이브를 하고 싶다. 이쪽은 이렇다 할 고속도로도 없고 관광용으로 정말 좋은 코스인지라 주말마다 차들로 극심한 정체라고는 들었다. 하긴, 주말에 서울 근교에 안 막히는 도로가 어디 있겠는가? 경부 고속도로도 토요일 오전에 승용차로 하행을 타 봤다가 피 본 기억도 생생하다.

Posted by 사무엘

멀티태스킹 운영체제에는 한 주소 공간에 여러 프로그램들이 동시에 실행될 수 있다. 그렇기 때문에 그런 환경에서 동작하는 프로그램이라면 자기가 메모리의 어느 위치에 적재되는지를 신경써야 하며, 임의의 위치에 올라가더라도 잘 실행될 준비가 되어 있어야 한다.

과거 도스 시절에는 EXE말고 COM이라는 실행 파일이 있었는데, 이것은 최소한의 헤더 같은 것도 없고 코드와 데이터가 다 16비트 공간 안에 막혀 있으며(과거 메모리 모델로 치면 제일 작은 tiny와 동일), 메모리 주소도 고정 붙박이식이어서 오늘날의 컴퓨터 환경과는 도저히 어울릴 수 없는 과거 유물이 되어 있다.

윈도우 운영체제의 실행 파일이 사용하는 PE 포맷은 position dependent code 방식이다. 즉, preferred base라는 개념이 존재하여 자기는 32비트 주소 공간에서 어디에 적재되는 게 이상적인 경우라고 이미 가정하고 만들어져 있다는 뜻이다. 어떤 EXE나 DLL이 거기에 바로 적재가 가능하다면 가장 빠르고 좋지만, 만약 이 선호하는 주소에다 적재가 못 된다면 별도의 재배치 작업이 필요하다. 즉, 마치 퀵 정렬처럼 잘 될 때와 못 될 때의 성능 편차가 크며 일종의 모험이 동반된다는 뜻이다.

이는 유닉스의 shared library와는 다른 디자인이다. 그쪽은 이렇다할 preferred base 주소가 없으며, 코드 자체가 어느 메모리 주소에 적재되든 동일한 성능으로.. 하지만 딱히 최적의 성능을 발휘하지는 않는 구도로 동작한다. 일종의 힙 정렬이나 병합 정렬처럼 동작한다는 뜻.

윈도우 PE 포맷에는 실제로 실행되는 기계어 코드인 code 섹션도 있고 data라든가 리소스(rsrc)와 더불어 재배치 정보를 나타내는 섹션(reloc)도 있다. preferred base에서 동작하지 못할 때, 코드의 어느 부분을 쫙 수정해 주면 preferred base가 아닌 다른 지점을 기준으로 이 프로그램이 잘 돌아갈 수 있는지를 따로 기록해 놓은 것이다. 사실 이런 개념의 재배치 정보는 도스 EXE나 16비트 윈도우 EXE에도 있긴 했다.

그런데 32비트 윈도우 EXE만은(물론 64비트도 포함) 원칙상 이런 재배치 정보가 필요하지 않게 됐다. 32비트 환경부터는 모든 EXE들이 나만의 독립된 주소 공간을 가지기 때문에, preferred base가 무엇이든지에 무관하게 EXE는 무조건 내가 원하는 위치에 가장 먼저 적재되는 게 보장되기 때문이다.
그래서 통상 EXE들은 재배치 정보를 넣지 않는다. 필요가 없기 때문에, 넣지 않는 게 파일 크기를 줄이는 데도 도움이 되기 때문이다.

그럼에도 불구하고 재배치 정보가 필요한 경우는 다음과 같다.

1. EXE가 아닌 DLL은 반드시 필요하다. DLL은 다른 EXE의 밑에 붙어서 동작한다는 특성상 자신만의 주소 공간을 갖고 있지 않다. 나의 preferred base에 EXE라든가 다른 DLL이 이미 선점되어 있다면 응당 재배치가 필요하다. DLL은 그런 상황을 언제든지 대비해야 한다.

2. Win32s에서 돌아가는 32비트 프로그램이라면 EXE라도 재배치 정보가 반드시 있어야 한다. Win32s는 과거 윈도우 3.1에서 일부 32비트 프로그램을 구동하기 위해 제공되었던 일종의 운영체제 익스텐더로, 32비트 프로그램을 실행만 해 줄 뿐, 16비트 윈도우 3.1이 지니고 있던 시스템적인 한계는 그대로 답습하고 있다.
멀티스레딩을 지원하지 않으며 32비트까지 포함해 모든 EXE가 독립이 아니라 단일 주소 공간을 공유한다!
프로그램을 실행할 때마다 EXE의 핸들이 제각각인 값이 들어오며, 로딩도 preferred base에 정확하게 절대로 되지 않는다. 여기에 대해서는 추후 실험해 볼 예정.
실제로 테스트를 해 보면 핸들이 0x1xxx 이렇게 아주 작은 값으로 들어온다는 게 매우 흥미롭다. 윈도우 NT에서는 그렇게 낮은 주소는 아예 무조건 에러로 간주하는 반면, Win32s에는 그게 여전히 쓰인다는 소리이다. 포인터가 아니라 진짜로 다른 번호에 가깝다.

3. 비주얼 C++ 2008에서 추가된 '시작 주소 랜덤화' 기능을 사용하려면 재배치 정보가 필요하다.
보안을 위해 성능을 희생하듯, 윈도우 비스타부터는 PE 실행 파일도 일종의 position independent (과거의 dependent가 아닌) code처럼 써먹으려는 것 같다.
이 방식으로 빌드된 EXE는 운영체제가 일부러 EXE의 preferred base와는 다른 임의의 위치에다가 로딩을 해 준다. 즉, 이 EXE의 특정 지점의 코드나 데이터를 딱 맞춰 수정하는 프로그램이 제대로 동작하지 않게 위해서이다. (스타크로 치면 맵핵 같은 프로그램)

Posted by 사무엘

금과 은, 특히 금은 동서고금을 막론하고 인류에게 값비싼 귀금속의 제왕으로 각인되어 왔으며 성경적인 의미도 풍부하다. 하나님은 이 세상의 물질도 귀한 것과 흔해빠진 것을 구분해 놓으신 것이다.
사람이라면 본능적으로 누구라도 번쩍이는 누런 금을 보면 아름다움을 느끼고, 탐내고 갖고 싶어할 것이다. 금은 어디서나 보편적인 ‘경제적 값어치’를 지니고 있다. 그래서 현찰만큼이나 검은 거래에서 쓰이는 매개체가 되기도 쉽다. 흔한 물질로부터 금을 만들려고 애썼던 연금술, 그리고 미국 서부 개척 시대의 골드러시를 우리는 역사를 통해 기억한다.

잘 알다시피 올림픽에서는 상위 입상자에게 금· 은· 동메달이 수여된다. 그런데 1차 세계 대전의 직전에 개최된 1912년 제 6회 대회까지는 메달을 단순 도금이 아닌 진짜 순금· 순은으로 만들어서 줬다는 것도 흥미로운 사실이다. 흠좀무... 그렇게 해서는 올림픽 위원회의 재정이 남아나질 못했을 것이다.

금은 잘 알다시피 일단 외형이 정말 탐스럽다. 그런데 희귀하다.
그리고 매우 안정적이다. 공기 중에서 녹이 전혀 슬지 않으며, 수중이나 고온에서도 산화하지 않고 어지간한 화학 물질에도 반응하지 않는다. (뭐, 왕수 같은 일부 물질에는 녹지만) 제아무리 금이 보기에 아름다워도 공기 중에 조금만 놔 두자 쇠처럼 녹이 슨다면, 이 정도로 비싼 귀금속의 지위를 차지할 수 없을 것이다. 이렇듯 불변성 역시 금의 매우 중요한 특징이다.

금은 액세서리를 만들 때뿐만이 아니라 그 안정성과 불변성 덕분에 치과 의료용으로도 쓰이고, 전기적 특성 덕분에 손전화 같은 전자 기기에도 소량 들어간다. 오죽했으면 그런 반도체 기판을 만드는 회사에서 수거되는 금을 몰래 빼돌린 직원이 경찰에 잡히기도 했을 정도이다.

태양계 바깥으로 떠난 우주 탐사선 파이어니어 10호와 11호에는 혹시 외계인이 발견하면 보라는 의도로 지구의 위치와 인간의 모습 등이 새겨진 일명 ‘파이어니어 금속판(Pioneer plaque)’이 장착되었는데 이 금속판의 재질은 알루미늄에다 금 도금이다. 11호에는 아예 금으로 만들어진 LP 음반까지 들어있다(지구의 소리 수록). 그야말로 지금까지의 인류 역사보다 더 긴 시간 동안 여행할지도 모르는데 변질되지 말라고 비싸고 무거운 금을 쓴 게 틀림없다.

또 금은과 비슷하게 안정적인 금속으로 백금이 있다. 백금은 촉매로도 실용성이 매우 뛰어난 금속이며, 백금과 이리듐(Ir)이라는 희소 금속과의 합금은 전자 장비의 접촉 부품, 만년필 펜촉 등으로도 쓰이고 측정 기기의 재질로 활용된다. 특히 과거에 킬로그램 원기, 미터 원기 같은 물건도 안정성 덕분에 이 합금으로 만들었을 정도이니 말 다 했다. 손전화 같은 정밀 전자 기기를 만들 때 쓰이는 이런 희소 금속들을 확보해 놓으려는 경쟁도 국가간에 치열하다고 소식을 전에 들은 것 같다.

은만 있는 게 아니라 수은도 있고, 금만 있는 게 아니라 백금도 있다는 게 흥미롭다. 백금과 은의 차이는 마치 여성 친구(female friend; 그냥 우정)와 여자 친구(girl friend; 애인-_-)의 차이인 것 같다. ^^;;

성경에는 예수님이 태어났을 때 동방 박사들이 그분께 바친 선물 세 종류 중에도 금이 있었다(마 2:11).
뭐니 뭐니 해도 황금 잔치가 벌어졌던 때는 솔로몬 왕 시절인데, 궁내 경비병들에게 지급된 방패의 재질이 금이었고 왕좌도 금이었으며, 왕이 사용하는 식기조차 다 금이었다! (왕상 10:14-22, 27)

은은 길거리에 굴러다니는 돌멩이마냥 흔해 빠졌고 아예  하찮은 것으로 여겨졌다니 믿어지는가? (왕상 10:27) 그때는 사실상 전세계의 모든 금이 예루살렘으로 몰렸다는 소리이다. 조금 상식이 있다면 불신자라도 666이라는 숫자가 아주 나쁜 의미로 성경에 나온다는 걸 알 텐데, 계시록에만 666이 있는 게 아니다. 1년 동안 솔로몬의 왕국으로 반입된 금의 무게가 666달란트(약 20~25톤)였다고 한다. 성경에서 666이 딱 두 번 이렇게 나온다는 게 아주 흥미로운 사실이다.

뭐 그래 봤자 금으로 도배를 해 놨던 성전과 각종 집기들은 이스라엘 민족이 망할 때 다 외적들에게 뺏겼다. 예수님은 헤롯 시절에 지어진 성전이 “돌 위에 돌 하나 안 남기고 다 무너질 것”이라고 예고하신 적이 있는데(마 24:2), 이것은 유대인들의 민족 자존심을 건드리는 발언이요, 마치 “제아무리 불침선 타이타닉이라고 해도 처녀 항해 때 싹 침몰해 버릴 것이다” 같은 메가톤급 예언이었다.
하지만 예언은 그대로 적중. 왜 성전이 돌 위에 돌 하나 안 넘기고 무너졌는가 하면, 탐욕스러운 적군들이 금을 추출하려고 돌을 하나하나 다 뒤지고 녹였기 때문이었다고 한다. 정말 ‘지못미 성전’이다.

그래도 안타까워하지 말자. 예수님께서 그 황금 잔치를 벌였던 솔로몬의 영광도 보잘것없다고 말씀하시며(마 6:29), 자신이 솔로몬보다도 더 큰 이(마 12:42)라고 소개하시기 때문이다. 그리고 구원 받은 크리스천이 하늘나라에서 살게 될 곳은 도시 전체가 맑은 유리 같은 순금일 테니 말이다(계 21:18).

이상, 4월의 마지막 블로그 포스트였다. ^^

Posted by 사무엘

※ 스크린도어

지금까지 전문 지하철 회사들에 비해 스크린도어 설치에 인색한 편이던 코레일도,
올해부터 전철 승강장 -- 그것도 분당선이나 과천선 같은 곳이 아닌 지상 승강장에 스크린도어를 설치하려는 움직임을 보이고 있다.
용산과 가산디지털단지 역에 설치 중인 걸 확인했고, 경인선은 역시 이용객이 많아서인지 송내 등 상당수의 역이 이미 공사가 시작되어 있다.

앞으로 이런 지상 국철 구간 승강장에서 일반열차가 주행하는 걸 촬영하기도 더욱 힘들어질 것 같다.
지하 구간인 분당선· 과천선· 일산선엔 저런 거 언제 들어오려나?

일본은 전동차 운전실 모습까지 유리창으로 보여준다. 대부분의 역에 스크린도어 같은 건 없다. 누가 승강장 투신 자살이라도 하면, 사회에 민폐 끼친 책임을 지라고 유족에게 되려 벌금을 매긴다. 이런 일본과 한국은 철도 인프라도 다르지만 그 문화 내지 정서도 상당히 다르다. ^^;; (일본이 운임도 더 비싸고 승객을 더 자비심 없이 대하고 더 짐짝 취급한다. 단지 철도로 갈 수 있는 곳이 더 많고 정시성이 더 뛰어난 정도?)

스크린도어 관련 추가 잡설:
- 가까운 미래에 개통을 앞두고 있는 용인 경전철은 이례적으로 스크린도어가 설치되지 않는다. 어차피 차량이 레일 위를 달리는 1량짜리 버스 수준에 불과한지라 선로 추락 사고가 나도 차를 급정거로 세우기 쉬운 편이며, 그런 사고라도 나면 무인 통제실에서 신속하게 대처가 되기 때문이라 한다.

- 아무리 그래도 차량 기지 임시역에까지 값비싼 스크린도어를 설치해 주지는 않는다. (7호선 장암, 9호선 개화) 그런데 광주 지하철 1호선의 녹동 역은 현재 국내에서 유일한 로프 셔터(?)가 설치되어 있다. 평소에는 이게 마치 상가의 셔터처럼 내려와서 승객과 선로 사이를 차단하고 있다가 열차 문이 열리면 그게 스르륵 위로 올라간다. 그러므로 선로와 승강장 사이에 공기는 통하기 때문에 열차풍 차단 효과는 없지만, 어쨌든 선로 투신은 확실하게 방지 가능하며, 로프 사이에다 카메라를 집어넣어서 선로를 촬영하는 것도 가능하다. 꽤 저렴하고 실속 있는 선택이라는 생각이 든다.

※ 중국· 일본어 안내방송

최소한 2009년쯤부터 SMRT 도철 5~8호선의 안내 방송에 묘한 변화가 생겼다.
잘 알다시피 환승역이나 비환승이더라도 이용객이 많은 주요역에는 중국· 일본어 방송이 추가됐다.
그리고 시종착역 뿐만 아니라 환승역 방송 후에도 일부 노선은 '5678 서울 도시철도' CM송이 끝에 추가됐다. 이 사실 자체에 대해서는 본인이 예전에도 비슷한 글을 블로그에 남긴 적이 있다.
그런데 재미있는 건 모든 노선에서 그러고 있지는 않다는 것.

(거의) 모든 환승역에서 중국어와 일본어 안내방송을 덩달아 하는 곳: 6, 7호선
5호선도 종로3가, 공덕, 광화문 등 주요역에서는 중국어와 일본어 방송을 하지만 왕십리 이후의 동쪽이나 여의도 이후의 서쪽에서는 하지 않는다. 하다못해 동대문역사문화공원 역에도 안 하며, 8호선에은 유일하게 그런 방송이 전혀 없다.

환승역 방송 후 "5678 서울 도시철도" 로고송이 나오는 곳: 7, 8호선
거 참 신기하지 않은지? 오로지 저 두 노선에서만 하고 있다.

따라서 이 두 방송을 모두 적극 실시하는 7호선이 안내방송 러닝 타임이 제일 길어져 있다.
본인은 시도 때도 없이 서는 지하철에서 일일이 4개 국어 방송이 다 나가는 거 별로 찬성은 안 한다. 역 안내 방송은 언어가 중요한 게 아니라 역명이라는 고유명사--특정 언어와 별 관계가 없는--가 더 중요한데 굳이 일일이 외국어 번역을 할 필요도 없는 것이고..
차라리 공항 철도가 4개 국어를 다 방송하는 건 말이 된다. 거기는 음성뿐만 아니라 LED 화면 자막까지 4개 국어로 해 주고 있으니 말이다. 더구나 역 간격도 일반 지하철보다는 훨씬 길기 때문에, 4개 국어 방송을 내보낼 시간적 여유도 되니 말이다.

Posted by 사무엘

※ 2000

일반 사용자를 대상으로 NT 커널과 9x 계열의 통합을 야심차게 기획했던 운영체제이다.
하지만 윈도우 디렉터리의 이름은 여전히 Windows가 아닌 WinNT였고, 특이하게도 마우스 포인터의 이동 자취(trail)를 남기는 기능이 없었다. 9x 계열은 말할 것도 없고 구닥다리 윈도우 3.1조차 갖추고 있는 기능인데 NT에서만 원래 없었던가? 물론 XP부터는 이 기능이 있다.
탐색기에서 wav/mp3을 클릭 후 바로 재생이 가능하던 유일한 운영체제이다.

그리고 2000부터 GUI의 표준 색상이 약간 바뀌었다. 그저 RGB(192,192,192)이던 회색은 살짝 더 누르스름하게 바뀌고, 파랑은 좀더 어둡고 군청색에 가깝게 바뀌었다.
그런데 유독 윈도우 2000만.. 스타크래프트 같은 256색 전체 화면에 들어갔다가 나오면 그 파란색이 예전의 덜 어두운 색으로 돌아가는 신경 쓰이는 버그가 있었다. 이 역시 ME라든가 XP 이후부터는 전혀 발생하지 않으며 윈도우 2000만의 문제. 후대의 추가 최신 업데이트까지 다 받으면 어찌 될지 모르지만, 아무튼 SP4까지 가도록 이 문제는 고쳐지지 않았다. 2000만의 고질병으로 기록될 듯.

(이해를 돕기 위해 스크린샷을 첨부하자면, '위'가 '아래'로 바뀐다는 뜻이다. RGB(10,36,106)이 RGB(0,0,128)로 변경. 본인에게는 정말 바로 티가 나고 아주 거슬리는 버그였던 반면, 저 버그에 대해서 공감하는 사람은 주변에서 지금까지 전혀 보지 못했다. 윈도우 2000 쓰면서 스타도 띄워 본 적 없나??)

※ XP

1. 유저 인터페이스가 파격적으로 많이 바뀌었다 보니 초창기 SP0은 별 특이한 버그가 많았다.
스트링을 내장하고 있지 않은 리스트박스나 콤보박스는 LB_ADDSTRING 내지 CB_ADDSTRING 메시지로 아이템을 추가할 때 당연히 string을 NULL로 지정해도 괜찮은데, 새로운 비주얼 스타일(테마)이 적용된 컨트롤은 저렇게 하면 프로그램이 죽는 어이없는 버그가 있었다. -_-;; (비주얼 스타일 없는 옛날 컨트롤은 문제 없음)

95부터 2000/ME까지 아무 탈 없던 코드가 유독 XP에서만 문제를 일으킨 것. 과거 <날개셋> 한글 입력기 2~3.x 시절에 윈도우 XP (sp0)에서 일부 제어판 UI가 뻗던 문제는 이 문제 때문이었다. 매우 황당한 버그이기 때문에 이 문제는 SP1에서 곧바로 고쳐졌다.

2. XP부터는 응답이 없이 죽은 윈도우는 대책 없이 배째라 있는 게 아니라, 최소한 창의 이동과 강제 닫기는 가능한 일명 고스트 윈도우를 그 프로그램의 원래 윈도우를 대체하여 잠시 보여주는 기능이 추가됐다. 그래, 만든 취지는 좋다.

그런데.. 최대화되어 있던 프로그램 창이 한동안 응답이 없어서 고스트 윈도우가 됐다가... 다시 돌아와서 깨어나면,
그 창의 최대화 이전의 위치와 크기가 사라지고 창의 최대화를 해제해도 창 크기 자체가 최대화나 마찬가지인 상태로 남는 버그가 있었다. -_-
이 문제 역시 SP1을 전후한 시기에 고쳐졌다.

3. SP0은 무선 인터넷을 좀 하다 보면 lsass던가 뭐가 이상한 시스템 프로그램이 문제를 일으켜서 1분간 초 단위로 카운트다운을 한 후 운영체제가 재부팅되는 현상도 있었다. -_-;;
갑자기 그런 게 떠서 놀랐고, SP1만 설치해도 그 문제가 없어지는 것을 보고는 더 놀랐다. 도대체 SP0에서는 무슨 문제가 있었기에?

이외에 다른 사람들은 XP에서 시스템 차원에서 첫 도입된 TSF와 관련된 문제(ctfmon) 등 여러 버그를 찾아낸 듯하던데(해결책이라고 내놓은 게 '고급 텍스트 서비스 사용 안 함' ^^), 본인은 그런 건 모르겠고 저 세 가지 버그가 지금까지 기억에 남는다.
SP2는 저런 사소한 버그 해결 수준이 아니라 보안 관련 기능 추가가 즐비해서 단순 서비스 팩 같지가 않고,
SP3은 제대로 쓸 일도 없이 그 즈음에 비스타로 갈아타게 돼서 잘 모르겠다. SP2 정도만 해도 사실 상당히 안정화가 돼 있으니까.

※ 비스타

굉장히 오랜만에 출시된 만큼 엄청나게 높아진 사양, 그리고 디폴트로 적용돼 있는 UAC (사용자 계정 컨트롤) 때문에 뭇매도 많이 맞았다. 하지만 비스타는 객관적으로 상당히 잘 만든 OS이며, 7에 비해서 그 정도로 평가절하될 품질은 결코 아니다. 윈도우 98이 단순히 95+IE4가 결코 아닌 것과 같은 이치이다.

본인은 language bar (TSF 도구모음줄, 입력 상태 표시줄)를 task bar(작업 표시줄) 내부에 포함(embed, minimize)시키는 게 아니라 바탕화면에 동동 띄워 놓고 지낸다.
그런데 유일하게 비스타에서만 구경한 버그로는.. 응용 프로그램을 좀 사용하다 보면 이 language bar가 사라져 버리고 아마 내 기억이 맞다면 한글 입력도 안 되는 것.
내 컴만 그런가.. 왜 그런지 좀 성가시고 불편했다. 윈도우 시스템 디렉터리로 가서 ctfmon.exe를 재실행하면 사라졌던 language bar가 살아났다.

이것도 요즘은 구경을 안 하는 걸 보니, 다행히 서비스 팩을 설치하는 과정에서 고쳐진 것 같다.
엑셀 2007에서 유명하던 65535 곱셈 버그가 생각난다.
예전에 MS의 정책은 SP n은 SP n-1을 다 포함하는 형태였던지라, 최신 서비스 팩 하나만 갖고 있으면 됐다. 비주얼 C++ 6이라든가 윈도우 NT는 패키지 프로그램을 설치 후 최신 SP인 SP6만 깔면 끝이었던 것.

그런데 윈도우 비스타부터는 SP2를 깔려면 먼저 SP1부터 깔아야 한다. 매번 꽤 오래 시스템 파일 고치고 재부팅하고.. 불편하더라.
그래도.. 본인은 보안 업데이트는 귀찮아하는 편이지만, 서비스 팩은 그때 그때 깔 필요가 있다는 걸 체험 중. 왜냐하면 내가 현실적으로 직접 겪는 버그가 서비스 팩을 통해 곧장 해결된 경우를 꽤 자주 겪었기 때문이다.
듣기로는 비주얼 스튜디오 2010을 설치하려면 비스타조차도 SP1 이상이 필요하다.

아 그리고.. 윈도우 비스타 SP0은 인증 기간이 끝나면 대놓고 작동이 완전히 맘춰 버리는 유일한 운영체제이기도 했다. 기능 제한 모드가 되어, 인증을 받게 인터넷 접속이 가능한 웹브라우저 하나만 달랑 뜨고 다른 모든 기능을 사용할 수 없었다. 이 때문에 항의가 빗발쳤는지 SP1부터는 바로 사라지고 이는 후속작인 윈도우 7도 마찬가지. 화면이 주기적으로 까맣게 변하고 '이 제품은 정품이 아닙니다' 자막만 뜰 뿐, 동작 자체는 한다.

※ 7

콘솔에서, 한글을 조합 중이다가 비조합 문자를 “IME 차원에서” 삽입하면 조합 중이던 문자가 덧나는 버그가 있다. 이건 <날개셋> 문제가 아니라 MS IME에서도 나타나는 운영체제의 버그이다.
가령, "다"를 조합 중에 마침표를 누르면 "다."가 아니라 "다다."가 되는 것.

MS IME의 경우 두벌식일 때는 발생하지 않는다. 두벌식은 A~Z 사이에 배당된 한글 글쇠만 IME 차원에서 삽입하고 여타 숫자나 기호는 영문 자판과 동일한 방식으로 별다른 터치 없이 응용 프로그램으로 보내기 때문이다.
과거에 포트리스 space 버그를 비롯해서 MS IME가 유독 세벌식 자판에서만 발생하는 버그가 심심찮게 발견됐던 이유는 이런 동작 방식의 차이 때문이다. 세벌식은 아는 사람도 쓰는 사람도 거의 없다 보니 버그 발견이나 수정도 금방 금방 되지 않을 것이고.. -_-

이제 문자 입력 쪽 기능은 비스타 이후로 좀 안정화가 돼 있길 바랐건만, 또 뭘 건드려서 저런 버그가 생겼는지 모르겠다. SP1에서라도 당장 고쳐져 있길 기대한다.

Posted by 사무엘

1. 과학 하는 마음으로 능률 있게 일하고
사람마다 손에 손에 한 가지씩 기술 익혀
부지런한 하루하루 소복소복 부는 살림
세상에 으뜸 가는 복된 나라 이루세

2. 과학으로 이치 찾아 새로운 것 발명하고
겨레의 슬기 모아 산업 크게 일으켜서
천 불 소득 백 억 수출 무럭무럭 크는 국력
세상에 으뜸 가는 힘 센 나라 이루세

3. 과학 하는 국민으로 기술 가진 국민으로
살림살이 늘려 가고 산업 크게 일으키면
나라의 힘 용솟음쳐 다가오는 평화 통일
세상에 으뜸 가는 민족 중흥 이루세

이 노래 아시는 분?
1970년대에 제정된 과학의 (날) 노래이다.
정말 "새벽종이 울렸네 새 아침이 밝았네" 만만찮게 그 시절 냄새가 아주 노골적으로 난다.

(박 정희는 교사 출신이고 음악· 미술 같은 예능에도 조예가 깊은 사람이었다. 본인은 개인적으로 <새마을 노래>-_-는 누구 대필이 아니라 그 사람이 진짜로 스스로 작사· 작곡했을 가능성이 높다고 생각한다.)

3절의 '민족 중흥' 하면 생각나는 거 없는지?
국민 교육 헌장에서 말고는 요즘 도무지 찾을 수가 없는 단어인데, 그때 '그분'이 저 표현을 정말 좋아했던 것 같다.
'국민 소득 1천 달러, 수출 100억 달러' 이런 가사는 정말, 철도의 노래로 치면 '지축을 흔드는 우렁찬 소리' 급의 옛날 추억이 돼 있다.

4월 19일은 우리나라에서 4 19 혁명일일 뿐만 아니라 찰스 다윈이 세상을 떠난 날이다.
(다른 훌륭한 과학자도 많은데 왜 하필 다윈이야.. -_-)
우리나라에서 과학의 날은 일제 강점기이던 1934년에 다윈의 기일을 기려 처음 시작됐다.
소파 방 정환 선생이 제정한 어린이날보다 약 10년 정도 늦게 시작된 것이다.
그러다가 과학 기술처가 발족된 4월 21일을 기려, 1968년부터 과학의 날이 재제정되었다. 참고로 국민 교육 헌장은 1968년 12월에 공표되었다.

본인은 저런 노래를 어떻게 아냐고?
엄청 어렸을 때 옛날 국민(초등)학교 음악 테이프에서 들었던 노래들은, 죽을 때까지 안 잊어버리고 기억하고 있어서이다. 머릿속 시스템 디렉터리에 known DLL로 등록됐다. ㅋㅋㅋㅋ
딱 초등학교에 입학할 때 이미 '읍니다'는 '습니다'로 바뀌어 있었고 국민 교육 헌장도 다 삭제되었지만, 그렇게 바뀌기 전의 교과서들을 본 기억은 있다. 정말 엄청난 옛날이 됐다.

본인은 딱히 수꼴 성향이거나 박통교-_- 신자는 아니다.
그러나 그 시절은, 이공계 과학 기술자가 "지금보다야" 정말 대접 받았으며, 긍지를 갖고서 마음껏 국가를 위해 일하던 시절이었을 거라고 생각한다.
그 반면 지금은? 현직 과학자들부터가 "내 자식 새끼는 절대로 이공계에 진학 안 시킬 거다" 그러는 시절이지 않은가!

  "그 어려운 살림에서도 박대통령은 과학 기술자들에게 파격적인 대우를 해줬다. 틈만 나면 과학기술자들 곁을 찾았다. 과로로 숨진 과학자들도 여러 명이나 됐다. 대전에 있는 국방과학연구소에는 그가 며칠씩 머물던 방이 하나 있었다. 그 방은 과학기술에 대한 그의 일선 지휘소였다. 그러나 그가 가고 난 지금까지 그 방을 찾는 사람은 아무도 없었다. 나머지 대통령들에겐 입으로만 과학이 중요했다."

아무리 지 만원 박사의 정치 성향이 싫다 하더라도 위의 내용만은 인정할 수밖에 없을 것이다.
특히 국방 과학 연구소는 정말 사기에 가까운 업적으로 지금까지 우리나라를 먹여 살리고 지키고 있는 곳 중 하나이다. 작년에도 과로로 순직한 분이 있었다!
나라가 잘 돌아가고 있을 때는 의료· 법조· 금융 같은 제로썸 산업 종사자가 아니라, 기술자가 늘 대접을 받았다.

  또 예루살렘에서 솜씨 있는 사람들로 하여금 기계(engine)들을 만들게 하여 망대와 보루 위에 두고 그것들로 화살과 큰 돌을 쏘게 하였더라. 그의 이름이 멀리 퍼졌으니 그가 놀랍게 도움을 받아 마침내 강하게 되었더라. (대하 26:15)

성경에서 역대기하 26장의 웃시야 왕의 업적을 읽어보면 정말 우리나라가 농업 개량을 하고 경제 개발하고 국방을 강화하던 1960~70년대 시절이 오버랩된다. 웃시야 왕은 교만으로 인해 비참한 최후를 맞이한 것도 박통과 일치하는 것 같다.

본인은 요즘 우리나라가 중산층이 몰락하고 빈부 격차 양극화가 심해지고 있다고 성토하는 사람에게 이렇게 묻는다. 그럼 이 땅에 중산층이 생기긴 언제 생겼냐고 말이다.
과학과 관련된 노래로 옛날에 드라마 카이스트 주제가가 생각나고, 대전 엑스포 주제가도 생각난다. 코리아나는 영 건전 가요 컨셉인 것 같다. 88 올림픽 주제가에 비해서 그리 잘 알려져 있지 않은 후자의 가사를 소개하며 글을 맺는다.

푸른 산들은 우리에게 말하네 고운 햇살 뿌려 달라고
이제 모두가 슬기로운 손길로 밝은 내일 꾸며 가 보자
아름다운 마음 마음 모여서 사랑으로 보살펴 주면
꿈이라고 생각했던 일들이 우리 앞에 펼쳐진다네 그 날은

우리 모두가 힘을 한데 모아서 끊임없이 달려 가 보자
하루하루가 다시 열릴 때마다 놀랄 일이 너무도 많아
우주 안에 감추어진 비밀을 차근차근 벗겨 가 보면
꿈이라고 생각했던 일들이 우리 앞에 펼쳐진다네 그 날은

그 날은 찾아오리라 그 날은 찾아오리라
미래의 물결 속에서 그 날은 찾아오리라 그 날은, 그 날은

Posted by 사무엘

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Posted by 사무엘

<날개셋> 편집기를 오래 써 온 분들은 아마 아실 겁니다. 찾기/바꾸기 대화상자에 아주 교묘한 버그가 있습니다.
글을 쓰다가 Ctrl+F 또는 Ctrl+H로 이 대화상자를 한 수십 번 꺼내다 보면
정말 가끔, 아주 random한 확률로 엉뚱하게 explorer.exe가 죽거나, 편집기 프로그램이 죽거나 응답 불능 상태에 빠집니다. 윈도우 XP부터 비스타에서 모두 이런 증상이 나타나는 걸 확인했습니다. 에러 대화상자를 살펴보면 comctl32.dll이 뻗었다고 나옵니다.

이건 저도 원인을 알 수 없고 참 괴이하기 그지없는 버그입니다.
딱 원하는 때에 맞춰 재연은 절대로 할 수 없지만, 그래도 어디서나 언젠가는 100% 반드시 나타난다고 보장할 수 있는 현상이었지요.
발생 조건에 관한 한 최악의 버그입니다. 저는 무려 <날개셋> 3.x 시절부터 이것에 대해 알고 있었지만 디버깅할 엄두를 못 내고 있었습니다.

찾기/바꾸기 대화상자가 <날개셋> 편집기의 여느 대화상자들과 다른 점은 '탭 컨트롤'을 써서 찾기와 바꾸기 기능을 구분하고 있다는 점입니다. 혹시 이게 문제인가 싶어서 이번 기회에 아예 대화상자의 디자인을 바꿔 버렸습니다. 물론 5.53에는 아직 이게 적용이 안 돼 있고요.
5.53 이후로 다음 버전이 언제 나오게 될지 모르겠지만, 이렇게 하니까 이제는 저 문제가 없어졌는지 최소 몇 달간 살펴볼 예정입니다.

Posted by 사무엘