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

본인은 사진, 촬영, 영상 관련 기술의 발달사에 대해 관심이 많다. 깊게 잘 알지는 못하고 그냥 관심뿐이지만, 그래도 흑백 사진이 컬러로 바뀌고 영사기가 발명되고, 따로 변사가 붙을 정도이던 무성 영화가 컬러+소리가 가미된 진짜 영화로 바뀌어 간 과정이 흥미진진하지 않은가? 그래서 예전에 사진술에 대해서 글을 올린 적이 있기도 하다.

옛날에 카메라가 처음 발명되었을 때는 알다시피 자기 생얼 사진이 찍히는 것만으로도 자기 혼이 빠져나간다고 생각하고 사람들이 질겁을 했다.
그런데 하물며...
아담 이래로 인류 역사상 최초로, 멀쩡히 살아 있는 사람의 뼈가 사진으로 찍혀 나온 걸 목격한 당사자는 얼마나 기절초풍했을까?

X선, 일명 뢴트겐선이라는 것을 발견한 사람은 잘 알다시피 독일의 물리학자 뢴트겐이다.
그리고 위의 사진은 1895년, 뢴트겐이 자기 아내의 손을 찍은 사진이다. 정말 아내의 손이 맞음을 확인하기 위해 반지까지 낀 채로 사진을 찍었다.
뢴트겐 당사자조차 최초의 방사선 촬영을 도저히 믿을 수 없어서 혹시 자기가 환각, 헛것을 본 건 아닌지 엄청 의심하면서 번뇌와 고민을 거듭했다고 한다.

그는 나중에 노벨 물리학상의 초대 수상자가 되었다(1901년).
이건 충분히 노벨 상 감인 업적이다. 해부를 하지 않고 신체의 내장과 뼈를 들여다보는 게 가능해졌으니 이는 의학계에 가히 혁신을 가져다 준 획기적인 발견이 아닐 수 없었다.

이것 덕분에 의학에 방사선과 내지 영상의학이라는 분야가 새로 생기게 됐다. 흉부 X선 촬영은 기초 건강 검진을 받을 때 아무 생각 없이 같이 받는 저렴한 검사 중 하나가 됐다. 놀라운 과학의 힘이다.
내과 치료 때는 아예 내시경을 집어넣어서 사진을 찍겠지만, 뼈가 부러졌는지 인대가 나갔는지 등을 판별하는 외과 치료 용도로는 X선이 가히 구세주가 아닌가 싶다.

그리고 이와 비슷한 맥락으로 짐을 일일이 열어 보지 않고도 내부를 들여다볼 수 있는 금속 탐지기 역시 세상의 보안과 인권을 크게 향상시켜 줬다.
단, 이게 20세기 초반부터 아주 일찍 상용화가 됐다면 일제 강점기 때 항일 독립운동가가 폭탄이나 총을 몰래 반입해서 의거를 일으키기도 훨씬 더 어려워졌지 싶다. X선 사진은커녕 생얼 사진조차 흔치 않은지라, 죽이고자 하는 일제 고위 관리의 얼굴도 알기 어려울 정도로 옛날이었으니 가능했던 일이다.

끝으로, 의학에 대한 원론적인 얘기를 하며 글을 맺겠다.
얼마 전엔 한의사에게도 X선 촬영을 허용하겠다는 말이 나와서 논란이 많았다.
현직 의료인들은 한의사 내지 한의학 쪽을 내가 막연히 생각하는 것보다 훨씬 더 싫어한다는 걸 알 수 있었다.

본인도 큰 줄기에서는 서양 의학을 지지한다. 어설픈 친환경 대체의학, 백신 음모론, 안전한 예방접종 그런 거 미는 진영을 별로 좋아하지 않는다. 그 사람들은 근대화 공업화 이전의 자연 환경과 위생 복지에 대해 너무 미화하고 지나치게 낙관하고 있다.

영아 사망률이 지금보다 넘사벽으로 높았고 어렸을 때 천연두 앓다가 목숨만 건진 곰보를 심심찮게 볼 수 있었으며, 죽은 형의 이름을 동생이 물려 쓰던 시절을 벌써 잊으셨는가? 그때로부터 시간이 뭐 얼마나 지났다고?
수돗물을 화학 약품으로 소독하고 너도 나도 백신을 맞은 덕분에 어렵게 퇴치한 전염병을 "이건 백신 없이도 어차피 자연스럽게 사라졌을 질병일 뿐이다" 이런 식으로 밀어붙이는 무식한 주장에는 할 말을 잃을 지경이다.

과학적 방법론으로 우주와 생명의 근원이 무엇인지, 사람이 죽으면 어디로 가는지 같은 걸 증명할 수는 없다. 그건 재연 가능하지 않으며 과학의 영역에 있지 않다.
그러나 지금 당장 살아 있는 사람을 대상으로 임상실험이 가능한 의학에 관한 한은, 투명하고 객관적인 과학적 방법론에 입각한 서양 의학이 지금까지 수많은 사람들의 생명을 구했으며, 온갖 사이비 돌팔이와 건강 관련 미신들로부터 사람들을 바르게 깨우쳐 줬다고 본인은 굳게 믿는다.

심지어 성경에도 이 주제와 관련된 진술이 있다.

• 아사의 통치 제삼십구년에 그의 발에 병이 생겨 마침내 그의 병이 심히 중하게 되었으나 병이 있을 때에 그가 {주}께 구하지 아니하고 의사들에게 구하였더라. (대하 16:12. 의사를 찾은 걸 부정적으로 얘기함)
• 더 이상 물만 마시지 말고 네 위장과 자주 있는 병을 위하여 포도즙을 조금 쓰라. (딤전 5:23. 인위적인 의학 처방을 긍정적으로 얘기함)

성경에 왜 이 두 구절이 동시에 존재하며 둘이 무슨 문맥에서 무엇을 말하는지를 바르게 분간할 줄 안다면, 질병 내지 치유와 관련된 온갖 교리적 오류에 빠질 일이 없을 것이다. 성경에서 그 많은 기적을 행한 엘리사도 나중에 병에 걸려 죽었다.

예수 믿는다고 해서 기도만 열심히 하면 공부 안 해도 학교 시험을 100점 맞을 수 있는 게 아니다. 병에 걸리기만 하면 다 마귀 탓이고 기도만 하면 다 낫는다는 식의 생각은 매우 잘못됐다.
위의 구절들도, 지금 병에 걸린 상황과 하나님에 대해서 어떤 생각을 했는지 자세와 믿음이 문제이지, 병원에 가느냐 안 가느냐가 본질적인 문제는 아닐 것이다.

Posted by 사무엘

지난 2월 설 연휴 기간에 본인은 가족 전체가 동남아로 가족 여행을 떠났다. 여행사를 통한 패키지 관광이다.
부모님이 퇴직하셨고 본인을 포함한 자녀들은 아직 미혼이니, 지금 같은 시기가 온 가족이 같이 여행을 떠나기에 적절하다고 여겨졌기 때문이다. 내가 마지막으로 외국 가는 비행기를 탄 지도 무려 6년이 돼 가고..
더 늦기 전에 여행기를 이제야 간단히 정리해서 올린다.

가족이 한꺼번에 움직인 덕분에, 지금까지 공항 철도나 리무진 버스로만 가던 인천 공항에 난생 처음으로 자가용을 끌고 가 봤다. 운전은 언제나 본인이 도맡아 했고. 시기가 시기이다 보니 공항의 장기 주차장엔 벌써부터 차들로 포화 직전이었는데, 가까스로 빈 자리를 하나 발견해서 차를 세웠다.

그렇게 기대를 품고 공항에 도착했으나, 베트남 항공 소속의 여객기가 정비 상태를 이유로 거의 10시간이 넘게 지연됐다. 관광 일정에 차질이 생기긴 했지만 어차피 이건 크리티컬한 업무를 목적으로 나가는 게 아니고 인천 공항은 안 그래도 내부 시설이 굉장히 좋은 공항이니, 출국 도장을 찍은 상태로 탑승동에서 이렇게 오래 지내고 있는 것도 나름 색다른 경험이었다.

항공사 측에서는 처음엔 기다리는 동안 밥이나 먹으라고 식권 정도를 내 줬으나, 지연이 길어지자 결국은 사람들을 버스에 태우고 도로 여객 터미널 입국장으로 보내서 출국 심사를 취소시키고 인근의 호텔에다 승객들을 보내 줬다. 저녁 식사까지 무료로 제공해 주고..;; 비행기 하나가 지연되는 바람에 승객들도 불편했지만 항공사 역시 손해를 굉장히 많이 봤지 싶다.

덕분에 현지 호텔을 구경하기 전에 운서동 공항 신도시 일대의 호텔부터 먼저 구경하게 됐다. 주변에 아파트 말고 전원 주택들은 전망이 참 좋아 보였다. 뭐, 본인이야 노트북 PC가 있으니 기다리는 동안 프로그램도 짜고 글도 쓰면서 시간을 허투루 보내지 않았다.

어쨌든, 이런 우여곡절 끝에 밤 비행기를 타고 먼저 베트남 북부의 하노이 공항에 도착했다. '하노이의 탑'의 원조 국가에 왔다니 감회가 새로웠다.
여기는 역사적으로 나름 프랑스를 이기고 미국까지 이긴 나라라고 자존심이 쩐다고 한다. 그리고 호치민을 정말 미치도록 숭상한다고.

베트남에서는 해안으로 건너가서 배를 타고 우리나라 제주도나 남해를 뺨치는 다도해와 동굴을 구경하고 맛있는 해물 요리를 먹었다.

그리고 호치민 광장을 구경했다. 호치민 자체는 나름 인품을 갖춘 좋은 지도자였다고는 하지만, 그래도 여기는 어쩔 수 없는 사회/공산주의 국가이더라. 구소련이 망한 지가 언젠데 낫과 망치 깃발 실물을 볼 수가 있었다.

그 뒤 약 1시간 반 동안 1000km남짓을 비행하여 캄보디아의 씨엠 립 공항에 도착했다.
이 공항으로 말할 것 같으면 비행기에서 내린 뒤, 브리지나 셔틀버스가 없이 승객들이 활주로를 직접 걸어서 여객 터미널로 들어가야 하는 공항이다. 철도역으로 치면 선로를 그대로 횡단해야 하는 시골 간이역 정도?

날씨는 베트남보다 더욱 더워져서 견디기 힘들었다. "여기가 위도가 몇 도이고 자전축이 몇 도 기울어져 있지? 서울과 비교했을 때 햇볕을 받는 각도의 cos 값이 얼마나 차이가 나지?" 같은 별 잡생각이 다 들 지경이었다.
여기는 입국 관리 공무원에게 공식적인 비자 발급 비용 외에도 대놓고 1$씩 뇌물을 줘야만 심사대를 빠져나갈 수 있었다. =_=;;

날씨도 더운데 앙코르 와트는 정말 핵심만 초스피드로 보고 돌아왔다. 요게 제일 먼저 만들어진 사원이고, 그야말로 캄보디아의 국기에도 그려져 있을 정도로 상징적인 유적이다. 캄보디아를 먹여 살리는 제1순위 관광 자원인데.. 이것도 처음 발견되었을 때와는 달리 굉장히 많이 파괴된 거라고 하니 참 안습하다.
서양 사람들은 처음엔 이걸 미개한(?) 동남아시아 사람이 만들었을 거라고 믿지 않았을 정도였다고 한다. 하지만 그렇다고 로마인의 후손이 만들었다고 우기기엔 표현되어 있는 종교관이 전혀 서양스럽지가 않은걸? -_-

나무 뿌리와 뒤엉킨 이 유적지는 아까 것보다는 더 나중에 만들어졌다. 앙코르 제국도 여러 시즌이 있기 때문에..;;

