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

0. 들어가는 말

세상에는 누구나 드나들 수 있는 공공장소와 누구나 신호를 주고받을 수 있는 통신망이 있지만, 사람마다 사생활도 있고 비밀도 있다. 이런 게 보장되지 않으면 인간이 정상적으로 살아갈 수 없으며, 사실은 생존에 필요한 기본 욕구를 충족시킬 수도 없어진다.
그렇기 때문에 어떤 장소나 어떤 정보는 내부의 믿을 수 있는 사람, 우리 조직 소속인 사람만 접근할 수 있게 해야 한다.

이를 구현하기 위해 전자에 대해서는 열쇠와 자물쇠라는 게 만들어져 왔고, 후자를 위해서는 암호 기술이라는 게 개발되었다. 열쇠가 없는 사람, 암호를 모르는 사람은 문을 열고 들어갈 수 없고 그 자료를 열람할 수 없다. 심지어 정보가 담긴 매체라든가 물건이 담긴 금고 자체가 유출되더라도 그 안의 물건에 손댈 수는 없다.

열쇠와 암호는 서로 담당하는 영역이 다르지만 심상이 아주 비슷한 구석도 있다. 요즘은 자물쇠도 열쇠 대신 일종의 숫자 암호인 디지털 도어락으로 바뀌고 있고, 암호학에서도 key라는 용어가 즐겨 쓰이니 말이다.

다만, password라는 개념의 '암호'와, 원본 정보를 password 없이는 알아볼 수 없게 변조하는 '암호화'(cryptography, encryption), 그리고 암호화가 적용된 텍스트를 작성하는 것 내지 그 결과물인 암호문(cipher).. 이게 우리말에서는 딱 부러지게 잘 구분되지는 않는다는 점을 감안할 필요가 있다. 마치 '뛰다'(jump/run), '다른'(other/different), '푸르다'(green/blue) 이런 게 잘 구분되지 않는 것처럼 말이다.

보이니치 괴문서처럼 암호 사용 여부와는 무관하게 단순히 체계와 의미가 파악되지 못한 물건도 decipher되지 못했다고 말한다.
그에 비해 한국어 ‘해독’은 동음이의어 한자의 특성 때문에 ‘독’에 read라는 뜻뿐만 아니라 poison이라는 뜻까지 있어서.. 미묘하게 중의적인 심상을 자아낸다. 마치 ‘충전’의 중의적인 심상처럼 말이다. (전기도 충전, 금액도 충전..)

1. 패스워드의 관리, 해시 함수

먼저, 암호화와 무관하게 로그인 패스워드 자체에 대한 보안을 논하는 기본 원칙이 있다. 이 주제에 대해서는 본인이 마지막으로 글을 썼던 때가 무려 7년 전이었구나.;; (☞ 이전 글)
사용자의 입장에서는 “다양한 종류의 문자를 섞어서 최소한 10자 이상의 긴 문자열로 정할 것, 주기적으로 바꿔 줄 것” 이런 게 있다.

물론 누군가의 원한을 사고 있어서 작정하고 당신의 계정을 뚫으려 노력하는 공격자라도 있는 게 아니라면.. 이런 얘기에 지나치게 민감해할 필요는 없다. 암호 좀 허술하게 만든다고 해서 현실에서 당장 위험에 빠지는 건 아니다. 하지만 그렇다고 해서 1234, asdf, iloveyou, 생일, 전화번호 정도로 암호를 너무 성의없게 만드는 건 정말 피해야 한다.

그리고 사용자의 접속 정보를 저장하는 운영자의 입장에서는 암호를 절~대로 평문 그대로 저장하지 말아야 한다. 게다가 암호 문자열이 무슨 도스 시절 파일 이름마냥 10~15자 같은 제약이 걸려 있거나 특정 특수문자 기호를 지정하지 못한다면.. 그건 정말 기본적인 보안 관념도 없던 쌍팔년도 시절 사고방식의 미개한 사이트라고 욕 먹어야 할 것이다.

사용자가 암호를 잊어버렸다면 사이트 운영자라도 그 암호를 알 수 없는 게 정상이다. 본인 인증을 시행한 뒤에 임의로 지정한 새 암호를 알려줘야지, 기존 암호를 그대로 알려주는 사이트는 그 자체가 보안이 매우 허술하다고 실토하는 것과 같다.

그러니 이런 패스워드는 딱히 key 없는 단방향 암호화라는 변조를 거쳐서 저장해야 하는데, 이럴 때 해시 함수라는 게 쓰인다. hash란 어떤 임의의 길이의 원본 문자열이 주어졌을 때 원본과는 완전히 다르고 무질서하게 변조된 다른 고정된 길이의 문자열 내지 바이트 시퀀스를 되돌리는 수학 함수이다. 원본 문자열이 조금만 바뀌어도 완전히 확 달라진 결과값이 나와야 한다.

F(X) → Y인데, 역으로 Y로부터 X를 복원하는 것은 수학적으로 불가능하다. 그리고 F(A) ≠ F(B) 라면 절대적으로 A≠B이지만, F(A)=F(B)이면서 여전히 A≠B일 확률은 매우 매우 낮은 확률로 존재한다. 비유하자면, 퀵 정렬의 시간 복잡도를 n^2로 만드는 input을 우연히 만들 수 있을 정도의 확률로 존재한다.

패스워드의 비교는 사용자가 입력한 문자열을 hash한 결과와, 저장된 패스워드 hash값을 비교함으로써 행해진다. 평문을 비교하는 게 아니라는 것이다.
사실, 이런 해시 함수는 패스워드의 보관뿐만 아니라 방대한 파일이 정확하게 잘 전송되었는지 동등성을 검증하는 용도로도 즐겨 쓰인다. 수 GB짜리 파일의 해시값이 얼마가 나와야 정상인데 엉뚱한 값이 나왔다면 중간에 오류가 있었다는 뜻이 되기 때문이다.

해시 함수가 튼튼하고 안전하려면 (1) F(X)로부터 X를 역으로 추적하는 것이 불가능해야 하고, (2) 서로 다른 두 입력 A, B에 대해서 동일한 해시값이 산출되는.. 다시 말해 ‘충돌’ 사례가 없어야 한다. 전자는 암호화된 값으로부터 패스워드를 복원하는 것이고, 후자는 의도하지 않았던 엉뚱한 암호로 원래 패스워드의 사칭을 가능하게 하기 때문이다.

성능 좋은 해시 알고리즘으로는 MD5니, SHA-256 이런 부류가 공개되어 쓰이고 있다. 이들도 한번 만들고 끝이 아니라 버전과 출력 해시의 길이가 올라가는 편인데, 기를 쓰고 공격하려 애쓰는 연구자에 의해 충돌하는 입력값 쌍이 발견되기도 한다. 그러면 그게 해당 알고리즘을 사용하는 소프트웨어의 잠재적 보안 결함으로 이어진다.

그리고 해시값으로부터 원래 입력을 역추적하기 위해 요즘은 상상을 초월하는 물량 데이터빨이 동원된다. “MD5 해시값을 자동으로 계산해서 구해 드립니다”라는 웹페이지를 개설한 뒤, 전세계 사용자가 입력했던 문자열과 그 해시값 수십억 개를 몽땅 보관해 놓는 것이다. 그래서 산술 연산을 하는 게 아니라 DB를 조회함으로써 해시값 복원을 한다. 우리가 남들도 떠올릴 만한 평범한 문자열로 패스워드를 만들면 위험한 이유가 이 때문이다.

2. 대칭 키 암호화

이게 우리가 흔히 생각하는 데이터 암호화이다. 발신자가 A라는 텍스트를 K라는 패스워드(혹은 key)를 이용해서 E라는 암호화 함수로 암호화해서 B라는 암호문을 얻는다. 수식으로 표현하면 B=E(A, K) 정도? 그러면 수신자는 D라는 복호화 함수를 이용해서 D(B, K)를 돌림으로써 A를 얻는다.
이걸로 끝.. ‘대칭’이라는 말은 발신자와 수신자가 K라는 동일한, ‘대칭인’ key를 공유하는 암호 체계라는 뜻이다.

암호화 함수는 해시 함수와는 달리 복호화 함수도 존재하며, key만 안다면 원문 복원이 가능하다는 차이가 있다. 해시 함수는 애초에 어떤 입력에도 128비트 같은 동일한 길이, 즉 동일한 정보량을 가진 해시값이 돌아오지만, 암호화 함수는 출력의 정보량이 입력의 정보량과 대등하다. 그러니 용도가 서로 근본적으로 완전히 다르다.

컴퓨터가 없던 시절에도 마치 VMS로부터 WNT (Windows NT)라는 명칭을 만드는 것처럼 글자들을 일정 간격 앞뒤의 것으로 변조하거나, 심지어 key 문자열의 형태를 토대로 각 글자들을 가변적인(하지만 규칙과 패턴은 물론 있는) 오프셋만치 변조하는 기법 정도는 응당 쓰였다. 모든 글자를 고정적인 오프셋만치 변조하는 암호는 각 글자들의 빈도수 분석을 통해 비교적 금방 깰 수 있을 것이다.

2차 세계 대전까지만 하더라도 전자식 컴퓨터라는 게 사실상 없던 시절이었고, 지금에 비하면 매우 단순하고 원시적인 암호가 쓰였다. 연합군이 승리한 것에는 적국(일본, 독일) 군대의 암호를 풀어낸 것이 아주 큰 기여를 했음이 주지의 사실이다.
컴퓨터가 등장한 뒤부터는 매우 컴퓨터 친화적인 비트 회전과 XOR 연산이 암호화에 즐겨 쓰이고 있으며 그 수준이 과거엔 상상도 할 수 없을 정도로 복잡해졌다. 문자열을 암호화하기 위해서는 문자열을 구상하는 각 문자들을 숫자처럼 취급하는 게 필수이다.

정보 보호라는 업계에서 이런 암호화와 관련하여 통용되는 철칙이 있다. 암호화 알고리즘은 자신의 동작 방식과 로직이 소스 코드 차원에서 몽땅 공개되어 있더라도 절대적으로 안전해야 한다는 것이다. 데이터의 안전은 key가 보장해야지, 알고리즘을 공격자가 알고 있는지의 여부와는 무관해야 한다.
그렇기 때문에 이 바닥은 소스를 공개할 수 없는 우리만의 초특급 비밀 노하우 원천기술 같은 게 없다. 모든 게 투명하게 공개돼 있고 심지어 취약점이 발견된 것, 수정 내역도 공개된다. 이런 열린 관행 덕분에 컴퓨터 세계는 역설적으로 더 안전해질 수 있었다.

여담이지만, 지난 2009년엔 ‘코드소프트’라는 정체를 알 수 없는 어느 스타트업 기업에서 상금까지 걸면서 자기네 암호화 알고리즘에 대한 크랙 공모전을 주최했으나 비슷한 시기의 T-max 운영체제 같은 흑역사만 남겼던 적이 있다. 자기네 핵심 기술이라던 암호화 알고리즘은 허술하기 짝이 없어서 겨우 몇 시간 만에 뚫려서 큰 망신을 당했으며, 그 회사도 얼마 못 가 통째로 폐업했기 때문이다(소스는 비공개이고 임의의 데이터에 대한 암호화 결과 확인만 가능). 걔들은 암호화 알고리즘의 전문가는 고사하고 보안에 대한 기본 관념이 있긴 한 기업이었는지가 의문이 든다.

대칭 키 암호화 알고리즘으로는 AES, DES 같은 기성 표준 알고리즘이 있고 이것도 버전 내지 사용하는 정보량(비트수)이 올라가고 있다. AES는 오늘날의 컴퓨터 성능으로는 뚫리는 데 걸리는 시간이 위험할 정도로 짧아졌기 때문에 이제 사용이 권장되지 않는 지경이 되었다.
우리나라에서도 SEED, ARIA, LEA라는 알고리즘을 자체 개발해서 국가 표준으로 지정한 바 있다. 국정원 내지 한국 인터넷 진흥원 이런 데서 날고 기는 수학 박사를 채용해서 머리 굴려서 개발한 듯하다.

문서나 압축 파일에 암호를 거는 기능에도 응당 이런 암호화 알고리즘이 쓰인다.파일 내부에다가 패스워드를 평문으로 저장하는 미친 짓을 하지는 말아야 할 것이다. 혹은 파일 내용 자체를 암호화하지 않아서 헤더의 패스워드 부분만 건너뛰고 나면 나머지 내용을 고스란히 읽을 수 있게 하는 것도 치명적으로 잘못된 설계이다.
틀린 패스워드를 주면 해독이 잘못되어 완전히 엉뚱한 파일이 생성될 텐데, 패스워드가 맞는지 틀린지를 확인하는 건 정상적으로 해독됐을 때의 파일 checksum hash 같은 걸 별도로 둬서 확인해야 한다. 암호화 알고리즘 다음에 붙는 CBC, GCM 같은 모드 명칭은 바로 이런 검증 방식을 가리킨다.

안전한 암호화 알고리즘이라면 평문이나 key가 조금만 달라져도 이들의 원래 형태와 통계적 특성을 전혀 알 수 없는 엉뚱한 암호화 결과가 출력으로 나와야(혼돈과 확산) 안전할 것이다. 이 점에서는 해시와 비슷한 구석이 존재하며 심지어 난수 생성 알고리즘과도 비슷하다고 볼 수 있다. 입력을 0, 1, 2 .. 순차적으로 주고 이를 hash시킨 결과가 난수나 마찬가지이고 암호화도 이와 크게 다르지 않을 테니까.. 하지만 암호화, 해시, 난수는 전문적으로 들어가면 지향하는 목표가 다른 분야라고 한다.

말이 나왔으니 말인데.. 임의로 생성 가능한 문자열과 이를 hash한 문자열을 혼합하면.. 올바른 번호와 잘못된 번호의 구분이 존재하는 일련번호(serial key) 체계도 생성할 수 있다.
간단하게는 우리나라 주민등록번호가 대표적인 예이다. 검증용으로 쓰이는 마지막 자리 숫자가 hash 함수의 결과값이니까 말이다.

소프트웨어에서 불법 복제를 감지하고 예방하기 위해 발급되는 제품 key도 다 이런 원리로 발급된다. 상업용 소프트웨어야 처음부터 고정된 시리얼 키가 제품 패키지에 들어있으니 사용자 이름과 무관하겠지만, 셰어웨어 등록판을 생성하는 시리얼 키는 사용자의 이름도 공식에 응당 반영된다.

