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

1. 선택과 책임 (1)

지난 2010년 10월 경에 미국 테네시 주 사우스풀턴 시에서는 가정집에서 화재가 났는데 그 지역 의용소방대에서는 뻔히 보고도 불을 꺼 주지 않은 일이 있었다.
왜냐하면 그 집은 연 75$인 회비를 내지 않았고, 그 소방조합에 자발적으로 가입하지 않았기 때문이다. 집 주인이 자기 집은 화재 따위 날 일 없을 거라고 생각했던가 보다.

그런데 그것이 실제로 일어나자 집 주인은 태도가 완전히 바뀌어서 화재 진압 비용을 몇 배라도 낼 테니 제발 불을 꺼 달라고 읍소했다. 그러나 소방관은 그 읍소도 단호히 거절하면서 이렇게 말했다.
"그런 유도리 부탁을 들어 주면 앞으로 아무도 평소에 소방조합에 가입하지 않을 것이고 불이 났을 때만 일회용으로 돈을 내려 할 것이다. 그러면 소방조합이 운영될 수 없게 된다."
소방관들은 화재 현장을 지켜보고 있다가 소방조합에 가입된 옆집에 불이 옮겨 붙으려 하는 것만 차단하고 돌아갔다.

이런 소방관의 처신은 매우 정당하며 잘못된 게 단 1도 없다!! 자기 선택에는 자기가 그대로 책임지고 심은 대로 거둬야지?
나는 이런 자유주의 원칙을 쌍수 들고 지지하며, 이것이 성경의 법리 원칙이기까지 하다고 생각한다. 잠 1:25-26도 떠오르고 말이다. 살아 있을 때 복음을 받아들이지 않고 죄 가운데 죽었다가 지옥 가는 혼들이 늘어놓지만 퇴짜 맞는 변명도 딱 이런 패턴인 경우가 매우 매우 많을 것이다.

저렇게 소방조합 가입 안 해서 쪽박 쓴 사람의 반대편 극단에 있는 사람은..
생명보험 가입하자마자 피보험자가 죽었지만 법적으로 아무 문제가 없어서 결국 보험금을 전액 수령한 "10억을 받았습니다" 당사자, 아니 그 유족일 것이다. ㄲㄲㄲㄲㄲㄲㄲ
뭐.. 이런 식으로 평생 죄 짓고 살다가 죽기 직전에 예수 믿어서 구원받는 것도 이론적으로 당연히 가능하다. 그러나 인간에게는 보편적으로 미래 예측 능력이란 게 존재하지 않는다.

2. 선택과 책임 (2)

이것도 위의 얘기의 연장선인데.. 아마 예전에도 내가 비슷한 얘기를 한 적이 있을 것이다.
옛날 전근대 시절과 현대(특히 197,80년대쯤 이후)의 관념· 사고방식의 차이가 뭐냐 하면..

- 옛날: 싸움에서는 무조건, 닥치고 승리하든가 아니면 죽든가 둘 중 하나였다. 의지드립, 약육강식, "인생은 실전이야 존만아" 관념이 훨씬 더 강했다. 초인적인 위인, 영웅이 생길 여지가 지금보다 더 많았다.
- 지금: 도저히 승산이 없으면 일단 살아서 돌아오기라도 해서 후일을 도모하려 한다. 무모한 희생을 피하고, 안전이나 인권을 더 챙긴다. 위인, 영웅이 등장할 여건 자체를 안 만들려 든다.

- 옛날: 빚을 졌으면 니 자신이나 자식새끼를 노예로 팔아서라도 갚아야 했다. 사람을 고의로 죽였으면 닥치고 사형이었다.
- 지금: 변제 능력 보지도 않고 돈 덥석 빌려준 채권자에게도 일부 책임이 있다. 빚이 아무리 많아도 상속포기 파산을 하면 약간 불이익이 따르긴 하지만 어쨌든 빚 안 갚아도 된다. // 흉악 범죄를 저질렀어도 사람을 저 지경으로 만든 사회의 책임도 있고 심신미약 상태여서 뭔 정상 참작을 하고 궁시렁궁시렁...

- 옛날: 게임만 해도 뭐 삐끗하면 즉사하는 형태인 게 훨씬 더 많았다. 모르면 죽어야 하고 레벨을 처음부터 다시 시작해야 했다.
- 지금: 훨씬 더 친절해졌다. 어지간한 게임들은 다 HP가 있고 저장 불러오기 기능이 있고 undo에 더 관대해졌다. 일부러 현실감을 추구하는 일부 장르를 제외하면 아군이든 몬스터든 즉사가 잘 없고, TTK (여러 발 맞아야 사망)가 더 길어졌다.

- 옛날: 부모님이 주신 이름값을 해야지?? 무슨 대놓고 '김개똥, 강간녀' 같은 미친 이름일 때에나 개명이 허용됐다.
- 지금: 개인의 자유를 얼마든지 존중해 준다. 범죄 내력을 세탁 은폐하려는 불순한 의도만 아니면 얼마든지 개명 허용이다.

성경이 말하는 전반적인 맥, 법리, 구원관은 '지금'이 아니라 '옛날' 관점에서 봐야 더 절실히 공감하고 믿을 수 있다.
하긴, 옛날엔 저렇게 사회가 살벌했기 때문에 애들이 요즘 애들보다 훨씬 더 일찍 철 들었던 것 같다. 철 들지 않으면 당장 쳐맞거나 밥을 굶거나 심지어 목숨이 위태로워졌을 테니까. =_=;;

"어쨌든 그건 니 사정이고 지금 사고 친 걸 어떻게 책임지고 수습할래?
아무리 니 혼자 스스로 열심히 진심으로 노력했어도 규정대로 규칙을 지키면서 게임을 한 게 아니라면 실격이다. 과정이나 동기가 중요한 게 아니다"

그 관점에서 봐야 영원히 꺼지지 않는 지옥불이라는 개념도 이해가 된다. 선악을 분별 못 할 정도로 너무 어리거나 지능이 딸려서 법적으로 면제되는 게 아니라면 책임이라는 게 절대 없어지지 않는다.

단지, 인간의 깜냥으로 무모한 희생까지 불사하는 게 아니라, 신이 이뤄 주신 위대한 희생을 받들이고 내 것으로 만들어야 된다는 것이다. 그저 인생은 실전이니까 너도 온갖 치사 비열한 수단과 방법을 동원해서 정글을 헤쳐 나가는 게 아니고, 그에 상응하여 신이 너에게 베풀어 준 은혜와 사랑을 받으라는 쪽으로 해결책이 있을 뿐이다!
그게 바이블 게임의 보스를 깨는 공략법이다.

3. 달란트 비유, 양극화

신약 성경 복음서에 나오는 유명한 이야기인 달란트/므나 비유 말이다.
얘의 핵심 주제가 그저 단순히 "재능 낭비하지 마라, 니가 받은 걸 썩혀 놓고 놀리지 마라"였다면..
2달란트와 1달란트 받은 종이 칭찬을 받고, 정작 5달란트 받은 사람은 돈을 파묻어 놓고 탱자탱자 노는 걸로 스토리를 짜는 게 더 이치에 맞았을 것이다. 과부의 헌금 2렙돈이 더 가치 있었다는 비유처럼 말이다. 그렇잖은가? 그게 더 극적인 효과가 나지 않았겠는가?

하지만 예수님은 양극화.. "받은 자는 더 부유해지고, 없는 자는 그나마 있던 것마저 뺏긴다~~"
부익부 빈익빈 복리 이자 선순환 악순환이라는 냉정한 원리까지 가르치고 싶어서 1달란트를 게으르고 악한 종으로 설정하신 것이 틀림없다. 이 점을 잘 생각해 보자.

그렇잖아도 이 비유는 성경에서 꽤 이례적으로 "돈을 환전상한테 맡겨서 이자라도 받아 왔어야지?"라는 경제 관념까지 등장한다. 단순히 "일하지 않으면 먹지도 말라" 수준이 아니다. 단순히 돈이 아니라 사람의 상태야말로 궁극적으로 천당 아니면 지옥이라는 양극화로 치닫기는 할 것이다.

4. 이방인· 불신자에 대해서

성경은 "어리석은 자는 자기 마음에 이르기를 하나님이 없다고 하는도다"부터 시작해서 '믿지 않음'을 죄로 규정하고 당연히 부정적으로 매우 깐다. 잠언에 나오는 어리석음은 생물학적인 지능이 낮은 게 아니라 그런 부류의 영적 악함이 가미된 불신, 죄악을 가리킨다.

(1) 그러나 한편으로 이방인이건 이교도건 원시 미개 부족이건.. 율법을 직접 받지만 않았을 뿐, 누구든지 민족 불문하고 양심을 통해 보편적인 선과 악 관념이 있다는 것도 부각시킨다. 살인이나 간음은 나쁘다(창 20:4-5, 행 28:4), 죄 지으면 천벌 받는다(욘 1:14) 따위..
민족이나 시기에 따라 경륜은 차이가 날 수 있지만, 각 개인의 선악 관념과 구원의 길에 대해서는 하나님 역시 동서고금을 막론하고 공평하게, 환경과 무관하게 배려하고 있다.

(2) 성경은 구원자로서의 예수 얘기만 양보 없이 배타적이지, 나머지는 심지어 "나쁜놈이라 할지라도 자기네 기준으로 잘하는 거, 맞는 말 하는 게 있으면 너도 인정하고 배워라" 이런 실용적인(?) 논조이다.
"뱀처럼 지혜로워라"라든가, 눅16의 불의한 청지기 비유(횡령이라는 짓거리를 본받으라는 게 아니라 그 준비 정신을..), "바리새인들이 하는 말은 듣고 행동은 본받지 마라" 이런 여러 예들을 보면 유추할 수 있다.

(3) 성경엔 이스라엘 민족의 입장에서 가나안 땅에 쳐들어가라, 이방 민족들을 멸절시켜라~~ 이런 얘기가 역사서에 많이 기록돼 있다. 물론 그건 그 이방 민족들의 죄악에 대한 심판이었으며, 반대로 이스라엘 역시 죄악 심판을 엄청 많이 처절하게 당했다. 오히려 선민이기 때문에 더 엄격한 잣대를 적용받은 것도 있다. 그러니 이건 하나님이 불공평 편파적인 게 아니다.

5. 황금률, 이타주의

세상엔 "자기가 대접받고 싶으면 너도 그만큼 남에게 대접해 줘라"라고 이타주의..라기보다는 쎄임 쎄임 상호주의를 말하는 격언이 있다. 공자 논어에도 비슷한 요지의 문구가 있지 싶다. "니가 싫어하는 것이라면 남에게도 떠넘기지 마라"라고 말이다.

이건 "자유(혹은 권한, 권리)에는 책임이 따른다", "주장에는 근거가 있어야 한다, 비판에는 대안이 있어야 한다"처럼 특정 종교나 이념을 떠나서 수학· 논리 차원에서 매우 합리적이고 정당한 법칙이다. 그래서 그런지 세상에서는 이걸 '황금률'이라는 뽀대나는 타이틀을 붙여서 부른다.

심지어 성경에서 예수님도 마 7:12 (+ 눅 6:31)에서 이 개념을 언급하셨다.
(1) 하나님 사랑과 (2) 이웃 사랑이 율법을 다 요약한 핵심이라고 공관(= 마태 마가 누가)복음에 명시돼 있는데, 황금률도 나름 그 정도로 성경 전체를 관통하는 핵심 사상이라는 것이다. 마 22:40과 마 7:12를 비교해 보시라.

물론, 황금률은 좋은 도덕 계명이긴 하지만 "그것만으로" 하나님 앞에서 의로워질 수는 없다. 이건 적당히 합리적인 것, 의로운 걸 추구하는 일반 불신자 이방인이라도 얼마든지 똑같이 할 수 있는 것이기 때문이다. 뭔가 마 5:46과 비슷한 구도가 된다.

다만, 마 7:12 주변은 "남 눈치 보면서 먼저 받을 생각만 하지 말고, 니들이 먼저 과감하게 베풀어라... 얼마나 과감하게? 니가 남으로부터 받고 싶은 만큼!! 쎄임쎄임 선순환을 너희가 먼저 시작하라~ 베풀고 나서 못 돌려받으면 어쩌나 하는 염려를 하지 마라~" 라는 뉘앙스가 들어있긴 하다. 그래서 단순한 상호주의보다는 이타주의 뉘앙스가 더 느껴진다.

6. 하나님 사랑 vs 이웃 사랑

성경에서 하나님 사랑은 '니 온 마음과 힘을 다하여'라고 구체적인 방식을 명시하고 있는 반면.. 이웃 사랑은 '니 자신을 사랑하듯이'..라고 단순하게 수식하고 있는 걸 주목해 보자. 굉장히 세심하게 차이를 둔 워딩인 것 같다~!
눈에 보이지 않는 하나님을 사랑하는 건 직관적으로 잘 되지 않는다. 그러니 뭔가 믿음 행사가 필요하고 니 육신적인 본성을 거슬러서 뭔가를 하는 쪽으로 유도했다.

그러나 나와 똑같은 레벨인 이웃 사랑은..?? 니 자신을 꾸미고 치장하고 맛난 거 먹이고 좋은 체험 시키는 것과 똑같이 하면 된다고.. 이기주의를 그대로 직관적으로 투영시켜서 이타주의를 설명한 것이다. 하나님 사랑을 그런 식으로 실행할 수는 없지만, 이웃 사랑은 그런 식으로 하면 되니까. ㅋㅋㅋ 흥미롭다.
그리고 구약 성경에서는 하나님 사랑과 이웃 사랑이 같은 책에서 동시에 등장하지 않았다. 전자는 신명기에서 거듭 거론되는 반면, 후자는 의외로 레위기 19장이 최초이다(18, 34절).

여담으로.. 성경에서 the law와 the prophets가 나란히 등장했다면 이건 모세오경과 선지서.. 라고 구약 성경 전체를 관용적으로 일컫는 문구라고 보는 게 좋을 것이다. 즉, law가 비인칭인 것처럼 prophets도 비인칭인 것이다.
마 5:17과 마 7:12는 동일한 개념을 가리키는 셈이다(율법을 포함해 성경을 폐하러 온 게 아니라 성취하러 왔다). 우리말 성경 중에는 한킹이 나름 이 관점을 반영해서 번역했다.

7. 기타

(1) 지금까지 나왔던 여러 얘기들을 한데 정리하면..
성경은 죄, 심판, 구원에 관해서는 결과 지향적이다. 그러나 그 뒤의 상급은 동기· 과정 지향적이다. 그렇기 때문에 예수님이 부자의 거액 헌금보다도 과부의 2렙돈 헌금이 더 값지다고 평가하신 것이다. 이런 거 평가는 어떤 형태로든 절대 공정하다. 환경 탓, 가정 환경 탓을 할 여지가 절대 없다.

