간음하다가 붙잡힌 여인

성경의 요한복음 8장의 초반부에 나오는 “간음하다 붙잡힌 여인” 사건은 비기독교인이라도 모르는 사람이 거의 없을 것이다. 성경에 기록되어 있는 매우 유명한 일화이다. 그러나 인지도가 높은 만큼 사건에 대한 오해도 굉장히 많다.

1. 먼저, 통념과는 달리 이 이야기--정확히는 요 7:53부터 요 8:11까지--는 정말로 원래 성경 원문에 있었는지 의심을 받고 있다. 거의 모든 성경들을 보면 “오래 된 사본에는 이 단락이 없음. 이것은 후대에 추가된 것임.” 같은 단서가 붙어 있다! 신약 성경에서 마가복음의 마지막 열두 구절(막 16:9-20)과 더불어 양대 의심 단락인 것이다.
물론 KJV 신자에게는 이것은 전혀 고려 대상이 아니다. 이것은 시내 사본 및 바티칸 사본 같은 변개된 고대 필사본을 기준으로 하는 잘못된 주장일 뿐이다.

2. 간음은 여자 혼자서 지을 수가 없는 죄다. 간음하다가 누군가가 현장에서 적발되었고 이에 대해 여러 사람의 증언이 일치한다면, 율법대로라면 간음을 저지른 “남자와 여자를” 모두 죽여야 한다. 그런데 저 사건에서는 남자는 어딜 가고 왜 여자만 붙잡혀 있는가? 단순히 여자의 순결이 의심되기만 하는 상황이라면 곧장 죽일 게 아니라 민수기 5장의 판별법을 사용해야 한다.

3. 여자는 법적으로 증거가 부족하기 때문에 예수님으로부터 단순히 법적으로 무죄 판결을 받은 것이다. 무슨 털어서 먼지 안 나는 사람 없으니 무조건 다 사랑과 아량으로 감싸자는 식으로 물타기 된 게 아니다! 이 사건은 무슨 사형제 폐지, 간통제 폐지 등 온갖 이상한 비성경적인 프로파간다를 정당화하는 명분이 절대로 될 수 없다.

4. 또한, 그 여자는 예수님을 “주님”이라고 부름으로써 구원받았다고 우리가 충분히 생각할 수 있다. (요 8:11)

5. 북한 문화어로 성경을 번역한다면 stone(동사)을 '돌탕치다' 정도로 번역해도 되겠다.

6. 간음하다 붙잡힌 여인 사건은 이런 패러디나 만들라고 성경에 기록된 게 아니다~~!

사용자 삽입 이미지

Posted by 사무엘

2013/12/26 19:22 2013/12/26 19:22
,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/913

언어의 기원에 대한 생각

“처음에 말씀이 계시니라. ...” (요 1:1)
우주 만물을 창조하신 하나님은 왜 하필 자신을 '말씀'이라고 성경에서 계시하셨을까?

인간의 언어라는 건 자연과학의 영역인 우주, 지구, 생명체 세포 같은 것 만만찮게 참 신기한 물건이 아닐 수 없다.
문자는 수천 년 전에 인간이 발명했지만 문자의 기록 대상인 그 언어 자체는 어디에서 유래되었는지 생명 자체의 기원만큼이나 정말 “아무도 모른다.”

생명의 기원에 대해서 창조 아니면 진화밖에 답이 없듯이,
언어의 기원에 대해서도 신수설 아니면 인위적인 발명설밖에는 선택의 여지가 없다.
더구나 언어는 화석이 있는 것도 아니고 방사성 원소 연대 측정 기술이 있는 것도 아니니.. 진짜로 뭐 과학적인 방법론을 동원하여 연구할 여지 자체가 없다.

게다가 언어의 우열이나 기원을 함부로 가리는 건 정치적으로도 꽤 민감한 영역이기도 하다.
이 분야에 검증 불가능한 추측과 낭설들이 하도 많이 떠돌다 보니, 언어학에 관심이 있는 분이라면 익히 잘 알듯, 먼 옛날 1866년에 파리 언어학회가 아예 공개적으로 이 분야는 불가지론의 영역이라고 못을 박아 버렸다.
언어의 기원에 대한 연구 같은 건 금지하고, 이 분야의 논문은 무조건 거절하겠다고 선언한 것이다.

난 무생물에서 생물이 우연히 생겨날 수 없고 원숭이가 아무리 긴 시간이 흘러도 사람으로 진화할 수 없다고 믿는다.
이와 같은 맥락으로.. 동물의 울음과 사람의 말은 넘사벽 급으로 서로 다르다.

겨우 몸짓, 손짓, 맘마, 빠빠, 쭈쭈, 끙끙에서...
촘스키 계층으로도 다 설명을 못 하는 그런 재귀적이고 복잡한 언어 문법이 점진적으로 생성되었을 거라고 생각하지 않는다.
그리고 이상한 날랄랄따따따 방언이 질서를 갖춘 정상적인 인간의 언어라고 생각하지도 않는다. ㅎㅎ
이건 내가 개인적으로 그렇게 생각한다는 뜻이지, 언어의 기원과 관련해서 나와 견해가 다른 사람을 디스한다거나 논쟁하겠다는 의도는 아니다.

NOTES
1. 한국어는 언어 계통상 고립어로 간주되고 있다. 우랄 알타이 어족 떡밥은 약발이 다한 지 오래이고, 주변에 유사한 언어를 도무지 찾을 수 없는 굉장히 특이한 언어라는 뜻이다.
일본어와 더불어 고립어치고는 그래도 사용자가 많은 축에 드는 언어이고, 또 영어권 사람이 배우기 몹시 어려운 언어로 분류되어 있다.

2. 우리말에는 '말'의 높임말로 '말씀'이라는 아주 좋은 말이 있어서 성경 용어로도 즐겨 쓰인다.
다만, “교장 선생님 말씀이 계시겠습니다.”는 잘 알다시피 높임법이 어긋난 문장이다. 말씀이 '계실' 수 있는 문맥은 요한복음 1:1과 요한일서 1:1 정도밖에 없을 것이다.

Posted by 사무엘

2013/12/24 19:31 2013/12/24 19:31
, ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/912

가장 좋은 반공 교육

우리나라 대한민국은 해방 이후로 기적적인 성장을 이뤘다. 그러나 저 이북 동네는 오로지 자기 권력 유지만을 위해 다른 공산주의 종주국조차 가지 않은 최악의 길만을 골라서 가면서 고립과 폐쇄, 공멸의 길을 갔다. 그리고 40년 전이나 지금이나 그들이 품고 있는 대남적화 야욕은 하나도 바뀌지 않았다.

한편으로는, 꿈도 희망도 없고 심지어 종교조차 없는 주민들이 절망 끝에 상당수가 전국적인 수준으로 마약에까지 빠진 것은 흔히 접하는 기아· 영양실조나 정치범 수용소 같은 것과는 레베루가 다른 문제다. 안 그래도 0으로 수렴해 가던 남북간의 화합· 일치 가능성을 완전한 0으로 확인사살 시키는 심각한 문제가 아닐 수 없다. 원래는 마약이 위조지폐, 불법 무기와 더불어 북한의 외화벌이 수단 중 하나였는데, 그게 국제간의 단속이 강화되면서 수출이 불가능해지자 북한 내부에서 나돌기 시작하면서 나라를 헬게이트로 만든 것이다.

정말 국제적으로도 나쁜짓은 가지가지 골라서 하는 양아치들이다. 중국이 탈북자를 강제 북송시키는 것은 인륜적으로 지탄받아야 마땅하다. 하지만 걔들이 마약 유통을 단속하는 건 지극히 정당한 행정 조치이지 않은가.
어지간해서는 정치적인 발언은 자제하려 하나, 소위 친북 정권의 햇볕 정책이라는 건 저런 북한의 본질적인 문제는 하나도 전혀 해결한 게 없으면서 그저 북한에게 나쁜짓 할 자금만 잔뜩 그것도 심각하게 많은 액수로 준 걸로 보인다. 그러니 내가 도무지 고운 시선으로 볼 수가 없는 것이다. 뭐 아무튼.

현실이 엄연히 그런 이상, 우리는 알량한 민족 드립에 현혹되지 말아야 하며 반공 정신이 그때나 지금이나 필요하다는 것을 인지해야 할 것이다. 우리나라 정치인들이 아무리 밉고 마음에 안 들어도, 김씨 부자가 그들보다 나을 거라고는 생각하지 말아야 한다.
그런데 반공 교육이라 하면 뭐 어떤 게 떠오르는가? 내 경험상 내가 생각하는 가장 바람직한 반공 교육은

  • 그저 북한 공산당의 잔인한 만행만 부각시키면서 증오심, 적개심을 키우는 것이 아니요,
  • 경제 이론을 들먹이면서 공산주의는 실패했고 자본주의가 승리했다는 유치한 숫자놀음이 아니요,
  • 우리나라 정치· 법조계에 간첩· 종부기들이 이미 싹 다 깔려서 나라가 거덜나기 직전이라고 호소하는 것도 아니요,
  • 심지어는 종교적으로 접근해서 신을 부정하는 공산주의는 마귀 적그리스도 666 식으로 선동하는 것도 아니다.

아 물론... 김 정은의 목을 따라고 초특급 인간흉기 북파공작원이라도 양성한다면야 그 정도 요원에겐 정신교육 차원에서 '원쑤'에 대한 무조건적인 적개심 세뇌를 시켜야 할 것이다.

그런 게 아니고 일반인들에게 가장 필요한 건.. 역시나 우리나라의 수립과 발전 과정에 대한 “감사와 자부심”, 그리고 위의 권위에 대한 “신뢰”가 아닌가 싶다.
한 마디로 말해 남에 대한 디버프가 아니라, 나에 대한 버프가 필요하다! 이 방식 말고 다른 방식으로 사람의 마음을 돌려 놓기란 대단히 어렵다.

마치 학교에서 하는 성교육으로 어린 학생에게 성경적인 성 관념을 심어 줄 수 없듯, 저런 사상도.. 형식적이고 유치한 “때려잡자 공산당” 식의 반공 교육만으로 형성될 수 있는 게 아니다.
자기 나라에 아무 애착도 없고, 이상한 음모론이나 믿는 사람들에게 백 날 간첩· 종부기 드립을 쳐 봐야 씨알도 먹히겠나?

방향이 잡히면 모든 문제가 해결된다. 왜 우리나라가 이상적인 방향으로 발전하지 못했는지 그 이유가 이해되고, 그럼에도 불구하고 이만치라도 온 게 정말 기적에 가까우며 그 비결이 무엇인지가 이해된다.
큰 방향이 잡히고 나서는 더 세부적인 팩트, 데이터 같은 건 그저 논쟁용으로나 필요한 것일 뿐이다.
그리고 이런 주장은 무슨 일베니, 뉴라이트니 친일 나부랭이 같은 특정 계층의 머릿속에만 존재하는 이상한 딱지와는 아무 상관도 없는 선량하고 건전한 애국 사상임을 알게 된다.

그리고 나는 그 '버프'의 많은 부분을 우리나라 철도를 통해서 받았다~!!ㅋㅋ

Posted by 사무엘

2013/12/22 08:20 2013/12/22 08:20
, ,
Response
No Trackback , 4 Comments
RSS :
http://moogi.new21.org/tc/rss/response/911

교통사고 분석

