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

코레일이나 각종 지하철 회사 같은 우리나라의 철도 운영 기관들은 현재 대체로 빚이 많으며 운영난을 겪고 있다. 그러나 그 이유는 근본적으로 막대한 건설 부채를 떠안고 있어서가 가장 크며, 다음으로 원가보다 훨씬 더 저렴한 운임, 손해를 감수하고 공익을 추구한 비경제적인 노선 운영, 그리고 전세계에서 유례를 찾을 수 없는 노인 전철 완전 무임 승차로 인한 손실이 뒤를 잇는다.

방만· 부실 경영이 차지하는 비중은 없다고는 할 수 없어도 아주 미미하다. 한국 철도가 굉장히 사회주의적인 준독점 시스템인 건 사실이지만, 태생적으로 적자를 감수하고라도 매우 큰 복지 혜택을 제공하고 있는 것도 사실이다. 이런 사실에 대해 무지한 채 그저 상업주의 민영화만이 철도 경영 효율을 위한 방안이라는 생각에는 본인은 공감할 수 없다.

아무리 오늘날의 노인 어르신들이 국가 근대화의 초석이었다고 하지만, 완전 무임은 너무하다는 생각이 든다. 단돈 100원을 내더라도 뭔가 지불하는 건 있어야지, 아예 0은 도덕적 해이를 부추긴다. (주말에 경춘선 전철을 한번 타 보라. 승객의 연령비에 아마 기겁을 하게 될 것이다.)

듣자하니 노인 전철 무임 승차 제도는 전통 시절인 1984년에 생긴 거라고 한다. 그때는 당연히 지금보다 노인 인구가 훨~씬 더 적던 시절이었고, 전철 노선 자체도 지금보다 훨~씬 더 빈약하던 시절이었다.

이 제도의 부조리와 폐해가 계속해서 논의되고 있지만, 그게 선뜻 폐지나 재조정이 못 되고 있는 이유는, 성탄절· 석탄일이 공휴일에서 선뜻 제외되지 못하고 있는 이유와 정확히 동일한 맥락에서 살펴볼 수 있다. 공휴일이 너무 많다고 맨날 징징대는 경제인 사장님들 단체들도, 감히 종교 공휴일을 건드릴 엄두는 못 내고 한글날 내지 제헌절 같은 것이나 대신 칼질을 하지 않았던가..

(사실, 10년쯤 전에 진작에 없어졌을 병역 특례 산업 기능 요원도 아직까지 그래도 명맥은 유지되고 있는 것 역시, 업계에서 온몸으로 강력하게 반발하면서 폐지를 막았기 때문이다. 중소기업은 이런 제도라도 없으면 정말로 유능한 사람을 못 뽑는다고. 재계의 목소리는 병무청이든 중앙 정부든 결코 무시 못 할 위상이긴 하다.)

본론으로 돌아오면, 물론 철도 적자의 원인을 전부 노인 무임 승차 탓으로만 돌리는 것도 좋은 진단은 아니다. 철도가 태생적으로 적자이긴 해도, 각종 광고 게시나 부동산 임대 사업을 하고 여타 각종 창의적인 사업 아이템을 생각해 내어, 승객 운임에만 지나치게 의존하지는 않는 탄탄한 재정 구조를 만드는 것이 철도 회사 경영자가 해야 할 일이다. 신문사는 구독료에 너무 의존해서는 곤란하며, 대학 역시 학생 등록금에만 너무 의존해서는 곤란하다.

그런 창의적인 일을 하는 것에는 경쟁이 필요하고 민간 사업자 유치가 필요할지도 모른다. 이런 일을 전부 정부나 정부 출자 공기업에만 맡겨서는, 철도 기관이 맨날 보조금에나 의존하는 세금 먹는 하마로 전락할 위험이 있다. 그러지 말라고 철도청이 진작부터 코레일이라는 공기업으로 바뀌었다. 하지만 수익 추구만 지나치게 강조하다 보면 철도 특유의 공공성이 훼손될 가능성도 커진다.

어느 쪽도 참 쉽지 않은 문제이다. 다만 본인이 이 글에서 얘기하고자 하는 것은, 철도 기관의 경영 수지에 대해 논하려면 오늘날 한국 철도가 처한 현실과 그 성격부터 제대로 직시할 필요가 있다는 것이다.

Posted by 사무엘

Windows라는 PC용 운영체제는 1985년에 처음 나온 이래로 많은 변화를 겪었다.

1.0 시절에 윈도우는 잘 알다시피 독자적인 실행 파일 포맷을 갖고 있긴 했지만, 완전한 운영체제가 아니라 16비트 도스 위에서 추가로 구동되는 액세서리 멀티태스킹 환경에 불과했다. 또 개발 언어가 의외로 C가 아닌 파스칼이었기 때문에, 실행 파일 내부의 각종 export/import 심볼을 보면 대소문자 구분이 없이 다 대문자였고, 문자열도 null-terminated 형태가 아니라 글자수가 앞에 찍힌 형태로 저장되어 있었다.

상업적으로 최초로 대성공을 거둔 윈도우 3.0때부터(혹은 2.x때?) C언어 형태 기반으로 API가 재정비되었으나, 이런 파스칼의 흔적은 실행 파일 포맷이라든가 함수 호출 규약 같은 데에 여전히 일부 남아 있었다. API에 하위 호환성도 잘 지켜진 편이기 때문에 1.x~2.x용 실행 파일도 내부의 리소스 데이터의 구조만 살짝 고쳐 주면 3.x에서 바로 실행 가능할 정도였다.

그랬는데 1993년에 윈도우 NT가 개발되면서 프로그램의 내부 구조가 크게 바뀌었다. 16비트에서 32비트 환경으로 갈아탔으며, 멀티스레딩+선점형 멀티태스킹이라는 게 도입되었다. 이때 실행 파일의 포맷도 NE에서 PE 방식으로 바뀌었고, 이 전통이 오늘날까지 그대로 이어져 내려오고 있다.

마이크로소프트는 동일 코드를 거의 고치지 않아고도 재컴파일만으로 16비트 바이너리와 32비트 바이너리를 동시에 만들 수 있게 많은 배려를 했다. 특히 운영체제의 API 함수는 int 크기가 4바이트가 된 것 같은 불가피한 변화를 빼면 프로토타입이 거의 바뀌지 않았다.
그럼에도 불구하고 불가피하게 프로토타입이 크게 바뀐 함수가 의외로 GDI 계층에 많이 있다. MoveToEx 함수가 그 예이다.

16비트 윈도우 시절에 이 함수는

long MoveTo(HDC, int x, int y);

처럼 정의되어 있었다. 주어진 DC가 내부적으로 기억하고 있는 그리기 기준 위치를 x, y로 옮기고, 예전의 기준 위치를 리턴값으로 돌려줬다. 그때는 좌표계의 범위가 16비트이기 때문에, 두 개의 16비트 수치를 32비트 long 정수로 합산해서 표현하는 게 괜찮은 방법이었다.

그러나 이 디자인은 32비트 환경에서는 바뀌는 게 불가피해졌다. int 개개의 값이 32비트로 커졌고 32비트 윈도우는 32비트 좌표계를 지원하기 때문이다. 16비트 숫자야 범위가 너무 좁기 때문에 16비트 컴퓨터 시절에도 느리게나마 32비트 정수를 다루는 long 같은 타입이 있었지만, 32비트 둘을 합친 64비트 정수는, 언어 차원에서 표준으로 지정된 타입이 그 당시에 없었다.

그래서 32비트 환경에서는 예전의 기준 위치를 POINT라는 별도의 구조체의 포인터에다가 되돌리는 형태로 동작 방식이 바뀌어야 했고, MoveToEx라는 함수가 추가되었다.

BOOL MoveToEx(HDC, int x, int y, POINT *pPoint);

윈도우 API에 어떤 함수의 Ex 버전이 추가되더라도 MS는 어지간하면 옛날 버전 함수도 남겨 두는 편인데, MoveTo만큼은 그렇게 하지 않았다. 원래 있던 함수는 삭제되고 새로운 함수로 대체되었기 때문에, 16비트 코드를 포팅하는 사람은 이 함수의 호출 부분을 수동으로 리팩터링을 하지 않을 수 없게 되었다. 좌표계가 어차피 16비트 범위를 넘을 일이 절대 없다는 보장이 있고 기존 16비트 코드를 빠르게 포팅해야 하는 사람이라면, 그냥 이런 wrapper 함수를 자체적으로 만들 필요가 있을 것이다.

long MoveTo(HDC hDC, int x, int y)
{
    POINT pt;
    MoveToEx(hDC, x, y, &pt);
    return MAKELONG(pt.x, pt.y);
}

오리지널 버전을 왜 살려 두지 않았냐 하면, 저런 식으로 확장해야 하는 함수가 한두 개가 아니기 때문에, 오리지널 버전을 다 살려 뒀다간 윈도우 API가 심하게 너무 지저분해지기 때문이다.

GetViewportExtEx, GetWindowExtEx, GetViewportOrgEx, GetWindowOrgEx와 이들의 Set 버전들. 오늘날의 윈도우 API에 Ex 버전만 존재하고 오리지널은 남아 있지 않은 이유가 동일하다. 16비트 시절에는 간단하게 x, y좌표를 32비트 long으로 합쳐서 되돌리던 함수였는데 그것이 32비트 윈도우에서부터는 POINT나 SIZE 구조체를 통해서 결과값을 받도록 바뀌었다.

사실, GDI라는 게 화면 픽셀만을 취급한다면 좌표계가 16비트 범위만으로도 아주 충분할 것이다. 오늘날도 화면 해상도는 끽해야 1000~2000대를 벗어나지 않기 때문이다. 그러나 GDI는 화면뿐만 아니라 프린터도 다루고, 픽셀뿐만 아니라 장치 독립적인 더욱 정밀한 단위도 취급하기 때문에 궁극적으로는 좌표계의 크기를 32비트로 확장할 필요가 있었다.

다만, 과거의 윈도우 9x는 GDI와 USER 계층의 상당수가 16비트 코드를 그대로 답습하고 있었기 때문에, API는 저렇게 32비트 형태여도 내부적으로 여전히 16비트 좌표계의 한계를 지니고 있긴 했다. 그러니 실수로 32767을 넘어가는 40000쯤 되는 좌표로 선을 그으라고 하면, 숫자가 음수로 바뀌어 인식되어 선이 오른쪽 끝이 아닌 왼쪽 끝으로 가게 되었다. 이런 보정은 응용 프로그램이 알아서 해 줘야 했다. 암울했던 시절이다.