(2) 성경은 "십자가 다음에 왕관, 영광" 주의이고, "작은 것에 먼저 충실해야 나중에 더 큰 것이 맡겨진다"의 신봉자이다. 이 원칙이 그야말로 철칙이다.

(3) 오· 남용되는 일이 없어야겠지만 "보이지 않는 믿음은 보이는 행실로 드러난다" 주의를 지지한다.
성경이 말하는 신의 존재나 사후 세계 같은 것은 일단 과학으로 증명 불가능한 영역이기 때문에 일단 증거 없이 믿어야 한다. 그러나 그 뒤에 이어지는 각종 교리들은 일말의 논리와 일관성과 형평성이 있다. 믿어야 하는 공리들이 인간의 보편적인 양심마저 저버릴 정도로 도저히 믿을 수 없는 황당무계한 반지성주의 맹신 광신 급이 절대 아니다.

물리적인 것과 그렇지 않은 것 사이에 어느 정도 인과? 상관관계가 있다. "너희가 서로 사랑하면 세상 불신자들도 니들이 그리스도의 제자인 줄 알게 될 것이다." / "영적인 것을 먹이는 사역자가 물질적인 보상 받는 것은 합당하다." / "사형수도 용서받고 구원은 받지만 그 대신 교수대에서 꽤꼬닥은 하고 가는 게 합리적이다~!!"
이런 식으로 말이다. 이 정도 보장은 돼 있기 때문에 충분히 믿을 만하며, 이래도 믿지 않은 것은 안타깝지만 완악한 죄라고 간주할 수 있다. 그게 아니었으면 난 이렇게 기독교 관련 글을 남들 보라고 못 올린다~!

Posted by 사무엘

미국은 20세기에 외세로부터 침략 받아서 주권을 빼앗긴 적 없고, 공산화된 적 없고, 쿠데타나 비민주 군사 독재를 겪은 적 없고, 헌정 체제가 널뛰기 하듯 바뀐 적도 없고.. 대공황 때문에 고생했던 것만 빼면 정치적으로는 큰 트러블 없이 살기가 참 좋았을 것 같다. 전쟁 참전은 다 남의 나라를 지켜 주러 했지, 자기 나라를 구하려고 한 게 아니었다.

하지만 이런 천하의 미국도 완벽한 유토피아는 아니니 사법 흑역사가 몇 건 있었다. 그것도 공교롭게도 굉장히 비슷한 시기에 말이다.

1. Joe Arridy (1915-1939) -- 가스실

이 사람은 15세 소녀를 강간하고 손도끼로 찍어 살해한 혐의를 받고 처형됐다. 그러나 문제는.. 그는 20대 청년이지만 지능이 5세 어린이 수준밖에 안 되는 정신지체아였다는 것이다. 저런 끔찍한 흉악 범죄를 저지를 능력 따위는 1도 없는 철부지에 지나지 않았다.
그냥 사건 현장 곁에 얼쩡대다가 붙잡혀 가서는.. 실적 올리고 싶은 형사와 검사에게서 집요하게 가스라이팅 당하고 시키는 대로만 하다 보니, 뜻도 모르는 조서에다 지문 찍고 “그 아이 내가 죽였어요”라고 거짓 자백을 하게 됐다.

이 사람은 교도관한테는 “우와~ 근육빵빵 아저씨다~!” 이러면서 교도소에서도 기차 장난감을 갖고 놀았다. ‘작은 하마 이야기’에도 나오는 그 유서깊은 장난감 말이다!!
이런 사람이 “범행을 언제 어떻게 저질렀습니까” 같은 질문에 일관성 있게 제대로 대답도 할 리가 만무했다.

지금이야 미국에서 사형이 교수형, 전기의자, 아니면 약물 주사인데.. 저 때는 미국도 무슨 나치 독일처럼 가스실을 운용했는가 보다. 그는 gas chamber이라는 게 무슨 장소인지를 이해하지 못하고, 심지어 해맑은 표정으로 사형장으로 들어갈 때도 기차 장난감을 갖고 들어갔다. 교도관들이 그건 허용해 줬는가 보다.

천하의 미국에서 그때 경찰과 검사, 판사는 도대체 뭘 하고 있었는지 모르겠다. 이 사람은 살인이고 사형이고 나발이고 아무것도 모르던 사람이어서 무슨 행복한 왕자도 아니고 행복한 사형수 the happiest prisoner on death row라는 역설적인 별명까지 붙었다. 모파상의 소설 ‘행복한 사형수’하고는 관계 없다.

이 사건은 정작 진범이 딴 지역에서 잡혀서 그놈도 처형되기도 했다.
그럼에도 불구하고 교통 통신이 열악해서 소식 업데이트가 더뎠는지, 한번 내린 사법 결정을 호락호락 번복할 수 없다는 똥고집이 작용했는지, 아니면 세뇌당한 저 사람도 자기가 진범인 듯 거짓 자백을 너무 진지하게(ㅠㅠ) 해 버렸는지.. 그래도 저 사람도 같이 사형을 당하고 말았다. 그는 2011년에야 주 정부로부터 정식으로 사면을 받았다.

참고로 우리나라에서는 지난 2014년 12월에 부산에서 어느 발달장애 1급 청년이 아주 잠깐 감시가 소홀한 틈을 타서 2살짜리 아기를 창 밖으로 휙 던져서 바닥으로 떨어뜨려 죽인 적이 있었다. 하지만 가해자는 정말 아무 생각 없이, 죽음이 뭔지 모르고 경찰이나 검사의 질문을 이해하지도 못하고 사리분별과 판별이라고는 단 1도 못 하는 말 그대로 저능아였다.

자기가 저지른 짓에 대한 자각이 없고 형사 책임을 질 능력도 전무했으니.. 피해자 집안의 입장에서는 정말 분통 터지겠지만 가해자는 아무 처벌 없이 무죄 방면되고 그 대신 치료 감호 판정만 내려졌다.
이랬는데 미국에서 저 때 저런 분위기 속에서 같은 사건이 터졌으면 가해자가 사형에 처해질 수도 있었겠다는 생각이 든다.

2. George Stinney Jr. (1929-1944) -- 전기의자

이건 앞의 1번보다도 더 뼈아픈 흑역사인 것 같다. 집 주변에서 7세· 11세 소녀 2명이 끔찍하게 살해 당했는데, 마침 곁에 있던 '만만한 흑인 소년'이 졸지에 용의자로 몰려 체포되고 범인으로 몰렸다. 이 소년은 오히려 경찰에게 그 당시의 주변 상황에 대해 증언을 하고 수색 작업을 도와 주기까지 했는데도 말이다.

피해자 가족, 그리고 이 사건을 수사한 경찰과 검사, 배심원들은 모조리 백인이었다. 이들이 모두 짜고 입을 모아서 “보나마나 추잡한 검둥이놈이 사고 쳤구만”으로 몰고 갔다. 재판은 거의 나치 인민재판 급으로 속전속결로 진행됐고, 피고인 측은 제대로 변호할 기회도 주어지지 않았다.
“내가 죽였어요”라는 자백을 얻기 위해.. 비록 대놓고 물· 전기 고문이나 몽둥이 찜질까지는 아니지만, 오랫동안 굶겨 놓고는 “배고프지? 자백하면 밥 줄게~!” 정도는 시전했다고 한다. 중학생짜리 애한테.

결국 이 소년은 유죄 판결을 받았을 뿐만 아니라, 겨우 15세의 나이로 전기의자형을 당해 형장의 이슬로 사라졌다. 체격이 너무 작아서 엉덩이 부분에다가 두꺼운 성경책을 몇 권 올려놓고 애를 앉혔다니 말이 되는 소리냐.. 게다가 이 친구도 학교에서 싸움박질이 잦긴 했지만 명목상 교회 댕기는 크리스천이었다고 한다.

그는 근현대 이래로 미국 역사상 최연소 사형수라는 타이틀까지 차지하게 됐다. 이 기록은 앞으로 깨질 일이 없을 것이다. 머리가 좋아서 저 나이에 대학교를 입학한 것도 아니고, 저 나이에 사형을 당했다니.. 그것도 누명을 쓰고..

이 사건은 어째 재심 청구가 받아들여져서 2014년에야 무죄 판결이 났다. 1번은 '사면'이라고 하고 2번은 '재심 결과 무죄'.. 법적 처분이 왜 서로 달라졌는지는 잘 모르겠다.
이 사건은 정황상 의심되는 진범(백인..!)이 있긴 하지만, 이놈은 빽이 있어서 법의 심판을 피해 갔다. 심지어 그놈의 부모가 배심원으로 들어가서 애꿎은 흑인을 범인으로 조작해서 사형장으로 보내는 추악한 짓을 저질렀다고 한다.

미국은 프랑스나 독일처럼 유대인을 괴롭히는 건 없었지만 저기 특유의 인종 차별이 있었다. 지금은 과거에 비해 많이 없어지긴 했지만 오늘날까지도 완전히 근절된 건 아니라 여겨진다. 특히 남부 텍사스 같은 레드넥 동네 말이다.. -_-;;
요즘도 경찰들이 과격한 범죄 현장에서 흑인을 더 줘 패거나 심지어 권총 쏴서 사살해서 과잉 진압이라고 욕 먹기는 하는데.. 이 사건은 법적으로 사람을 누명 씌우고 사형장으로 보내 버린 거니 사건의 막장성이 차원이 다르다고 하겠다.

심지어 이렇게 흑인에게 누명 씌우기가 그 뒤에도 몇 건 더 있었다고 전해진다. 다행히 사형까지 가지는 않고 교도소에서 몇 년 썩다가 누명이 풀렸을 뿐..

• 이 소년은 우리나라 여수에서 “임금님 귀는 당나귀 귀, 일제는 패망한다” 이런 낙서를 한 게 들통나서 고문 후유증으로 순국한.. 주 재년 열사와 동갑이다. 역시 1929-1944.
  
  
• 이렇게 인종 차별이 쩔었으니 미국에서는 n**** 이 단어가 f*** 급의 금기어 트라우마로 남았고, 치킨과 수박이라는 맛있는 음식조차 금기시되어버린 것 같다.
• 그래도 그 미국에서도 흑인 남자(1870)가 백인 여자(1920)보다는 훨씬 더 먼저 투표권이 주어졌다고 한다. 전근대 시절엔 세상 어디에나 가부장적 이념이 강했으니 일면 이해는 된다.
  
  
• 근데 평등은 평등이지만, 반대로 멀쩡한 기존 '인어공주'나 '미녀와 야수'에다가 쓸데없이 유색인종 주인공 집어넣는 PC 리메이크짓은 좀 안 했으면 좋겠다. 같은 유색인종이 보기에도 안 좋다. -_-;;
  

3. Edward Donald Slovik (1920-1945) -- 총살

이 사람은 군인이었고, 위의 두 사례 같은 막장 사법 살인을 당한 정도는 아니다. 결과만 따지자면 군생활에 적응을 못 하고 전시 탈영을 저질렀고, 이에 대한 벌을 받은 것이기 때문이다.
하지만 그는 너무 안 좋은 타이밍에 굉장히 운 나쁘게 일벌백계 시범 케이스로 걸려서 사형 당했기 때문에 좀 억울하다면 억울한 사례가 됐다.

그는 성장 배경이 불우했는지 좀 질이 안 좋게 컸고, 10대 소년 시절부터 각종 기계에 자동차까지.. 온갖 절도죄로 잡범 전과가 주렁주렁했다.
저 사람은 소년원인지 교도소인지를 실컷 드나들다가 1942년에야 겨우 석방됐다. 출소 후엔 직장 잡고 연애에 성공해서 결혼도 하고, 이제 좀 마음 고쳐먹고 바르게 살려고 했다. 근데 결혼 생활 1년을 못 채운 타이밍 때 군 징집 영장이 날아왔다.

평시에 여유가 있는 상황이라면 저 사람 정도로 전과가 화려한 사람은 군대에서도 필요 없다고 안 받아 줬다. (무공 전과가 아니라 범죄 전과..ㄲㄲㄲㄲ)
그러나 저 때는 2차 세계 대전 시국이었다. 병력이 많이 필요하니, 캐 싸이코패스 흉악범만 아니면 어지간히 범죄 이력이 있는 사람도 데려갈 정도로 징집 기준이 아주 낮아졌다.

그는 성장 배경의 특성상 단체 생활 잘 하고 군대에 적합한 체질이 아니었다. 각종 훈련이나 작전에서 수시로 낙오를 빙자해 전선을 이탈해 버리면서 전우들을 엿먹이고 고문관 신세를 면치 못했다. 심지어는 6주 동안이나 짱박혀 잠적하기도 했다고.. 그는 “나 이런 데서는 도저히 못 견디겠으니 앞으로 또 탈영하겠다”라고 상관에게 항명을 예고하는 편지를 보내서 결국 찍혔다.

그의 상관들은 이런 편지는 그냥 없는 걸로 하고, 얘를 전투 스트레스가 덜한 부대로 전출이라도 시켜 주려 했다. 그러나 그는 어차피 이판사판인데 군사 재판을 받아서 교도소에서 몇 년 썩는 걸로 군생활을 통째로 퉁치고 싶어했다.
사실, 미국 역사상 사형 선고를 받은 탈영병은 탈영 후에 살인· 강간 같은 흉악 범죄까지 저지른 사람뿐이었다. 이렇게 단순 탈영이나 병역 거부 자체만으로 사형이 선고된 적은 옛날 남북 전쟁 이래로 전무했다. 그러니 이 사람도 그걸 노렸는데..

그때는 2차 세계 대전 시국이었다는 것이 역시 문제였다. 천조국도 지긋지긋한 전쟁에 어지간히 이골이 나 있었고, 군복무 부적격자의 인권을 챙기는 것보다는.. 다른 멀쩡한 군인들의 사기를 진작시키고, 군기 빠진 꾀병 의심 탈영을 일벌백계 하는 것에 훨씬 더 관심을 두고 있었다.
그땐 한 집안 출신의 5형제가 몽땅 한 군함에서 성실히 근무하다가 다섯 명이 한 날 한 시에 몽땅 전사해 버린... '설리번 5형제'(1942) 같은 극단적인 사례도 있었다는 걸 생각해 보자.

이 때문에 이 '에디 슬로빅'의 죄질은 정말 불행히도 예상보다 훨씬 더 나쁘게 평가되었으며, 그는 미국의 역사상 탈영죄 단 하나만으로 사형이 선고된 유일한 사례가 되어 버렸다. 그의 선택은 자기 무덤을 파는 결과를 야기한 것이다.
그의 아내와 친척들이 대통령에게 수차례 감형 탄원서를 냈지만 전시이다 보니 별 공감대를 얻지 못하고 요청이 받아들여지지도 못했다. 2차 세계 대전 중에 미군 탈영병이 21000여 명이나 발생했는데 순수 탈영만으로 사형 선고는 49건, 그게 실제로 집행된 건 이 사람 혼자뿐이었다고 한다.

