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

1. 오버로딩과 오버라이딩의 관계

요렇게 Func라는 함수를 2개로 오버로딩한 A라는 C++ 클래스가 있다고 치자. 그리고 B는 A로부터 상속을 받았다.

class A {
public:
    virtual void Func(int x) {}
    void Func(int x, int y) {}
};

class B: public A { (...) };

B *ptr = new B;

그렇다면 B는 일반적으로야 너무 당연하게도 A가 갖고 있던 Func라는 함수에 곧장 접근 가능하다. ptr->Func라고 치면 요즘 개발툴은 사용 가능한 함수 후보 2개를 자동으로 찾아서 제시까지 한다.

그런데 B가 Func 중 하나를 오버라이드 하면 사정이 달라진다.

class B: public A {
public:
    void Func(int x) {}
    (...)
};

이전에는 Func라는 이름은 전적으로 부모 클래스의 전유물로 간주되었지만, 오버로딩 형태 중 하나라도 파생 클래스가 오버라이드 한다면 이 이름은 부모의 것과 자식의 것을 구분해야 할 필요가 생기더라.
이제 ptr->Func를 하면 오로지 B에서 갖고 있는 것 하나만 제시된다. 이제는 ptr->Func(1, 5)를 한다고 해서 부모 클래스가 갖고 있는 인자 2개짜리 함수가 자동으로 정적 바인딩 되지 않는다. ptr->A::Func(1, 5)라고 써 줘야 된다.

본인은 이런 기초적인 동작을 보고도 내 직감과는 일치하지 않는 걸 보고 약간 놀랐다. 마치 함수의 리턴값만으로는 오버로딩이 되지 않는 것처럼 저것도 C++이 제공하는 유도리의 한계인가 싶다.
내 의도는 동일한 이름의 함수를 인자의 형태를 달리하여 가상 버전과 비가상 버전으로 둘 다 만들어 놓는 것이었다. 비가상 함수는 부모 클래스 한 곳에다가만 정의해 놓은 뒤, 받은 인자를 보정하여 가상 함수 버전을 호출해 주는 고정된 역할을 한다.

그런데 이름을 동일하게 해 놓으니 파생 클래스에서는 직통으로 호출할 수가 없어서 결국 이름을 다른 걸로 바꾸게 됐다. 이런 것도 마치 생성자나 소멸자에서 가상 함수를 호출하려 한 것과 비슷한 차원의 디자인 실수가 아닌가 싶다.

2. pointer-to-member의 우선순위

C++에서 pointer-to-member 연산자인 .* 내지 ->*는 데이터 멤버를 참조할 때는 별 문제될 게 없지만, 함수를 참조해서 호출할 때는 앞부분을 따로 괄호로 싸야 한다. 즉, (obj.*ptrfn)(a, b) 내지, (pObj->*ptrfn)(x, y)처럼 말이다.
괄호 없이 pObj->*ptrfn(x, y) 이런 식으로 바로 호출이 가능하면 더 깔끔하고 자연스러울 것 같은데, 문법이 왜 이렇게 만들어지게 됐을까?

표면적인 이유는 우선순위 때문이다. 일반적인 구조체 멤버 참조 연산자인 .와 -> 그리고 함수 호출을 나타내는 괄호 연산자는 모두 우선순위가 최상이며, 좌에서 우로 결합한다. 그렇기 때문에 a.b()는 토큰들이 아주 직관적으로 순서대로 해석된다.
그러나 pointer-to-member (이하 P2M) 연산자들은 곱셈 같은 이항 산술 연산자보다만 우선순위가 높을 뿐, 다른 단항 연산자나 괄호 연산자보다 우선순위가 낮다. 그렇게 자신만의 독자적인 우선순위가 있다.

이런 구조 하에서 괄호 없이 a->*b(x,y)라고 쓰면.. ->* 뒤의 b(x,y)가 먼저 해석된다. b는 뭔가 a에 적용 가능한 P2M을 되돌리는 함수가 되는 셈이다. 하지만 P2M 자체도 쓰임이 굉장히 드문 물건인데 하물며 P2M을 되돌리는 함수라..? 일상생활에서 좀체 볼 일이 없을 수밖에 없다. 그러니 저렇게 a->*b를 괄호로 싸지 않고 곧장 함수 호출을 하는 표현도 볼 일이 없어진다.

만약 P2M 연산자의 우선순위가 일반적인 . -> 의 순위와 대등하다면 a->*b(x,y)만으로 (a->*b)(x,y)의 효과를 낼 수 있다. 아까처럼 b 자체가 따로 P2M을 되돌리는 함수라면, 그쪽을 a->*(b(x,y)) 라고 괄호로 싸야 할 것이다.

그런데 b가 데이터가 아닌 함수 P2M을 되돌리는 함수이고, 리턴값으로 또 함수 호출을 해야 한다면 어떻게 될까?
저렇게 가상의 우선순위 체계에서는 a->*(b(x,y))(X,Y)와 같은 형태가 된다.
그러나 지금의 우선순위 체계로는 (a->*b(x,y))(X,Y)가 된다. 이렇게 비교를 하니 아무래도 b만 괄호로 싸는 것보다는 a까지 다같이 괄호로 싸는 형태가 그나마 더 자연스러워 보인다.

요컨대 . ->는 오른쪽 피연산자로는 끽해야 고정된 멤버 이름밖에 오지 못한다. 임의의 변수, 상수, 값이 올 수 없다. 성격이 ::와 비슷하며, 애초에 C++ 말고 오늘날의 다른 프로그래밍 언어들은 아예 . -> ::를 전부 구분 없이 . 하나로 간소화하는 게 트렌드일 정도이다. 오른쪽 피연산자 자체에 함수 호출이 있는지, 전체 결과값을 또 함수로 호출하는지 그런 걸 구분할 일은 없다.

그 반면, .* ->*는 생긴 건 단순 멤버 식별 연산자와 비슷하게 생겼어도 피연산자로는 사실상 아무 값이나 올 수 있다. 그렇기 때문에 뒷부분에 함수 호출 () 파트가 중구난방으로 나열되는 일을 막으려면 P2M은 . ->, 그리고 ()와 동일한 우선순위를 부여해서는 안 된다는 결론이 도출된다.

(a->*b)(x,y)에서 a와 b를 싸는 괄호에는 이런 사연이 숨어 있다. 그래서 얘들은 기존 연산자들보다 우선순위가 한 단계 낮아진 것이지 싶다. 클래스에서 함수 포인터를 되돌리는 operator 함수를 선언할 때 발생하는 다소 난감한 상황과 비슷하다. 저것도 결국은 정석적으로는 안 되고 typedef나 decltype의 도움을 받아야만 선언 가능하니 말이다.

파스칼은 비트 연산자가 논리 연산자의 역할까지 하고 있고 얘가 C/C++과는 반대로 산술 연산자보다 우선순위가 높다. 그렇기 때문에 if 문 안의 (A=B) and (C>5) 이런 항들을 일일이 전부 괄호로 싸야 해서 일면 불편하다. C++의 P2M 연산자의 우선순위는 마치 이런 사연을 보는 것 같기도 하다.

3. MFC와 C 라이브러리의 충돌

C/C++에는 빌드 과정에서 컴파일 에러뿐만 아니라, 현대의 언어에서는 찾기 힘든 개념인 링크 에러라는 게 있다.
이게 단순히 '요 명칭을(주로 함수) 선언만 해 놓고 정의를 안 했네요' 같은 간단한 것만 있으면 세상이 지금보다 훨씬 더 아름다워 보이겠지만, 현실은 그렇지 않다.

C/C++은 바이너리 인터페이스 수준에서 파편화가 매우 심한 걸로 악명높은 언어이다. C++ 함수 인자의 decoration은 말할 것도 없고, 당장 언어가 기본으로 제공하는 C/C++ 표준 라이브러리부터가 그러하다. 디버그/릴리즈, 32/64비트 같은 거야 섞일 일이 거의 없을 정도로 완전히 다른 configuration이니까 그렇다 치더라도 static/DLL, 컴파일러의 제조사와 제품 버전까지도.. 그냥 전부 제각기 따로 논다고 봐야 한다.

표준 라이브러리에 malloc, qsort 같은 영원불변의 간단한 물건만 있는 건 아니기 때문에 말이다. 그러니 다양한 출처에서 빌드된 라이브리러들을 한데 엮다 보면 별의별 링크 에러를 겪을 수 있다.
그래서 컴파일러를 Visual C++로 한정한다 하더라도, 대표적으로 MFC와 C 라이브러리(CRT)부터가 특정 상황에서 서로 부딪칠 수 있다.

MFC와 CRT는 구조적으로 둘 다 DLL 형태로 쓰거나 둘 다 static 링크하는 것만이 가능하다.
그런데 DLL 링크를 할 때는 괜찮은데 static 링크를 하다 보면 가끔 operator new / operator delete라는 메모리 할당/해제 함수가 MFC에도 들어있고 CRT에도 들어있다고.. 심벌 중복 정의라는 LNK2005 에러가 뜬다.

본인의 경우는 MFC를 사용하는 C++ 프로젝트에다가 precompiled header를 사용하지 않는 타 C 코드를 프로젝트에다 넣은 채로 MFC/CRT는 static 형태로 빌드를 시도했을 때 이런 상황에 놓이곤 했다.
operator new/delete 나부랭이야 내가 짠 코드도 아닌데 저 충돌 문제를 도대체 어떻게 해결하면 좋을까..?

이건 그래도 많이 알려지고 유명한 문제인지라 간단히 구글링만 하면 해결 방법이 수십 페이지씩 쭈루룩 뜬다.
/NODEFAULTLIB 옵션을 줘서 링커가 라이브러리들을 암시적으로 자동 공급하지 않게 하고, MFC의 static 링크용 라이브러리인 uafxcw.lib를 다른 라이브러리들보다 먼저 링크되게 하면 된다.

예전에 마소에서 제공했던 Windows 9x 유니코드 API 호환 layer인 unicows 라이브러리를 사용할 때도 링커 옵션을 비슷하게 특이하게 고쳐야 했던 걸로 기억한다. kernel32, user32 같은 통상적인 라이브러리보다 unicows가 먼저 공급 되어야 Windows API 호출이 훅킹 DLL로 갈 테니까 말이다.

아무튼 C/C++은 이런 디테일까지 신경 써야 하는 피곤한 언어이긴 하다. Visual C++의 차기 버전에서는 이런 문제는 자동으로 충돌을 감지하고 해결했으면 좋겠다.

4. 맥용 swscanf의 꼬장

표준 C 함수밖에 쓰지 않은 멀쩡한 x64용 C 코드가 Windows에서는 잘 돌아가던 것이 맥에서는 제대로 동작하지 않았다.
이 경우 원인은 대부분 사소한 곳에 있었다. 파일을 읽고 쓰는 곳에 long이 들어가 있는 게 대표적인 예다. Windows는 long도 int와 동급의 32비트로 보지만 맥에서는 이걸 64비트로 키웠기 때문이다. C/C++은 long도 그렇고 wchar_t도 그렇고.. 파편화가 너무 심하다..;;

단순히 기본 타입의 크기에 대해서는 본인이 예전에도 언급한 바 있다. 그것 말고 최근에는 또 다른 괴상한 사례를 발견했다.
long 문제와도 무관하고 도대체 안 돌아갈 이유가 전혀 없는 코드에서 오류가 발생하고 있었다. 어디에서부터 변수에 잘못된 값이 들어와 있는지를 추적해 보니 문제는 swscanf이었다. wchar_t 크기쯤이야 이미 감안하고 보정을 다 했기 때문에 문제될 여지가 없었다.

"설마 이게 문제이겠나" 싶었는데 설마가 사람을 잡았다. 읽어야 하는 문자열 뒤에 한글· 한자처럼 U+100 이후의 문자가 들어가 있으면 swscanf의 실행이 무조건 실패하고 있었다. 나는 "%X"라고 인자를 줬기 때문에  "FF00 가나다"이라는 문자열이 있으면 프로그램은 '가나다'는 전혀 신경쓸 필요 없고 0xFF00만 읽어 오면 된다. 게다가 'FF00'과 '가나다'의 사이에는 멀쩡히 공백까지 있어서 확인사살을 하고 있다.

그런데 확인을 해 보니 그냥 평범한 'ABC', '^&*%' 따위가 있을 때는 괜찮은데 '가나다'가 있을 때는 실패하더라. FF00의 값을 읽는 것과는 1도 아무 상관 없으며, Windows에서는 당연히 이런 현상 없이 값을 잘 얻어 온다.
이 때문에 swscanf를 쓰던 것을 wcstol로 바꿔서 %X의 역할을 대신하게 해야 했다. wide string 기반의 유니코드이니 무슨 로케일이나 인코딩 같은 설정을 할 필요도 전혀 없는데 swscanf가 왜 쓸데없이 꼬장을 부리는지, 더구나 맥만 왜 이러는지는 알 길이 없다. 살다 보니 별 일을 다 겪었다.

5. 정적 분석 써 본 소감

여느 프로그래머들과 마찬가지로 본인은 요즘 개발툴들이 제공하는 정적 분석 기능을 잘 사용하고 있다. 방대하고 복잡한 코드에 존재하리라고 꿈에도 생각을 못 했던 실수들이 걸려 나오는 경우가 많기 때문이다. 아주 특수한 상황에서 초기화되지 않은 변수가 사용될 가능성, 메모리 내지 리소스 leak이 발생할 가능성 같은 것 말이다.
역시 인간은 어쩔 수 없이 실수란 걸 늘 저지르는 동물이다. 기계가 이런 걸 안 잡아 줬으면 개발자들이 얼마나 고생하게 됐을까? 더구나 내가 직접 만들지도 않고 남이 짠 지저분한 코드를 인계받아서 유지 보수해야 하는 처지라면 말이다.

심지어 내가 머리에 총 맞기라도 했는지, 왜 코딩을 이 따구로 했었나 자괴감이 드는 오류도 있다.
물론 이런 것들은 처음에 코드를 그렇게 작성한 것은 아니다. 나중에 해당 코드가 변경되고 리팩터링이 됐는데 그게 모든 곳에 적용되지 않고 부분적으로 편파적으로만 적용되면서 일관성이 깨진 경우가 더 많다. 예를 들어 리턴값의 타입이 BOOL이다가 나중에 필요에 따라 int로 확장됐는데, 마치 Windows API의 GetMessage 함수처럼 체크 로직은 >0으로 바뀌지 않고 여전히 !=0이 쓰인다면 그런 부분이 잠재적으로 문제가 될 수 있다.

먼 옛날, Visual C++ 4~6 시절에는 프로그램을 빌드할 때 부가 옵션을 줘서 browse 정보를 추가로 생성할 수 있었다. 빌드 시간과 디스크 용량을 매번 추가로 투자해서 이걸 만들어 둬야만 임의의 심벌에 대해서 "선언/정의로 이동, 함수의 Calls to/Called by 그래프 조회" 같은 편의 기능을 사용할 수 있었다.

그랬는데 세월이 흘러서 지금은 C++ 같은 문맥 의존적인 언어조차 심벌 browse 기능 정도는 IDE의 백그라운드 컴파일러로 실시간으로 다 가능하고 최신 정보가 수시로 갱신되는 지경에 이르렀다. 그 대신 지금은 빌드 때의 추가적인 액세서리에 해당하는 것이 바로 '소스 정적 분석'이 된 거나 마찬가지이다. 단순히 기계어 코드를 생성하는 빌드보다 시간이 더 걸리는 대신, 통상적인 너무 뻔한 경고보다 훨씬 더 자세하고 꼼꼼하게 소스 코드에서 의심스러운 부분을 지적해 주는 것이다.

6. C++ 디버깅

하루는 회사에서 Visual C++ 2015로 개발하던 C++ 프로그램을 불가피한 사정 때문에 더 낮은 버전인 Visual C++ 2012로 빌드할 일이 있었다.
빌드는 별 문제 없이 됐지만, 그 프로그램은 제대로 실행되지 않고 초반부에서 바로 뻗어 버렸다.

디버거로 들여다보니 원인이야 어처구니 없는 실수 때문이었고 금방 밝혀졌다. 클래스의 생성자에서 멤버들이 ABC~XYZ 순으로 초기화되는데, A~C의 초기화 과정에서 아직 초기화되지 않은 뒤쪽 멤버들을 참조하는 멤버 함수를 호출했던 것이다.
컴파일러가 지역 변수 int를 초기화하지 않고 사용하는 것 정도는 곧장 지적해 주지만, 저런 실수까지 찾아내는 건 정적 분석의 경지로 가야 하는 모양이다.