앙코르 와트 유적지는 굉장히 넓기 때문에 중간 중간엔 툭툭이를 타고 이동했다.

이런 유적지들이 처음에 만들어졌을 때는 얼마나 더 화려하고 웅장했을까 하는 생각이 든다.

관광 도시인 씨엠 립은 6번 국도던가 외국인 관광객들이 주로 다니는 큰길만 벗어나면 곧장 그냥 황무지 깡촌이었다. 카누를 타고 돌아다니면서 서민들이 사는 수상 주택 단지를 구경하기도 했다. 이런 단지가 조성된 것에도 다 사연이 있다고 함.

물은 별로 깊지는 않지만 정말 처참하게 더럽기 때문에 저 물이 몸이나 옷에 묻는 일은 만들지 않는 게 좋다. 저런 데서 사람이 어떻게 1년 365일을 살 수 있나, 생계는 어떻게 꾸리며 위생 문제와 먹고 입는 문제는 어떻게 해결하는지 궁금했다.

그리고 캄보디아라 하면 잊을 수 없는 건 일명 '폴 포트'라는 미치광이가 벌였던 킬링필드 학살극이다. 희생자의 유골을 안치해 놓은 어느 납골당을 방문하고 거기 적혀 있는 옛날 사진과 안내문을 보기도 했다.

어떤 나라가 힘이 없어서 남의 나라의 식민지가 되고 나중에 독립조차도 자기 힘으로 스스로 쟁취한 게 아니라면, 결국은 한 외세가 물러난 뒤에도 다른 외세들의 이념 각축장이 되고 파란만장 기구한 역사가 이어지는 건 남의 일만이 아닌 것 같다. 특히나 그런 와중에 공산주의는 단순히 억압받고 착취당하는 농민· 노동자(?)뿐만이 아니라 먹물깨나 먹은 지식인도 잘 현혹시키는 것으로 보인다.

그런데 결국 실현 불가능한 사상을 강제로 실현하려다 보니 인민들을 온통 바보 노예로 만들어야 하고 딴 생각 잡 생각을 못 하게 극도의 폭력과 공포로 통치를 해야 하고 종교도 말살하고 서로 감시와 밀고를 하게 만들어야 한다.
지도자의 우상화와 절대독재는 기본 중의 기본이다. 김 일성이고 호치민이고간에 자기 우상화를 하지 말라고 유언을 했어도 유언이 당연한 듯이 씹히는 이유는.. 그렇게 우상화를 해야만 공산주의 체제가 돌아갈 수 있기 때문이다.

공산주의가 매우 악한 사상인 이유는 "능력껏 벌어서 필요한 만큼/혹은 1/n만치 분배한다"라는 성선설을 제시해 놓고는 정작 그걸 실현하고 운영하는 방법은 철저하게 성악설에 기반을 두기 때문이다. 정직하게 필요악이라고 선을 긋는 것도 아니고, 애초에 성선설 따위는 없다. 인간의 본성에 대해서 성경적으로 고찰을 한 사람이라면 반공주의자가 될 수밖에 없으며 반공 때문에 불가피하게 벌어졌던 필요악이나 부조리를 보는 눈이 한결 관대해진다.

이런 것들을 보고 느꼈다.
귀국하고 나니 공항의 주차난은 더욱 심해져서 이중주차에, 도로변 주차까지 상태가 말이 아니었다. 다른 가족들이 수하물을 찾는 동안 본인은 먼저 밖으로 나가서 차를 여객 터미널로 가져왔다. 여객 터미널에서 장기 주차장까지는 수백 m 이상 떨어져 있으니까. 차는 깜빡 잊고 블랙박스를 켜 놓은 채로 추위 속에서 닷새 가까이 방치됐지만, 다행히 시동이 잘 걸렸다.

동일한 고속도로 구간에서 불과 1주일쯤 전에 짙은 안개 때문에 106중 추돌 사고가 발생했었지만, 지금은 안개고 뭐고 없이 도로는 한산하기 그지없었다. 이렇게 여행을 잘 마치고 돌아왔다.

Posted by 사무엘

우리나라의 기독교 역사에서 성경 번역만큼이나 중요한 부분을 차지하는 것은 찬송가의 번역과 편찬이다.
그리고 한국 교회에서 쓰였던 찬송가 중에 역사적으로 꽤 중요한 물건으로는 <신증 복음가>가 있다.

지금은 장로교가 세력이 크지만 한국 땅에 기독교가 처음 전래되었을 때는 감리교가 대세였다. 그리고 감리교에서 좀 더 심화와 로컬라이징(?)을 거친 교파가 바로 성결교인데..
<신증 복음가>는 성결교 선교사가 세운 "동방 선교회"라는 단체에서 출간하였다. 시기는 1919년 4월, 한반도에서 3·1 운동이 벌어지던 때와 아주 비슷하다.

이 신증 복음가에서 처음으로 소개되어서 지금까지 교회에서 불리고 있는 찬송가들이 적지 않다. 그리고 거기에는 인제 와서 뭔가 출처를 추적할 수가 없는 짬뽕(?) 번역도 꽤 있다. 이 글에서는 몇 가지 예를 들도록 하겠다.

1. 그 참혹한 십자가에 주 달려 흘린 피

난 지금까지 확 꽂혀서 좋아하게 된 찬송가들이 대부분 구원 카테고리 쪽에 있었다. Wonderful grace of Jesus, 그리고 And can it be that I should gain까지. 그 뒤 최근에 주목하고 있는 곡은 바로 저것이다.
올해는 삼일절이 일요일과 겹치는데, 이런 날엔 신증 복음가 출신 찬송가를 부르는 게 아주 어울린다고 생각되어 본인은 거의 한 달 쯤 전부터 이 날 준비 찬송으로는 이걸 넣으려고 벼르고 있었다.

앞부분 멜로디는 <찬양하라 내 영혼아>에서 "내 속에 있는 것들아"와 닮았다. 계속 듣고 있으면.. 정말 애절하고 화사하고 우리를 죄에서 구원하는 예수님의 피에 대한 한없는 신뢰와 감격이 솟아나는 것 같다. 그래서 후렴에서는 "나 믿노라..!"가 나온다.

그런데 이 곡은 작사· 작곡자가 미상이다. 1919년 당시의 가사는 지금 가사와는 차이가 많았다.
다만, 가사가 There is a fountain filled with blood(샘물과 같은 보혈은 임마누엘 피로다)에서 모티브를 약간 딴 거라는 말은 있다.
1절에 '샘물'이라는 단어가 있고(1919년 가사는 '임마누엘') 2절에 '십자가에서 구원받은 강도' 얘기가 있으며 3절에 '어린양'이 나오는 것이 이 가설을 뒷받침한다.

나중에 1930년대에 다른 찬송가가 출간되면서 가사가 좀 바뀌었는데,
그때의 가사도 지금과는 여전히 차이가 좀 있어서 '그 참혹한' 대신 '그 수욕된'(수치스럽고 욕된)이라고 적혔고, '나 믿노라' 대신 '나는 믿소'라고 적혀 있었다.

후렴 절정부에 나오는 Lord, I believe!를 생각해 보자. 한국어 가사에서는 음절수 제약 때문에 '주'가 빠졌지만 1919년 수록 당시부터 이 곡의 설정상 영어 제목은 "주여 내가 믿나이다"였다. 이 표현은 명백히 성경에 근거를 두고 있다.
"주여, 내가 믿나이다. (나의 불신을 도와 주소서)"(막 9:24)라는 아이 아버지의 절박한 절규가 오버랩되기도 하고, 한편으로 선천성 맹인이 시력을 받은 후 예수님을 믿는(요 9:38) 장면도 떠오른다. (막 9:24.. KJV 이외의 성경에서는 '주여'라는 단어가 빠졌다는 건 차치하고라도..;;)

이 찬송가 가사는 그 심상에다가 예수님 영접을 절묘하게 오버랩 시켰다.
죄의 사슬, 죄의 형벌로부터 해방된 것에 감격하면서 대한 독립 만세를 외치듯이 이 찬양을 예배당에서 목놓아 불러 보자.
깨알같은 바람이지만, 난 3절 가사대로 영원한 새 나라에 모여서 금거문고보다는.. Looking for you를 흥얼거리고 싶다. 하늘나라에는 철도도 있고 새마을호 열차도 당연히 있을 것이다.

본인은 평소에 유튜브에서 다음 찬양 동영상을 즐겨 듣는다.
2절과 그 이후로 갈수록 알토 한 분의 나지막한 목소리가 유난히도 부각되어 들린다. 투개월의 김 예림 목소리처럼 독특하다!

2. 마귀들과 싸울지라 죄악 벗은 형제여

우리에게 친숙한 요것도 신증 복음가에서 처음 소개된 찬송 중 하나이다.
한국어 가사를 보면 영락없이, 딱 전형적인 '영적 전투와 승리' 카테고리이다. 그러나 본고장인 미국에서는 이 곡이 하드코어 전천년주의 종말+재림 가사가 붙은 찬송인 걸 아시는 분 계신가?

영어 가사는 "내 눈이 주님의 재림의 영광을 보았노라"로 시작하며, 예수님이 수많은 성도들과 함께 지상 재림을 하는 모습을 묘사한다.

"진노의 포도즙 틀을 밟는다. 입에서 날카로운 검이 나온다." 이런 표현은 평소에 요한계시록을 문자 그대로 읽으면서(특히 19장) 성경적 종말론을 공부한 적이 없는 사람이라면 생소할 것이다.

기독교 음악 중에서 특별히 찬양보다 영적 노래에 가까운 범주라면 가사에 응당 성경 말씀과 직설적인 성경 교리를 담고 있어야 한다. 오늘날의 CCM이 영적으로 다 나쁘지는 않겠지만 CCM이 옛날 클래식 찬송가에 비해서 영성이 부족한 면모 중 하나가 교리가 노골적으로 담겨 있지 않다는 것이다. 그냥 "당신은 사랑받기 위해 태어난 사람" 같은 듣기 좋은 내용만 있지 대놓고 예수님의 피, 죄와 심판, 지옥, 재림 같은 원색적인 얘기를 점점 안 하는 것이 비단 설교 스타일뿐만 아니라 기독교 음악의 트렌드에까지 반영되고 있기 때문이다.

그런데 사실은 198, 90년대 이후의 CCM까지 갈 것도 없이 한국 교회의 찬송가는 클래식들부터가 영어 가사에 비해서 전반적으로 '찐한' 교리 표현의 수위가 좀 약하다. 여기에 대해서는 앞으로 또 내 블로그에서 다룰 기회가 있으면 언급을 할 것이다. 이런 점에서 볼 때, <마귀들과 싸울지라>의 영어 원판 가사는 본인에게 무척 인상적으로 보였다.
한국어 가사는 일본인 목사가 쓴 다른 찬송시를 번역한 것이라고 한다. 우리말 가사와 영문 가사가 같이 일치하는 건 후렴의 "영광 영광 할렐루야"밖에 없는 셈이다.

이 노래의 곡에 대해서도 사연이 많다. 원래 이 멜로디는 19세기에 미국에서 소방대원의 행진곡으로 만들어졌다. 그런데 멜로디가 적당히 경쾌하고 듣기 좋다 보니 이 곡은 여러 종류의 가사가 붙어서 다른 행진곡이나 군가 등으로도 애창되었다. 그랬는데 "이거, 곡 멜로디는 좋은데 가사가 영 좋지 않다. 뭔가 좋은 찬송시를 붙여서 부를 수는 없을까?"라는 생각을 한 어느 크리스천 작사자가 있었고, 성경을 묵상하다가 예수님의 재림을 동경하는 가사가 붙어서 저런 곡이 만들어진 거라고 한다.