Posted by 사무엘

1. Windows의 컴퓨터 비트 수 변화

과거에 주류 PC 환경이 (1) 16비트에서 32비트로 바뀌면서 소프트웨어 개발 환경이 크게 바뀌었다.
int와 WPARAM, handle, 포인터가 모두 4바이트 크기로 바뀌었고, 이로 인해 메시지도 몇몇은 스펙이 불가피하게 바뀌었다.
좌표계의 기본 단위도 다들 32비트로 확장됐고, 이로 인해 GDI 함수들이 상당수가 Ex 버전으로 바뀌었다. 왜냐하면 예전처럼 x, y 좌표 둘을 long 하나에다 묶어서 전달할 수가 없어졌기 때문이다.

하지만 선점형 멀티스레드가 지원되고 그 전에 모든 프로세스들이 자기만의 독립된 주소 공간을 갖는다는 건.. 과거엔 정말 상상도 못 할 혜택이다.
8비트야 거의 임베디드 급의 열악한 환경이니 멀티태스킹 따위는 별나라 얘기였다. 16비트 시절엔.. 어정쩡하게 아주 불편하고 힘들게 가능했던 반면.. 32비트가 되니 주소 공간도 넉넉하고 이제 좀 그럭저럭 할 만해진 것이다.

그리고 32비트에 와서는 예전에 깐깐하게 구분해야 했던 게 이제는 구분이 필요 없어지고(예: HINSTANCE vs HMODULE, far vs near), 예전에는 꼭 할당하고 해제해 줘야 했던 게 지금은 그럴 필요가 없는 등(resource 관련 API, MAKEPROC 따위).. 프로그래밍 하기가 전반적으로 더 간편해지고 편리해지기도 했다.

그에 비해 (2) 32비트에서 64비트로의 변화는 뭐.. int와 포인터의 크기가 달라진 것으로 인한 자잘한 충돌과 이식성 문제가 고작이다. 4GB 한계가 없어지기만 했을 뿐, 체감되는 변화는 아주 미미하다.
Windows의 경우, int는 물론 long조차도 여전히 32비트 크기로 유지된다. 그러나 WPARAM은 64비트로 확장됐다.

전에도 한번 얘기했듯이 게임기는 1990년대 후반, PC는 2000년대 후반, 스마트폰은 2010년대 후반이 돼서야 슬슬 64비트 시대에 들어섰다.
이런 곳은 비트 수가 점진적으로 늘어났기 때문에 기존 코드와의 호환성이 중요했다. 그렇기 때문에 포인터만 빼고 int나 long은 4바이트로 할지 8바이트로 할지 고민이 많은 편이었다.

그 반면.. 슈퍼컴퓨터 전용 아키텍처가 있던 시절 말이다. 197, 80년대에 처음부터 64비트로 시작했던 컴터 환경에서는 레거시 고민 따위 없었다. Cray 같은 플랫폼에서는 쿨하게 처음부터 int고 포인터고 몽땅 다 무식하게 64비트 모델을 채용한 곳도 있었다고 한다. 물론 오늘날이야 int까지 8바이트인 컴퓨팅 환경은 없다고 봐도 되지만..
그리고 저런 옛날 컴퓨터들은 데이터를 취급하고 연산하는 단위만 64비트였다. 아무리 슈퍼컴이라 해도 자기네 메모리 용량이 4GB에 미치지는 못했기 때문에 64비트 컴퓨팅이 곧 64비트 addressing을 의미하지는 않았다고 한다. addressing까지 다 되는 64비트 CPU는 1990년대가 돼서야 등장했다. (MIPS, DEC Alpha 따위) 아하~

얘기가 좀 옆길로 샜는데.. 아무튼 Windows는 16비트에서 32비트로 넘어갈 때 변화가 좀 있었고, 32에서 64비트로의 변화는 미미한 편이었다. 그럼 Windows의 역사상 16비트에서 32비트로의 전환만이 대격변이었던 것일까?
꼭 그렇지는 않았다. 오히려 더 옛날, (3) Windows 1 (+2)과 3 사이는 플랫폼 SDK의 변화, C 컴파일러의 변화 등의 단절이 더 심했다.

Windows 1과 2는 아직도 리얼 모드 내지 끽해야 286 표준 모드에서 멀티태스킹을 구현하던 정말 암울한 시절이다.
Windows의 오랜 역사를 좀 아는 guru라면, 20세기에 Windows에서 가장 혁신적인 변화는 바로 95나 NT도 아니고 3.0에서 "386 확장(enhanced) 모드"가 정식 도입되었던 사건이라고 말할 정도이다. (☞ 링크)

그랬기 때문에 Windows 1과 3은 같은 16비트 기계어에 같은 NE 포맷임에도 불구하고 1용 프로그램이 후대의 3 내지 9x에서 제대로 실행되지 않을 가능성이 매우 높았다.
게다가 저 1980년대의 구닥다리 C 컴파일러는 함수를 정의하는 문법조차 ANSI가 아닌 기괴한 K&R 방식이었다니.. 소스 레벨의 호환성도 기대하기 어렵겠다. 더 자세한 건 여기 글을 참고하시라. (☞ 링크)

2. 마소의 16비트 P-code 기술

마소와 관련된 옛날 이야기가 계속 이어진다. 이 블로그에서 본인이 지금까지 이 얘기를 한 번도 꺼낸 적이 없었다니 놀랍다.;;
네이티브 기계어가 아니라 다른 중립적인 바이트코드 기반으로 돌아가는 '가상 기계 프로그램'이라 하면 흔히 Java (JVM)나 C# (.NET, CLR) 같은 것만 떠올리기 쉽다. 이런 건 최소 32비트 이상의 컴퓨팅 환경에서 등장한 런타임 환경이다. 고유한 클래스 라이브러리도 갖고 있고 쓰레기 수집기도 제공한다.

하지만 마소는 창립하자마자 그 허접한 197, 80년대 8비트 컴퓨터로 제일 먼저 만들었던 게 BASIC 인터프리터였다. 현대적인 가상 머신 정도로 거창하지는 않지만, 그래도 고유한 바이트코드 가상머신 기술을 보유해서 16비트 컴퓨팅 시대까지 잘 써먹었다.

마소에서는 그 바이트코드를 스스로 P-code라고 불렀다. P는 pseudo-, portable, packed(조밀) 등을 뜻했다고 한다. 그리고 그걸 Basic뿐만 아니라 C/C++ 언어 컴파일러에다가도 접목했었다. 아니, 베이식은 그렇다 치지만 기계어 직통 컴파일이 당연시되는 언어이던 C/C++에다가는 성능(= 실행 속도) 희생까지 감수하면서 도대체 왜..?

이 바이트코드는 크기가 작았기 때문이다. 이게 packed의 의미이다.
같은 프로그램 소스를 비슷한 최적화 수준으로 컴파일 했을 때, 네이티브 x86 기계어 코드보다 훨씬 더 작은 크기로 표현할 수 있었다. 심지어 P-code를 해독하는 가상머신 코드의 오버헤드(9K 남짓?)를 포함시키더라도 수지맞는 장사였을 정도라니.. 이건 뭐 실행 파일 압축 기능까지 약간이나마 겸한 셈이었다.

컴퓨터 역사의 관점에서 볼 때 x86 자체도 골수 CISC 구조로서, 현대적인 아키텍처 대비 기계어 코드가 조밀하고 크기가 아주 작은 축에 드는 아키텍처라고 여겨진다. (그 대신 읽어들이고 디코딩하는 난이도가 쥐약이고, 저전력 모바일과 상극)
그런데 마소의 P-code는 그 악명 높던 x86 기계어보다도 더 조밀하고 작다니.. 그 시절에 얼마나 메모리가 비싸고 귀했고 메모리를 어떻게든 아껴야 했는지가 실감이 간다. PC에서도 386 486 같은 32비트 CPU는 진작에 등장하고 값도 내려갔지만.. 메모리가 아직 병목이었다. 이게 더 싸지고 풍부해진 뒤에야 본격적으로 Windows 95/NT가 쓰일 수 있었다.

Visual Basic이야 exe를 생성한다 해도 런타임 dll이 따로 필요하고 내부 코드는 P-code 기반이었다. 1997년에 출시된 5.0.. 최초로 32비트 전용으로 출시된 이 버전에 이르러서야 네이티브 코드 컴파일 기능이 도입됐다.
C/C++의 경우, MS C/C++ 7.0과 Visual C++ 1.x 시절.. 16비트 한정으로 이런 기능이 있다가 32비트부터는 폐기됐다. 그 대신, 16비트이기만 하면 플랫폼은 DOS와 Windows를 모두 지원했다.

따지고 보면 Windows NT의 32비트 PE (portable executable)는 저런 P-code와는 접점이 없었던 셈이다. 32비트 Visual Basic 5나 6을 쓰지 않는 한 말이다
자세한 것은 이 링크의 설명을 참고하시라. 마소의 전설적인 P-code에 대해서 구체적으로 소개한 글은 "Microsoft P-Code Technology" by Andy Padawer이 유일한 것 같다.

QuickBasic이나 GWBASIC은 소스 코드를 고유한 바이너리 포맷으로 저장하는 기능이 있었다. 이건 세상 그 어느 프로그램 개발 환경에서도 없는 기능이었지 싶다.
그 반면, 저 P-code는 소스 코드가 아니라 나름 기계어를 표방하고 컴파일된 코드였다는 차이가 있다.

3. 마소와 볼랜드 프로그래밍 툴의 Windows 지원 내력

(1) 아마 예전에 이 얘기를 한 적이 있었을 텐데..
1980년대 말부터 마소와 볼랜드에서는 주요 프로그래밍/개발툴을 내놓으면서 뭔가 교육용 저가 보급형 제품군에다가는 각각 Quick과 Turbo라는 스피디한 브랜드명을 붙였고, 기업용 기함급 모델에다가는 그냥 자기 회사 이름을 붙였었다.

(2) 1990년대 초엔 C 컴파일러에는 C++의 지원이 추가되었다. 그래서 지원 언어 표기가 C/C++이라고 바뀌었다.
마소의 경우, QuickC는 Microsoft C를 먼저 만들다가 곁다리로 병행하며 잠깐 만들었던 제품이다. 이건 C++ 지원 없이 겨우 2.0에서 맥이 끊겼다. 그 대신 이전부터 만들어 오던 MS C 6의 다음 버전이 MS C/C++ 7이 되었다(1992). 그리고 이거 다음 버전부터는 그 이름도 찬란한 Visual 브랜드가 시작됐고, C는 떼어낸 채 Visual C++ 1로 넘어갔다.

저 때는 1993년 무렵이었다. Visual C++은 Windows NT와도 역사를 함께한다. 이게 마소에서 최초로 내놓은 32비트 C/C++ 컴파일러이며, Windows NT 내부의 각종 프로그램들을 빌드하는 용도로, 즉 자체적으로도 쓰였기 때문이다.
물론 Visual C++도 1.5까지는 16비트 버전이 같이 나오긴 했었다. 그리고 대외적인 버전 번호는 1로 리셋됐지만 얘 역시 MS C를 계승한 제품이라는 흔적은 MSC_VER이던가 그 매크로 상수의 번호에 남아 있다.

(3) 한편, 볼랜드 진영에서는 Turbo C 2.0의 다음 작품이 Turbo C++ 1.0이 되었다. 제품명과 버전이 다 리셋됐다니 좀 이례적이다.
그리고 그 다음 버전인 Turbo C++ 2때부터 같은 버전의 Borland C++도 나란히 나오기 시작했다고는 하는데.. 실질적으로 Turbo와 Borland의 구분이 생겼다고 일반인들이 존재감을 인지하는 첫 버전은 3이다.
Turbo C++은 3인가 3.1에서 맥이 끊겼다. 그 뒤 적어도 4~5 버전부터는 Borland C++만 나오다가 RAD 툴인 C++ Builder 1로 넘어갔다.

(4) 그 시절 C/C++ 컴파일러 업계에서는 C++ 지원뿐만 아니라 Windows 플랫폼의 지원도 중요한 이슈였다.
마소는 DOS에 이어 Windows를 만들던 본가였고, C는 어셈블리어와 더불어 자기들 제품을 만들 때 사용되는 주력 언어이기도 했다. 그러니 MS C는 처음부터 Windows를 지원하는 게 너무 당연한 일이었다.

1980년대 중반, 정말 구닥다리 MS C 4~5 시절부터.. 그야말로 전설적인 Windows 1.x, 2.x 프로그램을 만들 수 있었다. 단, QuickC는 DOS용 버전 2.x대와 별개로 QuickC for Windows 1.0이 딱 한 번만 나오고 말았던 듯하다. 요컨대 마소는 QuickC의 Windows 버전만이 버전 리셋을 했고, 볼랜드는 C++ 컴파일러를 구현할 때 버전 리셋을 했다.

그에 비해 볼랜드 제품에서 Windows 지원이 추가된 건 버전 3.x부터로, C++까지 지원되고 난 이후의 일이다. 심지어 Win32의 지원은 Windows 95가 출시되고 4.x 정도는 된 뒤부터다. 후발주자 3rd-party 업체이니 이런 것 수용은 한 발 늦을 수 있다지만.. Windows용 32비트 extender까지 미리 만들었던 Watcom 같은 업체하고는 개발 방향이 많이 달랐던 것 같다. 그 대신 볼랜드에서는 OWL이라고 꽤 잘 만든 객체지향 프레임워크를 연구 개발했다.
이렇듯, Windows 지원과 관련해서는 볼랜드와 마소 개발툴 간에 이런 내력의 차이가 있었던 셈이다.

(5) 자, 그럼 C/C++ 다음으로 파스칼의 세계로 가면..
볼랜드에서 Turbo Pascal을 내놓으면서 1980년대를 호령하고 재미를 봤다. 도스 아니면 기껏해야 OS/2에서 말이다. 그러다가 1990년대 초, Turbo Pascal 6 타이밍 때 TP for Windows를 1.0과 1.5 두 차례 내놓았다. 아마 5.x던가 6이던가..
이때 ObjectPascal이라는 객체지향 문법이 언어에 도입되기도 했지만 이건 TP의 버전에 영향을 주지 않았다. 그 대신 Windows용을 1.0부터 다시 내놓았다는 점이 Turbo C++과는 다르다.

그러다가 Turbo Pascal 버전 7이 Borland Pascal 7과 나란히 출시됐으며.. 이 BP7은 TP for Windows 2를 통합· 포함한 형태가 됐다. 제품 라인업 한번 복잡하네..;;
TPW는 about 대화상자에 수학자 파스칼 얼굴이 그려져 있는 반면, BPW는 그렇지 않다는 차이가 있다.;;;

