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

한동안 너무 바빴던 나머지, 남한산성 이후 다음 등산 때까지 블로그에 다른 글을 올릴 시간이 거의 없었다.
그래도 이번에도 아주 흥미진진한 산행을 다녀왔다. 이번에 간 곳은 청와대 뒷산인 북악산이었다.

북악산은 자명한 이유로 인해, 서울에 있는 산들 중 아마 유일하게 신분증 까고 번호표 목걸이를 해야 입산 가능한 산이지 싶다. 인왕산은 사진 찍는 걸 감시하는 초소만 있던데 북악산은 그에 덧붙여서 저런 절차도 필요하다.

인왕산과 북악산은 빨간 날의(일요일 + 공휴일) 다음 날은 입산 금지이다. 감시 초소 직원들도 한 주에 하루 정도는 출근 안 하고 쉬어야 할 테니까. 북악산은 거기에다 아침 9시부터 오후 3시까지 입산 가능 시각도 정해져 있다. 현재 북악산에 있는 사람들의 신원이 모두 파악돼 있어야 하며, 해가 떨어진 뒤에는 산 속에 아무도 없게 마치 민통선에 준하는 수준의 관리를 하는 듯하다.

인왕산은 감시 초소는 있지만 저 정도까지 등산객들을 일일이 파악하고 통제하지는 않는다. 그도 그럴 것이, 해가 지고 나면 어차피 청와대 쪽으로 사진 찍는 것 감시는 할 필요가 없어지니 말이다.

사실, 청와대 근처에 있는 산들에 우리가 이 정도라도 접근하여 등산을 할 수 있게 된 건 생각보다 오래 되지 않았다.
21세기 이전엔 그런 거 없었다. 1968년 1월에 북한 무장공비가 청와대 바로 근처까지 쳐들어왔던 전대미문의 사건의 여파로 인해, 북악산과 그 일대의 산들은 민간인 접근 절대엄금으로 봉인돼 버렸기 때문이다.

서울 지리를 잘 모르던 시절에는 난 북한산과 북악산의 차이도 잘 몰랐다. 북악산은 북한산보다 훨씬 서울 중심부 안에 있다. 본인은 북악산을 오르기 위해 무작정 '창의문'으로 향했다. 예전에 인왕산을 올랐다가 돌아오면서 버스 차창 밖으로 스쳐 지나쳤던 곳이다.

창의문의 바로 옆에 있는 최 규식 경무관의 동상을 가까이에서 다시 접했다.

알고 보니 저 동상은 고인의 순직 1주기를 기념해서 만들어졌다.
태극 무공 훈장은 우리나라의 무공 훈장 중 최상위 등급으로, 이 정도 훈장은 6· 25 전쟁에서 나라를 구한 급의 영웅이 아니면 살아서는 못 받는다고 생각하면 된다. 또한 군인이 아닌 경찰에게 이런 훈장이 추서된 사례도 현재까지 저분만이 유일하다.
바로 몇 년 전(1965), 강 재구 소령이 수류탄 투척 훈련 중에 부하가 실수로 떨어뜨린 수류탄을 몸으로 감싸고 산화하여 동일한 태극 무공 훈장이 추서됐다는 것도 기억해 두면 좋다.

북악산을 오르면서 작년에 갔던 인왕산과 부암동 쪽을 본 모습이다. 인왕산과 북악산은 모두 산 속에 성곽과 감시 초소가 있고, 아예 군부대도 있다.

산을 오르는 길은 성곽을 따라 대략 이런 형태였다. 이 사진에는 보이지 않지만 성벽 너머로는 철조망이 둘러져 있다.
계단을 따라 산을 오를 수 있었는데, 경사가 꽤 가파른 편이었다.

북악산 주변은 경치가 이러했다.
우리가 평소에 서울 시내 쪽에서 바라보는 북악산의 전면은 바위가 참 인상적이다. 하지만 지금 여기는 이미 북악산의 뒤쪽으로 가는 것이고, 산을 타면서 딱히 그런 바위를 볼 일은 별로 없었다. 앞쪽은 영구 봉인돼 있으니 말이다.

저기가 바로 북악산과 북한산 사이에 조성된 마을인 평창동이다. 각종 고급 카페와 레스토랑, 그리고 부자· 유명인사들이 사는 단독 주택들이 가득하여 마치 서울 안의 딴 세상 같다. 교통이 왕창 불편하겠지만, 다들 차를 끌고 다닐 테니 별 문제가 되지 않을 것이다.

북악산의 정상은 생각보다 금방 도달할 수 있었다. '북악산'이 한때는 '백악산'이라고도 불렸다. 창의문에서 북악산 정상까지는 지도상의 직선 거리가 짧은 만큼 경사가 굉장히 급하다.

1· 21 사태 때 북한군과의 교전 중에 총알이 박힌 소나무라고 한다. 그런데 일부러 저렇게 표시를 해 놓은 게 좀 징그럽게 보인다.

성곽을 따라 가다가 '청운대'라고 불리는 다른 봉우리에도 도달했다.

그 뒤 걷는 길은 성곽 안에 있기도 하다가 성 밖으로 나가기도 했다. 철조망이 저렇게 있으니 무슨 GOP 철책처럼 보였다.
이거 사진이 도대체 어떻게 찍혔는지 광량 조절이 이상하게 됐다. -_-;;;

정상을 도착한 뒤에 지금까지 걸어 온 길이 저렇다.

그리고 '숙정문'이라고 불리는 대문에 도착했다. 나름 사대문 중 하나이며 '북대문'에 해당하는 대문이다. 얼마 전에 남한산성을 본 적이 있다 보니 모습이 친근했다.
본인은 조선 시대에 있었던 서울 성곽과 '대문'에 대해서 지금까지 진지하게 생각해 본 적이 없었는데 이제야 좀 개념이 생겼다.
남대문은 서울 역 근처에 있는 그 숭례문이고, 동대문은 국도 6호선상에 있는 그 흥인지문이다.

서대문(돈의문)은 서울 지하철 5호선 서대문 역 근처에 있긴 했지만 일제 강점기 때 헐려서 현재 전해지지 않는다. 옛날엔 노면 전차가 이 문을 통과했는데, 전차 노선을 복선화하려다 보니 이 성곽이 걸림돌이 됐다고.. 얘는 사대문 중 유일하게 복원이 못 되고 2016년 현재 존재하지 않는 문이다.

마지막으로 북대문이 바로 저 숙정문이지만, 높은 산 속에 있는 관계로 다른 문들만치 유명하거나 사람들이 막 드나들지는 않았다고 한다. 쉽게 말해 존재감이 별로 없다. 남대문하고는 접근성이 가히 넘사벽급으로 차이가 나지 않은가..;;

난 처음에는 창의문에서 숙정문, 와룡 공원까지 북악산을 성벽을 따라 수평으로 횡단하는 코스를 생각하고 왔다.
차를 이용해서 북악산을 오르면 아까 같은 정상으로는 못 가지만, 그래도 성벽 둘레길보다 높은 곳으로 가서 '팔각정'이라고 불리는 정자에 도달할 수 있다.

그러면 도보 등산로와 자동차 길은 서로 완전히 분리되어 있느냐 하면 그렇지 않다.
창의문과 와룡 공원 사이에, 청와대와 더 가까운 지점에 '삼청 공원'이 있고 거기에도 북악산 숙정문을 경유하여 팔각정까지 가는 등산로가 있다. 이건 북악산을 횡단이 아니라 종단하는 코스인 셈이다.

북악산에는 일명 '김 신조 루트'도 있고 북한산 형제봉과 연결되는 '하늘다리'도 있는데 거기로 가려면 숙정문의 밖으로 나가서 서울 성곽보다 훨씬 더 북쪽으로 계속 올라가야 한다.
위의 사진은 그 종단 등산로를 위에서 내려다보면서 찍은 것이다. 이 등산로는 나중에 북악산에 다시 와서 개척하게 됐다.

건물이 이 정도로 보이기 시작하니 이번 등산도 거의 끝이 난 것 같다. 옛날에는 저기도 다 산이었을 텐데 산중턱까지 다 개발되고 도로가 생기고 길이 닦인 것이다.

정작 와룡 공원에는 가 보니 별 거 없었다. 공 병우 박사가 운영하던 한글 문화원의 소재지가 와룡동이었던 걸로 기억한다.
여기서는 마을 버스를 타고 지하철역으로 가면서 지금까지 말로만 듣던 성균관 대학교 서울 캠퍼스, 감사원, 통일부 같은 건물들을 구경할 수 있었다. 등산을 하면서 서울에 이런 곳도 있다는 걸 알아 가는 건 즐거운 일이다.

안국 역과 혜화 역이 지리상으로는 생각보다 굉장히 가까이 있다는 걸 처음 알았다.

Posted by 사무엘

Windows에서 C/C++ 언어로 EXE를 만들 때는 시작점으로 WinMain이라는 함수가 쓰인다.
얘는 먼 옛날 16비트 시절과, 지금의 32/64비트 사이에 바뀐 게 거의 없다. HINSTANCE hInst, HINSTANCE hPrevInst, PSTR pszCmdLine, int nCmdShow 라는 네 종류의 인자 중에서 32비트로 오면서 바뀐 것은 hPrevInst이 언제나 NULL이라는 것밖에 없다. 그것도 과거에는 복잡하던 게 더 간결해진 변화이기 때문에 실질적으로 신경 쓸 필요가 없다.

옛날 16비트 시절에 HINSTANCE는 파일 차원에서 동일한 프로그램이 중복 실행되었을 때 각 실행 문맥을 구분하는 일종의 메모리 번호표였다. 한 프로그램이 완전히 처음 실행될 때는 hPrevInst가 NULL인데 두 번째 실행되면, 먼저 실행된 프로그램이 받았던 hInstance가 다음 인스턴스의 WinMain 함수에서 hPrevInst로 전달되고..
세 번째 중첩 실행되면 아까 그 두 번째 프로그램의 신규 핸들이 거기의 hPrevInst로 전달되는 형태였다. 단일 방향 연결 리스트의 head 노드 같은 느낌이다.
자기 자신 말고는 주변에 무엇이 있는지 일부러 특수한 API를 써서 조회를 하지 않으면 도무지 알 수 없는 32비트 이상 보호 모드에서는 정말 상상하기 힘든 관행이다.

EXE는 그렇고 그럼 DLL은 어떨까? DllMain이라는 기본적인 형태는 동일하지만 16비트 시절에는 아무래도 멀티스레드 같은 건 존재하지 않았으니까 DLL_PROCESS_(ATTACH/DETACH)만 있었고, 나중에 DLL_THREAD_*가 추가된 정도일까?

사실은 그렇지 않다.
옛날에는 BOOL DllMain(HINSTANCE hInst, DWORD fdwReason, PVOID pReserved)라는 형태의 함수 자체가 없었다.
그 대신 완전히 다른 int FAR PASCAL LibMain(HANDLE hInst, WORD wDataSeg, WORD wHeapSize, LPSTR lpszCmdLine) 라는 함수가 있었으며, DLL이 처음 로드되었을 때에 이게 한 번만 호출되곤 했다.

16비트 시절에 DLL은 프로세스 독립성이 보장되지 않았다.
지금이야 B.DLL을 사용하는 A.EXE가 두 번 중첩 실행되면 두 인스턴스에 대해서 B.DLL이 제각각 로드되어 DLL_PROCESS_ATTACH가 오지만..
옛날에는 A.EXE가 중첩 실행되었더라도 B.DLL에서 LibMain은 첫 로딩될 때 한 번만 실행되었다. 그리고 자신이 A의 두 번째 인스턴스에 의해 중첩 로드되었다는 사실을 알 길이 없었다. A가 B.DLL에 별도로 정의되어 있는 초기화 함수 같은 것을 호출하지 않는다면 말이다.

LibMain 함수의 인자를 살펴보면, 첫 인자는 자기 자신을 식별하는 인스턴스 핸들이다.
하지만 16비트 시절에는 DLL은 중첩 로딩이 되지 않고 자신의 전역변수 값이 모든 프로그램에서 공유되었다. 그렇기 때문에 저 값은 EXE의 WinMain에서 전달되는 인스턴스 핸들과는 달리 딱히 변별성은 없었을 것이다. 시스템 전체를 통틀어 같은 값이 들어왔으리라 생각된다.

그 다음 wDataSeg와 wHeapSize는 딱 보기만 해도 16비트스러운 암울한 값이다. 이게 어떤 의미를 갖고 이것으로 무엇을 할 수 있는지 잘 모르겠다.
데이터 세그먼트(DS) 레지스터 값은 뭐 어쩌라는 건지 잘 모르겠지만 어쨌든 실행할 때마다 다른 값이 들어올 수는 있어 보인다. 그 반면 wHeapSize는 이 DLL을 빌드할 때 def 파일에다가 지정해 줬던 로컬 힙의 크기이다. 즉, 이 DLL이 지금 형태 그대로 존재하는 한 언제나 고정된 값이 넘어온다.

마지막으로 lpszCmdLine은 더욱 기괴하다. EXE도 아니고 DLL을 어떻게 인자를 줘서 로딩한단 말인가? LoadLibrary 함수에 인자를 전달하는 기능이 있지도 않은데 말이다. 호스트 EXE에 전달된 인자를 되돌리는 것도 아닌 듯하다. 실제로 거의 대부분의 경우 이 인자의 값은 어차피 그냥 NULL이라고 한다.

16비트 DLL의 첫 관문인 LibMain은 기괴한 점이 여기저기서 발견된다.
DLL에 배당되어 인자로 전달된 데이터 세그먼트는 앞으로 빈번하게 사용되는 것을 염두에 두고 메모리 상의 주소가 바뀌지 않게 lock이 걸린다고 한다. 운영체제는 아니고 컴파일러가 lock을 거는 코드를 기본적으로 추가해 넣는 듯하다.
그래서 옛날 소스 코드를 보니, 이유는 알 수 없지만 LibMain에 보통 이런 코드가 들어갔다고 한다.

if (wHeapSize > 0) UnlockData (0);

즉, 아직은 lock을 걸지 말고 도로 재배치 가능한 상태로 놔 두겠다는 뜻이다. 그리고 LockData/UnlockData는 Windows 3.1의 windows.h에 이렇게 매크로로 정의돼 있다.

#define LockData(dummy)     LockSegment((UINT)-1)
#define UnlockData(dummy)   UnlockSegment((UINT)-1)

옛날에는 (Un)LockSegment라는 함수가 있었다. 그리고 Windows 3.x보다도 더 옛날에는 (Un)LockData라는 함수도 별도로 있었는데, 용례가 간소화돼서 Data의 기능이 Segment로 흡수된 듯하다. (가상 메모리라는 게 없던 Windows 2.x 리얼 모드 시절의 잔재라고 함.) 그러니 Data는 레거시 호환을 위해 매크로로 바뀌고, 인자 역시 쓰이지 않는 dummy로 바뀐 것이다.
평소에는 특정 세그먼트 lock/unlock을 하는데, (UINT)-1을 주면 모든 영역을 그렇게 하는 것 같다. 어떤 경우든 wDataSeg의 값이 직접 쓰이지는 않는다.

