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

아래아한글 2007은 2006년 한글날에 출시되었던 초창기 RTM 판을 어둠의 경로로나 잠깐 구해 쓰다가 다시 2005로 돌아와 버렸고, 저는 그 존재감을 1년이 넘게 잊고 지내 왔습니다.

그런데 얼마 전 한 지인께서 보내 주신 아래아한글 2007은 정말 사뭇 달라진 모습이었습니다.
사실 아래아한글이 그 때 이후로 3년에 가까운 시간 동안 아직까지 메이저 버전업이 없는 상태이긴 하지만 그래도 제품 개선은 정말 꾸준히 돼 오고 있었습니다. MS 식으로 표현하자면, 단순한 버그/보안 업데이트 수준을 넘어 서비스 팩 정도는 된다는 거지요.

각종 패치와 업데이트를 다 받고 나니 버전은 7.5.8.527이 되었습니다. 아래아한글도 날개셋과 마찬가지로 비주얼 C++ 2003 (7.1)로 개발되고 있는 건 여전하고요.
윈도우 비스타에서 “시스템 스타일” 테마를 쓰면드디어 Aero 반투명 프레임이 적용된 대화상자가 나오더군요. (2005는 그렇지 않았음.) 윈도우 XP 시절엔 MS 오피스 2003 테마가 그럭저럭 볼만 했으나 비스타에서는 아주 밍밍하고 보기 안 좋은 모양이 돼 버리기 때문에 차라리 아래아한글 2007 특유의 기본 블루 메탈 테마나 시스템 스타일 테마가 낫습니다.

지금까지 아래아한글은 대화상자에서 숫자만 입력 받는 에디트 컨트롤의 동작이 정말 기괴했습니다. 글씨 크기나 여백량 등. 세벌식 자판을 쓰고 있으면, 2004 이하에서는 Shift+알파벳의 고유 숫자도 동작을 안 하고, 0~9의 쿼티 숫자 배열도 동작을 안 해서 꼼짝없이 글자판을 바꾸거나 numlock 키패드만 써야 했습니다. 그러던 것이 2005에서는 Shift+알파벳 숫자는 인식되도록 개선됐고, 2007에서는 숫자 입력란에서는 아예 한글 글자판이 동작 안 하고 무조건 0~9 숫자만 인식하게 바뀌었던데 저는 차라리 이런 결정을 환영합니다. 정말 속 답답하던 동작 방식이었는데 무척 잘 했습니다.

글꼴을 고르는 콤보 박스가 화살표 키 선택만 가능한 게 아니라 이름을 입력도 해서 빠르게 찾을 수 있게 된 것은 매우 환영할 만한 기능. 비주얼 C++ IDE는 2003에서 2005 이후로 넘어가면서 이런 점에선 오히려 퇴보했죠. (물론 글꼴이 주류인 프로그램은 아니지만.)

그리고 운영체제 한글 IME로 비완성형 문자가 ?로 바뀌고 제대로 입력되지 않던 버그.. 드디어 고쳐진 것을 확인했습니다. 이제 아래아한글로도 <날개셋> 한글 입력기를 띄워서 각종 확장 한자나 옛한글까지 그대로 입력할 수 있습니다.

어떤 프로그램이 유니코드를 얼마나 잘 대비해서 만들어졌는지 측정하는 좋은 척도 중 하나는 파일 이름 인식인데요.
제가 보기엔 아래아한글은 아직도 윈도우 9x를 지원하느라, 혹은 TCHAR 같은 범용 자료형으로 Unicode-prepared된 코드를 작성해 놓지를 못해서... 하이튼 이 둘 중 한 이유로 인해 과감하게 스위치를 유니코드로 바꿔서 빌드 못 하고,
당장 유니코드 문자 지원이 절대적으로 필요한 부분에다가만 유니코드 함수를 임시방편으로 끼워넣은 거라는 인상을 받습니다. 윈도우 XP sp2 이상만 지원하는 MS 오피스 2007과는 달리, 한컴 제품은 똑같은 2007이 무려 윈도우 98 이상을 지원한다고 명시하고 있지요.. 물론 날개셋은 윈도우 95/NT4까지 다 지원.. 그러고도 유니코드도 100% 지원하죠.

임시방편이라고 생각하는 근거를 말씀드리자면..
영문 윈도우에서 HWP 파일은 한글이 섞인 파일도 잘 불러옵니다. 한글이 섞인 디렉터리 이동도 되고 파일 열기도 대화상자와 drag/drop 방식 모두 잘 되더군요. 이것만 해도 크게 개선된 것입니다. 하지만 HWP가 아닌 TXT 파일은 열리지 않았습니다. 더구나 “다른 프로세스가 파일을 사용 중이어서 열 수 없습니다”라고 에러 메시지도 ‘잘못’ 나오고요.따로 처리할 이유가 전혀 없는데도 파일 타입에 따라 유니코드 API 사용 여부를 따로 처리하고 있으니, 일관성 있는 처리가 아니라 HWP에다가만 임시방편 처리를 추가한 거라는 결론을 잠정적으로 내린 것이죠. 또한 ‘열기’ 대화상자라든가 타이틀에 뜨는 문서 파일 이름이 여전히 ???? 로 바뀌어 나온다는 것도 개선돼야 할 것입니다. 진짜로 여기서는 Ansi, 저기서는 유니코드 API를 섞어 쓴 것입니다.

한편, 아래아한글도 드디어 2007 나중판에서는 문서를 PDF로 저장? 인쇄? 하는 기능이 자체 포함되었습니다. 예전에 별개의 제품으로 팔던 PDF converter 엔진이 그대로 포함되어, 자체 글꼴인 HFT까지도 깔끔한 PDF로 바꿔 줍니다! 2.5 확장팩 시절의 추억의 신명 시스템 글꼴과 3.0/96 때의 #로 시작하는 수많은 글꼴들을 이제 깔끔한 PDF로 만날 수 있어 무한 감개무량하며 앞으로 아래아한글 쓸 일이 더욱 늘 것 같습니다.

단, 하나 옥의 티를 찾았는데요.
HFT 영문 이탤릭 글꼴이 PDF로 제대로 인쇄되지 않고 그냥 normal 글꼴을 기울인 형태로 바뀌어 버리더군요.
아래아한글이 내장하고 있는 신명조와 윈도우 운영체제가 내장하고 있는 바탕은 둘 다 ‘한양 시스템’에서 제작했으며 원도가 거의 일치합니다. 물론 후자가 영문의 폭이 좀더 크긴 하지만 비슷하죠.

하지만 둘의 큰 차이를 하나 꼽자면 전자는 영문에 이탤릭 전용 글꼴이 있다는 것입니다.
더구나 아래아한글 2.5 정도에서 추가된 걸로 기억하는 수식 전용 글꼴은 당시 교과서와 문제집 같은 출판물에서나 볼 수 있던 그 자형을 재현한 것이어서 더욱 의미가 컸습니다. 이것도 이탤릭체가 없으면 거의 무용지물이죠. 이것이 PDF로 만들면 여전히 되살아나지 않으니 개선이 필요하다고 봅니다.

끝으로 이건 극소수 매니아 계층 이외에게는 거의 의미가 없을 내용이지만 제품의 완성도 차원에서 하나 언급하겠습니다. 아래아한글의 한자 코드 체계와 관련이 있는 내용입니다.
아래아한글 2.0 이후에서부터 추가된 약 11000여 자의 제 2 수준 한자는 유니코드 BMP 영역에 대부분 이미 존재하지만(A급), 어떤 건 BMP에 없고 무려 surrogate 영역(B급)까지 가야 하는 것도 있으며 어떤 건 아예 유니코드 자체에 아직 정식 등재되지 않은 것(C급)도 있습니다. 물론 유니코드 버전이 계속 올라가면서 C급 한자라는 집합은 완전히 사라질 수도 있지요. 지금도 C급 한자는 거의 10여 자 남짓밖에 안 됩니다.

