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

1.
우리나라에 가장 먼저 등장한 열차 등급 내지 차급은 버스로 치면 시외/고속버스와 대등한 격인 '일반열차'이다. 우리나라 말고 외국도 마찬가지일 것이다.
우리나라의 일반열차는 1435mm 표준궤 기반이다. 일제 시대 때 금강산선에서 잠시 직류 3000V짜리 전철이 운행되기도 했지만 해방 후에 교류 25000V 가공전차선 방식이라는 전철 규격이 마련되었다.

문맥에 따라서 일반열차는 KTX 같은 고속철도 열차와 대비되는 개념으로 쓰이기도 한다. 하지만 그건 일반열차 안에서의 차종 등급의 차이를 나타내는 문맥에서만 성립한다. 운임 체계라는 문맥에서는 고속열차 역시 기존 재래선 열차보다 임률이 더 높은 일반열차의 최상위 등급일 뿐이다. 이 점에서 오해 없으시기 바란다.

그 뒤 1974년에 서울 지하철이 수도권 광역전철과 직통하는 형태로 개통하면서 편의상 '도시철도'라고 일컬어지는 새로운 운임 등급과 차량이 등장했다.
도시철도는 (1) 시내/광역버스와 환승 할인이 되는 독자적인 운임 체계를 사용하며, (2) 승강장이 고상홈 형태이고, (3) 내부 좌석이 앞을 보는 게 아니라 옆을 보는 형태로 길게 놓였고 (4) 지정석이 전혀 없는 자유석이라는 차이가 존재한다.

여기에 쓰이는 차량은 궤간과 덩치는 일반열차와 별 차이가 없었다. 단지, 광역전철 말고 순수 지하철은 전기 규격만 직류 1500V라는 고유한 더 작은 규격을 사용하게 되었다.
일반열차 중에서는 격이 제일 낮은 통일호와 비둘기호가 이런 입석 통근형에 근접했었다. 하지만 얘들은 본격적인 도시철도용 전동차와 시설이나 위상이 완전히 같지는 않았으며 전기로 달리지도 않았다.

그 뒤 서울 말고 타 지방의 지하철에는 이 차량보다 폭이 수십 cm 남짓 더 작은 '중형' 전동차라는 게 등장했다. 기존의 서울 지하철 차량은 '대형'인 셈. 우리나라에 등장한 최초의 중형 전동차는 부산 지하철 1호선이다. 그 뒤 대구 1~2, 인천 1, 광주 다음으로 대전 지하철이 국내에 개통한 마지막 중형 전동차 도시철도이다.

그 뒤 2010년대부터는 이것보다도 규모가 더 작아진 '경전철'이 등장했다. 대전 지하철 전동차까지는 차량의 폭이 약간 크냐 작냐의 차이가 있지만 중전철이었다. (重전철 中형 전동차, 또는 大형 전동차)
경전철은 쇠바퀴 또는 고무바퀴 버전으로 나뉜다. 쇠바퀴 버전은 궤도는 기존 철도와 완전히 동일하고 전기 규격이 직류 750V 제3궤조 집전식으로 더 작아졌다. 위에 전선이 치렁치렁 매달려 있지 않다는 것이다.

2.
일반열차보다 규모가 작은 이런 도시철도는 정말로 지방 지하철이라는 좁은 의미의 '도시철도'가 있는가 하면, 도시와 도시 경계를 넘나드는 광역전철도 있다. 버스에도 시내버스와 시외· 고속버스의 사이에 광역 좌석버스가 있듯이 말이다.
공항철도는 일반 완행열차는 광역전철에 가깝고, 직통열차는 일반열차에 가까운 위상이다.

일반적으로 광역전철은 그냥 코레일이 운영하고 지방 지하철은 각 지방의 공기업이 운영하는 것이 관행이었다. 하지만 요즘 추세는 꼭 그렇지 않다.
공항 철도는 공기업과 사기업을 정말 복잡하게 오락가락 하면서 경영 주체가 바뀌어 왔으며, 신분당선은 사기업이 운영하는 광역전철의 대표적인 사례로 자리매김 했다.

요즘 광역전철은 찔끔찔끔 급행 운행뿐만 아니라 용문 대신 지평 시종착(하루 4회 중앙선), 상봉 대신 광운대 시종착(하루 단 2회 경춘선), 왕십리 대신 청량리 시종착(하루 8회던가 분당선)처럼.. 극히 드물게나마 최대한 더 길게 운행하려는 시도도 하고 있는 게 인상적이다. 서울 지하철에서도 장암 같은 역은 열차 운행이 매우 뜸한 곳이긴 하지만 하루 운행 횟수가 열 손가락으로 꼽을 정도인 건 아니니 말이다.
그리고 공항철도가 마곡나루-김포공항은 서울 지하철 9호선과 비슷하게 따라가듯, 신분당선은 정자-미금 구간은 기존 분당선과 나란히 따라간다는 유사점이 있다.

다음으로 수도권의 경강선이나 부산의 동해선 광역전철은 깔끔하게 코레일 단일 관할인 반면, 서해선은 운영사가 '소사원시운영'을 비롯해 여러 계층으로 복잡하게 나뉘는 것 같다.
우리나라는 수도권이 아닌 다른 지역에 광역전철이 개통한 것 자체가 무려 2016년 말부터로 너무 늦은지라(동해선), 광역전철에 대한 개념이 정서적으로 좀 생소하다. 그래도 수도권이 아닌 지역에서 수도권 같은 대형 전동차를 구경할 수 있게 된 건 흥미로운 일이다.

서울 메트로는 도철과 통합되어 서울 지하철 1~8호선을 관할하는 매우 거대한 지하철 회사가 됐는데.. 9호선의 2~3단계 연장 개통 구간과 심지어 부산-김해 경전철까지 자회사를 통해 운영하고 있다. 한 도시의 지하철 회사가 다른 지역의 지하철에까지 손을 뻗치는 건 비행기 국제선에다 비유하자면 항공 자유화 협정의 단계수가 쭉 올라가는 것 같은 모습이다. (A국의 항공사가 B국 국내선 노선까지 개설해서 영업??)

그러고 보니 부산-김해 경전철은 성격상 광역전철인데 중전철이 아닌 경전철이라는 점이 이색적이다.
한편, 경전철이라고 해서 옛날 구식 철도처럼 협궤를 쓰지는 않는다. 궤간은 표준궤인데 차량의 축중 하중이 얼마 이상/이하인지에 따라 말 그대로 경전철과 중전철을 구분할 뿐이다.

* 참고로, 1435mm 표준궤다, 762mm 협궤다 하는 기준은 왼쪽 궤조의 맨 오른쪽 끝에서.. 오른쪽 궤조의 맨 왼쪽 끝까지의 거리를 말한다. 그런데 궤조 하나의 단면은 그냥 | 같은 세로줄이 아니라 일종의 工자 모양이다. 그렇기 때문에 工을 구성하는 | 세로줄 자체는 간격이 1435mm보다 약간 더 벌어져 있다. 이 점을 참고할 필요가 있다.
그렇다면 요즘 부설되는 표준궤 철도에서 양 工의 실제 간격은 얼마나 될까? 그에 대해서는 자료를 얻기가 의외로 어렵다. 工의 부위별 크기 자체도 딱 통일된 게 아니어서 그냥 정하기 나름인 것 같다.

Posted by 사무엘

마음 울적한 날에 거리를 걸어 보고 향기로운 칵테일에 취해...는 아니고, 국뽕을 한 사발 거하게 혈관에다 주입하고 취하고 싶어졌다.
그래서 본인은 올 3월에 리모델링 개관했다는 원조가카 기념관에 다녀왔다.
김치 한복 된장 정도로는 택도 없고 한글이나 할배, 원조가카 정도는 돼야 국뽕의 재료가 될 수 있지 않겠나.

본인은 저기에 2012년, 2017년 이렇게 두 번이나 가 봤지만, 지금까지 이렇게 독립된 블로그 글을 통해서 후기를 올린 적은 없었다.
작년 말에는 기념관 근처를 지날 일이 있었는데 웬 공사로 인한 휴관/폐관 상태였다. 안 그래도 나라 분위기가 뒤숭숭한데 저기도 정치 보복, 이념 보복을 당하고 있기라도 한지, 이화장처럼 공사를 가장한 무기한 폐쇄 상태는 아닌지 불길한 생각이 잔뜩 들었다.

그래도 기념관은 우려와 달리 다행히 깔끔하게 리모델링이 잘 됐고, 올해 삼일절부터 재개장했다.
전에는 이름이 좀 오해의 여지가 있게 '기념 도서관'이었는데(실제 의미는 기념관 및 도서관), 리모델링하면서 확실하게 '기념관'이라고 이름도 고친 듯하다.

전에는 원조가카의 어린 시절 개인사에 대해서 이 정도로 자세하게 나와 있지는 않았던 거 같다.
어쩐지, 옛날에 "만화 박정희"라고 민족 문제 연구소에서 박통에 대해 아주 부정적으로 묘사한 책에서도 박통이 어린 시절에 나팔 부는 모습이 묘사되어 있다.

"금강산까지는 철원에서 열차를 타고 이동하였다."
아아, 원조가카도 어린 시절에 금강산선 열차를 타 봤구나~! 기념관에서 읽은 제일 반가운 문구였다.

보다시피 원조가카는 지금으로 치면 교육 대학교와 군 사관학교 두 곳을 나왔다. 둘 다 안정된 진로와 명예가 보장된 코스이며, 공부를 대충 쉬엄쉬엄 해서 갈 수 있는 곳은 아니다. 확실히 똑똑한 사람이긴 했음이 틀림없다.

원조가카가 이뤄낸 것들..
x축은 61년부터 79년까지 시간이고, y축은 경제 정책 전반, 토목 건설, 과학 기술, 새마을 운동, 안보· 국방, 교육· 문화· 복지 이렇게 카테고리별로 박통이 만든 것들을 소개해 놓은 게 무척 유익했다.
또한, 저 테이블이 있는 방의 중앙에는 각종 토목 공사들의 준공식 때 원조가카가 테이프를 끊는 용도로 사용한 금색 가위들이 전시돼 있었다.

원조가카가 재임 기간 동안 해마다 저렇게 표어, 모토랄까 슬로건이랄까.. 그런 걸 제정했다는 얘기는 처음 들었다.
예전에도 말한 바와 같이 리 박사 할배는 이름을 지어 준 게 많고, 원조가카는 뭔가 글씨를 쓴 게 많았다.

사람들이 공업화 산업화가 환경을 꼭 파괴만 하는 줄 아는데, 사실은 그렇지 않다.
더티한 화석 연료는 역설적으로 나무를 땔감용으로 벨 일이 없게 해 준다. 그리고 원자력은 그 다음 화석 연료를 쓸 일을 줄여 준다.

우리나라의 산림 녹화는 석탄 산업 육성과 맞물린 덕분에 성공했는데.. 지금은 그 석탄 산업도 망했다는 게 아이러니이다.

쉽게 말해 1950년대 할배 시절에는 아직 국가 차원의 의료 보험이라는 게 없었다.
그러다가 박통 때 일단 공무원을 대상으로 먼저 의료 보험이 시작되었고, 이게 지금처럼 전국민에게 몽땅 시행된 것은 박통에다 전대갈 시절까지 지난 1989년부터이다.

그 이름도 유명한 국민 교육 헌장이다.
멸사봉공 진충보국스러운 표현 일색이라고 트집을 잡자면 한도 끝도 없이 잡을 수 있겠지만, 본인은 "능률과 실질을 숭상하고"라는 문구는 예사롭지 않게 들린다. 왜 그런지에 대해서는 본인이 몇 년 전의 블로그 글에서 언급한 바 있다.

지금까지 원조가카의 치적이 잔뜩 소개된 뒤, 맨 마지막에 '유신 -- 대통령의 고뇌와 결단'이라는 글자와 함께 엄격 진지 근엄한 표정의 가카 마네킹.. 요렇게 꾸며진 어두운 방이 나왔다. 참 웃겼다.
"머릿속에 구상해 놓은 계획이 아직 한참 남았는데, 벌써 물러나기에는 이 몸이 국가와 민족을 위해 해야 할 일이 너무 많은데, 아직도 북괴의 위협은 여전한데.." 아이고...;; ㅋㅋㅋㅋ

지금 이 2010년대에도.. 이놈의 헬조선은 답이 없다고, 영어만 되면 그저 외국으로 뜨는 것만이 최선이라고 생각하는 분이 많다. 미개한 조센징들은 국민성이 민주주의와 맞지 않고 불도저형 독재자가 한 명 나와서 싹 다 갈아엎어야 나라가 제대로 돌아갈 거라고 생각하는 분도 많다.

하물며 완전 전쟁 폐허 거지꼴이던 1960년대에는 사람들 생각이 어땠을까? "우린 안 될 거야 아마" 노예근성 패배의식이 얼~마나 만연했을까?
자국의 미개한 실상과 조센징의 국민성에 너무 절망한 나머지... 애초에 구한말 때부터 단군의 후손들은 다 일본 밑으로 들어가는 게 낫겠다고 진지하게 생각한 '신념형' 친일파도 있었다. 대표적인 예가 윤 치호이다.

지금으로 치면 그냥 나라 간판 내리고 천조국의 50몇 째 주로 편입해 들어가자는 식으로 말이다. 기회주의 권력 지향 매국노라든가 생계형 부역자, 싸이코패스 악질 헌병 같은 부류와는 성격이 다르다.

그런 절망적인 상황에서 원조가카라는.. 조선인에게 너무 과분했던 위대한 지도자가 등장해서 조선을 대한민국으로 업그레이드 시켰다. 사람들의 의식부터 개조하면서 "우리도 할 수 있다", "피똥 싸는 가난 물리치고 잘 살아 보세"라고 독려했다. 고속도로 놓고, 발전소 짓고 공장 짓고, 과학 연구소 만들고, 기능공을 양성했다.

성경의 느헤미야처럼 "일하면서 싸우고 싸우면서 일하자"(느 4:16-18)를 전파했다.
역대기하 26장에 나오는 웃시야 왕처럼 농사 시스템을 개선하고 신무기를 개발하고 기계(엔진)를 만들었다.
이런 사람이면 10년이고 100년이고 독재 하면서 종북 용공 빨갱이 자식들은 다 죽여서 씨를 말려 버렸어야 했는데.. 거기까지 바라기에는 원조가카도 역량이 한계가 있었다. 반동분자들을 너무 관대하고 너그럽게 다뤄서 말이다.

전시관을 다 보고 나면 이렇게 쾌적한 독서와 공부 공간이 나온다. 옆에 도서관과 카페도 있다.

전시관 내부에 있는 추모 공간의 벽면 모습이다. 우리나라 사람들은 0에서 1을 만든 할배 다음으로 1에서 100을 만든 선한 독재자 원조가카에게 큰 빚을 지고 있다.

그는 반일· 항일을 가장 수준 높게 실천한 사람이다.
소싯적에 일본군 장교를 지원해서 들어갔다고?
뭐, 항일 독립운동을 한 것보다야 비주얼 모양새가 안 나오는 건 사실이다. 하지만 아예 조선이라는 나라가 없던 시절에 일제로부터 월급 받는 직업에 종사한 것 자체만으로 친일 반민족질이라고 매도할 수는 없으며, 원조가카가 아예 헌병대 장교로 들어와서 자국 안에서 동포들을 괴롭히고 착취했다는 증거는 어디에도 없다. 오히려 독립 운동이라고는 맥이 다 끊긴 1940년대에 동족도 없는 먼 변방에 나가서 중국군하고나 싸웠지.

