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

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 사무엘

1. 관련 용어

빨강이라는 색이 있을 때 같이 나란히 쓰일 만한 보색으로는 노랑(경고의 수위), 검정, 파랑, 초록 등 여러가지가 있다.
그것처럼 성경 용어 내지 개념으로서 faith(믿음)와 대비될 만한 관련 용어로는 다음과 같은 것이 있다.

• 은혜(grace): 믿음에 의한 구원을 가능하게 하는 근간이다. 받을 자격이 없는 을에게 갑이 먼저 무료로 베풀어 주는 뭔가 좋은 것을 말한다. 엡 2:8은 saved by faith through grace라고 믿음과 은혜의 관계를 설명한다.
• 회개(repentance): 믿기 위해서 을에게 먼저 동반되어야 하는 심경의 변화, 유턴, 반전이다. 이전 글에서 논했듯이, 꼭 물리적인 나쁜짓을 그만둔 것만을 의미하지 않는다. 기독교는 믿지 않는 것도 죄라고 분명히 말한다. 그리고 문제의 본질을 진단하고 치료하지, 증상만 없애려 하지 않는다.
• 일, 행위(work): 정말 믿었다면 그 결과 겉으로 바뀌어 드러나는 행적을 말한다. 그럼에도 불구하고 인간에게 자유의지가 있고 믿음 분량의 차이가 있는 이상, 믿었다고 무조건 기계적으로 행위가 당장 나타나는 건 아니다. 또한 행위가 구원의 조건인 것은 더욱 아니다.
• 시인, 고백(confession): 자기가 믿는 것을 말로 표현하는 동작이다. 성경에는 "말과 혀로만 사랑하지 말라", "행위가 없는 믿음은 죽은 믿음" 같은 말씀이 있는데, 한편으로 문맥과 관점에 따라서는 입으로 시인하는 것만으로도 믿음의 열매인 행위나 마찬가지일 수 있다(롬 10:9-10).

2. 유사 용어

• faith는 뭔가 을이 갑에게 의지하는 종교적인 염원이 담긴 믿음을 말한다. "P와 NP는 아마도 같지 않을 것이다, 홀수 완전수나 65537 이후의 페르마 소수는 아마 전혀 존재하지 않을 것이라는 게 대다수 수학자들의 믿음이다." 이렇게 단순 추측에 가까운 믿음은 belief라고 하지 faith라고 지칭하지는 않는다.
• believing과 belief의 차이는 그리기와 그림의 차이와 비슷한 그냥 언어적인 차이일 뿐이고.. 성경에서 요한복음은 believe만 나오지 faith는 거의 등장하지 않는다.

3. 다양한 종류와 강도의 믿음

• 인간을 구원에 이르게 하는 회개와 믿음이 존재하고, 그 뒤에도 지속적인 회개와 믿음이 필요하다. 구원을 유지하기 위해서가 전혀 아니라, 하나님과 관계를 유지하고 바람직한 크리스천으로 살기 위해서이다. 예수님이 내 죄 사하려고 죽으시고 부활하셨다는 건 굳건히 믿지만, "주는 것이 받는 것보다 더 복되다, 먹은 것과 입을 것이 있는 것으로 만족하라"를 안/못 믿는 "구원받은 불신자"도 세상에 셀 수 없이 많다. (물론 그건 대외적으로나 자기 자신에게나 건전한 상태는 아님)
• 꼴랑 구원받는 회개와 믿음 하나만 갖고 평생 사는 것은 결혼한 부부가 연애와 신혼 시절의 콩깍지만 갖고 평생 사는 것과도 같은 무모하고 불가능한 짓이다. 구원받은 사람을 하나님이 왜 즉시 하늘나라로 데려 가시지 않는지를 잘 생각해 봐라.
• 그리고 믿음이 아직 작은 것하고, 믿음이 아예 없는 것, 죽은 믿음은 셋 다 다른 상태를 가리킨다. 세상에 그 어떤 고성능 자동차라도 정지 상태에서 3단, 4단 기어에서 곧장 출발할 수는 없다. 이걸 갖고 "그딴 식으로 할 거면 아예 때려쳐라" 식으로 남을 함부로 판단하고 정죄하지는 않아야 한다.

4. 성경에 나오는 정말 위대한 신앙고백들

성경에는 여러 인상적인 구절들이 있는데 그 중 신앙 고백과 관련하여 개인적으로 굉장히 대단하고 본받을 만하다고 생각하는 것을 몇 개 뽑으면 다음과 같다. 이걸 소개하면서 글을 맺는다.

(1) 욥: 알몸으로 태어났다가 죽어서도 알몸으로 돌아가는 게 인간 아닙니까? 모든 것을 주신 분도 하나님이고 도로 가져가신 분도 하나님입니다. 주의 이름이 찬송 받으옵소서.
(욥 1:21. 빌 게이츠 급의 플래티넘 수저 갑부이던 사람이 하루아침에 천재지변으로 전재산 다 풍비박산 나고 자녀 10명이 몽땅 몰살당한 뒤에..)

(2) 다니엘의 세 친구: 우리가 섬기는 하나님은 우리를 풀무불에서 능히 건져낼 능력이 있습니다. 설령 그분께서 “그리하지 않고” 우리에게 죽음을 허락하신다 할지라도 우리는 한 치의 고민 없이 폐하의 신을 섬기지 않을 것이며, 황금 형상에도 절을 하지 않을 것입니다.
(단 3:17-18. 노발대발한 느부갓네살 왕과 불타는 용광로 앞에서..)

(3) 백부장: 님하 같은 엄청난 분께서 굳이 누추한 저희 집에 오시겠다니요? ㅠㅠ 그럴 필요 없이 말씀만 한 마디 하시면 종의 병이 원격으로 치료될 겁니다. 저 같은 일개 중대장도 명령을 내리면 100여 명의 부하 군사들을 움직이게 할 수 있는데 하물며 님하이시겠습니까?
(마 8:8-9. 다시 생각해 봐도 예수님을 깜짝 놀라게 할 정도의 정말 대단한 논리와 믿음에 입각한 발언이 아닐 수 없다. 바리에이션으로 딸의 병을 원격으로 치료받은 어느 가나안 여인의 명대사도 있다. 마 15:27-28)

(4) 베드로: 님하는 그리스도이며 살아 계신 하나님의 아들이십니다!
(마 16:16. 특별히 역경 속에서 나온 말은 아니지만 그냥 내용 자체가 고퀄이어서)

Posted by 사무엘

1. 코드의 입체적 배치

C/C++에는 여느 프로그래밍 언어들과 마찬가지로 if else 조건문이란 게 있고 이게 여러 단계로 중첩될 수 있다. 단계가 깊어질수록 코드에서 들여쓰는 왼쪽 여백이 증가한다.

그런데 C/C++에는 전처리기 지시라는 것도 있어서 컴파일되는 실제 코드와는 완전히 별개의 다른 문맥과 차원에서 해석된다. 희곡에서 다른 코드들이 연극 대사라면 전처리기 지시는 괄호 안의 상황 설명지시와 비슷한 존재 같다. 결정적으로는 전처리기에도 조건부 컴파일을 지시하는 #if #else #endif 같은 물건이 있다.

전처리기의 #if도 여러 단계로 중첩되면 알아보기가 상당히 힘들어진다.
그러니 문득 드는 생각은.. 소스 코드의 들여쓰기도 3차원 입체로 표현 가능하면 어떨까 싶다. 통상적인 if else 등의 들여쓰기는 지금처럼 왼쪽 여백으로 표현하고, #if의 단계가 증가하면 그 부분의 코드가 몽땅 X, Y가 아닌 Z축으로.. 전방으로 한 단계 돌출되는 것이다. 해당 부분이 끝나면 다시 쑥 들어가고..
그러고 보니 전처리기 중에는 #if 말고도 #pragma pack처럼 스택 기반으로 설정을 저장하는 것들이 더 있기도 하다.

컴퓨터야 1차원적인 메모리 셀에서 코드와 데이터를 죽어라고 읽고 쓰고 계산하는 기계이겠지만, 그걸 기술하는 프로그램 코드라는 건 색깔(syntax coloring)과 XYZ 축 공간을 모두 이용해서 인간이 최대한 알아보기 편하게 시각화를 할 수 있다. 하지만 이런 수단을 몽땅 동원해도 남이 만든 코드는 선뜻 읽기가 어렵다.;;.

2. 컴파일러의 경고

C/C++ 코딩을 하다 보면 컴파일러가 뱉어 주는 경고 메시지의 도움을 종종 받곤 한다.
제일 자주 보는 건 아무래도 선언만 해 놓고 사용되지 않은 변수, 초기화하지 않고 사용한 변수, void형 함수가 아닌데 return으로 실행이 종료되는 구간 따위이다. 이런 건 에러로 치면 단순 스펠링 오타나 {}() 호응 미스, type mismatch만큼이나 흔하다. 아 하긴 type mismatch는 가벼운 건 warning 형태도 있긴 하다.

경고의 민감도를 상향 조정하면 if문에서 괄호 없이 대입(=) 연산자가 쓰인 것(혹시 비교 연산 ==이랑 헷갈린 거 아니냐?), 우선순위가 아리까리 한 << 나 & 같은 연산자가 괄호 없이 마구 섞여 쓰인 것, 심지어 for이나 if문이 뒷부분 없이 그냥 세미콜론으로 종결된 것까지도 실수가 아닌지 의심스럽다고 일단 지적해 주기도 한다.
글쎄, 컴파일러가 그 정도로 민감하다면.. 본인이 예전에도 언급한 적이 있지만 a=a++이나 a>>-2처럼 이식성이 없는(즉, 컴파일러마다 결과가 다를 수 있는 undefined behavior) 수식이야말로 안 쓰는 게 좋다고 경고를 띄워 줘야 하지 않나 싶다.

요즘 컴파일러는 printf/scanf에서 %문자와 실제 인지의 대응이 맞는지까지도 체크한다. printf 출력일 때는 float건 double이건 %f만 써도 충분하지만(float도 어차피 double로 값이 promote되므로), scanf 입력일 때는 둘은 %f와 %lf로 정확하게 구분돼야 한다.
가변 인자는 그야말로 type-safety의 완벽한 사각지대인데 이런 실수를 컴파일러가 잡아 준다면 프로그래머에게 굉장히 도움이 된다. 원래 전문적인 '정적 분석'용으로 쓰이는 함수의 인자별 annotation 정보까지 컴파일러가 활용하는 것 같다.

