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

Windows에는 우리가 생각하는 것보다 훨씬 더 세밀한 UI 옵션들이 가득하다.
사용자의 취향과 컴퓨터의 성능을 고려하여 처음에는 옵션으로 도입됐다가 나중에는 그냥 '답정너 무조건 적용'이나 다름없게 바뀐 옵션의 대표적인 예는 "마우스로 창의 위치나 크기를 변경하는 것을 즉시 반영"이 있다.

마우스가 움직일 때마다 큼직한 창을 매번 다시 그리는 건 198, 90년대의 PC 사양으로 감당하기에는 계산량과 부하가 버거운 작업이었다. 그래서 처음에는 XOR 연산으로 그려진 반전 윤곽선만 마우스 궤적을 따라 그려 주다가 왼쪽 버튼이 떼어졌을 때 실제로 반영하는 형태로 move/resize 기능이 구현되었다. 이 동작을 기억하는 분도 계실 것이다.
그러다가 Windows 95에 와서야.. 그것도 Microsoft Plus!라는 확장팩을 설치한 뒤에 '즉시 반영'이 옵션 형태로 추가됐다.

그리고.. Windows XP에서는 타이핑을 시작했을 때 마우스 포인터를 화면에서 잠시 감춰 주는 자잘한 옵션이 추가되었다. 이건 딱히 성능하고 관계가 있는 옵션은 아니다만.. 텍스트 편집 기능을 자체 구현한 프로그램이라면 운영체제 차원에서 저 옵션이 켜졌는지 여부를 확인해서 저 동작을 지원해 줘야 할 것이다.

운영체제 제어판의 프로그래밍 버전 역할을 담당하는 함수는 SystemParametersInfo이다. SPI_GETMOUSEVANISH를 주면 포인터 숨기기 옵션이 켜졌는지 여부를 알 수 있다. 저 함수가 제공하는 거의 100가지가 넘는 옵션 상수들을 살펴보면 Windows의 UI의 변천 내력을 알 수 있다.
그리고 오늘 이 글에서 논하려 하는 것은 바로 그런 자잘한 UI 옵션 중의 하나인 UI state이다.

마소에서는 사용자에게 온갖 정보를 표시하는 것뿐만 아니라, 불필요한 정보를 가능한 한 숨기고 꼭 필요할 때만 표시하는 것에도 많은 관심을 갖고 연구한 듯하다.
그래서 사용자가 키보드 타이핑을 할 때는 마우스 포인터를 숨기고, 반대로 마우스를 주로 사용하는 것으로 보일 때는 키보드 조작과 관련된 시각 요소들을 숨기는 게 낫겠다는 생각을 하게 됐다.

키보드 조작과 관련된 시각 요소라니? 두 종류가 있다. 하나는 메뉴나 대화상자에서 Alt 단축키를 나타내는 글자 밑의 밑줄이고.. 다른 하나는 현재 키보드 포커스를 나타내는 점선 사각형이다.

이런 것들은 없는 게 시각적으로 깔끔하며, 사실 맥OS에는 저런 게 전혀 존재하지 않는다. 하지만.. 걔네들도 키보드 조작에 도움을 주는 정보이니 하루아침에 싹 없애 버릴 수는 없다.
그러니 절충안은.. 일단 숨겼다가 필요할 때만 표시하는 것으로 귀착된다.

하긴, 메모장이나 날개셋 편집기처럼 운영체제의 표준 메뉴를 사용하는 프로그램들을 살펴보면.. "파일(F) 편집(E)" 같은 항목에서 F, E에 쳐진 밑줄도 평소엔 보이지 않다가 사용자가 Alt를 눌렀을 때에만 표시되는 걸 볼 수 있다. 뭐, 요즘은 아예 메뉴가 통째로 보이지 않다가 사용자가 Alt를 눌렀을 때만 표시되는 프로그램도 있지만 말이다.

그리고 아래아한글은 대화상자의 단축키들이 Alt를 누르고 있는 동안만 잠깐 보이고, Alt에서 손을 떼는 순간 사라진다.
MS Office 프로그램은 문서 편집 화면에서 Alt를 단독으로 눌렀다가 떼면 리본의 기능들에 할당된 단축키들이 표시되는데, 이건 대화상자보다는 메뉴의 단축키 동작을 흉내 낸 것에 가깝다.

UI state는 저런 것들과 완전히 같지는 않지만 비슷한 상태와 동작을 다룬다.
Windows에서 돌아가는 모든 윈도우들은 UI state라는 숫자 형태의 속성을 갖는다. 이걸 얻어 오려면 자기 윈도우에 대해서 WM_QUERYUISTATE 메시지를 보내면 된다. 그럼 운영체제가 답변해 준다(wParam, lParam 없음. 리턴값만 확인하면 됨). 딱히 우리가 customize할 필요가 없는 메시지이니, SendMessage 대신 그냥 DefWindowProc에다가 바로 줘 버려도 된다.

리턴값은 비트 플래그 형태이다. 포커스 테두리를 그리지 말 것을 지정하는 UISF_HIDEFOCUS (1), 그리고 단축키 밑줄을 그리지 말 것을 지정하는 UISF_HIDEACCEL (2)를 살펴보면 된다.
Windows XP부터는 UISF_ACTIVE (4)라는 것도 추가됐다고 하지만 개인적으로는 의미나 용도를 전혀 모르겠다. “A control should be drawn in the style used for active controls.”라는 설명만 봐서는 이해가 잘...

static/label 컨트롤은 자체적인 포커스가 없으니 Alt 단축키 밑줄만 신경 쓰면 될 것이고, 아이템을 표시하는 리스트박스, 트리 컨트롤 같은 물건은 포커스 테두리만 신경 쓰면 될 것이다.
그에 비해 버튼(push, radio, checkbox 모두)은 단축키 밑줄과 포커스 테두리를 모두 관리해야 할 것이다. 반대로 에디트 컨트롤은 저런 걸 신경 쓸 필요가 전혀 없을 것이고..

포커스 테두리야 DrawFocusRect 함수를 이용하면 간편하게 그릴 수 있고, &가 섞인 문자열에 대해서 단축키 밑줄을 같이 그리거나 생략하거나(DT_HIDEPREFIX) 심지어 단축키 밑줄만(DT_PREFIXONLY) 그리는 건 DrawText의 여러 플래그들을 사용해서 간편히 구현 가능하다.

그런데 사용자가 대화상자에서 alt나 tab(포커스 테두리) 같은 글쇠를 누르면 그 대화상자 내부의 컨트롤 윈도우들은 감춰 놨던 보조 요소들을 표시하도록 UI state가 바뀌게 된다. tab은 포커스 테두리만 건드리지만 alt는 포커스 테두리와 단축글쇠 밑줄을 모두 건드린다. 한번 표시된 보조 요소들은 다시 숨겨지지 않는다.

이렇게 UI 상태가 바뀌었음을 나타내는 메시지는 바로 WM_UPDATEUISTATE이다. 얘는 우리가 생성하는 게 아니라 운영체제가 보내 주는 메시지이다. 어떤 플래그가 켜지거나(UIS_SET) 꺼졌는지(UIS_CLEAR)를 wParam 값을 통해 알 수 있으니 자세한 사항은 검색해서 구체적인 스펙을 찾아보면 된다.

이 메시지를 DefWindowProc에다가 넘겨 주면 우리 윈도우의 UI state값이 그렇게 변경되며, 동일 메시지가 우리의 child 윈도우들로 전파된다. 다시 말해 WM_QUERYUISTATE의 리턴값은 WM_UPDATEUISTATE를 DefWindowProc에다 요청하기 전과 후가 서로 달라진다는 것이다.
이 메시지를 받았을 때 우리 윈도우가 해야 할 일은, 우리 윈도우의 외형 중에서 그런 UI state의 영향을 받는 게 있는 경우 해당 부분을 다시 그리는 것이 전부이다. 해당사항 없으면 그냥 무시하면 된다.

alt와 tab이야 대화상자에서의 공통 단축글쇠이다. 이때 윈도우의 UI state를 변경하는 것은 IsDialogMessage 함수가 알아서 처리하는 것이라고 쉽게 유추할 수 있다.
그것 말고 우리 윈도우 내부에서도 자체적으로 UI state를 변경해 줘야 할 때가 있다. 사용자가 화살표 키 같은 걸 눌렀을 때 말이다. 이때는 WM_CHANGEUISTATE라는 메시지를 나 자신에게 보내면 된다. wParam에다가는 WM_UPDATEUISTATE와 동일한 스타일로 변경된 플래그를 주도록 한다.

DefWindowProc에서는 이 메시지를 부모 윈도우로 보낸 뒤, 최상위 윈도우에서는 메시지를 WM_UPDATEUISTATE로 바꿔서 자식들로 다시 전파한다. 이런 절차를 거쳐서 대화상자에 있는 모든 윈도우들의 UI state가 동기화된다.

지금까지 얘기했던 것들을 정리하면 이렇게 요약된다.
UI state를 인식해서 동작하는 컨트롤을 직접 구현하고 싶은 경우, WM_QUERYUISTATE를 호출하면 자신의 UI state 값을 얻을 수 있다. 그리고 WM_UPDATEUISTATE가 왔을 때 적절히 화면을 다시 표시하면 된다. 그리고 자기 자신이 UI state를 변경하고 싶은 경우, WM_CHANGEUISTATE를 보내면 된다.

모든 윈도우 메시지들은 DefWindowProc으로 가도록 하면 된다.
대화상자의 경우, 마우스 클릭으로 명령을 내려서 연 경우 저런 보조 요소들이 숨겨진 상태로 시작하며, 그렇지 않고 키보드로 열었다면 이들이 표시되어 있다.

이런 UI state 변경 메시지들과 관련 기능들은 Windows 2000에서 최초로 도입됐다. 9x/ME/NT4 시절에는 존재하지 않았다는 뜻이다. layered window, 마우스 포인터 아래의 그림자, fade out되며 사라지는 메뉴도 다들 2000에서 도입된 기능이다. 2000이 XP 같은 테마는 없었지만 그래도 소소하게 바뀐게 많다는 걸 알 수 있다.

이런 동작은 SystemParametersInfo(SPI_GETKEYBOARDCUES)에 값이 설정돼 있을 때만 행해진다. 제어판에서는 "Alt 키를 누를 때까지 키보드 탐색에 사용할 문자 숨기기"라는 이름의 옵션으로 존재한다. 이게 꺼져 있으면 UI state는 언제나 0으로 고정되며, WM_UPDATEUISTATE 같은 메시지가 오지 않는다.
처음에는 얘의 명칭이 SPI_GETMENUUNDERLINES이었다. 하지만 보다시피 단축키 밑줄뿐만 아니라 포커스 테두리 같은 요소도 추가되면서 명칭이 더 범용적인 'keyboard cue'라고 수정되었다.

이 기능 내지 API와 관련된 본인의 생각을 두 가지 정도 첨언하고 글을 맺도록 하겠다.

1.
라틴 알파벳처럼 음소 풀어쓰기 형태이고 키보드 글쇠와 글자가 일대일 대응하는 문자라면.. 간단하게 해당 문자를 곧장 단축글쇠로 지정해서 아래에 밑줄을 쳐 주면 된다. 하지만 한글· 한자 같은 문자는 그렇지 못하기 때문에 문자열 뒤에 단축글쇠를 별도로 추가해 줘야 한다. 파일(F) 편집(E)처럼 말이다.

이런 환경에서는 단축글쇠를 숨기려면 밑줄만 숨기는 게 아니라 (F), (E)를 통째로 감춰 버리는 게 훨씬 나을 것이다. 하지만 이건 문자열의 내용과 길이를 통째로 변경해야 하니 좀 난감할 수도 있다. 단축글쇠 영역이 기존 UI 문자열의 폭을 건드리지 않도록 별도로 돌출된 툴팁 같은 데다 표시해야 할 것이다.

2.
지금까지 글을 읽은 분이라면 눈치 채시겠지만,
UI state라는 건 앞서 언급했던 라벨, 버튼, 리스트 같은 공용 컨트롤이나 그에 준하는 물건을 새로 구현하지 않는 한.. 프로그래머가 접하거나 신경 쓸 일이 거의 없는 개념이다.
한 대화상자 아래에서 컨트롤들이 UI state가 제각각 달라야 할 일도 없고, 사용자가 WM_***UISTATE 메시지를 DefWindowProc에다가 전달하지 않고 동작을 override해야 할 일도 없다.

사용 패턴이 뻔히 정해져 있고 자주 쓰일 일도 없음에도 불구하고 관련 메시지가 안 그래도 공간이 부족한 시스템 메시지 영역에 3개나 들어가 있는 건 개인적으로 생각하기에 좀 낭비인 것 같다.
UI state는 그냥 GetWindowLongPtr 함수로(GWL_UISTATE) 얻게 해도 되고, WM_CHANGEUISTATE는 메시지 대신 함수가 담당하게 했어도 될 것 같다. 아니면 그 메시지조차도 SetWindowLongPtr로 대체하고 말이다.

내가 보기에 메시지 형태가 꼭 필요한 건 WM_UPDATEUISTATE뿐인 것 같다.

Posted by 사무엘

1. 에러 메시지의 친근성

먼 옛날 도스 시절에는 명령 프롬프트에서 파일 이름이나 명령을 잘못 입력하면 갖가지 에러 메시지들을 볼 수 있었다. 제일 흔한 건 Bad command or file name... 아무말이나 입력하고 엔터 누르면 볼 수 있으니 말이다.
오늘날 Windows의 명령 프롬프트에서 XXXX is not recognized as an internal or external command, operable program or batch file이라고 정말 길고 정황하게 나오는 그 메시지가 옛날에는 저렇게 간결하고 무뚝뚝하게 나왔던 것이다. bad가 뭐냐 도대체.. ㅡ,.ㅡ;;

유닉스 계열만 해도 XXX: command not found 내지 XXX: no such file or directory로 나뉘어 있으나.. 도스는 그 특성상 파일 실행과 명령의 구분이 없는 관계로, 단일 메시지에 파일과 명령을 모두 포함해야 했던 것이다.
그런데.. 그렇게 문장 한 줄만 뜨고 아무 뒤끝 없이 프롬프트로 돌아오는 에러와 달리.. 어떤 에러는 Abort? Retry? Ignore? 이러면서 사용자를 물고 늘어지고 놔 주질 않았다. 이게 초딩 시절엔 굉장히 무섭고 강압적으로 느껴졌다.

