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

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

컴퓨터에서 돌아가는 프로그램들에는 각각 current directory라는 개념이 있다. 그래서 파일이나 디렉터리를 지정할 때 매번 드라이브 또는 볼륨의 이름부터 쓰는 게 아니라 그걸 생략하고 이름만 달랑 적거나, ..￦ 처럼 간편하게 ‘상대 경로’를 지정해 줄 수 있다.

기술적으로 봤을 때 current directory는 프로세스 전체 단위로 공유되는 속성이다. 스레드 단위가 아니다.
한 디렉터리 아래에 있는 모든 파일과 디렉터리를 조회하는 건 보통 SetCurrentDirectory를 이용해서 함수의 재귀호출로 구현하는 편인데(이름을 줘서 하위 디렉터리로 갔다가 앞으로 되돌아갈 때는 간편하게 ".."만 지정하면 됨), 이건 여러 스레드가 동시에 수행되지 않게 해야 한다.

여러 군데에서의 디스크 수색을 굳이 동시다발적으로 하려면 해당 함수가 경로 문자열 관리를 자체적으로 해서 FindFirstFile에 언제나 절대경로만 전해 주거나, 아니면 상대 경로를 쓸 거면 아예 별도의 프로세스를 만들어서 돌리게 해야 한다.

그런데 여기서 한 가지 의문이 생긴다. 각 드라이브별로 직전까지 작업하던 디렉터리 정보가 운영체제 차원에서 자동으로 보존될까, 그렇지 않을까?

드라이브별 커런트 디렉터리란, 위의 예에서 C에서는 Windows가 보존되고, D에서는 doc가 보존되는 것을 말한다.

그런데 정답부터 말하자면 그건 운영체제가 일일이 자동으로 기억하고 챙겨 주지 않는다.
당장 탐색기나 파일 열기 대화상자의 주소창에서 c: 나 d: 라고만 달랑 쳐 보아라. 이 경우 언제나 해당 드라이브의 루트 디렉터리로만 가지, 명령 프롬프트일 때처럼 직전에 해당 드라이브에서 마지막으로 살펴보던 디렉터리를 기억하지 않는다. 오히려 명령 프롬프트가 예외적으로, 유일하게 그걸 별도로 지원해 주고 있다.

그럼 질문의 초점이 이렇게 바뀔 것이다. 명령 프롬프트만 왜 그러는 걸까?
물론 명령 프롬프트는 GUI와 달리 '뒤로' 같은 버튼이 없으니 디렉터리를 기억해 주는 게 사용자의 입장에서 편리하다. 그리고 더 큰 이유는 먼 옛날 MS-DOS와의 호환을 위해서이다.

MS-DOS의 최초 버전인 1.0은 무려 1981년에 출시되었으며, 얘는 파일 시스템에 디렉터리라는 개념을 지원하지 않았었다. 즉, 모든 디스크는 루트 디렉터리만 존재했으며, 파일 이름에 (역)슬래시 기호가 들어갈 일이 없었다.

마치 Windows 1.0이 프로그램 창을 겹치게 배열하는 게 지원되지 않았던 것과 동급으로 정말 믿어지지 않는다. (뭐, 기술적인 한계 때문은 아니고, 애플 사와의 특허 분쟁을 피해 가느라 일부러 기능을 cripple시킨 것이지만) 1980년대 초의 열악한 컴퓨터는 무슨 매체든 디스크의 공간이 상상하기 힘들 정도로 작고 좁았으니 굳이 디렉터리 계층 구조의 필요가 존재하지 않았던 듯하다.

그러다가 DOS 2.0부터는 드디어 파일 시스템 차원에서 디렉터리가 도입됐다.
그런데 DOS 1.0용으로 개발된 프로그램은 디렉터리라는 걸 전혀 인식하지 않고 역슬래시 문자도 아예 사용하지 않으니 2.0에서 루트가 아닌 다른 디렉터리에 있는 파일을 읽고 쓸 방법이 없다.

그러니 이 문제를 최대한 호환성을 존중하며 해결하기 위해, :￦로 시작하지 않는 경로는 이제부터 상대 경로로 간주시켰다. 그리고 각 드라이브별로 커런트 디렉터리라는 개념을 도입하여, 상대 경로는 루트 고정이 아닌 커런트 디렉터리에 있는 파일에 접근하는 것으로 정책을 바꿨다. 운영체제가 일종의 state machine 역할을 대신해 주는 셈이다.

Windows는 앞서 살펴보았듯이 모든 드라이브를 통틀어서 단일 current directory만 관리하지 DOS처럼 동작하지 않는다. 단지 명령 프롬프트에서는 특수한 환경변수를 운용해서 사용자가 돌아다닌 디렉터리를 드라이브별로 추적하여 도스의 동작을 흉내 내 준다. 이건 물론 오늘날까지도 전적으로 호환성 차원에서 해 주는 것일 뿐이다. the old new thing 블로그를 보면 더 자세한 설명을 볼 수 있다. 환경변수를 사용하는 이유는 이 프로세스로부터 새로 실행된 child 프로세스에게까지 current directory 변경의 여파가 자동으로 이어지게 하기 위해서라 한다.

“타 드라이브의 current directory”라니, 지금까지 한 번도 진지하게 생각해 본 적이 없었는데.. 굉장히 흥미로운 사실을 알 수 있었다. 예전에 Windows 9x에서 존재하던 CD ... (점 3개 이상)처럼 뭔가 호환성과 관련된 사연이 있었던 것이다.

1.
컴퓨터에서 옛날에는 하나밖에 없는 게 당연하다고 여겨졌으나 나중에는 여러 개 존재할 수도 있게 된 것의 예로는 디렉터리뿐만 아니라 CPU 코어(멀티코어!)라든가 모니터(최소한 듀얼..)도 해당되지 싶다.
그러니 하나밖에 인식을 안 하는 소프트웨어에 대해서는 무조건 붙박이가 아니라 현재 default로 지정되어 있는 것 하나를 기준으로 동작하게 운영체제가 샌드박스 처리를 잘 해 줘야 할 것이다.

하드웨어 말고 소프트웨어적인 요소 중에서도 클립보드 같은 건 운영체제 API 차원에서 다변화될 가능성이 있다. 그것 말고는... 설마 한 컴퓨터에 마우스 포인터 같은 게 둘 이상 존재할 일이 있을지는 모르겠다.
마우스 말고 터치스크린은 여러 손가락이 동시에 눌러질 수 있다. Windows 98에서 멀티모니터 지원이 최초로 도입됐다면 Windows 7부터는 멀티터치 지원 기능이 최초로 추가됐는데, 본인은 지금까지 멀티터치 관련 기기나 API를 접할 일이 전~혀 없었다. 문자 입력과도 분명 연계가 가능할 텐데 그쪽으로 연구할 기회가 없었다.

2.
그러고 보니 시스템 전체 차원에서의 current 설정 vs 특정 항목별 current/default 설정이라는 양대 구도는 Windows의 IME에서도 동일하게 찾아볼 수 있다.
Windows에서 돌아가는 모든 UI 스레드들은 어떤 입력 언어/로케일과 연결돼 있다. 이것은 영어 드보락, MS 일본어 IME, 날개셋 등등 중 하나로.. 키보드 드라이버, IME/TSF 모듈을 모두 통합하는 개념이다.

각 스레드들이 서로 다른 입력 언어와 연결 가능하지만(Alt+Shift, Ctrl+Shift, 또는 도구모음줄 클릭), 어떤 스레드가 새로 생성되었을 때 맨 처음 기본으로 지정되는 'default 입력 언어'라는 건 따로 있다. 이건 제어판에서 변경 가능하다. 이게 디렉터리로 치면 current directory에 가깝다.

그런데, 사실은 한국어, 중국어, 일본어 등 각 언어별로도 말 그대로 default 입력 언어가 있다. 한 언어에 속하는 IME들이 여러 개 있을 때, 사용자가 Alt+Shift로 언어만 그걸로 전환하면 그 언어의 default IME에 속하는 놈이 기본 선택된다. DOS에서 존재하던 드라이브별 current directory처럼 말이다.

내 경험상 전체 default IME라든가, 언어별 default IME 같은 건 프로그래밍을 통해 알아 내거나 변경하는 뾰족한 방법이 없다. MSDN을 뒤져 보면 비슷한 기능을 하는 API가 있긴 하지만 current, active, default 등 용어도 혼란스럽고 기능들이 문서화된 대로 정확하게 동작하질 않는다. 더구나 Windows 8부터는 Win+Space를 통해 IME들을 언어 구분 없이 한 리스트에서 쭉 고르게 UI가 바뀌어서 언어별 default IME라는 건 개념이 굉장히 모호해지기도 했다.

이 방식은 운영체제에 설치된 입력기가 적을 때는 깔끔하지만 10개 가까이 많아지면 화면이 굉장히 난잡해진다. 언어별로 구분하는 Windows 7 이하 기존 방식도 여전히 필요하다고 생각된다.

Posted by 사무엘

1. 나랏말씀

이런 프로그램이 과거에 개발되어 나왔다는 것을 머리로는 알고 있었지만, 인터넷에 굴러다니는 걸 구해서 도스박스에서 개인적으로 직접 돌려 본 건 굉장히 최근의 일이었다.
얘는 개발 목표와 이념이 완전히 일치하는 건 아니지만, 어찌 보면 날개셋 편집기의 먼 조상뻘 되는 프로그램이라 해도 과언이 아니다.

그리고 얘는 시대를 굉장히 앞서 갔던 프로그램이다. 1993~94년 사이에 개발됐는데 무려 유니코드 1.1 방식 옛한글을 세벌식 글자판과 글꼴로 입· 출력하는 텍스트 에디터이기 때문이다. 비록 에디터로서의 기능은 매우 빈약하고(찾기 기능도 없다!) 글자 모양도 심히 열악하지만 그래도 모아쓰기 출력과 글자 단위 cursor 이동 같은 최소한의 처리는 옳게 지원된다.

예문으로 훈민정음 서문이 포함돼 있다. 방점도 자형 자체는 있지만 오늘날 OpenType 규격처럼 글자의 뒤에다가 쳐 넣으면 글자의 왼쪽에다 알아서 찍어 주지는 않는다.

그 옛날에 국내에서는 겨우 2바이트 조합형이니 완성형이니 하면서 논쟁이 진행 중이었을 뿐, 유니코드를 아는 사람은 일부 극소수 계층 말고는 없었다. 대다수 사람들에게 유니코드는 최소한 2.0이 제정되고 나서 Windows 98 이후의 시간대는 돼서야 갑자기 툭 튀어나온 물건이다.

