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

올해의 마지막 블로그 글은 몇 년 동안 새 글이 없이 먼지만 쌓여 가던 '철도-관련 미디어' 카테고리 소속이 되겠다. 만세~!

내가 맨날 Looking for you 타령만 죽어라고 늘어놓고 있어서 존재감이 많이 묻히긴 했지만.. 옛날(200x년대) 새마을호 열차에서는 Looking for you 음악만 흘러나온 건 아니었다.
열차가 시발역에서 운행을 시작했을 때, 그리고 종착역 도착을 앞두고는 황홀하고 모던하고 미래지향적이고 하이테크스러운 분위기의 다른 BGM이 흘러나왔다. 그러면서 "손님 여러분 안녕하십니까? / 즐거운 여행 되셨습니까?" 요런 안내방송이 나왔다. (☞ 동영상 링크) 본인은 이 BGM을 일명 로고송이라고 불러 왔다. 보통명사 또는 고유명사로 말이다.

초창기에는 출발 때에 한해서 새마을호의 로고송 자체가 Looking for you이던 적도 있었다고 한다. 즉, Looking for you를 배경으로 하고 "손님 여러분 안녕하십니까?" 이랬다는 거다. 이건 각 역별 도착 시각을 일일이 그것도 4개 국어로 다 안내해 주던 시절의 추억인데, 본인은 직접 들어 보지는 못했다. 지금은 KTX에서도 그러지는 않는걸..

그러던 것이 Looking for you 이후에 별도 로고송+안내방송으로 바뀌었다. 종착 Looking for you는 그래도 06년 말 정도까지 유지됐지만 출발 Looking for you는 KTX의 개통 이후에 얼마 못 가 스티브 바라캇 Dreamers로 바뀌었기 때문에 2002년 이래로 길게 잡아도 2년 남짓밖에 유지되지 못했다.

그건 그런데.. 문제는 곡명이 다 알려져서 철덕들의 찬송가로 등극한 Looking for you 말고, 그 고유 로고송의 정체가 무엇이냐는 것이었다.
그 시절에 무궁화호에서 연주되었던 로고송은 CAGNET의 What will I do(원곡은 아닌 듯하고 C장조로 조가 올라간 리메이크)라고 출처가 곧 알려졌다. 얘도 나쁘지 않은 곡이지만 새마을호 로고송 같은 황홀하고 고급스러운 느낌은 없는 게 사실이다.

그리고 새마을호 로고송의 정체는 여전히 오리무중이었다. D장조와 D단조를 오르내리는 그 황홀한 멜로디는 출처가 무엇인지 도무지 알 길이 없었다. 그렇게 철덕들의 의문은 풀리지 않은 채, 로고송은 2008년 무렵부터 다른 곡으로 대체되었다.

본인은 지난 2009년 1월 6일 아침, 서울 교통방송 라디오에서 정확히 같은 음색은 아니지만 로고송의 멜로디가 흘러나오는 것을 우연히 목격..은 아니고 청격했었다. (☞ 옛날 글 링크) 그걸 블로그에 공개했으며 다른 철도 동호인께서 호응하는 댓글까지 올려 주셨다. 하지만 일은 그걸로 끝나고 여전히 정확한 출처를 알아내지 못했다.

오죽했으면 이 사실이 나무위키에도 등재돼 있을 정도였다. (코모넷 항목.. 코모넷은 그 당시 새마을호에 방송 서비스를 제공하던 협력업체. 현재는 폐업함)

그랬는데 그로부터 거의 10년 가까이 세월이 흐른 2018년 12월 17일,
디씨 철갤에서 어느 갤러에 의해.. 이 음악의 출처를 근성으로 "단서를 쫓아 여러 음반 뒤져가며 듣고 또 듣고 생노가다 해가며" 찾아냈다는 소식이 타전되었다!

출처는 바로 Headline News라고, 방송국 BGM용 컴필레이션 음반.. 그것도 엄청 옛날인 1992년 5월에 발매된 음반의 6번 트랙인 Outlook이었다. 이건 우리나라 철덕 역사에 길이 남을 발견이 아닐 수 없다.

라디오나 TV 방송에서 광고나 섹션 전환, 아니면 심지어 방송사고 등 여러가지 상황에서 들려줄 만한 짤막한 BGM들 모음집이다. 이 분야의 음악만 전문적으로 작곡하는 사람도 있는 모양이다.
심각하게 마이너한 분야의 음악인 관계로 전곡이 유튜브 같은 데에 공개돼 있지는 않으며, 인터넷 상으로는 맛보기로 중간 30초 분량밖에 못 듣는다. 하지만 곡 자체도 1분 30초 남짓으로 짧은 편이다.

안내방송 멘트에 가려져서 제대로 듣기 어렵던 구간을 이렇게 음악만 들으니 감회가 새롭다.
게다가 본인이 라디오에서 들었던 곡은 저 앨범의 4번 트랙(Young Blood 젊은 피??)이라는 것도 덤으로 알 수 있었다! 같은 작곡자가 같은 멜로디를 다른 악기와 다른 분위기로 리메이크 해서 연주했던 듯하다.

이 곡의 작곡자(Nicolo Bardoni & Stephen Warr)에 대해서는 새마을호 Looking for you의 작곡자인 MALTA보다도 안 알려져 있고, 하물며 음반은 Obsession보다도 더 구하기 힘들 것 같다.
그래도 출처를 알게 된 것만 해도 어디냐.. 이런 듣보잡 마이너 음반까지 뒤져서 로고송의 출처를 알아낸 그 철갤러 분께 진심으로 경의와 존경을 표하는 바이다. 철덕의 오랜 의문이 이렇게 풀리니 기분 좋게 올해를 마무리할 수 있겠다.

※ 그리고 이미 국내의 어느 용자께서 이 곡의 음원을 구해서 유튜브에 이미 올리셨다.

Posted by 사무엘

1. 송파대로 일대의 시설

송파대로의 잠실 이남 구간이 한때 얼마나 황량했는지는 이 부근에 무엇이 있거나 있었는지를 생각하면 짐작 가능하다.
1980년대에는 논밭과 비닐하우스 부지를 인수하여 가락시장이 들어섰다. 이 부근에는 나름 보안 시설인 전파 관리소도 자리잡고 있었다.
그리고 문정· 장지 일대는 지금 강서구의 마곡 지구와 더불어 서울 최후의 미개발 농경지로 여겨지고 있었다. 198, 90년대까지는 거기에 자동차 학원도 있었다고 한다.

그랬는데 전파 관리소 부지는 지하철역 출구에서 엎어지면 코 닿는 금싸라기 땅이 되어 버렸고 2010년대부터는 그 역이 아예 환승역까지 됐다. (가락시장) 극소수의 전문 인력만이 근무하는 보안 시설답지 않게 시가지와 너무 가까워지고 접근성도 너무 좋아져 버린 것이다. 전파 관리소는 넓은 역세권 부지를 다 활용하지 못하고 상당수를 잔디밭과 테니스장으로 놀려 두고 있다.

철도 쪽을 살펴보면 서울 지하철 4호선의 북쪽 연장과 함께 창동 차량 기지가 이전할 예정이고, 구로 차량 기지도 어디 멀리 못 옮겨서 안달이다. 과거에 용산 역의 넓은 면적을 차지하고 있던 철도 공작창 부지는 앞으로 어떻게 개발되려나 모르겠다.
또한 군부대도 정보사, 특전사 등 서울에 있던 많은 부대들이 이전했으며 이제는 용산 미군 기지조차도 평택으로 이전이 임박해 있다.
이런 시설들의 이전 시기와 맞물려서 전파 관리소도 어디 성남의 산기슭이나 멀리 지방으로 이전하게 될 것 같다.

한편, 가락시장과 그리 멀지 않은 오금 역 인근에 있던 성동 구치소는 문정 법조 단지가 조성된 뒤엔 서울 동부 지방 법원 옆의 동부 구치소로 확장 이전했다. 요즘은 구치소나 교도소를 주변 건물들과도 전혀 이질감이 느껴지지 않게 여느 고층 아파트나 상업 건물과 다를 바 없는 스타일로 만드는 게 유행인 듯하다.

2. 자동차 전용 도로의 고저 위상

서울에 있는 대부분의 한강 공원들은 접근하기가 왠지 어렵고 부담스럽다는 생각이 든다. 굴다리를 통과해야 하고 뭔가 기존 도로들과 입체 교차를 해야 한다.
하지만 여의도 한강 공원만은 자그마한 도로의 옆으로 쏙 내려가기만 하면 부담 없이 갈 수 있다. 심리적인 진입 장벽이 아주 낮게 느껴진다. 왜 그럴까?

다른 한강 공원들은 강변북로나 올림픽대로 같은 거대한 시내 고속화도로의 바로 옆에 있기 때문이다. 그 도로를 횡단해야만 공원으로 갈 수 있다.
그 반면, 여의도는 사정이 다르다. 공원은 여의도에서 한강과 맞닿은 북쪽에 있지만, 올림픽대로는 여의도의 남쪽으로 지난다. 곁에 자동차 전용 도로가 아닌 평범한 시내 도로만 있으니 여의도 한강 공원은 자전거 라이더나 보행자가 접근하기가 상대적으로 더 가깝고 편하게 느껴진다.

그리고 자동차 전용 도로들 중에서 내부순환로는 그 구조상 거의 다 고가이다. 그렇기 때문에 진입 램프는 위로 올라가는 형태로 만들어져 있다.
그에 반해 동부 간선 도로는 중랑천의 둔치에 만들어져 있으니, 장마철 때 종종 침수까지 될 정도로 고도가 낮다. 진입 램프는 당연히 아래로 내려가는 형태이며, 빠져나갈 때는 위로 올라가게 된다.

강변북로는 한강 공원보다는 전반적으로 고도가 훨씬 더 높지만 그래도 한강의 다리들과 교차할 때는 대체로 아래로 지난다. 다만, 잠실대교에서는 동쪽 구리 방면 도로가 다리의 위쪽을 지나기 때문에 예외적으로 더 높다. 무슨 사정이 있어서 다리 아래로 공간을 내지 못했던 모양이다.

그리고 강변북로의 전신은 그냥 본토의 평지이기 때문에, 본토와 접해 있는 서쪽 일산 방면은 의외로 진입 램프 없이 평면으로 곧장 진입하는 곳도 많다. 이것이 동부 간선이나 내부순환로와의 차이이다. 물론 한강과 더 가까운 동쪽 방면으로 진입하려면 아래로 굴다리를 지난 뒤, 한강 공원 쪽의 도로를 거쳐서 진입하는 수고를 감수해야 한다.

3. 주류 기술과 대체 기술

우리나라 고속도로에는 그 이름도 유명한 하이패스라는 무정차 자동 요금 정산 시스템이 있다.
그런데 가끔은 하이패스가 안 달린 차가 실수로 하이패스 출입구로 들어가 버릴 때가 있고, 하이패스 장착 차량이라도 인식이 제대로 안 될 수가 있다.

본인도 자세한 내막은 잘 모르지만, 이럴 때를 대비해서 무인 톨게이트에서는 하이패스 이외의 다른 방법으로 통과 차량의 번호판을 판독하기도 하는 것 같다. 그런 상황에 대한 대비가 돼 있으니까 도로 공사에서는 미납 통행료 청구서를 추후에 차주에게 보낼 수 있는 것이다. 그리고 하이패스가 인식되지 않았더라도 세상이 끝장난 게 아니니 당황하지 말고 제발 급제동 급조향 하지 말고, 안전을 위해 일단은 지나가라고 운전자를 안심시킬 수도 있다.

사실, 하이패스 없이 차량을 무인으로 자동 인식하는 기술 자체야 전국의 수많은 번호판 인식 주차장들과 과속· 신호 단속 무인 카메라를 생각해 보면 아무런 문제가 없다. 고속도로 시설에서 그런 인프라를 갖추면 될 일이지, 운전자들에게 비싼 돈 들여 하이패스 단말기를 번거롭게 장착하라고 홍보할 필요가 없다.

하지만 그것만으로는 미덥지가 못한지, 아니면 이미 계약을 맺은 단말기 제조사들과 담합을 한 게 있기라도 한지, 우리나라 고속도로는 여전히 하이패스가 주류이고 그런 간편한 대체 수단은 전체 트래픽의 1% 이내의 보조 비상용으로만 활용하는 듯하다.

한편으로, 대통령 선거에서도 저렇게 비슷하게 '주류 기술'과 '대체 기술'의 관계에 있는 시스템이 보인다.
옛날에는 대선 당일에 자기 주민등록지에서 투표를 할 수 없는 사람들을 위해서 부재자 투표라는 게 따로 있었다. 이건 미리 부재자 등록을 해야 했다.

그런데 요즘은 기술이 좋아졌는지.. '사전 투표'라고 해서 당일 투표를 할 수 없으면 사전 등록 없이 아무나, 그것도 전국 아무 투표장에나 가서 미리 투표를 해도 된다.
이게 가능해졌을 정도면 아예 선거 당일과 사전 투표일의 구분을 없애도 될 것 같은데.. 그렇지는 않을 것이다.

