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

자동차가 다니는 도로 중에는 일반 시가지의 도로와는 달리, 진출입로를 입체화하여 신호 대기를 없애고 보행자는 물론 이륜차도 접근할 수 없게 한 ‘자동차 전용’ 도로가 있다. 이런 도로는 최고 속도 제한뿐만 아니라 최저 속도 제한까지 있어 많은 자동차가 원활하게 통과하도록 하고 있다.

한편, 도시와 도시를 이으며 해당 지역이 아닌 중앙 정부에서 노선을 직접 고시하여 관리하는 도로를 ‘국도’라고 부른다. 국도는 이미 번호로 매겨져 있어서 가령 1번 국도는 서울, 안양, 평택 등 처음엔 경부선 철도와 비슷한 길을 가다가 목포로 가며, 4번 국도는 경주 감포에서 출발하여 대전까지 경부선과 비슷한 방향을 향하다가 당진에서 끝난다. 국도라는 용어에는 시설이라는 개념은 그다지 들어있지 않기 때문에, 심지어 비포장 아니면 2차선 도로일 수도 있고 최근에 리모델링된 국도 구간은 미국 프리웨이급의 8차선의 고가 도로일 수도 있다. 원래 국도의 노선은 북한 지역까지 다 포함하고 있다.

이 글에서 다루고자 하는 한국의 고속도로는 자동차 전용 도로의 성격에 가깝지만 행정상으로는 ‘고속 국도’이다. 즉 국도이지만 통행료를 받는 유료 도로이고 시설이 일반 국도보다 훨씬 더 좋다. (88올림픽 고속도로는 예외이지만.)
사실 이런 고속도로와 개념적으로 정확하게 100% 대응하는 말이 영어에는 존재하지 않는다. 미국에는 한국의 경부 고속도로급의 넓고 잘 뻗은 길이 경부-경인 축이나 수도권에만 있는 게 아니라 미국 전역에 구축되어 있다. 하지만 한국과 같은 유료 도로는 아니다.

고속도로가 많지 않던 시절에는 매 도로마다 이름이 붙어 있었지만 요즘은 고속도로가 워낙 거미줄처럼 많이 놓이고 구조가 복잡해지면서, 우리나라도 고속도로의 이름을 없애고 일반 국도처럼 번호만으로 부르려고 시도하고 있다. (한국의 고속도로로서 상징적인 의미가 매우 큰 경부 고속도로는 당당히 1번이다.)
하지만 국민 정서상 그게 금방 정착할 것 같지는 않다. 주변에는 여전히 경부, 중부내륙, 영동 같은 명칭이 친숙하다.

이 한국의 고속도로는 유료 도로이다 보니 통행료를 징수하는 톨게이트가 존재한다. 마치 지하철 역 내부가 승차권 개집표기 전후로 분리되어 있고, 공항 내부가 탑승권 소지자만 들어가는 구역으로 분리되어 있는 것처럼 고속도로 구간을 분리하는 역할을 톨게이트가 하는 셈이다. 톨게이트는 차량의 소통을 크게 방해하기 때문에 이 오버헤드를 줄이고자 요즘은 하이패스 같은 기술이 등장하기도 했다.

톨게이트는 고속도로가 시작하는 양 종점에 있고 또 각 지역 인터체인지 말단에도 있다. 그래서 자동차는 톨게이트를 통과하여 고속도로에 진입한 후 톨게이트를 통과하여 고속도로에서 벗어나게 된다. 여기까지는 이해하는 데 아무 어려움이 없을 것이다.

그런데 경인이나 외곽 순환 같은 수도권 고속도로에서는 얘기가 좀 달라진다. 여기서는 단순히 장거리 여행이 아니라 매일 출퇴근을 고속도로로 하는 사람도 굉장히 많다. 진출입로인 인터체인지도 훨씬 더 조밀하게 많이 있다. 마치 일반 철도역 간격으로 있던 역이 (광역)전철역 간격으로 바뀌는 것과 정확히 같다. 여기에 일일이 다 톨게이트를 설치하고 수많은 차들을 세우는 것은 현실적으로 무리이다.

그렇기 때문에 이 두 고속도로는 다른 방법으로 통행료를 징수하고 있다.
일단 고속도로에 진입 자체는 톨게이트 없이 마음대로 한다. 하지만 도로 중간중간에 톨게이트가 있다. 외곽 순환의 경우 전구간을 통틀어 6개의 톨게이트가 있으며 경인 고속도로는 도로 중앙에 톨게이트가 하나 있다. 물론 통행료도 일반적인 거리 비례제가 아니라 고정된 요금을 매우 조금만 징수한다. 또한 톨게이트를 통과하지 않는 구간만 이용할 때는 통행료를 낼 필요가 없다.

따라서 경기도 남부에서 수평축의 외곽 순환 고속도로와 만나는 수직축의 서해안/경부/중부 고속도로들은, 외곽 순환 고속도로와 만나기 전에 이미 전통적인 방식의 요금 정산과 징수를 끝내야 한다. 그래서 제각기 서서울/서울/동서울 톨게이트는 안산, 성남 같은 꽤 남쪽에 자리잡고 있다.

철도뿐만 아니라 도로도 수도권과 비수도권이 상이한 교통 수요에 따른 상이한 운영 방식을 유지하고 있다는 것을 알 수 있다.

참고로, 철도는 서울을 기점으로 보지만 도로는 남북 통일과 대륙 진출을 염두에 두고 남쪽을 기점으로 보고 있다는 것이 흥미로울 것이다. 즉 경부 고속도로의 기점을 서울이 아닌 부산으로 본다는 것이다.

Posted by 사무엘

