« Previous : 1 : ... 23 : 24 : 25 : 26 : 27 : 28 : 29 : 30 : 31 : ... 43 : Next »

컴퓨터로 뭔가 input을 받아들여서 output을 내는 나만의 프로그램을 개발한다면, 그 결과물이 단순히 화면으로만 잠깐 나타났다가 사라지는 걸 원하지는 않을 것이다. 꼭 프린터로 출력까지는 아니더라도 파일로 저장하여 사용자의 컴퓨터에 (반)영구적으로 남는 정도는 가능해야 할 것이다.

일반적인 텍스트/그림 파일뿐만이 아니라 내 프로그램만이 인식할 수 있는 고유한 파일 포맷을 제정하고, 그 포맷이 널리 쓰이게 되는 것은 분명 해당 파일 포맷을 만든 사람에게는 기분 좋은 일일 것이다. 새로운 이미지 파일 포맷이라든가 압축 파일 포맷처럼 말이다. 본인의 경우는 <날개셋> 한글 입력기의 글쇠배열/입력 설정 파일이 이런 창조물의 범주에 속하게 됐다.

파일 포맷이라는 건 지금 당장 공간 낭비 없이 읽고 쓰기 빠르게 만드는 효율도 중요하지만, 범용성과 확장성도 대단히 중요하다. 지금 만들고 있는 프로그램이 구조와 기능이 앞으로 어떻게 바뀔지 알 수 없기 때문이다. 마치 프로그래밍 언어가 하드웨어 친화와 사용자 친화라는 양 이념 사이의 tradeoff로 떨어지듯, 파일 포맷도 위의 두 이념 사이의 tradeoff를 고려하여 제정된다.

또한 파일 포맷은 거의 필수적으로 앞부분에 헤더가 들어간다. 이 파일이 요런 파일 포맷으로 된 파일이라는 것을 나타내며, 헤더가 일치하지 않으면 파일을 더 읽지 말고 에러를 출력하라는 일종의 배려이다. 헤더의 앞에는 식별자가 있는데, 요것이 또 파일 포맷마다 아주 개성이 넘쳤다. 도스 실행 파일(EXE)은 MZ, ZIP 압축 파일은 PK 등.

도스에서 파일의 내용을 보여주는 type 명령은 end-of-file을 나타내는 아스키 문자인 0x1A를 만나면 뒷부분에 텍스트가 더 있어도 표시를 멈췄기 때문에, 파일 시그니처의 끝에다가도 저 문자를 넣어 주는 게 일종의 센스쟁이 관행이었다. 딱 HWP Document File v3.0 요까지만 출력하고 멈추게 할 수 있으니까 말이다. 0x1A는 10진수로 26인데, 이것이 바로 지금도 copy con 다음에 종결을 위해 입력하는 Ctrl+Z와 대응한다. Z는 알파벳 26째 마지막 문자이니까 말이다.

PNG 그래픽 파일은 이 시그니처를 상당히 머리를 써서 만든 것으로 잘 알려져 있다. 마냥 텍스트 파일로 오인하지 않게 의도적으로 맨 앞은 0x89라고 128보다 큰 문자를 집어넣고, 그 다음 PNG를 찍고 줄 바꿈 문자를 찍은 뒤 0x1A로 종결시킨다.

옛날에 아래아한글이 도스용으로 1~2.x 버전이던 시절엔 이런 미래 확장 가능성을 꼼꼼히 설계를 안 했는지 파일 포맷이 수시로 바뀌어서 하위 호환성이 깨지곤 했다. 뭐, 2.1 때는 최초로 압축 저장 기능이 생겼고 도중에 암호 체계가 뚫리는 해프닝이 있어서 불가피하게 포맷이 바뀌어야 하기도 했지만 말이다.
그나마 3.0 포맷이 도스와 Windows 공용으로 무려 97 버전까지 변경 없이 잘 쓰이다가 그래도 지금은 무려 워디안 이래로 포맷이 바뀌지 않고 꿋꿋이 잘 나가고 있다. 안정화가 됐다.

그런 최소한의 융통성을 갖춘 파일 포맷을 만들려면, 결국 어떤 용도의 포맷을 만들든지간에 버전 정보를 남기고 섹션, 구획(혹은 chunk)을 설정하는 정도의 추상화는 공통으로 필요하다. 내가 아는 chunk의 정보만 읽어들이고 모르는 건 무시할 수 있게, 하위 호환이 되게 말이다. PE라고 불리는 Windows용 실행 파일에서도 이런 구획이 있고(text, rdata, data, rsrc 등), TTF 폰트 파일에도 내부에 구획이 있다(cmap, glyf, head 등). 미디(mid) 음악 파일도 온갖 구획들이 합쳐진 컨테이너 포맷이다.

그렇게 외부에서 구획을 표현하는 방식은 파일 알멩이 포맷 이전에 껍데기 '컨테이너' 포맷이라는 공통 규격으로 바뀌는 게 요즘 추세이다. 매 프로그램마다 GUI 프로그래밍을 제각각 할 필요가 없듯, 껍데기를 일일이 새로 만들 필요는 없으니 말이다. 무손실 압축 파일 포맷도 컨테이너와 압축 알고리즘을 분리해서 생각하는 건 상식 중의 상식이고, 손실 압축 알고리즘의 각축장인 동영상/소리 파일 포맷도 컨테이너와 내부 컨텐츠 포맷은 계층이 분리돼 있다.

컨테이너는 아예 human-readable한 텍스트 방식과, 그것보다는 성능을 더 중요시한 바이너리 방식 둘로 나뉜다.
텍스트는 xml이 대세를 평정하는가 싶었는데 요즘은 json도 급부상하고 있다. json은 프로그래밍 언어에서 배열이나 튜플 같은 복합 자료형을 표기하는 방식을 그대로 가져왔다는 점이 무척 참신하다. 배열스러운 나열과 key-value 형태의 데이터를 모두 표기할 수 있으며, 그 덕분에 바이너리 덤프 같은 것도 xml보다는 덜 부담스럽게 집어넣을 수 있고 공간 효율도 더 좋다.

바이너리 차원에서의 컨테이너 포맷으로 요즘 굉장히 많이 쓰이는 건 zip 압축 포맷이다. 수많은 압축 알고리즘들이 존재하지만 역시 오픈소스 앞에서는 답이 없다. zip이 세상을 평정했다. 가장 친숙하게는 MS Office 2007 이후의 문서 파일 포맷, 그리고 오픈오피스 문서 파일 포맷이 내부적으로는 zip 압축 파일이다. Java의 jar 라이브러리, 그리고 안드로이드 adb 패키지도 zip이다.

다만, 저런 프로그램들은 zip 안에다가 자기 방식으로 고유한 메타데이터도 집어넣곤 한다. 그렇기 때문에 이들 파일의 압축을 풀었다가 다시 압축을 했다고 해서 그것들이 해당 오피스 문서나 패키지로 인식되지는 않는 경우가 많다.

멀티미디어 파일 포맷 중에는 avi/wav가 동일하게 RIFF(리소스 교환 파일 포맷)라는 컨테이너 기반이다.
한편 Windows 세계에서는 의외로 많이 쓰이는 공용 바이너리 컨테이너 포맷이 있는데.. 그것은 바로 OLE Compound Binary이다. 이름에서 알 수 있듯이 바이너리 규격에서 여러 프로그래밍 규격들의 통일을 시도했던 OLE/COM 기술과 역사를 같이하는 포맷인 것 같다. 난 잘 모르겠지만 아마 이 파일을 읽고 쓰는 I*** 하는 인터페이스 API도 있으리라 여겨진다.

이 방식의 파일은 D0 CF 11 E0 A1 B1 1A E1이라는 8바이트짜리 시그니처로 시작한다. 의도적으로 128 이하의 텍스트나 제어 문자는 제외한 듯하다. 그리고 앞부분엔 0xFF 문자가 수십~수백 개 나온다.
MS Office가 2007 버전이 등장하기 전에 재래식 doc/xls/ppt가 이 컨테이너 하에서 자기 데이터를 저장하곤 했다. 그리고 지금도 일반적으로는 xml+zip 기반의 docx/xlsx/pptx이지만 암호를 걸어서 저장하면 여전히 예전처럼 이 compound binary를 사용한다. 이건 그리 널리 알려져 있지 않을 것이다.

엑셀의 경우 대용량의 데이터를 빠르게 저장하기 위해 예외적으로 xml 대신 바이너리 포맷을 쓰는 xlsb도 지원하긴 하는데, 이때에도 컨테이너는 여전히 zip이다.
하지만 암호를 걸면 xls든 xlsb든 동일하게 컨테이너가 저 OLECB 방식으로 회귀한다.

OLECB는 Office 문서에서만 쓰이는 게 아닌 범용적인 컨테이너 포맷이기 때문에 Windows의 내부에서는 thumbs.db에서도 쓰이고 심지어 msi 패키지도 이 방식으로 만들어져 있다.
국내에서는 아래아한글이 워디안 이후 새로운 hwp 포맷이 이 컨테이너를 사용하는 중이다. 몇 년 전에 hwp 파일의 포맷이 부분적으로나마 공개되면서 요 방식도 같이 주목받은 편이었다. 워디안의 개발 당시에 OLECB를 사용하기로 한 것은 21세기에 아래아한글의 향후 행로를 결정한 매우 중대한 결정이었을 것이다.

파일 포맷이란 건 한번 정해지고 그게 대중화돼 버린 뒤에는 마치 전기 전압이나 교통수단의 통행 방향처럼 다른 방식으로 덥석 고치기가 거의 불가능하다. 프로그램의 구조가 아주 간단하고 기능 구현만 빨랑 해야 할 때는 숫자/문자열 몇 개를 덥석 텍스트 형태로 덤프하거나, 구조체가 차지하는 메모리 형태를 파일로 통째로 써 버렸을지 모른다. 하지만 그 파일을 남과 주고받게 되고 프로그램을 지속적으로 발전시켜야 한다면 본격적으로 파일 포맷을 고민해야 하는 날이 온다.

이걸 처음에 신중하게 생각을 안 하면 파일 포맷은 legacy들이 가득한 누더기가 돼 가고, 참다못해 파일 포맷을 다 갈아엎게 되고 그러면서 사용자들로부터 욕도 먹을 것이다. 컴터쟁이 프로그래머로서 파일 포맷은 참 재미있는 주제인 것 같다. 그 어떤 파일 포맷이라도 결국은 튜링 기계가 인식할 수 있는 형식 언어와 문법에 속하는 방식으로 귀착된다는 점 역시 생각할 점이고 말이다.

Posted by 사무엘

2015/06/26 08:35 2015/06/26 08:35
, ,
Response
No Trackback , 3 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1109

실종과 사망의 차이

1.
1993년 가을에 서해훼리(페리) 호 침몰 사고 때의 일이다. 탑승자들을 구조하고 수색하는데 웬일인지 이 배의 최고 책임자인 선장이 행방이 묘연해 보였다. 그런 와중에 일각에서는 "선장이 혼자 살아서 배를 탈출하여 몰래 튀는 게 목격됐다"라는 카더라 루머가 나돌았고, 언론은 이것을 확인도 안 하고 냅다 물어서 동네방네에 소문을 냈다.
이에 경찰조차 별 의심 없이 이 말을 믿게 되었으며 선장을 대문짝만 하게 공개 수배하고 가족들을 압박하여 선장더러 자수를 권유하게 했다.

