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

기왕 말이 나온 김에 또 문자 입력과 관련된 사용자 인터페이스 얘기를 좀 계속해 보자.

글자 입력란에서 깜빡거리고 있는 길쭉한 세로줄(|)을 우리는 보통 '커서'라고 부르고 영어로 cursor이라고 한다.
그러나 이 명칭은 우리말로는 용언 '크다'의 활용형으로 보여서 보기가 안 좋고, 영어로는 마우스 포인터조차 cursor이라고 부르는 경우가 있다. 실제로 Windows API에서 사용되는 LoadCursor, ShowCursor 같은 단어는 전부 마우스 포인터를 가리키며, 내부 공식 용어는 캐럿(caret)이다. 함수명도 ShowCaret, HideCaret따위다.
용어가 대단히 혼란스럽다는 점을 인정하지 않을 수 없다. 이 글에서는 편의상 그냥 cursor이라고 적도록 하겠다.

텍스트 모드가 존재하던 도스 시절에는 이 cursor가 반각 폭을 차지하는 밑줄 모양(_)이었다. 그리고 일부 환경에서는 겹침 모드일 때는 cursor가 약간 두툼해지곤 했다. 그 일부 환경 중의 하나로는 GWBASIC의 대화식 환경도 포함돼 있다.
그때도 cursor를 보이게 하거나 감추는 도스 API가 있었다. 그리고 심지어 cursor의 굵기를 바꾸는 기능도 있어서 옛날 노턴 유틸리티의 구성원 중 하나이던 NCC(Norton Control Center)라는 프로그램을 통해 변경을 할 수 있었다.

그러고 보니 정말 옛날이구나.
NCC의 스크린샷이 궁금했는데 구글을 뒤져도 관련 그림 하나 찾을 수 없을 정도로 완전히 역사 속으로 묻혀 버렸다.
얘는 cursor 모양을 포함해서 키보드와 마우스의 속도를 바꾸는 액세서리 기능도 있었다.
지금은 Windows의 제어판을 통해서 키보드의 속도를 바꾸지만 도스 시절에는 외부 명령인 MODE CON을 이용하거나 별도의 그런 유틸리티를 썼다. 그런 프로그램들 역시 내부적으로는 도스 API를 호출하는 형태였겠지만 말이다.

GUI 기반인 Windows에도 cursor는 응당 존재한다.
기술적으로 볼 때 cursor는 특정 시간 간격으로 운영체제가 DC에다 비트맵을 XOR이라는 래스터 연산을 적용하여 그려 주는 동작일 뿐이다. WM_CREATE 때 cursor를 생성하고, WM_DESTROY 때 파괴한다. 그리고 WM_SETFOCUS 때 화면에 표시를 해 주고 WM_KILLFOCUS 때 감춰 주면 된다.

숨김/감춤 요청이 교대가 아니라 중첩해서 발생할 경우, 운영체제는 일종의 reference counting을 해 준다.
하지만 개인적으로는 창이 WM_SETFOCUS와 WM_KILLFOCUS에 대한 처리를 운영체제가 자동으로 하게 API를 설계하는 게 더 나았을 거라는 생각을 한다. 언제나 단 한 프로그램에서만 cursor가 깜빡이는 게 보장되도록 말이다.

cursor만을 위해 문서화되지 않은 전용 타이머 메시지가 쓰인다는 것은 Spy++ 같은 프로그램을 통해 이미 아는 개발자들이 많을 것이다. 0x118인데, 편의상 흔히 WM_SYSTIMER라고 이름을 붙이는 듯하다.

한글을 조합 중일 때 cursor가 조합 중인 한글 전체를 감싸며 깜빡이는 것은, 도스 시절의 자체한글 프로그램들로부터 전해지던 전통이다. 나름 우리나라에서만 볼 수 있는 관행인데 MS가 로컬라이즈 차원에서 이런 시각 피드백을 Windows에다가도 적극 도입했다. MS 워드 6.0이 이를 첫 지원했으며 Windows 95때부터 운영체제의 에디트 컨트롤까지 지원이 확대되었다.
그냥 일본어/중국어를 입력할 때처럼 조합 중인 한글을 대충 밑줄로 표시하는 걸로 때워도 됐을 텐데 이를 특별히 배려한 것이다. Windows 3.x 내지 맥 OS에서는 깜빡이는 네모 cursor를 볼 수 없다.

과거에 훈민정음 워드 프로세서는 한글 모드일 때 cursor가 흰색 배경에 대해서 붉은색으로 변하곤 했다.
그리고 MS 오피스 2010은 수평이 아닌 임의의 각도로 기울어진 텍스트 상자에 글을 입력할 때... 입력란도 실제로 그 기울어진 각도를 반영하여 동작하는 직관적인 UI를 구현해 냈다. 이때 cursor도 당연히 기울어진 상태로 나타난다. 이런 cursor는 어떻게 만들었을까?

이것들도 다 CreateCaret 함수에서 크기만 달랑 지정하는 게 아니라 비트맵을 지정해 줌으로써 구현 가능하다.
비트맵 인자로 NULL을 넣으면 해당 영역의 모든 비트맵의 비트가 1이어서 전체 영역이 반전된다. 즉 InvertRect 함수를 호출하는 것과 동일한 효과가 난다.
그리고 MSDN에서 볼 수 있듯이, (HBITMAP)1을 집어넣어 주면 비트 0과 비트 1이 번갈아가며 나타나는 그 50% gray가 지정된다.