그런데 문제는 이런 버그가 오랫동안 존재했던 프로그램이 지금까지 2015로 빌드할 때는 왜 잘만 돌아갔느냐는 것이다. 그것도 디버그가 아닌 릴리즈 빌드로 말이다. 이 객체는 new로 heap에다가 할당하는 것이어서 전역변수와는 달리 초기에 내부 메모리가 언제나 0초기화라는 보장도 없는데..
더구나 C++은 성능 덕후 언어이기 때문에 파생 클래스 부분까지 기본적인 초기화를 다 해 준 뒤에 기반 클래스의 생성자를 호출하는 것도 아니고, 생성자에서 자신의 초기화되지 않은 부분을 건드려서 순수 가상 함수 호출 같은 각종 문제가 얼마든지 발생할 수 있는데... 언어 디자인이라는 구조적인 차원에서 말이다.

프로그램의 빌드 configuration을 바꾸면 한 환경에서는 없던 문제가 금세 튀어나올 수 있다. 디버그에서 릴리즈, 혹은 반대로 릴리즈에서 디버그로 양방향이 모두 가능하다.
또한, 평소에는 탄탄한 최신 NT 계열 Windows에서 개발하다가 프로그램을 더 불안하고 연약한 환경인 9x에서 돌리면 숨겨진 버그나 리소스 누수가 튀어나올 수 있다. 요즘 컴파일러에서는 이렇게 할 수조차 없지만 말이다.

그런데 컴파일러의 버전을 더 낮췄더니 숨겨진 문제가 튀어나온 경험은 이번이 거의 처음이었다.

Posted by 사무엘

1. 수동 변속기

자동차 운전을 오래 한 나이 지긋하신 분들은.. 전자 기기 일색이 된 요즘 차에서는 경험할 수 없는 옛날 차량의 '단순무식하고 견고한 특성'에 대해 일종의 향수를 갖고 있는 편이다.

대표적인 예 중 하나는 단연 수동 변속기이다. 수동은 엔진의 힘이 고정된 비율로 곧이곧대로 바퀴에 전해지며, 강한 힘이 필요할 때도 저단에서 밟으면 밟는 대로 곧장 나간다.
그에 반해, 자동은 가속 페달을 깊게 꾹 밟은 채로 1초 남짓 좀 기다려야 킥다운이 일어나면서 추진력이 올라간다. 특정 단이라는 개념이 없고 시동 꺼뜨리는 일도, 클러치 일일이 밟고 떼는 불편도 없는 대신, 차가 운전자의 의중을 '간보고' 보정하기 위해 어느 정도 딜레이가 필요하다.

이건 수동 운전의 사고방식으로는 상상도 할 수 없는 일이다. 불편하게 일일이 클러치 밟고 떼도 좋으니, 차의 모든 상태를 자기가 스스로 파악하고 통제하고 결정하기를 원하는 골수 기계덕이라면, 자동보다 수동을 모는 게 마음이 더 편할지도 모르겠다.
그러나 그런 사람들도 수동 운전을 좋아하는 것과는 별개로, 오르막에서 멈췄다가 뒤로 안 밀리고(특히 뒷차와 부딪치지 않고) 매끄럽게 출발하는 건 어려워하고 부담스러워하는 경우가 많다고 한다.;;

자동 변속기의 등장 초창기에는 킥다운조차도 버튼이 따로 있어서 이걸 사용자가 수동으로 알려 줘야 하기도 했다.
오늘날도 자동이라고 해서 언제나 D에만 갖다놓고 때때로 킥다운만 하는 게 장땡은 아니다. 저단 고정이라든가 오버드라이브, 파워 모드 같은 미세한 제어 옵션이 달려 있다. 오르막· 내리막, 추월 같은 상황에서 이를 적절히 활용하면 주행 연비를 개선할 수 있다.
(오버드라이브는 끌 경우 3 또는 4단 이하 변속만 허용하는 그냥 또 다른 형태의 저단 고정 기능 아닌가? 그런데 옛날엔 왜 따로 특별히 소개했는지 이유를 잘 모르겠다.)

참고로, 파워 모드는 단순히 자동 변속 조건을 평소보다 더 높은 rpm 시점으로 바꾸는 역할을 한다. 말 그대로 변속기의 수준에서 연비를 좀 희생해서 속도보다 가속력을 중시하는 결정을 내릴 뿐, 다른 마법을 동원해서 엔진에 힘을 더 불어넣는 건 아니다.

2. 카뷰레터

지금까지는 변속기 얘기를 했다. 그런데 옛날에는 자동차에 동력비의 변환만 수동· 기계식인 게 아니라 연료 분사까지 아주 원시적인 수동· 기계식이던 시절이 있었다.

운전자가 가속 페달을 밟으면 차에 힘을 내기 위해서 연료고 공기고 뭐든지 많이 공급해 줘야 하는데, 이거 비율을 적절하게 맞추는 게 생각보다 어려운 일이었다. 그게 적절하지 않으면 기껏 많이 공급한 연료가 제대로 연소하지 못해서 힘은 힘대로 안 나면서 연비는 안드로메다로 가고, 배기가스만 잔뜩 나올 수 있었다. 디젤의 경우는 이건 더 심각한 문제이다.

전동차로 치면 저항 제어만큼이나 가장 원시적인 연료 공급 메커니즘은 기화기라고도 불리는 카뷰레터 방식이다. 이건 아주 간단히만 설명하면, 전자 기기가 정밀하게 뭔가를 통제하는 것 없이, 공기의 흐름을 따라 물리 법칙에 의해서 연료가 저절로 기화되어 섞이고 혼합 기체가 되게 한 것이다.

이런 카뷰레터 방식의 자동차는 단순 무식하게 밟으면 밟는 대로 엔진 rpm이 막 올라가고 반응성이 좋았다고 한다. 이건 안 그래도 수동 변속기의 장점이기도 한 특성인데.. 옛날 카뷰레터 엔진 차량의 엔진룸을 열어 보면 둥근 밥통처럼 생긴 헤드가 달려 있었다.

하지만 원시적인 카뷰레터의 단점은 아까도 말했듯이 연비와 환경 문제이다. 그런 단순무식한 방법으로 연료를 공급해서는 요즘 자동차 같은 효율을 절대로 달성할 수 없다.

또한, 굳이 가속을 안 하더라도 엔진이 돌면 도는 만큼 연료가 자연적으로 소모되는 매우 큰 문제가 있었다고 한다. 즉, 퓨얼컷(fuel cut)이라는 게 없었다. 내리막에서 저단 엔진 브레이크를 걸어서 전적으로 바퀴를 따라 엔진 회전수가 올라간 건데도 연료는 그 회전수에 맞춰서 쿵짝쿵짝 소모되었다.

그렇기 때문에 옛날에는 긴 내리막을 갈 때는 시동을 끄는 것까지는 위험하지만 기어를 차라리 중립으로 맞춰서 rpm을 줄이는 게 연비에 좋다는 팁이 통용될 정도였다. 지금으로서는 상상도 할 수 없는 모습이다.

그 시절 옛날 자동차들은 주변 기온에도 더 민감했다. 날씨가 너무 추우면 배터리 같은 전기 장치뿐만 아니라 엔진도 잘 안 돌았다. 그래서 시동을 건 뒤에 어느 정도 공회전 예열이 필요했고, 또 시동이 잘 안 걸릴 경우 '초크 밸브'라는 걸 당겨서 연소실에 공기를 강제로 더 불어넣거나, 반대로 줄여서 연료의 농도를 올려 줘야 했다. 같은 힘을 내는 적정 공기량은 온도에 따라 달라지는 편인데 그걸 기계식 카뷰레터만으로는 알맞은 값을 스스로 감지할 수 없었기 때문이다.

그에 반해 요즘 자동차들이야 ECU 기반의 전자식 인젝터에, 간접 분사도 넘어서 직분사 같은 다양한 연료 분사 기술이 개발되었고 저런 번거로운 절차들은 다 자동화되었다. 공회전은 쓸데없이 오래 할 필요가 전혀 없으며, 내리막길을 갈 때는 엔진 브레이크 잘만 쓰면 된다. 오히려 중립은 시동 유지를 위해서 공회전만치의 연료가 들지만, 바퀴에 의해 엔진이 저절로 돌아가고 있을 때는 연료가 진짜로 전혀 들지 않는 퓨얼컷이 실현된다.
즉, 약간의 단순무식 거칠고 날렵함을 희생한 대신, 요즘 자동차는 더 똑똑해지고 운전하기 편해지고 성능과 경제성, 친환경성이 더 강화된 셈이다.

비행기만 해도 주변 온도와 공기 밀도, 기체의 중량 같은 온갖 복잡한 변수를 고려해서 V1 속도와 활주거리가 결정되는데, 자동차도 비록 그 정도까지는 아닐지라도 엔진 시동과 구동은 매우 섬세하고 복잡한 변수가 많은 메커니즘인 것 같다.
이런 옛날 자동차와 요즘 자동차의 특성을 감안했을 때, 고연비 고효율, 차에 좋은 주행을 하는 요령을 몇 가지 나열하면 다음과 같다.

1. 시동 건 직후에 워밍업 공회전 쓸데없이 오래 하지 말 것.

물론 엔진 오일의 점성과 냉각수 온도를 맞추기 위해 길어야 10~20초 정도.. 시동 직후의 엔진 rpm이 좀 낮아질 때까지는 기다리는 게 좋다. 하지만 혹한에서 디젤 차량 정도가 아닌 이상, 분 단위의 공회전은 전혀 필요하지 않다.
긴 공회전과 예열은 바로 저 옛날 카뷰레터(기화기) 엔진 시절의 잔재일 뿐이다.

2. 내리막이나 평지에서 기름 아끼고 싶다고 쓸데없이 N으로 바꾸지 말 것.

요즘 차들은 똑똑하기 때문에 차라리 D를 유지하고 상황에 따라 다음 둘 중 한 테크닉의 혜택을 입는 게 훨씬 더 낫다.

(1) 액셀 페달을 아예 안 밟아서 엔진 브레이크 + 퓨얼컷: 비록 완전 중립 관성 주행일 때보다는 차의 속도 감소 폭이 더 크지만, 이때는 전적으로 바퀴 관성만으로 엔진이 돌아가면서 연료가 아예 소비되지 않는다(이미 1500rpm 이상 정도로 엔진이 돌고 있는 경우). 그 반면, 중립일 때는 아이들링 rpm 유지를 위해서 기본적인 연료는 소모됨.
긴 커브+내리막에서 저단 엔진 브레이크는 브레이크 페달의 부담도 어느 정도 덜어 주는 굉장히 좋은 테크닉이다. 시속 100km 상태에서 1단.. 같은 미친 짓만 안 하면 된다.

(2) 액셀 페달을 얇게 꾸준히 밟아서 락업 클러치: 이러면 엔진 힘이 변속기의 토크 컨버터를 안 거치고 바퀴로 바로 전해진다. 특히 시속 60~80km급의 경제 속도에서 주기적인 재가속 없이 반쯤 크루즈 상태로 주행하면 가히 최강 연비를 달성할 수 있다.

3. 신호 대기처럼 작정하고 오래 정차가 예상된다면, D+브레이크 꿋꿋이 유지하는 것보다는 N으로 바꾸는 게 좋음.

요즘 차들은 D+브레이크 정차 상태가 오래 계속되면 자동 중립으로 최적화도 해 준다고는 한다만.. 일단은 기계적으로 봤을 때, 가려는 차를 억지로 붙잡고 세워서 변속기를 열받게 하는 것보다는, 직접 엔진과 바퀴를 분리시켜서 불필요한 동력을 끊어 주는 게 더 낫다. 똑같이 정차 공회전을 해도 N일 때 연료 소모가 약간이나마 더 적었다는 실험 결과도 있다. 수동에서 저랬으면 차가 견디지 못하고 바로 시동이 꺼졌을 것이다.

2와 3을 한데 요약하면, 변속기의 본래 설계 취지에 맞게 D는 주행할 때만 쓰고, N은 정차할 때만 쓰면 된다.
컴퓨터에서도 과거에 통했던 성능 최적화 꼼수들이 멀티코어 병렬화 시대가 되면서 통하지 않게 된 게 많은데 뭐 그런 걸 보는 느낌이다.

4. 주차하느라 전진· 후진을 자주 전환할 때.. 차가 완전히 서기 전에 P 또는 반대 진행 방향 기어로 절대 절대 성급하게 바꾸지 말 것.

이건 옛날 차든 요즘 차든 공통으로.. 모든 자동차 전문가들이 이구동성으로 말하는 당부사항이다.
엔진 브레이크야 변속기가 브레이크의 역할을 일부 도와주는 것이다. 하지만 엔진 브레이크는 애초에 아이들링 rpm의 크리핑 속도보다도 더 느리게 차를 완전하게 세우는 기법이 전혀 아니다. 아이들링 rpm 상태에서도 차가 내는 힘은 엄청나며, 브레이크의 제동력으로 감당해야 할 힘을 변속기가 받으면 변속기가 망가진다. "시속 100km에서의 1단"과는 반대 방향 극단으로 차가 무리를 받게 된다.

잦은 변속 자체는 변속기를 닳게 하거나 차의 수명을 떨어뜨리는 짓이 결코 아니다. 단지, 차가 완전히 서지 않았을 때 변속하는 것이 변속기에 무리를 줄 뿐이다. 위의 성질 급한 관행으로 인해 차가 고장 나는 것 때문에 정차 중에 정상적으로 N에다 두는 것까지도 차에 안 좋은 것처럼 오해받는 것이다.
그 밖에, 빨리 튀어나가려고 정지 상태에서 미리 rpm 왱알앵알 거리거나, 구동축 바퀴를 헛돌게 하는 것도 웬만하면 하지 말 것..;

Posted by 사무엘

하루는 식당에서 저녁을 먹는데, 저 멀리 텔레비전에서는 무슨 쇼 프로에서 연예인들이 등산을 하는 장면이 나왔다. 주변이 시끌벅적하고 화면이 잘 안 보였지만, 그래도 저 고깔 모양의 정상 표지석은 99% 청계산 매봉이라는 확신이 들었다. TV 근처로 다가가서 확인해 보니 내 예상이 맞았다.

예전에는 깜깜한 밤에 지상 전철 승강장에서 저 멀리 보이는 헤드라이트 불빛의 모양만 보고는 8000호대 전기 기관차가 오는 거라고 예상을 했고 예상이 실제로 적중한 적이 있었다. 뭐, 이것도 철덕에게는 기본 중의 기본 스킬이겠지만.. 철도만큼이나 등산도 짬이 차니까 이런 감까지 생기는구나 싶었다.

서울 강북에 북한산· 도봉산· 수락산 같은 산이 있다면 강남에는 관악산과 청계산이라는 제법 크고 높은 네임드급 산이 있다. 청계산은 전반적으로 흙산이기 때문에 손으로 로프를 잡고 올라야 하는 건 거의 없으며, 오르기 쉬운 편에 든다.
신분당선이 개통한 뒤에는 '청계산입구'라는 역이 생긴 덕분에, 거기 근처에 있는 서울 신원동 등산로로는 주말에 등산객이 굉장히 늘었다. 기슭에는 산악용품 가게와 등산객 뒤풀이용 식당들이 즐비하다. 신분당선이 없던 시절에는 4432 같은 버스가 청계산으로 가는 길을 책임졌던 것으로 본인은 기억한다.

거기서 옥녀봉 또는 582m짜리 매봉 정상까지 갔다가 그대로 돌아오는 게 무난한 코스이다. 내 기억으로 매봉 정상은 미묘하게 갈림길도 있다. 입산과 하산 지점은 동일하지만 중간에 거치는 경로를 달리할 수 있다. 본인은 그쪽으로 청계산 등산은 회사 사람과도 하고 교회 사람과도 해 봤다.

하지만 거기보다 더 남쪽으로 서울을 벗어난 성남시 고등동· 상적동 옛골 마을 일대에도 청계산 등산로가 있다. 4432의 종점 근처인데, 본인은 옛날에 인릉산을 찾아갈 때 여기까지 가 본 적이 있다. 그 시절엔 거기에서 또 청계산을 오를 생각은 미처 못 했으며, 예전에 갔던 매봉이 청계산에서 가장 높은 정상이기 때문에 청계산을 더 오를 필요는 없다고 생각했다.