그는 선생까지 됐는데도 굳이 더 고생해서 군인으로 신분을 업그레이드 했으며, 긴 칼 차고 돌아와서는 선생 시절에 자기를 깔보던 일본인들을 버로우 태우고 데꿀멍 시켰다. 그냥 현실 불만족과 출세욕 때문에 그랬을 뿐이다.
이 정도는.. 카이스트(국비 장학생..;;) 나와서 국내 대기업 내지 연구소에서 몇 달 근무해 봤는데, 헬조선 이공계의 현실에 만족하지 못해서 의대나 로스쿨로 다시 진학한 정도의 일탈일 뿐이다! 그 이상의 악질적인 짓은 아니라는 것이다.

할배 시절의 반민특위 해체와 친일 부역자 재등용에 대해서는 애산 이 인의 판단이라든가, Windows 9x의 16비트 코드 재사용과 같은 반박 비유가 있다. 그리고 원조가카의 과거에 대해서는 딱 저런 비유를 들어서 대처하면 된다.

내가 단언하건대 원조가카는 되도 않은 욕지거리 험담 늘어놓는 머저리들, 그리고 그들이 대안으로 내세우는 사상 불순한 정치인들보다 인품, 그릇 크기 등등이 0이 몇 개는 더 붙은 정도로 더 위대하고 훌륭한 사람이다.
그 시절에 전혀 통용되지 않았던 오늘날의 관행, 그 시절에 절대로 실현 불가능했던 일, 자기도 절대로 실천하지 못했을 도덕 청렴을 이루지 못했다는 식의 일고의 가치도 없는 생트집 불평에는 귀 기울일 필요가 없다.

맨날 천날 일제 잔재 탓, 군사 문화 탓만 하는데.. 비록 거기에도 악한 것 잘못된 것이 있긴 했어도 195, 60년대까지만 해도 남한 땅에서 군대는 어지간한 민간 싸제보다는 더 똑똑한 사람들의 집단이었고 선진 문물을 많이 접할 수 있는 곳이었다. 일본만 해도.. 그 일제 잔재의 원산지 본거지가 어찌 그렇게도 선진국이 됐고 노벨 상 수상자까지 배출하는 과학 기술 강국이 됐는가? 역사로부터, 자기보다 잘난 사람으로부터 배우지를 않고 저런 썩은 사고방식으로만 살아서는 평생 찌질이로 살 수밖에 없을 것이다.

Posted by 사무엘

1. 구원 관련 개념 복습

예전에도 신앙 관련 글을 쓰면서 여러 번 언급한 바 있지만, 성경적으로 인간이 구원받는 길 내지 방법은 오로지 예수 그리스도밖에 없다. 예수 그리스도의 의를 내 것으로 만들기 위해 필요한 것이라고는 알량한 믿음이라는 제일 바보같고 나약한 자유의지가 전부이다. 그것 말고 다른 어떤 외모나 스펙이나 능력도 필요하지 않다.

그리고 예수 믿을 정도의 지적 능력조차도 없고 스스로 선과 악을 분간 자체를 할 수 없는 너무 어린 애들, 정신지체 박약아는.. 그냥 무조건 구원 받는다. 걔들도 따지고 보면 죄가 있지만 죄에 대한 책임이 부과되지 않기 때문이고.. 예수님을 믿을 능력이 없지만 그분을 거부할 능력도 없어서 거부하지 않았기 때문이다.

성경에 없는 용어이지만 본인은 이 개념을 편의상 '특례 구원'이라고 일컬어 왔다. 이런 극단적이고 예외적인 경우는 이 블로그를 찾아와서 이 글을 직접 읽을 정도의 분들에게는 해당사항 없으니 신경 쓸 필요 없다. 수학에다 비유하면 방정식의 근 중에서 그냥 너무 자명한 trivial solution과 비슷한 개념이다. 생물학으로 치면 무성 호흡/생식 같은..??

이런 논리를 따라, 본인은 어린아기들이 병이나 사고로 죽으면 원죄 때문에, 혹은 유아세례를 안 받았기 때문에 지옥 간다는 말도 안 되는 교리를 일단 전혀 믿지 않고 부정한다.
그리고 하나님의 주권과 섭리를 너무 강조하는 나머지, 인간의 일체의 자유의지를 부정하고 "선물 받으실 분?" / "저요, 저도 좀 주세요!"라고 응답하고 손 내미는 것도 자기의 의이고 선물에 대한 대가(!)인 것처럼 이상하게 몰아가는 설명도 배격한다.

'무조건적인 선택'과 '거부할 수 없는 은혜'는 앞서 언급했던 '특례 구원'에 대해서는 정확하게 성립한다고 본인은 생각한다. 그 상태를 '전적 타락'이라고까지 부르는 건 '글쎄요~' 싶지만 말이다. 하지만 그 밖의 문맥에서는 인간이 얼마든지 제 발로 구원의 길을 거부하고 지옥 갈 수 있다. 그리고 그건 하나님의 전지전능이나 사랑이나 공의하고는 아무 상관 없는 현상이다.
하나님이 원하시는 뜻과 허락하시는 뜻을 분간하지 못하면 정말 온갖 골때리는 오류가 발생하게 된다. 6· 25 대한해협 해전 때의 동해상의 북괴군 600명하고, 광주 5· 18 북괴군 600명을 헷갈리듯이 말이다.

직접적으로 동일한 문맥을 다루는 구절은 아니지만 눅 14:16-21 같은 비유 얘기를 봤을 때... 그리고 인류 역사와 지금 세상 현실을 고려했을 때..
추측하건대 미래에 하늘나라에 가 보면 믿어서 구원받은 사람보다는 특례 구원을 받은 사람이 훨씬 더 많긴 할 것 같다.

마치 증기 기관이 주변에서 흔히 볼 수 있는 교통수단의 동력원으로서는 완전히 도태했지만 발전소에서 전력 생산용으로는 압도 다수인 주류이듯이(화력, 원자력이 모두 증기 터빈을 돌리므로!)...
선박이 장거리 여객에서는 비행기에 밀려 완전히 도태했지만, 일반인들 눈에 직접 보이지 않는 물류에서는 여전히 본좌이듯이..

그때가 되면 우리가 일상적으로 보지 못했던 큰 그림을 보게 되지 싶다. 민망하고 불편한 진실이지만, 언론에서 정치적으로 이용해 먹을 가치가 없어서 외면하고 있는 죽음이 이 세상의 음지에서 얼마나 많이 자행되고 있겠는가?

참 오랜만에 구원 기본 개념에 대해 복습해 보았다. 구원의 영원한 보장에 대해서도 얘기할 것이 많은데.. 시간과 지면 관계상 자세한 설명은 생략하겠다. 구원만 받고 어리고 육신적인 신자에 대한 개념이 잘 이해되지 않으니 사람들이 자꾸 구원의 영원한 보장을 의심하며, 심지어 자살하면 지옥 간다는 식으로 잘못 생각하는 편이다.
자살은 인간이 저지르는 다른 끔찍하고 흉악한 죄들보다 특별히 다르게 취급해야 할 이유가 전혀 없다. 국가와 민족을 위해 의롭게 자결했다고 구원을 얻지는 못하듯, 세상 비관해서 혹은 고문 당하는 게 두려워서 자살했다고 해서 구원을 잃지도 않는다.

2. 성경과 세속 과학, 학문과의 관계

정말 객관적으로 관찰하고 실험만 하는 과학이라면, 그 알량한 방법론을 동원해서 신의 존재를 대놓고 증명하거나 반증할 수는 없다. 사실은 교계에서 그렇게도 정죄하는 진화론을 절대무오한 진리라고 입증하지도 못한다. 그쪽 세계에서는 실험 결과에 따른 귀납적인 학설과 확률과 통계만이 있을 뿐이다.

원래 과학과 종교?신앙?은 서로 별개의 영역인 게 맞다. 그럼 창조니 진화니 하면서 싸울 필요가 없는 건가? 마냥 안심하면 되냐? 그렇지는 않다.
과학 그 자체는 자연 계시에 대한 체계적인 연구이기 때문에 가치 중립적이다. 잘 연구해서 나쁠 것 없다. 그러나 거짓되이 과학이라고 불리는 학설이 대놓고 신을 부정할 수는 없더라도, 그 사고방식이나 연구 방법론· 패러다임을 잘못 적용하여 성경에 대한 믿음을 파괴할 수는 있다. 이게 파괴된 신자는 진짜 볼장 다 본다.

"성경에 어차피 요런 부분에는 오류가 있다. 그렇다고 해서 기독교나 성경의 존재 가치가 싹 부정되는 건 물론 아닐 거다. 하지만 성경의 다른 부분에 기록돼 있는 엄청나고 극단적인 예언들도 그렇게 정밀하게 문자 그대로 믿을 게 못 된다는 거다. 비유와 교훈 등 우리에게 좋은 쪽만 재해석해서 받아들이면 된다. 히브리어를 보면 어떻게 그리스어를 보면 어떻고.."

요게 아주 위험하고 돼먹지 못한 사고방식이라는 것이다. 성경을 바르게 나누지 않고 특정 부분만 분별 없이 무식하게 문자적으로 밀어붙이면서 물의를 빚는 교파 종파에 대해서도 본인이 모르는 바는 아니지만.. 그런 오류에 대한 대안이 저런 지적 사기가 돼서는 안 된다. 본인은 성경은 세상의 여느 학문과 같은 방식으로 취급하고 접근해서는 안 되는 대상이라고 믿는다.

3. 성경에서 가장 자주 인용된 구절

성경에는 "곡식 밟는 소의 입에다 마개를 씌우지 마라"(신 25:4, 가축이 적당히 자유롭게 먹으면서 일하게 해 줘라)가 의외로 신약에서 두 번이나 더 언급된다. (고전 9:9, 딤전 5:18) 주의 일을 하는 사역자들의 보상과 관련된 문맥에서이다.

그리고 "의인은 믿음으로 살리라"가 합 2:4에서 '자기'(his)가 빠진 바리에이션으로서 세 번 더 나온다. (롬 1:17, 갈 3:11, 히 10:37) 이에 덧붙여 "네 부모를 공경하라"도 십계명인 출 20:12뿐만 아니라 신 5:16, 엡 6:2에서 반복되며, 복음서에서도 인용 형태로 마태· 마가· 누가에 거듭 등장한다.

그런데 이것뿐만 아니라 뭔가 좀 생뚱맞아 보이는 구절도 성경에서 톱급으로 자주 거듭 반복해서 인용된 게 있다. 바로 시 110:1이다. "내가 네 원수들을 네 발받침으로 삼을 때까지 너는 내 오른편에 앉아 있으라"
요한복음을 제외한 다른 세 복음서에서 연이어 copy & paste 수준이고(마 22:44, 막 12:36, 눅 20:43), 행 2:35와 히 1:13에서 추가로 나온다. 거기에다가 히 10:13도 재차 언급이라고 볼 수 있으니.. 횟수가 가히 압도적이다.

"소의 입마개"만치 인간의 실생활과 관련이 있지 않고,
"부모를 공경하라"만치 보편적인 인륜을 다루지 않고,
그렇다고 "믿음으로 살리라"만치 인간의 구원과 관련이 있지도 않은 저 말은 도대체 누가 누구에게 언제 왜 한 말이고 문맥이 뭘까?

시간과 지면 관계상 저 구절의 모든 문맥과 의미를 강론할 수는 없지만, 간단히만 말하자면 저건 아버지 하나님이 아들 하나님에게 한 말이다.
성경은 도덕 경전이나 역사 기록이나 복음과 구원 안내서 역할을 할 수 있지만, 그건 부가적인 2순위 이하의 목표일 뿐이다. 그 전에 하나님의 주 관심사와 성경의 핵심 주제는 하나님의 왕국과 그분의 통치임을 알 수 있다. 세상 용어를 동원해서 표현하자면 다분히 정치적이다.

예수님이 이 땅에 계실 때 사람들은 온갖 시사· 종교 난제들을 가져와서 그분에게 질문을 했다. (부활의 때에 누구 아내? 율법에서 가장 큰 명령? 카이사르에게 납세? 등등등~) 떠보고 트집 잡으려는 불순한 의도로든, 아니면 정말 몰라서든지..

예수님은 그런 것쯤은 막힘없이 전부 즉답을 하셨고 사람들을 데꿀멍 시켰다. 그리고 그 예수님이 우리 인간에게 물으신 건 단 하나였다.

"그럼 이제 내가 니들에게 하나 좀 물어 보마. 너희는 내 정체가 정확하게 무엇인 것 같냐? 시 110:1을 봐. 다윗이 자기 비속 후손을 보고 '주'라고 존대해서 부르는데 이건 도대체 어찌 된 일일까?"
그 뒤로 사람들은 버로우 타 버리고 더는 예수님에게 딴지를 걸지 못했다고 성경은 말한다. 시 110:1은 그 문맥에서 인용되었으며, 그게 복음서에 3회 반복해서 기록되었다.

또한, 나중에 배반당하고 체포된 뒤의 행적도 생각할 만하다. 예수님은 자신에 대한 다른 온갖 쓰잘데기없는 거짓 고소들에는 하나도 대꾸하지 않았지만, "너 정체가 뭐냐? 넌 정말 하나님의 아들 그리스도냐?"라는 물음에는 정말 솔직 담백하게 대답하셨기 때문이다. (마 26:62-65, 막 14:60-63, 눅 22:66-71)

예수님은 사람들이 자기가 누구인지를 정확하게 알고 믿기만을 바라셨다. 예수의 부활조차도 곧이곧대로 믿기 싫고, 그래도 역사 팩트와 후폭풍 증거까지 송두리째 외면할 수는 없으니 제자들의 자칭 예수 부활 "체험" 사건 이 따위로 둘러대는 짓 하지 말라고 말이다.

하나님은 인간에게 무슨 "P와 NP는 과연 동일할까?", "리만-제타 함수의 자명하지 않은 근은 실수부가 정말 몽땅 1/2일까?", 아니면 "광주에 과연 북괴 공작원들이 잔뜩 침투되었을까?" 같은 걸 묻지 않으신다.
그런 건 관심 있는 사람들이 연구해서 답을 구하든가 말든가 하면 되고, 그 전에 정말 똑바로 알아야 하는 건 그리 높은 지능을 필요로 하지 않는 "너에게 예수는 어떤 분인가?" 하나이다.

요한복음은 시 110:1의 직접 인용은 없지만 기록 목적이 독자들 예수 믿게 하는 것(요 20:31)이라고 다른 어떤 복음서보다도 분명하게 대놓고 적어 놓았다.

4. 신앙 생활이 인간에게 유리하게 짜여 있는 것

예수 믿고 구원받은 뒤의 신앙 생활은 인간에게 철저하게 유리하게 짜인 것도 있고 불리한 구조로 된 것도 있다.
유리한 것은.. 뭔가 좋은 것을 사람이 "먼저" 받아서 동기 부여를 받은 뒤에, 그 다음에 사람 쪽에서 베풀고 헌신하고 인내하고 희생하는 구도라는 것이다.

먼저 구원부터 받고 나서 침례를 받든지 믿음의 선한 행위를 하든지 성장을 하든지가 그 다음에 이어진다.
일단 쉬고 나서, 달콤한 은혜의 말씀부터 먹고 나서, 즐기는 것부터 하고 나서 "그 다음에" 일을 하고 헌신한다. 일이 먼저가 아니다. 인간이 만든 세상 기업 중에 입사 후에 월급이건 일당이건 보수를 받고 나서 다음부터 일하는 곳이 있던가? 세상에서야 소득 주도 성장은 마치 "일단 서울대부터 보내 주면 나도 공부 열심히 할게요" 같은 미친 개소리이지만.. 성경적인 신앙 원리에서는 실제로 존재하는 개념이다!

다른 대부분의 종교에서 최종 목적지, 만렙, 해탈의 경지라고 말하는 '구원' 내지 성인 성자(saint) 칭호가 이 바닥에서는 그냥 기본으로 따 놓은 당상이다. 근성 충전을 위해 일단 한 대 맞고 시작... 이 아니라 일단 구원부터 받고 시작이다.
창세기 1~2장의 천지 창조만 생각해 봐도 하나님은 6일간 일하고 나서 일곱째 날이 쉬는 날이었지만, 아담과 이브는 만들어지고 결혼하고 honeymoon부터 즐긴 뒤부터 동산 관리 일과가 시작되었다. 그리고 마리아와 마르다 얘기도 있다(눅 10:38-42).