LibMain은 초기화가 성공하면 1을 되돌리고 그렇지 않으면 0을 되돌려서 DLL의 로딩을 취소하게 돼 있었다. 이것은 오늘날의 DllMain과 동일한 점이다.
그럼 16비트 시절에는 시작 다음으로 DLL의 종료 시점을 감지하려면 어떻게 해야 했을까? EXE와는 달리 DLL은 main 함수의 종료가 곧 프로그램의 종료는 아니니까 말이다.
또한 16비트 시스템의 특성상 비록 매 프로세스의 종료 시점을 감지하는 건 불가능하겠지만, 그래도 아까 중복 실행되었던 A가 최후의 인스턴스까지 모두 종료되어서 B.DLL이 메모리에서 사라져야 하는 시점이 언젠가는 올 테니 말이다.

이것도 방법이 굉장히 기괴했다. DLL이 메모리에서 제거되기 전에 운영체제는 해당 DLL에서 'WEP'라는 이름을 가진 함수를 export 테이블에서 찾아서 그걸 호출해 줬다.

//16비트 시절에 _export는 오늘날의 __declspec(dllexport) 와 비슷한 단어임.
int FAR PASCAL _export WEP (int nExitCode);

이 함수 역시 성공하면 nonzero를 되돌리게 돼 있지만, 어차피 프로그램이 일방적으로 종료되는 상황에서 함수의 인자나 리턴값은 무시되다시피할 뿐 거의 의미가 없었다.
하다못해 오늘날 DllMain의 DLL_PROCESS_DETACH처럼 자신이 FreeLibrary에 의해 해제되는지, 프로세스의 종료에 의해 일괄 해제되는지라도 알 수 있으면 좋을 텐데 그 시절에 그런 정보를 바랄 수는 없었다.
참고로 WEP는 그냥 Windows Exit Procedure의 약자였다. -_-;;

이렇듯, 형태가 거의 바뀐 게 없는 WinMain과는 달리, DLL의 입구 함수는 16비트 시절과 지금이 달라도 너무 달라서 문화 충격이 느껴질 정도이다. 예전에도 16비트 Windows 프로그래밍에 대해서 글을 종종 쓰고 DLL에 대해서도 언급한 적이 있었는데 이런 내역에 대해서 정리한 적은 없었기 때문에 또 글을 남기게 됐다. 옛날에는 이렇게 불편한 환경에서 도대체 프로그램을 어떻게 만들었나 싶다.

LibMain과 WEP를 DllMain으로 통합한 것은 백 번 잘한 조치였다.
16/32비트 이식성을 염두에 둔 코드라면 DllMain에다가 LibMain과 WEP를 호출하고, 반대로 LibMain과 WEP에서 적절하게 서로 다른 인자를 줘서 DllMain을 호출하는 계층도 생각할 수 있으며, 과거에는 이런 관행이 실제로 존재했다고 한다. 마치 윈도우 프로시저와 대화상자 프로시저의 형태를 통합한 계층을 따로 만들어 썼듯이 말이다.

Posted by 사무엘

지난 3월 초, 봄비가 촉촉히 내리고 있을 때 또 무작정 산을 올랐다. 이번에는 지금까지 말로만 수도 없이 들었지 직접 가 본 적은 한 번도 없었던 남한산성을 구경하러 청량산으로 갔다.
전에 불암산을 오를 때는 서울 지하철 4호선의 종점인 당고개 역으로 갔고, 하산은 남양주 쪽으로 했다. 이와 대조적으로 이번에는 5호선의 종점인 마천 역으로 갔고, 하산은 하남 쪽으로 했다.

또한 불암산은 하산한 뒤 남양주의 산기슭에 군부대가 있던데, 여기 청량산은 반대로 등산 전 서울의 끝자락 지점에 군인 간부 아파트와 군부대가 있었다. 듣자하니 특전사 부대라고 함.
지하철 운임에 조조할인이 적용될 정도로 굉장히 이른 시간에 산행을 했다. 덕분에 아침 7시 정각이 되자 군부대에서 기상 나팔 소리가 울려 퍼졌다. 그리고 이어지는 군가 BGM들..;; 단 4주간의 짧은 경험이지만 훈련소 시절 생각이 났다.

인근 주민들은 이거 듣는 게 일상이 돼 있겠구나. 단, 지도를 보니 이 군부대는 위례 신도시의 개발로 인해 딴 데로 이전하고 부지가 재개발될 계획인가 보다. 서울 2기 지하철이 없던 시절에는 여기만 해도 굉장한 외곽이고 오지였겠지만, 지금은 그렇지 않으니 말이다.

본격적으로 산을 오르기 전, 아직 맛집들이 즐비한 골목을 지나고 있는데 "서울 빠이빠이. 여기부터는 하남시입니다" 이런 표지판이 눈에 들어왔다. 산이 행정구역상 하남에 있는가 보다. 단, 나의 목적지인 남한산성은 하남이 아니라 광주 소재였다.

남한산성은 도립공원이며 여기 일대는 유명한 등산 코스이다. 그래서 등산로는 내가 가 본 산들 중 가히 톱급으로 잘 닦여 있었다. 난간에다가 바닥은 미끄럼 방지용 매트까지.. 비가 내린 직후의 날씨이지만 진흙 진창을 밟을 일이 거의 없을 정도였다.

본인은 딱히 체력이 좋은 편이 아니며 산을 남들 이상으로 빠르게 잘 타지는 못한다. 하지만 1시간 남짓 느릿느릿 쉬기를 반복하면서 산을 오르니 남한산성엔 생각보다 금방 도달할 수 있었다. 저기는 서문(west gate)이었다.
아침 7시 남짓한 이른 시간이어서 산은 한산했지만, 그래도 하산하는 몇몇 일행과 마주치기도 했다.

연주봉 옹성에 들렀다가 왔다. 아무 산에나 이런 구조물이 있는 게 아니니 남한산성은 확실히 레어템이긴 하다.

내가 올라온 길 방향을 내려다보며 찍은 사진. 날씨가 흐리고 어두워서 전망이 그리 좋지는 않다. 또한 그렇게 막 높게 올라온 것도 아니다.

이번엔 내가 하산할 지점(하남시 춘궁동)을 내려다보며 찍은 사진이다. 좌우로 산(언덕?)에 둘러싸인 일종의 계곡 같은 지형이다.

남한산성의 안팎은 대충 이런 형태였다. 대포와 폭격기가 발달하면서 지금이야 이런 성 같은 건 군사적 가치가 전혀 없어졌지만, 옛날에는 가파른 산들 사이에 분지가 조성된 여기가 천혜의 요새 그 자체였다고 한다.

여기는 북문이다. 본인은 하산은 이쪽으로 했다.

산성 로터리. 남한산성 내부에는 아예 각종 맛집 마을이 조성돼 있으며, 자동차가 들어오는 정도를 넘어서 정규 노선 버스가 다닌다. 물론 산중턱이니 올라가는 데 기름이 많이 들 것 같다. 북한산성 주변은 이런 거 없음.
주변엔 한옥 형태의 한식당이 가득하다. 내가 갔을 때는 시간 관계상 아직 문을 연 곳은 없었음. 그래도 다들 가격이 왕창 셀 것 같았다.

저기서 방향을 꺾어서 조금만 더 가면 남한산성 행궁을 볼 수 있었을 텐데 그건 미처 생각을 못 했다.

이제 북문으로 나가서 하산을 시작했다. 지도에서 봤을 때 고도 대비 등산로가 좀 짧다는 생각을 했는데 역시나 지그재그 스위치백이 있었다.

산을 벗어나서 버스 정류장이 나올 때까지 한참을 걸었다. 서울 외곽에서 산 하나만 넘으면 이렇게 전원적인 마을이 펼쳐진다는 게 신기하다.

미리 봐 뒀던 버스 종점 겸 공영주차장에 도달했다. 공간이 얼마나 여유로운지, 저 주차장은 관리인도 없고 전면 무료이다. 그러니 마음만 먹으면 차를 여기에다 두고 안심하고 등산을 하는 것도 얼마든지 가능하다.
하지만 본인은 등산 원칙이 "갔던 길로 돌아오지 않는다"이기 때문에 어지간히 장거리 등산 원정을 떠나는 게 아닌 이상, 차는 가져가지 않는다. 여기서는 옆에 세워져 있던 마을 버스를 탔다.

그 뒤 하남 시내에서 내려서 서울로 가는 버스를 갈아탔는데...;; 시가지 도로의 모습은 약간 문화 충격을 느낄 정도였다. 나름 광역버스 9301이 지나는 길인데도 시내 도로가 이렇게 작다니.
하남대로라고 불리는 국도 43호선 구간을 제외하면 다 저런 것 같았다.

서울 역까지 가장 깊숙이 들어가는 버스는 9301뿐이고, 나머지 도시형 버스들은 다들 동서울 터미널 정도까지만 갔다. 물론 어느 것이든 국도 43호선의 천호대로 구간으로 들어가서 5호선 강동 역을 경유하는 건 변함없으므로 본인은 아무 거나 타고 귀가했다. 하남시와 인접한 서울 동쪽 끝자락에도 그린벨트가 풀리고 아파트가 곳곳에서 지어지는 게 보였다.
어쩌다 보니 남한산성 답사기는 다른 등산기보다 글이 좀 길어졌다.

Posted by 사무엘

<날개셋> 한글 입력기 8.4의 다음 버전은 8.5이다. 6월 말쯤에 나올 예정이다. 아울러, 타자연습도 3.5가 나올 예정이다.

8.5의 변화 사항들은 대부분 GUI 등 사소한 것들이다. 그러나 예전보다 센스 있게 동작하도록 기능이 추가되거나 변경된 건 있어도, 지난 8.4에서 뭔가 크게 잘못 동작하던 것이 바로잡혔다거나 버그가 고쳐진 것은 없다. 그만큼 8.4는 완성도 높게 잘 만들어졌으며 <날개셋> 한글 입력기도 '더 고칠 게 없는' 안정화 고정 단계에 근접한 듯하다.

8.5의 존재 의미라 할 수 있고 한글 입력 엔진 차원에서 바뀐 유일한 과업은 바로 '이벤트 핸들러'의 구현이다. 사실, 8.4에서 들어가려 했으나 이론 검증과 확신이 서지 않아서 차마 마무리를 못 하고 한 버전 더 거쳐 가게 됐다.
입력 스키마(현재 사용 중인 놈 한정)와 보조 입력 도구는 한글 입력 엔진으로부터 다음과 같은 상황에서 7종류의 이벤트를 받아서 이때 자신만의 처리를 할 수 있다. 주로 사용자(소문자 a~z) 변수를 초기화하는 수식이 실행된다.

(1) 시스템: <날개셋> 한글 입력기를 사용하는 프로그램 전체가 활성/비활성화됐을 때. 그리고 외부 모듈의 경우, 해당 UI 스레드 차원에서 IME가 날개셋으로 바뀌었거나 해제됐을 때. on/off 경우에 모두 호출된다. 단, 입력 패드는 언제나 시스템 차원에서 global하게 구동 중이므로 이 이벤트를 따로 보내지 않는다.

(2) 포커스: 한 프로그램 안에서 <날개셋> 한글 입력기를 사용하는 창의 포커스가 여기서 딴 데로 바뀌었을 때. 그리고 외부 모듈의 경우 창 포커스는 여전하더라도 내부적으로 사용하는 컨텍스트가 바뀌었을 때(HIMC). 역시 on/off 때 모두 호출된다.
포커스/컨텍스트가 바뀌었으며 잃었다가 얻었다는 사실 자체만 알 수 있지, 구체적으로 그 값을 구분해서 인식할 수 있지는 않다.

(3) 입력 항목(글쇠배열) 전환: 원래 있다가 교체되는 놈(off)과 새로 지정되는 놈(on)이 모두 이벤트를 받는다. 또한, 제어판을 구동하여 입력 설정이 바뀐 뒤에도 디폴트로 지정된 입력 항목은 처음에 on 이벤트를 받는 게 보장된다.
보조 입력 도구에는 요런 통지를 받는 게 이미 있다. 그래서 '화면 키보드' 도구가 지금 사용 중인 글쇠배열을 실시간으로 업데이트 해서 표시해 준다.

(4) 외부에 의한 조합 강제 종료: 한글 입력 중에 마우스 클릭, 포커스 변경, 우리 입력 스키마가 처리하지 않는 글쇠 등의 이유로 조합이 종료되었을 때 이벤트를 받는다. on/off 개념은 없고 그냥 단일.

(5) 문자 연속 입력 단절: 조합 강제 종료와 비슷하지만 이와 완전히 동일하지는 않은 개념이다. 굳이 조합을 만들지 않더라도 문자를 계속 입력하거나 bksp 하고 있었는데 갑자기 비문자 글쇠나 마우스 클릭, 포커스 변경 등이 감지되면 이 이벤트가 한번 날아온다.

지금도 "bksp 연타 시 한번 정해진 동작을 계속 적용" 옵션이 이 이벤트 비슷한 개념을 사용하고 있다. 그런데 이를 개념적으로 더 확장하여, 굳이 한글 조합 중일 때가 아니라 연속 입력 중일 때에 '낱자 단위로', 연속 입력이 끊어졌을 때는 '글자 단위로' 한글을 지우도록 할 수도 있게 했다.

(6) 변수값 변화: 입력 스키마의 글쇠배열 내지 문자 생성기의 오토마타에서 수식 계산으로 인해 변수값이 바뀐 것을 보조 입력 도구가 알 수 있게 한다.
그래서 보조 입력 도구를 이용해 변수값 디버거를 만들 수 있게 된다. 그리고 '화면 키보드' 도구가 아예 context-sensitive하게 지금 입력되는 문자를 화면에다 업데이트 가능하게 된다. 즉, 복벌식 입력기라면 내부 변수값에 따라 두벌/세벌 모드가 됐을 때 글쇠배열 전체가 두벌식이나 세벌식 모양으로 바뀐다.

(7) 타이머: 지금은 천지인 모바일 입력기처럼 특정 상황에서 일정 시간이 경과했을 때 조합을 강제 종료시키는 기능을 구현할 때 타이머가 제한적으로 지원되고 있다. 타이머는 그 기능을 더 일반화해서 겉보기로 조합은 유지하더라도 오토마타의 내부 상태만 바꾸는 것, 임의의 글자를 입력시키는 것, 타이머를 1회가 아니라 계속 동작시키는 등 더 다양한 처리를 할 수 있게 된다.

