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

1. 함수 명칭만으로 오버로딩 분간하기

C++에는 그 이름도 유명한 함수 오버로딩이라는 게 존재하기 때문에 어떤 함수를 이름만으로 유일하게 식별할 수 없다. 링크를 위한 심벌을 생성할 때는 자신이 받아들이는 인자들의 개수와 타입도 이름에다가 일일이 곁들여 줘야 동명이인(?) 함수들을 구분할 수 있다. 이 절차를 decoration이라고 한다.

그런데 바이너리 차원에서 함수 이름에 대한 구체적인 decoration 방식은 표준으로 정해진 것이 없어서 컴파일러마다 완전히 제각각이다. 이 때문에 동일한 타겟에다 동일한 포맷의 obj/lib(기껏해야 OMF 아니면 COFF..)라도 C++ 클래스 라이브러리는 컴파일러를 넘나드는 이식성이 크게 떨어진다.

C 단독이 거의 쓰이지 않는 오늘날까지도 유명 라이브러리들이 C언어 형태의 단순한 인터페이스를 고집하는 이유 중의 하나가 바로 이것이다. 아니면 그런 C 함수를 아주 얇게 감싸는(생성자, 소멸자, 오버로딩..) C++ wrapper 클래스를 만들더라도 하는 일이 정말 C 함수 호출밖에 없고, C++ 멤버 함수는 몽땅 인라이닝이 되게 만든다. 인라이닝이 됐다면 decoration이고 뭐고 걱정할 필요가 전혀 없어지기 때문이다.

그런데.. C++에서 함수를 (1) 실제로 호출하지 않고, (2) 저렇게 decoration 정보가 있는 link time도 아니면서 소스 코드 차원에서(= compile time) 오버로딩 동명이인 함수를 구분할 수는 없을까?

엥? (1)도 (2)도 아닌 애매한 상황은 C++에서 한동안 고려할 필요가 없었다. 그러나 2010년대부터 modern C++이 등장하고, 명칭만으로 type을 유추할 수 있는 auto와 decltype 키워드가 도입되면서 발생할 수 있게 됐다.

void foo() {}

라는 함수를 정의해 놓았다면

auto ptr = &foo;
decltype(&foo) ptr = ...;

이런 식으로 foo를 얼마든지 써먹을 수 있다. auto와 decltype이 자동으로 void (*)()이라는 타입을 유추해 내기 때문이다. 그런데 문제는..

void foo(int) {}

같은 overload를 더 만들었을 때이다.
그러면 이때부터 auto와 decltype에다가 foo를 언급할 수 없게 된다. 이 이름이 가리키는 함수의 prototype이 하나로 딱 떨어지지 않기 때문이다.

이에 대해 C++ 표준 스펙은 오버로딩된 함수 이름을 저기에다 집어넣는 것은 ill-formed라고만 지적하고 넘어간다. (☞ 링크)
이건 컴파일된 obj가 아니라 소스 코드 레벨이기 때문에 decorate된 저수준 명칭을 사용할 수도 없다. 어느 오버로드인지를 지목하는 문법은 딱히 마련하지 않고 넘어간 듯하다.

글쎄, 생각 같아서는 foo as_in () 내지 foo as_in (int) 같은 오버로딩 식별을 위한 토큰이 필요해 보인다.
파이썬이라면 모를까 C++에서 겨우 이런 용도를 위해 영단어 예약어를 도입하는 건 보기 좋지 않다. 그냥 foo 다음에 -> : []처럼.. 데이터 포인터가 아닌 함수 포인터라면 쓰일 일이 없는 기존 연산자 토큰을 늘어놓아서 이 함수의 인자들의 타입을 기술해 주면 될 것이다.

참고로, 함수의 포인터를 얻는 상황에서는 static_cast가 아주 유용하게 쓰인다.
void *p = static_cast<int (*)(int,int)>( func_ptr );

이렇게 해 주면 이 형변환은 func_ptr이 int 2개를 받고 int를 리턴하는 놈이 실제로 선언이나 정의돼 있을 때에만 성공한다. 그런 게 없으면 에러.. 그러니 안전하다. 흥미롭지 않은가? 형변환 연산자가 함수의 동명 오버로드를 분간할 때도 쓰인다니 말이다.
C-style cast나 reinterpret_cast는 그런 면모가 없고 무조건 될 것이다.

2. 복합 포인터 간의 더 세밀한 형변환 연산자

C/C++에서 void*라는 포인터 타입은 잘 알다시피 다른 아무 자료형을 가리키는 포인터를 받아서 대입될 수 있다. 공집합은 다른 모든 집합들의 부분집합이며, 1은 다른 모든 자연수의 약수인 것과 같은 이치이다.
malloc을 비롯해 메모리를 할당하는 함수들은 특정 자료형에 구애받지 않는 void*를 되돌린다. 그런데 이 포인터값을 함수의 리턴값이 아니라 함수 인자로 전달된 포인터가 가리키는 주소에다 받게 하려면 어떡해야 할까?

그럴 때는 별 수 없이 이중 포인터가 쓰이게 된다. 자주 보는 물건은 아니지만 Windows에서 COM 객체를 다루다 보면 QueryInterface 메소드, CoCreateInstance 함수 때문에 접하게 된다. COM에서는 함수 리턴값은 에러코드(정수값)를 되돌리고, 포인터는 인자로 전달된 주소를 통해 받기 때문이다.

여기서 우리는 문법 차원에서 약간의 어색함을 경험하게 된다.
void*는 int*, char* 등 다른 포인터 타입과 호환되지만 이중 포인터끼리는 그렇지 않다. 가령, void**와 int**, char** 따위는 호환되지 않는다.
상속 관계도 마찬가지이다. IUnknown**에다가 IUnknown의 파생 클래스의 포인터의 주소를 바로 넘겨줄 수는 없다.

단순 포인터는 한쪽은 호환되고, 역변환은 static_cast만 해 주면 된다. 그러나 이중 이상의 포인터는 가리키는 타입도 타입 그 자체가 아니라 그 타입의 포인터이다. 그렇다 보니 타입간의 아무런 계층 관계가 인정되지 않는다. 어느 방향으로든 얄짤없이 무식하게 reinterpret_cast만 써야 한다.

글쎄, 이런 일이 자주 발생하고 구분해 줄 필요가 꼭 있다면 pointer_cast 내지 reference_cast라고 해서.. 다중 포인터라도 참조 깊이가 동일하고 최종적으로 도달하는 타입이 서로 static_cast급으로 호환된다면 변환을 허용하는 형변환 연산자를 둘 법도 해 보인다. 저건 굳이 reinterpret_cast까지 사용해야 할 정도로 과격하고 위험해 보이지는 않기 때문이다.

하지만 저 상황만을 위해서 별도의 키워드까지 추가하는 건 좀 overkill 낭비로 보이니 그렇게 되지 않은 것 같다. 배열이야 필요에 따라 3차원 이상의 다차원 배열이 쓰일 수 있지만, 포인터는 본인도 20여 년에 달하는 프로그래밍 인생 이래로 3중 이상 깊이의 포인터를 사용할 일은 전혀 없었다. 즉, void ***p라든가, 이중 포인터에 대한 주소값 같은 것 말이다.

포인터라는 게 크게.. (1) 타 자료형에 대한 포인터, (2) 함수에 대한 포인터, (3) 구조체 및 클래스의 멤버에 대한 포인터라는 세 갈래로 나뉘는 것 같다. 물론, (1)~(3) 종류 불문하고 포인터를 가리키는 포인터는 자동으로 (1)에 속하게 된다. (2)와 (3)은 void*로 싸잡아 일컫는 것이 권장되지 않거나 원천적으로 가능하지 않다.

멤버 포인터의 포인터 내지 배열 같은 것은.. 잠깐 테스트를 해 보니 그래도 문법적인 한계나 typedef 땜빵 없이 이렇게 바로 선언해서 쓸 수 있긴 하다. 물론 멤버 포인터 자체도  쓰일 일이 극도로 드문데 하물며 그걸 또 가리키는 포인터는.. 삼중 이상의 포인터만큼이나 정말 레어템이다. 아래처럼 말이다.

class A {
public:
    void func(int x);
};

void (A::*pfn)(int) = &A::func;
void (A::**ppfn)(int) = &pfn;
void (A::*apfn[1])(int) = { &A::func };

A obj;
(obj.*pfn)(1);
(obj.**ppfn)(2);
(obj.*apfn[0])(3);

복잡한 포인터에서 세부 속성 간의 형변환은 비단 다중 포인터에만 존재하는 게 아니다. 함수 포인터에다가 인자의 개수와 calling convention 같은 건 완전히 일치하고, 일부 인자나 리턴값만이 void*와 char*처럼 미묘하게 다른 함수를 집어넣는 상황을 생각해 보자. 일반 함수뿐만 아니라 C++ 멤버 함수의 포인터도 해당된다.

이때도 지금 문법에서는 닥치고 C-style 또는 reinterpret_cast를 쓰는 수밖에 없다. 하지만 static_cast와 reinter_*의 중간 완충 역할을 해서 저럴 때만 유도리를 허용하는 연산자가 있다면 문법 차원에서 실수가 더 줄어들 수 있고 더 깔끔한 코드를 작성할 수 있다. 프로그래밍 언어에서 type theory의 심오함이 문득 느껴진다.

3. 복수 인터페이스의 구현체에서 IUnknown 베이스 얻기

C++로 COM 인터페이스를 지원하는 클래스를 구현하다 보면.. 다중 상속 기능을 이용하여 한 클래스에다가 2개 이상의 인터페이스를 한꺼번에 집어넣는 경우가 있다.
예를 들어 한 윈도우가 drag & drop을 양방향으로 지원해서 데이터를 밖으로 날릴 수도 있고 받을 수도 있다면, 그 윈도우를 나타내는 클래스(가령, CMyWnd)에다가 IDataObject, IDropSource와 IDropTarget를 몽땅 때려박는 게 편하다.

이렇게 하고 나면, 그 CMyWnd를 상대로 인터페이스들의 베이스인 IUnknown의 QueryInterface, AddRef, Release 메소드를 호출하는 것이야 아무 문제 없이 된다.
다중 상속의 특성상, CMyWnd를 IDataObject, IDropSource, IDropTarget 등으로 캐스트한 포인터 값은 제각각 달라질 수 있다. 왜냐하면 멤버 변수가 없는 인터페이스이더라도 상속을 하나 할 때마다 vtable 포인터의 크기 하나씩은 클래스에다가 차지하게 되기 때문이다.

하지만 이들의 vtable에서 IUnknown 파트는 모두 공통으로 CMyWnd가 구현한 동일한 QueryInterface, AddRef, Release 함수를 가리키게 된다. 이게 바로 마법의 비결이다.
단, 둘째, 셋째, n째 인터페이스들은 this 포인터 값을 살짝 보정한 뒤에 원래 함수를 호출하는 thunk가 추가된다. 마법이 공짜는 아닌 셈이다. 그래서 다중 상속에서는 내가 함수를 호출한 객체의 주소와, 해당 멤버 함수가 받은 this 포인터의 값이 일치하지 않을 수 있다.

그렇게 다중 상속에서 함수 호출과 this 보정 문제가 해결되었는데.. 정작 CMyWnd 오브젝트의 포인터를 IUnknown* 자체로 cast 하는 것은..??? 뜻밖에도 되지 않고 컴파일 에러가 난다. 암시적 자동 형변환은 물론이고, static_cast와 C-style cast도 통하지 않는다.
왜냐하면 얘는 2개 이상 여러 인터페이스를 구현했는데 어느 놈을 기준으로 삼아서 IUnknown으로 cast 해야 할지 알 수 없기 때문이다. 모호성이 존재한다는 것이다. 뜨악~

현실에서 어지간해서는 이런 일을 겪을 일이 거의 없다. 그냥 파생 클래스 구현체가 베이스 인터페이스의 완벽한 상위 호환이니, 어지간한 상황에서는 그냥 그 클래스를 쓰면 되지 굳이 베이스로 형변환을 할 일 자체가 없기 때문이다.

하지만 아무 인터페이스 오브젝트나 받아들여서 레퍼런스 카운트 관리만 한답시고 IUnknown을 인자로 받는 함수가 드물게 있을 수 있다. 그 함수에다가 이런 오브젝트를 덥석 넘겨주면 어느 베이스의 IUnknown을 골라야 할지 모르겠다는 태클에 걸린다. 저 인터페이스들이 IUnknown을 가상(virtual) 상속을 한 게 아니기 때문에 이 문제를 피해 갈 수 없다. 어차피 인터페이스에는 데이터 멤버도 없으니 아무거나 골라도 됨에도 불구하고 말이다.

그 클래스가 상속한 베이스들 중 가상 함수가 존재하는 제일 첫 놈이 IUnknown 기반의 인터페이스라면.. 그 클래스의 인스턴스의 포인터는 그대로 직통으로 IUnknown으로 형변환해도 된다. 하지만 이건 이게 C++의 문법 차원에서 안전이 보장될 수 없는 동작이기 때문에 컴파일 에러가 발생하는 것이다.

C-style cast는 static_*과 reinterpret_*의 중간 정도 위상을 차지하는 물건이며, 포인터 간의 형변환에서는 오히려 후자에 더 가까운 위치에 있다. 하지만 다중 상속에 대해서는 의외로 선 넘지 않는 안전 장치가 걸려 있는가 보다.
저 때 자기 자신을 베이스인 IUnknown으로 강제로 둔갑시키는 수단은 reinterpret_cast밖에 없다.
아니면!! 자신을 void*로 먼저 전환한 뒤에 그걸 IUnknown으로.. static_cast를 두 번 적용하면 된다. 물론 이것들은 다 at your own risk를 감수하고 해야 한다.