class CAppFrame: public CWnd {
public:
        void PostNcDestroy() { delete this; }
};

class CMyApp: public CWinApp {
public:
        BOOL InitInstance();
};

CMyApp g_App;

BOOL CMyApp::InitInstance()
{
        m_pMainWnd=new CAppFrame;
        m_pMainWnd->CreateEx(0, AfxRegisterWndClass(0), _T("Hello World"), WS_OVERLAPPEDWINDOW,
                100, 100, 500, 500, NULL, NULL);
        m_pMainWnd->ShowWindow(SW_SHOW);
        m_pMainWnd->UpdateWindow();
        return TRUE;
}

위의 코드는 MFC를 써서 만들 수 있는 가장 간단한 GUI 프로그램이다. 빈 창만 달랑 뜨는 게 허전하면, message map 넣고 OnPaint에다가 Hello, world! 출력하는 코드만 추가해 주면 된다.
MFC로 창을 띄우기 위해서는 본질적인 것 딱 두 가지만 기억하면 된다.

첫째, CWnd에서 상속 받은 클래스를 만들기

둘째, CWinApp에서 상속 하나 받아서 전역 개체를 하나 반드시 만들고, InitInstance를 오버라이드하여 내 윈도우 클래스를 생성하는 코드를 짜 주기

물론 요즘은 닷넷 프레임워크 같은 더 객체 지향적이고 깔끔한 API도 나와는 있지만 저 정도만 해도 그냥 C언어 + Win32 API만 썼을 때와는 비교할 수도 없이 간단하게 내가 원하는 일을 곧장 시작할 수 있다. 윈도우 클래스 등록, 윈도우 프로시저 등 온갖 지저분한 내부 처리를 상당 부분 MFC가 알아서 해 주기 때문이다.

MFC의 핵심부이며 가장 자주 다루게 되는 부분은 역시 윈도우를 나타내는 CWnd 관련 개체이다. 응용 프로그램의 메인 윈도우부터 시작해서 대화상자와 대화상자 안의 자그마한 컨트롤까지 매우 다양한 용도로 쓰이는 HWND를 한 뿌리 클래스와 상속 클래스만으로 원활히 제어하기 위해 MFC는 굉장히 심도 있게 설계되었으며 내부적으로 자질구레한 일들을 매우 많이 해 주고 있다. 단순히 ShowWindow(hWnd, SW_SHOW)를 wnd.ShowWindow(SW_SHOW)로 바꿔 주는 것을 훨씬 넘어서는 수준이다.

더구나 메시지 맵을 통해 컨트롤 서브클래싱(기존 윈도우 컨트롤의 동작을 부분적으로 조작하는 것)까지 매끄럽게 연결시킨 것까지 보면, 솔직히 굉장히 잘 만든 프레임워크임을 인정하지 않을 수 없다.

이런 프레임워크를 만들 때 근본적으로 문제가 되는 것은 CWnd라는 C++ 오브젝트와 운영체제의 HWND 사이의 씽크를 맞춰 주는 작업이다. 둘은 원래 개념적으로 생성 주기나 scope이 서로 완전히 다른 존재이다. 하지만 MFC는 한 HWND를 가리키는 CWnd 오브젝트가 중첩되지 않도록 배려하고 있으며, 나의 C++ 코드에 의해 생성되지 않은 외부 HWND에 대해서도 임시 맵까지 만들어 가면서 CWnd를 동기화해 주고 있다. 멀티스레드 환경까지 감안하면 이는 더욱 복잡한 작업이 된다.

new 연산자로 CWnd가 생성될 때 CreateWindow를 같이 해 주고, HWND가 완전히 소멸되어 WM_NCDESTROY가 왔을 때 CWnd까지 delete로 지워 주는 것은 대부분의 경우엔 바람직한 디자인 패턴이나, 이것이 언제나 유용한 것은 아니다. 가령 modal 대화상자는 자체적으로 message loop까지 갖추고 있기 때문에 heap이 아닌 스택에다가 간단히 지역변수로 선언하는 경우가 더 유용하기 때문이다. 더구나 대화상자는 사용자가 대화상자를 닫았더라도, 이 C++ 클래스 갖고 있는 데이터 변수들을 후에 활용하는 경우가 많기 때문에 HWND 개체가 사라진 뒤라도 C++ 개체는 남아 있어 줘야 한다.

이래저래 CWnd와 HWND 사이의 관계와 생성/소멸 주기는 여러 모로 이해하기 까다롭다. CWnd 클래스 중에서 new로 생성되고 HWND의 소멸과 동시에 소멸되어야 하는 오브젝트라면, PostNcDestroy 함수를 오버라이드하여 delete this를 넣어 주어야 메모리 누수가 발생하지 않는다. 응용 프로그램의 주 프레임 윈도우라든가 modeless 대화상자가 이런 예에 속한다.

저 소스 코드에서는 CWnd를 날것으로 사용했지만, CWnd에서 파생되어 아예 전문적으로 응용 프로그램의 주 프레임 윈도우를 담당하고 있는 MFC 클래스인 CFrameWnd는 PostNcDestroy가 이미 저렇게 구현되어 있다. 그뿐만 아니라 이 클래스는 LoadFrame 함수에서 이미 윈도우 클래스의 등록까지 다 알아서 해 주기 때문에 저 소스 코드에서처럼 AfxRegisterWndClass를 번거롭게 호출할 필요도 없다. 사용자가 준 ID와 일치하는 응용 프로그램 타이틀, 아이콘, 심지어 단축키 액셀러레이터 테이블 따위를 모두 엮어서 윈도우의 기반을 자동으로 구성해 주기 때문이다.