그런데 내가 지금까지 본 컴파일러 경고들 중 제일 계륵 같은 건 코드를 32비트에서 64비트로 포팅 하면서 생겨난 수많은.. type mismatch이지 싶다. 이제 int의 크기와 포인터의 크기가 일치하지 않게 되고, 덕분에 int와 INT_PTR의 구분이 생겼기 때문이다.
일단, 이 경고는 레거시 코드에서 발생하는 양이 어마어마하게 많은 편이다. 그리고 (1) 치명적인 것하고 (2) 그다지 치명적이지 않은 것이라는 분명한 구분이 존재한다.

int에다가 포인터를 곧장 대입하는 부분은 전자에 속한다. 이건 번거롭더라도 int를 당연히 INT_PTR로 바꿔 줘야 한다.
그러나 두 포인터의 차이를 대입하는 부분은 상대적으로 덜 치명적인 부분에 속한다. 왜냐 하면 64비트 환경이라 해도 작정하고 프로 연구자가 컴퓨터를 굴리는 게 아닌 한, 단순 end-user급에서 대놓고 2GB, 4GB를 넘는 데이터를 취급할 일은 거의 없다시피하기 때문이다.

특히 문자열의 길이를 구하는 strlen, wcslen 같은 함수 말이다. 리턴 타입이 size_t이지만.. 난 경고를 없애기 위해 그냥 대놓고 #define _strlen32(x) static_cast<int>(strlen(x)) 이런 것도 만들어서 썼다.
주변의 int 변수를 몽땅 확장하기에는 내 함수의 인자와 리턴값, 구조체 멤버 등 영향 받는 게 너무 많고 귀찮고, 그 반면 세상에 문자열 길이가 4GB를 넘어갈 일은 없기 때문이다.

대부분의 경우 무시해도 상관은 없지만 그래도 경고가 뜨는 게 마음에 걸리고, 그렇다고 기계적이고 무의미한 typecast 땜빵을 하고 싶지도 않으니.. 이건 64비트 컴퓨팅이 선사한 계륵 같은 경험이었다.

3. #include 절대경로 표시

요즘 개발툴 IDE, 에디터들은 코드에서 각종 명칭을 마우스로 가리키기만 하면 그게 선언된 곳이 어딘지를 친절하게 알려 준다. #define 매크로도 다 파악해서 이게 전개된 결과가 무엇인지도 툴팁 형태로 표시해 준다.
이와 관련해서 개인적으로는.. #include 다음에 이어지는 토큰을 마우스로 가리키고 있으면 얘가 무슨 파일을 가리키는지도 절대경로를 알려 주는 기능이 있으면 좋겠다. 이 파일을 여는 기능은 Visual Studio건 xcode건 이미 다 제공되고 있으니, 그렇게 알아낸 파일명을 가만히 표시만 해 주면 된다.

C/C++의 include 경로 찾기 규칙은 꽤나 복잡한 구석이 있기 때문이다. #define이 정의돼 있는 줄 모르고 삽질하는 것처럼, 예상하지 않은 다른 디렉터리에 있는 동명의 파일이 잘못 인클루드 되어 착오가 발생할 가능성이 있다.
이는 마치 경로를 생략하고 파일명만 달랑 입력했을 때 실행 파일 디렉터리를 탐색하는 순서라든가 LoadLibrary 함수가 DLL의 경로를 탐색하는 순서와도 비슷한 면모이다.

#include로 지정하는 경로는 C/C++ 문법의 지배를 받는 문자열 리터럴이 아니다. ""로 둘러싸기 때문에 문자열 리터럴처럼 보이지만 <>로 둘러싸는 것도 가능하고.. 여기서는 역슬래시 탈출문자가 적용되지 않기 때문에 디렉터리 구분자를 지정할 때 \를 번거롭게 두 번 쓸 필요도 없다. 애초에 #include는 컴파일러가 전혀 아닌 전처리기의 영역이니 당연한 소리인데.. 가끔은 당연한 사실이 당연하게 와 닿지가 않는다.

그런데 #include 경로명에다가 매크로 상수를 지정할 수는 있다. 내가 지금까지 이런 기괴한 용례를 본 건 지금까지 FreeType 라이브러리의 소스가 유일하다. IDE가 이런 것까지 다~~ 파악해서 실제로 인클루드 되는 헤더 파일을 사용자에게 알려준다면 코드를 분석하는 데 큰 도움이 될 것이다.

4. 리터럴 형태의 표현

프로그래밍 언어가 표현력이 좋으려면, 함수 코드든지 재귀성을 지난 복잡한 데이터든지(리스트, 배열 테이블 등) 불문하고 하나의 리터럴 내지 값(value)로 취급 가능하며, 굳이 이름을 붙여서 변수로 할당하지 않아도 함수 인자나 리턴값으로 자유자재로 주고 받고 대입 가능해야 한다.
쉽게 말해 함수 포인터가 들어갈 곳에 이렇게 함수 몸체가 곧장 들어갈 수 있어야 하며..

qsort(pData, nElem, nSize, [](const void *a, const void *b) { return 어쩌구저쩌구 } );

데이터가 들어갈 곳에도 이렇게 배열을 즉석에서 지정할 수 있어야 한다는 얘기이다.

memcpy(prime_tbl, {2,3,5,7, 11}, sizeof(int)*5);

하지만 C/C++은 이런 쪽의 유연한 표현력이 매우 취약했다.
함수 쪽은 machine word 하나에 딱 대응하는 것 이상의 context를 담은 추상적인 포인터를 지원하지 않는 관계로 클로저나 함수 안의 함수 따위를 지원하지 않는다.

그리고 언어 차원에서 복합 자료형을 built-in type으로 직접 지원하는 게 없다. 전부 프로그래머나 라이브러리의 구현에 의존하지..
그렇기 때문에 복잡한 데이터 리터럴은 변수를 초기화하는 이니셜라이저 형태로나 아주 제한적으로 표현 가능하며 이마저도 구조체· 배열의 초기화만으로 한정이다. 리터럴 형태 표현 가능한 배열 비스무리한 건 읽기 전용 null-terminated 문자열이 고작이다.

함수를 리터럴 형태로 표현하는 건 C++에 람다와 함수형 패러다임이 도입되면서 상황이 많이 나아졌다.
그 뒤 복합 자료형을 리터럴 형태로 표현하는 것도 C++1x 이후로 하루가 다르게 새로운 문법이 도입되면서 바뀌고 있긴 하다.

이름을 일일이 붙이지 않고 아무 테이블 및 계층 자료구조, 그리고 함수를 마음대로 선언해서 함수의 인자나 리턴값으로 주고받을 수 있는 것은..
마치 메신저나 이메일로 스크린샷 그림을 주고받을 때 매번 그림을 파일로 저장하고 그 파일을 선택하는 게 아니라 간단히 print screen + 클립보드 붙여넣기만으로 그림 첨부가 되는 것과 비슷하다. 의식의 흐름을 매우 편리하고 직관적으로 코딩으로 표현 가능하게 해 준다.

디자인 근본적인 차이로 인해 C++이 무슨 파이썬 수준의 유연함을 갖는 건 무리이겠지만 저 정도만으로도 엄청난 변화이며 한편으로 컴파일러를 구현하기에는 굉장히 난감할 것이다. 저수준 성능과 고수준 추상화 범용성이라는 두 모순되는 토끼를 몽땅 잡아야 하기 때문이다. 특히 그런 문법이 템플릿 내지 캐사기 auto와 결합하면.. 복잡도가 끔찍할 수준일 것 같다.

5. 기타

(1) 변수나 함수를 선언할 때는 type을 지정하면서 각종 modifier나 storage class를 같이 써 주게 된다. 거기에 들어가는 단어 중에는 static과 const, 그리고 int와 __declspec(..)처럼 대충 순서가 바뀌어도 되는 것이 있다.
그런데 long unsigned a도 된다는 것은 지난 20여 년 동안 본인이 한 번도 시도해 본 적이 없었다. 영어 어순 직관과 어울리지 않으니까.. 하긴, 2[a]도 되는 언어에서 저 정도쯤이야 이상할 게 없다.

(2) void main(void) {}은 컴파일은 되지만 void가 뭔가 권장되지 않고 바람직하지 않은 형태로 쓰이는 전형적인 예시라 하겠다. main 함수의 프로토타입도 그렇고, 또 함수에 인자가 없음을 나타낼 때는 C/C++ 가리지 않고 ()만 써도 충분하기 때문이다.

(3) 잘 실감이 나지 않겠지만 요즘은 C와 C++은 서로 따로 제 갈 길 가고 있다. 특히 C99와 C++1x부터 말이다. 그렇기 때문에 세월이 흐를수록 C 코드를 C++ 컴파일러에서 곧바로 돌리기는 어려워질 것이다.

보통은 C가 C++에 있던 // 주석, inline 키워드, C++ 라이브러리에 있는 몇몇 기능들을 자기 스타일로 도입하는 형태였지만 최신 C에서 C++과 무관하게 독자적으로 도입한 기능 중 하나는 restrict 키워드이다. 얘가 가리키는 메모리 주소는 딴 데서 건드리지 않으니 마음 놓고 최적화해도 된다는 일종의 힌트이다. volatile과는 반대 의미인 듯하다.

컴파일러에 따라서는 C++에서도 얘를 __restrict 이런 형태의 비표준 확장으로 도입한 경우가 있다. 하지만 Visual C++은 내가 알기로는 그리하지 않은 것 같다. 마소 컴파일러는 C 단독은 거의 없는 자식 취급하고 C99 지원도 안 하고 있으니 말이다.

(4) 방대한 C/C++ 코드에 정적 분석을 돌려 보면, 아무 type-safety 단서 없이 무데뽀로 아무 메모리에다 임의의 바이트만치 쓰기를 허용하는 memset, memcpy 계열의 함수에 실수와 버그가 들어간 경우가 생각보다 굉장히 많다고 한다.
배열 크기만큼 써야 하는데 포인터 크기(4/8바이트!)만치만 기록해 버리는 건 약과다. 둘째 인자와 셋째 인자의 순서가 바뀌어서 0을 기록하는 게 아니라 0바이트만치만 기록한다거나..;;