이 문제를 해결한답시고 CMyWnd에 대해서 무식하게 QueryInteface(IID_IUnknown, &obj)를 하는 건 너무 오버 같다.
뭐, 어느 베이스를 선택할지 static_cast<IDataObject*>(&obj) 이렇게 명시적으로 지정을 해 주면 모호성이 해소되어 C++ 차원에서 IUnknown으로 cast도 가능해진다.
하지만 이것도 언어 차원에서 더 깔끔하게 해결할 방법이 없는지, const 객체뿐만 아니라 베이스 인터페이스에 대해서도 select_any 같은 속성을 지정해 줄 수는 없을지 궁금하다.

참고로 이런 형변환이 일어나는 곳은 해당 객체 자체가 아니라 십중팔구 그 객체의 포인터들이다. 그러니 그 클래스에서 operator IUnknown*() { return static_cast<****>(this); } 이렇게 전용 형변환 연산자를 구비하는 것은.. 성능 오버헤드는 없지만 언어 문법 차원에서의 아주 깔끔한 해결책으로 보기는 어려워 보인다.;;;

Posted by 사무엘

밤에 일반 공도에서 주변 민폐를 끼치면서 차나 오토바이로 과속· 폭주를 즐기는 양아치한테 일반인들이 흔히 하는 핀잔 중 하나는 "그렇게 폭주가 좋으면 그런 짓은 서킷에나 가서 해라"이다.

본인도 나름 성질이 급하고 운전대를 잡으면 과속을 즐기며, 난폭운전은 직접 하는 것과 남의 차에 탑승하는 걸 다 좋아하는 취향이다.
하지만 그렇다고 그런 짓을 주변 차에다가 피해를 주면서까지 하지는 말아야 한다. 차가 없고 시야가 확보돼 있는 한적한 고속도로에서야 150~200km/h까지도 밟지만, 엄폐물이 많고 당장 앞과 옆에서 뭐가 튀어나올지 모르는 좁은 골목길에서는 시속 20도 안 밟으면서 천천히 가는 게 베스트 드라이버의 덕목이라 하겠다.

그건 그렇고 본인은 이 시점에서 의문이 들었다. 그 말로만 듣던 서킷에서는 어떤 일이 벌어지고 있을까? 더 나아가 Formula 1처럼 지금까지 말로만 들어 온 자동차 경주라는 업계의 사정은 어떠할까..?

1. 도로 시설

서킷은 통제된 환경에서 프로 선수들이 처음부터 작정하고 차를 위험하게 다루면서 극한의 속도 경쟁을 하는 곳이다. 공도가 전혀 아니며, 통상적인 도로교통법이나 자동차 보험 등에서 완전히 열외되어 있다. 일반인이 차를 슬금슬금 몰다가 실수해서, 혹은 극소수의 술 먹은 미치광이가 난입해서 사고가 나는 곳이 아니다.
이는 군인이 전투 중에 적군을 사살하는 건 살인죄가 전혀 아니며, 반대로 자기가 전사하는 것에 대해서도 통상적인 민간 생명보험이 적용되지 않는 것과 같다. 위험도와 사고 발생 형태가 규모와 차원 면에서 완전히 다르기 때문이다.

자동차가 발명된 이래로 자동차 경주라는 건 경마의 업그레이드 버전 차원에서 옳다구나 거의 곧장 존재해 왔다. 물론 이건 말 그대로 기름을 길바닥에다 뿌리는 짓이며, 장비값, 기름값, 보험료, 선수 인건비 등 돈이 굉장히 많이 깨지는 비싼 스포츠이다.
하지만 자동차 경주는 나름 흥미진진한 볼거리를 제공하며, 자동차 제조사들이 자기 제품의 기술력을 뽐내는 중요한 자리이기도 하다. 이런 이벤트가 하나쯤 있는 것은 자동차 산업의 관점에서 이해타산이 맞고도 남는다.

그렇기 때문에 자동차 경주 대회는 망할 일이 없으며, 기업 후원을 통해 꾸준히 잘 유지되고 있다. 아니, 그저 명맥만 유지하는 수준이 아니라 올림픽이나 축구 월드컵에 맞먹는 팬을 보유하고 있고 장사가 잘 된다. 물론 경주용 자동차들의 표면과 레이서들의 옷은 온~~통 스폰서의 광고들로 덕지덕지 도배된다.

우리나라는 10여 년 전에 전라남도 영암에서 F1 서킷을 건설하고 경기를 유치하기도 했다. 하지만 경기를 진행해 보니 수지가 맞지 않고 적자만 쌓인지라, 몇 년 못 가 중단됐다.
우리나라는 세계 선진국들의 평균 추세에 비해 경주처럼 자동차 자체를 즐기는 문화가 영 발달하지 못한 것 같다. 그러니 모터쇼도 자동차가 아니라 반쯤 레이싱걸 모델 전시장처럼 됐고 말이다..;;

2. 레이서

레이싱에서는 머신(자동차)뿐만 아니라 레이서, 즉 사람의 역량도 매우 중요하다. 사고가 나지 않을 만치만 차의 성능을 극한까지 짜내면서 최대의 급가속 급선회 기동을 적절한 타이밍 때 수시로 구사해야 한다. 그리고 전투기 조종사만큼이나 사방에서 발생하는 가속도를 잘 견뎌야 한다.

그래서 이 사람들도 몸 쓰는 게 아니라 기계를 조종한다고 해서 심신 단련을 안 하는 게 절대 아니다. 여느 운동 선수나 정예 군인에 준하는 수준으로 한다.
키와 체중은 일정 수준 이하여야 하며 높은 시력도 타고나야 한다. 말 타는 기수도 아니고 몇백 마력의 출력을 자랑하는 자동차를 모는데 체중이 10kg 가까이 더 나가 봤자 무슨 차이가 있겠는지 이해는 안 되지만.. 그 바닥 사정이 그러하다.

오죽했으면 세계적으로 봤을 때, 각 스포츠 분야의 1인자들 중에서 연봉과 사회적 지위가 제일 높은 사람은 무슨 축구나 농구 스타가 아니라 특급 카레이서이다~! 물론 여기에는 위험 수당도 있고, 타 스포츠와 달리 자동차 산업으로부터의 자본 투입이 많아서 그런 것도 있을 것이다.

3. 차량

그럼 서킷을 달리는 차들은 어떤 형태일까?
레이싱의 성격에 따라서는 일반 양산차를 쓰기도 하고 그보다 더 뛰어난 스포츠카를 쓰기도 한다. 하지만 속도가 생명인 경주용 차들은 공도를 달리는 평범한 차들과는 지향하는 특성이 다소 차이가 있다.

• 무게 최소화: 일반 양산차로 경주를 한다면, 불필요한 좌석이나 편의장치를 몽땅 떼어내는 정도의 개조가 무조건 필수이다.
  
• 접지력 최대화: 그래서 스포츠카들은 조금만 툭 튀어나온 과속방지턱도 제대로 지나기 어려울 정도로 바닥이 낮다(무게중심이 아래에 있어야..). 그리고 주름이 하나도 없는 타이어를 장착한다. 주름 없는 타이어는 접지력은 좋지만 도로가 조금이라도 젖으면 미끄러져서 위험하다. 공도에서는 이런 타이어를 장착하고 주행할 수 없다.
  
• 공기 저항 최소화: 더 이상의 자세한 설명은 생략한다.

그러니 자동차 경주에서는 양산차도 아니고 부가티· 포르셰 같은 차도 아니라, 큼직한 바퀴가 네 짝 달리긴 했는데 굉장히 특이하게 생겼고 한 명만 탈 수 있는.. 그 경주 전용 자동차들이 등장한다.

얘네들은 그야말로 배기량이 제한된 엔진의 힘을 이용해서 수단과 방법을 가리지 않고 제일 먼저 결승선에 도달하는 것만을 목표로 아주 특수하게 커스텀 제작된 물건이다.
부가티· 포르셰 같은 차는 성능에다가 일반인 운전자의 편의성까지 생각한 자동차이지만, F1용 머신은.. 오로지 성능 지향이다.

그런데 F1 경주라고 해서 무슨 부가티· 포르셰 급의 8기통 이상 6000~8000cc짜리 엔진이 장착된 차량이 달리는 게 절대 아니다.
이런 경주에서 엔진에 아무 제한을 걸지 않으면 온갖 기상천외한 짓거리를 한 머신이 등장해서 사고의 위험이 커지며, 자동차 제작 비용이 너무 치솟아서 경기가 제대로 진행될 수 없게 된다. 거기에다 아무리 속도만을 즐긴다고 해도 배기가스 환경 문제도 전혀 고려하지 않을 수는 없다.

그래서 격투기에 체중에 따른 체급 구분과 제한이 있는 것처럼 자동차 경주에는 엔진의 배기량 제한이 있는데.. 이게 낮아지고 낮아지기를 반복한 끝에 2014년부터는 F1 기준으로 겨우 1600cc라고 한다..;; 헐~~ 쏘나타보다도 작은 아반떼 배기량인데..

요즘 F1 차량은 그 배기량만으로 1000마력이 넘는 출력을 내고 2~3초대의 사기적인 제로백을 자랑한다. 즉, 튀어나가는 성능은 당연히 부가티· 포르셰에 뒤지지 않는다.
차 무게를 600kg대까지로 후려치고, 엔진 내구성도 후려치고.. 차량을 그야말로 경주를 위해 몇 시간 동안만 돌아가는 사실상의 일회용품 수준으로 쥐어짠 덕분이다.

컴퓨터계는 해커들이 겨우 100KB짜리 압축된 실행 파일로 거의 5분, 10분짜리 3차원 그래픽 데모를 선보이는 미친 최적화를 하기도 하는데, F1 머신에는 그런 식의 마개조가 일상이다.

그 대신 이런 F1 머신 같은 차들은 시동 걸고 운전하는 방식이 일반 차들과는 완전히 다르며, 사실 일반 공도를 제대로 주행하지도 못한다. 일반 자동차들은 동력원이 전기로 바뀌고 자율 주행 기술이 도입되고 있으니 경주용 자동차와는 개발 방향이 더욱 달라지고 이질화되고 있다. 스포츠 사격과 군대 저격수의 사격이 성격이 서로 다른 것처럼 말이다.

※ 그 밖에

(1) 지금까지 주로 F1을 기준으로 얘기했지만.. 이것보다 더 작은 체급으로 '카트'를 이용한 레이싱이 있다. 우리나라에서는 넥슨의 캐주얼 게임인 카트라이더의 인지도가 높다.

얘는 너무 작기 때문에 아무래도 큰 엔진을 얹어서 막 빠르게 달리지는 못한다. 그래도 바닥에 주저앉다시피해서 달리기 때문에 체감 속도는 굉장히 높게 느껴진다.
F1 프로 레이서들도 어린 시절에 카트부터 먼저 시작한 경우가 많다. 카트는 아무래도 양발을 한데 모을 수 없으니 브레이크는 어쩔 수 없이 언제나 왼발로 밟게 된다.

(2) 비포장 도로를 주행하는 오프로드 레이싱이라는 것도 있다. 얘들은 아무래도 속도에만 최적화된 타 레이싱과 같은 속도를 느낄 수는 없지만, 또 다른 방면으로 스릴과 박진감을 선사한다.
여기를 달리는 차들은 아주 큼직한 타이어를 장착하고 차체가 높은 게 특징이다. F1 머신과는 디자인이 정반대이다.

먼 옛날에 Ivan "Ironman" Stewart's Super Off Road, 일명 방구차라는 게임이 바로 오프로드 레이싱을 다뤘었다.

얘는 자동차 경주 게임이지만 화면 스크롤이 없다~! 한 화면에서 모든 경주가 행해진다. 스크롤도 없고 콩알만 한 자동차 스프라이트로 무슨 박진감을 표현하겠나 싶지만 평면에서 나름 복잡한 지형과 입체적인 자동차의 움직임을 그 시절 하드웨어로 표현하는 것은 딱 봐도 결코 쉬운 일이 아니어 보인다. 방향과 각도별 스프라이트 로직 설계를 어떻게 했을까? 나보고 저것과 똑같은 게임을 만들라고 하면 못 하거나 엄청 고생하지 싶다.

우리 주인공은 빨간 차인데, 노랑과 파랑은 제끼고 회색 차가 유난히 잘한다. 쟤만 따돌리면 된다.
이 게임의 별명이 '방구차'인 이유는.. Nitro라는 아이템을 먹어서 그걸 터뜨리면 마치 스타크래프트 마린이 스팀팩을 쓰듯이 일시적으로 차의 추진력이 올라갔기 때문이다.

(3) 사회 각지에서 금녀의 벽이 허물어진 지 오래이지만, 교통수단을 다루는 분야는 여성의 진출이 더딘 편이다.
옆의 레이서들에게 양산 씌워 주거나 자동차 옆에서 포즈만 취하고 있는 레이싱걸 병풍 말고.. 현업 여성 카레이서도 있다. '권 봄이'라는 사람이 지난 2010년대 동안 꽤 유명했는데 요즘은 뭘 하고 지내나 모르겠다.

또한, 여성 오토바이 라이더들도 모임이 있을 정도이며, (☞ 링크)
20대 여성 고속버스 기사 (☞ 링크),
20대 여성 트레일러 기사 (☞ 링크),
도 있다~!
한때는 " '이 운전사는 저의 아버지가 아닙니다.' / '이 아이는 제 자식입니다' 그럼 저 버스 기사의 정체는?" (아이의 어머니)
이게 "논리야 XXX" 시리즈 책에 실려 있을 정도로.. 짙은 선입견 때문에 일반인이 답을 선뜻 떠올리기 어려운 퀴즈였는데.. 그때에 비하면 지금은 세상이 많이 바뀌었다.