MFC를 써서 아주 간단한 프로그램을 짜고 싶은데 비주얼 C++의 MFC 마법사가 기본으로 생성해 주는 코드는 군더더기가 너무 많다. 그래서 이럴 때 본인은 MFC 없이 일반 Win32 응용 프로그램으로 프로젝트를 시작한 후, 저 코드 템플릿을 갖다 붙이고 프로젝트 세팅을 “MFC 사용”으로 수동으로 바꾸는 방법을 쓴다.

필요한 건 MFC가 잘 캡슐화해 준 message loop, 몇몇 GDI 오브젝트 같은 것밖에 없는데 이것만 쓰기에는 MFC는 덩치가 너무 커지고 static link를 하기에도 오버헤드가 너무 큰 것도 불만이다. 차라리 known DLL만 쓰기 때문에 매우 가벼운 바이너리를 만들 수 있는 비주얼 C++ 6.0이 그리울 때도 있다. 어차피 이후 버전에서 추가된 기능은 거의 안 쓰기 때문에.

<날개셋> 타자연습은 소스를 보면 알겠지만 딱 MFC를 써서 개발되었다. 하지만 한글 입력기는 3.0부터 MFC를 쓰지 않으며, 믿거나 말거나 MFC를 어설프게 흉내 내어 본인이 내부적으로 자체 개발한 프레임워크 라이브러리를 static link하여 개발해 오고 있다. 하지만 자체 라이브러리는 오버헤드 줄이고 최대한 가볍게 만드느라, Win32 API라든가 각종 핸들을 캡슐화한 수준이 MFC 수준으로 범용적이고 체계적이고 편하지는 못하기 때문에, 여전히 MFC가 그리울 때가 있다. ^^;;

Posted by 사무엘

밝은 초록색 선은 정석적인 원그리기 알고리즘으로 그린 진짜 원.
파란색 선은 제어점이 2개인 3차 베지어 곡선 하나로 사분원을 흉내낸 것,
그리고 빨간색 선은 제어점이 하나인 2차 베지어 곡선 두 개로 사분원을 흉내낸 것입니다.

베지어 곡선으로 원을 수학적으로 100% 정확하게 기술할 수는 없습니다.
단지 제어점을 잘 배치해서 원과 굉장히 비슷하게 생긴 곡선만을 그릴 수 있을 뿐입니다.

그래도 곡선이 그려진 곳에 초록색 점을 거의 찾을 수 없는 걸 알 수 있는데요, 3차 베지어 곡선(파란)만 해도 원하고 실용적으로 아무 차이가 없을 정도로 잘 근사해 냅니다.

빨간 선인 2차 베지어 곡선도 파란 선(≒ 원)과 상당히 일치하긴 하지만 그래도 파란 선이 초록 선과 일치하는 것만치 일치하지는 못합니다. 미묘하게 서로 살짝 어긋나는 오차가 보이죠?
(2차 곡선 여러 개를 모아도 3차 곡선을 근사만 할 수 있을 뿐 정확하게 일치시킬 수는 없습니다.)

컴퓨터의 벡터 드로잉에서 쓰이는 곡선들은 다 베지어 곡선(또는 이와 수학적으로 동일한 형태로 변형할 수 있는 다른 스플라인)입니다.
특히 트루타입 폰트가 쓰는 곡선은 2차 베지어 곡선이기 때문에 이렇게 빨간 선을 표현하는 방식과 동일한 방식으로 O, 이응, ● 같은 글자가 표현된다고 생각하시면 정확합니다.

Posted by 사무엘

예전에도 글로 쓴 적이 있지만, 16비트 윈도우 바이너리(exe/dll), 소위 NE 파일의 형태는 보면 볼수록 참 이상야릇하다고 느껴져서 흥미가 갑니다.

MZ로 시작하는 도스 EXE는 구조가 사실 매우 간단합니다. 맨 처음 32바이트 남짓한 구조체에다 몇몇 오프셋, 사이즈, 레지스터 초기값 따위를 넣고 재배치 정보(optional)만 넣어 주고 나면 그 뒤부터는 공통분모라는 게 없이 전적으로 프로그래머/컴파일러 재량입니다. COM은 아예 헤더란 것이 없고 곧장 코드+데이터가 등장하는 형태이니 초간단 패치 내지 램 상주 유틸리티, 혹은 심지어 바이러스를 만들 때 이보다 더 좋은 수단이 없었습니다.

하지만 좀더 복잡한 운영체제는 바이너리 파일에도 더 정교한 체계대로 구간별 역할을 딱딱 나누고 있습니다.
가령, EXE 뒤에다가 별도의 내장 데이터를 덧붙이는 것은 도스 시절에는 전적으로 컴파일러/링커 내지 해당 기능을 수동으로 제공하는 라이브러리의 재량이었습니다. 가령 볼랜드 컴파일러로 *.bgi 드라이버나 글꼴을 *.obj로 바꿔서 embed시키는 것은 운영체제보다 훨씬 더 상위 계층에서 행해지는 일이었죠.
하지만 윈도우에서는 운영체제 차원에서 바이너리 파일 안에 리소스라는 데이터 영역을 별도로 구분하여 관리해 주며, 이를 불러오는 API도 운영체제 차원에서 제공됩니다.

16비트 중에서도 윈도우 1.x(무려 1985년에 나온 바로 그것!), 2.x, 3.x의 포맷이 모두 서로 살짝 다르다고 하는데, 2.x 이상 바이너리는 오늘날 윈도우 운영체제의 NTVDM 하에서도 바로 실행 가능하다고 들었습니다. (9x 계열에서는 말할 나위도 없음.) 하지만 1.x도 리소스 데이터를 좀 변환하고 버전 플래그 같은 몇몇 값만 수정하면 곧장 실행할 수 있다고 하더군요. 윈도우가 하위 호환성을 상당히 잘 지키면서 버전업되어 왔다는 얘기가 되겠습니다.