전국민이 사전 투표일에 아무 데서나 투표를 해 버리면, 투표 용지도 on-demand로 뽑아야 하고 행정적으로 발생하는 무질서도를 감당하기가 아마 어려울 것이다. 모든 차량들이 하이패스 단말기 없이 하이패스 톨게이트를 통과해 버릴 때처럼 말이다.

우리나라도 궁극적으로는 전국의 고속도로들에 톨게이트가 없어지고 하이패스 단말기도 없어지고, 고속도로 통행료는 월말에 고지서 형태로, 아니면 차주의 카드 요금이 매월 결제될 때 일괄 청구되는 게 순리에 맞지 싶다. 일일이 하이패스 카드에 충전을 하거나 아니면 선수금을 쳐묵쳐묵 하는 자동 충전 카드는.. 많이 삽질스럽다.
그리고 전자 투표인지 뭔지가 도입될지 모르겠지만, 투표도 시간· 공간 제약이 갈수록 더 없어지는 쪽으로 가기는 할 것이다.

4. 아직도 4차로인 경부 고속도로 구간

난 경부 고속도로에 2010년대까지 남아 있던 최후의 오리지널 4차로 구간은 울산-경주-영천뿐인 줄로 알았다. 거기도 수 년 전부터 6차로 확장 공사가 시작되었기 때문에 그게 끝나면 경부 고속도로는 전구간이 최하 6차로 이상으로 탈바꿈하는 셈이다.

하지만 사실은 그렇지 않더라. 아직도 4차로이고 심지어 확장 공사조차 시작하지 않은 구간은 영동-옥천 사이에 더 있다. 거기가 경부 고속도로 최후의 4차로 구간이다. 마치 철도에서 경부고속선 때문에 경부선 기존선의 전구간 전철화가 오히려 늦어졌듯, 경부 말고도 다른 대체 고속도로들이 많이 생겼기 때문에 경부 자체의 전구간 확장이 작업의 우선순위가 낮아진 것이다.

다만, 영동-옥천 일대는 2000년대 초에 대대적으로 선형 개량을 한 적이 있으며, 이때 커브를 워낙 많이 편 덕분에 무슨 지방도도 아닌 고속도로가 길이가 약간 짧아지기도 했을 정도였다. 그리고 이 새 길은 비록 지금은 4차로를 유지하지만 미래의 확장 공사를 염두에 두고 노반도 미리 확보해 놓은 상태라고 한다.

그러니 저기는 1970년 개통 당시의 오리지널 선형이 "아닌" 4차로이다.
그에 반해, 영천-경주-울산은 확장 공사가 시작되기 전에는 진짜로 1970년 개통 당시의 선형을 그대로 간직한.. 정말 시간이 정지한 4차로였다.

경부 고속도로는 대구나 대전 같은 대도시 주변은 얄짤없이 8차로이고, 수도권에서는 아예 10차로에 육박하는 거대한 도로이다. 주변의 중부내륙이나 타 횡축 고속도로 같은 4차로 도로를 달리다가 경부로 진입하면 경부의 그 어마어마한 도로 폭에 압도당하게 된다.
그런데 그 경부조차도 6차로도 아닌 4차로 구간이 있다니, 거기는 경부 고속도로라는 게 실감이 안 날 것 같다.

Posted by 사무엘

1. 21년 전, 기성 교회에서의 크리스마스 성극 추억

지금으로부터 21년 전인 1997년 말, 본인은 중학교에서의 마지막 겨울방학을 맞이하고 있었다.
그때 본인이 다니던 교회 중고등부에서는 지도교사 선생님의 주도로 크리스마스 이브 행사 때 무려.. 뮤지컬을 공연했다. 연극을 하다가 노래가 나올 때면 MR 틀어놓고 그에 맞춰 부르는 거다.

그 뮤지컬의 맨 처음 도입부에서 불렀던 노래가.. 기억에 남아 있는 가사를 검색해 보니 '마리아의 아기 예수'라는 곡이고 가사가 다음과 같다.
국내곡인 것 같지는 않은데.. 원곡의 제목과 가사는 무엇인지 정체를 알 길이 없다.

지금 내가 다니는 교회에서라면 이런 컨텐츠는 심의상 공연 불가일 것이다.
이 진영에서는 '아기 예수' 이런 말 별로 안 좋아한다. 산타 클로스, 크리스마스 트리, 12월 25일 예수 생일 이런 거 다 생깐다. 그런데 그걸로도 모자라서 '마리아의 아기 예수'라니! 이런 OO교스러운 심상이 담긴 용어는 절대 용납될 수 없다.

성도들 중에 심지어 "메리 크리스마스"라는 인사말조차 싫어하는 프로불편러도 있기 때문에, 저런 게 버젓이 공연되었다가는 곧장 클레임 들어온다.

뭐 난 그 정도까지는 아니다. 성탄절이 잘못된 거지, 예수 그리스도의 성육신 탄생 자체가 잘못된 교리는 아니지 않는가? 그리고 12월 25일이라도 쉬는 나라가 안 쉬는 나라보다는 나으며, "메리 크리스마스"가 "해피 할리데이" 이딴 말보다는 훨씬 낫다고 생각한다. 고로 본인은 트럼프 대통령의 노선을 지지한다.. =_=;;;

그 뮤지컬은.. "크리스마스 추억"이라는 주제로 그 안에서 또 세 갠가 네 개의 에피소드로 구성돼 있었다. 어떤 에피소드에서는 주인공이 평소에 짜장면을 미치도록 너무 좋아해서 크리스마스 성극을 공연하던 중에도 "손님, 짜장면은 뭘로 드시겠습니까?"라고 NG를 낸 이야기가 있었다.

성탄절의 유래고 뭐고 교리 지식 다 제끼고 동심, 감성, 추억만 생각하면 저런 게 참 훈훈한 기억이다. 그 뮤지컬 각본을 다시 볼 수 있다면 좋겠다. 허나, 그런 긍정적인 심상이 어째 이교도의 전통과 혼합되어 변질되었는지를 같이 생각하면 안타까운 노릇이 아닐 수 없다. 빨간 싼타 모자 쓰고 열심히 율동 가르치는 주일학교 교사들 동영상도 검색하면 많이 나오는데.. 착잡함과 안타까움이 교차한다. ㅠ.ㅠ

주일학교라는 게, 그 당시에는 꼬마들이 그냥 아무것도 모르고 선생님하고 같이 노래 부르고 떠들고 놀지만, 그게 커서까지 추억으로 각인되는 효과를 노린다. 그러니 유아 교육이 유치하고 시시하고 당장 지쩍으로 드러나는 효과가 없는 것 같아도 실제로는 중요한 역할을 하는 셈이다.

물론 나의 동심, 감성, 추억 분야의 결정판은.. 더 말하자면 입만 아프겠지만 2003~04년에 접한 새마을호 Looking for you이다. 요한계시록을 끝으로 신구약 성경이 완결되었듯이 Looking for you가 그냥 영원한 종지부를 찍었다.
국영 독점 교통수단에서 이런 음악이 흘러나왔다는 것은 충격 중의 충격으로 나를 철덕의 블랙홀로 빨아들이게 했다. 이걸 능가하는 충격은 내 인생에 다시는 등장하지 않을 것이다.

2. 나의 사랑하는 책 비록 해어졌으나

얘는 성경을 소재로 하는 얼마 안 되는 찬송가 중 하나이다.
완전 동요풍인 "신구약 성경책 (The B-I-B-L-E oh that's the book for me)" 다음으로 조금 나이가 들면 주일학교에서도 접하게 된다.

"나의 사랑하는 책"은 영어로 가사 첫 줄은 There's a dear and precious book..이고 원제는 My mother's bible이다.
"비록 해어졌으나"를 "비록 헤어졌으나"라고 ㅐ를 ㅔ로 잘못 기재한 책이나 사이트가 의외로 굉장히 많다. 구글 같은 검색엔진들에서 자동 완성이 '헤어졌으나'라고 제시될 정도다.
영어 가사가 Tho' it's WORN and faded now이니, 우리말로도 worn out을 뜻하는 '해지다'가 맞다. 어머님의 성경책이 다 낡은 채로 남아 있기라도 하냐, 아니면 영영 잃어버렸거나 심지어 빼앗겼냐의 차이이다. 후자라면 작사자는 젊었을 때 신앙을 잃었다가 탕자의 아들처럼 되돌아온 것일 수도 있게 된다..;;

한편, 이 찬양은 3절 가사가 "어머님이 읽으며 눈물 많이 흘린 것 지금까지 내가 기억합니다"
즉, 우리말로는 어머님이 우셨다고 번역되어 있다.
하지만 원래 가사는.. "Then she dried my flowing tear with her kisses as ..."
"내가 울었고" 어머니께서 내 눈물을 닦아 주셨다는 뜻이다..;;
물론 단위 음절당 들어갈 수 있는 정보량이 한국어와 영어가 서로 쨉이 안 되니, 이런 보정은 오역이나 변개는 아니다. 단지 다르다는 것이다.

2절 가사도.. 우리말은 다니엘, 다윗, 엘리야가 언급돼 있지만 원래 가사는 엘리야가 아니라.. '요셉'이 언급돼 있다. 뭐, 요셉보다는 엘리야가 더 포스가 있는 인물인 건 인정한다만..
엘리야가 "병거를 타고" 무슨 은하철도 999처럼 하늘에 올라갔다는 가사는 약간 고증 오류이다.

왕하 2:11을 보면, 불길에 활활 타는 모양의 병거가 나타났다고만 했지, 엘리야가 그 행렬에 직접 합류하거나 병거를 타고 승천했다는 말은 없다. 그냥 혼자 몸뚱이가 회오리바람에 휩쓸려 승천했다.
영어 가사는 애초에 엘리야를 언급하지 않으니 이런 오류도 존재하지 않는다.

3. 나는 인생의 산과 들 방황하며

위의 제목으로 오랫동안 방황하며 인생을 허비하다가 뒤늦게 예수 믿고 구원받게 된 기쁨을 노래한 찬송가가 있다.
얘는 작사· 작곡자가 따로 전해지는 외국곡인데, 원곡은 애초에 찬송가가 아니었다. 그냥 "그대를 향한 사랑 영원할 것이오"라는 내용의 일반 노래이다. 우리말 가사는 영어 가사와는 무관하며 완전히 새로운 창작이다.

그러니 이 곡은 찬송가로서는 Believe me if all those endearing young charms 같은 원제를 기재해 줄 필요가 없다.
"마귀들과 싸울지라 죄악 벗은 형제여" 곡에다가 "존 브라운의 시체" 영어 가사를 병기할 필요가 없듯이 말이다. 그건 그렇고..

"나는 인생의 산과 들 방황하며"의 마지막 2절 가사 끝부분은 "시냇물 흘러 바다에 돌아가듯 나는 주 안에 잠겨지네"이다.
이 찬송을 부르면서 본인은 늘 궁금했다. 가사를 쓴 사람이 졸업식 노래를 참고하기라도 했는지 말이다.

졸업식 노래의 3절 끝부분은 "냇물이 바다에서 서로 만나듯 우리들도 이 다음에 다시 만나세"인데..
찬송가 가사에 저런 냇물-바다 비유가 들어갈 일이 얼마나 될까..??
그리고 "주 안에 잠겨지네.."는 침례도 아니고 도대체 어떤 심상을 의도한 것일까? 누가 무슨 동기를 받아서 이런 가사를 썼는지가 무척 궁금해진다.

4. 지금까지 지내 온 것

"지금까지 지내 온 것 주의 크신 은혜라..."라는 찬송가가 있다. 가사의 특성상 간증 집회나 연말 송구영신 때, 혹은 교회 창립 기념 예배 때 두루 부르기 좋다. 극동 방송 발 카더라 통신에 따르면 한국의 크리스천들이 가장 좋아하는 찬송가 조사에서 당당히 2등을 차지했다고 한다.

얘는 "복의 근원 강림하사"와 동일한 외국곡 멜로디가 붙어 있는데, 그것 말고 박 재훈 작곡의 민요풍 멜로디 버전도 있다. 이 작곡자에 대해서는 "어서 돌아오오"의 작곡자라고 얘기해 주면 한국인이라면 다들 고개를 끄덕일 것이다.
둘 다 3박자 계열인 건 동일하며, 우리나라 찬송가에는 두 곡이 모두 실려 있다.
한국곡 멜로디는 "부름 받아 나선 이 몸"과 분위기가 꽤 비슷하게 느껴진다만.. 그래도 "부름 받아..."의 작곡자는 다른 인물이다.

"지금까지 지내 온 것"의 멜로디 말고 가사의 출처를 살펴보면 굉장히 흥미로운 점이 발견된다.
본인도 굉장히 최근에 알게 된 건데.. 얘는 한국인 작사는 당연히 아니고 그렇다고 찬송가들의 대부분을 차지하는 미국· 유럽 계열도 아니다.