이런 점에서 윈도우 API를 커버하는 계층인 MFC가 편한 구석이 있다. 16비트 시절이나 32비트 시절이나 CDC 클래스의 멤버 함수의 프로토타입은 CPoint MoveTo(int x, int y)로 동일하다. POINT 자료구조를 생으로 함수값으로 되돌리게 한 것은 오버헤드가 따르지만, 그냥 이식성과 개발 편의에다 더 비중을 두고 클래스를 설계한 셈이다.

그럼, 세월이 흘러 32비트에서 64비트로 넘어가는 과정에서 생긴 큰 변화는 무엇일까?
뭐니뭐니해도 GetWindowLong 함수를 예로 들 수 있다. Set 버전도 포함.
얘는 원래 주어진 윈도우에 대해서 스타일, ID, 윈도우 프로시저 주소 등 다양한 수치 정보를 얻어 오는 일종의 다형적인(polymorphic) 함수이다. 리턴값이 일반 숫자일 수도 있고 포인터나 핸들일 수도 있다.

32비트 시절에는 컴퓨터가 표현하는 숫자의 크기는 32비트로 사실상 획일화되어 있었기 때문에, 문제될 게 없었다. int나 long을 바로 포인터로 typecast하거나 그 반대로 해도 정보가 손실될 일이 없었다.
그러나 64비트에서는 이것이 큰 문제로 작용하게 되었다. 윈도우 운영체제는 int와 long은 호환성 차원에서 32비트로 그대로 유지하고,포인터와 핸들만 64비트로 키우는 정책을 선택했기 때문이다.

그래서 개발자의 편의를 위해 비주얼 닷넷쯤의 플랫폼 SDK에서는 잘 알다시피 INT_PTR처럼 _PTR이라는 자료형 typedef가 추가되었다. 포인터의 크기와 같은 정수형이라는 보장이 있는 정수형을 따로 구분해서 표현하기 위해서이다. 윈도우 API도 원래는 GetWindowLong 하나만 있었는데 GetWindowLongPtr이라는 명칭이 추가되었다. 이것이 32비트 환경에서는 그냥 GetWindowLong로 도로 치환되는 매크로에 불과하지만, 64비트에서는 Ptr 버전만이 운영체제의 user32.dll에 실제로 존재하는 함수이다.

다시 말해, 32비트에서는 기존 Long과 새로운 LongPtr 버전을 둘 다 쓸 수 있고 LongPtr이 내부적으로는 Long으로 도로 바뀌어 처리되는 반면, 64비트에서는 LongPtr만 써야 하고 Long을 쓰면 에러가 난다.

이 함수가 받는 매개변수도 32비트 범위로 충분한 GWL_STYLE, GWL_ID 같은 상수는 바뀐 게 없는데, 포인터와 크기가 같은 윈도우 프로시저나 인스턴스 핸들 같은 걸 지정할 때는 GWL_*말고 GWLP_*라는 명칭이 새로 추가되었다. 둘은 의미하는 값도 차이가 없는데 왜 이런 조치를 취한 것일까?

이는 단순히 프로그래머의 편의를 위해서이다.

int n = (int)GetWindowLong(hWnd, GWL_WNDPROC);

64비트에 환경에서는 윈도우 프로시저의 크기 (8바이트)가 int의 크기(4바이트)보다 더 크기 때문에, 이런 식으로 32비트 관행을 전제를 하고 작성된 코드는 64비트 환경에서 아예 컴파일이 되지 않게 하기 위해서이다.

INT_PTR n = (INT_PTR)GetWindowLongPtr(hWnd, GWLP_WNDPROC);

이렇게 짜 주면 32비트와 64비트에서 모두 안전하게 잘 동작하는 코드가 된다.

memory mapped file을 만드는 CreateFileMapping이나 MapViewOfFile 함수는 메모리의 크기를 64비트 범위로 잡을 수 있어서 그 값을 32비트 기계에서 처리하기 편하게끔 두 개의 32비트 숫자로 쪼개서 받아들인다. 64비트 윈도우에서는 굳이 그렇게 할 필요가 없지만 함수의 프로토타입이 바뀌지 않았다. 어차피 64비트 윈도우라고 해서 당장 4GB를 능가하는 어마어마한 양의 메모리를 한 번에 잡는 일은 실제로 거의 없기 때문이다.

GlobalAlloc, VirtualAlloc, HeapAlloc 같은 메모리 할당 함수들은 메모리의 양을 잡는 숫자의 자료형이 SIZE_T이다. 즉, 32비트 환경에서는 32비트, 64비트 환경에서는 64비트로 결정된다는 뜻. SIZE_T는 UINT_PTR과 의미상 사실상 동급인 셈이다.
하지만 파일을 읽고 쓰는 ReadFile와 WriteFile은 정보를 전송하는 단위가 SIZE_T도 아니고 그냥 DWORD(32비트)로 고정되어 있다.

다만, 32비트 환경에서라도 32비트 크기의 범위를 능가하는 방대한 파일을 취급해야 할 일이 있기 때문에 파일의 크기를 얻거나(GetFileSize), 파일의 특정 지점을 탐색하는(SetFilePointer) 함수는 역시 32비트 필드를 두 개 받아서 64비트 숫자를 전달할 수 있게 되어 있다. 윈도우 2000부터는 숫자를 32비트 단위로 쪼갤 필요 없이 64비트 숫자를 한 번에 전달받는 Ex 함수가 운영체제 차원에서 추가되었다.

MFC는 운영체제에 그런 Ex 함수가 추가되기 전부터 CFile::Seek나 CFile::GetLength는 언제나 64비트 정수를 다뤄 왔으니 속 편한 경우라 하겠다.

GlobalMemoryStatus 함수는 현재 컴퓨터의 전체 메모리 양과 남은 메모리 양을 되돌리는 함수인데, 램 용량이 4GB를 넘어서는 날이 올 거라고 과거에 상상이 가능했을까. 구조체의 각 멤버가 32비트 크기로 고정되어 있다가 이것이 64비트로 확장된 Ex 함수가 역시 윈도우 2000 때부터 추가되었다. 64비트 운영체제에서는 오리지널 함수를 없애 버려도 될 법도 해 보이는데 이건 오리지널과 Ex가 여전히 남아 있다.

16비트 시절에는 윈도우 메시지와 함께 전달된 두 개의 부가 정보 중 WPARAM은 16비트이고 LPARAM은 32비트 크기였다. 그러던 것이 32비트 환경에서는 둘 다 32비트가 되었다. 16비트와 같은 사고방식이라면 64비트 환경에서는 WPARAM은 32비트이고 LPARAM만 64비트로 승격해도 될 것 같으나 그렇지 않다. 둘 다 64비트이다.

machine word보다 더 작은 크기로 정보를 제한해서 담을 필요가 전혀 없을 뿐더러, 이미 32비트 시절에 WPARAM과 LPARAM을 구분하지 않고 포인터와 핸들을 담는 관행이 10년 넘게 지속되었을 텐데 다시 그 구분을 넣는다는 건 불가능한 지경이 되었기 때문이다.

한 플랫폼에서만 10년 넘게 프로그래밍을 하니까 이제는 그 API를 처음에 설계한 사람의 마음을 읽고 시대에 따른 변천사를 이해하는 경지에 도달하는 걸 느낀다. ^^

Posted by 사무엘

화상이 얼마나 고통스러운지, 그리고 불에 타 죽는 게 얼마나 고통스러운 죽음인지는 모르는 사람이 없을 것이다.
그래서 역사적으로 불은 사람에게 공포를 주고 대중을 통제하는 수단으로 잘 쓰이곤 했다.

작게는 담뱃불, 크게는 다리미나 인두로 생살을 지지는 것은 고문 방법으로 통용되어 왔다.
그리고 중세에는 화형이란 게 있어서 반역자나 종교적 이단 같은 죄질이 굉장히 나쁜 죄인은 이 방법으로 처형했다.

동양의 조선이나 중국은 거열형이나 능지처참 같은 다른 끔찍한 형벌이 있을지언정, 화형은 없었나 보다. 그래서 화형 하면 일단 중세 유럽이 떠오른다.
게다가 그 당시는 지금처럼 불에 활활 잘 타는 천연 가스나 석유· 석탄이 개발되어 쓰이기 전이었음을 생각해 보자. 그러니 사형수를 완전히 확 불태우는 게 쉽지 않은 일이었으며, 집행 시간은 길었고 그만큼 사형수의 고통도 더했다.

근현대에 와서는 먹고 살 만해지고 인권(?) 의식이 향상되면서 그런 잔인한 형벌은 사라졌다. 그러나 사회 구조가 막장인 곳에서는 열사의 길을 가기 위해 분신 자살이라는 엄청난 방법을 선택한 사람이 이따금씩 나오곤 했다.

우리나라는 대표적인 예로 전 태일이 있다(1948-1970).
노동청에 탄원서를 보내고 대통령 면담을 요청하는 등, 노동자의 권익 보호를 위해서 합법적으로 할 수 있는 일은 다 해 봤지만 바뀌는 게 전혀 없으니,
이놈의 있으나마나한 근로기준법에 사망 선고를 내리자는 차원에서 자기 몸에다 기름을 끼얹은 뒤 불을 지르고 만 것이다.

난 어렸을 땐 우리 민족은 6· 25 폐허에서 한강의 기적을 이룩해 냈다고까지만 배웠는데, 그 과정에서 이런 희생자도 있었다는 걸 나중에 알게 됐을 때, 적지 않은 충격을 받았다.

세계적으로 분신 자살/자결의 예로 가장 유명한 사건은, 틱 광둑이라는 환갑이 넘은 베트남의 어느 불교 승려의 죽음이다.
그는 남베트남의 부패 독재 정권(응고 딘디엠 대통령)의 학정을 세계에 알리고 이에 항거하는 뜻을 전하고자 1963년 5월 29일, 수백 명의 불자들에게 둘러싸인 가운데 가부좌를 하고 앉아서 휘발유 화염에 휩싸였다.

아니, 불교에는 대의를 명분으로 하는 이런 행위에 대해서 '소신공양'(燒身供養)이라고 용어가 따로 있다고 한다.
에밀레종 같은 얘기만 있는 줄 알았는데 그게 아니다. 하긴, 한국인에게는 김 동리의 소설 <등신불>을 통해 이 개념이 비교적 널리 소개되기도 했다.

