본인은 평소에는 15년 넘게 개발하고 있는 날개셋 한글 입력기의 개발에 대부분의 역량이 집중되기 때문에 타 유명 프로그래머 고수들에 비해 타 플랫폼· 언어· 최신 프로그래밍 기술에 대한 개인적인 관심은 덜한 편이다. 뭐, 자주 언급을 안 할 뿐이지 직장에서는 아무래도 갑님이 시키는 대로 해야 하니, 무엇이건 업무와 생존에 필요한 최소한의 맛보기 정도는 한다. 다만 그런 생소한 분야는 본인이 특장점이 없이 그냥 여느 평범한 프로그래머 A, B의 역량과 다를 바 없다.

먼 옛날에 Windows API와 MFC, Visual C++를 처음으로 공부할 때 그러했고, macOS나 안드로이드 개발을 처음으로 익힐 때도 마찬가지이다. 코드와 리소스가 어떤 방식으로 연결되는지 감을 잡는 게 참 어려웠다. 이건 그야말로 프로그래밍 언어뿐만 아니라 각 플랫폼별 바이너리 실행 파일(DLL/EXE)의 구조, 개발툴의 기능에 대한 총체적인 이해가 필요한 부분이니까 말이다.

그래도 리소스(대표적으로 대화상자/화면 레이아웃)의 기술을 위해 XML을 쓰는 요즘 플랫폼에 비해, Win32 API의 rc 파일은 정말 구닥다리이구나 싶은 생각이 든다. 뭐, resource.h와 R.java처럼 개념상 일말의 공통점이 발견되는 것도 있다(개발툴이 자동으로 생성해 주는 리소스 ID 리스트).

또한 안드로이드의 경우, 굉장한 뒷북이긴 하다만 Eclair니 Froyo니 하던 시절과 비교했을 때 개발 환경이 몇 년 사이에 정말 엄청나게 달라져 있었다. 여전히 이클립스를 쓰는가 했더니 Android Studio라고 전용 개발툴로 진작에 갈아탔으며, 무엇보다 에뮬레이터도 x86과 arm이라는 엄청난 CPU 구조 차이를 어떻게 극복했는지 속도가 꽤 빨라졌다.
그도 그럴 것이 그 구글 내부에서 안드로이드 OS에만 달라붙어 있는 세계구급 날고 기는 프로그래머 엔지니어들이 도대체 얼마나 되며, 이들이 매일 생산하는 코드의 양은 또 얼마나 될까?

2010년대 이후에나 등장한 IDE가 copyright이 왜 엄청 옛날인 2000부터 시작하는지 궁금해서 검색을 해 봤더니.. 이건 그 옛날부터 개발되어 온 타 회사의 IDE를(이클립스 말고) Google이 인수해서 자체적으로 발전시킨 것이어서 그렇다고 한다. 으음..

이럴 때마다 늘 드는 생각인데, 새로운 문물이나 지식을 아주 빨리빨리 잘 익히고 남에게 가르치는 것까지 가능할 정도로 머리가 좋은 사람들이 개인적으로 굉장히 부럽다. 난 굳이 말하자면 애초에 남이 안 하는 짓을 골라서 하는 일에 일가견이 있다. 그래서 정보 올림피아드도 공모 부문에서만 입상하고, 코딩과 논문으로 그럭저럭 지금까지 지내 왔다.
그게 아니라 남과 똑같은 조건에서 뭔가를 빨리 달달 외우고 응용하는 능력이라면 본인은 남들 평균보다 못하면 못하지 결코 뛰어나지는 않다.

컴퓨터 쪽에 우글거리는 수많은 고수 괴수들 중에.. 김 상형 님이라고 한때 winapi.co.kr 이라는 사이트를 운영했고 지금은 '소프트웨어 공학'을 일본어 스타일로 축약한 '소엔'이라는 사이트로 여러 유용한 프로그램 개발 정보를 무료로 공유 중인 대인배가 계신다.
사이트 이름에서 유추할 수 있듯 한때 이분의 전문 분야는 Windows API였다. 텍스트 에디터를 그냥 C++만으로 혼자서 처음부터 끝까지 다 만들었고, 그 테크닉을 소스까지 통째로 책을 출간한 바 있다..;;

한 분야의 기술만 통달하기에도 벅찬데 이분은 안드로이드, HTML, 자바스크립트 등 온갖 분야를 다 탐독해서 책을 쓰고 학원 강사로 뛰고 있다.
그냥 위에서 내려오는 회사 업무나 감당하기 위해서 여러 기술들을 찔끔찔끔 서바이벌 수준으로 익히는 게 아니다. 그야말로 남을 가르치고 책을 쓸 정도로 전문가가 되기 위해서 혼자서 도대체 공부를 어떤 방식으로 얼마나 한 걸까? 비결이 궁금해지지 않을 수 없다.

이렇게 강의와 저술만으로 먹고 사는 데 지장 없는 분들은 굳이 회사 들어가서 조직에 매일 필요가 없다. 물론 프리랜서는 월급쟁이보다야 소득이 훨씬 불안정하고 복불복이 심하다. 보통은 자기 친구들에게도 "걍 회사에서 월급 받으며 지내는 게 짱이야, 아무리 엿같은 동료나 상사가 있더라도 어지간해서는 거기서 절대로 뛰쳐나올 생각 마라" 이렇게 권유를 할 정도라고는 하지만..
이것도 자기 하기 나름이다. 엄청난 능력자라면 을임에도 불구하고 여러 기업들을 상대로 갑질을 하면서 자유롭고 편하게 일을 할 수도 있을 것이다.

그리고 컴퓨터가 나왔으니 영어도 빠질 수 없다.
지금보다 자료 접근성이 훨씬 열악했던 옛날에 독학으로 이를 악물고 영어를 마스터해서 198, 90년대에 이미 유명 영어 교재의 저자로 등극한 사람들이 참 대단하다는 생각이 든다.
최 은경 어린이 영어, 오 성식 생활 영어/pops English, 김 인환, 정 철 ... 그리고 최근에는 Arrow English로 유명한 최 재봉 이런 분들.

난 무슨 영문과 교수나 영어 교사, CNN 리포터-_-;; 이런 거 지향하는 게 아닌 이상, 국내에서 영어 때문에 스트레스 받을 일은 없는.. "반도 토박이치고는 뭐 그럭저럭 하네" 딱 그 정도까지만 영어가 된다. 자막 없이 영화를 다 알아듣거나, 토익 만점 이런 경지는 아니다. 그리고 그마저도 나이는 자꾸 먹고 있는데 영어를 당장 쓸 일은 없으니 감이 점점 쇠퇴-_-하는 중이다.
도무지 들리지가 않는 것, 그리고 아무리 머리를 짜내도 독해 속도를 도저히 더 올릴 수 없는 건 그냥 내 머리의 한계인 것 같다.

영어를 잘하려면 뭐 영어식 사고방식과 어순 감각을 익혀야 되고 무슨 발상의 전환을 해야 하고.. 이런 것들은 그냥 기초가 없고 첫 단추부터 완전 잘못 끼운 생짜 영어 포기자한테는 꽤 유효한 조언일지 모른다. 영어 점수 2~30점을 6~70점으로 올리는 데는 도움이 될 것이다.

하지만 90점을 95점으로 올리는 건 무리임. 저런 기초적인 문법과 어순 감각은 이미 다 갖춰져 있고, 거기서 상위권에서 최상위권으로 가려면 그냥 닥치고 영어라는 빅데이터에 수시로 많이 노출돼서 감을 유지하는 것밖에 답이 없다. 외국 어학 연수는 개나 소나 아무나 가는 게 아니라 딱 이 정도 기초가 갖춰진 애들이 가야지 효과가 높아진다.

그런데, 저런 여러 영어 전문가들이 공통으로 말하는 영어 마스터 비결은.. 학창 시절에 영어 교과서 텍스트들을 몽땅 통째로 암송· 암기했다는 것이다. 사실 인간의 언어에는 굉장히 무작위하고 arbitrary하고, 그냥 문맥이 곧 용례를 결정하는 그런 정보가 많다. 암송· 암기는 학습자에게 괴로운 과정이긴 하지만 그래도 그거 효력은 확실한가 보다.
나도 테이큰의 전화 통화 대사 40초 분량은 통째로 줄줄 외우고 있긴 하다만.. -_- I don't know who you are ... I will find you. And I will kill you. 같은 거.. 그런데 영어를 잘하려면 그런 거 암기를 더 많이 해야 한다.

일본은 개개의 국민들이 다 영어를 못 하더라도 국가 차원에서 번역을 엄청 많이 잘 해 놨다고 그런다. 하지만 우리나라는 모든 국민들이 다 영어를 잘하는 것도 아니고, 번역을 깔끔하게 잘한 것도 아니니 뭔가 문제가 있어 보인다.

끝으로, 어려운 과목의 끝판왕인 수학이 있다. 수학은 영어와 달리 유행을 별로 안 탄다. 한편으로는 노력한 만큼 그대로 결과가 나오는 참 정직한 과목 같으면서도, 한편으로는 타고난 머리 지능빨을 타니 불공평한 면모가 느껴지기도 하는 과목이다.
수학에는 '정석' 책 하나로 그야말로 억만장자가 되고 우리나라에서 최고로 성공한 사람이 있다. 물론 이분 역시 머리가 공부벌레 괴수급이었으며, 굳이 책 안 쓰고 학원과 과외 강사료만으로도 그 옛날에, 겨우 20대 나이로도 왕창 잘나갔을 정도로.. 비범했다.

그런 정석의 저자가 말하는 수학 잘하는 비결은.. 수학은 처음에 느리고 시간이 걸리더라도 직접 계산해 보고 손으로 일일이 쓰면서 감을 익혀야 한다는 것이다. 그런 감이 생겨 있지 않은 사람이 눈으로만 보고 넘어가서는, 그리고 덥석 해설과 풀이를 봐서는 진짜배기 수학 실력이 절대 늘 수 없다고.. 참 너무 원론적이고 당연한 조언을 한다. 그건 게임으로 치면 그냥 무한 맵에 치트키 쓰는 것이나 마찬가지니까.

그리고 저 말을 프로그래밍에다가 적용하자면.. 일일이 직접 코딩해 보고 돌려 봐야 실력이 는다는 말과 일맥상통한다. 그 점은 본인 역시 적극 동의한다.
아무 감도 없는 사람이라면 노가다 코딩이라도 해 봐야 된다. 그런 경험을 많이 해 봐야 노가다 코딩을 왜 '노가다'라고 부르는지 그것부터 좀 알게 된다.

개발자, 프로그래머로 먹고 살려면 솔까말 트리 구조 순회 같은 재귀호출을 스택 배열로 직접 구현하기, 포인터 조작으로 연결 리스트의 원소 배열을 역순으로 바꿔치기 정도는 머릿속에서 로직이 어느 정도 암산이 돼야 하고, 굳이 컴퓨터가 없이 화이트보드 앞에서도 의사코드를 쓱쓱 적을 수 있어야 하지 않는가?

사실, 유수의 IT 업체들이 학-석사 급의 엔지니어를 뽑을 때 코딩 면접도 딱 이 정도 수준의 난이도가 나온다. 무슨 "B+ 트리를 구현하시오, 동영상 압축 알고리즘의 모든 과정을 설명하시오"가 아니다. 그리고 크고 유명하고 재정 넉넉한 기업일수록 당장 현업에서 쓰이는 HTML5니 자바스크립트니 언어 문법 지식보다는 저런 미래의 잠재성과 응용력, 새로운 기술을 더 본다. 능력 함수에서 현재의 f(x) 값보다 도함수 f'(x)를 말이다.

다시 말해, 최신 자바스크립트나 HTML5 API 지식이 필요하지 않으니까 당장 그런 걸 모르는 사람도 OK 하고 뽑는 게 아니다.
오히려 그 반대로.. 하나도 모르는 상태로 입사했더라도 현업에서 그런 것쯤은 30분 만에 즉석에서 공부하고 숙달될 능력이 있으니까 뽑는다는 뜻이다. 요구 사항이 훨씬 더 고차원적이다.

컴공과 수학의 관계는 어떨까? 물론 완벽하게 동치는 아니다. 기하 알고리즘을 구현하고 있는데 삼각형 넓이나 세 점의 방향을 구하는 공식, 3차원 공간에서 두 벡터에 대한 나머지 기저를 구하는 세부적인 외적 공식 같은 거야 당연히 까먹을 수 있다. 하지만 기억이 안 나면 당장 검색이라도 할 수 있으면 아무 문제될 것 없다.

단지, 수학은 그렇게 문제를 쓱쓱 풀어 나갔던 경험, 단 한 가지 경우라도 놓쳐서는 안 되고 논리적으로 완벽해야 한다는 그 관념이 나중에 프로그램을 짜는 데 낯설지 않은 정신적 자산으로 작용할 수 있다고 본다.
물론 그런 관념이 오로지 반드시 학창 시절의 수학 문제 풀이를 통해서만 형성될 수 있다는 건 아니겠지만 말이다. 기본적인 머리가 있고 필요를 느끼면 결국은 나중에 다른 경로를 통해서라도 적응은 하게 돼 있다.

어휴.. 나도 말은 이렇게 써 놨지만.. 당장 어떻게 풀어야 할지 모르는 어려운 문제를 대면하면 이게 도대체 지금까지 수업 시간에 배웠던 기본 수학 공식이나 법칙과 무슨 관계가 있고 무엇부터 적용해야 할지 막막한 게 많다. 맨날 이런 기억과 경험만 쌓이다 보면 그 누구라도 수학이 싫어질 수밖에 없고 수학을 포기할 수밖에 없을 것이다.. -_-;; 세상에는 나랑 나이 차이도 별로 안 나던 시절에 그런 문제를 생각해 내고 '만든' 사람도 있구만.. 참 자괴감이 든다~!!

Posted by 사무엘

2017/10/22 19:35 2017/10/22 19:35
, , , ,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1419

Trackback URL : http://moogi.new21.org/tc/trackback/1419

Comments List

  1. boolsee 2017/10/23 09:11 # M/D Reply Permalink

    사무엘님께서 이런 글을 쓰실 줄이야! 조금 당황스럽습니다. :) 제 관점에서는 사무엘님도 대.단.하.신 네임드 중 한 분이십니다만....
    글 내용에는 많은 부분에서 공감합니다. 나이가 들어가면서 나만 정체되어 있다거나 특별한 성과가 없다고 느껴지거든요.사실이 그런가는 차치하고 내 스스로가 한없이 작아지는 느낌? :)
    사람 사는 생각이 비슷한가 봅니다.

    1. 사무엘 2017/10/23 11:00 # M/D Permalink

      제가 본문에서 언급된 다른 사람들만치 공부 잘하고 머리가 빨리 잘 돌아갔으면 지금 겨우 날개셋 정도의 프로그램은 10년 안에 10.0까지 다 만들고 학위도 다 마치고 현재는 딴 일을 하고 있지 싶습니다.. ^^;;
      저도 제 자신이 한없이 작다는 느낌을 늘 받습니다.

Leave a comment

2017년의 국내 철도 동향

1. 경부선 ITX 청춘

한동안 열차 시각표를 안 보고 지냈는데 오랜만에 최신판을 받아 보니 흥미로운 변화들이 많이 눈에 띈다.
잘 알다시피 2010년대부터는 생소한 동력분산식 전동차들이 잔뜩 도입되어 과거의 기관차-객차 패러다임을 뒤흔들어 왔다. 경부선에는 서울-수원/천안 급행 전동차의 상위 호환인 듯한 '누리로'가 무궁화호를 조금씩 대체하고 있다. 서울-부산 풀코스는 아니고 서울-신창처럼 반쯤 광역전철 같은 고유한 노선 위주로 달리는 중이지만, 명절 때는 누리로도 대전 정도까지는 간 적이 있으며, 호남· 전라선으로는 이미 풀코스를 뛰고 있다.

누리로가 경부선 전구간을 '누빌/릴' 날이 얼마 남지 않았다. 하지만 현재는 경부선 본선 말고 다른 노선이나 관광 열차로 뛰는 차량이 많은지라, 누리로의 서울-신창 편도 운행 횟수는 하루 2회꼴로 크게 감소해 있다. 이것도 완전히 폐지될 뻔한 것을 지역 주민들이 민원을 넣어서 2회라도 건진 거라고 한다.

한편, 누리로와는 달리 ITX-새마을은 이미 기존 새마을호를 완전히 대체했다. 2017년 현재, 과거의 새마을호는 장항선에서나 어제 오늘 하면서 연명하는 중이다. ITX-새마을은 도입 컨셉부터가 광역전철과는 딱히 연결 고리가 없다.

그런데 이 와중에 경부선의 용산-대전 구간에 한해서 ITX-청춘이 소수 편성되었다니, 굉장히 참신하게 다가온다. 경춘선의 전유물이던 2층 객차 열차가 경부선에도 납셨다니~! 게다가 얘는 영등포에 정차하지 않는 주제에 서울의 노량진과 신도림 역에도 정차한다. 노량진이라고 해서 지금 버려진 일반열차 플랫폼을 이용하는 건 아니고, 거기서는 애초에 그냥 전철 선로와 승강장을 사용하는가 보다. 그래야 신도림에 정차가 가능할 테니 말이다.

이런 이유로 인해 경부선은 온갖 철도 차량들의 각축장이 됐다.
재래선이 이렇게 된 동안, 고속선은 잘 알다시피 기존 KTX와 수서 고속철 SRT가 섞이면서 한 선로에 둘 이상의 회사에 소속된 열차가 다니게 되었다.
지금까지 이런 운행 패턴은 서울 지하철과 코레일의 직통 구간에서만 볼 수 있었지만 앞으로는 고속선이라든가 공항선 등 다양한 철도에서 흔히 보게 될 것이다. 일례로 공항선은 코레일 공항철도(기존 공철)뿐만 아니라 KTX가 다니고 있으며, 앞으로는 서울 지하철 9호선조차 직통 운행을 할지 모르는 상황이지 않던가?