1992년에 출시된 Borland C++ 3.1, 그리고 Borland Pascal 7이 도스와 Win16을 풍미했던 장수만세 안정판으로 여겨진다.
Borland C++은 C++ Builder로 넘어가기 전 1993~1995년 사이에 자체적으로 버전이 4~5까지 올라가기도 한 반면, BP는 델파이로 넘어가기 전에 딱히 버전업이 없었다.
심지어 Delphi도 1995년의 첫 버전 1은 Win16, 16비트용이었고 버전 2부터 Win32로 넘어갔으니, 32비트화도 C++보다 늦은 셈이다.

한편, 마소는?? 처음에 Microsoft Pascal을 1980년대에 4.x 버전까지 개발했었다. 하지만 이건 Turbo Pascal과의 경쟁에서 승산이 없다고 판단했는지 접었다. 그렇게 접기 직전에 경쟁사 제품처럼 뽀대나는 IDE를 얹은 QuickPascal 1.0을 최후의 발악 차원에서 한번 내놓았을 뿐이다. Windows 지원 같은 것도 당연히 없었고 제품의 맥이 끊겼다.
볼랜드에서는 Turbo Basic을 만들었다가 반대로 마소의 QuickBasic 대비 승산이 없다고 생각해서 포기해 버렸으니.. 행보가 서로 정반대인 셈이다.

Posted by 사무엘

1. 단품 판매되는 DOS

(1) 197, 80년대에는 컴 단말기가 아니라 개인용 컴퓨터라는 건 이제 막 정립되고 있었고, 소프트웨어도 하드웨어와 함께 딸려 나오는 게 아니라 독립된 제품이라는 인식이 이제 막 정립되던 중이었다.
그래서.. 마소에서 만들었던 MS-DOS도 말이다. 1.0부터 4.x에 이르기까지는 다들 PC와 함께 OEM 형태로만 공급됐다. 도스 자체가 단품 패키지로 개별 소비자에게 retail 판매되기 시작한 건 1991년, 무려 5.0부터였다고 한다. himem.sys와 DOS=HIGH가 첫 도입됐던 그 역사적인 물건 말이다.

아 글쎄.. Windows 1.x 시절이던 1986년에 3.2 버전도 단품 패키지가 있긴 했다. 하지만 이때는 이 방식이 오래 지속되지는 못한 듯하다.

현실적으로 대다수 사용자들이 패키지 판매를 기억하는 건 아무래도 끝물인 6.x버전이지 싶다. 이 무렵에 마소는 IBM과 사이가 단단히 틀어져서 PC-DOS와 MS-DOS의 격차도 벌어지고, Windows와 OS/2도 격차가 벌어졌었다.
1990년대 들어서 MS-DOS는 이렇게 독립을 했는데, 매크로 어셈블러(Macro Assembler)는 그 무렵쯤에 반대의 길을 갔다. 단독 독립 제품으로서는 단종이고, MS C/C++이나 Visual Studio 같은 더 큰 제품에서 제공되는 유틸리티로 흡수되었다.

(2) MS-DOS가 대기업의 PC와 함께 공급되던 시절, 대략 쌍팔년도 정도까지는 한글 MS-DOS에 내장돼 있던 한글 바이오스도 PC 제조사들별로 제각각이었다.

• PC 제조사: 대우, 금성, 현대, 삼보 등
• 제3자 써드파티: 도깨비, 한메, 태백 등
• 마소 자체 개발: hbios, mshbios. Windows 3.1 + MS-DOS 6부터.

한글 바이오스 만드는 게 첨단 시스템 프로그래밍이던 시절이 있었다니.. 추억 돋는다. =_=;;
기능이 제일 많고 성능도 뛰어나던 건 역시 써드파티 제품들이었다. 조합형도 지원하고, 다양한 폰트와 글자판(세벌식까지)도 지원했지만.. 역시 1990년대 중후반쯤부터는 개발의 맥이 끊겼다.
현재 한글 바이오스가 돌아가는 중인지를 무슨 API를 호출해서 어떻게 판별했는지 궁금하다.

(3) MS-DOS는 버전 1부터 4까지는 OEM이었고 5~6 사이에 잠깐 독립 제품.. 그리고 마지막 7~8 버전은 Windows 9x에 포함된 채로 제공.. 이렇게 역사가 정리된다.
그 중에 OEM 끝자락이던 MS-DOS 4는 DOS shell이 처음 도입되었고 FAT16 파일 시스템의 개편으로 하드디스크 용량을 2GB까지 인식할 수 있게 하는 큰 변화가 있었다(종전에는 꼴랑 32MB까지만.. =_=) 하지만 4.0은 버그가 너무 많아서 곧 4.01로 패치가 돼야 했다.

이건 마치 버그가 너무 많아서 온갖 서비스 팩들이 덕지덕지 나와야 했던 Windows NT 4의 행로와도 비슷해 보인다.
그리고 개발툴 중엔 Visual Studio .NET 첫 버전(2002, 7.0)이 금세 묻혀 버렸던 것과도 처지가 비슷하다.

(4) 끝으로.. MS-DOS의 대체품으로 DR-DOS라는 게 있기도 했고, 그걸 한때 네트워크 솔루션으로 유명했던 어느 기업에서 인수하여 노벨 도스로 계승되었다.
한편, MS-DOS의 셸만 대체해서 강화한 제품으로 4DOS라는 게 있었다. 그걸 노턴 유틸리티에서 인수해서 더 발전시킨 게 NDOS...이다. 노벨 도스와 이니셜이 같지만 이들은 서로 다른 제품이다.

2. Rational

옛날에 Rational이라는 이름을 가진 컴퓨터 소프트웨어 회사가 둘 있었다.

(1) Rational Software는 소프트웨어공학 툴이라고 해야 하나.. 딱 정확하게 개발툴, IDE나 컴파일러는 아니지만 어쨌든 소프트웨어 설계· 개발과 관련이 있는 전문 도구를 개발해 왔다. 콕 집어 코딩, 프로그래밍이라기보다는.. 더 거시적인 소프트웨어 개발 말이다.
Rose라는 툴이 유명했다. 꽃하고는 별 관련 없고, 다른 단어들의 이니셜이 저렇게 된 거지 싶다. 내 기억으로 Visual C++ 6 시절에 엔터프라이즈 에디션에는 Rose의 데모 축소판이 번들로 제공됐던 적이 있었다.

얘의 제조사는 2003년에 IBM에 인수됐다. IBM이 PC용으로 소프트웨어를 만든 게 지금은 망한 운영체제 OS/2, 그리고 유구한 역사를 자랑하는 통계 패키지 SPSS 정도밖에 없는 줄 알았는데.. 지금은 Rose도 IBM 휘하로 넘어갔는가 보다.
하긴, 엑셀에 대항하여 넥셀이 있고, AutoCAD에 대항하여 캐디안이 있는 것처럼.. Rose의 저렴한 국산 대체제로 StarUML이라는 제품도 있다.

개인적으로는 직장에서 보고서 쓸 때 각종 UML 다이어그램 그리는 용도로 사용해 봤다.;; 클래스 관계 모식도라든가 각종 시퀀스 다이어그램 따위..
하긴, 그 비싼 프로그램에 겨우 다이어그램을 그리는 기능밖에 없으면 그냥 Visio 같은 벡터 드로잉 툴과 아무 차이가 없을 것이다. 그럴 리는 없고, 여기서 만든 설명대로 Java 클래스 파일을 생성하고 문서를 생성하는 기능도 있었던 걸로 기억한다.

(2) 그 다음으로 Rational Systems라는 곳이 있었다. 얘는 1980년대부터 DOS extender만 전문으로 개발해 왔다. 16비트에 640KB 메모리에 쩔어 있던 도스 환경에서 보호 모드를 구현하고, 메모리를 골치 아픈 제약 없이 32비트 그대로 접근하게 해 주는 획기적인 런타임 말이다.

사실, DOS extender라는 걸 처음으로 개척한 회사는 Phar Lap이었다. 워크스테이션에서나 돌릴 만한 거대한 업무용 프로그램을 PC용으로 포팅할 때 원래 Phar Lap의 extender가 주로 쓰였다. 옛날에 도스용 아래아한글도 전문용 내지 32비트 에디션은 얘를 사용했다.

그러나 Rational Systems에서는 DOS/4G라는 제품을 개발하고, 이걸 Watcom C/C++ 컴파일러에 DOS/4GW라는 번들 버전으로 아주 저렴하게 공급해 줬다. 1993년 말에 Doom이라는 게임이 딱 이 솔루션을 사용해서 출시되면서 DOS/4GW라는 32비트 extender는 세계적인 히트를 치게 됐다.

환상적인 그래픽을 선보였던 Doom이 어셈블리어를 거의 쓰지 않고 이식성 높은 C 코딩으로만 구현될 수 있었던 비결엔 이런 신기술이 있었던 것이다. 물론 그래픽을 제대로 보려면 그 당시로서는(1993~1995) 아직 가격이 부담되는 고성능 컴터이던 486급이 필요했지만 말이다.

그리고 Doom은 이 장르에서 하드웨어 가속이 없이 CPU 연산/소프트웨어만으로 동작한 마지막 게임이기도 했다. ^^ 이렇게만 동작해서는 320*200보다 더 높은 해상도에서 3D 폴리곤 그래픽이 실시간 애니메이션으로 나오기란 굉장히 무리였을 것이다. 뭐, 그래픽의 하드웨어 가속에도 더 높은 데이터 대역폭이 필요할 것이고, 32비트 버프가 기여했다고 볼 수 있다.

1990년대 중후반까지 덩치 큰 도스용 게임들은 처음 실행될 때 DOS/4GW 로고가 뜨는 게 무척 많았다. 이게 무슨 흥행 보증수표처럼 느껴질 정도로..;;
PC 역사에 한 획을 그었던 이 개발사는 훗날 Tenberry Software이라고 이름이 바뀌고 2000년대 초반까지는 살아 있었다. 하지만 도스 시절이 끝난 뒤엔 없어졌는지 근황을 모르겠다.

요컨대, 두 Rational들은 분야는 다르지만 과거에 뭔가 비범한 소프트웨어들을 개발하곤 했다. ^^.

3. 옛날에 C++ 코딩 환경

난 왕년에 이런 시퍼런 화면에서 코딩을 해 봤다. -_-;;

쌍팔년도를 넘어서 1990년대가 되자.. 이제 막 C가 아니라 C++ 직통 컴파일러라는 게 처음으로 등장했다. 그리고.. IDE의 텍스트 에디터에 syntax coloring이라는 게 제공되기 시작했다.
코드에서 예약어는 진하게 표시하고, 전처리기는 별도의 색깔로, 상수 리터럴이나 주석도 별도의 색깔로.. 이거 말이다. 하긴, 1990년대는 이제 막 VGA와 컬러 모니터가 보급되었던 시절이고, 286이니 386이니 하던 컴터 성능도 실시간 컬러링을 구현해도 될 정도로 향상됐다.

그 당시 도스용 컴파일러의 본좌는 볼랜드...였는데, Turbo C++ 3.0 버전부터 IDE에서 컬러링이 지원되기 시작했다. 1과 2 시절엔 저런 게 아직 없었다.
오 그런데... 말로만 듣던 Turbo C++와 Borland C++가 차이가 있었나 보다. 난 Turbo C++ 것만 어린 시절에 직접 봤었다.
일반 명칭은 초록색, 문자열 상수는 빨강, 전처리기는 저렇게 청록색 바탕, 기호가 노란색 말이다.

그러나 Borland C++은 보니까 일반 명칭이 노랑, 문자열 상수는 청록, 전처리기가 초록, 기호는 하양이다.
난 도스용 볼랜드 개발툴 IDE에서 C++의 컬러링이 저렇게 되는 건 직접 본 적이 없고, 구글 검색을 통해서 난생 처음 본다. 비슷한 시기에 동일 회사에서 내놓았던 Borland Pascal과 더 비슷해졌다. 우와..

사실, Turbo와 Borland의 차이는 Visual Studio로 치면 standard 에디션(개인용)과 enterprise 에디션(기업용) 같은.. 에디션 급의 차이와 비슷하다.
아.. 옛날에.. 볼랜드 IDE를 따라 djgpp 진영에서 개발했던 rhide는.. C/C++ 코드에 대한 컬러링이 Turbo가 아니라 Borland C++ 스타일이었다. 자, 난 저런 것도 기억하는 세대다. -_-;;;;

프로그래밍, 코딩이라는 건 30년 전이나 지금이나 재미있다.
참고로, 코딩 하다가 .이나 ->를 찍었을 때 멤버가 쫘르륵 나오고 명칭이 자동 완성되는 기능은..
1990년대 "말"이 돼서야 제공되기 시작했다. 그건 그만큼 구현하기 더 어려운 기능이었고, PC가 못해도 펜티엄 2 이상급으로 성능이 좋아진 뒤에나 쓸 만했다.

요즘은 이 기능이 없으면 너무 불편해서 코딩을 못 할 것이다. 옛날에 텍스트 에디터가 불편하고 컴퓨터 메모리가 부족하던 시절에는 각종 함수 명칭을 아주 짧고 암호 같이 붙이는 게 관행이었지만..
지금은 코드 양이 너무 방대해지고 저런 자동 완성 기능도 발달하니 길게 길게 풀어서 써 주는 편이다. setmemmgr() 대신에 SetMemoryManager() 같은 식.

4. PowerBasic

198~90년대에.. BASIC이라는 프로그래밍 언어는 입문하기 간편한 대신, 인터프리터 방식 위주이고 실행 속도가 느리다는 게 상식 겸 통념이었다. 즉, 언제까지나 교육용이지, 실무용은 "영 아니올시다"였다. 그러나 BASIC에 대해 그 통념을 정면으로 도전하고 반박하는 이단아 제품이 있었으니, 바로 PowerBasic(파베)이었다.

얘는 BASIC이라는 언어에다가 C/C++ 같은 이념을 접목했다. 마소처럼 느린 P-code 갖고 깨작거리거나 비주얼 RAD 툴 컨셉을 씌우는 게 아니라, 최적화되고 단독 실행 가능한 네이티브 코드 컴파일을 추구했다. 그렇다, 이 컴파일러 엔진을 만든 주 개발자는 그야말로 x86 어셈블리어에 정통한 smaller, faster 최적화 덕후 장인이었다.

PowerBasic은 마이너 비주류 제품군이지만 나름 존재의 의미는 있었다. 베이식 언어로 C/C++ 급의 작고 빠른 프로그램을 생성해 줬기 때문이다. 자기 자신의 덩치도 Visual Studio에 비하면 그냥 깃털 같은 수준이니 아주 실용적이었다.

얘는 16비트 도스에서 32비트 Windows까지는 잘 갈아탔다. 하지만 그 이후의 시대 변화에는 따라가지 못한 채, 2020년대에 와서는 명줄이 사실상 끝난 상태이다.
일단, 주 개발자인 Bob Zale 할아버지가 별세한 지가 이미 10년이 넘었다. 적절한 후임 개발자를 양성하지 못했는지, 파베는 x64건 arm64건 일단 64비트 버전이 못 나오고 있다.

