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

1.
아래아한글의 역대 버전 중, 96과 97은 실행되면서 스플래시 화면이 나올 때 짤막한 효과음(음악 멜로디)이 나오던 전무후무한 버전이었다.
96은 경쾌한 사과나무.wav (도~~ 미파솔..로 시작하는)이었고 97은 그것 말고도 여러 종류의 음향이 더 추가되었다. 물론 워디안 이후 후대부터는 그런 것 없고. 이런 것도 다 일시적인 유행이었다.

오늘날은 아예 Windows조차도 8부터는 로그인 로그아웃 소리가 없어졌다.
먼 옛날 3.x 시절에 사운드 카드가 지원된 이래로, 시작 효과음은 그 유명한 tada.wav부터 시작해 뭐가 들어가도 들어갔는데.. 완전히 없어진 건 8이 처음이다.

응용 프로그램을 실행하는 게 옛날만치 그렇게 막 유세 떨 일이 아니게 되어서 그런 것 같다.
설치 프로그램이 원래 전체 화면을 차지하는 형태이다가 조그마한 마법사 대화상자로 바뀐 것도 비슷한 맥락일 것이고 말이다.

2.
지금이야 MS Office 제품들이 리본 UI를 사용하여 인터페이스가 여타 프로그램과는 완전히 다른 형태로 바뀌었지만..
먼 옛날, Office 95 시절이 문득 생각난다.
Windows 95의 출시에 맞춰서 완전히 32비트로 포팅된 첫 버전이었으며, 동시에 Office가 운영체제의 표준 메뉴 인터페이스를 사용하던 마지막 버전이었다.
다만, 약간의 애드립이 생각지 못한 곳에 있었는데.. 아래 스크린샷에서 프로그램 상단의 타이틀/캡션 바 영역을 보시라.

Office 95 프로그램들은 처음이자 마지막으로 캡션 바를 자체적으로 그렸다.
그래서 Microsoft는 그냥 일반 폰트가 아니라 그 당시 쓰이던 MS 로고타입 형태 그대로 그려졌으며, 검은색에서 짙은 군청으로 바뀌는 그러데이션이 적용되어 있었다.
잘 알다시피, 캡션 바에 그러데이션이 추가된 것은 윈도 98부터이지 95엔 아직 그런 게 없었다. 응용 프로그램이 WM_NCPAINT를 처리하여 직접 그렸던 것이다.

정말 일시적인 유행이었지만 그 시절에 외국 프로그램 중엔 캡션 바를 이 스타일을 따라 그렸던 프로그램도 소수 있었다.

3.
사실 Windows는 GUI 외형이 Mac OS에 비해 매우 단순한 편이었고, 그 대신 색상을 다양한 스타일로 지정할 수 있었다.
그러던 것이 XP 이후부터는 큰 변화가 생겼다. Luna 테마는 파랑-은색-황록이라는 세 색상표만 지원했고, Vista부터는 Aero 창틀의 색깔만 사용자 지정이 될 뿐 나머지 색상은 고정 불변이 됐다. 예전의 재래식 외형은 '고전 테마'라는 legacy로 전락했다.

시스템 색상을 customize할 일이 없어졌다. GetSysColor 함수는 원래 수십 가지의 색상 요소들을 제공하지만 응용 프로그램은 사실상 COLOR_WINDOW(TEXT), COLOR_HILIGHT(TEXT), COLOR_BTNFACE 같은 것밖에 사용할 일이 없어졌다. 그리고 사실은, 선택된 아이템을 표시할 때도 COLOR_HILIGHT나 반전(InvertRect)이 아니라 엷은 파랑 효과를 쓰는 게 유행이 됐다.

옛날에 Microsoft Plus! 같은 확장팩이 제공했던 '테마'들은 색상, 마우스 포인터, 효과음을 한데 모은 세트였지만.. 지금은 Windows도 맥 OS처럼 어찌 보면 사용자 선택의 폭을 좁히고 있다. 지금의 외형 자체가 곧 Windows의 정체성과 같다는 점을 더욱 내세우려는 것 같다. 색상표는 이제 사실상 시각 장애자 내지 전력 절약용으로나 의미가 있는 '고대비'밖에 안 남았다.