그런데 SRT는 율현 터널 구간에 진동이 그렇게도 심한가 보다. 본인은 아직 거길 타 본 적이 없어서 모르겠는데, 타 본 지인들의 증언이 일치하는 편이다. 승차감이 KTX 고속선과 비교했을 때 어떤지 어서 체험해 보고 싶다.

2. 중앙선 지평 역

수도권 전철에서 차가 극도로 안 다니는 최하위권 역 내지 노선을 꼽자면 경부선 천안 급행이나 경의선 신촌, 광명 셔틀을 꼽을 수 있을 것이다. 그런데 이를 능가하는 역이 올해에(2017년 1월) 하나 더 생겼으니, 바로 중앙선 지평 역이다. 광역전철 역세권에서 아슬아슬하게 제외된 지역 주민들의 편의를 위해서 종점인 용문의 바로 다음 역에도 일부 전철을 운행시키기로 한 것이다.
그리고 수도권 전철 중앙선은 궁극적으로 무려 원주(...!)까지 연장 계획이 있으므로 미리 이렇게 역을 만들어 놓는 것이 어차피 나쁠 것도 없다.

다만, 현재 지평 역은 열차가 하루에 편도 4회밖에 운행하지 않으니.. 서울-천안 급행과 비슷한 급의 레어템이다. 장암이나 옛 보정(분당선), 서동탄처럼 차량 기지 안에 임시로 만든 역도 아니고 위상이 조금 독특하다.

3. 기존 서울 지하철의 연장

경전철 말고 기존 서울 지하철(+수도권 전철)들도 생각보다 많은 노선들이 연장 공사가 진행 중이다.

  • 1호선: 지하철이나 도시철도가 아닌 광역전철의 영역이긴 하지만, 북쪽 경원선 구간이 소요산보다도 더 길어져서 연천까지 연장 예정이다. 단, 복선은 아니고 2~30분 간격으로 단선전철 형태로. 통근열차의 최후 구간까지 전동차가 쓱싹 해 버리고, 그보다 더 북쪽까지 가는 건 안보 관광 패키지 열차가 역할을 대신할 것이다.
  • 4호선: 당고개 이북으로 산을 뚫고 남양주 진접면까지 연장 예정이다. 이 기회에 창동 차량기지도 거기로 이전하게 된다.
  • 5호선: 상일동 지선의 종점이 동쪽으로 더 연장되어 하남시 미사 신도시와 검단산 기슭까지 간다.
  • 7호선: 부평구청보다 더 서쪽으로 인천 지하철 2호선 석남 역까지 연장 공사 중임.
  • 8호선: 암사 이북으로 남양주 별내까지 연장된다. 8호선도 드디어 강을, 그것도 하저터널로 건너는 지하철이 된다.
  • 9호선: 종합운동장보다 동쪽으로 더 나가서 보훈병원, 일자산 기슭까지 연장될 예정이다. 8호선과는 1990년대의 계획이던 몽촌토성이 아니라 석촌역에서 만나게 된다. 그래도 아직까지는 유일하게 여전히 '인서울' 연장이다.

이들과 달리 3호선은 2010년의 오금 연장 이후로 딱히 더 연장 공사 중인 게 없다. 그리고 6호선도 봉화산에서 조금만 더 가서 그냥 자기 차량기지 안에다가 신내 역을 만들어서 경춘선과 환승시키자는 떡밥이 있지만, 주민들의 적극적인 요구가 있지는 않고 진행이 지지부진하다.

말단이 광역전철과 연결되어 연장된 것을 제끼고, 서울 지하철이 지하철 명목으로 처음 계획되었던 구간보다 더 연장된 것은 현재 3호선(양재 이남으로 수서, 오금)과 7호선(온수 이남으로 부평구청)이 존재한다. 9호선은 신논현-종합운동장은 처음부터 계획된 게 완공된 것이고 이보다 더 동쪽이 추가 연장 구간이다. 앞으로 그런 연장 구간이 4, 5, 8, 9호선에도 생길 것이고, 7호선은 연장 구간이 더 길어질 것이다.

이건 3기 지하철이라고 보기에는 타이밍이 한 박자 좀 늦은 것 같고, 서울 경전철과 더불어 3.5나 제4기에 가까운 트렌드로 봐야 할 듯하다.
서울의 동쪽으로 철도 불모지이던 하남에도 드디어 저렇게 지하철이 들어오게 됐는데, 서쪽의 철도 불모지인 김포는 사정이 어떤가 모르겠다. 거기는 9호선과 연계되는 별도의 경전철이 건설 중이라고 들었다.

4. 서울 서쪽의 신규 종축 철도

1988년에 개통한 안산선은 금정에서 한대앞 역까지는 고유한 구간이지만, 한대앞에서 오이도까지는 기존 수인선과 선형이 동일한 구간이다. 다만, 처음에 개통은 금정에서 안산까지 하고, 안산에서 오이도는 추후 2000년에 개통했다.
이 안산선이 2010년대에는 드디어 수인선과 앞뒤로 수평 연결되었으며, 미래에는 수직으로 환승역이 하나도 아닌 둘이나 생길 예정이다.

하나는 한국 철도에서 코레일 타임 티스푼 공사의 전설이 아닌 레전드인 '신안산선'이다. 얘는 안산선 '중앙' 역과 환승되며, 목감· 광명 일대를 지나서 영등포와 여의도까지 갈 예정이다. 즉, 서울 방면이다. 과거에 계획되었던 서울 지하철 10호선의 대체 노선이며, 얘의 착공과 개통이 너무 늦어졌기 때문에 광명 역의 대중교통 연계가 안습해진 면이 있다.

다른 하나는 신안산선보다 더 서쪽으로 지나는 소사-원시선이다. 얘는 단순 광역철도 수준을 넘어서 장거리 간선 철도이며, 초지(구 공단) 역과 환승된다. 위로는 경인선 소사 역과 만나서 대곡까지 갈 예정이며, 밑으로는 안산시 단원구 저 끝의 원시동까지 간다. 얘 덕분에 시흥시의 교통도 더욱 편리해질 것으로 기대된다.
동해 방면으로는 경강선과 동서 고속화 철도, 동해선이 계획 중이라면, 서해 방면으로는 이런 철도가 계획되고 있다.

5. 한국 철도 차량의 등급과 유형별 도입과 퇴역 내력

끝으로, 이걸 정리해 보았다.
아래 표를 달달 외워서 머리에 다 집어넣고 의미를 이해한 분이라면 철덕의 기본적인 자질은 갖췄다고 볼 수 있겠다.

  동차형 기관차+객차형
새마을호 먼 과거 DEC: 1980년 도입되었다가 유선형 객차 도입과 함께 무궁화호로 격하, 2001년 퇴역.

가까운 과거 DHC: 1987. 7. 6. 대우중공업 제조 전후동력형 동차와 함께 도입. 동력집중+유압 변속
그 뒤 94년까지 현대· 한진중공업 차량이 추가 도입. 2013. 1. 5. 전량 퇴역함

현재 ITX-새마을 전동차
1974. 8. 15. 관광호의 후신으로 새마을호 차급 도입.
1985. 11. 16. 서울-부산 4시간 10분 증속.
1986. 7. 12. 현대정공 제조 7000호대 새마을호 견인 전용 봉고 기관차 + 유선형 객차 도입. 일부 객차는 훗날 무궁화호 특실로 격하됨.
2012. 11. 28. 봉고 기관차 천량 퇴역
2015. 4. 2. 경부선 정규 노선 퇴역. 모두 ITX-새마을 전동차로 대체되고, 재래식 객차형 새마을호는 이제 장항선에만 남아 있음.
무궁화호 먼 과거 EEC: 1980년 DEC와 함께 도입되었다가 1998. 12.부터 통일호로 격하. 2001년 퇴역.

가까운 과거 NDC: 1984년 도입되어서 시종일관 무궁화호 등급으로 운행함. 최후에는 경부선 경전선 영남 구간에서만 운행되다가 2010년 전량 퇴역. (차급 변경 없이 시종일관 무궁화호 유지)

현재 TEC 누리로: 단, 위상만 무궁화와 동급이지 기존 무궁화호를 대체하는 운행을 하지는 않고 있음
명칭 자체는 1960. 2. 21. 등장.
현재까지 비전철 구간을 다니고 있는 가장 만만하고 무난한 일반열차의 대명사.
통일호 CDC: 타 차급에서 옮겨온 것 말고 처음부터 통일호로 만들어진 동차는 이게 유일함. 1996~1999년 도입. 2008년부터 이들 차량은 RDC 무궁화호, 관광열차 등으로 개조됨.
현재 정규 노선은 '통근열차'라는 이름으로 경원선 소요산 이북 구간에만 남아 있고, 수도권 전철 1호선이 연천까지 연장되면 폐지 예정.
통일호만 유일하게 동차형이 객차형보다 더 오래 존속 중임.
명칭 자체는 1954. 8. 15. 등장.
차급 인플레로 인해 서서히 격이 낮아지다가 2004. 3. 31. 고속철 개통 바로 직전에 전량 퇴역.
최후에는 중앙선 근성열차와 경춘선에서 운행 중이었음.
비둘기호 제조사의 이름을 따 니가타/가와사키 디젤동차 등으로 불림. 경의선, 교외선 등을 다녔고, 수인선 협궤 동차도 등급상 비둘기호임.
1960년대 중후반에 두루 도입되었다가 8~90년대에 통일호 격상 등을 거친 뒤 폐차됨. 정확한 시기 불명.
여러 최하위 등급 완행열차들이 최초로 이 명칭으로 통합 정립된 것은 1984. 1. 1.
리즈 시절엔 전국을 누비기도 했으나 1998. 11. 30. 정선선만 남기고 모두 폐지.
정선선도 기관차+객차형이 다니다가 2000. 11. 14. 마지막 운행 후 폐지.

Posted by 사무엘

2017/10/19 19:36 2017/10/19 19:36
,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1418

Trackback URL : http://moogi.new21.org/tc/trackback/1418

Comments List

  1. 비밀방문자 2017/10/22 19:22 # M/D Reply Permalink

    관리자만 볼 수 있는 댓글입니다.

    1. 사무엘 2017/10/22 23:14 # M/D Permalink

      그렇다? 후훗~ 거의 2010년대 초에 잠깐 있었다가 폐지됐던 특별급행..;; 그게 다시 부활하기도 했군? ㅋㅋ

Leave a comment

우리나라에 원자력 발전소가 처음으로 지어지고 가동된 건 고리 원자력 발전소로, 박통 말기인 1970년대 말이다. 그게 법적 설계 수명이 다 된지라 이제 가동 중단과 해체 단계에 진입해 있다.

원자력 발전의 건설과 운영은 당연한 말이지만 엄청난 과업이며, 하루아침에 이뤄진 일이 결코 아니다. 박통 이전에 할배 대통령부터가 원자력에 지대한 관심을 갖고 있었으며, 저게 이렇게 석유 한 방울 안 나는 반도에서 나라를 먹여 살릴 기적의 에너지원이라고 생각했다.
그도 그럴 것이, 평생 자기 조국의 숙적 원수요 전쟁 미치광이였던 일본을 단번에 거꾸러뜨리고 항복시킨(결과적으로 대한민국 해방과 독립을 가져다 준!!) 무시무시한 폭탄이 바로 원자폭탄이지 않던가? 그러니 원자력을 보는 할배의 눈빛은 남다를 수밖에 없었다.

할배 대통령은 그 열악한 전쟁 폐허 여건에서도 서울대에 원자력 공학과를 신설할 것을 지시하고, 미국을 설득해서 시험용 원자로를 도입했으며 원자력 연구원의 전신인 원자력 연구소(1959)를 만들었다. 박통이 70년대에 KIST와 국방 과학 연구소(ADD)를 만들었으나, 할배는 그보다도 전에 원자력에 지대한 관심을 보이고 있었다는 뜻이다. 이 점을 밑줄 치고 외우시길 바란다.

그리고 국비 장학 유학 제도를 통해 원자력 공학 공돌이 전문가들을 양성했다. 외화 한 푼이 아까울 정도로 가난하던 시절에도 교육을 위해서는 저렇게 투자를 아끼지 않았다. 이런 사전 준비가 있었기 때문에 훗날 박통 때 이 땅에 원자력 발전소가 가동될 수 있었다. 핵무기나 만들어서 북괴처럼 세계 평화를 위협하고 깽판 치기 위해서가 아니라 정말 먹고 살기 위해서, 풍요로운 미래를 만들기 위해서 원자력 기술을 도입했다.

본인은 원자력 발전의 적극 찬성론자이다. 화석 연료는 산림 황폐화를 예방해 주고, 원자력 에너지는 화석 연료의 부담을 덜어 준다는 원리를 왜 다들 모르는 걸까? 우리나라는 그저 품종 개량하고 나무를 무작정 심기만 해서 산림 녹화에 성공한 게 아니다. 땔감용으로 나무를 벨 일을 없게 만드는 과업이 성공했기 때문에 궁극적으로 녹화를 성공할 수 있었다. 바로, 런던 스모그의 주범이기도 한 그 더티한 석탄의 대규모 보급이 전국적으로 적절한 타이밍에 이뤄진 것이다. 그리고 이런 이유로 인해 우리나라의 산림 녹화 성공 사례가 아무 못사는 민둥산 나라에나 선뜻 도입 가능하지가 않은 것이다.

이런 큰 효과에 비해 대기오염이나 방사능 위험은 각각 따로 대책을 수립해서 해결해야 할 작은 부작용일 뿐이다. 다른 대안도 없는 주제에, 석기 시대로 돌아갈 생각도 없으면서 원자력 발전을 굳이 핵 발전이라고 부르면서 정작 북핵과 미사일엔 절대 침묵하는 애들을 난 개인적으로 굉장히 싫어한다. 그 대신..

사용자 삽입 이미지

나도 저 트루먼 대통령처럼 껄껄 웃어 보고 싶다~!! ㅋㅋㅋㅋㅋㅋ
언제 어디서든 누구에게든 말은 아주 젠틀하고 부드럽게, 공손하고 댄디하게 하되, 허리춤에는 커다란 몽둥이를 들고 있으면 된다.
요즘은 저 리스트에다가 "둠가이와 존나 크고 아름다운 총" 컷도 하나 더 들어가야 할 것 같긴 하다.

(뭐, 트루먼 대통령은 실제로는 잘 알다시피 마냥 저런 대마왕이 아니었다. 미국의 너무 호전적인 장성들이 6· 25 전쟁 중에 한반도에다 핵을 또 터뜨리려는 걸 오히려 저지하기도 했다.. ㅎㅎ)

아무튼.. 원자력은 이 승만 때 이래저래 뿌려졌던 씨가 박 정희 때 결실을 거뒀다. 그런데 그 다음으로 컴퓨터는... 박통 때 뿌려졌던 씨가 그 다음 전대갈 때 결실을 거뒀다고 보는 게 타당하겠다.
물론 컴퓨터 자체야 박통 때 국내에 첫 도입됐으며, 70년대부터 각종 행정 서비스의 전산화가 찔끔찔끔 진행되기 시작했다. 하지만 이때의 컴퓨터는 관공서와 연구소에서나 볼 수 있는 크고 아름다운 기계였지, 개인이 쓸 수 있는 물건은 아니었다. 천공 카드, 자기 테이프.. 아직 뭐 이러던 시절이다.

그러다가 1980년대에 와서야 일반 서민들도 정보화 시대라는 걸 체험할 수 있을 정도의 변화가 터져나왔다. 1983년에는 삼성 전자에서 반 년간 공돌이들을 갈아넣은 끝에 64K디램 메모리 반도체를 개발했고 그와 별개로 SPC-1000이라는 8비트 컴퓨터를 만들어 냈다. 경쟁사인 금성사에서도 곧 금성 패미콤을 만들었다.

1984년에는 철도청에서 최고급 열차인 새마을호부터 승차권 전산 발매를 시행했다. 지하철 승차권 같은 딱지(에드몬슨..) 말고 일명 전산 승차권이라는 게 이때부터 최초로 발급되기 시작했다는 뜻이다.
전산화 이전에는 열차의 좌석 배당이 어떻게 이뤄졌는지 모르겠다. 행정 착오로 인해 한 좌석에 두 사람이 중복 배당되기도 했을 테고, 아니 옛날에는 애초에 지정석보다는 자유석 위주로 승차권이 발매됐지 싶다.

또한 이 해엔 한국 정보 올림피아드의 전신인 전국 단위의 PC 경진대회가 최초로 개최되기도 했다. 이건 대통령이 직접 관심을 갖고서 거절할 수 없는 규모의 상을 걸고 정말 성대한 규모로 치러졌었다. 이 당시에는 심지어 일반부(대학부를 초월하여!)까지 있었는데, 1990년대 중반부터 정보 올림피아드로 바뀌면서 대회의 범위가 국제 규격에 맞게 대학 미취학 연령으로 조절되었다. 흥미진진하지 않은가?

뭐, 컴퓨터뿐만 아니라 자동차도.. 박 정희 때 이제 막 고속도로가 닦이고 자동차도 일정 수준 이상의 국산화율을 달성한 생산이 시작됐다. 하지만 서민이 체감할 정도의 본격적인 마이카 시대는 잘 알다시피 1980년대에 가서나 이뤄졌다.

그렇게 우리나라는 분야별로 차근차근 산업화하고 발전해 왔다. 지금이야 어디 깡촌에 고속도로가 개통하면 "또 어디 개통하나 보네~ 내비 업데이트나 해야겠네" 짤막하게 뉴스로 나오고 말지만.. 옛날에 경부 고속도로가 처음 개통했을 때는 임팩트와 포스가 지금과는 가히 넘사벽이었을 것이다. 지금은 경부 고속도로 같은 길이의 거대한 고속도로를 한번에 만들 일 자체가 없어졌기도 하고 말이다.