이런 무서운 에러는 디스켓과 관련해서 자주 볼 수 있었다. 드라이브에 디스켓을 넣지 않은 상태에서 A: 같은 드라이브 변경을 시도했거나.. 아니면 디스켓 파일을 복사하던 중에 오류가 발생했을 때도 저런 사태가 벌어졌다. 디스크 에러와 데이터 에러라는 게 있었는데, 둘의 차이는 지금 생각해 봐도 오리무중이다.

위의 그림은 도스/Windows 9x vs 오늘날 NT 계열 Windows에서 각각 디스크 없이 FDD 드라이브 전환을 시도했을 때의 에러 메시지의 모습이다.
아 옛날에는 ignore이 아니라 fail이었구나... 아무튼 저런 차이가 있었다는 것이다.
옛날에는 디스켓이 거의 복불복 지뢰밭 수준으로 오류가 잦았으며, 일반 프로그램이 파일을 읽고 쓰다가 지뢰를 밟지 않도록 주기적으로 표면 검사를 해서 bad sector 기입을 해 주는 게 필수이기도 했다.

사실, 시스템 전체의 관점에서는 에러가 이런 식으로 발생하는 게 효율적이다. 무작정 실패 판정만 내리고 끝나는 게 아니라 말 그대로 디스켓을 집어넣을 기회를 다시 준다거나, 오류를 무시하고 일단 더 진행한다거나.. 그러는 게 더 유도리가 있으며, 사용자 친화적이기까지 하다. 사용자가 모든 경황을 아는 전문가라면 말이다.

하지만 초보자의 입장에서는 저런 말이 뜨면 뭘 해야 할지를 모르고, 그냥 다 끄고 명령을 내리기 이전 상황으로나 돌아가고 싶을 것이다. 그런데 저놈의 메시지는 Ctrl+C고 ESC고 뭘 눌러도 없어지질 않고.. UI 측면에서 좀 미스인 건 사실이다.

게다가 말들이 표현이 아주 세고 기계적이고 부정적이다. Abort는 무슨 약속 예약 취소 같은 걸 넘어서 하던 걸 다 때려치우고 철회, 중단한다는 뜻이다. 오죽했으면 낙태라는 뜻까지 있다. Ignore도.. 무시, 묵살, '씹기', 생까기 같은.. 절대로 좋은 어감이 아니다.

물론 어떤 장애물에 부딪혀서 일이 진행되지 않았을 때, 그냥 포기하거나, 한번 더 시도하거나, 그 장애물을 일단 제끼고 넘어가는.. 세 가지 방법 중 하나로 의사결정을 하는 것은 일상생활에서 존재하며 필요하다.
DOS가 없어지고 Windows로 바뀐 오늘날까지도 본인이 프로그래머로서 저 패턴의 메시지를 보는 것은 디버깅 중인 프로그램이 뻗었을 때.. 더 구체적으로는 assertion failure가 났을 때이다. Retry가 디버거 실행과 연결된다.

Windows 2000/ME에서는 Abort/Retry/Ignore(중단/다시 시도/무시 MB_ABORTRETRYIGNORE) 대신, Cancel/Try again/Continue(취소/다시 시도/계속 MB_CANCELTRYCONTINUE)라고 말이 다소 부드럽게 바뀐 메시지 박스가 등장했다. 기존의 표현이 바뀌지는 않았으며, 새로운 플래그를 사용하는 프로그램에서만 새로운 표현을 볼 수 있다. 사실, A/R/I라는 단축키가 도스 시절 이래로 아주 익숙하며, 새로운 표현은 CTC로 이니셜이 겹치기도 하니 말을 일괄적으로 변경해 버리는 건 좀 부담스럽기도 했을 것이다.

그런데 MessageBox의 리턴값까지도 IDRETRY와 별도로 IDTRYAGAIN을 추가하고 IDIGNORE뿐만 아니라 IDCONTINUE도.. 이름뿐만 아니라 값까지 서로 별개로 추가해 버린 것은 의외이다. 두 쌍은 용도가 완전히 동일한데도 말이다.
참고로 MessageBox의 후신격인 TaskDialog에는 표준 버튼으로 '재시도 try again'만이 도입되었고, ignoer/continue는 포함되지 않았다. 기존의 확인/닫기/취소 등으로 보편적인 의사결정은 다 표현할 수 있다고 간주한 듯하다.

지금이야 Cancel/Try again/Continue가 첫 등장한 지도 20년 가까이 지났다. 컴퓨터 대신 PC, 디바이스라고 하고 응용 프로그램도 그냥 앱이라고 하는 세상이다. 게다가 이제는 전통적으로 무뚝뚝함과 충격과 공포 그 자체이던 패닉 BSOD화면에도 이모티콘과 한글 메시지가 표시되는 세상이 됐다. press any key의 번역은 "... 누르십시오" 대신 "... 누르세요"로 바뀌었다. 여러 모로 격식이 없어지고 말이 친근하게 바뀌고 있는 것 같다.

하지만 C/C++ 프로그램의 디버그 빌드에서 assertion failure가 났을 때, 무식한 A/R/I 메시지박스와 함께 "Press Retry to debug this application"이 뜨던 건.. 깔끔한 task dialog로 바뀌는 날이 올지 모르겠다.
end user는 볼 일 없고 어차피 개발자들이나 보는 메시지이니 아무도 신경 안 쓰려나? =_=

2. 반응성과 존재감

어떤 소프트웨어가 인터페이스 내지 반응성 관점에서 사용자에게 좋은 인상을 주려면 자잘하게 뻗는다거나 화면 잔상이 생기는 버그가 없어야 하고, 키· 마우스 입력에 대한 반응이 신속해야 할 것이다. 반응성을 보장하기 위해 필요하다면 스레드 같은 것도 적절하게 활용해야 한다. 어지간해서는 5초 이상 반응이 없어서 '응답 없음' 판정을 받는 일이 없어야 한다.

마우스로 창 크기를 변경했을 때 너무 굼뜬다거나, 화면 전체가 지워져서 번쩍거리면서 그려진다거나 하지도 않아야 한다. 새로 그리는 게 시간이 너무 오래 걸리는 게 있으면, 스크롤 내지 크기 변경 중에는 뼈대만 간략하게 그렸다가 키보드· 마우스 버튼이 놓였을 때 다시 그려도 좋다.

그런데.. 이런 것들과 반대로, 눈에 보이지 않고 백그라운드에서만 몰래 돌아가는 프로그램에도 지켜야 할 덕목이 있다.
사용자가 직접 명령을 내려서 실행된 게 아닌 서비스, 업데이트 체크 같은 부류의 프로그램이라면 정말 절대적으로 사용자의 눈에 띄지 않아야 한다.

컴퓨터의 성능을 떨어뜨리는 티를 절대 내지 말아야 한다.
요즘 컴터는 코어가 많으니 한 프로그램이 코어 하나를 다 점유한다고 해서 당장 속도가 느려지지는 않는다. 하지만 컴터를 열받게 할 수 있고 배터리 소모를 증가시킬 수 있고, 냉각팬이 쓸데없이 돌아가게 만들 수 있다. 특히 노트북에서 말이다.

업데이트를 받더라도 무슨 당장 안 받으면 컴퓨터가 악성 코드에 감염되어 박살나기라도 하는 울트라 초특급 필수가 아니라면 아주 쉬엄쉬엄 찔끔찔끔 받도록 하고, 네트웍 상태가 안 좋아서 발생하는 딜레이가 UI의 딜레이나 CPU 쳐묵 대기 상태로 절대로 이어지지 않게 해야 한다.

이는 음악회에서 넘돌이 넘순이(페이지 터너..;;)가 연주자보다 더 돋보여서는 안 되고, 무슨 집회에서 통역사가 연사보다 더 돋보이지 말아야 하는 것과도 같은 이치이다.
인터넷 연결이 안 된 곳에서 Windows Update 서비스라든가, 구글 크롬 브라우저의 software report tool이 도대체 뭔 짓을 하느라 CPU 코어를 다 쓰면서 날뛰고 있었나 모르겠다. 현재로서는 요 둘이 내 블랙리스트에 올라 있다.

컴퓨터 프로그램은 n초 이상 응답이 없으면 저렇게 다운 의심 판정을 받게 되고, 운전자는 교차로에서 파란불 신호를 받고도 n초 이상 응답 없이 움직이지 않으면 뒷차로부터 경적 세례를 받고 욕 먹게 된다. 개인적으로는 이게 서로 비슷한 양상의 현상인 것 같다.

3. 이식성

로터스 1-2-3, dBase III+ 같은 프로그램은 한때 시대를 풍미했던 명품 업무용 소프트웨어였다. 하지만 도스에서 Windows로 넘어가는 변화를 따라가지 못하고 그대로 도태해서 사라졌다.

내가 듣기로는 이 두 프로그램은 긴 짬밥답게 주요 코드가 쑤제 어셈블리어로 한땀 한땀 작성됐다고 한다. 덕분에 1980년대에 컴퓨터가 느리고 비싸던 시절에는 잘 최적화돼서 쌩쌩 돌아갔겠지만, 훗날 이 코드는 구조 확장이나 유지 보수가 도저히 안 되는 지경에 이르렀다고 한다. 특히 dBase가 말이다.

이래 가지고는 Windows로 포팅은 물론이고 같은 도스에서 32비트로 갈아타는 것조차도 쉽지 않았을 것이다. 현재의 하드웨어에서 돌아가지만 시간이 그 상태 그대로 멈춰 버린 코드는 그야말로 오늘만 사는 죽은 코드나 다름없다.

운영체제 중에서 Windows 9x야 저사양 똥컴 x86만 겨냥한 특이한 변종이니 어셈블리어 최적화가 없으면 안 됐고.. OS/2도 잘 만들어진 32비트 OS이긴 하지만 이식성이 부족했다. 훗날 64비트니 ARM이니에 전혀 대처하지 못하고 그대로 묻혀 버렸다.

그러나 유닉스처럼 C/C++을 처음부터 주력으로 사용한 Windows NT는 비록 처음에 나왔을 때는 너무 무겁고 느리다고 욕 먹었을지언정, 결국 여러 아키텍처들을 거쳐 오늘날까지 천수를 누리는 운영체제 커널이 됐다. 미래를 대비한 것에 대한 보상을 받은 것이다.

이런 게 이식성의 힘이다. 다만, 이 2020년대에는 이제 x86 계열과 ARM 계열 말고 또 획기적으로 새로운 컴퓨터 아키텍처가 설마 등장할 일이 있을까 싶다. ARM은 전력 효율이 x86이 범접할 수 없을 정도로 좋긴 하지만, 그렇다고 x86을 완전히 대체할 정도로 범용적인 성능이 좋은 건 아니다. 그러니 결국 이 두 아키텍처가 64비트 형태로 끝까지 갈 것 같다.

4. Windows와 맥이 추구한 가치의 차이

과거에 비해 텃새랄까 격차가 많이 줄긴 했지만 그래도 사과가 그려진 맥OS 컴퓨터는 예술, 출판, 디자인 업계에서 오늘날까지도 Windows보다 강세이다. UI 비주얼이 간지 날 뿐만 아니라, 같은 글꼴을 써도 글자의 렌더링이 정말 고퀄인 것을 부인할 수 없다.
그런데 그 분야 말고 게임은.. 특히 모바일용 말고 PC용은 맥 진영이 절대 범접하지 못할 정도로 Windows가 강세이다.

물론 게임은 애초에 특정 업계 종사자만 쓰는 업무용 생산성 앱이 아니며, Windows는 게임을 즐기는 end user 고객의 점유율이 압도적으로 높은 운영체제이다.
오늘날의 결과만 놓고 보면 저런 점유율이 당연히 저절로 이뤄진 것 같지만 사실은 그렇지 않았다. 먼 옛날에 IBM 호환 PC라는 물건은 동시대의 다른 컴퓨터들에 비해 사용자의 눈과 귀를 현혹시키는 기술에는 그렇게 관심을 두지 않았었기 때문이다.

지금으로서는 믿어지지 않지만 한때 Windows 같은 멀티태스킹에 하드웨어 추상화가 갖춰진 복잡한 환경에서 현란한 게임은 어림도 없는 일이었다. 그렇기 때문에 1990년대 중반까지만 해도 PC용 게임은 하드웨어 자원의 독점이 가능한 도스용으로만 나왔다.

그리고 90년대 중반, Windows 95는 바로 이런 배경에서 출시되었다.
빌 게이츠는 가히 목숨을 걸고 Windows를 게임과 멀티미디어에 최적화된 홈 엔터테인먼트 운영체제로 만들려고 애썼다. 구닥다리 WinG로는 성이 안 차고 OpenGL은 그 시절엔 아직 업무용에다 NT의 전유물이었으니.. 거기서도 하드웨어 직통 액세스가 가능한 DirectX를 만들고 게임 개발을 위해 물심양면 지원을 했다. Doom을 만들어 냈던 이드 소프트웨어를 인수할 생각까지 했던 것도 유명한 일화이다.

이런 마소 진영에 비해, 맥은 클래식 시절이건 OS X의 개발 초창기이건 잡스 아저씨가 저렇게 게임에 눈독을 들였다거나, Doom을 자기 맥OS에서 꼭 구동하고 말겠다고 나선 적이 없다. 빌처럼 가정 소비자들의 취향을 저격하는 방법, 시장에서 팔리는 제품을 만드는 방법을 기를 쓰고 연구하기보다는 그냥 자신의 천재적인 감과 괴팍· 고상한 취향을 따라 제품을 만들었다. 다수의 보편적인 소비자보다는 소수의 골수 매니아 애플빠를 양성하는 노선을 추구한 듯하다.

5. 설치/배포 패키지

Windows Installer (msi)라는 기술이 개발된 게 20여 년 전 1999~2000년 사이의 일이다.
소프트웨어의 설치와 제거라는 게 '파일 열기/저장 대화상자'만큼이나 응용 프로그램들이 공통으로 요청하고 수행하는 기능이니, 이를 위한 공통의 API를 정의하고 만든 것은 일면 바람직한 일이다.

