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

우리나라는 서해를 건너는 두 개의 대형 교량 위에서 안개가 자욱하게 낀 날에 초대형 연쇄 추돌 교통사고를 한 건씩 경험하게 됐다. (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 사무엘

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Posted by 사무엘

※ 컴퓨터 & 프로그래밍

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 사무엘

오늘은 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 사무엘

• 지금으로부터 무려 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 사무엘

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 사무엘

* 이 글과 함께 볼 만한 과거 관련글: 추락(으/사)로 유명해진 사람들

1.
2015년 1월 초엔 경기도 안성에서 엽기에 가까운 황당한 뉴스가 하나 전해졌다. 아파트 16층에 사는 어떤 70대 노파가, 밖에 일일이 나갔다 오는 게 귀찮다는 이유로 밤에 여러 차례 상습적으로.. 자기 집의 음식물 쓰레기를 베란다 밖으로 투척해 오다가 결국은 덜미가 잡혔다.

그 사람이 떨어뜨린 쓰레기 봉투는 음식물 쓰레기 수거함에 곱게 갔을 리가 없으니 지상에 주차돼 있던 차량들 위로 다 떨어졌다. 차들은 유리, 지붕, 엔진룸 등이 부서졌으며, 그냥 쓰레기도 아니고 썩은 물이 줄줄 흐르는 음식물 쓰레기가 묻는 바람에 청소까지 해야 하는 지경이 됐다.
피해 주민들이 민원을 넣고 CCTV를 설치하고 경찰에 신고까지 했지만, 깜깜한 밤에 갑자기 쓱 떨어지는 작은 물체를 포착하기는 쉽지 않았다. 급기야는 쓰레기 봉투 안에 들어 있던 마트 바코드를 조회해서 가해자를 잡아 냈다니 이번에도 우리나라 공권력 만세다.

저 할머니는.. 중증 치매나 정신병, 몽유병, 만취 상태 같은 경우가 아니라면, 지금까지 나이를 도대체 어디로 잡수셨는지 내 머리로는 이해할 수 없다. 자동차니까 망정이지 사람이 그 봉지에 맞았으면 어찌 하려 했는가?
형사상의 벌금은 법에 정해진 한도로만 떨어지지만, 민사상의 손해 배상금은 피해를 입한 만큼 내야 한다. 지금까지 1000만원이 넘는 물적 피해를 낸 저 가해자는 집안 재정이 좀 파탄 날 각오를 해야 할 듯이다. 과거엔 삼풍 백화점이나 세월호를 소유했던 기업도 이런 손해 배상금 명목으로 재산이 다 털렸었다.

2.
지하 주차장에 차를 세워 놓으면 최소한 저렇게 위에서 떨어지는 오물을 맞을 일은 없을 것이고, 더 나아가 뺑소니 차량이 긁고 튄다거나 지나가는 취객이 차를 망가뜨리는 일도 상당수 예방이 가능할 것이다. 거기는 24시간 내내 불이 켜져 있고 CCTV도 잘 갖춰져 있어서 치안이 좋다.

그러나 거기도 마냥 안심할 수만은 없다. 지하는 지상보다 근본적으로 화재에 취약하다는 약점이 있다. 지금으로부터 2년쯤 전엔 용인의 모 아파트 지하 주차장에서 어느 젊은 정신이상자가 불장난을 하다가 대형 화재를 내는 바람에 그 층에 있던 30여 대의 차량들을 깡그리 불태워 버린 적이 있다.
이 정도 피해 규모이면 정말 노예 제도라도 있지 않으면 한 집안을 다 거덜내서라도 피해 보상을 할 수 없을 것이다.

3.
아파트에서 누가 투신 자살을 한 것만으로도 충분히 안타깝고 불미스럽고 끔찍한 소식인데, 우리나라엔 2010년대에 투신 자살하는 사람에게 깔려서 깔린 사람과 자살자가 같이 죽은 일도 두 건이나 있었다. 이거 뭐, 아파트 주변에서는 앞만 보고 나갈 게 아니라 위로 하늘도 반드시 경계하고 주시해야 하는가 싶을 정도이다.

2012년 10월엔 경북 고령에서 한 중국 동포 30대 여성이 신변을 비관하여 14층에서 뛰어내렸는데.. 그 순간에 다른 남자가 "쓰레기를 버리러"(아까 1번 이야기와는 좋은 대조를..) 아파트 현관 밖으로 나가려 했고.. 결국 떨어진 사람을 맞았는지 부딪혔는지 깔렸는지.. 표현을 어떻게 하면 좋을지 모르겠지만 끔찍한 참변을 당했다. 정말 마른 하늘에 날벼락이 따로 없다.

이듬해 2013년 5월엔 우울증을 앓고 있던 30대 남성이 부산의 한 아파트 고층에서 뛰어내렸다. 그런데 마침 1층에서는 한 집에서 6살짜리 여자아이와 부모가 외출하러 나가던 중이었다.
아이는 신이 났는지 부모보다 먼저 밖으로 쪼르르 달려 나갔는데.. 저 자살자는 하필 그 타이밍 때 아이 위로 떨어져 버렸다.

자기 눈앞에서 눈 깜짝할 사이에 생판 모르는 사람이 투신 자살을 하고 자기 애가 그 사람 몸과 부딪혀서 치명상을 입고 죽었다니.. 부모가 얼마나 쇼크 받고 멘붕에 빠졌을지 차마 상상이 가능하겠는가? 쓰레기 봉투가 아니라 사람이 떨어졌고 그 가해자는 죽고 없으며 가해자의 유족은 최소한 가해자의 자살과는 관계가 없는 사람들이니, 이건 뭐 누구에게 책임을 물을 수도 없다. 그러니 답답할 뿐이다. 앞으로 이런 일이 다시는 없기를 바랄 뿐이다.

4.
끝으로.. 우리나라에서야 멀쩡한 엘리베이터를 놔 두고 음식물 쓰레기 봉투를 밖으로 떨어뜨린 노파의 파렴치· 몰상식한 행동이 지탄의 대상이지만, 북한에서는 이게 그저 웃거나 비아냥거릴 일이 절대로 아니다.
남조선에서 음식물 쓰레기를 몰래 투척한 노파의 소식을 들으니, 오래 전에 봤던 본 주 성하 기자의 증언도 덩달아 연관 검색 결과로 떠올랐다.

인평양의 고층 아파트에서 살 정도이면 그야말로 1% 안에 드는 최상류층일 텐데.. 그런 동네에서도 전력이 부족해서 엘리베이터는 그야말로 오전과 저녁 러시아워 때만 운영된다. 그렇기 때문에 고층에서 사는 몸이 불편한 노인들은 진짜 자기 집 밖으로 나오지를 못하고 사실상 높은 탑 안에 감금된다.

물도 당연히 특정 시간대에만 제한급수다. 더운물이 안 나오고 난방이 안 되는 건 차라리 양반이다. 추위 정도는 집안에 또 비닐하우스를 만들고 이불과 옷을 겹겹이 감싸면 극복 가능하며 실제로 평양 시민들은 그렇게 지낸다고 한다. 허나 밥 지을 물, 마실 물, 씻을 물, 심지어 변기 내릴 물이 제때에 충분히 안 나오니...;;

이건 음식물 쓰레기 투척하고는 차원이 다른 문제이지 않은가? =_=;;;
시가지에 인분이 굴러다니는 건 중세 유럽이나 구한말 조선 시대가 미개하다고 깔 때에나 등장하는 레퍼토리인데 저 동네는 시골 촌구석도 아니고 평양이 저 지경이고 이에 대한 탈북자들의 증언이 서로 일치하니 참 뭐라 할 말이 없다.
참 여러가지 일들을 생각할 수 있었다.

Posted by 사무엘

본인이 지금까지 게임 포함 고전 소프트웨어에 대해 글을 잔뜩 올린 것은 그래도 플랫폼은 PC 한정인 편이었다. 운영체제는 응당 16비트 도스/윈도이다.
하지만 그보다 더 옛날 8비트.. 아무래도 롬 베이직을 빼면 롬 카트리지를 꽂아서 게임밖에 할 게 없었던 더 옛날 컴퓨터에 대한 추억도 없는 건 아니다.

본인은 난생 처음 접한 개인용 컴퓨터가 286 AT인 관계로, 저 컴퓨터는 친구 집에서 어깨 너머로 구경만 했지 개인적으로 소장한 경험은 없었다.
그런 플랫폼용으로 프로그램 개발은 어떻게 했을까? 16비트도 모자라서 8비트이면 int도 char과 크기가 같을까? 몇만 바이트밖에 안 되는 허접한 메모리로 어떻게 저런 게임을 만들 수 있었을까? 1980년대 초니까 C 컴파일러조차도 없이 그냥 기계어/어셈블리 직통 코딩을 했을까?

그런 컴퓨터와 아예 8비트 아케이드 게임기와의 관계는 어떠했을까? 그리고 MSX인지 뭔지는 무슨 규격이지? 난 그런 건 전혀 모른다.
그러고 보니 일본이 유난히도 이런 플랫폼용 게임을 많이 만들었던 것 같다. 이 글에서 소개하는 5개의 게임도 다 일제이다.
하지만 본인은 정작 일본에서 동전 품절 현상을 일으킬 정도로 대성공을 거뒀다는 슈퍼마리오는 전혀 접한 적이 없었다. 그리고 황금도끼나 보글보글도 PC 도스용을 접했지 오락실용은 접한 적이 없다. 오락실용이 더 완성도가 높고 재미있는데도 말이다.

1. 남극 탐험

영어 원제는 Antarctic Adventure로, 1984년에 일본 코나미에서 MSX용으로 개발했다.
구멍과 바다표범을 요리조리 피하면서 펭귄을 잘 달리게 하는 게 목표이다. 구멍에 빠지거나 바다표범에 부딪히면.. 주인공인 펭귄이 죽거나 다치지는 않지만.. '지연'이 발생해서 제한 시간 안에 도착을 못 하고 미스가 난다.

BGM은 잘 알다시피 다른 음악이 아니라 스케이터 왈츠라는 고전 음악이다.
그리고 레벨을 클리어하면 가상 세계가 아니라 현실에서 남극 기지를 보유하고 있는 국가들의 국기가 뜨는데, 이는 이 게임이 완전한 허구의 게임성보다는 일종의 교육용으로 개발되었기 때문이다.
늘 드는 생각이지만, 주행 거리 단위는 km를 m로 거의 1/1000에 가깝게 너프시켜도 모자랄 판에 뻥튀기가 너무 심하다.

2. 캐슬 엑설런트

1985년에 일본 아스키 사에 MSX 및 여타 플랫폼용으로 개발한.. 일단은 아케이드 게임이지만 슈파플렉스처럼 퍼즐 요소가 굉장히 강하다. "도미솔미 파레솔~~ 도미솔미 파레도" 요런 BGM이 유명하다. 참고로 아스키는 MSX 규격을 제정하는 데 동참했던 그 회사이다.

얘가 게임 메카닉면에서 여타 게임들과 다른 점은.. 점프가 단순히 일시적인 추진력으로 공중에 떴다가 즉시 떨어지는 게 아니라... 일종의 제트팩을 몇 초간 동작시키는 것과 같다는 점이다. 그리고 다른 방으로 들어가면 각종 기물이나 적들의 위치가 원상복귀되어 버린다는 것도 비현실적이다. 단, 없애 버린 기물이나 적이 다시 생기지는 않는다.

이 게임은 레벨이라는 개념이 없으며, '캐슬'을 구성하는 가로 10*세로 10 총 100개의 방 전체가 거대한 단일 레벨이다. 그리고 지형과 기물, 각종 열쇠 조합을 이용한 굉장히 까다로운 퍼즐을 풀어야 공주가 있는 방까지 갈 수 있다. 주인공은 각종 움직이는 트랩이나 적에게 걸리면 HP 없이 바로 죽는다. 그리고 무기가 없어서 적은 움직이는 기물이나 트랩을 이용해서만 죽일 수 있다.
난 당연히 엔딩은 못 보고 포기했지만, 그래도 뭔가 중세풍의 성 안에서 각종 보석을 먹는 게 잠시나마 재미있긴 했다.

3. 덱스더(Thexder)

친구 집에서 패미컴용을, 그리고 나중에 초딩 시절에 개인적으로 PC DOS용도 해 봤다. PC용은 극악의 종횡비를 자랑하는 CGA 640*200 16색 그래픽 모드에서 실행되었다. 물론 원작은 1985인가 86년에 Game Arts라는 일본 기업에서 개발되었으며, 그 당시 수십~수백만 카피가 팔렸을 정도로 굉장히 히트 치고 성공한 작품이라고 한다.

게임 주인공은 이족보행과 비행 기능을 모두 갖춘 로봇이다. 아케이드 게임으로서는 아주 드물게 각도를 목표물을 자동 조준하여 총을 쏘는 기능이 있다. (이것 말고 자동 조준을 하는 게임으로는 난 툼 레이더밖에 못 봤다~!)
비행 모드에서는 덩치가 좀 더 작아지고 낙하· 추락을 안 하게 되지만 자동 조준을 못 하며 중간에 정지를 할 수 없다는 제약이 생긴다.

이런 상태에서 던전 안의 수많은 장애물· 몬스터들을 죽이거나 피하면서 던전을 빠져나가는 게 게임의 목표다. 게임을 잘 못하면 적들이 너무 많이 나와서 걔네들에게 다구리 당하다가 게임오버 된다.
SF스러운 느낌이 나면서 한편으로는 단조 특유의 구슬픈 느낌이 나는 BGM도 인상적이다.

4. 마피 (Mappy)

1983년에 일본 남코에서 개발한 아케이드 게임으로, 동작 플랫폼이 위의 둘과는 좀 다르다. 위키백과에서도 MSX가 아니라 '아케이드'라고만 소개하고 있는데, 그래서 그런지 본인 역시 이건 동전을 넣어서 사용하는 동네 문방구의 오락기로만 구경해 봤다.
주인공은 쥐이고 적들은 고양이인데, 고양이를 피하면서 아이템들을 모두 모아야 한다.

고양이를 직접 공격해서 죽일 수는 없으며, 문을 적절한 타이밍에 열어서 기절시킬 수만 있다. 그리고 굉장히 특이한 규칙이 있는데, 봉봉 패드를 타고 점프 내지 낙하 중일 때, 다시 말해 발이 땅에 닿지 않은 상태일 때는 고양이와 닿아도 죽지 않는다. 요 타이밍을 잘 이용해야 한다.
그런데 안전하다고 해서 봉봉 패드만 계속 연달아 타고 있으면 안 된다. 그러면 패드가 나중에 끊어져서 화면 아래로 떨어지기 때문이다.

E단조의 BGM 멜로디도 20년 가까이 기억 속에 봉인되어 있었는데 본인은 아직까지 정확하게 기억하고 있다. 신기하다.
그리고 정식 오락실도 아니고 마치 뽑기 기계처럼 비치된 '동네 문방구의 오락기'라고 하니까 또 추억이 돋는다. 요즘은 그런 용도의 게임은 스마트폰 게임이 다 대체해 버렸으며, 3, 40대 아저씨들이나 옛날 추억을 살리려고 에뮬레이터와 롬 파일을 구해서 PC에서 게임을 즐기는 지경이 됐다.

일본에서는 패미컴(family), 퍼스컴(personal) 등.. 한국 같았으면 그냥 알파벳 이니셜을 그대로 썼을 텐데 영어 단어를 제멋대로 뚝뚝 잘라 내서 말은 참 잘 만든다는 생각이 들었다.

5. 요술나무 (Magical Tree)

남극탐험과 마찬가지로 코나미에서 1984년에 MSX용으로 개발한 작품이다. 제목을 까맣게 잊어버린 상태였는데 구글에서 MSX tree climbing game이라고만 쳤더니.. 이거 뭐 내가 원하는 답이 즉시 튀어나와서 기억을 복원할 수 있었다. 역시 무서운 구글.

이건 깃털 달린 모자를 쓴 귀여운 인디언 소년이 주인공으로 나오고, 나무를 수직으로 끝도 없이 타고 오르는 게 목표인 게임이다. 9개의 스테이지를 거치면서 설정상 총 2004m를 올라가야 한다. 한라산보다 약간 더 높구나.
게임 BGM을 말하자면, 평소에는 F장조 파~도 파~도 파라솔파도... 요렇게 시작하는 명랑한 멜로디 6마디가 무한 반복된다. 아, 한 스테이지에는 화면의 중앙에 나무 기둥이 있는 보통 모드가 있고, 중앙 대신 좌우 양 끝에 나무 기둥이 있는 특별 모드가 있다. 특별 모드에서는 반음 간격의 뚜두뚜두...만 반복되면서 뭔가 위기 상황인 듯한 분위기가 난다.

주인공을 방해하는 건 무슨 게처럼 수평 비행을 하는 부엉이, 번개를 떨어뜨리는 먹구름, 그리고 시도 때도 없이 튀어나오는 애벌레 등이다. 아이템으로 칼과 활이 있는데 이건 점수만을 줄 뿐 무기가 아니다. 이 게임엔 주인공에게 무기를 사용한 공격은 없으며 단지 사과를 떨어뜨리고 굴려서 적을 없애는 시스템만이 존재한다.

끝도 없이 높이 솟은 나무 위에 성이 있는 게 '재크와 콩나무' 동화 같은 느낌이 든다.

Posted by 사무엘

본인은 이 블로그의 옛날 글들을 보면 알 수 있듯, 어린 시절의 추억이 담긴 옛날 고전 게임들을 회상하는 걸 매우 좋아한다.
본인이 어릴 때에 생각한 가장 typical한 게임은 사람 또는 최소한 두 팔 두 다리가 달린 캐릭터가 2차원 던전을 뛰어다니면서 적을 죽이는 액션/아케이트 장르였다. 그래서 주 관심사도 페르시아의 왕자나 황금도끼 같은 부류였는데..

하루는 오랜 기억 속에 봉인되어 있던 약간 색다른 게임이 되살아난 관계로 별도의 글을 좀 쓰게 되었다. 바로 슈파플렉스이다.

이 게임은 통상적인 액션/아케이드라고 보기에는 맵 구조가 단순하고 주인공의 묘사가 더 기하학적(?)이며 퍼즐의 비중이 매우 높다. 주인공이 대놓고 동그란 공 모양인 건 Bumpy's Arcade Fantasy 말고는 쟤 정도밖에 기억이 안 난다.

이 게임의 명목상 배경은 컴퓨터 내부=_=;;이다. 주인공은 저 붉은 공 모양의 입 큰 캐릭터이다. 주인공은 던전 안에서 좌우상하 마음대로 드나들 수 있기 때문에 던전의 전체 시점이 좌우전후인 것 같지만, 실제로는 그렇지 않다. 중력이 아래로 작용하고 있다. 그리고 일부 소수 레벨은 주인공에게도 중력이 걸리기 때문에 위로 한없이 자유롭게 올라갈 수가 없다.

게임의 기본적인 목표는 던전 안을 돌아다니면서 위험물에 걸려 죽지 않고, '인포트론'이라고 불리는 아이템을 모두 먹어서 모은 뒤 출구로 빠져나가는 것이다. 초록색 기판은 주인공만이 먹어서 없앨 수 있는 일종의 지형인데(적은 이걸 못 없앰), 이게 없어지면 그 위에 있던 돌덩어리와 인포트론은 아래로 떨어진다. 떨어지는 물체에 맞으면 주인공이건 적이건 다 죽는다.
(여담이지만, 주인공이 녹색 기판을 먹으며 이동 중일 때는 눈을 소복소복 밟는 듯한 찰진 소리가 들린다.)

슈파플렉스의 모티브는 팩맨과 분명 비슷한 점이 많다. 하지만 지형을 먹어 없애서 장애물을 아래로 떨어뜨릴 수 있는 것은.. 1983년에 개발된 완전 옛날 게임인 Digger와도 비슷한 것 같다.
혹시 Digger 아는 분 계시는지? 본인은 초딩 시절에 컴퓨터 학원에서 디스켓 넣어서 흑백 모니터 XT 컴퓨터로 저걸 돌려서 해 봤다. 얘는 주인공이 무슨 자동차처럼 생겼으며, 한 화면에서 보석을 다 먹기만 하면 자동으로 레벨이 끝난다.

물론 슈파플렉스는 Digger보다야 머리 써야 하는 복잡한 요소가 훨씬 더 많다.
돌과 인포트론이 막 복잡하게 섞여 있는 곳에서 뭘 까딱 잘못 건드리면 죽거나, 인포트론이 돌 사이에 파묻혀서 내가 먹을 수 없게 되는 게 많다. 마작으로 치면 무작정 짝이 맞다고 해서 아무렇게나 가까운 패를 없애다가 나중에 게임을 풀 수 없는 지경이 되는 것과 비슷하다.

이런 장르를 별로 안 좋아하는 사람이라면 게임 하다가 너무 골치 아파서 스트레스만 잔뜩 받을 법도 한데.. 덕후들은 오히려 이런 데에 완전 열광한다.
엔하위키 아니랄까봐 각 레벨과 게임 특성에 대해서 아주 자세히 설명돼 있다. 역시 거기 글 쓰는 사람들은 덕력이 장난이 아니다.

PC 통신 시절에 내가 알고 지내던 내 또래의 어느 컴덕/프로그래머는 슈파플렉스의 중독성을 극찬하던 매니아였으며, 도스용으로 슈파플렉스 레벨 에디터를 자작하기도 했다. =_=;;
하긴 별도의 복잡한 트리거나 이벤트가 별로 없이 정말 사각형 격자 데이터만으로 레벨이 만들어지니 데이터가 압축/암호화만 돼 있지 않다면 레벨 에디터를 만드는 건 어렵지 않았겠다.

이 게임의 백미는 돌더미들이 하나씩 순서대로 떨어지면서 좌우로 균형 있게 데굴데굴 굴러서 차곡차곡 쌓이는 모습이다. 이런 게임 메카닉은 어떤 알고리즘으로 구현되었을지가 프로그래머로서 무척 신기하게 느껴진다.

나와 비슷한 또래의 사람이라면 옛날 비디오 게임에 대한 추억을 하나 이상씩은 다 갖고 있는 모양이다. 그래서 웹툰 작가 가스파드는 작년 가을부터 <전자오락 수호대>라는 작품을 연재하기 시작했는데..
다들 알다시피 이건 뭐 예고편부터가 일개 웹툰 퀄리티가 아니었다. 도대체 무슨 약 빨고 이런 걸 창조해 냈는지? 천재라고밖에 생각할 수 없다.

그리고 여담이지만, 퍼즐보다는 더 현실성을 추구한 아케이드 게임에서도 아래로 떨어지는 중력을 왜곡하는 효과는 종종 등장한 경우가 있다.
페르시아의 왕자는 7단계 끝부분에서 초록색 물약을 먹어서 잠깐 낙하산 효과가 나며, 퀘이크 1의 비밀 레벨은 주인공을 포함한 모든 동체들이 중력이 1/n토막 나서 꽤 높은 점프가 가능하다.
물론 지구상에서 그걸 실제로 구현하는 건 제트팩 같은 것이라도 달지 않는 이상 불가능할 것이다. 아니면 달 같은 다른 작은 행성으로 가든가.

Posted by 사무엘

* 본인은 니코틴의 맛이라는 게 뭔지 모르는 비흡연자이다. 담배를 접할 일은 앞으로도 평생 없을 것으로 보인다.

올해부터 잘 알다시피 담뱃값이 크게 올랐다. 그래서 오르기 전 가격으로 담배를 사재기 하려는 흡연자, 그리고 있는 담배도 일부러 꿍쳐 놓고 값이 오를 때까지 안 파는 가게, 사재기를 단속하려는 정부 당국..의 삼파전은 뭔가 병림픽 같다는 생각이 들었다.

지금이야 흡연이 건강에 나쁘다는 인식은 상식 중의 상식이 된 지 오래이며 대중교통을 포함해 지붕이 있는 공공장소에서 흡연이 허용되는 곳은 전혀 없다. 그나마 건물 내에 별도로 지정되어 있던 흡연실도 요즘은 없어지는 추세여서 흡연자들은 근무 중에 담배라도 한 대 피우려면 옥상이나 1층까지 갔다가 와야 하니 시간과 업무 생산성 손실이 많다.

하지만 옛날에는 그 위험한 수소 비행선인 힌덴부르크 호 내부에도 흡연실이 있었고 비행기 스튜어디스가 간접흡연 때문에 폐암에 걸려 죽을 정도였다. 지금으로서는 상상도 할 수 없는 일.
담배가 몸에 해롭다는 건 둘째치고라도, 비행기 객실 안에서 화기를 반입하고 불을 피울 수 있다는 것 자체가 오늘날의 보안 관념으로는 충공깽에 가까운 사실임은 틀림없다.

다만, 군대나 회사에서 “우리 나가서 담배나 좀 피우고 올까?” 이러면서 선임과 후임 사이에 훈훈한(?) 이야기가 오고가고 서로 친해지는 순기능이 있다는 건 본인 역시 인정한다. 어찌 보면 꽤 큰 순기능이다. 담배가 그렇게까지 건강에 나쁘지 않고 연기 냄새가 그렇게까지 역겹지만 않다면 말이다.

나도 어지간해서는 비흡연자의 권리만큼이나 흡연자의 권리도 보장해 주고 싶다. 그래서 지붕 뚫린 바깥에서까지 흡연을 금지시키고 싶지는 않다. 내 앞에서 담배를 뻑뻑 피우며 길빵을 하는 사람이 있으면 내가 그냥 달려서 그 사람을 조용히 추월해 가 줄 용의는 있다.

하지만 길빵은 담배 연기가 문제가 아니라 굉장히 위험하다. 담배를 든 팔을 잘못 휘둘러서 옆의 사람이 화상을 입는 사고가 실제로 여럿 발생했다. 또한 담뱃재와 담배꽁초를 아무렇게나 버리는 사람은 정말 싫다.
이와 대조적으로 공공장소 화장실이나 아파트 계단 통로에서 몰래 담배 피우는 사람들은 본격적으로 연기와 냄새로 민폐를 끼친다. 개인적으로 완전 혐오. 가끔은 건물의 엘리베이터 대신 계단으로 내려가고 싶은데 그렇게 할 수가 없게 만드는 주범들이다.

이렇듯, 담배는 기체를 퍼뜨려서 주변의 여러 사람들에게 큰 불편을 끼친다는 점에서 액체인 술과 다르다.
그러나 한편으로 담배는 무슨 음주운전 교통사고나 주폭 같은 피해를 끼치지는 않으니 해악의 양상이 술과는 사뭇 다른 것 같다.

한국 담배인삼 공사의 비공식 슬로건이 “담배 피워 망친 건강 인삼으로 회복하자”라고 한다. =_=;; 진짜라고 믿으면 당연히 골룸..
둘 다 우연히 국가가 전매 독점 관리하는 식물이라는 공통점이 있을 뿐이다. tomorrow와 global을 갖다붙인 영어 이니셜은 아무래도 어거지 성격이 짙다.

담뱃값 인상은 그냥 복지 집행으로 인한 부족한 세수 확보 명분일 뿐이다. 국민 건강 그딴 것 때문이 아니며, 우리나라가 주변 선진국들보다 담뱃값이 싸기 때문에 더 올리자는 주장도 말이 안 된다. 그럼 우리나라가 주변 선진국보다 매우 비싼 생필품들에 대해서는 가격을 내려 줄 용의가 있기라도 한가? -_-;;

다만, 그렇다고 해서 국가가 담배 판매를 통해 왕창 이득을 챙기고 있는가 하면 그런 것도 아니다.
거시적으로는 담배 때문에 고의로 건강 망쳐서 발생하는 생산성 저하, 사회 비용과 의료보험 재정 탕진이 더 크다.
마치 서울 지하철 보증금보다 1회용 교통 카드의 생산 단가가 더 높으며,
미국은 자국에서 생산되는 석유를 자국의 자동차들을 굴리는 데 쓰느라 더 바쁘지 나중에 더 비싸게 팔려고 꿍쳐놓고 있는 게 아닌 것과 비슷한 이치이다. 음모론은 그저 음모론일 뿐.

끝으로, 금연 장려를 위해 이런 아이디어가 제안되어 있는데 다들 참 기발하다.

• 각종 경고문이나 사진을 붙이기에 앞서 담배 이름부터 좀 화끈하게 짓자. 자살초, 폐암말기, 썩은허파, 매독 등.
• “경고: 이 담배의 판매 수익은 국회의원들의 월급 지급을 위해 쓰입니다” ...;; 내 건강 망가지는 것보다 정치인들 배부르는 게 더 싫구나. 그저 웃프다.

Posted by 사무엘