또한, 옛날에는 탈북자의 귀순은 대대적인 뉴스감 및 선전거리였다. 그러나 지금은 탈북자가 1년에 몇만 명씩 내려오고 체제 선전이나 경쟁 따위도 전혀 할 필요가 없으니, 이제는 아주 유명한 사람이 아닌 이상 그냥 "병사 1명 군사분계선 넘어서 귀순, 서해상으로 탈북" 한 줄 보도로 끝이다. 이름 같은 신상은 밝히지도 않는다. 63 빌딩과 서울 타워를 구경시키면서 남조선의 발전된 모습을 보여주는 관행 역시 없어진 지 오래이며, 그냥 국정원 소속의 탈북자 신문 센터와 하나원으로 직행이다.
초딩 시절에 김 만철 씨 가족의 해상 귀순과 <광호의 일기> 책을 봤던 세대로서 이것도 격세지감이 느껴진다.

Posted by 사무엘

2017/10/17 08:34 2017/10/17 08:34
, , , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1417

Trackback URL : http://moogi.new21.org/tc/trackback/1417

Leave a comment

본인은 초딩 시절에 어렴풋이 경험했던 옛날 컴퓨터 환경의 추억을 회상하는 일에 관심이 많다. 16비트 환경은 베이직 이외에 C/C++ 같은 급의 언어로 프로그램을 직접 개발한 경험이 전무하기 때문에 더 관심이 간다.
그래서 블로그에서 API 썽킹 얘기도 한번 했고, 1년 남짓 전에는 Windows 9x 시절에 악명 높던 리소스 퍼센티지를 32비트 프로그램에서 직접 구하는 방법까지 옛날 책을 뒤져가며 복습해 봤다. 이번에는 이와 관련하여 지금까지 다룬 적이 없었던 다른 기술 얘기를 좀 해 보겠다.

시대를 풍미했던 Windows 9x는 왜 그리도 블루 스크린(BSOD)이 자주 뜨고 불안정했을까? 흔히 지저분한 16비트 코드 잔재 때문이라고들 그런다.
80386급 이상의 CPU에서 제공되는 보호 모드, 가상 메모리 같은 기술을 적극적으로 활용하면 굳이 그렇게 허접한 운영체제가 만들어질 일이 없다. 하지만 문제는 단 하나.. CPU가 원론적으로 제공하는 기능들을 제대로 활용해서 이상적인 운영체제를 만들려면, 당시 서민들이 범접할 수 없던 엄청난 메모리와 속도빨이 필요하다는 것이다.

Windows 9x는 Windows NT와 같은 최신 32비트 선점형 멀티태스킹 환경뿐만 아니라 기존 16비트 도스/Windows 프로그램과의 호환성도 놓치지 말아야 하고, 이런 모든 미래와 과거 이념을 Windows 3.1과 크게 차이 나지 않는 1990년대 중반의 서민들 컴에서 그럭저럭 구현해야 했다. 그러니 얘는 태생적으로 아주 기괴한 방향으로 개발될 수밖에 없었다.

그래서 파일 시스템이나 메모리처럼 반드시 32비트 덕을 봐야 하는 엔진 부분인 kernel은 32비트 코드 위주로 개발했지만, user나 gdi처럼 운영체제의 단순 외형과 관련된 부분은 16비트 코드를 그대로 답습했다. 이쪽 함수는 비록 32비트 프로그램에서 user32.dll, gdi32.dll을 통해 호출했다 하더라도 결국은 argument들을 thunk 해서 16비트 user.exe와 gdi.exe로 내려가서 기능이 수행된다는 뜻이다.

개량된 트루타입 글꼴 래스터라이저처럼 GDI 계층에도 32비트 코드로 다시 작성된 게 없지는 않지만 기본적인 틀은 여전히 16비트 기반이다.
Windows NT는 16비트 썽킹은커녕 훨씬 더 안정적인(하지만 속도는 좀 느려지는) 별개의 API layer가 있는 지경인데.. 9x와 NT가 서로 설계 이념과 처지가 얼마나 극과 극인지를 알 수 있다.

이런 설계 방식 때문에 Windows 9x는 16비트 heap 크기에 맞춰진 리소스 퍼센티지 한계가 여전히 걸려 있으며, GDI 좌표계도 기본적으로 32비트가 아닌 16비트 크기이다. 그래도 이런 건 그냥 한계와 제약일 뿐, 딱히 운영체제의 안정성과 관련된 문제는 아니다.
Windows 9x는 메모리 절약과 하위 호환성을 위해 (1) 16비트 코드를 많이 재활용했는데, 이걸 온전한 가상 머신 샌드박스 안에서 구동하는 게 아니라 (2) 32비트 코드와 동일한 주소 공간과 위상에서 동일한 권한으로 섞인 채 최대 성능으로 실행하는 것을 허용했다. 16비트 코드가 운영체제 차원에서 대놓고 돌아가는 부분도 있으니 저렇게 안 해 주면 안 된다.

그리고 이를 구현하는 과정에서 Windows 9x는 NT와 같은 급의 (3) 엄격한 메모리 보호를 포기했다. 스레드 동기화나 가상 메모리 같은 현대적인 개념이 없이 쑤제 어셈블리어로 코딩된 레거시 코드가 한둘이 아니니, 걔네들이 있는 그대로 돌 수 있게 시스템의 안정성을 일부 희생하게 된 것이다.

32비트 프로세스가 독자적으로 사용하는 최신식 private 메모리야 9x도 NT의 동작 방식을 물려받았기 때문에 각 프로세스별로 동일하게 보호가 잘 된다.
그러나 9x에서는 32비트 프로세스라 해도 16비트 프로그램과의 호환을 위해 남겨놓고 있는 4MB 이내 주소대의 영역은 보호가 적용되지 않으며, 반대로 운영체제 시스템 DLL이 로딩되는 상위 영역도 성능 오버헤드 간소화를 위해 모든 프로그램들이 씨크하게 같은 주소로 공유된다. 보호 같은 거 없다.

나쁜 마음 먹은 프로그램이 이런 16비트 호환 영역이나 시스템 DLL 영역 주소를 0으로 덮어써 버린다거나 하면 운영체제를 BSOD와 함께 곧장 다운시킬 수 있다. Windows NT에서는 메모리 덮어쓰기만으로는 이런 사태가 절대로 발생하지 않고 문제의 프로그램만 강제 종료되고 운지하는 것으로 끝난다. 하지만 9x는 그 정도로 튼튼하지 못했다. 메모리 보호 강도가 반쪽짜리일 뿐이라는 뜻이다. 반쯤은 응용 프로그램이 선할 거라고 믿고 곧이곧대로 돌려 주는 셈이었다.

이렇게 메모리 보호 말고 Windows 9x가 안정성이 결정적으로 취약한 분야는 멀티스레드와 관련하여 또 있었다.
Windows 9x/NT는 3.1에서는 꿈도 꿀 수 없던 선점형 멀티태스킹이라는 것을 도입했다. 한 프로그램이 자발적으로 CPU 자원을 반납하지 않고 무한 뺑뺑이를 돌더라도 운영체제가 강제로 CPU 자원을 뺏어서 다른 프로그램에게 골고루 분배해 줄 수 있다. 또한 한 프로그램 안에서 UI 스레드 따로, 작업 스레드 따로 운용이 가능하다. 작업 스레드가 재귀호출까지 마음대로 하는 동안 사용자의 입력에도 매끄럽게 응답할 수 있다는 뜻이다.

즉, 가상 메모리가 메모리 주소를 잘못 건드리는 것만으로 타 프로그램이나 운영체제를 뻗게 하지 않게 하는 공간 보호막이라면, 선점형 멀티태스킹은 한 프로그램이 CPU를 독식해서 시스템 전체의 동작을 먹통으로 만들지 않게 하는 일종의 시간 보호막이다.

선점형 멀티태스킹 환경에서는 내 스레드가 받고 있던 CPU 포커스가 싹 바뀌어서 타 스레드로 이동하는 게 정말 예고 없이 불시에 될 수 있다. 컴퓨터의 모든 코드가 자기 자신의 스택과 지역변수만 갖고 놀면서 고립된 채 돌아가는 게 아니며, 한 자원을 여러 스레드들이 공유하는 경우가 많다. 그런 코드에 둘 이상의 실행 주체가 동시에 진입했다간 프로그램 실행이 왕창 꼬여 버린다. 이건 마치 화장실에 문을 잠그는 기능이 없어서 누가 볼일이 아직 안 끝났는데 아무 예고 없이 문이 확 열리고 딴 사람이 들어오는 것과도 같다.

결국 스레드 사이에는 교통 정리 기법이 필요하며, 이를 위해 크리티컬 섹션, 뮤텍스 등 다양한 커널 오브젝트들이 존재한다. 여기까지는 아무 문제가 없다.
그런데 문제는.. 저 16비트 레거시 코드들도 선점형 멀티태스킹 통제의 대상이라는 것이며, 그 코드들은 레거시답게 멀티스레드 동기화 같은 대비가 전혀 돼 있지 않다는 점이다. 그런 걸 고려할 필요가 없는 환경에서 개발되고 구현된 코드이니까 말이다.

이것도 메모리와 마찬가지로 16비트 코드를 완전히 자기 가상 머신에서 따로 돌게 하면 별 문제될 게 없으며, Windows NT는 실제로 ntvdm이라는 16비트 가상 머신을 돌렸다.
하지만 Windows 9x는 가상 머신을 돌릴 여력이 안 되는 PC를 대상으로 성능을 얻는 대신 안정성을 희생하는 방법을 택했다. 바로, 16비트 GUI 쪽 코드는 GetMessage, PeekMessage 같은 함수로 명시적으로 CPU 자원을 반납하지 않는 동안에는.. 전체를 동기화 오브젝트로 둘러싸서 어떤 경우에도 여러 스레드들의 동시 진입이 되지 않게 한 것이다. 이름하여 Win16Mutex라는 무시무시한 시스템 동기화 메커니즘이다.

이게 무슨 뜻인가 하면.. Windows 9x도 16비트 프로그램만 줄곧 돌린다면 과거의 Windows 3.x와 별 차이 없이 동작하게 된다는 뜻이다. 제 기능을 활용할 수 없다.
물론 32비트 코드도 16비트로 thunk하는 gdi/user 함수를 호출할 수 있다. 걔네들은 그 함수가 실행되는 동안에만 Win16Mutex 안에 잠시 들어갔다가 나온다. 그러나 16비트 프로그램은 Get/PeekMessage를 호출하지 않고 실행되고 있는 동안 계속해서 Win16Mutex를 붙들고 있게 된다. 그리고 그 동안 운영체제의 그 어떤 프로그램도 16비트 코드를 수행할 수 없으며, 앞 프로그램의 실행이 끝날 때까지 기다려야 한다.

어떤 프로그램이 창을 띄웠다가 while(true) 같은 데라도 빠져서 응답이 멎었다고 치자. 그렇다면 32비트 프로그램은 ctrl+alt+del을 누른 뒤 작업 목록에서 그럭저럭 강제 종료를 할 수 있었다. 이 기능 자체는 NT뿐만 아니라 9x 계열에서도 있었다.
하지만 옛날 기억을 꺼내 보면, 16비트 프로그램은 그렇게 깔끔하게 강제 종료가 잘 되지 않았다. 16비트 프로그램이 응답 불가 상태가 되면 운영체제 전체가 실행이 불안정해졌으며, 해당 프로그램을 강제 종료한 뒤에도 매우 높은 빈도로 블루 스크린이 계속되다가 운영체제가 뻗었다. 그 이유가 바로 (4) 16비트 코드는 애초에 선점형 멀티태스킹 대상이 아니며, 16비트 코드의 실행이 32비트 코드의 gdi/user계층 기능에까지 직통으로 영향을 끼치기 때문이다.

이제야 퍼즐 조각이 끼워맞춰진다. 저건 메모리 보호와는 별개의 영역의 문제이다.
그럼에도 불구하고 Windows 95는 안정성이 더 헬게이트이던 Windows 3.x보다 많이 나아지지는 못해도 최소한 더 나쁘게 만든 건 없다. 그러니 제품으로 나와서 1990년대 중반의 PC 환경을 획기적으로 바꿔 놓을 수 있었다.

물론 Windows 9x도 Windows API와 무관하게 완전히 분리된 환경인 도스용 프로그램에 대해서는 그럭저럭 샌드박스를 지원하고 있었다. Windows NT의 ntvdm가 지원하지 못하는 더 다양한 도스용 프로그램을 직통으로 구동해 주면서도 말이다. Windows 3.x때부터 386 확장 모드가 도입되면서 Virtual 8086 모드를 이용해 도스창을 여러 개 동시에 여는 게 가능해졌다. 9x부터는 도스창을 강제 종료도 할 수 있게 됐다.

단지, 하드웨어를 너무 저수준으로 제어하는 도스용 프로그램이라면 대책 없으며, 16비트 Windows GUI 프로그램은 32비트 프로그램과 자원을 어중간하게 직통으로 공유하다 보니, 운영체제 전체에 여파가 끼치는 잠재적인 위험이 상존했던 것이다.

Windows NT, 9x, 그리고 더 과거의 win32s를 비교하면 다음과 같다.

  Windows NT Windows 9x Windows 3.1 + Win32s
PE 방식의 32비트 EXE/DLL 실행, 32비트 메모리 접근 O O O
프로세스 별 고정되고 독립된 주소 공간 보장 O O X
DLL도 인스턴스별 독립된 공간 보장 O O X
선점형 멀티태스킹과 멀티스레드 O O X
레지스트리, 32비트 파일 시스템, 최신 TTF 래스터라이저 O O X
온전한 메모리 보호 O △ (private area만. 도스 호환 영역과 커널 영역은 보호되지 않음) X
유니코드 API O △ (코드 변환, 메시지, 기본적인 문자 찍기 정도만 한정) X
유니코드 기반 O X X
user, gdi 계층이 완벽하게 32비트. 리소스 제약 없음 O X X
16비트 프로그램 가상화 O (안정적임) X (도스용 프로그램만 가상화. 느리고 메모리 적은 컴 친화적) X
하드웨어 계층 추상화 O (이식성. 하지만 느림) X (x86 전용, 저사양에서 성능 최적화) X
NTFS 파일 시스템 O X X
시스템 요구사항 압도적으로 제일 높음 win32s보다 더 높지만, NT보다는 훨씬 낮음 제일 낮음

이상.
지금 생각해 보면 컴퓨터가 성능이 정말 열악하던 시절에 어째 저런 유리몸 Windows를 어떻게 쓰고 지냈나 싶다. 특히 9x 계열 중에서도 1호인 Windows 95는 다음과 같은 점에서도 안정성이 굉장히 안습했으며, 지나치게 고성능인 컴퓨터를 감당(?)하지 못하는 물건이었다.

  • 잘 알다시피 디렉터리명에 CON 같은 예약어가 들어간 채로 파일 목록 조회 같은 요청을 하면 운영체제 전체가 뻗는다. 탐색기이든 dir 명령이든 마찬가지. 95/98에서는 별도의 버그 패치가 나왔고, ME에서야 버그가 처음부터 완전히 수정되었다.
  • 부팅 후에 밀리초 단위로 부호 없는 32비트 정수 범위를 초과하는 대략 7주(49.x일) 이상 계속 켜져 있으면 역시 뻗음. Windows 95는 알고 보면 7주짜리 시한폭탄이었던 셈이다. 하지만 이게 NT도 아니고, 무려 7주가 지나기 전에 십중팔구 어차피 다른 이유로 다운되고 재부팅이 일어났기 때문에 이 문제가 별로 부각되지 않았을 뿐이다. 이 문제 역시 별도의 버그 패치가 추후 공개되었다.
  • 저사양 PC에서 가상 메모리를 관리하는 방식의 한계로 인해, 램이 512MB보다 더 많은 컴에서는.. 단순히 초과 잉여 영역이 인식되지 않고 무시되는 게 아니라 그냥 부팅되지 않고 뻗는다.
  • 클럭 속도가 대략 2.1GHz보다 더 높은 컴에서는 Network Driver Interface Specification라는 계층에서 오류가 발생하고 뻗었다고 한다. 너무 빠른 컴퓨터에서 레거시 코드가 문제를 일으킨 유명한 다른 사례로는 볼랜드 파스칼의 crt 유닛이 266MHz보다 더 빠른 컴에서 오류를 일으켰던 것이 있다. 이런 것들은 대체로 내부적으로 시간 측정을 하다가 0으로 나누기 오류가 발생하는 형태인데, Windows의 저 문제도 마찬가지였던 것 같다.

그러니 옛날부터 컴덕들은 OS/2나 Windows NT 같은 신세계를 갈망하긴 했지만, 그걸 돌리려면 흙수저 가정에서는 엄두를 못 낼 정도의 비싼 고성능 컴퓨터가 필요했다. 윈95가 나왔던 시절에는 램 16MB도 돈지랄 감지덕지이던 시절이고 32~64MB는 가히 꿈의 영역이라 여겨졌었으니 말이다.
그러다 1990년대 후반에 가정용 보급형 PC들도 램 용량이 급증하여 100수십 MB급이 되었다. 그제서야 하드디스크 스와핑/thrashing을 볼 일이 없어졌으며, 마소의 입장에서는 NT와 별개로 굳이 헝그리한 9x 커널이 존재해야 할 명분이 사라졌다.

말이 나왔으니 옛날 추억 회상을 더 해 보자면, 주메모리뿐만 아니라 1990년대에 컴퓨터의 비디오 메모리가 딱 1MB이던 시절에는 Windows 3.1의 비디오 모드를 (1) 꼴랑 640*480 저해상도인 대신에 트루컬러, (2) 800*600에서 적당하게 하이 컬러, 아니면 (3) 1024*768에서 256색.. 셋 중 하나로 골라 쓰는 재미(?)가 있었다.
Windows 3.1은 원래는 우리에게 익숙한 짙은 파란색으로 윈도우의 굵은 틀을 표현했지만, 하이 컬러 이상부터는 어인 일인지 은은한 하늘색으로 색깔을 바꿔 표시했다. 왜 무슨 근거로 색깔을 바꿨는지는 모르겠지만 개인적으로 아주 신기하게 느껴졌었다.

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