Posted by 사무엘

과거에 일제가 조선의 주권을 빼앗고 저지른 만행 중에서 물자나 노동력을 저렴하게 착취한 것, 사람을 차별 대우한 것, 독립 운동을 탄압한 것 자체는 아무래도 식민 통치를 하고 식민지에서 뽕을 뽑으려는 주체로서 당연히 할 만한 짓을 한 것이다. 잘했다는 것은 아니지만 우생학과 제국주의가 만연하던 그 시절에 일제만의 독보적인 악행이라고 보기는 어렵다. 더구나 조선에서의 양반 쌍놈 차별이라든가 기존 탐관오리들의 악행도 같이 비교한다면 상대적인 수위가 더욱 낮아진다.

그 반면, 일제 말기의 태평양 전쟁 관련 뻘짓과 악행은 성격이 좀 다르며 별개로 생각해야 할 것이다.
이렇게 (1) 일반적인 차별과 착취, 그리고 (2) 전쟁 준비에 속하지 않으면서 일제가 특별히 큰 죄악을 저지른 것, 정당하지 않은 명분으로 조선 민간인을 싹 학살한 만행을 추려내면 제암리 학살이라든가 관동 대지진 학살 정도가 남는다. 특히 개인적인 생각으로는 위안부보다도 관동 대지진 학살이 죄질이 더 나쁘다고 본다.

뭐, 일제도 한 마을 사람을 아무 이유 없이 싸이코패스마냥 몰살시키고 마을을 지도에서 지워 버린 건 아니었다.
3· 1 운동 만세 시위를 진압하던 헌병인가 누군가 한두 명이 성난 군중에게 구타 당해 죽었다. 그러자 일제는 범인이 저 마을 사람 중에 있다는 명목으로 보복을 저렇게 저지른 것이었다.

그런데 그렇게 따지면.. 처음엔 태극기만 들고 평화롭게 함성 지르며 행진하던 시위대가 격분· 흥분한 건 일본 헌병들이 실탄을 발사하고 피를 보게 만들었기 때문이다.
오죽했으면 유 관순 같은 시위대 리더들이 우리까지 폭력으로 나서면 안 된다고.. 그랬다가는 더 큰 보복을 당하고 만세 시위가 더 큰 참극으로 바뀐다고 군중을 말렸지만 혼란스러운 와중에 의사소통이 잘 되지 않았다.

결과는 잘 알다시피.. 처음에 일부 헌병 주재소가 박살나고 유치장 수용자들이 풀려나긴 했지만, 일본 쪽의 추가 지원 병력이 도착한 뒤부터는 시위대는 공중분해되고 더 많은 사람들이 죽거나 다쳤다. 헌병들도 흥분해서 다 죽이거나 잡아 가두고, 마을 집까지 불지르게 되었다.

이때는 오늘날 민주 국가의 경찰처럼 폴리스라인 치고 공포탄 경고 사격부터 몇 발 한 뒤에 암염탄이니 테이저건이니 발사하는 신사적인 매뉴얼이 없었다. 일제 저놈의 입장에서도 남의 나라 식민 통치라는 건 처음 해 보고, 반항하는 애들에 대해서는 그냥 닥치고 총칼로 위협하고 고문하고 죽여서 제압한다는 매뉴얼밖에 없었다.
(하물며 우리나라조차도 해방 이후에 4 19 같은 시위를 진압할 때 잘 알다시피 경찰이 대놓고 시위대에게 총질을 할 정도였다. 그때는 보고 배우고 행한 관행이 그랬기 때문이다.)

1919년 4월, 제암리 학살은 이런 배경에서 벌어졌다.
석 호필이라는 이름으로 유명한 프랭크 스코필드 선교사가 제암리 학살 현장의 참상을 촬영하고 세계에 타전해 줬다.

우리 선조들은 민족 자결주의 하나만 달랑 믿고 무슨 "꿈은 이루어진다"마냥 "대한 독립 만세"를 열심히 외치면 진짜 일제가 물러날 거라고 생각했던 걸까?
냉정한 현실에 비춰 본다면야 3· 1 운동은 그냥 숱한 인명과 재산의 피해만 야기한 순진해 빠진 망상이었을 것이다. 하지만 저런 희생을 치른 덕분에 조선은 일본과 다른 민족이며 일제의 통치를 원하지 않는다는 메시지 하나는 세계에 확실하게 전하고 일제의 입장을 굉장히 난처하게 만들 수 있었다. 전술의 패배 대신 전략의 승리를 얻은 건지..?

강대국이 식민 통치를 하는 것 자체는 합법이고 관행이던 제국주의 시절에도 "당신 일본은 식민지를 얼마나 개판으로 관리했으면 10년을 못 채우고 저런 대규모 항쟁이 전국에서 벌어졌냐? 그리고 그걸 또 그 따구 방식으로 겨우 진압했냐?"라는 질타가 들어왔을 정도였다. 그러니 조선 총독도 본토로부터 당연히 내리갈굼을 먹었다. -_-;;

그래도 3· 1 운동 같은 발악이 있었던 덕분인지 일본 내부에도 조선의 식민 통치를 반대하고 조선의 독립을 지지하는 소수의 일본인이 생겨났으며, 그 흐름이 지금까지 이어져서 자국의 만행을 사죄하는 사람들이 있다.
이거 마치 임진왜란 시절에 조선으로 귀순한 왜군 장수를 보는 듯한 느낌인데.. 이런 사람들이 제일 최근에 대대적으로 매스컴을 탄 건 2년 전, 2019년 2월경이다. (☞ 링크)

우와, 읽는 내가 눈물이 나려 한다. (반어법이 아님!)
저 사람들이 다른 사회· 정치 쪽으로 다른 이상한 운동에 연루돼 있지 않고, 신학 노선이 그리 이상한 곳도 아니라고 가정한다면, 난 저 사죄가 진심 레알임을 인정한다.

정치인들의 정식 사죄?? 바라지도 않는다. 사실 외교적으로는 우리나라는 이미 일본의 까임권을 다 써 버린 지 오래다. 그걸 아직도 우려먹는 게 비정상이고, 외교 신뢰를 깎아먹는 바보짓이다. (이제 더 논하지 않기로 약속하고 퉁쳤잖아! 그런데 이거 뭐 정권이 바뀔 때마다 말이 달라지니..)

정치인이 아니면 민간에서라도.. 저렇게 자기 나라 참전 때문에 남북 분단을 영구히 고착시켜 버린 것을 안타까워하고 미안해하는 대륙 사람이나 조선족이 어디 있나? 비열한 전쟁과 테러 공작에 대해서 진심으로 유감스러워하고 화해하고 싶어 하는 동족이 이북에 어디 있긴 하냐?
이러니 내가 종북이 친일보다 더 나쁘다고 논리적으로 정정당당하게 주장하는 거다.

저렇게 대표 기도를 한 '오야마 레이지'(尾山令仁)라는 목사는 나이가 이미 90을 넘은 고령인데..
행적이 정말 엄청난 분이더라. 제암리 학살에 대한 사죄와 추모를 50년 이상 전부터, 1965년 한일 수교가 최초로 이뤄졌던 시절부터 일평생을 바쳐 해 왔다!
1969년 4월 15일, 인류가 아직 달에도 가기 전이었던 시절의 중앙일보 보도를 보자. (☞ 링크)

오야마 이마히도(미산금인).. 저 사람 맞다. 령을 금이라고 표기한 건 종이 신문 OCR의 한자 판독 오류일 테고..
그는 진작부터 하나님께 나아오기 전에 니 형제와 화해부터 먼저 하라(마 5:23-24)는 말씀으로부터 깊은 부담을 느꼈고, 60년대부터 "일본은 히로시마· 나가사키를 기억하기 전에 제암리부터 먼저 기억해야 합니다"라고 주장했다. (☞ 링크)

"제암 교회 방화 사건 속죄 실행 위원회"라는 걸 만들어서 자국에서 성금을 1천만 원(50년 전 물가.. 책 한 권 가격이 백원대 단위이던 시절)을 모아서.. 제암리 교회를 재건하고 주민 의료 진료소까지 만들려고 했다...;;

감리교 교단에서는 이를 환영하고 동의했으나(오리지널 제암리 교회도 감리교였음).. 문제는 민심이었다.
제암리 학살 피해자 유족들은 "왜놈들의 더러운 돈으로 교회를 세우는 건 순국선열에 대한 모독이다. 죽어도 결사 반대!!" 이렇게 나오면서 성금 따위 한 푼도 안 받으려 했으며, 오야마 씨를 만나 주지도 않았다.

1960년대의 우리나라는 그야말로 반공과 반일이 가히 하늘을 찌를 기세였던 시절이다. 일가족이 몰살당했던 유족들의 저 까칠한 반응에 대해서도 후손인 우리 세대가 뭐라 할 수는 없다.
하지만 오야마 목사는 저런 냉대조차도 담담히 감내하면서 몇십 년을 한결같이.. 2019년까지도 "일본의 과거 침탈을 깊이 사죄합니다. 주여, 우리 일본인들을 용서해 주십시오." 이래 왔던 것이다. 한국, 일본 모두로부터 그다지 지지나 환영받지 못했는데도 말이다.

이 정도면 대인배만으로는 표현이 부족하고.. 예수쟁이로서 좀 거시기한 표현이긴 하지만.. 가히 보살 급이지 않은가..??
이 뿐만이 아니다. 쟤들은 무려 20년 전에 세상을 떠난 의사자 이 수현 씨를 아직도 기억하면서 매년 추모식을 연다.

JR 서일본(☞ 링크)은 2005년 후쿠치야마 선 탈선 사고에 대한 사죄와 반성 문구를 자사 홈페이지에다가 15년째.. 지금까지도 사실상 영구 박제 수준으로 걸어 놓고 있다. 이런 걸 보면 일본인의 근성에 참으로 놀라움을 느낀다.

오야마 이마히도 목사도 신학을 한 구체적인 배경은 잘 모르겠지만.. 한국인으로서 꼭 기억할 만한 양심적이고 훌륭한 일본인이라 하겠다. 얼마 안 있으면 소천해서 근황을 못 보게 될 수도 있다.

그럼 제암리 학살과 관련하여 다른 이야기 하나만 더 꺼내고 글을 맺겠다.
미국 독립 전쟁을 배경으로 20년 전 옛날 영화 '패트리어트'에서는 영국군 레드 코트들을 개 싸이코 악마 병신으로 묘사하기 위해, 어디서 본 건 있는지 제암리 학살 사건을 오마주 한 듯한 장면이 들어갔다.
니들이 식민지군 반역자들을 숨기고 있다는 죄목으로 주민들을 예배당 안에 한데 모아 놓고 문을 못질 하고 건물을 불지른 것.

하지만 영국군이 그런 잔학한 짓까지 실제로 한 적은 없었기 때문에 영국은 이 장면에서 언짢은 반응을 보였다고 한다.
심지어 제암리 학살조차도 여자, 아이들까지 다 예배당에다 가두고 문에 못질을 한 건 아니었다고 사료가 정정되고 있다. 키가 일정 수준 이상인 15세 이상 남자만 죽였다고.. 뭐 그것도 비무장 양민에 대한 반인륜적인 학살인 건 변하지 않지만 말이다.

심지어 그때 불타는 예배당 안에서 어떤 여인이 "제발 우리 아이만은 살려 주오"라고 담요에 둘러싸인 아기를 밖으로 내밀었는데 헌병들이 칼질을 했던가 총질을 했던가.. 그런 얘기까지 전해지는데.. 그것도 일단은 현실성을 의심해야 할 것 같다.;;

Posted by 사무엘

1. 2021년 상반기, 교통 분야의 변화

여의대로와 경인로 사이엔 길 중앙을 틀어막고 공사가 몇 년째 벌어지고 있었는데.. 공사가 끝난 깔끔한 모습을 본인은 며칠 전에야 드디어 처음으로 목격했다.
신안산선이나 GTX 같은 지하철 공사인가 막연히 생각했는데 그게 아니다. 여의도-신월 지하 유료 도로. 여의도와 경인 고속도로가 이렇게 곧장 연결되었다니 신기한 노릇이다.

그건 반가운 소식이지만, 정말 노이로제 걸릴 정도로 난무하는 변태 같은 시속 50, 50, 50, 50 소리 때문에 미치겠다. 시속 80~100은 밟아도 될 것 같은 멀쩡한 6~8차로 도로에서 이게 무슨 개짓거리냐?? 저 신월-여의 지하 도로 출입구에도 시속 50 단속 카메라가 붙어 있더라.

작년에 재난지원금 뿌려서 재정이 부족한 걸 이딴 식으로 회수하려 든다는 합리적인 의심이 든다.
정상적인 애매한 자동차들 속도를 찍어누르지 말고 악성 무단횡단자나 엄하게 처벌하면 도로가 훨씬 더 안전해질 것 같은데 말이다.
멀쩡한 대만 유학생을 죽게 한 음주운전 가해자놈한테는 솜방망이 처벌로 나라 망신이나 시키고.. 사법 분야는 영 마음에 안 든다.

뭐 그건 그렇고, 자동차뿐만 아니라 도시철도 쪽도..
서울 지하철 5호선의 동쪽 종점이 상일동에서 무려 몇십 년 만에 하남 검단산으로 바뀌었다.
공교롭게도 6호선은 봉화산, 7호선은 도봉산 이렇게 종점 근처에 산이 있었는데 5호선도 그 관행을 따르게 된 듯하다.

