1. 하나님/주께 속한 것들

  • 해석 (창 40:8)
  • 판단/심판 (잠 29:26)
  • 전쟁 (삼상 17:47)
  • 보복 (신 32,35, 시 94:1, 나 1:2, 롬 12:19, 히 10:30)

이런 거 한데 모아서 의미를 강론하면 심도 있는 설교 한 편이 만들어질 수 있을 것 같다. 아, 실제로 이런 설교가 나왔다.
위의 요소들을 종합하면, "목표는 수단을 정당화한다"는 하나님의 입장에서만 보편적으로 적용 가능하다는 결론이 도출된다(인간에게 어떤 역경이 닥치더라도..).

2. 믿음에 대해서

평소에 아무리 영적이고 소위 말하는 신앙 좋은 사람이라 하더라도 일상을 살면서 정말 최소한의 세상적으로 방어적으로 생각하는 게 있으며, 그로 인해 판단을 잠시 잘못하거나 하나님의 일을 불신할 수도 있다.

그 천하의 사무엘도 처음엔 이새의 맏아들 엘리압이 덩치 크고 잘생겨서 스펙 외모가 탁월한 걸 보고는 "이 사람이야말로 장군깜 대왕깜이구나"라고 생각했는데.. 이때 기어이 하나님의 그 유명한 " '주'는 사람의 겉모습이 아니라 마음을 보느니라" 말씀이 나오게 됐다. (삼상 16:6-7을 꼭 보시길)

사도행전에서 베드로가 포악한 헤롯 왕에게 체포되자 교회가 정말 열심히 뜨겁게 간절히 기도했는데..
정작 기적이 일어나고 베드로가 진짜로 탈옥해서 찾아오니까 교회 사람들이 믿질 못했다. 여자애가 문을 열어 보지도 않고 달려와서 "저거 베드로 님 목소리예요!"라고 외치자 그에 대한 어른들의 반응은 "너 미쳤구나?"였다. (행 12:14-15. "아니면 (죽은) 베드로의 천사의 목소리이겠지"라는 확인사살까지 나옴..)

5천 명을 먹이는 오병이어 기적 이전에 똑똑한 제자 빌립이 계산기 뚜드리면서.. "이거 아무리 적게 잡아도 예산이 200데나리온, 1천만 원이 훌쩍 넘게 필요하겠는데요?"라고 말한 건
빌립이 특별히 믿음이 없거나 악의적이기 때문은 절대 아니었다.

사무엘도, 저 초대교회 사람들도 저 상황에서 처음엔 당연히 그렇게 판단할 수밖에 없었다. 그걸 우리가 죄나 잘못이라고 판단할 자격이라곤 털끝만큼도 없다.
단지, 자기 생각이 틀렸다는 걸 알게 되면 곧장 자기 생각을 유연하게 고치고 하나님을 찬양하고 감사하면 된다.

계산기 뚜드리지 말라는 얘기도 아니고(눅 14:28, 31) 세상일을 소홀히 하라는 말도 아니고, 그냥 하나님 핑계로 내 일을 방관하라는 말도 아니다. 인간은 신처럼 사람의 마음을 읽는 능력을 갖고 있지 않다. 또한 예수쟁이들도 평소에야 병 걸리면 병원 가고 백신도 맞는 게 너무 당연한 일이고 정상이다.

그 대신 세상 돌아가는 일이 그렇게 "눈에 보이는 것만이 전부는 아니다, 하나님의 역사는 언제든 일어날 수 있다"라는 여지를 늘 고려하고 믿음을 전제로 깔고 살면 된다는 것이다.

3. 내가 믿는 것에 대한 흔한 부정적 편견과, 그에 대한 반박

(1) 구원의 영원한 보장
오해: 기쁜 소식 선교회, 일명 구원파..;;
반박: 저기서 무슨 교리를 가르치는지는 모르겠지만, 구원의 영원한 보장은 너무 당연한 얘기이다. 성경에 따르면, 인간은 자기 선행으로 구원을 얻은 게 아니기 때문에 자기 악행으로 구원을 잃지도 않는다. 일단 한번 예수님을 제대로 내 구원자로 영접만 했다면 말이다. 구원의 근거는 인간 쪽에 있는 게 아니라 하나님 쪽에 있다. 그리고 그렇게 된 사람이라면 아주 예외적인 개막장이 아닌 이상, 죄에 대해서 결코 그렇게 안일하게 생각하지 않게 된다.

(2) 왕국
오해: 여호와의 증인.. =_=;;
반박: kingdom은 지극히 평범한 성경 용어이다. 예수님이 지상 재림해서 이 땅을 다스릴 때에도 당연히 절대왕정으로 다스리지, 무슨 대통령 선거에 후보로 출마해서 다른 사람들과 경쟁(?)하고 선거 유세할 일 따위는 없다. 개역성경에서 그냥 '나라'라고 번역한 단어들도 nation이 아닌 이상 kingdom은 '왕국'이라고 번역해야 정확하다.
멀쩡한 좋은 용어의 어감을 다 망가뜨려 놓는 집단이 공산주의자만 있는 건 아니어 보인다(인민, 동무..).

(3) 킹 제임스 성경 유일주의
오해: 특정 성경 출판사, 특정 목사를 떠받드는 편협한 짓이다.
반박: 그건 KJV 유일주의를 반대하는 진영에다가도 동일하게 적용 가능한 치졸한 논리이다. 그럼 그 사람들의 최종 권위는 그냥 특정 신학교 교수 내지 현대의 그리스어 히브리어 학자들일 뿐이지.

오로지 예수만이 유일한 구원자라고 믿는 종교가, 그 종교의 근거 경전이 단 한 종류만 완벽하게 보존돼 있고 나머지는 잘못됐다고 믿지 못할 이유는 전혀 없다. 또한, 말씀이 육신이 되어 오셨다는 엄청난 얘기도 믿는데 말씀이 언어의 장벽을 극복하고 온전히 번역됐다고는 왜 못 믿는가? (저 말씀과 그 말씀이 서로 다르다는 태클은 사절)
내 신앙은 그 어느 집단이나 사람의 이익을 결코 대변하고 있지 않다.

(4) 간극 재창조
오해: 아담 이전의 인간, 귀신 따위를 가르친다.
반박: 전혀 아니다. 인간 문명만 6천 년이고 현 세상이 문자적인 6일 동안 창조되었을 뿐이지, 이전 세상은 더 오래 전부터 있었고 그걸 세속 과학이 말하는 긴 지질 시대 및 우주의 역사와 조화시키면 아무 문제 없다. 그리고 재창조는 기독교에서 당연하게 가르치는 사탄 마귀의 창조와 타락을 정확하게 설명해 줄 수 있다. 아담은 최초로 죄를 지은 인간이지만 최초로 죄를 지은 인격체는 아니다.

(5) 세대주의
오해: 시한부 종말론을 조장한다.
반박: 세상에 끝이 있는 것 자체는 맞다. 단지 이 세상에서 사는 것은 미래를 알 수 없고 끝이 없는 것처럼 신실하게 살다가 죽거나 들림받는 것이 바람직할 뿐이다.
성경은 "원수를 사랑하라"도 있고 한편으로 맹렬한 보복과 "네 어린것들을 돌에 메어치는 자가 행복하리로다"도 있는 책이다. 성경의 저자가 싸이코 정신분열 다중인격자가 아닌 이상, 세대주의는 성경을 성경으로 풀이하고 성경에 모순처럼 보이는 구절, 우리에게 당장 적용되지 않는 구절들을 잘 분별해 주는 아주 건전한 성경 풀이법이다. 먼저 문자적으로 해석하고, 다음으로 영적으로 적용한다.

나로서는 계시록 20장에 거듭 반복해서 나오는 문자적인 1000년을 안 믿는 건, 창세기 1장의 문자적인 6일을 안 믿는 것하고 하나도 다를 바 없어 보인다.
성경에 논리· 과학적으로 설명이 안 되고 일면 믿어지지 않는 게 있으면 솔직하게 안 믿으면 된다. 성경이 말하는 바 자체가 그게 아니라고 주작을 하는 것은 옳지 못한 태도이다.

4. 음모론

믿을 가치가 있는 음모:

  • 이 세상의 영적 배후에 있는.. '빛의 천사로 위장한 세상의 신' (고후 4:4. 성경에 아예 대놓고 나와 있음)
  • 북괴의 대남적화 음모. 재래식 무기로 안 되니 비대칭무기, 남조선의 법조계와 교육계 적화, 나라 정체성 부정, 역사왜곡. 작은악과 필요악 교란. 민주팔이로 사회 기강과 체제 전복.
  • 철도청의 음모. 승객을 철덕 철도 중독자로 만들기 위해 과거 철도청에서는 코모넷에 외주를 줘서 새마을호 객실에다 Looking for you 곡을 주입해 넣음

별 영양가 없는 음모

  • 케네디 대통령 암살의 배후
  • 유대인 재벌, 로스차일드 가문, 프리메이슨 일루미나티 음모
  • 백신 제조 및 제약 회사들 음모

일고의 가치가 없는, 택도 없는 음모

  • 9· 11 테러는 자작극이다
  • 아폴로 계획 달 착륙은 NASA의 거짓 조작이다
  • 남북 통일을 원하지 않는 미국 일본의 음모, 친일파 음모, 뭐시기의 국정농단 음모 따위

5. 변하는 것, 변하지 않는 것

  • 초딩 시절에 4천~4500만이라고 배웠던 우리나라 인구는 5천 1백만을 넘어섰고, 옛날에 50억이라고 배웠던 세계 인구는 선진국들의 저출산 풍조에도 불구하고 80억을 향해 다가가고 있다.
  • 지구 전체의 평균 이산화탄소 농도가 340ppm쯤 된다고 배웠던 것이 이제는 400ppm을 넘어섰다고 한다. 하지만 오존층은 파괴되는 걸 한창 걱정하던 시절과는 달리 많이 회복됐다고도 한다.
  • 언어학에서 한국어· 일본어에 대한 우랄 알타이 어족설은 부정되고 있다.
  • 한때 세계에서 가장 깊은 바다라고 배웠던 마리아나 해구 아래의 '비티아스 해연'(11034m)은 1957년에 행해진 러시아의 첫 탐사 이후로 재탐사에서 같은 결과가 나오질 않아서 당시 측정의 정확도에 의구심이 제기되고 있다.
  • 어렸을 때는 곰팡이를 식물의 특수한 형태라고 배웠던 반면, 요즘은 이놈은 동물도 식물도 아닌, 균계라는 독자적인 카테고리로 분류되고 있다.
  • 난 어렸을 때는 김 구가 젊은 시절에 "국모의 원쑤"를 갚으려고 민간인으로 위장한 일본 육군 장교 첩자를 때려죽였다고 배웠지만, 사실 그건 생 날조이고, 김 구가 그냥 객기로 애매한 일본인 민간인을 죽인 흑역사라는 것이 밝혀졌다.

한때 '청산리 대첩'이라고 배웠던 항일 독립군의 전투는 비록 우리가 전술적으로 승리를 거두긴 했지만 과연 정말 '대첩'이라고 불릴 정도의 압도적인 교환비로 이긴 것인지는 진위가 좀 의심받고 있다. 그 정도로 일본군이 졸전· 패전을 하고 학살당했는데 당시 지휘관이 문책되거나 본토로 지원 요청이 갔거나, 많은 시신이 수습되어 야스쿠니 신사에 간 정황이 없기 때문이다.
물론 일제도 자기에게 불리한 역사를 대외적으로 조작할 가능성이 있지만, 조작할 이유가 없는 내부 기록에도 증거가 없으며 한국 내부에서도 전과 기록에 대한 과장이 존재한다는 것은 공공연한 비밀로 통용돼 왔기 때문이다.

반대로 조선을 비하하는 근거로 즐겨 활용되던 지리학자 김 정호의 최후에 대해서 '주리 틀기+옥사설' 역시 21세기에 와서는 주작으로 여겨져서 부정되고 있다. 관련 증거와 기록이 전무할 뿐만 아니라 지도 작품이 잘만 전해져 내려오며, 지도의 제작에 관여했던 다른 관료들도 아무 처벌 없이 승승장구+자연사했기 때문이다.

뭐 이런 식으로.. 그 정의상 절대불변인 수학 공식이라든가, 우주가 뒤엎어지지 않는 한 절대불변이 보장되는 뉴턴의 법칙, 열역학 법칙 같은 게 아닌 한.. 세상 대부분의 학문들은 시간의 흐름에 따라 변하고 고쳐지고 보완된다. 심지어 고전 텍스트조차도 일본어· 영어를 거쳐서 중역되었던 것이 원어 직역으로 다시 나온다거나, 검열되었던 내용을 원래대로 다 넣어서 다시 출간되곤 한다.

그러나 이 모든 추세에도 불구하고 본인은 성경만은 그런 트렌드, 그런 연구 방법론의 영향을 받지 않는다고 믿는다. 오늘날 인간의 노력으로 성경 본문이 더 나아지고 있다거나, 새로운 해석, 더 정확한 해석이 나온다고 믿지 않는다. 그런 새로운 추세로 나왔다는 대안이란 게 기껏해야, 겨우, 고작 "이스라엘 백성은 홍해가 아니라 갈대밭을 건넌 것이다", "아담과 이브가 아니라 아담과 '스티브'였다", "가룟 유다도 사실 알고 보면 인간적으로 착한 사람이었다" 이런 식이라면 난 더욱 단호히 거부한다.

왜냐하면 인간이 과학 기술이 아무리 발달해도 성경이 전제로 깔고 있는 인간의 죄성과 근본 성품이라는 건 정말 뉴턴의 만유인력 법칙만큼이나 6천 년 전이나 지금이나 전혀 변함없기 때문이다. 성경의 텍스트가 바뀌어야 할 이유가 전혀 없다. 죄인이 성경 말씀의 판단을 받아서 고쳐져야지, 인간이 성경을 업데이트 해야 할 필요나 이유나 당위성은 없다. 오늘날은 옛날처럼 성경을 물리적으로 파괴하고 없애지는 않지만 성경 본문이나 해석을 변조하고 왜곡하는 시대이다.

다른 모든 텍스트들은 번역을 거칠수록 마치 jpg 손실 압축처럼 원래 의미로부터 차이와 왜곡이 커질지 모르나, 영어 킹 제임스 성경으로 옮겨지는 과정에서는 본인은 다른 특례나 섭리가 있었다고 믿는다.

전에도 한 적이 있는 얘기이지 싶은데.. 이 '지구 안'에서는 저 수천 m 깊이에 달하는 암흑천지 바닷속이나 극지방, 심지어 화산 근처 등 일반적인 형태의 생명체가 도저히 살 수 없는 곳에서도 생명이 존재한다.
그러나 지구 밖 우주에서는 제아무리 지구와 비슷한 행성을 눈에 불을 켜고 찾아 헤매도 생명 같은 건 코빼기도 존재하지 않는다.

과학적으로 증명이나 반증이 불가능한 신념의 영역이긴 하지만, 본인은 이것이 보통일이 아니라고 생각한다. 반대로 무신론 회의론자라면 이 현실을 도저히 받아들일 수 없으니 지구 밖에서도 기를 쓰고 생명을 찾아 헤매고 있을 것이다. 세상엔 이런 식으로 성경에 대해서든 신에 대해서든, 뭔가 우연 같아 보이지 않은 구석이 존재한다.

Posted by 사무엘

2017/12/29 08:34 2017/12/29 08:34
,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1442

C++ 다중 상속 생각

날개셋 한글 입력기 같은 Windows용 프로그램을 개발하다 보면 여러 개의 COM 인터페이스를 한꺼번에 상속받아 구현한 단일 클래스를 구현하게 된다.

그런데 하루는 이런 의문이 들었다. 각각의 인터페이스들이 다 IUnknown을 상속받았는데 어떻게 어느 인터페이스로 접근하든지 AddRef, Release 같은 공통 인터페이스들은 중복 없이 동일한 함수 및 동일한 숫자 카운터 인스턴스로 연결될까? 데이터 멤버 없이 인터페이스 상속만 하면 this 포인터 보정이 필요 없이 다중 상속과 관련된 문제들이 상당수 깔끔하게 해결될까?

그래서 클래스 A, 이로부터 상속받은 B와 C, 그리고 B와 C를 다중 상속한 D 이렇게 네 개의 클래스가 있을 때 일명 ‘죽음의 다이아몬드’ 현상을 해소하는 방법이 무엇이 있는지를 정리해 봤다. C++의 다중 상속과 관련해서는 이제 더 글을 쓸 게 없을 줄 알았는데 내가 지금까지 생각하지 못하고 있던 요소들이 더 있었다.

1. 가상 상속

클래스에서 상속이라는 건 기술적으로 어떤 구조체에다가 부모 클래스의 컨텐츠(데이터 멤버)들을 앞에 쭉 늘어놓고 나서 그 뒤에 나 자신의 컨텐츠를 추가하는 것과 같다. 그러니 부모 클래스와 자식 클래스 포인터를 형변환 하는 건 그냥 프로그래밍 언어 차원에서의 의미 변환일 뿐, 메모리 주소가 바뀌는 것은 전혀 없다. 아주 쉽다.

그런데 가상 상속은 부모 클래스의 컨텐츠를 그렇게 나 자신의 일부로서 고정된 영역에 배치하는 게 아니라, 포인터로 참조하는 것과 같다.
부모 클래스를 ‘가상’이라는 방식으로 상속한 자식 클래스는 부모 클래스와 자식 클래스가 굳이 메모리 상에 연속된 형태로 있지 않아도 된다. 그러니 동일 부모를 공유하는 다수의 클래스가 다중 상속되더라도 이들이 공통의 유일한 부모 하나만을 가리키게 하면, 한 부모 클래스의 데이터들이 불필요하게 여러 번 상속되는 것을 막을 수 있다.

여기서 중요한 것은, D가 B, C를 ‘가상’ 상속하는 게 아니라는 점이다. 부모인 B와 C가 A를 미리 가상으로 상속해 놔야 한다.
가상 함수도 자식이 아닌 부모 클래스에서 미리 지정해 놔야 하듯 말이다.

그러니 클래스 라이브러리 개발자는 공통 부모를 공유하는 여러 클래스들이 사용자에 의해 다중 상속되겠다 싶으면 그 공통 부모를 virtual로 상속하도록 설계를 미리 해 놔야 한다. 특히 그 클래스(공통 부모 말고)가 순수 가상 함수 같은 걸 포함하고 있어서 상속이 100% 필수라면 더욱 그러하다.
앞의 A~D의 경우, 혹시 A가 default constructor가 없어서 B, C의 생성자에 모두 A를 초기화하는 인자가 들어있었다 하더라도, D의 A는 D의 생성자에서 제공된 인자만으로 딱 한 번만 초기화된다.