* 모닝와이드 -- 블랙박스로 본 세상 시리즈.
운전 중에 교통사고를 당하거나 주변의 교통사고를 목격한 시청자의 블랙박스 제보 영상을 소개하는 프로이다.
가끔은 현직 변호사로부터 자문을 구해서 저런 상황에서는 가해자와 피해자의 과실 비율이 법적으로 얼마 정도 되는지 해설도 해 준다.
비록 TV 본방 형태는 아니지만, 본인은 안전운전 자가교육(?) 차원에서 유튜브로 저걸 종종 즐겨 본다. 사실, 저 프로는 나 말고도 운전자들 사이에서 굉장히 인기가 많고 시청률도 높다고 한다.

핸들이나 브레이크를 급하게 조작하다 보면, 차가 평소에 내가 조작한 대로 나아가지 않고 정말로 뱅글뱅글 돌고 미끄러지면서 저렇게 패닉 상태에 빠지는구나 하는 생각이 들어 무섭다. 차가 패닉이면 운전자도 “아, 내가 이렇게 죽는구나” 하는 생각에 완전 멘붕에 빠진다.
특히 주행 중에 타이어가 터지면 조향과 제동이 모두 맛이 가서 생각보다 훨씬 더 위험한 상황에 빠지게 된다.

저 프로에서 방영되는 교통사고들은 다음과 같은 여러 패턴들 중 하나로 정리된다.
먼저, 좀 빨리 가려고 교통법규를 위반하다가 사고를 내는 경우이다.

1. 안쪽 차선이 빈 것만 보고는 무리하게 교차로 꼬리물기를 시도하다가, 바깥쪽 차선에서 질주하던 차와 박는 것.. 아슬아슬한 꼬리물기 정도가 아니라 빨간불로 바뀐 지 꽤 오래 됐는데도 대놓고 신호를 위반하는 경우도 있다. 딱 내가 교차로를 지나려 할 때 신호가 노랑-빨강으로 바뀌는 거 정말 짜증나며 그 심정 나도 누구보다도 이해한다. 하지만 반대편 방향 차량들도 자기 신호가 초록불로 바뀌자마자 총알같이 튀어나가려고 매의 눈으로 대기 중이라는 걸 잊지 말아야겠다.

2. 직진 차선(혹은 일반차로)에 차들이 멈춰 선 것만 보고는 무단횡단하거나 U턴 시도하다가 좌회전 차선(혹은 버스전용 차로)으로 달리던 차와 부딪히는 것..

1과 2는 전형적인 병신인증 패턴이다. 단순 과속 차량뿐만 아니라 구급차 같은 긴급자동차, 그리고 사고 현장을 향해 경쟁자들을 제치고 필사적으로 제일 먼저 도착하려는 견인차(wrecker)도 무법 난폭운전 하다가 종종 사고를 내곤 한다.
그 밖에,

3. 답이 없는 졸음운전, 음주운전.;;;
차가 옆 차선을 밟으면서 들썩들썩 불안하게 움직이거나 갑자기 길을 벗어나 도랑으로 푹 빠져 버린다. 사고가 날 때까지 브레이크를 밟은 흔적조차 없으니 더욱 끔찍하다.
한편 음주운전은 좀 강하게 처벌할 수 없나 싶다. 만취 운전자들은 보통 멘탈도 맛이 가 있어서 사고를 내고는 뺑소니를 치는 경우까지 있는데, 이 경우 처벌이 더욱 무거워진다.

4. 고속도로나 그에 준하는 자동차 전용 도로에서 급정거 및 급격한 차선 변경.
도로에 갑자기 동물이나 장애물이 튀어나와서 그거 급히 피하느라 차가 중심을 잃고 뒤집히고 도랑으로 빠진다. 아니면, 그 때문에 멈춰 섰다가 뒷차로부터 쾅 추돌을 당한다.
이 뿐만이 아니다. 옆에서 갑자기 쓱 들이대는 차를 피하려다 혼자 덤탱이를 쓰는 경우도 있다. 심지어는 어느 고문관 운전자가 진출로를 놓쳤다고 차를 길 한가운데서 세우거나 아예 후진· 역주행을 한 것 때문에 사고가 나기도 하고.

5. 무단횡단. 다른 것보다도, 주차된 차들 사이에서 갑자기 툭 튀어나오는 보행자(특히 어린애)는... 전혀 예측 불가이고 한 마디로 답이 없다. 말 그대로 '갑툭튀'다.
아무리 운전자가 갑이고 보행자가 을이어서 어지간한 차-보행자 교통사고는 운전자에게 불리하게 법적 책임이 매겨진다지만..
우리나라는 운전자에게 너무 불리하고 가혹하지 않나 하는 생각이 개인적으로 든다.
차들이 잔뜩 주차되어 있고 옆의 보행자를 확인할 수 없는 곳에서는 자동차는 닥치고 옛날에 영국에서 적기 조례가 있던 시절처럼 슬금슬금 기어가라는 소리와 마찬가지다.

이유야 어쨌든 보행자를 친 운전자에게 거의 무조건 더 많은 과실이 매겨진다면, 반대로 운전자가 무단횡단하는 보행자를 안 치려고 핸들/브레이크를 과격하게 꺾다가 더 처참한 사고를 당했을 경우, 이번엔 그 보행자에게 더 큰 과실을 규정하는 법규라도 있어야 서로 공평하지 않겠는가?

6. 끝으로, 저 동영상 시리즈를 보면서 본인이 가장 깊은 인상을 받은 유형은 이것이다.
바로, 정비 불량 상태인 대형 트럭/트레일러가 주행 중 갑자기 타이어가 터지거나 심지어 타이어가 빠져나와 굴러가는 것... 이거 정말 무시무시한 상황이 아닐 수 없다.

대형차의 타이어는 개당 무게만 이미 수십~100여 kg에 달하는데, 데굴데굴 구르느라 어마어마한 운동 에너지를 갖고 있다. 게다가 동글동글 엄청 잘 굴러간다는 점에서, 단순 적재 불량 화물이 떨어지는 것보다도 더욱 위험하다.

소개하는 동영상에서 15:35 이후의 마지막 에피소드인 <타이어가 위험하다> 편을 보기 바란다.
3~4차선을 달리던 화물차에서 타이어가 빠져나와서 굴러가더니 통통 튀면서 중앙분리대까지 넘어 반대편 승용차의 앞유리를 내리찍고, 이 때문에 2차 추돌사고까지 냈다. 이게 웬 날벼락이냐. 직접 보지 않고는 믿을 수 없다.

게다가 대형차와 얽힌 이런 교통사고는 이 휘소 박사(1935-1977)가 당한 교통사고와 거의 똑같은 패턴이다!
그래서 오래 살았으면 노벨 상까지 받았을 위대한 물리학자가 그렇게 허망하게 도로에서 목숨을 잃었다.
어떤 자료에서는 트레일러의 타이어가 날아와 차 운전석을 강타했다고 하고, 어떤 자료에서는 트럭 자체가 이 박사의 승용차와 정면충돌했다고 하니, 의외로 설이 일치하지 않는 듯하다. 하지만 타이어로 인한 사망 사고라 해도 이는 실제로 불가능한 일은 결코 아님을 알 수 있다.

* 별첨 1: 잡설

- 사실, 자동차뿐만 아니라 비행기도 타이어의 회전과 관련된 고려 사항이 있다. 대형 여객기쯤 되면 어지간한 대형 트레일러보다 덩치가 더 크며, 랜딩기어의 바퀴도 더 많고 더 크고 더 무겁다. 비행기가 이륙하여 땅에서 뜬 뒤에도 10수 개가 넘는 바퀴들은 관성 때문에 시속 300km에 가까운 맹렬한 속도로 한동안 계속 돌게 된다.
랜딩기어를 접어서 기내로 집어넣은 뒤에도 무거운 바퀴들이 그렇게 계속 돌아가고 있으면 비행기의 안정성에도 문제가 생긴다. 그래서 비행기가 뜬 뒤에는 랜딩기어에다 일부러 브레이크를 걸어서 바퀴의 회전을 중단시킨다고 한다.

- 블랙박스 영상들을 보니, 자동차의 앞부분이 파손되는 사고가 난 뒤에는 사고 차량의 앞유리에 갑자기 와이퍼가 동작하는 경우가 적지 않은 듯하다. 와이퍼 스위치나 센서에 자극이 가기라도 하는지, 왜 그렇게 되는지는 잘 모르겠다.

- 아무리 보험사들이 보험금 지급에 인색하다고 해도, 자동차 손해 보험 회사들은 일반적으로 재정이 그리 넉넉치 못하고 적자라고 한다. 들어오는 돈보다 사고 수습을 위해 지출하는 돈이 더 많다는 뜻이다. 결국 교통사고가 잦으면 운전자가 차를 소유했다는 이유만으로 지출해야 하는 보험료 부담이 더 늘 수밖에 없고, 국가와 사회의 경쟁력은 떨어지게 된다.
정말 우리 모두를 위해서 안전 운전 방어 운전을 해야겠다.

* 별첨 2: 대형차의 전방주시 태만 사고

지난 12월 14일엔 경부 고속도로 하행선 경주 휴게소 인근에서 끔찍한 교통사고가 났다.
보도블록을 가득 실은 25톤 트럭이 앞의 승용차를 들이받으면서 4중 추돌 사고로 번졌다.
접촉사고 때문에 정체 서행이 시작되고 있었는데 트럭 운전자가 이를 발견을 못 한 것.

문제는 승용차는 그 25톤 트럭과 자기 앞의 25톤 탱크로리의 사이에 끼였다는 점이다.
차는 형체를 알아볼 수 없이 박살났다.
승용차에는 두 집안의 어머니와 각각의 자녀 2명, 총 6명이 타고 있었고.. 이들은 대형차 두 대에 끼여 으스러진 차 안에서 전부 즉사하고 말았다..;;

하루아침에 처자식을 다 잃은 남편 두 명은 완전 멘붕에 빠졌을 것이고, 한편으로 가해 운전자도 업무상 중과실치사상죄로 인해 직장 짤리고 구속되고, 처자식들이 멘붕에 빠질 것이다. 최소한 세 개의 가정이 파탄에 이르게 됐다.
사고의 원인은 비록 음주운전은 아니지만 트럭 운전사가 라디오 조작하느라 전방주시를 소홀히 한 거라고 한다.

사실, 이 사고는 작년 5월에 발생했던 상주 여자 사이클 선수 교통사고 참사와 판박이다.
그때 역시 규모도 똑같은 25톤 트럭 운전사가 DMB를 보거나 조작하다가 전방의 선수단 SUV 차량과 사이클 선수들을 덮쳤다.
이 사고로 선수 세 명이 사망하고 다른 세 명은 중경상을 입었다.

열악한 환경에서 하루 종일 차만 굴리느라 무료하고 따분한 건 이해하지만..
다른 일에 신경 쓰기 전에 자기가 모는 차량이 얼마나 어마어마하게 무겁고 운동 에너지가 큰 물건인지를 물리 법칙에 입각하여 절대로 잊지 말았으면 하는 바람이 있다.

Posted by 사무엘

2013/12/19 08:37 2013/12/19 08:37
, ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/910

유니코드 1.x가 제정되었을 때는 믿거나 말거나 한글도 글자마디는 완성형 몇천 자만 지금과는 딴판의 영역에 등록되어 있었다. 단, 글자마디뿐만 아니라 옛한글을 포함한 자모도 자음 134개(물론 초성과 종성의 개수는 서로 다르고 따로 등록됨), 모음 66개가 등록되어서 이 자모들을 아래아한글 2.x가 한컴 2바이트 코드에서 그대로 채택해서 썼다. 한컴 2바이트 코드는 기존 조합형 코드와 유니코드를 적당히 짬뽕한 문자 코드였던 것이다.