4.
Windows는 파일/디렉터리 목록을 이름 순으로 정렬해서 표시하더라도 디렉터리(폴더)와 파일은 따로 분류해서 보여주는 반면, Mac OS는 이들을 다 한데 섞어서 보여준다. 디렉터리도 특수한 형태의 파일로 볼 것이냐, 아니면 아무래도 파일과는 개념적으로 다른 존재로 보느냐의 차이 같다.
또한 마우스 휠을 인식하는 대상도 Windows는 키보드 포커스를 받고 있는 창이지만, Mac은 마우스 포인터가 놓여 있는 창이다.

참, 맥OS는 메뉴나 대화상자에 액셀러레이터 키가 전혀 없는 게 굉장히 뜻밖이다.

5.
유튜브나 스마트폰의 동영상 재생 앱 등... 요즘은 이게 유행인지 모르겠지만
대부분의 멀티미디어 재생 컴포넌트들은 Pause(||) 버튼만 있지, 완전 정지 Stop(■) 버튼이 없다.

파일을 열었으면 나중에 반드시 닫아야 한다는 프로그래머스러운 사고방식에 사로잡혀 있는 본인 같은 사람에겐 그런 디자인이 심리적으로 좀 불안하게 느껴지기까지 한다. 정말 Stop이 없어도 될까? 굳이 프로그래머가 아니더라도 옛날 카세트 및 비디오 테이프 재생기 역시 기계적인 특성 때문에 Pause와 Stop은 성격이 상당히 다르기도 했고 말이다.

하지만 리소스 제약 같은 걸 생각하지 말고, 사용자의 입장에서 오로지 틀고 싶을 때 틀고 끄고 싶을 때 끄는 것만 생각하면, 원론적으로야 둘을 굳이 구분할 필요가 없긴 해 보인다.

6.
top-to-bottom과 bottom-to-top이 헷갈릴 때가 종종 있다.
당장 좌표계만 해도 수학에서는 아래에서 위가 y축의 양의 방향이지만.. 컴퓨터 화면에서는 위에서 아래가 y축의 양의 방향이다.

Windows에는 spin, 혹은 up-down이라고 불리는 컨트롤이 있다.
얘는 언제나 위에 있는 ▲ 버튼 혹은 위(↑) 화살표 키를 눌렀을 때 숫자를 증가시키고, 그 반대의 조작을 하면 숫자를 감소시킨다.
안타깝게도 이 동작을 정반대로 바꾸는 방법은 없는 듯하다. 컨트롤의 동작을 교묘하게 서브클래싱하지 않는 이상 말이다.

저 컨트롤은 <날개셋> 한글 입력기의 제어판에서 입력 항목의 배열 순서를 바꾸는 용도로도 쓰이는데..
입력 항목들은 위에서 아래로 오름차순으로 배열되어 있다.
그래서 ↑가 아니라 ↓를 눌렀을 때 숫자가 증가하고 아래로 가게 하고 싶으나 그렇게는 못 하고 있다.
이건 솔직히 사용자를 굉장히 헷갈리게 만들 수도 있는 면모이다.

이 외에도, 노트북의 터치패드를 손가락으로 상하 드래그를 했는데, 위에서 아래로 그었을 때 화면을 위에서 아래로 스크롤시킬지, 반대로 아래에서 위로 스크롤시킬지도 보통은 옵션으로 존재한다.
본인이 선호하는 건 위에서 아래로 그었을 때 화면은 아래에서 위로, 즉, 아래 페이지의 내용을 표시하는 것이다. ↓ 키를 눌렀을 때와 같다. 손가락은 전체 내용에 대한 화면(view)의 상대적인 위치와 같은 것이다.

그러나 손가락의 위치를 지금 표시되어 있는 텍스트의 상대적인 위치와 같은 것으로 본다면.. 소프트웨어의 동작은 저것과는 반대가 되어야 직관적일 것이다. 결국 이것은 사람마다 취향이 다른 답이 없는 문제이다.

Posted by 사무엘

지난 설 명절 땐 고향을 방문하여 주변에서 여러 의미 있는 일들을 치렀다.

1. 변 정용 교수님 만남

고향집에서 가장 가까운 대학교에 이런 교수님이 계신 건 예전부터 알고 있었는데.. 작년 가을쯤에 드디어 개인적으로 연락이 됐고, 개인적인 만남까지 성사되었다. 오오~~!

그분도 자기와 관심분야가 가까운 젊은이가 이렇게 가까운 곳에 살고 있다니 굉장히 반가워하셨고.
짤막하게나마 그분의 한글과 훈민정음 견해, 북한의 학자들과 교류하느라 평양 시내와 금강산 실물을 진작부터 몇 번이나 구경했던 이야기, 각종 학계와 업계 사정 이야기 등등을 들었다. 국가보안법을 어기면서 몰래 갔다 온 게 아니요, 달러 엄청 뜯기면서 단순 관광객으로 갔다 온 것도 아니니 부럽다.