하물며 지금 같은 인터넷도 없고 "유니코드가 뭐야? 먹는 거야? 주변에 지원하는 프로그램도 아무것도 없구만?" 이러던 초창기였으니.. 이 프로그램은 서식이나 레이아웃 기능이 없는 텍스트 에디터임에도 불구하고 저장한 파일을 읽을 수 있는 프로그램이 사실상 자기 자신밖에 없었다.

이건 평범하게 터보 C 공부한 어느 똑똑한 대학생이 뚝딱 만들어서 PC 통신에다 올릴 만한 물건은 아니고, 사실은 부산 대학교 김 경석 교수 연구실에서 개발해서 배포한 프로그램이다. 지도교수는 그 당시 유니코드 위원회의 우리나라 대표였고, 동료 학자들과 함께(아마 국어학자들과도..) 문헌을 뒤져서 옛한글 자모들을 선별했으며 <컴퓨터 속의 한글 이야기>라는 책을 쓰기도 했다. 이 프로그램은 그 책의 부록 디스켓에 포함돼 있다.

물론, 프로그램의 실제 개발은 제자인 대학원생이 했다. 프로그램 개발자들은 다들 부족한 시간과 여건 속에서 코딩을 하는 편인데, 이 프로그램은 의외로 화면 비주얼은 신경을 썼는지 VGA 기본 팔레트가 아니라 연보라색 계열의 자체 색상을 쓰고 있다.

완성된 글자들의 모양은 볼품없지만, 이미 찍힌 낱자의 모양이 입력 도중에 다른 성분의 낱자에 의해 바뀌지 않기 때문에 뭔가 타자기를 쓰는 것 같다. 세벌식 글자판에다 세벌식 글꼴의 묘미를 제대로 경험할 수 있다. 더구나 이 프로그램에서 최초로 채택한 '세벌식 옛한글' 글쇠배열은 오늘날까지 아래아한글이나 날개셋이 그대로 계승하고 있기도 하다.

유니코드 1.1 옛한글 자모 집합은 그 전 1992년에 발표된 아래아한글 2.0이 사용하는 한컴 2바이트 코드에도 반영된 바 있다. 하지만 아래아한글은 아직 2바이트 완조형에 묶여 있었기 때문에 옛한글의 표현 능력이 온전하지 못했다.

굉장히 의외의 사실인데, 이 프로그램은 텍스트를 빅 엔디언 방식으로 저장한다. 다시 말해 UTF-16BE라는 것이다. LE가 아니라. (물론 저 당시에는 UTF라는 계층은 존재하지 않았기 때문에 UCS2만 있음)
저기서 입력하고 저장한 텍스트는 MS Word처럼 UTF-16BE를 지원하는 소수의 프로그램에서 인코딩을 수동으로 지정해 줘서 연 뒤, 날개셋 편집기에서 한글 형태 정규화를 해 줘야 오늘날 통용 가능한 텍스트 형태로 바뀐다. 저 프로그램이 개발되던 시절에는 지금 같은 U+AC00으로 시작하는 현대 한글 글자마디 11172자가 아직 없었다. byte order mark 같은 것도 없었다.

한편, 나랏말씀은 옛날에 만들어진 프로그램이지만 문서 저장 확인 질문의 Yes/No가 "예/아니오"가 아니라 "예/아니요"인 게 인상적이었다. 그 시절에 본인은 '아니요'를 그 어떤 프로그램의 UI에서도 보지 못했다. 표준어가 나중에 개정되기라고 했나 싶었는데, 그건 아니고 '아니오'가 오랫동안 컴퓨터 프로그램들 사이에서 잘못 내려온 관행이라고 한다.
아래아한글은 2002부터, Windows은 Vista부터 '아니요'로 바뀌었다. 단, 요즘 프로그램들은 대답 자체에 '저장함/저장 안 함'처럼 동작을 일일이 집어넣는 게 대세가 되어 가다 보니 간단한 "예/아니요"를 볼 일이 예전보다 드물어져 있다.

나랏말씀 같은 프로그램이 있다는 걸 내가 더 일찍 알았으면 날개셋 한글 입력기도 한컴 2바이트 코드 같은 걸 거칠 필요 없이, 3.x보다 더 이른 1이나 2.x 버전부터 유니코드 옛한글 기반으로 개발됐을지 모르겠다.
내 프로그램이 1990년대 초· 중반에 개발돼 나왔으면 도스를 겨냥해서 자체한글 텍스트 에디터(편집기) 내지 도스용 한글 바이오스(외부 모듈), 혹은 간단한 램 상주 키보드 훅킹 유틸(입력 패드) 형태로 나왔지 싶다. 흥미로운 상상이 아닐 수 없다. 아예 한글 Windows용 3rd-party IME나 영문 Windows를 통째로 한글화하는 시스템은 만들기 너무 어려웠을 것 같고.

비록 내 프로그램은 기본적인 한글 입출력 인프라는 운영체제 차원에서 다 갖춰지고 보장된 뒤에야 개발되어 나왔지만, 그래도 기성 IME들이 지원하지 않는 기능들이 매우 많으며 구현체 차원에서도 Windows IME의 온갖 지저분한 꼼수 동작들을 이 정도로 보정하는 3rd-party IME라는 존재 역할을 수행하고 있다.

2. 신의손

본인은 한글 IME/텍스트 에디터뿐만 아니라 고유한 타자연습 프로그램도 개발하고 지금까지 유지보수 중이다.
타자연습을 처음 개발하던 시절에는 당연히 그 당시 국내에 이미 나와 있던 다른 타자연습 프로그램들을 먼저 쭉 살펴보면서 벤치마킹을 했다.

그런데 그 중 압도적으로 높은 완성도로 제일 잘 만들어진 프로그램을 꼽자면.. 단연 '신의손'이었다. 지금까지도 이 생각은 변함없다.
20년 전 하이텔 게임 제작 동호회 공모전에서 '삭제되었수다'가 혼자 튀면서 압도적인 1등을 했듯이, 타자연습 프로그램 중에서는 신의손이 지존이었다고 개인적으로 생각한다.
상업용 내지 셰어웨어로 만들어도 됐을 퀄리티였다.

디자이너가 따로 없이 1인 개발자의 해골만으로 VGA 16색에서 어지간한 게임에 준하는 저 정도의 미려한 그래픽과 UI를 만든 거라면 정말 보통 실력이 아니다.
게임도 스토리나 설정 같은 게 센스가 철철 넘지고.. (신 중의 신 고무신 ㄲㄲㄲ)
내 경험상 16컬러에서 팔레트를 자체적으로 조작해서 자기만의 독자적인 색깔톤을 만들 정도의 프로그램이라면 비주얼에 신경을 꽤 쓴 프로그램이다. 예전의 도스용 Packard Bell desktop 셸처럼 말이다.

(보통은 저런 파란 톤이지만 최고 어려운 마지막 난이도에서는 화면이 전반적으로 시뻘건 톤으로 바뀐다. 우와~!)
도스용이지만 그래도 나온 때가 1995년이다 보니, 보다시피 Windows에서 그 퍼런 키보드 배경 그림(95에서만 존재하던!)과 각종 아이콘과 굴림체 글자를 따서 도스용 프로그램에다 접목한 것도 꽤 독특한 분위기를 만들어 냈다.
식상한 윗줄 따라 치기 말고 좌우/상하 대조 같은 연습 방식을 도입한 것도 얘가 원조였지 싶다.

손가락 모양의 포인터로 각종 버튼과 UI 요소들을 선택하는 GUI 비주얼을 자랑하면서 정작 마우스를 지원하지 않은 건 조금 의외였다. 허나, 키보드 뚜드리는 연습만 하라고 만들어진 프로그램이 굳이 마우스까지 지원할 필요는 없긴 하지..

신의손의 개발자는 백 승찬 씨로 알려져 있다. ('신자'이신 분은 옹기장이 백 승남 씨와 혼동하지 말 것.)
이분은 정말 진지하게 게임 개발자로 가도 되지 않을까 생각했는데..
근황을 검색해 보니.. 아아~ P2P 유틸인 프루나도 만들었으며 2010년대부터는 이미 모바일로 전향하여 어썸노트라는 앱을 개발해서 여전히 1인 기업 하고 계신다.

신의손은 그냥 대학교 재학 시절에 만든 것인데, 그 프로그램을 상업용으로 판매하려고 유통처를 알아보고 고생도 했다고 한다. (그러나 현실적인 한계에 부딪혀서 실제로 하지는 못했음)
내가 겨우 날개셋 2.x 갖고 깨작거리던 나이 때 벌써 저런 프로그램을 만들 정도였으니 지금은 뭘 못하겠냐..;;
나는 17년 전이나 지금이나 최소한 플랫폼과 외형은 진~짜 바뀐 거 없는 투박하고 공대감성 충만한 프로그램만 죽어라고 파고 있는걸. ㄲㄲㄲㄲㄲ

세상 참 많이도 바뀌었다. 창의적인 일을 하는 모든 분들에게서 경외감을 느끼는 하루이다.

그러고 보니 옛날 프로그램들 중에는 메뉴를 열어 놓은 상태에서도 단축키가 곧장 동작하는 것들이 있었다. 당장 떠오르는 예는 도스용 아래아한글, PowerBasic IDE처럼.
Windows의 기본 UI는 구조적으로 이게 전혀 지원되지 않고 그 대신 메뉴 자체의 액셀러레이터만이 동작하게 돼 있다.
어디서든이 단축키가 동작하는 게 편하긴 한데 그래도 지금은 바뀐 프로그램에 사용자가 적응해야 할 때이긴 하다.

Posted by 사무엘

1. 외부 모듈 핵심부의 EXE 분리

오래 전부터 조금씩 풀었던 썰이긴 한데, 마침 최근에 회사에서 유사 개발 업무를 한 적도 있고 해서 다시 얘기를 꺼내 보겠다.
Windows는 타 OS들과는 달리 IME가 EXE가 아닌 DLL 형태이다. 한 프로세스의 주소 공간에 완전히 속해 있는 덕분에 성능이 좋다는 장점이 있겠지만, 한영 상태가 스레드들마다 제각각 따로 놀고 거기에다 memory-mapped 방식으로 로딩된다는 특성까지 겹쳐서 IME의 on-the-fly 업데이트가 몹시 난감하다.

EXE라면 업데이터 하나 띄워서 자신을 종료한 뒤 업데이트 된 놈으로 재시작만 하면 간단하게 끝났을 일인데 Windows용 IME는 업데이트 하려면 자신을 사용하는 프로그램들을 몽땅 종료해야 하고, 그게 여의치 않으면 그냥 운영체제를 재시작/로그오프 해야 한다. 거기에다 32/64비트까지 모두 신경 써야 한다.

그래서 <날개셋> 한글 입력기 외부 모듈도 인제 와서 처음부터 다시 만드는 건 무리이겠지만, 앞으로 덩치 큰 IME를 만들 일이 있으면 DLL은 거의 업데이트 할 일 없는 껍데기만 남겨 놓고 실질적인 문자 조합은 EXE 기반의 '서버'에 담당시키면 어떨까 생각을 해 왔다. 업데이트도 IME가 통신하는 EXE만 하고 말이다.

