« Previous : 1 : ... 171 : 172 : 173 : 174 : 175 : 176 : 177 : 178 : 179 : ... 221 : Next »

개발자의 수명이 짧은 이유

세상에는, 인생의 보편적인 패턴이긴 하지만 우리나라에서 유독 강박관념에 가까울 정도로 심하다고들 하는 현상이 있다.
사람은 어느 분야에서든 젊을 때는 현역-_-에서 시간과 노력을 투자하여 몸 쓰면서 열심히 뛰고 일해서 결과물을 내고 돈과 명성을 끌어 모은 뒤,
나이가 들어서 노련하긴 하지만 몸이 예전만치 말을 안 듣고 밑으로 뛰어난 신참 후배들이 계속 들어올 무렵이 되면, 관리자, 해설자, 감독· 코치 등으로 물러나거나, 지금까지 모은 밑천으로 남을 부려 쓰면서 자기 사업을 한다는 것. 뭐, 이건 자연스러운 현상이긴 하다.

자율적이든 타율에 의해서든 뭔가를 열심히 만들던 위치이던 게 이제는 남에게 뭘 만들지 지시를 내리고, 그 과정을 관리하고, 남들이 만들어 놓은 걸 그냥 평가만 하면 되는 위치가 된다. 그거야말로 아무나 할 수 있는 일이 아니기도 하니까.
이제는 오히려, 체면과 위계질서 같은 여러 가지 이유 때문에, 자기는 현장에서 뛰고 일하고 뭔가를 ‘만드는’ 자리로는 가고 싶어도 갈 수가 없다. 후임에게 그 일을 완전히 맡기고, 간섭을 하지 말아야 한다.