난 내가 14년째 만들고 있는 프로그램 하나로 이 바닥에서는 이름이 언급되지 않을 수 없는 수준의 업적을 남겼고, 확실히 전문가로 인정받고 있는 걸 알 수 있었다.

“석사도 아니고 박사 정도 되면, 뭘로 학위논문을 썼는지가 학계· 업계에서 어딜 가나... 너의 얼굴이자 자존심이자 프로필과 스펙으로서 평생 따라다닐 것이다. 그러니 그게 평생 밥줄 수준인 연구 주제가 될 수 있어야 된다”라고 충고를 하시더라. 난 물론 그걸 생각하고 있다고 말씀드렸다.

아무튼, 이쪽으로 기를 충전(?)하고 돌아오니.. 난 코레일 공채 준비하지 않아도 원래 본업으로 먹고 살 수도 있겠다는 생각이 들어서 좋았다. ^^

내가 나 자신에 대해 개인적으로 아쉬운 걸 굳이 하나 짚자면.. 남들처럼 20대가 가기 전에 박사 학위를 후딱 받지 못하고, 인제 입문해서 뒤늦게 시작했다는 것이다. 하지만 난 그 대신 그 전에 저런 걸 이뤄 놨다.
그리고, 남들은 자기가 좋아하는 것, 하고 싶은 걸 꾹~ 참고 억제하고 노력해서 목표를 성취한 것이며, 특히 이공계는 비록 인문계보다야 졸업이 이르고 취업도 더 잘 되겠지만 그 대신 군기 센 폐쇄적인 집단 안에 틀어박혀서 고생도 훨씬 더 한다.

그 반면 나는 덕업일치 형태로 전혀 힘든 것 없이 완전 널널하게 목표를 성취한 거다. 그런데도 성취 시기가 서로 똑같기를 바라는 거야말로 도둑놈 심보가 아닐까 한다.

2. 시내 간이역 답사

차 끌고 나가서 국도 7호선을 따라 동해남부선 동방, 불국사, 죽동 역을, 그리고 국도 4호선 따라 중앙선 모량, 건천 역을, 끝으로 국도 20호선과 지방도 68호선 따라 동해남부선 나원 역을 답사하여 사진을 찍고 무사히 귀환했다.
늘 이용하는 경주, 서경주, 신경주 말고 경주에 있는 다른 마이너 역들을 거의 다 답사했다. 자동차는 이런 훈훈한 일을 하는 데 쓰라고 있는 거다.

이 중 영업을 하고 여객열차가 정차까지 하는 역은 불국사와 건천뿐이고
직원은 있지만 여객 취급을 안 하는 역은 나원.
건물만 있고 주변이 폐쇄된 역은 동방, 모량.
죽동은 그냥 임시승강장만 있고 사실상 폐역 상태다. 주변에 울산-포항 고속도로(고속국도 65호선)가 건설되고 있었다.

간이역에 도착할 때마다 뭔가.. 경건해지고 내 마음의 고향, 종교적인 성지를 방문하는 듯한 느낌이다.
일부 간이역은 이미 코레일이 매각하여 민간 상업용 건물로 전환된 경우가 있다. 동해남부선 모화 역이 대표적인 예인데..
이건 유럽에 크리스천들이 갈수록 감소해서 교회 예배당 건물이 나이트클럽이나 무슬림 예배당으로 바뀌는 것과 같은 차원의 비극이다.

아아 철도여! 이름만 들어도 가슴이 설레는 교통수단이다.

3. 1992년 세계 자동차 연감

초딩 시절 나의 자동차 수련의 잔재를 고향집에서 모처럼 발견했다.
1992년도 세계 자동차 연감. 어머니께서 20년 전 물가로 무려 39000원이나 하는 비싼 물건을 나를 위해 사 주셨다!

그도 그럴 것이 수백 페이지 분량에 달하는 자동차 화보가 올컬러로 고급 코팅지에 인쇄돼 있어서.. 비싼 게 수긍이 간다.