가상 상속을 한 자식 클래스는 굉장히 이색적인 특징을 하나 갖게 된다.
자식 클래스의 포인터에서 부모 클래스의 포인터로 형변환을 하는 것이야 너무 당연한 귀결이며, 반대로 부모에서 자식으로 가는 건 좀 위험한 일이긴 하지만 어쨌든 가능하다. 단일 상속에서는 말할 필요도 없고, 다중 상속이라 하더라도 그냥 고정된 크기만큼의 포인터 덧셈/뺄셈만 하면 된다.
그에 반해, 부모 클래스에서 자신을 virtual 상속한 자식 클래스로 형변환은 일반적으로 허용되지 않는다…!

A *pa = new D; //자식에서 부모로 가는 건 당연히 되고
B *pb = new D;
D *pd;
pd = static_cast<D*>(pb); //부모에서 자식으로 가는 건 요건 괜찮지만
pd = static_cast<D*>(pa); //요건 안 된다는 뜻..

그 자식 클래스의 주소와 부모 클래스의 주소 사이에는 컴파일 타임 때 결정되는 관계 내지 개연성이 없기 때문이다.
자식에서 부모로 거슬러 올라가는 게 단방향 연결 리스트를 타는 것과 다를 바 없게 됐는데, 저런 형변환은 단방향 연결 리스트를 역추적하는 것과 같으니까 말이다.

물론, 가상 상속이라 해도 현실에서는 D라는 오브젝트 내부에서 A가 배치되는 오프셋은 고정불변일 것이고 컴파일러가 그 값을 계산하는 게 불가능하지 않을 것이다. 모든 자식 클래스들과 연속적으로 배치되지만 않을 뿐이다.
static_cast를 어거지로 구현하라면 구현할 수는 있다. 하지만 이 A가 반드시 D에 속한 A라는 보장도 없고, 포인터에 무엇이 들어있는지 확신할 수 없는데.. C++ 컴파일러가 그런 어거지 무리수까지 구현하지는 않기로 한 모양이다.

2. 가상 함수로 이뤄진 추상 클래스(인터페이스)들만 상속

죽음의 다이아몬드를 해소하기 위해서 요즘 프로그래밍 언어들은 C++ 같은 우악스러운 수준의 다중 상속을 허용하지 않고, 잘 알다시피 데이터 멤버 없고 가상 함수로만 구성된 추상 클래스들의 다중 상속만 허용하곤 한다.
그러면 문제의 복잡도가 크게 줄어들긴 한다. 효과가 있다. 하지만 그게 전부, 장땡은 아니다.

명시적인 데이터가 없는 클래스라 하더라도 가상 함수가 들어있는 클래스를 상속받을 경우, 2개째와 그 이후부터는 클래스 하나당 vtbl (가상 함수 테이블 v-table) 포인터만치 클래스의 덩치가 커지게 된다.

단일 상속 체계에서는 this 포인터의 변화가 전무하니 상속을 제아무리 많이 하더라도 한 vtbl의 크기만 커질 뿐, 그 테이블을 가리키는 포인터의 개수 자체가 늘어날 필요는 없다.
그러나 다중 상속에서는 D 같은 한 객체가 상황에 따라 클래스 B 행세도 하고 클래스 C 행세도 하면서 카멜레온처럼 변할 수 있어야 한다. 그렇기 때문에 A, B, D일 때의 vtbl, 그리고 C일 때의 vtbl 이렇게, 테이블과 테이블 포인터가 둘 필요하다.

클래스 D에 속하는 인스턴스 포인터(가령, D *pd)를 부모 C의 포인터로 변환해서 전달할 때는 pd는 A, B, D 같은 직통 상속 계열 vtbl이 아니라 C의 vtbl을 가리키는 형태로 오프셋이 보정된다. 그리고 여기서 가상 함수를 호출하면.. this 포인터가 C가 아닌 D를 기준으로, 보정 전의 형태로 복구된 채로 함수에 전해진다. 이 함수는 애초부터 C가 아닌 D에 소속된 함수이기 때문이다.

즉, 다중 상속에서 가상 함수를 호출하면 비록 겉으로 this 포인터는 바뀐 게 없지만 내부적으로 vtbl을 찾는 것을 부모와 자식 클래스가 완전히 동일하게 수행하기 위해서 보정이 일어나고, 그걸 함수에다 호출할 때는 보정 전의 값을 전하도록 일종의 thunk 함수가 먼저 수행된다.
한 클래스 오브젝트에서 여러 인터페이스 함수를 자유자재로 호출하는 polymorphism의 이면에는 이런 비용 오버헤드가 존재하는 셈이다. 무슨 숫자나 문자열로 메시지를 전하는 게 아닌 이상, 서로 다른 클래스에 존재하는 가상 함수는 vtbl의 종류와 오프셋으로 구분할 수밖에 없다.

3. 멤버로만 갖기

다중 상속의 지저분함을 회피하는 방법 중 하나는.. 원하는 기능이 들어있는 클래스를 내 아래로 상속하지 말고 그냥 멤버 변수로 갖는 것이다. 상속하더라도 걔만 따로 상속해서 확장 구현을 한 뒤에 그걸 멤버 변수로 갖는다. 이 개념을 유식한 용어로는 aggregation이라고 한다.

이 방법은 다중 상속의 각종 오버헤드는 피할 수 있지만 그만큼 다른 방면에서 불편을 야기한다. 그 클래스가 동작하는 과정에서 내 클래스의 함수 및 데이터를 빈번하게 참조해야 한다면(결합도 coupling가 높은 관계..) 그 통로를 억지로 트는 게 더 불편하며 코드를 지저분하게 만든다. 또한 서로 다른 클래스 간에 중복 없이 동일한 기능을 제공하는 일관된 인터페이스를 만드는 게 다중 상속이 아니면 답이 없는 경우도 있다.

이게 경험상 딱 떨어지는 답이 있는 문제가 아니다. 복잡한 클래스 계층이 필요한 대규모 개발을 한 경험이 없는 프로그래머라면 이런 부류의 문제는 배경을 이해하는 것조차 난감할 것이다. 그렇기 때문에 다중 상속이 무조건 나쁘기만 한 건 아니며, 그걸 억지로 우회하다 보면 결국 다른 형태로 불편함과 성능 오버헤드가 야기될 거라며 다중 상속을 옹호하는 프로그래머도 있다.

이상.
객체지향 프로그래밍 언어에서 다중 상속은 사람마다 취향 논란이 많은 주제이다. 비록 C++이 이걸 지원하는 유일한 언어는 아니지만, 네이티브 코드 생성이 가능한 유명한 언어 중에서는 C++이 사실상 대표격인 것처럼 취급받고 있다.

어떤 기능이 절대적으로 나쁜 것만 아니다면야 없는 것보다는 있는 게 좋을 것이다. 상술했다시피 다중 상속이 가능해서 아주 편리한 경우도 물론 있다. 한 오브젝트로 다수 개의 기반 클래스 행세를 자동으로 하는 것과, 그 오브젝트 내부의 구현 함수에서는 여러 기반 클래스를 넘나드는 게 동시에 되니까 말이다.

하지만 다중 상속은 가성비를 따져 보니 그 부작용과 오버헤드, 삽질을 감수하면서까지 굳이 구현하고 지원할 필요가 있나 하는 게 PL계의 다수설 대세로 흐르고 있다. this 포인터의 보정이라든가, 복수 개의 기반 클래스들이 또 공통의 기반 클래스를 갖고 있을 때 발생하는 모호성의 처리 등.. 템플릿 export만치 막장은 아니지만 컴파일러 개발자와 PL 연구자들의 고개는 설레설레 저어지곤 했다.

그래서 C++ 이후에 등장한 더 깔끔한 언어인 D, C#, Java 등은 다중 상속을 지원하지 않는다. 그 대신 다중 상속을 우회하고 복잡도를 완화하기 위해, 적어도 가상 상속만은 할 필요가 없게끔 static 내지 가상 함수 선언만 잔뜩 들어있는 인터페이스에 대해서만 다중 상속을 허용하는 것이다. Java는 두 종류의 상속을 extends와 implements라고 아예 구분까지 했다.

물론 이런 패러다임 하에서는.. 프로그램 구조가 간단해서 가상 함수로 만들 필요가 없는 것까지 일단은 인터페이스부터 만들어 놓고 구현 클래스를 내부적으로 또 만드는 식의 오버헤드 정도는 감수해야 한다. 하지만 Java는 final이 아닌 함수는 기본적으로 몽땅 가상 함수일 정도로.. 디자인 이념이 애초에 성능 대신 극도의 유연성이니, 그 관점에서는 그건 별 상관이 없는가 보다.

가장 대중적인 기술이 알고 보면 레거시 때문에 굉장히 지저분하고 기괴하기도 하다는 것은 CPU계에서 x86이 그 예이고, 프로그래밍 언어에서는 C++이 해당되지 싶다. 전처리기(+생짜 파일 기반 인클루드), 다중 상속, 클로저 없이 특유의 pointer-to-member 기능 같은 것 말이다. 후대 언어에서는 저런 게 결코 도입되지 않고 있다.

본인은 다중 상속을 굳이 의도적으로 기피하면서 코딩을 하지는 않는다. 다중 상속이 필요하고 당장 편하겠다 싶으면 한 클래스에다 막 엮었다. 그 상태로 막 복잡한 pointer-to-member나 람다를 구사하면서 컴파일러를 변태적으로 괴롭히지는 않을 것이고, 컴파일러가 그냥 this 포인터 보정을 알아서 해 주는 것만 원했으니까 말이다.

하루는 ", public"라고 검색을 해서 날개셋 한글 입력기의 소스 코드 내부에도 혹시 다중 상속을 쓴 부분이 있나 찾아 봤는데.. 그래도 2017년 현재 날개셋 한글 입력기의 소스 코드에는 데이터 멤버가 존재하는 클래스를 둘 이상 동시에 상속받은 부분은 없었다. 추가적인 상속처럼 보이는 것은 COM 인터페이스 내지, 내가 콜백 함수를 대신해서 내부적으로 만들어 놓은 추상 클래스 인터페이스들이었다.

한두 번 썼을 법도 해 보이는데.. 이 정도 규모의 프로그램을 만드는 데도 실질적인 다중 상속을 사용한 부분이 없다면 그건.. 정말로 가성비 대비 불필요하게 지원할 필요는 없을 법도 해 보인다.

Posted by 사무엘

2017/12/26 08:37 2017/12/26 08:37
, ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1441

1. 1공 시절

우리나라 헌정 체제의 변천사에 대해서는 본인이 이 블로그에서 몇 차례 글로 다룬 적이 있었다.
초대 대통령인 할배가 집권했던 최초의 1공화국 시절은.. 지금으로서는 뭐랄까 같은 나라라는 생각이 들지 않을 정도로 이질감이 심하다. 대체역사물 소설에서나 나올 것 같은 그런 나라이다. 태극기, 한국어, 한글만 없다면 말이다.

이때 대통령은 생전에 군대의 근처에도 안 가 본 문돌이였고 군사 정권도 분명 아니었지만, 가난한 여건에다 극렬 반공 트렌드 때문에 나라가 막 자유롭다고는 보기 어려운 분위기였다. 그리고..

  • 지금과 같은 화폐 단위가 도입되고 마지막으로 화폐 개혁을 한 게 1962년,
  • 군대에 상병과 병장 계급이 추가된 게 1962년,
  • 공문서에서 서기 연호만 쓰기 시작한 게 1962년(더 옛날의 이 승만 시절 관보나 대한뉴스, 각종 법조문에서는 4천 몇백 년 하면서 단기 연호가 나온다~!)
  • 마지막으로 탈영병을 사면해 준 게 1963년
  • 부산이 전국 최초의 직할시로 승격된 게 1963년
  • 국가 차원에서 독립 유공자를 본격적으로 발굴해서 훈장을 추서한 게 1962년...

당장 떠오른 예만 나열해도 이 정도이니 지금의 우리나라 기틀이 상당수 다져진 건 확실히 박통 때부터라는 건 부인하기 어려워 보인다.
(그나저나, 대통령 관저의 이름이 경무대에서 청와대로 바뀐 건 박통보다 미묘하게 전인 윤 보선 때 1961년..)

해방 이후 1962년 이전에 우리나라는 6· 25 전쟁을 전후한 1950년 8월과 1953년 2월에 화폐 개혁을 시행했다. 1950년이야.. 개전 직후 서울이 털리고 한국 은행에 보관돼 있던 현찰 뭉치들이 괴뢰군에게 통째로 노획돼 버렸기 때문에 그 돈은 당연히 국가 차원에서 무효화하고 유통을 금지시켜야 했다. 수능 문제지가 시험 전날에 외부로 유출된 것과 얼추 비슷한 상황이다. 새로 만든 돈은 부득이 일본에서 인쇄해서 수입해 와야 했다.

그 뒤 1953년의 화폐 개혁은 단위도 '환'으로 바뀌어서 인플레이션을 수습하는 용도로 쓰이다가, 훗날 1962년에 단위가 또 바뀌어 지금의 '원'이 정착했다. 개드립을 좀 치자면, 환에서 원으로 '환원'됐다.

할배 각하는 기본적으로야 크리스천이었지만, 자기 치적에 대한 자랑질도 했다. 남산과 탑골공원에 크고 아름다운 자기 동상을 세우고, 남한산성 근처 도로를 닦고는 자기 호를 따서 '우남로'라는 이름을 붙였다(지금은 헌릉로와 합쳐져서 없어짐). 1957년부터 하야 직전의 60년까지는 황금연휴 부근도 아닌 대통령 탄신일(3월 26일)을 임시공휴일로 지정하기도 했다.
이 승만은 양력 기준 1875년 5월 1일생인데, 이 날짜가 그 당시 음력으로는 3월 26일이었던 것이다. 임시 공휴일은 그냥 일관되게 매년 양력 3월 26일에 시행되었다.

그리고 할배는 생일을 기리는 것으로도 모자라서, '환' 지폐에다 한복 차림의 자기 초상화를 집어넣었다(100, 500환). 처음엔 정중앙에다 집어넣었는데 지갑에 돈을 넣을 때 자기 얼굴이 접힌다는 걸 발견하고는 한쪽 끝으로 위치도 옮겼다. (그런데 소리만 '환'이지, 이때도 한자 표기는 여전히 '원'이네..?)

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

요즘 우리나라 지폐가 온통 조선 시대 '이씨' 인물만 너무 많이 집어넣었다는 비판이 있는데, 사실 우리나라는 먼 옛날에 대한민국 인물, 그것도 시퍼렇게 살아 있는 인물을 집어넣은 적이 딱 한 번 있었던 셈이다. 전무후무 1공 시절에 말이다. 지폐에다 자기 얼굴을 떡 집어넣는 건, 나중에 군인 출신 대통령도 하지 않은 짓인걸.. 반쯤은 자기 자발적인 지시이고, 반은 부하들이 알아서 아부질 하는 걸 본인도 듣기 싫지는 않고 적극적으로 저지하지 않아서 그렇게 된 거지 싶다. 대통령과 왕의 차이점에 대한 관념도 아직 드물던 시절이기도 했으니..

제1공화국 시절엔 남한 땅에서 미국처럼 서머타임(일광 시간 절약)이 시행되기도 했다. 미국이 단위 체계와 전압처럼 세계 규격과 달리 혼자 따로 노는 관행 중 하나인데.. 1960년대 박통 때부터는 폐지됐다. 그 서머 타임은 훗날 서울 올림픽을 하던 시절에 또 잠깐 부활했다가, 올림픽이 끝난 뒤부터는 다시 영구 봉인됐다.

2. 부산 잔혹사

우리나라 광역시들 중 대전은 공항이 없고(대전 대신 청주에..), 울산은 지하철이 없다. 꽤 흥미로운 사실이다.
대전은 포항· 울산 같은 네임드급 공장이 없는 대신(산업단지 자체가 없는 건 아님. 대덕구 대화동에..), 정부 청사와 각종 과학 연구소들이 있어서 고급스러운 느낌이 나는데.. 1공화국 얘기가 나왔으니 그 시절에 특정 지역과 관련해서 기억나는 아이템을 하나 더 늘어놓아 보겠다.

부산은 앞서 언급했듯이 1960년대에 전국에서 제일 먼저 직할시로 승격됐으며, 서울· 평양과 더불어 한반도에 노면전차가 다닌 세 도시 중 하나이다.
6· 25 때 북괴에 점령당하거나 대판 전투가 치러진 이력이 없고, 오히려 안전한 최후방인 덕분에 임시 수도 본진 역할을 한 적도 있다.
하지만 부산은 전쟁과 지진이 없는 대신, 피난민 목조 판잣집들이 밀집해 있던 와중에 화재 참화를 여러 번 겪었다.

1953년 1월 30일엔 영화로도 나왔던 국제시장에서 대화재가 나서 수천 채에 달하는 상가와 판짓집들이 다 타 버렸다. 하지만 이건 나중에 또 벌어졌던 화재들에 비하면 피해 규모가 약과였다.

사용자 삽입 이미지

1953년 11월 27일, 전쟁이 끝난 지 정확히 3개월 뒤엔 또 판자촌에서 화재가 발생한 것이 시내 중심부로까지 번져서 부산 역, 방송국, 신문사까지 몽땅 불에 탔다. 이 때문에 부산 역이 철거되고, 오리지널 부산 역보다 1km 남짓 북쪽에 있던 초량 역이 지금의 부산 역 역할을 하게 됐다.

사용자 삽입 이미지

1954년 12월 10일과 26일에는 또 두 차례 대형 화재가 용두산 언덕 일대를 덮쳤다. 판잣집들 피해야 말할 것도 없고, 이번엔 휴전 뒤에도 귀차니즘에 입각하여 서울로 아직 안 옮기고 부산의 모 창고에 보관해 놓고 있던 조선시대 어진과 유물, 문화재들 수천 점이 소실돼 버렸다.
국제시장, 부산역, 용두산 등등.. 다 비슷비슷한 지역이다. 열악한 닭장 같은 곳에서 살다 불 한번 나면 이렇게 작살난다는 걸 알 수 있다.

그러다가 5년 뒤에 1959년에는 땅, 불 다음으로 바람과 물 차례였다(이젠 '마음'만 남았나?-_-). 14호 태풍 사라 때문에 일대가 또 박살이 났으니, 1950년대에 부산은 제2의 서울임에도 불구하고 살기가 참 잔혹한 곳이었지 싶다.

3. 1960년, 1980년의 올림픽

미국에서는 케네디 대통령과 링컨 대통령의 공통점 뭐 이런 괴담이 나돌았고, 또 1840년부터 1960년까지 20의 배수 년도에 당선됐던 대통령은 제 명에 못 살고 병사· 암살로 최후를 맞이했다는 일명 '테쿰세의 저주' 괴담이 나돌곤 했다.
우리나라는 해방 후 대한민국으로서의 역사는 아주 짧으며 정치가 아닌 스포츠 분야이긴 하다만, 20의 배수 년도에 참가했던 올림픽이 좀 뭔가 특이했다.

우리나라는 그 가난하고 열악했던 1948년 런던 올림픽 첫 참가 때, 그리고 전쟁으로 혼란스럽던 1952년도 올림픽에서도 복싱과 역도에서 메달을 따 오곤 했다. 그런데 1960년 로마 올림픽에서는 어찌 된 일인지 현재까지 전무후무하게 메달을 단 하나도 못 따는 부진을 보였다. 이 때문에 올림픽 선수단 대표이던 손 기정 단장은 삭발을 하고 귀국했다.