이 곡의 작사자는 보통 T. Sasao라고 소개돼 있는 편인데, 일본인이다. '사사오 데쓰사부로'(笹尾鐵三郞 1868-1914)라고 메이지 시대를 주로 살았던 성결교 목사이다. 데쓰(tetsu)는 '철'의 일본어 음일 뿐이며 death하고는 당연히 무관하다.
영어 가사가 멀쩡히 기재돼 있어서 일본인 작사가 아닌 것 같지만 이것 역시 일본어로부터 나중에 번역된 것이다.

이 곡의 진짜 원어 가사는 이렇다. きょうまで守られ
일본어를 모르는 본인이 보기에도.. 1절 지금(今日)까지 지내 온 것, 2절 몸과 맘도 연약하나(か弱き者を), 3절 주님 다시 뵈올 날이(主の日) 등 우리말과 일본어가 앞부분이 얼추 일치하는 것 같다.

사사오 데쓰사부로가 작사한 다른 대표적인 찬송가로는 "우리들의 싸울 것은 혈기 아니요"가 전해진다. March we onward 이렇게 시작하는 영어 가사가 있지만, 외국 사이트에서 검색이 잘 되지 않을 것이다. 어쩐지 옛날 가사는 '일심'도 그렇고 약간 일본어스러운 표현이 있더라. 그래도 저 사람은 "지금까지 지내 온 것"의 작사자로 훨씬 더 많이 알려져 있는 듯하다.

다만, 이해가 되지 않는 것은 "나 위하여 십자가에 중한 고통 받으사.."이다.
"My life flows on in endless song; (...) How can I keep from singing?"이라고 Robert Lowry 작사의 가사가 분명히 전해지는데..
우리나라 찬송가에는 동일 멜로디에 "My life flows rich in love and grace (...) How can I keep from singing?"이라는 비슷하지만 약간 다른 가사와 함께 T. Sasao가 기재돼 있다. 작사자가 잘못 기재된 것 같은데 제2의 영어 가사는 정체가 뭔지 궁금해진다.

이런 식으로 오늘날 교회에서 불리는 찬송가들의 출처와 계보, 탄생 배경들을 연구해 보는 것도 무척 재미있다. 성경으로 치면 주석을 같이 보는 것과 같다. 계보가 의외로 복잡하고 배배 꼬인 것, 전혀 찬송가가 아닌 멜로디에다가 번역이 아닌 창작 수준의 가사가 붙은 게 많다. 옛날에는 지금처럼 곡들의 출처를 구글 검색 한 번으로 바로 알 수 있지 않고, 또 저작권에 대한 개념도 정립되지 않았으니 말이다.

Posted by 사무엘

Windows API에서 LoadCursor는 EXE/DLL 실행 파일의 리소스로부터 마우스 포인터를 얻어 오는 함수이다. 아니면 모듈 핸들 값을 NULL로 생략하면, 시스템이 제공하는 다양한 공용 포인터를 얻을 수도 있다. 일반적인 화살표 아니면 모래시계, 텍스트 입력란용 I-beam 등등 말이다.

그런 known 포인터의 명칭은 IDC_ARROW, IDC_IBEAM, IDC_WAIT ... 등으로 10여 종이 WinUser.h에 정의돼 있다. 실제값은 그냥 32xxx대의 리소스 ID 정수이다.

그런데, 제어판의 마우스 포인터 설정에 나열되어 있는 공통 포인터 중, 유일하게 IDC_* 명칭이 전혀 부여되지 않은 포인터가 하나 있다. 바로 펜 모양의 필기 포인터이다.
MSDN 문서와 WinUser.h를 눈을 씻고 찾아 보시라. 무려 Windows 95 이래로 제어판에 버젓이 등재되어 온 표준 공통 포인터임에도 불구하고 이름이 없다. 신기하지 않은가?

사실, 이 펜이랑 xor 반전 십자가인 IDC_CROSS(정밀도 선택), 그리고 IDC_UPARROW(대체 선택)는 응용 프로그램에서 거의 볼 일이 없긴 했다. =_=;;

그래서 본인은 장난기가 발동했다.
1부터 65535까지 brute-force로 LoadCursor 요청을 해서 문서화되지 않은 마우스 포인터가 돌아오는 게 있는지 역대 Windows 운영체제별로 확인을 해 봤다.

결과는 꽤 흥미로웠다.
답부터 말하자면 펜 모양은 32631이라는 ID가 홀로 부여되어 있었다. Windows 95부터 10까지 동일하게 사용 가능하다.
'홀로'라는 말은 인접한 32630이나 32632 같은 숫자에는 포인터가 배당된 게 없다는 뜻이다.

모든 Winows에는 100부터 11x번에 완전 기본 마우스 포인터가 할당되어 있었다. 즉, Aero 포인터를 쓰고 있더라도 여기에는 완전 운영체제 기본 흑백 화살표 포인터들이 있으며, 얘들은 포인터 뒤에 입체감을 주는 그림자도 표시되지 않았다. 이건 무슨 다른 특수한 용도로 쓰이는가 보다.

그리고 IDC_HELP 다음으로 32652부터 32662 사이에 있는 11개의 포인터는.. 놀랍게도 마우스 휠을 눌러서 자동 스크롤 모드가 됐을 때 나타나는 '작은 원 + 검은 삼각형'들이었다(각 방향별로). 그것도 휠이 운영체제 차원에서 정식 지원되기 시작한 Windows 98부터 20년째 동일한 형태로 존재하고 있었다. 이건 기술적으로는 user32.dll에 존재하는 리소스이다.

그런데 이런 걸 도대체 왜 문서화하지 않았을까? Windows 98부터는 하이퍼링크용 IDC_HAND만 추가됐다고 달랑 써 놓고 입 싹 씻은 걸까..? 뭔가 단단히 속은 느낌이었다.

본인은 당장 날개셋 한글 입력기에다가 조치를 취했다.
날개셋 한글 입력기는 16년 전(2002...)에 나온 2.0 이래로 지금까지 자동 스크롤 모드용 마우스 포인터들을 내장하고 있었다. 그걸 모두 제거하고, (1) 운영체제가 비공식적으로 제공하는 이 포인터를 사용하게 했다. 그래서 파일 크기가 4~5KB 남짓 감소하는 효과를 얻었다.

(2) 그리고 최근에 추가된 필기 인식 입력 도구에서 마우스를 그리기 입력란 내부로 가져가면 포인터가 펜 모양으로 바뀌게 했다. 뭔가를 그리면 된다는 것을 강조하기 위해서이다.
결과물을 보니 만족스럽다. 이 달 초에 나온 9.61 버전에 바로 요 사항들이 반영되었다.

이것 말고 문서화되지 않은 포인터로는 32663이 있는데, 일반 화살표 포인터 옆에 모래시계 대신 의외로 CD 아이콘이 자그맣게 붙어 있다.
광학 드라이브가 백그라운드에서 뭔가 돌아가고 있을 때 표시되는 듯하며 본인도 이걸 본 기억은 있다. 하지만 정확한 표시 조건은 잘 모르겠다.

차라리 화살표 옆에 점선 사각형 내지 [+]가 붙어서 drag & drop을 나타내는 포인터가 더 자주 쓰이며, 공통 포인터로 등재됐으면 좋겠는데 얘들은 그렇지 못하다. 그냥 ole32.dll에 하드코딩된 리소스가 쓰인다. 그리고 창 전체의 크기 말고 창 내부의 splitter 구획의 폭을 조절할 때 바뀌는 포인터도 창 크기 조절용과는 다른 걸 쓰는 게 UI 디자인상으로 맞는데 그것들 역시 공통 포인터에는 없다. 그렇기 때문에 여전히 싸제 자체 내장에 의존하거나, 아니면 comctl32.dll에 하드코딩된 리소스를 슬쩍 가져오는 게 통용된다.

아무튼, 오늘은 마우스 포인터와 관련하여 새로운 사실을 알게 됐다.
그러고 보니 옛날에 16비트 시절에는 메모리 공간이 엄청나게 부족하기도 하고, GDI 핸들의 번호 영역 자체가 몇 만 남짓밖에 안 되었다. 그러니 Windows 3.1뿐만 아니라 9x에서도.. 아까 본인이 했던 것처럼 1부터 65535까지 brute-force 식으로 대입해서 시스템에 현재 존재하는 비트맵· 아이콘 따위를 몽땅 나열하고 조회하는 툴을 만드는 것도 가능했다.

오늘날 32/64비트 시대에도 DLL의 심벌 ordinal 번호와 리소스 ID 번호는 16비트 영역으로 한정돼 있다. 이 둘에서는 숫자와 문자열이 식별 용도로 모두 쓰이며, 16비트를 초과하는 큰 숫자는 문자열 포인터인 것으로 간주되게 의미가 예약돼 있기 때문이다.

Posted by 사무엘

지난 11월 초엔 하늘은 맑고 푸르고 산과 들은 단풍으로 물들어 가는 게.. 혼자 집에 틀어박혀 있기에는 너무 아까운 날씨였다.
그래서 9월에 중순에 갔던 남양주를 다시 찾아갔다. 먼저, 와부읍 월문리에 소재한 먹치고개 쪽을 돌아다녀 봤다.

단풍이 드니 경치가 몹시 아름다웠다. 딱 1년 남짓 전에 남한산을 갔을 때도 풍경이 이랬었다.
"나뭇잎도 다들 적화... 어?? 아, 내가 종북좌빨들 때문에 망해 가는 나라를 보며 심성이 어지간히도 피폐해졌구나" 하는 생각이 들었다.

여기 일대는 한적한 시골답게 주차 걱정 없이 갑산을 오르는 등산로가 있었다. 그런데 웬일인지 울타리가 쳐지고 막혀 있었으며, 길이 아닌 곳엔 아예 전기 울타리가 둘러져 있기도 했다. 흐음..;;
그래서 그냥 경치 구경만 하다가 재작년에 올랐던 예봉산을 다시 올라 보기로 결심했다. 여기도 등산로 바로 코앞에다 차를 세워 놓을 수 있어서 차량 접근성이 좋았다.

정상까지 가는 길에 이 정도로 하늘이 뚫린 공터가 나온 건 여기가 거의 유일한 듯했다.
그것 말고는 예봉산은 2년 전이나 지금이나 별로 볼 것 없었다.

드디어 정상에 도착했다. 2년 전과 동일한 경로로 1시간 반쯤 걸렸는데.. 그 동안 운동을 게을리 해서 그런지 2년 전보다 더 힘들다는 느낌이 들었다. 아, 공사 때문에 일부 등산로가 우회 경로로 바뀌기도 했다.

주변은 그때나 지금이나 계속해서 뭔가 공사가 계속되고 있었는데, 등산로를 새로 내거나 목재 데크라도 설치하는 게 아니었다.
여기 정상에도 마치 관악산 정상 근처처럼 동그란 관측 레이더가 설치될 거라고 한다..! 그때 만들던 길은 사람이 지나가는 길이 아니라 공사 자재를 실어나르기 위한 모노레일이었다.

하긴, 여기도 관악산과 비슷한 해발 650m대이고 얘가 관악산보다 더 높기까지 하다. 하지만 얘는 바위가 전혀 없는 흙산인 덕분에 등정 난이도는 관악산보다 훨씬 낮았다.

시간대가 시간대여서 그런지, 저 사진을 찍던 당시에 산 정상에는 본인 포함 총 여섯 명이나 있었다.
산에서 마주친 등산객 어르신들은 저 구조물 때문에 정상 경치가 많이 가려졌다며 아쉬워하셨다. 일행 중에는 아침 일찍 운길산부터 시작해서 하루 종일 산행을 진행하신 분도 있었다.

산 정상에서 아래를 내려다보니, 지상에서 올려다볼 때보다는 하늘이 마냥 맑지 않고 뿌연 게 보였다.

차가 있는 곳으로 되돌아가야 하니, 더 멀리 나가지 못하고 하산은 등산의 정확히 역순 경로로 했다. 앞으로 기회가 되면 예봉산 근처의 예빈산, 운길산, 갑산, 적갑산 일대도 가 보고 싶다.

그로부터 1주일 남짓 뒤, 나라 전체가 웬 미세먼지 테러를 당했다가 하루 종일 여름 장마 같은 비가 내리면서 공기가 맑아졌다. 본인은 이때를 놓치지 않고 야영을 했다. 다만, 멀리 나가지는 못하고 그냥 동네 뒷산의 정자에다가 텐트를 쳤다. 비 소리 듣고 풀 냄새 맡으면서 나만의 공간에서 밤을 보내다니, 정말 꿀잼이었다.

야영을 마친 뒤엔 오랜만에 성남으로 가서 예전에 올랐던 망덕산을 올라 봤다. 작년 봄이니 지금으로부터 1년 반쯤 전이다.
서울 303과 9403번 버스의 종점인 동성 교통 차고지에서부터 시작해서 이배재 고개를 버스 대신 도보로 올랐으며, 고개 정상에서부터 등산로에 진입했다. (이배재 고개를 내 자가용으로 통과한 적은 없음)