이와 같은 맥락으로, 옥색으로 채워진 비트맵을 지정하면 흰색 바탕에서는 보색인 빨강 cursor가 나타나며
검정 배경에 기울어진 흰색 사각형 모양의 비트맵을 지정하면 기울어진 cursor도 만들 수 있다.
요컨대 운영체제의 caret은 무조건 직교좌표계를 따르는 직사각형만 가능한 게 아니다.
임의의 비트맵과 XOR 연산을 하는 형태로 구현되기 때문에 임의의 모양의 cursor를 만들 수 있다.

다만, 별도의 마스크 비트맵이 존재하지 않기 때문에 마우스 포인터나 아이콘 같은 완전히 opaque한 스프라이트를 깜빡이게 할 수는 없으며, 알파채널 같은 걸 줄 수 없을 뿐이다. 그런 효과를 만들려면 프로그래머가 직접 cursor의 깜빡임을 타이머를 써서 구현해야 할 것이다.

Posted by 사무엘

지금 여러분의 PC에는 비트맵 그래픽 에디터로 무엇이 설치되어 있는가?
포토샵, 페인트샵, 페인트 닷넷, 심지어 그림판, 비주얼 스튜디오가 자체 제공하는 그래픽 에디터 등등...
이런 것들을 떠올리면서 각 프로그램들이 텍스트를 삽입하는 텍스트 도구가 어떤 형태로 구현되어 있는지 생각해 보시기 바란다.

보통은 텍스트 도구를 실행하면 텍스트를 삽입할 지점 내지 영역을 지정할 수 있고, 그 뒤에는 어지간해서는 텍스트 입력란이 별도의 대화상자나 창을 통해서 뜨게 된다.
그런데 Windows가 기본 제공하는 그림판은 다소 참신하게 설계되어 있다.

텍스트를 입력받는 영역이 그림 내부에 일체형으로 생긴다. 그림 내부에 cursor가 생겨서 텍스트를 곧바로 입력할 수 있으며 심지어 블록까지 잡을 수도 있는데,
일괄적인 단색이 아니라 기존 그림이 그대로 배경에 깔린다. 즉, 텍스트를 입력했다가 지우면 원래 그림이 도로 보존된다는 뜻이다. 별로 깜빡거리는 현상도 없다. 게다가 윈도 95 시절부터 그림판은 이렇게 동작해 오고 있었다. 참고로 페인트 닷넷이나 과거 윈도 3.1 시절의 페인트는 텍스트가 그림에 바로 삽입은 되지만, 블록까지 잡을 수는 없다.

이건 보통일이 아님을 알 수 있다. 아무래도 운영체제의 일반 에디트 컨트롤로는 불가능한 일인 것 같다.
WS_EX_TRANSPARENT라는 스타일이 있고 자체적으로 배경을 지우지 않게 WM_ERASEBKGND 메시지를 서브클래싱한다 해도, 일단 글자에 가려졌던 배경을 깜빡거림 없이 지능적으로 복구하는 일은 해당 컨트롤이 알아서 해 줘야 하기 때문이다.

Spy++로 살펴보면, 텍스트를 입력받는 동안엔 그림 클라이언트 영역 내부에 리치 에디트 컨트롤이 하나 생기긴 한다.
잘은 모르겠지만 얘는 일반 에디트 컨트롤보다 기능이 더 많고 전문적인 만큼, 옵션을 줌으로써 투명하게 동작하는 것에 대비되어 있는 게 아닌가 싶다.

과거의 그림판은 글꼴이나 크기, 색깔을 바꾸면 그게 모든 텍스트에 일괄 적용되었다. 하지만 7의 그림판은 리치 에디트답게 속성을 글자별로 다 따로 줄 수 있다. 뭐, 일괄 적용되던 시절에도 어차피 리치 에디트 기반인 건 동일했으니 그건 단순히 개발 난이도를 낮추기 위해 사용되었던 정책인 것 같다. 그래픽 에디터는 전문적인 텍스트 에디터가 아니니까 말이다.

상황을 좀 더 일반화해서 생각해 보자.
사실, GUI 위젯의 구성요소로는 각종 버튼들, 리스트 박스, 콤보 박스 등 여러 물건들이 있는데,
그 중 기술적으로 가장 만들기 힘든 것은 단연 에디트 컨트롤이다.
키보드 입력을 가장 정교하게 처리해야 하고, 텍스트의 변경으로 인해 텍스트의 전체 레이아웃이 바뀌는 것을 그때 그때 처리해야 하며 그러면서 화면상으로 바뀐 부분만 다시 그리거나 스크롤해 줘야 한다.

에디트 컨트롤을 만들어야 하는데 이런 어렵고 복잡한 내부 처리는 다른 컴포넌트에다 맡기고, 주어진 레이아웃대로 화면에 글자를 출력하는 것만 사용자가 customize할 수는 없을까?

예를 들어서 게임을 만들 때 말이다. 채팅창이 있는데 글자는 그림자 같은 일반적인 리치 에디트 포맷에 없는 특수한 효과가 적용되고, 배경으로는 게임 배경 화면이 알파 채널로 겹쳐진다. 이런 그래픽 출력을 일반 윈도우 DC를 이용해서 할 수는 없는 노릇이다.