유니코드는 첫 도입 배경이 저렇다 보니 “유니코드 = all 2바이트 단일 문자 체계 = wide character 문자 체계”라고 혼동하는 사람이 적지 않다. 그러나 이는 개념적으로 올바른 관계가 아니다. 2바이트 문자 체계로만 치자면 한컴 2바이트 코드도 이에 해당하며, 윈도 이외에 유닉스 계열 OS에서는 wide character는 16비트가 아니라 32비트인 경우도 있다. 왜 32비트이냐 하면 6만 5천여 개라는 집합 크기도 시간이 흐르다 보니 부족해졌기 때문이다.

1996년에 유니코드 2.0이 제정되면서 유니코드는 오늘날 우리가 아는 유니코드와 같은 뼈대가 갖춰졌다. 한번 등록한 문자는 이제부터 재배치나 제거 없이 영구불변으로 굳히기로 했으며, 이때 현대 한글 글자마디 11172자가 순서대로 고스란히 등록되었다. 2바이트 조합형처럼 비트 연산은 못 쓰지만 그래도 테이블 없이 뺄셈과 나눗셈, 나머지 연산으로 한글의 자소 정보를 얻을 수 있으니, 과거 조합형 한글 코드의 장점을 유니코드에서도 물려받은 셈이다.

외국 위원들의 반대를 무릅쓰고 한글에다 유니코드의 금싸라기 영역을 이만치 할당 받기 위해 한국 위원회 사람들이 애를 많이 썼다. 사실 확장완성형도 유니코드 등록 근거를 대기 위해 급히 만들어진 것이라고 한다.
이와 더불어 유니코드 2.0에서는 중요한 개념 내지 꼼수가 추가로 도입되었는데, 바로 surrogate이다.
16비트 공간 중 일부 영역은 그대로 쓰지 말고 따로 떼어 내서 두 글자를 뭉쳐서 더 많은 종류의 글자를 표현하는 데 쓰자는 것이다.

0xD800부터 0xDBFF는 high surrogat이고, 0xDC00부터 0xDFFF까지는 low surrogate이다. high는 언제나 앞에, low는 언제나 뒤에 오는 식으로 역할이 딱 고정되어 있다. 1024개의 앞짝과 1024개의 뒷짝이 만나니, 총 2048개의 독립 글자를 희생하여 2의 20승, 약 100만여 개의 글자 공간을 추가로 확보할 수 있게 된다. 요컨대 유니코드에 U+D800 같은 글자는 없고, U+D7FF 다음에는 곧바로 U+E000이 이어진다. 그 대신 0xD800과 0xDC00이 만나면 U+10000이라는 surrogate, 즉 확장 평면이 시작될 뿐이다. 예전의 16비트 단일 영역은 '기본 다국어 평면'(BMP)이라고 불리게 되었다.

비록 과거의 1바이트/2바이트 혼합 체계보다는 사정이 훨씬 낫고 문자열 처리가 수월한 건 사실이지만, 어쨌든 유니코드도 확장으로 인해 2바이트 단일 표현(UCS2)이라는 깔끔한 장점은 포기해야 하게 되었다. 이쯤 되니 유니코드라는 개념에서 문자 코드와 인코딩을 구분해서 표현해야 할 필요가 생겼다.

유니코드 자체는 UCS, 즉 universal character set이라 불리는 단일 문자 집합이다. 얘는 '가'라는 한글 글자에다가 U+AC00이라는 코드값을 부여해 줄 뿐, 그 코드값이 메모리나 파일에 어떻게 표현되는지에 대해서는 규정하지 않는다. 이를 표현하는 방식이 바로 Unicode transfer format, 즉 인코딩이 된다.

모든 유니코드 번호를 아무 뒤끝 없이 32비트 정수 하나로 균일하게 표현하면 그것은 UTF32이다. 아까 wide character가 4바이트인 플랫폼은 바로 UTF32를 구현하는 자료형인 것이다. 가장 깔끔하고 공간도 넉넉하고 모든 글자를 하나씩 쉽게 접근할 수 있지만 한 글자가 4바이트나 차지하여 메모리 낭비가 심하다.

BMP 영역에 있는 놈은 종전대로 16비트 정수 하나로 표현하고 확장 평면에 있는 놈만 surrogate 두 개로 쪼개서 표현하는 방식은 UTF16이라고 불린다. UCS2를 개념적으로 확장한 것이기 때문에 처음부터 2바이트 wide character를 표방하며 개발된 Windows 플랫폼이 매우 사랑하는 방식이다. 비록 Windows의 wchar_t는 이제 유니코드 코드 포인트 하나를 온전히 표현할 수 있을 정도로 충분히 크지 못한데도 말이다.

끝으로, 그 이름도 유명한 UTF8이 있다. 얘는 U+007F 안에 드는 전통적인 알파벳· 숫자, 제어 문자들은 1바이트로 유지하고, 나머지 BMP 영역의 외국어들은 2~3바이트로 표현하고 surrogate는 BMP와 동일한 4바이트로 늘여 표현하는 진정한 multibyte 인코딩이다.

n째 문자를 찾는 무작위 접근은 안 되겠지만, Windows NT처럼 커널을 처음부터 16비트 문자 단위로 설계하지 않고도 기존 8비트 문자 시스템에서 유니코드를 단절감 없이 표현할 수 있다는 엄청난 장점이 있다. CPU의 엔디언(비트 배열 순서)의 영향을 받지 않으며, tail byte가 기존 영문· 숫자와 충돌을 일으키지도 않는다는 점도 좋고 말이다.
그래서 얘는 웹에서 매우 사랑받고 있고 윈도 이외의 플랫폼에서는 파일뿐만 아니라 메모리 저장용으로도 UTF8이 즐겨 쓰인다. 사실 윈도만 이례적으로 UTF16을 너무 사랑하고 있는 것이고.. ㅎㅎ

여담이지만 UTF32, 16, 8 중 유니코드의 문자 집합이 먼 미래에 또 확장되어야 할 때, 공간이 가장 넉넉하게 남아 있는 놈은 두 말할 나위 없이 UTF32이다. UTF8이야 애초부터 들쭉날쭉 가변 길이 인코딩을 표방했기 때문에 한 글자당 4바이트보다 더 긴 5~6바이트까지 약간 더 확장할 여지가 있다. 지금 당장은 그것까지는 쓰이지 않지만 말이다.

하지만 UTF16은 유일하게 확장의 여지가 전혀 없다. 지금 surrogate 영역이 다 차 버리면 surrogate의 surrogate라도 또 만들지 않는 이상 답이 없다. 그리고 그런 헛짓을 할 바에야 차라리 UTF16을 폐기하고 UTF8 아니면 UTF32로 갈아타는 게 낫지..;; 이런 미묘한 면모가 있다.

다만, 한글 표현의 관점에서는 메모리가 가장 적게 드는 인코딩이 UTF16이라는 것도 감안할 점이다. 현대 한글 글자마디의 경우 UTF8은 3바이트, UTF32는 4바이트이지만 UTF16은 2바이트다. 초-중-종성이 모두 갖춰진 옛한글이라면 UTF8과 UTF32는 각각 9바이트, 12바이트를 차지하지만 UTF16은 6바이트이니 차이가 더 벌어지게 된다. 유니코드에는 한글이 완성형(글자마디+호환용 자모) 방식과 조합형(세벌 한글 자모) 방식이 모두 등록되었으며 완성형 방식도 11172자가 순서대로 모두 등록되었으니, 예전의 조합형· 완성형 논쟁을 완전히 종결짓는 데 성공했다.

Windows NT도 처음에 개발될 때 문자 처리 단위를 wide로 무리해서 넓히느라 고생하지 말고, 그냥 UTF8만 도입했으면 어땠을까 싶지만 이제 와서는 다 지난 일이다. 아무래도 UTF8보다야 UTF16이 컴퓨터의 입장에서는 더 빠르고 간편하게 각각의 문자를 인식할 수 있으며, 이것이 메모리와 성능 소모면에서 UTF32와 UTF8 사이의 완충지대 역할을 해 온 건 부인할 수 없기 때문이다. 덕분에 Windows API의 관점에서는 UTF8조차도 native 인코딩인 유니코드 UTF16으로부터 '변환'되어야 하는 여러 multibyte 인코딩 중의 하나일 뿐이다~! ㅎㅎ

옛날에 인터넷 익스플로러의 버전이 5~6이던 시절엔 한글로 된 URL이 인식이 잘 안 돼서 맨날 “URL을 UTF8로 보냄” 옵션을 끄라는 지시가 팁처럼 공유되곤 했다. 당시엔 Unicode-aware하지 않은 웹 서버가 아직 많아서 말이다. 오늘날로 치면 UAC(사용자 계정 컨트롤)를 끄거나 팝업 창 허용 기능을 사용하는 것과 비슷한 편법이다.
하지만 요즘은 UTF8 방식 URL이 표준으로 정착한 지 오래다. 호환성을 중요시하는 IE에나 그런 옵션이 있지, 크롬 같은 브라우저는 선택의 여지 없이 무조건 UTF8이기도 하고 말이다.

유니코드는 문자 처리 기술의 발전과 함께 더욱 덩치가 커졌으며, 한편으로 더욱 복잡해지고 지저분해지고 있다.
UTF32가 아닌 인코딩으로는 어차피 메모리 배열 인덱스만으로 실제 글자 인덱스를 얻을 수 없는 것은 물론이거니와, 메모리 상으로 존재하는 글자 코드 포인트 수와, 화면에 출력되는 글자의 수도 일대일 대응이 전혀 이뤄지지 않게 되었다. 옛한글이라는 것도 유니코드 관련 기술이 방대해지면서 덤으로 같이 처리 가능해졌을 뿐이다. 진짜 미치도록 복잡한 문자에 비하면 옛한글 쯤이야 양반이지... 동일한 글자를 나타내는 방법이 여러 가지 존재하게 되어서 정규화라는 것도 필요해졌다.

코드 포인트 값만으로 정렬을 하는 것 역시 상당수 의미를 잃었다. 옛한글 자모는 유니코드 5.2 때 한양 PUA 비표준에만 존재하던 것들이 추가 등록되었는데, 이것들의 코드 포인트상의 순서를 따지는 건 부질없는 짓이다. 가뜩이나 부족한 BMP 공간의 여러 틈새에 산발적으로 간신히 등록된 것 자체를 감지덕지해야 할 판이다.

한자는 더욱 가관이다. 유니코드에서 공간을 압도적으로 제일 많이 차지하고 있는 문자인 건 두 말할 나위도 없거니와.. BMP 영역에 이미 등록돼 있고 호환용 같은 이유도 없는데 작업자의 실수로 인해 나중에 surrogate 확장 평면에 중복 등록된 글자도 있고, 일본 문자 코드의 실수 때문에 문헌에 전혀 등장한 적이 없는 유령 한자가 등재돼 있기도 하다.

이것이 오늘날의 컴퓨터 문명을 지배하고 있는 가장 원초적인 규범에 속하는 유니코드의 현실이다. ㅎㅎ
수십 년 주기로 유니코드를 전면 reset하고 코드값을 재정리하면 어떨까 싶지만 그건 기존 컴퓨터 문명이 핵 전쟁 같은 걸로 폭삭 없어지지 않는 한, 상상 속에서나 가능한 일일 것이다.

Posted by 사무엘

2013/12/16 08:25 2013/12/16 08:25
, , , , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/909

디지털 컴퓨터는 전자 신호로 0과 1만을 인식할 수 있다. 그렇기 때문에 컴퓨터에서는 문자 역시 0과 1의 조합인 숫자로 표현되며, 문자를 그런 숫자에다가 대응시키는 규칙이 바로 문자 코드이다. 정보 교환을 원활히 하기 위해서는 보내는 쪽과 받는 쪽이 모두 문자 코드가 통일돼 있어야 함은 두 말할 나위가 없다.

