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

요즘은 좀 덜해진 감이 있지만 한때 마소에서는 자사의 운영체제인 Windows에 단순히 기술과 기능뿐만 아니라 감성을 담으려고 애쓰곤 했다. 애플 진영만 감성 마케팅을 한 게 아니라는 얘기이다.
이쪽으로 굉장히 신경을 많이 썼던 때는 크게 세 시즌으로 나뉜다. (1) 95, (2) XP, 그리고 그 다음 (3) Vista 정도 되겠다.

Windows 95는 그야말로 마소의 Windows 개발 역사상 가장 큰 격변을 이룬 작품이었다.
그러니 3.1 시절의 너무 식상했던 tada.wav를 대신하여, 참신하고 세련되고 오픈되고 모던한 이미지를 표현할 수 있게, Windows 95 부팅이 마치 미래로 가는 창문을 열어젖히기라도 한 인상을 줄 수 있는.. 그런 시작음을 외주를 줘서 개발하게 되었다.

그 유명한 "또르릉~ 띵~ 띵.." 95의 시작음을 작곡한 사람은 Brian Eno이다. 파일 이름부터가 참 거창하게 The Microsoft Sound였다.
다만, 정작 그 작곡자는 DOS고 Windows고 전혀 사용하지 않는 골수 Mac 유저였다는 것이 훗날 당사자의 회고 인터뷰를 통해 알려지기도 했다.;;

Windows 95는 누구나 듣는 시작음뿐만 아니라, 소수의 매니아만이 열어 보는 이스터 에그 화면에다가도 고유한 음악을 집어넣었다. 여기에 들어간 음악이 바로 그 유명한 Clouds이다. 이거 작곡자는 Brian Orr이니 또 다른 Brian이다. 단, 이건 길이와 용량 관계상 wav가 아니라 mid 포맷이다.

저 작곡자가 회고하기를, 작곡을 의뢰받을 때 컨셉으로 받은 키워드가 clouds, floating, peaceful이었다고 한다. Windows 95는 부팅 스플래시 화면부터가 파란 창공과 구름이었으니까..;; 그래서 그 컨셉에 맞게 멜로디를 써 넣은 결과물이 저 음악이라고 한다.
여느 음악 예제들과 마찬가지로 Windows\media 디렉터리에 있었다고는 하지만 본인은 얘는 Windows 95가 실제로 사용되던 시절에 PC에서 찾아서 들어 보지 못했다.

저거 이후로 마소의 제품에서 이스터 에그 재생 중에 그럴싸한 음악이 나온 경우는 Visual Basic 5~6의 이스터 에그가 유일했던 듯하다. 공교롭게도 저 이스터 에그도 파란 창공을 배경으로 정육면체 상자 4개가 뱅글뱅글 돌아가고 그 배경 위로 개발자 명단이 스크롤 되어 올라간다.

물론 이스터 에그라는 것도 2002년 이후로는 마소의 제품에서는 싹 자취를 감춰서 볼 수 없게 됐지만 말이다.
우리나라 지하철에다 비유하자면, 처음에 인테리어가 좀 독특하게 꾸며졌던 역들이 모두 안전을 이유로 스크린도어로 뒤덮이고 불연재 재질로 교체되어 미관이 예전보다 안 좋게 바뀐 것과 비슷해 보인다. 뭐 아무튼..

Windows NT 4라든가 98~ME 사이에서는 전자 악기 기반의 시작음들이 많이 쓰였으며 특히 chimes, chord, ding 같은 메시지 비프음도 다시 만들어졌다. 이것들은 다른 아티스트들의 작품이다.

그러다가 Windows XP는 프로그램의 시청각 요소가 완전히 쇄신했다. 이제 PC의 속도와 메모리가 충분해진 덕분에 9x 계열 커널이 수명을 다할 때가 됐고, 그리고 64비트와 멀티코어 CPU도 등장하다 보니 하드웨어가 큰 변화를 겪을 시기였다. 이 시기에 맞춰 마소에서는 OOBE (out-of-box experience)라는 말까지 만들어 내면서 새 운영체제로 '사용자에게 새롭고 특별한 경험을 선사하자'에 목숨을 걸었다. 굳이 Windows 2002 대신 XP라는 브랜드명까지 만들면서 말이다.

일단 피아노 소리 위주인 시작음, 비프음들은 다 Bill Brown이라는 작곡가가 작곡하고 오케스트라를 동원해서 연주했다. 그리고 (1) Tour를 실행했을 때 나오는 고퀄의 배경 음악들도 이 사람의 작품이다. 시퍼런 Luna 테마와 풀밭 사진뿐만 아니라 음악도 Windows XP를 뭔가 종합 예술 작품 같은 인상을 심어 주는 요인이다.

사실, Windows XP는 애초에 설치를 하다가 작업이 마무리되고 비디오/사운드 카드가 자동으로 잡히고 나면 간단한 애니메이션과 함께 (2) 몽환적인 분위기의 intro 음악이 나온다. 길이도 무려 5분 24초나 된다. 이걸 듣고서 강렬한 인상을 받은 사람이 많았을 것이다.

그런데 이 유명한 음악의 작곡자는 의외로 Bill Brown이 아니며, 정확하게 알려져 있지 않다. 인터넷 상으로는 Brian Eno가 작곡했다는 말이 많지만 저 사람은 공식적으로는 Windows 95 로고송 이후로 딱히 마소와 다시 작곡과 관련된 계약을 맺은 내역이 없다.

Susan Ciani라는 미국의 여성 작곡자를 지목하는 곳도 있으나, 이 역시 정확한 출처나 근거가 부족하다. 이 곡은 Windows XP의 정체성 그 자체로서 Tour 음악과 쌍벽을 이룬다고 해도 과언이 아닌데, 작곡자가 공식적으로 미상인 것이 무척 미심쩍게 여겨진다.

그 뒤, Windows Vista부터 도입된 "따단 따단" 그 4개 음표짜리 전자음 멜로디는 Robert Fripp이라는 사람이 작곡한 것으로 알려져 있다. 이때 이후로 마소에서는 운영체제의 음악에 큰 신경을 쓰지 않고 있다.
옛날에는 사용자가 선택한 테마에 따라 GUI의 색상과 글꼴, 각종 사운드가 싹 달라지게 하는 게 유행이었고 애초에 Windows와 Office, Visual Studio 제품들도 버전이 바뀔 때마다 프로그램 외형과 색상도 같이 바뀌던 시절이 있었거늘, 그마저도 2010년대 이후로는 약발이 다한 모양이다.

시작음처럼 운영체제나 프로그램의 구동과 함께 연주되는 음악 말고.. Windows\media 디렉터리에 예제로 제공되는 음악들도 버전별로 바뀌어 왔다.
Windows 3.1 시절에는 canyon과 passport라는 이름의 mid 파일이 있었다. 95와 그 이후까지 존속했는지는 기억이 확실치 않다.

98/2000쯤에는 '엘리제를 위하여'를 포함해 뜬금없이 클래식 음악의 미디 파일이 갑자기 쭈욱 추가되었던 걸로 본인은 기억하는데, 후대 버전에서는 몽땅 다시 사라졌다.
그 대신 ME와 XP에서는 그 당시의 최신 외국 가요 음반에서 발취한 샘플 wma 한두 곡이 잠시 들어갔다. 미디로는 town, flourish, onestop이 들어가서 오늘날 Windows 10에까지 전해져 내려오고 있다.

특히 onestop의 경우 마치 음악계의 the quick brown fox jumps over the lazy dog처럼.. 미디에 정의되어 있는 모든 악기들을 일부러 모두 동원하는 형태로 만들어졌으며, 구간별로 분위기가 오락가락 하면서 굉장히 괴랄한 흐름과 중독성을 자랑한다.
뭔가 RPG 게임의 BGM 같기도 하고.. "이 음악 들으니 문득 집 앞 편의점까지 희망찬 모험을 떠나고 싶어졌어!" 뭐 이런 말이 나올 정도라고 한다..;;

Posted by 사무엘

1. 도스 시절 명령어

도스에서 파일(과 디렉터리)을 다른 곳에 복사하는 명령은 copy이다. 얘는 명령 셸인 command.com이 자체 지원하는 내장 명령이다.
그런데 도스에는 copy의 일종의 강화 버전이라 할 수 있는 xcopy라는 것도 있으며, 이건 별도의 프로그램을 통해 실행되는 외부 명령이다.