이렇듯, 통합적인 이벤트 핸들러는 한글 입력기의 아키텍처에서 매우 중요한 기능이다. 오랫동안 필요성만 인지하고 있었을 뿐 작업을 할 엄두를 못 내고 있던 곳에 대대적인 수정이 가해졌다. 이 기능 하나에다가 다른 UI 쪽의 변화 사항들을 합치면 +0.1 버전업은 충분한 가치와 의미를 지닌다.
이벤트 핸들러 수식을 지정하는 UI는 글쇠배열의 추가 옵션을 지정하는 대화상자에 들어갈 예정이다. 어차피 글쇠배열 내부에서 쓰이는 변수들을 초기화하는 수식이 들어갈 테니 말이다.

이것 말고 가볍게 읽을 만한 새 버전 변화 사항들은 다음과 같다. 8.5가 어서 완성됐으면 좋겠다.

1. 한글 낱자 종류 변환에 filler를 안 집어넣는 옵션

텍스트 필터 중에 '한글 낱자 종류 바꾸기'라는 게 있는데, 이건 호환용 한글 자모(U+31??)와 표준 한글 자모(U+11???) 사이를 변환하는 나름 중요한 기능이다.
표준 한글 자모에는 정규화 규칙이라는 게 적용되기 때문에 자음 하나, 모음 하나만 있을 때에도 초/중성의 빈 자리에는 채움 문자(filler)가 꼭꼭 들어간다. 하지만 채움 문자 없이 호환용 자모를 문자 그대로 표준 한글 자모로 일대일 치환만 해 주는 옵션이 이번 버전에서 추가되었다.

이 옵션을 사용하면 정규화 규칙에 어긋나는 문자열을 생성할 수도 있지만, 한편으로 "ㅎㆍㄴ" 같은 풀어 쓴 호환용 자모로부터 모아 쓴 옛한글을 곧바로 만들어 낼 수 있다. 채움 문자가 없으니 각 자모가 그대로 한 글자를 구성하게 됐기 때문이다.

2. 외부 모듈에서 문자표 대화상자의 동작 방식 변경

<날개셋> 편집기와 외부 모듈은 모두 문자를 입력하는 프로그램이니 키보드에 없는 특수문자를 입력하는 '문자표' 기능이 있다.
편집기야 내부의 모든 데이터 입출력이 100% 자가통제가 가능하기 때문에 문제될 게 없지만 외부 모듈은 문자표로부터 받은 문자를 응용 프로그램에서 보내는 것만 가능하고 그 프로그램이 실제로 문자를 접수하는지를 완벽하게 알 수는 없다.

그래서 문자표라는 대화상자가 키보드 포커스를 얻어 있는 상태에서 본문 창에다가 계속해서 문자를 보내는 게 기술적으로 가능한 프로그램도 있고 가능하지 않은 프로그램도 있었다. 즉, 외부 모듈에서 문자표 대화상자는 사실상 반쪽짜리 기능이었던 것이다. 텍스트 필터가 TSF A급에서만 사용 가능한 반쪽짜리 기능인 것처럼 말이다. 이런 이유로 인해, 이 버튼은 프로그램을 처음 설치했을 때는 기본적으로 도구모음줄에 나타나 있지도 않았다.

이 점을 감안하여 이번 버전에서는 외부 모듈의 문자표의 동작 방식을 바꿨다. 연속 입력 기능을 희생시켰다. 엔터를 누르면 문자표 대화상자는 곧장 닫혀 버린다.
그 대신 글자 단 하나를 입력하더라도 그 기능만은 IME, TSF A/B 등을 가리지 않고, 또 BMP와 surrogate를 가리지 않고 모든 프로그램에서 제대로 동작하게 정책을 바꿨다. 동작을 차라리 이렇게 바꿔 버릴까 오랫동안 고민했는데 결국 이제야 결정을 내렸다.

문자표를 꺼내 놓은 채로 여러 문자를 입력하고 싶으면, 이런 대화상자가 아니라 '보조 입력 도구' 중 하나인 문자표를 사용하면 된다. 얘는 반대로 문자표 내부에서 키보드 조작을 할 수는 없지만, 키보드 포커스를 차지하지 않기 때문에 창이 떠 있는 상태에서도 다른 프로그램의 UI에 영향을 주지 않는 게 가능하다.

3. 문자표에 Ctrl+클릭

요즘은 그냥 클릭에 뭔가 2% 부족한 면모가 있을 때 Ctrl+클릭을 추가하는 게 새로운 UI 트렌드인 것 같다.
후보 데이터를 추가할 때 Ctrl+클릭을 하면 입력된 문자열이 각각의 글자 단위로 따로 후보로 추가된다. 그리고 낱자 결합 규칙에서도 Ctrl+클릭을 하면 추가 후에 입력란의 값과 키보드 포커스가 그냥 클릭과는 다르게 바뀐다.
외부 모듈의 후보 목록에는 Ctrl+클릭(Ctrl+엔터 포함)뿐만 아니라 Shift+클릭도 있어서 단순히 한자 변환뿐만 아니라 한글(한자) 또는 한자(한글) 형태를 지정할 수도 있다.

이와 같은 맥락에서, 문자표에도 Ctrl+클릭 동작을 추가했다.
그냥 '추가'를 누르면 선택된 문자가 본문에 삽입되고 대화상자가 그대로 남아 있는 반면, Ctrl+클릭을 하면 이제 문자가 삽입됨과 동시에 대화상자가 닫히게 했다. 이 기능이 있으니 정말 편하다. 물론 애초부터 연속 입력이 가능한 편집기의 문자표 같은 곳에서 말이다.

4. 글자가 많이 존재하는 부수는 진하게 표시 (부수로 한자 입력 기능)

오늘날 수만 자에 달하는 한자들을 분류하는 데는 부수라는 게 쓰인다. 부수는 총 214개가 존재하는데, 한자에 식견이 있는 분이라면 다 아시겠지만 이 부수들이 골고루 쓰이는 게 아니다. 분포가 전혀 균일하지 않으며, 소수의 특정 부수에만 쏠림이 매우 심하다.

예를 들어 요일을 나타내는 한자들(火, 水, 木, 金 같은. 단 月은 제외), 人, 車, 言, 鳥처럼 만만하고 보편적인 뜻을 가진 부수에는 한자가 수백~심지어 1000개가 넘게 들어있고 새로운 글자가 또 만들어지기도 한다. 그러나 匕, 至, 臣, 牙, 首, 父, 龜, 鼠 같은 나머지 대부분의 부수들은 듣보잡이다. 그 제부수자 자체는 首, 父, 高, 非, 長처럼 아주 기초적이고 친숙한 반면, 거기서 파생된 한자는 거의 없는 경우도 있다.

이 점을 감안하여, 다음 버전에서는 "부수로 한자 입력" 도구에 한자가 매우 많이 들어있는 상위 10% 정도의 부수는 약간 진하게 표시해서 사용자의 눈에 미묘하게 더 잘 띄게 했다.
이것도 시각 피드백을 어떻게 줄지 무척 고민했다. 색깔을 달리 하는 건 제일 간단하긴 하지만, 실험 결과가 좋지 않아서 관뒀다. 이미 색깔로 변별하는 다른 요인들도 있는데(한자의 등급, 현재 선택된 부수와 획수가 같은 부수) 거기에다 색깔 변화를 더 주면 비주얼이 너무 튀고 더 혼란스러워졌다.

그 다음으로 생각한 건, 글자 크기에 변화를 주는 것이었다. 하지만 이 역시 결과가 별로 좋지 않아서 최종적으로는 '볼드' 속성이 낙찰됐다. 요렇게 해 주니 딱 봤을 때 너무 튀지 않으면서도 자주 쓰이는 메이저 부수만 빨리 찾는 데 확실히 도움이 된다. 나만 그렇게 생각하는 게 아니었으면 좋겠다만..;;

5. 타자연습: 계정 import/export, 그리고 파일 기반 custom 연습글

타자연습에는 로그인 화면에서 계정 파일을 다른 디렉터리로 내보내거나 거기서 계정 파일을 가져오는 import/export 기능을 추가했다.
단순한 파일 copy 기능에 지나지 않지만, 사용자 계정을 컴퓨터끼리 옮길 수 있게 하는 건 진작부터 필요했던 기능인데 이제야 도입됐다.
궁극적으로는 서버를 통한 동기화도 지원해야 할 텐데 그건 내 혼자 할 수 있는 일은 아니고..

그리고 거의 10년 가까이 유지되던 연습글 목록 관리 방식이 바뀌었다.
XML 파일 기반인 것은 변함없지만, 이것은 프로그램이 기본 제공하는 고정 붙박이 연습글에만 적용된다.
이전처럼 사용자가 XML 리스트를 직접 고치는 것은.. 이제는 더 권장되지 않는 지저분한 관행으로 deprecate됐다. 프로그램 UI에는 예전과 같은 '연습글 추가/삭제' 같은 버튼과 기능이 사라졌다.

그 대신, 사용자의 custom 연습글은 특정 디렉터리에다가 txt 파일들을 갖다 놓기만 하고 '새로 고침'을 누르면 거기에 있는 것들을 프로그램이 알아서 추가로 등록해 주는 형태로 바뀌었다. 하위 디렉터리가 있으면 물론 그것까지 알아서 찾기 때문에 재귀적인 트리 구조를 만들 수 있다. 디렉터리는 꾸러미, 파일은 연습글로 그대로 대응되는 거다.

custom 연습글은 크게 두 종류가 있다. (1) 이 컴퓨터를 사용하는 모든 사용자가 똑같이 공유하는 놈, 그리고 (2) 현재 사용자 계정에서만 보이는 놈.
(1)의 위치는 답정너로 고정돼 있다. "운영체제의 공용 문서\YmSoft\NgsType"이다. 여기에다가 txt 파일들을 심어 놓으면 <날개셋> 타자연습에서 어느 계정으로 로그인 하건, 아니 로그인하지 않고 익명으로 사용하더라도 연습글들을 볼 수 있다.

또한, 여기에 덧붙여 임의로 지정된 디렉터리를 하나 더 동일한 방식으로 수색하게 할 수 있다. 이 위치는 각 계정별로 달라질 수 있다.
기본 제공되는 보급 연습글은 맨 위에 표시되며 꾸러미가 예전처럼 자주색이다. 그러나 (1) 공용 custom 연습글은 꾸러미가 밝은 분홍색이며, (2) 개인용 custom 연습글은 꾸러미가 파란색이다.

"문장/글 연습" 탭에 가 있는 상태에서 '환경설정' 버튼을 누르면, 예전에는 '외형'과 '타자 연습'이라고 탭이 2개 있는 대화상자가 떴는데, 이제는 '추가 연습글'이라는 제3의 탭이 추가되었다. 여기에서 공용 연습글 디렉터리가 어디인지 정확한 경로를 확인하고 그 창을 탐색기로 열어 볼 수 있다. 그리고 개인 연습글 디렉터리는 위치도 사용자가 지정하고 탐색기로 여는 것도 가능하다. 이제 나만의 연습글을 추가하는 건 이런 식으로 하면 된다.

여담이지만, 이번 버전에서는 기본 제공되는 연습글들도 좀 현실화했다.
잉여도가 너무 높아 보이던 옛한글 연습글을 삭제하고, 성경도 잠언과 요한복음만 남겼다. 잠언은 '슬기로운 이야기' 카테고리에 있던 것을 '영적 생활'로 옮겼다.
우리말 우리글 카테고리에 있던 글들을 삭제하고 '한글 노래' 하나만 남겨서 '마음의 양식' 카테고리에다 옮겼다.
그래도 <날개셋> 타자연습은 안 창호 선생의 글과 김 성모 화백 어록, '어둠에다크에서'가 한 자리에 놓여 있는 타자 연습 프로그램이다. 제작자가 인터넷 병맛 개그를 좀 좋아하기 때문에..;;

* 그 밖에,

(1)
 <날개셋> 편집기는 상태 표시줄(status bar)에 있는 글자판(입력 항목)을 우클릭하면 글자판을 선택하는 메뉴가 나타난다. 그래서 한영 내지 Shift+Space 같은 단축글쇠를 안 누르고도 마우스로 입력 모드를 전환할 수 있다.
그 중 '빈 입력 스키마'는 아시다시피 <날개셋> 한글 입력기가 제공하는 특정 입력 모드가 아니라 그냥 운영체제가 제공하는 IME를 그대로 받아들여서 문자를 입력하는 모드이다.

빈 입력 스키마를 사용하고 있는 상태에서 이 메뉴를 통해 동일한 빈 입력 스키마를 또 선택하면 그때는 운영체제의 한영 상태를 전환하는 기능을 추가했다. 중국어나 일본어 IME를 사용하고 있다면 해당 언어의 자국 문자 모드와 영문 모드가 전환된다.

(2)
대화상자에서 리스트 박스의 아이템을 더블 클릭하면 그 아이템을 고치거나, 그걸 선택한 채로 '확인'을 바로 누르는 shortcut 동작이 수행되곤 한다. 그에 비해 라디오 버튼의 더블 클릭은 잘 알려져 있지 않지만, 이 역시 MS가 권장하는 UI 동작이다. 대표적인 예가 MS Office 프로그램에서 화면 확대 대화상자인데, 100, 200같은 퍼센트를 라디오 버튼으로 선택하고 그걸 더블 클릭하면 곧바로 대화상자가 종료된다.

<날개셋> 한글 입력기는 다음 버전부터 주요 UI에 라디오 버튼의 더블 클릭이 지원될 예정이다. 라디오 버튼의 선택이 해당 대화상자의 동작 방식이나 옵션을 거시적으로 결정하는 대화상자들이 그 대상이다. 대소문자 전환(전환 방식), 기본 입력기 빠른설정(사용할 글자판) 등등에서 아이템을 더블 클릭하는 것만으로 대화상자를 확인 종료할 수 있게 된다.

(3)
Windows의 한글 IME 지원 체계에는 좀 이상한 문제가 있다.
TSF를 응용 프로그램이 직접 지원하는 A급 환경 말고, 그냥 IME 호환 계층을 통해 지원하는 B급 환경에서는..
처음에 2글자 이상의 조합을 만들면 조합이 그냥 끊어져 버린다. 이건 이유는 모르겠지만 운영체제가 한글 IME에 대해서 거의 일부러 강요하는 동작이다. 9x/XP 시절, IME 모듈조차도 안 이랬는데 말이다.

이런 이유로 인해 TSF B급 프로그램에서는 한글 조합은 반드시 1글자짜리 호환용 한글 자모로 시작해야 하고, 2~3글자짜리로 정규화된 표준/옛한글 자모로 시작할 수 없다. 첫 타 이후에 다음 타로 인해 계속된 조합의 길이가 2글자 이상으로 가는 건 괜찮다.
이번 새 버전에서는 TSF B급 프로그램에서 2글자 이상의 조합을 만들려 해서 조합이 끊어졌다면 이를 감지해서 이 현상에 대한 간단한 안내 메시지와 도움말 링크를 표시하게 했다. 그래서 이건 설정 문제이지 프로그램의 버그가 아님을 사용자가 알 수 있게 했다.

