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

우리는 학교에서 산수를 배우면서 덧셈을 가장 먼저 배우고, 그 뒤 이들을 묶은 형태인 곱셈을 배운다. 그리고 나중에는 곱셈을 묶은 거듭제곱이라는 걸 배운다. 그런데 덧셈이나 곱셈과는 달리, 거듭제곱은 같은 수를 곱하기를 반복한다는 직관적인 정의만 적용해서는 정수가 아닌 형태의 거듭제곱을 생각하기가 쉽지 않다.

지수법칙이 있으니 유리수 승까지는 그래도 괜찮다. 정수 승과 정수 제곱근으로 설명이 가능하기 때문이다. 하지만 이를 초월하여 2^sqrt(2)처럼 임의의 실수 승은 어떻게 해야 계산하고 표현할 수 있을까?

거듭제곱을 모든 실수 범위에서 정의함으로써 지수함수라 불리는 연속인 함수의 형태로 영역을 확장하는 데는, '연속'이라는 개념에서 알 수 있듯, 미분의 도입이 큰 기여를 했다. 자연상수 e가 발견되고 로그 함수라는 게 생기면서 지수함수는 로그의 역함수로서 정체성을 확립하게 되었다.

이 글에서 수학적으로 엄밀한 디테일을 다 말할 수는 없지만, e는 임의의 수에다 제곱근을 반복하면서 지수가 0에 가까워지고 원래 수가 1에 한없이 가까워질 때 그 수의 소숫점, 다시 말해 숫자에서 1을 뺀 값이 지수와 어떤 비례 관계가 있는지를 규명하는 과정에서 발견되었다. (1+1/n)^n에서 n의 무한대 극한이라는 원론적인 정의가 바로 거기서 유래되었으며, 사실, (1+x/n)^n라고 해 주면 그냥 exp(x)를 바로 구할 수 있다.

exp(x)는 0인 지점에서 기울기가 1이다. 그리고 미분해도 도함수가 자기 자신과 같다는 매우 중요한 특징이 있다. 즉, y=exp(x)에 있는 점 (x, y)의 기울기는 곧 y라는 뜻. 그럼 이놈의 역함수는 어떻게 될까? 본디 함수와 그 역함수는 y=x에 대해 대칭이므로, 점 (y, x)의 기울기는 곧 1/y여야 한다.

미분하면 1/x가 되는 함수를 찾아보니 다름아닌 ln x이다. 복잡한 거듭제곱을 곱셈으로, 곱셈은 덧셈으로 바꿀 수 있는 놀라운 함수 말이다. 그래서 exp는 로그의 역함수인 고로 그 정체가 e^x인 지수함수라는 결론이 도출되고, 그래서 로그와 지수의 함수 관계가 완성될 수 있었다.

a^b = e^(b ln a)이다. ln a^b는 b ln a이므로 양변에 자연로그를 씌우면 아주 자연스럽게 유도 가능하다.

또한 굳이 밑이 e가 아닌 임의의 a인 로그를 생각하더라도, log[a] b = ln b / ln a이다. 이것은 지수보다는 약간 연상이 쉽지 않을지 모르나, 이 경우를 생각해 보자. 로그의 정의상 당연히 a^(log[a] b) = b이다. 이 식 자체에다가 자연로그를 씌우면 log[a] b * ln a = ln b가 되고, 그 후의 논리 전개는 생략. ㄲㄲ

이건 굉장히 유용한 특징이다. 이 덕분에 exp와 ln만 있으면 우리는 임의의 지수의 값도 구할 수 있고, 임의의 로그의 값도 구할 수 있게 된다.
그럼 이 함수의 값을 실제로 컴퓨터로 어떻게 계산하면 좋을까?

이걸 연구하는 분야는 기호, 순수함, 추상성만을 좋아하는 전통적인 수학에서 벗어나 일면 '지저분한 이단아'처럼 보일 수도 있는 수치해석 쪽으로 가게 된다. 컴퓨터에서 exp, ln, cos, sin 같은 기초적인 초월함수의 값을 조금이라도 더 빠르고 정확하게 구하는 기법은 이미 천재 컴덕후, 수학자, 공학자들이 연구할 대로 다 연구해서 소프트웨어 정도가 아니라 아예 하드웨어에 회로에 다 코딩되어 있을 정도이다.

그러니 내가 거기에 뭔가를 더 기여할 게 있다고 여겨지지는 않는다. 단지 본인은 핵심적인 아이디어만 직접 짜 보고 넘어갈 생각이다.
초월함수들의 근사값을 계산하는 아이디어도 미분에서 유래되었다. 단순히 1차함수 접선을 구하는 것을 넘어서 곡선과 가장 가까운 n차 근사 다항식을 구하는 것으로 생각을 확장하면 '테일러 근사 다항식'이라는 걸 구할 수 있고, 무한히 미분 가능한 함수에 대해서는 무한합인 그 이름도 유명한 테일러 급수라는 걸 유도할 수 있다.

* 이말년 씨리즈와 Taylor series는 서로 느껴지는 포스가 확 다르다. 흠.;;;

exp(x)는 예전에도 글로 썼듯이, 원론적인 정의를 이용해서 값을 구할 리는 절대 없고, 테일러 급수를 쓴다. 아래의 코드는 16항 정도까지 계산했다.

double pseudo_exp(double x)
{
    double v=1.0, p=x,q=1.0;
    for(int i=1; i<=16; i++, v+=p/q, p*=x, q*=i);
    return v;
}

단, 이 급수는 x=0인 지점을 기준으로 구한 것이기 때문에 x가 8~9 정도만 넘어가도 오차가 상당히 커진다. 하지만 컴퓨터 부동소숫점에도 한계가 있으니 항을 한없이 많이 계산할 수도 없는 노릇이고, 큰 수에 대해서는 다른 방법으로 보정이 필요할 듯하다.

한편, 로그는 어떻게 구할까?
자연로그도 다음과 같은 직관적인 형태의 테일러 급수가 있긴 하다.

ln (1+x) = x (+-) x^n/n (n이 짝수일 때는 빼기, 홀수일 때는 더하기)

그런데 이 급수는 x가 -1 초과 1 미만일 때만 유효하고, 따라서 0과 2 사이의 로그값만 구할 수 있다. 나머지 범위는 항을 제아무리 많이 계산해 줘도 아예 원천적으로 원함수와 전혀 일치하지 않게 된다. 테일러 급수가 모든 범위에 대해서 무조건 만능은 아님을 알 수 있다.

하지만 지수함수와는 달리 로그는 ln ab = ln a + ln b라고 큰 숫자를 한없이 쪼개는 마법과 같은 공식이 있다. 그러므로 저것만 있어도 아무 수의 로그라도 구할 수 있다.

즉, ln 2의 값을 미리 갖고 있다가 임의의 수에 대해서 2보다 작아질 때까지 ln 2를 따로 더하면서 계속 2로 나누면 된다. 2는 잘 알다시피 2진법을 쓰는 컴퓨터가 좋아하는 수이기도 하고 말이다. 그래서 주어진 수가 2 이하의 범위에 들어오면 그때 급수를 써서 최종적으로 구한 로그값을 또 더하면 된다.

double pseudo_ln(double x)
{
    #define LN_2  0.693147180559945
    double v=0;
    while(x>2.0) x/=2.0, v+=LN_2;

    double x_min1 = x-1, xm = x_min1;
    for(int i=1; i<=16; i++, xm*=x_min1)
    if(i&1) v+=xm/i; else v-=xm/i;
    return v;
}

단, 이 급수의 아쉬운 점은 x가 0이나 2라는 양 극단에 가까워질 때 정확도가 꽤 크게 떨어진다는 점이다. 이는 계산하는 항의 수를 충분히 크게 잡아도 쉽게 극복되지 않는다.

그래서 성능면에서 실용적인 가치는 별로-_- 없지만, ln이 exp의 역함수라는 점을 이용하여, 기존 exp 함수로부터 방정식 근 찾기 기법을 이용하여 로그를 구하는 방법도 이 기회에 실습하게 되었다. 그게 없으면 무엇보다도 초기에 정확하게 값이 구해진 채 공급되어야 하는 LN_2 내장값은 또 어떻게 구하겠는가?

일변수 방정식의 근을 찾는 기법은 수치해석 교재에서 가장 먼저 다뤄지는 기초 주제이다.
exp(x)는 기복이 없으며 그래프 모양이 워낙 예쁘고 원천적이기-_- 때문에, 근이 존재하는 초기 구간만 잡아 주면, 어떤 근 찾기 알고리즘을 쓰더라도 근을 구할 수는 있다. 단지 얼마나 빨리 수렴하여 구해 내느냐가 문제일 뿐이다. 애초에 지수 함수 정도면 범용적인 방정식 근 찾기 알고리즘이 과분하게 느껴질 정도로 특징이 너무 분명하기도 하고 말이다.

가장 먼저 나오는 것은 이분법(bisect)이다. 이게 자료구조에서는 이분법이라고 하면 이분 검색처럼 log n 시간 만에 문제를 푸는 효율적인 알고리즘이라고 불리는 반면, 수치해석에서는 정수 개의 discrete한 데이터가 아니라 사실상 연속인 구간을 다룬다. 그렇기 때문에 통상적인 이분법조차도 수렴이 느린 비효율적인 방법으로 간주된다.

double solve_bisect( double (*pfn)(double), double v )
{
    double f=-10.0, t=10.0; int nt=0;
    while(1) {
        double d = (f+t)/2.0;
        double p = pfn(d) - v;
        if(fabs(p) < 0.000001) break;
        if(p > 0) t=d; else f=d; nt++;
    }
    return f; //nt는 계산 횟수 counter
}

double pseudo_ln2(double x)
{
    return solve_bisect(pseudo_exp, x);
}

근 찾기 알고리즘 중에서는 뉴턴-랩슨(혹은 그냥 뉴턴) 법이 수렴이 매우 빠른 알고리즘으로 여겨지고 있다. 이 방법은 이분법과는 달리 시작점과 끝점이라는 구간을 잡고 시작하는 게 아니라 시작점에서 해당 방정식의 접선을 그은 뒤, 접선과 x축이 만나는(y=0) 지점을 다음 점으로 잡는다. 이 작업을 방정식의 값이 근인 0과 충분히 가까워질 때까지 반복한다.