그런데 알고 보니 청계산에는 매봉보다 더 높은 정상이 존재할 뿐만 아니라 거기에는 우면산이나 성남 검단산처럼 공군 방공 부대도 있다. 민간인 등산객은 거기로 접근할 수 없고 거기서 살짝 떨어진 곳의 공터를 정상인 줄 알고 간다.
이렇게 흥미로운 정보들이 많이 입수되었기 때문에 본인은 지금까지 들른 적이 없는 청계산 등산로와 정상을 개척하기 위해 성남시 상적동 옛골 마을을 찾아갔다.

옛골 마을은 이렇게 생긴 평온한 동네이다. '상적천'이라는 개천이 지나며, 이 때문에 근처의 경부 고속도로도 여기는 살짝 교량 형태로 지난다(상적교). 주변엔 등산객을 위한 식당과 카페가 많지만 막 유명한 유원지 같은 정도는 아니다.
저기까지 대중교통으로 갈지 아니면 아예 차를 가져갈지 고민하다가 차를 선택했다. 딱 봐도 아무 곳에나 딱히 주차 걱정을 할 필요는 없어 보이는 곳이며, 이번에는 등산 경로를 여기로 다시 돌아오는 형태로 계획했기 때문이다.

안 그래도 등산을 마친 뒤에 몸이 땀범벅 녹초가 됐는데, 편안한 귀가를 위해 차를 가져간 건 아주 잘한 선택이었다. 새벽에 적당한 곳에다 차를 세워 놓은 뒤, 차에서 한숨 자고 나서 아침부터 산을 오르기 시작했다.

마을 어귀에는 이렇게 청계산 꼭대기의 군부대로 가는 길이 떡 놓여 있었다. "경고 - 민간인 차량 통제"라는 팻말과 함께 말이다.
사실은 경부 고속도로 부산 방면에서도 이 길로 합류하는 비밀 진출로가 있다. 마치 헌릉로에서 국정원으로 들어가는 진출로처럼 말이다. 경부 고속도로 개통 초기에는 "상적 IC"라고 진출입로가 정식 등재도 돼 있었지만 나중에 슬그머니 폐쇄된 듯하다. 비상 활주로만큼이나 고속도로의 또 다른 군사 활용의 예라 하겠다.

하지만 민간인은 차량만 못 들어갈 뿐이지, 보행자 등산객은 저기로 통행 가능하다. 저기에는 엄연히 성남 누비길 구간과 청계산 등산로가 포함되어 있기 때문이다.

이런 길을 따라 오르막을 오르면 군부대 초소가 나온다. 민간인은 초소 너머 군부대 내부로는 물론 들어갈 수 없지만, 그래도 차도를 벗어나 옆으로 등산로로 들어갈 수 있다. 본인의 등산은 이렇게 시작되었다.

옻샘 약수터에 도달했다. 맑고 시원한 물 보급을 받을 수 있어서 무척 좋았다.
북쪽의 매봉이 아니라 남쪽의 망경대 방면으로 가야 하는데, 마침 옻샘이 나왔다는 건 지도상으로 계획했던 길을 잘 찾아간 것이었다.

산길은.. 숲이 울창하고 뭐 이런 분위기였다. 날씨가 무척 맑고 좋았다.

처녀 폭포라는 자그마한 폭포가 있어서 들렀다.
그리고 여기 부근(대략 4~500 m 떨어진..)에는 군부대로 향하는 샛길도 있었다. 본인 역시 따라 가서 주변 구경을 좀 하다가 되돌아왔다.

중간에 '힐링의 숲'이라고, 그냥 평범한 탁자나 벤치, 마룻바닥뿐만 아니라 저렇게 S자형으로 반쯤 누울 수 있는 목재 의자가 산에 놓여 있었다. 저기 누워 있으니까 굉장히 편하긴 했다. 이대로 한숨 자고 싶을 정도였다.

힐링의 숲 이후부터는 이정표 없이 한참 동안 가파른 오르막을 올라야 했다.
그러다 드디어 '혈읍재'라고 불리는 고개에 도달했다. 고개의 이름이 '피가 울다'라는 섬뜩한 뜻인 이유는 조선 시대와 관련된 역사적 사연이 있다.
거기에서부터 또 계단을 타고 한참을 오르면 이제 정상이 얼마 안 남았는지 옆으로 철조망을 따라 군사 시설이 보이고... 나중에는 이런 넓은 공터가 나타났다.

위의 사진 시야를 기준으로 전방에 있는 작은 길은 산을 내려가는 찻길이다. 저 길 자체는 민간인도 통행 가능해 보였지만, 본인은 아직 하산할 생각이 없으므로 저기로 가지 않았다.
사진에 나오지 않은 뒤로는 각종 차들이 세워져 있었다. 번호판이 '국'인 희귀한 차량도 있었다(국방부 소속!!).

그리고 역시 사진에 나오지는 않았지만 오른쪽으로, 위쪽의 건물 방면으로 올라가는 찻길이 있었다. 망경대 정상으로 간 뒤 이수봉 방면으로 산행을 계속하려면 그 오르막길을 가야 했다. 본인은 그 방향을 선택했다.

저 멀리 우측 상단의 관악산 정상이 보인다. 산 아래에 있는 건물들은 과천 시내이다.
청계산은 전반적으로 나무로 빽빽하게 덮여 있으며, 등산 중에 산 아래를 내려다볼 만한 전망대 같은 곳은 거의 전무하다. 그나마 정상에 근접해서야 이런 사진을 찍을 만한 곳이 나왔다. 그리고 위의 사진은 아직 완전히 정상에 도착해서 찍은 건 아니다.

청계산 봉우리들의 다른 정상들은 다 흙바닥 공터이고 정상 표지석도 있는 반면, 망경대만은 북한산이나 도봉산의 정상처럼 꼭대기가 그냥 바위였다. 청계산에서 유일하게 밧줄 붙잡고 꽤 아슬아슬하게 올라야 했다. 여기는 본인도 부득이하게 백팩을 아래에다 내려다놓고 몸만 올라갔다. 위의 사진에서 본인 손에 맥북이 들려 있지 않은 게 이 때문이다.

주위를 둘러보니 덜 위험한 우회 등산로를 거쳐서 바위로 오는 길도 있어 보였다. 하지만 놔 두고 온 백팩 때문에 그리로 내려가 볼 수도 없었다.
이 정상은 곁에 있는 군부대가 자리잡은 봉우리보다는 약간 미묘하게 낮지만, 그래도 아까 그 흰 돔이 2개 달린 관측 시설보다는 훨씬 높았다. 국가 안보를 위해 이 시설들을 찍은 사진은 블로그에 게재하지는 않기로 하겠다. 궁금하신 분은 직접 등산 가서 보시길..

서울랜드가 내려다보였다. 저기는 한때는 잘나갔었으나.. 시설물의 퀄리티가 넘사벽급 대기업 관할인 롯데월드와 에버랜드에 비할 바는 못 되니 슬슬 인기가 하락하는 중이다.

서울 공항 방면으로도.. 본인은 저 앞에 보이는 산들도 나름 올라 봤다. 저 멀리 병풍 같은 산이 바로 성남과 광주의 경계 역할을 하니까 말이다.

망경대 바위 위에서 경치 구경을 실컷 한 뒤, 본인은 하산하여 남쪽으로 계속 걸어갔다. 내려가던 중에 이렇게 평평하고 나무가 없는 공터가 나왔다.
위의 사진은 저 흰 돔이 보이는 것에서 알 수 있듯, 뒤 돌아서 왔던 길 쪽으로 찍은 것이다. 이 공터에서는 아래로 내려가는 찻길 또는 이수봉 방면 오르막 도보 등산로를 선택할 수 있었다. 본인은 이수봉 쪽으로 갔다. 여기를 끝으로 찻길 분기점은 더 등장하지 않았다.

그래도 중간에 이런 헬리패드가 나왔으며..

한참을 산을 더 오른 뒤에야 드디어 이수봉에 도달했다. 본인은 지금까지 청계산에서 이런 정상 표지석을 본 적이 없으니, 새로운 등산로 탐험을 이 기회에 그럭저럭 잘 해냈다.
이제 하산을 시작했다. 하산도 길 잃지 않고 잘 해서 차가 있는 곳으로 무사히 돌아가야 하니까 말이다. 이정표가 나오면 국사봉이나 과천 매봉 방면 말고 '옛골'이라고 적혀 있는 곳만 골랐다.

하산을 시작한 지 얼마 안 되어 철조망이 쳐진 거대한 구역이 나타났다. 그런데 평범한 '군사 시설, 무단 접근과 촬영을 금함 -- oooo부대장'이 아니라, 관리 주체가 웬 듣도 보도 못한 기관인 '도시환경 연구소'라고 적혀 있었다. 본인으로서는 인터넷 검색을 해 봐도 정체를 알 길이 없다.
철조망 사진도 이곳에다가 대놓고 올리지는 않겠다. 위의 사진은 철조망 구역을 다 지나치고 나서 다시 울창한 숲이 등장한 뒤의 하산 경로 풍경을 찍은 것이다.

한참을 내려가다 보니 언제부턴가 물이 졸졸 흐르는 계곡이 길 옆에 등장했다. 이 계곡이 아래의 상적천으로까지 이어지는 모양이다. 그리고 올라갈 때 옻샘 약수터를 만났다면, 내려올 때는 '천수샘 약수터'를 지났다. 하지만 여기 물은 대장균이 기준치 이상으로 검출되어 음용 불가라고 옆에 쓰여 있었다.

산을 오를 때는 종아리가 힘들고 땀이 왕창 나고 물도 많이 마시게 되는데, 내려갈 때는 그런 식으로 덥고 힘든 것은 없다. 그 대신 무릎과 발목 관절이 남아나질 못하는 것 같았다. 등산을 오랜만에 해서 그런지 슬슬 삭신이 쑤시고 다리가 후들거리기 시작했다.

착륙이 이제 얼마 안 남았다. 등산로 옆으로 갑자기 이런 밭이 등장했다. 그리고 저 고개 너머엔 사격장이 있는지 본인이 방문하던 당시에 사격 훈련을 하고 있었다. 총소리가 막 들렸다. 실제로 구글 어쓰로 보니 그쪽엔 예상대로 사격장처럼 생긴 시설이 보였다.

아까 그 밭에서 거의 6, 700미터쯤 걸은 뒤에야 옛골 마을이 다시 등장했으며, 본인은 모든 등산과 하산을 계획했던 경로로 잘 마쳤다.
정리하자면, 청계산 정상까지 올라가는 차도는 앞부분은 기슭의 군부대 때문에 막혀 있지만, 정상 인근의 군부대가 다시 등장할 때까지 그 사이 구간은 등산객도 이용할 수 있는 것 같다.

서울 시내 구간만 이용할 때는 청계산에 군부대가 있다는 생각은 별로 안 들었는데(단지, 1982년의 C-123 수송기 추락 사고로 순직한 특전사 장병에 대한 위령비만 있을 뿐), 이렇게 남쪽의 그린벨트 지대를 차로 답사하고 군사 시설 위주로 청계산의 진짜 정상도 구경하고, 계곡도 구경하는 등 굉장히 큰 성과를 올렸다. 즐거운 시간이었다.

Posted by 사무엘

1. 주 UI 스레드와 배경 작업 스레드

대화상자를 텅 빈 깡통 상태로 일단 띄워 놓은 뒤, 시간이 좀 오래 걸릴 수 있는 초기화 작업을 백그라운드에서 하고서 그게 끝나면 작업 결과를 대화상자의 각종 컨트롤에다가 반영하고 표시하기..
본인은 이런 형태로 동작하는 GUI를 구현한 적이 있었다. 리스트/콤보 박스에 들어갈 아이템들을 파일을 탐색하면서 수집하는 것이 대표적인 예이며, 당장 날개셋 한글 입력기 프로그램에도 이렇게 동작하는 UI가 한두 군데 있다.

그런데 그 백그라운드 작업이 언제나 수행되는 건 아니고, 조건에 따라서는 전혀 해당사항이 없는 경우도 있었다. 이때는 작업 결과의 표시와 관계가 있는 컨트롤들은 그냥 숨기거나 disable 시켜 놓으면 됐다.

그러니, 그런 컨트롤은 괜히 만들었다가 도로 숨기는 게 아니라, 스레드 함수가 자기 작업이 다 끝나고 마지막 부분에서 대화상자에다가 동적으로 생성하게 로직을 고치는 게 어떨까 생각을 했는데... 그렇게 하다가 더 피봤다.
당연한 말이지만 특정 스레드가 생성한 윈도우는 그 스레드의 실행이 끝남과 동시에 소멸되기 때문이다. 머리에 나사가 하나 빠지기라도 했는지 왜 그걸 생각을 못 했나 순간 "아차~!" 했다.

컨트롤 자체는 주 UI 스레드에서 미리 만들어 놓은 뒤, 백그라운드 작업 스레드에서는 그걸 ShowWindow / EnableWindow 정도의 제어만 할 수 있다. 컨트롤을 굳이 조건부로 동적 생성하고 싶다면, 백그라운드에서는 주 UI로 하여금 컨트롤을 생성하라고 메시지나 타이머 요청 정도를 보내는 간접적인 방법만 사용 가능할 것이다.

이렇게 윈도우의 생명 주기는 스레드와 관계 있는 반면, 접근 가능한 윈도우 클래스의 범위는 드물게 스레드가 아니라 RegisterClass를 호출한 모듈과 관계가 있다. 한 프로세스 안의 모든 모듈에서 접근 가능한 윈도우 클래스를 구현하려면 클래스 스타일에 CS_GLOBALCLASS를 지정해 줘야 한다. CreateWindowEx 함수는 현 스레드의 함수 호출 스택을 추적해서 자신을 호출한 모듈이 무엇인지를 따지기라도 하는가 보다. (인자로 받은 HINSTANCE 값은 무시하고 사용하지 않음.)

Windows 말고 안드로이드 프로그래밍을 해 보니 거기서는(Java)는 네트워크 통신은 무조건 백그라운드 스레드에서만 가능하고, 각종 GUI 요소의 조작은 반대로 주 스레드에서만 가능하게 해 놓았다. 이 규칙을 어기면 바로 예외가 발생한다. 그래서 Windows에서와 같은 혼동이 발생할 일이 없게 해 놨지만.. 간단한 통신 결과가 왔을 때 이를 GUI에다 표시하는 걸 한 함수에서 바로 못 하고 매번 스레드에, 메시지+핸들러로 실행 주체를 분리해야 하는 게 좀 번거로웠다.

2. 스레드의 강제 종료와 스택 상태

프로세스가 종료되는 가장 무난하고 좋은 방법은 main / WinMain 함수가 실행이 끝나서 자연스럽게 return하는 것이다. 그와 마찬가지로 스레드가 종료되는 가장 무난하고 좋은 방법 역시 해당 스레드 함수가 실행이 끝나서 자연스럽게 return하는 것이다.
하지만 Windows API에는 Exit...내지 Terminate...로 시작하는 프로세스· 스레드 종료 함수가 따로 있다.

두 단어 모두 뜻은 비슷하나, 전자는 자동사이고 후자는 목적어를 받는 타동사이다. 이로부터 유추할 수 있듯, 전자는 그 함수를 호출하는 자신을 종료하고 후자는 임의의 다른 프로세스나 스레드를 강제 종료시킨다.
어떤 프로세스가 이런 함수에 의해 종료되면 그 프로세스 하에서 돌아가던 모든 스레드들은 강제 셧다운된다. 그리고 반대로, 어떤 프로세스에서 모든 스레드들이 종료되어서 돌아가는 스레드가 하나도 없는 지경이 되면 빈 껍데기 프로세스는 자동 종료되고 소멸된다.

main 함수의 실행만 끝나면 자동으로 주변 잔여 스레드들의 실행도 강제로 다 끝나는 것 같지만 원래부터 그렇지는 않다. main을 호출한 하단의 C 런타임 라이브러리가 내부적으로 ExitProcess를 호출하기 때문에 그렇게 되는 것일 뿐이다. 운영체제 차원에서는 모든 스레드들의 실행이 끝나야 프로세스가 종료된다.

어쨌든, 프로세스나 스레드 같은 실행 주체는 자기 스스로 곱게 종료하는 게 좋다. 강제 종료 대상인 프로세스나 스레드는 자신이 강제 종료 당한다는 어떤 통지도 받지 못하며 이를 회피· 거부할 수도 없다. 뭐, 강제 종료를 막는 방법 뒷구멍이 있다면 악성 코드가 이를 마음껏 오· 남용, 악용할 것이니 저건 불가피한 면모도 있다. 강제 종료를 요청하는 프로세스가 적절한 권한만 갖고 있다면 강제 종료 작업 자체는 성공이 반드시 보장된다.