사용자 삽입 이미지

그러나 결말은? 선장은 수색 닷새 만에 기관장과 함께 배 안에서 시신으로 발견됐다. 서해훼리호의 선장은 세월호의 선장 같은 급의 인간말종은 아니었던 것이다.
이제 예전의 선장 생존 보도는 국내 언론 역사에 길이 남을 오보 흑역사로 전락했다. 그리고 그 기자들은 선장의 유가족을 찾아와서 싹싹 빌었다. 범죄자를 숨겨 주고 있다는 누명을 이제야 벗은 유가족들은 "당신들이 선장이 살아 있다고 말했으니 이제 그 선장을 살려내 보시오"라고 그들을 꾸짖었다.

2.
1996년 가을, 강릉 무장공비 침투 사건 때에는 싸리비를 만들기 위해 싸리나무를 벌목하러 혼자 나갔던 표 종욱 일병이 덜컥 실종됐다. 군에서는 제대로 수색도 안 하고 이걸 전시 무단 탈영으로 단정짓고 탈영병을 찾는다는 방송을 전국에 내보냈다. 그의 집엔 헌병대 사람들이 와서 표 일병 내놓으라고 마치 사채업자가 빚독촉 하듯이 수시로 온갖 민폐를 끼쳤다.

그러나 이 역시 결말은? 그는 무장공비에게 살해당했음이 나중에 밝혀졌다. 이건 부끄럽게도 군 당국이 스스로 적극적으로 수색해서 찾은 게 아니라, 사살한 무장공비에게서 노획한 '일기'에서 의심스러운 점을 발견하여 그걸 토대로 추적한 덕분에 찾은 것이었다. 그 무장공비는 위장을 위해 표 일병에게서 국군 군복을 빼앗은 상태였으며, 그 대신 표 일병은 시신 발견 당시 속옷 바람이었다.

상황이 이렇게 되자 헌병대 관계자들은 표 일병의 유가족 앞에서 그야말로 석고대죄하고 손이 발이 되도록 빌었다. 생사도 알 수 없는 치욕스러운 탈영병과, 현충원에 묻히는 영예로운 전사자는 그야말로 한 끗발 차이에 지나지 않았다. (더구나 전시 탈영은 평시 탈영보다 처벌이 훨씬 더 무겁다!)

무장공비는 그를 결박하고 목을 졸라서 살해했다. 총은 시끄러운 데다 걔네들 입장에선 안 그래도 총알 한 알이 극도로 아까운 지경일 텐데 당연히 총을 썼을 리는 없다.
또한, 생지옥 북한에서 태어나서 거기서 혹독한 훈련을 받으며 남파 간첩이나 무장공비까지 됐을 사람이라면 목표를 위해서는 수단과 방법을 가리지 않고 인간성이라고는 그야말로 완전히 제거된 인간 흉기나 마찬가지였을 것이다. 잠수함을 좌초시키고 비밀 작전에 실패했다고 동지들끼리도 무자비하게 처형을 했는데, 하물며 자신을 발견해 버린 민간인도 아니고 적군을 살려 둘 이유는 전혀 없었을 것이다. 생포해서 인질극 협상을 벌일 수 있는 처지도 아니고.

기록을 찾아 보니 표 일병은 군 복무 당시 계급이 이미 일병이었다.
“이제 일병을 달고 군생활에도 적응이 되었지만 원인모를 한숨과 동경이 계속되고 있다. 언제까지 이 신세타령을 해야 하는지 내자신도 한심하다.” (고인의 일기 중)

그럼 전사자니까 이제 공식 매체에서는 '표 상병'이라고 불러야 하지 않겠는가? 제설을 하다가 사고로 죽어도 작전 중 순직이기 때문에 1계급 특진 추서인데.
탈영 중으로 잘못 알려졌을 때의 계급이 너무 깊게 인식돼 버려서 그런 것 같다. 이런 점에서 거짓 선동이라든가 오보의 해악은 더욱 큰 셈이다. 한번 생긴 사람의 편견은 쉽게 고쳐지지 않으니까.

* 그러게 사람이 없어진 듯이 보이면 덮어놓고 악한 추측부터 좀 하지 말았으면 좋겠다.
하긴 출애굽기 32장의 금송아지 사건도 따지고 보면 그런 심성을 바탕으로 벌어졌다. 이때 모세는 시신이 발견된 게 아니라 멀쩡히 살아 돌아오기도 했고 말이다.

Posted by 사무엘

2015/06/24 08:30 2015/06/24 08:30
,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1108

대단한 '프란시스' 부자

1.
"프란시스" 쉐퍼(섀퍼) (1912-1984)는 유명한 복음주의 기독교 신학자, 철학자, 장로교 목사이며 국내에서도 <그러면 우리는 어떻게 살 것인가> 같은 영성 쪽의 여러 유익한 신앙 서적들을 통해 잘 알려져 있다.

사용자 삽입 이미지

저 책의 제목인 How should we then live는 성경에서 겔 33:10의 표현을 딴 것이다.
출판 시기는 1976년이다. 정치적으로는 냉전, 공산당 혁명과 월남전, 그리고 과학 기술 분야로는 초음속기와 우주선, 대중 문화로는 비틀즈와 락 음악 같은 그야말로 격변의 시기에 말 그대로 어떤 가치관을 갖고 사는 것이 바람직한지에 대한 의문을 던지면서 그 해답을 성경적 세계관에서 찾았다.

물론 현대만 다루는 게 아니다. 부제가 The Rise and Decline of Western Thought and Culture이니만큼, 로마 제국, 중세, 종교 개혁, 산업 혁명 등을 모두 다루면서 서양사를 전반적으로 고찰했다.
그렇게 살펴봤는데 역시 사회의 문제는 절대적인 진리를 거부하고 절대적인 선과 악이 없다고 주장하는 상대주의에서 유래되곤 했다. 그 결과 무정부주의가 나오고, 이로부터 야기된 혼돈을 바로잡으려고 또 다른 극단인 피의 독재자가 등장하여 학정을 하곤 했다.

영국의 명예 혁명과 미국의 독립 혁명에 비해, 프랑스의 혁명과 러시아의 혁명은 좋지 못한 결말로 끝났다. 공산당식 혁명은 언제나 끔찍한 피의 비극과 독재 학정으로 마무리 되곤 했다.
하지만 반공 우파스러운 주장만 있는 게 아니다. 다른 나라들에 비해 그나마 성경적인 가치관이 심어져 있던 영국도 산업 혁명 이후에 부의 제대로 된 분배에 교회가 제 역할을 못 해서 공산주의가 등장할 빌미를 줬다. 미국은 크리스천들이 흑인 노예의 인권에 소홀하여 오점을 남겼다고도 글쓴이는 지적한다.
또한, 저런 정치 해석뿐만이 아니라 미술사· 음악사 얘기도 나온다.

방대한 책을 다 읽을 시간이 없는 사람들을 위해, 쉐퍼의 책은 그 이듬해에 10부작 다큐멘터리 영화로도 출시되었다.
바로 그의 아들인 프랭크(혹은 Y가 붙어서 프랭키) 쉐퍼 (1952-)가 영화 감독, 시나리오 작가, 연설가였으며, 20대 중반의 나이로 자기 아버지가 자기 저서에 대한 나레이션을 하는 영화를 만든 것이다. 나름 굉장히 잘 만들었다. 제5편 혁명의 시대 때는 시도 때도 없이 단두대가 내려오는 장면이 나온다. ㅎㅎ

이 영화는 현재 유튜브에서 바로 검색해서 볼 수 있다. 다만, 한국어 자막이 없기 때문에 유튜브의 혜택을 볼 수 있는 사람이 그리 많지는 않을 것 같다.

2.
"프란시스" 메크너(1932-)는 심리학자이다. 위키백과를 보면 1960년대부터 이미 학계에서 날고 기었던 것으로 소개된다.
그런데 그의 아들이 바로 조던 메크너 (1964-)로.. 비디오 게임 개발자, 시나리오 작가, 영화 감독이다. 프란시스 쉐퍼의 아들과 비교했을 때 영화학도라는 공통점이 있는데, 물론 메크너 쪽은 종교 쪽으로는 안 가고 게임업계로 갔다. 그리고 조던 메크너는 그 이름도 유명한 "페르시아의 왕자" 게임을 20대 중반의 나이 때 만들어 냈다.

그 게임 특유의 던전 구조와 메카닉, 왕자의 움직임 같은 것이야 그 옛날에 조던의 머리에서 나온 천재적인 발상이다. 그리고 코딩 역시 그 사람이 애플 II 어셈블리 언어를 독학하여 직접 했다. 하지만 전반적으로 볼 때 <페르시아의 왕자>는 가족의 도움으로 만들어졌다.
모션을 촬영할 때 연기는 남동생을 시켜서 이리저리 굴리며 했고, 무엇보다도 게임의 음악은 심리학자인 저 아버지가 전부 작곡해 줬기 때문이다. 빰 빠빠빰 빰빰 하는 그 음악을 말이다.

사용자 삽입 이미지

게임을 그저 죄악시 금기시하는 우리나라 풍토와 비교했을 때, 그것도 1980년대에 조던 메크너의 집안이 시대를 얼마나 앞선 천재 집안이었는지를 짐작할 수 있다. 게임을 하는 정도가 아니라 그런 게임을 만들어 냈다. 그것도 본인과 본인의 아버지, 동생이 힘을 합쳐서 말이다.

쉐퍼든 메크너든, 위키백과에 대대로 이름이 등재돼 있는 '프란시스' 부자들엔 이렇듯 굉장히 의미심장한 패턴이 있다.

Posted by 사무엘

2015/06/18 19:25 2015/06/18 19:25
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1106

* 평소에 내가 좀체 다루지 않던 경제 쪽 주제에 대해서 오랜만에 글을 써 본다.
그래서, 뒷부분에 성경 얘기가 많이 나오지만 분류도 기독교 쪽이 아닌 그냥 보통명사로 했다.

세상의 모든 물건들은 담보로 맡기는 게 아닌 이상, 그 자체만을 남에게 안심하고 맡기려면 맡아 주는 사람에게 보관료를 내야 한다. 교통수단을 세워 둘 때 드는 주차료· 주기료 같은 건 말할 것도 없고, 아기나 애완동물을 맡길 때도 말이다. 이게 세상의 보편적인 이치이다.

하지만 유일한 예외가 있으니, 바로 돈 그 자체이다. 돈을 맡기면 맡은 사람이 오히려 반대로 맡긴 사람에게 주기적으로 돈을 준다. 그렇게 주어지는 돈을 우리는 이자라고 부른다. 생각을 해 보시라. 돈을 안전하게 보관하기 위해서는 맡는 쪽에서 막대한 경비 비용을 부담해야 하는데도 불구하고 그래도 맡은 사람이 맡긴 사람에게 돈을 준다.

