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

새로운 의약품이 개발되었을 때는 임상 실험을 차마 사람을 대상으로 할 수 없기 때문에 맨 처음에 동물을 상대로 실시한다. 사실 의학 내지 생명 공학을 연구하는 과정에서 실험용 흰쥐를 비롯해 적지 않은 동물들이 희생된다. 그래서 그런 연구소의 뒤뜰에는 동물 위령탑이 있을 정도이다.

그런데, 이쪽과는 완전히 다른 분야에서 또 인간에게 예상되는 위험을 대신 체험해 주는 존재가 있으니, 그것은 바로 더미(dummy)이다. 더미란 사람과 유사한 체구, 체중, 표면 재질을 갖추고 있는 마네킹 비슷한 인체 모형이다. 여기에다 온갖 센서들을 장착한 후 개발 중인 신차의 좌석에 곱게 앉혀 놓고 차를 충돌시킴으로써, 탑승자가 신체 부위별로 어떤 데미지를 받았는지, 생명에 지장은 없는지, 차 디자인이 안전 면에서 문제가 없는지를 연구진들은 꼼꼼히 분석하게 된다. 보통 시속 60km로 주행하다가 콘크리트 벽에 정면충돌하는 테스트가 가장 일반적인 형태 같다.

더미는 덩치는 옷 가게에 진열돼 있는 마네킹과 비슷하다. 그러나 용도는 그런 마네킹과는 근본적으로 완전히 다른 물건이다. 코스프레를 하는 일이 없으며 사람의 체중까지 흉내내어야 하기 때문에 마네킹보다 더욱 무겁다(지게차로 운반한다고 한다). 또한 대량 생산하는 물건이 아닌 데다 최첨단 센서 장비가 동원되다 보니 가격도 굉장히, 엄청 비싸서 한 개 가격이 억대에 육박한다고 한다. 쉽게 말해서 더미 하나의 가격이 거의 버스 한 대 가격이라는 뜻.

더미는 성인 남자, 임산부, 노인, 어린이, 아기 등 다양한 체구별 에디션(?)이 존재하며 이 한 세트가 일종의 더미 일가족을 구성한다. 실제로 자동차 회사의 연구소는 이런 더미 한 세트를 보유하고서 한 모델이 개발될 때까지 수십에서 무려 백수십 회에 이르는 충돌 테스트를 하게 된다. 한번 테스트용으로 사용한 더미는 강한 충격으로 인해 파손된 부품만 그때그때 교체하고서 거듭 재활용하는 게 일반적이나(가격의 압박), 심하게 손상된 더미는 어쩔 수 없이 폐기하고 새걸 구입하기도 한다.

한 가지 흥미로운 것. 충돌 테스트를 할 때 차를 어떻게 움직이는지가 궁금하지 않은가? 밖에서 차를 원격 무인 조종이라도 하는가 싶었는데 그건 아니고, 차는 가만히 서 있으면서 바닥의 무빙워크 같은 궤도가 위의 차를 날라서 벽에다 부딪히게 만든다고 한다. 궤도가 힘이 엄청 좋아야 할 것 같다.
쉽게 말해 실험 대상차는 시동을 걸지 않으며 바퀴가 굴러가지도 않는다는 뜻인데, 내가 옛날에 무슨 충돌 실험 동영상을 본 기억으로는 바퀴도 굴러갔던 것 같아서 좀 의아스럽다.

어쨌거나 교통사고란 정말 있어서는 안 될 비극이다. 그냥 순식간에, 너무나 허무하게 사랑하는 가족, 사회 구성원, 유능한 인재를 죽거나 불구 병신으로 만들며 그로 인한 사회적 손실은 이루 말할 수 없다. 특히 이놈의 음주운전 사고는 단순 과실치사가 아니라 고의성을 가미하여 살인 내지 살인 미수죄로 다스려야 하지 않나 생각해 본다.

Posted by 사무엘

컴퓨터 프로그램에서 뭔가 데이터를 저장할 기억 장소를 확보하는 방법은 크게 다음과 같은 세 가지이다.

먼저, 함수 안에서 선언하는 지역 변수이다. 지역 변수는 스택에다 할당되며, 그 함수와 사실상 일심 동체이기 때문에 거듭 실행되면 계속 스택을 점유하여 기억 장소도 계속 할당된다. 따라서 스레드 충돌 걱정을 할 필요도 없으며, scope을 벗어나면 소멸도 100% 자동으로 되기 때문에 memory leak가 생길 여지도 전혀 없다. 끼칠 수 있는 영향의 범위 자체가 가장 좁다.

그리고 전역/static 변수가 있다. 이들은 scope이 말 그대로 굉장히 정적이며, 프로그램 실행 기간 내내 살아 있고 프로세스 내부의 모든 스레드들이 공유한다. 잘 알다시피 static은 메모리에 저장되는 형태는 전역 변수와 완전히 같고, 접근성은 지역 변수와 같은 중간 존재이다.
이런 변수가 C++ 개체라면, 생성자나 소멸자 함수가 호출되어야 하는데 이는 main 함수의 실행을 전후하여 CRT 라이브러리가 알아서 해 준다.

마지막으로 heap에다 할당되는 동적 메모리가 있다. 이것은 가장 동적이고 자유로운 야생마 같은 형태의 메모리로, 프로그램 언어 차원에서 보장해 주는 scope이란 개념이 없다. 전적으로 프로그램이 양도 얼마든지 할당하고 아무 스레드에서나 해제 가능하다. 그 대신 C/C++에서 온갖 포인터 관련 버그, memory leak의 온상이 되는 존재이기도 하다.

그런데 멀티스레드 환경이 보편화하면서 첫째와 둘째의 또다른 형태의 중간에 속하는 scope이 필요해진 게 있으니, 바로 한 스레드 안에서만 global인 공간이다.
사실 표준 C 라이브러리조차도 멀티스레드 환경을 고려하지 않고 디자인되어 지금 문제되고 있는 요인들이 적지 않다.

함수의 실행 결과를 나타내는 에러 코드를 예전에는 그저 전역 변수 하나에만 집어넣으면 됐지만 멀티스레드 환경에서는 최소한 스레드마다 독립된 공간에 저장해야 한다.
strtok 함수는 예전에는 토큰 해석 위치를 그저 static 변수에다가 집어넣으면 됐지만, 이랬다가는 여러 스레드가 동시에 이 함수를 호출했을 때는 재앙을 각오하야 한다.
qsort 함수는 콜백 함수만 달랑 받지 콜백 함수에 따로 사용자가 지정한 데이터 따위를 넘겨 주지는 않는다. 결국 콜백 함수가 외부로부터 정렬 옵션 같은 걸 얻고자 한다면 전역 변수로부터 참고를 해야 하는데, 서로 다른 정렬 옵션으로 여러 스레드가 동시에 qsort를 호출하면 어떤 상황이 벌어지게 될까?

이런 기초적인 문제를 해결하기 위해 멀티스레드 운영체제는 thread local storage를 관리하는 기능을 제공한다. 윈도우 API에서는 TlsAlloc()으로 TLS 슬롯 번호를 하나 받아서 그 값을 전역 변수로 저장한다. (해제는 나중에 TlsFree()로) 그래서 TlsGetValue()와 TlsSetValue()에다가 아까 받은 TLS 슬롯을 넘겨줌으로써 machine word와 같은 크기의 정수/포인터 값을 읽고 쓰면 된다.

한 프로세스 안에서 동일한 슬롯 번호이지만, 이 함수를 호출하는 스레드가 무엇이냐에 따라 서로 제각기 독립된 값을 읽고 쓸 수 있음이 보장된다는 것이다. 스레드별로 공유해야 하는 값이 그냥 정수 하나라면 그 값을 바로 집어넣으면 되지만, 더 큰 영역의 메모리라면 따로 heap에다 할당한 메모리의 포인터를 집어넣으면 된다.

한 프로세스가 가질 수 있는 TLS 슬롯은 윈도우 95/NT4 시절에는 64개였다. 그러나 윈도우 2000/XP/비스타급에서는 수백, 1천 개가 넘어가도 괜찮게 바뀌었다. 나뿐만이 아니라 한 프로세스에 같이 로드되어 있는 다른 수십 개의 DLL들이 다 TLS 슬롯을 요청하기도 하기 때문에 TLS 슬롯 요청은 최소화하는 습관을 들여야 한다. TLS는 EXE보다도, 내가 생성하지 않은 스레드에 느닷없이 붙어서 돌아가야 하기도 하는 DLL을 만들 때 더욱 필요한 존재이다.

CRT 라이브러리의 DLL 에디션도 strtok 같은 함수를 구현하기 위해 TLS를 사용한다. 직전의 토큰 위치를 TLS 슬롯이 가리키고 있는 별도의 메모리에다 저장해 놓고 그때 그때 참고한다는 것이다.
또한 qsort처럼 콜백 함수가 사용할 데이터를 별도로 얻는 방법이 없는 함수를 사용하면서도 스레드 안전은 보장되게 코드를 짜야 할 때, 그 데이터를 TLS에다가 저장해 놓은 뒤 내가 짠 콜백 함수는 그 TLS를 사용하도록 만들 수도 있다.

