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

군대 유머, 관제탑 유머가 있는 것처럼 변호사를 소재로 한 블랙코미디 시리즈가 있다.
돈만 주면 자기 양심과 혼까지 팔아서 온갖 미사여구와 궤변(?)으로 범죄자의 형량을 감소시키고 심지어 무죄로 조작한다는.. 변호사에 대한 좀 과장되고 왜곡된 이미지가 들어가 있다.

천당과 지옥(혹은 천사와 악마)이 법정에서 소송이 붙으면 천당/천사 진영은 아마 승산이 없을 거라는 개드립조차 있다. 왜냐하면 유능한(=타락한-_-) 변호사들은 몽땅 지옥에 가 있어서 다 악마 편이기 때문에. -_-;; 물론 영적 법정에서 실제로 하나님이 어떤 편인지를 안다면, 그리고 성경에서 judgment라든가 judge라는 단어의 용례만 쭉 뽑아 보면 개드립은 그냥 개드립일 뿐이라는 걸 알 수 있다.

그런데 변호사가 굉장히 바보 같은 질문을 할 때가 있(었)는가 보다. 예를 들어..

• 그림을 도둑맞던 당시에 선생님/고객님은 현장에 계셨습니까?
• 그 일을 혼자 하셨나요? 아니면 단독 범행?
• 충돌 당시에 두 차가 얼마나 떨어져 있었죠?
• 그 스무 살 먹었다는 막내아들이 나이가 어떻게 된댔죠?
• 전쟁에서 죽었다는 사람이 당신이었습니까, 아니면 당신 동생이었습니까?
• 건망증을 앓고 계셨다면, 그럼 그 동안 잊어버린 것들의 예를 좀 들어 주시죠.

도대체 저 변호사 양반이 왕년에 그 무시무시한 사법 시험을 어떻게 통과했는지, 아니면 악착같은 공부 기계 괴수들이 몰리는 로스쿨을 어떻게 들어가서 졸업했고 어떻게 변호사 시험을 합격했는지를 의심케 하는 대목이 아닐 수 없다.

바보같은 질문은 그 변호사가 너무 격무에 시달린 나머지 (1) 정말로 뇌에 나사가 좀 풀려서 감을 잃었거나, (2) 정신 없어서 의뢰인을 완전 성의없게 대해서 나올 수 있다. 하지만 한편으로는 (3) 일부러 바보 같은 질문을 던져서 일종의 심문을 하려는 의도도 있다. 같은 내용을 비비 꼰 바보 같은 질문에 낚여서 진지하게 대답하다 보면, 일관성 없는 진술이 들통날 수 있기 때문이다.

뭐, 여기서 내가 법조인들의 심리나 심문 기법 같은 걸 얘기하려는 건 아니고.
중요한 건, 자연 언어뿐만 아니라 프로그램 코드도 사람이 작성하는 것이다 보니 저런 바보 같은 문장이 있을 수 있다는 것이다. 그리고 컴파일러가 그걸 지적해 주는 것을 우리는 '경고'라고 부른다.

간단한 예로는 선언만 해 놓고 사용하지 않은 변수, 초기화하지 않고 곧장 참조하는 변수, 한쪽에서는 class로 선언했는데 나중에 몸체를 정의할 때는 동일 명칭을 struct로 규정한 것이 있다. 딱히 에러까지는 아니고 코드 생성이 가능하지만, "혹시 다른 걸 의도한 게 아니었는지" 의심할 만한 부분이다.

더 똑똑한 컴파일러는 세미콜론이나 =/==사용이 아리까리해 보이는 것도 경고로 찍으며, 이런 것도 지적해 준다.
unsigned long p; (...) if(p<0) { }

unsigned 타입의 변수를 보고 "너 혹시 0보다 작니?"라고 묻는 건 그야말로 변호사가 "당신과 당신 동생 중 전쟁에서 죽은 사람이 누구라고 했죠?"라고 묻는 것이나 다름없다. 그러니 저 if 안에 있는 코드는 unreachable이라고 지적해 주는 건 적절한 조치이다.

사실, 사람이라 해도 처음부터 대놓고 저렇게 바보 같은 문장을 작성하는 경우는 드물다. 작성한 지 오래 된 코드를 나중에 리팩터링이나 다른 수정을 하게 됐는데, 같이 고쳐져야 하는 문장이 일부만 고쳐져서 일관성이 깨지는 경우가 더 많다. 남이 int를 기준으로 작성해 놓은 코드를 나중에 후임이 UINT로 고치면서 저 if문의 존재를 잊어버린다거나(알고 보니 이 값에 음수가 들어오거나 쓰일 일은 절대 없더라). 버그도 이런 식으로 생기곤 한다.

비주얼 C++에서 경고는 총 4단계가 있다. 1단계는 정말로 말이 안 되어 보이는 것만 출력하고, 4단계까지 가면 정말 미주알고주알 별걸 다 의심스럽다고 지적한다. 경고들을 그렇게 여러 단계로 분류한 기준은 딱히 표준이 있지는 않고 그냥 컴파일러 제조사의 임의 재량인 것으로 보인다.

비주얼 C++이 프로젝트를 만들 때 지정하는 디폴트는 3단계이다. 3단계를 기준으로 깔끔하게 컴파일되게 작성하던 코드를 4단계로 바꿔서 빌드해 보면 이름 없는 구조체를 포함해서 사용되지 않은 '함수 인자'들까지 온통 경고로 뜨기 때문에 output란이 꽤 지저분해진다. 물론, 특정 경고를 그냥 꺼 버리는 #pragma warning 지시문도 있지만, 그 자체가 소스 코드를 지저분하게 만드는 일이기도 하고.

그러니 어지간하면 3단계만으로 충분하지만, 4단계 경고 중에도 컴파일러가 잡아 주면 도움이 되겠다 싶은 일관성 미스 같은 것들이 있다.
그래서 모든 사람들이 코드의 모든 구조를 알지 못하는 공동 작업을 하는 경우.. (직감보다 시스템이 차지하는 비중이 더 커짐) 그리고 팀원/팀장 중에 좀 결벽증 강박관념이 있는 사람이 있는 경우, 4단계를 기준으로 프로젝트가 진행되며, 커밋하는 코드는 반드시 경고와 에러가 하나도 없어야 한다고 못을 박곤 한다. 심지어 경고도 에러와 동등하게 간주시켜서 빌드를 더 진행되지 않게 하는 컴파일 옵션을 사용하기도 한다.