xcopy는 일반 copy와 달리 (1) 서로 다른 드라이브 사이에 서브디렉터리까지 재귀적으로 통째로 복사하는 걸 지원했으며, (2) 복사에 사용하는 메모리 버퍼 크기가 더 크고, 여러 개의 파일을 한꺼번에 읽은 뒤(대략 수백 KB 정도 크기까지) 타겟에다 쓰는 걸 지원했다. xcopy의 전치사 X는 일반적으로 cross라고 발음되었다.

지금 생각해 보면 이 둘은 차별화 요소가 전혀 될 수 없으며 굳이 분리할 필요가 없다. 그냥 copy가 원래 (2)처럼 동작하면 되고, (1)은 /s 같은 옵션을 추가해서 지원하면 될 일이다.
하지만 옛날에 xcopy가 외부 명령으로 존재했던 이유는 겨우 그 정도 고급 복사 옵션/기능마저도 command.com에다 상시 집어넣고 있기에는 메모리가 부족하고 아까웠기 때문이다. 옛날에는 베이직 인터프리터가 Ready 출력할 메모리조차 아까워서 프롬프트를 Ok로 바꾼 시절이 있었다는 것 기억하시는가? (단 3바이트를 아끼려고!) 검색을 해 보니 xcopy는 1987년, MS-DOS 3.2에서 첫 도입됐다고 한다.

하긴, 옛날에는 다단계 디렉터리를 재귀적으로 탐색하면서 뭔가를 하는 일이 쉽지 않아서 외부 유틸리티를 많이 이용해야 했다. 파일 찾기는 말할 것도 없고, 지우는 것도 옛날에는 deltree라는 명령이 따로 있었지 싶다. 그건 지금은 del에 /s옵션으로 통합됐지만 말이다.
유닉스 계열 셸은 내장과 외장 명령어 구분이 어찌 되나 모르겠다. cp, mv, rm은 외부 프로그램인 것 같던데 설마 pwd, cd 이런 것들도 다 외부 프로그램이려나?

그리고 옛날에는 플로피 디스크(일명 디스켓)란 게 쓰여서 파일 시스템 차원에서 완전히 똑같은 디스크 복제를 해 주는 diskcopy라는 외부 명령이 있었다. 얘는 굳이 외부 명령으로 만들 거면 디스크 이미지 파일을 만들거나 이로부터 복제 디스크를 만드는 기능도 같이 있었으면 좋았을 거라는 아쉬움이 남는다.

1.2~1.44MB짜리 디스크를 단일 드라이브에서 복사하려면 source와 target 디스켓을 여러 번 갈아 끼워야 했는데.. Norton Utilities 같은 다른 유틸리티들은 EMS 및 XMS 메모리를 활용하여 한 번만 갈아 끼우고 바로 복사가 된다는 걸 장점으로 내세우곤 했다. 프로그램을 하나 설치하려 해도 "제품의 이제 1~N번 디스크를 넣고 아무 키나 누르세요" 이러던 참 아련한 옛날 추억이다.

2. 16비트 Windows의 실행 모드

예전에 언급한 바와 같이, 1990년대 초중반에 Windows라는 운영체제가 32비트 플랫폼으로 처음 갈아타던 시절에는 Win32 API라는 것의 구현체가 Windows NT, Windows 95, Windows 3.1+Win32s라는 세 계통으로 나뉘었다. NT가 가장 이상적인 레퍼런스 구현체이고, Win32s는 제일 허접하다.

그리고 그 중간의 95는 비록 NT처럼 스레드도 지원하고 도스로부터 많이 독립했다고는 하지만, 도스로부터 완전히 독립했다기보다는 도스를 내부적으로 흡수· 합병한 것에 가깝다. Windows NT의 마이너 축소판이라기보다는 Win32s가 각종 한계 없이 제대로 구현된 형태라고 보는 게 더 타당하다.

그런데 95 계통의 전신이라 할 수 있는 Windows 3.0이 나왔을 때에는 동일 제품· 단일 바이너리 하에서 실행 모드가 세 갈래로 나뉘었다. 바로 8086 리얼 모드, 286 표준 모드, 386 확장 모드이다.
Windows NT 4가 가장 많은 아키텍처를 지원하는 32비트 운영체제였다면, Windows 3.0 (3.1 말고)은 실행 모드가 가장 다양했던 16비트 도스용 운영 환경(?)이었다.

원래 Windows 1과 2에서는 리얼 모드밖에 존재하지 않았으며, Windows는 진짜 도스 위의 덧실행 껍데기 그 이상도 이하도 아니었다. 리얼 모드에서는 메모리가 기본 640K밖에 없었으며, 그 번거로운 16비트 Windows 3.x보다도 프로그래밍 환경이 더 열악했다.

그러다 Windows 2.0의 후속 버전으로 2.1은 286 표준 모드를 도입한 Windows/286과, 386 확장 모드의 전신인 Windows/386 이렇게 두 갈래로 나왔다. 사실, 16비트 80286 프로세서에도 보호 모드가 있긴 했지만 프로그래밍에 애로사항이 많았는지 그걸 사용한 프로그램은 매우 소수였으며 여전히 거의 봉인돼 있었다. 그냥 EMS/XMS 같은 규격으로 메모리를 수백 KB 남짓 더 사용할 수 있다는 것에 의미를 둬야 했다. 386 확장 모드도 첫 버전답게 문제가 많았으며, 2.11이 더 나와야 했다.

그러다가 Windows 3.0은 리얼, 286 표준, 386 확장을 모두 통합하여 출시됐다. 이때는 DPMI 규격도 갓 제정되었기 때문에 2.x 시절보다 보호 모드 지원도 더 개선되었다.
이때는 3.0에다가 멀티미디어 API가 최초로 추가된 확장팩이 나왔으며, 3.1은 네트워크 API가 추가된 Windows for Workgroup 3.11, 그리고 중국어 입출력 지원이 추가된 3.2 이런 식으로 기능 확장팩이 많던 시절이었다. 지금처럼 인터넷을 통한 업데이트가 가능한 시절도 아니었으니 말이다.

Windows 3.1에서는 리얼 모드가 삭제되고 win /2 또는 /3을 통해 286 표준 모드만 지원하지만, 이것은 성능이 굉장히 많이 열화된 모드였다. 그리고 Windows 95부터는 표준 모드도 빠져서 기술적으로 언제나 386 확장 모드로만 동작하는 형태가 됐다.

이렇듯, Windows 3.x는 비록 순수한 32비트 운영체제는 아니지만 보호 모드라든가 도스용 프로그램을 내부에서 구동할 때처럼 일부 기능에서 80386 이상 CPU가 제공하는 가상화 기능을 사용하기 때문에 결과적으로 32비트 CPU가 필요했다. 386 확장 모드가 지원하는 기능이 그런 것이었다.
이는 과거에 존재하던 PIF 편집기가 확장 모드에서는 표준 모드에 비해서 지원하는 옵션이 얼마나 더 다양해지는지를 보면 얼추 짐작 가능하다. 286 표준 모드에서는 요게 전부이던 옵션이..

386 확장 모드에서는 XMS뿐만 아니라 EMS 규격, 그리고 멀티태스킹 우선권 등 다양한 옵션들이 별도의 대화상자와 함께 추가되는 걸 알 수 있다.

Windows 95 역시 순수 32비트 프로그램이 아니면 도스용 프로그램에 대해서만 제대로 된 가상 머신과 선점형 멀티태스킹을 지원했다. 16비트 Windows 프로그램을 강제 종료하면 운영체제와 얽혀 있는 스레드 동기화 오브젝트 같은 것이 얼어붙으면서 시스템의 안정성에 심각한 문제가 발생하곤 했다.

LimitEmsPages 이런 함수는 32비트가 아니라 이미 Windows 3.x 시절부터 deprecated돼 있었는데, 아마 리얼 모드 시절의 잔재이지 싶다.
Windows 1~2.x용 실행 파일은 후대 Windows와 실행 파일 포맷은 동일하지만(NE) 내부의 플래그로 구분되어 있어서 3.x에서 실행하면 "제대로 실행되지 않을 수 있음" 경고가 뜨곤 했다. 요컨대 Windows의 역사를 살펴보면, 16비트에서 32비트로 넘어갈 때만치 큰 변화는 아니지만, 같은 16비트 안에서도 1~2.x와 3.x 사이에 보호 모드가 도입되기 전과 후에는 기술적으로 나름 변화와 단절이 있었다고 볼 수 있다.