그 검단산 근처에 성남시에도 영장산과 망덕산 사이에 '검단산'이 있긴 하다. 하지만 성남 검단산은 두 산 사이에 끼여 있고 정상에 군부대도 있어서 접근성과 존재감이 하남 검단산보다는 훨씬 떨어진다. 굳이 '하남'을 붙일 필요는 없는데 왜 저렇게 작명을 했는지는 잘 모르겠다.

요즘 안 그래도 외국 여행을 못 가서 국내 여행과 등산이 젊은 사람들 사이에서도 각광 받고 있다는데, 나도 등산 다시 가 보고 싶네..
앞으로 신분당선 강남-신사 구간, 그리고 서울 동부의 29번 고속도로를 연결하는 한강 교량, 400번 제2순환 고속도로, 동해남부선 복선 전철, 경기도 GTX 등이 기대된다.

2. 프로그램 개발

보통 프로그램 개발 근황은 날개셋 카테고리에다가 올리는 편인데 이번에는 분량이 짧고 별 컨텐츠가 없기 때문에 여기에다가도 간단히 언급하고 넘어가겠다.

지난달에 나온 날개셋 한글 입력기 10.2는 외부 모듈의 동작 안정성과 프로그램 호환성이 크게 개선되었음을 당당하게 내세운 버전이었다. 실제로 한글과 비한글(조합과 비조합)을 섞어 가며 입력할 때 프로그램별로 자잘하게 발생하는 문제들은 이제 확실하게 해결됐다.

그래서 정말 답이 없는 Windows Terminal 요놈에 대한 인위 보정만 제외하면 나머지 수동 보정 옵션은 없어졌다.
사실은 MS IME조차도 이 프로그램에 대해서는 놀랍게도 일종의 보정을 해서 동작하고 있다(타 프로그램일 때와는 기능 수행 순서가 정반대). 무슨 기준으로 보정하는지를 알 길이 없어서 내 프로그램에서는 불가피하게 수동 보정으로 남겨 놨을 뿐이다.

하지만 크롬 브라우저에서는 여전히 그것도 버전업 될 때마다 계속해서 새로운 문제가 발생하고 있다. 한글을 입력하는 것 자체가 아니라 조합이 마우스 클릭 등 외부에 의해 강제 종료됐을 때의 처리가 영 원활하지 않다.
그리고 심지어 조합이 종료됐을 때 이전에 입력됐던 글자들이 무더기로 삽입되는 현상까지도 본인이 발견은 했지만.. 정확한 재연 조건을 도무지 모르겠다. 크롬과의 악연은 2년쯤 전인 2019년부터 지금까지 계속 이어지는 중이다. 어휴~~ㅠㅠㅠ

그것 말고도 제어판 대화상자를 DPI 설정이 다른 모니터로 옮겼을 때 내부 컨트롤 배치가 확 깨지는 문제를 버그 신고를 통해 발견해서 해결했고, 입력 도구와 대화상자 UI 곳곳에서 버그를 고치고 외형이나 동작을 자잘하게 고쳤다.
다음 버전은 일단은 6월애 내놓으려 하는데, 10.3이 될 수 있을지 그 이상이나 이하가 될지 잘 모르겠다.

3. 캠핑 노숙

요즘처럼 날씨가 좋을 땐 본인은 밤에 집에서 잠을 자지 않는다.
금요일 밤엔 자전거만 몰고 갈 수 있는 곳에 가고, 토요일 밤에는 차로 좀 가야 하는 곳에서 텐트를 친다. 이튿날 아침에 곧장 교회에 가기 위해 운전을 또 하니까 이게 합리적인 선택이다.

차로 간 곳은 충분히 외져서 인적이 전혀 없고 보안 걱정을 할 필요가 없었다.
하지만 자전거로 간 곳은 속세와 완전히 떨어지지는 않은 단순 공원 안에서 짱박힌 수준.. 그래서 한밤중이나 이른 아침에 산책을 하는 주변 사람들 눈에 가끔 띌 수도 있었다.
프로그래머로서 이런 건 hash값의 충돌과 비슷한 상황이라고 생각한다.;;;

가끔은 텐트 근처까지 누군가가 데리고 오는 개가 짖는 소리가 들리곤 한다. 물론 텐트는 창과 문을 다 닫았으니 보이지는 않고..
텐트 주변에 시시하게 겨우 개가 아니라 야생 멧돼지가 다가오는 날은 언제쯤 도래할지 모르겠다.

자연 속의 환상적인 내 개인 연구실 겸 침실을 놔두고.. 더워서 선풍기를 틀어야 하는 갑갑한 콘크리트 구조물에서 도대체 왜 자리요? 그건 무술 연마 없이 그냥 총 쏴서 사람을 제압하는 것과 같고, 등산 없이 그냥 헬기나 케이블카 타고 산을 오르는 것과 같다.

내게 집은 주민등록 근거지와 수도 전기의 보급, 씻기 등의 개인정비=_=, 책과 옷 등을 보관하는 창고 정도의 역할을 한다. 먹고 자는 곳은 아님. 처자식 없이 혼자 사는 동안 당분간은 계속 그럴 것 같다.
쓰레기 버리고 오존층 파괴하고 이산화탄소 농도 늘리는 것만 자연에 대한 비매너인 게 아니다. 이런 날 자연 속에서 밤을 보내지 않는 것도 자연에 대한 예의가 아니라는 것이 나의 신념이다.

한겨울은 엄청나게 춥다.
나야 추운 것 자체는 아주 땡큐이지만.. 이 때문에 추가 담요와 잠바 같은 방한 보온 장비가 많이 필요해져서 보행 시의 무게 부담(payload)이 증가하며, 이동 반경이 감소한다.
그리고 -10도 밑으로 내려가면 전자기기들도 잘 못 버틴다. 폰의 배터리가 일시적으로 곤두박질치거나 차의 스마트키가 버벅거릴 정도로..

여름이 되면 짐은 한결 가벼워진다. 더 멀리 이동 가능하고 간편하게 텐트 칠 수도 있다.
하지만 낮이 길고 이동에 부담이 없기 때문에 다른 사람들도 산이나 공원 내부의 더 깊숙한 곳까지 이른 시간부터 접근한다. 그렇기 때문에 보안이 상대적으로 떨어진다.

그리고 기온이 올라가면 야생에서는 벌레도 증가한다. 더워서 텐트 창문도 열어야 할 판인데 도대체 어디서 냄새를 맡았는지 모기 떼들이 5분 안으로 창문 방충망에 덕지덕지 달라붙는다.

이런 장단점을 감안하면..
적당히 추워서 최소한의 장비만으로 간단하게 보온이 되고, 산에 조금씩 초록색이 늘어 가고, 아직 모기도 들끓지 않는 지금이야말로 텐트 캠핑 노숙에 입문하기 최적의 시기라고 할 수 있다.

Posted by 사무엘

1. 압축 유틸

요즘은 Adobe Reader 같은 거 설치할 필요 없이 크롬이나 Edge 같은 브라우저만으로도 자체적으로 pdf 문서를 바로 열어 볼 수 있다.
압축 유틸리티에서 광학 디스크 이미지 파일의 내용을 바로 볼 수 있게 된 것과 비슷해 보인다. 한 분야의 프로그램이 비슷한 다른 분야의 프로그램의 역할을 일부 흡수해 버렸다.

물론 이미지 파일을 새로운 드라이브로 mount 시키는 것까지 압축 유틸이 지원하지는 않는다. 그것까지 지원하면 압축 유틸의 기능이 옛날 도스 시절의 Double Space 같은 디스크 압축 유틸 급으로 커지는데.. 요즘은 그런 기능이 필요할 정도로 디스크의 용량이 부족한 시절이 아니기 때문에 유행이 지났다. 그리고 결정적으로 드라이브 mount는 이제 운영체제(Windows 10)가 자체적으로 제공해 주는 기능으로 흡수되기도 했다;;

국내의 경우 20여 년 전, 이 바닥이 WinZip, WinRAR 같은 외국산 압축 유틸리티 일색이던 시절에 이스트소프트의 '알집'이 처음에 적절한 마케팅 덕분에 시장 선점을 잘 해서 폭발적인 인기를 누렸다. 그러나 버그· 안정성 문제에 적절히 대처하지 못해서 2000년대 말쯤에 컴덕들 사이에 욕을 엄청 먹었으며, 그 와중에 기업 대상 유료화까지 선언하는 바람에 입지를 더욱 잃게 됐다.

그 와중에 개인 개발자 1인의 작품인 '빵집'이 알집의 대체제로 각광 받아서 2000년대 후반에 큰 인기를 끌었다.. 하지만 빵집은 개발자의 개인 취미 생활이다 보니 유지보수에 한계가 있었고, 결국 개발이 중단되어 역사 속으로 사라졌다.
그리고 오늘날이야.. 그 틈새를 저격한 반디소프트의 '반디집'이 탁월한 완성도로 천하를 평정했다.

압축 유틸의 역사를 읽어 보노라면, 소프트웨어는 모름지기 수요와 타이밍, 시장 공략을 잘 해야겠다는 걸 느낀다.
zip은 압축 해제뿐만 아니라 생성까지 소스가 완전히 공개돼 있고 그 다음부터 7z, ace, rar 등 압축 알고리즘들의 압축률은 이론적인 정보량 한계에 근접해서 거기서 거기이다 보니.. 알고리즘은 zip 하나만 있으면 되고 그 뒤 멀티코어, 64비트, 유니코드, 기본적인 보안, 운영체제 셸과 잘 연계하는 UI...

이것만 제공되면 그 다음부터 굳이 유료 유틸을 쓸 필요가 크게 줄어드는 것 같다. 실제로 본인도 '-집' 계열 유틸을 사용하기 시작한 뒤부터는 Windows에서 zip 말고 rar 등 다른 압축 파일을 '생성'해 본 적이라고는 전혀 없는 것 같다.

2. 유튜브

(1) 유튜브 동영상에 광고가 5~10여 년 전에 비해 굉장히 많이 늘어난 게 느껴진다.
뭐, 쟤들도 흙 파서 먹고 사는 건 아닐 테니, 오랫동안 무료로 잔뜩 뿌리고 투자했던 것을 회수할 때가 됐다. 전세계에서 발생하는 천문학적인 수의 동영상들을 저장하고 전송 트래픽을 감당할.. 서버 유지비가 장난 아니게 깨질 것이며.. 몸값 비싼 엔지니어들을 고용하는 인건비도 상상을 초월할 것이다. 서버 관리자, 웹 UI 디자이너 및 개발자, 동영상 코덱 전문가, 동영상 컨텐츠들의 검색과 분류 알고리즘 전문가 등..

그러니 동영상 포털이 사용자에게 거부감을 제일 덜 주면서 수익을 내는 건 광고 또는 사용자에게 "광고 안 뜨는 기간제 유료 계정" 판매로 자연스럽게 귀착될 것이다. 나도 광고가 너무 잦아지니 잠시 동안만이라도 광고 없는 유튜브 프리미엄 유료 계정을 써 보고 싶다는 생각이 종종 든다. 유튜브도 사용자를 이렇게 적당히만 귀찮게 하는 걸 목표로 하지 싶다.

요즘 친구들끼리 생일 선물로 카카오톡으로 이모티콘이라든가 커피 상품권을 주고 받는 게 있다. 그런 것처럼 몇천 내지 1~2만원대의 유튜브 프리미엄 n개월 이용권이 온라인/모바일 생일 선물로 오가는 건 어떨까 싶다.

여담이지만, 유튜브뿐만 아니라 평소에 위키백과를 지식 습득용으로 유용하게 사용해 온 사람이라면 거기에도 후원금을 소액이나마 내는 게 좋을 것이다. 특정 기업의 입맛에 휘둘리지 않고 상업 광고도 없는 개방된 지식 저장소는 컴퓨터와 인터넷을 지금 같이 누구에게나 평등하고 투명하게 개방된 정보의 바다로 만드는 데 절대적인 기여를 했기 때문이다.

(2) 다음으로, 돈이나 광고와 별개로 본인이 요 근래에 유튜브에 대해서 느끼는 굉장히 큰 불만이 하나 있다.
HD급 이상의 무거운 고화질 동영상일수록 더 두드러지는 것 같은데.. 슬라이더에서 좌우 화살표를 눌러서 앞뒤 5초 남짓 단위로 seek를 한번 하는 데 걸리는 딜레이가 너무 길다는 것이다. 동일 화질 기준으로 그냥 하드에 저장된 동영상을 데스크톱용 플레이어 앱에서 seek하는 것만치 빨리 즉시는 절대 못 한다. 답답하지 않으신가?

옛날 저화질 동영상은 이렇지 않다. 이건 다운로드 자체는 이미 다 된 구간을 돌아다니는 것만 말한다. 그러니 네트워크 상태하고도 무관하다.
기술적인 한계 때문에 느린 건지 아니면 이것도 설마 현질 유도를 위해 고의로 들어간 핸디캡인지는 잘 모르겠다.

(3) 끝으로, 유튜브 유료 계정에 제공되는 서비스로는 광고 제거뿐만 아니라 동영상을 아예 로컬에다 다운로드하는 것도 있었다.
하지만 그건 별도의 서비스가 없더라도 뒷구멍을 통한 다운로드 서비스가 넘쳐나다 보니 유튜브에서도 단속을 포기한 것 같다. 별도의 앱이던 게 더 간편한 웹으로 바뀌기까지 하고 말이다. 사실 이건 기술적으로, 근본적으로 막을 수 있어 보이지는 않는다.

3. 이메일: 대용량 파일 첨부, 발송 확인 및 취소 기능