이렇듯, 성경의 각 책만큼이나 찬송가도 각 곡들이 작사· 작곡· 번역된 과정이 독특한 게 많다. 그런 것들을 알고 부르면 재미있다. 지금은 인터넷 검색만 하면 이런 정보들은 정말 금방 쉽게 얻을 수 있기도 하고 말이다.
이런 맥락에서, 작년 봄에 세월호 침몰이라는 국가적인 대참사가 벌어졌을 때는 It is well with my soul(내 평생에 가는 길 순탄하여 / 내 영혼 평안해)라는 찬송이 잠시 주목을 받기도 했다. 이거 작사자도 선박 사고로 처자식을 잃은 와중에 하늘로부터 오는 평안을 되찾고 가사를 썼기 때문이다.

* 그리고 몇 가지 별로 중요하지 않은 사실은..

• 본인은 지금 다니는 교회에서 찬양 인도자이다. 비록 기악이든 성악이든 음악을 전공한 이력은 전혀 없지만 찬송은 그냥 의욕 있게 크고 기계적으로 정확하게만 부르면 장땡이니까..
• 본인은 킹 제임스 진영에 들어가기 전에 고향에서는 성결교 출신이다.

Posted by 사무엘

• 지금으로부터 무려 30년도 더 전에 만들어진 엄청난 옛날 물건이다. 나이가 본인과 맞먹는다~!
• 게임기(오락기 포함)이 아닌 PC용이다. 그래서 비주얼이 겨우 4색 CGA로 맞춰져 있는지라 당대의 게임기용 게임들보다는 그래픽이 다소 초라해 보인다.
• 본인은 옛날에 컴퓨터 학원에서 구경했던 적이 있다. 그런 인연이 있기 때문에 이렇게 내 블로그에다 소개도 하는 것이다.
• 개인 작품이다.
• 프로그램은 롬/카트리지 이미지 따위가 아니라 COM 파일 하나로 존재한다. 그래서 도스박스 정도의 에뮬레이터에서 간단히 실행 가능하다.
• 딱히 이렇다 할 엔딩이 없다. 단지 인간이 도저히 감당할 수 없을 정도로 게임 진행이 점점 더 빨라지고 어려워질 뿐이다.
• PC용이지만 그래도 여전히 게임기용 게임을 표방하는지, 실행을 종료하는 명령도 없다.
• 오늘날은 다들 '리메이크' 작품이 나와 있다. 특히 모바일용으로. 게임 목표와 방식은 동일하지만 그래픽과 사운드를 월등히 더 고퀄로 끌어올려서 말이다.

"아~ 이거! 그때 그랬지" 하면서 공감하는 old-timer들이 많이 계시기를 기대하며 글을 시작하겠다.

1. Paratroopers (1982)

우리는 화면 하단 중앙의 포탑의 각도를 좌우 화살표로 조종할 수 있다. 하늘 위로는 헬리콥터들이 수시로 드나드는데 총알을 맞혀서 떨어뜨려야 한다. 총알을 한 발 쏠 때마다 점수를 1 잃지만 목표물을 맞히면 그보다 더 많은 수의 점수를 얻는다. 단, 0점이라도 총알 보급 자체는 무한임.

가끔은 헬리콥터에서 낙하산을 탄 군인이 떨어지는데 얘는 반드시 쏴 죽여야 한다. 좌나 우 한 방향에 군인이 4명이 생기면 이 군인은 포탑 위로 기어 올라와서 포탑을 부수며 이로써 게임이 끝난다.
또한 주기적으로 헬리콥터 대신 제트기가 날아오면서 폭탄을 일직선으로 투하하는데, 이 폭탄도 요격해야 한다. 안 그러면 포탑은 폭탄에 맞아 박살 난다. 폭탄을 요격했을 때의 점수가 가장 높다.

재미있는 것은 사람의 경우 사람 자체가 아니라 낙하산만 맞히는 게 가능하다는 점이다. 그러면 그 사람은 땅바닥으로 운지-_-하는데, 아래에 다른 사람이 있다면 그 사람도 같이 죽는다. 이것이 포탑 아래에 이미 내려간 군인을 제거하는 유일한 방법이다.

나름 아기자기한 요소가 여기저기 담겼고 상당히 재미있는 시간 죽이기용 게임이다.
다만 실제로 게임을 해 보면 조작이 굉장히 불편하다는 게 아쉬운 점이다. 폭탄 요격도 생각보다 잘 안 돼서 첫 제트기 씬 때 죽어 버리는 경우가 허다하다.
포탑이 돌아가는 속도, 총알이 날아가는 속도도 그리 빠른 편이 아니어서 군인들이 좌우로 사정없이 떨어질 때 신속하게 대응하기 어렵다.

이 게임의 개발자는 폴란드계 미국인인 Greg Kuperberg인데.. 이 사람은 1967년생이다. 즉, 저 게임을 중3~고1쯤 되는 나이일 때 어셈블리어를 혼자 뚝딱거리며 만들었다는 뜻이다. 그리고 이 글에서는 소개하지 않지만, 저 사람은 비슷한 시기에 이것과 비슷한 타입의 다른 게임도 여럿 개발한 경력이 있다.

10대 중반의 나이에 엄청난 프로그램을 개발한 괴수야 이 세상에 한둘만 있는 건 아니니, 이것만으로는 그렇게까지 대단한 이야기가 아닐 수 있다. 하지만 저 사람은 좀 더 무서운 가정사와 내력이 있는데, 바로 부모가 모두 영문 위키백과에 등재되어 있을 정도로 저명한 수학자이다. (대학교 수학과 교수) 그리고 저 사람 자신도 나중에 미국의 유수의 명문대에서 박사 학위를 받은 뒤 나중에 수학과 교수가 되었고, 수학은 아니지만 물리학과 교수인 여자와 결혼했다.

이 정도면 우리나라의 홍 성대 씨에 맞먹는 수학 명문 가문이 아닐 수 없다.
수학 덕후가 만든 덕분에 헬리콥터나 대포가 박살날 때 날아가는 파티클들의 모양과 움직임이 상당히 고퀄이었던 건지도 모르겠다. 다시 말하지만 저건 중삐리~고삐리 급 애가 만든 게임이다.

2. Bouncing Babies (1984)

화면의 왼쪽엔 5층짜리 건물이 온통 불길에 휩싸여 있으며, 미처 지상으로 대피를 못 한 어린 아기들이 수시로 창문에서 떨어진다. 그리고 당신은 안전 낙하용 매트를 든 2인조 구급대원이다. 아기는 한번 매트에 떨어지면 오른쪽으로 세 번 통통 튀는데, 이때도 아기를 매트로 받아서 구급차가 있는 데까지 안전하게 보내야 한다. 게임 진행이 하도 엽기적이어서 머리에서 잊혀지지가 않는다. (걍 구급차를 좀 더 건물에 가까이 주차시켜 놓지 그래..?? 같은 건 묻지 말자..ㅋ)

게임의 기술 수준은 그렇게 높지 않다. 건물의 불은 불꽃 애니메이션이 있는 것도 아니고 그냥 무작위로 불 스프라이트를 xor 연산한 것이 나타났다가 사라지기를 주기적으로 반복하는데, 그래도 기술적인 단순함에 비해 불 같은 느낌이 살짝은 난다. 색깔을 나타내는 숫자의 한 비트만을 xor시킨 것으로 보인다.

또한 구급대는 일체의 스프라이트가 존재하지 않으며, 좌우 화살표를 누를 때마다 좌중우 세 위치 중 하나로 곧바로 워프할 뿐이다. 이 정도 게임은 걍 GWBASIC으로도 만들 수 있지 않을까 싶을 정도.

그리고 그런 의심이 더욱 강하게 드는 이유가 뭐냐 하면.. 이 프로그램은 실행 직후에 불, 아기, 구급대 같은 그래픽만 화면에 잠깐 나타났다가 사라지기 때문이다.
도스 시절의 BASIC 프로그래머라면 이건 화면에 그려진 그래픽 내용을 버퍼에다 저장하는 GET 명령을 호출하는 준비 과정과 유사함을 눈치 챌 수 있을 것이다.

난이도가 올라가서, 한 아기가 완전히 구급차로 가기 전에 또 5층에서 아기가 떨어지기 시작하면 구급대는 그야말로 좌우로 축지법을 써야 하게 된다. 옛날 도스용 라이온 킹 게임의 스테이지 중간 보너스 게임으로 있던 Bug Toss와 비슷한 방식이다.

게임 화면에서 고개를 좀 갸웃거리게 하는 것은.. 잔기를 표시한 방식이다.
저 게임에서 미스는 두 말할 나위 없이, 떨어지는 아기를 하나라도 놓쳐서 땅에 떨어뜨리는 것이다. 그런 사고를 낼 때마다 잔기가 하나씩 줄어들며, 모든 잔기가 떨어지면 게임 오버가 된다.

그런데 게임에서는 그 잔기를 아기 모양으로 표시해 놓았다. 아기 모양은 차라리 한 스테이지당 구해야 하는 아기의 수를 나타내고, 스테이지가 진행될수록 그 남은 수가 줄어들게 하는 게 자연스럽지 않을까? 아기 모양으로 "허용되는 미스의 수"를 표기한 건 좀 직관적이지 못해 보인다.

물론 나도 말은 그렇게 했지만 근본적으로 아기를 떨어뜨린다고 해서 저 구급대원이 당장 다치거나 죽는 건 아니기 때문에, 이런 게임 체계에서는 뭔가 다른 대안을 떠올리기도 쉽지 않아 보인다.

뭐, 이런 게임도 있다 싶어서 소개해 보았다.
개발자는 Dave Baskin이라고 알려져 있으나, 동명이인이 많을 뿐만 아니라 직접적으로 이 게임과 프로필이 연결되어 있는 사람을 찾지 못해서 개발자가 지금은 뭘 하고 있는지 알기가 어렵다.

3. Alley Cat (1983)

그리고 그 이름도 유명한 Alley Cat. 얘는 게임 자체와 개발자 모두에 대해서 본인이 이미 심층분석을 한 적이 있기 때문에 이 글에서 또 상세히 다루지는 않겠다.

비슷한 시기에 나온 위의 두 게임과 비교해 보니 Alley Cat이 당시로서는 창의적인 명작 대작이었는지가 실감이 가지 않는가? (비록 Alley Cat은 전적으로 1인 기획은 아니었고, 다른 사람이 만들던 것을 Bill Williams가 물려받은 형태이지만)
다른 게임에 비해 얘는 일단 길거리, 집안, 최종 보스 퀘스트 등 현실 세계과 초현실 세계를 드나들면서 장면 내지 컨텐츠 자체가 엄청 많이 존재한다.

예전 글에도 적혀 있듯, 이 게임의 개발자는 훗날 게임 업계를 은퇴한 뒤 신학을 시작했다. 그러나 유전병을 갖고 있던 게 도져서 30대 후반의 나이로 세상을 떠났다. 생년과 몰년이 pkzip의 개발자인 필립 카츠와 비슷해서 비교된다는 점까지 언급한 바 있다.

* 그나저나 옛날에는 마우스가 없어도 조이스틱은 있었는지.. 그 시절엔 조이스틱을 어느 포트에다 연결해서 어떻게 썼는지 참 궁금해진다.
도스용 고전 게임들 중에서도 조이스틱을 지원 안 하는 물건은 거의 없다시피했기 때문이다.

Posted by 사무엘

NT 계열은 일단 마의 리소스 퍼센티지 제약이 없었으며, 말로만 듣던 2바이트 문자열 기반의 유니코드 API가 잘 지원되었다. 이 둘은 매우 크게 다가온 아이템이다.
작업 관리자가 9x 계열에 비해서는 넘사벽급으로 잘 만들어져 있었고, 도스창이 아닌 정식 명령 프롬프트가 제공되었다. 이 외에도 EXE/DLL 내부의 리소스를 수정하는 API가 사용 가능한 것도 좋았다. (9x 계열은 16비트 바이너리의 리소스만 고칠 수 있었음)