방정식 f(x) 위의 점 (x_0, f(x_0))을 지나는 접선의 방정식은 기울기가 f'(x_0)일 테니 y=f'(x_0)*x + f(x_0) -f'(x_0)*x_0이 된다. 그래야 x에다가 x_0을 집어넣었을 때 f'(x_0) 나부랭이는 소거되고 함수값으로  f(x_0)만 남기 때문이다.
이 접선이 y=0을 만족시키는 다음 점 x_1을 방정식으로 풀면 x_1=x_0 - f(x_0)/f'(x_0)이라는 생각보다 깔끔한 식이 나온다. 이를 코딩하면,

double solve_newton( double (*pfn)(double), double (*pfn_prime)(double), double v )
{
    double d = 0.0; int nt=0;
    while(1) {
        double p = pfn(d) - v;
        if(fabs(p) < 0.000001) break;
        d = d - p / pfn_prime(d); nt++;
    }
    return d;
}

double pseudo_ln3(double x)
{
    return solve_newton(pseudo_exp, pseudo_exp, x);
}

뉴턴 법 함수는 도함수의 포인터를 별도로 받는데, exp는 어차피 도함수가 자신과 동일하므로 자신을 한번 더 넘겨주면 된다는 점도 특징이다.

프로그램을 실제로 돌려 보면 알겠지만, 동일 오차 범위를 줬을 때 뉴턴 법은 이분법보다 통상 2~5배나 더 빨리 수렴하는 걸 볼 수 있다. 마치 퀵 정렬이 pivot을 기준으로 자료가 그럭저럭 이미 정렬돼 있을수록 더욱 빨리 동작하고 자료의 상태에 민감하듯, 뉴턴 법은 접선과 가까운 형태의 부드러운 곡선일수록 수렴이 더욱 빨라진다.

자, 지금까지 공대 학부 수준의 아주 허접한 수학 덕질을 감각 유지 차원에서 잠시 복습해 보았다. 각종 공식들이 유도되는 원리를 좀 더 깊이 생각해 보고 싶으나 시간과 여유가 부족하다.

아, 수학에서는 거듭제곱뿐만이 아니라 팩토리얼까지도 자연수가 아닌 실수, 그리고 복소수 범위에까지 정의하고 그 증가폭을 측정하는 방법에 대해 연구가 진행돼 있다. 그 일환으로 ln n!이 n log n - n과 얼추 비슷하다는 스털링의 공식이 있고, 그보다 더 괴랄한 감마 함수라는 것도 있어서 z! = Γ(z+1)이다. 머리 좋은 똘똘이들의 수학 덕질의 끝은 도대체 어디까지인지를 다시 생각하게 된다.

Posted by 사무엘

※ 셸 프로그램

명령 프롬프트 하나만 달랑 떠 있는 게 아니라 최소한의 GUI를 갖춘 컴퓨터 운영체제에는 셸이라는 게 존재하며, 그 셸을 구동하는 역할을 하는 프로그램이 있다. 그것이 맥 OS는 Finder이고, 윈도우는 95 버전 이래로 Explorer(탐색기)가 셸 역할을 하고 있다.
리눅스는 저 두 상업용 OS만치 셸과 커널이 일심동체인 형태가 아니기 때문에, 딱 떨어지는 단일 셸 브랜드가 없다.

95 이전 3.x 시절에 윈도우 운영체제의 셸은 도스 계열과 NT 계열 모두 그 이름도 유명한 '프로그램 관리자'(ProgMan.exe)라는 MDI 프로그램이었다. 알록달록한 32*32 크기의 16색 프로그램 아이콘들은 초등학생이던 본인에게 굉장히 아름다운 기억으로 남아 있다.

하지만 잘 알다시피 프로그램 관리자는 운영체제의 셸로서는 그리 잘 만들어진 프로그램이 아니었다. 기능이 무척 빈약하고 이것 자체도 여러 프로그램들 중 하나일 뿐, 운영체제 전체를 아우른다는 느낌을 사용자에게 못 줬다. 그룹 안에 다단계 그룹도 못 만들었고..-_-;;
또한 범용적인 파일 관리 유틸리티 기능이 전무했기 때문에 이건 또 '파일 관리자'라는 별도의 프로그램을 통해서 해야만 했다.

게다가 윈도우는 win.ini라는 환경 설정 파일에서 [boot] 섹션에 있는 shell=progman.exe라는 문장을 다른 것으로 고치면, 전통적인 프로그램 관리자 대신에 다른 것으로 셸 프로그램을 손쉽게 대체할 수 있었다.

그래서 윈도우 3.x는 프로그램 관리자를 대체하는 별도의 셸 유틸리티가 존재하기도 했다. 시작 메뉴, 내 컴퓨터, 탐색기 등을 통해 운영체제의 셸로서 explorer.exe의 지위가 확고해진 오늘날에는 이것은 꽤나 상상하기 힘든 모습이다.

당장 떠오르는 건 20여 년 전에 명성을 떨쳤던 Norton Desktop이라는 프로그램이다. 그 당시 도스용 노턴 유틸리티는 버전이 6~7 사이였고 노턴 커맨더라는 도스용 셸도 현역이었는데, 그 회사에서는 한편으로 윈도우용으로도 그런 걸출한 프로그램을 만들었다.

노턴 데스크탑은 화면 보호기도 자체적으로 운영하고 모든 프로그램들의 시스템 메뉴에다 특수한 기능을 추가하기도 했으며, 독자적인 바탕 화면을 구동하면서 윈도우 3.x를 전반적으로 매킨토시와 비슷한 형태로 만들어 줬다. 16비트 윈도우는 오늘날의 운영체제보다는 한 프로그램이 시스템 전체에 영향을 끼치가 훨씬 더 쉽기도 했으니 말이다.

※ 한컴 셸과 윈도우용 아래아한글 초창기 버전

국내에서는 1990년대 중반에 한컴에서 '한컴 셸'이라는 프로그램을 개발한 적이 있다. 화면의 한쪽 귀퉁이에 여러 프로그램들의 아이콘이 나열되는 게 마치 오늘날 맥 OS의 Dock과 비슷했다. 이것으로 기존 프로그램 그룹/폴더에 접근이 가능하고 제어판이나 탐색기도 띄우고, 운영체제를 종료할 수도 있었기 때문에 이것만 있으면 다른 셸 프로그램이 필요하지 않았다.

사진은 아래아한글 3.0b 기준이지만, 내 기억으로 아래아한글 97에도 한컴 셸이 있었다. 윈도우 95/NT4의 셸에 더 친화적인 기능들이 추가되고 버튼들도 90년대 말의 유행이던 flat 스타일로 바뀌었다. (마우스 포인터가 가리키고 있는 버튼에만 3D 테두리가 얇게 생기는 그 형태)

그런데 이 역시 97 초기판에만 있었고, 8· 15 특별판(1998)이나 국제판/기능 강화판(1999)에서는 사라졌다. 윈도우 9x 이래로 탐색기 셸 자체가 기능이 굉장히 강력해졌기 때문에 그때부터는 별도의 셸 유틸리티에 대한 수요와 의미가 없어졌기 때문일 것이다. 특히 IE4와 통합을 이루면서 윈도우 운영체제의 셸은 완전히 환골탈태를 했으니 말이다.

아마 아래아한글 3.0b나 기껏해야 96까지만 해당일 것이다.
그 당시 이 프로그램에는 한컴 셸 동반용으로 추정되는 나침반, 시계, 계산기처럼 워드 프로세서와 직접적인 관계가 없는 액세서리 프로그램도 포함돼 있었다. 지금의 운영체제에서는 제대로 실행이 안 되는 듯한데, 예전에 분명히 돌려 봤던 기억이 난다.

시간이 흐르면서 그런 것들은 거의 다 역사 속으로 사라졌다. 그나마 21세기에까지 장수한 보조 유틸리티는 아래아한글 97과 함께 도입된 '한컴 쪽지'가 유일하다. 그것도 윈도우 7부터는 스티커 메모라는 대체 프로그램이 운영체제 차원에서 생겼으니 필요가 없어진 상태.

옛날에 윈도우용 아래아한글 3.0은 Windows에서도 도도하게 완전 독자적인 GUI와 독자적인 GUI 글꼴, 독자적인 문자 입출력 체계를 쓴 데다, 기술적으로도 Win32s + 별도의 메모리 서버까지 요구하는 등 군계일학 유아독존 포스가 압권이었다.

도스용 아래아한글만 만들던 개발팀이 단기간에 프로그래밍 공부를 얼마나 해야 윈도우 운영체제의 구조를 완전히 마스터하여 방대한 도스용 프로그램을 윈도우용으로 그것도 그런 기술 수준으로 포팅할 수 있었을까? 혹시 공밀레?

이때는 한컴이 금방이라도 독자적인 운영체제를 새로 만들기라도 할 것처럼 보였다. 사실, 비슷한 타이밍 때 나왔던 큰사람의 이야기 7.0 도스용도 도움말을 잘 뒤져 보면 개발팀이 한국형 32비트 운영체제를 자체 개발하겠다는 포부를 밝힌 대목이 있었다. 지금 생각하면 그때 사람들이 참 순진/순수했던 것 같다.. ^^

물론, 윈도우용이 처음 나왔던 3.0, 그리고 에디팅 엔진을 다 갈아엎었던 워디안 때 아래아한글이 버그 때문에 정말 욕을 많이 얻어먹은 건 사실이다. 까일 건 까여야 마땅하지만 그 첫 삽을 뜨기가 얼마나 힘들고 어려웠을지 본인은 프로그래머로서 이해는 한다.

아, 아래아한글 3.0x가 사용했던 그 특유의 GUI 디자인은 이미 아시는 분도 있겠지만 NeXTSTEP에서 따 온 것이다. 아이폰이 나오기 훨씬 전부터 아래아한글이 나름 스티브 잡스 진영에서 만든 디자인을 수용한 적이 있다는 뜻 되겠다. 다만, 메뉴에 카테고리를 구분하는 separator가 없던 것은 좋은 디자인이 아닌 것 같다.

그리고 대화상자의 GUI 컨트롤 중엔, 콤보 상자와 용도가 비슷하지만 콤보 상자보다 더 static하면서 개수가 그리 많지 않은 컨텐츠 중 하나를 선택할 수 있는 '콤보 버튼'이 있다. 예를 들어 글꼴 리스트는 사용자의 컴퓨터에 설치된 글꼴이 무엇이냐에 따라서 dynamic하게 바뀔 수 있지만, 워드 프로세서가 제공하는 문단 정렬 방식 '왼쪽, 중앙, 오른쪽, 혼합' 같은 것은 수가 그리 많지 않으면서 내용이 절대 고정불변이지 않은가. 그런 것을 선택할 수 있다.