규칙에 어긋난 잘못된 문자열을 입력하면 해당 제품의 설치 프로그램은 에러 메시지를 내뱉으면서 다음 단계로 진행을 하지 않을 것이다. key의 생성 규칙은 그 제품 개발사의 중대한 영업 기밀이다.

하지만 이렇게 수학적인 방법, 소프트웨어적인 방법은 역공학을 통해서 뚫리기도 너무 쉽다. 암호학에서 알고리즘이 아니라 key만 믿어야 한다고 괜히 강조하는 게 아니다.
옛날에 불법 복제 어둠의 경로를 가 보면 도대체 어떻게 알아냈는지 특정 소프트웨어의 제품 key를 생성해 주는 툴이 버젓이 굴러다니곤 했다. 그렇기 때문에 요즘은 이 제품 key가 실제 구매자가 사용하는지의 여부를 제품 개발사 서버로부터 일일이 추가로 확인받곤 한다.

설계 차원에서 결함이 있지 않은 안전한 암호화 알고리즘이라면 key 없이 복호화를 하는 방법이 존재하지 않는다. 그렇기 때문에 이런 암호문은 그냥 a부터 z까지 모든 글자 조합을 무식하게 일일이 대입하는 brute force 방식으로만 풀 수 있다.
패스워드의 길이가 한 글자 늘어날 때마다 공격에 소요되는 시간이 수십 배씩 기하급수적으로 늘어나니.. 이 시간 덕분에 오늘도 인간의 컴퓨팅 세계는 딱히 금융 사고나 개인정보 유출 사고가 별로 없이 안전하게 돌아가고 있다.

하지만 컴퓨터의 계산 성능은 하루가 다르게 향상되고 있고 암호 공격은 병렬화에도 아주 유리한 분야이다.
이런 brute force 공격을 저지하기 위해 요즘 암호를 입력받는 프로그램, 웹사이트 등에서는 암호가 틀릴 때마다 수 초씩 딜레이를 일부러 주고, n번 이상 암호를 틀리면 계정을 정지시키는 조치까지 취한다. 그 어떤 암호 시스템도 하나하나 다 대입해 보는 제일 무식하고 원천적인 전수조사에는 언젠가 뚫릴 수밖에 없는데.. key가 너무 허술하게 만들어져 있으면 거기에 더욱 취약해질 것이다.

3. 공개 키 암호화

지금까지 key를 따로 받지 않는 대표값 변조(해싱), 그리고 key를 받는 대칭 키 암호화까지 얘기가 나왔다. 대칭 키 암호화는 입력 데이터를 받아들이는 방식에 따라 블록 암호화 내지 스트림 암호화로도 나뉘는데, AES/DES 같은 것들은 블록 암호화로 분류된다.
그런데 1970년대에는 이런 것과는 성격이 근본적으로 다른 완전히 새로운 암호화 분야가 개척되었다. 바로 대칭이 아닌 비대칭, 또는 공개 키 알고리즘이라는 개념이 제안되고 개발된 것이다.

왜냐하면 제아무리 날고 기는 복잡 정교한 암호화 알고리즘이 있다 하더라도 그것들은 발신자와 수신자가 모두 동일한 key를 알아야 하고 보안을 위해서는 수시로 교체해야 하고, 그 바뀐 key를 모든 구성원에게 전해 줘야 한다는 원천적인 한계와 위험성이 있기 때문이다. 군대에서 새 암구호를 어떤 절차를 통해 전파하는지를 생각해 보자.

key를 주고 받는 건 암호라는 걸 운용하는 모든 조직이 감내해야 하는 어쩔 수 없는 숙명인 것 같다. 하지만 암호화 때 사용되는 key와 복호화 때 사용되는 key가 다르고(비대칭), 전자는 마음대로 주변에 공개해도 되는(공개 키) 알고리즘은 이런 한계를 극복해 준다. 이런 마법 같은 일이 어떻게 가능할까..?

이 암호화는 수학적 비가역성 내지 난해함에 근거를 두고 있다. 자릿수가 많은 두 수를 곱하는 건 사람의 입장에서 몹시 고된 노가다이겠지만.. 역으로 이미 곱해진 듣보잡 수를 아예 소인수분해 하는 것은.. 뭐 차원이 다를 정도로 난감하고 시간이 오래 걸리는 일일 것이다. 페르마 수 같은 게 n이 조금만 커져도 합성수인 것만 알려졌을 뿐 완전한 소인수분해가 안 된 놈들이 부지기수인 게 이 때문이다.

공개 키 암호화 중 하나로 유명한 RSA는 수십 자리 이상의 엄청나게 큰 소수 둘을 골라서 이 원천으로부터 공개 key와 개인 key pair를 만들어 낸다. 즉, 처음부터 동일한 원천으로부터 두 key 쌍이 계산에 의해 만들어진다는 것이다. 비록 계산이긴 해도 한 key로부터 나머지 key를 역으로 유도하는 것은 무진장 어렵고 시간이 많이 걸린다.

이런 공개 키 암호화는 제약이 크다. 앞서 살펴봤던 재래식(?) 암호화처럼 임의의 메모리 블록이나 문자열을 취급하지는 못하며, 평문과 key, 암호화 결과 모두 그냥 숫자 달랑 하나일 뿐이다. 숫자에다가 문자열에 맞먹는 정보를 담으려면 그 수가 엄청나게 커져야 한다.
그리고 얘는 그런 주제에 계산량이 차원이 다르게 많다. 컴퓨터 친화적인 XOR이나 비트 회전 같은 게 아니라 거대 정수에 대한 산술 연산을 무진장 해야 하기 때문이다.

그렇기 때문에 이런 암호화 알고리즘은 재래식 블록 암호화처럼 몇 MB짜리 데이터 자체를 암호화하는 단순한 용도로 쓸 수 없다.
그 대신 재래식 암호화 알고리즘에다가 돌릴 짤막한 key만을 암호화하는 용도로 병행해서 쓰인다. 멀티스레드 프로그램에서 TLS 슬롯은 공간이 한정되어 있으니 거기에다가 생 데이터를 몽땅 저장하는 게 아니라 그냥 포인터만 저장해 놓는 것과 비슷한 이치랄까..? 마치 손실 압축과 비손실 압축만큼이나 고유한 용도가 있는 셈이다.

https 보안 사이트 내지 인터넷 뱅킹에서 로그인을 할 때 시간이 0.n초나마 랙이 있는 이유는 네트워크 트래픽 때문이 아니라 순수하게 계산 때문에 그렇다. 그때마다 암호 해독을 위해 OpenSSL에 구현된 BigInt 같은 라이브러리의 코드가 실행되면서 큰 수 연산과 값 비교가 행해진다고 생각하면 되겠다.

공개 키 암호화로서 RSA가 아주 유명하지만 이런 소수와 소인수분해 말고 타원곡선이나 이산로그 같은 다른 어려운 연산에 기반을 둔 알고리즘도 있다.
이 암호화 기술은 인터넷의 발달과 더불어 우리의 생활을 크게 바꿔 놓았다. key를 위험하게 통째로 주고받지 않아도 되는 암호화 덕분에 인터넷 상으로 금융 거래도 할 수 있게 되고 디지털 서명, 인증서라는 것도 존재할 수 있게 됐기 때문이다!

보통은 공개 key로 암호화를 해서 개인 key로 복호화를 하는데, 반대로 어떤 문서를 개인 key로 암호화하고 공개 key로 복호화하게 하면 된다. 그러면 이 문서는 누구나 열람은 가능하지만, 만든 사람은 그 공개 key에 대응하는 개인 key의 소유자밖에 없다는 것이 입증된다. 놀랍지 않은가?

hash가 어떤 데이터가 원본과 동일한지 무결성을 보장한다면, 공개 key 암호화는 어떤 데이터가 반드시 특정인으로부터 만들어졌고 변조되지 않았다는 것을 보장할 수 있다.
도장이고 자필 서명이고 자물쇠와 열쇠 같은 모든 실물은 조작이 가능하며 컴퓨터야 뭐 0과 1 무엇이건 해킹이 가능한 디지털 세상이다. 이런 바닥에서 믿을 것은 수학적인 비가역성밖에 없어진다는 것이다.

이 세상에서 생명을 다루는 의료 다음으로 중요하고 착오가 절대로 없어야 하는 크리티컬한 임무는 아무래도 돈 거래, 기밀 거래일 텐데, 이 정도 기반은 갖춰진 뒤에야 인터넷이 안전하게 돌아가고 있다. 그러나 초창기에 인터넷은 기반 프로토콜 차원에서 이런 암호화 알고리즘이 제공되지 않았다.

그렇기 때문에 전자상거래나 인터넷 뱅킹을 남보다 일찍 서둘러 구현하려면 특정 운영체제에 종속적인 온갖 비표준 편법 기술이 동원돼야 했다. 오죽했으면 2000년대 초에 SEED 같은 알고리즘까지 개발한 걸 보면 공개 키뿐만 아니라 대칭 키 암호화까지 모두 허술했던가 보다.
허나 이게 바로 우리나라 특유의 IE + ActiveX 의존이라는 독이 되어서 오늘에 이르고 있다. 일본이 일찍부터 철도 왕국이 되긴 했지만 협궤 때문에 발목 잡힌 것과 비슷한 현상이랄까..?

이상이다. 인증서가 어떻고 공개 키, 개인 키, 디지털 서명 이러는 바닥은 통상적인 hash나 블록 암호화와는 영역이 상당히 다르다는 것, 그리고 이런 공개 키 암호화 덕분에 인터넷 보안 수준의 차원이 달라졌다는 것이 핵심이다. 이 바닥도 날고 기는 괴수들이 너무 많다..;;

Posted by 사무엘

1. 아이콘 불러오기

창(그 자체 또는 클래스)에다가 아이콘을 지정하기 위해 흔히 LoadIcon 함수가 쓰인다.
얘는 원래 고정된 32*32 크기의 기본 아이콘 하나만을 달랑 가져오는 함수로 출발했다. 허나 Windows 95부터는 글자 크기와 같은 16*16 작은 아이콘이라는 것도 추가됐고, 나중에 XP쯤부터는 24*24, 48*48 같은 다양한 중간 크기가 도입됐다.

거기에다 화면 DPI까지 가변화가 가능하지, 256픽셀 대형 아이콘까지 도입됐지.. 이거 뭐 아이콘이라는 건 이제 도저히 단일 크기 이미지라고 볼 수 없는 물건으로 바뀌었다. 한 아이콘이 다양한 크기와 색상 버전을 가질 수 있다는 점에서 과거의 비트맵 글꼴과 약간 비슷한 위상이 됐다.

한편, 원래 마우스 포인터(cursor)와 아이콘은 기술적인 원천과 본질이 거의 같은 물건이었다. 작은 정사각형 크기의 이미지 비트맵과 마스크 비트맵의 쌍으로 표현된다는 점에서 말이다. 마우스 포인터는 거기에다가 hot spot 위치 정보가 추가됐을 뿐이었다.
그랬는데 마우스 포인터는 애니메이션이라는 바리에이션이 생겼고, 아이콘은 크기 바리에이션이 생겼다고 보면 되겠다. 동일한 특성을 같이 공유하다가 서로 다른 방향으로 기능이 추가된 것이다.

Windows 95에서는 창이나 창 클래스에다가 아이콘을 지정할 때 큰 아이콘과 작은 아이콘을 구분해서 지정할 수 있게 했다. 그래서 WNDCLASS에는 멤버가 하나 더 추가된 Ex버전이 만들어졌다. WM_SETICON 메시지도 아이콘의 대소 종류를 지정하는 부분이 wParam에 추가됐다.

그리고 LoadIcon 함수 자체도.. Ex가 추가된 건 아니고, 비트맵, 아이콘, 포인터까지 다양한 크기를 모두 처리할 수 있는 완벽한 상위 호환 LoadImage에 흡수되었다. 스펙을 보면 알겠지만 기능이 정말 많다.

하지만 내 경험상, 굳이 Ex 버전을 쓰지 않고 WNDCLASS의 hIcon에다가 큰 아이콘만 LoadIcon으로 지정해 주더라도.. 동일한 ID의 아이콘에 큰 아이콘과 작은 아이콘이 모두 있다면 별도의 처리가 없어도 괜찮았다. 프로그램 타이틀 창에 작은 아이콘은 그 별도의 작은 아이콘으로 자동으로 지정되는 듯하다. 큰 아이콘을 흐리멍텅하게 resize한 놈이 지정되는 게 아니라는 뜻이다.

그래서 본인은 지금까지 프로그램을 개발하면서 굳이 WNDCLASSEX와 RegisterClassEx를 사용한 적이 없었다. 큰 아이콘과 작은 아이콘이 ID까지 다른 서로 완전히 다른 아이콘일 때에나 이런 전용 함수가 필요한 듯하다.
단, 윈도우 클래스를 등록하는 상황이 아니라 대화상자 같은 데서 WM_SETICON으로 아이콘을 지정할 때는 큰 아이콘과 작은 아이콘을 LoadImage 함수로 구분해서 일일이 지정해 줘야 했다.

참고로 Windows에서 아이콘이라는 건 메모리 관리 형태가 크게 세 종류로 나뉜다. (1) 메시지박스에서 흔히 볼 수 있는 ! ? i 표지처럼 시스템 공통 공유 아이콘, (2) 응용 프로그램의 아이콘 리소스를 직통으로 가리키기만 하는 공유 아이콘, (3) 그게 아니라 자체 메모리를 할당하여 동적으로 독자적으로 생성된 놈.

(3)만이 나중에 DestroyIcon을 호출해서 제거해 줘야 한다. (2)는 해당 모듈의 생존 주기와 동일하게 관리된다. (1)이야 뭐 언제 어디서나 유비쿼터스이고..
그리고 RegisterClass 계열 함수가 특례를 보장해 주는 건 역시 리소스 기반인 (2) 한정이다.
wndClass.hIcon = LoadIcon(hInst, IDI_MYICON) 이렇게 돼 있던 곳에서 LoadIcon(...)의 결과를 CopyIcon( LoadIcon(...))으로 감싸서 아이콘의 형태를 (3)으로 바꿔 보시라. 그러면 그 프로그램의 제목 표시줄에 표시된 작은 아이콘은 큰 아이콘을 resize한 뭉개진 모양으로 곧장 바뀔 것이다. 이것이 차이점이다.