지금까지 옛날 이야기를 많이 늘어놓았는데..
본인은 우리나라 역사 내지 이념을 Windows의 개발 내력에다 비유해서 설명하기도 한다. 매우 적절한 비유라고 개인적으로 생각하기 때문이다.

우리나라가 이 승만 대통령을 비롯해 핵심 내각은 독립 운동가· 광복군 위주로 철저하게 깨끗하게 건국되었음에도 불구하고 중간과 말단의 군· 경 간부는 친일 부역자들도 불가피하게 그대로 재등용하여 운용되었다. 독립 운동가를 적극 무료 변론하다가 일제에게 찍혀서 면허 정지까지 당했던 애산 이 인 선생이 해방 후에 법무부 장관이 되고 나서는 오히려 반민특위의 해체에 앞장섰을 정도였다.

이게 Windows 95가 일단 겉으로는 32비트 코드 기반으로 개발되고 32비트 주소 공간과 선점형 멀티태스킹을 제공함에도 불구하고 내부적으로 16비트 코드를 잔뜩 재등용하고 메모리 보호가 완전하지 못했던 이유, 수시로 파란 화면 뜨고 불안정했던 이유와 정확하게 일맥상통한다.

한 마디로 그 시절에 가정용 컴퓨터에서 Windows NT 같은 운영체제를 돌리는 건 불가능했기 때문이다. 아직 조선과 일제 강점기 사고방식에 쩔었고 공산주의가 뭔지도 모르던 사람이 태반이던 시절에.. 게다가 북괴의 위협과 비열한 공작까지 횡행하던 시절에, 일제 치하에서 행정 유경험자를 재등용하지 않고서 치안을 유지하고 자유 민주주의 국가를 FM대로 이상적으로 세우고 굴리는 것도 동급으로 절대 불가능했다.

Windows 95의 한계에 대해서 정리해 보니 이 생각이 더욱 굳건하게 확신이 든다. 그 시절의 운영체제든, 194~50년대의 우리나라 사정이든 흑역사와 한계는 불가피하게 발생했던 것이지 악의적으로 일부러 발생한 것이 절대 아니었다. 아폴로 17호 이후로 인간이 달에 안/못 가고 있는 이유는 다른 악의적인 거짓이나 음모 때문이 아니라, 그저 단순히 재정이 부족하고 가성비가 안 맞기 때문인 것과도 같은 이치이다.

쓸데없이 자국 비하를 조장하고 사람 정신건강을 해치고 일제보다 더 나쁜 악을 정당화하고 무마하는 이 악하고 해로운 생각은 보이는 족족 반박하고 뿌리뽑아야 하며, 거기에 사로잡혀 있는 사람들을 산업화하고 일깨워 줘야 한다.

Posted by 사무엘

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

Trackback URL : http://moogi.new21.org/tc/trackback/1416

Comments List

  1. 비밀방문자 2017/10/19 04:09 # M/D Reply Permalink

    관리자만 볼 수 있는 댓글입니다.

    1. 사무엘 2017/10/19 12:46 # M/D Permalink

      오랜만이구나, 반갑다? 잘 지내고 계신가!
      이 2, 30년 묵은 옛날 Windows 프로그래밍 배경 얘기가 이해가 될 정도이면 대단한 한편으로 님도 슬슬 아재력이 늘어 가는 것 같다? ㅋㅋㅋ

Leave a comment

Visual Basic 6은 이제 개발사로부터 지원이 중단된 지 무려 10년이 돼 가는데(나온 지는 20년..!) 아직도 현업에서 쓰는 경우가 있는지 모르겠다. Visual C++ 6도 업계에서 도를 넘는 노인학대를 당해 온 물건이긴 하지만, 그래도 얘는 이제는 거의 은퇴한 듯하다. 그리고 VB6과 VB .NET은 VC6과 VC .NET하고는 처지가 완전히 딴판으로 다르다.

비주얼 베이직이 오늘날까지 인류에게 남긴 독보적인 GUI 유산은 바로 property grid이지 싶다. 이거 원조가 바로 VB이다.

사용자 삽입 이미지

이건 운영체제의 공용 컨트롤로 제공되지는 않는다. 하지만 닷넷에서는 자체 구현한 컴포넌트가 있는 듯하며, 네이티브 환경에서는 그냥 3rd-party GUI 툴킷에서 구현해 놓은 레플리카 내지 짝퉁이 쓰인다.

property grid는 오늘날까지 Visual Studio IDE에서 Alt+Enter 속성 창과 프로젝트 속성 대화상자에서 고스란히 볼 수 있다. 수십 개의 설정들이 추가되더라도 번거롭게 대화상자를 디자인할 필요 없이 설정을 뒤에다 추가만 하면 되니 참 편하다.
이에 비해 VC6의 옛날 속성 대화상자는 얼마나 추레하게 생겼는가?

단, 외형이 깔끔하긴 해도 너무 사무적이고 재미없게 생겨서 그런지, 개발툴이나 DBMS 말고 일반 사용자용 Office 제품 같은 데서는 property grid가 등장하는 걸 여전히 본 적이 없는 것 같다.

Visual Basic은 1991년 5월에 Windows용으로 1.0이 첫 출시됐다. 드래그 앤 드롭 방식으로 폼을 디자인하고 곧장 이벤트를 추가하는 방식으로 코딩을 하는 굉장히 획기적인 개발툴이라고 찬사를 받았음이 틀림없다. Windows용의 호평에 힘입어 그 해 9월에는 처음이자 마지막으로 도스용 비베도 1.0이 나와서 QuickBasic과 MS Basic PDS의 라인을 종결시켰다. 하지만 VB의 UI 엔진은 경쟁작이던 볼랜드 Turbo Vision 라이브러리에 비해서는 인지도가 매우 낮다.

그 뒤 VB 2와 3은 16비트 Windows용으로 나와서 인기를 얻다가 95년에 나온 4.0은 16비트용과 32비트용이 나란히 동시에 출시되었다. 마소에서 제품을 이런 식으로 동일 버전을 16비트용과 32비트용으로 동시에 내놓는 건 극히 드물었고 아마 VB4가 거의 유일했다. Office나 VC++는 그냥 상위 버전에서 곧장 32비트용이 나오면서 16비트 지원을 중단하는 형태였기 때문이다.
물론 VB도 5부터는 당연히 32비트 전용으로 갈아탔다. VB6 이후의 .NET에 맞춘 언어 마개조의 역사는 굳이 여기서 더 말할 필요가 없을 것이다.

델파이(네이티브 코드 지원 RAD), Java(압도적으로 넓은 플랫폼 지원, 인지도, 점유율)와 C#(닷넷 지원 킹왕짱) 같은 경쟁 솔루션이 너무 쟁쟁한테 비주얼 베이직 프로그래머 수요가 국내에 얼마나 되는지는 잘 모르겠다. 그나저나 ASP도 비베와 비슷한 문법인 걸로 아는데 그건 살아 있나?
또한 비베가 .NET 으로 바뀌면서, 기존 Office와 Visual Studio IDE에서 제공되던 VBA 매크로 언어까지 반쯤 낙동강 오리알 레거시로 전락한 것도 좀 아쉬운 점이다. 덕분에 Visual Studio 201x 최신 IDE는 지금도 제대로 된 키/스크립트 기반 매크로가 없는 걸로 본인은 기억한다.

이런 비주얼 베이직과 달리 C/C++ 컴파일러 라인은 원래 IDE 같은 게 없다 보니 도스/Windows 플랫폼은 그리 타지 않았다. C/C++은 베이직과는 완전히 다른 저수준 고성능 시스템 프로그래밍 언어이지 않던가? Windows는 NT 이전엔 애초에 자체적인 명령 프롬프트라는 게 없던 물건이었고, C 컴파일러는 도스 환경에서 스위치만 바꿔서 도스뿐만 아니라 Windows, 그리고 그 당시 중요한 플랫폼이던 OS/2용 프로그램을 크로스 컴파일했다.

그러다 1990년대 초에 이쪽은 C++ 언어 추가 → MFC 도입 → MS C/C++ 8.0 대신 Visual C++ 1.0으로 명칭 변경 같은 중요한 사건을 겪었으며, 리소스 편집기와 간단한 소스 코드 에디터가 16비트 Windows용으로 나왔다.
그리고 1993년, Windows NT가 출시되면서 NT용 32비트 Visual C++ 1.0이 별도로 나왔지만 이때는 NT는 시장 점유율이 아주 미미했으니 별 재미를 못 봤다.

그 뒤 1993~94년 사이에 Visual C++은 16비트와 32비트가 서로 약간 엇갈린 길을 갔다. 16비트용은 1.5 ~ 1.52c가 나온 뒤 지원이 중단됐고, 32비트용으로는 2.0이 나왔다. 하지만 아직 Windows 95도 없던 시절에 NT밖에 지원하지 않는 32비트용 VC++ 2는 정말 존재감이 없다. 이 32비트 바이너리를 Windows 3.1에서도 아쉬운 대로 돌릴 수 있게 하기 위해 Win32s라는 런타임이 이 시기에 개발되기 시작했는데, 얘 역시 본격적으로 이름이 부각된 건 Windows 95가 나온 뒤부터였다. 요컨대 Win32s는 95의 등장 이전부터 NT 3.1과 오리지널 3.1 사이의 gap을 메우기 위해 존재해 왔던 물건이다.

그 뒤, Windows 95가 나오고 1995년 말에 출시된 Visual C++ 4가 대박을 치면서 마소의 개발툴이 볼랜드 같은 타사 컴파일러를 슬슬 제치기 시작했다. Developer Studio라는 통합 IDE도 이때 처음으로 등장했다(텍스트 에디터, 리소스 에디터, 디버거, 빌드 툴, 도움말 레퍼런스 모두 한데 통합). VC4 시절에는 UI상으로 생뚱맞게도 맥용 크로스 컴파일이 있었던 모양이나, 본인이 직접 써 본 적은 없다.

이 당시에는 지금 같은 인터넷 기반 제품 업데이트가 없다 보니 소숫점 첫째나 둘째 자리가 0이 아닌 제품 버전을 심심찮게 볼 수 있었다. Win32s는 Visual C++ 4.1까지 지원되다가 96년 가을에 출시된 4.2에서부터 지원이 중단됐다. 설치할 때부터 "이 버전부터는 Win32s를 지원하지 않으니 이걸 타겟으로 개발하려면 구버전을 쓰고 이건 설치하지 마세요"라고 확인 질문이 뜬다.

비베는 4.0에서야 32비트 에디션이 등장하고 16비트와 32비트가 공존했던 반면, C++은 진작부터 32비트가 존재했고 그 대신 Win32s라는 과도기를 거쳤다는 차이가 있다.
또한 비베는 21세기부터는 닷넷 기반 언어로 완전히 탈바꿈해 버린 반면, C++은 이전부터 위상이 위상이다 보니 닷넷의 공세에 영향을 받지 않있다. 차라리 C++/CLI 같은 파생형 확장이 나오면 나왔지, 네이티브 코드 개발 부분은 바뀐 게 없다.

비베는 5와 6에서 잠시 MS Office 97 기반 GUI 엔진을 사용했고, 닷넷 200x에서는 그 기반을 계승하여 Office XP 및 파생 변종 GUI를 사용했다. VC++의 4~6에서 쓰인 IDE는 MFC를 써서 Office와 비슷한 외형이 나오게 자체적으로 만든 GUI 엔진 기반이었다.
그러던 것이 Visual Studio 201x부터는 WPF 기반의 완전히 독자적인 고유한 GUI를 사용하여 오늘날에 이르고 있다. 버전이 올라갈 때마다 매번 외형을 바꾸던 것도 이제는 지쳤는지(?) 2013 이후쯤부터는 안 하고 있다.

Posted by 사무엘

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

Trackback URL : http://moogi.new21.org/tc/trackback/1415

Comments List

  1. 비밀방문자 2017/10/19 04:10 # M/D Reply Permalink

    관리자만 볼 수 있는 댓글입니다.

    1. 사무엘 2017/10/19 12:46 # M/D Permalink

      임베디드나 그런 바닥은 기계의 수명이 다할 때까지 소프트웨어 업데이트/업그레이드란 없을 테니 그럴 수도 있을 것이다? 뭐, 인터넷 연결 같은 것도 없고 애초에 안정화돼서 잘 쓰던 프로그램만 죽도록 쓰면 될 테고.

Leave a comment

날개셋 한글 입력기 9.1

1. 들어가는 말

2017년 6월에 날개셋 한글 입력기 9.0이 나온 지 4개월 만에 9.1 버전이 나왔다. 추석을 낀 10월 황금 연휴 기간까지 보낸 뒤에 드디어 공개되었다. 오랜 마음의 부담을 덜었다.
이번 버전은 이전 버전들과 달리, 오로지 '보조 입력 도구'의 기능을 크게 강화하는 것에 초점이 맞춰졌다. 비록 readme가 분량이 이례적으로 매우 짧으며 사실 넣고 싶은 기능을 다 넣지도 못했지만, 이번에도 내부적으로 1500줄이 넘는 코드가 새로 추가되고 많은 변화가 있었다.

이미 있는 입력 도구에 기능이 추가된 것부터 소개하자면,
(1) 먼저, 지난 7월에 소개한 것처럼 "화면 키보드"에 일종의 live preview 옵션이 추가되었다. 현재의 문맥을 기준으로 수식을 계산했을 때 입력되는 문자를 실시간으로 바꿔서 표시해 주기 때문에 복벌식이나 신세벌식 같은 복잡한(?) 입력 방식을 사용할 때 큰 도움이 될 것이다.

(2) 그리고 5.3에서 첫 도입된 이래로 변화가 전혀 없었던 "한손 입력기"에도 아기자기한 변화가 생겼다.
화면 키보드처럼 3단계 크기 조절이 가능해졌으며, 초성과 종성의 배치가 대칭이라는 점을 착안하여 초성· 종성을 우-좌로 배치할지, 좌-우로 배치할지를 변경할 수 있게 했다. 세벌식이니까 존재할 수 있는 절묘한 customization이다.

사용자 삽입 이미지

또한, 중성의 경우, 천지인 방식뿐만 아니라 나랏글 방식도 고를 수 있게 했다. ㅡ 글쇠가 따로 없기 때문에 얘는 ㅣ를 두 번 눌러서 입력하면 된다.
한손 입력기는 애초에 나랏글처럼 '가획' 글쇠가 있어서 자음에서 쓰이고 있다. 그러니 모음도 나랏글 방식을 지원하지 말라는 법이 없다. 이런 옵션으로 인해 한손 입력기의 활용의 폭이 더 넓어지기를 기대해 본다.

2. 휴대전화 입력기

이번 9.1에서 추가된 가장 대표적인 기능은 바로 이 입력 도구이다. 얘는 3*4 방식의 키패드를 통해 다양한 입력 방식을 제공한다.
한글, 영문, 숫자, 기호 이렇게 총 4가지 모드가 있다. 그 중 한글은 현재 지정되어 있는 키보드 입력용 글자판(= 입력 항목) 중 하나에서 0~9와 * # 자리를 그대로 빌려 쓴다.
즉, '한손 입력기'처럼 독자적으로 제공하는 입력 기능이 없이 기술적으로는 '화면 키보드'의 부분집합처럼 동작한다. 처음에는 구동 당시에 사용 중이던 글자판을 기준으로 동작하지만, 글자판을 딴 걸로 변경하고 나서 우클릭 메뉴에서 '동기화'를 선택하면 기준으로 삼는 글자판을 바꿀 수 있다.

(1) 이 입력 도구는 기존 입력 설정을 빌려 와서 동작하는 대신, 한번 참조해서 불러들인 글자판은 사용자가 딴 걸로 변경하더라도, 심지어 날개셋 제어판을 통해 기존 입력 설정을 싹 갈아엎더라도 절대불변으로 계속 갖고 있는다. 이것이 '화면 키보드'와는 다른 점이다.
그렇기 때문에 한번 천지인이나 나랏글 같은 입력 방식으로 동기화시킨 뒤엔, 다시 PC 키보드용으로 쓰기 편한 두벌식이나 세벌식을 쓰다가 마우스로만 모바일용 입력 방식을 같이 쓸 수가 있다.

(2) 또한 비트맵 글꼴을 사용하는 '화면 키보드'와 달리, 이 입력 도구는 나름 크기 조절이 가능한 운영체제의 글꼴을 사용한다. 게다가 조합을 통해 생성되는 한글 자모들을 모두 한데 표시해 준다. 나랏글의 경우 ㅏㅓ, 첫지인의 경우 ㄱㅋㄲ 이런 것을 한 글쇠에다 크기 조절까지 알아서 해서 표시한다는 것이다.

사용자 삽입 이미지

다만, 글쇠에 비문자 특수글쇠나 가상 낱자가 들어있다면 이렇게 프로그램이 글쇠 문자를 자동으로 찾아 준 결과가 썩 정확하지 않을 것이다. 이럴 때는 이 글쇠는 무슨 역할을 한다고 사용자가 그냥 직접 지정을 할 수 있다. 나랏글의 가획/쌍자음 같은 글쇠는 500이니 501이니 이런 내부 숫자가 아니라, 저렇게 사람에게 실질적인 의미를 갖는 별칭을 표시하는 게 훨씬 낫기 때문이다.

이런 정보를 읽어들이기 위해서 '휴대전화 입력기'는 글쇠배열의 '설명문'을 사용한다. 그 텍스트에 XML 시그니처가 존재한다면 그 뒤에 나오는 XML을 해석해서 거기에 지정된 이름을 출력한다~!
미래에 궁극적으로는 설정 파일 내부에 임의의 메타데이터를 저장하는 계층을 더 그럴싸하게 강화할 것이지만, 일단은 이런 임시방편을 동원했다.