0x3C 오프셋에 도스 바이너리가 아닌 실제 바이너리가 시작되는 위치가 기록되어 있다는 것은 NE(16비트 윈도우 바이너리), PE(오늘날의 32/64비트 바이너리) 모두 공통입니다. NE에도 PE와 마찬가지로 최소 운영체제 버전과 자신을 빌드한 링커의 버전이 헤더에 명시되어 있습니다.

윈도우 3.x 바이너리들은 대개 링커 버전이 5~6 정도로 잡혀 있던데 이건 비주얼 C++ 버전이 아니라 그 전신인 MS C 버전 기준이라고 보는 게 타당하겠습니다. 비주얼 C++ 1.5x는 MSC_VER의 값이 600밖에 안 되거든요. 그 반면 요즘 비주얼 C++ 200x는 이미 무려 1300~1500대까지 올라갔죠.

최소 운영체제 버전은 물론 3.10으로 잡으면 윈도우 3.1에서 실행 가능합니다. 하지만 이 수치를 더 높게 4.0으로 잡으면 “윈도우 3.1에서 실행되지 않는 16비트 윈도우 바이너리”를 만들 수 있습니다.

그런 예가 무엇이 있냐 하면 바로 윈도우 9x 이후에 제공되는 SysEdit.exe입니다. 이 프로그램은 16비트 EXE이지만 정작 윈도우 3.1에서는 실행이 안 됩니다. 하지만 윈도우 9x에서 실행하면 비록 16비트 EXE이지만 대화상자의 배경을 다른 32비트 프로그램들처럼 회색 입체 효과로 입혀 주며 16비트 프로그램과 호환되지 않는 일부 신규 메시지/API를 32비트 프로그램과 같은 스타일로 날려 줍니다. Win32s도 아니고 참 난감한 케이스이죠? 윈도우 9x가 나오던 당시, MS에서 내부적으로 기존 16비트 프로그램들의 외형 껍데기의 이질감을 줄이려고 넣은 꽁수에 가깝다고 보면 되겠습니다.

요즘은 파일 포맷을 설계할 때 최대한 확장성을 고려하여 chunk 테이블부터 넣는 게 일반적입니다. MIDI(음악), TTF(글꼴), PNG(그래픽)들이 다 그렇죠. PE도 마찬가지여서 text, data, reloc, rsrc 같은 청크 식별자가 존재합니다. 하지만 NE는 나중에 등장한 PE와는 달리 그런 구분은 존재하지 않으며 헤더, 세그먼트 테이블, 리소스 테이블, 이름 테이블 등 미리 정해진 정보가 순차적으로 쭉~ 등장하는 형태입니다.

kernel, user, gdi처럼 내가 참조하여 import하는 다른 모듈의 API에 대한 정보는 있지만 PE처럼 함수명이 그대로 기록되어 있지는 않고 그냥 서열 번호만 들어가는 것 같습니다. 또한 윈도우 1.x가 맨 처음에 파스칼로 개발되어서 그 영향을 받아서인지, export하는 심볼 이름들은 다 대문자로만 적혀 있고 대소문자 구분은 딱히 안 하는 걸로 보입니다. 물론 윈도우 내부 API가 SDK 형태로 최초로 정식 공개된 3.0 시절에는 이미 다 C언어 기반으로 바뀌었지만.

끝으로, NE에는 PE에 전혀 없는 개념인 name table이라는 게 있습니다. 프로젝트 빌드할 때 *.DEF 파일로부터 링커가 생성해 주는 테이블일 겁니다.
그것도 resident name, non-resident name이라 하여 언제나 메모리에 상주하는 것, 아니면 언제나 상주시키지 않기는 때문에(메모리 아끼기 위해) 불러오는 데 시간이 좀 걸릴 수도 있는 것으로 종류도 나뉘어 있습니다. 둘 다 자신이 export하는 함수들의 명칭 같은데 정확한 용도가 무엇인지, 그리고 또 왜 이런 식으로 분류를 했는지는 알 길이 없습니다. 인터넷으로도 이런 게 있다는 식으로 기계적으로 설명해 놓은 자료만 있지, NE 포맷을 왜 이런 식으로 만들 수밖에 없었는지 같은 친절한 설명은 정말 찾을 수 없더군요.

또한 이 테이블에는 꼭 export symbol만 들어가는 게 아니라, non-resident name의 1순위로는 이 프로그램의 full name도 같이 들어갑니다. 즉, 버전 리소스를 굳이 안 뒤져도 여기를 찾아봐도 “Microsoft Visual C++”, “FontMania” 같은 정보를 얻을 수 있다는 것이죠. 오늘날 쓰이는 PE에는 이런 정보가 없습니다.

윈도우 3.1의 기본 프로그램인 문서 작성기, 페인트 등의 EXE를 들여다보면 마치 DLL처럼 프로그램의 내부 함수로 추정되는 명칭(특히 윈도우/대화상자 프로시저)을 상당수 non-resident name table에다가 export해 놓은 것을 알 수 있습니다. PageInfoWndProc, DialogGoto, BroadcastChildEnum 등. 왜 이렇게 해 놓은지는 저는 16비트 윈도우 개발 경험이 없으니 알 길이 없습니다. 메모리가 캐 부족하던 시절에 아마 한 번 만들어 놓은 코드는 EXE, DLL을 불문하고 최대한 많이 재사용하려고 이렇게 한 게 아닌가 싶습니다.

