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

2015/11/30 08:24 2015/11/30 08:24
, ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1165

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

2015/11/28 08:31 2015/11/28 08:31
,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1164

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/11/25 08:36 2015/11/25 08:36
, ,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1163

배틀넷 아시아 서버에 들어가 보면 무려 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 사무엘

2015/11/22 08:31 2015/11/22 08:31
,
Response
No Trackback , 4 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1162

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

2015/11/16 08:36 2015/11/16 08:36
, ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1160

컴퓨터에는 자체적으로 달력과 시계 기능이 포함되어 있으며, 운영체제에는 그걸 설정하는 기능이 있다.
대략 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/11/13 19:34 2015/11/13 19:34
,
Response
No Trackback , 5 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1159

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

날짜 문자열은 마치 프로그래밍 언어 문법처럼 형식이 있으며, 문법과 의미 차원에서 정오(맞고 틀림)가 존재한다. 가령, 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 사무엘

2015/11/11 08:33 2015/11/11 08:33
,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1158

간극은 있다 (the Gap Fact)

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

원서의 저자는 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 사무엘

2015/11/05 08:25 2015/11/05 08:25
, , , ,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1156

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

2015/11/02 08:33 2015/11/02 08:33
, ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1155


블로그 이미지

그런즉 이제 애호박, 단호박, 늙은호박 이 셋은 항상 있으나, 그 중에 제일은 늙은호박이니라.

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2015/11   »
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30          

Site Stats

Total hits:
3936418
Today:
834
Yesterday:
4175