변호사 유머를 보니까 컴파일러의 경고가 생각이 나서 글을 썼다.
내 생각엔 a=a++처럼 이식성 문제가 있고 컴파일러 구현체마다 다른 결과가 나올 수 있는 코드에 대해서나 경고가 좀 나와 줬으면 좋겠다. 저것도 초기화되지 않은 변수만큼이나 문제가 될 수 있기 때문이다. 비주얼 C++의 경고 level 4 옵션으로도 저건 그냥 넘어가는 듯하다.

예전에도 얘기한 적이 있듯, 법은 사람을 제어하는 일종의 선언/논리형 프로그래밍 언어로서 컴퓨터 사고방식으로 생각할 수도 있는 물건이다. 또한, 프로그램의 버전을 얼마나 올릴지 결정하는 게 형벌의 양형 기준과 비슷한 구석이 있다.
잡다한 기능들을 많이 추가한 것, 짧고 굵직한 기능을 구현한 것, 비록 작업량은 별로 많지 않지만 현실에서의 상징성과 의미가 굉장히 큰 것, 아니면 그냥 적당히 시간이 많이 흘렀기 때문에 숫자를 팍 올리는 것.

형벌이라는 것도 사람을 n명 죽인 것에 비례해서 징역이 올라가는 그런 관계는 당연히 아닐 테니, 상당히 많은 변수들이 감안된다.
이런 것들을 다 감안해서 다음 버전의 숫자를 결정하는데 이거 굉장히 복잡하다.

Posted by 사무엘

1. MBC 뉴스데스크

나무위키를 돌아다니다가 거의 성지순례 급의 진귀한 동영상을 발견했다. 바로, 역대 MBC 뉴스데스크 오프닝 화면의 역사이다.

본인은 1981년에 제정되어서 87년까지 쓰였다고 하는 BGM을 기억한다.
현란한 신시사이저 소리를 배경으로 굵직한 "시~솔 ... !@#!!@# .. (옥타브 up) 솔 솔라 시~솔~" 쿠우우웅~~ 멜로디가 깔리는 게 아주 인상적이었다. 30년 전 그 옛날에는 고전과 현대 음악을 두루 섭렵한 방송 기획자가 심혈을 기울여 선곡한, 아주 참신한 음향 효과였지 싶다. 곡명은 구스타브 홀스트의 Jupiter, the Bringer of Jollity의 도입부를 또 일본에서 리메이크한 곡이라고 한다.

물론, 본인이 TV에서 저걸 직접 본 건 거의 유치원을 갈까말까 하던 꼬마 시절이었으며, 선사시대(내가 직접 남긴 기록이나 기억이 없는)에서 역사시대로 옮겨간 직후였다. 1988년부터 음악이 딴 걸로 바뀌었다고 하니 올림픽을 하기도 전에 교체됐다. 난 그렇게 일찍 바뀐 건 아니라고 생각했다만.. 그래도 1987년 7월에 새마을호 전후동력 디젤 동차가 투입됐던 시절엔 아직 이 시그널송이 쓰였다.

지금은 바뀐 지 10년이 넘었지만, 저 MBC 영문 서체는 아직 기억하는 분들이 많을 것이다. 영문 서체는 Banco라는 기성 서체이지만 '뉴스데스크'라는 한글은 영문 서체의 느낌을 보고 손으로 획을 그려 만든 일종의 캘리그래피?로고타입?에 가까워 보인다. 한글까지 포함된 완전한 문화방송체 서체는 90년대에 가서야 나중에 개발된다.

그리고 옛날에는 이유는 모르겠지만, 뉴스의 시그널송이 끝난 뒤에 광고 리스트가 뜨는 동안은.. 웬일인지 무슨 기계가 탈탈탈탈~ 돌아가는 소리가 나왔다. 윤전기를 돌리는 소리라고 하는데 그땐 왜 그런 소리를 넣었을까? 1990년대가 넘어서야 탈탈탈 소리 대신에 그때도 BGM이 나오게 바뀌었다. 그리고 광고 리스트도 세로쓰기가 아닌 가로쓰기 형태로 바뀌었다.

1980년대 아니랄까봐, 그때는 반드시 대머리 대통령의 근황부터 먼저 전하는 땡전뉴스 관행이 KBS와 MBC에 공히 있었던 듯하다. 그것도 모자라서 하도 '한편 이 순자 여사께서는...'이 관용구로 많이 등장하다 보니, 대통령 영부인의 호가 '한편'이라는 개드립도 나돌았다.

그때는 강 성구 앵커도 종종 보이는데... 맞다. 1988년 8월에 "귓속에 도청장치가 있습니다 여러분!"이라는 희대의 엽기적인 방송 사고를 경험한 그 앵커이다. 그 사람은 훗날 MBC 사장에 국회의원까지 역임하면서 굉장히 승승장구하고 성공했으나.. 2013년엔 음주운전과 식당 주인 폭행으로 물의를 빚기도 했다.

2. 만화영화 주제가들

다음으로 만화 주제가도 빼놓을 수 없다. 옛날에는 성우에 대해서 글을 썼었는데 내용을 더 보강하겠다. 먼저, 요술 공주 밍키.

아버지가 작곡하고 딸이 불렀구나(당시 10~11살).;;; 과연 음악 가문이다.
하긴, 아버지는 억만장자 수학 교재 저자이고 딸은 서울대 수학과 교수인 집안도 있고,
아들은 로토스코핑으로 아케이드 게임을 만들고 아버지는 거기 들어갈 음악을 만든 집안도 있지. =_=;;

저건 내가 태어나기 거의 직전에 방영된 만화영화인지라, 본방을 직접 보는 건 불가능-_-했고 다른 경로로 주제가만 들어서 알고 있었다. 듣자하니 엔딩이 굉장히 충격적이었다는데.. (제작사에서 주인공인 밍키를 어이없게 죽여 버렸다고..)
주제가는 가수의 목소리가 참 곱고 노래 잘 부른다고 오래 전부터 생각을 했다. 곡도 동요스럽게 잘 만들었고.
그리고 밍키 주제가 같은 경우, 화음이 최하 3부 정도 있다. 가장 높은 화음은 원래 파트하고 같은 목소리가 아닌데 누가 같이 불렀나 하는 생각도 든다.