아래아한글은 이미 제 2수준 한자와 유니코드 사이의 변환 테이블도 다 갖추고 있고 이를 문자표에다 제공하고 있습니다. 하지만 정작 한컴 2바이트 코드로 저장된 파일을 가져와 보면 아래아한글이 지금처럼 유니코드 surrogate를 정식 지원하기 전에 워디안/2002 시절에 임시로 사용하던 변환 테이블을 여전히 수정하지 않은 것 같습니다.
가령 B급 한자에 속하는 0x531C는 한중일 통합 한자 확장 B인 U+20850 (surrogate 영역)이지만 이 글자를 한컴 2바이트 코드로 저장하여 불러와 보면, 옛날의 임시 주소인 U+A700이라는 엉뚱한 문자가 되지요.

아래아한글은 97에서 워디안으로 넘어갈 때 정말 큰 진통을 겪긴 했지만 그래도 그때 고비를 잘 넘긴 것 같습니다. 그때 HWP 파일 포맷이 딱 바뀐 이후, 지금은 아랍 어, 세로쓰기, 문서 워터마크 등 문서의 뼈대 구조를 결정하는 굵직한 기능이 엄청 많이 추가되었음에도 불구하고 워디안부터 2007까지 파일 포맷이 근본적으로 바뀌는 일 없이 하위/상위 호환성이 잘 유지되고 있으니까요.

다음 버전(아마 2010)은 지금 MS 오피스 다음 버전이 추구하고 있는 것과 마찬가지로 ODF 스펙 구현이 몰두 중이라고 합니다. 개인적인 생각은 아래아한글도 어서 워드처럼 개체가 사각형이 아닌 모양으로 본문을 감싸는 기능이 지원돼야 한다고 생각합니다. 앞서 지적했지만 유니코드 지원도 강화돼야 할 것이고, 좀더 욕심을 부리면 워드처럼 TSF A급 프로그램으로 발전하고 한양 PUA가 아닌 유니코드 낱자 결합 방식으로 옛한글을 지원해야 할 텐데, 참 가야 할 길이 멀군요!

Posted by 사무엘

오늘날 소프트웨어 업계에서 네이티브 기계어 기반 프로그램을 개발, 빌드하는 데 가장 널리 쓰이는 언어는 단연 C++이다.
C++은 잘 알다시피 C언어로부터 파생되어 C의 호환성을 유지하면서 거기에 OOP 요소를 가미한 매우 복잡한 언어이다. 클래스와 this 포인터, 생성자/소멸자. 상속, 정보 은닉, 다형성 따위는 언뜻 C처럼 보이는 코드의 함축성과 표현력을 월등히 끌어올려 주었다.

C++이 처음 등장한 것은 1983년이지만, 당대의 주류 컴퓨터 성능에 비해서 컴파일러 구현의 난해함, C++의 개념을 구현하기 위한 비용에 대한 논란 등등 때문에 실제로 C++이 업계에서 널리 쓰이기 시작한 것은 최소한 90년도가 지나서이다.

C++도 일종의 순수주의자의 관점에서 보자면 지저분한 특성, 욕 얻어먹을 면모가 굉장히 많다. 마치 윈도우라는 운영체제처럼.
하지만 상업적으로 성공하는 제품은 역시 무조건 성능이 우수한 것보다는, 현실과 이상을 적당히 잘 절충하고 대중화를 잘 한 녀석이라는 사실은 프로그래밍 언어라는 바닥에서도 적용되는 게 틀림없다.

오늘날 C++ 말고 동급 용도의 다른 어떤 언어에도 존재하지 않으며 앞으로도 차용되지 않을 기능을 뽑자면 아마 전처리기와 다중 상속이 아닌가 싶다. 강력한 만큼 괴악하고 폐단(?)이 심하기도 한 기능이어서이다. 요즘은 조건부 컴파일의 범위를 넘어서는 전처리기/매크로 기능은 거의 빠지는 추세이고 다중 상속도 인터페이스라는 다른 개념으로 대체되고 있다. 자바, C#, D 같은 언어의 스펙을 보면 그 alternative를 알 수 있다.

C++은 첫 등장한 후에도 꾸준히 변화해 왔다.
90년대 이후에는 템플릿이라는 어마어마한 기능이 추가되었으며
기능상으로 없던 게 추가된 건 아니지만, type-safety 강화 및 모호성 발생 예방을 위해서 특별히 취해진 조치도 상당하다. 가령, static_cast 같은 장황한 형변환 연산자가 추가되었으며 bool, wchar_t 같은 타입이 built-in으로 추가되었다. explicit도 이런 차원에서 추가된 키워드이다.

namespace는 각종 명칭들의 scope을 C와 같은 2차원적인 평면이 아닌 3차원적인 입체 계층으로 관리하게 해 준 엄청난 기능인 한편으로 C++ 컴파일러 구현의 난해성을 더욱 올린 기능이 아닌가 싶다. 컴파일러 개발자 내지 컴파일러를 돌리는 컴퓨터가 고생하는 만큼 프로그래머는 더 편해지고 프로그램을 유지 관리하기가 더 수월해지는 셈이다.

얼마 전엔 꽤 흔치 않은 개념을 코딩해야 할 일이 있었다.
템플릿 클래스 안에 static 멤버가 있었고, 이 멤버는 그 클래스가 자체 정의하는 구조체를 사용하고 있었다. 그래서 이 static 멤버를 클래스 바깥에서 초기화를 해 줘야 했는데, 그 멤버의 type을 클래스 바깥에서 표현이 제대로 되지 않고 자꾸 컴파일 에러가 나는 것이었다.

template<typename T>
class A {
        struct B {
        };
        static B data;
};

template<typename T>
A<T>::B A<T>::data;

(1) C++ 초창기.. 그러니까 한 터보 C++ 1.0 시절에는 static 데이터 멤버를 이렇게 바깥에서 정의 안 해 줘도 괜찮았다. 하지만 스펙이 바뀌어서 정의를 안 하면 링크 에러가 나게 나중에 바뀌었다.

(2) 또한 typename이라는 키워드도 C++에 템플릿이 추가되고 나서 한 박자 뒤에 표준화되어 90년대 중반에 도입된 것이다. 예전에는 class T만 가능했다가 문맥상 혼동을 없애기 위해 나중에 추가되었다.

어쨌든.. A라는 클래스가 템플릿이 아니거나,
혹은 data의 타입이 저런 자체 구조체가 아니라 전역 scope로 존재하는 다른 구조체 내지 그냥 built-in 타입이었다면.. 저렇게 선언하는 건 정말 일도 아니다.
그리고 솔직히 템플릿 클래스에다가 저런 식의 멤버를 만드는 일은 굉장히 희박한 것도 사실이다.

템플릿 클래스 내부의 자체 구조체로 선언된 static 멤버를 정의하는 방법은 아무리 생각해도 저것밖에 없는데 컴파일러가 도무지 말을 안 들어서 한 30분을 삽질했다.
그런데 문제 해결 방법은 기괴했다. typename을 앞에 추가하면 되더라..;;

template<typename T>
typename A<T>::B A<T>::data;

템플릿은 컴파일러가 실제로 생성해 내는 그 코드 자체가 아니라, 나중에 코드를 생성하는 틀, 말 그대로 템플릿에 불과하기 때문에 C++ 컴파일러에 템플릿이 첫 도입되었던 초창기엔 디버깅도 굉장히 어렵고, 실제로 템플릿을 A<int>처럼 인스턴스화해서 사용해 보기 전엔 컴파일 에러 자체도 잡아내기가 쉽지 않았다. 더구나 템플릿 클래스의 각종 구현부도 소스 파일이 아니라 헤더 파일에 다 선언되어 있어야 하기 때문에 한계가 많으며, 최적화 성능도 시원찮아서 code bloat의 주범이라고 욕도 먹었다. int형 코드 따로, short형 코드 따로 등등등.