살상가상으로.. PowerBasic 컴파일러 자체부터가 통짜 어셈블리어=_=;;;로 개발됐고, 코드가 호락호락 maintainance 가능한 구조가 아니라고 한다. 이러면 뭐 과거의 OS/2나 dBASE 같은 꼴 나면서 죽는 건 시간 문제지..
그렇게도 성능에 목숨 걸었다지만, 최신 멀티코어 프로세서나 GPU에 맞춰진 컴퓨팅을 잘 지원한다는 얘기도 난 못 들었다. 이러면 머신러닝 스크립트인 파이썬의 용도를 대체하기도 대략 곤란해진다.

지금 생각하면 PowerBasic이 뭔가 슈퍼컴 Cray 같은 물건이라는 생각도 든다. 고전적인 성능 덕후 장인이 애지중지 만들었지만 시 대에 뒤쳐지고 도태됐다는 점에서 말이다.
글쎄, 쟤는 그 성능빨에다가.. 마소에서 버린 자식인 클래식 Visual Basic 6 코드를 지원하는 후속 써드파티 개발툴을 표방하고 나섰으면.. 마르지 않는 고객 수요를 확보하고 절대로 망할 일이 없었을 것 같은데 말이다. 그렇지 않은가? 이렇게 사라지기에는 아깝고 아쉽다.

쌍팔년도 시절에 볼랜드와 마소가 PC용 베이식, C, 파스칼 컴파일러 시장을 꽉 잡고 있긴 했다. 하지만 그 컴파일러들은 처음부터 그 회사에서 만든 게 아니었다. 다들 다른 사람이나 영세업체의 제품을 인수한 것에서부터 개발을 시작했다.

• BASIC/Z by Bob Zale --> Turbo Basic (요게 PowerBasic의 전신)
• Wizard C by Bob Jervis --> Turbo C 1.0 in 1987
• PolyPascal by Anders Hejlsberg --> Turbo Pascal
• Lattice C --> Microsoft C

Posted by 사무엘

1. 혼을 얻는 자

잠 11:30 he that winneth souls is wise.
통상적으로는 주변 사람들에게서 호의를 얻고 마음을 사서 다들 자기 편으로 만들 줄 아는 사람은 지혜롭다~~ 이런 뜻이다. 그러나 좀 더 영적으로 들어가면 이건 '전도'하는 거.. 복음 전해서 남을 회개시키고 예수 그리스도에게서 이끌어 온다는 뜻이 된다. soul winning.

말씀 보존 학회의 한킹은 저 구절이 동사가 win이라는 이유로 "혼들을 이겨 오는 자"라고 정말 단순무식 투박하게 번역했다. =_=;;
"우리 교회는 거리설교를 통해 매년 수십 명의 혼들을 그리스도께로 이겨 오고 있습니다" 자기들끼리 말도 저렇게 전투적으로 한다. 옛날 개역성경의 "강하고 담대하라"처럼 언어에 대한 비표준 확장이라고 봐야 할지.. ^^

당연한 말이지만 저건 win a prize(상을 탄다/받는다) 할 때의 win이다. 경쟁 상대를 꺾거나 제쳐서 이긴 것은 beat라고 한다.
예전에 언급한 적이 있는 예시이다만, "1994년 올해의 명작 게임이라는 영예를 차지하고(win) 싶은 작품이 있다면 먼저 Doom부터 제쳐야/능가해야(beat) 할 것이다." 이렇게 말이다.

세상을 이기거나 마귀를 이기는 것도 아니고 혼들을 이기는 건 뭘까.. =_=;;
그렇다고 평범하게 get obtain acquire과 아무 차이 없이 얻는다고만 하면 성이 안 차니.. '쟁취'라는 말이 어떨까 하는 생각을 오래 전부터 개인적으로 했다.
오, 근데 유일하게 표준역이 저기서 쟁취라고 번역했구나. 우리말 성경 중에서는 첫 사례인 것 같다.
표준역이 논란이 많은 역본이긴 하지만.. 저기서는 단어를 잘 고른 것 같다.

I am not a prize to be won! 나는 무슨 남자들의 전리품이 아니라구요! (디즈니 알라딘에서 자스민 공주의 대사. Prince Ali 노래가 끝나고 얼마 뒤에..ㄲㄲㄲㄲㄲ)

2. 강하고 담대하라?

우리말 국어에서는 형용사 뒤에 명령문이 바로 오는 게 잘못됐다면서 여호수아의 저 유명한 말 "강하고 담대하라"라든가 예수님의 "진리가 너희를 자유케 하리라"가 비문(문법에 어긋난)이라고 비판이 제기되곤 했다.
그런데 기껏 대안이란 게 훨씬 더 길어지고 장황해지고 거추장스러워진 "마음을 강하게 하라, 담대해져라"이면.. 어떡해야 할까?

그리고.. "내가 거룩하니 너희도 거룩하라" (벧전 1:16) 같은 구절도 있다. 표준어를 준수했다는 최신 우리말 성경들도 이 구절은 거의 건드리지 않고 놔두고 있다.
'거룩하다'도 형용사인데? 동사가 아니기 때문에 '거룩한다'라는 말이 없는 거다. 쉽게 말해 '거북하다'(불편하다)와 완전히 동일한 품사이다.

하지만 '거룩하라'라는 말이 너무 간결하고 잘 와 닿는다. "거룩해져라, 거룩하게 살아라" 이렇게 군더더기를 붙일 필요가 없고, 저걸 그대로 그냥 성경 언어적 허용이라고 정착시키는 게 더 합리적이지 않을까? 난 그렇게 본다.
우리말은 '맞다/틀리다/맞는/알맞은'처럼 근본적으로 형용사와 동사의 경계가 애매한 구석이 있어서 더욱 그러하다.

새로 번역되는 우리말 성경은 현행 언어 규범을 가능한 한 따를 필요가 있다. 그러나 거기에만 절대적으로 얽매일 필요는 없을 것 같다.
오히려 한킹은 흠정역 같은 후대의 역본 대비, 개역성경 스타일의 간결함이 있어서 더 잘 읽히는 게 아닌가 하는 생각이 들기도 한다. "예수님께서 말씀하시되"보다 "예수께서 가라사대"가 더 간결한 것처럼 말이다.;;

그리고 울나라 헌법도 생각해 보자. 1987년 개헌 이후에 맞춤법이 개정되는 바람에 지금 관점에서 맞춤법에 어긋난 문장(..."투표에 붙이다")이 생겨 있다. 하지만 그렇다고 헌법을 호락호락 또 수정하지는 않는다. 그건 개헌이라는 엄청난 과업이 되어 버리며, 헌법에는 무슨 위키백과 같은 '사소한 수정'이라는 것도 존재하지 않기 때문이다. 헌법이 그러한데 하물며 성경 본문에도 그런 정도의 권위와 무게감이 있어야하지 않겠나 싶다.

3. help meet for him

한국어 '맞다'뿐만 아니라 영어에도 드물게 형용사-동사 품사통용이 있는 것 같다. 대표적으로 meet.
옛날 영어에서는 '만나다'가 뭔가 '만족시키다, 충족시키다' it meets the requirement으로 확장되고, 그게 '-에 적합한, 알맞은'이라는 형용사로 더 확장된 듯하다.

그게 바로 창세기 2:18에서 아담을 위한 합당한 조력자(help meet for him)라고 번역되었다. meet는 형용사이므로 "help meet - for him"이 아니라 "help - meet for him"이라고 끊는 게 바람직하겠다.

근데 저 문맥에서 조력자란 곧 '배우자'이지 않은가?
이게 얼마나 임팩트가 컸으면 helpmeet라는 한 단어가 생겨서 배필, 배우자라는 뜻이 됐고.. helpmate라는 말까지 파생돼 나왔다. 이거는 마치 비키니에서 모노키니가 나온 것처럼, 어원상 관계는 없지만(meet ≠ mate) 걍 비슷한 조어가 튀어나온 것으로 보인다.

즉, help가 먼저이고 helpmeet는 후대의 해석 내지 파생 의미이다. 그러니 성경 번역을 helpmeet로 미리 할 필요는 없을 것 같다. 조력자/도우미가 1차 의미이기 때문이다.

그나저나 help는 굳이 helper이라고 하지 않아도 help만으로 어느 정도 '도와주는 사람'이라는 뜻이 얼추 들어있는가 보다. 물론 반대로 helper이라고 해서 굳이 사람일 필요가 없고 사물, 기계가 모두 가능하다.
게다가 help me라고 외치면 "사람 살려!!"가 되니.. help가 생각보다 인간적인 단어인 것 같다.

4. God forbid? The LORD forbid?

성경에는 그냥 No를 넘어서 천부당만부당, Absolutely not이나 May it never be 같은 강한 부정을 나타내는 관용구가 있다. 킹 제임스 성경은 이를 God forbid라고 번역했다.
성경에서 이 표현을 제일 많이 사용한 책은 로마서이다. "그럼 그렇다고 우리가 이렇게 하리? ㄴㄴ 절대 그럴 수 없음" 이런 패턴으로 말이다.

그래서 킹 제임스 진영에서는 이 구절에 대해 "반드시 God을 살려서 '하나님이 금하시리'라고 번역해야 한다" vs "아니다, 저기서 God은 원어에도 없는 그냥 영어의 관용 어휘일 뿐이다~ 저거 한 덩어리 전체가 '절대 안 됨'이라는 뜻이다" 갖고 치고 받고 싸우는 일이 많다.
본인은 이런 소모적인 논쟁에 진지하게 가담하고 싶지는 않다. 다만, 이 문제에 대해 뭔가 가타부타 의견을 내려면 다음 경우도 생각해서 일관되게 적용 가능한 답을 제시해야 한다는 점을 지적하고자 한다.

(1) 성경엔 God forbid뿐만 아니라 God save the king (국왕 폐하 만세 vs 하나님이 울 국왕을 보우하시리)라든가 God speed (축복 인사. 요즘으로 치면 God bless you에 가까운..)도 있다는 걸 감안해야 한다. 전자는 구약 성경 역사서에서 두루두루 나오는 편이지만, 후자는 요한이서에서만 딱 두 번 등장하는 희귀 관용구이다.

(2) 짤막한 God forbid 감탄사뿐만 아니라 "God forbid that ..." 이런 문장도 있다. 창세기 44장에서 요셉의 형들이 "저희가 감히 파라오님의 술잔을 훔쳐 가다니요~ 저흰 절대 그러지 않았습니다" 이럴 때 최초로 이 문장이 쓰였다. God forbid를 '하나님이 금하시리라'라고 옮기려면 창 44:7이나 창 44:17도 그렇게 옮길 수 있겠는지를 따져 봐야 한다.

(3) 그리고 끝으로.. 성경엔 God forbid만 있는 게 아니라 the LORD forbid도 구약에 있다. "주가 금하신다"..이고, 개역성경 용어로는 "여호와가 금하신다"이다. 단, 이건 단독 감탄사는 아니고 문장 형태만 있다.
삼상 24:6, 26:11에서 다윗이 사울 왕을 해코지할 수 없다고, 하나님이 기름 부으신 사람에게 내가 감히 손을 댄다니~~~ "절대 그리할 수 없다"라고 말할 때 쓰였다.
그리고 왕상 21:3에서 나봇이 아합 왕에게 조상 대대로 살아 온 땅을 처분한다니 절대 그럴 수 없다고 말할 때도 이 표현이 쓰였다.

내가 궁금한 건.. 우리말 성경들이 God forbid의 문장형은.. "결코 그럴 수 없다"라고 옮긴 반면, The LORD forbid의 문장형은.. "주께서 금하신다"라고 옮겼다는 것이다. 개역성경 이래로 표킹을 제외한 킹 계열 역본들이 모두 동일하다. (표준역은 '하나님이 금하신다'를 첫 시도했음)

이렇게 LORD forbid와 God forbid의 번역이 달라질 만한 이유가 원어 차원에서나 다른 이유로 인해 있는지 개인적으로 궁금하다.

하긴, 우리말에도 딱히 하나님을 진심으로 의식하지 않는 "하나님맙소사" 이런 말도 있고, 영어 Good-bye도 god be with you에서 유래되기는 했다고 들었다. 재채기 인사인 Bless you도 그렇고..
그리고 예전에 영국에서 찰스 3세 국왕이 즉위했을 때 국가적으로 참 오랜만에 God save the king 인사가 울려퍼졌고.. 그게 자막에서는 우리말 애국가 가사 "하나(느)님이 보우하사"처럼 번역돼 나갔었다. 흥미로운 일이다.

사실 지금이야 우리말 '만세'는 hooray banzai-_-라는 평범한 감탄사로 많이 쓰이지만, 원래는 국왕의 '만수무강'을 기원할 때만 쓰이는 아주 존귀한 단어였다고 한다. 오죽했으면 그 만세를 국왕 폐하가 아니라 자기 나라에다가 끌어다 쓴 삼일 운동이 정말 파격적이고 민주적인 발상이었으니 말이다.
이를 감안하면 God save the king을 "국왕 폐하 만세"라고 옮긴 건 더욱 적절한 용례인 것 같다. 영어의 God이 우리말의 만세에 대응하는 거나 마찬가지이기 때문이다.

5. 하루살이를 걸러내나, 모기에 긴장하나

성경의 마 23:24는 대략 "이 눈깔이 썩은 가이드놈들아. 니들은 하루살이는 걸러내면서 낙타는 잘도 꿀꺽하네?" 이런 의미의 책망 구절이다. ㄲㄲㄲㄲㄲ
개념적으로 "달면 삼키고 쓰면 뱉는다" 같은 구조이다. 그리고 본질적이지 않은 디테일에는 왕창 목숨 걸면서 진짜 큰 잘못은 슬쩍 답습하고 넘기는 부조리가 잘못됐다는 뜻이다.

저 구절에서 후반부, 낙타를 삼킨다는 말은 지구상의 모든 성경 역본들 간에 이견이 없다.
하지만 전반부, strain at a gnat은 역본마다 번역이 좀 갈리는 편이다.

먼저 gnat이 하루살이냐 모기냐를 갖고 갈리는데, 이건 이 글에서는 논외로 하겠다.
다음 strain가 진짜 문제다. "힘주다, 끙끙대다, 애쓰다, 신경 곤두세우다"인지 아니면 '걸러내다'인지가 갈린다. 참고로 현대에 strainer라고 하면 주방에서 쓰이는 걸러내는 동그란 체를 뜻한다.

거의 모든 성경들.. 심지어 킹 계열이라는 한킹, 근본역 표준역까지 다 "하루살이/모기를 걸러낸다"라고 옮겼다. 비킹과 다를 바 없다.
하지만 딱 하나.. 흠정역만이 유일하게 "모기에 긴장하고"라고 옮겼다. 뭐, 이것도 '대언'과 마찬가지로 안티오크 권위역에서 처음으로 유래된 번역이다.