그랜다이저 역시 본방을 보지는 못한 엄청 옛날 작품이긴 하다만.. 이거 주제가도 남자 목소리에 같이 곁들어져 있는 여자아이 목소리는 역시 동일한 정 여진이다.
명랑하고 경쾌하고.. 가사를 좀 바꾸면 거의 군가로 불러도 될 것 같다.
가사가 "빠~ 빠빠빠. ... 태양을 향해라 용기를 마셔라" 이렇게 시작하는데.. '용기'(courage) 다음에 '마시다'(drink)라니, 참 독특 희한한 연어 관계이다. 저게 뭔 말인지 궁금해진다.

다음으로, 세월이 흘러 본인이 직접 본방을 본 적이 있는 만화영화를 몇 개 소개하겠다. 말괄량이 뱁스와 은비 까비의 옛날 옛적에는 가수가 모두 조 갑경이다.
전자는 동영상의 화질은 좀 개판이다만, 별로 신경쓸 것 없고 노래만 들으면 된다. 어차피 그 당시의 영상 자체를 보고 싶으면 유튜브에서 tiny toon adventures라고 영어 원판을 시청하는 게 훨씬 나을 테니까. 노래는 정말 귀엽고 깜찍하고, 동심을 마음껏 자극하는 창법으로 부른 게 느껴진다.
후자의 경우, 당시 KBS2 텔레비전에서 금요일 저녁에만 방영한 국산 애니 시리즈였는데, 덕분에 본인의 불금 엔터테인먼트를 책임지곤 했다. 노래 자체는 남녀 듀엣이기 때문에 남자 가수도 포함돼 있다.

미국 만화영화 중에는 미키마우스에다가 슈퍼맨을 합친 컨셉인 듯한 마이티마우스도 있었는데.. 국내에서는 MBC에서 1992년에 수입· 번역해서 방영을 했었다. 단선 선로에서 마주 보며 달려오는 열차를 마이티마우스가 양팔로 충돌을 막는 장면이 있는데.. 실제 열차의 속도와 무게를 생각한다면.. 정말 불가능 중의 불가능임. 미국 애니 특유의 극도의 과장 연출이 아니고서는 상상도 못 할 일이다. 저건 주제가를 익명의 어린이 제창으로 불렀다.

그리고 (신비한 바다의) 나디아까지만 얘기를 하고 글을 맺겠다. 나디아는 일본 문화 개방도 하기 전에 이례적으로 세계관이 좀 심오하고 스케일이 크고 매니악한 일본 애니가 방영된 경우라고 개인적으로 생각한다. 이거 주제가를 부른 가수는 윤 익희이다.

텔레비전에 UHF와 VHF 채널 다이얼 두 개가 있고, 화면과 소리로 white noise를 볼 수 있던 아날로그 시절, 광고 리스트가 무려 세로쓰기로 뜨던 시절이 갑자기 그리워진 다. ^^ 옛날에는 컴퓨터까지 갈 것도 없이 텔레비전만으로도 정말 최첨단 전자 기술이긴 했겠다.
아아~ 그리고 나도 작곡 스킬 좀!!! ㅜ.ㅜ 이런 음악을 만들어 내는 사람들이 참 대단하고 부럽다. 이미 있는 곡을 편곡만 하는 건 자동차로 치면 그냥 정비나 튜닝에 불과하지만, 작곡은 예전에 없던 새로운 자동차 모델을 개발하는 것과 같은 급일 테니 말이다.

Posted by 사무엘

인간이 자체적으로 무슨 사기적인 기술을 개발한 것을 가리킬 때는 '공밀레'라는 명사와 '약빨다'라는 동사가 쓰인다. 그 반면, 이건 도저히 인간의 기술이 아니라고 여겨질 때는 '외계인(을) 고문(했다)'라는 엄청난 관용구가 있다.

저 고문은 문맥상 顧問(adviser, consultant)이라고 해도 말이 될 것 같지만 사실은 그게 아니라 拷問(torture)을 가리킨다. -_-;;; '문'은 동일하지만 '문'을 하는 방법이 완전히 다르다. 그리고 자기가 약을 빨든 남을 고문하든, 모두 정상적인 방법은 아님이 분명하다.

1. I want you라고 징병 포스터에 얼굴마담으로나 등장하던 엉클 쌤 아저씨가.. 자국의 이익을 위해 외계인을 칠성판(?)에다 묶고 손수 무자비하게 족치고 있다.

2. 우리의 회장님까지도 기업의 미래를 위해 손수 집도하시였다.... 응? 이 정도면 고문이 아니라 그냥 생체실험인데..?? =_=;;

3. 끄응...;; 메모리 반도체의 본좌와 비메모리 반도체의 본좌가 나란히 손잡고 정보를 쪽쪽 빼내고 있다.

인텔과 삼성을 능가하는 웬 반도체 전문가가 무슨 일로 UFO를 타고 이 누추한 지구까지 친히 방문했다가 순순히 납치 당해서 지구인에게 기술을 털려 줄지는 미지수이다. 그리고 이런 일이 벌어졌다가는 지구인의 입장에서는 훗날 외계인으로부터의 보복과 후한이 두렵지 않을까?
그러고 보니 옛날에 영화 <인디펜던스 데이>에서는 지구인이 외계인의 컴퓨터를 해킹까지 한다는 막장 설정까지 있긴 하다.

마지막 동영상의 출처가 뭔지는 다들 아실 것이다. 혹시나 해서 말인데 1947년 여름에 진짜로 외계인 비행접시이건, 미국이 몰래 테스트하던 비행체이건, 아무튼 우리 입장에서는 UFO라 불릴 만한 비행체가 미국 서부 로스웰의 들판에 떨어진 것 자체는 팩트이다. 단지 문제의 외계인 해부 동영상은 음모론 대박을 노린 몇몇 사람들의 주작이다. 하지만 상당한 고퀄이긴 했는지, 한때는 영화 특수효과 전문가와 현직 의사들까지 여러 사람들을 성공적으로 낚았다.

본인이 중고딩 시절에 그 동영상에서 인상적으로 관찰한 건 첫째, 시신의 손발가락이 6개씩이었다는 것이다. 성경에도 유전자가 변이되어 진짜로 울펜슈타인 3D의 뮤턴트처럼 된 거인들이 손발가락이 6개였다고 나오니까 말이다.
그리고 둘째, UFO 잔해로 추정되는 무슨 철도 궤조 모양의 I-beam 표면에 정체를 알 수 없는 이상한 문자/부호들이 써져 있었다는 점이다. 그 중엔 임금 왕(王)자와 동일한 모양의 글자도 있었다.