견출명조 + 헤드라인 서체는 정말 1990년대 광고 전단지의 클리셰다. 응4, 응7 같은 레트로 영상 매체를 만드는 분이라면 고증에 참고할 필요가 있다.
그리고 저 때는 신명 시스템 서체의 리즈 시절이기도 했다. 저 책도 페이지 번호는 SM중고딕, 본문은 SM신명조더라.
당장 저 표지의 '1992'는 악보의 번호에 즐겨 쓰이던 Bodoni라는 외국 서체이고.

쏘나타 2, 뉴 엑셀, 엘란트라, 에스페로 같은 추억의 자동차를 다시 만나 볼 수 있다. 대우는 물론이고 아시아 자동차(RV 록스타)까지 나와 있다.
어렸을 때 나는 일본 미쓰비시의 데보네어 V가 우리나라 그랜저를 베낀 거라고 아주 애국심 충만하게 생각했었다. -_-;;;

부록에 우리나라 자동차 연표가 나와 있어서 이건 매 페이지를 폰 카메라로 찍었다. 철도사가 일부 실려 있기도 해서 더욱 귀중한 자료다.

4. 김 문수 목사님 만남

이분은 PC 통신 프로그래밍 동호회를 통해 거의 1990년대 중반(나의 중고딩 시절)부터 알긴 했는데, 그 뒤 소식이 끊어졌다가 먼 훗날 킹 제임스 성경 진영에서 극적으로 다시 만난 분이다.
목사가 된 뒤엔 사랑 침례 교회에 잠시 계시다가 포항을 거쳐 부산 제일 성서 침례 교회에서 자리를 잡으셨다. 내 고향에서야 1시간 남짓한 거리이니 한번 찾아뵙고 왔다. 목사님 부부도 날 아주 좋아하면서 반갑게 맞이해 주셨다.

교회가 역사가 길고 자체적인 부지와 예배당--좀 낡긴 했지만--을 갖추고 있다 보니, 건물 임대료 지출이 없는 것은 재정에 굉장한 도움이 될 것 같았다. (한국 교회가 괜히 '성전 건축'을 강조한 게 아닌 듯. ㅎㅎ)
영남의 대도시에 흠정역을 쓰는 지역 교회가 생긴 것을 기쁘게 생각한다. 부산 대학교를 포함해 금정산 기슭의 각종 학교들하고도 가까이 있는데 학생들이 많이 왔으면 좋겠다.

사랑 침례 교회와의 관계는 어찌 된 건지 궁금해하시는 분이 계실지 모르니 짤막하게만 언급하자면, 역시 좁은 바닥에 태양이 둘일 수는 없고 목회 철학과 사역 방식, 가치관의 차이 때문에 서로 독립한 것에 가깝다. 이분 역시 사랑 침례 교회에서도 담임목사직을 즉시 완전히 승계하는 게 아닌 이상, 애초에 거기서 오래 계실 걸 생각하지도 않으셨다고 하고.

큰 교회에서 재직하는 부목사들은 어김없이 가능한 한 독립과 개척을 생각하고 있다는 걸 실감했다. 다른 업종이 아니고 교육자이니 어지간히 열악해도 자기만의 살림을 차리고 싶어하는구나. 의사가 개인 병원 차리냐 그냥 페이닥터로 지내느냐, 변호사가 개인 사무실을 차리냐 아니면 대형 로펌에 취직해서 월급만 받고 사느냐를 고민하는 그런 차원과는 확실히 다르다.

이동 시간까지 포함하면 거의 4시간 가까이 얘기를 나눴지만 그래도 시간이 부족했다. 위치가 부산 북부이니 갈 때는 응당 노포동 버스 터미널을 이용했지만, 돌아올 때는 동래 역에서 동해남부선 열차를 이용했다.
서울은 시내에 있던 단선 철도가 전부 복선 전철로 바뀌거나 아니면 폐선되는 등 확실하게 정리가 되었지만, 부산은 시내를 깊숙히 파고드는 단선 비전철과 간이역이 있으니 아주 인상적이었다.

Posted by 사무엘

자, 오늘은 아주 간단한 Windows API 프로그래밍 퀴즈를 하나 내겠다.
다음과 같은 창을 만들려면 어떻게 해야 할까? (닫기 X 버튼이 사용 불가)

닫기 버튼 말고 최소화 및 최대화 버튼이야 윈도우의 스타일이라는 형태로 지정 가능하다.
WS_MINIMIZE/WS_MAXIMIZE와 WS_MINIMIZEBOX/WS_MAXIMIZEBOX가 있는데, BOX가 붙은 비트는 이 창에 해당 버튼과 기능을 제공하라는 뜻이다. 그리고 BOX가 없는 비트는 이 창이 현재 실제로 최소화됐거나 최대화돼 있음을 나타낸다.