하지만 얘는 2009~2010년 정도까지 버전업이 되었다가 그 뒤부터는 이렇다 할 변화가 없는 것 같다. 2010년대부터는 마소에서도 Office나 Visual Studio 같은 제품을 배포할 때 msi를 사용하지 않는다. 또 자신들만의 독자적인 설치/제거 시스템을 개발하기라도 한 것 같다.

통상적인 배포 패키지 시스템이라면 프로그램의 구성요소들을 세부적으로 나눠서 지금 당장은 사용자가 원하는 부분만 설치하고, 설치하지 않은 기능은 나중에 언제든지 추가 설치 가능하게 되어 있다.
그런데 2010년대 이후의 배포 패키지 시스템이라면 적어도 두 가지 요소를 반드시 지원해야 할 것 같다.

(1) 먼저, 웹을 통한 설치이다. 지금 로컬 installer 실행 파일에 내장된 데이터가 아니라 지정된 주소를 통해 서버로부터 데이터를 받아서 설치하는 것이다.

그리고 (2) 요즘 프로그램들의 거의 필수 기능이 된 최신 버전 체크 및 자동 업데이트와의 연계이다. 현재 버전과 최신 버전을 비교하여 부분만 자동 업데이트가 가능한지 판단하고, 꼭 바뀌어야 하는 분량만큼만 다운로드를 한다.
설치 후에 마이너 버전이 바뀐 것은 '프로그램 추가/제거' 목록에도 당연히 반영된다.

Windows Installer가 웹 연계 내지 자동 업데이트까지 고려하여 개발되었는지 잘은 모르겠지만 내가 알기로 그 정도까지는 아니지 싶다.
통합된 API가 없으니 Visual Studio고 아래아한글이고 다 독자적인 설치 및 업데이트 시스템을 구축하고 있는데.. 업데이트를 시켜 보면 프로그램뿐만 아니라 설치 관리자 자체부터 업데이트 하는 경우가 굉장히 잦다.

저건 뭐 한번 만들어 놓고 나면 버전 체크, 파일 설치 등등 끝.. 처음에 한번 안정적으로 잘 만들어 놨으면 바뀔 일이 없어야 하는 시스템이지 않은가? 그런데 뭐 이리 자주 바뀌나 모르겠다. 그리고 궁극적으로는 이런 분야도 운영체제 차원에서의 통합 솔루션이 나와야 할 것 같다.
그나저나 10~20여 년 전에 시대를 풍미한 배포 패키지이던 InstallShield는 요즘도 잘 먹고 살고 있는지 모르겠다.

6. 각종 약관 동의 화면

웹사이트에서 회원 가입을 할 때나 응용 프로그램을 처음 설치할 때는 사용자에게 뭔가 법적으로 동의를 구하는 계약 안내문이 표시되는 것이 관례이다. 사용자가 그 내용에 대해 명시적으로 yes라고 동의 의사를 밝혀야만 다음 단계로 넘어갈 수 있다.

응용 프로그램을 설치하는 경우라면 안내문의 내용은 주로 저작권과 관련된 것이다. 마소에서는 이 안내문의 명칭을 EULA(end-user license agreement)라고 붙인 것으로 잘 알려져 있다. 상업용 소프트웨어에는 불법 복제 금지와 관련된 경고문이 으레 들어가지만 그것 말고도 해킹이나 리버스 엔지니어링 금지 같은 조항도 있다.
한편으로 웹사이트 회원 가입이라면 개인 정보 수집 정책과 관련된 내용이 꼭 포함된다.

아울러, 요즘은 응용 프로그램도 사용권 계약과는 별개로 사용자의 사용 패턴 데이터나 오류 정보를 수집해서 개발사 서버로 보내도 되겠는지 동의를 구하기도 한다. 이걸로 사용자 개인을 식별하는 건 절대로 아니니 안심하라고 하면서.. 물론 이건 동의하지 않아도 프로그램을 설치하거나 사용하는 데는 지장이 없다.

이런 약관이나 법적 주의사항 고지 문구는 너무 비현실적인 상황까지 일일이 어려운 단어와 장황한 문장으로 미주알고주알 열거하면서 길고 딱딱하고 재미없는 걸로 악명 높다.
뭐 이건 온갖 애매한 상황까지 철저하게 논리적으로 방어해서 갑 쪽의 법적 책임을 최대한 피하기 위해 말이 그런 식으로 만들어진 것이다. 계약서는 아니지만.. 망토 하나를 만들어도 소송을 피하기 위해 “주의: 이걸 목에다 두르고 옥상에서 뛰어내리지 마시오” 경고문까지 들어가는 게 세상 돌아가는 이치이지 않은가?

그런데 말이 하도 재미없으니 갑이나 을이나 텍스트를 꼼꼼히 제대로 읽지 않는 건 마찬가지 같다. 그러니 한 10여 년 전이었나? “본 약관이 해지되는 순간 뼈와 살이 분리됩니다”던가? 개드립이 들어간 약관이 복붙 되어서 여러 웹사이트들에서 그대로 쓰인 게 뉴스에까지 방영되곤 했다.

약관과 관련된 말이 좀 길어졌는데..
본인이 이걸 표시하는 소프트웨어 UI와 관련해서 굉장히 큰 불만을 품고 있는 건.. 아니, 이건 나만의 불만도 분명 아닐 것이다.
안 그래도 재미없고 귀찮아서 안 읽는 긴 약관을 너무 작은 크기의 텍스트 셀에다가 집어넣고는 창의 크기 조절도 안 되게 해 놓으면.. 사용자는 읽고 싶은 생각이 더욱 멀리 달아날 것이다. 그렇지 않겠는가?

쪼금 생각을 한 곳에서는 약관을 plain text가 아니라 서식을 적용한 텍스트로 제공하고, 인쇄 기능 정도는 갖다놓았다. 하지만 이걸 인쇄까지 해서 보는 사람도 과연 얼마나 될까?
그냥 화면에서 창 크기 조절과 본문 검색 정도만 가능하게 하는 게 제일 좋아 보인다.

Posted by 사무엘

마침내 운길산의 정상에 도달했다.
이 산은 국립공원이나 각종 둘레길 같은 브랜드가 없고, 딱히 군사 시설이나 역사적인 사연도 없는 아주 평범한 산이었다. 구조도 흙산이어서 정상 부근에 거대한 바위 같은 것 역시 보이지 않았다.

정상에는 어쩐 일인지 넓은 전망대가 꾸며져 있었다. 그리고 본인 말고도 다른 등산객 일행이 서너 명가량 있었다.

이 날 본인이 세팅한 숙소이다.
정상으로 가는 길의 중간쯤에 헬리패드와 함께 넓은 공터가 있었다. 그리고 그 공터의 주변에 고맙게도 이런 평상이 3개 정도 있었던 덕분에 거기에다 간편하게 텐트를 칠 수 있었다. 텐트를 지고 힘들게 산을 오른 보람이 있었다.

본인은 여기서 저녁을 먹고 하룻밤 묵었다. 예빈산, 갑산 새재고개에 이어 운길산까지.. 남양주 남부에 있는 산의 정상이나 능선에서 야영 기록을 연달아 남기게 됐다.
이불만 덮으니 밖은 전혀 춥지 않고 지낼 만했다.

4. 국도 45호선과 대성리 유원지

한숨 잘 자고 나서 텐트를 걷고 산을 내려갔다. 이른 아침에 국도 45호선을 타고 북한강을 따라 북쪽 가평 방면으로 이동했다. 안개가 자욱히 껴 있는 시원하고 한적한 시골길을 주행하는 기분은.. 정말 끝내주게 좋았다. 그래서..

둘째 날의 첫 목적지는 대성리 역 근처에 있는 북한강변의 넓은 풀밭이었다. (그 전에 대성리 역 화장실의 도움을 받기도..)

사진은 전반적으로 흐리고 우중충한 잿빛으로 찍혔지만 지내기는 이때가 덥지 않고 무척 좋았다. 주변엔 저 멀리 자전거 타거나 산책하는 사람만 가끔 지나가고, 이 공터에는 아무도 없었다.

본인은 여기서 돗자리 깔고 있으면서 폰과 노트북의 남은 배터리를 모두 소모했다.
아직 일반적인 식당이나 카페가 문을 열기에는 좀 이른 오전이었지만, 그래도 아침 9~10시쯤 되니 민간 카페(?) 말고 브랜드 체인점 카페는 문을 연 게 있었다. 거기서 또 2시간이 넘게 있으면서 음료와 전기를 보충하고 인터넷 확인도 했다.

5. 청평댐과 지방도 391호선

아침이 지나고 낮이 가까워지자 해가 뜨고 날이 급격히 더워졌다. 그리고 도로에는 이전보다 차들이 훨씬 더 많아졌다.

보급을 받은 뒤엔 이제 어디에 갈지가 고민됐는데.. 마침 신청평대교 아래의 강변에 아주 넓은 풀밭과 함께 한낮부터 텐트들이 잔뜩 보였다. 사진에는 나오지 않았지만 저 멀리 댐 같은 것도 보였다.

이에 본인은 옳다구나 하고 그리로 내려갔다. 낮에는 또 여기서 텐트를 치고 지냈다.
자세한 내역을 적지는 않지만 이 날 카페와 텐트 안에서 날개셋 한글 입력기의 코딩 작업도 많이 진행됐다.

여기까지 일과를 진행하니 오후 3시쯤이 됐다.
이제 가평 쪽으로 탐험을 더 계속할지, 아니면 어디로 갈지 고민하던 끝에.. 이번 여행의 공세종말점(?)을 감안했을 때 신 청평대교를 건너서 유턴을 하는 것으로 결정했다. 강 건너편의 지방도 391호선 강변 구간도 어차피 몽땅 미지의 영역이긴 마찬가지이기 때문이다.

돌아오는 길에 점심을 먹고, 어느 근사한 카페에서 전자기기들을 추가로 충전하며 마지막 보급을 받았다.
391번 지방도는 마냥 평지에서 강만 따라가는 게 아니라 가끔 경사와 커브가 아주 급한 산길 형태로 돌변하기도 했다. 운전이 꽤 다이나믹했다.

벌써 날이 슬슬 저물고 있다. 여기는 아마 양평과 가평 경계의 어느 카페촌이었지 싶다. 마음만 먹으면 인터넷 지도를 펴서 정확한 위치를 추적할 수도 있겠지만.. 귀찮아서 생략한다.
이 당시 서종대교 위로 60번 고속도로는 차들로 몸살을 앓고 있었다. 상· 하행 어디인지는 기억이 안 나지만..

6. 강변 오토캠핑

그리고 저녁 6시 반쯤, 가평을 벗어나 양평 서종면 구간에서 드디어 텐트들이 즐비한 넓은 캠핑장을 발견했다. 캠핑장은 보통 '수상레저'라는 상호가 붙은 곳에 같이 있는 편이었다.

강가에 텐트... 취미 성향이 이런 쪽인 남자사람이라면 높은 확률로 낚시에도 재미를 붙일 법하지만.. 그러고 보니 본인은 어제와 오늘 동안 자덕들은 많이 봤어도 낚시꾼은 거의 못 봤다.

이렇게 물 바로 코앞에다 텐트를 치고 강 구경 하면서 밤을 보내니 이것도 황홀하기 그지없었다. 산에서 보냈던 어젯밤과도 비교되고 말이다. 한강 공원이나 팔당호 주변의 강가라면 상상도 할 수 없는 일이다.

텐트를 친 모든 사람들이 야영을 하지는 않았다. 해가 떨어지니 상당수는 돌아가고 텐트는 몇 개 남지 않았다. 그래도 전혀 없지는 않았다..;;

어제는 등산 때문에 피곤해서 그런지 눈을 감자마자 곧장 기절했지만, 이 날 밤은 덜 피곤하고 마음이 들떠서 그런지 눈을 감았다 뜨기를 반복하면서 몸이 시동이 쉽게 꺼지지 않았다. 새벽 3시가 넘게 컴퓨터 작업과 독서를 반복하다가 그제서야 잠시 잠들었다.

아침에 일어나니 날씨는 어제와 거의 같았다. 어제와 비슷하게 아침 드라이브를 즐기며 귀가했다. 길거리 사진은 이것 하나만 올리지만, 여기 도로 주변 풍경이 전반적으로 다 이런 식이었다.

남한강 합류 지점이 가까워지자 강폭이 커지고 주변에 갑자기 울타리와 철조망이 둘러지면서 “상수원 보호 구역” 표지판이 곳곳에 눈에 띄기 시작했다. 이걸 보니 여행이 끝났다는 게 벌써부터 느껴졌다.
이렇게 휴가 여행을 마쳤다. 그러고 보니 경기도조차 벗어나지 않은 단거리 투어가 됐지만.. 새로운 장소들을 개척하면서 자연인· 자유인 체험을 잘 하고 왔다. ㅎㅎ

Posted by 사무엘

우리나라는 4월 말부터 5월 초 사이에 석가탄신일, 근로자의 날, 주말, 어린이날이 거의 일렬로 쭉 이어지는 황금 연휴가 있는 편이다. 일본은 4월 29일이 쇼와의 날이라고 해서 자기네 리즈 시절이었던 히로히토 일왕을 기리는 공휴일인데.. 한국은 석가탄신일이 얼추 비슷한 시기에 공휴일 역할을 하는 것 같다. 성탄절과의 형평성을 맞추기 위해 1970년대에야 추가된 종교 공휴일이 나름 봄철의 연휴를 더욱 풍성하게 만들어 주고 있다.;;

평소 같았으면 이 기간 동안 너도 나도 외국으로 나가느라 인천 공항은 터져나가고 있었을 것이다. 그리고 국민들더러 외국으로만 나가지 말고 내수 경제도 좀 살려 달라고 나라에서 고속도로 톨비도 면제해 줬을 것이다.
하지만 올해는 그런 것 없다. 천재지변 급의 재앙 때문에 하늘길이 꽁꽁 묶여 버렸다. 인천 공항은 재작년에 평창 올림픽에 맞춰서 제2 여객터미널까지 당당히 개장했는데 지금 이게 무슨 꼴이냐..;; 안습하기 그지없다.

그래도 국내는 다행히 전염병이 기세가 많이 꺾였으며, '사회적 거리 두기' 조치도 완화되었다. 그러니 본인은 이 연휴 기간 동안 하계 휴가에 준하는 국내 여행을 다녀왔다. 여행의 컨셉은 "2020년 춘계 황금연휴를 이용한 자연인 체험 -- 북한강변을 중심으로"가 됐다.