난 “외계인도 한글 같은 문자를 쓰지는 않는구나” 이런 생각을 먼저 했는데, 삼성이나 인텔 관계자가 외계인을 납치하면 그런 건 관심 없고 진짜로 반도체 기술부터 쪽쪽 빼 갈 것 같다. 로스웰 사건이 벌어졌던 1947년은 이제 막 에니악 컴퓨터가 발명돼서 실전 배치되던 까마득한 옛날이었다. 그리고 저 일이 있은 후 1947년 말~1948년 사이에 트랜지스터가 발명되었다니, 우연치고는 참 기가 막힌다.

무한에 가깝게 너무나 방대 광활한 우주에서 오로지 지구에밖에 생명이 존재하지 않는다는 것은 신앙이 없는 사람이라면 논리적으로 도저히 납득하기 힘든 사항이긴 하겠다.

Posted by 사무엘

<날개셋> 한글 입력기 8.2는 기념비적인 작품이었다. 내부적으로 이것저것 개선 사항이 많았으며, Windows 10 지원에다 후보 변환 프로토콜 관련 작업은 아주 뜻깊은 결실이기 때문이다.

8.2는 한글 조합과 관련된 쪽보다는 키보드 입력을 인식하는 쪽에서 이례적으로 새로운 기능이 많이 추가되었다. 오른쪽 alt/ctrl을 지원하는 것에 대해서 몇 번 건의를 받긴 했지만 지금까지 별 생각을 안 하고 지냈다. 그랬는데 이것을 키보드 드라이버 보정이라는 새로운 기능으로 통합하면 되겠다는 생각이 들자, 결국 예정에 없던 신규 기능으로 들어가게 됐다.
여기에다가 키보드/키패드 구분과 scroll lock 인식 같은 것도 아주 신선한 기능이다.

그 뒤, 8.2의 다음 버전은 8.4로 설정되어 있으며, 이번엔 다시 입력기 내부의 아키텍처를 개편하는 어려운 작업이 한창이다. 내년 2월 말쯤에 내는 것을 목표로 하고 있다.

1. 최종 변환 규칙의 개편

가장 먼저 수술대에 오른 기능은, 지난 3.0 이래로 거의 변화 없이 형태가 동일하게 유지돼 왔던 편집기 계층의 '최종 변환 규칙'이다. 최종 변환 규칙은 수식값을 만족하는 번호에 해당하는 입력 항목에 대해서 아스키 문자의 전/반각을 바꾼다거나 한글 자모를 호환용 자모로 바꾸는 것 같은 간단한 변환을 수행한다.
다음 버전에서는 최종 변환 규칙이 적용되는 조건과 방식이 더 깔끔하게 바뀔 예정이다.

첫째, 수식이 없어진다. A<=2 (첫 세 개의 글자판만), A&1 (짝수 번째 글자판만) 이런 식으로 적용 대상을 지정하는 게 강력하긴 하지만 실제로 쓰이는 경우가 거의 없다고 판단되어서이다. 또한 이런 번호가 붙어 있지 않고 보조 입력 도구가 제공하는 입력 항목에 대해서는 최종 변환 규칙을 적용할지 의문이 생기기도 한다.

그래서 이제는 최종 변환 규칙을 지정하면 모든 입력 항목에 일괄적으로 그 규칙이 적용된다. 수식 같은 거 생각할 필요가 없다. 그 대신, 각각의 입력 항목에서 '기본 입력기' 이상 등급부터는 최종 변환 규칙의 적용을 원하지 않는 경우 옵션을 지정할 수 있다. No라고 옵션이 지정되지 않은 모든 문자 생성기들은 기본적으로 최종 변환 규칙을 적용 받으며, 특히 '빈 입력기'는 그런 옵션도 없기 때문에 규칙이 무조건 적용되게 된다(입력 스키마조차 '빈 스키마'인 경우는 물론 제외. 문자 생성기가 아예 동작하지 않는 상황이므로).

둘째, 조건이 완화된 대신, 적용 범위는 더 좁아진다. 최종 변환 규칙은 (1) '일반 문자' 타입의 날개셋문자, 또는 (2) 한글의 경우 두벌/세벌/종성 두벌식 등등 무엇이건 상관은 없지만 초중종 낱자가 단 하나만 있는 경우에만 한해서 적용된다. '다중 문자' 타입에는 적용되지 않으며, 날개셋문자가 아닌 방식으로 생성된 raw 문자열에도 적용되지 않는다. raw 문자열이란 후보 변환 내지 '고급 입력기'의 '사용자 정의 조합' 같은 걸 말한다.

애초에 반각/전각 변환이나 한글 자모 종류 변환 같은 간단하지만 보편적이고 전역적(global)인 변환만을 의도했던 것이기 때문에 이렇게 범위를 좁히는 게 최종 변환 규칙의 취지를 살리는 데 더 도움이 될 것으로 보인다. 가령, 더 복잡한 형태의 한글을 다른 형태의 문자로 바꾸려면 아예 '고급 입력기'의 '한글 출력 치환'을 사용하면 될 테니 말이다.

이런 이유로 인해 이제는 최종 변환 규칙을 통해 반각을 전각으로 바꾸는 설정을 넣었다 하더라도 '일반 문자' 날개셋문자 외에 다른 방식으로 입력하는 문자/문자열에 대해서는 그런 변환이 일어나지 않는다. 그것들은 언제나 있는 그대로만 입력될 것이다.

2. 오토마타에 T 변수 추가

글쇠배열 수식에서는 잘 알다시피 T라는 변수가 오토마타 상태 번호를 나타낸다. 그런데 이제는 오토마타에도 O에 이어 T라는 변수가 추가되었다. 이것은 한글 조합을 더 계속할 수 없어졌을 때 왜 더 계속할 수 없는지에 대한 추가 정보를 담고 있다.

잘 알다시피 오토마타는 입력된 글쇠의 초중성 정보가 A~C라는 변수에 담겨 있고, 지금 상태에서 무슨 상태로 분기할지를 그 변수 값으로부터 결정하는 수식의 집합이다.
그런데 오토마타상으로는 결합이 계속 가능함에도 불구하고 결합이 가능하지 않은 경우가 크게 두 가지가 있다.