전산학 개념으로 설명하자면,
‘X라는 input에 대해서 Y라는 조건을 만족하는 solution Z를 다항 시간 만에 찾으시오(찾는 알고리즘을 고안하시오’
에서
‘X라는 input에 대해서 어떤 solution Z가 있을 때, 그게 Y라는 조건을 만족하는지 다항 시간 만에 검증하시오’
로 바뀌는 셈이다. 결정성 튜링 기계(DTM)가 비결정성 튜링 기계(NDTM)로 바뀌었으니, P와 NP가 동치이지 않은 한, 일이 편할 수밖에 없다.

난 대학이든 대학원이든 학교를 다니면서 교수들에 대해 무척 놀라는 면모가 있었다. 첫째는 특강 시간에 학생들이 무슨 주제로 발표를 하더라도, 심지어 발표 자료를 미리 올리지 않았더라도, 교수가 즉석에서 발표 내용에 대해 코멘트를 하고 그 바닥 사정이 어떤지 보충 설명을 주절주절 늘어놓는다는 것이다.
그리고 둘째는, 교수는 전산학과 교수라 해도 코딩에는 이제 진짜 전혀 신경 안 쓴다는 것. 이런 게 진정한 지도자 내지 사장· 상사 마인드인 건가 하는 생각이 들었다.

가령, 축구야 워낙 선수의 체력이 생명인 과격한 스포츠이다 보니 선수의 현역 수명이 굉장히 짧다. 그런데 프로그래밍이라는 업무, 또는 개발자라는 직위는 과격한 스포츠가 전혀 아닌데 적어도 한국에서는 여전히 수명이 짧다. 그 나이가 되도록 아직도 개발자라고 하면 이상하게 본다.
왜 그런 걸까? 한국에는 왜 노짱 개발자가 없는 걸까? 물론 이 바닥이 워낙 변화가 빠르고 날고 기는 친구들이 너무 많은 분야여서 그럴 수도 있다. 그러나 그건 우리나라 사정만 그런 건 아닐 텐데 말이다.

문득 드는 간단한 시나리오로는... 1인 개발자가 프로그래밍만으로 먹고 사는 인프라가 마련돼 있지 못해서--극심한 불법복제, 개인 개발 작품의 품질 보증 문제 등의 여러 구조적인 문제-- 결국 프로그래머의 밥줄은 프로그래머 자신이 아니라 그 프로그래머를 이용하는 다른 경영자에게 달리게 되고, 그런데 그 경영자는 사업가· 장사꾼일 뿐이지 프로그래밍 바닥을 잘 모르는 사람이고.. 그 뒤 더 이상의 자세한 설명은 생략..;; 이런 식으로 개발자에게 불리한 IT 시스템이 생긴 게 아닐까 한다. 어휴.

빵집의 개발자인 양 병규 씨는 개인 블로그에서 안 철수 씨가 백신 개발자로 남지 않은 걸 개인적으로 아쉬워한다고 썼었다. 물론 안 씨야 백신만 파기에는 너무 아깝고 대학 교수에, 장관에 뭘 해도 이상할 게 없는 넘사벽 천재 만렙 완전체이긴 하다만... 그래도 그 근성으로 백신 하나만 밀었다면 지금 여타 보안 솔루션들을 모조리 떡실신시키는 보안 귀재 장인이 되지도 않았을까? (그분이 안랩을 떠난 후 거기가 예전만 한 명성을 유지하지 못하고 있는 것도 사실이고)

본인은 프로그래밍을 좋아한다. 까놓고 말해 <날개셋> 한글 입력기 한 8.0~10.0까지 만들고 리눅스나 맥용도 응당 만들고 싶다. 여러 분야를 총괄하는 게 아니라 좁은 분야 하나만 스페셜리스트로 미치도록 파는 걸 좋아한다. 그렇다고 해서 노가다 코더 타입도 절대 절대 아니다. 군대로 치면 ‘장군’보다는 ‘준위’형 인물이다.

허나, 이거 개발을 언제까지 할 수 있을지 생각하면 한숨이다. ㄲㄲㄲㄲ 아직 갈 길이 먼데... 나 같은 사람이 종사할 만한 업종이 있으려나? -_-
결국은 역시나 돈 문제, 영적으로는 사회의 구조적인 죄 문제와 연결되는 걸 느낀다. 죄가 만연한 사회일수록 결국 일하고 생산하고 연구하는 업종보다는, 인간의 죄를 제어하고 다스리고 통솔하는 업종의 비중이 더 커지고 그 업종과 여타 업종간의 빈부 격차도 커지게 마련이기 때문이다.

Posted by 사무엘

2011/07/23 08:36 2011/07/23 08:36
, ,
Response
No Trackback , 7 Comments
RSS :
http://moogi.new21.org/tc/rss/response/544

독특한 크리스천

※ 이 승만

크리스천답게 술· 담배 안 하고 사생활 깨끗했다. 대통령이 된 뒤에도 관료들 회식 때, 기생 대신에 각자 자기 부인을 데려 오게 한 사람이다. 여대생· 여배우 끼고 술판을 벌이던 박 정희와는 완전히 다른 타입.

그에게는 프란체스카 이전에 엄청 옛날에 조혼했다가 헤어진 조선인 전처가 있었고 나중엔 임 영신 같은 사람과 스캔들 루머가 나돌기도 했으나, 루머는 루머일 뿐이다. 이 승만은 자기는 이미 유부남이라고 오히려 임 영신을 찼으며, 불륜을 원천적으로 저지르지 않았다. 전처와의 흑역사는, 마치 성경 시대에 일부다처가 용인되었던 것만큼이나 당시 정황상 어쩔 수 없는 것이었고.

이는 같은 크리스천이고 똑같이 천재 엄친아이던 여 운형과는 좋은 대조를 이뤘다. 여 운형은 왕년에 여자들 끼고 바람 잔뜩 피웠던 호색한.. ㄲㄲㄲㄲ
김 구도, 여 운형도, 이 승만도 다 명색이 기독교 신자인 민족 지도자였지만, 이들이 정치적으로 간 노선은 잘 알다시피 스타크래프트 세 종족 내지 윈도우/맥/리눅스만큼이나 서로 달랐다.

※ 차 지철

알고 보니 상당히 특이한 사람이다. 박 정희 전대통령의 경호실장으로 무소불위의 권력을 누리면서 박통의 다른 부하들로부터조차도 미움을 살 정도였고, 결국 10. 26. 사태 때 박통과 함께 김 재규의 총에 맞아 죽었다는 건 잘 알려진 사실이다만... 이 양반도 의외로 상당히 독실한 '신자'였다고 한다.

'각하'에게는 예쁜 연예인들 데려 와서 시중 들게 했어도 자기 자신은 부인 말고는 다른 여자를 거들떠보지도 않았다. 늙은 어머니에게 극진한 효자였으며, 의외로 비리와도 담을 싼 타입. 은행 대출 청탁을 받자, 의뢰인과 함께 기도실에 들어가 기도만 한 후 청탁은 들은 체도 안 했다는 흠좀무스러운 일화가 전해진다. 꿍쳐놓은 재산이 없이 청렴했다는 건 사후에 그의 유족들에 의해 잘 입증되어 있고... 지나쳤던 권력욕만 빼면 사후 평판이 싹 달라졌을 사람이다.

※ 조지 W. 부시

길게 설명하지 않겠다. 사생활에 관한 한 클린턴과 180도 다른 타입인 건 두말 할 나위도 없고, 모 목사님의 증언에 따르면, 재임 중에 백악관으로 인턴 온 어느 학생에게 “학생은 예수 그리스도를 구주로 개인적으로 영접했나요? 만약 그렇다면 백악관 직원들이 참석하는 기도 모임에 나랑 같이 가지 않을래요?” 같은 말까지 했다고. 개인적으로 만날 때야 부시만치 다정하고 공손하고 정중한 사람이 별로 없었댄다. -_-;;

내가 몇 차례 글로 썼듯이 저 사람은 약간 띨띨하고 어렸을 때 좀 놀기도 했다가, 교회 다니면서 신앙의 힘으로 '교화'되고 나서 그나마 저렇게 바뀌고 나중에 미국 대통령까지 한, 유능보다는 '그냥 착한 사람' 타입이다.

※ 스티브 유

담배 끊은 걸로 금연 홍보 대사도 하고, 여타 연예인들과는 달리 사생활 깨끗하고, 교회 다니는 거 공언도 하고 다니고... 거기에다 노래와 춤은 덤. 20세기 말까지만 해도 가히 아름다운 청년이라는 타이틀이 아깝지 않은 연예인이었는데...

그 후 이미지 완전히 말아먹고 한국에 못 들어오는 미국인이 되어 버린 건, 누가 봐도 자업자득이고 욕 얻어먹어도 싸다. 동정표를 줄 수가 없다. 워낙 이미지가 좋아서 병무청에서도 그를 믿고 병역 미필자로서 미국에 선뜻 보내 줬는데 거기서 정면으로 배신을 때린 거니까. 어차피 4급이어서 현역 가지도 않았을 사람이 왜 그런 식으로 병역을 회피했는지 모르겠다. 한국의 남자들이 군대에 대해서 얼마나 민감하고 피해의식을 갖고 있는지를 잘못 짚었다. -_-

.
.

뭐, 예수 믿는다는 사람 중에도 일반 불신자와 똑같이 행동하고, 특히 불륜 저지르고 가정 말아먹은 사람이 많다. 이것 때문에 파면-_-당한 목사 내지 CCM 작곡가 겸 가수도 부지기수이고..
하지만 위에서 열거한 네 사람은, 대외적으로 자기 종사 분야에서는 욕 얻어먹을 짓을 좀 했고 잘못을 저지른 것도 있지만, 의외로 개인과 가정의 측면에서는 예수쟁이로서의 간증을 꽤 잘 지켜서 두 분야가 서로 잘 어울리지 않는 사례이다. 뭐, 사생활만 깨끗하다고 해서 대외적으로 무능하거나 욕 먹을 짓을 한 게 용서되지는 않겠지만. -_- 그래도 세상에는 한 잣대만으로는 제대로 평가하기 곤란한 사람이 많다.

Posted by 사무엘

2011/07/19 08:45 2011/07/19 08:45
, , , ,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/542

예전에 본인이 글로 쓴 적도 있고, 상식 차원에서 이미 아시는 분도 있겠지만..
프로그래밍 언어마다 문자열을 다루는 방식엔 차이가 존재한다.
C/C++은 null-terminated 문자열이라는 단순하고 독특한 체계를 사용하는 반면, 다른 언어들은 그렇지 않다.
그렇기 때문에, 문자열 상수가 실행 파일 내부에 어떤 형태로 박혀 있는지를 추적하면, 이 프로그램이 무슨 언어로 만들어졌겠는지 추측이 어느 정도 가능하다.

과거의 도스 시절에는 볼랜드 사에서 개발한 터보 시리즈의 컴파일러가 인기가 많았다. C/C++과 파스칼이 기억에 남는다. 이 볼랜드 제품은 당시 타사의 컴파일러가 제공하지 않던 두 가지 독자적인 기능이 있었다. 하나는 깔끔하게 잘 만들어진 IDE(에디터)였고, 다른 하나는 BGI(볼랜드 그래픽 인터페이스)라고 일컬어지는 그래픽 API였다.

한 IDE에서 프로그램을 바로 빌드-실행-디버그할 수 있으니 프로그램 개발 생산성이 뛰어나고 굉장히 편리하다. 이에 덧붙여, 그래픽은 그렇잖아도 printf 같은 표준화된 API 규격이 전무해서 ‘싸제’ 라이브러리에 의존할 수밖에 없던 영역인데, 자체 개발 라이브러리가 있다 보니 볼랜드의 컴파일러는 폭발적인 인기를 모을 수밖에 없었다.
bgidemo라고 유명한 그래픽 API 예제 프로그램도 있었는데 기억하는 분이 있으려나 모르겠다. QBasic용 예제 프로그램인 nibbles, gorilla 게임과 비슷한 시기에 만들어진 그 시절 추억이다.

사용자 삽입 이미지

아래의 스크린샷은 이 BGI 라이브러리를 사용해서(=링크해서) 만들어진 어느 EXE 파일 내부를 들여다본 모습이다. 그래픽 라이브러리이다 보니 내부적으로 출력하는 에러 메시지 문자열, 가령 No error, (BGI) graphics not installed, 심지어 Out of memory in flood fill 같은 친숙한 문자열이 내장되어 있음을 알 수 있다. 그런데 동일한 문자열들 사이에 한 놈은 ▲, →, ← 같은 이상한 기호가 듬성듬성 끼어 들어가 있다. 왜 그럴까?

사용자 삽입 이미지

사용자 삽입 이미지

기호가 없는 프로그램은 C언어(=터보 C)로 만들어진 프로그램이다. 왼쪽의 16진수값을 보면 알겠지만, 이들은 모든 문자열들이 그냥 0번 문자로 구분되어 있다.
그러나 기호가 있는 프로그램은 파스칼로 만들어진 프로그램이다. ▲, →, ←은 다음에 뒤따르는 문자열의 길이를 의미한다. 예를 들어 “▲Graphics hardware not detected”를 보면 ▲의 코드 번호는 0x1E, 즉 30인데 그 에러 메시지의 길이는 30바이트임을 알 수 있다. 얘네는 반대로 문자열들 사이에 0번 문자가 전혀 존재하지 않는다.

실제로 C/C++ 말고 String이 built-in type으로 존재하는 언어들은 이렇게 글자 수를 따로 저장해 놓는 방식으로 문자열들을 관리한다. 베이직으로 만들어진 프로그램도 QuickBasic이든 PowerBasic이든 문자열 상수들을 들여다보면 비슷한 결과를 얻을 수 있다. 그래서 이런 언어는 문자열의 길이를 구하는 함수의 시간 복잡도가 O(1)인 반면, C언어만 strlen의 시간 복잡도는 O(n)이다.

베이직 언어들은 문자열의 길이가 16비트 정수로 저장되던 반면, 터보 파스칼은 문자열 길이를 달랑 8비트 크기로 저장하여, 문자열의 길이가 256자를 넘을 수 없다는 한계가 존재했다. 흠;;

파스칼로 만든 프로그램을 들여다보면 Runtime error 같은 문자열도 존재한다. 이 역시 C/C++로 만들어진 프로그램에서는 디버그 빌드가 아닌 이상 있을 수 없는 개념이다. C/C++은 배열 첨자 범위의 검사조차도 안 할 정도로 런타임 에러라는 개념 자체가 존재하지 않는-_- 언어이기 때문이다. 그저 컴퓨터 다운(도스 시절)이 아니면 segmentation/page fault(요즘 같은 보호 모드 운영체제에서)-_-만이 존재할 뿐. -_-;;

그 반면, %d, %s이라든가 Null pointer assignment 같은 문자열이 있다면 그건 99.9% C 라이브러리가 들어갔다는 뜻이고 그 프로그램은 C/C++로 작성되었다고 유추할 수 있다.

덧붙이는 말

1. 볼랜드는 BGI 라이브러리만큼이나 텍스트 모드용 GUI? TUI? 툴킷으로 Turbo Vision이라는 라이브러리를 개발한 것으로도 유명했다. MS가 도스용 비주얼 베이직을 잠시나마 개발했다면 볼랜드에는 이런 게 있었던 셈. 당장 터보 C++과 파스칼의 IDE부터가 이를 사용해서 개발되기 시작했다. 비록 C/C++과 파스칼에서 모두 지원되긴 했지만 이 언어의 주 개발 및 지원 언어는 파스칼이었지 싶다. MS가 베이직을 좋아한다면, 볼랜드는 전통적으로 파스칼을 더 좋아하는 회사였다. (그러니까 훗날 델파이까지 만들었지)

지금은 세월이 세월이다 보니 소스가 완전히 풀려서 이이 프로젝트는 오픈소스 진영에서 관리되고 있다. 내 기억이 맞다면 DJGPP의 IDE인 Rhide가 이 Turbo Vision의 오픈소스 버전으로 개발되었다.
그리고 우리나라에서 PC 경진대회가 정보 올림피아드로 최초로 바뀌었던 1996년(13회), 대회의 채점 프로그램이 Turbo Vision 기반으로 개발되어 있던 걸 본인은 분명히 봤다.

2. 오늘날 윈도우용 네이티브 EXE/DLL이 만들어지는 출처는, 내 감으로는 비주얼 C++이 적게 잡아도 70% 이상, 그 뒤에 소수의 오픈소스 프로젝트용으로 gcc, 그리고 끝으로 델파이 정도가 고작인 것 같다. 볼랜드는 그 후로 다른 회사에 인수되면서 이름도 여러 번 바뀌고(InPrise, CodeGear, Embarcadero 등...;;) 우여곡절을 많이 겪었는데 걔네 입장에서는 옛날의 영광이 그리울 법도 할 것 같다.

3. BGI 라이브러리와 파워베이직--얘 역시 전신이 볼랜드 사의 터보 베이직이긴 했지만--의 그래픽 라이브러리는 이상하게도 VGA mode 13h를 지원하지 않아서 개인적으로 아쉬웠었다. (퀵베이직은 지원했는데...) 해상도가 너무 낮아서 한글· 한자 같은 문자를 찍는 데는 부적격이었지만 256색 덕분에 게임 만들 때는 필수이던 그래픽 모드이다. 그게 지원됐으면 그 당시 게임 만들기가 훨씬 더 수월했을 텐데 말이다.

Posted by 사무엘

2011/07/15 08:38 2011/07/15 08:38
, , ,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/540

2007년 내일로 티켓 여행기

새 홈페이지에다 이 귀한 자료를 내가 아직 올리지 않고 있었구나.
병특 회사에 다니는 중이던 2007년, 본인은 나이가 만 24세였던 덕분에 내 인생에서 처음이자 마지막으로 내일로 티켓 여행을 즐겼다. 지금으로부터 딱 4년 전에!

사실은 내일로 티켓 자체가 그때 처음으로 생겼었다. 본인은 ISEF 참가 1세대일 뿐만 아니라 내일로 티켓 1세대. ㄲㄲㄲ
그 후로 코레일이 내일로를 정책적으로 밀어붙이면서 내일로 UCC 공모전을 하고, 하계뿐만이 아니라 동계 내일로도 시행하고, KTX 내일로에다 일반 내일로도 2회에 한해 KTX 운임 50% 할인까지 도입했지만 내 때는 처음이라 그런 게 없었다.

그때는 정말 꿈같은 즐겁고 행복한 시간이었다. 보이저 호가 우주의 사진을 찍어서 지구로 전송하듯, 미지의 세계를 철도로 탐사하면서 수많은 사진, 동영상을 찍었다. 여행 경로 구상과 모든 계획은 내가 직접 했고, 나중에는 내일로 티켓 여행을 떠나는 후배에게 코치도 해 줬다.

내일로 티켓을 이용해 본 분들은 알겠지만, 목걸이 명찰 형태의 티켓을 받는다. 이거 무슨 대회, 학회, 워크숍 같은 데에 등록하고서 받은 명찰처럼 느껴지지 않는지? 마치 한국의 모든 철도역이 대회장이 된 것 같다. 실제로 여행 기간 동안 본인의 모습은, 미리 정해진 오전· 오후 일정대로 철도 워크숍에 참석한 기자 내지 연구원 같았다.

7일 중 4일은 주말+제헌절+회사 연차를 이용해서 연달아 여행을 즐겼고, 나머지 3일은 일종의 번외편으로 회사 퇴근 후에 밤에 또 기차를 타고 왔다. 수원까지만 갔다 오거나, 심지어 광주까지 갔다가 새벽 상행 열차를 되돌아온 후 바로 다시 출근-_-, 그리고 주 간선이 아닌 경춘선만 타고 돌아온다거나 하는 식으로 티켓을 사용했다. ^^;;

귀차니즘에 입각하여 하이라이트 중의 하이라이트 사진만 첨부한다. 지금 나이가 되는 후배 여러분들은 나중에 나이 들어서 후회하지 말고, 지금 당장 내일로 여행을 가고 특히 새마을호를 많이 타 두기 바란다. 내가 다 생각이 있어서 이런 충고를 하는 거다. ㄲㄲ

차창 밖으로 바다를 볼 수 있는 동해남부선 해운대 부근

사용자 삽입 이미지

부산 지하철 2호선의 북서쪽 구간은 낙동강+경부선과 나란히 달리기는 하지만 서울과는 달리 고저 차이가 존재하며, 광역전철 직결 운행도 아니다.

사용자 삽입 이미지

경부선에서 경치가 제일 빼어난 곳. 더 이상의 자세한 설명은 생략한다. 마곡 역 승강장 사진과 더불어 2007년에 본인이 남긴 명장면 중 하나이다.

사용자 삽입 이미지

경북선으로 진입하는 열차 안에서 경부선과 경부고속선을 나란히 카메라에 담았다. 이 날 유난히도 날씨가 참 좋았다. 그리고 최강 광량.

사용자 삽입 이미지

그야말로 산과 강, 들판뿐이던 영동선

사용자 삽입 이미지

영동선과 태백선이 합류? 분기? 하는 지점

사용자 삽입 이미지

내일로 티켓의 대단원을 찍은 곳! 이 마석 역은 본인이 방문한 후 얼마 되지 않아, 그리고 경춘선 전철이 개통하기 한참 전에 이미 선로가 이설되면서 철거되었다.

사용자 삽입 이미지

본인은 이곳에 올린 사진들에 딱히 워터마크를 넣는다거나 내 꺼라는 티를 안 냈다. 우클릭을 막지도 않고..
한국 철도의 아름다움을 널리 알리고 미래의 철덕 꿈나무들에게 동기와 자극을 주기 위한 비영리 목적이라면, 누구라도 마음대로 퍼 가고 사용해도 좋다. 새마을호 덕후인 사무엘 님이 찍은 거라고 출처 밝혀 주면 Thank you이지만, 강요는 안 함..;; 자기가 찍은 거라고 거짓말만 안 하면 된다.

사실, 웹에 올리기 위해 해상도를 팍 낮춘 것만으로도, 디카 원본 사진에 비해서 엄청나게 품질을 저하시킨 것이다.
원본 사진을 누가 갖고 있는지만 대조해 봐도 사진의 진짜 주인이 누군지는 바로 판가름이 날 테니, 인터넷 상으로 그렇게 저작권 따지지는 않을 생각.

Posted by 사무엘

2011/07/12 08:11 2011/07/12 08:11
, ,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/539

어지간한 중급 이상 수준의 기능을 갖춘 텍스트 에디터나 워드 프로세서들은 일명 ‘칼럼 블록’ 기능을 제공한다. 아래아한글은 도스 시절부터 ‘구역’이라고 하여 동일 기능을 제공했으며, 단축키는 F4였다. 일반 블록의 단축키는 F3이고 말이다. 마우스로는 그냥 드래그는 일반 블록이고 Alt+드래그가 칼럼 블록으로 통용되고 있다. 칼럼 블록을 만드는 키보드 단축키가 통일되어 있는지는 잘 모르겠다.

칼럼 블록이 일반 블록의 복붙 동작과는 어떤 차이가 있으며 얼마나 유용한지 일일이 구차하게 설명하지는 않겠다. 칼럼 블록은 불연속적인 여러 줄들의 일부를 통째로 선택할 수 있을 뿐만 아니라, 붙이는 동작도 여러 줄에다가 내용을 끼워 넣는 식으로 달라진다. <날개셋> 편집기는 전문적인 에디터를 표방하면서 개발되고 있지는 않기 때문에, 현재 (아쉽게도) 칼럼 블록을 지원하지는 않는다.

그런데 칼럼 블록을 구현할 때 현실적으로 부딪히는 문제가 있다. ‘붙이기’를 할 때 클립보드의 내용이 일반 블록인지 아니면 칼럼 블록인지를 어떻게 판별할 거냐는 것이다.
제일 간단한 방법은 응용 프로그램이 별도의 플래그를 갖고 있는 것이다. 클립보드에다가는 일반 블록처럼 텍스트만 복사해 놓으나, 이 블록이 칼럼 블록이라면 플래그를 켠다. 그래서 붙이기를 할 때 플래그가 켜져 있으면 칼럼 형태로 붙인다.

윈도우 탐색기가 파일을 클립보드에다 복사(Copy)한 것인지 오린(Cut) 것인지 판별할 때도 내부적으로 이런 자체 플래그를 쓴다. 파일은 오려 놓는다고 해서 실제로 파일을 지워 버릴 수는 없으므로, 자체적인 표식밖에는 구분할 방법이 없으니 말이다. 파일의 오리기는 텍스트의 오리기와 다르다. 더 나아가면, 엑셀 같은 스프레드 시트의 오리기도 마찬가지임.

하지만 이 방법을 쓸 경우, 칼럼 블록을 복사해 놓고는 다른 응용 프로그램에서 텍스트를 또 복사했을 때, 그 텍스트도 칼럼 형태로 붙여진다는 문제가 있다. 국산 에디터인 AcroEdit, 그리고 유명한 개발 IDE인 Source Insight가 칼럼 블록을 이런 식으로 구현했고 저런 동작을 보이는 것을 확인했다.
내부 플래그 방식으로 칼럼 블록을 구현했다면, 클립보드 내용이 외부에서 바뀌었을 때 내부 칼럼 플래그를 끄는 기능도 구현해야 할 것이다.

이런 방식 말고, 클립보드 차원에서 아예 자신만이 인식 가능한 별도의 포맷을 등록하는 방법도 있다. 칼럼 블록은 그 포맷으로 복사한 후, 붙이기를 할 때 그 지정 포맷이 존재하면 일반 형식이 아닌 칼럼 형식으로 붙여 넣는 것이다.
물론, 칼럼 블록을 복사하더라도, 다른 프로그램이 내용을 일반 블록 형태로 붙여넣을 수도 있게 일반 텍스트 형식으로도 복사는 해 놓는다.

국산 에디터인 EditPlus, 그리고 MS 비주얼 스튜디오 IDE는 이렇게 칼럼 블록은 별도의 클립보드 포맷을 써서 복사해 놓는 것을 확인했다. 이렇게 하면 칼럼 블록을 오로지 자기 프로그램에서 생성한 클립보드 데이터를 통해서만 인식할 수 있기 때문에 앞서 언급했던 오동작이 발생할 여지가 없다.

EditPlus의 식별자는 “EditPlus Column Selection”이요,
비주얼 스튜디오의 식별자는 “MSDEVColumnSelect”이다. 다른 프로그램들은 어떨지 모르겠다.
워드 프로세서들은 어차피 자기네 고유 포맷을 쓰는 게 관행이기 때문에 칼럼 블록만을 위한 고유 포맷을 만들지는 않는 듯하다. (아래아한글과 MS 워드의 경우)

개인적은 생각은, CF_TEXT 같은 것처럼 칼럼 블록을 위한 텍스트도 운영체제 차원에서 표준 클립보드 포맷을 도입하면 좋지 않을까 싶다. 내부적으로 전세계의 수많은 텍스트 에디터들이 자신만의 고유 포맷으로 칼럼 블록을 표현하고 있을지 알 수 없는 노릇이기 때문이다. 그게 제정되면 칼럼 블록도 에디터들마다 공유가 가능할 것이다.

Posted by 사무엘

2011/07/10 08:08 2011/07/10 08:08
, ,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/538

아래 코드를 실행하면 놀랍게도..
입력된 숫자에 대한 팩토리얼 값이 출력된다. 단, 플랫폼은 x86 한정으로..;;
(뭐, 컴퓨터가 돌아가는 원리를 아는 사람이라거나 맨날 기계어 코드 들여다보는 게 직업인 사람이라면 전혀 새삼스러운 일이 아니겠지만)

비주얼 C++뿐만이 아니라 도스용 DJGPP로도 프로그램이 잘 동작하는 걸 확인했다. 둘 다 IA32 아키텍처인 건 동일하니까 이는 당연한 귀결.

int main(int argc, char* argv[])
{
 BYTE instrs[]={
  0x55,
  0x8B,0xEC,
  0x83,0xEC,0x08,
  0xC7,0x45,0xFC,0x01,0x00,0x00,0x00,
  0x8B,0x45,0xFC,
  0x89,0x45,0xF8,
  0xEB,0x09,
  0x8B,0x4D,0xF8,
  0x83,0xC1,0x01,
  0x89,0x4D,0xF8,
  0x8B,0x55,0xF8,
  0x3B,0x55,0x08,
  0x7F,0x0C,
  0x8B,0x45,0xFC,
  0x0F,0xAF,0x45,0xF8,
  0x89,0x45,0xFC,
  0xEB,0xE3,
  0x8B,0x45,0xFC,
  0x8B,0xE5,
  0x5D,
  0xC3
 };

 PVOID pv = instrs;
 
int (*pfn)(int) = reinterpret_cast<int (*)(int)>(pv), y;
 while(1) {
  printf("? "); scanf("%d", &y); if(y<1) break;
  printf("%d\n", pfn(y));
 }
 return 0;
}


프로그래밍 언어의 인터프리터 내지 just-in-time 컴파일러를 만든다거나,
가상 기계 에뮬레이터를 만드는 것은 어렵지 않다.
결국 핵심이 뭐냐 하면 컴퓨터가 직통으로 실행하는 코드 자체를 실행 시간에 메모리에다 생성하는 건데,
함수 포인터가 가리키고 있는 게 바로 저런 것들이다.

물론, 위에서처럼 실행해야 할 코드가 완전히 고정돼 있는 경우라면
소스 코드에다 인라인 어셈블리를 집어넣으면 되겠지만, 그 코드는 데이터 영역에 들어가는 게 아니라 소스 코드(text) 영역에 그대로 포함되어 버리게 될 것이다.

위의 팩토리얼 함수는 물론 컴파일러가 생성해 준 코드를 복사한 것이다.
최적화를 안 한지라, 간단한 for 루프 하나밖에 없는 함수가 코드 길이가 꽤 길다.
최적화를 하고 나면 정상적인 함수 입출력 껍데기에 해당하는 코드조차도 거추장스러운지 생성되지 않아서
그걸 저렇게 따로 떼어내서 쓸 수가 없었다.

Posted by 사무엘

2011/07/08 08:06 2011/07/08 08:06
, ,
Response
No Trackback , 3 Comments
RSS :
http://moogi.new21.org/tc/rss/response/537

프로그래밍 잡설

1. 닷넷 기반 프로그램의 특징:

- 뜨는 데 시간이 좀 오래 걸린다.
- 파일 내부를 들여다보면 전통적인 네이티브 프로그램처럼 kernel32, user32, gdi32 따위가 아니라, mscoree.dll에 대한 Dependency만 있다.
- 생성하는 GUI 윈도우들의 클래스를 보면 WindowsForm10 이런 명칭으로 시작한다.
- 같이 들어있는 DLL들이 '뭐.뭐' 이런 식으로 대소문자가 섞이고 중간에 마침표도 있는 등, 이례적으로 이름이 긴 경향이 있다. 네이티브 EXE/DLL은 그런 식으로 작명되는 경우가, 금지되거나 불가능한 건 절대 아님에도 불구하고, 거의 없다. 유닉스 내지 심지어 도스 시절 8.3 영향을 받은 짧고 암호 같은 영어 알파벳 조합이 아직까지 대세.

유명한 닷넷 프로그램으로는 MS Keyboard Layout Creator, Paint .NET이 있다. 비록 닷넷 기반으로 비주얼 베이직.NET과 C++ managed extension 같은 언어도 있긴 하지만, 그래도 90%이상의 여건에서는 닷넷이 곧 C#이나 마찬가지이다.

게임 자체는 모르겠지만, 최소한 게임과 관련된 툴 정도는 C#으로 만드는 게 충분히 승산이 있는 단계에 이른 것 같다. 스타크래프트의 StarEdit처럼 고객이 사용하는 툴이든, 게임 개발사 내부에서 디자이너나 기획자가 쓰는 툴이든 말이다. C#은 일종의 가상 기계 프레임워크 기반이면서도 로컬 환경 역시 적당하게 잘 공략한 것 같다. 이제 MFC는 덩치가 커져도 너무 커졌고, C#은 빌드 속도 같은 생산성 면에서 C++을 압도적으로 능가한다.

게임 클라이언트에 이어 게임 서버까지 C#으로 만들어 돌리는 날이 과연 올지는 모르겠다. 컴퓨터의 성능이 계속 향상되니까 괜찮을 거라는 말이 있지만, 그래도 과거에 C/C++은 어셈블리와 일대일 대응하는 최소한 네이티브 코드 생성 언어이지 않았던가.
다만, 아직은 C# 프로그램이 네이티브에 비해 느린 건 둘째치고라도, 앞서 말했듯이 좀 무겁다는 인상이 짙게 느껴진다. (뜨는 데 걸리는 시간) 이게 좀 개선됐으면 좋겠다. 듣자하니, MS는 내부적으로는 C# 코드를 산뜻한 네이티브 코드로 빌드해 주는 컴파일러를 보유하고 있다는데..;;

2.
본인, 전공이 전공이다 보니 소위 '국어 정보 처리' 분야의 프로그램들을 좀 접했다. 형태소 분석, 말뭉치 검색 등.
비주얼 C++ + MFC로 만들어진 게 다수이지만 2005년 이후부터는 C#을 쓴 것도 심심찮게 보인다. 다만, '깜짝새'라고 유명한 프로그램이 있는데, 얘는 이례적으로 델파이로 개발됐다.

이런 프로그램들은 그 특성상, 결과 데이터를 마치 스프레드 시트처럼 row-column 형태의 출력하는 경우가 많다. 그런데 순수하게 처리를 하는 비용뿐만이 아니라, 처리가 끝난 결과 데이터를 해당 리스트 컨트롤에다 등록하는 데 걸리는 시간도 만만찮아서 본인은 그게 불만이다. 결과 출력하느라 리스트 컨트롤의 스크롤바가 쫘르륵~~ 변하는 모습을 보고 있으면 좀 민망하다. 불필요한 화면 refresh가 수천, 수만 회 발생하고 있다는 뜻이지 않은가?

대용량의 데이터를 그런 형태로 출력할 때는, owner-draw라든가 virtual list control 테크닉을 써서, 결과 데이터를 일일이 리스트 컨트롤로 복사하는 게 아니라, 그때 그때 출력을 내가 직접 하도록 해야 한다. 이렇게만 하면 프로그램의 체감 동작 속도가 월등히 빨라지며 메모리도 크게 아낄 수 있다.
도스 시절이었다면 리스트 컨트롤 같은 컴포넌트라는 개념 자체가 없었을 터이니 이런 비효율 자체가 존재할 여지가 없었을 것이다. 물론, 소프트웨어의 재활용성면에서 도스는 어차피 빵점인 열악한 환경이니 도스 시절이 마냥 좋다는 건 아니다.

저런 프로그램들이 어떤 여건 속에서 개발되었는지 잘은 모르겠다. 허나, 열악한 자금과 시간에 쫓기면서 공밀레 공밀레 하면서 만들어진 프로그램이라면, 개발자가 아무리 날고 기는 천재 프로그래머라고 해도 답이 없다. 품질을 보증할 수 없고, 이런 자그마한 곳에서의 사용자 배려 따위는 절대로 기대할 수 없다. 이는 개인의 프로그래밍 실력과는 하등 관계 없는 문제이다.

그 반면에 <날개셋> 한글 입력기가 가히 변태적인 수준의 최적화를 자랑하며 개발되고 있는 이유는 시간과 돈에 전혀 구애받지 않고 전적으로 개인의 자아 실현을 위해 만들어지는 프로그램이기 때문이다. -_-;; 언제까지나 그런 태도로 프로그램을 만들 수는 없으니까 그게 문제지만.
이런 문제를 이쪽에 계시는 교수님들도 인지는 하고 있지만, 우리나라 IT 인프라에 전반적으로 딱히 답이 안 보이는 문제이니 어쩔 수 없다.

3.
C/C++ 부류의 type 시스템은 액세스(MS Access)와 비슷하고,
파이썬 부류의 type 시스템은 엑셀(MS Excel)과 비슷하다. 진짜 딱 대응하는 것 같다.

스프레드 시트인 엑셀은 아무 셀에 아무 타입의 데이터나 바로 집어넣을 수 있으며, 그러면 그 형태를 엑셀이 알아서 인식해서 출력해 준다. 날짜는 날짜처럼, 문자열은 문자열처럼, 숫자는 숫자처럼 오른쪽 정렬을 해서.
그러나 데이터베이스 프로그램인 엑세스는 테이블을 설계할 때 모든 애트리뷰트와 각 애트리뷰트에 들어갈 수 있는 값의 타입을 지정해야 하며, 딱 그 값만 넣을 수 있다. 문자열은 길이 제한까지도 생각해야 한다. 정말 딱딱하고 까다롭다.

엑셀은 셀의 값들에 서식도 자유롭게 지정할 수 있고 Undo도 얼마든지 가능하다. 엑세스는 그런 게 없으며, 테이블을 수정한 게 파일에도 바로 반영된다.

그러나 수십, 수백만 개에 달하는 데이터를 검색하고 한꺼번에 고치고, 테이블 간의 관계를 분석하는 동작에서 엑셀과 엑세스의 효율은...;; 더 설명이 필요하지 않을 것이다.

그럼에도 불구하고 엑세스 급의 전문적인 성능이 필요한 경우는 매우 드물다. 일반 사용자들은 어지간한 중소 규모의 데이터나 다룰 것이고 이때는 친근한 엑셀이 대부분의 경우 훨씬 더 도움이 될 것이다.

4.
PC 파워 유저라면, 윈도우용 EXE 파일에는 리소스라는 별도의 데이터 섹션이 있다는 걸 알 것이다. 윈도우용 EXE는 이례적으로 자체 아이콘을 갖춘 파일 포맷인데, 그것도 바로 리소스라는 형태로 들어있다. 운영체제는 EXE/DLL의 리소스를 조작하는 API를 제공하며, 이를 이용하면 프로그램의 메뉴, 메시지 문자열을 고쳐서 허접하게나마 프로그램을 한글화(자국어화)할 수도 있다. 물론, 모든 프로그램에 그런 테크닉이 통하는 건 아니지만.

이 일을 프로그래밍을 통해서 하려면 BeginUpdateResource, UpdateResource, EndUpdateResource라는 함수를 쓰면 된다. 다만, 윈도우 9x는 이 기능을 지원하지 않았으며 그건 NT에서만 지원됐다. 그런 기능을 어차피 일반 사용자가 쓸 일은 없었을 테니까.
그런데 신기하게도 그 당시 윈도우 9x에서 실행된 비주얼 C++ 6은, 32비트 EXE/DLL의 리소스를 고칠 수는 없었던 반면, 16비트 EXE/DLL의 리소스를 고쳐서 저장할 수는 있었다.

윈도우 API를 쓴 건지, 아니면 16비트 바이너리는 비주얼 C++의 자체 기능으로 파일을 건드렸는지는 잘 모르겠다. 다만, 16비트 바이너리와 32비트 바이너리는 리소스를 저장하는 방식이 상당히 다르기 때문에 아마 자체 기능이 아니었겠나 싶다. 근본적으로 32비트 바이너리는 wide character 유니코드를 사용하지만 16비트 바이너리는 그렇지 않다. 그래서 과거에 윈도우 3.1에다가 Win32s를 설치하면 각종 시스템 DLL뿐만이 아니라 유니코드 변환 테이블인 NLS 파일들도 잔뜩 설치됐던 것이다.

Posted by 사무엘

2011/07/06 08:09 2011/07/06 08:09
,
Response
No Trackback , 10 Comments
RSS :
http://moogi.new21.org/tc/rss/response/536

현재 세계에서 가장 높은 곳에 있는 도시는 볼리비아의 수도 라파스라고 한다. 해발 고도가 무려 3600m에 달해 우리나라의 백두산보다도 더 높다!
이 외에도 에콰도르, 콜롬비아 같은 나라들도 높은 고도를 자랑하는 곳이고, 멕시코의 수도 멕시코시티 역시 고도가 2240m로, 한라산의 높이를 능가한다. 1968년에는 이곳에서 올림픽이 개최되었는데, 평지보다 산소가 부족해서 참가 선수들이 굉장히 힘들어했다고 한다. 하지만 대기가 그만큼 옅은 덕에 멀리/높이뛰기의 기록 수립에는 도움이 됐다는 말도 있다.

과학 상식에 따르면, 대류권에서는 높이 올라갈수록 기온이 조금씩 떨어지고, 물이 끓는 온도도 차츰 내려가서 고지대에서 지은 밥은 설익는 경향이 있다. 또한, 에베레스트 산 정상 정도 되는 곳에서 산소통 없이 돌아다니면, 발을 떼어 좀 걷기만 해도 100미터를 전력질주라도 한 것처럼 숨이 가빠 온다고 한다. 학창 시절 과학동아 잡지에서 읽은 내용이다.
히말라야 산맥의 그 높은 산중턱에서 조개껍데기 화석이 발견되기도 했다니 더욱 흥미로운 사실이다.

덧붙이자면, 현재 지구를 초월해 태양계의 행성들 내부에서 가장 높은 산으로 알려진 산은, 화성에 있는 올림푸스 산. 백두산처럼 칼데라가 있는 화산 지형인지라, 과거에 화산이었던 걸로 추정된다.
화성에는 지구처럼 물이 없으니 해발 고도 같은 개념은 없고 행성의 평균 반지름이던가 하는 기준의 차이로 산의 높이를 재는데, 저 산의 높이는 25km에 달해서 에베레스트 산의 3배에 필적한다. 게다가 산 전체가 차지하는 면적은 한반도의 그것에 맞먹는다고. (단, 면적이 면적인 만큼, 경사는 굉장히 완만해서 별도의 등산 테크닉이 필요 없을 정도라 함.)

지구 같았으면 활발한 지질 활동으로 인해 아예 산맥이 생겼을 텐데, 그러지는 못하고 화성이기 때문에 그냥 크고 아름다운 단일 산이 생기는 것으로 그친 거라고들 한다. (게다가 화성 자체의 반지름이 지구의 절반밖에 안 된다는 걸 감안한다면 얼마나 큰가?)

지구에서 높은 곳을 살펴보았으니 다음으로는 낮은 곳 차례이다.
먼저 네덜란드가 있다. 국토의 상당수가 간척지이며, 해수면보다 수~십수 m가량 낮은 곳이 많다. 이런 곳에 쓰나미라도 몰아쳤다간 정말... jot망일 듯.

이탈리아의 베네치아는 과거에 한메 타자 교사 게임의 배경으로 등장해서 우리나라에 널리 알려졌다. 툼레이더 2에서 레벨 2의 배경이기도 하고.. 거기 묘사되어 있듯이 그곳은 도시 전체가 수로로 연결되어 있어 배로만 이동 가능하고 자동차가 못 다닌다. 말 그대로 물의 도시. 하지만 주기적으로 폭우의 피해를 심심찮게 당하며, 도시가 매년 진짜로 차츰 가라앉고 있어서 걱정이라 한다.

일본의 칸사이 국제 공항도 비슷한 사정. 토지 보상 문제를 원천봉쇄하기 위해 오지게 고생해서 바다 위에 인공섬을 만들고 그 위에 공항을 만들었는데... 지반이 약해서 섬이 예상보다 꽤 빠른 속도로 가라앉고 있다고 한다. 일본 침몰이 아니라 칸사이 공항의 침몰. 이미 10미터가 넘게 가라앉았고 게다가 부위별로 가라앉는 속도가 다르기까지 하다. 덜덜;;; 이 때문에 이 공항은 건설 비용뿐만이 아니라 유지 보수 비용이 장난 아니게 들고 있으며, 세계에서 공항 이용료가 비싸기로 악명 높은 공항의 순위권을 지키고 있다.

이런 인간이 만든 간척지 말고, 진짜 순수하게 자연적으로 지구 중심부에서 가장 가까이 있는 땅은 잘 알다시피 사해(dead sea) 일대이다. 그 해발 고도는 -421m이며, 인근의 여타 사막 지역과의 고도 차이는 7~800m나 된다. 해발보다 세계 무역 센터급 마천루의 높이만치 더 낮다고 생각하면 이해하기 쉬우려나?
요르단 강에서 이곳으로 유입된 물은 증발만 할 뿐 밖으로 빠져나가질 못한다. 그렇잖아도 이곳은 엄청나게 더운 곳이다.

말이 나왔으니 사해 얘기를 좀 더 하자. 사해는 저런 지형적 특성으로 인해 무진장 짜다. 일반 바닷물의 소금 농도는 3.5% 남짓이어서 보통은 퍼센트(1/100)도 아닌 퍼밀(1/1000)로 측정하는 반면, 사해의 농도는 20%가 넘는다. 그것도 모자라서 녹지 못한 소금이 기둥을 이루고 있으며, 요즘 거기는 물의 유입량보다 증발량이 더 많아서 차츰 메마르고 있다고. 몇십 년 뒤엔 사해는 물이 다 증발하고 진짜 소금 뻘밭이 될지도 모른다.;;; ㅎㄷㄷㄷ;;

사용자 삽입 이미지
이건 얼음이 아니라 소금 덩어리이다. -_-;;;

이곳에서 생명체 따윈 살지 못한다. 목 마르다고 바닷물을 마시다간 염분으로 인한 탈수 때문에 더 목 말라지고 죽듯이, 민물고기 따위가 여기 들어갔다간 그냥 즉사한다...;;

소금으로 인해 워낙 밀도가 높기 때문에, 여러분도 이미 잘 알다시피, 사해에서는 수영을 전혀 안 해도 사람 정도는 물에 그냥 둥둥 뜬다. 뭐, 그렇다고 해서 아예 물 위에서 서서 첨벙첨벙 걸을 수 있을 정도는 아니겠지만. (예수님의 기적은 신기하기 그지없다!)
사해 수면에 둥실둥실 떠서 한가롭게 책이나 신문을 읽는 아저씨 사진은 누구나 본 기억이 있을 것이다.

어렸을 때 물에다 계란을 넣어서 가라앉혔는데, 소금을 집어넣자 그게 떠오르는 실험을 한 기억이 난다.
그러고 보니, 초딩~중딩 시절엔 소금물의 농도와 관련된 수학 방정식 문제들이 본인을 무척 괴롭혔었다..;;
사해의 물은 민물보다 그만큼 더 단단(?)하고 끈끈하기 때문에, 민물에다 하듯이 다이빙을 하는 것도 위험하다고 한다.

다만, 사해는 소금뿐만이 아니라 온갖 지하자원의 보고이기도 해서 관광지 이상으로 그 가치가 높다. 인간의 활용 가능성에 관한 한 사해는 결코 죽은 바다가 아니라는 뜻.
통념과는 달리, 전세계에 유통되는 소금의 상당수는 암염으로부터 채취된 것이라고 한다. 염전 생산의 비중은 그리 크지 않다. 염전을 아무 바닷가 지형에서나 조성할 수 있는 것도 아니고, 비열이 그렇게도 높은 물을 대량으로 끓이거나 증발시키는 건 역시 쉬운 일이 아닌가 보다.

사해는 성경에도 응당 등장하며, salt sea라고 창세기부터 여호수아기에 이르기까지 여러 차례 언급되어 있다. 유황불 맞고 폭삭 망한 소돔과 고모라가 있던 곳이 여기라고들 한다(소금기둥으로 변한 롯의 아내-_-). 그리고 민수기를 보면 모세에게 반역하다가 산 채로 땅속 지옥으로 떨어져 버린 고라의 얘기가 나오는데, 그들이 있던 곳이 고증상 마침 해발 고도가 가장 낮고, 고로 지옥과도 가장 가까이 있는 이곳 부근이었다고 한다.

우리나라에서 가장 높은 산인 백두산 일대와, 세계의 지붕인 에베레스트 산 일대, 노아의 방주 떡밥이 나도는 아라랏 산 일대, 세계에서 가장 넓은 호수인 카스피 해 일대가 그런 것처럼 사해도 둘 이상의 나라의 국경을 접하고 있다. 백두산 관광을 북한이 아닌 중국을 통해 가듯, 관광객들은 사해 관광을 요르단을 경유해서 하는 경우가 많다고 한다. 익사할 위험이 없다고 자기도 모르게 건너편까지 멀리 수영을 즐기는 관광객이 있는가 본데, 이는 무단 월경으로 오인당할 수 있기 때문에 주의가 필요하다고. 우리나라 같은 반도 + 분단국 정서로는 이해하기 쉽지 않은 모습이다.

사해 얘기가 길어지긴 했다만, 고산 지대만큼이나 이런 저지대에 생태학적으로 다른 side effect가 있는지는 잘 모르겠다. 더 더워지긴 하겠지만, 어차피 해수면보다 1km가 넘게 심하게 낮은 육지가 존재하는 것도 아니니 뭐..
태양계에서 압력과 온도의 극단적인 예는 물론 금성 표면이겠지만, 지표면에는 그런 곳이 없다. 그런 금성은 오히려 성층권 이상의 높은 곳의 대기 온도와 압력이 지구의 대류권의 그것과 비슷하다고 하니 흥미롭다.

Summary:

1. 아주 어렸을 때 본인, 지금의 철덕의 수준에는 훨씬 못 미치지만 그래도 약간 지구과학덕 색깔을 좀 띤 적은 있었다. -_-;;
2. 홍해는 영어로 Red Sea이지만, 홍차는 red tea가 아니다. 어??
3. 민물고기를 직류 전동차, 바닷물고기를 교류 전동차에다 비유한 건 아무리 다시 생각해 봐도 참 적절한 비유 같다. 바닷물과 민물이 만나는 곳은 바로 절연 구간(dead section)!

Posted by 사무엘

2011/07/04 08:00 2011/07/04 08:00
, , ,
Response
No Trackback , 5 Comments
RSS :
http://moogi.new21.org/tc/rss/response/535

세상에는 갖가지 종류의 상(prize)이 있다.
그 중 세계구급인 상으로는, 우리나라에서 그토록 입상자를 배출하려고 애써도 결국 못 받고 있는 노벨 상(과학 분야)이 있고, 수학 분야에서 노벨 상보다 더 받기 어렵다는 필즈 상이 있다.
그리고 전산학계에는 튜링 상이 있고, 사회· 정치 분야에는 막사이사이 상도 있으며 교육· 문화 분야에는 세종대왕 상도 있(었)다고 카더라.

이런 상들은 연구 실적을 기관에서 따로 평가하여 입상자가 결정되는 상이지만, 아예 contest, competition을 치러서 입상자를 결정하는 대회 성격이 짙은 상도 있다. 각종 올림픽, 올림피아드가 그 예이며, 이런 곳은 상이 메달의 형태로 등급이 매겨져 있다.

그런데, 이런 세상의 많고 많은 상 중엔 영예(honor, pride)가 아닌 굴욕(humiliation)에 가까운 상도 있으니,
다윈 상이라고 혹시 들어 보셨는가?
이건 개그 내지 풍자 성격으로 온라인 공간에서 수여되는 상인데...
열성 유전자를 지닌 사람이 자신의 씨를 스스로 끊음으로써 인류의 발전/진화-_-에 공헌한 경우 수상할 수 있다.
공식 홈페이지는 여기. http://www.darwinawards.com/

그래, 한 마디로 개소리이다. -_-;;;
쉽게 말해서 ㅂㅅ같은 개죽음을 맞이하거나 최소한 생식불능이 된 사람이라면 이 상을 받을 수 있다. 더 구체적으로 말하면 다음과 같은 다섯 가지 조건이 있다.

1. 수상자는 기막히고 놀라울 정도로 충분히 멍청한 짓을 하거나 어이없는 일을 당해야 한다.
2. 수상자는 그로 인해 죽거나 고자가 돼야 한다. 내가 고자라니
3. 그 행동은 의도했건 안 했건 자신의 능동적이고 자발적인 의지로 인해 야기된 것이어야 한다.
4. 당연한 말이지만, 수상자는 정상적인 지적 능력을 지닌 사람이어야 한다.
5. 행적에 신빙성이 있어야 한다. 공신력 있는 매체에 보도되었다거나, 증언이 충분히 믿을 만하다거나.

예를 들자면,
- 공짜로 음료수를 마시기 위해 자판기를 기울이다 자판기에 깔려 죽은 사람. -_-;;; (1994년)
- 독사에게 물렸는데, 병원에 안 가고 술집에서 술이나 퍼 마시면서 깡으로 “난 독사에게 물리고도 끄떡없어”라고 자랑을 하고는 곧 죽어 버린 어느 미국인 남성 (1997년)
- 자기 집에다가 수심이 자기 키보다 얕게 수영장을 설치하고는 다이빙 후 목이 부러져 죽은 사람 (1998년)
- 광산에서 수정을 캐고 있었는데 위에 달려 있던 수정이 떨어지면서 거기에 정통으로 찔려 죽은 멕시코의 광부.. (2001년)
- 벌집을 옮기려고 온몸을 얼굴까지 보호막으로 둘러쌌는데, 작업 중에 그만 밀폐된 비닐봉지 안에서 질식사한 농부.. 숨구멍을 안 뚫었다. -_-;; (2002년)

이런 사람들이 받아 왔다. ㄲㄲㄲㄲㄲㄲㄲㄲ

이런 상이 다루는 사건들이든, 이런 상이 존재한다는 사실 자체이든 모두 단순히 엽기 해외 토픽 정도로 치부될 법도 한데
이 다윈 상은 최근에 우리나라에서 큰 주목을 받기 시작했다.
왜냐하면 작년(2010) 여름에 우리나라에서 압도적인 지지로 첫 다윈 상 수상자가 배출되었기 때문이다.

그 주인공은 바로...;;
대전 지하철 서대전네거리 역에서 휠체어 탄 채로 추락사한 어느 장애인.. ㅠㅠㅠㅠㅠ

구체적인 스토리를 아는 분도 있겠지만...
고인은 8월 25일, 지하철 타러 내려가려고 엘리베이터를 타러 가는 길이었다.
그런데 아주 간발의 차이로 엘리베이터 문이 닫히고, 엘리베이터는 한참 전에 먼저 탄 어느 60대 여인 혼자만을 싣고 매정하게 먼저 아래층으로 내려가 버렸다.
내가 알기로 지하철의 엘리베이터는 한번 문이 열리고 나면 닫히지 않고 굉장히 오랫동안 열려 있으며, 주행 속도도 아주 느리다. 비장애인들이 남용하지 말라고 말이다. 그러니, 이 엘리베이터를 놓치면 또 몇 분이 그냥 날아가는지 모른다.

나라도 짜증 났겠다. 그래서 고인은 빡쳤는지, 닫힌 엘리베이터 문을 휠체어로 쾅쾅 들이받았다. 그런데 2타 때는 약한 엘리베이터 문이 벌어졌고, 3타 때는 그가 그대로 밑으로 엘리베이터 문 아래로 추락해 버렸다.
서대전네거리 역이 얼마나 깊은 역인지는 모르겠지만.. 그 역이 무슨 여의나루나 만덕 같은 역이 아닌 이상, 설마 사람이 추락사할 높이였겠나 싶다. 허나, 몸이 불편했던 장애인은 충격을 최소화하는 자세를 유지하지 못했는지, 아래의 엘리베이터 상부에 휠체어에 앉은 채로 떨어져서 그대로 사망. 떨어지면서 순간 무슨 생각을 했을까? -_-;;;

여인이 탄 엘리베이터가 아래층에 막 도착하려던 찰나, 그 장애인과 휠체어가 엘리베이터 카 위로 쾅 떨어졌으며, 충격을 받은 엘리베이터는 그대로 불이 꺼지고 고장이 났다. 결국 그 여인도 엘리베이터 안에 한동안 갇혔다. -_-;;; 마른 하늘에 날벼락.
이 모든 장면은 CCTV에 고스란히 찍혔다.
동영상은 인터넷을 통해 삽시간에 퍼졌으며, 외국에까지 소개되면서 네티즌들은 이 사람을 올해의 다윈 상 1등급 수상자로 뽑게 되었다.

듣자하니, 당시 엘리베이터에 구조적인 이상은 없었다고 한다. 무거운 휠체어로 그 속도로 저 정도로 작정하고 쾅쾅 들이받는 건 어차피 설계 기준을 초과하는 충격이기 때문에 엘리베이터 관리자의 관점에서는 면책 사유가 성립한다고. 그러니 고인의 죽음은 정말 빼도 박도 못하고 자업자득인 꼴이 됐다. 완전 캐굴욕. 그저 묵념뿐이다.

다윈 상의 취지 자체가 고인드립인 건 말할 것도 없고, 한국식 정서라면 망자에 대한 명예 훼손감일 텐데. 에휴...;;
사실은 찰스 다윈조차도 그런 상의 이름에 자기 이름이 붙은 것으로 인해 통탄할지도 모르겠다. 다윈에 대한 고인드립 ㄲㄲㄲㄲㄲ
하지만 다윈 상의 발상 자체가 진화론적이니 이 역시 자업자득이다.
참고로, 내가 전에도 말했지만 우리나라는 한때(일제 강점기 때) 다윈의 기일을 기려서 과학의 날을 제정하기도 한 적이 있다. 왜 하필 다윈일까.;;

에어장 목사 정도면 다윈 상의 범주에 들지 궁금하다. 그런데 그건 굴욕적이긴 해도, 바보짓이라기보다는 천하의 개쌍놈짓을 하다가 자업자득으로 명을 다한 것이기 때문에 조금은 성격이 다르다 하겠다.

다윈 상 자체에는 뭔가 노골적인 종교적 이념이 없지만, 그래도 이건 창조· 진화 논쟁을 의식해서, 더 나아가 기독교를 좀 조롱하려는 의도에서 만들어졌다는 뉘앙스가 전혀 없다고 말하면 그 역시 거짓말일 것 같다. 날으는 스파게티 괴물(FSM 날스괴;;)처럼 말이다. 유한 상태 기계가 아니다!
FSM 의 공식 홈페이지: http://www.venganza.org/

FSM 하니까 여러 모로 라면교 교주가 떠오르던데.. 한국 버전은 라면이고 양놈들 버전은 스파게티이다. -_-;;
라면교 교주는 끓는 물에 돌아가셨다가 3분 만에 부활하셨다거나, 극악한 사탄의 무리인 비빔면과 짜파게티 무리를 조심하고 적그리스도인 뿌셔뿌셔에게 현혹되지 말아야 한다는 둥 그냥 웃고 넘길 수 있는 패러디 수준인 반면..
FSM에는 좀 더 수위가 높은 비수가 꽂혀 있다.

FSM 신도들이 웬만하면 하지 말았으면 하는 짓
1. 웬만하면 나를 믿는다고 남들보다 성스러운 척 하지 말았으면 좋겠다. 나는 남이 나를 믿지 않는다고 마음 상하지 않으며, 어차피 안 믿는 자들에게 하려는 말들이 아니므로 말 돌리지 마라.
2. 웬만하면 내 존재를 남들을 괴롭히는 핑계로 사용하지 말았으면 좋겠다.
(...)
6. 웬만하면 내 신전을 짓는데 수억금을 낭비하지 말았으면 좋겠다. 더 좋은 데 쓸 데가 많다.
7. 웬만하면 내가 임하여 영지를 내린다고 떠들고 다니지 말았으면 좋겠다. 이웃을 사랑하랬다. 좀 알아 먹어라.
뭐 이런 것들이 있다.

흔히 “종교는 나약한 사람들이나 의지하는 수단이지. 난 차라리 내 주먹을 믿는다”고 말하는 사람이 있다.
그거보다 조금 온화(?)한 사람이 한다는 말은 뻔하다. “뭐, 심신 수양을 위해서 종교 하나 갖는 거 나쁘지는 않지. 하지만 너무 빠지지는 말고, 특히 네 종교만 옳다는 독단에 빠지지는 마라”

국내외의 유~명한 개독안티 석학들은 종교가 지금까지 저질러 온 온갖 폐해들, 종교 때문에 벌어진 각종 참극은 둘째치고라도 그게 사람의 이성을 얼마나 마비시키고 우민화해 왔는지를 지적한다.
그걸 직설적으로 표현 안 하고 교묘하게 sarcasm을 섞어 풍자하다 보니 FSM 같은 것도 만들어진 것이리라.
애초에, FSM교는 “어이쿠! 창조론과 지적 설계를 가르칠 정도로 학교 교육이 막장으로 치닫는다면, 아예 날으는 스파게티 괴물님을 가르쳐도 되겠네요 ㅋㅋㅋㅋㅋ” 이런 비꼼의 목적으로 만들어졌다.

난 그런 것에는 별로 대응할 필요를 못 느껴서 대응 안 한다.
걔네들의 말 중에서 한 20~30% 정도는 특정 문맥에서 '몇몇 가정이 성립한다는 전제 하에서' 맞는 말도 물론 있다.
마치 성경에서 “어리석은 자가 '마음 속으로 이르기를', '하나님이 없다' 하는도다”라는 문장 자체는 참인 것과 같은 맥락에서 말이다.

신을 찾아 온 것도 인간이고 그 신이 필요없다고 신 없이 살자고 부르짖는 것도 인간이다. 그런데 과연 신 없이 인간이 잘 살면 얼마나 훌륭하게 잘 살 수 있을까? 신이 없다고 주장하는 사람이 과연 당신의 혼을 사랑하고 걱정해서 그렇게 말하는 걸까? 잘 생각해 보기 바란다.

인간이 아무리 노력해도 인간에게 진짜 중요하고 필요한 가치는 눈으로, 시스템으로 측정할 수 없으며 돈과 권력과 과학 기술로 얻을 수 없다.
그걸 측정할 수 없기 때문에 한국의 입시 위주 교육 제도 문제는 해결될 기미가 보이지 않는 것이고, 아무리 사회 개혁을 외쳐도 사회 구조는 여기서 저기로 쳇바퀴만 돌 뿐 바뀌지 않는 것이다. 잘 생각해 봐라.
아무리 돈을 쳐발라서 스펙 완벽한 배우자와 결혼해도 행복한 결혼 생활을 살 수는 없기 때문에, 상류층들이 이혼을 엄청 많이 한다. 이래도 아직 이해가 안 되겠는가?

뭐 이런 예가 부지기수이다. 인간이 우주에 갔다 오고 핵무기를 발명하고 지구촌을 인터넷으로 연결했다 한들, 과연 저 구도가 본질적으로 바뀔 수가 있을까?
이건 내 주관적인 생각이다만, 세상에 사람들의 빈부 격차가 이토록 심하고 환경과 여건 차이가 난다고 해도 하나님이 공평하다고 하는 이유가 이런 곳에 있는 것 같다. 인간에게 진짜로 공평해야 하는 건 여전히 어느 누구에게나 공평하다.

저렇게 영적으로 불만족스럽고 부족한 것이 존재하는 한, 무신론자들이 아무리 날뛰어도 절대자를 찾는 사람(굳이 기독교가 아니어도)은 없어질 수 없다고 본인은 생각한다. 무신론자 중에 미신에 빠진 유신론자들이 너무 불쌍한 나머지 그들을 위해 대신 죽을 정도의 사랑을 그들에게 베푸는 사람이라도 나오지 않는 이상 말이다.
세상에 저런 데에 왜 매달리는지 내 머리로 진짜 이해가 안 되는 시한부 종말론자, 도박 중독자, 이단들도 세상에 절대로 안 없어지고 있는데 그것보다 훨씬 더 건전한 게 당신의 논리에 설득되어 없어질 거라고? 꿈 깨라.

끝으로..
나의 종교가 '철도'라고 말한다면 그건 맞을 가능성이 높다. ㅋㅋㅋㅋ
하지만 성경에 기록된 예수님의 복음은 나에게 종교가 아니다. 편의상 여타 종교들 중 하나인 것처럼 분류하는 경우는 있지만 본인이 개인적으로 그걸 종교 차원에서 받아들이는 건 아니라는 뜻이다.

“도대체 기독교는 왜 이리도 교파가 많고 이단들도 많습니까?”라고 묻는다면 나의 대답은 간단하다.
“윈도우즈에만 온통 악성 코드나 보안 이슈가 들끓고 있고 맥OS나 리눅스는 바이러스가 거의 없는 것과 비슷한--같지는 않지만-- 이유 때문입니다. 설마 그게 OS의 기술적 우열 차이 때문이라고 생각하시지는 않겠죠?

Posted by 사무엘

2011/07/02 08:15 2011/07/02 08:15
, , , , , , ,
Response
No Trackback , 5 Comments
RSS :
http://moogi.new21.org/tc/rss/response/534

본인은 윈도우 플랫폼용 한글 입력기의 개발자이다. 그런데 진짜 옛날 도스 시절, 텍스트 모드가 따로 있던 시절에 한글 입출력 바이오스 같은 건 어떻게 구현했는지가 무진장 궁금해질 때가 있다.
출력은 그렇다 치더라도 입력은 어떻게 구현했을까? 게다가 한글도 모자라서 한자 입력은?
그리고 한글 정도면 양반이지 도스 시절에 일본은 사정이 어땠을까? 한자 변환까지 포함한 일본어 입력이 가능했을까? -_-;;

IBM 호환 PC는 그렇게 그래픽에 최적화돼 있지도 않던 놈이었고.. 영어 아스키 코드밖에 모르는 이런 기계에다가 없는 문자를 찍기 위해서는 막대한 양의 오버헤드가 필요했다.

요즘은 잘 알다시피 사운드 카드, 랜 카드 따위는 마더보드에 통합되어 버린 지가 오래이고 GPU, PPU 같은 거나 별도로 부착하는 CPU 애드온이다. (그리고 이마저도 요즘은 본격 통합 기세-_-)
허나 한 25~30년 전에는 한글 카드라는 별도의 하드웨어가 있을 정도였다. '한글 도깨비'. 그때는 그만큼 컴퓨터의 성능이 열악했다.

한글 입출력 바이오스를 만들려면, 일단 바이오스의 글꼴을 다른 걸로 대체할 수 있을 정도로 하드웨어에 정통해야 했고 메모리 사용량이든 계산량이든 극도의 최적화 작업이 필수였다. 한글 모드에서는 텍스트의 스크롤 속도가 한 2, 30% 정도 감소하는 효과가 있었기 때문. -_-;; 더구나 기본 메모리 640KB는 그야말로 1K라도 아껴야 하는 귀중한 영역이기 때문에, 한자 글꼴 같은 건 XMS/EMS 같은 확장 메모리에다 저장하는 테크닉도 필수였다.

VGA의 기본 텍스트 모드는 잘 알다시피 가로 80글자, 세로 25글자이다. 그런데 아주 신기하게도 한 글자의 크기는 너무나 컴퓨터스럽게 잘 떨어지는 8*16이 아니라, 9*16이다. 그리고 화면 해상도는 640*400도, 640*480도 아니요 720*400이다. 정작 mode 12H 같은 그래픽 모드 중에는 640을 넘는 해상도가 없던 시절이었는데 왜 텍스트 모드만 한 글자의 폭이 8이 아닌 9였는지는 모르겠다.
한글 바이오스들은 16*16 크기의 한글· 한자 글꼴을 사용했으며 640*400 해상도의 텍스트 모드에서 동작했다.

그뿐만이 아니다. 그때 VGA 텍스트 모드에는 화면 전체의 테두리 색이라는 게 있었다! 베이직에서 COLOR문은 보통 글자색과 배경색을 의미하는 A,B만이 쓰이는데, 셋째 인자도 있어서 이걸 지정하면 화면의 테두리에도 색깔을 줄 수 있었다. 이런 기능을 누가 썼고 왜 만들었는지는 모르겠지만...
이건 DosBOX나 VMware 같은 에뮬레이터들도 지원 안 하고 있는 기능이다.
그 테두리가 차지하는 픽셀 수는 얼마나 됐을까? 이것까지 감안한 화면 해상도는 얼마였을지를 생각하면 옛날에 비디오와 관련된 하드웨어 제어는 심오함 그 자체였겠다는 생각이 든다.

텍스트 모드의 바이오스 글꼴을 다루는 테크닉을 구사한 프로그램은 흔치 않았다. 도스용 노턴 유틸리티(Norton Utility)는 이걸 환상적으로 조작해서 텍스트 모드에서 준 GUI 수준의 비주얼을 만들고 심지어 그래픽 모양의 마우스 포인터까지 구현하는 용자짓을 했다. 그리고 Screen Thief라는 캡처 프로그램은 당시로서는 흔치 않게 텍스트 모드를 색깔과 바이오스 글꼴까지 감안한 실제 그래픽 화면 픽셀 그대로 캡처하는 기능이 있었다.
뭐, 한글 바이오스가 구동된 상태에서 노턴 유틸리티 같은 프로그램을 GUI 모드로 동시에 실행했다간 '영 좋지 않은 곳에 하드웨어 접근이 일어나서' 대략 불상사가 발생했겠지만 말이다. "내 컴이 다운이라니!!"

그때는 마우스의 존재 여부를 알아오는 테크닉만큼이나 한글 바이오스의 존재 여부를 알아오는 테크닉도 있었고
이는 텍스트 모드에서 실행되는 프로그램이 선문자를 깨지지 않고 맞게 출력하기 위해서 필수였다. 도스용 V3이나 MDIR 같은 프로그램들 말이다.
그러고 보니 한글 모드에서는 아스키 번호 1~31번 제어 문자도 원래 얼굴 모양 등 각종 도형이던 게, 1바이트 선문자로 바뀌었던 것 같다.

당연한 말이지만, 한글 바이오스는 바이오스의 글자 크기가 8*16이기만 하면, 텍스트가 아닌 그래픽 모드에서도 물론 동작했다.
하지만 그래픽 모드에서까지 텍스트를 찍는 프로그램은 전혀에 가깝게 없을 테니 이건 그리 의미는 없는 기능이었다.
그래픽 모드에서 동작하던 프로그램이 crash가 발생하는 바람에 그 상태 그대로 도스로 빠져나가서 도스 프롬프트가 찍힌 게 아닌 이상 말이다.
텍스트 모드에서는 cursor가 아주 빠르게 깜빡거렸지만 그래픽 모드에서는 cursor가 깜빡이지 않는다는 중요한 차이가 있었다.

그럼, 말이 나온 김에 옛날에 접했던 도스용 한글 바이오스들을 추억 차원에서 몇 개 예나 좀 들어 보자.

1. 본인이 난생 처음으로 접했던 IBM 호환 PC는 대우 전자에 개발한 286 AT였는데, config.sys의 DEVICE 문을 통해 구동하는 자체(대우에서) 개발 소프트웨어 기반 한글 바이오스가 들어있었다. 즉, 일단 load된 후엔 메모리에서 제거하는 방법이 없어서 불편했다. (그 당시 sys 파일은 com 실행 파일과 기술적으로 비슷한 구조가 아니었겠나 싶다.)
Alt+한영을 누르면 한글 바이오스 메뉴가 떠서 영문 전용/조합형/완성형 같은 모드를 바꿀 수 있었고, Alt+한자를 누르면 일시적으로 영문 전용 모드로 전환할 수 있었다.
대우 전자에서 개발한 만큼, 조합형과 완성형뿐만이 아니라 당시 악명 높던 DH 완성형도 지원했는데, 얘는 알파벳 소문자+대문자를 묶어서 한글을 표현하는 경우도 있었던 걸로 기억한다. 물론 한글 코드의 표준화가 일단락되면서 깔끔하게 묻혀서 역사 속으로 사라졌지만.

텍스트 + 한글 모드일 때는 화면의 맨 아래에 자그마하게 현재 한글/영문 모드인지, 완성형인지 조합형인지 같은 상태가 파란 배경의 줄에다 떴다. (그래픽 모드일 때는 그런 거 없음) 텍스트 모드에서 그런 걸 어떻게 구현했는지 지금 생각하면 정말 신기하기 그지없다.
물론 아까 말했던 VGA 테두리도 그보다 더 아래에 표시되었다.

한글을 입력하다가 bksp를 누르면 그냥 바이트 단위로 지워졌다. 즉, '한'을 입력하다가 bksp를 누르면 '하'가 되는 게 아니라 그대로 조합이 끝나면서 KS 완성형 기준 '한'을 구성하는 %C7%D1 중 %C7만 남아서 깨진 문자가 보였다.
우연히 한글 초성만 입력해 놓고 한자 키를 누르니까 지금까지 듣도 보도 못한 온갖 특수문자들이 펼쳐져서 이것도 신비로움 그 자체였다.

2. 한글 MS-DOS를 판매한 MS도 응당 자체 한글 바이오스를 갖추고 있었다.
그런데 지금까지 생각해도 참 대단한 건, MS에서 만든 한글 제품은 텍스트 모드에서도 깨진 문자를 보여주는 법이 없었다.
조합 중인 문자든 조합이 끝난 문자든, 한글은 알아서 자동으로 2바이트씩 한꺼번에 지워졌다. 조합 중인 글자를 조합의 역순으로 차곡차곡 '한' -> '하' 식으로 지워 주기에는 도스 환경이 너무 열악했고, MS가 개발한 한글 바이오스는 그냥 한글을 한꺼번에 지웠다.

GWBASIC, QBASIC 같은 프로그램은 한글판이 따로 있었는데, 한글 바이오스를 구동하지 않고 한글판 프로그램을 실행하면 글자만 깨지는 게 아니라 그대로 컴퓨터가 다운됐었다!
그러나 텍스트 모드에서 GUI를 구현한 한글판 프로그램들을 잘 살펴보면, 메뉴 같은 게 배경에 있는 한글의 2바이트를 반으로 가르게 될 경우 나머지 1바이트도 알아서 지워서 표시해 줬다. 어떤 경우에도 깨진 한글의 잔해 바이트가 표시되는 일이 없었다.

아마 한글 바이오스뿐만이 아니라 응용 프로그램 차원에서 무슨 특수한 처리를 한 것 같긴 한데, 그 대신 당시 MS에서 만든 한글판 프로그램들은 한글 바이오스가 없으면 동작하지 않고, 속도도 느리고 이래저래 파워 사용자들에게서 욕 많이 먹었다. 특히 QuickBasic 한글판은 라이브러리 파일이 영문판과 호환되지 않는 등 최악의 제품이었다.

<날개셋> 한글 입력기는 현재 '마소바탕'이라고 하여 MS 한글 바이오스가 내장한 조합형 글꼴을 그대로 지원하고 있다. 조합 구조가 전통적인 8*4*4벌 도깨비 글꼴과는 다른데 이런 것까지 복원해 냈다.

3. 끝으로 태백한글이라는 프로그램이 있었다. 1994~95년까지 32비트 코드로까지 비교적 오래 개발되었고, 도깨비 글꼴을 그대로 지원한다는 점이 무척 좋았다. 얘는 아마 조합 중인 한글을 음소 단위로 지우는 기능이 있었지 싶다.

도스도 모자라서 영문 윈도우 3.x에서 한글을 구현해 냈다는 한메한글 같은 프로그램은 운영체제의 무슨 계층에서 훅킹을 해서 도대체 어떻게 만든 걸까? 파워 사용자 중에는 영문 윈도우+한메한글이 오히려 한글 윈도우보다 더 안정적이고 좋았다는 말을 할 정도였으니 말이다.
32비트 시대가 도래하기 전에 한글 IME는 DLL이 아닌 EXE이긴 했는데, 그때는 구체적으로 어떤 메카니즘을 썼는지 잘 모르겠다. 물론 그 시절에는 한 프로세스가 시스템 전체에 어떤 영향을 끼치기가 지금보다 훨씬 더 쉬웠을 테니까 그 원리가 그렇게 복잡하고 어려운 건 없었을 것이다.

이것저것 잡설이 길어졌는데, 추억에 공감하시는 분이 있다면 용자.

한글 윈도우 3.1은 실행 전에 언제나 아래와 같은 경고문이 떴었다.
보다시피 MS는 분명히 Hangeul이라는 명칭을 썼었다. 허나 지금 대세는 Hangul이 압도적으로 굳어져 버린 듯. <날개셋> 한글 입력기도 6.0부터는 표기를 Hangul로 바꿨다.

Warning: For correct execution of DOS Box in Hangeul Windows 3.1,
You should use Hangeul Windows 3.1 standard HBIOS.

Warning: Your DOS is not compatible with Hangeul MS-DOS. You may have
some problems when you use Hangeul Windows 3.1.

Press any key to continue...

Posted by 사무엘

2011/06/30 08:47 2011/06/30 08:47
, , ,
Response
No Trackback , 10 Comments
RSS :
http://moogi.new21.org/tc/rss/response/533

« Previous : 1 : ... 171 : 172 : 173 : 174 : 175 : 176 : 177 : 178 : 179 : ... 221 : Next »

블로그 이미지

그런즉 이제 애호박, 단호박, 늙은호박 이 셋은 항상 있으나, 그 중에 제일은 늙은호박이니라.

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2024/12   »
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 30 31        

Site Stats

Total hits:
3046386
Today:
1606
Yesterday:
1972