sizeof(A)*b라고 써야 할 것을 실수로 sizeof(A*b)라고 써 버려서 역시 4/8바이트 고정과 같은 효과가 나기도 한다. 전체 바이트 수를 써야 하는 곳과 배열의 원소 수만 써야 하는 곳을 헷갈리는 것도 미터나 피트 같은 단위를 헷갈려서 착오를 일으킨 것과 비슷하다.
문제는 저런 건 잘못 써도 언어 문법상으로는 아무 잘못이 없고 철저하게 합법이라는 것이다. 컴파일러가 잡아 주지 못하니 더 고차원적으로 문맥을 읽는 정적 분석에 의존해야 한다.

Posted by 사무엘

1.
내 개인적으로는 진정한 철덕이라면 일단 자기 팔이나 다리를 어느 정도 벌린 폭이 1435mm 표준궤인지 자 없어도 감을 잡고 있어야 한다고 생각한다.
그리고 폭과 무게와 차륜 크기가 동일한 사륜자전거를 타고 같은 힘으로 페달을 밟을 때,
철 바퀴로 레일을 달릴 때가 고무 바퀴로 아스팔트를 달릴 때보다 얼마나 더 매끄럽게 오랫동안 잘 나아가는지를 직감적으로 체득하고 있어야 한다고 본다.

그거야말로 철도의 존재 이유와 당위성을 설명하는 본질적인 현상이기 때문이다.
전통적인 철도가 바퀴의 마찰을 줄여서 효율을 올렸다면, 미래의 궤도 교통수단은 자기 부상 방식으로 전기 저항과 마찰을 더 줄이고, 더 나아가서는 전용 터널에서 공기 저항까지 극복해서 극도의 효율과 속도를 실현해야 하지 않을까 싶다.

2.
체코의 드보르작뿐만 아니라 프랑스에도 아르튀르 오네게르라고 아주 열혈 철덕 작곡가가 있었다.
아아.. 프랑스는 100년 전 20세기 초에도 “퍼시픽 231”이라고 증기로 이미 시속 120km를 찍었던 고속열차를 개발한 바 있다. 그리고 저 사람은 그 열차에 감탄해서 동명의 교향곡도 만들었다. 우리나라에서 달렸던 ‘파시’ 증기 기관차하고는 태평양이라는 이름의 어원만 동일할 뿐, 기술적으로는 관계 없다.

드보르작은 자기가 인생을 다시 살아서 증기 기관차의 제작자가 될 수만 있다면 자신의 음악 커리어와 교향곡쯤은 몽땅 포기할 의향이 있다고 말한 바 있는데.. 저 사람도 만만찮다~!!

3.
철도가 없던 시절의 역사 암기는 정말 고문이 따로 없다. 국사 시험 도대체 어떻게 치냐..?? ㅠㅠㅠ
근현대 이전의 역사는 역사가 아닌 것 같다. -_-;;

태정태세 문단세 이런 건 죽어라고 안 외워지지만.
1899년 9월 18일 제물포-노량진 경인선, 1905년 1월 1일 경부선, 1908년 4월 경의선, 1914년 호남선, ...
1946년 해방자호, 1955년 통일호, 1960년 무궁화호, 1969년 관광호, 1974년 새마을호와 서울 지하철 1호선,
1981년 경부선 서울-수원 2복선, 1980~1984년 서울 지하철 2호선, 부산 지하철 1호선 등등등등등...은
머리 뇌세포에 오일이 발라지기라도 했는지 날짜와 연표가 그냥 술술술 외워진다.

이게 바로 한강의 기적..이 아니라 Looking for you의 기적이다.
오늘도 철도님 사랑합니다.

Posted by 사무엘

구한말 의병이 토벌된 이후로 일제 시대에 무력을 사용한 항일 독립운동 분야의 최초 원조는 (1) 이토 히로부미를 저격한 안 중근이라고 봐야 할 것이다. 한일합방보다도 전이니 독보적인 원조이다.
그 뒤 한 10년 정도 일제의 무단 통치를 경험하고 3· 1 운동까지 진압된 걸 보니, 일제를 상대로 테러와 게릴라전을 동원해서 계란으로 바위 치기라도 해야겠다는 생각을 하는 사람이 나타났고.. 1919년 말에는 김 원봉의 주도로 의열단이라는 게 생겼다.

아, 의열단보다 근소하게 전인 1919년 9월엔.. (2) 사이토 마코토 총독을 향해 폭탄을 던진 강 우규가 등장했다. 하지만 이건 실패했다. 그는 현장을 탈출하는 것까지는 성공했지만, 나중에 같은 조선인의 밀고로 체포되어서 조선인 형사에게 취조를 받는 안타까운 일을 당했다. 이후 사형 선고를 받고 서대문 형무소에서 순국했다.

그래도 사이토 총독의 입장에서는 3· 1 운동이라는 대형 사고가 터졌었지, 게다가 부임 당일에 자기 목을 노린 폭탄 의거까지 벌어졌지.. 당장은 이빨과 발톱을 감추고 민심을 달래야만 했다. 괜히 문화 정책을 편 게 아니었다. 통치 양상이 더 교묘해질 수밖에 없었다.

의열단이 벌인 최초의 거사는 (3) 부산 경찰서를 노린 박 재혁이었다. 1920년 9월, 폭탄을 터뜨려서 경찰서장을 살해하는 데 성공했지만 자신도 다친 채로 체포됐고 옥중에서 단식 자결했다. 당시 경찰서장이 중국 고전 덕후라는 정보가 있어서 그는 중국인 고서 상인으로 위장해서 들어갔었다.

그 뒤 1920년대 초중반엔 본토 밖에서는 독립군이 활동했고, 본토 안 서울에서 권총과 폭탄을 쥔 의열단의 리즈 시절이 잠깐 벌어졌다.

(4) 김 익상은 일본인 전기 기사로 변장해서 1921년에 무려 조선총독부 청사 안으로 잠입하는 데 성공했다. 폭탄을 몇 군데 투척해서 터뜨리긴 했지만 불발탄도 있었고 유의미한 인명 살상 목표를 달성하지는 못했다.
그래도 자신도 변장 잘하고 일본어를 유창히 구사한 덕분에 안 잡히고 무사히 탈출했다.

의열단에서는 거기까지 들어갔다가 살아서 돌아온 게 참으로 용한데, 이제 그만 은퇴하고 니 인생 즐기라고 그에게 권유했다. 그는 그 제안을 거절하고 이듬해에 일본의 육군 대장(다나카 기이치)을 암살하러 동지 2명과 함께 상하이에 갔으나.. 여기서도 권총 사격과 폭탄 모두 지독하게 타이밍이 맞지 않았다. 이들은 임무에 실패한 채 모두 붙잡히고 말았다.

김 익상은 뭔가 유의미한 1차 목표를 달성하지는 못했지만 무장 항일 독립운동 역사상 조선총독부 내부에 대놓고 침투해서 저만치라도 타격했던 전무후무한 인물이다. 2차 의거 때도 사형은 면했지만 1943년까지 일제 시대 기간 대부분과 자기 2, 30대 나이를 몽땅 감방에서 보내게 됐다. 명목상 석방된 뒤에도 일제로부터 감시를 받다가 또 다시 쥐도 새도 모르게 끌려가서 최후를 맞이한 것으로 추정된다. 여러 모로 좀 특이한 위치에 있는 인물이다.

다음으로 (5) 김 상옥이 1923년 1월, 종로 경찰서 내부에서 폭탄을 터뜨려서 주변 일본인들 여러 명을 다치게 했다. 당일에는 도주에 성공했지만 며칠 뒤 은신처가 탄로나고 서울 시내에서 포위되었는데, 이때 자신을 체포하려는 수많은 일본 경찰들을 상대로 혼자서 권총 두 자루만 쥐고 수 시간 동안 시가지 총격전을 벌였다. 이 과정에서 경찰서장까지는 아니지만 그래도 중견 간부급을 사살하고 부하들에게 중상도 입했다고 한다.
그는 총알이 다 떨어지자 마지막 총알로는 자결했다.

(6) 나 석주는 1926년 말, 의열단의 거의 끝물을 장식한 사람이다. 그는 중국인으로 위장해서는 동양 척식 주식회사와 조선 식산 은행에 폭탄을 던져서 내부 시설을 부쉈다. 다음으로는 사장이나 행장 같은 특정 타겟 없이 그냥 주변의 VIP 같아 보이는 일본인들을 권총으로 마구 사살하다가 신고를 받고 출동한 경찰들과도 대치하게 됐다.

결말은 3년 전의 선배 김 상옥과 비슷해졌다. 그 역시 마지막에는 자결을 시도했지만.. 단번에 절명하지 못하고 체포된 채로 병원으로 옮겨졌다. 그래도 충분한 치명상을 입은 덕분에 다행히 일제에 의해 고문과 처형 당하지는 않고 병원에서 순국한 것으로 보인다.

의열단은 이 글에서 언급되지 않은 실패한 거사도 몇 건 더 추진한 바 있다.
몇 년간 그렇게 해 봤는데 우리 역랑이 부족한 게 느껴지고, 딱히 대세가 바뀌는 건 없는데 귀중한 대원들의 희생만 더 커지고, 임시정부와도 손발이 썩 맞지 않고..

의열단은 일제 내지 내부 배신자에 의해 비극적으로 일망타진 와해된 것은 아니었지만, 여러 악재들이 겹치면서 해체되었다. 김 원봉은 무장 투쟁을 할 거면 이런 게릴라 공작원 테러리스트 급이 아니라 정규군 급의 병력을 양성할 필요를 느끼고 중국으로 떠났다.

그래서 1930년대 초에는 김 구가 의열단을 대신하여 임시정부 명의로 한인애국단이라는 비밀 단체를 만들었다. 이 봉창과 윤 봉길은 의열단이 아니라 바로 저기 소속으로 활동했던 사람이다.

(7) 이 봉창은 잘 알다시피.. 일본어를 너무 유창하게 잘하고 일본인 지인도 많고 심지어 일본 경찰과도 인맥이 있어서 김 구가 처음에 이놈은 밀정이 아닌지 진지하게 의심했을 정도였다. 한참을 얘기를 나눠 본 뒤에야 끄나풀이 아니고 레알 동지라는 것을 인정하게 됐다고 한다.