15년쯤 전에 구글 gmail이 최초로 1GB짜리 웹 기반 무료 이메일을 개설한 이래로 요즘은 어디건 이메일 서비스는 기본이고 용량이 기가바이트급이다. 하지만 이메일은 편지함 용량과 컴퓨터의 하드 용량이 증가한 것에 ‘비하면’, 무슨 영화 파일 급의 대용량 첨부 파일을 주고 받기에는 여전히 좀 버거운 수단이다. 기껏해야 수~수십 MB 정도가 한계?

초대용량 파일은 메일에다가 직접 붙이는 게 아니라 다른 클라우드/웹하드에다 올리고 나서 그거 링크만 메일에다 넣는 형태로 대체되는 게 요즘 추세이다.
수신 확인 및 오발신 취소 같은 것도 이메일의 정식 프로토콜/스펙에 규정된 기능이 아니라 각 웹메일 서비스 사이트에서 자기 계정간 이메일에 한해서만 제공되는 비표준 편의 기능인데.. 이것도 좀 표준으로 승격됐으면 하는 바람이 있다.

4. 크롬 브라우저로 네이버 블로그 첨부 파일 다운로드

크롬 브라우저로는 네이버 블로그 기반의 사이트에서 첨부 파일 다운로드가 잘 되지 않는 문제가 있다.
나만 겪는 현상인 줄 알았는데 아니었구나..

검색을 해 보니, 네이버 블로그는 https 기반인데 다운로드 링크는 보안이 취약한 http 기반이어서 크롬이 의심스럽다는 이유로 다운로드를 차단한 것이었다.
즉, 네트워크 구조에 문제가 있어서이지, 첨부 파일의 내용에 문제가 있어서가 아니었다.

이렇게 웹페이지의 구성요소에 https와 http가 뒤섞여 있으면 브라우저가 의심스럽고 불안하다고, 그래도 내용을 다 보고 싶냐고 온갖 귀찮은 확인 메시지를 사용자에게 띄운다. 다들 한 번쯤은 그 모습을 본 적이 있을 것이다.

그런데 크롬의 경우, 그 어떤 에러 메시지도 없이 그냥 일방적으로 네이버 블로그로부터의 다운로드를 씹어 버리니 당혹스러웠다. 은행 ActiveX도 아니고 파일 다운로드를 위해서 구닥다리 IE를 끄집어내는 촌극이 벌어지기도 했다.
뭐, 궁극적으로는 천하의 네이버가 이 문제를 해결하고 네트워크 구조를 불안 요소가 없게 어서 고쳤으면 좋겠다.

크롬은 이제 올해부터 플래시조차 지원을 완전히 끊었다. 아직도 메뉴가 플래시 기반인 웹사이트는 한 몇 년은 관리를 안 한 완전 구닥다리.. "1024*768 해상도에서 IE 6 브라우저에서 가장 잘 보입니다" 이러면서 제로보드 게시판까지 같이 붙어 있는 사이트일 가능성이 높을 것이다.
세월이 참 많이도 흘렀다. 플래시, 제로보드, Visual Basic 6, 재래식 hlp.. 이런 것들이 역사 속으로 사라졌다.

5. 마이너한 검색들

일반적으로 널리 쓰이는 기능은 아닐 테니 유료 서비스 형태로 제공되더라도..

(1) 많고 많은 웹툰들은 그림 파일뿐만 아니라 말풍선 안의 대사들도 색인화돼서 대사로 해당 컷의 검색이 됐으면 좋겠다.
짤방으로 써먹고 싶은데 그 그림이 긴 웹툰 시리즈의 어느 화에 있었는지 기억을 못 할 때가 많다.
물론 "이 학교의 주인은 이사장인 나예요."(사립정글고), "네놈을 살려 두긴 쌀이 아까워!"(이말년), "선 넘네"(엉덩국 애기공룡 둘리) 같은 거야 너무 강렬하고 유명하니 일반 검색 엔진으로도 대사와 컷 이미지가 개념적으로 연결돼 버렸지만.. 그렇지 않은 컷도 많다.

(2) 주선율 음표 표기로 음악 검색. 밖에서 재생되는 음원을 들려줘서 비슷한 음반의 노래를 찾는 건 이미 서비스 되는 게 있지만.. 그건 음원이 없고 사람의 오랜 기억 속에만 존재하는 음악을 찾아 주지는 못한다. 내가 말하는 건 음악들의 주선율 악보를 색인화해서 검색하는 것이다. 다만, 이걸로 검색하려면 사용자도 최소한의 채보· 기보 능력이 있어야 한다.

검색 엔진이란 게 처음에는 같은 웹에서 텍스트 위주로만 검색을 지원했다. 그러나 요즘은 웹뿐만 아니라 종이책, 잡지, 옛 신문들과 방송 자료, 논문 같은 오프라인 매체로 범위가 확장되었으며, 정보의 형태도 텍스트에 국한되지 않고 그림과 동영상까지 취급한다.

그러니 이게 앞으로는 텍스트뿐만 아니라 사람이 마우스로 얼추 끄적인 스케치와 비슷하게 생긴 그림이나 실제 로고타입을 찾아 주고, 콩나물 배열만으로 음악을 찾아 주는 경지에 도달하지 않을까 싶다. 그야말로 사람의 기억을 보조해 주는 도구가 되는 것이다. 그리고 국내 웹툰뿐만 아니라 과거의 뉴스 보도, 특히 대한뉴스들도 다 색인화되면 엄청난 도움이 될 것이다.

Posted by 사무엘

1. 동물 분류

내가 생물 분류에 대해 잘은 모르지만.. 생각보다 많은 동물들이 가축화된 에디션과 그렇지 않은 야생 에디션으로 나뉜다는 것이 꽤 흥미롭게 느껴진다.

• 집토끼 / 산토끼
  
• 소 / 들소, 물소
  
• 개 / 들개
  
• 말 / 야생마, 얼룩말
  
• 돼지 / 멧돼지
  
• 생쥐 / 들쥐

동물이건 식물이건, 인간에게 식량을 제공할 목적으로 사육/재배된 놈들은 오랜 세월 동안 이 용도로만 엄청나게 품종 개량이 진행됐다고 한다. 그래서 살코기나 열매는 크고 많이 산출하지만, 얘들은 거친 야생에서는 스스로 거의 생존하지 못한다고 한다.

후천적 획득 형질이 후세로 유전까지 되지는 않을 텐데 품종 개량이라는 게 동식물별로 어떻게 진행되는 것인지 개인적으로 궁금하다. 사실은 사람조차도 흑백황 인종이 어떻게 생겨났는지 궁금하다.

2. 익충과 해충

지렁이는 비록 생긴 건 좀 뱀처럼 혐오스럽지만 땅의 흙을 부드럽게 하고 지력을 회복시켜주기까지 해서 농사에 큰 도움을 준다. 쇠똥구리는 말 그대로 더러운 골칫거리인 소똥을 처리해 주면서 인간에게는 위생적으로 큰 문제를 끼치지는 않아서 이롭다.

그런데 자연 전체를 통틀어 인간에게 가장 큰 유익을 주고 있는 '곤충'은 꿀벌이다. 겨우 꿀 생산만 생각한다면 큰 오산이고, 얘는 꽃가루를 받아 줘서 충매화 식물들의 번식이 가능하게 한다.
이 역시 꼭 장미나 튤립 같은 꽃만 꽃이라고 생각하지는 마시길.. 야생에서 꿀벌의 이 역할과 효율 가성비는 인간의 과학 기술로 대체할 수 없다. 꿀벌이 싹 멸종하면 좀 과장 보태면 인간의 농업이 궤멸적인 타격을 입게 된다.

그러니 꿀벌은 비슷하게 집단 생활을 하고 근면의 상징으로 통용되는 개미보다 대접이 훨씬 더 좋다. 오죽했으면 꿀벌은 법적으로 가축으로 분류된 유일한 곤충이기도 하다.
이런 꿀벌과 달리, 인간을 지금까지 제일 많이 죽인 악랄한 해충은 모기이다. 이 역시 흡혈 자체 때문이 아니라 그 과정에서 말라리아 같은 다른 질병을 옮기기 때문이다. 빈대나 거머리도 흡혈을 하고 모기와는 다른 방식으로 악랄한 구석이 있지만, 이것들은 그래도 모기 정도의 치명적인 병을 옮기지는 않는다.;;

인간이 주변에서 접하는 수많은 해충들은 민폐를 끼치는 방식에 따라 대략 이런 식으로 분류가 가능할 것 같다.

• 비행 불가능하고 인간 거주지에 서식: 개미, 바퀴벌레
  
• 비행 가능하고 신체에 접촉: 파리, 모기
  
• 신체 표면에 기생: 벼룩, 빈대, 이, 진드기, 사면발이
  
• 신체 내부에까지 기생: 회충, 흡충, 촌충 따위

그나마 개미와 바퀴벌레는 한 개체를 잡아 죽이는 것 자체는 상대적으로 쉬운 축에 든다. 날아다니는 놈들은 때려잡기가 상당히 어려우며, 인체에 기생하는 너무 작은 놈들은 역시 그것대로 잡기가 어렵다. 신체의 털을 다 민다거나, 약을 먹고 바르는 식으로 제각기 다른 방법을 동원해야 한다.

그런데 떼거지로 날아다니면서 사람을 성가시게 하지만 그 이상으로 사람을 쏘거나 무는 식의 해를 끼치지는 않는 벌레들도 별도의 그룹으로 분류할 수 있을 것 같다. 깔따구, 하루살이, 그리고 어쩌면 날파리도?
얘들은 대체로 수명이 아주 짧으며 어인 일인지 입이 없거나 퇴화했다. 파리· 모기보다 잡기도 쉽다. 하지만 얘들은 여름철에 더러운 물웅덩이로부터 떼거지로 나타나서 주변을 산책하는 사람들에게 존재만으로도 큰 불쾌감을 선사한다. 주변 가게들은 영업을 못 할 지경이 된다.

요 몇 년 사이에 전국 각지에서 이런 벌레들이 너무 많이 창궐해서 난리라는 뉴스 보도를 종종 접한다. 저런 놈들뿐만 아니라 더러운 음식이나 시체에 붙는 날파리와 구더기, 여름에 모기 같은 것도.. 이놈들은 평소에 잠도 안 자고 어디에 숨어 있다가 밑도 끝도 없이 튀어나오는 걸까? 옛날 사람들이 생명 자연 발생설을 믿었던 게 일면 이해가 된다.
게다가 구더기가 파리의 유충이라는 것, 지렁이가 땅을 기름지게 한다는 것은 거의 19세기는 돼서야 발견된 사실이다. 지구가 둥글다는 것보다도 훨씬 더 늦게 알려졌다.

3. 동물이 만드는 보석

흑연과 다이아몬드가 탄소의 동소체인 것만큼이나 조개 껍질과 진주도 완전히 같은 탄산칼슘 물질일 뿐이라니.. 꽤 흥미롭다.
흑연과 다이아몬드는 경수와 중수 같은 동위원소 차이도 아니고 그냥 분자 배열이 다를 뿐이다. 하물며 조개 껍질 vs 진주는 차이가 그 만치 미시적인 것도 아니고 훨씬 더 더 가깝다고 한다.

그럼 다음으로 역시 보석을 만들어 내는 특이한 생물인 산호는 정체가 뭘까?
조개는 그래도 껍데기 안에 살이 있고 동물 같은 구석이 1만치는 느껴지지만 산호는..? 영 그래 보이지 않는다. 육지로 치면 버섯처럼 생긴 구석이 좀 있는데, 버섯은 균류이고 균류는 동물도 식물도 아닌 고유한 계(kingdom; 균계)로 분류되고 있다.

그러나 산호는 버섯과 달리 여전히 동물로 분류되어 있다. 체내의 세포 구조가 세포벽이 없는 형태에서 식물은 아니며 그렇다고 균류도 아니라 동물이라는 것이다. 단지 같이 공생하는 다른 식물 조류가 있을 뿐이라고..
산호도 진주처럼 주 성분은 탄산칼슘이다. 다이아몬드, 진주, 산호는 분명 보석이며 다이아몬드는 무기물 광물이기도 하지만, 금· 은 같은 귀금속에 속하지는 않을 것이다.

4. 외눈박이 동물?

사람을 비롯해 주변의 곤충, 동물들은 모두 눈이 두 개 달려 있다. 사고나 장애로 애꾸눈이 되더라도 그건 그 개체만의 문제이지, 안면에 눈알 2개의 자리 자체는 있다.
그런데, 아예 유전자 차원에서 눈이 하나만 달린 동물이 과연 있을까?

외눈박이는 굉장히 기괴하게 느껴지다 보니 도깨비라든가 게임 몬스터 따위의 특성으로 종종 묘사되었다. Doom 게임에서도 둥둥 떠다니는 카코데몬과 페인 엘리멘탈은 외눈이다.

Doom의 후속작인 Quake에서는 몬스터들이 눈이 아예 없고 입만 달린 형태인 것 같더라만.. 이것들은 다 인간의 창작물이다.
궁금해서 검색을 해 봤더니.. 현실에서는 최소한 척추동물 이상의 고등한 동물 중에 외눈박이는 존재하지 않는다. 신이 동물들에게 눈알은 두 짝씩 달아 주는 것을 디자인 원칙으로 삼으신 듯하다.

그 대신, 요각류, copepod라고 불리며 물에 살고 길이가 1~2mm급에 불과한 듣보잡 동물 중에는 외눈박이가 있다고 한다. 이런 것도 SF의 우주선과 현실의 우주선의 차이와 비슷한 걸까? 입이 없는 벌레만큼이나 무척 기괴한 놈이 아닐 수 없다.

5. 구제역

작년이야 전세계가 중공 염병 우한 폐렴 때문에 난리를 겪었고 그 여파가 아직도 가시지 않고 있지만..
지금으로부터 딱 10년 전, 2010년 말부터 11년 초 사이엔 사람이 아니라 돼지 때문에 전국이 발칵 뒤집혀 있었다. 그 이름도 유명한 구제역 때문에 말이다.