(4)
좀 어이없는 실수이긴 한데..
드보락이라는 영문 글쇠배열을 만든 사람은 미국의 교육심리학자인 '어거스트 드보락' 박사이다. Dvorak Simplified Keyboard라는 이름으로 이 글쇠배열이 공표된 것은 1932년이고 특허를 얻은 것은 1936년이다.
하지만 지금까지 <날개셋> 한글 입력기의 빠른설정 UI와, 타자연습 도움말의 '세벌식과 드보락의 관계는?'에는 이게 '안톤 드보락이 1930년에 고안한 글쇠배열'이라고 잘못 소개되어 있었다.

이 사람의 이름은 체코의 작곡가 이름인 '안토닌 드보르작'과 매우 혼동되는 편인데, 그거 영향을 받은 것 같다.
우연히 간단한 구글링을 하다가 이 사실을 발견하고는 바로잡았다. <날개셋> 한글 입력기와 타자연습의 다음 버전에서 반영될 것이다.
이거 실수의 근원을 추적해 보니.. 어이없게도 아래아한글의 도움말이었다. 2007 버전만 해도 글자판 소개에서 드보락 설명을 보면 "쿼티 글자판의 단점을 보완하여 1930년 안톤 드보락 박사가 고안한 글자판"이라고 설명되어 있기 때문이다.

Posted by 사무엘

1. 들어가는 말

오늘날의 거대하고 복잡한 운영체제와는 달리, 도스는 이니셜 D-_-가 암시하듯이 달랑 플로피디스크 한 장만으로 부팅이 가능할 정도로 참을 수 없이 작고 가벼웠다. 정말 필수불가결인 파일은 부팅에 쓰이는 io.sys, 그 뒤 셸 역할을 하는 텍스트 명령 해석기인 command.com이 전부다.
msdos.sys라는 파일도 있는데 얘는 정확하게 무슨 존재인지 모르겠다.

그리고 사실은 config.sys의 DEVICE 명령을 통해 실행되는 sys 파일과, com 실행 파일이 서로 무슨 차이가 있는지도 모르겠다. 마우스, 그래픽 카드 에뮬(simcga, msherc ^^), 사운드(sound, unsound) 같은 여러 램 상주 드라이버들은 com이었지만, 씨디롬 드라이브는 sys였으며 그것도 주 메모리를 꽤 많이 차지하는 드라이버였다. 단, 부팅 후에 sys 파일을 별도로 실행해 주는 유틸리티가 있기도 했다.

디스크로부터 파일을 읽으려면 파일 시스템이 정립돼 있어야 하며, 이건 운영체제가 하는 일 중 하나이다. 그런데 그 운영체제를 로딩하는 프로그램도 파일 형태로 저장돼 있다. 이런 '닭이 먼저냐 계란이 먼저냐' 딜레마를 해소하기 위해서는, 부팅에 쓰이는 운영체제 프로그램은 디스크에 단순히 파일 형태로만 존재하는 게 아니라, 컴퓨터 바이오스가 물리적이고 원초적으로 인식 가능한 첫 지점에 저장돼 있어야 한다. 이건 굳이 도스뿐만 아니라 어느 운영체제라도 마찬가지이다.

도스는 단일 사용자 단일 프로그램 구동 체계이다 보니, 한 프로그램이 그야말로 컴퓨터 하드웨어를 전부 있는 그대로 조종 가능하게 허용하는 백지수표, 열린 허허벌판 같은 환경이었다. 프로그램의 인터페이스도 명령 기반, TUI, GUI 등 제각각이었고 정말 창의적이었다. 요즘 프로그램들만치 UI가 획일화됐다는 느낌이 없이 형형색색 컬러풀했다.

물론 그건 거시적인 관점에서는 그리 효율적이지 못하다. 이런 빵빵한 컴퓨터 자원에서 여러 프로그램을 동시에 실행하고 작업 전환을 할 수 없다면 그것도 컴퓨터에 대한 예의-_-가 아니다.
그러니 운영체제가 더 강력하게 모든 걸 통제하는 지금 같은 환경으로 궁극적으로는 바뀌는 게 맞긴 하지만.. 인제 와서 도스가 다시 새삼스럽게 그리워질 때도 있다.

2. 역사

본인이 경험한 MS-DOS의 가장 옛날 버전은 학교 내지 컴퓨터 학원에서 봤던 3.2/3.3이다. 2.x 이하나 4는 실물로 구경을 못 해 봤다. 다만, 5.0과 6.2는 집 컴퓨터에 내장돼 있던 물건이다 보니 개인적으로 친숙하다.

1981년에 첫 출시되었다고 전해지는 MS-DOS 1.0은 그야말로 정말 골동품 폐물이었다고 한다. 그리고 Windows 1.0이 프로그램 창을 겹치게 배열하는 걸 지원하지 않았다면, DOS 1.0은 디스크에 서브디렉터리를 만드는 걸 지원하지 않았다..;;
그나마 도스가 최소한의 도스다운 틀을 갖춘 건 2를 거쳐서 3.x대에 와서부터이다. 특히 5.25내지 3.5인치 고밀도(1.2, 1.44MB) 플로피디스크를 지원하기 시작한 첫 버전이 이 버전이기 때문이다. 3.x에 와서야 좀 물건다운 물건이 나왔다는 점에서는 도스와 Windows가 역사가 서로 비슷한 것 같다.

그 다음 4.0의 아주 기념비적인 업적은 파일 시스템이 FAT12에서 FAT16으로 확장되어, 이론적으로 지원 가능한 디스크 볼륨의 용량이 2GB로 커진 것이다.
그 시절에 기가바이트는 가히 꿈의 규모였기 때문에 홍보 자료에서는 그냥 '제한이 없어졌다'라는 표현이 관용적으로 쓰였다. 참고로, FAT12 시절의 하드디스크의 용량 한계는.. 고작 32MB였다. =_=;;

또한 MS-DOS shell이라고 나름 드래그 드롭도 지원하고 Windows GUI를 어설프게 베낀 듯한 파일 관리자 셸이 추가된 것도 4부터이다. 하지만 MS-DOS 4는 구체적인 내역은 모르겠지만 불안정하고 버그가 많아서 좀 문제작으로 남았다고 한다.

도스 5.0에서 기념비적인 업적은 그 이름도 유명한 HIMEM.SYS와 DOS=HIGH일 것이다. EMM386은 4.0 때 SYS 버전이 있었지만 5.0부터는 EXE로 형태가 바뀌었다고 한다.
또한 이 버전에서는 과거의 불편하던 EDLIN을 대체하는 QBASIC 기반의 텍스트 에디터가 추가되었으며, 명령 프롬프트에서 cursor 이동을 자유롭게 할 수 있게 하고 히스토리 기능도 넣어 주는 DOSKEY 유틸도 이때 추가됐다.

지워진 파일을 첫 글자 이름을 집어넣어서 복구하는 undelete 역시 아마 6이 아닌 5에서 첫 추가됐지 싶다. 이건 PC-tools나 노턴 유틸리티가 먼저 제공하던 꼼수 기능이었는데 동일 기능을 도스에서 직접 수용한 것이다.

그 뒤 6.0은.. 변한 게 많았다.
가장 유명한 건 하드 디스크를 압축해 주는 '더블 스페이스'라는 유틸리티의 도입이다.
이건 무슨 요술을 부리거나 하드 디스크를 물리적으로 어떻게 하는 게 아니라, 그냥 파일 시스템 차원에서 데이터를 zip 같은 소프트웨어 압축을 적용하는 것일 뿐이다. 당장 용량 확보에는 도움이 되지만 디스크의 액세스 속도가 좀 느려지고 에러에 취약해지며, 하드웨어를 좀 험하게 다루는 일부 프로그램과는 트러블의 여지가 생긴다.

참고로 1993~1994년이면 Windows 3.1이 보급되고 어지간한 PC의 하드디스크는 몇백 MB 정도이던 시절이다.
더블 스페이스는 그렇잖아도 꽤 중요하고 민감한 간판 기능인데, 버그를 많이 잡고 안정화를 더 시켜서 6.2가 나왔다.
그런데 이게 '스태커'라는 타사의 제품을 무단 도용한 것으로 판결이 나서 '더블 스페이스'를 뺀 6.21이 나왔고, 저작권 문제를 해결하여 '드라이브 스페이스'를 대신 도입한 6.22로 6.x대가 마무리 되었다. 지금이야 마소에 대해서 IE 브라우저의 독점 소송이 유명하지만, 1990년대 중반엔 저거 저작권 침해 소송이 IT 업계에서 굉장한 화두였다.

압축 유틸리티 말고도 6.x대엔 멀티 부팅이라는 매우 유용한 기능이 추가됐다. 즉, C/C++의 조건부 컴파일처럼 사용자가 선택한 옵션 방식대로 디바이스 드라이버를 로딩하여 부팅할 수 있게 됐다는 것이다.
그리고 디스크 점검 scandisk, 조각 모음 defrag, 시스템 점검 msd, 주 메모리 확보 유틸리티 memmaker 등이 추가되고 PC-Tools로부터 라이선스 받은 안티바이러스 msav 같은 유틸도 도입됐다. 덕분에 노턴 유틸리티가 예전보다는 좀 덜 필요해졌다.

모든 내부/외부 명령에 /? 옵션을 줬을 때 도움말이 나오는 것도 처음부터 존재한 게 아니었다. 6이거나 아니면 5부터인데 그건 정확하게 기억이 안 난다. 옛날에는 도움말 텍스트를 일일이 내장시켜 줄 정도로 컴퓨터의 메모리나 디스크 용량이 충분하지 못했기 때문이다.

단독 제품으로서 MS-DOS의 역사는 1994년에 출시된 6.22가 끝이었다. 도스는 Windows 95/98/ME와 함께 7.0. 7.1. 8.0 버전으로 명맥을 유지하다가 2000년에 드디어 20여 년의 긴 수명을 마치고 역사 속으로 사라졌다.
도스 외부 명령어 중에서 몇몇 필요한 건 Windows 9x 계열에서는 Windows\command로 갔고, NT 계열은 그냥 system32 디렉터리에 있다. 그리고 NT 계열은 format이나 diskcopy 같은 유틸리티도 콘솔에서 실행될지언정 도스가 아니라 Windows용 프로그램이라는 차이가 있다.

3. 그 당시의 유사품/경쟁자

한편, 도스의 바리에이션으로는..
PC-DOS는 그냥 MS-DOS가 IBM 브랜드만 달고 나온 동일 제품이었다고 한다. 한동안 그러다가 6.x대부터는 서로 다른 길을 가기 시작했는데 이미 그때는 PC 환경이 Windows로 충분히 넘어가기 시작했으니 별 의미는 없다. 따지고 보면 IBM은 OS/2가 망한 데다, 도스 분야도 뒷북으로 끝나고 별 재미를 못 본 셈이다. "IBM 호환 PC"라는 걸출한 대인배 이름만 남긴 채 PC 시장에서는 철수했다.

DR-DOS는 MS-DOS의 전신인 CP/M을 직접 만든 게리 킬달이라는 엔지니어가 '디지털 리서치'라는 회사를 세워서 따로 만든 MS-DOS의 대항마이다. '디알'이지 '닥터 도스'는 아님.. 뭔가 기능이 MS-DOS보다 뛰어났다고 얘기는 들었는데 구체적인 내역은 잊어버려서 기억이 안 난다.
DR-DOS를 '노벨' 사가 인수하여 새로 내놓은 것이 '노벨 도스'이며, 이건 1990년대 초중반까지 나왔다.

한편, 4DOS는 커널을 처음부터 새로 만드는 건 아니고 명령 인터프리터인 COMMAND.COM만 대체하는 기능 확장판으로 컴덕들에게 많이 알려져 있었다. 이걸 시먼텍(Symantec) 사에서 인수하여 자신들이 인수한 다른 유명 솔루션인 '노턴 유틸리티'에다가 집어넣은 것이 NDOS이다. 각종 도스 명령들에서 2% 부족하던 것을 보완하는 편의 기능이 굉장히 많았던 걸로 기억한다. (가령, 중간에 파일이 사라져도 괜찮은 batch-to-memory 배치 파일)

그리고 8.3 짧은 파일 이름의 한계를 보완하기 위해, 내부적으로 descript.ion이라는 숨김 파일을 만들어서 파일명에 대한 '주석'을 표시하는 것도 4DOS의 작품이었다. 옛날에 MDIR도 이걸 지원했다. 파일이 복사· 이동· 개명· 삭제됐을 때 주석도 같이 관리하는 게 좀 번거로운 일이 됐으니까.. NTFS처럼 운영체제의 파일 시스템 차원에서 메타데이터를 관리하는 기능이 없으면 어쩔 수 없이 셸 유틸리티가 뒷감당을 해야 한다.

4. MS-DOS의 한글화

MS-DOS가 최초로 한글판이 나온 것도 2나 3 버전부터이지 싶다. 정말 먼 옛날에는 마소가 잠깐 동안 조합형 코드 기반으로 도스를 한글화화기도 했다는데 지금으로서는 거의 Windows 2.1의 한글판 같은 도시전설이 돼 간다.
허나, 1987년에 지금의 KS X 1001, 그 당시의 KS C 5601 완성형이 제정되자마자 표준을 잘 지키는 마소는 완성형으로 광속으로 갈아탔다. 그게 이미 도스 3 시절의 일이다. 마소는 그냥 표준을 따른 것일 뿐이지만, 결과적으로 조합형 코드를 죽이고 한글을 파괴한 원흉(?)으로 일부 진영으로부터 좀 지탄받곤 했다.

그런데 한글 MS-DOS가 텍스트 모드에서 한글 입출력을 구동해 주는 바이오스 유틸리티를 처음부터 내장하고 있지는 않았던 것 같다. 쉽게 말해 hbios와 그 특유의 바탕체 글꼴을 구경한 건 최소한 도스 5나 6부터이다. 3이나 4 시절에나 그런 게 없었으며, 한글 바이오스는 다른 프로그램으로 구동했었다. 이건 내 기억이 잘못됐을 수도 있음.

hbios는 Windows 95로 가면서 mshbios로 이름이 바뀌었으며, 그 당시의 고유 글꼴은 <날개셋> 편집기에 '마소바탕'이라는 글꼴을 통해 구경할 수 있다. 도깨비나 태백한글 같은 싸제 한글 바이오스들은 조합형/완성형, 두벌식/세벌식, 명조/고딕 등 글꼴과 글자판과 코드를 다 선택 가능했지만, 마소의 보급 바이오스는 당연히 완성형, 두벌식, 명조로 다른 선택의 여지가 없었다.

전에도 한번 얘기한 적이 있었지만, 마소에서 한글화한 프로그램들은 2바이트 문자에 대한 처리가 굉장히 잘 돼 있었다. 2바이트를 구성하는 앞뒤 문자 중 하나가 가려지거나 지워지면 다른쪽 문자도 반드시 같이 사라졌기 때문에 텍스트 모드에서 메뉴나 대화상자가 표시될 때도 문자가 깨지는 걸 보이는 법이 없었다. 이에 대한 처리가 세심하게 돼 있었다.