하지만 지금은 상황이 많아 나아져서, 적당히 비슷한 타입으로 여러 템플릿을 사용하더라도 어지간한 건 void *형 포인터로 C 문법으로 general하게 코드를 생성할 정도로 컴파일러도 많이 똑똑해졌다. compile-time뿐만 아니라 link-time에 코드를 생성하고 한 obj 파일뿐만 아니라 여러 obj 파일 사이의 전역적인 최적화를 수행하는 기술이 도입된 것도 템플릿의 처리에 무척 유리하다. 압축으로 치면 RAR의 솔리드 압축 기능뻘 된다. 비주얼 C++은 6.0은 이런 기능이 없고, 200x닷넷급에서 최초로 이런 게 도입되었다.

C는 일단 그 가벼움과 C 특유의 이식성 때문에 영원히 절대 없어지지 않을 언어이다. (그 정도 고급 언어 중에 공용체, 비트 필드가 존재하는 언어가 또 무엇이 있을까? =_=;; C에 비트 회전 연산자가 없는 게 이상하다.)
그에 반해 C++은 동급이면서 더 깔끔하고 생산성 뛰어나고 GC(누수 메모리 자동 회수)까지 지원하는 다른 차세대 OOP 언어로 먼 미래에 대체될 수 있을 수도 있겠다는 생각이 들기도 한다. 특히 클라이언트에서 네이티브의 비중이 낮아질수록 지위가 역전되는 시기는 더욱 일러질지도 모르겠다.

윈도우 운영체제가 전통적으로 C언어식 API를 제공해 왔다면, 닷넷은 C# 기반이기도 하다.
하지만 20여 년에 가까운 컴퓨터 역사상, 무수히 쌓인 C/C++ 코드의 쪽수와 짬밥이 쉽사리 역전될 것 같지는 않기도 하고.. 미래를 예측하기란 참 어렵다. ^^;;

Posted by 사무엘

사람이나 물건을 싣고 공중을 비행할 수 있는 교통수단을 모두 통틀어 ‘항공기’(aircraft)라고 한다.
미사일은 항공기와 같은 역학 원리로 목표물을 향해 날아가지만 단순히 비행체일 뿐 항공기는 아니다.
또한 아예 지구 대기권을 벗어나 날아가는 로켓, 우주 왕복선은 비록 승무원이 탑승했다 하더라도 항공기라고 간주하지는 않는다.

항공기를 분류하는 큰 속성을 둘 꼽자면 경항공기냐 중항공기냐, 그리고 동력원이 있냐 없냐이다.
경항공기(aerostat)란 밀도를 공기보다 낮춤으로써 날아가는 항공기를 말한다. 동력원이 없는 경항공기는 기구(balloon)이며, 동력원이 있는 경항공기는 비행선(airship)이다.

밀도를 낮춰서 뜨기 위해서는 경항공기는 부피가 어마어마하게 커야 한다. 비운의 사고로 최후를 맞이한 힌덴부르크 호의 경우 생긴 것만 봐도 프로토스 캐리어를 연상시키는데, 타이타닉 호보다 덩치가 더 컸다. 마치 옛날에 자전거가 앞바퀴가 엄청나게 컸던 것 같은 그런 과도기 모습을 보는 것 같다. 물론 그래 봤자 수송 인원은 오늘날의 중형 제트 여객기 수준밖에 안 된다.

기구는 수송력과 이동성은 실용적인 가치가 거의 없으며 그저 하늘에 뜨는 것 자체에만 의미가 있다고 봐야 한다. 그나마 비행선이 20세기 초반에 여객 수송용으로 잠시 실용화된 적이 있다가 경제성, 안전 등 여러 문제로 인해 오늘날은 사라졌다. 공기보다 가벼운 대표적인 기체인 수소는 너무 위험하고 헬륨은 너무 비싸다는 게 문제이다. 공기보다 가볍다고 해서 기구가 한없이 위로 올라가면, 희박한 주변 공기 탓에 기구 내부의 공기가 펑 터져 나오고 만다는 것도 잘 알려진 현상이다.

그럼, 중항공기에 대해 살펴보자. 중항공기는 공기보다 무거우며, 양력이라는 물리 특성을 활용하여 공중에 뜬다. 중항공기 중에 동력원이 없는 것은 글라이더(glider)이다. 물론 글라이더는 스스로 공중에 뜰 수는 없기 때문에 마치 연을 처음 날릴 때처럼 자동차 견인 같은 도움을 받아야 한다. 동력도 없는 데다 밀도까지 높은 글라이더는 기구만큼이나 용도가 크게 제한되며, 탑승 인원도 거의 전투기 수준밖에 될 수 없다.

동력원이 있는 중항공기가 드디어 진정한 ‘비행기’(airplane)이라고 불릴 수 있는 교통수단이며 그 전신을 라이트 형제가 최초로 발명한 것으로 알려져 있다. 단순히 car이다가 이제 automobile로 바뀐 셈이다. 비행기는 크게 고정익 항공기와 회전익 항공기로 나뉜다. 전자는 고정된 커다란 날개를 통해 양력을 얻어서 공중에 뜨며, 이착륙할 때 활주로가 필요한 평범한 비행기이다. 후자는 우리가 헬리콥터라고 부르는 그런 비행기이다. 물론 수직 이착륙이 가능한 중간 형태의 비행기도 특수한 용도로 쓰인다.

따라서, '경비행기'는 말 그대로 덩치가 작은 중항공기를 일컫는 말이지만, '경항공기'는 부피면에서 비슷한 수송력을 지닌 중항공기보다 훨씬 더 크면 컸지 결코 작지는 않다는 것을 알 수 있다.

바퀴를 굴려서 지표면과의 마찰을 의지하여 움직이는 육상 교통수단과는 달리, 항공기와 선박에는 동력원이 없이 움직이는 방법이 존재한다는 것이 인상적이다. 비록 동력 기관이 발명된 것은 2, 300년 남짓밖에 안 되었지만, 육로와 해로는 성경에도 등장할 정도로 인류 역사상 가장 오래 된 교통수단이다.

그 반면 철도는 은근히 굉장히 최근에 발명된 교통수단으로, 처음 등장한 시기가 고작 1800년대밖에 되지 않는다. 항공은 역사가 더 짧아서 겨우 1세기 남짓이다. 그래서 항공업계에서 쓰이는 cabin, boarding, captain 같은 용어는 선박 분야로부터 고스란히 물려받은 용어이기도 하다. 다른 교통수단도 마찬가지이지만 항공은, 말세에 인류의 이동이 빨라져 이리저리 왕래하고 지식이 증가할 거라고 성경 다니엘서에 예언된 그 예언을 이루는 주된 도구임이 틀림없다.

그나저나 집채만한 비행기가 어떻게 공중에 뜨고 전투기는 묘기까지 부릴 수 있는지, 글라이더가 어떻게 뜨는지도 나는 도통 이해할 수 없다. 파일럿 류만 이해가 안 가는 게 아니라 항공기 류 자체가 별로 이해가.. ㅜㅜ
불과 몇백 년 전만 해도 당대 최고의 물리학자조차 공기보다 무거우면서 하늘을 나는 artifact는 존재 불가능이라고 단언을 했었지 않은가.

Posted by 사무엘

인천 공항 내부에 있는 스타라인이라는 무인 경전철은, 인천 공항에 확장 탑승동이 지어진 관계로 main 여객 터미널과 확장 탑승동을 연결하기 위해서 활주로 지하에 건설되었다. 둘 사이의 거리는 거의 900미터 정도 된다고 한다.
완공도 작년 6월이니 얼마 되지 않았으며, 한창 내가 병특 마칠 무렵에 생긴 것이었다. 작년에 미국 갔다 올 때도 이미 있었다는 얘기인데 나는 물론 그땐 그런 게 있다는 걸 알지 못했다.