서로 자기 번역이 맞다고 스트롱 성구 사전이 어떻고 웹스터 영영사전이 어떻고 심지어 원어 사전이 어떻고 막 떠드는데, 내가 이 문제를 접근하는 방식은 이렇다.

strain out도 아니고 strain at이라면
뭔가를 '걸러 내는(out)' 것보다는 '-에(at) 신경이 곤두선다, 긴장한다'라는 의미가 더 강하게 느껴지는 게 사실이다. 흠정역 측의 견해에 일면 동의한다.

하지만, 다만, 그럼에도 불구하고.. 생각해 보자.
모기한테 왜 긴장하는데? 왜 눈 부릅뜨고 신경을 곤두세우고 난리인데?

모기가 무서워서 긴장할 리는 없다. 쬐끄맣지만 성가신 놈이 있으니까, 잡으려고, 걸러내려고 저러는 거다.
불 끄고 침대에 누웠는데.. 짜증나는 앵앵~ 소리가 들릴 때.
잡가시가 왕창 많은 생선살을 씹어먹으려 할 때.. 그 심정 말이다. =_=;;

이런 차원에서 "모기한테는 긴장하고"라는 말이 결국은 "모기를 걸러내고"라는 말과 다를 바 없다고 여겨진다.
'긴장하고'는 표면적인 동작이고, '걸러내고'는 본질적인 의미이다.
"선물은 넙죽넙죽 받으면서"라는 의미를 "선물만 보면 입 헤 벌리면서", "선물만 있으면 손 잘도 내밀면서"라고 표현한 것과 비슷하다는 것이다. 오키?

피터 럭크만이 저기서 at은 out이라는 뜻과 다를 바 없다고 얘기까지 했다는데.. 당연히 문법적으로야 at이 on도 아니고 어떻게 out이랑 같을 수 있냐? 저 구절에 한해서 화용론적으로 동치라는 뜻일 것이다.

그러니 킹의 영어 표현을 존중해서 "모기에 긴장하고"라고 번역을 하려거들랑, 여기 긴장이 최소한 무서워서 쫄아서 긴장한다는 뜻은 아니라고 옆의 성경 교사가 보충 설명을 하면 좋을 것 같다. 저 표현이 '걸러낸다'라는 의미와 별개가 아니기 때문이다.
차라리 두 동작을 합쳐서 "기를 쓰고/눈 부릅뜨고 걸러내면서" 이렇게 표현하는 것도 괜찮을 수 있겠다. win을 "쟁취하다"(이겨서 얻음)라고 표현하는 것처럼 말이다.

사실은 한킹이 영어 킹 제임스 성경을 번역한 게 아니라고 비판받는 다른 여러 표현들도 이런 식으로 해명이 가능하다.
작은 숲(외형) vs 아세라(정체, 실체)라든가, 생활방식 vs 시민권 따위 말이다. 결국은 같은 뜻이다.
차라리 의역이 지나치다고(?) 비판할지언정, 최소한 오역이나 변개는 아니다.

Posted by 사무엘

날개셋 한글 입력기의 다음 버전이 일단은 다음 달 4월 하순쯤에 나올 예정이다. 버전이 10.9가 되었으면 좋겠지만 현실적으로는 무리=_=;;이고, 아마 10.8이 될 가능성이 높다.
타자연습도 오랜만에 버전업 해서 4.0을 만들고 싶은데 얘는 또 언제 작업하려나.. ㅠㅠㅠ
아무튼, 현재 작업이 진행된 자랑거리들을 몇 가지 나열하자면 다음과 같다.

1. 외부 모듈: 안정성 개선

날개셋 한글 입력기는 사용자가 입력 설정을 바꿔서 imeconf.dat를 저장해 놓은 게 없는 경우, 마소 한글 IME의 설정 레지스트리 값을 참조하여 동일하게 두벌/세벌 설정을 세팅해서 동작한다.
그 레지스트리 주소는 운영체제의 버전에 따라 다를 수 있기 때문에 일종의 탐색 알고리즘을 거쳐서 결정된다.

그런데 그 로직에 심각한 버그가 있었다. 그것도 꽤 오랫동안 존재해 왔다.
한번 구한 주소값을 저장해 놓는다는 것이.. 지역변수 버퍼의 주소를 static 변수에다가 저장해 버리고는 계속 써먹는 병크가 벌어졌다.

이 때문에 날개셋 제어판에서 '프로그램 설치 직후 상태'로 팩토리 리셋 명령을 여러 번 내려 보면, 마소 한글 IME로 분명히 세벌식을 사용하고 있음에도 불구하고 제1글자판이(0번) 두벌식으로 지정되곤 했다.
이건 잘못된 메모리 주소를 넘겨준 것이기 때문에 원래는 실행 실패만으로 곱게 넘어가지 않는다. 일부 민감한 환경에서는 프로그램이 뻗을 수도 있다.

오랜 고질병이 있었구나.. 문제를 당장 개선했다.
더구나 외부 모듈은 imeconf.dat가 있더라도 매번 이렇게 디폴트 세팅부터 먼저 했다가 다시 파일 내용으로 세팅을 다시 하는 삽질을 지금까지 하고 있었다.
이를 개선했기 때문에 "메모리 문제 해결", "애초에 문제의 동작 자체를 하지 않게" 이렇게 2중으로 문제를 원천봉쇄 해결했다.

나무위키에 올라와 있던 "Windows 95에서 IE 4~5 + Active desktop을 켠 환경에서 날개셋을 기본 IME로 지정해 놓으면 부팅 과정에서 운영체제가 뻗어 버린다".....;;
이건 내가 직접 확인은 못 해 봤지만, 어쩌면 이 문제도 같이 해결되었을 가능성이 높다.

2. 편집기: ctrl+ins, shift+ins/del 단축키 지원

날개셋 편집기는 1.0 이래로 지난 20여 년 동안, 복사/잘라내기/붙여넣기 기능의 단축키로 Ctrl+C, X, V만을 지원했다. 이들 기능은 Ctrl+Ins, Shift+Del, Shift+Ins라는 단축키로도 통용되고 있지만, 내 프로그램에서는 지금까지 지원되지 않았다.
일단 내가 개인적으로 저런 제2군 단축키를 전혀 사용하지 않았고, 그리고 shift+ins는 한글 낱자 수정 - 글자 전체 수정을 전환하는 용도로 이미 사용 중이었기 때문이다.

그러나 정신을 차리고 보니.. 텍스트 입력 기능을 갖춘 주변의 각종 에디터나 워드 프로세서에서 제2군 단축키를 지원하지 않는 프로그램은 없다. 정말 내 프로그램밖에 없는 것 같다. -_-;; 이는 거스를 수 없는 대세라 여겨지고 또 사용자의 건의도 있으니 이걸 이제야 반영했다.

그럼 낱자/글자 모드를 전환하는 기존 shift+ins를 어디로 옮길지가 문제인데.. 의외로 간단하게 해결했다. 그냥 ctrl+ins로 옮겼다.
Ctrl+ins는 텍스트에 블록이 잡혀 있을 때는 복사 기능을 수행하고, 블록이 없을 때는 낱자/글자 모드를 전환하게 했다. 텍스트를 타이핑으로 수정하는데 블록을 잡을 일은 전혀 없을 테니 이렇게 해도 영역이 전혀 겹치지 않는다.

3. 편집기: 자잘한 UI 개선

(1) 도구 메뉴에 있는 텍스트 분량 계산 기능을 크게 강화했다.
텍스트 중의 확장 평면(surrogate) 글자 수, 대략의 공백(whitespace) 수와 단어 수를 추가로 표시해 준다.
일본어· 중국어는 띄어쓰기가 없으니 전각 구두점만으로도 단어 구분이 되게 했다.
그리고 블록을 잡았다면 블록이 텍스트 전체에서 몇 % 정도 차지하는지도 나오게 했다.

(2) 예전에 날개셋 편집기에서는 텍스트를 스크롤 하거나 인쇄할 때, 화면 내지 페이지의 맨 마지막 줄은 그 아래의 줄 간격을 계산에 또 반영하지 않도록 동작이 개선된 적이 있었다. 그럴 필요가 없기 때문이다.
이와 비슷한 최적화가 세로뿐만 아니라 가로 스크롤에 대해서도 행해졌다. cursor가 줄의 맨 끝에 있을 때는 굳이 반각 한 칸 공간을 확보하면서 스크롤되지 않는다. 홀쭉한 cursor를 표시할 공간만 있으면 스크롤을 더 하지 않게 했다.

(3) 계산기 대화상자에서 오류가 있는 수식을 입력하더라도 그저 씹히는 게 아니라..
텍스트 전체가 블록으로 잡히고, 히스토리를 보관하는 콤보 상자에도 제일 최근 아이템으로 "1회 임시 등록"되게 했다.
그러면 사용자가 수식에서 오류가 있는 부분만 고쳐서 다시 계산을 시도할 수 있다.
수식이 오류 없이 정상적으로 계산되면 오류 수식은 히스토리에서 제거되고 맞는 수식으로 대체된다.

(4) 찾기 명령을 내렸는데 텍스트가 더 없으면 "도로 역방향으로 찾으시겠습니까, 문서 처음부터 다시 찾으시겠습니까?" 물음이 뜬다. 이 두 번째 시도에서도 텍스트가 전혀 나오지 않으면 그때는 "찾는 문자열이 없습니다" 메시지가 뜨게 돼 있다. 이 로직 자체는 맞다.

그런데 내 프로그램에는 애초부터 '문서의 맨 처음부터 검색'하는 옵션이 있다. 이 옵션을 켰는데도 match가 발견되는 게 없다면 저렇게 "찾는 방향이나 위치를 변경해서 재시도 하시겠습니까?"라고 또 물을 필요가 없다. 그때는 바로 "찾는 문자열이 없습니다"를 출력하도록 로직을 개선했다.

(5) 내 프로그램에는 문자열을 찾는 게 아니라 특정 코드값을 만족하는 문자를 찾는 기능이 있다. 얘로 검색을 시도했는데 찾는 문자열이 없으면.. 대화상자가 종료되지 않고 다시 검색을 시도할 수 있게 UI 동작을 고쳤다.

4. 입력 패드: 미세하게나마 성능 개선

날개셋 한글 입력기의 구현체 중에 입력 패드는.. 아무래도 편집기나 외부 모듈에 비해 존재감이 없는 잉여에 가깝다. 한번 엔진을 만들고 나서는 고칠 게 거의 없는 물건이다만, 이번에 의외로 대대적인 '최적화/성능 개선' 작업이 행해졌다.

(1) 이 프로그램은 동작 원리의 특성상, 64비트 OS에서도 32비트 프로그램들을 지원하기 위해서는 64비트 버전과 32비트 버전을 모두 실행해서 메시지 훅킹을 제각기 구동해야 한다.
그러니 32비트 버전의 경우, 32비트 운영체제에서 단독 실행될 수도 있고, 64비트 버전을 보조하는 간편 모드로 실행될 수도 있다.

간편 모드로 실행됐을 때는 자체적으로 GUI를 표시하는 게 전혀 없고(전부 64비트 버전이 전담하니) 하는 일도 매우 단순하다. 그렇기 때문에 굳이 32비트용 날개셋 커널을 로딩할 필요가 없다.
32비트 버전이 간편 모드로 실행됐을 때는 날개셋 커널을 로딩하지 않도록 동작을 개선했다. 뭐 그래 봤자 메모리 1MB 남짓 절약한 것에 불과하지만.. 불필요한 군살을 이렇게 하나 뺐다. ㄲㄲㄲㄲ

(2) 그리고 32비트 호스트를 내부적으로 실행하는 것도 무조건이 아니라 입력 도구를 하나 끄집어냈을 때, 키 입력 모드를 켰을 때처럼.. 사용자가 진짜로 그런 기능을 수행할 때만 하도록 했다.
이런 최적화는 해 봤자 당장 성능에 큰 차이는 없겠지만.. 64비트 환경에서 32비트 의존을 최대한 줄이겠다는 상징적인 차원에서 행해졌다.

5. 보조 입력 도구: 화면 키보드

날개셋 한글 입력기에 '화면 키보드'는 정말 유구한 역사를 자랑하는 입력 도구이다. 다음 버전에서는 다음과 같이 외형이 바뀌고 자잘한 기능이 추가될 예정이다.

(1) Windows 글꼴을 사용하는 경우, 문자들이 진하게 표시되게 했다. 이렇게 하니 가독성이 훨씬 더 나아졌다.
지금은 문자 키의 우측 상단에 자그맣게 고정적으로 붙어 있는 123 QWERTY...가 쓸데없이 진하게 찍혀 있었는데 로직을 바꿨다. 또한, 구형 운영체제에서 그 123 QWERTY...의 크기가 잘못 계산되어 큼직하게 찍히던 문제를 같이 해결했다.

(2) 한 글쇠에 대해 글쇠배열은 원래 자리와 shift를 합쳐서 2줄로 출력된다. 그러나 평소에는 원래 자리의 것만 표시되게 하는 '1줄 모드' 옵션을 이번에 추가했다. 윗글쇠 자리는 shift를 누르고 있는 동안에만 표시된다.
이렇게 하면 글쇠배열이 더 깔끔하고 알아보기 편할 것이다.

(3) 자체 비트맵 글꼴은 Windows 글꼴과 달리 크기 조절이 되지 않는다. 그래서 글쇠배열을 크게 키워도 너무 작게 찍혀서 문제인데..
이제 창 크기를 '대형'으로 하면 글자를 2배로 확대해서 출력하게 했다. 1줄 모드일 때는 창 크기를 '중형'으로만 해도 2배로 확대된다.

Posted by 사무엘

전등, 텔레비전, 전화기, 냉장고 같은 평범한 백색 가전제품 이후로 21세기에 인간들의 전기 소비량을 특별히 크게 증가시킨 물건은 시대별로 다음과 같다.

1. 2000년대: 에어컨

20세기 중반에 미국에서 이게 처음 도입됐을 때는 사무실의 시원한 에어컨 바람이 너무 좋아서 직장인들이 퇴근을 안 하고 잔업· 야근을 자처했을 정도였다고 한다. ㄲㄲㄲㄲ
그 당시엔 에어컨이 집집마다 비치되기에는 너무 비싸고, 결정적으로 전기 소모도 장난이 아니었으니까.. 회사와 직원 모두 윈윈이다.;;

1990년대까지만 해도 버스나 지하철 열차 안에 에어컨 냉방이 없었고, 학교 교실에도 천장엔 에어컨이 아니라 선풍기가 달려 있었다.;;
그렇잖아도 비효율적이고 열 풀풀 나는 저항 제어 전동차를 여름엔 어떻게 타고 다녔을까? 찜통 그 자체였을 텐데. ㅠㅠㅠㅠ 1990년대엔 지하철 승강장도 너무 덥다고 TV 뉴스의 카메라 출동 같은 시사 고발 섹션에서 지적할 정도였다.