그 반면, 인간에게 불리하게 짜여 있는 것, 혹은 이것까지 보장해 주지는 않는 사항도 있다.
신앙 생활이란 건 본질적으로 당장 보이고 들리는 대로, 편한 대로 직관적인 대로, 남들 다 하는 대로 사는 게 아니다. '바보 같아 보이고 손해 보는 듯이 보이는 좁은 길 역행'을 감내해야 한다는 것이다. 이 모든 결단과 행동은 각 개인이 자발적으로 직접 해야 한다. 그리고 자기가 심은 대로 거둬서 물리적인 여건이 요 모양 요 꼴이 된 것을 하나님이 굳이 수습해 주고 undo 해 주시는 경우 역시 일반적으로는 없다.

그렇다고 해서 신앙 생활이 무슨 공밀레 같은 신밀레 열정페이 착취는 절대 아니다.
인간이 인간의 본성· 성품으로 감당하기 어려운 것, 단단하고 입에 쓴 말씀, 실행하기 힘든 것에 대해서는 최소한 하나님이신 예수님이 먼저 다 당하고 겪어 놓았다. 그때는 이런 믿는 구석으로 요렇게 하면 된다고 선례, 모범, 샘플이 마련돼 있다.

어려운 시험 문제나 과제에 대해 원리, 예제, 유사한 기출문제, 힌트를 듬뿍 주긴 한다. 그러나 대놓고 정답을 가르쳐 주는 일은 결코 없으며, 하물며 시험 문제를 미리 유출해 줄 리는 절대 만무하다. 모든 과제는 자신의 문장을 써서 직접 해야 한다.

하나님의 입장에서 인간에게 절대로 '안알랴줌'인 것의 대표적인 예는.. 세대 경륜 급의 큰 그림 이상으로 각 개인의 구체적인 미래 예언, 그리고 예수님의 재림 시기이다. 나에게 내일 어떤 일이 닥칠지는 완전 랜덤 케바케이다.
그것만 좀 알면 딱 죽기 직전에만 예수 믿고 구원을 먹튀할 수도 있을 것이고, 인간의 입장에서는 굉장히 꼼수 부리면서 편하게 살 수 있겠지만.. 하나님이 겨우 그런 걸로 농락당하는 시스템을 만들어 놓지는 않으셨다.

자, 유리한 것과 불리한 것을 비교해 보면.. 신앙 생활 할 만하겠다는 생각이 드시는가, 어떤가?

5. 예외적으로 허용되는 것

• 군대는 일반적으로 최악의 범죄라 여겨지는 살인이 제한적으로 허용되는 집단이다. 하지만 자기 집 지키느라 불가피한 정당방위도 허용되는 마당에, 하물며 나라를 지키느라 지휘관의 명령대로 전쟁터에서 무장한 적군을 죽이는 것은 형법상의 살인이 전혀 아니며, 오히려 정반대로 숭고하고 영예로운 일이다.
• 국정원 같은 첩보 기관은 "악에는 악으로 맞선다, 이이제이, 목표는 수단을 정당화한다"가 제한적으로 허용되는 집단이다. 절대악을 퇴치하기 위해 필요악 역할을 맡고, 작은 악을 동원해서 더 큰 악을 예방하는 궂은일을 한다.
  일반적인 상황이라면 이건 나쁜짓이며, 공산주의자 빨갱이들이나 사용하는 수법(거짓말, 위장 침투..)으로 여겨진다.

• 끝으로 종교는 겉으로 언뜻 보이는 결과만 보자면 정신승리, 진영논리, 권위에 호소하는 오류가 제한적으로 허용되는 분야이다. "생명은 생명으로부터만 나올 수 있다"라는 과학 팩트는 "그럼 최초의 생명은 도대체 어디서 어떻게?"를 설명하지 못한다. "닭이 먼저냐 계란이 먼저냐" 무한순환을 끊으려면 결국 처음에 한 번은 비논리적인 방법을 동원할 수밖에 없다.

예수 믿으면 물질적인 복 받고 부자 되지 않는다. 뭐, 그렇다고 북한이나 사우디아라비아 같은 극단적인 박해 지역이 아닌 한, 무조건 쫄딱 망하고 거지 되고 감옥에 갇히고 죽지도 않는다. 구원받아서 신분이 바뀌는 것과 개인이 물질적으로 잘 되거나 못 되는 건 별로 유의미한 상관관계가 없다.
또한, 국가 차원에서 사회가 전반적으로 성경적인 건전한 경제관과 시스템이 갖춰져서 잘살게 되고 중산층이 늘고 부강해질 수는 있다. 하지만 이 역시 게으른 개인을 일일이 다 먹여 살려 주는 게 아니다.

예수 믿어서 확실하게 보장되는 것은 영적 복을 받고, 설령 가난하더라도 그 처지만으로 먹을 것과 입을 것이 있는 것, 주님께서 내게 지금 당장 허락하신 처지에 만족하고 감사할 줄 알게 되는 것이다. 나를 강하게 하는 그리스도를 통해서 내가 할 수 있게 되는 건 별 게 아니라 바로 이런 것들이다.

"남들보다 가난하지만 난 영적으로는 부자.." 영이건 정신이건 이것도 정신승리라면 정신승리이다. 하지만 이건 아Q의 정신승리와 달리, 성경적인 근거와 보장이 돼 있는 건전한 정신승리인 것이다.
상대적 빈곤에 연연하는 사고방식부터가 달라져 있지 않으면 어차피 하나님이 물질을 아무리 많이 공급해 주셔도 인간은 절대로 만족하지 않고 여전히 눈에 보이는 것에만 연연하면서 불만족 불평 악순환에서 헤어나오지 못할 테니 말이다.

Posted by 사무엘

인류는 19세기에 전깃줄을 이용한 전화라는 유선 통신 기술을 발명해 냈으며, 20세기 초에는 아예 전자기파를 이용한 장거리 무선 통신 기술까지 개발했다.
그리고 1960년대에는 통신 위성 덕분에 아예 둥근 지구의 반대편으로 전화와 TV의 전파를 실시간으로 주고 받는 게 가능해졌다. 위성 생중계가 최초로 시작된 올림픽이 1964년의 도쿄 올림픽이었다고 그런다.

그러니 유선 전화에 전혀 의존하지 않는 무선 전화도 오래 전부터 있긴 했다. 단지 기계값과 시간 당 통화료가 아주 비싸기 때문에 자동차나 선박에 장착되는 사치품 내지 아주 특수한 물건으로 취급되었을 뿐이다.
그러던 것이 1990년대 말부터는 그냥 전국민 1인 1휴대전화 시대가 시작됐다. 이를 위해서 전국 곳곳에 휴대전화 기지국이 건설되었으며, 각종 건물과 지하철 내부에도 중계기가 설치되었다.

전깃줄 중에 진짜로 전기를 보내는 용도로만 사용되는 굵은 송전선은 지상의 산들과 철탑 위로 아주 높고 길게 뻗어 있다. 요즘 만드는 도시들 내부에서는 지중화되어서 지하로 지난다.
다음으로, 동축 케이블이니 광섬유 케이블이니 하는 이름으로 데이터 통신을 담당하는 전깃줄들은 대륙과 대륙을 연결해야 하기 때문에 바다 밑으로 쫙 깔려 있다. 해저 지진이 나서 이런 케이블이 파손되면 주변 국가들의 인터넷 속도가 느려지는 사태가 발생한다.

인간이 지난 수십 년 동안 지구 곳곳에 깔아 놓은 통신 인프라를 생각하면 경이로움마저 느껴진다. 민간보다는 군용에 더 가까운 레이더(radar) 관련 기술도 말이다. 따지고 보면 레이더의 발명은 비행기의 발명 그 자체만큼이나 비행기의 운용· 관제 방식과 공중전의 양상을 근본적으로 바꿔 놓았다.

2차 세계 대전 당시에 일본에서는 자국인 과학자/공학자가 아주 훌륭한 레이더용 안테나(야기-우다 안테나)를 발명했는데, 그걸 군부에서 제대로 활용하지 않는 병크를 저질렀다. 그래서 정작 적국인 연합국(영국)이 그 기술을 활용해서 전쟁에서 일본을 관광 태웠다는 안습한 일화까지 전해진다.
레이더도 원래 레이저(laser)처럼 복잡한 단어들 이니셜로 만들어진 단어이지만, 지금은 그 자체가 새로운 형태소처럼 쓰인다.

그런데 경이로운 통신 기술은 지구 대 지구 스케일만 있는 게 아니다. 지구 대 우주 분야도 있다.
까놓고 말해 달에 착륙한 아폴로 11호 승무원들의 활동 동영상은 어떻게 해서 지구로 실시간 중계될 수 있었을까?
뉴 호라이즌스 호가 보낸 명왕성 사진은 어떻게 해서 지구로 잘 전달될 수 있었을까?
신호가 가는 데 편도로만 17시간이 넘게 걸린다는 보이저 탐사선은 어떻게 지금도 지구와 교신이 되고 있을까?

우주로 나가려면 적도 근처에다 우주 센터와 발사대를 만들고 로켓만 죽어라고 쏴 올릴 게 아니라, 로켓에 실린 탐사선이 보내 주는 정보를 넙죽넙죽 잘 받기 위한 통신 시설도 반드시 개발해야 한다. 그래서 미국 NASA에서는 진작부터 Deep Space Network(심우주 네트워크)라는 이름으로 전파 수신용 거대한 접시형 안테나 기지를 만들었다.

20세기 초· 중반까지만 해도 우주는커녕 지구 표면의 남극이나 에베레스트 산 정상을 탐험하는 사람들과도 실시간 무선 통신이 가능하지 않았으며 그들의 생사를 곧장 확인할 수 없었다. 주변 풍경 인증샷은 탐험가들이 카메라로 찍은 뒤에 무사 귀환할 때까지 필름을 반드시 잘 간수해야만 전해질 수 있었다!

아폴로 우주선의 달 탐사가 그런 식으로 답답하게 진행되지 않고 전세계 텔레비전으로 전파를 타고 생중계된 것은 매우 다행스러운 일이 아닐 수 없다.
이런 안테나 기지는 로켓이 실제로 발사되고 수많은 관중들이 몰리는 우주 센터보다는 존재감이 훨씬 덜하다. 하지만 이런 시설에서 일하는 사람들도 우주 탐사의 숨은 일등공신이라 불리기에 전혀 손색이 없을 것이다.

NASA 내부에서 이 안테나 기지를 관리하는 부서는 '제트 추진 연구소'이다. 이름만 봐서는 만년 발사체 연구만 할 것 같은 곳에서 통신망까지 연구한 것은 우연이 아니라 하겠다. 우리나라의 인터넷 인프라의 대부인 전 길남 박사/교수도 젊은 시절에 저기서 근무한 경력이 있는 것이 잘 알려져 있다.

저기는 비행기용 제트 엔진(터보 팬 같은..?)을 연구하는 곳이 전혀 아니다. 엄연히 산화제까지 같이 들어있는 우주 발사체용 로켓 엔진의 연구가 본업이다. 하지만 저 연구소가 처음 생겼던 당시에는 '로켓'이라는 단어가 그리 대중적이지 않았기 때문에 이름이 저렇게 붙은 것이다.

비슷한 다른 예로는 IBM이 있다. 이름에 '컴퓨터, 정보' 같은 단어가 들어가기에는 역사가 너무 긴 기업인 관계로, 오늘날까지도 고작 '국제 사무용품 기기'라는.. 마치 국제시장 같은 매우 낡은 명칭으로 통용되고 있지 않은가? 그래도 워낙 넘사벽급의 기술과 인지도를 자랑하는 세계구급 기업이니 이름 따위는 바꿀 필요가 없다.

제트 추진 연구소 때문에 이야기가 잠시 옆으로 샜는데, 다시 안테나 얘기로 돌아오기로 한다.
사진을 보면 알겠지만, 이들 기지에 만들어진 안테나는 지름이 30m대 내지 70m대까지 있을 정도로 매우 거대하다.
그리고 한 곳에만 있는 게 아니라 다음과 같이 대략 120도대의 경도 간격으로 세 군데가 존재한다. 그래야 임의의 지표면에 도달한 전파가 지구의 자전에 구애받지 않고 셋 중 적어도 한 곳 이상에서 언제나 수신 가능하기 때문이다.

• 미국 서부의 캘리포니아 바스토우 모하비 사막 (UTC-08:00)
• 스페인 마드리드 (UTC+01:00)
• 오스트레일리아 캔버라 (UTC+10:00)

보행자와 차들로 북적대는 육지의 도로와 달리, 비행기가 순항하는 공중이나 배가 항해하는 공해는 장애물이 없다시피하다.
하물며 우주의 스케일은 지구를 훨씬 능가한다. 우주는 정말 우리가 상상하기 어려울 정도로 너무 방대 광대하게 텅 빈 공간이다. 태양계 행성들의 크기는 행성들 간의 거리에 비하면 새 발의 피 수준에 지나지 않는다. 우주 탐사선은 한번 가속을 한 뒤엔 관성으로 한없이 등속 운동만 하면 되며, 전파도 그냥 조준만 잘 해서 쏴 주면 지구나 탐사선에 도착하는 건 그냥 시간 문제일 뿐이다. 다른 장애물에 부딪칠 걱정은 사실상 할 필요가 없다.

우주 공간에서 지구와 탐사선의 사이에 물리적인 장애물 걱정을 할 필요가 없는 건 일면 다행이다.
하지만 외행성 탐사선의 경우, 지구와 워낙 너무 멀리 떨어져 있기 때문에 전파도 진행하는 동안 점점 넓게 퍼지고 신호가 약해진다. 게다가 지표면에서는 주변에 숱하게 돌아다니는 지구 발 노이즈들을 걸러내고 그 약한 우주 발 신호만 증폭해서 받아야 한다.

신호를 보낼 때야 지구에서 최신 설비로 최고 출력 고주파로 그나마 최대한 빵빵하게 쏘겠지만, 가녀린 탐사선에서 지구로 보낸 신호를 받는 것은 정말 보통일이 아닐 것 같다.
안테나가 괜히 저렇게 거대한 게 아니다. 그나마 지금은 기술의 발달 덕분에 옛날 같은 지름 70m짜리는 필요하지 않고 30m대만으로도 충분하다고 그런다.

그나마 보이저보다 나중에 더 최신 기술로 발사됐고 지구에 훨씬 더 가까이 있는 뉴 호라이즌 호도 거기서 지구까지 전파가 도달하는 데 4~5시간을 잡아야 한다. 그런 propagation delay와는 별개로, 데이터의 전송 속도도 초당 수백 바이트, 1980년대의 2400~9600bps 모뎀 수준에 지나지 않는다고 한다. 거리가 너무 멀고, 탐사선의 전파 출력에도 한계가 있기 때문에 이건 뭐 어쩔 수가 없다.

그렇기 때문에 탐사선은 자기 메모리에 저장해 놓은 수십 GB에 달하는 사진들을 지구로 찔끔찔금 보내느라 그야말로 세월아 네월아 애써야 했다.
propagation delay인 4~5시간만 지나고 나면 지구에서 인터넷 하듯이 고화질 명왕성 사진이 짠~ 뜨는 건 인류의 기술로는 아직 가능하지 않다.

지구가 둥글다는 건 말할 것도 없고, 빛의 속도조차도 느리다는 걸 실감하는 직업에 종사하는 사람들은 평소에 자기 전공과 생업에 대해서 무슨 생각이 들지 궁금해진다.
더 나아가 달 같은 데서 지구의 인터넷을 연계해서 쓰는 게 가능해질까? 흥미로운 상상이 아닐 수 없다.