3. 외주로 제작되었던 보조 프로그램과 게임

Windows에 내장돼 있는 기본 프로그램들 중에는 마소에서 직접 만들지 않은 외주 프로그램도 있다. Windows 95 시절에 잠깐 있었던 하이퍼터미널이라는 터미널 접속 프로그램이 대표적인 예로, 스플래시 화면이라든가 각종 UI 외형이 대놓고 기존 마소 프로그램과는 어울리지 않아서 마소 자체 개발이 아니라는 걸 알 수 있었다.

또한 게임 중에서도 Windows XP에까지 제공되었던 3D 핀볼(시네마트로닉스 개발, 맥시스 유통)은 외부 프로그램이었으며, Vista/7 시절에 그래픽이 쇄신했던 지뢰찾기 등의 기본 게임들도 외주였다(Oberon games).

그런데 더 옛날에 Windows 3.1의 내장 프로그램들을 보면, 굉장히 단순하게 생겼고 이 정도면 자체 제작했을 법도 한 프로그램이 About 대화상자를 보면 외주인 경우가 은근히 더 있었다. 게다가 아래의 목록에서 보다시피 제작자/제작사가 프로그램마다 완전 제각각이었다.

• 계산기: Kraig Brockschmidt
• 터미널: Future Soft Engineering 사
• 레코더: Softbridge 사
• 지뢰찾기: Robert Donner & Curt Johnson
• 카드놀이: Wes Cherry

그러니 Vista/7 이전에 제공되던 기본 게임들도 알고 보니 외주였던 셈이다. 특히 지뢰찾기는 Windows 1.0부터 3.0까지 존재하던 Reversi(일명 오델로)를 대체할 목적으로 3.1에서 처음 선보였던 게임이기도 하다.
레코더의 경우 Windows의 역사상 거의 전무후무하게 존재하던 키보드· 마우스 매크로 유틸리티인데 95와 그 이후로는 결코 재등장하지 않았으니 희소성이 크다.

물론 이것들 말고 프로그램 관리자, 파일 관리자, 제어판이라든가 간판 앱인 문서 작성기(오늘날의 워드패드)와 페인트(오늘날의 그림판)은 외주가 아니라 내부 자체 제작이다.

4. 색깔의 미묘한 차이

말이 나왔으니 옛날 추억 회상을 더 해 보자면,
컴퓨터의 주메모리가 아니라 비디오 메모리가 딱 1MB이던 시절에는 Windows 3.1의 비디오 모드를 (1) 꼴랑 640*480 저해상도인 대신에 트루컬러, (2) 800*600에서 적당하게 하이 컬러, 아니면 (3) 1024*768에서 256색.. 셋 중 하나로 골라 쓰는 재미(?)가 있었다.

그리고 Windows 3.1은 원래는 우리에게 익숙한 짙은 파란색으로 윈도우의 굵은 틀을 표현했지만, 하이 컬러 이상부터는 어인 일인지 은은한 하늘색으로 색깔을 바꿔 표시했다. 왜 무슨 근거로 색깔을 바꿨는지는 모르겠지만 개인적으로 아주 신기하게 느껴졌었다.

그 이전 3.0은 슈퍼 VGA나 트루컬러로 진입할 일이 있긴 있었는지, 그래픽 드라이버가 개발되거나 3.1 것과 호환되긴 했는지에 대해 본인은 아는 바가 없으며, 이에 대해서 회의적이다.

Posted by 사무엘

오늘은 1980년대 후반부터 1990년대 중반 사이의 기간에 마소에서 '도움말, 튜토리얼, tour, intro, guide' 장르에 속하는 프로그램을 개발한 것들을 좀 회상하고자 한다.
요즘 튜토리얼이라 하면 컴퓨터 게임에서 본게임을 수행하기 전에 기본적인 조작법을 익히는 싱글 플레이어 미션 정도를 가리킨다. 툼 레이더로 치면 Lara's home이 대표적인 예이다.

하지만 1980년대에는 게임 정도가 아니라 컴퓨터라는 괴상한 기계 자체에 익숙하지 않은 사람이 아주 많았다. '컴맹'이라는 단어 기억하시는가? 1992년에만 해도 '키출판사'라는 곳에서는 <저는 컴퓨터를 하나도 모르는데요>라는 컴퓨터 입문서를 하나 잘 만들어서 전국 서점에서 베스트셀러 자리를 수 년간 석권하며 초대박을 쳤었다.
그런 시절엔 일반인들을 대상으로 컴퓨터에 대한 두려움을 없애고 컴퓨터 입문을 도와 주는 프로그램도 나올 필요가 있었다. 특정 프로그램의 사용법뿐만 아니라 키보드 타자 내지 심지어 마우스 같은 사치품(?)을 다루는 방법도 사용자가 익혀야 했다.

마소에서는 오래 전부터 뭔가 인터랙티브한 학습/데모 소프트웨어를 만드는 것에 남다른 신경을 썼던 것 같다. 그도 그럴 것이, 이거 학습을 잘 시켜야 컴퓨터 사용자를 늘리고 잠재적인 자기 고객도 확보할 수 있을 테니까 말이다.

그리고 사실은 방대한 운영체제나 Office 솔루션의 '설치 프로그램'도 단계별로 뭔가가 진행된다는 점에서 UI 구조가 반쯤은 이런 데모 프로그램과 비슷하다. 그러니 마소에서 1990년대에 '마법사'라는 UI 요소를 만들어 냈고 두 개념을 합쳐 '설치 마법사'라는 말까지 만든 것이지 싶다. (다만, 비슷한 시기에 도입했던 '길잡이 clippy'는 너무 과잉 오버 사족으로 여겨져서 오래 못 가고 망했다만..)

아무튼.. 마소에서 지극히 초창기에 만들었던 학습 프로그램의 원조로 본인은 QuickBasic 4.5에 들어있던 (1) QuickBasic express를 기억한다. 실행 파일은 learn.com이고, qbcbt.ctx/scn/sob, 그리고 bx.pgm이라고 내부 구조를 알기 어려운 코드/데이터 복합 보조 파일을 추가로 사용한다.
이들 파일들을 다 합해 봤자 크기는 100K가 채 되지 않으며, 압축된 것도 아니어서 얼추 내부 문자열 같은 건 그대로 확인 가능하다. 그래도 프로그램을 실행해 보면 저 작은 크기가 믿어지지 않을 정도로 학습 컨텐츠가 많이 들어있다.

화면은 16색 텍스트 모드에서 아스키 아트를 최대한 창의적으로 활용해서 화려하게 꾸몄다. 무려 열차를 그렸으며, 프로그램을 실제로 돌려 보면 연기가 뿜어져 나오고 기관차의 구동축이 움직이며 선로가 가로 스크롤을 하기 때문에 열차가 진짜 달리는 것처럼 보인다. 프로그램 이름에도 BASIC만 빼면 Quick, express 온통 이런 단어들이니 얼마나 스피디한 느낌이 나겠는가? 말 그대로 '퀵베이직 특급· 고속· 급행열차'인 셈이다.

물론, 아스키 128번 이후 문자를 이용한 아스키 아트는 2바이트 단위의 동아시아 문자 코드와는 상극이니 이런 프로그램은 한글화 따위는 절대 불가능했을 것이다. 아니면 아스키 아트들을 2바이트 특수문자 기반으로 완전히 마개조 재창조 초월번역을 해야 할 텐데, 일본은 몰라도 그 당시 한국 마소에서 그런 용자짓을 할 여유와 능력, 재량이 있었으리라 여겨지지는 않는다.

마소에서는 이런 부류의 프로그램에 대해 내부적으로 이미 CBT(computer-based training)이라는 용어를 쓰기 시작했다.
뭐 본격적으로 프로그래밍 언어를 가르치는 것도 아니고, 전적으로 컴맹 왕초보를 위해서 QuickBasic을 구동하고 프로그램을 불러오고 실행하는 것까지만 설명하는 튜토리얼을 상당한 덕력을 담아서 굉장한 고퀄로 만든 것이다.
화차 그림에 쓰인 주의사항 보이시는가? 아주 대단한 선심이라도 쓰는 듯 "주목: 이런 지식은 아무 데서나 알려주는 거 아니야!" 이런 드립까지 친다.