구제역 자체는 그 전에도 있었고 지금까지도 감기 유행처럼 찔끔찔끔 발생하고 있지만, 저 때만은 그야말로 0이 몇 개 더 붙은 전국구 수준의 궤멸적인 피해가 났었다. 살처분 보상금 기준으로 피해액이 다른 구제역은 수십~수백억 원이었지만 저 때는 조 단위였다.

이것도 초기 대응 실패로 인해 제주· 호남을 제외한 전국에 구제역이 확 퍼져 버렸고.. 그 자체가 감염자를 무조건 죽이는 에이즈 급의 병은 아님에도 불구하고 이렇다 할 치료법도 없다 보니 여러 정황상 그냥 닥치고 매몰 살처분 말고는 답이 없었다. 그 많은 가축을 대상으로 사회적 거리 두기를 시킬 수는 없으니..

지금이야 가축들에게 구제역 백신을 꼬박꼬박 시키고 있지 싶은데 저 때는 아직 그리하지 않던 시절이었다. 접종 비용도 비용이거니와, 백신은 미래의 예방제일 뿐 현재의 치료제가 아니므로 문제의 본질을 해결해 주는 물건이 아니고.. 또 한동안 구제역 청정국 지위를 반납하고 무역 같은 데서 불이익을 감수해야 하는 문제도 있었다.

치사율이 그리 높지는 않지만 치료법이 없고, 그냥 무식하게 모든 개체들을 몽땅 떼어 놓거나 죽일 수밖에 없으며, 전국에 궤멸적인 피해를 냈고 백신 접종이 뒤늦게 시작됐다는 점에서 10년 전의 가축 구제역과 지금의 우한 폐렴은 살짝 비슷한 구석이 있는 것 같다. 타겟이 가축이다가 지금은 어째 인간으로 바뀌었을까? 시사하는 바가 없지 않은 것 같다.

내 기억이 맞다면, 식당에서 먹는 삼겹살의 1인분 가격이 저 때 1만원 이상으로 오르고 나서 다시 내리지 않고 있다. 원래 8000원 정도 하다가 말이다.

6. 미스터리 괴물??

198~90년대에는 과학 기술의 발전과 세기말 분위기가 합쳐져서 UFO, 초능력 같은 불가사의 신비주의에 대해 사람들의 관심이 많이 쏠려 있었다. 이에 대해 기독교계에서는 물론 크게 경계하며 반발했다.
그 당시에 과학의 불가사의라는 건 여러 카테고리로 나뉘었는데, 그 중엔 예티라든가 빅풋 사스콰치(sasquatch) 같은 정체불명 이족보행 괴물 부류도 있었다.

사스콰치에게 납치됐다가 탈출했다는 어떤 사람의 회고에 따르면.. "산에서 캠핑 중이었는데 한밤중에 누군가가 저를 슬리핑 백째로 번쩍 들고 어디론가 가더랍니다" 영락없이 보쌈(...;;)을 당했다는 묘사도 있었다. 이게 내가 태어나서 처음으로 침낭이라는 물건을 접한 곳이었다.

허나, 서기 2000년을 넘어서 무려 2021년에 도달한 지금은..?? 불가사의니 신비주의니 하는 건 굳이 기독교계에서 반발하지 않아도 볼짱 다 봤고 거품이 알아서 사그라들었다. 상당수가 그냥 근거 없는 낚시나 사이비 유사과학이었기 때문이다.
버뮤다 삼각지대, 이집트 피라미드 무엇의 저주, 네스 호의 괴물, 히말라야 예티, 북아메리카 사스콰치 따위는 실체가 존재하지 않고 불가사의 미스터리가 아닌 것으로 판명됐다고 들었다. 마치 UFO처럼 말이다.

일례로, 요즘은 개인이 초고성능 스마트폰 카메라로 밤에 천체 사진까지 찍는 시대인데도 1980년대에 비해 UFO 사진이 올라오는 건 없다시피하다.
예티는 증거랍시고 전해지던 윗머리 가죽이라는 게.. 멀쩡한 기존 동물(야크)의 것으로 밝혀져서 신뢰도가 수직 추락했다. 이런 식이다.

저런 괴물이 존재한다면 이놈은 저그와 프로토스 중에 어느 쪽에 더 가까운지, 인간으로 진화 중인 유인원인지, 오스트랄로피테쿠스의 연장선인지 등 다양한 관찰과 연구가 가능했을 텐데 그런 일이 실제로 벌어지지는 않았다.
물론 옛날에는 지금처럼 지식과 정보, 개나 소나 인증샷 동영상들이 넘쳐나고 투명하게 공유된다거나.. 외국의 각종 괴담이나 미스터리들이 신속하게 검증되는 때가 아니었음을 감안할 필요가 있다.

1980년대엔 우리나라는 아직 외국 여행도 전면 자유화되지 못했었고, 무려 '유리 겔러' 아재가 염력(!!)으로 숟가락 구부리면서 마술사가 아닌 초능력자 행세를 하는 게 가능했다. 아기공룡 둘리가 "호이~ 호이" 거리면서 마법이 아니라 굳이 초능력을 구사한다고 주제가 가사에까지 묘사된 건 명백하게 그 당시의 사회적인 관심사가 반영됐던 설정이었다~! =_=;;

하지만 어린 시절에 예티에 대해서 읽었던 게 잠재의식 속에 남은 덕분에.. 훗날 퀘이크라는 게임에 나오는 제일 강한 몬스터인 섐블러(Shambler)는 뭔가 예티를 닮았다는 생각을 하게 됐다.
영화 킬 빌 1에서 '오렌 이시이'가 윗머리 가죽이 뎅겅 잘리면서 죽는 장면에서도 예티의 윗머리 가죽이 떠오르고 말이다..;; 예티의 존재감이 강렬했던 것 같다.

Posted by 사무엘

내가 ‘고혈압’이라는 단어를 태어나서 최초로 접한 곳이 방 정환 위인전이었다.; 이분은 어린이를 사랑한 인물답게 입맛과 식성도 초딩 스타일이었던가 보다. 담배도 골초였고..
그는 비만, 고혈압 같은 성인병을 낀 채로(아마 당뇨도?) 엄청난 스트레스와 과로에 시달려다가 겨우 30대 초반의 나이로 동화 구연 중에 코피 흘리면서 쓰러지고 절명했다.

옛날에 부실한 영양과 위생 때문에 결핵에 걸려 요절한 사람도 있었더라만(예: 날자꾸나 이 상, 수학자 닐스 아벨 등..), 방 정환은 그 시절 트렌드와 달리, 현대인과 굉장히 비슷한 방식으로 돌연사했다. 몸을 혹사시키며 자기 인생을 아이들을 위해 갈아 넣었다.

이 사람은 살아 생전에 동화 구연을 어찌나 리얼하게 잘했는지.. 감시하던 일제 헌병, 형사, 형무소 간수들조차 듣다가 자기도 모르게 훌쩍거리며 울었다. 가령, 주인공이 병으로 가련하고 불쌍하게 죽는 장면 같은 데서 말이다.

요즘 관점에서 보면 그냥 유치하고 오글거리는 신파극처럼 보이겠지만 저 때는 현대의 초딩 꼬마들이 상식 수준으로 접하는 외국 동화들도 이제 막 번역되고 국내에 소개되던 시절이었다. 유흥이고 문화 생활이고가 없던 재미없는 시절에 이런 참신한 신문물을 약간만 각색을 해 주면 어른 아이 할 것 없이 울리고 웃기는 게 가능했다.

뭐, 그런 시대 상황을 감안한다 하더라도 방 정환의 화술은 요즘으로 치면 어지간한 TV 코미디언을 능가하는 구석이 있었다.
오죽했으면 따라 붙던 일본인 형사조차도 “이 아재는 조센징이 아니라 일본인이었으면 한낱 나 같은 일개 짭새한테 쫓기는 처지가 되지 않고 저 실력으로 훨씬 더 성공했을 텐데” 안타까워했을 정도였다.

이렇듯, 1920년대의 한반도는 방 정환처럼 “어린이를 인격적으로 대해 줍시다”라는 파격적인 주장을 하는 사람도 나오고, 커리어우먼 신여성도 나오고, 좌익 사회주의 문학도 나올 정도로.. 일제 시대 중에서는 ‘그나마’ 자유롭고 개방되고 살기 좋던 시절이었다. 이것도 감안할 점이다.

사람이 죽을 때가 되면 정말로 저 정도로 평소에 안 보이던 헛것이 보이고 헛것이 들리게 될까? 난 어린 시절에 어린이를 그렇게 사랑했다는 사람이 저런 유언을 남겼다는 걸 읽고서 꽤 섬뜩한 느낌이 들었다.

나는 수명이 다해서 눈을 감을 때쯤 철길에 놓인 새마을호 전후동력형 디젤 동차가 눈앞에 짠~ 나타나 보이고 Looking for you가 하늘에서 어렴풋이 들려 온다면.. “아 내가 그래도 확실하게 구원은 받은 게 맞구나~!”하면서 평안하게 최후를 맞이할 수 있을 것 같다.
그게 아니라 산 채로 들려 올라간다면, 딩동댕~ 새마을호 로고송이 들려오지 싶다. (영상음악 컴필레이션 음반인 Headline News, 6번 트랙 Outlook)

아아~! Looking for you는 정말.. 천국 음악이었다.
내 인생은 경부선 새마을호이다. 요르단 강을 건너는 게 아니라 한강을 건너는 거다. 벌써 용산, 남영을 지났고 인생의 종착역인 서울역이 얼마 안 남았다~! 이제 로고쏭과 Looking for you가 객실에 흘러나올 일만 남았다.

현장에서 더 들을 수 없는 음악을 하늘나라에서 또 듣게 되기를 간절히 소망한다.
새마을호에서 이것도 안 들어 본 주제에 무슨 천국 갔다 온 간증..?? 체험담..?? 일고의 가치도 없다.
오늘도 철도님을 사랑합니다.

Posted by 사무엘

1. 초크 밸브

요즘은 트럭이나 버스가 아닌 승용차 차급에서 수동 변속기라는 게 사실상 전멸했다 보니, 어지간한 일반인 운전자들은 면허를 딴 뒤부터 클러치 페달이라는 걸 밟은 경험이나 기억이 전혀에 가깝게 없다.

오르막을 출발할 때의 떨림 찾기, 반클러치, 시동 꺼뜨림, 반대로 배터리가 나갔을 때 밀어서 시동 걸기.. 이런 것들을 모르는 사람이 주류가 되고 있다. 그러니 수동 차량은 대리 운전을 시키거나 중고로 파는 게 갈수록 난감해져 간다.
그래도 수동 변속기는 대형 상용차가 있기 때문에 완전히 멸종할 일은 없다. 쟤도 마치 에어 브레이크만큼이나 대형차만의 전유물이 될지도 모르겠다.

그런데, 운전과 관련하여 지금은 완전히 멸종했고 수동 변속기보다도 더 하드코어한 과거 유물은.. 초크 밸브이지 싶다.
연료 분사가 지금처럼 전자화· 자동화되기 전, 원시적인 카뷰레터(기화기)가 쓰이던 시절엔 연료 분사량을 조절하는 악셀 페달과는 별개로 공기 주입량을 조절하는 밸브도 운전석에서 수동 조작 가능한 기기 형태로 존재했다.

엔진의 출력이라는 함수값은 단순한 1변수이지만, 내연기관은 연료뿐만 아니라 공기까지 감안해서 동작하는 2변수 함수이기 때문이다. 비행기가 공중에서 선회를 위해서 자동차처럼 단순히 핸들을 꺾는 게 아니라 pitch와 roll이라는 2축, 2변수를 조절하는 것처럼 말이다.

추운 겨울에 디젤 엔진에다 시동을 걸 때는 초크 밸브를 이용해서 공기를 더 불어넣어 줘야 했다. 그리고 반대로, 공기를 수동으로 차단하지 않으면.. 지금으로서는 믿어지지 않지만, 키를 뽑는다고 해서 엔진 시동이 즉각 꺼지지도 않았다고 한다.

가파른 내리막에서 저단+높은 rpm 상태로 엔진 브레이크가 걸렸을 때 연료 공급이 차단되는 fuel cut도 없고.. 이 정도로 공기 공급과 연료 공급이 서로 맞물려서 효율적으로 통제되지 않으니 엔진 출력 대비 불완전 연소 매연과 그을음(특히 디젤)이 심하며 연비도 요즘 자동차보다 훨씬 더 나빴다.

초크 밸브까지 적절히 활용해야 하던 포니 같은 승용차는 운전하는 난이도와 느낌이 어떠했는지 궁금하다.
컴퓨터 프로그래밍으로 치면 암울하던 16비트 시절에 HMODULE과 HINSTANCE라든가 원거리 근거리 포인터 구분 등.. 지금은 신경쓸 필요가 없는 별 복잡한 요소들을 구분하고 따로 취급해야 했던 것과 비슷해 보인다.

이런 번거로운 기기는 전자식 연료 분사 기술이 도입되면서, 아니 그 전에 카뷰레터 자체도 기계식에서 전자식으로 바뀌면서 사라졌다. 1980년대 중후반에 완전히 사라졌다는 점에서 버스 안내양이나 항공 기관사와 시기가 비슷하다.
그래도 이 정도로 옛날 차는 요즘 차에 비해 침수(!!)나 저질 연료에 강하고 엔진음이 더 터프하고 웅장(?)하고, 악셀을 밟았을 때 밟은 대로 튀어나가는 반응성 하나는 좋았다고 한다.

2. 휠