Posted by 사무엘

올해 1사분기 동안 본인에게 무슨 일이 있었는지.. 사는 얘기 기록을 좀 남기도록 하겠다.

0. 미세먼지

4월이 되니 날씨가 그럭저럭 좋은 편이다. 하지만 지난 3월 초에는.. 어휴, 정말 역대급 최악의 독스모그 미세먼지가 전국을 뒤덮었던 게 본인의 기억에도 트라우마로 남아 있다. 최장 기간, 최대 면적, 최고 농도... 이런 날이 잠깐 하루 이틀이면 집에 틀어박혀서 버티겠지만, 저게 1주일 가까이 계속되니 본인도 미쳐 버릴 것 같았다.

층간· 벽간 소음이라든가 주차 문제 때문에 미치겠다면서 이웃 간에 싸움 나고 최악의 경우 살인까지 벌어지는데, 미세먼지는 그런 부류의 갈등이 개인이 아닌 국가 단위로 벌어지는 것이나 마찬가지이다. 이 스케일에서는 이론적으로, 정말 최악의 경우 전쟁까지 날 수도 있다.

미세먼지 자체가 정치인 탓은 물론 아닐 것이다. 그리고 우리나라가 정말로 국력이나 기술이 부족해서 옆의 나라에다 항의나 응징 한번 제대로 못 하고 찌그러져 있는 거라면 그것도 어쩔 수 없다.
하지만, 같은 강도의 미세먼지여도 그게 어디에서 오는지에 따라서, 그리고 지금 누가 여당이고 집권했느냐에 따라서 조건부로 정반대로 완전히 다르게 반응하는 더러운 종자들을 생각하면 생각할수록 짜증이 치솟으며 욕을 한 바가지 퍼붓지 않을 수가 없다.

저게 무슨 환경 단체냐? 정치 운동 선동꾼일 뿐이지! 비싼 밥 쳐먹으면서 도대체 왜 인생을 저 따위로 사는 걸까? 2MB 시절의 747 공약보다 더 허무맹랑하고 황당하고 전혀 안 지켜진 공약이 뭐가 있는지 진지하게 생각해 본 적은 있으려나 모르겠다.
하긴, 쟤들은 광우뻥 vs 멜라민, 그리고 산에서 케이블카 만드는 것조차 반대하더니 되도 않은 태양광 한답시고 산 깎고 산림 몽땅 파괴하는 것에는 절대침묵 등.. 일관성과 정당성과 명분은 진작부터 상실했다.

평생을 일제 식민지 일본 탓, 분단의 원흉 미국 탓 지랄하면서 살던 놈들이.. 미세먼지에 대해서는 아이고, 어지간한 종교인들 뺨치는 "내 탓이오" 모드가 돼서 고등어 탓, 포항제철 탓(!!), 디젤 차량 탓 내부 요인 운운하는 거다. 왜? 일본이나 미국에서 온 미세먼지가 아니기 때문이다. 지구의 자전 방향이 반대였으면 이거 정말 큰일 났겠다. 어휴~

그나저나 병X은 국내뿐만 아니라 어디에나 있는지, 옛날에 일본에서는 "먹어서 응원하자"(후쿠시마 지역 방사능 유출 의심 농산물...ㅜㅜ) 구호가 나오더니만 중국에서는 "다같이 구보하면서 공기를 마셔서 정화하자"(우웩..ㅠㅠ) 캠페인이 나왔던가 보다.

1. 찬양 인도 경력 10년

2019년을 기해 본인은 개인적으로 다니는 교회에서 예배/집회 전의 준비 찬송(회중 찬양) 인도를 맡은 지 딱 10년이 됐다. 주일 예배를 새마을호 열차 운행에다 비유한다면, 시발역 출발 전에 Looking for you가 흘러나오는 것 같은 10분 남짓한 예비 시간을 책임지게 됐다.
우리 교회에서는 유튜브 방송으로 예배를 실황 중계를 하는데, 이 때문에 내 얼굴도 지금까지 인터넷으로 많이 팔린 모양이다.

준비 찬송이라는 말을 안 좋아하는 분도 있다. "이거 찬송 부르는 시간도 엄연히 예배의 일부이다. 예배 중에 주보에 기재된 찬송가는 부르면서, 준비 찬송(?)은 불러도 되고 안 불러도 되는 식으로 격을 낮게 취급해서는 안 된다" 식으로 말이다.

그렇게 생각해 준다면 나야 고마운 일이긴 하다만, 그런 격식을 따지기에 각 성도들이 정말로 찬송을 진심으로 부르고 싶어서 불렀으면 좋겠다.
너무 짠한 얘기를 자주 남발하고 싶지는 않지만.. 저 이북에서는 굶주림 때문도, 정치적 자유 때문도 아니고 "찬송 좀 마음 놓고 불러 보고 싶어서" 탈북을 한 사람도 있었다.

난 어디처럼 감미로운 BGM과 함께 "할렐루야~ 우리 다함께 찬양하며 주님 앞에 나아가길 원합니다~ / 성령이여 불같이 임하소서~~!! / 우리 다같이 주여삼창 통성으로 기도하시겠~슙니다~ !@#@!#@!#@!" 같은 건 오글거려서 못 하고...;;; 그냥 "찬송가 xx장입니다"와 함께 진~짜 행진곡 풍으로 크고 정확하게만 부른다.

그리고 잘 부르는 것뿐만 아니라 잘 고르는 것도 중요하다.
내 찬송가 책은 비슷한 시기에 구매한 다른 사람의 책에 비해 종이가 굉장히 낡았고 너덜너덜하다. 매주 곡을 고르기 위해서 책 전체를 뒤적이고 연구하기 때문이다. (신자라면 사실은 찬송가보다도 성경책이 더 그래야 되는데..)
학교에서 교육용으로 재래식 칠판과 분필을 따라갈 물건이 없듯, 선곡을 위해 책을 뒤적이는 도구로는 답답한 컴퓨터 화면 스크롤이 종이책을 결코 대체할 수 없더라.

그 결과, 회중 찬송용으로 적합한 수십여 곡의 신곡들이 내가 직접 들은 적 없이 악보를 읽어서 분위기를 추측한 것만으로 많이 개척됐다.
형제님 덕분에 새로운 좋은 찬송가를 많이 배워서 좋고, 준비 찬송 장면을 녹음해서 집에 가서 다시 들으면서 익힌다는 어느 어르신의 말씀이 굉장한 격려가 됐다.

하루는 주보의 '읽어 보세요' 코너에 영적 성장과 관련된 시가 한 편 실렸는데..
동일한 시가 그대로 가사로 쓰인 곡을 내가 언젠가 찬송가 책을 뒤적이고 악보를 읽어다가 본 적이 있었다. 그 곡을 찾아내어 신곡이 하나 발굴됐다.

또한, 우리 교회는 오전 예배 때 다같이 성경 구절 암송을 하는 게 있는데.. 그 구절을 가사로 쓴 찬양이 있으면 오전 준비 찬송곡에 넣기도 했다. 이거야말로 찬송가를 최고 적절하게 활용하는 게 아니겠는가?
그리고 매 사분기마다 주일학교 애들이 발표를 하는 날이면 오후 예배 준비 찬송 때도 걔들에 대한 courtesy 차원에서 어린이 찬송가를 한두 곡 준비 찬송에 넣는다.

그런 특별한 변수가 없을 때 다음 주에 부를 찬송가를 컴퓨터 추첨 뺑뺑이로 자동화를 좀 했으면 좋겠지만..
곡을 고를 때는 각 곡별 개인적인 선호도와 가중치, 친숙한 정도 등등 딱 수치화할 수 없는 변수들이 굉장히 많이 동원된다. 그래서 자동화가 안 되고 있다.
요런 게 찬양 인도의 묘미이다.

2. 먹빵과 취향

내가 이 정도로 먹는 날은 1년에 두 번 남짓이다. 생일, 그리고 3년쯤 전부터 관행이 되어 온 하계 휴가를 갔을 때 말이다. 본인은 공교롭게도 생일이 겨울이어서 두 날이 반 년에 가까운 간격으로 떨어져 있기 때문에 서로 시기적으로 균형도 잘 맞다.

덧붙이자면 본인은 종교관과 취향의 이유로 인해 술· 담배를 안 하는 사람이다.
하지만 그것과 별개로.. 안 그래도 건강에 안 좋은 저런 기호품을 사람들이 굳이 왜 즐길까, 저게 무슨 일말의 순기능이 있을까 하는 생각 자체는 해 봤다.

담배의 경우, 다같이 일하다가 휴식할 만한 적절한 명분과 휴식 시간, 휴식 방식을 제공해 준다. "화장실 다녀오겠습니다"만큼이나, "잠시 담배나 좀 한 대 피웁시다"가 휴식 선언이다.
그리고 상급자와 하급자가 같이 담배 쪽쪽 빨면서 대화 나누면 자연스럽게 친해지기는 하겠더라. 둘 중 한 명이 그냥 가만히 있기만 하면 민망하고 뻘쭘하니까 말이다. 그에 반해 화장실은 대화와 친교가 오갈 만한 공간은 아니다.

담배 다음으로 술은 사람 정신을 몽롱하게 만들어서 본성을 드러나게 하고, 맨정신으로 하기 힘든 얘기가 선뜻 나옴으로써 사람끼리 가까워지게(?) 하는 효과가 있어 보인다. 또한, 인체에 탈을 일으키는 물질을 흡입하고도 자기는 멀쩡하다고 남자들 세계에서 부심을 조장하는 추가적인 효과도 있다.

그리고 술은 음식을 안주감으로 소비하게 만들지만 한편으로 음식의 소모 속도를 늦추기도 한다. 술 없이 회만 먹으니 내 경험상 음식이 없어지는 속도가 감당이 안 되더라..;; 뭐, 저 때는 나 혼자가 아니라 가족과 같이 먹은 것이었다.

그래도 그렇지 사람을 중독시키고 건강 망치는 물건을 도대체 누가 자기 돈 주면서 마시고 피울까?? 저게 도대체 어떻게 장사가 될까? 세상에는 단순한 경제 논리만으로는 이해되지 않는 원리가 종교 영역 말고 다른 곳에서도 적용되는 것 같다.

그나마 이것들이 건강에 워낙 나쁘다는 인식이 널리 퍼졌고(특히 담배), 예전에 비해 집단 전체주의 똥군기 관행이 사그라든 덕분에 간접 흡연이니 술 강요니 하는 것도 많이 없어졌다.

3. 일요일 결혼식

난 개인적으로는 일요일 정오 결혼식은 예수 믿는 사람은 오지 말라고 or 안 와도 된다고 대놓고 선언하는 거라고 간주한다. 오전 예배를 완전히 대놓고 생까라는 걸 어쩌라고..??
"왜 하필 저 때로 잡았어? 날 엿 먹이려고?" 같은 다른 아쉬움이나 감정이 들어가는 게 아니라, "아 그래? 난 시간· 장소가 안 맞아서 가지는 못하겠네. 어쨌든 결혼 축하해." 그냥 딱 그 이상도 그 이하도 아니라는 것이다. 외국 출장 가 있어서 못 가는 것과 동급으로.

그리고 그것처럼 남 결혼식 정도는 주일 예배를 빠질 명분이 되지 못한다는 것이다. 그걸 일일이 다 챙겨서 가고 예외를 전부/일부 인정해 버리면 예배 제대로 못 드린다.

마치 자동차 교통사고로 치면.. (1) 까방권이 성립할 정도로 불가피하지 않으며 그렇다고 (2) 형사처벌 될 정도로 고의· 악의적인 것도 아닌, 그냥 (3) 정당하지 않은 급차로 변경이나 급정거 정도에 대응한다.
길을 잘못 들었거나, 실었던 짐이 떨어졌다거나 해서 고속도로에서 멍청하게 어영부영 하다가 뒷차로부터 추돌 사고가 나는 거 말이다. 그건 앞차의 과실이 더 크게 잡힌다.

난 무슨 에릭 리들 같은 위인이 아니며, 율법적인 주일성수 덕후가 아니다. 다른 사람이 친구 결혼식 때문에 주일 오전 예배를 수시로 빠지는 걸 정죄할 생각도 없다. 그것과 별개로 나 본인은 남의 결혼식 정도로 예배 시간을 빼앗기고 싶지 않다.
무슨 길거리에서 복음 전해라, 거리설교 해라, 술자리 거부해라, 신앙을 지키기 위해 금전적인 손실을 감수해라 정도의 큰 risk가 필요한 일도 아니고, 원래 개인 사생활 시간대에 예배 드리는 시간 정도는 대외적으로 사수할 배짱이 어느 신자에게든 있어야 하리라고 여겨진다.

Posted by 사무엘

Windows API에는 region(영역)이라는 일종의 자료구조 라이브러리가 있다. 얘는 2차원 래스터(픽셀/비트맵) 그래픽 공간에서 각 픽셀별로 "영역에 포함되냐 안 되냐"라는 일종의 '집합'을 표현한다.
그리고 운영체제는 이 자료구조를 이용하여 각종 그래픽이 그려지는 영역을 정한다. 즉, region은 클리핑(clipping) 영역을 표현하는 데 쓰인다는 것이다.

도스 시절의 여느 그래픽 라이브러리에도 간단한 사각형 영역에만 그림이 그려지게 하는 초보적인 수준의 클리핑 기능은 있었다. 하지만 Windows의 region은 여러 사각형이 겹친 것, 임의의 다각형, 원 등 아무 모양이나 표현하고, 그 영역 안에만 그림이 그려지게 만들 수 있다.

그도 그럴 것이 Windows 같은 GUI 운영체제라면 창들의 Z-order 같은 걸 구현하는 과정에서 밥 먹고 맨날 하는 짓이 정교한 클리핑일 수밖에 없게 된다. 뒤쪽에 있는 창 내용은 앞쪽에 있는 창의 영역을 침범하지 않고 그려져야 하기 때문이다. 그러니 그런 기능을 사용자들에게도 쓰라고 제공해 주는 게 결코 이상한 일이 아니다.

region은 가장 먼저, (1) 직사각형, 타원, 모서리가 둥근 직사각형, 다각형(CreatePolygonRgn, CreatePolyPolygonRgn)처럼.. 속이 닫힌 도형을 그리는 다양한 API를 통해 생성할 수 있다. 당연히 그 도형의 모양이 영역의 모양이 된다.

다음으로, GDI가 제공하는 기능인 (2) path로부터 region을 생성할 수 있다(PathToRegion). path란 마치 윤곽선 글꼴 글립처럼 직선(MoveTo, LineTo)과 곡선(PolyBezirTo)을 임의로 조합하여 어떤 궤적이나 경계선을 기술하는 자료구조이다. region과 달리 벡터 기반이며, 별도의 자료구조로 존재하는 게 아니라 DC의 내부 상태에 종속인 형태로 보관된다는 차이가 있다.

path를 사용하면 경계선이 베지어 곡선인 region을 만들 수 있으며, TextOut 같은 글자 출력 함수를 path에다 넣으면 임의의 글자의 윤곽선도 따서 고스란히 region으로 만들 수 있다. 커다란 두 글자를 포개 놓은 뒤, 겹치는 영역만 다른 색깔로 칠하는 게 region으로는 가능하다. 그 비결은 바로...

(3) CombineRgn이라는 함수를 통해 region 간에 일종의 집합 연산을 할 수 있기 때문이다. 두 region의 교집합, 합집합, 차집합을 구함으로써 더 복잡한 형태의 region을 만들 수 있다.

위의 그림을 보아라. 운영체제나 하드웨어 차원에서 제공되는 layer이나 alpha channel 합성 같은 걸 쓴 게 아니다. 옅은 회색(B), 짙은 회색(S), 검정(겹침)이 차지하는 영역을 2차원적으로 완전히 따로 떼어내서 서로 완전히 다른 색깔과 무늬로 칠할 수 있다. 뚝 떨어진 영역도 당연히 같이 감안해서 말이다. 이런 게 평범한 글자 찍기 API로는 가능하지 않을 것이다.
다만, region은 anti-aliasing을 지원하지 않는 boolean 흑백 자료구조이다 보니, 글자 경계가 거친 것은 아쉬운 점이며 요즘 그래픽 기술의 트렌드와 맞지 않다.