물론 타는 곳은 승차권을 소지하고 보안 검색과 출국 신고까지 마친 승객 당사자만 들어갈 수 있는 ‘면세 구역’에 있기 때문에 일반 공항 방문객이 이걸 이용할 수는 없다. 확장 탑승동은 전구간이 면세 구역이다. 지난 3월 말에 중국 갔다 올 땐, 겨우 1시간 남짓 제주도 거리밖에 안 되는 노선을 이용하는데 탑승구까지 가느라 시껍을 했다. 비행기에서 내린 직후 공항의 면세 구역을 완전히 벗어나 환영객이 기다리고 있는 출구까지 나가는 데 거의 30분은 걸린 것 같았다. 수하물 찾을 것도 없었는데도! 아예 비행기 탑승권 뒷면에도 “탑승구가 졸라 멀리 떨어져 있으니 공항에 꼭 충분히 일찍 오셔야 합니다” 주의 사항이 찍혀 있었다.

스타라인 자체에 대해서 얘기를 좀 더 하자면, 일단 서울 지하철이나 심지어 공항 철도와도 굉장히 다르다. 차량은 3량 1편성이며, 운전석이 없는 무인 열차여서 앞뒤 터널 경치를 볼 수 있다. (물론 차량 자체도 일본에서 도입한 거라고 한다) 그리고 고무 바퀴이다. 한 편성 안의 모든 차량이 같은 외형으로 생겼으며 객실과 객실 사이를 이동할 수 없다. 다수의 항공 여객을 아주 짤막한 시간 동안만 수송하는 차량의 특성상, 좌석은 소수의 노약자석 말고는 없다.

또 하나 매우 중요한 사실이 있다.
재미 삼아 한 열차 안에서 짱박고 있다가 왔던 길로 되돌아가면 되는 일반 광역전철과는 달리, 이 열차는 장난으로 탈 수가 없다. 이 열차를 타기 위해 별도의 승차권이라도 사야 하는 것도 아니고 완전 무료인데도 왜 그럴까? 교통수단별로 시스템의 차이를 살펴보자.

고속버스 터미널은 심지어 승차권 없이도 아무라도 승강장까지 갔다가 잠시 차내에 들어가서 배웅을 하고 올 수도 있다. 한 차의 승객이 적기 때문에, 승차권 검사는 어차피 출발 직전에 차내에서 이루어진다.
그 반면 철도는 역내에 개집표기가 있어서 마치 고속도로의 톨게이트처럼 paid 영역과 non-paid 영역이 엄격하게 구분되어 있다. 일반 열차역의 경우 비승객이 paid 영역에 잠시 들어갔다 나오려면 입장권을 구매해야 한다. 비승객이 열차 객실 내부까지 들어가는 것을 금지는 하고 있으나 이를 막을 방법은 없다.

이제 국제선 공항은 어떨까? 입장권 같은 건 꿈에도 상상할 수 없다. (면세점 쇼핑 좀 하려고 입장권 구입? ㅋㅋㅋ) paid 영역 안에서도 출발 승객과 도착 승객이 드나들 수 있는 구간은 매우 엄격하게 분리되어 있다. 출발(출국) 승객과 도착(입국) 승객을 엄격하게 분리시켜야 하기 때문에, 스타라인 같은 열차 안에서도 두 부류의 승객이 섞여서는 절대 안 된다.
이런 이유로 인해 한번 여객 터미널에서 확장 탑승동으로 이동한 출국 승객은 다시 터미널로 돌아올 수 없으며 매번 열차는 한쪽 출입문을 열어서 모든 ‘출국’ 승객이 내린 것을 확인한 후에 거길 닫고 반대쪽 출입문을 열어서 ‘입국’ 승객을 받아들인다.

공항에 따라서는 여객 터미널과 탑승동이 일체로 연결되어 있지 못해서 paid 영역으로 들어간 후, 공항 건물에서 비행기까지나 또는 그 반대로는 저상 버스를 또 타고 이동하는 경우도 있다. 하지만 인천 공항은 그런 게 없고 모든 탑승구가 건물로 연결되어 있다. 철도역으로 치면 역사와 승강장이 따로 있는 옛날 역과, 100% 선상역으로 지어지고 있는 요즘 역의 차이 정도 된다고 할 수 있다.

그나저나 항공업계는 어찌 보면 가장 세계화 텃세가 강한 분야임에도 불구하고 대한 항공이 ‘코에어’로 사명을 바꾼다던가, 요즘 전철까지 유행처럼 번지고 있는 ‘승객’ -> ‘고객’ 이런 트렌드는 없는 것 같다.

Posted by 사무엘

인류가 만들어 낸 인공물(artifact) 중 현재 지구에서 가장 멀리 떨어져 있는 것은 우주 탐사선 보이저 1호/2호이다. 태양계를 떠나 지구로부터 한없이 멀어지고 있는 탐사선은 파이어니어 10/11호밖에 없는 줄 알았는데, 이것 말고도 더 있다는 걸 알게 됐다.

http://blog.naver.com/bk210850/140001208301
이들은 이미 태양-해왕성 사이 거리의 두 배에 달하는 지점마저 넘어섰다.

파이어니어 10호의 경우 2003년 초에 정말 가냘픈 신호가 감지된 것을 끝으로 교신이 영영 끊겼고, 이제는 수명이 다 해 죽은 것으로 추정된다. 하지만 보이저 탐사선은 지구로부터 100수십 억 km나 떨어져 태양계의 거의 끝자락에 도달했음에도 불구하고 지금도 예상 수명을 훨씬 초과하여 살아 있고 활동 중이라 하니, 정말 놀랍지 않을 수 없다. 물론, 그렇게도 멀리서 오는 탐사선의 미약한 전파를 잡아내려면 정말 넓고 크고 성능 좋은 안테나들을 세계 각지에 설치해 놔야 한다.

  (파이어니어 10호는 2000년 말에도 교신이 한동안 끊겨서 이거 실종이 아닌가 싶었으나 2001년 5월에 다시 신호가 와서 관계자들이 안도한 적이 있었다.)

무려 30여 년 전, 박통 시절에, 인텔에서 이제 막 4비트/8비트 마이크로프로세서를 만들어 내던 시절에 발사된 우주 탐사선이 지구로 각종 행성들의 사진을 보내 왔다는 게 정말 믿기 힘들다. 하다못해 JPG 압축 알고리즘도 없던 시절인데 말이다.
본인의 경우, 처음 봤을 때의 전율과 감격을 아직도 잊을 수 없는 사진이 뭐냐 하면 달 뒷면의 모습, 그리고 달과 지구가 나란히 포즈를 취하고 한 사진에 찍혀 있는 모습이다. 달은 지구에 비해서 얼마나 비정상적으로 기괴하게 큰 위성인지를 한눈에 알 수 있다. 인류가 이런 정보와 지식을 얻기까지 몇 년이 걸렸던가!

1960, 70년대엔 냉전 구도 때문이었는지는 모르겠으나 미국과 러시아가 우주 개발이 한창 전성기였다. 어떤 놈은 금성과 수성의 표면을 관측한 뒤 임무를 마치고 태양을 돌다가 과열되어 최후를 마치기도 했고, 어떤 놈은 금성 대기권에서, 어떤 놈은 금성 표면에서 1시간을 버티다 고열 고압을 견디지 못하고 파괴되기도 했다. 탐사선 이름은 기억 안 나는데, 목성 착륙을 시도하다가 그대로 파괴되어 버리고 연락이 끊긴 놈도 있었다. 목성은 크기만 작을 뿐 내부 성분은 태양 같은 항성과 완전히 똑같다고 하니, 착륙했다간 그 길로 짙은 고압 유독가스에 모든 게 분해되어 버릴지도 모르겠다. Quake 3 Area에 나오는 Fog of Death가 생각난다.