TlsGet/SetValue()는 일종의 없는 scope을 새로 구현하는 함수이다. 그렇기 때문에 함수 실행 결과값을 기존 scope에 속하는 전역/지역 변수에다가 저장해 놓는다는 게 완전 무의미하다. 그러므로 콜백 함수가 TLS를 사용한다면 이 함수도 매번 무지막지한 빈도로 호출해야 한다. 따라서 이 함수는 다른 어떤 함수들보다도 성능에 초점을 맞춰 구현되어 있으며, 인자값의 검증을 거의 하지 않는다고 MSDN에 명시되어 있기도 하다.

물론 근본적으로 비주얼 스튜디오 2005에서 도입된 strtok_s는 TLS를 꺼낼 필요가 없이 토큰 위치를 아예 별도의 인자로 넘겨준 포인터에다 저장하도록 프로토타입이 바뀌어, 문자열을 중첩적으로 토큰화할 수도 있게 됐다.
그리고 qsort_s는 콜백 함수에다 넘겨줄 데이터를 별도로 같이 지정도 할 수 있다. 이렇게 하는 게 전역 변수급(TLS 포함) 메모리의 사용을 줄이고, 가능한 한 함수 인자와 지역 변수만 사용함으로써 모듈 사이의 독립성도 높이는 좋은 방법일 것이다.

DLL의 함수를 매번 LoadLibrary, GetProcAddress, FreeLibrary로 퍼 와서 쓰는 게 불편하기 때문에 import library가 존재하듯이, TLS도 비주얼 C++의 컴파일러 확장을 이용하여 좀더 쉽게 사용하는 방법이 있긴 하다. __declspec(thread)로 선언된 변수는 컴파일되는 바이너리의 내부에 .data, .text 처럼 섹션이 .tls라고 하나 더 생기고 거기에 보관된다. 하지만 이건 운영체제 관점에서 오버헤드가 굉장히 크고 옛날 운영체제에서는 동작하지 않기도 해서 잘 쓰이지 않는다.
#pragma data_seg로 섹션을 하나 더 만들어서 share 속성을 주어, 메모리 맵을 쓰지 않고 모든 프로세스에서 공유되는 메모리 영역을 만드는 것과 비슷한 차원인데, 물론 사용되는 기술 계층은 서로 차이가 있다.

우리가 다른 프로세스에서 멀티스레드로 동작하는 DLL을 만들고 있는데 우리 프로그램이 스레드마다 꽤 복잡한 C++ 오브젝트라든가(별도의 메모리 내지 리소스의 할당/해제가 필요한) 대용량 오브젝트를 운영해야 한다면 어떻게 해야 할까? TLS 슬롯에는 그 포인터밖에 집어넣을 수 없으며 메모리는 별도로 할당해야 한다. 그러나 디버거 쪽 훅을 설치하지 않는 이상 스레드의 생성, 소멸을 일일이 다 감시할 수는 없다. 그 대신 스레드마다 새로 생성된 TLS 슬롯의 초기값은 언제나 0임이 보장되기 때문에 오브젝트의 생성은 TlsGetValue의 값을 매번 검사하여 NULL일 때 하면 된다.

소멸은 약간 주의해야 한다. 프로세스의 실행 중에 스레드가 하나 실행이 끝났다면 DllMain에 DLL_THREAD_DETACH 통지가 오기 때문에 그때 우리 스레드 TLS 슬롯이 가리키는 포인터를 해제해 주면 되나, 문제는 모든 스레드의 소멸에 대해 일일이 이런 통지가 오지는 않는다는 것이다. primary thread의 실행이 종료됨으로써 DLL_PROCESS_DETACH 한 방으로 끝인 경우도 빈번하기 때문이다.

한 스레드가 여타 스레드의 모든 TLS 슬롯 값들을 enumerate하는 방법은 윈도우 API에 존재하지 않는다. 그렇기 때문에 각 스레드가 갖고 있는 포인터들은 별도의 전역 변수 링크드 리스트 같은 데에 별도로 관리하고 있다가 프로세스가 단번에 종료되면 이들을 한꺼번에 해제도 해 줘야 한다. 어차피 프로세스가 종료되는 마당에 memory leak 정도야 문제될 게 없지만, inter-process한 커널 오브젝트처럼 "cleanup"이 반드시 제때에 이루어져야 하는 자원도 있을 수 있기 때문이다.

물론 가장 이상적인 경우는 DLL을 만드는 우리가 매 스레드별로 Init 내지 Uninit 함수를 만들어서 우리 DLL을 사용하는 응용 프로그램이 스레드 실행의 시작과 종료를 알려 주는 것이다. 이렇게만 하면 모든 논란이 일축된다.

Posted by 사무엘

컴퓨터가 충분히 발전하여 오늘날의 운영체제 시스템 개념을 실현하게 된 것은 중앙 처리 장치가 최소한 32비트로 커지고부터이다. 보호 모드, 가상 메모리, 스레드 같은 것들. 4GB 정도는 돼야 주소 공간이 아쉬운 대로 넓다고 말할 수 있기 때문이다. 아무리 메모리 부족하고 열악한 임베디드 기기라 해도, 일단 최소한 디스플레이가 있는 general-purposed 컴퓨터라면, 16비트 시절의 원거리/근거리 포인터 같은 기법을 재도입할 정도로 열악하지는 않다.

물리 메모리와 가상 메모리의 대응을 운영체제가 CPU 차원의 지원으로 즉각 수행할 수 있게 되고 시분할 동시작업도 하드웨어 차원에서 할 수 있게 된 것은 소프트웨어 개발자에게 매우 큰 편의와 잠재성을 제공하게 되었다. 이를 입증하는 윈도우 3.1과 95의 큰 차이는 마우스 포인터 모양만 봐도 알 수 있다. 옛날에는 프로그램을 로딩하고 있을 때는 마우스 포인터가 완전 모래시계로 바뀌고 시스템 전체가 응답 불가 상태였지만, 지금은 화살표 오른쪽에 작은 모래시계가 붙고 시스템은 여전히 사용 가능하다(물론 좀 느려지기는 하지만). 또한, 모래시계 포인터는 해당 프로그램 안에서만 모래시계이지 다른 응용 프로그램에서는 여전히 화살표이다. 이른바 선점형 멀티태스킹 덕분이다.

단일 스레드 환경에서 사용자의 입력도 받으면서 작업도 동시에 수행하려면 타이머로 정말 찔끔찔끔 작업을 하거나, 작업 루틴 내부에서 수시로 입력을 체크(윈도우 API로는 PeekMessage 같은)해 주어야 했다. 효율은 효율대로 떨어지고 코드는 더욱 복잡해질 수밖에 없었다. 멀티스레드에서는 그런 번거로운 짓을 할 필요가 없다. 하지만 단일 스레드에서 전혀 신경쓸 필요가 없던 또다른 걱정거리가 생겼는데, 그것은 바로 스레드 동기화이다.

실행되고 있는 여러 스레드에 CPU 시간이 어떻게 분배되는지는 정말 전혀 예측할 수 없다. 심지어 a++; 같은 간단한 문장도 기계어로는 두세 개로 번역되는데 이 명령을 수행하던 도중에 스레드의 context가 바뀔 수가 있다. 여러 스레드가 동일한 데이터에 동시에 접근하여 값을 읽고 쓰다 보면, 다른 스레드에 의해 계산 전 값이 덮어써지거나, 아직 처리가 덜 끝난 중간 상태가 다른 스레드에 의해 뒤엉켜 버릴 수가 있다.

쉽게 말해서 a=0이고 a의 값을 1 증가시키는 스레드를 100개를 만들어서 아무 통제도 없이 이들을 동시에 실행시켰다고 가정해 보자. 그렇다면 스레드 실행이 모두 끝난 후 a의 값이 100이 되어 있을까? 천만의 말씀이다. 한 스레드가 a의 값이 0임을 인지만 한 찰나에 다른 스레드로 context가 넘어가고, 그 스레드 역시 a의 값을 0으로 인식하게 된다. 그러면 두 스레드는 모두 1이라는 값을 기록하게 되고.. 그렇다면 a는 도저히 100이 될 수가 없어짐이 명확하다. a++ 같은 지극히 단순한 연산이 이러한데 하물며 링크드 리스트나 트리 같은 복잡한 자료 구조를 변형하는 루틴에 여러 스레드가 동시에 접근한다면 어떤 재앙이 벌어질까?

멀티스레드 환경에서는 필연적으로 한 데이터를 여러 스레드가 공유하게 된다. 문서를 입력 받는 GUI 스레드와, 내부적으로 문서의 맞춤법 검사를 하는 스레드. 작업을 진행하는 스레드와 그로부터 작업 상황을 출력하는 스레드 등. 컴퓨터는 사용자가 프로그램을 짜 준 작업 중 어느 구간이 반드시 원자성이 보장되어야 하는지, 어느 구간이 반드시 여러 스레드들이 순차적으로 실행되어야 하는지를 알지 못한다. 이는 사용자가 지정해 주어야 하며, 운영체제는 스레드 동기화를 위한 여러 기법들을 제공하고 있다.

아무 통제 없는 무법천지인 멀티스레드 환경만으로는 프로그래머가 뭔가 의미 있는 작업을 하는 게 불가능하기 때문이다. 흔히 멀티스레드 환경을 여러 사람이 사용하는 한 화장실에다 비유하는데 무척 재미있고 적절한 비유 같다. 사람은 바글바글한데 화장실 문을 잠글 수 없다면 누가 감히 용변을 볼 수 있을까?