나무들은 다들 잎이 떨어져서 가지만 앙상했으며, 길바닥은 낙엽으로 뒤덮여 있었다. 온통 초록색이던 작년과는 분위기가 확 달랐다.

망덕산 정상 표지판을 다시 지나쳐 갔다. 예봉산 등 여느 산과는 달리, 정상만을 위한 공간이 따로 있는 게 아니라 그냥 등산로 길목에 정상 표지판이 있다.

본인은 예전에는 검단산과 망덕산을 쭉 일주했었다. 하지만 이번에는 그렇게 하지 않고 조금 더 가다가 사기막골 방면으로 하산했다.
여기는 다니는 사람이 별로 없어서 그런지 등산로도 좁고 험한 편이었다. 하지만 얼마 전에 비가 온 덕분인지 언제부턴가 골짜기에서 물이 졸졸 흐르는 소리가 들리기 시작했다. 오옷~!

성남과 광주 사이의 산에서 물 흐르는 걸 구경하는 건 처음이었다.
하산을 계속할수록 물줄기는 더 커졌다.

최종적으로는 대원사라는 절에 도착하는 걸로 산행이 끝났다.
사기막골은 성남시에서 손꼽히는 오지라고 한다. 하지만 그렇게 막 시골 같지는 않았으며, 주변의 집들은 단독주택보다는 빌라 위주였다.

대원사를 벗어나니 '사기막골 근린공원'이 나왔다. 여기는 난생 처음 가 봤다.
'사기막'에서 '사기'는 도자기 그릇을 뜻한다. 여기가 옛날에는 도자기 굽는 제조업으로 유명했던가 보다.
그래서 공원에는 민속촌처럼 한옥 마을이 꾸며져 있으며, 도자기 체험관도 있었다.

남양주에 이어 성남에서는 이런 걸 구경하면서 추억을 남겼다.
성남 구시가지 쪽은 정말 경사가 급한 동네라는 게 거듭 느껴졌다. 지금처럼 개발되기 전에는 이런 언덕도 다 들판과 숲이었지 싶다. 그나마 성남대로가 지나는 분당과 판교 쪽이 평지... 아, 그것도 아니고 가천대-태평 사이는 지상이 경사가 장난이 아니다.

그리고 남양주와 성남은 둘 다 면적이 넓고, 지형에 따라 생활권이 많이 찢어져 있긴 하다. 하나도 개발 안 된 산기슭 오지가 있는가 하면, 전철이 지나고 아파트와 고층 빌딩이 잔뜩 지어진 곳도 있다. 또한, 성남과 광주 사이의 산맥처럼 남양주 동쪽의 산맥도 탐험하기 좋겠다는 생각이 들었다.

Posted by 사무엘

C++에는 using이라고.. class, namespace, template, virtual, operator 이런 것보다는 좀 생소하고 덜 쓰이는 키워드가 있다.
일반적인 프로그래머라면 타이핑 수고를 덜기 위해서 using namespace std; 정도 선언할 때나 사용했던 게 전부일 것이다.

얘는 C의 키워드로 치면 그나마 typedef와 성격이 얼추 비슷해 보인다. typedef는 여러 토큰으로 구성된 복잡한 타입 명칭을 한 단어(식별자) 한 토큰으로 축약해 준다.
타입 명칭이란 건 unsigned long처럼 예약어만으로도 두 단어 이상으로 구성될 수 있으며, 포인터형 *이라든가 const/volatile modifier 등이 붙어서 더욱 복잡해질 수 있다.

그러니 이런 걸 축약하는 기능은 단순히 토큰을 기계적으로 치환하는 #define 전처리기 계층이 아니라 컴파일러 계층에서 반드시 필요하다. 가령, PSTR a, b를 char *a, *b로 자동으로 인식되게 바꾸는 것은 #define만으로는 문법적으로 불가능하기 때문이다. 더구나 함수의 포인터 타입은.. 가리키는 함수가 받아들이는 인자들의 개수와 타입을 일일이 그런 식으로 나열해야 한다~!

C에서는 구조체형 변수를 선언할 때 반드시 struct를 일일이 붙여서 struct ABC 이런 식으로 선언해야 했다. struct를 생략하고 바로 ABC 한 단어만으로 쓰려면 이것조차도 typedef를 해 줘야 됐다.
그러니 C에서는 구조체를 typedef struct _ABC { ... } ABC; 이렇게 두벌일을 하면서 선언하는 게 관행이었으나..

C++에서는 객체지향 이념이 강화되면서 번거롭게 typedef를 안 해도 struct/class를 생략하고 곧바로 그 타입을 쓸 수 있게 됐다. 사실 이게 당연하고 더 자연스러운 조치가 아닌가 생각한다.

뭐 아무튼 typedef는 그런 중요한 역할을 하는 물건이다.
typedef를 통해 새로 만들어진 명칭은 사람이 보기에만 서로 다를 뿐, 컴파일러의 입장에서는 서로 완전히 동치이다. 전문 용어로 표현하자면 syntactic sugar이다.

내부적으로 담고 있는 물건은 동일하지만(똑같은 정수??) 서로 다른 타입으로 취급되어서 명시적인 형변환 없이는 서로 덥석 대입되지 않는 파생 타입.. 이런 걸 생성할 수 있으면 좋을 텐데 C/C++에서는 그게 쉽지 않다.
그러니 unsigned short/int와는 미묘하게 다른 wchar_t 같은 타입은 컴파일러가 언어 차원에서 직통으로 지원해 주지 않으면 사용자가 만들어 내기 난감하다.

그리고 HWND, HMODULE처럼 서로 호환되지 않는 다양한 핸들 타입도 내부적으로는 dummy 구조체의 포인터형을 일일이 typedef하는 편법을 동원해야 선언할 수 있다.
마치 include guard 삽질을 대체하기 위해 #pragma once가 사실상의 표준 형태로 등극한 것처럼.. 저것도 앞으로는 C++ 언어 차원에서 개선되어야 할 점이 아닌가 한다. 정수형에 대해서는 부분적이나마 type safety를 강화하려고 정수와 무작정 호환되지 않는 enum class 같은 것도 2010년대 들어서 도입된 바 있다.

아무튼, typedef는 통상적인 사유로 인해 길어진 type 명칭을 한데 줄이며, 축약된 명칭을 현재의 scope에다 도입해 준다.
그런데 using도 긴 명칭을 줄여 준다는 점에서는 역할이 비슷하다. 단지 그 배경이 typedef와는 완전히 다를 뿐이다.
바로, 지금 문맥과는 다른 namespace에 속한 명칭을 일일이 namespace를 명시하지 않고도 곧장 참조 가능하게 해 준다. 뭐, 개념은 그러하지만 구체적인 세부 문법과 용례는 생각보다 복잡하며, 본인 역시 이를 다 정확하게 알지는 못한다.

using은 크게 선언(declaration)과 지시(directive)라는 두 형태로 나뉘어서 문법적으로 서로 다르게 취급된다. 전자는..

using std::vector;

이런 식으로 구체적인 명칭을 써 주는 형태이다. 위의 경우 이 scope에서는 이제 앞에 std::를 안 붙여도 vector 클래스를 쓸 수 있게 된다. 사용되는 곳이 클래스의 내부라면 굳이 namespace 말고 기반 클래스 같은 타 클래스의 이름이 들어와도 된다.

std::vector를 vector로 줄여 쓰는 것은 기존의 #define이나 typedef로 가능하지 않다. 특히 typedef의 경우,

typedef std::vector<int> vector; //????

템플릿 인자가 모두 주어져서 온전한 type으로 실현된 놈이라면 저렇게 단축 명칭을 부여할 수 있겠지만, 그렇지 않은 추상적인 명칭을 축약하지는 못하기 때문이다. C++의 상속과 연계를 위해 dynamic_cast가 도입된 것처럼, C++에서 도입된 다단계 scope과의 연계를 위해 예전에는 없던 완전히 새로운 명칭 축약 기능이 필요해진 셈이다.

그리고 후자인 using 지시는.. using namespace라는 두 단어로 시작하여 이 namespace에 속하는 모든 명칭들을 곧장 자동 개방해 버린다.
선언이건 지시건 하는 일은 별 차이가 없다. 이것도 그냥 와일드카드에 속하는 ... 이나 * 를 써서 using std::...; 같은 선언으로 통합해 버려도 될 것 같은데, 미관상 보기 안 좋아서 그렇게 안 했나 보다.

물론 일부러 구분해 놓은 걸 당장 쓰기 편하다는 이유로 몽땅 개방해서 내 명칭과 뒤섞어 버리는 건 전역 변수, friend, public의 남발만큼이나 경계해야 할 일이다. 하지만 적절하게 활용하는 건 auto를 쓰는 것만큼이나 코드를 짧고 간결하게 만드는 약이 될 수도 있다.

C++ 표준 라이브러리의 경우 namespace가 도입되기 전 코드와의 호환을 지키기 위해 <iostream.h>는 std로 감싸져 있지 않고, <iostream>은 감싸져 있는 것으로 잘 알려져 있다. 물론 .h 버전은 앞으로 사용을 권하지 않는 deprecated로 철저히 봉인됐고 말이다.

요 두 가지가 using의 전통적인 기능이었다.
그런데 C++11 이후에는 using이 typedef의 기존 기능까지 흡수하여 본격적인 타입 alias 전담 키워드로 등극하기 시작했다. 바로, 등호를 이용해서

using P_INT = int*;
using PF_INT = int (*)();

위와 같이 써 주면 아래의 typedef와 완전히 동치가 된다.

typedef int* P_INT;
typedef int (*P_INT)();

굉장히 참신하다. 새 명칭과 치환 대상 타입이 =를 경계로 딱 분리되어 있다 보니 재래식 typedef보다 깔끔하고 알아보기도 더 쉽다.
using이라는 단어는 파스칼의 use 키워드와 비슷한 느낌이며, using A=B는 파스칼의 type A=B와 뭔가 닮은 것 같다. 또한 이 문법은 namespace에 대한 alias를 만드는 namespace A = B::C 같은 문법과도 일관성이 있다.

Visual C++에서는 한 2013쯤부터 지원되기 시작했다. 2010은 지원 안 하고, 2012는 인텔리센스 컴파일러는 지원하지만 본 컴파일러는 지원하지 않더라.
이름 없는 namespace를 선언해서 C의 static 전역 변수/함수를 표현하듯이, C++의 키워드를 이용해서 기존 C의 기능을 대체하는 예가 하나 더 생겼다. 최신 컴파일러에서는 using을 볼 일이 더 많아지겠다.

Posted by 사무엘

1. WM_CREATE의 리턴값/타입에 의문

Windows에서 C/C++로 GUI 프로그래밍을 할 때 WM_CREATE 메시지는 기본 필수 0순위로 접하게 되는 물건이다. 메시지 번호부터가 WM_NULL 다음으로 당당하게 1번이다.
얘가 오면 윈도우 프로시저는 lParam의 값으로 날아온 CREATESTRUCT 구조체 내용을 참조하면서 자신에 대해 초기화를 하고, 필요하다면 자기의 위치와 크기도 변경하고, 내 밑의 차일드 컨트롤들도 적절히 생성하면 된다.

그런데 이 메시지를 처리하고 나서 되돌리는 리턴값은 약간 이상한 형태이다. 성공하면 0, 실패하면 -1을 되돌리라고 명시되어 있다. 윈도우 프로시저가 실패값을 되돌리면 CreateWindow(Ex) 함수의 동작도 실패하여 창이 생성되지 않으며, NULL이 돌아온다.

즉, WM_CREATE의 리턴 형태는 BOOL이나 마찬가지이다. 그런데 왜, 어째서 직관적인 TRUE (1) / FALSE (0)가 아니라 이것보다 1 작은 값 형태로 정해진 걸까? (0 / -1)
이 때문에 MFC에서도 CWnd::OnCreate는 리턴 타입이 int로 설정되었다. 하지만 얘는 성공/실패만 따지기 때문에 원래는 int가 필요하지 않다. 내가 실험해 보니 굳이 0이 아니어도 -1을 제외한 다른 모든 값들은 성공이라고 간주되기는 하더라.

WM_CREATE는 대화상자 프로시저(DialogProc)처럼 평소에는 BOOL을 되돌리지만 몇몇 소수의 메시지에 대해서는 예외적으로 정보량이 더 많은 리턴값을 직접 되돌려야 하기 때문에 불가피하게 INT_PTR 형태로 설계된 것도 아니다. 더구나 WM_CREATE의 전신격인 WM_NCCREATE는 평범한 BOOL TRUE/FALSE 형태인 것도 의문을 더욱 증폭시킨다.