생각했던 것만치 멀리 나가지는 않았지만 지금까지 한 번도 답사했던 적이 없는 장소를 다니면서 자연을 즐기고 왔다. 특히 "하루는 산에서 자고 하루는 강가에서 자기"를 목표로 설정하여 잘 달성했다.
딱 하나 미스는 처음에 떠나는 길에 시간대를 잘못 선택해서 극심한 교통 체증에 시달린 것이었다. 역시 이 시국에 나만 여행을 가는 게 아니었다..;; 평범한 아침 시간대가 아니라 새벽 같은 다른 시간대를 선택했어야 했다.

사고 하나 없이 오로지 차량과 분기점 병목만으로 길이 이 정도로 막히는 건 굉장히 오랜만에 봤다.;; 팔당대교 진입로에는 2~3km에 달하는 차들이 길게 늘어섰다.
명절 귀향· 귀경길이 아닌 상황에서 차 내비 화면에 "2시간 연속 주행하셨습니다. 좀 쉬었다 가세요"가 뜨는 걸 보니 자괴감이 들었다.

서울을 빠져나가는 건 마치 우주 로켓이 1단 엔진을 가동해서 지구 대기권을 빠져나가는 것과 같았으며,
서울 교외에서 남양주든 양평이든 가평이든 어디든 가는 건 지구 저궤도에서 3단 엔진을 가속해서 달이든 화성이든 가는 것과 비슷하게 느껴졌다.

서울-남양주가 2시간이 넘게 걸렸다. 하지만 일단 서울을 벗어난 뒤부터는 고생한 것에 대한 보상을 충분히 받을 수 있었다.

1. 중앙선 구 능내 역

이번 여행의 첫 목적지는 바로 남양주 조안면에 소재한 중앙선 능내 역이었다. 이 역은 중앙선 복선 전철화와 선형 개량(=대대적인 선로 이설)으로 인해 2008년 말에 폐역했지만, 역 주변이 통째로 공원 내지 관광지로 보존 처리되었다.
본인은 다산 유원지는 두 번이나 다녀왔지만, 저기는 지금까지 가 본 적이 없었다. 다산 유원지와 이 정도로 가까이 있는 줄 몰랐다.

역 내부와 승강장은 지난 2월에 답사했던 화랑대 철도 공원과 여러 모로 비슷한 분위기였다.
단, 여기는 "자덕들의 성지"라는 점에서 화랑대 철도 공원과는 차이가 있었다. 반포 한강 공원이 자덕의 성지인 것처럼 말이다.
그도 그럴 것이 중앙선과 경춘선은 모두 복선 전철로 개량되면서 많은 구간이 이설됐는데, 기존 구선로 구간, 특히 강을 따라 달리는 구간은 상당수 자전거길로 리모델링 됐기 때문이다. 능내 역은 이 과정에서 특혜를 입은 셈이다.

여느 철도 공원이 그렇듯이, 저기 보이는 객차 안에도 카페가 있다. 하지만 본인이 방문하던 당시에는 역시 코로나 크리 때문에 영업이 중단돼 있었다.

선로에서 역 건물을 바라본 모습이다. 이 시선의 후방으로는 자전거 도로가 나란히 놓여서 자전거들이 씽씽 지나갔으며, 근처에는 자전거 대여점도 있었다.

역의 근처에는 선로와 자전거 도로, 주차장이 이런 식으로 이어졌다.

2. 물의 정원

능내 역을 답사한 뒤, 다음으로 본인은 북한강을 따라 가평 방면으로 올라가다가 '물의 정원'이라는 강변 공원을 발견하여 거기를 들렀다.
팔당 물안개 공원 같은 곳이 남양주의 북한강 구간에도 있었구나. 다만, 규모는 이게 훨씬 더 작다. 그리고 여기가 팔당 물안개보다는 먼저 만들어졌다.

대략 이런 곳이다.

날씨도 좋고.. 아무 데나 카메라를 들이대도 근사한 풍경화가 나오는 것 같았다.
사람들은 넓은 풀밭을 자유롭게 거닐다가 벤치에 앉아 쉬거나 나무 그늘 아래 돗자리를 깔고 앉곤 했다.

공원 내부에는 이렇게 섬 같은 곳을 드나드는 다리가 있었다. 섬 안이나 밖이나 면적은 비슷해 보였다.

마지막으로 한 장면 남긴다. 본인은 여기서 2시간 남짓 머물면서 신선놀음을 하다가 다음 장소로 이동해서 등산을 시작했다.

3. 운길산

등산 대상은 큰 고민 없이 의외로 금방 정해졌다.
운길산은 본인의 여행 경로와 가까이 있고 산 중턱의 수종사 부근까지 차를 몰고 들어갈 수도 있기 때문이다. 게다가 정상 근처에 평상까지 준비돼 있으니 가히 최적의 장소가 아닐 수 없었다. 덕분에 본인은 첫째 날은 여기서 텐트 치고 잤다.

마침 이 날이 석가탄신일이기도 해서 수종사 주변의 주차장 공터엔 불자들이 등산객 이상으로 아주 많았다. 절과 운길산 역을 오가는 셔틀버스(소형 승합차..)도 다닐 정도였다.
산을 올라간 다음에는 다음날 아침에 내려올 예정이니 본인은 여기서 오늘의 마지막 보급을 받았다. 음료수를 보충하고 전자기기들을 충전했다.

수종사를 지나고 나니 주변에는 절 방문객이 아닌 등산객만 남고 주변이 썰렁해졌다.
거기서 정상까지 명목상 이동 거리는 800m 남짓에 불과했지만, 고도는 거의 300m 가까이 상승해야 했다. 즉, 등산로가 꽤 가파르고 험했다.

산에서 '물의 정원' 쪽을 내려다본 모습이다.

북한강과 저 멀리 남한강이 합류하는 지점의 모습이다. 산에서는 이런 넓은 전망을 볼 수 있으니 좋다.

Posted by 사무엘

오늘은 오랜만에 원초적인 성경 계보와 종교 비교 얘기를 좀 하겠다. ㄲㄲㄲ
종교 개혁 개신교 진영에 킹 제임스라는 고전 영어 성경이 있다면, 가톨릭(천주교) 진영에는 듀에이-림즈(Douay-Rheims)라는 고전 영어 성경이 있다.

개신교 쪽 성경 중에 제네바 성경처럼 인명이 아니라 지명을 딴 역본이 있듯, 듀에이와 림즈는 프랑스의 지명이다. 원어인 프랑스어 스타일로 읽으면 “두에 렝스”라고 한다.
프랑스는 영국이나 독일과 달리 개신교 쪽의 종교 개혁이나 성경 번역과 관련해서는 언급되는 게 아무것도 없는데, 그 대신 천주교 성경이 저 동네에서 번역되었던가 보다.

공교롭게도 킹 제임스와 듀에이-림즈는 나온 시기가 굉장히 비슷하다. 전자는 어명에 의해 1604년에 번역 위원회가 조직되고 번역이 시작됐으며, 1611년에 전서가 한꺼번에 출간됐다.
한편 후자는 전자보다 약간 더 전부터 더 오랫동안 번역되어서 1582년에 신약, 1609년에 구약의 순으로 나눠서 출간됐다. 그래도 시기가 상당히 비슷한 건 사실이다.

1582년은 율리우스력을 개정하여(100의 배수해의 윤년 여부) 현재까지 세계 공통으로 쓰이는 달력인 그레고리력이 시행된 해이기도 하다. 저 때가 교황청에서 나름 성경도 만들고 달력도 고치는 등 여러 일을 했던 때였다. 왜냐하면 그 당시 쟤들은 독일에서 시작된 종교 개혁을 저지하고, 교황의 권위를 다시 강화해야 했기 때문이다.

영국은 먼 옛날 헨리 8세 때부터 이미 교황으로부터 결별하고 자체 교회를 운용하였으며, 자국어로 성경 번역도 진작부터 하고 있었다. 킹 제임스 성경의 출간 목적 중 하나는 성경 역본을 통합하여(비숍, 제네바) 그런 영국 교회(성공회, 청교도)를 하나로 단결시키는 것이었다.

그에 비해 천주교에서, 특히 휘하 조직인 예수회에서 뜬금없이 영어 성경을 내놓은 목적은 개신교 진영에서 시작된 자국어 성경 번역 트렌드에 맞불을 놓고(counter-) 자기네 교리를 정당화하는 것이었다. 이것 때문에 지금까지 안 하던 짓을 어쩔 수 없이 한 셈이다.
그래서 거기에는 오늘날 천주교 성경에서도 수용하지 않는 오글거리는 왜곡 번역이 좀 있다. 본인이 아는 건 딱 두 가지이다.

• 창 3:15에서 여자의 씨가 뱀의 머리를 상하게 할 거라는 예언을 “여자”가 뱀의 머리를 상하게 할 거라고 바꿨다.
• 눅 1:28에서 천사가 마리아에게 하는 말은 원래 “큰 은총을 입은 자여”(피동)라는 요지인데.. 그걸 “은혜가 가득한 자여”(능동)라고 바꿨다.

마리아를 신격화하기 위해서 번역을 저렇게 한 것이다. 저 시절에 저렇게 뜯어고치는 건 우리로 치면 일제 시대에 손 기정 선수 사진에서 복부의 일장기를 뽀샵질로 일부러 지우는 것과 비슷한 의미가 있지 않았을까 싶다.

본인은 킹 제임스 성경 유일주의자로서 천주교는 성경을 금지하고 없애고 신자들을 죽이고 성경 변개에 일조한 집단 정도로나 알고 있었다. 자기 교리를 위해서 말을 버젓이 뜯어고친 듀에이-림즈 역본이야 더 볼 것도 없는 부패한 성서이고 말이다.

지금도 그 신념은 크게 바뀌지 않았다. 다만, 총론을 넘어 세부적인 각론으로 들어가면 이런 성경에도 의외의 면모가 있다는 것을 근래에야 발견했기에 몇 가지 예를 완전성 차원에서 이 글을 통해 소개하고자 한다.

듀에이-림즈(DRB)는 만들어진 시기가 시기이다 보니 킹 제임스와 마찬가지로 고어체이며 thou, thee, -eth 같은 대명사와 접사를 볼 수 있다. 그건 그렇다 치는데.. 가장 먼저 골 1:14를 펴 보자.
변개된 역본에서는 “그분의 피로 through his blood”가 삭제되었다고 킹 제임스 유일주의자들이 으시대는 구절이기도 하다. 그런데...

In whom we have redemption through his blood, the remission of sins:

본인은 눈을 의심했다. 존재할 거라고 꿈에도 생각하지 않았던 through his blood가 DRB에서도 살아 있었다. 아니 이거, 마리아 숭배를 조장하던 그 역본이 맞나?
오히려 개신교 계열이며 천주교에서 과거에 시신을 부관참시했고 오늘날까지도 싫어하고 이단시하고 있는 위클리프.. 그 사람이 만들었던 옛날 성경(WYC)에는 through his blood가 없다.

in whom we have again-buying and remission of sins.

그건 이해가 된다. 위클리프 성경은 DRB보다 200년 가까이 전, 이 성계가 살아 있고 조선이 건국되었던 1390년대에 그 시절 여건의 한계상 ‘변개된 본문 계열’인 제롬의 라틴 벌게이트에서 번역됐기 때문이다.

호기심이 발동하여 요 1:18도 찾아봤다. 무려 초대 교회 시절 오리겐 때 ‘독생하신 아들(son)’이 ‘독생하신 하나님(God)’으로 바뀌었다고 들었기 때문이다.

… the only begotten Son who is in the bosom of the Father, he hath declared him. (DRB)
… but the one begotten Son, that is in the bosom of the Father, he hath told out. (WYC)

어라? 위클리프와 듀에이 모두 ‘아들’이라고 돼 있고 결과적으로는 KJV와도 일치한다. 오히려 개역, NIV, NASV 같은 20세기 역본들이 ‘하나님’이라고 표현하고 있다. 뭔가 혼란이 느껴지기 시작했다.

For three be, that give witnessing in heaven, the Father, the Son, and the Holy Ghost; and these three be one. (WYC)
And there are Three who give testimony in heaven, the Father, the Word, and the Holy Ghost. And these three are one. (DRB)

혼란에 결정타를 날린 것은 요일 5:7이었다. “하늘에서 증거하는 세 분이 계시니…”라고 KJV의 우수성을 입증하는 구절, 원래는 없었다가 후대에 첨가된 거라고 잔뜩 공격받는 그 구절이 위클리프와 듀에이에 모두 버젓이 시퍼렇게 살아 있었다.

서로 죽고 죽이고 못 잡아먹어서 안달이던 양 진영에서 각각 내놓은 성경이 진술이 이 정도로 일치한다면 이건 완벽한 교차검증 성공이지 않은가? KJV를 만들 때 성공회 팀과 청교도 팀이 눈에 불을 켜고 상호 검증하던 것을 뺨치는 수준이다.

따로 소개하지는 않지만 DRB는 사 14:12에 루시퍼도 남아 있고 계 2:13에서 사탄의 왕좌 대신 자리라고 KJV 스타일로 되어 있었다. 이 정도면 DRB만 욕하기가 민망하고 미안해질 정도였다. 이래서 뭐든지 양쪽의 말을 다 들어 보고 팩트 확인을 꼼꼼히 해야 되는구나..

뭐 그래도 벧전 2:2에서는 서로 제 갈 길 가는지 DRB는 변개된 “구원에 이르도록 자라라”이고, WYC는 어째 KJV에 더 가까운 스타일로 번역되었다.

As newborn babes, desire the rational milk without guile, that thereby you may grow unto salvation. (DRB)
as now born young children, reasonable, without guile, covet ye milk [of full teaching], that in it ye wax into health; (WYC)

다시 말해 골 1:14와 벧전 2:2를 비교해 보면 KJV는 OO, 개역 NIV 따위는 XX인데.. DRB는 OX요, 위클리프는 XO인 셈이다.
본인은 세상의 모든 성경은 OO 타입 아니면 XX 타입이지, OX나 XO 타입이 존재할 거라고 생각하지는 않았었다. 그런데 옛날에는 그런 중간형이 존재했던 모양이다.