강제 종료는 파일이나 메모리, 스레드 동기화 오브젝트를 포함해 해당 스레드가 할당하고 선점해 놓은 그 어떤 자원도 제대로 수습· 회수하지 않은 채 말 그대로 해당 실행 주제만 없앤다. 그러니 엄청난 리소스 누수를 야기한다. 그나마 프로세스는 독립성이 높은 실행 단위인 덕분에 강제 종료되더라도 자기가 사용하던 모든 자원들이 자동으로 반납되는 게 보장이라도 되는 반면, 스레드는 그렇지 않다.

그렇기 때문에 TerminateThread는 TerminateProcess보다도 가능한 한 더욱 사용하지 말아야 한다.
I/O 관련 병목이나 데드락 같은 게 걸려서 해당 스레드의 코드 자체가 전혀 돌아가지 않을 때.. 옛날 같았으면 컴퓨터 리셋을 했을 피치 못할 상황에서나 극도로 제한적으로 사용해야 한다. 자기 스스로 실행 가능한 스레드라면 외부에서는 중단· 종료 플래그만 걸어 주고, 그 스레드가 알아서 실행이 종료되게 하는 것이 절대적으로 바람직하다.

그렇기 때문에 작업 관리자 같은 유틸에서 응용 프로그램을 강제 종료하는 기능은 일단 그 프로그램의 주 윈도우에다 WM_CLOSE만 살짝 보내 보고, 그 프로그램이 거기에 불응하면 API 차원의 극약 처분을 내리는 식으로 동작한다. 기왕이면 주먹보다는 말로 곱게 해결하는 게 좋으니까...

스레드가 강제 종료된 경우, 코드 실행 차원에서 발생하는 리소스 leak이야 어쩔 수 없는 귀결이다. 그런데 Windows는 전통적으로 exit 말고 terminate로 강제 종료된 스레드에 대해서는 그 스레드가 사용하던 스택에 속하는 메모리 주소도 해제· 재사용하지 않고 내버려 뒀다. 그러니 heap이 아닌 stack에 속하는 메모리가 leak이 발생하게 됐다.

이것은 스레드가 강제 종료되더라도 그 스레드의 스택에 속하는 메모리를 참조하던 다른 스레드가 뻗지 않게 하려고 성능보다는 안전을 고려해서 시행한 정책이었다. 어차피 TerminateThread를 할 정도이면 온갖 리소스들이 누출되었을 가능성이 높고 이왕 버린 몸에 비정상적인 상황이니 스택도 해제하지 않고 일부러 놔뒀던가 보다.
그러나 이 정책이 Windows Vista부터는 바뀌어서 이제는 terminate된 스레드의 스택도 곧장 해제된다. 흥미로운 점이다.

3. 열악하던 시절에 동시작업 구현하기

CPU 차원에서의 멀티스레드라는 게 없던 시절에 UI와 백그라운드 작업이 동시에 돌아가는 프로그램을 짜는 건 상당한 고역이었다.
옛날에는 컴퓨터 하드웨어 차원에서 관리되는 키보드 버퍼라는 게 있었다. 컴퓨터가 바빠서(busy) 정신없는 상태에서 사람이 키보드를 누르면 그게 일단 버퍼에 들어갔으며, 나중에 컴퓨터가 정신을 차리면 먼저 온 글쇠부터 밀린 처리를 했다. 일종의 queue 자료구조처럼 말이다.

이 키보드 버퍼는 크기가 15타 남짓밖에 안 됐다. 그러니 컴퓨터가 바쁜 상태에서 키보드를 조금만 많이 누르면 그 글쇠는 버퍼에조차 추가가 못 되고 컴퓨터가 시스템 전체를 잠시 멈추면서 높은 톤의 '삐~' 경고음을 냈다. "나 건드리지 마세요..!" 물론 ctrl, shift 같은 비문자 글쇠 말고 문자 글쇠들 한정으로. pause 키를 누르면 컴퓨터 전체의 실행을 일시정지 시킬 수 있던 시절의 얘기이다.

Windows 시대가 되면서 하드웨어와 소프트웨어 사이에 무슨 계층이 덧붙여졌는지, 컴퓨터에서 저런 걸 볼 일은 없어졌다. 하지만 9x 시절에는 운영체제가 대미지를 심하게 입고 반쯤 뻗어서 다운+재부팅 징조가 농후할 때면, 윈도우들이 메시지 큐가 다 차 버리고 메시지에 아무런 응답도 처리도 할 수 없는 상태가 되곤 했다. 이때는 그 윈도우로 마우스 포인터를 갖다대서 옮기기만 해도 짤막한 비프음이 났다. 이게 옛날에 키보드 버퍼가 다 차서 경고음이 나던 것과 같은 맥락의 현상이다.

옛날에 컴퓨터 속도가 왕창 느릴 때는 사용자가 화살표 키를 눌러서 화면을 스크롤 하던 도중에도 끊임없이 글쇠 입력 체크를 해야 했다. 그래서 화면 갱신 속도가 글쇠 연타 속도를 따라가지 못한다면 지금 갱신하던 것은 때려치우고 글쇠 처리부터 모두 한 뒤, 이로 인해 화면 위치가 바뀌었으면 스크롤을 처음부터 다시 하고, 변동 사항이 없으면 아까 하다 말았던 스크롤을 마저 계속하게 코딩을 했다.

오늘날은 단순히 2차원 스크롤을 위해서 저렇게 헝그리 코딩을 할 필요는 없을 것이다. 그러나 화면에다 아주 복잡한 3D 그래픽을 점진적으로 렌더링 하거나, 고해상도 만델브로트 집합 같은 프랙탈 그래픽을 실시간으로 그린다면.. 동일한 테크닉이 여전히 필요할 것이다.

CPU를 많이 소모하는 계산 위주의 작업 말고, 주변 기기와의 I/O 비중이 큰 작업도 생각해 보자. 워드 프로세서에서는 인쇄 중 동시작업(일명 스풀링), PC 통신 프로그램에서는 전화 연결 중에, 업· 다운로드 중에 동시작업.. 지금은 너무 당연해서 일도 아닌 게 옛날 도스 시절에는 해당 프로그램의 완전 첨단 고급 기능이라고 소개되곤 했지 않는가?

Windows는 여러 프로그램들을 동시에 띄워서 구조적으로 동시작업이 기능하다고 하지만, 16비트 시절엔 여건이 도스에 비해 막 좋을 건 없었다. 빡센 작업을 하는 중에도 여전히 사용자 반응성을 잃지 않으려면 message loop 차원에서 PeekMessage와 OnIdle 같은 로직이 추가돼야 하고, 작업 역시 UI의 반응성을 해치지 않을 정도로 연산을 짧게 끊어서 찔끔찔끔 해야 하는 건 변함없었다. 이런 정신없는 상태에서 트리 구조 순회나 순열 생성 같은 건 당연히 쌩 재귀호출로 구현할 수 없으며, 사용자 스택 자체 구현이 필수였다.

더구나 이런 idle time processing은 내가 아닌 Windows 내부의 고유한 message loop 하에서 구동되는 modal 대화상자 내지 메뉴 표시 중에는 중단된다는 문제가 있다. 타이머 메시지는 저렇게 modality와 관련된 끊김 현상은 없지만, CPU를 활용하는 효율이 일반적인 idle time processing 메커니즘에 비해 좋지 못하다.

이런 걸 생각하면 멀티스레드가 없었으면 지금처럼 사용자가 입력하는 텍스트의 맞춤법을 실시간으로 검사해서 빨간줄을 그어 주는 기능, C++ 같은 문맥 의존적인 언어 코드를 사용자가 입력하는 걸 인클루드 파트까지 실시간으로 구문 분석해서 자동 완성과 syntax coloring을 구현하는 건 불가능에 가깝게 힘든 일이 될 수밖에 없을 것이다.

4. 파이버: 스레드의 변종

사실, time slicing을 운영체제가 자기 재량껏 하는 게 아니라 내가 원할 때 하도록 thread의 변종인 fiber라는 게 있다. Windows의 경우, 일단 자기 자신을 일반 스레드에서 fiber로 먼저 변환해서(ConvertThreadToFiber) 초기화를 한 뒤, 다른 파이버들을 생성하고(CreateFiber), 파이버들끼리 필요한 타이밍 때 서로 전환(SwitchToFiber)을 하면서 열심히 제 할 일을 하면 된다.

이 경우 스레드 동기화 같은 건 전혀 필요하지 않으며, 멀티스레딩을 표방하면서도 프로그래밍 패러다임은 멀티스레드 성향이 전혀 아니게 된다. 사실, 이건 유닉스 기반의 서버 프로그램의 포팅을 돕기 위해 일부러 도입된 기능이지 실용적으로 딱히 쓰일 일도 없다. 하지만 복잡한 재귀호출이 여러 곳에서 동시다발적으로 일어날 때 자기 스택 상태를 고스란히 보존하면서 작업 context들을 원하는 때에 전환할 수 있다는 점에서는 뭔가 독특한 용도가 있을 것 같기도 하다.

개인적으로 thread가 원래 실타래라는 뜻이니, 컴퓨터 용어로서 thread는 '일타래'라고 번역해서 쓰면 꽤 그럴싸하겠다고 생각해 왔다. 서로 꼬일 수 있는 것까지도 동일한 개념이니까. 그런데 thread의 변종으로서 아예 '섬유'라는 뜻인 fiber는 우리말로 어찌 번역해야 할지 모르겠다. 우리말 순화· 번역이라는 게 이런 추가적인 조어력과 확장성까지 갖추지는 못하는 편이니 대부분 실패하곤 한다.

오늘날 운영체제에서 module이라는 건 EXE, DLL 등 실행 가능한 코드와 데이터, 리소스가 담긴 한 이미지 파일을 식별하는 개념이다. process는 자신만의 독립된 주소 공간을 가진 실행 공간으로, EXE만이 새로 생성할 수 있다. thread는 한 process 안에서 하나 이상 존재할 수 있는 실행 주체이다.
이들에 비해 instance, task는 좀 16비트스러운 용어이다. 32비트 이상부터는 프로세스들이 기본적으로 자기 주소에서 다 혼자 따로 노는 형태이기 때문에 한 모듈(HMODULE)의 여러 instance (HINSTANCE)라는 개념 구분이 별 의미가 없어져 있다.

운영체제에 따라서는 여러 개의 프로세스도 parent/child 관계를 맺고 job이라는 집단을 형성할 수 있다. Windows도 이를 API 상으로 흉내는 내는 걸 지원하지만 막 널리 쓰이지는 않는다. 마치 C가 함수 안에 함수를 공식적으로 지원하지 않는 것처럼(람다 내지 지역 클래스 같은 편법 말고..), 프로세스들도 굳이 계층 구조가 존재하지 않더라도 뭔가 심각하게 불편하거나 불가능해지는 건 없기 때문으로 보인다.

Posted by 사무엘

자동차의 덩치를 소형· 중형· 대형으로 분류할 때 이 등급은 탈 수 있는 인원수에 따른 절대적인 기준일 수도 있고, 승용차나 버스 같은 동일한 형태의 차량 중에서 상대적인 기준일 수도 있다.
예를 들어, 똑같이 5명이 타는 "소형" 승용차이더라도 모닝이나 레이 같은 경차는 소형차요, 아반떼는 준중형, 쏘나타는 중형이다. 그리고 그랜저 정도 되면 준대형이고 제네시스는 소형차 중에서는 대형이다. 하지만 제네시스라고 해서 같은 거리를 가는데 고속도로 통행료가 아반떼보다 더 비싸지는 않다. (경차는 별도의 혜택이 있는 차급이니 논외로 하고.)

승용차는 '스마트 포투' 같은 극단적으로 작은 차를 제외하면 경차라도 일단 4~5인승이다. 왜건· 해치백형 SUV 내지 밴 차량은 맨 뒤의 공간에다 좌석을 추가로 달면 9명 정도가 탈 수 있다. 뒷문은 여닫이가 아닌 미닫이(슬라이딩 도어)가 장착되기도 하며, 승용인지 승합인지 솔직히 좀 알쏭달쏭해진다. 아래의 차는 기아 카니발이다.

그 다음으로 일명 봉고차라고 불리는 승합차는 일단은 좌석이 네 줄 있어서 최대 12명이 타는 게 표준이다. 하지만 세 줄만 있어서 9명이 타는 물건도 있고, 또 과거에 아시아 자동차에서 만들었던 '토픽'이라는 승합차는 이례적으로 줄이 하나 더 있어서 15명이 탈 수 있었다. 참고로 15인승이 1종 보통 면허로 운전할 수 있는 차량의 인원수 한계이다.

이렇게 5인승 승용차보다 사람이 약간 더 많이 탈 수 있는 차량은 자그마한 학원이나 교회에서 수송용으로 운용하기 좋은 물건이다. 그리고 9인승 이상의 차에 6명 이상이 탑승했다면 경부 고속도로에서 버스 전용 차선을 이용할 수 있다.
남산 터널은 승용차라도 3인 이상만 타면 혼잡 통행료가 면제되고, 서울 시내의 중앙 버스 전용 차선은 일단은 오로지 정규 노선 버스 같은 영업용 차량만 이용할 수 있기 때문에 규정이 서로 조금씩 차이가 있다.

승합차보다 더 큰 차가 필요하다면 이제 미니버스 또는 마이크로버스라고 불리는 물건을 살펴볼 차례이다. 버스 중에서는 소형이지만 차량 전체의 덩치 랭크에서는 중형차 급에 속한다.
얘는 이제 한 줄에 좌석이 3개에서 4개로 늘어나며, 차에서 키 170~180급인 성인이 일어서서 차내 복도를 돌아다닐 수 있다. 작고 좁은 좌석에 25명 정도가 탈 수 있으며, 객실 아래의 별도의 짐칸과, 운전석에서 스위치로 곧장 개폐 가능한 자동문도 이 차급에서 최초로 등장한다.

요런 버스는 대중교통에서는 주로 마을버스 형태로 다닌다. 현대 자동차의 브랜드명은 '카운티'이다.

하지만 얘는 오늘날의 대형 버스와 비교하면 여전히 전방엔진이며, 승객이 타는 문은 중문 하나만 존재한다는 차이가 있다. 옛날 버스의 구조와 더 비슷하다.
승합차와는 달리 미니버스부터는 뒷바퀴의 한 축에 타이어가 하나가 아니라 트럭처럼 두 개씩 연결되어 있다. (사실, 기아 자동차 봉고는 승합차 차급인데 1톤 트럭처럼 뒷바퀴가 둘씩으로 구성되어 있었음)

마이크로버스보다 한 단계 더 커진 버스는 35인승 중형 버스이다. 얘는 바퀴의 크기, 차량의 길이와 폭이 대형 버스보다 미묘하게 작다. 사실 마이크로버스와도 구분이 쉽지 않아 보일 정도다. 그래도 얘는 덩치만 살짝 작을 뿐 앞바퀴의 앞에 드디어 폴딩 도어가 달렸으며, 외형이 더 각이 졌고 후방엔진이기까지 하니, 버스로서 갖출 건 다 갖추고 있다. 전체 차급의 관점에서는 준대형 정도 된다.

이것과 다른 중형 버스도 있다. 시내버스 중에 폭과 타이어 크기는 대형 버스와 동일한데 길이만 오리지널 대형보다 약간 짧은 놈을 본 적이 있을 것이다. 하긴, 연세 대학교 셔틀버스도 요런 차종이 다닌다.

일반적인 '45인승'(4*10+5) 대형 버스는 이제 8톤 트럭과 얼추 비슷한 덩치가 되며, 한 줄에 좌석이 5개까지 배치 가능하다. 구체적인 스펙을 접하지는 못했지만 대형 고속버스· 관광버스는 대형 시내버스보다 크기나 엔진 출력이 좀 더 크다고 한다. 아래의 에어로시티를 보면, 위의 중형 버스인 그린시티와 길이가 어떻게 차이가 나는지를 알 수 있다

좌석을 일반이 아닌 우등 형태로 배치하면 '28인승'(3*8+4)이 되는데, 일부 시외버스는 좌석의 폭은 우등과 동일하지만 간격은 약간 조밀하게 해서 31인승을 구현하기도 했다.

45인승보다 더 큰 버스는 차축이 더 늘어나고 굴절 또는 2층 형태가 된다. 우리나라는 요 얼마 전부터 일부 경기도 광역버스에 2층 버스가 도입된 정도이지 차내에 화장실이 있거나, 운전사가 두 명 타서 정기적으로 교대 근무를 하거나(짐칸 옆에 교대 운전자용 간이침실이..), 엔진룸이 차체 앞에 달린 경우는 없다. 제일 큰 이유는 물론 국토가 그 정도로 장거리 운행 최적화 디자인이 필요할 정도로 크고 아름답지 않기 때문이다.