<?xml version="1.0"?>
<info>
    <key pos="#" name="SEP" flag="1"/>
</info>

날개셋 한글 입력기가 예제로 기본 제공하는 천지인· 나랏글· SKY 입력방식들은 모두 '휴대전화 입력기' 도구와 연계해서 잘 동작하게 저런 정보가 추가되었다. 지금까지 타자 시퀀스를 구하는 용도로나 사용되던 이 예제들에게 더 그럴싸한 활용 방법이 생긴 셈이다.
천지인의 경우, 사용되지 않는 * 자리에 문장부호를 다중타로 입력하는 사용자 정의 조합이 추가되었으며, # 자리에는 음절 구분자 글쇠가 배당됐다.

(3) '휴대전화 입력기' 도구는 한글 모드에서만 저렇게 기존 입력 설정을 빌려다 쓰며, 나머지 입력 모드에서는 다 자체적인 고정된 입력 기능을 제공한다.
영문은 '모비언스'라는 국내 기업에서 개발한 SmallQwerty 방식의 다중타 입력을 제공한다. 무식하게 ABC 순이 아니라 영문 글자 빈도수와 기존 쿼티 글자판을 적절히 고려하여 글쇠를 배당했는데, 생각보다 편한 걸 알 수 있을 것이다.
0번 키를 눌러서 대소문자를 바꾼 것은 한 글자에 대해서만 적용되고, 우클릭 메뉴에서 대소문자를 바꾼 것은 영구적으로 적용된다는 차이가 있다.

(4) 숫자 모드는 다른 복잡한 기능 없이 말 그대로 12키 키패드를 숫자 입력용으로만 사용한다.
그런데 여기에도 재미있는 바리에이션이 있다. 위에서부터 아래로 123 순으로 배열된 '전화기' 모드와, 그렇지 않고 역순으로 배열된 '계산기' 모드가 모두 제공되어서 사용자가 이를 선택할 수 있다. 전화기 모드에서는 기호도 말 그대로 *와 #가 있지만, 계산기 모드에서는 .와 ,가 배당된다.

(5) 끝으로, 기호 모드는 기술적으로 영문 모드와 별 다를 바 없는 다중타 방식 문자표이다.
backspace, space, enter는 모든 모드에 공통으로 존재하는 글쇠이다.
그리고 mode 버튼은 좌측 하단을 누르면 한/영이 전환되며, 우측 상단을 누르면 숫자/기호가 전환된다.
3*4 크기의 글쇠배열에서 단일타라는 범위 안에서는 내가 생각할 수 있는 가장 창의적인 기능들이 한데 깔끔하게 구현되었다. 단일타라 함은 여러 버튼을 동시에 누르거나 드래그 하는 것까지는 생각하지 않는다는 뜻이다.

3. 글쇠배열 이름 표시

그리고 이번에는 문자를 직접적으로 입력시키지는 않지만 문자 입력과 관련된 편의 기능을 제공하는 입력 도구가 하나 또 추가되었다.
'글쇠배열 이름 표시'는 메뉴에서 선택하더라도 당장 화면에 뭔가 튀어나오는 게 없다. 그 대신 사용자가 한/영이나 Shift+Space 같은 걸 눌러서 글쇠배열을 전환하면 새로 바뀐 글쇠배열의 이름이 cursor 근처에 풍선 도움말 형태로 나타난다. 짜잔~

사용자 삽입 이미지

풍선 도움말은 2.5초 정도 표시됐다가 사라진다. 한/영 상태뿐만 아니라 Caps/Num/Scroll lock을 눌러서 램프 상태가 바뀐 것도 풍선 도움말(툴팁) 형태로 표시해 준다.
그리고 툴팁이 사라진 지 5초가 경과한 상태라면, 날개셋 한글 입력기를 사용하는 텍스트 입력란이 포커스를 새로 얻었을 때에도 현재의 글쇠배열을 자동으로 잠시 표시해 준다. 반대로, 툴팁이 떠 있는 동안은 키보드 포커스가 다른 윈도우로 이동하더라도 툴팁 역시 cursor 근처를 자동으로 따라다닌다.

그리고 사용자가 텍스트의 입력을 시작하면 이 툴팁 역시 화면을 가리지 말자는 차원에서 곧장 사라진다. (응용 프로그램이 직통으로 담당하는 키 입력 말고, 날개셋 입력기로 접수되는 문자 입력 한정) 이런 여러 이벤트들을 세심하게 신경 썼다.

본인은 날개셋 입력기에 한/영 상태를 화면에 별도로 표시하는 기능이 있으면 좋겠다는 요청을 수 년 전부터 일부 사용자로부터 받은 적이 있었다. 그게 이런 형태로 드디어 실현되었다.
Windows 8 이상의 Metro UI에서는 입력 도구모음줄이란 게 없는 관계로 윈도우 포커스를 얻었을 때 현재 글자판의 대표 아이콘을 잠깐 표시해 주는 기능이 이미 있다. 그것과 기능이 약간 겹친다고 볼 수 있다.

물론, 이 기능은 한계도 있다.
날개셋 한글 입력기가 구동되자마자 자동으로 동작하는 게 아니며, 사용자가 이 입력 도구를 골라서 구동을 해 줘야만 동작한다. 내 프로그램은 자동으로 특정 입력 도구를 곧장 구동하는 기능은 아직 없다.
또한, 편집기가 아닌 외부 모듈에서는 응용 프로그램에 따라 cursor의 정확한 위치를 기술적으로 얻을 수가 없어서 화면 가장자리의 엉뚱한 위치에 툴팁이 뜨기도 한다. 이 점을 감안할 필요가 있다.

그래도 '글쇠배열 이름 표시' 기능은 날개셋 편집기의 상태 표시줄 내지 운영체제의 language bar를 응시할 필요를 상당수 줄여 주는 유용한 기능이 될 것이다. 다음 버전에서는(아마 9.3쯤) 이런 기발한 입력 도구들이 몇 개 더 추가되어서 사용자의 문자 입력에 시각적으로 큰 도움을 줄 것이다.

4. 제공 자료

(1) 예제로 제공되는 신세벌식 유형 파일을 '신세벌식 공동 개발안'이라는 이름으로 세벌식 커뮤니티에 공개된 최신 파일로 업데이트 했다. 이것이 20여 년 전 PC 통신 시절에 신세벌식 입력 방식을 처음으로 제안했고 지금까지 '신 광조'라는 이름만 알려져 있던 원 제작자분이 직접 고친 최신 입력 방식이라고 한다.

(2) 그리고 쿼티, 드보락, 콜맥에 이어서 영문 글쇠배열도 Carpalx라는 타자 행동 분석 프로그램으로 계산한 최적의 배열(배열 중 하나)이라는 QGMLWY 배열을 추가해 넣었다. 여러 바리에이션 중, ZXCV는 Ctrl 단축키를 의식해서 기존 Qwerty의 것을 그대로 유지시킨 거라고 한다. 제2군, 제3군에 이어 제4군까지 내려가면 얼마나 마이너해지려나 모르겠지만, PC용 영문 글쇠배열도 오늘날까지 연구가 완전히 중단된 게 아니라는 걸 알 수 있다.

(3) 내 프로그램의 도움말 디렉터리에는 버전 히스토리 리스트뿐만 아니라 '한글 자모 목록' 레퍼런스 txt 파일이 있다. 거기에 인터넷에서 긁어 온 '훈민정음 서문'과 '용비어천가' 텍스트를 예제로 또 추가해 넣었다. 이 분야에서 워낙 상징성이 뛰어난 텍스트이기도 하니, 방점이 가미된 그럴싸한 옛한글 예문이 필요할 때 간단히 불러와서 활용할 수 있을 것이다.

5. 그 밖에

입력 도구 외의 변화 사항들은 일일이 언급할 필요를 느끼지 못할 정도로 사소한 것들만 있다. 그나마 리드미 말고 블로그 글을 통해서라도 언급할 만한 것으로는..

(1) 날개셋 편집기의 화면 인쇄 퀄리티를 크게 개선했다. 작은 배율에서는 비트맵이 안티앨리어싱이 적용되어 부드럽게 찍힐 뿐만 아니라, '고대비 검정' 같은 검은 배경에서도 작은 글자의 뭉개지는 픽셀들이 다 사라지지 않고 정상적으로 표시된다. 어려울 것도 없고 비트맵을 찍는 옵션 하나만 살짝 바꿔 주면 됐는데 10년이 넘게 방법을 모르고 있었다.

(2) 그리고 고급 입력기의 사용자 정의 조합을 편집하는 화면에서.. 현재 존재하지 않는 새로운 상태로 가는 조합을 정의한 뒤 그걸 마우스로 더블 클릭하면, 자동으로 그 상태 번호를 등록하고 거기로 이동하게 해서 사용자 편의를 약간이나마 강화했다.

6. 끝으로.. 휴대전화(모바일)용 입력 방식에 대한 추가 잡설

(1) 사실, 휴대전화용 입력기라고 해 봐야 옛날에나 12키 layout에 매여 있었지, 지금은 꼭 그렇지도 않다. 스마트폰은 글쇠 레이아웃의 제약이 없으니 qwerty처럼 익숙한 PC용 키보드 그림을 띄워서 그걸 터치하는 방식으로 문자를 입력하기도 한다.
다만, 키보드와 완전히 같지는 않고 거기에서 규모를 약간만 줄이곤 한다. Google 단모음 입력기가 이런 틈새시장을 잘 공략한 입력 방식이긴 하다.
4단 숫자까지 사용하는 세벌식에게 이런 모바일 환경은 일면 악재로 보인다. 하지만 그런 곳에서는 신세벌식 같은 방식으로 글쇠 수를 줄인 입력 방식이 각광받고 있다.

그리고 사실은.. 모든 모바일 기기들이 다 qwerty 배열을 통째로 화면에 띄울 수 있을 정도로 화면이 크지는 않다.
교통에서도 동일 면적에 차들을 너무 많이 집어넣어서 밀집도가 지나치게 올라가면 차들이 서로 부딪칠까봐 조심하느라 빨리 달리지 못한다. 정체가 시작되며 단위 시간당 차량 소통량이 오히려 감소하게 된다.

그것처럼 작은 화면에 글쇠들이 정확하게 누르기도 힘들 정도로 너무 조밀하게 많이 있으면, 원하는 글쇠를 한 번에 누를 수 있어서 편리한 것보다 오타 때문에 불편한 게 더 커진다.
이런 이유로 인해 본인 역시 스마트폰에서 qwerty 기반 두벌식을 잠깐 써 보다가 불편해서 다시 3*4 나랏글로 갈아탔다. 적당한 버튼의 면적과 수에 대한 HCI 관점에서의 연구가 필요해 보인다.

아울러, 3*4 같은 고정적인 글쇠 패러다임도 완전히 없어질 수는 없는 게.. 시각 장애인이 있기 때문이다. 점자는 물리적인 요철로 구현해야 하니 터치스크린으로 절대로 구현할 수 없다. 요즘 같은 비주얼한 세상에도 라디오가 망하지 않고 있는 게, 수많은 영업용 자동차 운전자 때문인 것과 비슷한 이치라 하겠다.

(2) 지금까지 고안된 수많은 모바일용 한글 입력 방식 중에는 한 글쇠에 자음과 모음이 중첩 배당된 게 있다. 신세벌식에서는 그나마 중성과 종성 중첩이라지만, 저런 입력 방식에서는 두벌식이기 때문에 한 글쇠가 문맥에 따라 초중종성 역할을 모두 담당하게 된다.

가령, 김 민겸 님(☞ 홈페이지)이 고안하신 입력 방식은 '으'에다가 ㅡ를 덧붙여서 ㅎ이 되는 동작이 있다..! 이건 워낙 특이한 동작이기 때문에 날개셋에서도 거의 7.x대 버전에서 0으로 만드는 특수 낱자까지 도입한 뒤에야 겨우 구현 가능해졌다. 그래도 복잡한 전용 특수 오토마타가 필요하며, 이렇게 너무 변칙적인 입력 로직은 내 프로그램에서 입력 순서 계산 같은 자동화도 제대로 못 해 준다.

그리고 웹사이트의 설명을 아무리 읽어 봐도.. 자음과 모음이 그렇게 중첩돼 버리면 음절 경계 구분은 어떻게 하는지, 초성은 그렇게 입력한다 쳐도 종성에서 '으으'와 '읗' 같은 건 어떻게 구분하는지, 뭔가 보편적인 규칙이 떠오르질 않았다. 내부 로직이 어떻게 돼 있는지 리서치를 할 시간이 없어서 본인은 그런 입력 방식들은 예제로 제공하지 못하고 있다.

사실, 모비언스에서도 영문뿐만 아니라 한글 입력 방식을 제안한 것이 있는데 거기서도 자음과 모음 중첩이 존재한다. 이 역시 비슷한 이유로 구현하지 못하고 내 프로그램에서는 영문 입력 방식만 얹었다.

Posted by 사무엘

2017/10/09 08:32 2017/10/09 08:32
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1414

Trackback URL : http://moogi.new21.org/tc/trackback/1414

Leave a comment

Doom 게임의 몬스터 내분 외

예전에는 고전 게임들 중에 페르시아의 왕자 얘기를 종종 늘어놓는 편이었는데 요즘은 둠/퀘이크로 관심사가 바뀌어 있다. 그 시절엔 PC급에서 실시간 3D 렌더링를 구현한 최첨단 게임이었는데 그것도 벌써 20년도 넘은 게임이 돼 버렸구나.

Doom 계열 게임은 몬스터들끼리의 내분(infighting)이 존재하는 걸로 유명하다. 여타 액션· 아케이드 게임에서는 거의 찾을 수 없는 특징이다.
사실은 몬스터가 주인공과 동일하게 게임상의 트랩에 걸릴 수 있고 몬스터끼리 팀킬이 존재하는 게임도 흔치 않다. Doom에서도 몬스터는 용암· 독극물 같은 바닥 트랩에는 면역이며, 주인공과 달리 체력을 잃지 않는다. 이건 몬스터가 총알이 무한대(!)이고 스타 1의 AI에서 컴퓨터는 플레이어 위치를 내부적으로 이미 알고 있는 것처럼, 밸런스 차원에서 사람과 컴퓨터 사이에 어쩔 수 없이 존재하는 차이점이다.

단, Doom 몬스터도 위에서 짓누르는 crushing ceiling 트랩에 의한 압사는 동일하게 가능하다. 플레이어의 무기 공격 이외의 방법으로 몬스터가 죽을 수 있는 얼마 안 되는 방법 중 하나인데, 그런 것처럼 Doom은 몬스터끼리 팀킬이 가능한 걸 넘어, 자기들끼리 적극적으로 싸움박질까지 가능하다는 뜻이다.

솔직히 말해 게임이 아닌 현실에서는 킹왕짱 주인공 한 명이 적들이 우글거리는 본거지나 던전 같은 데에 들어가서 깽판을 치고 다니는 일이 도저히 있을 수 없다. 현실에서는 주인공 보정 같은 게 전혀 존재하지 않을 뿐만 아니라, 적군들도 절대로 혼자 놀지 않는다. 침입자가 감지되면 던전 전체에 경보가 걸리고 모든 적들이 서로 "연락"을 주고받으면서 힘을 합쳐서 침입자의 퇴로를 차단하고 화력을 집중해서 잡아낸다.

그러니 협력은 고사하고 몬스터 자기들끼리 싸운다니.. 이건 솔직히 말해 매우 비현실적인 설정이다.
하지만 현실을 곧이곧대로 반영했다가는 FPS는 너무 어렵고 재미가 없어지고, 심지어 잠입 액션 게임 같은 장르는 존재 자체가 불가능해진다. 현실에서 경험할 수 없는 쾌감과 카타르시스를 얻으려고 게임을 하는데 게임이 쓸데없는 데에 너무 고증에 충실할 필요도 없다.

Doom의 몬스터는 처음에는 주인공을 향해서 공격하지만 다른 몬스터로부터 공격을 당할 수도 있고, 또 누구든지 자기를 공격한 놈을 무조건 공격한다. 각각의 몬스터들이 그야말로 자기밖에 모르는 아주 이기적인 놈이라는 설정이 붙어 있어서 그런데, 이건 역으로 플레이어 주인공에게는 유리한 면모가 된다. 듀크 뉴켐 3D 같은 유사 3D FPS에는 이런 시스템이 존재하지 않는다.

몬스터간 내분은 단순한 꼼수 테크닉 차원을 넘어서 Doom의 제작사에서 정식으로 홍보를 했으며, 레벨들 자체도 저걸 반드시 활용하는 걸 가정하고 설계하기도 했다.
Doom 2의 경우 오리지널 버전에서 최종 보스였던 스파이더 마스터마인드(이하 스마마)와 사이버데몬이 이제는 에피소드가 바뀔 무렵에 종종 등장하는 중간 보스로 위상이 바뀌었는데, 사이버데몬이 있는 곳엔 어지간하면 무적 아이템이라든가 다른 몬스터도 있다. 그래서 걔네들끼리 싸움을 붙이면 편하게 격파할 수 있다. 대표적인 곳이 level 20 Gotcha!의 도입부이다.

다만, 개나 소나 다 서로 싸우게 만들 수 있지는 않다.
일단 총알은 눈이 안 달렸다 보니 우리 주인공, 좀비맨, shotgun guy, chaingunner, 심지어 스마마까지 동족· 이족을 불문하고 다 싸움을 시킬 수 있다.
그러나 괴물이 발사한 뭔가 초월적인 형태의 파이어볼들끼리는 서로 내성이 있다. 가령, 임프나 카코데몬, hell knight, baron of hell, mancubus 같은 놈들은 동족이 발사한 파이어볼에 맞아도 체력이 깎이지 않으며 서로 싸우지도 않는다.