또한 스크롤 막대의 좌우, 상하 버튼이 한데 붙어 있는 것도 이 GUI의 특징 중 하나이다.

※ 여담

하긴, 도스 시절에도 셸 유틸리티가 당연히 있었다. 이때의 셸은 윈도우처럼 초보자들을 위한 GUI 기능을 강화한 놈, 아니면 파일 관리 유틸리티에 더 특화된 놈으로 나뉘었다. 후자에 속하는 것이 바로 노턴 커맨더나 MDIR 같은 유명한 프로그램임.

도스 시절에는 아무래도 컴에 대한 접근성이 지금보다는 다소 떨어졌으며, 그래픽 셸을 찾아 쓸 정도의 사람이라면 이미 그래픽 셸이 필요치 않은 파워 유저였다. 그렇기 때문에 도스용 셸 유틸은 GUI보다는 아무래도 매니악한 파일 관리 기능 특화로 더 가는 경향이 있었다.

사실, MS-DOS 자체도 한 4.0부턴가 5.0부터 도스 셸이라는 잉여에 가까운 파일 관리 유틸리티가 있었다. 그냥 밋밋한 UI에 기능도 평범한 편이지만 나름 드래그 드롭 기능이 있었으며, 그리고 하드디스크에 존재하는 모든 파일들을 한 리스트로 뽑아 주는 기능은 윈도우 파일 관리자에도 없고 이놈만의 전매특허였다. 물론, 이건 하드디스크 전체에 존재하는 파일 수가 수천~수만 정도에 불과했던 옛날이니까 가능했던 일이다.

이런 맥락을 이어받아 오늘날의 GUI 시대에도, 비록 운영체제의 기본 셸을 대체하려는 프로그램은 맥이 끊어졌지만, 전문 파일 관리 유틸리티는 건재하다. 토탈 커맨더라든가 넥서스 파일 같은 프로그램이 있다. 여러 단축키를 통해 기본 셸 프로그램보다 원하는 프로그램이나 파일, 폴더에 훨씬 더 빨리 접근할 수 있고, 한 프로그램 안에서 압축 파일도 쉽게 다루고 FTP 연계도 되는 편리한 기능에 대한 수요가 없지 않기 때문이다.

끝으로, 옛날 글들을 보면 알 수 있듯, 난 한동안은 shell을 '쉘'이라고 표기해 왔다. 도스 시절부터 프로그램이나 PC 잡지들이 다 그렇게 표기했기 때문이다. 그때 쉘 대신 셸을 쓴 프로그램은 한글 MS-DOS가 제공하던 '도스 셸'밖에 없었다. 진짜 그거 딱 하나밖에 못 봤다.
그랬는데, 외래어 표기법상 '셸'이 맞다고 하니 이 글부터 시작해서 앞으로는 셸을 쓰도록 하겠다. 틀렸으면 고치면 되지. ㅎㅎ

Posted by 사무엘

지난 8월말에 잘 알다시피 <날개셋> 한글 입력기 6.7이 완성되고 공개됐다. 내가 만들었지만 나 자신도 잘 쓰고 있다. 의미심장한 중요한 기능들이 많이 추가되어 아주 만족스럽다.

프로그램의 한 버전이 완성된 후, 조금 시간이 흐르면 버그 수정이나 새로운 아이디어 구현, 기능 추가를 위해서 결국 프로그램 소스를 또 건드리게 되고, 내가 쓰는 개발 중간 버전과 직전 완성 버전 사이에는 차이가 생기게 된다. 그 첫 차이가 생기기까지 걸리는 시간은 생각보다 길지 않다.

이번 6.7도 그 점에서는 예외가 아니다. 벌써 다음 버전 작업이 시작되었다. 프로그램 내부의 버그가 발견되었거나 새로운 기능이 떠오른 건 아니고, 단지 운영체제의 특성과 관련된 enhancement가 불가피하게 생기게 됐다. 그 내역은 다음과 같다.

1. 테마가 적용된 옅은 파랑 선택막대

<날개셋> 한글 입력기의 외부 모듈에서 한자 선택 UI를 꺼내면 외형이 윈도우 7 기준으로 지금까지(up to 6.7)는 왼쪽과 같았다. 그렇던 것을 다음 버전부터는 오른쪽처럼 나오게 수정했다.

highlight 색상이 너무 옅었던 것을 좀 더 진하게 하고, 아이템의 크기를 약간 더 키웠다. 예전보다 보기가 훨씬 더 좋아졌다. 크기를 약간 키웠는데도 MS IME의 목록이 <날개셋>의 그것보다 여전히 더 크다.

잘 알다시피 MS에서는 소프트웨어의 GUI에서 highlight된 항목을 표시하는 방법을 슬금슬금 교체해 오고 있다.
전통적인 방법은 파란 바탕 solid color에다가 하양 글씨였다. 그 이름도 유명한 GetSysColor(COLOR_HIGHLIGHT) 말이다. 아니면, 컨텐츠 자체에 여러 색깔이 서식 형태로 들어갈 수 있는 워드 프로세서 같은 곳에서 블록 같은 걸 표시하는 방법은 흰 바탕을 검정으로 바꾸는 XOR 반전색이 통용되어 왔다.

그러나 요즘 MS에서 밀고 있는 방법은 배경에다 그냥 옅은 파랑을 씌우는 것이다. 이 기법의 원조는 사실 MS 오피스 2000의 '엑셀'로 생각보다 오래 됐지만, 워드에서까지 블록이 전통적인 반전색 대신 옅은 파랑으로  표시되기 시작한 건 오피스 2007부터이다.

윈도우 XP부터는 리스트 컨트롤에서 드래그 사각형을 점선 사각형 대신 옅은 파랑으로 대체하는 LVS_EX_DOUBLEBUFFER 스타일을 도입하였으며, 비스타부터는 메뉴와 운영체제의 공용 컨트롤(리스트 뷰, 트리)에서 선택 막대까지 반전색 대신 알록달록 옅은 파랑 그러데이션이 도입되었다.

그리고 이 테마 색상은 운영체제의 시스템 색상의 영향을 받지 않는다.
Aero를 사용 중일 때에는 잘 알다시피 GPU가 합성해 내는 glass 프레임의 색깔만 바꿀 수 있지, 기존 시스템 색상은 바뀌지 않는다. 어찌 보면 시스템 색상도 점점 과거의 유물처럼 돼 간다는 뜻 되겠다.

그런데 본인은 그 옅은 파랑이 윈도우 비스타나 7이나 동일한 줄로 지금까지 알고 있었는데, 그렇지 않다. 똑같은 Aero 기반이지만 비스타가 약~간 더 옥색에 가까웠고 7이 좀 더 파래졌다.

또한 그 색상도 알고 보면 짙고 옅은 구분이 존재한다. 7은 옅은 색과 짙은 색의 차이가 비스타 시절보다 더 커졌다(위 그림에서 왼쪽의 상하 한 쌍이 비스타 것,, 오른쪽의 한 쌍은 7 것). 그래서 이를 조정함으로써 이제는 비스타와 7에서 모두 보기 좋은 색상이 나오게 되었다. 지금까지 사용하던 채색 방법은 비스타에서는 어차피 별 차이가 없던 반면, 7에서는 너무 옅게 나온다는 문제가 있었다.

2. 윈도우 8 지원

시기가 시기인 만큼 <날개셋> 한글 입력기의 다음 버전은 여건이 허락하는 한 윈도우 8의 지원 강화가 계획되어 있다.
<날개셋>은 지금까지 윈도우 2000에서 발생하는 특수한 문제 해결(아직 윈98이 대세이던 시절), 외부 모듈 첫 개발, 64비트 지원 등 외부적인 큰 환경 변화를 몇 차례 대면했었는데, 윈도우 8 지원도 상당히 도전적인 과업이 될 것 같다.

우선, 윈도우 8을 접한 소감부터 좀 말하자면, 이제 얘들은 XP, 비스타 같은 이름을 일일이 짓기가 귀찮아졌는지, 연도도 아니고 숫자를 버전과 아무 관계 없는 브랜드명으로 쓰기로 작정을 한 모양이다. 윈8의 내부 버전은 6.2이다. (비스타가 6.0, 7은 6.1)

GUI가 동글동글하던 것이 전반적으로 다시 각진 컨셉으로 바뀌고, 그러데이션이 단색(solid color)으로 바뀌는 등, 좀 더 검소해지고 단순해졌다(simplify). 의외이다.

컴덕후라면 이미 익히 알듯이 데스크톱 모드에 이어 메트로 모드라는 게 생겼으며, 메트로 모드는 확실히 과거와의 호환성을 버리고 좀 더 '새끈하고' 스마트폰 앱과 더 친화적인 응용 프로그램 환경을 추구한 듯하다.
근데 데스크톱 모드에 도대체 시작 버튼을 무슨 생각으로 없애 버렸는지는 잘 모르겠다.

윈8에서는 문자 입력기 쪽 인터페이스가 완전히 바뀌는 바람에 기존 한글 IME들은 메트로 모드에서는 동작하지 않으며, 데스크톱 모드에서도 기존 IME 도구모음줄(language bar)가 누락된 채 거의 반쪽짜리 상태로 동작한다. 특히 메트로 모드에서 동작하려면 IME 프로그램이 반드시 디지털 서명이 돼 있어야 한다고 그런다.

무엇보다 심각한 문제는, 기존 API로는 운영체제에 설치되어 있는 IME 프로그램들이 전혀 조회가 되지 않는다는 점이다. 또한 상태 표시 아이콘 쪽도 알다시피 크게 바뀌었기 때문에 이에 대한 대처를 하려면 적지 않은 시간과 수고가 필요할 것 같다.

세벌식 파워업은 수동으로 두벌/세벌 전환을 한번 해 준 뒤에 돌리면 자동 글자판 전환이 다행히 잘 된다. 그러나 IME 설정 대화상자를 꺼내기가 굉장히 불편해졌는데(일일이 제어판으로 들어가야 함. 예전처럼 우클릭만으로 되지 않는다) IME 설정 대화상자를 곧바로 꺼내는 기능이 동작하지 않기 때문에 이에 대한 패치는 해야겠다.