그는 조선 총독도 아니고 무려 히로히토 일본 천황을 암살하러 1932년 1월에 본토에 갔으며, 현장까지 잘 도달해서 폭탄을 던졌다. 폭탄은 불발 없이 잘 터지기까지 했다.
그러나 일본인들에게 신이나 마찬가지인 천황이 사람들에게 호락호락 얼굴을 비춰 줄 리 없었다. 천황은 면상은커녕 항복 방송 옥음(!)을 들려준 것만으로도 신민들이 벌벌 떨었던 존재인걸..;; 그는 똑같이 생긴 여러 대의 마차 중에 어느 게 천황이 탄 마차인지 알 길이 없었기 때문에 목표물을 맞히지 못했다.

그로부터 3개월 뒤, 히로히토의 생일에 훙커우 공원에서 벌어진 (8) 윤 봉길 의사의 의거는 무장 항일 독립운동 역사상 역대급의 대박을 터뜨렸다. 물리적인 인명 살상 실적으로나, 상징성으로나..

게다가 이런 스타일의 유의미한 거사는 훗날 해방될 때까지 저게 사실상 마지막 대단원이나 마찬가지였다. 윤 봉길 이후로는 일제의 감시와 탄압이 더욱 강화되고 김 구의 신변도 위험해졌기 때문에 한인애국단은 활동이 지속되지 못하고 1933년에 문을 닫았기 때문이다.

(이 봉창과 윤 봉길은 모두 외국에서 거사를 벌이고 외국에서 순국했다는 공통점이 있다. 그리고 의열단 시절과 달리, 이렇게 가입 선서식 사진까지 존재하는데.. 그런데 사진들의 태극기 배경은 다 합성인 것 같다.)

그러니 사람들이 안 중근과 윤 봉길만 기억하는 것은 우연이 아니다. 그게 이 분야의 알파와 오메가, 시작과 끝이니까 말이다. 그래서 서로 사용한 무기(전자는 권총, 후자는 폭탄)나 처형된 방식을 헷갈리기도 한다(전자는 교수형, 후자는 총살). 이들 이후로는 김 구도 개인· 소수 단위의 테러 의거가 아니라 광복군이라는 정규군을 양성하는 쪽으로 방향을 선회하게 된다.

이상이다.
누가 만들어 낸 구분인지는 모르겠으나.. 똑같이 항거하고 투쟁했더라도 무기를 들고 싸운 사람은 의사라고 부르고, 맨몸으로 싸운 사람은 열사라고 부르는 경향이 있다. 그래서 이 준(헤이그 밀사), 유 관순, 전 태일 같은 사람은 열사이고, 안 중근, 윤 봉길 같은 사람은 의사이다. 국어사전에는 명시돼 있지 않지만 통상적으로는 진짜로 저 기준으로 나뉘는 것 같다.

가만히 생각해 보면.. 일제 강점기는 컴퓨터라든가 각종 전자 출입 카드, X선 금속 탐지기 따위가 아직 없었기 때문에 저런 방식의 무장 항일 투쟁도 가능했음을 알 수 있다. 그런 게 있었으면 외국에서 만들어진 폭탄과 권총을 어떻게 한반도로 반입할 수 있었겠는가?

그리고 안 중근(하얼빈 역)과 윤 봉길(훙커우 공원)의 경우, 초대장 내지 입장권이 없었기 때문에 원래 해당 행사 장소에 들어갈 수 없었다. 그걸 유창한 일본어로 "아이 씨, 티켓을 깜빡 잊고 안 가져왔네.. 이런 경사스러운 행사에 자국민도 못 들어가요?"라고 유창한 거짓말을 구사하며 둘러댄 덕분에 들어간 것이었다. 참으로 대단한 멘탈과 배짱이 아닐 수 없다.

본인은 무장 투쟁이건 외교건 국민 계몽이건.. 독립 운동을 위해 다 필요한 것이었다고 인정하는 주의이다.
현실성만 따지면 어느 것도 다 비슷하게 계란으로 바위 치기이고 비효율적인 삽질 같기는 마찬가지였다. 그러나 그런 계란으로 바위 치기라도 안 했으면 일본이 원폭 맞고 깨갱 하고 물러갔다 해도 한반도가 자유 독립국이 된다는 보장은 결코 없었다.

그리고 이 주제와 관련하여 분명하게 짚고 넘어가야 할 점으로는.. 그 시절에도 난창 폭동이라든가 자유시 참변 등, 공산주의 진영에서는 조선의 독립과 관련하여 선한 게 나온 적이 없었다는 것이다.
조선인 독립운동가 중에서는 적의 적은 친구일 거라는 논리로 공산주의의 영향을 받은 사람이 있었다. 그러나 외국의 공산당원들이 그들의 기대에 부합하게 도움을 준 적은 결코 없다. 중국에서는 국공합작이라도 있었지만 한반도에서는 역시 그런 거 없다.

우리나라의 입장에서 그렇게도 임시정부가 좋으면.. 친중을 하지 말고 지금까지도 일관되게 친대만을 해야 할 것이다.
상식적으로 생각해 보아라. 장 제스가 임시정부와 대한 독립을 도와 줬지 마오 쩌둥이 도와준 적이 있었냐? 후자는 오히려 대한민국의 자유 통일을 저지한 원흉일 뿐이다.
오늘날 친중종북분자들의 유체이탈 궤변 논리는 아무리 생각해도 이해가 되지 않는다.

Posted by 사무엘

우리나라에 존재하는 네임드급 자동차 제조사 중에서 완전히 자국 국적의 기업은 현대, 기아, 쌍용 정도인 것 같다. 다만, 기아는 현대 그룹에 편입해 들어갔기 때문에 완전히 자체 독립적인 형태가 아니다. 르노삼성이나 한국GM이야 더 볼 것도 없고..

그리고 소형 승용차 말고 버스를 만드는 회사를 나열해 보면 상황이 좀 달라진다. 대우라는 브랜드가 추가되고 그 대신 쌍용은 빠진다. 그래서 현대, 대우, 기아가 남는데.. 거기에다 생소한 제조사가 둘 더해진다. 바로 ‘에디슨모터스’와 ‘우진산전’이다.

얘들은 자동차뿐만 아니라 각각 신소재와 철도 차량 같은 다른 분야에 기술과 제품도 보유하고 있다. 하지만 자동차 중에서는 버스만, 그것도 현재로서는 시내버스만 만든다. (시내버스 없이 고속버스만 만드는 기아하고는 대조적)
평범한 버스는 메이저 제조사들 대비 경쟁력이 부족해서인지, 천연가스· 전기 같은 대체 에너지 기반 차량 위주이다.

전자기기만 해도 삼성 LG 말고 다른 중소기업 제품이 있듯이 자동차 역시 그런 구도가 존재하는 셈이다. 자가용 승용차 말고 상용차에 한해서 말이다.
그리고 뭐.. 메이저 제조사들도 대체 에너지 차량을 연구를 안 하는 건 아니다. 다만, 현대는 평범한 배터리 기반 전기차 말고 수소 연료전지 기반 전기차의 연구에 특화돼 있다.

본인은 올해 초에 출근길에 난생 처음으로 전기 버스를 타 봤다. 지금은 안 그러는 것 같다만, 그 당시엔 버스 도착 안내 화면에 '저상'뿐만 아니라 '전기'라는 말이 당당히 떠 있길래 놀랐다. 그 많은 버스들 중에 하필 내가 출퇴근용으로 이용하는 노선에 전기차가 작년 말부터 시범적으로 도입됐던 것이다.
디젤 엔진이 천연가스에 이어 아예 전기 모터로 바뀌었구나! 하지만 번호판이 파란색 배경이지는 않았던 걸로 기억한다. (영업용이라는 노란색의 우선순위가 여전히 더 높은지?)

운전석을 보니 계기판에 타코미터가 없고 통상적인 변속기 레버가 없었다. 서울 시내버스들에 의무적으로 장착돼 있는 에코드라이브 제어 장치도 없다(정확한 이름이 갑자기 기억 안 나네..). 기존 버스들보다 운전 시설이 더 단순해졌다.

자동차에서 돌아가는 기계가 엔진만 있는 건 아니고 주행할 때도 엔진 소리만 나는 건 아니다. 그러니 전기 버스라고 해서 무슨 지하철 전동차 같은 소리가 나는 건 아니었다. 하지만 정차 중일 때 엔진 공회전 소리와 진동이 없고, 출발 시의 가속과 변속 역시 훨씬 더 부드럽고 정숙했다.

이 차량의 제조사는 우진산전이었다. (전면부 중앙의 W자 CI)
과거에 남산에서 다니던 전기 버스는 제조사가 에디슨모터스의 전신인 한국화이바였는데.. 걔는 고장이 잦아서 퇴출됐었다. 그 문제를 극복했는지 에디슨모터스 전기 버스 자체는 지금도 굴러다닌다.

한편, 일렉시티는 배터리나 수소 탱크 공간 때문인지 맨 뒷좌석이 5칸이 아니라 3칸으로 줄어들어 있더라. 그게 특징이다.

내가 알기로 전기차는 배터리 문제 때문에 일단은 소형차에 머물고 있다. CVT(무단 변속기)가 기술적인 한계 때문에 소형차에 머물고 있듯이 말이다. 그런데 어째 저 거대한 버스를 배터리만으로 굴릴까? 이래 가지고 여름에 에어컨까지 틀면 감당 가능하나? 게다가 대형차는 엔진 동력으로 브레이크의 공기 펌프도 충전해야 되는데.. 아 제동은 전기 모터의 회생 제동으로 감당 가능하겠다.

이런 복잡한 생각들이 머릿속을 맴돌았다. 하긴, 천연가스 엔진만 해도 디젤보다는 휘발유 엔진에 더 가까운 구조일 텐데 배기량과 기통수는 어떻게 되며 동력비 변환은 어떻게 하는지, 규모를 기름 엔진과 동일한 잣대로 측정 자체가 가능한지 개인적으로 잘 모르겠고 궁금하다.

천연가스 버스는 충전소 문제 때문에, 그리고 전기 버스도 충전 시간 및 항속거리 문제 때문에 현재로서는 시내버스 수준에만 머물러 있다. 마치 방위산업체들은 국방부와 납품 계약을 맺듯, 국산 워드 프로세서나 고유 운영체제 개발사들이 학교· 공공기관· 군부대와 납품 계약을 맺듯, 친환경 시내버스를 만들면 시내버스를 굴리는 지방자치 단체들과 계약을 맺고 납품하게 되겠다. 버스는 end-user용 제품이 아니니 말이다.