이 원리를 이해하는 게 자본주의 원칙과 경제 원리를 이해하는 첫걸음임이 틀림없다. “세상에 공짜란 없다” 다음으로 초등학교에서 가르칠 법한 제2의 핵심 원리이다.

그리고 은행들 역시 예금을 곱게 꿍쳐 놓고만 있지 않는다. 대부분의 돈을 다른 데에 투자하거나 대출을 줘서 돈을 불리는 일을 한다. 그러니 모든 예금자가 불시에 자신의 예금을 전부 인출하려 들면 은행은 못 버틴다.
이런 점에서 성경의 달란트/므나 비유에 나오는 게으르고 악한 종은 선악을 따지기에 앞서 정말 최소한의 경제 관념조차 없던 멍청한 친구였다. (마 25:27, 눅 19:23)

지금이야 우리나라가 먹고 살 만하니까 쏙 들어갔지만, 옛날에는 나라에서 국민들 보고 그렇게도 저축을 많이 하라고 홍보하고 과소비 추방하자고 캠페인을 벌였던 게.. 단순히 근검절약(?) 정신을 함양하고 외화 유출을 방지하려는 차원이 아니었다. 그건 부수적인 효과다.
저축을 많이 함으로써 은행이 돈을 많이 보유하게 하고, 이로써 초기 자본이 많이 드는 기업에다 투자를 많이 하게 하려는 의도였다.

무슨 유머 중에, 학교에서 "지금 손에 100만 달러가 생기면 무엇을 하겠는가?"를 상상해서 작문을 시키는 시간이 있었는데 어떤 애는 그냥 가만히 있었다는 이야기가 전해진다. 교사가 이상하게 여겨서 "세계일주를 한다, 여자를 꼬신다" 등 왜 뭐라도 안 쓰냐고 물었더니 아이 왈, "네, 저는 100만 달러가 있으면 저는 아무것도 안 하고 가만히 있을 거예요(모든 걸 남에게 시키고)" 이랬다는데..
그 애도 알고 보면 굉장히 천진난만 순진한 타입이다.
자본주의 사회의 법칙을 일찌감치 깨달은 영악한 애라면, 그 돈으로 지금 당장 흥청망청 유흥을 즐기는 게 아니라, 어딜 투자를 하든지 해서 100만 달러를 1000만 달러 이상으로 불릴 궁리를 할 것이다.

그리고 혼자만 살 때는 돈 욕심 없이 자급자족으로 만족할 것처럼 지내던 사람이라도 처자식이 생기고 나면 어지간해서는 생각이 달라진다. 나는 상관없지만 내 자식에게 남들만치 밥 사주고 용돈 주고 비싼 학교에 옷 등등을 차려 주지 못한다면..? 그때부터는 어쩔 수 없이 돈독 오르게 된다. 그게 현실이다.

자 그럼, 돈으로 돈을 버는 것에 대해 성경은 뭐라 말할까?
일단 구약 율법에서 내가 느끼는 뉘앙스는.. 정말 천하의 개쌍놈 급의 절대 하지 말아야 할 몹쓸 짓까지는 아니지만, 어지간해서는 그러지 마라. “이방인들을 상대로라면 몰라도 동족간에는 최대한 아량을 베풀어라. 이자 따지지 말고, 못 돌려받을 걸 감수하고라도 관대하게 꿔 줘라. 손해분은 내가 친히 갚아 주겠다” 정도인 것 같다.

이건 십일조만큼이나 “신정국가+유대 민족의 믿음 테스트+이 땅에서의 복” 문맥이다. 그러니 신약 시대엔 자선행위 차원에서, 혹은 교회 지체들끼리 적용 가능한 가이드라인이 될지 몰라도, 굳이 이방인 세상 정부에서 행정법 수준의 강제 사항이 될 필요는 없을 것이다. 오히려 달란트/므나 비유에서 “하다못해 이자라도 받아 왔어야지?” 같은 주인의 책망이 있는 걸 보면, 성경도 돈 자체가 악이라고 말하지 않는 것만큼이나 돈으로 돈을 버는 것 자체가 악이라고는 안 하는 듯하다.

성경은 명백히 사유재산과 free market, 빈부격차를 인정한다. 사실, 돈으로 돈을 불리는 것도 아예 불가능하다면 투자라는 게 생길 수 없고 경제가 성장할 수가 없어진다. 절대적인 빈부격차 자체는 더 커질지 몰라도, 그래도 입에 풀칠도 못 하던 가난뱅이를 중산층으로, 그리고 지금 부자는 훨씬 더 큰 부자로 만드는 게 낫지 않은가?

부자가 가진 돈이 고용과 일자리를 더 만드는 발전적인 쪽에도 부분적이나마 쓰이는 게 더 나은가, 아니면 걍 오로지 부자들의 유흥과 사치에만 돈이 쓰이는 게 더 나은가? 이런 관점에서 봐야 한다. (“부자들 돈을 강제로 뺏어서 분배해야 된다” 이건 영락없이 빨갱이 생각이 되는 거고.)

또한 생각해 볼 점은, 성경에는 이자에 대해서 정확한 가이드라인도 안 나온다는 점이다. 하나님이 인정하는 금리나 사채 이율 한도는 최대 몇 %이고 그 이상은 악.. 뭐 그딴 얘기는 없다. 음악이나 옷차림에 대해서도 추상적인 원칙만 있을 뿐 디테일한 적용 방법은 안 나오는 것과 마찬가지 맥락이다.

그 숫자놀음이 얼마인지는 중요하지 않으며, 그게 얼마이든 전혀 무관하게 인간의 불완전한 경제 제도가 인간의 죄성과 맞물리면 문제와 폐단이 생길 수밖에 없기 때문일 것이다.
“서로 사랑하는 것 외에는 누구에게든지 어떤 것도 빚지지 말라”, “돈을 사랑함이 모든 악의 뿌리”, “급히 부자가 되려 하는 자는 악한 눈을 가졌으므로...”, “탐욕은 우상 숭배”처럼 인간의 자유의지와 사유재산은 존중하되, 경제와 관련된 인간의 죄악을 제어하는 말씀은 성경에 이미 충분히 있다.

그런데 이게 자발적으로 이행되지 않고, 각 개인의 이기적인 행동이 집단 전체의 이익이 아니라 공멸로 가는 경우도 있으니, 비효율적인 줄 뻔히 알면서도 정부가 시장에 개입해서 최저임금이니 무슨 비율이니 하는 걸 강제로 정하고 복지라는 명목으로 세금을 꽤 많이 걷어 가는 일도 생기는 걸로 보인다. 참 절대적인 답이 없는 문제 같다.

NOTES:

1. 은행이 불안하다 싶으면 개인 예금주들은 전부 몰려와서 자기 돈을 빼려고 몰려올 것이고, 이러면 아까 말했듯이 그 어떤 은행도 버티지 못한다. 은행은 그런 상황을 감안하고 운영되는 기관이 아니다.
하지만 각 개인이 자기 예금을 전부 인출하려는 행위 자체는 법적으로 하나도 전혀 문제될 게 없는 행동이다. 마치 기업이 생존을 위해 구조 조정을 하고 경쟁력 없는 기업은 시장에서 도태하는 것만큼이나, 그리고 전쟁터에서 군인이 무장한 다른 적군(포로나 항복한 군인, 민간인이 아니라)을 죽이는 것만큼이나 합법이다.

2. 흔히 "올림픽 메달리스트 운동 선수의 자녀가 또 올림픽 금메달리스트가 될 확률하고, 재벌의 자녀가 계속 재벌로 있을 확률이 동일한 사회가 좋은 사회이다" 이런 말이 나도는 듯하다. 무슨 취지로 하는 말인지는 이해하겠으나 거기에 마냥 100% 공감할 수는 없다. 재능과 재화는 근본적으로 동일한 자산이 아니기 때문이다.

세상에서는 돈을 많이 가진 사람, 소득이 높은 사람에게 절대적인 액수로나 혹은 비율로나 어쨌든 더 많은 액수의 세금을 매긴다.
그러나 시험 쳐서 100점 맞고 올림픽 같은 대회에서 1등을 하는 등, 재능이 뛰어난 사람에게 재능이 뛰어난 것 그 자체만으로 세금을 부과하지는 않는다. 그랬다가는 재능의 발휘에 도무지 동기 부여가 되겠는가? 세금을 부과하더라도 그건 상금에서 세금을 일부 공제하는 형태일 뿐이다.

굳이 돈이 아니라 소위 '열정페이, 재능기부' 같은 것도 철저하게 당사자가 자발적으로 하는 것이지, 그것이 세금을 걷는 것처럼 법적으로 강제되지는 않는다. 이것이 재능과 재화의 차이인 것이다.
부모가 똑똑해서 자녀를 좀 더 편하게 살게 해 주려고 재산을 많이 물려 주는 것 자체가 죄악이라 할 수 있을까? 내 자녀였으면 그러고 싶은 생각이 들지 않겠는가?

물론 자녀가 인격도 의사결정권도 일체 없이 부모의 소유물과 다를 바 없이 취급하는 생각은 잘못되었지만, 그렇다고 부모와 자녀는 법적으로 아무 상관도 없는 완전히 다른 사람이니 부모의 재산은 한 푼도 안 남기고 몽땅, 마치 무연고 사망자의 재산마냥 국고로 환수해 버린다면 그것도 올바른 처사이겠느냐 말이다.

또한 부모가 재벌이라고 해서 그 자녀 세대까지 재벌인 게 마냥 100% 보장되는 것도 아니다. 기업은 치열한 세계 시장에서 언제 도태될 지 모르니, 경영진은 수많은 종업원들에게 꼬박꼬박 월급을 주기 위해 맨날 이대로는 안 된다며 위기 드립을 치고, 때로는 좀 더러운 짓도 하고 여론 관리도 하고, 미래에 뜨는 아이템을 예측하고 사업 방향을 구상해야 한다. 재벌이 유지될 확률이 대대로 올림픽 메달리스트가 나올 확률과 그렇게까지 크게 차이가 나지는 않을 수도 있다는 뜻이다.

문제를 이런 관점에서 볼 수도 있어야 한다. 나야 일개 학생 겸 월급쟁이일 뿐이고 무슨 대기업 재벌 재계 인사하고는 하등 아무 관계도 없는 처지이지만, 나중에 내가 무슨 있는 돈 없는 돈 꼬라박아서 사업을 해서 종업원을 고용하는 처지가 되는 상황을 상상해 보면, 지금 사회 구조가 마냥 근로자만이 약자이고 모든 기업주가 그저 갑질을 일삼는 악당이라고 여겨지지는 않는다.

3. 난 지금까지 정치관이나 역사관 관점에서 우리나라 체제를 방어하는 글을 쓰는 편이었다.
하지만 알고 보면 우리나라의 경제관을 부정하는 불순세력의 공격도 많다. 자기들도 입고 있는 큰 혜택에 대해서는 입 싹 씻고 작은 부작용과 폐해만 자꾸 부각시키면서 우리나라를 점점 사회주의 공산주의 체계로 바꾸려고 하는 시도들.