세상에 사람이 라이브로 불에 타 죽는 장면은 영화로도 보기가 쉽지 않다. 그런데 틱 광둑 스님의 충격적인 자결 장면은 처음부터 끝까지 동영상과 정지 사진으로 촬영되어 전세계에 알려졌다. 이것이 국제 사회에 경종을 울리고 독재 정권의 명을 재촉했음은 물론이다.
동영상을 보면 알 수 있듯, 그는 죽는 마지막 순간까지도 고통에 울부짖거나 바둥대지 않았고 꼿꼿하게 책상다리 차림으로 앉아 있었다. 절명해서 몸에 힘이 완전히 빠진 뒤에야 뒤로 벌렁 넘어갔다.

지금으로부터 무려 반세기 가까이 전인 1963년의 일인데 동영상이 컬러로 남아 있고 오히려 정지 사진은 흑백이다.
동영상 (1:34 지점부터 불이 확! 2:21에 시신이 쓰러짐)
정지 사진
비위가 약하신 분은 열람 금지.

동영상은 멀리서 찍은 것이고 활활 타는 불밖에 안 보이는 반면, 정지 사진은 고인의 모습을 비교적 가까이서 여러 장 찍은 듯하다.

처음에 밝은 색 계열이던 승복이 시간이 흐르면서 새까맣게 탔다.
화마가 얼굴 피부까지 검붉게 할퀸 모습은, 흑백이 아닌 컬러 사진이라면 훨씬 더 참혹하고 끔찍한 장면이었을 것이다.
안면 화상을 입은 이 지선 씨 모습만 해도 얼마나 끔찍했던가?

응고 딘디엠 정권은 막장이었을 뿐만 아니라 불교를 대놓고 탄압까지 했다. 뭐 그렇다고, 시대가 20세기인데 멀쩡한 불자들을 잡아 죽인다거나 한 건 아니고, 사찰을 파괴하고 석가탄신일을 금지하는 등 불교를 제도적으로 디스하고 불이익을 준 정도이다.

그런데 여기서 굉장히 이상한 점이 있는데, 응고 딘디엠은 독실한 가톨릭 신자였다는 점이다! 정부 관료들도 전부 가톨릭 신자만 등용했다.
분명히 말하지만 개신교 계열이 절대 아니다. 그런데 불교를 탄압했다고라...
응고 딘디엠의 아내, 즉 베트남의 영부인이라는 사람은 틱 광둑 스님의 죽음을 보고는 아예 “바베큐 파티”라고 천하의 개쌍놈급의 개드립을 공공연히 치기도 했다.

난 정말 이상함을 느꼈다.
우리나라는 가톨릭과 불교가 얼마나 사이가 좋은가?
성탄절과 석가탄신일 때 천주교계와 불교계가 서로 축하해 주는 건 뭐 관행으로 정착한 지 오래이다.
그러면서 천주교는 타 종교에 대해서 관용과 화합 잘 한다고 폭풍 칭송을 받고 있는 반면에, 우리나라에서는 개독 먹사들이 담대하게 복음 전한 것도 아니고 타 종교인들에게 무례한 무개념 병크 저질러서 간증 상실하고 욕 바가지로 얻어먹고 있지 않은가?

물론 가톨릭의 전략을 아는 사람에게야 이런 차이가 그리 새삼스럽지 않을 것이다. 그들은 각 국가와 문화에 따라서 자신이 약자일 때나 경쟁자와 아직 동급일 때 취하는 전략이 다르고, 마침내 그들이 진짜 주류가 되고 정치· 종교적 갑이 되었을 때 시행하는 전략이 또 완전히 다르다. 섬뜩할 정도로 다르다. 우리가 역사를 통해 뭔가를 배우고자 한다면, 이런 패턴을 배워야 할 것이다.

기독교는 교회 역사상 순교자가 셀 수 없이 많이 나왔으며, <폭스의 순교사> 같은 책을 보면 '흠좀무'라는 말밖에 안 나오는 사례들이 많이 기록되어 있다. 특히 (겉보기로) 아무 고통 없이 화형 당한 사람 얘기가 나온다. 토머스 헉스(Thomas Haukes)라는 사람은 1555년, 피의 메리 시절에 유아 세례 반대라는 죄목으로 화형을 당해 순교했는데, 불에 타 죽는 고통이 견딜 만하면 위로 손을 뻗어 손뼉을 치고 죽을 테니 손은 묶지 말라고 말했다. 그리고 그는 진짜로 손뼉을 세 번 친 뒤 숨을 거뒀다고 한다.
그런데 이런 사건 자체는 기독교에만 있는 사건이 아닌 것 같다. 불에 타 죽는 고통조차도 인간의 극한의 정신력으로 극복할 수 있는 것인지 신기한 일이다.

틱 광둑에 이어, 우리나라에서는 지난 2010년, 문수 스님이라는 노승이 이 명박 정권을 정면으로 비판하고 4대강 사업의 전면 중단을 촉구하면서 소신공양으로 생을 마감했다. <민중의 소리> 같은 진보 성향 언론에서는 진짜 문자 그대로 새까만 숯덩이가 되어 버린 고인의 시신까지 사진으로 공개했다. 이것 역시 비위가 약한 분은 클릭 금지.

그런 사람들이 인간적으로야 정말 숭고한 뜻으로 자기 목숨을 그렇게 비장하게 초개처럼 버렸을 수는 있다. 허나 인간의 의로 참 하나님의 절대적인 의의 기준을 통과할 수 없다는 것은 실로 애석한 일이 아닐 수 없다.
사람의 육신의 몸이 불타면서 느끼는 고통은 정말 끔찍하긴 해도 그래도 길어야 수 분이 채 안 되어 끝이겠지만, 그 동일한 고통을 죽음으로 종결지을 수조차도 없이 영원무궁토록 겪어야 하는 '그곳'에 또 가게 된다면 얼마나 안타까울까??

마가복음 9장 끝부분에 기록된 “거기는 그들의 벌레도 죽지 않고 불도 꺼지지 않느니라” 3콤보의 경고를 이 시간에 되새기도록 하자. 이것이 하나님으로부터 진짜로 정죄받은 죄인의 최후인 것이다. (단, 3콤보는 KJV에만 있음)

이런 얘기를 접하노라면, 이와는 반대로, 맹렬히 불이 붙었는데도 재가 되지 않고 멀쩡히 살아있는 떨기나무(출 3:2-3)가 얼마나 대단한 기적인지 실감하게 된다. 또한, 평소보다 연료와 공기를 7배나 더 공급해서 달궈진 맹렬한 용광로 불길로부터 멀쩡히 살아서 돌아온 다니엘의 세 친구들 이야기가 얼마나 경이로운지도 또 실감하게 된다. 하나님은 불을 만드신 분이고, 연소라고 불리는 급격한 화학적 산화 현상을 제어하여 예외로 적용할 능력도 응당 갖추고 계시기 때문이다.

성경에 따르면 결박만 없어졌을 뿐 그들은 머리털 하나도 상하지 않았고 옷도 전혀 타지 않았다고 기록되어 있다(단 3:27). 오히려 그들을 용광로에 집어넣으려던 병사가 허둥대다가 불에 타 죽었다. 그러나 용광로에서는 하나님의 아들, 곧 성육신 전의 예수님이 그들을 미리 기다리고 있다 맞이했다니 얼마나 경이로웠을까? (세 명이 아니라 네 사람이 용광로에 있었다. 단 3:25) 그들은 왕이 부르기 전까지는 오히려 용광로에서 나가고 싶지 않았을 것이다.

물론, 하나님께서 인류 역사상 수많은 순교자들 중에 다니엘의 세 친구들에게만 예외적으로 기적을 허락해 준 것은 하나님의 경륜상의 특별한 이유 때문이었을 것이다. 게다가 그들은 하나님께서 설령 자기를 불에서 구해내지 않고 죽게 허락할지라도 그래도 느부갓네살 왕의 형상에는 절을 하지 않겠다고, 한 치의 타협도 하지 않고 순교를 불사할 생각으로 단호하게 자기 신앙을 “먼저” 지켰다는 것을 우리는 명심할 필요가 있다. (단 3:17-18) “그리 아니하실지라도”라는 찬양의 의미를 생각해 보자.

지금까지 불, 화상, 화형, 분신자살, 순교 등 여러 섬뜩한 주제로 어찌 보면 두서없을 수도 있는 형태로 얘기가 나왔다.
글을 쓰면서 더욱 느꼈는데, 나는 인간의 알량한 의를 내세우지 않는 나의 종교, 아니 나의 신앙이 좋다. 복음이라는 말이 괜히 나온 게 아니다.

성경의 하나님은 그 아무리 큰 죄를 짓고 그 어떤 급으로 하나님이나 교회, 기독교의 명예를 실추시켰다 하더라도 진심어린 눈물의 회개만 하면 다 용서하고, 생명이 붙어 있는 한 사람을 다시 사용해 주신다. 그래서 베드로의 예수님 부인과 회개 장면이 더욱 드라마틱하게 읽히는 것이다.

성경에는 너희(크리스천) 몸을 하나님께 살아 있는 희생물로 드리라는 권면이 분명히 기록되어 있지만(롬 12:1) 그건 무슨 신앙의 자유를 위해 세상 정부를 상대로 투쟁하고 시위대의 불화살이 되거나, 명예 회복을 위해 할복을 하라는 소리가 절~대로 아니다. 너도 십자가형 체험을 일부러 해 보라는 소리도 결코 아니다. 남이 먼저 날 죽여서 순교를 하면 했지, 기독교는 그 어떤 명분이라도 자해나 자결 같은 열사의 길을 권장하지 않는다. 그런 식으로 티를 내 봤자 우리 의가 설마 예수님의 의를 능가하겠는가?

기독교가 세상의 여느 시민 단체, NGO 단체와 다를 바가 없다면, 매 예배 때마다 아마 순교선열들에 대한 묵념도 하고, 각종 유명한 순교자들의 동상도 세워서 떠받들고 숭배하는 게 정상일 것이다. 그래서 천주교에서 하는 게 딱 이러한 발상에서 비롯된 성인 시성과 성인 숭배이다. 수많은 크리스천들을 잡아 죽인 종교이지만, 자기네들이 내세우는  자기네 순교자도 없는 건 아니어서..=_=;; 그러나 성경을 믿는 기독교는 애시당초 그렇게 사람을 떠받들지 않으며, 그건 다 이유가 있기 때문이다.