정보량의 최소 단위는 1비트이지만 현실적으로 컴퓨터의 기억 장치들이 한 글자로 취급하는 정보량의 최소 단위는 8비트, 즉 바이트이다. 8비트, 2^8승, 즉 256이라는 정보량은 숫자와 알파벳을 정하는 데는 충분하고 상위 1비트를 잉여화하여 오류 검출용으로까지 사용할 수 있을 정도이지만, 한글이나 한자 같은 문자를 담는 데는 턱없이 부족하다.

한자는 글자를 체계적으로 부분글자로 분해할 뾰족할 방도가 없는 상태로 글자 수가 너무 많다. 한글은 글자 생성 체계는 한자보다 훨씬 더 유리한 위치에 있지만, 실용적으로 편하게 다루려면 여전히 1만여 개의 미리 조합된 음절 형태를 그대로 배당해야 한다.

예를 들어 현실에서 '학교'라는 단어는 두 글자로 간주되지, 데이터베이스나 문서 분량 같은 데서 5글자라고 계수되는 곳은 아무도 없다. 코드 차지 영역을 줄이자니 메모리 사용량이 늘며, 그리고 오늘날로 치면 화면에 보이는 글자 길이와 메모리를 차지하는 글자 길이가 서로 완전히 따로 노는 complex script 급의 복잡한 기술이 필요해진다.

결국 한글과 한자는 1바이트만으로 표현할 수 없고 통상 2바이트로 표현된다. 그런데 기존 1바이트 영문· 숫자를 건드릴 수는 없으니 1바이트와 2바이트 문자가 공존하는 multi-byte 코드 체계가 만들어진다. 영문권에서 패리티 비트 내지 유럽 특수문자를 표현하는 데 쓰이는 최상위 1비트는, 이 문자가 1바이트로 끝인지 아니면 2바이트 문자의 첫 바이트(lead byte)인지를 판별하는 비트로 쓰인다.
공교롭게도 한글· 한자는 폭도 균일한 2글자 분량을 차지하여 비주얼 상 잘 어울린다. 전각· 반각이라는 개념이 여기서 유래된다.

그런데 lead byte는 그렇다 쳐도 2바이트의 다음 둘째 바이트인 tail byte도 기존 순수 1바이트 문자들과(영문· 숫자 같은) 전혀 겹치지 않게 할 것인지? 아니면 어차피 얘는 lead byte에 의해 변별이 됐으니 좀 문맥 의존적으로 겹치는 걸 허용할 것인지가 문제가 된다. 한글 코드의 경우 완성형은 겹치지 않으나 조합형은 겹친다.

그렇기 때문에 조합형은 tail byte가 대문자 알파벳과 소뭇자 알파벳이 제각기 따로 될 수 있고 심지어 \ 역슬래시 문자가 나올 수도 있다. 이런 이유로 인해 조합형은 1비트 + 초중성 5비트씩 한글의 구성 원리를 매우 잘 반영하여 설계된 문자 코드임에도 불구하고 당시 8.3 제약이 있던 시절에 파일 이름을 사실상 한글로 지정할 수 없었으며, 심지어 이론적으로는 // 주석을 조합형 한글로 지정한 경우 \ 때문에 2-byte aware 하지 않은 컴파일러에서는 충돌이 발생할 수도 있었다.

옛날에 한글 MS-DOS 시절에 한글 도스 셸이나 QBasic처럼 텍스트 GUI(?)를 구현한 프로그램들을 실행해 보면 한국 마소가 굉장히 잘 만든 게 있었다. 메뉴나 대화상자 같은 게 표시되어서 배경에 있던 2바이트 텍스트를 반토막 내더라도 깨진 문자열을 보여주는 법이 결코 없었다. 늘 짝수 바이트가 유지돼야 하는 한글/한자 영역이 홀수 바이트로 줄어들면 가장자리를 하나 삭제해 주면 된다.

그러나 문맥 의존적인 문자 코드로 그런 걸 구현하려면 문자열을 처음부터 읽어 봐야 하고, 두 바이트 중 하나가 소실됐을 때의 뒷처리가 문맥 독립 코드보다 더 어려우면 어렵지 쉽지는 않을 것이다. 불가능하다는 뜻은 아니지만.

조합형을 옹호하고 완성형을 까기에만 바쁜 분들의 심정이야 세벌식+한글 에반젤리스트로서 본인은 적극 이해한다. 그러나 과거의 2바이트 한글 코드의 이면엔 이런 면모도 있었음을 지적하고자 한다. 완성형은 여러 이슈가 얽혀서 그렇게 만들어졌지, 작정하고 한글을 난도질하려는 악의적인 의도로 만들어진 건 아니었다. 문맥 독립성뿐만 아니라 굉장히 보수적인 국제 규격 권장 사항을 만족하는 방식으로 문자 코드를 만들려다 보니, 한글 11172자에다 한자와 각종 특수문자들까지 넣을 절대적인 공간 자체가 부족했기 때문이다.

나중에 완성형에다 어거지로 한글 부족분을 채워 넣은 cp949 확장완성형은 어차피 조합형처럼 문맥 독립성이 깨졌다. 물론, 어차피 이렇게 만들 거면 처음부터 조합형으로 가지 하는 비판은 피할 수 없게 된 게 사실이다. 그런데, 이런 비슷한 삽질을 일본도 문자 코드를 만들면서 했으며, 이를 우리나라도 그대로 답습했을 뿐이다.

조합형과 완성형은 11172자와 2350자의 차이뿐만 아니라 한글 낱자를 표현하는 방식에서 매우 큰 차이가 있다.
조합형은 글자마디와 자모의 차이가 사실상 없다. 그냥 초 중 종성 중 한 성분만 있으면 자모이고, 초성과 중성이 갖춰졌으면 글자마디이다. 초성 ㄱ과 종성 ㄱ을 구분해서 표현할 수 있고 초성+종성이나 중성+종성 같은 '미완성 한글'도 얼마든지 표현할 수 있다.

그러나 완성형엔 그런 개념이 없다. 한글 입력을 처음 시작했을 때 쓰라고 '호환용 한글 자모'라는 게 있는데 그건 한글이 아니라 명목상으로는 '특수문자' 영역이다. 그냥 한글 자모 모양인 그림일 뿐이다. 초성+종성 구분이나 미완성 한글 표현 같은 건 없다.

메모리 1바이트가 아깝던 16비트 도스 시절에 국내에서는 조합형 한글 코드+글꼴이 쓰였지 마소의 윈도처럼 2350자 완성형 코드+글꼴로 돈지랄을 하는 프로그램은 전혀 없었다. 이런 압도적인 인지도의 차이로 인해 조합형은 1992년에 한국의 복수 표준으로 승격되어서 cp1361이라는 이름으로 나름 운영체제의 코드 페이지에 등록도 됐다.

자, 이렇게 컴퓨터는 1바이트 인코딩에다가 한중일 문화권을 위한 1+2바이트 멀티바이트 인코딩 구도가 유지되었고 마소에서는 이를 도스 시절부터 코드 페이지라고 불렀다. 그런데 이런 문자 코드들은 (1) 알파벳· 숫자 같은 공통 문자를 제외하면 같은 문자라 해도 국가마다 배당된 코드값이 같을 수가 없고, (2) 문자 집합 자체의 크기가 너무 작아서 세계 모든 문자들을 한 코드 페이지에다 담을 수 없다는 문제가 있었다.

人(사람 인)이라는 한자가 한국· 중국· 일본의 표준 코드에서의 코드값이 같을 리가 없으니 (1)은 자명한 문제다. (2)의 경우, 2바이트 코드라 해도 앞서 보았듯이 1바이트 문자와의 충돌을 피하기 위해 매우 제한된 영역의 바이트들만 묶을 수 있다. 이 때문에, 문맥 의존까지 시킨다 해도 추가로 만들 수 있는 문자는 1만여 자에 불과하다. CJK에서 쓰는 상용 한자들이나 간신히 다 집어넣을 정도이다.

그래서 1980년대 말부터 이런 발상의 전환이 이뤄졌다. “앞으로 컴퓨터의 메모리는 증가하고 소프트웨어 국제화의 중요성은 커질 테니, 글자 하나의 크기를 16비트로 쿨하게 확장하고 6만여 자의 공간에다가 전세계 언어 문자들을 집어넣고 동일 문자 동일 코드값을 실현하는 게 어떨까?”

이것이 바로 유니코드의 존재 목적 되시겠다. 컴공 전공자가 아니더라도 컴퓨터에서 '유니코드'라는 말은 한 번쯤은 다들 들어 보셨을 것이다. 이건 그야말로 컴퓨터 문자 코드계의 바벨 탑 내지 에스페란토 같은 물건이다.

마이크로소프트는 소프트웨어의 국제화에 굉장한 혜안이 있던 기업이었다. 그래서 OS/2와 결별하고 Windows NT를 첫 개발할 때, 애초부터 8비트 문자가 아니라 유니코드를 담을 수 있는 16비트 문자를 기반으로 설계했다. 심지어는 NTFS 파일 시스템까지도. 그리고는 이를 독자적으로 wide character이라고 부르기 시작했다. 어차피 8비트 문자만으로 충분하던 라틴 문화권에서는 별로 득이 되는 것도 없이 메모리 사용량만 두 배로 뻥튀기되는 대가를 감수하고라도 말이다.

Win32 API는 기존 16비트 윈도 API를 최대한 닮게 설계되었지만, 문자열을 다루는 모든 API에 A 버전과 W 버전 구분이 생겼다. 다만, 32비트 시절에 처음으로 도입된 OLE/COM 같은 기술은 처음부터 오로지 유니코드(= wide) 문자열만 취급하게 만들어졌다.

PE 방식으로 만들어진 32비트 EXE/DLL은 string 테이블, 메뉴, 대화상자 같은 리소스의 저장 포맷도 다 유니코드 방식으로 바뀌었다. 윈도 3.1에다가 Win32s를 설치하면 32비트 커널 DLL뿐만 아니라 각종 코드 페이지 변환 테이블도 설치되는 걸 볼 수 있다. 그게 바로 리소스를 변환하기 위해서이다.

윈도 NT가 3.x나 9x보다 메모리 사용량이 매우 많았던 이유 중 하나도 유니코드 때문이며, 반대로 윈도 9x가 유니코드 API를 지원하지 않았던 이유도 가정용 PC의 부족한 메모리 문제 때문이다.
이 때문에 컴파일 스위치만 바꿔서 유니코드와 기존 멀티바이트를 모두 커버할 수 있는 TCHAR, _T 같은 개념도 그때 생겼다. 두 개의 문자 포맷을 모두 지원하는 작업은 정말 엄청난 대공사였을 것 같다.

Posted by 사무엘

2013/12/13 08:24 2013/12/13 08:24
, , , , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/908

본인은 중학생이던 1996년 말, 친구 집의 컴퓨터를 통해 우연히 툼 레이더라는 게임을 접했을 때의 충격을 난 지금도 잊을 수 없다.
페르시아의 왕자 같은 파쿠르 액션이 full 3D로 구현되어 나오고 게다가 주인공이 듀크 뉴켐스러운 마초 근육맨이 아닌 아리따운 아가씨라니!
툼 레이더 시리즈는 전세계적인 히트를 쳤으며 게임 주인공인 라라 크로프트는 역사상 가장 성공한 사이버 모델이 되었다.
이번 글에서는 롤스로이스에 이어 또 '영국'이 만들어 낸(냈던) 명작에 대한 리뷰를 좀 써 보겠다.