먼저, 여러 스레드들이 공유하여 시시때때로 값을 바꿀 수 있는 변수라면 C/C++의 경우 volatile로 선언하는 것이 필수이다. 고급 언어로 한 메모리 영역으로 표현되는 변수라 할지라도, 기계상으로는 메모리와 레지스터라는 차이가 존재할 수 있기 때문이다. 아울러 멀티스레드를 고려하다 보면 프로그램 모듈간의 독립성도 결국 고려하지 않을 수 없게 된다. 당장 쓰기 쉽다고 습관적으로 남발하던 전역/static 변수들은 멀티스레드 환경에서는 재앙으로 돌아올 가능성이 높다.

윈도우 운영체제는 정수 변수값을 1 증가하거나 감소시키는 것을 원자성이 보장되게 수행해 주는 InterlockedIncrement/Decrement라는 함수를 제공한다. 앞서 말했듯이 심지어 a++; 같은 간단한 연산조차도 컴퓨터에서는 CPU 한 사이클로 해결되지 않으며, 연산 수행 도중에 스레드 context가 바뀌고 결과가 꼬일 수 있다. 여러 스레드가 동시 접근할 수 있는 COM 오브젝트를 만든다면 reference count를 관리하는 함수를 이 함수를 이용해서 만들면 될 것이다. 고작 숫자를 1 더하고 빼는 것밖에 없지만 이것이 운영체제가 제공하는 가장 간단한 형태의 스레드 동기화 기능이라고 볼 수 있다.

이것보다 좀더 복잡하고 임의적인 루틴에 동기화 제동을 걸고 싶다면 임계 구간(critical section)이 좋은 선택이 될 수 있다. 크리티컬 섹션 오브젝트를 전역 변수로 선언하여 초기화해 준 후, 한 번에 한 스레드만이 차례대로 접근해야 하는 구간의 앞에 EnterCriticalSection을 해 주고, 끝에 LeaveCriticalSection을 해 주면 된다. 방법도 쉽다. 아까의 Interlocked* 함수는 크리티컬 섹션이 가미된 a++ 연산이라고 보면 된다.

이 정도면 다 된 것 같은데 동기화와 관련해서 또 필요한 게 있을까? 크리티컬 섹션은 간단하고 쓰기 쉽고 성능도 매우 좋은 반면, 타 스레드가 임계 구간을 빠져나올 기미가 안 보이더라도 한없이 기다리는 수밖에 없다. 또한 동일한 코드에 대한 스레드 접근만 제어할 수 있지, 다른 스레드(심지어 다른 프로세스)가 임의의 다른 작업을 끝낼 때까지 나의 스레드 실행을 멈추는 식으로 제어를 할 수는 없다.

이쯤 되면 그림이 나온다. 스레드 동기화 기능들을 수행하는 중요한 역할 중 하나는 busy waiting을 없애는 것이다. XT, 286 시절에는 컴퓨터 실행을 좀 느리게 하기 위해서 for i=1 to 5000: next 같은 문장을 썼지만 지금은 그건 큰일 날 짓이다. 자발적으로 일정 시간 CPU 시간을 내어 주고 프로그램 실행을 멈추는 Sleep 같은 운영체제 함수를 써야 한다. 어떤 스레드가 작업을 끝낼 때까지 쉬는 것도, while(bProcessing); 이런 식으로 수도 없이 뺑뺑이를 도는 polling은 절대 피해야 한다.

그렇기 때문에 일정 조건이 만족될 때까지 스레드를 CPU의 사용 없이 자동으로 기다리게 하는 함수가 있으며 이와 관련된 스레드 동기화 오브젝트들이 커널 차원에서 제공된다. “어떤 스레드가 임계 구간을 빠져나갈 때까지”란, 그 조건의 subset일 뿐인 것이다.

커널 오브젝트는 단순 크리티컬 섹션보다는 느리다. 이를 사용하기 위해서는 user 모드와 kernel 모드 사이의 전환 overhead를 감수해야 한다. 하지만 이들은 쓰임이 훨씬 더 범용적이며, 단순한 변수가 아니라 핸들과 이름으로 식별하기 때문에 inter-process하며 시스템 전체에서 통용이 가능하다. (이런 커널 오브젝트의 존재 여부로 프로그램의 중복 실행을 감지할 수도 있을 정도이다.) 크리티컬 섹션은 스레드의 waiting이 아주 implicit하게 일어나지만, 커널 오브젝트는 이를 WaitForSingleObject 같은 함수로 explicit하게 지정 가능하며 기다리는 한도를 제어할 수 있다. 또한 다른 커널 오브젝트들과 덩달아 함께 기다리게 할 수도 있다.

뮤텍스는 크리티컬 섹션의 커널 오브젝트 버전에 가깝고, 세마포어는 임계 구간에 들어갈 수 있는 스레드의 최대 개수를 지정할 수 있어서 뮤텍스보다 더욱 범용적이다.
한편 이벤트는 굳이 임계 구간이 아니더라도 사용자가 임의의 신호를 날려서, 그 신호를 기다리며 잠들어 있던 스레드를 깨울 수 있게 한 원초적이고 general-purpose한 동기화 수단이다.

결국 스레드 동기화 수단이 여럿 등장했는데, 구현 형태는 달라도 결국 여기에 적용될 수 있는 동사는 딱 둘.. ‘잠그기, 풀기’로 요약된다. 그래서 MFC는 이런 것들을 CSyncObject라는 클래스로 요약하여, Lock과 Unlock이라는 가상 함수로 공통 기능을 추상화해 놓고 있다.

참고로 이런 것뿐만 아니라 프로세스, 파일, 스레드 핸들 그 자체 같은 다른 커널 오브젝트들도 동기화 오브젝트에 해당하는 것이 여럿 있다. 그래서 해당 프로세스의 실행이 끝날 때까지, 혹은 스레드의 실행이 끝나고 파일 트랜잭션이 끝날 때까지 프로그램을 기다리게 하는 게 가능하다.

Posted by 사무엘

<날개셋> 한글 입력기가 기본 제공하는 텍스트 필터도 벌써 10 종류를 넘어섰군요.

매뉴얼에 나와 있는 대로, 텍스트 필터란, 일정한 텍스트 A가 있을 때 이것을 적당한 규칙대로 변형해서 B라는 텍스트를 만들어 주는 기능의 총칭입니다.
기본 제공되는 필터들은 기능의 성격에 따라 다음과 같은 다섯 그룹으로 분류됩니다.

※ 한글 입력과 관련된 것: 동작 방식이, 현재 사용 중인 한글 입력기 설정에 따라 달라집니다. 사실 텍스트 필터라는 개념 자체가 처음에 한글 입력기 기능의 자동화를 위해 도입된 것이기도 합니다.

  - 문자열을 글자판 입력으로: '한글'을 mfskgw(세벌식) 또는 gksrmf(두벌식)으로 바꿔 줍니다. 한글을 입력하는 데 필요한 영타를 재현하는 기능을 이렇게 필터라는 자동화 기능에다가 접목시켰습니다. 한글을 암호화(?)를 비롯해 다양한 형태로 가공하는 데 이 필터를 활용할 수 있습니다.
한글 로마자 입력 방식을 쓰고 있다면 이 기능은 한글을 얼추 로마자 표기법 형태로 바꿔 줄 수도 있습니다. 두벌식의 경우, 모호성이 발생하여 연속 입력이 안 되는 지점을 찾아내는 기능도 갖추고 있습니다.

  - 글자판 입력을 문자열로: 위 기능의 역변환입니다.
  - 한글 낱자 재결합: 한글을 현 입력기의 오토마타 설정대로 재결합하는 기능으로, 현재 오토마타 설정에 따라 한글을 모아쓰기와 풀어쓰기(또는 반풀어쓰기) 등 다양한 형태로 변환할 수 있습니다. 또한 한글에서 초성, 중성 같은 특정 성분만 남길 수도 있지요. 한글 입력 오토마타 알고리즘을 키보드를 일일이 두들길 때뿐만 아니라 자동화, 일괄 처리 용도로도 활용할 수 있습니다.

※ 한글 형태 변환과 관련된 것: 컴퓨터에서 한글은 여러 가지 형태로 표현될 수 있습니다. 호환용 낱자도 있고, 글자마디도 있고, 소위 첫가끝 영역도 있습니다. 이것은 어떤 점에서는 번거롭지만 어떤 점에서는 마치 memory hierarchy처럼 각 계층별로 장단점이 있으며 어쩔 수 없이 필요한 귀결이기도 합니다. 한글의 표현 형태를 변환하는 것도 텍스트 필터가 해야 하는 중요한 임무 중 하나입니다.

  - 한글 낱자 종류 바꾸기: <날개셋> 한글 입력기가 사용하는 첫가끝 낱자와(초-종성 구분도 되는), 일반적으로 운영체제에서 통용되는 호환용 낱자 사이를 변환합니다.
  - 한글 형태 정규화: 한글을 표현 가능한 가장 상위 계층으로 최적화하거나, 무조건 다 첫가끝 낱자로 풀어 써 줍니다. U+AC00 하나로 표현 가능한 '가'도 U+1100, U+1161로 풀어 주는 식이죠. 풀어 쓴 형태는 모든 한글에서 ㅏ를 ㅓ로 바꾸는 식으로 낱자 단위의 정밀한 일괄 처리를 할 때 필요할 것입니다.