여기에 대해서도 이론적으로 조금씩 공부하고 무장을 해야 할 필요를 느낀다. 난 인간의 이기심과 욕심을 있는 그대로 인정하면서 그나마 그걸 모두가 잘살고 파이의 크기를 키우는 쪽으로 유도하는 경제 체제를 지지한다. 인간을 감히 성선설적으로 보면서 불가능한 것을 가능하다고 선동하는 속임수에 속지 않는다. 기업이 노동자를 착취하는 세상은 국가가 개인을 착취하는 세상에 비해서는 비교할 수 없이 훨씬 더 천국이다.

Posted by 사무엘

2015/05/22 08:34 2015/05/22 08:34
, , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1096

서해대교 29중 추돌 참사

우리나라는 서해를 건너는 두 개의 대형 교량 위에서 안개가 자욱하게 낀 날에 초대형 연쇄 추돌 교통사고를 한 건씩 경험하게 됐다. (2006. 10. 서해, 2015. 2. 영종)

두 다리는 각각 2000년 11월 10일과 20일에 개통해서 개통 시기도 참 묘하게 비슷하다. 딱 그 중간인 11월 14일이 2001학년도 수능 전날인 동시에 비둘기호 열차가 마지막 운행을 마친 날이긴 했는데, 그건 일단 이 글에서는 논외로 하고.

서해대교에 대해서 좀 더 자세히 서술하자면, 이 다리는 내게 소설 <상록수>와 소설가 심 훈을 떠올리게 한다. 일제 강점기 때는 서해대교와 서해안 고속도로가 없었으니, 당진에서 안산 샘골을 찾아갈 때 저 작가가 훨씬 더 고생을 해야 했을 것이다.
그 반면, 오늘날은 교통이 참 편리해졌다.

2006년 개천절은 북한이 핵실험 예고 선언을 했으며, 반 기문 씨가 유엔 사무총장 후보로 출마하네 마네 하던 날이었다.
그랬는데 그 날 아침, 짙은 안개 속에서 대형 트럭이 앞서가던 1톤 트럭을 추돌했으며, 최초 사고 유발 차량들이 차를 갓길로 안 빼고 우왕좌왕 하는 사이에 뒤따라 오던 차들이 연쇄적으로 앞 차를 들이받았다.

영종대교 때와는 달리 서해대교 사고에서는 차에서 화재가 발생하는 바람에 사고 현장은 정말 헬게이트로 바뀌고 피해 규모가 더욱 커졌다. 공장에서 갓 출고된 새 승용차 여러 대를 싣고 가던 트레일러에도 불이 옮겨 붙었다. 그래서 거기 실려 있던 승용차들은 미처 팔려 나가기도 전에 깡그리 잿더미가 됐다.

사용자 삽입 이미지

하지만 물적 손실보다 더 심각한 건 인명 피해이다. 초기에는 사망자가 총 11명이라고 집계되었지만 전신에 중화상을 입고 치료를 받던 남성 1명이 치료 3개월 만에 결국 사망하면서 사망자는 최종적으로 12명으로 늘었다. 현장에서 혹은 구조된 후에 사망한 사람이 7명, 스스로 대피하던 도중에 2차 사고를 당해 사망한 사람이 5명이었다고 한다.

다른 차량에서는 보통 1대당 운전자 1명꼴로 사망자가 나왔지만, 유일하게 탑승자 일가족 3인이 전원 사망한 차량이 있었다. 이건 대형 차량들 사이에 끼여서 처참하게 으스러지고 완전히 박살이 난 소형 승용차였다. 그 상태로 불까지 붙어 활활 탔으니 탑승자는 도저히 살아 있을 수가 없었을 것이다.

바로 저 차에서 운전자의 아내와 아들은 현장에서 즉사했으며, 당사자만이 목숨만 겨우 건졌지만 나중에는 그도 사망했다. 화상이 워낙 심각한 상태였기 때문에 더 손을 쓸 수가 없었다. 고인은 마지막 순간까지 아내와 아들도 역시 생존해서 자신과는 다른 병원에서 치료를 받고 있을 거라고 생각했다고 하니 참으로 안타까운 일이 아닐 수 없다.

2차 사고의 희생자 중에서도 기가 막힌 경우가 있다. 바로, 차량과 다리 난간 방호벽 사이에 끼인 채로 탈출을 못 하고 그대로 화마에 휩쓸린 사망자가 2명이나 있었기 때문이다.
당시 사고 현장 사진을 보니, 벽이 딱 그 지점만 사람 모양으로 검게 그을려 있어서 더욱 섬뜩하게 느껴진다.

이 사람들은 사고 직후에 현장에서 즉사나 기절을 한 게 아니라, 제 발로 대피하던 중에 변을 당했다.
그냥 사고 현장 주변만 배회하고 있었을 뿐인데 뒤에서 오는 차들로 인해 추가 추돌 사고가 나면서 근처의 차들이 앞으로 밀려나고, 이 때문에 정말 운이 나쁘게도 방호벽과 차량 사이에 몸이 끼인 것이다.

사용자 삽입 이미지

서해대교 사고에 대해서는 2007년에 KBS 스페셜에서 사건을 CG로 잘 재현하고 분석한 다큐멘터리가 있어서 그게 유튜브와 각종 동영상 포털 사이트에서 나돌고 있다. 이 글에서 언급한 사망자 관련 정보의 출처도 여기이다. 대형차에 끼여서 사망한 3명(빨강), 그리고 트럭과 방호벽 사이에 끼인 채 사망한 2명(파랑)을 모두 확인 가능하다.

이런 사고 장면을 보면, 안개, 특히 해무는 살얼음 빙판 이상으로 위험한 존재이고 한 치 앞이 안 보일 정도로 안개가 너무 짙을 때는 애초에 고속도로 같은 데에 차를 끌고 나가지 말아야겠다는 생각을 하게 된다. 비록 그렇게 하기가 말처럼 쉽지는 않겠지만.

그리고 저런 데서 사고가 났다면.. 니가 10% 더 잘못했네 마네 같은 거 안 따져도 좋으니, 차량이 아직 운행 가능한 상태라면 걍 닥치고 차부터 가장자리로 빼야겠다 싶다. 100미터, 200미터 뒤로 거슬러 가서 삼각대를 놓고 올 배짱 같은 게 없다면 말이다. 또한, 초기의 단순 접촉/추돌 사고 정도라면 차가 운행 불가능한 상태가 되지는 않았을 테니까.

서해대교와 영종대교에서 9년 간격으로 사고가 한 번씩 났는데, 다음에는 이들보다 훨씬 더 긴 다리인 인천대교에서 시즌 3이 발생하지 않기를 간절히 바랄 뿐이다.

Posted by 사무엘

2015/05/13 08:28 2015/05/13 08:28
, , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1093

익사 사고 관련 정보

물에 빠져 죽는 건 비록 당장 눈에 띄는 상처나 핏자국 같은 건 없지만, 폐에 물이 찬 채로 숨을 못 쉬면서 굉장히 고통스럽게 죽는 죽음이다. 질식사의 일종이다.
허나, 여름에 강과 바다로 놀러 갔다가 거기서 살아서 못 돌아온 불운한 사람이 매년 전국에 수십~백수십 명가량은 된다.

익사 사고에 대해서 우리가 주의해야 하는 점이 몇 가지 있다.
먼저, (1) 물에 빠져서 허우적대는 사람은 주위를 향해 자기를 구해 달라는 티를 적극적으로 못 낸다는 것이다.
무슨 "불이야!" / "도둑이야!" 외치듯이, 혹은 육지에서 강도에게 쫓기는 것처럼 우렁차게 "사람살려!" 소리를 지르며 구조요청을 할 수가 없다.

익수자는 숨 차고 힘들어 죽을 것 같은 상태이다. 입을 조금이라도 벌렸다가는 물이 당장 입으로 흘러들어올 판이고, 말을 하면서 숨을 내뱉었다가는 몸의 밀도가 올라가 물 속으로 더욱 가라앉을 게 뻔한데 어떻게 그런 소리를 지를 수 있겠는가? 절대 불가능하다. 기껏해야 '헉~ 헉~ 꺼억' 같은 죽는 신음 소리밖에 못 내다가 조용히 꼬로록 가라앉고 익사할 뿐이다. 당연히 멀리서 들릴 리가 없고. 물에 빠져 죽어 가는 건, 물리적인 양상만 다를 뿐 차라리 목이 밧줄로 졸리고 있는 상황과 비슷하다고 봐야 한다.

그러니 물에 들어간 채로 뭔가 큰 소리로 외칠 여유가 있다는 건 그 자체가 이미 얼굴이 당장 물에 잠길 위험은 없으며 따라서 생명에도 사실상 지장이 없음을 의미한다. 이 정도면 드라마, 영화가 현실과는 다른 왜곡 중 하나에 해당되겠다. 마치 유언 장면처럼 말이다. (현실에서의 죽음, 특히 병사는 절대로 그렇게 낭만적이지 않다.)

현실에서 물에 빠져서 생명의 위협을 느끼고 허우적거리는 사람이, 그저 평범하게 수영을 하거나 물장난만 치는 사람과 다른 점은 대체로 다음과 같다. (위가 아니라 아래와 더 비슷하다는 뜻) 해수욕장에 비치된 안전 요원들은 멀리서 수면을 관찰하다가 "아, 저 사람이 지금 위급한 상황이구나"를 먼저 분간하는 훈련을 받는다. 즉, 청각이 아니라 시각을 이용한다.

사용자 삽입 이미지

  • 물이 입까지 간당간당 차 있으며 고개는 뒤로 젖혀져 있다.
  • 정상적인 수영을 하는 상태가 아니므로 물에서도 다리를 아래로 하고 꼿꼿하게 수직으로 서 있다. 물론 물 밖에서 익수자의 다리를 보기는 어렵겠지만, 물에 빠진 사람은 뭔가 "사다리"를 잡고 오르려는 듯한 손짓을 필사적으로 하므로 손을 봐도 된다.
  • 해수욕장에서 물에 빠진 사람이 시선을 해변이 아닌 심해 쪽으로 향하고 있을 리는 없다. 땅 또는 더 얕은 곳을 향하여 필사적으로 이동하려는 듯하지만 나아가질 못한다.
  • 앞머리가 이마나 눈을 가리고 있지만 수습을 못 한다. 힘이 더 빠지면 눈에 초점이 없거나 아예 눈을 감고 있다.

수영을 할 줄 모르고 물에 뜨지 못하는데 발이 바닥에 닿지를 않는다면 익수자는 얼마나 놀랄까? 그야말로 패닉에 빠진다. 그리고 소중한 친구나 가족, 친지가 물에 빠졌다는 걸 알게 되면 주변 사람들도 덩달아 만만찮게 패닉에 빠진다.
그런데 여기서 절대 유의해야 할 점이 하나 더 추가된다. (2) 자기가 수영깨나 할 줄 안다고 해서 섣불리 맨몸으로 구조하러 나서서는 안 된다. 최대한 침착해야 한다.