본인은 예전에도 몇 차례 글을 썼듯이, 비디오 게임의 역사 중에서 3차원 그래픽 기술이 막 도입되던 1990년대 중· 후반의 과도기가 가장 흥미진진한 시절이었다고 생각한다.
id 소프트웨어의 엔진이 울펜슈타인, 둠, 퀘이크를 거치면서 발전해 가던 시절,
2.5D와 완전한 3D 사이의 과도기이던 켄 실버맨의 빌드 엔진을 쓴 게임(듀크 뉴켐, 섀도우 워리어),
목각인형에서 진짜 사람으로 발전하던 버추어 파이터 시리즈,
실사 사진을 쓰다가 최초로 3D 폴리곤으로 바뀐 모탈 컴뱃 4 등등 말이다.

그런 맥락에서 툼 레이더도 예외가 아닌 것이다.
안 그래도 엔하위키나 한국어 위키백과는 각 시리즈 별 설명이 부실한 편이기도 하니 한번쯤 이런 내력을 나열해 보는 것도 흥미롭지 싶다.

사용자 삽입 이미지

※ 1

그야말로 전설이 아닌 레전드를 창조한 첫 작품이며, PC 플랫폼은 처음이자 마지막으로 도스를 지원했다. 눈이 종종 쌓여 있는 숲, 광활한 고대 유적지, 피라미드 등을 돌아다니면서 말 그대로 묘지를 터는 본분에 충실한 형태였다. 몹 중에 인간은 흔치 않았던 걸로 기억하며, 혼자서 퍼즐을 풀어 나가는 비중이 컸다.
1부터 3까지는 같은 엔진 기반으로, 그래픽이나 게임 진행이 그렇게 큰 차이가 없다.

※ 2 (starring Lara Croft)

1이 대성공을 거둔 뒤, 2부터는 도스 대신 Windows용으로 나오기 시작했다. 2는 1에 비해 폴리곤 수가 늘어서 라라가 아주 약간 더 예뻐졌으며, 기술적으로 무리였던 팔랑거리는 말총머리가 드디어 구현되었다.
그리고 동적 광원을 구현하면서 flare(섬광탄) 아이템이 첨가되었다. 그리고 물에는 언제나 수영만 있던 것과 달리 얕은 물에서 걷는 wading이 추가되었으며, 암반을 오르는 climbing이 추가되었다.

2는 첫 시작을 만리장성에서 하고, 결말부에서 최종 보스도 용일 정도로 배경에 중국에 대한 비중이 가장 높다. 1보다 대인 전투의 비중이 높아졌으며 무덤 말고 도시, 선박 등 인간이 만든 시설도 많이 등장한다. 무기는 샷건뿐만 아니라 M16 소총, 작살총도 추가되었다.
보트나 스노우모빌 같은 탈것을 이용하는 동작도 처음으로 추가되었다. 생각해 보면, 주인공이 탈것을 이용할 수 있는 아케이드 게임은 매우 드물다. 용 정도나 타는 옛날 황금도끼 말고 딴 게 뭐 있었던가??

※ 3 (라라 크로프트의 모험)

3은 2와 같은 맥락으로 더 큰 변화가 이뤄졌다. 그래서 단순한 유적지 털기라는 타이틀이 무색할 정도로 전세계 방방곡곡을 배경으로 한 액션 어드벤처로 바뀌었다. 덕분에 게임 배경이 역대 툼 레이더 시리즈 중 가장 넓어서 인도, 남태평양 섬, 남극, 미국 AREA 51, 런던 자택 근처가 레벨로 모두 등장한다. 그리고 각 레벨별로 라라의 복장도 가장 다양해졌다. 지역별로 레벨 플레이 순서를 사용자가 임의로 선택할 수 있는 시스템도 3이 역사상 전무후무하게 갖추고 있었다.

기술적으로 보자면 라라에게는 그냥 달리는 게 아니라 기력을 소비하면서 잠시 동안 전력질주를 하는 sprinting이 추가되었으며 엎드리기(crouching), 천장을 잡고 건너기 같은 동작이 추가되었다. 그래픽이 개선된 건 총기 격발 후에 발생하는 탄피와 연기 흔적, 그리고 물에서 나타나는 특수효과가 일부 개선된 정도다. 슬슬 엔진의 약발이 다할 때가 되고 있었고, 라라 팬으로부터 불만도 들어오고 있었다. 3이 이룬 것은 같은 시스템 하에서 단순 양적 팽창 위주일 뿐이었으니 말이다. 그래서 다음 편부터는 시대에 맞추어 엔진이 교체되었다.

※ 4 (마지막 계시)

프로그램이 처음부터 싹 다시 개발되었다. 시작 화면, GUI 글꼴 같은 게 전부 바뀌었다. 여권 수첩 형태의 메뉴나 동그란 고리 형태로 나오던 인벤토리 링도 다 없어졌다.
4는 오로지 이집트 주변만 공략하여 순수하게 유적지 털기 미션으로 되돌아갔으며, 라라의 의상도 시종일관 기본 단일 복장으로 바뀌었다. 그렇잖아도 툼 레이더 4가 나온 1999년은 <미라>(Mummy)라는 영화가 인기를 끌었던 해이기도 해서 더욱 이집트스러운 기억이 깊게 남아 있다.

4는 엔진이 교체되면서 그래픽이 예전보다 대대적으로 향상되었다. 드디어 모든 텍스처에는 하이컬러 안티앨리어싱이 적용되기 시작했고 라라의 외형도 더욱 매끄럽고 예뻐졌다. 복잡한 지형에서 발생하던 1~3 엔진 특유의 그래픽 glitch가 거의 다 사라졌다. 3에서 바뀌었는지 4에서 바뀌었는지 모르겠지만 어쨌든 아이템이 여전히 2D 스프라이트로 표현되던 것들도 드디어 순수 폴리곤으로 바뀌었다.

4에서는 예전 시리즈에서 전통적으로 등장하던 라라 저택 연습 미션이 없어졌고, 그 대신 게임 전반부에서 라라가 어렸을 때의 모습이 잠깐 나온다. 그리고 줄을 타고 오르는 동작이 추가되었으며 여러 아이템을 조립해서 새로운 아이템을 만드는 시스템이 도입됐다. 또한, 4는 역대 툼 레이더 시리즈 중 레벨 수가 가장 많고 플레이 시간이 가장 길었다고 한다. 그 중 열차 안에서 미션을 수행하는 사막 열차 레벨은 상당히 참신한 디자인.
이 게임의 엔딩은 라라가 죽는 걸(최소한 그걸 암시하는)로 끝난다. 왜 그 잘 나가는 캐릭터를 죽이는지, 시리즈를 벌써 종결지으려는 건지 제작사의 의도를 알 수 없는 대목이다.

※ 5 (크로니클 연대기)

1부터 5까지는 각각 1996년부터 2000년까지 1년 간격으로 그 해의 하반기에 제품이 출시되었다. 5편인 크로니클은 4편과 거의 같은 엔진 기반에 컨텐츠만 다르다. 라라 크로프트는 죽고 없는데 그녀가 살아 생전에 남긴 무용담을 회상하며 플레이한다는 설정. 그래서 3편만큼이나 다양한 복장으로 과거 유물과 현대 도시를 아우르면서 다양한 미션을 수행한다.

5는 이상한 설정으로 인해 예전 시리즈만 한 대박은 못 친 걸로 본인은 기억한다. 다만, 이때 제작사가 무슨 생각이 있었는지 상당히 대인배적인 조치를 취했는데, 바로 레벨 에디터를 게임과 더불어 공식 배포했다. 스타크래프트로 치면 걸출한 캠페인 에디터인 StarEdit인 셈.

덕분에 툼 레이더 4~5 엔진은 내가 알기로 역대 툼 레이더 시리즈들 중 단순 의상 패치 이상으로 full-featured custom 레벨 MOD가 존재하는 최후의 엔진이다. 그래서 인터넷엔 라라 크로프트 하앍하앍 하는 전세계의 양덕후들이 만들어 올린 custom 레벨 파일 및 플레이 동영상들이 즐비하다.
1~3 엔진은 에디터가 있다 하더라도 요즘 기준으론 그래픽이 너무 심하게 후져서 별로. 4~5 엔진 정도는 돼야 그나마 할 만하다.

※ 6 (어둠의 천사 AOD)

툼 레이더의 제작사인 코어 디자인은 라라 크로프트라는 희대의 대박 아이템이자 황금알 낳는 거위를 창조해 놓고는 영업이랄까 운영을 썩 잘했다고 볼 수는 없었다. 3에서 4로 넘어갈 때 좀 혁신을 한 걸 제외하면, 계속 같은 엔진과 게임 시스템만 지겹게 우려먹는 걸 좋아하는 편이었다. 그리고 배가 산으로 가는 듯한 스토리를 전개하며 4편에서 라라 크로프트를 덥석 죽여 버린 건 팬들의 원성을 사기에 충분했다.

그런 와중에 거의 3년간의 침묵을 깨고 툼 레이더의 다음 시리즈인 어둠의 천사가 나왔다. 시기가 시기인 만큼 기술은 분명 크게 발전했다. 물리 엔진이 도입되었고 라라의 손발 모션은 지형을 반영하여 더욱 자연스럽게 나오기 시작했다. 그래픽 디테일 레벨을 올리면, 그림자도 그냥 바닥에 시꺼먼 타원으로만 나오는 게 아니라 실제 광원과 라라의 체형대로 나오기 시작했다.

다만, 이 작품에서 라라 크로프트는 과거에 죽었다가 아무 개연성 없이 불쑥 살아서 돌아왔으며, 고대 유적지를 돌아다니는 묘지 도굴꾼 컨셉에서도 더욱 멀어졌다. 전통적인 복장 대신 군복과 청바지 차림으로 의상이 완전히 바뀌었다.
6은 기술의 진보는 분명 있었으며 국내에서는 툼 레이더 시리즈 중 최초로 완전 한글화가 되기도 했다. 하지만 저런 괴상한 정체성과 많은 버그들 때문에 완성도가 떨어지고 뭔가 핀트가 안 맞는 작품으로 전락했으며, 큰 성공을 거두지 못했다.

※ 7 (레전드)

툼 레이더의 본디 제작사이던 코어 디자인은 6 이후로 제작사 타이틀을 반납하고 그저 그런 게임 개발사로 남아 있다가 2007년쯤에 망했다. 그 뒤 툼 레이더의 개발은 영국이 아닌 미국의 크리스탈 다이나믹스로 넘어갔는데 얘가 툼 레이더 시리즈를 다시 물건으로 회복시켜 놓았다.

2006년 봄에 출시된 레전드는 툼 레이더의 '제2기' 시대를 열었다. 툼 레이더의 기본 복장이 되돌아왔으며 유적지 탐험 패턴도 복귀했다. 그러는 한편으로 조작도 다 뭔가 현대적인 감각으로 바뀌었다. 언제나 자동 세이브가 되고 굳이 별도의 키를 누르지 않아도 절벽에서는 자동으로 매달리는 등, 퍼즐 난이도는 예전보다 더 쉬워졌는데 이건 요즘 게임기용 게임들의 추세가 다 그런 게 아닌가 싶다.

레전드에 대한 반응은 전반적으로 좋았다. 하지만 예전하고는 너무 이질적으로 바뀐 게임 시스템에 대해서는 게이머들 사이에 호불호가 갈리기도 했다. 맨날 동료하고 얘기를 주고받는 것도 예전에는 없던 관행이었으니까.
아무튼, 이렇게 레전드로 희망찬 데뷔 선언을 한 크리스탈 다이나믹스는 그 이듬해에 Anniversary라고 불리는 시리즈도 내놓았다. 이것은 툼 레이더 1을 오늘날 스타일로 리메이크한 작품이다.