그나마 resident name table은 거의 쓰지도 않는 거 같던데 왜 만들었는지도 모르겠고.. 수수께끼이군요. 참고로 32비트 시대로 와서는 리소스 같은 건 free 한다는 개념 자체가 없어졌습니다. 당연히 resident, non-resident 같은 구분도 전혀 필요 없죠.

대략 이렇게 NE 포맷에 대해서 살펴봤는데, PE까지 그대로 이어지고 있는 개념도 있는 반면 어떤 것은 완전히 다른 것도 존재한다는 걸 알 수 있었습니다. 역시 16비트와 32비트 사이에는 넘사벽 같은 gap이 있는 듯이 보입니다.

Posted by 사무엘

오랜만에 플게에 이런 이슈가 나와서 우리말 쪽으로도 글을 써 본다.

1. 서로, 스스로를 부사가 아닌 명사로 쓰는 것은 잘못됐다.
OK. 공감함.
  서로가 서로를 배려해야 한다. (X)
  각자(우리)가 상대를 배려해야 한다. (O)

  네 스스로에게 문제가 있다. (X)
  너 자신에게 문제가 있다. (O)
O 같은 어휘를 생각해 내기가 귀찮아서 X로 단순화하고 있는 것 같다.

하지만 '모두'까지 부사로만 써야 하고 명사형이 잘못됐다는 것은 현실성이 없다.
모두를 안 쓰면 전부, 전체 같은 한자어가 대신 들어갈 수밖에 없음.

2. 그녀라는 말을 쓰지 말아야 한다.
응, 충분히 취지를 이해하며 가능한 한 다른 걸로 표현을 바꿔 쓰고 싶은데 전혀 안 쓸 수가 있나?
특히 성경 번역 같은 거 할 때.. 한국어에 she 같은 개념 자체가 없었고 이제는 필요해졌는데 어떡하라고?

3. '-에 있어서'란 말을 쓰지 말아야 한다.
OK. 정말 장황한 군더더기이고 '더 이상'만큼이나 안 쓰고 지냄.

4. 역할, 입장, 불구하고(despite, in spite of) 같은 말도 쓰지 말아야 한다.
글쎄. 한동안 구실, 관점, though 같은 다른 표현도 써 봤지만 전자는 후자하고 의미가 다른 면모가 있다.
완전히 안 쓸 수는 없을 것 같으며, 특히 이런 문제와 관련하여 본인의 고민은 도대체 일본과 한국이 공용하는 한자어들 중 어떤 건 괜찮고 어떤 건 써서는 안 되는지 판단하는 그 잣대가 불분명하다는 것이다. 이건 판단 보류.

5. 애매하다와 모호하다를 구분해야 한다.
OK. 좋은 지적.
  공연히 애매한 사람을 들볶다..
  의미가 너무 모호(한자어)하고 막연하다.

6. '의'자 붙이는 거 자제해야 한다.
가능한 한 지키려고 노력하지만, 싸그리 몰아낼 수는 없다.
'의'자 안 붙이고 링컨 대통령의 "국민의, 국민에 의한, 국민을 위한 정치"를 번역할 수는 없는 노릇이 아닌가.
한국어는 이런 점에서 표현력이 무척 떨어지는 면모가 있다.
'A의 평면 B로의 정사영'... 영락없는 영어/일본어 번역투인 것은 알지만 도대체 이보다 더 간편하게 어떻게 번역할 수 있겠는가?

7. '보다'를 주의해서 써야 한다.
  보다 나은 미래 (X)
  네가 나보다 낫다 (O)
OK. X는 영 어색하고 기초적인 우리말 문법 관념도 없이 생겨난 표현임을 인정한다. '(좀)더'만 써도 충분하죠.

8. 했었다 같은 이중 과거
순화 운동가들이 보면 펄쩍 뛰고 노발대발할 말투인데..
원래 한국어에는 없던 시제 표현을 확장해서 받아들인 거라고 볼 수 있지 않을까? "간 적이 있다"를 줄여서 "갔었다"라고.. 굳이 배척할 필요는 없다고 느낀다.

9. '가지다' 남발
OK. 한국어의 정서와 명백하게 이질적인 own, have 직역투는 자제염..;;
쓰기 전에 한번 생각을 해 보고 쓰자.
임신하면 아이를 배는 거지 아이를 갖는 게 아니다.
행사를 가지는 건 너무 심했잖아!

이것 말고 또 무슨 예가 있을까?
본인은 고등학교 시절에 이 오덕 선생, 대학교 시절에 이 수열 선생님의 우리말 순화 책을 섭렵한 경험이 있다.
100% 공감하지는 못하는 사항도 있지만 어쨌든 우리말의 실태에 대해 많은 생각을 일깨워 준 좋은 내용이었다.

스스로 판단하기에 OK라고 결론을 내린 사항들은 나름대로 이 홈페이지 열 무렵부터 그대로 지켜 왔다.
지금은 한말글 정신이 투철하던 2001~02 시절에 비해서는 많이 타-_-락해서 본인 쓰는 글에 한자어, 영단어도 예전보다 많이 들어간 편이지만, 그래도 감각 자체를 잃어버린 건 아니다.

나의 원칙은 간단하며 실용성을 지향한다.

- 한국어가 의미가 잘 구분되고 문법에 원칙이 있는 언어가 되는 방향으로: 다르다/틀리다는 반드시 구분해서 써야 한다. '더 이상' 같은 말을 쓰지 말아야 한다.
- 청각적으로 구분이 잘 되는 방향으로: 그래서 한글 전용 지지이다.
- 그리고 가능하면 짧고 간결하게
- 그리고 가능하면 토박이말에 우선순위: 어설픈 외래어 순화보다, 이미 있던 순우리말부터 먼저 퍼뜨리고 써야 한다.