그리고 끝으로.. region은 내부 자료구조를 어느 정도 노출해 주고 있기까지 하다. 그래서 그걸 직통으로 저장하고 불러오는 식으로 생성할 수도 있다. 데이터를 얻는 함수는 GetRegionData이고, (4) 그걸로부터 region을 다시 생성하는 함수는 ExtCreateRegion이다.

어떤 방식으로 region을 생성했건, 얘는 내부적으로 크게 세 부류로 나뉜다. region을 생성하거나 받아들이는 함수들이 그 region의 유형을 리턴값을 통해 알려주기도 한다.

• 아무 영역도 없는 공집합인 NULLREGION
• 직교좌표 직사각형 하나로만 구성된 SIMPLEREGION
• 그 외의 다른 모든 모양을 표현하는 COMPLEXREGION.. 얘는 내부적으로 2개 이상의 사각형, 아니 scan line들로 구성된다.

자연에서 관찰되는 힘이라는 것들이 중력이나 원자력과 관계 있는 게 아니면 나머지는 출처가 몽땅 전자기력이듯이(폭발력, 마찰력, 탄성, 자석, 정전기, 표면장력, 생물 근육 등등등..),
그리고 사람이 생성(...)되는 방식이 흙을 빚어서 직통, 여자의 씨 같은 극소수 예외를 제외하면 나머지 수십~수백 억의 인간들은 몽땅 남자의 씨 기반이듯이.. 그런 것처럼 region도 일상생활에서 보는 단순하지 않은 물건들은 몽땅 complex라고 생각하면 되겠다.

region이 내부적으로 구현된 방식의 특성상(벡터/오브젝트 기반이 아닌 비트맵/픽셀 스캔라인 기반) 무한을 구현할 수 있지는 않으니, 집합 연산에서도 not 연산인 여집합이 지원되지는 않는 걸 볼 수 있다. 차라리 이미 있는 집합끼리 차집합이 대신 지원되고 말이다.

region을 식별하는 핸들 내지 포인터 자료형은 HRGN이다. 그런데 Create...처럼 HRGN을 리턴값으로 주는 함수 말고, Get...Rgn, CombineRgn 이런 이름이면서 HRGN을 인자로 받는 함수들은... 이미 있는 HRGN에다가 값만 바꿔서 넣어 준다. 그런 함수를 쓰려면 null region 하나라도 미리 미리 생성해서 전해 줘야 한다.

그런데 Windows API에는 많고 많은 region 생성 함수들 중에 null region만을 달랑 생성하는 함수는 의외로 없다. 좌표가 모두 0인 직사각형.. CreateRectRgn(0,0,0,0) 이게 그냥 텅 빈 region을 생성하는 역할을 한다. 좀 교묘한 점이다.

그럼 이 region는 어떤 용도로 쓰이며, 할 수 있는 일이 무엇일까? 본인이 생각하기에 다음과 같다.

1. 단독

그냥 저거 자체만으로 뭔가 2차원 공간 상의 기하/집합 알고리즘 구현체로.. 다른 GDI API와의 연계 없이, 심지어 명령 프롬프트용 프로그램에서도 쓰일 수 있다. 펜, 브러시, 글꼴, 비트맵 같은 타 오브젝트들이 DC와의 연계 없이는 거의 쓸모없는 것과 굉장히 대조적이다.
하지만 region이 그렇게 단독으로 쓰이는 경우는 그리 많지 않아 보인다.

2. 창의 invalid 영역 표현

어떤 창의 앞을 가리던 다른 창이 없어지고 내 창의 내용이 다시 그려지게 됐을 때.. 그 이름도 유명한 WM_PAINT 메시지가 날아온다.
BeginPaint와 함께 제공되는 DC는 창 전체가 아니라 정확하게 다시 그려져야 하는 영역에만 그림이 그려지도록 클리핑 처리가 돼 있는데, 이 영역이 말 그대로 region으로 표현되며 GetUpdateRgn 함수를 통해 얻어 올 수 있다.

WM_PAINT 때 이 영역에 대해서 PtInRegion이나 RectInRegion을 적절히 호출하면서 그림을 그리면, 무식하게 화면 전체를 그리는 것보다 프로그램 성능과 반응성을 향상시킬 수 있다.
물론 DC 차원에서 클리핑 처리가 되는 것만으로도 화면 전체를 그리는 것보다는 속도가 향상되지만, 애초에 그리기 요청을 안 하고 CPU 계산을 안 하는 게 더 낫기 때문이다.

3. 내부 클리핑

운영체제뿐만 아니라 사용자 역시 임의의 region을 생성해서 클리핑 용도로 쓸 수 있다. 비트맵이 사각형 모양이 아니라 원 모양으로만 뿌려진다거나, 특정 글자 모양으로만 뿌려지게 할 수 있다는 것이다.
그렇게 하려면 HRGN을 DC에다가 지정하면 된다. 이것은 SelectObject로 해도 되고 SelectClipRgn으로 해도 된다. 완전히 동일하다.
단지, 클리핑을 해제하는 것은 SelectClipRgn로만 가능하다. HRGN 값으로 NULL을 전해야 하기 때문이다. null region은 그림이 전혀 그려지지 않게 하는 효과를 낼 테니까..

HRGN은 기술적으로는 HPEN, HBRUSH, HBITMAP, HFONT와 마찬가지로 여러 GDI 오브젝트 중 하나로 취급된다. 상술한 바와 같이 DC에 SelectObject 될 수 있으며, 소멸 함수가 DeleteObject인 것까지도 동일하다.
하지만 얘는 다른 오브젝트들과 달리 select나 get 될 때 내부 메모리가 복사될 뿐, 핸들값 자체를 주고 받지는 않는다. 즉, HRGN은

HRGN oldRgn = (HRGN)SelectObject(dc, newRgn);
(.....)
SelectObject(dc, oldRgn);

이런 식으로 운용되지 않는다는 것이다. 옛날 핸들값을 보관하고 되돌리는 식의 절차가 필요하지 않다.
DC와 region은 서로 따로 논다. 이렇게 설정한 뒤에 원래 있던 HRGN 핸들은 곧장 삭제해 버려도 된다.

본인은 MFC의 CGdiObject처럼 GDI 객체 핸들만 한데 뭉뚱그린 템플릿 클래스를 만들어서 쓰고 있다. (소멸자에는 DeleteObject가 있고..)
그런데 다른 오브젝트들은 template<T> Handle(T v=NULL) 이런 식으로 NULL이 default 인자인 생성자를 만들어서 초기화할 수 있는 반면,
HRGN에 대해서는 인자가 없는 경우에 대해 specialize된 생성자를 따로 만들어서 이때는 null region을 생성해 놓게 했다. 그래야 이놈을 region을 얻어 오는 다른 함수에다가 인자로 줄 수 있기 때문이다.

4. 칠하고 그리는 공간

그리고 region 자체가 도형을 나타내니 그 모양대로 클리핑이 아니라 내부를 칠하는 용도로 응당 활용할 수 있다. 내부를 칠하는 FillRgn과, 내부의 경계선을 그려 주는 FrameRgn이라는 함수가 제공된다.
흥미로운 것은 경계선을 그릴 때도 pen 대신 brush가 쓰인다는 것이다. region은 path와 달리 벡터 드로잉이 아니기 때문이다. 경계선은 그냥 픽셀 차원에서 색깔이 변하는 곳을 얼추 감지해서 표시해 주는 것일 뿐이다.

5. 창 자체의 외형

끝으로, region은 윈도우의 모양을 지정하는 용도로도 쓰인다. 통상적인 사각형 모양이 아니라 리모콘 같은 다른 물건처럼 생긴 프로그램 창, 현란한 스플래시 윈도우, 내부에 구멍까지 있는 윈도우.. 전부 SetWindowRgn 함수의 산물이다.
한번 SetWindowRgn에다 전해 준 HRGN은 이제 운영체제가 관리하기 때문에 사용자가 DeleteObject 하지 말아야 한다고 문서에 거듭 명시되어 있다.

SetWindowRgn를 지정하는 순간부터 그 창은 운영체제가 non-client 영역과 테두리 경계에 기본 제공하는 각종 테마와 반투명 프레임, 둥그런 테두리, 그림자 효과들로부터 완전히 열외된다. 그 대신 고전 테마의 완전 무미건조한 테두리만이 그려진다. 일반적으로는 당연히 아래처럼 그려질 프로그램 창이 위처럼 그려지게 된다는 뜻이다.

그런 창은 어차피 non-client 영역이 전혀 없이 외형을 사용자가 완전히 customize하는 형태로 쓰일 테니 말이다. 제목 표시줄과 테두리의 외형은 보급품 그대로이면서 중앙에만 region을 지정해서 총알 구멍 같은 게 숭숭 뚫린 프로그램 창 같은 건 만들 수 없다는 뜻이다.

보통은.. 공용 컨트롤 6.0 매니페스트가 없는 프로그램의 경우, 버튼 같은 컨트롤들이 구닥다리 고전 스타일로 그려지고 non-client 영역은 운영체제가 자동으로 쌈빡하게 그려 준다. (그림에서 아래 오른쪽) 그런데 SetWindowRgn을 지정하면 반대로 컨트롤들은 정상적으로 그려지는데 non-client 영역이 고전 스타일로 돌아간다는 게 흥미롭다.

단, 지난 Windows 2000부터는 SetWindowRgn가 아닌 다른 방법으로도 사각형 모양이 아닌 윈도우를 표현할 수 있게 되었다. 바로 layered window이다. WS_EX_LAYERED 스타일을 준 윈도우에다가 SetLayeredWindowAttributes 함수를 호출하면 (1) 이 창에 대해서 투명도를 지정할 수 있고, (2) 특정 RGB 값을 color key로 지정해서 그 색깔은 투명으로 처리할 수 있다. 배경색을 칠하는 것만으로 그 부위가 투명해지니, 번거로운 region보다 훨씬 더 편리해지기까지 했다.

과거 MS Office 97~2000 시절의 흑역사 중에는 'Office 길잡이'라는 "취지만 좋았다" 급의 물건이 있었다. 애니메이션 캐릭터가 화면에 나타나서 돌아다니는데.. 첫 도입되었던 97은 캐릭터가 사각형 창 안에 갇힌 형태였던 반면, 2000부터는 배경 없이 창이 시시각각 애니메이션 캐릭터 모양으로 변했다.

이게 Windows 2000에서는 하드웨어빨을 탄 layered window로 비교적 간편하게 구현됐던 반면.. 9x에서는 일일이 window region을 바꿔 가면서 동작했다. 그 밑의 창은 매번 WM_PAINT가 발생하면서 성능 페널티가 장난이 아니었을 것이다.

본인은 먼 옛날에 이런 프로그램도 구경한 적이 있었다. 실행하면 만화영화 그림체로 그려진 병아리 한 마리가 마치 저 Office 길잡이처럼 튀어나왔는데, 그냥 가만히 있는 게 아니라 각종 프로그램 창들 위를 돌아다녔다. 나름 중력도 구현했던지라, 마우스로 집어다가 공중에다 옮겨 놓으면 아래의 근처에 있는 창으로 떨어지기까지 했다. 내 기억이 맞다면 꽤 재미있는 프로그램이었는데.. 지금 인터넷으로 다시 검색하고 구할 길이 없다.

이 프로그램에 대해서 본인이 현재 기억하고 있는 건 아마 일본에서 만들어진 걸로 추정된다는 것, 그리고 무려 Windows 3.x용 16비트 프로그램이었다는 것이다. 그 열악한 Windows 3.x에서도 타이머를 걸어서 최소화 아이콘에다가 애니메이션을 구현하고, 창의 경계가 시시각각 곡선 윤곽으로 바뀌는 저런 액세서리 프로그램이 만들어지기도 했다.

이렇듯, SetWindowRgn을 이용해서 이런 재미있는 활용을 할 수 있는데.. 날개셋 한글 입력기에서 사각형이 아닌 모양의 창이 나타나는 곳은 마우스 휠을 눌렀을 때 나타나는 동그란 자동 스크롤 앵커가 유일하다.

에디트 컨트롤은 자동 스크롤 모드가 없고, MS 오피스 제품들은 동그란 테두리 없이 그냥 배경에다가 회색 화살표가 나타나는 듯하지만.. 마소에서 만든 웹 브라우저(IE, Edge)에서는 앵커 윈도우가 나타난다. 날개셋의 앵커 윈도우도 먼 옛날에 얘를 참고해서 만들어진 것이다. 맨 처음에는 region만 쓰다가 이내 layered window도 사용하도록 형태가 바뀌었다.

여담: 좌표계 관련 문제

아, region의 경계면과 관련해서 주의해야 할 점이 있다.
같은 좌표를 줬을 때, 직사각형은 pen으로 그려지는 테두리와 region의 영역이 픽셀 단위로 정확하게 일치한다. 다시 말해 같은 RECT rc에 대해서 CreateRectRgn + SetClipRgn을 한 뒤에Rectangle을 호출한 결과는 클리핑을 안 했을 때와도 동일하다.

하지만 타원(Ellipse vs CreateEllipticRgn)이나 폴리곤(Polygon vs CreatePolygonRgn) 같은 다른 도형에 대해서는 이것이 성립하지 않는다. region은 오른쪽과 아래 끝의 1픽셀이 미묘하게 잘린다.

//직사각형
CRgn rg; CRect rc(10, 10, 80, 80);
rg.CreateRectRgnIndirect(rc);
dc.SelectClipRgn(&rg); dc.Rectangle(rc);
rc.OffsetRect(40, 40); dc.Rectangle(rc);

//원
CRgn rg; CRect rc(110, 10, 180, 80);
rg.CreateEllipticRgnIndirect(rc);
dc.SelectClipRgn(&rg); dc.Ellipse(rc);
rc.OffsetRect(40, 40); dc.Ellipse(rc);

//폴리곤으로 표현한 직사각형
CRgn rg; POINT pt[4] = {
{10, 100}, {80, 100}, {80, 170}, {10, 170} };
rg.CreatePolygonRgn(pt, 4, ALTERNATE);
dc.SelectClipRgn(&rg); dc.Polygon(pt, 4);

이 코드를 실행한 결과는 다음과 같이 차이가 난다.

폴리곤으로 직사각형 좌표를 지정해 줘도, 아예 직사각형 전용 생성 함수를 줬을 때와 달리, region은 영역이 살짝 덜 생긴다. 그래서 그 region 안에서 동일 좌표로 도형을 직접 그려 보면 테두리의 오른쪽과 아래쪽이 잘린다.

이를 감안해서 원형 region을 생성할 때는 그리기 함수일 때보다 1픽셀 정도 더 크게 원을 그리면 잘리는 현상은 막을 수 있다. 하지만 그래도 그리기 함수와 region 함수는 경계 계산 결과가 서로 미묘하게 달라서 직사각형일 때처럼 깔끔하게 일치하는 모양이 나오지 않는다.
그러니 region 자체의 경계를 그려 주는 FrameRgn 함수를 대신 쓸 수밖에 없다. 허나, 얘가 그려 주는 테두리는 전문적인 원 그리기 함수에 비해 표면이 거칠며 별로 예쁘지 않다.

본인은 처음에 이런 특성을 몰라서 한동안 삽질을 했었다. 이럴 때도 region 대신 layered window는 순수하게 그리기 결과에 따라서 투명색을 자동으로 처리해 주니 더욱 유용하다.

Posted by 사무엘

1. 재부팅 이벤트