참고로 우진산전은 철도 전동차의 생산에도 관심이 많아서 전동차 현대 로템과 경쟁하는 구도이다.
에디슨모터스는 단거리 입석형 시내버스에만 그치지 않고 장거리 고속버스도, 심지어 기존 디젤 엔진 모델도 생산해서 메이저 자동차 전문 제조사들과 경쟁할 의향이 있다고 한다.

전기차가 한때는 기름차에 밀려서 도태했지만 21세기에는 다시 주목을 받고 있다. 전기 전자 공학이 눈부시게 발달하고, 그리고 석유의 고갈과 환경 오염 문제를 해결해야 할 필요성이 더욱 커졌기 때문이다. 아직 기존 기름차에 비해 부족한 게 많고 대량생산 덕도 제대로 못 보지만.. 미래를 내다보고 연구 개발하고 제품 구매도 좀 하라고 나라에서 지원을 많이 해 준다.

다만, 이런 분위기를 이용해서 전기차 개발사들이 자기 제품의 성능을 실제보다 부풀리면서 사기를 치는 경우도 없지는 않은 것 같다.
미국의 유명한 전기차 제조사인 테슬라는 요즘도 살아는 있나 모르겠고..

과거에는 우리나라의 ‘레오모터스’라는 회사에서 자기들이 세계 최초로 고속형 전기 버스를 개발했다고 대대적으로 광고하고 홍보한 적이 있었다. 언론 보도 날짜가 다들 2009년 12월이니 지금으로부터 무려 10년도 더 전의 일이다. 하지만 그 뒤로는 소식이 전혀 없고 회사가 돌아가고 있는지도 모르겠다.

내가 이걸 어떻게 아느냐 하면, 남한산 기슭의 광주 엄미리 마을 어귀에 레오모터스에서 개발한 중형 전기 버스가 버려진 채 세워져 있기 때문이다. 2017년 가을에 처음으로 우연히 목격했고, 작년에 다시 찾아가 보니 여전히 있었다. 2년 동안 방치됐음에도 불구하고 운전석 쪽 유리창이 없어진 것 말고는 외형이 크게 부서지거나 망가지지는 않았다.

이것 말고 마치 ‘LNG/LPG 개조’처럼.. 소형 트럭을 대상으로 ‘전기차 개조’를 해 주는 업체도 있다. 내가 들어 본 곳 중 하나는 ‘파워프라자’.. 개조도 하고, 아주 작은 경승용차는 자체 제작도 하는가 보다.

소형 트럭을 전기차로 개조해서 장기적으로 기름값 아끼라는 취지로 영업을 하는 듯하다. 고속도로 주행도 가능하고 스마트 포투 ev와 동급 정도 되는 차량인지, 아니면 자동차 전용 도로에도 못 들어가는 저속 전기차인지는 잘 모르겠다.
뭐, 어떤 경우든 10톤 이상, 그것도 전국을 돌아다니기까지 하는 트레일러를 배터리 전기차 형태로 만드는 건 현재 인류의 기술로는 가능하지 않을 것이다. 아직 전기 고속버스도 없는걸..

이상이다.
여객기 제조사가 보잉이나 에어버스만 있는 게 아니듯, 국내 자동차 제조사도 현대 기아만 있는 게 아니다. 마이너 제조사들은 시장에 뛰어드는 김에 전기차 같은 미래 기술을 같이 공략하는 경향이 있다는 것이 이 글의 요지이다.

아 그러고 보니 반세기쯤 전 과거에도 길거리에서 전기로 달리는 교통수단이 있긴 했다. 그 이름도 유명한 노면전차 내지 트롤리버스. 배터리 대신 팬터그래프가 달린 버스라니.. 참 흥미롭다.

얘들은 기술적인 구현 난이도가 매우 낮지만 공중에 전차선을 주렁주렁 달고 다녀서 미관에 굉장히 안 좋았으며, 차량 역시 전차선 주변을 전혀 벗어나지 못한다는 한계가 있었다. 그래서 여러 도시들에서 도태되고 사라지기도 했다. 건물 주변의 전봇대와 전깃줄들도 다 지중화해서 없애는 게 요즘 추세인데 전깃줄에 의존하는 대중교통은 시대에 안 맞았기 때문이다.

그 대신 요즘은 노면전차는 전깃줄을 땅에다 놔서, 그리고 버스는 배터리 형태로 바꾸고 굴절까지 시켜서 구식 이미지를 벗고 새로운 교통수단으로 변신했다. 이름도 트롤리버스 대신 무궤도 전차 내지 트램 등으로 바꿨다. 저 에디슨모터스, 우진산전 같은 기업들도 이런 차량의 생산에 응당 관심을 두고 있지 싶다.

자동차용 전기는 규격이 어떤 형태로 제정될까? 철도야 교류 25000V 60Hz(일반열차), 직류 1500V(도시철도 중전철), 직류 750V(경전철) 이렇게 딱 나뉘어 있는데 자동차는? 이것도 생각할 점이다. 검색을 해 보니 220V, 380V에다 완속· 급속 두 종류가 존재하고 단자 종류도 완전히 단일 표준화가 아직 안 된 듯..
석유와 LPG는 송유관이나 유조차를 통해 공급받겠지만 LNG/CNG는 도시가스 인프라를 통해 공급받을 것이고, 전기야 건물에 이미 갖춰진 전기 시설을 통해 공급될 것이다.

Posted by 사무엘

1. 고대와 현대의 전쟁 방식 차이 복습

옛날 전쟁에서는 겨우 성을 하나 정복하는 것만 해도 보통일이 아니었다. 사다리를 타고 오르거나 같은 높이의 언덕을 쌓는 등 별짓을 다 해야 했다.
그리고 해전에서는 배와 배끼리 접근하여 부딪치고, 발판을 놓아서 상대편 배로 건너가서 칼싸움을 벌였다. 적선은 완전히 부수고 침몰시키기보다는 나포해 오는 게 더 현실적이었다. 뭐, 목선이었으니까 아예 불질러 없앨 수는 있겠지만 그랬다가 잘못하면 아군도 위험해질 수 있었다.

적의 군함을 노획(!)해 오는 병사는 그야말로 평생 놀고 먹어도 될 정도의 포상을 받았다. 군량미 한 섬을 적군 것을 노획해도 그건 아군이 일일이 수송해 온 군량미의 10배가 넘는 전술 가치가 있다고 여겨졌는데 하물며 배는 뭐.. 그 정도로 보상해 줘도 국가의 입장에서는 남는 장사였다. 지금 우리나라도 단순 간첩 신고 포상금보다 "간첩선"의 신고 포상금이 훨씬 더 높다는 것을 생각해 보자.

뭐, 그렇게 눈에 보이는 전과를 세우는 병사 말고 공성전에서 사다리를 제일 먼저 오르기, 전열보병(!!) 시절에 제일 앞줄에서 머스킷 주고받기.. 이렇게 제 발로 죽으러 가는 거나 마찬가지이지만 누군가가 반드시 맡아야만 하는 임무에도 동기 부여를 위해 엄청난 포상과(생사 여부 무관), 반대로 도주 시 엄청난 처벌이 뒤따르곤 했다.
무기의 화력이 부족하고 부족하고 시설이 열악하던 옛날에는 어느 분야의 조직에나 닥치고 근성 의지드립 똥군기가 지금보다 얼마나 더 횡행해야만 했을지가 짐작된다.

그런데 화포의 성능이 크게 향상되면서 이런 싸움의 양상이 바뀌었다. 갑옷이 없어지고 방탄복으로 바뀌었다. 공성전이라는 것도 역사 속으로 사라졌다. 성을 쌓는 게 아니라 참호를 잔뜩 파서 방어하는 전술이 잠시 등장했다가 그걸 뚫기 위해 탱크라는 게 발명되었다.

현대의 해전은 교전 거리가 이미 수~수십 km에 달하며, 포탄은 보이지도 않는 까마득히 먼 곳에서 날아온다. 눈에 보이는 거리에서 총탄을 교환하는 건 그냥 백병전으로 여겨질 정도이다. (그러니 제2 연평해전 때 배 옆구리를 들이대서 막던 기동이 얼마나 무모하고 위험하고 불리한 짓이었는지도 다시 생각을..)

이렇게 먼 거리에 포를 정확하게 쏘려면 직사가 아니라 중력과 공기 저항을 감안한 곡사 궤적은 물론이요, 심지어 지구가 둥근 것까지도 감안해야 한다. 해수면이 무한한 평면이라고만 단순하게 가정할 수 없게 되는 것이다.
거기에다 쏘는 방향에 따라서는 심지어 지구의 자전으로 인해 발생하는 전향력도 고려 대상이 된다. 포 하나 쏘는데 오만 물리 지식이 동원된다. 그게 바로 오늘날의 전장의 현실이다.

그래서 20세기 초· 중까지는 군함이 크기가 왕창 커졌다. 돛 달린 목선이 엔진 달린 철갑선으로 바뀐 데다, 배가 커지면 더 많은 사람이 타고 더 멀리 더 오랫동안 항해할 수 있기 때문이다. 더구나 함포도 그에 비례해서 더 커질 수 있으며, 더 강한 화력과 더 긴 사정거리를 보장하게 된다. 큰 배 한 척이 작은 배 여러 척보다 훨씬 더 나았다.

배의 지하에 수십 명의 노꾼들이 타고, 위에서 수병들이 화살을 쏘다가 상대편 적선으로 건너가서 칼싸움을 벌이던 시절에 비하면 상황이 얼마나 극과 극으로 달라졌는가? 멀리 갈 것도 없이 임진왜란 거북선만 해도 노꾼이 필요한 배였다.

하지만 제국주의와 세계 대전 시절이 끝나고, 군함을 폭격기와 미사일로 잡는 시대가 되면서 군함이 한없이 더 커지는 유행도 끝났다.
태평양 전쟁을 배경으로 한 영화를 보면 자그마한 비행기들이 추락에 가까운 고각 급강하를 하면서 적국 군함에다 포탄 내지 어뢰를 떨군 뒤 튀는 장면이 나온다. 이렇게 해야 자유 낙하만 시키는 것보다 탄의 명중률이 올라가기 때문이지만, 이건 비행기의 입장에서는 항공역학적으로나(실속..) 군사적으로나(대공포 피격 가능성..) 매우 위험한 기동이다.