5. 도스 시절의 멀티태스킹

비록 그래픽은 아니고 텍스트 기반이긴 하지만, Windows 3.x 비스무리한 도스 기반 멀티태스킹 운영환경(운영체제는 아니고..)으로 DESQView 같은 프로그램이 있었다. 난 이름만 들어 보고 실제로 구경은 못 했다. 외국에서는 그럭저럭 쓰는 사람이 있었던 듯하지만 Windows의 등장 이후에는 조용히 역사 속으로 사라졌다.

그리고 사실은 더 발전된 멀티태스킹 운영체제를 마소에서 직접, 그것도 Windows나 OS/2와는 별개로 만들려는 시도를 한 적이 있었다. 무려 1986년, Windows조차 이제 막 개 허접한 1.0이 나왔던 시절에 MS-DOS 3을 기반으로 일명 '멀티태스킹 MS-DOS 4.0'이 계획되었던 것이다. 이것은 앞서 언급한 그 도스 4.0과는 무관한 새로운 개발 브랜치였다.

멀티태스킹 MS-DOS 4는 제품이 나오기는 했고 의도도 나쁘지 않았지만, 1980년대 중반에 시대를 너무 앞서간 문제작이었다. 그 옛날에 그 열악한 하드웨어 환경에서 도대체 뭘 더 바라겠는가? 컨셉에 비해 상품성이 떨어졌다.
게다가 그 당시 마소는 지금처럼 독자적인 불특정 다수용 유명 소프트웨어를 독점 판매하는 공룡 기업이 아니었으며, 여전히 하드웨어 제조사에다 소프트웨어를 납품하면서 먹고 사는 기업이었다. 즉, 지금으로서는 상상이 잘 안 되지만, 업계에서의 위상이 '갑'이 아니라 '을'이었다.
프로젝트를 발주했던 IBM이 이 물건을 더 구입해서 사용하지 않겠다고 선언하자 프로젝트는 흑역사가 되었고, 이 멀티태스킹 MS-DOS 4는 오히려 유럽의 일부 컴퓨터에 OEM 형태로 공급되는 걸로 개발 계보가 끝났다.

멀티태스킹 MS-DOS 4는 비록 GUI 환경은 아니지만 Windows의 전유물로만 알려졌던 NE (new executable) 실행 파일도 지원하고 지금으로서는 무척 신기한 면모가 많았다고 한다. 정작 NE를 사용하던 Windows는 NT가 등장하기 전에는 콘솔 모드라는 게 없었는데, GUI 기반이 아니던 멀티태스킹 도스가 NE를 어떤 형태로 사용했는지 궁금하다.

6. 맺는 말

도스 시절에 메모리 관리를 하는 건 요즘으로 치면 연봉별로 돈 관리하는 요령과 비슷했다. 램이 1MB 이하일 때, 2MB일 때, 4MB일 때, 8MB 이상일 때... HIMEM.SYS와 EMM386을 세팅하는 법, 기본 메모리를 최대한 확보하는 법, 메모리가 왕창 많이 있다면 램 드라이브와 디스크 캐시를 운용하는 요령 등.. 그런 게 1990년대 컴퓨터 잡지들이 고급 정보랍시고 많이 다룬 정보였다.
지금으로서는 그저 격세지감이 느껴질 뿐이다. 그 당시에 기본 메모리라는 개념은 돈에다 비유하자면 당장 손에 있는 현금이고, 나머지 확장 메모리는 통장 잔고나 신용카드 같다는 생각도 든다. =_=;;

MS-DOS의 역사를 살펴보면 많은 걸 느낀다. 금수저 출신의 독종에 천재에 똘끼와 운, 엔지니어 기질과 사업가 기질을 모두 갖고 있는 사람이라면 무슨 여건에다 던져 놔도 결국은 성공했겠다 싶다. 공부만 계속했어도 교수나 변호사가 됐을 사람이 결국은 소프트웨어의 황제로 등극해서 교수· 변호사보다 더한 억만장자가 됐으니까.

물론 빌 역시 그 과정에서 언제나 실력만으로 정정당당하게 승부하지는 않았으며, 경쟁자 치사하게 죽이기 같은 짓을 전혀 안 했다는 건 아니다. MS의 모든 기술과 제품이 100% 빌의 머리에서 비롯된 원천기술인 건 아니며, 그가 미래에 대해 예측한 것이 전부 적중한 것도 아니었다. 그래도 그는 자기보다 더 똑똑한 엔지니어들을 한데 통솔하고 이끌어서 시너지 효과를 잘 낼 줄을 알았다. 그리고 실수를 하고 병크를 저지르더라도, 회사를 완전히 말아먹을 정도로 치명적으로 하지는 않았으며 곧 수습했다.

한편, 게리 킬달은 뭔가 스티브 워즈니악 같은 포스가 느껴지는 공돌이로 보이는데, 실력에 "비해" 빛을 못 보고 좀 어이없게 훅 가 버린 게 안타깝게 느껴지기도 한다.
기술만 있고 너무 고지식하기만 하면 저렇게 되기 쉬운데, 나부터가 딱 그런 스타일이라는 게 문제임.. -_-;;

Posted by 사무엘

오늘날이야 우리들의 눈을 현혹하는 온갖 사진과 짤방, 동영상들이 인터넷을 통해 컴퓨터로 현기증 날 정도로 범람하고 터져 나가는 시대이다.
하지만 불과 2~30년 전만 해도 PC는 글이 아닌 그림을 처리하기에는 용량과 성능이 꽤 버거운 물건이었다. 컴퓨터로 뭔가 실사 사진 자체를 구해다 보기가 쉽지 않았다. PC 통신으로 인기 연예인 사진을 단 한 장 다운로드 해서 보는 것조차도 단단히 작정하고 기다릴 준비를 하고서 해야 했다. 그리고 그것도 출처는 종이 화보나 필름 사진 스캔, 또는 아날로그 TV 화면 캡처였다..

21세기에 태어난 애들이 이런 얘기를 듣는 건.. 우리 세대가 부모님에게서 1950, 60년대에 나라가 얼마나 폐허였고 못살았는지를 듣는 것과 비슷한 느낌일 것이다. 아아~ 나도 이런 식으로 올드 타이머 꼰대의 대열에 합류하는구나..;;
그래도 난 옛날 컴퓨터 환경 회상이 좋다. 그러니 얘기를 계속하겠다.

그 시절엔 bmp, pcx를 넘어 gif 정도만 돼도 디코딩이 만만한 작업이 아니었다. 아래아한글 도스용에서 그림을 삽입해 보면 gif는 유독 렌더링이 더뎠다. 그런데 하물며 jpg는... 전용 뷰어가 필요하고 386에 램 얼마 이상, 부동소수점 코프로세서는 필수 이런 걸 요구하는 엄청난 포맷이었다. png 역시 그 당시로서는 신생인 만만찮게 무거운 포맷이었고.

이런 이유로 인해 도스에서 그래픽 뷰어는 나름 단순 텍스트/헥스 뷰어 이상의 유니크함과 전문성(?)을 지녔고 또 그래픽 에디터와는 별개의 입지를 가진 프로그램이었다. GUI 운영체제의 셸이 제공하는 기본 중의 기본, 필수 중의 필수 기능이 그때는 그렇게나 특별한 기능이었다. 도스까지 갈 것도 없이 무려 Windows 95 시절, 웹 브라우저 같은 게 없던 때엔 운영체제 차원에서 jpg 파일을 바로 볼 수 있지 않았다. 그림판은 bmp/pcx 전용이었으니까.;;

그래픽 뷰어는 완전 상업용 제품이라기보다는 셰어웨어로 만들기에 좋은 소재였다. 디렉터리 이동 + 파일 리스트 선택 기능을 구현한 뒤, 사용자가 엔터를 누르면 그 그림을 표시해 주는 게 기본 형태이다.
그런데 그것만으로는 좀 단조로우니 그래픽 뷰어에는 여러 장의 그림을 슬라이드 쇼처럼 보여주는 기능이 응당 추가됐다. 현란한 화면 전환 효과는 덤이고. 요즘 같으면 화면 보호기와 역할이 비슷해졌다.

비주얼 쪽 말고 다른 방면으로는.. 파일 관리 기능이 있다는 점에 착안하여 단순히 뷰어 이상으로 많은 그림 파일들을 일괄적으로 포맷을 변환하고 크기를 보정하고 효과를 주는 기능이 들어갔다. 이건 전문적인 그래픽 에디터와도 기능이 겹치는 구석이 있지만, 이쪽은 드로잉 기능이 없으며 한 파일이 아니라 여러 파일들에 대한 일괄 편집에 더 최적화되었다.
이런 분야에 속하는 프로그램으로 본인은 현재까지 다음과 같은 제품들을 기억하고 있다.

1. Graphic Workshop

모 컴퓨터 잡지/서적을 통해 알게 됐다. 1990년대 초인 꽤 옛날부터 개발되어 온 프로그램이며, 내 기억이 맞다면 GIF를 굉장히 일찍부터 지원해 온 걸로 유명했다.
스크린샷을 보면 알 수 있듯, 전반적으로 셸은 파란 배경의 단순한 텍스트 모드에서 동작했고 단순 표시뿐만 아니라 포맷 변환, 크기 조절 같은 그림 파일 관리 기능도 갖추고 있었다.

1989년에 처음 개발됐는데 91년에 벌써 버전이 6을 넘어간 건 도대체 개발과 버전업이 어떻게 돼 왔다는 뜻인지 모르겠다. MS Word는 다른 제품과 번호를 맞추기 위해서 2에서 바로 6으로 넘어가긴 했다만..;;
개발사인 Alchemy Mindworks라는 회사는 지금도 살아 있으며, 이 프로그램은 Windows용으로 계속 개발 중이다.

2. SEA

그래픽 뷰어 중에서는 느낌이 굉장히 인상적이었다. 일단, 왓콤 C/C++ 32비트 에디션으로 만들어진 덕분에, 게임도 아닌 것이 첫 실행 때 DOS/4GW(도스 익스텐더) 로고가 떴다.
성능면에서는 jpg 파일의 디코딩이 경쟁 프로그램들 중 가장 빠르다고 자처했다. 그림뿐만 아니라 소리 파일 재생이 됐으며, 동영상도 AVI 중에 1990년대 중반 런렝쓰 정도의 간단한 방식으로 압축 된 건 바로 재생 가능했다.

스크린샷을 보면 알 수 있듯 일괄 변환과 슬라이드 쇼 기능 정도는 물론 갖추고 있었으며,
이 모든 것에 더해서 전반적인 GUI 껍데기도 NextStep 운영체제를 흉내 낸 듯한(바탕에 검정 제목 표시줄) 상당한 고퀄이었다.
여러 모로 인상이 좋고 장인 정신이 느껴지는 잘 만든 프로그램이었다. 비등록 셰어웨어 버전도 첫 실행 때 '등록 해 주세요. press any key'가 뜨는 것 말고는 별다른 제약이 없어서 상당한 대인배이기까지 했다.

3. ACDSee

운영체제에 gif/jpg/png급 그림 파일을 보는 기능이 자체적으로 없던 Windows 95~98/2000 시절에는 개인적으로 이 프로그램을 유용하게 썼다. 이름이 똑같이 '씨'인데 앞의 도스용 프로그램은 sea이고 요 프로그램은 see이다.
얘도 한때는 내가 운영체제를 새로 설치한 뒤에 MDIR만큼이나 곧장 설치하는 필수 프로그램 중 하나였다. 굉장히 유용하게 썼다. SEA의 Windows 버전이나 마찬가지였는데, 해당 기능을 운영체제가 흡수한 뒤에는 정말 자연스럽게 존재감이 싹 없어져 버렸다.

그 첫 신호탄은 Windows에 IE 웹브라우저가 포함돼 들어가면서 기본적인 그래픽 뷰어 문제는 사실상 제공되기 시작한 사건이다. 월드 와이드 웹이라는 게 글과 그림으로 이뤄져 있으며 웹브라우저는 그 자체가 훌륭한 단백질 공급원은 아니고 훌륭한 그래픽 뷰어였기 때문이다. 단, IE는 옆 파일을 바로 열람하는 기능조차 없고 진짜 보는 것 하나만 가능하기 때문에 전문 뷰어/슬라이드 쇼 프로그램이 여전히 존재 의미가 있었다.

한 디렉터리 안에 있는 그림 파일들을 IE 창에서 쭈욱 열람하기 위해서 그 디렉터리를 기준으로 <img src="...."/> 태그를 쭈욱 나열하는 html 파일을 '생성하는 프로그램'을 짜서 개인적으로 활용했던 기억이 있다. 물론 이건 썸네일만 읽어들이는 게 아니라 파일들을 몽땅 한 페이지에다 읽어들이는 것이니 성능면에서는 좀 안습한 짓이긴 하다.

그리고 둘째 확인사살은 Windows XP이다. 얘부터는 탐색기 내부의 파일 리스트에서 그림 썸네일을 보는 편의 기능이 크게 강화되었으며, 그럭저럭 가볍고 괜찮은  그래픽 뷰어까지 내장됐기 때문이다. 그러니 별도의 싸제 그래픽 뷰어 프로그램에 대한 필요는 거의 사라졌다. 이런 이유로 인해 기존의 그래픽 뷰어들은 생존을 위해서 포토샵 같은 이미지 보정 기능을 더 강화한다거나 디지털 카메라 사진 관리 같은 더 차별화되고 전문적인 영역으로 넘어갔으며, 내 기억 속에는 현업에서 다들 물러나고 추억의 영역만 남게 되었다.

한때는 Paint Shop Pro에 내장돼 있는 Browse 기능도 유용하게 썼던 것 같은데 지금은 그냥 MS Office에서도 2003부터 Picture Manager라는 유틸리티가 생겨 있다. 예전에는 희귀했던 기능들이 지금은 다 기본으로 내장되고 대중화가 된 것이다.
단, Windows XP의 기본 그래픽 뷰어는 애니메이션 GIF를 재생하는 것까지도 지원했는데 Vista 이후부터는 그 기능은 없어졌다. 왜 빠졌는지는 알 길이 없다.

여기까지가 그래픽 뷰어 프로그램에 대해 본인이 갖고 있는 추억이다.
하긴, 음악을 듣는 것도 한때 꽤 먼 옛날엔 거원 제트오디오, WinAmp 같은 프로그램을 따로 썼다. 그러다 언제부턴가 그냥 WMP만 쓰지 다른 건 안 쓰게 됐다.
그래도 동영상은 WMP가 코덱과 자막 등 부족한 구석이 많이 있어서 팟/곰 같은 제3자 프로그램이 여전히 살아 있다. 내가 알기로 마소에서 WMP도 거의 IE11만큼이나 이제 더 만들 게 없는지 별로 육성은 안 하는 것 같다.

Posted by 사무엘