오히려 우리나라에 고속도로가 처음으로 생겼던 1970년대에는 미국의 유명한 버스 회사인 그레이하운드 사가 국내에도 진출했으며, 그때는 미국 스타일의 차축 3개 + 일부 2층에 화장실까지 달린 버스가 잠시 다니긴 했다. 비행기로 치면 팬암 사가 한국에 진출해서 광고를 내던 시절 같다.

그러다가 그 회사가 한국에서 철수하고, 버스 안에 굳이 화장실을 설치하느니 그냥 휴게소에 정차하면 되고, 도로의 상태와 차량의 성능도 향상되면서 흑역사가 된 것이다. 철도에서 야간 열차가 갈수록 없어지고, 침대차가 정규 운행 노선에서 퇴출된 것과 동일한 이치이다.

단, 에버랜드에서 정문과 주차장 사이를 오가는 셔틀버스는 참 인상적이다. 차축이 3개이며 전문 중문 후문이 다 존재하여 거의 굴절 버스에 맞먹는 덩치이지만, 그렇다고 중간에 굴절이 있지는 않다.

에버랜드 셔틀버스는 덩치가 너무 커서 우리나라 현행법상 일반 도로를 주행할 수 없는 차량이라고 한다. 차량으로 등록할 수가 없어서 법적으로는 '놀이기구'로 등록했으며, 번호판 자리에는 '구내운송용'이라는 팻말이 달려 있다. 이 버스들은 주차장과 정문 사이의 셔틀버스 전용 도로만 오가며, 일반 도로에서는 일체 주행하지 않는다.

역시 삼성빨로 이런 특이한 차량도 들여올 수 있었나 하는 생각이 들었다.
하긴, 공항 활주로에서 비행기와 여객 터미널 사이를 오가는 단거리 셔틀버스도 저렇게 성격과 용도가 특이한 차량이며, 인천 공항은 장기 주차장과 여객 터미널을 오가는 무료 셔틀버스가 다니기도 한다. 주차장과 본 건물 사이에 버스가 다닐 정도로 거대한 시설은 인천 공항과 에버랜드 말고 국내에 또 있는지 궁금하다.

한편, 버스와는 달리 트럭은 대형 버스보다 작은 차종에도 추가적인 차축이 달린 게 많다. 특히 4~5톤급 중형 트럭에서 들었다 놓았다 하는 가변 차축의 형태로 말이다. 이렇게 차축이 더 달리면 4.5톤 덩치의 트럭에다가도 한 8톤 정도는 그냥 실을 수 있다.
이런 식으로 짐을 왕창 실으면 축중 하중이 여러 개로 분담되는 덕분에 도로 파손이라는 관점에서의 과적 단속에는 안 걸릴 수 있다. 하지만 엔진 출력과 브레이크는 여전히 4.5톤 기준이기 때문에 차량이 무리를 받는 건 어쩔 수 없다.

* 추가 설명: 자동문

버스에 존재하는 자동문은 시내버스에서 안내양을 퇴출시키는 데 큰 기여를 한 물건이다. 얘는 사람의 힘으로 여닫는 승용차 문들과는 달리, 뭔가 철컥 걸린 채로 꼭 닫아야 한다는 단서가 없다. 차를 타면 일반적으로 "문이 완전히 안 닫혀서 도어 경고등이 여전히 켜져 있으니 다시 똑바로 닫으세요" 이걸 신경 써야 하지만, 자동문은 그렇지 않다는 것이다. 문과 차체의 부품이 기계적으로 연결되고 걸린 것에 의존하지 않고, 공기압 같은 외력에 의해 문이 닫힌 상태가 계속 유지되고 있기 때문이다.

이런 '걸림' 구조(충분히 세게 꽝 닫아야 하는 것)랑 '자동문' 메커니즘이 꼭 일대일 동치 관계인 것은 아니다. 자동문이야 자체적인 동력으로 문을 붙잡고 있는 게 '걸림' 구조와 연동하는 것보다 더 쉬우니까 일반적으로 걸림 구조를 채택하지 않는 것일 뿐이다.
그렇기 때문에 에쿠스 내지 오늘날의 EQ900 같은 호화 고급차는 트렁크 정도에는 자동 개폐 장치가 달려 있다. 롤스로이스는 승용차이지만 아예 출입문도 자동 개폐 가능하다.

그리고 소형 승합차는 원래는 자동문이 없지만 3rd-party 업체에서 만든 자동문 시스템이 추가 장착되기도 한다. 옛날에, 대략 10년쯤 전에 1시간 간격으로 대전 지하철 월평 역에서 출발하던 KAIST 행 셔틀버스가 그랬다.
봉고차 크기이지만 좌석은 마치 우등 고속 좌석처럼 1인석 위주로 띄엄띄엄 리모델링하고, 운전사가 일괄적으로 문을 개폐할 수 있게 자동문 장치를 달아 놓은 형태였다. (직접 보지는 못했지만 지금은 25인승 미니버스로 차의 크기가 업그레이드 된 모양이다.)

* 잡설: 버스와 지하철의 차이

대중교통으로서 지하철에는 없고 버스에만 있는 것 중 하나는 바로 라디오 방송이지 싶다. 사용자 경험 측면에서 굉장히 큰 차이가 아닐 수 없다.
"잠깐만~! 우리 이제 한번 해 봐요 사랑을 나눠요.." 이런 CM송으로 끝나는 무슨 공익광고? 미담 사례 방송은 25년쯤 전에 나 초딩 때도 들었던 것인데 지금도 똑같이 흘러나오는 걸 우연히 들었다. 옛날에는 "기아자동차 협찬" 이러던데.. 물론 그건 IMF 이전의 정말 옛날 얘기이다.

한편, 지하철에는 버스에는 없는 잡상인이 종종 등장한다. 그리고 문 곁에 서 있는 사람 때문에 승하차 무질서가 야기되는 편이다.
이건 자동차로 치면 횡단보도나 교차로 근처에 불법주차된 차들 때문에 차량 통행이 불편해지고 사고의 위험이 증가하는 것과 같다. 이들 때문에 하차 승객이 나가기 어려우며, 심지어 동일한 문에서 승차와 하차가 동시에 진행(!)되면서 문의 양쪽에 서 있던 승객이 공평하게 승차하지 못하게 된다. 이 말인즉슨, 둘 중 한쪽은 좌석에 앉을 가능성을 공평하게 얻지 못한다.

이런 지하철과 달리, 버스는 예측 가능한 정해진 위치에 정차하지 않는 게 문제이다(대로변에 버스 여러 대가 동시에 많이 들어오는 정류장 기준). 이 때문에 미리 줄을 서서 기다리기가 어려우며 더 큰 무질서가 야기된다.

Posted by 사무엘

1. 미혼과 기혼의 차이

미혼자와 기혼자의 처지 차이는 자동차에다 비유하면 이렇게 설명할 수 있을 것 같다.
미혼자는 처자식이 딸린 게 없기 때문에 매우 자유롭고 경제적인 부담이 덜하다. 이것은 자동차가 엔진이 돌아가지만 기어가 중립이어서 힘이 바퀴에 걸리지 않은 상태와 같다.
이 상태에서는 가속 페달을 정말 조금만 밟아도 '웽~~!!' 소리와 함께 엔진 회전수가 치솟는다. 그러나 페달에서 발을 떼는 순간 엔진 회전수 역시 곧장 곤두박질치면서 다시 공회전 상태로 돌아온다.

기혼자는 기어가 D로 들어가서 엔진의 힘이 바퀴에 전해지고 자동차가 앞으로 나아가는 것과 같다. 엔진이 굉장한 부하를 받고 있는 관계로, 액셀을 같은 강도로 밟으면 중립일 때보다는 엔진 회전수가 훨씬 더 더디게 증가한다.
그러나 이제는 엔진만 바퀴를 굴리는 게 아니라 바퀴가 굴러가는 관성도 엔진의 회전을 어느 정도 유지시켜 준다. 그렇기 때문에 주행 중에는 액셀에서 발을 떼더라도 엔진 rpm이 바로 곤두박질치지 않고 있다가 아주 서서히(평지 기준) 감소한다.

이 차이가 사람의 인생에서 무엇을 의미하는지 감을 잡을 수 있을 것이다.
그리고 자동차가 실제로 굴러가서 일을 하고 자동차의 존재 목적을 실제로 수행하려면 결국은 N에만 머물러 있는 게 아니라 D에서 주행을 하긴 해야 할 것이다.

교회에서도 홀몸인 2, 30대 청년일 때야 체력과 지능이 최고 뛰어난 시절이고, 직장 다니면서 돈도 벌 테니 얼마든지 교회 일을 별 부담 없이 수행할 수 있다. 하지만 그건 제풀에 꺾이기도 쉽다. 이것은 마치 N 상태에서 액셀 페달을 밟았다가 떼는 것과 같다.

그 성경적인 사고방식이 자기 평생을 함께할 배우자를 고를 때에도 동일하게 작용하고, 결혼과 가정이라는 어마어마한 부담이 지워진 뒤에도 변함없이 교회를 섬길 수 있을 때에야 그 신앙심이 진정 레알이라는 것을 입증할 수 있을 것이다. 그리고 배우자를 잘 만났다면 자신의 영적 상태를 배우자가 같이 돕고 유지시켜 주기도 할 것이다. 바퀴도 엔진을 퓨얼컷 상태에서 자연스럽게 회전시켜 주는 것처럼 말이다. 뭐 운전하면서 갑자기 이런 생각이 들었다.

자동차의 엔진에 가해지는 부하의 강도는 위에서 아래로 갈수록 커진다.

1. 애초에 엔진이 바퀴와 연결되지도 않은 채(기어 중립) 그냥 엔진 혼자 도는 것 (아무 부하 없음)
2. 엔진과 바퀴가 연결은 됐지만 차체가 공중에 들려서 바퀴가 혼자 도는 것 (구동축 자체의 무게 말고 다른 부하 전무)
3. 바퀴가 지면과 접촉하여 차체를 지탱하면서 돌지만, 바퀴와 닿아 있는 지면의 궤도만 돌아가고 차체 자체는 움직이지 않는 것 (그러면 바퀴가 아무리 고속으로 돌아도 공기 저항 받는 게 없음)
4. 바퀴가 굴러가면서 차체가 그대로 움직이는 것 (실제 주행. 부하가 가장 큼)

2. 남이 올려 줘야 올라갈 수 있음

자동차의 원리를 통해서 알 수 있는 인생의 원리는..
먼저 저단에서 엔진이 열심히 돌아서 rpm이 웽~~ 올라가야 더 높은 단으로 변속이 되고 차가 속도를 계속 낼 수 있다.
"쳇 겨우 1단? 쒜빠지게 몇천 rpm으로 돌아 봐야 시속 30도 채 못 낼 텐데 왜 돌아?" 이런 마인드로는 차가 결코 제대로 달릴 수가 없다.

사람은 모름지기 낮은 지위, 덜 중요하고 남이 안 알아주는 위치에 있을 때부터 자기 직분에 신실하고 성실해야 한다. 그래야 점차 더 화려하고 중요한 자리로 올라가고 책임감 큰 직분이 주어지고, 연봉도 덩달아 뛰게 된다.

남이 당신에게 보상을 주는 게 먼저가 아니라, 당신이 노오력하고 애쓰는 게 먼저다. 이것은 성경에도 거듭해서 등장하는 철칙 중의 철칙이다(눅 19:17, 눅 16:10, 눅 14:10, 마 25:23). 가령, 박봉 탓을 하기에 앞서 자기가 먼저 자기 월급보다 회사에 더 기여해야 한다.
상식적으로 당신이 무슨 기업의 경영자라든가 높은 사람 자리에 있어 봐도.. 누구한테 중요한 일을 맡기고, 누구에게 기업 기밀과 핵심 기술을 알려주고 궁극적으로 기업의 후계자로 삼고 싶겠는가? 답이 뻔한 노릇이다.

물론, 예외 없는 규칙 없다고, 이 악한 세상에서 당신의 노력이 반드시 금방 인정받고 보상으로 돌아온다는 된다는 법은 없다.
성실한 근로자를 호구로 삼아서 열정페이 착취를 일삼는 악덕업주가 없다는 얘기는 아니다. 좌익들도 맨~날 이런 극단적인 예외 사례만 부각시키면서 반정부 반기업 선동을 벌인다.
허나 그건 법대로 처분하고 통계상의 outlier 상으로 생각할 문제이지 세상 전체에는 아직도 자기 월급보다 직원 월급을 더 생각하는 선량한 기업주가 더 많다.

이것이 인생이다.

3. 참교육

성경에 나오는 '참교육'이란 이런 거다.

"기드온이 이르되, 이런 까닭에 {주}께서 세바와 살문나를 내 손에 넘겨주신 뒤에 내가 '들가시와 찔레'로 너희 살을 찢으리라, 하더라." (삿 8:7)

그 뒤... 그런데 그것이 실제로 일어났습니다. 기드온은..

"그 도시의 장로들을 붙잡은 뒤 '들가시와 찔레'를 취하여 그것들로 숙곳 사람들을 가르치고" (삿 8:16)

기드온은 어렵고 위급할 때 자기를 무시하고 깔봤던 사람들을 예고했던 대로 그대로 되갚아 줬다.
타 성경들은 그냥 분위기 대로 응징, 징벌했다, punish, 방법(...!)했다.. 이런 식으로 번역했지만, 킹 제임스 성경만은 저걸 '가르쳤다' taught라고 번역했다.
기드온이 가시가 숭숭 박힌 식물 줄기를 폼으로만 들고 다니면서 무슨 강의를 했을 리는 만무하고 말 그대로 거기 사람들을 붙잡아서 자기가 말했던 대로 행했다.

"인생은 실전이야 이 존만아~" (퍽~퍽~)
"아 X발, 누구든지 작은 기드온을 건드리면 X되는구나, 아주 X되는 거구나.. ㅠㅠ"

그러니 당사자들은 이걸 가시에 찔리면서 피눈물을 흘리면서 깨우치게 됐고, 성경은 그걸 '가르쳤다/가르침을 받았다'라고 표현했으니 이 얼마나 흥미로운 일인가?
일진들을 참교육 시키는 걸로 유명한 천10호 천 종호 판사 아저씨의 호통 따위는 그냥 약과다.

똑같이 애를 두들겨 패도 사랑의 체벌과 아동 학대는 종이 한 장 차이이다.
똑같이 사람을 죽여도 누가 무슨 명분으로 죽이느냐에 따라 한쪽은 나라를 지키는 숭고한 행동이거나 사회 정의를 행하는 사형 집행인 반면, 다른 한쪽은 흉악 범죄인 것이다. 정말 똑같은 화학 작용인데 발효와 부패의 차이와도 같다고 봐야 할 듯하다.
그리고 이 사회는 필요악만 없애고 절대악은 그대로 방임하고 놔두는 지경으로 가고 있다. 인간이 하나님보다 자비· 자애로운양 코스프레 해서 인간에게 좋을 건 하나도 없다.

Posted by 사무엘

1. 어순의 차이

성경 용어만 해도 ‘그리스도 예수’랑 ‘예수 그리스도’는 용례와 의미가 서로 미묘하게 다르고 kingdom of heaven과 heavenly kingdom (딤후 4:18)은 다르다.
수학에서 '제곱근(=루트) 2'는 그냥 1.414...로 시작하는 양의 무리수 하나이지만, '2의 제곱근'은 말 그대로 방정식 x^2=2의 근을 모두 나타내므로 양수와 음수를 모두 포함한다.

그리고 프로그래밍 언어에서도 예전에 몇 번 언급한 적이 있었듯이, C++에서 new operator와 operator new는 다르다.
전자는 말 그대로 객체나 배열을 heap 메모리에 동적 생성할 때 사용하는 new 연산자 자체를 가리킨다. 그러나 두 단어의 순서를 바꿔서 ‘operator new’라고 하면, new 연산자가 메모리 할당을 위해 내부적으로 호출하는.. C로 치면 malloc 같은 함수를 가리키게 된다.
또한 function template이라고 하면 클래스 템플릿과 달리 함수 형태로 선언된 템플릿이고, template function은 그 템플릿에다가 템플릿 인자가 주어져서 실제 코드가 생성된 함수를 뜻한다.