1960년대에는 국제 대회에 선수를 선발하고 육성하는 스포츠 행정 체계가 굉장히 미개하고 막장이었던 듯하다. 밥그릇 싸움과 부정부패는 말할 것도 없고.. 이 때문에 뉴스 기사를 찾아보면 손 기정은 1966년 방콕 아시안 게임 때도 선수단 단장이었는데, 이때는 나름 성적이 좋았음에도 불구하고 또 뭔가 심하게 마음에 안 드는 게 있어서 삭발 귀국을 단행했던 듯하다.

게다가 로마 다음 1964년 도쿄 올림픽에서도.. 나름 가까운 이웃 나라에서 열리는 올림픽이라고 대대적으로 선수들을 파견한 것에 비해서 우리나라의 성적은 꽤 부진했다. 이래서는 안 되겠다는 생각 하에 박 정희 정권은 어수선한 분위기를 수습하고 스포츠 단체들을 통합하고 태릉 선수촌도 만들면서 엘리트 체육의 육성에 힘썼다.

지금 괴수들이 우글거리고 한국인 코치가 세계 곳곳에 활동하는 지경이 된 양궁조차도 처음부터 지금 같은 인프라가 갖춰진 게 절대 아니라는 점이 아주 흥미롭다. 우리나라가 건국 이후 최초로 메달을 딴 분야는 역도와 복싱이지 양궁이 아니지 않던가??

뭐, 1960년대는 그렇다 치고 그로부터 20년 뒤, 1980년 모스크바 올림픽은.. 짐작하다시피 우리나라가 애초에 보이콧을 해 버리고 참가를 안 했기 때문에 메달도 없다. 그런데 우리나라와 일본은 그렇다 치더라도 공산권 국가인 중국조차도 참가를 안 했다는 게 흥미롭다. 공산주의 사회주의라고 해서 반드시 친소 성향은 아니니까..
세월의 변화를 느낀다만, 이것 때문에 우리나라 여자 양궁의 초창기 멤버이던 김 진호 선수가 커리어에서 큰 손해를 봐야 했다.
2000년대부터는 1960, 1980 같은 굴곡이나 이변이 아마 더는 없을 것이다.

4. 국민투표

민주주의 사회에서 투표라 하면 대통령, 국회의원 같은 어떤 대표자를 뽑는 선거만 생각하기 쉬운데, 사실은 국가적으로 어떤 중대한 결정을 내릴 일이 있을 때 투표를 통해 yes/no를 묻는 제도도 있다(우리나라 헌법 제72조). 이를 '국민투표'라고 한다. 마치 논문이라고 해서 학위 청구용 졸업 논문만 있는 게 아니라 학술지 논문도 있고 발표 논문도 있듯이, 투표란 것도 그렇게 성격에 따른 구분이 있는 것 같다.

보통은 이런 의사 결정을 국민이 아닌 의회를 통해서 간접적으로 하게 돼 있으나, 국민투표를 통해 국민의 의견을 직접 묻는 예외적인 제도도 대통령이 자기 재량껏 시행할 수 있다. 투표 결과가 대통령이 의도하는 방향으로 나왔다면 이건 강력한 설득력을 얻게 되니 의회도 어찌하기가 난감할 것이다.

국민투표는 보통은 헌법을 고쳐야 할 때 시행되곤 했으며, 투표일은 임시공휴일로 지정되곤 했다. 이 승만 때는 시행된 적이 없고 1960년대의 군사 정권 시절이 원조이다. 우리나라는 1987년 10월, 제6공화국 수립을 위한 개헌을 앞두고 시행한 것이 마지막이었다. 북괴의 붕괴와 흡수 통일과 같은 급의 이변이 없는 한, 현 헌정 체제에서는 앞으로도 할 일이 없는 게 좋을 것이다.

5. 대통령의 초법적 권한: 계엄과 긴급명령

자고로 대통령은 왕이 아닌 관계로, 자기 멋대로 기분대로 "짐이 곧 법이다" 식으로 통치할 수 없다. 특히 무엇보다도 혼자 평생 그 자리에 있을 수 없으며, 자기 자식에게 권좌를 슬쩍 넘겨줄 수도 없다. 현대의 대통령은 국가 원수라는 지위와 예우는 동일하지만, 권한의 행사 범위는 법의 통제를 받으며, 전근대 시절의 왕에 비해 큰 제약이 걸려 있다.

그럼에도 불구하고 대통령은 전쟁을 포함한 굉장히 긴박하고 불가피한 상황일 때 예외적으로 일시적으로 법과 권한, 의회의 동의 같은 절차를 씹어먹고 명령을 내릴 수 있다. 그 정도는 이미 법에 보장돼 있다.
대표적인 예는 계엄이다. 계엄은 나라 사정을 준전시 상태로 만들어서 바싹 긴장시키고, 국민의 기본 자유와 권리를 일부 제한하는 조치이다.

우리나라에서는 건국 이래로 1948년 여순 반란(여수· 순천 일대)과 4· 3 사건(제주도)을 시작으로 제일 최근에는 1979년의 부마 항쟁(부산· 경남)과 10· 26 사건 때 계엄이 내려졌으며, 전땅크의 쿠데타의 정점인 1980년 5월 17일 내란 때 또 계엄이 내려진 것이 "마지막"이다. 마지막 두 계엄은 제주도를 제외한 전국에 내려졌었다.
뭐, 4· 19 혁명(의거), 5. 16 쿠데타(군사 혁명), 10월 유신 같은 크리티컬한 이벤트 때는 제주도까지 포함한 전국에 계엄크리가 떨어지기도 했었다.

계엄 다음으로 현행 헌법 제76조에 의거한 '긴급명령'이란 게 있다. 이건 건국 이래로 지금까지 총 16번이 내려졌는데, 그 중 13회가 6· 25 전쟁 기간 중에 내려졌다. 전시의 마지막 명령인 제13호는 1953년 2월, 100원을 1환으로 바꾸는 화폐 개혁 지시였다.
대부분의 역대 긴급명령들은 관련법이 따로 제정됨으로써 폐지되었다. 우리나라에 현재까지 마지막으로 내려진 긴급명령은 1993년 8월, 금융실명제를 빵 터뜨려 실시한 김 영삼 대통령의 명령이었다.

박 정희는 긴급명령을 제3공의 말기에 단 한 번밖에 내리지 않았으며(제15호, 1972. 8. 2.), 이것도 계엄과는 달리 정치 분야는 아니었다. 그 대신 이 양반이 특별히 고안해서 1974년부터 75년, 4공 유신 시절에 1년 반 남짓 동안 무려 아홉 번이나 남발했던 더 강한 특별 명령은 바로 '긴급조치'였다.
"대한민국 헌법을 부정, 반대, 왜곡 또는 비방하는 일체의 행위를 금한다."로 시작하는 게 제1호였고, 제9호가 가장 길었다. 이전의 긴급조치를 해제한다는 명령도 별도의 긴급조치 호수로 올라가곤 했다.

대부분의 긴급조치들은 사실상 빨갱이들, 데모질 하는 애들을 잡아서 벌 준다는 협박이었지만, 딱 하나 제3호만은 민생과 관련된 다소 생뚱맞은 긴급조치였다. 긴급조치는 박통이 암살당하고 헌법이 업데이트 되면서 즉시 역사 속으로 사라졌다.
국민투표 내력, 개헌 내력처럼 계엄과 긴급명령(/조치) 내력도 살펴보는 게 재미있다. 이런 게 사회 공부의 묘미이다.

Posted by 사무엘

2017/12/23 08:36 2017/12/23 08:36
, ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1440

컴퓨터 프로그램의 GUI 구성요소들 중에는 여러 아이템들을 한데 나열하는 리스트 박스(list box)라는 게 있고, 고정된 한 문장에 대해서 예/아니요, 참/거짓 여부를 지정하는 체크 박스(check box)라는 게 있다.

체크 박스는 프로그램이 고정 붙박이 형태로 제공하는 기능이나 옵션 하나에 대한 설정을 할 수 있다. 그리고 리스트 박스는 보통은 가변적인 개수의 항목들 중에 하나를 선택할 때 쓰인다.
그런데 가끔은 이 두 물건의 기능을 한데 합치고 싶은 상황이 생긴다. 리스트 박스의 각 아이템들에 대해서 1비트짜리 정보를 배당해서 선택 여부를 지정하는 것 말이다.

뭐, Windows의 리스트박스 컨트롤은 모든 아이템들에 대해서 1비트도 아니고 그냥 machine word 크기 하나로 custom 정보 data를 지정하는 기능이 있다. 또한 필요하다면 하나가 아닌 복수 개 multi-selection 모드로 동작하게 할 수 있고, 각 아이템에 대한 custom drawing도 가능하다.

하지만 딱 부러지게 아이템들 앞에 자동으로 운영체제의 check box 그림을 그려 주고 체크 박스의 리스트를 구현하는 기능 자체는 없다. 필요하면 사용자가 그걸 직접 구현해서 쓰게 여건만 만들어 놨을 뿐이다.
그래서 MFC의 경우 기존 리스트박스를 서브클래스 해서 CCheckListBox라는 걸 제공한다. owner drawing만 구현하는 것으로는 충분치 않고, space를 누른 키보드 입력과 check 버튼 주위를 누른 마우스 클릭도 감지하게 메시지 몇 개를 서브클래스 했다.

자고로 화면에 뭔가 길다란 리스트를 만들고 아이템들을 복수 선택할 수 있게 해 놓은 프로그램의 원조는 PC-Tools나 MDIR, Norton Commander, 심지어 Windows 3.x의 파일 관리자 같은 파일 관리 유틸리티이지 싶다. 복수 개의 파일을 복사하거나 삭제하는 기능을 제공해야 하니 리스트의 복수 선택 기능이 무조건 필수이기 때문이다.

그런데, selection이라는 것과 highlight 선택막대의 관계를 어떻게 보느냐에 따라서 프로그램의 동작이 달라지곤 했다. 도스용 프로그램들은 selection과 선택막대가 서로 따로 논다고 본 반면, Windows는 selection이 곧 선택막대의 연장선이라고 봤다.

그래서 Windows의 리스트박스는 화살표 키를 누르는 순간 기존 selection들이 다 사라지면서 선택막대가 움직이곤 했다. Shift+화살표로 연속된 영역을 한꺼번에 선택하는 것 말고 불연속적인 영역을 취사선택하려면 Shift+F8부터 눌러서 선택막대가 아닌 포커스 테두리가 깜빡거리는 상태로 들어간 뒤, 포커스 테두리만 움직이면서 Space로 아이템들을 선택하면 됐다.

굉장히 특이한 동작인데 Windows에서는 이게 기본이다. 기본적으로 포커스 테두리만 움직이게 하는 모드는 extended 플래그(LBS_EXTENDEDSEL)로 따로 있었다.
그에 비해 평소에는 선택막대와 selection이 다같이 움직이고 Ctrl+화살표로 포커스 테두리를 움직여서 Space로 선택하는 비교적 '직관적인 방법'은 훗날 리스트뷰 컨트롤이 도입하게 된다. 아이템을 복수 선택하는 방식은 이 두 컨트롤이 서로 호환되지 않는다.

또한, 각 아이템들에 대해 체크 플래그를 지원하는 건 아이템을 그냥 복수 선택할 수 있게 하는 것과는 UI의 관점이 다르다. 비록 내부적으로 본질적으로는 아이템별로 1비트짜리 boolean 정보를 지정한다는 점에서는 차이가 없겠지만 용도가 같지 않다는 것이다.

복수 선택은 대체로 아이템들이 진짜 가변적이고 사용자에 의해 아이템을 추가하거나 삭제까지 할 수 있는 상황에서 쓰이겠지만 체크 리스트는 그렇지 않은 경우가 대부분이다. 단순히 응용 프로그램이 제공하는 기능과 옵션이 많기 때문에 리스트 형태로 만들었을 뿐이다. 체크 리스트는 복수 선택과 달리, 선택 막대 selection과는 완전히 별개로 관리되기도 해야 할 것이고 말이다.

다음은 MFC의 CCheckListBox를 사용했던 먼 옛날 날개셋 한글 입력기 1.x의 옵션 대화상자이다.
Windows XP부터는 테마도 등장했기 때문에 지금 상황에 따라 체크 박스를 그리는 방법 역시 더 복잡해졌다.

사용자 삽입 이미지

다음은 리스트 박스가 아니라 무려 트리 컨트롤(공용 컨트롤)을 사용했던 날개셋 2.x의 옵션 대화상자의 모습이다.
Internet Explorer가 4인가 5에서부터 인터넷 고급 옵션들을 이렇게 트리 컨트롤로 구현해서 오늘날 최후의 11 버전에까지 이어져 오고 있다. 지원하는 옵션이 너무 많기 때문이다. 본인 역시 이 스타일을 따라해 보았다.

사용자 삽입 이미지

공용 컨트롤들은 owner-draw 안 쓰고도 자체적으로 아이템별 비트맵을 지정할 수 있으며, 더구나 트리 컨트롤은 아이템들을 카테고리별로 분류도 할 수 있으니 더욱 좋다.
날개셋 3과 그 이후부터는 이들 옵션이 상당수가 오토마타와 글쇠의 수식, 별도의 카테고리 옵션 등으로 떨어져나간 관계로, 저렇게 트리 컨트롤까지 써야 할 정도로 긴 옵션 리스트를 만들 일이 없어졌다.

사실, 트리 컨트롤은 IE 4 타이밍에서 TVS_CHECKBOXES라는 스타일이 추가되기도 했다. 기존 이미지 스타일을 활용하는 게 아니라 그건 놔두고 옆에 체크 박스를 별도로 추가해 주는 형태이다.

트리 컨트롤에서 체크 박스는 설치 프로그램에서 어떤 소프트웨어 제품의 구성요소들을 계층 구조로 나열한 뒤 설치· 제거할 부분을 선택받는 부분에서 유용하게 쓰일 듯하다. 이런 데서는 자식 노드가 하나라도 선택되면 부모 노드들은 중간 상태로 바뀌고, 부모 노드를 선택하거나 해제하면 자식들도 한꺼번에 선택이나 해제되는 동작이 필요할 것이다.

하지만 트리 컨트롤의 체크박스 기능은 깔끔하게 구현되지 않아서 잡음이 많다. 스타일을 윈도우를 생성한 뒤에 SetWindowLongPtr로 런타임 때, 그리고 아이템을 하나라도 추가하기 전에 적절한 타이밍에만 지정할 수 있다.
레이먼드 챈 아저씨는 저건 차라리 스타일이 아니라 메시지 형태로 구현하는 게 더 나았을 정도라면서 API 설계 구조를 비판한 바 있다. (☞ 링크) 실제로 콤보 박스의 extended UI 여부는 스타일이 적절해 보임에도 불구하고 덩그러니 CB_SETEXTENDEDUI라는 메시지를 통해 지정하게 돼 있다.

한편, 트리 컨트롤은 처음 도입됐을 때부터 지금까지 체크 박스와는 달리, '복수 선택'은 지원하지 않고 있는 것으로 유명하다. 리스트뷰 컨트롤처럼 아이콘을 Shift 및 Ctrl을 이용하여 복수 선택할 수 있지 않다는 뜻이다.
Windows 운영체제는 탐색기에서 볼 수 있듯이, UI 디자인 철학이 "트리로는 분야를 하나 선택만 하고", "리스트에다가 그 분야에 속하는 아이템들을 출력한 뒤 복수 선택해서 지지고 볶는다" 형태이긴 했다.

계층 구조를 나타낼 수 있는 복잡한 UI 컨트롤에서 복수 선택까지 가능하면 프로그램의 기능이 매우 복잡해지며, 리스트도 아니고 트리 컨트롤이 굳이 복수 선택까지 가능해야 할 일은 매우 드문 것도 사실이다.
하지만 그럼에도 불구하고 당장 Visual Studio IDE부터가 클래스· 리소스· 솔루션 뷰의 트리 목록이 진작부터 복수 선택을 지원한다. 걔들은 4.0 시절부터 공용 컨트롤 없이 진작부터 자체 구현 트리 컨트롤을 써 왔기 때문이다.

끝으로, 체크와 다중 선택을 짬뽕한 듯한 기괴한 UI가 Windows의 역사상 단 한 번, 8의 리스트뷰 컨트롤에서 잠시 등장한 적이 있었다.
아이템의 좌측 상단 같은 특정 부위를 마우스로 가리키고 있으면 체크 박스가 나타나고, 그걸 클릭하면 아이템을 복수 선택할 수 있었던 것이다.
보통 아이템을 클릭하면 기존 selection들은 다 없어지고 그것'만' 선택되곤 하는데, 체크 박스를 선택하면 기존 selection들을 놔두고 그걸 추가로 선택할 수 있었다.

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

그 당시엔 아마 터치 장치를 염두에 두고.. Ctrl/Shift+클릭이나 드래그 없이 클릭만으로도 아이템들을 복수 선택할 수 있게 고심 끝에 저런 기능을 넣었던 듯하다.
하지만 반응이 좋지 않았는지, 이런 기능은 내 기억이 맞다면 Windows 8.1에서 곧장 없어졌고 다시 등장하지 않았다. 하긴, Windows 8은 저 정도면 약과이지, 아예 시작 버튼을 없애 버렸을 정도로 엄청 과격한 모험을 한 물건이기도 했으니까.

이렇듯, 리스트 박스, 리스트뷰 컨트롤, 트리 컨트롤을 두고 아이템의 복수 선택 및 체크 선택과 관련하여 할 말이 무척 많은 걸 알 수 있다. 복수 선택은 단수 선택만치 일상적으로 자주 쓰이는 기능은 아닐 뿐더러 어떤 방식으로 구현할지 동작의 customization의 폭도 넓은 편이다. 그래서 운영체제의 GUI가 곧장 직통으로 지원하지 않고 구현을 사용자에게 맡기는 편이었던 것 같다.

Posted by 사무엘

2017/12/20 08:36 2017/12/20 08:36
, ,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1439

1.
과거 2010년대 초에는 제로보드 4를 쓰지 말자, IE6을 쓰지 말자, ActiveX를 퇴출시키자 이런 운동이 벌어졌다. 그때는 같은 PC 안에서 Windows에 종속되지 말고 맥, 리눅스까지 잘 지원하는 웹 표준을 지키자는 게 아젠다였다.

그러다가 2010년대 중반부터는 구시대 관행들이 추가적으로 없어지는 게 눈에 띈다. 웹 상으로 주민 등록 번호 13자리 전체를 수집하는 게 금지되었으며, 기술적으로는 영원불변할 것만 같던 플래시마저 웹에서 퇴출 수순을 밟고 있다. 이건 PC 운영체제 간의 연동이 아니라, PC와 모바일이라는 상이한 플랫폼 간의 연동이 아젠다이다. (플래시 없이 현란한 광고 애니메이션은 어째 만드나 싶다.)