※ 8 (언더월드)

레전드의 명성을 계승한 후속 시리즈이다. 라라 크로프트가 배를 타고 세계 각지를 이동하면서 미션을 수행한다. 덕분에 레전드에 비해 잠수와 수영의 비중이 더 높다. 고전 복장은 사라졌으며, 그나마 이것과 가장 비슷한 복장은 태국 숲 미션에서 입는 까만 셔츠와 핫팬츠 복장이다.

라라 크로프트의 집이 난장판이 되는 건 옛날에 2의 맨 마지막 레벨 Home Sweet Home에서 침략자들과 총격전을 벌이는 게 전부였는데... 이번 언더월드에서는 첫 미션에서 집이 불바다가 되는 걸로 시작한다. 그래서 집에서 겨우 빠져나왔는데.. 이번엔 레전드 시절의 동료가 라라에게 무슨 원한이 생겼는지 권총을 쏴 댄다. 도대체 어찌 된 일일까? 다행히 원한을 살 만한 짓은 라라가 아니라 라라의 도플갱어의 소행으로 밝혀져 오해는 나중에 풀리지만... 스토리 전개가 재미있다.

도플갱어라.. 옛날에 1편에서 베이컨 라라가 있긴 했고.. 더 옛날 고전 게임 중엔 페르시아의 왕자 1에서도 왕자를 골탕먹이다가 나중에 합체하는 영혼 도플갱어가 있었다. 정말 별의 별 걸 게임에다 다 집어넣었다.

※ 9

자... 1996년 이래로 근 15년간 라라 크로프트를 쌍권총 찬 고고학자로 우려먹어 온 건 약발이 다한 모양이다.
크리스탈 다이나믹스는 5년간의 잠수 끝에, 이제 예전의 스토리를 다 뒤집어엎은 리부트작을 내놓았다. 이 작품은 1편과 마찬가지로 부제가 없이 이름이 그냥 툼 레이더이다.

라라는 더욱 어려졌으며, 도도한 특수요원 같은 이미지가 아니라 이제 막 생존술을 터득해야 하는 연약한 여고생/여대생 컨셉으로 바뀌었다. 어린 라라 떡밥은 지난 4편에서 잠시 등장한 적이 있지만 그걸 떠올려서도 물론 곤란하겠다. 예전의 라라가 인디아나 존스 컨셉이었다면, 지금의 라라의 위상은 거의 생존왕 로빈슨 크루소나 심지어 베어 그릴스-_-를 생각해도 될 것 같다.

9의 설정상 배경은 일본 열도 인근에 있는 어느 섬이다.
사실, 툼 레이더 시리즈에서 일본이 등장하는 것 자체가 코어 디자인 시절에는 없었고 크리스탈 다이나믹 때 레전드와 9에서 딱 두 번이었다. 코어 시절에 툼 레이더의 배경은 오히려 중국, 네팔, 티베트 같은 대륙이 더 자주 등장했었다.
중국과 일본 사이에 끼어서 한국은 영토가 너무 작기도 하고 게임이나 영화 같은 매체에 선뜻 등장하기에는 정치적 민감성도 크고 역시나 콩라인이라는 생각이 들었다.

그래픽이야 뭐, 피부에 핏자국이 묻고 각각의 머리카락들이 찰랑거리는 걸 볼 수 있을 정도로 사실에 가깝게 발전했다.
AOD에서 레전드로 넘어갈 때를 능가하는 엄청난 쇄신이 있었는데, 반응은 역시 좋은 편이다. 9 이후로 툼 레이더 시리즈가 과연 또 어떻게 변할지가 궁금해진다.

Posted by 사무엘

2013/12/07 08:32 2013/12/07 08:32
,
Response
No Trackback , 4 Comments
RSS :
http://moogi.new21.org/tc/rss/response/906

롤스로이스 이야기

롤스로이스(Rolls Royce)는 잘 알다시피 영국의 명차로, 세계 톱클래스급의 간지를 자랑하는 대형 초호화 고급 승용차이다. 우리나라에서는 삼성 그룹 회장님이 마이바흐와 더불어 개인용으로 굴리는 차 중 하나라고 알려져 있다.
그리고 웹툰에서는 <입시명문 사립 정글고>에서 정 안봉 이사장의 자가용이 저 차라고 설정되어 있다..;; (220화 참조)

사용자 삽입 이미지

앞의 엔진룸이 매우 두툼한데 비해 헤드라이트는 모양이 작다. 수 년 전 모델은 헤드라이트 아래에 있는 미등이 원형이었는데 지금은 그게 길쭉한 직사각형 모양으로 바뀐 듯하다.
참고로 지금으로부터 한 30년쯤 전에는 차 모양이 이랬었다. 그때나 지금이나 라디에이터 그릴은 파르테논 신전을 형상화한 형태라고 한다.

사용자 삽입 이미지

롤스로이스는 공장에서 마구 찍어내고 재고를 쌓아 놓는 양산이 아니라 주문 생산만 되었으며, 그 공정도 다 장인 수작업이었다고 한다. 더구나 지금 당장 돈만 있다고 해서 아무에게나 차를 덥석 팔아 주는 것도 아니었고 안정적인 소득과 지위, 평판이 있는 고객에게만 팔았다.
그도 그럴 것이, 명차를 구입만 덥석 해 놓은 뒤에 차주가 쫄딱 망해 버리면 차는 처분해야 하는 처지가 되기 때문이다. 롤스로이스 같은 차가 겨우 중고 매물로 나도는 건 롤스로이스 제조사의 입장에서는 체면상 용납할 수 없는 모습인 것이다.

그 대신 한번 고객에게 판매하여 넘겨 준 차는 폐차하는 순간까지 제조사에서 끝까지 책임을 졌다고 한다. 그래서 롤스로이스가 소재로 등장하는 이런 예화가 있을 정도이다.

롤스로이스가 사막 한가운데에서 갑자기 퍼져 버려서 차주가 무슨 보험사 긴급 출동도 아닌 차량 제조사에다 연락을 했다... 그랬더니 제조사에서는 곧바로 헬기를 띄워 다른 멀쩡한 롤스로이스를 공수해 줬는데, 나중에 그에 대한 비용을 청구하기는커녕 그런 일 자체가 없었다며 완전히 입 싹 씻고 함구했다. “롤스로이스는 애초에 고장이 나지 않는다”고 말이다(고장을 공식적으로 고장이라고 취급하지 않으며, 따라서 고장 수리비 같은 개념도 없다).

물론 오늘날은 롤스로이스가 그 정도까지 극단적으로 도도하지는 않다. 이런 극소수 엘리트 고급차는 양산차에 비해 수지가 안 맞기 때문에 생존을 위해서는 언제까지 그런 고집만 부릴 수는 없다.
마치 오늘날은 슈퍼컴도 저가 양산형 CPU를 병렬로 연결해서 쓰지, 슈퍼컴만의 전용 아키텍처 같은 개념은 없어진 것과 비슷한 맥락으로 볼 수 있겠다. 과거의 수제형 슈퍼컴인 크레이 시리즈가 맥이 끊어진 것을 생각해 보시라.

그래서 요즘은 돈만 내면 누구라도 롤스로이스를 사서 굴릴 수 있다. 그래서 국내에서도 예전보다야 이 차 구경하기가 쉬워졌다. 게다가 롤스로이스 역시 뒷좌석만 고급화시키는 게 아니라, 차주가 직접 앞좌석에서 운전을 하는 오너 드라이빙 트렌드를 더욱 반영하는 쪽으로 변모하고 있다.

비록 그 정도로 격이 낮아졌다(?) 해도 롤스로이스의 가격은 여전히 최하 수억 원대로, 서울 강남의 아파트 한 채 내지 에쿠스 네댓 대(5000cc 최상위 모델 기준으로!) 이상 값은 충분히 하는 비싼 가격이다. 게다가 구매한 후에도 어마어마하게 깨질 세금과 기름값, 보험료 따위는 어찌 감당하려고?

롤스로이스는 리무진 형태가 아니라 4명밖에 못 타는 세단 주제에 차의 길이가 5.6m에 달한다. 1톤 트럭 특장차보다는 확실히 더 길고, 2.5톤 트럭의 길이와 얼추 비슷하거나 약간 더 짧다. 그러니 일반적인 승용차 자리엔 주차도 제대로 못 할 정도로 크다. 그 대신 뒷좌석에 탄 사람은 앉은 채로 다리를 쫙 들어서 뻗어도 될 정도로 공간이 완전 넉넉하다. 좌석에 앉은 채로 다리를 다 뻗을 수 있는 교통수단은 새마을호 특실, 비행기 1등석 등 극히 드물다.

엔진으로 말할 것 같으면 롤스로이스는 예로부터 V형 12기통 엔진에 6000~7000cc에 달하는 배기량을 자랑한다. 3000cc대의 6기통 엔진만 달아도 대형 승용차인데 롤스로이스는 그 크기의 두 배라는 뜻이다. 차의 무게는 1톤대는 당연히 아니고 공차 중량만 약 2.5톤가량. 여러 통계를 보면 공인 연비는 1리터에 거의 5~6km대라고 한다. 마티즈를 보고 출력이 약하다고 탓해서는 안 되듯, 롤스로이스는 확실히 경제성을 보고 굴려서는 안 되는 차임이 분명하다.. ㅎㅎ

롤스로이스는 전통적으로 엔진의 정확한 출력 한계를 함구하고 외부에 공식적으로 알리지 않았던 것 같다. 옛날에 자동차생활 잡지에서 취재를 할 때도 회사 관계자는 “충분히 큽니다”라고만 얼버무렸지 정확한 숫자 얘기를 안 했었다. 일종의 신비주의 전략인 걸까?
그래도 지금은 롤스로이스에 대한 베일이 예전에 비해서는 많이 벗겨졌다. 제원을 검색해 보면 460마력대의 최대 출력과 70kg대의 최대 토크가 곧장 뜬다. 최대 성능이 나오는 rpm은 여느 가솔린 엔진 차량과 별 차이가 나지 않는다.

다만, 롤스로이스의 계기판에는 엔진 회전수를 표시하는 통상적인 타코미터는 지금까지도 존재하지 않는다. 단지, 지금이 엔진 최대 성능의 몇 %를 뽑아 쓰고 있는지 백분율만이 표시되며 이것이 타코미터의 역할을 대신한다고 그런다. Windows Vista부터는 작업 관리자에서 메모리 사용량을 바이트 단위가 아니라 백분율 단위로 보여주는데, 마치 그런 걸 보는 것 같다.

롤스로이스는 뒷좌석 문이 앞좌석과 같은 앞쪽으로 열리는 게 아니라 뒷쪽으로 열리는 게 특이하다. 그리고 타이어 휠의 중앙에 있는 휠캡은 바퀴와 연결되어 있지 않기 때문에, 차가 움직일 때도 데굴데굴 같이 따라 구르지 않고 그대로 있다고 한다. 차 문과 트렁크는 버튼 하나만 눌러서 전동 개폐가 되며, 뒷좌석엔 좌석별 개인 비디오 장비와 우산 거치대도 따로 있다.

사용자 삽입 이미지

명차, 고급차 소리를 들으려면 단순히 내장재만 호화로운 게 아니라 닥치고 승차감이 좋아야 할 것이다.
승차감에 관한 한 롤스로이스는 정말 본좌급이라고 한다. 탑승자는 엔진음을 도무지 들을 수 없으며 주행 중에도 워낙 진동이 없어서 차가 가고 있는지도 모를 정도라니 말 다 했다.