이렇게 하면 모든 IME들의 설정과 상태 동기화는 자동으로 이뤄진다. 서버와는 함수 호출이 아니라 메시지와 memory-mapped file 같은 간접적인 방법으로 통신을 하니 서버는 굳이 바이너리 구분을 할 필요 없다. 64비트 OS에서는 64비트 서버 하나만 띄워 놓으면 32비트와 64비트 IME가 모두 통신이 가능하니 더욱 좋다.

실제로 실험용 IME를 만들어 본 결과는 흥미로웠다. 서로 다른 프로세스끼리 메시지를 주고받을 때는 단일 스레드끼리 메시지를 주고받을 때에 비해 고려해야 할 점이 더 많았다. 받는 쪽에서 자체적으로 대화상자 같은 걸 출력하고 그 상태로도 자체 메시지를 처리하지 못하는 block 상태가 되지 않으려면 대화상자는 modal이 아니라 반드시 modeless 형태로 만들어야 했다.

SendMessage와 PostMessage를 조심해서 가려 써야 하며, 리턴값을 꼭 받기 위해 Send를 하면서도 신속한 반응성을 보장하기 위해서는 지금까지 머리로만 알고 있던 ReplyMessage 같은 함수를 난생 처음으로 써 보기도 했다. 특히 호스트가 클라이언트로부터 Send된 메시지를 받은 뒤에 대화상자 같은 modal UI를 띄운다면 말이다.

여기까지 생각을 하긴 했으나.. IPC 기법들은 근본적으로 IME들이 쓰라고 만들어진 메커니즘이 아니다 보니 한계도 많다.
가장 먼저 권한 문제가 걸리니, IME 서버는 번거롭게 관리자 권한으로 실행하거나 아니면 애초에 운영체제의 서비스 같은 급으로 만들어야 한다. 메트로와 데스크톱 앱 사이의 소통도 문제이고..
IME가 글쇠 입력을 받은 것을 서버로 요청을 보내는 건 그럭저럭 할 만하나, 반대로 서버가 IME로 문자 입력 요청을 하는 것은.. IME가 제각각 스레드 동기화 오브젝트나 윈도우를 만들어야 가능할 것이다.

서버는 자신과 접속하거나 종료하는 클라이언트들을 파악하고 있어야 하는데 자고로 프로세스라는 건 강제 내지 비정상 종료될 때도 있다. 그렇기 때문에 모든 프로그램들의 근황을 언제나 정확하게 파악하고 있는 것도 훅킹이라도 동원하지 않으면 의외로 쉽지 않더라.

이것저것 가성비를 생각해 보니 서로 장단점이 있고 근본적으로 한 방식이 다른 방식을 완전히 대체 가능해 보이지는 않았다. 안 그래도 날개셋의 경우 EXE 기반의 입력기 개발 실험은 입력 패드를 만들면서 이미 그럭저럭 하기도 했다. Windows에서 어떤 DLL이 타 프로세스에 합법적으로 침투할 수 있는 양대 통로는 미우나 고우나 훅킹 아니면 IME이다.

다만, 지금 MS 일본어 IME가 이미 그런 것처럼 제어판 대화상자만은 EXE로 분리하는 게 나은 점도 있다.
실행되는 응용 프로그램에 따라서는 공용 컨트롤.. 특히 6.0 이상에서만 지원되는 syslink나 split button, 에디트 컨트롤의 풍선 도움말(cue banner) 같은 게 초기화되지 않은 경우가 종종 있어서 내 날개셋 제어판도 그거 영향을 받아 제약을 받기도 하기 때문이다.

뭐 그건 그렇고..
기존 데스크톱 앱인 '제어판' 말고 메트로 앱인 '설정'에서 돌아가는 환경설정은 어떻게 만드는지 모르겠다. MS 한글 IME에는 그런 게 있던데..;;

2. 설치 시스템 개편

예전에도 여러 번 언급한 바와 같이, <날개셋> 한글 입력기는 Visual Studio가 기본 제공하는 Windows Installer 기반 msi 패키지 형태로 배포되고 있다. 이 솔루션은 MS 본가에서 만든 만큼, 프로그램을 설치하거나 제거하는 본연의 성능은 일정 수준 이상의 퀄리티가 보장된다. 프로그램 디렉터리 어딘가에 uninstall stub 프로그램 같은 게 덕지덕지 붙어 있을 필요도 없고 아주 seamless + 깔끔하다. 하지만 개발툴이 제공하는 GUI 템플릿은 customize가 매우 제한적이고 불만족스러운 점이 많기 때문에 다른 솔루션을 써 볼까 생각도 자주 해 왔다.

이상적인 설치/배포 솔루션은 다음과 같은 조건을 만족해야 한다. 다른 프로그램이라면 몰라도 <날개셋> 한글 입력기에 대해서는 내가 보다시피 욕심이 좀 많다.

1. CPU 통합: 한 exe 파일 단독으로 32비트와 64비트 OS에서 잘 동작하고, 32비트에서는 당연히 64비트 바이너리를 설치하지 않아야 한다. EXE처럼 32/64비트 중 사용 가능한 상위 바이너리 하나만 설치하면 되는 파일은 선별이 옳게 돼야 한다. 필요한 디스크 공간 계산도 이 모든 변수를 감안해서 돼야 한다.
2. 언어 통합: 한 exe 단독으로 운영체제의 기본 언어가 한국어이면 한국어, 그렇지 않으면 자동으로 영어로 설치 프로그램의 UI가 출력되어야 한다.
3. 유니코드 통합: 평상시에 유니코드 API를 사용하는 건 너무 당연한 얘기이고, 그럼에도 불구하고 구닥다리 Windows 9x에서도 유니코드만 포기하고 기본적인 실행이 돼야 한다. 이것도 물론 단일 파일로 말이다. <날개셋> 한글 입력기 본제품이 Windows 95/NT4부터 꼬박꼬박 다 지원하는 프로그램이기 때문이다.
4. known 폴더: 또한 아무 액세서리 없는 깡통 Windows 95 RTM에서 실행되더라도 IE 4~5 이상에서 첫 도입된 ProgramData (Application Data)같은 known 디렉터리를 인식해서 파일을 제 위치에 설치해야 한다.
5. 원활한 제거: Windows용 IME는 그 특성상 on-the-fly로 업데이트나 제거가 꽤 난감한 물건인데, 당일 제거를 못 했으면 재부팅 요청 같은 후처리를 적절히 수행해야 한다.
6. 그 밖에: 관리자 권한 드립 치는 UAC 화면은 setup을 실행하자마자 뜨는 게 아니라, 실제로 설치가 시작되어 관리자 권한이 정말로 필요해졌을 때 직전에 뜨는 게 바람직함.

진짜 유명한 세계구급 소프트웨어인 경우, 설치 프로그램이 언어를 선택받는 대화상자부터 띄우는 경우가 있다. 하지만 날개셋의 경우 그렇게 유명한 물건은 아니니 그냥 운영체제의 기본 GUI 언어가 한국어가 아닐 때에만 영어로 동작하는 걸로도 충분할 듯하다. 날개셋은 GetSystemDefaultLangID() 함수를 써서 판별하는데, 이게 GetUserDefaultLangID와 차이가 무엇이 있는지는 개인적으로 궁금하다.

msi는 (1)과 (2)는 전혀 만족하지 않는 것으로 보여서 문제다.
그러나 (3)과 (4)는 Windows installer runtime (non-Unicode 9x용 에디션)자체만 미리 설치하면 그럭저럭 어렵지 않게 충족된다. 2.0 런타임은 의외로 깡통 Windows 95에서도 깔끔하게 설치 가능하다. 이것 때문에 <날개셋> 한글 입력기가 MSI 외에 다른 배포 솔루션으로 갈아타기가 어렵다.

"HKCU 또는 HKLM"\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders라는 레지스트리를 참조하면 known 폴더 위치를 얻을 수 있다. MSI가 이런 것까지도 생성해 준다. 이렇게 레지스트리를 수동으로 뒤지는 방법은 오늘날에는 마소에서 권장하지 않는 방법이지만, The old new thing 블로그의 설명에 따르면 아직도 여기를 참조하는 고집쟁이 옛날 어플 때문에 어쩔 수 없이 호환성 차원에서 레지스트리를 계속 지원해 주는 거라고 한다. 사실, IE 4~5가 없고 SHGetSpecialFolderPath 함수가 존재하지 않는 골동품 Windows 95 환경에서는 여기를 뒤지는 것밖에 선택의 여지가 없기도 하다.

다음으로 (5)의 경우 msi는 딱 기본만 수행한다. "다음 프로그램들이 요 DLL을 사용하고 있습니다" 대화상자도 찍어 주고, 뭔가 못 건드린 파일이 있으면 "재부팅 하시겠습니까?"라는 여운을 남기기도 하는데, 가끔은 안 그럴 때도 있는 듯하다.

msi 말고 3rd party installer 중에서는 오픈소스이기도 한 NSIS가 세계적으로 제일 유명하다. WinAmp는 역사 속으로 사라졌고 개발사인 Nullsoft도 없어졌지만, 그래도 NSIS만은 유용성 덕분에 오픈소스 진영에서 살아남아 있다. Nullsoft의 개발자들이 왕년에 불멸의 작품 하나로 이름을 남겼다.

얘는 어떤가 하면..
(1)과 (2)는 기술적으로 일단 가능하다. msi보다 분명 우월한 점이다. 그러나 그냥 '가능하다'에서 끝일 뿐, 막~ 적극적으로 지원되고 깔끔하고 편한 형태로 가능하지는 않아 보인다.

단적인 예로, 생성되는 installer에 붙는 런타임 바이너리가 기본적으로 32비트 기반이다 보니, 거기 스크립트 언어에서 기본 제공하는 등록 명령만 이용해서는 64비트 DLL에 대해서 DllRegisterServer(시스템 등록) 호출을 할 수 없다. 뭐, 운영체제가 제공하는 regsvr32 /s를 이용하면 되긴 하지만, 사용자가 직접 저렇게 외부 유틸리티나 플러그 인을 끌어들일 필요 없이 NSIS가 내장 명령어 차원에서 저걸 지원하면 더 좋을 것이다.
홈그라운드 운영체제의 지원빨이 있는 msi에서는 반대로 DLL의 등록쯤은 전혀 걱정할 것 없는 사항이다. 64비트용 msi라면 64비트 DLL이건 32비트 DLL이건 불문하고 등록이 깔끔하게 잘 처리되기 때문이다.