※ 한국어 관련: 한글뿐만 아니라 한국어의 특성까지 가미하여 간단한 자동화 처리가 가능한 기능을 필터로 엮었습니다.

  - 한글을 소리나는 대로: "국밥"을 "국빱"으로, "국력"을 "궁녁"으로 바꿔 주는 매우 흥미로운 기능입니다. 한글 표기에는 반영되어 있지 않은 음운 현상을 표현하기 위해 별도의 hint 부호도 4종류 도입했습니다.
  - 숫자를 한글로: 300을 "삼백"으로, 45를 "사십오"로 바꿔 줍니다.
  - 한자를 한글로: 한자를 한글 독음으로 일괄 치환합니다. 아래아한글에도 있는 기능이죠.
  - 정렬: 한글의 모든 표현 계층을 감안하여 sorting 기능을 제공합니다. 아래아한글처럼 초-중-종 순이 아닌 역순 비교도 가능하며, 중복 항목을 제거하는 기능도 있어서 유용할 것입니다.

※ 문자 단순 기계 치환 관련: 여기부터는 이제 한글, 한국어하고는 그다지 관련이 없는 단순 편의 기능입니다.

  - 대소문자 바꾸기, 전각/반각 바꾸기: 에디터가 제공하는 제일 고전적인 필터 기능이고 self-explanatory하므로 더 이상의 자세한 설명은 생략.
  - 빈 줄 제거: 공란밖에 없는 빈 줄을 제거하고 줄 끝의 공란도 제거해 줍니다. 개인적으로 무척 빈번하게 유용하게 쓰는 필터.
  - 일괄 치환: 주어진 텍스트 블록 내에서 여러 "바꾸기" 작업을 일괄 수행합니다. 에디터의 기존 "찾기-바꾸기" 기능으로는 수행하기 힘든 A <-> B 맞바꾸기도 한번에 할 수 있으며, 특히 줄바꿈 문자도 찾거나 바꾸는 문자열의 일부로 지정할 수 있기 때문에 줄 앞뒤로 문자를 추가하거나 줄 삭제, 탭을 줄바꿈으로 바꾸는 기능도 수행할 수 있게 됩니다.

※ 시스템 인코딩 관련: 운영체제가 제공하는 다국어 쪽 API를 사용해서 문자 종류나 인코딩 관련 변환을 수행합니다.

  - 인코딩 변환: 인코딩이 잘못 지정되어 깨진 문자를 변환합니다. 컴컴컴컴 -> ────────, ´eCN¹I±¹ -> 대한민국 등.
  - 시스템 언어별 변환: 히라가나 <-> 카타카나 변환, 번체 <-> 간체 한자 변환 등을 수행할 수 있습니다. 대소문자 변환도 A~Z뿐만 아니라 유럽어 추가 알파벳에 대해서도 수행 가능하며, 알파벳의 쓰임이 다른 터키어 같은 언어에 맞는 변환을 할 수도 있습니다.
  - 코드 번호로 변환: 글자를 가 -> ACO0 같은 유니코드 번호 또는 B0A1 같은 특정 인코딩의 코드 번호로 풀어 주거나 역변환을 합니다. C언어 내지 HTML과 호환되는 접두사를 붙일 수 있으며, 이 기능을 이용하여 %AC%BD 같은 URL의 의미를 해독할 수도 있게 됩니다.

Posted by 사무엘

오늘날 운영체제의 표준 글꼴 포맷으로 널리 쓰이고 있는 TTF 내지 OTF는 내부적으로 쓰는 각종 구조체들이 기술하는 글립의 영역 크기가 16비트로 제한되어 있다.

이것은 TTF 파일이 제정되던 초창시에는 아주 넉넉하고 인심 쓴 공간이었다. 겨우 8비트 크기의 코드 페이지에 맞춰진 글꼴밖에 없던 서양에서, 그나마 “수천 자의 2바이트 한자를 써야 하는 동아시아 문자권”까지 국제화 차원에서 고려한답시고 크기를 넓힌 게 16비트였다. 무슨 포스트스크립트 글꼴은 그것마저 지원 안 돼서 한글 글꼴은 여러 파일로 나눠서 표현해야 하지 않았던가. 쓸데없이 비트 수가 크면, 쓰는 영역에 비해 불필요한 0만 뒤에 잔뜩 달라붙고 글꼴 래스터라이저를 더욱 ‘무겁게’ 만들게 된다.

하지만 지금은 시대가 달라졌다. 아무리 작은 임베디드 기기라도, 일단 사람과 직접적인 의사 소통을 하는 기계의 CPU는 일단 최하 32비트는 기본으로 먹고 들어간다. 실용적으로 가장 적합하면서도 가상 메모리라든가 현대적인 운영체제 기본 개념을 제대로 구현할 수 있는 최소한의 CPU 규모가 32비트가 아닌가 한다.

메모리 자원은 넉넉해지고 국제화의 중요성은 엄청 커졌다. 그래서 한컴바탕이라든가 Arial Unicode MS처럼, 모든 유니코드 영역 글꼴을 모두 담고 있는 글꼴의 필요성이 대두되고 있다.

아직 모든 문자가 16비트 안의 BMP에 있던 유니코드 2~3.0 시절까지는 그럭저럭 별 문제 없었고 6만 5천여 개라는 글립 개수 제한은 현실적으로 별 영향이 없었다. 하지만 이제 유니코드가 surrogate 영역까지 쓰고 집합 크기가 16비트 크기를 넘어서면서, 이제 단일 글꼴에다 유니코드 전영역 문자를 담을 수가 없어져 버렸다.

더구나 이 16비트라는 크기는 글자 코드 단위가 아니라, 글립이라는 그림 단위이다. 한 코드 페이지에 해당하는 글자가 여러 글립을 차지할 수가 있다. 조합형 한글 글꼴처럼 한 글자를 여러 글립의 묶음으로 표현하는 글꼴이 있다면, 그렇게 부품 글립이 들어가는 자리를 글립 인덱스 상으로 제외해 줘야 한다. 아랍어처럼 한 글자가 상황에 따라 여러 글립 중 하나로 달리 표현되는 문자가 있다면, 그런 것까지 고려해야 하기 때문에 실질적으로 표현 가능한 문자 개수는 더욱 줄어든다.

지금 컴퓨터의 두뇌가 32비트와 64비트 사이에서 달랑달랑 거리는 것처럼, 글꼴 쪽은 16비트 크기라는 글립 개수 한계를 어떻게 초월해야 할지 고민 중이다. 당연히 TTF 규격상으로 각종 구조체의 필드를 확장하고 새 버전 식별자만 부여하면 문제는 해결된다. 하지만 온갖 테이블들의 내부에서 바꿔야 하는 게 너무 많고 이 새로운 TTF는 이전의 어떤 운영체제/응용 프로그램에서도 인식 못 하는 듣보잡 포맷이 되고 말 것이다. 결국 문제는 호환성이다. =_=;;

Posted by 사무엘

2003~2004년의 역사적인 Looking for you 사건을 계기로 본인의 혼이 철도와 완전 동화해 버린 후, 지금까지 본인은 철도에 대해서 많은 글을 써 왔다.
하지만 그 범위는 '우리나라'로 한정되어 있었다. 우리나라의 철도 노선, 철도 차량 계보, 심지어 더 나아가서 우리나라의 고속도로 구조, 지형, 도시 교통 양상 등등..

특히 그 분야에 그 정도로 미쳐 버린 사람치고는 의외로 일본 철도에 대한 관심과 지식은 별로 없었다.
나는 솔직히 일본 문화와는 별 흥미나 인연이 없었고 앞으로도 없을 것 같다. 딱 하나 예외 케이스인 개그 만화-_-만 빼면 일본 애니나 게임 등과는 담을 쌓고 살아 오기도 했다. 하지만 오늘은 일본 철도에 대해서, 특히 신칸센을 위주로 개념을 좀 정리해 보고자 한다.

일본은 로봇, 자동차 쪽 기술이 강하다는 건 잘 알려진 사실이고 철도도 한국과는 비교도 할 수 없이 앞서 있다. 철도가 문화이며 생활의 일부이다. 우리나라와는 근본적으로 다르다. 그런 배경 하에서 은하철도 999 같은 애니도 나온 게 아닐까 한다. 건널목을 지나는 디젤 동차를 아버지와 아들이 나란히 디카로 사진 찍는다거나, 심지어 아버지는 시각표 펼쳐들고 "맞은편 열차가 올 때가 됐다!" 하면 아들은 카메라로 촬영한다. 이 얼마나 감동적인 모습인가!

시속 200km를 돌파한 신칸센 첫 개통이 1964년이요, 도쿄 지하철 첫 개통이 1927년이니, 철도 핵심 기술의 총아라 할 수 있는 지하철과 고속철이 모두, 한국보다 시기만으로 쳐도 거의 반세기 가까이 앞섰다. 그것도 전부 자체 기술과 자본이다.
1900년대 초, 조선을 식민지로 영원히 부려먹으려고 장기 계획을 짜면서도 맨 먼저 생각한 것은 바로 치밀한 지형 측량과 철도 건설이었다. 자기네는 협궤이면서 한반도에 간선 철도는 표준궤로 놓았다. 아무리 생각해도 정말 치떨리고 무서운 전략이었다.

일본은 영국의 영향을 받아 모든 교통수단이 좌측 통행이고 운전대가 우측에 있다. 100% 표준궤(1435) 일색인 우리나라와는 달리 일본은 간선인 신칸센을 제외한 도시 철도는 협궤가 대다수를 차지한다. 수인선 같은 762mm협궤는 아니고 1067mm인가 한다. 우리나라가 70년대에 서울 지하철용으로 일본 히타치 사에다 주문해서 도입한 전동차는, 스타일만 일본식이었지 사실 본토 일본에서도 안 쓰는 어마어마한 대형 전동차였다. 그것도 한 편성에 10량씩이나 후덜덜!