사실, 기술과 이론만 따지자면야 모바일에서도 플래시를 지원하지 못할 이유는 없다. 그러나 플래시는 근본적으로 현란한 벡터 애니메이션을 출력하려고 만들어진 물건이니 설계 이념이 딱히 화면 작고 전력 소비에 민감한 모바일과는 친화적이지 않다. 기기와 무관한 접근성의 보장이라는 웹 표준과도 어울리지 않는다.

더구나 플래시도 따지고 보면 그 본질은 3rd-party plug in이고 IE의 용어로 표현하자면 ActiveX의 일종이긴 했다. 플래시를 집어넣을 때 쓰는 태그가 여느 ActiveX 컨트롤을 집어넣을 때 사용하는 태그와 다를 바 없다. 다만, 얘는 독보적으로 너무 유명하고 널리 쓰이다 보니 타 ActiveX와는 지위가 다른 예외적인 물건으로 취급되어 왔을 뿐이다.

그러니, 좀 웹 표준을 어겨도 PC에서는 큰 문제가 되지 않던 것이 완전히 차원이 다른 컴퓨팅 환경인 모바일에서는 더욱 부각되게 되었다. 거기에다 보안 문제도 불거지고, 또 모종의 이유로 인해 아이폰 제조사인 애플과 플래시의 제조사인 어도비가 사이가 나빠지는 악재까지 겹치면서 플래시는 인터넷에서 퇴물로 전락했다. 급속도로 몰락의 길을 가게 됐다.

플래시가 독자적으로 제공하던 고급 기능들은 그냥 웹브라우저가 직통으로 지원하는 HTML5 표준으로 몽땅 이동했다. 인터랙티브하게 싹 나타났다가 사라지는 웹사이트 메뉴, 인터랙티브한 게임, 간단한 이미지 편집 등등이 몽땅 말이다.
Chrome 브라우저의 경우 플래시는 자동 실행은 개뿔 물 건너 갔으며, 사용자가 수동으로 켜 줘야만 실행되는 legacy가 됐다. 음.. 예전에 흑역사로 사라졌던 MS Office의 길잡이를 보는 듯한 느낌이다. 웹 환경이 이렇게 변할 줄이야..

2.
인터넷 IPv4 주소 고갈과 주소 할당 중단은(이미 2011년의 일임!) 마치 유니코드에서 BMP 영역의 고갈과 비슷한 성격의 현상 같다.
결국 요즘 사람들은 대부분 공유기를 사용해서 인터넷을 하고 고정 IP라는 개념이 사실상 없어졌는데,
공인 IP와 사설 IP가 따로 노는 것 때문에 계층이 좀 헷갈리고 복잡해지고 골치 아파진 것도 있다. 이건 마치 분당선 서현 역이 지하철 출구 번호(안)와 백화점 출구 번호(밖)가 서로 완전히 따로 놀아서 위치 식별이 어려운 것과 비슷한 양상이다.

초기에 설계되었던 공인 IP 주소 영역들을 보면 class A~C 이런 거 말고도 공유기를 위한 영역을 따로 떼어 놓은 게 있는데.. 이게 유니코드로 치면 UTF-16에 존재하는 surrogate와 개념상 정확하게 일치한다. (처음엔 유니코드에 UCS2만 있었지 UTF-16 같은 게 있지는 않았듯이, IP 주소도 처음부터 공유기 영역에 있지는 않았었다.)
아니, 애초에 유니코드가 없던 시절에 지원 글자 수를 늘리려고 사용하던 multibyte, lead byte, tail byte 따위와도 비슷한 개념이라 볼 수 있다.
또는 16비트 시절의 far pointer하고도 비슷하고 말이다.

결국 32비트, 64비트, IPv6처럼 본질적으로 더 우월하고 넉넉하고 나은 것, 완전한 것이 오기 전에 컴퓨터에서 불완전한 것으로 임시땜빵을 하는 방법은 분야를 불문하고 방법론이 다 비슷해 보인다~!

3.
예전에 PC에서는 ICQ, MSN, 그리고 국내 한정으로 네이트온 같은 온라인 메신저가 있었다. 얘들은 시대가 시대이다 보니 PC 전용이었는데, 2010년대 들어서는 다들 망하고 스카이프만이 MS에 인수되어 살아 있는 듯하다.
2010년대에는 카카오톡이 스마트폰 앱과 PC 통합으로 메신저 시장을 사실상 평정했다. PC는 사람이 기계가 있는 곳으로 가서 기계의 전원을 넣어야만 쓸 수 있는 반면, 스마트폰은 365일 24시간 내내 켜져 있으며 사람이 늘 들고 다닌다. 이런 결정적인 차이로 인해 카카오톡은 과거의 메신저와는 달리, 자기 상태를 표시하는 기능이 없다~! (available, away, out to lunch 같은)

카카오톡은 PC용이 있기 때문에 PC와 모바일을 지원한다.
한편, SNS 웹사이트로 출발한 페이스북도 메신저 기능이 있으니, 모바일과 '웹'을 지원하는 셈이다.
예전에 잠시 있었던 Google Talk은 PC용 프로그램, 모바일용 앱에다가 gmail 같은 Google 계열 사이트에서 실시간 대화도 지원하여 드물게 PC, 모바일, 웹을 모두 커버했던 걸로 기억한다.
이렇게 애플리케이션들이 실행 양상이 다양해지고 있는 게 흥미롭다.

그리고 2010년대부터는 웹 자체도 사용자 상호작용과 반응성이 워낙 좋아진 관계로 PC용 네이티브 프로그램까지는 몰라도 모바일 앱의 정체성을 크게 위협하고 있다..
물론 기기의 물리적인 기능에 아주 특화된 기능이라든가 방대한 게임 같은 건 모바일 기기에서 직통으로 돌아가는 프로그램이 필요하겠지만, 단순 서버와의 교신과 정보 공유, 조회, 열람이 목적이면 웹 페이지와 자바스크립트 자체를 그냥 기계와 운영체제를 초월한 통합 GUI 플랫폼으로 쓰지 말라는 법이 없게 되는 셈이다.

순수 웹 애플리케이션은 서버 주소만 알려주면 앱스토어 심사 같은 것도 필요 없고 곧장 배포가 가능하다. 웹 전체를 검열하는 빅 브라더 같은 건 세상에 존재하지 않으니 말이다.
그러나 웹을 기반으로 안드로이드와 iOS를 모두 통합하고, 부분적으로 각 모바일 플랫폼에 종속적인 코드를 끌어다 쓸 수 있는 형태인 '하이브리드' 앱이 있다. 그리고 그런 걸 만들어 주는 프레임워크도 있다. qt가 PC에서 Windows/리눅스/macOS 통합이라면, 아이오닉 같은 모바일 프레임워크는 안드로이드/iOS 통합인 셈이다.

'아이오닉'은 하이브리드 자동차의 이름이기도 한데 컴퓨터에서도 나름 하이브리드 모바일 프레임워크의 이름이구나(비록 영어 철자는 차이가 있지만). 디스크와 드럼(브레이크 vs 메모리 기술), 엑셀(자동차 이름 vs 스프레드시트 이름)처럼 들린다.

4.
웹은 기계와 CPU 아키텍처에 구애받지 않는 정말 universal한 프로그래밍 환경이다. 그 누구도 처음에 상상하는 것조차 쉽지 않았다.
인터넷에서 다른 형태의 프로토콜로 제공되는 서비스들도 거의 다 웹이 몽땅 독식해 버렸다. 글과 그림과 하이퍼링크만 있는 문서에 불과하던 웹은 한 2, 30년쯤 전의 옛날 얘기이고, 지금은 이게 그냥 인터넷의 알파와 오메가요, 문서와 코드의 짬뽕인 광활한 프로그래밍 환경이다. 그러니 웹 프로그래밍을 하나 잘 공부해 놓으면 그야말로 모든 기계에서 똑같은 결과가 나오는 프로그래밍 스킬을 얻게 된다.

웹이 그런 공룡 같은 거대한 환경으로 발전하는 과정에서 브라우저, 언어 등 각종 규격들이 찢어졌다가 표준화된 과정도 살펴보면 참으로 격세지감이 느껴지는 한편으로, 인간 사는 바닥은 어디든 다 정치와 밥그릇 싸움, 돈지랄이 있구나 하는 병맛스러움이 느껴진다.

HTML4의 지저분함을 참다못해 1990년대 말에 엄격한 XHTML이 제정되었지만, 결국 망하고 HTML5가 다시 옛날 관행 기반에서 제정된 건.. 1990년대 말에 IA64가 너무 과격한 변화를 추구하다가 망하고 기존 x86 호환성을 유지한 amd64로 64비트 컴퓨팅의 판도가 기운 것과 비슷해 보인다. 시기도 서로 비슷한 편이다.

또한 Windows 10이 2015년 가을에 나온 첫 판이 지금까지 그대로 유지되고 있는 게 절대 아니듯, HTML5도 보아하니 한번 정하고 영원히 고정이 아니라 찔끔찔끔 계속 뭔가 추가되고 있긴 한 모양이다. 그렇기 때문에 전통적인 ACID 테스트 말고 또 2017년 현재까지 만점을 받은 브라우저가 전혀 없는 다른 HTML5 점수 테스트 사이트도 있다.

한편으로 HTML4 이래로 무려 15년 가까이 뒤에야 HTML5가 제정되고 HTML이 급격히 발전하고 있는 건 C++98 내지 C++03 이후로 C++이 2000년대에 정체돼 있다가.. C++1x 이후로 C++이 함수형 패러다임도 받아들이고 네이티브 코드 생성 언어가 갑자기 약 빤 듯이 발전하고 있는 양상과 비슷해 보인다.

웹이 MS Office 문서라면 자바스크립트는 VBA 매크로와도 같은 물건이다. 그리고 내가 HTML, CSS, JS를 삼권분립과 비슷한 구도라고도 비유한 바 있다. 게임 개발에다 비유해도 기획자, 디자이너, 개발자에 착착 잘 대응하는 것 같다.
아 그래..! 옛날에는 이런 스크립트 자체가 단일화되지 않아서 HTML 주석 안에다가 스크립트 코드를 몰래 집어넣어야 했다. 마치 프레임만큼이나 "이 웹페이지를 제대로 표시하려면 자바스크립트를 지원하는 브라우저가 필요합니다" 이런 말이 출력되도록 참 기괴하게 HTML 문서를 작성했었다. 이거 도대체 언젯적 얘기냐..;;

또한, 웹 프로그래밍에 스크립트는 클라이언트 쪽만 있는 게 아니라 서버 쪽도 있다. 클라이언트는 처리가 빠른 대신 대외적으로 프로그램 소스 코드가 몽땅 공개돼야 한다. (뭐, 난독화는 가능하지만) 서버 쪽은 소스가 노출되지 않지만 데이터 입출력에 서버와 네트워크 트래픽을 감수해야 한다. 이것도 컴퓨터 한 대에서만 돌아가는 프로그램을 만들 때에는 고려할 필요가 없는 흥미로운 면모이다.

이런 와중에 마소는 20여 년 전 1990년대 중반에 Bob이라든가 MSN 이런 거 만들면서 좀 삽질을 했었다. Windows 95를 만들어서 개인용 PC의 운영체제는 자기 뜻대로 세계정복을 했지만, 인터넷까지 자기 서비스만으로 호락호락 세계를 정복할 수 있으리라 생각했던 건 큰 오판이었다. 그래서 잘 알다시피 IE를 수단과 방법을 가리지 않고 운영체제에다 끼워넣어서 웹 브라우저의 전면무료화 관행을 정착시켜 버리기도 했다. 하지만 IE 자체는 경쟁 브라우저와 모바일 환경 때문에 세계정복까지는 이루지 못했다.

또한 마소는 2000년대 말에 와서는 PC에 너무 안주하고 모바일 환경에 대해서도 대수롭지 않게 예상하다가 스마트폰 플랫폼의 주도권을 안드로이드와 iOS에 완전히 뺏겨 버렸다. 그 시기에 LG전자가 피처폰에 안주하다가 지금 같은 처지가 된 것과 비슷한 실수이다.
그런데 2000년대 중후반엔 나조차도 솔직히 말해 사고의 구조가 "그냥 디카 쓰면 되지 폰에다가 카메라를 왜 얹어?" 이러던 수준이었다. 어지간한 전문가라도 스마트폰이 이렇게 뜨고, 그 스마트폰 OS를 오픈소스로 전세계에 뿌려 버리는 괴수 용자 대인배가 등장할 거라고는 예상할 수 없었다.

즉, <미래로 가는 길> 같은 베스트셀러 책을 이미 1990년대 중반에 썼던 천하의 빌 게이츠조차도 웹과 모바일에 대한 전망이 다 적중하지는 못했다. 뭐, "손가락 끝으로 모든 정보를" 같은 큰 그림이야 물론 적중했지만, 그런 기술이 언제나 자기가 원하는 형태로 보급되고 마소 주도적으로 이뤄지지는 않았다는 것이다.

그나저나, IA64 하니까 떠오르는데.. 소프트웨어 업계에서는 2000년 가을쯤 Windows ME와 아래아한글 워디안도 비슷하게 세기말의 흑역사 삽질을 좀 했다는 공통점이 있다.

Posted by 사무엘

2017/12/17 08:31 2017/12/17 08:31
, , ,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1438

1. 비행기 외형과 동력의 간략한 변천 내력

(1) 옛날에 처음으로 등장한 동력 비행기는 날개가 두 겹으로 달린 복엽기 형태가 주류였다. 빈약한 엔진으로 양력을 최대한 만들기 위해서였다. 그러나 날개 형태는 단엽기로 곧 바뀌었으며, 오늘날은 복엽기는 일부 작은 경비행기에서나 볼 수 있다.

(2) 비행기는 랜딩기어의 접지 형태가 자동차로 치면 삼륜차(...!)에 가깝다. 뒤쪽에 삼각형의 두 꼭지점이 있는 형태가 일반적이지만(△), 옛날에는 전방에 삼각형의 두 꼭지점이 있는.. 일종의 역삼각형(▽) 형태의 비행기 디자인이 주류였다. 이런 비행기는 앞바퀴가 아니라 꼭지점이 하나만 있는 쪽인 뒷바퀴를 조향했으며, 아마 이륙 시에 양력을 더 크게 하기 위해, 땅에서 주기· 주행 중일 때는 기수가 위로 치켜세워진 형태이기도 했다. 오늘날 이런 비행기는 역시 일부 경비행기에서나 볼 수 있다.

(3) 비행기는 거의 1950년대 이전까지는 프로펠러기가 주류이다가 그 뒤부터 슬슬 프로펠러 대신 팬이나 다른 추진 기관이 달린 물건이 나온다. 그런데 프로펠러라고 해도 다 같은 엔진 기반이 아니었다.
동체의 전방에 프로펠러가 하나만 달려 있는 놈은 프로펠러를 자동차와 별 차이 없는 피스톤 왕복 또는 성형 엔진으로 돌렸다. 그렇기 때문에 엔진 소리도 자동차와 별 차이 없는 "털털털 부우웅~" 이런 식이었다.

그러나 양 날개에 총 2개나 4개씩 프로펠러가 달린 것은 '터보프롭' 엔진으로, 프로펠러를 돌려서 뒤로 배기가스를 분출하는 터빈 기반의 제트 엔진이다. 이제 "위이잉~ " 좀 공기 가르는 비행기다운 세련된(?) 소리가 들리지, 자동차 같은 엔진 소리는 나지 않는다. 오늘날 왕복 엔진 기반 단발 프로펠러기는 역시 소형 경비행기에서나 볼 수 있다.

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

소형 비행기 축에 드는 An-2 (12인승)와 DHC-6 트윈오터(19인승). 날개 형태(복엽/단엽), 랜딩기어 구성, 프로펠러 구조(성형 왕복/터보 프롭)가 모두 다른 재미있는 대조군이다. DHC-6의 경우, 미국 그랜드 캐년 관광용으로 쓰이는 기종이기도 하다.

그리고 굉장히 흥미로운 사실인데, 옛날에는 프로펠러가 뒤에 달린 비행기가 만들어진 적도 있다고 한다. 마치 선박처럼 말이다.
프로펠러가 뒤에 있어도 비행기가 나아가고 뜨는 것 자체는 얼마든지 가능하다. 그게 다른 방면에서 의미와 장점이 있었을지는 모르지만, 일단 비행기가 떠서 기수가 들릴 때 프로펠러가 땅과 부딪칠 위험이 크다.;; 그리고 굳이 꼭 그렇게 만들어질 필요가 없다 보니 사장되었다. 삼발기, 전방 엔진 버스 같은 레어템이 됐다.

2. 악천후

폭우나 폭설처럼 '물'을 동반한 통상적인 악천후뿐만 아니라, 물 없는 지나친 폭염도 교통수단들에게는 전반적으로 악재이다.
고온은 물질들의 열팽창과 밀도 감소를 야기하는데.. 이 때문에 자동차는 공기압이 부족한 대형차에서 타이어의 파열 사고를 야기할 수 있다. 이러면 자기 혼자만 운행 불가능해지는 게 아니라 타이어 파편이 다른 차에 튈 수 있고, 또 조향력의 상실로 인한 연쇄 사고의 위험이 커진다.

철도의 경우 레일이 과열된다. 팽창으로 인해 휘는 것은 요즘은 기술 개발로 인해 극복되어서 장대 레일까지 잘 돌아가고 있으니 괜찮다. 하지만 문제는 강도도 약해진다는 것. 기관총 같은 게 너무 과열된 상태로 격발이 계속되면 아예 총열이 휘어 버리고, 현지에서 정비 불가능한 정도의 심각한 손상을 입는 것과 같은 이치이다. 그래서 철도의 경우 스프링클러로 물을 주기적으로 뿌려서 레일을 식히기도 하고, 불가피하면 고속철이라도 주행 속도를 평소보다 낮춘다.

육상 교통수단과는 달리, 비행기는 이착륙 때를 제외하면 타이어와 지면의 접촉은 존재하지 않는다. 하지만 무더위로 인해 공기의 밀도가 감소하면 이는 양력의 부족으로 이어진다. 그래서 비행기는 평소보다 더 긴 활주로에서 더 빠르게 달려야 이륙이 가능해지는데, 공항(작은 지방 공항)과 비행기(무겁고 큰 중형 이상급 여객기..)가 드물게 이 조건을 충족하지 못하면 안전을 위해 어쩔 수 없이 결항된다.
비행기는 날개 위의 눈조차도 무게 이전에 양력 발생을 방해하기 때문에 반드시 싹 다 치우고 출발하는 교통수단이다. 그러니 무더위와 관련해서도 자신만의 독특한 사정이 있다.

선박은 폭풍우라면 모를까, 그래도 폭염의 영향을 받지는 않는 것 같다. 오히려, 육지가 폭염에 시달리는 중이어도 바다에는 언제나 시원한 바람이 가득하다.
물이나 바다가 싹 말라 버려서 배가 주저앉는 건 지구 멸망 급의 극단적인 천재지변일 테니..