어찌된 일일까? 이런 사실은 요즘 같은 인터넷 시대에 5분만 관심을 갖고 검색해 보면 알 수 있는데 나도 왜 지금까지 몰랐을까? 뭐, 킹 제임스 지지자건 반대자건 별로 관심을 갖지 않는 회색지대 영역이어서 그런 것 같다.

하지만 너무 어렵게 생각할 것 없다. 위의 사실은 가톨릭 쪽이든 개신교 쪽이든, 성경이 필사되고 전수된 과정이 모 아니면 도 하나로 언제나 딱 깔끔하게 떨어지지 않았음을 보여줄 뿐이다.
그게 그나마 긍정적인 쪽으로(OO) 크게 교통 정리가 된 건 에라스무스의 공인 본문 정립이다. 그리고 이를 대적하기 위해서 부정적인 쪽으로(XX) 크게 교통 정리가 된 것은 19세기 말의 웨스트코트와 호르트의 본문과 RV 역본이다.

16세기에는 요일 5:7에 실제로 “하늘에서 증거하시는 세 분”이 기록돼 있었나, 마가복음의 마지막 열두 구절이 진짜로 기록돼 있었나 하는 것은 전혀 관심사가 아니었다. 그건 웨스트코트와 호르트 이래로 본문비평이라고.. 성경 변개를 학술적으로 합리화하려는 수작 하에서 근현대에 와서야 제기된 낭설이다.

종교 개혁으로 인해 천주교와 개신교 사이에 반목과 대립이 심하던 16세기에 진짜 중요했던 것은 “성경에 외경--가톨릭에서 제2경전이라고 부르는--을 넣을 것인가? 넣는다면 구약의 일부로서 embed시킬 것인가 아니면 부록으로 별도로 넣을 것인가?”였다. 천주교 식이라면 토비트, 유딧, 에스드라, 마카베오 같은 책도 구약에 자연스럽게 포함되어 있을 것이고, 에스더기는 10장 3절 이후로도 계속되어 무려 16장까지 있게 된다.

킹 제임스조차도 당대의 관행과 종교적 영향력을 무시할 수 없었기 때문에 초기에는 외경이 포함되어 나왔다. 그러나 성경 본문은 절대 아니고 구약으로부터 분리된 부록 형태로 수록되었다. 그 시절엔 이것만으로도 엄청난 신의 한 수 파격이었고 교황 추종자들로부터 밉보일 짓이었으며, 최악의 경우 번역자들이 신변의 위협을 겪고 암살 당할 수도 있었다.

위의 사진은(☞ 출처) 1611년도 KJV 원판에서 외경의 한 페이지이다. 보다시피.. 에스더기만 해도 10장 4절부터 시작되는 외경 영역은 완전히 분리해서 수록하지 않았는가? The rest of the chapters of the book of Esther, which are found neither in the Hebrew, nor in the Calde라고 말이다. 세상에 그 어떤 천주교 성경도 에스더기 뒷부분을 이딴 식으로 편집해서 수록하지 않는다.

그럼에도 불구하고 반가톨릭 정신이 너무 투철한 일부 사람들은 KJV도 외경이 들어갔기 때문에 친가톨릭 성경이라고 비판하고 1611년판이 아니라 1655년인가 뭔가 외경이 완전히 제외된 KJV가 진짜 KJV라는 식으로 주장한다. 그건 역사에 대한 무지의 소치이며, 별 영양가 없는 소리에 지나지 않는다.

얘기가 길어졌으니 슬슬 정리를 하겠다.
본인은 KJV 유일주의자로서 가톨릭이 성경과 관련하여 부정적인 기여를 한 것을 다음과 같이 다섯 가지 독립된 분야로 요약하겠다.

1. (과거) 가장 먼저 옛날에야 일반인들에게 성경의 소지를 금하고 번역도 금하고.. 자기들 말고는 성경에 접근하는 사람들을 죽이고 실물을 불태웠다.
차라리 이단도 생기고 온갖 교단 교파들로 찢어지는 한이 있어도 수많은 지역 교회들이 잡초처럼 생겨나는 것이 성경적이지, 저기 같은 피라미드 중앙 집권 체계는 성경적인 교회 모델이 아니다. 뭐 지금이야 시대가 바뀌어서 쟤들도 물리적인 박해는 못 한다.

2. 오리겐 같은 옛날 사람들이 조금씩 독소를 넣고 변개해 놓은 일명 알렉산드리아 원문을 토대로 변개된 라틴어 본문을 만들었다.
하지만 옛날에는 사람들에게 성경에 대한 물리적 접근성 자체가 너무 낮았기 때문에 그 당시엔 본문 변개의 여파가 그리 크지 않았다. 그렇기에 DRB에도 올바른 다수 사본의 영향을 받은 맞는 표현도 여럿 등장했던 것이다.

3. 구약 성경에다 외경을 추가해 넣고, 십계명을 고쳤다. 이건 오늘날 개신교 쪽의 변개된 성경에서도 따르지 않는 사항이니 골 1:14, 벧전 2:2 같은 변개하고는 성격이 좀 다르다.

4. (과거) 한때 DRB 같은 마리아 숭배용 엽기적인 역본도 만들었다. 물론 오늘날은 천주교 성경에서도 그런 식으로 번역을 하지는 않으니 저건 흑역사가 되었다.

5. 그리고.. 옛날 성경에서 O를 확실하게 X로 몽땅 바꾼 개정판을 만들고, 20세기 이래로 모든 성경들의 번역 트렌드가 이걸 따라가게 만들었다. 2에다가 학문적인 근거(?)를 추가해서 그 영향력을 소위 기독교계 전체에 파급시킨 것이다.

본인은 이번 리서치를 통해서 2와 5를 더 명확하게 구분하게 되었다.
요일 5:7이 원래는 없다가 후대에 추가됐네 이딴 소리들은 2가 아니라 5의 산물인 것이다. 그놈의 후대라는 건 도대체 정확하게 언제쯤 후대를 가리키는 걸까?

사실, 논리를 더 명확하게 세우려면 천주교에서는 DRB 이후로 어떤 영어 성경을 사용해 왔는지를 알아야 할 것 같다. 개신교계가 KJV를 300년 가까이 사용하다가 갑자기 19세기 말부터 RV, ASV의 순으로 부패가 시작됐는데 저쪽도 DRB를 천주교계의 KJV마냥 수백 년 사용하다가 성경이 바뀌었는지?

1970년대에 나온 천주교용 NAB (New American Bible)은 이미 변개된 XX 스타일로 다 바뀌었다. 개신교가 이미 변개의 영향을 받기 시작했는데 가톨릭에도 그런 변화가 없었을 리가 없다.
사실 본인은 공동번역 성서가 나오기 전에 한국 천주교에서는 무슨 성경을 사용했는지도 솔직히 모르겠다. 설마 개신교 쪽 성경을 봤을 리는 없을 테고, 아니면 아예 성경 없이 교리문답서만 보고 살았는가?

적장은 적장을 알아본다고 가톨릭은 오늘날도 위클리프나 루터나 틴데일이나 킹 제임스 성경에 대해서는 당연히 절대로 호의적으로 말하지 않는다. 지금이 옛날 같은 종교 재판, 이단 심문 같은 게 존재하지는 않으며 다들 평화니 화합이니 하고 있지만.. 결국 교리와 믿음이 다른 것은 다른 것이다. 그 차이점이 어디에서부터 시작되었는지는 종교를 가진 사람이라면 분명히 알아야 할 것으로 보인다.
하나님이 십계명을 두 버전으로 주셨을 리는 없지 않겠는가 말이다. 둘 다 옳을 수는 없다.

가톨릭의 듀에이-림즈는 현재 가톨릭에서도 사용하지 않는 골동품이지만, 기독교의 킹 제임스 성경은 오류가 없는 최종 권위 말씀이며 하나님께서 말씀 보존 약속을 이행해 주신 바로 그 실물이다. 아멘.

• 종교 개혁의 불모지이고 예수회의 본산지이던 스페인에도 그래도 ‘레이나-발레라’라고 바른 계보의 성경 역본이 있다. 요일 5:7을 찾기가 생각보다 어렵지 않다. 얘는 누가 언제 어떤 계기로 번역한 것인지 궁금해진다. 한국은 1990년대가 돼서야 바른 계보 번역 성경이 나왔는걸..;;
• 우리 진영 교회사에서는 맨날 사악한 가해자, 거의 공산주의자 급의 종교 공작원이라고 묘사되는 예수회가 일본에서는 박해받은 ‘기리시탄’이라고 불렸다는 게 굉장히 아이러니하다. 중세 일본에서 사용했던 예수쟁이 식별법 중엔.. 나 같은 사람이라면 굳이 걸려들지 않았을 방법도 있다. 형상에 대한 인식의 차이 때문에 그렇다.

Posted by 사무엘

1.

• "즉시 그(바울)의 눈에서 비늘 같은 것이 떨어지고 그가 곧 시력을 받으니라. 그가 일어나 침례를 받고" (행 9:18)

요즘 scale이라고 하면 크기, 규모라는 뜻이 더 와닿지만 scale에는 비늘이라는 뜻도 있다. (동음이의)
구약 성경의 율법에서 포유류는 굽과 되새김질 여부가 식용 가능 여부를 결정한다면, 어류는 비늘과 지느러미의 존재 여부가 그 역할을 한다.
아울러, 사전을 찾아보면 피부병 딱지, 갑옷의 미늘, 물통 안에 낀 물때 같은 것도 다 저 scale이다.

치아 스케일링은 치아 주변에서 저런 비늘처럼 덕지덕지 붙은 치석을 떼어낸다는 뜻이다. 무슨 크기 조절과 관련된 뜻이 아니다.
그러니 사실 descale이라고 해야 말이 더 정확할 것이다. 컴퓨터 저장 장치에서 defragment, 비행기에서 deicing처럼 말이다. 뭔가를 제거하여 정리한다는 뜻의 단어에는 대체로 접두사 de-가 붙어 있다.
다만, void/be devoid of, press/depress 이런 관계를 생각해 보면 de-가 언제나 뒤의 어근을 없애거나 부정하는 것 같지도 않다.

2.
기왕 말이 나온 김에 성경을 더 찾아보면, 예수님이 행하신 기적 중에 눈먼 사람에게 시력을 되찾아 준 것이 여럿 나온다.
예수님이 당하신 고난 중에는 남이 뱉은 침을 맞는 극도의 치욕· 모욕이 있었다. 그런데 반대로 예수님도 침을 뱉으신 적이 있다. 두 번인데.. 모두 다 맹인의 눈을 고치실 때이다. 치과 다음으로는 안과 얘기네..

• "그분께서 그 눈먼 사람의 손을 잡고 그를 고을 밖으로 데리고 나가사 그의 눈에 침을 뱉으시며 그에게 안수하시고 그가 무엇을 보는지 그에게 물으시니" (막 8:23)
  
• "이렇게 말씀하시고는 그분께서 땅에 침을 뱉고 침으로 진흙을 이겨 그 눈먼 사람의 눈에 진흙을 바르시며" (요 9:6)

모욕하고는 억만 광년 떨어진 정반대 일을 하는 상황이었음을 알 수 있다.

3.
구약 외경 중에 토비트.. 개역성경식 외래어 표기법이라면 아마 '도빗' 정도 됐을 사람의 이야기가 있다.
이 사람은 놀랍게도 공중에서 떨어진 새똥(정확히는 참새의..)을 눈에다가 정통으로 맞는 바람에 눈에 막 같은 게 끼고 시력을 완전히 잃었다고 한다. 그리고 나중에 결말부에서는 물고기의 쓸개를 환부에다 발라서 눈을 치료받는다.

눈 영양제 '토비콤'의 이름이 혹시 토비트에서 유래된 게 아닐까? 안국 약품의 창업주나 중역 중에 혹시 가톨릭 신자가 있나.. 라고 나만 생각한 건 아닌 것 같다. 그냥 추측이다.

Posted by 사무엘

* 운전자용 호신술은 흔히 "방어 운전"이라고 일컬어지는 편이다.

1.
무단횡단을 하다가 달려오는 차와 마주치게 됐다면, 무리해서 길을 마저 건너려고 뛰어가거나 차를 피해 도망치지 마라. 차도 당신이 달려가는 쪽으로 회피 기동을 하다가 충돌 사고가 나기 십상이다.
0.5초 만에 완전히 도로 바깥으로 벗어날 수 있지 않고, 오는 차가 그리 크지도 않은 소형 승용차라면.. 차라리 그냥 가만히 서 있어라. 그러면 차가 당신을 알아서 피해 갈 것이다. 무단횡단자를 쳐도 이 나라는 과실 비율이 무단횡단자에게 엄청나게 유리하고, 운전자에게 엄청나게 불리하다. 차는 절대로 당신을 치지 않으려고 필사적으로 노력하게 마련이다.

2.
무단횡단이라는 건 인도와 차도의 구분이 있고 차선이나 중앙선도 그어졌을 정도로 최소한의 규모가 있는 도로에서 성립한다. 횡단보도가 있는 경우, 신호등이 있어서 빨간불일 때 건너면 무단횡단이 되지만 신호등이 없다면.. 그냥 보행자가 걸어다니는 빨간불이나 마찬가지이다.
차와 보행자가 어설프게 서로 눈치를 보는 상황이 됐다면.. 어영부영 있지 말고 보행자가 그냥 손 들고 과감하게 먼저 건너 가 버리는 게 운전자의 입장에서도 훨씬 더 낫다.

3.
2차로 도로 같은 데서 중앙선 침범 차량과 정면충돌 위기에 처했다면 각 차량이 자신의 진행 방향 기준 "오른쪽"으로 피하도록 하자. 이것도 상대방을 생각한답시고 서로 엇갈리는 방향(= 결과적으로 동일한 방향)으로 대피해 버리면 충돌을 피할 수 없게 된다.
하다못해 비행기도 마주오다가 관제 실수로 인해 동일 방향으로 회피해서 충돌 사고가 난 적이 있다. 자동차는 그런 관제를 받는 것도 없으니 운전자들이 자체적으로 일관된 매뉴얼을 갖춰야만 한다.