4번을 제외하고 위의 세 가지 대원칙에 역행하지 않는다면 외래어나 번역투도 다른 우리말 순화 운동가들에 "비해서는" 그렇게 배척하지 않는다.
우리말이 영어처럼 수동태가 발달해 있지 않고 자주 쓰이지 않는 것은 사실이나 우리말에 수동태에 해당하는 표현이 없어서 좋을 것도 없는 건 사실이지 않은가.

물론, 번역투 때문에 말이 장황하고 거추장스러워지는 것은 분명히 경계한다. 또한 외래어나 외래 문체가 전혀 필요하지 않고 이미 멀쩡히 잘 쓰이던 우리말 표현까지 왜곡되고 파괴되는 것 역시 막아야 할 것이다.

우리말과 글 쪽의 홍보/계몽은 이렇듯 분명한 원칙과 체계를 갖추고 추진해야 쓸데없는 논쟁과 반감에 휩싸이지 않는다.

그리고 "비판을 하려면 수긍할만 한 대안을 제시하라." 주의이다.
그런 거 없이 무조건 뭐 일본식 한자어니까, 번역투란 이유만으로 쓰지 말자는 주장은 그냥 가능한 한 기피하는 고려 수준은 될 수 있어도, 적극적으로 안 쓰지는 않는다.

내가 또 하나 주장을 하는 걸로 글을 맺겠다. 나름대로 이 바닥에 짬밥도 있기 때문에 응용하는 것이다.

※ '기존'은 '예전'이 아니다. 제발 똑바로 쓰자.

- 현존, 실존 이런 단어하고 똑같은 용법으로 써야 하는 말이다.
- "기존에 있던 것들은 다 지워라" 이런 말... 정말 한숨만 나온다. "기존하는 것들은" 아니면 "예전의 것들은"이라고 쓰는 게 낫다.

Posted by 사무엘

요세미티 국립 공원과, 샌프란시스코 일대의 관광 사진부터 먼저..

(1)

모레 아침이면 벌써 귀국이다. ㅠㅠ (여기는 지금 금요일 저녁)
내일은 멀리는 안 나가고 쉬면서 선물 쇼핑 위주로 시간을 보내게 될 것 같다.
한국은 또 환율이 워낙 올라서, 이거 귀국 후에 남은 달러를 되팔아도 차익 챙길 수 있을 정도가 돼 있구나. -_-;;

민박을 한 집안이 다 크리스천 가정이었다.
LA에서 만난 분들은 아예 매주 우리 서울 교회 목사님하고 잘 알고, 설교를 정기 구독하는 KJV 신자들이니 노선이 완전 일치한다. 그러니 그 교회 다니는 청년이 미국 방문한 거니까, 이거 뭐 일면식인 사람들하고도 어지간한 친척 이상으로 친밀하게 지낼 수 있었다.

샌 프란시스코에서 만난 가정도 KJV까지 일치는 아니지만 꽤 열심히 믿는 장로교 집안이었다. 이것만으로도 마음이 굉장히 편했다.

금문교를 비롯해 볼 거 다 봤다.
말로만 듣던 실리콘 밸리와, 스탠포드, UC 버클리 대학도 다 눈도장 찍고 사진 찍었다. 둘은 서로 사립, 공립이라는 차이도 있거니와 캠퍼스 분위기가 서로 굉장히 다른 것 같았다.

프리웨이 저 너머로 보이는 저 건물이 말로만 듣던 휴렛 패커드, 야후의 본사라니 감개무량했다.

(2)

무지로 인해 한 가지 실망한 것.
샌 프란시스코에 UC 버클리 대학이 있고,
매사추세츠 주에 버클리 음악 대학은 따로 있다.
한글로는 구분되지 않으나 영어 스펠링이 서로 다르다. Berkeley vs Berklee.. -_-;;
내가 가 본 곳은 당연히 전자..

(스탠포드 대학과 라이벌 관계이다. 참고로 스탠포드 대학은 아래..)

버클리라고 해서 Looking for you의 작곡자 MALTA님이 거쳐 간 학교를 이 기회에 성지 순례로 방문하는가 싶었지만 그건 아니었다. T_T
후자뿐만 아니라 전자도 재즈 쪽이 강하다고 하더라만..
아마 송 영주 씨가 거쳤다는 버클리 대학도 전자가 아니고 후자이지 싶다. 한글로만 적으면 구분 못 한다. 전자를 "UC 버클리"로, 후자를 "버클리 음악 대학"으로 구분해 줘야 한다.

(3)

혼자 이렇게 훌쩍 외국으로 떠나는 것도 그렇게 어려운 일이 아니란 걸 알게 됐다.

미국 가기 전까지는 이민에 대해서 부정적인 얘기를 주로 많이 들어 왔다.
의료 제도가 완전 개떡이다,
유색 인종에 대한 정서적 차별이 여전하고 치안도 형편없다, 미국도 이제 예전의 미국이 아니다,
그저 교육비, 기름값 비싸다는 이유 정도만으로 한국 떠나고 싶다는 식의 소리는 꿈에도 하지 마라.

처럼.

하지만 여기서는 약간 다른 의견도 들었다.
여기에 잘 정착해 계신 분들은 하나같이 한국보다 여기가 살기 좋다고 말한다.
(한국과는 달리) 법과 원칙이 통한다,
연줄이 아니라 실력만 있으면 인정 받을 수 있다,
국민성이 훨씬 더 선진적이다,
굳이 대도시에 안 매달려도 푸근하게 잘 살 수 있다 등.