3. 비상 탈출

자동차에는 안전벨트가 있고, 선박에는 구명조끼와 구명보트가 있다. 그나마 철도 차량만이 아무런 안전 장치가 없는 게 인상적이다.
비행기에는 안전벨트는 물론이고 구명조끼와 산소 마스크까지 있다. 구명조끼는 비행기가 바다나 강에 내렸을 때를 대비한 것이고, 산소 마스크는 비행기가 사람이 정상적으로 호흡하기 힘든 고고도에서 위험에 빠졌을 때를 대비한 것이다. 한 사람당 순항 고도에서 자연 호흡이 가능한 고도로 하강하는 데 걸리는 최대 시간만치만 산소가 준비돼 있다. (내가 알기로 대략 15분) 상승도 아니고 하강인데 이건 최대 시간 이내에는 반드시 달성 가능할 것이다.

갑자기 산소 마스크가 덜컥 내려왔다는 건 비행기가 비상 상황에 빠졌음을 뜻한다. 이때 독신 홀몸이라면 그나마 나 자신만 챙기면 되지만, 곁에 금쪽같은 처자식이 있더라도.. 일단은 "가장인 나 자신부터 마스크를 쓴 뒤에" 아직 방법을 모르는 어린애들에게 마스크를 씌워 주는 게 정석이다. 다른 애들을 챙겨 줘야 할 어른 본인이 먼저 기절해 버리면 안 되기 때문이다.
뭐랄까, 굳이 창조 진화 논쟁이 아니어도 성경의 법칙도 "닭이 먼저냐 계란이 먼저냐" 질문의 답은 언제나 단호하게 "닭이 먼저"인데, 그런 심상이 느껴진다.

비상 착륙을 하든 불시착을 하든 심지어 추락을 했든.. 어쨌든 공중에서 땅이나 물에 내려앉았다면 이제 비행기를 신속하게 빠져나가야 할 차례다.
선박이야 건물 수준의 대형화가 가능하니 논외로 하더라도, 오늘날은 버스와 열차에 이어 비행기까지도 모두 2층 차량· 기체가 개발돼 있다. 보잉 747은 조종석과 특실..만 2층이었지만 A380은 일반실까지 모두 2층이 존재한다.

하지만 20세기 중반에는 2층 여객기가 수요도 있고 기술적으로 문제도 없지만 한동안 출시되지 못한 적이 있었다.
몇 차례 추락 사고를 겪은 뒤부터는 비상시에 비상구를 개방하고 미끄럼틀을 깔아서 모든 승객을 90초 이내에 탈출시킬 수 있어야 한다는 국제 안전 규정이 추가됐는데, 2층 객실로는 이 조건을 구조적으로 도저히 충족시킬 수 없어 보였기 때문이다.

그래서 역사적으로 여객기는 1층을 유지하면서 승객을 더 많이 태우기 위해서 광동체가 먼저 개발되었다. 버스나 열차와는 달리 복도가 두 줄 있는 것 말이다. 보잉 747이 대표적인 예이다. 얘는 조종석과 특실(!!)만이 2층이다.
그래도 지금은 결국 2층짜리 비행기도 봉인이 풀리고 나오긴 했는데, 그 90초 탈출 한계를 어떻게 극복했나 모르겠다. 결국 배는 말할 것도 없고 자동차, 열차, 비행기에 모두 2층 차량/기체가 존재하게 됐다.

높은 비행기에서 승객을 0.1초라도 더 빨리 지면에 닿게 하려면 탈출용 슬라이드/미끄럼틀은 직선이 아니라 사이클로이드(최단 강하 곡선) 모양으로 만들어야 하겠다는 잡생각이 문득 든다.
어차피 이 슬라이드는 딱딱한 강체가 아니고, 비행기가 물에 내려앉은 경우 그대로 구명보트로도 쓰이니 현실적으로 그렇게 굽은 모양으로 만들 수는 없을 것이다.

추락해서 부서진 비행기는 어디서 연료가 새고 언제 폭발할지 모르기 때문에 모든 승객들이 절대적으로 신속하게 비행기 밖으로 빠져나갈 수 있어야 한다. 그렇기 때문에 항공사 승무원들은 깜깜한 비행기 세트장에서 임의의 엑스트라 승객들을 동원해서 탈출 모의 훈련도 실시하며, 이 상황에서는 "고갱님~ 5천원이십니다" 오글오글 서비스 모드가 아니라 강한 명령조와 반말까지 부득이하게 허용된다. "당신, 이쪽으로 빨리 나가!"처럼. 워낙 1분 1초가 급하기 때문이다.

사용자 삽입 이미지

실제로 "나가세요"보다 저런 반말이 승객들을 더 빨리 상황을 파악하고 정신 차리게 만들어서 더 신속한 탈출을 돕는다는 실험 결과가 있다. 조종석에서 기장과 부기장끼리나, 비상 상황에서 승객과 승무원끼리나 한국어 특유의 괴상한 높임법은 별로 효율적인 의사소통 모델이 아님을 보여주는 듯하다.

비상구 쪽에 앉아 있던 승객은 지금까지 다리 쭉 뻗으며 편하게 앉았던 대신, 이제부터는 법적으로 승무원들과 함께 다른 승객의 탈출을 같이 도와야 하는 의무가 부여된다. 그럴 능력이나 의사가 없는 승객에게는 애초부터 비상구 쪽 좌석이 아예 발권되지 않는다. 이건 타 교통수단에서는 찾기 힘든 관행인데, 요즘은 인터넷이 발달해서 항공 상식도 많이 알려졌기 때문에 알 만한 분들은 다 아실 것이다.

비상 탈출을 할 때는 짐도 어지간히 거추장스러운 건 다 버려야 한다. 수하물로 부친 캐리어는 두 말할 필요도 없고 어지간해서는 선반 위에 올린 백팩조차도 못 건진다. 지갑, 핸드백, 최소한의 개인 의료기기 정도나? 자기가 짐 꺼내느라 복도 공간을 점유하는 동안 뒤의 승객들이 탈출을 못 하기 때문이다. 그 짐은 무게 당 얼마로 환산해서 나중에 보험사로부터 보상만 받을 수 있을 뿐이다.

이런 상황에서 하이힐 같은 신발은 거동에 불편할 뿐만 아니라, 뾰족한 굽으로 탈출 슬라이드를 펑크내는 민족 반역자급 초 울트라 민폐를 끼칠 위험이 있다. 이런 거 탈출하는 모습을 보면 그 승객이 속한 국가와 사회의 평소 시민의식 질서의식을 확인할 수 있다.

4. 추락 실험

자동차, 특히 그나마 작고 자가운전의 비중이 높은 양산형 소형차들은 모델을 처음 개발할 때 철저한 안전 테스트를 거친다. 사고가 나더라도 탑승객이 받는 대미지가 도를 넘지 않고 일정 수준 이상의 생존률이 보장돼야 한다고 말이다. 특히 미국 같은 자동차 선진국에 신차를 수출하려면 거기서 시행하는 아주 엄격하고 까다로운 테스트를 통과해야 한다.

컴퓨터 시뮬레이션만으로 자동차의 구조적인 안전을 100% 완전히 예측하고 검증할 수는 없기 때문에 오늘날까지도 자동차에는 충돌 테스트가 쓰인다. 그때 교보재로 동원되는 마네킹인 더미는 보기보다 굉장히 비싸고 귀하신 물건이다.
그런데 자동차의 충돌 실험 말고 혹시 비행기의 추락 실험이 시행된 예가 있을까?

보잉이든 에어버스든, 양산형 여객기가 개발되는 과정에서 "조류 충돌에 대비한" 모의 충돌 테스트는 하지만, 아예 기체를 통째로 추락· 전손시키는 테스트까지 하지는 않는다. 그렇기 때문에 비행기가 추락 사고가 났을 때 어디에 있던 승객이 가장 많이 생존하더라 어쩌고 하는 것은 다 실제로 일어난 사고들을 통해서만 데이터를 축적해서 통계를 낸 것이다.
그런데 이것만으로는 뭔가 부족하다 싶으니, 미국에서는 비행기 제조사가 아닌 다른 서로 다른 단체에서 딱 두 번 추락 테스트를 시행한 적이 있었다.

처음은 1984년 12월 1일, NASA와 FAA(Federal Aviation Administration. 번역은..;;)의 공동 주관으로 보잉 720기를 캘리포니아 주의 모 사막에다 추락시켰다. (☞ 자세한 설명) 720이라는 모델명이 생소할 텐데, 이건 727의 오타가 아니다. 195, 60년대를 풍미했던 구닥다리 4발 여객기인 707의 다운사이즈 버전으로, 제원상의 최대 좌석 수는 149였다.

시범타로 쓰인 기체는 FAA에서 1960년에 훈련용으로 구매한 것으로, 심하게 낡았고 어차피 폐기할 때도 됐으니 이런 용도로 쓰이며 최후를 맞이한 것으로 보인다.
추락한 기체는 파손되면서 연료가 온통 유출되었으며, 이것이 주변의 뜨거운 엔진열로 인해 발화하여 화재를 일으켰다. 기체는 순식간에 불길에 휩싸였다.

사용자 삽입 이미지

비싼 비행기를 추락시켜 부수는 것은 자주 얻을 수 있는 기회가 아니니, 한 번의 이벤트로 최대한의 실험 데이터를 얻을 수 있게 추락 계획을 정말 치밀하게 잘 짜야 했을 것이다. 마치 건물 철거 계획을 수립하듯이 말이다.

더구나 자동차 충돌 실험 때야 궤도나 피아노줄을 이용해서 차를 무인으로 이동시킨다지만, 비행기는 그런 게 없다. 여객기는 하다못해 전투기 같은 조종석 사출 기능조차도 없다. 그러니 처음엔 사람이 들어가서 비행기를 조종하다가 중간에 낙하산으로 뛰어내려서 탈출해야 했다. 물론 동승한 전문 스카이다이버의 도움을 받으며 말이다. 비행기 조종 전문가가 낙하산 전문가는 아니니까.

이런 추락 실험이 비교적 최근에 또 행해졌다. 지난 2012년 4월 27일, 이번에는 미국의 디스커버리 채널이 자사의 "무엇이든 물어 보세요"(Curiosity) 프로 방영을 위해 구닥다리 중고 보잉 727-200을 구매해서 미국· 멕시코 국경 지대에 있는 사막에 추락시켰다. (☞ 자세한 설명)
추락시킨다는 게 공중에서 시동을 꺼 버리고 마냥 활강 내지 자유 낙하시키는 게 아니다. 정상적인 착륙 때처럼 뒷부분부터 사뿐히 착지시키지 않고 그냥 연약한 앞부분부터 바로 땅에 닿게만 해도 하체가 으스러지면서 추락 사고가 나는가 보다.

이때는 1984년 실험과는 달리 비행기가 수평 자세로 비교적 곱게(?) 추락했으며, 기체에 불이 나지도 않았다. 훗날 발생한 2013년의 아시아나 항공 814편 추락 사고와 비슷한 양상이 된 것 같다.
단, 727은 삼발기이며 요즘 비행기들처럼 엔진이 날개 아래에 주렁주렁 달린 형태가 아니다. 그렇기 때문에 오늘날의 다른 비행기와는 사고의 양상이 좀 다르게 흘러간 것일 수도 있다.

사용자 삽입 이미지

720과 727 모두 엄청난 구형 기종이긴 하지만, 그래도 이렇게 여객기의 추락 실험에 동원된 이력이 있다는 게 흥미롭게 느껴진다.
하긴, 서구· 영미권에서 저런 "스펀지" 스타일의 지식 쇼 프로들은 자동차쯤이야 아무렇지도 않게 충돌시키고 박살 내고, 폭탄도 터뜨리고 별 엽기적인 소재를 갖고 실험을 하더라. 그리고 자동차의 충돌 실험 자체를 수평 충돌이 아니라 자유낙하 실험 형태로 진행하기도 한다.

Posted by 사무엘

2017/12/14 08:28 2017/12/14 08:28
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1437

오늘은 기초 전산학/컴공 상식을 좀 복습해 보고자 한다.

※ 지금과 같은 컴퓨터의 근간이 갖춰진 과정

1. 순 전자식

이로써 인간이 발명한 계산 기계는 엔진 달린 주판 수준을 넘어서 자신의 모든 내부 상태를 전자 신호만으로 광속으로 표현할 수 있게 됐다. 에니악이 순 전자식 컴퓨터로서는 거의 최초 원조라 여겨진다. 이거 이후로 컴퓨터는 진공관, 트랜지스터, IC, (V)LSI 회로 순으로 그야말로 엄청난 공간 워프를 거듭하면서 작아지고 빨라지기 시작했다.

전자식이 아니라면? 컴퓨터도 엔진이나 모터가 달린 채로 만들어졌을 것이다. 19세기에 영국의 수학자 찰스 배비지는 '프로그래밍 가능한 보편적인 계산 기계'인 '해석 기관'이라는 걸 제안하고 만들려 했다. 시대를 아득히 앞서 간 물건이었는데, 그걸 가동하기 위해서 무려 증기 기관을 접목할 생각까지 했었다. 지금 같은 눈부신 전자 공학 기술이 없던 시절이니 당연히 기계식밖에 선택의 여지가 없었던 것이다.

그리고 1940년대 초에 에니악 이전에 등장했던 '하버드 마크 1'이라는 기계는 '전자식 계산기'라기보다는 '전동식 계산기'에 더 가까웠다. 복잡한 배선과 릴레이뿐만 아니라 4마력짜리 모터가 달려 있었다. 이건 냉각팬 모터가 아니며 하드디스크 같은 기계식 보조 기억장치용 모터도 아니고, CPU의 실제 계산 동작을 위한 모터였다..;;

2. 2진법 기반

사람이나 열 손가락이 달려 있으니 10진법이 편하지, 기계는 단순한 2진법이 더 편하다. 컴퓨터가 전자식으로 바뀐 뒤부터는 그 차이가 더욱 두드러졌다.
하지만 극초창기에는 숫자 진법을 변환하는 것조차 쉬운 작업이 아니었고, 정수가 아닌 부동소수점으로 가면 숫자를 표현하는 난이도가 더 올라갔다. 더구나 컴퓨터는 처음부터 포탄 탄도 예측, 풍동 실험, 일기예보 시뮬, 모의 핵실험처럼 천상 실수 연산이 잔뜩 필요한 과학 영역에서 쓰였다.

그러니 에니악 같은 컴퓨터는 10진법 기반으로 만들어졌다. 4비트를 한 자리로 묶어서 0~9를 표현하는 BCD 코드 기반이었지 싶다. 하지만 10진법 숫자를 처리하기 위해서 어차피 2진법 기반의 각종 논리 연산 회로를 구현해야 했을 것이고, 후대의 컴퓨터들은 얼마 가지 않아 native 2진법 기반으로 다 바뀌었다.

3. 튜링 완전

프로그램이 하드코딩된 고정된 변수가 아니라 메모리에 기록된 값을 토대로 또 임의의 위치의 메모리를 읽고 쓸 수 있고(= 배열, 포인터 등을 이용한 복합 자료형. 공간 확장),
런타임 때 결정되는 값의 조건에 따라 반복과 분기가 가능하다면 (= 시간 확장)
그런 계산 모델은 Turing-complete하다고 여겨진다. 즉, 단순 계산기를 넘어 뭔가 본격적으로 프로그래밍이 가능해진다는 것이다.
그 열악한 에니악조차도 설계 구조는 튜링 완전한 형태였다고 한다.

4. 프로그램 내장형

컴퓨터에게 시킬 작업을 변경하기 위해 매번 회로 배선을 뜯어고치고 바꾸는 게 아니라, 한 메모리에서 코드와 데이터를 일체로 내장시킨다. 이 개념까지 정립됨으로써 비로소 컴퓨터는 정말 유연하고 무한한 확장성을 지닌 물건으로 변모했으며, 컴퓨터에서 하드웨어와 별개로 '소프트웨어'라는 것이 존재할 수 있게 됐다.
또한, 메모리가 컴퓨터의 성능에서 차지하는 비중이 아주 커졌다. 프로그램을 메모리에다 처음으로 입력시킬 때는 과거엔 천공 카드 같은 불편한 매체가 쓰였지만, 나중에는 더 간편한 키보드로 대체됐다.

저 아이템들 하나하나가 그야말로 병아리가 알을 깨고 세상으로 나오는 급의 대격변이고 혁신이었다.
인류 역사상 이런 네 조건을 모두 만족하는 컴퓨터가 발명되고 등장한 지 아직 100년이 채 지나지 않았다. 자동차와 비행기의 역사는 100년을 넘었지만 컴퓨터는 아직 그렇지 않고 오히려 2차 세계 대전 이후 냉전 때부터 발전해 왔다.
그 짧은 기간 동안 컴퓨터가 인류 역사상 유례가 없이 세상을 바꿔 놓은 걸 보면.. 정말 전율이 느껴지지 않을 수 없다.

※ 메모리 계층

컴퓨터는 모름지기 정보를 다루는 기계이다. 그리고 앞서 언급했던 프로그램 내장 방식의 특성상, (1) 실행할 코드와 (2) 그 코드가 처리할 데이터가 모두 메모리에 담겨 있어야 한다. 쉽게 말해 정보를 담을 그릇이 필요하다.
그런데 컴퓨터가 취급하는 메모리라는 게 여러 종류가 있고, 이들은 속도와 용량, 단위 용량당 가격이 극단적으로 반비례하는 관계이다. 그렇기 때문에 종류별로 일종의 '메모리 계층'이 존재한다.

1. 레지스터(수십~수백 byte)

CPU 구성요소의 일부이다. 당연히 CPU 차원에서 최고속으로 직통으로 값을 읽고 쓸 수 있다.
현재 프로그램이 실행되고 있는 지점(메모리 위치), 수만 번씩 실행되는 for 문 loop 변수, C++ 함수의 경우 this 포인터, 산술 연산 명령에 쓰이는 피연산자와 연산 결과 같은 정~말 원초적인 값들이 이곳에 저장된다.
실행되는 스레드의 context가 바뀌면 레지스터의 값도 자기 상태의 것으로 바뀐다.

2. 캐시 메모리(수백 KB~수 MB)

CPU 자체는 아니지만 여전히 CPU의 연장선 격이며 접근 속도가 매우 빠르다. CPU가 사람 두뇌이고 레지스터가 손의 손가락이라면 캐시는 의수 정도는 된다.
얘는 CPU 속도와 메모리 속도의 격차가 커지면서 메모리로 인한 병목을 줄이기 위한 버퍼 차원에서 도입되었다.

캐시도 레벨 1, 레벨 2로 나뉘긴 하는데, 인텔 x86 CPU에서 제일 원초적인 L1 캐시는 80486 때 8K짜리가 도입된 것이 최초이다. 반대로 펜티엄 2이 나왔던 시절에 셀러론 프로세서는 L2 캐시를 제거하거나 용량을 팍 줄인 저가형 모델이었다.

3. 일반 메모리(수십 GB)