기독교는 죄 때문에 인간이 정말로 죽어야 할 때도 동물을 대신 피 흘려 죽게 해 주고, 나중에는 하나님께서 직접 성육신하여 인간에게 죽임을 당했다고 가르친다. 심청전에도 나오는 인신 공양 같은 게 절대로 없다. 다른 종교와는 차원이 다르다. 구약 성경에서 하나님께서 이스라엘 백성에게 이방 민족들을 전부 죽이고 흔적도 남기지 말고 파괴하고 멸하라는 잔인한 명령을 왜 내렸는지 아는가? 이 방법이 아니면 이방 민족들의 그런 악한 관행들을 뿌리뽑을 수가 없어서였다!

아무쪼록 육신의 장막을 벗고 사망도, 슬픔도, 고통도, 울부짖음도 없는(계 21:4) 세상이 올 것을 염원해 본다. 여기에는 불에 의한 사망, 고통, 울부짖음도 당연히 포함되어 있다. 불 및 불과 관련된 일련의 사건들을 생각하면서도 많은 사람들이 구원의 길을 다시 생각하고 예수님께로 돌아오면 좋겠다.

NOTE:

'스님'은 님짜 때문에 높임의 뜻이 들어가기 때문에, 공식적인 글에서는 '승려' 정도가 적절하다는 지적이 있다. 그에 대해서 나는 좀 회의적이다. 그런 식의 논리이면 '장님'도 분명히 높임말이다. 그런데도 그건 또 정서적으로 받아들여지지 않아서 성경에 나오는 장님이나 소경도 요즘은 다 그냥 '맹인'이나 심지어 시각 장애인으로 바뀌는 추세이다.

님짜를 뗀 '스'는 말이 되지 않으며, '장'도 마찬가지이다. 심지어 '하나님'도 님짜를 떼면 말이 되지 않는다. 본인은 그런 단어들은 단어 전체를 한 형태소로 보며, 그렇게 의도적인 존칭이 들어가 있다고 생각하지 않는다. 이 점을 염두에 두고 본문에서 '스님'이라는 단어를 사용하였음을 밝힌다.

그 반면에 '예수님' 다음의 님짜는 명백하게 존칭어미이다. 그래서 우리끼리는 글 쓸 때 예수님이라고 하지만 다른 불신자들은 그냥 예수라고만 부른다.

Posted by 사무엘

과거에 항공 교통이 지금처럼 거대해지기 전에는, 철도 간이역처럼 자그마한 건물에다 활주로랍시고 잔디밭 공터만 덩그러니 있는 시설에서 비행기가 뜨고 내린 적이 있었다. 그러나 오늘날은 여객용 공항 대접을 받으려면 첨단 관제 시설과, 튼튼하게 포장된 활주로, 편의 시설을 갖춘 여객 터미널과 주변 보안 시설 등이 필수이다.

크기뿐만이 아니라 공항의 특성을 분류하는 속성(property; attribute)들로는 당장 다음과 같은 것을 떠올릴 수 있다.

1. 국제 공항인가?

국제 공항은 일반적으로 국내선 비행기보다 더 큰 여객기를 취급할 수 있어야 하고, 세관이나 검역 (그리고 면세점) 같은 추가 시설이 있어야 한다. 국제 공항 내부의 면세 구역은 국제법상으로 나름 치외법권 지대이다.
대구에 있는 공항은 대구 국제 공항이지만, 포항이나 울산에 있는 공항은 국제 공항이 아니다.

2. 24시간 운항 가능한가?

비행기는 움직이면서 주변에 끼치는 소음 공해가 장난이 아니다. 그렇기 때문에 주거지로부터 충분히 멀리 떨어져 있지 못한 공항은 민폐를 끼치지 않기 위해 심야 시간대에는 비행기 취급을 금지하는 curfew가 시행된다.

멀찍한 영종도에 건설된 인천 공항은 24시간 운항 가능하고 청주 공항도 마찬가지이다. 그러나 김포나 제주 공항은 그렇지 않음. 그래서 밤에 김포 공항으로 날아가는 비행기가 만약 지연크리를 먹게 되면, 부득이 김포 공항에 못 내리고 인천 공항에 착륙하는 경우가 생긴다. 사실, 국제 허브 공항 역할을 하는 데는 운행 시간대의 제약이 없이 24시간 운항 가능한 공항이 좋을 것이다.

3. 대표하는 지역과 일치하는 지명으로 불리는가?

대도시의 유명 공항은 의외로 해당 도시의 이름으로 불리지는 않는 경우가 있다. 인천(서울), 김포(서울), 김해(부산) 등. 일본 도쿄(하네다/나리타), 미국 뉴욕(케네디), 영국 런던(히드로)을 대표하는 간판급 공항도 지역 이름이 공항 이름이지는 않다. 그러나 역시 미국의 대도시인 LA의 공항은 그대로 LA 국제 공항. 명칭은 말 그대로 케바케인 셈이다.
우리나라는 김포 공항은 김포에 있지 않고 서울에 있는데, 서울 공항은 서울이 아닌 성남에 있다. 좀 웃기지 않은지?

4. 군사 비중은?

요즘 철도역이나 버스 터미널은 백화점 내지 영화관 같은 상업 시설과 결합한 민자 형태로 건설되는 경우가 많으며, 김포 공항도 청사 하나가 완전한 상업 단지로 개조되면서 그런 유행을 많이 받아들였다. 그러나 공항은 마냥 민간 상업 시설로만 쓰기에는 군사적인 역할이 차지하는 비중도 무척 크다.

한국의 대표적인 간판 공항인 김포와 인천 공항은 100% 민간 공항이다. 그렇기 때문에 인터넷 지도로 항공 사진을 봐도 활주로의 모습까지 모두 공개되어 있다. 그러나 우리나라에 100% 민간 공항은 흔치 않다. 김포와 인천 말고는 울산, 여수, 양양 정도가 고작.

그래서 당장 김해나 제주 공항에만 가도 인근의 군사 시설 때문에 경비가 서울의 공항들보다 훨씬 더 삼엄하며 공항 주변에 사진 촬영도 함부로 못 한다. 민· 군 겸용 공항인 것이다. 그래서 인터넷 지도를 보면 이런 공항들은 김포· 인천과는 달리, 활주로가 흐리게 처리되었거나 공항 부지가 아예 풀숲· 논밭으로 대체된 것을 볼 수 있다. 포항, 대구, 청주, 원주 공항들이 모두 마찬가지이다. 다 이유가 있어서 그렇게 된 것임.

민간 여객기를 전혀 취급하지 않고 공군이 전투기를 띄울 때만 사용하는 100% 군용 공항은 대체로 그냥 비행장이라 불린다. 하지만 군용 공항 중에서 성남의 서울 공항은 국빈 방문 때도 사용되고, 에어쇼 할 때 민간인 접근을 허용하기도 하는 예외적인 경우이다. 사실, 유사시에 만약 김포와 인천 공항이 마비된다면 수도권에 있는 이 공항과 국토의 중앙에 있는 청주 공항이 대체 공항 역할을 하게 될 것이다.

군대, 보안 하니까 생각나는 분석인데 말이다. 고정익 항공기를 띄우는 공항은 하늘 위가 뻥 뚫린 방대한 면적의 활주로가 필요하다는 이유로 인해, 은폐가 사실상 불가능하다. 핵무기 연구야 지하 실험실에서 몰래 한다 하더라도, 비행기는 역학 특성상 지하에다가 활주로를 만들어서 거기서 비행기를 불쑥 띄울 수는 없는 노릇이지 않은가. 그리고 활주로가 또 좀 기냐? 그러니 인공위성 사진에 공항은 어지간하면 다 노출이 된다.

요즘 버스 터미널은 상업 시설과 결합하여 정작 버스 탑승은 지하에서 하기 때문에 밖에서 보면 버스 터미널이라는 티도 안 나는 경우가 있다. 성남 버스 터미널이 좋은 예임. 철도도 그렇다. 광명 역은 KTX가 서는 역 중에 지상에서 역의 앞뒤로 레일이 전혀 안 보이는 유일한 역이다.
하지만 공항은 항구만큼이나 그런 티가 안 나게 만들어지지는 못할 듯하다. (원주 공항은 여객 터미널과 활주로가 서로 멀리 떨어져 있는 경우임)

Posted by 사무엘

주기적으로 또 철도(+성경) 드립을 좀 칠 때가 됐다.

1. 나 자신이 하나님 앞에서 죄인임을 시인하고, 예수님의 죽으심과 부활이 진정 나를 위한 것이었음을 믿고 그분을 나의 개인적인 구주로 받아들인 사람이 곧 구원받은 사람이다.
그것처럼 경부선, 중앙선 등 한국의 모든 철도가 진정 나를 위한 것임을 인지하고, 철도 규격 및 건설 역사 같은 얘기를 듣기만 해도 마치 내 일처럼 감격과 기쁨과 행복을 느끼는 사람이 바로 철도 성령으로 충만한 사람이다.

2. 내가 확신하노니 사망이나 생명이나 천사들이나 정사들이나 권능들이나 현재 있는 것들이나 장래 있을 것들이나 높음이나 깊음이나 다른 어떤 창조물이라도 능히 우리를 새마을호 안에 있는 한국 철도의 사랑에서 떼어 놓지 못하리라.

3. 내가 또한 받은 것을 무엇보다 먼저 너희에게 전하였노니 그것은 곧 문헌 기록대로 대한민국에 새마을호 열차가 1974년부터 운행되었으며 1987년부터는 전후동력형 디젤 동차가 투입되었고 2002년부터 2007년 사이에는 시발역 출발 전과 종착역 도착 직전에 Looking for you가 흘러나왔다는 것이라.

참으로 철도는 모든 것이 사랑스럽도다. (yea, the railroad is altogether lovely 아 5:16 참고)
2와 3도 성경 구절 패러디인데, 원래 구절이 뭔지 궁금하신 분은 알아서 찾아 보시라. ㅋ

4. “마이크로소프트 UX팀의 이사 샘 모라우가 밝힌 바에 따르면, 메트로 UI는 지하철이 지나가는 모습에서 영감을 얻어 탄생한 UI라고 한다. 이름부터 ‘Metro(지하철)’다.”
그래서 메트로이구나! 오 역시나 윈도우 8을 개발하는 과정에서 철도 성령이 MS에게도 임한 게 분명하다!!

세월이 흐르면서 그리스도인이 구원에서 성화로, 내가 아닌 남을 생각하고 남의 믿음을 세워 주는 단계로 신앙이 성숙하듯, 철도와 본인과의 개인적인 교제도 더욱 친밀해지고 있다.

