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

1. 마디가 홀수 개만 있는 3박자 계열 곡

대표적인 예가 무엇이냐 하면 <예수 따라가며>(Trust and obey)에서 "..." 부분,
그리고 <구주를 생각만 해도>(Jesus, the very thought of thee)에서 "..." 부분,
<나 같은 죄인 살리신>(Amazing grace)에서 "..." 부분이다. 생각보다 예가 많다.

내가 적절한 용어를 몰라서 묶음 단위를 편의상 그냥 '단'이라고만 부르겠다.
대부분의 찬송가들은 못갖춘마디를 감안하더라도 한 절이 보통 기승전결 4개의 단으로 구성되고 각 단은 4개의 마디로 이뤄져서 총 16마디로 돼 있다.

그러나 위의 곡들은 무슨 이유인지 둘째 단은 마디가 4개가 아니라 3개만 있다.
그래서 마지막 마디를 한 마디만 부르고 곧장 다음 단으로 넘어가는 게 심리적으로 굉장히 불안하고 어색하다. 반주자도, 찬양 인도자도, 회중들도 여기서는 좀 멈칫 한다. 마디를 하나 더 추가하고 싶어진다.
실제로 <나 같은 죄인 살리신>의 경우, 21세기 새찬송가에서는 마디를 하나 더 추가해 버리기도 했다. 찬송가 편찬자들이 보기에도 홀수 마디는 너무 어색했는가 보다. 아래 두 악보를 대조해 보시라.

원곡의 작곡자는 무엇을 의도하고 둘째 단에는 마디를 홀수 개만 넣었는지 모르겠다.
이건 6박자 계열도 아니고(6/4 또는 6/8) 엄연히 3박자인데 굳이 마디 수를 반드시 짝수 개로 맞춰야만 할 필요는 없다는 식으로 반론이 혹시 있을지도 모르겠으나, 그래도 홀수 마디는 영 아닌 것 같다.

2. 못갖춘마디의 박자 구획

<날 위하여 십자가의>(How can I keep from singing)는 보다시피 '어찌 찬양 안 할까'라고 번역된 맨 마지막 단 가사가 원제목이다.
우리나라에서는 찬송가들이 고유 제목 대신, 닥치고 가사 첫 줄을 곧 곡을 식별하는 제목으로 취급하는 게 관행이 돼 있다. 어차피 대부분의 찬송가들이 외국곡 번역이다 보니 원제목이 무엇인지는 별로 중요하지 않을지도 모르나, 국내 창작곡에 대해서는 문제가 생길 수 있다. <당신을 향한 노래>를 <아주 먼 옛날 하늘에서는>으로 바꿔서 적는다는 얘기니까 말이다.

뭐, 제목은 그렇고.. 내가 이 곡에 굉장히 불만인 것은, 박자가 굉장히 이상해지는 형태로 못갖춘마디의 구분이 되어 있다는 것이다.
찬송가 책들을 보면 얘는 다음 그림에서 A 형태로 기보되어 있다. 그러나 사람들이 실제로 부르면서 강약약 박자를 느끼는 건 B 형태이다.

다시 말해 이 곡은 <사랑하는 주님 앞에 형제 자매 한 자리에>의 전반부 3/2박자 부분하고 리듬과 박자가 완전히 동일하다는 뜻이다. 못갖춘마디를 저렇게 적어야 할 이유는 하등 존재하지 않는다.
억지로 끼워 맞춰 보면 악보대로 박자를 맞추는 게 아주 불가능하지는 않으며, 한국어 번역 기준으로 기능어가 아닌 내용어에 강박이 더 걸리는 장점도 있다. 하지만 멜로디의 흐름은 그 박자와 전혀 어울리지 않는다. 그래서 애국가의 앞부분처럼 박자가 어색하고 연상거부가 심하다.

저렇게 우리나라 애국가 스타일로 박자가 아주 이상한 예가 하나 더 떠오른다. 바로 <예수가 거느리시니>(He leadeth me; O blessed thought)의 후렴 "주 날 항상 돌보시고" 부분이다.

'주'가 약박이고 '날 항상 돌'이 '강 약 중강 약'이 들어가야 하지만, 실제 멜로디는 홀수 박자가 아니라 짝수 박자가 음높이가 높고 영락없이 강박이다. 그래서 쓰기는 A처럼 써졌지만 부르기는 B처럼 불러지며, 이 때문에 뒷부분에 박자는 자연스럽게 연결되지 않게 된다. 교회 다니는 분이라면 정말 그런지 한번 직접 불러 보시라.

찬송가도 가끔은 이렇게 비판적인 안목으로 볼 필요가 있는 것 같다.
그리고 굳이 찬송가에만 국한되는 이야기는 아니겠지만, 외국곡의 가사를 번역할 때는 가능한 한 내용어는 강박에, 기능어는 약박에 배치해서 부르기 자연스럽고 쉽게 했으면 좋겠다.

* 잡설

1.
악보에서 스타카토 같은 꾸밈음 기호는 C/C++로 치면 매크로와 같은 구석이 있다고 본인은 옛날에 글을 쓴 적이 있었다. 음악 시간에 '적기' / '내기'라고 기보법을 배우는 건 영락없이
#define STACCATO(pitch, interval)  play(pitch, interval/2); pause(interval/2) 이런 꼴이니까 말이다.
그럼 페르마타(늘임표)는 C/C++로 치면 register나 inline와 비슷해 보인다. 늘이는 것이 권장 사항이지만 그래도 연주자의 재량껏 무시할 수도 있으니까 말이다.

2.
군대에서 유격 훈련을 정신없이 받다 보면 <어머니의 마음>을 부르다가 후렴은 <스승의 은혜>로 넘어가기 쉽다고 한다. 둘은 동일한 3/4박자에 조와 분위기도 비슷한 편이다.
그런 것처럼 찬송가에도 분위기가 비슷하고 메들리로 엮기 좋은 pair가 몇 쌍 있다.

• 내 죄 사함 받고서 → 내가 매일 기쁘게 순례의 길 행함은: 구원 + 성령 동행. 둘 다 경쾌하고 명랑하다.
• 내 모든 시험 무거운 짐을 → 내 모든 소원 기도의 제목: 위로와 평안, 간구 쪽으로 좋은 조합이다.
• 하나님 아버지 주신 책은 → 달고 오묘한 그 말씀: 성경 카테고리. 내가 교회 청년부 찬양 때 실제로 메들리를 시도하기도 했다. 작사· 작곡자가 동일하고 굉장히 좋은 조합임. (단, 전자곡은 극초반만 빼면 나머지 가사는 성경이라기보다는 구원 카테고리에 더 가까운 내용이다.)
• 내 주의 보혈은 → 이 세상 험하고: 서로 다른 작곡자의 곡이지만 리듬과 멜로디가 아주 비슷하며, 구원에서 신뢰와 확신 카테고리로 주제가 잘 넘어간다.

3.
끝으로, 이건 멜로디가 아닌 가사 얘기이며, 번역도 아니라 영어 원가사 얘기이다.
찬송가 가사 중에는 영어로는 "예수님은 내 꺼"라는 표현이 있다. 그것도 옛날 클래식 찬송가에 말이다.

• My Jesus, I love Thee, I know Thou art mine (내 주 되신 주를 참 사랑하고)
• Blessed assurance, Jesus is mine! (예수로 나의 구주 삼고)

무슨 말인지는 충분히 이해하겠지만, 높임법이 존재하고 소유에 대한 개념이 보수적인 한국 및 한국어 문화로는 직역하기가 영 곤란한 대목이다. 사실, 성경적인 용례를 봐도 A is mine은 하나님이 "모든 혼은 내 것이다"(겔 18:4), "금과 은도 내 것이다"(학 2:8), "보복은 내 것이다"(롬 12:19), "첫 열매는 모두 내 것이다"(출 13:2)처럼 '갑'의 소유를 명시하는 게 전부이지.. 을이 갑을 보고 내 것이라고 말하는 경우는 찾을 수 없다.

그럼에도 불구하고 영어권에서 찬송가 가사를 Jesus is mine이라고 가끔 쓴 것은 다른 서정적인 의미가 있어서인지, 아니면 my Lord, my God, my savior, 심지어 my love를 상징적으로 표현한 것인지 본인으로 하여금 좀 생각을 하게 만든다. 하긴, 아 6:3가 있으니(나는 내 애인 것이고, 내 애인도 내 것이다) 이런 용례가 전혀 없는 건 아니다.

Posted by 사무엘

배틀넷 아시아 서버에 들어가 보면 무려 2015년 말인 지금까지도 스타크래프트 1을 하는 사람이 제법 보인다. 방을 만들어 놓으면 새로운 사람이 의외로 금방 들어와서 1:1이고 2:2이고가 된다.
이들은 도대체 어디서 뭘 하는 사람들일까? 잘은 모르겠지만 스타에 자신의 10대와 20대 시절의 추억을 남긴 건 확실한 분들일 것이다.

추억을 공유하는 사람들이 아직 활동 중인 건 일면 반가운 소식이긴 하지만, 이 사람들이 만만한 스타 초짜일 거라는 생각은 접는 게 정신 건강에 이롭다.
2015년, Windows 10이 나온 이 시점에서 640*480 256색 펜티엄 + 윈도 95급 컴용 초 구닥다리 스타 1을 찾아서 하고 있는 사람들이 갓 입문한 뉴비 하수일 리가 있겠나..;; 방 이름을 "초보만요"라고 아무리 붙여도 실제로 초보 같은 건 존재하지 않는다.

얼마 전엔 오랜만에 고딩 동창을 만나서 PC방에서 몇 판 땡겨 봤다.
스마트폰 덕분에 단순 인터넷 서핑용으로 PC방을 이용할 일은 전혀에 가깝게 없어졌고 게임마저도 모바일이 차지하는 비중이 커졌지만..
자그마한 스마트폰이 헤비 게임 매니아들의 모든 욕구를 충족시키지는 못한다. PC방이 아무리 코너에 몰린 산업이라고 해도 당장 몽땅 싸그리 폐업할 지경은 아님을 알 수 있었다.

확실하게 느낀 건 스타를 하는 사람들의 평균적인 수준이 옛날과는 달라졌다는 것이다.
무한/유즈맵이나 찾아 하는 초딩 따위는 없으며, 아저씨들 실력은 다들 왕창 상향평준화했다고 봐야 한다. 하긴, 아직도 리니지 1이나 퀘이크 아레나를 하는 사람도 있다니까 뭐..

본인의 대학 학부 시절엔 나보다도 못하는 사람, 황당무계한 플레이를 하는 애들도 종종 보였다. 팀플도 이만치 하면 나 같은 하수가 꼽사리로 껴도 승리도 종종 하곤 했으나.. 지금은 그렇지 않다. =_=;; 만나는 상대방마다 단위 시간당 모으는 자원, 뽑아내는 유닛이 장난이 아니다.

저글링이나 질럿 같은 밀리 유닛은 뭉치는 컨트롤도 꽤 잘한다. 그냥 어설프게 어택 땅만 했다가는 대등한 유닛 수로도 몰살 당한다는 교훈을 뒤늦게 얻었다. -_-;; 에휴...
스타를 잘하려면 크게 다음과 같은 네 분야에 충실해야 할 것 같다. 운전으로 치면 집중, 방향 감각, 비상 대처 요령처럼 제각기 서로 다른 분야이다. 허나, 말은 쉬워도 실제로 지키기는 어렵다.

• 제일 기본적인 구도는: 일꾼을 꾸준히 많이 뽑아서 자원 왕창 모으고, 그 자원으로 물량 왕창 뽑아서 힘싸움을 한다.
• 그러기 위해: 자원이 너무 남거나 모자라지 않게 하고, 서플라이 병목이 발생하지 않게 관리한다.
• 장기적인 전략: 수시로 적진 정찰해서 무슨 테크나 전략으로 대응할지도 판단 잘한다. 그리고 말라죽지 않으려면 멀티도 게을리하지 않아야 한다.
• 마이크로 컨트롤: 전투 중일 땐 세세한 유닛들 컨트롤도 잘해 주고..;; 전장에서의 컨트롤과 본진에서의 컨트롤을 멀티태스킹으로 해야 한다. (전투 중에도 계속 유닛 뽑는 것 잊지 말 것)

스타(1998)는 실시간 전략 시뮬 분야에서, 퀘이크 3 아레나(99~2000)는 FPS 분야에서 세기말을 장식한 정말 불멸의 명작이었다. 너무 완성도가 높게 잘 만들어졌고, 후속 작품까지 팀킬할 정도로 너무 장수했다.

특히 아직까지 퀘이크 투기장을 어슬렁거리는 애들은.. 정말 인간이길 포기한 괴수들이라고 그 악명을 익히 들었다.
초짜가 한 명 들어왔다가는 그냥 눈 깜짝할 사이에 죽는다. 레일건 같은 즉발 무기는 당연히 초정밀 원샷 원킬이며, 로켓 런처나 심지어 수류탄 같은 비선형 무기까지 남이 움직이는 궤적까지 예측하면서 다 맞힌다. 거기에다 이동 속도는 그냥 축지법 쓰는 수준. 아무리 death cam 기능이 있어도 누가 날 죽였는지 확인조차 어렵다.

그러니 초짜는 질려서 다 떨어져나가고, 고수들만 남아서 평균 실력은 더욱 상향평준화하니 난이도는 더욱 헬인 매니아 게임이 돼 간다고.
스타도 장수한 만큼 그런 경지에 도달한 지 오래다. 오늘은 스타를 하면서 오랜만에 든 생각을 더 끄적여 보겠다.

.1.
스타크래프트에서 각 종족별로 건물을 짓는 걸 보면 잘 알다시피...
프로토스는 프로브가 워프 게이트만 만들어서 건물이 알아서 소환되게 하며, 테란은 SCV가 손수 건물을 짓는다. 그리고 저그는 드론이 자기 몸을 직접 건물로 변이시킨다.
지구상의 동물 중에도 비버처럼 재료를 물고 와서 SCV 스타일로 건축을 하는 동물이 없는 건 아니지만, 그건 저그에서 반영이 되지 않았다. 덕분에 morph 이런 말을 난 언어학에서 접하기 전에 스타에서 먼저 접했다.

스타 3종족의 빌드 형태를 프로그래밍에다 비유하면.. 프로토스는 작업이 비동기적이다. 함수를 호출해서 작업을 요청하면 그 작업은 별도의 스레드에서 백그라운드로 돌며, 그 상태로 함수 실행이 즉시 끝나고 되돌아온다.
Windows에서는 CreateProcess, TerminateProcess 같은 프로세스 관련 요청들이 대체로 비동기적이며, Windows RT 환경에서는 상당수의 작업들이 동작 형태가 비동기적으로 바뀌었다. 동기화를 위해서는 특수한 언어 문법을 동원해야 할 정도가 됐고.

테란이야, 함수를 호출하면 그 작업이 다 끝난 뒤에 함수 실행이 끝나고 제어가 되돌아오는 가장 일반적(순차적, 동기적)인 형태이고..
저그는 마치 Windows에서 배치 파일을 이용해 실행 중인 자기 파일을 제거하는 것처럼.. 작업 요청을 외부에다 해 놓은 뒤 자기 자신을 신속히 종료해야 다음 작업이 진행되는 형태이다.
성경에도 유언은 유언을 남긴 사람이 죽은 뒤에야 효력을 발휘한다는 말이 있는데(히 9:16), 그것과 비슷한 맥락이다.

2.
그나저나 이것도 종족별 컨셉인지는 모르겠는데, 프로토스는 건물이 완성되어도 어떤 형태로든 알림이 원래 전혀 없었구나. 지금까지 이걸 한 번도 따져서 생각해 본 적이 없었다.
테란이야 미니맵으로도 위치가 하이라이트되고 SCV가 "Job finished!"라고 맵 전역에서 우렁차게 복창을 하기 때문에, 화면 어디를 보고 있건 건물 완성 이벤트를 모를 수가 없다.
저그는 맵 전역에서 들리는 소리는 없지만 그래도 미니맵으로 위치 하이라이트는 해 준다. 프로토스만 완전 나몰라라이다. 건물이 소환되고 있는 곳을 눈여겨보고 있어야 한다.