즉, 프로그램이 지정하는 속성 정보와, 사용자가 변경하는 상태 정보가 비트값만 달리하여 동일 스타일에 한데 담겨 있다. 이건 개인적으로는 좀 이상한 설계라고 생각한다. 뭐 그건 그렇고...

그런데 닫기 버튼은 이런 스타일의 형태로 존재하지 않는다.
사실, UI 디자인 상으로도 응용 프로그램은 사용자에게 뭔가 강압적인 요소를 가능한 한 만들지 않아야 하며, 모든 창은 사용자가 언제라도 닫을 수 있어야 한다. [X] 버튼이 없는 창을 접할 일은 극히 드물다. 이는 오늘날처럼 언제라도 task switch가 가능한 선점형 멀티태스킹 환경에서는 더욱 그러하다.

창에 시스템 메뉴 자체를 완전히 없애서 [X]버튼을 없애는 것 말고 저렇게 [X] 버튼을 disable만 시키는 간단한 방법은 시스템 메뉴에서 SC_CLOSE를 없애거나 disable시키는 것이다. 창의 WM_CREATE 메시지에서 이렇게 해 주면 된다.

HMENU h = ::GetSystemMenu(hWnd, FALSE);
::RemoveMenu(h, SC_CLOSE, MF_BYCOMMAND);

요렇게 해 주면 캡션에 달린 [X]버튼도 같이 영향을 받게 된다. [X]버튼뿐만 아니라 시스템 메뉴를 더블클릭해도 창이 닫히지 않는다.

그런데, 외형상 닫기 버튼을 없애는 것은 마우스를 통한 닫기 동작을 차단해 주는 반면, 키보드 Alt+F4를 차단하지는 못한다.
물론, 이런 메시지가 왔을 때 닫는 반응을 안 하도록 WM_CLOSE 메시지나 IDCANCEL을 차단하는 식으로 별도의 처리를 할 수도 있지만, 운영체제 차원에서 창을 닫으려는 시도를 원천차단하는 방법은 따로 있다.

이것은 윈도우의 스타일에 있는 게 아니라, 윈도우 클래스의 스타일에 있다.
바로 CS_NOCLOSE 되시겠다.
아무 창에나 쉽게 쓰이는 속성이 아니라고 판단되었는지 윈도우의 스타일이 아니라 클래스의 스타일로 분류되었다. 뭐, 역사적으로는 [X] 버튼 자체가 윈도 95/NT에서 처음 등장한 것이기 때문에 최소화/최대화 버튼하고는 API가 들어갈 위치가 다르기도 했고 말이다.

윈도우 클래스를 등록할 때 저 스타일을 준 윈도우는 윈도우 프로시저에서 WM_CREATE 때 시스템 메뉴 조작 같은 걸 하지 않아도 시스템 메뉴에 '닫기' 명령이 등재되지 않으며, [X] 버튼이 자동으로 흐리게 표시된다. 그리고 Alt+F4를 눌러도 자동으로 닫히지 않는다.
응용 프로그램이 직접 제공하는 '종료' 명령으로 WM_CLOSE 메시지를 날려 줘야만 닫을 수 있다. 아니면 프로세스를 강제로 죽이든가.

MDI 차일드 윈도우도 이런 스타일이 지정된 클래스에 소속된 놈으로 지정할 수 있다. 그렇기 때문에 MDI 창들 중에도 절대로 닫히지 않고 언제나 떠 있어야 하는 고정 붙박이 윈도우는 요렇게 따로 배치하는 게 가능하다.

화면을 다 차지한 채 Z-순서가 바뀌지도 않고(WS_EX_TOPMOST) 닫히지도 않는 창이 떠 있다면, 거기에다 키보드/마우스/메시지 훅만 추가해서 다른 프로그램으로 작업 전환도 되지 않게 해서 포커스를 특정 프로그램이 사실상 독점할 수도 있다. 특정 프로그램만 뜬 채로 통제를 벗어나지 않아야 하는 공공장소의 특수 목적 PC에서 돌아가는 프로그램은 이런 기능을 활용하면 만들 수 있을 듯하다.

16비트 윈도 시절에는 특정 프로그램이 시스템의 자원을 독점하기가 훨씬 더 쉬웠고 그때는 그냥 modal이 아니라 system modal이라는 기능이 버젓이 존재했다. 이 창을 닫기 전에는 아예 다른 프로그램으로 Alt+Tab 작업 전환도 안 되는 거다.