이런 예가 언어학에도 있다. isolating language는 형태 구조상의 고립어를 말한다. 중국어 같은 언어. 영어도 이제 굴절이 하도 무뎌졌다 보니 이 정도면 많이 고립어처럼 된 거 아니냐는 얘기가 있다.
그 반면 language isolate는 계통 분류상으로 유사 언어를 현재로서는 도무지 찾을 수 없는 고립어, 언어계의 ‘은행나무’ 같은 특이한 유아독존 언어를 말한다.

그리고 한국어가 그런 유별난 위치를 차지하는 것에 우리 반도 사람들은 자부심을 갖도록 하자. =_=;; ‘우랄 알타이 어족/제어’처럼 한국어도 공통 조상이 있고 타 언어들과 같이 분류 가능할 거라는 가설은 현재로서는 근거 부족으로 인해 부정되고 있는 추세이니까.

물론, 일본어도 굉장히 유별나긴 하지만 걔들은 화자가 많고 여러 지역에 바리에이션이 있기 때문에 작게나마 자체적인 ‘어족/언어군’을 형성할 정도는 된다.
한국어는 그 정도까지 안 되지만 그래도 남한이 선진국 말석 정도는 차지하는 강소국이고, 다른 모든 소수 고립어 화자들을 합한 것보다 훨씬 더 많은 화자를 보유하고 있는 특이한 고립어이다.

끝으로, 우리나라 지명에도 어순 장난의 끝판왕이 대전에 있다. 서대전네거리역, 서대전역네거리, 서대전네거리..;;;가 모두 서로 다른 장소이고 버스 정류장 이름이기도 하다.

2. 고속버스 터미널

지금으로부터 1년 남짓 전인 2016년 8월경에 서울 강남 고속버스 터미널의 공식 명칭이 터미 “날”에서 “널”로 드디어 바뀌었다.
고속버스 타고 서울 올 때마다 굉장한 옛날 스타일의 간판 글씨체와 더불어 ‘날’이 참 압박스럽긴 했는데, 이제야 손을 봤나 보다.

그런데, 저기 말고 여전히 ‘날’이 활발히 쓰이는 곳이 있긴 하다. 바로 맥도 “날” 드.
원어 발음상으로는 둘 다 동일한 소리이다.
ㅓ와 ㅡ 사이의 미묘한 그 어눌한 중모음, 모음 삼각도에서 정중앙에 위치한 일명 ‘슈와’이다. 이마저도 워낙 약하게 발음되기 때문에 사전에 따라서는 이탤릭으로 표기하거나 아예 생략하기도 한다.

옛날에는 실제 발음은 상관없이 스펠링이 A니까 ‘날’이라고 적었던가 보다.
사실, 강남 고속버스 터미널이 처음 생겼던 1980년대는 컴퓨터조차도 ‘콤퓨타’ 이러던 시절이었다. 배터리 같은 것도 없고 ‘밧데리’가 있을 뿐이었지. 지금으로서는 ’-읍니다’ 만큼이나 굉장한 이질감이 느껴진다.

3. 어휘를 구성하는 글자

어떤 개념을 나타내는 두 글자짜리 한자어가 있는데, 그 개념을 더 실질적으로 가리키는 글자는 둘 중 무엇이냐 하는 문제가 있다.
예를 들어 원소 '유황'(sulfur). 흔히 '황'이라는 글자 자체가 저 원소를 가리킨다고 생각하기 쉽지만 그렇지 않다. '황'은 그냥 '노랑'이라는 뜻일 뿐으로, 동음이의어 변별을 위해 덤으로 붙은 말에 가깝다. 금을 '황금'이라고 수식해서 부르는 것처럼 말이다.

원래는 '황' 대신 앞의 '유'(硫)가 진짜 sulfur이라는 뜻이다. 그래서 H2SO4라는 용액도 옛날에는 '황산'이 아닌 '유산'이라고 불렀으나.. 지금은 '황'이 '유'를 완전히 대체한 상태이다. 다만, 유황은 황산이나 황금과 달리 황이 앞에 붙지 않았는지는(황유..!) 잘 모르겠다.

그리고 본인이 꽤 재미있는 예를 또 찾은 것은 '명령'(command, instruction)이다.
"어명이오~!" 할 때는 '명'에도 명령이라는 뜻이 있으며, 이는 국어사전에도 '준말'이라고 명시되어 있다. 그러나 실질적으로 명령의 뜻을 가진 것은 뒤의 '령'(令)이다. 법령, 시행령, 포고령 등..

"누가 기침소리를 내었는가?"로 유명한 태조 왕건 80회 장면을 보면.. 궁예의 명령대로 신하를 죽이는 '금대'라는 장수가 하는 말이 대본상으로는 "폐하의 명이시니라. 눈을 감아라"라고 되어 있다.
그러나 TV에 방영은 "폐하의 영이시니라."라고 말하는 것으로 나갔다. 흥미롭지 않은가?

command는 명령으로, instruction은 지령으로, direction은 지시 정도로 번역하면 되지 않을까 싶다. 다 어차피 일본식 한자어인지는 모르겠지만.
그런데 우리나라에서는 '지령'을 내리는 주체도 이상한 곳인 경우가 참 많다 보니 '동무, 인민'만큼이나 쓰기가 참 민망해져 가고 있다.

4. 며칠, 너머 등

우리말에는 '맞다'가 동사· 형용사 경계를 오락가락하는 것처럼.. 부사· 명사 경계를 오락가락하는 단어가 좀 있다. 대표적인 예는 '모두'이고, '서로'(상대방), '스스로'(자기 자신)도 좀 비스무리하다.
멀쩡한 부사 단어를 명사로 써서는 안 된다고 강경하게 주장하는 국어 운동가 내지 연구자도 있지만 썩 먹혀들지는 않고 있는 것 같다.

그런데 '넘다'라는 용언에 연결어미 '-어'가 붙은 활용형 '넘어'는 이게 통째로 명사로 쓰이기 때문에 사전에도 소리 나는 대로 풀어 쓴 '너머'가 등록되어 있다. "저 산 너머에는 뭐가 있을까?"
"저 강 건너에는 뭐가 있을까?"처럼 다른 유사 동사를 갖다붙여서는 말이 되지 않으니, '넘다'에만 저렇게 독특한 바리에이션이 있다고 본 것이다.

다들 사망과 관계가 있는 단어이긴 하다만, 무덤(묻다), 주검(죽다).. 그리고 '설거지'(설겆다)도 어원을 밝히지 않고 소리 나는 대로 적고 있다. '굳다', '붓다', '웃다', '눋다' 등 다른 단어들을 살펴봐도 '-엄'이 붙은 활용례를 도통 찾을 수가 없으니.. 저건 생산성을 상실한 죽은 단어라고 보기 때문이다.

이런 단어들을 그냥 소리 나는 대로 적는 것을 그냥 귀차니즘이나 맞춤법의 퇴화라고 꼭 부정적으로만 볼 필요는 없다. 단어는 언제까지나 합성어 형태로 남는 게 아니라 그 자체가 더 쪼개지지 않는 형태소인 것처럼 간소화도 돼 있어야 그게 또 다른 합성어의 부품으로도 쓰일 수 있고, 더 복잡한 개념을 나타내는 데 쓰일 수도 있기 때문이다.

머리카락, 킬로그램조차도 너무 복잡하다고 "머리 자른다", "20키로" 이러는 게 인간이다. '머리카락'이 '멀칼' 이런 식으로라도 굳어졌다면 굳이 "머리 자른다"라고 말할 필요가 없었을 것이다. 일본은 합성어를 '게센', '프레스테' 제멋대로 잘도 짜르는 걸로 유명하며, 영어권에서도 로봇은 그냥 bot으로, 애플리케이션은 app으로 잘만 짤라서 AppStore 같은 단어도 만들어서 쓴다.

띄어쓰기(한 번, 한번 같은..)와 저런 표기 방식(넘어, 너머)이 한글 맞춤법에서 참 어려운 떡밥인데..
'며칠'은 '몇 주, 몇 개월'과는 달리, 통념상 한 단어로 굳어진 듯하다는 이유로 붙여 쓴다. '큰코다치다'를 한 단어로 쓰는 것과 비슷한 맥락이다. 품사(너머)나 뉘앙스(한번) 같은 거 따질 필요 없이 '몇 일'을 쓸 것을 기계적으로 '며칠'이라고 대체한다고 생각하면 된다.

5. 사이시옷이 아닌 표기

한글에서 받침 ㅅ은 한국어의 사잇소리를 표기할 때, 그리고 외래어에서도 음절말 D, T 발음 같은 걸 적당히 표기할 때 굉장히 즐겨 쓰인다. 그런데 이런 관행에만 너무 익숙해지면, 단어의 최소한의 어원을 생각하지도 않고 ㄷ 받침 소리를 몽땅 ㅅ으로 잘못 표기하기 쉽다.

• '옛다'가 아니라 '옜다'가 맞다. 굉장히 의외이고 본인도 오랫동안 잘못 알고 있었다. 이 단어는 '예'(yes? old?)라는 형태소와는 전혀 관계 없이, 단순히 "여기 있다"의 준말이기 때문이다. ㅆ이 어색하게 느껴진다면 '있다'를 생각하면 된다. '옜'은 안 그럴 것 같지만 나름 KS X 1001 완성형에도 포함돼 있는 문자이다.
• '반짇고리'도 무슨 '반지+고리'의 합성어가 아니라 '바느질'이 줄어든 형태이기 때문에 ㅅ 받침이 쓰이지 않았다. '숟가락'이 '술+가락'의 축약· 합성어이기 때문에 '숫가락' 대신 '숟가락'으로 적는 것과 동일한 이치이다. 그나저나 반지와 고리.. 영어로 둘 다 ring인 게 흥미롭다.

6. 기타 표기

• 개인적으로 '소시지'가 맞는지 '소세지'가 맞는지 종종 헷갈리곤 했다. 최근에는 안 헷갈리는 노하우를 터득했는데, 그건 바로 '메세지'가 아니라 '메시지'라는 걸 떠올리면 된다는 것이다. 영어로는 똑같이 i 발음이다. 본인은 '메시지'는 혼동한 적이 없다.
• 영어로 된 흑인영가 찬송가를 하나 듣고 있었는데.. 웬 "길르앗에 폭탄?" 이게 무슨 말이지 도저히 이해되지 않아서 알아봤더니.. 아~ BOMB이 아니라 BALM이었다. '길르앗의 향유'는 성경에서 유명한 물건이다. (렘 8:22, 렘 46:11)
  발음은 [ba:m]으로 둘 다 동일한데, 각 단어가 제각기 B, L이라는 기괴한 묵음도 있고 철자가 이상하다.
  
• 그러고 보니 형용사화 접미사 -al이 붙은 영어 단어에서 끝의 L만 빼서 고유명사를 만든 예가 한국과 일본에 하나씩 있다. 기아 자동차 포텐샤(Potentia), 그리고 버추어(Virtua) 파이터. 어째 이런 것도 우연인가 싶다.

그리고, '브로더번드'라고 먼 옛날에 그 유명한 페르시아의 왕자 게임을 배급했고, 그것보다는 덜 알려졌지만 배너매니아(BannerMania)를 개발· 판매하기도 한 미국의 소프트웨어 회사가 있다. 지금도 회사가 살아는 있는 모양이다.
얘는 영문 표기가 Broderbund이다. 뭔가 '브라더'스러운데, 실제로 저 이름은 "band of brothers"에서 어순과 어감을 적당히 변조한 신조어라고 한다. (이거 무슨 SK 브로드밴드도 아니고..)

단, 더 정확한 공식 표기는 그냥 o가 아니라 사선이 쳐진 ø이다. 스펠링까지 미묘하게 이렇게 바꿨다. 하지만 현실에서는 컴퓨터 키보드로 치기 어렵거나 귀찮다는 이유로 그냥 o를 쓰기도 하며, 초창기엔 발음조차도 '로'냐 '루'냐 혼란이 있었다고 한다.

우리나라의 아래아한글은 공식 명칭 표기에 컴퓨터에서 입력하기 쉽지 않은 옛한글이 포함돼 있다. 그래서 편의상 '한글'이나 '한/글'이라고 이름을 표기하기도 했으며, 공식 명칭을 '혼글', 심지어 '훈글'이라고 읽는 사람도 있었다. 브로더번드의 경우 라틴 알파벳 문화권에서 딱 그런 현상을 보는 것 같다.

Posted by 사무엘

1. Windows 부팅

Windows 8 내지 10부터던가.. 요즘 Windows에서는 예전까지 오랫동안 쓰이던 통상적인 부팅 전 F8 메뉴가 사라졌다. 하긴, 메뉴가 여럿 있긴 했지만 고르는 건 안전 모드(F5) 또는 네트워크 되는 안전 모드 둘 중 하나밖에 없긴 했다.
그 대신, 부팅 후에 컴을 팩토리 리셋 초기화시키는 메뉴가 곧장 들어간 것은 일단 꽤 유용하며, F8을 눌러야 할 필요를 이걸로 상당수 대체하긴 했다.

하지만 뭐가 꼬여서 애초에 부팅이 안 되고 있을 때는 이 기능에 접근할 수 없어서 더 불편해졌다. 부팅 전의 OS 재설치 및 복구 UI는 사용자가 특정 글쇠를 눌렀을 때 바로 뜨는 게 아니라, 수차례 컴퓨터를 혹사시키면서 부팅이 실패한 것을 얘들이 인지했을 때에 그제서야 슬그머니 띄워 준다. 로직을 왜 이런 식으로 만들었나 모르겠다.

전에도 얘기했듯이, 본인은 업데이트를 받은 뒤에 운영체제가 꼬이고 커널 패닉 뜨는 걸 몇 번 겪은 뒤부터는 진절머리가 나서 업데이트 받는 걸 레지스트리까지 조작해서 강제로 끊어 버렸다. 지금 네트워크는 유료 종량제이니 니 멋대로 함부로 업데이트 받아서 설치하지 말라고 말이다.

CPU와 메모리와 네트웍 트래픽 잡아먹고 하드디스크 용량 잡아먹고, 컴퓨터를 꺼야 할 때 바로 곧이곧대로 꺼지질 않고.. 민폐가 너무 심한 데다, 그런 민폐가 시도 때도 없이 너무 자주 발생하고.. 설치 후에도 뭐가 크게 달라지고 좋아지기는커녕 저런 부작용만 있으니 이 상황에서 누가 업데이트 꼬박꼬박 받고 싶은 마음이 들겠는가?

그거 안 하고도 내 컴은 악성 코드고 뭐고 지금까지 보안 문제 같은 건 하나도 없었다. 이러다가 업데이트에 대해서조차도 현대 서양 의학 불신, 백신 불신 같은 이상한 풍조가 생기지는 않으려나 모르겠다만.. 브라우저를 선택할 권리 운운하면서 웹 표준 외치는 것만큼이나, 필요하지 않은 업데이트를 안 받거나 원하는 타이밍에만 받을 권리도 좀 보장됐으면 좋겠다.

2. 바이오스

뭐, 이건 운영체제 얘기였고 그 전에 롬에 탑재된 컴퓨터 고유의 소프트웨어 계층을 일명 BIOS라고 부른다. 이것도 2010년대에 와서는 UEFI라는 새로운 규격으로 바뀌었다.
운영체제 부팅 전에 BIOS 셋업(CMOS 셋업이라고도 불렀던 듯..)을 들어가려면 ESC, F2, F10, Del 이런 글쇠를 죽어라고 누르곤 했는데, 이 글쇠도 좀 Ctrl+Alt+Del 재부팅처럼 통일이 됐으면 하는 생각이 든다. 바이오스는 어차피 만드는 업체도 피닉스나 아메리칸 메가트렌드 요렇게 아주 소수이지 않던가?

살면서 BIOS setup으로 들어가야 하는 상황은 몇 년에 한 번꼴로 운영체제 변경· 재설치를 위해 부팅 매체 선택 순서를 변경할 때.. 혹은 하이퍼-V 가상화 같은 옵션을 켜고 끌 때 정도이지 싶다. 살다가 병원이나 법원, 경찰서, 주민센터 같은 델 들르는 빈도와 비슷한 격이다.

옛날에는 컴퓨터를 켠 직후에 숫자가 쫘르륵 올라가면서 주 메모리 테스트를 하는 게 관행이었는데 그 광경도 참 오래 전에 사라졌다. 램의 용량이 수백 MB 수준으로 넘어간 시기, 대략 21세기 초쯤부터 없어진 것 같다. 글쎄, 카운트만 안 보여줄 뿐, 내부적으로 여전히 테스트는 하는 걸 수도 있음.