3.
프로토스는 건물과 유닛을 현장에서 생산하는 게 아니라 워프 게이트를 열어서 고향 행성으로부터 소환하는 것으로 설정돼 있다. 심지어 지상 유닛들은 죽는 것도 죽는 게 아니라 치명상을 입을 뿐이고, 그 즉시 고향 행성으로 소환돼 사라진다. 그렇기 때문에 질럿과 템플러는 죽더라도 테란· 저그의 지상 유닛과는 달리 피를 흘리는 시체가 남지 않는다. "노병은 죽지 않는다. 단지 사라질 뿐"이라는 맥아더 장군의 연설처럼 되는 설정인 셈이다. (단, 드라군의 최후에 대해서는 논외로 하자..;;)

그리고 프로토스도 모든 유닛이 소환은 아니다. 생명체가 전혀 들어있지 않은 몇몇 '로봇 유닛'은 현장에서 생산한다. 넥서스에서 생산하는 일꾼 프로브, 그리고 로보틱스 퍼실리티의 유닛들이 여기에 해당한다. 그래서 얘들은 프로토스라 해도 생산 중일 때 opening warp gate가 아니라 buliding이라는 말이 뜨며, 프로브와 리버는 죽을 때 그냥 폭발하며 터지지 연기처럼 사라지는 효과는 없다. 또한 퀸의 브루들링에 전혀 반응하지 않는다.

4.
스타에서 모든 종족의 건물들은 파괴되고 나면 잔해가 지면에 한동안 남아 있는다. 테란의 건물들도 공중에 뜬 상태에서 공격을 받아 터진 게 아니라면 잔해가 남아 있다.
그러나 프로토스는 건물 중에 파일런과 '실드 배터리'는 예외적으로 잔해가 남지 않고 그냥 펑~ 터져 없어진다. 파일런이야 성격이 좀 특이한 건물이니 그렇다 치더라도 왜 실드 배터리도 잔해가 남지 않는 걸까?

링크로 소개하는 이 동영상은 프로토스가 테란을 상대로 매너 파일런으로도 모자라서 적진에다가 실드 배터리까지 박은 플레이 영상이다. 그래서 성큼성큼 걸어 들어온 질럿이 아군 기지가 아니라 적진 한복판에서 실드를 보충까지 하면서 SCV와 마린을 때려잡는다. -_-;;;

물론 파일런과 실드 배터리는 곧 파괴된다. 그런데 이들은 아무 잔해를 남기지 않고 깔끔하게 사라진다는 걸 알 수 있다. 비슷한 방어 건물인 포톤 캐논은 그렇지 않은데 말이다. 신기한 일이다.

5.
건물에 "나 생산/업그레이드 중이요!" 상태를 거짓말 전혀 못 하고 가장 적나라하게 보여 주는 종족은 테란이다. 모든 생산· 연구 건물들은 동작 중일 때 불빛이 반짝거리고 기계가 돌아가는 게 보인다.
저그는 알을 부화하고 있는 것이야 다 보이지만, 업그레이드 건물들은 연구 중인 게 티가 잘 안 나는 편이다. 단, 스파이어는 업그레이드 중일 때 꼭대기의 지붕 부분이 뭔가 돌아가는 것 같던데.

프로토스는 일단 생산 건물인 게이트웨이(지상 유닛)와 로보틱스 퍼실리티는 생산 중인 티가 전혀 나지 않는다. 생산 건물이 이렇게 조용한 경우는 세 종족 중 프로토스가 유일하다. 단, 프로토스도 넥서스(일꾼)와 스타게이트(공중 유닛)는 생산 중일 때 불빛이 반짝거린다. 연구 건물의 경우, 일반 업그레이드를 담당하는 포지와 사이버네틱스 코어는 상태가 보이지만 나머지 건물들은 조용한 듯(시타델 오브 아둔, 템플러 아카이브, 플릿 비콘 등).

6.
골리앗은 카론 부스터(대공 사거리 증가) 업그레이드를 하고 나면 사거리만 느는 게 아니라 미사일의 비주얼 이펙트 자체가 바뀌는구나!
우와, 지금까지 꿈에도 생각을 안 하고 있었다. 정말 놀랍다.
어떤 형태로든 사거리 업그레이드가 있는 유닛은 각 종족마다 하나씩 마린, 히드라, 드래군 정도가 있고 골리앗은 브루드워에서 좀 특이한 형태의 업그레이드가 추가된 경우이다. 대공에 한해 사거리가 +1 정도가 아니라 무려 +3으로 크게 늘어나는 것이니 비주얼이 같이 바뀔 만도 하다.

7.
옛날에는 드론이라고 하면 6드론/9드론 저글링 이런 게 먼저 떠올랐는데, 세월이 흘러 요즘은 드론이 소형 무인기를 뜻하는 용도로 더 많이 쓰이고 있다.

Posted by 사무엘

1. 에어컨의 핵심은 압축기

본인은 몸에 열이 많고 더위에 약하다. 날씨도 더운 것보다는 추운 걸 더 좋아한다. 추위는 뭔가를 더 껴입기만 하면 얼마든지 극복 가능한 반면, 더위를 극복하려면 장비를 가동해야 하고 에너지 소비가 필요하기 때문이다. (뭐 겨울에도 컴퓨터 키보드를 두드리기가 어려울 정도로 손이 시려울 때, 정전기가 생길 때, 얼굴 표면이 부르틀 때는 좀 불편하긴 하다만..)

집도 너무 덥기 때문에 여름방학 땐 개인적인 코딩이나 연구는 가능한 한 학교로 ‘피서’를 가서 진행하곤 했다. 산기슭이어서 그런지 아무래도 학교가 집보다는 훨씬 덜 더운 것 같다. 공공장소인 도서관이나 기껏해야 동아리 방 정도만 활용할 수 있는 학부생과는 달리, 대학원생은 자체 연구실이 있는 것도 좋다.

이런 특성상, 본인에게 여러 문명의 이기들 중에 열역학과 동력 기관의 산물인 에어컨은 정말 축복 중의 축복이 아닐 수 없다. 냉장고와 에어컨이 없던 시절에 사람들은 식품 보존과 더위 극복에 애로사항이 잔뜩 꽃폈을 것이다. 냉동 공학 분야에 종사하는 엔지니어들이 존경스럽게 느껴지는 순간이었다. 자동차 공학, 철도 차량 공학, 심지어 한글 공학만큼이나 냉동 공학도 있으며, 이건 엄연한 기계 공학의 한 분야이다. 그러니 오늘은 에어컨 이야기를 좀 집중적으로 늘어놓아 보겠다.

에어컨은 외부에 아무 영향도 안 끼치면서 혼자 곱게 주변의 온도를 낮춰 주는 요술상자가 아니다. 그 원리는 본질적으로 물이나 알코올이 증발하면서 주변을 시원하게 하는 것과 같다. 단지, 에어컨은 물보다 더 쉽게 액화나 기화가 되는 물질을 냉매로 쓰고 열전달이 순환이 가능한 구조를 갖춰 놓았다.
더운물과 찬물을 한데 섞으면 미지근한 물이 되지만, 미지근한 물이 저절로 더운물과 찬물로 바뀌는 일은 결코 발생하지 않는다. 에어컨은 저절로 발생하지 않는 그 일을 인위로 발생시키는 기계이다.

C++ 가상 함수만 해도 일반 함수에 비해 많은 성능 비용이 뒤따르듯, 세상에 공짜는 없다. 에어컨은 에너지 소모가 대단히 많은 걸로 악명이 높다. 송풍기나 방열기의 팬은 에어컨이 소모하는 전체 전력에서 차지하는 비중이 미미하며, 90% 이상은 냉매의 상태를 강제로 바꾸는 압축기가 차지한다. 그렇기 때문에 송풍기의 강약만 조절하는 건 에어컨의 전력 소모에 거의 영향을 끼치지 않는다. 온도의 높낮이와 실질적인 가동 시간이 더 중요하다.

압축이라는 게 간단하게 그냥 되는 작업이 아니기 때문에 에어컨에는 실외기라는 크고 무거운 물건이 필요하다. 에어컨의 진짜 ‘엔진’은 실외기인 것이다. 한쪽이 열을 잃었으면 다른 쪽이 열을 얻었다는 뜻이므로 그 열을 방출하려면 또 다른 의미에서 어차피 외부 통로가 필요하기도 하고 말이다.
구체적인 메커니즘은 난 잘 모르지만, 공기든 냉매든 압축은 조용히 진행 가능한 작업은 아닌지라 소음과 진동이 뒤따른다. 에어컨 실외기가 마냥 조용하게 동작하지 못하는 게 이 때문이다.

에어컨은 처음 등장했을 때는 기계값과 전기료 어디로 보나 두 말할 나위도 없이 초호화 사치품이었다. 그에 비해 오늘날 가정, 차량, 공공기관, 교통수단 등에 널리고 널린 에어컨을 보면 참 경이롭기 그지없다.
지하철을 생각해 보자면, 옛날에 197, 80년대엔 객실에 에어컨이 없었을 뿐만 아니라(천장에 선풍기만 달랑), 전동차의 동력 제어도 원시적인 저항 방식이었다. 제동을 걸 때 열이 바닥에서 솟아올랐으니 여름에 지하철은 완전 찜통 지옥철이 따로 없었을 것이다. 생각만 해도 아찔하다. 기술이 인류의 삶을 지금까지 정말 편하게 만들어 줬다.

2. 차량용 에어컨

차량용 에어컨은 송풍기는 배터리로 가동하더라도 압축기는 대놓고 엔진 힘을 끌어들여 가동한다. 내 차만 해도 에어컨을 켜거나 껐을 때 엔진룸으로부터 느껴지는 엔진음과 진동이 살짝 달라진다. 또한, 시동을 켰더라도 오랫동안 정차하고 있으면 냉기가 좀 약해지다가, 액셀을 밟아서 엔진 rpm이 증가하면 바람도 다시 차가워지는 경향이 있었다.
어디선가 언뜻 본 자료에 따르면 승용차용 에어컨만 해도 엔진 출력을 3~4마력 정도는 깎아 먹는다고 한다. 그렇다면 시동을 안 켠 on 상태일 때는 에어컨을 켜더라도 그냥 송풍기 바람만 나온다는 뜻인데 실제로 그런지 개인적으로는 확인을 못 해 봤다.

옛날에는 마치 자동 변속기만큼이나 아무 차에나 에어컨이 달린 게 아니었다. 그리고 저배기량 경차는 가격은 둘째치고라도 엔진 출력이 견디질 못해서 에어컨을 제대로 틀지 못하는 면이 있었다. 사람이 가득 탄 채로 에어컨 틀고 오르막을 오르면..?;; 또한 굳이 경차뿐만 아니라 대형 버스도 과거엔 엔진 출력이 충분치 못해서 에어컨을 달고 틀기가 부담스럽던 시절이 있었다고 들었다. 공간이 넓으니 에어컨도 용량이 꽤 커야 했을 테니까.

하지만 요즘 자동차는 종류를 불문하고 그렇게까지 약골이 아니다. 그렇기 때문에 굳이 더운데 차의 엔진과 연비를 걱정해서 그렇게까지 극단적으로 에어컨을 안 틀고 참을 필요까지는 없다.
20년쯤 전에 486/펜티엄급 골동품 컴퓨터에서는 128kbps짜리 평범한 MP3을 하나 재생하는 것만으로도 CPU 사용률이 10~20%대까지 치솟았으며 컴퓨터가 다른 데서 버벅댔다. MP3 디코딩은 계산량이 엄청난 연산이긴 하지만, 요즘 컴퓨터로는 그건 뭐 ‘껌’이지 않은가. 에어컨이 자동차에 끼치는 오버헤드도 그런 식으로 변하고 있는 셈이다. 다만, 내연 기관이 없이 아예 전기로만 달리는 자동차에는 에어컨의 가동이 꽤 난관으로 작용할 것 같다.

그래도 에어컨은 사무실에서는 선풍기와 달리 서류를 흩날리지 않으며, 음료수 비용이나 땀으로 인한 의복 세탁 비용, 매번 몸을 씻는 데 드는 비용을 아껴서 보이지 않는 곳에서 사람들의 작업 생산성을 은근히 향상시켜 준다. 또한 자동차에서는 창문을 열 필요를 없게 해 주니 공기 저항 면에서는 오히려 연료를 아껴 주기도 한다. 에어컨은 마냥 에너지를 처먹기만 하는 하마가 아닌 것이다.
올해 초에 별세하긴 했다만, 싱가포르의 독재(?) 대통령 리콴유는 사는 곳이 사는 곳이다 보니, 에어컨이 인류 역사상 최고의 발명품이라고 극찬을 하기도 했다. 에어컨이 한여름에 생산성과 능률의 향상으로 인해 가져오는 축복을 직감했던 것이다.

자동차가 전진뿐만 아니라 후진이 가능하듯, 에어컨에서 열 전달 방향을 반대로 바꿔 주면 냉방이 아니라 난방도 할 수 있다. 즉, 실내의 에어컨 송풍기에서는 더운 바람이 나오고 실외 송풍기에서는 찬 바람이 배출되는 것이다. 단지 그건 아무 쓰잘데기가 없는 짓이기 때문에 그렇게 하지 않을 뿐이다.

겨울에 난방을 하고 싶으면 그냥 난로를 때고 히터/보일러를 틀면 된다. 그러고 보니 히터도 전기로만 하는 게 아니라 석유를 때서 가동하는 경우가 많으나, 요즘은 기름값이 너무 비싸서 그마저도 올전기로 때우는 추세로 가고 있다.
자동차는 이 점에서 좀 여유가 있다. 엔진열이 자동으로 공급되니, 히터는 에어컨과 달리 엔진에 아무런 추가 오버헤드가 없이 공짜로 가동 가능하기 때문이다. 물론 이 역시 에어컨과 마찬가지로 시동이 켜져 있는 동안에 한정일 것이며, 전기 자동차는 아예 해당사항이 없다.

3. 습기 관리

자, 그럼 마지막으로 습기· 물기와 관련된 이야기를 하고 글을 맺겠다.
에어컨은 시원하기만 할 뿐만 아니라, 굳이 저온이 아니어도 습기가 싹 빠져 보송보송한 공기를 불어 준다. 그렇기 때문에 그냥 땡볕만 내리쬘 때보다, 비 오기 직전의 눅눅하고 후덥지근하고 불쾌지수가 최악인 상황에서 에어컨은 더욱 놀라운 성능을 발휘한다.

그러나 에어컨은 남은 건조하게 만들어 주지만 반대로 자기는 물기에 찌들려 산다.
냉매를 액화시키기 위해 냉각기 내부의 온도는 영하 몇십~수십 도까지 떨어진다. (우리가 원하는 실내 온도까지만 내려가는 게 아님) 그럼 주변의 공기는 견디지 못하고 습기가 다 이슬로 바뀐다. 겨우 5도가 될까말까인 냉수만 물병에다 가득 담아 놔도 장마철엔 병의 표면이 얼마 못 가 물기로 온통 축축해진다. 하물며 에어컨 내부는 어떻겠는지를 충분히 상상하고 공감할 수 있다.

오죽했으면 국정원 추리 퀴즈 시리즈에서는 이 원리를 소재로 사용한 적도 있었다. 물이 없는 상황에서 은 요일 요원은 에어컨을 가동한 뒤 냉각판에서 흘러나오는 물을 마시면서 1주일을 버텼다.