4.
무작정 피하는 것만이 능사가 아닐 때도 많다. 너무 놀라고 오버해서 급 핸들 조작을 하는 게 그냥 곧이곧대로 가면서 감속만 하다가 적당히 앞의 장애물을 들이받거나 측면 접촉사고를 내는 것보다 훨씬 더 큰 사고를 낼 수도 있다는 걸 유의하자. 좌우로 휘청거리다가 멀쩡한 옆차와 팀킬, 혹은 최악의 경우 중앙선 침범, 정면충돌, 보행자 치기 등... 비접촉 뺑소니 때문에 자기만 혼자 독박 쓰면 정신 건강에 굉장히 안 좋다.

5.
보행자건 운전자건 무단횡단이나 갑툭튀 칼치기로 인해 멀쩡히 잘 가던 남의 차를 급브레이크를 밟게 만들었으면 좀 미안한 줄 알고 최소한의 쏘리, 사과 비상등 같은 의사 표현을 해라.
차대 차의 경우 이것만으로도 분노 조절 장애로 인한 막장 보복운전 범죄를 상당수 예방할 수 있다. 이게 무슨 교통사고 과실 따지는 것도 아닌데.. 평생 다시 볼 일 없다시피할 사람에게 자기 실수 좀 인정하고 넘어간다고 해서 님하의 인생에 불이익이 돌아올 거 하나도 없다.

6.
어디서나 저속 차량은 제발 제일 구석의 n차로로 달리고, 추월은 "왼쪽"으로만 하게 왼쪽 차로를 비워 놓는 습관을 들여야 한다. 과속, 칼치기 차량보다 더 나쁜 차량은 자기보다 더 급한 차들의 정당한 추월을 방해하면서 남의 시간을 뺏고 우측 추월 칼치기를 강요하고 사고의 위험을 높이는 차들이다.

(* 우리가 차선이라는 말을 쓰는 대부분의 상황에서는 실제로 차선이 아니라 차로가 더 정확한 표현인 경우가 많다. 시간과 시각, 음정과 음고처럼 잘 혼동하는 용어이다.
"점선이냐 실선이냐, 색깔이 무엇이냐, 비 오는 날 밤엔 잘 안 보인다" 이럴 때 쓰는 말이 차선이고, 자동차가 진입하는 공간을 얘기할 때는 차로가 맞다.)

7.
보너스. 내가 급발진을 겪을 일이 생길지는 모르겠지만.. 만약 그런 일이 생긴다면..

1. 기어 중립 후 브레이크 꾸욱~~으로 통상적인 동력 차단과 제동 시도.
2. 그게 안 통하고, 조향 걱정이 없는 공간이 있다면 시동을 강제로 끄고 어떻게든 세운다. 비파괴적인 방법은 여기까지다.
3. 다음으로는 측면으로.. 길가 담벼락이나 가드레일을 긁으면서 차를 세우는 게 최선이다.
4. 그마저도 할 수 없다면 앞이 완벽하게 막힌 벽면이나 비슷한 체급의 차를 추돌해서 세운다. 측면 긁기보다 더 위험해지며, 에어백에 얼굴 파묻을 각오도 해야 한다.

단, 대형 트럭· 버스처럼 높은 차 또는 나무· 기둥 같은 단면이 좁은 물체를 들이받는 건 매우 위험하다.
최악의 경우는 어설프게 요리조리 피하면서 시간 끌고 차 속도를 실컷 키운 뒤에야 무엇이건 들이받는 것이다. 이런 상황에는 절대로 도달하지 않게 해야 한다.

8. 똑똑한 신호의 필요성

이제는 단순히 운전 습관을 넘어 신호와 교통 정책 쪽으로.. 뭐랄까 전술보다는 전략에 가까운 얘기를 좀 하겠다.

도로와 도로가 만나는 교차로에서 모든 방향이 차들로 터져 나간다면.. 각 방향별로 통행 신호를 일정 시간 동안 교대로 부여하는 것밖에 답이 없다. 하지만 차량 통행이 아주 적어진다면 저런 고전적인 신호 체계는 지나가는 차도 없는데 쓸데없는 신호 대기를 유발하고 효율이 매우 안 좋아진다.
이럴 때는 무작정 운전자에게 비합리적인 준법 정신을 무작정 열정페이마냥 강요할 게 아니라 다음과 같은 더 합리적인 방법을 찾아 나서야 한다.

• 점멸 신호: 서로 서행(황색) 내지 일시정지(적색) 의무를 지키면서 조심스럽게 통과하면 되지만, 사고의 위험이 아무래도 높다.
• 회전 교차로: 점멸 신호보다 안전하다는 장점이 있지만 처리 가능한 교통량에 큰 한계가 있다. 그리고 큰 도로에서는 적용하기 어렵다.
• 감응식 신호: 인적이 드문 횡단보도는 보행자가 버튼을 눌렀을 때에만 파란불 신호가 오게 돼 있다. 그것처럼 자동차 도로에도 차가 특정 자리에 진입해서 대기하고 있을 때만 잠시 후에 좌회전 신호가 오는 '감응식' 신호 교차로가 국내에 드물게 존재한다.

카메라라는 걸 맨날 차를 마음대로 못 움직이게 감시만 하는 데 쓰지 말고 이렇게 합리적인 용도로 활용하면 얼마나 좋나?
도로들이 궁극적으로는 이런 식으로 스마트하게 바뀌어야 효율과 안전이라는 토끼 두 마리를 모두 잡을 수 있으며 운전자에게 불만과 신호 위반의 충동을 억제시킬 수 있다.. 이런 알고리즘은 긴급 자동차의 주행 우선순위 조정 내지 자율주행 자동차의 동작과도 연계 가능할 것이다.

9. 좌회전 유도로에 대한 추억

과거의 도로 교통 정책은 제한된 공간에 차들을 최대한 많이 집어넣고 공간을 효율적으로 활용하려는 성향이 강했다. 고가 차도라든가 상· 하행 가변 차로..
그리고 신호 방식이 '직진 후 좌회전'인 +자형 교차로의 경우, |쪽이 직진일 때 좌회전 차들도 -쪽을 살짝 침범할 정도로 앞으로 미리 전진해서 신호를 기다리는 일명 '좌회전 유도 차로'라는 게 있기도 했다. (☞ 더 자세한 개념 설명)

그런 것들이 21세기에 와서는 몽땅 없어지고 단순화됐다. 고가 차도나 육교는 점점 철거되고 없어지는 추세이며, 상· 하행 가변 차로도 내가 알기로 이제 거의 전멸이다.

좌회전 유도 차로라는 것도 잘 활용하면 좌회전 신호 대기 차량이 직진 차량의 앞을 막는 현상을 완화하고 교차로의 통과 용량을 증가시키는 매우 좋은 효과가 있는데.. 활용하는 방법을 모르는 운전자가 많아서 부작용이 종종 발생하곤 했다.
직진 신호가 됐는데 좌회전 차들이 유도 차로로 진입하지 않는다거나, 심지어 자기 신호가 끝나자 유도 차로에서 멍청하게 서 버려서 -쪽 방향을 길막 하고 그쪽 운전자들로부터 경적과 욕 먹고.. ㅡ,.ㅡ;; 이 광경을 본인도 몇 차례 본 적이 있다.

어휴, 그러면 홍보를 더 해서 좌회전 유도 차로가 정착하게 했어야지.. 무식하게 없애 버리니 아쉽다. 과거 로드뷰를 보면.. 얘는 생각보다 늦은 2010년대 초에 등장했다가 16~17년 사이에 도로 없어진 것 같다.

10. 신호등은 교차로 건너편에 있는 게 보행자에게도 더 나음

그리고 끝으로.. 본인은 차들이 정지선 좀 침범해서 정지해도 괜찮으니, 교차로 신호등이 예전처럼 교차로 건너편에 있었으면 좋겠다. 오래된 생각이다.

그래야 (1) 보행자도 주변 차도들의 방향별 신호등 상태를 총체적으로 파악하고, 언제쯤 내 횡단보도의 신호등이 파란불이 될지, 이제 얼마나 더 기다리면 되는지를 얼추 예측하고 준비를 할 수 있기 때문이다. (물론 주변의 움직이는 차들이나 횡단보다 상태를 봐도 짐작 가능하지만, 신호등을 보는 게 더 편함. 특히 신호등엔 노란불이라는 중간 상태가 있으므로..)

왜 별 쓸데없는 걸 자꾸 바꾸는지 모르겠다.
더구나 신호등이 건너편에 있는 게.. 정지선 조금 몇 cm좀 초과한 것보다 훨씬 더 악질적인.. (2) '꼬리물기'를 잡아내는 용도로도 훨씬 더 좋다. 다 지나서 건너편에 도달할 때까지는 교차로를 완전히 통과한 게 아니기 때문이다.

난 21세기 들어서 자꾸 보행자 위주니, 대중교통 우대니 하면서 자꾸 자동차에 규제를 거는 식으로 정책이 바뀌는 게 전반적으로 마음에 안 든다. 특히 빌어먹을 속도 규제 말이다.
이놈들은 대중교통을 더 빠르고 편하게 만드는 것보다, 자가용 자동차를 찍어누르는 식으로 일을 추진하는 것의 비중이 훨씬 더 크기 때문이다. 공산주의자들이 평등을 다같이 부자를 만드는 식으로 실현하는 게 절대 아닌 것과 비슷한 이치이다.

그리 크지 않은 길에 한해서 모든 방향의 차도를 틀어막고 대각선 방향 횡단보도까지 파란불 신호를 주는 것까지는 좋다. 하지만 요즘 시내 속도를 너무 지나치게 낮추고 있으며, 시내와 고속도로를 불문하고 과속 단속 카메라가 너무 많다.
천호대교는 교량에까지 중앙 버스 전용 차로가 있는 유일한 예인 것 같은데.. 안 그래도 6차로밖에 안 되는 교량에다 왜 그런 짓을 했나 모르겠다.

거기에다가 희대의 악법인 민식이법은 막장의 정점을 찍었고.. 악질 음주운전 사망사고 가해자한테도, 졸다가 고속버스로 승용차를 짓밟아 뭉개서 앞날이 창창한 20대 탑승자 4명을 몽땅 몰살시킨 가해자한테도 선고된 적이 없는 형량이 구형되는 걸 보고 난 어이없음에 할 말을 잃었다. 애초에 시속 30km 초과 과속을 한 것도 전혀 아닌데..
이 정도면 진짜 적기 조례 시즌 2를 실현할 것으로 보인다. 애 부모라는 놈이.. 자기가 욕 먹으니까 이제는 국회 탓이나 하는 꼴이 정말 혐오스럽기 그지없어 보였다.

Posted by 사무엘

Windows에는 문자열을 입력받는 일반 에디트 컨트롤뿐만 아니라 글자마다 서로 다른 서식(글꼴, 크기, 진하게/이탤릭, 탭, 문단 정렬, 하이퍼링크..)을 주고 그림이나 표를 집어넣을 수도 있는 리치(rich) 에디트 컨트롤이라는 게 있다.

그야말로 소형 워드 프로세서가 통째로 윈도우 컴포넌트로 만들어진 셈이니 이건 굉장한 혁신이었다. 심지어 특정 용지 크기에 맞게 위지윅(장치 독립 레이아웃)을 지원하기 위해 기준으로 참조할 DC를 지정하는 기능도 있고.. 아예 윈도우 없이 에디팅 엔진의 동작만 뽑아서 쓰라고 windowless rich edit control이라는 라이브러리도 제공된다. 이 정도면 작정하고 굉장히 세심하게 만들어진 셈이다.
Windows의 기본 예제 프로그램 중 하나인 워드패드가 얘를 써서 만들어진 것으로 유명하며, 초창기에는 Visual C++에 워드패드의 소스가 통째로 제공되기도 했다.

얘의 내부 자료구조는 RTF라는 파일 포맷으로 제정되어서 마소뿐만 아니라 애플 같은 타 회사에서도 쓰기 시작했다. 단적인 예로 macOS의 TextEdit도 이 포맷을 지원한다.
다만, RTF는 HTML이라는 완벽한 상위 호환이 등장하면서 존재감이 굉장히 묻혀 버린 감이 있다. 당장 도움말만 해도 16비트 Windows 시절에는 RTF 기반의 hlp였지만 곧장 HTML 기반으로 대체됐으니 말이다.

상업용 워드 프로세서보다는 기능이 빈약해도 리치 에디트도 엄연히 워드 프로세서에 준하는 물건이니.. 얘는 단독으로 덩치가 굉장히 컸다. 공용 컨트롤 comctl32 패밀리의 멤버 형태로 제공되지 않았으며, 자신만의 전용 DLL과 버전업 체계를 갖추고 있다. 게다가 역사적으로 형태도 몇 차례 바뀌었다.

초창기 1.0은 riched32.dll이었고 윈도우의 공식 클래스 이름은 RICHEDIT였다. Windows 95와 함께 제공되었다.
그러다가 리치 에디트 2.0은 riched20.dll로 바뀌고 클래스 이름도 RichEdit20A 또는 W로 바뀌었다. 짐작하다시피 이때 유니코드가 최초로 지원되기 시작했고 다단계 undo도 지원되기 시작했다. 저 둘은 텍스트 에디터를 밑바닥부터 다시 만들어야 할 명분이 충분한 대공사가 맞다. 얘는 Windows 98과 함께 제공되었다.

나중에 Windows 2000/ME 타이밍 때는 3.0이 나왔는데, 3.0은 프로그래머의 입장에서 API가 바뀐 것이 전혀 없이 2.0을 상위 호환 명목으로 아주 부드럽고 자연스럽게 대체하게 됐다. 그리고 기존 1.0의 생성 요청조차도 그냥 3.0 엔진을 기반으로 호환성 모드로 동작하게 바뀌었다.
지금도 Windows의 system32 디렉터리를 가 보면 riched32.dll은 있긴 하지만 크기가 달랑 10KB밖에 되지 않는다. 실질적인 기능은 riched20.dll에서 수행되기 때문이다.

그랬는데 수 년 뒤, Windows XP sp1에서 리치 에디트 컨트롤은 형태가 또 바뀌었다. 목적은 TSF를 지원하기 위해서다. 얘 역시 내부의 모든 동작을 저 스펙에 맞게 수정해야 하는 엄청난 대공사였다.
얘는 모듈 이름이 영 생소한 msftedit.dll로 바뀌고, 버전도 공식적으로는 4.1이지만 클래스 이름은 RICHEDIT50W이라고 정해졌다. 어디서는 4.1이었다가 저기서는 5라고 표기하면서 혼란스럽다.