첫째는 말 그대로 낱자 결합 규칙이 더 존재하지 않을 때이다. 가령, ㅋ 다음에 ㅁ을 누른다거나 하면 일단은 답이 없다. 그리고 둘째는 흔한 경우는 아니지만 '허용 한글 제약'에 걸렸을 때이다. KS 완성형 2350자만 조합 가능하게 해 놓은 상태에서 "또" 다음에 받침 ㅁ을 시도한다면 더 진행을 할 수 없다.

이럴 때는 한글 입력기는 A~C에 모두 0을 넣어서 동일 오토마타 수식의 값을 다시 구한다. 이때 수식은 반드시 양수가 아니라 0 이하의 값을 되돌려야 한다. 10여 개의 0 이하 코드값들은 "다음 글자로 자연스럽게 넘어가기", "이 입력을 무시", "무한 낱자 수정" 등 여러 용도로 의미가 예약돼 있다.

A~C 중 적어도 한 성분에 nonzero가 있는 정상적인 상황일 때는 T는 0임이 보장된다. 그러나 오토마타 이외의 사유로 조합을 할 수 없어서 A~C가 0인 상태로 수식이 다시 계산될 때는, T는 1(낱자 결합 불가) 또는 2(허용 한글 제약)가 들어온다.
즉, A|B|C와 T==0은 동치이기 때문에 A~C 낱자 값을 일일이 살펴보기 전에 지금이 정상/비정상 중 어느 상황인지부터 판단하고 싶으면 T 값을 먼저 살펴보면 된다.

T 값을 판단해 보면, '똔' 다음에 '똔ㅁ(받침ㅁ. ㄴ+ㅁ 결합은 없음)으로 가는 것은 허용하지만(0. 다음 글자로) '똠'은 입력되지 않고 ㅁ이 아예 무시되게(-1. 이 입력 무시) 할 수 있다. 두 상황을 구분해서 인식할 수가 있게 되는 것이다. '허용 한글 제약' 기능을 좀 더 창의적으로 활용할 수 있을 것이다.
참고로 진짜로 세 성분 중 단 하나도 nonzero가 없는 빈 한글 날개셋문자는 오토마타에 전달되지 않는다. 새로운 조합을 만들거나 지금 조합을 종료시키지도 않음이 보장된다.

3. 서로 다른 문자의 개수 계산

<날개셋> 편집기에는 블록으로 잡은 텍스트에 대한 간단한 분량 통계를 내는 기능이 도구 메뉴에 존재한다.
줄 수와 UTF16 기준 글자 수는 쉽고 직관적인 통계이고 거기에다 ANSI 인코딩으로(UTF-8도 포함) 변환했을 때의 바이트를 출력해 주는데, 이번에는 텍스트 내부에 존재하는 서로 다른 문자의 수도 추가했다. 즉, "ABCADE"는 글자 수는 6이지만 서로 다른 문자의 수는 5이다.

그래픽 에디터에 이 selection 내부에 존재하는 서로 다른 RGB 색상수가 몇인지 출력하는 기능이 있는 것에 착안하여 저 기능을 구현해 넣었다.
특정 문자 집합으로만 구성되거나 중복되는 문자가 없어야 하는 데이터 테이블을 검증할 때, 혹은 이 문서에 쓰인 서로 다른 한글이나 한자가 총 몇 자인지 궁금할 때 이 기능을 활용하면 된다. 생각보다 요긴할 것이다.
계산 기준은 surrogate까지 감안하여 철저하게 유니코드 코드 포인트이다. 그렇기 때문에 옛한글은 글자 단위가 아니라 낱자 단위로 종류가 계산된다.

4. 정렬 기능의 대소문자 비교 방식 개선

지금으로부터 거의 4년 전에 나온 6.5버전에서는 대소문자 구분이 없이 텍스트를 정렬할 때 문자열을 비교하는 알고리즘을 개선한 바 있다. 동일하게 간주되는 텍스트끼리라도 걔네들 사이에서는 대소문자 기준으로 서열을 둬서 ABCabc가 아니면 AaBbCc가 보장되게 했다. 대소문자 구분을 안 한다고 해서 aABbcC 이렇게 뒤섞이지 않게 했다는 뜻이다.

그런데 그때 작성한 알고리즘에는 좀 문제가 있었다. 그건 같은 문자열들 중에서는 AB Ab ab라고 순서를 딱 보장해 줬지만, AD와 ab를 비교할 때는 여전히 AD를 앞으로 보냈다. 왜냐하면 첫 글자 A와 a 중에서 A가 먼저 처리되기 때문이다.
난 "AB, Ab, ab, AD"를 기대했고 당연히 그렇게 나올 줄 알았는데 실제로 나오는 결과는 "AB, Ab, AD, ab"였다.
왜 이런 문제가 이제야 발견됐는지, 내가 왜 그때 그런 실수를 했는지를 통탄하면서 어쨌든 문제를 고쳤다. 문자열 비교에도 생각보다 교묘한 곳에 복병이 있다.

5. 외부 모듈의 우클릭 메뉴 형태 변경

Windows 8 이래로 외부 모듈은 이제 우클릭 메뉴를 이용해서 입력 항목(입력 모드, 글자판..)을 전환할 일이 많아질 텐데..
입력 항목이 10개보다 적을 때는 입력 항목을 우클릭 메뉴 첫 단계에서 바로 고를 수 있게 했다. 아래 그림에서 왼쪽을 오른쪽으로 바꿨다는 뜻이다. 이렇게 하니까 시각적으로 내지 심리적으로 훨씬 더 좋아 보인다.

'입력 패드'는 키보드 입력도 이제 가능하긴 하지만 그래도 입력 도구가 여전히 더 중요하다 보니, 입력 도구를 우클릭 메뉴의 첫 단계에서 바로 고를 수 있고 글자판은 하위 메뉴에서 고른다.
'외부 모듈'은 반대로 글자판을 첫 단계에서 바로 고르고, 입력 도구는 하위 메뉴에서 고른다. 이런 관계가 딱 정립되었다.

6. 단축글쇠 리스트에서 이동뿐만 아니라 복사도 지원

날개셋 제어판의 설정 중에는 단축글쇠를 관리하는 기능이 편집기 계층에 있고 기본 입력 스키마의 추가 옵션에도 있다. 여기에 등록한 단축글쇠는 딱히 정렬 기준이 있거나 중복 등록 체크를 하지 않으며, 지난 7.7 버전부터는 마우스 드래그로 항목을 이동할 수도 있게 했다. 복수 개의 아이템을 선택해서 끌면 그 아이템들이 한꺼번에 위나 아래로 이동한다.