이렇듯, 프로그램 자체의 기능과는 전혀 무관하게 프로그램을 또 고쳐야 할 부분이 몇 군데 생겼다. 그러나 이번 6.7은 그것만 빼면 현재까지는 여전히 버그가 발견된 게 없고 최고의 완성도로 만들어져 있다..

참고로 윈8은 명령 프롬프트에서 '다다.' 글자가 덧나는 버그는 고쳐져 있었다. 그리고 모든 프로세스에서 사용 중인 IME의 종류와 상태가 한데 공유된다! IME가 각 프로세스의 스레드별로 따로 기어들어가는 게 아니라, 별도의 전용 프로세스를 통해 IPC를 써서 응용 프로그램들과 소통하는 것 같다!

※ 여담

- 난 내 컴퓨터로 서식이 없는 글을 쓸 때 무슨 프로그램을 써서 할지가 고민된다.
일단 윈도우에서는 내가 만든 <날개셋> 편집기가 심리적으로 마치 우리집 안방에 있는 것 같은 편안함과 가벼움을 선사한다. 정다운(?) 비트맵 글꼴과 화려하기 그지없는 고급 입력 기능들을 그대로 쓸 수 있으니 이것도 좋다.

한편, 맥 OS의 텍스트 편집기는 비록 한글 입력기의 자유도는 뒤쳐지는 반면, 찍히는 글꼴의 품질이 윈도우와는 넘사벽급으로 차이가 나고 너무 우수하니 이 또한 글 쓰는 즐거움을 선사하는 요인이다.
두 장점을 하나로 합치려면 결국 <날개셋> 한글 입력기가 맥용으로도 나와야 할 텐데 말이다.;;

- 요즘 모바일용 입력 방식 중에는 그냥 버튼을 눌렀다 떼는 게 아니라 특정 제스처를 취했을 때 초성과 중성이 동시에 입력되게 되어 있는 한글 입력 방식이 있다. 이런 로직을 <날개셋> 한글 입력기로 구현하는 건 일도 아니다. 날개셋문자는 애초에 여러 낱자를 한꺼번에 배당을 할 수 있는 구조이기 때문이다. 그걸 글쇠 수가 충분한 편인 PC 키보드에서는 잘 활용을 안 할 뿐.

'가'를 ㄱ+ㅏ로 입력했을 때와 한꺼번에 입력했을 때 종성의 조합 여부를 달리 지정하는 것도 가능하다. 오토마타가 통상 A ? 1: B ? .. 같은 식으로 지정되어 있는 것을 A && B ? 라고 하여 동시 입력 여부에 대한 상태 분기도 직접 지정하면 되기 때문이다. 어지간한 변칙적인 한글 입력 방식에 대한 대비는 <날개셋>이 다 해 놓고 있다.

그렇기 때문에 본인은 어떤 새로운 한글 입력 방식이 있으면 그게 손이 편하냐, 빨리 칠 수 있냐 하는 것보다는 그 입력 방식을 구성하는 기본 동작과 로직이 어떠한지를 보는 편이다. 그게 나의 연구 주제이기 때문이다.

- <날개셋> 한글 입력기의 다음 버전은 6.x대의 마지막 버전이 될 것이다. 이 글에서 언급된 이슈 말고 또 무슨 변화가 생길지는 아직 미지수이다.

그런데 개인적으로 난 윈8은 너무 급격한 변화들 때문에 비스타 꼴 날 것 같은 생각이 든다. -_-;; 왜 자꾸 익숙한 UI를 쓸데없이 바꾸고, 게다가 보안을 빌미로 응용 프로그램 실행엔 번거로운 제약만 자꾸 추가하는지 모르겠다. 2000/ME와 비스타가 망하고 XP와 7이 무진장 장수했는데, 8은 아무래도 오른쪽보다는 왼쪽 계열로 갈 것 같다.

Posted by 사무엘

학사는 성적이 중요하니 최우등/우등 졸업이라는 게 있다. 박사는 시험 점수 따위를 초월하여 개개인이 이제 자기 분야에서 프로 연구자이니, 졸업자들이 모두 호명되고 학위 논문의 제목까지 유인물에 다 기재된다.
그 반면, 석사는 둘 중 어느 것에도 속하지 않는 콩라인이다.

태풍 직후, 날씨가 최강 좋았다. 맑고 파란 하늘 덕분에 사진 찍기는 최고의 날씨였다.
괜히 Y대 아니랄까봐, 학위수여식은 찬송가 제창과 성경 봉독으로 시작해서 축도로 끝났다.
혼자 예상한 것보다 좀 더 오버하듯이 씨익~ 웃어야 사진이 더 밝고 명랑한 표정으로 나온다는 걸 느꼈다.

내가 전형적인 내 학부 학교 출신들이 가지 않는 학교와 과로 대학원 진학을 하고, 남들은 박사까지 다 마칠 나이에 이제 겨우 석사를 마친 건 정말 어쩔 수 없는 귀결이다. 남들이 전혀 관심을 갖지 않는 분야에 없는 진로를 만들면서 가고 있어서..;;

Posted by 사무엘

- (1) 부대내의 박물관 관람 → (2) 천안함 잔해 구경 → (3) 초청자가 현재 근무하고 있는 군함 구경 → (4) 초청자의 관사에서 식사 대접 받으며 교제 순의 코스였다. 옆에 같이 간 사람들은 모두 교회 사람들. 단순 안보 관광인 (1), (2)를 넘어 (3), (4)는 군 관계자 인맥이 없으면 경험하기 쉽지 않을 것이다.

- 나의 “천하의 개쌍놈 북한” 관념이 이 견학을 계기로 더욱 투철해졌다. 정정당당한 교전으로는 남한을 이길 수 없어지니 치밀하게 비열한 복수극을 계획한 나쁜 놈들. 늘 민족 동족 운운하면서 뒤로는 일본 이상으로 나쁜짓을 해 온 녀석들이다.

- 제2 연평해전 당시에 교전 수칙 때문에 대통령이 많이 까였었다. 그런데 그것보다도 내가 더 이해를 할 수 없는 건 당시 제1 연평해전을 승리로 이끈 지휘관인 박 정선 제독을 나라에서는 (사실상) 좌천 발령시키고 이내 전역시켜버렸다는 사실. 100번 까여야 마땅하다. 어디에서 주장하는 것처럼 이건 북한의 요구대로 한 게 정말 사실인가?

- 제2 연평해전 전사자 영결식이던가 그때 대통령이 안 온 것에 대해서, 기지 견학을 시켜 준 해군 관계자는 아직까지도 꽤 유감스러워하는 표정이었다.

- 제주 해군 기지 건설에도 배후에 그렇게 깊은 뜻이 있는 줄 처음 알았다.

- 육군은 닥치고 쪽수이고, 공군은 1인 1비행기인 전투기 파일럿만 빼면 대부분이 비전투 병과인 반면, 해군은 배가 생활 공간 겸 그대로 전장이다 보니 그 중간에 속하는 군대 문화를 갖추고 있다. 대한민국은 수출에 목숨 걸어야 하고 바다 없이는 못 사는 나라인 주제에, 해군에 대한 지원이 너무 열악하다고 한다.

- 군함에는 내연기관과 제트엔진이 모두 달려 있다고 한다. 이것도 자동차와 비행기의 중간인 셈인데, 제트엔진을 가동하면 무척 빨리 움직일 수 있지만 극심한 소음과 연료 소모를 감수해야 한다고. 그런데 둘은 사용하는 연료부터가 서로 다르지 않나? (중유 vs 등유)

- 평택 시내의 경부 고속선 고가를 달리는 KTX를 보니 정말 감격스러웠다.

- 우리나라 철도를 공부하면서 단련된 나의 우리나라 역사, 지리, 안보 지식은 군 관계자와 얘기를 나누면서도 유감없이 발휘되었다. 철도님, 사랑합니다.

- 이런 곳에 신실한 KJV 빌리버 크리스천이 계셔서 성경 교제와 안보 관광을 동시에 하고 올 줄이야. 친절하게 군 시설을 안내하고 융숭한 대접을 해 주신 해군 관계자들께 감사드린다.

Posted by 사무엘

1. conime가 conhost로

윈도우 NT 계열 운영체제에는 전통적으로 시스템 디렉터리에 conime.exe라는 자그마한 프로세스가 있었다.
이 프로그램의 타이틀은 Console IME로, 말 그대로 명령 프롬프트(콘솔이라고 불리는)라는 특수한 환경에서 한글이나 일본어의 입력을 지원하기 위해 운영체제와 명령 프롬프트 사이의 통신을 담당하는 듯하다.

conime는 명령 프롬프트를 여러 개 연다고 여러 인스턴스가 중복 실행되지는 않는다. 하지만 한번 실행되고 나면 나중에 명령 프롬프트를 모두 닫아도 종료되지 않고 남아 있는다. 그래서 명령 프롬프트에서 <날개셋> 한글 입력기를 사용하다가 나중에 <날개셋>을 버전업/제거한다거나 하면 conime 프로세스를 강제 종료시켜야 한다고 설치 프로그램이 징징대는 걸 볼 수 있다.

뭐, 작업 관리자로 이 프로세스를 강제 종료시키더라도 운영체제에 악영향은 (전혀) 없다. 나중에 명령 프롬프트를 열면 운영체제가 그걸 알아서 또 실행해 준다.

그런데 윈도우 7에서는 시스템 프로세스 중에 conime.exe가 사라졌다는 걸 본인은 아주 뒤늦게 확인했다. 명령 프롬프트에다 IME 기반 문자 입력을 제공하는 계층이 다른 걸로 바뀌었다는 뜻인데, 어쩌면 이런 변화 때문에 콘솔에서 조합 중인 한글이 덧나는 버그('다다.' 같은)도 덩달아 들어간 게 아닌가 하는 추측도 할 수 있을 것 같다.

관찰해 보니, 윈도우 7에서 콘솔과 관련하여 대신 등장한 프로세스는 conhost.exe이다. 콘솔에서 <날개셋> 한글 입력기를 사용하고 있는 채로 해당 프로그램을 제거하거나 변경하려고 시도하면 conhost 때문에 안 된다는 경고가 뜬다.

그럼 conhost는 cmd.exe 자체와 일대일 대응하는 자매 프로세스냐 하면 꼭 그렇지는 않다.
명령 프롬프트에서 또 cmd라고 치면 그 동일한 창 안에서 명령 프롬프트가 또 구동되는데(exit를 치면 종료 가능한), 이때는 conhost가 또 생기지는 않는다. start cmd라고 쳐서 독립된 콘솔 창이 생성되어야 conhost도 중첩 생성된다. 관계가 이해되시겠는가?