물 속에서 생명의 위협을 느낀 익수자는 최후의 발악을 하는 과정에서 힘이 평소보다 훨씬 더 세어지며, 구조자가 다가가면 튜브마냥 다짜고짜 붙잡고 매달린다. 익수자가 물귀신처럼 되는 셈. 이러다 일이 틀어지면 둘 다 물에 나란히 가라앉아서 익사하고 만다.
구조자의 입장에서는 하다못해 익수자가 물 좀 먹고 힘 빠져서 축 늘어진 뒤에 나서는 게 더 안전할 정도이다.

사람이 따로 나서는 게 아니라, 고정된 물건과 밧줄로 연결된 도구를 던져 주는 게 일단은 제일 좋다. 불가피하게 구조자가 직접 물에 뛰어들더라도 그런 것과 몸을 줄로 연결한 상태로 나서는 게 안전하다. 디즈니 포카혼타스에서도 초반부에 토머스가 배에서 떨어져 바닷물에 빠졌을 때, 존 스미스는 그렇게 자기를 배와 밧줄로 연결하고 나서 물에 뛰어들었다. 물놀이를 갈 때 긴 밧줄이 굉장히 요긴하게 쓰일 것 같다.

결국 사람을 물에서 구하는 건 감전된 사람을 구하는 것과도 비슷해 보인다. 어지간히 심하게 감전된 사람은 신경이 마비되어 자기 힘으로 사지를 전원으로부터 떼어낼 수가 없게 된다. 그런데 주변 사람이 어설프게 나섰다가는 구조자까지 같이 감전되기 쉬우니, 부도체 도구를 최대한 사용해서 구출해야 한다.

익사 사고는 더운 여름에 많이 발생하지만, 겨울에도 얼음 낚시 같은 걸 하러 갔는데 약한 살얼음을 잘못 밟는 바람에 물에 빠져서 발생하기도 한다. 이때는 마지막으로 유의해야 하는 점이 있다. (3) 물에서 빠져나온 뒤에 얼음판 위에서 절대로 두 발로 서지 말아야 한다는 것. 발바닥만 한 좁은 면적에 체중이 다 쏠리면, 옆의 얼음도 연달아 깨지기 쉽다. 그래서 기껏 물 밖으로 나왔는데 또 물에 빠지는 최악의 사태가 벌어진다.

그때는 누운 채로 옆으로 데굴데굴 구르면서 체중을 넓은 면적에 최대한 분산하면서 육지로 가야 한다. 옛날에 무슨 서바이벌 가이드 TV 프로에서도 다뤘던 내용이다.

물에 한번 빠져서 곤혹을 치른 적이 있는 사람이라면 부력의 소중함을 체험함과 동시에 비행기나 배를 탈 일이 있을 때 거기에 비치되어 있는 구명조끼도 다시 보게 될 듯하다. 구명조끼는 승객이 입수하더라도 얼굴과 코가 물에 잠기지 않게 정말 최소한의 부력을 만들어 주는 물건이다. 물에 떴다고 해도 구명조끼가 차가운 물로 인한 저체온증까지 예방해 주지는 않으니, 비상 상황에서 수면에 내던져진 승객은 최대한 어서 구조되거나 다른 부유물의 위로 올라가서 전신이 물 밖으로 나갈 수 있어야 한다.

끝으로, 본인이 개인적으로 굉장히 안타깝게 생각하는 익사 사고를 언급하며 글을 맺겠다.
바로 작년(2014) 8월에 경북 청도의 어느 계곡에서 승용차가 통째로 급류에 휩쓸려서 안에 있던 일가족 7명이 모조리 사망한 사고이다. 물놀이 익사는 아니고 일종의 자연재해인 폭우로 인한 사고 되겠다.

자동차가 지나가는 경로와 수직으로 물이 졸졸 흐르고 있었는데 그 날은 물이 불어서 물살이 꽤 강했던 모양이다. 차가 지나가는 게 좀 불안해 보여서 가장인 운전자가 혼자서 시범삼아 차를 몰고는 길을 건넜다가 되돌아와 보기까지 했다고 한다. 그런데 정작 가족들을 다 태우고 다시 건너는 순간 차는 그대로 휩쓸려서 옆으로 떠내려가 버렸다. 뒷차 운전자들이 보는 앞에서 말이다.
차는 2km가 넘게 떠내려 갔고, 탑승자들은 차에서 탈출할 엄두도 못 내고 안에서 모조리 익사했다.

사용자 삽입 이미지

하긴 작년 여름엔 물폭탄 폭우가 쏟아졌던 창원에서 시내버스가 불어난 물에 떠내려 가는 바람에 운전사와 승객이 모두 사망하기도 했다. 이때는 차체를 탈출한 사람들도 여럿 있었지만 그래도 생존하지는 못했으며, 차량보다 더 멀리 떨어진 하류에서 시신이 발견됐다.

이런 강한 흙탕물 앞에서는 아무리 수영 실력이 뛰어나도 아무 소용이 없었겠다..;;
도시에 사는 사람들은 물에 빠지는 것에 대한 대비보다는 당장 심폐소생술이나 소화기 및 제세동기 같은 물건의 사용법을 익혀 놓는 게 비상 응급 상황에서 더 유용히 쓰일 가능성이 높을 것이다.
기왕 이런 얘기가 나온 김에 우리 주변에 있는 그런 것들에 관심을 갖고 살펴보는 것도 나쁘지 않을 듯하다.

Posted by 사무엘

2015/05/01 08:38 2015/05/01 08:38
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1089

※ 컴퓨터 & 프로그래밍

1.
예전에 본인은 시스템 종료 중에라도 사용자가 무슨 동작을 취하면, 컴을 아주 꺼 버리는 시스템 종료가 아니라 그 뒤 '재시작'으로 종료 모드를 바꾸는 기능이 있으면 좋겠다는 제안을 한 적이 있다. 그것과 비슷한 제안인지도 모르겠는데, 또 하나 아이디어를 내자면 이렇다. 사용자가 한동안 컴퓨터를 건드리지 않아서 모니터가 꺼지거나 컴퓨터가 절전· 최대 절전· 종료 등으로 바뀌게 되면, 그 모드로 진입하기 전에 화면에 10초나 5초 정도 카운트다운을 좀 띄웠으면 좋겠다.

프레젠테이션을 할 때처럼 화면을 빤히 보고 있으면서 키보드· 마우스만 안 건드리고 있는데 화면이 갑자기 꺼져 버려서 당황한 적이 여러 번 있었다. 화면 보호기 정도는 카운트다운 없이 바로 진입해도 상관 없겠지만 아예 하드웨어적인 변동이 생기는 저런 모드는 예고가 있으면 좋겠다.

2.
동영상 엔진인 '코덱'과 과거의 컴퓨터 통신 장비인 '모뎀'이 정확히 같은 조어법에 의해 거의 같은 구조의 이니셜을 가진 단어이구나.

3.
식당에서 주문을 한 뒤에야 "아 손님, 죄송하지만 재료가 떨어져서 그 메뉴는 지금 제공이 안 됩니다" 이런 메시지를 받으면 허탈하잖아. 애초에 메뉴판에 그런 메뉴는 disable된 상태로 시각 피드백이 있으면 좋겠다.

4.
공동 작업을 하는 코드의 명칭에 영어 스펠링이 틀린 게 많아서 작업에 지장을 적지 않게 받은 적이 있었다. 검색이 안 되기 때문이다. 이쯤에서 분명 availableItem이런 단어가 있는 걸 봤었는데 나중에 보니 avalible이라고 돼 있는 식.
이건 당장 버그나 성능 같은 동작과 직접적인 관련이 있지는 않지만, 그래도 또 다른 형태의 민폐이다. 도서관으로 치면, 책을 보고 나서는 자기 분류 코드상으로 있어야 할 곳이 아닌 엉뚱한 곳에다 책을 꽂은 것과 같다. "잘못 꽂힌 책은 없는 책과 같습니다. 정리는 사서가 알아서 할 테니까 열람하신 책은 그냥 여기에 놔 두세요" ;;;;

5.
관광 가이드를 매뉴얼과 스케줄 대로 승객들을 안내하는 컴퓨터 프로그램에다가 비유한다면, 이 사람이 수행하는 프로그램의 소스 코드는 정말 그야말로 try ... catch문으로 빽빽이 무장하고 있어야겠구나 하는 생각이 들었다.
누군가가 갑자기 아플 때, 뭔 물건을 놔 두고 왔을 때, 여권을 잃어버렸을 때, 긴급한 사고가 발생했을 때, 일행 중 일부가 없어져서 못 찾을 때 등등.. 그 어떤 예외 상황에서도 패닉과 스케줄 펑크를 최소화하는 방향으로 의연히 대처가 가능해야겠다.

6.
Windows 환경에서 응용 프로그램이 자기 영역으로 사용할 수 있는 메모리 주소는 64KB 이상부터이다. NULL 포인터인 0자체뿐만이 아니라 첫 64KB는 가상 메모리 영역 설계 차원에서 봉인되어 있으며, 이 주소에 메모리를 읽거나 쓰는 건 무조건 에러가 난다. 사실, 0 자체뿐만 아니라 64KB 정도까지는 막혀 있어야 NULL포인터 자체뿐만 아니라 NULL로부터 구조체 멤버를 참조한 포인터도 에러로 처리될 수 있을 것이다. ((POINT *)NULL)->y처럼.

아울러, 과거의 Windows 9x는 이보다 제약이 더 커서 64KB가 아니라 상위 4MB까지가 추가로 막혀 있었다. 64K부터 4M까지의 영역은 16비트 프로그램(도스용 & Windows용 모두)이 사용한다. (☞ 이에 대한 더 자세한 설명)

이런 이유로 인해 전통적으로 32비트 Windows 프로그램들은 시작 주소(preferred base)가 딱 4MB로 맞춰지곤 했다. NT 계열에서는 꼭 4MB가 아니라 64KB 이상 아무 지점이어도 상관이 없지만, 4MB 이상이어야 윈도 9x와 NT계열에서 모두 실행 가능하기 때문이다.

그런데 이건 오늘날까지도 하드디스크가 C로 시작하는 디스크 드라이브 관행과도 정확히 일치하는 것 같다.
플로피 디스크가 완전히 없어졌음에도 불구하고 A, B 드라이브는 사실상 결번으로 남아 있으니 말이다. 요즘은 하다못해 USB 메모리 드라이브를 거기에다 할당해도 될 것 같은데!

※ 알고리즘

7.
longest common subsequence를 구하는 문제와 longest increasing subsequence를 구하는 문제는 서로 관련이 있는 무척 흥미로운 문제인 것 같다.
가만히 생각해 보니, 후자는 임의의 sequence와, 그 입력을 오름차순으로 정렬한 sequence와의 longest common subsequence를 구하는 것과 같다. 그러므로 후자는 전자 문제로 다항 시간 만에 변환 가능한 special case이다.