물론 서로 다른 종족끼리는 얄짤없다. 임프 vs 카코데몬, 레버넌트 vs hell night 이런 식으로는 싸움을 얼마든지 붙일 수 있다.
그럼 동족끼리는 싸움을 붙이는 게 절대 전혀 불가능한가 하면.. 그렇지는 않다. 이게 또 Doom 엔진의 아주 오묘한 면모이다. 바로, 폭발하는 드럼통의 스플래시 대미지를 이용한 간접적인 방법을 통해 가능하다.

드럼통은 내부적으로 소량의 hit point를 갖고 있으며, 얘가 공격을 받아서 HP가 0 이하가 되면 터진다. 그런데 동족 몬스터 A, B가 있고 B가 A의 공격을 받아 터진 드럼통의 근처에서 대미지를 입으면 B는 A가 자신을 공격했다고 간주하게 된다.

이건 아무데서나 가능한 게 아니고 컨트롤도 굉장히 어렵다. 하지만 Doom 엔진 하에서 파이어볼 쏘는 괴물끼리 서로 싸우는 게 이론적으로 가능은 하다는 뜻이다. 이를 시연하는 동영상들도 유튜브에 많이 있다.
동영상을 보면, 드럼통이 맨 먼저 A의 공격을 받고 당장 터지지는 않았지만, 나중에 B가 그 드럼통의 근처에 왔을 때 플레이어가 최종적으로 터뜨려서 B에게 대미지를 입혀도 되는 듯하다. 이게 사실 더 쉽긴 하다.

이 일이 벌어지면 B는 A에게 파이어볼을 쏘면서 다가간다. 그래도 파이어볼은 대미지나 공격으로 인식되지 않기 때문에 A는 B의 원거리 공격을 무시하고 반응하지 않는다. 그러다가 B가 A를 직접 할퀴고 때리는 식으로 근접 공격을 시작하면 그건 비로소 대미지로 인식되기 때문에 A와 B는 동족임에도 불구하고 서로 싸우는 진풍경이 벌어진다. 그러다 둘 중 하나가 죽는다..;;

몬스터들 중에 demon은 물어뜯는 근접 공격밖에 존재하지 않기 때문에 다른 몬스터에게 먼저 피해를 주는 건 불가능하다. 언제나 자기가 먼저 얻어맞고 시작하게 된다.
pain elemental도 먼저 피해를 줄 능력이 없는 놈이다. 그런데 반격을 하는 방법이 자기가 무슨 파이어볼을 발사하는 게 아니라 가해자를 공격하는 lost soul을 소환하는 것이다. 참고로 lost soul은 돌격하다가 자기들끼리 부딪치면 내분을 잘 일으킨다.

스마마는 인간이 아닌 괴물이고 게다가 보스급임에도 불구하고 괴물 특유의 파이어볼을 발사하는 게 아니라 평범한 기관총 탄환을 발사한다.
Doom 2의 level 28 Spirit world에서는 전레벨을 통틀어 유일하게 한 레벨에서 스마마가 두 마리나 나오는데, 스마마끼리 내분을 붙일 수 있다. 아까 level 20에서는 사이버데몬 vs 스마마였는데 이제는 동족끼리 팀킬인 것이다.

Doom의 몬스터들은 대체로 요리조리 갈짓자걸음으로 얼쩡거리다가 일정 주기로 공격을 하는 편인데, 스마마의 경우 플레이어를 발견하면 그냥 자신이 경직되거나 플레이어가 시야에서 사라질 때까지 닥치고 다발총을 갈겨댄다. 이런 공격을 하는 몬스터가 오리지널 Doom에서는 최종 보스이던 스마마밖에 없었지만, 둠 2에서는 잡몹급에서도 더 늘었다. chaingunner (heavy weapon dude), 아라크노트론(둠 2에서 추가된 거미 축소 양산판)이 추가됐기 때문이다.

Doom 2의 시크릿 레벨에 존재하는 나치 SS 군인도 이런 식으로 공격한다. 그런데 얘들은 인간이지만 동료의 총알에 맞아서 대미지를 입더라도 자기들끼리 싸우지 않고 오로지 플레이어만 공격한다. 즉, 팀킬이 존재함에도 불구하고 몬스터 내분에서 예외이다. (.... 라고 처음에 썼는데, 그건 아니고.. 스프라이트의 출처가 옛날 울펜슈타인이다 보니, 공격하는 모습은 언제나 플레이어를 향한 정면 각도 것밖에 없어서 겉보기로만 그렇게 보이는 거라고 한다. ㄲㄲㄲ)

참고로 보스급 몬스터는 (1) 로켓 런처의 스플래시 대미지를 맞지 않고 오직 직타 대미지만 입으며, (2) 죽더라도 아크바일이 소생시키지 못하고, (3) 얘들이 플레이어를 발견하는 소리와 죽는 소리가 플레이어가 어디에 있던 맵 전체에서 들린다는 특징이 있다. (4) 이동하는 것만으로도 삐걱삐걱 소리가 들리는 건 보스가 아닌 아라크노트론도 가진 특징이므로 유니크함이 덜하고.

Doom 2에서 이런 보스를 오마주한 듯한 작은 양산형(?) 스케일 몬스터가 추가됐다. 사이버데몬은 mancubus (노란색 계열, 3콤보 공격)이고, 스마마는 아라크노트론이다.
mancubus는 근접 공격이 없고 원거리만 있기 때문에 그럼 동족끼리 싸움이 붙으면 싸움이 영원히 끝나지 않을 것 같다.

또한, 오로지 총알만 종족 불문 통용인지, 사이버데몬의 로켓과 아라크노트론의 플라즈마건은 플레이어도 동일하게 소유한 무기임에도 불구하고 동족간 몬스터 내분을 일으키지 않는 것으로 보인다. 이유는 모르겠다. 하긴, 사이버데몬은 일반적인 Doom 맵에서는 두 마리 이상이 동시에 존재하는 경우가 없기 때문에 몬스터 내분을 따지는 것이 의미가 없기도 하다.

Doom은 안 그래도 몬스터 개떼들이 몰려드는 물량전이 많은데 플레이어가 지형 장애물에만 가려지지 않고 있으면 다들 닥치고 공격부터 한다. 그래서 몬스터 내분이 굉장히 잘 일어나는 편이었다.
그러던 것이 후속작인 Quake에서는 AI가 수정되었다. 앞에 지형 장애물뿐만 아니라 동· 이족을 불문하고 자신과 플레이어 사이의 직선 경로에 다른 몬스터가 있으면 공격을 하지 않게 되었다. 둠을 하다가 퀘이크를 해 보면 곧장 차이를 알 수 있다.

그래서 퀘이크는 둠만치 몬스터 내분이 금방 곧장 발생하지는 않는다. 하지만 그래도 플레이어를 조금만 컨트롤하면 여전히 내분을 어렵지 않게 일으킬 수 있다. 멍청해서 수류탄을 맵의 온 곳에다 뿌리는 Ogre 아저씨가 몬스터 내분의 가해자가 되기 제일 만만하고 쉽다.

Ogre는 같은 Ogre의 수류탄에 맞아도 동족을 공격하지는 않는다. 하지만 의외로 대미지를 전혀 안 입는 건 아니고 아주 조금씩은 입는다. 내 경험상 동족 내지 심지어 자기 자신이 발사한 수류탄을 수십~백여 번 가까이 맞으면 죽긴 하더라.

Doom에서는 몬스터끼리 싸우다가도 죽을 때는 언제나 플레이어를 보는 방향으로 쓰러지는 게 다소 어색한데(죽는 스프라이트는 플레이어를 보는 시점 하나뿐이므로) 퀘이크는 폴리곤 기반 풀 3D이기 때문에 죽는 모션의 시점도 자연스럽게 개선되어 좋다. 몬스터 내분을 구경할 맛이 난다.

이를 더 확장해서 보면, Doom 게임을 몬스터의 시점에서 본다거나, 주인공의 움직임을 다른 곳에서 3인칭 시점에서 보면 어떨까 하는 생각이 든다. 실제로 이를 가정한 유튜브 동영상도 있다. 몬스터가 보기에 플레이어는 크기는 생쥐처럼 작은 게 무엇보다도 이동이 겁나게 빨라 보이겠다. alert sound도 없고 pain chance(공격 당해서 일정 확률로 움찔하는 것) 같은 것도 없다. 몬스터가 물량에서 유리한 반면 플레이어는 압도적인 민첩성이 유리하겠다.

FPS의 유행이 퀘이크 3 아레나를 거쳐서 밀리터리 + 온라인 팀플 스타일로 바뀌는가 싶더니 요즘은 오버워치와 LOL처럼 다시 옛날 같은 초현실적인 스타일이 뜨는 듯하다. 이런 트렌드의 차이가 둠 3과 둠 4의 성향 차이를 만들기도 했다. 이건 2010년대 이후에 병맛이 전세계적으로 재조명 받은 둠 코믹스의 영향을 받기도 했을 것이다.

군대에서 실제로 총을 쏴 보면 알 수 있듯, 현실의 총질과 하이퍼/고전 FPS의 총질은 느낌이 영 다를 수밖에 없다. 현실의 총기는 반동과 재장전이라는 게 존재하고 총소리도 서로 다르다. 현대의 군인이 쓰는 돌격소총은 둠의 권총, 샷건, 체인건 중 어느 부류에도 정확하게 딱 떨어지지 않는다. 그리고 총을 100% 현실처럼 반영해 버리면 치명상 내지 즉사가 너무 쉬워져서 게임의 재미가 크게 줄어든다. 그러니 현실적인 군사 FPS는 그런 걸 일부러 추구하는 사용자를 대상으로 하는 별도의 장르로 가야 한다.

이 와중에도 Doom은 C언어 소스 코드가 공개된 이후로 엔진이 양덕후들에 의해 그야말로 뼈와 골수 속까지 몽땅 다 분석됐다. 온갖 변태적인 포팅판, 개조· 변형판, 맵이 나와서 플레이 동영상들이 돌아다닌다. 페르시아의 왕자의 경우 소스는 공개되지 않았지만 그래도 더 오래 된 단순한 게임인 덕분에 오로지 역공학 분석을 통해 맵 에디터가 나돌긴 하는데.. 둠의 경우는 더 재미있고 소스까지 공개되지 않았던가? 활용의 스케일이 더하다.
(뭐, 엄밀히 말하면 페르시아 왕자도 조던 메크너가 초 구닥다리 애플 2 어셈블리어로 짰던 원판 소스가 수 년 전 공개되긴 했지만 그건 과연 분석과 포팅이 가능할지? ㅡ,.ㅡ;;)

그 중 초월이식 마개조의 끝판왕으로 뜨고 있는 건, 이미 아는 분도 계시겠지만 2013년경부터 개발된 Brutal Doom(브루탈 둠)이다. 오리지널 둠의 무기가 더 밀리터리 FPS스럽게 바뀌고 듀크 뉴켐과 모탈 컴뱃스러운 마초이즘이 가미되었다. 그리고 그래픽이 온통 피가 튀는 형태로 잔혹해졌다.

1990년대 중반에 둠/퀘이크의 경쟁작이던 듀크 뉴켐 3D는 high resolution pack이라고 해서 몬스터들을 완전히 폴리곤으로 개조까지 한 리메이크작이 있는데 둠은 모르겠다. 브루탈 둠도 스프라이트 자체를 3D화한 건 아니니 말이다.

추신 1. 찰진 무기들

이상, Doom의 몬스터 내분부터 시작해서 굉장히 많은 얘기가 나왔다. 둠 2는 단순 따발총이나 로켓 런처 같은 평범한(?) 무기 말고도, (1) 버서크(berserk) 파워업이 가능한 주먹, (2) 그야말로 범용성 가성비가 최강인 슈퍼샷건, (3) 이후의 그 어떤 FPS에서도 찾을 수 없는 캐사기 BFG.
이렇게 무기들도 분야별로 개성 넘치며, "찢고 죽이는"(rip and tear) 카타르시스가 느껴지게 정말 잘 만든 것 같다. 울펜슈타인 바로 다음으로 어떻게 저런 것들을 생각해 낼 수 있었을까?

내 총은 반동이 없지만 총을 맞은 적은 팍팍 과장되게 뒤로 밀려나는 것도 쾌감을 증가시키는 요인이다.
그리고 BFG의 경우 단일 파이어볼의 위력이 넘사벽이고 주변의 잡몹들을 싹 정리하는 용도로도 최강이지만, 한편으로 파이어볼이 터질 때 나 자신 역시 적에게 노출하고 적들을 똑바로 보고 있어야만 위력이 제대로 발휘된다는 함정도 있다.

다시 말해 BFG는 다 좋은 대신, 쏘고 튀거나 엄폐물에 숨는 식으로 운용할 수 없다는 뜻이다. 전혀 현실적이지 않고 소스 코드가 공개될 때까지는 정확한 동작 방식을 짐작조차 하기 어려웠던 설정이나, 이런 창의적인 무기를 게임용으로 생각해 내고 구현했다는 것 자체가 심히 경이롭지 않을 수 없다.

추신 2. 스타크래프트와의 접목

엉뚱한 잡생각이긴 하다만, 스타크래프트 같은 게임에서 Doom 2 몬스터를 유닛으로 뽑을 수 있으면 어떨까 상상을 해 봤다. 종족은 인간형, 사이보그형, 외계인형(프로토스?), 그냥 괴물형(저그?) 같은 식으로 나뉠 거고..

좀비맨, 샷건가이 같은 인간형 몬스터는 테란 바락(배럭스)에서 생산될 것이고 헤비 웨펀 듀드는 공격력이 탁월한 상위 유닛이니 아카데미 같은 건물이 추가로 필요하다. 뭐, 그래도 인간형은 전반적으로 너무 약하니 밸런스 보정이 좀 필요하다.
임프나 데몬도 괴물형 중에서는 당연히 저가형 기본 유닛에 속한다. 기획을 어찌 하느냐에 따라 데몬에다가 클록킹을 개발해서 스펙터로 일시적으로 변하거나, 아니면 영구 클록킹 형태로 스펙터를 따로 넣을 수 있다.

아크 바일은 정규 공격이 아니라 프로토스로 치면 다크 아칸 급의 고급 마법형 유닛이 될 것이다. 화염 공격이나 죽은 유닛 소생 둘 중 하나는 건물에서 리서치를 해야 가능하며, 스킬 사용 시에 마나가 필요하다. 카코데몬은 당연히 공중 유닛이고, 페인 엘리멘탈은 캐리어가 인터셉터 생산하고 리버가 스캐럽 날리듯이 내부적으로 로스트 쏘울을 생산해서 날리는 공중 유닛이 될 것이다~! (응???)
사이버데몬이나 스파이더 마스터마인드는 테크트리 최종 단계의 유닛이 될 것이다.

2D 스프라이트가 3D 폴리곤보다 좋은 점은.. 아무래도 컴터에서 처리하기 가볍고 처리 속도가 월등하다 보니 수백, 심지어 수천 마리 물량 개떼전이 가능하다는 것이다. 안 그래도 둠과 스타 모두 '마린 vs 질럿, 캐리어 vs 배틀'처럼 '사이버데몬 vs 스마마, 아라크트론 vs 맨큐버스' 이렇게 개떼 대결이 많이 나돌기도 한다.

"노업 레버넌트 한 부대 뽑아서 사거리 업한 카코데몬 한 부대 잡기"...;;; 비록 FPS와 RTS라고 장르는 다르지만 발상을 바꿔서 이런 교배도 생각할 수 있을 것 같다.
Doom 몬스터들을 그저 슈퍼 샷건이나 BFG, 버서크 주먹으로 내가 학살하거나, 몬스터 내분 붙여서 구경만 하는 게 아니라.. 내가 생산해서 부대 지정해서 다른 몬스터들을 공격하라고 어택 땅 시켜 보고 싶기도 해서 말이다.

추신 3. 언어 이슈

mancubus 몬스터 얘기가 나와서 말인데 언어 관련 얘기만 추가하고서 글을 맺겠다.
외국 동영상을 보니 mancubus의 복수형을 mancubi라고 부르더라. 신기했다.
대학 시절에 강의 계획서라고 많이 들어 봤을 syllabus도 복수형은 원래는 syllabi라고 한다. 라틴어 어원의 단어가 복수형이 좀 기괴한 경우가 있는데 저 단어도 저런 듯..

matrix, index, vertex처럼 -(e)x로 끝나는 단어의 복수형이 -(i)cies로 바뀌는 것과 비슷한 맥락이다.
다만, 자동차 bus는 omnibus에서 끝부분만 떼어 온 라틴어 어원의 단어이지 싶은데 그냥 buses라고 잘 정착해 있다.

Posted by 사무엘

2017/10/06 08:30 2017/10/06 08:30
,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1413

Trackback URL : http://moogi.new21.org/tc/trackback/1413

Comments List

  1. 허국현 2017/10/07 09:24 # M/D Reply Permalink

    또 특이한 복수형으로는 -um으로 끝날 때 -a로 바뀌는 datum -> data 같은 것도 있고(그런데 이제 datum은 거의 사라진 단어라... 대화에서 datas 같은 이상한 단어가 가끔 보이기도 합니다),

    -is로 끝나면 -es로 바뀌는 axis -> axes, hypothesis -> hypotheses 같은 경우도 있고,

    Japanese, Chinese처럼 단복수가 같은 경우도 있습니다.

    인간의 언어라는 것이 참 괴상한 규칙들이 많아서 어렵네요...

    1. 사무엘 2017/10/07 14:43 # M/D Permalink

      datum (..!)은 그렇다 치더라도
      아, s나 z로 끝나서 es인 게 아니라 -is로 끝나는 단어가 복수형이 -es로 바뀌는 건 지금까지 한 번도 생각을 안 하고 있었네요. 정말 기괴합니다. ^^
      자연어에는 일부러 배배 튼 게 아닌가 하는 생각이 들 정도로 괴상한 규칙이 어디에든 꼭 존재하는데, 저는 그게 언어 신수설을 뒷받침하는 심증이라고 생각합니다. 언어가 인간에 의해 우연히 저절로 만들어진 거라면 일부러 그렇게 만들어졌을 이유가 없으니까요.
      말과 '문자' 사이의 괴리라든가, 옛날에 구분하던 것이 오늘날 구분이 없어지는 거라면 자연스러운 변화이지만 말이 처음부터 그렇게 만들어진 건 설명이 안 됩니다.

      그래도 독일어나 러시어, 심지어 한국어의 그 신묘막측한 무질서에 비하면 영어 정도면 그래도 양반이고 국제어로서 손색이 없는 것 같습니다. 단순히 개인적으로 일찍 배워서 익숙하기 때문이 아니라 객관적으로 덜 어려운 거라고 생각합니다.