그리고 요즘 컴퓨터는 바이오스 셋업 화면도 텍스트가 아닌 그래픽 모드로 바뀌었고 마우스가 지원된다. 저기는 한글화의 영원한 불모지라고 여겨졌는데 이젠 그것도 아니다. 마소처럼 11172자 완성형 글립을 다 때려박은 게 아니라 이야기체 같은 8*4*4 조합형 비트맵 글꼴을 쓴 것도 있어 더욱 반갑다.

바이오스 차원에서 하드디스크에 predefined type이 40몇 가지 정도 있던 시절도 있었는데.. 안 변하는 것 같아도 이 바닥도 하드웨어의 발전을 따라서 많이 변하고 있다.
그나저나 애플 제조 컴퓨터들은 바이오스 계층도 자체 개발인 거겠지? (켠 직후에 흰 화면에 빵~~! 소리, 그리고 alt 눌러서 부트캠프 동작..)

3. 글꼴

수 년 전부터 개인적으로 '감지'는 했던 현상인데, 어떤 컴퓨터는 글꼴 대화상자를 열어 보면 황당하게도 Times New Roman이나 Courier New 같은 필수 기본 글꼴이 목록에서 빠져 있고 선택 가능하지 않았다. 물론 그 컴퓨터에 실제로는 해당 글꼴이 멀쩡하게 잘만 설치돼 있다.
게다가 더 황당하게도 MS Word 같은 프로그램에서는 그 글꼴을 선택할 수 있었고 메모장이나 워드패드에서만 안 나왔다. 내 경험상 이건 컴퓨터마다 케바케로 발생하는 듯하고 Windows 7 이상 2010년대부터 종종 보였다.

처음엔 글꼴 목록에 영향을 끼치는 악성 코드가 있기라도 한지 의심을 했다. 하지만 알고 보니 이 현상에 대한 해답이 따로 있었다.
"제어판-글꼴-글꼴 설정"으로 들어가서 "언어 설정에 따라 글꼴 숨기기" 옵션을 끄면 사라졌던 Times, Courier 같은 글꼴을 다시 선택할 수 있다. (Designed for your language settings)

Windows 7부터 등장한 옵션은 맞아 보인다. 그런데 멀쩡한 글꼴을 선택할 수 없게 만드는 옵션은 대관절 도대체 왜 도입됐는지 모르겠다. 그런 옵션을 굳이 넣을 거면 글꼴 선택 대화상자 내부에다가 넣거나 show all 같은 버튼이라도 넣어야지 왜 제어판 깊숙한 곳에다가 짱박아 놓았는지도 알 길이 없다.

4. PNG

한때 GIF라는 그림 파일 포맷이 있어서 웹에서 정말 많이 쓰였다. 압축률 좋고 투명색과 애니메이션, progressive 렌더링 같은 독보적인 장점 기능이 많았다. 그러나 GIF는 내부의 압축 알고리즘에 특허가 걸려 있어서 아무나 활용하기가 곤란했다.

물론 이미 만들어진 그림 파일을 보기만 하는 사용자 입장에서는 제약이 걸리는 게 전혀 없고, GIF 파일을 생성하거나 디코딩하는 프로그램을 상업용 제품에다 직접 얹는 제조사의 입장에서 로얄티 같은 게 들었던 것 같다. 휴대용 MP3이나 WMA 재생기를 만들 때처럼 말이다. 전자는 프라운호퍼 연구소에, 후자는 마소에 특허든 저작권이든 뭐든 걸려 있다.

그래도 이 특허는 저작권 자체의 보장 기간(70년)보다는 기간이 훨씬 짧았던 모양이다. 2005년경에 특허가 풀리긴 했다. 그러나 gif는 트루컬러를 지원하지 못한 채 256색에서 발전이 멈춰 버렸기 때문에, 오늘날은 대체제인 PNG에 밀려 서서히 사장되는 중이다. 웹에서 사진용 손실 압축은 JPG가, 그 밖의 범용적인 비손실 이미지는 PNG가 시장을 나란히 양분하는 중이다.

PNG는 GIF보다 압축률이 더 좋고 트루컬러도 지원하며, 단순 color key 기반 투명보다 더 발전한 알파채널도 지원한다. 심지어 고화질 아이콘을 저장하는 컨테이너로도 이용되고 있다.
그러니 GIF의 대체물이 되기에 손색이 없다. 다만, 알파 채널은 1990년대 PNG의 첫 버전과 동시에 등장한 게 아니라 나중에 추가된 확장 규격이기라도 한지, 제대로 지원하는 프로그램이 여전히 적어서 아쉽다.

또한 PNG도 애니메이션 기능은 없다. APNG라는 규격이 있기는 하지만 웹 표준이 아니기 때문에 파이어폭스 같은 극소수의 브라우저 말고는 지원하지 않는다. 플래시가 없어지고 브라우저 자체의 동영상 코덱 규격조차 표준화가 논의되고 있는 와중에 애니메이션용 이미지도 더 늦기 전에 표준이 마련되고 모든 브라우저들이 지원해 줘야 하지 않나 생각이 든다. 하긴 옛날에는 동영상도 코덱 파편화가 무진장 심해서 '통합 코덱' 이러면서 혼란이 말도 아니긴 했었다.

5. high DPI 관련

Windows에서 high DPI 지원 정책은 한번 만들어 놓은 걸로 끝이 아니고 버전을 거듭할수록 마개조를 거듭하고 있다. 심지어 같은 Windows 10에서도 새 업데이트에서는 새 기능이 들어갔다.

8.1에서인가 그때부터 per-monitor high DPI이라는 게 도입된 걸로도 모자라서 이제는 아예 스레드별로 high DPI-aware 여부를 지정하고 그걸 on-the-fly로 변경하는 기능까지 추가됐다.
DPI의 변경은 너무 파격적인 변화여서 원래는 재부팅이 필요했으며, Windows Vista 시절에는 믿어지지 않지만 관리자 권한까지 필요하던 작업이었다. 그리고 어차피 제대로 대비가 돼 있는 유연한 프로그램도 매우 드물기 때문에 변경이 권장되지 않기도 했다.

그랬는데 그게 그래픽 카드의 성능 발달 덕분에 실시간 변경이 가능한 기능으로 서서히 바뀌어 간다. 그래도 마소는 레거시 호환성에도 목숨을 거는 곳이니, DPI 변화의 대비가 안 돼 있는 레거시 프로그램은 그냥 가상화 샌드박스빨로 통째로 속이고 말이다. Windows의 역사상 동일 기능이 위상이 이렇게 드라마틱하게 변한 다른 예는 찾기 어려울 것이다.
원래 화면 해상도나 색깔수를 바꾸는 것조차 먼 옛날에 Windows 3.x 시절에는 재부팅이 필요한 작업이었지만 9x/NT부터는 실시간 변경이 가능해졌지 않던가? DPI 변경도 그렇게 바뀌었다.

그도 그럴 것이, high DPI라는 게 원래는 시력 나쁜 사람을 위한 장애인 접근성에 가까운 잉여 기능이었다. 하지만 21세기에 모니터의 해상도가 급격히 올라가면서 이건 모든 사람에게 필요한 편의 기능이 됐다.

이 점에서 high DPI는 마치 자동차의 자동 변속기와도 비슷한 구석이 있다. 원래 자동 변속기 전용 면허는 왼발용 페달, 오른손용 다기능 스위치, 시청각 장애인용 볼록 거울처럼 장애인의 운전을 위한 여러 면허 조건 중 하나였다. 자동 변속기가 운전하기가 훨씬 더 쉬우니 장애인에게도 더 유리하니까 말이다. 그랬는데 자동 변속기가 워낙 대중화되고 나니 자동 전용 면허만은 1997년부터 일반인도 취득 가능하게 바뀐 것이다.

원래 화면 확대 배율이 기본값인 동시에 최소값일 때의 DPI 값은 96이었다. 이건 사실상 하드코딩된 채 쓰여 온 값인데, 언제부턴가 Windows SDK 헤더 파일을 보니 요게 USER_DEFAULT_SCREEN_DPI 라는 상수 명칭으로 추가되었다. 마치 마우스 휠의 기준값인 WHEEL_DELTA (120)과 성격이 비슷해 보이는데, 아무튼 GetDeviceCaps(hDC, LOGPIXELSX)의 리턴값과 저 96의 비율을 계산하면 확대 배율을 얻을 수 있다.

그런데 Windows가 존재하는 한 LOGPIXELSX와 LOGPIXELSY의 값이 서로 달라질 일은 설마 없겠지..?
모니터가 일부러 종횡비가 더 큰 와이드 화면으로(4:3 → 16:9) 바뀐 와중에, 논리적인 화면 종횡비를 또 보정해야 하는 건 옛날 CGA 640*200이나 허큘리스 720*348 해상도 시절 이래로 이제 없으리라 여겨진다.

옛날에는 멀티 모니터조차 예견을 못 하고 WM_CONTEXTMENU 메시지에서 마우스 클릭이 아닌 키보드 글쇠는 x, y 좌표가 모두 -1인 것으로 구분하게 스펙을 설계한 적이 있었는데.. 그때와 지금은 참 격세지감이다.
또한, 해상도 차이가 많이 나는 모니터를 둘 이상 연결해서 사용할 때를 대비해서, 이제는 두 모니터가 DPI 설정이 서로 다른 것까지 다 지원해야 한다. 그러니 high DPI를 제대로 지원하는 일이 더욱 복잡해진 것이다.

6. 네트워크가 안 될 때

집에서는 이런 현상이 없는데 회사에서는 가끔씩 멀쩡히 랜선이 꽂혀 있는데도 유선 인터넷이 안 되는 경우가 있다. 이때는 ipconfig /renew를 해 주면 문제가 해결되는 편이다.
때로는 /release도 해야 하고, 한번은 '설정'(제어판 말고)으로 들어가서 네트워크 관련 메뉴 맨 아래의 '전면 초기화'+재부팅까지 한 뒤에야 문제가 해결된 적이 있었다. 그 당시에 무엇이 정확하게 문제였는지 나로서는 알 길이 없지만, 아마 공유기 쪽 문제인 듯하다.

7. USB 메모리 관련

USB 메모리를 꽂아 쓰다 보면.. 분명히 작업을 마쳤고 관련 프로그램들을 다 종료한 뒤, 메모리를 빼려고 하는데 안전하게 분리가 안 된다고 운영체제가 꼬장을 부려서 난감해지는 경우가 있다.
Windows 2000 시절에만 해도 USB 메모리를 무단으로 뽑으면 경고 메시지가 나왔지만, 그게 그렇게까지 위험하지는 않고 괜히 사용자를 불안하게 만들 필요는 없다고 판단되었는지 XP와 그 이후부터는 경고 메시지가 사라졌다. 그러나 그렇다고 해서 무단 분리가 전혀 위험하지 않다는 얘기는 아니다.

USB 메모리를 분리하는 명령은 시스템 트레이에만 있는 게 아니라 의외로 해당 드라이브의 셸 우클릭 메뉴에도 존재한다. 마치 CD롬 드라이브의 우클릭 메뉴에 '디스크 꺼내기' 명령이 있는 것처럼 USB 메모리 드라이브도 우클릭하면 'eject'가 있으며, 이 명령을 이용해서 분리하면 트레이 메뉴 명령보다 성공률도 더 높다고 그런다.

경험상 macOS는 지금까지 쓰면서 USB 메모리 제거가 바로 안 되는 경우를 거의 못 본 거 같다.
그런데 pkg 파일을 열어서 설치하는데.. USB 메모리의 것을 바로 여니까.. insert the "(null)" disc to continue installation 이러면서 설치가 제대로 되지 않았다.
저건 %s 포맷 문자열에다가 null 포인터를 주기라도 했는지 메시지의 형태도 비정상일 뿐만 아니라, 배포 패키지 파일이 깨지고 문제가 있을 때에나 나타날 법한 메시지이다.

하지만 파일이 실제로 깨진 건 전혀 아니었으며, pkg 파일을 하드디스크에다 복사한 뒤에 설치하니까 아무 문제 없이 됐다.
왜 저런 현상이 있는지는 잘 모르겠다.

8. USB가 없던 시절의 컴퓨터 단자

그러고 보니 먼 옛날에.. USB 포트가 없던 시절에는 컴퓨터에 주변기기를 인식시키는 용도로 직렬 포트와 병렬 포트라는 게 있었다.
정확하게 뭐가 직렬 내지 병렬이어서 이런 명칭이 붙었고 서로 어떤 장단점이 있는지 잘 모르겠다. 라디오에 AM과 FM, 인터넷 프로토콜에 TCP와 UDP처럼 일장일단이 있는 관계가 아닌가 생각된다.

직렬 포트는 COMn 이런 이름이 붙어서 주로 마우스나 모뎀이 연결되었다. 그리고 병렬 포트는 LPTn 이런 이름과 함께 프린터나 스캐너 같은 기기가 연결되었으며, 과거에 쓰이던 하드웨어 방식 불법 복사 방지 장치 '락'도 대체로 병렬 포트에다 꽂는 형태였던 것 같다.

으음.. 그럼 외장 하드는 어디에다 꽂았지? 옛날에 하드 디스크끼리 꽂아서 데이터를 복사하는 건 정말 아무나 할 수 있는 일이 아니었다.;;
꽂고 나서는 바이오스 설정을 들어가서 이게 무슨 기기인지 설정을 수동으로 해 줘야 했다. plug and play 그런 건 없었다. 코덱이 너무 난무해서 동영상 보는 데 애로사항이 꽃폈고, 유니코드가 없어서 문자 인코딩이 어느 장단에 맞춰 춤을 춰야 할지 알 수 없던 그런 열악하던 시절의 추억이다.

Posted by 사무엘

1. 견인차

다른 자동차를 끌거나 수송하는 자동차는 도로에서 흔히 볼 수 있는 물건들이다.
사다리차가 크게 (1) 이삿짐을 나를 때 혹은 (2) 불 끌 때로 용도가 나뉘듯, 견인차는 크게 (1) 사고· 고장 차량 견인과 (2) 불법· 부정 주차 차량 견인으로 용도가 둘로 나뉘는 것 같다.
그리고 (1)용 견인차는 유난히도 '현대 리베로' 개조 차량이 눈에 많이 띄는 듯하다. 국산차 중에서는 보기 드물게 엔진룸이 앞에 돌출돼 있는 그 트럭 말이다.

사고가 한번 나면 어디서 정보를 입수했는지 정말 광속으로 견인차들이 벌떼같이 달려온다고 한다. 하지만 견인료 바가지를 피하려면 반드시 자기 차의 관할 보험사가 운영하는 견인차를 이용하는 게 좋다. 그리고 고속도로에서 차가 퍼졌다면 도로 공사도 자체적으로 인근의 휴게소나 톨게이트 정도까지는 무료 견인을 제공한다고 한다.
승용차 말고 대형 트럭이나 버스를 견인하는 더 크고 아름다운 견인차도 있으나 이런 건 더 보기 어렵다.

한편 이들과는 달리, 공장에서 갓 출고된 신차(특히 승용차 같은 소형차)는 여러분도 모양을 기억하고 있을 거대한 트레일러에다 최하 대여섯 대씩 통째로 싣고 운반한다. 액션 영화에서는 달리는 신차 수송 트레일러를 주인공이 폼나게 탈취해서 거기 있는 차를 곧장 시동 걸어서 달려가는 장면이 나온다.
그리고 수리의 여지가 없는 폐차는? 차량을 한 치의 손상도 안 나게 곱게 수송해야 할 필요는 없으니, 생채기가 나건 말건 상관없이 차들을 같은 공간에라도 더 우겨넣어서 나르는 편이다.

자동차 다음으로 철도를 살펴보면.. 기관차는 애초에 동력이 없는 다른 객차들을 견인하라고 만들어진 물건이다. 특히 전기로 달리는 차량들은 디젤 차량보다 퍼질 확률이 상대적으로 더 높기 때문에 디젤 기관차가 '구원 운전'용으로 쓰인다. 또한, 본격적인 장거리 주행이 아니라 단순히 역이나 기지 내에서 차량의 분리· 결합, 선로 전환용으로 잠깐 잠깐 쓰이는 소형 기관차를 '입환기'라고 따로 부른다. 오늘날의 특대형 기관차가 아니라 옛날에 도입되었던 상대적으로 소· 중형, 저성능 기관차 중, 4400호대가 오늘날까지 이례적으로 입환용으로 쓰이는 중이다.

끝으로, 선박에도 견인이라는 게 물론 있다. 예인선이라는 선박도 있는데 있는데 이건 구조가 어찌 되나 잘 모르겠다. 오로지 비행기만이 한 기체나 다른 기체를 물리적으로 어찌할 방법이 전혀 존재하지 않는다. (전투기를 동원해서 아예 격추시키는 것 말고) 다만, 고정익 비행기는 아직 공중에 뜨기 전에는 타 자동차의 견인을 받는 게 관행이다.