본인은 지금까지 Windows가 시스템 종료/재시작/로그아웃 될 때.. 메시지에 즉각 응답하면서 정상적으로 돌아가는 프로그램이라면 종료 처리도 당연히 정상적으로 되는 줄로 알고 있었다.
사용자가 [X] 버튼이나 Alt+F4를 눌러서 종료할 때와 완전히 동일하게 말이다. WM_CLOSE에 이어 WM_DESTROY, WM_NCDESTROY가 날아오고, WM_QUIT이 도달하고, message loop이 종료되고, MFC 프로그램으로 치면 ExitInstance와 CWinApp 소멸자가 호출되고 말이다.

왜냐하면 시스템이 종료될 때 발생하는 현상이 언뜻 보기에 정상적인 종료 과정과 동일했기 때문이다. 저장되지 않은 문서가 있는 프로그램에서는 문서를 저장할지 확인 질문이 뜨고, 운영체제는 그 프로그램 때문에 시스템 종료를 못 하고 있다고 통보를 한다. 좋게 WM_CLOSE 메시지를 보내는 걸로 반응을 안 하는 프로그램에 대해서만 운영체제가 TerminateProcess 같은 강제 종료 메커니즘을 동원할 것이다.

그런데 알고 보니 그게 아니었다.
정상적인 종료라면 ExitInstance 부분이 실행되어야 할 것이고 프로그램 설정들을 레지스트리에다 저장하는 부분도(본인이 구현한..) 실행돼야 할 텐데, 내 프로그램이 실행돼 있는 채로 시스템 종료를 하고 나니까 이전 설정이 저장되어 있지 않았다.

꼭 필요하다면 WM_ENDSESSION 메시지에서 사실상 WM_DESTROY 내지 ExitInstance와 다를 바 없는 cleanup 작업을 해야 할 듯했다. 뭐, 날개셋 한글 입력기에서 이 부분이 반영되어 수정돼야 할 건 딱히 없었지만 아무튼 이건 내 직관과는 다른 부분이었다.

시스템이 종료될 때 발생하는 일은 딱히 디버거를 붙여서 테스트 가능하지 않다. =_=;; 로그 파일만 기록하게 해야 하고, 매번 운영체제를 재시작해야 하니 가상 머신을 동원한다 해도 몹시 불편하다. 꽤 오래 전 일이 됐다만, 날개셋 외부 모듈이 특정 운영체제와 특정 상황에서 시스템 종료 중에 운영체제 시스템 프로세스 안에서 죽는 문제가 발생해서 디버깅을 한 적이 있었다. 몹시 골치 아팠었던 걸로 기억한다.

2. 파일의 동등성 비교

파일 이름을 나타내는 어떤 문자열이 주어졌을 때,

• 상대 경로(현재의 current directory를 기준) vs 절대 경로
• 과거 Windows 9x 시절이라면 ~1 같은 게 붙은 8.3 짧은 이름 vs 원래의 긴 이름
• 대소문자 (Windows는 대소문자 구분이 없으므로. 그런데 이것도 A~Z 26자만 기계적으로 되나? 언어별로 다른 문자의 대소문자는?)
• 그리고 옵션으로는 정규 DLL search path와 환경 변수

이런 것들을 몽땅 다~ 감안해서 다음과 비스무리한 일을 하는 가벼운 API가 좀 있으면 좋겠다. 보다시피 동일한 파일을 표현하는 방법이 굉장히 다양하기 때문이다.

• 두 개의 파일 명칭이 서로 동일한 파일인지 여부를 판단. 당연히 파일을 직접 open/load하지 않고 말이다.
• 그 파일의 대소문자 원형을 유지한 절대 경로. 일명 '정규화된' 이름을 되돌린다. 이게 동일한 파일은 물리적으로, 절대적으로 동일한 파일임이 물론 보장된다.
  참고로 Windows API 중에서 얼추 비슷한 일을 한다고 여겨지는 GetFullPathName이나 GetModuleFileName 함수는 절대 경로 말고 파일의 대소문자 원형 복원이 제대로 되지 않는다.
• 혹은 그 파일의 시작 지점이 디스크에서 물리적으로 어디에 있는지를 나타내는 64비트 정수 식별자를 구한다. 포인터가 아니지만 파일의 동등성 여부 판단은 가능한 값이다. 정수를 넘어 UUID급이어도 무방함.

본인은 비슷한 목적을 수행하기 위해, 그냥 두 파일을 CreateFileMapping으로 열어 보고 리턴된 주소가 동일하면 동일한 파일로 간주하게 한 적이 있었다. 핸들 말고 MapViewOfFile 말이다. 본질적으로 동일한 파일이라면 운영체제가 알아서 같은 주소에다 매핑을 하고 레퍼런스 카운트만 증가시킬 테니까..
Windows 9x에서는 주소가 시스템 전체 차원에서 동일하겠지만 NT 계열에서는 한 프로세스 내부에서만 동일할 것이다.

하지만 내가 필요한 건 파일의 내용이 아니라 그냥 두 파일의 동등성뿐인데 이렇게 매핑을 하는 건 overkill 삽질 같다는 인상을 지울 수 없었다.
비슷한 예로, LoadLibrary도 같은 파일에 대해서는 같은 리턴값이 돌아온다. HMODULE도 오늘날은 핸들이 아니라 메모리 map된 주소이니까.. 다만, 오버헤드를 줄인답시고 LoadLibraryEx + LOAD_LIBRARY_AS_DATAFILE 이렇게 열어서는 안 된다. 그러면 로딩 방식이 크게 달라지더라.

3. JNI에서 문자열 처리하기

Java 언어는 JNI라고 해서 자기네 바이트코드 가상 머신이 아닌 C/C++ 네이티브 코드를 호출하는 통로를 제공한다.
프로그램 자체를 C/C++로 짜던 시절에는 극한의 성능을 짜내야 하는 부분에 어셈블리어를 집어넣는 게 관행이었는데.. 이제는 일반적인 코딩은 garbage collector까지 있는 상위 계층에서 수행하고, 극한의 성능을 짜내야 하는 부분에서만 C/C++ 코드를 호출한다는 게 흥미롭다.

JNI는 그냥 언어 스펙에 가까운 광범위한 물건이다. Windows 환경에서는 그냥 Visual C++로 빌드한 DLL이 export하는 함수를 그대로 연결할 수도 있다. 물론 그 DLL을 빌드하기 위해서는 Java SDK에서 제공하는 jni 인터페이스 헤더와 static 라이브러리를 사용해야 한다.
한편, 안드로이드 앱 개발에서 쓰이는 NDK는 JNI 스펙을 기반으로 자체적인 C++ 컴파일러까지 갖춘 네이티브 코드 빌드 도구이다.

Java의 문자열은 JNI에서는 jstring이라고 내부 구조를 알 수 없는 자료형의 포인터 형태로 전달된다. C++에서는 UTF-8과 UTF-16 중 편한 형태로 바꿔서 참조 가능하다.
UTF-8로 열람하려면 JNIEnv::GetStringUTFChars를 호출하면 된다. 길이를 알아 오려면 GetStringUTFLength부터 호출한다. 전해받은 문자열 포인터는 ReleaseStringUTFChars로 해제한다.

그 반면, UTF-16 형태로 열람하려면 위의 함수 명칭에서 UTF를 빼면 된다. GetStringChars, GetStringLength, ReleaseStringChars의 순이다. Java가 내부적으로 문자를 2바이트 단위로 처리하기 때문에 이들이 주로 취급하는 자료형은 jchar*이다. 그러니 얘는 char16_t 자료형과 호환된다고 간주해도 좋다. 참고로 wchar_t는 NDK 컴파일러의 경우 4바이트로 처리되더라.

UTF-16이나 UTF-8이나 다 UTF이긴 마찬가지인데, Java는 변별 요소인 8을 생략하고 함수 이름을 왜 저렇게 지었나 개인적으로 의구심이 든다. 물론 GetStringChars는 Java가 내부적으로 문자열을 원래부터 2바이트 단위로 처리하다 보니 우연히 UTF-16과 대응하게 됐을 뿐, 대놓고 UTF-16을 표방했던 건 아닐 것이다. 뭐, 이제 와서 그 체계를 바꾸는 건 불가능하고 "자바 문자열 = 2바이트 단위"는 완전히 고정되고 정착했지만 말이다.

또한 GetStringChars는 GetStringUTFChars와 달리 굉장히 치명적으로 불편한 단점이 하나 있다. 바로.. 변환된 문자열이 NULL-terminated라는 보장이 없다는 것이다!
그래서 본인은 이 포인터를 사용할 때 메모리를 n+1글자만치 또 할당해서 null문자를 추가해 주는 매우 번거로운 두벌일을 하고, 아예 클래스를 이렇게 따로 만들어야 했다. 좀 개선의 여지가 없으려나 모르겠다.

class CJstrToString16 {
    JNIEnv *_ev;
    jstring _jstr;
    const jchar *_ret;
    char16_t *_arr;
public:
    CJstrToString16(JNIEnv *ev, jstring js): _ev(ev), _jstr(js) {
        jsize n = ev->GetStringLength(js);
        _ret = ev->GetStringChars(js, NULL);
        _arr = new char16_t[n+1];
        memcpy(_arr, _ret, n*sizeof(char16_t));
        _arr[n] = 0; //고작 요거 하나 때문에..
    }
    ~CJstrToString16() {
        ev->ReleaseStringChars(_jstr, _ret);
        delete[] _arr;
    }
    operator const char16_t*() const { return _arr; }
};

4. Visual C++의 STL

C++은 타 프로그래밍 언어들과 달리, 심지어 전신인 C와도 달리, 언어가 개발되고 나서 자신의 특성을 잘 살린 라이브러리가 언어 차원에서 붙박이로 곧장 제정되지 않았던 모양이다. 그래서 각 컴파일러들이 중구난방으로 파편화된 형태로 라이브러리를 제공해 오다가.. 표준화라는 게 1990년대 말이 돼서야 논의되기 시작했다.

템플릿이 추가되어 C++에서도 제네릭, 메타프로그래밍이라는 게 가능해진 뒤부터 말이다. 처음에는 자료구조 컨테이너 위주로 STL이라는 이름이 붙었다가 나중에는 그냥 C++ library가 된 걸로 본인은 알고 있다.

Windows용으로 가장 대중적인 C++ 컴파일러야 두 말할 나위 없이 MS Visual C++이다. 얘는 거의 20여 년 전 6.0 시절부터 P.J. Plauger라는 사람이 구현한 C++ 라이브러리를 제공해 왔다. C 라이브러리와 달리 C++ 라이브러리는 소스가 비교도 안 될 정도로 복잡하고 난해하다는 것(암호 같은 템플릿 인자들..=_=), 그리고 저렇게 마소 직원이 아닌 개인 이름이 붙어 있다는 게 인상적이었다. 2000년대 초까지만 해도 휴렛-패커드라는 회사명도 주석에 기재돼 있었다.

P.J. Plauger는 현재는 Dinkumware라고 C++ 라이브러리만 전문적으로 관리하고 라이선스 하는 회사를 설립해 있다. 나이도 생각보다 지긋한 듯..
그런데 이런 세계적인 제품에 들어가는 라이브러리가.. 성능이 의외로 시원찮은가 보다. Visual C++이 제공하는 컨테이너 클래스가 유난히도 느리다고 까이는 걸 여러 사이트에서 봐 왔다.

최근에는 본인 직장의 상사마저도 같은 말씀을 하시기에 "헐~!" 했다. 업무상 필요해서 string, set, map 등을 써서 수십, 수백 MB에 달하는 문자열을 분석하는 프로그램을 돌렸는데, 자료 용량이 커질수록 속도가 급격히 느려져서 자료구조를 직접 새로 짜야 할 판이라고 한다.

난 개인적으로는 C++ 라이브러리를 거의 사용하지 않고, 더구나 그걸로 그 정도까지 대용량 작업도 해 보지 않아서 잘 모르겠다. 그 날고 기는 전문가가 만든 코드에 설마 그런 결함이 있으려나? 아니면 컴파일러의 최적화 문제인지?

글쎄.. 이런 게 있을 수는 있다. MFC의 CString은 그냥 포인터와 크기가 동일하며 값으로 전할 때의 reference counting도 처리한다. 그러나 std::string은 자주 쓰이는 짧은 문자열을 번거로운 heap 메모리 할당 없이 빠르게 취급하기 위한 배열까지 내부에 포함하고 있다. 이런 특성을 모르고 std::string도 함수에다 매번 value로 전달하면 성능에 악영향을 줄 수밖에 없다.

그런 식으로 임시 객체가 쓸데없이 생겼다가 사라지는 구조적인 비효율이 C++ 라이브러리에 좀 있는 걸로 들었다. R-value 참조자 &&가 도입된 것도 vector의 내부 처리에서 그런 삽질을 예방하는 근거를 언어 차원에서 마련하기 위해서라지 않는가? 그리고 Visual C++이 그런 비효율을 보정하는 성능이 좀 시원찮다거나 한 것 같다. 전부 다 그냥 추측일 뿐이다.

그러고 보니 cout<<"Hello world"가 printf("Hello world")보다 코드 오버헤드가 작아지는 날이 과연 올지 모르겠다. 이것도 그냥 떡밥인 건지..?? =_=;;

Posted by 사무엘

요즘 컴퓨터 프로그램들은 상업용이라 해도 과거처럼 디스켓이나 씨디가 담긴 패키지 박스의 형태로 배포되는 경우가 거의 없어졌다. 바이너리의 배포 자체는 인터넷으로 하며, 패키지가 있다 해도 그 안에는 시리얼 번호 쪽지 정도나 달랑 들어있다. 그 뒤, 사용자가 구매한 카피 개수만큼만 프로그램을 동시에 구동하고 있는지, 사용 기한이 경과하지 않았는지 같은 인증은 인터넷으로 진행한다.

정식 사용자가 확인되지 않은 프로그램은 일단 평가판 모드로 동작한다. 정품 인증이 안 됐고 평가판 기간도 경과했다면 그 다음부터는 기능 제한 모드로 동작한다. 문서나 데이터를 취급하는 업무용 프로그램이라면 이제 문서를 편집할 수 없고 일종의 viewer 형태로만 동작하게 된다.

과거에는 소프트웨어 개발사들이 사용자에게 자기 제품의 기능을 자랑하는 한편으로 정품 구매에 대한 동기를 부여하기 위해 셰어웨어, 평가판, 데모 같은 것을 따로 배포하곤 했다.
하지만 지금은 인터넷이 워낙 발달한 덕분에.. subset 구분 없이 전체 제품을 통째로 뿌린다. 그 뒤 제품을 구입하고 해금 비밀번호/일련번호를 받은 사용자에게만 전체 기능이 제공되도록 한다. 아래아한글, MS Office 같은 거대한 프로그램들도 이제는 다 이런 식으로 동작하고 있다.

과거에는 그런 일련번호를 수학 공식을 기반으로 생성하곤 했다. 하지만 오프라인 환경에서 소프트웨어적인 알고리즘에만 의존하는 copy-protection은 역공학을 통해 뚫릴 수 있다. 마치 주민 등록 번호 자동 생성기처럼 말이다. 어둠의 경로를 개척하는 사람들이 이만저만 똘똘한 게 아니기 때문이다.

하지만 인터넷이 소프트웨어의 배포와 불법 복제만 편하게 만든 건 아니며, 까놓고 말해 개발사가 사용자의 사용 패턴을 미주알고주알 파악하는 것도 더 용이하게 만들었다. (뭐, 서버 유지 비용은 부담해야 하지만..) 제아무리 클라이언트 프로그램을 복제하고 뿌려도 온라인 게임을 돈 안 내고 즐기는 건 불가능하며, 스타크래프트 불법 복제 립버전으로 배틀넷 접속은 할 수 없다. 또한, 주민 등록 번호는 생성하더라도 방대한 DB에 일일이 접속하는 실명 인증은 수학 공식만으로 뚫을 수 없지 않던가? 그런 식으로 창과 방패는 발전하는 것 같다.