최근에 이 사이트에서 해 본 테스트에서 본인은 절대음감 인증을 받았다. 그냥 대충 찍은 것도 많고, 좀 더 집중해서 문제를 풀었으면 더 높은 점수가 나올 수도 있었겠지만, 어쨌든 이 정도도 그리 나쁜 점수는 아니니까. 둘 다 36점 만점인데, 확실히 순수 싸인파가 피아노 소리보다 훨씬 더 분간하기 어렵다.

하긴, 유니클락 배경 음악을 들으면서도 난 이런 생각이 바로 들었다.
“이 곡 템포는 정확하게 ♩=120 이겠구나!” (왜 그런지 화면 보호기+음악 시청하면서 생각해 보셈)

어떤 음악이든 앞부분 몇 초를 들으면 조와 템포와 박자부터 먼저 귀에 들어오고 악보가 떠오른 경지에 도달하게 된 것도 철도 덕분이다. Looking for you를 3천 번 들으면서 채보를 해 보면 누구나 저렇게 될 수 있다. 이건 전적으로 집념과 노력의 결과이지 선천적인 재능이 아니다.
철도님, 사랑합니다.

Posted by 사무엘

굳이 전산학이나 컴퓨터과학· 공학의 전공자가 아니어도, 그리고 현업 프로그래머가 아니더라도 조금만 기계 다루는 것에 조예가 있는 컴덕후라면 요즘 컴퓨터의 발전 추세가 어떤지는 다들 알 것이다. 사실은 <날개셋> 한글 입력기의 개발자인 본인보다도 더 잘 알 것이다.

튜링 완전하며 메모리로부터 프로그램을 읽어 와서 구동하는(프로그램 내장 방식) 범용 컴퓨터가 발명된 지가 아직 100년은커녕 반세기 남짓밖에 지나지 않았다. 그러나 컴퓨터의 속도와 메모리 용량은 가히 넘사벽급으로 발달했다. 컴퓨터는 지난 수십 년 동안 자연이 아니라 인간의 발명한 물건의 내부에서, 시간에 따른 지수함수 스케일의 발전을 볼 수 있던 얼마 안 되는 엄청난 분야였다.

그러나 그것도 한계는 있어서 컴퓨터 성능의 대표적인 지표이던 클럭 속도가 2003년 즈음에 놀랍게도 지수함수적인 성장이 멈췄다. 10년까지는 아닌 거 같다만 8, 9년 전의 PC나 지금의 PC나 다 3GHz대이다. 오늘날과 같은 반도체 회로라는 근본적인 패러다임이 바뀌지 않는 한, 전력 소모와 발열 때문에 컴퓨터의 기본 동작 자체만의 속도가 더 빨라질 수는 없다.

우리가 다루는 컴퓨터는 생각보다 굉장히 정밀하고 빡세게 만들어져 있다. 예전부터 파이프라인, pre-fetching 등 온갖 있는 테크닉, 없는 꼼수를 다 동원해서, 어떻게든 낭비되는 자원이 없이 모든 자원이 계산에 동원되고, 1ms라도 속도를 더 올리려고 공돌이들의 온갖 공밀레 연구가 동원되었다. 이런 수직적인 성장이 한계에 달하니 요즘 컴퓨터는 코어 수를 늘려서 분업이라는 수평적인 성장을 추구하고 있다.

100이라는 일이 있어서 이게 2GHz짜리 컴으로 다 처리하는 데 10이라는 시간이 걸린다면, 1GHz짜리 컴으로는 20만큼의 시간이 걸릴 것이다. 그러나 1GHz 짜리 컴이 2개 있어서 그 일을 정확히 50씩 분담할 수 있다면, 각각의 컴퓨터의 최대 속도는 비록 1GHz밖에 안 되더라도 10에 가까운 시간 만에 일을 끝마칠 수 있어서 2GHz에 준하는 효과를 낼 수 있다. 이것이 기본적인 아이디어이다.

물론, 딱 10으로 줄이지는 못한다. 일을 분할하고 두 대의 컴퓨터를 세팅하고 굴린 후, 두 컴퓨터(코어)가 내놓은 결과를 취합하는 오버헤드가 역시 결코 작지 않기 때문이다. 그리고 세상에 상호 의존성이 없이 역할을 저렇게 딱 분담할 수 있는 작업이란 흔치 않다.

방대한 계산이 필요한 작업을 다수의 컴퓨터 기계들을 여러 대 동원해서 수행하는 건, 분산 컴퓨팅이라 하여 예전부터 그리 생소한 개념이 아니었다. 3D 그래픽으로 영화를 만드는 업계에서는 rendering farm이라 하여 수많은 컴퓨터들을 농장에다 비유할 정도로 열나게 굴려서 영상을 만들어 낸다. 빌드 속도가 느린 걸로 악명 높은 C++ 언어를 위해서 Incredibuild라는 이스라엘산 분산 빌드 시스템도 있다.

그런 것처럼 개개의 컴퓨터도 이제 코어가 여러 개 돌아가고 멀티스레딩 능력이 충분히 뛰어나니, 이제는 프로그램 차원에서 멀티코어-aware한 개발이 필요해졌다. 왜냐하면 분산 처리 시스템을 설계하는 건 정말 머리가 뽀개질 정도로 복잡하기 때문에 컴퓨터나 컴파일러가 자동화를 해 줄 수 없다. 예전 계산 결과에 의존적인 다음 계산을 병렬로 동시 수행시킬 수는 없는 노릇이니까 말이다.

그렇기 때문에 멀티코어-aware하지 않은 옛날 프로그램은 컴퓨터가 언제나 최악의 case로 가정하고 보수적으로 돌려서 코어를 하나만 할당하여 돌아가게 된다. 한 프로그램이 while(1); 만 하고 가만히 있다 해도 CPU 사용률이 100%로 치솟지 않는다.

특히 C/C++의 포인터는 그야말로 아무 메모리 주소나 가리킬 수 있고, *a, *b가 있으면 둘이 가리키는 주소가 같을지 아닐지 등 최적화나 병렬화를 할 여지가 없을 정도로 너무 generic하기 때문에 오히려 처리가 어렵다고 한다. 파스칼이나 포트란처럼 언어 표현력이 C/C++보다 부족한 대신에 컴파일러가 소스 코드만 보고서 그 복잡도를 어느 정도 파악할 수 있는 언어가 병렬화에는 오히려 더 유리하다고.

그래서 소스 코드의 특정 구간에 대해서 컴파일러나 CPU가 안심하고 병렬화를 할 수 있게 중간 중간에 부가정보를 인위적으로 넣어 줄 필요가 생겼는데, 이런 부가정보를 기술하는 표준 규격 중 하나가 그 이름도 유명한 OpenMP이다. #pragma omp 같은 컴파일러 지시자도 있고, OpenMP 라이브러리보부터 호출해서 쓰는 함수도 있다.

옛날에 C언어가 처음 발명되던 시절엔 최적화를 위해서 변수를 가능한 한 레지스터에 올려라고 지시하던 register라는 카워드가 있었는데, 앞으로 C/C++ 같은 네이티브 코드 언어는 멀티코어를 언어 차원에서 수용하는 규격이 덩달아 생겨야 할 것이다.

물론, CreateThread 같은 함수를 써서 코드의 로직 차원에서 대놓고 여러 작업 스레드를 만들었다면, 단일 프로세스가 여러 개의 코어를 자연스럽게 점유하는 게 응당 가능하다. 그러나 디자인의 성격상, 멀티스레딩은 보통 일하는 스레드, 사용자 UI 스레드, 입출력 신호를 기다리는 스레드처럼 용도별로 달리 배당하는 게 바람직하지, 동일한 일을 하는 코드 내부에서 굳이 다중 코어 활용을 위해 스레드를 분할하기에는 동기화를 비롯해 일이 너무 복잡해진다. 서버 같은 게 아니라면, 제각기 CPU를 full로 사용하는 여러 작업 스레드를 만들 일 자체가 매우 드물다.

이때 멀티코어 프로그래밍을 잘 하면 이런 단일 코드가 명시적인 스레드 생성을 하지 않고도 CPU의 자원을 골고루 전부 활용해서 고성능으로 돌아가게 된다. 다만 앞서 말했듯이 이렇게 작업을 분할하는 오버헤드부터가 큰 편이기 때문에, 소규모 작업보다는 동영상 인코딩이나 대용량 파일 압축이나 컴파일 같은 진짜 방대한 작업에서 멀티코어의 진가는 더욱 두드러질 것이다.
일례로, 비주얼 C++은 2005부터 빌드할 때 병렬 컴파일이 수행된 경우, 빌드 로그에 해당 빌드를 수행한 코어의 번호가 뜬다.

O(n^3)짜리 행렬 곱셈은 워낙 단순 무식하고 복잡한 의존도 따위도 없는 순수 노가다이다 보니, “나 병렬화 해 주세요”라고 온몸으로 외치는 문제라고 볼 수 있다. 퀵 정렬이나 병합 정렬처럼 구간이 딱딱 나뉘는 알고리즘이 병렬화에도 적합한 구조일 것 같긴 하다만, 요즘 컴퓨터의 성능이라면 겨우 internal sort 규모의 정렬 작업은 굳이 멀티코어를 쓸 필요도 없을 정도로 금방 끝날 듯.

요컨대 이제는 고성능 컴퓨터를 쓰는 것만으로 프로그램의 수행 속도가 저절로 올라가는 시대는 끝났다. 그 다음으로 레지스터 배당이라든가 캐시나 파이프라인 적중률 같은 건 CPU 설계에 맞춰 컴파일러가 더 똑똑해야 하는 영역인데, 이 역시 튜닝의 수준은 예술의 경지에 도달해 있다. 그리고 그 다음으로 필요해진 것이 코드에 등재되어 있는 병렬화 가능성 정보라고 생각하면 되겠다. 멀티코어는 프로그래머가 잘 숙지하고 있어야 하는 프로그래밍 패러다임이 되었음이 틀림없다.

Posted by 사무엘

잘 알다시피 <날개셋> 한글 입력기는 Windows용 한글 IME이다(IME이기만 한 건 아니지만). 이 분야는 경쟁 프로그램이 거의 없다시피하기 때문에, MS가 직접 공급하는 IME를 제외하면 3rd party 한글 IME 중에서는 <날개셋> 한글 입력기가 가히 독주를 하는 중이다. 그 이유로는,

첫째, 모바일용도 아니고 PC용으로는 한글 입력 방식이 딱히 더 만들 게 없다고 여겨지고 있어서인 것 같다. 그리고 딱히 돈이 되는 것도 아니니까 말이다. 싸제 IME가 활발히 쓰이고 있는 중국어· 일본어 IME의 개발 환경과 비교했을 때 이것이 크게 다른 점이다.