maintenance-free하고 청소가 필요 없이 선풍기처럼 오래 오래 쓰는 에어컨이 존재한다면 참 좋겠지만.. 현실의 에어컨은 그렇지 않다. 일단 외부 공기를 걸러 주는 필터를 주기적으로 청소해야 하고, 또 아까 거론한 냉각기의 냉각판도 별도로 청소가 필요하다. 업계에서는 일명 '에바'(EVAporator)라고 불리는 듯. 시간이 흐르면서 먼지가 쌓이기도 하거니와, 축축한 채로 바깥 공기를 받아들이는 일만 하다 보면 냉각판이 온갖 세균과 곰팡이의 온상이 되기 때문이다. 이것은 나중에 차내에 굳이 에어컨이 아닌 송풍기만 틀 때에도 지린내와 악취의 원흉 역할을 한다.

차라리 차가 실외 땡볕 아래에 주차돼 있다면 모를까, 그 상태로 눅눅한 지하 주차장에 장시간 주차되면.. 문제는 더욱 심각해진다.
이런 공기가 사람 건강에도 좋을 리가 없다. 사실 냉방병이라고 불리는 것도 안팎의 급격한 온도 변화로 인한 피로도 증가와 면역력 감소라기보다는 호흡기 질병에 더 가깝다는 자료도 어디선가 봤었다. 코로 코렁탕...은 아니고 먼지와 세균을 꾸역꾸역 들이켰는데 몸에 탈이 안 날 리가. 어차피 급격한 실내외 온도 차이 자체는 한겨울에도 만만찮게 경험하는데 굳이 여름에만 몸이 특이하게 탈이 날 이유가 없기 때문이다.

이 찌든 악취는 필터만 교체하거나 송풍구에 소독만 한다고 없어지지 않더라.
내 경험상 자동차 공업소에서는 잘 해 주지 않고, 전문적인 자동차 에어컨 출장 청소 업체를 불러서 해야 했다. 필터는 엔진오일의 주기와 비슷하게 교환하는 반면, 냉각판은 거기 있는 상태 그대로 조수석 쪽에서 통로를 낸 뒤, 세제를 발라서 세척을 했다. 거기를 세척해 줬더니 진짜로 냄새가 싹 없어졌다. 거기에 설마 무슨 동물 배설물이나 사체 급의 끔찍한 오염원-_-이 있기라도 한 건 아니었고 그냥 정말 오랫동안 청소를 안 해 줘서 평범한 오염원들이 누적된 거랬다.

본인이 궁금했던 것은 왜 에어컨 가동 없이 송풍기만 가동했을 때 악취가 나며, 에어컨을 가동하고 나고 잠시 지나면 냄새가 없어지느냐는 것이었다. 청소 기사에게서 설명을 듣긴 했는데 이 역시 이해가 잘 되지 않았다. 잘은 모르지만 (1) 악취를 내는 요소들은 온도가 낮을 때는 일시적으로 냄새를 일으키지 않으며, (2) 에어컨을 가동하지 않더라도 냉각판이 송풍기에 영향을 주기는 하는 것 같다. 왜 어째서 그런지는 본인에게 묻지 마시고... ^^

그래서 인터넷이나 자동차 정비소 직원의 공통된 조언으로는.. 목적지에 도착하기 n분쯤 전부터 에어컨을 끄고 송풍만 가동해서 냉각판의 습기를 좀 말리라는 것이었다. 그 n의 값은 2~3이나 5, 심지어 10 이상으로 사람마다 차이가 있었다.
실제로 고급 외제차는 시동이 꺼진 뒤에 자동으로 송풍기를 말리는 기능이 있는 경우도 있다고 하니 그게 실제로 효과가 있긴 한가 보다.

Posted by 사무엘

Windows의 공용 컨트롤 열전.
날짜/시간 컨트롤에 이어 오늘은 툴바(toolbar)라고 불리는 '도구상자/도구모음줄' 컨트롤에 대해서 좀 얘기를 해 보겠다.

메모장 같은 급의 초간단 프로그램이 아닌 이상, 표준 GUI 기반인 대다수의 프로그램들은 상단에 클릭 가능한 그림 버튼들이 가로로 쭉 늘어서 있다. 도구모음줄은 바로 그 그림 버튼들의 표시를 책임진다. 각 그림 내지 아이콘은 그 프로그램에서 자주 쓰이는 명령들을 나타내며, 이를 클릭하면 일일이 메뉴를 열어서 글자 형태로 된 명령문을 읽고 선택하는 것보다 명령을 더 빠르게 내릴 수 있다.
자주 쓰이는 명령에 대해서 키보드에 단축키가 있다면 마우스에는 도구모음줄이 있는 셈이다.

사실, 도구모음줄은 컴퓨터의 성능 관점에서는 그렇게 효율적인 도구가 아닐지도 모른다. 요즘이야 제약이 덜해지긴 했지만, 과거에 화면 해상도가 충분하지 못하던 시절에는 텍스트나 그림 같은 문서 컨텐츠를 한 줄 표시할 공간이 아까운데 도구모음줄을 늘어놓는 건 화면 낭비였다. 수십 종류에 달하는 명령 아이콘들도 다 메모리를 수십 KB 이상씩 잡아먹는다는 건 역시 두 말할 나위가 없고.

하지만 어떤 프로그램을 실행했더니 그냥 빈 화면에 cursor만 달랑 깜빡이는 것보다는, 아무래도 컬러풀한 아이콘들이 가득한 도구모음줄 하나라도 좀 놓여 있는 게 사용자에게 친근하다. 이것이 마우스 사용자에게는 뭔가 클릭할 거리를 제공함으로써 프로그램을 더 편리하게 사용하는 데 실질적인 도움이 된다.

1990년대 초, Windows 3.x 시절에도 MS Word나 Excel의 까마득한 옛날 버전을 보면 파일, 편집, 보기 같은 자주 쓰인 명령이 등재된 도구모음줄이 있었다. 도구모음줄이라는 개념은 그때 처음으로 등장한 것으로 보인다. 그 시절에는 도구모음줄은 자체 구현이었고 MFC조차도 그걸 자체 구현해 줬었는데, Windows 95로 넘어오면서 운영체제의 공용 컨트롤로 형태가 바뀌었다. MFC의 ToolBar 클래스도 4.0 32비트 버전부터는 운영체제가 제공하는 놈을 쓰는 걸로 형태가 바뀌었다.

그리고 1990년대 말, MS Office 97부터는 버튼의 모양이 마우스로 가리키고 있는 놈만 얇은 입체 테두리가 나타나는 flat 스타일로 바뀌었으며, 메뉴도 도구모음줄 버튼이 있는 명령은 왼쪽에 그 도구모음줄 아이콘이 같이 뜨게 되었다. 이건 당시로서는 나름 굉장히 참신한 디자인이었다.
Office야 운영체제의 표준 GUI를 안 쓰는 걸로 악명(?)이 높았으니, flat 스타일은 Windows 98 타이밍 때 공용 컨트롤에도 도입되었다.

운영체제 차원에서 공용 컨트롤이 등장했으니 Visual C++과 MFC가 독자적으로 하는 일은 이제 없어졌느냐 하면 여전히 그렇지 않다. MFC가 하는 일은 다음과 같다.
(1) 먼저, 도구모음줄의 컨테이너격인 Control bar를 제공한다. 도구모음줄의 폭을 자유롭게 지정하고 위치도 자유롭게 옮기고 심지어 부모 윈도우의 상하좌우 등 어디든 자유롭게 붙이거나 떼는 것은 운영체제가 알아서 해 주는 일이 아니다. MFC의 도움 없이 직접 구현하는 건 머리에 쥐가 나는 노가다이다. 심지어 드래그하기 편하게 왼쪽에 그려 주는 gripper 세로줄 공간도 MFC가 그려 준 결과물이다.

개발하는 프로그램이 덩치가 MS 오피스 내지 포토샵 같은 상업용 프로그램 급으로 커지면 도구모음줄이 2개 이상 존재하게 된다. 보기 메뉴의 '도구모음줄' 항목은 체크 하나만 달랑 있는 게 아니라 '표준, 서식, 그리기' 등 도구모음줄의 종류를 가리키는 부메뉴를 갖게 된다.
도구모음줄이 하나밖에 없을 때는 겨우 그것만 이리저리 옮기고 붙였다 떼는 기능이 좀 잉여스럽게 느껴지겠지만, 그게 여러 개가 존재하게 되면 이들의 위치를 관리하는 기능은 필수가 된다. MFC는 그런 필수 기능을 구현해 준다.

도구모음줄이 한두 개도 아니고 무려 10~20개씩 달려 있는 방대한 프로그램은 도구모음줄의 버튼들을 사용자 정의(customize)하는 기능도 전문적으로 갖추고 있다. 공용 컨트롤이 기본으로 제공하는 customize 기능도 있지만, 그건 전체 아이콘들 집합에서 자기 도구모음줄에다가 추가할 버튼을 선택하고 순서를 바꾸는 것 정도가 전부이다. 그 반면 MS Office의 경우, 2007 이전 버전은 메뉴의 텍스트, 도구모음줄의 버튼 그림까지 전부 사용자가 바꿀 수 있어서 가히 개발자의 근성을 짐작케 하는 엄청난 customize 기능을 제공했다. 나중에는 MS Office는 리본 UI 기반으로 바뀌고 Visual Studio도 WPF 기반으로 UI가 싹 바뀌면서 이런 기능은 더 찾아보기 어렵게 됐다.

이런 컨테이너 기능 말고도 또 Visual C++가 MFC와 연계하여 제공하는 기능은 바로 (2) IDE가 제공하는 리소스 편집기이다.
MFC로 응용 프로그램을 만든다면 우리는 리소스 편집기를 이용해서 리소스에다가 Toolbar를 추가하고 도구 버튼과 아이콘, 연계 명령들을 넣곤 한다. 그런데 이 Toolbar라는 리소스 카테고리는 Windows가 제공하는 표준 리소스 포맷이 아니다. 비트맵, 아이콘, 메뉴, 문자열과는 달리 표준 포맷이 아니며, MFC가 자체적으로 정의해서 사용하는 포맷이다. 여기에 지정된 데이터를 바탕으로 도구모음줄을 초기화하는 것은 응당 MFC의 몫이다. LoadIcon, LoadMenu, LoadString 따위와는 달리, LoadToolBar는 MFC 클래스의 멤버 함수로나 존재하지 Windows API에는 없다.

게다가 이 toolbar 리소스는 단독으로 있는 것도 아니다. 얘가 정의하는 것은 한 도구모음줄에 몇 개의 버튼이 있고 각 버튼이 의미하는 명령 ID는 무엇인지, 혹은 이것이 구분자인지 같은 정보가 전부이다. 그 도구모음줄이 참조하는 비트맵은 같은 ID의 Bitmap 리소스에 있다.
하지만 Visual C++ IDE는 도구모음줄과 연계하는 비트맵은 비록 비트맵이라 할지라도 표준 비트맵 리소스에서 따로 표시를 하지 않으며, 그 비트맵은 도구모음줄 리소스를 편집하는 곳에서 버튼 구조와 함께 편집하게 돼 있다. 프로그램이 내부적으로 이런 보정 처리까지 하고 있는 것이다.

내부적으로 MFC는 한 프로그램 윈도우에 대해서 한 리소스 ID를 부여하여 이걸로 문자열(프로그램 제목), 아이콘, 액셀러레이터 단축키, 표준 도구모음줄(비트맵 포함)까지 한데 관리를 하기까지 한다. 이것이 바로 CFrameWnd::LoadFrame 함수가 하는 일이다. 참 대단한 발상이다.

다음으로, 도구모음줄에 대해서 프로그래머가 반드시 짚고 넘어가야 할 기술적인 사항이 하나 있다.
도구모음줄의 버튼 그림은 작고 아담한 게 아이콘을 닮았지만, 실제로 이건 아이콘이나 마우스 포인터와는 달리 그냥 비트맵이다.
'아이콘'은 이미지 비트맵과 마스크 비트맵으로 구성되어서 태생적으로 래스터 오퍼레이션을 통해 투명 배경이나 반전 같은 걸 표현할 수 있다. 그러나 이미지 비트맵 한 장만 갖고는 그런 걸 표현할 수 없다. 그렇다면 도구모음줄 버튼은 어떤 방식으로 투명색을 표현하는 걸까?

이 방식은 생각보다 굉장히 원시적이고 단순무식하다. TB_ADDBITMAP 메시지라는 재래식 방식을 쓰는 경우, 도구모음줄은 이미지 비트맵 한 장만 달랑 받아들이고 투명 처리 같은 걸 해 주지 않는다. 비트맵을 생으로 있는 그대로 출력만 한다.
그렇기 때문에 MFC의 도구모음줄 클래스는 자신의 리소스 비트맵 이미지에 대해서 보정을 한다. 비트맵에 RGB(192,192,192)에 속하는 은색/회색 픽셀이 있으면 그걸 현재 운영체제의 COLOR_BTNFACE 시스템 컬러로 바꾸고, 은색 말고도 짙은 회색이나 검정, 하양은 그에 상응하는 시스템 컬러로 바꾼다. 그렇게 보정된 비트맵을 도구모음줄로 보내서 은색이 편의상 투명 배경색인 것처럼 보이게 한다. 보정을 안 하면 바로 이런 꼴 난다..;;

시스템 색상이 바뀌어서 WM_SYSCOLORCHANGE 메시지가 오면? 당연히 도구모음줄 비트맵도 매번 다시 만들어서 지정한다.
MFC를 뒤져 보면 이 일을 하는 AfxLoadSysColorBitmap라는 함수가 bartool.cpp에 있다. 아니, 이렇게 색깔 치환을 한 비트맵을 생성하는 함수가 Windows 95 시절부터 comctl32.dll에 CreateMappedBitmap이라고 있어 왔다. 도구모음줄 전용이기 때문에 user32도, gdi32도 아닌 comctl32에 있는 것이다.

그리고 이런 색깔 보정이 마냥 삽질인 것만은 아닌 것이..
시스템 색상이 고대비 검정 같은 걸로 바뀌었을 때는 검은색을 흰색으로 바꾸는 작업도 어차피 필요하기 때문이다. 도구모음줄의 비트맵은 반쯤은 이런 유동적인 환경 변화에도 대비가 돼 있어야 한다는 점이 흥미롭다.

도구모음줄용 비트맵으로 원시적인 생 비트맵뿐만 아니라 image list를 지정하는 TB_SETIMAGELIST 메시지는 Internet Explorer 4는 아니고 3과 함께 약간 나중에 추가됐다.
image list는 자체적으로 마스크 정보도 포함할 수 있으니 예전보다는 상황이 좀 낫다. 또한 ImageList_LoadImage 함수는 은색이 아닌 임의의 색깔을 투명색으로 지정할 수 있고, 아예 default로 (0,0) 화면 최상단 좌측 픽셀을 투명색으로 지정하게 할 수도 있다.
평소에는 흑백 이미지이다가 마우스 포인터가 가리키고 있는 버튼만 컬러 이미지로 출력하는 일명 hot image를 지정하는 것은 이렇게 image list 형태로만 지정 가능하다.

이렇게 특정 한 색깔을 투명색으로 끌어다 쓰는 건 아무래도 16색/256색 시절의 그래픽 패러다임을 벗어나지 못한 발상이다. MFC feature pack을 이용해서 트루컬러 아이콘이 들어간 도구모음줄을 만들면 당장은 보기 좋지만 시스템 색상을 고대비 검정으로 바꿔 보면 경계가 완전 뭉개지고 보기 좋지 않은 걸 알 수 있다. 어느 배경색에도 경계가 부드럽게 나오려면 근본적으로 알파채널이 쓰여야 할 텐데 그렇지 못하기 때문이다.