물론 업무용 프로그램들은 온라인 게임과 달리 업데이트 체크나 인증을 할 때만 인터넷에 접속하지, 나머지 동작은 전부 어차피 오프라인에서 행해지는 게 대부분이다. 그런 부류라면 실행 파일을 분석해서 인증을 시도하는 부분만 변조하고 크랙해 버릴 수도 있다. 파일이 전부 암호화되지 않고 헤더에만 암호가 기록돼 있다면 그 부분만 건너뛰어 버리면 되듯이 말이다. 그렇기 때문에 오프라인에서의 소프트웨어 보안도 예나 지금이나 여전히 필요하다.

이렇게 소프트웨어의 정품 사용 여부를 파악하기 위해서 반드시 필요한 절차가 있다. 바로 프로그램이 돌아가고 있는 기기 내지 제품의 사용자를 중복 없이 유일하게 식별하는 것이다!
매번 변하는 난수 씨앗이야 그냥 현재 시각을 기반으로 생성한다고 하지만, 한 컴퓨터에만 고유하게 적용되는 시리얼 키 같은 걸 생성하려면 전세계에서 유일하고 불변하고 전무후무한 식별 번호가 하드웨어 차원에서 부여되어 있어야 한다.

하다못해 예전에 도스용 게임 중에서도 저장 기능이 없는 대신, 각 레벨별로 암호 코드가 부여되는 게 있었다. 그 코드값을 알면 나중에 상위 레벨에서부터 게임을 시작할 수 있다.
그런데 문제는 그 코드값이 컴퓨터마다 제각각으로 생성된다는 것.. 그러니 매 컴퓨터에서 게임을 새로 시작해서 상위 레벨에 직접 진입을 해야만 코드값을 알 수 있었다.

그리고 어떤 소프트웨어가 정품 인증을 받았다거나, 셰어웨어의 경우 등록판이 생성되었는데.. 그 인증 정보는 레지스트리나 파일 형태로 저장되곤 한다. 물론 꼼꼼하게 암호화해서 말이다.
그 인증 정보에는 당연히 특정 컴퓨터의 식별자도 들어있어야 할 것이다. 그래야 그 인증 정보만 다른 컴퓨터에다가 슬쩍 복사해서 집어넣더라도 명의가 도용되지 않을 테니 말이다.
이런 식으로 컴퓨터의 고유 식별자는 프로그램 개발자의 입장에서는 매우 다양하게 활용될 수 있다.

자동차에는 외부에 노출된 번호판과 별개로, 자동차 껍데기 자체를 식별하는 차대 번호라는 게 있어서 엔진룸이나 도어 한구석에서 확인할 수 있다.
노트북 PC는 시리얼 번호가 밑바닥에 적혀 있다. 그리고 스마트폰도 기기를 식별하는 고유 번호가 있는 건 마찬가지이다. 사용자를 식별하는 USIM과는 당연히 별개로 말이다.

그런데 PC는 컴퓨터를 유일하게 식별하는 깔끔한 단일 통합 메커니즘이 의외로 존재하지 않는다.
먼 옛날에 펜티엄 3~4 시절에는 CPU의 일련번호를 얻어 오는 명령이 있었던 듯하나.. 예제 코드가 어셈블리어여서 이식성이 전혀 없으며, 요즘 CPU에서는 통하지도 않는다고 한다.

컴퓨터를 식별하기 위해서 지금까지 제일 만만하게 쓰여 온 방법은 맥 어드레스(mac address)라는 48비트짜리 숫자이다. 요즘은 휴대전화 번호가 사람을 식별하는 준 주민 등록 번호나 마찬가지이지 않는가? 그것처럼 통신망에서의 주소는 기기 식별 용도로 나쁘지 않은 선택이다.
하지만 얘를 쓰기에는 요즘 컴퓨터 네트워크는 계층과 종류가 너무 다양해졌으며, 사용자가 값을 변조도 그리 어렵지 않게 할 수 있기 때문에 여러 모로 약발이 다했다.

하드웨어적인 방법에만 너무 의존하면.. 사용자가 램을 더 달거나 하드디스크를 교체한 것만으로 프로그램 정품 인증이 실패하는 불상사가 벌어진다. 도대체 한 컴퓨터의 정체성을 결정하는 것이 무엇인가 하는 본질적인 고민에 부딪히게 된다.
소프트웨어적인 방법으로는 HKEY_LOCAL_MACHINE 상에 있는 Windows의 product ID라든가 Machine GUID가 있는데.. 이것은 변조하기 쉽고 운영체제를 다시 설치하는 것만으로도 무력화될 수 있는 게 약점이다.

최근엔 본인도 이런 쪽으로 고민할 일이 좀 있었다. 그러다가 WMI(Windows Management Instrumentation)라는 DB인지 API인지.. 정체를 알 수 없는 방대한 물건을 최근에야 난생 처음으로 접했다. 여기에 시스템 정보와 관련된 것들이 다 있었다. 하드디스크의 시리얼 번호, 마더보드의 시리얼 번호, 뭐 별별 것까지 다.. 그야말로 끝판왕이었다.

그 중 Win32_ComputerSystemProduct라는 클래스에 있는 uuid 값이.. SMBIOS, 즉 펌웨어 레벨에서 새겨져 있는 불변 유일한 컴퓨터 식별자 역할을 얼추 하겠다는 결론을 내리게 됐다. 최소한 맥 어드레스보다는 더 믿을 만하지 않을까? 명령 프롬프트에서는 wmic csproduct get uuid라고 하면 얻을 수 있다.

WMI에 접근하는 건 C#에서는 꽤 간단하고 쉽게 할 수 있어 보이던데 C++에서는 COM을 초기화하고 온갖 복잡한 인터페이스를 몇 단계씩 생성해야만 가능했다. DB 아니랄까봐, COM으로도 모자라서 팔자에 없는 SQL 쿼리까지 날려야 되더라! SELECT * from Win32_ComputerSystemProduct 같은 식으로 말이다.
누가 클래스 라이브러리 하나 만들어 놓은 것조차 없는 듯... 저 GUID 하나만 달랑 얻어 오는 용도로 쓰기에는 낭비가 꽤 심해 보인다.

Windows와 달리 mac 계열은 하드웨어/소프트웨어가 워낙 딱딱 들어맞는 일체형이니 저 정도의 복잡한 고민은 필요 없을 듯하다. 시스템 정보를 보면 나오는 시리얼 번호와 하드웨어 UUID만으로 식별과 관련된 모든 고민이 끝이지 않을까?
게다가 gethostuuid라는 함수 한 방으로 그 값을 바로 구할 수 있었다.

이미 유비쿼터스니 사물 인터넷 IoT니 뭐니 하면서 운영체제 불문하고 수많은 기기들이 인터넷에 접속하고 있으며, 그에 맞춰서 주소 공간이 월등히 넓어진 ipv6도 서서히 보급되고 있다. ipv6는 주소 공간의 크기가 UUID의 그것과 동일한 128비트이다.

그러니 Windows/mac, 그리고 안드로이드/iOS를 불문하고 전세계 전무후무 유일불변이 보장되는 기기 식별자 같은 것도 제정되지 않을까 싶다. 이미 제정돼 있는데 본인이 아직 모르는 것일 수도 있겠지만, PC 한정으로는 내가 알기로 딱 떨어지는 답은 아직까지 없다. 심증에 속하는 여러 정황상의 단서들을 모아서 물증인 것처럼 편의상 활용하고 있을 뿐이다.

Posted by 사무엘

1. 옛날 언어의 간결함

예전에도 한번 언급한 적이 있었지만.. 세상에 생명의 기원보다도 더 알 수 없는 게 바로 언어의 기원이다.
먼 옛날, 최초의 언어가 어떠했는지는 문헌 기록도 음성 녹음도 없고, 아예 문자조차 없으니 제대로 알 길이 없다. 이런 게 저절로 우연히 생겨날 수는 없다고 믿어 버리면 증명도 반증도 할 수 없고 그냥 개인 신념의 영역이 된다.

언어별로 차이가 있긴 하겠지만, 대체로 고대 언어는 현대의 언어보다 문법이 더 복잡하고 불규칙도 더 많고, 사용되는 음운도 더 다양했으리라고 추측된다. 그런데 한편으로는 반대로 옛날 언어가 어휘나 표현이 더 간결한 것도 있었다.

(1) 예를 들어.. 영어 고어에는 before보다 더 짧은 ere(air, heir와 같은 '에어')가 있고.. enemy보다 더 짧은 foe가 있다. 그리고 뻔한 문맥에서 목적어 같은 걸 생략도 많이 했다. 아래의 KJV 구절을 살펴보자.

• Abimelech king of Gerar sent, and took Sarah. (창 20:2)
• Bring these men home, and slay, and make ready. (창 43:16)

'사람을 보내어'인데 그냥 sent를 자동사인 듯이 썼으며
'가축을 잡아서'인데 그냥 slay 한 단어로만 씨크하게 표현했다.

(2) 그런데 영어 이전의 성경의 언어였던 히브리어· 그리스어 레벨에서는 이런 자비심 없는 축약이 더 많았던 모양이다.
그래서 KJV 영어 본문에서 이탤릭체 처리된 단어들을 찾아보면.. 없으면 단순히 문법적으로만 어색하거나, 아까 사람 내지 가축처럼 어렴풋이 유추 가능한 정도를 넘어서 뜻이 완전히 달라지는 것들도 있다.

시 12:5 끝부분의 "I will set [him] in safety [from him that] puffeth at him."에서 []로 둘러싸인 부분이 전부 이탤릭이다. 도대체 히브리어 원어 원문은 얼마나 암호처럼 짧게 기록됐길래 영어에서 저런 목적어와 수식어를 창작해서 집어넣어 줘야 했는지가 궁금해진다. (물론 KJV 외의 타 성경들도 동일하게 저렇게 번역했음)

(3) KJV는 they라는 짤막한 단어를 3인칭 복수 대명사로도 쓰고, people 같은 '일반적인 사람' 용도로도 쓴다. 이것 자체는 현대 영어에서도 존재하는 관행이지만, KJV는 중의성· 모호성이 느껴지기도 할 정도로 they를 즐겨 쓰는 감이 있다.
왕하 19:35를 보면.. "they가 아침에 일어나 보니 they는 모두 죽은 송장이 되어 있었더라"처럼.. 서로 다른 대상에 대해서도 똑같은 they가 쓰인다.

출 20:13 "살인하지 말라"도 타 성경들은 murder 정도를 넣었지만 KJV만은 그냥 짧은 kill이다.

(4) 영어를 비롯한 성경 언어 쪽 얘기가 길어졌는데, 반대편의 한국어도 마찬가지이다. 훈민정음 서문이라든가 이 윤탁 한글 영비 같은 걸 보면.. "영한 비라. 거운 사람은 재화를 입으리라" 말이 굉장히 짧다는 생각이 들지 않는가?
요즘 같으면 못해도 "이것은 신령한 비입니다. 이 비를 무너뜨리는 사람은 재앙을 당할 것입니다" 정도로는 풀어서 쓸 텐데? 띄어쓰기가 없는 고어체를 감안하더라도 주어 생략에다 '거우다?'라는 짤막한 단어.. 뭔가 현대 한국어의 화자는 알지 못하는 옛 한국어의 면모인 것 같다.

2. 의존명사

한국어에는 의존명사라는 게 있다. '리', '수' 같은 건 분명 고유한 뜻과 뉘앙스가 있긴 한데, 그게 구체적으로 뭔지를 설명해 보라고 하면 난감하다. 얘들은 '-ㄹ' 꼴로 활용된 용언으로부터 수식을 받은 바로 다음에만 등장하며(그럴 리, 할 수..), 특히 '리' 다음에는 '없다'만 쓰인다.

어처구니, 어이 같은 단어는 그런 통상적인 의존명사에 속하지는 않지만.. 뒤에 붙는 용언이 답정너 너무 뻔하고 다른 형태로 쓰이는 일이 없다시피하다. 그래서 '어이없다, 어처구니없다'가 그냥 한 단어로 인정될 지경이다. '쓸데없다'처럼 말이다.

한국어 맞춤법과 띄어쓰기가 너무 어렵고 일관성이 부족하다고 원성이 자자하지만.. 한국어가 단어와 형태소의 경계를 구분하는 게 그만치 어렵다. 이것 때문에 사전 편찬자와 국어 문법학자들도 고충이 많다. 용언에 극도로 제한된 뻔한 형태로만 활용되는 불완전동사가 있는 것만큼이나(더불다, 가로다, 달다) 체언에는 아주 제한된 형태로만 쓰이는 의존명사 같은 물건이 있는 셈이다.

그런데.. 이렇게 제한된 형태, 관용구 형태로만 쓰이는 명사가 영어에도 있는 것 같다. 유익· 편의라는 뜻인 sake 내지 behalf 같은 단어 말이다. 얘들은 오로지 one's sake, ?n behalf of .., for the sake of 형태로만 쓰이고 단독 내지 다른 형태로 쓰이는 일이 없다. 이것 말고 다른 예도 있지 싶다.

3. 일관성을 찾을 수 없는 혼돈의 카오스

(1) 외래어 표기법의 노답 문제

• 자음 음절 경계: 플룻 플루트 로보트 백 태그..;; 답이 없다. ㅡ는 음가가 참 불분명한 모음이다.
• 장모음: 윈도우 보우 리모트 보트 스노우.. [ou]라는 영어 장모음은 u를 무시하고 '오'로만 표기하는 게 원칙이지만 snow나 window 같은 단어는 여전히 '우'까지 표기한 형태가 더 익숙하다.
• 모음 경계: washer는 와셔일까, 워셔일까? ㅏ~ㅓ, ㅗ~ㅓ 경계가 의외로 헷갈린다.

(2) 한글 맞춤법 및 발음에서 노답 문제

• 사잇소리와 사이시옷: 비빔밥/볶음밥 중에서 왜 전자만 밥이 '빱'으로 바뀔까? 물고기/불고기 중에서 왜 전자만 '꼬' 소리가 날까? '김밥'의 발음은 밥과 빱 중에 무엇이 더 바람직할까?
• 띄어쓰기: 한자어 복합명사들의 띄어쓰기부터가 아주 모호하다. 또한, 순우리말 중에도 '잘 만 듯 못' 요런 어절들은 단어도 되고 접사도 되기 때문에, 뒤에 '+하다' 같은 게 이어질 때 띄어쓰기 여부가 아주 구리다.

4. ㅐ와 ㅔ의 발음

이건 한국어 음운 체계에 남아 있는 희대의 미스터리이다.
원래 '아 다르고 어 다르다'만큼이나, I와 you를 구분할 정도로 완전히 다른 소리였는데 어쩌다가 요즘 사람들이 절대로 구분하지 못하는 소리의 쌍으로 전락했나 모르겠다. 서로 다르게 발음도 못 하고, 알아듣지도 못한다. 장음· 단음 구분이 망가진 것처럼 말이다.

요즘 통용되는 그 소리는 원래의 ㅐ도, ㅔ도 아닌 중간의 소리라고들 한다. 그런데 그 소리가 영어나 일본어에서도 쓰이는 보편적인(?) 소리인 건지도 모르겠다.
ㅐ/ㅔ뿐만 아니라 ㅒ와 ㅖ의 구분도 완전히 사라졌으며, ㅙ/ㅞ/ㅚ도 서로 변별력을 완전히 상실했다. 덕분에 재련과 제련, 결재와 결제, 제제와 제재 같은 한자어의 표기도 굉장히 헷갈리게 되었다.

한글이 처음 창제되던 당시에는 저 모음들이 어떻게 구분되어 발음되었는지.. 몇백 년 전 사람을 만나서 물어 보고 싶기라도 한 심정이다.

5. 사라져 가는 순우리말