그리고 둘째로는, 윈도우용 IME라는 게 여타 운영체제의 IME와 비교해 보더라도 그 아키텍처와 스펙이 미치도록 폐쇄적이기 때문이다. 비록 프로토콜이 공개돼 있는 건 있지만, 그것만 참고해서는 쌩쌩 잘 돌아가는 한글 IME를 절대로 만들 수 없다. 문서화되지 않은 무수히 많은 상황에 대한 대비를 해야 되는데 이걸 이제 와서 혼자 처음부터 만든다는 건 불가능에 가깝다.

그럼에도 불구하고 <날개셋> 한글 입력기 말고 ‘싸제’ 한글 IME가 전혀 없는 건 아니다. 본인은 MS가 개발하지 않은 한글 IME를 최소한 두 종류를 더 알고 있다.

※ 새나루

윈도우 DDK에 등재되어 있는 FakeIME라는 일본어 예제 IME를 고쳐서 만들어진 한글 IME이다. 오픈소스 진영에서 만들어진 프로그램답게 소스 공개이다. 개발자들은 본인처럼 아예 대놓고 국어 정보학 쪽으로만 발을 들인 것도 아닌데 이쪽으로 조예가 굉장히 깊은 고수 프로그래머이다.

싸제 IME답게 여러 실험적인 기능이 많아서 실속이 있으며, 그러면서도 <날개셋>보다 덩치 작고 가볍다는 이점이 있다. 특히 <날개셋>이 개발 방향의 특성상 의도적으로 더 지원하지 않는 다음 기능들 때문에 새나루를 선호하는 사람도 있다.

키보드 드라이버 차원에서 드보락 글자판과의 연동: 쉽게 말해, 단축키까지 드보락 식으로 나오면서 그 상태에서 한글 입력까지 지원.

글자가 아니라 단어 전체를 조합으로 잡아서 단어 단위로 한자 치환: 일부 한자 혼용론자가 무척 좋아하는 기능이라 한다. MS IME로는 이 기능은 TSF A급 프로그램에서만 가능하며, <날개셋> 한글 입력기 역시 훗날 이 기능을 추가한다 하더라도 MS IME처럼 TSF A급에서만 지원할 것이다.

이 외에도 잘은 모르겠지만, 안 마태 키보드 드라이버도 입력 스키마를 살짝 변조한 수준에 머물러 있는 <날개셋>보다 새나루가 좀 더 지원을 잘 하는 게 있는 듯하다.

다만, 새나루의 개발자는 <날개셋>의 개발자처럼 한글 입력기 하나에만 완전 목숨을 건 타입은 아니다 보니, 프로그램의 유지· 보수와 버전업이 <날개셋>만치 애착을 갖고 꼬박꼬박 되고 있는 건 아니어 보인다. 하긴, 무료 소프트웨어가 이 정도라도 개발되어 온 게 감지덕지지.

※ Unicode CJK IME

이건 아는 분이 얼마 없지 싶다. 이건 무려 남북 합작으로 개발된 프로그램이다. 주 개발은 북한의 평양 정보 센터(PIC)에서 했으며, 남한의 한국 과학 기술 정보 연구원과 고려 대학교 민족 문화 연구원은 프로그램을 설계하고 각종 한자 데이터베이스를 구축했다. PIC는 서체도 만들고 ‘단군’이라는 워드 프로세서도 개발한 적이 있을 정도로 문자 처리 쪽에 기술이 상당한 수준이다. 그러니 IME도 만들었다.

세벌식은 전혀 지원하지 않지만, 남북 합작 IME 답게 북한 두벌식을 지원한다. 그리고 한양 PUA 방식의 옛한글을 지원하며, 문자표, 부수로 한자 입력, 자체 한자 사전 등의 기능을 내장하고 있다.

제목에서 알 수 있듯, 이 제품은 한글 IME뿐만이 아니라, 동일한 UI 엔진 기반으로 개발된 중국어· 일본어 IME와 한 세트를 구성하고 있다. 북한에서 그런 것까지 만들었다. 하지만 이들 IME의 성능(사전 크기 및 어절 분할 정확도)은 본인이 판단하기에 운영체제가 기본 제공하는 중국· 일본어 MS IME보다 못하다.

이런 프로그램들과는 달리, <날개셋> 한글 입력기는 처음에는 전용 에디터로만 개발되고 있었다. 2.x 시절까지만 해도 본인은 내가 스스로 한글 IME를 만들 수 있을 거라고 생각도 못 하던 처지였다. 그랬는데 2003년은 참으로 드라마틱하게도 한글 IME 개발의 원년으로 등극하게 되었다.

새나루는 2003년 말에 첫 버전이 나왔다. 그리고 본인이 접한 Unicode CJK IME 역시 2003년 6월자 버전이었다(다만, 그 후로 유지 보수는 중단된 듯). 그리고 그 해 가을에 출시된 MS 오피스 2003은 한자 변환 기능이 크게 강화되어 단어 단위 한자 변환이 처음으로 도입된 버전이었다. 이게 다 우연인 걸까?

이런 일련의 사건을 계기로 본인은 운영체제의 IME 스펙을 처음으로 공부하기 시작했으며, <날개셋> 한글 입력기를 운영체제의 IME로 거듭나게 하려는 연구를 난생 처음으로 시작했다. 마침 2003년 하반기이면 <날개셋> 한글 입력기 역시 3.0이 개발 중이었고, 입력기의 내부 구조를 싹 뒤집어 엎고 있었다. 나의 대학 3학년 시절, 이때가 <날개셋> 한글 입력기의 미래를 결정하는 개발이 이뤄지던 시절이었으니, 흥미롭지 않을 수 없다.

그래서 <날개셋> 한글 입력기에 좀 이렇다 할 외부 모듈이 난생 처음으로 탑재된 건, 2004년 9월에 나온 3.02 버전이다. 한글 입력기를 표방하면서 정작 윈도우용 IME가 나온 것은 새나루나 남북 합작 IME보다 시기적으로 늦다.

첫 버전은 당연히 정말 불안정했고 볼품없는 퀄리티였다. 아직 운영체제의 IME 시스템의 내부 구조를 제대로 이해 못 한 상태에서 최소한의 글자 찍기만 가능하던 상태였다. 이 때문에 직후 버전인 3.1에서 당장 무더기 버그 패치가 이뤄졌으며, 그 후로 외부 모듈이 큰 안정화 단계를 마치기까지는 1년이 넘는 시간이 더 필요했다.

그러나 첫 진입 단계에서 이런 시행착오를 충분히 겪은 뒤엔, 워낙 탄탄한 자체 한글 입력 시스템을 갖추고 있던 <날개셋> 한글 입력기가 완성도 높은 윈도우용 IME로 완전히 자리잡게 되었다. TSF 인터페이스를 이용해 bksp 달라붙기 같은 <날개셋> 고유 기능까지 그럭저럭 재연해 냈고, 심지어 윈도우 95부터 오늘날의 7까지 모든 운영체제를 지원하는 최적화까지 덤으로 구현했기 때문이다.

<날개셋> 한글 입력기는 이런 내력을 거쳐 지금과 같은 모듈들이 잘 개발되었다. 하지만 IME(외부 모듈)이 첫 개발되던 그 시절을 본인은 지금도 잊을 수 없으며, IME 모듈의 개발에 영향을 끼친 위의 두 프로그램들에도 나름 애착을 갖고 있다.

Posted by 사무엘

예전 글에서는 지하철 회사별로 전동차 차량 기지가 있는 곳을 열거한 적이 있는데, 이번에는 회사들의 본부가 있는 곳을 나열해 보겠다. 차량 기지와 회사 본사는 일반적으로 다른 개념이다. 그리고 요즘은 민자 철도가 많아져서 회사 나열하기도 좀 복잡해져 있다.

1. 코레일 (국철들..)

코레일은 잘 알다시피 전국의 거의 모든 철도를 관할하는 거대한 기업이며, 광역전철은 내부의 일개 사업 파트일 뿐이다. 그래서 코레일의 본부는 국토의 중앙으로서 상징성이 높은 대전에 있다. 코레일의 전신인 철도청은 원래 정부 대전 청사의 내부에 있었지만, 공사로 바뀐 뒤에는 이제 정부 부서가 아니기 때문에 거기서 나왔다. 대전 역 근처에 철도 시설 공단과 나란히 쌍둥이 사옥을 완공하여 거기에 입주했다.

코레일은 여기 말고도 지역별 관할 기관이 있다. 서울 본부는 서울 역 북부에 있으며, 사실 광역전철 사업 본부도 이곳에 자리잡아 있다. 이 외에도 수도권 동부 본부는 잘 알다시피 신이문 역 근처에 이문 차량 기지와 같이 입주해 있으며, 수도권 서부 본부는 영등포 역 근처에 있다. 끝으로, 철도 교통 관제 센터는 구로 차량 기지 내부에 있다.

2. 서울 메트로 (서울 지하철 1~4호선)

최초의 서울 지하철이 강북 종로선이고 2호선도 강북의 신설동-종합운동장 구간이 가장 먼저 개통한 만큼, 관할 회사의 본부가 강북 사대문 안의 어딘가에 있을 것 같기도 하다. 하지만 그렇지는 않다. 현재 서울 메트로 본사는 사당 역 근처에 있다. 강북은 아니어도 나름 중요한 환승역이 있는 지점이고, 한때 지하철 4호선의 남쪽 종점이기도 한 곳이다.

서울 메트로는 원래 이름이 서울 지하철 공사였고, 그 전신은 지하철 건설 본부로 거슬러 올라간다. 이때는 본부가 서울 시청 내부에 있었지만, 지금처럼 건설과 운영을 분리한 별도의 운영 회사는 1981년에야 생겼다. 지금의 사당동 사옥은 지하철 2호선이 건설되고 있던 1983년에 완공되었다.

3. 서울 도시철도 공사 (서울 지하철 5~8호선)

서울 2기 지하철 중 5호선은 1996년에 가장 먼저 전구간이 개통했다. 1994년에 먼저 설립된 도철은 본부가 천호대로 근처에 있으며, 그 5호선 답십리와 장한평 역의 중간에 있다. 거기는 5호선 중에서도 가장 먼저 개통한(1995년 가을) 구간인 왕십리-상일동의 구간에 속하기도 한다.

이곳 인근에는 차량 기지처럼 생긴 시설이 있는데 이건 재미있게도 도철이 아닌 서울 메트로 관할의 군자 차량 기지이다. 2호선 지선의 용답 역의 이름이 처음에는 ‘기지’ 역이었다.
2007~08년 사이에는 5호선 전동차가 답십리나 장한평 역에 도착할 때 “5 6 7 8 서울 도시철도는 답십리/장한평 역 n번 출구 근처에 있습니다” 비슷한 멘트를 잠시 들려 주기도 했다.