(3)은 NSIS가 한동안 정식으로 지원하지 않아서 Unicode NSIS라는 별도의 프로젝트 브랜치가 나돌 정도이다가 비교적 최근에 NSIS가 3.x 버전에 진입하고 나서야 유니코드를 정식으로 수용하게 됐다.
그러나 NSIS는 기술 수준이 그냥 이미 있는 Windows API를 감싸는 정도를 벗어나지 않기 때문에 유니코드와 Windows 9x를 동시에 지원한다거나, 구버전 OS에서 신버전의 known 디렉터리를 만들어 주는 정도의 과잉 친절을 베풀지는 않는다.
(5)의 경우는 NSIS가 어디까지 자비롭게 대처하는지 아직 제대로 확인을 못 해 봤다.

요약하면, 완전한 스크립트 기반인 NSIS가 당장 자유도가 뛰어나 보이기는 하지만, 그래도 레거시 운영체제 지원이나 시스템 차원에서의 융통성은 그래도 msi가 나은 게 있어서 한 솔루션이 다른 솔루션을 완벽하게 대체하지는 못하는 실정이다.
NSIS의 스크립트는 무슨 파이썬이나 Lua 급으로 복잡한 연산식이나 복합 자료구조를 지원하는 본격적인 고급 언어가 아니다. 스크립트의 문법은 반쯤 어셈블리어에다가 C언어의 전처리기를 얹은 것 같은 구조이며 생각보다 제약이 많다.

어셈블리어 같은 문법인데 CPU 인스트럭션이 들어가는 게 아니라 Windows API의 함수와 각종 속성 명칭이나 상수들이 들어간다는 점만 다르다. if-then-else, switch 같은 조건 판단과 분기조차도 언어의 키워드가 아니라 그냥 분기문을 표현하는 매크로 형태로 구현되었을 정도이다.
그나저나, 파일 경로를 많이 다루고 역슬래시를 필연적으로 많이 쓴다는 특성상 \ 자체는 탈출문자로 쓰지 않고 $를 붙여서 $\n으로 개행문자를 표현하는 건 인상적이었다.

설치 스크립트도 당장 필요한 기능만 주먹구구식으로 구현하는 게 아니라 치밀하게 잘 만들려면 끝이 없겠다.

• 한 스크립트로 몇몇 스위치만 달리하여 동일 제품의 여러 파생형이나 변형 에디션(가령, 셰어웨어 데모/정식 같은)을 조건부 컴파일로 간단히 감당 가능
• 한 제품에서는 아까 말한 언어와 아키텍처를 단일 출력 바이너리만으로 모두 커버 가능
• 모든 문자열 값들은 언어 중립적인 값과 언어 종속적인 값으로 나눠서 관리 가능하고, 제품 이름 같은 건 한 곳에서 값을 바꾸면 등장하는 모든 곳에서 값이 알아서 바뀌어야 함
• 컴퓨터의 상태 파악을 알아서 해야 함. 처음 실행됐을 때 지금이 첫 실행인지, 동일 버전, 구 버전, 또는 동일 버전의 바리에이션이 이미 설치돼 있는지, 이전에 설치를 하다가 만 상태인지, 심지어 자신이 중복 실행됐는지 같은 걸 사용자가 수동으로 파일이나 레지스트리 삽질 안 해도 알아서 감지해야 함
• 설치할 파일과 삭제할 파일을 NSIS는 수동으로 일일이 써야 하는 것 같던데, 마치 C++ 개체 선언하듯이(생성자, 소멸자) 설치하는 파일, 추가하는 레지스트리 같은 걸 한 곳에다만 명시하면 역순의 제거 작업 역시 자동으로 파악돼야 하며, 작업을 실제로 수행하기 전에 예상 디스크 공간 계산 같은 것도 알아서 돼야 함.
• 서로 다른 소프트웨어 제품이 동일한 파일을 설치하고 사용하는 경우, 그런 공용 파일은 reference counting을 해서 그 제품들이 모두 제거되었을 때에만 최종적으로 삭제되게 해야 함.
• 그리고 uninstall 시엔 사용자가 생성한 데이터처럼 이 프로그램이 초기에 설치하지 않은 파일이나 레지스트리도 필요하다면 싹 제거하는 메커니즘이 제공돼야 함. (조건 범위 지정)
• 최종 생성된 msi 내지 exe 파일에 대한 디지털 서명 후처리도 언어 내지 툴 차원에서 명시해서 자동 처리하기.

오픈소스 프로젝트에 기여한 것도 없는 주제에 불평만 길게 늘어놓은 것 같다만.. 이게 NSIS를 좀 써 보고 개인적으로 느꼈던 아쉬운 점이다. 오죽했으면 반디소프트에서 개발하고 있는 유명 파일 압축 유틸리티인 반디집도 6.0부터는 NSIS 대신 자체 개발한 인스톨러로 갈아탔다. 다만, NSIS는 저 정도 꽤 적지 않은 기능을 제공하고도 exe에 붙는 자기 런타임 stub 크기가 겨우 몇만 바이트에 불과할 정도로 작은 건 굉장히 인상적이었다.

그냥 간단한 파일 몇 개만 복사하고 끝나는 게 아니라 컴퓨터를 좀 깊게 제어하는 설치/제거 패키지를 만든다면 이걸 만드는 툴도 GUI 위주의 가벼운 툴이 아니라 그냥 핵심 기능만 SDK 형태로 만들고, 자주 쓰는 프로그램 패턴은 Visual C++의 프로젝트 마법사 형태로 구축하는 것도 나쁘지 않을 것 같다. 배포 패키지 자체를 그냥 C/C++로 만들라고 말이다. 그러면서 파일 압축 풀어서 복사하거나 지우는 등의 정말 핵심적인 공통 기능만 라이브러리를 쓰라고..

근데 생각해 보니 애시당초 그러라고 만들어진 라이브러리가 Windows Installer이긴 하다. 쟤도 사실은 단순 GUI 껍데기가 아니라 라이브러리가 본질이니까. 하지만 저 라이브러리도 구조가 워낙 복잡하고 설치, 제거, 롤백이 어떻고 알아야 할 사전 배경지식이 많다 보니 그 저수준 함수를 직통으로 쓰면서 배포 패키지를 만들 일이라곤 없을 듯하다.

Posted by 사무엘

* 과거 내지 현재의 컴퓨터와 관련하여 개인적으로 궁금한 것들 컬렉션이다.

1.
요즘 길거리나 건물 근처에서 쏘는 와이파이를 보면 처음에 접속하는 건 암호가 없는 public 형태이지만, 접속한 뒤에는 무슨 주소를 입력하더라도 로그인/요금 결제 페이지로만 포워딩되는 형태인 것들이 많다. 사실은 학교 와이파이도 보안 ActiveX 등등을 안 깔면 설치 요구 페이지로만 연결된다.

그런데 이 상태에서도 페이스북이나 유튜브에 접속하는 건 바로 되는 경우가 종종 있다. 얘들만 교신을 하는 방법이나 프로토콜이 달라서 그런지(https라든가.. 서버가 외국에 있어서?) 무슨 이유 때문인지는 모르겠다.

사실, 웹서버가 뭔데 내 컴퓨터의 운영체제와 브라우저라면 몰라도(http 헤더에 에이전트 정보가 들어가므로), 보안 솔루션의 설치 여부는 뭘 보고 판단하는지 모르겠다. 프록시인지 뭔지를 써서 warning.or.kr를 우회해서 각종 금지 사이트에 접속하는 것도 어떻게 하는지? 난 웹 쪽은 아는 게 거의 없음. 그 바닥은 너무 골치 아프다.

2.
디카나 폰을 PC에다 연결했을 때 보통은 여느 USB 메모리를 꽂은 것처럼 드라이브 문자가 하나 더 추가되고 해당 기기의 메모리 내부 파일 시스템에 접근이 가능해진다.
그런데 어떤 건 꽂으면 뭔가 파일 시스템이 생기기는 하는데 드라이브 문자가 추가되는 형태가 아니다. 여기는 탐색기로만 접근 가능하지, 어지간한 다른 프로그램에서 파일을 바로 열고 내용을 볼 수 없다. 하드디스크에 복사한 뒤에야 내용을 확인할 수 있다.

그러니 사용자의 입장에서는 불편한데, 오히려 더 나중에 등장한 디카나 폰이 PC와 연결됐을 때 더 이러는 경향이 있다.
이건 기술적으로 무슨 규격이나 프로토콜을 써서 동작하는 건지 모르겠다. 그리고 드라이브 문자가 추가되는 것보다 무슨 장점이 있어서 저렇게 동작하는지도 모르겠다. 혹시 보안?

3.
컴퓨터의 USB 포트에 어떤 기기를 연결하면 인식이 곧장 될 때가 있지만 "인식 실패" 에러가 뜨면서 잘 안 될 때도 있다. 폰이나 USB 메모리 부류 말고 외장 하드 같은 묵직한 물건은 전력이 부족해서 안 될 때도 있다. 이런 건 (1) 컴퓨터, (2) 케이블, (3) 해당 기기 중 어느 게 문제인 걸까..?
컴퓨터라는 건 절대적으로 확실하고 예측 가능한 결과만 나오는 물건일 텐데, USB 포트만은 뭔가 상황에 따라 복불복인 결과가 나오는 면모가 있다.

4.
이제 슬슬 레거시 얘기를 꺼내겠다.
요즘 아직도 빅 엔디언을 쓰는 컴퓨터가 현역으로 돌아가는 게 있는지(코볼 프로그램도 돌아가는 마당에 빅 엔디언이 하루아침에 전멸할 리는 없겠지만.. 엔드 유저가 실감 가능한 영역에 있는가?),
그리고 IA64 아이테니엄 컴퓨터가 아직 살아서 운용 중인 게 있는지 궁금하다.

1990년대 말과 2000년대 초에 인텔이 IA64, 그리고 펜티엄 4의 넷버스트 아키텍처 때문에. 그야말로 세기말과 새천년기에 컴퓨터계의 판도를 바꿀 정도로 큰 삽질을 하긴 했다. 물론 덕분에 경쟁사인 AMD는 큰 이득을 볼 수 있었다.
공교롭게도 이 시기가 무어의 법칙이 슬슬 약발이 다해 가는 시기이기도 했다. (싱글 코어 기반 클럭 속도 향상) 그러니 CPU 제조사의 입장에서는 미래를 내다보고 모험을 감수하고라도 판도를 근본적으로 바꾸는 큰 결정을 내려야 했을 것이다.

다음으로 엔디언 얘기를 하자면, 스마트폰용 최신 CPU는 아예 어느 엔디언으로도 네이티브 구동이 가능한 bi-endian 구조라고 하지만, 굳이 big 모드에서 실행될 일은 별로 없을 것 같다.
오늘날 빅 엔디언의 잔재는 예전에도 언급했듯이 트루타입 글꼴 파일, 그리고 네트워크 표준 스펙 정도에나 남아 있는 듯하다. 유니코드 텍스트도 UTF-16LE 아니면 차라리 UTF-8이지 UTF-16BE가 쓰일 일이 있나 싶다. 난 지금까지 한 번도 못 봤음.