CPU의 외부에 있기 때문에 위의 것들보다는 느리지만, 그래도 보조 기억장치보다는 여전히 훨씬 빠르다. 이들 메모리는 전원이 끊어지면 내용이 다 지워지는 휘발성 메모리이다. 이제 신체 접근성으로 치면 의수를 넘어서 핸들과 버튼으로 따로 조작하는 로봇 팔과 비슷하다고 볼 수 있겠다.

4. 하드디스크(수 TB)

디스크부터는 보조 기억장치이기 때문에 이건 CPU의 명령만으로는 직접 접근조차 할 수 없다. 운영체제라는 소프트웨어가 구현해 놓은 파일 시스템에다 해당 운영체제 API를 통해 요청해야만 데이터를 읽고 쓸 수 있다. 파일 시스템은 열고 닫는 상태를 따로 보관하고 관리해야 하며, 프로그램의 입장에서는 여는 작업이 실패하는 상황에 대한 대비가 필요하다.
사람으로 비유하면 내 손으로 뭔가를 직접 조작하는 게 아니라, 남에게 말로 부탁을 해서 간접적으로 뭔가를 요청하고 움직이는 형태가 된다.

그 대신 보조 기억장치는 전원이 끊어진 뒤에도 기록을 남기고 보존할 수 있다. persistency를 보장하려다 보니, 하드디스크는 컴퓨터에서 전자식이 아닌 기계식으로 동작하는 얼마 안 되는 부품 중 하나가 돼 있다. 플래시 메모리는 '일반 메모리'의 성격에 더 근접해 있는 기억장치이지만, 가격과 용량 문제 때문에 하드디스크를 완전히 대체하는 구도는 못 된다.

캐시 메모리에서 캐시 미스가 나서 더 느린 일반 메모리까지 내려가서 데이터를 가져오는 게, 아래의 운영체제의 가상 메모리 체계에서 페이지 폴트가 발생해서 디스크의 페이지 파일에서 데이터를 가져오는 것과 비슷한 구도이다. 메모리 공간 자체가 CPU의 일부는 아니지만, 보호 모드 가상 메모리 구현을 위한 주소 변환은 CPU 차원의 지원을 따로 받아서 이뤄진다.

메모리가 비싸고 귀하고 부족하던 옛날에는 가상 메모리라는 게 디스크를 메모리 보충분처럼 사용하는 메커니즘이기도 했다. 비록 속도는 안드로메다로 가 버리지만, 그래도 아예 안 돌아가는 것보다는 나으니 better late than never이다. 요즘 운영체제들은 memory mapped file이라고 디스크를 반쯤 메모리 다루듯이 포인터로 접근시켜 주는 API를 제공하는데, 가상 메모리를 구현하면서 내부적으로 구현된 기능을 사용자도 적절하게 활용하라고 떼어 준 것에 가깝다.

또한, 가상 메모리와는 별개 개념으로.. 레지스터와 메모리 사이에 '캐시 메모리'가 있듯이, 메모리와 디스크 사이에 '디스크 캐시'라는 계층이 존재한다. 이게 잡아먹는 메모리 양이 만만찮지만 도스 시절에 smartdrv 유틸로 수백 KB~2MB 남짓만 캐시를 잡았어도 체감 성능 향상 효과가 장난이 아니었다. 이거 없이 곧이곧대로 찔끔찔끔 디스크에 접근해서는 오늘날의 방대한 컴퓨터 시스템이 돌아가질 못한다. 그만치 메모리와 디스크 사이의 속도 격차 병목이 엄청나다는 뜻이다.

5. 자기 테이프(수백 TB~수 PB)

아주 극단적인 보조 기억장치이다. 느리고 랜덤(임의 위치) 접근이 안 된다는 엄청난 단점이 있지만, 용량이 가히 압도적이고 가격이 저렴하다. 그렇기 때문에 서버 전체 내지 매일 생성되는 방송국 동영상 같은 엄청난 양의 데이터를 오로지 백업· 보존만 할 목적으로 일부 연구소나 기업에서 테이프가 여전히 사용되고 있다. 마치 국제 화물 운송에서 선박이 차지하는 위상(느리지만 엄청난 수송량)과 비슷하고, 프린터계에서 도트 프린터의 먹끈 카트리지(원시적이지만 타의 추종을 불허하는 저렴함)와 비슷하다.

메모리야 컴퓨터 프로그램들이 맨날 하는 짓이 저걸 건드리는 것이고, 보조 기억장치는 파일을 읽고 쓰는 운영체제 API를 통해 사용 가능하다.
레지스터의 경우, C/C++ 언어에는 특정 정수 변수를 가능한 한 저기에 얹어 달라고 컴파일러에게 요청하는 register이라는 키워드가 있다. 함수에 inline이 있다면 변수는 저게 있는 셈이다. for문 loop 변수가 레지스터에 올라가면 좋다.
물론, inline 함수는 재귀호출을 해서는 안 되며, 레지스터 등재 변수는 주소 참조(단항 & 연산자)를 해서는 안 된다.

이렇게 타 메모리나 디스크나 레지스터와는 달리, 캐시 메모리만은 적중률을 올리기 위해 소프트웨어가 직접 접근하고 개입하는 방법이 딱히 존재하지 않는다. 멀티코어 병렬화를 위해서는 CPU 직통 명령인 인트린식 같은 것도 있는데 캐시는 활용 방식이 소프트웨어가 아닌 오로지 CPU의 재량인가 보다.
이렇게 존재감이 없음에도 불구하고 캐시 메모리의 양과 성능은 클럭 속도 다음으로 컴의 속도에 직접적인 영향을 끼치는 요인이다.

※ 인텔 x86

인텔 x86은 전세계의 PC 시장을 완전히 석권한 기계어 아키텍처이다. 애플 맥 진영이 x86으로 갈아탄 지 이미 10년이 넘었고, 슈퍼컴퓨터조차도 Cray 같은 슈퍼컴 전용 아키텍처가 진작에 다 망하고 x86이 코어 수를 늘려서 야금야금 파고들고 있다.

하지만 x86은 CPU를 만들던 기술과 방법론이 지금과 같지 않던 초창기, 특히 메모리 가격이 왕창 비싸던 시절을 기준으로 기반이 설계되었으며 16, 32, 64비트로 올라가는 과정에서도 하위 호환성을 잘 유지하고 있다. 그래서 넘사벽급의 범용성과 시장 경쟁력은 확보했지만, 내부 구조가 갈수록 왕창 지저분해지고 스마트폰용 ARM 같은 후대의 최신 CPU들의 유행과는 영 동떨어진 형태가 됐다.

  • 범용 레지스터 수가 유난히 매우 적음. R## 이렇게 수십 개씩 번호가 붙는 게 아니라 EAX EDX ESI EBP 등 꼴랑 8개로 끝인 건 x86이 예외적이고 특이하기 때문이다. 함수에다가 매개변수를 올리는 주 방식도 x86은 당연히 레지스터가 아닌 스택 기반이다. 이 때문에 컴파일러 백 엔드를 개발하는 방법론이 x86 타겟 계열과 타 아키텍처 계열은 서로 완전히 다르며, x86은 오늘날 컴공과에서 컴파일러 제작 교육용 교보재로 쓰이기에는 영 좋지 못한 타겟 아키텍처이다.
  • 메모리를 조밀하고 compact하게 쓰는 대신에, 디코딩이 복잡하고 더 어려운 CISC 가변 길이 방식으로 명령어를 기술한다. 한 인스트럭션으로 연산에다 메모리 조작까지 몽땅.. 이런 식으로 많은 지시를 함축하고 있는 편이다. 자동차 엔진으로 치면 회전수가 낮은 대신 실린더의 스트로크가 긴 디젤처럼..
  • machine word align이 맞지 않은 메모리 주소의 값을 fetch하는 것을 굉장한 비효율(여러 클럭수 소모)을 감수하고라도 CPU 차원에서 아무 문제 없이 잘 처리해 준다. 요즘 CPU 같았으면 그냥 예외 날리고 끝이었을 텐데.. 이 역시 메모리를 아끼기 위한 조치이다.

레지스터가 부족하면 나중에라도 더 보충하면 되지 않냐고?
레지스터는 추가로 더 꽂기만 하면 되는 메모리가 아니라 CPU 그 자체이다. 그걸 뒤늦게 확장한다는 건 CPU의 아키텍처, 세부 설계와 생산 라인이 다 바뀐다는 뜻이다. 컴파일러도 그에 맞춰 바뀌고 프로그램도 몽땅 다시 빌드되어야 추가된 레지스터 덕을 볼 수 있다. 사람으로 치면 가방 크기를 더 키우는 게 아니라 생물의 유전자 차원에서 손의 크기, 손가락 개수를 더 키우고 늘리는 것과 같은 엄청난 변화이다.

x86이 너무 지저분하다는 건 제조사인 인텔도 누구보다 잘 알고 있었기 때문에 과거 2000년대 초, 64비트 CPU를 내놓는 김에 애플처럼 하위 호환성을 싹 버리고 현대적인 디자인 트렌드를 따라 과감한 물갈이를 하려 했다.
마소 역시 새천년 Windows 2000에 맞춰 64비트 에디션을 당당히 내놓으려고 벼르고 있었다. Windows SDK 헤더 파일에서 INT_PTR, INT64 이런 typedef가 등장하고 GetWindowLong이 GetWindowLongPtr로 감싸진 게 이 시기의 준비 작업이었다.

하지만 모두의 예상을 깨고 IA64 Itanium라는 새 아키텍처는 CPU와 컴파일러 개발이 제대로 되지 않고 호환성도 안습했기 때문에 철저히 망하고 실패했다.
결국 지금은 기존 x86을 그대로 수용하면서 Itanium보다 훨씬 더 현실과 절충한 x86-64라는 다른 아키텍처를 기반으로 64비트 컴퓨터가 쓰이게 됐다. 이 아키텍처는 인텔이 아니라 경쟁사인 AMD가 최초로 개발했다.

Windows 2000은 과거 NT 3~4 시절에 지원했던 한물 간 구형 CPU들의 지원은 다 끊었고(Alpha, PowerPC, MIPS 등), IA64는 베이퍼웨어이고, 지금 같은 ARM이나 x64는 아직 안 나왔다 보니 NT로서는 이례적으로 사실상 x86 전용으로만 출시되어야 했다.

그런데.. 인텔 x86이 저렇게 메모리 아끼려고 CPU 본연의 효율까지 희생하면서 헝그리하게 설계된 건 과거 PC의 역사를 살펴보면 충분히 이해가 된다.
32비트 80386 CPU가 이미 1985년에 개발됐는데도 Windows NT, OS/2 같은 이상적인 32비트 운영체제의 도입과 보편화가 10년 가까이 너무 늦었고 Windows 9x 같은 요물이 몇 년간 쓰여야 했던 이유는 32비트 가상 메모리를 운용하고도 남을 정도로 컴의 메모리가 충분치(못해도 수~십수 MB) 못했기 때문이다. (CPU 말고 그래픽 카드는 1987년에 VGA가 개발되자 못해도 2~3년 안으로 프로그램들이 다 지원하기 시작함)

64비트로 넘어갈 때도 마찬가지다. IA64가 개발되던 1990년대 말엔 아직 가정용 컴의 메모리는 100~200MB대에 불과했다. 32비트를 벗어나야 할 이유가 전혀 없었다. 64비트 CPU는 대용량 데이터 처리 분야에서 속도가 좀 더 올라갈지는 모르지만, 같은 명령과 데이터를 수행하더라도 메모리 소모가 훨씬 더 많아지는 건 피할 수 없었다. 이러니 가정용 PC에서 64비트의 대중화는 Windows 2000/XP 시기는 어림도 없고, 본격적으로 램 용량이 4GB를 넘어선 2000년대 후반 Vista/7급은 돼서야 이뤄지게 됐다.

Posted by 사무엘

2017/12/11 08:31 2017/12/11 08:31
, ,
Response
No Trackback , 4 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1436

다음 버전 개발 근황

날개셋 한글 입력기는 2018년 3월쯤 완성 목표로 9.3 버전이 개발 중이다.
프로그램의 전체 소스 코드가 이제 8만 줄을 돌파했다. 참고로 7만 줄은 2015년에 8.2 버전을 개발할 때 달성됐으며, 6만 줄은 2011년에 6.0 버전을 개발하는 과정에서 달성되었다.

※ 버그 수정

1. 후보 변환 관련 문제

지난 9.0과 9.1이 기능 추가 말고 '개선' 사항이란 게 없다시피했기 때문에, 이제 이 프로그램은 기존 기능들이 충분히 안정화가 됐다고 여겨졌다. 그래서 본인은 오랫동안 안심하고 새 기능 구현에만 집중하면 되겠다고 생각했다.

그러나, 얄밉게도 9.1을 공개한 지 얼마 되지 않아 후보(한자) 변환 쪽에서 총체적으로 꽤 난감한 버그가 발견되었다. 옛한글 내지 미완성 한글처럼 내부적으로 단일 코드 포인트로 표현되지 않는 한글을 조합 중인 상태에서 한자 키를 눌러 보면 된다.
'제1후보 변환' 기능에 문제가 있어서 "마지막 낱자(from) + 아무 후보가 없는 상태(to)"로 후보 선택창이 이상하게 뜬다.

사용자 정의 후보에서 from을 옛한글이나 미완성 한글로 지정하더라도 조합 중에는 변환이 되지 않는다.
그리고 조합을 마치고서 post-mortem 변환을 하더라도 cursor 이동 계산이 이상하게 돼서 글자가 정상적인 위치보다 앞에 삽입 되는 식의 오동작이 발생한다.

이건 후보 변환 관련 버그 수정이 마지막으로 행해졌던 8.9시절부터 계속 남아 있었던 문제로 보인다. 9.0이나 9.1때도 버젓이 있었던 문제이다. 그게 지금까지 왜 발견하지 못하고 있었는지, 버그인지 아니면 아예 미구현 미완성이었는지, 왜 그때 코드를 이 따위로 작성했는지 자괴감이 든다. 뭐, 버그를 발견 즉시 사살하긴 했다.

2. MS Word에서의 수식 중복 수행 문제

그리고, MS Word에서 특정 상황 조건이 만족되었을 때(가령 bksp를 누른 뒤), 글쇠를 한 번만 눌렀는데 그 글쇠에 대한 수식이 두 번 수행되어 오동작이 발생하는 문제를 해결했다.
이 문제는 3년 전에 나온 7.7 버전에서 다뤄진 적이 있었지만 그 당시의 해결책이 온전하지 못했다. 추가적인 문제는 내가 발견한 건 아니고 사용자의 제보를 통해 파악했다.

기술적인 관점에서 보면, MS Word와 워드패드는 TSF 인터페이스를 잘 지원하는 프로그램이긴 하지만 얘들만 글쇠를 좀 이상하게 인식하고 요청하는 문제가 있어서 이들 프로그램에 대한 보정이 필요했다. 워드패드는 혼자 다른 프로그램들과 정반대의 순서로 key 입력을 전해 주며, Word는 순서는 문제가 없는데 동일한 key 입력을 중복 전달하는 경우가 있다.

이게 버그가 아니라 사용자가 진짜로 같은 key를 반복해서 누른 것일 수도 있기 때문에 보정도 앞뒤 상황을 봐 가면서 조심스럽게 해야 한다. 여러 모로 골치아프다.
게다가 중복 전달을 2중이 아니라 아예 3중으로도 하는 경우가 있는데, 내 프로그램은 이에 대한 대비는 돼 있지 않았다. 이를 확인하여 개선했다.

※ 보조 입력 도구 기능 추가

그럼, 버그 수정 내역 말고 기능 추가 내역을 소개하겠다. 이번 9.3도 지난 9.1과 마찬가지로 '보조 입력 도구' 가 새로운 것들이 추가되고 있다. 특별히 한글 입력기(문자 생성기)의 내부 상태를 시각적으로 진단· 확인하는 데 도움이 되는 것들이다.

1. 수식 계산 기록

이건 꽤 이색적인 보조 입력 도구이다. 얘를 띄우고서 글자판을 바꾸거나 한글을 입력하거나 각종 기능을 조작하면 그 과정에서 내부적으로 실행된 글쇠배열, 오토마타 등의 수식이 화면이 쭉 뜬다. 그 수식 중 하나를 클릭하면 어느 설정에서 유래된 수식이고 초기에 공급된 변수값들이 무엇이 있는지, 실행 후에 대입 연산으로 인해 변경된 변수가 있는지, 수식의 계산 결과는 무엇이 나왔는지가 화면 우측에 조목조목 나타난다.

사용자 삽입 이미지

그러니 이 기능을 사용하면 내가 만든 입력 설정이 기대했던 대로 동작하지 않을 때 수식과 변수에 무슨 문제가 있는지 추적을 아주 편리하게 할 수 있다.
수식은 날개셋 한글 입력기의 설정을 기술하는 핵심 구성 요소이다. 하지만 이게 어떤 방식으로 동작하는지를 사용자에게 시각적으로 알기 쉽게 보여주는 편의 기능이 없어서 사용이 불편했던 게 현실이다. 이 입력 도구는 그 불편을 크게 개선해 주리라 기대된다.

2. 내부 입력 상태 표시

얘도 '수식 계산 기록'와 비슷하지만 관점이 미묘하게 다른 입력 도구이다. 조합을 만들어 낸 문자 생성기의 내부 상태만을 표시해 줄 뿐 자신이 뭔가 입력 기능을 제공하는 건 없는 read-only 도구이다. '내부 입력 상태'는..

사용자 삽입 이미지

(1) 조합 문자열이 생기면 그 조합을 생성한 주체, 문자 생성기의 오토마타 상태 번호, 그리고 조합의 종류를 표시한다. 대부분의 경우 조합을 소유한 주체는 그냥 지금 키보드 입력을 담당하는 입력 스키마이지만, 자체적인 문자 생성기를 가진 보조 입력 도구가 주체가 될 수도 있다(휴대전화, 한손 입력기 같은..). 조합의 종류도 한글 또는 고급 입력기의 사용자 정의 조합 이렇게 두 종류가 존재한다.

(2) 입력 스키마 휘하에 있는 사용자 변수들이 현재 갖고 있는 값들을 출력한다. '수식 계산 기록'은 수식 계산이 행해질 때마다 각각의 계산 내역들을 '목록' 형태로 관리하며, 프로그램이 제공하는 대문자 변수의 값도 다 출력해 준다. 그 반면, 얘는 모든 처리가 끝난 뒤에 글쇠배열과 오토마타 등이 공유하는 소문자 사용자 변수들의 최종적인 값만 실시간으로 업데이트 하여 보여준다. 사용자 변수의 변화만 추적할 때는 '내부 입력 상태 표시' 도구를 사용하는 게 더 편리할 수도 있다.