그런 시도가 있은 후 어떤 놈은 그렇게 특정 행성에서 말뚝 박고 최후를 마치는 게 아니라 아예 태양계 밖으로 영원한 질주를 시작한 것이다. 기존 행성의 중력을 이용하여 나름 초속 수십 km로 주행한다 하지만 그래 봤자 한 행성에서 다른 행성까지 가는 데 꼬박 2~3년씩 걸린다. 지구와 전파를 교신하는 데도 수십 분에서 한두 시간은 족히 걸린다. (태양-지구 사이의 거리인 1 천문단위가 전파로는 8분 20초 가량 소요)

그런데 여기서 중요한 것은, 자체 연료도 없는 우주 탐사선이 아무 때에나 그렇게 기존 행성의 중력을 잘 이용하여 태양계 바깥으로 갈 수 있는 게 아니라는 사실이다. 정확한 사항은 기억이 안 나지만, 1970년대 중반이 외행성들이 거의 일렬로 배열되어 백수십 년마다 한 번 찾아올까 말까 하는 절호의 기회였다고 한다. 이것도 어쩌면 영적으로 볼 때 우연은 아닌 것 같다. -_-;;

탐사선의 궤도를 계산하고 탐사선이 그 암흑천지 우주 공간 속에서 일말의 에너지를 받아서 전력을 생산하고 더구나 사진까지 찍고 지구와 교신하는 건 정말 수학과 과학 첨단 기술의 승리라고밖에는 말할 수 없다. 광량이 절대적으로 부족한 곳에서 항성도 아니고 행성 사진을 어떻게 저렇게 찍었을까? (극악의 노출 시간 동안 있는 빛 없는 빛 다 긁어모아서 찍지 않았겠나? -_-) 육안으로는 지구에서 관측할 수 없는 천왕성만 해도 아직까지 우주 탐사선이 보내 준 사진의 질이 별로 좋지 못하며, 그저 희뿌연 구 형상만 파악할 수 있는 실정이다.

컴퓨터의 발전 속도도 놀랍지만
어떻게 인간이 자체 동력으로 하늘을 나는 데 성공하고서 겨우 반세기 남짓만에 민간인 여객기가 전세계를 연결하기 시작하고 인공 위성을 띄웠으며 이내 우주 왕복선과 탐사선이 발사되었을까? 그런데 한편으로는 그로부터 거의 40년이 또 지난 지금은 왜 우주 개발 쪽으로 아무런 진척이 없을까? 신기하기 그지없다.

또한 우주를 아무리 뒤져 봐도 아직까지 태양과 지구 같은 이런 행성-항성 조합은 발견되지 않았고 생명 또한 발견되지 않은 것도 경이롭다. 달은 자전 주기와 공전 주기가 정확하게 일치하여 지구에서는 뒷면이 절대로 보이지 않으며, 지구에서 달의 겉보기 크기가 태양의 겉보기 크기와 일치하는 것도 우연이라고는 도저히 받아들일 수 없는 이상한 점인 것은 틀림없어 보인다.

Posted by 사무엘

우리는 C/C++ 언어에서 포인터란, 정수와 비슷한 형태이긴 하나 일반적인 숫자가 아니라 메모리 주소를 가리키는 특수한 자료형이라고 배운다. 포인터는 하드웨어 친화적이고(기계 입장에서 아주 직관적임) 매우 강력한 프로그래밍 요소이지만, 그만큼 길들여지지 않은 야생마처럼 위험 부담이 크다. 포인터 자체하고 포인터가 가리키는 메모리 영역이 따로 놀 가능성이 언제든지 있기 때문에 memory leak, dangling pointer 같은 위험에 노출되기가 매우 쉽다. 자유라는 약이 무질서라는 독으로 변질될 여지가 큰 것이다.

포인터의 값은 다른 지역/전역 변수의 주소로부터 얻어지거나 아니면 메모리 할당 함수를 통해 생성된다. 우리가 직접 상수 값을 대입하는 경우는 거의 없으며, 두 포인터의 값의 차이를 상대적으로 비교하는 경우는 있을지언정, 포인터가 나타내는 그 숫자 자체는 프로그래머에게 사실상 아무 의미가 없다.

사실 이 숫자가 무엇을 의미하는지는 C/C++ 언어의 영역이 아니라 그 언어를 돌리는 플랫폼 내지 운영체제의 영역으로 넘어가게 된다. 포인터란 그만큼 저수준인 존재이며, C++ 이후에 등장한 더 진보한 언어들은 포인터를 더 다루기 편하고 덜 위험한 형태로 어떻게든 감싸고 포장하고 더 상위 계층을 만들려고 애쓰고 있다.

우선 0은 NULL 값으로 유명하며, 윈도우 운영체제의 경우 0뿐만이 아니라 그 이후 0xFFFF 번지까지가 모두 오류로 간주된다. 즉, 이 영역은 운영체제가 어떤 경우에도 메모리를 가리키는 주소로 절대 인정하지 않으며, 오히려 응용 프로그램이 일반 숫자를 포인터로 착각하고 잘못 사용한 것으로 간주하여 무조건 오류를 일으켜 주겠다는 뜻이다. 이런 정책은 사실 프로그래머에게 굉장히 유용하다. 16비트 범위 안에 드는 작은 숫자는 메모리 주소보다는 인덱스 번호 같은 일반 숫자의 의미를 갖는 경우가 훨씬 더 많기 때문이다.

그 후 32비트 윈도우를 기준으로, 64KB부터 2GB까지는 응용 프로그램이 마음대로 사용할 수 있는 “사용자 영역”이다. 이 공간에 나의 EXE, DLL들이 로딩도 되고, 스택/힙 같은 메모리 공간이 할당되고 모든 일이 일어난다. 한 프로세스는 다른 프로세스의 이 영역을 넘볼 수 없다.

단 여기서 잠깐 예외가 있는데, 윈도우 9x는 앞부분의 64KB부터 4MB까지가 또 도스 및 16비트 윈도우 프로그램과의 호환성 유지를 위한 고정된 공용 주소로 예약이 되어 있다. 이런 이유로 인해 윈도우 9x는 4MB에 해당하는 0x400000보다 낮은 메모리 주소에다가는 32비트 바이너리를 불러올 수 없다. EXE/DLL의 preferred base가 이보다 더 낮은 주소인 데다가 재배치 정보까지 들어있지 않다면 그 바이너리는 윈도우 2000/XP 이상에서는 실행 가능하지만, 9x에서는 실행할 수 없게 된다. 비주얼 C++을 보면 EXE의 디폴트 기준 주소가 0x400000으로 잡혀 있는데, 이것은 윈도우 9x와의 호환성을 고려한 귀결이다.

NT급 윈도우는 0x80000000부터 커널이 사용하는 메모리 영역이 시작된다. 쉽게 말해 32비트 포인터로 가리킬 수 있는 4GB의 영역을 응용 프로그램이 2GB, 커널이 2GB로 반반씩 나눠 쓴다는 뜻이다. 물론 여기 부근에도 NT 계열과 9x 계열 윈도우는 메모리를 사용하는 방법이 대동소이한 차이가 존재한다.

NT급 윈도우에는 0x80000000 이전의 64KB 공간을 또 떼어서, 프로그래밍의 편의상 무조건 사용하지 않고 여기에 접근하는 것을 에러로 간주하는 영역을 또 두고 있다. 0~0xFFFF의 용도와 마찬가지이며, 말 그대로 사용자 영역과 커널 영역 사이에 안전을 위해 마련해 놓은 "메모리의 비무장 지대"인 셈이다.