열기: "자, 디스크에 저장된 프로그램을 불러오는 걸 실습해 보시겠습니다."
저장: "짜잔~! 프로그램이 final.bas라는 이름으로 저장됐습니다."

문장들의 문체가 전반적으로 은근히 재치 있고 익살스럽기 때문에, 한국어의 사무적인 해요체 합쇼체로 번역하기에는 너무 무겁고 길이도 너무 길다.
저건 그야말로 디스크와 파일에 대한 개념도 아직 부족해서 하드디스크에 몇백 GB짜리 사진을 저장하면 컴퓨터의 무게가 물리적으로 증가할 것처럼 생각하는 왕초짜를 위한 설명이다..;; C언어라면 몰라도(저 때는 마소에서 아직 C++ 컴파일러를 개발하지 않았던 시절) 베이직만은 그야말로 왕초보라도 접근 가능한 대중적인 프로그래밍 툴로 만들려는 빌 게이츠의 야심이 담긴 것 같다.

다 끝나고 나면 이 프로그램이 가르쳐 준 lesson의 핵심 요약을 요렇게 쭉~~ 늘어놓아 준다. 잊어버릴까 봐 종이에다 프린트 명령까지 제공하는 배려를 했다.
사실, 영어권에서 뭔가 개념원리 학습 자료를 만들어 놓은 걸 보면 참 대단하고 부러움이 느껴질 때가 많다. 기본기를 탄탄하게 다지는 게 느껴지기 때문이다.

가령, 컴퓨터 쪽은 아니지만 무려 1930년대에 GM사에서 영업사원들(이미 기계공학을 전공한 엔지니어들 말고) 교육용으로 변속기의 원리를 설명해 놓은 필름을 보면.. 매체의 기술 수준 말고, 강의 자체는 기본적인 물리 법칙부터 시작해서 공학적인 응용에 이르기까지.. 지금 봐도 나무랄 데 없는 고퀄이다. 저렇게 기본기와 실용주의에 충실한 교육이 쌓이고 쌓인 덕분에 미국이 과학 기술 선진국이 된 게 아닌가 싶다.

다 끝나고 나면 다시 열차 그림과 함께 엔딩 화면이 나타나는데..
이번에는 시작 화면과는 달리 화차가 텅 비었고 아무 짐도 실려 있지 않다. 아하.. 이런 차이를 담았구나!!
난 그걸 전혀 눈치 채지 못했는데.. 이번에 스크린샷을 찍기 위해 프로그램을 오랜만에 다시 돌려 보면서 차이를 알게 됐다.

QuickBasic은 시대를 풍미했던 명작이고, 지금도 고전 레트로 레거시 프로그래밍 장난감으로서 외국에 매니아 커뮤니티가 있다.
그런데 QuickBasic의 인지도에 비해 이 자습서 프로그램은 존재감이 너무 묻히고 있는 것 같다. QuickBasic learn.com, Express 등 내가 생각하는 모든 관련 키워드들을 조합해서 검색해도 스크린샷 한 장 뜨는 게 없기 때문이다.

게다가 learn.com은 어찌 된 이유인지 도스박스에서 안 돌아가고 시스템이 뻗는다(0.72 기준). 이것 때문에 더욱 접근이 어려웠다. VMware 같은 다른 가상화 유틸에서 돌려야 했다.

QuickBasic 말고 자습서로서 가장 유명한 건 아마 (2) Windows 3.1의 자습서이지 싶다. '프로그램 관리자'의 도움말 메뉴에 당당히 등재돼 있기 때문에 쉽게 접근 가능하다. PC 환경의 판도를 도스에서 Windows로 완전히 뒤바꾸기 위해서는 사용자에게 기본적인 마우스 사용법을 가르치고 Windows의 기본 UI 요소들을 다루는 일에 익숙하게 하는 것이 반드시 필요했기 때문이다.

이 자습서야 검색을 해 보면 스크린샷과 동영상들이 이미 넘쳐나니 이곳에서 미주알고주알 자세히 설명할 필요는 없을 것이다.
이런 식으로 고해상도(?) 화면에서 16색+도트 노가다로 깔끔하게 파스텔톤 그림을 그려 놓은 화풍을 개인적으로 좋아했다. 문자 때문에 고해상도가 필요했던 일본 게임들의 그림체도 이런 형태이긴 했다.

'파일-열기' 명령을 내려서 기존 문서를 불러오는 실습은 QuickBasic 자습서와 Windows 자습서에 공통으로 존재한다.

그 밖에 창 제목을 마우스로 드래그 해서 창의 위치를 옮기는 것, 그리고 라디오· 체크· 콤보 등 기본 GUI 요소들을 실습하는 것도 있다.

사실은 (3) Windows 95에도 자습서가 있다.
1990년대 중후반은 컴퓨터의 기본 조작에 익숙하지 않은 세대에 대한 고려가 여전히 필요한 시기였으며, Windows 95가 3.1에 비해 UI 요소가 바뀐 것도 워낙 많았기 때문에 시작 메뉴, 작업 표시줄, 폴더 같은 것에 대한 학습이 필요했다. 이때는 Windows 95 사용 관련 컴퓨터 서적도 정말 많이 출간됐었다.

단, 95의 자습서는 모든 컴퓨터에 기본으로 깔리지 않았으며, 운영체제를 설치할 때 사용자가 수동으로 자습서를 직접 골라야 했다. 그리고 구동하는 방법도 내 기억으로 도움말 어딘가에 숨겨져 있었고 메뉴에서 바로 선택 가능하지 않았다. 그렇기 때문에 3.1의 자습서보다는 훨씬 덜 알려져 있다.

내 기억이 맞다면 95의 자습서는 Visual Basic으로 개발되었지 싶다. 외부 링크로 소개를 대신하고자 한다.
그 당시 Windows 95의 비주얼 컨셉은 푸른 창공, 하늘과 구름이었다. 제품 패키지 박스와 부팅 스플래시 화면부터가 그렇고, 이스터 에그에 내장되었던 음악도 clouds.mid였으니.. 그러니 자습서에도 경비행기 그림이 있는 게 수긍이 간다.

그리고 끝으로.. 이거야말로 정말 오래된 기억에만 의지해서 회상하는 것이지만..
MS Word 중에서 16비트 Windows를 지원하는 마지막 버전이었던 (4) 6.0 역시 자습서를 내장하고 있었다.
구체적으로 무슨 내용이었는지는 기억이 안 나지만... Windows 3.1 자습서와 같은 엔진 기반으로 추정되고 비슷한 톤의 흰색 계열 화면이었다. 하지만 Windows 자습서와는 분명 다른 내용이었고, 배경 그림에 그 당시 Word 특유의 만년필 그림이 있긴 했다.

이 역시 내가 구글링 능력이 부족해서인지, 아니면 진짜로 역사 속으로 묻혀 버려서 그런지 인터넷 상으로는 자습서의 장면이나 동영상을 구할 수 없다.
16비트 시절 회상은 이 정도까지 하겠다.
사실, 도스박스로도 Windows 3.1 정도는 돌릴 수 있다. 이것도 0.6x대의 구버전에서는 안 되다가 후대 버전에서 가능해진 것이다.

도스박스는 여느 가상화 툴처럼 디스크 이미지를 별도로 만들 필요 없이, 기존 파일 시스템의 디렉터리를 곧장 mount 해서 쓰면 되는 게 참 편하다.
Windows 95까지도 돌린다고는 하지만, 그 정도부터는 아무래도 하드웨어 가상화의 도움을 받는 VMware 같은 더 정교한 가상화 프로그램의 도움이 필요할 것이다.
도스박스에서 Windows 3.1을 설치하면 다 좋은데, 프로그램 그룹의 수집과 생성이 왜 자동으로 되지 않는지가 의문이다. 프로그램 관리자가 기본 프로그램, 보조 프로그램 같은 그룹이 아무것도 없는 채로 시작된다.

한편, Windows 95부터는 부팅 직후에 간단한 welcome 프로그램을 실행하던 관행이 있었다.