윈도 95/98에서는 못 보던 파일은 ntoskrnl.exe, csrss.exe, lsass.exe, ntdll.dll, hal.dll, ntvdm.exe, svchost.exe 등이다.
그 반면, 윈도 9x의 잔재이던 파일은 msgsvr32.exe, win386.swp, system.dat, user.dat, winoa386.mod, *.vxd, win.com 같은 것이다.

윈도우 2000/XP부터는 NT 커널 덕분에 주기적으로 재부팅을 할 필요가 없어졌다.
하지만, 주기적으로 재설치도 거의 할 필요가 없어진 건 Vista 이상인 듯하다. XP는 이 범주에까지 넣기에는 좀 2% 부족한 구석이 있었다.

2.
과거에 Windows 9x 시리즈와 Windows NT는 구조적으로 여러 차이가 있었지만, 프로그래머의 관점에서 중요한 특징 중 하나는 '이식성'이었다.
NT는 하드웨어에 종속적인 계층이 철저히 분리되어 설계되었으며 커널이 대부분 어셈블리가 아니라 C/C++이라는 '고급 언어'로 작성되었다. 마치 유닉스처럼. 덕분에 인텔 x86뿐만 아니라 90년대 당시로서는 MIPS, Alpha 등 다양한 아키텍처용 윈도 NT가 나오기도 했다.

NT는 설계 차원에서 특정 하드웨어의 특성에 맞는 '타협'을 별로 안 하고 추상화 계층이 많이 존재하다 보니 깔끔함, 안정성, 범용성 등 많은 장점을 얻을 수 있었다. 게다가 그 시절에 벌써 유니코드를 염두에 두고 wide string을 기본적으로 사용하기 시작한 건 상당한 선견지명이다. 물론 그 대신 시스템 요구 사항이 당연히 1990년대의 가정용 PC가 도저히 범접할 수 없을 정도로 높았다. 메모리와 속도 모두.

이런 NT와는 달리, Windows 95는 이상이 아닌 현실을 추구하였다. 도스와 윈도 3.1을 돌릴 수 있는 정도의 램 한 자릿수 MB대 똥컴을 타겟으로 하여 Win32 API를 최대한 많이 구겨 넣었다. 이 과정에서 지금은 당연시되고 있는 유니코드 API조차도 메모리를 필요 이상으로 많이 잡아먹는 다고 판단되어 과감히 짤려 나갔다.

9x 커널의 소스에는 도스 레거시를 비롯해 오로지 x86 CPU에만 최적화된 쑤제 어셈블리 코드가 난무하였다. 그렇게까지 극도로 최적화를 하고 성능을 짜내야만 메모리 사용량을 1K라도 줄일 수 있을 테니 말이다. 9x는 NT보다 배고픈 운영체제인 것이다. 그럼에도 불구하고 OS/2를 PC 환경에서 완전히 몰아내고 Windows 천하통일을 이루는 데 기여한 일등공신은 NT가 아니라 95였음이 부인할 수 없는 사실이다.

OS/2를 개발하던 마소의 엔지니어들이 떨어져 나가서 따로 만든 게 NT라고는 하지만, OS/2 자체는 NT 같은 이식성 있는 형태라기보다는 9x에 더 가까운 어셈블리 최적화 컨셉이었다고 한다. OS/2는 NT 뺨치는 수준의 앞서 나간 최첨단 운영체제이긴 했지만, 내부 구조가 이식성보다는 역시나 x86에 너무 종속적이었다는 뜻. 그래서 다른 아키텍처로 이식은커녕, 같은 x86 컴에서 가상화 소프트웨어로도 돌리기가 곤란할 정도라고 한다.
(그래도 지금은 x86에서 맥 OS X 해킨토시까지 돌리는 세상이 됐는데 설마 OS/2를 못 돌리나 싶다.)

3.
더 옛날, 도스 시절에는 뭔가 새로운 하드웨어를 사용하려면 램 상주 프로그램을 덕지덕지 실행해 놔야 해서 몹시 불편했다. CD롬조차도!

• 사운드: sound / unsound (굉장한 옛날 유물. 왠지 '불건전하다!'가 생각 나는 건 기분 탓. ㅋㅋㅋ)
• 그래픽: simcga, msherc (이것도 옛날 유물. msherc의 경우, QuickBasic에도 포함돼 있었다.)
• 마우스: mouse (단, 윈도 3.x는 별도의 램상주 드라이버 없이도 마우스를 스스로 인식하여 실행되었음!)
• CD롬: mscdex (기본 메모리를 상당히 많이 차지했음)

아마 USB 포트가 도스 시절에 도입됐다면, 이걸 인식시켜 주는 램 상주 프로그램도 당연히 필요했을 것이다.
아, 텍스트 모드에서 한글을 구동해 주는 프로그램도 빼먹을 수 없다. hbios / mshbios(윈도 95) 같은 것.
그 외에 화면 캡처나 게임 위저드 같은 램 상주 유틸리티는 하드웨어 인식보다는 편의 기능 분야에 속한다.

요즘은 환경변수 같은 건 PATH에서나 제일 많이 쓰이고, C/C++ 프로그래머에게는 컴파일러의 동작에 필요한 include 및 라이브러리 디렉터리를 지정할 때나 쓰이는 게 고작이다.
하지만 옛날에 사운드 블래스터라는 사운드 카드가 있던 시절에는 기본 IRQ 번호던가 뭔가도 환경변수에다 지정해 놓곤 했으며, 각종 게임의 환경설정 프로그램에는 사운드 종류와 그런 세부 정보도 입력을 받곤 했다.

이것도 정말 까마득한 옛날 얘기가 됐다.
도스용 프로그램들에는 파일 메뉴에 '도스 나들이(DOS Shell)' 기능이 있던 시절이니까 말이다.
운영체제가 이렇게 방대하고 권한이 커지면서 상당수의 유틸리티들은 의미를 퇴색했으며, 전문화된 고급 셸 아니면(토탈 커맨더 같은) 더 전문적인 유지보수 유틸리티(노턴 고스트?) 내지 안티바이러스/보안 쪽으로 업종을 세분화· 전환하는 게 불가피해졌다.

4.
태초에 도스는 검은 화면에 흰 프롬프트밖에 없었을 뿐만 아니라 명령어를 입력하는 환경도 굉장히 자비심이 없었다.
삽입/삭제 모드 같은 개념이 없을 뿐만 아니라, 애초에 이미 입력된 글자를 지우지 않고서는 앞 글자로 cursor를 옮기는 것 자체가 불가능했다. 즉, 왼쪽 화살표만 눌러도 마치 bksp를 누른 것처럼 앞글자가 지워지면서 cursor가 앞으로 이동했다.

명령 히스토리는 직전의 딱 한 단계만 지원했다. F1~F3을 눌러서 직전 명령을 한 글자씩 복구하거나 첫 n 글자 또는 전체를 한꺼번에 불러오곤 했다. 그 시절을 혹시 기억하는 분이 계시는지?

그나마 doskey.com이라고 아마 도스 3~4쯤에서 추가된 걸로 추정되는 외부 명령 램 상주 유틸리티를 실행하면 위/아래 화살표로 히스토리가 가능하고 좌우 cursor 이동이 자유롭게 가능해졌다. 지금은 너무 당연하게 여겨지는 기능이 옛날에는 별도의 프로그램을 통해서만 접근 가능한 액세서리 기능이었던 것이다.

윈도 NT의 명령 프롬프트는 기본적으로 이 모드인 듯한데, 그런데 tab을 눌러서 파일/디렉터리 이름을 자동 완성하는 기능은 윈도 XP에서 처음으로 추가되었다. 세상에, NT4와 2000 시절까지만 해도 이런 기능이 없었으며, tab을 누르면 그냥 문자적인 탭이 그대로 삽입되곤 했다.

단, 기능 추가만 있는 건 아니다. 윈도 XP까지는 탐색기에서 파일이나 디렉터리를 명령 프롬프트에다 drag & drop을 하면 그 이름을 자동으로 삽입해 주는 기능이 있었는데 아마 윈도 Vista부터는 그 기능이 의도적으로 삭제되었다. 보안 때문에 취해진 조치라고 하는데 이런 편리한 기능에 도대체 무슨 보안 문제가 있는지는 나로서는 알 길이 없다.

명령 프롬프트를 전체 화면으로 실행하는 기능 역시 Vista에서부터 삭제되었다. 딱히 별 의미가 없어지기도 했으니.
어디 이 뿐이랴. 2000까지만 해도, 콘솔창 내용을 마우스로 긁는 '빠른 편집' 모드는 곧장 사용 가능했던 반면 XP부터는 먼저 속성 창을 거쳐서 강제로 켜야만 사용 가능하게 바뀌었다. 이건 보안 이유 때문은 아니고, 마우스를 지원하는 도스용 프로그램과의 호환 때문에 취해진 조치라고 한다.

제아무리 도스 기반이 아닌 NT 계열의 명령 프롬프트라 해도, 문자 인코딩부터가 2바이트 ANSI 코드 페이지와 여전히 얽혀 있고 도스의 흔적을 완전히 걷어내지는 못한 듯하다. 그래도 64비트부터는 16비트 코드 자체가 이제 지원되지 않는데 더 좀 걷어내도 되지 않나 싶다.
기존 명령 프롬프트보다 더 강력한 대체제라고 일컬어지는 PowerShell이라는 물건이 있긴 하나, 본인은 그런 게 있다는 것만 알고 이게 특별히 장점이 무엇인지는 알지 못한다.

아 그리고. 지긋지긋한 Terminal 내지 굴림체 말고 Consolas 내지 Courier, Lucida Console 같은 글꼴을 좀 쓰고 싶은데 Wndows는 공식적으로는 명령 프롬프트의 글꼴을 자유자재로 바꾸는 방법을 제공하지 않는다. 마치 uxtheme을 해금/탈옥시키듯이 레지스트리를 조작해서 글꼴을 바꾸는 방법이 인터넷에 있긴 한가 본데 본인은 성공하지 못했다.

Posted by 사무엘

* 지금으로부터 무려 4년 전에 Windows 공용 컨트롤에 대해서 글을 쓴 적이 있었는데 오늘은 그에 대한 연장선이다. 또 옛날 이야기를 늘어놓아 보겠다.

예전에도 글을 썼듯이, 공용 컨트롤은 좀 더 새끈한 UI를 제공하기 위해, Windows 1.0 이래로 기본 제공되던 시스템 컨트롤에 추가적으로 도입된 컨트롤들이다.
사용 전에 InitCommonControls 함수 호출이 필요하다지만, 요즘은 공용 컨트롤 (6.0) 매니페스트를 지정하는 것만으로도 초기화가 자동으로 되기 때문에 EXE에서는 이 절차가 굳이 필요하지 않다.

공용 컨트롤들은 완전히 새로운 기능이라기보다는 Windows의 특정 응용 프로그램이나 Office에서 내부적으로 자체 구현으로 돌리던 싸제 컨트롤이 보급품으로 바뀌는 경우가 많다.
이들은 16비트 시절을 경험한 적이 없고 Windows 95/NT 3.51과 역사를 같이하기 때문에, '32비트'를 강조하기 위해 클래스들의 이름이 대부분 32로 끝난다는 특징이 있다. ListView, TreeView 같은 것들은 이런 1기 공용 컨트롤이다.

그 뒤 Internet Explorer 3 이후로 공용 컨트롤은 IE의 버전업을 따라 비약적으로 발전하기 시작했다. 달력 컨트롤, 날짜 선택 컨트롤, ReBar 같은 건 운영체제 보급 컨트롤이라기보다는 뭔가 델파이 컴포넌트 같은 느낌이 드는데.. 이것들은 IE와 함께 도입된 2기 컨트롤이다.