물론 이런 강압적인 기능은 32비트 이후부터는 공식적으로 삭제되었지만 이것의 영향을 받았는지 윈도 NT 계열과는 달리 9x 계열은 메시지 대화상자에도 그 잔재가 여전히 남아 있었다. 취소 버튼이 없이 '확인'만 있는 메시지 박스는 시스템 메뉴에 '닫기'가 존재하지 않았으며 [X] 버튼이 클릭 가능하지 않았다. 단, 그래도 키보드의 ESC나 Alt+F4는 동작한다.

Posted by 사무엘

2014년에 처음으로 나올 <날개셋> 한글 입력기의 다음 버전은 7.4로 정해졌으며 한창 개발 중이다. 지금까지 작업이 완료된 변화 내역은 다음과 같다.

1. 현재 MS 한글 IME의 사전을 이용하여 단어 단위로 한자를 변환하는 기능이 제공되고 있는데, 원래 있는 사전뿐만 아니라 MS IME에다 사용자가 등록해 놓은 custom 사전의 내용도 목록에 같이 뜨게 했다.

2. 제어판의 '편집기 계층'에서 옵션을 바꾼 뒤 '확인' 종료를 하면, 제4후보 설정들이 날아가 버리는 약간 중대한 버그가 있었다. 이것을 고쳤다. 사용자 정의 후보가 첫 추가된 7.0 이래로 존재했던 버그이며, 7.11에 존재하던 사실상 유일한 버그였다. 게다가 이것은 7.11만의 버그도 아니니 이번 7.11은 딱히 고쳐져야 할 게 없이 정말 완성도 높게 잘 만들어지긴 했다.

3. 낱자 수정 모드로 진입했을 때 전체 반전이 아니라 사각형 테두리 모양의 cursor가 거의 10년 만에 부활했다. 물론 이건 외부 모듈 말고 <날개셋> 편집기만으로 한정이다.

아마 아시는 분이 많지 않겠지만... <날개셋> 한글 입력기에는 낱자 수정 모드라는 게 있다. 삽입/겹침이 '겹침'에 맞춰져 있고(Ins 키), 낱자/글자가 '낱자'로 맞춰져 있는 경우(Shift+Ins), '가'를 '개'나 '나'로 곧바로 고친다거나 '강'으로 한 타 만에 고칠 수 있다. 글자를 처음부터 다시 입력해야 할 필요가 없다. 이것은 무려 1.0 첫 버전부터 긴 역사를 자랑하며 지원되어 온 기능이다.

낱자 수정 모드도 엄밀히 말하면 한글 조합 상태이긴 하지만 여느 상태와는 다르다. <날개셋> 편집기는 삽입/겹침이나 한글/영문이 아니라 낱자 수정 상태만을 별도의 cursor 모양으로 표시해 주고 있었는데.. 이건 까마득한 옛 버전인 1.x와 2.x까지만으로 한정되었다.

에디팅 엔진이 완전히 교체되고 운영체제의 표준 cursor를 사용하기 시작한 3.0부터는 낱자 수정 모드 자체는 존재하지만 다른 시각 피드백 구분이 없어졌으며, 그 관행이 2004년 이래로 10년째 지속되어 왔었다. 테두리 cursor는 10년 가까이 봉인되었다가 드디어 이번 버전에서 부활할 예정이다.

4. 외부 모듈에서 '빈 입력 스키마' 내지 '빈 입력 스키마 호환 옵션이 지정된 영문 쿼티'를 없앤 상태로 '확인'을 누르면 아예 경고문이 나타나게 했다. 링크를 클릭하면 더 자세한 도움말 설명도 나타난다.
쿼티를 없애고 드보락만 지정했는데 '빈 입력 스키마'가 자꾸 자동으로 추가돼서 이상하다는 문의가 지금까지 하도 많이 들어와서 말이다.

그렇게 IME가 인위로 글쇠를 생성하는 글자판은 비록 영문을 입력하는 방식이라 할지라도 기술적으로는 한글 모드일 뿐이다. IME가 아무 글쇠도 처리하지 않고 한국어 키보드 드라이버에 배당되어 있는 쿼티 방식 그대로 글쇠를 보내는 모드가 아예 없을 수는 없다.