요컨대 오늘날 도구모음줄은 아이콘들이 그런 것처럼 트루컬러와 알파 채널에 대비가 돼 있어야 하고, 그러면서 고대비 모드도 지원해야 하며, 더 욕심을 부리자면 고해상도 DPI에서는 약간 큰 비트맵도 준비돼 있어야 한다. MS Office의 리본 UI는 고대비 모드에서는 그냥 16컬러로 간략화한 비트맵을 대신 출력하는 것 같다.
그리고 <날개셋> 편집기는 겨우 그 덩치의 프로그램에서 저런 것까지 일일이 대비하는 건 너무 낭비라 여겨지기 때문에 도구모음줄의 아이콘은 그냥 16*16 크기의 16색에 머물러 있다.. ^^

그나저나,

• 공용 컨트롤을 쓰지 않고 자체 구현된 도구모음줄은 대화상자를 띄우는 명령을 클릭한 경우, 대화상자가 떠 있는 동안에 버튼이 여전히 눌러져 있기도 했던 것 같다. MS Office 2007 이전의 옛 버전과 Visual C++ 6 등이 그 예다.
• 전무후무하게 도구모음줄 배경에 solid color가 아니라 무늬가 있었던 IE 3의 도구모음줄은 어떻게 구현되었는지가 새삼 궁금해진다. 얘는 표준 공용 컨트롤 기반인데, 아마 얘 때문에 image list 기능이 도입되었지 싶다. 이쯤 되면 버튼 비트맵에 자체적으로 마스크 정보가 있어야만 도구모음줄 배경과도 합성이 가능하지 않았겠는가.

Posted by 사무엘

컴퓨터에는 자체적으로 달력과 시계 기능이 포함되어 있으며, 운영체제에는 그걸 설정하는 기능이 있다.
대략 197, 80년대 엄청 미개하던 시절에는 개인용 컴퓨터의 시계에 배터리가 없었다. 그래서 컴퓨터가 꺼지면 현재의 날짜· 시각 정보가 사라졌으며, 매번 부팅 때마다 사용자가 그걸 다시 지정해 줘야 했다. 옛날에 도스가 autoexec.bat가 없으면 디폴트로 하던 일이 바로 date, time 명령을 실행하여 날짜· 시각을 입력받는 것일 정도였다.

그 반면 지금은 컴퓨터가 자체적으로 날짜· 시각을 관리하고 있을 뿐만 아니라 Windows의 경우 XP부터는 인터넷 서버로부터 시각을 자동으로 동기화하는 기능이 추가됐다. 그러니 긴 시간이 흐른 뒤에 시계가 오차가 쌓여서 부정확해질 일이 없어졌다. 기지국으로부터 받은 시각을 표시하는 휴대전화처럼 말이다. 다만, 휴대전화는 자체 시계는 없는지, 기지국과의 통신이 끊어지면 컴퓨터와는 달리 시각을 아예 표시를 못 하는 것 같다.

XP를 넘어 Windows Vista부터는 날짜· 시각을 사용자가 변경하는 건 관리자 권한이 필요한 일로 바뀌었다. 보안과 권한 개념이 발달해 있는 유닉스 계열 컴퓨터에서는 진작부터 그랬다.
거기에다 자동 동기화 기능까지 있으니 일반인이 컴퓨터에서 날짜· 시각을 손수 건드릴 일은 거의 없어졌으며, 소프트웨어의 사용 기한 같은 걸 속이려고 컴퓨터의 날짜를 조작하는 일도 예전보다는 쉽지 않게 됐다.

Vista 이전의 과거엔 Windows에서 작업 표시줄의 시계를 더블 클릭하면 곧장 날짜· 시각을 입력받는 제어판 대화상자가 떴다. 그러나 지금은 간단하게 달력과 아날로그 시계만 뜬 뒤, 날짜· 시각을 바꾸는 대화상자는 추가로 버튼을 클릭해야만 나오게 바뀌었다.

이 창은 정식 대화상자가 아니며, 마우스로 이동을 시킬 수가 없고 바깥을 툭 건드리기만 하면 바로 사라진다. 그렇기 때문에 예전에 비해 UI가 좀 불편해진 면모도 있다. 하지만 read-only 형태의 달력· 시계 UI만 먼저 제공하고 수동 변경 기능을 뒤에 숨겨 놓는 것 자체는 디자인상 필요했으며 바람직한 조치이다. 또한 변경 기능의 접근성을 떨어뜨린 대신, 시차를 고려해 최대 2개의 custom 시계를 추가로 표시할 수 있게 한 건 예전 버전에는 없었던 편리한 기능이다.

아무튼, 어떤 형태로든 사용자로부터 날짜와 시각을 입력받는 UI가 필요하니, 태초에 Windows 95의 날짜· 시각 제어판 애플릿은 이런 형태였다.

여기서 중요한 사실은, Windows 95 시절부터 제어판의 날짜· 시각 대화상자에는 커스텀 컨트롤이 은근히 많았다는 점이다.
이 대화상자는 IE 4 내지 공용 컨트롤 4.7이 등장하기 전부터 존재해 왔다. 그렇기 때문에 저 달력은 SysMonthCal32 공용 컨트롤이 아니다. 공용 컨트롤은 컨트롤 자체에 달력뿐만이 아니라 년과 월을 선택하는 기능이 존재하는 반면, 저 커스텀 컨트롤은 년 월 선택은 위의 콤보 박스에서 따로 하고 있다.
아날로그 시계는 두 말할 나위도 없고, 그 아래의 시간 선택 컨트롤도.. 에디트 컨트롤 몇 개를 내부적으로 갖다 붙인 커스텀 컨트롤이지 SysDateTimePick32가 아니다.

Windows Vista부터는 제어판의 날짜· 시각 대화상자가 구닥다리 자체 구현 달력이 아니라 공용 컨트롤을 사용하는 것으로 구조가 바뀌었다. 하지만 시각을 입력받는 에디트 컨트롤은 공용 컨트롤이 아니라 여전히 재래식 방식이다.
또한, 일부 Windows 버전에는 시간대를 선택하는 UI에 세계 지도 그림이 곁들어진 것이 있는데, 이것도 커스텀 컨트롤로 구현되어 있다.

세계 지도는 내력이 좀 복잡하다. Windows 95에 있었다가 98/ME에서는 잠시 빠졌다. NT 계열인 2000/XP에서는 줄곧 있었지만 Vista부터는 도로 제외된 채 오늘날에 이르고 있다.

Windows 95가 처음 개발되던 당시에는 콤보 상자뿐만 아니라 사용자가 지도의 지역을 클릭하면 그 지역의 시간대가 자동으로 선택되는 기능까지 있었다. UN에서 발행한 지도 자료를 토대로 국가 영역을 다 입력해 넣었으나..
영토 분쟁을 겪고 있는 모 국가들로부터 국경 인식을 왜 그 따위로 하느냐는 항의 메일이 빗발쳤다고 한다. 그 나라에서 제시하는 경계를 다른 쪽 나라에서는 당연히 인정하지 않았고.. 이 기능이 그대로 들어갈 경우 국가적으로 Windows 95를 보이콧 하겠다고 서로 난리도 아니었다. 우리나라의 확장완성형 논란은 이에 비하면 약과로 보일 정도로 자세가 강경했다.

역시 세상에서 무서운 건 정치이다. 고민 끝에 마소에서는 결국 이 기능 자체를 빼 버리고 오로지 콤보 박스로만 시간대를 선택할 수 있게 했다고 한다. 이 일화는 오래 전에 the Old New Thing 블로그에서 운영자가 증언한 내용이다. 세계구급 소프트웨어를 개발하는 데 관여한 사람만이 경험할 수 있는 일이니 참 흥미롭다.

* 여담: 과거 Windows의 동작 방식

믿어지지 않는 사실인데..
과거 Windows 95/98은 제어판의 '날짜/시간'에 들어가서(저 설정 대화상자를 연 뒤) 달력 컨트롤에서 임의의 날짜를 찍거나 연도· 월을 변경하면..
그것만으로도 시스템의 날짜가 즉시 그 날짜로 바뀌었다고 한다! 본인이 가상 머신으로 테스트 해 보니 진짜로 그렇다.

사용자들은 시스템의 날짜를 변경할 의도가 없이, 지금으로부터 가까운 과거나 미래의 달력을 잠시 조회만 할 목적으로 그 대화상자를 종종 꺼내곤 했다. 그도 그럴 것이 작업 표시줄의 우측 하단에 있는 시계만 클릭하면 되기 때문이다. 그런데 달력 컨트롤의 날짜를 클릭하는 것만으로 시스템의 날짜까지 덩달아 바뀌었다니..

물론 대화상자를 ESC/'취소'를 눌러서 닫으면 변경 전의 원래 날짜로 원상복구 되긴 했다. 그러나 일시적으로 날짜가 과거나 미래로 바뀐 동안에는 시스템 날짜에 의존해서 동작하는(업데이트 체크, 알람 등..) 프로그램이 심각한 오동작을 일으킬 위험이 다분히 있었다.

내 경험상, 애플 macOS 진영은 저장이나 인쇄 같은 동작이 수반되는 기능 말고, 단순 설정 기능들은 '취소 cancel/undo'가 딱히 갖춰져 있지 않고 모든 설정들이 변경 즉시 바로 적용되는 편이다.
그러나 마소는 소프트웨어의 UI 디자인 원칙 차원에서 원상복귀/"빠꾸"에 무한 관대할 것을 요구한다. 사용자가 OK라고 최종 승인을 하지 않는 한 말이다.

Windows에서 설정을 변경하는 것만으로 변화를 즉시 경험할 수 있는(preview) 기능은 스피커의 볼륨, 키보드와 마우스의 반응 속도처럼 사용자와 직접 소통하는 컴퓨터의 입출력 장치와 관련이 있는 옵션 정도밖에 못 봤다. 그리고 이마저도 당연히 '취소' 가능하다. 하지만 시스템 날짜도 그렇게 직접 실시간으로 바뀌었다는 건.. 음~ UI를 왜 그렇게 만들었는지 의문이 들게 된다.

그리고 더 이상한 것은 '날짜'(date)만 그렇게 즉시 반응했다는 것이다. '시각'(time)은 사용자가 새로운 시· 분· 초 값을 입력해도 즉시 바뀌지 않았다. 프로그램을 왜 그렇게 만들었는지도 개인적으로 이해되지 않는다.

이런 동작 방식은 Windows 2000/ME에 와서야 개선되어서 달력을 막 건드리더라도 '확인'이나 '적용'을 누르기 전에는 날짜가 절대로 바뀌지 않게 되었다. 날짜· 시각 변경은 DPI 변경과 더불어 20여 년 사이에 Windows에서 위상이 드라마틱하게 달라진 기능에 속한다.

* 여담 하나 더: 컴퓨터 내부에서 날짜와 시각을 표현하는 방식

일상생활에서는 날짜와 시각이 모두 쓰이거나 둘 중 하나만 사용될 때가 있다.

• 날짜와 시각 모두: 특정 날짜와 시각에 발생하는 알람이나 일회성 약속을 나타낼 때
• 날짜만: 구체적인 시각이 중요하지 않은 역사 사건을 나타낼 때 (1994년 9월 1일, 분당선 개통)
• 시각만: 부산 오전 8시 정각, 대전 10시 38분, 서울 12시 10분처럼 날짜가 중요하지 않은 정규 스케줄을 나타낼 때

하지만 컴퓨터 프로그램들은 이들을 모두 동일한 방식으로 저장하고 표현만 필요에 따라 다르게 한다. 무슨 말이냐 하면, 1이 하루를 나타내는 날짜 전용 수 체계와 1이 1초를 나타내는 시간 전용 수 체계를 따로 운용하는 게 아니라, 둘 다 동일한 수 체계를 사용한다는 뜻이다. 기준 연도로부터 얼마의 시간이 경과했는지가 기준이며, 수 체계는 과거에는 32비트 정수가 주로 쓰였지만 요즘은 응당 범위가 훨씬 더 넓은 64비트가 대세이다.

Windows에는 FILETIME이라는 유명한 자료형이 있다. 이것은 1601년 1월 1일 자정으로부터 경과한 시간을 나타내며, 1은 100나노초, 즉 0.1 마이크로초 단위이다. 왜 하필 1601년을 선택했는지는 본인은 모르겠다.
그 반면 Java 언어는 내부적으로 시각을 유닉스 원년인 1970년 1월 1일 자정으로부터 경과한 시간으로 나타내며, 1은 마이크로초를 나타낸다. C 언어에 있는 time() 함수는 기준이 1970년 1월 1일이긴 한데 그냥 초 단위라는 차이가 있다. 이렇듯 시간을 나타내는 방식도 언어와 플랫폼 사이에 미세하게 차이가 있다.

유닉스 원년은 지질학 원년인 1950년과는 딱 20년이라는 차이가 존재한다는 게 흥미롭다. 쉽게 말해, 지질학에서 뭐 "지금으로부터 6500만 년 전에 공룡 멸망", "몇억 몇천만 년 전쯤에 중생대" 이러는 것은 1950년보다 그만치 전이라는 뜻이다. 지질학에서는 방사성 원소 연대 측정법이 본격적으로 쓰인 때를 원년으로 삼았고, 컴퓨터 업계에서는 유닉스 운영체제와 C 언어가 막 개발된 그 시기를 원년으로 삼은 듯하다.

한편, 이런 날짜· 시각과는 달리, 전화번호는 숫자처럼 보이지만 그 형태 그대로 문자열로 저장된다는 점에서 날짜· 시각과는 성격이 다르다. 얘는 아무래도 대소 비교를 하거나 차이를 계산하는 대상은 아니니 말이다. 이런 건 데이터베이스나 엑셀 같은 프로그램으로 주소록 같은 것만 만들어 봐도 바로 공감할 기본적인 내용이다.

Posted by 사무엘

사람이 일생상활에서 취급하는 정보 중에는 일반적인 숫자나 문자열만치 자주 쓰이지는 않지만 날짜· 시각도 있다. 얘들은 컴퓨터 내부에서는 커다란 정수 하나로만 달랑 표현되겠지만 사람에게 보일 때는 일정한 형식을 갖춘 부분숫자의 나열로 표현된다. 또한, 그걸 표현하는 형식 내지 부분숫자들(년월일, 시분초)을 나열하는 순서는 언어나 문화에 따라 대동소이한 차이가 있다.

날짜 문자열은 마치 프로그래밍 언어 문법처럼 형식이 있으며, 문법과 의미 차원에서 정오(맞고 틀림)가 존재한다. 가령, 2015*5#20은 구분자 문자열이 잘못 지정되어서 문법에 어긋나며, 2015/5/100은 문법엔 맞지만 5월 100일이라는 게 존재하지 않기 때문에 의미가 잘못됐다.

날짜· 시각은 그냥 이런 문자열로 입력받게 할 수도 있다. 하지만 필요하다면 달력 같은 걸 내려서 사용자가 전체 날짜를 보면서 내가 원하는 날짜를 마우스로 콕 찍을 수도 있게 하는 게 좋을 것이다. 이 날짜가 무슨 요일인지, 그리고 지금으로부터 과거나 미래로 얼마나 떨어져 있는지를 달력을 통해 시각적으로 확인 가능하다면 날짜를 정확하게 선택하는 데 큰 도움이 되니까 말이다.

그러니 날짜· 시각을 입력받는 GUI 컨트롤은 에디트와 리스트를 겸하여 뭔가 콤보 박스 같은 형태로 만드는 게 좋다.
흔히 date picker라고 불리는데, 이런 컨트롤은 당장 웹사이트에서 더 많이 보는 것 같다. 무슨 예약· 예매 기능이 있는 사이트들이 대표적인 예이다.