5.
옛날 도스 시절에 상당수 프로그램들의 종료 단축키는 Alt+X였다. 아래아한글, 이야기, 그리고 Q-edit 계열이 이런 관행을 유지해 왔다.
지금 Windows에서는 Alt+F4가 단순히 대화상자 창을 닫는 ESC의 상위 호환이다. 대화상자만 닫는 게 아니라 응용 프로그램의 main window도 닫고 궁극적으로 시스템 종료까지도 가능하다. 하지만 도스 시절에 Alt+F4로 종료하는 프로그램은 본인은 정말로 MS DOS Shell밖에 못 봤다.

게임들은 대부분 ESC만 눌러도 원큐에 종료 가능했지만 페르시아의 왕자는 혼자 Ctrl+Q라는 독특한 단축글쇠로 종료했다(2편에서는 Alt+Q도 추가). 페르시아의 왕자 원판이 처음에 애플 기종용으로 개발되었고, 그쪽은 Cmd+Q가 종료이니 그거 영향을 받은 게 아닌가 싶다. 맥의 Cmd+Q는 창을 닫는 기능이 없이 그냥 원큐에 프로그램을 종료하는 용도로만 쓰인다. 그리고 내 기억이 맞다면 포토샵처럼 맥에서 이식된 프로그램은 Windows에서도 Ctrl+Q 종료 단축글쇠를 갖고 있었다.

그 외에 마소에서 만든 옛날 도스용 프로그램 중에는 웬 F3이 종료인 물건도 드물게 있었다. 주로 Windows 3.1 내지 9x 계열의 설치/setup 프로그램이 그랬던 것 같다. 이 관행은 오래 이어지지 못했다.

6.
옛날 자동차만큼이나 개인용 컴퓨터계에서도.. IBM 호환 PC라는 게 세상을 평정하기 전에 있었던 특히 1980년대의 8비트 구닥다리 컴퓨터들에 대해서 요즘 갑자기 좀 관심이 생겼다. 기계들 계보를 분류해 보고 싶다. 어떤 건 기계 자체의 명칭이지만 어떤 건 규격의 명칭이기도 하다. 이 당시 CPU의 제조사도 여럿 있었을 텐데.. 시간 나는 대로 인터넷 찾아 가며 차근차근 공부할 생각이다.

먼저 애플 II~III부터가 8비트였고 국산 컴퓨터로는 삼성 SPC-1000, 금성 패미콤이 있다. MSX는 특정 기종 이름이 아니라 규격명일 테고. Commodore 64에서 64는 메모리가 64KB라는 뜻이다 CPU는 64비트가 전혀 아니며 8비트임.
요런 컴퓨터들은 그냥 켜면 롬에 내장돼 있던 베이직 인터프리터가 떴고, 카트리지를 꽂으면 게임을 할 수 있었다. 테이프는 개인적으로 구경 못 해 봤다.

삼성의 경우 살인적인 공밀레에 공밀레를 거듭한 끝에 1983년 말에 최초의 국산 메모리 반도체인 64K D램을 개발하는 데 성공했다.
팀원: "저 다음 주에 결혼할 예정이어서 휴가 좀.." / 팀장: "야 왜 하필 이렇게 바쁜 와중에 결혼을 (쳐)하는 거야! 버럭"
거의 이런 분위기에서 개발한 것이었다. -_-;; 과장이나 주작이 아님. 저렇게 팀원을 실제로 갈궜던 당시 팀장이 신화창조던가 다큐에서 출연해서 증언을 했으며, 지금 생각하니 그 팀원에게 너무 미안하다고 회고했다.

더 부가가치가 높은 비메모리 반도체를 선점하지 못한 건 아쉬운 점이지만 일단은 그 열악한 환경에서 메모리 반도체 하나라도 저렇게 잡은 걸 다행으로 여겨야 할 듯하다. 그런데 삼성 전자에서 같은 1983년에 컴퓨터까지 만들었다는 게 대단하게 느껴진다. 그 옛날부터 이미 미래에 나라를 먹여 살릴 산업을 예견하고 리스크를 감수한 투자를 아낌없이 한 것이다.

나도 "IBM 호환 PC"에 속하는 컴퓨터를 접하기 전에 아주 잠깐 소위 8비트 컴퓨터라는 걸 집에서 접한 적이 있었다. 그건 정확하게 무슨 기종에 속한 물건이었을지 궁금하다.
프롬프트가 Ok 대신 READY라고 나오고, 입력한 문장에 문법 에러가 있으면 비프음과 함께 SYNTAX ERROR이라고 나왔는데.. 롬 베이직 인터프리터가 뜬 모습은 지금 생각해 보면 커모도어 64의 그것과 제일 비슷해 보인다. 하지만 실제로 그게 맞는지는 알 길이 없다.

넥슨 컴퓨터 박물관에서 이런 물건을 발견했다. 모니터는 내가 옛날에 집에서 써 봤던 그 기계와 정확하게 일치한다. 확실하다. 검은 테두리에다 오른쪽에 저렇게 작은 다이얼이 3개 있었고..  하긴, 옛날 아날로그 모니터들은 밝기 같은 걸 조절하는 게 저렇게 물리적인 다이얼 형태로 존재했었다. 검색을 해 보니 "금성 패미콤".. 아하, 메이커가 금성사였구나.

아무튼, 이런 원시적인 물건을 통해서 나는 프로그래밍이라는 행위의 짜릿함을 경험했고 무한한 신기함과 흥미를 느꼈다. 그래서 지금의 내가 있게 됐다. 어렸을 때 접한 컴퓨터가 처음부터 지금의 컴퓨터처럼 성능이 너무 좋고 시스템이 복잡하고 사용자가 개입할 여지가 없다시피한 형태였다면, 난 컴퓨터 말고 다른 진로를 갔을 가능성이 높다.

Posted by 사무엘

1.
근래에는 회사 업무 때문에 드디어 맥OS에다가 xcode까지 좀 건드릴 일이 있었다. 작년에 애플에서는 자기네 PC용 운영체제의 공식 명칭을 macOS라고 붙이면서 mac이라는 단어를 다시 복귀시켰던데, 이건 잘한 조치라고 생각된다. mac을 빼고 OS X라고 하는 건 영 아니었다. 무슨 OS/2도 아니고. 물론 걔네들 입장에서는 iOS 같은 타 기기용 운영체제와 명칭 표기를 통일하느라 mac을 소문자 형태로 살린 것이었다.