95 때는 '알고 계십니까' 팁을 출력했지만 98과 2000에서는 인터넷 연결, 제품 등록 같은 걸 안내하는 것으로 프로그램의 실행 형태가 바뀌었고, ME와 XP부터는 이런 게 없어졌다.
2000년대 ME/XP 시기에는 컴퓨터의 기본 사용법을 가르치는 클래식한 자습서는 사라졌지만, Windows의 새 기능을 소개하는 데모는 플래시 내지 HTA (HTML application) 형태로 잠시 존재했다.
특히 XP에 내장돼 있던 플래시 기반의 "새 기능 투어"는 굉장한 퀄리티였다. 비록 한글화되지 않았으며, 이런 관행 역시 Vista와 그 이후부터는 역사 속으로 사라졌지만 말이다.

그럼 이제 프로그래머의 직업병을 발휘하여, 이런 자습서 내지 튜토리얼 프로그램들을 만드는 과정은 어떠할까 생각해 보고 글을 맺겠다.
웹이나 플래시는 처음부터 멀티미디어 컨텐츠를 표시하는 데 최적화된 저작도구 내지 플랫폼이라 치지만, EXE 기반의 전통적인 데모 내지 자습서· CBT 프로그램은 어떤 방법론을 동원하여 만들었을까?

순차적인 절차대로 진행되는 프로그램을 이벤트 드리븐 방식으로 개조하는 건 만만찮은 작업이기 때문이다. 쉽게 말해 과거의 터보 C/파스칼에 존재하던 BGIDEMO 예제처럼 순차적으로 일괄적으로 그래픽 데모가 진행되는 프로그램을 Windows용으로 짜는 걸 생각해 보자. 간편하게 자기가 원하는 타이밍 때 그림을 그리고 마는 게 아니라, 운영체제로부터 그림을 그리라는 요청을 받았을 때에만 그림을 그려야 한다.

그러니, 지금은 어느 데모의 그래픽을 출력할 차례인지 내부적인 진행 상태를 추상화해서 잘 관리해야 한다. 그리고 애니메이션이나 끊임없는 그리기 작업은 스레드나 타이머 같은 완전히 다른 방법론을 동원해서 해야 한다.

더 세부적으로 들어가면.. 자습서 프로그램은 그 특성상 학습 대상 프로그램이 실행된 가상의 화면을 표시할 일이 많고 심지어 그 가상의 화면에서 사용자가 창을 조작하는 것을 흉내까지 내야 할 때가 있다.
모든 그림들을 무식하게 비트맵 이미지로 때려박는 건 공간 효율과 유지 보수(일부 컨텐츠가 수정되었을 때, 화면 해상도가 변경됐을 때 등) 관점에서 별로 좋지 못하다.

저런 건 진짜 윈도우를 생성한 뒤에 서브클래싱 같은 customization으로 내가 원하는 형태로만 동작하게 제약을 추가하는 식으로 구현할 수도 있고, 아니면 윈도우 그림만 가짜로 그린 뒤에, 창의 이동과 크기 조절, 메뉴 표시 같은 당장 학습에 필요한 이벤트에만 임기응변으로 반응하게 만들 수도 있다. Windows 자습서는 정황상 대부분의 UI는 후자 방식으로 구현된 것으로 보이지만.. 이건 좀 어설프고 삽질스러워 보이는 면모가 있다.

당신이 Visual Basic의 짝퉁 개발툴을 직접 개발한다고 생각해 보자. VB의 디자인 모드에서 떡 나타나 있는 폼의 '윈도우 프로시저'는 어떻게 구현되어 있을지가 궁금하지 않은가? 평소에는 클라이언트 영역에 일정 간격으로 격자 도트가 찍혀 있을 것이고, 자신의 위치나 크기가 바뀌면 폼의 정보가 수정된다. 자기에게 놓인 차일드 컨트롤을 클릭하면 크기 조절을 위한 8개 모서리가 주변에 표시되며, 이걸 더블 클릭하면 해당 컨트롤에 대한 이벤트 핸들러 코드를 편집하는 창이 뜬다.

자습서 창 내부에서 특정 윈도우의 외형과 동작을 구현하는 일도 이런 것과 비슷한 차원일 것이다. 어떤 물건이긴 한데, 실물이 아니라 뭔가 영화 촬영용 소품과 비슷한 격의 물건을 갖다놓는 격이 된다.
'짝퉁'을 만드는 식으로 접근하는 방법론이 한계에 달했는지, 나중에 마소에서는 실제 프로그램이 돌아가는 상태에서 그때 그때 도움말이 응용 프로그램으로부터 신호를 받아 인터랙티브한 형태로 출력되는 모델을 고안하게 되었다.

그래서 오죽했으면 윈도우 훅 중에서도 WH_CBT라는 게 있다. 어떤 프로그램이 내부에서 창을 생성하거나 없애고, 포커스가 바뀌고 창의 크기를 조절하는 것.. 자습서는 학습 대상 프로그램에서 요런 특정 동작만 감지하면서 상황에 맞는 도움말을 출력하거나 지시를 사용자에게 내릴 수 있다. 이런 간단한 용도라면 굳이 모든 메시지를 통째로 훔쳐보는 무거운 다른 훅을 설치할 필요 없이 저것만 사용하면 된다.

이런 훅을 사용한 아주 모범적인 사례가 있다. 바로 HTML 도움말인 CHM 말고, Windows XP까지 지원되었던 재래식 HLP 파일을 생성하는 (5) 오리지널 Help Workshop 툴을 보면.. 도움말 프로젝트를 생성하는 요령을 설명하는 traning card라는 자습서 세션이 있었다. 전용 자습서가 거창하게 뜨는 게 아니라, 화면 옆에 아주 자그마한 도움말 창만 추가로 뜬 뒤, 도움말이 시키는 대로 실제로 프로젝트를 만들고 프로그램을 사용하면서 기능을 익힐 수 있었다.

물론 지금이야 HLP 도움말 자체가 폐기되었으며, 이런 식의 도움말 디자인 패러다임 역시 완전히 한물 가고 역사 속으로 사라졌다는 것은 아쉬운 점이다. Help Workshop에 이런 간소화판 자습서 튜토리얼이 존재했다는 것도 오늘날 인터넷에서는 흔적을 거의 찾을 수 없다.

Posted by 사무엘

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Posted by 사무엘

1. Windows 부팅

Windows 8 내지 10부터던가.. 요즘 Windows에서는 예전까지 오랫동안 쓰이던 통상적인 부팅 전 F8 메뉴가 사라졌다. 하긴, 메뉴가 여럿 있긴 했지만 고르는 건 안전 모드(F5) 또는 네트워크 되는 안전 모드 둘 중 하나밖에 없긴 했다.
그 대신, 부팅 후에 컴을 팩토리 리셋 초기화시키는 메뉴가 곧장 들어간 것은 일단 꽤 유용하며, F8을 눌러야 할 필요를 이걸로 상당수 대체하긴 했다.

하지만 뭐가 꼬여서 애초에 부팅이 안 되고 있을 때는 이 기능에 접근할 수 없어서 더 불편해졌다. 부팅 전의 OS 재설치 및 복구 UI는 사용자가 특정 글쇠를 눌렀을 때 바로 뜨는 게 아니라, 수차례 컴퓨터를 혹사시키면서 부팅이 실패한 것을 얘들이 인지했을 때에 그제서야 슬그머니 띄워 준다. 로직을 왜 이런 식으로 만들었나 모르겠다.

전에도 얘기했듯이, 본인은 업데이트를 받은 뒤에 운영체제가 꼬이고 커널 패닉 뜨는 걸 몇 번 겪은 뒤부터는 진절머리가 나서 업데이트 받는 걸 레지스트리까지 조작해서 강제로 끊어 버렸다. 지금 네트워크는 유료 종량제이니 니 멋대로 함부로 업데이트 받아서 설치하지 말라고 말이다.

CPU와 메모리와 네트웍 트래픽 잡아먹고 하드디스크 용량 잡아먹고, 컴퓨터를 꺼야 할 때 바로 곧이곧대로 꺼지질 않고.. 민폐가 너무 심한 데다, 그런 민폐가 시도 때도 없이 너무 자주 발생하고.. 설치 후에도 뭐가 크게 달라지고 좋아지기는커녕 저런 부작용만 있으니 이 상황에서 누가 업데이트 꼬박꼬박 받고 싶은 마음이 들겠는가?