이런 경우, 별 수 없이 게임 내부의 GUI 라이브러리를 개발하는 사람이 야메로 에디트 컨트롤을 직접 구현한다.
직접 만들면 세세한 제어가 가능하니 속 편한 경우도 있지만, 외국 시장까지 생각했을 때 아무래도 높은 완성도를 기대하기 어렵다. 중국어· 일본어 IME의 시각 피드백을 출력한다거나 아랍어가 뒤섞인 텍스트를 제대로 처리하는 에디트 컨트롤을 혼자 다 만든다는 건 불가능하며 그럴 필요도 없다.

본인이 개발한 <날개셋> 타자연습에도 기술적으로 완전 구닥다리이긴 하지만 그래도 DirectDraw surface를 만들어서 동작하는 게임이 있다.
내 원래 계획은 입력 중인 글자는 게임 배경에 같이 오버랩되어 표시되는 것이었다.
하지만 그것까지 구현하는 게 어려워서 그냥 화면 하단에 날개셋 에디트 컨트롤을 때려박아 넣는 형태로 프로그램이 만들어졌다. 에디트 컨트롤의 내부 알고리즘이 내린 지시를 custom 출력 매체에다 효과적으로 임베딩하는 방법이 필요하다.

이런 생각을 마소의 개발자가 안 했을 리가 없다.
그래서 Windowless Rich Edit Control이라는 게 있다. 리치 에디트 컨트롤의 내부 알고리즘을 COM 객체 형태로 만든 것이다. 얘를 이용하면 굳이 독립된 윈도우를 만들지 않고도 리치 에디트 컨트롤처럼 동작하는 객체를 손쉽게 구현할 수 있다.

물론, 스펙을 보면 알겠지만 우리 쪽에서 처리해야 할 요청이 한두 개가 아닌 관계로, 마냥 쉽게만 사용할 수 있는 물건은 아닐 수도 있다.
우리는 ITextHost라는 인터페이스를 구현하여 “어디에다 cursor를 만들어라, 무슨 크기를 얻어 와라” 같은 요청를 처리하면 되고, 운영체제의 기본 서비스가 필요하면 ITextServices 인터페이스를 호출하면 된다. 이들 객체는 CreateTextServices 함수를 통해 주고받으면 된다.

본인은 그렇잖아도 문자 입력과 관련된 프로그래밍 경험이 많은 관계로, 운영체제에 이런 API가 있는 것은 진작부터 알고 있었고, 이걸 실전에서 활용도 몇 차례 해 봤다. 단, 정작 그림판은 이런 windowless 오브젝트를 사용한 게 아니라 내부에 특수 처리된 리치 에디트 컨트롤 윈도우를 직접 생성했다는 게 의외로 놀랍다.
text services라는 단어 자체는 이 때부터 있었던 셈이다. 그러니 IME를 대체하는 Windows의 차세대 문자 입력 프로토콜이 text services framework, 즉 TSF라고 명명된 것은 우연이 아니라 하겠다.

Posted by 사무엘

고전 게임 페르시아의 왕자에 대해서 더는 글을 쓸 일이 없을 것 같았는데 또 하나 글을 쓰게 됐다.
지금까지 까맣게 잊고 지냈던 게임 중 이벤트가 하나 갑자기 떠올랐기 때문이다.

잘 알다시피 페르시아의 왕자에는 주인공의 영혼(?)이 빠져나가는 듯한 이상한 이벤트가 있다.
레벨 4에서 클리어 관문을 열고 나오면 거울이 하나 생겨서 길을 가로막는다.
이 거울을 도움닫기 점프로 깨뜨리면 진행은 가능해진다. 하지만 이때 자기 영혼 내지 그림자? 도플갱어가 빠져나가고 그 과정에서 왕자는 HP가 1로 다 깎여서 죽기 직전의 상태가 된다.

도플갱어의 정체가 무엇인지, 제작자 조던 메크너가 무엇을 의도하고 이런 걸 넣었는지는 모르겠다.
다만, 이 도플갱어가 왕자에게 하는 짓은 결코 호의적이지는 않다.
레벨 6에서 뚱보를 죽인 뒤에 벼랑을 앞두고 서로 만났을 때는, 도플갱어가 문을 쾅 닫아서 왕자를 벼랑 아래로 빠뜨려 버린다.

그 뒤로 도플갱어는 한동안 등장하지 않다가 게임이 끝날 때가 다 된 레벨 12의 꼭대기 층에서야 등장한다. 원수진 것 때문에 서로 칼을 뽑고 대적하지만 그래도 성질 죽이고 칼을 집어넣고 서로 합체를 해야 살 수 있다. 재결합을 한 뒤에는 보상 차원에서인지 전체 체력이 1 증가된다.

이 글에서는 그 전에 레벨 5에서 발생하는 이벤트에 대해서 좀 분석을 해 봤다.
레벨 5에는 전체 체력을 1 늘려 주는 대형 물약이 있다. 그러나 이것은 우리 왕자가 먹을 수 없다. 도플갱어가 먼저 와서 진짜 말 그대로 정확하게 '먹튀'해 버리기 때문이다. 그게 무슨 말이냐고?

자, 옛날에 페르시아의 왕자를 해 본 경험이 있는 분이라면 옛날 생각이 나실 것이다.
1층과 3층에 문이 있는데 물약이 있는 3층 문은 닫혔기 때문에 낮은 1층으로 먼저 들어가야 한다.
1층 문을 진입하는 순간, 발판 때문에 문은 쾅 닫힌다. 왔던 길로 못 돌아간다. 미우나 고우나 “들어올 때는 마음대로였겠지만 나갈 때는 아니란다” 상태가 되고, 어떻게든 저 무시무시한 왕복 톱날 2개를 통과하여 물약을 먹으러 가야 한다.