이와 관련해 혹시 숨겨진 사연이 있는지 레이먼드 챈 아저씨가 블로그에서 한 번쯤 다뤘을 법도 해 보이는데 내가 검색한 바로는 의외로 없다.
"CreateFileMapping은 실패값이 NULL인데 CreateFile은 실패값이 왜 혼자 INVALID_HANDLE_VALUE (-1)인가요?"와 거의 같은 맥락의 내력 의문점인데도 말이다.

파일 API의 경우, 먼 옛날에는(16비트 시절?) CreateFile이 지금 같은 형태의 핸들값이 아니라 파일 식별자 번호를 되돌렸으며, 0도 특수한 용도이지만 올바른 파일 식별자 값으로 예약돼 있었기 때문에 실패값을 -1로 따로 정한 거라고 설명이 돼 있다.

그렇다면 WM_CREATE도 처음에 설계하던 당시에는 굳이 BOOL로 국한되지 않고 0을 포함한 다양한 범위의 성공 리턴값을 되돌릴 수 있게 만들었는데.. 그럴 필요가 없어지면서 결국 지금 같은 형태로 굳어진 게 아닌가 싶다.

2. NC 버전과의 관계, 창의 소멸

Windows의 메시지 중에는 클라이언트 영역의 바깥 테두리를 그리거나(PAINT, ACTIVATE) 거기 크기를 정하거나(CALCSIZE) 그 영역의 마우스 동작을 감지하는(MOUSE*, ?BUTTON*) 용도로 WM_NC*로 시작하는 것들이 있다. 여기서 NC는 non-client를 의미한다.

그런데 WM_CREATE와 WM_DESTROY에도 WM_NC버전이 있다. 이때 NC는 딱히 외관상으로 클라이언트 바깥의 테두리나 제목 표시줄 같은 걸 가리키지는 않으며, 다른 방향으로 의미를 갖는다.
소멸 버전의 경우, WM_DESTROY는 아직 자기 밑에 자식 윈도우들이 멀쩡히 남아 있을 때 호출된다. 즉, 호출되는 순서가 top-to-bottom이다. 그러나 WM_NCDESTROY는 WM_DESTROY가 전달되었고 자식 윈도우들이 모두 소멸된 뒤에 자식에서 부모 순으로 bottom-to-top으로 호출된다.

즉, 어떤 윈도우가 윈도우 프로시저를 통해 가장 마지막으로 받는 메시지는 WM_DESTROY가 아니라 WM_NCDESTROY이다. WM_QUIT은 아예 스레드의 메시지 큐 차원에서 Get/PeekMessage를 통해 전달받을 뿐, 특정 윈도우의 프로시저로 오지는 않으니까...

어떤 윈도우 핸들과 C++ 객체가 연결되어 있는 경우, WM_NCDESTROY에서 그 객체를 delete 해 주면 된다. 그 전 단계인 WM_DESTROY에서 delete를 해 버리면 아직 소멸되지 않은 자기 자식 윈도우가 부모 윈도우의 C++ 객체 같은 걸 여전히 참조할 때 문제가 발생할 수 있다.

사용자가 Alt+F4를 누르거나 창의 [X] 버튼을 누르면 그 윈도우로 WM_CLOSE 메시지가 전달된다. 시스템 메뉴에서 닫기를 누른 것도(WM_SYSCOMMAND + SC_CLOSE)도 디폴트 처리는 WM_CLOSE 생성이다.
그리고 이 메시지에 대해 윈도우 프로시저가 다른 처리를 하지 않고 DefWindowProc으로 넘기면 그때서야 이 윈도우에 대해 DestroyWindow 함수가 호출되고 WM_DESTROY와 WM_NCDESTROY가 차례로 날아온다.

DestroyWindow는 호출하는 주체와 동일한 스레드가 생성한 윈도우들만 없앨 수 있다. 프로세스/스레드 소속이 다른 윈도우는 없앨 수 없으며, 그런 윈도우를 상대로는 WM_CLOSE를 보내서 창을 없애 달라는 간접적인 요청만 할 수 있다.

악성 코드 급의 프로그램이 아니라면 이 요청을 무작정 거부하는 끈질긴 윈도우는 없을 것이다. 하지만 일반적인 프로그램의 경우, "이름없음 문서를 저장하시겠습니까?"라고 질문을 해서 사용자가 취소를 누르면 자기가 종료되지 않게 하는 처리 정도는 한다. 작업 관리자의 '프로세스 종료' 기능은 응용 프로그램 창에다가 WM_CLOSE부터 먼저 보내 보고, 그래도 말을 안 들으면 TerminateProcess라는 극약 처방을 하는 식으로 동작한다.

그런데 WM_DESTROY 메시지를 받았는데 자기 자신에 대해서 DestroyWindow를 또 호출하는 이상한 프로그램도 있는가 보다. 창을 없애라는 요청은 WM_CLOSE이고, 이때는 그냥 DefWindowProc만 호출해도 알아서 소멸이 된다. WM_DESTROY는 요청이 아니라 이 창이 없어지는 건 이미 정해졌고 피할 수 없는 운명이라는 통지일 뿐인데.. 이때 DestroyWindow를 호출하면 같은 창에 대해서 WM_DESTROY가 이중으로, 재귀적으로 전달되는가 보더라.

소멸 중인 윈도우에 대해서 DestroyWindow 요청은 가볍게 무시만 해도 될 듯하지만 이미 이런 식으로 정해지고 정착해 버린 동작은 호환성 차원에서 함부로 고치지는 못한다고 한다.

3. 창의 생성

소멸 얘기가 좀 길어졌는데...
생성 버전에 속하는 WM_CREATE와 WM_NCCREATE 짝은 소멸 관련 메시지와 같은 유의미한 차이가 없긴 하다.
자식 컨트롤들을 생성하는 건 그냥 WM_CREATE 때 하면 되지, NCCREATE 때 딱히 해야 할 일은 없다. 쟤는 그냥 NCDESTROY와 짝을 맞추기 위해 도입된 것에 가깝다.

어떤 창이 생성되면, CreateWindow(Ex) 함수가 실행되어 있는 동안 WM_CREATE만 오는 게 아니라 WM_GETMINMAXINFO, WM_NCCREATE, WM_NCCALCSIZE가 먼저 전달된다. CREATE말고 나머지 메시지들은 창 내부의 공간 배분과 관계 있는 것인데, 아주 특수한 형태로 동작하는 유별난 윈도우가 아니라면 그냥 다 디폴트로 넘겨도 무방한 것들이다.

그리고 앞서 살펴본 바와 같이, CREATE 계열 메시지들은 실패값을 리턴함으로써 이 창의 생성을 저지할 수 있다.
WM_NCCREATE의 실행이 실패한다면(FALSE) 이 창은 그 뒤로 곧장 WM_NCDESTROY만 날아온 뒤 소멸되어 버린다. 그러나 WM_CREATE에서 실패하면(-1) WM_DESTROY와 WM_NCDESTROY가 차례로 날아오면서 소멸된다.

그런데 여기서 유의할 것이 있다.
프로그램의 main 윈도우의 경우, WM_DESTROY를 받았을 때 대체로 main message loop을 벗어나고 프로그램 전체를 종료하기 위해서 PostQuitMessage를 호출한다.
이게 일단 호출된 뒤부터는 이 스레드에서는 다른 GUI 윈도우를 생성한다거나 message loop을 돌아서는 안 된다. 여기에는 에러 메시지를 출력하기 위한 간단한 MessageBox 호출도 포함된다.

main 윈도우의 생성이 WM_CREATE 단계에서 실패했다면(WM_NCCREATE은 무관) WM_DESTROY를 거치게 되며, 특별한 조치가 없는 이상 그 메시지의 handler에 있는 PostQuitMessage도 처리되었을 것이다. 이 상태에서

if(::CreateWindowEx( .... )==NULL) {
    ::MessageBox(L"프로그램 실행 실패");
    return 1;
}

이런 식으로 코드를 쓰면 MessageBox 내부의 메시지 loop은 메시지 큐에서 WM_QUIT이 튀어나오기 때문에 곧바로 끝난다. 즉, 메시지 박스가 화면에 표시되지 않는다는 것이다.
그러니 에러 메시지를 찍을 거면 차라리 WM_CREATE 내부에서 -1를 리턴하기 전에 하는 게 낫다.

심지어 main 윈도우의 WM_NCDESTROY에서 MessageBox를 호출하려 시도하는 경우도 있다고 한다. 프로그램 실행이 다 끝난 마당에 무엇을 찍을 일이 있는지는 모르겠지만 이 역시 위와 동일한 이유로 인해 메시지 박스가 화면에 나타나지 않는다.
뭐, WM_DESTROY 대신 WM_NCDESTROY에서 PostQuitMessage를 요청할 수도 있겠지만 int main(int argc, char *argv[]) 대신에 char **argv만큼이나.. 익숙한 관행은 아니어 보인다.

이상. 이렇게 간단하고 익숙한 주제를 갖고도 지금까지 진지하게 생각하지 못한 것에 대해 할 말이 많을 때가 흥미롭다.

Posted by 사무엘

1. 3차원 그래픽 시연 프로그램의 개편

지난 2003년부터 2005년 사이, 본인의 대학 재학 시절에 만들어진 뒤 10년이 넘게 버전업이 없었던 '3차원 그래픽 시연 프로그램'이 정말 오랜만에 업데이트 되었다. 무엇이 바뀌었냐 하면.. '시선 고정' 모드란 게 추가됐다.

이 프로그램은 지금까지 3D FPS 게임처럼 앞뒤 좌우 상하로 움직이는 것에만 최적화돼 있었는데, 시선 고정 모드에서는 카메라가 어디 있든지 시선이 언제나 기준점을 향해 고정되게 된다.
시선이 고정되니, 이때는 통상적인 좌우 화살표나 page up/down을 이용한 시점 변경이 동작하지 않는다. 끄덕끄덕(pitch)/설레설레(yaw) 말고 시선에 영향을 주지 않는 갸우뚱(roll)만 동작한다.

그리고 좌우 게걸음인 ZX와 상승/하강인 QA를 누르면 그냥 움직이는 게 아니라 기준점과 같은 거리를 유지하면서.. 기준점 주변을 상하 좌우로 돌게 된다.
요것이 본인이 원하던 바였다. 사실, 3차원 그래픽 편집 프로그램에서는 FPS 게임 같은 움직임보다는 이렇게 시선이 고정된 '빙글빙글' 앵글 이동을 더 흔히 볼 수 있었을 것이다. 이 동작을 내 프로그램도 뒤늦게 지원하게 됐다.

F를 누르면 시선 고정 모드를 켜거나 끌 수 있다. 아래의 상태 표시줄에 기준점의 좌표가 같이 나타난다.
그리고 D를 누르면 지금 카메라가 있는 위치를 기준점으로 지정한다. 초창기에는 (0, 0, 0) 원점이 기준점이다.
기준점을 파란색 동그라미 같은 별도의 부호로 표시해 주면 사용자에게 도움이 될 수 있겠지만.. 일단은 그런 걸 생략했다.

예제 데이터들 중에서는 구(sphere)가 제일 볼 만할 것이다. 이 구는 그렇잖아도 원점이 중심으로 만들어져 있다. 구에서 적당히 떨어진 뒤 시선 고정 모드를 켜고 QA/ZX를 누르면 우리가 인공위성이라도 된 것처럼 구 주변을 빙글빙글 돌게 된다.
그에 비해 토러스(torus)는 원점을 기준으로 만들어져 있지 않은 듯하니(구체적인 값은 기억이..) 적당히 다른 점을 기준으로 설정해야 튜브 안을 이탈하지 않고 빙글빙글 돌 수 있다.

지난 2016년에는 삼각형 오심 그리는 프로그램을 오랜만에 업데이트 했는데.. 이번에는 3차원 그래픽 프로그램을 손보게 되니 감회가 새롭다. '옛날 자료실'에 있는 프로그램들도 이런 식으로 최소한의 유지 보수는 여전히 하는 중이다.

2. 날개셋 개발 관련 미스터리

본인은 하루는 키보드 보안 ActiveX를 사용하는 어느 사이트에서 날개셋 한글 입력기 외부 모듈이 뻗는 걸 발견했다. 한글만 연달아 입력하는 것은 문제가 없는데, 그렇게 조합을 만들었다가 숫자나 마침표 같은 기호를 찍어서 조합을 중단하면.. 에러가 나고 브라우저 창이 다시 열리곤 했다.

마소 IME 같은 타 프로그램에서는 괜찮고 내 프로그램에서만 100% 재연 가능한 문제가 뻔히 발견되었는데.. 그렇다면 이 문제는 독 안에 든 쥐나 마찬가지이고 곧바로 원인을 추적해서 해결되어야 할 것이다. 그런데 믿어지지 않지만 도저히 그러지를 못했다. 디버깅에 필요한 모든 절차와 방법론을 IE와 보안 유틸리티가 원천봉쇄하고 있었기 때문이다.