그리고 만난 분들로부터도,
너처럼 영어 걱정 없고 미국 음식 거부감 없고
더구나 컴퓨터 쪽 하는 사람은, 여기 와서 공부 계속하다 영주권 받고 걍 정착하라는 제안도 적지 않게 받았다. ㄱ-

단순히 개인의 영달 차원이 아니라
유능한 사람들이 이민 듬뿍 가 줘서 전세계에 코리아 타운 건설하고 한국인들이 정착해서 살 수 있는 터전을 마련하는 게 애국 행위라는 얘기까지 나오더라.
실제로 재미 교포들이 국내 수출 자동차나 전자 기기도 듬뿍 사 주고, 외환 위기 때 달러도 굉장히 많이 보태 줬다고 한다.
스타로 치면 끝없는 멀티 확장 뻘 되겠다.

에휴, 하지만 본인은 유학 가기엔 학부 성적도 상당히 안 좋고,
무엇보다도 한글 입력기, 한국 철도 등..
내 전문 특기 분야 자체가 그다지 미국에서 인정 받을 만한 분야가 아니니, 말씀은 고맙지만 현실성은 별로 높지 못하다. -_-;;

(4)

- 도로에 가끔씩 XING 이렇게 적혀 있는 게 도대체 뭐지? 한어병음 표기 같아서 중국식 지명이나 도로명인 줄 알았는데 LA뿐만 아니라 샌 프란시스코에서도 보인다.
나중에 알고 보니 CROSSING (횡단)을 줄여 쓴 것이었다. ㅜㅜ
미국 도로 표지판에도 그런 거 굉장히 많다. BLVD, RD, INTL
X는 Z소리도 되고, 음절 말미에서 ks 소리도 되고, 저런 의미도 갖고 있다. ㅜㅜ #이 sharp도 되고 number도 되는 것처럼.

- 흰 달걀을 미국 가서야 거의 10년만에 처음 본 거 같다. 우리나라는 묘하게 흰 달걀이 완전 자취를 감추고 말았다. 살색 달걀하고 맛, 영양이 아무 차이가 없는데 소비자 취향이 한데 우루루 쏠려 버렸기 때문이다.

- 미국에서 어디 돌아다니느라 차 안에서 보낸 시간이 정말 어마어마했다. 만약 다음에 또 미국 갈 일이 있을 때는 차에서 들을 수 있는 오디오 내지 MP3 씨디 하나 좀 구워 가야겠다. 오랫동안 Looking for you 못 들으니 금단 증세 때문에 좀 괴로웠다. ㅜㅜ
10년 안으로, 이번 여권과 비자 유효 기간이 끝나기 전엔 또 갈 기회가 있으려나? 더구나 미국 비자는 면제 직전에 꽤 번거롭게 받은 건데, 한 번 방문만으로 끝내 버리면 아까우니까. -_-

Posted by 사무엘

여기 낮엔 완전 더워서 초여름 같습니다.
여름 같은 날씨에 겨울 같은 낮 길이는 태국에서도 경험한 적 있지만 참 적응 안 되네요.

Posted by 사무엘

관광 하나 갔다오고 나니까 벌써 이번 주도 끝이 슬슬 보이는군요. 먼저 그랜드 캐년.

Posted by 사무엘

미국 가서 최초로 인터넷 접속..

예정 시각보다 50분 가까이 일찍 현지에 잘 도착했습니다.
11월 초에 서머 타임이 풀리기 때문에 그거 때문에 시각에 착오라도 생긴 게 아닌가 생각했을 정도입니다.
제트 기류가 시속 거의 300km를 넘는 속도로 불어 준 덕분인지, 순항 중일 때는 비행기가 시속 1200km를 넘는 속도로 날기도 했으니 이 정도면 음속 돌파 수준 아닌가요? =_=

이코노미 석으로 다리, 허리, 엉덩이가 본인이 경험상 견딜 수 있는 시간의 한계는 4시간 정도. -_-
하반신에 피가 잘 안 통하니 굉장히 힘들었습니다.
KTX 터널 안에서는 좀체 겪을 수 없던 이명 현상.. 비행기가 착륙할 때는 고막에 진짜 고통이 느껴졌습니다.
입을 벌리고 있으면 괜찮아진다고 하더군요. 저는 그건 몰라서 그저 귀 틀어막는 수밖에 없었음.

뉴욕 정도까지 가면 완전 북극 쪽으로 그린란드 내지 알래스카까지 빙 걸쳐서 가는데(그게 구면상에서의 최단 거리임.) LA이니 그냥 태평양만 쭉 경유하여 목적지에 도착했습니다.

지인 좀 만난 후 지금은 2박 3일 그랜드 캐년 여행사 관광을 가 있습니다.
라스 베가스의 모 호텔에서, 남 놋붉 빌려서 잠시 글 쓰는 중.

미국은,
1. 끝없이 펼쳐진 허허벌판 위로 뻗은 도로
2. 3층 이상 건물을 도무지 찾을 수 없는 시가지 내지 주거 구역
3. 서울 같은 고층 빌딩이 즐비한 도시

대략 이런 양상 같습니다. 뉴욕 내지 라스 베가스는 3정도 되겠지만
LA는 더구나 지진 위험 지대이기도 해서 대부분이 1, 2 타입입니다.
(내진 설계 하면 건축비 무지 비싸진다 함)

여기도 철도가 없지 않습니다. 고속도로 타다 보면 비록 원시적인 단선 비전철이긴 하나, 철길을 어렵지 않게 볼 수 있고

Posted by 사무엘