톱날을 통과하면 곧장 1층과 3층 문을 모두 여는 발판이 우리를 기다리고 있다.
그런데 3층 문이 열리자마자 3층에서는 왕자의 도플갱어가 갑자기 튀어나와서 물약을 쳐묵쳐묵 한 뒤 달아나 버린다.
톱날을 지나면서 힘들게 묘기는 우리가 다 했는데 갑자기 저 녀석이 소중한 물약을 먹튀하다니..

일단, 맵의 디자인이 굉장히 교활하게 돼 있다는 걸 부인할 수 없다.
문을 여는 발판이 하나만 있어도 될 게 굳이 2개씩이나 있다. 왼쪽 것과 오른쪽 것 중에 오른쪽 것은 3층으로 올라가는 과정에서 무조건 밟지 않을 수가 없다. 둘 중 어느 것을 밟더라도 1층과 3층 문이 모두 열린다. 그리고 3층이 열리는 순간 왕자가 미처 3층으로 다 올라가기도 전에 도플갱어가 먼저 달려온다..

결국, 왕자가 3층으로 올라갈 때까지 저 문이 최대한 늦게 열리게 하려면..
저 두 발판을 밟지 않은 상태에서 왕자가 두 발판을 사이에서 오른쪽이 아닌 왼쪽을 보고 있는 상태를 만들어야 한다.
이게 꽤 어렵다. 그래도 오른쪽의 둘째 톱날의 앞에 바싹 붙어 선 뒤, 오른쪽으로 점프를 하면 왼쪽 발판을 밟지 않고 양 발판의 사이에 설 수 있다.

그 상태에서 3층으로 올라감과 동시에 3층 문이 열리게 하면 그나마 시간을 최대한 벌 수 있으나..

그래도 우리가 도플갱어보다 먼저 물약에 닿는 것은 여전히 불가능하다. 최선을 다해도 결국 위와 같은 차이가 난다는 것을 알 수 있었다.

그 다음으로 본인이 시도한 것은, 3층 문을 열어서 도플갱어가 들어올 때쯤 도로 1층으로 내려가서 문을 닫아 버리는 것이었다. 1층의 닫힘 발판은 1층 문뿐만 아니라 3층 문까지 한꺼번에 닫기 때문이다.

그런데 이것도 엄청나게 어렵다. 아까 저 그림처럼 3층 문을 열지 않은 상태에서 왼쪽을 보고 있는 상태를 먼저 만들어야 하는 데다, 거기에다 추가적인 묘기가 더 필요하기 때문이다.
준비됐으면 발판을 밟아서 3층 문을 연 뒤, 정확한 타이밍을 노려서 2개의 톱날을 도움닫기 점프로 한번에 통과하고 1층으로 떨어져서 닫힘 발판을 밟아야 한다! 타이밍이 안 맞으면 톱날에 찍혀 끔살당한다.

그래도 이것 역시 불가능한 일은 아니다.
그러나.. 그럼에도 불구하고..
악랄한 우리의 도플갱어는 닫힌 철문도 통과하고서 물약을 훔쳐 먹고 유유히 사라지는 걸 알 수 있었다.

이 정도면 정말로 답이 없고 불가능이긴 하다.

2중 톱날은 왕자의 진행 속도를 크게 낮추는 어려운 트랩이다.
레벨 8의 경우, 클리어 관문을 열기 위해서 2중 톱날을 왕복으로 통과해야 한다.
그러고 나니까 철문이 닫혀 있어서 꼼짝없이 갇혔는데, 이때 공주가 보낸 생쥐가 문을 열어 주는 게 원래의 설정이다.
하지만 잘 알다시피 2중 톱날도 아무 거리낌없이 통과하여 철문이 완전히 닫히기도 전에 자력으로 빠져나오는 것도 불가능하지는 않다. 유튜브에서 괴수들의 플레이 동영상을 보면 그런 게 있다.

레벨 8에는 그런 플레이가 있는 반면, 레벨 5에서 도플갱어를 따돌리고 대형 물약을 먹는 데 성공했다고 하는 테크닉이나 플레이 동영상은 인터넷에 전혀 존재하지 않는다. 불가능한 일이기 때문이다.

MEGAHIT 치트를 써서 게임을 실행한 뒤, 도플갱어가 등장하는 장면에서 K(현재 화면에 있는 몹을 죽임)를 누르면 도플갱어가 사라진다. 이를 활용하면 레벨 5에서 대형 물약을 먹을 수 있게 되며, 레벨 6에서도 도플갱어가 있는 절벽 건너편으로 올라가는 것도 가능해진다. 하지만 이건 언제까지나 치트를 써서 만들어 낸 결과일 뿐이다.

참고로, 2007년에 나온 3D 리메이크작인 <페르시아의 왕자 클래식>은 이 시스템이 좀 개선되었다.
2층에서 3층 문을 열었다가 1층으로 잽싸게 되돌아와서 그 문을 닫아버리면, 도플갱어는 왔다가 물약을 못 훔치고 되돌아간다. 그래서 레벨 5에서도 대형 물약을 먹고 체력을 늘리는 것이 가능하다!
리메이크작은 톱날이 2개이던 것이 1개로 줄고 왕복 주기도 원작보다 훨씬 더 길기 때문에, 통과하기도 쉽다.

Posted by 사무엘

1.