대충 만든 사이트라면 년월일을 그냥 각각 콤보 박스에다가 집어넣어 놓곤 한다. 뭐, 생년월일이나 신용카드 유효 기간처럼 수 년 이후의 미래나 수십 년 이전의 과거를 입력받는 거라면 달력을 일일이 스크롤하는 게 번거로우며 단도직입적으로 날짜를 고르는 방식이 나쁘지 않다. 게다가 이런 날짜는 내 의지와는 상관없이 답정너 형태로 존재하는 날짜들이다.
그 반면, 현재로부터 비교적 가까운 날짜에 있을 스케줄을 '내 자유의지'에 따라 잡는 상황에서는 달력이 있는 게 좋을 것이다.

자바스크립트로 만들어진 웹 컴포넌트 말고, Windows의 로컬 프로그램에서 사용 가능한 공용 컨트롤은 95때부터 바로 있었던 게 아니다. 나중에 Internet Explorer 4와 함께 도입되었다(공용 컨트롤 버전 4.7). 바로, 날짜/시각 선택 컨트롤과 달력 컨트롤이며, 클래스 이름은 각각 SysDateTimePick32와 SysMonthCal32이다.

날짜/시각 선택 컨트롤은 스타일을 뭘로 주느냐에 따라서 날짜와 시각 중 하나를 입력받게 할 수 있다. 시각 모드일 때는 컨트롤의 오른쪽에 up/down 버튼이 붙지만, 날짜 모드일 때는 오른쪽에 콤보 버튼이 붙는다. 각 숫자들은 숫자 키로 직접 입력하거나 상하 화살표로 증가· 감소를 시킬 수 있다.

날짜 모드일 때 콤보 버튼을 누르거나 F4 키를 누르면 달력이 나타나서 달력의 날짜를 클릭하는 방식으로 날짜를 지정할 수도 있다. 그리고 달력 컨트롤은 날짜 선택 컨트롤이 일시적으로 표시해 주는 그 달력을 상시 표시해 놓는다.
하긴, 본인 역시 <날개셋> 한글 입력기에서 낱자 선택 콤보 박스를 이런 식으로 만들곤 했다. F4를 눌렀을 때 나타나는 셀 리스트는 drop list일 뿐만 아니라 그걸 단독으로 list box 형태로 쓸 수도 있게 말이다.

그런데 달력 컨트롤은 공용 컨트롤 6.0 것을 쓸 때와 그렇지 않은 재래식 버전을 쓸 때 동작이 살짝 다르다. 재래식은 년과 월을 클릭하면 그냥 년 또는 월을 선택하는 단순한 콤보 박스가 나타나는 반면, 새것은 그걸 클릭하면 달력 자체가 일(day) 대신 월, 1년, 10년 단위로 스케일이 커진다. 마치 지도를 확대/축소하듯이 말이다. 이 새로운 동작 방식은 Windows Vista에서 처음으로 추가되었다.

실행 파일의 호환성 옵션으로 들어가서 시각 테마를 끄더라도 공용 컨트롤 6.0의 달력 컨트롤은 그렇게 동작한다. 즉, 이것은 외형의 차이가 아닌 코드 로직의 차이이다.

그러니 날짜/시각 선택 컨트롤과 달력 컨트롤은 ComboBox와 ComboLBox의 관계와 같으며, 리스트 컨트롤과 헤더 컨트롤의 관계와도 얼추 비슷하다.
얘는 공용 컨트롤 중에서도 조금 나중에 도입된 놈이기 때문에 InitCommonControls만 호출해 준다고 해서 초기화가 되지 않는다. 반드시 Ex 버전을 써서 이렇게 초기화해야 한다.

INITCOMMONCONTROLSEX ics;
ics.dwSize=sizeof(ics); ics.dwICC=ICC_DATE_CLASSES;
::InitCommonControlsEx(&ics);

물론, 공용 컨트롤 6.0 매니페스트가 지정된 프로그램들은 저 함수를 호출하지 않아도 모든 공용 컨트롤들을 곧장 사용할 수 있다.
그럼 다음 시간에는 운영체제의 날짜· 시각 설정 UI를 이 컨트롤과 연계해서 살펴보도록 하겠다.

* 여담: 언어적인 이슈

number가 '수'도 되고 '번호'도 되는 것만큼이나, time은 시각도 되고 시간도 돼서 개념이 언어적으로 무척 혼란스럽다. 두 시각의 차가 시간이니 날짜에 대응하는 current time은 '현재 시각'이 돼야 맞다.
'째'(얼추 nth)와 '번째'(nth time)도 이와 비슷한 맥락에서 쓰임이 무척 혼동스럽다. 한국어에서 '째'는 서열이나 순위 개념이고 '번째'는 횟수 정도에 대응한다.
x시 y분에 A역을 발차해서 z시 w분에 B역을 도착한다는 식으로 열차의 운행 스케줄을 적어 놓은 도표도 시간표가 아니라 시각표라고 한다.

Posted by 사무엘

본인이 번역한 신앙 서적이 하나 출간되었기에 오늘은 이곳에서 소식을 좀 전하고자 한다. 제목은 <간극은 있다>이다. 부제는 "루시퍼의 죄로 인해 야기된 홍수에 대한 성경적 해설".

원서의 저자는 Perry Demopoulos라는 미국 출신의 우크라이나 선교사이다. Gap Fact라는 제목으로 2014년에 책이 나왔다. 제목에서 알 수 있듯이 이 책은 성경적 과거 연대기에서 매우 중요한 비중을 차지하는 창 1:1-2 사이의 '간극'을 다루고 있다.

세상에서는 창 1:1-2 사이에 간극이 있었다고 주장하는 사람들이 일부 있다 "카더라"라는 차원에서 '간극 이론'(gap theory)이라는 용어가 통용된다. 그러나 간극을 성경적으로 확고하게 믿는 사람들의 관점에서는 이건 동해를 일본해라고 부르는 것만큼이나 말도 안 되는 소리이다. 간극은 겨우 이론· 학설 따위가 아니라 확고한 진리이고 팩트이기 때문에 이들은 gap truth 내지 gap fact라는 말을 쓴다. 그 뉘앙스를 본인은 서술형으로 좀 의역해서 "간극은 있다"라고 책 제목을 뽑았다.

본인은 성경을 문자 그대로 믿는 신자로서 창세기 1장이 말하는 6일 창조는 정말 말 그대로 24시간 문자적인 하루 단위였다고 믿으며, 지금으로부터 6천여 년 전의 아담 이전에는 인류가 존재하지 않았다고 믿는다. 여기까지는 소위 말하는 '창조 과학회'라는 단체가 주장하는 것과 견해가 완전히 일치한다.
그러나 지구와 우주 전체의 역사는 인간과 '현 세상'의 역사만치 짧지 않다, 정확히 말하면 "반드시 짧아야만 할 필요가 없다"라는 것이.. 세속 과학과의 타협이 아니라 성경 교리를 토대로 내리는 결론이다.

창조 과학회는 그야말로 '젊은 지구, 젊은 우주' 덕후이다. 생명의 기원에만 신수설을 주장하는 게 아니라 천문· 지질학의 연대 측정 방식까지 모두 부정하며, 오로지 '노아의 홍수'만으로 모든 지질 이변을 설명하는 걸로 유명하다. 본인은 걔네들이 주장하는 과학 디테일에 대해서야 크게 관심이 없다. 불신자들이 알아서 가루가 되도록 반박하고 까고 있으며 본인의 신앙 역시 거기에 근간을 두고 있는 게 아니니 말이다.

창조 과학회는 성경 믿음을 수호한다고 하면서 성경 믿음에 대한 팀킬까지 야기하고 있다는 게 나 같은 신자의 입장에서는 훨씬 더 큰 문제이다.
그들이 생각하는 진화론이란 곧 비인간적인(?) 적자생존 약육강식이고 피흘림과 죽음이다. 걔들은 잘 알다시피 진화론이 단순한 무신론을 넘어 나치즘과 공산주의 등 온갖 악한 사상의 근간이 됐다고까지 공격할 정도로 진화론을 완전 극혐한다.

뭐 인간이 원숭이나 아메바로부터 진화한 게 아니라 하나님에 의해 처음부터 창조되었다고 주장하는 것 자체는 건전하고 좋다고 치자. (여기서 '원숭이나 아메바' 따위에 트집 잡는 진화론자가 없길 바란다. 공통 조상이야 그 무엇이 됐건 중요하지 않으며, 아무튼 저절로 '진화'를 했다는 게 중요한 키워드임.)
그런데, 그런 이념을 몰아내려다 보니 그들이 읽는 창세기 1장엔 그 어떤 일체의 죄, 타락, 심판, 사망 같은 부정적인 심상이 있어서는 안 된다. 창세기 1장의 배경엔 무조건 반드시 아름답고 긍정적인 것만 있어야 한다.

그 결과, 얘들은 "죄의 원조 = 오로지 아담"에 완전히 꽂혀 버렸다. 선악과를 시간적인 순서상 제일 먼저 먹은 건 아담이 아니라 이브이고, 인간보다도 루시퍼라고 불리던 사탄 마귀가 먼저 죄를 짓고 타락했는데 그건 까맣게 잊어버렸다. 도대체 어쩌다가 주객이 전도된 그런 오류에 빠졌는지 모르겠다.
그 이름도 유명한 롬 5:12는 너무 당연한 얘기이지만 최초로 죄를 지은 '인간'에 대한 이야기일 뿐, 영원부터 영원까지 하나님의 모든 경륜을 통틀어서 죄라는 걸 처음으로 지은 인격체(사람뿐만 아니라 영적 존재들까지 포함)에 대한 문맥이 아니다.

재창조· 간극을 안 믿는 사람치고 사탄은 정확하게 언제 창조되어 언제 타락했고, 쫓겨나서는 어디로 갔는지 딱 부러지게 설명하는 사람은 단언하건대 전혀 없다. 물과 어둠은 언제 창조됐는지, 6일 창조 중 둘째 날에만 "보기 좋았더라"라는 말이 왜 없는지 같은 것도 설명할 수 있을 리가 없다.

사탄은 교만에 빠져서 자신이 하나님과 대등한 지위를 차지하려고 반역을 저지르는 그야말로 엄청난 죄를 지었다. 그런데도 처벌을 받긴 한 건지 행동 반경에 별다른 제약이 없이 잘만 살아 있다.
그 반면 사람은 어떤가. 이브는 뱀의 꼬드김에 넘어가서 겨우 금지된 선악과 하나 좀 먹는 아주 소심한(?) 죄를 지었을 뿐이다. 아담은 이브보다 더 고의로 적극적으로 하나님 말씀을 어기긴 했지만, 사랑하는 이브가 저 지경이 돼 버렸으니 차라리 같이 죽자는 심정으로 같이 선악과를 먹은 것이다. 어떤 경우든, 사람이 지은 최초의 죄에는 최소한 교만이나 신성모독 같은 괘씸죄 요소는 없었다.

그런데도 아담 부부는 그 날로 낙원에서 추방당하고, 창조 세계가 와르르 타락해서 이 모든 고생이 시작되고, 그야말로 후손들의 인류 역사가 모조리 꼬여 버리는 헬게이트가 시작됐다.
사람과 사탄의 처분을 비교해 보면 이거 좀 형평성이 심각하게 안 맞다는 생각이 들지 않는가? 본인은 옛날엔 이 논리를 들추면서 복음을 거부하고 하나님을 조롱하던 불신자를 실제로 본 적이 있었다.

아담의 죄가 사탄의 죄보다 격이 낮고 죄질이 가볍다는 사실은 오직 킹 제임스 성경을 통해서만 발견할 수 있다. 창 3:5가 '하나님(God)처럼 되어'가 아니라 '신들(gods)처럼 되어'이기 때문이다(사 14:14와 비교해 볼 것!).
더구나 사탄 마귀의 옛 이름인 '루시퍼' 자체도 킹 제임스 성경(사 14:12)에만 존재한다. 얘는 단순히 바빌론 왕이 아니라 진짜 사탄에 대한 이야기로 이중 적용이 가능하다고 말이다. NIV도 아니고 이런 엄청난 영적 조명을 얻을 수 있는 성경을 손에 쥐고서 간극을 안 믿는다고? 논리적으로 정말 말도 안 되는 소리이다.

먼 옛날에 하나님께서 이전 세상을 창조하셨는데 거기서 사탄 마귀가 반역하고 타락함으로써 그 세상은 물의 넘침으로 멸망(벧후 3:6)하고, 땅이 형태가 없고 공허하게(창 1:2) 되었다고 해야만 논리가 맞아 떨어진다. 지금 세상은 6일 동안 새로 "재창조"된 것이며, 에덴 동산에 뱀의 모양으로 몰래 침입해 들어간 사탄은 예전에 누리던 영광에 비해서는 그야말로 빈털터리가 된 상태인 것이다.

재창조· 간극과 관련된 FAQ 중에는 "사람이 죄를 지은 것 대해서는 하나님께서 회개의 여지를 주시고 예수님 같은 구원자를 보내기도 하셨는데 루시퍼에 대해서는 왜 저렇게 가차없이 쫓아내고 세상을 다 뒤집어엎고 완전히 주적을 삼으신 걸까?"가 있다. 이 의문도 루시퍼와 인간이라는 두 인격체가 최초로 저지른 죄의 죄질을 비교해 보면 바로 답을 얻을 수 있다.
루시퍼는 엄연히 내란수괴인 정치범이다. 제5공화국 장 태완 장군의 대사를 빌리자면, 탱크를 몰고 가서 머리통을 날려 버릴 반란군이요 역적놈의 새X이다. 그 반면, 사람은 생계형 잡범에 가까운 죄를 지은 것이다. 그러니 법적으로 서로 다르게 처분하는 게 당연한 귀결 아니겠는가? 하나도 어려울 거 없다.

물론 한번 죄에 빠지고 타락이 진행되면서 아담의 후예들 역시 사탄 마귀와 별 다를 바 없는 반란 가담자로 흑화해 갔으며, 이들은 사탄 마귀를 집어넣으려고 만들어진 지옥에 사후에 불청객으로 들어가게 된 건 사실이다. 또한, 그 엄청난 내란 반역죄에 비해 하나님께서 루시퍼에 대한 완전한 심판 집행은 좀 이례적으로 길게 보류하고 계신 것도 사실이고 말이다. (사람과 관련된 다른 뜻이 있어서..;;)

이전 세상에는 공룡이 살았건 네안데르탈 인이 살았건, 다른 영적 존재들이 살았건 그건 내 알 바 아니다. 단지 아담과 같은 호모 사피엔스만이 전혀 없었을 뿐이며, 그 옛날 생명체들은 설령 지금까지 화석으로 남아 있더라도 인간과 유전적인 관계는 없다.

이런 사탄의 죄와는 달리 아담의 죄는 현 세상을 망가뜨리긴 했지만 사탄의 죄처럼 당대 세상을 깡그리, 송두리째 멸망시킬 정도는 아니었다. 훗날 노아의 홍수는 코로 호흡하는 지표면의 육상 생물만 절멸하는 수준이었으며, 루시퍼 시절의 홍수와는 규모면에서 비할 바가 되지 않는다.

창 1:2의 "the earth was without form, and void"가 대환란 심판 문맥인 렘 4:23 "I beheld the earth, and, lo, it was without form, and void"와 표현이 일치한다는 것은 그야말로 대박이 따로 없다.
창세기의 소돔 사람들이, 그리고 사사기의 베냐민 지파 불량배들이 "우리가 그들을 알리라"라고 말한 것은 서로 정확하게 같은 심상이다.
창세기에서 라헬이 죽기 전에 산파가 "두려워하지 말라, 네가 이 아들을 얻으리라"라고 말한 것과, 사무엘기상에서 비느하스의 아내가 죽기 전에 여인들이 "두려워하지 말라, 네가 아들을 낳았다"라고 말한 것에는 당연히 동질감이 있다.