옛날에는 자동차 타이어에 장착된 휠이라는 게 완전히 희거나 검은 표면이 있고, 중심부와 가장자리에 동그란 구멍이 숭숭 뚫려 있어서 마치 사람 얼굴처럼 보였다. 중심부의 동그란 원은 입, 휠너트는 콧구멍, 휠너트 주변의 돌출된 부위는 뽈살(!!), 그리고 제일 바깥쪽에 숭숭 난 동그라미들은 눈...;;;

요런 식으로 말이다.
그에 비해 요즘 승용차들의 휠은 굵직한 스포크 몇 개가 전부이고 나머지 부위는 다 뚫려 있어서 안쪽의 디스크 브레이크 패드가 다 보일 정도이다. 그리고 옛날 휠에 달리, 은색의 반들반들한 광택이 난다.
옛날 방식의 전통적인 휠은 트럭· 버스 같은 상용차에서나 볼 수 있다.

난 이게 단순히 디자인 트렌드의 차이인 줄 알았는데 그렇지 않더라. 재질부터가 다르다. 옛날 휠은 철제(스틸)인 반면, 나머지 더 뽀대나는 휠은 알루미늄 재질이다.
옛날에는 외곽의 '눈' 부위가 저렇게 아주 납작해서 눈을 흐리멍덩하게 떴다거나 우는 듯한 모습인 것도 있었지만, 원래는 모든 구멍을 그냥 원 모양으로만 뚫은 게 기본이다.

그래서 어떤 자동차에서 아무 옵션도 장착하지 않은 제일 저렴한 사양에 최하위 모델은 휠이 요런 모양이었다. 아니면 같은 차종이라도 자가용 말고 택시의 휠 역시 요런 편... ^^
조금 상위 모델로 가면 저기에다가 껍데기 하나 씌워 주는 게 관행이었다. 스틸 휠의 단조롭고 추레한 외형에 좀 변화를 주도록 말이다. 옛날엔 고속버스 타이어 휠에 반들반들한 휠캡이 따로 달렸던 것처럼..

그랬는데 요즘은 "철제 휠 + 휠캡 껍데기" 관행이 사라지고 알루미늄 휠이 대세가 된 듯하다.
그렇다고 가느다란 스포크가 수십 개씩 박힌 건 내구성이 약해서 그런지 자전거나 리어카 타이어의 휠에서나 볼 수 있고..
이런 것도 변화라면 변화라고 하겠다.

3. 엔진음과 동력원

(1) 요즘은 길거리를 달리는 자동차에서도 일반적인 부르릉이 아니라 전기 기관차 같은 조용한 웨에엥~ 전자음이 많이 들리기 시작해서 기분이 묘하다. 소형차에서 카르릉~ 디젤 엔진 소리가 나는 것 이상으로 이색적이다. 하이브리드, 배터리 전기, 수소 연료전지 같은 변종들이 갈수록 늘고 있긴 하다. 전기차는 내연 기관 같은 냉각 계통이 필요하지 않으니, 이런 차는 앞에 라디에이터 그릴도 없다.

(2) 그리고 요즘은 쬐끄만 소형 스쿠터(발을 한데 모을 수 있는..)들도 예전 같은 하이톤 앵앵앵 대신, 일반 오토바이와 동일한 부르릉 털털털 소리가 난다. 신기하지 않은가? 이제 이륜차도 내연기관형은 다들 2행정이 아닌 4행정 엔진을 쓰기 때문이다. 아니면 덩치 작은 놈은 아예 전기 모터로 바뀌고 말이다.

2행정은 구조가 간단하고 배기량 대비 더 큰 출력이 나지만, 엔진 내구도와 환경면에서 4행정보다 불리하다. 이제 소형 2행정 엔진은 교통수단이 아니라 제초· 제설 장비 정도에서나 볼 수 있다. 휴대용 엔진 발전기조차도 휘발유, 디젤, 터빈 등 다양한 엔진이 쓰이지만 2행정은 아니기 때문이다.

(3) 하지만 군용차라든가 대형 버스나 트레일러는 저런 트렌드를 다 씹어먹고 여전히 디젤이 본좌다. 제아무리 깨끗하고 다재다능한 전기 에너지라 해도, 말통에다가 석유 담듯이 많은 양을 화학적으로 곱게 축적하는 효율은 인류의 과학 기술로는 아직 메롱이기 때문이다.;;

그러니 전기 에너지는 실시간으로 생산과 소비를 동시에 하는 형태를 벗어나지 못해 있으며, 그나마 연료 전지는 배터리와 엔진의 중간 위상인 타협안이다. 현대차에서 열심히 연구· 노력한 덕분에 수소 연료전지 정도가 승용차 레벨을 벗어나 대형차 버전까지 만들어져 있다.

(4) 그리고 EQ900, 롤스로이스 같은 초호화 기함급 승용차들도 역시.. 하이브리드고 디젤이고 전기고 다 필요 없고, 안정성이 검증된 땡 휘발유 다기통 대용량 엔진이 사용되는 중이다. 부유하고 높으신 분들이야 길바닥에 돈을 줄줄 흘리고 다녀도 걱정할 게 없기도 하니.. 디젤과는 반대편 극단에 속한 분야라 하겠다.

Posted by 사무엘

군대라는 곳은 규율, 질서, ‘절도 있음’을 강조하는 집단이다. 그래서 외형적으로 무엇이든 구부리지 않고 ‘각 잡는 걸’ 아주 좋아하는 경향이 있다. 하지만 일부 관행은 비록 폼 나고 멋있어 보일지는 모르지만, 전투력과는 별 관계 없으면서 쓸데없이 삽질스러운 똥군기에 가까워 보이기도 한다.

1. 직각 식사와 거위걸음

위의 둘은 그야말로 군대· 군인의 상징이다만.. 실제로 해 보면 엄청나게 힘들고 부자연스럽고 불편한다. 현직 군인이라도 일상적으로 시행하는 건 무리이다.
한국군의 경우 쌍팔년도 급의 먼 옛날에는 심지어 병들에게도 싸제물 빼기의 일환으로 훈련소에서 직각 식사를 시켰다고 한다. 하지만 현재는 부사관들조차 그냥 패스이고, 저건 최정예 사관학교 생도만의 한 달 남짓한 통과의례로 존재감이 많이 축소된 듯하다.

다음으로 거위걸음은 걷거나 달릴 때 무릎을 굽히지 않으면서 걷는 동작을 말한다. 그러면서도 매 걸음마다 다리를 반쯤 발차기 하듯이 고각으로 드는 게 포인트다. 팔은 반대로 자연스럽게 흔들지 말고 차렷 자세이거나 소총을 파지하거나, 아니면 거수경례 자세를 유지한다. 시선은 정면이 아니면 측면에서 이 행군을 관전하는 최고존엄-_-이나 지휘관을 향한다.

이걸 수백· 수천 명의 병사들이 동시에 똑같이 수행하면 굉장히 웅장하고 위압감이 느껴지는 게 사실이다.
하지만 직각 식사로도 모자라서 거위걸음 행군은.. 자유 진영 민주주의 국가보다는 과거에 전체주의 군국주의가 강한 나라 내지.. 오늘날의 북괴· 중국 같은 공산권 국가의 관행이라는 느낌이 든다. 마치 카드섹션 매스게임처럼 말이다.
라이온 킹 Be prepared 노래에서 하이에나 떼거지들의 행군 장면도 생각해 보시길..

총검술이야 냉병기 쓰던 옛날 군대 전술에서 유래되었지만, 저런 직각 식사나 거위걸음은 의외로 머스킷+전열보병 급의 옛날 군대하고도, 격투기 무술하고도 아무 관계가 없다. 우리가 흔히 생각하는 중국 무술이나 일본 닌자 어쌔신 같은 것도 사실 19세기 말에야 정립됐듯이, 저 둘도 그에 준하는 비슷한 시기에 서양에서 처음으로 등장했다. 흑백 카메라 내지 후장식 총기의 등장 시기와 비슷하다.

2. 거수경례

군인은 각 잡는 차원에서 평상시에 고개조차 함부로 숙이지 않는다. 그래서 평범한 인사 대신 거수경례가 관행이 돼 있다. 뭐, 나치식 경례도 나쁘지는 않지만 이제는 영구봉인 돼 버렸고..
여느 격투기 스포츠라면 대련 전에 상대방에게 인사 정도는 아무 제약 없이 고개를 선뜻 숙이며 한다는 걸 생각해 보자. 그런 데서 거수경례를 하지는 않는다.
그리고 군대라고 해도 해군은 좁은 배의 복도에서 그 정도 팔 뻗을 공간도 없을 수 있기 때문에 경례를 더 약식으로 한다고는 한다.

고개를 숙이지 않는 경례 자세는 뭐 똥군기라고 볼 수는 없을 것이다.
심지어 성경에는 야전에서 얕은 개울물을 마실 때 경계하는 자세로 손으로 떠서 마신 사람 vs 그렇지 않고 팍 엎드려서 입을 수면에다 대고 벌컥벌컥 마신 사람을 갖고 군인 자질을 평가한 대목이 있다(삿 7:5-6). 그 유명한 기드온의 300 용사가 이 기준으로 선발되었다는 것도 진지하게 생각할 점이다.

한편, 단재 신 채호 선생은 세수할 때도 고개를 안 숙여서 옷을 다 적셨다고 한다. 그건 개인적인 다른 신념 때문에 그리한 것이지, 군사적인 각진 멋을 추구했기 때문은.. 아니다. -_-;;

3. 불침번

인간이 만든 거의 모든 건물이나 시설에는 24시간 상주하는 경비원이 있다. 이는 군대도 예외가 아니다. 물론 사람은 잠을 자야 하니 24시간 경비를 서려면 2명 이상이 교대 근무를 해야 한다.
또한 건물이 아니더라도 여러 사람이 언제 무슨 일이 터질지 모르는 위험한 오지로(폭우, 들짐승 등..) 야영이라도 갔다면 아무래도 교대로 불침번을 서야 한다.

이런 이유로 인해 군대에는 위병소나 GOP 같은 곳의 외부 경계 근무와 별도로, 병사들이 지내는 생활관(내무반) 내부에서도 일정 주기로 불침번을 운용하고 있다. 이건 직각 식사나 거위걸음처럼 멋이나 간지는 전혀 없으면서 군생활의 스트레스와 난이도를 크게 올리는 주범이다.

군인들은 군대 일과표 상으로는 밤 10시부터 아침 6시까지 8시간 수면이 보장돼 있지만.. 며칠이 멀다 하고 돌아오는 불침번 때문에 실질적으로는 수시로 중간에 잠을 깨야 해서 거의 절반 남짓밖에 못 자기 때문이다.
이건 뭐 완전한 근무도 아니면서 휴식도 아니고.. 그렇다고 회식 같은 것도 아닌 이상한 관행이다. 안 그래도 군인 병은 마치 시내버스의 안전벨트 열외만큼이나 근로기준법에서 열외되어(최저임금..) 착취 당하고 있는데 불침번은 열정페이 착취의 최고 정점이 아닐까 한다.

심지어 과거에는 군 병원에서 병사 환자들을 대상으로도 형식적인 불침번을 세웠다고 한다. 이건 불침번이 가능한 환자와 그렇지 않은 환자를 가르는 기준부터가 명확하지 않고 그냥 부조리 그 이상도 이하도 아니라고 여겨진다. 별 이유 없이 쫄병은 언제 어디서든 편하게 풀어진 채 그냥 놔둬서는 안 된다는 탁상행정에서 유래된 부조리이다. 질병이야말로 푹 자고 푹 쉬어야 빨리 낫는다는 게 기본 상식 아닌가?

내가 알기로 해군과 공군은 불침번 같은 거 없다. 마치 직각 식사라든가 심지어 수류탄(!!)처럼.. 훈련소 시절에만 잠깐 체험하고 그걸로 끝이다. 국군도 더 근대화 현대화되면 무식한 의지드립 강요 똥군기에서 벗어나서 내부 관행들이 더 합리적으로 바뀌어야 할 것이다. 생활관 내부를 24시간 제대로 지키고 싶으면 밤에 정식으로 당직병을 두고, 이튿날 아침에 온전한 근무 취침을 보장해 줘야 할 것이다.

불침번 교대자를 보면 컴퓨터의 연결 리스트 자료구조를 보는 것 같다.

Posted by 사무엘

1. make, build

요즘 소프트웨어라는 건 여러 개의 실행 파일들로 구성되고, 그 각각의 실행 파일들도 수십~수백 개에 달하는 소스 코드들로 구성된다. 이를 빌드하려면 단순 배치 파일이나 스크립트 수준으로는 감당하기 어려울 정도로 많은 옵션과 입력 파일 리스트들을 컴파일러 및 링커에다가 일일이 전해 줘야 한다. 기존 소스 코드들을 빌드하는 시나리오를 짜는 것조차도 일종의 프로그래밍처럼 된다.

그래서 이런 빌드 시나리오를 기술하는 파일을 makefile이라고 하며, 이 시나리오대로 컴파일러와 링커를 호출해서 빌드를 수행해 주는 별도의 유틸리티가 make라는 이름으로 따로 존재한다. 얘는 이전 빌드 때 만들어져 있는 obj 파일과 소스 파일과의 날짜를 비교해서 새로 바뀐 파일만 다시 컴파일 하는 정도의 지능도 갖추고 있다.
그리고 이름이 저렇게 고정 불변이며, 한 디렉터리에 하나씩만 존재하는 것으로 여겨진다. 프로젝트는 디렉터리별로 독립적이므로..