사실, Visual Studio의 리소스 에디터 상으로는 구분이 잘 되지 않지만, 응용 프로그램 모듈(EXE/DLL)에 저장되는 리소스 차원에서는 단순 아이콘(RT_ICON)과 아이콘 집합(RT_GROUP_ICON)이 서로 구분되어 있다. 후자는 전자의 상위 호환이다. RegisterClass는 이를 감안해서 동작하지만 HICON 자료형이나 LoadIcon 같은 타 함수들은 일반적으로 그렇지 않은 것으로 보인다.

이럴 거면 wndClass.hbrBackground에 (HBRUSH)(COLOR_WINDOW+1)이 있는 것처럼 hIcon에도 (HICON)IDI_MYICON 이런 게 허용되는 게 더 깔끔하겠다는 생각도 든다.

자, 이 정도면 아이콘 지정에 대해서 더 다룰 게 없어야 하겠지만.. 그렇지 않다. LoadImage 함수에 약간의 버그가 있다.
얘는 (1) 시스템 공용 아이콘에 대해서는 요청한 크기에 맞는 버전을 되돌리지 않고 가장 큰 놈 또는, 걔네들 용어로는 캐시에 보관돼 있는 크기의 이미지만을 되돌린다. 즉, 기존 LoadIcon과 다를 바 없이 동작한다.

특정 크기에 해당하는 아이콘을 정확하게 되돌리라고 별도의 함수까지 만들었는데 그건 (2), (3) 계층에 해당하는 custom 아이콘에 대해서만 동작한다. (1)에 대해서는 글쎄, 성능 때문인지 호환성 때문인지 잘못된 동작을 일부러 방치해 버리고는 더 고치지 않는 듯하다.

그렇기 때문에 시스템 공용 아이콘의 16픽셀급 작은 버전을 이 함수로 얻을 수 없다.
Windows Vista부터는 사용자 계정 컨트롤이라는 보안 기능이 추가되어서 관리자 권한을 나타내는 방패 아이콘(IDI_SHIELD)이 추가되었다. 얘도 UI 텍스트와 함께 작은 크기로 그려야 할 텐데.. LoadImage로는 256픽셀짜리 대형 아이콘만 얻을 수 있기 때문에 이걸 16픽셀로 줄여서 그리면 보기가 흉하다.

마소에서는 LoadImage 함수의 버그를 고친 게 아니라 Vista부터 LoadIconMetric이라는 함수를 추가했다.
얘를 사용하면 시스템 공용 아이콘에 대해서도 정확한 크기를 얻을 수 있다.
얘는 아이콘을 언제나 (3)번 형태로 동적 할당해서 되돌리기 때문에 다 사용하고 나서는 DestroyIcon을 해 줘야 한다. 처리하기 간편한 shared, read-only 속성을 포기하고 정확한 동작을 하도록 로직을 바꾼 것 같다.

그 외에 SHGetStockIconInfo라는 함수도 있어서 얘를 사용하면 한 마디로 탐색기에서 쓰이는 각종 디스크 드라이브, 폴더, 돋보기, 네트워크 등의 표준 셸 아이콘을 얻을 수 있다.

2. DrawFocusRect

Windows에서 대화상자를 키보드로 조작하다 보면, 현재 포커스를 받아 있는 각종 버튼(라디오/체크 박스 포함)이라든가 리스트 아이템에 가느다란 점선 테두리가 쳐진 것을 볼 수 있다. 이것은 DrawFocusRect라는 함수를 이용해서 그려진 것이다.

마소에서는 키보드 포커스를 받아 있는 GUI 구성요소에다가는 요 함수를 호출해서 점선으로 테두리를 그려 줄 것을 GUI 디자인 표준으로 명시하고 있다. 뭐, 일반 프로그래머라면 버튼 같은 커스텀 컨트롤을 직접 구현하거나 owner-draw 리스트박스를 만들 때에나 숙지할 만한 개념이다. 다른 요소들을 다 그리고 나서 맨 마지막으로 focus 테두리를 그려 주면 된다.
다만, 에디트 컨트롤은 애초에 깜빡이는 캐럿(caret; cursor)이 포커스에 대한 시각 피드백 역할을 하고 있기 때문에 또 점선 테두리를 그려 줄 필요가 없다.

이 점선은 이미 아시겠지만 xor 연산을 가미한 반전색이다. 원래 색과 반전 색이 교대로 등장하는 아주 단순한 패턴이다.
요즘 세상에 테두리는 그냥 알파 채널을 가미한 옅은 실선으로 그려도 될 것 같지만, 이 분야는 구닥다리 GDI 레거시 API와의 호환 문제도 있어서 그런지 여전히 옛날 그래픽 패러다임이 쓰이고 있다. 이 xor 테두리는 계산량 적고 간편할 뿐만 아니라, 다시 한번 그리라는 명령을 내리면 싹 사라지고 원래 이미지로 돌아온다는 특성도 있어서 더욱 편리하다.

이 테두리는 두께가 오랫동안 1픽셀로 고정되어 있었다. 하지만 1픽셀만으로는 너무 가늘어서 눈에 잘 띄지 않고 시각 장애인의 접근성에 좋지 않다는 의견이 제기되었다. 게다가 모니터의 해상도가 갈수록 올라가고 100%보다 더 높은 확대 배율도 등장하다 보니, 1픽셀 고정 두께의 한계는 더욱 두드러지게 됐다.

이 때문에 Windows XP부터는 제어판 설정에 따라 2픽셀 이상의 focus 테두리도 등장할 수 있게 됐다.
이 조치가 응용 프로그램에서 특별히 문제가 될 일은 거의 없겠지만, DrawFocusRect로 평범한 직사각형을 안 그리고 1~2픽셀 남짓한 두께의 수직선· 수평선을 그려 왔다면 선이 의도했던 대로 그려지지 않을 수도 있다. 같은 영역에 선이 두 번 그려지면서 점선이 없어져 버리기 때문이다.

DrawFocusRect는 기술적으로 사각형 테두리 모양으로 50% 흑백 음영 비트맵을 브러시로 만들어서 PatBlt() 한 것과 완전히 동일하다. raster operation은 PATINVERT (흑백 xor target)이고 말이다. 그러면 원래색 / 반전색이 교대로 등장한다.
xor이 아니라 and라면 과거 Windows 9x/2000의 시스템 종료 대화상자의 배경처럼 "검정 / 원래색"이 교대로 등장하면서 화면이 반쯤 어두워지는 걸 연출할 수 있을 텐데.. 이 래스터 연산 코드는 따로 정의돼 있지 않은 것 같다.

그런데.. Windows의 GDI API에서 흑백 비트맵은 자체적인 색이나 팔레트 따위가 없으며, 현재 DC의 글자색과 배경색이 DC에 select된 비트맵의 색깔로 쓰인다.
그렇기 때문에 DrawFocusRect로 정확하게 반전 점선 테두리를 그리려면 호출 당시에 해당 DC의 글자색과 배경색을 반드시 black & white로 해 줘야 한다. 시스템 색상 따질 것 없이 RGB(0,0,0)과 RGB(255,255,255)로 하드코딩하면 된다.

이렇게 해 주지 않으면 마지막으로 텍스트를 찍던 당시의 글자색 및 배경색이 무엇이냐에 따라서 focus 테두리의 색깔이 정확하게 반전색이 되는 게 아니라 들쭉날쭉 날뛰고 지저분해질 수 있다.
이건 꽤 중요한 사항인데 왜 MSDN 같은 문서에 전혀 소개되어 있지 않았나 모르겠다. 나도 10수 년째 모르고 있다가 요 얼마 전에야 깨달았다.

또한 50% 음영은 굉장히 단순하고 자주 쓰이는 패턴인데.. 브러시나 비트맵을 stock object로 제공을 좀 해 주지, 왜 안 하나 모르겠다. 요즘 같은 트루컬러, 알파채널 이러는 시대보다도 모노크롬, 16색 이러던 옛날에 더 필요했을 텐데 말이다.
CreateCaret 함수로 caret을 생성할 때는 일반적인 비트맵 핸들 대신 특수한 상수를 넣어서 50% 음영 모양을 지정하는 게 있는데.. caret보다는 다른 형태로 쓰이는 경우가 더 많다.

다음은 파란 배경에 대해서 잘못 그려진 테두리(위: 반전색+검정)와, 맞게 그려진 테두리(아래: 반전색+원래색)의 예시이다.

3. 비트맵 윤곽으로부터 region을 곧바로 생성하는 방법의 부재

Windows에서 region은 사각형이 아닌 임의의 비트맵 영역을 scan line들의 집합 형태로 표현하는 자료구조이며, 창을 사각형이 아닌 임의의 모양으로 만드는 데 쓰이는 수단이기도 하다. 이 블로그에서 예전에 한번 집중적으로 다룬 적이 있다. (☞ 예전 글)
Windows에서는 사각형이 아닌 임의의 복잡한 모양의 region을 생성하기 위해서 다각형, 원, 모서리간 둥근 사각형 등 여러 API를 제공하며, 집합 연산 비스무리하게 기존 region과 영역을 합성하는 CombineRgn이라는 함수도 제공한다.

그런데 이것만으로는 여전히 좀 2% 부족한 구석이 있다.
region을 생성할 때 사용되는 원· 다각형 그리기 함수의 결과와, 실제 DC에다 원· 다각형을 그리는 함수의 결과가 픽셀 단위로 100% 정확하게 일치하지 않을 때가 있다. 그래서 딱 정확하게 영역 안에다가 테두리를 깔끔하게 그리는 게 난감하다.

그리고 아예 만화 캐릭터 같은 모양의 창을 만들 때는.. 저렇게 벡터 이미지가 아니라 임의의 마스크 비트맵으로부터 그 윤곽 영역대로 region을 바로 생성할 수 있는 게 좋은데 의외로 그런 함수가 없다.

뭐, region의 내부 자료구조에 접근해서 복잡한 region을 직통으로 생성하는 방법도 없지는 않지만(정말 생짜 직사각형들의 집합..;; ) 이 역시 귀찮다는 건 어쩔 수 없다.
이 때문에 비트맵 그림으로부터 region을 생성하는 코드를 보면.. 비트맵 내용대로 한 줄 한 줄 CombineRgn(RGN_OR)로 한눈에 보기에도 정말 느리고 비효율적인 방법을 쓰고 있다.

layered window의 color key를 쓰면 투명색을 더 편리하게 구현할 수 있긴 하다. 허나, 창 아래의 그림자(CS_DROPSHADOW)는 region을 통해 지정된 경계하고만 정확하게 연계한다. 그렇기 때문에 애니메이션이 아닌 데서는 구닥다리 region도 여전히 필요하다.

이 분야는 다른 그래픽 API 같은 대안이 있는 것도 아닌데 마소에서 GDI API의 지원에 왜 이리 인식한지 모르겠다.;;

Posted by 사무엘

1. for one's sake

가만히 생각해 보면.. 성경의 맨 처음 책인 창세기에서는 주요 성경 용어들이 약간 뜬금없는 문맥에서 최초로 등장하곤 한다.
창세기에 존재하는 KJV만의 독특한 표현으로 replenish, God will provide himself a lamb 같은 게 있는데, 이 글에서 소개하려는 아이템은 저런 것들보다는 훨씬 덜 유명해 보인다.

아담과 이브가 죄를 지은 후에 하나님이 인간과 세상에게 내리시는 징벌이 창 3:17에 기록돼 있다. “땅이 너로 인하여 저주를 받고..” 그런데 다른 모든 성경들은 because of you인 반면, 킹 제임스 성경은 유일하게 for thy sake라고 쓰여 있다.

똑같이 인과관계를 나타내더라도 for one's sake는 굉장히 긍정적인 심상이다. because of가 중립적이거나 약간 미묘하게 부정적인 심상인 반면, 쟤는 ‘누구 덕분에, 누군가를 보호하기 위하여, 누군가를 배려해서· 감안해서’라는 심상이 담겨 있다.
까놓고 말해 18장에서 하나님께서 “소돔과 고모라에 의인이 50명, 40명~10명이라도 있으면 걔네들을 생각해서라도 재앙을 내리지 않겠다”라고 말씀하셨을 때도 for their sakes라는 표현이 쓰였다.

게다가 replenish가 창 1:28뿐만 아니라 노아의 홍수 이후인 9:1에서 또 나오는 것처럼, for one's sake는 역시 근처인 8:21에서 거의 동일한 문맥을 배경으로 한 번 더 등장하기도 한다. “내가 다시는 사람으로 인하여 땅을 또 저주하지 아니하리니...”

물론 둘 다 우리말로는 because of와 마찬가지로 '-로 인하여'라고 번역해도 별 무리는 없다.
하지만 KJV도 because of가 엄청나게 많이 쓰이는데 굳이 이걸 놔두고 for one's sake가 따로 쓰였다는 것은.. 땅에 내려진 원초적인 심판과 저주조차도 그저 사람들을 엿먹이고 불편하게 하는 목적이 아니라 그 인간의 처지에 대한 하나님의 다른 뜻과 배려가 담겨 있음을 암시하는 듯하다. 당장 이해는 잘 안 되지만 말이다.