그거 안 하고도 내 컴은 악성 코드고 뭐고 지금까지 보안 문제 같은 건 하나도 없었다. 이러다가 업데이트에 대해서조차도 현대 서양 의학 불신, 백신 불신 같은 이상한 풍조가 생기지는 않으려나 모르겠다만.. 브라우저를 선택할 권리 운운하면서 웹 표준 외치는 것만큼이나, 필요하지 않은 업데이트를 안 받거나 원하는 타이밍에만 받을 권리도 좀 보장됐으면 좋겠다.

2. 바이오스

뭐, 이건 운영체제 얘기였고 그 전에 롬에 탑재된 컴퓨터 고유의 소프트웨어 계층을 일명 BIOS라고 부른다. 이것도 2010년대에 와서는 UEFI라는 새로운 규격으로 바뀌었다.
운영체제 부팅 전에 BIOS 셋업(CMOS 셋업이라고도 불렀던 듯..)을 들어가려면 ESC, F2, F10, Del 이런 글쇠를 죽어라고 누르곤 했는데, 이 글쇠도 좀 Ctrl+Alt+Del 재부팅처럼 통일이 됐으면 하는 생각이 든다. 바이오스는 어차피 만드는 업체도 피닉스나 아메리칸 메가트렌드 요렇게 아주 소수이지 않던가?

살면서 BIOS setup으로 들어가야 하는 상황은 몇 년에 한 번꼴로 운영체제 변경· 재설치를 위해 부팅 매체 선택 순서를 변경할 때.. 혹은 하이퍼-V 가상화 같은 옵션을 켜고 끌 때 정도이지 싶다. 살다가 병원이나 법원, 경찰서, 주민센터 같은 델 들르는 빈도와 비슷한 격이다.

옛날에는 컴퓨터를 켠 직후에 숫자가 쫘르륵 올라가면서 주 메모리 테스트를 하는 게 관행이었는데 그 광경도 참 오래 전에 사라졌다. 램의 용량이 수백 MB 수준으로 넘어간 시기, 대략 21세기 초쯤부터 없어진 것 같다. 글쎄, 카운트만 안 보여줄 뿐, 내부적으로 여전히 테스트는 하는 걸 수도 있음.

그리고 요즘 컴퓨터는 바이오스 셋업 화면도 텍스트가 아닌 그래픽 모드로 바뀌었고 마우스가 지원된다. 저기는 한글화의 영원한 불모지라고 여겨졌는데 이젠 그것도 아니다. 마소처럼 11172자 완성형 글립을 다 때려박은 게 아니라 이야기체 같은 8*4*4 조합형 비트맵 글꼴을 쓴 것도 있어 더욱 반갑다.

바이오스 차원에서 하드디스크에 predefined type이 40몇 가지 정도 있던 시절도 있었는데.. 안 변하는 것 같아도 이 바닥도 하드웨어의 발전을 따라서 많이 변하고 있다.
그나저나 애플 제조 컴퓨터들은 바이오스 계층도 자체 개발인 거겠지? (켠 직후에 흰 화면에 빵~~! 소리, 그리고 alt 눌러서 부트캠프 동작..)

3. 글꼴

수 년 전부터 개인적으로 '감지'는 했던 현상인데, 어떤 컴퓨터는 글꼴 대화상자를 열어 보면 황당하게도 Times New Roman이나 Courier New 같은 필수 기본 글꼴이 목록에서 빠져 있고 선택 가능하지 않았다. 물론 그 컴퓨터에 실제로는 해당 글꼴이 멀쩡하게 잘만 설치돼 있다.
게다가 더 황당하게도 MS Word 같은 프로그램에서는 그 글꼴을 선택할 수 있었고 메모장이나 워드패드에서만 안 나왔다. 내 경험상 이건 컴퓨터마다 케바케로 발생하는 듯하고 Windows 7 이상 2010년대부터 종종 보였다.

처음엔 글꼴 목록에 영향을 끼치는 악성 코드가 있기라도 한지 의심을 했다. 하지만 알고 보니 이 현상에 대한 해답이 따로 있었다.
"제어판-글꼴-글꼴 설정"으로 들어가서 "언어 설정에 따라 글꼴 숨기기" 옵션을 끄면 사라졌던 Times, Courier 같은 글꼴을 다시 선택할 수 있다. (Designed for your language settings)

Windows 7부터 등장한 옵션은 맞아 보인다. 그런데 멀쩡한 글꼴을 선택할 수 없게 만드는 옵션은 대관절 도대체 왜 도입됐는지 모르겠다. 그런 옵션을 굳이 넣을 거면 글꼴 선택 대화상자 내부에다가 넣거나 show all 같은 버튼이라도 넣어야지 왜 제어판 깊숙한 곳에다가 짱박아 놓았는지도 알 길이 없다.

4. PNG

한때 GIF라는 그림 파일 포맷이 있어서 웹에서 정말 많이 쓰였다. 압축률 좋고 투명색과 애니메이션, progressive 렌더링 같은 독보적인 장점 기능이 많았다. 그러나 GIF는 내부의 압축 알고리즘에 특허가 걸려 있어서 아무나 활용하기가 곤란했다.

물론 이미 만들어진 그림 파일을 보기만 하는 사용자 입장에서는 제약이 걸리는 게 전혀 없고, GIF 파일을 생성하거나 디코딩하는 프로그램을 상업용 제품에다 직접 얹는 제조사의 입장에서 로얄티 같은 게 들었던 것 같다. 휴대용 MP3이나 WMA 재생기를 만들 때처럼 말이다. 전자는 프라운호퍼 연구소에, 후자는 마소에 특허든 저작권이든 뭐든 걸려 있다.

그래도 이 특허는 저작권 자체의 보장 기간(70년)보다는 기간이 훨씬 짧았던 모양이다. 2005년경에 특허가 풀리긴 했다. 그러나 gif는 트루컬러를 지원하지 못한 채 256색에서 발전이 멈춰 버렸기 때문에, 오늘날은 대체제인 PNG에 밀려 서서히 사장되는 중이다. 웹에서 사진용 손실 압축은 JPG가, 그 밖의 범용적인 비손실 이미지는 PNG가 시장을 나란히 양분하는 중이다.

PNG는 GIF보다 압축률이 더 좋고 트루컬러도 지원하며, 단순 color key 기반 투명보다 더 발전한 알파채널도 지원한다. 심지어 고화질 아이콘을 저장하는 컨테이너로도 이용되고 있다.
그러니 GIF의 대체물이 되기에 손색이 없다. 다만, 알파 채널은 1990년대 PNG의 첫 버전과 동시에 등장한 게 아니라 나중에 추가된 확장 규격이기라도 한지, 제대로 지원하는 프로그램이 여전히 적어서 아쉽다.

또한 PNG도 애니메이션 기능은 없다. APNG라는 규격이 있기는 하지만 웹 표준이 아니기 때문에 파이어폭스 같은 극소수의 브라우저 말고는 지원하지 않는다. 플래시가 없어지고 브라우저 자체의 동영상 코덱 규격조차 표준화가 논의되고 있는 와중에 애니메이션용 이미지도 더 늦기 전에 표준이 마련되고 모든 브라우저들이 지원해 줘야 하지 않나 생각이 든다. 하긴 옛날에는 동영상도 코덱 파편화가 무진장 심해서 '통합 코덱' 이러면서 혼란이 말도 아니긴 했었다.

5. high DPI 관련

Windows에서 high DPI 지원 정책은 한번 만들어 놓은 걸로 끝이 아니고 버전을 거듭할수록 마개조를 거듭하고 있다. 심지어 같은 Windows 10에서도 새 업데이트에서는 새 기능이 들어갔다.

8.1에서인가 그때부터 per-monitor high DPI이라는 게 도입된 걸로도 모자라서 이제는 아예 스레드별로 high DPI-aware 여부를 지정하고 그걸 on-the-fly로 변경하는 기능까지 추가됐다.
DPI의 변경은 너무 파격적인 변화여서 원래는 재부팅이 필요했으며, Windows Vista 시절에는 믿어지지 않지만 관리자 권한까지 필요하던 작업이었다. 그리고 어차피 제대로 대비가 돼 있는 유연한 프로그램도 매우 드물기 때문에 변경이 권장되지 않기도 했다.