(3) 그리고.. 현재 발동된 타이머들을 모두 표시해서 "지금으로부터 타이머 N이 1.x초 후에 발동 예정" 이거 카운트다운을 실시간으로 보여준다. 한 타이머가 반복해서 작동되었으면 hit 횟수까지 카운트 해 준다. 물론 타이머를 발동한 근거 수식이나 그때 입력된 날개셋문자를 확인하려면 '수식 계산 기록' 도구의 도움을 받아야 하지만, 타이머의 작동 현황을 실시간으로 파악하려면 이렇게 다른 관점에서 만들어진 입력 도구를 같이 사용하는 것이 좋다.

※ UI 개선

1. '한글 표현 방식' 탭의 변신

외부 모듈(+ 입력 패드)에서 날개셋 제어판을 열면 시스템 계층에 잘 알다시피 '한글 표현 방식'이라는 거창한 탭이 제공되는데..
한번 만들어 놓은 뒤부터 오랫동안 불변이던 이 탭이 이번에 정말 획기적으로 크게 달라졌다.

(1) 처음 열었을 때는 내정값 말고 나머지 복잡한 설정들은 보이지 않게 디자인을 바꿨다. "세부 옵션 보기"를 클릭해야만 이전부터 있던 옵션들이 나타난다.
다만, 이전에 사용자가 맞춰 놓은 설정이 내정값 중 하나로 떨어지는 상태가 아니었다면 역시 처음부터 detailed view 상태로 대화상자가 뜬다.

사용자 삽입 이미지

(2) 그리고, 이 방식의 옛한글을 표시하려면 무슨 글꼴이 필요하네 뭐네 장황하고 잡다하던 설명을 다 집어치우고.. 그냥 백문이 불여일견을 구현했다.
자체 비트맵 글꼴로 예문을 레퍼런스로 제시한 뒤, 바탕, 맑은고딕 등 사용자의 컴에 있는 주요 글꼴로 지금 옵션대로 옛한글을 찍은 결과를 직접 보여주게 했다~~!

아.. 속이 다 후련하다. 이 대화상자를 진작부터 왜 이렇게 만들 생각을 안 했나 모르겠다.
물론 지금은 무려 2018년이 코앞이고 옛한글 표현 기술은 유니코드 5.2 표준이 완전히 정착했다. 이제 한글 표현 방식을 변경하는 건 "현대 한글 전용" 아니면 "유니코드 5.2" 내정값 이 둘밖에 없으며, 나머지는 그냥 legacy일 뿐이다.

그러니 이 '한글 표현 방식' 탭은 제공되는 옵션들을 처음부터 사용자에게 몽땅 미주알고주알 보여줄 필요가 없으며, 특수한 이유가 있는 게 아니라면 이건 오히려 건드리지 않는 게 좋다고 먼저 안내해야 한다. (1)은 이런 생각을 구현한 것이다.

지금 이 기능을 새로 구현한다면 '한글 표현 방식'을 선택하는 건 별도의 탭을 만들지 않고 시스템 계층의 다른 대화상자에다가 콤보 상자와 버튼 하나로 간단하게 구현됐을 수도 있다.
하지만 이게 처음 도입된 건 날개셋 4.x대 후반, 2007년인가 08년경이었기 때문에 아직 그럴 상황이 아니었다. 유니코드 5.2가 정식 제정되기 수 년 전이었으며, 한양 PUA나 유니코드 1.1 같은 절충안이 여전히 유효하던 때였다. 그러니 무슨 방식을 선택하느냐에 따라서 주의 사항을 출력할 것이 많기도 했다.

이번에 새로 구현된 미리보기 기능은 스크린샷에서 보다시피 현대 한글 자모와 글자, 유니코드 1.1 수준의 자모와 글자, 한양 PUA 문헌에 있는 옛한글과 그렇지 않은 옛한글, 유니코드 5.2 전용 옛한글을 일목요연하게 찍어서 보여준다.
그러니 사용자는 낱자들이 풀어지거나 깨지거나 벌어지지 않고 레퍼런스 렌더링인 비트맵 글꼴과 가장 비슷하게 찍히는 글꼴을 찾아서 그걸로 옛한글을 입력하면 된다.

2. '코드 번호로 변환' 텍스트 필터의 UI 변화

날개셋 한글 입력기에는 '코드 번호로 변환'이라는 텍스트 필터가 있어서 문자를 유니코드 또는 여러 multibyte 인코딩 번호로 풀어 쓰거나 그걸 반대로 재합성하는 기능을 제공했다. 리드미를 찾아보니 8년 전의 5.31 때 첫 도입되었는데, 임의의 유니코드 문자열을 소스 코드나 URL로 풀어 써야 할 때 무척 유용하게 활용 가능한 기능이다.

사용자 삽입 이미지

문자를 숫자로, 또는 숫자를 문자로..
그리고 유니코드 코드 포인트, 또는 특정 인코딩으로.. 이 2*2=4가지 변환을 모두 지원한다.
문자를 유니코드 번호로 변환하는 기능은 어느 문자를 변환할지 수식, 문자 코드 페이지(이 코드 페이지에 없는 것), 글꼴(이 글꼴에 없는 글자) 이렇게 세 조건 중 하나로 지정할 수 있다. 그렇기 때문에 별도의 '조건' 대화상자를 여는 버튼이 지금까지 있었다.

그러던 것이 다음 버전부터는 조건 대화상자가 없어지고 그 조건이 동일 대화상자 화면의 아래에 바로 표시된다. 단계가 더 간단해졌다. 위의 스크린샷에서 보는 바와 같다.

그리고.. 문자를 유니코드로 바꾸는 것 말고 인코딩 바이트로 바꾸는 기능에도 "추가로 변환할 문자"를 지정하는 입력란이 추가되었다.
이 기능은 아스키 127번 이하의 문자는 코드값이 불변이기 때문에 0x나 %로 변환을 하지 않는다. 한글· 한자처럼 진짜로 변환해야 하는 문자, 숫자나 접두사와의 혼동을 피해야 하는 문자만 변환해 준다.

하지만 문자열을 URL 같은 데에 전달할 목적으로 변환하다 보면.. +, &, ?처럼 특수한 용도로 예약된 문자도 강제로 변환해야 할 때가 있다. 유니코드 번호로 변환하는 기능이야 수식을 지정할 수가 있지만, 여기서는 문자의 종류가 끽해야 몇십 종류밖에 안 되니 굳이 수식을 넣을 필요는 없고, 부득이하게 강제로 번호로 변환해야 하는 문자를 사용자가 수동으로 지정할 수 있게 했다.

이런 자그마한 기능 추가와 함께 UI 개선, 소스 코드 리팩터링도 같이 진행하니 굉장히 훌륭한 결과가 나왔다. 변환 형태 4가지를 선택하면 그 아래의 화면은 네 가지가 하나도 같은 게 없이 제각각 동적으로 바뀐다. '유니코드 번호를 문자로' 바꾸는 기능이 옵션이 제일 적어서 썰렁하다. '번호 표현 형태'를 고르는 것밖에 남지 않기 때문이다.

※ 나머지 얘기

1. 사소한 변화들

데이터: 9.0에서 첫 도입되었던 24픽셀 옛한글 글꼴이 외형이 지금보다 더 예쁘게 보이게 일부 수정· 개선되었다. 그리고 제공되는 비한글 입력 예제인 Qwerty/Latin Ext가 최신 유니코드를 기준으로 후보 데이터가 더 방대해졌다. 이것들은 정 재민 님께서 수고해 주셨다.

타자연습: 큰 기능 추가는 없으나, 입력기의 API 구조 변경의 영향을 받아서 타자연습도 새 릴리스가 나오긴 할 것이다. main 화면에서 Alt+1~6을 누르면 '시작'부터 '통계' 탭까지 곧장 이동하게 비밀 단축키를 추가했다. 마우스 없이 키보드만으로 프로그램을 사용하기가 좀 더 편리해질 것이다.

2. 고민: 보안 프로그램과의 충돌 문제

날개셋 한글 입력기가 보안 프로그램과 충돌하는 건 2000년대 중반쯤부터 인터넷 뱅킹 사이트 위주로 신고가 들어오곤 했다. 그때는 ActiveX 형태로 동작하면서 키보드 드라이버 계층에서 날개셋으로 전달되는 입력을 차단하여 내 프로그램 동작을 먹통으로 만드는 게 문제였다. 즉, 프로그램이 아닌 사이트가 문제였다.

또한, 그때는 엄밀히 말해서 3rd-party IME를 쓰는 게 문제가 아니라 세벌식을 쓰는 게 문제인 경우도 있었다. 한글을 입력하라고 알파벳 글쇠만 허용해 놨는데 세벌식은 4단 숫자와 기호 자리까지 사용하니 그것만으로 충분치 못한 것이다.

요즘은 온라인 게임에서 내 프로그램이 잘 동작하지 않는다는 문의가 종종 들어온다. 조합이 덧난다거나 하는 사소한 문제가 아니라 (1) 아예 글쇠가 인식되지 않고 한글이 아닌 영문만 입력된다거나, (2) MS IME로는 문제가 없는데 날개셋만 그런다면 그건 내 프로그램에서 딱히 해결책이 없을 가능성이 90% 이상이다. 해당 게임, 더 정확히는 그 게임이 사용하는 보안 솔루션이 날개셋 한글 입력기의 동작을 차단하지 않아야 한다.

사실, 내 프로그램이 디지털 서명이 없어서 각종 백신이나 보안 프로그램으로부터 의심받는 것도 문제이긴 하다. 현재로서는 뾰족한 대책이 없어서 그냥 넘기고 있지만, 이 때문에 사용자의 불편이 크다면 어찌 해야 할지 고민된다. 요즘은 안 그래도 어지간한 프로그램들은 웹브라우저에서 몽땅 띄우고 네이티브 프로그램의 다운로드와 설치는 점점 기피되는 추세인데, 이런 불편까지 끼치는 것은 참 민망한 일이 아닐 수 없다.

Posted by 사무엘

2017/12/08 08:36 2017/12/08 08:36
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1435

일본을 이기는 법

* 예전에 썼던 일본에 대한 생각 글 및 기업 관련 일화 글과 함께 읽을 것을 권한다.

1. 학문· 기술 업적과 제품 시장 점유율로 이긴다. (100점)

2차 대전 이후의 국제화 세계화 자본주의 개방 경쟁 시대에 이거야말로 남의 나라를 합법적으로 제일 수준 높게 이기는 방법이다. 예전 글에서 소개한 적이 있듯이, 전범 기업인 미쓰비시를 쳐바르고 기술 종속 관계를 역전시킨 현대 자동차라든가, 반도체 분야에서 이름은 모르겠다만 일본 기업들을 쳐바른 삼성전자, LG전자 등등..
이것만 알아도 되도 않은 이상한 반기업 구호들 반 이상은 필터링된다. 이공계가 세상을 바꾼다.

2. 문화 예술로 이긴다. (50점)

겨우 한류 스타 욘사마가 어떻고 하는 것만 얘기하는 게 아님. 그야말로 사람들 정신 세계 전반을 점령하는 것을 말한다. 위의 100점짜리와는 분야가 굉장히 다르고 별 것 아니어 보이지만 그래도 중요하다. 이것에 대한 우려 때문에 우리나라가 일본과 경제 협력을 위한 재수교는 무려 1965년에 했어도, 대중문화 개방은 90년대 말이 다 돼서야 성사됐다.
내 한글 입력기는 비록 기술 쪽으로 최첨단 극치를 추구하지는 않지만, 나름 이 바닥을 기여하고 공략하는 것을 목표로 하고 있다. 예술은 아니지만 문화에는 해당한다.

3. 운동 경기에서 이긴다. (30점)

열심히 노오오력해서 한일전에서 일본 이겨 주는 것도 아주 합법적이고 좋은 방법이다. 하지만, 스포츠는 경기 당시에 짜릿함 카타르시스를 주는 것 외에 우리 일상생활에 딱히 영향을 끼치는 건 아니다.
또한, 축구 한일전이 벌어질 때에만 열혈 민족주의 애국자이고 다른 상황에서는 자기 나라를 전혀 사랑하지 않는 이상한 사람들도 많다. 그들에게 대한민국이라는 나라나 태극기는 도대체 무슨 의미를 지닌 존재인 걸까?

4. 목소리와 키보드 배틀에서 이긴다. (5점)

국가관 역사관이 이상한 사람을 키배로 제압하고 산업화해 주고, 어디에 일본해가 어떻고 독도가 어떻고 하는 곳에 득달같이 달라붙고, 일본 정치인들 망언을 규탄하는 시위 벌이는 건..;; 들이는 시간에 비해서 그렇게 생산적이지는 않아 보인다.

5. 국민성, 공중도덕 등으로..

이건 이기는 법이라기보다는 지지 않는 법의 범주에 드는 것 같다.

6. 전쟁에서 이긴다? (??)

가능하지도 않고 그래야만 할 필요도 의미도 없음.
한· 일은 정치 이념 프레임이 동일한 나라이며, 예측 가능한 미래에 서로 전쟁 벌일 확률은 남북한이 전쟁 벌일 확률보다는 넘사벽급으로 낮다.

한일전 하니까 옛날 일화가 하나 떠오른다.
뭐, 예전에 비해 반일 감정이 많이 옅어진 편인 지금도 한일전이라 하면 일단 나라의 자존심이 걸려 있고 그야말로 절대로 져서는 안 되는 싸움이라 여겨진다. 하지만 진짜 한일전의 원조는 먼 옛날 1954년, 우리나라가 FIFA 월드컵에 최초로 참가하던 시절에 벌어졌다(그 당시 스위스 개최).
우리로서는 6· 25 전쟁이 끝난 지 얼마 안 됐고, 스포츠 분야에서 해방 후 최초로 앙숙 일본과 맞장을 뜨게 됐다. 1953년에 치러진 아시아 지역 예선전이다.

해방된 지 아직 10년이 채 안 되었으니 분위기가 얼마나 비장했을까?
씅만 리 할배 대통령은 승부에 대한 극심한 중압감과 부담감 때문에 처음엔 이 경기 자체를 원하지 않았을 정도였다. 그냥 월드컵 출전을 포기하고 말지, 일본놈들과는 상종을 하고 싶지 않았다.

원래 경기는 우리 홈그라운드에서 한 판, 일본으로 원정 가서 한 판씩 하는데 “쪽발이 왜놈들을 한국 땅에 들어오게 할 수 없다”라는 똥고집, 그리고 그 와중에 일본이 우리를 이겨 버리기까지 했을 때 뒷감당을 할 수 없다는 걱정이 반반씩 할배의 머리를 압박했다.
(하긴, 일제 강점기 때 일본 정부와 협력해서 반인륜 범죄를 저지르는 데 가담하고 부역한 외국인은 우리나라에 입국할 수 없다고 지금까지도 출입국 관리법에 명시돼 있긴 하다. 뭐 이젠 그런 사람들은 거의 다 죽고 없겠지만..)

뭐 어쨌든, 일본 선수들이 한국으로 올 수 없으니 우리 선수들이 두 판 모두 일본에 가서 경기를 치르게 됐다. 출정식 때 할배 각하는 친히 선수들에게 “이기지 못하면 살아서 돌아오지 마라 / 졌다가는 국민 세금으로 배 탈 생각일랑 말고 대한해협을 헤엄 쳐서 귀국해라” 이런 급의 공포스러운 막말 훈화를 했다는 카더라가 전해진다. 아니면 축구 협회 대표와 선수팀 감독이 각하를 끈질기게 설득하는 과정에서 저런 맹세를 했다고도 한다.

하지만 저런 처절한 배수진 하에서 스포츠계의 합법 도핑인 반일로이드가 약발이 제대로 적중했다..;; 우리나라는 1차전에서 5:1로 일본을 압도적으로 꺾었으며, 2차전에서도 2:2 무승부를 달성해서 무난히 본선 진출에 성공했다! 이때야 스포츠 분야의 극일 가중치가 지금 같은 30점이 아니라 당연히 그 이상이었을 것이다. 독립 주권 국가로서 한국이 일본을 당당히 이겼으니까.

뭐, 본선 가서는 헝가리에게 9:0, 터키에게 7:0으로 지고 광탈하긴 했지만, 그건 너무나 열악한 여건 하에서 첫 출전을 하고도 정말 혼신을 다해서 얻은 결과였다. 10몇 대, 20대 0으로 지지 않은 것만으로도 대단했던 값진 투혼이요 성공적인 실패, 위대한 패배였다. (그리고 일본만 이겼으면 됐고 그것만으로 목표 달성이지, 나머지 결과는 어차피 아오안이었을 것이다..;; )

이 승만은 정말 쥐뿔도 힘 없는 가난한 나라 처지에서도 그래도 미국을 최대한 이용해서 일본을 상대로 갑질을 하고 반일 노선을 고집했다. 평화선에, “대마도 내놔”에, 재일 교포 북송에 결사 반대하여 일본 적십자사 테러 시도에, 그것도 모자라서 왜관 발언은 최고의 압권이었다.
“지금 우리가 아무리 전쟁 중이고 위급하다지만, 감히 일본놈들이 우리 집안 내부 싸움에 개입하려 든다면(심지어 남한을 돕는 것도 포함) 우린 일본놈들부터 죽이고 나서 괴뢰군을 쏘겠다.

하긴, 이 할배의 입장에서는 일본이 유엔군 병참기지가 돼서 경제적으로 어부지리 덕을 보고 있는 것조차도 차마 눈꼴 시려 못 볼 지경이었을 게다.

저 때야 해방된 지 얼마 안 됐으니 그렇다 치지만, 가만히 생각해 보니 지난 2002년 월드컵은 개최 장소도 이례적으로 한일 공동 개최로 귀착됐었다. 20여 년 전에 이거 개최지 결정하던 과정도 내 기억으로 분위기가 장난 아니게 험악했다. 둘 중 한 나라 단독 개최로 결정 났다면 무슨 불미스러운 일이 벌어질지 알 수 없었다. 그래, 한국과 일본은 뭐 그런 사이이다.

하지만 감정은 감정이고, 이성적으로 분별할 건 따로 분별해야지..
까놓고 말해서 일본이 평화 헌법을 건드리거나 심지어 자위대를 군대로 승격하는 것보다, 당장 코앞에 있는 미친 또라이 국가의 핵탄두가 실험을 거듭하면서 위력이 더 강력해지고, 미사일의 사거리가 갈수록 더 길어지는 게 훨씬 더 위험한 일이다!

지금은 20세기 초 같은 제국주의 군국주의 이념이 세계를 지배하는 시대가 아니다. 일본의 작은 또라이짓에 대해서는 난리를 치고 발광을 하면서, 바로 옆에 현존하는 훨씬 더 직접적인 위협에 대해서는 아무 말도 없고 방어 체계를 구축하지 말라고 X랄인 것은 정말 머리가 정상적인 상태가 아니다.

쟤들은 종북들을 이용해서 남조선을 살살 삥뜯거나 한반도에서 미국의 영향력을 완전히 떼어 놓기 위해서 핵을 만들 뿐이다. 터뜨려서 자폭하거나 심지어 미국을 공격하기 위해서 핵을 만드는 게 절대로 아니다. 그게 불가능하다는 건 걔네들도 잘 알 것이다.