그에 이어 이번 버전에는 Ctrl+드래그로 복사도 되게 했다.
이미 왼쪽의 입력 항목 트리는 이동과 복사가 모두 지원되고 있었는데 그게 단축글쇠 리스트로까지 범위가 확대된 것이다. 글쇠나 수식이 비슷한 단축글쇠를 여럿 등록할 일이 있을 때 복사를 한 뒤에 다른 부분만 고치는 식으로 편집하면 단축글쇠를 지금보다 더 편리하게 등록할 수 있을 것이다.

이 외에도,
(1) "빈 입력 스키마와 호환되게" 옵션을 지금까지는 '기본 입력 스키마'에서만 지정할 수 있고 '고급 입력 스키마'에는 지정할 수 없었는데, 그 제약이 없어졌다.

(2) 편집기에서 '자동 줄바꿈' 옵션을 끈 상태로 임의의 파일을 열거나, 혹은 스크롤 바가 생기지 않을 정도로 아주 짧은 파일을 연 경우 초기에 문서의 전체 줄 수가 실제 줄 수가 아니라 1로 잠시 잘못 표시되던 버그를 잡았다. 이것 말고도 자체 에디트 컨트롤의 코드를 전반적으로 좀 최적화를 했다.

(3) 지난 7.9 버전부터는 조합 중인 두벌식 한글을 도깨비불 현상이 미리 적용된 형태로 표시하는 옵션이 '고급 입력기'의 '한글 출력 옵션'에 추가되었다. 그래서 일명 '초성 지향 도깨비불'이라는 걸 구현 가능해졌는데, 문제는 "가ㅁ" 상태일 때는 '감'에 해당하는 한자 변환을 할 수 없었다. 지금까지는 그게 가능하지 않다가 이제 다음 버전부터는 글자 단위와 단어 단위로 모두 한자 변환이 가능해졌다.
저 상황에서 예외를 둬서 저것만 가능하게 하는 것은 어렵지 않지만, 더 탄탄한 이론적 근간을 마련해서 문제를 완전히 해결하는 게 쉽지 않아서 지금까지 문제 해결을 보류하고 있었다.

(4) 고급 입력기의 사용자 정의 조합을 이용하여 비한글 외국어 문자를 입력하는 예제로 지금까지 제공된 건 히라가나/가타카나라는 일본어 자료가 거의 유일했는데, 이번에는 일명 'Qwerty Extension'이라는 걸 추가했다.

일본어 자료는 조합 로직 자체가 유의미한 반면, 얘는 후보 데이터들이 본좌이다. 알파벳, 숫자, 기호 등 거의 모든 문자가 곧장 입력되는 게 아니라 조합 형태로 입력되며, a를 조합하는 상태에서 한자 키를 누르면 a에 그야말로 상상할 수 있는 온갖 액센트/변형 부호가 붙은 것들을 선택할 수 있다. -에 대해서는 N-dash, M-dash, 하이픈 등 온갖 바리에이션이 들어있는 식이다.
생각보다 무척 유용하며 예제 입력 데이터로서의 의미도 큰데, 왜 지금까지 이런 게 없었는지 궁금하다. 정 재민 님께서 제공해 주셨다. 설명문 때문에 파일이 생각보다 덩치가 크다.

Posted by 사무엘

1. 목적어 없는 타동사

킹 제임스 성경에는 의미상 분명히 타동사인데 목적어가 없이 동사 하나만 달랑 나오는 경우가 종종 있다. 옛날 영어에는 그런 문법이 원래 가능했나 보다.
사실, KJV에는 원어로는 뭔가 자비심 없는 짧은 단어 배치가 가능할지 모르나 영어로는 문법적으로 가능하지 않아서 이탤릭체로 단어를 집어넣은 게 있다. 하지만 그 영어를 우리말로 번역하려다 보면 한국어로도 이탤릭체 단어가 또 첨가되어야 하기도 한다.

(1) SLAY
Bring these men home, and slay, and make ready; (창 43:16)

이집트의 총리가 된 요셉이 요셉의 형들을 대접하는 장면이다. 저 slay는 당연히 사람(these men)을 죽이는 게 아니라 식용 가축을 도축하여 고기를 대접한다는 뜻이다.
한국어 성경 번역은 모두 ‘짐승을’이 추가되어 있고, 영어 역시 KJV를 제외한 성경들은 an animal 또는 animals라고 목적어가 추가되었다.

(2) MOCK
And Sarah saw the son of Hagar the Egyptian, which she had born unto Abraham, mocking. (창 21:9)

하갈이 낳은 아들이 ‘이삭’을 조롱하는 것을 사라가 봤다는 장면인데, 정작 영어 성경 구절을 보면 mock에 이삭이라는 단어가 없고 심지어 대명사조차도 없다. 이것은 KJV 영어만의 용법은 아닌지, 영어 성경도 굉장히 많이 의역된 역본에만 Isaac이 들어 있으며, 대명사가 빠진 역본이 KJV 말고도 더러 있다.

참고로, 문장 전체의 목적어가 또 분사구문으로 행동을 취하는 다른 대표적인 예는 스데반의 순교 직전을 묘사하는 행 7:59이다. calling upon God의 주체는 they가 아니라 스데반이다. 하나님께 부르짖었는데 “주 예수님”이라고 말하는 걸 보니 예수님이 곧 하나님이라는 것이 자연스럽게 입증된다만, KJV 이외의 성경 역본에서는 God이 없다. 이것은 KJV도 call의 목적으로 God을 향상 계시 차원에서 이탤릭체로 넣은 부분이다.

And they stoned Stephen, calling upon God, and saying, Lord Jesus, receive my spirit. (행 7:59)

(3) SEND
And Abimelech king of Gerar sent, and took Sarah. (창 20:2)
성경에는 목적어 없이 send가 ‘사람(심부름꾼)을 보내다’라는 뜻으로 엄청 자주 쓰인다. 영어 성경 중에는 a man / a messenger를 첨가한 것과 그렇지 않은 역본이 반반씩 있는 듯.
흥미로운 것은, 옛날 개역성경은 이 단어를 목적어 없이 직역하여 우리말로도 ‘왕이 보내어’라고 번역했다는 점이다. 개역개정판부터는 ‘왕이 사람을 보내어’라고 바뀌었다.

2. 죽음을 뜻하는 단어