한편 9x 계열은 그런 것은 존재하지 않는다. 대신 0x80000000부터 0xC0000000 사이의 1GB를 “공유 메모리 전용 영역”으로 지정하여, 일부 운영체제 커널 DLL과, 응용 프로그램들이 생성하는 ‘공유 메모리’(memory mapped file)를 이 영역에다 따로 두고 있다. 물론 NT 계열은 그런 것들도 다 구분 없이 사용자 영역에 저장된다. 실제로는 같은 물리 메모리를 가리키더라도 이를 가리키는 포인터의 값은 프로세스마다 다 다를 수 있다는 것이다. 이런 이유로 인해, 공유 메모리를 생성해 보면 9x 계열은 메모리 위치가 0x80000000을 상회하는 높은 주소인 반면, NT 계열은 심지어 자기 EXE가 로딩된 0x400000보다도 낮은 위치에 매핑이 된 경우도 볼 수 있다.

본인 생각에, 이것은 안정성을 약간 희생하여 좀더 작고 빠른 저사양 친화형 OS를 추구한 9x 계열의 고육지책으로 보인다. 사용자 영역에는 진짜로 각 프로세스마다 따로 돌아가야 하는 메모리만 넣고, 조금이라도 프로세스들이 공유할 여지가 있는 메모리는 여기에다가 따로 옮겨 둔 것이다.
이런 구조상의 차이로 인해 윈도우 9x는 NT 계열만치 커다란 메모리 맵 파일 내지 공유 메모리를 생성할 수 없다. 모든 응용 프로그램들이 1GB짜리 공간 안에서 바둥대며 살아야 하기 때문이다. 하지만 NT 계열은 설령 공유 메모리라 할지라도 마치 자기 개인 메모리 다루듯이 얼추 2GB 안에서 자유롭게 그런 것들을 만들어 보호도 잘 받으면서 쓸 수 있다.

나머지 영역은 전부 커널이 사용한다. 프로세스, 스레드 같은 각종 커널 오브젝트를 생성하고 가상 메모리 내지 페이지 파일들을 관리하기 위한 메모리이다. 쉽게 말해 메모리를 관리하기 위한 메모리. 무슨 커널이 최하 1GB에 넉넉잡아 2GB까지씩이나 주소를 차지하고 있어야 하냐 질문할지 모르는데, 결론부터 말하면 그 정도 공간은 반드시 있어야 하며 사실 2GB조차도 부족한 감이 있다.

NT급 운영체제는 커널 영역의 주소가 사용자 응용 프로그램으로부터 완벽하게 보호받고 있으며 user가 커널 영역 메모리로 접근을 시도하면 즉시 에러가 난다. 둘 사이에 앞서 언급한 "비무장 지대"까지 존재한다. 그러나 9x 계열은 그렇지 못하다.

BYTE *pb = (BYTE *)0xC0001000;
int i;
for(i=0; i<4096; i++) {
        printf("%02X ", *pb), *pb=*pb; pb++;
}

이런 간뎅이-_-가 배 밖에 나온 코드를 실행하면 NT급에서는 당연히 즉시 Access violaton 에러가 나고 프로세스가 사살되는 반면,
9x 계열은 놀랍게도 잘 실행된다. *pb=*pb로 해 줬으니 망정이지 다 0으로 덮어쓴다거나 하면 무슨 일이 벌어질까? 9x 계열이 왜 불안정할 수밖에 없는지 답이 딱 나올 것이다.

같은 32비트 안에서 사용자:커널이 2G:2G가 아니라 사용자한테 좀더 메모리를 많이 줘서 더 대용량의 데이터를 처리할 수 있게 한 3G:1G 부팅 방식도 있긴 한다. 사실 9x 계열도 앞서 말한 구조의 차이 때문에 커널 메모리는 1G이다.
하지만 이 경우 운영체제가 관리할 수 있는 가상 메모리의 이론적 최대치가 크게 감소하고 생성 가능한 커널 오브젝트(프로세스, 스레드, 공유 메모리 등)의 수도 더 줄어든다는 것을 알아야 한다. 또한 응용 프로그램도 large-address-aware하게 빌드되었다는 별도의 플래그가 있어야 한다.

Posted by 사무엘

윈도우 API로 다른 프로그램을 "실행", 즉 기술적으로 말하면 프로세스를 생성할 때 쓰는 함수는 크게 다음과 같다.

WinExec, LoadModule, CreateProcess, ShellExecute

어느 것을 사용하더라도 다음과 같은 정보를 받는 란은 꼭 존재한다:
실행 파일 이름, 명령인자, 그리고 메인 윈도우를 표시할 디폴트 방식(SW_SHOW 등).

즉, 윈도우 운영체제는 GUI 기반이라는 특성상 프로그램 메인 윈도우를 기본적으로 최대화하여 실행하라, 창을 숨겨 놓고 실행하라는 식의 지시를 내릴 수 있다. 이런 정보들은 WinMain 함수의 매개변수로 고스란히 그대로 전달된다. 물론 응용 프로그램이 그걸 무시하면 어쩔 수 없지만.

앞의 W..., L... 두 함수는 매개변수가 매우 단순한 편해서 쓰기는 편하나, 16비트 API 시절의 잔재로 치부되어 유니코드 버전조차 존재하지 않으며, 사용이 비추(discourage)되고 있다.

CreateProcess가 32비트 이상급 윈도우 API에서 표준으로 통용되는 가장 원초적인 프로그램 실행 함수이다. 그 대신 받아들이는 매개변수가 무진장 많으며 쓰기가 좀 어렵다. 여기에 대해서는 뒤에서 다시 좀 다루기로 하겠다.

끝으로 ShellExecute는 그 이름이 암시하듯, 커널 계층이 아닌 쉘이라는 꽤 상위 계층에서 구현된 함수로 단순히 파일을 실행하는 게 아니라 인터넷 URL을 기본 웹 브라우저에서 열거나 텍스트 파일을 메모장에서 여는 일도 다 담당한다. 동작 자체도 "open", "print" 등 아예 명령 문자열로 지정할 수 있다. 즉, 쓰임이 훨씬 더 포괄적이다. 이 함수도 EXE를 실행할 때는, 내부적으로 어차피 CreateProcess를 응당 호출한다.

C...는 리턴값이 프로그램의 실행 성공 여부를 나타내는 BOOL 형태인 반면, 나머지 세 함수들은 값이 약간 특이하다. 32보다 큰 정수를 되돌리면 성공을 뜻하고 그렇지 않으면 실패라는 뜻이다.
왜 이렇게 되었냐 하면 이 legacy 함수들은 원래 리턴값이 "인스턴스/모듈 핸들"이었으며 32 이하의 핸들값은 에러를 나타내는 값으로 의미가 예정되었었기 때문이다. 일종의 과거 잔재이다.

오늘날 윈도우 프로그래밍에서 HINSTANCE라고 부르는 핸들은, 과거에는 프로세스 ID와 비슷한 개념이었다. 이 핸들은 자신이 실행한 파일을 식별하는 정보도 있었던지라 동일 EXE를 중복 실행한 것을 WinMain 함수와 함께 넘어온 hPrevInstance로 분간할 수 있었다. 또한 EXE를 실행하여 생긴 인스턴스 핸들과, 그 EXE 안에서 DLL를 읽어들임으로써 이를 식별하는 모듈 핸들(HMODULE)도 별개의 존재였다.

하지만 32비트로 넘어오면서 운영체제의 메모리/파일 관리 모델이 완전히 바뀌었고 오늘날은 HINSTANCE와 HMODULE의 구분이 완전히 없어졌다. 단순히 프로세스 메모리 공간에 맵핑되어 있는 파일 이미지를 가리키는 포인터일 뿐이다. 메모리 영역 overlap에 따른 재배치만 일어나지 않는다면, 해당 DLL/EXE의 preferred base가 그대로 핸들값이 되는 것이다. 인스턴스 핸들이 이렇게 특정 프로세스 안의 주소 공간을 가리키는 포인터가 되는 바람에(national), 이제 이 핸들로 여러 프로세스들을 식별(international)하는 것은 불가능해졌다.