1.
코코아, Win32 API, MFC 같은 플랫폼 종속적인 API를 전혀 쓰지 않고 순수하게 표준 C/C++ 라이브러리 함수만으로 백 엔드 엔진만 만들었다 해도 Windows + Visual C++로 작성한 코드가 안드로이드 내지 맥 같은 다른 플랫폼에서는 곧장 컴파일 되지 않거나, 빌드된 프로그램이 의도한 대로 동작하지 않을 수 있다.

개인적으로는 회사에서 wchar_t 때문에 굉장한 불편을 겪었다. 잘 알다시피 Windows에서는 이게 2바이트이지만 다른 플랫폼에서는 4바이트이다. 플랫폼을 불문하고 2바이트 문자 단위로 동작하는 strcpy, strcat, strlen, printf, atoi 등등은 직접 구현이라도 해야 하는지..? 특히 파일로 읽고 쓰려면 말이다.

C++ string 클래스야 typedef std::basic_string<unsigned short> string16; 부터 먼저 만들어 놓고 썼다지만 그렇게 처음부터 객체를 만드는 게 아니라 raw memory를 다루는 상황에서는 해결책이 되지 못한다.

이런 게 원초적인 애로사항이고 또, 소스 코드 내부에서 유니코드 문자열 상수를 표현하는 방식도 또 다른 난관이다.
언어가 제공하는 L"" 문법은 wchar_t형 기반이다. 그러니 wchar_t 말고 명시적으로 unsigned short 배열에다가는 문자열 상수를 쓸 수 없고 "가"를 { 0xac00, }로 표현하는 식의 삽질을 해야 한다.

거기에다 비주얼 C++은 C++ 소스 코드나 명령 프롬프트가 UTF8과 전혀 친화적이지 않다는 다른 문제점도 있어 더욱 불편하다. 유니코드가 등장하면서 플랫폼별로 문자열을 다루는 방식이 너무 심하게 파편화됐다는 생각이 든다.
문자열을 저장하고 메모리를 관리하는 방식이 난립하는 것 말고(string class!) 문자열을 구성하는 문자를 표현하는 방식 그 자체부터가 말이다.

2.
하루는 Visual C++에서 표준 C 함수만 사용해서 만들어 준 코드를 안드로이드 내지 맥 OS 플랫폼으로 넘겨 줬더니 컴파일 에러가 났다. wcslen 함수가 선언되지 않았다고 꼬장을 부리는데 도무지 원인을 알 수 없었다. strlen은 인식되는데 wcslen은 왜 인식이 안 되는 거지?

그런데 알고 보니 wcslen은 strlen과는 달리 string.h가 아니라 wchar.h에 선언되어 있었다.
Visual C++은 string과 wchar에 wcslen을 모두 선언해 줬지만 타 플랫폼은 그렇지 않았다. 흐음~ 나의 불찰이다.

malloc/free 함수는 stdlib.h에도 있고 malloc.h에도 있다.
memset/memcpy는 string.h에도 있고 memory.h에도 있다.
그런 예가 몇 가지 있는 건 알고 있었지만 wcs* 함수는 Visual C++에만 string/wchar 겸용으로 선언돼 있었던 듯하다.
C 인클루드 헤더는 한 함수가 오로지 한 헤더에만 유일하게 존재하지는 않기도 하다는 것이 흥미롭게 느껴진다.

3.
요즘 표준 라이브러리들의 헤더 파일을 보면 함수의 인자마다 타입과 이름만 있는 게 아니라 소스 코드 정적 분석을 위한 Annotation 정보가 같이 들어있다. 같은 포인터라 해도 이건 읽기 전용, 쓰기 전용.. 쓴다면 어떤 조건으로 얼마만지 써지는지(옆의 인자만큼~) 같은 거.

그래서 함수 하나만 봐도 선언도 정말 덕지덕지 길어졌다. 이 정보들이 처음부터 있지는 않았을 텐데, 그 수많은 API들의 선언에다 일일이 다 기입하는 건 완전 중노동이었을 것 같다.
한때는 정적 분석 기능은 개발툴의 유료 최상급(엔터프라이즈 같은) 에디션에서나 접근 가능한 고급 기능이었는데, 이것도 죄다 무료로 풀리는 듯하다. 유료 GUI 툴킷이 통째로 MFC에 들어갔듯이 말이다.

4.
요즘은 CPU 아키텍처야 x86 아니면 ARM만 살아 남아서 그런지, 이식성을 논할 때 비트 순서, 일명 endian-ness 얘기는 별로 안 나오는 것 같다. 우리 주변에서 흔히 볼 수 있는 x86은 요지부동 리틀 엔디언인 반면, 옛날에 매킨토시의 밑천이던 PowerPC는 빅 엔디언이었다. 트루타입 폰트 포맷이 빅 엔디언 기반인 건 이런 애플의 영향력이 닿아서 그랬던 걸까?

먼 옛날 대학 시절에 터미널에 원격 접속해서 거기서 C 컴파일러를 돌려 봤던 게 본인으로서는 빅 엔디언 컴퓨터를 직접 구경한 처음이자 마지막 경험이다. 큰 자릿수가 앞부분부터 저장되다니 굉장히 신기했다. 이건 앞으로 수동 변속기 차량이라든가 IA64 (Itanium) 컴퓨터만큼이나 앞으로 또 접할 일이 없는 초희귀템으로 남을 것 같다.

최신 CPU인 ARM은 하드웨어 차원에서 endian-ness를 모두 지원하기 때문에 아무 쪽으로든 취사 선택이 가능하다고 한다. 사람으로 치면 완벽한 양손잡이이고, 철도에다 비유하자면 좌측/우측통행 전용 복선 철도가 아니라 어느 쪽으로든 운용 가능한 단선병렬과 비슷한 격이다.
결국은 다 지원하는 것으로 가는구나. 한글 코드에서 조합형/완성형 논쟁, CPU 미시구조에서 CISC/RISC 논쟁, 리눅스에서 그놈/KDE 셸 논쟁도 다 비슷한 방식으로 종결됐듯이 말이다.

비트 순서 같은 하드웨어 특성을 타는 요소 말고 소프트웨어 플랫폼과 언어 차원에서.. 사소하지만 코드의 이식성을 은근히 저해하는 요소는 내 경험상 몇 가지 있었다. 그러니 GUI가 없고 특정 운영체제의 API를 사용하지 않았다고 해서 무작정 이식이 잘 될 거라고 기대할 수는 없다.

5.
당장 떠오르는 건, 64비트 상수를 나타내는 % 문자가 파편화돼 있다(%I64d, %lld). 그리고 long이 Windows에서는 64비트 플랫폼에서도 여전히 32비트이지만 타 플랫폼은 그렇지 않다. 그러니 이식성을 생각한다면, long은 파일 오프셋 계산에 영향을 주는 곳에서는 절대로 구조체 멤버로 쓰이거나 sizeof의 대상이 돼서는 안 된다. (앞서 논했던 char_t도 마찬가지이고!) 그런 데서는 정말 닥치고 int32, uint64처럼 비트수를 명시한 typedef를 쓰는 게 안전하다.

C#이나 Java, D는 아무래도 1990년대 중후반에 PC에서 32비트 CPU 정도는 확실하게 정착한 뒤에 등장한 최신 언어이다 보니, 32/64비트 플랫폼을 불문하고 long이 처음부터 일관되게 64비트였다. 하지만 C/C++은 그보다 훨씬 전부터 컴퓨터 하드웨어의 발전의 격변기와 동고동락했던 언어이다 보니, 저런 깔끔함을 기대할 수는 없는 노릇이 돼 있다.

그리고, fopen에다 주는 옵션에서 r/w/a (+)만 있고 b/t 모드가 지정되지 않았을 때..
Windows는 binary 모드로 동작하는 반면 맥에서는(타 플랫폼은 확인 안 해 봄) 디폴트가 text였다. 멀쩡한 코드가 완전 엉뚱하게 동작하고 파일이 쓰라는 대로 써지지 않고 읽으라는 대로 읽히지 않아서 한창 문제를 추적했더니.. 결국은 이런 데에서 차이가 있었다. 이것도 표준 규격이 정의돼 있지 않나 보다.

말이 나왔으니 말인데, Visual C++은 fopen조차 쓰지 말고 fopen_s를 쓰라고 권한다. printf_s, qsort_s 같은 *_s 물건은 안전하고 편리하긴 하지만 언제까지나 이식 불가능한 Visual C++만의 전유물로 남을지 궁금하다..

strdup와 _wcsdup는 표준처럼 생겼지만 진짜 표준인지 아닌지 알쏭달쏭한 놈이다. 앞에 괜히 밑줄이 있는 게 아니다. _wtoi 이런 것도 Windows를 벗어나면 컴파일되지 않을 가능성이 높은 지뢰이니 strtol, wcstol을 쓰는 게 안전하다.
strtok의 경우 Visual C++은 토큰 컨텍스트를 따로 받는 _s 버전을 추가한 반면, 타 플랫폼은 strtok, wcstok 함수 자체가 그렇게 고쳐진 것도 있다. 이런 것들도 너무 골치아프다.

6.
끝으로, 이건 이식성하고는 큰 관계가 없는 얘기다만..
형변환 연산자인 static_cast는 코드 생성 차원에서 하는 일이 전혀 없거나(base class* → derived_class*, enum → int), 뻔한 값 보정(float → int, char → int), 또는 다중 상속일 때는 컴파일 타임 때 결정된 고정된 상수만치 this 포인터 보정 정도만(derived_class_B* → base_class) 하는 걸로 으레 생각했다.

그런데 다중 상속을 다룰 때 꼭 그런 일만 하는 건 아니다. 포인터가 처음부터 NULL이었다면, 거기서 또 얼마를 뺄 게 아니라 cast된 포인터도 그냥 NULL을 주는 예외 처리를 해야 한다. 과연 생각해 보니 그렇다. 아래 코드를 생각해 보자.

struct A { int a,b; };

struct B { int c,d; };

struct C: public A, public B { int e,f; };

void foo(B *pm) { printf("Received %p\n", pm); }

int main()
{
    C m, *pm=&m;
    printf("Passing %p\n", pm); foo(pm);
    pm=NULL; printf("Passing %p\n", pm); foo(pm);
    return 0;
}

단일 상속과는 달리, 다중 상속에서 passing의 값과 received의 값이 서로 달라질 수 있다고 아는 것은 하나를 아는 것이다.
그러나 NULL일 때는 다중 상속이더라도 언제나 NULL이 유지된다는 것이 함정이다. 우와.. 지금까지 한 번도 그런 경우를 생각한 적이 없었는데.. 꽤 충격적이다. 간단하지만 다중 상속의 보이지 않는 오버헤드를 보여주는 요소 중 하나이다.

Posted by 사무엘

* 이번 글은 지난번 글과는 달리 성경과 신앙관을 곁들인 아이템들 위주이다.

1.
성경의 마지막 책인 요한계시록에서, 거기서도 거의 끝부분인 백보좌 심판 쪽을 보면 이런 말이 있다.

"또 내가 보매 죽은 자들이 작은 자나 큰 자나 할 것 없이 하나님 앞에 서 있는데 책들이 펴져 있고 또 다른 책이 펴져 있었으니 곧 생명책이라. 죽은 자들이 자기 행위들에 따라 책들에 기록된 그것들에 근거하여 심판을 받았더라. (...) 누구든지 생명책에 기록된 것으로 드러나지 않은 자는 불 호수에 던져졌더라." (계 20:12, 15)

지구상에 살았던 모든 사람들의 모든 인생 행적이 기록되고 저장돼 있는 방대한 매체가.. 무슨 거대한 IDC(데이터센터) 서버 컴퓨터라든가, 데이터베이스 백업용 자기 테이프 형태로 표현되어 있지 않은 게 무척 신기하다.
영원에서 영원까지라는 관점에서 보면 결국은 제일 오래 가는 정보 저장 매체는 '책'이다.
그래서 성경에는 책이라는 정보 저장 매체와 관련하여 이런 엄청난 끝판왕 말씀도 있다.

"예수님께서 행하신 다른 일들도 많으므로 만일 그것들을 낱낱이 기록한다면 심지어 이 세상이라도 기록된 책들을 담지 못할 줄로 나는 생각하노라. 아멘." (요 21:25)
(당연히.. 예수님이 창세 전부터 계신 하나님이라는 뜻이다.
그냥 평범한 30대 청년의 일거수일투족 인생 로그만 덤프 뜨는 거라면, 이 세상이라도 책들을 다 담지 못할 거라는 말은 과장일 수밖에 없지.)

2.
'테크노피아'라는 말은 쉽게 짐작할 수 있듯, '테크놀러지 + 유토피아'의 합성어이다. 전자를 통해 후자를 이룬다는 말. 이건 전혀 말이 안 되는 소리는 아니다. 어느 정도 부분적으로는 사실이다.

과학 기술은 수많은 인간(시장경제 논리의 특성상 모든 인간까지는 아니더라도!)을 질병과 굶주림으로부터 구했으며, 단순노동 노가다로부터 해방시켜 줬다. 인간을 돌도끼 들고 야생을 뛰어다니지 않아도 되게 해 줬다. 생존본능 지향적인 욕구를 충족시킨 뒤, 더 창의적이고 고차원적인 가치를 추구할 수 있게 해 줬다. 마이크로소프트의 슬로건인 Your potential, our passion처럼 말이다.

그러니 이걸 경제 제도와도 결부지어서 생각해 보면, 본인은 그저 다국적 기업의 음모, 유대인 재벌의 음모 이러면서 일방적으로 자본주의만을 마귀적으로 몰고 가는 식의 선전 선동에 공감하지 않는다. 소위 말하는 신자유주의, 황금 만능주의가 아무리 부작용과 폐단, 병크가 있다 해도 사회주의· 공산주의는 그보다 훨씬 더 사악하기 때문이다. 기업이 노동자를 착취하는 것보다 국가가 개인을 착취하는 게 훨씬 더 악하다. 신앙은 있는데 선악 구도에 대한 생각이 여기에까지 미치지 못한 채 어설픈 정의감만 있으면 흔히 말하는 '좌독' 성향이 되기 쉽다. 하나만 알고 둘은 모른다.

뭐 그런 그렇고 다시 본론으로 돌아오면.. 국내에서 '테크노피아'라는 말은 지금으로부터 한 30여 년쯤 전에 금성사가 회사 이미지 광고를 내보내면서 썼다. 금성사 하면 국내에서 최초로 흑백 텔레비전을 만들어 낸 업체가 아니던가. LG 전자로 바뀐 뒤 2010년경에 얇은 대형 TV 광고에다가는 "기술이 너희를 자유케 하리라"라고, 동일한 이념의 광고 카피를 내보내기도 했다.

LG 말고 삼성의 경우는 '휴먼테크'라는 말을 만들어서 오늘날까지 자기네 논문 공모전에다가 쓰고 있다. 그리고 현대 자동차에서도 옛날에 엘란트라를 웬 '휴먼터치 세단'이라는 수식어로 광고했는데.. 어감이 좀 이상했는지 얼마 못 가 '고성능 엘란트라'라고 바꿨던 게 기억에 남아 있다. 뭘 터치한다는 거지? 사람의 감성?