conime와는 달리, 이놈은 명령 프롬프트 창의 인스턴스와 일대일 대응하고, 창이 닫히면 이 프로세스도 종료되어서 IME 프로그램 파일에 걸렸던 lock이 풀린다. 예전에는 콘솔 디버깅 후에는 conime를 강제로 죽여 줘야 했는데 윈7에서는 그럴 필요가 없어진 건 편해진 점이다.

2. 윈도우 7의 kernel32.dll 리모델링

이뿐만이 아니라, 윈도우 운영체제의 시스템 프로그래밍 내지 파일 해킹에 관심이 많은 분이라면 윈도우 7의 under the hood에서 일어난 흥미로운 변화를 하나 알고 있을 것이다.
운영체제의 근간을 이루는 시스템 DLL 중 하나인 kernel32.dll이 내부적으로 여러 분야로 리모델링을 거치기 시작했다는 점이다.

시스템 디렉터리에 가 보면 api-ms-win-core-*.dll이라는 수십여 개의 DLL들이 보일 것이다.
이것들은 kernel32.dll이 제공하는 1000개가 넘는 윈도우 API를 스레드, 힙 메모리, 동기화 오브젝트, 파이프 등으로 세부 분류한 껍데기들이다.

전통적으로 kernel32.dll은 윈도우 9x 계열의 것은 100% 순수 자체 코드로만 이뤄져서 그런지 외부 DLL에 의존하는 게 아무것도 없었다.
NT 계열의 것은 운영체제 커널보다 먼저 로딩되는 ntdll.dll에만 의존도가 있었다. 그리고 그 ntdll이 외부 DLL에 전혀 의존하지 않는 원초 프로그램이었다.

영원무궁토록 변하지 않을 것 같은 kernel32.dll의 내부 구조가 윈도우 7에서 이렇게 바뀐 걸 처음 봤을 땐 무척 흥미로움을 느꼈다.
지금은 그냥 뭔가 더 큰 변화를 위한 준비 수준일 뿐인 것 같은데, 윈도우 8에서는 변화가 얼마나 더 진행될지가 궁금하다.

3. 콘솔의 시각 테마 적용

윈도우 7로 넘어가면서 콘솔에 미묘하게 생긴 재미있는 변화가 또 있다.
전통적으로 명령 프롬프트 창은 윈도우 XP에서부터 도입된 '시각 스타일', 혹은 시각 테마가 적용되지 않는 딱딱한 창으로 처리되었다.

물론, 공용 컨트롤 6.0 매니페스트가 명시되어 있지 않은 구형 프로그램은 각종 컨트롤이나 child window의 테두리가 구닥다리 고전 테마로 나오긴 했지만, 그래도 프로그램의 제목 표시줄 같은 non-client 영역은 모서리가 둥글게 다듬어지기도 하고 최소한의 시각 테마가 자동으로 적용되었다.

그런데 명령 프롬프트는 그런 게 전혀 없이 완전 사각형 모양에 제목도 여전히 윈도우 98/2000식의 그러데이션이고 100% 고전 테마 스타일로 나왔다.
이렇게 100% 구닥다리로 뜨는 프로그램은 (1) 명령 프롬프트, (2) ntvdm 밑에서 돌아가는 16비트 윈도우 프로그램, 그리고 (3) 사용자가 호환성 옵션에서 '시각 테마 사용 안 함' 옵션을 명시한 프로그램 이렇게 세 종류로 한정되곤 했다.

윈도우 비스타/7의 Aero를 사용하면 100% 구닥다리 프로그램도 제목 표시줄이나 창 프레임 자체는 다른 창과 똑같은 형태로 나오기 때문에 이를 구분하기가 쉽지 않다. 고전 테마 말고 Basic 테마를 고르면 한눈에 구분이 가능해진다. 이게 과거의 윈도우 XP Luna와 기술 수준이 동일한 테마이기 때문이다.

그랬는데 윈도우 7부터는 (1) 명령 프롬프트 창도 시각 테마가 적용되는 창으로 바뀌었다. (2)에 해당하는 16비트 윈도우 프로그램은 64비트 운영체제에서는 아예 존재하지도 않으니, 남은 건 이제 (3)뿐이다.

윈도우 비스타/7이 제공하는 한국어/일본어 입력기는 그렇게 시각 테마 열외 프로그램 밑에서 동작하면 가/A, 漢 같은 아이콘이 흰색이 아닌 검은색으로 표시된다. 고전 테마가 아니라 Basic이나 Aero 같은 일반 테마에서 동작할 때 말이다.
본인은 한글 IME의 개발자로서 그 차이를 눈여겨보고 있었고, 그냥 얘네들이 명령 프롬프트에서 동작할 때만 아이콘 글자색을 검게 처리하는가 보다 하고 넘어갔었다.

그랬는데 윈도우 7에서는 명령 프롬프트에서도 글자색이 변하지 않았고, 이에 의문을 느껴 좀 더 관찰을 해 보니 차이를 만드는 요인은 '시각 테마'의 적용 여부라는 사실을 발견하게 되었다.
왜 일부러 그런 차이를 만들었는지는 나로서는 알 길이 없다. 문자 입력기가 응용 프로그램의 시각 테마 적용 여부에 따라 달리 동작해야 할 요인이 있을 리도 없을 텐데 말이다.

자, 다음 그림은 Basic 테마일 때 윈도우 비스타의 명령 프롬프트 화면과 7의 명령 프롬프트 화면이다. 창 프레임의 모양과 입력기 도구모음줄 아이콘의 색깔에 차이를 주목하시길. 내가 지금까지 설명한 것들이 이해가 될 것이다.

4. 도스에서 명령 프롬프트로의 변화

윈도우 9x 계열이야 전용 명령 프롬프트 터미널이라는 게 없이 도스창이 명령 프롬프트의 역할도 겸해 왔다. 그리고 거기서는 아예 도스용 한글 바이오스 프로그램이 따로 쓰이니 conime 같은 컴포넌트는 필요하지 않다.

사실, 16비트 윈도우 시절에 운영체제가 쓰던 전용 실행 파일 포맷(New Executable)은 GUI 환경 전용이었지, 콘솔용은 있지도 않았다. 어차피 똑같은 16비트 기반이고 윈도우 운영체제 자체가 파일 접근 같은 요청은 여전히 도스에다 요청을 해서 처리를 하고 있었으니, 콘솔용 실행 파일을 따로 만드는 건 아무 의미가 없고 필요하지도 않았다.

사실, 매킨토시와는 달리 윈도우 계열 OS에만 존재하는 독특한 ANSI/OEM 인코딩, 코드 페이지 같은 개념은 그 기원을 도스의 명령 프롬프트에서 찾을 수 있을 것이다. 걔네들은 원래 철저하게 1바이트 기반 인코딩을 썼었기 때문이다. 그에 반해 매킨토시는 시작부터가 명령 프롬프트가 전혀 없는 GUI였으니 그런 잔재가 없는 셈일 테고.

5. 윈도우 운영체제의 문자 입력 관련 보조 프로세스

처음에 얘기가 나왔던 conime.exe처럼, Windows에서 문자 입력 프로그램과 관계가 있는 시스템 프로세스를 더 나열하자면...
과거에 윈도우 95~2000/ME까지는 internat.exe라는 프로그램이 있었다. 시스템 트레이에다 현재 선택되어 있는 입력기의 언어와 종류를 띄워 주는 역할을 했다.

그러다가 2001년에 윈도우 XP와 함께 COM 인터페이스 기반의 고급 텍스트 서비스(TSF)가 도입되면서 그 역할은 ctfmon.exe가 대체하게 되었고 그게 오늘날의 비스타/7까지 변함없이 내려오는 중이다. internat이나 ctfmon은 언제나 상주해 있으며, 운영체제를 업데이트하지 않는 한 사용자가 강제 종료할 일도 없는 프로그램이다.

하지만 TSF의 도입 초기이던 오피스/윈도우 XP 시절에는 그게 운영체제의 안정성을 떨어뜨리기도 했기 때문에, 딱히 고급 문자 입력 기능에 관심이 없던 사용자 사이에는 운영체제의 버그를 고친답시고 TSF 기능을 완전히 끄고, 심지어 ctfmon 프로그램을 죽여서 문제를 해결하는 방법이 운영체제 팁으로 공유될 정도였다.

6. MS IME가 등록해 놓는 정체 불명의 유틸리티

MS가 제공하는 한중일 IME는 시작 프로그램에다가 정체를 알 수 없는 이상한 migration 유틸리티 같은 걸 등록하여, 운영체제가 시작될 때 매번 그게 실행되게 해 놓곤 했다. HKLM\Software\Microsoft\Windows\CurrentVersion\Run 아래에 말이다.

일본어나 중국어도 아니고 한국어 IME는 무슨 사용자 데이터를 관리하는 것도 아닌데 도대체 이게 하는 일이 무엇이며 왜 이런 과정이 필요한지는 본인으로서는 알 길이 없다. 그냥 일본어 IME 따라 관례적으로 이런 것도 따라 한 것이기라도 할까?

Posted by 사무엘

오랜만에 <날개셋> 한글 입력기의 새 버전 소식을 전하게 된 것을 기쁘게 생각한다.
6.51 다음으로 6.7! 나의 대학원 석사 졸업 기념작이다.
나의 대학 학부 졸업 기념작은 까마득한 옛날인 2005년 여름에 나온 3.41이고,
4년 전 여름에 나온 5.0은 병특 만료 기념작이다.
작년에 6.2가 나온 뒤 거의 정확히 1년 만에 버전이 0.5만치 올라가게 되었다.

이번 버전은 비주얼 C++ 2010으로 개발된 첫 버전이다. 5.5부터 지난 6.51까지는 약 3년 동안 2008로 개발됐다.
더 옛날의 2.5부터 5.31까지는 거의 6년 동안 2003을 썼고 말이다. 그에 반해 VC++ 2005는 처음에 64비트 에디션을 빌드할 때만 잠깐 썼고 그다지 즐겨 사용되지 않았다.