exception handler를 지정해서 뻗었을 때 덤프 파일을 만들려고 해도, 윗선에서 예외 이벤트를 가로채기라도 하는지 덤프가 만들어지지 않았다. (덤프는 프로그램이 뻗은 지점이 소스 코드상으로 어디이고 그 당시 함수들의 호출 계층이 어떠한지에 대한 정보를 담고 있음. 원인 추적에 매우 중요!)

입력란이 떠 있는 IE 프로세스에다가 디버거를 붙이면.. 보안 유틸이 이를 감지하고 디버거를 끄라고 요구하면서 동작을 거부했다.
뻗었을 때 디버거를 붙여도 문제의 프로세스는 상황을 확인할 틈도 없이 혼자 싹 종료되어 버렸다.

결국은 무식하게 키 입력이 감지됐을 때.. 등 의심되는 모든 곳에다가 화면/파일로 로그를 찍어서 테스트를 해 봤다.
그런데 이거 뭐 내가 짠 코드는 모조리 정상 통과한 뒤에 이상한 데 엄한 데서 에러가 발생하는 것이었다.

이건 정황상 키보드 보안 유틸과 3rd-party IME와의 충돌이긴 하지만 내가 아는 방법으로는 도저히 문제의 원인이나 해결책을 파악할 수 없어서 이번 9.61 버전에서도 부득이하게 해결되지 못했다. 언젠가 여유가 있으면 그 보안 유틸의 개발사와도 협조를 구해서 합동 수사 공조라도 해야 하지 않을까 싶다.

3. 스레드

어느 플랫폼에서든 프로그램을 짜다 보면, 백그라운드 스레드에서 뭔가를 열심히 수행한 뒤에 결과값을 표시하는 마무리 작업은 반드시 main UI 스레드에서 실행해야 할 때가 생긴다. 이에 대해서 본인은 예전에 글을 쓴 적이 있다.

요즘 프로그래밍 언어들은 언어 차원에서 별도의 블록을 분리해서 이 블록 안의 코드는 별도의 스레드에서 비동기적으로 실행되다던가, main UI 스레드에서 실행시키는 식으로 간편하게 제약을 가할 수 있다. 요런 걸 macOS의 Objective C에서도 보고 Java, C# 등에서도 봤던 것 같다.
그런 게 지원되지 않는 언어나 플랫폼에서는 해당 기능을 직접 구현하게 되는데.. Windows라면 메시지를 보내는 것과 일맥상통한다. main UI 스레드라면 그 정의상 message loop을 돌리고 있을 것이기 때문이다.

그런데 Windows용 IME는 자기가 만들지 않은 남의 프로그램 창, 남의 스레드, 남의 message loop을 기반으로 돌아가기 때문에 거기에다가 자신만의 메시지와 자신만의 메시지 핸들러를 슬쩍 얹기가 좀 난감하다.
그나마 옛날에 프로토콜이 IME 방식이던 시절에는 IME가 제각기 자신만의 보이지 않는 윈도우가 있었기 때문에 내부적으로 custom 메시지를 얼마든지 처리할 수 있었다. 하지만 TSF로 바뀐 뒤에는 그런 윈도우가 존재하지 않는다.

IME는 키보드 포커스를 받는 남의 윈도우에다가 WM_USER+* 이상한 메시지를 함부로 보내서는 안 되고, 타이머 ID도 함부로 선점하지 않아야 한다. 그러면 윈도우 핸들 없이 콜백 함수를 바로 호출하는 타이머밖에 선택의 여지가 없는데.. 그렇게 하면 SetTimer를 호출하는 자신과는 다른 스레드 문맥에서 처리되는 타이머를 생성할 수가 없다.

이게 생각보다 굉장히 난감한 문제이다. 결국은 타 스레드에서 main UI 스레드 문맥으로 특정 코드를 실행하기 위해 본인은 TSF 모듈도 임시로 나만의 message-only 윈도우를 main UI 스레드에서 생성하고, 이 윈도우가 특정 메시지를 받았을 때 그 코드가 실행되도록 프로그램을 작성했다. 메시지라는 게 알고 보면 스레드 간 교통 정리에 큰 기여를 하고 있는 셈이다.

사실 스레드, 특히 콘솔 프로그램이 아니라 main UI가 있는 프로그램에서 스레드를 쓰는 건 십중팔구 사용자 입장에서 프로그램의 반응성을 올려 주기 위해서 하는 게 대부분이다. 일시불로 프로그램이 잠시 멈추고 뜸을 들이는 게 싫으니 이자를 감수하고라도 찔끔찔끔 할부를 선택하는 것이다.

스레드 그 자체는 메모리를 더 잡아먹고 컨텍스트 스위칭 오버헤드 때문에 전반적으로 CPU가 할 일을 더 늘리고 성능을 떨어뜨린다. 하지만 스레드를 만들어서 컴퓨터가 더 많이 고생할수록 사용자의 입장에서는 더 편리한 기능이 많이 구현되는 것이 사실이다.

4. 날개셋 외부 모듈과 입력 패드의 동작 차이

날개셋 한글 입력기의 구현체 프로그램 중에서 편집기는 오로지 자기 혼자서만 돌아가는 프로그램이니 다른 고민의 여지가 없는데.. 외부 모듈과 입력 패드는 본격적으로 타 프로그램에다 문자를 보내기 때문에 다양한 환경에서 최대한 동일한 동작을 보장해야 한다. 그게 불가능한 경우 불가능한 한계에 대해서 사용자에게 미리 고지를 해야 한다.

Windows용 IME의 입장에서 좀 별종인 환경은 전통적으로 (1) 로그인(잠금) 화면, 그리고 (2) 명령 프롬프트가 있다. 그리고 Windows 8/10부터는 (3) Metro UI도 추가됐다.
입력 패드는 원래 명령 프롬프트에서는 전혀 동작하지 못하다가 Windows 7에서부터는 동작 가능해졌다.

외부 모듈은 Metro UI에서는 조합 중인 한글을 보내는 일반적인 동작은 가능하지만 tab, enter 같은 글쇠 입력을 보내지는 못한다(날개셋문자 또는 각종 입력 도구의 버튼을 통해서).
그 외에 Metor UI에서는 프로그램이 외부의 데이터 파일을 참조하지 못해서 입력 설정이 데스크톱 환경과 동기화되어 있지 않다거나, 문자표 같은 입력 도구들도 제대로 동작하지 않는 한계가 있다. 입력 도구를 X 버튼을 눌러서 닫을 수도 없다. (우클릭 메뉴를 이용해야..)

한편, 입력 패드는 외부 모듈과 달리 자신이 독립된 프로세스이기 때문에 파일을 못 여는 한계는 없다. 단지, 반대로 Metro UI로 조합 문자 같은 입력 동작을 보낼 수 없을 뿐이지..;;
그런데 굉장히 의외로 글쇠 입력을 보낼 수는 있다. 가령, 화면 키보드에서 ㄱ, ㅏ 같은 한글 조합 글쇠는 못 보내지만 tab, enter 버튼을 누른 것은 전해진다는 뜻이다. 외부 모듈이 할 수 없는 일을 입력 패드가 예외적으로 할 수 있으니 흥미로운 차이점이다.

외부 모듈에서 글쇠 입력을 못 보냈거나 입력 패드에서 자체 입력을 못 보냈을 때, 못 보냈다는 에러 메시지라도 출력할 수 있으면 좋겠지만 일단은 방법이 없어 보인다.

외부 모듈과 입력 패드에는 이것 말고도 흥미로운 차이점이 더 있다.
외부 모듈은 Windows 메시지를 직접 받지 못한다는 특성 때문에 alt가 섞인 단축글쇠를 전혀 인식할 수 없다. 원래 alt는 운영체제 차원에서의 단축키나 메뉴 구동용으로 쓰이지 IME 같은 데서 가로챌 여지가 없기도 하고 말이다.

그 반면, 비록 프로토콜을 제대로 지원하는 소수의 프로그램 한정이긴 하지만 그래도 편집기와 다를 바 없는 온전한 A급 동작을 보장 가능한 것도 외부 모듈이다. 입력 패드로는 완성된 한글을 낱자 단위로 지우거나 달라붙는 자유자재 동작까지 지원하지는 못한다. 서로 일장일단이 있는 셈이다.

Posted by 사무엘

1.
인텔 CPU의 역사를 살펴보자면.. 1971년에 무려 4비트짜리로 나온 4004가 최초의 상업용 마이크로프로세서라고 여겨진다. 그 뒤 72년에 8비트 8008이 나오고, 1978년의 16비트 8086이.. 오늘날까지 이어지는 x86 아키텍처의 서막을 열었다.

8086, 80186, 80286은 모두 16비트 CPU이다. 186은 PC에서는 거의 쓰이지 않았고, 286은 이론적으로는 보호 모드와 멀티태스킹까지 지원하는 물건이었지만 구조적인 한계 때문에 소프트웨어에서 실제로 제대로 활용되지는 못했다.

086에서 286으로 넘어가는 과정에서는 그냥 CPU의 클럭 속도만 올라가고, IBM PC 규격 차원에서 XT/AT의 차이가 더 컸던 것 같다. 가령, 하드디스크 탑재라든가 고밀도 디스켓 지원 말이다. 키보드의 반복 속도 조절 기능도 내 기억이 맞다면 AT부터 지원되기 시작했다.

무려 1985년, 아직 VGA도 없던 시절에 80386 CPU가 개발되어서 IA32라는 아키텍처가 완성되긴 했다. 하지만 이때는 컴퓨터의 가격이 너무 비싸서 32비트가 가정용으로 보급되기는 곤란했다.
나중에 외부 데이터 버스를 32 대신 16비트로 줄여서 가격을 좀 낮춘 보급형 386SX라는 게 등장했다. 훗날 등장한 펜티엄은 반대로 그 버스의 크기가 64비트로 머신 워드 크기보다도 더 커졌으니, 386SX와 좋은 대조를 이룬다.

또한 386 때부터 슬슬 캐시 메모리가 쓰이기 시작했으며, 486에서부터는 부동소수점 프로세서(FPU)가 기본 내장으로 들어가기 시작했다. 클럭 속도의 증가는 덤이다.
486 이후로는 인텔이 숫자 명칭 대신 '펜티엄'이라는 자체 브랜드명을 사용하기 시작했고, 펜티엄 다음으로는 코어.. 코어 안에서는 네할렘, 샌디브릿지 같은 세부 공정이 달라질 때마다 새로운 명칭을 붙여서 제품을 구분하고 있다.

2.
2000년대 중반, 딱 Windows XP와 IE6이 장수하던 05~06년 사이에 멀티코어와 64비트가 도입되면서 PC의 환경이 20세기 시절과는 크게 달라진 듯하다. 둘은 도입 시기가 완전히 일치하지는 않지만 미묘하게 비슷하다. 펜티엄 4의 후기형을 거쳐서 펜티엄 D에서부터 싱글코어 기반의 x86-64가 정착했으며(정확히는 2003~04년 사이), 반대로 Core 1 Duo는 32비트 전용의 첫 멀티코어 프로세서였다.

그러다가 둘이 합쳐져서 Core 2 Duo가 64비트 + 2개짜리 멀티코어 시대를 열었다. 운영체제는 Windows Vista/7부터 말이다.
사실 Core 1 Duo는 PC용으로는 출시도 되지 않고 모바일용으로 나왔는데, 애초에 x86이 모바일에 적합한 구조의 아키텍처가 아니다 보니 존재가 모순적이었다. 그러니 별 재미를 못 보고 단종됐다.

CPU가 그렇게 바뀐 동안 모니터는 LCD와 와이드가 도입되었다. 옛날에는 4:3 비율의 액정 모니터도 있었지만 2000년대 중후반쯤에 자취를 감춘 듯하다.
요즘은 형광등이 처음 켜질 때 깜빡거리는 걸 볼 일이 없어진 것처럼.. CRT TV나 모니터를 처음 켤 때 화면이 예열과 함께 천천히 fade in 되는 모습도 볼 일이 없어졌다.

또한 기분 탓인지는 모르겠지만, 예전에는 모니터의 테두리 색깔이 흰색이 많았는데 와이드 화면 모니터는 검은색이 주류가 된 것 같다.

3.
인텔 CPU가 초창기에 저렇게 발전해 온 동안, 우리나라는 역사적으로 국가에서 나서서 전국민에게 PC를 보급한 적이 딱 두 번 있었다. 전자는 그 말 많던 "교육용 PC" 사업이고(1980년대 말), 후자는 그로부터 10년쯤 뒤, IMF에다 세진 컴퓨터 랜드가 아직 있고 인텔 펜티엄 2, 셀러론 이러던 시절의 국민 PC 사업이다.

전자의 사업 때 이미 많이 보급돼 있던 MSX니 SPC니 하는 8비트들을 싹 배제하고 과감하게 16비트 IBM 호환 PC를 지정한 것은 마치 철도 표준궤와 220V 전압만큼이나 미래를 내다본 굉장한 선견지명이었다. 결국은 그 PC 계열이 천하를 평정했기 때문이다. 1980년대 당시에 정보통신부나 과학기술처의 담당 관료가 중대한 결정을 잘 내렸다.