그것만큼이나 earth was without form and void는 창 1:2와 렘 4:23 공히 명백하게 심판 문맥이고 부정적인 심상이다! 스타 테란 종족으로 치면 SCV가 건물을 짓다 만 상태가 아니라, 파괴된 건물의 잔해인 것이다. 성경을 제대로 읽어서 여기저기 네트워크가 형성된 사람이라면 이런 심상을 놓칠래야 놓칠 수가 없다.
세속 학계에서도 두 논문에 통상 여섯 단어 정도가 연달아 복붙한 듯이 일치하면 그건 우연이 아니라 거의 필연이고 표절을 강력하게 의심하게 된다. 그 잣대를 보더라도 창 1:2와 렘 4:23은 인과관계를 부정하기란 절대 불가능하다.

이런 심상을 무시하고, 어둠도 부정적인 게 아니고 중립적이고 하나님께서 선하게 창조하신 거라고 궤변을 늘어놓는 것은.. 하나님께서 원하시는 뜻과 하나님께서 허락하시는 뜻을 혼동하는 것과 같다. 죄악도 다 하나님의 섭리로 예정된 것이라는 식으로 하나님의 성품을 완전히 왜곡하는 짓이다.
하나님께서 지옥을 만드신 게 과연 하나님이 기뻐하고 원하시는 뜻에 의해서 이뤄진 것인가? -_-;; 이와 비슷한 급의 혼돈을 정치 분야에다 비유하자면, 북한 체제(수뇌부)와 북한 주민을 구분 안 한 나머지 이상한 방법으로 통일을 해야 한다고 쫓아다니는 짓거리와도 같다.

난 재창조 간극이 없을 때 성경에 야기되는 논리 모순과 부조리들이 아주 빤~히 눈에 보인다. 마치 교회 대환란 통과 교리가 야기하는 모순과도 일맥상통한다. 그러니 공룡 박사이자 열혈 간극 반대자요, 젊은 지구 창조론자로 유명한 켄트 호빈드(Kent Hovind) 씨가 몇 년 전에 엉뚱하게 교회 대환란 통과 교리로 전격 전향한것은 우연이 아니라 동일한 오류에 빠진 결과로 여겨진다. 옛날에 안티오크던가 거기를 비롯해 "간극 극렬 반대 + 교회 환란 통과" 진영을 몇몇 본 적이 있다. 거기는 그렇게 같은 영인 것 같다.
성경 교리 체계가 와르르 무너지는 와중에 지금이 무슨 공룡 발자국 화석이 인간과 같은 시기네 뭐네 한가롭게 따질 때가 아니다.

눈에 도대체 뭐가 씌여서 이런 건전한 교리가 별 희한한 거짓 고소와 중상모략으로 매도되고 있는지 참 기가 차고 통탄할 노릇이다. 젊은 우주(지구)는 너무 무리수다 싶어서 아예 창세기 1장의 6일을 문자적으로 받아들이기를 포기하는 것보다야, 그 6일은 그냥 냅두고 간극만 설정하는 게 100배 이상 더 건전한데도 말이다.

사실, 재창조 교리도 아담 이전의 세상에 대해서 아주 상세한 디테일을 제공하지는 않기 때문에, 세속 과학과 여전히 맞지 않는 게 있을 수 있고 선뜻 믿어지지 않는 시나리오가 있을 수는 있다. 간극 반대자들의 트집 역시 성경 해석 쪽이 아니라 이런 지엽적인 과학 디테일 쪽에서 많이 나오기도 한다.
허나, 우리가 무슨 문자적인 24시간 6일 창조를 믿지 않는다는 둥, 아담 이전부터 인간이 살았다고 주장한다는 둥, 있지도 않은 소설을 근거로 비방을 하지는 않기를 간절히 바란다.

본인은 이런 마음을 담고 정말 없는 시간을 쪼개어 최고의 속도와 최고의 품질로 번역을 했다.
회사 다니면서 학교 다니고, 일요일엔 교회에서 하루를 다 보내고, 그러고 남은 개인 시간엔 몽땅 한글 입력기 개발하고.. 글감이 있으면 개인 블로그에다 글까지 꼬박꼬박 써 올리고..
그 와중에 도대체 무슨 짬을 내서 방대한 분량의 책 번역도 할 수 있었는지는 모르겠다. 또 하라면 못 할 것 같다. -_-;;

다만, 시간 스케줄링에 관한 한 세상에 공짜는 없다. 저런 극한의 최적화를 한 대신에 본인은 여가와 유흥이라고는 없는 인생을 살아 왔으며, 운동 부족-_- 때문에 키 대비 체중이 증가하고 있어서 고민이다.
그리고 본인은 무엇보다도 30여 년 평생 모솔이다. 정말 시간이 없어서 할 수가 없다.

참 안타깝고 유감스럽고 불행한 일이지만, 우리나라에 킹 제임스 성경을 번역해서 보급하는 데 큰 기여를 해 온 모 출판사 겸 교회 진영은 간극을 정당한 이유 없이 그저 반대하며, 자신과 믿음이 다른 진영에 대한 거짓 비방을 일삼고 있다. 반대하는 논리들이 나 같은 사람이 보기엔 대부분 말이 안 되는 것들이다. 아직도 진화론과의 절충, 유신론적 진화론, 아담 이전의 인간(세상이 아니라) 따위의 케케묵은 레퍼토리를 벗어나질 못하고 있다. 간극에 대해 제대로 알지도 못하고서 그저 반대하는 것이다.

그러니.. 공은 공이고 과는 과이다. 협력할 건 협력하지만 이 주제에 관해서는 본인 역시 본인의 양심을 걸고 단 한 발자국도 물러설 생각이 없으며 그들의 교리적 오류를 꾸준히 폭로할 것이다. 하다못해 아까 얘기했던 '둘째 날', 사탄의 타락 시기 이런 거 해명이나 좀 하고서, 제대로 된 대안을 제시하고서 자기 주장을 했으면 싶다. 거짓에는 논리와 팩트가 답이다.

창 1:1-2 사이에 간극이 있다는 것은 성경에 스타에 대해서 "처음에 저그 해처리에서 저글링이 나오니라. 그 저글링은 발업이 되고 *and* 아드레날린업이 되었느니라." 라는 구절이 있는 것과 같다.
발업은 스포닝 풀을 지은 순간 바로 가능하지만, 아드레날린업이 되기까지는 그 사이에 레어업에 퀸, 하이브업까지 어마어마한 테크 간극이 필요하지 않은가? 성경에서는 이런 스타일로 기록된 문장을 얼마든지 찾을 수 있다. 대표적인 예가 예수님의 초림과 재림 간극이고 말이다(예: 사 61:2).

진리가 다른 진리와 모순을 일으키고 다른 진리를 파괴한다면 그건 진리가 아니다.
부디 gap이라는 fact가 널리 알려져서 많은 사람들이 진리로 돌아오고 성경의 깊숙하고 은밀한 주제에 대한 안목이 넓어졌으면 좋겠다.
본인은 제프리 티벳의 <창 1:1-3 주석>도 번역했으며, 의도한 건 아니었지만, 다니고 있는 교회에서 거의 재창조 교리 전문가 및 간극 에반젤리스트-_-처럼 활동하고 있다.

Posted by 사무엘

과거 Windows XP 시절부터 눈치 챈 분이 계시려나 모르겠다.
XP에서부터 아시다시피 대화상자 컨트롤들에 테마가 적용되어서 얘들의 비주얼이 알록달록 한결 예뻐졌다. 단, 모든 프로그램에 테마가 자동 적용되는 건 아니며 공용 컨트롤 6.0을 사용한다는 표식이 존재하는 프로그램에 대해서만 테마가 적용된다. 이것은 Windows 프로그래머라면 추가적으로 알고 있을 것이다.

그런데, 콤보 박스의 경우 공용 컨트롤 6.0 것을 사용하면 동작이 약간 달라졌다. ▼ 버튼을 눌러서 drop list를 꺼내면 drop list의 크기가 예전보다 훨씬 더 길쭉해져 있다. 프로그램이 리소스 차원에서 지정해 준 것보다 훨씬 더 길어졌다.
이것은 테마의 적용 여부와는 무관하게 공용 컨트롤 6을 적용하는 것만으로도 나타나는 변화였다.

다음은 <날개셋> 편집기의 문자표 대화상자를 Windows 2000에서 구동한 것과 XP(및 그 이후 모두 포함)에서 구동한 것의 차이를 나타낸 스크린샷이다. 테마나 글꼴과는 무관하다는 것을 보이기 위해 XP에서도 고전 테마를 사용했고, 글꼴 역시 Tahoma로 통일시켰다.
문자표뿐만이 아니라 “보기-편집화면 설정”에서 이미 30개가 넘는 글꼴이 존재하는 한글 글꼴 콤보 박스를 내려 봐도 같은 현상을 볼 수 있다.

그리고 이것은 비단 내 프로그램에서만 발생하는 차이가 아니다. 다음은 Windows 2000과 XP의 워드패드에서 글꼴 콤보를 내린 모습이다. 워드패드는 Windows 7에서 크게 바뀌었지 2000과 XP는 외형의 차이가 거의 없으니 말이다.

콤보 박스에서 drop list의 크기는 원래 콤보 박스가 생성될 때 CREATESTRUCT에 지정되어 있던 크기로 결정되어 왔다. 그 크기는 따로 저장된 뒤, 지금 당장 콤보 박스는 아이템을 1줄만 표시 가능한 정도로 세로 크기가 자동으로 조정되었다.

하지만 공용 컨트롤 6에 있는 콤보 박스는 알 수 없는 이유로 인해 이런 전통적인 동작이 바뀌었다. 원래 지정되었던 세로 크기는 무시되고 drop list는 아이템을 최대 30개까지 표시하는 크기로 지정된다. 그래서 XP에서부터 공용 컨트롤 6을 사용하는 프로그램은 콤보 박스의 drop list가 굉장히 커진 것이다.
그 대신 이 개수를 얻어 오고 바꾸는 메시지가 새로 추가되었다. CB_(GET/SET)MINVISIBLE이 그것이다. 이 메시지는 공용 컨트롤 6 기반의 콤보 박스에서만 사용 가능하다. 개수의 기본 초기값이 30인데, 이것은 이례적으로 상당히 큰 값이다.

단, 공용 컨트롤 6이라 해도 CBS_NOINTEGRALHEIGHT 스타일이 지정된 콤보 박스에는 이런 새로운 정책이 전혀 적용되지 않고 이전의 콤보 박스와 동일한 크기로 drop list가 튀어나온다. 이 스타일은 크기 보정을 전혀 하지 않고 마지막 줄에 아이템의 일부가 잘려 나오는 것도 감수한다는 옵션인데.. 개인적으로 이런 옵션이 왜 있는지 모르겠다. 이걸 사용하는 콤보 박스는 난 지금까지 전혀 못 봤다. 마치 extended UI만큼이나 실용적인 의미가 거의 없음.

여러모로 Windows GUI에서 콤보 박스의 동작과 메시지 API가 왜 이렇게 설계되었는지 본인으로서는 이해할 수 없다. (1) 공용 컨트롤 6이 됐다고 해서 저런 동작이 함부로 바뀌어서는 안 되며, (2) 콤보 박스의 drop list 크기는 자신의 원래 크기를 기반으로 동작해야 한다. 그리고 (3) drop list의 크기를 알아 오거나 바꾸는 메시지는 진작부터 있어야 했다.
XP에서부터 콤보 박스의 drop list 크기가 갑자기 커졌다는 건 오래 전부터 알고 있었지만 왜 그런지는 10년 가까이 제대로 모르고 있었다. 이유를 알게 됐다고 해서 그 이유를 수긍하는 것도 아니긴 하지만.

이것 말고도, Windows XP 첫 버전의 공용 컨트롤 6에서는 owner draw 방식이어서 문자열이 필요하지 않은 콤보 박스에다가도 아이템을 추가할 때 그냥 NULL을 주면 프로그램이 뻗는 어이없는 버그가 있었다. 원래는 그렇게 안 해도 돼야 되는데. 그래서 꼭 0-length 문자열 ""이라도 집어넣어 줘야 했다. 테마 내지 공용 컨트롤 6 기반이 아닌 기존 컨트롤에서는 문제가 없었으니 명백한 운영체제의 버그였다.

<날개셋> 한글 입력기가 최초로 XP 테마를 도입한 버전이 2.3이었는데, 바로 이 버그 때문에 엄청 곤혹을 치렀었다. 이 버그는 XP sp1에서 바로 고쳐지긴 했지만, 비주얼 말고 도대체 뭘 고쳤길래 같은 콤보 박스에 이런 동작이 차이가 났는지 본인으로서는 알 길이 없다. 요컨대 공용 컨트롤 6의 컨트롤들은 설령 다른 테마 없이 고전 테마로 표시된다 하더라도 근간이 기존 컨트롤과는 근본 출신이 다르다.

Posted by 사무엘

문자· 문서를 처리하는 기계의 역사를 살펴보면 기계식 타자기가 발명된 뒤 나중에는 전자식 타자기가 만들어지고, 그게 더 나중에는 컴퓨터가 달린 휴대용 워드 프로세서 기기 형태로 발전했다.

그 뒤 특정 장치에 구애받지 않고 범용 컴퓨터에서 동작하는 워드 프로세서 소프트웨어도 개발되긴 했지만 이 역시 특정 컴퓨터 내지 프린터 번들의 성격이 강했다. 아무래도 워드 문서의 최종 목적지는 인쇄였던지라 프린터의 입김에서 자유로울 수 없었으니 말이다. 게다가 윤곽선 글꼴이 없었으니 글꼴부터가 애초부터 프린터의 해상도에 따라 도트판/레이저판으로 나뉠 수밖에 없었다.

이런 척박한 여건에서 옛날 도스 시절에 '한글'을 처리할 수 있는 워드 프로세서가 몇몇 컴퓨터 선구자들에 의해 개발되었다. 그래픽 모드에서 실행되었던 도스용 한글 워드 프로세서로 제대로 살아남은 건 아래아한글밖에 없다.
관공서에서 많이 쓰였던 '하나' 내지, 삼보 컴퓨터 번들로 제공되었던 '보석글'(엄밀히 말하면 순수 국산 프로그램은 아님)은 그래픽 기반이 아니었기 때문에 편집 중에 각종 속성들은 태그 부호로 표시되었다는 한계가 존재한다..

0. 하나

1995년까지 금성이 아닌 LG 소프트웨어라는 브랜드로도 생각보다 오랫동안 개발됐다. 95년이면 아래아한글은 이미 Windows용까지 나왔을 정도였으니 시대에 너무 뒤쳐지긴 했다. 물론 금성/LG 소프트웨어에서도 그 시기에 다른 팀을 꾸려서 Windows용 '윈워드'라는 제품을 개발했으며 이걸 2.0까지도 만들긴 했지만... 더 오래는 못 갔다.

‘하나’도 아래아한글처럼 문서 확장자가 hwp였다. 하지만 둘은 동일한 포맷은 물론 아니었다. 아래아한글이 하나 문서를 읽거나 쓰는 건 ‘공용(공통) 파일’이라는 이름으로 최소한 아래아한글 2.5나 3.0 등 도스용 에디션의 막바지 시절에야 추가됐다. 자기 hwp와 구분을 위해 확장자는 일부러 kwp라고 했다.

하나와 아래아한글 모두 관공서에서 사랑받은 프로그램답지 않게 한때 보안이 좀 허술했다. 하나의 경우 암호를 걸어서 저장해도 암호가 문서 파일의 헤더에 평문으로 버젓이 저장되었는지 군대에서 이렇게 암호를 뚝딱 풀어서 중대의 영웅으로 추앙받았다는 분의 무용담이 전해진다.