버전 번호에 7이라는 숫자가 들어가는 것은 지난 12년간의 <날개셋> 한글 입력기의 개발 역사상 최초이다. 물론 6.x를 졸업하고 아예 메이저 버전이 7로 진입할 날도 얼마 안 남았고 말이다.
6.7은 여느 역대 버전들과 마찬가지로 다방면의 기능 추가와 개선을 거쳤다. 하지만 이번에도 시간과 여유의 부족으로 인해 원하는 기능, 넣고 싶었던 기능들을 모두 충분히 넣지 못했다. 그렇기 때문에 6.7까지는 안 하고 6.65, 심지어 6.66-_-으로 번호를 정하는 것도 이론적으로 충분히 가능하나, 국민 정서를 감안하여 그러지는 않았다.

한동안 <날개셋> 한글 입력기의 API에 큰 변화가 없었기 때문에 타자연습 3.3은 입력기 6.2부터 6.51까지 API 호환이 지켜졌으나, 이번 6.7에서는 클래스 가상 함수 한 군데의 프로토타입이 바뀌는 바람에 정말 어쩔 수 없이 API 호환이 깨지게 되었다.

타자연습은 1년 전이나 지금이나 바뀐 건 없고, 입력기 6.7의 API를 기준으로 재빌드한 프로그램만 다시 올렸다.
물론, 이제는 API 호환이 안 되는 버전의 <날개셋> 입력기 외부 모듈과 타자연습이 서로 같이 실행되어도 충돌이 없기 때문에, 굳이 타자연습에서 입력기 6.7에 새로 추가된 기능을 꼭 써서 타자 연습을 해야 할 분이 아니라면, 이미 설치된 타자연습 3.3을 또 재설치해야 할 필요는 없다.

이번 6.7에서 내세울 만한 변화는 다음과 같다.

1. 편집기의 에디팅 엔진 최적화

비록 눈에 당장 차이가 느껴지지는 않는 변화이긴 하나, 새 버전에서는 에디팅 엔진의 최적화가 최후 종결자 지점에 이르렀다.
텍스트의 여러 군데가 동시다발적으로 바뀌어서 구간별로 어디는 다시 그려져야 하고, 어디는 단순히 위로 몇 줄 스크롤하면 되고, 더 아랫부분은 반대로 아래로 스크롤되어야 할 때... O(n^2) 복잡도까지 감수하면서 구간별로 모든 가짓수를 100% 정확하게 파악하여 동작하게 했다. (물론, n이 너무 커지면 골치 아프게 그런 것 따질 필요 없이 그냥 화면 전체를 다시 그려 버리면 된다)

예전에는 그냥 최악의 상황을 가정하고 무조건 화면을 다시 그리게 하던 것이 지난 6.2 버전이던가 그때쯤에 크게 개선되었다. 그러나 그것도 동작이 지금 정도로 정교하지는 못했으며, 나중에 다시 생각해 보니 논리 자체에도 원천적으로 결함이 있어서 아주 특수한 상황에서는 여전히 화면 잔상이 남는 버그까지 있었다.

그 점이 찝찝했었는데 이번 버전에서는 드디어 작정하고 매달린 끝에 완전히 끝장을 내고 말았다. 만세! 새로운 기능 구현도, 단순 리팩터링도 아니고 최적화 작업을 끝냈을 때의 홀가분한 기분은 직접 구현해 본 사람만이 느낄 수 있을 것이다. 역시 좋은 프로그래머란, 모든 경우의 수를 논리적으로 잘 따지는 사람임을 느꼈다.

텍스트 에디터를 만들면서 이런 식으로 구간과 구간 사이의 여러 변화들을 한데 합성하는 알고리즘을 구현하는 게 굉장히 힘들었다. <날개셋> 편집기는 한글에만 초점을 맞추려고 complex script는커녕 글씨 크기 변경도 안 되고 가변폭 글꼴조차 지원 안 하는 아주 제한된 에디팅 엔진을 의도적으로 고수하고 있지만, 그 정도를 만드는 데도 지금까지 의외로 복잡하고 어려운 알고리즘이 제법 들어갔다. undo/redo를 관리하는 것도 그렇고.

2. 한글 입력 오토마타 차원에서의 기능 추가

이 달 초에 블로그 글을 통해 먼저 소개한 바 있는 종성 지향 두벌식은, 예전에는 없던 완전히 새로운 개념이 추가된 것이다. 같은 두벌식이라도 음절 경계에서 자음을 초성으로 볼 것인가, 종성으로 볼 것인가 하는 것을 이제 사용자가 직접 지정하는 것은, 한글 입력 전문 프로그램으로서 매우 중요한 기능이 아닐 수 없다.
종성 지향 두벌식과 맞물려 돌아가는 BKSP 옵션, 특수 키, 타수 복원 알고리즘 등등도 다 일관성 있게 동작하도록 로직의 수정과 보강이 이뤄졌음은 두 말할 나위가 없다.

그리고 오토마타에서는 현재 입력된 날개셋문자가 두벌식인지(종성 지향 포함) 세벌식인지를 나타내는 변수를 추가하여, 한 오토마타가 벌식에 따라 다르게 동작할 수도 있게 했다.

사실 이 두 기능은 내 학위 논문에도 들어가야 했을 아이디어인데 논문 학기가 다 끝난 뒤에야 생각이 나고 구현된 것이 좀 아쉽다. ^^;;

3. 단어 단위 한자 변환

<날개셋> 한글 입력기의 아주 오랜 숙원이 이번 버전에서 드디어 부분적으로나마 성취되었다. 만세!
드디어 '대한민국'에서 '국'을 조합 중이거나 '국'의 뒤에다 커서를 두고 한자 키를 누르면 단어를 한꺼번에 大韓民國로 바꿀 수 있다. 그리고 한자를 한글로 바꾸는 것도 최대 12글자까지 한꺼번에 할 수 있다.

이렇게 하기 위해서는 제어판의 '편집기 계층'에서 '단어 단위 한자 변환' 옵션을 켜 주면 된다. 그리고 이 기능은 아무데서나 쓸 수 있는 건 아니고, 자체 편집기나 TSF A급 프로그램(워드패드, MS 워드 등 몇몇)에서만 가능하다.

단, 이것은 아주 초보적인 수준으로만 구현된 것이기 때문에 한계도 적지 않다.
커서 바로 앞까지 끝나는 범위의 단어만 한자로 바꿀 수 있으며, 글자가 아닌 단어 영역에 대해서 블록 같은 시각적인 피드백이 없다.

그리고 이 단어 사전은 <날개셋> 한글 입력기가 자체적으로 갖추고 있는 게 아니다. MS 한글 IME의 한자 사전을 빌려다 써서 동작한다. 그래서 내 프로그램으로 단어 단위 한자 변환을 하려면 윈도우 비스타/7의 한글 IME가 설치되어야 있어야 한다. 자체 사전이 아니므로 사용자 사전 등록 기능 같은 것도 없다.

이번 버전은 그냥 최소한의 노력으로 <날개셋> 한글 입력기도 이제 제한적으로나마 단어 단위 한자 변환이 가능하다는 걸 맛만 보여 준다는 데 의미가 있다. 그러나 이렇게만 해도 정말 신기하기 그지없다.

4. 그 밖의 사소한 변화들

- <날개셋> 한글 입력기의 외부 모듈은 설치하여 구동하고 나면 language bar에 예닐곱 개의 아이콘들이 주렁주렁 달리는 편이었는데, 이번 버전부터는 잉여력이 꽤 강한 전/반각 모드, 텍스트 필터(극소수의 TSF A급 프로그램에서만 사용 가능), 문자표는 제외하고 기본적으로 4개의 아이콘(한/영, 한자, 제어판, 보조 입력 도구)만 표시되게 바꿨다. 나머지 아이콘들은 별도의 명령을 내려서 사용자가 표시하도록 해야 표시된다.

이렇게 하니까 훨~씬 깔끔하고 좋다. 외부 모듈이 개발된 지도 벌써 7~8년째인데 왜 지금까지 이렇게 정리를 할 생각을 안 했나 모르겠다.

- 그리고 <날개셋> 편집기에서 외부 모듈을 사용하면서 편집기의 도구-옵션 명령으로 프로그램의 GUI 언어를 변경한 경우, 외부 모듈의 도구모음줄 아이콘의 툴팁이나 명칭도 해당 언어로 바뀌게 했다. 크게 의미 있는 변화는 아니지만 프로그램간의 일체성을 향상시킨 조치이다.

- 외부 모듈의 한자 변환 후보 선택 중에 Ctrl+C를 누르면 선택된 한자를 클립보드에다 복사가 되게 했고, Shift+엔터/번호를 누르면 한(韓) 형태로, 그리고 Ctrl+엔터/번호를 누르면 韓(한) 형태로 삽입이 되게 했다. 저 기능도 언젠가 넣어야 할 필요를 느끼고 있었는데 이렇게 하는 게 제일 좋을 것 같다.
필요는 발명을 낳는 법. 단어 단위 한자 변환과 연계하면 더욱 편리해진다. '대한민국(大韓民國)' 같은 문구를 한번에 바로 삽입할 수 있으니 말이다.

- '한글을 소리 나는 대로' 필터가 받침 ㄷ계열(ㄷ, ㅅ, ㅌ 등)+ㄹ을 지금까지 ㄹㄹ로 동화시키고 있었는데 이를 ㄴㄴ 계열로 수정했다. 그런데 한국어에서 저렇게 동화가 일어나는 경우가 전혀에 가깝게 없기 때문에 <날개셋> 3.0 이래로 이에 대한 문제를 제기할 일이 없었다.

- '한글 낱자 종류 변환' 필터에 호환용 한글 자모 4개 나열로부터 표준 한글 자모나 한글 글자마디를 만드는 변환 기능을 추가했다. 이것은 우리나라 표준 문자 코드에 명시되어 있는 스펙이기 때문에 도입했다. (거의 사문 전락 수준이 아닌가 의심되긴 하지만.)

- 굳이 나열하기에도 구차한 여러 버그 수정들은 덤. 사용자는 거의 접할 일이 없겠지만.
- 그리고 이번 버전부터 후원 안내문이 프로그램 설치 화면과 도움말 구석에 추가되었다.

5. 제공 자료들

새로 추가된 한글 입력 기능을 활용하여 두벌/세벌 판별 변수를 활용한 복벌식용 모아치기 오토마타, 그리고 맥 OS의 세벌식 자판이 예제로 추가되었다. 종성 지향 두벌식을 사용하여 고증을 100% 살린 MS 두벌식도 예제로 제공된다.
그리고 6.7의 새로운 기능으로만 가능한 건 아니지만, 아래아한글 97이 과거에 제공하던 세벌식 semi-모아치기 오토마타도 예제로 추가했다.