5. 또한 이와 비슷한 매락에서, 단축글쇠 배당 대화상자에서는 Ctrl/Alt의 경우 오른쪽 방향은 인식되지 않을 수 있다는 경고문도 간단히 추가했다. 한국어 키보드 드라이버는 이들 글쇠를 한영/한자 키로 인식하기 때문이다.
<날개셋> 편집기야 자체 한글 기반이기 때문에 한국어가 아닌 여타 외국어 글쇠배열을 사용하다가 자체 한글 입력 모드로 들어가면 오른쪽 Ctrl/Alt를 인식 가능할 수도 있다. 그러나 외부 모듈은 그 자체가 한글 IME이고 무조건 한국어 키보드 드라이버와만 연결되기 때문에 그런 선택의 여지가 없다.

6. <날개셋> 한글 입력기는 MS IME와 마찬가지로 유니코드 BMP 영역에 있는 모든 한자들을 독음으로 입력할 수 있다. 그러나 현실에서 상용 한자 이외의 한자가 쓰이는 일은 매우 드물다. 그렇기 때문에, 좀 잉여스러워 보이긴 하지만 MS IME와 마찬가지로 '확장 한자 사용' 옵션을 켰을 때만 모든 한자들이 다 보이고 평소에는 상용 한자 4888자만 나타나게 했다. 이렇게 하는 게 처리 속도도 더 빠르고 말이다.
물론 이것은 사용자 후보나 단어 단위 한자 변환 동작에는 전혀 영향을 주지 않는다. 한글 하나만을 제1 후보 방식으로 기본 변환할 때에 한해서이다.

7. 편집기는 문서를 저장할 때 이미 있던 파일에다 덮어쓰는 경우, 임시 파일을 생성하여 저장한 뒤 임시 파일의 저장이 완전히 성공한 뒤에야 기존 파일을 지우고 임시 파일을 개명하는 방식으로 동작하게 했다. 저장 중에 프로그램이 뻗더라도 파일 내용이 송두리째 날아가는 일은 발생하지 않게 조치를 취했다. 어찌 보면 안전을 위한 기본 조치인데 <날개셋> 편집기는 지금까지 그런 정책을 채택하지 않고 있었다.
디스크의 용량이 극도로 부족할 때는 예외적으로 그렇게 복사본을 만들지 않게 하는 알고리즘도 필요할 듯도 하지만 일단은 거기까지 고려는 하지 않게 했다.

그리고 안전한 저장이라 하니까 생각하는데, <날개셋> 편집기는 자동 저장 기능은 여전히 지원하지 않으며 개발 계획에도 없다.

8. 다음으로 아주 잉여로운 GUI 변화 사항으로는...
TSF 시스템이 없는 운영체제에서는(Windows XP 미만의 초 구닥다리) 편집기의 'TSF 지원' 옵션이 흐리게 나오고, 자체 한자어 사전이 없는 운영체제에서는(Vista 미만) '단어 단위 한자 변환' 옵션이 흐리게 나오는 당연한 조치를 취했다. 물론 오늘날 운영체제에서는 아무 의미 없는 조치이지만, <날개셋> 한글 입력기는 공식적으로는 32비트 에디션 기준으로 윈도 95에서도 완벽하게 실행되는 거의 변태 같은 프로그램이기 때문에.. ㅎㅎ

- 블로그에 공지했던 입력 방식 유료 컨설팅 관련 설명은 도움말의 '일러두기'에도 당연히 짤막하게 추가되었다.

- UTF-8, UTF-16LE 같은 몇몇 용어를 표준 표기에 맞게 수정했으며,
- 빠른설정을 선택하는 목록 메뉴에서 '한글 로마자 입력기'가 신세벌식이나 복벌식보다 더 앞에, '기본 입력 설정' 바로 다음으로 나오게 순서를 변경했다. 이유는 두 말할 나위 없이 로마자 입력 방식이 두벌식/세벌식 다음으로 가장 널리 쓰인다고 판단되기 때문이다.

메이저한 굵직한 기능을 추가하기도 전에 사소한 변화 사항도 벌써 이만치 나왔다. 재미있다.
이런 경험들이 하나씩 쌓이면서 프로그램의 완성도는 갈수록 상승한다.

이미 보신 분도 계시겠지만, 사실 지난 1월에는 <날개셋> 한글 입력기 소개 페이지도 싹 갈아엎었다. 문서 만드는 게 코딩 이상으로 더 힘들 수 있다는 걸 실감한 시간이었다.