리치 에디트 컨트롤은 이렇게 두 번 격변을 거친 뒤에는 딱히 단절적인 변화 없이 지금까지 전해져 오고 있다. MFC에서는 리치 에디트 컨트롤을 초기화하는 AfxInitRichEdit() 계열의 전용 함수를 두고 있다. 2와 5가 붙은 버전도 있다.
그래도 일반적인 대화상자에서 리치 에디트 컨트롤을 집어넣어야 할 일은 그리 많지는 않을 것이며, 굳이 넣더라도 서식이 동원된 문서나 데이터를 “읽기 전용”으로 표시하기 위해서일 것이다.

Visual C++ IDE의 리소스 에디터가 지원하는 것은 버전 2 (사실상 3)에 머물러 있다. 굳이 버전 5를 집어넣으려면 custom control을 삽입해서 RICHEDIT50W를 수동으로 지정해야 한다.
그래도 Visual C++ 201x대의 최신 MFC는 CRichEditView 클래스에 대해 버전 5를 집어넣게 돼 있다. 하긴 4.1인지 5인지 최신 버전이 나온 지가 이미 10년이 넘었는데, 진작에 지원했어야지..

5.0의 가장 큰 존재 의의라 할 수 있는 TSF를 사용하기 위해서는 SES_USECTF 스타일을 지정하는 코드 단 한 줄만을 실행해 주면 된다. SendMessage(hRichEdit, EM_SETEDITSTYLE, SES_USECTF, SES_USECTF)
글쎄, TSF를 제대로 지원하려면 원래는 응용 프로그램에서 COM을 초기화하고 message loop에도 TSF 오브젝트에다가 선처리를 먼저 맡기는 등 해야 할 일이 많다. 이 때문에 날개셋 편집기는 TSF 사용 여부 옵션을 변경한 것이 프로그램을 재시작해야만 적용된다. 그걸 다 무시하고 일반 앱에서 이렇게 간단하게 TSF 지원이 정말 가능한지는 잘 모르겠다.

이걸 해 주면 리치 에디트 컨트롤에서 IME에서 단어 단위 한자 변환이 되며, 날개셋의 경우 다른 고급 특수 기능들도 모두 아무 제약 없이 사용할 수 있다.

그 밖에 리치 에디트 컨트롤이 사용 측면에서 기존 에디트 컨트롤과 다른 점은 다음과 같다.

• 기존 에디트 컨트롤은 단일 배열 버퍼 기반이지만 리치 에디트는 문자열의 연결 리스트 기반으로, 처음부터 대규모 텍스트 편집에 최적화돼 있다. Windows 9x 시절에는 기존 컨트롤은 편집 가능한 텍스트의 크기도 64K 남짓으로 제한돼 있었지만 리치는 그런 한계가 없다.
• 리치 에디트 컨트롤은 기존 에디트 컨트롤과 달리, 자체적인 우클릭 메뉴가 없다. 우클릭 이벤트 때 할 일은 전적으로 부모 윈도우의 동작에 달려 있다.
  
• 기존 에디트 컨트롤은 텍스트의 드래그 드롭을 지원하지 않지만 리치는 지원한다.
  
• 기존 컨트롤은 블록이 언제나 짙은 파랑 highlight색으로만 표시된다. 그러나 리치 에디트는 그냥 반전색 또는 요즘 유행인 옅은 파랑으로 표시되며, 사용자 정의를 할 수 있다.
  
• 리치는 트리플 클릭(3연타...)으로 텍스트 전체를 선택할 수 있다. 기존 컨트롤은 그런 동작이 지원되지 않는다.

서로 지향하는 목표와 설계 방식이 생각보다 많이 차이가 난다는 걸 알 수 있다. 에디트 컨트롤을 두 종류 따로 만들 만도 하다.
리치 에디트 컨트롤의 다른 사용법들이야 기존 문서를 참고하면 되니 여기서 다룰 필요가 없다. 이 글에서는 역사, TSF 지원, 그리고 한 가지 더.. 중요하지만 다른 문서에서 다루지 않는 특성을 하나 더 다룬 뒤 글을 맺도록 하겠다. 바로.. 경계 테두리이다.

리치 에디트 컨트롤은 공용 컨트롤 계열의 물건이 아니다. 그래서 그런지 공용 컨트롤 6 테마가 적용되었더라도 경계 테두리가 일반 에디트 컨트롤 같은 새끈한 모양으로 안 나오고 그냥 고전 테마의 투박한 모양으로 그려진다. 위의 스크린샷에서 보는 바와 같다. 어찌 된 영문일까? 답을 말하자면 상황이 좀 복잡하다.

윈도우 스타일 중에는 WS_BORDER (검고 가는 테두리), WS_DLGFRAME (버튼 같은 볼록 두툼한 테두리), WS_EX_CLIENTEDGE (오목 두툼한 테두리), WS_EX_STATICEDGE (오목 가는 테두리) 처럼 운영체제 차원에서 윈도우 주변에 non-client 영역을 확보하고 테두리를 치는 스타일들이 몇 가지 있다.

여기서 볼록이라 함은 좌측과 상단은 밝은 계열, 우측과 하단은 어두운 색인 테두리를 말하며, 오목은 순서가 그 반대이다. WS_DLGFRAME(볼록 테두리)을 지정하면 대부분의 다른 테두리 스타일들이 무시되지만, 그래도 WS_EX_CLIENTEDGE와 동시 지정은 가능하다. 그러면 꽤 흥미로운 테두리가 만들어진다. 이 역시 위의 스크린샷에서 묘사된 바와 같다.

이 테두리가 그려지는 모양은 테마의 적용 여부와 무관하게 언제나 동일하다. 그렇기 때문에 특별히 하는 일이 없다면 원래는 리치 에디트 컨트롤처럼 투박하게 그려지는 게 맞다.

테마가 적용된 공용 컨트롤 6들은 WS_EX_CLIENTEDGE(오목하고 두툼한 테두리)가 존재할 경우, WM_NCPAINT 메시지를 자체 처리하여 DrawThemeBackgroundEx 같은 theme API를 호출해서 테두리를 그린다. 자세히 보면 심지어 포커스를 받았을 때와 그렇지 않을 때 테두리 색깔이 달라지는 것도 확인할 수 있다. 하지만 리치 에디트 컨트롤은 저런 처리를 안 하기 때문에 테두리가 고전 테마 모양 그대로인 것이다.

그러니 컨트롤 자신이 테두리를 제대로 그리지 않으면 응용 프로그램이 강제로 그려 주는 수밖에.. 리치 에디트 컨트롤의 테두리 미관을 개선하려면 해당 컨트롤을 서브클래싱 해서 WM_NCPAINT 처리를 직접 하는 것 말고는 선택의 여지가 없다. 이것도 뭔가 운영체제 차원에서의 자동화 절차가 필요해 보인다.

본인이 이런 테두리 그리기와 관련해서 알게 된 굉장히 놀라운 사실이 있다.
오늘날 Windows에서 대화상자를 꺼내는 DialogBox, CreateDialog 계열 함수들은 대화상자 리소스에서 WS_BORDER이라고 지정된 스타일을 무시한다. 그걸 무조건 WS_EX_CLIENTEDGE로 치환해 버린다.

오목하고 두툼한 테두리는 대화상자 내부에서 사용자가 뭔가 아이템을 선택하고 문자를 입력하는 '작업 공간'을 나타내는 시각 피드백이다. 그에 비해 볼록/오목 효과가 없이 그냥 flat한 검정 단색 테두리(WS_BORDER)는 대화상자에 회색 입체 효과가 없던 Windows 3.x 시절 비주얼의 잔재로 여겨진 것이다.

어쩐지 옛날에도 WS_BORDER이랑 WS_EX_CLIENTEDGE가 차이가 없는 것 같았는데 그땐 그저 그러려니 하고 넘겼었다. 관계가 정확하게 저렇다는 걸 본인도 이제야 직접 조사해 보고 알게 됐다. 대부분의 경우 WS_BORDER는 그냥 WS_EX_CLIENTEDGE로 포워딩 되는 호환성 옵션으로 전락했다.

다만, 테마가 적용된 뒤에는 윈도우의 외형이 다시 옛날 같은 flat 스타일로 돌아간지라.. 검정 단색 테두리가 회색 단색 테두리로 바뀌었을 뿐이다. 그래서 볼록/오목 효과가 역으로 오래되고 촌스럽게 보이는 촌극이 빚어져 있다. 역사는 이런 식으로 돌고 돈다! =_=;;;

이상이다. 그러고 보니 리치 에디트는 최신 버전인 5(또는 4.1)에 대해 공용 컨트롤 6처럼 side-by-side assembly를 적용하는 게 충분히 일리가 있음에도 불구하고 전혀 그런 조치가 취해지지 않았다. 그렇기 때문에 얘는 사용자가 DLL과 윈도우 클래스 이름을 달리하는 원시적인 방법으로 버전 구분을 해야 한다.

즉, 리치 에디트는 Windows XP와 동시대에 개발됐음에도 불구하고 같이 개발되던 관련 신기술 두 종류와는 완전히 열외된 셈이다. (테두리 테마, SxS assembly) 아쉬운 대목이 아닐 수 없다. 리치 에디트 팀의 관심사에 든 XP의 신기술은 오로지 TSF뿐이었다.

본인이 개발한 날개셋 한글 입력기에도 자체 에디트 컨트롤과 텍스트 에디터가 있다. 먼 옛날에 2.x에서 3.0으로 넘어갈 때 프로그램이 내부 구조를 다 뜯어고치고 완전히 새로 개발되었는데, 이때 유니코드 기반, 다단계 undo, 그리고 TSF까지.. 리치 에디트 컨트롤이 1에서 2, 3에서 5로 갈 때의 공사를 몽땅 진행했다. 리치 에디트와 비슷하다면 비슷한 전철을 밟은 셈이다.

Posted by 사무엘

1. 호출과 사용

Windows API 중에는 IsBadWritePtr이라고 해서 주어진 포인터가 가리키는 메모리가 올바른지를 되돌리는 함수가 있다. 하지만 이 함수는 모든 경우를 맞게 판단하지 않을 뿐만 아니라 다른 코드에서 처리해야 하는 exception을 가로채서 다른 곳에서 문제를 일으킬 가능성을 높인다.

그리고 올바르지 않은 포인터가 발생했을 정도라면 이런 부류의 함수를 갖고 성공 여부를 어설프게 간보는 게 애초에 별 의미도 없다. 그 즉시 깔끔하게 뻗고 프로그램을 종료시키는 게 차라리 더 안전하며, 문제의 원인을 탐색하는 데도 더 도움이 된다.

이런 이유로 인해 과거에 the old new thing 블로그에서는 IsBadWritePtr should be called XXXX..라는 제목의 글이 올라왔는데, 본인은 제목의 진짜 의미를 파악하지 못해서 한동안 멈칫했다. 함수 이름 다음에 be called가 나오니 이 함수의 호출과 실행, 다시 말해 프로그래머가 이 함수를 사용하는 방법과 관련이 있는 제목인 줄 알았기 때문이다.

하지만 제목의 실제 의미는 그게 아니다. "IsBadWritePtr은 실제로는 XXX라는 이름으로 명명되었어야 한다. 하는 일이 '요게 잘못된 포인터인지 판단'이 아니라 그냥 '프로그램을 랜덤하게 뻗게 하라'이기 때문이다." 요게 제목의 의도이다.
하긴, Windows API 중에는 이름이 좀 므흣하게 지어진 게 내 기억으로 몇 가지 있다. 가령, IsDialogMessage는 동사가 Is가 아니라 Translate가 되는 게 훨씬 더 적절하다는 식으로 말이다.

call이 '명칭 부여'라는 뜻도 있고 '실행, 사용'이라는 뜻도 있다. 옛날에 GWBASIC의 Illegal function call이라는 에러 메시지가 한국어로는 "기능호출 사용이 잘못되었읍니다"라고 호출과 사용을 모두 넣어서 번역됐던 게 떠오른다.

2. 목적어가 자체 포함된 타동사

정확한 출처와 문맥은 기억이 안 난다만.. 본인은 어느 프로그래밍 라이브러리 문서에서 "The XXXX function does not return." 형태의 문장을 본 적이 있다. 언뜻 보기에는 이 함수가 실행이 끝나지 않고 무한루프에 빠진다는 말 같지만, 거기서의 의미는 그렇지 않았다. 저 함수는 그냥 리턴 타입이 void, 즉 리턴값이 없다는 뜻이었다.
이건 영어에서 마치 이런 식의 의미 차이를 보는 것 같다.

• I can't read. 난 문맹이다. (시력이나 조명에 문제가 있어서 못 읽는 게 아니라)
• XXXX is a word. 스크래블 게임 같은 데서, XXXX는 아무 글자 나열이 아니라 스펠링이 맞는 정식 단어이다.

read가 단독으로 '글을' 읽는다라는 뉘앙스를 포함하고 있고, word라고만 해도 자동으로 '올바른' 단어라는 뜻이 포함돼 있다.
사실, 이건 생소한 개념이 아니다. dream, design, sleep 같은 다른 동사도 마찬가지이며 얘들은 아예 명사도 된다. 심지어 dream a dream, design a design, sleep a sound sleep 같은 말도 의도적으로 쓰인다.

옛날 영어에서는 심지어 kill/slay, send 같은 타동사도 목적어를 생략한 채로 쓰였다는 것을 예전 글에서 언급한 바 있다. 그러니 굳이 murder이라고 안 쓰고 thou shalt not kill이라고만 해도 "살인하지 말지니라"가 된다.
return도 그런 식의 유도리 용례가 있는 것으로 보인다.

3. 한국어와 영어의 재귀 구조

한국어는 주어, 보어, 목적어, 부사어 등의 격이 체언 뒤에 달라붙는 온갖 조사들에 의해 구분된다. 어순에 의존하지 않고 격조사가 따로 존재하기 때문에 어순의 도치가 '비교적' 자유로운 편이다.
하지만 종결어미가 들어있는 서술어는 예외이다. 절대적으로 무조건 마지막에 와야 한다. 그리고 그 어떤 문장도 종결어미가 등장해서 말을 완전히 끝맺기 전에는 끝난 게 아니다.

