« Previous : 1 : ... 118 : 119 : 120 : 121 : 122 : 123 : 124 : 125 : 126 : ... 221 : Next »

1. 평행사변형의 넓이, 평행육면체의 부피

2*2 크기의
(a b)
(c d)

행렬이 있을 때, 이 행렬의 행렬식이라고 불리는 D 값은 a*d - b*c로 정의된다. ax+by = 얼마, cx+dy = 얼마 요런 방정식의 근을 구하는 식을 세워 보면 행렬식은 x, y의 분모에 들어가 있다. 그러니 이 값이 0이면 근은 부정이나 불능으로 빠지게 된다.

한편, 행렬식에는 기하학적인 의미가 있다. 원점에서 (a,b)를 잇는 선분이 가로변, 원점에서 (c,d)를 잇는 선분이 세로변인 평행사변형의 넓이를 나타내기 때문이다.

그도 그럴 것이 이 행렬은 한 변의 길이가 1인 (0,0), (1,0), (1,1), (0,1)이라는 정사각형을 (a,b), (a+c, b+d), (c,d)라는 평행사변형으로 옮긴다. (a+b)*(c+d)라는 전체 직사각형에다가 주변의 합동인 삼각형 두 쌍의 넓이를 빼면, 평행사변형의 넓이로 남는 것은 ad-bc뿐이다. 아래 그림을 보시라.

(a+c)(b+d) - b(a+c) - c(b+d) = d(a+c) - c(b+d) = ad + cd - bc - cd = ad-bc

사용자 삽입 이미지

이 평행사변형에서 대각선을 구성하는 (a,b)와 (c,d)를 연결하면 사각형을 반으로 쪼갤 수 있다. 다시 말해 원점과 (a,b), (c,d)를 꼭지점으로 하는 삼각형의 넓이는 ad-bc의 절반이 된다.

다음으로..
저렇게 두 점 A(ax, ay)와 B(bx, by)가 있을 때, A-원점-B 자취의 방향을 판단하는 공식이 있다(시계 방향인지 반시계 방향인지). bx*ay - by*ax이며, 여기에는 배후에 삼각함수 sin( alpha-beta )가 숨어 있다.

그런데 위의 두 점 (a,b), (c,d)도 코싸인/싸인 alpha와 코싸인/싸인 beta라는 극좌표 형태로 표현하면, 행렬식 a*d-b*c 역시 결국은 sin( alpha-beta )과 패턴이 동일함을 발견할 수 있다. 두 쌍의 숫자를 각각 서로 엇갈리게 곱해서 빼는 것 말이다.
이렇듯, 행렬식에 두 벡터의 사잇각에 대한 삼각함수 값이 들어있으니, 벡터의 길이만 정규화하면 각도를 구할 수 있다. 또한 두 변의 길이와 그 사이의 끼인각을 알고 있는 삼각형의 넓이는 A*B*sin(theta)/2로 간단하게 결정된다.

그리고 이 식을 확장하면 삼각형뿐만이 아니라 여러 삼각형들로 분해 가능한 단순다각형(선분들이 서로 만나지만 않으며 볼록하거나 오목할 수 있음) 넓이 내지 폴리곤 패스 방향을 구할 수도 있다. 넓이와 방향(넓이의 부호)이 같이 구해진다.

2차원에서는 이 정도로 분석이 되고, 3차원으로 가면 어떨까?
짐작했겠지만 3*3 행렬의 행렬식은 그 행렬을 구성하는 3개의 벡터들을 축 내지 기저로 삼는 평행육면체의 부피와 같다. 직교좌표에서 모든 점들의 최대치에 해당하는 직육면체의 부피에다가 또 모서리 주변의 온갖 사면체들의 부피를 빼야 하니 식이 굉장히 복잡할 것이다. 3*3 행렬의 행렬식이 항이 6개나 되고 2*2의 것보다 훨씬 더 복잡한 것은 이 때문이다.

하지만 3차원에서도 언제나 부피만 구하는 건 아니다.
차원만 2차원이 아닌 3차원으로 확장한 뒤, 원점에서 출발하는 두 벡터를 가로변 세로변 축으로 삼는 평행사변형의 넓이는 어떻게 구하면 좋을까? (삼각형의 넓이도 당연히 자동으로 포함) 즉, 3차원 공간 안에서의 2차원 평면인 것이다. 이건 2*2 행렬식보다는 어렵겠지만 3*3 행렬식보다는 쉬울 것이다.

그리고 이것이 바로 벡터의 '외적'(벡터곱) 연산이 하는 일이다. 아마 고등학교에서는 내적까지만 하지 외적은 안 배우지 싶다. 단, 내적부터 먼저 개념을 좀 복습해 보자.

2. 벡터의 내적

왜 각 성분을 차례대로 곱한 것을 더하면 내적이 나오는 걸까?
이 원리의 배후에는 코싸인 제2법칙이 있다.
아까 두 변의 길이(두 선분의 길이를 각각 A와 B라 하자)와 그 사이의 끼인각을 아는 삼각형의 넓이를 구했는데, 이 경우 삼각형이 유일하게 결정되었으므로 나머지 한 변의 '길이' C도 당연히 구할 수 있다. 그 삼각형의 모든 특성이 파악 가능한 것이다. C^2 = A^2 + B^2 - 2*A*B*cos(theta) 이다.

이건 피타고라스의 정리의 일반적인 경우이며, 증명하는 방법이 상당히 많다. 여기에서는 제일 직관적인 해석학적 방법 하나만 소개하고 넘어가겠다.
선분 A와 B가 원점을 지나고 선분 A는 x 축에 평행하다고 한다면 선분 A는 (0,0)과 (a,0)을 지나게 될 것이며, 0도인 선분 A로부터 theta도만치 떨어진 선분 B는 선분 B는 (0,0)과 (b*cos(theta), b*sin(theta))를 지난다. 임의의 차원의 임의의 위치에 있는 어떤 삼각형 ABC라도 변환을 통해 그렇게 2차원 평면에서의 일반화가 가능하기 때문이다.