아래아한글 97을 기억하시는가? 아래아한글 2.0 기반의 에디팅 엔진과 3.0 기반의 파일 포맷, 그리고 한컴 2바이트 코드를 사용하던 마지막 버전임과 동시에, 당대로서는 가장 완성도가 높았고 1990년대 말과 2000년대 중반까지 전국적인 사랑을 받았던 명작 워드 프로세서이다.

그 아래아한글 97은 세벌식 글자판에서 우리나라의 소프트웨어 역사상 전무후무한 한글 입력 로직을 갖고 있었다.
초성만 가장 먼저 입력한 뒤엔, 그 후의 중성과 종성은 아무 순서대로나 입력하면 된다. 아래아한글 97의 오토마타를 <날개셋> 식으로 기술해 보면 다음과 같은데...

0 → A ? 1 : B|C ? 2 : 0
1 → A ? 1 : B|C ? 2 : 0
2 → B|C ? 2 : 0

수식이 정말 심하게 단순하다!
<날개셋>의 표준 모아치기 오토마타는 초성을 나중에 뒤늦게 입력하는 경우를 고려하는 것도 있기 때문에 0부터 3까지 4상태이다. 그러나 아래아한글은 초성 아니면 중성/종성으로만 딱 칼같이 나눠서 겨우 3상태이고 수식도 더 간결하다.
거기에다가 아래아한글의 전통인 조건부 / 키만(초성 입력 직후에만 ㅗ, 나머지 상황엔 / 그대로) 수식으로 넣어 주면 100% 정확한 아래아한글 스타일 세벌식이 완성된다.

Mac OS의 세벌식에 이어 아래아한글 97의 세벌식 입력 오토마타를 구현해 보니 스스로 생각해 봐도 재미있다. 다 똑같은 한글 입력 방식 같아도 실제로는 100% 똑같지가 않다.

내가 예전 글에서 썼듯이, <날개셋> 한글 입력기는 그야말로 한글 덕후들의 지적 욕구를 충족할 수 있는 프로그램, 한글 덕후의 마음의 고향 같은 프로그램을 표방하며 개발되고 있다. 그리고 이번 6.7은 그 이상향에 더욱 근접했다고 볼 수 있으며, 글을 다 써 놓고 보니까 마음이 바뀌는 듯. 이 정도면 6.51에서 6.7로 충분히 버전을 올릴 만도 하다는 생각이 든다. ^^

Posted by 사무엘

옛날에 나의 기억 속에 남아 있는 매킨토시는 가히 꿈의 컴퓨터였다. 여기서 옛날이라 함은 대략 1990년대를 말한다.

그때 우리의 IBM 호환 PC는 아키텍처가 다 공개되어 있기도 했으니 ‘행정 전산망용’ 내지 ‘교육용’이라는 타이틀을 달고 국내 대기업이 로컬라이즈까지 해서(일본의 로컬라이즈 방식을 따라한 것이겠지만) 보급되고 있었다. 그러니 맥에 비해 희귀하다는 느낌이 덜했다. 그리고 이 기계는 그래픽 성능이 맥보다 훨씬 시원찮았다.

그에 비해 매킨토시는 희귀함과 화려함 그 자체였다. IBM PC가 겨우 도스 명령 프롬프트에서 16색, 256색 VGA를 논하는 동안 매킨토시 화면에서는 화려한 GUI 운영체제에다 천연색 사진 그래픽과 각종 전자 출판물 편집 장면이 나오고 있었다. 듣자 하니 매킨토시 컴퓨터에는 텍스트 모드라는 게 아예 없다는데? (물론, PC에서도 텍스트 모드는 컴퓨터 켠 직후에나 잠깐 보이는 과거 유물 잉여가 된 지 오래이지만.)

기계의 모양을 봐도 모니터와 본체 일체형에, 하드웨어와 소프트웨어도 다 무조건 자기네 순정만 쓰이는 게 고급스러움과 간지 그 자체였고, 웬지 지구인이 만든 물건 같지가 않은 티가 역력했다. 엘렉스 컴퓨터가 총판을 맡던 시절에, 매킨토시는 가격도 억소리 나게 크고 아름다웠기 때문에 딱히 전자출판· 그래픽 분야 종사자나 유학파 얼리어답터들이 아니면 쓸 엄두를 내기 어려웠다.

(물론, 그때 컴퓨터 덕질을 안 하고 그 돈 더 모아서 서울 강남에다 집을 사 놨으면, 지금쯤 떼부자가 됐을 거라고 자조 섞인 말투로 회상하는 얼리어답터도 있다고 카더라)

매킨토시 진영은 서비스 구리고 하위 호환성에 자비심 없는 것으로도 잘 알려져 있다. ‘윈텔’ 진영과는 성향이 달라도 너무 다르다. MS 윈도우야 API의 하위 호환성은 정말 경악스러울 정도이고, x86 아키텍처 자체도 호환성에 목숨 거느라 그 지저분함이 말도 못 할 수준이지 않던가.

그런데, 그 간지 최강 귀족 컴퓨터에서 돌아가는 맥 OS도, X 이전의 클래식 버전은 사실 선점형 멀티스레딩도 없이 기술적으로는 윈도우 95보다도 뒤쳐진 물건이었다고 한다.
하긴, 어렸을 땐 난 시커먼 도스 프롬프트에서 그 허접한 윈도우 3.1이 시동되는 모습만 보고도, 화려한 그래픽에 동심이 매료되고 가슴이 두근거렸는데 하물며 매킨토시는 어땠을까?

그로부터 세월이 흘러 매킨토시 진영의 역사상 있었던 대단히 큰 사건들을 요약해 보자면 다음과 같다. 200x년대에 굵직한 일들이 많았다.

1. 엘렉스 대신 애플 코리아가 직접 한국으로 진출 (1999)
2. 맥 OS X 출시 (2001)
3. 인텔 아키텍처 기반으로 전향 (2005-2006)
4. 아이폰의 흥행 대성공(과 국내에 드디어 시판) (2007, 2009)
(5. 그리고 아마, 잡느님의 사망. 2011)

매킨토시가 옛날에 비해서는 정말 가격도 많이 떨어지고 보급도 많이 된 건 사실이지만, 서비스의 품질은 오히려 엘렉스 시절보다도 못한 면모도 있다는 성토가 여전히 나돈다.
또한 최강의 장사꾼 기질로 한글화를 꼬박꼬박 친절하게 하는 MS 윈도우 진영과는 달리, 맥 진영은 소프트웨어의 한글화도 좀 투박한 구석이 있다. 기본 제공되는 한글 서체의 품질이 저질이라고 폭풍처럼 까여 온 것 역시 그런 맥락일 테고.

맥은 하드웨어 배경이 완전히 다르다 보니 640KB 메모리 제한이라든가 16비트/32비트 썽킹 같은 흑역사는 없다.
다만, PowerPC에서 x86으로 갈아탄 것은 워낙 여파가 너무 큰 변화이기 때문에 제작사인 애플에서도 어떤 형태로든 호환 레이어를 제공하지 않을 수가 없었다. 그래서 CPU 에뮬레이터인 '로제타'를 만들고, 그리고 한 프로그램 바이너리에 아예 x86 코드와 PowerPC 기계어가 같이 들어있는 Universal binary라는 포맷도 제정했다.

물론 지금은 시간이 충분히 지났기 때문에 Snow Leopard던가 Lion이던가 버전부터는 PowerPC 지원은 완전히 끊겼다. 그리고 Universal binary는 PowerPC/x86이 아니라 같은 x86 계열 안에서 32비트와 64비트 코드를 동시에 내장하기 위한 용도로 쓰이고 있다. 앞으로는 ARM과 x86(-64) 사이의 동시 지원이 필요해질 듯.

가만히 생각해 보면 이게 옛날에 MS가 윈도우 NT 시절에 제정한 Portable Executable과 일맥상통하는 개념이 아닌가 여겨진다. 당시에 윈도우 NT는 x86, PowerPC 등 다양한 CPU를 target으로 개발되고 있었기 때문에, 비록 기계어 코드는 공유를 못 하더라도 동일한 헤더로 실행 파일 바이너리들을 식별하고 관리 가능하게 할 필요는 있었다. 하지만 정작 PE는 한 바이너리에 다양한 아키텍처의 기계어 코드를 한꺼번에 담는 건 지원하지 않는다.

세월이 흘러 지금이야 PC의 역량도 충분히 매우 발전하여, 매킨토시를 사실상 다 따라잡은 지가 오래이다. (그런 비주얼 쪽의 발전을 주도한 건 다 게임이라 해도 과언이 아닐 듯.) 기계어까지 가상 바이트코드로 대체하려는 발칙한 시도가 가능해졌을 정도이니 컴퓨터가 얼마나 성능이 좋아진 셈인가?

그랬는데, 지금 나는 그 시절의 매킨토시보다 훨씬 더 성능이 좋은 매킨토시 노트북 PC를 아무렇지도 않게 갖고 다니며 쓰고 있고, 사실 그 기계로 맥OS보다 윈도우를 여전히 훨씬 더 많이 쓰고 지낸다. 격세지감이 아닐 수 없다!

Posted by 사무엘

지난 2012년 6월 30일엔 수인선 복선 전철 1차 구간이 개통했다. 그리고 그 이튿날에는 서울 수도권에서의 첫 경전철인 의정부 경전철이 개통했다. 그런데 그와 비슷한 시기인 6월 27일에는 철덕들이 기릴 만한 아주 의미심장한 사건이 또 있었다. 바로 우리나라에서 딱 한 군데 존재하던 영동선 스위치백이 역사 속으로 사라진 것이다.

문제의 장소는 태백선과 영동선이 합류하는 강원도 태백시와 삼척시 사이의 지점이다. 아래의 그림을 보기 바란다. (바탕 그림의 출처: 네이버 지도)

동백산 역 이북으로 올라가는 영동선은 험준한 산을 오르느라 몹시 고달프다.
자, 무엇부터 설명하는 게 좋을까?
이번에 새로 개통한 노선은 연화산을 빙 도는 연보라색의 둥근 똬리굴(1)과 한 치의 곡선도 없이 북쪽으로 정면돌파하는 분홍색 선(2)이다. 이것이 기존의 초록색 선과 파란색 선을 대체하게 되었다.