두 문제는 일단 다이나믹 프로그래밍으로 O(n^2)의 복잡도로 풀 수 있지만, 더 작고 특수한 케이스인 후자는 O(n log n)의 해법도 있다.
전자 문제는 문장의 정확도를 구하는 알고리즘, 소스 코드의 diff 툴 등 활용되는 분야가 굉장히 많다. 지금은 어떤가 모르겠는데 내 때에는 국제 정보 올림피아드의 첫째 날 1번 문제가 해법이 이 형태로 귀착되는 경우도 종종 있었다. 1999년도의 꽃병 문제는 대놓고 저런 타입이었고, 2000년도의 palindrome 문제도 자신과 자신을 역순으로 뒤집은 단어와의 longest common subsequence를 구하는 것과 동일하다.

8.
엑셀에서 파이 모양 차트를 그리면 아이템별로 파랑, 빨강, 주황 등 알록달록한 색깔이 배당되어 차트가 그려진다.
그런데 최초의 색깔인 파랑부터 아이템 N에 이르기까지, 색깔을 선별하는 방식이 과연 무엇일까?
Office 2003까지는 뭔가 보라색 위주의 우중충하고 칙칙한 색깔 위주였는데 2007부터는 그래도 예전보다 훨씬 더 세련되게 바뀌었다.

이건 뭔가 RGB나 hue 같은 색공간에서 최대한 균등하게, 마치 흑에서 백으로 디더링 픽셀을 하나씩 채워 나가듯이 색깔을 뽑아낸 것 같다(관련 링크). 그 구체적인 알고리즘이 궁금하다.
그리고, 이런 픽셀 채우기 문제의 domain을 2차원 평면이 아니라 3차원 공간으로 확장하면 문제의 난이도가 어찌 되는지도 궁금하다.

※ 자동차

9.
자동차 차량 취급 설명서의 각종 선택사양에만 적용되는 설명들은 C/C++ 코드에서 #if #endif 전처리기에 대한 아주 좋은 예시라 여겨진다.

10.
오늘날 "일찍 나는 새가 벌레를 잡는다"보다 훨씬 더 현실적으로 와 닿는 말은 "일찍 움직이는 차가 주차 자리를 차지한다"라고 해도 과언이 아닐 것이다.

※ 기타 미분류

11.
공항 안에 개인 물품 보관함 같은 게 있으면 단독 여행 시에 유용하겠다는 생각이 든다. 이곳과 계절이 크게 다른 지역을 여행 갈 때 지금 입은 옷을 보관해 놓는다거나, 반입 금지 내지 무게 제한에 걸린 물건을 귀국 때까지 임시로 보관할 수 있게 말이다. 물론 후자의 경우는 당사자가 보관함까지 갔다가 돌아오는 게 곤란하니, 추가 비용을 부담해서 보관 대행을 맡길 수 있어야 하겠다.

12.
비행기와 열차의 큰 차이:
열차는 출발 15분 전부터 승강장으로 입장이 가능한 반면, 비행기는 출발 15분 전에 탑승이 종료된다는 것이다.
그리고 여담인데, 내 경험상 인천 공항을 출발한 비행기는 견인차에 끌려 터미널을 떠난 순간부터 활주로에 진입하여 이륙을 시작할 때까지도 거의 정확히 15분이 소요된다.

13.
"바탕체 레귤러"라는 서체 이름을 보고는 바탕체 볼드가 아니라
"바탕체 라지"가 순간적으로 먼저 떠올랐다.
요즘 커피를 너무 많이 마셨나 보다....? =_=;;
하긴, 아메리카노가 생각이 안 나서 순간 "아프리카노요"라고 주문을 했다는 사람 얘기도 있으니..;;

14.
몇 년 전부터 우리나라에서는 우측통행, 도로명 주소 등 일상생활과 직접적인 관계가 있는 여러 규범이 바뀌었으며, 이런 차원에서 단위도 비표준 단위가 통상적으로 쓰이던 곳까지 SI 단위가 강제 추진되었다.
고기의 무게는 오래 전부터 '근'이 거의 전멸하고 100그램 단위로 다 정착을 한 것 같지만 여전히 오락가락하는 곳은 부동산에서 다루는 건물이나 땅의 면적이다.

그런데 내가 보기에도 '1평'을 '3.3제곱미터'로 바꿔서 실생활에서 유리한 게 없다. 부자연스러울 뿐만 아니라 음절수도 너무 많아서 발음하기가 불편하다. 바꿀 거면 사람이 실제로 생각하는 넓이의 덩어리도 1제곱미터나 10제곱미터 단위로 업데이트가 돼야 할 텐데.
참, 그나저나 화면의 크기를 표기할 때 으레 쓰이는 '인치'는 센티미터로 바뀌기라도 했는지 궁금하다. 여기도 평이나 근 만만찮게 좀 이상한 단위가 관습적으로 쓰여 온 곳이니까 말이다.

Posted by 사무엘

2015/04/19 08:36 2015/04/19 08:36
, , , , ,
Response
No Trackback , 7 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1084

오늘은 1980년대 후반~1990년대 초반에 개발되었던 비트맵 그래픽 에디터인 Image72와 Splash!를 소개하겠다.
이들은 닥터할로(원래 이름은 드로잉 할로라고 하는..) 나 딜럭스 페인트 같은 프로그램에 비해 인지도가 이상할 정도로 듣보잡인 것 같다.
진작부터 추억을 회상하는 글을 올리고 싶었으나, 정보가 넘쳐나는 구글과 잡학 지식의 보고인 위키백과를 검색해 봐도 나오는 정보가 너무 없었다.

이름뿐만이 아니라 제작사까지 같이 넣어 줘야 그나마 외국 사이트 위주로 몇 개가 뜨는데, 그래도 자료가 드물다.
국내에서는 운영자가 뭘 하는 어떤 분인지는 모르겠지만 dreamphp라는 사이트에서 그야말로 엄청난 양의 국내외 고전 소프트웨어 소개와 스크린샷 리스트가 있고 거기에 Image72와 Splash!도 나란히 소개돼 있다. 가히 고전 소프웨어 박물관이라고 해도 될 듯. (단, 소개와 스크린샷만 있지 프로그램의 다운로드는 제공 안 함)

본인은 초· 중딩 시절엔 컴퓨터가 256컬러를 표현하는 것만으로도 희열을 느끼곤 했다.
게다가 그래픽 에디터는 여타 분야의 프로그램과는 뭔가 다른 독특한 UI와 포스가 존재해 왔으니 말이다.
그런 프로그램들을 어른이 된 뒤 다시 접하니 마치 이산가족을 상봉한 듯한 느낌이다.

1. Image72

사용자 삽입 이미지

20여 년 전, 본인이 집에서 486 컴퓨터를 처음으로 접했을 때 그때 컴에 기본으로 깔려 있던 프로그램 중 하나였다.
나중에 알고 보니 얘는 메뉴가 없이 그저 검정 배경에 단순한 UI를 제공한다는 점에서는 닥터할로를 닮았다. 그리기 기능은 Windows의 그림판 같은 그저 그런 수준.

표준(?) 버전은 640*480 16색 VGA에서 실행되었다. 단색 버전과 심지어 Image256이라는 256색 SVGA 버전도 있다고는 하지만 그건 난 실물을 못 봤다.
또한, A4tech라는 제작사에 대해서도 현재는 알려진 게 없다. 다른 제품을 더 만든 게 있는지, 혹시 이 프로그램은 DOS 말고 다른 플랫폼 포팅도 됐는지 같은 것들. 단, 검색을 해 보니 미국이 아닌 타이완 국적의 기업이며 저 링크된 회사와 정체성이 동일한 회사가 맞는 것으로 보인다.

인터넷에서 존재감이 완전히 묻혀져 가는 Image72에 대해서 더 많은 정보를 알고 계신 분의 제보를 기다린다.

2. Splash!

사용자 삽입 이미지

얘는 320*200 저해상도에서 256색을 지원한 프로그램이다. 게임 말고 이런 그래픽 모드를 사용하는 프로그램은 드물었다.
개발사는 Spinnaker software. 지금도 있는 회사이긴 하나, 그때로부터 워낙 긴 시간이 흘렀다 보니 Splash!의 개발사와 동일한 곳인지 정확히는 모르겠다. (맞는 것 같긴 하다만)

우리가 놀랄 만한 점은, 이 프로그램은 1988년 12월에 출시되었다는 점이다.
VGA 그래픽 카드가 출시된 게 1987년이다. 그 정도로 까마득한 옛날에 VGA의 256색을 모두 활용하는 거의 초창기 프로그램이었기 때문에 Splash!는 출시 당시엔 굉장한 화제를 모았다. 당대의 컴퓨터 잡지들도 앞다퉈 소개할 정도였다고 한다. 마치 19세기나 20세기 초반에 만들어진 소수의 컬러 사진을 보는 듯한 느낌이다.

다만, 화면 해상도는 그렇다 쳐도 편집할 수 있는 그림의 크기도 화면의 크기를 넘어갈 수 없었던 걸로 기억한다. 그건 좀 아쉬운 점이다.

Splash!를 보니 다음으로, 팔레트 관련 추억을 좀 늘어놓고 글을 맺도록 하겠다.
컴퓨터의 그래픽 모드에서 256색은 2색/16색 같은 저색상도 아니고 하이/트루 같은 고색상도 아닌 딱 중간을 차지하는 독특한 모드이다. 1픽셀의 정보량이 딱 1바이트여서 프로그래밍이 쉬운 한편으로, 팔레트의 중요성이 가장 커진다. 어떤 색들을 선별해서 256개에다가 배당하느냐에 따라 해당 그래픽의 분위기가 싹 달라지곤 했다. 특히 게임들 말이다.

VGA 그래픽 카드가 모드 13h에서 기본 제공하는 256색 팔레트는 다음과 같았다. 기존 16색 이후로는 흑백 32단계와 고채도 원색 그러데이션이 잠시 나온 뒤, 형광/파스텔톤의 색이 3단계 명암으로 나열된다. 저 색깔띠 자체는 예쁘지만, 배색이 게임 같은 그래픽을 표시하는 데는 그리 적절하지 않은 것 같다.

사용자 삽입 이미지

유명한 VGA 팔레트로는 1990년대를 풍미한 명작 그래픽 편집기인 딜럭스 페인트가 제공한 팔레트가 있다. 나름 미술 전문가가 설계했다고 전해지는데 이 정도는 돼야 좀 알록달록 다채로운 색상을 쓸 수 있는 것 같다. 이 팔레트는 그대로 각종 게임들에서 많이 쓰였다.

사용자 삽입 이미지

요즘이야 웹 표준이라고 하면 HTML5를 떠올리지만, 지금으로부터 20년 전쯤만 해도 웹 그래픽에도 256색 디스플레이를 배려하여 web-safe한 표준 색상 규정이 있었다는 걸 기억하시는가?
RGB 각 축당 6단계 명암을 줘서 총 6^3 = 216개 색상이 나오니 그걸 순서대로 배당하고, 나머지 40개 색깔은 호환용이나 흑백 등 다른 용도로 비워 두는 것이다. 공교롭게도 51*n(n은 0이상 5이하, 이상 6단계)을 해 주면 n이 최대값 5일 때 성분값이 딱 255 최대값이 된다.

