우리 주변에서 교량(다리)이라는 건축물들을 보면 (1) 교각이라고 불리는 기둥들이 물 위에 일정 간격으로 박혀 있고, 그 교각들을 한데 잇는 길이 위에 놓여 있다. 그 이상 딱히 다른 특이사항은 없다.

사용자 삽입 이미지
(밋밋 평범한 다리의 예: 한남대교 ㄲㄲㄲ)

하지만 어떤 교량은 추락· 투신을 방지하기 위한 난간의 규모 이상으로 (2) 거대한 철골 구조물(트러스? 아치?)이 놓여 있다. 자동차보다 훨씬 더 무거운 열차가 다녀서 그런지 한강철교가 이런 형태이다. 그 밖에 서울 지하철이 다니는 동호대교(3호선)과 동작대교(4호선)도 이런 범주에 들며, 특히 후자는 동그란 아치 모양의 철골 구조물이 있다.

사용자 삽입 이미지
사용자 삽입 이미지

다만, 모든 철교가 이런 형태인 건 아니다. 그리고 철골 구조물이 그냥 다리 하부에 상판과 기둥 사이에 설치된 것도 있다. 성수대교 내지 구 당산철교(부실 시공 붕괴 위험으로 인해 1997년에 철거됨)가 그 예이다.

사용자 삽입 이미지
(게르버트러스 공법이 사용된 성수대교. 유난히 야경이 많이 검색돼 나온다.)

경부 고속도로의 초기 개통 구간 중에는 비록 강을 건너는 건 아니지만 아래의 지형을 훌쩍 타넘는 고가 교량이 몇 군데 있었다. 대전 육교와 당재 육교가 대표적인데, 미관을 살리고 아래에 차지하는 공간도 최소화하기 위해 교각이 아치 형태로 만들어졌다. 1960년대 말에는 이 정도 건축물을 만드는 것도 굉장히 어렵고 위험한 일이었다.

사용자 삽입 이미지

그 다음으로 대형 교량 중에는 (3) 다리의 기둥을 아득히 초월하는 높은 주탑이 세워져 있고, 다리 상판이 케이블에 매달린 형태인 게 있다. 신기하지 않은가?

사용자 삽입 이미지
(인천대교의 어마어마한 위용..)

사장교는 상판의 각 지점이 주탑과 직통으로 연결돼 있다. 그래서 주탑으로부터 덕지덕지 뻗은 케이블은 직선 모양이다. 서울에서는 올림픽대교가 사장교의 유명한 예이며, 서울과 인천 공항을 연결하는 인천대교, 그리고 당진과 평택을 잇는 서해안 고속도로의 서해대교도 사장교이다.

사용자 삽입 이미지
(올림픽대교는 이런 게 사장교라고 작은(?) 주탑 하나로 데모를 보인 수준이다.)

그 반면 현수교는 양 주탑이 주케이블로 연결돼 있고, 주케이블에 일정 간격으로 매달린 보조 케이블들이 상판들을 지탱하는 형태이다. 그렇기 때문에 주케이블의 선형은 곡선이다.
영종대교, 부산의 광안대교, 울산의 울산대교가 현수교이다.

사용자 삽입 이미지
(샌프란시스코 금문교. 색깔이 빨간 게 인상적이다.)

샌프란시스코의 금문교(Golden Gate)는 현수교의 상징이나 마찬가지이다. 1940년에 바람에 흔들려 요동치다가 붕괴된 걸로 유명한 미국의 타코마 다리 역시 현수교였다.
현수교는 현존하는 다리들 중 기둥 사이 간격을 압도적으로 제일 멀리 벌릴 수 있는 형태이다(거의 2km 이상도).

울산대교는 인도가 존재하지 않는 자동차 전용 도로 교량임에도 불구하고 지난 몇 년간 주행 중에 차에서 갑자기 내려서 뛰어내리는 자살 시도자 때문에 골머리를 앓고 있다고 한다. 하지만 거기에다 무슨 마포대교 같은 급의 거대한 난간과 자살 방지 시설을 추가로 설치하는 건 불가능하다. 케이블이 상판을 지탱하는 현수교의 특성상, 다리가 버틸 수 있는 하중이 무한하지 않기 때문이다.

사용자 삽입 이미지
(울산대교~!!)

사장교와 현수교는 경제성 및 안정성 면에서 제각기 장단점이 있다. 사장교는 주탑이 하나만 있어도 되지만 현수교는 그 특성상 적어도 둘 이상 필요하다.
한강의 하류 서울 시내 구간은 폭이 1km 남짓이니 강치고는 굉장히 큰 편이지만, 그래도 사장교라면 모를까 현수교가 필요할 정도의 길이는 아니라고 여겨진다.
사장교와 현수교의 차이를 한눈에 쏙 들어오게 그림으로 묘사하면 다음과 같다.

사용자 삽입 이미지

자, 이렇게 (1)뿐만 아니라 (2)나 (3) 유형의 다리가 있는 이유는 무엇일까? 특히 바다를 건너는 길이 수 km짜리 거대한 교량은 굳이 엄청나게 높은 주탑까지 세우면서 (3)과 같은 형태로 만드는 이유가 무엇일까?
그저 미관과 폼 때문에? 그렇지 않다. (2), 특히 (3)은 같은 무게를 지탱하는 다리라도 “기둥 수를 최소화해서” 만들려는 노력의 결과물이다.

자잘한 기둥 여러 개를 그냥 커다란 주탑 하나와 케이블로 퉁치는 게 더 저렴하다는 것, 콘크리트 구조물이 그냥 물도 아닌 바닷물 소금물에 쩔어서 좋을 건 하나도 없으니 적을수록 좋다는 것 따위는 부수적인 이유이다. 무엇보다도 다리 아래로 일정 규모 이상의 큰 선박이 지나갈 공간이 있어야 하기 때문이다. 이건 강이 아닌 바다 위의 교량이라면 진지하게 고려해야 할 사항이 된다.

과거에는 이럴 때 자동차와 선박의 건널목 평면교차나 마찬가지인 도개교를 만드는 게 유행이었다. 하지만 요즘은 기술의 발달로 인해 다리 자체를 엄청 크고 높게 만들고 말지, 교통수단 간의 평면교차는 만들지 않는 추세이다.
이렇게 다리의 유형 종류를 알고 나면 다음에 자동차나 열차로 다리를 건널 일이 있을 때 이 다리는 어떤 방식인지를 더 주의 깊게 보게 될 것이다.

현수교와 관련해서는 꽤 의외의 사실이 있다. 현수교의 주케이블이 자연스럽게 형성하는 선은 현수선이 아니다.
그냥 자연스럽게 매달려 있기만 할 때는 현수선이지만, 일정 간격으로 주렁주렁 매달린 보조 케이블로부터 힘을 받으면서 유사품(?)인 포물선에 가깝게 변형된다.

그 이유는 의외로 간단하다.
현수선은 걸리는 무게가 선 자체의 길이에 비례해서 커진다.  그렇기 때문에 이전에 살펴본 바와 같이 미분 방정식에 거리 적분이 들어갔으며, 이게 cosh라는 함수의 근원으로 작용했다.

그러나 현수선 아래에 하중이 걸리는 것은 선 자체의 길이나 기울기와 전혀 무관하게 그냥 x축의 일정 간격으로 균일하게 힘이 가해지는 것이다. 그러면 미분 방정식이 f(x) = x 급으로 아주 간단해지며, 문제의 함수는 포물선을 그리는 이차함수로 귀착된다.

다만, 선형이 완벽하게 포물선이 되기 위해서는 걸리는 하중이 띄엄띄엄이 아니라 연속적으로 일정하게 걸려야 하며, 줄 자체의 무게는 걸리는 하중과 비교했을 때 무시할 수 있을 정도로 없다시피해야 한다.
그렇지 않은 현실에서는 선형이 현수선과 포물선 사이의 어중간한(?) 모양이 되겠지만.. 포물선과 현수선은 특정 조건을 만족하는 한도 내에서는 어차피 서로 매우 비슷한 모양이라고 여겨진다.

1600~1700년대에 고전 역학과 미적분학이란 게 처음 생겨나던 시절에는 뉴턴, 호이겐스, 베르누이, 라이프니츠 같은 당대의 날고 기는 수학자들 사이에서도 이 궤적이 포물선일까 현수선일까 긴가민가 하는 경우가 있었다. 그 시절엔 충분히 헷갈릴 만도 했다는 생각이 든다.;;

Posted by 사무엘

2020/11/16 19:35 2020/11/16 19:35
, , , , , , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1820

현수선

자연에서 중력이 만들어 내는 물체의 '운동 궤적'은 이차함수 포물선이다. 중력이 물체를 아래로 일정하게 가속시키기 때문이며, 이는 심지어 총알 같은 작고 가볍고 빠른 물건이라도 예외가 아니다. 지구에서는 그나마 공기의 저항이란 게 있어서 그 포물선의 말단 부분이 더 가팔라지는 것을 막아 준다.

사용자 삽입 이미지
(바람이나 공기 저항 같은 게 없다면 이것들이 다 포물선 궤적일 것이다.. ㄲㄲ)

한편으로, 중력이 자연스럽게 만들어 내는 '물체의 선형'은 현수선이다. 밀도가 동일한 줄, 선, 사슬 따위를 양 끝을 잡아서 매달았을 때 그 줄이 자연스럽게 축 늘어진 모양 말이다. 이건 포물선이나 타원(!!) 따위가 아니라 수학적으로 완전히 다른 선형이다.

사용자 삽입 이미지

포물선은 공중으로 내던져진 물체가 붕 떠올랐다가 떨어지는 궤적이다. 그렇기 때문에 운동 궤적 말고 자연에서 포물선이 쫙 그려지는 것은.. 글쎄, 불꽃놀이에서 불꽃이 자기 궤적 잔상을 남기면서 움직이는 모습 같은 게 아니면 보기가 쉽지 않을 것 같다.

그에 반해 현수선은 길다란 줄이 늘어져서 정지한 모습 그 자체이기 때문에 어쩌면 포물선보다도 더 친근한 모습일 수 있다.
포물선은 이차함수이며 원뿔곡선에 속하는 반면, 현수선은 답부터 말하자면 더 생소하고 어려운 쌍곡선함수, cosh이다. 왜 그렇게 되는 것이며 이 함수가 지니는 의미는 무엇일까?

일단 쌍곡선함수라는 것 자체가 중등 교육과정에는 등장하지 않는다. 그리고 현수선의 원리를 제대로 설명하려면 고전역학 지식이 필요하며, 식을 유도하려면 역시 중등에서는 배우지 않는 미분방정식이라는 걸 풀어야 한다.
하지만 꼭 그 정도로 엄밀하게 따지지 않더라도 cosh가 될 수밖에 없는 대략의 이유 정도는 중등 수준만으로도 납득할 수 있다.

현수선은 외형상 명백하게 중력이 작용하는 아래로(y축 값이 작아지는 쪽) 볼록하면서 좌우가 대칭인 곡선이어야 할 것이다.
현수선 공식을 유도하는 여러 사이트들의 설명은 대체로 비슷하다. 선 내부에 있는 임의의 점에 대해.. x축으로 작용하는 힘은 좌우가 모두 동일한 반면(그래야 합력이 0으로 상쇄되고 안정되므로), y축으로 작용하는 힘은 자연스러운(= 줄이 향하는 방향) 상하뿐만 아니라 양쪽 줄의 무게까지 감안했을 때 합력이 0이 된다는 것이다.

사용자 삽입 이미지
(이 식에서 Fx는 T(x)cosθ = T(x+dx)cosθ일 뿐만 아니라 x, dx, θ에 관계없이 값이 일정하다. 그리고 Fy에서 m은 "줄의 밀도"와 해당 지점까지 "줄의 길이"의 곱으로 나타낼 수 있다. 그림의 출처는 여기..)

그래서 선의 정체에 대한 결론은 다음과 같은 형태의 미분방정식으로 귀착된다.

사용자 삽입 이미지

이게 의미하는 게 무엇일까?
이 f(x)는 어떤 점 x에서의 기울기(좌변)가 0부터 x까지 f(x) 함수 곡선의 거리(우변)와 동일 내지 상수배 정비례한다는 뜻이다.
양변을 한번 더 미분하면 아래처럼 되지만, 2차 도함수(도함수의 변화량을 나타내는 도함수..)는 머리로 이해하기가 더 난감하다.