이런 특성으로 인해 한국어를 외국어로서 공부하는 사람들 사이에서 한국어는 끝까지 들어 보지 않으면 뭔 말인지 도무지 종잡을 수 없는 스펙터클한 반전 언어라는 평이 지배적이다.
"내가 무릎을 꿇은 건 추진력을 얻기 위함이었다...는 소식이 나돈다..고 하지만 그건 사실이 아니다" ... 앞서 언급되었던 내용들이 막판에서 순식간에 전면 부정되거나 매트릭스 안에 들어가 버리기 때문이다. 이런 막장 어순을 영어로 실시간 동시 통역해야 한다면 통역자의 멘탈에 얼마 못 가 과부하가 걸릴 것이다.

이런 한국어와 달리, 영어는 SVO형 언어답게 보어건 목적어건 객체를 문장의 뒤에다 꽝 찍은 뒤, 그 객체를 수식하는 문구들이 관계대명사와 함께 꼬리에 꼬리를 물고 끝없이 이어질 수 있다. 즉, 뒤에 이어지는 말들은 앞의 문맥을 더 구체화하는 역할을 한다.
성경으로 치면 롬 8:1처럼 말이다. 그들은 정죄가 없는데 그들이란 바로 그리스도 예수 안에서 걷는 자들이고, 그런 자들은 육체가 아니라 성령을 따라 걷는다.. them, who가 말을 쭉쭉 이어 준다.

한국어는 저런 영어의 특기를 그대로 따라하기가 난감하다. 관형어가 체언의 뒤가 아니라 앞에 등장하며, 길이가 한없이 길어지기 어렵기 때문이다. 말을 저렇게 만들면 십중팔구 번역투가 돼 버리니.. 문장을 둘로 나누거나 어순을 재배치한다든가 해야 한다. 한국어에 가주어 it 같은 개념이 있지도 않으니 말이다.

한국어는 인용문 안에 또 인용이 등장하는 식으로 문장을 n중으로 안았다면 안은 문장을 끝내는 종결어미도 n중으로 역순으로 스택 pop 하듯이 나와 줘야 한다. 그래서 성경에도 “... 있나이다, 하라, 하고” (창 32:18) 같은 문장이 종종 등장한다.

영어는 그런 제약이 없다. 지금 문장이 몇 중으로 깊게 인용돼 있건, 끝나는 건 인용이 없을 때와 아무런 차이가 없다. 이는
if() for() for() while() ...; 과
if() { for() { for() { while() { ... } ... } ... } ... }
의 차이와도 비슷해 보인다.
혹은, 전자는 굳이 스택을 사용하지 않는 선형적인 최적화가 가능한 tail recursion 구조인 반면, 후자는 그렇지 않은 느낌?

지금까지 별 잡생각이 다 튀어나왔는데, 정리하고 결론을 내리자면 이렇다. 한국어와 영어는 말을 길게 이어 나갈 때 화자의 관점 내지 사고 전개 방식이 서로 근본적으로 다르다는 것이다.
어느 것이 구조적으로 더 나은지 굳이 우열을 따질 필요는 없을 것이다. 비트 배열 순서(엔디언)나 함수 인자 전달 방식에 절대적인 우열이 존재하지는 않을 테니 말이다.

단지, 언어간에 이런 차이점이 존재한다는 것을 염두에 둔다면 외국어 학습이나 자연스러운 번역에도 도움이 될 것이다. 그리고 차이점들을 프로그래밍 언어의 특성과 연계해서도 생각해 볼 수 있다는 게 이 글의 요지이다.

Posted by 사무엘

1. 경부선의 전철화

우리나라 최대의 간선 철도인 경부선은 다음과 같은 과정을 거쳐 전철화가 됐다.

(1) 1974년 8월 15일, 서울 지하철 1호선과 직통으로 수도권 전철 운행을 하기 위해 서울-수원 구간이 가장 먼저 전철화됐다. 하지만 이때 이후로 거의 30년 동안 추가적인 전철화는 전무했다. 뭐, 여기 대신 경부고속선을 따로 만들긴 했지만..

(2) 2003년 4월 30일, 수원에서 딱 두 정거장 더 남하한 수원-병점 구간이 전철화된 동시에 선형 개량과 2복선화도 같이 진행됐다. 원래 있던 선로 방향에는 병점 차량기지가 만들어졌으며, 회차를 위한 입체교차 선로도 같이 만들어졌다.

(3) 2004년 4월 1일, KTX의 운행을 위해 대전-옥천, 대구-부산 구간이 전철화됐다. 전용 고속선이 없기 때문에 기존선의 전철화부터 먼저 한 것이다.
옛날에 중앙선이 전구간 복선화를 할 여력이 도저히 안 되니 신호장이라도 늘리고 단선 전철화부터 한 것과 비슷한 맥락이라 하겠다. 거기는 힘이 더 좋은 전기 기관차를 투입하는 것만으로도 화물의 수송력을 끌어올릴 수 있었기 때문이다.

(4) 2005년 1월 20일, 병점-천안 구간이 전철화 및 2복선화됐다. 이제 수도권 전철 1호선이 수원과 오산, 평택을 넘어 천안까지 가게 되었다. 병점은 수원에서 그리 멀지 않은 데다 차량기지와 입체교차 시설 때문에 중요도가 높아서 2년 먼저 미리 개통했던 것이다.

(5) 2005년 3월 30일, 전철화된 근처의 충북선과 서울 방면의 연계 강화를 위해 천안-조치원 구간이 전철화됐다.

(6) 2005년 7월 1일, 충북선과 대전 방면의 연계 강화를 위해 조치원-대전 구간도 전철화됐다. 대전-제천 무궁화호에 전기 기관차를 투입할 수 있게 됐다.
하지만 이렇게 2005년에 천안 이남에서 전철화 과업은 앞의 광역전철이나 고속철처럼 여객의 관점에서 변화를 야기한 것이 없다 보니.. 존재감이 매우 미미하다. 잘 알려지거나 보도되지 않았기 때문에 지금 인터넷에서 관련 언론 보도를 거의 찾을 수 없다.

(7) 그리고 2006년 12월 7일, 대구-옥천이 산악 구간의 선형 개량과 함께 전철화됨으로써 경부선 441km 전구간이 전철화가 완료되었다. 선형 개량을 하면서 길이도 좀 짧아졌을 텐데 얼마나 개선됐는지는 딱히 자료를 못 찾겠다.
경부선의 전구간 전철화는 상징성이 크니 언론에서도 대대적으로 알리고 보도했었다. 이제야 중앙선뿐만 아니라 경부선 일반열차에서도 전기 기관차를 볼 수 있게 되었고, 오늘날 새마을호의 후신인 ITX-새마을 전동차도 다닐 수 있게 되었다.

경부선의 전구간 전철화 완료 이후 1주일 남짓 뒤인 12월 15일에 수도권 전철 1호선의 북쪽이 의정부북부에서 소요산까지 연장됐다는 것도 추가로 알아두면 좋다. 그리고 그로부터 또 2년 뒤인 2008년 12월 15일엔 남쪽 끝이 천안에서 또 연장되어 장항선의 신창까지 가게 됐다. 2009년 여름에는 그 이름도 유명한 누리로 전동차가 등장한다.

그 사이의 2008년 1월에 장항선과 군산선이 새 선로로 연결되었다. 거기 일대에 있는 세풍제지선이 한때 철덕들의 주목을 받았지만 비슷한 시기에 없어졌다. 그게 그 시절 그 지역의 주요 철도 역사이다.

2. 고속선의 개통

여기서 이야기를 끝내기에는 좀 짧으니, 기존선 말고 고속선도 살펴보면 이렇다.

• 2004년 4월 1일, 서울-대전-대구 (1차)
• 2010년 11월 1일, 대구-부산 (2차)
• 2015년 8월 1일, 대전과 대구 도심 구간까지

경부선 쪽은 이런 순서대로 완공됐다.
호남 고속철은 2015년 4월 2일에야 오송-광주송정 구간이 완공되어 1차 개통했으며, 광주송정에서 목포까지는 여전히 호남선 기존선 기반이다. 경부고속선이 대구까지만 개통했던 과거 시절과 상황이 비슷하다. 잔여 구간은 현재까지도 고속화 공사가 진행 중이며 앞으로 몇 년은 더 있어야 완료될 것 같다.

이제는 시속 300까지 밟지는 못해도 그래도 200 정도는 밟을 수 있는 준고속선이라는 개념도 생겨 있다. 경강선 내지, 개량된 전라선처럼 말이다.
참, 포항 쪽도 준고속선이 완공되어 호남선 개통과 같은 날에 KTX가 개통했다. 그쪽은 기존 동해남부선이 완전히 걷히고 기존 경주 역이 신경주 역으로 완전히 대체될 날만 남았다. 아울러 대구선과 중앙선 복선 전철화가 진행 중이다.

3. 2020년 상반기의 철도계 동향

(1) 경의선 수도권 전철화 구간이 문산을 넘어 드디어 임진강까지 연장됐다(3월 28일). 그 사이에 있던 임시승강장인 운천 역은 폐쇄되고 정식 역사가 지어지고 있으며, 문산-도라산 사이는 하루 4번 셔틀 열차만 왕래하고 있다.
이는 중앙선 끝의 지평 역에도 하루 단 4회만 열차가 운행되는 것과 처지가 같지는 않지만 비슷해 보인다. 경의중앙선의 양 끝에는 열차가 하루에 4회만 다니는 셈이다.

내년에는 도라산 역까지도 전철화가 되고 경원선도 소요산 이북의 연천까지 수도권 전철이 연장될 예정이니 더욱 기대된다. 그런데 단선 전철이라니..
경남 양산에서 건설 중인 경전철이 전국 최초의 단선 도시철도가 될 예정인데.. 경원선은 전국 최초의 단선 '중전철' 광역전철이라는 타이틀을 차지하게 되겠다.

(2) 지난 4월 1일부터 서울 지하철들의 새벽 1시 운행이 중단되고 막차 시간대가 자정으로 당겨졌다.
기억하는 분이 계신지 모르겠지만 이건 2002년, 이 명박 서울 시장 시절부터 행해진 것이다. 그 1시간 연장 운행 관행이 거의 18년 만에 무기한 중단되고 원래대로 돌아간 셈이다.

자동차에다가 비유하자면.. 일반인이 시속 200까지 밟을 일이라고는 현실에서 거의 없다. 그래도 시속 200까지 내는 고성능 차를 몰면 고속도로에서 시속 100~120쯤은 아주 가볍고 여유롭고 가뿐하게 달릴 수 있다.
그것처럼 열차가 막차가 1시이면 그 전의 자정 시간대엔 중간 주박역에서 끊어지지 않고 종점까지 쭉 가는 열차를 탈 수 있다. 열차의 막차 시각에는 이런 의미가 담겨 있다.

4. 참고: 철도역과 고속도로 나들목의 위상

어떤 지역에서 그 지역명을 그대로 딴 대표 철도역은 대체로 그 지역의 대표 행정기관(시청· 군청)과도 별 차이 없을 정도로 완전 시내 도심 중심부에 있는 편이다. 바다를 접하고 있는 부산과 인천이야 항구와 더 가까이 있지만, 그래도 수도 서울이나 대구 정도만 해도 시청과 철도역이 꽤 가까이 있다.

그 이유는 뭐.. 다방면으로 생각할 수 있다. 가장 단순하게는.. 철도가 개통하던 시절에는 전국 어디건 시가지의 크기가 지금보다 훨씬 작았기 때문일 것이다.
그때 기준으로는 철도가 좀 변두리 외곽에 만들어진 것인데도 나중에는 그 철길 주변도 역세권 버프를 받고 온통 개발되어, 결과적으로 도시의 중심부처럼 바뀌었을 수 있다. 서울 남산이 지금은 남쪽 끝의 산이 전혀 아니라 그냥 서울 중심부의 산으로 바뀌었듯이 말이다.

더구나 옛날에는 자동차가 지금처럼 보급돼 있지 않았으며, 승객을 철도역까지 연계하는 보조 대중교통이 충분치 못했다. 그러니 철도의 혜택을 입으려면 닥치고 최대한 역에 가까이 붙어서 살아야만 했다. 철도역이 도시의 중심이 될 수밖에 없었다.

이런 철도역과 달리, 고속도로 나들목은 이용 주체가 사람이 아니라 넘사벽 급의 수송력을 자랑하는 자동차이다. 여기는 애초에 일반 도로와 자동차 전용 도로를 구분하는 경계이기도 하다.
그렇기 때문에 고속도로 나들목은 태생적으로 도시의 외곽 변두리 끄트머리에 있는 게 자연스럽다. 고속도로 나들목 주변까지 온통 개발되고 건물로 뒤덮힌 경우는 수원 IC처럼 매우 드물다. 경인이나 외곽순환 고속도로 나들목 주변은 논외로 하더라도 말이다.

경부 고속도로가 처음 만들어지던 시절에는 사람들이 이런 개념조차 생소했다. 그래서 도시의 시장이라는 사람이 XXX 나들목을 자기 관할인 XXX 시의 도심 안으로 유치하겠다고 떼를 쓰는 웃지 못할 해프닝도 있었다.

그리고 요즘은 새로 만들어지거나 이설되는 철도역들도 마치 고속도로 나들목처럼 온통 외곽 변두리에 자리잡는 추세이다. 여기에는 여러 이유가 있다. 선로의 선형을 최대한 직선으로 만들려다 보니 기존 도심지를 경유할 수 없는 것, 그리고 굳이 간선 철도가 시가지를 대놓고 통과하지 않더라도 시가지와 철도를 연계해 주는 다른 교통수단이 충분하다는 것.

결국은 철도는 당장 역의 접근성이 떨어지는 것 같아도 고속화와 직선화로 대량 간선 수송에 충실하고, 단거리 연계는 다른 교통수단이나 도시철도가 담당하는 것이 시스템 전체의 교통 효율에 좋다는 것이다. 그러니 요즘 철도역들이 20세기의 철도역처럼 시내 깊숙히 들어와 있지 않고 외곽으로 멀어지는 것을 마냥 나쁘게만 보지 말고, 그 트렌드에 대해 어느 정도 적응할 필요가 있어 보인다.

Posted by 사무엘