맥OS에서 메뉴를 꺼내는 단축키는 웬 뜬금없는 Ctrl+F2이구나(Win은 F10 또는 Alt). 그리고 한 프로그램 안에서 문서 창을 전환하는 단축키는 Cmd+` 이다(Win은 Ctrl+Tab 또는 Ctrl+F6). 이런 왕초보 기초부터 다시 시작했다.

Visual Studio와 C++과는 너무 다른 프로그래밍 방법론이 여전히 적응이 안 됐지만.. 나름 맥OS에 대한 이해가 예전보다는 더 깊어질 수 있었다. NextStep에서 딴 NS... 이런 명칭은 게임브리오 소스에 있는 NI... (넷이멀전) 접두사와 비슷한 느낌이 들었다. N으로 시작하고, 지금은 대외적으로 쓰이지 않는 이름. 마치 MFC의 Afx처럼 말이다.

한번은 각종 설정들을 이것저것 건드린 뒤부터 멀쩡한 프로젝트에서 정체를 알 수 없는 링크 에러가 나서 한참 고생한 적이 있었다.
링크 에러라면 당연히 extern "C"처럼 함수 호출 규약이나 심벌 decoration 방식의 충돌이 1순위로 의심되겠지만, 알고 보니 프로젝트 파일 리스트와는 별개로 관리되는 빌드 대상 목록에서 몇몇 소스 파일이 실수로 누락되어 벌어진 일이었다. 둘이 동일한 개념이 아니었 것이다.

하긴 Visual Studio도 각각의 파일들에 대해서 속성을 줘서 exclude from build를 지정하는 게 있긴 했다. 그걸 몰라서 딴 데서 한참을 헤맸다.
IDE에서 각종 경고를 출력하는 인텔리센스와 문맥 감지 색깔 처리가 정상적으로 되고 있어서 이 파일이 애초에 컴파일이 되지 않고 있다는 건 상상을 못 했었다.

2.
맥OS는 자기네 그래픽 비주얼은 그렇게도 뛰어나면서 정작 그래픽 툴을 제공하는 건 왜 그리 인색한지 모르겠다. 맥OS에는 Windows의 '그림판'에 해당하는 기본 프로그램이 내가 알기로 여전히 없다.
개발툴 중에서도 Visual Studio는 간단한 아이콘이나 비트맵 정도 편집할 수 있는 그래픽 에디터를 내장하고 있는 반면, xcode는 그런 거 없고 viewer만 있다. 비트맵 그래픽 편집을 어떻게 해야 할지 모르겠다.

그리고 또 인상적인 점으로는 맥 진영은 Windows에서는 거의 듣보잡이나 마찬가지이던 tif/tiff를 좋아하는 듯하다. 화면 캡처 기본 앱이 그림 파일을 tif로 저장할 때부터 뭔가 심상찮았는데.. 타 xcode 프로젝트들을 보니까 비트맵/아이콘에 역시 tif가 들어가 있구나.

그런데 tif도 다 같은 tif가 아닌지, Windows에서 돌아가는 타 그래픽 에디터에서 저장한 tif는 맥에서 못 읽는 것 같다.

3.
명령 프롬프트로 가 보면, 공백이 포함돼 있는 파일명을 명령 프롬프트에서 표현할 때 Windows는 파일명을 따옴표로 싸서 공백을 표현하는 반면, 맥은 그렇지 않은 듯하다. 역슬래시+공백이라는 탈출문자 기법을 사용한다. 그러니 "a b"냐 a\ b냐의 차이가 발생한다. 디렉터리 구분자부터가 슬래시이니 역슬래시를 저렇게 C스럽게 탈출문자 용도로 활용한다는 게 아주 흥미롭다.

명령 프롬프트가 현재 가 있는 디렉터리(폴더)를 기준으로 탐색기 또는 그에 준하는 파일 관리 셸을 여는 것도 자주 행해지는 작업이다. 숨김 속성 때문에 셸을 통해 접근할 수 없거나 접근 방법이 까다로운 폴더를 다루고 싶을 때 말이다. Windows에서는 start .이던데 맥은 open .이다. 리눅스는 어찌 되려나 궁금하다.

4.
그리고... 결정적으로 맥용 IME 예제도 다뤄 봤다. 골치 아픈 DLL이 아니라 쿨하게 EXE 형태이고, regsvr32 따위 할 필요 없이 그냥 프로그램을 특정 디렉터리에다 얹어 놓기만 하면 바로 IME가 동작하는 게 참 깔끔해 보였다. 여기에다가 날개셋 엔진만 얹으면 내 프로그램이 맥용으로 나오는 것도 불가능하지는 않겠다는 생각이 들었다. 물론 글자만 달랑 찍히는 수준을 넘어서 완성도 있는 제품을 만드는 건 지금 시간과 내 실력만으로는 아직 어림도 없는 요원한 일이다.

오래 전부터 인지했던 것이긴 하지만, Windows와 맥은 문자 입력 시스템을 설계한 형태가 서로 크게 다르다.
Windows는 IME가 또 내부적으로 한영 상태를 갖고 있고 자기 상태를 아이콘을 통해 출력하는 형태이다. 즉, Windows 8식 용어로 표현하자면 brand icon과 state icon이 따로 있다.
그러나 맥은 그렇지 않고 한글 입력 상태가 영문 상태만큼이나.. Windows식으로 표현하자면 별도의 input locale이다. 일단 한글 IME 상태에서 한영 키로 한영 전환을 하는 게 아니라, 입력 로케일 전환인 Ctrl+Shift가 한영 전환인 셈이다. state icon이 없고 brand 자체가 state 역할을 한다.

그러나 <날개셋> 한글 입력기는 자기 brand 하에서 2개 이상 열몇 개까지 입력 항목을 추가할 수 있는 형태이다. 이것부터 맥OS에서는 어떻게 표현을 해야 할지 모르겠다. 맥에서 <날개셋> 한글 입력기는 편집기 계층은 제대로 구현하지 못하고 그냥 입력기 계층 하나 수준에 머물러야 할 수도 있다.

맥에서는 IME가 독립된 프로그램이고 시스템 전체에서 동일한 한영 상태가 유지된다는 것도 매우 흥미로운 점이다. Windows도 IME가 애초에 이런 형태였으면 지금처럼 32비트와 64비트가 공존까지 하는 시대에 IME를 개발하기가 훨씬 더 깔끔해지지 않았을까 싶은 생각이 든다.
언제든지 자기 자신을 죽이고 재시작만 하면 업데이트도 아주 간편하게 할 수 있다. Windows는 DLL에다 memory-mapped file크리까지 겹쳐서 프로그램 강제 종료나 재시작 같은 지저분한 짓 없이는 IME의 업데이트라든가 전체 상태 동기화가 몹시 어렵다.

다만, 그 구조의 특성상 IME를 디버깅 하는 도중에 잠시 딴 프로그램에서 타 IME를 구동해서 문자를 입력하기가 좀 난감한 점은 있다. IME는 그 특성상 타 입력기로 대체만 될 뿐 '스스로 종료'라는 개념이 없는 프로그램인데, Windows에서는 자기 DLL을 사용하는 프로그램이 하나만 존재하면 그것만 끝내면 디버깅도 원활하게 종료되는 반면, 맥에서는 그런 것도 없어서 그냥 IME 프로그램을 강제 종료해야 한다.

그리고 IME 프로그램은 내 자신이 실행하는 게 아니라 운영체제가 on-demand로 구동해 주는 형태이다. 그러니 개발툴이 처음부터 IME를 디버깅 할 수 있는 게 아니라 이미 구동돼 있는 IME 프로세스에다 디버거가 붙는(attach) 식으로 디버깅을 해야 한다.
이렇게 붙으면 NSLog를 찍는 게 xcode의 output 창에 나타나질 않는 문제가 있더라. 그 이유는 모르겠다. 운영체제의 문자 입력 프로그램이라는 건 어떤 형태로 만들더라도 디버깅이 어려운 구석이 있는 듯하다. 동력분산식과 동력집중식만큼이나 서로 일장일단이 있는 셈이다.

5.
코딩을 하면 할수록 Objective C의 고유 문법과 일명 NSFramework 라이브러리는 독립된 언어라기보다는..
Windows로 치면 COM처럼, 그냥 API/라이브러리의 컴포넌트화, 그리고 운영체제-내 프로그램 간의 통신을 위한 바이너리 수준의 프로토콜에 가까운 물건이라는 생각이 든다.

쉽게 말해 NSObject는 IUnknown에, YES/NO는 S_OK, S_FALSE에, @문자열은 BSTR, SysAlloc/FreeString 등에, xib/nib는 리소스 겸 type library에 대응하는 식이다. 뭐 가상 머신이 따로 돌아가는 급은 아니지만 그래도 가벼운 garbage collector도 있다.

물론 기능 호출 방식은 서로 큰 차이가 있다. COM은 함수 포인터 기반인 C++과 더 비슷하지만 옵씨는 진짜 SendMessage 같은 방식이다.
그러니, NSObject에 뭐가 이렇게 오버라이드 가능한 메소드들이 많이 정의돼 있는지, 리스트를 보고 깜짝 놀라곤 했다. v-table 기반의 가상함수라면 상상도 못 할 일이다. MFC도 v-table 크기 부담 없이 운영체제 메시지 처리를 C++로 하기 위해 message map이라는 별도의 메커니즘을 도입한 것이다.

옵씨라고 해서 말 그대로 C만 쓸 수 있는 건 아니며 C++ 코드도 작성 가능하다. 그러니 [ ] 어쩌구로 시작하는 그쪽 ‘오브젝트’와 해당 문법은 운영체제로부터 호출을 받는 것에 대처할 일이 있을 때만 사용하게 되더라.
아무튼 지구를 떠나서 달이나 화성에서 사는 건 어렵고, Windows 홈그라운드를 떠나 타 OS에서 사는 건 여전히 몹시 어렵다!

Posted by 사무엘

이 글에서는 1994년에 발매되었던 국산 패키지 게임을 하나 소개하고자 한다. '리크니스'라고 그림체나 게임 진행 방식이 슈퍼마리오와 비슷한 형태인 아케이드 게임이다.
본인은 그 시절에 얘 실물을 해 보거나 구경한 적이 없다. 단지 초딩 말년이던 시절, PC월드 한국어판 1994년 8월호 기사를 통해 소개된 것을 읽은 기억만이 남아 있다. 그리고 그 기억이 최근에 오랜만에 되살아나서 다시 회고를 하게 된 것이다.

1990년대 중반에는 그 날이 오면, 못말리는 탈옥범, 낚시광 같은 여러 국산 게임들이 있었다.
이 시절에 게임은 하드웨어 제어가 용이한 도스용으로 개발되었다. DirectX나 3D 셰이더 언어, 언리얼/유니티 엔진 같은 건 존재하지 않았다. 그 대신 어셈블리를 이용한 교묘한 하드웨어 테크닉이 고급 기술로 취급되었다. 그래픽 모드를 바꾸고, 비디오 메모리를 직접 조작해서 화면이 Doom처럼 쫙 흐르듯이 갈라지고, 사각형이 아닌 형형색색 모양의 2D 스프라이트로 애니메이션을 구현하고..

IBM PC는 게임 전용 하드웨어가 아니다 보니 3차원 그래픽은 고사하고 부드러운 2차원 화면 스크롤을 구현하는 것조차도 보통일이 아니었던 것 같다. Windows API로 치면 ScrollDC 내지 ScrollWindowEx를 구현하는 거 말이다.
스크롤 기술이 더 발전하면 '다중 스크롤'이 된다. 먼 배경은 천천히 스크롤하고, 가까운 기물은 많이 스크롤해서 반쯤 원근감과 입체감을 내는 것 말이다.

저 리크니스도 그렇고, 더 옛날에 id에서 Doom 이전에 개발했던 커맨더 킨을 보면 자기들의 독자 노하우를 동원해서 게임기를 방불케 하는 빠르고 부드러운 스크롤을 구현했다고 자랑을 했다. 스크롤을 못 하면 페르시아의 왕자 같은 페이지 단위 스크롤밖에 구현할 수 없을 것이고 그건 단조롭다. Titus에서 만들었던 고인돌(Prehistorik) 1편과 2편의 스크롤의 차이도 생각해 보시라.

게임용 그래픽 아티스트들도 포토샵이나 MAX, Maya가 아니라 딜럭스 페인트가 생계 도구였다. 트루컬러 같은 건 없고, 256색에서 팔레트 배분을 잘하고 도트 노가다를 열나게 하는 게 일이었다.
320*200이 지금으로서는 상상하기 힘든 워낙 저해상도이니, 막 크고 화질 높은 그림을 그릴 필요가 없는 건 다행이었다. 그러나 스프라이트 말고 고정된 그림은 가장자리 안티앨리어싱을 잘해서 저해상도에서도 최대한 부드럽게 보이게 해야 했다.

1990년대에 그런 불모지 영역을 개척했던 1세대 게임 개발자들이 김 동건· 이 은석(85되었수다/삭제되었수다), 정 재성(그 날이 오면) 같은 분들이다. 그리고 같은 연배의 개발자로 김 학규라는 분이 있으며, 이분이 옛날에 소프트맥스의 아트크래프트 스튜디오에 소속되어서 만들었던 게임이 리크니스이다.

(이 게임을 심층 분석한 블로그 링크)

리크니스는 만화풍 + 파스텔톤의 그래픽을 추구했는데 개인적으로 색감이 참 예쁘고 마음에 든다.
저런 게임 스토리 연출과 각종 그래픽들을 그 시절에 어떻게 다 생각해 내고 만들었는지 경이로울 따름이다. 하드웨어 장비도 열악하고 지금 같은 인터넷도 없던 시절에!

스토리 화면에서 리크니스(남캐)와 아이리스(여캐)가 눈을 마주친 뒤, 새들이 푸드득 날아가면서 시작 메뉴 화면이 뜬다.
링크하는 블로그 글에서도 지적하지만, 주인공을 선택했을 때의 반응이 참 익살스럽다.
블루스 형제(Titus 작)와는 달리, 이 게임에서는 선택받은 주인공이 기뻐하는 게 아니라 "뭐? 또 나야?" 같은 뻘쭘하고 당황한 표정을 짓는다. 특히 아이리스 아가씨는 마시던 물을 뿜기까지 한다.

(전체 플레이 동영상)

플레이 장면을 보니 진짜 슈퍼마리오 스타일 같다.
여러 블로그들의 평을 보면.. 리크니스는 왕창 어렵다는 게 중론이다. 특히 카지노 슬롯 같은 걸 돌려서 공격하는 최종 보스전은 메모리를 강제 조작해서 보스의 HP를 너프시킨 뒤에야 겨우 깼다는 얘기까지 있다.
그럼 나 같은 사람한텐 더욱 어렵겠다. <그 날이 오면>도 그렇고 게임들이 전반적으로 어려웠다. ^^

끝판을 깬 뒤 엔딩은 생각보다 허무하고 별로 볼 게 없었다. 개발팀의 사진 같은 게 나오는 것도 아니고.

본인이 리크니스를 재주목하게 된 이유는 개인적인 경험과 관련하여 또 있다.
먼 옛날에 하이텔 게임 제작 동호회에서 딱 두 번인가 게임 공모전을 한 적이 있었다. 이 얘기 자체는 <삭제되었수다>를 소개하면서 예전에 한 적이 있다. 그때 저 게임이 1등을 했기 때문에.

그런데, 그 당시에 본인이 개인적으로 알고 지내던 프로그래밍 동호회 친구도 거기에 게임을 출품했으며, 공개된 그 게임을 나도 해 봤다.
그 게임에 쓰였던 BGM들 중 일부가 바로 리크니스 게임의 BGM을 빌린 것이었다는 걸 알게 된 게 그로부터 거의 20년 뒤의 일이니 감회가 새로울 수밖에... 일부 스테이지의 음악이 귀에 아주 익숙했다.

1990년대에 20대 초반의 나이로 이미 저렇게 날고 기었던 김 학규 씨는 그 뒤로 대학까지 중퇴하고서 게임 개발 학원 강사로 뛰기도 했고, 수제자들과 함께 그라비티를 설립해서 걸출한 온라인 게임을 계속해서 개발했다. 1990년대 이후에는 플랫폼도 Windows로 넘어가고 3D 기술 + 네트워크 기술까지 게임 개발 방법론이 그냥 싹 갈아엎어진 거나 마찬가지 아니던가? 그걸 일일이 다 공부하면서 어떻게 따라갔는지가 그저 대단할 따름이다. 하지만 개발 능력 대비 경영 수완이 부족해서 자기가 세웠던 회사에서 물러나기도 하고 인생에 우여곡절이 많았던 모양이다.

나도 학창 시절에는 프로그래밍에 빠져서 제도권 교육에서는 완전히 이탈해 버렸지만.. 그렇다고 실력이야 쨉도 안 되고 저렇게 현업에서 당장 돈 되는 물건을 만들 능력도 없다 보니 학교를 때려칠 배짱은 없었다. 저런 사람들의 꿈과 열정이야 참 대단하긴 한데 요즘 우리나라는 게임 업계가 사정이 너무 안 좋긴 하다. 정부로부터의 온갖 규제, 사용자의 불법복제, 끊임없이 치고 들어오는 외산 게임들.. 업계에서는 또 공밀레에 야근 야근..;;

그런데 이렇게 열악함에도 불구하고 코딩으로 먹고 살자니 그나마 SI 품팔이 같은 진짜 지옥 말고 스스로 수익을 내고 할 만한 데가 미우나 고우나 게임밖에 없다. 국내의 걸출한 소프트웨어 개발자 프로그래머들을 제일 많이 볼 수 있는 데가 모르긴 몰라도 넥슨, NC 같은 게임 개발사들이다. 에구, 이건 나의 적성· 전공과도 관계가 있는 문제인데 이 바닥이 앞으로 어떻게 변화할지 찬찬히 살펴봐야 할 것 같다.

Posted by 사무엘

1. 블레이크 스톤 (Blake Stone)

먼 옛날 기억을 되살려 보니, 본인은 1990년대 중반에 울펜슈타인이나 둠 같은 id 사의 게임 말고 다른 계열의 3D FPS 게임을 친구 집 컴퓨터에서 본 적이 있었다. Doom처럼 좀 SF스러운 분위기이지만 Doom은 아니고 그것보다는 기술 수준이 뒤떨어졌다. 열쇠가 없는 상태로 잠긴 문을 열려고 하면 깜찍한 소리로 문이 열리지 않는다는 피드백이 왔다. (울프와 둠에는 청각 피드백이 없음)

그리고 제일 결정적인 단서로는.. 체력이 막대기나 숫자나 주인공의 얼굴 상태로 표시되는 게 아니라 검은 배경에 초록색 파형인 심전도 그래프로 나타났다. 완전히 죽어 버리면 물론 심장 박동이 없어진다.
이 모든 조건을 만족하는 게임을 검색해 보니.. Blake Stone이다.

기술적으로는 얘는 울펜슈타인 3D 엔진을 기반으로 개발되었다. 그렇기 때문에 높이를 표현할 수 없으며 레벨 배경은 여전히 건물 안으로 제한된다. 그러나 얘는 울프와는 달리 (1) 바닥과 천장에도 텍스처를 얹어서 그래픽을 고급화했으며, (2) 시점에서 먼 곳은 살짝 더 어둡게 표시되는 걸 구현했다. 게다가 얘도 미래가 배경이기 때문에 높이가 없다는 것만 빼면 전반적으로 둠과 분위기가 비슷해 보인다.

얘는 분명 나쁘지는 않은 게임이었으나, 스케일과 기술 수준 등에서 둠의 적수가 될 수는 없었다. 게다가 너무 늦게 나왔다. 출시일이 1993년 12월. 얘가 발매되고 나서 겨우 1주일 뒤에 Doom이 출시되는 바람에 블레이크 스톤은 존재감이 싹 묻혀 버렸다.

2. 퀘이크 1의 베타 3

본인은 중학교 말년에 어느 이웃집 형이 가져온 불법복제 백업CD를 통해서 퀘이크라고 둠의 다음 세대 게임을 처음으로 접했다. 그때는 지금 같은 고속 인터넷망이 없었으니 어둠의 경로에서 소프트웨어 불법복제를 책임지던 매체는 CD였다.
요즘은 아무 컴퓨터에나 당연하게 달려 있는 CD 쓰기/굽기 기능도 그때는 고가의 기계를 따로 돌려야 할 수 있는 첨단 기능이었다. 어디 그 뿐이랴? 요즘은 인터넷, USB 메모리, 외장 하드의 발달로 인해 광학 드라이브의 필요 자체가 극도로 줄어들어 있으니 격세지감이 아닐 수 없다.

그렇게 본인은 오랫동안 도스용 퀘이크 1을 즐겼다. 486 66MHz짜리 컴퓨터로는 퀘이크는 기본 최저 해상도인 320*200/240대에서나 제대로 프레임이 나왔지 640*480으로는 도저히 제대로 할 수 없었다. 그러고 보니 동일한 영어 이니셜을 갖고 "그 FPS(1인칭 슈팅) 게임은 이런 사양의 컴터에서 FPS(초당 프레임 수)가 얼마나 나오냐?" 이런 드립을 치는 게 가능하구나.;;

세월이 흘러 2000년대 중반이 되었고, 본인의 컴퓨터는 퀘이크를 처음 접하던 시절보다 당연히 성능이 월등히 더 향상된 걸로 바뀌었다. 본인은 옛날 생각에 Windows용으로 포팅된 퀘이크를 고전 게임 사이트에서 구해서 돌려 봤다.
그런데 이 퀘이크는 내가 옛날에 하던 퀘이크와는 미묘하게 다른 게 많았다. 정자체에 가깝던 화면 글꼴은 bloody한 분위기를 내려는 듯 좀 흘리고 날린 형태로 바뀌었다. 메뉴를 꺼내면 뒤의 게임 배경이 단순히 팔레트만 바뀌는 게 아니라 시꺼먼 하프톤 점이 쫙 깔렸다.

각 에피소드별로 모아야 하는 아이템의 이름을 본인은 10여 년 가까이 sigil이라고 알고 있었는데 이 게임은 rune이라고 표현했다.
그 이름도 유명한 무기 파워업 아이템은 quake power이라고 알고 있었는데 그게 이 퀘이크에서는 quad damage였다.
새로 구한 퀘이크는 에피소드 2의 마지막 레벨은(비밀 레벨 말고) 물웅덩이를 중심으로 사방으로 이동해서 다리를 내는 형태였는데 내가 기억하는 맵이 아니었다. 또한 에피소드 3의 마지막 레벨의 끝부분에서 Vore 두 놈은 높은 곳에서 튀어나왔으나, 이 게임은 다리 아래 용암 바닥에서 튀어나왔다.

차이점은 이 뿐만이 아니다. 에피소드 1의 보스인 Chthon의 생김새도 내가 기억하던 모양이 아니었다. 내가 하던 퀘이크는 얼굴도 몸통과 비슷한 색깔이고 눈이 있었던 반면, 이 퀘이크는 딱히 눈 같은 게 없고 얼굴 전체가 세로로 난 입의 이빨 같은 것으로 둘러져 있었다.

결정적으로 게임 전체의 최종 보스인 Shub-Niggurath와 싸우는 마지막 레벨은 완전히 다른 맵으로 바뀌어 있었다.
내가 기억하는 마지막 맵은 요렇게 뭔가 에피소드 4의 비밀 레벨과 비슷한 분위기였다. 나중에는 천장이 청록색인 거대한 필드에 도달하고, Shub-Niggurath가 있는 곳까지도 갈 수는 있지만 여기서 더 보스를 죽이거나 게임을 진행해서 엔딩을 볼 수는 없었다. 적을 다 죽인 뒤에 어떻게 해야 할지를 몰랐다.
(그나저나 퀘이크는 다 뭘 참고해서 몬스터들의 이름을 지었는지, 스펠링이 다 읽기 힘든 형태이다.)

이렇게 내가 경험했던 퀘이크에 차이가 존재했던 이유는 이미 제목에 쓰여 있다. 내가 중딩 시절 옛날에 했던 퀘이크는.. 바로 퀘이크 정식 버전이 발매되기 불과 2주 남짓 전에 유출된 '0.8 베타 3 버전'이었기 때문이다. 그게 어째 어떤 복돌이가 만든 백업 CD에 포함되었던 것이다. 난 10년이 넘게 베타 버전 퀘이크가 정식 퀘이크인 줄로 알고 있었다.
그래도 이런 것도 이제 검색해 보면 구체적인 출시 내역을 다~ 알 수 있고.. 옛날 기억도 어지간한 건 다 복원 가능한 세상이 됐으니 참 대단하다.

beta 3 구버전의 구동 및 플레이 동영상을 짤막하게나마 유튜브로 다시 보니 감회가 새롭다. 구버전은 마지막 레벨을 클리어 하는 엔딩이 원래 존재하지 않았던 게 맞았다. 미완성이었다.
그에 반해 정식 버전은 적절한 타이밍에 순간이동 장치로 들어가서 Shub-Niggurath의 몸 속으로 '텔레프래깅'을 하는 방식으로 적을 죽여서 엔딩을 볼 수 있다.

더 생각나는 걸 열거하자면, 몬스터 Ogre가 톱질 하는 소리가 구버전 것은 정식 버전의 것보다 피치가 좀 더 낮았다. Vore가 쏘는 탄환이 구버전은 그냥 용암 fireball과 동일했지만 정식 버전은 보라색 공으로 바뀌었다.

또한, 주인공이 뭔가에 깔려 죽었을 때 구버전은 be crushed라는 말을 썼지만 정식 버전은 be squished라고 말을 바꿨더라. 본인은 crush라는 단어를 둠과 퀘이크를 통해서 알게 됐다. Doom 2에서도 레벨 6이 The crusher이기도 하고 말이다. 끝으로, 구버전에서는 Ogre 이상 몬스터들은 로켓 같은 무기로 오버킬을 당해도 결코 육편 피떡으로(gibbed) 변하지는 않았던 걸로 기억한다.

id에서 1990년대 중반에 개발했던 Doom과 Quake들은 묘사가 잔혹할 뿐만 아니라 오각형, 염소 뿔 등 의도적으로 오컬트나 사탄 숭배교를 표방하는 듯한 비주얼이 많이 들어가 있었다.
그래서 자국 내에서도 이런 비판을 많이 받았는가 보다. 파일로 제공되는 도움말 문서를 보면, FAQ 중 하나로 "Are you guys Satan-worshipers?"가 있고, 이에 대한 답변은 No 한 마디로 간단히 일축해 놓았다.

그런데, 이것도 구버전의 도움말 문서는 간단히 No만 있는 게 아니라.. "아니요, 우리는 그냥 오각형과 666을 좋아할 뿐입니다."라는 부연 설명도 들어있었다. 중고딩 시절에 분명히 읽었던 기억이 있다.
id는 전통적으로 종료 확인 메시지도 그렇고 말을 전반적으로 익살스러운 농담조로 하는 걸 좋아하긴 한데, 이 질문에다가도 답변을 그런 식으로 하면 기독교 단체 같은 데에다가 더 큰 논란과 어그로를 일으킬 것 같으니 저 말을 삭제한 듯하다.

3. 기타

10대 중반의 나이로 접했던 FPS들은 나의 가치관 형성에 많은 영향을 줬다.

요렇게 거의 270도 턴을 해서 미로처럼 꼬불꼬불 들어가게 돼 있는 건물 화장실을 이용한 적이 있었다.
벽면 텍스처도 규칙적인 형태인 게 무슨 둠 맵 같다. 문은 좌우로 열리는 게 아니라 셔터처럼 위로 열릴 것 같다.
이런 모양의 맵을 설계하면 bsp 파일이 어떤 형태로 만들어질까 이런 게 머리에 어른거린다. -_-;;

정확하게 1인칭 시점인 건 아니지만 툼 레이더도 있다.
선유도 공원을 가 보면 거긴 잡초가 낀 야외 콘크리트 구조물이 영락없이 툼 레이더 1 맵 같다.
손에 쌍권총 쥐고 옆으로 점프라도 하고 싶은데.. 그랬다가는 다치겠지.

말이 나왔으니 말인데, 내 생각에 적당히 스토리만 잘 짜 놓으면 우리나라 DMZ를 배경으로 툼 레이더 커스텀 레벨 얼마든지 만들 수 있다고 본다. GP에 들어가서 아이템 먹고 북한군을 때려잡는 식으로 진행될 것이다.
Demilitarized Zone 이름도 얼마나 근사하냐? ㅋㅋ

Posted by 사무엘

본인은 태생적으로 신체 활동을 싫어했다. 운동 경기는 스스로 하지도 않고, 남이 하는 걸 즐겨 보지도 않았다. PC 게임으로도 액션· 아케이드에 밀려서 거의 안 했다.
야구의 경우, 아직까지도 정확한 룰과 득점 조건도 모를 정도이다. 투수가 던진 공을 쳐내고 나서 각 선수들이 무엇을 목표로 어디로 그렇게 열나게 뛰어가는지 로직을 모른다. 배구· 농구· 축구만치 룰이 직관적이지 않아서 말이다. 당연히 유명 구단이나 선수 같은 것도 전혀 아오안이다.

야구는 옛날에 '하드볼'이라는 PC용 고전 게임이 있었고, 축구는 더 나중에 'FIFA 연도' 이런 게임이 있었던 것 같다. 요즘도 계속 나오는지는 모르겠다.
그런데 스포츠라는 장르에 속하는 고전 게임 중에는 그렇게 한 종목에 특화된 놈이 있는가 하면, 간단한 종목들을 여럿 옴니버스 식으로 제공하는 게임도 있었다. 오늘은 그런 게임들을 먼저 좀 늘어놓아 보겠다.

먼저, 캘리포니아 게임즈이다. 학교 친구와 함께 디스켓으로 실행하며 즐겼던 추억이 있다.

Epyx라고 옛날에 스포츠 게임 시리즈를 전문적으로 개발해 온 회사에서 1987년에 발표한 게임이다. Epic Games와는 다른 회사임.
IBM PC뿐만 아니라 다양한 플랫폼으로 만들어졌다. PC용의 경우 VGA 카드가 개발되기도 전이었으니 최고 그래픽은 응당 EGA 16컬러였다.
게임 로고가 뜬 뒤엔 위의 사진과 같이 검은 배경에 흰 글씨로 게임 방식을 선택하는 메뉴가 뜬다. 선택막대가 Doom은 두개골이라면 얘는 야자수인 게 인상적이다.

이 게임은 여러 간단한 퍼즐형 스포츠의 컬렉션이다. 요즘 같으면 플래시나 모바일용으로 만들면 딱일 듯한 스케일이다.
보드 타기, 파도 타기, 제기 차기, 롤러 스케이트처럼.. 무슨 올림픽 종목까지는 아니지만 미국 서부의 길거리 스포츠라고 해야 하나.. 그런 것들이 제공되었다.

각 경기별로 주인공은 남자도 있고 여자도 있다. 특히 부메랑처럼 생긴 디스크 날리기(flying disc)도 있는데... 뭔가 좀 미국스러운 게임 같다. 사람이 날리고 개가 받아서 가져오는 게 아니라, 남자가 날리고 여자가 받는다. 실사로 치면 이런 식으로.

먼저 남자가 각도와 힘을 설정해서 디스크를 날리는데, 이 자체는 뭐 투사체를 던지는 기능이 있는 게임들과(QBasic 고릴라, Scorched Earth 등) 크게 다를 바 없는 UI이다.
디스크를 날린 뒤부터 게임 컨트롤은 파트너인 여자에게로 넘어간다. 디스크가 떨어질 걸로 예상되는 위치에다 파트너를 잘 조종해야 디스크를 붙잡을 수 있다. 디스크와 여자 파트너의 위치는 화면 위의 미니맵에 표시되어 있다.

그런데 재미있는 건... 남자가 디스크를 오랫동안 안 날리고 가만히 있으면.. 하늘에서 무슨 UFO 같은 게 내려와서 여자를 납치해 가 버린다..;;; 그 장면을 우리가 직접 볼 수는 없고 미니맵 상으로만 표시된다. 그리고는 게임오버. 디스크가 외형상 비행접시와 비슷하니 이런 깜짝쇼를 넣은 건지는 모르겠다.

그리고 또 캘리포니아 게임즈에서 즐겨 하던 게임은 사이클이었다. 장애물을 요리조리 잘 피해야 넘어지지 않고 제한 시간 안에 목적지에 도달할 수 있으며, 그 와중에 회전이나 바퀴 들기 같은 위험한 묘기도 종종 해서 성공해야 점수를 딸 수 있다. 생각보다 어려웠던 걸로 기억한다.
1990년에는 VGA를 지원하고 1보다 그래픽이 크게 강화된 캘리포니아 게임즈 2가 나오기도 했다. 하지만 본인은 2는 접해 보지 못했다.

Epyx에서는 역시 비슷한 시기인 1988년경엔 우리나라에서 개최된 서울 올림픽을 게임화한 The Games: Summer Edition을 내놓았다. 전편인 Summer Games도 있고 자매품인 The Games: Winter Edition까지 있으니 저 회사는 진짜 스포츠 게임 전문이었나 보다.

그런데 여느 작품과는 달리, 이 The Games: Summer Edition은 올림픽 개최국인 한국을 지도까지 곁들여서 굉장히 자세히 소개했다. 위의 애니메이션을 보시라. 한복에다 서울 남산 타워도 나온다. 이 정도면 저 제작사가 그냥 스스로 저렇게 만들지는 않았고 우리나라 정부로부터 협찬· 후원도 받았지 않았나 생각된다. 쟤들은 캘리포니아 하계 스포츠를 소개하는 게임을 만들면서도 1984년 LA 올림픽을 대놓고 홍보하는 게임을 만든 적은 내가 알기로 없다.

플레이 동영상에 나와 있듯이, 얘는 올림픽 스포츠 게임답게 평행봉, 다이빙, 기계 체조, 양궁, 장애물 넘기, 육상, 사이클까지 간단하지만 다양한 종목의 경기를 제공했다. 게다가 제한적이나마 1인칭 시점 3차원 애니메이션까지 제공하며 그래픽의 퀄리티가 높다. (지금으로부터 30여년 전의 게임이다!)

운동 선수가 하는 동작의 무엇을 컨트롤해서 무엇으로 승부를 가르고 재미를 만들지를 설계하는 건 쉬운 일이 아니었을 텐데 그 당시 이 게임을 만든 개발자들은 굉장히 똑똑한 사람들이었음이 틀림없다. 허나, 정작 본인은 우리나라를 소개하는 이 게임은 어렸을 때 접해 보지 못했다.

그 다음, 마지막으로 소개하고자 하는 종합 스포츠 게임은.. 위의 것들과는 달리 '동계' 스포츠 담당이다. 바로 Ski or Die. 제목이 참 아찔하다.

본인은 Ski or Die와 캘리포니아 게임즈가 성격이 비슷하다고 생각해 왔다. 하지만 Ski or Die는 Epyx 사의 작품이 아니다. 그 이름도 유명한 Electronic Arts에서 개발했다고 나온다. 다만, 신기술의 도입이 늦었는지 1990년작임에도 불구하고 VGA를 지원하지 않고 여전히 16컬러인 것은 좀 아쉬운 점이다.

얘는 메뉴를 고르는 게 아니라 주인공의 스키를 조종해서 원하는 경기를 선택하는 형태로 진행된다. 스키, 보드 또는 튜브를 타고 슬로프를 내려가는 건 기본이며, 스키 점프 묘기에다 심지어 눈싸움도 있다. 눈싸움은.. 뭐랄까 SEGA 시노비에서 한 레벨을 깬 뒤에 등장하는 보너스 게임과 비슷한 스타일 같다. (돌아다니는 자객들을 전부 표창 던져서 맞히는 거)

캘리포니아 게임즈에서 자전거나 스케이트를 타고 이동하는 게임은 다 횡(가로) 스크롤이지만, Ski or Die에서 스키를 타고 이동하는 게임은 다 종(세로) 스크롤이라는 차이가 있다.

Posted by 사무엘