지금으로부터 거의 반세기 가까이 전에는 영동선에 인클라인이 있었다는 것을 철덕이라면 알 것이다. 거기는 철길이긴 하지만 경사가 지나치게 급해서 열차가 자기 힘으로 올라갈 수가 없었다. “설렁탕을 사 왔는데 왜 먹지를 못하니?”가 아니라, “레일을 깔아 놓았는데 왜 달리지를 못하니?”였다.
그래서 이 구간만 기관차와 객차를 한 량씩 크레인으로 끌어당기고, 승객들은 내려서 옆에서 언덕을 걸어 올라가야 했다.

여기서 오해하지 말아야 할 점은, 크레인의 힘이 부족해서 승객이 내려야 한 건 아니라는 사실이다.
객차에 승객과 짐이 꽉 차 있어 봤자 기관차 한 량보다 더 무거울 리는 없잖은가.
승객들을 부득이 다 하차시킨 것은 그냥 안전 문제 때문이었을 거라는 게 내 생각이다. 사람들이 뒤에서 같이 객차를 밀어야 했던 건 더욱 아니다.

자, 그 인클라인이 있던 곳이 바로 지금은 폐역하고 없는 통리 역과 심포리 역 사이였고, 지도에서는 대략 '빨간색 선'에 해당한다. 이 1km 남짓 되는 인클라인을 8배가 넘는 거리와 그 대신 1/8 이하의 경사로 우회 대체시킨 것이 옆의 초록색 선이다.

그 뒤 그 이름도 유명한 스위치백은 N자 모양의 파란색 선이다. 초록색 선 정도의 회전 반경을 낼 공간마저 부족했던 관계로 부득이 열차를 정지시키고 후진을 하게 만든 것이다.

스위치백은 관광객에게는 흥미로운 체험 수단이지만 원시적이고 운전하기 까다로우며 열차의 원활한 운행에는 방해가 되는 존재였다. 게다가 구불구불한 기존 초록색-파란색 선로는 지반도 그리 좋지 않아서 위험했다고 하니, 궁극적으로는 이들을 대체할 깔끔한 선로가 필요했다.

그래서 다른 지대인 연화산 기슭을 한 바퀴 빙 돌면서 언덕을 오르는 대체 똬리굴이 개통했다. 평지가 아니라 터널이다. 똬리굴 자체는 우리나라에 이미 중앙선을 비롯해 몇 군데 있지만 이번에 개통한 건 국내 최대 규모이다. 이 터널의 이름은 '솔안 터널'이고, 터널 자체는 이미 2006년에 관통식까지 끝나고 완공되었다.

솔안 터널은 스위치백뿐만 아니라 과거의 인클라인 대체 우회 선로까지 훌륭히 대체했으며, 전체 거리는 기존의 우회 선로보다 더 단축시키고 열차의 운행 시간도 10분이 넘게 더욱 단축시켰다.
어떤 철도의 선형이 하루아침에 이 정도로 급격하게 바뀌고 지도까지 덩달아 바뀌는 일은 앞으로도 매우 드물 것이기 때문에 이는 국내 철도사에 길이 남을 큰 사건으로 기억될 것이다.

재래식 스위치백 선로의 폐선을 며칠 앞두고 코레일에서는 평소에는 정차하지 않던 스위치백 구간의 간이역에도 영동선 여객 열차를 정차시켜 줬었다. 거기서는 당연히 철덕들의 향연이 펼쳐지곤 했다.

그리고 좀 옛날 소식이긴 하다만, 지난 6월 초엔 웬 KTX 산천 한 편성이 강릉으로 디젤 기관차의 견인을 받아 끌려가서 스위치백까지 넘는 사상 초유의 이벤트가 벌어졌었다. 평창 동계 올림픽도 열리는데 앞으로는 강원도에도 고속신선이 깔리고 고속철이 들어갈 거라는 홍보 행사를 위해 현역 고속철 한 편성이 얼굴마담 자격으로 끌려간 듯하다.

발상 자체는 좀 병맛 같기도 하지만 어쨌든 KTX 산천이 강원도에 들어와서 스위치백 고개를 넘는다니, 게다가 한 달 남짓 뒤면 역사 속으로 사라질 그 스위치백을 말이다. 이 소식은 전국의, 아니 듣자하니 심지어 일본의 일부 철덕들의 시선까지 사로잡았다. 이 KTX는 미리 대기하고 있던 철덕들의 카메라 플래시 세례를 집중적으로 받았으며, 자가용을 굴리는 철덕은 아예 도로를 나란히 달리면서 열차를 따라가며 사진을 찍었다.

이런 열정을 가진 사람들이 있기에 세상은 비록 죄악도 있으나 일말의 아름다움도 갖추고 있다. 비록 본인은 교회크리와 논문크리 때문에 그 당시에 이런 사람들과 함께하지 못했으나, 마음만은 그들과 함께하며 그들을 응원한다.

Posted by 사무엘

프로그래밍 언어가 제공하는 기본 라이브러리에는 단순히 자주 쓰이는 자료 구조나 알고리즘 외에도, 운영체제에다 요청을 해야 지원받을 수 있는 기능이 일부 있다. 메모리를 할당하거나 파일을 읽고 쓰는 작업이 대표적인 예이다. C/C++ 라이브러리라 해도 그런 기능은 궁극적으로 Windows API 같은 저수준 API를 호출함으로써 제공하는 셈이다.

그러니 프로그래머로서는 굳이 이식성을 염두에 두고 작성하는 코드가 아니라면, 언어가 제공하는 API보다 운영체제가 제공하는 API를 직통으로 쓰는 게 성능면에서 낫지 않나 하는 생각을 하게 된다.
이게 완전히 잘못된 생각은 아니다. 그러나 그렇지 않은 경우도 있으므로 주의해야 한다.

예를 들어, 윈도우 API에 있는 ReadFile/WriteFile과, C 라이브러리에 있는 fread와 fwrite를 생각해 보자.
C 라이브러리의 소스를 보신 분은 있겠지만, 일례로 fwrite는 내부적으로 _write 함수를 호출하는 형태이고, 두 함수만 해도 소스 코드가 수백 줄에 달한다. 뭔가 추상화 계층을 거치는 게 있고 복잡하다. 그러면서 _write 함수의 한쪽 구석에 결국은 WriteFile 함수를 호출하는 부분이 있다. fwrie가 WriteFile 직통보다 빠를래야 빠를 수가 없어 보인다.

그런데 윈도우 환경에서 프로그래밍을 오래 해 본 분은 경험적으로 아시겠지만, 몇 바이트짜리 소량의 I/O를 수백, 수천 번씩 반복해서 시켜 보면 fread/fwrite가 ReadFile/WriteFile보다 훨씬 더 빠르게 수행된다.
그렇다. C 함수는 내부적으로 버퍼링? 캐싱?을 해서 소량의 I/O는 뭉쳤다가 몰아서 한꺼번에 하는 반면, 운영체제 API는 곧이곧대로 매번 오버헤드를 감수하면서 I/O를 직통으로 하기 때문이다.

물론, 요즘은 운영체제가 자체적으로 디스크 캐싱을 다 하는 게 대세이지만, C 함수는 더 상위 계층에서도 캐싱을 하는 걸로 보인다. 이게 성능 차이가 굉장히 많이 난다.
<날개셋> 한글 입력기에서 1년 전쯤에 공개된 지난 6.2 버전의 README를 보면, 편집기의 파일 저장 및 변환기의 변환 속도가 훨씬 더 빨라졌다고 적혀 있다. 이것의 비결이 바로 저 특성을 이용해서 파일 I/O 속도를 향상시킨 것이었다.

메모리 할당도 마찬가지이다.
운영체제는 프로세스마다 heap이라는 가상 메모리를 둬서 프로그램이 다수의 작은 메모리 덩어리를 동적으로 요청할 때 빨리 빨리 반응할 수 있게 하고 있다. 연결 리스트나 트리 같은 자료구조는 메모리 할당이 잽싸게 안 되면 성능이 크게 떨어질 테니 말이다.
(이때 heap은 자료 구조 heap하고는 전혀 관계 없는 개념이므로 혼동하지 말 것.) 그래서 윈도우 운영체제에서 C 라이브러리의 malloc 계열 함수는 HeapAlloc이라는 API 함수를 호출하는 상위 계층이다.

내 경험상으로는 요즘의 NT 커널 윈도우는 HeapAlloc와 malloc, 그리고 HeapFree와 free가 성능 차이가 거의 느껴지지 않는다. 그러나 과거의 윈도우 9x 시절에는 그렇지 않았다.
“윈도우 9x에서는 이 함수는 진짜로 작은 메모리 블록에만 최적화되어 있기 때문에, 이걸로 수 MB에 달하는 메모리를 한꺼번에 여러 번 할당하면 성능이 크게 떨어지고 프로그램이 느려짐. 그 경우엔 다른 메모리 할당 함수를 쓰기 바람.”이라는 경고문이 MSDN에 명시되어 있었다.

내부적으로 그 함수가 어떻게 구현되어 있는지는 잘 모르겠지만, 내가 테스트 해 보니 진짜 그랬다. 9x에서는 프로그램이 뻗은 게 아닌가 싶을 정도로 도저히 견딜 수 없이 느려졌다.
이때에도 윈도우 API가 아닌 C 라이브러리의 malloc 함수는 랙 없이 잘 동작했다. 대용량 메모리 할당 요청이 왔을 때 가상 메모리 주소를 다시 잡는 등 대비가 되어 있어서 그런 것 같다.

원론적으로야 추상화 계층이 있는 언어 API보다는 운영체제 API 직통이 더 빠를 수밖에 없는 게 맞다. 사실, Windows API로도 모자라서 NTDLL처럼 아예 문서화되어 있지도 않은 곳에 있는 native API를 사용하는 프로그램이 있기도 하고 말이다.

그러나 프로그램의 이식성까지 희생하면서 굳이 직통 API를 쓰고자 한다면, 위에서 예를 들었듯이, 그 API의 특성을 잘 알고 쓰는 게 무엇보다도 중요하다고 하겠다. C++ 라이브러리야 객체지향 구현을 위해서 bloat되는 게 불가피하다고 쳐도, 그보다는 더 단순한 C 라이브러리의 추상화 계층은 그저 불필요한 잉여밖에 없는 건 아닐 것이기 때문이다.

Posted by 사무엘