1970년대에 울나라에서는 그 비싼 에어컨이 석굴암 내부에 설치된 적이 있었다. 습도 조절 때문에.
그런데 그 시절에 운행됐던 관광호 및 새마을호 열차는 객실에 벌써부터 에어컨이 있었을 정도라니 이건 뭐 초 호화 금수저 열차였다.

통계에 따르면 가정집 에어컨 한 대가 가정용 선풍기 30대의 전기를 잡아먹는다는 말이 있고, 소형 승용차용 에어컨은 엔진 출력을 4~5마력 정도 깎아먹는다고 한다.
지금도 이북 평양의 아파트들 풍경에서 에어컨 실외기가 눈에 띈 적은 없을 것이다.;;

2. 2010년대: 스마트폰

이건 그야말로 사람이 머무는 곳 어디에나 콘센트나 보조 배터리를 필요하게 만든 주범이다.
요즘 전화기는 간단한 전화기 기능만 있던 2000년대 폴더폰/피처폰 시절에 비해 전력 소모가 정말 어마어마하게 늘어나 있다. 매일 AA 사이즈 건전지 5~6개씩을 소모하는 것에 맞먹는다고 한다.

나 옛날에 초창기 폴더폰/피처폰 쓸 때는.. 배터리 용량이 총 4칸으로 표시됐는데, 걸거나 받지 않고 가만히 있으면.. ‘이틀’ 지난 뒤에 한 칸이 줄어들어던 적이 있다. 그대로 방치하면 진짜 6~7일 가까이는 갔다.;; 도저히 믿어지지 않지? ㅡ,.ㅡ;;
우리나라 KTX 고속철 최초 차량의 내부에 콘센트가 없었던 이유도 1990년대에 이런 걸 예측을 못 했기 때문이었다. 서울-부산을 1시간 56분 만에 찍을 건데 굳이 저런 시설까지 갖출 필요는 없다고 여기고 넣지 않았었다.;;

30여 년 전 Windows 3.x 및 9x 시절에는 컴터를 쓰면서 사용자가 운영체제의 리소스 퍼센티지를 민감하게 관찰하곤 했었다.
그러나 요즘 사람들이 뭔가 퍼센티지를 들여다보는 건.. 폰 배터리일 것이다.

비슷한 맥락으로, 30여 년 전에 사람들이 컴퓨터에서 뭔가 먼지를 주기적으로 청소해 주는 건 볼 마우스 안이었지 싶다. =_=;; 그러나 요즘 사람들이 먼지를 청소하는 건 폰 충전 단자 주변이지 싶다.
폰 충전 단자도 규격이 통합되지 않아서 기기마다 제각각이던 시절이 있었는데.. 이제는 아이폰까지 USB C로 통합되는 나날이 도래했다.

3. 2020년대 이후 전기 등골 브레이커계의 다크호스는 과연 전기차가 차지할까?

그 많은 자동차들까지 전기 인프라에 빨대를 꽂기 시작한다면 이건 원자력 발전이 없이는 도저히 감당이 안 될 텐데 말이다.;;
핵융합은 지금보다 더 낮은 온도에서 일으키려고 애쓰는 현상이고,
초전도는 지금보다 더 높은 온도에서 일으키려고 애쓰는 현상이구만. 하지만 둘 다 아직은 SF의 영역이다.

전기차는 비슷한 체급, 성능의 기름차보다 무게가 수백 kg 이상 더 나간다.
오~ 지금까지 생각을 안 하고 지냈네. 현타가... =_=
전기차는 정작 엔진룸 안은 기름차보다 훨씬 더 단순하고 깔끔하고 가벼운데도 말이다.

쟤들이 엔진오일이 필요하나, 냉각수가 필요하나~ 점화 플러그가 필요하나~ 연료 필터 공기 필터가 필요하나, 터보차저가 필요하나, 배기가스 정화 장치가 필요하나.. ㄲㄲㄲㄲ
그런데 빳데리가 이 모든 장점을 싹 씹어먹는다.
게다가 빳데리가 야기하는 공간 복잡도 무게 복잡도는 필요한 전력량(= 차 크기 내지 모터 출력)의 제곱 이상에 비례해서 급격히 커진다.

옛날에 구닥다리 브라운관 방식으로 텔레비전을 지금 수준으로 대형화하는 게 도저히 불가능했던 것과 비슷한 맥락이라고 생각하면 되겠다.
이러니 빳데리 전기 방식으로 버스나 대형 트레일러, 군용차, 국가원수 의전차, F1 레이싱카는 요원한 거지 싶다. 승용차나 시내버스, 소형 트럭 같은 일부 분야만 대체하겠지..

참 어려운 문제이다. 오늘날의 배터리 기술이 용량은 많이 늘렸지만, 그게 아무 부작용 없이 늘린 게 아니고 아직 갈 길이 멀다. 무게, 가격, 안전성 따위.. 기름 담긴 말통을 대체하는 게 쉽지 않다.

Posted by 사무엘

인류가 물 위를 건너기 위해 선박이라는 물건을 만들어서 띄운 지는 수천 년이 됐다. 심지어 그걸로 바다 위에서 전쟁도 치렀다.
하지만 그걸로 사람만 잔뜩 실어 나르는 장거리 전문 여객선이라는 게 등장한 건 역사가 의외로 짧다.

전근대 시절에는 평민들의 경제력과 교통 수요가 그런 걸 받쳐 주지 못했다. 거기에다 그 당시엔 선박 자체가 너무 위험하고 느리고 정시성을 장담 못 하는 물건이었다.
배 타고 망망대해로 나가는 것의 포스와 리스크가 요즘으로 치면 과장 보태서 무려 우주로 나가는 것에 맞먹었다. 보험 회사의 이름이 'oo 화재, xx 생명'뿐만 아니라 'xx 해상'이 괜히 있는 게 아니었다. 낭만적인 여행이 절대 아니고 모험 탐험이었다.

그 시절에 사람을 잔뜩 태운 배가 있다면 그건 지하에 노꾼이 잔뜩 탄 갤리선이거나, 아니면 아예 노예 무역선. 둘 중 하나일 뿐이었다. -_-;; 사람을 살인적인 중노동을 시키거나, 아니면 용변도 제대로 못 볼 정도로 꼼짝달짝 묶어서 짐짝처럼 쌓아 놓거나.. 둘 중 하나였다.
(단, 노예이면서 동시에 노꾼이지는 않았다. 많은 사람들이 호흡 맞춰서 엉킴 없이 노 젓는 건 극심한 중노동일 뿐만 아니라 전문성도 필요했다. 일자무식에다 더 잃을 것도 없는 노예에게 믿고 맡길 수 있는 일이 아니었다. ㄲㄲㄲ 질 낮은 죄수를 호락호락 총 쥐어 주고 군인으로 부려먹지는 않는 것과 비슷한 이치..)

상식적으로 생각해도 50미터 남짓한 길이에 엔진이 아니라 돛-_-이 달렸고 배수량도 200톤이 채 안 될 대항해시대 나무 범선 갖고 호화로운 장거리 여객선 영업이 가능할 리가 없잖아..

근데 그 시절에는 그 가냘프고 열악한 배에 남자들 수십 명이 낑겨 앉아서 신대륙을 개척하러 갔다는 거다. 이 정도면 교도소 복역이랑 선원 생활을 퉁쳐도 될 것 같은데 말이다.
지금 우리가 잠수함에 대해서 생각하는 위험함, 갑갑함, 열악함 등등이 그때는 일반 수상 범선에 적용됐고 수위가 더 높았다.

선박을 굴려서 돈을 벌려면 그 비좁은 공간에 화물을 왕창 실어야 했다. 그러니 선원들 복지는 더 열악해질 수밖에 없었다. 전근대 시절에 선박은 화물 수송이 main이었고, 여객은 거기에 꼽사리로 낑겨 타는 정도였다.

자, 그러면 성경의 요나서도 어떤 배경인지가 완벽하게 이해가 될 것이다. 요나 역시 여느 상선 화물선에 낑겨 탔기 때문에, 편안한 좌석이나 선실이 아니라 어디 한구석에 짱박혀서 잠들었다. 그리고 배가 위험에 처하자 선원들이 손해를 감수하고라도 무거운 화물들을 바다에 버린 것이다. 그건 승객 개인이 들고 다니던 더플빽이나 캐리어 같은 덩치의 짐이 아니었다.

참고로, 옛날 목선 범선에 대해 생각해 볼 거리를 좀 더 나열하자면 이렇다.

(1) 노아의 방주도 오늘날 기준에서는 그렇게까지 막 큰 배는 아니다. 길이 150미터 남짓한 목선이니 대항해시대 범선보다 좀 큰 정도이고, 20세기에 등장한 여객선이나 군함에 비할 바는 아니다. 이 크기와 부피이면 배수량은 여러 자료로 추정하건대 1만 톤 안팎쯤 됐을 거라고 여겨진다.
참고로, 현대의 조선공학 관점에서는 목선은 길이가 100미터, 배수량 2000톤 정도가 현실적인 한계로 여겨진댄다. 목재는 금속처럼 단단하지 못하고, 용접으로 이어붙이지도 못하기 때문이다.

(2) 노아, 요나 이상으로 성경에서 바다 항해를 제일 진지하게 다루는 곳은 사도행전 27장이지 싶다. 바울이 죄수 호송선을 타고 이스라엘에서 이탈리아 로마로 가는 장면 말이다. 자료를 찾아보니 뱃길로 약 2400km 거리라고 한다.
이건 부담 없는 단거리는 절대 아니고 2000여 년 전의 항해 기술로는 더욱 만만찮았을 것이다. 하지만 그래 봤자 태평양이나 대서양도 아니고 기껏해야 지중해 횡단일 뿐인데 그걸 한 번에 못 가서 중간 정박을 하고 겨울을 나네 마네 논쟁이 오갔던 것이다.
게다가 배에 사람이 276명이나(행 27:37) 탔었다. 선내에 공간이 절대로 넉넉하지 않았을 것이고 승선 환경은 몹시 열악했을 것이다.

(2) 500여 년 전, 마젤란의 세계일주 항해는 대장인 마젤란을 비롯해 250명에 달하는 선원을 잃고 배 세 척 중에 한 척만 겨우 귀환하는 개막장 거지꼴 패잔병 상태로 종결됐다. 그럼에도 불구하고..!! 그 배 한 척에 실린 외국 향신료만으로도 그들은 항해 비용을 다 뽑고 남는 흑자 장사를 했다고 한다.
그 시절에 향신료 가격이 지금의 마약 가격 정도라도 됐나 싶다. =_=;; 후추가 아니라 필로폰이었는지.. -_-;; 하긴, 그때는 화약 가격도 그렇게도 비쌌다니까 말이다.

암튼, 이런 열악한 상황은 증기 기관이 발명되면서 획기적으로 바뀌었다. 얘 덕분에 선박이 바람을 거스르는 정시 항해가 가능해지고, 해풍이 불지 않는 육지 한가운데 운하도 주행할 수 있고, 그러면서도 배가 더 크고 무거워질 수 있게 됐다.
배의 재질이 나무 대신 철로 바뀌었고, 동력 전달 매체도 처음에 외륜이 쓰이다가 스크루 프로펠러로 바뀌었다. 엔진조차도 왕복이던 게 터빈으로.. 19세기 후반에 일어난 혁명적인 변화가 아닐 수 없다.

이제 좀 뭔가 호텔 같은 배가 등장할 수 있게 됐다. (해상 호텔이라, 옛날 범선 시절에는 정말 상상도 할 수 없었던 사치.. ㄲㄲㄲㄲ) 민간이 아닌 군함은 훨씬 더 강하고 사정거리 긴 함포를 장착해서 적을 압도할 수 있게 됐다.
1906년경에 영국에서 만든 여객선 루시타니아 호, 그리고 드레드노트 전함이 민간과 군함 각 분야에서 최첨단 과학기술의 산물이었다.

그래서 민간에서는 대서양· 태평양을 건너는 장거리 대형 여객선이라는 게 운항을 시작하고, 군에서는 순양함을 넘어 전함이라는 등급이 등장했다. 19세기 말에 서 재필이니 이 승만이니 하는 우리나라 선각자들도 저런 배를 타고 미국을 다녀올 수 있었다. (비행기 1시간이 선박 1일에 맞먹으니, 편도로 2주 이상 걸렸을 듯.)
그 이름도 유명한 타이타닉이 이 바닥의 정점을 찍었다. 인류가 이런 배를 구경하게 된 지 얼마 되지 않았다.

1차 세계 대전을 겪은 뒤 세계 열강들은 군함만 만들다가 등골 빠지고 공멸하지 말고, 군함을 일정 배수량 이상은 다같이 만들지 말자고 군축 조약을 맺었을 정도였다. 그때는 전함을 더 만들지 말자는 게 지금으로 치면 핵무기를 다같이 만들지 말자고 약속하는 것이나 마찬가지 개념이었다.

그 뒤 선박은 연료가 석탄에서 석유 디젤 기관으로 바뀌면서 리즈 시절을 찍었지만, 비행기가 발명되면서 추세가 또 바뀌었다. 비행기는 터빈을 기반으로 한 제트 엔진이 도입되면서 세계의 하늘을 석권하게 됐다.
오늘날 배가 거대한 건 항공모함이나 초대형 유조선/화물선 정도이고, 인명을 태우는 건 말 그대로 해상 호텔인 관광 크루즈선만이 남았다. 100년 전과 같은 ocean liner(대륙 횡단 정기 여객선)라는 개념은 없어졌다.

거함거포주의는 항공모함 때문에 논파됐고, 지금은 미사일 때문에 더욱 확인사살됐다.
요즘은 해군보다도 해병대에서 상륙작전을 벌일 때 정도에나.. 뒤에서 펑펑 쏴 주는 전함의 함포를 그리워하는 지경이 됐다. 포탄이 그래도 비행기나 미사일보다는 화력 대비 훨씬 더 저렴하기도 하지.

20세기 초-중에는 여객선과 비행선이 대륙을 횡단했다. 그러나 20세기 중-후부터는 여객기와 미사일이 대륙을 횡단하면서 오늘날에 이르고 있다. =_=;;
우리나라 기준으로 여객선으로는 부산에서 일본, 인천에서 중국, 동해안에서 러시아 정도만 갈 수 있다. 즉, 아주 단거리 한정이다.

Posted by 사무엘

(1) 옛날 아폴로 계획 시절의 새턴 V 로켓, (2) F-22 전투기, (3) KTX-산천 열차.
분야가 서로 완전히 다른 교통수단이지만, 이들은 모두 공통적으로.. 맨 앞에 무슨 총검처럼 길쭉하게 삐죽 튀어나온 부위가 있다.
이건 각각..