본인은 <날개셋> 한글 입력기의 개발자이며, 사용자로부터 프로그램과 관련된 문의 사항을 종종 메일로 받고 있다.
그런데, 단순 문의나 버그 신고, 제안을 넘어서 이런 한글/일반 문자 입력 방식을 고안해 놓은 게 있는데 이걸 혹시 날개셋에서 쓸 수 있게 만들어 줄 수 있느냐는 문의가 오기도 한다.

사실, 내 프로그램은 초보자가 당장 사용하기가 좀 어렵다는 것을 본인도 인정한다.
워낙 특이하고 구조가 복잡하기 때문에 프로그램의 개발 취지와 내부 구조를 어느 정도 이해하고 있어야 고급 기능들을 제대로 활용할 수 있다. 날개셋문자, 수식, 오토마타, 낱자 결합 규칙 같은 것들...

그러나 내 프로그램도 비록 여전히 내용이 어렵다는 비판은 있을지언정, 모든 기능들이 개념 설명과 문서화는 충분히 돼 있다.
스스로 설정을 이것저것 바꿔 보고 있는데 모르는 게 있어서 궁금한 부분만 묻는 것도 아니고,
아예 처음부터 끝까지 밥을 떠 먹여 달라는 부탁을 내가 일일이 다 들어 줄 수는 없다.

그분들이 날개셋 한글 입력기의 구조를 공부하는 게 어려운 것만큼이나,
역으로 그분들이 생각하고 있는 각종 독창적이고 기괴한 입력 방식 스펙을 내가 이해하고 의견을 맞추는 것도 만만찮게 어렵기 때문이다. 어느 쪽에서든 세상에 쉬운 일은 없다~!

그리고 만에 하나 내가 입력 설정 파일을 하나 만들어 줘도 그분들이 그걸 제어판에서 불러다 선뜻 쓸 수 있을 거라는 보장도 없고,
머릿속에만 존재하던 자기 입력 방식을 실제로 쓰다 보면 결국은 마음에 안 드는 게 생기고, 또 고치고 싶은 게 생기기 마련이다. 당사자는 손 하나 까딱 안 하면서 그걸 내가 일일이 다 고쳐서 애프터서비스를 해 줄 수도 없다. 프로그램 자체에 대한 서비스가 아니라 그 사람의 아이디어에 대한 서비스가 말이다.

그러니 내가 일일이 다 코치를 해 줄 수도 없고, 그렇다고 해서
정말로 날개셋 한글 입력기의 구조를 다 공부할 여력이 안 되는 분의 부탁을 고사만 하는 것도 최선의 해결책은 아니라 생각되기에...
이렇게 하기로 했다.

<날개셋> 한글 입력기를 이용한 문자 입력 방식 구축 컨설팅(?) 서비스는 앞으로 유료로 정식 제공할 것이다.

이 프로그램은 1.0 이래로 수익 모델은 한동안 대회 상금이 전부였다. 그러다가 1년 남짓 전부터 후원금을 받기 시작했으며 고맙게도 몇몇 분들께서 실제로 후원을 해 주셨다.
그 다음으로 제3의 수익 모델로는 저게 자연스럽고 적절하다고 여겨진다.

리눅스 배포사들도 리눅스 자체는 무료 배포하고, 각종 기술 지원을 유료로 함으로써 이윤을 내지 않던가.
그것처럼 <날개셋> 프로그램 자체는 누구나 무료로 사용 가능하되, 자기가 원하는 대로 프로그램을 세팅하는 기술 지원만을 유료로 하는 것이다.

현재 생각하고 있는 것은,
한 입력 방식에 대해서 customize된 ist 파일을 한 번만 만들고 애프터서비스 없이 끝내는 것이 3만 원, (단수?)
그리고 첫 ist 파일이 완성된 이후로 두 주 동안 최대 3회까지 입력 방식의 개정 요청까지 들어 주는 것이 5만 원 선이다. (복수?)

물론 만들어진 파일의 내부 구조와 원리에 대해서 각종 설명은 충분히 해 준다.
그리고 단수라 해도, 애초에 입력 설정이 예전에 접수된 주문대로 만들어지지 않았다면 수정을 해 준다. 주문 자체가 모호하고 불충분했던 것에 대한 추가 보완 내지, 단순 변심 수정 요청만을 받지 않을 뿐이다.

이건 양산된 컨텐츠를 뿌리는 게 아니라, 일종의 일대일 맞춤형 과외 같은 서비스이기 때문에 비용이 무슨 공산품 수준으로 저렴할 수는 없다.
저 비용을 지불하고 싶지 않으면 자기가 직접 날개셋 도움말을 독학하면서 수식을 입력하고, 비한글 입력의 경우 고급 입력기의 로직을 스스로 짜면 된다.
즉, 프로그램 자체가 무료인 이상, 무료 우회도로가 얼마든지 존재한다. 유료 고속도로는 단지 더 빠르고 편하게 가게만 해 줄 뿐이다.

거래는 이런 식으로 진행될 것이다.
사용자가 먼저 자기 입력 방식에 대해서 설명하고, 단수와 복수 중 원하는 서비스를 주문한다.
그러면 본인은 그 입력 방식에 대해서 내가 이해한 게 맞는지 되묻고, 그게 기술적으로 내 프로그램에서 가능한 입력 방식이라면 승락을 한다.
그래서 사용자가 서비스료를 후원 계좌로 입금하면 본인은 그 입력에 대한 설정 파일을 만들고 사용자에게 이것을 보내 준다.