색깔을 그런 식으로 배당하는 게, 마치 유니코드에서 나눗셈/나머지 연산만으로 한글 자모 정보를 추출하듯이 원하는 RGB대역의 색깔 인덱스를 계산만으로 얻는 데 유리할 것이다.
차라리 VGA의 기본 256색 팔레트도 그렇게 원시적인 방식으로 색을 배당할 법도 한데 나름 파스텔톤 색깔띠를 만든 게 누구 머리에서 나온 발상인지는 잘 모르겠다.
아무튼, 오늘날 그래픽과 디스플레이 기술이 불과 20여 년 전에 비해 얼마나 까마득하게 발전했는지를 실감한다.

Posted by 사무엘

2015/03/24 19:39 2015/03/24 19:39
, , , ,
Response
No Trackback , 8 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1076

이번에 소개하는 세 개의 고전 게임들은 다음과 같은 공통점이 있다.
  • 지금으로부터 무려 30년도 더 전에 만들어진 엄청난 옛날 물건이다. 나이가 본인과 맞먹는다~!
  • 게임기(오락기 포함)이 아닌 PC용이다. 그래서 비주얼이 겨우 4색 CGA로 맞춰져 있는지라 당대의 게임기용 게임들보다는 그래픽이 다소 초라해 보인다.
  • 본인은 옛날에 컴퓨터 학원에서 구경했던 적이 있다. 그런 인연이 있기 때문에 이렇게 내 블로그에다 소개도 하는 것이다.
  • 개인 작품이다.
  • 프로그램은 롬/카트리지 이미지 따위가 아니라 COM 파일 하나로 존재한다. 그래서 도스박스 정도의 에뮬레이터에서 간단히 실행 가능하다.
  • 딱히 이렇다 할 엔딩이 없다. 단지 인간이 도저히 감당할 수 없을 정도로 게임 진행이 점점 더 빨라지고 어려워질 뿐이다.
  • PC용이지만 그래도 여전히 게임기용 게임을 표방하는지, 실행을 종료하는 명령도 없다.
  • 오늘날은 다들 '리메이크' 작품이 나와 있다. 특히 모바일용으로. 게임 목표와 방식은 동일하지만 그래픽과 사운드를 월등히 더 고퀄로 끌어올려서 말이다.

"아~ 이거! 그때 그랬지" 하면서 공감하는 old-timer들이 많이 계시기를 기대하며 글을 시작하겠다.

1. Paratroopers (1982)

우리는 화면 하단 중앙의 포탑의 각도를 좌우 화살표로 조종할 수 있다. 하늘 위로는 헬리콥터들이 수시로 드나드는데 총알을 맞혀서 떨어뜨려야 한다. 총알을 한 발 쏠 때마다 점수를 1 잃지만 목표물을 맞히면 그보다 더 많은 수의 점수를 얻는다. 단, 0점이라도 총알 보급 자체는 무한임.

사용자 삽입 이미지

가끔은 헬리콥터에서 낙하산을 탄 군인이 떨어지는데 얘는 반드시 쏴 죽여야 한다. 좌나 우 한 방향에 군인이 4명이 생기면 이 군인은 포탑 위로 기어 올라와서 포탑을 부수며 이로써 게임이 끝난다.
또한 주기적으로 헬리콥터 대신 제트기가 날아오면서 폭탄을 일직선으로 투하하는데, 이 폭탄도 요격해야 한다. 안 그러면 포탑은 폭탄에 맞아 박살 난다. 폭탄을 요격했을 때의 점수가 가장 높다.

재미있는 것은 사람의 경우 사람 자체가 아니라 낙하산만 맞히는 게 가능하다는 점이다. 그러면 그 사람은 땅바닥으로 운지-_-하는데, 아래에 다른 사람이 있다면 그 사람도 같이 죽는다. 이것이 포탑 아래에 이미 내려간 군인을 제거하는 유일한 방법이다.

나름 아기자기한 요소가 여기저기 담겼고 상당히 재미있는 시간 죽이기용 게임이다.
다만 실제로 게임을 해 보면 조작이 굉장히 불편하다는 게 아쉬운 점이다. 폭탄 요격도 생각보다 잘 안 돼서 첫 제트기 씬 때 죽어 버리는 경우가 허다하다.
포탑이 돌아가는 속도, 총알이 날아가는 속도도 그리 빠른 편이 아니어서 군인들이 좌우로 사정없이 떨어질 때 신속하게 대응하기 어렵다.

이 게임의 개발자는 폴란드계 미국인인 Greg Kuperberg인데.. 이 사람은 1967년생이다. 즉, 저 게임을 중3~고1쯤 되는 나이일 때 어셈블리어를 혼자 뚝딱거리며 만들었다는 뜻이다. 그리고 이 글에서는 소개하지 않지만, 저 사람은 비슷한 시기에 이것과 비슷한 타입의 다른 게임도 여럿 개발한 경력이 있다.

10대 중반의 나이에 엄청난 프로그램을 개발한 괴수야 이 세상에 한둘만 있는 건 아니니, 이것만으로는 그렇게까지 대단한 이야기가 아닐 수 있다. 하지만 저 사람은 좀 더 무서운 가정사와 내력이 있는데, 바로 부모가 모두 영문 위키백과에 등재되어 있을 정도로 저명한 수학자이다. (대학교 수학과 교수) 그리고 저 사람 자신도 나중에 미국의 유수의 명문대에서 박사 학위를 받은 뒤 나중에 수학과 교수가 되었고, 수학은 아니지만 물리학과 교수인 여자와 결혼했다.

이 정도면 우리나라의 홍 성대 씨에 맞먹는 수학 명문 가문이 아닐 수 없다.
수학 덕후가 만든 덕분에 헬리콥터나 대포가 박살날 때 날아가는 파티클들의 모양과 움직임이 상당히 고퀄이었던 건지도 모르겠다. 다시 말하지만 저건 중삐리~고삐리 급 애가 만든 게임이다.

2. Bouncing Babies (1984)

화면의 왼쪽엔 5층짜리 건물이 온통 불길에 휩싸여 있으며, 미처 지상으로 대피를 못 한 어린 아기들이 수시로 창문에서 떨어진다. 그리고 당신은 안전 낙하용 매트를 든 2인조 구급대원이다. 아기는 한번 매트에 떨어지면 오른쪽으로 세 번 통통 튀는데, 이때도 아기를 매트로 받아서 구급차가 있는 데까지 안전하게 보내야 한다. 게임 진행이 하도 엽기적이어서 머리에서 잊혀지지가 않는다. (걍 구급차를 좀 더 건물에 가까이 주차시켜 놓지 그래..?? 같은 건 묻지 말자..ㅋ)

사용자 삽입 이미지

게임의 기술 수준은 그렇게 높지 않다. 건물의 불은 불꽃 애니메이션이 있는 것도 아니고 그냥 무작위로 불 스프라이트를 xor 연산한 것이 나타났다가 사라지기를 주기적으로 반복하는데, 그래도 기술적인 단순함에 비해 불 같은 느낌이 살짝은 난다. 색깔을 나타내는 숫자의 한 비트만을 xor시킨 것으로 보인다.

또한 구급대는 일체의 스프라이트가 존재하지 않으며, 좌우 화살표를 누를 때마다 좌중우 세 위치 중 하나로 곧바로 워프할 뿐이다. 이 정도 게임은 걍 GWBASIC으로도 만들 수 있지 않을까 싶을 정도.

그리고 그런 의심이 더욱 강하게 드는 이유가 뭐냐 하면.. 이 프로그램은 실행 직후에 불, 아기, 구급대 같은 그래픽만 화면에 잠깐 나타났다가 사라지기 때문이다.
도스 시절의 BASIC 프로그래머라면 이건 화면에 그려진 그래픽 내용을 버퍼에다 저장하는 GET 명령을 호출하는 준비 과정과 유사함을 눈치 챌 수 있을 것이다.

난이도가 올라가서, 한 아기가 완전히 구급차로 가기 전에 또 5층에서 아기가 떨어지기 시작하면 구급대는 그야말로 좌우로 축지법을 써야 하게 된다. 옛날 도스용 라이온 킹 게임의 스테이지 중간 보너스 게임으로 있던 Bug Toss와 비슷한 방식이다.

게임 화면에서 고개를 좀 갸웃거리게 하는 것은.. 잔기를 표시한 방식이다.
저 게임에서 미스는 두 말할 나위 없이, 떨어지는 아기를 하나라도 놓쳐서 땅에 떨어뜨리는 것이다. 그런 사고를 낼 때마다 잔기가 하나씩 줄어들며, 모든 잔기가 떨어지면 게임 오버가 된다.

그런데 게임에서는 그 잔기를 아기 모양으로 표시해 놓았다. 아기 모양은 차라리 한 스테이지당 구해야 하는 아기의 수를 나타내고, 스테이지가 진행될수록 그 남은 수가 줄어들게 하는 게 자연스럽지 않을까? 아기 모양으로 "허용되는 미스의 수"를 표기한 건 좀 직관적이지 못해 보인다.

물론 나도 말은 그렇게 했지만 근본적으로 아기를 떨어뜨린다고 해서 저 구급대원이 당장 다치거나 죽는 건 아니기 때문에, 이런 게임 체계에서는 뭔가 다른 대안을 떠올리기도 쉽지 않아 보인다.

뭐, 이런 게임도 있다 싶어서 소개해 보았다.
개발자는 Dave Baskin이라고 알려져 있으나, 동명이인이 많을 뿐만 아니라 직접적으로 이 게임과 프로필이 연결되어 있는 사람을 찾지 못해서 개발자가 지금은 뭘 하고 있는지 알기가 어렵다.

3. Alley Cat (1983)

그리고 그 이름도 유명한 Alley Cat. 얘는 게임 자체와 개발자 모두에 대해서 본인이 이미 심층분석을 한 적이 있기 때문에 이 글에서 또 상세히 다루지는 않겠다.

비슷한 시기에 나온 위의 두 게임과 비교해 보니 Alley Cat이 당시로서는 창의적인 명작 대작이었는지가 실감이 가지 않는가? (비록 Alley Cat은 전적으로 1인 기획은 아니었고, 다른 사람이 만들던 것을 Bill Williams가 물려받은 형태이지만)
다른 게임에 비해 얘는 일단 길거리, 집안, 최종 보스 퀘스트 등 현실 세계과 초현실 세계를 드나들면서 장면 내지 컨텐츠 자체가 엄청 많이 존재한다.

예전 글에도 적혀 있듯, 이 게임의 개발자는 훗날 게임 업계를 은퇴한 뒤 신학을 시작했다. 그러나 유전병을 갖고 있던 게 도져서 30대 후반의 나이로 세상을 떠났다. 생년과 몰년이 pkzip의 개발자인 필립 카츠와 비슷해서 비교된다는 점까지 언급한 바 있다.

* 그나저나 옛날에는 마우스가 없어도 조이스틱은 있었는지.. 그 시절엔 조이스틱을 어느 포트에다 연결해서 어떻게 썼는지 참 궁금해진다.
도스용 고전 게임들 중에서도 조이스틱을 지원 안 하는 물건은 거의 없다시피했기 때문이다.

Posted by 사무엘

2015/03/05 08:31 2015/03/05 08:31
, , ,
Response
No Trackback , 6 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1069