그렇게 새로운 GUI 컨트롤을 만들어서 자기 혼자만 안 쓰고 꼬박꼬박 다른 프로그래머에게도 공개한 건 의도는 좋지만, 그 대신 1990년대 말엔 4~5.x대의 온갖 버전의 comctl32.dll이 난립하면서 Windows가 DLL hell 비판을 받기도 했다. 응용 프로그램이 자신을 기준으로 하는 comctl32.dll을 시스템 디렉터리에다가 막 덮어쓰면서 운영체제의 안정성을 떨어뜨렸기 때문이다.

공용 컨트롤의 3기는 side-by-side assembly라는 방식으로 DLL hell을 종식시키고 GUI가 근본적으로 싹 바뀐 Windows XP와 함께 도래했다. 그리고 3기와 함께 추가된 새로운 공용 컨트롤은 아시다시피 하이퍼링크 컨트롤이다. 인터넷 시대가 도래하면서 하이퍼링크 역할을 하는 컨트롤의 필요성은 예전부터 대두되어 왔으니 말이다.

텍스트 전체가 단일 링크인 게 아니라 A 태그로 둘러싸인 부분만 링크이며, 한 컨트롤 내부에 여러 링크가 있을 수 있기 때문에 더욱 편리하다. A 태그가 없는 하이퍼링크 컨트롤은 그냥 텍스트 static 컨트롤과 별 차이가 없다. 얘는 재래식 InitCommonControls(Ex)가 아니라 오로지 공용 컨트롤 6.0 매니페스트로만 사용 가능하다.

공용 컨트롤들 중에 에디트 컨트롤과 동작이 비슷해 보이는 건 IPv4 주소를 입력받는 컨트롤이 있는데, 내부적으로 자그마한 에디트 컨트롤을 4개 나란히 생성하여 동작한다. 운영체제의 제어판 밖에서는 별로 볼 일이 없는 물건임. IPv6 주소를 입력받을 때는 그냥 일반 에디트 컨트롤을 썼더라.

그리고 잘 쓰이지는 않지만 단축글쇠 입력 컨트롤도 있다. 캐럿도 생성하고 언뜻 보기에 에디트 컨트롤의 서브클래싱 버전 같지만 얘는 에디트 컨트롤을 사용하지 않고 독자적으로 동작하는 물건이다. 사용 가능하거나 반드시 써야 하는 modifier를 Ctrl, Alt, Shift 중에서 지정할 수 있다.
<날개셋> 한글 입력기는 이것들의 좌우 구분이 가능해야 하고 Win키까지도 modifier로 지정 가능해야 하는 관계로, 용도에 맞지 않아서 단축글쇠 규칙 편집 UI에서도 이 컨트롤을 사용하지 않았다.

위의 컨트롤과는 달리 리치 에디트 컨트롤은 공용 컨트롤이 아니다. 얘는 혼자 독자적인 DLL을 갖고서 따로 노는 물건이기 때문에 초기화도 공용 컨트롤과는 다른 방법으로 한다. 복잡한 워드 프로세서를 통째로 컴포넌트화한 것이기 때문에 이것 하나만으로도 다른 어지간한 컨트롤들의 덩치를 모조리 능가한다고 봐야 할 것이다.
예전에도 한번 글로 썼듯이 리치 에디트 컨트롤은 파일 이름과 버전 사이의 관계가 굉장히 이상하게 꼬였다. SxS 방식을 쓰는 것도 아니고.

IE 웹브라우저 컨트롤은 공용 컨트롤이 아닐 뿐만 아니라 일반 윈도우 자체도 아니다. ActiveX 컨트롤이기 때문에 COM API를 써서 훨씬 더 복잡한 방식으로 초기화해서 사용해야 한다. MFC의 도움 없이는 난 불러다 써 보지도 못했다.

comctl32.dll에는 공용 컨트롤을 구동하는 코드가 주로 들어있을 테니 이들을 초기화하는 함수 말고 딱히 다른 기능이 있을까 싶은 생각이 든다. 하지만 기성 대화상자를 변형하여 동작하는 property sheet나 wizard GUI를 구동하는 함수도 여기 있고, 또 image list를 관리하는 함수들도 죄다 여기에 들어있다. 이게 user나 gdi에 들어있지 않고 comctl에 들어있는 이유는, 이 이미지 리스트들은 여러 공용 컨트롤들이 이미지를 표시할 때 한데 공유하는 자료구조이기 때문이다.
그런데 윈도우 컨트롤이 전혀 아닌 물건이 다른 공용 컨트롤과 같은 등급의 카테고리에 문서화돼 있으니 이건 좀 의아한 점이다.

공용 컨트롤들에 대해 본인이 오랫동안 의아하게 생각해 온 점은.. 클래스 이름들의 작명에 일관성이 없다는 점이다. 작명 방식은 크게 세 가지가 있는데, 이것들이 별다른 원칙 없이 뒤죽박죽으로 섞여 있다. 32라는 숫자로 끝난다는 점 말고는 다른 공통점이 없는...데, 그러고 보니 하이퍼링크와 pager 컨트롤은 예외적으로 32가 안 붙었다!

1. Sys+대문자 계열: SysIPAddress32, Header32, Link, ListView32, TreeView32, TabControl32, Animate32, MonthCal32, DateTimePick32, Pager
2. msctls_+소문자 계열: msctls_hotkey32, statusbar32, trackbar32, updown32, progress32
3. 아무 접두사가 없음: ToolbarWindow32, ReBarWindow32, ComboBoxEx32

어지간한 응용 프로그램에서 안 쓰이는 경우가 없는 도구 모음줄과 상태 표시줄만 해도 클래스 이름의 작명 스타일이 (2)와 (3)으로 서로 다르다.

심지어는 소스 코드상으로 클래스 이름을 나타내는 매크로 상수조차도 작명 방식에 통일성이 없다. WC_* 로 시작하는 명칭이 있는가 하면 그냥 *CLASSNAME로 끝나는 명칭도 있다. (toolbar, rebar, statusbar)
서로 다른 팀에서 별개로 만들던 컨트롤들을 한데 합쳐서 이런 일이 생긴 것 같다. 물론 대세는 WC_* 스타일이다.

마소에서도 이런 식의 이름 혼란에 대해서 의식을 전혀 안 하고 있는 건 아니다.
공용 컨트롤들이 사용하는 구조체를 보면 TV_*로 시작하는 구조체가 NMTV*로 바뀌고 예전 명칭은 typedef로 처리되는 등, rename을 종종 하기도 한다. 하지만 처음부터 개명을 할 일이 없게 명칭을 잘 정하는 게 더 좋았을 것이다.

이상이다.
그나저나 공용 컨트롤의 스펙을 다시 보니 옛날에는 Native font control이라는 게 있었던 모양이다. 클래스 이름도 NativeFontCtl이라고 당당하게 있는 윈도우인데.. 도대체 뭘 하는 물건이었지?

MSDN에 문서화는 이렇게 돼 있지만, 도대체 이런 윈도우를 만들어서 해결하려고 한 문제가 무엇인지.. 그리고 지금은 그게 왜 불필요해졌는지에 대한 의문은 해결되지 않는다. 공용 컨트롤의 세계도 다시 살펴보니 재미있다.

Posted by 사무엘

1. elseif 키워드

프로그래밍 언어에 따라서는 else if를 한데 묶은 축약형인 elseif 또는 elif 키워드를 별도로 제공하는 경우가 있다.
베이직이나 파이썬, 그리고 프로그래밍 요소 중에 없는 게 없는 백과사전형 언어인 Ada에는 저게 있다.

하지만 파스칼, C/C++이나 그 파생형 언어들은 전통적으로 그게 없다. 굳이 그걸 또 제공할 필요 없이 기존 if/else만으로도 동일한 표현력과 계산 능력 자체는 낼 수 있으며,
또한 더 큰 이유로는, 이들 언어는 안 그래도 공백이나 줄바꿈에 구애를 받지 않는 freeform 문법이기 때문이다. 필요하다면 어차피 else if를 한 줄에 나란히 연달아 써도 elseif와 얼추 비슷한 비주얼을 만들 수 있다. (컴파일러의 구문 분석 스택은 복잡해지겠지만..) 베이직과 파이썬은 그렇지 않다.

elseif 축약형은 else 절에서 실행되는 구문이 다음 if 절에 '완전히' 포함되어 있을 때 유용하다.
원래는 else 다음에 소스 코드의 들여쓰기가 한 단계 증가해야 하지만 그렇게 하기는 귀찮고..
수평적인 들여쓰기 단계에서 여러 개의 if를 대등한 위상에서 마치 switch-case처럼 늘어놓고 싶을 때 elseif가 쓰인다.

이런 점에서 보면 elseif 축약은 if-else에 대해서 tail-cut recursion을 한 것과 개념적으로 유사하다.
함수 재귀호출 뒤에 또 다른 추가적인 계산이 없다면, 그런 단순 재귀호출 정도는 스택을 사용하지 않는(= 한 단계 깊이 들어가는) 단순 반복문으로 바꾸는 것 말이다.

사실 C/C++은 elseif 축약이라는 개념은 언어 자체엔 없고 전처리기에만 #elif라는 형태로 있다.
전처리기는 알다시피 freeform 문법이 아니기 때문에 elif 없이 else와 if를 동시에 표현하려면 얄짤없이 줄 수가 둘로 늘어나야 하니,
문법을 최대한 간단하게 만들고 싶어서 부득이 그런 지시자를 넣은 것 같다.

2. NULL 포인터와 0

하루는 통상적으로 사용하던 #define NULL을 0에서 nullptr로 바꾸고 날개셋 코드를 리빌드해 봤다. 그랬더니.. 생각지 못했던 곳에서 엽기적인 컴파일 에러가 떴다.

아니 내가 머리에 총 맞았었나.. 왜 bool 변수에다가 NULL을 대입할 생각을 했지? =_=;;
HRESULT 리턴값에다가 S_OK 대신에 return NULL을 해 놓은 건 도대체 뭔 조화냐.
그리고 그 정도는 애교고.. obj=NULL이 원래는 컴파일 에러가 났어야 했는데 잘못된 코드를 생성하며 지나쳐 버리는 경우가 있었다. 포인터를 별도의 클래스로 리팩터링하는 과정에서 실수가 들어간 것이다.

그 클래스가 정수 하나를 인자로 받는 생성자가 있기 때문에 obj=Class(0)으로 자동으로 처리되고 넘어갔는데, 그 클래스는 독자적인 메모리 할당이 있으면서 대입 연산자 같은 것도 별도로 존재하지 않았다.
이런 일을 막으려고 C++엔 나중에 생성자에 explicit이라는 속성을 지정하는 키워드가 추가되었지만 그걸 사용하지 않는 레거시 코드를 어찌할 수는 없는 노릇이고..

아무튼 언어에서 type-safety를 강화하는 게 이렇게 중요하다는 걸 알 수 있었다.
Windows 플랫폼 헤더 include에서 NULL의 definition이 nullptr로 바뀌는 날이 언제쯤 올까? 옛날에 16비트에서 32비트로 넘어갈 때는 핸들 타입에 대한 type-safety를 강화하면서 STRICT 상수가 도입된 적이 있었는데.

NULL은 C 시절에 (void *)0, 초창기 C++에서는 타입 오버로딩 때문에 불가피하게 그냥 0이다가 이제는 nullptr로 가장 안전하게 변모했다.
개인적으론, PSTR ptr = false; 도 컴파일러 차원에서 안 되게 좀 막았으면 좋겠으나.. 포인터에 0상수 대입은 뭐 어찌할 수 없는가 보다.

3. 자바의 문자열