한편, 1994년경엔 아래아한글 2.1 (2.1과 2.5 공용) 파일 포맷의 암호도 어느 서울대 출신의 천재 해커에 의해 뚫려서 화제가 됐는데..
이건 이적행위 증거를 찾으려고 지금의 국정원, 당시의 안기부에서 작정을 하고 해커를 고용해서 뚫은 것이었다고 한다. 개발사인 한컴이 이적행위를 했다는 건 물론 아니고, 사용자 중에 불온문서를 만든 사람이 있었다는 뜻.
단순한 오덕질이나 사적 이익 때문이 아니었다는 점이, 그리고 또한 단순히 한 특정 문서의 암호만 brute force 방식으로 대입해서 알아낸 게 아니라 전반적인 암호화 알고리즘 자체를 파악하고 예측하는 데 성공해 버렸다는 점이 무척 놀랍다.

그 당시 한컴은 2의 32승 운운하면서 “암호를 걸었던 사람이 암호를 잊어버리면 우리조차도 암호를 풀 수 없다. 암호를 뚫으려면 130년은 족히 걸릴 것”이라고 언론 보도까지 내면서 아주 자신만만한 모습이었다. 그런데 그것이 실제로 일어나자 망연자실할 수밖에 없었다. 다음 3.0 버전에서는 즉시 암호화 알고리즘을 변경해야 했다.

그럼 다음부터는 자체한글 '그래픽' 모드에서 실행된 프로그램 얘기를 하겠다.
본인은 오래 전에 윤곽선 글꼴로 한글을 찍는 기능이 어떤 형태로든 있었던 도스용 프로그램을 주목하여 몇 가지 예를 든 적이 있다.
아래아한글 2.x를 제외하면 그래픽 에디터 내지 배너 프로그램이 걸려들곤 했는데, 그것들 말고 아래아한글과 비슷한 급의 상업용 워드 프로세서로는 다음 두 프로그램이 있다. 단, 본인은 어렸을 때 이들 프로그램을 직접 써 보지는 못했다.

1. 사임당

난 10여 년 전에 우리나라에서 5만원권 지폐를 신권 형태로 첫 발행했을 때 이 프로그램이 떠올랐다. 지폐에 들어간 모델 때문이긴 하지만, 그래도 써 본 적도 없는 프로그램을 어떻게 그렇게 분명하게 기억하고 있었는지는 모르겠다.

사임당은 윤곽선 글꼴, 위지윅, 컬러 지원, 그래픽 처리 등의 기술적인 면에서는 아래아한글 2.x 초반대 버전보다 더 뛰어나면 뛰어나지 절대로 못하지는 않았던 매우 우수한 프로그램이었다. 그런 기능들은 따지고 보면 오히려 아래아한글이 도입 타이밍이 더 늦거나 전문용에만 오랫동안 봉인돼 있었다. GUI만 봐도 뭔가 비범한 구석이 느껴지지 않는지?

저기 '무른연모'라는 글자를 보아하니 휴먼샘체/팸체(안상수체는 아님) 같은 한글 가변폭 글꼴도 잘 지원하고 있었다.
사임당은 분명 시대를 앞서갔던 프로그램이었지만, 위키백과의 설명에 따르면 비싼 가격과 강경한 복제 방지 정책 때문에 그리 많이 보급은 못 됐으며 아래아한글을 실질적으로 위협하지 못하고 사라졌다고 한다.

사임당의 개발사인 한컴퓨터 연구소/주식회사도 오늘날의 한글과컴퓨터 못지않은 워드 프로세서 개발 전문 기업이었다. 예전부터 사임당의 전신인 '한글 2000'이라는 프로그램을 만들었고, 사임당 말고도 저가 보급형 프로그램인 '쪽박사, 글박사' 같은 프로그램을 따로 개발했다. 글박사의 경우 본인도 초딩 시절에 컴퓨터 잡지에 소개된 걸 본 기억이 있다. 무려 1992년에! 하지만 이 역시 실물을 직접 써 보지는 못했다.

사임당, 글박사 등의 스크린샷을 보면 저기서 만든 워드 프로세서들은 전통적으로 세로획도 1픽셀인 고딕 계열 글꼴을 UI 표시용 한글 글꼴로 써 왔다. 세로획이 2픽셀인 명조 계열 글꼴을 사용한 아래아한글과는 대조적이다.

2. 21세기 워드

아래아한글과 사임당으로도 모자라서 도스에서 한글 윤곽선 글꼴을 지원했던 그래픽 워드 프로세서가 더 있었다. 그것은 바로.. 지금은 알집과 카발(온라인 게임)로 유명한 그 회사가 먼 옛날 초창기에 만들었던 제품이다.

본인은 실물을 써 보지는 못했지만 컴퓨터 잡지에서 광고를 한 건 봤다. 글꼴을 가지고 대놓고 아래아한글을 디스하고 있었다.
모 제품은 가격이 8만 8천원이나 하는데도 글꼴이 꼴랑 다 깨지는 비트맵 명조로밖에 안 나오는 반면,
우리 21세기 워드는 그거 거의 반값으로도 아주 미려한 윤곽선 글꼴 신명조가 나온다고...;;

디스 당한 모 제품은 뭔지 직접적으로 언급은 안 돼 있지만, 누가 봐도 아래아한글 2.0이던가 2.1의 일반용인 건 뻔한 노릇이었다.
이를 의식해서인지 아래아한글도 2.5 버전에 와서야 일반용/전문용 구분을 없애고 16비트 컴퓨터에서도 컬러와 윤곽선 글꼴을 실현시켰지만.. 때가 좀 늦은 조치였다.

21세기 워드는 글자 크기 조절과 윤곽선 글꼴을 빼면 나머지 워드로서의 기능은 아래아한글 1.5x와 크게 차이가 나지 않았다고 한다. 화면을 딱 봐도 색상이나 글꼴은 아래아한글 1.5x를 대놓고 오마주한 것 같지 않은가? ㅎㅎ
단, 한글의 비트맵 글꼴 명조체는 아래아한글 1.5x가 사용하던 그 명조와는 다르다. 아래아한글은 custom 3차원 조합 테이블을 사용한 약간 더 정교한 글꼴인 반면, 21세기는 그냥 그 당시에 널리 통용되던 초중종 8*4*4벌 도깨비 조합 규칙으로 구현된 명조이다.

어떻게 아냐고? 다 방법이 있다.
도깨비 조합형은 세로줄형 모음에서 받침 ㄴ일 때와 이외의 다른 모음일 때의 구분이 없다. 그래서 '편'(집)일 때와 (입)'력'일 때 ㅕ가 길이가 똑같아서 받침 ㄴ일 때 아래 공간이 약간 허해 보인다.
그 반면, 지금 <날개셋> 편집기의 '바탕'으로 채용돼 있는 아래아한글의 명조는 받침 ㄴ일 때 세로 모음들이 딱 1픽셀 더 길어서 아주 조금 더 균형이 잡혀 보인다. 이런 작은 차이가 존재한다.

사소한 글꼴 디테일 얘기는 그렇고.
그 당시 이스트소프트는 파릇파릇한 공대생 몇 명이 갓 창업한 벤처/스타트업 수준에 불과했기 때문에 기술과 영업 역량에 한계가 있었다. 물론 그 여건에서 천재 프로그래머 몇 명이 이 정도를 뚝딱 만든 건 정말 대단한 일인 건 맞지만, 그런 몇 가지 차별화 요소만 갖고 아래아한글이라는 기득권 아성을 무너뜨릴 수는 없는 노릇이었다.

21세기 워드는 사임당 정도의 엘리트주의로 간 것 같지는 않지만, 어쨌든 그렇게 망하고 역사 속으로 사라졌다. 이걸 계기로 이스트의 창립자분은 뭔가 깨달은 게 있었는지, "그냥 기술적으로 뛰어나기만 한 제품"이 아니라 "사용자에게 잘 어필되고 실질적으로 팔리는 제품"을 만들어야겠다는 실용주의 노선으로 생각을 급선회하게 됐다고 한다. 하긴, 에디슨도 처음엔 자기 오덕질대로만 외곬스러운 발명을 하다가 나중에야 그렇게 깨닫는 계기가 있었다고 들었다.

21세기 워드를 만들었던 회사는 그로부터 6, 7년쯤 뒤 21세기가 실제로 임박하자, 이번엔 '새 폴더'를 비롯해 아주 익살스러운 외형의 압축 프로그램을 무료로 뿌리면서 컴백했다. 본인은 2000년 말, 알집을 4.8대 버전 때 처음으로 접했다. 그런 식으로 잘나갈 수도 있었고 "개인에게만 무료, 기업은 유료" 정책도 나쁘지 않은 것 같았는데.. 프로그램이 압축 본연의 기능이 탄탄하지 않다는 나쁜 소문이 2000년대 초중반에 워낙 퍼지면서 안 쓰게 됐고.. 지금은 빵집을 거쳐서 반디집이 국민 압축 프로그램 타이틀을 물려받았다. 빵집은 퀄리티가 나쁘지는 않았으나 보다시피 개발이 중단됐으니 말이다.

워드 얘기를 하다가 갑자기 딴 얘기가 길어졌네.
아무튼, 저 두 프로그램들은 아래아한글에 밀려 역사 속으로 사라졌다. 그로부터 20여 년 뒤, 도스가 아닌 Windows 얘기이긴 하지만 지난 2014년 가을엔 삼성조차 1992년 이래로 개발돼 왔던 훈민정음을 완전히 포기하고 MS 워드로 복귀를 선언했다. 훈민정음은 처음부터 Windows용으로 개발됐고, 버전 4.5 시절엔 마치 Visual Basic 4처럼 16비트용과 32비트용이 동시에 따로 출시된 탄탄한 제품이기도 했는데 말이다.

훈민정음이 GG를 쳤는데 그럼 아래아한글은? 지금까지 쌓인 인프라가 워낙 많고, 또 아래아한글과 워드는 내부 구조가 서로 너무 다르다 보니 사용자가 하루아침에 전멸하고 쫄딱 망할 것 같지는 않다. 그러나 '갈라파고스화' 알박기 덕분에 겨우 연명하고 있는 비중도 크며, 학교· 군대· 관공서가 아닌 사기업에서 HWP의 입지는 이미 눈에 띄게 줄어들었다는 것을 감안해야 할 것이다. 그리고 결정적으로, 이젠 워드, 엑셀 같은 너무 흔한 필수 프로그램은 그냥 다 공짜로 뿌리는 거나 다름없는 세상이 되기도 했고.
그러니 이스트도 결국은 돈 되는 건 게임이라고 생각하고 진작부터 과감하게 카발을 개발한 것 같다. 이 컴퓨터 소프트웨어 업계가 앞으로 어찌 되려나 참 눈 돌아가겠다.

Windows의 개발 역사에 대해서는 현직 마소 고참 개발자인 레이먼드 챈 아저씨가 The Old New Thing이라는 개인 블로그에서 10년이 넘게 오늘날까지도 구수한 입담으로 그때 그 시절 이야기를 하고 있다. 그것처럼 개인적으로는 아래아한글 1.0부터 현재까지의 역사를 몽땅 꿰뚫고 있는 어떤 개발자가 아래아한글 내지 그 시절 경쟁 워드 프로세서들의 역사를 구구절절 회상하는 코너가 좀 있으면 좋겠다. 필기체가 개발된 사연, 1.2 버전에서 테트리스 게임이 개발된 사연, 한컴 2바이트 코드의 제정 경위, 옛날 공 병우 박사와의 인연 등등 얘기가 엄청 많을 것 같은데..!

Posted by 사무엘

<날개셋> 한글 입력기가 8.0이 나온 뒤 거의 4개월 만에 8.2로 버전이 올라갔다. 1.0 이래로 개발 10주년을 자축한 지가 엊그제 같은데 벌써 15주년이 됐다. ㄷㄷㄷㄷ 이번에도 여느 버전업 때와 마찬가지로 온갖 부분에서 자잘한 개선과 변경 사항이 생겼다. 이 8.2는

• 1.0 이래로 개발 15주년 돌파
• 전체 소스 코드가 7만 줄 돌파
• 32비트 msi 배포 패키지가 정확히 2MB 돌파
• 32비트 ngs3.dll 커널 크기가 700KB 돌파

라는 여러 기록을 보유하게 되었다.

타자연습은 변화 사항이 없지만 API 구조와 폰트 로딩 방식의 변경 때문에 불가피하게 재컴파일 업데이트를 하게 됐다. 입력기는 8.2인데 타자연습은 구버전을 계속 사용한다면, 실행은 되겠지만 이제 글꼴 리스트에 글꼴들이 제대로 표시되지 않을 것이며, '고급 입력 스키마/입력기'는 로딩이 되지 않을 것이다. 그러니 타자연습도 부득이 같이 업데이트를 해야 한다.

1. Windows 10 지원

이번 8.2는 Windows 10에서 정식으로 테스트된 최초의 버전이다.
Metro UI에서는 제어판이나 텍스트 필터처럼 데스크톱 GUI를 사용하는 기능들을 모두 사용할 수 없게 막았다. 이건 뭔가 새로운 기능을 추가한 것도 아니고, 지금까지는 굳이 필요하지 않던 안전 체크 오버헤드만이 추가된 것일 뿐이다. 본인은 개인적으로 Metro UI는 왜 존재하는지 모르겠다.

명령 프롬프트에서 한글 입력이 더 진행되지 않던 문제를 고쳤고, 그 상태에서 제어판이 동작하지 않던 문제도 해결했다. (명령 프롬프트는 Metro 앱이 아니기 때문에 제어판 접근이 가능해야 한다.) 두 문제 모두 Windows 10의 명령 프롬프트는 예전 버전과는 영 다른 방식으로 동작하기 때문에 발생했었다.

이 정도 보완만 해 주면 되는 듯하나, Edge 브라우저에서 페이스북의 댓글란에 한글 입력이 제대로 안 되는 것은 기술적으로 해결 불가능한 문제로 남았다. 도대체 입력 문자를 어떻게 넘겨 줘야 MS IME 와 동일하게 동작할 수 있는지 현재로서는 알 수 없다. Edge의 버그에 더 가까운 것 같다.

늘 느끼는 것이지만, Windows에서 한글 입력기를 만드는 일은 프로토콜이 IME에서 TSF로 바뀌면서 무질서도와 난관이 한 10배 가까이 뛰고 더 복잡하고 어려워졌다. 예전에는 뭔가 static하고 write-only이기만 하던 고정 프로토콜에다가 문자열을 넣어서 메시지만 쏴 주면 됐지만 지금은 스레드 동기화부터 시작해서 온갖 복잡한 COM 객체 관리, 게다가 레거시 프로그램에 대한 호환 유지, 스펙대로 동작하지 않는 프로그램에 대한 보정.. 등 지저분함이 이루 말로 표현할 수 없다.
극소수 프로그램에서 드디어 텍스트의 임의 조작이 가능해진 것은 분명 큰 발전이지만, 그것 말고 똥싸 놓은 걸 치워야 하는 것도 많다.

2. 입력 패드에 후보 변환 기능 추가

요 근래엔 <날개셋> 한글 입력기의 제3의 구현체인 입력 패드가 장족의 발전을 거듭해 왔다.
7.9에서는 '화면 키보드' 기능에 눌린 글쇠 표시 기능이 추가되었으며, 이 작업을 발전시켜 8.0에서는 입력 패드가 여타 구현체와 대등한 수준으로 키보드 입력이 가능해졌다. 그리고 이번 8.2에서는 조합 중인 글자 하나에 한해서 한자 후보 변환까지 가능해졌다. 그리고 이 기능을 구현하기 위해 후보 변환 프로토콜을 전반적으로 재설계· 확장하는 대공사가 선행되었다.

지금까지 <날개셋> 한글 입력기가 내부적으로 사용하는 프로토콜은 중간에 후보 변환 요청이 있는 경우, 사용자가 무슨 후보로 변환할지 완전히 응답을 해야(취소하는 것도 포함해서) 다음 단계로 진행이 되는.. 일종의 순차· 동기적인 진행만을 지원했다.