Leave a comment

컴퓨터 프로그램이 뻗는 방식을 분류하면 크게 다음과 같이 정리된다.

1. 아무 뒤끝 없이 그냥 뻗음(crash)

제일 단순하고 흔한 형태이다. 코딩을 잘못해서 잘못된 메모리에 접근하다가 튕긴 것이다. 그 예로는 null 포인터(null로부터 유도된 인근의 잘못된 주소 포함), 초기화되지 않은 포인터, 초기화되지 않은 배열 첨자 인덱스, 이미 해제된 메모리 포인터 등 참 다양하다.
혹은 애초에 메모리를 할당하는데 할당량에 엉뚱한 값이 들어와서 뻗은 것일 수도 있다. 가령, 음수만치 할당은 저 문맥에서는 대체로 부호 없는 정수로 바뀌면서 도저히 감당 불가능한 엄청난 양의 메모리 요청으로 바뀌기 때문이다.

2. CPU 사용 없는 무한루프

단독으로 돌아가는 프로그램이 제발로 이렇게 되는 경우는 잘 없다. 이건 스레드 내지 프로세스 간에 서로 아귀가 안 맞는 상호 대기로 인해 deadlock에 걸려서 마취에서 못 깨어난 상황이다. 그러니 엄밀히 말해 무한루프보다는 무한대기에 더 가깝겠다.
굳이 커널 오브젝트를 직접 취급하지 않고 윈도우 메시지를 주고받다가도 이렇게 될 수 있다. 가령, 스레드 A가 타 프로세스/스레드 소속의 윈도우 B에다가 SendMessage를 해서 응답을 기다리고 있는 중인데, B는 또 스레드 A가 생성한 윈도우에다가 SendMessage를 했을 때 말이다. 요 데드락을 해소하려고 ReplyMessage라는 함수가 있다.

3. CPU 쳐묵과 함께 무한루프

종료 조건을 잘못 명시하는 바람에 loop에서 빠져나오지 못하는 경우이다. 부호 없는 정수형으로 변수를 선언해 놓고는 while(a>=0) a--; 이런 식으로 코딩을 해서 무한루프에 빠지는 경우도 있다. 얘는 그래도 다행히 메모리 관련 문제는 없는 상황이다.

4. stack overflow와 함께 뻗음

이건 단순 뺑뺑이가 아니라 재귀호출을 종료하지 못하고 비정상적으로 반복하다 이 지경이 된 것으로, 컴에 메모리가 무한하다면 3번 같은 무한루프가 됐을 상황이다. 하지만 현실에서는 물리적인 자원의 한계가 있고, 또 컴이 취급 가능한 메모리 주소 자릿수 자체도 무한하지 않기 때문에 언젠가는 뻗을 수밖에 없다.

재귀호출도 반드시 A-A-A-A-A... 이렇게 단일 함수만 쌓이는 게 아니라 마치 유리수 순환소수처럼 여러 함수 호출이 주기적으로 쌓이는 경우도 있다.
스택은 다음에서 다룰 heap 메모리와는 달리, 그래도 그 정의상 할당의 역순으로 회수되고, 회수가 반드시 된다는 보장은 있다.

5. 메모리 쳐묵과 함께 뻗음

이건 heap memory의 leak을 견디다 못하고 프로그램이 뻗은 것이다. loop 안에서 계속해서 leak이 발생하면 꽤 골치아프다. 또한, 금방 발견되는 leak은 그나마 다행이지, 프로그램을 몇 주, 몇 달째 돌리다가 뒤늦게 발견되는 것은 더 답이 없고 잡기 어렵다. 프로그램이 뻗은 지점이 실제로 문제가 있는 지점과는 전혀 관계 없는 곳이기 때문이다. 뭔가 컴파일 에러와 링크 에러의 차이와도 비슷한 것 같다.

요약하면, 메모리 쪽 문제는 가능한 한 안 마주치는 게 낫고, 마주치더라도 프로그램이 곧장 뻗어 주는 게 디버깅에 유리하다. 1과 5는 포인터를 대놓고 취급하지 않는 C/C++ 이외의 언어에서는 프로그래머가 직접 볼 일이 드물다.
요즘은 그래도 디바이스 드라이버 급이 아닌 평범한 양민 프로그램이라면 메모리 문제로 뻗는 경우 전적으로 혼자만 뻗지, 컴퓨터 전체를 다운시키는 일은 없으니 세상 참 좋아졌다. 이게 다 가상 메모리와 보호 모드 덕분이다.

Posted by 사무엘

2017/10/03 19:34 2017/10/03 19:34
, , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1412

Trackback URL : http://moogi.new21.org/tc/trackback/1412

Leave a comment

1. 이 교숙 (1924-): 우리나라의 상징 BGM들

이런 엄청난 분이 계신다는 것을 최근에야 인터넷을 돌아다니다가 우연히 알게 됐다. 요즘 인터넷은 정말 대단하긴 하다. 지금 존재하는 모든 유· 무형의 사물들에 대해 그 창조주(?)와 기원과 내력에 대해 알 수 있다.
에디슨 같은 질문덕후가 21세기를 살았으면 무슨 짓을 하며 살다가 뭐가 됐을지 궁금해진다.

아무튼, 저분은 우리나라 국민의례 BGM을 있게 한 분이다. 해군 군악대장 출신으로, 국기에 대한 맹세/경례 BGM을 작곡했으며 “빰빠라 빰빠라 밤~”으로 시작하는 그 장성 경례곡도 작곡했다. 그게 정확하게 언제인지는 잘 모르겠다.
지난 2007년에 국기에 대한 맹세 본문이 약간 수정된 바 있지만 BGM은 여전히 그대로이다. 고칠 필요가 없으니까.

확인은 못 해 봤지만 순국선열 및 호국영령에 대한 묵념 BGM도 정황상 저분 작품이 아닌가 하는 추측을 해 본다. 이 묵념은 국민의례를 완전 진지하게 full scale로 할 때만 실시하기 때문에 BGM 역시 자주 들을 수 있지는 않다. 우리나라 근현대 수난기의 양대 비극이 각각 일제 강점기와 북괴(특히 6· 25)이니 순국선열과 호국영령은 각각 전자와 후자를 대표하는 셈이다.

아무튼. 저분이 아직 살아 계신다면 90이 넘은 고령인데, 최근 근황은 잘 모르겠다. 다만, 먼 옛날에 저분에게서 직접 음악을 배운 적이 있는 분의 회고록이 전해진다.

옆길 1. 태극기와 애국가

2007년에 국기에 대한 맹세가 일부 수정된 것과 마찬가지로, 태극기 자체도 공식적으로 한번 잠수함 패치가 가해져서 오늘에 이르고 있다. 마지막으로 수정된 게 1997년 9월의 일로, 태극 무늬의 청홍 색조가 좀 더 채도가 높아지고 산뜻해졌다. 그래서 빨강은 자주색에 좀 더 가까워졌고, 파랑은 남색? 군청색?에 좀 더 가까워졌다. Windows의 고전 테마에서 98의 시퍼런 프로그램 제목 표시줄이 2000/ME에서는 남색에 좀 더 가까워졌는데, 그런 식의 변화를 생각하면 된다.
저 국기에 대한 맹세 유튜브 동영상 화면에 떠 있는 태극기 그림이 표준 배색대로 맞게 된 거 맞다.

개인적으로 태극기는 국기로서 너무 단순하지도 않고, 그렇다고 아랍 글자나 비트맵-_- 그림처럼 인간이 도저히 그릴 수 없을 정도로 복잡하지도 않으면서 적당히 좋은 것 같다. 기하학적인 복잡도를 문자와 비교하자면 한글과 비슷한 구조이다. 한글도 직선과 원으로만 이뤄졌고 막 꼬부랑스럽거나 한자만치 복잡하지는 않으니까.

하지만 애국가는 예전에도 의견을 피력했듯이 개인적으로 좀 별로다. 가사가 진취적인 구석 없이 너무 밍밍하고, 앞부분 박자도 이상해서. 애국가야말로 저런 전문가가 좀 다시 만들 수 없을까? 나중에 우리나라가 북괴를 몰아내고 통일을 이루면 화폐 단위 고치고 헌법 고치고 두음법칙은 없앤 뒤에 애국가 정도는 이 기회에 다시 제정해도 될 것 같다.

옆길 2. 짤막한 멜로디 (1920-2001)

2~3분 이상 길이에 기승전결(?) 형식을 갖춘 노래나 악곡이 아니라 ‘딩동댕!’ 같은 짤막한 멜로디 말이다. “만나면 좋은 친구” 방송국 시그널송이나 초인종 벨소리.
글에다 비유하면 산문이나 운문도 아니고 짤막한 포스터 표어와 비슷한 위상일 것이다. 그림에다 비유하면 커다란 그림이 아니라 16*16, 32*32 크기의 아이콘 정도.

이렇게 극도로 제한된 시공간에다가 최대한 임팩트 있는 메시지를 전달하게 곡을 쓰는 건 보통일이 아닐 것 같다.
장성 경례곡을 좀 만들어 달라/보라는 의뢰를 받았거나 학교 수업 과제를 받았다면 독자 여러분은 어떻게 하시겠는가? 길어야 30초 남짓한 시간 동안 무슨 심상을 표현하도록 콩나물을 오선지에다 그려 넣을까?

더 나아가 초인종 BGM은 어쩌다가 하필 “엘리제를 위하여”로 온통 물갈이가 됐을까? 그 곡이 초인종 BGM으로서 도대체 무엇이 좋아서? 장성 경례곡을 듣다 보니 이런 의문도 강하게 든다.

단, 저것들 말고 군대 기상 나팔 BGM은 딱히 작곡자가 전해지지 않는 것 같다. 외국 군대에서도 오래 전부터 나돌던 멜로디가 적당히 변형되었다.

2. 김 희조 (1920-2001): 국민체조

이분은 육군 군악대장 출신이다. MBC 기자 출신인 여자분과는 당연히 동명이인.
지금은 학교에서 자취를 감췄다지만 "국민체조" BGM과 “잘 살아 보세”가 바로 이분의 작품이다. 그렇다면 자매품인 “국군 도수체조” BGM도 같은 출처이지 싶다.

본인은 먼 옛날에 잉여짓 차원에서 국민체조 BGM의 주선율을 오선지에 받아써 본 적이 있다. 진작부터 머릿속 장기 기억에 영구보존된 곡이니 검색해서 다시 안 들어도 얼마든지 채보 가능하다.
기본에 충실한 박자이면서도 최소한의 기교는 다 동원된 것 같았다. 음표는 2분에서 16분음표까지 다 나오고 점 4, 8분음표도 쓰인다. 임시 조표도 나오고 당김음(등배 운동), 스타카토(당연히 뜀뛰기에서), 셋잇단음표(전주에서)도 한 번씩 나온다.

템포 변화가 잦은 편이다. 가령, 전주에서는 ♩=108가량이지만, 체조가 시작되고부터는 ♩=88 정도로 느려진다. 뜀뛰기에서는 ♩=112~120 정도로 평소보다 25% 이상 템포가 빨라지다가, 마지막 숨쉬기에서는 ♩=60~70대까지 떨어진다.
모든 체조를 한 번씩만 했을 때(뜀뛰기 후 다시 처음으로 돌아가는 게 아니라 팔다리 운동으로 진입) 전주에서부터 숨쉬기 끝까지 음악의 러닝 타임은 우연의 일치인지 딱 2분 30초가 나왔던 걸로 기억한다. 이런 것도 다 계산해서 작곡한 건지? 처음으로 한번 되돌아가서 풀 세트로 하면 4분 50초 정도 걸린다.

참고로, 국민체조의 BGM 말고 체조 동작 자체를 고안하고 구령을 녹음한 사람은 당연히 음악인이 아닌 체육인이다. 전 경희대 교수인 유 근림 씨로 알려져 있다.

3. MBC 창작 동요제

이제 분위기를 바꿔서 오랜만에 동요 얘기를 좀 꺼내 보겠다.
<새싹들이다>. 1983년 제1회 MBC 창작 동요제 대상 수상작인 것, 작사 작곡자가 '좌'씨인 건 알고 있었는데, 제주도민의 작품인 건 처음 알았다. 전문적인 음악가가 아니라 현직 교사의 작품이다.
저 애도 참 목소리 예쁘고 노래 잘 부른다. 1972년생 정도일 텐데 지금은 어디서 뭘 하고 있을까?

개인적으로 저거랑 제일 비슷한 풍의 다른 곡은 <어린이 노래>(하늘 향해 두 팔 벌린 나무들 같이..)라고 생각하는데, 그래도 그거보다 더 나중에 작곡된 <새싹들이다>가 더 훨씬 더 밝고 명랑한 분위기이다.
미디, 신시사이저, 컴퓨터 반주 같은 일체의 디지털스러운 흔적 없이, 완전 클래식으로 오케스트라 꾸며서 반주하는 것도 지금 보니 굉~장히 인상적이다. 영상에다 비유하면 CG 없는 아날로그 특수효과만으로 구성됐다는 뜻이다.

이거 다음 1984년도 대상 수상작인 <노을>은... 나 초딩 시절, 컴퓨터 학원에서 GWBASIC 배우던 시절에 들은 적이 있다.
그 당시 매주 금요일은 학원에서 다른 수업이 없고 그냥 원장님이 만든 음악 재생 프로그램을 있는 그대로 쳐서 실행되는 거 검사만 받고 나면 오락(게임)을 할 수 있었다.
그때 입력해서 들었던 곡 두 개가 지금까지 기억에 남아 있는 게 하나는 MBC 드라마 <질투> 오프닝이랑, 알고 보니 노을이었다.
다시 말해 난 저 두 곡은 텔레비전에서 처음 들은 게 아니라 PLAY문 코드를 통해서 PC 스피커로 난생 처음으로 들었다.

MBC 창작 동요제는 의외로 오래, 2010년 20몇 회차까지 계속되긴 했다. 그러나 얘는 그 성격상 순수성이 오래 유지되기가 도저히 어려웠다.
21세기부터는 출품되는 곡이 점점 더 동요답지 않게 기교가 심해지고 가요풍으로 바뀌고, 출연하는 애들의 의상만 쓸데없이 고퀄로 올라가고, 후원 협찬 줄어드는 등.. 여러 악재가 겹치면서 2010년대에 들어와서는 폐지됐다. 어찌 보면 미스코리아와 비슷한 과정을 거치며 위상이 추락했다.

Posted by 사무엘

2017/10/01 08:32 2017/10/01 08:32
,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1411

Trackback URL : http://moogi.new21.org/tc/trackback/1411

Leave a comment

1. 화생방

공중이나 바다가 아닌 평범한 육상 재래전 전쟁터에서 군인을 가장 많이 죽이는 것은 폭발물 파편이다. 근원지가 수류탄이든 지뢰이든 포격이든 폭격이든, 어쨌든 날아가서 박히기만 하는 게 아니라 터져서 넓은 면적에 파편을 날리는 폭탄이 짱이다. 단순 총알은 파괴 면적이 너무 작은 관계로, 저격이 아니라면 그 자체가 사람을 죽이는 경우는 흔치 않다.

그래도 총은 여전히 군인의 상징이며, 소총 사격은 화망을 형성해서 아군을 엄호하거나 적군을 움직이지 못하게 하는 역할을 충분히 한다. 당장 kill 수를 많이 못 낸다고 해서 개인화기가 일체의 쓸모나 필요가 없는 건 결코 아니다. 지금 세계가 명목상 교류와 평화를 추구하고 옛날 같은 제국주의 침략 전쟁을 지향하지는 않는 시대가 됐다고 해서, 군사력 자체가 당장 필요하지 않게 된 건 절대 아니듯이 말이다.

그런데, 전쟁터에서 사람을 죽게 하는 방법은 폭탄이나 총알, 심지어 총검을 이용한 물리적인 충격만 있는 게 아니다. 파리를 굳이 손바닥이나 파리채로 쳐서 잡는 게 아니라 에프킬라를 뿌려서 잡듯,  방탄조끼나 헬멧이 아니라 방독면으로 방어해야 하는 방식의 전투도 있다. 이를 특별히 '화생방전'이라고 한다. 이건 공격 수단들의 근간 원리에서 각각 첫 글자를 딴 명칭인데, 마치 군사의 육해공처럼, 물리 화학 생물이라는 과학의 세 분야를 두루 아우르는 용어이기도 하다.

단, 보다시피 '물화생'은 아니고 '화생방'이다. 물리는 분야가 너무 넓어서 그런 것 같다. 과학의 각 분야에 대응하는 공학을 생각해 봐도 화학공학, 생명공학은 있지만 물리공학이라는 말은 없으니 말이다. 그 대신 기계공학, 전자공학, 원자력공학, 항공우주공학 등이 있을 뿐이지.
스타에서 테란의 물리학 연구소는 배틀크루저의 야마토 포를 개발하는 곳인데, 물리학의 어느 분야를 주로 연구하는지가 문득 궁금해진다.

스타에도 응당 화생방에 해당하는 개념이 있다. 디파일러의 플레이그가 생물에 해당하고, 베슬의 이레디는 방사능에 속한다.
원래는 고스트의 핵도 방사능이어야 하지만, 설정과 밸런스 문제 때문에 게임엔 반영 안 됐고 그냥 크고 무시무시한 폭탄이라고 구현돼 있다.
화학은 잘 모르겠다. 스타에 딱히 독가스 같은 게 등장하지는 않으니까.. 단지, 광범위 대량학살용으로는 독가스보다 더 고차원적인 프로토스의 싸이오닉 스톰이 존재할 뿐이다.