오죽했으면 롤스로이스는 정숙성을 내세우기 위해 내부 모델명을 다 유령과 관계 있는 이름으로 정해 왔다. 그래서 고스트, 레이쓰, 팬텀 따위. 팬텀은 <오페라의 유령>에 나오는 그 단어이며, 고스트와 레이쓰는 스타크래프트 테란 유닛 이름이다. 공교롭게도 둘 다 클록킹 스킬이 있는 유닛이라는 공통점도 있고 말이다. 이들 중 '팬텀'이 바로 가장 비싼 최상위 기함급 모델이다.

끝으로, 명차 고급차의 앞부분에 관례적으로 상징처럼 붙어 있는 마스코트(hood ornament)를 생각해 보자.
현대 차 중에는 제네시스에도 없고 오로지 에쿠스에만 그런 마스코트 비스무리한 액세서리가 붙어 있다.
롤스로이스는 '환희의 여신상'이라고 불리는 마스코트가 달려 있으며 내력도 굉장히 길다. 공식 명칭은 the spirit of ecstasy.
 

사용자 삽입 이미지

그런데 그 이름을 보니까 역시나 이런 생각이 들었다. 진정한 spirit of ecstasy는 도로가 아닌 철도에 있지 않던가!
새마을호 Looking for you를 빼 놓고서 교통수단에서의 황홀감, 엑스터시를 논한다는 건 어불성설이고 불가능이다.

정말, 새마을호에서 Looking for you 음악이 흘러나왔던 건 한글 창제 내지 예수님의 부활의 복음에 버금가는 엄청난 사건이다. 혁명, 혁신, 그 어떤 단어로도 설명하기 어렵다.
하필 저 음악을 골라 넣은 그 당시의 철도청 고위 간부는 그야말로 심리학, HCI, 인지과학 분야의 어마어마한 전문가였을 것이다. 그야말로 사람을 낚기 위해, 미래의 철덕 양성을 위해 치밀한 음모를 꾸미면서 Looking for you를 선곡했을 것이다. 이 현상에 대해서는 정말 그렇게밖에 설명이 안 된다.

철도가 나의 삶을 어떻게 바꿨는지를 기회가 된다면 강연, 저술을 통해 널리 알리고 싶다.
아아, 롤스로이스 얘기를 하면서도 철도가 연결됐구나.. ㅋㅋㅋㅋㅋ
아무튼, 롤스로이스를 직접 타면서 열차와의 승차감을 상호 비교해 볼 기회가 있으면 좋겠다.

Posted by 사무엘

2013/12/04 08:30 2013/12/04 08:30
, ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/905

두벌식 한글 입력 방식에는 초성과 종성의 구분을 위해 도깨비불 현상이라는 게 존재한다.
이것은 <날개셋> 한글 입력기의 내부에서는 다음과 같은 조건에서 발생한다. 쉽게 말해 두벌식 종성 + 두벌식 중성 + 오토마타 0상태라고 요약된다.

1. 현재 입력 중인 글자의 직전 마지막 타가 두벌식 타입으로 입력되었고, 종성이 존재한다. (초성이나 중성은 있든 없든 무관)

2. 그 상태에서 초성이 없고 중성이 존재하는 두벌식 타입의 날개셋문자가 새로 입력되었다. (종성은 있든 없든 무관)
여기서 두벌식 타입이라 함은, 오리지널 두벌식 또는 6.7에서 새로 추가된 두벌식 종성 타입이 모두 해당한다.

3. 종성까지 입력된 그 상태에서 새로 입력된 날개셋문자에 대한 오토마타 수식 계산 결과가 0이다. 보통 종성의 경우 이어치기 오토마타 수식은 n -> C ? n : 0인데, 이때는 중성이 입력되면 C가 아닌 B가 nonzero가 되므로 어차피 계산 결과는 0으로 귀착된다.

4. 혹은 양수 상태라 해도 그 상태로는 중성 and/or 종성의 낱자 결합이 불가능해서 어차피 다음 글자로 넘어가야 한다. (implied zero state)


이런 상태에서 다음 글자의 조합이 계속될 때는, 그냥 넘어가는 게 아니라 앞 글자의 종성을 적당히 떼어서 다음 글자의 초성에 미리 넣어 주는 게 도깨비불 현상이 하는 일이다.
자음을 분할하는 방식은 그냥 마지막 한 타만 떼는 기본 동작이 있고, 그 외에 특수 도깨비불 규칙이나 초-종성 공유 낱자 결합 규칙이 관여하기도 한다. 이에 대한 더 자세한 설명은 프로그램 도움말을 참고하도록 하시고.

<날개셋> 한글 입력기는 여러 낱자를 한꺼번에 입력하는 걸 지원한다. 초-중성, 중-종성을 한꺼번에 입력하는 건 물론이고 지금 글자의 종성과 다음 글자의 초성을 곧바로 입력하는 것조차 가능하다.
이와 비슷한 맥락으로 두벌식에서는 '굴' 상태에서 ㅡ를 입력해서 '구르'까지 만드는 것뿐만 아니라 ㅡ+ㅁ을 한꺼번에 입력해서 '구름'을 바로 만들 수도 있다.

다만, 그게 오리지널 두벌식 타입으로는 가능한데, 비교적 따끈한 새 기능인 '두벌식 종성' 타입에서는 중성과 종성을 중첩 입력하는 게 제대로 지원되지 않았다. 이것이 지난 7.11 버전에서 개선되었다.
오리지널 두벌식은 비록 종성이라 하더라도 다음 글자로 넘어갈 때 종성이라는 정체성이 없어지고 초성과 완전히 다름없게 처리된다. 그렇기 때문에 그 상태에서 중성+종성을 한꺼번에 입력하는 것이 자연스럽게 가능하다.

그러나 두벌식 종성은... 비록 다음 글자로 넘어가서 모음과 결합함으로써 외형상 초성으로 바뀌긴 하지만, 원래 자신이 종성이었다는 본디 정체성은 변함없이 유지되어야 한다.
자신이 이미 불변 종성인데 중성과 더불어 또 다른 종성까지 한꺼번에 입력되면, 이것은 도깨비불을 의도하는 건지 아니면 그냥 중성과 종성의 평범한 결합이나 분리를 의미하는 건지 프로그램이 논리적으로 명확하게 결정해야 한다.

오리지널 두벌식 타입의 종성 ㅁ (H2|_M)을 조합하는 상태에서 두벌식 ㅏ+ㅂ(H2|EO|_B)을 배당해 주면 응당 '맙'으로 바뀐다. 단지 bksp를 한번 누르면 ㅁ이 이제는 종성이 아니라 초성으로 되어 있을 뿐이다.
그러나 두벌식 종성 타입의 종성 ㅁ (H2J|_M)에다가 같은 입력을 공급하면 '받침ㅁ/ㅏㅂ'이 되고 ㅏ+ㅂ을 따로 조합하는 상태가 된다.

그리고 받침 ㅁ 대신 받침 ㄹ을 조합하는 상태에서 같은 입력을 공급하면 그 중성과 종성이 지금 글자와 결합하여 ㅏ+ㄻ을 조합하는 상태가 된다. 이것은 받침 ㄹ이 오리지널 두벌식이든 두벌식 종성이든 결과가 동일하다. 왜 그럴까?

가장 큰 이유는 입력 날개셋문자에 중성뿐만 아니라 종성이 존재하기 때문이다. <날개셋> 한글 입력기가 제공하는 기본 오토마타들은 한 번에 초-중-종이든 낱자가 하나씩만 들어온다고 가정하고 설계되어 있다. 그래서 C ? n : 0 수식의 값은 nonzero가 되어, 도깨비불 현상 대신 지금 글자의 조합이 계속 유지되게 되는 것이다.

물론, ㄹ+ㅂ의 경우와는 달리 ㅁ+ㅂ은 결합이 성립하지 않는다. 세 성분 중 한 성분이라도 결합이 되지 않으면 결합은 실패하므로 도깨비불 현상이 발생한다. 이때 오리지널 두벌식은 ㅁ을 초성으로 넘겨 주기 때문에 '맙'을 성공적으로 만들어 준다. 그 반면 두벌식 종성은 ㅁ을 종성으로 처리한다. 그래서 도깨비불 현상 후에도 두 종성은 서로 충돌하며 결합이 실패한다.

이 경우 프로그램은 최종적으로 도깨비불 없이 ㅁ이 마치 세벌식 종성이었던 것처럼 변경 없이 놔 두고, ㅏ+ㅂ만 다음 글자로 따로 떼어 내 준다. 이번 7.11이 취한 정책이다. 예전에는 그냥 조합이 끊어져 버렸었다.

두벌식 종성으로도 중성+종성이 충돌 없이 도깨비불 현상 처리가 되려면, 도깨비불은 결합 실패로 인해 뒤늦게 발생하는 게 아니라 오토마타 수식 차원에서 0이 돌아옴으로써 이 타이밍 때 곧바로 발생해야 한다.
애초에 중성+종성 날개셋문자가 C ? n : 0 수식을 nonzero로 통과했던 게 화근이었다. 이 수식을 !B && C ? n : 0으로 바꿔 주면 문제가 해결된다. 종성이 한번 입력된 뒤부터는 오로지 종성만 받아들이도록 말이다.

이렇듯, 두벌식 종성에서 중성뿐만 아니라 중성+종성 복합 입력의 도깨비불 현상을 처리하기 위해서는 프로그램의 내부 알고리즘도 개선되어야 하고, 사용자의 설정도 미묘하게 바뀌어야 함을 알 수 있다. 한글 입력기 하나에도 오묘한 면모가 은근히 많다.

<날개셋> 한글 입력기는 13년 동안 개발되면서 버전이 무려 7.x대까지 올라갔다. 편집기나 외부 모듈의 외형은 엄청 옛날 버전이나 지금이나 거의 바뀐 게 없지만, 이 프로그램이 진짜로 꾸준히 바뀌고 있는 부분은 입력 엔진과 이를 제어하는 제어판 쪽이다. 이 프로그램은 그야말로 어떤 변칙적인 한글 입력 방식도 만들 수 있고 한자 변환이나 bksp 동작 같은 주변 기능까지 전부 세밀하게 제어 가능한 기술 통합형 엔진을 추구하고 있기 때문이다.

살짝만 스포일링을 하자면, 현재 구상하고 있는 것은 고급 입력 스키마와 고급 입력기이다.
글쇠를 길게 눌렀다 떼는 건, 여러 글쇠를 한꺼번에 누르는 것, 타이밍까지 세벌식 자판에 최적화해 주는 입력 스키마..
그리고 지금의 최종 변환 규칙 같은 것을 입력기 단위로도 적용하여 한글로 일본어나 구결을 곧바로 입력할 수 있는 문자 생성기. 한글과 비한글 문자를 조합 상태에서 끌어들일 수 있는 그런 시스템을 생각 중이다.

이 정도까지 만들어 놓으면 프로그램의 버전은 7.x대 중후반은 올라갈 수 있을 것이고, 그 뒤에 입력기 개발은 진짜로 반쯤 접은 채 다음 글꼴 연구를 시작할 수 있을 것 같다.
NLP 쪽의 연동이 없이 한국어와 무관하게 한글 자체만의 engineering도 할 일이 정말 많다.

Posted by 사무엘

2013/12/01 08:22 2013/12/01 08:22
, ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/904