1. 로켓: 비상 탈출용 로켓이다.

발사 초기에 이상이 발생했을 경우, 승무원이 탄 캡슐을 로켓 본체로부터 사출· 생환시킬 용도로 장착되었다. 승무원들의 탑승 공간을 통째로 사출시키니.. 이건 경비행기에 장착되는 비상 탈출용 낙하산이라든가, 전투기에 장착되는 사출 좌석보다 더 강화된 버전인 셈이다.
단, 2단 엔진까지 무난하게 분리됐을 때쯤이면 이제 고도와 속도가 너무 올라갔고 비상 탈출이 의미가 없어지기 때문에 탈출용 로켓도 같이 분리되고 버려진다.

아폴로 계획 전체를 통틀어서 이 로켓이 실제로 사용된 적은 없었다. 1969년 말의 12호 때.. 로켓이 발사되자마자 벼락을 맞는 바람에 이걸로 승무원들을 비상 탈출시키고 임무를 실패 처리시킬까 사령실에서 고민하긴 했었다. 하지만 그리하지 않았고, 임무도 다행히 성공했다.

2. 전투기: 피토 관이다.

기체 주변의 맞바람의 세기를 측정해서 이 기체의 비행 속도를 구하는 아주 중요한 장비이다. 레이더나 GPS 같은 기술이 개발되기 전엔 비행 속도를 측정하는 방법이 이것밖에 없었기 때문이다. 자동차처럼 바퀴의 회전수로 속도를 산출할 수가 없으니까..
정비 불량으로 인해 피토 관이 제대로 동작하지 않아서 계기판 바늘이 엉뚱하게 폭주하고, 이 때문에 조종사가 조종을 잘못해서 비행기가 추락까지 한 사고도 역사적으로 있었다.

다만, 피토 관이 꼭 저렇게 앞에 돌출된 형태로 장착될 필요는 없다. 그렇기 때문에 여객기의 피토 관은 옆구리나 꼬리날개 쪽에 훨씬 작게 장착되기도 한다. 자동차에 안테나가 옛날에 길쭉한 삼단봉 형태이다가 지금은 작은 상어 지느러미 모양으로 바뀐 것처럼 말이다.

3. 그리고 열차: 이 쇠막대기 빨대의 정체는 무려.. 독일제 최첨단 차량 연결기의 센서이다.

떼제베 기반의 1세대 KTX의 이후에 국내에 도입된 고속철 차량들은 무지막지한 20량 1편성이 아니라, 10량 1편성을 기본으로 하고 필요 시 중련· 연결 운행이 가능하게 만들어졌다.
열차의 연결과 분리를 간편 신속하게, 한편으로 견고하게 하는 건 나름 엄청난 기술이다. 양 차량을 물리적으로 붙들거나 놓을 뿐만 아니라, 서로 전기· 통신 배선 같은 것도 바로 연결이나 분리가 돼야 하기 때문이다.

두 차량이 합체할 일이 있으면 저 삐져나온 빨대가 먼저 상대 차량 연결기를 쑥 접촉하고, 나머지 부위도 찰칵 연결된다. 항공우주 업계에서는 우주 비행체의 합체를 도킹(docking)이라고 하는 반면, 철도에서는 이런 연결을 커플링(coupling)이라고 부른다. 오옷~!
참고로 우리나라의 철도 차량에서 일반적으로 쓰이는 연결기는 이런 것이다.

철도는 동력원뿐만 아니라 선로 분기기나 신호 시스템, 그리고 전철의 집전 방식(가공전차선=_=)까지 하나하나가 다 첨단 기술이다.
달리는 증기 기관차를 배경으로 하는 옛날 서부물을 보면 아주 흔히 등장하는 장면이 둘 있다. (1) 말 타고 달려가서 열차를 따라잡고 탑승하는 거(현대라면 오토바이-_-), (2) 그리고 열차 안에서 무슨 작업을 하고 나서는 뭔가를 조작해서 객차와 기관차를 분리시키는 것..

아마 영화적 허용이 많이 들어갔겠지만, 옛날 열차는 연결기도 구조가 더 허술해서 차량을 분리시키는 게 더 쉬웠던 것 같다.

Posted by 사무엘

1. 단 한 가지 장점

세상에는 단점이 많고 정말 불편하고 너무 비효율적이어 보이지만.. 여전히 쓰지 않을 수 없는 물건, 기계, 방법론 따위가 있다. 장점이 단점들을 다 씹어먹는 수준이고 다른 대안이 현실적으로 도저히 없기 때문이다.

(1) 교류 전기: 전기공학 이론의 난이도를 한 100배쯤 더 끌어올린 주범이다=_=. 직류보다 취급하기 너무 복잡하고 어렵고, 전자기기들에서는 어차피 직류로 변환도 해야 된다.
하지만 발전과 변압이 간편하고, 덕분에 대용량 전기의 초장거리 송전이 용이하다는 거.. 이 독보적인 장점 하나가 다른 모든 단점을 씹어먹었다. 건전지나 깨작거리는 수준으로는 오늘날 같은 눈부신, 찬란한 전기 문명이 절대 이뤄질 수 없었다.

(2) 헬리콥터: 고정익기보다 느리고 연비 안 좋고 대량 수송도 안 되고 너무 시끄럽고..;; 온통 단점뿐이지만 활주로 없이 수직 이착륙 가능하고 공중에서 정지할 방법이 이것 말고 더 있으리..??
(로켓도 양력이 아니라 추력만으로 공중에 뜨니 헬기 같은 기동이 이론적으로 가능은 하다. 하지만 걔는 헬기보다도 연비가 훨씬 더 안 좋다. -_- 로켓은 동체 대부분이 연료로 꽉 차 있으면서도 자동차나 비행기와 달리 엔진을 겨우 '분 단위'로밖에 가동을 못 한다.)

(3) 주사기: 아프고 공포스러운 데다 감염 위험도 있다. 하지만 먹거나 바르는 약보다 훨씬 더 빠르고 효과 좋으면서, 대놓고 배를 가르는 수술보다는 훨씬 더 간편하고 안전하다. 이 독보적인 장점을 대체할 다른 수단이 없다.

과학기술 분야는 전혀 아니지만, 복음 전하는 방법으로 거리 설교도 이와 비슷한 부류라고 개인적으로 생각한다.
불신자뿐만 아니라 교인들조차도 상당수가 부정적인 편견과 안 좋은 인식을 갖고 있다. "저래 갖고 누가 듣나", "광신자라고 욕 먹고 신고나 당하지", "그냥 어려운 주변 이웃 도우면서 이미지 제고나 하는 게 낫다" 등등..

근데 저 방법 말고 세상 사람들이 예수 천당 불신 지옥 메시지를 듣고 경고를 받고 복음을 들을 통로가 뭐가 있겠나? 그 사람들이 제 발로 기독교 방송을 듣겠나 스스로 성경을 찾아 읽겠나? 거부, 거절, 부정적인 피드백은 당연한 것이니 제대로 전한 것만으로 씨앗을 뿌린 것이다. 저건 주사기만큼이나 더 나은 다른 대안이 없다.

다시 과학기술 얘기로 돌아오면..
저 사례들과는 정반대로, 언뜻 보기에 많은 장점이 있어 보이지만 치명적인 단점 한두 가지가 해결이 안 되어 주류가 못 되고 묻혀 버린 기술도 있다.
무탄피총이라든가 비행선, 반켈 엔진 같은 거 말이다.

2. 세분화, 전문화

대학 이상의 고등교육을 받고 인간이 이룩한 온갖 과학기술, 특히 공학의 세계를 맛보기나마 접하면서 느끼는 점 중 하나는..
이 바닥은 정말 깊게 세분화돼 있어서 한 사람이 모든 걸 다 알기가 불가능하다는 것, 그리고 기계도 하나만으로 이것저것 다 대응 가능하게 만들지는 않는/못한다는 것이다.

현실에서는 스타크래프트 테란과 달리, 단일 차체로 곡사 자주포와 장갑차 역할을 동시에 수행하는 탱크를 만들지 못한다.
미사일 하나만 해도 대공이냐 대잠이냐 대전차냐.. 전투기가 발사하냐 잠수함에서 발사하냐에 따라 미사일의 형태와 폭약과 추진제의 구조가 다 달라진다. 하나 만드는 정밀 기술로 다른 분야를 커버할 수 없다.

물에서 항해도 가능하고 공중 비행도 가능한 비행정은 비행기의 태동 초기에 잠깐 쓰이다가 말았다. 물 저항을 적게 받는 디자인과 공기 양력을 잘 받는 디자인에 서로 교집합이 없기 때문이다.
항해도 가능하고 지상 주행도 가능한 호버크래프트/수륙양용차 같은 건 해병대 상륙 작전용으로나 쓰이지, 여객용..?? 아니올시다. 가성비가 맞지 않는다.
로터를 기울여서 헬리콥터도 되고 프로펠러기도 되는 비행기조차도 성능이 어정쩡하고 비싸서 널리 실용화되지 못했다.

그리고.. 비행체 엔진만 해도 지상에서 뜰 때, 아음속 비행, 초음속 비행, 심지어 우주 기동에 적합한 엔진의 형태가 다 다르다.
단일 엔진 단일 기체만으로 단 분리 없이 대기권과 우주를 모두 비행..??? 현재 인간의 기술로는 불가능하다.
이러니 SF물만 많이 봤던 사람들이 아폴로 우주선의 '달 착륙선'을 보면 깜짝 놀라는 것이다. 유체역학적인 디자인이 전혀 아니기 때문에.

• 이거 뭐 첫 이륙과 출발 때는 터보 팬이나 터보 제트를 썼다가 극초음속에서는 램 제트..?? 변속기를 넣어서 자동차처럼 기어비를 바꿀 게 아니라 아예 속도별로 엔진을 바꿔 끼워야 할 지경이다. 기술적으로 당연히 불가. ㄲㄲㄲㄲㄲㄲㄲ
• F1 레이싱용 자동차들은 정말 서킷 전용으로 극도로 특수하게 만들어진 놈들이다. 시내를 달리는 일반 자동차들처럼 신호 받으면서 저속으로 가고 서다 하다가는 다 퍼지고 고장날 거라고 한다.
  
• 시속 200짜리 기록 도전용으로 만들어지는 특수한 자전거도 마찬가지. 기어비를 극단적으로 높게 맞춘 채로, 공기 저항을 몸빵해 주는 자동차를 졸졸 뒤쫓아가는 것에만 특화돼 있다. 이 자전거를 사람이 정지 상태에서 페달 밟아서 시속 200까지 몽땅 가속시키는 건 아니며 그럴 수는 없다고 한다.. -_-;;;
  

동력 기관 말고 안전 장치만 해도, 총알을 막아 주는 방탄유리가 교통사고 때 쉽게 깨지지 않는 안전유리의 역할까지 동시에 수행하지는 못한다.
오토바이 헬멧이랑 공사장 헬멧도 역할이 다르며, 방검조끼와 방탄조끼 역시 한쪽이 다른쪽 영역까지 동시에 보호해 주지 못한다는 한계가 있다.

하긴, 굳이 물건뿐만 아니라 사람의 전문성도 마찬가지이다.
미친 난이도를 자랑하는 리스트의 클래식 피아노를 치는 전공자라도 재즈 반주를 보면 벙 쩔 수 있다. 영역이 완전히 다르기 때문에.
공기총 스포츠 사격 금메달이랑, 군대 육군 소총수의 특등사수 사격, 그리고 특전사 저격수의 사격은 다들 영역이 다르고 잘 호환되지 않는다. 한쪽을 잘하는 사람이 다른 분야까지 전문가를 겸하지 못하며, 그나마 원래 전문인 분야도 며칠만 연습· 훈련을 게을리하면 금세 감이 무더져 버린다.

그러니 사람뿐만 아니라 총기도 용도별로 특성이 모두 다른 건 당연지사다.
저격수 정도로 극도로 민감하고 전문적인 분야로 오면 총도 무슨 악기마냥 전용 케이스에 넣어서 고이 간직해야 하고, 수시로 닦아 주고 손질해야 한다.
유효 사정거리를 겨우 100~200m로 잡는 일반 쫄병들이야 훈련용 총 따로, 실전용 총이 따로이고 소총과 함께 진흙탕에 막 뛰고 뒹굴기도 한다만.. 그런 건 저격수한테는 상상조차 할 수 없다.

3. 한 10년 전부터, 앞으로 2~30년 안으로 없어질 거라고 난리였던 것들

(1) Java, C# 같은 가상 머신 언어가 주류가 되고, 구닥다리 C/C++ 프로그래밍은 한물 갈 거다
그럴 리가.. C++이 2010년대 이후부터 얼마나 괴물 같은 문법과 기능들이 마구 추가되고 상상을 초월하게 바뀌었는지를 알면.. 저건 이불킥 수준의 단견임이 느껴질 거다.
아 물론 MFC 같은 일부 프레임워크는 한물 간 거 맞다. 기존 프로젝트들을 유지보수 하는 용도로만 쓰이지 신규 제품 프로젝트를 저걸 써서 진행하는 경우는 거의.. (간단한 내부 툴, 데모, 쌤플 정도나 만드는 경우 말고) 전멸이다.

(2) Windows NT 커널이 없어질 거다
마소에서 차세대 Windows를 표방하며 한때 개발했던 Midori니, Windows 10X 같은 건 전부 망했다. 만들려다 말았고 개발 중단됐다. NT 커널이 없어진다니 그게 말이나 되는 소리인가.;;
마치 인텔에서 x86 말고 다른 계열 CPU를 만들려다가 만 것과 비슷한 취급이다. 과거의 Itanium이라든가 i860, i960 같은 거.

(3) 폰트에서 힌팅이란 게 없어질 거다
요즘 서브픽셀 안티앨리어싱 기술이 많이 발달했고, 어지간한 디스플레이 해상도가 30~40년 전의 도트 프린터에 근접하기는 했지만..
그래도 작은 본문 글씨에서 힌팅이 있고 없고의 차이는 유의미한 걸요?? 힌팅 없으면 획이 뿌옇고 뭉개지는 게 여전히 티가 난다.
맑은 고딕도 언뜻 보기엔 100% ClearType빨인 것 같지만.. 똠 뷁처럼.. 2350자 밖의 비완성형 글자를 작게 찍어 보시라. 힌팅이 적용된 일반 2350자 글자보다 훨씬 못생겨진다.

물론 옛날처럼 한땀 한땀 쑤제로 정교하게 힌팅을 할 필요는 없고, 심지어 대부분의 절차가 자동화, AI화는 될 것이다. 그러나 완전히 없어지지는 못할 거다. 마치 비행기 유인기 vs 무인기의 역할 분담과 비슷한 관계가 될 듯하다.

Posted by 사무엘