그랬는데 그게 그래픽 카드의 성능 발달 덕분에 실시간 변경이 가능한 기능으로 서서히 바뀌어 간다. 그래도 마소는 레거시 호환성에도 목숨을 거는 곳이니, DPI 변화의 대비가 안 돼 있는 레거시 프로그램은 그냥 가상화 샌드박스빨로 통째로 속이고 말이다. Windows의 역사상 동일 기능이 위상이 이렇게 드라마틱하게 변한 다른 예는 찾기 어려울 것이다.
원래 화면 해상도나 색깔수를 바꾸는 것조차 먼 옛날에 Windows 3.x 시절에는 재부팅이 필요한 작업이었지만 9x/NT부터는 실시간 변경이 가능해졌지 않던가? DPI 변경도 그렇게 바뀌었다.

그도 그럴 것이, high DPI라는 게 원래는 시력 나쁜 사람을 위한 장애인 접근성에 가까운 잉여 기능이었다. 하지만 21세기에 모니터의 해상도가 급격히 올라가면서 이건 모든 사람에게 필요한 편의 기능이 됐다.

이 점에서 high DPI는 마치 자동차의 자동 변속기와도 비슷한 구석이 있다. 원래 자동 변속기 전용 면허는 왼발용 페달, 오른손용 다기능 스위치, 시청각 장애인용 볼록 거울처럼 장애인의 운전을 위한 여러 면허 조건 중 하나였다. 자동 변속기가 운전하기가 훨씬 더 쉬우니 장애인에게도 더 유리하니까 말이다. 그랬는데 자동 변속기가 워낙 대중화되고 나니 자동 전용 면허만은 1997년부터 일반인도 취득 가능하게 바뀐 것이다.

원래 화면 확대 배율이 기본값인 동시에 최소값일 때의 DPI 값은 96이었다. 이건 사실상 하드코딩된 채 쓰여 온 값인데, 언제부턴가 Windows SDK 헤더 파일을 보니 요게 USER_DEFAULT_SCREEN_DPI 라는 상수 명칭으로 추가되었다. 마치 마우스 휠의 기준값인 WHEEL_DELTA (120)과 성격이 비슷해 보이는데, 아무튼 GetDeviceCaps(hDC, LOGPIXELSX)의 리턴값과 저 96의 비율을 계산하면 확대 배율을 얻을 수 있다.

그런데 Windows가 존재하는 한 LOGPIXELSX와 LOGPIXELSY의 값이 서로 달라질 일은 설마 없겠지..?
모니터가 일부러 종횡비가 더 큰 와이드 화면으로(4:3 → 16:9) 바뀐 와중에, 논리적인 화면 종횡비를 또 보정해야 하는 건 옛날 CGA 640*200이나 허큘리스 720*348 해상도 시절 이래로 이제 없으리라 여겨진다.

옛날에는 멀티 모니터조차 예견을 못 하고 WM_CONTEXTMENU 메시지에서 마우스 클릭이 아닌 키보드 글쇠는 x, y 좌표가 모두 -1인 것으로 구분하게 스펙을 설계한 적이 있었는데.. 그때와 지금은 참 격세지감이다.
또한, 해상도 차이가 많이 나는 모니터를 둘 이상 연결해서 사용할 때를 대비해서, 이제는 두 모니터가 DPI 설정이 서로 다른 것까지 다 지원해야 한다. 그러니 high DPI를 제대로 지원하는 일이 더욱 복잡해진 것이다.

6. 네트워크가 안 될 때

집에서는 이런 현상이 없는데 회사에서는 가끔씩 멀쩡히 랜선이 꽂혀 있는데도 유선 인터넷이 안 되는 경우가 있다. 이때는 ipconfig /renew를 해 주면 문제가 해결되는 편이다.
때로는 /release도 해야 하고, 한번은 '설정'(제어판 말고)으로 들어가서 네트워크 관련 메뉴 맨 아래의 '전면 초기화'+재부팅까지 한 뒤에야 문제가 해결된 적이 있었다. 그 당시에 무엇이 정확하게 문제였는지 나로서는 알 길이 없지만, 아마 공유기 쪽 문제인 듯하다.

7. USB 메모리 관련

USB 메모리를 꽂아 쓰다 보면.. 분명히 작업을 마쳤고 관련 프로그램들을 다 종료한 뒤, 메모리를 빼려고 하는데 안전하게 분리가 안 된다고 운영체제가 꼬장을 부려서 난감해지는 경우가 있다.
Windows 2000 시절에만 해도 USB 메모리를 무단으로 뽑으면 경고 메시지가 나왔지만, 그게 그렇게까지 위험하지는 않고 괜히 사용자를 불안하게 만들 필요는 없다고 판단되었는지 XP와 그 이후부터는 경고 메시지가 사라졌다. 그러나 그렇다고 해서 무단 분리가 전혀 위험하지 않다는 얘기는 아니다.

USB 메모리를 분리하는 명령은 시스템 트레이에만 있는 게 아니라 의외로 해당 드라이브의 셸 우클릭 메뉴에도 존재한다. 마치 CD롬 드라이브의 우클릭 메뉴에 '디스크 꺼내기' 명령이 있는 것처럼 USB 메모리 드라이브도 우클릭하면 'eject'가 있으며, 이 명령을 이용해서 분리하면 트레이 메뉴 명령보다 성공률도 더 높다고 그런다.

경험상 macOS는 지금까지 쓰면서 USB 메모리 제거가 바로 안 되는 경우를 거의 못 본 거 같다.
그런데 pkg 파일을 열어서 설치하는데.. USB 메모리의 것을 바로 여니까.. insert the "(null)" disc to continue installation 이러면서 설치가 제대로 되지 않았다.
저건 %s 포맷 문자열에다가 null 포인터를 주기라도 했는지 메시지의 형태도 비정상일 뿐만 아니라, 배포 패키지 파일이 깨지고 문제가 있을 때에나 나타날 법한 메시지이다.

하지만 파일이 실제로 깨진 건 전혀 아니었으며, pkg 파일을 하드디스크에다 복사한 뒤에 설치하니까 아무 문제 없이 됐다.
왜 저런 현상이 있는지는 잘 모르겠다.

8. USB가 없던 시절의 컴퓨터 단자

그러고 보니 먼 옛날에.. USB 포트가 없던 시절에는 컴퓨터에 주변기기를 인식시키는 용도로 직렬 포트와 병렬 포트라는 게 있었다.
정확하게 뭐가 직렬 내지 병렬이어서 이런 명칭이 붙었고 서로 어떤 장단점이 있는지 잘 모르겠다. 라디오에 AM과 FM, 인터넷 프로토콜에 TCP와 UDP처럼 일장일단이 있는 관계가 아닌가 생각된다.

직렬 포트는 COMn 이런 이름이 붙어서 주로 마우스나 모뎀이 연결되었다. 그리고 병렬 포트는 LPTn 이런 이름과 함께 프린터나 스캐너 같은 기기가 연결되었으며, 과거에 쓰이던 하드웨어 방식 불법 복사 방지 장치 '락'도 대체로 병렬 포트에다 꽂는 형태였던 것 같다.

으음.. 그럼 외장 하드는 어디에다 꽂았지? 옛날에 하드 디스크끼리 꽂아서 데이터를 복사하는 건 정말 아무나 할 수 있는 일이 아니었다.;;
꽂고 나서는 바이오스 설정을 들어가서 이게 무슨 기기인지 설정을 수동으로 해 줘야 했다. plug and play 그런 건 없었다. 코덱이 너무 난무해서 동영상 보는 데 애로사항이 꽃폈고, 유니코드가 없어서 문자 인코딩이 어느 장단에 맞춰 춤을 춰야 할지 알 수 없던 그런 열악하던 시절의 추억이다.

Posted by 사무엘

본인은 평소에는 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 사무엘

예전에는 고전 게임들 중에 페르시아의 왕자 얘기를 종종 늘어놓는 편이었는데 요즘은 둠/퀘이크로 관심사가 바뀌어 있다. 그 시절엔 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 사무엘

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

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

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

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

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

곁다리: 짤막한 멜로디

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

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

* 2010년에 썼던 글을 리메이크 한 것이다.