작고 가벼운 협궤 차량의 잠재적 위험성은 지난 2005년 일본 어딘가에서 난 전동차 탈선 추락 대형 사고에서 한 번 입증된 바 있다. 서울 지하철로는 도저히 일어날 수 없는 현상이 아닐까 한다.
도쿄에도 야마노테 선이라고 순환 지하철이 있긴 하지만, 차도 작고 노선 길이도 서울 2호선에 비할 바가 못 된다. 차량뿐만 아니라 노선도 한국의 지하철은 스케일이 굉장히 크다.

하지만 물리적인 규모와는 달리, 일본의 철도의 인프라는 한국보다 모든 면에서 스케일이 크다. 한국 코레일은 철도청이라는 정부 직속 기관이었다가 그나마 공기업화한 수준인 반면, 일본 철도는 민영화도 훨씬 일찍부터 더 개방적으로 진행됐으며, 사설 운영 기관도 많고 그래서 역마다 회사별 개성도 더 짙다(나쁘게 말하면 한국 같은 완벽에 가까운 환승 할인과 요금 통합을 기대하기도 어려움). 민영화의 특성상 일본의 철도 운임은 양국의 경제력을 감안하더라도 한국보다 훨씬 더 비싸다. 그 대신 비싼 만큼 노선도 풍부하고 서비스나 정시성 따위도 한국보다 월등히 뛰어나다. 철도 여객 회사들은 운임 말고도 부동산, 임대업 등 다른 사업 분야 진출을 통해 많은 이윤을 올리고 있기도 하다.

영국, 일본 같은 나라의 지하철 기본 운임은 한국으로 치면 거의 택시 기본 요금 정도는 된다고 봐야 한다. 하지만 한국처럼 철도와 버스가 경쟁하는 이상한 구조가 아니어서 간선 버스라는 게 존재하지 않는다. 장거리 간선 이동은 100% 철도이며, 철도가 좀 큰 사고가 나거나 파업이라도 하면 자가용을 이용하지 않는 승객들은 진짜 교통이 마비되고 만다. 철도가 깊숙한 생활의 일부이기 때문에, 열차 지연으로 인한 지각은 학교나 회사에서도 공식 인정되는 면책 사유이며, 그런 지연 사고라도 나면 역마다 지연 증명서를 떼 주는 것도 지극히 보편화해 있다.

그럼 지금부터는 신칸센에 대해서 알아보자.
철도 동호인이라면 신칸센이 후지 산 아래로 달리는 사진을 한번 쯤 본 경험이 있을 것이다.
하지만 우리나라의 고속철 차량 후보로는 신칸센은 일찌감치 배제되었는데 그 이유로는 같은 표준궤이지만 차체의 크기가 한국의 기존 철도역 구조와 맞지 않았던 것(신칸센이 더 컸음), 당시엔 신칸센이 해외 수출 사례가 전무했다는 것, 기술 이전에 시큰둥했던 것 때문이었다.

  (하지만 늦게 개통한 만큼 우리나라 KTX도 하드웨어적인 면에서는 세계 어느 고속철에 내놔도 뒤지지 않는다. 시속 300~310으로 이 정도로 상시 주행할 수 있는 선로와 차량을 갖춘 나라는 정말 드물다. 일본이나 프랑스에서 성공했다던 시속 4, 500 달성은 시운전이며, 언제까지나 시운전일 뿐이다.)

신칸센은 차량 구조가 근본적으로 한국에서 아직 찾아보기 쉽지 않은 동력 분산식 전동차이다. EEC 내지, 좀더 까놓고 말하면 오히려 지하철과 비슷한 형태라는 것이다. 전동기의 구동음을 객실 아래 바닥에서도 들을 수 있다. 심지어 선두차에도 새마을호 PP 동차보다도 좌석이 많다.
기관차+객차 구조에 너무나 절어 있는 한국 철도와는 완전히 다른 양상이라 하겠다. 한국의 철도 운영이 그만큼 일제 강점기 이후로 변한 게 별로 없고 많이 경직된 것도 사실이다. 하지만 실용적이기는 동차 형태가 더 실용적이며, 앞으로 공항 철도 직통 열차라든가 신창 급행 좌석형 동차 등, 우리나라에서도 전기 동차를 더욱 많이 보게 될 것이다.

또 하나.
신칸센이 역에 정차해 있는 사진을 눈썰미 있게 살펴본 분이라면, 승강장이 전부 "고상홈"이라는 것에 적지 않게 놀랄 것이다. 분명 서울-부산 장거리급 열차인데, 열차가 생긴 모습도 그렇고 타는 방식도 마치 지하철 타듯이? 이것도 한국에서는 찾을 수 없는 일본 신칸센의 문화라 할 수 있겠다.

신칸센의 초창기 차량은 앞이 마치 구형 비행기(정확히 말하면 전투기)처럼 동그랗게 생긴 소위 "0계"이다. 처음에는 비주얼 스튜디오 .NET이라고만 불리다가 2003이 등장하면서 이전 제품이 2002라고 불리게 된 것처럼, 0계라는 숫자는 후속 차종이 등장하면서 서로 구분을 위해 나중에 붙여진 이름이다. ^^;;

이 0계의 외형은 증기 기관차만큼이나 기차의 대표적인 상징물이 된지라 심지어 우리나라에서도 "경축 어디어디 전철 개통" 이런 현수막이나 전단을 보면 신칸센 0계 그림을 심심찮게 볼 수 있을 정도이다.
그 후 신칸센의 디자인은 점차 개선되어 앞은 점점 새 부리처럼 더 뾰족해지고 세련되게 바뀌었다. 500계가 그 변화의 극치가 아니었나 싶다. 앞이 워낙 작고 뾰족한지라 선두차의 운전석이 뒤로 꽤 밀려나고, 덕분에 열차 탑승 정원도 약간 줄어들 정도였다.

그런데 신칸센이 정말 무지막지하게 비싸다는 것도 알 만한 사람들은 알 것이다. 같은 노선의 국내선 비행기보다도 비싸며, 서울-부산 정도 거리의 편도 운임이 우리 돈으로 최하 10몇 만원씩은 깨진다고 봐야 한다. 그래도 "출장은 신칸센으로!"이런 구호가 있을 정도로 신칸센은 일본인들의 주된 교통수단으로 쓰이면서 생활을 바꿔 놓고 있다.

KTX가 2004년에 첫 개통했을 때 경부선 이용객이 예상 수요의 70% 남짓밖에 안 됐다고, 정치적 실패라고 그때 언론이 떠들썩했는데, 지금 생각하면 "안정화가 덜 돼서 그렇게도 욕 얻어먹던 그 시절에도 벌써 70%씩이나 탔으면 별로 실패는 아닌 것 같은데?" 싶기도 하다.

사실 2005년 코레일 출범 이후, 내가 보기에 새마을호의 몰락은 무척 안타깝지만 걔네들이 KTX로 영업을 못 하지는 않았다. 일제 강점기 이후로 별 차이 없는 너무나 열악한 노선만으로 어떻게든 사람들이 최대한 많이 KTX를 타게 만들고 일반열차와 환승 연계가 잘 되게 하려고 애썼다. KTX 이용객은 꾸준히 증가하기 시작했고, 3천억짜리 간이역이라고 엄청 욕 얻어먹었던 광명 역도 많이 회생하긴 했다. 극심한 초만원으로 시달리는 경인선 전철과 더불어 경부 고속선은, 코레일의 흑자 양대 산맥인 것은 분명한 사실이다.

KTX는 전기로 달려서 수송 원가가 매우 저렴한 데다, 속도도 빨라서 운임을 비싸게 받을 명분이 되고 한 편성으로 무려 900명 가까이를 태울 수 있다. 어차피 접근성 면에서는 자동차한테 경쟁이 안 되고 무궁화호급 운임으로는 수지도 안 맞으니 거기는 포기하고 코레일 경영자라면 그 누구라도, 뇌가 있다면 어떻게든 KTX에다 올인해서 이윤 챙겨야 한다는 결론을 이끌어내지 않을 수 없을 것이다. KTX에 사운이 걸려 있다.

  (승객 입장에서는 싸고 좌석이 편한 새마을호와, 빠르고 비싼 KTX가 상호 경쟁하는 것을 원하지만, 경영자 입장에서 새마을호는 위상이 어중간하고 완전히 KTX 시다바리로 전락시키기도, 처분하기도 곤란한 계륵 같은 열차가 되었을 것이다.)

승객의 user experience 만족도 향상을 위해 고속신선 주행 최대 시속을 305에서 310으로 올려 잡은 것엔 나름 센스도 부렸다는 생각이 든다. 아무쪼록 2단계 구간도 속히 개통되어 KTX가 대구-부산 고속도로도 멀찌감치 따돌리고, 서울-부산을 진짜 2시간대 이내로 어서 연결해 줬으면 좋겠다.

그나저나 개통 첫 해도 아니고 작년의 이용객이, 예상 수요의 70%는커녕, 7%였다던 공항 철도야말로 정말 어찌 할 방법이 없는 것 같다.
맑고 신선한 인천 영종도 공기를 서울로 수송하기 위해 만든 철도라는 비아냥까지 나돌았다고 하니. ㅜㅜ

Posted by 사무엘

윈도우 비스타에서는 모르긴 몰라도 그래픽/사운드 기술과 관련된 계층이 굉장히 많이 바뀌었습니다.