아무리 MS 워드가 다른 기술이 월등하고 훨씬 더 프로페셔널하고 무엇보다도 파일 포맷이 국제적으로 널리 통용되고 다 좋다고 하나, 아래아한글의 비장의 무기들.

글자 모양/문단 모양을 구분할 수 있는 속성 복사 Alt+C

그리고 Alt+B 키매크로. MS 제품에도 심지어 비주얼 스튜디오에는 키매크로가 있습니다. Visual Basic 기반의 더 복잡하고 전문적인 매크로 이전에 이런 게 없나 궁금합니다. 키매크로는 차라리 과거의 도스용 아래아한글만한 시절이 없었죠.
사실 매크로, 핫키 정도는 과거 윈도우 3.1의 “레코더”처럼 운영체제 차원에서 유틸이 하나쯤 있어야 합니다. 너무 초보자 위주의 마우스 GUI에만 치중하다 보니 GUI 운영체제들은 컴퓨터를 정말로 효율적으로 활용하게 해 주는 자동화, 프로그래밍, 일괄 처리 기능이 너무 미약하죠.

하나 더, 특정 스타일을 바로 지정하는 Ctrl+숫자 단축키. 이거 정말 워드에는 없나 궁금합니다.
사실 이따금씩은 도스 시절의 잔재인 “글꼴 단축키”가 아쉽기도 합니다. 블록 잡고 Alt+L, K, T, C, D 끗. (한글 폰트를 ‘견명조’로 바꾸기 ^^)

단축키가 더욱 빛을 발하는 또다른 분야는 표입니다. 저는 비슷한 난이도의 표 문서를 아래아한글과 워드로 모두 작성해 봤습니다. 셀 블록 잡기, 병합, 분할, 서식 지정 등등.
지켜보는 사람도 말하더군요. “님은 아래아한글 쓸 때는 대부분 양손이 키보드에 가 있고 단축키로 하는데, 워드는 꼭 스타 하는 것처럼 마우스 움직임이 복잡하고 많네. ㄳ”

워드 2007에서 표 작업 정도 하려면 ‘아래에다 셀 삽입, 셀 제거’ 같은 자주 쓰는 기능을 간추려서 Quick Access Toolbar에다가 옮겨놓기부터 먼저 해야 합니다. Home, Table 이런 리본들 왔다갔다하다 보면 정신 없습니다.

물론 워드가 훨씬 더 합리적으로 기능 잘 제공하는 것도 많습니다. 가령, 여러 아이템을 클립보드에다 복사해서 골라가며 붙이는 게 실무에서 이렇게 유용한 줄은 몰랐습니다. 오피스 2000부터 추가된 기능이죠.

아래아한글은 기본적으로 2.0 시절부터 표를 그림이나 문자 같은 동일한 개체라는 개념으로 봐 왔습니다. 그래서 여러 페이지에 걸치는 표는 2002에서 에디팅 엔진을 새로 디자인할 때에야 드디어 가능해졌습니다. 하지만 워드는 애초부터 표는 레이아웃의 일종으로 구현되었으며, 아래아한글처럼 표 전체를 한 글자처럼 취급하는 기능이 없습니다. 이건 HTML의 구조와도 비슷하죠.

아래아한글이 2.0 이래로 별다른 변화 없이 제공해 온 개체 배치 방식은 저는 완전히 이해하여 프로그램과 제가 일심동체가 되어 있는 반면, MS 워드가 개체를 배치하는 방식은 저는 나름 97 이래로 워드를 쓰고도 아직도 알쏭달쏭입니다. 내가 이렇게 바꾸면 프로그램이 이렇게 딱 동작할 거라는 확신이 없습니다. ㅜㅜ

서식 지정하는 방식, 특히 불릿/개요 같은 문단 속성도 마찬가지. 아래아한글은 딱 프로그래머스럽게 동작하는 반면 워드는 정말 제멋대로.. 그 미묘한 감각 차이는 아래아한글처럼 독학 자습만으로는 도저히 습득을 못 하겠습니다.

워드와 아래아한글은 서로 정말 극과 극에 가까운 다른 철학으로 디자인된 프로그램이라는 건 두 프로그램을 모두 중급 이상 활용하는 분이라면 누구나 공감할 것입니다. 저는 이미 초등학교 고학년 때 그림, 표, 메일 머지, 목차, 각주, 스타일, 개요 등등 아래아한글 2.X 전기능을 마스터한 반면 워드는 성인이 된 지금도 아직까지 그 동작 알고리즘이 뿌옇게 흐리게만 보입니다. 한 프로그램의 철학에 익숙한 사람이 다른 프로그램에도 능숙해지기는 어려운 장벽이 있습니다. 그래서 두 프로그램 중 하나가 쉽게 없어지지는 않을 것입니다.

워드에는 아래아한글처럼 매 언어별로 글꼴의 상대 크기와 장평, 자간을 세밀하게 맞추는 기능이 아쉽고, 아래아한글에는 워드처럼 사각형이 아닌 개체의 실제 모양대로 글자가 흐르는 어려운 기능, 아주 정교한 서식들(덧말, 첫 글자 자동 키우기 등, 아래아한글에도 없지는 않으나 글자 배치가 워드에 비해 완성도가 떨어짐) 같은 게 아쉽습니다.

아래아한글이 2004에서야 surrogate를 지원하기 시작하고 2005부터 아랍/히브리 문자를 제대로 지원하기 시작한 건 굉장히 늦은 감이 있지만 바람직한 향상이라 생각됩니다. 그나저나 2005는 2007에서 잘 쓰던 과거 신명 시스템 글꼴들을 왜 인식을 못 하나 모르겠습니다. 태 시스템 것만 인식되네요. (태 가는 헤드라인) ㅜㅜ

Posted by 사무엘