입력 방식 컨설팅 수요가 얼마나 될지 앞으로 지켜보겠다.
오해가 없게 다시 말하지만, 자기가 직접 프로그램을 써 보면서 잘 모르는 것을 본인에게 문의하고 상담하는 건 당연히 얼마든지 무료이다.
머리부터 발끝까지 프로그램을 자기 입맛대로 설정을 다 맞춰서 떠 먹여 달라는 주문만이 유료이다.

2.

다음으로 <날개셋> 한글 입력기의 외부 모듈과 관련하여 지금까지 최상위 순위권으로 접수되어 온 질문에 대한 설명을 좀 다시 하겠다.
“드보락 자판을 쓰려고 하는데, 쿼티/빈 입력 스키마 글자판이 또 자꾸 새로 생기는 것” 말이다.

이미 아시는 분들도 있겠지만, 외부 모듈(IME)은 편집기처럼 자기 혼자 독자적으로 돌아가는 프로그램이 아니다. 운영체제 내지 응용 프로그램과도 조화를 이루며 동작해야 한다.
응용 프로그램이 생각하는 영문 모드는 “IME가 영문 글자를 보내는 모드”가 아니라 IME가 아무 키도 처리하지 않고 그걸 응용 프로그램으로 그대로 보내 주는 모드이다. 이때 지원되는 쿼티 배열은 IME보다도 아래인 키보드 드라이버 차원에서 제공되는 기능이다.

그렇기 때문에 <날개셋>도 여러 입력 항목 중에 아무 글쇠도 처리하지 않는 모드를 반드시 갖추고 있어야 하며, 날개셋의 영문 모드가 아니라 “운영체제가 지정하는 영문 모드”로 진입해야 할 때는 날개셋 프로그램이 자신을 그런 모드로 동기화해야 한다. 그렇기 때문에 그런 상황에서는 '빈 입력 스키마'가 지정되는 것이다.

<날개셋>으로 드보락 글자판을 아무리 설정해 봐도 그것은 운영체제의 관점에서는 영문이 아니라 한글 모드일 뿐이다. 응용 프로그램의 단축키가 드보락 방식으로 바뀌지는 않는다. 그 드보락이 native 쿼티를 완전히 대체할 수는 없다는 것을 이 자리를 통해 다시 밝히는 바이다.

3.

음, 그리고 이번에도 한영 상태 관련 이슈이다.
지금이 한글 모드인지 영문 모드인지, 지정돼 있는 글자판을 좀 더 쉽게 알 수 있게 할 수 없느냐는 문의도 지금까지 종종 받았다.
옛날에 삼성 전자에서 개발한 워드 프로세서인 훈민정음이 생각난다. 한글 모드일 때는 cursor가 검은 반전이 아니라 빨간색으로 바뀌었었다...!

이미 한영 상태 표시를 위해 입력 도구모음(language bar)에 아이콘이 있기 때문에 본인은 그걸 놔 두고 구태여 또 다른 UI를 만들 생각은 없음을 밝힌다. 게다가 훈민정음처럼 cursor의 외형을 바꾸는 것은 워드 프로세서 같은 응용 프로그램의 영역이지 한낱 IME가 관여할 수 있는 영역도 아니다.

다만 Windows 8의 style(modern, metro) UI의 경우 language bar가 없기 때문에 별도의 시각적 피드백이 필요하다. 입력란으로 키보드 포커스가 가면 현재의 IME 입력 모드가 간단한 사각형 모양으로 잠깐 나타났다가 사라진다. 이것은 <날개셋>도 지원한다.
그러나 이 기능을 굳이 style UI 말고 기존 데스크톱 UI에까지 지원해야 할 필요를 느끼지는 않는다.

Posted by 사무엘

오늘날은 정말 전기 없이는 잠시도 돌아갈 수 없는 시대이다. 21세기엔 24시간 상시 켜져 있는 컴퓨터인 스마트폰을 사람마다 들고 돌아다니기 시작하면서 전기에 대한 의존도는 더욱 커져 있다.
교통수단들을 살펴봐도 그렇다. 전철에 목숨을 걸고 있는 철도 쪽은 말할 것도 없거니와, 자동차도 기름값이 워낙 오르니 하이브리드 내지 순수 전기 동력원이 주목을 받는 중이다.

굳이 동력원 자체가 아니더라도 엔진 내부 역시 종래엔 기계 제어이던 것이 다 전자 제어로 바뀌어서 어떤 형태로든 컴퓨터가 탑재되기 시작했다. 덕분에 교통수단들은 연료 소비 효율이 더 좋아지고 예전보다 사람이 신경을 덜 쓰고도 운행이 가능해졌지만, 한편으로 자동차의 경우 급발진 문제가 의심되고 있으며, 침수에 예전보다 더욱 취약해지기도 했다.

뭐 어쨌든..
교통수단이야 전차선이라도 있지 않은 이상 엔진의 힘으로 자가발전을 해야겠지만
붙박이 건물들이 사용하는 전기는 잘 알다시피 발전소라는 거대한 국가 기간 시설에서 생산된다. 예전에 심시티 게임을 할 때도 도시를 만들 때 가장 먼저 지어야 하는 시설은 바로 발전소였다. 스타크래프트 프로토스 종족으로 치면 파일런 같은 건물이다.
전기는 생산되는 직후 광속으로 흘러가 없어져 버린다는 특성상, 생산과 동시에 소비되어야 한다는 제약이 있다.