※ 비디오 (그래픽)

예전에 글로 쓴 적이 있지만 제가 가장 먼저 인지한 큰 변화는, 이제 동영상 화면까지 Print Screen 키로 바로 캡처가 된다는 것. 그것도 Aero (desktop window manager)가 가동 중일 때뿐만 아니라 DWM이 돌아가지 않는 고전 모드일 때도 동일하게 잘 됩니다. 옛날에는 인터넷 같은 데서 웹브라우저 창을 옮기면 그 안에서 돌아가던 동영상은 위치가 이동하지 않거나 느릿느릿 굼뜨던 현상도 심심찮게 볼 수 있었는데 이 역시 비스타에서는 아련한 추억이 됐지요. 그래픽 카드와 운영체제의 발전에 힘입어, 드라이버 계층에서의 어떤 큰 변화가 생긴 게 틀림없습니다.

멀쩡하게 상위 계층의 윈도우 API만 썼다면 비스타라고 해도 안 돌아갈 이유가 없는데, VMware, 메이플, 비주얼 스튜디오 같은 프로그램들이 옛 버전이 비스타에서는 제대로 동작하지 않아 버전업을 해야만 하는 이유도 저런 ‘저수준에서의 미묘한 변화’ 때문이라고 풀이할 수 있겠습니다. XP와 비스타는 각종 하드웨어 드라이버들이 호환되지 않죠. 하지만 비스타와 7은 드라이버 차원의 호환이 유지될 것으로 알려져 있습니다.

윈도우 XP부터는 심지어 운영체제 설치 GUI나 안전 모드에서도 VGA 640*480 16컬러는 완전히 자취를 감추었고, 하이 컬러 이하로는 디스플레이 모드가 설정이 되지도 않습니다. 게임용 3D 그래픽 가속까지는 뒷받침을 원활히 못 하더라도, 최소한 1024*768 하이컬러 이상급의 그래픽 모드는 메인보드가 내장하는 VBE 규격만으로도 지원되게 컴퓨터 규격이 향상됐기 때문이지요. 물론 이것만으로는 비스타 체험 지수는 1밖에 나오지 못하며, 창을 끌어 보기만 해도 답답함이 느껴지기 때문에 비디오 카드 드라이버 업데이트는 필수입니다.

XP보다 전에 선보였던 윈도우 2000은 시대가 시대였으니만큼 여전히 16/256컬러의 잔재를 볼 수 있습니다. 하지만 설령 안전 모드의 16컬러 표준 VGA에서 실행될 때라 하더라도, 그래픽이 쉴 새 없이 변하고 있는 곳에 마우스 포인터를 가져갔을 때 포인터가 깜빡거리거나 사라지지 않습니다. 윈도우 9x 시절에는 상상도 할 수 없었는데! 이걸 보고도 저는 당시 2000은 보통 운영체제가 아니라는 생각을 했었습니다. 하드웨어 차원의 지원이 필요하거든요.

90년대 말, 윈도우 95급 컴퓨터 시절에만 해도(메인보드의 폼 팩터가 슬슬 AT에서 ATX로 넘어가던..), 운영체제의 표준 디폴트 포인터만 깜빡임 보호가 되었지 사용자 정의 포인터는 여전히 깜빡거렸습니다. 비디오 카드의 성능이 썩 좋지 못했다는 뜻이겠죠. 하지만 몇 년 사이에 이마저도 깜빡임이 완전히 사라졌습니다.

아, 그러고 보니 이것도 그래픽 체계의 변화와 관계가 있는지는 모르겠지만, 비스타는 알 수 없는 이유로 인해 콘솔을 전체 화면 모드에서 실행하는 기능이 사라졌고(무조건 창 모드만 가능), 콘솔에다가 파일이나 디렉터리 이름을 마우스로 드래그하여 떨어뜨리는 기능도 없어졌지요.

※ 오디오 (사운드)

지금까지 열거한 비디오 쪽뿐만 아니라 오디오 계층도 윈도우 비스타는 굉장히 많이 바뀌었습니다.
일단 윈도우 95부터 XP까지 큰 차이 없이 제공되던 볼륨 조절 유틸리티 sndvol32.exe가 없어지고 비슷한 기능을 sndvol.exe가 대신 담당하기 시작했는데, 인터페이스가 싹 달라졌죠.

옛날에는 컴퓨터 내부에 소리를 만들어내는 ‘장치’가 여럿 존재했고 윈도우 XP까지는 각 장치들을 멀티미디어 API를 써서 enumerate한 뒤, 장치별로 볼륨을 조절하는 구도였습니다. PC 스피커 따로, 애드립 소리를 내는 미디 따로, 오디오 CD 따로, 입력 단자 따로, 그리고 일반 wave 오디오 따로! (PC 스피커는 볼륨 조절이 되지 않는 게 보통이지만, 노트북 컴퓨터 중엔 그것도 조절되는 게 있었답니다.)

특히 CD롬 드라이브는 CPU와는 전혀 상관없이 자기가 직접 오디오 CD를 재생했습니다. 윈도우 95 시절의 CD 재생기는 그저 오디오 CD에다가 재생/정지/탐색 명령을 내리고, 드라이브로부터 트랙별 시간 정보를 가져와서 재생 지점을 업데이트해 주는 ‘시다바리’ 기능밖에 하지 않았었습니다. 당시 도스용 퀘이크 같은 게임은 오디오 CD 겸 CD롬 형태로 게임을 만들어서 게임 음악은 아예 오디오 트랙의 형태로 제공하기도 했지요.

그러나 지금은 시대가 바뀌었습니다. 사운드 카드는 이제 랜 카드와 더불어 메인보드의 일부로서 완전히 편입이 되어 버렸습니다. 그리고 소리를 내는 모든 장치는 가장 범용적인 매체인 wave 오디오로 통합이 되어 버렸습니다. 이는 전적으로 컴퓨터 성능이 좋아진 덕분입니다.

미디는 이제 어설픈 FM 사운드가 아니라, 소프트웨어적으로 노래방 수준 음향을 wave 오디오로 흉내 내어 주는 신시사이저가 재생합니다. 오디오 CD도 마찬가지. 컴퓨터가 디지털 음원을 일일이 추출, 파악해서 wave 오디오로 내보내는 건 요즘 필수입니다. 그래야 파형 visualization도 보여주고 mp3/wma 리핑 기능도 제공할 수 있을 테니까요.

사정이 이러하니 예전처럼 ‘장치’별 볼륨 조절은 완전히 무의미해졌습니다. 그건 한 프로그램이 어떤 장치를 꺼내서 소리를 출력하면 다른 프로그램은 그 장치를 이용할 수 없던, 쉽게 말해서 멀티웨이브조차 안 되던 윈도우 3.1~95 캐 암울하던 시절의 사고방식이죠. 그나마 wave 오디오의 멀티웨이브는 윈도우 98~2000급으로 넘어가면서 가능해졌지만, 여전히 애드립 미디 같은 다른 장치는 멀티웨이브가 되지 않았었습니다.

비스타부터는 운영체제가 모든 사운드를 wave 오디오 하나로 통제하고 믹싱까지 담당합니다. 그래서 비스타의 볼륨 조절 프로그램을 살펴보면 예전과 같은 개념의 장치 구분은 완전히 사라지고, 현재 실행 중인 응용 프로그램별로 상대적 볼륨을 조절하는 게이지가 나와 있습니다. 이거야말로 윈도우 XP 이하에서는 상상조차 할 수 없던 일이었지 않습니까?

※ 윈도우 각 버전별 비교

Aero Flip3D를 보면서 신기해하던 게 엊그제 같은데 비스타와 오피스 2007이 나온 지도 벌써 2년이 넘었습니다. 제가 XP를 주 작업용 OS로는 ‘빠이빠이’ 한 지도 반 년은 넘은 것 같습니다. 이제는 윈도우 7이 나온다고 해도 비스타하고 시간 간격은 윈도우 95와 98 사이의 간격과 별 차이가 안 날 정도로 시간이 흐른 셈이군요. 그렇게 긴 시간이 지난 것 같지는 않은데.

비스타는 XP 이후로 꽤 긴 시간만에 출시된 데다 상당히 무거운 편인 컴퓨터 요구 사양, 그리고 이질적으로 바뀐 보안 정책, 일부 옛날 프로그램과의 호환성 문제 같은 여러 잡음 때문에 비스타는 그 기술적인 우수성에 비해서는 그렇게까지 환영 받지는 못한 것 같습니다. 그래서 MS도 7에다가 더 전략 가중치를 더 부여하고 있는 듯하기도 하고요.

약 2001~2002년경에 2000/ME/XP 이던 구도가 앞으로는 조만간 XP/비스타/7이 되지 않을까 싶습니다. 비스타는 ME와는 급이 다른 운영체제임에도 불구하고! 차라리 7로 갈아타면 탔지, XP는 앞으로도 한동안은 없어지지 않을 최장수 운영체제로 기억에 남을 것 같습니다.

저의 주 개발 분야인 문자 입출력 쪽만 보더라도 비스타는 일단 TSF를 주된 입력 프로토콜로 완전히 굳혀서 운영체제의 기본 입력기로 지정도 가능하게 했고(XP는 여전히 IME 모듈만 가능함), 일부 TSF A급 확장 프로토콜도 도입했으며 전세계 모든 언어 입력기와 글꼴을 다 내장하고 있습니다. XP로 치자면 ‘동아시아 및 complex script 지원’ 옵션이 선택의 여지 없이 무조건 켜져 있는 것과 같다는 뜻입니다.