4. 서울9호선운영 주식회사 / 서울시메트로9호선 주식회사 (서울 지하철 9호선)

여타 철도/지하철 회사와는 달리, 서울 지하철 9호선을 운영하는 회사는 민간 기업이다. 게다가 회사가 하나가 아니라 둘이다.
먼저, '메트로'라는 단어가 없는 서울9호선운영 주식회사는 프랑스의 다국적 대기업인 베올리아의 자회사가 상당수의 지분을(80%) 출자하여 설립한 일종의 외국 자본 회사이며, 이 회사가 서울시메트로9호선 주식회사라는 국내 중소기업에다 또 위탁을 줘서 9호선 전동차를 굴리는 형태라고 생각하면 될 것 같다. 뭔가 복잡하다.
9호선 운영사의 본사는 서쪽 종점인 개화 역, 아니 개화 차량 기지와 일체로 존재한다. 차량 기지와 운영 본부를 일체로 만든 첫 사례이다.

5. 코레일 공항 철도

건설 당시에는 공항 철도의 명칭이 '인천'의 이니셜을 딴 IREX이다가 나중에 AREX로 바뀌고, 다시 정식 명칭이 '코레일 공항 철도'로 바뀌었다(코레일의 자회사). 공항 철도의 운영사는 영종도로 가기 직전에 본토의 마지막 역인 검암 역 근처에 본사가 있다. 2차 개통 후에는 열차가 검암 행과 인천 공항 행이 번갈아가며 운행되고 있으니 여기가 일종의 중간 회차 지점이기도 하다.

6. 신분당선 주식회사

신분당선은 서울 디자인 정책의 영향도 없고, 요금까지 독자적으로 걷고 있어서 민간 사철의 성격이 가장 강한 노선이다. 이곳 역시 사업 운영자는 외국계 네오트랜스라는 회사이고 사업 시행자는 신분당선 주식회사로, 서울 지하철 9호선과 비슷한 이중 형태로 운영되는 중이다.
신분당선은 신규 개통 구간으로서 상징성이 높은 판교 역 근처에 본사가 있다. 이곳에서는 신분당선을 한창 DX Line이라고 홍보하는 중이다.

그나저나 얘들은 아직 독립적인 차량 기지도 없어서 전동차가 코레일의 분당 차량 기지에 아직 세들어 사는 중임.

7. 인천 교통 공사 (인천 지하철)
지하철 회사에 메트로나 도시철도 공사가 아니라 교통 공사라는 명칭을 쓰는 도시는 현재 부산과 더불어 인천 이렇게 둘이 있다.
인천 지하철을 관할하는 이 회사는 간석오거리 역 근처에 있으며, 따라서 동암 역하고도 비교적 가까운 편이다.

8. 대전 도시철도 공사
갑천 역 근처에 본사가 있다. 의외로 대전 지하철 1차 개통 구간에서는 좀 떨어진 곳이다. 그냥 정부 대전 청사 일대에 있을 법도 한데 말이다.

9. 대구 도시철도 공사 (대구 지하철 1~2호선)
1호선 서쪽 외곽의 상인 역 근처에 본사가 있다. 앞으로 모노레일 형태로 도시철도(지하철은 이제 아니니;;) 3호선이 건설될 예정인데, 이 노선 또한 이 회사가 운영하게 된다.

10. 광주 도시철도 공사
상무 역 근처에 있다. 이 역은 지하철의 1차 개통 당시에 서쪽 종점이기도 했다.

11. 부산 교통 공사 (부산 지하철 1~4호선)
이름은 뭔가 범용적인 뉘앙스가 풍기는 '교통 공사'이지만, 이 회사는 여전히 지하철들만 관할하고 있다. 뭐, 이는 경전철인 4호선까지 포함한 것이고 그것만으로도 영역이 충분히 크긴 하지만 말이다. 1호선 범내골 역 근처에 본사가 있다.

12. 부산-김해 경전철 주식회사

부산-김해 경전철은 부산 지하철과는 격이 다르다. 신분당선이나 9호선과 같은 수준의 민영이다. 그래서 노인에 대해서 경로 승차권은 발급하지만 완전 무료는 아닌 독자적인 운임 체계도 쓰고 있다.
부산-김해경전철운영 주식회사와 부산-김해경전철 주식회사 이렇게 둘로 나뉘어 있는데, 운영 주식회사는 외국 자본 기반이 아니다. 70%의 지분을 다름아닌 '서울 메트로'가 가지고 있다.

본사는 서쪽 끝의 가야대 역에서도 더욱 외곽인 차량 기지 안에 같이 있다. 이 역시 9호선과 유사하다.

Posted by 사무엘

국가 원수가 사용하는 관용(官用) 교통수단 중 일부는 우리에게 잘 알려져서 친숙하다.

천조국인 미국은 Air Force One이라는 보잉 747 개조 비행기가 있는 걸로 유명하며 이걸 소재로 영화가 만들어진 적도 있다.
내 기억이 맞다면 2005년에 미국 부시 대통령 가족이 한국을 방문했을 때, 우리나라에서는 전투기까지 보내 에어 포스 원을 엄호하면서 서울 공항으로 안내를 해 줬다.

우리나라는 대통령 전용기가 없는 건 아니나, 덩치가 작고 한 번에 끽해야 동남아 정도까지밖에 못 간다고 한다. 그래서 대통령이 어디 멀리 나갈 일이 있을 때는 결국 대한 항공 여객기를 그때 그때 전세 내서 쓰고 있다고 본인은 들었다.

비행기 말고 자동차도 있다. 최고급 최고 성능 승용차인 건 말할 것도 없으며, 지뢰를 밟아서 터져도 내부 승객이 다치지 않을 정도로 튼튼한 장갑이 바닥에 장착되어 있다. 유리는 당연히 몇 겹으로 방탄 처리가 돼 있고, 차 내부에서는 밖이 보이지만 밖에서는 안이 보이지 않게 특수한 도장 처리가 되어 있다.
(그럼에도 불구하고 미국의 케네디 대통령은 그런 거 필요 없다며 서민적인 이미지 어필을 위해, 천장을 완전히 개방하고 신체를 노출한 채 차량 퍼레이드를 하다가, 어느 저격수의 총에 머리를 정통으로 맞고 세상을 떠났다.)

국가 원수가 이용하는 교통수단은 이런 하드웨어적인 보안 시설뿐만이 아니라 보안을 유지한 운영도 매우 중요하다.
동일한 차체를 둘 이상 보유하고 있는 건 필수. 둘의 스케줄을 서로 다르게 유지한다. 차량의 경우, 아예 동일한 차를 다섯 대씩 연달아 지나가게 하고 그 중 대통령은 완전 random한 차에 무작위로 탑승시키기도 한다.

실제로 일제 강점기 때, 우리나라의 모 독립 운동가 중에서도 이 테크닉 때문에 일제 요인의 암살에 실패한 사례가 있었다. 내 기억으로는 사이토 총독을 폭탄으로 암살하려다 실패한 강 우규 의사로 알고 있었는데, 자료를 다시 검색해 보니 내가 원하는 사건이 안 나온다. 정확히 누구인지는 잘 모르겠다.

아무튼, 이런 높으신 분이 탄 차는 세워서는 안 되고 끊임없이 움직이게 해야 한다는 게 중요하다. 그래야 안전하기 때문. 그래서 이런 관용차가 한번 납시면 당연한 말이지만 주변 도로를 다 틀어막고 관용차를 최우선순위로 통과시킨다.

비행기와 자동차까지 얘기가 나왔고 이제야 철도 차량 차례이다. 열차는 어떨까?
일단, 북한 뽀글이 아저씨가 중국 갈 때 맨날 열차를 애용했다는 게 잘 알려져 있는데, 그건 그냥 고소공포증이 있고 겁이 많아서일 뿐 그가 딱히 철덕이어서 그런 건 아니라는 것도 역시 잘 알려진 사실이다.

걔네들은 먼저 경호원의 열차가 지나간 후 2~30분쯤 뒤에야 김 정일이 탄 열차가 지나가고, 또 나중에 경호원의 열차가 또 지나가는 형태라고 한다. 열차 안은 미국의 에어 포스 원과 마찬가지로 어지간한 집무 환경이 다 갖춰져 있고, 요양/의료 시설도 있다.

철도는 역까지 가야 이용할 수 있고, 갈 수 있는 곳이 제한적이기 때문에 환승이 불가피하다. 국가 원수 정도 되는 인물이라면, 어지간하면 그냥 자동차나 비행기를 이용하는 게 훨씬 더 낫지 굳이 열차를 타야 할 필요는 없을 것이다. 청와대 밑으로 비밀 선로와 철도역이 놓여 있지 않은 한 말이다.

다만, 비행기를 띄울 수 없을 정도로 날씨가 너무 안 좋고 도로까지 마비된 상황이라면 열차도 좋은 고려 대상이 되겠다.
옛날에 6· 25가 터졌을 때 이 승만 대통령과 참모진은 열차를 타고 피난을 갔다. 그때는 고속도로도 없었고 포장 도로 자체가 거의 없던 시절이어서, 자동차로는 서울-대전만 해도 4시간~8시간씩 걸렸다. 그러니 그때는 철도가 가장 빠르고 편한 육상 교통수단이었다. 경부 고속도로가 완성되기 전까지는 박 정희 대통령도 관용 열차를 애용했었다.

이제야 이 글의 결론이 나온다.
대한민국에는 현재 대통령을 위한 관용 열차라는 게 있다. 그 열차의 이름은 ‘경복호’이다. 김 대중 정권 시절에 2001년에 한진 중공업(로템 통합 직전이었던 듯.)에 의뢰하여 만들어진 4량짜리 열차 2편성이 있다. 그때 막 남북한 철도 연결 떡밥이 나돌기도 했으니 말이다. 경의선 도라산 역이 개통했을 때 경복호가 김 대통령을 태우고 실제로 운행된 바 있다.

(사진 출처는 기억 안 남. 내가 찍은 건 당연히 아니고, 지금 인터넷에 나도는 저 포즈의 경복호 사진은 모두 동일 인물이 찍은 것임.)