그럼 선분 C의 길이는 저 (a,0)과 (b*cos(theta), b*sin(theta)) 사이의 거리와 같다. 그러므로 길이의 제곱은 (a - b*cos(theta)^2 + (b*sin(theta))^2 가 된다.
이 식을 풀면 a^2 - 2*a*b*cos(theta) + b^2*cos(theta)^2 + b^2*sin(theta)^2 가 된다.
b^2항은 cos(theta)^2 + sin(theta)^2 이므로 1로 약분돼 없어지고, 결국 코싸인 제2제곱 공식이 고스란히 나온다.

그럼, A, B, C를 이제 벡터라고 생각하고 2차원이 아니라 각 축별 좌표를 코싸인 제2제곱 공식에다 대입해 보자.
A=(a1,...,an), B=(b1,...,bn) 같은 식이다. C는 두 벡터의 차이 A-B와 같다.
벡터의 절대값의 제곱은 잘 알다시피 거리의 제곱과 같기 때문에 각 성분들의 제곱을 모두 더한 것과 같다. 그러므로

∑ [i=1..n] (ai^2 + bi^2 - 2*ai*bi) = ( ∑ [i=1..n] (ai^2 + bi^2) ) - 2*A*B*cos(theta) 로 식이 대충 떨어진다.

A와 B에서 각 성분들의 제곱을 합을 구하는 부분은 좌우변 공통이므로 소거되고.. 남는 것은
2*A*B*cos(theta) = ∑ [i=1..n] 2*ai*bi 이다. 여기서 양변을 2로 나눠 주면 내적 공식이 아주 깔끔하게 유도된다. 콜?

벡터의 내적은 그냥 숫자 하나(스칼라)만으로 답이 떨어지며, 벡터의 각 성분들을 차례대로 곱해서 더하기만 하면 된다. 내적에는 두 벡터의 사이각의 '코싸인' 값이 들어있기 때문에, 두 벡터가 서로 수직인지를 벡터의 길이와 무관하게(= 정규화 안 하고도) 간편하게 판별할 수 있다. 코싸인 90도는 0이므로!

내적은 계산이 딱히 어렵지 않을 뿐만 아니라, 2차원이고 3차원이고 어느 차원이든지간에 계산법이 동일하다는 것도 큰 장점이다. 두 벡터의 사이각을 구하는 용도로는 완전 딱이다. cos(alpha-beta) = cos(alpha) cos(beta) + sin(alpha) sin(beta) 인 것에도 2차원일 때의 내적 공식이 숨어 있다는 걸 발견할 수 있다.
또한, 생긴 모양 덕분에 벡터의 내적을 행벡터(행이 하나. 수평선-_-)와 열벡터(열이 하나. 수직선)의 곱으로 표기하기도 한다. (행과 열뿐만이 아니라 횡과 종도 어느 게 어느 건지 종종 헷갈릴 때가 있다만..;;)

3. 벡터의 외적

그에 반해 외적은 결과값도 벡터이다. 그리고 3차원일 때에만 정의된다. 계산값의 각 차원과 피연산자들이 일대일로 딱 밀착해 있는 관계로 3차원 말고는 선택의 여지가 없기 때문이다.

성분이 (a1,a2,a3)인 벡터 A와, 성분이 (b1,b2,b3)인 벡터 B의 외적은
(a2*b3-a3*b2, a3*b1-a1*b3, a1*b2-a2*b1)이라고 정의된다.
어 그런데 이거, 두 쌍의 숫자를 각각 서로 엇갈리게 곱해서 빼는 게 2*2 행렬식을 구하는 것과 비슷해 보인다. 맞다.
그래서 벡터 A, B가 동일 평면상에 있어서 a3와 b3 같은 게 동시에 0이기라도 하면, 해당 변수가 포함된 항은 모두 소거된다. 이 경우 외적은 그냥 2*2 행렬식과 동일해진다.

또 생각할 점은.. 3*3 행렬식을 구하는 것도 특정 row와 col을 제외한 2*2 행렬식을 구하는 것의 연속이라는 점이다. 그래서 외적 구하는 공식을
(i  j  k )
(a1 a2 a3)
(b1 b2 b3)

의 행렬식이라고 표현하기도 한다. 물론 여기서 i~k는 스칼라값이 아니라 각각 (1,0,0), (0,1,0), (0,0,1)에 해당하는 단위벡터이다. 그러니 스칼라와 벡터가 뒤섞여 있는 저 행렬은 대수적인 의미는 딱히 없다. 외적 구하는 공식을 좀 더 뽀대나게 표현하는 용도로만 쓰이는 셔틀일 뿐이다. 그래도 결국은 3*3 행렬식과 닮긴 닮았다.

행렬식을 구하는 공식에서 j에 해당하는 부분은 더하는 게 아니라 뺀다. 그렇기 때문에 외적 공식에서는 1,3이 아니라 3,1 순서로 쓴 뒤에 더하는 것으로.. 다시 말해 양수를 빼는 게 아니라 음수를 더한다고 표현을 달리 했다. 둘 다 동일한 의미이므로 부호에 주의하기 바란다.

벡터는 스칼라와는 달리 '크기'뿐만 아니라 '방향'이라는 정보가 추가로 들어있다.
외적 연산을 통해 구해진 벡터는 일단 크기는 두 벡터의 크기의 곱에다가 사잇각의 sin값을 곱한 것과 같다. 그러므로 3차원 공간에서 두 3차원 벡터가 만드는 평행사변형/삼각형의 넓이를 구할 수 있다.

외적 식을 전개해서 크기의 제곱을 해 보면, 각각의 두 벡터의 크기의 제곱을 곱하고 거기에다 벡터의 내적값(양 벡터의 각 성분들을 서로 곱해서 더함)의 제곱을 뺀 것과 같다고 식이 전개된다. A^2 - B^2 꼴이 되기 때문에 (A+B)(A-B)로 인수분해를 하고 싶은 충동이 느껴지지만 여기서는 식을 다른 형태로 바꿔야 된다.

내적에는 역시 두 벡터의 크기의 곱에다가 사잇각의 cos이 들어 있으니 이것의 제곱이라면 두 항이 결국 |A|^2 * |B|^2를 공통으로 갖고 있고 (1  - cos^2 )가 남는다. 그리고 이것이 sin^2과 같다는 건 두 말하면 잔소리이고.

외적의 크기에 벌써 이렇게 유용한 정보가 들어있는데, 방향은 더욱 흥미롭다.
짐작하겠지만 두 벡터의 외적의 방향은 두 벡터와 수직이다. 물론 위쪽도 수직이고 아래쪽도 수직인데, 해당 좌표계의 동일 부호가 향하는 쪽으로 방향이 결정된다. 두 기저 벡터에 대한 외적을 구하면 나머지 기저 벡터가 튀어나온다.

애초에 두 벡터의 외적은 그 두 벡터와의 내적이 모두 0인 벡터 중에 크기가 저렇게 AB sin(theta)로 나오는 놈을 구한 것이다. a1*c1 + a2*c2 + a3*c3 = 0과 b1*c1 + b2*c2 + b3*c3 = 0을 만족하는 (c1,c2,c3)을 직접 구해 보면 안다. 저것만으로는 식보다 미지수 개수가 더 많으니 (c1,c2,c3)가 하나로 딱 떨어지지 않고 c1과 c2가 c3의 배수인 것처럼 관계식만 나온다. 그런데 c3의 특정값일 때 c1,c2에 있던 분모가 싹 소거되고 c1~c3이 저렇게 아주 대칭적이고 깔끔하게 나오는데 그게 바로 외적값이다.

이런 유용함 때문에 외적이 3차원에서의 전유물이라고 여겨지는 것이다. 이항연산에 딱 최적화돼 있지 않은가.
물론, 외적은 수직이라는 게 위아래가 모두 존재한다는 특성상 교환 법칙이 성립하지 않고 A×B=-B×A이다. 뭐, 4차원 이상에서는 두 벡터와의 내적이 모두 0인 벡터는 3차원일 때처럼 일직선상의 형태로 유일하게 떨어지지가 않는다. 그러니 외적과 같은 접근 방식이 큰 의미가 없어져 버린다.

끝으로, 3차원에서 벡터의 내적과 외적은 삼중곱이라는 연산을 통해 한데 만난다. 3개의 벡터 A,B,C를 축으로 하는 평행육면체의 부피를 구하고 싶으면 아까처럼 벡터들을 3차원 행렬의 행렬식으로 표현해도 되지만, 밑면에 속하는 두 벡터 A×B의 외적을 구한 뒤 거기에다 C와 내적을 구하면 된다. (A×B)·C! 그게 결과적으로 행렬식을 구한 것과 같은 계산 결과가 도출된다. 왜 그런지는 아까 그 외적 구하는 행렬과 일반 행렬의 행렬식을 늘어놓고, 거기에다가 내적을 구하는 공식까지 적용한 뒤 서로 비교하며 생각해 보면 된다.

Posted by 사무엘

2015/08/23 08:25 2015/08/23 08:25
, , , , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1130

한국과 일본은 가까운 이웃 나라이지만 기독교계 종교에 대한 정서는 거의 지구와 금성의 차이만큼이나 극과 극이다. 물론 일본뿐만이 아니라 북한 내지 중국하고 비교해 봐도 극과 극에 가까운 건 마찬가지이지만.

난 솔직히 말해 일본의 보편적인 종교관을 잘 모르겠다. 완전히 불교도 아니고 유교, 도교도 아니고 전적으로 샤머니즘이라고 봐야 하는 건지? 신사는 무엇이고 덴노(일왕/천황)는 무엇이고 이들이 정치 종교 통합적인 존재인지? 어쨌든 기독교 배경이 절대로 아닌 것만은 확실하다. 한국 사람들은 기독교인이 아니라고 해도 딱히 단군을 숭배한다거나 하지는 않는데?

일본은 서양 문물을 잘 받아들이고 근대화를 잘해서 서구 열강의 식민지가 되지 않았으며, 반대로 다른 식민지를 거느리고 침략 전쟁을 일으키기까지 할 수 있었다. 서양 문물을 받아들이는 과정에서 흔히 '기독교'라고 부르는 종교 교리도 당연히 전파되었고 선교사들도 들어왔다. 단, 엄밀히 말하면 기독교 계열은 아니고 스페인의 예수회가 주축이 된 천주교 중심이었다.

16~17세기 사이는 조선에서는 임진왜란이 벌어져서 나라가 작살이 나 있었고, 서양의 영국에서는 엘리자베스 1세, 제임스 1세, 찰스 1세의 순으로 왕이 바뀌고 있었다. 신대륙에서는 버지니아 주 제임스타운, 포카혼타스 이런 일이 벌어지고 있었다.
그런 와중에 스페인에서는 종교 개혁을 저지하고 유럽을 다시 가톨릭화하기 위해 예수회가 만들어졌는데... 이와 비슷한 시기에 일본에 천주교가 전래되었다.

조선도 한때 천주교에 대한 박해가 없지는 않았다. 황 사영 백서 사건 같은 병크 때문에 스스로 매를 번 것도 있었고. 하지만 그 기간이나 규모는 일본의 박해에 비할 바는 못 됐다. 임진왜란을 일으켰던 도요토미 히데요시부터가 극렬 "안티개독"이었으며, 정말 중세 종교 재판을 뺨치는 가학· 변태적인 악랄한 고문과 형벌로 신자들을 괴롭히고 죽이고 박멸했다. 천주교고 기독교고 그딴 건 그 양반이 알 바 아니었을 테고.

다른 때도 아니고 서양에서는 킹 제임스 성경이 나오는 동안 동양에서 저런 일이 벌어졌다는 것이, 천주교 기독교를 떠나서 일단은 안타까운 일이다. 이 시기에 있었던 일들은 일본의 B급 새디스트 사극 영화의 좋은 소재가 되어 왔다. <쇼군의 새디즘>처럼.
사람을 십자가에다 묶어 놓고 산 채로 창으로 옆구리를 찌르기, 미꾸라지가 가득한 어항에다 사람을 옷 벗겨서 집어넣기, 썰물 때 바다 갯벌에다가 십자가 기둥을 꽂고 사람을 거꾸로 묶어 놓기(그 상태로 나중에 밀물이 되면..;;) 이런 건 중세 서양에서는 못 본 장면 같다. -_-;;

사용자 삽입 이미지

또한, 육체적으로 끔찍한 형벌이나 고문은 그렇다 치더라도.. 이런 것도 있었다고 한다.

"그들은 당시의 기독교인을 색출, 고문, 박해하는 형태를 여러 가지로 연구하면서 철두철미하게 기독교 박해를 자행했다. 십자가나 예수나 마리아 상을 새긴 동판이나 목판 위를 밟게 함으로써 기독교인이 아니라는 것을 증명하는 후미에 제도는, 1629년 나가사키에서 시작되어 전국에 걸쳐 오랜 기간 사용되었다."


"어디에 절을 해라", "입으로 믿음을 부인해라", 아니 단순무식하게 "김 일성 개XX 해 봐라" 식의 더 간단한 판별법도 있었을 텐데, 저건 그야말로 성상, 형상을 중요하게 생각하는 천주교 스타일에 최적화된 판별법이라 여겨진다. 나 같았으면 저런 건 걸릴 게 없었을 것이다. 마치 주의 만찬이 끝나고 남은 빵과 포도 주스는 아무렇지도 않게 누가 몽땅 집어먹거나 여느 잔반을 처리하듯이 임의 처분해도 되는 것처럼 말이다. (사실, 소설 <바비도>에 나오는 것처럼, 성찬식에 대한 견해 하나만으로도 서양에서는 한때 순교 사유였다. 기독교인이 천주교인에게 죽임을 당했다는 뜻이다.)

북한은 민주화에 실패하고 8월 종파 사건을 계기로 완전 김씨 일가의 철권독재 생지옥으로 전락했다. 종교도 주체사상 외에는 당연히 전면 말살. 스페인은 종교 개혁이 실패하고 다시 가톨릭 국가로 돌아가서 20세기까지만 해도 누가 '개신교인'(천주교의 입장에서 기독교의 호칭)이 되면 잡혀 가는 나라가 됐다.

그것처럼 일본도 이 박해를 못 이기고 천주교/기독교를 막론하고 양놈(이 또한 엄밀히 말하면 양놈이 아니라 유대계=_=) 종교는 거의 씨가 말라 버렸으며, 그 상태가 오늘날에 이르렀다. 개신교 계열 교파가 나중에 안 들어온 건 아니지만, 그래도 1억이 넘는 일본 인구 중에 그나마 명목상 교회 다니고 예수 믿는다는 사람은 몇십만 명밖에 되지 않는다.

이런 배경이 있는 일본은 오늘날까지도 이슬람도, 공산주의도 아니고 나름 자유 진영의 강대국 선진국인 것치고는 상당히 이례적인 기독교 선교의 불모지로 여겨진다. 솔까말 기복신앙에 대한 반례이기도 하다. 뭐, 국가가 부유한 것만치 국민들이 다 잘사는 건 아니더라도 말이다. 쟤들이 과거에 한국의 크리스천들을 박해하긴 했지만 역사 전체를 통틀어 봤을 때 아예 자국민에 대한 천주/기독교 박해는 그 이상이었다는 점도 고려할 사항이다.

이런 상황에서, 한국인이 일본 선교를 가는 건 마치 요나가 니느웨로 설교하러 가는 것과 비슷해 보인다. 앗시리아가 훗날 북왕국 이스라엘을 멸망시킬 게 뻔히 보이니, 요나는 니느웨로 가기 싫어서 하나님 앞에서 얼마나 생쑈를 했던가? 하지만 인제 와서 일본에서 니느웨 같은 대각성 부흥이 과연 일어나기라도 할지는 좀 회의적이다. 성경적으로 민족주의를 적용할 문맥이 있고 그게 별 의미나 영양가가 없는 문맥도 있는 법이다.

한국은 역사가 워낙 스펙타클하다 보니, 조선 정부에 의한 박해보다는 일제 말기에 일제로부터의 박해, 그리고 해방 후에 공산주의자에 의한 기독교 박해가 더 부각되는 편이다. 그리고 아시아의 여느 나라들과는 달리, 기독교회가 이 정도로 양적 성장을 이루는 이례적인 선례를 세계에 남겼다. 신자라면 감사할 일이다.

Posted by 사무엘

2015/08/21 08:31 2015/08/21 08:31
, , , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1129

삼손 평전

성경에 나오는 삼손은 이스라엘의 사사치고는 너무 괴팍하고 특이했던 사람이며, 천하장사였지만 여자에게 배신을 당해서 인생을 망친 비운의 사나이라고 비기독교인에게도 그럭저럭 알려져 있다.
삼손은 혼자서 많은 블레셋 사람들을 살상했지만, 그렇다고 해서 정식으로 군대를 소집하고 전쟁을 벌여서 블레셋으로부터 확실하게 독립을 쟁취해 낸 건 아니었다. 오히려 명색이 민족 지도자인데 적국의 여자와 연애를 하면서 너무 똘끼 넘치게 행동했다.

민족 대표, 민족 지도자라 불리는 사람은 적국이 아니라 그냥 중립적인 외국인을 애인· 배우자로 맞이하는 것만 해도 민족 정서상 대외 평판에 절대로 좋게 작용하지는 않는다. <이 연걸의 정무문> 영화에서 일본인 여자를 사귄 진진, 그리고 에티오피아 여인과 재혼했다고 비방을 받은 모세(민 12:1) . 거기에다 우리나라 초대 대통령 이 승만도 그 많고 많은 한국 여자를 놔 두고 '호주댁'과 결혼했다고 비방 받곤 했다. 삼손 역시 그런 격이었다.

사사기 14장을 보자. 그는 부모의 반대를 무시하고 첫 블레셋 여인에게 청혼을 하러 갔다. 그런데 포도원에서 사자를 만났다. 이건 단순히 위험에 처한 상황이기에 앞서 여러가지로 이상한 상황이었다. 왜 포도원인 걸까?

삼손은 나사르 서원의 적용을 받는 사람이어서(삿 16:17) 머리를 깎는 것뿐만이 아니라 포도도 절대 금지이다. 단순히 알코올 성분이 든 포도주를 안 마시는 것 정도를 넘어, 아예 생 포도송이, 포도 주스, 건포도 같은 것도 먹어서는 안 된다. (민수기 6장 참고) 불자에다 비유하자면 오신채를 먹어서는 안 되는 것처럼 말이다. 그런데 삼손은 왜 포도원을 갔을까?
그리고 포도원에서 뱀이라든가, 혹은 여우(아 2:15)처럼 성경에도 나오고 이솝 우화에도 나오고 침입자로서 비교적 흔히 연상 가능한 동물을 만난 게 아니라, 하필 야생 맹수인 사자를 만난 걸까?

구약 역사서에서 동물 사자는 사람을 징벌하는 용도로 종종 쓰였다. 그러나 저기서는 하나님께서 삼손에게 몬스터/몹만 소환한 게 아니라 Doom 2 게임으로 치면 Berserk 파워업 치트키를 먹여 주셨다. 다윗은 돌팔매질로 맹수들을 내쫓았다지만, 삼손은 도구가 필요하지 않았으며 그냥 맨주먹으로 사자를 찢어 죽였다. FPS 용어로 치면 gib을 했다.

그런데 이런 놀라운 무용담은 "하나님이 나를 지켜 주셨습니다"라는 공개적인 간증거리가 될 수가 없었다.
"하나님께서 화재 현장에서 저를 기적적으로 지켜 주셨습니다" / "오 그래요? 어디서 화재를 겪으셨는데요?" / "나이트클럽에서요" =_=;;; 이런 꼴이었기 때문이다.
삼손은 공인으로서 포도원 안에서 그런 일을 겪었다는 얘기를 입 밖에 낼 수 없었다.

나중에는 삼손이 죽인 사자의 시체에도 이변이 생겼다. 더러운 구더기가 들끓는 게 아니라 여왕벌이 들어오기라도 했는지 안에 벌꿀이 생겼다. 하지만 아무리 꿀이어도 그렇지 저건 시체 안에 담겨 있는 건데..;;
원효대사의 이야기만 봐도, 밤에 마셨던 물이 더러운 해골 안에 담겼었다는 걸 알게 되자, 그 사람이 우웩~ 하면서 난리를 치지 않았던가.

그런데 삼손은 참 멘탈도, 비위도 강했나 보다. 부정한 걸 만져서는 더욱 안 되는 나사르 인인데도 손수 사자의 시체를 뒤져서 꿀을 가져와서는 자기도 먹고 부모에게도 줬다.
이것 다음에 꿀 이야기는 사무엘기상 14장에서 또 나오는데 이것과는 어떤 영적 관계가 있으려나 모르겠다.

삼손은 혼자서 사자를 때려 잡고 그 시체에서 꿀까지 득템한 행적을, 비록 공개적으로 간증은 못 하지만 개인적으로는 분명 뿌듯한 자랑거리라고 생각한 듯하다. 율법을 몽땅 어긴 건 안중에 없고 말이다.
그래서 결혼식을 앞두고 친구들에게 그걸 절대 풀지 못할 수수께끼 문제로 냈다. 사자와 꿀이라니, 전혀 어울리지 않는 조합을 평범한 사람들이 떠올리기란 물론 불가능했다.

삼손의 친구들은 치사하게도 삼손의 여친을 공갈 협박해서 답을 알아 냈다. 이것은 오늘날 정보 보호· 보안의 관점에서도 의미 있는 사례이다. 이중 삼중으로 복잡하게 암호를 걸어 놔도, 관리자 당사자 내지 그 지인을 매수하거나 족치는 데 성공하면 그냥 끝이니까. 결국 모든 문제의 정점에는 사람이 있다.

이 때문에 삼손은 내기에서 졌으며, 옷 서른 벌을 마련하느라 다른 동네의 블레셋 사람 30명을 쥐도 새도 모르게 죽이게 됐다. 옷 서른 벌 때문에 30킬이라니 오늘날로 치면 그야말로 개 싸이코패스 연쇄살인마가 따로 없다. "피해자들은 모조리 시체도 없이 실종"되거나 또는 "피해자들은 모두 겉옷이 없어졌다는 공통점 있음" ㅎㄷㄷㄷㄷ
그 시절에 마을 곳곳에 CCTV가 없었던 게 정말 천만다행이었다.

사용자 삽입 이미지

(모든 그림의 출처는 삼손의 생애를 그린 칙 출판사 만화 전도지 <Superman?> (1990) 편.)

그리고 또 생각할 점이 있다. 피해자가 입고 있던 옷을 그대로 벗겨서 줘야 하니, 사람을 죽이는 것도 옷이 찢어지거나 핏자국이 묻지 않게 매우 조심해서 죽여야 했다는 점이다. 때리거나 칼로 찔러서는 안 되고, 뒤에서 덮쳐서 목을 조르거나 비틀기라도 해야 했을 것이다. 물론 삼손은 워낙 천하장사 인간흉기였으니, 사람 목을 움켜쥐고서 손가락에 까딱 힘만 주면 곧바로 경동맥이 작살이 났을 테고, 사람을 무슨 개미를 눌러 죽이듯이 죽일 수 있었을 것이다.;;

나중에 당나귀 턱뼈로 블레셋 사람 1천 명을 죽인 건 고전 FPS로 치면 천하무적 주인공이 잡몹들을 싸그리 사냥하면서 1000 kill / frags를 달성하는 것과 똑같다. 삼손의 이야기는 은근히 게임스럽다. 턱뼈가 아니라 칼이나 창 같은 진짜 냉병기가 있었다면 삼손의 주변에 있던 적군들은 그냥 죽는 수준을 넘어 그야말로 사지가 남아나지 못했을 것이다.

단, 이 사건은 포도원에서의 사자 킬과는 달리 공적인 찬양 명분이 충분함에도 불구하고 삼손은 딱히 하나님께 영광을 돌리지 않고 "내가 당나귀 턱뼈로 시체로 산을 쌓으며 1천 킬을 달성했도다"라고 으쓱하기만 했다(삿 15:16).
이에 삼손은 싸움을 다 이겨 놓고는 곧 극심한 갈증으로 인해 죽을 지경이 됐다.
하나님은 삼손에게 당장의 기도 응답과 승리는 주시지만 그래도 뼈 있는 경고도 같이 주셨다는 것이 눈에 들어온다. 그 경고에 담긴 메시지를 삼손이 더 일찍 간파했으면 자기 자신이나 민족이 훨씬 덜 불행을 겪어도 됐을 텐데 말이다.

이것들 말고도 삼손의 차력 기행 중에는 성을 탈출하기 위해 그 크고 무거운 성문을 잠금 장치까지 포함해 통째로 뜯어 버린 뒤, 그걸 방패 삼아 등에 지고 도망친 것이 있다(삿 16:3). 못해도 수백 kg 내지 몇 톤에 달하는 무게였을 것이다.
이 정도면 블레셋의 입장에서는 그야말로 전의를 상실케 하는 충격과 공포 도시전설 괴담이었을 것이다. (그런데 나중엔 상황이 역전되어 블레셋에서 골리앗이 배출된 것이 참 공교롭다. 삼손과 골리앗이 일대일 맞장을 떴으면 어땠을까? =_=)

그런데 삼손이 그저 무식하게 힘만 셌는가 하면 그건 또 아니었다.
"삼손이 가서 여우 삼백 마리를 붙잡아 꼬리와 꼬리를 묶고 불붙는 나무 조각들을 취하여" (삿 15:4)
이것도 얼마나 대단한 일인지를 알아야 한다. 오로지 복수를 위해서 산과 들로 나가서 여우를 300 마리나... 그것도 학살이 아니라 산 채로 수집하는 데 시간과 노력이 얼마나 들었을까?

이건 힘만 세다고 가능한 일이 아니다. 퀘이크로 치면 Frags나 Excellent가 아니라 Impressive, Perfect, Accuracy 같은 분야에 속하는 어려운 일이었다. 생포하는 과정에서 여우를 다리 같은 걸 조금이라도 다치게 해서도 안 된다. 여우들을 꼬리에 불을 붙인 채 풀어 줘서 남의 밭을 왕창 불태워 버릴 작정이었으니 말이다. 얘들은 마지막 순간까지 밭을 전속력으로 뛰어다닐 수 있는 상태여야 한다!

삼손은 늘 개인 플레이를 하다 보니, 딱히 자기 동지· 부하나 공범이 있었는지는 모르겠다. 만에 하나 공범이 좀 있다 하더라도 여우를 300마리나 곱게 사로잡는 건 어떤 방법으로든 정말 보통일이 아니다. 삼손은 굉장한 근성가이였음을 알 수 있다.

.
.
.

이런 삼손이 한 순간의 실수로 인해 너무 허무한 최후를 맞이했다는 것은 참으로 애석한 일이다. 자기의 엄청난 능력에도 불구하고 헬스 트레이너-_-로든 성경· 정치· 군사 어느 쪽으로도 후계자 양성을 못 하고 정규전 한 번 제대로 못 치른 채 혼자 원맨쇼만 일삼다가 자폭으로 모든 것을 끝냈다.

삼손은 들릴라의 치명적이고 위험천만한 질문에 대해 너무 째째하고 진지하고 재미없게(?) "당신, 내 힘의 근원을 알려고 했다간 다쳐. 그런 건 다시는 묻지 마시오. / 내 힘은 우리 민족의 신인 주 하나님께서 주신 것이오" 이렇게 원천차단 돌직구를 날리기에는... 너무 대인배였다.
예전에 사자를 죽이던 시절부터 수수께끼와 내기를 즐기던 근성이 여전했다. 이제는 절대로 유출되어서는 안 되는 자기의 힘의 근원마저도 수수께끼 소재로 삼아서 "그게 궁금해? 그럼 내가 힌트 줄 테니 알아맞혀 보셔" 유흥거리로 생각했다. 그러면서 살얼음판위를 걷는 것과 같은 위태로운 게임을 계속했다. 이것은 그의 치명적인 실수였다.

하지만 그는 영적으로 순진하고 철딱서니 없는 구석은 있을지언정, 교활하거나 나쁜 사람은 절대로 아니었다. 동족들로부터 버림받을지언정 자기가 먼저 동족을 해치지는 않으려 했으며, 철저하게 피아 구분을 할 줄 알았다. "나 한 몸 죽어서 다른 사람들을 살리리라"라는 뭔가 요나와 예수님의 예표스러운 행적도 있다.
그 스펙과 지위에도 불구하고 여자한테는 완전 순애보였고..;; 어쨌든 교활 잔머리의 천재인 발람하고는 억만 광년 떨어진 성향이었다.

"오 하나님이여 간구하옵나니 이번 한 번만 나를 강하게 하사 블레셋 사람들이 내 두 눈을 뺀 것을 단번에 원수 갚게 하옵소서. (...) 나를 블레셋 사람들과 함께 죽게 하소서"(삿 16:28,30)는 눈물이 핑 돌 정도의 회한 서린 비장한 기도가 아닐 수 없다. 그도 그럴 것이 저 사람은 적군에게 잡히고 나서 꼴좋다고 얼마나 새디스틱한 모욕과 능멸을 당했겠는가?

사용자 삽입 이미지

(우리로 치면 ㅎㅎ/ㅋㅋㅋ를 W를 붙여서 haw haw라고 표현하는 건 칙 만화 전도지의 고유한 관행이다.)

가정용 소형 맷돌이 아니라 아예 감옥에 있는 대형 맷돌은 나귀나 소 같은 동물을 동원해서 돌리는 물건이다. 요즘 같았으면 당연히 내연기관이나 모터를 쓰지 생명체는 쓰지도 않는다. 자동차에 밀려서 인력거가 사라진 것처럼 말이다. 삼손은 딴 데다 비유하자면, 배나 건물의 지하 기계실 같은 데서 평생 힘만 쓰는 동력 셔틀로 전락하고 말았다(삿 16:21).
작업 환경이 어두컴컴한 건 삼손에게는 별 상관이 없다. 어차피 눈이 없는 상태이니까. 사람을 무진장 귀찮게 하던 파리나 모기가 결국 생포당해서 날개가 뽑힌 것과 비슷한 격이다.

삼손의 생애를 각색한 드라마 중에는 (1) 들릴라가 마치 가룟 유다마냥 나중에 양심의 가책을 느껴서 삼손을 배반한 것을 후회하고 울고불고 매달리는 이야기가 들어간 게 있다. 요즘 사람들은 절대적인 선악 구도보다는 대체로 입체적인 인물 위주의 휴먼 드라마를 좋아하니까.
또한, 삼손이 마지막 순간엔 자기가 신전의 기둥을 붙드는 것을 도와 준 소년에게는 몰래 (2) "고맙소. 당신은 이 신전에서 최대한 멀리 빨리 탈출하시오."(내가 곧 신전을 무너뜨릴 거니까)라고 귀띔을 하는 애드립이 있기도 하다.
물론 이에 대해서는 "진실은 저 너머에"이다. (1)과 (2)는 성경에 직접적인 언급은 없는 애드립일 뿐인 것을 감안하도록 하자.

사용자 삽입 이미지

성경에 따르면 삼손은 거대한 석조 건물을 맨손으로 붕괴시킴으로써, 자폭하면서 죽인 블레셋 사람 수가 생전에 죽인 블레셋 사람 수보다 더 많았다고 말한다. 저 정도 대형 신전은 폭탄 테러로 붕괴시킨다고 해도 TNT가 몇 톤짜리가 필요했겠는가? =_=;;; 이거 정말 그냥 웃어 넘길 일이 아니다.
(참고로 1995년 오클라호마 폭탄 테러가 TNT 2.3톤 정도의 위력이었으며 영국의 Gunpowder plot이 위력계수 0.55짜리 흑색 화약 1.n톤이니 TNT 1톤에 약간 못 미치는 정도의 위력으로 추정됨)

성경에 기록된 생전의 kill 수만 해도 최하 1000+30+알파인데, 저 붕괴 사고로 몰살당한 사람은 제일 적게 잡아도 3천 명가량으로 추정한다(삿 16:27, 30). 블레셋 민족의 원수 삼손이 재주 부리는 꼴을 보러 사람들이 참 많이도 몰려와 있었기 때문이다. 20년 전에 삼풍백화점 붕괴 사고로 죽은 사람이 600여 명, 부상자가 900여 명이니 저 살상 규모가 얼마나 엄청났는지를 추측할 수 있다.

삼손은 히브리서의 믿음장에 이름이 올라 있으며, 덕분에 자살· 자폭을 하고도 정황상 얼마든지 구원받는 게 가능하다는 예로도 언급된다. 삼손이 실존 인물일 뿐만 아니라 하늘나라에서 만날 수 있는 믿음의 선진이라는 것을 히브리서의 저자(아마 사도 바울)가 확실하게 인증한 셈이다. "삼손도 믿음으로 신전을 무너뜨렸다." 같은 말이 "더 이상의 자세한 설명은 생략한다" 속에 포함되어 있을 것이다(히 11:32).
또한 딸을 죽이는 대형 사고를 치긴 했지만 그래도 믿음이 있었고 나쁜 사람은 아니었던 입다 역시 같이 믿음장에 있는데, 삼손은 저 사람하고도 뭔가 통하는 맥이 있어 보인다.

그나저나 머털도사가 삼손 이야기에서 모티브를 땄나 싶은 생각이 든다. 거기에도 머리털이 다시 자라는 게 나오는데..;;

Posted by 사무엘

2015/08/18 08:27 2015/08/18 08:27
, ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1128

오사마 빈 라덴이 죽은 지가 벌써 4년이 넘었다.
저 한 사람을 잡으려고 미국이 정말 얼마나 천문학적인 돈(= 국민 세금)을 쏟아부어야 했는지를 생각하면 아마 치가 떨릴 것이다.
정확한 근거는 모르겠다만, 한때 미국 해병대 내부에서는 "빈 라덴을 용서하는 것은 신이 하실 일이겠지만, 둘의 만남을 주선하는 것은 우리 일이다."라는 대박 간지 넘치는 모토가 설정돼 있었다고 한다. 짱이다. 같은 메시지도 단어만 바꾸면 저렇게 센스 넘치게 표현할 수가 있구나!

뱀발을 내밀자면, 비슷한 패턴의 대사가 테이큰 3에도 있었다.
"내게 이틀만 주시오. 그러면 내가 무죄인 것과 진짜 범인이 누군지를 모두 입증해 보이겠소!"
"밀스 씨, 당신의 무죄 여부는 법정에서 판단할 일이지 내 관할이 아니오. 내가 할 일은 당신을 붙잡아서 법정에 세우는 일이지. 단지 그 뿐이오.
당신이 그 길로 도주한다면 LAPD(로스앤젤레스 경찰국), FBI, CIA가 모두 당신을 찾아 나설 것이고 당신을 저지시킬 거요."
"굿 럭." 아, 뿅 갈 거 같다.

뭐, 빈 라덴은 실제로 신에게서 용서받았을 확률은 매우 희박하며(단순 악행 때문만은 아님), 정작 실제로 둘의 만남을 주선한 것도 해병대가 아니라 해군 대테러 특수부대였다.
그 시절을 좀 회상하자면, 그는 하필 킹 제임스 성경 반포 딱 400 주년 당일에 사살당했다. (2011년 5월 2일) 이건 뭐 그냥 우연이라 치자.
듀크 뉴켐 포에버는 원래 북미 기준으로 5월 3일에 나오려 했는데 마지막으로 딱 한 번 더 연기돼서 6월 10일로 낙점됐었다.

이렇게 빈 라덴을 사살하기 위해서 미국은 전국, 전세계 각지에서 놈의 근황과 행동을 추적하고 치밀한 첩보 활동을 벌여야 했다. 미국은 세계에 큰 영향을 끼치고 있는 나라이고 그만큼 적도 많으니까.
세계 각국에는 보이지 않는 곳에서 방첩 활동을 하는 국가 기관이 있다. 그것이 우리나라는 한때는 중앙정보부, 안기부였다가 지금은 국가정보원, 혹은 국정원이다. 미국이나 이스라엘처럼 국내· 국외가 나뉘어 있지는 않고 단일 기관이다.

전철 안에서 111 신고 전화를 홍보하면서 "국가정보원에서는 마약, 국제범죄, 테러, 산업 스파이 등 ..." 어쩌고 하는 방송을 종종 들은 적이 있을 것이다.
요즘 국정원에서 실제로 하는 일은 예전만치 오로지 대공· 대북 업무보다는 제3세계 산업 스파이 단속의 비중이 더 크다. 이런 교묘한 범죄를 잡아 내는 건 경찰만으로는 증거 확보에 어려움이 있는 관계로, 불시에 확 덮쳐서 범죄 순간의 스냅샷을 떠 주는 전문 첩보 기관의 도움이 필요하다.

국정원 요원은 딸을 구하기 위해서가 아니라 국익을 지키기 위해서 진짜로 리암 니슨처럼 어디에 위장해 들어가고 감시하고, 필요하다면 폭력도 쓰고 희대의 난폭운전도 벌이는 등 별 짓을 다 해야 한다. 그러다 들키면 납치· 고문· 살해 등을 당하기도 하고 이때 모기관으로부터는 필요하다면 "우린 저런 요원을 보낸 적 없는데? 모름." 버림받기까지 하는 것도 국익을 위해 감수해야 한다.

국정원이 워낙 뽀대와 간지가 나고 연봉과 복리후생이 좋다고는 하지만, 그걸 다 공짜로 제공해 줄 리가 없으니.. 그저 간지만 보고 도전할 만한 곳이 결코 아니다. 임기응변과 근성, 예리한 관찰력이 부족한 사람, 그 어떤 사람과도 친근하게 붙어서 원하는 정보를 얻을 정도의 화술과 사회성을 갖추지 못한 사람, 일반인 평균 이상의 지력과 체력이 없는 사람, 미행을 티 안 나게 못 하고 어디서든 거짓말을 실감나게 못 하는 사람은 저런 기관에 절대로 들어가서는 안 된다.

특히, 자기 분야의 밥벌이 기술만 평생 연마하며 살고 싶은 사람, 처자식과 평범한 가정 꾸리고 가정적인 남편이 되고 싶은 사람은 더욱 가지 말아야 한다. 고로 국정원 같은 곳은 본인에게 맞는 직장은 전~혀 아니다.
그럼에도 불구하고 국정원 요원 신입 공채는 SKY 출신에 외대 출신들이 대거 몰려 경쟁률이 몇십~100몇십 대 1이라고 한다.

본인이야 인간의 죄성의 본질을 아는 크리스천으로서, 절대악을 다스리기 위해 불가피한 필요악의 존재에 대해 긍정적이다. 북한 같은 절대악이 있는 우리나라 같은 상황에서는 더욱 그러하다. 그러나 그 필요악이 옛날에는 잡으라는 빨갱이는 안 잡고, 반공을 빌미로 도리어 자국민에게 나쁜짓을 한 것도 있음은 사실이다. 그래서 첩보 기관인 국정원 역시 대국민 이미지가 아직까지도 마냥 좋지만은 않다.

이런 위압적이고 코렁탕 스러운-_- 이미지를 쇄신하기 위해서인지 국정원에서는 일반 시민들을 대상으로 꽤 오래 전부터 한 달에 두 번꼴로, 국정원 요원이 하는 일이나 당할 만한 일을 소재로 추리 퀴즈를 연재하고 있다. 국정원 요원이 반쯤은 탐정 같은 일도 하는구나. 기출문제가 이미 몇백 개나 쌓여 있다.
영화나 드라마를 많이 본 사람들은 어지간히 뻔한 설정이나 스토리, 클리셰를 보면 다음 장면이 바로 예상이 되듯이, 추리 소설 덕후들은 딱 보면 바로 답이 나올 정도의 난이도라고 한다.

추리소설의 설정에만 파묻히면, 마치 Doom 2를 너무 많이 한 것처럼 정말 세상에 어디 믿을 놈 없고 기술을 어디 팔러 홀몸으로 나갔다가는 반드시 살해당할 것만 같고, 마약 조직이나 사이비 종교에 있다가 탈출하게 되면 정말 목숨을 부지 못할 것 같다.
시신을 전기 장판으로 덮어서 따뜻하게 유지해서 체온 감소로 사망 시각을 추정하지 못하게 하는 건 2008년 부산 청테이프 살인 사건에서 실제로 있었던 일인데 이걸로 모티브를 딴 건지?
또한 커피에 독을 타서 누구를 독살한 건 대한제국 마지막 황제 순종이 어린 시절에 비슷하게 당한 일이다. 국정원 간부라면 역사· 시사· 상식의 달인일 테니 이런 것에서도 소재를 차용했을지도 모르겠다.

추리 문제를 푸는 건 어찌 보면 거짓 증언에서 설정 오류를 찾아내는 것이니, 역덕후들이 사극을 보면서 고증오류 찾아내며 낄낄대는 것과 비슷한 것 같다. 뭔가 교집합이 있다. 나 같아서도 당장 떠오르는 철도 추리 퀴즈는 전철이 절연구간에 진입해서 좀 어두워졌을 때 객실에서 무슨 살인 사건이 터졌고, 어느 철도 덕후 탐정이
"범인이 제시한 사진은 합성· 조작된 것입니다. 2014년에는 아직 수인선 전철이 거기까지 개통하지 않았습니다."
"그 복복선 선로 구간에서 일반열차가 내선을 주행한다는 건 있을 수 없는 일입니다."
이런 데서 단서를 찾아내면 무척 아름다운 이야기가 완성될 것 같다.
이와 관련된 본인의 옛날 글을 한번 보시라. 거기서도 이미 '셜록 홈즈' 같다는 댓글이 있었다. ^^

실제로, 국정원 추리 퀴즈 기출문제들 중 다른 건 내가 뭔 소리인지 몰라서 대부분 그냥 해답을 봤지만,
이것만은 그냥 문제를 다 읽기도 전에, 저거 그림만 보고는 출제 의도와 논리상의 헛점을 0.n초 만에 바로 알아챘다. <전철 3호선 살인 사건> 편.

우측통행을 하는 전동차 선로 사진을 들이밀면서 '1호선 보산 역'이라고 주장하며 알리바이를 내세우다니 거 참.. ^^
아 추가로, 그림에 나와 있는 전동차가 폭이 좀 작은 편인지라,
혹시 지방 지하철의 중형 전동차 사진을 찍어 갖고 와서는 서울· 수도권 전철이라고 사기 치는 건 아닌가도 생각을 했는데 그건 아니었다.

정말로 아는 만큼 보이고 시뮬레이션이 된다.
추리 소설은 걸핏하면 정체불명의 시신이 발견되는 것으로 이야기가 시작되지만, 역사적으로 시신의 신원이 전혀 밝혀지지 않아 영구 미제 사건으로 남은 사건도 있다. 1948년 12월, 오스트레일리아 소머튼 해수욕장의 "Taman shud" 사건은 그 많은 똘똘이들이 추리를 하고도 도저히 답을 못 구한 사건 중 하나이다. 그는 아마 어느 나라에서 보낸 흑색 첩보 요원이 아니었나 싶다.

뭐, 그런 현실 설정 말고도
"다음과 같은 도로 지도에서 다리를 최소 몇 군데를 끊으면 A에서 B지점까지 테러리스트의 도주 경로를 완전히 차단할 수 있을까?"
이건 그래프에서 단절점 내지 브릿지를 찾는 문제이니 컴공/전산 전공자에게는 익숙할 것이고,
A~E가 전부 범인이라 지목하는 사람이 다 다를 때 진짜 맞는 증언을 찾는 문제는, 이건 가로· 세로로 O X 표 만들어서 IQ 테스트 하듯이 풀면 되겠다. 실제로 이런 문제는 정보 올림피아드 문제 같다는 생각이 들기도 했다.

간단한 문자/문자열 암호 풀이 문제도 있고.
국정원 추리 퀴즈 중에서 누군가가 남긴 추상화 형태의 다잉메시지 퍼즐을 푸는 건...
지난 2009년에 어떤 만화가가 원주 시정 홍보지의 삽화에다 대통령 욕설을 교묘하게 적어 놓은 걸 찾아 내는 것 같은 생각이 들었다. -_-;;

사용자 삽입 이미지

아무튼, 세상엔 걍 생업 전선에서 자기 근로만 하면서 갑님으로부터 월급 받는 것에 만족하지 못하고, 저렇게 맨날 머리 굴리면서 세상을 참 복잡하고 스릴 넘치게 사는 사람이 많다.
그리고 한편으로 인간은 죄 때문에 죄를 감시하고 죄의 결과를 수습하느라 정치 권력이 없을 수가 없게 되었으며, 그 비효율적인 일에 무지막지한 양의 세금이 쓰이게 되었다는 것도 알 수 있다.
난 저렇게 외국에서 탐내고 국내에서 보호해야 할 가치가 있는 기술을 개발할 능력이라도 좀 있으면 좋겠다. =_=;;

* 끝으로, 국정원과 아무 관계 없는 여담..;;
국정원은 영어로 national intelligence service여서 영어 이니셜이 NIS이다.
그런데 본인이 난생 처음으로 본 NIS라는 글자는 페르시아의 왕자 2의 구성 파일 중 하나인 NIS.DAT였다.
크기가 거의 1MB에 달하고 아마 가장 큰 파일이었는데, 이름의 의미는 무엇인지 모르겠지만 컷씬 그래픽이 들어있었다.
20여 년 전에 페르시아의 왕자 2를 디스켓으로 불법복제를 해 봤기 때문에 인상적인 파일 이름을 아직까지 기억하고 있다.

Posted by 사무엘

2015/08/15 08:39 2015/08/15 08:39
,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1127

한때 Windows에서 바탕 화면에 배경 그림을 표시하는 방식은 '바둑판, 화면 중앙, 화면 크기에 맞춤'이라는 딱 세 가지 중 하나를 선택할 수 있었다.
이것은 GDI에서 직사각형 영역에다 비트맵을 뿌리는 함수로 치면 각각 PatBlt, BitBlt, 그리고 StretchBlt에 대응한다. 지금은 몇 가지 방식이 더 나오는데, 그건 그림의 종횡비와 화면의 종횡비가 다를 때 확대를 어떻게 할지를 결정하는 것이므로 개념적으로 StretchBlt에 대응하는 셈이다.

GDI에서 비트맵 그래픽을 표현하는 추상적인 핸들 자료형은 잘 알다시피 HBITMAP이다. 그러나 위의 세 *Blt 함수들 중 어느 것도 HBITMAP을 인자로 받지 않는다. 이는 어찌 된 일일까?
이들은 비트맵을 자기들이 처리하기 용이한 형태로 바꾼 파생 자료형을 대신 사용한다. PatBlt를 사용하려면 뿌리려는 비트맵을 브러시로 바꿔야 하며, BitBlt와 StretchBlt는 해당 비트맵에 대한 그래픽 조작이 가능한 메모리 DC를 추가로 준비해야 한다. 그럼 그 구체적인 내역을 살펴보자.

모노크롬 아니면 16색 그래픽이 있던 시절, 도스용 그래픽 라이브러리에는 8바이트로 표현되는 8*8 단색 패턴이라는 게 있었다. 그 작은 공간으로도 벽돌, 사선 등 생각보다 기하학적으로 굉장히 기발한 무늬를 표현할 수 있었다.
Windows는 2000/ME까지만 해도 배경 그림은 오로지 BMP만 지원했으며(액티브 데스크톱을 사용하지 않는 한), 배경 그림이 차지하지 않는 나머지 영역은 그런 무늬로 도배하는 기능이 있었다. 물론 이것은 트루컬러 그래픽과는 영 어울리지 않는 낡은 기능이기에, XP부터는 깔끔하게 없어졌다.

사용자 삽입 이미지

PatBlt는 직사각형 영역을 주어진 브러시로 채우는 함수이다. 즉, 이 함수가 사용하는 원천은 함수의 별도 인자가 아니라 해당 DC에 선택되어 있는 브러시이다. 그럼 얘는 Rectangle이나 FillRect와 하는 일이 거의 차이가 없는 것 같아 보인다. 이 세 함수의 특성을 표로 일목요연하게 정리하면 다음과 같다.

  PatBlt FillRect Rectangle
경계선을 current pen으로 그음 X X O (유일)
경계면을 current brush로 채움 O No, brush를 따로 인자로 받음 O
사각형 좌표 지정 방식 x, y, 길이, 높이 RECT 구조체 포인터 x1, y1, x2, y2 (RECT 내용을 풀어서)
래스터 오퍼레이션 지정 O (유일) X (= PATCOPY만) X (왼쪽과 동일)

다들 개성이 넘쳐 보이지 않는가? =_=;;
Rectangle은 선을 긋는 기능이 유일하게 존재하며, FillRect는 유일하게 사용할 브러시를 매번 인자로 지정할 수 있다. 그 반면 PatBlt가 유일하게 갖추고 있는 기능은 래스터 오퍼레이션인데, 사실 이것이 이 함수의 활용도를 크게 끌어올려 주는 기능이다. 이에 대해서도 앞으로 차차 살펴보도록 하겠다.

브러시는 '2차원 면을 바둑판 형태로 채우는 어떤 재질'을 나타내는 GDI 개체이다. 가로선· 세로선· 대각선 같은 간단한 무늬는 CreateHatchBrush로 지정 가능하지만 이건 오늘날에 와서는 영 쓸 일이 별로 없는 모노크롬 그래픽의 잔재이다.
CreateSolidBrush는 아무 무늬가 없는 순색 브러시를 표방하긴 하지만, 그래도 16/256컬러 같은 데서 임의의 RGB 값을 넘겨 주면 단순히 가장 가까운 단색이 아니라 ordered 디더링이 된 무늬가 생성된다.

그리고 다음으로 비트맵으로부터 브러시를 생성하는 함수는 바로 CreatePatternBrush이다.
여기에서 사용할 비트맵은 가장 간단하게는 CreateBitmap이라는 함수를 통해 생성할 수 있다. 이 함수가 인자로 받는 건 비트맵의 가로· 세로 크기와 픽셀 당 색상 수, 그리고 초기화할 데이터가 전부이다. 아주 간단하다.

그러나 이 비트맵은 그냥 2차원 배열 같은 픽셀 데이터 덤프 말고는 그 어떤 정보도 담겨 있지 않으며, 이걸로 만들 수 있는 건 구조가 극도로 단순해서 어느 그래픽 장비에서나 공통으로 통용되는 모노크롬 비트맵뿐이다. 즉 그 도스 시절의 8*8 패턴 같은 극도로 단순한 비트맵만 만들 수 있다. 오늘날에 와서 CreateBitmap은 모노크롬 비트맵 생성 전용이라고만 생각하면 된다.

모노크롬 비트맵을 기반으로 만들어진 DC나 브러시는 다른 solid/hatched 브러시와는 달리 자체적으로 색상 정보가 담겨 있지 않다. 그렇기 때문에 이때는 그래픽을 뿌리는 DC가 갖고 있는 텍스트의 글자색(값이 0인 곳)과 배경색이(값이 1인 곳) 양 색깔로 선택된다는 점도 참고하자. MSDN에 명시되어 있다. (0과 1 중 어느 게 글자인지 이거 은근히 헷갈린다. 빈 배경에서 뭔가 정보가 있다는 관점에서는 1이 글자 같아 보이기도 하니 말이다.)

그리고 브러시는 origin이라는 게 있어서 어떤 경우든 이를 원점으로 하여 바둑판 모양으로 뿌려진다. oxoxoxox라는 무늬가 있다면, 0,0부터 8,0까지 뿌린다면 oxoxoxox로 뿌려지지만 1,0부터 9,0까지 뿌린다면 ox가 아니라 xoxoxoxo가 된다는 뜻이다.

모노크롬이 아닌 컬러 비트맵을 저장하고 찍는 절차는 좀 복잡하다. 이미 컬러를 표현할 수 있는 DC로부터 CreateCompatibleDC와 CreateCompatibleBitmap을 거쳐서 비트맵을 생성해야 한다. 아니면 CreateDIBitmap를 써서 DIB라 불리는 '장치 독립 비트맵' 정보로부터 HBITMAP을 생성하든가.. 얘는 그냥 비트맵 데이터뿐만 아니라 팔레트 정보 같은 것도 담긴 헤더를 인자로 받는다. 출력할 그래픽 데이터와 출력 매체의 픽셀 구조가 다를 때를 대비해서 추상화 계층이 추가된 것이다.

원래 패턴 브러시는 8*8의 아주 작은 비트맵만 취급할 수 있었다. 그러나 NT 내지 95 이후의 버전부터는 그 한계가 없어지면서 브러시와 오리지널 비트맵 사이의 경계가 좀 모호해졌다. 그래도 PatBlt는 작은 비트맵 무늬 위주의 브러시를 래스터 오퍼레이션을 적용하여 그리는 용도에 원래 최적화돼 있었다는 점을 알아 두면 되겠다.
윈도우 클래스를 등록할 때 우리는 WNDCLASS의 hbrBackground 멤버를 흔히 (HBRUSH)(COLOR_WINDOW+1) 이런 식으로 때워 버리곤 하는데, 여기에다가도 저런 패턴 브러시를 지정해 줄 수 있다. 그러면 그 윈도우 배경에는 자동으로 바둑판 모양의 비트맵이 배경으로 깔리게 된다. 이런 식의 활용도 얼마든지 할 수 있다.

한편, 비트맵을 찍는 동작에는 그냥 있는 그대로 뿌리는 것뿐만이 아니라 래스터 오퍼레이션을 통해 반전을 해서 찍기(PATINVERT), 타겟 화면을 무조건 반전시키기(DSTINVERT), 타겟 화면을 무조건 검거나 희게 바꾸기 같은 세부 방식의 차이가 존재할 수 있는데, 앞서 언급한 FillRect뿐만 아니라 InvertRect나 DrawFocusRect 같은 함수도 사실은 PatBlt의 기능을 이용하여 다 구현 가능하다. cursor를 깜빡거리는 건 두 말할 나위도 없고 말이다.

임의의 색깔로 음영을 표현하는 것이라든가, 특히 이동이나 크기 조절을 나타내는 50% 반투명 검은 음영 작대기/테두리는 모두 이 함수의 xor 래스터 오퍼레이션으로 표현된다. 그걸 구현하는 데는 PatBlt 말고는 선택의 여지가 없다는 뜻. 흑백을 xor 연산 시키면 "원래 색 & 반전색"이 교대로 나타나니까 말이다.

사용자 삽입 이미지
물론 요즘은 (1) 걍 테두리 없이 해당 개체를 즉시 이동이나 크기 조절시키는 것으로 피드백 또는 (2) 알파 블렌딩을 이용한 음영이 대세가 되면서 전통적인 xor 음영은 점점 비중이 줄어들고 있긴 하지만, PatBlt 함수는 그래도 이렇게 유용한 구석이 있다.

이런 PatBlt에 반해 BitBlt는 비트맵을 SelectObject시킨 DC를 원본 데이터로 사용하기 때문에 컬러 비트맵의 출력에 더 최적화되어 있다. PatBlt처럼 비트맵을 바둑판 모양으로 반복 출력하는 기능은 없으며, 딱 원본 데이터의 크기만큼만 출력한다. PatBlt와는 달리 고정 origin이 없고 사용자가 찍으라고 한 위치가 origin이 된다. StretchBlt는 거기에다가 확대/축소 기능이 추가됐고 말이다.

이 정도면 비트맵 API에 대한 개념이 충분히 숙지될 수 있을 것이다. 각종 아이콘과 마우스 포인터들도 다 마스크 비트맵 AND와 컬러 비트맵 XOR이라는 래스터 오퍼레이션을 통해 투명 배경 내지 반전을 구현한다는 건 두 말하면 잔소리이다. 물론 오늘날은 알파 채널로 투명도를 구현하면서 래스터 오퍼레이션의 의미는 다소 퇴색했지만 말이다.
그럼 이제 비트맵 API들에 대한 개인적인 의문점과 아쉬운 점을 좀 나열하며 글을 맺겠다.

(1) GDI는 후대에 등장한 다른 그래픽 API들과는 달리, 글꼴을 제외하면 벡터와 래스터 모든 분야에서 안티앨리어싱과는 담을 싼 구닥다리 API로 전락해 있다. 그러니 비트맵을 정수 배가 아닌 확대/축소를 좀 더 부드럽게 하거나, 아예 임의의 일차변환을 한 모양으로 출력하려면 최소한 GDI+ 같은 다른 대체제를 써야 한다.

(2) 운영체제가 가로줄, 세로줄 같은 몇몇 known pattern에 대해서 CreateHatchBrush 함수를 제공하긴 하는데, 50% 음영 정도는 오늘날에도 많이 쓰이기 때문에 known 패턴이 좀 제공되어야 하지 않나 싶다. 그게 없어서 수많은 프로그램들이 내부에 0x55, 0xAA 배열을 일일이 생성해서 패턴을 만드는 것은 낭비이다.
오히려 cursor는 CreateCaret 함수에 (HBITMAP)1을 줘서 50% 음영을 만드는 기능이 있는데, 정작 그건 별로 쓸 일이 없다.

(3) 브러시 말고 펜으로 선을 그리는 걸 xor 반전 연산으로 하는 기능은 없는지 궁금하지 않으신지? 임의의 사선이나 원 테두리를 그렇게 그리는 건 그래픽 에디터를 만들 때도 반드시 필요하니 말이다.
물론 그런 기능이 없을 리가 없다. SetROP2라는 함수로 그리기 모드를 바꿔 주면 된다. 단, 여기서 입력받는 래스터 오퍼레이션 코드는 BitBlt가 사용하는 코드 체계와는 다르다. 비트맵 전송 API들은 화면의 원본 픽셀(D), 그리려는 픽셀(S)뿐만 아니라 패턴(P)이라는 변수가 또 추가되어서 원래는 3변수 코드를 사용한다. BitBlt는 PatBlt가 하는 일까지 다 할 수 있는 모양이다.

Posted by 사무엘

2015/08/12 08:33 2015/08/12 08:33
, , , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1126

타이머 API 이야기

컴퓨터 프로그램이라는 건 원래 처음부터 끝까지 컴퓨터가 그야말로 눈 깜짝할 사이에 전속력으로 실행해 버리는 물건이다. 그러나 컴퓨터에는 정밀한 시간 측정 기능이 있으며, 프로그램이 원하는 경우 자신이 실행되는 주기를 그에 맞춰 인위로 조절할 수 있다.
일명 타이머 기능인데, 이것은 컴퓨터가 액세서리 차원에서 제공하는 부가 기능이 아니라 컴퓨터 자체의 내부 동작 방식의 특성상 컴퓨터가 반드시 갖추고 있는 기능이다. 단적인 예로 난수 생성을 위한 씨앗(= 매번 달라야 하는 초기값)도 내부적으로 재고 있는 시각으로부터 얻을 정도이다.

컴퓨터가 속도가 매우 느리고 자원이 부족하고, 한 프로그램이 컴퓨터의 전체 자원을 독점할 수 있던 옛날에는 매번 타이머를 측정하면서 0.n초가 경과하는 것을 프로그램이 일일이 감시하는 방식으로, 즉 polling 방식으로 동작했겠지만, 지금은 그건 어림도 없는 소리이다. 자기에게 time slice를 주는 운영체제에다가 '알람' 요청을 해서 알람이 왔을 때 동작하게 해야 한다.

Windows에서 이 기능을 사용하는 아주 대표적인 방법은 타이머 API이다. SetTimer, KillTimer와 그 이름도 유명한 WM_TIMER 메시지.
타이머는 그 성격에 따라 게임이나 멀티미디어 재생기 등에서 프레임 간격 유지를 위해 1초에 수십 번씩 돌아가는 (1) 아주 정밀한 놈부터 시작해, 수백 밀리초~수 초 정도의 간격으로 사용하는 (2) 일반적인 타이머, 그리고 드물게는 수 시간~수 일 주기를 갖는 (3) 장기 타이머도 있다. 운영체제의 보급 타이머는 일단은 가성비가 적당히 우수한 '일반적인' 용도에 가장 적합하게 설계돼 있다. 이게 무슨 뜻인지를 설명하면 이렇다.

보급 타이머도 명목상으로는 수십 밀리초 정도의 정밀도를 지원한다. 하지만, WM_TIMER는 WM_PAINT만큼이나 메시지 큐에서 처리 우선순위가 무척 낮은 메시지이기 때문에 컴퓨터가 아주 바쁘고 윈도우 메시지 트래픽이 아주 많을 때는 정밀도가 떨어질 수 있다. 더구나 Windows는 근본적으로 리얼타임 운영체제가 아닌 관계로, 커널의 시간 스케줄링을 초월해서까지 무조건적인 초정밀도는 애초에 보장되지도 않는다. 타이머의 정밀도가 올라갈수록 필요한 시스템 자원과 부하도 더 커질 테니, 초정밀 타이머가 필요하다면 QueryPerformanceCounter나 멀티미디어 타이머 같은 다른 전문 API를 쓰고 동기화도 커널 오브젝트 같은 다른 방법을 써서 해야 한다.

한편, 다른 쪽 극단에 있는 장기 타이머는 응용 프로그램 자체의 동작이라기보다는 업데이트 주기를 체크하거나 사용자에게 적당히 덜 성가신 주기로 뭔가를 알리는 용도로 사용된다. 이 정도면 타이머라기보다는 알람에 더 가깝다.
개인적으로는 지금으로부터 "5000밀리초 간격으로" 같은 것 말고, 절대적인 시각.. 예를 들어 1970년 1월 1일 0시 정각 이래로 40억 5800만 초가 딱 경과했을 때처럼 절대적인 시각을 기준으로 trigger되는 진정한 '알람' 타이머도 필요하다고 생각한다.

시계 프로그램을 만들 때는 이런 타이머 API가 더 유용하지 않겠는가? 그리고 장기 타이머를 사용할 정도의 상황이라면 지금으로부터 시간이 얼마만치 지났는지보다는 매일 몇 시가 됐는지가 더 중요한 경우가 많을 것이기 때문이다.

이렇게 극단적으로 짧은 주기의 타이머나 극단적으로 긴 타이머 말고, 보통 주기의 타이머는 여러가지 용도로 쓰인다. 가령, 키보드는 누르고 있는 동안 키 입력이 하드웨어 차원에서 자동으로 반복 전달되는 반면 마우스는 그런 게 없는데, 마우스를 누르고 있는 동안 자동 스크롤이 되는 것은 타이머로 처리가 가능하다. 그리고 간단한 비동기적인 처리를 위해서도 타이머가 약방의 감초처럼 쓰인다.

이게 도스의 제약인지 아니면 인텔 x86 CPU 차원의 제약인지 구체적인 내역은 기억이 안 나지만, 도스 시절에는 컴퓨터의 타이머 해상도가 1/18.2초여서 최소 주기가 약 55밀리초였던 것 같다. Windows 9x 시절에만 해도 운영체제의 타이머의 정밀도는 그 정도였다고 MSDN에 기록돼 있었는데 NT 계열은 하드웨어를 또 어떻게 튜닝했는지 타이머가 그것보다 훨씬 더 정밀해졌다.

자, 그럼 이 글에서는 Windows의 일반 타이머 API에 대해서 더 자세히 알아보자.
SetTimer 함수의 인자로는 타이머의 발동 주기뿐만 아니라 (1) 타이머를 메시지로 받을지 아니면 함수 호출로 받을지, (2) 그리고 메시지로 받는 경우 동일 메시지에서 이 타이머만을 식별할 번호를 지정하면 된다. SetTimer 함수는 사용하는 방법이 생각보다 좀 복잡하다.

(1) SetTimer에다가 뭔가 윈도우 핸들을 전해 주는 경우, 타이머는 메시지로 받을 수도 있고 콜백 함수로 받을 수도 있다. 두 가지 선택의 여지가 있으며, 타이머 식별 번호는 우리가 임의의 자연수로 일괄 지정해 줄 수도 있다.
(2) 그 반면 윈도우 핸들이 없이, 윈도우를 전혀 생성하지 않고도 타이머를 사용할 수 있다. 그 대신 이때는 몇 가지 제약이 따른다. 메시지가 아닌 콜백 함수로만 통지를 받을 수 있으며, 타이머 식별자는 우리가 지정할 수 없다. SetTimer 함수가 되돌린 값을 별도의 변수에다 보관하고 있어야 한다.

마치 에디팅 엔진의 기능만을 따로 떼어서 windowless 리치 에디트 컨트롤이 존재하는 것처럼 타이머도 windowless 타이머가 존재하는 셈이다. 물론 SetTimer가 무슨 스레드를 만들기라도 해서 따로 돌아가는 건 아니기 때문에, 비록 windowless 타이머를 사용한다 하더라도 메시지 loop은 돌리고 있어야 타이머가 동작할 수 있다.

개인적으로는 (1)과 (2)의 특징을 취합하는 방법이 없는 게 아쉽다. 윈도우 핸들을 지정해 줘서 WM_TIMER 메시지를 받는데 타이머 식별자는 내가 일괄 지정한 게 아니라 운영체제가 기존 타이머들과의 충돌을 피해서 동적으로 배당한 값이 오는 형태 말이다.
서브클래싱 내지 후킹을 한 윈도우에 대해서 타이머를 걸 때는 하드코딩된 타이머 ID를 써서는 안 된다. 원래의 윈도우 프로시저가 사용하는 고정 타이머 ID와 충돌을 일으킬 수 있기 때문이다. 마치 윈도우 메시지가 서로 충돌하는 것처럼 말이다.
이때는 충돌이 없음이 보장되는 windowless 타이머를 써야 한다. 하지만 windowless 타이머는 다음과 같은 이유로 인해 사용이 불편하다.

첫째, 콜백 함수에 user data를 넘겨 주는 추가 인자가 없다. 그래서 user data는 전역 변수나 TLS 값 같은 불편한 방법으로 얻어 와야 한다.
둘째, 윈도우가 붙은 타이머는 같은 ID값으로 타이머를 지정하는 경우, 기존 타이머가 새 타이머로 자동으로 대체된다. 그러나 windowless 타이머는 그런 기능이 없기 때문에 기존 ID에 대해서 KillTimer를 하고 다시 SetTimer를 해서 새 ID를 얻는 작업을 수동으로 해 줘야 한다. 다시 말해 기존 타이머의 재지정이 어렵다.

결국, 충돌을 피하기 위해서는 windowless 타이머를 써야 하는데 이 타이머도 윈도우가 붙은 타이머하고 비슷하게 동작하도록 추가 군더더기 기능을 구현한 클래스를 만든 뒤에야 그럭저럭 쓸 만하게 됐다.
윈도우가 있는 타이머와 없는 타이머에서 서로 필요한 기능을 취합하는 방법이 없어서 불편하다는 걸 다시 한 번 확인할 수 있었다.

그나저나 SetTimer 함수에서 ID를 받는 부분은 포인터나 핸들을 넘기는 용례가 없는데 자료형이 왜 UINT가 아닌 UINT_PTR로 잡혀 있는지 이것도 개인적으로는 의문이다.

Posted by 사무엘

2015/08/09 08:21 2015/08/09 08:21
, , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1125

1. 우리말에서 "교장 선생님 말씀이 계시겠습니다"는 높임법이 잘못 적용된 비문이다. 그러나 성경에서 "처음에 말씀이 계셨느니라"(요 1:1)는 높임법이 아주 적절하게 쓰인 문장이다.
사실, '말씀'이나 '지옥' 같은 단어는 성경 용어로서 어쩌면 영어 단어보다도 잘 번역되고 잘 만들어진 단어이다. 성경 번역 같은 데서 영어에 비해 한국어의 어휘와 문법의 한계가 많은 편이지만, 그래도 한국어가 오로지 약점밖에 없는 건 또 아니다.

2. 여느 관광 여행이나 맛집 방문 같은 것이야 당연히 백문이 불여일견이며, 직접 가서 겪어 보고 체험하는 것이 더 낫다. 그런데 글을 통한 간접 체험이 당대의 직접 체험보다 더 확실하고 더 낫다고 보증이 돼 있는 유일한 예외가 있다. 무엇일까? (힌트: 벧후 1:19, 요 20:29)

3. 세상의 다른 고전 문헌이나 골동품은 아무래도 제일 오래 된 필사본이 원문, original에 가장 근접해 있을 거라고 여겨진다. 그렇기 때문에 그런 것들은 나이가 깡패이다.
그러나 이 책만은 애초에 오래 된 필사본 같은 건 닳아 없어지고 남아 있질 않으며, 반대로 최근까지도 잡초처럼 많이 필사되어 읽히고 내용이 일치하는 것으로 교차 검증된 집단이 진본이다. 어렵게 생각할 것 없다.

4. 세상의 다른 모든 텍스트들은 원어가 당연히 원저자의 의도에 가장 근접해 있고 가치가 가장 높다. 그래서 예전에 일본어 중역이던 텍스트가 나중에 직통 번역으로 재출간되고, 그 분야 전문가는 아예 원어를 공부해서 원문을 다시 구해다 읽는다.
그러나 이 책만은 번역본이 원어 원문에 꿀릴 게 없으며, 오히려 다른 n차 파생 번역본을 모두 판단하는 절대 기준이 되는 번역본을 보유하고 있다. 이건 무엇일까?

1과 2, 그리고 3만 해도 불신자의 통념을 한참 거스르며 상식을 벗어난 논리이다. 기독교는 원래 그런 종교이다.
그러나 반대로 1~3을 일단 믿는 사람이라면 4를 믿지 못할 이유는 추호도 없다고 여겨진다. 논리적으로 그렇지 않은가? 안타깝게도 안 그러시는 분도 있지만, 그분의 양심과 믿음이 그러려니 하고 넘길 수밖에.
이것 말고 다른 분야에서도 1~9를 다 믿으면 10도 당연히 믿지 못할 이유가 없는데 도대체 왜 저러시나, 딱히 충분히 대안이 될 만한 논리 체계가 있는 것도 아닌데 싶은 게 있다.

아무리 상수도관에서 깨끗한 물이 만들어져도 가정의 수도관이 더러우면 최종 소비자는 더러운 물을 받을 수밖에 없다. 4는 앞의 다른 명제들을 성립 가능하게 하는 전제조건이라 해도 과언이 아닐 것이다.
그럼 다음으로, 이 4에 대한 보충 설명 차원에서 성경을 구성하는 언어 계층에 대해서 살펴보자.

1. 원어
성경의 '원문'이 기록된 언어이다. 구약은 히브리어(다니엘서 같은 일부는 아람 어라 함), 신약은 그리스어(헬라· 희랍은 그리스와 동의어).
그럼 원어로 원문만 읽으면 끝이고 성경의 내용 전수에 아무 문제가 없을 거라고 생각하기 쉽다. 그러나 현실에서 다음과 같은 이유로 인해 문제가 그렇게 간단하지가 않다.

(1) 오늘날 성경의 최초 자필 원본은 어디에도 남아 있지 않다.
또한 그 어떤 성경 필사본도 단일 필사본에 성경 66권이 온전히 집대성돼 있지 않다. 즉, 이것들은 partial이다. 내용 자체가 변개된 필사본이 있긴 하지만, 변개되지 않은 계열의 필사본이라 해도 결국은 빠짐없이 모아서 짜깁는 과정이 필요하다.

(2) 성경이 기록되던 당시에는 이들 언어가 인지도와 중요성이 있었지만, 지금은 그 원어가 사어가 돼 있다.
여느 언어들이 그렇듯이 원어의 어휘 역시, 같은 단어라도 문맥에 따라 뜻이 달라지는 것들이 굉장히 많다. 이 단어가 여기서는 무슨 뜻인지 분별해 줄 수 있는 절대무오한 권위자 역시 오늘날 존재하지 않는다. 오늘날 사도의 표적이 없는 것만큼이나 존재하지 않는다. 인간이 만든 사전· 어휘집도 100% 믿을 게 못 된다. 그러니 원어 원문만 있다고 해서 장땡이 아닌 거다. 환상을 깨시라.

2. 영어
오늘날 원어 원문이 갖고 있는 위의 문제들을 모두 해결하여 원어(영어) 원문(KJV) 차원의 지위를 가진 절대기준이다. 솔까말 기독교는 논리로만 따지면 권위에 호소하는 오류(?)가 있는 종교인데, 그 원천적인 권위가 무엇인지 정도는 인류 역사를 주관하는 하나님께서 보장을 해 주셔야 하지 않겠는가? 그래야만 그 체계 하에서 최소한의 '논리'와 일관성을 갖추지 않겠는가. 원어 원문 문제를 해결하기 위해서 배교한 불신자 신학자들의 말장난에 의존하지 않아도 되게 말이다.

원어가 불필요하다거나 무의미하다는 게 아니다. 단지 성경의 이 구절에서 이 원어를 어떻게 해석하는 게 맞는지 모르겠으면 KJV의 번역을 보면 된다. 요일 2:23 후반부가 원래 필사본에 있는지 없는지 궁금하면 KJV 구절을 보면 된다는 얘기다. 원어 원문조차도 KJV로 판단 가능하다. KJV는 단순히 가장 뛰어난 번역, 우수한 번역 차원이 아닌 것이다. 관점이 완전히 다르다. 이런 번역본 KJV에 하나님의 영감이 있는 걸까 없는 걸까? 판단은 여러분이.

KJV를 최종 권위로 믿고 안 믿고를 떠나서 신자라면 가슴에 손을 얹고 양심적으로 생각을 해 보시라. 기독교라면 저런 절대 기준이 상식적으로 있어야 하지 않겠는가? 우리가 믿는 건전한 하나님이라면 언어 접근성으로 사람 차별을 하지 않으시며, 그런 것쯤은 보장해 주셨을 것 같지 않은가?

지옥에 대해 경고를 하기 위해 굳이 죽었다가 살아난 사람을 보내서 증언시킬 필요가 없듯(눅 16:27-31),
원어가 무슨 뜻인지 파악하기 위해서 하나님께서 현대인들을 위해 굳이 그 시절의 원어 토박이를 무덤에서 끄집어내어 보내실 필요가 없다. 킹 제임스 성경이 있기 때문이다.
또한, 예수님께서 "나를 본 자는 이미 아버지를 보았거늘"(요 14:9)라고 책망했듯이, 킹 제임스 성경을 읽은 사람은 이미 원어 성경을 읽은 것이나 마찬가지이다. 그런 관계인 것이다. 이런 식으로 성경 언어의 관계는 성경의 여러 비유들을 통해 설명할 수 있다.

3. 자국어
절대 기준인 영어 KJV를 바탕으로 건전한 교리관을 갖춘 양심적인 번역자가, KJV의 표현을 그대로(가령, '유월절' 대신 '이스터', '기뻐하라' 대신 '잘 있으라', 요일 5:6-7도 온전히 갖추고 등) 자국어로 일관성 있는 스타일로 번역할 수 있다. 그 성경은 교회에서 예배를 드리고 복음 전하고 신앙 서적을 만드는 용도로 쓰일 수 있다. 이것은 "신들과 같이", "절대무오한"은 못 되더라도 노아나 욥이 "완전했던" 것과 같은 완성도를 갖췄다.

해당 자국어의 특성을 이용해서 번역을 아주 적절하게 할 수도 있지만(하나님, 말씀, 지옥 등), 어휘와 문법 체계의 특성상, 그리고 해당 언어권의 문화· 관습의 한계로 인해 KJV 특유의 도치나 중의성, 운율, 미묘한 문법 요소들을 다 담지 못할 수도 있다. 그건 해당 언어나 번역자의 자질 문제가 아니다. 성경 강사가 영어 KJV를 참고하여 보충 설명을 해 주면 된다. 마치 데나리온이라는 화폐 단위가 요즘 물가로 얼마 정도라고 얘기하듯이. 오늘날 영어의 지위를 생각하자면 히브리어, 그리스어를 꺼내는 것보다야 상황이 훨씬 더 나아진 것이다.

(그럼 원어에서 영어로 번역될 때는 원어의 모든 뉘앙스가 고스란히 옮겨지는 게 가능했느냐 하는 반문이 있을 수 있다. 이에 대해서는 언어학적인 팩트 답변도 있고, 그것만으로 좀 확신이 안 서서 믿음의 영역으로 그냥 받아들이고 넘겨야 하는 면모도 있다. 이 글에서는 이 정도까지만 얘기하도록 하겠다.)

다만, 각 언어마다 최종 권위가 제각각 또 있는 건 아니다. 그건 최종 권위라는 게 무슨 뜻인지 파악을 못 한 말도 안 되는 소리다. 단지 모든 언어적인 혼란을 일축하는 중심점에 영어 KJV가 있다는 것이 KJV 유일주의 신자의 믿음이다.

'영킹 유일주의자', '이중 영감론자' 등의 누명 내지 딱지에 전혀 움츠러들 필요가 없다. 그럼 그들이 미는 대안은 뭔데? '원어 원문 유일주의자'이건 '영어 숭배자'건 '자국어 만능주의자'이건, 어느 편에 서더라도 그에 대한 멸칭은 얼마든지 지어낼 수 있다. 무엇을 선택하든지 결국은 뭔가를 신념으로 믿는다는 점에서는 똑같다. 마치 무신론도 유신론만큼이나 동일하게 신념이고 신앙인 것처럼 말이다.

그럼 우리는 무엇을 믿어야겠는가? 원어 원문은 앞서 말했듯이 실체가 없으며, 반대로 자국어 최종 권위 운운은 당장 생각해 봐도 말도 안 되는 소리이다. 그러느니 차라리 영어 중심이 가장 현실성 있고 균형 잡혔으며, 실제로 KJV의 출간 이래로 지난 400여 년간 역사적인 증거와 열매도 넘치는 건전한 관점이다. 애초에 예수천당 불신지옥 같은 과격하고 극단적인 교리를 믿는 신자가, 한 성경 역본만이 절대적으로 옳고 이와 일치하지 않는 역본은 틀렸다고 믿지 못할 이유는 단언하건대 절대로 없다.

Posted by 사무엘

2015/08/06 08:31 2015/08/06 08:31
, ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1124

Windows의 역사 회상

1. 공용 대화상자

먼 옛날, Windows 3.0은 최초로 VGA를 지원하고 팔레트 API, 장치 독립 비트맵, MDI 관련 API가 추가되고, RTF 기반 winhelp 도움말이 추가되고, 버튼이 3D 회색으로 바뀌고 시스템 글꼴까지 가변폭으로 바뀌는 등 장족의 발전을 이뤘다. (386 확장 모드는 2.1때 미리 도입됐다고 하니 그건 논외로 하더라도)
그런데, 3.0에 없다가 3.1에서 새로 추가된 기능들도 만만찮았다. 트루타입 글꼴과 OLE야 워낙 잘 알려진 3.1의 신규 기능이다만.. 이것 말고도 오늘날 당연하게 여겨지고 있는 '공용 대화상자' 컬렉션들이 역시 3.1에서 처음 도입되었다.

3.1 이전에는 GetOpenFileName 함수가 Windows API에 없었다는 뜻이다. 파일 열기/저장 대화상자는 응용 프로그램들이 전부 직접 따로 구현해야 했다. MS Office 제품들이 한동안 독자적인 파일 열기/저장 대화상자를 갖추고 있었던 건 운영체제도 Windows 3.1 이전까지는 어차피 해당 기능을 제공하지 않았기 때문이지 싶다. Word, Excel은 이미 1980년대부터 개발되었던 프로그램이니까.
그리고 파일 대화상자뿐만 아니라 색깔 선택, 텍스트 검색, 인쇄 같은 잘 알려진 공용 대화상자들도 3.1에서 처음으로 도입됐다.

옛날 도스 시절에 TUI 내지 GUI를 직접 구현하면서 파일 열기/저장 대화상자도 손수 만들어 본 프로그래머라면 공용 대화상자가 얼마나 혁신적인 물건인지 이해가 될 것이다.
그리고 내 생각엔 아마 ShellAbout 함수도 3.1에 와서야 용례가 완전히 정립되지 않았나 싶다. 3.0 때는 응용 프로그램별로 About 대화상자도 서로 다르게 생긴 경우가 있었기 때문이다.

공용 대화상자에 이어 리스트/트리 컨트롤 같은 추가적인 "공용 컨트롤"은 Windows 3.1보다 한 박자 뒤인 Windows 95 내지 NT 3.51과 함께 도입됐다.
물론 일반 사용자에게 와 닿는 Windows 3.0과 3.1의 큰 차이는 저런 기술적인 요소가 아니라... 보조 프로그램으로 리버시(오델로 게임)가 짤리고 그 이름도 유명한 '지뢰찾기'가 대신 도입된 게 아닌가 싶다.

2. 9x와 NT가 따로 놀던 API

과거에 Windows 95와 NT가 공존하던 시절에는 일반적으로 95의 API는 NT의 API에 부분집합으로서 완전히 포함되는 것으로 여겨졌다. 보안이나 유니코드, 일부 고급 기능들이 빠져 있을 뿐, 공통 기능은 동일한 형태로 사용 가능하다는 것이다.
하지만 일부 기능은 95에도 전혀 없는 건 아닌데 NT와는 완전히 다른 형태로 따로 구현되어 API가 파편화되고, 이 때문에 프로그래머들 사이에서 번거로움으로 인해 악명을 떨치기도 했다. 그만큼 Windows 95팀과 NT 팀이 마치 MFC 팀과 Office 팀(리본 UI), Windows 팀과 Visual C++ 팀(CRT DLL)만큼이나 생각만치 교류가 없었다는 뜻이다. 이거 무슨 일본군 육군과 해군도 아니고.

그런 기능으로 무엇이 있느냐 하면 첫째는 사용 중인 파일을 다음 재부팅 때 지우도록 예약하는 기능이요, 둘째는 실행 중인 프로세스와 모듈들을 조회하고 heap 메모리 상태를 조회하는 기능이다.
전자는 NT에서는 MoveFileEx 함수를 쓰면 됐지만 95에서는 그 함수가 지원되지 않았다. 95에서는 wininit.ini라는 살생부 리스트를 수동으로 건드려 줘야 했는데, 이게 처리가 Windows가 아닌 도스 계층에서 행해지는지라 긴 파일 이름을 쓸 수 없어서 더욱 불편했다.

다음 후자의 경우, NT는 커널 API의 연장선 차원에서 EnumProcesses, EnumProcessModules, HeapLock, HeapWalk 같은 함수가 제공되었다. 카테고리의 명칭은 Process status API (PSAPI)라고 불렸다.
그러나 95는 Tool Helper라는 특수한 디버그용 라이브러리 개념으로 CreateToolhelp32Snapshot 이후 [Heap/Module/Process/Thread]32[First/Next] 이런 식으로 함수를 제공했다. 함수를 초기화하고 사용하는 방법이 서로 완전히 딴판이라는 얘기다.

공교롭게도 이 두 기능은 모두 설치/제거 프로그램을 만들 때 필요한 기능이다. "이 DLL은 다음 프로그램이 사용하고 있습니다. 다음 재부팅 때 제거하시겠습니까?"를 구현하려면 말이다. Windows Installer 런타임은 당연히 9x용과 NT용이 이런 점을 감안하여 제각각 구현되어 있었을 것이다.
결국 Windows 2000에 가서야 지금까지 9x에만 있던 tool help library를 NT 계열이 마저 흡수하는 걸로 문제가 종결되었다. 마치 95에서 첫 도입되었던 Plug & play를 드디어 2000이 수용했듯이 말이다. 게다가 궁극적으로는 9x 계열 자체가 없어지기도 했고.

3. 그래픽과 사운드 성능 향상

1990년대 중후반에서 2000년대 초반에 이르기까지 컴퓨터의 성능이 향상됨으로써 Windows에 생긴 3대 변화를 들자면 난 다음을 꼽는다. 예전에 한 번씩은 다 언급한 적이 있었을 것이다.

(1) 화면이 막 고쳐지는 곳으로 마우스 포인터를 가져가도 깜빡임이 없게 되었다. 그래픽 카드가 마우스 포인터 주변은 건드리지 않게 하드웨어적인 처리를 진작부터 하기 시작했기 때문이다. 이것은 요즘 형광등이 깜빡임 없이 바로 켜지기 시작한 것만큼이나 신기한 일이다.

초창기에는 흑백의 기본 포인터만 처리가 되지, 컬러 내지 심지어 애니메이션이 있는 custom 포인터, 그리고 마우스 포인터 자취까지는 차마 깜빡임 방지 처리를 다 못 했다. 그러나 이것도 2000년대부터는 제약이 없어졌다.
Windows 2000은 아예 안전 모드에서 16컬러 VGA로 동작할 때에도 마우스 포인터의 깜빡임이 없는 게 무척 신기하다. NT가 원래 그랬는지 아니면 2000부터 그렇게 된 건지는 모르겠다.

(2) 멀티웨이브가 되기 시작한 것도 아주 신기한 일이다. 지금으로서는 도저히 믿을 수 없는 일이지만 Windows에 사운드/멀티미디어 지원이 처음으로 도입됐던 3.1/95 초창기에는 한 번에 한 프로그램만 사운드 카드의 사용이 가능했다. 그리고 다른 프로그램은 사운드를 이용할 수 없었다! PC에 사운드 카드가 버젓이 달려 있음에도 불구하고 사운드 초기화가 실패하는 상황에 대한 대비를 해야 했던 것이다.

9x 시절에는 일부 고급형 사운드 카드만이 멀티웨이브가 가능했다가 2000부터는 드디어 그냥 아무데서나 멀티웨이브가 가능해졌다. 이쯤에서 미디 역시 노래방 수준의 소프트웨어 신시사이저로 대체되었고 XP쯤부터는 오디오 CD까지 모든 사운드의 음원이 waveform으로 통합되었으며, Vista부터는 장치가 아닌 스피커/응용 프로그램별로 구분해서 볼륨을 지정하는 게 가능해졌다.

오늘날도 PC에 따라서는 출력 단자에 헤드폰/스피커 같은 게 전혀 연결돼 있지 않으면 사운드의 초기화가 실패하는 경우가 있다. 물론 PC 자체에 스피커가 달려 있는 노트북 PC에서는 해당사항이 없는 얘기. 옛날에도 입력 단자를 감지해서 녹음 버튼의 성공/실패를 감지하는 것 정도는 가능했던 것 같다.

(3) 그리고 제일 늦게 생겼고 Windows Vista가 이뤄낸 쾌거 중 하나는 역시 동영상 장면도 Print screen으로 간단히 캡처가 가능해졌다는 점이다. 창을 움직였는데 동영상 영역은 제대로 움직이지 않는다거나, 화면 캡처를 하면 그냥 컬러 키를 나타내는 이상한 단색만 캡처된다거나.. 이런 것도 이미 10년쯤 전부터 옛날 추억이 됐다.
기술적으로 따지고 보면 동영상만 추가적인 하드웨어 가속을 받는 게 아니라 아예 모든 그래픽이 동등하게 하드웨어 가속을 받기 시작했기 때문이다. GDI조차도 그 위에서 돌아가니까 BitBlt 같은 GDI API로 간단하게 캡처가 되기 시작한 것이다. 게다가 Vista가 처음으로 선보인 flip3d나 live preview에도 동영상이 실시간으로 표시되기 시작했다.

4. Windows 10

그리고 그 Windows 95가 출시된 지 거의 20년이 지난 지금, Windows 10이 출시되었다. 95 출시 당시에 중학생이던 본인은 뭐 이미 30대 중반의 성인이 됐고.
2015년에 마소 소프트웨어의 최대의 이슈는 단연 새 운영체제와 새 개발툴이다. Windows 10과 Visual Studio 2015.

IE가 11에서 종결되고 Edge로 넘어가는 것만큼이나 마소에서는 Windows 10이 독립된 브랜드 형태로는 Windows의 마지막 버전이 될 것이고 그 뒤로는 그때 그때 인터넷 업데이트만으로 유지보수를 할 것이라고 밝혔댄다.. 그 정책이 실제로 언제까지나 유지될지는 모르겠다.

하긴, 매번 XP, Vista 같은 브랜드명에다 숫자에다.. 이런 발상 자체가 식상해지고 아이디어가 고갈될 때도 되긴 했다.
허나 과거에 마소 내부에서는 IE 팀이 Windows 팀으로 합병될 뻔한 적도 있었고, 또 이미 윈도 7 시절부터 이건 NT 커널 기반 Windows의 마지막 버전이고 그 뒤로는 Midori던가 뭐던가 완전히 새로운 기반의 운영체제가 나온다는 식의 설레발도 나돌았다. 트렌드라는 건 언제든지 얼마든지 바뀔 수 있는 것이니 변화를 신중하게 지켜봐야겠다.

그래도 마소에서 이번 Windows 10을 뭔가 완결판이라는 컨셉을 두고 만들었다는 티가 벌써부터 팍팍 느껴진다.
외형이 8하고 별 차이가 없는 줄 알았는데, 프로그램의 제목이 가운데 정렬이던 것이 다시 왼쪽으로 복귀한 건 좀 사소한 점일 테고. ㅋㅋ
그리고 운영체제의 버전뿐만 아니라 커널의 내부 버전 번호도 Vista 이래로 지금까지 6이던 것이 7~9를 건너뛰고 10으로 맞춰졌다.
Windows 10이 저런다고 하니까 마치 Mac OS X 같은 느낌도 든다. 저 X도 10을 나타내니까.. 인터넷을 뒤져 보니 당연히 나만 그렇게 생각한 게 아니었다.

한편, Visual Studio의 경우, 2012 이래로 외형 색상의 변화는 크게 없다. 그럼 그렇지, 매 버전마다 비주얼을 다 뒤집어 엎는 것도 언제까지나 가능한 건 아니겠지 싶었다. ^^ 2013 커뮤니티 에디션이 나온 것부터가 굉장히 놀라웠는데, 갈수록 개방적으로 바뀌는 한편으로 이클립스 내지 xcode의 전통적인 영역까지 넘보고 있다.
운영체제, 브라우저, 개발툴에서 모두 마소가 종전의 소프트웨어 개발 방식 내지 패러다임을 종결하고 단절하겠다는 의지를 표현한 듯하다. 확실히 변해야만 살아남을 수 있다.

Posted by 사무엘

2015/08/03 19:38 2015/08/03 19:38
, , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1123

다음 버전 개발 근황 약간

요즘 날씨는.. 최악의 불볕과 최악의 찜통은 별개 개념이라는 걸 온몸으로 입증해 보이는 듯하다. 미치겠다.;;
이렇게 이번 여름방학도 벌써 절반이 넘게 지났고 <날개셋> 한글 입력기 8.0이 나온 지도 역시 한 달이 좀 넘었다. 그 동안 서적 번역 등 다른 일에 관심이 쏠려 있어서 방학 전반부 동안은 사소한 이슈 말고 굵직한 기능을 설계하고 구현하는 코딩은 거의 못 하고 지냈다.

그래도 지금까지 지켜본 바로는 8.0은 별다른 새로운 버그 없이 높은 완성도로 잘 만들어졌다. 이 프로그램도 가까운 미래에는 꿈에도 그리던 전체 신규 기능 개발 완료와 고정· 정착 단계에 진입하는 게 아주 요원한 꿈은 아닐 것 같다.
국민 교육 헌장을 보면 "안으로 자주독립의 자세를 확립하고, 밖으로 인류 공영에 이바지할 때"라고 나와 있는데, 실상은 "안으로는 약 빨고 밖으로는 외계인 고문을 일삼으면서" 결과물을 내야 할 거 같다.

본인은 석사를 졸업한 지 이제 3년이 지났다.
석사 논문은 아시다시피 저 입력기의 이론적 배경과 구조, 주요 기능이 주제였다. 지금 동일 주제로 논문을 다시 쓰면 그때보다 수십까지는 아니어도 10수 페이지 정도는 더 써 넣을 분량이 있다.

가령, 다음 글자로 넘어갔을 때도 초성이 아니라 변함없이 종성 문맥으로 동작하는 '종성 지향 두벌식'은 6.7 버전에서 첫 도입되었으며 <날개셋> 한글 입력기의 역사에서 무척 중요한 위치를 차지하는 기능이지만, 논문이 다 완성되고 졸업하자마자 그 직후에야 추가된 기능이다. 그러니 논문엔 못 들어갔다.

7.9와 8.0대에서는 종성 지향 두벌식의 정반대 이념이며 두벌식 연구자의 떡밥이던 '초성 지향 두벌식'까지 추가되었다. '살 → 사라'가 아니라 반대로 '사ㄹ → 살ㅈ' 이런 식으로 되는 입력 방식 말이다.
전자는 별도의 날개셋문자 타입으로 구현된 반면, 후자는 '고급 입력기'가 제공하는 낱자 치환 옵션의 일환으로 구현되었다. 기술 계층이 서로 완전히 다른 것이다.

또한 그때 이후로 키보드 입력이라는 물리적인 프로세스 자체에 대한 기술적 이해도가 더 깊어진 덕분에, 키 입력을 흉내 내는 기능이 독립된 날개셋문자 타입으로 추가되었다. 최근에는 입력 패드 구현체가 그런 키보드 입력이 드디어 지원되기 시작한 쾌거도 이뤘다.
이런 것들이 논문에 더 들어갈 수가 있었다는 뜻이다. 박사 졸업 이수 요건에 속하는 학술지 소논문에 이런 걸 적절히 투고할 방법이 있으면 좋겠다. 엄연히 국어 정보학과 관련된 개인적인 연구 실적이니까.

  1. 한글의 고유한 특성과 활용 가능성: 한글은 IME가 필요한 복잡한 스케일의 문자이지만 중국· 일본어처럼 문장 단위가 아니라 1글자 단위로만 조합을 잡으면 된다. 이렇게 한글 같은 문자만이 처해 있는 특수한 상황에서 IME만이 제공할 수 있는 여러 편의 기능이 있을 것이다.
  2. 세벌식의 우수성: 두벌식은 자음 종류 구분과 음절 경계 구분을 위한 온갖 테크닉이 필요하다. 그러나 세벌식은 그게 기본적으로 되기 때문에 타자기나 두벌식에서는 불가능한 다른 응용 기능을 언어 의존적인 데이터 없이 바로 구현할 수 있다. PC에서 세벌식 입력 방식이 없다는 건 말이 안 된다.
  3. 이 시스템의 엔진의 독창성: 한글 입력 방식을 규정하는 모든 세부적인 동작을 customize할 수 있으며, 그 과정에서 두-세벌의 중간에 속하는 입력 방식도 구현 가능하다.
  4. 이 시스템의 구현체의 독창성: 이 엔진을 편집기, IME, 입력 패드라는 다양한 기술적인 구현체를 통해 제공한다.

지금 논문을 다시 쓴다면 내가 주장하고자 하는 바를 위와 같은 네 카테고리로 더 분명하게 구분해서 깔끔하게 결론이나 초록을 썼지 싶다. 뭐 그건 이미 다 지난 일이고...
난 다음 박사 논문을 위해서는 "한글의 고유한 특성과 활용 가능성"이라는 기본 명제는 동일하지만, 입력이 아닌 출력에 속하는 한글 글꼴과 관련된 연구를 할 생각이다. 그러니 입력기는 빨리 마무리를 좀 지어야 한다.

논문 얘기가 너무 길어졌는데, 어쨌든 <날개셋> 한글 입력기의 다음 버전에서 만날 수 있는 사소한 변화들을 늘어놓으면 다음과 같다.

1. 이제는 프로그램을 설치할 때, 원하는 구현체만 선택해서 설치할 수 있게 했다.

사용자 삽입 이미지

세 구현체들의 특징은 다음과 같이 표로 일목요연하게 정리된다.

항목 편집기 외부 모듈 입력 패드
형태 EXE (32/64비트 하나만) DLL (32/64비트 모두) EXE+DLL (각각 32/64비트 모두)
도스용 프로그램에 비유 자체한글 에디터 한글 바이오스 (입력 부분만) 램 상주 키보드 인터럽트 유틸리티
기능 지원 범위 오로지 자기 내부 자기를 사용하는 타 프로그램 내부 실행 중인 모든 프로그램들
TSF A급 O △ (동작 환경에 따라 다름) X
Alt 지원 O X O
특이사항 자체 옛한글 글꼴, 텍스트 필터, 키 입력으로 붙여넣기. 성능 오버헤드가 가장 작음 명령 프롬프트 및 Metro UI에서 유일하게 동작 가능 구현체들 중 크기가 가장 작고 가벼움. 키보드 모드는 옵션으로 제공


2. 웹 브라우저 같은 외부 프로그램의 텍스트를 <날개셋> 편집기의 빈 문서 창에다가 drag & drop을 하고 나면 가끔 편집기의 프레임이 고전 테마 형태의 이상한 모양으로 일시적으로 바뀌는 문제가 있었다. 개인적으로는 운영체제의 버그에 가깝다고 생각하는 현상이지만 Windows Vista부터 8.1까지 일관되게 발생하는 현상이고, 또 문제를 회피하는 방법도 있으므로 그걸 적용했다.

사용자 삽입 이미지

3. 도움말에서 "외부 모듈 → 알려진 버그" 부분에, 키보드 보안 프로그램으로 인한 오동작 가능성을 더 자세히 언급했다. 이런 문제가 있을 수 있는 프로그램은 크게 "IE 브라우저"뿐만 아니라 요즘은 "온라인 게임"이 더 중요하다. IME도 나름 키보드 입력을 가로채는 프로그램이다 보니, 디지털 서명이 없는 날개셋 같은 프로그램을 여타 보안 프로그램이 차단할 수도 있다.
5년 전에 스타크래프트 2가 출시 직후에 이와 관련된 대표적인 문제를 일으켰었는데, 앞으로 다른 게임에서 이런 부류의 문제가 계속 보고될 수도 있다.

4.
얼마 전, 인디자인 9에서 한글 입력과 관련된 귀찮은 문제가 출판 디자인 업계에서 거론된 적이 있었다. 한글 조합 중에 space, tab 등의 글쇠를 누르면 원래는 한글 조합도 중단되고 해당 글쇠 문자도 뒤에 입력이 돼야 한다. 그런데 인디자인은 이때 조합만 중단되고 해당 글쇠는 씹히기 시작했다. 그것도 예전엔 안 그러다가 최신 버전에서 갑자기 그러기 시작했다. space/tab이 아니라 IME가 인위적으로 처리를 하는 비한글 문자는 씹히는 문제가 없었다(세벌식 자판의 숫자처럼).

그런데 이와 비슷한 문제가 MS Word에서도 부분적으로 발생한다는 것이 최근 확인되었다. "고급 입력기"가 제공하는 사용자 정의 조합이나 한글 출력 치환 기능을 이용해서 평범한 알파벳이나 숫자를 조합하는 상태를 만들고 나면, space, tab을 눌렀을 때 조합만 종료되고 해당 글쇠는 씹힌다. 그 반면, 한글이나 전각, 특수문자, 2글자 이상의 긴 조합을 만들고 있을 때는 그런 현상이 없다! 간단히 "일본어 히라가나/가타카나" 예제 유형만 MS Word에서 사용해 봐도 확인 가능하다.

TSF를 지원하는 다른 모든 프로그램들은 안 그러는데 오로지 MS 워드만 왜 저러는지 나로서는 알 길이 없다. 아니, 애초에 왜 그 타가 씹힐 수가 있는지도 이해가 안 되지만.. 문제의 증상과 해결(회피) 방법이 인디자인과 Word가 동일하기 때문에 도움말에 동일한 항목으로 보충 설명을 넣었다.

5.
끝으로, 시대가 시대이다 보니 About 대화상자에 Windows 10을 인식하는 데이터도 추가했다.
그리고 외부 모듈에서 옛한글을 사용하는 것과 관련된 추가 설명을 UI나 도움말에 넣었다. (시스템 계층에서 한글 표현 방식도 제대로 설정했는지 확인하라, 옛한글 글쇠배열을 가져오기만 하는 것과 빠른설정으로 총체적으로 맞추는 건 다르다 등)
지금까지 두벌식으로 옛한글 글쇠배열을 설정하면 4단 아랫자리에 있는 한쪽이 길쭉한 반치음들은 종성까지 입력 가능한 형태로 배당되었는데, 이제는 그걸 없애고 초성으로만 배당되게 했다. 이들 자음은 어차피 초성 형태밖에 존재하지 않기 때문이다. 종성 표현은 <날개셋> 편집기 내부에서 사용자 정의 영역 글자를 이용해서 편의상으로나 존재한다.

현대 한글 두벌식을 사용할 때는 ㄸ, ㅃ, ㅉ이 받침이 존재하지 않기 때문에 언제나 초성으로만 입력된다.
옛한글 두벌식일 때는 이들은 종성으로도 입력 가능하고 그 대신 반치음들이 그런 형태를 이어받게 되는 것이다.

Posted by 사무엘

2015/08/01 08:38 2015/08/01 08:38
Response
No Trackback , 11 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1122

근황과 잡설

* 이번엔 프로그래밍 말고 다른 분야의 컬렉션이다.

1. 이메일 주소 변경

이미 오래 된 일이지만... 본인은 대외적으로 홍보하고 사용하는 이메일 주소를 올해 상반기부터 드림위즈에서 gmail로 변경했다. <날개셋> 한글 입력기의 도움말에 안내되어 있는 메일 주소도 고쳤다. 지금까지는 영문 홈페이지에다가만 gmail을 안내했지만 이제는 한국어 사이트에다가도 주소를 바꿨다.

변경한 이유는 드림위즈가 이메일을 보내는 본연의 기능이 제대로 동작하지 않기 때문이다.
단순히 서비스가 낙후해 있고 용량이 적고 비번이 8글자까지밖에 입력 안 되는 개막장인 정도여서가 아니다.
메일을 보냈는데 실제로는 상대방에게 메일이 가 있지 않아서 중요한 일정에서 골탕을 여러 번 먹고 나니, 이제는 안심하고 드림위즈 메일을 이용할 수 없어졌다.
지도교수님에게 보낸 수강 관련 중요 메일이 안 가고, 문서 작업 때문에 보낸 초안 원고가 안 가고.. 게다가 늘 발생하는 것도 아니고 진짜 러시안 룰렛마냥 복불복인 것 같다.

예전에 알집이나 알FTP가 왜 욕을 바가지로 먹었던가? 구린 라이선스 정책은 부가적인 얘기이고, 중간에 파일을 잘라먹고 사용자의 데이터를 파괴해 버리는 크리티컬한 버그 때문에 욕 먹었던 것이다. 자기 본연의 기능을 제대로 수행을 못 하니까. 드림위즈 메일도 이와 동일한 이유 때문에 버리기로 했다.
하긴, 주변 지인에게 이걸 얘기하니 돌아오는 반응은 "드림위즈 아직도 살아 있었어?"이긴 했다. =_=;;

gmail은 다 좋지만 국내 포털들과는 달리 간편한 대용량 첨부 기능과 수신 확인 기능이 없는 게 아쉽긴 하다.
대용량 첨부 중에서는 오로지 다음만이 2GB가 넘는 ‘초대용량’까지도 첨부가 된다. 드림위즈와 네이버는 그렇지 않더라.

2. 복날 몸보신

교회엔 내가 철도를 좋아하는 것만큼이나 핫도그(ㄱㄱㄱ, ㄱㅈㄱ 또는 ㅂㅅㅌ의 애칭)에 사족을 못 쓰는 지인이 있다.
난 경험상 개고기는 수육은 좀 느끼한 것 같고 그래도 개장국은 맛있게 잘 먹는다. 양념도 마음에 들고. 개고기는 성경적으로는 하나도 걸릴 것 없으니, 하나님께서 주신 훌륭한 단백질 공급원으로서 말씀과 기도로 성결하게 한 후 먹으면 된다. 난 오히려 청국장이나 홍어 같은 건 못 먹는다.

하긴, 핫도그라 하니까 지금으로부터 100여 년 전의 아문센의 남극 탐험이 생각 난다. 그거야말로 그 당시 장비와 보급 기술만 갖고는 핫도그 없이는 성공할 수 없었다. 아, 거기서는 고기도 다 날것으로 먹었을 테니 '핫'은 아니겠다만.. -_-;;

일단은 개는 극지방에서의 생존성과 수송력 제공 가성비가 말을 훨씬 더 능가했다. 스스로 체온 조절이 가능하고 식량도 사람의 것과 동일했다. 영국의 스콧 팀은 조랑말과 스노우모빌을 운용했지만 둘 다 남극의 혹한 속에서는 죽고 고장나고 피봤다.

아문센 팀은 탐험 과정에서 효용이 떨어진 개들을 사정없이 잡아먹었다. 심지어는 먼저 잡거나 죽은 개의 고기를 다른 개에게 사료로 주기도 했다! 하지만 열량 소모가 극심한 남극에서는 최대한 여유를 갖고 준비한 기존 보급에다 바다표범 현지 조달로도 식량이 부족했고, 그렇게 해야만 살아남을 수 있었다.
스콧과 영국 언론은 영국 신사 드립을 치면서 개썰매나 타고 개고기를 쳐먹은(는) 야만인이라고 아문센을 사정없이 깠다. 그러나 신사면 뭘 하나, 결국 스콧은 아문센과는 달리 남극에서 살아서 못 돌아오고 다 죽었다.

요즘은 고어텍스, GPS, 초고밀도 생존 식품 같은 첨단 기술 덕분에 그때처럼 '서플라이 디팟'을 미리 안 만들고 동력기관이나 동물도 안 쓰고, 심지어 비행기로 실시간 보급조차 안 받고 사람만으로 남극점에 뚝딱 갔다 온다. 하지만 그래도 한여름에만 갈 수 있는 건 변함없으며 1인당 100수십 kg에 달하는 보급 자루를 썰매에다 싣고 질질 끌면서 정말 힘들게 살 잔뜩 빠지면서 갔다 온다.

옛날에 우리나라에서 올림픽을 개최하던 시절엔 "세계가 지켜보고 있습니다" 프로파간다 하에서 손님들의 동선상에 있는 보신탕집들은 강제로 셧다운 당하고, 사철탕· 영양탕 등으로 간판 바꿔 달고 음지에서 영업하던 적이 있었다.;;; 정말로 개고기만 딱히 야만적이고 잔인하다고 볼 이유가 없는데..
오히려 애완견을 집 안에서까지 데리고 와서 키우는 게 성경적으로 당장 대놓고 죄악은 아니더라도 별로 비추에 바람직하지 않은 모습이다. 인간 학살자 독재자들이 이상한 동물 보호론자였다는 점을 차치하고라도 말이다.

개고기는 아무래도 규모의 경제에서 밀리는지라 국밥류로 한 끼 식사 정도 하려면 초밥 정식 먹듯이 1만 몇천 원 이상 들 각오는 해야 한다. 그래서 그런지 여러 사람이 가면 1인 1국밥 식사 대신 야채가 많아서 가성비가 더 높은 전골류를 권하더라.
저 친구가 "맛 한번 보지도 않고 개고기를 반대한다" 이렇게 한탄을 하길래, 모 전대통령의 "나한테 당해 보지도 않고.." 드립이 문득 떠올랐다.

3. 전동차 재림 신앙

언젠가 야근을 마치고 퇴근하던 때의 일이었다. "아차!" 도시락통을 놔 둔 채 전동차에서 내렸다는 걸 알아 챈 건 왕십리 역에서 하차한 지 3분 남짓한 시간이 경과한 뒤였다.
전동차 안에서 노트북 PC로 다른 작업에 너무 집중하고 있던 게 화근이었다. 전동차로부터는 이미 100미터가 넘게 떨어진 상태.

유실물이 있다는 것을 감지한 직후에는 불안과 흥분 때문에 마치 차에 갓 시동을 건 직후처럼 심장 회전 rpm이 치솟았다. 그러나 난 최대한 침착하려 애쓰면서 rpm을 조절했다.
"역무실에다 신고를 해야 할 텐데 이 역에 코레일 역무실은 어디쯤 있더라?"(분당선이므로) 생각을 하면서 다시 코레일 관할 구간으로 갔다.

그런데 생각을 해 보니 왕십리역은 분당선의 시종점이고, 여기는 딱히 차량 기지나 주박 공간이 있지는 않다. 단지 인상선만 있을 뿐.
그러므로 다음과 같은 가설이 도출됐다. 그 열차가 떠난 지 아직 10분도 채 경과하지 않았으니, 내가 탔던 열차는 인상선을 거쳤다가 다시 반대편 승강장으로 곧 그대로 들어올 것이다. 청소부 아줌마는 바닥만 신경쓰지 그 짧은 시간 동안 선반을 일일이 다 살펴보지는 않을 것이다.

그리고 행 1:11 말씀이 내게 평안과 위로를 주었다. "너희 갈릴리 사람들아, 너희가 어찌하여 서서 하늘을 바라보느냐? 너희를 떠나 하늘로 들려 올라가신 이 동일한 예수님께서는 너희가 그분께서 하늘로 들어가심을 본 그대로 오시리라."
그렇다. "너희 전철 승객들아, 너희가 어찌하여 패닉에 빠져 있느냐? 너희를 떠나 인상선으로 들어간 이 동일한 상행 열차는 너희가 봤던 상태 그대로 진행 방향만 바꿔서 하행선 승강장으로 되돌아오리라." 아멘.

상행 열차는 맨 앞칸을 탔으므로 이번엔 난 하행 승강장의 맨 뒷칸에서 다음에 들어올 열차를 기다렸다. 잠시 후 하행 열차가 들어왔고, 그 열차의 선반에 아까 내가 놔 뒀던 도시락통이 있는 걸 창문을 통해 확인했다. 역무실에 연락을 할 필요조차도 없었다.

"그럼 그렇지!" 전동차 재림 신앙은 그 믿음대로 응답되었고 간증거리가 되었다. 지하철 영화 <튜브>에서 위기를 넘겼을 때 통제실 권 실장이 기뻐하던 그 장면이 떠올랐다.
다른 승객들은 열차에 올라타서 자리에 앉았지만, 나는 그 도시락통만 쓱 끄집어 낸 뒤 도로 내렸다. 주변의 다른 승객들은 나의 행동에 저런 배경이 있다는 것을 알 수 없었을 것이다.

Posted by 사무엘

2015/07/29 08:33 2015/07/29 08:33
, ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1121

« Previous : 1 : ... 118 : 119 : 120 : 121 : 122 : 123 : 124 : 125 : 126 : ... 221 : Next »

블로그 이미지

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

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2024/12   »
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:
3054523
Today:
759
Yesterday:
2071