자바(Java)로 코딩을 하다 보면 나처럼 C++ 사고방식에 머리가 완전히 굳은 사람의 관점에서 봤을 때 궁금하거나 불편하다고 느껴지는 점이 종종 발견된다.
int 같은 기본 자료형이 아니면 나머지는 모조리 클래스이다 보니 한 함수에서 데이터 참조용으로나 잠깐 사용하고 마는 int - string 쌍 같은 것도 못 만드는지? 그런 것도 죄다 새 클래스로 만들어서 new로 할당해야 하는지?

그리고 기본 자료형은 값으로만 전달할 수 있으니 int의 swap 함수조차 만들 수 없는 건 너무 불편하지 않은지?
인클루드가 없는데 자신 외의 다른 클래스에 존재하는 public static final int값이 switch case 상수로 들어오는 게 가능한지? 등등..

이와 관련되어 문자열은 역시 자바 언어에서 좀 어정쩡한 위치를 차지하며 특이하게 취급되는 물건이다.
얘는 일단 태생은 기본 자료형이 아닌 객체/클래스에 더 가깝다. 그래서 타입의 이름도 소문자가 아닌 대문자 S로 시작하며, 이 개체는 가리키는 게 없는 null 상태가 존재할 수 있다.

그러나 얘는 문자열 상수의 대입을 위해서 매번 new를 해 줘야 하는 건 또 아니다. 이건 예외적으로 취급되는 듯하다.
그럼 그냥 String a; 라고만 하면 얘는 길이가 0인 빈 문자열인가(""), 아니면 null인가? 그리고 지역 변수일 때와 클래스 멤버 변수일 때에도 그 정책이 동일한가? 뭐 직접 회사에서 프로그램을 짜 본 경험으로는 전자인 것 같긴 하다.

단, 자바의 문자열을 다룰 때는 주의해야 할 점이 있다. 자바 프로그래머라면 이미 잘 숙지하고 계시겠지만, 문자열의 값 비교를 ==로 해서는 안 된다는 것이다. equals라는 메소드를 써야 한다.
==를 쓰면? C/C++식으로 얘기하자면 문자열이 들어있는 메모리 포인터끼리의 비교가 돼 버린다. 애초에 포인터의 사용을 기피하고 다른 걸로 대체하는 컨셉의 언어에서, 이런 동작은 99% 이상의 경우는 프로그래머가 의도하는 결과가 아닐 것이다.

C++에서야 문자열 클래스에 == 연산자가 오버로딩되지 않은 경우가 없을 테니 언어가 왜 저렇게 만들어졌는지 이해하기 어렵겠지만.. 자바는 연산자 오버로딩이란 게 없는 언어이며 String은 앞서 말했듯이 기본 자료형과 클래스 사이의 어중간한 위치를 차지하는 물건이기 때문에 이런 디자인의 차이가 발생한 듯하다. 자바는 안 그래도 걸핏하면 클래스 새로 만들고 get/set 등 다 메소드로 구문을 표현해야 하는 언어이니까.
오죽했으면 본인은 회사에서 자바 코드를 다루면서도 문자열 비교를 실수로 ==로 잘못 해서 발생한 버그를 발견하고 잡은 적도 있었다.

그나저나 유사 언어(?)인 스칼라, 자바스크립트 같은 언어들은 ==로 바로 문자열 비교가 가능했던 걸로 기억한다.

4. true iterator

파일을 열어서 거기에 있는 문자열을 한 줄씩 얻어 오는 함수(A), 그리고 각 문자열에 대해 출력을 하든 변형을 하든 일괄적인 다른 처리를 하는 함수(B)를 완전히 분리해서 별도로 작성했다고 치자. 혹은 한 디렉터리에 파일들을 서브디렉터리까지 빠짐없이 쭉 조회하는 함수(A)와, 그 찾은 파일에 대해서 삭제나 개명 같은 처리를 하는 함수(B) 구도로 생각할 수도 있다.
그런데 이 둘을 연계시켜서 같이 동작하게 하려면 어떻게 하는 게 좋을까?

이럴 때 흔히 떠올릴 수 있는 방법은,
A 함수에다가 B 함수까지 인자로 줘서 호출을 한 뒤, A의 내부 처리 loop에서 B에 넘겨줄 데이터가 준비될 때마다 B를 callback으로 호출하는 것이다. B는 간단한 일반 함수 + context 데이터 형태가 될 수도 있고, 아니면 가상 함수를 포함한 인터페이스 포인터가 될 수도 있다.

데이터 순회를 하는 A 자체도 파일을 열고 닫거나 내부적으로 재귀호출을 하는 등 state가 존재하기 때문에 매번 함수 실행을 시켰다가 종료하기가 곤란한 경우, 상식적으로 A를 먼저 실행시킨 뒤에 A가 계속 실행되고 있는 중(= 상태도 계속 유지되고)에 그 내부에서 B를 호출하는 게 바람직한 게 사실이다.
물론, 반복문 loop을 B에다가 두고, 반대로 B에서 A를 callback 형태로 호출하는 것도 불가능한 건 아니다. 그런데 프로그래밍 언어에 따라서는 이런 B 중심적인 사고방식의 구현을 위해 좀 더 획기적인 기능을 제공하는 물건도 있다.

def func():
    for i in [1,5,3]:
        yield i

a=func()
print a.next()
print a.next()
print a.next() # 예상하셨겠지만 1, 5, 3 순서대로 출력

파이썬에는 함수에 return 말고 yield 문이 있다. 그러면 얘는 함수 실행이 중단되고 리턴값이 지정되기는 하는데..
다음에 그 함수를 실행하면(정확히는 next() 메소드 호출 때) 처음부터 다시 실행되는 게 아니라, 예전에 마지막으로 yield를 했던 곳 다음부터 계속 실행된다. 예전의 그 함수 호출 상태가 보존되어 있다는 뜻이다.

난 이걸 처음 보고서 옛날에 GWBASIC에 있던 READ, DATA, RESTORE 문과 비슷한 건가 싶었는데.. 저건 당연히 GWBASIC을 아득히 초월하는 고차원적인 기능이다. C++이었다면 별도의 클래스에다가 1, 5, 3 static 배열, 그리고 현재 어디까지 순회했는지를 가리키는 상태 인덱스 정도를 일일이 구현해야 했을 텐데 저 iterator는 그런 수고를 덜어 준다.

단순히 배열이 아니라 binary tree의 원소들을 prefix, infix, postfix 방식으로 순회한다고 생각해 보자.
순회하는 함수 내부에서 다른 콜백 함수를 호출하는 게 아니라 매번 원소를 발견할 때마다 리턴값을 되돌리는 형태라면..
구현하기가 굉장히 까다로울 것이다. 스택 메모리를 별도로 할당한 뒤에 재귀호출을 비재귀 형태로 일일이 구현해 주거나, 아니면 각 노드에다가 부모 노드의 포인터를 일일이 갖춰 줘야 할 것이다.

C++의 map 자료형도 내부적으로는 RB-tree 같은 자가균형 dynamic set 자료구조를 사용하는데, 이런 iterator의 구현을 위해서 편의상 각 노드에 부모 노드 포인터를 갖고 있는 걸로 본인은 알고 있다. RB-tree는 내부적으로 로직이 굉장히 복잡하고 까다로운 자료구조이긴 하지만, 그래도 부모 노드 없이도 구현이 불가능한 건 아닌데 말이다.
안 그랬으면 iterator가 자체적으로 스택을 멤버 변수로 갖거나, 최소한 메모리 할당· 해제를 위해 생성자나 소멸자까지 갖춰야 하는 복잡한 class가 돼야 했을 것이다. 어떤 경우든 포인터 하나와 비슷한 급인 lightweight 핸들이 될 수는 없다.

개인적으로는 지난 여름에 <날개셋> 한글 입력기 7.5에 들어가는 새로운 한글 입력 순서 재연 알고리즘을 구현할 때 비슷한 레벨의 iterator를 비재귀적으로 구현한 적이 있는지라, yield문의 의미가 더욱 절실히 와 닿는다.

Posted by 사무엘

1.
말라기서는 구약 성경의 맨 마지막 책이다. '말라기'는 이 책을 기록한 대언자의 이름이다.

구약의 예언/선지서들은 분위가 다 비슷하다.
우선 이스라엘 백성들의 죄를 신랄하게 깐다. 좀 우파스러운 원론적이고 영적인 죄뿐만이 아니라, 당대 상류층들의 부정부패를 까발리면서 민생 안정과 사회 개혁을 촉구하는 좌파스러운 책망도 골고루 균형있게 나온다.

그런데 결론은 기승전철..은 아니고 기승전'회'로 동일하다. 저런 죄악에도 불구하고 하나님의 타임라인에서 궁극적으로 최후의 승자는 이스라엘이다. 하나님과 이스라엘의 관계는 회복되며 옳다구나 이스라엘 백성들을 괴롭힌 놈들은 다 작살이 나고 씨도 안 남는다. 이러니 오늘날 이스라엘 사람들은 예수를 안 믿음에도 불구하고 반유대주의와 반기독교 성향은 바늘과 실처럼 따라다니는 것이다. 단적인 예로, 천주교 교황이 전세계를 돌면서 예수님 재림과 이스라엘 회복을 말한 적이 있던가? (말한다면 그건 해가 서쪽에서 뜰 일이며, 그 종교는 이미 천주교가 아닐 게다)

그래도 성경 말씀은 기록된 대로 이루어질 것이고 구약 예언서들이 일관되게 말하는 크고 두려운 '주의 날'은 임할 것이다. 단지 구약 대언자들은 산봉우리 너머의 재림만을 보았을 뿐, 예언의 골짜기에 속하는 신약 교회에 대한 계시가 없었으며 초림과 재림의 구분에 대한 개념도 아직 몰랐다는 차이가 존재한다. 물론 실질적으로 초림과 재림 구분은 이스라엘 백성들의 예수님 거부 이후부터 생겼겠지만 말이다.

본론으로 돌아오자면, 말라기서는.. 이스라엘 백성들이 자기 땅으로 귀환까지 하고 나서 거의 100여 년 뒤에 구약 중에서 혼자만 굉장히 늦게 기록됐다.
이스라엘 백성들은 바빌론 포로 귀환 후, 우상 숭배라는 죄 하나는 완전히 떨쳐 냈다. 그러나 노골적으로 바알 숭배만 안 할 뿐이지 영적 상태는 여전히 정상이 아니었다.

주 하나님에 대한 신앙은 막장급의 매너리즘에 빠졌다. 사람들은 자기가 못 먹는 거니까 흠 왕창 많고 병들고 상품으로서의 가치가 없는 가축을 헌물로 바쳤다. 출애굽기 이후로 모세오경에 without blemish이라는 단서가 얼마나 지겹도록 많이 나오는데.. 저건 상상도 할 수 없는 일이었다.
그리고 십일조 헌금을 안 바치니까 레위 지파 성직자들은 먹고 살 수가 없어서 생업을 따로 구해서 투잡을 뛰어야 할 정도였다. 요즘으로 치면 밤에 대리운전?? =_=;;;

말라기서는 전반적으로 하나님에 대한 사랑과 두려움이 완전히 상실되고 “뭐 대충 이렇게 해도 괜찮겠지”, “어차피 다 소용없어”, “우린 아마 안 될 거야” 등, 하나님에 대한 온갖 잘못된 생각들에 대해 하나님이 친히 반박을 하고 책망하는 논리로 진행된다.

말이 나왔으니 말인데 성경에서 사람들의 잘못된 신앙관을 먼저 제시하고서는 그걸 반박하는 형태로 진행되는 텍스트가 신구약을 통틀어 여럿 있다. 로마서의 “그럼 ...하겠느냐? 결코 그럴 수 없느니라(God forbid)”는 완전히 같지는 않지만 비슷한 예이고. 개인적으로는 성경을 통틀어 이런 예들만 한데 모아도 주일 예배 설교 한 편 분량은 충분히 나올 것 같다.