그럼 sqrt(1+f'(x)^2)라는 거리 적분식은 어디서 왜 나오는가..? 줄의 무게가 줄의 길이에 정비례하기 때문이다.
x축 지점에 대한 도함수에다가 그 지점까지 선의 길이에 대한 함수값을 대입하면 식이 그렇게 나오게 된다.

도함수 f'(x)가 x 자체와 같은 함수 f(x)는 x의 부정적분인 x^2 /2 + C ... 즉 포물선이 된다.
f'(x)가 f(x)와 같은 함수는.. e^x, 즉 지수함수이다.
그 반면 f'(x)가 거리 적분과 같은 함수는 중력이 작용하는 임의의 지점에서 역학적 평형을 이루는 현수선이 된다는 것이 핵심이다. 그리고 이 미분방정식을 풀면 이 f(x)는 cosh가 된다.

cosh는 맞은편 쌍곡선함수인 sinh와 짝이며, 미분· 적분을 하면 상대방으로 곧장 바뀐다. cos/sin처럼 부호가 바뀌면서 4행정(?) 순환을 하는 것도 아니고 그냥 2행정이다. 그렇기 때문에 cosh는 2차 도함수도 자기 자신과 같다.
그 말인즉슨... f(x)는 어디에서든 길이의 증가폭과 면적의 증가폭이 동일한 함수라는 뜻도 된다! y=x 같은 직선은 이 조건을 만족하지 않는다. x가 커지면 길이는 일정하게 증가하더라도 아래의 면적은 제곱으로 증가하기 때문이다.

그리고 cos^2 + sin^2 = 1이듯이 쌍곡선함수는 cos^2 - sin^2 = 1이다.
sqrt( 1 + f'(x)^2 )에서 f(x)에다가 cosh(x)를 집어넣으면 f'(x)^2는 sinh(x)^2가 되는데, 얘는 저 정의에 따라 cosh(x)^2 - 1로 치환 가능하다. 그러니 -1은 앞의 1과 상쇄되어 없어지며, 제곱은 제곱근과 상쇄되어 없어지니...
찰나의 거리 변화량을 구하는 함수가 자기 자신과 동일해지는 것이다!

예전에 란체스터의 법칙 얘기를 하면서도 쌍곡선함수가 나왔는데, 얘가 비록 삼각함수보다 인지도가 떨어지지만 나름 자기 분야에서 유용한 구석이 있음을 알 수 있다.

Posted by 사무엘

2020/11/14 08:35 2020/11/14 08:35
, ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1819

only에 대한 생각

한국어에는 '단 하나뿐인 / 유일한'이라는 말이 있고, 영어에도 only one이라는 말이 있다.
그런데 수학이나 논리학 같은 데서는 one과 only를 더 엄밀하게 구분해서 표현해야 할 때도 있다. 둘은 서로 독립된 별개의 속성이기 때문이다. 이런 맥락에서는 표현도 only one이 아니라 one and only가 된다. one은 이때 명사/대명사가 아니라 형용사임을 주의할 것.

only라는 속성을 지닌 유니크한 개체라고 해서 반드시 단수 형태여야 할 필요가 없다. 복수이고 집단이지만 우주를 통틀어 그 물건이 이것밖에 남아 있지 않다는 것을 강조하고 싶은 상황도 생기는 법이다.
이럴 때 영어는 the only 복수형 명사가 자연스럽게 붙는다. 그러나 only의 한국어 번역인 '유일한'에는 일(一)이라는 글자가 들어가 버려서 그냥 only가 아니라 one and only라는 의미가 추가된다. 그래서 의미의 범위가 더 좁아진다.

이건 마치 "one of the ...-est(최상급) 복수형 명사"가 의미상 잘못됐다는 관점과도 비슷해 보인다. "1등이라면 하나뿐이지 웬 '가장 뛰어난 물건들 중 하나'.. 이딴 식이냐"라는 식으로 트집을 잡을 수 있다.
하지만 좁게는 공동 1위도 있을 수 있고, 그리고 저런 표현은 단순히 가상의 등급 하에서 최상이라고 생각할 수도 있다. 학력고사 전국 수석이 아니라 그냥 수능 1등급을 가리킨다는 것이다.

하물며 only는 이것 말고 다른 건 없다는 뜻이므로 등수도 아니고.. 얼마든지 복수가 존재할 수 있다.
그렇다고 유이한 존재, 유삼한 예외, 이렇게 얼치기로 말을 만들 수는 없으니, '유일'은 글자 단위로 쪼개서 생각하지 말고 one을 배제한 only라는 의미만 생각해서 통용해야 할 것 같다.

'이름'이 full name과 first name이라는 중의성을 지니듯, '유일'은 only와 one and only의 뜻을 모두 지닌다는 것이다. 얼치기 같지만 이런 식의 다의 중의성은 영단어에도 얼마든지 존재한다. man (남자 vs 사람)이나 day (낮 vs 날)처럼 말이다.
한국어에서 one and only를 꼭 강조하려면 앞에 '단일'을 추가해서 '단일 유일'이라고 표현하면 되지 않을까?

성경에서 요 3:16 '독생자'가 영어로 어떻게 표현돼 있는지 생각해 보자. 하나이면서 또 다른 아들이 없음을 나타내야 하니 only begotten Son 내지 one and only Son이다.
일반적으로는 only son이라고만 해도 외아들이라는 뜻이 통하지만, one and only는 그걸 더 강조해 준다. begotten은 하나님으로부터 직통으로 났다는 의미를 강조한다는 차이가 있다.
(영어는 씨를 준 아버지의 관점에서 누구를 낳은 건 beget이라고 표현하며, 씨를 받아서 아이를 실제로 출산한 어머니의 관점에서 낳은 것은 bare이라고 표현한다는 점 역시 생각할 사항..)

only와 관련하여 one 다음으로 살펴볼 단어는 if이다.
if A then B는 "A이면 B이다"라고 프로그래밍 언어에서도 매우 즐겨 등장하는 문장 구조이다. only if는 "A여야만, A일 때만" 정도와 대응한다. 둘의 차이가 무엇인지에 대해서는 수학의 집합과 명제 시간에 다들 배우게 된다.

  • A^2=1 if A=1 (A=1이라면 A^2의 값이야 다른 선택의 여지가 없이 무조건 1임. 하지만 A^2를 만족시키는 값 자체는 1 말고도 더 있음. 충분조건)
  • A=1 only if A^2=1 (A^2=1이라고 해서 100% 반드시 A=1이라는 보장은 없지만, 최소한 A^2의 값이 1이 아니라면 A가 1일 가능성은 전혀 절대 존재하지 않는다. 필요조건)

그러므로.. 둘은 관점이 서로 다르다.

  • A=1은 A^2=1이기 위한 충분조건이다. A^2=1에 대한 정밀도가 100%이다.
  • A^2=1은 A=1이기 위한 필요조건이다. A=1에 대한 재현율이 100%이다.

이런 식의 포함 관계를 명확하게 하기 위해, 계약서 같은 법적 문서엔 including but not limited to (A를 하나 제시하지만 A만 맞다는 건 아니며, 다른 가능성도 있음) 라는 조건 문구가 즐겨 등장하는 것이다.
"A^2=1을 만족시키는 수를 하나 찾아 준다고 했지, 이것밖에 없다고 말했거나 전부 찾아 준다고 말한 적은 없습니다~ 나는 거짓말 안 했어요" 이런 식의 면피를 위해서이다.

if와 only if를 합쳐서 if and only if (iff)가 돼야만 두 명제가 완전히 필요충분 동치가 된다.

  • 정사각행렬 A는 판별식 값이 0이 아니다. if and only if Ax = O을 만족하는 열벡터 x가 trivial solution밖에 없다.

이런 식으로 말이다.
그런데 iff는 우리말로는 어떻게 표현해야 좋을까? "-이고 -이어야만 / -이고야만" 본격적으로 우리말로 학문을 하려면 뭐 이런 식으로 짤막하게 말을 만들어야 할 것 같다.

이상이다.
어떤 사물이나 조건이 있는데 그게 여러 개체들 중의 한 인스턴스(!!)일 뿐인지, 아니면 이것밖에 없는 유일한 개체인지를 따지는 것은 언어의 저변 사상에서 차지하는 비중이 꽤 크다. 0이냐 1이냐, 아니면 다수이냐 말이다.
그렇기 때문에 영어에는 정관사와 부정관사가 있고 단수와 복수도 깐깐하게 따진다. 한국어는 그런 관념은 딱히 없지만 '-가', '-는', '-만', '-도' 같은 조사들이 세밀하게 발달해 있으며, 생물이냐 무생물이냐 여부를 영어보다 더 따지는 편이다.

한국어는 용언과 부사가 발달해서 no(없음)라든가 more(더 이어지는, 더 있는) 같은 개념이 관형어로 딱히 존재하지 않는 반면, '없다', '모르다' 같은 건 의외로 한 단어로 깔끔하게 존재한다.

only에 대해서도 이렇게 생각할 것들이 있다는 게 이 글의 요지이다. '유일' 말고는 의존명사 겸 조사인 '뿐', 부사 '오직', 그리고 관형사 '단' 따위로 나뉘어 번역되는데.. '단'은 사실상 숫자 앞에서만 붙기 때문에 제약이 큰 편이다(단 두 개..). "단, 조건이 있다" 같은 접속사하고 헷갈리지 말 것.

Posted by 사무엘

2020/11/12 08:35 2020/11/12 08:35
, , , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1818

오늘날처럼 컴퓨터의 문자 인코딩이 유니코드로 천하통일이 되기 전엔 국내에서는 2바이트 완성형과 조합형 한글 코드 논란이 가라앉지 않고 있었다. 완성형은 94*94 격자 모양의 단순하고 국제 규격에 부합하는(?) 방식으로 인코딩돼 있었지만 한글의 구성 원리를 무시하고 한글을 난도질했다는 비판을 떠안고 있었다.

완성형은 “한글 vs 비한글”을 구분하고 처리하는 데 유리했다.
그에 비해 민간에서는 “한글 글자 vs 낱자”의 처리가 더 용이한 조합형이 훨씬 더 대중적으로 쓰였다. 그도 그럴 것이 640KB 기본 메모리를 1KB라도 더 확보하려고 목숨 걸던 시절, 메모리 모델이 어떻고 far 포인터가 어떻고 이러던 시절에.. 한글 처리를 위해서 2350자 테이블을 내장하고 다닌다는 건 성능과 효율로나 민족 정서(?)로나 도저히 용납할 수 없었기 때문이다.

허나, 명목상 국가 표준은 완성형이었기 때문에 마소 역시 도스와 Windows의 한글판을 전적으로 완성형 기반으로 만들었다. 완성형은 두벌식과 마찬가지로 그 시절에 소프트웨의 한글판을 필요 이상으로 더 무겁게 만든다는 비판을 피하기 어려웠다. 다만, 이건 애초에 우리나라에서 표준을 이상하게 만든 게 잘못이지 마소의 잘못은 아닐 것이다.

Windows 3.1이야 이런 배경에서 만들어졌기 때문에 한글 IME로 똠, 펲 같은 글자가 입력되지 않았으며, 또ㅁ, 페ㅍ이라고 글자가 풀어졌다. ‘썅’은 2350자에 속해 있는데 중간의 ‘쌰’는 그렇지 않기 때문에 ‘썅’까지 덩달아 입력할 수 없는 것은 유명한 사실이다.

그리고 처음부터 ‘쌰’를 입력하면 ‘ㅆㅑ’라고 잘 갈라지는데, 두벌식에서 ‘있’ 다음에 ㅑ를 입력하면 ‘이ㅆㅑ’가  되지 않고 뭔가 올바른 동작이 나오지 않았던 걸로 본인은 기억한다.
이런 것들이 한글 입력기, 특히 특정 문자 입력 제한이 걸린 두벌식 입력 방식을 구현할 때 고려해야 하는 복병이다. 날개셋이야 이 분야 전문이기 때문에 그런 것들도 다 정상적으로 처리해 준다.

그럼 차기 버전인 Windows 95는 상황이 어땠을까?
Windows 95는 오늘날 세계 표준 문자 집합 겸 인코딩인 유니코드, 특히 유니코드 중에서도 버전 2.0이 한창 제정되고 있던 와중에 개발되고 먼저 출시되었다. 이건 굉장히 중요한 사건이었다.

우리나라에서는 수 년 전 유니코드 1.x 시절에는 완성형 2350자만 그대로 제출하는 삽질을 저지른 적이 있었다. 그러다가 유니코드 2.0에서 문자 체계를 싹 재정비하는 인류 역사상 마지막 기회가 찾아왔을 때.. 한글을 11172자 모두 순서대로 등록하려는 과감한, 역사적인 계획을 세웠다. 그래야 글자 코드값으로 자모 정보를 쉽게 추출할 수 있기 때문이다.
이건 스타에다 비유하자면 종족 밸런스를 앞으로 다시는 바꾸지 않는 1.08 패치와 비슷한 타이밍이었다.

그런데 그렇게 하려면 세계를 설득해야 했다.
다른 나라들은(특히 일본과 중국도) BMP 영역의 1/5 가까이를.. 그것도 사용자가 1억도 채 안 되는 언어의 고유 문자로 싹 도배하려는 한국을 고깝게 보고 이의를 제기했다.
유니코드 회의에서 누가 발언권을 얻으려면 한화로 억대에 달하는 회원 등록비도 많이 내야 하는데, 이런 비용을 한컴 같은 기업에서 많이 후원해 줬다. 저 때는 삼성전자도 훈민정음 워드 같은 프로그램이나 간간이 만들었지, 지금 정도로 IT계에 세계구급 영향을 행사하는 기업이 아니었다는 걸 생각해 보자!

이런 우여곡절 끝에 한글 11172자는 1996년 7월, 유니코드 위원회의 승인을 받아서 성공적으로 등재되었다. 이거 내막을 아는 사람이라면 이것도 1981년 서울 올림픽 바덴바덴의 기적에 맞먹는 외교 승리라고 여기고 칭송한다. 올림픽은 52:27의 압승이라도 했지만 11172자 등재는 찬성이 반대를 한 표 차이로 정말 간신히 꺾은 거라고 한다.

그런데 문제는 Windows 95는 유니코드 2.0이 정식으로 발표되기 미묘하게 약간 전에 출시되었다는 것이다. 한글판도 1995년 11월 말에 출시됐으니..;;
그럼에도 불구하고 각종 글꼴과 코드 변환 테이블은 이미 유니코드 2.0을 기준으로 맞춰져 있다. 어떻게 이게 가능했을까?

유니코드 2.0에다가 한글을 2350자가 아니라 11172자를 몽땅 집어넣기 위해서는.. 근거가 필요했다. 유니코드가 아닌 기존 2바이트 인코딩 중에도 한글 11172자 표현이 가능한 놈이 있어야 했다.
그럼 Windows가 처음부터 조합형 코드로 개발됐으면 좋았겠지만 모종의 이유로 인해 그리 되지 못했고.. 결국은 기존 완성형에다가 지저분한 독자적인 편법을 동원해서 비완성형 한글을 끼워넣을 수밖에 없었다.

이게 그 이름도 유명한 확장완성형, 일명 CP949 인코딩이다.
KS X 1001은 한글 2350자, 한자 4888자 등을 포함하는 그 2바이트 완성형 문자 집합/코드이고, KS X 1003은 역슬래시를 원화로 대체한 그 한국 특유의 1바이트 영문/숫자 아스키 문자 집합이다. 이 둘을 합쳐서 EUC-KR이라고 부르고, 여기에다가 확장완성형까지 추가하면 CP949가 된다. 집합 관계를 정리하자면 (KS X 1001 ∪ KS X 1003) = EUC-KR ⊂ CP949이다.

(참고: KS X 1002는 완성형 형태로 현대 한글, 옛한글, 한자를 추가로 정의하는 규격이다. 하지만 KS X 1001과 병용하는 인코딩 규칙이 제정되지 않아서 컴퓨터에서 실제로 쓰인 적은 없는 캐잉여이다. 얘는 애초에 유니코드 1.1에다가 글자를 추가로 등록할 근거를 마련하려고 어거지로 만든 문자 집합에 지나지 않는데, 이제는 유니코드 1.1 자체도 오래 전에 흑역사가 됐으니 더욱 의미와 존재감이 없다.)

이렇듯, 확장완성형이라는 건.. 비록 처음에 첫단추를 잘못 끼우긴 했지만 뒤늦게 유니코드 2.0에라도 한글을 11172자를 순서대로 다 집어넣기 위해서 도입한 2바이트용 타협 절충안이었다. 마소에서는 한국 편을 들면서 도와 주면 도와 줬지, 최소한 상황을 더 나쁘게 만든 건 절대 없었다.

그럼에도 불구하고 1990년대 당시에는 마소에서 완성형에다가 그보다 더한 확장완성형까지 집어넣어서 한글을 난도질한다고 엄청난 논란이 일었다. 심지어 한컴에서도 아래아한글 도움말 및 제품 광고에서 이 괴담을 어느 정도 활용하고 부추겼다.

왜 한글을 난도질 하느냐 하면, 확장완성형은 이미 2350가 조밀하게 순서대로 배치된 건 그대로 유지하면서 나머지 틈새에다가 비완성형 8822자를 집어넣는 형태가 되기 때문이다. 그러면 겉보기로는 11172자가 모두 배당되지만 문자의 코드값 순서가 그 문자의 사전상의 배열 순서와 일치하지 않게 된다. 사전 순 정렬을 하려면 코드값을 별도로 보정을 해야 한다.

물론 코드값만으로 문자를 정렬할 수 있는 게 가능하지 않은 것보다는 더 직관적이고 깔끔하고 낫다. 하지만 오늘날 유니코드는 시간 차를 두고 뜬금없이 여기저기 지저분하게 추가된 문자들이 워낙 많기 때문에(특히 한자~!!), 거시적으로 봤을 때 코드값만으로 문자들을 정렬하는 건 어차피 불가능하고 무의미해져 있다.

뭐, 이것도 논란이 다 끝난 오늘날의 관점에서 보니까 별것 아닌 것처럼 보이지, 2바이트 한글 코드만 단독으로 생각하던 시절에 확장완성형이 답답하고 지저분하게 보이는 것도 부인할 수 없어 보인다.
그리고 마소는 훗날 IMF 때 경영난에 빠진 한컴에다가 돈줄을 대 주는 대신 아래아한글의 개발을 중단시키려 했던 바 있다. 그러니 확장완성형에 대한 불필요한 오해 실드를 감안하더라도 마소에 대한 국민 감정이 마냥 좋을 수만은 없었을 것이다.

아무튼, 그 시절 Windows 95는 유니코드 2.0의 정식 도입을 선도하면서 온전한 한글 11172자의 입출력이 가능해지려는 과도기에 연결 고리 역할을 했다.
참고로 95 말고 Windows NT는 도스 짬뽕이던 기존 Windows와 달리, 1993년 첫 버전부터 2바이트 wide char 유니코드 기반이었다. 얘도 유니코드 2.0이 정착할 무렵이 돼서야 본격적으로 정식 한글판이 나올 수 있었다. 3.51부터 말이다.

사용자 삽입 이미지

Windows NT 3.5 한글판의 ‘베타 버전’ 평가판. 이건 Windows NT의 역사상 최초로 만들어진 한글판으로, 정말 엄청난 희귀 레어템이다. 마치 Windows 2.x의 듣보잡 한글판처럼 말이다.

저 화면에서 한글 글꼴은 기존 Windows 3.1의 돋움체(큐닉스 제작) 8포인트이다. 하지만 영문은 정체를 모르겠다. W와 i의 폭이 다른 가변폭인 걸 보니 같은 돋움체의 영문은 아닌데, Arial은 물론이고 심지어 후대에 등장한 Tahoma나 Verdana까지 그 어떤 영문 글꼴도 저 크기에서 9나 5의 획이 저렇게 생기지 않았다.

그런데 저 영문 모양이 내가 보기에 전혀 낯설지는 않다.
마소에서 개발한 1990년대 옛날 프로그램의 스플래시 화면 내지 About 대화상자에서 Copyright 문구가 저런 스타일의 글꼴로 표시된 걸 본 것 같기도 한데.. 정확한 정체는 모르겠다.

내 기억이 맞다면 Windows NT 3.51의 정식 한글판은 3.51의 특성상 Windows 3.1과 같은 구형 UI 기반임에도 불구하고 한글 글꼴은 이미 Windows 95 한글판과 동일한 한양 시스템 글꼴로 갈아탔다.
Windows NT의 역사에서 유니코드 1.1 방식 한글이 존재했던 적은 내가 아는 한 없다. 만에 하나 있다면 그건 조합형 코드를 잠깐 썼었다고 전해지는 MS-DOS의 초창기 한글판만큼이나 완전 전설 속에나 존재하지 싶다.

이렇게 95건 NT건 온전한 11172자짜리 유니코드 2.0 기반임에도 불구하고.. 95의 한글 IME를 써 보면.. 구버전인 Windows 3.1과 마찬가지로 여전히 2350자밖에 입력할 수 없었다. 다만, “있+ㅑ”일 때는 ㅆ이 뒷글자로 넘어가지 않도록 로직이 약간 개선돼 있었다.;; ㅎㅎ

사실, Windows 95의 한글 IME는 확장완성형을 기반으로 11172자를 모두 입력하는 기능도 구현은 돼 있었다. 하지만 그걸 기본적으로는 봉인해 놓았으며, 사용 여부를 별도의 유틸리티를 통해 따로 지정할 수 있었다!
바로, C:\Windows 디렉터리에 있는 iso10646.exe라는 30KB짜리 자그마한 프로그램이다. 역시 괜히 과도기였던 게 아니다.

사용자 삽입 이미지

프로그램 UI에는 유니코드니 완성형이니 같은 말은 없고 그냥 "ISO 10646 사용 여부"가 전부였다. 유니코드의 문자 집합을 가리키는 표준 규격 명칭이 ISO 10646이기 때문이다.
전체 사용 아니면 특정 프로그램에서만 사용.. 이런 걸 지정해 주면 타 프로그램에서 똠쌰 등등의 글자를 입력할 수 있었다.

신기한 것은 Windows용 프로그램뿐만 아니라 도스용 mshbios의 한글 입력기까지 이 설정의 영향을 받았다는 것이다. 설정값을 레지스트리가 아니라 파일에다 저장했던가 보다. 아니면 도스에서도 레지스트리 파일에 저수준으로 접근을 했던지..

확장 한자의 사용 여부를 옵션으로 지정하는 것처럼 2350/11172자 입력 범위도 그냥 IME의 옵션으로 지정하면 됐을 것 같은데 굳이 별도로.. 제대로 문서화되지도 않은 프로그램에다 저렇게 꽁꽁 숨겨 놨다.
부작용을 어지간히도 의식했는지 각종 프로그램별로 입력 범위를 달리 지정할 수 있게 신경을 썼다. 즉, 여느 평범한 IME 옵션이 아니라.. 날개셋으로 치면 응용 프로그램별 동작 보정 옵션과 비슷한 걸로 취급한 것이다.

훗날 MS Office 97이 나왔고.. 그 중 Word는 단품으로 따로 팔기도 했다.
마소 역시 한컴 진영의 조합형 한글 마케팅을 많이 의식했는지, 신문 광고에서 조그맣게.. "우리 마소 제품에서도 똠방각하 펩시콜라 찦차를 입력할 수 있습니다." 문구와 함께, iso10646 프로그램 사용법을 소개해 놓기도 했었다.

본인은 학창 시절에 그 광고를 직접 본 기억이 있다.
지금도 구글에서 iso10646.exe 라고 검색해 보면 옛날 흔적을 찾아볼 수 있다.

마소의 전략은.. 요런 프로그램을 몰래 집어넣은 뒤, 확장완성형이 계속 부정적인 피드백을 받으면 Windows 95는 그딴 거 지원한 적 없다고 발뺌 하면서 2350자 기존 완성형에만 머무르면 될 것이고,
한글을 2350자밖에 입력 못 한다고 욕먹는 게 더 크면, 저 비장의 프로그램을 음지에서 양지로 끄집어내려는 속셈이었던 것 같다. 쉽게 말해 간보기 전략이다.

그러다가 Windows 98부터는 이런 간보기가 없어지고 그냥 모든 프로그램에서 확장완성형까지 활용한 11172자 한글 입력이 되기 시작한 것이다. 나중에 Office 2000과 함께 옛한글 입력기가 도입됐을 때는 이제 마소의 제품이 옛한글의 표현 능력도 아래아한글 97과 한컴 2바이트 코드를 추월하게 됐다.

이상이다. “라떼는 말이야” 같은 얘기가 좀 길어졌다.. ^^
25년 전, Windows 3.1에서 95로 넘어간 것은 정말 엄청난 격변이었다. 하지만 Windows 95와 98 사이에도 컴퓨터 환경은 굉장히 많이 바뀌었다.
가정용 PC의 평균 램 용량이 4~16MB대이던 것이 그 짧은 기간 동안 32~128MB로 순식간에 뻥튀기 됐다. PC 규격도 이것저것 많이 바뀌고.. 또 무엇보다도 이 사이에 유니코드 2.0이 제정되었다. 운영체제 차원에서 UTF-8 인코딩이 직접 지원되기 시작한 최초의 Windows가 바로 98이다.

Windows에서 완성형 2350자에 구애받지 않고 한글 입력이 가능해지기까지 이런 우여곡절이 있었다.
Windows 98은 현대 한글이 완전히 해금됐고, 지난 Windows 8 (2012)부터는 옛한글까지 해금됐으니 참 격세지감이다. 그 사이의 XP는 입력 프로토콜이 IME에서 TSF로 넘어간 과도기였고 말이다.

그런데 정작 옛한글 말뭉치를 엄청나게 많이 구축한 21세기 세종 계획은 이것보다 미묘하게 일찍 진행된 바람에 비표준 한양PUA 방식으로 결과물을 산출해 버렸으니 타이밍이 안습했던 구석이 있다.

Posted by 사무엘

2020/11/09 08:35 2020/11/09 08:35
, , , , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1817

1. 크리스천의 삶

성경 말씀대로 크리스천답게 사는 것, 예수님의 제자의 삶을 사는 것은 내 성깔을 죽이고 희생과 헌신과 손해를 수반하고 일면 바보같이 사는 구석이 있다. 하지만 이건 그렇다고 무슨 인생의 대단한 낙을 포기하고, 아무 멋도 재미도 없이 금욕주의 꼰대같이 사는 것은 절대로 아니다. 이 점에 대해 많은 사람들이 오해하고 있다.

뭐, 옛날 중세에는 도를 넘게 꼰대같은 관행이 있긴 했다.
가령, 성경은 음행만 죄로 규정하고 금지할 뿐, 정상적으로 결혼한 부부의 사생활은 뭘 하든 서로 좋으면 하나님도 절대적으로 존중하고 귀히 여겨 주신다고 약속했다.

하지만 옛날엔.. 이거 뭐 섹스 자체를 추잡하고 지저분한 짓으로 규정해서 오로지 불가피한 욕구 해소와 자녀 생산 수단-_-으로만 치부했다. 전날 부부관계를 한 사람은 이튿날 예배 참석도 금지당했다. (무슨 레위기의 부정한 사람 규정처럼) 그러면서 피임까지도 금기시됐다.;.
이 정도면 인간에게 생식기와 성욕 같은 걸 만드신 하나님의 성품이 추잡하고 더러운 거나 다름없어 보인다.

그 뿐만이 아니다. 대외적으로만 거룩한 범생이 같은 말을 늘어놓으면서 사석에서는 지위를 이용해서 여성에게 더러운 성추행을 일삼는 놈들도 동서고금 어디에나 있어 왔다. 그래서 과거에 마 광수 교수조차 저런 부류의 인간들을 극혐하면서 욕을 퍼부었다.
(마 교수야 내세를 부정하는 무신론 불신자였고, 우리 솔직해지자는 명목으로 소설을 꽤 야하게 썼었다.;;; 하지만 그분은 위선을 철저히 배격하는 소신이었으며, 오프라인에서 넘지 말아야 할 선은 절대 안 넘고 학생들을 깍듯이 존중해 주기도 했다.)

과거에 대한 반대급부로 사람들이 하는 일은 대체로 이쪽 아니면 저쪽의 잘못된 극단으로 치닫는 편이다.
체벌 자체는 성경적인데 그걸 빌미로 미친 아동학대를 저지른다거나, 아니면 아예 정상적인 체벌까지 싹 금지하고 애새끼들을 전대미문의 싸가지없는 세대로 키운다.

흉악범 살인범만 사형에 처하랬는데 그걸 빌미로 무고한 사람도 누명 씌워 사법살인으로 잡는다거나, 아니면 아예 사형 집행을 안 하면서 직무를 유기하고 가해자를 평생 공짜로 재우고 먹여 준다. 이게 과거와 현재의 차이이며, 피해자의 인권이 억울하게 짓밟히는 건 하나도 다를 바 없다.
성에 대해서도 과거에는 너무 억압적이었다가 지금은 세상 망조 들 정도로 너무 풀리고 있다고 보면 된다.

이런 식으로 하나님 말씀에 대한 불신과 오해, 악한 추측은 아주 오래 전부터 존재했다. 최초의 여성 이브는 선악과를 먹지 말라는 명령에 반발하여 원래 말씀이 무엇이었는지 정확하게 기억하지도 않고서 “만지지도 말라”를 덧붙였다. 학교에서의 두발 단속에 반발해서 아예 삭발하는 것과 비슷한 심보라고 보면 된다. 그러면서 그녀는 뱀의 유혹에 곧장 넘어가 버렸다.

달란트/므나 비유에서 게으르고 악한 종도 주인에 대해 사람을 억압하고 갑질하고 착취하는 악덕업자 정도로 생각했는데, 그게 하나님에 대해서 비슷하게 오해하고 악한 편견을 가진 삐뚤어진 심보를 묘사했다고 볼 수 있다. 하나님에 대해서 자기에게 해 준 건 없으면서 자기 안 믿으면 몽땅 지옥에나 보내겠다고 협박하는 저열한 신 정도로 생각하지, 죄와 심판에 대한 경고라든가 십자가에서의 은혜와 사랑이 눈에 들어올 리가 없다.

그런 사고방식의 연장선으로.. 세상에는 예수 믿고 교회 다니기 시작하면 지금 즐기고 있는 것들을 못 하게 된다는 피해의식 비슷한 인식이 좀 있다. 그러니 “좀 있다가, 나중에, 죽기 직전에 예수 믿을게” 이런 반응이 나온다.
아니, 그 정도 반응이면 차라리 감지덕지다. 요즘 매체에서는 천국은 아주 따분하고 고리타분하고 재미없는 곳이고 지옥이 화끈하고 재미있는 곳처럼 묘사된다.

“유능한 변호사들은 몽땅 지옥에 가 있을 것이기 때문에 천국과 지옥의 거주자 간에 소송이 붙으면 지옥이 승소할 것이다”야 피식 웃고 말 개드립이지만.. 심지어 “천국이 저런 꼴도 보기 싫은 꼰대 위선자들이나 우글거리는 곳이라면 난 그냥 지옥 가고 말겠다”처럼 흘러가는 지경이다.

이건 영적으로 굉장히 심각한 문제이다. 이런 시국에 예수 믿는다는 사람들이 세상에 복음을 어떻게 지혜롭게 전해야 할지를 다시 생각해 봐야 한다.
옛날에는 불신자라도 “하늘이 두렵지 않느냐” 정도의 관념이라도 있는 편이었다. 하지만 지금은 그렇지 않다는 것이다.

그럼에도 불구하고 모든 좋은 것, 즐거운 것들은 하나님께 속해 있다. 성생활이든 음악 스타일이든, 인간관계든... 이것이 변함없는 사실이다. 성경에서 금지하는 것들은 우리에게 인생의 낙을 뺏어가려는 악의적인 의도가 아니라 진짜로 우리를 ‘위해서’ 금지되어 있는 것들이다. (혼전순결, 육신적인 정욕에 대한 각종 절제 등)

better late than never.. 아예 지옥을 가 버리는 것보다는 죽기 직전에라도 간신히 믿고 구원받는 것이 낫다. 하지만 그건 젊고 팔팔하고 능력 좋을 때부터 진작부터 구원받고 주님을 섬기고 그분과 교제하며 산 것에 비해서는 명백하게 “손해”이다.
하나님이 “그럼 나 죽기 직전에만 믿으면 되겠네” 정도의 유치한 잔머리 계산 따위에 농락당할 지능일 리는 만무하다.

많은 사람들이, 심지어 신자조차도 자기도 솔로몬 같은 부귀영화도 좀 누리고 수백 명의 미녀들과 원나잇 스탠드(!!)도 왕창 해 보고.. 그러면서 구원도 덤으로 받았으면 좋겠다고.. 꽤 편하게 생각한다. 상금과 훈장 둘 중 하나만 받을 수 있는 상황에서도 “상금에서 훈장의 제조원가만 제외한 나머지 상금과 훈장을 같이 받을 수는 없을까요?” 같은 잔머리를 굴린다. 훈장의 진짜 가치가 무엇인지를 모르니 그런 식으로 생각하는 것이다.

물론 신앙 생활이 세상적인 부귀영화와 무조건 정반대 상극인 것은 아니다. 하나님께서 어떤 사람에게는 그런 물질적인 복과 세상적인 성공을 허락해 주실 수도 있다. 하지만 그게 그 사람에게 언제나 마냥 좋은 일인 것만은 아니다!

또한 성경은 요한복음에서 “보지 않고 믿은 자들은 더 복되다”라고 말한다. 우리는 굳이 전도서의 저자처럼 평생을 온갖 사치 향락과 오덕질과 연구 실험 하면서 진 다 빼고 말년에 가서야 결국 “모든 게 헛되고 헛되도다”라고 허무하게 고백하지 않아도 된다.
젊은 나이에 미리 그걸 말씀을 통해 간접 경험으로 체득한 뒤, 동일한 시행착오를 또 겪지 않는 것이야말로 더 복되다는 생각이 들지는 않는가?

예수 믿어서 좋은 것 중 하나는.. 그렇게 진짜 수준 높고 영원한 행복, 평안, 낙, 멋, 재미 등이 무엇인지 알게 된다는 것이고 당장 보이는 것을 넘어서 영원을 보는 안목이 생긴다는 것이다. 그 관점에서 지금 세상에서 학교나 직장에서의 본분도 아주 고차원적으로 행할 수 있다.

일찍 예수 믿고 성경을 알게 되는 것은 여러분의 인생에 손해가 절대로 아니다. 좋은 것이 모두 거기에 있다. 아니, “좋다, 즐겁다, 선하다” 등의 정의 자체가 바뀔 것이다. 찬송가 가사 “주님께 귀한 것 드려 젊을 때 힘 다하라”는 빈말이 아니다. 그렇게 해 볼 가치가 있으니까 다 생각이 있어서 나온 말이다.

2. 판단 문제

성경에는 다음과 같이 "우리가 남이가" 양비론 퉁치기(?)를 암시하는 듯한 구절이 있다.

  • 판단받지 않으려거든 판단하지 말라 (마 7:1-2)
  • 죄 없는 자부터 먼저 돌로 치라 (요 8:7)
  • 교회 내부 교인간의 분쟁을 세상 법정으로 가져가서 해결하려 들지 마라 (고전 6:6-7)

이건 참 훈훈하게 들리지만, 한편으로 지 죄를 슬쩍 은폐하고 넘어가려는 의도로 악용에 가깝게 오· 남용되는 빈도도 굉장히 높은 구절들이다.
교리 쪽에서 제일 흔한 오류가 교회와 유대인 혼동, 하늘의 왕국과 하나님의 왕국 혼동, 예정과 자유 의지 혼동 같은 것이라면.. 행실 쪽에서 제일 흔한 오류는 바로 저런 유형이지 싶다.

세상에서는 아무 사람이나 덥석 믿을 수 없기 때문에 양심과 자율과 사랑(?) 대신, 시스템과 법과 매뉴얼대로 이성적으로 냉정하게 돌아가는 사회를 만들려 애쓴다.
신약 교회는 그런 세상 조직보다야 더 유도리 있게 돌아가야 할 필요가 있다. 하지만 그렇다고 해서 니 것 내 것 구분도 없는 무법천지가 되라는 말은 결코 아니다.

그리고 헌신이라는 명분으로, 하늘나라에서 받는 보상을 목표로 신앙 열정페이? 좋다. 그 자체는 종교적으로 있을 수 있다. 그러나 이건 굉장히 신중하게 조심해서 적용되어야 하는 관행이다.
가까운 가족이라 해도, 교인이라 해도, 지켜야 할 도리가 있고 공과 사를 구분해서 선을 그어야 하는 영역 구분이란 게 있기 때문이다. 어떤 인간 관계에서건 남의 시간과 노력을 존중해 주고, 호의를 권리로 여기지 말아야 한다.

안 그러면 가족 같은 교회가 '가~~족같은 교회'로 전락하는 건 순식간이 된다. 회사만 가족 같은 회사가 있는 게 아니다. 물론, 반대편 극단인 목사/전도사 노조..?? 이딴 것도 병신 미친짓이긴 마찬가지이고 말이다.

하나님께서 구원받은 성도들의 모임은 교회 하나로 충분하지, 기독교 기업, 기독교 국가 같은 걸 만들지 않으신 이유를 생각해 보자.
종교 본연의 기능에만 충실한 제일 원초적인 조직인 교회 하나, 신학교 하나조차 오래 유지를 못 하고 교리 때문에 찢어지고 사람 때문에 분리되고 파편화되는 게 이 바닥의 생리이다. 하물며 신앙의 이름으로 돈이나 권력까지 다루는 조직은 만들어 봤자 서로 의만 상한다. 일반 불신자 경영자가 운영하는 기업만치도 못 돌아가고 폭파될 것이다.

그 반면, 교회는 사람을 스펙이나 능력으로 평가하거나 짜르지 않는다. 그리고 교회만치 작은 죄의 누룩 하나, 연약한 지체가 시험 들고 실족하는 것에 민감하게 반응하는(반응해야 하는) 조직은 없다. 물론 죄를 책망하는 진리 팩트폭격에 지 혼자 자존심 상하고 삐치고 발끈해서 뛰쳐나가는 것은 별개의 문제인데.. 두 상황(약함 vs 악함)을 잘 분별할 필요가 있다.

그러니 성경은 "판단하지 말라" 바로 다음에 거짓 선지자를 조심하라는 경고가 이어진다. 누가 거짓 선지자인지 아닌지 판단을 해야 된다.
"죄 없는 자부터 먼저 돌로 치라" 다음에 예수님은 여인에게 "가서 앞으로 다시는 죄를 짓지 말고 살아라"라고 당부하는 걸 잊지 않으셨다. 누구든지 성경은 끝까지 꼼꼼히 다 읽어봐야 된다.

끝으로 신자간의 법정 분쟁 문제는..?? 이건 마치 교회와 세상 정부의 관계, 교인과 정치의 관계만큼이나 미묘하고 민감한 구석이 있다. 다만, 어떤 경우에도 일체 세상 법정에 의지하지 말라는 얘기는 아닐 것이다.

3. 박해에 대한 대처

예수 믿는 사람들은 기본적으로 정교분리를 지지하며, 위의 모든 권위를 인정하고 순종한다. 특히 군대에도 가며, 필요하다면 자기 나라를 지키기 위해 싸우다 죽는 것도 불사한다.
그런데 그 나라가 개인의 신앙을 간섭해서 예수 못 믿게 한다거나 교회를 핍박한다면, 혹은 교묘하게 핍박하는 듯이 보인다면 어떡해야 할까?

기독교 신앙은 "가능하면 이 쓴 잔을 내게서 떠나게 하옵소서. 하지만 궁극적으로는 내 뜻이 아니라 아버지 뜻대로 하옵소서"이다.
그리고 "죽음을 불사하고, 죽을 각오까지 하고 싸우라. 죽으면 죽으리이다"가 올바른 자세이다. 그러다가 진짜로 순교할 수도 있지만, 섭리가 있어서 살아서 돌아올 수도 있다.

무슨 옛날 일본군 같은 무조건 나가 죽어라 카미카제 특공대가 아니다.
그리고 "주여, 내게 고난의 십자가를 얼마든지 내려 주시옵소서" 이건 교만 만용 객기이며 '지나친 의로움'이다. 저건 예수님보다 더 의로운 짓거리이다. 저렇게 깝치는 애들은 진짜 고난 시험이 실전으로 닥쳤을 때는 베드로보다 더 큰 실수를 하고, 행 19에 나오는 7형제들보다 더 큰 망신을 당할 것이다.

도피, 망명 등 최대한 안 부딪히기 위해 노력하다가 도저히 안 되면 소극적으로 항거하고, 핍박이 가해지면 받고, 그래도 위의 권위자와 통치자를 위해서 기도하고 "주여 저 (새끼)들을 용서하소서. 저들은 자기가 무슨 짓을 하는지 알지 못하나이다"라고 예수님처럼, 스데반처럼 숭고하게 간구하는 게 FM이고 가장 이상적인 대처이다.

저걸 인간의 육신만으로 위선 가식 연기 없이 실천한다는 건 딱 잘라서 전혀 불가능하다. 그 불가능을 가능하게 하는 게 십자가의 권능이고 기독교의 능력이다.

그런데... 저게 예수쟁이들로 하여금 뻔히 보이는 시국을 분간할 필요가 없다는 얘기는 아니고, 멀쩡히 챙길 수 있는 정당한 권리까지 바보 병신같이 호구처럼 가만히 있다 뺏기라는 얘기도 아니다. 그건 마치 기도만 죽어라고 하면 공부 안 해도 시험 100점 맞을 수 있다는 소리와 같고, 기도만 죽어라고 하면 병에 걸려도 병원 갈 필요가 없다는 소리와 같다.

그래서 이런 영역에 인간의 자유의지가 가미되어 신앙생활의 좌파와 우파, 또는 매파와 비둘기파 성향이 나뉜다.
북한에서도, 옛날 로마 제국 초대 교회 시절에도, 정들었던 교인들이 하나 둘 잡혀가고 순교하고, 교회 안에 배신자 밀고자가 튀어나오고, 아무리 기도해도 당장 박해가 끝날 기미가 안 보이니..

혈기 넘치는 젊은 청년들 중심으로 “우린 도대체 언제까지 이렇게 살아야 되냐? 우리도 힘을 모아서 보복하러 가야 하고, 하나님을 대적하는 로마 정부나 김정은 정권 따위 갈아엎어야 한다! 우리의 아이들을 생각해서라도(엄마 감성!!) 신앙의 자유를 쟁취해야 한다. 자유는 공짜가 아니다!” 이렇게 주장하는 사람이 나오지 않았을 리가 없었다. (영화 <바울>, 모 지하 교회 출신 탈북자 증언 등 참고) 여러분은 어떻게 생각하시는가?

지금 대한민국이야 북한 같은 기독교 박해는 없다. 하지만.. 이런 식으로 민감하게 생각하다 보니 지금 중공 폐렴 대처를 핑계로 이상하게 교회에다가만 감염원 누명을 과장해서 씌우고 모임에 불공평하게 제약을 가하는 것조차 명백히 불순한 수작이자 박해로 간주하고, "이런 정책까지 마냥 고분고분 따를 수만은 없다. 적극적으로 청원을 넣고 항의하고 대항해야 한다, 힘을 모아서 일어나야 한다" 이렇게 생각하고 주장하는 분들도 있다.

이 주제에 대해서 내가 조심스럽게 내리는 결론은.. 그런 운동은 아직까지는 그냥 개인별로 자기 신념과 재량에 따라 참여하고 활동할 사항인 것 같다.
옛날 LA 폭동에다 비유하자면, 성경에 명시된 권리를 행사해서 총 들고 집 지키고 폭도들에게 발포하는 것도 훌륭한 크리스천 시민의 모습이지만, 한편으로 평소에 워낙 선행을 많이 베풀고 평판이 좋아서 폭동 때 오히려 흑인들이 앞장서서 집을 지켜 줬다는 Mama Kim 아줌마 같은 사람도 예수쟁이들 중에서 더 많이 나왔어야 했다. 두 면모가 모두 필요하고 적절히 발휘돼야 한다.

국가 정책과 교회 활동이 서로 충돌하고 이것이 도저히 피할 수 없는 상황이라면 어떤 형태로든 저항과 투쟁이 뒤따를 것이다. 하지만 그런 최후의 수단이 동원되기에 앞서, 신자들이 잘 행한다면 그 문제를 원천적으로 예방· 회피하거나, 정말 초월적인 상호 해피엔딩으로 해결될 여지가 없지 않은지를 꼭 살펴봐야 할 것이다.
좌우 성향의 균형이란 건 이런 해법을 찾으라고 있는 개념이다. 국가 정체성을 부정하는 빨갱이들은 좌우 균형과 아무 상관없고, 그냥 잡아 죽여야 할 기생충 암세포 버러지일 뿐이다.

Posted by 사무엘

2020/11/06 08:35 2020/11/06 08:35
, ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1816

성경으로 성경 풀이하기

1. 사랑은 허다한 죄를 덮음

"무엇보다도 너희끼리 뜨거운 사랑을 품으라. 사랑은 허다한 죄를 덮으리라." (벧전 4:8)
라는 말씀과 관계가 있는 구절들은 내가 아는 한 다음과 같다.

(1) 사랑의 위력/효과에 대한 말씀의 원조는 잠언이다.
"미움은 다툼들을 일으키되 사랑은 모든 죄를 덮느니라." (잠 10:12)

(2) 저기서 말하는 사랑은 교회 지체간의 brotherly love이다. 이에 대해서는 바울 서신에서 언급돼 있다.
"형제의 사랑으로 서로 친절하게 애정을 가지고 서로 먼저 존중하며.." (롬 12:10)
"형제의 사랑을 지속하고" (히 13:1)

(3) 지체들간에 그렇게 사랑한다면, 특별히 누군가가 오류에 빠져 잘못 행동하는 것을 사랑으로 잘 권면하게 된다.
"형제들아, 너희 중에 어떤 사람이 진리를 떠나 잘못하는데 누가 그를 돌아서게 하면.. 그 죄인을 그의 길의 잘못에서 돌아서게 하는 자가 한 혼을 사망에서 구원하며 허다한 죄를 덮을 것임을 그가 알게 할지니라." (약 5:19-20)

이런 게 "성경을 성경으로 풀이하면서" 진리를 얻어 가는 과정이다~!
물론 머리로 이렇게 아는 것하고, 진짜로 성령의 열매로서 사심· 가식이나 조건 없이 사랑이 실천되어 나오는 것은 또 별개의 일인 것을 알 필요가 있다.

2. 야고보서와 로마서

성경에서 야고보서는 “믿음뿐만 아니라 행위로 의롭게 된다”를 가르치면서 언어 통사와 논리 구조상 로마서와 정면으로 모순되는 책이라고 여겨진다. 두 책의 텍스트를 입력시켜서 컴퓨터로 구문 분석을 했더니 통사론적으로 모순 판정이 나왔다는 카더라 통신이 전해지지만.. 누가 언제 어디서 어떤 방식으로 실험을 했는지, 믿을 만한 결과인지 출처가 불분명하다.

두 책은 똑같이 아브라함을 거론하고 똑같이 창 15:6까지 인용함에도 불구하고 결론은 정반대로 전개된다. 이걸 보면 굳이 기계가 아닌 사람이 보더라도 두 책이 정면으로 충돌하는 것처럼 보이긴 한다.

만일 아브라함이 행위로 의롭게 되었으면 그 일에 대하여 자랑할 것이 그에게 있으려니와 하나님 앞에서는 없느니라.
성경 기록이 무어라 말하느냐? 아브라함이 하나님을 믿으매 그것을 그에게 의로 여기셨느니라, 하느니라. (롬 4:2-3)

우리 조상 아브라함이 자기 아들 이삭을 제단 위에 드릴 때에 행위로 의롭게 되지 아니하였느냐? 네가 보거니와 믿음이 그의 행위와 함께 일하고 행위로 믿음이 완전하게 되지 아니하였느냐?
이에, 아브라함이 하나님을 믿으니 그것을 그에게 의로 인정하셨느니라, 하시는 성경 기록이 성취되었고 그는 하나님의 친구라 불렸느니라. 그런즉 너희가 보거니와 사람이 행위로 의롭게 되고 단지 믿음만으로 되지 아니하느니라. (약 2:21-24)


오죽했으면 믿음 덕후 종교 개혁자였던 마틴 루터는 야고보서가 성경 정경이 아닐 거라고 현실을 부정했으며, 차마 쓰레기라고는 말 못 하고 지푸라기 같은 책이라며 극딜을 가했다. 참고로 야고보서는 신약 성경 중에서는 시기적으로 제일 일찍 먼저 기록되었을 것이라고 여겨진다.

야고보서에서 말하는 행위의 필요성은 “보이지 않는 것을 믿는다는 증거는 보이는 형태로 드러난다. 이로써 그 믿음이라는 게 실체가 있다는 것이 인증된다” 차원에서 하는 말이다. 예전에도 비유를 들었듯이, 자동차가 시동이 걸렸으면 공회전만 하지 말고 변속기를 D로 넣고 앞으로 나아가야(행위의 열매) 존재의 의미가 있다.

N에서 공회전만 하면 그 자동차는 아무 쓸모가 없다.
다만, 그렇다고 해서 그 차의 존재(구원과 믿음)와 작동 자체가 거짓인 건 아니다. 그런 차원인 것이다.

히 5:9에 따르면, 예수님은 전지전능한 하나님의 아들이지만 직접 몸소 고난을 받고 섬김과 순종을 실천함으로써 완전하게 됐다고 한다. 이건 예수님이 성육신 이전에는 신으로서의 능력이나 레벨이 2% 정도 부족했다는 얘기가 아니다. 마치 노아(창 6:9)나 욥(욥 1:1)이 perfect였다고 해서 한 치의 죄가 없는 완전무결한 사람이라는 말은 아니듯이 예수님에 대한 made perfect도 그런 자질을 말하는 게 아니다.

그건 예수님이 행위를 통해서 뭔가 공개적으로 인증, 입증을 받았다는 뜻이다. 예수님조차 본을 보이셨는데 구원받은 성도들 역시 가식 위선적인 선행이 아니라 믿음의 선행을 실천해 보여야 그 믿음의 실체를 대외적으로 인증받고 남에게 영향력을 행세할 수 있다. 이것이 야고보서가 말하는 바이다.

이 외에도 야고보서에서 “욕심이 잉태하면 죄를 낳고 죄가 완료되면 사망”(약 1:15)은 “죄의 삯은 사망”(롬 6:23)과 대조된다. “믿음의 단련이 인내를 이룸”(약 1:3)은 “환난은 인내를, 인내는 체험을, 체험은 소망을”(롬 5:3-4)과도 대응하는 구석이 있다.

3. 노아의 날과 롯의 날

본인은 우주(지구 포함)와 생명의 기원에 관한 한 신의 창조를 믿으며, 연대기에 관해서는 오래된 우주와 젊은 인류를 지지한다고 이 블로그 글을 통해 몇 차례 밝힌 바 있다. 그리고 창세기 1장 1절과 2절 사이의 간극(gap)을 믿는다. 이것이 과학뿐만 아니라 성경적으로도 이치에 맞기 때문이다.

간극 지지자라면 벧후 3:6의 “물의 넘침으로 인한 멸망”이 노아의 홍수가 아닌 더 큰 우주적인 이전 세상의 심판과 멸망이라고 본다. 그러나 반대론자는 이것도 무조건 100% 노아의 홍수라고 여긴다. 도대체 어느 쪽의 말이 맞는 걸까?

본인은 예전에 여러 논리와 비유를 들면서 간극이 성경 교리 차원에서 가능하고 옳으며, 이게 지질학· 천문학 관찰과도 조화를 가장 잘 이룬다고 주장했다. 그런데 벧후 3:6이 노아의 홍수 얘기가 아닌 이유를 다음과 같이 설명한 적은 없었던 것 같다. 그래서 '성경을 성경으로 풀이하기' 컬렉션에다가 항목을 개설하여 이야기를 늘어놓도록 하겠다.

성경적으로 볼 때 노아의 홍수는 소돔· 고모라의 멸망과 호응하고 짝을 이룬다. 전자는 물바다, 후자는 불바다여서 그런 것 같다. 소돔과 고모라도 성경에서 노아의 홍수와 거의 대등한 급으로 굉장히 자주.. 악과 심판과 폐허의 상징으로 두고두고 언급된다. 즉, 인지도가 매우 높다.

그리고 노아의 홍수는 인간을 포함해 코로 호흡하는 육상 동물만 다 죽었지, 다른 어류· 식물· 곤충 따위는 굳이 방주에 타지 않아도 멸종하지 않았다.
소돔과 고모라는 뭐.. 그 지역에 있는 생명체들은 몰살을 면하기 어려웠겠지만, 면적이 노아의 홍수보다는 훨씬 좁았다. 두 심판은 강렬하긴 하지만 규모 면에서 전면적이지 않고 부분적(partial)이라는 공통점도 있다.

이 사실을 염두에 두고 성경 본문을 살펴보자.
베드로후서는 바로 앞 2장의 5~6절에서 하나님이 내리신 심판의 사례로 저 두 사건을 쌍으로 언급하고 있다.
더구나 예수님도 눅 17:26-30에서 노아의 날과 롯의 날을 같이 거론하면서 둘을 쌍으로 엮으셨다. 이 정도면 둘이 매우 비슷한 심상이라는 건 성경적으로 전혀 의심할 필요가 없을 것이다.

그 반면, 벧후 2의 바로 다음 3장은 어떤 문맥인가?
이 홍수와 나란히 대응하는 불 버전은 하늘과 땅을 통째로 불태워 없애 버리는 것이며(7절), 겨우 소돔과 고모라의 유황불 정도하고는 쨉이 안 된다. 계속해서 10~12절을 읽어 보면, 거의 원자력 핵융합/핵분열 급의 전우주적 물질 붕괴가 묘사되어 있다. 단순히 산소에 의한 연소가 아니다.

이런 묘사는 벧후 이외의 다른 책에서는 거의 찾을 수 없다.
저 불 심판이 소돔과 고모라와 차원이 다른 것과 동급으로, 과거의 물 심판 역시 노아의 홍수와 같은 차원이 아니라는 것이 본인의 논리이다. 2장 5절도 노아의 홍수이고 3장 6절도 노아의 홍수라고? 완전히 차원이 다른 문맥에서 또..??
아래의 비례식을 생각하면서 본문을 진지하게 다시 읽어 볼 것을 권하고 싶다.

노아의 홍수 : 소돔과 고모라 유황불 =
???? :
하늘과 땅이 몽땅 불로 멸망, 물질 붕괴

4. 수식 대상과 범위

위의 3번 아이템과 이어지는 내용인데..
성경에는 긴 문장에서 수식의 대상과 범위를 잘 분간하며 읽어야 하는 부분이 좀 있다.

(1) 그것으로 말미암아 그때 있던 세상은 물의 넘침으로 멸망하였으되 지금 있는 하늘들과 땅은 (중략) 심판과 멸망의 날에 불사르기 위해 예비해 두셨느니라. (벧후 3:6-7)

벧후 3장을 처음부터 쭉 읽어보면 종말과 재림을 믿지 않는 비웃는 자들이 나타날 거라는 예측이 나온다.
“그것으로 말미암아”와 연결되어 비웃는 자와 인과관계를 형성하는 다음 사건은 “현 세상은 불로써 멸망할 것”이다. 걔네들 때문에 이전 세상이 물로써 멸망한 게 아니다. 수식어와 피수식어의 거리 차이 때문에 저렇게 읽히기 쉬우니 주의해야 한다. 과거의 물 심판은 미래의 심판하고 그냥 대조 대구를 이루기 위해 언급되었을 뿐이다.

(2) 세상의 창건 이후로 죽임을 당한 [어린양]의 생명책에 이름이 기록되지 않은 자들이 그에게 경배하리라. (계 13:8)

‘세상의 창건 이후로’는 생명책의 이름 등재 시기를 수식한다. 어린양의 도살..;; 시점을 수식하는 게 아니다.
문장의 통사 구조는 중의성을 지니는데 니가 그걸 어떻게 아냐고? 뒤에 계 17:8에서 대놓고 “세상의 창건 이후로 이름이 생명책에 기록되지 않은 자”가 분명하게 다시 등장한다. 안심하시라.

어린양이야 지금으로부터 2000여 년 전에 딱 한 번 죽임을 당했다가 부활했다. 어린양의 도살 시점은 계 5:6에서 “전에 죽임을 당했었던” as it HAD BEEN slain이라고 대과거 완료 시제를 통해 표현돼 있다.
참고로 마 1:6에서 “우리야의 아내였던 여인”, 전처 ex-wife라는 개념도 that HAD BEEN the wife of Urias 과거 완료 시제로 표현됐다는 걸 생각하자. (지금은 우리야가 아닌 다윗의 아내이다 / 지금은 죽지 않았고 살아 있다~ 계 1:18)

5. 달란트 비유와 므나 비유

성경의 복음서에는 달란트 비유와 므나 비유가 있다. 전자는 예수님을 유대인의 왕 관점에서 묘사한 마태복음에 있고, 후자는 예수님을 온전한 인간 관점에서 묘사한 누가복음에 있다. 그렇기 때문에 누가복음은 마태복음에 비해 유대인 민족색이나 왕국복음 같은 얘기가 덜 나오며, 킹 제임스 성경은 비유에 등장하는 화폐 단위를 음역이 아니라 아예 영어 파운드로 로컬라이즈 번역해 버리기도 했다.

달란트 비유에서는 종 세 명이 각각 5, 2, 1달란트씩을 받는다. 그걸 밑천으로 각각 5와 2달란트.. 즉 정확하게 수익률 100%를 달성한 종은 칭찬을 받지만, 1달란트를 받은 종은 그걸로 아무것도 안 하고 돈을 묵힌 죄로 바깥 어둠 속으로 추방당한다. 이 장소는 성경적인 심상으로 볼 때 지옥으로 여겨진다. 즉, 게으르고 악한 종은 아예 구원받지 못하는 사람을 상징한다.

그러나 므나 비유에서는 종 10명이 각각 1므나를 “동일”하게 받는다. 그리고 1므나를 밑천으로 투자해서 10므나, 즉 수익률 1000%를 낸 사람도 있고 5므나(500%)를 번 사람도 있어서 수익률이 차이가 난다. 달란트와 달리 원금 별도는 아니고 원금 포함인 것 같긴 하다만.. (달란트는 5+5, 므나는 1-1+10)

여기서도 1므나로 아무것도 안 한 종은 주인에게서 꾸중을 듣는다. 하지만 받았던 원금을 빼앗기는 것으로 끝이고, 추방까지 당하지는 않는다. 심판이 집행되어 처형 당하는 대상은 따로 있다.
므나 비유는 아무리 봐도 구원을 잃지 않고 보상만을 잃는 구원받은 크리스천을 빗댄 얘기임을 알 수 있다. 다시 말해 저건 그리스도의 심판석 등급이다.

이 정도 차이는 세대적 진리 공부를 좀 한 사람이라면 누구나 분간할 것이다.
그런데 본인이 이 성경 본문에서 요즘 추가로 주목하고 있는 아이템은 바로.. 예수님의 칭찬도 두 비유에서 서로 미묘한 차이가 있다는 점이다.

마 25:21은 “네가 적은 것(few - many 少)에도 신실했다”라고 말한다. 하지만 눅 19:17은 “네가 아주 작은 것(very little - big 小)에도 신실했다”라고 말한다. 전자는 일의 양, 금전의 액수, 물건의 개수를 따지고, 후자는 일 또는 물건의 규모를 따진 것이라고 볼 수 있다.

뭐 언뜻 보기에는 구분 없이 섞어 써도 별 차이 없으며, 그게 그 말 같게도 들린다. 하지만 왕국 복음에서는 “적은 일에 신실함”이 나오고 은혜의 복음에는 “작은 것에 신실함”이 언급되는 것에도 뭔가 미묘한 영적 통찰이 담겨 있을 것 같다. 최소한 하늘의 왕국과 하나님의 왕국의 차이 같은 차이는 있지 않을까? 이 역시 성경을 성경으로 풀어서 답을 구할 수 있을 것이다.

Posted by 사무엘

2020/11/03 08:34 2020/11/03 08:34
,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1815

항공 사건 사고와 관련하여 꼭 볼 만한 명작 영화로는
Flight 93 (2006), 그리고 Sully (2016)가 있다. 실제 사건으로나 영화의 작품성으로나 모두 탁월하다.

1.
전자는 2001년 9 11 테러 당시에 테러리스트에게 피랍된 유나이티드 항공 93편(미국 국내선, 보잉 757-222) 여객기 내부에서 벌어졌던 일을 다룬다. 9 11 테러 이전까지만 해도 미국의 항공 보안 규정은 지금보다 훨씬 더 널널했다.

사건은 빨간 머리띠를 두른 테러리스트들이 갑자기 승무원들을 제압하고 조종실로 난입하는 것으로 시작된다. 나중에는 승객들이 힘을 합쳐 기내식 카트로 박치기를 해서 조종실 문을 부수기는 하지만.. 이미 조종간을 잡고 있던 테러리스트가 이판사판 동귀어진 차원에서 비행기를 평지로 추락시켜 버렸다.
추락 충격이 얼마나 컸으면 영화에서 묘사되는 것처럼 커다란 버섯구름이 피어오르면서 기체는 형체도 없이 박살났다. 그리고 전원 사망..

사용자 삽입 이미지

하지만 승객들의 영웅적이고 숭고한 저항 덕분에 이 사건은 저 비행기만 혼자 추락하는 걸로 끝날 수 있었다. 테러리스트들을 그대로 놔 뒀으면 쟤는 워싱턴 DC에 있는 백악관이나 국회의사당에다 꼬라박았을 가능성이 매우 높았다. 그때 미처 무장을 못 하고 긴급 출격했던 미군 F-16 전투기 2기는 얘와 몸으로 충돌할 각오까지 했었다고 한다.
이 기체가 추락한 지점에는 현재 Tower of Voices라는 이름의 위령비가 세워져 있다.

사용자 삽입 이미지

2.
한편, 후자는 2009년 1월, 허드슨 강의 기적이라 불리는 US 에어웨이즈 1549편(미국 국내선, 에어버스 A320-214)의 불시착 사고를 다룬다. ‘설리’는 당시 여객기 기장의 이름이다.

사용자 삽입 이미지

이 기체는 이륙한 지 얼마 못 가 새떼들과 제대로 충돌한 덕분에 좌우 엔진이 몽땅 망가지고 시동이 꺼져 버렸다. 새가 기체와 단순히 부딪힌 정도를 넘어 엔진으로 빨려들어갔기 때문이다. 공기만 들어와야 하는 엔진 내부에 크고 무거운 생명체 이물질이 들어갔으니 뭐..
기체는 순식간에 글라이더로 전락하고 서서히 추락하기 시작했다.

이 상황에서 기장이 얼마나 적절한 상황 판단으로 강에 잘 불시작해서 승객들을 전원 구출했는지는.. 직접 보면 알 수 있다. 공포의 GPWS 경보음을 “웽웽~ pull up!” 단계까지 듣고도 멀쩡히 살아남은 여객기 기장은 세계적으로도 드물지 싶다.

영화에서는 NTSB 조사관들이 저런 영웅 기장을 과실 있는 가해자인 것처럼 막 의심하고, 그때 비행기를 꼭 이렇게 처박았어야 했냐는 식으로.. 검사가 피의자 심문하듯이 거칠게 몰아세우는 것으로 묘사된다. 하지만 실제 사고 조사 때는 그렇지 않았다. 도저히 불가피한 상황이었다는 것이 명백했기 때문에 딱히 빡세게 조사할 것도 없었다. 오히려 기장 당사자가 영화에서 상대측 조사관들이 너무 악의적으로 묘사됐다고 이의를 제기했을 정도였다.

3.
이런 식으로 우리나라도 1971년 1월, 대한항공 포커 27기 납북 미수 사건 정도면 충분히 영화로 만들 만한 스토리였다고 개인적으로 생각한다.
납북 미수라고는 하지만 이건 진짜 북괴 간첩은 아니고 그냥 중2병 또라이의 단독 범행이었다. (대공 용의점 없음) 그렇지만 피의자가 진짜 폭발물을 소지하고 있었고 여객기를 진짜로 이북으로 보낼 뻔했다.

사용자 삽입 이미지

그 와중에 승무원들은 매우 적절하게 잘 대처했다. 기내에 탑승 중이었던 보안관이 놀라운 실력으로 테러리스트를 사살했으며, 결정적으로 놈이 기폭시킨 폭탄은 전 명세 부기장이 자기 몸으로 덮어서 폭발을 상쇄했다. 그리고 그분은 순직.. 기체는 다행히 바닷가에 잘 불시착했다.

사용자 삽입 이미지

이건 강 재구 소령의 비행기 버전이나 마찬가지였다. 그 시절에 강 소령 전기 영화(1966)도 나오고, 공군의 활약을 다룬 빨간 마후라(1964)도 나왔는데.. 저 일화가 잊혀져 가고 있는 건 아쉬운 일이다.
또한, 보안관이야 1969년 말 YS-11기 납북 사건의 교훈 때문에 도입된 것이지만 그 당시에 소지품 보안 검색은 저런 사제 폭탄의 반입을 허용했을 정도로 여전히 허술했던가 보다.

Posted by 사무엘

2020/10/31 19:34 2020/10/31 19:34
,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1814

철도 사진 분석 퀴즈 - 3

1.
요즘 유튜브에는 혼자 차박 캠핑을 즐기는 여행 유튜버들의 동영상이 유난히 많이 눈에 띈다. 특히 엄지, 밍동, 리랑 등 여자사람도 많다는 게 흥미로웠다. 그렇게 유튜브의 AI가 추천해 주는 동영상을 몇 편 봤는데.. 한번은 이 풍경이 내 눈에 들어왔다. (☞ 동영상 전체 보기)

사용자 삽입 이미지

여기서 문제: 저 캠핑 장소는 어디일까?

정답과 해설

2.
이번 아이템은 배경 설명이 없고 간단하다.

사용자 삽입 이미지

문제: 위의 사진은 어느 역의 내부 모습일까?

정답과 해설

3.
다음으로, 아래 화면은 올여름에 SBS에서 방영했던 드라마 <편의점 샛별이>에서.. 주인공의 패싸움 장면 전에 잠시 흘러나온 주변 배경 모습이다.

사용자 삽입 이미지
문제: 저기는 어딜까?

정답과 해설

Posted by 사무엘

2020/10/29 08:35 2020/10/29 08:35
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1813

인쇄 기능 -- 下

지난번 상편에서는 Windows에서 인쇄 기능을 코딩으로 구현하는 절차와 인쇄 관련 기본 개념과 동작들을 살펴보았다. 이번 하편에서는 상편에서 분량상 모두 다루지 못한 인쇄 관련 추가 정보들을 한데 늘어놓도록 하겠다.

1. 인쇄 관련 공용 대화상자들

우리가 Windows에서 가장 자주 접하는 공용 대화상자는 아마 파일 열기/저장 대화상자일 것이다. 이것 말고도 글꼴 선택 내지 색깔 선택 대화상자가 있으며, 인쇄 대화상자도 그 중 하나이다.

사용자 삽입 이미지

인쇄를 지원하는 대부분의 프로그램에서 Ctrl+P를 눌러서 쉽게 보는 인쇄 대화상자라는 건 위와 같이 생겼다. 기본적으로 ‘일반’이라는 탭 하나밖에 없지만, 추후 확장과 사용자의 customize 가능성을 염두에 두고 프로퍼티 시트 형태를 하고 있다. 20년 전, Windows 2000 시절부터 저런 형태가 도입되었다.

사용자 삽입 이미지

하지만 Windows 9x 내지 더 옛날 16비트 시절에는 인쇄 대화상자가 전통적으로 위와 같은 모양이었다. 외형상 가장 큰 차이는 프로퍼티 시트가 아닌 일반 대화상자 형태이고, 프린터 목록이 리스트 컨트롤이 아니라 콤보 상자라는 점이다. 지금도 좀 옛날 프로그램에서는 요런 모양의 대화상자를 여전히 볼 수 있다.

인쇄 대화상자로 할 수 있는 일은 크게 (1) 인쇄를 내릴 프린터를 선택하고, (2) 각 프린터별로 용지의 종류와 방향, 여러 부 인쇄 방식 등을 지정하고, (3) 인쇄할 페이지 영역을 지정하고, (4) 최종적으로 인쇄 명령을 내리는 것이다.
하는 일이 생각보다 많기 때문에 옛날에는 인쇄 대화상자를 약간 간소화시켜서 (2)만 지정할 수 있는 “프린터 설정” 대화상자라는 게 따로 있기도 했다. 아래처럼 말이다.

사용자 삽입 이미지

Windows 말고 아래아한글만 해도 먼 옛날 도스 시절에는 Alt+P는 인쇄 대화상자이지만 Ctrl+P는 프린터 설정이었다는 걸 생각해 보자.
하지만 Windows 2000 스타일의 최신 인쇄 대화상자에서는 인쇄와 프린터 설정이 한데 통합되었다. 어떻게..?? 기존의 '프린터 설정'은 자신의 상위 호환인(superset) 인쇄 대화상자를 '적용'만 누른 뒤 '취소'로 닫는 것으로 퉁친 것이다. 이 때문에 인쇄 대화상자는 딱히 modeless가 아닌 modal 형태--자신이 떠 있는 동안 부모 윈도우로 포커스를 옮길 수 없음--임에도 불구하고 '적용' 버튼이 따로 있는 것이다.

MFC에서는 기본 구현돼 있는 인쇄 기능만 사용하는 경우, 오늘날의 2019 최신 버전까지도 의외로 옛날 스타일의 인쇄 대화상자가 계속해서 나타난다. CPrintDialog는 PRINTDLG 구조체 기반이며, 최신 스타일 대화상자를 지원하려면 PRINTDLGEX 기반인 CPrintDialogEx를 사용해야 한다. 최신 스타일이 도입되면서 내부 동작이 많이 바뀌고 바이너리 호환성이 깨졌기 때문에 Ex 클래스는 오리지널 클래스의 파생형이 아니며, 서로 호환성이 없다.

MFC 없이 Windows API만 사용한다면 재래식 PRINTDLG 구조체만 사용하더라도 최신 스타일 대화상자가 나오게 하는 것 자체는 가능하다. 대화상자 템플릿을 customize하는 것 없이 기본 멤버만 사용한다면 말이다.

그러나 구형 구조체와 구형 API만 사용해서 나타난 최신 대화상자에는 ‘적용’ 버튼이 나오지 않는다. 구형 API에는 함수 리턴값 차원에서 그런 응답 자체가 존재하지 않았기 때문이다.
아울러, 인쇄할 영역을 단순히 x~y쪽이 아니라 x1~y1, x2~y2 이런 식으로 여러 개 지정하는 것도 구형 API로는 불가능하다. 해당 구조체 멤버가 존재하지 않기 때문이다. 이런 식의 제약이 있다.

다음은 관련 여담이다.

(1) PrintDlg 내지 PrintDlgEx의 실행이 성공하면 프린터 DC뿐만 아니라 DEVMODE 내지 DEVNAMES 구조체 내용을 담고 있는 global 동적 메모리 핸들도 돌아온다. 현재 선택된 프린터에 대해서 지정한 용지 등의 설정들이 여기에 저장되기 때문에 응용 프로그램이 이 핸들을 잘 관리하고 있어야 한다. 그래서 다음에 인쇄 기능을 호출할 때 요걸 넘겨줘야 기존 인쇄 설정이 보존된다.

(2) 인쇄 대화상자 말고 용지 설정 대화상자라는 것도 있지만 이건 잘 쓰이지 않는다. 용지 종류와 방향, 상하좌우 여백 정도는 공통이겠지만 그 뒤로 인쇄 내용을 배치하는 방식들은 응용 프로그램들마다 같은 구석이 별로 없기 때문이다. 당장 워드패드, 메모장, 그림판만 해도 용지 설정 대화상자의 모양은 전부 제각각이다.

(3) 운영체제에 설치된 글꼴들을 조회하는 것처럼, 현재 설치돼 있는 프린터들을 조회하는 API도 있다. 인쇄 대화상자를 꺼내지 않고 내 대화상자의 한구석에다가 프린터 목록 같은 걸 마련하고 싶다면 이런 API를 쓰면 된다. 하지만 현실에서 사용할 일은 거의 없을 것이다.

(4) “인쇄 중” 대화상자라든가 “인쇄 미리보기(화면 인쇄)” 같은 건 공용 대화상자 버전이 존재하지 않으며, MFC의 경우 자체 구현돼 있다. 오늘날은 인쇄 진행 상황 같은 건 위대하고 전능하신 task dialog로 너무나 깔끔하게 구현할 수 있을 것이다.
그리고 인쇄 미리보기는 여느 대화상자와 달리 꽤 큰 공간이 필요한 관계로, 전통적인 modal 대화상자보다는 프로그램 주 화면에다가 곧장 미리보기를 표시하는 식으로 디자인이 바뀌는 추세이다. 요즘 MS Office 프로그램들이 대표적인 예이다.

2. 플로터

먼 옛날 한 1980~90년대쯤에 컴퓨터 개론 교양 서적에서는 컴퓨터의 출력 장치로 모니터, 프린터와 더불어 플로터라는 물건도 소개되어 있었다. 플로터는 로봇 팔 같은 게 달려서 종이에다가 도면을 말 그대로 '그려 주는' 장치이다.
덕분에 얘는 직선이나 곡선 하나는 무한한 해상도로 원본 그대로 정확하게 그릴 수 있다. 잉크를 적절히 배합해서 컬러 표현도 가능하다.

하지만 장점은 그걸로 끝.. 인쇄 속도가 도트 프린터 이상으로 끔찍하게 느리며(비록 도트 프린터처럼 시끄럽지는 않지만), 속이 채워진 도형이나 비트맵 같은 그림을 표현할 수 없다.
실제로 플로터를 가리키는 DC에다가 GetDeviceCaps(hDC, RASTERCAPS)를 호출해 보면 RC_BITBLT가 가능하지 않다는 응답이 올 것이다. 비트맵 전송을 할 수 없고 천상 원과 직선과 곡선 그리기나 하라는 소리이다.

일반 가정집이나 사무실에서 A4 용지에다가 인쇄하는 거라면 그냥 닥치고 일반 프린터만 쓰면 된다. 하지만 플로터는 프린터가 범접할 수 없는 A1 같은 엄청나게 큰 종이에다가 도면을 그릴 수 있으며, 펜 대신 커터 같은 걸 꽂아서 선 궤적대로(가령 글자의 윤곽선) 종이를 오려낸다거나 하는 용도로도 활용 가능하다는 것에 존재 의의가 있다. 즉, 산업용으로 마르지 않는 수요가 있다.

하긴, Windows에도 트루타입도 비트맵도 아니고 Modern, Roman, Script처럼 내부가 채워지지 않은 선으로만 구성된 '벡터 폰트'가 있었다. 실용적인 쓸모가 전혀에 가깝게 없는 완전 잉여인지라, 요즘 어지간한 프로그램의 글꼴 목록에서는 조회조차 되지 않을 것이다. 이런 게 바로 플로터용 글꼴이다. 물론 프린터에서도 쓸 수 있지만..

사용자 삽입 이미지

옛날에 도스용 터보 C의 BGI에도 비트맵 말고 벡터 글꼴 컬렉션이 있었다. 큰 크기에서는 내부가 채워지지 않고 선만 그어졌으며.. 힌팅이 없어서 작은 크기에서는 영 보기 좋지 않았으니 반쪽짜리인 건 동일했다. 비트맵 같은 계단 현상만 없을 뿐 다른 방면으로 단점투성이였다.

사용자 삽입 이미지
OpenCV 같은 그래픽 라이브러리도 전문적인 폰트 엔진 없이 자체적으로 영문· 숫자를 뿌리는 기능은 제공되는 글꼴이 딱 저런 퀄리티이다.

3. 프린터 드라이버의 가상화

컴퓨터라는 기계는 개나 소나 다 “물리적으로는 없지만 그래도 일단 있다고 치자”라고 넘기는 가상화가 통용되는 동네이다. 메모리는 진작부터 가상화하고 지내고 컴퓨터 자체도 가상 머신, 그리고 iso 같은 광학 디스크는 뭐.. 이제 운영체제(드라이브 마운트)와 압축 유틸조차(생성) 정식으로 지원하는 세상이 됐다.

그러니 프린터도 당연히 가상화의 대상이다. 당장 내 자리에 프린터가 존재하지는 않지만 어떻게든 인쇄를 하는 방법은 크게 두 가지인데, 하나는 그냥 pdf나 xps 같은 파일로 인쇄하는 것이고 다른 하나는 원격 프린터에 네트워크로 연결해서 인쇄하는 것이다. 한때는 컴퓨터조차 한데 공유하는 자원이고 각 사용자는 단말기로 접속만 하던 시절이 있었지만 지금은 프린터 정도나 사무실 같은 데서 여러 컴퓨터들이 한데 공유한다는 점이 흥미롭다.

옛날에는 PC에 Windows 운영체제만 달랑 설치하고 나면 프린터가 잡힌 게 없었다. 프린터는 네트워크나 비디오/오디오 장치만치 필수는 아니니까..
기본 프린터가 없는 컴퓨터에서는 어지간한 프로그램에서 인쇄 미리보기 기능조차 동작하지 않았다. 프린터 공급 용지의 크기를 알 수 없기 때문이다. 하지만 Vista부터는 xps 문서 생성기라는 드라이버가 기본 연결되어 저런 광경을 볼 일은 없어졌다.

pdf/xps가 대중화되기 이전에도 "파일로 인쇄"라는 개념 자체는 마치 "램 드라이브"와 비슷한 위상으로 존재했으며, 지금도 인쇄 대화상자의 옵션으로 존재한다. 인쇄할 내용이 저장된 컴퓨터와 프린터가 연결된 컴퓨터가 서로 일치하지 않을 때 파일로 인쇄하는 기능이 꼭 필요하지 않겠는가?

하지만 지난번 글에서도 잠시 언급했듯이 이런 파일 인쇄 결과는 특정 프린터 기종에 종속적이기 때문에 범용성이 떨어진다. 본인도 저걸 활용한 적은 거의 없었던 것 같다. 그 대신 오늘날은 위지윅만 보장되고 물리적인 프린터의 구조와는 철저하게 독립적인 전자 문서 파일 포맷이 활발히 쓰이고 있다.

우리나라는 인터넷으로 은행 거래나 공문서 발급 같은 걸 받을 때 보안 ActiveX들을 잔뜩 설치해야 해서 원성이 자자하다. 그래서 이런 사이트 접속 전용으로 ActiveX 설치 총알받이 가상 머신을 만들려고 해도 안 되는 경우가 많다. 반드시 본머신(?)만 쓰라고 강요하면서 가상 머신에서는 설치되기를 거부하는 매우 악랄한 ActiveX도 있기 때문이다.

그것처럼.. 증명서 같은 것을 인쇄하는 전용 프로그램의 경우, 가상 프린터인 건 또 어떻게 감지하는지 pdf 같은 파일 생성은 거부하는 경우가 대부분이다.
가상 CD를 감지하는 프로그램은 못 봤는데 프린터와 PC는 어째 감지하는지? 신기한 노릇이다. 하드카피 종이 인쇄는 뭐 변조 못 할 줄 아나..;; 어차피 원본대조필 워터마크가 필요한 건 똑같을 텐데.

한편, 가상 프린터 드라이버라는 게 파일 아니면 네트워크만 있는 건 아니다. 예전에는 FinePrint라고 인쇄되는 데이터를 인위로 보정해서 1페이지에 여러 페이지 내용을 축소해서 인쇄한다거나, 잉크의 농도를 인위로 줄이는.. 뭐랄까 메타 프린터 드라이버 유틸이 있었다. 최종 목적지는 물리적인 프린터이지만 그 사이에 중재를 한다는 것이다.
하지만 요즘은 축소 인쇄라든가 잉크 절약 모드는 프린터 드라이버 차원에서 기본 제공되는 옵션이 돼서 그런 메타 드라이버의 필요성이 많이 줄어든 게 사실이다.

또한, 레이저 프린터는 기술 배경이 복사기와 비슷하다 보니, 같은 페이지를 여러 부 인쇄하는 것을 소프트웨어가 아니라 프린터에게 맡기는 게 매우 능률적이다.
양면 인쇄를 위해 페이지별 인쇄 순서를 교묘하게 바꾸는 것도 해당 워드 프로세서/전자출판 프로그램, 심지어 메타 드라이버가 담당할 법도 하지만.. 요즘은 프린터 드라이버 차원의 옵션으로 자체 제공하기도 한다. 물론 파일로 인쇄할 때는 이런 것들은 전혀 고려할 필요가 없을 것이다.

4. 창 내용을 인쇄(?)하는 API

끝으로, 이것만 마지막으로 언급하고 글을 맺도록 하겠다.
Windows에서 화면에 표시돼 보이는 각각의 창(윈도우!)들은 WM_PAINT라는 특수한 메시지가 왔을 때 invalid region과 BeginPaint - EndPaint 사이클에 맞춰 자기 내용을 그리는 일에 특화돼 있다. 이는 창 내용을 다시 그리라는 요청이 여러 번 반복해서 오더라도 그리는 건 한 번만 행해지고, 꼭 다시 그려야 하는 부분만 효율적으로 그리기 위한 조치이다.

그런데 가끔은 윈도우도 저런 사이클에 구애받지 않고, 특정 DC가 하나 주어졌을 때 묻지도 따지지도 말고 거기에다가 자기 모습 전체를 있는 그대로 싹 다시 그리게 하고 싶을 때가 있다.
이럴 때를 위해 운영체제는 WM_PRINT 및 WM_PRINTCLIENT라는 메시지를 정의하고 있다. 이건 어지간한 Windows 프로그래머라도 접하거나 구현해 본 적이 거의 없는  듣보잡일 것이다.

그런데 Windows XP에서는 저 메시지로도 모자라서 하는 일이 거의 차이가 없어 보이는 PrintWindow라는 함수까지 추가됐다. 이건 뭐 WM_GETTEXT와 GetWindowText의 관계와 비슷한 것일까?
MSDN을 찾아보면..

  • The PrintWindow function copies a visual window into the specified device context (DC), typically a printer DC.
  • The WM_PRINT message is sent to a window to request that it draw itself in the specified device context, most commonly in a printer device context.

이라고 이런 물건들이 주로 인쇄용으로 쓰일 거라고 대놓고 문서화돼 있다. 하지만 현실에서 창 스크린샷 한 장 달랑 프린트 할 일이 얼마나 될까? 실제로는 이것들 역시 화면 출력용으로 쓰인다.

가령, alt+tab을 눌렀을 때 나타나는 각 프로그램 창들의 썸네일 말이다. 물론 Vista 이후부터는 DWM이 창들 화면을 하드웨어빨로 몽땅 저장하는 세상이 되긴 했지만, 그런 것 없이 invalid region과 무관하게 자기 모습 캡처 화면을 떠야 할 때는 저런 함수/메시지가 필요하다.

그리고 메뉴나 콤보 상자 목록이 스르륵 미끄러지며 표시되는 것 말이다. 이런 걸 구현하기 위해서도 WM_PAINT와 별개 계통인 그리기 전담 메시지가 쓰인다.
스르륵 미끄러지는 걸 구현한답시고 매 프레임마다 WM_PAINT가 날아온다거나 하지는 않는다. WM_PRINTCLIENT를 날려서 전체 리스트 모양을 메모리 DC에다가 한번 그려 놓은 뒤, 그걸로 애니메이션은 운영체제가 알아서 구현해 준다.

이런 걸 생각하면 창 핸들과 DC 하나 던져주고 print를 요청하는 메시지와 함수가 왜 필요하고 어떨 때 쓰이는지 약간 수긍이 갈 것이다. 하지만 그게 왜 하필 print라는 단어가 붙었으며 함수 버전과 메시지 버전이 모두 필요한지는 나로서는 아직도 잘 모르겠다.

Posted by 사무엘

2020/10/26 08:37 2020/10/26 08:37
, , , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1812

인쇄 기능 -- 上

1. 모니터와 프린터의 차이

소프트웨어를 개발하면서 프린터 인쇄 기능을 구현할 일은 그리 많지 않을 것이다. 넓게는 pdf를 생성하는 것까지 포함하더라도 말이다. 인쇄 기능이 존재하는 프로그램이라면 게임은 절대 아닐 것이고 아무래도 골수 업무 분야일 것이다.

뭐, Windows API의 경우, GDI API에서 사용되는 DC라는 게 처음부터 극도의 장치 독립과 추상화를 추구하면서 매우 범용적으로 설계되었다. 얼마나 추상적인가 하면, 아직 VGA도 없던 1980년대의 Windows 1.0부터 얘네들의 그래픽 API에는 색깔을 팔레트 인덱스 기반으로 선택하는 게 아예 없었으며 언제나 RGB 기반이었다.
그러니 글자와 그림을 찍는 기본적인 동작은 화면에다 그릴 때나 종이에다 그릴 때나 거의 같은 코드로 구현할 수 있다.

물론 두 장치는 성격이 근본적으로 완전히 다른 물건이다 보니, 코드가 100% 완전히 같을 수는 없다. 프린터는..

  • 3D 가속 렌더링이라든가 동영상 따위와는 전혀 접점이 없다.
  • 출력 속도가 화면보다 훨씬 더 느리다.
  • 색깔은 뭐.. 흑백 프린터도 여전히 현역인 것을 감안해야 한다.
  • 출력이 한없이 연속적인 게 아니며, 페이지의 구분이 존재한다.
  • 프린터가 꺼졌거나 아예 연결되지 않은 것, 용지가 없는 것, 종이가 걸린 것 등으로 인한 실패 확률이 높다.
  • 다만, 해상도는 프린터가 모니터를 아득히 초월할 정도로 높다. 오늘날 HDPI 화면의 해상도가 이제 30~40여 년 전 도트 프린터의 해상도(180dpi)를 따라잡은 것과 비슷한 수준이다.

화면용 3D/애니메이션 위주의 그래픽 API가 DirectX 기반으로 눈부시게 바뀐 동안, 프린터 쪽은 GDI+ 정도 말고는 수십 년 전이나 지금이나 별로 바뀐 게 없다. 글쎄, 인쇄 대화상자의 디자인이 살짝 바뀌었으며 Windows Vista/7 즈음에는 xps라고 pdf 같은 위지윅 전자 문서 생성 API도 추가되긴 했지만, 이게 통상적인 인쇄 절차를 대체할 만한 물건은 아닌 것 같다.

2. Windows에서 통상적인 인쇄 절차

정말 핵심 중의 핵심 기본은 다음과 같다.

  • 화면에다가 그릴 때는 GetDC, BeginPaint 따위로 DC를 얻었다. 하지만 인쇄용 DC를 얻을 때는 PrintDlg 함수의 실행 결과로 얻어진 DC를 쓰는 편이다. CreateDC 직통으로 DC를 생성하는 건, 특정 프린터만을 저격하는 아주 특수한 프로그램을 만드는 상황이 아닌 한 거의 없다.
  • 인쇄를 시작할 때는 저 DC에 대해서 특별히 StartDoc이라는 함수를 호출한다. 이렇게 프린터 DC에서만 사용 가능한 전용 함수들이 몇몇 좀 있다.
  • 그리고 매 페이지에다 인쇄할 때마다 시작과 끝을 StartPage와 EndPage로 해 준다. 인쇄하고자 하는 페이지 수만치 for문을 돌리면 된다. 그 동안 프린터 DC를 상대로 각종 GDI 함수를 호출해서 글자와 그림을 찍도록 한다.
  • 인쇄를 마치려면 EndDoc을 호출하고, 중간에 인쇄가 취소됐다면 AbortDoc을 호출한다. 이거 무슨 저그 스커지가 적기와 자폭하느냐, 아니면 피가 닳아서 죽느냐의 차이와 비슷하다.;;
  • 다 사용한 DC는 ReleaseDC가 아니라 DeleteDC로 해제한다. 화면 DC 말고 메모리 DC와 프린터 DC는 저 함수로 해제해야 한다.

아 참.. 똑같이 DC를 사용하더라도 화면에다 그릴 때와 프린터에다 그릴 때의 매우 큰 차이가 하나 있는데, 바로 좌표계이다.
화면에는 그냥 픽셀 단위를 가리키는 MM_TEXT가 간단하고 직관적이니 널리 쓰이지만 프린터에는 그런 게 없다. 프린터의 해상도와 무관한 밀리미터, 인치, 포인트 등의 실제 길이 단위 기반의 좌표계를 지정해 줘야 한다(SetMapMode 함수).

그리고 MM_TEXT를 제외한 나머지 추상 단위계들은 수학 좌표계처럼 y축의 값이 증가하는 방향이 위로 올라가는 방향이다. 이건 동일 코드로 화면 출력과 프린터 출력을 모두 구현하는 것을 어렵게 하는 주범이다. BMP 이미지가 화면 기준으로 파일이 상하가 뒤집힌 구조인 이유도 이런 좌표계를 염두에 두고 만들어졌기 때문이다.
인쇄 미리보기를 구현한다거나 더 나아가 편집 화면 차원에서 프린터 결과와 화면 결과가 동일한 위지윅 프로그램을 개발한다면, 어차피 화면에서도 저런 범용적인 좌표계를 사용해야 할 것이다.

3. 용지 정보 얻기 (크기와 방향)

그러고 보니 응용 프로그램이 인쇄를 하기 위해서는, 아니 그 전에 인쇄 분량 계산을 하기 위해서는 먼저 인쇄되는 종이의 크기를 알아야 한다. 이 정보는 인쇄를 하는 당사자인 프린터 드라이버가 갖고 있으며, 응용 프로그램은 운영체제 API인 GetDeviceCaps(hPrinterDC, HORZSIZE 또는 VERTSIZE)를 호출해서 얻을 수 있다.
이 함수의 리턴값은 언제나 밀리미터 단위이다. 그러므로 mm 계열이 아닌 좌표계를 사용하고 있다면 적절히 변환해서 글자를 찍으면 된다.

여기서 알 수 있듯, 인쇄 용지의 크기라는 것은 프로그램이 인쇄를 위해 프린터 DC를 생성하기 전까지는 알 수 없다. 하지만 MS Word나 아래아한글처럼 위지윅을 지원하는 워드 프로세서 부류의 프로그램은 자체적으로 가상의 용지를 설정하고 동작한다.
문서에 설정되어 있던 용지와 실제 인쇄 용지가 크기나 종횡비 같은 게 일치하지 않는다면.. 인쇄할 때 배율 같은 걸 적절히 보정해 줘야 가장자리 내용이 짤리지 않는다. 그건 해당 프로그램이 담당해야 하는 영역이다.

한편, 용지의 크기뿐만 아니라 인쇄 방향--세로 portrait 또는 가로 landscape--도 응용 프로그램의 페이지 옵션과 프린터 내부의 옵션이 서로 따로 노는 형태이다. 그럴 만도 한 게.. 기능이 매우 빈약한 메모장으로 인쇄를 하건, 아래아한글로 인쇄를 하건, 가로· 세로 인쇄는 응용 프로그램과 무관하게 언제나 가능한 게 정상이기 때문이다.

그렇기 때문에 인쇄 대화상자에서 각 설치된 프린터별 설정 대화상자를 또 연 뒤, 용지의 방향을 바꿔 줄 수 있다.
인쇄 방향이 프린터 차원에서 landscape(가로)로 설정되었다면 GetDeviceCaps(hPrinterDC, HORZSIZE)의 값이 VERTSIZE의 값보다 더 커진다.

그리고 PrintDlg 함수는 프린터 DC를 생성하면서 PRINTDLG 구조체에다가 DC뿐만 아니라 DEVMODE라는 구조체 내용을 담고 있는 메모리 핸들도 따로 되돌려 주는데, 여기에서 dmOrientation이라는 멤버를 참조하면 용지의 방향을 알 수 있다. (DMORIENT_PORTRAIT 또는 DMORIENT_LANDSCAPE)

물론, 프린터의 용지 방향이 세로이더라도 내 프로그램에서의 용지 방향 설정이 가로로 돼 있으면 이를 감지하여 내가 직접 그림을 90도로 눕히고 돌려서 그리면 된다. 그러면 어차피 가로 방향 인쇄와 동일한 효과를 낼 수 있다.
하지만 그 정도 수고는 워드 프로세서 급에서나 할 일이다. 일반적인 프로그램이라면 그냥 프린터 설정만 따라서 내용을 출력하면 된다.

이렇듯 가로 세로 방향 전환이라는 건 전통적으로 프린터에만 존재하는 개념으로 여겨졌으나, 요즘은 디스플레이 장비에서도 어렵지 않게 찾을 수 있다. 스마트폰은 말할 것도 없고(방향 전환), 모니터도 방향을 전환하는 피벗 기능이 있기 때문이다. 가로로 납작한 모드는 영화를 볼 때 유용할 것이며, 세로로 길쭉한 모드는 문서 편집 내지 코딩을 할 때 유용할 것이다.

4. 인쇄 전담 계층의 분리

요즘 프린터는 한 줄씩 데이터를 받는 족족 타자기처럼 출력물을 토해내는 게 아니라 복사기처럼 최소한 페이지 단위로 동작한다. 운영체제의 인쇄 관리자는 응용 프로그램이 StartDoc ~ EndDoc 사이에서 GDI 함수로 명령을 내린 것들을 마치 메타파일 생성하듯이 모았다가 프린터 드라이버로 보낸다. 그럼 프린터 드라이버는 그걸 프린터가 해석할 수 있는 인쇄 동작으로 바꿔서 기계에다 전송한다.

즉, 응용 프로그램의 입장에서는 인쇄할 데이터를 운영체제의 인쇄 관리자에다가 다 보내 놓기만 하면 명목상 인쇄를 다 마친 것이다. 그 뒤에 실제로 인쇄가 제대로 됐는지, 도중에 종이 부족 같은 문제가 발생하지는 않았는지를 프린터와 통신하며 챙기는 건 인쇄 관리자의 영역이다.
이 인쇄 관리자를 '프린터 스풀러'라고 부르는 편인데, SPOOL은 다른 단어들의 이니셜이다.

문서를 실제로 인쇄하는 것보다야 같은 소프트웨어인 스풀러에게 인쇄 데이터를 파일 형태로 생성하고 전달하는 게 훨씬 더 빨리 되며, 중간에 실패할 일도 거의 없다. 그러니 스풀러가 별도로 분리되어 있으면, 응용 프로그램의 입장에서는 인쇄를 굉장히 빨리 끝마치고 사용자가 프로그램을 사용할 수 있는 상태로 신속하게 복귀할 수 있다.

그 반면, 도스 시절에는 지금처럼 운영체제 차원에서 인쇄 관리자가 제공되는 게 없었다. 그래서 도스용 아래아한글 같은 프로그램은 스풀러 기능을 내부에서 직접 구현해야 했다.
그리고 스풀 옵션을 사용하지 않거나, MB급 단위인 스풀 데이터를 저장할 디스크 공간이 부족하거나, 아예 스풀 기능이 없던 아래아한글 1.x 시절에는...
수십 페이지의 인쇄 명령을 내려놓았다면 다 끝날 때까지 컴퓨터를 사용하지 못하고 기다려야 했다. 스풀러가 아니라 그 느린 프린터로 데이터를 전부 보내야 했기 때문이다. 지금으로서는 도저히 믿을 수 없는 삽질이다.

도스 시절에는 PC 통신 프로그램은 전화를 걸거나 업로드/다운로드를 하는 중에 멀티태스킹을 하는 게 핵심 기술이었다. 그것처럼 워드 프로세서는 인쇄 중의 멀티태스킹이 핵심 기술이었던 셈이다.
1994년에 출시되었던 도스용 아래아한글 2.5는 프린터에다가 인쇄 데이터를 전송하는 방식을 개선해서 인쇄 속도를 크게 향상시켰다고 광고했었는데.. 그 기술 디테일이 무엇이었는지는 개인적으로 지금도 알 길이 없다.

프린터 스풀링용 데이터는 파일의 형태로 인쇄를 한 것이니 '인쇄의 가상화' 결과물이라고 볼 수 있다.
하지만 아무래도 특정 프린터 하드웨어에 지극히 종속적인 형태일 것이므로 pdf나 xps 같은 장치 독립까지 만족하는 전자문서라고 볼 수는 없다.

글쎄, 도스 말고 Windows에서도 3.x + 옛날의 굉장한 구식 도트 프린터의 경우(KS 24핀 180dpi 이러던..-_-), 응용 프로그램에서 인쇄 명령을 내리면 요즘처럼 인쇄 관리자와 해당 프린터 드라이버의 자체 UI가 뜨는 게 아니라 직통으로 바로 인쇄가 시작되기도 했던 것 같다. 거의 30년 가까이 전의 추억이다.

5. 인쇄를 중간에 취소하기

제아무리 인쇄 과정이 가상화돼서 프린터가 아니라 인쇄 관리자에게만 인쇄 데이터를 넘겨주면 된다 하더라도.. 수십· 수백 페이지 분량의 문서를 인쇄하는 건 1초 안으로 호락호락 금방 끝나는 작업이 아니다.
더구나 속도와 별개로 사용자가 인쇄 작업을 중간에 취소할 수 있게도 해 줘야 한다. 현재 페이지만 인쇄하려 했는데 실수로 100페이지짜리 인쇄를 몽땅 시켜 버리는 건 흔히 저지르는 실수이다.

그렇다면 요즘이야 해결책이 아주 간단하다. "전체 x쪽 중 현재 y쪽 인쇄 중"이라는 진행률 게이지와 "취소" 버튼이 달린 대화상자를 modal로 표시한 뒤, 인쇄는 스레드로 진행하면 된다. 인쇄 스레드는 매 페이지의 인쇄가 끝났을 때마다 main UI로부터 취소 버튼의 클릭 여부를 검사하고, 만약 그게 눌렸다면 AbortDoc을 호출해서 인쇄를 취소하고 곧장 빠져나오면 된다.

그런데 문제는 멀티스레드라는 게 존재하지 않던 옛날 16비트 골동품 시절이다. 이때는 실시간 인쇄 상황 표시와 취소 처리를 어떻게 했을까?
그때는 main 스레드가 근성의 idle time processing만으로 UI와 인쇄를 같이 병행해야 했다. 그리고 이를 도와주는 취지의 API가 제공되었다. 그 정체는 SetAbortProc라는 함수이다.

인쇄를 시작하기 전에 프린터 DC에 대해 abort 콜백 함수를 지정해 주면.. 나중에 그 DC를 대상으로 각종 그리기· 조작 명령이 수행된 뒤에 운영체제가 그 콜백을 매번 호출해 준다. 마치 잠수하다가 수시로 수면 위로 잠깐씩 나와서 숨을 쉬는 것처럼 말이다.
이때 콜백 함수가 해야 할 일은 두 가지였다. (1) 큐에 쌓여 있는 메시지를 처리해서 프로그램의 GUI를 돌아가게 하기, 그리고 (2) 혹시 사용자가 인쇄 취소 명령을 내렸는지 검사해서 그 여부를 리턴값으로 되돌리기.

이를 위해서 콜백 함수에는 무려 message loop이 들어가 있어야 했다. 단, 종료 조건을 통상적인 GetMessage로 하지 말고 PeekMessage(... PM_REMOVE)로 지정해야 한다. 전자는 처리해야 할 메시지가 없으면 메시지가 또 생길 때까지 내부적으로 대기를 한다. 하지만 지금 이 콜백은 메시지 처리만 하고 나서 실행을 종료해야 하기 때문이다.

그리고 SetAbortProc을 호출 하기 전에 "인쇄 중..." 대화상자를 표시해 놔야 한다. 이 대화상자는 백그라운드 인쇄 기능과 연계해서 돌아가야 하는 관계로, 응용 프로그램의 자체 message loop을 타는 modeless 형태로 표시돼야 한다. DialogBox 말고 CreateWindow를 쓰라는 뜻이다.
그래도 이 대화상자의 용도는 명백하게 modal이니, 이게 표시된 동안은 parent 프레임 윈도우로 포커스가 옮겨질 수 없게 EnableWindow(hParent, FALSE) 처리도 사용자가 수동으로 해야 한다.

SetAbortProc 같은 메커니즘이 없었다면 인쇄 도중 UI 표시와 취소를 구현하기 위해서 우리가 수동으로 인쇄 루틴의 내부에다 PeekMessage 체크를 집어넣어야 했을 테니 인쇄용 코드와 인쇄 미리보기용 코드조차 동일하게 관리하기가 어렵고 프로그램이 많이 지저분해졌을 것이다. 하지만 abort 콜백 함수를 구현하는 건 과거의 클립보드 chain 관리만큼이나 여전히 몹시 삽질스럽고 번거로운 구석이 있었다.

사용자 삽입 이미지
(MFC 라이브러리가 자체 구현한 "인쇄 중" 대화상자)

옛날 프로그램으로 인쇄를 해 보면.. 잠깐 표시되는 '인쇄 중' 대화상자는 왠지 추레해 보이고 (1) 그 흔한 진행률 게이지 하나 없고, (2) 다른 대화상자들과 달리 중앙 정렬돼서 표시되지 않고(좌측 상단에 치우쳐서) [X] 버튼도 없으며, (3) 반응성이 안 좋아서 종종 응답이 멎기도 하던 이유들이 모두 설명된다.
(1)은 16비트 시절엔 진행률 게이지 공용 컨트롤이 없었기 때문이요, (2)는 modal이 아닌 modeless로 처리됐기 때문, (3)이야 뭐.. idle time processing으로 돌아가니 반응성이 좋지 않은 것이다.

이런 지저분함은 앞서 언급했듯이 멀티스레드가 등장한 뒤에야 과거 유물로 남게 되었다.
하지만 과거에 나왔던 Windows 프로그래밍 책들은 여전히 옛날 전통적인 방식으로 SetAbortProc 기반의 인쇄 절차를 소개하고 있으며, 16비트 시절부터 유구한 전통과 짬을 자랑하는 MFC도 그 구조를 고스란히 따르고 있다.
SetAbortProc가 함수 주소만 받고 함수에다 넘겨줄 데이터를 받지 않는 것도.. 데이터쯤은 그냥 전역변수로 넘겨주던 1980년대 C스러운 사고방식의 결과물이 아닐까 싶다.

참고로 MS Word의 경우, 신기하게도 스풀러에게 인쇄 데이터를 넘겨주는 작업조차도 철저하게 백그라운드로 수행된다. 즉, "인쇄 중" 대화상자 자체가 표시되지 않으며, "몇 페이지 인쇄 중"이라는 말은 아래의 상태 표시줄에 표시된다. 그 와중에도 문서 편집과 수정이 가능하고 프로그램을 온전하게 사용할 수 있다. 이런 프로그램도 얼마든지 만들 수 있다.;;

Posted by 사무엘

2020/10/23 08:35 2020/10/23 08:35
, , , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1811

« Previous : 1 : 2 : 3 : 4 : 5 : 6 : 7 : 8 : 9 : ... 174 : Next »

블로그 이미지

철도를 명절 때에나 떠오르는 4대 교통수단 중 하나로만 아는 것은, 예수님을 사대성인· 성인군자 중 하나로만 아는 것과 같다.

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

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

Site Stats

Total hits:
1552714
Today:
1094
Yesterday:
647