수력, 화력, 원자력, 풍력, 조력 등 우리가 생각하는 거의 모든 발전 방식은 결국 동력을 얻어서 발전기를 돌려서 전기를 생산한다.
그리고 동력 발전은 열을 만들어서 물을 끓이고 터빈을 돌리는 놈, 쉽게 말해 열기관이 주류이며, 화력이나 원자력, 심지어 열병합이 여기에 속한다.

화력 발전은 화석 연료를 사용하지만, 자동차 엔진에 달린 발전기 같은 내연기관 형태가 아니라 보통은 증기 터빈이라는 외연기관이 쓰인다. 아마 이게 출력과 효율이 더 좋아서 그런 게 아닌가 싶다.
그 반면, 무공해를 표방하는 일명 대체 에너지 발전 방식은 대부분 열 없이 자연의 힘으로 동력을 얻는 발전 방식 위주이다. 공해는 없지만 발전 용량이 메이저들보다 턱없이 부족한 게 흠이다.

수력 발전은 비록 원시적이지만, 정말 말 그대로 물의 위치 에너지, 즉 잠재적인(포텐셜) 에너지를 사용하여 발전한다는 특성상, 순발력이 좋고 전력 생산량의 제어가 용이한 게 매우 큰 장점이라고 한다.
날씨의 영향을 받는 여타 자연 동력 발전은 논의할 가치도 없거니와 화력도 기계적인 메커니즘이 간단하지 않기 때문에 풀가동 모드로 진입하는 데만 몇 시간씩 걸린다. 예열을 하고 증기를 만들기 위해서인지? 사실 거대한 디젤 엔진 선박만 해도 시동을 켜는 데만 수십 분 걸리는 건 기본이라고 한다.

원자력 발전소의 '원자로'는 이보다 더해서 초기화하는 데 거의 하루씩 걸리고 가동된 놈을 세우기란 막대한 손실을 감수하지 않고서는 불가능하다.
그렇기 때문에 한번 발전이 시작되면 전력 소비가 상대적으로 줄어드는 밤에도 잉여 전기는 낮과 별 차이 없이 계속 생산되어야 한다. 이걸 좀 쓰라고 우리나라는 진작부터 심야 전기 할인이 존재해 온 것이다.

여담이지만, 수력은 멈춰 있던 발전 설비의 첫 가동을 위해서 전기가 필요하지 않다는 특징도 있다. 자동차만 해도 배터리가 방전돼 버리면 시동을 못 거니 말이다.

원자력은 많고 많은 에너지원들 중에 어떤 형태로든 태양으로부터 전혀 유래되지 않은 유일한 에너지원이라 여겨진다. 굳이 태양광 발전 같은 게 아니어도 날씨나 물의 움직임에 의존하는 발전 방식은 전부 태양과 관계가 있으며, 심지어 화석 연료의 원천도 결국 태양 없이는 생길 수 없으니 말이다.

그러니 태양계 밖으로 나가는 우주 탐사선에는 원자력 전지가 탑재되는 것이 자연스러운 귀결이다. 지구 주변만 도는 인공위성 정도야 태양광 발전을 위한 집광판이 달려 있지만, 보이저/파이어니어 같은 탐사선에는 그런 게 없다. 걔네들은 공기 유체역학 원리로 비행하는 게 아니니 비행기 같은 날개도 없고 말이다.

원자력 발전은 20세기에 인간이 이룩한 위대하고 엄청난 과학 업적임이 분명하다. 물론 관리를 제대로 안 했을 경우 큰 위험에 빠지는 건 사실이나, 지금까지 찬란한 전기 문명 혜택은 실컷 입어 놓고는 대안도 없이 반대만 줄곧 늘어놓는 주장에는 선뜻 공감할 수가 없을 것이다.

한편, 말이 나왔으니 말인데 태양광 발전은 화학적 원리로 전기를 만들지 동력으로 전기를 만들지 않는다는 큰 차이가 있다. 태양열을 초대형 돋보기로 한데 모아서 물을 끓여서 터빈을 돌리는 게 아니니, 전통적인 발전 방식과는 발상이 다르다. 신기하지 않은가? 마치, 많고 많은 정렬 알고리즘 중에 '비교 연산'을 쓰지 않는 알고리즘을 보는 듯한 느낌이다. 빛으로 자가발전 내지 충전이 되는 손목시계나 계산기 같은 물건을 다시 보게 된다.

제한적으로는 사람의 힘으로 발전기를 돌리는 인력 발전도 생각할 수 있다. 주변에서 찾을 수 있는 제일 간단한 예는 자전거의 헤드라이트를 켜는 발전기인데, 어렸을 때부터 이게 무척 신기하긴 했다.
잘 알다시피 자전거의 바퀴와 발전기 바퀴를 연결만 시켜도... 자전거를 굴리는 데 드는 힘이 미세하게나마 더 증가한다. 전기 생산은 물리적으로 공짜가 아닌 것이다.

무슨 엔진 브레이크도 아니고, 전동차의 회생제동은 바로 이런 원리를 이용한 것이다. 기왕 속도를 줄이는데 전기나 더 생산하자는 발상.

교도소 수감자에게 징역형으로 다른 노동을 시킬 게 없으면, 몸으로 전력이라도 약하게나마 생산해서 할당량을 채우게 하는 것도 나쁘지 않을 것 같다. 운동도 되고. -_-;
물론, 겨우 사람이 만드는 전기는 동력 기관이 만드는 전기에 비해 양이 턱없이 부족하며, 전압도 불안정하기 때문에 전구 같이 밝기만 변하는 간단한 기기 말고 다른 정교한 기기에 바로 공급해 줘서는 곤란하다.