한자 글꼴도 단순히 ‘한중일 통합 한자’뿐만 아니라 확장 A, 그리고 심지어 surrogate 영역의 확장 B까지도 Simsun-extB 같은 외국의 확장 글꼴까지 자동으로 대체 동원해서 운영체제 차원에서 제대로 표시해 주는 걸 보고 정말 놀랐습니다. 비스타에서는 굳이 ‘한컴바탕확장’이 없어도 이런 한자들을 어디서나 볼 수 있습니다. <날개셋> 다음 버전에서는 글꼴을 본뜰 때 이런 점도 감안하도록 수정할 예정입니다.

윈도우 ME는 잘 알다시피 태생이 9x 계열이기 때문에 95 이래로 변함없던 유니코드 API 부재, 지저분한 16비트 도스의 잔재에다 불안정한 커널, 64K 리소스 제한 같은 단점은 고스란히 갖고 있습니다. 그래서 비슷한 시기에 나온 2000보다는 95/98과 더 동일시됩니다. 안정성은 떨어지는 주제에 덩치만 더 무거워지고, 겉보기로만 도스로 빠져나가는 옵션은 또 없애 놓으니, 도스와의 호환성 때문에 9x 계열 운영체제를 찾는 파워 유저로부터조차도 외면 받을 수밖에 없었습니다.

하지만 ME도 98 SE에 비해서 장점이 없는 것은 아니어서, 부팅 속도가 매우 빠르고 최신 하드웨어 인식은 역시 98보다 확실히 더 탁월하여 2000급에 필적합니다. VMware로 각 운영체제들의 가상 머신을 만들어 보면 2000/ME 이상은 사운드가 자동으로 잡히는 반면, 95/98은 그렇지 않습니다. 또한 2000/ME부터가 미디 신시사이저를 기본 내장하고 있고 멀티웨이브 기능도 더 원활하게 잘 감지됐습니다. 외장 하드와 USB 메모리를 별도의 드라이버 설치 없이 바로 인식하고, ‘하드웨어 안전하게 제거’ 기능을 갖추고 있는 것도 2000/ME부터입니다.

Posted by 사무엘

저의 대학 시절 중반기에 KTX 개통과 주요 대형역들의 리모델링 공사가 행해졌습니다.
그리고 그와 거의 딱 일치하는 시기에 저는 철도 매니아가 됐습니다. 타이밍 한번 절묘하기 그지없습니다.

※ 서울

일제 강점기 때 일본의 건축가가 서양 스타일로 지은 그 유명한 옛 역사는 역사적 가치가 워낙 높아서 사적 문화재로도 지정돼 있죠. 간이역이 아닌 대형역이 문화재로 지정받은 건 유일한 사례가 아닐까 합니다.
옛날 역사만 해도 공항 같다는 느낌이 들 정도로 게이트 수도 많고 덩치가 컸습니다. 요즘이야 선상역이 대세이지만, 옛날에는 어지간한 중대형 역도 1층이 매표소이고 승강장까지는 지하도를 통과하여 가는 경우가 많았는데요. 그래도 서울 역은 옛 건물도 나름 선상역인지라, 탈 때는 1층의 입구로 들어가서 대합실, 매표소가 있는 2층으로 올라가고 다시 승강장으로 계단을 이용하여 내려갔었습니다. (영화 라이터를 켜라 참고)

이미 KTX 개통 전 2003년 말부터 지하철 서울 역의 출구 개조 공사가 활발히 진행됐고 역의 기능은 옆에 새로 지어진 민자역사 유리궁전으로 완전히 넘어갔습니다. 그러고 보니 서울 청계 고가 철거 공사와 시기적으로 비슷했습니다. 신축 건물은 서울 역이라는 문구보다 콩코스(Concos)가 더 큼직하게 보이죠.

옛날 역사는 하차 승객은 역 입구로 나오는 게 아니라, 지하도를 통해 별도의 출구로 빠져나갔습니다.
지금도 대전 역은 지하도는 아니지만 하차 승객의 통로가 별도로 분리된 형태이고, 대전은 동부 고속버스 터미널도 마치 서울 강남 고속버스 터미널처럼 하차장이 따로 갖춰져 있는 게 인상적이랍니다.
참고로 옛날에는 청량리 역도 하차 승객 전용 지하도와 출구가 있었습니다. 지금은 또 새 역사 신축하느라 그것도 다 없어지고 형태가 바뀌었지만.

※ 대전

대전 하면 우동이 유명했지요.
옛날 역사는 2층도 없는(최소한 승객이 올라갈 일은 없는) 1층짜리 자그마한 건물이었고, 역사에서 승강장까지는 또 지하도로 이동하던 형태였습니다. 하지만 2004년부터 슬슬 리모델링 공사가 진행되어 지금은 선상역으로 변했습니다. 저는 대학 시절, 대전 역의 변화를 일일이 목격할 수 있었습니다.

옛날에는 역전 광장도 무지막지하게 넓었습니다만, 지금은 온통 택시 진입로와 지하철 출구 공사 때문에 공간이 거의 사라지고 없습니다. 대전은 건물 통로상으로 딱 연결은 안 돼 있지만 지하철 출구로 나오면 딱 철도역 입구이기 때문에 지하철과의 연계가 서울만큼이나 잘 돼 있습니다.
다만, 대전은 1호선 치고는 철도역에 해당하는 지하철 역이 이례적으로 굉장히 깊습니다. 서울, 대구, 부산은 안 그렇거든요.

※ 동대구

과거의 구질구질하던 동대구 역도 유리궁전으로 변신하고, 언덕 위의 본 입구뿐만 아니라 언덕 아래에서도 올라가는 출입구를 신설했습니다. 사실, 선상역으로 리모델링하면서 서울, 대전도 반대편 출입구가 신설되어 역의 접근성이 더 향상되기도 했답니다.

동대구 역은 언덕 위에 건설되어서 언덕 아래의 승강장으로 내려간다는 특성상, 입구에 들어가서 별도로 또 계단을 오르내리지 않습니다. 들어가면 곧바로 매표소와 대합실이 나오는 게 특이하죠. 나가면 광장은 거의 없고 고가 도로 상으로 차와 택시들만이 즐비합니다.

지하철 동대구 역하고는 서울· 대전에 비해서는 거리가 좀 먼 편입니다. 하지만 이 기회에 이 지역에 동대구 역, 지하철 역, 동대구 고속버스 터미널, 동부 시외버스 터미널이 통합한 종합 터미널이 생기면 얼마나 좋을까 싶기도 합니다. 전국에서 유례를 찾을 수 없는 대구 명물이 되겠죠. 대구는 철도역과 고속버스 터미널 모두 굉장히 특이한 형태라는 건 익히 잘 알려진 사실이니까요.

※ 부산

겉은 으리으리한 유리 궁전으로 탈바꿈하여 외형은 광주 역과 비슷해 보입니다. 하지만 내부는 60년대 말에 건설된 옛날 형태에서 크게 달라진 게 없습니다. 한 건물로 연결은 돼 있지만 서울 같은 완전한 선상역은 아니어서 대합실· 매표소 영역과 승강장 영역은 다소 거리가 있습니다.
바다와 가까운 역이다 보니 이 역의 승강장 주변엔 온통 컨테이너, 화물들을 심심찮게 볼 수 있습니다. 경부선상의 다른 역과는 다른 분위기이고 마치 또다른 항구 역인 인천 역을 떠올리게 합니다.

부산 역은 제가 알고 있는 경부선 역들 중 현재 광장이 가장 넓은 역이기도 합니다. KTX 개통을 앞두고 숱한 리모델링의 손길에도 불구하고 학교 운동장을 방불케 하는 넓은 광장이 아직 원형 그대로 남아 있습니다. 지하철 역과는 그렇게 완전 가깝지는 않아서 지하철 출입구는 학교로 치면 딱 교문까지만 닿지, 대전이나 서울처럼 학교 건물 코앞에 닿아 있지는 않습니다. 이런 점에서는 부전동 역(부전 역)도 마찬가지.
전에도 글로 썼지만 부산은 남쪽이 철도, 북쪽 노포동 쪽에 종합 버스 터미널 이렇게 교통이 양분되어 있습니다.

Posted by 사무엘

※ 종축 (서 -> 동 순)

15: 가장 서쪽에 있는 서해안 고속도로입니다. 서울 2기 지하철 전구간, 그리고 인천 공항과 더불어 2001년에 완전 개통한 이 도로는 서울-목포를 일직선으로 연결하며 특히 충청도 서부의 발전에 크게 기여했습니다. 서울에는 서서울 톨게이트로 진입하며, 횡축인 영동 고속도로하고는 안산 분기점에서, 외곽 순환과는 조남 분기점에서 만나는데 두 분기점은 서로 굉장히 가까이 있습니다.
소설 <상록수>의 저자 심 훈이 최 용신의 장례식에 참석하러 당진에서 안산까지 찾아왔다고 하는데, 그 이동 경로가 이 도로하고 거의 정확히 일치합니다.