뭐, 8비트 컴터들은 대체로 화면 해상도가 낮고 성능도 떨어져서 당장 한글· 한자 처리에 애로사항이 너무 크긴 했다. 그 문제 때문에 한국· 일본은 16비트 컴에서 비디오 카드조차도 허큘리스에서 거의 곧장 VGA로 갈아탔지, 서양처럼 CGA/EGA를 진지하게 경험하지는 않았으니 말이다.

지금이야 PC는 너무 흔해 빠지고 기업의 입장에서는 이윤도 별로 안 남아서 하나 둘 철수할 지경이 돼 있다. 남사스럽게 PC에 연연할 필요 없이 폰이 다 보급돼 있고.. 당장 돈이 없어도 온갖 할부 제도를 이용해서 뿌리다시피하고 있다. 저 시절의 컴퓨터와는 비교할 수 없을 정도로 더 성능 좋고 작은 컴퓨터를 전화기에다가 얹어서 들고 다니는 게 경악스럽게 느껴질 지경이다.

4.
지금까지 CPU 얘기가 나왔으니 말인데,
문자 인코딩을 CPU 명령의 인코딩에다 비유하자면, UTF-8은 CISC에, UTF-16이나 32는 RISC에 딱 대응하는 것 같다.
원래 UTF-8은 그 구조상 5~6바이트까지도 늘어나서 U+10FFFF보다 더 큰 코드값도 기록이 가능은 하다. 하지만 언제부턴가 인코딩 규칙이 개정되어서 5~6바이트짜리는 현재로서는 고이 봉인하고, 1~4바이트까지만 사용하기로 했다.

오늘날 국내외의 컴덕이나 프로그래머들 중에는 UTF-8을 완전 만능으로 칭송하는 한편으로 UTF-16은 거의 사회악 쓰레기 수준으로 싫어하는 사람이 종종 눈에 띈다. 프로그래밍 배경이 Windows가 아닌 유닉스 계열인 사람, 그리고 특히 wchar_t의 플랫폼별 파편화 때문에 삽질과 고생을 단단히 한 사람일수록 그런 성향이 더욱 강하다.

본인은 주장의 논지는 이해하지만 그 정도까지 부정적인 견해에는 공감하지 않는다.
컴퓨터에서 어떤 데이터를 주고받기 위해서는 결국은 값을 그대로 전하든지, 아니면 좀 덩치가 큰 데이터는 별도의 메모리에다가 저장해 놓고 그 메모리 주소만 전하든지.. 둘 중 하나를 선택해야 한다. 32비트니 64비트니 하는 건 그 컴퓨터의 CPU가 한번에 취급하는 그 정보의 크기 단위이다.

문자 하나를 전하기 위해서 일일이 메모리 할당해서 문자열을 만들고 포인터를 전달하느냐, 아니면 그 문자의 코드 포인트 값만 간단하게 전하느냐.. 이게 얼마나 큰 차이인지는 프로그램 좀 짜 본 사람이라면 누구나 공감할 것이다.

그 와중에 옛날 사람들이 UTF-16이라는 계층의 존재를 예상 가능했던 것도 아니고, 1990년대에 메모리가 지금만치 풍부하고 저렴했던 것도 절대 아니고, 그저 모든 글자의 크기를 2바이트로 균일하게 늘리는 것만으로도 메모리를 너무 많이 잡아먹네 하던 시절에.. UTF-8도 아니고 UTF-32도 아닌 적당한 절충안인 UTF-16 내지 그 전신 UCS-2가 과연 그 정도로 태어나지 말았어야 한 존재인 걸까? 그게 아니라는 것이다.

내가 보기에 이건 유니코드에 현대 한글 글자마디 11172자가 일일이 다 등록된 게 잘못된 거라고 비판하는 것과 비슷해 보인다. 그렇게 등록을 안 했으면 글꼴을 만들기가 훨씬 더 복잡하고 어려워지고, DB 문자열 필드나 파일명 같은 데에 집어넣을 수 있는 한글 글자 수가 크게 감소했을 텐데 말이다.

문득 Windows가 오로지 65001 UTF-8만으로 천하통일이 이뤄지고.. 심지어 9x 시절처럼 W가 아닌 A 함수가 주류로(그 대신 UTF-8 기반으로!) 회귀하는 엉뚱한 상상을 해 본다. 물론 실현 가능성은 사실상 0일 것이다. =_=;;
Windows의 WCHAR뿐만 아니라 macOS의 NSString, Java의 Char과 jstr, COM의 BSTR 등 많은 운영체제와 프레임워크들은 2바이트를 문자의 기본 단위로 사용하고 있으니 어차피 이걸 쉽게 벗어날 수 있지도 않다.

5.
컴퓨터에서 일상적으로 볼 수 있는 보조 기억 장치는 결국 (1) 자기 디스크, (2) 플래시 메모리, (3) 광학 디스크 이 세 범주 중 하나로 귀착된다. 또 완전히 새로운 범주가 개발될 여지가 있으려나 모르겠다.
용량과 속도 가성비가 "전반적으로" 제일 뛰어난 건 역시나 자기 디스크이다 보니, 얘를 기반으로 한 '하드디스크'는 가히 유구한 역사를 자랑한다. 기계식, 물리적인 요소가 존재하는 장치임에도 불구하고 오늘날까지도 컴퓨터에 여전히 건재하다.

플래시 메모리는 PC에서는 USB 스틱 아니면 SSD의 형태로 요긴하게 쓰이고 있다. 동작 중에 일체의 소음과 진동이 없는 순수 전자식이며, RAM과 보조 기억 장치의 경계를 허물 차세대 주자로도 각광받는 물건이다. 하지만 가격 때문에 하드디스크를 완전히 대체하는 건 여전히 무리이다.

마지막으로 광학 디스크인 CD/DVD/블루레이는 매체의 외형부터가 빛을 반사하는 새끈한 재질인 게 굉장히 간지 나고 미래 지향적으로 보인다. 하지만 20여 년 전에 40배속인가 뭔가에서부터 읽기 속도가 한계에 달했으며, 쓰기를 마음대로 할 수 없다는 치명적인 한계 때문에 쓰임이 반쪽짜리가 됐다.

USB 메모리와 초고속 인터넷 파일 전송, 가상 디스크 마운트 기술에 밀려서 광학 디스크를 사용할 일이 예전에 비해 극히 드물어진 것이 사실이다. 이제는 부팅조차도 USB 메모리만으로 가능해질 정도가 되기도 했고 말이다.

옛날에는 레이저를 사용하는 컴퓨터 주변 기기들이 굉장히 비쌌다. CD 라이터라든가 레이저 프린터 말이다. 이런 것들이 개인이 쉽게 보유할 정도로 흔해진 건 이르게 잡아도 1990년대 말이고 21세기에 와서부터이다.
또한 얘들은 다 열을 많이 가하는가 보다. 레이저 프린터만 해도 종이를 고온 고압을 가해서 토너가루를 붙이는 식으로 인쇄하는데(그래서 타 인쇄 방식에 비해 전기도 많이 씀), 광학 디스크에다 기록하는 것도 한국어· 영어 공히 '굽다/BURN'이라고 표현할 정도로 비슷한 메커니즘을 동원하는 듯하다.

여담이지만, 자기 디스크는 영어 철자가 disk이고, 광학 디스크들은 철자가 disc라는.. 미묘한 차이가 있다.

6.
터치스크린은 기존 키보드와 마우스를 완전히 대체하지는 못하지만, 그래도 모니터를 출력 장치뿐만 아니라 입력 장치도 겸하게 해 주는 깔끔하고 참신한 인터페이스임이 틀림없다. 단순히 버튼을 콕콕 찍어서 선택하거나 간단한 필적을 그리는 용도로 아주 좋다.

터치스크린을 구현하는 방식은 크게 감압식과 정전식으로 나뉜다. 감압식은 물리적인 압력을 감지하는 방식이고, 정전식은 그게 아니라 표면의 전기 신호의 변화를 감지하는 방식이다.
이게 마우스로 치면 제각기 볼 마우스와 광 마우스에 대응하는 것이나 마찬가지로 보인다. 전자가 좀 기계식이고 후자는 말 그대로 전자식이다.

처음에는 전자와 후자가 장단점이 서로 호각인 지경인데, 기술적인 구현 난이도는 후자가 더 높았다. 하지만 세월이 흐르면서 지금은 결국 기술적인 한계가 극복되고 후자의 장점이 더 부각된 덕분에, 후자 방식이 주류 대세가 되었다. 이런 변화 양상도 마우스와 터치스크린이 서로 동일하다.

엘리베이터 버튼 중에도 오로지 사람의 생 손가락만 인식하고 타 물체 내지 장갑 낀 손가락은 인식하지 않는 게 있는 게 개인적으로 신기한 한편으로 잘 이해가 되지 않았다. 마치 광 마우스는 유리판 위에서는 좀체 동작하지 않는 것처럼 말이다.
그렇게 생 손가락만 인식하는 센서들은 다 정전식이다. 감압식이라면 무슨 물체를 쓰든지 버튼을 누른 건 다 인식돼야 할 것이다.

정전식은 감압식보다 터치를 더 부드럽게 인식할 수 있으며 특히 마우스가 결코 흉내 내지 못하는 멀티터치를 구현하는 게 더 유리하다.
Windows 98에서 마우스 휠이 정식 지원되기 시작했다면 지난 Windows 7에서 터치 장비가 정식으로 지원되기 시작했다. 안 그래도 7은 그림판이 크게 개선되어서 초보적이나마 브러시 엔진까지 도입됐는데, 여러 손가락으로 동시에 태블릿을 긁으면서 그림을 그리던 시연 모습이 인상적이었다.

하지만 본인은 데스크톱/노트북급에서 화면이 터치스크린을 지원하는 장비는 10년째 한 번도 못 봤다. 장비를 주위에서 쉽게 접할 수 있었다면 날개셋 한글 입력기에도 멀티터치 같은 걸 연계한 입력 도구를 구현할 생각이라도 했을 텐데 그건 지금까지도 그냥 장기 계획으로만 머물러 있다.

그러고 보니 이런 터치 장비는 좌표뿐만 아니라 압력 정보까지 전할 수 있다.
다만, 얘들은 올록볼록 입체적인 점자를 표현하지 못하니 터치스크린 기반 UI는 장애인과는 그리 친화적이지 못한 인터페이스이다. 이건 뭐 어쩔 수 없는 귀결이다. 시각 장애인 내지 손가락을 자유롭게 움직이지 못하는 사람은 스마트폰도 여전히 버튼식 폴더 형태로 된 기기를 써야 한다.

7.
자동차에 경차라는 차급이 있고 총기 중에도 제일 작은 권총이라는 게 있듯, 컴퓨터계에서 제일 작은 놈은 넷북이지 싶다. 정말 작고 아담해서 들고 다니기 편하며 값도 저렴하다. 부담 없이 인터넷과 문서 작업만 하는 용도로는 참 좋다.

하지만 얘는 그만큼 CPU의 성능이 매우 뒤떨어지고 화면 해상도도 너무 낮으며, 키보드 역시 적응이 힘들 정도로 너무 작은 편이다. 그렇기 때문에 얘로 단순히 글자판떼기 치기 이상으로 다른 생산적인 일을 하기에는 애로사항이 많다. (프로그래밍, 그래픽 디자인 등등..) 아니, 사람에 따라서는 키보드의 구조 때문에 단순 글자판떼기 치기조차도 불편하게 느껴질 수 있다.

게다가 2010년대부터는 PC가 아닌 스마트폰 운영체제에 기반을 둔 각종 태블릿 판떼기들이 급속히 발전한 덕분에, 단순 휴대용 인터넷 단말기 및 게임기라는 수요는 사실상 거기로 다 흡수됐다. 그러니 단순히 노트북 PC를 경차급으로 줄인 넷북이라는 건 사실상 존재 의미를 상실하고 오히려 그 태블릿들이 필요에 따라서는 키보드를 연결해서 쓸 수도 있는 형태가 됐다.

물론 터치스크린은 기존 키보드와 마우스를 결코 완전히 대체할 수 없으며, 정보의 소비와 열람이 아니라 정보를 생산하는 도구로서 PC의 지위는 예나 지금이나 변함없다. 또한, 넷북이 없어진다고 해서 넷북의 용도 내지 걔들이 수행하던 작업 자체가 없어지는 건 아니다. 휴대용 컴퓨터는 좀 더 모바일 기기와 결합한 형태로 변모하고, 전통적인 PC는 자기 역할에 특화되는 쪽으로 가는 듯하다.

8.
1990년대 초반