그런데 소스 말고 헤더 파일은? 조금 어렵다. 이게 수정되면 역으로 얘를 인클루드 하는 소스 파일들도 재컴파일이 돼야 하는데, make 유틸이 C/C++ 컴파일러나 전처리기는 아닌지라, 그걸 자동으로 파악하지는 못한다. 이건 makefile 스크립트 내부에서 각 소스별 헤더 파일 의존성을 사람이 수동으로 지정해 줘야 한다. 이를 기술하는 문법이 따로 있다.
이건 매번 풀 빌드 명령을 내리는 것보다 분명 편리하지만 그래도 사람이 의존성을 잘못 지정할 경우 빌드가 꼬일 수 있는 잠재적 위험 요인이다.

이렇듯 C/C++ 공부 좀 해서 본격적인 프로그램을 개발하거나 기존 제품을 유지 보수하려면, 언어 자체 말고도 다른 툴이나 스크립트를 알아야 할 것이 이것저것 생긴다. 이 바닥도 체계가 정말 복잡하기 때문에, 잘 모르는 사람은 말 그대로 소스까지 다 차려 놓은 오픈소스 프로젝트를 멀쩡히 받아 놓고도 빌드를 못 해서 돌려보지 못하곤 한다. 최소한 Visual C++ 솔루션 파일 하나 달랑 열어 놓고 F7만 누르면 바로 짠~ 빌드 되는 물건은 아니기 때문이다.

물론 그런 복잡한 시스템들은 훨씬 더 복잡한 상황을 간편하게 제어하고 관리하고 프로세스를 자동화하기 위해 도입되었겠지만.. 그마저도 초보 입문자에게는 쉬운 개념이 아니다.
Visual Studio 같은 개발툴들이 그런 make 절차를 얼마나 단순화시키고 프로그램 개발을 수월하게 만들어 줬는지 짐작이 된다. 당장 include 의존성을 자동으로 파악하는 것만 해도 말이다.

이런 개발툴 덕분에 프로그래머가 makefile 스크립트를 일일이 건드려야 할 일이 없어졌다. makefile은 해당 개발툴이 읽고 쓰는 프로젝트 파일로 대체됐으며, 얘는 비록 텍스트 포맷이긴 하지만 사람이 수동으로 편집해야 할 일은 거의 없다. 한때는 포맷이 제각각이었는데 요즘은 xcode건 비주얼이건.. 껍데기는 XML 형태인 것이 대세가 됐다. 스크립트라기보다는 설정 데이터 파일에 더 가까워진 셈이다.

Visual C++도 지금 같은 번듯한 IDE가 갖춰진 버전은 적어도 1995년의 4.0이다. 그때의 IDE 이름은 Developer Studio이었다. 이 시절에는 얘도 IDE와 별개로 유닉스 유틸과 비슷한 스타일의 make를 따로 갖추고 있었으며, 프로젝트 파일로부터 make 스크립트를 export해 주는 기능도 갖추고 있었다. 그러나 그 기능은 후대의 버전에서 곧 없어졌다. 명령 프롬프트로 빌드를 하는 건 그냥 IDE 실행 파일의 기능으로 흡수되었다.

2. cmake

유명한 대규모 크로스 플랫폼 오픈소스 프로젝트를 받아 보면 분명 Windows를 지원하고 Visual C++로 빌드도 가능하다고 명시돼 있는데, 그 빌드라는 게 내가 생각하고 이해 가능한 방식으로 행해지는 건 아닌 경우가 있다.
한때 직장에서 이미지 처리와 인식 때문에 OpenCV며 Tesseract며 머신러닝 라이브러리까지 C/C++에서 돌리겠답시고 삽질을 좀 한 적이 있었는데.. 이때 이런 식으로 지금까지 듣도 보도 못했던 프로젝트 구조와 빌드 방식 때문에 식겁을 하곤 했다.

압축을 풀거나 git으로 생성된 저장소를 아무리 들여다봐도 sln, vcxproj 같은 파일은 보이지 않는다. 먼저 MinGW에다 cmake 같은 유닉스 냄새가 풍기는 런타임을 설치해야 한다. 그래서 cmake를 돌리고 나면 자기 혼자 무슨 라이브러리 같은 걸 한참을 받더니 그제서야 디렉터리 한구석에 Visual C++용 솔루션과 프로젝트 파일이 생긴다.

소스를 사용자 자리에서 일일이 빌드해서 쓰는 것도 모자라서 빌드 스크립트 자체도 사용자 자리에서 즉석에서 동적 생성되는 모양이다. 흠..;
그 생성된 솔루션 파일을 Visual C++에서 열어서 빌드를 해 보면.. 비록 컴파일러는 마소 것을 쓰더라도 소스 파일이 선택되고 빌드되는 방식은 절대로 Visual C++ IDE의 통상적인 스타일대로 진행되는 게 아니다.

솔루션/클래스 view에는 아무것도 뜨는 게 없으며, 빌드되는 파일을 열어도 인텔리센스 따위 나오는 게 없다. 이 상태로 Visual C++ IDE에서 곧장 코드를 읽으면서 편집할 수 있지 않다. IDE에서는 그냥 debug/release나 win32/x64 같은 configuration을 변경하고 빌드 명령만 내릴 수 있을 뿐이다.

이런 프로젝트는 Visual Studio도 반드시 거기서 쓰라고 하는 버전만 써야 한다. 가령, 2017을 쓰라고 했으면 IDE까지 꼭 2017을 깔아야 한다. 2019에다가 컴파일러 툴킷만 2017을 설치하는 식으로는 안 통한다. 도대체 프로젝트를 어떻게 꾸며야 이런 빌드 환경이 만들어지는지 나로서는 알 길이 없다.

알고 보니 얘는 프로젝트의 Configuration type이 Utility 내지 Makefile로 잡혀 있었다. Visual C++에서 빌드되는 일반적인 프로젝트라면 저건 EXE, DLL, static library 중 하나로 지정하는 속성인데, 그런 것으로 지정돼 있지 않다.

그렇기 때문에 이 프로젝트에서 Visual Studio IDE는 그냥 명령줄을 실행해 주는 셔틀 역할밖에 안 한다. Visual C++ 컴파일러가 호출되는 것도 IDE가 원래 동작하는 방식으로 호출되는 게 아니다. 세상에 C/C++ 프로젝트를 이런 식으로 만들 수도 있다는 것을 어렴풋이 경험하게 됐다.

요컨대 cmake는 기존 make 툴의 또 상위 계층이며, 얘만으로도 기능이 굉장히 많고 덩치가 큰 프로그램이다. qt가 소스 레벨 차원에서 Windows와 리눅스와 맥을 모두 지원하는 범용 GUI 프레임워크로 유명하다면, cmake는 범용 빌드 시스템 관리자인 셈이다. qt를 기반으로 개발되는 GUI 앱의 프로젝트를 cmake 기반으로 만들면 진짜로 한 소스와 한 프로젝트로 Visual C++과 xcode와.. 음 리눅스용 IDE는 뭔지 모르겠지만 아무튼 진정한 크로스플랫폼 프로그램을 개발하고 관리할 수 있을 것으로 보인다.

맥OS야 요즘은 다 유닉스 스타일의 터미널을 갖추고 있으니 빌드 내지 패키지 관리 툴이 Windows보다는 이질감이 덜하다. 그러나 맥도 리눅스와 완전히 동일하게 호환되는 건 아니라는 건 감안할 필요가 있다.
그나저나 같은 x64 환경이면 GUI 말고 a.out급의 명령 프롬프트 실행 파일은 리눅스와 맥이 바이너리 차원에서 호환되나?? 아마 그렇지는 않지 싶다.

3. Source Insight

Source Insight라고 프로그래밍 및 소프트웨어 개발로 먹고 사는 사람이라면 다들 알 만한 유명한 개발툴이 있다. 단순 텍스트 에디터보다는 코드 구조 분석과 심벌 조회 기능이 훨씬 더 정교하게 갖춰져 있지만, 그렇다고 Visual Studio 같은 급으로 특정 플랫폼용 컴파일러나 디버거와 밀접하게 연결돼 있는 IDE도 아니다. 위상이 둘의 중간쯤에 속하는 독특한 물건이다.

즉, Source Insight는 각종 언어들 컴파일러의 ‘프런트 엔드’ 계층에만 특화돼 있다.
얘가 굉장히 독특한 점이 뭐냐 하면.. 전문 IDE와 달리, 실제 컴파일 결과에 꼭 연연하지 않고 유도리가 있다는 점이다. 그래서 코드에 컴파일 에러가 좀 있더라도 괜찮고, 심지어 #if #else로 갈라지는 부분까지 개의치 않고 특정 심벌이 정의된 부분을 몽땅 한꺼번에 조회 가능하다.

그래서 프로젝트와 configuration이라는 걸 꼭 바이너리를 빌드하는 단위로 만들 필요 없이, 전적으로 사용자가 심벌을 조회하고 코드를 분석하고 싶은 큼직한 단위로 만들 수 있다. 생각해 보니 이게 Source Insight의 강점이다.
Visual Studio나 Android Studio 같은 IDE만 쓰면 되지 이런 게 왜 필요하냐고..?? 응, 필요하고 유용하더라. 틈새시장을 잘 공략한 제품 같다.

그나저나 최근에 회사 업무 때문에 SI 3.5 버전을 쓸 일이 있었는데.. 본인은 또 한 번 굉장히 놀랐다.
2019년 11월에 릴리스 됐다는 프로그램이 알고 보니 구닥다리 노인학대의 종결자인 무려 Visual C++ 6으로 빌드돼 있었기 때문이다.;; ㅠㅠㅠㅠ 실행 파일 헤더에 기록돼 있는 링커 버전, 섹션간의 4KB 단위 패딩(옛날 스타일), 생성돼 있는 기계어 코드의 패턴으로 볼 때 확실하다.

게다가 유니코드 기반도 아니었다. 도움말을 보니 여전히 Windows 9x를 지원한다고 쓰여 있다. 요즘 같은 시대에 레거시 OS 종결자인 프로그램이 날개셋 말고 더 있었구나;;
회사에서만 쓰는 프로그램이어서 많이 다뤄 보지는 못했지만 쟤들도 자기 제품에다가 분명 최신 C++1x 문법을 구현했을 텐데, 그걸 자기들이 제품 코딩을 할 때 좀 써 보고 싶은 생각은 하지 않았을까..?? 피치 못할 사정이 있어서 VC6을 그렇게 오랫동안 써 온 건지 궁금하다.

그나마 2020년에 출시된 SI 4.0에서는 유니코드를 지원하고 많은 변화가 있었다고 한다. 거기서는 자기네 개발툴도 새 버전으로 갈아타지 않았겠나 추측해 본다.

4. Visual C++

그리고 나의 사랑하는 툴인 Visual Studio.. 얘는 2019 이후로 202x이 나오려나 모르겠다. 지난 2년 동안 꾸준히 소규모 업데이트 형태로만 버전업을 거듭한 끝에, 무려 16.9.x 버전에 진입했다.
업데이트가 너무 잦아서 좀 귀찮은 감이 있긴 했지만, IDE 자체의 안정성은 야금야금 눈에 띄게 강화되어 왔다. 그 예를 들면 다음과 같다.

• 예전에는 컴에 절전/최대 절전을 반복하다 보면 IDE의 글꼴이 내가 변경하기 전의 것으로 되돌아가곤 했는데 그 오동작이 어느 샌가 발생하지 않게 됐다. 상당히 성가신 버그였다.
  
• 가끔 대화상자 리소스 편집기를 열 때 IDE가 응답이 멎던 현상이 이제 더는 발생하지 않는다.
  
• 또 가끔은 프로젝트 대렉터리 내부에 RCxxxx, *.vc.db-??? 등 임시 쓰레기 파일이 프로젝트를 정상적으로 닫은 뒤에도 지워지지 않고 남아 있었던 것 같은데.. 이제는 그런 문제가 확실히 해결됐다.

예전에도 언급한 적이 있지 싶은데, 난 Visual Studio IDE가 서로 다른 프로세스 인스턴스끼리도 연계가 더 자연스럽게 됐으면 좋겠다.

• 다른 인스턴스에서 이미 열어 놓은 솔루션을 또 열려고 시도한다면 그냥 그 인스턴스로 이동하기
• 다른 인스턴스에서 만들어 놓은 문서창끼리도 한 탭으로 묶거나 떼어내기 지원 (크롬 브라우저처럼)

그리고...

• BOM이 없는 파일의 인코딩, 또는 새 파일을 첫 저장할 때의 기본 인코딩을 utf-8로 인식해 줬으면 좋겠다.
• 탭이 설정된 대로뿐만 아니라, 주변 파일의 모양을 보고 탭인지 공백 네 칸인지 얼추 분위기를 파악해서 동작하는 기능이 있으면 좋겠다.
• 프로젝트별로 소스 파일 곳곳에 지정된 책갈피와 breakpoints들의 세트들을 여럿 한꺼번에 저장하고 불러오는 기능이 있으면 좋겠다. 디버그를 위해 실행할 프로그램과 인자도 여러 개 한꺼번에 관리하고 말이다.

끝으로.. Visual C++은 2015부터가 Windows 10과 타임라인을 공유한다. 이때 CRT 라이브러리의 구성 형태가 크게 바뀌었다. vcruntime이 어떻고 ucrtbase가 어떻고.. 그리고 Visual Studio 2015~2019는 재배포 패키지도 한데 통합됐다.

그래서 그런지 요즘은 Visual C++이 설치되어 있지 않아도 시스템 디렉터리를 가 보면 msvcp140, mfc140 같은 DLL은 이미 들어있다.
20여 년 전의 msvcrt와 mfc42 이래로 운영체제의 기본 제공 DLL과 Visual C++의 런타임 DLL이 일치하는 나날이 찾아온 건지 모르겠다.

Posted by 사무엘