16비트 시절에는 잘 알다시피 int 포함 machine word의 크기가 말 그대로 2바이트였다. 그리고 근거리/원거리 포인터가 존재했으며 복잡한 메모리 모델을 따져야 했다. 여기까지는 도스든 윈도든 공통이다. 그럼, 그 시절에 Windows 프로그래밍은 어떠했을까?

16비트 Windows는 잘 알다시피 모든 프로그램이 단일 스레드를 공유하면서 단일 메모리 주소 공간에서 실행되었다. 이런 열악한 환경에서 멀티태스킹을 구현하는 것은 결코 쉬운 일이 아니었다.
그래서 그 시절에는 콜백 함수를 운영체제에다 지정해 주는 것조차도 보통일이 아니었다. 오늘은 오랜만에 이 부분에 대해서 예전에 몰랐다가 최근에 본인이 추가로 알게 된 이야기를 좀 하겠다.

Windows API는 C언어 함수 형태로 만들어졌으니 그때는 지금으로 치면 C++ 가상 함수가 할 일을 함수 포인터로 다 처리하고 있었다. 윈도우 프로시저, 대화상자 프로시저 같은 것 말이다.

그런데 같은 프로그램이 두 번 중첩 실행되면, 코드는 동일하더라도 그 코드가 다루는 스택(데이터) context는 결국 프로세스별로 서로 달라질 수 있게 된다. 이를 어떻게 구분해야 할까?
32비트 이후부터는 가상 메모리 기술이 워낙 발달하여 그 context가 CPU 차원에서 알아서 따로 잘 처리된다. 그러나 16비트 기계엔 그런 개념이 없었다.

결국은, 실제 콜백 함수가 호출되기 전에 그 콜백 함수가 처리할 자신의 데이터 세그먼트 영역을 CPU 레지스터에다 써 주는 stub, 일명 썽킹(thunking) 코드를 소프트웨어적으로 별도로 만들어야 했다. C++로 치면, 클래스 멤버 함수 호출을 위해 this 포인터의 값을 EAX 레지스터에다 써 주는 것과 개념적으로 비슷하다.

우리가 만든 콜백 함수는 그 썽킹 함수를 통해서 호출해야 한 것이다. 운영체제에다가도 당연히 썽킹 함수를 알려 주고 말이다.
이것이 바로 16비트 시절 코드를 보면 밥 먹듯이 보이는 MakeProcInstance와 FreeProcInstance API 함수의 정체이다.
별도의 메모리를 추가로 할당해서 기계어 코드를 추가해 준 것이기 때문에, 메모리의 해제까지 해 줘야 한다.

대화상자 하나를 출력하더라도 아래처럼 말이다.

FARPROC pfnThunkProc = MakeProcInstance( (FARPROC)My_Actual_Dialog_Proc, hInstance); //내 대화상자 프로시저가 우리 인스턴스 핸들을 context로 동작하게 한다
DialogBox(hInstance, "Dialog_Resource_Name", hWndParent, (DLGPROC)pfnThunkProc );
FreeProcInstance(pfnThunkProc);

요즘 같으면 아래의 절차 하나만으로도 충분했을 텐데 말이다.

DialogBox(hInstance, "Dialog_Resource_Name", hWndParent, My_Actual_Dialog_Proc );

결국 My_Actual_Dialog_Proc라는 코드는 시스템 전체를 통틀어서 단 하나 유일하게 존재하겠지만,
이 프로그램을 여러 번 실행하더라도 각 프로그램들은 그 함수로부터 파생된 자신만의 고유한 콜백 함수를 통해서 대화상자를 호출하게 된다.

단, Windows 3.1에서는 함수명을 export해 주는 것만으로 이렇게 콜백 함수에 대한 썽킹을 매번 해 줘야 하는 번거로움을 생략할 수 있었다고 한다.

지금이야 프로그래밍에서 export 키워드라 하면, C++에서 템플릿의 선언과 정의를 번역 단위를 넘나들며 공유할 수 있게 하려 했던 비현실적인 흑역사 키워드일 뿐이다. Windows 플랫폼으로 문맥을 넓힐 경우, export는 클래스나 함수 심벌을 빌드되는 파일 차원에서 외부로 노출하여 GetProcAddress 함수로 노출이 되게 하는 속성 지정자이다. 비주얼 C++ 기준으로 __declspec(dllexport) 라고 쓴다.

지금이야 이런 export 속성은 말 그대로 DLL을 만들 때에나 쓰인다.
그러나 16비트 시절에는 EXE도 운영체제로부터 호출을 받아야 하는 콜백 함수를 넘겨 줄 목적으로 심벌 export를 즐겨 활용했었다.
export된 함수는 외부로부터 호출받는 게 당연시될 거라 여겨졌으므로, 링커와 운영체제가 자체적으로 데이터 세그먼트 보정을 하는 전처리 루틴을 추가해 줬다. 따라서 코드가 훨씬 더 깔끔해진다.

이런 이유로 인해 Windows 3.x 실행 파일들을 헥스 에디터로 들여다보면 대체로 ...WNDPROC, ...DLGPROC 같은 식으로 끝나는 웬 이상한 함수 이름들이 내부에 들어있는 걸 확인할 수 있다. 32비트 이후부터는 찾을 수 없는 관행이다. 자기 내부에서만 쓰는 콜백 함수들을 왜 저렇게 노출해 놓겠는가?

어떤 함수에 export 속성을 부여하기 위해서는 결국 C/C++ 언어에다가 없는 문법을 새로 추가하거나, 아니면 소스 코드는 그대로 놔 두고 컴파일러가 아닌 링커만이 인식하는 부가 정보 같은 게 주어져야 할 것이다. 전자는 소스 코드의 이식성을 떨어뜨린다는 부담이 있지만, 그래도 뒤끝이 없고 한 소스에 빌드에 필요한 모든 정보가 한데 모이니 편리하다. 그래서 그 당시에는 __export라는 비표준 MS 확장 키워드가 도입되었고, 이를 보통 EXPORT라는 매크로로 감싸서 사용하곤 했다. 이런 식으로 말이다.

long FAR PASCAL EXPORT MyWindowProc(HWND hWnd, UINT nMsg, WPARAM wParam, LPARAM lParam); //그 당시 콜백 함수는 반드시 '파스칼' 방식이라는 함수 호출 규약대로 선언되어야만 했다.

한편 후자는 바로 그 이름도 유명한 DEF(모듈 정의) 파일이다.
지금도 DEF 파일이 안 쓰이는 건 아니지만 정말 DLL을 만들 때가 고작이다. 그 반면 16비트 시절에는 DEF가 훨씬 더 중요하게 쓰였던 모양이다.
export하는 콜백 함수뿐만 아니라 이 프로그램에 대한 소개문, 그리고 필요한 스택/힙 크기까지 정확하게 명시되어야 했다.

32비트 이후부터는 스택/힙이 부족하면, 프로그램 로딩 시간이 좀 더 걸릴 뿐이지 실시간으로 추가 할당하여 working set의 확장이 가능한 반면, 16비트 시절에는 메모리 양도 부족하고 또 한 주소 공간에서 여러 프로그램들이 뽁짝뽁짝 복잡하게 지내다 보니 이런 게 핀트가 어긋나면 프로그램 실행이 아예 불가능했을 것 같다.

옛날의 New Executable 포맷에는 자체적으로 name table이라 불리는 범용적인 문자열 테이블이 있었고, import/export하는 심벌 이름은 물론 이 EXE/DLL에 대한 간단한 소개문까지 그런 데에 들어갈 수 있었다.
지금으로 치면 버전 리소스에 들어가는 description과 유사한데 역할 중복인 셈이다. 그런 것까지 DEF 파일에다 명시해 줬었다.

자.. 설명을 들으니 어떤 생각이 드시는지?
16비트 Windows용 실행 파일을 분석하는 도구는 그리 충분치 않다. 일단 개발자들의 친구인 Dependency Walker가 이를 전혀 지원하지 않으며, 그나마 괜찮은 물건으로는 옛날에 Windows 98에 내장되어 있던 QuickView라는 프로그램이 적격이었다. 기본적인 사항은 다 잘 출력해 줬다.

16비트 시절에는 잘 알다시피 HINSTANCE는 각 프로그램의 데이터 세그먼트를 식별하는 번호표에 가까웠고, 개념적으로 지금 같은 포인터가 아니라 오늘날로 치면 오히려 프로세스를 식별하는 HANDLE처럼 널리 쓰였다. (비록 Close를 할 일은 없었겠지만 말이다) 게다가 EXE는 HINSTANCE, DLL은 HMODULE로 성격도 달랐다. 그래서 LoadLibrary 함수의 리턴값은 분명 HMODULE이다.

그때는 EXE/DLL로부터 리소스를 얻어 오는 과정도 정말 복잡했고 Load/Free 절차뿐만 아니라 lock/unlock까지 있었다. 메모리의 절대적인 양이 충분치 않기도 하고 가상 메모리 같은 시스템이 없던 관계로, 단편화를 방지하기 위해 평소에 즉각 쓰지 않는 메모리 블록은 재배치가 가능하게 놔 두는 관행이 더 보편적이었기 때문이다.

한편으로 그때는 시스템 전체에 영향을 끼치기가 쉬웠다. 특히 DLL이 이 분야에 관한 한 지존이었다.
DLL에서 선언한 전역변수는 모든 프로세스가 한데 공유되었으며, DLL이 실행하는 코드는 저런 EXE처럼 여러 컨텍스트에서 중첩 실행될 일이 없고 애초에 데이터 세그먼트 구분을 할 필요가 없었다!

그리고 16비트 시절엔 애초에 콜백 함수를 지정해 주는 과정이 처음부터 저렇게 번거로웠던 만큼, 시스템 전체의 동작 방식을 바꾸는 global 훅을 설치하더라도 훅 프로시저를 반드시 DLL에다가만 만들어야 한다는 제약이 없었다.
그럼에도 불구하고 16비트 시절은 32비트 시절보다 편한 것보다는 불편한게 더 많았다는 것이 부인할 수 없는 사실이다.

끝으로 여담.
이렇듯, 본인은 초등학교 아주 어릴 적부터 프로그래밍을 시작한 관계로, 그 시절에 대한 향수가 있고 '레트로'-_- 컴퓨팅 쪽으로 관심이 많다.
그런데, 그런 것에서조차도 양덕후들의 기상은 갑이다. the old new things 같은 블로그는 이 바닥의 지존이라고 봐야 하고, Windows 3.x로도 모자라서 2.x나 1.x용 프로그램을 만들었다고 인증샷 올리는 사람도 있다.

1985년에 출시된 Windows 1.x의 경우, VGA 카드조차도 없던 시절에 만들어진 관계로 가장 좋은 비디오 모드가 640*350 해상도짜리 EGA이다. 그런데 그걸 640*480 VGA 내지 심지어 800*600 SVGA에서 동작하게 드라이버 패치를 만든 사람도 있다.

참고로 Windows 1.x 정도 되면.. 프로그램 개발을 위한 컴파일러는 그야말로 1986년에 나온 MS C 4.x를 써야 하고, 얘는 함수 호출 인자도 ANSI 스타일이 아니라 K&R 스타일만 써야 하는 진짜 무지막지한 골동품이라고 한다. Windows 1.x는 파스칼로 개발되었다고 들었는데 그래도 그때부터 C 형태의 SDK는 있었던 모양이다.

Posted by 사무엘

2013/11/28 08:29 2013/11/28 08:29
, ,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/903

« Previous : 1 : ... 130 : 131 : 132 : 133 : 134 : 135 : 136 : 137 : 138 : ... 214 : Next »

블로그 이미지

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

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

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

Site Stats

Total hits:
2633125
Today:
1677
Yesterday:
1314