• 86키 키보드는 이제 거의 도태하고 101키 키보드가 대세가 됐다. 옛날 키보드는 F11, F12가 없으며, 기능 키 F1~F10이 맨 왼쪽에 2열 5행으로 세로로 배치돼 있었다. 지금의 capslock 자리에 ctrl이 있고 capslock은 지금의 우alt/ctrl 자리에 있었다. 키패드에서 우측 하단인 지금의 엔터 자리에 더하기가 있었다.
• 옛날에 키보드는 정체를 알 수 없는 이상한 전용 포트에다 꽂았으며 마우스는 모뎀과 같은 COM.. 직렬 포트에다 꽂았다. 프린터는 병렬 포트에 꽂았고.. 모뎀과 마우스의 충돌은 정말 대표적으로 골치아픈 문제였다.
• Plug & play도 없고 USB도 없던 시절이니, 외장 하드디스크를 연결해서 인식시키는 것만 해도 바이오스 설정을 바꾸는 등 정말 고도의 컴터 지식이 필요한 작업이었다.

1990년대 중반

• 좋은 그래픽 카드를 사용하면 화면이 바뀌는 곳에서도 마우스 포인터가 깜빡거리지 않기 시작했다. 단, 흑백 기본 포인터 한정으로. custom 포인터는 여전히 깜빡거렸다.
• 486쯤부터는 컴퓨터 본체가 모니터 밑받침으로 까는 형태가 아니라 모니터 옆에 세워 놓는 형태로 거의 정착했다. 하지만 Windows의 '내 컴퓨터' 아이콘은 XP에 가서야 이 모양을 반영하는 형태로 바뀌었다.
• 486/펜티엄급 컴에서 WinAMP로 128kbps급 mp3를 하나 재생하면 CPU 점유율이 10~20%가량 올라가곤 했다.
  

1990년대 후반

• 시스템 종료 후에 컴퓨터가 자동으로 꺼지기 시작했다. "이제 컴퓨터를 끄셔도 안전합니다"라는 주황색 글자를 사용자가 직접 볼 일이 없어졌다.
• Windows 98쯤부터 멀티웨이브가 가능해졌다. 지금으로서는 정말 믿어지지 않지만, 원래 옛날에는 한 프로그램에서 사운드를 출력하기 시작하면 다른 프로그램에서 사운드를 사용할 수 없었다!

1999~2000 사이

• 컴퓨터 규격이 크게 바뀌었다. 그 이름도 유명한 USB 포트라는 게 등장했고, 키보드와 마우스용 초록색-보라색 PS/2 포트도 등장했다.
• 전원을 3초 이상 꾹 눌러야 꺼지는 관행도 이때부터 정착했다.
• 사운드카드의 스피커가 이제 컴터 본체에 내장되지 않기 시작했다.
• 가정에서도 모뎀 대신 인터넷 전용선이 슬슬 보급되기 시작했다.

2000년대

• 이제 custom 마우스 포인터도 깜빡이지 않기 시작했다. 사실 Windows 2000은 9x와 달리, 16색 VGA 구닥다리 안전 모드에서도 마우스 포인터가 깜빡이지 않는 게 개인적으로 굉장히 신기했다.
• 컴퓨터에서 오디오 CD의 음원을 추출하는게 옛날에는 쉽지 않았는데 이제는 손쉽게 가능해졌다.
• USB 메모리가 디스켓을 확실하게 골로 보냈으며, 무선 인터넷과 합세하여 CD의 지휘조차 위협한다. 호각인 라이벌은 엄청난 용량을 자랑하는 하드디스크뿐..
• PS/2포트조차 한물 가고 키보드와 마우스도 그냥 USB 기반으로 나오기 시작했다.
• Windows Vista부터는 동영상 화면도 일반 화면과 아무 차이 없이 print screen으로 캡처 가능해졌다.

Posted by 사무엘

1. 출국

독일 베를린에서 실제로 벌어졌던 동백림(동베를린) 사건을 바탕으로 만들어진 영화이다. 실제 모델 인물인 오 길남은 월북한 뒤 재독 한인을 포섭하는 공작원 명목으로 독일로 파견됐는데.. 북한 정권의 실체를 깨달은 뒤엔 거기서 자수하고 남한으로 귀순했다.

어색한 억지 감동 유도라든가, 좀 식상하고 허무한 듯한 결말이 아쉬운 점으로 남지만, 중간 전개는 역시 찢어 죽일 종북좌빨들이 충분히 불편해하고 싫어할 만한 팩트 위주이다.
그러니 북괴의 정체와 흉악한 수작이 까발려지는 걸 원치 않는 놈들은 블랙리스트니 화이트리스트니 나발이니 딴 거 갖고 시비를 거는 것이다. 영화계 전체 그림을 객관적으로 보자면 지금 솔직히 우보다는 좌편향이 훨씬 더 심하지 않은가?

북괴가 역사적으로 저지른 극악무도한 죄악 중 하나는.. 단순히 사람을 죽인 걸 넘어서 가족을 저렇게 하루아침에 산 채로 찢어 놓은 것이다.
6·25 이산가족은 말할 것도 없고, 먼 옛날엔 여객기 납치로도 단란하던 가정을 많이 파탄냈다.

또한, 저런 젊은 학자들을 속여서 북한으로 보내서 그 가족들의 인생을 파멸로 이끈 악마가 지금 청와대 수장에게는 민족을 사랑하는 평화통일 운동가로 보이는가 보다. 정말 같은 부류의 악마이며, 쳐죽일 반민족 반역자임이 틀림없다. 한 번 속는 건 실수이지만 두 번 속는 건 공범이다.
이런 영화가 많이 알려지고 퍼져 나갔으면 좋겠다.

2. 바울

내가 일사각오, God’s not dead, 신이 보낸 사람 등 국내외의 다양한 장르의 기독교 영화를 봤지만.. 얘가 성경 고증과 작품성, 비주얼 등을 고려했을 때 제일 뛰어난 작품인 것 같다. 정말 잘 보고 왔다.
북미에서는 이스터(..)에 맞춰서 지난 봄에 개봉했지만, 국내에서는 종교 개혁 기념일에 맞춰서 10월 말에 개봉했다.

14년 전의 Passion of Christ는 분위기가 전반적으로 음침 암울하고 오로지 예수님이 잔혹하게 채찍질 당하는 장면 말고는 남는 게 별로 없어서 인상이 안 좋았다. 하지만 이 영화는 영화 특유의 교묘한 심상 왜곡이랄까, 그런 게 별로 없었다. 내가 느끼기엔 말이다.

스데반이 돌에 맞아 죽는 것, 사울의 회심 등 주요 장면들 다 나온다. 대사 중에 성경 말씀 인용이 굉장히 자주 나와서 아주 마음에 든다.
사울이 회심 후에 무슨 물고문 당하듯이 물에 얼굴까지 첨벙 잠겼다가 나오는 장면이 있다. 이게 침례를 의도한 장면이었다면, 난 평가 점수를 더욱 올려 줄 생각이다. 물 뿌리는 세례는 고증 오류이다.

그리고 촛불과 온갖 신들 형상(마리아 형상도 포함) 앞에서 기도하는 장면이 대부분의 영화와 드라마에서는 긍정적인 심상으로 그려지지만 여기서는 로마인들의 잡신이라는 부정적인 심상으로 그려진다. 이것도 구도를 아주 잘 잡았다.

그러면서 허구 각색도 어색하지 않게 가미된다. 사랑하는 교회 동지가 어이없게 억울하게 살해당하자, 남자 청년들 일부가 극도로 흥분하고 분노해서 우리도 칼 들고 쳐들어가서 로마를 상대로 보복하자고 날뛴다.
바울은 회심 전에 자기가 죽이면서 눈 마주쳤던 크리스천들이 때때로 꿈에 나와서 트라우마를 안긴다면서 인간적인 고뇌를 호소하기도 한다.

누가는 직업이 의사이다 보니 교도소장인 로마 군인의 딸의 병을 극적으로 고쳐 준다. 무슨 오글거리는 기도 한 방으로 신앙 치료를 성공한 게 아니라, 자기 의술로 해낸다. 바울 역시 “자기는 소문과는 달리 아무 능력 없으며, 자기가 약함을 보일수록 그리스도께서 역사하셨다”라고 증언한다. 요런 식의 개연성 있고 자연스러운 허구 말이다.

그런 일이 있었지만 그래도 인간 횃불 될 사람은 되고, 사자밥이 될 사람은 그렇게 되면서 순교 행렬이 이어진다. 네로의 명령이 떨어지자 바울은 딤후 4:6-8의 유언을 남긴 뒤 예정대로 참수당한다. 그래도 교도소장은 바울과 누가의 인품에 충분히 감화됐기 때문에, 마치 옛날에 안 중근 의사를 존경하게 된 뤼순 감옥 간수처럼.. 사형장으로 끌려가는 바울을 "잘 가시오" 이렇게 공손하게 댄디하게 대해 준다.

바울은 그나마 로마 시민인 덕분에 화형 같은 더 끔찍한 방법으로 죽지는 않고 저렇게 일반적인(?) 방법으로 처형된 거라고 전해진다.;;
그리고 한 가지 짚고 넘어갈 점은.. 바울과 네로는 모두 AD 60년대 중후반에 죽은 꽤 옛날 사람이라는 것이다. 이때는 로마 제국에 콜로세움 경기장이란 건 아직 없던 시절이었다. (약간 뒤인 AD 70년대, 베스파시아누스 황제 때부터 등장)

네로 시절에 크리스천들이 로마 대화재의 주범이라는 누명을 쓰고 억울하게 박해받고 처형당한 건 사실이다. 하지만 우리가 흔히 생각하듯이 원형 경기장에 우루루 풀려나가서 사자밥이 되어 순교하는 것과 "네로 황제"하고는 엄밀히 말해서 시기적인 연결 고리가 없다.
그러니 영화의 묘사는 엄밀히 말하면 고증 오류이다. 하지만 뭐 심각한 오류는 아니다. 60년대건 70년대건 시기가 그렇게 심하게 차이가 나지는 않으며, 콜로세움 안이건 아니건 크리스천들이 잔혹하게 죽임을 당한 건 변함없으니 말이다.

신약 기독교라는 게 생겼던 당시에, 예수쟁이들은 불신자들이 보기에 도저히.. 뭐라 한 마디로 정의내릴 수 없고 정체를 알 수 없고, 세속적인 관점에서는 도대체 무슨 이익을 노리고 왜 저런 식으로 사는지 도저히 이해가 불가능한 이상한 집단이었다.
남들이 다같이 믿는 신을 안 믿고, 황제를 반신반인으로 숭배하지 않으며, '예수'라는 웬 듣보잡 목수 출신 유대인이 죽었다가 뿅 부활했다는 황당한 악성 루머를 퍼뜨린다는 점에서는 분명 미친놈 왕따 아싸 반동분자 그 자체였다.

그런데 대놓고 국가 권력에 반역하고 싸우려 드는 여느 독립투사나 정치범 사상범 같지는 않고, 이웃으로서 개인 단위로 만나 보면 행실도 그렇게 나쁘지 않아 보인다. 무슨 마술사 초능력자도 아닌데.. 자기들의 세속적인 통념과 계산으로는 도통 이해가 되지 않는다는 것이다. 히 11:38이 말하는 것처럼 서로가 상대방을 감당할 수 없었고 무가치한 존재로 여길 수밖에 없었다.

그리고 신자들은 지금처럼 아무나 “우리 교회로 오세요, 예수 믿고 복 받으세요”는 개뿔.. 언제 잡혀가서 죽을지 모르는 파리 목숨 같은 처지였다.
모르는 사람이 교회 회원으로 가입하겠다고 하면 얘가 진짜 동지 형제인지, 아니면 우리를 밀고할 가짜 끄나풀 첩자인지 판별하는 게 급선무였다.

사람이 다른 사람의 마음을 읽을 능력이 없으니.. 이럴 때 판별을 빨리 할 수 있게 도와주는 건 믿을 만한 이웃 교회 지도자의 ‘추천서, 보증서’였다. “우리가 보내는 이 형제는 스파이가 아니고 믿을 만한 사람입니다. 잘 대해 주세요~”
우리나라에서 옛날 건군 초기에 숙군 작업을 할 때도 “이 사람은 빨갱이가 아님을 내가 보증합니다”가 아주 유효했던 것처럼 말이다.

아무쪼록 이 영화를 보면 신약 교회가 이렇게 시작됐고 신약 성경의 대부분은 저런 여건 속에서 기록되고 필사됐다는 것을 얼추 실감할 수 있다. 복음은 뭔가 GPL 라이선스 오픈소스 같은 프로그램이라는 것을 알 수 있다.
그리고 종이와 펜이 귀하던 시절에 감옥에 갇힌 채로 찬송가를 부르려면 가사를 평소에 다 외운 상태여야 한다는 것도 알 수 있다.

클래식 교과서적인 명작 영화는 옛날에 벤허 같은 것 말고는 이제 자본주의 논리 앞에서 완전히 멸종하지 않았나 싶은데, 아직도 이런 영화가 만들어지긴 한다. 생각을 바꿔도 될 것 같다.
그리스도 안의 지체로서 바울은 꼭 볼 가치가 있음을 추천하는 바이다.

Posted by 사무엘