말라기도 기본적으로 그런 논조이니 유쾌한 분위기는 절대 아니다. 오죽했으면 하나님께서 자꾸 동물 헌물을 그딴 식으로 바칠 거면, 그 동물들의 똥을 꼴도 보기 싫은 성직자 네놈들 얼굴에다 덕지덕지 쳐발라 버리겠다는 노골적인 책망까지 하셨을 정도이다. (말 2:3)
헌물 말고도 이 책은 '의의 태양', 침례인 요한 예언도 나오고 십일조에 결혼 문제 등 생각보다 다양한 주제를 이것저것 부랴부랴 다룬다.

그런데 지금 내게 굉장히 절실히 와 닿는 구절은 말 3:14-17이다.
“교회 다니고 하나님 섬기는 거 다 무가치한 헛일일 뿐이다. 어차피 세상에는 자기를 내세우고 적당히 줄 잘 서고 죄도 잘 짓는 사람들이 사회성이 뛰어나고 잘 되고 성공한다..”는 식의 생각.. 역시 일반적인 사람들의 심리는 2400여 년 전이나 지금이나 똑같다.

허나 16절을 보자. 하나님을 두려워하는 사람들이 자주 성경을 강론하고 서로 믿음을 북돋우는 교제를 나누면..
그 사건은 하나님이 친히 귀를 기울여 듣고, 정말 기쁘고 기특하다면서 그걸 책으로 기록으로 남기신댄다.
그리고 다음 17절에 따르면.. 그런 사람들은 보석만큼이나, 친아들만큼이나 하나님께서 무진장 귀중히 여겨고 보상할 것이라는 약속이 나온다.

성경에서 역사· 교리적으로 유대인 얘기를 하고 있는 곳에다가 교회가 유대인 사칭을 하는 건 병크이지만.. 저것만큼은 정말로 오늘날 교회에까지 그대로 적용되는 약속이 아닐 수 없다.
“그러므로 이 말씀들로 서로 위로하라.” (살전 4:18) 휴거와 재림만큼이나 위로의 명분이 성립하는 게 틀림없다.
스바냐서에서 “하나님께서 너로 인해 기뻐하고 노래까지 부르실 것이다”라는 말씀이 나오는 것만큼이나 엄청난 구절이 의외로 소선지서 한구석에서 발견되곤 한다.

이렇게 본인은 길고 길던 구약 통독을 드디어 끝냈다.

2.
난 예나 지금이나 아예 문을 걸어 잠그고 아무것도 안 믿고 무신론자 회의론자로만 산다면 모를까,
내세와 영원을 논하는 '종교'관을 판단하는데 겨우 그 종교에 속한 사람의 외적 행실, 또는 대외 이미지, 유명인사의 의견을 높은 가중치에 두는 건 아주 굉장히 대단히 매우 어리석은 발상이라고 생각해 왔다.

그런 걸 전혀 볼 필요가 없다는 얘기가 아니며 물론 신자들은 좋은 행실로 좋은 간증을 남기고 가능한 한 세상과 화평하게 지내야 한다. 병싯같은 짓으로 불신자에게 쓸데없이 실족거리를 줘서는 안 된다. 허나, 그렇다고 해서 어차피 구도자의 입장에서도 그런 외형적인 것들은 주된 판단 근거가 돼서는 안 된다.

본인은 몇 차례 글을 썼듯이, 무슨 하나님 믿고 예수는 믿지만 교회는 안 믿는다는 식의 생각을 굉장히 싫어한다.
예수님이 무슨 좋은 덕담이나 남긴 4대 성인 도인 슈퍼스타이고 자신의 상식과 교양 한 줄 정도나 기여하는 아이템인 줄로 아는가 본데, 그 예수가 당신이 싫어하는 교회의 창립자이고 교회의 머리이다. 뭘 좀 알고서 얘기해야 하지 않을까?

불신자들하고 어울려서 대형 교회 욕이나 하고 다니는 헛똑똑이 겉멋 든 좌독 성향도 완전 혐오.
경제 쪽으로 대기업에 대한 생각하고 완전히 똑같은 논리이다.
대기업을 엿먹이고 싶고 중소기업을 살리고 싶으면, 나 자신부터 중소기업 제품을 애용하면 되듯이
한국 교회를 진심으로 걱정하고 대형 교회가 한국 교계의 레알 비성경적인 악의 축이라고 생각한다면.. 나 자신부터 아주 보수· 근본주의적이고 신앙의 양심을 충족하는 작은 교회를 찾아서 다니면 된다.

대형 교회가 당신의 개인의 양심의 자유와 신체의 자유를 빼앗지 않았고 폭력을 행사하지 않았다면.. 그렇게까지 피해의식 갖고 미워하지는 않아도 된다. 그리고 작은 교회에는 사람간의 트러블, 부조리가 어디 없을 줄 아는가? 대안 없는 비판, 일관성 없는 판단은 이제 좀 그칠지어다.

세상의 모든 대중교통들은 운송 약관을 보면 "만취자, 중환자 또는 신변이 불결한 자에 대해서는 당사가 승차를 거부할 수 있음"이 명시돼 있다. 무조건이든 단독 승차에 한해서든.

그러나 다른 곳은 몰라도 목욕탕이.. 만취자는 몰라도 신변이 불결한 자를 입장 거부한다는 게 말이 되는 소리이겠는가?
병원이.. 중환자를 거절한다는 게 말이 되는가? 교회가 바로 그런 곳이다.
교회 성도들보다 자신이 너무 똑똑하고 의롭고 질이 높아서 차마 예수는 믿어도 교회는 못 믿겠다(다니겠다) 이러는 분들.. 정말 구원이라도 받은 사람이라면 그 불평을 나중에 예수님 앞에서 자신 있게 털어놓고 예수님을 논쟁에서 이길 수 있기를 난 바라마지 않겠다.

나는 행실이 너무 막장 저질이었는데 나 같은 사람을 구원하고 일꾼으로 써 주신 예수님의 은혜가 너무 고맙고, 가끔 교회에서 이상한 사람과 싸우더라도 교회의 정체성과 본분을 잊지는 않을 것이다. 100% 완벽한 성도로만 구성된 교회에 내가 등록하는 순간부터 그 교회는 완전성이 깨진다는 생각을 하며 다닐 것이다.

* 나는 늘 공언한다. 누군가가.. 있지도 않은 신을 숭배하고 교회 다니느라 인생을 낭비하는 나같은 중생을 너무 불쌍히 여기고 사랑해서.. 무신론을 전하기 위해 나를 위해서 목숨까지 버렸다가 나중에 부활했다면 나는 그 정도 표적에는 기꺼이 반응하여 지금의 기독교 신앙을 버리고 무신론자가 되겠다. 이 정도면 내가 왜 교회를 다니는지 논리가 설명이 되었을 것이다.

Posted by 사무엘

우주 개발과 관련하여 일반적인 항공· 우주덕, 역덕들에게 잘 알려져 있는 유명한 사고는 아폴로 1호나 13호, 그리고 챌린저와 컬럼비아 우주왕복선처럼 유인 우주선에서 발생한 인사사고 위주이다. 그게 임팩트가 크다.

하지만 컴퓨터공학 관련 수업에서 종종 언급되는 우주 사고는 저런 것들보다는 덜 알려진 무인 우주선의 오동작· 자폭 사고 두 건이다. 바로 (1) 1999년에 미국이 발사한 화성 기후 탐사 인공위성의 추락 사고와, (2) 1996년 유럽 우주국에서 발사한 정지 궤도 진입용 아리안 5호 로켓의 자폭 사고이다. 이것들은 다른 기계 구조적인 실수· 결함이 아니라, 전적으로 발사체 포함 로켓을 제어하는 소프트웨어의 버그로 인해 발생했기 때문이다.

전자는 서로 다른 팀의 엔지니어들이 같은 물리량에 대한 단위계를 제각각 다르게 가정하고 코딩을 하는 바람에, 계산 결과의 scale이 산으로 가 버려서 위성이 추락한 정말 안습한 사례이다. 흔히 길이(미터 vs 인치)의 착오라고 알려져 있는데, 더 자세한 문헌을 찾아 보니 사실은 단위 시간당 힘(킬로그램힘 vs 파운드)의 착오이다. 뭐 어느 것이든 표준 단위계와 비표준 단위계의 착오인 건 마찬가지이고 우리나라로 치면 제곱미터와 평, 킬로그램과 근 같은 게 헷갈린 것과 동일하다.

이 때문에 무려 9개월간의 긴 여행을 마치고 기껏 화성까지 잘 가서 궤도에 진입하려던 위성은 예상보다 고도가 급격히 낮아졌으며, 화성의 뒷면으로 들어가는 예상 시각보다 더 일찍 통신이 끊어졌다가 다시는 통신이 회복되지 못했다. 화성의 대기권에까지 들어가 버린 위성은 대기와의 마찰열로 인해 파괴되고 추락했다.

지구로부터 수천만 km나 떨어져 있는 다른 행성에서 벌어진 사고이다 보니, 사고 장면도 전해지는 게 없다.
사고의 원인이 어처구니없는 실수 때문이었음이 밝혀지자 미국 내부에서도 “우리도 미터법의 국내 도입이 시급합니다”라는 여론이 당연히 일었다. 그러나 오랜 관행을 바꾸는 일은 요원해 보인다.

한편, 후자의 사고도 사연이 만만찮게 안습하다.
로켓을 제어하는 프로그램의 내부에는 64비트 float 부동소수점을 16비트 int로 형변환을 하는 루틴이 있었다. 알다시피 이건 양 자료형의 표현 범위의 차이가 엄청나다. 단순히 소수점이 잘리는 것 이상으로 수의 표현 가능한 범위 자체가 잘릴 위험이 높다.

다만, 이전의 아리안 4호에서 이게 별 문제가 된 적이 없었던 관계로 이 부분을 맡은 엔지니어는 앞으로도 오버/언더플로우가 발생할 일은 없다고 판단했다. 그래서 성능 향상을 위해 범위 검사를 하는 옵션을 제외하고 프로그램을 빌드해서 우주선에다 탑재했다.

그런데 아리안 4호와 5호는 로켓의 규격이 서로 달랐으며, 일어나지 않으리라 예상했던 그것이 실제로 일어났다.
완전히 엉뚱하게 형변환된 정수 숫자가 예외 처리도 없이 계산식에 들어가면서 프로그램의 내부 상태는 엉망이 되었으며, 사태 극복을 할 수 없던 컴퓨터 프로그램은 결국 최후의 수단으로 설정되어 있던 자폭 모드로 진입했다. 그래서 아리안 5호 로켓은 발사된 지 겨우 37초 만에 기수를 아래로 숙이면서 추락했다.

중앙 통제실은 싸늘한 초상집 분위기로 변함. 망연자실한 직원들..;; (☞ 동영상 링크)
무인 우주선인 관계로 인명 피해는 없었지만 둘 모두 수억 달러급의 손실을 초래했다. 나로 호의 발사 실패하고도 급이 다른 게, 아리안 5호만 해도 나로 호보다 5배 이상 더 무거운(= 크기도 더 큰) 로켓이었기 때문이다. 그게 고스란히 폭죽으로 전락해 버렸으니.

학부 시절에 소프트웨어공학 수업 시간 때 들은 얘기를 먼 훗날 대학원에서 프로그래밍 언어 수업에서 다른 교수로부터 또 들으니 감회가 새로웠다.
전자 시간에는 체계적인 소프트웨어의 테스트/검증의 중요성에 대해 얘기하면서, 후자 시간에는 프로그래밍 언어 차원에서 타입 검증과 예외 처리의 필요성을 얘기하면서 저것들이 타산지석 사례로 소개되었다.