전세계에 테크노피아에 대한 환상이 처음으로 개발살이 난 때는 1차 세계 대전이 아니었을까 싶다.
물론 그렇다고 과학기술 무용론, 문명의 이기 거부 쪽으로 갈 필요는 없다. 이 자연에는 애초에 선한 것만 있는 게 아니다. 그런 맥락에서 본인은 유사의학, 친환경, 백신 반대 이런 거 공감하지 않으며, 원자력 발전도 적극 찬성론자이고.. 뭐 그렇다.

단지 과학 기술은 마치 칼이나 돈처럼 가치 중립적인 도구일 뿐이다. 마치 "총칼이 사람을 죽이는 게 아니라 사람이 사람을 죽이는 거다"라는 말이 있듯, 과학 기술도 저렇게 사람을 살릴 수 있지만, 반대로 사람을 온통 타락시키고 죄 짓게 만드는 데 쓰이는 것 역시 가능하다. 단순히 원자력처럼 물리적으로 위험한 기술만 위험한 게 아니다.

또한 과학 기술이 아무리 발달하더라도 인간의 죄 문제는 해결할 수 없을 것이고 타락 이래로 세상에 내려진 저주와 엔트로피 증가 자체를 거꾸로 돌리지는 못할 것이다. 모 성경 구절이 제아무리 패러디 되더라도, 인간에게 진짜로 자유를 선사할 수 있는 건 기술이나 노동이 아니라 일차적으로는 '진리'라는 사실도 변함없을 것이다.

3.
그러고 보니, "총칼이 사람을 죽이는 게 아니라 사람이 사람을 죽이는 것일 뿐이다"
이건 특히 미국에서 총기 규제/금지를 반대하고 개인 총기 소유를 옹호하는.. 전미 라이플 협회(NRA) 같은 단체에서 들이대는 논리이기도 하다.
이제 와서 총기를 금지한다고 해서 금지가 가능한 것도 아니고, 결국 진짜 총을 뺏어야 할 나쁜놈들에게서 총을 완전히 없애는 건 어차피 불가능하니 너라도 총을 구입해서 이 험악한 세상에서 네 목숨 지켜야 한다.. 뭐 이런 논리.

개인적으로는 그 논리에 크게 반대하지 않는다. 난 크리스천으로서 절대악을 놔두고서 필요악만 나쁘다고 없애자는 식의 논리에는 어떤 형태로든 전혀 찬성하지 않기 때문에.. 사람이 사람을 죽이는 거지, 총칼이 사람을 죽이는 거 아니다.
무기 자체가 나쁘다고 생각하지 않으며, 오히려 역사적으로 볼 때 시민들이 무장을 강제로 해제당한 뒤에 악당들에게 더 참혹한 꼴 험한 꼴을 많이 당했다.

우리나라도 일제 강점기가 되는 과정에서 군인들은 무장해제 당하고 백성들 역시 사냥용 무기나 위험물은 압수 당했다. 성경에서 이스라엘 백성은 블레셋의 지배를 받을 때 무장해제 차원에서 쇠붙이를 몽땅 빼앗겨서 농기구조차 빌려 쓸 지경이 됐었다. 같은 맥락으로, 미국 같은 나라에서 크리스천들이 "총을 빼앗긴 다음에는 성경을 빼앗길 거다" 식으로 생각하는 거 공감한다.

무기를 동원해서 내 집을 내가 지키는 건 부부관계 사생활만큼이나 정말 신성한 권리이며, 그 어떤 이유로든 남의 집에 무단 침입하는 행위는 정말 목숨을 거는 위험한 짓이 돼야 하는 게 마땅하다. 어쩌다 싸이코 미친놈 때문에 발생하는 총기 사고 같은 건 저 자유라는 대전제 하에서 일부 부작용을 해결하는 방법 차원에서 논의돼야 할 뿐이다.

옛날에 영화 배우 찰턴 헤스턴이 한때는 월남전 반전 시위도 했을 정도로 그쪽으로 진보 성향이었으나, 총기 소유에 관한 한은 꼴보수 스탯을 유지해서 NRA 회장으로 활동했던 것 유명하다.
그런데 가만히 생각해 보니... 영화 <연평해전>에서는 어째 된 일인지 저 말과는 정반대 심상의 말이 있다.. 총기 소유 그런 게 아니라.. 다른 쪽으로 반대다.

"약이 사람 살리는 거 아니다. 사람이 사람 살리는 거다." (한 상국 중사. 배 위에서 야식 먹으면서 신참 박 동혁에게)
사람을 살리는 것도 사람, 죽이는 것도 사람. 이게 문득 생각이 났다.
난 영화를 많이 보지는 않지만.. 일단 인상깊게 보는 영화는 대사를 다 외운다.

4.
프로그래머의 최종 테크는 치킨집 사장이고, 억만장자의 최종 테크는 건물주 임대업자라고 한다. (☞ 관련 링크)

오죽했으면 대한민국 땅에서 조물주보다 더 위대한 건 건물주랜다. "의느님", "천당 위에 분당" 이래로 내가 무릎을 쳤을 정도로 기발한 신조어다. =_=;;
"건물은 내가 직접 벌어서는 살 수가 없어요. 받아야죠. 그 방법밖에 없어요." (모 자산 관리소장 인터뷰 중)

난 누구처럼 뭐 지금 사회 구조가 엿같네, 금수저 은수저 계급론 그딴 거 거론하고 싶은 생각은 없다. 돈으로 돈 버는 건 정도의 문제이지 그 자체를 나쁘다고 죄악시할 수는 없기 때문이다.
다만, 나도 그놈의 임대업인지 뭔지 하면서 생업 걱정 없이 날개셋 한글 입력기 코딩이나 평생 펑펑 하고 싶긴 하다.

외제 명품 호화 사치 유흥 음주가무 주색잡기 같은 건 정말 하나도 눈꼽만치도 관심 없음. 그리고 돈 너무 많아서 에쿠스만 굴리고 다니느라 새마을호에서 Looking for you도 못 들어본 사람들은 난 교통 분야에 한해서는 전혀 부럽지 않다.
부러운 건 딱 하나. 돈 자체가 아니라 코딩할 시간이 있다는 게 부러울 뿐이다.

물론 아무 부동산이나 소유하고 있다고 해서 무조건 100% 돈 놓고 돈 먹기가 보장되는 건 아니다. 아무 건물이나 공실률이 없이 빵빵 입주자가 들어오는 게 아님. 이거도 여느 자영업만큼이나, 투자 잘못해서 본전도 못 뽑고 망한 사람이 역시 당연히 있다.

그럼에도 불구하고 일반적으로는 어디에든 땅 내지 집이 있다는 건 정말 좋은 일인 건 사실이다.
구약에 나오는 "땅을 상속 받으리라"가 얼마나 큰 복인지, 그리고 한국 교회가 어째서 물질주의 기복신앙으로 빠져들었고 왜 걸핏하면 땅, 건물에 목숨을 거는지, 왜 "성전 건축 헌금"이 있는지가 이해가 된다.

그에 반해 신약 성도는 세상에서 알박은 거처가 없이, 복은 일단 영적인 형태이며 이 세상에서 순례자(pilgrim)라고만 표현돼 있다. 이것만 생각해도 소위 십일조 헌금이라는 건 교회와 얼마나 안 어울리는 이상한 관행인지를 알 수 있다. 그리고 솔직히 성경은 의식주 중에서 의식에 비해 '주'는 상대적으로 덜 강조한다(딤전 6:8, 눅 3:11, 마 6:25 등).

부동산 정책과 관련해서 성경에는 요셉이 흉년을 빌미로 전국의 모든 농토를 국유화해 버린 게 나온다(창 47). 이때에 요셉이 취한 정책은 일종의 무상 몰수 유상 분배였는데 성경적으로 무슨 의미가 있는지는 모르겠다.
룻기도 부동산 상속과 관계가 있는 책이고. 언젠가 이 주제에 대해서 체계적으로 공부를 해 봤으면 싶다.

끝으로 중요한 것. "건물은 내 힘으로 돈 벌어서는 절대로 살 수 없어요. 받아야죠. 그 방법밖에 없어요"에는 의외로 굉장한 성경적인 진리가 담겨 있다.
칭의와 '구원'에 대해서도 사람들이 저런 관념이 박혔으면 좋겠다. -_-;;

5.
오늘날 인간은 채식만 해서는 제대로 영양 공급을 받을 수 없다. 몸 관리를 위해서는 육류를 통한 단백질 공급이 필요하다. 성경에서 다니엘의 시험이 괜히 있었던 게 아니다. 또한, 소림사에서도 한창 성장을 해야 하는 동자승 내지 무술 수련을 하는 승려들은 고기를 부득이하게 먹는다.

그런데 문득 의문이 들었다.
정작 인간에게 단백질을 공급해 주는 소는 어째서 풀만 먹어도 덩치가 크고 힘이 좋은 걸까? 인간 중에서는 거의 최 배달 같은 전문 파이터-_-나 소를 상대했네 뭐네 그러지 않던가?

생물학적으로 간단히만 말하면, 소는 풀로부터 인간이 소화할 수 없는 성분도 몽땅 소화해서 인간보다 훨씬 더 많은 '뽕'을 뽑을 수 있기 때문이다. 단적인 예로 염소만 해도 셀룰로오스를 소화할 수 있어서 종이를 먹을 수 있는 반면, 사람은 그렇지 못하다.
동물은 원래 이론적으로는 풀만 먹어도 저렇게 크고 힘센 개체로 성장이 가능하다는 건 시사하는 바가 커 보인다.

성경에도 풀을 뜯어 먹는 모습을 유독 소에다 비유한 장면이 여러 번 나온다.
욥기에서 베헤못이라는 영적 괴물이 소처럼 우적우적 풀을 뜯어 먹는댄다. (욥 40:15)
미래에 천년왕국 때는 땅의 저주가 풀려서 사자도 소처럼 풀만 먹는 초식동물로 바뀔 거랜다. (사 11:7, 65:25) 어렸을 때 교회 댕긴 애들은 <사막에 샘이 넘쳐 흐르리라> 노래 기억하실 것이다.
그리고 다니엘서에서도 느부갓네살 왕이 하나님으로부터 벌을 받아 미쳐 버렸을 때 "소처럼" 풀을 뜯어먹으며 지내게 될 거라고 경고하는 게 나오며, 그것이 실제로 일어났다고 한다. (단 4~5)

사람은 소처럼 아무 풀이나 짚을 먹을 수는 없다. 그러니 옛날에 "일본인은 원래 초식동물이니 (딱히 식량 보급이 없더라도) 길가의 풀을 알아서 뜯어먹으며 진격하라"라는 미친 명령을 내렸던 일본의 졸장 무다구치 렌야 장군이 더욱 병맛스럽게 느껴진다.

뭐, 사람은 풀뿐만이 아니라 고기도 아무렇게나는 못 먹는다. 다른 육식 동물은 야생에서 초식 동물의 생살과 내장을 생으로 뜯어먹고, 반쯤 썩거나 상한 것까지도 막 먹을 수 있지만 사람은 그럴 수 없다. 반드시 익혀서 먹어야 한다. 사람이 기생충 같은 거 오염에 더 취약한 듯하다.

6.
아이고, 골치아픈 잡생각을 많이 늘어놓았는데, 끝으로 한국을 빛낸 100명의 위인들(?) 스타일의 위대한 성경 목록가 오케스트라를 소개하며 글을 맺겠다.

이게 단순히 성경 각 책들의 요약 소개가 아니라, 각 책에서 예수님이 어떤 분이신지를 나타내고 있다.
First Assembly of God라는 곳에서 공연한 걸로 보이는데.. 정말 웅장하고 훌륭한 찬양이다. 가사는 다 외워 버릴 가치가 있다.

처음엔 조용한 단조풍으로 시작하다가 스케일이 갈수록 커진다. He is. (그분은 계신다, 모든 것이 되신다~~)
난 이미 음성 추출해서 차에서 듣고 있다.
S. M. Lockeridge라는 목사가 1976년에 했다는 "그분은 나의 왕이십니다!"라는 엄청난 설교를 떠올리게 한다. 관심 있는 분들은 한번 들어 보시라.

Posted by 사무엘

1.
내가 한겨울에 운전을 하면서 지금까지 본 가장 낮은 기온은 -13도이다.
그런데 기온이 영상과 영하를 오락가락 할 때 차에서 표시해 주는 온도계를 보면, 가끔 0도라고 표시할 때도 있고 -0도라고 표시할 때도 있다.

기온이 영상이었다가 어느 땐가 영하로 내려갔다면, 그 사이에 0도이던 순간이 적어도 한 번 이상 존재했겠다는 중간값 정리 개드립이 떠오르는 한편으로.. (시각 t에 대한 기온 변화 함수는 연속함수일 테니..)
또 하나 떠오른 생각은.. "저 컴퓨터는 온도를 내부적으로 부동소수점 실수로 표현하고 있겠구나!"였다.

2의 보수 기반 정수로 표현했다면 0이 두 종류가 있을 수가 없었을 테니까.
이공계 지식을 알면 기계 내부의 별별 디테일이 머리에 들어온다.
그나저나 연도에는 서기 0년이 없다고 한다. 서기 1년의 이전 해는 바로 기원전 1년. 마치 건물에서 지상 1층의 아래는 0층이 아니라 바로 지하 1층인 것과 비슷한 이치이다.

2.
밤에 잠을 자는데 그냥 평범한 침실이 아니라, 밖에 어디 아늑하고 아담하고 눈에 안 띄는 곳에 콕 짱박혀서 자고 싶다. 집 밖에서 야영을 하고 싶다.
하루 종일 대형 트럭이나 트레일러를 몰다가 밤에 뒷좌석의 간이 침대에서 길다랗게 누워 자는 화물차 운전사 있잖아.. 뭐 그런 거에 갑자기 꽂혀서 로망이 생겼다.

트럭이 아니라 버스도. 땅 넓어서 이동에 며칠씩 걸리는 나라에서는 버스 안에도 화장실이 있고 운전사가 두 명 타서 한 명은 운전하고 다른 한 명은 짐칸에서 자다가 몇 시간 주기로 교대 근무를 한다는데.. 뭐 그렇게 자는 것도 좋다. 되게 편안하게 잘 잘 수 있을 것 같다.

청계천 공원이나, 아예 깊은 산 속 수풀 덤불에 짱박혀서 침낭과 외투 껴입고 자고 싶기도 하고,
무슨 무장공비나 북파공작원처럼 비트 파서 맥북과 함께 밤을 보내고 싶기도 하다.
아 근데.. 산에서 자면... 그땐 식물들도 광합성 안 하고 호흡만 하기 때문에 산소 공급 측면에서는 안 좋으려나.