CreateProcess는 사용자가 보내준 파일 + 명령행 사이에다 null 문자를 잠시 삽입하여 토큰화를 했다가, 함수 실행이 끝난 후 문자열을 원래대로 되돌려 준다. C 언어의 strtok 함수를 떠올리면 된다. 이런 이유로 인해 명령행을 넘겨주는 포인터 영역이 read-only const여서는 안 되며 쓰기가 가능해야 한다. (물론 윈도우 NT 계열 운영체제에서 W 버전이 아닌 A 버전을 호출하면 어차피 쓰기 가능한 메모리 버퍼로 인코딩 변환이 일어나기 때문에 read-only 메모리를 넘겨줘도 문제될 건 없다.)

프로그램을 실행할 때는 이 프로그램에다 기본으로 넘겨 줄 각종 환경 변수, 콘솔 프로그램인 경우 표준 입출력 스트림의 핸들, 디버그 실행 여부 등 갖가지 고급 정보를 넘겨줄 수 있으며,
프로그램이 실행되었을 경우 생성된 프로세스의 핸들과 ID 등도 돌려받게 된다. 가령, 이 프로그램이 실행이 완전히 끝날 때까지 내가 기다려야 할 때 이 핸들에 대해 WaitForSingleObject를 호출하고 있으면 된다는 뜻이다. 단, 이 핸들을 Close하는 것도 우리 책임이다.

불필요하게 높은 계층에 자리잡고 있는 ShellExecute 대신, 커널 계층에 있는 CreateProcess를 좀더 간편하게 활용하기 위해 본인은 이 함수를 클래스로 감싸서 쓰고 있다. OpenFileName, TaskDialogIndirect (윈도우 비스타) 같은 복잡한 대화상자 UI 함수만큼이나 CreateProcess도

- 각종 디폴트 argument나 구조체들 챙기기
- 소멸자에서는 결과물로 받은 핸들들 닫아 주기
- 커맨드 라인을 알아서 자체 버퍼에다 생성하고, 필요한 경우 매개변수 전체를 따옴표로 싸 주기
- 이 프로그램의 실행이 끝날 때까지 기다리는 멤버 함수도 추가.

같은 자질구레한 일을 클래스로 감싸 놓으니, 프로그램 실행하기가 한결 편리하다.

Posted by 사무엘

비행기는 후진을 못 한다..는 것을 이번에 처음 알게 됐습니다.
과거에 철도 차량의 선로 분기 방법에 대해 알게 된 것 같은 새로운 지식입니다. 열차는 분기할 방향을 스스로 전혀 선택할 수 없기 때문에, 외부에서 분기 부분의 선로를 바꿔 줘야 하지요. 조금만 생각해 보면 당연히 알 수 있는 건데, 평소 실감이 잘 안 난 것 같습니다. 비행기도 마찬가지.

헬리콥터 부류를 제외한 일반적인 항공기는 바퀴(랜딩 기어)를 이용하여 일시적으로 도로를 주행할 수 있으며, 이는 이착륙을 위해서도 당연히 꼭 필요한 기능입니다. 그런데 도로 주행이라고 해 봤자 자동차처럼 바퀴에 구동축을 연결해서 엔진 동력을 따로 전달하여 달리는 게 아닙니다. 비행기는 그런 기능에 특화될 필요가 없죠.

  (후진 주행이 전진과 조금도 차이가 없이 가장 잘 발달해 있는 교통수단은 단연 철도 차량이다. 앞뒤로만 달릴 수 있는 유일한 1차원 교통수단이라는 점을 감안하면 이는 명백한 귀결이다.)

당연한 말이지만 비행기가 도로를 주행하는 방법은 바퀴를 따로 굴리는 게 아니라, 하늘을 날 때와 동일한 추진력으로 공기를 뒤로 밀어내는 것입니다. 그 힘을 받아서 바퀴는 저절로 굴러갈 뿐이죠. 추진력을 내는 방향을 바꾸려면 변속을 하는 게 아니라 날개와 날개 아래 팬의 배치를 바꿔야 하는데, 이는 어지간한 구조상 불가능한 일입니다. 이런 이유로 인해 비행기는 스스로 후진을 할 수 없으며, 할 필요도 없습니다.

그런데, 승객을 갓 태우고 출발을 시작한 비행기는 전방이 터미널 건물을 향하고 있죠. 고속버스와 마찬가지로 터미널과 수직 배치입니다. (철도는 무조건 플랫폼과 평행. 선박은 수직, 평행을 둘 다 쓰는 듯.)
후진부터 해서 방향을 바꿔야 주행을 시작할 수 있는데 이때의 후진은 어떻게 하는 걸까요?

그때는 견인 차량(tow car)의 도움을 받아야 합니다. 수십~백수십 톤에 달하는 비행기를 끌어서 방향을 틀어 줘야 하는 이 차량의 역할도 큰 것 같습니다. 그 뒤 비행기가 잠시 대기하는 동안 견인 차량은 옆으로 물러나고, 비행기는 스스로 활주로로 이동을 시작합니다. 이를 towing에 이어 택싱(taxiing)이라고 하죠. 동력 주체가 바뀌었다는 것을 기내 승객은 물론 눈치채지 못합니다. 저도 창 밖으로 다른 비행기가 그렇게 끌려가는 것을 보고서야 이 사실을 알게 됐으니까요.

이런 식으로 비행기는 출발하기 전까지는 다른 차량의 보조를 받는 경우가 흔합니다. 엔진을 정식으로 켜기 전엔 발전차가 기내 전력을 공급해 주기도 하고 심지어 냉방차의 에어컨으로 냉방된 공기를 이런 식으로 기내에 주입하기도 합니다. 활주로라는 발사대까지 느릿느릿 가서 대기하고 있다가 마치 철도 신호등처럼 이륙해도 좋다는 신호가 떨어지면, 그때부터 비행기는 엔진 소리가 한 옥타브 올라가면서 급가속 급발진을 시작하고, 이내 공중에 뜨게 됩니다.

이럴 때면, 공중에서 좌우 상하 전후 6방향으로 마음대로 움직일 수 있고 심지어 공중 정지조차 가능한 헬리콥터가 무척 부러워 보이긴 하지만 속도가 느리고 연료 소비 효율이 너무 안 좋은 게 큰 문제이죠. 한마디로 장거리 비행 및 대량 수송에 매우 부적합. 역시 군용 작전이나 취재, 사고 구조 활동 같은 특수한 용도로나 적격인 것 같습니다.

Posted by 사무엘

※ 1기: 1.x 커널

아래아한글 1.x 시절의 에디팅 엔진입니다. 잘 알다시피 단순한 plain text에다가 약간의 서식만 붙은 것 같은 초보적인 형태였죠.
글씨의 크기 조절은 가로 확대/세로 확대만 되고 가변폭 글꼴은 사실상 지원되지 않았으며, 문단 여백도 그냥 칸 수로 지정하던 시절이었습니다. 표는 선그리기 기능으로 그려야 했습니다.
문서의 파일 포맷은 최소한 1.0, 1.1, 1.2 이렇게 세 방식 이상이 존재했던 것 같습니다. 아래아한글 1.5x는 1.2 방식과 문서 파일 포맷이 동일하며, Alt+V (새 이름으로 저장)를 누르면 과거 1.1 방식으로 저장도 할 수 있습니다.

※ 2기: 2.0 커널

1992년에 출시된 2.0부터 97까지 굉장히 장수하여 안정화한 한컴 2바이트 코드 기반의 에디팅 엔진입니다. 글씨 크기를 포인트로, 여백은 mm 같은 단위로 지정할 수 있게 되고 색깔도 8종류 중 하나로 지정할 수 있게 됐습니다. 가변폭 글꼴의 표현이 가능해지고 그림, 표 같은 각종 개체를 넣을 수 있게 됐습니다. 개요, 스타일 같은 개념도 생겼죠.