일반 폭탄은 그렇다 치더라도, 어뢰도 군함이나 잠수함이 아닌 비행기가 투하하고 가는 게 이례적인데.. 아무래도 비행기가 군함의 머리 위로 위험하게 접근하지 않아도 된다는 점, 그리고 배의 아래에서 더 치명적인 타격을 줄 수 있다는 점이 작용하지 않았나 싶다.
비행기에서 발사하는 항공 어뢰는 더 높은 고도에서 더 고속으로 바닷물에 떨어져도 내부 부품이 손상되지 않고 곧장 추진과 격발이 가능하도록 성능과 신뢰도가 계속해서 개선되었다.

이렇듯, 군용기야 같은 비행기끼리 공중전을 벌이는 전투기가 있고, 지상이나 수면의 목표물을 타격하는 폭격기도 있다.
그럼 전함은..?? 망망대해에서 같은 배끼리만 싸우는 것 같지만.. 적당히 큰 배는 현대전에서 의외의 역할도 한다. 바로 육지에 근접해서 내륙에다 신나게 엄호 포격을 퍼부어서 아군의 상륙 작전을 지원하는 것 말이다. 얘들이 어지간한 포병 부대를 능가하는 화력을 내기 때문이다.

그래서 인천 내지 장사리 상륙 작전 같은 영화를 보면 이런 포격 장면을 응당 볼 수 있다.
하지만 다른 곳은 몰라도 인천의 경우, 해안이 매우 얕고 조수 간만의 차이도 심하기 때문에 군함이 한없이 안쪽으로 들어와 줄 수 없다. 해병대가 차량 지원도 없이 뻘밭을 달려서 상륙해야 되니 더욱 어렵고 위험한 작전이라고 일컬어진 것이다. 현대전에서는 옛날처럼 사다리 타고 성벽을 오른다거나 적진 참호 앞에서 속수무책으로 갈려 나가는 일은 없지만(대응 전술이 개발되었으니), 이런 해병대라든가 낙하산 메고 적진에 뛰어내리는 공수부대가 성벽을 오르는 거나 다름없어 보인다.

2. 태평양 전쟁

1940년대의 태평양 전쟁 때 활약했던 일본군 장성 중에는 야마모토 이소로쿠, 그리고 나중에 쿠리바야시 타다미치라는 사람이 있었다. 이들은 일본이 저지른 침략 전쟁과 반인륜 범죄 같은 이슈들을 배제하고 생각할 때, 군인으로서는 나름 유능한 인물이었다.

이들은 개인적으로는 미국과의 전쟁을 반대하는 소신이었다. 그저 친미나 평화주의 이념 때문이 아니라, 이 국력으로 미국 같은 나라와 싸워서는 승산이 없다는 논리적인 판단에 근거해서 반대한 것이다.
그러나 미국과 틀어지고 무역로도 봉쇄되는 등 국제 정세가 계속 불리하게 흘러가자.. 야마모토 이소로쿠는 기왕 미국과 싸워야 한다면 지금 같은 여건에서 상상 밖의 통수를 치는 것밖에 할 게 없다는 결론을 내렸다.

마치 서울대를 가기 위해 수능을 무조건 만점 맞는 게 아니라 남들보다만 잘하면 되고, 위조지폐도 무조건 완벽하게가 아니라 그저 액면가보다만 비싸지 않은 퀄리티를 투자하면 되듯.. 적당히 미국을 타격하면 쟤들로 하여금 "쟤랑 싸우면 우리가 이기기야 하겠지만 우리도 출혈이 클 테니 그건 귀찮.. 차라리 적당히 협상" 쪽으로 방향을 전환할 수 있을 거고 생각한 것이다.

"우리는 40여 년 전에 러시아를 꺾었듯이 이번에도 미국을 제압할 수 있을 것이다. 일본은 신이 지켜 주는 나라이고 우리 민족은 야마토 정신이 깃든 대단한 민족이니까" 같은 근자감도 들어갔을 것이고..
그 결과 그는 1941년 12월에 그 이름도 유명한 진주만 공습을 실행해서 처음엔 실제로 굉장한 피해를 줬다.

그리고 일본은 그 뒤로도 반 년 정도, 대략 1942년 5월 정도까지는 승승장구했다. 연합국 연합군이 우왕좌왕 하던 사이에 동남아시아 지역을 순식간에 정복하면서 리즈 시절을 찍었다. 맥아더 장군조차 그 기세에 밀려 필리핀에서 철수하면서 "I shall return."이라는 말을 남긴 게 그 해 3월 11일이었다.

그러나.. 일본의 리즈 시절은 거기까지였다.
미국은 통수에는 통수로.. 먼저 둘리틀 특공대를 보내서 일본 본토를 타격하는 깜짝쇼를 선보였다. 그 뒤 전열을 가다듬고 자기 국력을 총동원해 가히 show me the money급의 물량으로 비행기고 배고 무기고 식량이고 팍팍 찍어냈다.

일본이 그렇게도 좋아하는 불굴의 정신력도 사실은 미국이 압도했다. 대공황을 버틴 깡다구에다가 일본에 대한 극도의 적개심으로 눈이 시뻘개진 젊은이들이 "꼭 입대해서 쪽발이들을 내 손으로 때려잡고 싶습니다!"라고 줄을 서서 몰려들었기 때문이다.
윌리엄 홀시 제독이 외쳤던 "Kill Japs, kill Japs, kill more Japs"는 요즘으로 치면 "개미를 죽입시다 개미는 나의 원쑤" 내지, 둠가이의 "Rip and tear"이나 다름없는 구호였다. 그땐 물론 임프, 카코데몬 따위가 아니라 쪽발이를 성경의 왕하 2:24처럼 찢고 죽인다는 얘기이고..

어디 그 뿐이랴, 미국은 정보전마저도 일본을 앞섰다. 쟤들은 일본군의 통신 암호를 쭉 해독해서 사실상 맵핵까지 확보해 놓은 상태였다. 연합군은 서부 유럽 독일군의 에니그마만 해독한 게 아니었다.
심지어는 "놈들이(일본) AF라는 곳을 공격할 거라는데 거기가 구체적으로 어딜까? 혹시 여기가 맞는지 우리가 낚시 무전을 평문으로 보내서 쟤들이 반응하는지 확인해 볼까?"라고 떠봤는데, 쟤들이 정확하게 거기에 낚여 준 덕분에 작전을 사전에 다 파악한 적도 있었다.

저기서 AF란 그 이름도 유명한 미드웨이였다. 일본이 미국의 통신을 도청했다고 자국으로 송신하는 메시지까지도 미국이 통째로 도청해 낸 것이다.
일본은 하와이와 가까이 있는 미드웨이 일대를 점령해서 영토를 넓히고 전세를 더 유리하게 이끌고 싶었지만 일이 뜻대로 풀리지 않았다. 1942년 6월에 벌어진 미드웨이 해전에서 일본은 항공모함 4척을 모두 잃는 참패를 당했지만, 미국은 전쟁에 대비가 단단히 돼 있었고, 전사자 수는 일본의 1/10에 지나지 않았다. 어차피 다른 전투에서 많이 손상을 입었던 요크타운 항공모함 한 척이 격침된 것 정도가 전부였다.

미드웨이 해전은 우리 식으로 풀이하자면 미국판 명량해전이나 마찬가지인 승전보였다. 얘는 인류의 전쟁 역사상 최초로, 해전이지만 전함의 함포가 아니라 항공모함의 함재기들이 서로 먼저 마주쳐서 싸우고 적선까지 격침시킨 전투였다.
그 뒤 1942년 11월에 벌어진 과달카날 해전은 태평양 전선에서 일본의 보급로를 완전히 끊어 놓았으며, 이때부터 전세는 슬슬 미국과 연합국 쪽으로 기울기 시작했다.

이듬해 4월에는 미국에서 야마모토 이소로쿠의 동선과 스케줄을 '맵핵'으로 파악했다. 그래서 우연을 가장한 특별 작전을 펼쳐서 그 적장을 제거해 버렸다! 소수의 전투기를 출격시킨 뒤, 전선 시찰 중이던 저 사람이 탄 수송기를 벌집으로 만들어서 추락시키고 튄 것이다.
미국은 자신이 일본의 무전을 도청하고 있다는 사실을 들키지 않기 위해 이번 사건도 철저하게 우연한 전과로 치부했으며, 그 뒤에 일본이 의심스러워서 낚시 역정보를 퍼뜨리는 것에는 반대로 절대 응하지 않았다. 이 정도면 일본을 아주 그냥 갖고 논 거나 다름없었다.

1944년의 필리핀 해 해전과 레이테 만 해전을 거치면서 일본은 더는 회생 불가능한 치명타를 입었고..
맥아더 장군은 필리핀을 떠난 지 2년 반쯤 뒤인 1944년 10월에야 귀환해서 I have returned라고 자평할 수 있었다.

1945년 2월에는 여느 전선보다는 일본에서 굉장히 가까운 곳인 이오지마 섬에 미군이 상륙하게 되었다. 이때 최선임 지휘관이었던 일본군 장성이 바로 구리바야시 다다미치이다.
그는 어차피 대세를 뒤집을 수 없다면 우리가 최대한 오래 살아서 미군의 진격을 최대한 지연시키고 놈들을 최대한 귀찮게 하고 최대한 피해라도 끼치자고.. 지는 걸 전제로 하고 예전과 좀 색다른 전술을 폈다. 3년 전쯤의 야마모토 이소로쿠와 통하는 면이 있어 보인다.

놈들은 화력이 워낙 넘사벽이기 때문에, 엄폐물 없는 해변에서 상륙 자체를 저지하는 것은 무의미 불가능하다. 그러니 일단 상륙은 허용한 뒤, 적이 깊숙이 들어왔을 때 게릴라전을 펼치며 여기저기서 산발적으로 괴롭히면서 정신을 빼 놓았다. 그는 반자이 어택 따위 하면서 절대로 허무하게 개죽음 당하지 말고, 가늘고 길게 끈질기게 살아남아서 적을 괴롭히라고 부하들에게 훈시했다. 해변에 방어를 구축하는 게 아니라 섬 내륙 곳곳에 지하 땅굴과 동굴을 이용한 아지트 네트워크를 꾸며 놓았다.