이것은 편집기처럼 한자 후보 목록이 별도의 modal 대화상자로 출력되는 구현체에는 곧장 적용 가능한 만한 반면, 외부 모듈처럼 (1) 후보 목록이 뜬 채로 key 입력을 계속 받아들여야 하는 구현체에는 적합하지 않은 구조였다. 그렇기 때문에 동일 코드의 중복 같은 지저분한 편법이 필요했다. 그런데 외부 모듈과 비슷하게 동작하는 구현체(= 입력 패드)가 또 추가되고, 적합하지 않은 프로토콜을 여기에 또 적용할 수는 없기 때문에 이 기회에 리팩터링을 왕창 하게 되었다.

또한, 기존 프로토콜은 한자 후보 선택을 받은 뒤에 cursor를 이동시키거나 텍스트를 조작할 수만 있었지, (2) 반대 순서의 동작을 시킬 수는 없다는 한계도 지니고 있었다. cursor를 이동시켜서 다른 위치에 있는 글자에 대해 후보 변환을 할 수가 없었다.

아래아한글이나 MS IME에서 '토선생'이라는 단어를 입력해서 '생'을 조합하고 있는 상태로 한자 키를 누르면.. 앞의 '토선'이 선택되고 土船이 후보로 제시된다. 그거 변환을 하고 나면 cursor는 다시 '토선'이 아니라 '생'의 뒤로 딱 되돌아온다.
그러나 <날개셋> 한글 입력기는 cursor 위치는 변함이 없고 뒷부분의 '선생'이 선택되고 先生이 후보로 제시된다. 전자와 같은 동작은 프로토콜 차원에서 근본적으로 구현할 수 없기 때문이었다.

8.2부터는 드디어 이런 한계가 없어졌다. 내 프로그램 역시 MS IME와 완전히 동일한 방식으로 자유자재로 텍스트를 조작하면서 원하는 때에 후보 변환 UI를 modal 형태든 그렇지 않은 형태든 꺼낼 수 있다. 단, 실제로 MS IME와 동일한 방식으로 동작하는 기능 자체는 당장 반영되지 않았고 <날개셋> 한글 입력기의 소스 내부에 #ifdef ... #endif의 형태로 막혀 있다. 일단은 이론적으로 구현 가능해졌다는 것만 입증하고 넘어갔다.

<날개셋> 입력 패드에 후보 변환 기능은 이런 최신 프로토콜을 기반으로 구현되었다. 외부 모듈에 존재하는 후보 선택 UI를 그대로 가져다 쓰는 것을 고려했지만 현실에서의 여러가지 문제점으로 인해 그렇게 하지 않고 또 자체 구현을 했다. 외부 모듈의 후보 선택 UI는 운영체제의 프로토콜과 맞물려서 패드에는 필요하지 않은 오버헤드가 너무 많기 때문이었다.

입력 패드의 후보 선택 UI는 <날개셋> 한글 입력기의 GUI 엔진이 자체 제공하는 리스트박스 컴포넌트를 이용하여 최대한 간결· 단순하게 구현되었다. 외부 모듈의 것과 거의 동일하지만 확장 모드(tab 키)는 지원되지 않으며, 세로쓰기 모드의 지원도 기술적으로 불가능하지는 않으나 구현을 과감히 생략했다.

그 대신 입력 패드의 후보 리스트는 스크롤 막대를 마우스로 누르거나 끌어 보면, 줄 단위 스크롤이 가능하여 좀 더 직관적이라는 차이가 존재한다. 외부 모듈의 그것은 언제나 페이지 단위 스크롤만 된다. 물론 마우스가 아니라 키보드 화살표로 선택막대를 움직이면 페이지 단위로 스크롤된다. 페이지 단위로 이동 후 1~9 숫자를 선택하는 동작도 여전히 고려했기 때문이다.

후보 UI를 구현할 때 같이 구현돼야 하는 중요한 요소 중 하나는 후보 윈도우를 어디에다 표시할지를 결정하는 것이다. cursor 근처 아래에다가 표시해 주는 게 원칙인데, 이걸 hook 프로시저를 통해 알아 와야 한다. 이때는 IME 쪽 인터페이스만 사용하는 게 아니라 오버헤드를 감수하고라도 정확도의 향상을 위해 TSF 인터페이스도 사용한다. 훅킹으로 응용 프로그램에서 TSF edit session까지 요청해 보는 것은 처음이어서 프로그래밍이 굉장히 흥미로웠다. 32비트와 64비트를 구분 없이 모두 잘 지원하는 건 물론이고.

단, 이미 사용하고 있는 시스템의 IME가 한영 내지 한자 키를 가로채고 있으면 키보드 입력 모드에서도 이 입력 패드가 그 key들을 가로챌 수 없다. 그러므로 입력 패드에서 한자 변환을 하려면 F9 같은 다른 위치에다가 C0|0x82 같은 후보 변환 기능을 배당해 놓고 있어야 한다.

3. 글꼴 쪽의 변화

'한메가는본문'이라고 타자기 자형처럼 생긴 한글 글꼴이 지금까지 있었다. 개인적으로는 이것과 Lucida Console 영문 글꼴이 같이 잘 어울린다고 생각했는데, 이번 8.2에서는 이것과 같은 계열인 '한메굵은본문'이 추가되었다. 도스용 한메한글이 출력하던 글꼴을 그대로 재현한 것이다.

한메 계열 글꼴은 초성 5, 중성 2, 종성 3벌로 되어 있어서 도깨비 8*4*4보다 구조가 더 간단하다. 특히 '고'의 ㄱ과 '공'의 ㄱ이 동일해서 더욱 타자기 글꼴 같은 느낌이 나지만, 그렇다고 진짜 샘물이나 타자기 계열만치 과격한 모양은 아니다. 또한, '한솔바탕'과도 좀 비슷해 보이지만 그래도 엄연히 차이가 느껴진다.

그리고 이번에 굵은본문을 분석하고 추가하는 과정에서, 기존 가는본문의 조합 규칙이 몇 년째 잘못되어 있던 것도 같이 발견하여 고쳤다. 당장 '메' 자를 보면 차이를 발견할 수 있다.

잘 알다시피 <날개셋> 한글 입력기는 컴퓨터에서 한글을 '입력'하는 모든 아이디어와 기술을 구현하는 기반 시스템이다. 그런데 편집기는 다른 구현체와는 달리 독자적인 한글 글꼴 출력 시스템도 갖추고 있으며, 특별히 과거에 존재했던 다양한 독창적인 비트맵 글꼴들을 몽땅 한데 재현하는 일에도 덤으로 관심을 두고 있다. 아래아한글, Windows 3.x, mshbios 등. 입력 방식뿐만 아니라 글꼴도 보존 가치가 있는 옛날 데이터가 또 발견된다면 얼마든지 채택되고 추가될 것이다.

그리고 이번 버전에서는, 겉으로 차이가 느껴지지는 않겠지만 글꼴의 전반적인 로딩 방식을 memory-map 기반으로 바꿨다. 그래서 여러 프로그램에서 <날개셋> 한글 입력기 외부 모듈을 사용하고 있고 여러 프로그램들이 동일한 한자 글꼴 같은 걸 중복해서 로딩하더라도, 메모리가 제각각 따로 할당되는 게 아니라 1파일 1메모리가 보장되어 더 효율적으로 동작하게 했다. 뭐, 요즘처럼 메모리가 넘치는 환경에서는 겨우 16*16 비트맵 글꼴 나부랭이는 중복 로딩을 한다 해도 별 부담이 되진 않겠지만 말이다.

4. 변수 N의 의미 확장

기본 입력 스키마가 글쇠배열에다 제공하는 변수로는 P (caps lock 여부), N (num lock 여부), T (오토마타의 조합 상태), D~F (입력 중인 한글 자모)가 있다. T, D~F는 정수인 반면 P와 N은 일종의 0 아니면 1의 boolean값이었다.
그런 키보드 램프의 상태에 따라 서로 다른 문자를 되돌리고 싶으면 해당 변수 값을 토대로 ? : 조건부 수식을 지정하면 된다. caps lock은 그렇다 치더라도 num lock의 경우, 세벌식 글쇠배열의 숫자 자리를 키패드처럼 바꾸는 용도로도 활용할 수 있어서 매우 편리하다.

본인은 이 생각을 아주 오래 전부터 했기 때문에 저건 <날개셋> 한글 입력기의 1.0때부터 있던 기능이었다. 단지 그때는 지금 같은 입력 스키마와 문자 생성기의 계층 구분이 없었기 때문에, 그 기능이 입력 스키마의 변수가 아니라 그냥 입력 옵션 중 하나로 제공되었을 뿐이다.

그런데 이번 버전에서는 옵션을 추가로 줄 경우, N에 num lock (비트 1)뿐만 아니라 scroll lock (비트 2)도 같이 줄 수 있게 했다. 이 옵션이 지정되어 있으면 N은 앞으로 키보드의 상태와 관련된 다른 유의미한 비트 플래그가 도입될 경우 4, 8, 16 같은 식으로 의미가 계속 추가될 것이다.

scroll lock은 사실 굉장한 잉여 램프로 전락해 있으며 caps lock만치 문자 입력에서 중요한 역할을 하지는 않는 게 현실이다. 그렇기 때문에 별도의 독립된 변수를 할당하지는 않고 기존 N에서 비트만 추가하는 것으로 의미를 정했다.
그래도 기능을 일단 만들어 놓으면 이것도 아주 창의적으로 활용하는 사용자가 분명 있으리라고 생각된다.

따라서 이 옵션을 켠 상태에서 num lock만 인식하려면 글쇠 수식을 N ? A: B 이렇게 작성할 게 아니라 번거롭지만 N&1 ? A: B라고 써 줘야 한다.
세벌식 키패드 수식을 생성해 주는 빠른설정 기능은 여기에 맞춰 &1이 추가되도록 알고리즘이 수정되었다.

5. 키보드 드라이버 보정

이번 버전에서는 입력기나 편집기 계층이 아니라 시스템 계층에서 꽤 참신한 기능이 하나 또 추가되었다. 바로 키보드 드라이버의 글쇠 인식을 인위적으로 변조하는 기능이다.
내 프로그램의 내부에는 Shift+Space를 '한영'으로 바꿔서 인식하는 type-3 키보드의 동작을 도로 무효화하는 보정이 있었다. 그런데 이 로직이 편집기와 외부 모듈과 패드의 구현체에 몽땅 중복으로 존재하며, 이것도 켜거나 끌 수가 있게 해야겠다는 생각에 별도의 계층으로 빼냈다.

그리고 type-3 보정뿐만 아니라 type-1 보정도 추가했다. 바로, 오른쪽 Ctrl/Alt를 한영/한자가 아니라 있는 그대로 인식하는 것 말이다. 이로써 한국어 키보드에서도 Ctrl/Alt의 좌우 구분이 가능해졌다. 물론, 아무 보정을 하지 않는 것도 가능하고 말이다. 왜 이런 유용한 기능을 진작에 넣지 못했나 하는 아쉬움이 느껴진다.

그리고 여기서 키보드 드라이버 보정을 한 것은 물론 응용 프로그램이 아니라 <날개셋> 한글 입력기 내부에서만 통용된다. type-1 보정을 했다고 해서 오른쪽 Alt로 응용 프로그램의 메뉴를 바로 열 수 있는 건 아니다.

시스템 계층 설정에는 지금까지 글꼴과 관련된 설정과 기능 몇 가지만 있었는데 '보정 없음, type 1, type 3'이라는 세 항목 중 하나를 선택하는 UI도 추가되었다.
시스템 설정의 내용은 사용자 컴퓨터의 레지스트리에 저장되지, ist/st 같은 파일에는 저장되지는 않는다. '미저장 확인'을 누르면 해당 프로그램이 실행되어 있는 동안만 유효하니, '확인'을 눌러야 레지스트리에까지 저장되어 다음에 프로그램을 재실행할 때도 반영된다.

6. 키패드 글쇠와 키보드 글쇠의 구분 기능

Scroll lock 지원과 키보드 드라이버 보정. 이번 버전엔 어쩌다 보니 키 입력 인식과 관련된 기능이 여럿 추가됐는데, 이것만 들어가기에는 좀 아쉽다.
이번 8.2에서는 <날개셋> 한글 입력기의 개발 역사상 최초로 일부 글쇠에 대해 키패드 글쇠와 키보드 글쇠를 구분해서 인식할 수 있게 되었다.

그 대상은 바로 상하좌우 화살표(4) + Home/End/Pg Up/Pg Dn(4) + Ins/Del(2) + 엔터 이렇게 총 11개이다.
단축글쇠 배당 대화상자를 열어서 이들 키를 누르면.. 오른쪽에 종류를 묻는 콤보 상자가 추가로 뜬다. 사용자는 종전처럼 "구분 없이 아무 거나 인식"을 선택해도 되고, 키보드 것만 혹은 키패드 것만 인식하게 설정할 수 있다. 문자 키와 키패드 사이에 따로 몰려 있는 구역도 '키보드' 영역이다.

그리고 고급 입력 스키마에서는 바로 N 변수에서 1(num lock), 2(scroll lock)에 이어 4가 이 글쇠의 변별을 담당한다.
Windows의 키보드 메시지에서 extended key 플래그가 바로 여기에 전달된다. 다른 글쇠들은 키보드 글쇠일 때 플래그가 켜져 있지만, 엔터만 유일하게 키패드 글쇠일 때 플래그가 켜져 있다. 여기에는 사연이 좀 있다.

extended key란 예전의 84/86키 키보드에는 없다가 지금과 같은 101/103키 키보드에서 중첩되어 새로 추가된 key를 나타내는데, 예전에는 키패드에 엔터가 없다가 나중에 키패드에 새로 추가됐기 때문이다.
그 반면, 나머지 home, end 같은 건 원래 키패드에만 있다가 나중에 별도의 구역이 또 추가된 것이기 때문에 '키보드'에 속하는 구역의 글쇠들이 extended이다.

아무튼 이런 옵션과 변수를 통해서 단축글쇠와 고급 입력 스키마에서 모두 키보드와 키패드를 구분해서 글쇠를 인식할 수 있다.

7. 보조 입력 도구

끝으로, 사소한 사항으로는..
보조 입력 도구인 '부수로 한자 입력'에서 부수나 한자를 우클릭했을 때 해당 글자를 클립보드에 복사하는 명령을 추가했다. 지금까지는 이 명령이 문자표에만 있지 부수 한자 입력에는 없었다.

그리고 문자표에는 알다시피 문자를 운영체제의 특정 글꼴로 출력하거나 내장 비트맵 글꼴로 출력하는 옵션이 있는데, 제어판의 시스템 계층에서 설정된 그 후보 출력용 글꼴을 지정하는 옵션도 추가했다. 지금까지 이런 기능이 왜 없었는지 모르겠다.
이들 보조 입력 도구는 지금으로부터 5~6년 전, 5.5x 시절에 처음으로 도입되었다. 참 격세지감이다.

위의 신규 기능들을 구현하는 과정에서 꽤 황당한 버그가 오랫동안 남아 있던 것을 발견했다.
원래 날개셋 제어판을 열었다가 '확인'을 눌러서 닫으면 입력 설정만 저장되는 게 아니라 모든 플러그 인들의 설정도 파일로 저장된다. 텍스트 필터들의 내부 설정들이 여기에 포함되며, 문자표는 사용자가 예전에 선택한 글꼴과 view 모드를 이 방식으로 기억하고 있는다.
그런데 64비트 에디션은 그런 플러그 인 기능들을 설정을 변경한 뒤 사용하고, 날개셋 제어판을 '확인'을 눌러서 닫았는데도 해당 프로그램(편집기 같은..)을 재실행했을 때 예전 설정이 보존되어 있지 않았다. 파일 오프셋과 관련된 착오가 있는 것을 확인해서 즉시 고쳤다.

Posted by 사무엘