경복호는 언뜻 보기에 전후동력형 새마을호 열차처럼 생겼다. 하지만 객차의 창문 모양을 보면 국내에 여객 열차로 존재한 적이 없는 형태임을 알 수 있다. 스펙에 대해서는 많은 것이 국가 기밀로 여겨지고는 있지만, 객차수가 적고 관용차 특유의 성능 튜닝을 한 덕분에, 기존 새마을호의 최고 속력이 140km/h인 반면 경복호는 선로가 좋은 곳에서 160km/h까지도 낸다고 알려져 있다.

철도 덕후라면 잘 알듯이 한국 철도 ‘로지스’ 사이트에서는 여객과 화물 공히 전국 모든 열차 운행 스케줄을 조회할 수 있다. 그래서 심지어 신규 개통 전철 노선으로 반입되고 있는 전동차까지 수송 경로를 추적해서 사진을 미리 찍는 철덕들까지 있다. 그럼에도 불구하고 경복호의 운행은 로지스에 당연히 뜨지 않는다. 이 열차의 스케줄은 코레일의 진짜 극소수 고위 간부만 알고 있다.

경복호는 통행 우선순위가 최상이며, 한번 떴다 하면 동일 운행 경로에 있는 열차들은 다들 깨갱+대피이다. 노 무현 대통령은 퇴임 후 고향 귀환을 KTX로 한 걸로 잘 알려져 있지만, 재임 중에 경남 지방으로 휴가도 경복호를 타고 몇 차례 떠난 적이 있었다고 한다. 그때 비슷한 구간을 달리던 여객 열차는 영문도 모른 채 괴열차를 먼저 기다렸다 보내 주느라 10~20분가량 지연을 먹어야 했다고 전해짐. 이때도 경복호 하나만 달랑 달린 게 아니라 선두와 후미에는 호송인 열차가 있었으며, 호송 열차 역시 겉모양은 PP형 새마을호이다.

어째, 경복호와 관련된 이야기는 보수 진영에서 좀 싫어하는 대통령들하고만 얽혀 있구나.
KTX만 해도, 대통령까지는 아니어도 1급 요원들이 몰래 타는 공간이 있는 KTX 모 편성 얘기가 철덕들 사이에서 나돌았는데, 아예 관용차가 있다는 얘기는 다소 생소할 것이다. 경복호는 코레일 직원들도 모르는 경우가 태반이다.

Posted by 사무엘

요즘 학교나 관공서의 전산망에서는 인터넷 접속을 위해서 특정 보안 솔루션 ActiveX들과 그것도 모자라서 바이러스 백신까지 무조건 설치하라고 강요하는 걸 볼 수 있다. 그걸 안 하면 사이트 접속이 되질 않게 해 놓았다.  허나 본인은 그런 보안 솔루션들에 대해 정서적으로 굉장한 반감을 갖고 있으며, 그것들을 몸서리치게 싫어한다.

여러 보안 솔루션 중 키보드 보안 프로그램이 하는 역할은 아마도 사용자의 키 입력(비밀번호 같은)을 메시지 훅킹으로 가로챌 수 없게 하고, 반대로 없는 키 입력을 소프트웨어적으로 생성할 수 없게 하는 일일 것이다(온라인 게임에서 오토의 실행 차단). 또한, 은행 돈거래 관련 정보가 담긴 패킷은 정보가 유출되더라도 의미 파악이나 변조가 거의 불가능하게 아주 복잡한 계산을 동원한 암호화/해독이 클라이언트에서 행해져야 할 필요가 있을 것이다. 그런 기술적인 필요를 본인은 모르는 건 아니다.

다만, 웹 표준만으로 도저히 구현할 수 없는 운영체제 커널 기술 수준의 보안이 불가피하게 필요하다면, 차라리 무리해서 웹 애플리케이션을 만드는 걸 포기하고 깨끗하게 로컬 환경에서 돌아가는 exe 형태의 프로그램과 배포 패키지를 만들었으면 좋겠다.

nProtect 부류의 이상한 프로그램들은 웹브라우저를 끈 뒤에도 계속 메모리 차지하면서 남아 있는 것 정도나 보기 싫은 수준이고 그나마 ‘낫다’. 하지만 이놈의 빌어먹을 백신은 답이 없다. 바이러스나 악성 코드에 걸리지 말라고 설치하는 솔루션들이, 깔고 나면 악성 코드나 그 이상 수준으로 민폐 끼치면서 컴퓨터 성능을 쪽쪽 갉아먹기 때문이다. 좀 심하게 표현하면 컴을 완전히 병신으로 만들어 놓는다.

마치 치안과 국방을 담당해야 할 자국의 정규군이나 경찰이 하라는 일은 안 하고 자기네들부터 민폐 끼치고 민간인들을 등쳐 먹는다거나, 반공을 빌미로 공권력이 심심하면 멀쩡한 생사람을 빨갱이로 몰아서 잡아 죽인다거나 하는 상황을 생각하면 되겠다.

맥북 이전 4대 노트북을 쓰던 시절의 일이다. 본인이 다니는 학교는 내부에서 와이파이로 인터넷에 접속할 때 NetCare인지 뭔지 하는 보안 ActiveX와 바이로봇 백신을 반드시 설치하도록 강요를 하고 있다. 둘 중 하나라도 설치를 안 하면, 몇몇 사이트는 아예 접속이 되지 않거나 쿠키가 저장되지 않아서 로그인을 할 수가 없으며, 되는 사이트도 보안 솔루션들을 설치하라고 협박하는 문구가 든 프레임이 웹사이트에 제멋대로 추가되어 나오곤 했다.

그래서 본인은 어쩔 수 없이, 울며 겨자 먹기로 마지못해 깔라는 것들을 다 설치해 줬다. 그러자 저런 성가신 현상이 모두 없어지고 인터넷은 잘 되기 시작했다. 그러나 그 뒤부터 내 컴에서는 끔찍한 헬게이트가 시작되었다.

부팅 직후에 시스템이 시작 메뉴 구동 같은 각종 조작에 응답하는 속도가 눈에 띄게 느려졌고, 웹브라우저가 페이지를 여는 속도, 전반적인 파일 액세스 속도도 인내심의 한계를 느끼는 수준이 되었다. 최대 절전 모드에서 복귀하는 시간까지 예전보다 훨씬 더 길어졌다. 멀쩡하던 컴퓨터가 진짜 만신창이 장애인이 된 느낌이었다. 평상시에 운영체제의 메모리 사용량도 예전보다 수십 MB가량 늘었다.

나는 운영체제의 업데이트들은 목록만 자동으로 받게 한 뒤, 다운로드와 설치는 내가 지정한 것만 수동으로 하게 해 놓고 있었다. 그랬는데 그 보안 솔루션은 나의 설정을 씹고, 인터넷만 됐다 하면 마구잡이로 온갖 업데이트들을 제멋대로 받아서 설치했다.

언제부턴가 MS 오피스가 SP2이던 게 느닷없이 SP3으로 바뀌어 있었다. 프로그램이 버전업되어서 좋은 게 아니라 도리어 부아가 치밀었다. “이 자식, 지금까지 왜 이리 느리고 쓸데없이 디스크 액세스를 하는가 했더니, 그 수백 MB짜리 업데이트를 내 동의도 없이 제멋대로 설치하느라 그랬군.” 하는 생각에 말이다.

참다못해 하루는 넷케어고 백신이고 전부 다 모조리 지워 버렸다. 요즘은 백신도 용량이 몇백 MB 수준으로 뭘 하느라 그리도 커졌는지 모르겠다. 이것들을 다 지우고 나자 내 컴퓨터는 거짓말처럼 평화가 찾아왔다. 모든 성능이 예전 상태로 돌아갔다. 보안 솔루션들이 그들의 퇴치 대상인 악성 코드가 하는 짓을 동일하게 하고 있음이 입증된 순간이었다.

이제 맥북을 사용하면서 뜻하지 않게 얻은 큰 수확이 있다. 보안 솔루션 제약은 Windows 운영체제에만 적용되며, 맥에서는 그런 게 전혀 없이도 인터넷을 곧바로 자유롭게 이용할 수 있다는 것. 야호! 빌어먹을 넷케어니 바이로봇 따위를 설치하지 않아도 된다. 맥OS가 날 구했다. 스잡빠니 애플빠니 난 그딴 건 모르지만, 어쨌든 이거 덕분에 맥OS 호감도가 급상승했다.

한편, 고향에서도 비슷한 일을 최근에 겪었다. 고향집 컴퓨터가 언제부턴가 병신 중의 상병신이 돼 있었다. 부팅 후에 시작 메뉴를 눌러도 한참 동안 반응이 없고, 웹브라우저를 띄운 뒤에 창이 나타나기까지 몇 분이 족히 걸리고 있었다. 레지스트리나 파일 디렉터리를 살펴봐도 딱히 악성 코드에 걸린 것 같지는 않은데 영문을 모를 노릇이었다.

이 현상의 주범은 바로 V3 Lite였다. 이놈을 당장 지우자 컴퓨터는 운영체제를 갓 설치한 직후처럼 아주 쌩쌩해졌다! 그러니 난 도대체 진짜 악성 코드란 어떤 놈인지 가치관의 혼란을 겪을 수밖에 없었다.

바이러스가 묻은 메일 첨부 파일을 클릭한 것도 아니고, 이상한 사이트를 돌아다니다가 ActiveX 설치에 ‘예’를 누른 것도 아니었다. 이 V3은 어머니께서 집에서 인터넷으로 업무를 보시기 위해 어쩔 수 없이 설치한 것이었다. 이거랑 무슨 희한한 듣보잡 ActiveX들을 설치하지 않으면 직장의 업무 자동화 시스템에 접속이 되질 않기 때문이었다.

이런 일련의 사건을 겪은 뒤, 나는 더욱 더 백신 따위는 죽어도 절대로 쓰지 말아야겠다는 생각을 굳게 하게 되었다. 옛날처럼 백신이 그냥 사용자가 요청할 때만 파일이나 메모리를 스캔하면서 바이러스 검사를 해 주던 시절이 그립다. 저런 거지 같은 잉여 쓰레기 프로그램을 얹고도 작업을 원활하게 하려면, 가히 정말 최신식 최고급 컴퓨터를 써야겠다. 아니, 내 컴퓨터가 아무리 빠르고 메모리가 썩어 넘친다 해도 저런 프로그램에게 컴퓨터 자원을 내어 주기는 싫다.

보안을 빌미로 원치 않는 프로그램의 설치를 강요하는 이런 못돼먹은 풍조가 좀 없어졌으면 하는 바람이 있다. 이런 일이 계속될수록 이에 대한 반발 심리로 나의 컴퓨터 보안 위협 불감증은 더욱 커질 것이다.

Posted by 사무엘