* 그나저나 영광과 울진 원자력 발전소가 이름을 바꾼 줄은 최근에야 알았다. 각각 한빛과 한울로. '광'이 '빛'으로, '울'은 공통으로 들어가는 글자라는 점을 생각하면 외우기 쉽다. 해당 지역의 이미지가 나빠진다는 이유로 2013년 5월부터 바꾼 거라고 하니 안타깝네. 고리와 월성은 지역명이 직접적으로 들어가 있지 않긴 하다.

Posted by 사무엘

Posted by 사무엘

작년 가을엔 <응답하라 199x>라는 레트로 장르의 TV 드라마가 인기가 많았다.
요즘은 사극 드라마라도 하나 방영되면 전국의 역덕후들이 벌떼처럼 일어나서 별 희한한 곳에서 고증 오류들을 찾아 올리는 게 관행이다. 이 드라마 역시 예외가 아니었다.

2013년 10월 18일 방영분에는 아래와 같은 유명한 장면이 나온다.

서울 지하철 1호선의 노선색이 빨간색이고 역명판이 둥글게 만들어져 있던 옛날 시절을 재현한 것까지는 좋다. 솔직히 말하면 본인조차도 그 실물을 본 적은 없다. 본인은 서울 태생이 아니며 서울 지하철을 이용하기 시작한 건 21세기부터이기 때문이다.

그럼에도 불구하고 저 장면에는 여러 크고 작은 고증 오류가 존재한다.
벽면의 인테리어가 실제 지하철 서울 역과 다르며 섬식 승강장 역을 상대식 승강장으로 만들어 놓은 건 애교라 친다만...
역명판의 글꼴을 2003년에 만들어진 걸로 쓰면 어떡하냐. 무려 코레일체!

20세기 설정에 너무 깔끔한 21세기 서체가 혼자 확 튀어 보인다.
게다가 저건 철도청/코레일의 전속 서체이지 서울 지하철에서 쓰던 서체도 아니다.
완전 어처구니없는 고증 오류가 아닐 수 없다.ㅋㅋㅋㅋㅋ

또한, 글꼴만치 부각되는 건 아니지만 '서울驛'이라는 한자 병기가 들어간 것도 오류다.
서울 지하철이 처음 개통했을 때는 역명판에 한자 병기가 없었기 때문이다. 그건 1999~2000년대가 돼서야 추가되었다. 딱 그 시기에 로마자 표기법 개정분 반영, 한자 병기와 더불어 국철(= 광역전철) + 지하철 노선색 통합까지 몽땅 진행되었으니 수도권 전철의 외형이 크게 바뀌는 시기였다.

그건 그렇고 아무튼...
그럼 1994년 기준으로 코레일체 대신 저기에 무슨 글꼴이 들어가야 맞는지 궁금하다면, 아래의 '진짜' 옛날 사진을 참고하시기 바란다. 엔하위키엔 관련 자료가 이미 다 올라와 있다. ㅎㅎ

시대를 풍미해 온 지금의 지하철 전속 서체와 같거나 최소한 비슷한 투의 납작한 헤드라인이 그때에도 쓰였다.
초롱테크에서 1990년대 중반에 정식으로 내놓은 그 디지털 서체는 그걸 좀 더 세련되게 다듬은 게 아닐까 싶다.

본인은 개인적으로 이 서체를 굉장히 좋아한다. 마치 런던 지하철의 전속 서체가 그야말로 런던 지하철 전체의 정체성을 대변하는 명물이 되어 있듯, 저 서체는 수도권 전철까지는 아니어도 서울 지하철을 대표하는 서체가 되기에 손색이 없다고 생각한다.

그런데 왜 그걸 함부로 바꾸고, 이미 만들어 놓은 멀쩡한 시설까지 돈 들여서 뜯어고치고 있는지 모를 일이다.
서울 도시철도 공사 관할역들의 경우, 지상에 있는 검은 배경의 세로형 역 폴사인의 서체가 어느 샌가 야금야금 서울 남산체로 바뀌고 있다.

오히려 지하철이 아니라 광역전철 소속이어서 우측도 아닌 좌측통행으로 건설된 신분당선이 클래식 지하철체를 살려 쓰고 있으니.. 혼란스럽다.

음, 그나저나 응답하라 1994의 오류가 또 생각 났다.
내가 언뜻 본 기억으로는 그 드라마 내부에서 등장하는 TV 뉴스 화면의 자막이...
굴림은 양반이고 아예 나눔고딕인 장면이 있었다!

서 태지가 은퇴하는 소식이 나오는 20세기 복고 드라마에, 2008년 한글날에 무료 배포된 서체가 등장한다는 게 말이 되냐.. ㅋㅋㅋㅋ

요즘은 유튜브만 검색하면 1990년대 옛날 영상 매체의 주요 장면을 아주 쉽게 구할 수 있다.
자막에다가는 엑스포체나 그래픽체만 넣었어도 지금으로부터 2, 30년 전의 영상 매체의 구리구리한(?) 분위기를 아주 손쉽게 낼 수 있었을 것이다. 무슨 서체를 쓰든 CG 처리는 똑같이 필요했을 텐데, 이게 무슨 돈이 더 드는 일도 아니고!

* 결론

1. 이렇듯 글꼴 유행도 시대에 따라 변한다.
2. 철도와 성경의 융합에 이어 철도와 글꼴의 융합도 얼마든지 가능하다.

Posted by 사무엘