그나저나 아리안 5호에 들어가는 프로그램도 Ada로 작성되었다고 한다.
Ada에는 배열 첨자 범위라든가 형변환 overflow 예외를 감지하는 기능이 있고, 그걸 끄는 옵션도 별도로 존재한다.
C/C++처럼 무작정 프로그래머에게 모든 걸 맡기기보다는 적당히 언어 시스템이 개입해서 안전을 추구하는 것도 많다 보니 Ada가 프로그래밍 언어계에서는 꽤 noble한 대접을 받는가 보다. 하지만 배열 첨자를 마치 함수 호출처럼 ()로 하고, 명칭에 대소문자 구분이 없는 것은 좀 Basic스럽고 요즘 언어가 아닌 구시대 언어 같은 느낌이 든다.

참고로 Ada는 명칭 자체가 여자 이름인 반면, 코볼은 주 설계자가 수학자 출신의 여성 해군 장성이다(그레이스 호퍼).

Posted by 사무엘

인간이 발명한 교통수단은 그 형태가 자동차(육상-도로), 열차(육상-철도), 비행기(하늘), 그리고 배(물)라는 네 종류로 크게 나뉜다. 각 교통수단은 일반적으로 자기가 다닐 수 있는 형태의 길 위에서만 다닐 수 있는데..
군사 같은 특수한 용도를 목적으로 두 분야의 성격을 동시에 갖는 하이브리드 교통수단도 드물게나마 있다.

1. 자동차+열차

도로도 달릴 수 있고 레일 위도 달릴 수 있는 차량이다.
바퀴에다가 밖으로 툭 튀어나온 채 레일에 닿는 특수한 휠캡을 끼우는 방법이 있고, 아예 레일 주행용 대차를 타이어의 전후에 따로 갖추고 있다가 필요할 때 내리는 방법도 있다. 전자는 사람이 휠캡을 착탈하는 게 골치아픈 일이겠으며, 후자는 엔진 구동축 자체가 도로 바퀴용과 철도 바퀴용이 둘 존재해야 하니 기술적으로 구현하기가 더 어렵겠다.

도로+철도 겸용 차량은 군용 내지 선로 시설 보수용 차량으로 일부 존재한다. 우리나라 군용 트럭들은 특수한 휠캡을 끼워서 유사시에 레일 주행이 가능하다는 얘기를 어디에선가 들었는데, 그게 사실인지 확인은 못 해 봤다.
하긴, 과거에는 굳이 동력 엔진이 없는 인력거나 마차조차도 열차 버전이 없지는 않았다. 오늘날도 관광· 레저용으로 레일바이크가 있고 말이다.

2. 열차+열차

사실은 철도는 길에 대한 제약이 가장 심하기 때문에 도로가 아니라 같은 철도끼리라 해도 궤간이 다르면 차량이 못 다닌다. 우리나라야 육로로 인접하는 나라가 사실상 없는 지형에다가 표준궤 단일 궤간이 잘 정착하여 궤간 혼란이 존재하지 않지만, 당장 러시아의 시베리아 철도만 해도 표준궤가 아닌 광궤이다.

이 문제를 해결하는 전통적인 방법은 한 선로에다가 궤간이 다른 궤조를 동시에 여럿 설치하는 것이다. 전차선이 아니라 협궤/광궤용 제3궤조가 생기는 셈이다. 이건 이것대로 몹시 힘든 일이며, 선로가 분기라도 하는 곳에서는 작업 난이도가 답이 없는 수준으로 치솟는 걸 감안해야 한다.

궤간 문제를 선로가 아닌 차량을 바꿔서 해결하는 방법은 가변궤간 대차를 설치하는 것이다. 틸팅열차가 대차 위의 객실의 기울기를 조절해서 원심력을 상쇄한다면, 가변궤간 대차는 양 바퀴 사이의 간격을 궤간 변경 구간 사이에서 조정한다.
튼튼하게 꽉 고정되어 있어야 하는 부품의 유격이 유동적으로 변하기 때문에 가변궤간 대차는 일반적인 고정형 대차보다 수명이 짧고, 정비불량이 발생할 위험도 있다.

이것도 마치 앞의 도로+철도 겸용 차량처럼 그냥 A궤간용 바퀴와 B궤간용 바퀴를 둘 다 들고 다니면서 필요한 것을 들었다 놓았다만 하는 방법을 생각할 수 있을 텐데, 둘 다 들고 다니기엔 철도 차량의 대차 부품들은 너무 무겁다는 게 흠일 것이다. 일반적인 화차나 객차를 다 그렇게 만들기에는 경제적이지 못하다.

3. 자동차+비행기

사실, 자동차와 비행기는 한 물건에 다 구겨넣기에는 엔진 구조가 서로 너무 다르고 차체/기체의 외형도 차이가 너무 많이 난다. 이런 이유로 인해 flying car 같은 물건은 SF 창작물에서나 볼 수 있는 상상의 산물로 치부돼 왔다.
하지만 엔진 출력이나 차의 덩치, 연비 같은 실용적인 제약이 없다고 치면.. 고정익기와 회전익기 중 어떤 형태가 자동차와의 융합에 더 어울리는지를 먼저 생각할 필요가 있다.

고정익기 겸용 자동차가 있다면 미국처럼 땅 넓은 데서 원래부터 자가용 비행기를 굴리고 살던 부자들이 아주 좋아할 것이다. 한 기계만으로 하늘과 땅에서 모두 장거리 주행이 가능하기 때문이다. 이런 차량은 도로를 달릴 때는 날개를 잘 접어 두는 기능이 있어야 할 것이고 완전한 고정익 비행기처럼 연료를 날개 안에다 집어넣기는 어려울 것이다.
이착륙을 위해서는 온전한 형태의 활주로가 필요하며 타이어 역시 도로 주행뿐만 아니라 랜딩기어 역할도 할 수 있게 아주 튼튼한 고가의 제품을 써야 할 것이다.

하지만 이 비행이라는 게.. 단순히 보조용을 더 원한다면.. 다시 말해 차가 꽉 막히고 있을 때 정체 구간이나 사고 지점만 폴짝 뛰어 넘어갈 수 있고 주차장에서도 옆 차를 밀 필요 없이 원하는 지점에 쏙 드나들 수 있는 걸 원한다면.. 헬리콥터 같은 회전익기 형태의 비행 겸용 차량이 더 유용할 것이다. 고정익기는 뜨고 내리기 위해 활주로가 필요하기 때문에 이런 역할은 할 수 없다.

아니면 아예 자동차용 제트팩이라도? =_=;;
평소에는 제트 가스를 후방으로 분출해서 가속력을 얻는 데 쓰지만 그걸 아래로 분출하면 차를 뜨게 만들 수 있을 것이다. 특수한 용도로 쓰이는 초음속 자동차 같은 건 조금만 개조하면 비행도 가능하지 않을까 싶다.

4. 비행기+비행기

비행기 중에는 뱅글뱅글 돌아가는 바람개비를 고정익기의 프로펠러로도 쓸 수 있고, 회전익기의 로터처럼도 쓸 수 있게 한 '틸트로터' 형태의 하이브리드가 있다. 바람개비가 향하는 각도를 바꾸면 된다.

5. 자동차+배

다음으로 배 이야기를 해 보자.
자동차와 선박 사이의 교배는 '수륙양용'이라는 이름으로 우리에게 상대적으로 친숙한 개념이다. 물론 십중팔구 군용차 형태로 말이다. (1) 물에 뜨지는 못하지만 그래도 방수 처리가 되기 때문에 차체의 대부분이 물에 잠긴 상태에서도 운행 가능한 차, 아니면 아예 (2) 물에서도 뜬 채로 달릴 수 있는 차 이렇게 두 부류로 나뉜다.

(이런 차가 민수용 자가용으로 양산되면 일단 낚시꾼들이 무진장 좋아하겠다. 저 차의 이름은 Python이라고 한다. 전산업계에서는 '파이썬'이라고 명칭이 통일되다시피했는데, 다른 업계에서는 '톤', '손' 등 여러 표기가 혼재하는 듯.)

6. 열차+배/비행기

철도 차량은 그 배타성으로 인해 육지가 아닌 다른 교통수단과의 하이브리드는 사실상 무의미하다. 배는 제끼고 랜딩기어가 철도 차량 형태인 비행기가 있어서 활주로가 철길 형태인 상황만을 한번 가정해 보자.

쇠는 고무보다는 착륙 충격과 마찰열에 더 강하겠지만, 그래도 일반 철길도 매일 유지보수를 해야 하는 판에 레일 활주로가 maintanance-free를 보장해 주는 것도 아니고, 활주로 이탈 사고를 크게 예방해 주는 것도 아니고 딱히 유리한 게 없다. 오히려 쇠로 만들어진 바퀴와 대차는 아무래도 중량면에서 불리할 것이고 착륙 후 제동을 거는 데도 큰 악재로 작용할 것이다.

음, 그나저나 하늘을 날 수 있는 열차라니 은하철도 999 생각도 나고 철덕으로서 이색적인 느낌이 든다.

7. 비행기+배

사실, 20세기 이래로 하이브리드가 가장 잘 발달한 조합은 비행기와 배끼리이다.
지금과 같은 잘 닦인 공항과 활주로가 없던 시절에는 자연적으로 형성된 강, 호수, 바다에서 쉽게 뜨고 내릴 수 있는 비행기가 있는 게 좋았기 때문이다.
또한 옛날에는 엔진 기술이 지금처럼 발달하지 못했던 관계로, 장거리 비행기는 비행 중에 엔진이 퍼져서 망망대해로 떨어질 위험이 높았다. 그러니 이걸 감안해서라도 물에 뜨고 내리는 비행기는 자연스럽게 생각할 수 있는 개념이었다.

먼저, 다리에 바퀴 대신 뗏목이나 스키처럼 생긴 플로트가 달려서 물에 뜰 수 있는 자그마한 수상기(floatplane)라는 게 있다.
그리고 이것보다는 규모가 크고, 동체 자체가 하부가 둥그렇게 생겨서 물에 뜰 수 있는 비행정(flying boat)이 있다.
A380이나 심지어 An-225보다도 더 커서 역사상 가장 거대한 비행기로 간주되는 휴즈 H-4 허큘리스도 비행정이다. (참고로 '휴즈'의 철자가 Hughes인데.. gh는 알다시피 영어에서 발음이 가장 기괴하게 다양한 걸로 악명 높은 철자이다.;;)

하지만 비행기 기술이 발달하고 육지에도 공항과 활주로 시설이 구축되면서 배의 기능을 겸하는 비행기는 인기를 잃게 됐다.
가장 큰 이유는 수상기든 비행정이든, 물에 뜨는 데 쓰이는 장비들이 일단 기체가 하늘로 뜬 뒤부터는 항공역학적으로 아무 도움이 되지 않고 무게만 차지하는 잉여가 되어 비행 가성비를 떨어뜨리기 때문이다.

또한 물에 착륙(응? 륙?)하면 활주로나 랜딩기어 타이어의 정비는 필요 없을지 모르지만, 그래도 착수 충격도 생각보다 크기 때문에 이로 인한 기체의 정비가 여전히 불가피했다. 바닷물이라면 염분 부식 문제도 있고 말이다.

오히려 비행 원리가 적용되어 수면을 수~수십m 남짓 떠서 매우 빠르게 달리는 선박으로는 호버크래프트나 위그선 같은 부류가 있다.
고정익기는 "공기를 거슬러 빨리 달린다 → 날개에 양력이 생긴다"의 순인데 이런 선박의 원리를 설명할 때는 "뜬다 → 물의 저항이 없어서 빨리 달린다"로 순서가 바뀌는 것 같다.
성능면에서 장점이 있지만, 조종을 위해 선박과 항공기 면허가 모두 필요하고 안전 같은 문제가 있어서 이쪽 역시 생각만치 실용화는 못 돼 있다.

* 교통수단간의 이종교배 하나만 생각했는데 글 쓸 것, 생각할 거리가 무척 많고 재미있다.

Posted by 사무엘