물론 그래 봤자 섬은 끝내 함락되었고 일본군은 궤멸을 맞이했다. 그래도 구리바야시 다다미치의 전략이 적중한 덕분에 미군은 1주일이면 끝날 거라고 쉽게 생각했던 땅따먹기에 1개월이나 소모해야 했다. 그리고 상상 이상의 인명 피해도 당하게 되었다. 워낙 고생해서 그런지 이모지마 섬 전투와 관련해서는 미 해병대원들이 산꼭대기에다 성조기를 꽂는 모습의 저 사진이 유명해졌다.

바로 다음 달 3월 9일과 10일에는 이제 도쿄 대공습이 펼쳐져서 일본의 수도가 불바다 잿더미로 바뀌었다. 옥쇄 항전 운운하는 정신나간 일본을 보면서 미국은 진주만 공습을 당했을 때와는 다른 관점에서 인내심이 한계에 도달했으며, 한편으로는 저런 또라이들의 본거지에 직접 쳐들어가는 것에도 부담을 느끼게 되었다.
그래서 직접 쳐들어가지 않는 대신 원자폭탄을 떨구게 됐다. 이제야 일본 천황이 직접 무조건 항복을 하고 드디어 전쟁 종결..

굽시니스트 님의 ‘본격 2차 세계 대전 만화’ 시리즈를 본 게 벌써 10여 년 전의 일이다. 태평양 전쟁의 서막인 진주만, 그리고 피날레인 원자폭탄 사이에도 연대기별로 다양한 사건과 전투가 있었다. 2차 대전은 전역이 워낙 넓었고 전개가 드라마틱했기 때문에 영화로도 제일 많이 만들어져 나왔다. 올해 초엔 마침 영화 ‘미드웨이’가 개봉해서 본인은 아주 재미있게 봤다.

1차 대전이 전투기와 탱크가 첫 등장한 전쟁이라면 2차 대전은 로켓, 미사일, 핵무기, 컴퓨터 같은 것을 개발시킨 전쟁이다. 그래도 2차 대전을 끝으로 식민지니 제국주의니 하던 구도가 완전히 종결되었으며, 세계가 고전적인 형태의 전쟁은 없이 평화가 유지되고 있다.

다시 생각해 봐도 그 시절에 일본은 정말 또라이 같은 나라였다. 쟤들이 어쩌다가 영국· 미국 하고도 사이가 순식간에 틀어졌는지 참 신통한 노릇이다.
물론 일본은 그 옛날에 아시아에서 유일하게 항공모함과 전투기, 잠수함을 독일로부터 기술 원조를 받아서든 어떻게든 자체 제작까지 했던 대단한 선진국인 건 사실이었다. 조선 따위 범접할 수조차 없었다.

하지만 안 그래도 국력이 미국에 비하면 택도 안 되는데 육군과 해군이 대립하면서 따로 놀고, 레이더는 개발해 놓은 것을 적국이 먼저 활용하고 있는데도 정작 자기는 활용을 못 하고, 거기에다 무식한 똥군기와 의지드립으로 인한 폭주, 점령한 식민지에서 차라리 예전의 백인의 지배가 훨씬 더 나았다고 원주민들이 학을 뗄 정도의 폭압 학정 병크 등..
전반적인 행정 시스템과 정신 세계랄까.. 그런 소프트웨어들이 도저히 미국의 적수가 될 수 없었다. 결국 일본 제국은 총체적 난국을 겪으면서 비참하게 몰락하고 전쟁에서 졌다.

Posted by 사무엘

2020년은 2~40년 전쯤에 만들어졌던 각종 소설과 SF물에서나 다루던 까마득한 미래 시점이다. 그게 현실로 찾아왔다니 감회가 새롭다.
하지만 현실의 2020년은 코로나19라는 웬 신종 바이러스 때문에 교회 예배가 중단되고 학교 개학과 심지어 올림픽까지 연기되는 초유의 사태와 함께 시작되었다. 세상의 그 어떤 소설과 SF물도 이런 걸 예측하지는 못했을 것이다.

2020년은 날개셋 한글 입력기도 개발 20주년에 진입한 시점이다. 그리고 무려 10.0 버전이 현재 개발 중이며, 이게 9.x 시절부터 지금까지 수 년째 미뤄지고 또 미뤄졌던 파이널이다.
원래 9.5를 파이널로 삼으려고 했다. 9.5 이후로도 1년 반 동안 9.6, 9.7, 9.8x 등 새 버전이 도대체 몇 개가 더 나왔던가?? =_=;; 그러던 게 이제야 드디어 제동이 완전히 걸렸다.

이 글에서는 개발 중인 10.0에서 이미 작업이 완료된 것, 더해지고 고쳐지는 것들이 어떤 것이 있는지 잠시 소식을 전하도록 하겠다.

1. '기본 글자판 설정' 빠른설정에 no-shift 두벌식 세팅

10.0 버전에서 본인이 가장 먼저 알리고 싶은 소식은.. 날개셋 한글 입력기의 제어판에서 사용자가 가장 자주 접하게 될 UI인 '기본 글자판 설정' 빠른설정에 no-shift 두벌식을 간편하게 세팅하는 기능이 추가됐다는 것이다. 바로 여기에 말이다.

지금까지 사용자들로부터 받은 피드백을 종합해 보면.. 두벌식에서 shift 없이 쌍자음을 언제나 연타로 입력하는 것에 대한 수요가 제법 많다는 걸 알 수 있었다. 하지만 별 생각 없이 낱자 결합 규칙만 추가해 놓으면 '이끼, 바삐, 앗싸, 홀씨' 같은 단어에서 뒷글자에 등장하는 쌍자음을 연타로 입력할 수 없다. 음절 경계 모호성에 걸려서 '익기, 밥비, 았사, 홄시' 따위와 구분이 안 되기 때문이다.

이런 모호성을 해소하려면 그런 쌍자음은 어쩔 수 없이 shift를 동원해서 입력하거나.. 아니면 capslock 같은 글쇠를 눌러서 앞 글자의 조합을 수동으로 끊는 수밖에 없다. 옛한글 글쇠배열이야 모호성이 훨씬 더 많이 발생하기 때문에 대놓고 조합 중단 글쇠가 배당돼 있기도 하다.

하지만 그런 고전적인 방법 말고 타자 시간 간격을(타이머) 이용해서 음절 경계 구분을 할 수도 있다.
이건 구버전에서도 진작부터 지원돼 왔으니 기술적으로 새로운 기능은 전혀 아니다. 하지만 사용자가 일일이 설정을 하는 게 마냥 간단하고 쉽지 않다. 수요가 많은 상징적인 설정을 곧장 세팅해 주는 기능을 빠른설정에다가 도입한 것은 그 자체만으로도 버전업의 명분이 될 수 있다.

더구나 타이머를 적용하는 방식도 두 가지 중 하나를 선택할 수 있다.

• 통상적인 방법(가-까 타이머): 뒷글자가 쌍자음이면 앞글자를 다 입력한 뒤 한 박자 쉰다(이-끼 → 이끼). 쉬지 않으면 예전처럼 ‘익기’가 된다.
• 다른 방법(각-가 타이머): 위와 반대로, 쌍자음을 지연 없이 빠르게 치고, 자음이 앞뒤 글자에 분산돼 있을 때 한 박자 쉰다(익-기 → 익기). Google 단모음이 이런 방식을 사용한다.

각 방식이 어떻게 구현됐는지를 살펴보면.. 전자는 중성까지만 입력됐을 때도 타이머가 발동돼야 하며 오토마타도 상태가 두 개 더 필요하다.
후자는 오토마타 상태가 하나만 있으면 되지만 특수 도깨비불 규칙과 다단계 입력 분리(65531) 낱자 결합이 추가로 필요하다. ‘밝’까지 쳤다가 도로 ‘발ㄲ’을 만드는 것은 명백하게 더 과격한 동작이기 때문이다.

그래도 사용자의 타자 행동 관점에서 두 방식에 절대적인 우열은 없으니 그냥 자기에게 편한 방식을 골라서 쓰면 된다.
기본으로 설정되는 시간 threshold는 0.5초(500밀리초)이다. 타이머 설정에서 이 값을 더 늘리거나 줄일 수 있다.

2. “조합 안에 조합 생성” 입력 도구

얘는 여러 글자로 이뤄진 단어 같은 덩어리를 다른 형태의 문자로 변환하는 핵심 인터페이스이다. 한글 단어나 훈으로 한자 입력하기, 그리고 T9 방식으로 영단어 입력하기 기능이 제공되고 있는데..

• 변환에 쓰이지 않는 문자는 애초에 조합창에 들어가지 않고 바로 본문으로 삽입되게 인터페이스를 개선했다.
• Ctrl 내지 Shift 클릭을 좀 다르게 인식하게 했다. T9 영단어 입력의 경우 마침표 and/or 공백을 뒤에 같이 삽입하게 했고, 한글-한자 변환의 경우 지금 외부 모듈이 지원하는 것처럼 "한자(漢字)" 내지 "漢字(한자)" 형태의 삽입이 되게 했다.
• 여러 독음 후보들이 존재하는데 이들이 길이가 길고 앞부분이 상당수 일치한다면 명령 프롬프트나 개발툴 에디터에서 하는 것처럼 앞부분의 ‘자동 완성’이 되게 했다. 타이핑 수고를 상당 부분 덜 수 있을 것이다. 자동 완성 단축키는 tab 또는 Ctrl+space 중에서 선택 가능하다.

3. 편집기: 자잘한 개선

날개셋 편집기에서 파일을 읽고 쓰는 아주 기본적인 동작과 관련하여 다음과 같은 강화· 개선 작업이 이뤄졌다.

(1) 파일을 제대로 불러오지 못한 상태에서 저장을 시도하거나, 아까 전에 제대로 저장하지 못한 상태에서 창을 닫으려 하면 확인 질문을 하게 했다.
여기서 ‘제대로’ 열기나 저장을 못 한 상황이란.. 인코딩이 잘못 지정되어서 깨진 문자가 발생했고, 현재 메모리에 존재하는 문서와 파일 형태로 존재하는 문서 내용이 서로 일치하지 않는 것을 말한다. 그 상태로 저장을 하면 문서를 변경하지 않았더라도 원래 있던 정보는 소실될 것이고, 창을 닫으면 마찬가지로 깨진 문자가 원래 무엇이었는지 알 수 없게 될 것이다.