성경은 영적 세계, 사후 세계, 구원을 다루는 책인 만큼, 죽음/죽임을 뜻하는 단어가 여럿 존재한다. 사전적인 차원에서의 동의어도 있지만, 비유적인 표현도 많다.
'죽임 당하신 어린양'이라고 할 때 killed를 안 쓰고 slain이라는 생소한 단어를 쓴다는 걸 알게 된 게 중학교를 졸업할 무렵이었다. 마치 <토끼와 거북>이 rabbit and turtle이 아니라 hare and tortoise라는 것, 뱀이 snake 대신 serpent인 것, 돼지가 pig/hog 대신 swine인 것만큼이나 생소했다.

하나님이 성경을 어떤 동작에다 비유를 하셨는지 성경의 다음 용례들을 살펴보자. 이건 교회에서 설교나 성경 공부 소재로 삼아도 될 거라고 개인적으로 생각한다.

(1) DEPART 떠나다
그녀의 혼이 떠나려할 때에 (이는 그녀가 죽었기 때문이더라.) ... (창 35:18, 라헬)
... 주의 종이 평안히 떠나도록 허락하소서 (눅 2:19, 예루살렘의 시므온)
... 나의 떠날 때가 가까이 이르렀도다. (딤후 4:6, 바울)

(2) SLEEP 잠들다
... 이 말을 하고 그가 잠드니라. (행 7:60, 스데반)
자기 조상들과 함께 잠들고 (왕상, 왕하, 대하.. 숱하게 등장)
무덤들이 열리니 잠든 성도들의 많은 몸이 일어나 (마 27:52)
... 우리 친구 나사로가 잠자는도다. 그러나 내가 그를 잠에서 깨우러 가노라 ... (요 11:11)
그러니 고전 11:30도 단순히 자는 사람이 아니라 죽은 사람이라는 것을 쉽게 유추할 수 있다. 고전 15:51, 살전 4:13-14 같은 건 두 말할 나위도 없고!

(3) GIVE UP THE GHOST 숨지다, 숨을 거두다
창세기(아브라함, 이스마엘, 이삭, 야곱), 사복음서(예수님), 사도행전(아나니야와 삽비라, 헤롯)
특히 사복음서에서 예수님의 십자가 죽으심에 대해서는 한결같이 오로지 이 표현만 사용했다는 것이 매우 인상적이다(마 27:50, 막 15:37, 눅 23:46, 요 19:30). die라고 하지 않았다.

(4) DIE 죽다 더 이상의 자세한 설명은 생략한다.

(5) DECEASE die/death와는 달리 동사형과 명사형이 동일하다. 성경에 딱 4번만 등장하는데..
사 26:14와 마 22:25에서는 die와 거의 동일한 의미로 병렬되고, 눅 9:31에서는 예수님의 죽으심을 가리킬 때 쓰였다.
벧후 1:15는 우리말 성경들이 웬일인지 순교를 '내가 떠나간 후에도' departure이라고 좀 의역하는 경향이 있다.

Posted by 사무엘

1.
비행기에는 잘 알다시피 이제 이륙을 중단할 수 없고 중간에 이상이 생겼더라도 일단은 반드시 떠야 하는 V1 속도라는 게 있는데..
비슷한 개념이 자동차에도 좀 있으면 좋겠다는 생각이 든다.

이 정도로 속도가 붙은 채로 교차로와도 충분히 가까워져 버렸으니, 이제는 중간에 신호등이 노란불로 바뀌더라도 서면 안 되고, 급제동이 아니라 그냥 가속을 해서 교차로를 통과해야 한다는 결정을 내리는 속도 말이다. 이런 걸 내비가 안내해 준다면 어떨까.;;

자동차가 존재하고 각 자동차의 상태를 일일이 다 감안하는 지능형 신호 시스템이라도 도입되지 않는 한, 이놈의 노란불 딜레마는 마치 기독교계에서 믿음과 행위, 자유 의지와 예정, 육신과 성령만큼이나 잡음이 끊이지 않는 어려운 문제로 남을 듯하다.
아니면 그냥 자동차 신호등도 남은 시간 카운트다운을 좀 표시해 주면 안 되나..?? -_-;; 부작용이 더 크려나?

2.

• 자전거로 자동차 도로를 역주행하는 것
• 자동차 전용 도로에서 차가 1차로를 정속으로 계속 주행하는 것
• 여러 자동차들이 좌우나 전후로 등속· 동일 간격을 유지하면서 주행하는 것 (일명 떼빙)
  

음주운전, 과속, 신호위반 따위에 비해서 사람들의 인식이 무척 더디긴 하지만, 위의 사항들은 모두 불법이다. 마음만 먹으면 단속에 걸려서 과태료 딱지 먹어도 할 말 없는 사항이다.

하지만 FM대로 밀어붙이기가 좀 어려운 구석도 있다. 먼저 자전거 얘기. 자전거는 근본적으로 경로 자체가 인도와 차도 사이에 끼여 무척 애매한 위치에 있다. 오토바이도 아니고 겨우 자전거가 인도도 제대로 못 다니고 게다가 한 길에서 상행과 하행을 못 다니니 왕복을 위해 반드시 중앙선 횡단을 해야 하는 건 좀..;; 비현실적이다.

다만, 차도에서 그것도 차가 옆에서 튀어나올 수 있는 교차로 주변에서 자전거가 역주행을 하는 건 몹시 위험해 보이는 짓이니 자제해야겠다. 제아무리 제일 바깥쪽 차선으로 조심스럽게 다닌다고 하더라도 하지 말아야 한다.

다음으로 주행/추월 차선 얘기다. 도로 정체 상황이 아니라면 중앙선에서 제일 가까운 차선은 추월용으로 언제나 비워 둬야 하며, 딴 차를 추월했으면 자기 자신도 다시 오른쪽으로 2차로 이상으로 되돌아와야 한다. 외국에서는 "1차로는 화장실 이용하듯이"(이용한 뒤 곧장 나와라)라는 의식이 딱 박혀 있다. 느린 차들이 모든 차선들을 점유하고 있으면 뒷차 운전자의 심정은 짜증 그 자체일 것이다.

끝으로 줄지어 다니는 떼빙이다. 이건 과속이나 신호 위반이 아니고, 요리조리 차선을 바꾸는 난폭운전은 아니나, 다른 방향으로 난폭 운전이 될 가능성이 농후하여 금지되는 행위이다. 돌발 상황이 많은 도로에서 차량 간격을 아슬아슬 일정하게 유지하면서 다른 차가 사이에 끼어들지 않게 하는 건 몹시 어렵고 위험한 일이기 때문이다. 앞의 차가 급정거하게 됐을 때 연쇄 추돌 사고가 날 우려도 있고 말이다. 여러 차량들이 길을 아는 선두차를 따라서 동일 목적지로 갈 때 떼빙을 하기 쉬운데, 요즘 세상엔 내비를 켜서 각자 알아서 찾아가는 게 낫다.