2. 비행기 tow car

고정익 비행기는 주변의 공기를 거세게 빨아들이고 내뿜으면서 움직인다는 특성상, 여객 터미널 주변에서는 자기 엔진으로 자력 이동을 하지 않는다. 특히 후진도 기술적으로 전혀 불가능한 건 아니지만 여러 여건상 무리라고 판단하여 그냥 봉인하고 지낸다. 그렇기 때문에 우리가 타는 여객기들은 출발 직후에 주기장부터 활주로의 자력 주행 구간까지 잠시 동안은 별도의 견인차의 도움을 받아서 움직인다.

공항 활주로에서 납작한데 바퀴는 엄청 크게 생긴 이상하게 생긴 트랙터가 바로 비행기 견인차이다. 나름 비행기의 운행에 없어서는 안 될 물건이다. 크기는 다양한 편이며, 보잉 747이나 A380 같은 크고 아름다운 여객기를 견인할 정도의 견인차는 최대 시속은 겨우 32.2km인 주제에 엔진은 무려 10400cc 배기량에 1000마력대를 자랑한다. 가격은 억~10억 원대.

비행기는 움직이지 않고 자기 바퀴만 헛도는 현상을 방지하려면 엔진 힘만 강한 게 아니라 자기도 엄청 무거워서 접지력이 좋아야 한다. 그렇기 때문에 이런 견인차의 자체 중량도 수십 톤에 달한다. 또한 철도 차량이 아닌 것이 이례적으로 후진 역시 전진과 거의 대등한 다양한 단수로 할 수 있게 돼 있다.
대형 비행기 견인차는 가격과 엔진 성능으로만 따지자면 이거 무슨 외제 슈퍼카 스포츠카와 별 다를 바 없다. 단지 제로백이나 속도만이 천지차이일 뿐..

3. 스페이스 셔틀의 셔틀

비록 오래 전에 퇴역해서 지금은 존재하지 않지만, 이 분야의 최고 특별한 사례로는 우주왕복선을 실어 날랐던 보잉 747 개조 화물기를 꼽을 수 있겠다.

이게 왜 필요하냐 하면.. 우주왕복선은 착륙은 여러 곳에서 할 수 있지만 발사는 반드시 한 곳(케네디 우주 센터. 플로리다 주 소재)에서만 가능하기 때문이다. 뭐, 착륙 지점도 여러 곳이라고 해 봤자 실제로는 두 곳뿐이긴 했다만(에드워즈 공군 기지 추가. 캘리포니아 주 소재).. 한때 NASA에서 남아메리카의 이스터 섬조차 우주왕복선의 착륙 공항으로 개척할 생각을 했을 정도이니 우주왕복선이 활발히 운용된다면 착륙 가능 공항이 더 생길 가능성이 있었다.

지구로 재진입하는 우주왕복선 사령선은 그냥 글라이더일 뿐, 동력 비행이 가능하지 않다. 그러니 발사 기지 외의 다른 곳에 착륙한 사령선은 재활용을 위해서는 누군가가 다시 발사 기지로 수송해 줘야 된다.
그런데 얘는 크기도 엄청 큰데 일일이 분해해서 육로 수송을 하기에는 기계의 신뢰성 차원에서 리스크가 너무 큰지라, 있는 그대로 항공 수송을 선택하게 됐다.

세상에서 가장 큰 단일 세포가 타조알이듯, 우주왕복선 사령선은 세상에서 가장 큰 단일 항공 화물이라고 기네스북에도 올랐다고 한다. 세계에서 제일 큰 화물기는 AN225이긴 하지만 우주왕복선은 그냥 보잉 747 개조기로 수송된다. 우주왕복선을 기체 안에 집어넣을 수는 없으니 저렇게 위에다가 특수한 방법으로 고정해 놓는다. 그리고 화물을 실은 뒤의 항공역학적인 최적화를 위해 이 비행기는 수직미익이 추가로 달려 있다.

우주왕복선을 위에다 얹는 작업도 특수한 크레인을 동원해서 며칠씩 걸리는 굉장히 까다로운 작업이다. 고정을 잘못했다가 우주왕복선이 공중에서 비행기에서 굴러떨어지는 사고라도 나는 건 생각도 하기 싫은 악몽일 테니까.
게다가 이 비행기는 우주왕복선을 실은 상태에서는 미국 대륙 횡단조차 한 번에 못 하고 중간에 착륙해서 급유를 받아야 했다고 한다! 굉장히 충격적이다. 747은 그냥 승객만 가득 실었을 때는 나름 한국· 일본에서 뉴욕까지도 직항이 가능하지 않던가?

물론 우주왕복선은 승객 400명보다 더 무거운 80톤에 달하는 무게를 자랑하기도 하지만, 셔틀 수송기가 빌빌대는 더 큰 이유는 연료 탑재량, 엔진 출력 등이 아니라 다른 곳에 있다. 저렇게 우주왕복선을 등짝에다 업은 외형으로는 오리지널 비행기와 같은 수준의 양력이 발생하지 못하기 때문이다. 그래서 오리지널 747 여객기의 순항 고도보다 훨씬 낮은 고도에서 더 낮은 속도로 조심스럽게 비행해야 하며, 항속 거리도 몇 분의 1 수준으로 감소한다고 한다.

그러니 수백만 달러가 깨지는 온갖 번거로운 두벌일을 안 하려면 우주왕복선은 어지간해서는 그냥 발사지인 케네디 우주 센터로 곧장 착륙하는 게 바람직했다. 그러나 하필 거기가 날씨가 안 좋고 폭풍이라도 분다면 이는 활강을 하는 우주왕복선에게 안전상의 악재일 수밖에 없다. 그러니 불가피하게 에드워즈 공군 기지로 가야 했다.

사실, 자체 동력이 없는 우주 비행체를 잘 조종해서 특정 지점에 딱 맞춰 착륙시키는 것도 쉬운 일이 아니었을 것 같다. 보통 우주에 다녀온 사람들은 자그마한 캡슐에 탄 채 대서양 망망대해에 낙하산 달고 퐁당 떨어진 뒤, 군함이 좌표를 받고 구조하러 오지 않던가? 그리고 우주왕복선은 이렇게 지구에서 수송하는 과정뿐만 아니라 발사되는 과정도 모두 아주 경이로운 물건이다. 연료가 분출되어 기체가 나아가는 방향과 사령선이 달린 곳이 일직선이 아니기 때문에, 무게와 각도 배분이 아주 까다롭다..

4. 유니목/우니모크 -- 만능 자동차

메르데세스 벤츠에서 개발한 '우니모크'(Unimog)라고 바퀴가 굉장히 크고 범퍼와 차체가 높고, 길이는 짧아서 좀 특이하게 생긴 트럭이 있다. 그런데 이게 보통 물건이 아니다. 얘는 유연성, 확장성, 플러그 인 연계, 험지 주행 능력.. 이런 것들이 지구의 그 어떤 육상 교통수단의 추종도 불허하는 세계 최강의 다기능 다재다능 다용도 자동차이다. 뭔가.. 자동차계의 맥가이버칼이다.

위의 사진을 보면 서스펜션부터가 비범해 보이는데.. 어지간한 험지에서도 하부가 긁힐 걱정 따윈 안 해도 된다.
45도 경사를 오를 수 있으며, 기어도 최저단은 가속 페달을 밟고도 사람 걷는 속도보다 느리게 만들 수 있을 정도이다. (자동차가 보통은 idle creeping조차도 사람 걷는 속도와 대등한데..)

휠을 교체하면 레일 위 주행쯤은 당연히 가능하고, 심지어 운전대도 작업 편의를 위해서라면 좌핸들과 우핸들 실시간 전환이 된다. 그리고 덤프 트럭, 타 차량이나 비행기 견인 등 온갖 파트를 붙여서 작업용 차량으로 개조 가능하다.
이런 차는 군대에서 최고로 환영받을 거라고 생각했다면 100% 정답이다. 독일군 내부에서 당연히 제식용으로 쓰이고 있다.

5. 바거 288

세계에서 가장 큰 비행기에 이어, 지상에서 세계에서 가장 큰 자력 이동 가능(= 다른 교통수단으로부터 견인받지 않아도 되는) 기계는.. 이미 아시는 분도 계시겠지만 독일에서 제작한 초대형 광산 굴착기인 Bagger 288이다. 미국뿐만 아니라 독일 공돌이들의 발상과 능력에도 경의를 표하게 된다.

뭐 법적으로는 교통수단이 아닌 건설기계일 테고, 너무 크고 무겁기 때문에 일반 도로를 주행하기란 어차피 불가능하다. 과거에 나치에서 만들었던 열차포 따위와도 비교가 안 되는 규모이니까... 자력 이동은 광산 지대에서 이동하라고 넣은 기능이지, 도로를 달리라고 넣은 게 아니다.

굴삭기의 경우 바퀴식은 그냥 도로를 달려서 주행하기도 하지만 그래도 타 자동차들보다는 주행 속도가 훨씬 느리기 때문에 일반 자동차들에게는 추월을 강요하는 약간의 민폐를 끼친다. 무한궤도식은 도로 파손을 방지하기 위해 평소에는 그냥 다른 대형 트럭에 실린 채 수송되기도 한다.

하지만 Bagger 288은 뭐 다른 교통수단에 싣거나 견인 받는 것 자체가 절대 불가능하고.. 자력 이동이 가능은 하지만, 주행 속도는 시속 1km가 채 되지 않는다고 한다..;; (0.1~0.6km/h, 분당 2~10m) 그렇게 느리게 움직이지만 움직이는 기계에 다른 차가 부딪치면 그냥 통째로 뜯겨져 나가고, 사람은 스치기만 해도 사망이지 싶다.

Posted by 사무엘

지난 여름 동안 본인은 등산은 너무 더워서 한동안 못 했다. 자전거로 한강 공원 정도나 다니다가, 여기서 더 나아가 서울과 적당히 떨어져 있으면서 큰 강이나 호수를 보러 놀러 갈 만한 곳은 없는지 찾아보게 되었다.
그 결과 본인의 눈에 띈 곳은 북한강과 남한강이 합류하는 남양주와 양평 사이였다. 강 두 개가 만난다고 해서 지명부터가 '양수'리, '두물머리' 이런 식이었다.

그런데 거기 일대에는 웬 다산 정 약용 선생 유적지가 있고, 강가에는 숲과 풀밭이 잘 꾸며져 있었다. 놀다 오기 좋겠다는 생각이 들어서 토요일 아침에 곧장 차를 몰고 나갔다.

예전에 검단산을 올랐다가 하남시 배알미동 방면으로 하산하면서 팔당댐을 멀리서 본 적은 있다. 그런데 댐 위의 '공도교'를 건너는 건 이번이 난생 처음이었다.
여기는 국가 기간 시설인 댐 위이고 이게 딱히 교량 역할을 하라고 만들어진 시설물은 아니지만.. 강북의 국도 6호선과 팔당대교가 주말에 워낙 많이 막히는 관계로 주말에만 소형차에 한해서 공도교의 통행이 허용되고 있었다. 도로의 폭은 그냥 2차선에 불과하며 좌우로는 온통 철조망이 쳐져 있다.

다산 유적지 겸 생태 공원 주변은 한가한 농촌 마을이었다. 이렇게 유적지 어귀에 공영 주차장이 있고, 카페나 생태 공원에 더 가까운 곳에도 주차장이 또 있었다.
아침 11시쯤에 왔을 때는 주차장이 널널한 편이었지만 오후 2~3시가 넘어가면서 여기는 차들로 온통 꽉 찼다.

가장 먼저, 이 유적지의 주인공인 다산 정 약용 선생의 생가(복원된 레플리카), 기념관, 동상, 묘지가 한데 있는 단지를 들렀다. 이분은 경치 한번 참 좋은 곳에서 태어났구나.
묘지는 단지 안의 10몇 m 남짓한 높이의 언덕을 올라가면 볼 수 있는데, 이렇게 생가와 묘지가 같이 조성돼 있는 건 이 승복 어린이 기념관도 비슷한 형태였던 걸로 기억한다.

정 약용은 '다산'이 아니라 '다작'이라는 호가 더 어울렸을 것 같다. 천재이고 생각보다 굉장히 대단한 인물이었다. 목민심서 말고 나머지 책들은 일반인에게는 다 듣보잡이긴 하다만... ㅠㅠ

이 사람은 평범한 유학자가 아니라 실학의 선구자라고 불린다. 윤리 도덕 분야 말고도 왕년엔 수원 화성을 쌓을 때 거중기를 고안해서 투입 인력과 공사 기간과 절감해 줬고, 과학과 추리를 이용한 사건 수사로 억울한 누명을 벗겨 주기도 했다. 손대는 분야마다 뭔가 비리를 척결하고 시스템을 개선하고 경영 효율을 올려 놨다. 그런 능력에다가 어진 인품까지 갖췄다는 게 매우 중요하다.

설령 김 성모 식으로 우려먹기 재탕을 거듭한다 하더라도 컴퓨터도 없던 시절에 그것도 한문으로 저렇게 많은 책을 쓰기란 매우 어려울 텐데.. 물론 정 약용의 경우 17년 동안, 다시 말해 박 정희 대통령의 통치 기간에 맞먹는 긴 기간을 유배 생활을 하느라 저술 활동을 할 시간이 많기도 했다.

그 다음으로 근처에 있는 실학 박물관을 찾아갔다. 다산 유원지의 다른 모든 시설은 무료이지만 이 박물관만은 입장료를 받았다.
여기는 말 그대로 정 약용에만 국한되지 않고 조선 후기에 실학이 등장한 배경, 그때 깨어 있던 사람들이 서양 문물을 받아들인 배경, 조선 후기에 지리학과 천문학이 조금이나마 발전한 과정 같은 게 소개되어 있었다.

이런 실학의 이념은 훗날 국민 교육 헌장에도 '능률과 실질을 숭상하며'라는 문구로 어느 정도 반영돼 들어간 셈이다.
참, 내가 갔을 때는 특별 전시회 명목으로 한글로 글을 남긴 조선 여성들의 실학 트렌드 이런 것도 있었다.

역사 공부를 이 정도로 한 뒤, 그 다음부터 본인은 본격적으로 자연을 즐기러 나갔다.
실학 박물관을 나와서 강 쪽으로 가는 길에는 이렇게 분위기 좋은 풀밭이 꾸며진 카페들이 날 반겨 줬다.

이제 저 멀리 강이 보이기 시작한다. 돗자리는 이런 나무 아래 풀밭에 아무 데나 펴면 됐다.

강이라기보다 호수나 저수지, 심지어 바다처럼 보이는 커다란 물이 모습을 드러냈다.

경치가 정말 아름다웠다.
여기는 엄연한 상수원 보호 구역이기 때문에 서울 시내의 한강 공원 따위와는 레벨이 다르다.
또한, 한강 종합 개발 사업 같은 게 없었으니 콘크리트 제방 같은 것도 없으며, 땅과 물의 경계는 그냥 흙· 뻘밭인 걸 알 수 있다.
이런 곳에서 물놀이를 할 수는 없다. 물에 들어가려면 바다나 산 속 계곡으로 가야 한다.

물의 면적이 워낙 크니 강바람도 바닷바람 만만찮게 느껴졌다. 시원하고 좋았다.

본인은 이렇게 돗자리를 깔고 뒹굴뒹굴 하다가 잠시 눈을 붙이기도 하고 프로그래밍 작업도 했다.
그러다가 폰과 노트북의 배터리가 더 견디지 못할 지경에 이르렀을 때쯤엔 아까 봐 뒀던 카페에 들어가서 에어컨 바람을 쐬고 음료수와 전기를 보충했다.

그런데 이게 웬일? 내가 카페에 들어간 사이에 저녁에는 비가 내리기 시작했다. 풀밭과 강가에 그 많던 인파와 돗자리족· 텐트족들은 어느새 쏙 들어가고 일부 우산을 들고 산책하는 사람만 보였다.
몇 시간 전까지만 해도 차 안은 너무 더워서 도저히 있을 수가 없었다. 그런데 이제는 반대로 밖이 반팔 반바지 차림으로 지내기엔 쌀쌀해지고, 차 안이 비바람을 피하는 아늑하고 포근하고 따뜻한 아지트가 됐다.

이렇게 더 있다가 완전히 해가 진 뒤에 돌아왔다. 이런 휴양지가 있었다니, 가 보길 정말 잘했다.

Posted by 사무엘