성경을 동원해서 더 직설적으로 말하자면, 밖은 폭풍 때문에 배가 다 가라앉게 생겼는데 밑전에서 쿨쿨 잘 쳐자던 요나처럼 자고 싶다. 서리해서 먹는 수박이 박진감 넘치고 더 맛있듯, 저거 그야말로 꿀잠이지 않았을까? 오죽했으면 선장이 한심해서 sleeper라는 단어까지 썼다. ㅋㅋ

3.
과식과 과속은 훌륭한 스트레스 해소 수단이다. 다음은 고기와 관련된 명언들이다.

• "훌륭한 단백질 공급원이죠." (베어 그릴스)
• "밥상에 자연의 향기가 물씬 풍기네. 자연에도 달리는 동물이 있는데 여긴 그게 없네."
  ("현기증 난단 말이에요 빨리 라면 끓여 주세요~~" 의 주인공. ㅠㅠㅠ 그런데 세종대왕도 딱 저런 타입이었다~ 고기와 학문을 사랑하신 우리 대왕님)
• "이모, 반찬이 죄다 잡범이네. 아니, 어떻게 살인사건이 하나도 없나?" (영화 아저씨 대사 중)
• "일본인은 원래 초식동물이니 가다가 길가에 난 풀을 뜯어먹으며 진격하라." (일본군 병맛 졸장 무타구치 렌야)

4.
지금까지 컵라면으로만 접하던 육개장 사발면이 언제부턴가 봉지 라면으로도 나오는 걸 편의점에서 봤다.
이걸 보니 딱 바로 든 생각은... 뭔가 스마트폰 앱이 데스크톱 PC용으로 포팅되어 출시된 듯한 느낌이다~~!! 카카오톡처럼.
신라면과 짜파게티는 반대로 PC에서 오랜 인기를 누리던 장수 소프트웨어가 모바일용으로 포팅된 예이다.
식당에서 라면을 시켰을 때 보통은 면이나 스프가 신라면 베이스가 많다고 하는데, 그럼 이건 서버 기반의 웹 애플리케이션인 걸까? =_=;; 라면 하나를 두고도 별 희한한 생각이 다 들었다. ^^

5.
2000년대 이래로 우리나라 가요계는 그야말로 그냥 아이돌도 아니고 '걸그룹' 아이돌 위주로 구도가 급격히 바뀐 듯하다. H.O.T 같은 남자 그룹도 아니고, 이 효리나 박 정현 같은 여성 솔로도 아니고.. 하긴 옛날에는 핑클이나 SES 같은 그룹도 있긴 했다만 요즘은 그때보다 애들이 더 어리고, 무엇보다 그룹 당 인원 수가 무진장 많으며 게다가 다국적이기까지 하다. 아이고 정말 정신없다. 그 와중에도 아이유는 어째 솔로로 여전히 잘 나가고는 있다만...

올해 연초에 방영됐던 '프로듀스 101'은 참 인상적이었다. 슈스케 시리즈보다 스케일과 선정성이 더 커졌다. "정말 자본주의의 진수이구나.. 도대체 어떤 사람이 약 빨고 이런 프로를 만들 생각을 했을까, 그리고 저런 걸 한다고 또 저기 출연을 하는 여자애들은 도대체 무슨 생각을 하고 참가를 신청해서 저 고생인 걸까..?" 여러 생각이 들었다. 출연자들은 다들 98년에서 2002년생.. 나보다 띠동갑 이상으로 어린 걸 보고는 기겁을 했다.

예능과 끼만으로 돈 버는 게 쉬울 리가 있겠나..;; 저런 스트레스 받느니 차라리 학업 스트레스가 낫지. 나중에 내 자녀가 철딱서니 없이 '나도 연예인 될래. 걸그룹 아이돌 할래' 이러면 참 골치 아프겠다는 생각이 들었다.

요즘은 드라마도 그렇고 노래도 그렇고.. 정공파로 나가는 건 약발이 다했으니 '병맛'으로 승부하는 것 같다. "병맛으로 인한 중독성 때문에 욕을 하면서도 저게 머리에서 떠나질 않는다. 자꾸 보게 된다" 같은 것이랄까.. 텔미, 크레용팝 빠빠빠, 픽 미 다 그런 부류인 것 같다. 걸그룹과 관련해서 본인이 최근에 얻은 경험으로는..;;

• 서현과 설현이 서로 다른 인물이라는 걸 얼마 전에 확실하게 깨우쳤다. 특히 설현은 쏠 스마트폰 CF에 출연해서 더 유명해졌다.
• 10년이 넘게 국제 정보 올림피아드의 약자로만 알았던 이니셜이 이제는 걸그룹 명칭이 됐구나. 101이 그대로 알파벳으로.. 참 기발하다. =_=;;
• 크레용팝 빠빠빠의 뮤직비디오를 촬영한 곳은 서울 아차산 기슭에 자리잡은 폐업한 유원지인 "용마랜드"라는 것을 알게 됐다. 뮤비에 나온 장면을 항공 사진 지도를 통해서도 확인할 수 있다.
• 한때 교회에서 <주께 가오니>를 굉장히 과격한 독수리춤 안무로 표현해서 사람들에게 충격과 공포를 선사했던 그 당사자가.. 훗날 트와이스라는 걸그룹의 멤버로 데뷔했음을 알게 됐다! 이름은 다현..;;

6.
석면은 거의 방사능 물질과 같은 급으로 왕창 위험한 물질이었구나. 수 년 전부터 "지하철 역사 내부에서 석면 검출" 이러는 뉴스 보도를 여느 "미세먼지 주의보"처럼 그리 대수롭지 않게 넘기고 지내 왔는데.. 그렇게 사소하게 치부할 일은 아닌 것 같다.
슬레이트 지붕도 전부 석면이라면.. 그렇게도 위험한 물질인 것치고는 일상생활에서 너무 흔히 봐 왔는데 말이다.

보온· 단열재로 쓰였다는데 그럼 스티로폼과도 용도가 비슷한 건가?
한 분야에서 가성비가 아주 뛰어난 물건이 환경을 치명적으로 파괴하고 인체에 안 좋다는 게 뒤늦게 밝혀져서 흑역사로 전락한 게.. 토머스 미즐리의 발명품 말고도 더 있었다.

7.
끝으로, 운전자의 직업병을 소개한다.
골목길을 거닐다가 옆에 요런 적당한 공터를 발견하면.. 차를 세워 놓고 싶다는 생각이 든다.

등산 갔다가 내려오는 길에 발견한 어느 한적한 골목이다.

Posted by 사무엘

자동차 역사에 대해서 글을 쓰는 건 거의 3년 반 만에 처음인 것 같다.
지난번 자동차 이야기에 이어, 이번엔 화제를 VIP의 애마 말고 다른 쪽으로 좀 돌리도록 하겠다.

까마득히 먼 옛날인 순종 황제라든가 이 승만· 김 일성 같은 사람이 몰았던 차는 유니크템으로서 오늘날까지 실물이 존재하는데..
정작 해방 후에 한국 땅에서 직접 처음부터 조립해서 생산된 최초의 자동차인 '시발'(1955)은 의외로 실차가 오늘날 전혀 전해지지 않는다. 이거 참 아이러니한 일이 아닐 수 없다.

시발은 차체 외형은 자동 기계 공작 없이 엔지니어가 일일이 손으로 두들기고 펴서 만들고, 엔진은 미국 자동차 부품을 불법 복제해서 넣는 수준이었다.. 그러니 이 물건들은 수출로 팔려 나가지는 못했을 것이고, 차량이 한물 갈 때쯤 다들 폐차 처분되어 없어진 것으로 보인다.

오늘날 자동차 박물관 같은 데에 전시돼 있는 시발 택시는 그 시절에 달렸던 실차가 아니며, 다들 레플리카이다(예전의 고증을 반영해서 후대에 옛 물건을 일부러 새로 만든 복원품). 지금 불국사가 신라 시대에 지어진 원판이 아니라 훗날 재건된 건물인 것과 같은 이치이다.

시발 이후에 우리나라 자동차 역사를 현대 자동차 위주로 좀 늘어 놓으면 이렇다.

• 코티나(1968): 현대 자동차가 창립 후 면허 생산한 최초의 자동차. 외국의 자동차를 단순히 완제품 수입만 해서 판 게 아니라 면허 생산한 것임.
• 포니(1975~1976): 잘 알다시피 국내 최초의 고유 모델 승용차. 디자인 자체는 외국의 디자이너(쥬지아로)가 한 것이고 엔진도 일제(미쓰비시 새턴)이지만 어쨌든 지금까지 지구상에 없던 모양의 자동차를 한국 땅에서 생산해 내는 데 성공함.
• 프레스토(1985): 포니의 후속으로 개발된 포니 엑셀의 세단형 버전에 붙은 별칭이며, 요건 현대차 최초의 전륜구동 승용차이다. 전륜구동은 후륜구동보다 부품 수가 더 적지만 만들기는 더 어려웠다. 첫 승용차인 포니가 괜히 후륜구동이었던 게 아님.
• 엑셀(1989): 연료 분사 방식이 카뷰레터에서 전자제어 다중분사(MPI)로 넘어가는 과도기. 최신 기술은 최상위 모델인 GLSi에서 첫 도입됐다. 이때 CF에서는 자동차에도 드디어 컴퓨터가 들어간다며 최첨단 기술이랍시고 왕창 자랑을 해 댔었다.
• 엘란트라(1990): DOHC 흡기 방식 도입으로 엔진 출력 향상. 이 역시 최신 기술은 최상위 모델에 도입되곤 했다. 엘란트라 이전엔 그랜저의 최상위 모델인 V6 3000cc (1989)짜리도 SOHC 방식이었다.
• 스쿠프(1991): 최초의 2도어 쿠페. 엔진을 최초로 독자 개발(알파 엔진). 터보차저
• 액센트(1994): 최초로 로얄티가 전혀 들지 않고 현대 자동차가 머리부터 발끝까지 100% 독자 개발한 승용차다. 이만치 기술이 발달했다.

확실히 현대 자동차의 역사는 포드 사와 기술 제휴를 하던 시절과, 그 후 미쯔비시 사와 손잡은 시절로 시즌 1과 2로 나눌 수 있을 것 같다. 현대와 미쓰비시 사이의 기술 주종 관계 역전은 우리나라의 자동차 역사에서 잘 알려진 사실이다. 더구나 공동 개발한 자동차들이 하필 일본에서는 다 망했는데 한국에서만 대박을 친 것도 신기하고 말이다(그랜저/데보네어 V, 에쿠스/프라우디아).

1990년대에 자동차의 엔진 성능은 비슷한 시기에 무슨 컴퓨터의 클럭 속도가 증가한 것만치 그 정도로 폭발적으로 뻥튀기되지는 않았다. 그러나 요즘 차는 같은 배기량으로도 몇십 년 전 자동차가 상상도 못 할 만치 큰 출력이 나오는 건 사실이다. 특히 DOHC 흡기라든가 터보차저가 엔진 출력을 크게 끌어올려 주긴 했다.

포니 같은 옛날 차들을 보면 엔진룸이 요즘 차보다 더 길고 각지게 돌출돼 있는 주제에 정작 뚜껑을 열어 보면 공간은 더 휑하다. 부품들도 다 기계식이고 단순하다.
하지만 요즘 차들은 온통 복잡한 전자 부품들로 가득하고 그러면서도 엔진룸은 최대한 줄이고 객실 공간을 짜내다시피하게 설계된 것이 눈에 선하다.

포니부터 시작해서 엑셀, 스텔라, 쏘나타 Y2까지 그 시절 자동차들은 조르제토 쥬지아로의 디자인이다. 그러나 1986년에 나온 각그랜저는 시간대가 얼추 저 시절에 듦에도 불구하고 쥬지아로의 디자인이 아니며, 디자인과 설계까지 모두 현대/미쓰비시 공동 개발이다. 우리나라의 동전 중에 500원만이 다른 동전보다 늦게 따로 등장했으며, 열차 명칭 중에 새마을호는 비둘기/통일/무궁화와는 달리 독자적으로 먼저 쓰이고 있었던 것과 비슷한 느낌이다.

쥬지아로 이후로 한참 뒤, 2000년대 말에 fluidic sculpture라는 이념 하에 YF 쏘나타와 아반떼 MD를 디자인한 사람은 안드레 허드슨이라는 미국인이다. 쏘나타는 미국물 먹은 디자인이고, 경쟁 차종인 K5는 유럽물 먹은 디자인이라고 흔히 비교되곤 했다.

* 보너스: 현대 자동차의 차명 관련 개드립

• 코티나: 앞서 언급했듯이 현대 자동차가 생산한 최초의 차량이다. 최초라는 건 시행착오의 시범타라는 뜻이기도 하다. 한국의 열악한 도로 사정으로 인해 차가 생각보다 잘 퍼지고 고장이 잦았던지라, 코티나의 초창기 모델은 '고치나', '코피나', '골치나' 등 불명예스러운 개드립이 많이 따라다녔다고 한다. 컴퓨터 프로그램으로 치면 버그가 꽤 많았던 듯.
• 그라나다: 역시 유럽 포드 사의 차량을 면허 생산한 것이다. 얘는 그 당시로서는 그랜저의 전신이라 할 수 있는 꿈의 최고급 승용차였으며, 국내에 아직도 이 차를 애지중지 관리 잘 하면서 소장 중인 사람이 있다. 채널 A 카톡쇼에서 그 차주와 차를 취재한 적이 있는데(제18회).. 차주의 가족들은 차명에서 G를 B로 바꿔서 차를 '불안하다'라고 부른다고 한다. 너무 옛날 차여서 언제 갑자기 퍼질지 몰라서 타기 불안하다고. -_-;;
• 쏘나타: '소나 타'. 이건 그 당시 경쟁사(대우?)의 회장조차도 현대를 디스할 때 구사한 드립이라고 한다.-_-;;; 한국어 보조사의 특성상 나름 중의성도 있다. (1) 사람이 아닌 소를 싣는 데 적합한 차라는 의미와, (2) 이런 저질 차를 탈 바에야 차라리 소를 타는 게 낫다는 의미. 그래서 1985년에 스텔라의 최상위 트림으로 Y1 모델이 나왔을 때에는 CF에 분명히 '소나타'라고 기재돼 있었지만, 그 이듬해, 심지어 Y2이 나오기도 전에 곧장 '쏘나타'라고 한글 표기가 ㅅ이 ㅆ으로 바뀌었다!
• 에쿠스: 어느 난센스퀴즈에 따르면, 궁예가 타고 다니는 차라고 한다. -_-;; 글쎄, 한 나라의 국왕이니까 저 정도 기함급 승용차를 몰 만도 하겠다. 그런데 이젠 에쿠스도 단종되고 제네시스 EQ 900으로 넘어갔으니 옛날 이야기가 됐다.

소나타/쏘나타 드립에 대해서는 다음 사진과 화면을 참고할 것.  -_-

Posted by 사무엘