문서 파일 포맷은 2.0, 2.1, 3.0으로 나뉩니다. 사실 아래아한글 2.1은 기능면에서는 2.0과 그렇게 큰 차이가 없으나, 글꼴 쪽으로 굉장히 많은 변화가 생겼고 또 2.1에서 문서 압축 저장이 추가됐기 때문에 포맷이 바뀐 것으로 기억합니다. 아래아한글 2.5는 파일 포맷의 변동이 없었기 때문에 2.1과 포맷이 동일합니다.
3.0은 하이퍼텍스트라든가 자체 벡터 드로잉 기능, 그리고 윈도우 OLE 데이터 같은 것을 저장해야 하는 데다, 때마침 2.1 방식 문서 파일의 암호가 크랙되어서 큰 논란을 겪기도 했기 때문에 바뀌었지 싶습니다.

※ 3기: 21세기 커널

정말 많은 우여곡절을 겪은 워디안 때부터 지금까지 큰 변화 없이 이어지고 있는 에디팅 엔진 겸 파일 포맷입니다. 아마 아래아한글은 앞으로 이 방식에서 더 바뀔 일이 없을 것 같습니다.
문자 인코딩이 시대의 조류를 따라 드디어 유니코드로 바뀌고 글씨라든가 용지의 크기 제한이 완전히 사라졌습니다. 색깔도 RGB 어느 색으로나 줄 수 있게 되었으며, 여러 쪽에 걸치는 표처럼 MS 워드의 앞선 기능을 대폭 수용하여 2.0 시절 커널과는 비교가 되지 않는 많은 기능들이 추가됐습니다.

더구나 워디안 이후로 아래아한글은 과거에 없던 여러 기능이 추가되고 있음에도 불구하고 예전과는 달리 파일 포맷의 하위 호환성은 비교적 잘 유지되고 있는 것 역시, 처음에 파일 포맷 설계를 확장성 있게 잘 한 덕택이라고 볼 수 있습니다.
아래아한글도 이제 open xml 기반 문서 파일 포맷도 적극 도입해야 하지 않나 싶습니다만 과연 실현될지?

- MS 워드의 경우 97~2003 커널이 가장 보편적으로 널리 쓰이다가 2007에 와서는 에디팅 엔진과 파일 포맷이 또 크게 바뀌었지요. 95 그 이전 기수는 잘 모르겠네요.
개인적으로 워드보다도 엑셀에서, 편집 가능한 셀 수가 크게 증가하고 색깔 제한이 없어진 것을 매우 환영합니다.

Posted by 사무엘

한메 타자 교사(HTT).
정말 전설적인 타자 연습 프로그램이며, 이후에 등장한 동일 분야 프로그램들의 근간을 제공했습니다.

아래아한글 1.x와 비슷한 연배의 프로그램이죠. 90년대 초반에 개발된 도스용 응용 프로그램들이 90% 이상 볼랜드 터보 C 2.0 기반이었고 그래픽 모드 동작을 위해 BGI 라이브러리를 사용한 것과는 대조적으로 HTT는 MS C 6.0 기반입니다. (비주얼 C++ 6.0이 아님!)

  당시에 통용되던 프로그램들을 좀더 살펴보면,
페르시아의 왕자도 1, 2 모두 MS C로 개발되었고 볼랜드 계열 빌드가 아닙니다.
아래아한글은 16비트 바이너리들은 전통적으로 볼랜드 컴파일러를 써 왔지만, BGI 라이브러리 기반은 물론 아니지요.

HTT는 제가 두벌식을 쓰던 시절과 맥을 함께 했습니다. 세벌식 연습은 도스용 한컴 타자 연습으로 주로 했고 HTT를 쓰지 않았거든요. 390에서 최종으로 갈아타던 시절에는 박 정만 님이 개발한 <광타>의 도움을 받기도 했습니다. 그때가 얼마나 불모지였냐 하면 390 말고 최종 연습을 정식으로 지원하는 프로그램이 “없었습니다.” 윈도우 운영체제는 말할 것도 없고 아래아한글 97이 제공하던 최종 자판에도 오류가 있었습니다. 지금이야 워디안 때부터 최종 자판이 제대로 지원되기 시작했고, 윈도우용 한컴 타자 연습에도 최종 배열이 추가되긴 했지만, <날개셋> 타자연습이 첫 등장하던 시절엔 정말 제 프로그램의 지위가 더욱 독보적이었었습니다.

한메 타자는 일부러 이렇게 만들기라도 했는지 문장 연습하는 감이 묘하게 좀 좋지 않았습니다. 키를 계속 누르고 있으면 글자가 생기는 느낌이 더디고 좀 latency가 느껴집니다. 아마 이것 때문에 그 당시 세벌식 연습을 한메 대신 한컴으로 사용하지 않았던가 생각됩니다.

두벌식으로는 단문도 700 이상은 정말 무리였지만 지금 세벌식으로 연습해 보니 800 넘는 것도 가뿐하군요. “드는 정은 몰라도 나는 정은 안다.”라는 문장은 완전 세벌식 최적화 문장이어서 1000을 넘기기도 했습니다.

그리고 베네치아 게임을 오랜만에 해 보니,
<날개셋> 타자 게임의 혹독하기 그지없는-_- 지옥 훈련에 단련돼 있는 저한테는 정말 애들 장난도 아니었습니다. 떨어지는 속도도 느리고 단어도 훨씬 더 짧고 쉬운 것들이고..!
1단계부터 시작해 보니 2만점대의 점수로 끝탄을 깼습니다. 껑충 바이러스가 두 번이나 걸렸습니다.

8단계부터 시작하니 클리어 시 보너스가 더욱 붙어 47000점대의 점수를 획득했습니다. 물론 단 한 번도 HP를 소모한 적이 없었으므로 재건 바이러스는 아무 의미가 없었죠.

<날개셋> 타자연습의 게임은 베네치아를 전혀 어려움 없이 가뿐하게 엔딩 보는 개발자 본인도 만신창이로 간신히 다 클리어할 정도로 월등히 더 어렵게 짜여 있습니다. 옛날 버전은 지금보다도 더 어려웠어요. -_-;; 난이도와 각종 주인공 밸런스들은 거의 05~06년 이후로는 더 수정 없이 완전히 정착한 듯합니다. 지금 이 상태가 딱 적당하며, 더 어렵게도, 더 쉽게도 만들 필요 없을 것 같습니다. 지금은 타자를 치는 인구가 훨씬 더 늘었으니 국민 평균 실력도 영어 실력만큼이나 더욱 상향 평준화해 있을 거라는 점, 모아치기 같은 세벌식 고급 입력 기능을 십분 활용할 수 있다는 점을 감안하면 말이죠.

옛날에 두벌식 쓰던 시절엔 베네치아도 6~8단계 정도만 되면 글자 떨어지는 게 무서워서 차마 못 할 정도였는데 정말 격세지감입니다. 그나저나 “에이즈 바이러스 퇴치!”와 “지뢰 바이러스”는 도대체 뭘 하는 놈이고 왜 넣었는지 모르겠습니다. 전자는 아무 효과 없는 꽝인 것 같고, 후자는 글자들이 지뢰에 부딪히면 점수가 깎이는 것 정도밖에 모르겠네요.

<날개셋> 타자연습 1.x를 개발하던 초창기 시절엔 한메, 한컴, 광타는 물론이고 신의 손, 번개손, 천타를 꿈꾸며 같은 당대의 경쟁(?) 프로그램들을 많이 참고했습니다. 개인적으로는 도스용 <신의 손>이 정말 완성도가 높다고 인정하며, 그 열악한 640*480 16컬러에서 어지간한 게임을 방불케 하는 비주얼 디자인을 연출해 낸 것에 최고의 점수를 주고 싶습니다. 게임도 나름 테마를 갖춰서 무척 잘 만들었죠.

아무튼, 한메 타자 연습을 보니 이런 저런 여러 생각이 들었답니다. 그리고 세벌식 만세입니다. =_=;;;

Posted by 사무엘