일상생활에서 유리는 뭔가를 담는 병이나 그릇, 컵의 재료로 쓰이고 안경과 렌즈를 만드는 데 쓰이며, 각종 교통수단이나 건물에서 창문의 재료로도 쓰이는 요긴한 물질이다. 사실, 유리를 빼면 투명한 고체 자체가 주변에 의외로 흔하지 않다. 플라스틱, 얼음, 보석 말고는 뭐 떠오르는 게 없는 것 같다.

유리는 목재나 플라스틱과는 달리 열에 강한 편이며, 불탈 때 유독가스가 발생하지 않는다.
성냥을 갖다 대면 바로 불이 붙을 정도로 수백 도로 달궈진 유리 막대도, 차가운 유리와 외형상 전혀 차이가 안 보이기 때문에 취급에 절대 주의해야 한다고 과학 실험실 안전 수칙에 언급되어 있을 정도이다.

유리는 금속과는 달리 녹이 슬지 않으며, 염산이나 황산, 왕수 같은 위험한 강산 약품을 담을 수도 있다. 매우 편리한 점이 아닐 수 없다. (뭐, 플루오르 같은 변태 독극물은 유리조차 녹이기 때문에 다른 플라스틱 병에다 담는다지만..)
또한, 유리는 도자기와 더불어 전자레인지에 넣기에 가장 적합한 용기 재료이기도 하다. 종이나 나무 그릇은 용기도 손상될 수 있기 때문에 안 되고, 금속 그릇은 전자파를 반사하기 때문이다.

그런데 이런 유리도 단점이 있으니, 조금만 충격을 받아도 잘 깨진다는 것이다. 깨질 때 꽤 경쾌한-_- 소리가 나기 때문에 이말년 작가께서 이 소리를 만화에서 자주 써먹곤 했다.
그리고 그 깨진 유리 조각은 굉장히 날카롭고 위험하다. 길바닥에 이런 게 널브러져 있으면 사람이 다치기 쉬운 건 말할 것도 없고 자동차나 자전거의 타이어를 펑크 내기도 딱 좋다. 이런 조각들은 쓰레기로 배출· 수거하기도 힘들다.

말이 나왔으니 말인데, 사람이 자기 신체로 유리를 직접 파괴하는 건 대단히 위험한 짓이다. 그렇기 때문에 어떤 경우에라도 절대로 하지 말아야 한다. 교통사고나 화재로 인해 건물이나 교통수단으로부터 긴급히 탈출해야 할 때라도, 더 무겁고 단단한 다른 물건(망치, 소화기 등)으로 유리를 미리 먼저 부순 뒤에 나가야지, 박치기를 해서는 안 된다.

긴급 상황이라면 차라리 이해라도 하는데, 열받았을 때 객기 부린답시고 유리창이나 거울을 맨주먹으로 쳐서 깨는 건... 완전 바보 짓 미친 짓이다. 주먹과 닿은 유리 표면이 부서지는 순간 손은 유리 조각에 찔리며, 유리를 뚫고 들어갔다가 되돌아오는 과정에서 날카로운 유리 날에 쫘악~ 베이고 긁히고 유리 조각이 박힌다. 손은 그야말로 피투성이가 되고, 잘못하면 불구가 될지도 모른다. 동맥이라도 손상됐다간, 급소를 다치지 않아도 과다 출혈로 죽는 수가 있으며, 고인은 영락없이 다윈 상 후보로 귀착되어 버린다.

유리는 총· 총소리만큼이나 영화나 게임이 현실을 제일 왜곡하고 사람들에게 잘못된 관념을 심어 주는 물건에 속한다.
액션 영화에서는 주인공이 조금만 충격을 줘도 유리로 된 문이나 창문이 정말 쉽게, 시원하게 박살나고 주인공은 아무렇지도 않지만 현실은 전혀 그렇지 않다. 영화에서 소품용으로 쓰이는 유리는 애초에 따로 있기 때문이다. 투평하고 잘 깨지고 파편이 사람에게 피해를 주지 않는 대신, 너무 약하기 때문에 애초에 건축자재로 쓰이지도 않는다.

게임에서도 마찬가지다. 우리는 현실에서는 절대로 페르시아의 왕자처럼 행동하지 말아야 한다. 묘하게도 1과 2에서 모두 이런 장면이 있다.

거울을 무려 맨발로 격파하는 왕자님. 자기 영혼(?)이 빠져나가고, HP는 1로 곤두박질친다.

2는 아예 시작부터가 저런 막장 설정으로..;;

좀 큰 규모의 교통사고가 나면 역시 해당 교통수단의 유리창도 박살이 나곤 한다. 과거에는 깨진 앞유리 파편들을 얼굴에 고스란히 뒤집어 쓴 자동차 운전자는 충돌로 인한 충격보다도 이것 때문에 그대로 끔살 당하곤 했다..;;
그래서 두 유리판을 셀룰로이드로 접착한 안전유리가 20세기 초에 발명되었다. 일반 유리보다 강하고 잘 깨지지 않으며, 심한 충격을 받아 깨지더라도 유리 조각들 모양으로 금만 쫙 생기지 모양은 최대한 유지되는 유리이다. 이것도 만능은 아니겠지만, 그래도 마치 방탄조끼나 헬멧만큼이나 인간의 생명을 구하는 데 큰 기여를 한 훌륭한 발명품임이 틀림없다.

VIP들이 타는 자동차에는 안전유리를 넘어 방탄유리가 쓰인다. 이건 교통사고처럼 넓은 면적에 고르게 받는 충격이 아니라, 총알처럼 한 점에 집중된 강한 충격에도 쉽게 뚫리지 않게 강화된 유리이다. 즉, 방탄복· 헬멧의 유리 버전이다.
영화 <아저씨>에서 만석이 차 안에서 이거 하나만 믿고 "이거 방탄유리라구 이 ㅂㅅ아~!"라고 깝쳤으나, 한 곳에만 집중된 권총 사격에 유리가 뚫리면서 결국 밥숟가락 놓게 됐다.

중남미 어디던가 치안이 불안한 어떤 나라에서 한인 교포가 차량용 방탄 유리 제조 업체를 운영하는데, 성능이 좋아서 현지인들에게서 인기가 좋다고 TV에서 본 기억이 있다. 길거리에서 수시로 총싸움이 벌어질 정도로 치안이 막장이다 보니 저게 보안 차원에서 수요가 있다고 그런다..
하긴, 외국 또 어디에서는 제조사 사장이 직접 차에 타고 직원이 그 차에다 소총을 갈기는 CF를 찍어서 유튜브에 올리기도 했다. 멀쩡히 살아서 나온 사장은 "이래서 우리 제품 짱"이라고 선전하고 말이다.

다만, 운동 에너지에서 m이 극단적으로 작고 v만 극단적으로 큰 총알이 아니라, 아예 쇠망치나 도끼 같은 걸로 차량 유리를 찍는다면 창 자체는 박살나거나 뚫리지 않지만 창이 통째로 차량의 필러(기둥, 지지대)에서 뜯겨져 나갈 수가 있다. 다양한 형태의 물리적인 충격에 대비하여 철통보안을 달성하려면 이래저래 신경써야 할 게 많다.

한편, 총알 방어와는 반대로, 교통사고 현장의 탈출이나 차량 내 자살자 구출 같은 이유로 차량의 유리를 인위적으로 깨야 할 때도 있다. 앞유리는 굳이 방탄이 아니더라도 앞서 얘기했던 안전을 위해 어지간한 인력만으로는 정말 지독하게 안 깨지게 설계돼 있다. 거기보다는 측면,  도어의 유리를 공략하는 게 좋다. 도어의 유리에서 모서리 쪽을 망치로 쳐 주면 그럭저럭 깰 수 있다고 한다.

끝으로, 똑같이 투명한 유리여도 그런 창문용 유리랑 아예 유리궁전 건물 외벽을 구성하는 유리는 강도와 두께가 서로 쨉이 안 된다. 이건 똑같이 벽돌처럼 생겼어도 건물 외벽 벽돌과 내부 인테리어용 벽돌이 다른 것만큼이나 다르다. 후자는 아예 겉모습만 벽돌일 뿐 애초에 돌도 아닌 플라스틱 벽돌도 있으니 말이다. 초가집이 사라진 것만큼이나 불과 몇십 년 전까지만 해도 주류였던 벽돌이 자취를 싹 감춘 게 인상적이다.

Posted by 사무엘