(2) 저장 옵션을 통해서 파일의 인코딩을 변경했다면 문서 내용을 대놓고 변경하지 않았더라도 창을 닫을 때 파일을 다시 저장할지 묻게 했다.

(3) 아울러, 문서창의 시스템 메뉴에 ‘파일 이름 변경’이라는 기능을 추가했다. 이걸 실행하면 ‘다른 이름으로 저장’과 비슷한 대화상자가 나타나며, 여기서 파일 이름을 새로 지정하면 문서창을 열어 놓은 상태에서 프로그램 상의 이름과 디스크 상의 이름을 그걸로 간단히 바꿀 수 있다. 탐색기에서 따로 이름을 바꾼 뒤에 다시 불러온다거나 하는 번거로운 수고를 하지 않아도 된다.

4. 외부 모듈: Chrome 브라우저에서 추가적인 보정

크롬 브라우저는 과거에 자신이 데스크톱 앱인데도 돌아가는 IME에다가는 자신이 메트로 앱이라고 잘못 알려주는 문제가 있었다. 그 버그는 얼마 안 가서 수정됐지만, 그 다음으로 또 약간 알쏭달쏭 아리까리하게 동작하는 게 있다(2020년 3월의 80 버전 기준).

마소 Edge와 Firefox는 TSF를 온전히 지원하는 브라우저이다. 그러나 IE와 Chrome은 그렇지 않다.
TSF를 지원하지 않는 프로그램에서는 앞뒤 글자를 요청한다거나 caret 이동 같은 지시를 내리면 어차피 실패한다. 내 프로그램은 실패에 대한 대비는 물론 돼 있다. 그리고 처음부터 앱을 가려가며 동작하는 게 아니라, 이런 실제 기능의 성공 여부를 토대로 동작한다.

그런데 크롬의 경우, 앱의 종류를 식별해 보면 "TSF 미지원"이라고 나오지만, 앞뒤 글자 요청이나 caret 이동 등의 지시를 내리면 마치 TSF 지원 프로그램처럼 수행되고 성공했다는 리턴값이 돌아온다. 하지만 그게 제대로 올바르게 correctly 수행되어 있지는 않다.

크롬에서 '대한민국' 같은 단어를 입력하고 단어 단위 한자 변환을 시도해 보면 마소 한글 IME는 안 되지만 날개셋은 된다. 하지만 변환을 해 봤자 '大韓民國'이 아니라 '대한민국大韓民國' 이런 식으로.. 정확하게 동작하지 않는다.
더구나 낱자 단위로 달라붙기 옵션을 사용하면서 bksp를 눌러 보면 caret이 앞 글자로 제대로 가지 않고 계속 자기 자리에서 머무른다.

여러 정황상 인접 글자의 fetch는 되지만 텍스트 selection을 변경하는 건 안 되는 것 같다.
결정적으로 크롬이 대외적으로 자신을 "TSF 미지원"이라고 보고를 하므로 날개셋 역시 크롬에 대해서 "오동작을 하느니 아예 동작을 안 하도록" 조치를 취하는 게 바람직해 보인다.

요 보정을.. "데스크톱 앱으로 인식"이라는 보정 옵션에다가 추가했다. 이 옵션이 켜져 있고 앱이 자신을 "TSF 미지원"이라고 표시한 경우, 내 프로그램은 텍스트 고급 조작 지시를 시도조차 하지 않고 방어적으로 동작하게 된다. "TSF 지원"이라는 명시적인 정보가 있을 때만 고급 조작을 하게 된다.

5. 도깨비 한글 글꼴

옛날 도스 시절의 한글 바이오스 유틸인 '한글 도깨비'의 최종 버전  5.1에서 제공되었던 고유한 둥글동글한 글꼴, 일명 '둥근도깨비'체가 날개셋 한글 입력기의 다음 버전에서 제공될 예정이다.
"둥근모, 한솔바탕, 도깨비고딕, 한메굵은본문"을 한데 섞은 듯한 인상이지만 어느 것에 딱 떨어지지 않는 변별성과 독창성이 있고, 모양이 상당히 예쁘기도 한 편이다.

내부 구조를 살펴보니 얘는 놀랍게도 일종의 완조형이었다.
'가'부터 '히'까지 받침이 없는 글자는 완성형으로 각각의 글자들이 일일이 그려져 있고, 받침이 붙었을 때의 '가'~'히'도 마찬가지이다. 그 뒤 받침은 ㅗㅛㅜㅠㅡ용 아니면 나머지.. 이렇게 두 벌만 있다. 이런 형태의 글꼴은 난생 처음 봤다.

이 글자들로부터 초성과 중성을 일일이 decompose한 뒤, 뭔가 반복· 규칙과 패턴을 찾아내어 3차원 조합 테이블을 복원하고 날개셋 편집기에서 읽을 수 있는 11172자 조합형 한글 글꼴로 얼추 재구성했다. 어렵지만 흥미진진한 작업이었다.

ㅏㅑㅓㅕ 같은 모음은 거의 판에 박은 듯이 똑같지만, ㅘㅙ 같은 복합 중성 및 이와 결합한 초성들은 자형이 의외로 제각각 임의로 그려져 있었다. 그래서 규칙을 찾기 어려웠다.
요런 모양의 글꼴을 이런 복잡한 완조형 말고 8*4*4벌로 간소화(?)된 형태로도 옛날에 봤던 것 같기도 한데 정확하게 기억은 안 난다.

도깨비 말고도 1990년대까지 도스 시절에 텍스트 모드에서 쓰였던 유명한 한글 바이오스 유틸로는 태백한글, 한메한글이 있다. 태백과 한메는 제품 이름 겸 개발사의 이름이기도 하지만, 도깨비의 경우 개발사가 '한도 컴퓨터'여서 제품명과 일치하지 않는다.

한글 도깨비의 개발자인 최 철룡 씨는 정말 대단한 분이었다. 1980년대에 IBM 호환 PC의 내부 구조를 모두 마스터하여 한글 바이오스를 만들었을 뿐만 아니라.. 사실은 안 철수와 거의 비슷하게 브레인 바이러스 백신까지 자작했었다. 처음에는 마이크로소프트웨어 잡지의 기자로 재직하다가 나중에는 성이 안 차서 자기 회사를 차리게 된다.
날개셋 한글 입력기는 아래아한글과 마소 도스/Windows뿐만 아니라 태백, 한메, 도깨비에서 제공하던 글꼴들도 한 종류 이상씩은 courtesy 차원에서 제공하고 있다.

6. 그 밖에

• 프로그램 UI를 여러 군데 찔끔찔끔 수정했다. 기억에 남는 것으로는.. 이모지 문자표에다가도 우클릭 메뉴에 '복사'를 추가하고 전용 도움말을 넣었다.
• 지난 8.8부터 9.0대 기간 동안 심혈을 기울여서 구현했던 '복합 낱자 입력 로직 생성기' 빠른설정이 언제부턴가 제대로 동작하지 않고 적용 후에 프로그램이 뻗던 문제를 뒤늦게 발견하여 고쳤다. 직전인 9.9보다 전부터 존재했던 문제로 보인다. 처음에 구현이 잘못된 건 아니고, 나중에 소스 코드를 리팩터링을 잘못 했기 때문이다.
• 24픽셀(화면 확대 배율 150% 이상) 환경에서 날개셋 제어판을 꺼내서 ‘낱자 처리’ 탭에서 ‘낱자 코드 번호 병기’ 옵션을 켰는데.. 자그마한 낱자 번호가 초-중-종성별로 세로 위치가 차이가 나지 않고 언제나 같은 위치에 찍히던 문제를 뒤늦게 발견해서 고쳤다.
• 이 외에도 그 밖에 24픽셀 비트맵 글꼴을 표시하는 목록에서 줄 간격을 1픽셀에서 2픽셀로 늘렸으며, U+200?대에 있는 특수한 공백과 줄표에 대한 글립도 16픽셀일 때와 마찬가지로 추가했다. 또한 외부 모듈에 24픽셀용 아이콘을 추가했다. 고해상도 24픽셀 환경에 대한 지원을 여러 방면에서 강화한 셈이다.
• 외부 모듈의 ‘프로그램 호환성’ 탭에 현재 화면에 보이지 않는 몇몇 Metro 앱이 불필요하게 목록에 표시되어 있던 것을 감췄다. 그리고 ‘모두 원래대로’ 버튼의 원래 의도는 프로그램의 기본 보정 방식으로 되돌리는 것인데 그러지 않고 설정을 몽땅 삭제만 해 버리던 것을 고쳤다.
• 정말 사소한 것이지만.. 立의 한자 훈이 '설 립'(stand 서다)이 아니라 '설사 립'(??!!!)으로 잘못 등록돼 있던 것을 고쳤다. 2020년 현재 마소 한글 IME의 한자 데이터에도 동일한 오류가 있으며, 그게 날개셋에도 그대로 전해진 것 같다.

이상이다. 이 정도면 9.9에서 0.1이 더해진 10.0에 딱 어울리는 수준의 변화로 손색이 없다고 여겨진다.

대략 9.x 초기 시절에.. Windows 10의 특정 버전 내지 특정 게임에서 한글 입력이 안 될 때 내 프로그램을 쓰면 된다는 소문이 퍼졌으며, 날개셋 한글 입력기의 다운로드 트래픽이 폭증하여 내 홈페이지가 며칠 연속으로 셧다운 됐던 적이 있었다.
그래서 한동안 다운로드 링크를 내 홈페이지 서버가 아닌 Google Drive 링크로 제공했는데.. 요즘은 그런 시절도 지났는지 구글 드라이브를 안 써도 트래픽 초과가 뜨지는 않는다.

요즘은 프로그램 관련 문의를 메일로만 받고 있지만 그래도 여러 사용자에게서 문의와 버그 의심 신고 연락이 종종 오곤 한다. 정말 꿈에도 상상할 수 없던 곳에서 내 프로그램을 잘 쓰고 있다는 연락을 받은 적도 있었다. 덕분에 이번 버전도 자잘한 개선 중에는 메일을 통해 접수된 사용자 피드백이 반영된 게 무척 많았다.

내 프로그램을 사용하면서 개인 메일까지 보내서 질문이나 건의를 남겨 주는 분들이 계시니 고마운 일이 아닐 수 없다. 어서 새 버전이 완성되어서 새 기능들이 두벌식과 세벌식 사용자에게 모두 큰 도움이 되었으면 좋겠다.

Posted by 사무엘