떼빙이나 추월 차선 위반 차량을 적발하려면 건 속도· 신호 위반 단속처럼 특정 지점을 체크하는 게 아니라 구간을 꾸준히 감시해야 하니 현실적으로 난감하며, 무인 기계가 하기는 더욱 힘들 것 같다. 하다못해 구간식 속도 위반 단속도 그냥 시작점과 끝점에서 동일 차량의 통과 시각만 비교하면 되는 반면, 차로 위반은 그런 부류가 아니니까 말이다.

3.
버스 운전사가 운전을 하는 걸 옆에서 지켜보고 있으면, 정지 상태에서 출발할 때 변속기 스틱을 전방이 아니라 꼭 뒤로 밀더라. 뒤는 짝수단이나 후진이 있는 쪽이다. 버스나 트럭 같은 디젤 차량은 정말로 1단이 아니라 2단에서 출발을 한다는 걸 알 수 있었다. 1단은 정지 상태에서 오르막을 오를 때에나 필요한 듯.
게다가 내가 최근에 확인을 했을 때는 승객이 더 탈 수 없을 정도로 버스가 초만원이고 그만큼 무거운 상태였다. 그런데도 버스는 아무 탈 없이 2단에서 아주 부드럽게 잘만 출발을 했다. 힘이 딸린다는 느낌이 들지 않았다.

그런데 내 경험상, 어떤 버스에 따라서는 금방이라도 시동이 꺼질 정도로 부르르 떨리면서 출발하기도 했다. 그건 기사 아저씨가 클러치 조작을 잘못했거나 아예 3단 출발을 시도하기라도 해서 그런 건지 궁금해진다.

또한, 버스는 정지해서 문이 열리기 직전에 '쉬익~ 치익' 공기 빠지는 소리가 나는데.. 그건 운전석을 관찰해 보니 주차 브레이크 같은 걸 조작하는 소리 같다. 아무래도 승용차와는 구조가 다른 듯.
주차 브레이크를 거는 걸 깜빡하고 운전사가 차에서 내렸다가 버스가 슬금슬금 앞뒤로 미끄러지기 시작해서 대형 사고가 나는 동영상을 몇 번 봤었다. 디젤 엔진에 무거운 대형차일수록 1/2 mv^2에서 v가 커지면 피해는 걷잡을 수 없게 되고, 또 엔진 브레이크의 효력이 약하고 주 브레이크가 무리를 받기도 쉽댄다. 제동 장치를 빡세게 잘 만들고 적절히 활용하는 게 필수이다.

4.
지난 여름에 휴가차 양평으로 가던 길에 국도변의 모 휴게소 주변에서 뜻밖에 득템한 사진이다.
포니도, SMC 덤프트럭도 아니고.. 무려 "제무시" 트럭의 실물을.. 그것도 굴러가는 모습을 조우하게 됐다.
곧바로 사진을 찍었다. 딱 보면 알겠지만, 자동차계의 생생한 노인학대 현장이라고 생각하면 된다.

이건 미국 GMC에서 제작한 군용 2.5톤 트럭이 민간에 풀려 나온 것이다.
그리고 GMC를 일본식으로 변형해서 발음하면 '지 에무 씨' → '제무시'가 된다. ㄲㄲㄲ
앞바퀴 휀다의 모양으로 보건대 M602 / M35 / K511 계열이다. 한 196, 70년대에 생산되었던 물건.
군필자 분들은 '육공 트럭'이라고 부르더라.

그런데 진짜로 낡은 원조는 6·25 내지 2차 세계 대전 시절에 생산된 놈도 있다고 한다.
군용차다운 압도적인 무게와 엔진 출력 덕분에 강원도 산길을 오르면서 통나무들을 실어 나르는 실력은 이놈 만한 게 없다고 함.
다만 기름 먹는 하마인 건 각오해야 할 것이고, 심지어 미국 차 아니랄까봐 이런 트럭이 디젤도 아니고 휘발유 엔진 모델도 있다고 한다.

5.
초가삼간도, 산 정상도, 그리고 도로가 극심하게 막힐 때 신호 대기 중의 운전석도 훌륭한 코딩과 작문 공간이다.
너무 맑고 밝은 낮에는 명암차 때문에 바깥 경치와 모니터 화면이 카메라에 동시에 담기지 않는 반면, 흐린 날엔 그게 가능하더라.

자동차는 당연한 말이지만 엔진의 경제 속도로 고단 고속으로, 그리고 최대한 관성을 활용해서 나아가고 있어야 연비가 극대화된다. 그 반면, 길이 막혀서 나아가질 못하면 길에서 아까운 기름을 흘리면서 시간은 시간대로, 돈은 돈대로.. 자동차의 가성비는 극악으로 곤두박질친다.
컴퓨터로 치면 메모리가 부족해서 가상 메모리 페이지 파일 교체만 하느라 다른 일을 못 하고 성능이 그냥 곤두박질치는 것에다 비유가 가능하다.

이런 이유 때문에 본인은 도로 정체를 매우 싫어한다. 시내 도로보다 2~3배 가까이 우회해서 가더라도 신호 안 받고 연속 주행이 가능한 자동차 전용 도로가 자동차에게는 이익이고 결과적으로 그게 돈과 시간을 아끼는 경우가 많았다. 자동차 전용 도로마저도 답이 없으면.. 그냥 차 안 가져가고 만다.
그나마 신호 대기 시간에 다른 작업이라도 해서 내 개인 시간이라도 좀 아껴야 할 필요를 느낀다.

6.
속담과 성경 구절 몇 개를 자동차를 배경으로 좀 각색해 보면...
"일찍 나는 새가 벌레를 잡는다"보다 운전자에게 훨씬 더 절실히 와 닿는 속담은 "일찍 도착한 차가 주차 자리를 차지한다"이다.
"마귀에게 틈을 주지 말라"(엡 4:27)보다 운전자에게 훨씬 더 절실히 와 닿는 말씀은 "옆차에게 (끼어들) 틈을 주지 말라"이다.

Posted by 사무엘

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

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