본인 역시 지금 당장 더 절박하고 시급한 문제이기 때문에 평소에는 종북 쪽을 더 비판하고 까며 지낸다. 하지만 우파가 반일· 극일 분야도 좌향좌들보다 훨씬 더 건전하게 실천하고 있다는 것을 본인은 행동으로 입증하고 싶다. 사상과 행적 모든 면이 우월하다는 것을 말이다.

Posted by 사무엘

2017/12/05 08:33 2017/12/05 08:33
, , , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1434

1. 트렁크에 싣는 물건들

차의 접지력을 위해서 일부러 무겁게 만드는 경우가 아니라면, 어지간해서는 트렁크에 쓸데없는 짐을 싣지 말고 차를 가볍게 유지하는 게 연비 운전의 정석이다. 하지만 평소에 차의 트렁크에 늘 실어 놓을 만한 물건도 전혀 없는 건 아니다. 생각해 보니 다음과 같이 인간 편의용과 차량 비상용으로 범주가 나뉜다.

  • 어디 여행 간 뒤, 현장에서의 인간 편의용: 돗자리, 담요(비행기 담요 같은..), 우산, 슬리퍼, 손전등, 식수, 나무젓가락, 종이컵, 상비약, 휴지/티슈
  • 차량 비상용: 소화기, 비상 삼각대, 경광봉과 건전지, (간단한 공구류와 스페어 타이어는 당연히..)

평소에는 워낙 조용하게 달리니 잘 모르겠지만, 자동차는 엔진 내부가 매우 뜨거우며 화재의 위험이 상존하는 물건이다. 굳이 냉각수 부족과 엔진 과열 때문이 아니어도, 운 나쁘게 엔진룸 속에 끼어들어간 종이· 나뭇잎 같은 이물질이 발화점 이상의 열을 받아서 불이 붙고, 그게 차량의 화재로 이어질 수 있다. 식당도 굳이 누전이나 가스 누출 같은 일이 없이, 환풍기에 낀 사소한 기름때나 먼지만으로 불이 날 수도 있는 것처럼 말이다.

또한, 큰 교통사고가 난 뒤에는 연료가 새서 케바케로 불이 나기도 한다. 승용차의 경우 엔진이 있는 앞쪽과 연료 탱크가 있는 뒤쪽 모두 안심할 수 없다.
이럴 때 소화기를 신속하게 꺼내서 연기와 불꽃이 최초로 모락모락 피어나는 곳을 적절하게 초기 진화해 주지 못하면.. 엔진 부분만 교체하고 끝날 것을 발만 동동 구르다가 차량 전체를 홀랑 태워먹고 전체 폐차라는 비극을 야기할 수 있다.

자동차는 뼈대만 쇳덩이일 뿐, 시트나 도색 등은 온통 가연성 화학물질이며, 불타면서 유독가스를 내뿜는 공해덩어리 그 자체다. 불 나서 좋을 것 하나도 없다.
말이 길어졌는데, 어쨌든 PC에 보안 업데이트가 필요한 것만큼이나 차량에는 소화기를 비치할 필요가 있다는 말을 하고 싶었다. 사고가 난 뒤에 2차 사고를 예방하는.. (나 여기 있소) 도구들은 두 말할 나위도 없고 말이다. 자동차 학원에서도 이런 물건들의 필요성을 더 진지하게 가르쳐야 하지 않나 싶다.

돗자리나 우산, 슬리퍼 같은 수준을 넘어서 아예 낚싯대· 골프채, 커다란 악기, 자전거 같은 걸 차에다 상시 실어 놓는 건...;; 글쎄, 정말 차를 오로지 레저와 여가용으로만 활용하는 게 아니라면 "화물은 차를 무겁게 할 뿐이야!"를 진지하게 고려해야 할 것이다. 그래도 자전거를 차에다 싣는 게 가능하면 차와 자전거의 활용성이 더욱 커져서 상호 win-win이 되긴 하더라. 차 트렁크도 충분히 커야 하고, 자전거도 접을 수 있는 구조여야 한다.

2. 자동차의 냉각수와 워셔액

자동차의 내부에 집어넣어서 비축하는 액체 중에 연료나 윤활유 같은 기름 계열 말고 '물' 계열 혼합물에 속하는 것은 엔진 냉각수와 와이퍼 워셔액 정도인 것 같다. 전자는 물의 높은 비열이 활용되고 후자는 물의 세척력이 쓰인다.
물론 두 액체의 용도와 성격은 서로 매우 다르다. 워셔액은 유리창이 깨끗하기만 하면 별로 쓸 일이 없는 선택사양이지만, 냉각수는 엔진의 가동과 직접적인 관계가 있는 필수품이다. 워셔액은 세척용으로 조금씩 소모되고 보충이 필요한 소모품인 반면, 냉각수는 누수 같은 이상 현상이 없는 한, 한번 주입해 준 게 반영구적으로 쓰인다는 차이가 있다.

순수한 물은 그리 낮지 않은 온도에서도 금세 얼어 버리며 금속류의 부식(녹)을 초래하기도 한다. 그렇기 때문에 두 액체 모두 부동액과 부식 방지 성분이 첨가된다. 동일하지는 않지만 공교롭게도 알코올 계열 화합물이 첨가되는데, 둘 다 인체에 아주 해로운 독극물이라는 공통점이 있다.

부동액의 첨가 성분인 '에틸렌 글리콜'은 물과 혼합될 경우 어는점을 영하 40도 아래로 크게 낮춰 준다. 성능 하나는 뛰어나지만 그렇다고 이것만 잔뜩 집어넣으면 반대로 물 고유의 냉각 성능이 저하되기 때문에 부동액을 아무리 많이 넣어도 물보다 많이 넣지는 않는다. 그리고 이 에틸렌 글리콜은 독약임에도 불구하고 투명한 외형에 꽤 달콤한 맛과 냄새가 나서 사람이나 동물이 실수로 마시고 훅 가는 사고가 세계적으로 종종 발생한다고 한다.

이거 무슨 농약도 아니고.. 그 맛과 냄새가 어떤지 개인적으로 궁금하다..;; 부동액이란 게 자동차에만 쓰이는 게 아니고 혹한의 건축· 건설 현장에서도 물이 들어가는 곳에 쓰이기 때문이다.
도로의 제설용으로 사용되는 염화칼슘도 물과 섞이면 수용액의 어는점을 역시 거의 영하 52도쯤으로 크게 낮춰 준다. 이 효과로 눈을 녹여 버려서 제설 효과를 낸다. 그러니 나름 제설에다 제습 효과까지 있는 물건인데.. 얘는 이미 짐작한 분도 계시겠지만 부식 문제가 있어서 부동액 용도로는 쓰이지 않는다. 뭐 부동액 얘기는 여기까지 하고..

와이퍼 워셔액은 비록 사람이 마시는 술 같은 액체는 아니지만 소독(?), 빠른 증발, 부동 효과를 위해 역시 알코올이 들어간다. 그런데 단가가 저렴하고 가성비가 뛰어나다는 이유로 메탄올이 들어가기도 한단다.
메탄올은 보다시피 극소량만 인체에 들어가도 신경을 마비시키고 눈을 멀게 하고 궁극적으로 생명까지 잃게 만드는 맹독이다. 선박이나 실험실 같은 데서 술 취한 기분 내고 싶어서 메탄올을 에탄올인 줄 알고 물에 섞어서 들이켰다가 골로 간 사람들.. 역시 없지 않다. 정상적으로 팔리는 술을 구할 수 없거나, 세금 안 붙은 저렴한 알코올을 섭취하고 싶어하는 상황에서 말이다.

2012년에는 워셔액을 술인 줄 알고 마시는 바람에 메탄올 중독으로 숨진 사람이 다윈 상 수상자 중 하나로 뽑히기도 했다! 하지만 이건 고의로 멍청한 짓을 한 게 아닌 단순 실수가 아니냐는 이견과 논란도 있다.

메탄올은 이렇게 입으로 들이키지만 않는다고 해서 장땡이 아니라고 한다. 앞유리에다 워셔액을 분사하는 경우, 메탄올이 소량이나마 기화한 형태로 차내에 유입되기도 한다. 워셔액 제조사들이야 그건 극소량이기 때문에 별로 문제될 게 없다는 입장이지만, 이제 대한 정밀한 임상 실험이 진행된 사례는 아직 없는 것 같다. 정 불안하면 좀 더 비싸더라도 에탄올 성분의 워셔액을 쓰는 수밖에 없다.

3. 차량의 외형과 내부 구조의 차이

트렁크와 객실(cabin)의 구분이 없는 해치백형 차량(SUV 포함)이 공간 활용성이 더 좋은 건 사실이다. 뒷좌석을 완전히 접거나 옮겨서 자전거를 접지 않고 그대로 실을 수 있고, 아니면 사람이 발 뻗고 눕는 공간을 만들 수도 있다.
무척 부러운 면모이긴 하지만, 이런 실용성과는 별개로 본인의 취향은 그래도 트렁크와 객실이 완전히 분리되어 있는 세단이 뭔가 안정적인 느낌이 들고 좋다.

하루는 회사 업무 때문에 짐을(컴퓨터 본체 여러 대 등..) 승용차의 트렁크와 뒷좌석에 이르기까지 잔뜩 실을 일이 있었다. 그런데 이 차는 회사의 이사· 사장급인 높으신(...) 분의 소유였고.. 그래서 대형 후륜구동이었다.
후륜구동은 잘 알다시피 뒷좌석 중앙 바닥이 구동축 때문에 위로 봉긋 솟아 있다. 요것 때문에 짐 싣는 데 의외의 어려움을 겪었던 걸로 기억한다. 그 일을 겪고 나니 뒷좌석 바닥이 그냥 평평한 내 차, 아니 요즘 대부분의 승용차들이 더욱 신기하게 느껴졌다.

하긴, 나 완전 어렸을 때 탔던 포니 택시도 뒷좌석 중앙이 봉긋 솟아 있긴 했는데, 저런 차를 참 오랜만에 다시 구경했다. 포니야 소형차 덩치밖에 안 되지만 아직 기술과 노하우가 부족해서 후륜구동으로 나온 것이다.

포니 1은 해치백처럼 생겼지만 실제로는 객실과 트렁크가 분리되어 있었으며, 트렁크를 열 때도 뒷유리는 고정된 채 아래의 몸체만 들려 올라갔다(4도어 일반 모델 기준). 즉, 사실상 세단이나 마찬가지였다. 해치백은 3도어 쿠페 모델에서 처음 적용되었으며, 그리고 후속작인 포니 2에서 완전히 해치백 형태로 바뀌었다고 들었다.

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

이런 내부 구조 말고 해치백은 세단과 달리 뒷유리에도 와이퍼가 달려 있는 게 특징이다. 뒷면의 유체역학적 구조상 트렁크가 튀어나와 있는 세단보다 뒷유리에 흙먼지가 더 잘 끼기 때문이라고 한다.

4. 자동차의 동력원

(1) 내연기관이 발명되자 처음에는 자동차, 열차, 비행기가 모두 휘발유건 디젤이건 피스톤 왕복 엔진을 동력원으로 사용했다. 그러다가 20세기 중반부터 비행기는 제트 엔진이 대세가 되었으며, 철도 차량은 주 동력원이 전기 모터로 바뀌었다.
덕분에 털털털 붕붕붕~ 이러던 엔진음이 다 바뀌었다. 제트기는 그 특유의 공기 뿜는 소리 덕분에 한때 '쌕쌕이'라고 불렸을 정도이며, 전철은.. 뭐 VVVF 인버터가 도입되면서 완전 전자악기 소리가 나기 시작했다.

결국 오늘날은 자동차만이 왕복 엔진을 꾸준히 사용하고 있다.
왕복 엔진이 배기가스를 내뿜는 건 그냥 연소가 끝난 잔여 찌꺼기를 내보내는 것이기 때문에 엔진 출력과는 무관한 메커니즘이다. 그러나 제트 엔진은 배기가스를 엄청난 고압으로 뒤로 내뿜어서 추진력을 낸다. 자동차와는 앞으로 나아가는 방식이 완전히 다르다.

이렇게 동일한 재료나 부품이 한 기술에서는 그저 그런 존재감인 것이, 다른 기술에서는 동작에 결정적인 역할을 하는 중요한 요소인 경우가 있다.
배터리가 기름 자동차에게는 그냥 객실 전원 공급과 시동 모터+점화 플러그 동작용이지만, 하이브리드나 순수 전기차에게는 차를 가게 하는 동력원 그 자체인 것,
그리고 변속기 오일이 수동 변속기에서는 정말 단순 윤활 기능만 하지만, 자동 변속기에서는 엔진과 바퀴 동력을 중재하는 완전 핵심 매체인 것처럼 말이다. 예전에도 언급한 적이 있지 싶다.

(2) 그리고 자동차가 처음 발명됐을 때 차의 가장 일반적인 형태는 전방 엔진, 후륜 구동인 일명 FR 방식이었다. 그러다가 승용차는 준대형급(대략 3000cc) 이하부터는 FF로 바뀌었고, 버스는 준대형급(35인승) 이상부터는 RR로 바뀌었다. FR은 이제 대형 승용차와 소형 승합차, 또는 크기 불문하고 트럭에서만 유지되고 있다.

(3) 전동차에 가변 전압 가변 주파수(VVVF) 인버터 기술이 있다면, 내연기관 자동차 엔진에도 공기를 흡입· 배출하는 밸브에 가변화 기술이 있다. 엔진 회전수에 따라 밸브의 여닫는 깊이를 지능적으로 조절하는 VVL (lift), 그리고 그 개폐 동작의 시점 자체를 조절하는 VVT (time). 흡기측과 배기측에 shaft를 구분한 DOHC 방식에 이어서 밸브 계통에 또 다른 발전이 이뤄졌다.

그리고 어느 분야건 양과 질, 주기와 강도를 조절하는 변수가 있다. 라디오에는 AM(세기)과 FM(주파수)이 있고, VVVF도 V는 전압(세기)이요 F는 주파수이다. 자동차에도 VVL은 강도이고 VVT는 타이밍이니까 동일한 개념이지 않은가?

5. 차량별 변속기 성향

자동차의 동력 변환 계통으로서 물리적으로 큰 바퀴와 작은 톱니바퀴를 맞물리게 돌아가게 하는 '기어'라는 건 꽤 간단하고 직관적이고 효율적인 수단이다.
그러나 200~300마력짜리 자동차를 넘어서 열차나 거대 건설기계 수준이 되면 미세한 출력 조절을 위해서는 가히 어마어마한 크기의 기어비와 다양한 단계가 필요해지는데, 이건 톱니바퀴만으로 감당할 수 없다. 바퀴가 너무 커지거나 개수가 늘고 무겁고 복잡해진다.

(1) 그래서 철도 기관차는 동력을 일단 변압이 자유로운 교류 전기로 바꿔서 전동기를 돌려서 움직이는 디젤 전기 기관차가 대세이며, 드물게 자동 변속기 같은 유체 토크 컨버터로 동력을 변환하는 차종도 있다. 과거에 다녔던 새마을호 전후동력형 디젤 동차가 이 범주에 속한다.
물론 이것들은 광원에다 비유하자면 직접조명에서 간접조명으로 바뀐 것과 같기 때문에 연비는 톱니바퀴 기어만치 좋지 못하다.

(2) 대형 버스와 트럭은 저 정도로 불가피한 상황도 아니고, 또 연비와 옵션 가격 같은 경제성 문제도 있기 때문에 오늘날까지 여전히 수동 변속기 차량이 대세이다.

(3) 그런데, 이 와중에도 예외적으로 자동 변속기가 기본인 대형 상용차도 있으니 바로 “저상버스”이다.
바닥이 워낙 낮아서 버스 엔진 출력 정도의 동력비를 감당할 기어박스 내지 굵고 긴 샤프트조차(운전석에서 뒤쪽의 엔진까지)도 장착할 수가 없는 관계로 불가피하게 자동 변속기를 쓴다. 변속 명령은 기계 조작이 아닌 전기 신호로 전하고, 실제 변속 역시 톱니바퀴가 아닌 토크 컨버터로 행한다.

사실, 옛날에 버스가 트럭과 별 차이 없는 전방 엔진 방식으로 만들어지던 시절에는 바닥이 왕창 높았을 뿐만 아니라, 아예 구동축이 차체의 아래 중앙을 관통했다. 그래서 고속버스의 경우 바닥 아래의 화물칸까지도 좌우로 서로 단절돼 있을 정도였다.
그때에 비하면 버스가 바닥이 정말 낮아지고 사람이 타고 내리기 좋아진 셈이다. 철도로 치면 고상홈이 도입된 것과 비슷한 변화이다. 이런 차들에 비해 대형 트럭을 타는 건 지금도 거의 등산 수준으로 힘들다..;;

(4) 끝으로, 저런 대형차와는 상극의 체격인 오토바이는 또 반대로 수동이 대세이다.
글쎄, 리터급의 고성능 대형 오토바이라면 모를까 100~300cc대의 그저 그런 모델의 경우.. 그런 엔진 출력과 차체 크기에다가 크고 무거운 토크 컨버터를 장착하는 것부터가 삽질이고, 전통적인 기어박스를 장착하는 게 훨씬 경제적이기 때문이다.
아주 쬐그만 스쿠터는 차라리 CVT가 달리면 달렸지, 어떤 경우든 통상적인 자동차용 자동 변속기 같은 물건이 달리는 일은 없다.

똑같이 공간이 없는데 그 양상이 저상버스와는 다르다는 것이 무척 흥미롭다. 대류권에서는 고도가 오를수록 기온이 내려갔다가 성층권에서는 다시 기온이 올라가는 것 같은 느낌이다.

6. 동력의 취합과 분산

자동차가 굴러가기 위해서는 엔진이 죽어라고 피스톤 왕복운동만 한다고 장땡이 아니라..
여러 개의 피스톤이 균등하지 않은 주기로 만들어내는 불연속적인 힘을 한데 부드럽게 합쳐 주는 플라이휠 같은 부품이 필요하다.
그리고 이 힘을 실제로 회전하는 바퀴에 부드럽게 분산해서 전달하는 주는 차동 기어도 변속기와는 별개의 계층으로서 필요하다. 커브를 틀 때는 커브 안쪽의 바퀴와 바깥쪽의 바퀴가 속도가 달라지기 때문이다. 컴퓨터에다 비유하면 CPU와 램뿐만 아니라 파워 서플라이도 필요하다는 뜻이다.

자전거 중에는 크랭크가 둘 달려서 앞뒤 사람이 모두 페달을 밟을 수 있는 물건이 있다. 이런 자전거는 개인이 구입해서 굴리기보다는 관광지 같은 데에서 대여하는 형태로 사용되는 편이다.
거기에서도 두 사람의 힘이 어떤 형태로 취합되는지 문득 궁금해졌다. 사실 자전거는 페달을 뒤로 밟았을 때 후진하지 않는 것도 신기하고 말이다.

Posted by 사무엘

2017/12/02 08:28 2017/12/02 08:28
, , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1433


블로그 이미지

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

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

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

Site Stats

Total hits:
2633945
Today:
743
Yesterday:
1754