난 태어나서 화생방(전)이라는 단어를 처음 본 곳은 아마 초딩 시절 전화번호부 끝부분 부록에 적혀 있던 '전시 국민 행동 요령'이었지 싶다.
성경에도 계시록뿐만 아니라 슥 14:12처럼 사람이 산 채로 눈과 살과 혀가 녹아/썩어 없어지는 묘사는 뭔가 화생방전을 떠올리는 섬뜩한 장면으로 보인다.

2. 전쟁의 주요 양상

  • 고지전: 나로서는 이거 뭐 6· 25 말고는 다른 고지전 자체가 떠오르는 게 존재하지 않는다. 한반도 중부의 서쪽은 평지 위주였지만 우리에게 지형적으로 불리하고 판문점도 가까이 있어서 제대로 싸울 수 없었던 반면, 동부의 첩첩산중에서는 고개를 하나 점령해서 조금이라도 영토를 더 수복하려고 치열한 전투가 벌어졌으니 말이다.
  • 참호전: 1차 세계 대전 당첨이다. 여차여차 하다 보니 서로 평지에서 땅따먹기를 한 뒤, 참호 파고 지겹도록 시즈 탱크 우주 방어만 벌이는 지경이 벌어졌다. 무슨 FPS에서 캠핑처럼.. 공격이 방어보다 너무 불리하다 보니, 참호 하나 점령하려고 갈려 들어간 병사들이 그 당시에 얼마였나 모르겠다. 그 교착 상태를 해소하려던 와중에 원시적인 탱크와 전투기가 발명됐고 독가스도 동원됐다.
  • 상륙전: 바다에서 육지로 상륙하면서 섬을 하나씩 점령하는 형태의 전투는 2차 세계 대전 중에서 태평양 전선이 대표적이다. 전쟁의 규모가 커지다 보니 미군 해병대의 비중이 본격적으로 커졌다. 뭐, 거기 말고도 본토 진출을 위해서 서부 전선의 노르망디 상륙이 있고 나중에 6· 25 때 인천 상륙도 전쟁사의 한 획을 그었지만..

오늘날은 세상에 고층 건물이 즐비한 대도시가 많기 때문에 전쟁이 나면 '시가전'의 비중이 커질 것이다.
만약 북괴가 다시 남침해서 서울로 쳐들어온다 해도, 2017년의 서울은 1950년 당시의 그 허접한 서울이 절대 아니다. 그때와는 비교도 할 수 없이 복잡하고 빽빽해진 건물숲 속에서 시가전을 제대로 치러야 할 것이며, 그렇게 호락호락 사흘 만에 서울 점령이란 절대 가능하지 않을 것이다.

하지만 역사 속의 전쟁 중에 시가전으로서 내가 딱 떠오르는 건 없다. 그리고 2차 대전은 동부(vs 러시아)나 태평양 전선(vs 일본..) 말고 서부 전선에 대해서는 내가 딱히 기억이나 존재감이 느껴지는 게 없다.

3. 탄피 처리

공기총 같은 거 말고 화약으로 격발하는 총들은 탄두와 화약이 탄피로 감싸져 있는 탄환을 사용한다. 음식을 먹고 나면 그릇이 남고 커피를 마시고 나면 컵이 남듯, 총을 쏘고 나면 탄피 껍데기만 남아서 사출된다.
탄피 부분까지 싹 폭발해서 없어지거나, 아니면 같이 발사되어 날아가는 총알이 있다면, 마치 손잡이 부분까지 몽땅 과자로 돼 있어서 다 먹어치울 수 있는 길거리 아이스크림 콘만큼이나 참 좋을 것이다. 하지만 총알을 그렇게 만들었다간 화약 부분이 평소에는 어지간히 열받아도 절대로 폭발하지 않고 안전하게 있다가 원하는 순간에만 격발하게 만들기가 도저히 불가능하다. (실용적인 가성비 수준에서..)

탄피 처리라는 게 군대에서 골치아픈 일이긴 하지만.. 그래도 얘는 여러가지 이유로 인해 가능한 한 몽땅 회수해서 재활용하는 것이 바람직하다. 환경 보호(?)나 물자 절약 따위 말고 좀 더 social한 이유로는..
평시에는 탄약의 무단 유출을 감지하고 자살· 프래깅 같은 부정 사용을 예방하기 위해서이다. 총을 몇 발 쐈는지 알고 싶을 때 탄피 개수를 세는 것만치 단순무식하고 효과적이면서도 정확한 방법이 없기 때문이다.

전시에야 적에게 총 쏘는 게 병사들의 재량 영역이 되며, 수십· 수백 발의 총알이 순식간에 없어진다. 그러니 실탄 사용 내역을 평시만치 일일이 파악하고 통제하면서 탄피를 챙길 여유가 없다. 그 대신, 적군에게 아군의 위치 내지 이동 경로를 노출하지 않기 위해 흔적을 치우는 과정에서 탄피도 눈에 띄는 것 정도는 다 줍고 치운다.
그리고 전투가 끝나고 병사들이 병영으로 복귀한 뒤에는 모든 병사들을 일일이 정말 빡세게 몸수색을 해서 잔여 실탄을 몰래 짱박아 둔 게 절대 없도록 조치를 취한다고 한다. 1996년 강릉 무장공비 토벌 작전이 끝났을 때에도 이런 후처리 절차가 응당 행해졌다고 한다.

4. 심폐소생술과 인공호흡

사람을 죽이는 전쟁 얘기를 했으니 다음으로는 사람 살리는 얘기로 넘어가 보겠다.
멀쩡하던 사람이 어디로 추락하거나 뭘 맞거나 부딪치지 않았는데 외상 없이 의식을 잃고 픽 쓰러지는 건 아무래도 흔히 보는 장면은 아니다. 신경계나 뇌 쪽의 문제로 인해 몸이 셧다운 된 게 아니라면 저런 건 대체로 (1) 호흡기 아니면 (2) 순환기에 문제가 생겼기 때문이다.

목에 생선 가시 같은 게 걸려서 숨을 못 쉬고 쓰러지는 건 기도 폐쇄로 인한 질식이니 (1)번 계열이다. 본인이나 어린 자녀가 갑자기 이런 상황에 처했을 때 대처하는 방법을 뒤늦게 네이버에서 검색하려 든다면 너무 늦을 것이다. 평소에 숙지해 둬야지.
그리고 물에 빠진 건 숨을 못 쉰 질식에다 폐에 물이 들어간 것까지 복합이다.

호흡과 무관한 순환 계통 문제는 부정맥 같은 심장의 지병 때문이다. 그런데 혈액 순환이 잠시만 중단돼도 어차피 호흡기 문제와 마찬가지로 뇌에 산소가 제대로 못 가게 되고, 뇌세포가 죽기 시작해서 몸에는 심각한 트러블이 발생한다.
물에 빠져서 질식으로 인해 의식을 잃어 가는 거나, 심장 박동이 중단되어 쓰러진 거나 원인은 다르지만 결과는 비슷하며, 단 몇 분간의 golden time 이내에 최소한의 적절한 조치가 취해져야 하는 건 동일하다.

이거 하냐 못 하냐에 따라 사람이 사냐 죽느냐, 혹은 살더라도 온전히 살아나냐 반신불수가 되느냐가 갈린다. 그래서 소위 '심폐소생술'(CPR)이라 하는 기법이 도입되고 대대적으로 홍보되고 있다.
누군가가 쓰러지면 먼저 "괜찮으세요?" 물어 보고, 의식이 없으면 주변 사람을 지목해서 "왼쪽 저 여자분은 당장 119에 신고해 주세요, 저기 흰 옷 입으신 분은 근처의 심장 제세동기를 가져와 주세요" 지시를 한다. 그 뒤 CPR 실시다.

심폐소생술은 배터리가 방전된 차를 시동이 걸릴 때까지만 밀어 주는 게 아니다. 의료진이 와서 환자를 인계할 때까지 시술자의 손으로 심장의 역할을 얼추 대신하는 거라고 생각하고 가슴을 눌러야 한다. 하다못해 사람이 수 분 동안 숨을 참으면 참았지, 심장 박동이 그만치 멈춰 버리면 어찌 되겠는가?
약한 갈비뼈는 부러뜨리는 것도 감수한다는 심정으로 굉장히 세게, 분당 110~120회 남짓한 주기로 생각보다 빠르게, 오래 해야 한다.. 이건 수~10수 분 간격으로 옆 사람과 주기적으로 교대도 해야 할 정도로 꽤 힘든 노동이다.

전문적인 의료· 보건인이라면 몇 차례의 CPR 후 환자 상태를 봐서 인공호흡을 재량껏 시도할 수도 있으나, 일반인을 상대로 한 매뉴얼에서는 그런 건 물에 빠진 가족을 구한 정도가 아니면 안 해도 된다고 진작에 빠졌다. 환자가 독극물에 중독돼 있는 경우 구강 접촉은 시술자도 위험에 빠뜨릴 수 있거니와, 명백한 호흡기 쪽 이상이 아니라면 심장 압박만 잘 해 줘도 산소 전달은 그럭저럭 된다고 여겨지기 때문이다. CPR이 그만큼 더욱 중요하다고 보는 셈이다.

CPR과 인공호흡은 의식을 잃은 사람을 구명하는 양대 조치로 여겨지고 있는데, 취지와 목적과 효과가 이렇게 서로 차이가 있다는 점이 개인적으로 와 닿았다. 호흡과 혈액 순환의 관계에 대해서도 이 기회에 다시 한번 생각하게 되었다.
참고로 사람의 목을 졸라 죽이는 교수형도 흔히 생각하는 호흡의 차단이 아니라, 그에 앞서 뇌로 가는 혈류를 막아서 훨씬 더 신속하게 사형수를 죽이는 것이 목적이다. 물론 집행을 잘못하면 여전히 켁켁거리면서 더 고통스럽게 죽게 될 수도 있다.

5. 보건의료인과 군대의 관계

아군을 살리는 일은 적군을 죽이는 일 이상으로 매우 중요하고 어렵고 책임감이 큰 스킬이다. 그렇기 때문에 저 스킬의 보유자는 어떤 형태로든 소총 들고 전장에서 뛰어나니는 알보병 소총수 같은 보직에는 결코 투입되지 않는다. 그 대신,

  • 군 소속의 의사가 돼서 장교 계급으로 병역을 수행하는 방법이 있다.
  • 아니면 군대와는 빠이빠이 하고 그냥 공중보건의 신분으로 스킬의 난이도 대비 굉장한 저임금과 널널함으로 병역을 수행할 수도 있다.
  • 보건의료 계열 출신이긴 하지만 정식 의사보다 낮은 급이거나(물리치료사..) 미묘하게 다른 계열이라면(의공, 수의학 등등..) 의무병으로 빠질 수 있다. 위생병은 의무병의 옛 명칭 되겠다.

단,

  • 공보의로 병역을 마친 의사들은 여느 보충역들처럼 명목상 예비역 이등병이며, 예비군 훈련을 받는다. 의사들은 직장인(봉직) 내지 자영업자(개원)이지, 무슨 보건소 직원 같은 처지가 아니기 때문이다. 군· 경이나 교사, 소방관만치 전시 보직이 국가 차원에서 완전히 동일하게 보장되지 않는다.
  • 의사라도 극소수 만학도 의대생이나 의전 출신처럼 군대를 다른 경로로 이미 다녀온 사람이 예외적으로 있다. 이들은 여느 의사들 같은 공보의나 군의관 복무 경험이 있지 않다.

6. 주유와 충전의 차이

우리 주변에서 볼 수 있는 대부분의 기계들은 동력의 원천이 기름 먹는 (1) 내연기관이 아니면 전기 먹는 (2) 모터이다.
에너지 공급이라는 관점에서 봤을 때, 주유는 사람에다 비유하면 식량을 그냥 가방이나 창고에 넣고 비축하는 것과 같다. 그러니 아무리 많은 양도 비축이 금방 끝날 뿐만 아니라, 공간이 허락하는 한 얼마든지 해도 문제 없다.
그러나 충전은 실제로 사람 몸에다 밥을 먹이는 것과 얼추 비슷하다. 그렇기 때문에 시간이 엄청 오래 걸리며, 인간이 소화하고 비축할 수 있는 양만큼만 가능하다.

전기는 에너지 그 자체이다. 배터리의 전기가 소모될 때 발생하는 화학 메커니즘을 역방향으로 가해 줘야 충전이 된다. 세상엔 공짜란 없으니 말이다. 충전 아니면 방전, 그리고 전동기 아니면 발전기.. 전기는 이렇게 상호 가역적인 에너지 이동 메커니즘이 있는 게 신기하다. 마치 생물에서 광합성 아니면 세포호흡이 있는 것처럼 말이다.

다만, 사람이 손으로 수동 발전기를 죽어라고 돌려 가지고 그 알량한 전기로 할 수 있는 일은 정말 얼마 없다. 결국 기계가 필요하다.
반대로, 아무리 힘이 넘쳐나도 배터리가 견딜 수 없을 정도의 과다한 에너지가 짧은 시간 동안 가해지면 배터리가 터진다. 충전 시간을 무슨 주유 시간마냥 획기적으로 단축시킬 수 없는 이유가 이 때문이다.

사람은 오랫동안 굶은 상태에서 갑자기 기름진 음식을 막 먹으면 몸에 큰 탈이 나고 심하면 그걸로 죽기까지 한다. 그것처럼 배터리도 무슨 탱크 안에 잘 밀폐· 보관돼 있는 석유처럼 stable한 물건이 아니다. 완충과 완방 반복 시의 내부 상태 변화, 충전 가능 용량의 감소, 너무 추운 환경에서의 자연 방전처럼 까탈스러운 변수들이 존재한다. (아 하긴, 석유조차도 휘발유 같은 건 생각만치 오래 보관 가능하지 않으며, 증발과 변질 때문에 몇 년밖에 못 간다고는 하더라..)

이런 전기와는 달리, 석유는 그 자체는 에너지가 아니라 평범한 액체일 뿐이다. 엔진이 돌아가야만 그제서야 석유가 연소와 폭발을 통해 에너지로 바뀐다. 엔진은 연료의 공급과 비축이 신속하고 간편하고 안정된 반면, 그 엔진을 최초로 돌리기 위해서는 전기 같은 외부 에너지 공급이 필요하다는 한계가 있다. 관계가 이렇게 설명된다.

순수 전기차가 배터리의 용량과 무게· 가격 문제 때문에 도저히 실용화가 못 되고 소형차 수준에 머물러 있는 건, 과거에 브라운관이 화면 크기에 비례해서 급격히 두꺼워지고 무거워지는 것 때문에 30인치대 이상의 대형화는 도저히 엄두를 못 냈던 한계를 보는 것 같다. 요즘의 왕창 크고 넓으면서 두께는 왕창 얇은 텔레비전과 얼마나 비교되는가?

과거에는 전기 자동차는 소형차보다도 더 작은 경차 수준에 머물다가 그나마 기술이 발전해서 이젠 소형이나 준중형 승용차까지는 노리는 모양이다. 하지만 대형 버스나 트레일러가 순수 전기만으로 지금처럼 힘차게 달리는 것은 요원한 일이다. 전기차는 자체 동력은 말할 것도 없고 지금까지 엔진의 힘과 열의 도움을 받아 자연스럽게 얻던 냉난방마저 추가로 자력으로 해결해야 하니 그 부담이 이만저만이 아닐 것이다.

획기적인 배터리나 무선 송전 기술이 개발되지 않는 한, 전기차는 대형차· 군용차까지 몽땅 대체하지는 못하고 그냥 개인용 자가용 수준에 머무르면서 기름 자동차와 공존할 가능성이 높아 보인다. 철도에서는 전기 기관차가 대형차 영역인 여객과 화물 수송에서 그야말로 디젤이 넘보지 못하는 차력쇼를 선보이고 있는 것과 무척 대조적이다. 다만, 아직까지는 부피 당 에너지 축적 능력 면에서 석유를 능가하는 원천은 없는 듯하다.

참고로 하이브리드 차는 엔진이 어중간하게 크고 무거워지고 비싸지기 때문에 경차나 소형 승용차에서는 수지가 맞지 않고, 심지어 이미 더 크고 무겁고 복잡한 디젤과도 그리 궁합이 안 좋다. 승용차 중에서 최하 준중형 이상은 가야 하고, 적당히 비싸면서 가성비도 챙긴 쏘나타-그랜저급 승용차가 하이브리드를 얹기 제일 적당하다.
하지만 아예 최고급 기함급 대형 승용차는 오로지 성능만 추구한다거나 돈이 썩어나는 부자들만 공략하는 너무 고매한 컨셉이어서 그런지, 휘발유 말고 다른 동력원을 얹은 사례가 없다. (에쿠스 디젤이나 롤스로이스 하이브리드 같은 건.. ㅡ,.ㅡ;;)

* 이상, 위의 모든 아이템들은 민방위 교육 가서 떠올랐던 생각과 글감들이다~
그러고 보니 육군 대령이나 준장급은 예편한 뒤에 예비군 내지 민방위의 안보 강사로 종종 빠지는 것 같고, 대위· 소령급은 예편 후에 군무원으로 취직해서 예비군 동대장으로 들어가는 것 같다.

Posted by 사무엘

2017/09/28 08:34 2017/09/28 08:34
, , , , , , , , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1410

Trackback URL : http://moogi.new21.org/tc/trackback/1410

Leave a comment
« Previous : 1 : 2 : 3 : 4 : 5 : ... 134 : Next »

블로그 이미지

철도를 명절 때에나 떠오르는 4대 교통수단 중 하나로만 아는 것은, 예수님을 사대성인· 성인군자 중 하나로만 아는 것과 같다.

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2017/10   »
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:
863122
Today:
226
Yesterday:
535