까닭(이유), 달걀(계란), 뭍(육지, 땅) 같은 순우리말 단어는 한 1990년대 초반까지만 해도 방송과 도서에서 종종 접할 수 있는 단어였는데 갈수록 용례가 줄어들고 있는 게 보인다. 특히 '뭍'의 경우, 옛날에 전래동화 책에서 봤던 기억이 남아 있기도 하지만 이제는 사전에서나 찾을 수 있는 단어로 전락했다.

이런 식으로 '미덥다, 미쁘다, 미련하다' 같은 단어도 사라지는 것 같다. 어째 다 '미'짜로 시작한다는 공통점이 있다.
콩팥은 신장에 밀려서, 허파도 폐에 밀려서 앞날을 장담하기 어려워 보인다.
지금 세대는 알아듣기라도 하지만 다음 세대 애들한테는 완전히 듣보잡이 되겠지?

Posted by 사무엘

본인은 박사 과정에 진학해서 수업을 다 듣고 종합 시험도 통과한 뒤, 지난 2년이 넘는 기간 동안 휴학을 했다. 그리고 그 기간 동안 날개셋 한글 입력기는 8.6에서 9.7까지 올라갔다.
입력기 연구의 연장선에다가 글꼴 연구도 새로 접목하는 것을 목표로 진학했었는데, 입력기 연구가 당초 계획보다 다소 오래 걸렸다.

이제 입력기는 파일 포맷과 엔진 구조를 다 뜯어고칠 정도로 너무 비현실적인 추상화(재설계나 리팩터링), 아니면 너무 이상적인 수준의 기능을 제외하고 어지간히 규칙 기반 한글 입력과 관련된 것들은 다 통달했으며 잘 실현됐다. 9.7도 특별히 심각한 문제 없이 아주 잘 만들어졌다.

다만, 날개셋은 TSF 기반의 한글 IME일 뿐만 아니라 반대로 타 IME들을 구동해 주는 텍스트 에디터이기도 하니.. 요즘은 편집기에서 타 IME를 구동하는 동작과 관련된 이슈들을 좀 살펴보고 있다.

1. 내 프로그램에서 9.7 이후로 개선된 사항

(1) 외부 모듈의 옛한글 조합을 여느 블록(selection)과 달리 취급

날개셋 편집기에서 입력 항목을 '빈 입력 스키마'로 고르면 앞서 언급한 바와 같이 자체 입력기가 아니라 다른 외부 IME들을 사용할 수 있다.
그런데 한글 IME로 현대 한글을 조합할 때는 깜빡이는 네모 cursor가 나타나는 반면, 옛한글을 조합할 때는 조합이 그냥 블록 형태로 잡힌다. 그래서 자체 입력기로 옛한글을 입력할 때와는 달리 이질적이고 아마추어스러운 느낌이 난다.

이건 일차적으로는 운영체제에서 옛한글처럼 내부적으로 2개 이상의 코드값으로 표시되는 한글에 대한 배려를 안 해서 그렇다. 조합 문자열이 한글로만 이뤄져 있을 때 응용 프로그램이 강제로 보정을 해서 깜빡이는 네모 cursor를 구현하라면 할 수도 있다.

내 프로그램에서는 그렇게까지는 안 하는 대신, 비록 블록처럼 보이더라도 진짜 블록이 잡힌 것처럼 복사/잘라내기 버튼이 켜지지도 않게 프로그램의 동작을 깨알같이 개선했다. 그건 블록이 아니라 조합을 표시하는 용도일 뿐이기 때문이다..

(2) 붙여넣기를 할 때 외부 모듈의 조합이 덧나지 않게

또한, 자체 입력기가 아닌 외부 IME로 한글을 조합하고 있던 중에 도구모음줄의 '붙여넣기' 버튼을 마우스로 누르면..
자체 입력기를 사용할 때와 마찬가지로 조합이 종료된 뒤에 클립보드 내용이 삽입되는게 정상이다.

하지만 지금까지는 그렇지 않았다. 조합이 중단되고 그 문자열이 사라지고서 클립보드 내용이 삽입되었다. 이 버그를 발견하여 고쳤다.

이 두 가지 사항은 언제쯤 다음 버전에 반영되어 나올지 모르겠다.

2. 내 프로그램과 무관한 운영체제의 버그

(1) IME 도구모음줄이 두 종류 모두 표시됨

Windows 10 1803 버전 기준으로..
IME의 구형 재래식 도구모음줄과 Windows 8 스타일의 간소화 도구모음줄이 다같이 동시에 뜨는 경우가 있다. 정확한 재연 조건은 잘 모르겠지만 컴퓨터를 절전 상태로 껐다가 다시 켰을 때 가끔, 그러나 확실하게 이런 현상이 발생한다.

"고급 키보드 설정"에서 "사용 가능한 경우 바탕 화면 입력 도구 모음 사용" 옵션을 건드려 주면 다시 둘 중 하나만 나타나게 개선되긴 한다. 하지만 이건 운영체제의 버그이니 나중에 업데이트를 통해 해결되어야 할 것이다. Windows 8은 물론이고 10도 초창기에는 이런 현상이 발생한 적이 없었다.

(2) 일본어 IME의 조합 관리 버그

날개셋 편집기 또는 IE/Edge 브라우저의 텍스트 입력 폼에서 Microsoft 일본어 IME를 구동하고, 히라가나 모드에서 일본어를 몇 자 입력한다.
space를 눌러서 그 일본어 문자를 변환은 하지 말고, 좌우 화살표 키를 눌러서 조합 영역을 빠져나간다. 그러면 조합을 나타내는 밑줄이 일시적으로 사라진다.

그 뒤에 caret이 기존 조합 영역으로 돌아오면 기존 조합이 다시 생겨야 되는데 그리 되지 않는다.
그 상태에서 다른 곳에서 Shift+화살표를 눌러서 블록을 만들어 보면 아까 조합하던 일본어 문자가 덧나서 잘못 삽입된다.

이 버그는 Windows 10의 16xx대 이전 버전에서는 발생하지 않다가 후대 버전에서 나타났다. 1803의 후대 버전에서는 어찌 되었나 모르겠다. 날개셋 편집기뿐만 아니라 MS에서 만든 TSF A급 웹브라우저에서 모두 동일하게 발생하니 내 프로그램만의 문제도 아니다.

단, 워드패드에서는 동일 운영체제와 동일 IME에서 저런 오동작이 발생하지 않는다. 서식을 지원하기도 하니 에디팅 엔진 차원에서 무슨 차이가 있어서 그런 것 같다.

(3) 옛한글 IME의 조합 영역 처리 버그

이건 Windows 8 이래로 계속 동일한 것 같은데..
마소에서 제공하는 옛한글 입력기는 초성이나 중성에 옛한글이 들어간 상태에서 종성의 첫 타를 입력하면.. caret 위치가 좀 이상하게 찍힌다. 내부적으로 표현되는 글자 수가 3자가 되었으니 0~3까지 모두 조합 영역으로 설정해야 하는데 종성이 입력되기 전처럼 0~2까지만 설정한다.
그래서 날개셋 편집기에서는 화면이 일시적으로 이렇게 표시된다. 종성 둘째 타 이후부터는 다시 괜찮아진다.

시각적으로 좀 이상한 것 말고 다른 오동작은 없다. 하지만 날개셋, 한컴 입력기 등 옛한글 입력을 지원하는 다른 모든  IME에는 이런 현상이 없고 MS IME만 저러니.. 이건 저 프로그램만이 단독으로 해결해야 할 문제로 보인다.

3. 단순 차이점 -- 옛한글 filler 글쇠

두벌식 옛한글 글자판에는 중성이 빠진 미완성 한글 내지 종성 단독 낱자를 입력하기 위해서 일명 filler라는 글쇠가 있다. 위치는 관례적으로 Shift+J로, 날개셋, 아래아한글, MS 옛한글 입력기가 모두 동일하다.

날개셋과 아래아한글에서는 이 filler라는 게 언제나 '중성 filler'를 의미한다. 이것만 있어도 초성이나 종성이 없는 글자는 입력 가능하기 때문이다.
하지만 MS의 경우, filler도 뭔가 두벌식스럽게 글자를 완전 처음 입력할 때는 빈 자리에다가 '초성 filler'를 흉내 내어 주는 것 같다. 굳이 그럴 필요가 없지만 말이다.

그래서 초기 상태에서 종성을 단독으로 입력하려면 filler를 한 번이 아닌 두 번 눌러야 한다. 본인은 처음엔 이런 차이를 몰라서 마소 옛한글 입력기로는 종성 단독 입력이 불가능한 줄 알았다.
초성 filler도 지원해 주는 게 사람에 따라서는 더 직관적으로 보일 수도 있다. 하지만 한글을 연속으로 입력하기 시작하면 filler는 어차피 사실상 중성으로만 동작해야 하기 때문에 굳이 저럴 예외를 둘 필요가 있나 싶다.

중요한 건 이런 동작조차도 표준으로 딱 정해진 게 없어서 프로그램마다 차이가 있을 수 있다는 점이다. 날개셋에서는 글쇠배열의 수식을 바꿔 주면 지금 동작(중성 고정)뿐만 아니라 MS IME의 동작도 물론 구현할 수 있다.

4. 원인을 알 수 없는 문제

다음은 본인의 개발 환경에서 아주 드물게 발생하는 것을 확인하긴 했지만 재연 조건을 전혀 몰라서 좀 난감한 지경에 있는 버그 아이템들이다. 이것들이 문제의 원인이 전적으로 내 프로그램의 귀책사유로 판명되어 해결된다면.. 위의 1번의 개선 사항까지 포함해서 다음 버전인 9.71이 지금이라도 당장 나오게 된다.

(1) 여전히 발생하는 랙

이번 9.7에서는 안 그래도 편집기의 에디팅 엔진과 관련된 몇몇 버그들이 잡히고 내부 동작 방식이 최적화 됐다. 그런데 편집기를 한번 띄워 놓고 며칠 이상 오래--특히 중간에 컴의 절전 모드와 복귀를 수차례 반복할 정도로-- 쓰다 보면, 어느 샌가 글자가 화면에 나타나는 속도가 내 타자 속도를 못 따라갈 정도로 랙이 걸리는 경우가 여전히 발생한다.

게다가 이게 참 악랄한 게.. 랙의 발생하던 당시에 발생 조건이 다음과 같이 가변적이었다는 것이다.

• 오로지 날개셋 외부 모듈로 한글을 입력할 때만 느려짐 (MS IME, 자체 입력기 등등은 괜찮음)
• 외부 모듈로 한글을 입력할 때만 느려짐 (날개셋, MS IME에서 랙. 자체 입력기는 괜찮음)
• 아무 방식으로나 글자를 입력할 때 몽땅 느려짐

마지막으로 이 문제가 발생했을 때엔.. 처음엔 외부 모듈에서만 발생하는 것 같더니 이내 상황이 최악으로 바뀌었다.
특정 문서의 맨 마지막 줄에서 글자를 입력할 때만 극심한 랙이 걸리고, 그렇지 않을 때는 괜찮았다(타 문서 or 다른 줄). 심지어 그 문서에서 편집하고 있던 텍스트를 몽땅 지우고 새로 입력을 시작해도 랙이 사라지지 않았다.

이 랙이 발생하는 동안 내 프로그램의 내부에서는 무슨 일이 벌어지고 있고 도대체 어느 계층에서 뺑뺑이를 도는 건지 도무지 알 길이 없다. 그냥 평범하게 프로그램을 띄워서는 절대로 발생하지 않는다. 그나마 유력한 단서가 될 만한 현상은.. 이때 날개셋 편집기가 다음과 같이 memory leak이 발생해 있었다는 것이다.

(2) MS IME를 사용할 때 발생하는 괴이한 memory leak

날개셋 편집기와 작업 관리자를 같이 실행한다. 다음으로, 편집기에서 TSF 지원 옵션을 켠 상태에서 '빈 입력 스키마'를 고른다.
Microsoft 기본 한글 IME로, "세벌식 390/최종"(두벌식 말고)으로 "ㅇ.ㅇ.ㅇ.ㅇ." 처럼.. 한글 + 비한글 문자를 수십 회 쭈룩쭈룩 교대로 입력해 보라.

그러면 초기에 2~3MB대 안팎이던 프로세스 메모리 사용량이 계속해서 증가하는 게 관찰된다. 명백하게 memory leak이다.
COM 오브젝트 간의 reference count 같은 게 꼬인 것 같은데.. 이건 도대체 누구 잘못이라고 봐야 할까?

당연히, 디버그 빌드에서 단순 memory leak detector로는 문제가 전혀 감지되지 않는다. 내 프로그램은 10수 년에 달하는 짬밥을 자랑하며 얼마나 오랫동안 안정화가 돼 왔는데.. 소스 코드 상으로 무식한 결함이 있지는 않다.

더구나 날개셋, 한컴 입력기 등 "타 IME에서는 이런 현상이 없다." MS IME도 세벌식을 쓰고 있을 때만 저렇고 두벌식일 때는 문제 없다.
그리고 Windows Vista, 7, 10에서 이 현상을 확인했다. 구닥다리 XP에서는 MS IME+세벌식에서도 문제가 없다.

그럼 내 과실 0, 마소 과실 100을 입증하려면 날개셋 편집기 말고 다른 프로그램에서도 MS IME + 세벌식으로 저렇게 쳤을 때 동일한 memory leak이 발생한다는 걸 입증해야 하는데 그건 또 그렇지 않아 보인다~! 워드패드, MS Word, IE, Edge 등 TSF를 지원하는 프로그램들은 또 희한하게도 저런 현상이 발생하지 않는다.

다음으로 지푸라기를 잡는 심정으로 날개셋 구버전까지도 구해서 써 봤다.
날개셋 8.0까지는 이 문제가 없고, 8.4부터 leak이 발생하더라. 8.2는 불명.. 그러니 이 버그는 대략 2016년부터 있어 왔다는 것이다.
이때 도대체 어떤 변화가 있었는지.. 본인은 프로그램 소스를 자주 백업하는 편이지만, 컴퓨터가 바뀌는 과정에서 지금으로부터 3년이 넘게 너무 오래된 소스는 갖고 있지 않아서 이 방법으로도 문제의 원인을 파악할 수 없었다. ㅠㅠ

난 Windows용 IME라는 물건을 개발하느라 지난 10여 년 동안 온갖 희한한 버그 신고들을 받고 기상천외한 지저분한 환경에서 디버깅을 했다. 그러면서 마치 교통사고 과실 비율 따지는 것 같은 현상들을 많이 경험했었다.
둘 다 스펙대로 100% 무결하게 구현된 건 아니었고(혹은 스펙 자체가 모호해서..) 둘 다 조금만 조심하면 됐는데 둘 다 무데뽀로 동작해서 운 나쁘게 문제가 발생하는 것.. 말이다. Windows용 IME라는 바닥은 무척 "구리다."

아무튼 현재로서는 저 memory leak의 원인과 해결 방법이 오리무중이다. 해결만 된다면 9.7 다음으로 9.71이 당장 나와야 할 것이다.

(3) 제어판 닫았을 때 프로그램 뻗나?

정말 민망하고 황당한 버그인데.. 올해 들어 두세 번인가 겪었다.
날개셋 편집기에서 제어판을 꺼내서 설정을 바꾼 뒤, 확인을 눌러서 닫았더니 편집기 프로그램이 그냥 대짜로 뻗어 버렸다.
한 번 발생했을 때는 그냥 재수없는 우연인가 싶었는데, 몇 주 전에 마지막으로 동일 문제를 겪었을 때는 '미저장 확인'을 누른 것만으로도 뻗었다.

물론 그 뒤로는 편집기에서 날개셋 외부 모듈을 또 얹고, 제어판에서 온갖 설정을 바꾸고 빠른설정을 띄우면서 지지고 볶아 봐도.. 동일 문제가 다시는 재발하지 않고 있다. 위의 랙도 몹시 드물게 발생하지만 이 crash는 그것보다 더 드물게 발생했다. 그래서 난감하다.

Posted by 사무엘