1: 한국 고속도로의 상징인, 그 이름도 유명한 경부 고속도로입니다. 대각선 경로이기 때문에 정확하게 횡축이라고 보기는 힘듭니다. 건설비가 1km당 사기에 가까운 1억 원이 들었고 비슷한 시기에 비슷한 규모로 건설된 일본 동명 고속도로 건설비의 1/8이 들었다는 도로. 그러나 그 후 유지 보수, 패치하는 데 비용이 훨씬 더 많아 든 도로. 1970년 7월 7일에 개통식이 열렸고 공사 중에 77명이 순직했다는 그 도로입니다.
평택 이북으로는 철도와는 달리 서쪽이 아닌 동쪽으로 간다는 점, 그리고 남부에서 경주와 울산 근처로 우회한다는 점만 빼면 철도 경부선과 노선이 얼추 비슷합니다. 분당에 서울 톨게이트가 있으며, 영동과는 신갈 분기점에서, 외곽 순환과는 판교 분기점에서 만납니다. 처음엔 전구간 4차선으로 건설됐지만 지금은 건천-경주-울산 같은 남쪽 최고 오지 구간만 제외하면 거의 다 6, 8차선급으로 확장됐습니다.

25: 이 번호는 서울에서 시작하는 고속도로가 아닙니다. 경부 고속도로에서 시작하다가 천안에서 갈라지는 논산-천안 민자 고속도로와, 호남 고속도로를 한데 묶어 25번이라고 일컫습니다. 원래 대전에서 논산까지 이어지던 구간은 251번 호남 고속도로 지선으로 바뀌었습니다. 마치 철도에서, 서대전-대전처럼 원래 호남선의 일부였던 구간이 대전선이라는 지선으로 바뀐 것과 비슷한 맥락입니다.

35: 중부 고속도로와 통영-대전 고속도로를 한데 묶어 일컫는 번호입니다. 두 고속도로는 엄밀히 말하면 서로 끊어져 있고, 그 사이의 청주-대전은 경부 고속도로 구간을 공유합니다. 중부는 잘 알다시피 청주, 이천, 용인, 광주, 하남처럼 산으로 가로막혀 있고 철도도 없던 수도권 동남부 교통 오지의 접근성을 크게 올려 주었습니다.
호법 분기점에서 영동 고속도로와 만나며, 하남 분기점에서 외곽 순환과 만남과 동시에 이 고속도로도 끝이 납니다. 동서울 톨게이트가 있습니다. 대전 이남은 가 본 적이 없군요.

37: 폭증하는 교통량을 감당하기 위해, 이천에서 하남까지 위의 중부 고속도로와 동일한 구간에다 또 도로를 건설한 것입니다. 제 2 중부 고속도로라고 부릅니다. 경부는 대부분 평지에 저렴하게 건설됐기 때문에 확장이 쉬웠지만, 중부는 길이 없는 험준한 산을 다 고가와 터널로 뚫으면서 건설된지라 도저히 확장을 할 수가 없었고 옆에 도로를 또 만드는 수밖에 없었지요. 제 2 중부는 중간 나들목도 없기 때문에 일종의 장거리 급행 도로 역할도 합니다.

45: 중부내륙 고속도로입니다. 대전을 안 거치고 여주, 충주, 상주 같은 국토 최고 중심부를 관통하여 경기도와 경상도를 지름길로 연결합니다. 덕분에 서울에서 구미 이남으로 가는 고속버스들은 이 도로를 즐겨 이용합니다. 가는 길목에서 철도 충북선과 경북선하고 모두 마주치며, 김천에서 경부 고속도로와 만나지요. 김천 이남으로는 창녕, 마산까지 한데 쭉 이어지는데, 그쪽까지는 가 본 경험이 없습니다.

55: 대구에서 출발하여 군위, 의성, 안동, 풍기, 제천, 원주로 가는 중앙 고속도로와, 그 유명한 부산-대구 민자 고속도로를 한데 일컫는 번호입니다. 중앙 고속도로는 철도 중앙선과 놀라울 정도로 노선이 비슷하죠. 하지만 이제 수도권과 꽤 멀리 떨어져 있으며 북쪽에서 서울을 향하지 않고 춘천으로 간다는 점 때문에 평시에 통행량이 그렇게 많지는 않습니다. 경부 고속도로에서 중앙 고속도로는 금호 분기점에서, 부산-대구 민자 고속도로는 동대구 분기점에서 진입하면 되는데, 이 둘의 거리는 그렇게 길지는 않습니다. 본인 이용 경험 없음.

65: 서해안 축에 비해 여전히 교통 오지로 남아 있는 동해안 축을 연결하기 위한 고속도로 노선입니다. 현재는 작년 말에 갓 개통한 부산-울산간 민자 고속도로에 이 번호가 붙어 있지요. 경부 고속도로는 너무 서쪽으로 치우쳐 있어서 정작 울산에서는 이용하기 힘든 감이 있었습니다.
새로 생긴 고속도로는 부산과 울산을 30분대 거리로 연결해 주었지만, 길이 너무 곧아서 과속의 여지가 있다는 비판도 받고 있다고 합니다. 본인 이용 경험 없음.

※ 횡축 (남 -> 북 순)
우리나라는 통일을 염두에 두고 도로에서 남쪽을 기점으로 본다고 말씀드린 바 있습니다. 그래서 동서를 관통하는 횡축 도로도 남쪽부터 차례대로 번호를 매깁니다.

10: 국토 최남단에 있는 남해 고속도로는 철도 경전선과 노선이 거의 일치합니다. 본인 이용 경험 전무함.

12: 4공 때 경부가 건설됐다면, 5공 때는 대구와 광주를 잇는 악명 높은 88 올림픽 고속도로가 건설됐죠. 소백 산맥을 넘으면서 주변 경치는 정말 좋지만, 그래 봤자 최고 시속 겨우 80에 중앙 분리대도 없는 2차선의 열악한 도로입니다. 중앙선을 넘어 앞차를 추월하려다가 맞은편 차선과 정면 충돌 사고도 막 나서 교통사고 치사율이 굉장히 높습니다. 본인 이용 경험 전무하며, 언젠가 드라이브를 해 보고 싶음.

20: 산으로 가로막힌 지형의 특성상 경주를 거치는 길밖에 없었던 포항과 대구를 직통으로 이은 것을 시작으로, 무주, 익산, 군산을 연결할 예정인 노선 번호입니다. 그렇게 다 완공되고 나면 국도 4호선과 경로가 얼추 비슷해지겠군요. 본인은 이용 경험 없음.
하지만, 이 고속도로가 생긴 후에도 시외버스들은 여전히 경주를 거쳐서 대구나 서울로 가고 있으며, 대구-포항은 고속버스 노선도 없어서 이 도로의 이용 빈도는 그다지 높지 않은 걸로 알고 있습니다. 그나저나 얘는 대구-부산과는 달리 비싼 민자 도로는 아니지요.

30: 2007년 말에 개통한 청원-상주 고속도로에 붙은 번호입니다. 이 도로는 국내에서 최초로 최고 시속 120km를 기준으로 건설되기도 했습니다. 서쪽으로 평택까지 확장 공사가 진행 중이지만 동쪽으로는 별다른 계획이 없군요. 아마 안동, 영덕 정도가 되지 않을까 싶습니다.
본인은 딱 한 번 구경한 적 있습니다. 회인, 속리산 등 지금까지 들어 보지 못한 나들목 이름이 나와서 놀랐더랬습니다.

40: 경기도 남부에서 서해안과 경부 고속도로를 연결해 주는 평택-안성간 고속도로로 개통했습니다. 비록 지금은 짧지만 앞으로 진천, 충주, 제천까지 연장될 예정입니다.

50: 횡축 고속도로 중에 현재 가장 길고 유명한 영동 고속도로입니다. 수도권에서도 가깝기 때문에 인천에서 강릉까지 이 도로가 경기도 남부에서 감당하는 교통 비중은 가히 절대적이며, 주말과 평일을 가리지 않고 차들로 인해 큰 혼잡을 겪고 있습니다. 신설된 직선 고가 도로 덕분에 서울에서 강릉까지 불과 3시간대에 갈 수 있으며, 이는 재래식 철도인 태백, 영동선과는 비교할 수 없이 빠릅니다.

60: 영동보다 더 북쪽으로, 한창 건설이 진행 중인 경춘 고속도로에 이 번호가 붙어 있으며, 이 도로는 앞으로 강원도 양양까지 연장될 예정이라 합니다.

※ 다음은 수도권에 있는 여타 고속도로들입니다.

100: 서울 지하철 2호선을 떠올리게 하는 외곽 순환 고속도로입니다. 첫 구간이 건설된 이래 거의 20년만에 완전한 고리를 이루게 되었지요. 경기도 남부에서는 마치 영동 고속도로처럼 횡축 노선을 제공하고 있고 북부는 민자 구간으로 서울 교외선과 노선이 매우 비슷합니다. 저는 남부 구간만 구경해 봤습니다. 의왕, 과천에서 매우 높은 고가로 경부선 철길을 타넘는 형태가 인상적입니다.

110~130: 120번이 경인 고속도로이고 130이 그 위로 지나는 공항 고속도로, 그리고 110은 제 2 경인 고속도로입니다. 인천과 서울은 철도도 2복선이고 고속도로도 무려 3개나 있는 셈이네요. 차선도 당연히 8차선. 그래도 쏟아지는 교통량을 감당을 못 해서 저속도로, 통행료 폐지라는 말이 나오는 지경입니다. 전국에서 가장 뻑뻑한 길은 단연 ‘경인’ 축임이 틀림없습니다.
저는 인천은 전철로밖에 가 보질 않아서 이쪽 고속도로는 구경한 적이 없습니다.

Posted by 사무엘

아래아한글 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 사무엘