첫 화면에는 이 프로그램이 무엇인지 그 본질을 최대한 단순· 간단하게 소개한 뒤, 다운로드 페이지는 별도로 마련하고
프로그램에 대한 자랑질은 (1) 입력 아키텍처 쪽, (2) 세벌식 위주의 고급 활용 기능, (3) 편집기 및 외부 모듈 같은 구현체 소개
이렇게 세 단계로 완전히 세분화를 했다.

특히 (2)번의 경우.. 팔자에도 없던 움짤(gif)까지 최초로 만들어서..
기존 입력기에서는 이렇게 불편하게 고쳐야 하는 것을 이 프로그램으로 세벌식 + 관련 설정을 바꾸면 저렇게 곧바로 가능하다는 걸 바로 알 수 있게 했다. 왜 지금까지 이렇게 만들 생각을 안 했나 모르겠다.

마지막 '간단한 사용법'은 이 프로그램을 받아 놓고 도대체 무슨 기능부터 써 봐야 할지를 모를 사용자를 위한 팁 모음 같은 페이지이다.
내가 왜 코레일로 이직을 못 하고 있는지 궁금하신 분들은 한번 구경해 보시길~~ ㅎㅎ

다음으로 <날개셋> 타자연습이다.
타자연습의 경우 지난 2013년 한 해 동안은 새 버전 소식이 없었다.
그러다가 올해 초에는 입력기 7.4와 더불어 타자연습도 3.4가 나올 예정이다.

큰 기능 변화는 없고 아기자기한 외형 변경, 고해상도(high DPI) 모드에서의 일부 외형 glitch 수정 등이 이뤄졌다.
작은 크기에서 기존 32*32 아이콘을 줄인 밍밍한 아이콘이 아니라, 깔끔한 소형 전용 아이콘이 나오는 것을 주목할 것.
그리고 이번 기회에 연습글을 상당수 교체할 예정이다.

단문 연습용으로 너무 식상한 속담· 격언을 넘어서서 김성모 화백 어록이 제공된 게 지금까지 반응이 무척 좋았다. "내가 무릎을 꿇었던 건 추진력을 얻기 위함이었다" 같은 드립이 타자 연습글로 나오니까..ㅎㅎ
이번에는 일반 인터넷 유행어도 추가되어 "저 새는 해로운 새다" "찰지구나" "안녕하신가 힘세고 강한 아침" "병시나 산소" 등이 연습글로 제공될 예정이다.

그리고 허 성도 교수의 <우리 역사 다시 보기> 강연 녹취록을 적당히 편집하여 새 연습글로 추가했다. 분량도 적당히 많고, 내용 역시 매우 건전하고 훈훈하고 이념스러운 것 없고, 전국민에게 알릴 필요가 있는 좋은 내용이기에 즉시 추가했음.

이것 외에도 혹시 추가할 만한 좋은 연습글 있으면 추천받는다.
잘 알려지지 않은 인물의 선행/성공 일대기, 특정 사회 시스템을 돌아가게 하는 내부 사정 이야기, 언어 특성을 잘 살린 탁월한 운문이나 수필 등등이 좋을 것 같다..
아울러, <방망이 깎던 노인> 내지 <은전 한 닢>의 패러디 중 하나가 "재미있는 이야기" 카테고리에 들어갈 가능성이 있다.

끝으로, 세벌식 파워업도 2013년 한 해 동안 버전업이 없다가 최근에 간단한 업데이트가 행해졌다.
다른 프로그램을 사용하다가 파워업의 꼬마 윈도우를 클릭했을 때, "x벌식으로 바꿨습니다"와 함께 키보드 포커스가 잠깐 밖으로 나갔다가 다시 돌아와야 하는데..
지금까지 그렇지가 않아서 IE 11 같은 프로그램에서 글자판 전환이 곧장 반영되지 않던 문제가 있었다.
이번 패치는 이 문제를 해결했다.

IE 9와 IE 10에서 모두 원래 관찮았는데 하필 Windows 8.1 + IE 11에만 문제가 있는 걸 사용자의 제보를 통해 확인했다.

이상, 입력기, 입력기 소개 페이지, 타자연습에 파워업까지.. 오랜만에 본인의 본업 관련 소식을 쭉 전했다. 새해에는 세벌식 글자판이 더욱 널리 알려지고 쓰였으면 좋겠다.

Posted by 사무엘

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

글자 입력란에서 깜빡거리고 있는 길쭉한 세로줄(|)을 우리는 보통 '커서'라고 부르고 영어로 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 사무엘