1.
먼 옛날, 윈도 98을 쓰다가 2000으로 갈아탔을 때, 난생 처음으로 Windows NT 계열을 구경하고서 굉장히 놀랐던 기억이 지금도 선하다.

NT 계열은 일단 마의 리소스 퍼센티지 제약이 없었으며, 말로만 듣던 2바이트 문자열 기반의 유니코드 API가 잘 지원되었다. 이 둘은 매우 크게 다가온 아이템이다.
작업 관리자가 9x 계열에 비해서는 넘사벽급으로 잘 만들어져 있었고, 도스창이 아닌 정식 명령 프롬프트가 제공되었다. 이 외에도 EXE/DLL 내부의 리소스를 수정하는 API가 사용 가능한 것도 좋았다. (9x 계열은 16비트 바이너리의 리소스만 고칠 수 있었음)

윈도 95/98에서는 못 보던 파일은 ntoskrnl.exe, csrss.exe, lsass.exe, ntdll.dll, hal.dll, ntvdm.exe, svchost.exe 등이다.
그 반면, 윈도 9x의 잔재이던 파일은 msgsvr32.exe, win386.swp, system.dat, user.dat, winoa386.mod, *.vxd, win.com 같은 것이다.

윈도우 2000/XP부터는 NT 커널 덕분에 주기적으로 재부팅을 할 필요가 없어졌다.
하지만, 주기적으로 재설치도 거의 할 필요가 없어진 건 Vista 이상인 듯하다. XP는 이 범주에까지 넣기에는 좀 2% 부족한 구석이 있었다.

2.
과거에 Windows 9x 시리즈와 Windows NT는 구조적으로 여러 차이가 있었지만, 프로그래머의 관점에서 중요한 특징 중 하나는 '이식성'이었다.
NT는 하드웨어에 종속적인 계층이 철저히 분리되어 설계되었으며 커널이 대부분 어셈블리가 아니라 C/C++이라는 '고급 언어'로 작성되었다. 마치 유닉스처럼. 덕분에 인텔 x86뿐만 아니라 90년대 당시로서는 MIPS, Alpha 등 다양한 아키텍처용 윈도 NT가 나오기도 했다.

NT는 설계 차원에서 특정 하드웨어의 특성에 맞는 '타협'을 별로 안 하고 추상화 계층이 많이 존재하다 보니 깔끔함, 안정성, 범용성 등 많은 장점을 얻을 수 있었다. 게다가 그 시절에 벌써 유니코드를 염두에 두고 wide string을 기본적으로 사용하기 시작한 건 상당한 선견지명이다. 물론 그 대신 시스템 요구 사항이 당연히 1990년대의 가정용 PC가 도저히 범접할 수 없을 정도로 높았다. 메모리와 속도 모두.

이런 NT와는 달리, Windows 95는 이상이 아닌 현실을 추구하였다. 도스와 윈도 3.1을 돌릴 수 있는 정도의 램 한 자릿수 MB대 똥컴을 타겟으로 하여 Win32 API를 최대한 많이 구겨 넣었다. 이 과정에서 지금은 당연시되고 있는 유니코드 API조차도 메모리를 필요 이상으로 많이 잡아먹는 다고 판단되어 과감히 짤려 나갔다.

9x 커널의 소스에는 도스 레거시를 비롯해 오로지 x86 CPU에만 최적화된 쑤제 어셈블리 코드가 난무하였다. 그렇게까지 극도로 최적화를 하고 성능을 짜내야만 메모리 사용량을 1K라도 줄일 수 있을 테니 말이다. 9x는 NT보다 배고픈 운영체제인 것이다. 그럼에도 불구하고 OS/2를 PC 환경에서 완전히 몰아내고 Windows 천하통일을 이루는 데 기여한 일등공신은 NT가 아니라 95였음이 부인할 수 없는 사실이다.

OS/2를 개발하던 마소의 엔지니어들이 떨어져 나가서 따로 만든 게 NT라고는 하지만, OS/2 자체는 NT 같은 이식성 있는 형태라기보다는 9x에 더 가까운 어셈블리 최적화 컨셉이었다고 한다. OS/2는 NT 뺨치는 수준의 앞서 나간 최첨단 운영체제이긴 했지만, 내부 구조가 이식성보다는 역시나 x86에 너무 종속적이었다는 뜻. 그래서 다른 아키텍처로 이식은커녕, 같은 x86 컴에서 가상화 소프트웨어로도 돌리기가 곤란할 정도라고 한다.
(그래도 지금은 x86에서 맥 OS X 해킨토시까지 돌리는 세상이 됐는데 설마 OS/2를 못 돌리나 싶다.)

3.
더 옛날, 도스 시절에는 뭔가 새로운 하드웨어를 사용하려면 램 상주 프로그램을 덕지덕지 실행해 놔야 해서 몹시 불편했다. CD롬조차도!

  • 사운드: sound / unsound (굉장한 옛날 유물. 왠지 '불건전하다!'가 생각 나는 건 기분 탓. ㅋㅋㅋ)
  • 그래픽: simcga, msherc (이것도 옛날 유물. msherc의 경우, QuickBasic에도 포함돼 있었다.)
  • 마우스: mouse (단, 윈도 3.x는 별도의 램상주 드라이버 없이도 마우스를 스스로 인식하여 실행되었음!)
  • CD롬: mscdex (기본 메모리를 상당히 많이 차지했음)

아마 USB 포트가 도스 시절에 도입됐다면, 이걸 인식시켜 주는 램 상주 프로그램도 당연히 필요했을 것이다.
아, 텍스트 모드에서 한글을 구동해 주는 프로그램도 빼먹을 수 없다. hbios / mshbios(윈도 95) 같은 것.
그 외에 화면 캡처나 게임 위저드 같은 램 상주 유틸리티는 하드웨어 인식보다는 편의 기능 분야에 속한다.

요즘은 환경변수 같은 건 PATH에서나 제일 많이 쓰이고, C/C++ 프로그래머에게는 컴파일러의 동작에 필요한 include 및 라이브러리 디렉터리를 지정할 때나 쓰이는 게 고작이다.
하지만 옛날에 사운드 블래스터라는 사운드 카드가 있던 시절에는 기본 IRQ 번호던가 뭔가도 환경변수에다 지정해 놓곤 했으며, 각종 게임의 환경설정 프로그램에는 사운드 종류와 그런 세부 정보도 입력을 받곤 했다.

이것도 정말 까마득한 옛날 얘기가 됐다.
도스용 프로그램들에는 파일 메뉴에 '도스 나들이(DOS Shell)' 기능이 있던 시절이니까 말이다.
운영체제가 이렇게 방대하고 권한이 커지면서 상당수의 유틸리티들은 의미를 퇴색했으며, 전문화된 고급 셸 아니면(토탈 커맨더 같은) 더 전문적인 유지보수 유틸리티(노턴 고스트?) 내지 안티바이러스/보안 쪽으로 업종을 세분화· 전환하는 게 불가피해졌다.

4.
태초에 도스는 검은 화면에 흰 프롬프트밖에 없었을 뿐만 아니라 명령어를 입력하는 환경도 굉장히 자비심이 없었다.
삽입/삭제 모드 같은 개념이 없을 뿐만 아니라, 애초에 이미 입력된 글자를 지우지 않고서는 앞 글자로 cursor를 옮기는 것 자체가 불가능했다. 즉, 왼쪽 화살표만 눌러도 마치 bksp를 누른 것처럼 앞글자가 지워지면서 cursor가 앞으로 이동했다.

명령 히스토리는 직전의 딱 한 단계만 지원했다. F1~F3을 눌러서 직전 명령을 한 글자씩 복구하거나 첫 n 글자 또는 전체를 한꺼번에 불러오곤 했다. 그 시절을 혹시 기억하는 분이 계시는지?

그나마 doskey.com이라고 아마 도스 3~4쯤에서 추가된 걸로 추정되는 외부 명령 램 상주 유틸리티를 실행하면 위/아래 화살표로 히스토리가 가능하고 좌우 cursor 이동이 자유롭게 가능해졌다. 지금은 너무 당연하게 여겨지는 기능이 옛날에는 별도의 프로그램을 통해서만 접근 가능한 액세서리 기능이었던 것이다.

윈도 NT의 명령 프롬프트는 기본적으로 이 모드인 듯한데, 그런데 tab을 눌러서 파일/디렉터리 이름을 자동 완성하는 기능은 윈도 XP에서 처음으로 추가되었다. 세상에, NT4와 2000 시절까지만 해도 이런 기능이 없었으며, tab을 누르면 그냥 문자적인 탭이 그대로 삽입되곤 했다.

단, 기능 추가만 있는 건 아니다. 윈도 XP까지는 탐색기에서 파일이나 디렉터리를 명령 프롬프트에다 drag & drop을 하면 그 이름을 자동으로 삽입해 주는 기능이 있었는데 아마 윈도 Vista부터는 그 기능이 의도적으로 삭제되었다. 보안 때문에 취해진 조치라고 하는데 이런 편리한 기능에 도대체 무슨 보안 문제가 있는지는 나로서는 알 길이 없다.

명령 프롬프트를 전체 화면으로 실행하는 기능 역시 Vista에서부터 삭제되었다. 딱히 별 의미가 없어지기도 했으니.
어디 이 뿐이랴. 2000까지만 해도, 콘솔창 내용을 마우스로 긁는 '빠른 편집' 모드는 곧장 사용 가능했던 반면 XP부터는 먼저 속성 창을 거쳐서 강제로 켜야만 사용 가능하게 바뀌었다. 이건 보안 이유 때문은 아니고, 마우스를 지원하는 도스용 프로그램과의 호환 때문에 취해진 조치라고 한다.

제아무리 도스 기반이 아닌 NT 계열의 명령 프롬프트라 해도, 문자 인코딩부터가 2바이트 ANSI 코드 페이지와 여전히 얽혀 있고 도스의 흔적을 완전히 걷어내지는 못한 듯하다. 그래도 64비트부터는 16비트 코드 자체가 이제 지원되지 않는데 더 좀 걷어내도 되지 않나 싶다.
기존 명령 프롬프트보다 더 강력한 대체제라고 일컬어지는 PowerShell이라는 물건이 있긴 하나, 본인은 그런 게 있다는 것만 알고 이게 특별히 장점이 무엇인지는 알지 못한다.

아 그리고. 지긋지긋한 Terminal 내지 굴림체 말고 Consolas 내지 Courier, Lucida Console 같은 글꼴을 좀 쓰고 싶은데 Wndows는 공식적으로는 명령 프롬프트의 글꼴을 자유자재로 바꾸는 방법을 제공하지 않는다. 마치 uxtheme을 해금/탈옥시키듯이 레지스트리를 조작해서 글꼴을 바꾸는 방법이 인터넷에 있긴 한가 본데 본인은 성공하지 못했다.

Posted by 사무엘

2015/03/02 19:28 2015/03/02 19:28
, , ,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1068

« Previous : 1 : ... 23 : 24 : 25 : 26 : 27 : 28 : 29 : 30 : 31 : ... 43 : Next »

블로그 이미지

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

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

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

Site Stats

Total hits:
2634542
Today:
1340
Yesterday:
1754