사실은 굳이 sake까지 안 쓰더라도 영어는 전치사 for이 단독으로 ‘위하여’(좋은 목적 one's sake) 내지 ‘인하여’(이유, 인과관계 because of)라는 뜻을 모두 지니는 구석이 있다. 이 용법을 생각하게 하는 대표적인 찬송가는 바로 “예수 나를 위하여 십자가를 질 때”이다.

영어로는 Jesus died for me와 Jesus died for my sins가 모두 성립한다. 그런데 저 찬송가 후렴의 “예수여 예수여, 나의 죄 위하여”는 좀 고개를 갸웃거리게 만든다. 죄 자체는 뭔가 ‘위해서 죽어야’ 할 가치가 있는 좋은 대상은 전혀 아니지 않은가? 죄값을 대신 치르기 위해서 죽는다면 모를까..?

이건 희소병을 희귀병이라고 잘못 표기한 것과 비슷한 오류로 보인다! 그래서 어떤 찬송가 책에서는 후렴 가사를 “나의 죄 인하여”라고 수정하기도 했다. 흥미로운 차이점 같다.
예전에도 글로 쓴 적이 있지만, 영어의 sake는 behalf와 마찬가지로 굉장히 제한적인 특정 문맥과 용법에서만 쓰인다. 한국어 문법 체계로 치면 '의존명사'와 매우 비슷한 물건이라 하겠다.

2. 하나님의 아들들(sons of God)

창세기 6장에 등장하는 '하나님의 아들들'의 정체는 평범한 사람이 아니라 타락한 천사이다. 이건 대다수의 기성 교회나 신학교에서 가르치는 해석과는 사뭇 다를 것이다.

사람처럼 생기긴 했지만 생물학적으로 사람과 동일하지는 않은 천사가 인간 여성과 결합함으로써 초인적인 괴수· 거인 잡종이 태어났다. 창 6:4에 나오는 네피림.. 킹 제임스 성경에서는 간단하게 거인이라고 번역한 이놈은 말 그대로 로버트 워들로를 능가하는 거인이었다. (20세기 초, 키가 272cm까지 갔던 관측 이래 인류 최장신 미국인)

신 3:11에 따르면, 바산의 왕 '옥'도 침대의 길이가 9큐빗.. 약 4.5미터.. 거의 아반떼 승용차와 비슷한 길이였다고 나온다. 인간의 침대가 말이다. 그리고 골리앗의 키가 6큐빗 플러스 알파다(삼상 17:4). 거의 3미터 이상..
그러니 창세기 6장의 거인도 무슨 영적 거장이니, 카인의 후예 따위로 이상하게 갖다붙일 게 아니라, 말 그대로 생물학적 거인이라고 받아들이는 게 성경을 성경으로 푸는 바람직한 해석이다.

로버트 워들로는 성장판이 정신줄 놓는 병에 걸려서 키만 비정상적으로 커졌던 것이다. 발이 자기 체구와 체중을 감당하지 못해서 지팡이를 짚고 다녀야 할 정도였으며, 나중에는 발목 부상으로 인한 패혈증 때문에 20대 초반의 나이로 죽었다.

그러나 골리앗은.. 지팡이는 개뿔.. 그 키에다가 무거운 갑옷 입고 창을 들고, 전투력도 인간 흉기 급이었다.
세상에 그 어떤 교단 교파에서도 골리앗이 무슨 영적 거장이었다니 장수였다느니 헛소리를 하지는 않을 것이다. 그럼 다윗은 짱돌이 아니라 영적인 돌로 신학 논쟁과 키배로 골리앗을 '영적으로' 제압했게?

이런 괴수들은 다 인간의 정상적인 평범한 유전자로부터 나온 존재가 아니었다는 것이다. 또한 성경적으로도 신약에서는 하나님의 아들들이 사람 또는 구원받은 크리스천이라는 보편적인 심상을 갖지만, 구약에서 창세기와 욥기에 나오는 하나님의 아들들은 천사라는 용례가 명백히 존재한다. (욥 1:6, 38:7 등)

본인은 '하나님의 아들들' 그리고 "being old and full of days"라는 표현의 유사성을 근거로 욥기의 저자 자체가 모세일 것이라고도 추측을 한다만, 이건 뭐 논쟁할 정도로 강하게 주장하지는 않는다.

3. 창세기 나머지

(1) 포도주 wine
잘 알다시피 9장에서 노아가 만취해서 곤드레만드레가 되는 모습으로 처음 등장한다.
전에도 한번 얘기했었지만.. 본인은 교리적인 근거(가나의 혼인 잔치, 빵과 잔 만찬 따위)가 있는 곳이 아니라면 wine은 “즙 < 주”로 받아들여도 무방하다고 생각한다. 최초의 언급 법칙을 감안했을 때 말이다.

특히 마 11:19, 눅 7:34처럼 명백히 부정적인 음해 문맥에서까지 무알코올 포도즙을 고집할 필요는 없다. 식탐 다음에 술주정이 따르는 것은 신 21:20 (부모가 막장 패륜 자식을 고발해서 죽여버리기~!! ㄷㄷ)과 대조해 봐도 자연스럽게 호응한다.
성경이라 해도 문맥상 필요하다면 술도 나오고, 심지어 “There is no God”이라는 불신자 말 인용도 나오는 법이다.

(2) 누룩 없는 빵(unleavened bread 무교병)
19장에서 롯이 소돔에서 천사들을 잔치까지 베풀면서 대접하는데, 잘 부풀어오른 부드럽고 맛있는 빵이 아니라 저런 빵이 등장한다. 이상하지 않은가?
율법 유월절하고 아무 관계 없는 상황인데 이건 무슨 의미가 있는 걸까..?? 잠시 후에 소돔 불벼락을 앞두고 쟤들도 마치 이집트를 탈출하듯이 이 집을 허겁지겁 빨리 탈출해야 했던 건 사실이지만, 롯이 그 사실을 알 리가 없었을 텐데 말이다.

혹시 손님으로 가장했던 천사들이 "누룩 없는 빵으로 플리즈~~" 라고 커스텀 주문을 했던 것은 아닐까?
본인은 오랫동안 궁금했는데 이에 대해서는 관련 강해나 주석을 아직 한 번도 접해 보지 못했다.

(3) 사랑
성경에서 최초로 이 단어가 등장하는 곳이 바로 22장, 하나님이 아브라함더러 아들 이삭을 번제 헌물로 바치라고 명랑하는 문맥이다.
모세오경 중에서는 마지막 책 신명기가 사랑이라는 단어가 압도적으로 많이 나오고, 특히 “{주} 네/너희 하나님을 사랑하라”라는 말이 유일하게 나온다.

(4) 묵상
"이삭이 저물 때에 들에 나가 묵상하다가 눈을 들어 바라보니, 보라, 낙타들이 오더라." (창 24:63)
여호수아기나 시편을 보면 “주의 말씀을 밤낮으로 묵상한다/하라”처럼 묵상의 대상이 같이 언급되는 반면.. 창 24:63에서는 목적어가 생략된 채 꽤 뜬금없이 이 단어가 최초로 등장한다.
그러니 세상적인 관점에서 성경을 읽으면, 이삭이 들판에서 눈을 감고 가부좌 틀고서 엄근진한 자세로 참선, 요가, 단월드 기수련, 파륜궁, 관심법(!!) 시전을 하는 장면이 떠오르기 쉽다.. ㅡ,.ㅡ;; 골수 예수쟁이인 나조차도 이 정도 선입견과 편견은 생겨 있다.

핵심은.. 묵상은 명상이 아니라는 것이다.
저런 구절을 읽으면서 시 119:15 “내가 주의 훈계들을 묵상하고 주의 길들에 관심을 기울이며” 내지, 찬송가 가사로도 있는 “나의 입술의 모든 말과 나의 마음의 묵상이 주께 열납되기를 원하네” (시 19:14)가 연결돼야 하는데..
온갖 잡다한 다른 유사품이 떠오르는 게 바로 마구니들이다.. 진짜 마구니는 법봉으로 대가리 깨뜨린다고 잡을 수 있는 게 아니다.

옛날의 천조국 어린이들은 호환 마마 전쟁... 이 아니라,
어릴 적부터 성경을 읽은 덕분에 ?Z라는 단어를 보고 욥의 고향 우스 UZ를 먼저 떠올렸었다.
하지만 현대의 어린이들은 오즈의 마법사 OZ를 먼저 떠올린다는 카더라가 있었다. 뭐, 요즘은 오즈조차도 해리 포터에게 밀려서 한물 간 지가 오래이지만 말이다.

이런 것 말고도, 세상 매체(영화, 게임, 드라마 따위)들을 접하던 사고방식으로 성경을 읽다 보면..

4. 유령

• 그때에 내 얼굴 앞으로 한 영이 지나가므로 내 살의 털이 곤두섰느니라. (욥 4:15)
• 제자들이 그분께서 바다 위로 걸어오시는 것을 보고 불안해하여 이르기를, 영이다, 하고 두려워서 소리 지르거늘 (마 14:26)

성경에도 딱~ Ghostbusters 풍의 공포 영화를 떠올릴 만한 정면이 이렇게 존재한다. 성경이 말하는 혼과 영이 각각 귀신과 유령으로 바뀌는 것이다. 심지어 번역 자체도 그런 스타일로 돼 있다(KJV 제외).

한 30년쯤 전엔 고스트버스터스가 “유령 대소동”이라는 제목으로 어린이용 TV 만화영화로도 방영됐었다. “유령이 나타났다, 잔꾀와 속임수로 사람들 괴롭히는 유령이다~ㅎ”라는 주제가는
“뱀이다 뱀이다, 몸에도 좋고 맛도 좋은 뱀이다~ㅎ” 트로트 “참아 주세요”와 굉장히 비슷한 풍이었다.. ㅠㅠㅠ

하지만 성경이 말하는 영에는 원래 호러 요소는 전혀 존재하지 않는다.

• 한 영이 나아와 {주} 앞에 서서 이르되, 내가 그를 설득하겠나이다, 하거늘 (왕상 22:21)
• 내 손과 내 발을 보라. 바로 나니라. 나를 만지고 또 보아라. 영은 살과 뼈가 없으되 너희가 보는 바와 같이 나는 있느니라. (눅 24:39)

요 4:24를 “하나님은 유령이시니...”라고 번역하는 게 말이 되겠는가?
ghost도 마찬가지. 성령님 the Holy Ghost 아니면 숨지다 give up the ghost라는 두 용례로만 쓰였다.

여담이지만, 본인의 어린 시절에 학원인가 학교에서 이름이 '혜령'인 여자애가 있었는데.. 별 상관도 없는 유령이라는 별명으로 짓궂은 남자애들로부터 놀림 받곤 했다.
본인의 이름 별명 중 하나이던 묵사발, 도루묵 따위보다는 훨씬 더 점잖아 보이는데 유령이 뭐가 그리 대수였나 모르겠다. 뭐 여자여서 유령이라는 말에 더 민감했던 것일지도 모르지만..

그러고 보니 귀신은 긴 생머리에 소복 입은 하얀 처자가 떠오르는 동양 스타일에 가깝고, 유령은 얼굴 찌그러뜨리고 해파리처럼 흐물흐물 거리는 게 서양 스타일에 더 가깝게 느껴진다. 저승사자(!!)만 해도 동양은 검은 옷 검은 갓 차림의 아재이고, 서양은 낫 들고 있는 해골 아저씨이듯이.. 아이고, 갑자기 전혀 기독교적이지 않은 얘기가 많이 튀어나왔다. ㅎㅎ

Posted by 사무엘

1. 볼링장

볼링장 레인의 표준 규격은..
길이 19.15미터, 폭 1066mm이다.

선수가 투구하는 구역 말고, 도랑이 등장하는 지점과 맨 뒤쪽 핀이 있는 지점 사이의 거리가 19.15m라는 뜻이다.
우리나라의 수도권 전철 및 지하철에서 볼 수 있는 '대형 전동차'가 1량의 길이가 19.5m로 정해져 있어서 볼링장 레인보다 근소하게 더 긴 수준이다. 무궁화호 이상의 일반열차는 이보다 더 길어서 20m를 상회하며, 반대로 중형 전동차는 더 짧다.

다음으로 폭은.. 도랑을 제외하고 순수하게 공이 굴러가는 공간의 폭이 1066mm라는 뜻이다.
그러므로 신칸센 말고 1067mm짜리 협궤를 사용하는 일본에서 지하철이나 재래선 열차를 볼링장에다 가져오면 바퀴를 양 도랑에다가 딱 맞게 얹을 수 있다.
양쪽 도랑(커터)의 폭을 몽땅 포함시키면 1520~1524mm가 되며, 이는 표준궤를 넘어 시베리아 횡단열차의 궤간과 얼추 비슷해진다.

볼링장에서 공이 굴러가면서 일으키는 잔잔한 진동은 열차가 주행하면서 근처에서 들리고 느껴지는 미세한 진동을 연상케 한다.
그리고 볼링장의 여러 레인들은 마치 철도 차량기지에 있는 여러 출입구를 떠올리게 한다.
우리 주변에 철도를 알게 할 만한 것들이 충분히 널려 있다(롬 1:19-20). 그렇기 때문에 사람이 변명할 수 없다.

2. 수도권 전철 경의중앙선의 특성

(1) 서쪽의 경의선 방면으로는 공항 철도가, 동쪽의 중앙선 방면으로는 경춘선이 같이 분기해 나가는 형태이다. 분기하는 노선들은 운임 체계가 수도권 전철과 다른 열차가 다닌다는 공통점이 있다. (직통열차, ITX 청춘)

(2) 경의선의 종점은 문산이며 중앙선의 종점은 용문이다. 하지만 양쪽 모두 열차가 매우 드물게 제한적으로 다니는 추가 종착역이 존재한다. 중앙선은 지평이며, 경의선은 민통선 안의 도라산까지 연장 개통 계획이 있다.

(3) 경의선과 중앙선은 모두 일반열차 트래픽 때문에 서울 시내 구간의 선로 용량 제약이 심한 편이다. 그래서 둘 다 서울 외곽에 중간 시종착역이 존재했다. 중앙선과 연결되기 전의 경의선은 DMC, 지금도 경춘선은 상봉. DMC-수색과 상봉-망우는 역간 거리가 매우 짧다는 공통점이 있다.

(4) 경의선의 경우, 서울 역 이북으로 신촌을 경유하는 선로가 만들어지면서 이게 오랫동안 경의선 역할을 해 왔다. 하지만 지금은 과거의 용산선 구간이 지하로 내려가면서 다시 경의선 본선으로 바뀌었으며, 신촌 구간은 지선이 됐다.
1시간 1대 서울-신촌-대곡 4량 운행 계통은 마치 영등포-광명 4량 계통과 비슷해 보인다. 훗날 교외선이 어떻게든 전철로 부활한다면 이 열차가 경의-교외-경원 순으로 운행 구간이 그대로 연장되어 의정부나 광운대 정도까지 다니지 싶다.

(5) 경의선은 경부선과 만나는 용산-효창공원과 서울-신촌에 굉장한 급커브가 있다. 기존 건물과 시설을 피해서 아주 힘들게 철도를 건설해야 했기 때문이다. 특히 용산-효창공원의 경우, 짧은 구간에서 지상과 지하도 오르내리기 때문에 경사도 강원도 산악철도처럼 거의 법적 한계에 근접하는 수준이라고 한다.

(6) 하긴, 용산에서 이촌 쪽으로 진입하는 구간도 원래 급커브에다가 절연 구간까지 있어서 만만찮게 열악했다. 무슨 기술로 극복한 건지는 모르겠지만, 절연 구간이 없어진 게 한 2017년쯤부터였지 싶다.

3. '역'이라는 글자로 시작하는 전철역

우리나라의 지하철역 중에는 이름이 '역'으로 시작하는 것이 있다.
수도권 전철의 경우 역곡(1호선 경인선), 역삼(서울 2호선), 역촌(서울 6호선) 이렇게 세 개인데, 소속된 노선이 모두 다르고 위치도 각각 부천, 강남, 은평구로 흩어져 있다.
하지만 저 역명들은 모두 인근의 행정구역(동)의 명칭에서 유래되었으며, 첫 글자인 '역'은 한자가 정거장/정류소를 뜻하는 驛으로 동일하다는 공통점이 있다.

자동차가 없던 조선 시대에 서양처럼 말이 끄는 대중교통 마차 정거장이 있었던 건 아니다.
지금 우리가 철도역의 의미로 쓰고 있는 驛이라는 글자 내지 단어(역참)는.. 전근대 시대에 높으신 분이 말 타고 지방으로 출장을 가거나 어명 같은 소식을 급히 전하러 이동할 때, 지친 말과 쌩쌩한 말을 교환하는 일종의 보급소였다.

'파발', '파발꾼', '파발마' 같은 말을 들어 보셨을 것이다. 성경에도 post라는 이름으로 등장한다. 특히 에스더기에 왕의 명령을 전하는 파발꾼이 말 타고 전국 방방곡곡으로 흘어지는 모습이 유난히도 생생하게 묘사된다. (에 3:13, 15 등)
뭐, 역참까지 나오지는 않지만 그런 파발꾼이 중간에 들르던 보급고가 바로 역참이다.

그리고 驛이라는 글자로 시작하는 지명은.. 과거에 여기 일대에 역참이 있었기 때문에 그런 이름이 붙은 것이다. 교통· 이동과 관계 있는 한자이지만 부수가 車가 아닌 馬인 것을 주목하자. 하긴, 옛날에 車는 '싣는 수레'라는 심상이 더 강했지, 스스로 움직인다는 심상은 馬보다 약했다.
한편, 서울 지하철 3호선의 서쪽 끄트머리에 있는 구파발은 '역' 대신 '파발'이라는 말을 집어넣어서 동일한 어원을 나타내고 있다.

옛날에는 파발꾼이 말 타고 장거리를 쉴 새 없이 달리는 모습이 신기한 한편으로 불안하고 부정적으로 여겨지기라도 했는지.. '역마살이 꼈다'라는 관용구는 그다지 좋은 뜻이 아니다. (한 곳에 오래 머물러 지내지 못하고 늘 분주하게 떠돌아다니며 사는 액운)
조선이 도로가 별로 발달하지 않은(못한) 것도 이런 정서 배경 때문인가 하는 생각이 든다.

그랬는데.. 한때 역참을 가리키던 한자가 나중에는 철도역을 가리키는 한자로 바뀌었다는(확장?) 것이 신기하다.
역명 속에 또 들어있는 驛은 철도역에서 유래된 글자가 아니라는 점을 알 필요가 있겠다.

4. 새로 생기는 역들의 이름

(1) 가끔은 철도 노선이 새로 생기는 게 아니라, 이미 있는 두 철도역 사이에 새로운 역이 추가로 만들어지는 경우가 있다. 서울 지하철에서는 1호선 동묘앞(동대문과 신설동 사이)과 2호선 용두(신답과 신설동 사이)가 대표적이며, 수도권 광역전철에서는 분당선 이매(야탑과 서현 사이)가 있다. 이들은 다 2004~05년이라는 비슷한 시기에 만들어진 지하역이라는 공통점이 존재한다.

그런데 앞으로는 대전 지하철 오룡과 용문 사이에 용두라는 역이 추가될 예정이라 한다. 두 역은 유등천을 끼고 있어서 역간거리가 1.5km 정도로 약간 긴 편인데, 그 사이에 역을 하나 더 만드는 것이다.
서울과 대전 모두 지하에 추가되는 역이 용두동에 있어서 이름도 용두라니.. 매우 흥미롭다. 게다가 서울 2호선과 대전 1호선은 노선색도 초록색 계열로 비슷하다.

(2) 지난 2010년 1월, 서울 지하철 3호선 수서-오금 연장과 비슷한 시기에 수도권 전철 1호선에서는 군포와 의왕 사이에 ‘당정’이라는 역이 추가됐다.
그런데 그로부터 11년 정도 지난 지금은 그 1호선의 장항선 구간인 아산과 배방 사이에 ‘탕정’이라는 역이 추가될 예정이다. 이름이 참 절묘하지 않은지?

게다가 옆으로 배방과 온양온천 사이에는 ‘풍기’라는 역을 추가로 만들려는 계획이 잡혀 있다. 양평(5호선)에 이어 중앙선의 역과 이름이 겹치는 전철역이 하나 더 생기게 되겠다.

5. 기타

(1) ‘캐나다’라는 나라를 우리나라 수도권 전철에다가 투영시켜 보면 개인적으로 일산선이 떠오른다. 붉은색 계열(노선색 주황, 붉은 단풍), 미국보다 북쪽 위치인 것(서울보다 북쪽), 영연방 국가이지만 우측통행인 것(코레일 구간이지만 우측통행), 뭔가 전원적인 분위기.. 이런 것들이 연상되기 때문이다. ㄲㄲㄲ

(2) 구워 먹는 육상 동물 고기(소, 돼지)는 디젤 차량 같고, 날로 먹는 생선회는 전기 차량 같다. 그리고 바닷물고기는 교류 차량, 민물고기는 직류 차량, 연어는 직-교류 겸용 전동차처럼 느껴진다.

(3) 국도 6호선을 타고 양평으로 가는 길목에는 '아세아 연합 신학 대학교'라는 초교파 복음주의 성향의 신학교가 있다.
그런데 이 학교에서 제일 가까운 전철역이 경의중앙선 '아신' 역이라니.. 매우 공교롭게도 학교명의 이니셜처럼 들린다. 역명은 학교와 아무 상관 없이 그냥 양평군 아신리라는 지명에서 유래됐을 뿐인데..

학교가 있는 곳은 남한강이 내려다 보이고 주변 자연의 정취가 죽여준다. 애초에 온통 상수원 보호 구역이니까.. 그 대신 통학하기 불편하고, 일명 2호선 대학교들처럼 도시 문명과 어우러진 캠퍼스 생활을 할 수 없는 건 감수해야 한다.;;

(4) 끝으로.. 이야, 수도권 전철 전체를 통틀어 낚시로는 타의 추종을 불허하던 신길온천역이 올해 초에 드디어 '능길'이라고 이름이 바뀌었다니 참 감개무량하다. 이제 "우리 역 주변엔 온천 시설이 없습니다 -- 신길온천역장" 이렇게 써 붙여 놓지 않아도 되겠군.

Posted by 사무엘

Windows 환경에서는 프로그램이 자기 화면(창)에다 뭔가를 그리고 표시하는 걸 보통은 WM_PAINT 메시지가 왔을 때 한다.
하지만 반드시 그때만 그림을 그릴 수 있는 건 아니다. 키보드나 마우스 입력(특히 뭔가 드래그)이 들어와서 특정 지점에 대한 시각 피드백만 즉각 주고 싶을 때, 혹은 타이머를 걸어서 일정 시간 주기로 반드시 뭔가를 그리고 싶을 때는 InvalidateRect라든가 WM_PAINT에 의존하지 않고, 프로그램이 직통으로 DC를 얻어 와서 그림을 그려도 된다.

화면 그리기뿐만 아니라 키보드 입력 인식도 마찬가지이다.
반드시 WM_KEYDOWN/UP 메시지를 통해서만 키보드 입력을 인식할 수 있는 건 아니다. 마우스 메시지를 처리 중일 때도 shift나 ctrl 같은 modifier key가 같이 눌렸는지, 혹은 caps/num/scroll lock 램프가 현재 켜져 있는지를 함수 호출 하나로 간편하게 알 수 있다.
그런 modifier 글쇠조차 매번 WM_KEYDOWN/UP때만 감지할 수 있다면.. 응용 프로그램이 지역 변수의 범위를 넘어서는 지저분한 key state 관리자를 둬야 할 것이고, 코딩이 굉장히 번거롭고 불편해질 것이다.

옛날에 도스 시절에 키 입력을 감지하는 건 꽤 번거로웠던 걸로 본인은 기억한다.
문자가 아닌 화살표, home/end, page up/down 같은 글쇠에 대해서는 0번(null) 문자가 prefix 명목으로 오고, 동일 함수를 한번 더 호출해서 실제 값(아마 스캔 코드)을 얻는 형태였다. 그러고 보니 저건 나름 dead key라는 개념이 구현된 셈이다.

그것 말고 ctrl이나 shift, 각종 lamp 글쇠는 저런 방식으로도 잡히지 않았기 때문에 또 다른 도스 API를 동원해야 했다. 요것들은 키보드 버퍼를 차지하지 않고, 컴퓨터가 바쁠 때 아무리 누르고 있어도 삑삑 소리를 발생시키지 않는 조용한 특수글쇠이기 때문이다.;;

글쇠를 누르는 것 말고 떼는 것을 감지하는 것도 본인은 도스 시절에 개인적으로 경험한 적이 없다.
글쇠를 누르고 있는 동안 해당 문자를 일정 간격으로 반복해서 접수해 주는 것은 컴퓨터 하드웨어 차원에서 행해지는 일인데.. 그런 키보드 속도에 구애받지 않고 누른 것과 뗀 것 자체만을 감지하는 건 특히 게임 만들 때의 필수 테크닉이다.
그랬는데 Windows에서는 모든 글쇠들이 한 치의 차별 없이 WM_KEYDOWN과 WM_KEYUP 메시지 앞에서 평등해지고 가상 키코드값을 부여받게 됐다니~! 정말 혁명 그 자체였다. 프로그래밍 패러다임이 싹 바뀌었다.

가상 키코드는 기반이 전적으로 소프트웨어에 있는 계층이기 때문에 같은 하드웨어에서도 차이가 날 수 있다. 가령, 같은 글쇠에다 가상 키코드를 부여하는 방식은 Windows와 mac이 서로 다를 수 있으며, Windows는 사용하는 키보드 드라이버에 따라서도 차이가 날 수 있다.

Windows의 가상 키코드는 caps lock 내지 shift의 영향을 받지는 않기 때문에 a건 A건 코드값이 같다. 하지만 num lock의 영향은 받기 때문에 키패드 0~9 숫자와 키패드 화살표의 코드값이 서로 다르다. 키패드 numlock 숫자는 진짜 숫자키의 숫자와도 가상 키코드가 다르다.
가상 키코드와 달리 스캔 코드는 각각의 물리적인 글쇠들에 고정불변으로 부여되어 있다. 좌우로 두 개 있는 shift처럼 가상 키코드가 동일한 글쇠는 스캔 코드로 방향을 구분할 수 있다.

요컨대 스캔 코드는 저수준이고 가상 키코드는 고수준이다. 여기에다가 문자 글쇠는 message loop에서 TranslateMessage 함수를 거침으로써 caps lock(대소문자)까지 고려한 실제 입력 문자가 담긴 WM_CHAR로 바뀐다.
WM_CHAR가 생성되는 과정(가상 키코드와 스캔 코드로부터 문자를 얻기)이 별도의 함수로 제공되기도 한다. 바로 ToUnicode 내지 ToAscii이다.

배경 설명이 좀 길어졌는데..
현재 어떤 글쇠가 눌러졌는지 여부를 알려주는 대표적인 함수는 GetKeyState이다. 인자로는 가상 키코드를 주면 되고, 리턴값으로는 2비트의 유의미한 정보가 담긴 BYTE값이 돌아온다.
최상위 비트 0x80은 이 key가 지금 눌렸는지의 여부이고, 최하위 비트 1은 눌렸다 뗐다 toggle 여부이다. 3대 lock들의 램프 점등 여부는 &1을 해 보면 알 수 있다.

심지어 GetKeyboardState 함수는 모든 가상 키코드값에 대한 키보드 상태를 배열 형태로 한꺼번에 되돌려 준다.
컴퓨터 키보드의 글쇠는 많아야 100여 개이지만 가상 키코드의 범위는 0~255라는 바이트 규모이므로 가상 키코드를 할당할 공간은 아주 넉넉한 셈이다.

그런데 Windows에는 GetAsyncKeyState라는 함수도 있다. 무엇이 비동기적이라는 얘기이며 GetKeyState와는 어떤 차이가 있는 걸까..?
GetKeyState는 현재 스레드의 메시지/input 큐 기준으로 WM_KEYDOWN/UP 메시지가 마지막으로 처리되었던 그 순간의 키보드 상태를 일관되게 쭉 되돌린다. 한 메시지가 처리되던 도중에 사용자가 어떤 글쇠를 누르거나 떼더라도 값이 변함없다.
한 컴퓨터에 키보드야 하나만 존재하겠지만, 각 응용 프로그램의 UI 스레드별 키보드 상태는 이론적으로 서로 제각각으로 다를 수 있다.

그 반면, GetAsyncKeyState는 그런 것과 상관없이 시스템 전체의 현재 키보드 상태를 실시간으로 반영해서 알려준다. 그리고 이유는 알 수 없지만 GetKey*는 최상위 bit 크기가 BYTE인 반면, GetAsyncKey*는 최상위 bit 크기가 WORD이다.
둘 다 함수의 리턴 타입은 short로 잡혀 있다. 하지만 전자는 눌려 있는 글쇠를 0x80으로 표현하는 반면, 후자는 0x8000으로 표현한다.

그러면 마우스 휠을 Ctrl을 누른 채로 굴렸는지 감지하고 싶을 때 GetKey*와 GetAsyncKey* 중 무엇을 쓰는 게 좋을까?
프로그램이 사용자의 키보드· 마우스 입력에 0.1초 안으로 정상적으로 반응하고 있는 상태라면 두 함수는 유의미한 차이를 보이지 않는다.

GetAsyncKey*는 내 프로그램이 작업을 하느라 수 초 동안 응답이 멎은 중에 사용자가 ESC를 누른 것 정도나 잡아내는 용도로 쓰면 된다. 아니면 애초에 자기 GUI 창이 없는 콘솔 프로그램에서 키 입력을 감지하는 것 말이다. 얘는 심지어 포커스가 다른 프로그램에 가 있을 때에도 특정 글쇠가 눌린 것을 감지할 수 있다.

이와 달리 GetKey*는 메시지 처리 단위로 실행 결과가 '동기화'돼 있으며, 정확하게 자기 스레드의 UI에 포커스가 가 있을 때 글쇠가 눌린 것만 감지해 준다. 그러니 일반적인 상황에서 우리에게 필요한 것은 대체로 GetAsyncKey*가 아니라 그냥 GetKey*이다.

Async가 붙은 놈이건 안 붙은 넘이건, 이들 함수는 글쇠가 눌린 것을 감지만 하지, 그걸 처리한 것으로 퉁쳐 주지는 않는다. 내 작업 루틴에서 ESC가 눌린 것을 감지해서 하던 작업을 중단했다 하더라도 UI에서 WM_KEYDOWN + VK_ESCAPE 메시지가 가는 것은 변함없다.
이럴 거면 GetAsyncKey*를 호출할 게 아니라 Peek/Get/DispatchMessage로 메시지를 정식으로 처리하는 게 더 낫다. GetAsyncKey*는 쓸 일이 더욱 줄어드는 셈이다.

Posted by 사무엘

지금으로부터 30년쯤 전에 도스용으로 만들어졌던 프로그래밍 툴 중에는 자기 언어로 만들어진 예제 프로그램으로 그럴싸한 게임을 제공하는 경우가 있었다.
QBasic의 경우, 포트리스 내지 Scorched Earth와 비슷한 형태의 턴 기반 슈팅인 '고릴라'가 유명했으며.. 길다란 뱀을 사방으로 적절히 조종하면서 아이템(?)을 먹는 퍼즐인 nibbles도 있었다.

아이템을 먹을수록 뱀은 길이가 더 길어지며, 머리가 벽은 물론이고 자기 몸통과도 부딪치지 않도록 조종을 잘 해야 한다. 그리고 레벨이 올라갈수록 뱀의 이동 속도가 더 올라가고 장애물도 더 많아져서 게임 진행이 더 어려워진다.
영문판 원판은 80*25 텍스트 화면에서도 아스키 그래픽 문자를 적절히 이용해서 글자 한 칸을 상하로 쪼개어 세로 공간을 두 배로 늘리는 편법을 구현했다. 하지만 한글판에서 제공된 nibbles는 문자 코드의 한계로 인해 그런 게 다 삭제되었다.

그런데 가만히 생각해 보니 마소 말고 볼랜드 개발툴에서 제공한 예제 프로그램 중에는 가히 이 분야의 끝판왕이 있었다. 번듯한 체스 게임이 컴퓨터 AI까지 포함해서 소스가 통째로 제공되었던 것이다.

이거 기억하는 분 계신가..?
그런데 이게 bgidemo보다 훨씬 덜 유명하고, 본인도 지난 수십 년 동안 얘의 존재를 까맣게 잊고 있었던 이유는.. 아무래도 아무 버전에서나 쉽게 볼 수 있는 예제는 아니었기 때문이지 싶다.
즉, 보급형인 Turbo가 아니라 기함급인 Borland라는 브랜드가 붙은 C++ 내지 Pascal을 설치하고, Windows 개발 환경에다 자체 프레임워크 라이브러리까지 다 선택해야 얘를 구경하고 돌려볼 수 있다.

이 예제 프로그램의 이름은 볼랜드에서 개발한 C++용 Windows API 프레임워크의 이름을 딴 OWL Chess였다.
하지만 내 기억이 맞다면 Turbo Vision 기반의 도스용 체스 예제도 있었다. 체스판과 말을 그래픽 모드가 아니라 텍스트 모드에서 꽤 기괴한 색과 특수문자를 동원해서 표현했던 걸로 기억하는데.. 정확한 내역은 너무 오래돼서 잘 모르겠다.

Windows용 OWL Chess는 이런 식으로 동작했던 걸로 본인은 기억한다.

• 16비트 전용이다. 32비트 에디션에도 포함됐다거나, Delphi 및 C++ Builder 같은 후대의 컴포넌트 기반 RAD툴로 리메이크 됐다는 소식은 내가 아는 한 없다. 그러니 얘는 Windows XP에서 실행됐을 때도, 저 스크린샷에서 보다시피 프로그램의 제목 표시줄에 테마가 적용돼 있지 않다.
• 역시 저 스크린샷에서 묘사된 바와 같이, 창 크기는 고정 불변이다. 요즘처럼 모니터가 크고 화면 해상도가 높은 시대엔 크기 조절이 안 되는 프로그램은 사용자에게 좋은 인상을 주기 어려울 것이다.
• 키보드 포커스가 딴데로 넘어가서 프로그램이 비활성화 되면 즉시 게임판이 가려지고 pause 모드로 바뀐다.
• 컴퓨터 AI는 1990년대의 바둑 같은 보드 게임 AI들이 그랬던 것처럼 규칙 기반으로 move를 평가하고, 재귀적으로 수읽기를 하면서 알파-베타 가지치기로 복잡도를 제어하는 식으로 구현됐다. 생각하는 데 시간이 많이 걸리긴 하지만, 멀티스레드라는 것도 없던 시절에 이 동작이 찔끔찔끔 idle time processing만으로 잘 만들어져 있다. 컴퓨터의 생각이 현재 어느 정도까지 진행됐는지가 수시로 현란하게 시각적으로 표시되기 때문에 지겹지 않다.

하긴, 1990년대 초중반에는 프로그래밍깨나 공부 좀 한 사람들이 도스의 그래픽 모드에서 아기자기한 오목· 장기 게임을 구현해서 PC 통신 자료실에 무료로 공개한 게 많았다. 아, 심지어 화투 치는 고도리...도 그 시절부터 있었다.
또한 그 시절에 유명한 프로그래밍 기술 간행물이던 '비트 프로젝트' 시리즈에도 초창기엔 Borland C++로 개발한 Windows용 장기 게임이 있었다.

지금이야 국내에서 유료 판매까지 되고 있는 장기 게임 프로그램으로는 '장기도사'가 있다. 하지만 그 전에는 '바다장기'라는 프로그램도 있었는데, 얘가 내 기억이 맞다면 저 원조 OWL Chess의 소스를 기반으로 만들어진 듯했다.
프로그램의 외형과 동작이 굉장히 비슷하게 느껴졌었기 때문이다. 또한 바다장기도 검색을 해 보면 16비트스러운 스크린샷밖에 안 나오는 게 더욱 비슷하다.

그래도 서양의 체스와 동양의 장기가 완전히 동일한 게임은 아닐 텐데, 체스 AI를 장기 AI로 룰을 개조하는 건 건 아무나 할 수 있는 일이 아니었을 것이다. 그리고 그 원판 AI 코드도 move를 기술하고 평가하는 룰 계층만 바꿔 주면 어지간한 보드 게임의 AI에 모두 대응 가능하도록 상당히 추상적이고 깔끔하게 잘 만들어져 있었던 모양이다. 바다장기는 AI를 '추론 엔진'이라는 용어를 써서 표현했다.

일개 예제 프로그램의 체스 AI가 전문 상업용 AI에 비할 바는 아니겠지만.. 이 정도만 해도 어디인가? 지금 저 프로그램의 소스를 다시 볼 수 있으면 보드 게임 AI의 구현과 관련해서 많은 통찰을 얻을 수 있을 텐데 아쉽다. 얘의 소스만 어디 github에 따로 올라와도 될 텐데 말이다.
본인은 체스는 룰조차도 모르지만.. 그래도 학창 시절에 오목과 스크래블이라는 보드 게임 AI를 연구했던 이력이 있는 사람이어서 이런 쪽에 더욱 흥미를 느낀다.

Posted by 사무엘

1764년부터 1767년 사이에 프랑스의 Gevaudan이라고 불리던 지역에서는 정체 모를 시커먼 괴물 맹수가 출현하여 사람을 죽이고 잡아먹어서 주민들이 극심한 공포에 떨었다고 한다. 총 희생자 수는 피격 210명에 사망자가 무려 113명에 달했다. 단시간에 여러 지역에서 한꺼번에 피해가 보고된 적이 있는 걸 보면, 한 마리만 있는 것도 아니었다.

18세기이면 막 황당무계할 정도의 옛날이 아니다. 더구나 유럽에서 나름 수학과 과학이 발달하고 선진국 축에 들던 프랑스에서 저런 괴수가 나타났다는 것은 비록 사진이나 박제 현물이 없어서 아쉽지만, 문헌과 그림이 있고 외국의 동시대 기록을 통해 교차 검증까지 되는 100% 팩트이다. 단순 괴담 도시전설이 절대 아니다.

그럼 그 맹수의 정체는 정확히 무엇이었을까?
지금으로서는 그냥 커다란 늑대, 아니면 그냥 하이에나 같은 평범한 개과 부류가 아니었을까 추정되지만.. 당대 사람들은 단순 늑대가 아니라 beast라고 적었다.
덩치가 꽤 컸으며(특히 머리와 입과 이빨) 시커먼(검붉은?) 털에 온몸이 악취로 가득했다고 한다. 박제가 보존되지 못한 이유 중 하나도 지독한 악취였다고..

평범한 맹수라면 사냥감을 목을 물어 죽였을 텐데, 이놈은 강력한 턱과 이빨로 목이 아니라 말 그대로 대가리를 물어서 깨뜨리는 식으로 공격했으며.. 가축보다도 사람을 일부러 더 공격했다고 한다! 이 정도면 정말 평범하지는 않아 보인다. 게임에서나 볼 수 있는 비현실적인 몬스터에 근접한 건지도..??
그나마 인간이 아닌 짐승인 덕분에, 도구를 쓰거나 뭘 던진다거나 하지는 않았다.

인제 와서 놈의 정체를 알 수는 없지만, 그래도 그 당시에 군대까지 동원하여 의심 개체를 모조리 사살하고 토벌한 뒤부터는 다행히 이런 피해가 더 발생하지 않았다고 한다.

이건 마치 15세기에 스코틀랜드에서 수많은 사람들을 죽이고 잡아먹다가 결국은 발각되어 처형된 식인귀 소이 빈 패밀리..;;
19세기 말에 미국에서 수많은 양과 소들을 지능적으로 학살하면서 농장주들을 치를 떨게 만들었던 시튼 동물기 이리 왕 로보..
이런 얘기처럼 들린다.

인간이 기관총을 발명해서 자연 먹이 사슬의 최강자로 군림하기 전까지는 동양 서양 할 것 없이 산에서 호랑이나 늑대에게 물려 죽거나 심지어 잡아먹히는 사람도 매년  장난 아니게 많았다. 옛날 어린이들의 3대 재앙 중에 "호환"이 괜히 포함된 게 아니었다. 이를 생각하면 '제보당의 괴수'가 창궐하던 시절과 지금 사이에 참 격세지감이 느껴진다.
괴짐승에 대한 온갖 묘사가 적혀 있고 독자가 그걸 읽으면서 짐승의 정체를 추론하는 게.. 무슨 성경에 묘사된 짐승의 묘사를 읽는 것 같은 느낌이 들기도 한다.

또한, 프랑스는 안 그래도 "미녀와 야수" 스토리의 원산지 같은 느낌적인 느낌이 있는데, 그 동네에서 정체불명의 야수 괴수에 의한 끔찍한 인명 피해가 실제로 있었다는 것도 매우 놀랍다.
이 스토리는 이미 2001년에 <늑대의 후예들>이라는 제목으로 프랑스에서 영화화도 됐다. 영화로 만들기 좋은 소재인 것 같다. 한국 영화 <대호>의 프랑스 버전과 비슷하게 대응될까? ㄲㄲ 공포에 질린 주민들, 괴수 잡으러 파견된 사냥꾼, 그리고 괴수를 잡았다고 거짓 보고를 올리면서 비리를 저지르는 부패 정치인 등.. 뭔가 프랑스 식으로 정의를 추구한다는 냄새가 느껴진다.

우리나라는 옛날에 아동용 반공물 내지 각종 반공 포스터에서 북괴 공산당을 딱 저런 괴물로 묘사하는 편이었다.

개인적으로 제보당의 괴수의 이미지와 좀 오버랩 되는 것 같다.;; 물론 저 괴수보다는 작고 귀엽게(?) 그려졌지만.. (1950년대 어느 고딩들의 멸공 북진통일 퍼레이드 모습)

Posted by 사무엘

날개셋 한글 입력기가 10.1 이후 4개월 만에 다음 버전(10.2)이 나왔다.
아아.. 개발자의 역량의 한계로 인해 날개셋 한글 입력기의 개발 속도가 점점 느려지는 것 같다. 변화 내역을 보니 옛날 같았으면 버전을 0.1만치 올릴 분량이 안 되는 것 같은데.. -_-;;

그래도 시간이 4개월이나 지났고 아이템들이 마냥 사소한 것만 있지는 않으며, 나름 버전이 10.x인데 굳이 소수점 둘째 자리를 건드릴 필요는 없다는 점을 감안하야 다음 버전을 10.1x 대신 10.2로 정했다.
두 달 전에 소식을 먼저 전했던 바와 같이 외부 모듈의 동작 방식이 개선된 것이 가장 큰 자랑거리이며, 제어판의 외부 모듈 관리 페이지가 동작이 개선된 것도 개인적으로 뿌듯하게 생각한다. 그것 말고 다른 변화를 열거하자면 다음과 같다.

1. 외부 모듈에 자체적으로 겹침 모드 지원

날개셋 한글 입력기 외부 모듈에서 도구모음줄의 버튼들의 종류와 역할은 거의 3.x 버전 시절부터 15년 가까이 변화가 없었다. 그랬는데 이번에 마이너한 버튼이 하나 추가되었다. 바로 자체적인 삽입/겹침 모드 전환이다.

삽입/겹침 모드는 바로 전 10.1 버전부터 이제 날개셋 제어판에서 지정하는 설정이 아니라 각 구현체들이 자체적으로 관리하는 상태로 위상이 바뀌었다.
편집기(= 날개셋 자체 에디트 컨트롤)은 ins 키 내지 상태 표시줄을 클릭해서 삽입/겹침을 지정할 수 있는 반면, 외부 모듈은 그런 게 없었다. 그래서 10.2에서는 이를 보완하는 별도의 버튼이 추가된 것이다.

물론 이 모드는 TSF가 제대로 지원되는 환경에서만 의미를 가지며, 90% 이상의 상황에서는 그냥 삽입 모드로 동작한다. 궁극적으로는 응용 프로그램이 제공하는 겹침 모드와 외부 모듈이 동작하는 겹침 모드가 서로 자동으로 연계되는 게 가장 좋지만.. 그렇지 못한 현 상황에서는 이렇게 아쉬운 대로 겹침 모드를 지정할 수 있게 했다.

아울러, 날개셋 편집기는 1.0 이래로 ins는 삽입/겹침 상태만 전환하고 shift+ins는 낱자/글자만 전환했었다.
그러던 것을 Shift+ins를 누르면 곧장 '낱자+겹침' 모드로 진입하고, ins를 누르면 곧장 '글자+삽입' 모드로 전환되게 동작을 수정했다. 필요할 때 낱자 겹침 모드로 곧장 진입했다가 신속하게 이전 모드로 복귀할 수 있게 한 것이다. 구체적인 동작 로직은 다음과 같다.

아 참.. Windows 10에서는 도구모음줄 버튼들이 저렇게 길게 표시되지 않으니 삽입/겹침 모드도 저렇게 우클릭 메뉴에서 선택해야 한다.
이거 손보는 김에 전자/반자 버튼에 해당하는 메뉴도 수정했다. 지금까지 체크 표시 달랑 하나로 전/반 모드를 나타냈는데.. 그걸 별도의 팝업 메뉴를 통해 선택하고 라디오 버튼 모양을 통해 현재 모드를 나타내게 했다.

정보량이 1비트라고 해서 아무데서나 체크 UI를 사용하지는 말아야 하기 때문이다. 가령, 남/녀 성별을 ‘여자임 체크’ 이런 식으로 지정해서는 안 될 것이다. ㄲㄲㄲ
그나저나 상태 표시줄과 입력 도구모음줄이 동시에 나타나 보이는 버그는 Windows 10 [2004] 버전에서도 고쳐지질 않고 있구나. 이쪽은 아예 out of 안중인 걸까..?

2. 단어 경계 인식 방식 개선

그리고 편집기에서 역시 10년 넘게 변함없던 단어 단위 식별 방식을 개선했다.
일정 길이 이하의 짧은 단어에 대해서는 알파벳, 밑줄, 숫자를 한 덩어리로 인식하게 했다. 이건 텍스트의 더블 클릭 내지 Ctrl+(좌우 화살표/bksp/del)에서 동작을 확인할 수 있다.

이렇게 하니 프로그램 소스 코드에서 16진수 상수나 변수 명칭들이 정확하게 한 단어로 인식되기 때문에 프로그램의 사용성 내지 편의성이 훨씬 더 나아졌다. 문자의 종류가 바뀐다고 괜히 그 안에서 멈출 필요가 없었다. 왜 진작부터 이런 조치를 취하지 않았나 모르겠다.

3. 나머지 자잘한 변화

다음과 같이 여러 자잘한 부분이 수정되고 개선됐다. 심지어 여기에 기록되지 않은 더 자잘한 사항도 있다.

• 휠을 눌렀을 때 나타나는 동그란 자동 스크롤 패드 그림의 가장자리에다 그림자 효과 추가
  
• 편집기 파일 메뉴의 최근 사용 파일 목록에서 현재 열려 있는 파일은 체크 표시
  
• 24픽셀 크기에 대해 U+1D00~U+1FFF 비트맵 글립 추가
  
• 편집기의 색깔 구성표에 '민트색'도 추가
  
• 제어판의 입력 항목 정보 페이지에서.. 외부 키보드 드라이버 같은 파일을 열었던 내역이 날아가 버리던 문제 해결. 다음에 열기/저장을 할 때 보존되게 함
  
• 제어판의 '입력 일반' 탭에서 사용자 정의 제2/제3 후보 관련 설정 UI를 더 직관적으로 개선함
  
• 입력 도구를 닫았다가 다시 열 때, 무조건 이전 위치가 아니라 현재 존재하는 모니터의 영역도 감안해서 표시되게 개선

※ 넋두리: 디지털 서명의 필요성

2020년대를 맞이하여 날개셋 한글 입력기가 내부의 기능 개발 말고 외부 환경과 관련하여 앞으로 이뤘으면 하는 과업이 두 가지 있다. 하나는 ARM64 지원, 그리고 다른 하나는 디지털 서명이다.;;
전자를 하려면 아무래도 개발용 기기를 구매해야 하는데 본인이 딱히 그걸 들여다 볼 여유가 없다.

그리고 후자도.. 인터넷을 찾아보니 사업자 등록증 없는 개인 개미 개발자에게도 인증서를 발급하는 기관이 있긴 하다. 하지만 이것도 어떤 형태로든 돈이 10만원 이상씩 깨지며, 그것도 한 번만 내고 끝이 아니라 지속적으로 홈페이지 유지 비용만치는 지불해야 한다.

아직까지 디지털 서명 없이 버티고는 있지만.. 이걸 안 하니 각종 게임이나 운영체제의 보안 솔루션에 의해 내 입력기가 강제 종료되거나 심지어 강제 삭제된다는 신고가 심심찮게 들어온다. 이것도 언제까지나 방치할 수는 없는 사항인데 좀 고민된다. 이와 관련하여 최근에 있었던 일을 좀 소개하고자 한다.

하루는 어느 온라인 게임 개발사에서 메일이 왔다. 자기들 게임에서 님하의 입력기를 구동했더니 자꾸 뻗는다면서 crash 덤프 파일을 몇 개 보내 줬는데..
일단, 3년도 더 전에 나왔던 9.5부터 포함해 9.6, 9.8x 등 구버전이 아직도 많이 쓰이고 있다니 놀랐다. 10.0이나 10.1 덤프는 없었다.

하긴 내 프로그램은 자동 업데이트 기능이 없고 딱히 사용 내역 데이터 수집 같은 걸 하지도 않으니, 내 프로그램이 사용자들에게 어떤 형태로 쓰이는지는 나도 전혀 알지 못한다.
뭐, 사용자도 내 홈페이지를 일부러 들어가지 않는다면 프로그램 새 버전을 전혀 접할 수 없을 것이다.

버전은 그렇다 치고.. 내 입력기가 뻗는 이유는 커널인 ngs3.dll이 디지털 서명을 받지 않았다는 이유로 출처가 의심돼서.. 그 게임 내부의 보안 솔루션이 로딩과 실행을 차단했기 때문이었다.
파일이 아예 없는 경우라면 내 입력기도 대비가 돼 있어서 동작을 전혀 못 할지언정 뻗지는 않게 돼 있는데..
뻔히 로딩이 된 뒤에 보안 솔루션이 개입해서 ngs3.dll을 없애 버리는 듯했다.

흐음.. 보안 솔루션이 키보드 드라이버의 동작을 바꿔서 한글 IME의 동작까지 교란시키는 경우는 이미 잘 알려졌지만, 아예 이런 식으로 디지털 서명이 없는 DLL의 로딩에도 관여할 수 있다는 걸 알게 됐다.

Posted by 사무엘

먼 옛날에 인간이 아폴로 우주선을 타고 달에 직접 다녀오는 정말 초유의 이벤트가 벌어졌을 때, 정말 세계가 열광했다.
우리나라는 1969년 7월 21일 월요일, 아폴로 11호 달 착륙일 당일을 임시공휴일로 지정했다. 지구 반대편의 온두라스와 엘살바도르는 전쟁 중이었는데, 저거 중계방송을 다같이 시청하려고 잠시 휴전을 했을 정도였다.

그 시절 수많은 꼬꼬마들이 저 광경을 보면서 나도 공부 열심히 해서 공무원이나 연예인이 아니라 위대한 과학자/공학자가 되고 싶다고 장래희망을 굳혔다.
그리고 2000년쯤이면 인간이 화성에도 가고 달에 식민지 하나 정도 건설될 거라고 생각했다.

그 분위기에 편승하여 우주를 배경으로 다리 달린 로봇이 나오는 수많은 SF물들이 만들어졌다.
그런 작품에서는 비행기처럼 날개 달리고 항공역학적으로 아주 새끈하게 만들어진 전혀 현실적이지 않은 비행체들이 우주에서 전투를 벌이면서 외계인 군단을 때려잡았다. (그에 비해 실제 아폴로 우주선 LM 달 착륙선의 모양은... ㄲㄲㄲㄲㄲ)

허나, 실제로 2020년이 돼 보니 현재 인간의 우주 진출 현황은 어찌 됐나..??
2001 스페이스 오디세이 영화에서 묘사됐던 2001년과, 실제 2001년의 차이는..??
더 이상의 설명이 필요하지 않을 것이다. 물론 지난 수십 년 동안 천문학도 발전하고 항공우주 기계공학 기술도 눈부시게 더 발전했지만.. 그것과 유인 달 탐사 내지 우주 식민지 개발은 별개의 문제였다. 우주 개발은 전쟁이나 결혼 생활만큼이나 매체(게임, 영화..)와 현실과의 괴리가 매우 매우 큰 분야이다.

그런데 이와 비슷한 식의 설레발이 세상뿐만 아니라 기독교계에도 미래 예언과 관련하여 많이 있었음을 나는 신자로서 인정하지 않을 수 없다.

본인은 개인적으로 성경을 문자적으로 해석하고 적용을 넓게 영적으로 하는 방법론이 가장 건전하다고 생각하며 이를 지지한다.
6일이나 7년이나 1000년 같은 기간을 특별한 다른 단서가 없는 한 문자적으로 받아들인다. 당장 이해가 안 되고 실감이 안 가는 부분이 있어도.. 판단을 보류하고 가만히 묻어 둘지언정, 말을 제멋대로 바꾸고 뜯어고치지 않는다.

구약과 신약을 구분하고, 유대인과 교회를 구분하고, 하늘의 왕국과 하나님의 왕국을 구분하고, 영과 혼을 가능한 한 구분하고, '채우다'와 '다시 채우다'를 구분하고.. 그러니 세대주의에 대해서도 태생적으로 우호적인 입장이었다.
그런데 이게 왜 이렇게 대외적으로 평이 안 좋은가 했더니.. 시한부 종말론과 얽혀서 오해를 살 짓을 한 게 있긴 했다.

인류의 시작과 과거 역사가 4천 년쯤 전으로 굉장히 구체적인 값이 나오니, 인류의 종말 시기도 지금쯤이면 굉장히 가까워진다.
물론 세대주의 자체가 어디 악성 이단 사이비처럼 몇 월 며칠에 휴거가 일어날 것이니 “직장 그만두고 산속에 들어가고 재산 다 교회에 갖다바쳐라” 같은 미친 짓을 권장하고 조장하지는 않는다. 하지만 저런 움직임이 발생할 빌미는 제공했으며, 결정적으로 종말의 징조, 조짐과 관련하여 지금까지 불발한 설레발을 너무 많이 쳤었다.

• 이스라엘 건국
• 유럽 연합 결성
• 20세기의 아주 카리스마 넘치던 모 교황과 세계적인 에큐메니즘 운동, 세기말 Y2K 문제
• 그러면서 세계 단일 정부 단일 종교 떡밥..

이런 거 말이다.

아, 20세기 중반부터 일어난 저런 사건들이 과거에는 정말 상상도 할 수 없었던 대격변인 건 사실이다. 아폴로 우주선 달 착륙에 비견될 만도 하다.
그리고 세상은 갈수록 악해지고 빗장 풀리고 타락하고 심판을 향해 나아가고 있다는 ‘큰 그림’ 역시 사실이다. 뭔가 성경적으로 의미 부여를 하고 싶은 그 심정은 이해가 된다. 전부 비유 묵시라고 헛소리 하는 것보다는, 조금이라도 갖다붙이고 적용하려고 노력해 보는 게 차라리 더 나은 자세이기도 하다.

그렇지만 그런 국제 정세나 과학 기술은 아주 상대적이고 가변적인 요소이다. 언제라도 “아니었나 보네, 아님 말고”를 시전하면서 버릴 수 있게, 여러 가능성 중 하나로서 아주 가볍고 얕게 참고만 하고 있어야 하는 사항이다. 성경에는 인류의 역사와 관련하여 철기 시대, 불의 발견, 바퀴의 발명조차도 나와 있지 않다는 걸 생각하자.

아예 초대 교회 사람들부터가 “이때쯤 예수님이 다시 오시겠지..” 생각하다가 죽었고, 중세 때 스코틀랜드 교회 사람들은 저 교황이 '그' 적그리스도일 거라고 생각했다. 그 교황이 소속된 집단이 몇백 년 뒤에는 개신교를 상대로 에큐메니즘 운동을 주관하는 날이 올 거라고 그 옛날 사람들이 감히 상상할 수 있었을까?

컴퓨터만 해도.. 오늘날 같은 극도의 정보화 시대가 순기능만 있는 것은 물론 아닐 것이다. 지금 전자, 컴공, 언어 처리, 바이오 등 분야를 막론하고 이공계들이 추구하는 상당수의 목표는 인간을 닮고 인간처럼 생각하면서 인간의 취향을 정확하게 저격할 줄 아는 기계를 만드는 것이다. 그걸 만들기 위한 밑천인 실제 인간 군상들의 동선과 행적 데이터를 수집하고 처리하는 기반도 다~~ 갖춰져 있다. 이게 마냥 좋은 의도로만 쓰일 거라고 100% 장담할 수는 없다.

다만, 최소한 1980년대에 우려했던 것처럼 금수저들만 비싼 컴퓨터를 마음껏 쓰면서 정보와 기술을 독점하고 대중을 통제하는 무식한 사회 같은 건 전혀 실현되지 않았다. 그 시절 음모론자들은 블랙박스와 CCTV 덕분에 질서와 치안이 상상을 초월하게 개선되는 것, 그리고 오픈소스 진영이 등장해서 정말 과거에 상상도 할 수 없었던 양의 정보와 기술들이 무료로 풀릴 것을 예상하지는 못했다.

성경에서 용이 불을 뿜는 게 미래에 등장하는 탱크나 미사일을 의미하는 거라고 이상하게 갖다붙이는 사람도 있고,
한술 더 떠서 미래엔 석유가 고갈되어서 사람들이 성경의 묘사대로 문자 그대로 다시 말 타고 냉병기를 들고 싸우게 될 거라고.. 아인슈타인이 3차 세계대전 이후 다음 전쟁의 양상을 예측했던 것과 같은 추측을 하는 사람도 있다.
뭐 그럴 수도 있지만 후자조차도 100% 장담은 하기 어렵다. 2010년대부터 셰일 가스가 재발굴되어 지금처럼 다시 기름값이 팍 내려가고 석유 고갈 예상 시기가 한참 늦춰질 거라는 점까지 예상한 사람은 내가 못 봤다.

그러니.. 성경으로 미래 전망은 함부로 설레발 치지 말고 영원까지 길게 보는 안목을 갖고, 한낱 국제 정세나 일개 과학 기술에 너무 일희일비하지 말고.. 불가지론에 가까운 냉정한 자세로 판단해야 한다고 여겨진다.
성경은 거의 1900년 전의 요한계시록 기록 시점부터 "내(예수)가 속히 오리라(come quickly)"라고 약속해 놓았다. 도대체 어느 기준으로 '속히'인지에 대해 진지하게 고찰할 필요가 있다.

세상 정세와는 아무 상관 없이 “예수님이 지금이라도 다시 오실 수 있겠구나”, 핵무기고 스마트폰이고 구글이고 중공 폐렴이고 전부 다 “이 또한 지나가리라, 아 그땐 그랬지” 이렇게 회상할 각오를 하고..
따분하고 재미없어 보이지만 그냥 원론적인 지침에 충실하며 사는 수밖에 없다. 그것만이 최후 승자가 되는 길이라고 생각된다. 신의 존재 여부야 불가지론의 대상이 아니지만, 종말 내지 예수님 재림 시기는 인간들 입장에서는 불가지론인 게 맞다고 성경에서 대놓고 쓰여 있지 않은가?

이런 생각으로 살지 않고 어설픈 사회 정세 음모론에다가 믿음의 근간을 두면.. 그 음모론이나 예상이 빗나갔을 때 다른 성경의 건전한 가르침까지 같은 급으로 매도되고 부정당하게 되기 때문이다. 그것 때문에 초신자가 실족하고 믿음이 파괴되는 일이 생겨서는 안 된다.

지금은 무려 2020년이다. 이제는 근미래에 대해서 과거에 전망했던 것, 그리고 빗나간 예언들에 대한 경험과 데이터도 그럭저럭 쌓이고 있는 중이다. 다미선교회 병크, Y2K 설레발, 2012년 종말 떡밥.. 전부 도대체 몇 년 전의 해프닝이 되고 있나? 이 와중에 아직 바코드, 베리칩 음모론 믿는 사람은 좀 없어야 하지 않냐 말이다.
그럼에도 불구하고 요한계시록에서 묘사된 실제 대환란기는 언제쯤 어떤 형태로 실현될지 개인적으로는 노무노무 궁금해 죽겠다. 정말 흥미진진한 사건이 될 것이다.

1940년대 말, 우리나라의 반민특위 재판정에서 “조선이 해방될지 몰랐으니까~!!”라고 변명하고 절규하는 사람들이 많았는지는 모르겠다.
하지만 그리스도의 심판석에서는 “예수님이 그렇게 꿈에도 상상 못 하던 시기에 덥석 오실 줄은 정말 몰랐으니까(요)!! / 내가 이렇게 갑작스럽게 죽게 될 줄은 상상도 못 했어요~! ㅠㅠㅠ” 이렇게 변명하고 절규하는 사람들이 분명 엄청나게 많이 나올 것이다.

그리고 천국 가면.. 모인 사람들끼리 아마,

• "라떼는 말이야 성경 몰래 베껴가면서 읽다가 걸리면 화형이었어"
  
• "라떼는 말이야 영어 성경이 200종류가 넘게 나왔고 역본 내용의 차이 갖고 키배가 벌어졌어"
  
• "흥, 나는 그 세상에서 살아 본 적도 없이 바로 왔거든?" (☜ 이 케이스가 아마 제일 많을 것임..)
  
• "웃기시네. 니들이 공중으로 번개같이 들려 올라가는 그 느낌을 알아?"

서로 출신과 배경 갖고 약간의 알력 싸움이 벌어지지 않을까 개인적으로 생각....한다.
물론 성품이 변화된 뒤이기 때문에 선 넘는 진흙탕 싸움이 되지는 않을 것이다. -_-;;

Posted by 사무엘

0.
지난 2월은 직장을 옮긴 것, 요 근래에 누적된 야근· 초과 근무 수당, 그리고 연말정산 환급이 더해져서 급여가 평소보다 꽤 많이 나왔다.
마치 여객기가.. 전투기처럼 상시 초음속 비행은 못 하지만, 제트 기류 뒷바람을 잘 탄 거나 하강이라는 변수까지 더해져서 일시적으로 초음속 비행을 하는 것 같은 느낌이었다.

뭐, 정말 잘나가는 능력자들은 2월 뽀록이 났을 때가 아니라 평소에 이만치, 아니 그 이상도 더 벌 것이다. 특히 올해는 넥슨과 넷마블에서 전사원 연봉을 크게 인상한 것이 매스컴에 대대적으로 보도되기도 했다.
하지만 나로서는 우한 폐렴 타격 따위 없이 일거리가 넘쳐나는 이 정도 직장이 있는 것만으로도 반가운 노릇이다.

난 15년쯤 전에 병특을 하면서 앞으로 게임 업계엔 절대로 종사하지 않을 거라고 다짐-_-을 했었다;;
회사의 근무 여건이나 복리후생이 불만족스러워서가 아니라, 내가 온라인 게임을 즐기거나 만드는 쪽 적성이 아니었기 때문이다.
그리고 개인적으로는 게임은 이제 나올 거 다 나왔고 혁신이란 게 거의 끝났다고 생각해서 더욱 발길이 꺼려졌다. 블리자드, id, SEGA 같은 전설적인 개발사들이 과거의 명성을 다 날려먹고 괜히 삽질· 몰락하는 게 아니라고 여겨진다.

하지만 한편으로는 이것도 나의 단견일 뿐이고 NC 같은 곳은 리니지 모바일 하나 잘 만들어서 또 돈을 빗자루로 쓸어담고 있다.;;
SI나 정부 과제나 대기업 납품에 의존하지 않고 자체적으로 뭔가 독창적인 걸 만들어서 end user를 상대로 장사를 할 수 있는 분야가 그나마 게임이긴 하다.

어차피 월화수목금금금 갈려 들어가는 건 마찬가지라면, 넥슨이나 넷마블 같은 곳에 들어가면 그래도 월급이라도 많이 받을 수 있다. 그러니 거긴 아무리 판교의 등대, 구로의 등대 운운하더라도 똑똑한 프로그래머들이 몰리는 것 같다.
뭐 그건 그렇고.. 오늘은 2021년 봄을 맞이하며 접한 여러 주변 소식, 그리고 개인적인 근황을 잡생각들을 늘어놓도록 하겠다.

1.
최소 20년이 넘는 유구한 역사를 자랑하던 중앙선 청량리-부전 심야 열차가 딱 올해 초(2021년 1월 5일)에 폐지돼 없어졌다..;; ㅠㅠㅠㅠㅠㅠㅠ 난 이 사실을 뒤늦게 알게 됐다.

이런 열차가 있다는 걸 내가 처음으로 알게 된 건 2003년 말, 서울-경주 저녁 6:30 새마을호를 놓쳐서 대체 교통편을 찾던 때였다.
사실 이건 Looking for you를 들을 기회를 한번 날려 버린 치명적인 실수였다. 나의 공식적인 철(도 성)령 강림일이 2004년 1월 31일 제 4타째였는데, 저 새마을호를 안 놓치고 탔으면 철령 강림일이 더 앞당겨질 수도 있었다.

서울 역 대신 청량리 역에서 밤 9시에 출발해서 고향 경주로 가는 무궁화호 열차가 있다고 해서 잘 이용했고, 본인은 그 뒤로도 지난 20여 년 동안 얘를 종종 탔다.
하행보다는 상행을 더 자주 이용했다. 경주에서 0시 무렵에 출발해서 서울에 딱 아침 6시쯤에 도착하는 놈이었다.

너무 북적대는 경부선의 대구-구미-대전-천안이 아니라 영천-의성-안동-영주-제천.. 이름부터가 정겹게 느껴졌다. 얘를 타면 고속도로나 고속철에 비해 뭔가 시간이 정지하고 속세를 떠난 듯한 느낌마저 들었다.
처음에는 시각표 상으로 청량리-경주가 무려 6시간 반이나 걸렸다. 그러다가 중앙선이 복선화와 선형 개량, 증속이 거듭되면서 2010년대 중후반부터는 5시간 반대로 많이 줄어들었다.

우리나라는 침대차가 진작에 퇴출됐고 심야열차라는 게 없어지는 추세인데, 그나마 최후의 보루로 꿋꿋이 남아 있었던 중앙선 밤차마저 드디어 역사 속으로 사라지다니 아쉽고 허전하다.
이제 얼마 안 있으면 기존 경주 역과 서경주 역 자체가 영업을 중단해 버리고, 신경주 역이 일반열차까지 같이 취급하게 될 것이다.

2.
본인은 지난 겨울엔 어느 때보다도 야영 외박을 많이 했다. 산과 강, 각종 오지에 가서 텐트를 쳤을 뿐만 아니라 꽁꽁 얼음 위에서도 몇 번 성공적으로 자고 왔다.

.내 경험상 -10에서 -5도 사이 정도가 침낭과 담요와 패딩 잠바가 제 성능을 발휘하면서 밖에서 자기 좋은 최적의 환경이었던 것 같다.
화학에서 물질의 상평형이던가, 이상기체의 부피던가 머시기 할 때는 온도-압력이라는 변수에 대한 그래프를 그렸던 것 같은데...

사람의 거주 쾌적성을 나타낼 때는 압력은 무슨 멕시코시티 같은 특이한 고지대가 아닌 한 별 관계 없을 것이다. 그냥 온도-습도를 변수로 삼아야 하지 싶다.
무거운 담요와 침낭을 들고 다니느라 불평하는 게 아니라 이 추위를 즐길 수 있을 때 감사하고 즐기는 것이 진정한 야인 자연인의 자세이다.

이건 지난 설날 때 고향에서 아무도 없는 어느 공원 풀밭에 텐트를 치고 잤던 당시의 모습이다.

그리고 얼음에 이어.. 산 속 군용 벙커에서 하룻밤 자는 데 성공했다~! 밖에 눈이나 비가 왔으면 더 아늑하고 좋았을 텐데. 여기는 텐트를 칠 필요가 없으니 돗자리만 깔았다. ^^

오오~ 그러고 보니 벙커도 외관이 뭔가 비슷하게 생긴 구석이 있었구나~! 돌문만 없을 뿐.

해뜰녘에 눈을 떠서 내가 간밤에 머물렀던 곳의 어귀를 내려다보니까 문득 이런 생각이 들었다.
"주의 첫날 매우 이른 아침 곧 해 돋을 때에 그들이 돌무덤에 가며 자기들끼리 이르되, 누가 우리를 위하여 돌무덤 입구에서 돌을 굴려 주리요? 하고 바라볼 때에 돌이 이미 굴려져 있음을 보았으니 이는 그 돌이 심히 컸기 때문이더라~~" (막 16:2-4)
더 이상의 자세한 설명은 생략한다.

3.
2021년에 대한민국 땅에서 이런 등록문화재 실물을 구경하게 될 줄이야..
차주가 존경스럽다.

개인적으론 그리 멀지 않은 과거(1~2년쯤 전?)에 각그랜저와 쏘나타 Y2 모델(스텔라 바로 다음의 그 초기형), 그리고 에스페로를 목격한 적이 있었다. 시간 여행이 따로 없었음..
옛날에 SBS 모닝와이드 블랙박스로 본 세상의 어느 에피소드에서는 그 귀하신 각그랜저 하나가 애석하게도 교차로에서 접촉 사고의 희생양이 되기도 했더라만.. 너무 옛날 차여서 수리하기 꽤 난감했을 것 같다.

컴퓨터 소프트웨어가 다음 버전의 출시 이후 n년까지 mainstream support, 그 다음 n년까지 extended support 같은 생명 주기가 있는 것처럼.. 자동차도 다음 모델의 출시 이후 n년까지 수리용 부품 지원 같은 정책이 공식적으로 존재하지 싶다.
제주도 내지 강원도 산골짜기에서 제무시 트럭 내지 새한 덤프 트럭이 “아직도” 현역인지 그것도 궁금하다.

4.
끝으로, 나의 사랑하는 책, 비록 해어졌으나..
There's a dear and precious book, Tho' it's worn and faded now, Which recalls the happy days of long ago

2005년쯤인가 친구에게서 선물 받아서 15년이 넘게 애용했던 영어 성경책.
주머니에 쏙 들어가는 크기 덕분에 휴대성 하나는 정말 만족스러웠으나..
가는 세월을 이기지 못하고 가죽이 몽땅 떨어져 나가고 앞뒤 종이까지 뜯겨지는 매우 안습한 처지가 되었다.

울 교회의 목사님께서 이를 위하야 어엿비 너겨 저거보다는 더 두껍고 크지만 그래도 여전히 휴대성이 나쁘지 않은 다른 성경책을 하사해 주시였다. 감사합니다~!
나는 찬송가 책도 5년 남짓 봤는데 표지와 종이가 이미 10년 넘은 연식처럼 해지고 너덜거린다.
곡 고르느라 매주 굉장히 많이 뒤적이기 때문이다.
Random access를 많이 시키면 하드디스크 수명이 짧아지듯이 종이책도 마찬가지이다.

Posted by 사무엘