« Previous : 1 : 2 : 3 : 4 : 5 : 6 : 7 : 8 : ... 10 : Next »

1.
우리나라가 옛날보다는 소프트웨어 불법복제에 대한 경각심이 좀 생겼고 불시단속도 강화된 관계로..
기업들 역시 대기업· 중소기업을 막론하고 직원들의 컴퓨터에 혹시 불법복제 소프트웨어가 깔려 있는지 자체 단속을 하는 편이다.
그런데, 그런 소프트웨어 자체를 생산하는 일을 하는 IT 기업에서는 추가적으로 민감한 물건이 더 있다.
자사가 개발하는 제품의 내부에 혹시 오픈소스 솔루션이 예기치 않게 들어가지 않느냐 하는 것이다.

당장 돈을 안 들이고 원하는 문제를 쉽고 빠르게 해결할 수 있다고 해서 출처 명시 없이, 혹은 라이선스가 요구하는 사항을 이행하지 않고 그런 솔루션들을 자기 소스 코드에다 불쑥 집어넣었다가는..
글쎄, 그 회사와 회사 제품이 완전 듣보잡 마이너 내수급이라면 별로 문제되지 않고 넘어갈지 모른다.
그러나 외국으로도 널리 널리 쓰이고 돈을 빗자루로 긁어모으는 인기 프로그램이라면 얼마 못 가 당연히 걸리고 발목 잡히게 된다.

왕년에 병역비리 내지 논문 표절을 저지른 사람이 나중에 고위 공직자가 되려 할 때 청문회에서 탈탈 털리듯이 말이다.
오픈소스를 표방하는 자유 소프트웨어라고 해서 저작권이 전혀 없는 게 아니기 때문이다. 아무나 완전히 제멋대로 고치고 이득을 챙겨도 되는 '인류 공용 자산'급인 public domain이 아니다.

방대한 분량에 복잡한 로직을 가진 소프트웨어는 설령 소스 코드가 있다 해도 누가 함부로 찔끔찔끔 고칠 수 있는 물건이 아니다. 그래서 그런지 설령 컴파일된 바이너리이고 소스 코드가 없다 하더라도, 여기에 어떤 오픈소스 솔루션이 무단으로 포함되었는지 정도는.. 오픈소스 진영에서 매의 눈으로 감시해서 다 적발해 낸다. 컴파일된 바이너리 코드의 패턴 분석을 정교하게 하는 듯.

그래서 그렇게 자기는 이윤을 챙기면서 엔진 내부에 무료 오픈소스를 무단으로 사용한 양심불량 소프트웨어는 hall of shame 같은 데에 올라서 업계에서 국제적으로 망신을 당하며,
GPL 라이선스 급의 오픈소스를 잘못 따다가는 그걸 사용한 프로그램 전체에 대해 소스 공개라는 형벌(?)을 당하게 된다. 실제로 그런 소스 공개형을 당한 사례도 몇 건 있다. 물론, 프로그램 소스만 공개이지 그 소프트웨어 제품에 사용된 각종 데이터나 리소스까지 죄다 공개는 아니기 때문에 완전한 기술 유출은 아니다.

대기업의 경우, 자사 직원들만치 꼼꼼하게 감시하지는 않는 하청업체로부터 납품받은 소스에 이런 지뢰가 들어있어서 골탕을 먹는 경우가 있는 모양이다. 그래서 납품 계약을 할 때부터 그 솔루션에 오픈소스 저작권 문제가 확실하게 없다는 걸 확인시키며, 문제가 생길 경우 이런 책임을 지우겠다는 식으로 얘기를 하는 걸 본인은 업계에서도 경험했다.

여담이지만, 요즘은 응용 언어학에서 다루는 말뭉치(코퍼스)에도 저렇게 저작권 바람이 불고 있다.
그래서 국립 국어원에서도 21세기 세종 계획 성과물로서 세종 말뭉치를 배포하다가.. 저작권이 문제가 되는 데이터를 빼고 분량이 다소 감소한 말뭉치를 새로 배포하기 시작했다. 그 얘기를 들으면서 IT업계의 오픈소스 얘기가 문득 떠올랐다.

2.
요번 학기에 학교에서 오픈소스와 관련된 세미나 수업을 들었다. 오늘날 IT 업계에서 오픈소스라는 트렌드가 차지하는 비중을 더욱 절실히 알 수 있었다. 자유 소프트웨어는 무엇이고 오픈소스 소프트웨어는 무엇인지, 그리고 리눅스 진영과 리처드 스톨먼 진영의 차이는 무엇인지 예전에는 거의 관심이 없었고 아는 게 없었는데 이제 좀 어렴풋이 알게 되었다. 유익했다.

오늘날은 정말로 거의 모든 분야에서 github, sourceforge 같은 오픈소스 진영의 저작물을 이용하지 않고는 실용적인 프로그램을 만들기가 대단히 어렵거나 가성비가 안 맞아 의미가 없는 지경이 되었다. 그 오픈소스 진영에서 활동한 이력은 만천하에 공개된 자기 스펙과 자산이 되기 때문에, 당장 소프트웨어의 무료 공개로 인한 금전 손실 이상의 이득이 돌아온다는 말에는 공감이 됐다.

확실히 IT 업계에서 경력을 쌓는 방식의 패러다임이 바뀌긴 했다. 내 지인 중에서도 이 바닥에서 워낙 유명한 사람이 있다. 그 친구는 이런 수업 따위는 들을 필요가 없거나, 아니면 나처럼 따로 자료 찾으며 과제를 낑낑대며 할 필요조차 없이, 평소에 하던 오덕질을 갖고 학점 따위 그냥 날로 먹는 게 가능했을 것이다.

내게 오픈소스라는 건, 이거 소스 코드 하나쯤은 공개해 버려도 내 밥줄에 아무 지장 없고 그것보다 더 나은 것 정도는 얼마든지 또 만들어 낼 수 있고, 이 프로그램의 UI, 데이터 파일들을 업계 표준 관행으로 굳히는 효과까지 노릴 수 있는 괴수들의 전유물일 뿐인 것 같다. =_=;; 물론 그런 진영에서 기여를 하는 프로그래머들이 매우 고마운 대인배인 건 사실이지만, 일단은 무슨 희생, 헌신, 자선 행위라기보다는 “가진 자의 여유” 구도라는 것이다.

또한, 마냥 다 공개하는 게 능사만은 아닐 텐데.. “경쟁자가 따로 이득을 보기 vs 경쟁자를 원천 견제하고 차단하기”라는 결말의 차이가 어떤 과정에서 생기는지 궁금하다. 가령, IBM은 하드웨어계의 오픈소스라 할 수 있는 PC 규격을 내놓았고 그게 결국 세계를 평정하긴 했지만, 이 때문에 정작 자기는 아무 이득도 못 보고 PC 사업에서 손을 떼게 됐단 말이다.

id 소프트웨어에서도 둠과 퀘이크의 소스를 공개하긴 했지만, 그래도 해당 세대의 기술이 충분히 한물 갈 정도로 굉장히 나중에 공개하지 않았던가. 물론, 엔진을 유료로 판매하기도 하는데 소스를 돈 주고 산 업체들이 손해를 보지 않게 하려고 좀 늦게 공개하는 것도 있긴 하지만 말이다.
오픈소스가 과연 개발자와 사용자가 모두 윈윈 할 수 있는 소프트웨어 생태계로 계속 명맥이 유지되는 게 가능할지 지켜볼 일이다.

아 그리고, 이 모든 사실에도 불구하고 <날개셋> 한글 입력기는 완성품을 복사해서 사용하는 것만 무료이지 여전히 소스 비공개 사유 소프트웨어이다. 물론 오픈소스 저작물을 사용한 것도 최소한 C++ 코드 내부엔 전혀 없다. 거기 들어있는 모든 모듈의 모든 기계어 코드는 한 치의 예외 없는 100% 자작이다.
전세계에 한국어와 한글이 쫙 퍼져 있고 세벌식 자판이 주류 글자판이 돼서 누구나 이런 응용 한글 입력 엔진의 필요를 느끼고 있고 사용자가 왕창 많고 거기에 다른 형태의 돈줄까지 있다면야 내가 거기에 공개적으로 기여를 해서 오픈소스계에 등단(?)할 수도 있겠지만.

시장과 수요 자체가 극도로 마이너한데... 공개해 봤자, 한글 IME를 연구하는 일부 극소수 오덕들에게나 좋은 일을 하게 되고, 내가 노력을 보상받는 길도 없고, 날개셋의 리눅스나 맥 버전을 뚝딱 책임감 있게 만들어 줄 사람이 있는 것도 아닌 와중에..
무작정 오픈소스화는 현실에 맞지 않는다고 여겨진다. 오픈소스 진영이 있다고 해서 모든 프로그래머가 흙 파서 먹고 살 수 있는 건 아니다.  8.0 정도가 나온 뒤부터는 내 프로그램의 장기적인 생존 방법에 대해서도 슬슬 생각을 해 봐야겠다.

3.
저건 나름 학점이 붙은 과목이기 때문에, 세미나만 있는 있는 게 아니라 과제도 있었다. 관심이 가는 오픈소스 프로젝트를 하나 선정해서 그에 대해 조사를 하고, 관심이 있으면 자그마한 오타 수정이라도 직접 하나 contribute를 해 보라는 것.

그래서 평소에 프로그래밍 언어에 대한 관심이 무진장 많으며, 나보고도 줄곧 이것저것 다른 언어를 익혀 보라고 권유를 하던 대한민국 오픈소스 진영의 거물이자 프로그래밍의 천재 T모 군의 도움을 받았다. (IOCCC 입상자 ㅋㅋㅋㅋ) 권유의 대상도 예전부터 파이썬, D, 자바스크립트로 계속 바뀌어 오다가 요즘은 Rust로 정착했다.

Rust는 모질라 재단에서 자체 개발한 새로운 절차형 시스템 프로그래밍 언어이다. Java/C# 같은 언어는 full-time 쓰레기 수집기가 갖춰진 별도의 가상 기계에서 동작하는 반면, 이 언어는 그런 형태의 쓰레기 수집기가 없이 C++과 동급의 네이티브 코드로 컴파일되는 언어이다. 메모리 관리 수준은 걍 Windows RT의 C++/CLI와 비슷한 급이 되겠다.

웹 브라우저 렌더링 엔진을 만드는 단체가 웬 PL을 새로 만들게 되었는지는 나름의 이유가 있다. 렌더링 엔진도 응당 GPU와 멀티코어의 도움을 받아야 할 터인데 여러 페이지들이 자연스럽게 멀티코어를 활용하는 게 아니라 단일 페이지가 멀티코어를 적절히 활용하게 만들자니 C/C++로 만들어진 기존 코드들은 답이 없는 지경이었나 보다.

또한 C/C++은 알다시피 빌드 시간이 매우 길고 컴파일러가 잡아 주지 못하는 메모리 관련 버그에 무방비로 노출되어 있는 등, 대형 프로젝트의 진행에 전통적인 한계와 약점도 적지 않다. 그래서 대형 프로젝트의 개발과 유지에 적당한 새로운 언어를 찾았는데 마땅한 대안이 없자 언어를 직접 고안하게 되었다.

이 언어는 모질라 재단에 소속되어 있던 개발자인 Graydon Hoare가 개인적으로 설계하던 언어를 재단이 인수하여 발전시킨 것이다. 지금은 모질라 재단뿐만 아니라 삼성전자도 Rust의 개발을 후원하고 있다고 한다.
아직도 활발하게 개발되고 있어서 0.12까지 나왔는데.. (12는 소수점이 아니라 그냥 정수. 0.2보다 최신 버전임) 긴 베타 기간을 거친 후, 가까운 미래에 Rust의 1.0 정식 버전이 나올 예정이라 한다.

즉 멀티코어 병렬 처리 편의와 자동 메모리 관리, 그리고 성능을 만족시킬 목적으로 만들어진 언어라는 뜻인데, 구글에서 비슷한 시기에 개발한 Go라는 언어하고도 경쟁 구도인 듯하다. 하지만 둘은 패러다임이 좀 다른 언어이다.

Rust에서 모든 값은 그 값이 대입된 변수나 구조체 필드, 넘겨받은 함수 인자 등의 이름에 귀속된다. 이름은 자기에게 귀속된 값에 대한 소유권을 가지며, 다른 이름으로 값을 대입하면 그 이름으로 소유권이 이전된다. 예를 들어, 다른 언어에서 a = b와 같은 대입 연산은 b의 값을 a로 복사하거나, b가 가리키던 객체를 a도 함께 가리키겠다는 의미를 갖는 데 반해, Rust에서는 b가 가지고 있던 값을 a로 이동시킨다는 의미가 된다. C++로 치면, C++11에서 첫 도입된 R-value reference type과 개념적으로 비슷하다.

만약 함수의 리턴값을 받지 않는다던가 하는 일로 인해 소유권을 넘겨주지 못한 채로 이름이 사라지게 되면, 거기에 귀속되었던 값도 함께 사라지면서 그 값을 담았던 메모리도 해제되게 된다. 프로그래밍 언어 이론의 관점에서 보자면, binding과 object의 생명 주기를 일치시킨 셈이다.

Rust 컴파일러는 컴파일 단계에서 소유권이 어떻게 이전되는지를 모두 추적할 수 있으며, 필요한 메모리 할당 및 해제 코드를 컴파일 중에 정확한 위치에 삽입한다. 이런 방법으로 Rust는 런타임 오버헤드가 없는 안전한 메모리 관리를 이루어 낸다.
일단 대충 이 정도 조사하면서 그쪽 진영에서 뜨고 있는 이슈와 작업 진행 방식들을 조사해 봤다.

Posted by 사무엘

2014/12/14 08:34 2014/12/14 08:34
, , ,
Response
No Trackback , 4 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1039

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

Comments List

  1. 김재주 2014/12/14 14:36 # M/D Reply Permalink

    누군지 알 것 같군요 ㅋㅋ T는 예전에 쓰던 닉네임의 앞글자죠?

    Rust는 C언어가 바라보는 기계 추상화를 그대로 사용하면서도 Functional Language들의 특징을 가지고 있습니다. 보통 Functional Language들에서는 값을 한번 바인딩하면 이 변수는 불변값이라 고칠 수 없고 이를 바꾸고 싶다면 함수 호출을 해서 State 자체를 변경해야 하는 식의 접근방법을 가지고 있었는데 Rust의 객체 모델도 어떤 의미에서 비슷하죠. 함수형 프로그래밍 언어로 작성된 프로그램을 거의 그대로 옮길 수 있는 것도 그 때문이고요. 불변값이라면 당연히 다른 이름으로 바인딩되는 일이 없을 테니까요.

    지금까지 수많은 프로그래밍 언어들이 등장하고 서로 장점을 흡수하며 발전해왔는데, Scala나 Python 같은 일부 언어를 제외하고는 상업적으로는 별로 성공하지 못했죠. 오픈소스 계에서 제 나름대로 큰 규모인 모질라 재단에서 밀어주고 있는 Rust는 성공할 수 있을지 궁금하네요.

    1. 사무엘 2014/12/14 20:00 # M/D Permalink

      네, 본문에서 언급하지는 않았지만 Rust는 단순 데이터 병렬처리/절차형 특화 언어 이상으로 함수형 프로그래밍 속성이 강하더군요.
      파이썬, 스칼라 역시 학교 수업 때문에 간단한 프로그램을 짜는 용도로 잠깐 써 봤습니다. 스칼라는 자바스크립트와 비슷하다는 생각을 했고요.
      제가 어쩌다가 T모 같은 엄청난 괴수와 아는 사이가 됐는지 참... ^^;;

  2. eson 2014/12/26 13:28 # M/D Reply Permalink

    한글립력기 개발자 이신가 보네요. 그리고 오픈소스에 대한 고민도 많으신 것 같습니다.
    그리고, 적으신 것 처럼, 오픈소스화 하는 것이 마냥 능사는 아닙니다.
    오픈소스를 해서 좋을 분야가 있고, 해서는 안될 분야가 있을 겁니다.
    경쟁자만 좋게하는 호구가 되지 않기 위해서는, 많은 고민과 전략적인 추진이 필요하겠죠.
    특히, 명성/실력 외에 뭔가 경제적 이득이 필요하다고 생각한다면,
    큰 수정 없이 바로 사용할 수 있는 코드를 오픈소스화 하는 것은 지양해야 될 겁니다.
    코어에 해당하는 부분만 오픈소스화 하고 사용될 제품에 커스터마이징을 해야 하는 수준까지 하는 것이 맞을 것이구요.
    IBM 을 예로 드셨는데, IBM 은 오픈소스라기 보다 표준화라고 보시는게 맞을 겁니다.
    오픈소스와 표준화는 다른 부분도 많고 비슷한 부분도 많은데,
    비슷한 부분을 짚어 본다면, 오픈하고 나서 지속적으로 관리 하면서 주도권을 계속 가질려는 노력이 필요하다는 겁니다.
    그런 점에서, 오픈소스를 한다는 것이 어렵다고 말하는 것이구요.

    1. 사무엘 2014/12/26 14:49 # M/D Permalink

      오옷.. 여러 조언에 감사드립니다. 꽤 고수 프로그래머의 포스가 느껴지는데요. ^^

Leave a comment

1.
비교적 최근에 알게 된 건데..
C/C++에서 default문은 굳이 case의 맨 마지막에 있지 않아도 된다. =_=;;;
그래서 case 1: .. default: ... case 2: 이런 식으로 라벨들이 따라오고 일부 항의 끝에 break까지 생략되어 있다면 생각보다 꽤 기괴한 로직을 구현할 수도 있다.

뭔가 발상의 전환이 느껴진다. 어떻게 활용 가능한지는 더 생각을 해 봐야겠다.
물론 파스칼의 case else문은 그렇지 않으며, 반드시 맨 마지막에 와야 한다.

2.
컴퓨터에서 부동소수점은 연산을 하는 게 까다로워서 하드웨어적인 도움을 진작부터 받아 왔다. 하지만 연산뿐만 아니라 이미 있는 수를 10진법 형태의 문자열로 나타내거나 문자열로부터 역변환하는 것도 생각보다 몹시 어렵다. 에니악 같은 초창기 컴퓨터가 괜히 굉장한 비효율을 감수하고라도 10진법 기반으로 설계되었던 게 아닌가 싶다.

이와 관련된 정보는 printing float numbers 같은 키워드로 구글링을 하면 얻을 수 있다.
이 작업은 어떤 f * 2^e에 대해서 f' * 10^e' <= f * 2^e < (f'+1) * 10^e'가 성립하는 최소의 f'/e'를 찾는 것인데, 결국 컴퓨터 프로세서가 기본 단위로 처리 가능한 범위를 넘는 big number 연산까지 필요할 정도라고 한다.

2진법 부동소수점은 1/2^n이 아닌 사실상 거의 모든 소수들이 순환소수로 표현되어 뒷부분이 잘린다. 0.1, 0.3 이런 소수도 컴퓨터에서 표현되는 형태는 순환소수라는 뜻이다. 순환소수를 화면에 출력할 때는 그래도 10진법 유한소수인 것처럼 표시하는 것이니 컴퓨터에서 부동소수점은 본질적으로 100% 정확한 정밀도가 보장되지 않는 셈이다.

3.
Visual C++ 201x는 200x에 비해서 매우 강력해진 인텔리센스, 새로 디자인된 IDE, C++1x 언어 기능 같은 게 부각되는 편이다. 하지만 그것 말고도 IDE가 매우 편리해진 면모가 최소한 둘 있는데...
이제 IDE의 버전이 올라갈 때마다 프로젝트 파일을 매번 강제로 업그레이드 하지 않아도 되고, 그리고 컴파일러 툴킷을 직접 고를 수 있게 된 점이다.

이로써 IDE가 개별 프로젝트나 빌드 툴과는 좀 더 독립한 구도가 됐다.
이것은 딱히 새로운 기능 추가가 아님에도 불구하고 옛날에 도스 시절에 멀티부팅 기능이 추가된 것만큼이나 매우 편리해진 조치이다. (autoexec.bat / config.sys에 일종의 조건부 실행 로직을 추가하여, 부팅 configuration을 직접 고를 수 있는 것)

4.
본인은 예전에 precompiled header에 대해서 글을 쓴 적이 있다. 그때에도 언급했지만, 본인은 성질이 좀 급한 관계로 PCH 없이 소스 코드가 엄청난 분량의 인클루드 반복 때문에 컴파일 속도가 굼뜨는 걸 못 참는다.
그런데, 프로젝트 전체를 분석하면서 중복 인클루드로 판단되는 파일들을 자동으로 감지해 주는 기능이 있으면 좋지 않을까? 그것들을 stdafx.h로 대체하고 그 파일에다가 인클루드들을 몰아 넣는 것이다. 물론, 빈번하게 인클루드되긴 하지만 수정도 빈번하게 되는 편이기 때문에 pch에다 넣어서는 안 되는 것 판단은 사람이 하면 된다.

이건 마치 데이터베이스에서 테이블과 쿼리들을 분석하면서 자주 쓰이는 테이블 내지 애트리뷰트는 인덱스를 넣는 최적화 기능과 비슷한 구석이 있는 것 같다.

5.
자동차의 특성이 컴퓨터 소프트웨어의 특성과 매우 비슷하다고 여겨지는 점이 몇 가지 있다.

  • 내릴 때 실내등이나 각종 라이트가 완전히 꺼졌는지 확인하고, 블랙박스는 장시간 주차시 자체 전원 차단 기능이 켜져 있는지 확인해야 한다. → 메모리 leak 예방과 개념적으로 일치한다.
  • 급발진: 아주 희귀한 상황에서 갑자기 발생하는 치명적인 버그에 해당한다.
  • 자동 vs 수동 변속기: 옛날이라면 컴파일러가 자동 생성한 코드 vs 수제 어셈블리 코드.. 정도와 대응하고, 지금이라면 managed vs native 코드와 대응하는 듯하다. 요즘은 자동 변속기도 어지간한 수동 조작에 뒤쳐지지 않을 정도로 효율이 굉장히 좋아졌으니 말이다.

6.
세상에는 분야를 불문하고 여러 단체가 공동으로 뭔가 통합 작품이나 프로토콜을 만드는 경우가 있다. 따지고 보면 킹 제임스 성경도 성공회와 청교도가 연합해서 작업한 그런 통합 작품이다.
하지만 그런 통합 작품이 실질적인 통합을 이루지 못하고 그냥 기여를 가장 많이 한 단체의 전유물로 전락해 버리는 경우도 있다. 그런 예를 몇 가지 들어 보자면 다음과 같다.

  • HFT 통합 글꼴: 지금은 아래아한글밖에 안 쓰는 완전 옛날 유물이 됐다.
  • 공동번역 성서: 에큐메니컬 성경이라지만 현실은 역시 천주교 전용 성경일 뿐이다.
  • 타이젠 OS: 당초 취지와는 달리, 컨소시엄을 구성하던 협력사들은 다 빠져나가고, 사실상 삼성 전자밖에 관심이 없는 모바일 OS가 됐다.

삼성은 예전에도 아래아한글과 MS 워드가 뻔히 있음에도 불구하고 수익성과는 별개로 훈민정음을 오랫동안 밀었다.
그런 것처럼 모바일 OS 하나 정도는 우리가 자체 기술을 갖고 있어야 한다는 차원에서 타이젠을 꾸준히 미는 듯하다. 안드로이드와 iOS의 텃새에도 불구하고 정말 막대한 자금을 투자하여 타이젠 앱 프로그래머를 육성하는 중이다.

7.
비주얼 C++이 컴파일러, IDE, 디버거 등 모든 차원에서 64비트를 완벽하게 자체 지원하기 시작한 건 2005부터이다.
그런데 나는 그 시절부터 굉장히 궁금했던 게...
devenv IDE는 예나 지금이나 32비트 프로그램임에도 불구하고 어떻게 64비트 바이너리를 아무 제약 없이 바로 디버깅 하고 메모리 내부를 잘도 들여다볼 수 있느냐 하는 것이었다.

운영체제 차원에서 64비트와 32비트가 서로 얼마나 격리되어 있는지는 이 바닥에 짬밥깨나 있는 프로그래머라면 누구나 잘 알 테고. 그러니 결론은 하나. 별도의 64비트 EXE를 띄워서 IPC(프로세스 간 통신)를 하지 않고서는 이 정도의 자연스러운 연계는 절대 가능하지 않다는 것이었다.

확인해 보니 이 예상이 맞는 듯하다. 32비트 프로그램을 디버깅 할 때는 안 그러는데 64비트 프로그램을 디버깅 할 때는 msvsmon이라는 일종의 64비트짜리 원격 디버그 호스트 프로그램이 같이 뜬다. 그리고 디버깅이 끝나면 얘도 실행이 종료된다. EXE 크기가 수MB에 달하는 결코 작지 않은 프로그램이긴 한데, 얘가 뭔가 하는 일이 많은 것 같다.

8.
끝으로.. 시간 복잡도, 공간 복잡도라고 하면 전산학에서나 다루는 무슨 뜬구름 잡는 개념처럼 들리기 쉬운데, 현실에서도 의외로 간단한 예가 있다.

먼저, 자전거를 잠그는 자물쇠로는 열쇠 방식이 있고 숫자 다이얼 방식이 있다.
전자는 열쇠만 있으면 금방 자물쇠를 딸 수 있다. 후자는 번거로운 열쇠를 챙기지 않아도 되지만 원하는 숫자까지 다이얼을 맞추고, 다시 잠김 모드로 옮기는 시간이 오래 걸린다.

나는 프로그래머로서 이걸 경험할 때마다 시간/공간의 tradeoff라는 생각이 들곤 한다. 열쇠 자물쇠는 열쇠라는 공간이 필요하고 열쇠를 분실하지 않게 주머니 관리를 잘 해야 하지만, 열고 잠그는 건 배열 테이블을 참조하듯이 O(1) 시간 만에 즉시 끝낸다.
숫자 자물쇠는 열쇠가 없어도 되어 심리적으로 편하지만, 다이얼을 맞추기 위해 마치 매번 탐색을 하고 연결 리스트의 노드를 찾듯이 O(n) 시간 작업을 매번 해야 하기 때문이다.

옛날에 브라운관 모니터가 어느 수준 이상의 대형화가 도저히 불가능하고 LCD 모니터에 밀려 도태한 주 이유가..
바로 화면 크기 n에 따른 공간 복잡도가 O(n^3)이나 되었기 때문이다. 무게나 가격까지 그 정도로 급격하게 증가했고.
색감이 좋다고는 하지만, 그래도 전자총을 뒤에서 화면 크기만큼이나 거리를 두고 쏴 줘야 하니, 화면의 크기가 커질수록 어마어마한 양의 공간을 잡아먹는 것을 감당할 수가 없었다.

그리고 지구본(지구의)도 생각난다.
알 만한 분들은 이미 다 아시겠지만, 메르카토르 도법 평면 지도에는 아프리카 대륙은 실제보다 굉장히 작게 나오고, 그린란드 내지 러시아는 말도 안 되게 면적이 부풀려져 있다.

왜곡 없이 둥근 지구 위에서 세계 각국의 위치에 대한 실질적인 공간 감각을 키우는 데는 지구본 만한 게 없다. 그리고 지구본이 비치된 책상 앞에서 누가 머리 싸매고 있으면 왠지 간지 나고 멋있어 보이기도 하나..

지구본 얘도 크기에 따른 공간 복잡도가 O(n^3)인 부피를 차지하는 물건이고, 안 쓸 때 딱히 접거나 분해해서 부피를 축소시키는 방법도 여의치 않다 보니 실용성이 떨어진다.
현실적으로는 입체 효과까지 지원하는 구글 어스 같은 지도 어플이 대안이지만.. 그래도 이런 건 실물이 아쉽기도 하다. (어플은 여러 사람이 한 지구의 여러 지점을 한데 공유하면서 서로 비교할 수 없음)

다시 프로그래밍 얘기로 돌아오자면, 현실에서는 단순무식한 알고리즘이 O(n^2) 정도의 복잡도가 나오는 게 약간 머리를 굴림으로써 O(n log n) 정도로 최적화되는 경우가 많은 듯하다. 정렬이 대표적인 예이고, 그 외에도 빠른 푸리에 변환이라든가 최장 증가 수열 찾기 문제도 이런 범주에 속한다.

그리고 단순무식하게 접근했을 때 지수함수 복잡도가 되는 게, 다이나믹 프로그래밍으로 중간 계산 결과를 저장함으로써 메모리 복잡도 O(n^2), 시간 복잡도 O(n^2) 내지 O(n^3)이 되는 경우가 많다.
아예 O(n)으로 간단하게 줄어드는 건 피보나치 수열이나 팩토리얼을 구하는 것처럼 문제 자체가 극도로 단순한 경우밖에 없을 것이다.

Posted by 사무엘

2014/11/19 08:22 2014/11/19 08:22
, ,
Response
No Trackback , 4 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1030

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

Comments List

  1. Lyn 2014/11/21 15:02 # M/D Reply Permalink

    아 지저분한 C++ ㅋㅋ

  2. Lyn 2014/11/21 15:04 # M/D Reply Permalink

    CRT 시절에

    http://tinman.co.kr/board/bbs/board.php?bo_table=NEWS&wr_id=516#.VG7VqlWsVaw

    이런 기술이 있었다면 수명이 더 길어졋을지도 ㅎㅎ
    물론 lcd만큼 얇게 만들긴 무리겠지만요

    1. 사무엘 2014/11/21 15:47 # M/D Permalink

      1. C++은 정말 계속해서 기괴한 문법 용례가 뒤늦게 발견되더군요. ㅎㅎ
      2. 오옷~ 아주 짧은 거리에서도 왜곡 거의 없이 엄청난 양의 시야를 담아 내는 초광각 카메라...가 입력 버전이라면
      저 프로젝터는 출력 버전이네요!

    2. 김재주 2014/11/26 17:02 # M/D Permalink

      오, 재미있는 기술이네요.

      저런 기술을 응용하면 HMD(헤드마운트디스플레이)의 가장 큰 단점인 큰 픽셀 크기 문제를 해결하는 데도 도움이 될 것 같은데요?

      그러고 보니 소니도 HMD 선도 기업 중 하나네요. 조만간 엄청난 물건이 튀어나올지도 모르겠어요.

Leave a comment

고전 게임 황금도끼에 대해서 아주 오래 전에 글을 쓴 적이 있었는데 또 내용을 첨언할 게 생겼다.
그 글은 이 블로그가 생기기도 전, 제로보드 시절에 썼던 글이니 시기로는 2009년이나 그 이전의 정말 옛날 글이다.

황금도끼는 오락실용 원판이 나온 이후로 다양한 플랫폼으로 이식되었다.
그 중 Mega Drive/Genesis 판(게임기용?)은 레벨을 좀 더 추가하고 Duel이라는 결투 모드를 넣는 등 게임 시스템에 변화를 좀 넣었는데, PC(도스)용 버전은 바로 이 버전에서 파생되어 나왔다. 원판이 1989년에 나왔고 PC용이 그 이듬해에 나왔다는 것은 페르시아의 왕자와 일치하는 내력이다.

Mega Drive/Genesis에서 추가되고 PC용에서도 도입된 결투 모드는 스토리(아케이드)를 따라 진행되는 정식 게임이 아니라, 주인공이 고정된 arena에서 정해진 적들과 PvP를 벌이는 일종의 대전 게임이다. 첫 레벨에서는 그냥 잡몹 한두 마리만 나오지만, 레벨이 올라갈수록 보스급 몬스터가 등장하면서 진행이 어려워진다.

결투 모드에서는 아케이드 때와는 달리 몹도 체력이 화면에 나온다. 정확히는 화면에 존재하는 모든 몹들의 체력의 합임. 덕분에 적을 얼마나 더 두들겨 패야 이번 레벨을 끝낼 수 있는지를 얼추 알 수 있다.

사용자 삽입 이미지

사실, MMORPG나 전략 시뮬, 아니면 아예 1:1 대전 액션 게임 같은 장르 말고 통상적인 액션/아케이드형 게임에서 내가 싸우고 있는 몹의 체력을 알 수 있는 게임은 별로 없다. 페르시아의 왕자는 적과 싸우는 것은 1:1 대전 컨셉을 표방했기 때문에 친절하게 적의 HP가 화면에 나오는 것일 테고, 황금도끼도 아케이드가 아닌 결투 모드에서는 그런 컨셉을 추구하여 적의 HP를 표시해 주는 것 같다.

단, PC용의 경우, 해골 두 마리가 등장하는 레벨 9 이상부터는 주인공과 몹들의 HP가 화면에 안 나오기 시작한다. 화면에 아무 정보도 표시되지 않으며, 이 덕분에 부하가 좀 줄어들어서 게임의 진행이 약간 빨라지기도 한다.

사용자 삽입 이미지

Mega Drive/Genesis 판에서는 레벨이 올라갈수록 날이 점점 어두워져서 밤이 되는 효과가 있으나, PC용은 그런 것도 없다. 아무튼...
그렇게 레벨 13까지 가면 빨간 기사와 빨간 뚱보에 잡몹 둘까지.. 총 4마리나 되는 몬스터가 나타난다.

사용자 삽입 이미지

그런데 문제는 이 레벨을 깬 다음이다. 무슨 파일이 없는지 다음 디스크를 넣으라는 메시지와 함께 게임 진행이 중단된다.
이건 뭐 취소할 수도 없고 프로그램을 종료할 수도 없다. 황금도끼를 돌리고 있는 도스 에뮬레이터를 강제 종료하는 수밖에 없다.

사용자 삽입 이미지

도대체 왜 이러는 것일까?
혹시 프로그램 배포에 문제가 있는 게 아닌가 싶어서 국내외 여러 곳에서 서로 다른 황금도끼 파일을 구해 봤지만, 파일 구성은 변한 게 없으며 레벨 13 이후에 저렇게 진행이 중단되는 건 여전했다.

그럼에도 불구하고 유튜브를 뒤져 보면, 황금도끼 PC판에서 레벨 13 이후에도 결투를 진행하는 플레이 동영상이 존재한다. 세상에! (☞ 링크 클릭. 2분 58초부터)
레벨 14는 아케이드 레벨 6의 보스인 Death Adder 주니어와 부하 해골 두 마리이며, 레벨 15는 아케이드 마지막 레벨의 최종 보스인 그 시커먼 Death Adder와 부하 해골 두 마리이다. 그리고 이게 결투의 마지막이다.

이 사람은 어떻게 해서 레벨 14와 15까지 잠금해제를 한 걸까?

결론부터 말하자면, 뜻밖에도 인터넷에 굴러다니는 황금도끼 배포본에 일부 파일이 누락됐거나 문제가 있는 건 아니다.
레벨 14~15의 리소스도 다 준비돼 있는데 프로그램 자체에 버그가 있어서 그걸 제대로 인식을 못 한 거라고 한다.
외국의 어느 리버스 엔지니어링/해커 팀에서 해당 프로그램을 기계어 코드를 일일이 분석하면서 디버깅한 끝에 그 버그가 무엇인지를 알아냈다. 이 문서를 참고하시라.

황금도끼 PC판은 gold.exe라는 실행 파일이 lzexe라는 과거의 16비트 도스용 실행 파일 압축기로 압축되어 있다.
그런데 저 글을 쓴 해커는 unlzexe가 있는 줄 모르고, 실행 파일 내부에 들어있는 압축 해독 루틴과 압축된 데이터를 읽고 따라가면서 그냥 근성으로 실행 파일의 로직을 추적했다고 한다.;; 8086 어셈블리와 도스 인터럽트 API에 통달한 사람이라면 최소한 80년대 이전생의 old timer일 텐데, unlzexe를 모르는 것도 신기하다만... 아무튼 괴수.

물론, 그 lzexe를 만든 사람도 괴물인 건 두 말할 나위가 없고 말이다. (ioccc 입상자이며, lzexe는 그가 겨우 고등학생일 때 만든 작품이다.. 쩝~)

자, 저 문서의 내용을 요약하면 이렇다.
문제의 원인은 레벨 14로 갈 때 프로그램이 잘못된 파일 이름을 요청한다고 한다. 파일 이름에 아스키 코드 4번 제어 문자가 들어있다고 하니 이는 명백한 오류이다.

역추적을 해 보면 드디어 레벨별로 소환할 몬스터 정보가 담긴 테이블에까지 도달하는데..
레벨 14와 15를 보면 비정상적인 값이 들어있다. 메모리의 내용을 강제로 일관성 있게 수정해 주니 놀랍게도 모든 결투 레벨이 정상적으로 진행된다.

이런 걸 찾아내다니 저 해커에게 경의를 표하는 바이다. 정말 안 되던 걸 되게 만든 사람이다.
SI가 가리키는 값을 보면 남자 여자 소형 잡몹은 따로 처리해 주는 게 없고, 0xA는 그 chicken leg 탈것이고 0xB+0x10은 붉은 용, 0xB+0x11은 푸른 용이다. 0x6은 대머리 보스, 0x3은 해골, 0x8은 칼 든 기사 보스, 그리고 0x7은 Death Adder의 스프라이트에 대응한다는 걸 알 수 있다.

저 메모리 테이블은 다행히 황금도끼의 실질적인 실행 파일에 해당하는 axe.dat에 고스란히 들어있다. unlzexe로 얘의 압축을 푼 뒤, 메모리를 패치하듯이 잘못된 값이 들어있는 부분(오프셋이 대략 0xFFxx대에 있음)을 고치면.. 레벨 14~15가 모두 잠금해제된 황금도끼를 즐길 수 있다~!

옛날에 게임 위저드 32를 이용해서 주인공의 HP를 강제로 늘리거나 심지어 값이 바뀌지 않는 무적 상태를 만들어 놓고 게임을 즐긴 적도 있다. HP 한 칸이 내부 HP 4에 대응하는 형태이기 때문에 비교적 쉽게 메모리 주소를 찾을 수 있었다.
지금도 그런 해킹 프로그램이 있다면 저 테이블을 메모리에서 찾아내서 결투 모드 버그 정도는 런타임 때 고칠 수 있을 듯하다.

디버깅을 할 줄 알면 이런 것도 다 가능하다는 걸 알 수 있었다.

Posted by 사무엘

2014/08/27 08:38 2014/08/27 08:38
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1000

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

Leave a comment

캡챠 이야기

요 근래부터 이 블로그에도 국내외 광고 스팸 댓글이 급증하고 있어서 대책이 좀 필요한 것 같다.
옛날에는 외국 발 스팸 트랙백이 아주 가끔 걸리는 듯했는데 요즘은 트랙백은 없고 그냥 닥치고 쓰레기 댓글뿐이다.
일단 영어만 들어있는 텍스트는 무조건 차단하고, 요주의 키워드와 IP는 블랙리스트로 등록해 추가로 차단하고 있는데도 가끔은 그런 필터를 통과한 놈들이 게시되곤 한다. 그런 건 내가 보이는 족족 수동으로 제거하는 중이다.

옛날에 제로보드 시절엔 비로그인 사용자가 댓글/답변을 올릴 때 캡챠를 입력하게 하는 플러그인 내지 소스 추가 패키지가 있어서 본인 역시 제로보드 게시판을 운영할 땐 그걸 유용하게 썼었다. PHP 코드만 돌아가는 게 아니라 리눅스용 실행 파일이 서버에서 실행되어 캡챠 이미지(PNG)를 실시간으로 생성해 냈다.
TextCube용으로도 그런 플러그인이 없을 리는 없겠지. 조만간 도입해야 할지도 모르겠다.

여기서 캡챠란 무엇인지 모르시는 분을 위해 설명하자면..
사용자가 서버로 보내는 게시물 내지 회원가입 신청이 봇/매크로/오토 같은 컴퓨터가 생성한 게 아니라 진짜 사람이 하는 게 맞음을 입증하기 위해, 사람만이 판독할 수 있게 비비 꼬아 놓은 랜덤하고 이상한 글자· 그림이 의미하는 값을 입력받는 인증 장치를 말한다.
gotcha!와 비슷한 어감 때문에 좀 얍삽하다는 심상이 느껴지는데, CAPTCHA는 나름 영단어 이니셜이다.

기계가 인식할 수 없는 이미지를 기계가 생성해 낼 수 있을까?
패턴인식 기술의 발달로 인해 어지간히 허술한 캡챠를 기계가 인식하여 뚫는 기술도 발달하고, 그에 맞서.. 진짜 사람조차 인식 못 할 정도로 난해하지 않으면서 적당히 기계만 엿먹이기에 충분할 정도로 어려운 캡챠를 생성하는 기술을 개발하는 것도 만만찮은 수준이다.

(첨언하자면, 오늘날은 무질서로부터 질서를 도로 찾아서 복구하는 기술이 매우 경이로운 수준이다.
물리적으로 어지간히 손상을 준 하드디스크로부터도 최대한 데이터를 복구해 낸다거나, 심각하게 BLUR된 이미지로부터도 놀라울 수준으로 원래 이미지를 복원한다거나. 캡챠를 뚫는 것도 그런 맥락에서 살펴볼 수 있을 듯하다.)

도스 시절에 '맥스'라는 유사 채팅 프로그램이 있었는데 혹시 기억하는 분 계시는지?
얼굴이 안 보이는 공간에서 어떤 사람이 상대방과 채팅을 했는데, 대화 상대가 패턴이 뻔한 '봇'이 아니라 진짜 사람이 맞는지를 같은 사람이 분간할 수 없었다면 그 대화를 생성한 AI는 '튜링 테스트'를 통과했다고 간주된다.
그런데 캡챠는 역으로 컴퓨터가 이 입력이 진짜 사람이 맞는지를 판단하는 것이므로, 일종의 '역방향 튜링 테스트'에 가까운 셈이다.

스팸 게시물을 막기 위해 도박, 성 등 여러 불건전한 분야의 금지어들을 지정해 놓은 게시판이 많다.
그런데 게시물에 금지어가 우연히 포함되었다고 해서 아무 설명도 없이 없이 글의 등록을 거부하면..
진짜 사람이 그런 거부를 당했을 때 그 사람을 굉장히 화나게 만들 수 있다.

또한 반대로 'xxx는 금지어입니다'라고 매번 친절하게 알려 주면.. 스패머들은 그 피드백 결과를 바탕으로 금지어만 교묘하게 피해가는 스팸 게시물을 만들어 뿌리게 된다. 이 역시 딜레마다.

따라서 둘을 절충하는 방법으로는...
일단은 캡챠 같은 거 없이 깔끔하게 글을 접수한 뒤,
본문이 금지어가 포함돼 있거나 특정 패턴을 만족하여 광고글로 의심되면... 그때는 금지어 같은 광고글 의심 판정 근거를 노출하는 대신, 가만히 캡챠만 좀 입력해 보라고 friendly하게 추가 요청을 하는 게 바람직하지 않은가 싶다. 한 마디로 말해 선패턴 후캡챠 전략인 것이다.

그게 익명 사용자에게 당장 깔끔한 첫인상을 주며,
사용자가 댓글을 올리지 않고 그냥 글을 읽기만 하는데도 복잡한 이미지 프로세싱이 필요한 캡챠를 매번 생성하는 것보다 서버 부담도 줄이는 일거양득 방법일 것이다.

특정 패턴이란 굳이 단어가 아니어도 되고 NLP 기술이 아니어도 된다. 지나치게 URL 링크가 많은 글, 특수문자가 한글과 너무 지저분하게 뒤죽박죽 섞여 있는 글만 찾아도 된다. 이 정도만 돼도 스패머가 제아무리 금지어 필터를 피하려고 잔머리를 굴린들 광고글 따위는 모조리 걸러낼 수 있다.

사이버 공간에서 이런 광고 댓글 스패머는 국제 민폐요 인터넷 트래픽을 좀먹는 공해덩어리 떨거지들이다.
하지만 겨우 얘네들 때문에 게시판을 회원만 글을 올릴 수 있게 바꾼다거나, 심지어 누가 올려 놓은 글은 관리자가 일일이 사전 검열(?)한 뒤에야 공개 게시한다거나 하는 건.. 빈대 잡으려다 초가삼간 다 불태우는 수준의 극단적인 짓일 것이다. 아무쪼록 인간과 기계의 경계를 허물기도 하고 강화하기도 하는 기술의 발달이 절실하다.

이미 널리 알려져 있기도 하겠지만, 캡챠로부터 유래된 재미있는 발상이 있다.
포털 사이트 같은 델 가입할 때, OCR 프로그램이 제대로 인식하지 못한 어떤 책 스캔 이미지 조각에 든 문자열을 캡챠하고 같이 입력하게 한다. 그래서 캡챠를 맞게 입력한 여러 사람들이 동일한 이미지 조각에 대해 일치하는 문자열을 입력했다면, 그 이미지에 담긴 텍스트는 그게 맞다고 데이터를 수집하는 것이다.

캡챠 타이핑과 동시에 real-world 캡챠도 같이 타이핑하여 전세계 네티즌들이 힘을 합쳐 문헌의 전산화(?)에 기여하게 하는 것이다. 일명 '리캡챠 프로젝트'라고 한다. 구글, 페이스북, 아마존 등 세계 유수의 사이트들이 리캡챠 엔진을 활용 중이라고 한다.

Posted by 사무엘

2014/08/16 08:22 2014/08/16 08:22
, ,
Response
No Trackback , 7 Comments
RSS :
http://moogi.new21.org/tc/rss/response/996

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

Comments List

  1. 김재주 2014/08/16 14:00 # M/D Reply Permalink

    구글 맵의 건물번호 및 번지 인식용 신경망의 정확도가 사람을 뛰어넘었죠. 이걸 활용해서 같은 구글의 리캡챠를 완전 무력화할 수 있는 봇이 나와서 화제가 됐었습니다.

    그리고 구글의 보이스 캡챠도 구글의 음성 검색 기능에 무력화되어 팀킬 제국(...)의 악명을 드높인 바 있습니다

    1. 사무엘 2014/08/16 18:54 # M/D Permalink

      창과 방패를 동시에 만드는 외계인 고문 기업이다 보니 그런 일도 있군요.. ㄷㄷㄷ

  2. Lyn 2014/08/22 07:29 # M/D Reply Permalink

    맥스...

    초딩시절에 참 신기해 했었죠. 최근엔 맥스 개발자와 같이 일하는 (뭐 만나거나 그런건 아니고 어쩌다보니 온라인상으로 ...) 상황도 벌어지지만요

    1. 사무엘 2014/08/22 08:52 # M/D Permalink

      Lyn 님은 개발자 인맥이 도대체 어디까지입니까~!!! ^^

    2. Lyn 2014/08/22 09:04 # M/D Permalink

      맥스 개발자 분이 지금 모바일 게임프로그래머시라 ^^; 같은 분야에 있으니 이런 신기한 일도 생깁니다.

      과거 같은 Borland 계열 툴을 사용했었다는 이유도 있구요.

  3. 세벌 2014/09/02 19:25 # M/D Reply Permalink

    여긴 제가 만든 사이트보다 침입자가 많군요. 제가 만든 http://sebul.co-story.net/q2a/ 에 외국발 스팸( 한글 한 글자도 안 들어간 쓰레기 글)이 종종 올라오기에, 한글이 포함되지 않은 글은 쓰기 안되도록 코드를 살짝 바꾸었더니 그 후로는 스팸이 없네요. :)

    1. 사무엘 2014/09/03 11:14 # M/D Permalink

      요즘은 한 달쯤 전에 비해서는 좀 잠잠해졌습니다. 스패머들이 기세가 꺾였는지, 아니면 서버 호스팅 업체에서 자체적으로 차단 조치를 취했는지는 모르겠습니다.
      스팸 댓글 얘기는 아닙니다만, 하도 악성 트래픽이 들끓어 대니까 일부 호스팅 업체는 secure 접속이 아닌 FTP/텔넷 같은 건 아예 외국 발 접속을 무조건 막아 버리기도 했지요.

Leave a comment

노트북 PC에서 가장 흔하게 발생하는 잔고장의 양대 산맥은 (1) 액정 화면 접촉불량과 (2) 키캡 빠짐이라 해도 과언이 아닐 것이다.

본인이 개인용 노트북 PC를 사용한 지가 15년이 넘었고 지금 쓰는 맥북은 제 5대 컴퓨터인데,
예전에 쓰던 노트북들은 쓴 지 1년 남짓 되면 저런 잔고장이 어김없이 발생하곤 했다.
물론, 언제나 새 노트북만 쓴 게 아니라 중고나 준중고를 쓴 것도 있기 때문에, 품질이 원래부터 안 좋아서 그랬던 것일 수도 있다.

(1)은 화면을 편 각도에 따라서 붉은 세로줄이 나타났다가 사라진다거나, 화면이 아예 꺼진다거나 하는 등 굉장히 성가신 증상이다. 이것 때문에 서비스센터 들러서 수리 받느라 신경 쓰이고 시간· 돈이 낭비되는 것도 과거엔 상당한 수준이었다.

(2)도 노트북 키보드가 데스크톱 PC 키보드보다 약해서 발생하는 고질적인 문제인 듯.
자주 누르는 편인 화살표, 엔터, space, shift 같은 게 잘 빠졌으며 가끔은 문자 키가 빠지기도 했다. 키캡이 없어도 해당 키를 누르는 것 자체는 가능하지만, 빠른 타자와 원활한 컴퓨터 사용에는 애로사항이 꽃핀다.
빠진 키캡 한두 곳만 수리가 되지는 않는 경우가 많다. 그래서 키캡이 대여섯 개쯤 빠질 때까지 컴을 더 쓰다가, 나중에 한꺼번에 키보드 기판을 교체하곤 했던 것 같다. 돈 몇만 원 정도는 깨진다.

그런데.. 지금 쓰는 맥북은.. 쓴 지 2년이 넘었지만. 위의 잔고장이 지금까지 전혀 발생한 적이 없다. 엔터 키가 약~간 달랑달랑거리긴 하지만 그래도 키캡이 완전히 빠진 건 없다. 잡느님의 손길이 담긴 품질 덕분인 걸까? 놀랍다.
맥북은 한번 병원 치료를 받으면 일반 놋붉에 비해 수리비가 작살나게 깨진다는 게 겁나긴 했었지만, 아직까지 A/S를 받을 일 자체가 전혀 없었다.
(참고로 난.. 흔들리는 교통수단 안에서도 쓰고 몇 번 떨어뜨린 적도 있고, 노트북 PC를 시도 때도 없이 험악하게 혹시시키며 쓰는 편이다.)

따라서 애플케어를 구입 안 한 게 현재로서는 결과적으로 이익이었다.
난 비록 맥북으로도 95% 이상의 시간은 맥OS가 아닌 Windows만 쓰며 지내지만 맥북의 이런 품질은 만족스러우며 인정할 만하다.

다만, 세월 때문인지 배터리 용량은 예전보다 확실히 줄어들었다. 2시간 남짓이면 간당간당하다. 배터리는 아직 구경도 못 해 봤다.
그리고 얼마 전엔 맥북을 쓴 지 2년 3개월 만에 처음으로 기능 고장을 경험했다. 본체나 LCD 쪽은 아니고, 전원 어댑터가 문제가 발생했다.

여기저기서 전선의 피복이 슬슬 벗겨지면서 속의 금속선들이 드러나 보이기 시작했다. 벗겨진 부분에다가는 테이프를 감았으며, 노출 부위 때문에 감전이나 화재 사고가 날까 두려워서 잘 때나 부재 중일 때는 전원 플러그를 빼 두기 시작했다.
그러더니 나중엔 컴퓨터 본체와 연결하는 목덜미 부분이 너무 너덜너덜해진 나머지 거의 두 동강 나다시피하면서 결국 단선됐다. 전원을 연결해도 본체에 전원 공급이 되지 않기 시작했다. 컴퓨터 본체는 이제 2시간짜리 시한부 인생으로 전락했다.

어댑터 전선에 피복이 벗겨지면서 고장이 이런 식으로 발생하는 노트북 컴은 맥북이 처음이다. 그런데 다른 맥북/아이폰 사용자에게 물어 보니, 애플 제품은 그런 식으로 전원 어댑터 내지 충전기가 망가지는 건 생각보다 흔한 일이라고 한다.

어댑터 자체는 이상이 없고 전선만 망가진 건데 어째 물건을 재활용할 수는 없나 궁금하다. 물론, 콘센트 쪽 전선이 아니라 컴퓨터에다 꽂는 쪽의 전선이다 보니 어댑터와 분리가 가능하지도 않고 가능하지는 않을 것 같다.

지금은 어댑터를 새로 구입해서 상황을 마무리 지었지만, 약 3~4일 동안 내 컴을 못 쓰면서 좀 불편하게 시간을 보냈다. 다음부터는 좀 불편하더라도 컴퓨터 본체와 어댑터 선이 언제나 같은 높이와 평행한 각도가 유지되게 해 놓고 써야겠다. 목덜미 부근엔 수축 튜브를 감아 주고, 전선을 둘둘 감아서 가방에 넣는 것도 굉장히 조심해서 해야 할 것 같다.

* 다음은 여담.

1. 맥 OS가 의외로 굉장히 유용한 경우가 있는 걸 본인이 얘기한 적이 있나 모르겠다. 바로 학교 안에서이다.
Windows의 경우 컴퓨터의 속도를 한 반쯤 깎아내리는 엄청난 백신, 보안 솔루션 등을 강제로 설치해야만 교내 무선 인터넷 이용이 가능한 반면, 맥 OS는 그런 것 전혀 없이도 바로 인터넷 이용이 가능하기 때문이다. 아주 편리하고 좋다.

2. Windows 진영에서는 Metro라는 이름을 안 쓰는 게 마음에 안 들던데, 애플 진영에서는 매킨토시로도 모자라서 Mac이라는 이름까지 왜 빼 버렸나 궁금하다.. 자기 정체성을 가장 잘 분명하게 보여 주는 명칭을 빼 버리고 그냥 OS X...;;;

3. 그러고 보니, 플래시가 깔려 있지 않은 맥 OS의 사파리 브라우저에서 유튜브 동영상이 나오고 있어서 깜짝 놀라서 살펴봤더니.. 말로만 듣던 HTML5 기반 동영상이다. 우와~ 물론 비스타+IE9 구닥다리에서 실행해 보니 여전히 플래시다. 브라우저에 따라 기술을 알아서 판별하는 듯하다.

솔직히 플래시든 뭐든 인터넷으로부터 패킷을 받아서 하드웨어 가속으로 동영상을 틀어 준다는 기본 원리는 똑같다. 단지, 동영상을 해독하고 재생하는 기계어 코드가 예전에는 플래시 ActiveX라는 일종의 private한 영역에 있었던 반면, 이제는 그게 통일된 규격으로 웹브라우저에 있다는 차이만이 존재할 뿐이다. 웹 표준은 기술 자체가 아니라 기술을 담는 그릇의 규격에 대한 논쟁인 것이다.

Posted by 사무엘

2014/07/08 08:29 2014/07/08 08:29
,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/982

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

Comments List

  1. 김재주 2014/07/10 15:48 # M/D Reply Permalink

    애플 제품들은 비싼 대신에 QA는 확실히 하는 편인 것 같습니다. 뭐 동급 사양의 삼성 제품과 비교한다면 그렇게 택도 없이 비싼 것 같지 않기는 하지만... 삼성은 A/S 정책이 가격에 포함되어 있는 걸 생각해 보면 비싸긴 비싸요.

    2.
    Mac OS X라고 하면 아무래도 기존의 낡은 매킨토시와의 연관성이 떠오르기 때문이 아닌가 싶습니다. 옛 매킨토시와 OS X는 기반부터가 완전히, 전혀 다른 운영체계이고 현재는 호환성 레이어도 제거된 상황이니까요.


    3.
    HTML5 요소들도 과거 HTML이, 그리고 Javascript가 그랬던 것처럼 브라우저마다 파편화가 되고 있는 게 아닌가 하는 생각을 합니다. 태그 자체는 표준으로 정의가 되어 있지 브라우저에 따라서 지원 정도가 달라요. 이게 단순히 구현이 덜 된 정도 문제가 아니라 각 브라우저들의 정치적 판단에 따라 넣고 빼고...

    예를 들어서 구글 크롬은 H264 영상을 원래 지원하다가 구글에서 VP8 코덱을 내놓으면서 지원 코드를 삭제했습니다. 명목상으로는 H264가 오픈 소스 코덱이 아니고 각종 특허들이 달려 있어서 추후 로열티를 제공해야 하기 때문에 오픈 소스인 VP8만 지원하겠다는데, 사실 진짜 이유는 누구나 다 알고 있죠.

    그래서 같은 웹킷 기반인 사파리에서는 H264만 지원하고, 크롬에서는 VP8만 지원하죠 -_-; 파이어폭스는 H264만 지원하던가 그랬을 텐데 아마 태그 지원이 완전치 못했던 걸로 기억합니다.

    1. 사무엘 2014/07/10 22:02 # M/D Permalink

      1. 그렇군요. ^^ 제가 써 본 노트북 PC들 중에 이 기간 동안 본체에 이 정도로 잔고장이 전혀 발생하지 않은 물건은 맥북이지만, 전원 어댑터의 선이 저렇게 어이없게 사망한 물건도 맥북입니다. ㅎㅎ
      수 년 뒤에 제6대 노트북을 장만하게 되면 또 맥북을 쓸지 아니면 일반 노트북으로 돌아갈지를 고민하게 될 듯하네요.

      2. 그런데 새 이름이 옛 이름보다 고유명사스럽지가 못해 보여서 불만입니다. ^^
      그나저나 10(X)이라는 저 번호가 또 바뀌는 날이 있으려나 궁금해지기도 합니다.

      3. 흠, 그것도 그냥 공통 태그만 표준으로 제정된다고 끝이 아니었군요. ㄷㄷ
      하긴 웹 표준이 이제 동영상 압축 포맷에까지 관여해야 하는 세상이 왔습니다.

Leave a comment

* 에구. 나 완전 고전 게임 덕후 인증이다. ㅎㅎ

1.
옛날의 액션/아케이드 게임 중에는 주인공을 죽게 하는 각종 트랩들이 적(몬스터)에게도 동일하게 적용되는 게 있고, 그렇지 않은 게 있다. 동일하게 적용되는 게 더 공정하고 현실 고증에 더 충실한 시스템이겠지만, 그 경우 적의 AI를 더 똑똑하게 만들어야 게임성이 성립할 테니 개발자에게는 더 큰 난관이 된다. 안 그러면 적을 정당하게 싸워서 죽이는 게 아니라 AI 헛점을 이용해서 트랩으로 죽이는 꼼수가 너무 횡행하여 게임 밸런스가 무너질 것이다.

이런 한계로 인해 id에서 개발한 둠, 퀘이크 등의 몬스터는 용암이나 화학 용액 같은 데에 들어가도 체력을 잃지 않으며 물에 들어가도 익사하지 않는다. 그 대신 잘 알다시피 자기끼리 팀킬을 벌이는 몬스터 내전(monster infighting)이 있을 뿐이다. 둠에서는 몬스터들이 정말 무식한지라 내전이 정말 잘 벌어졌지만, 퀘이크에서는 몬스터와 주인공 사이에 다른 몬스터가 일직선으로 있을 때는 공격을 안 하게 일말의 AI 개선이 이뤄졌다.

위험한 데이브에서는 몬스터는 트랩 같은 건 쌈싸먹으며 잘만 날아다니고..
과거의 툼 레이더 게임들은 주인공이 혼자 트랩 퍼즐을 풀어야 하는 구역과 몬스터와 싸우는 구역을 완전히 철저하게 분리하여 논란의 여지를 차단한 사례에 가깝다.
Rick Dangerous 2는 이 점에서 독특하다. 몬스터도 미사일, 전깃줄 같은 트랩에 걸리면 얄짤없이 죽을 뿐만 아니라, 이렇게 죽이는 게 전기총(50점), 폭약(100점) 같은 주인공의 일반적인 공격으로 죽이는 것보다 점수도 더 높게 준다(150점).

자, 서론이 너무 길어졌는데.. 페르시아의 왕자는 잘 알다시피 로토스코핑 기법으로 스프라이트를 만들었을 정도로 극도의 현실성을 추구한 게임이다. 악당도 딱히 초현실적인 괴물이 아니라 그저 검을 든 똑같은 인간이며, 이들을 상대로도 가시와 톱날 같은 트랩은 똑같이 동작한다. 악당 역시 트랩에 걸리면 피투성이가 되어 끔살당한다.

악당을 죽이는 방법으로는 (1) 칼 공격으로 HP를 다 깎아서 죽이는 가장 평범한 방법 외에도,
(2) 2층 이상의 높이에서 추락사시키기. 주인공은 이 경우 HP 하나만 잃지만, 악당은 의외로 즉사한다. 그 대신 악당은 1층 높이에서 떨어졌을 때 주인공처럼 무릎을 굽혀 엎드리지 않으며 바로 자세를 잡는다. 일당일단? 그리고 악당이 지금보다 아래 화면으로 떨어진 경우, 시체가 남지 않는다.
(3) 가시 꼬챙이가 있는 곳으로 떨어뜨리기. 한 층 높이에서만 떨어져도 주인공이든 악당이든 다 죽는다.
(4) 허리 자르는 쇠톱날.. 더 이상의 자세한 설명은 생략한다.

악당을 죽이고 나면 '빰 빠밤 빰' 하면서 승전 멜로디(?)가 흘러나온다. 칼로 찌르든, 떨어뜨리든 어떻게 죽이든지 말이다.
그런데... 페르시아의 왕자에서 악당을 (3)번, 즉 가시에다 밀어넣어 죽인 뒤에 승전 멜로디를 들은 적이 있으신 분 손..??
난 한 번도 없다. 20년 전부터 지금까지 이걸 대수롭지 않게 여기고 넘어가곤 했는데, 갑자기 문득 이상한 점이 느껴진다.

페르시아의 왕자 레벨에서 악당을 (3)번처럼 죽이는 건 레벨 2, 4, 8, 9(두 번), 11에서 총 6군데가 가능하다. 특히 마지막 레벨 11의 경우, 아예 왼쪽과 오른쪽에 모두 가시 트랩과 절벽이 존재하니 악당을 재미있게 요리하는 맛이 더욱 쏠쏠하다.

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

악당을 정상적인 (1)번 방식으로 죽였을 때는 승전 멜로디가 무조건 나온다. (2)나 (4) 같은 트랩으로 죽였을 때는 아주 가끔 음악이 안 나오기도 했던 것 같다.
그 반면 (3)은... 지금까지 한 번도 나온 적이 없었다.
어떤 방식으로 죽든 악당의 HP가 0이 되어 전투가 끝나고 주인공이 칼을 집어넣을 때 승전 멜로디를 연주하면 될 텐데.. 로직을 상황별로 다 따로 처리했나? 그리고 저기서만 if문이 하나 실수로 빠진 건지? 진실은 그 당시 코딩을 했던 프로그래머만이 알 수 있을 것으로 보인다.

2.
자, 이제부터는 가시 말고 톱날 얘기가 줄곧 나올 것이다.
페르시아의 왕자의 일부 던전에는.. 톱날을 통과해 들어간 뒤에 곧바로 칼을 뽑고 악당과 싸워야 하는 곳이 있다. 레벨 4에서 처음으로 등장한다.
그런데 적과 싸우기 시작했을 때는 게임 진행이 조금 느려지고, 심지어 톱날의 톱질 주기도 약간 길어지는 것 같다.

이것은 시스템 성능 같은 다른 외부적인 문제일 뿐, 게임 메카닉 자체가 느려지는 건 아니다.
페르시아의 왕자는 참 좋은 게, ESC를 눌러서 게임을 일시 정지시키고 나서 계속 ESC를 누르면 게임을 한 프레임 단위로 천천히 진행시킬 수가 있다.
이걸로 측정을 해 보면, 톱날의 톱질 주기는 언제나 15프레임으로 동일하다. 전투 중일 때든, 평시든 말이다.

그리고 심지어 톱날이 여러 개 연달아 동작할 때도 동일하다.
각각의 톱날이 한 번씩 연달아 톱질한 뒤에 첫 톱날의 다음 주기가 시작되기 때문에 주기가 좀 길 것처럼 느껴지기 쉬운데, 그렇지 않다.

원작 게임에서야 톱날이 한 층에 가장 많이 등장하는 게 레벨 3의 대형 물약이 있는 방이다. 3개짜리가 최다이다.
유튜브 같은 데서 톱날이 5개가 넘게 있는 이상한 방을 가 보면, 모든 톱날들이 15프레임 안에 한 번씩 순회를 하는 게 불가능하다. 이런 데서는 뒤쪽의 톱날이 미처 톱질을 하기 전에 15프레임을 다 채운 앞쪽 톱날이 또 톱질을 시작한다.
게임 메카닉이 이러하다는 걸 알 수 있다.

3.
또한, 톱날은 주인공이 톱날과 같은 층에 진입한 경우 곧장 동작한다.
그런데 주인공이 그 층에서 다른 이유로 인해 죽어 버리면, 톱날은 일반적인 경우 동작을 멈춘다. 가령, 그 층에 있는 악당과의 전투에서 져서 죽거나, 칼을 뽑지 않은 상태에서 악당의 칼빵을 맞아 죽은 경우 말이다. 톱날이 있는 층에 주인공이 추락사를 했다면 톱날은 역시 더 동작하지 않는다.

하지만 주인공이든 악당이든 누군가가 그 톱날 자체에 찍혀 죽었다면 톱날은 계속 동작한다. 다시 말해 누군가를 한번 죽인 적이 있는 톱날은 그 층에서 주인공이 추락사하든 악당의 칼에 맞아 죽든, 주인공이 그 층에 어떤 형태로든 있다면 계속 동작한다.

사용자 삽입 이미지
내가 치트까지 써 가면서 다양한 상황에서 테스트를 해 보니 대략 그러하다. 알고리즘 차원에서 이런 미묘한 차이도 존재한다는 게 흥미롭지 않은가?

4.
그리고.. 주인공이 톱날이 존재하는 층에 있긴 한데, 추락하느라 잠시 지나는 형태라면 톱날은 어떻게 동작할까?
톱날은 이때도 반응한다. 레벨 9에서는 심지어는 주인공이 아니라 악당이 떨어지는데도 톱날이 한번 동작하니, 참 놀랍지 않을 수 없다. 아래 그림을 보시라.

사용자 삽입 이미지

그 반면, 주인공이라 해도 이렇게 지나갈 때는 톱날이 동작하지 않는다. megahit 치트를 써서 천천히 떨어지게 하는 낙하산 효과를 줬는데도 톱날이 동작하지 않는다.

사용자 삽입 이미지사용자 삽입 이미지
이런 걸 보면, 톱날의 동작 여부에는 우리가 흔히 생각하는 것보다 더 복잡한 로직이 들어간 건지도 모른다. 심지어 던전의 지형별로 톱날의 동작 여부를 제어하는 메타데이터가 수작업으로 들어간 건 아닌지?

5.
아까도 잠깐 얘기했던 레벨 3으로 돌아간다. 여기는 알다시피 최대 HP를 늘려 주는 대형 물약이 있지만, 그 길목을 저렇게 톱날이 무려 3개가 가로막고 있다.

사용자 삽입 이미지

페르시아의 왕자에서 레벨 3은 중간 waypoint가 존재하는 유일한 레벨이기도 하다. 죽으면 얄짤없이 처음부터 시작하는 게 아니라, 타임어택 절벽 관문은 통과한 뒤의 시점부터 시작한다는 뜻. 페르시아의 왕자 2야 각 레벨이 워낙 방대해진 관계로 waypoint가 존재하는 레벨이 더 생긴 편이지만, 1에서는 레벨 3이 유일했다.

레벨 12에도 그림자 인간과 합체하고 나서 Jafar를 만나기 직전 위치에 일종의 waypoint가 있긴 하지만, 이건 내부적으로는 완전 별도인 레벨 13으로 간주된다. 그렇기 때문에 레벨 3의 waypoint와는 약간 성격이 다르다.
관문을 통과하기 전에 대형 물약을 먹었다면, 그렇게 해서 늘어난 HP도 다음에 waypoint에서 게임을 다시 시작할 때 반영된다.

그런데, 여기에 약간의 버그 내지 exploit가 있다.
waypoint에서 게임을 다시 시작하면, 레벨 3의 모든 요소들이 원래대로 되돌아간다. 딱 하나, 그 타임어택 절벽 관문의 한쪽에서 우리가 도움닫기를 위해 밟아 떨어뜨려 없애던 발판만 계속 없는 채로 남아 있다.

그것만 빼고 나머지는 전부 원상복귀. 심지어 타임어택 절벽을 넘기 전에 먹었던 대형 물약도 다시 생긴다.
그렇기 때문에 다음 레벨로 넘어가는 관문을 열고 해골도 처지한 뒤, 다시 그 방으로 돌아와서 대형 물약을 먹으면.. 이론적으로 레벨 3에서 대형 물약을 두 번 먹어서 HP를 2개나 확장하는 게 가능해진다.

레벨 3 시작 → 대형 물약 → 타임어택 관문 통과 → 그 뒤 Ctrl+A 눌러서 waypoint 지점부터 게임 재시작. 예전에 대형 물약 먹은 게 반영됨 → 되돌아와서 대형 물약 또 먹음 → 클리어

물론 실제로 이렇게 하는 건 시간이 너무 많이 걸리는 노가다이기 때문에 현실성은 별로 없지만..
이건 아마 조던 메크너(오리지널 게임 설계자, Apple II용 개발자)와 랜스 그루디(도스용 게임 포팅 개발자)조차 그 당시 예상을 못 했던 꼼수일 것이다.
차라리 waypoint 이후에 도달하는 위치에다 대형 물약을 놔 뒀다면 이런 exploit가 틈탈 여지가 없었을 텐데.

자, 이런 글을 보니 나도 도스박스 깔아서 페르시아의 왕자를 실행해 보고 싶은 생각이 드시지는 않는가?

Posted by 사무엘

2014/06/29 08:21 2014/06/29 08:21
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/979

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

Comments List

  1. 김진 2014/06/29 13:29 # M/D Reply Permalink

    이런 신기한 게 있었군요. 당시 여러 번 즐기면서도 몰랐던 것이 많네요. 이제는 조던 메크너의 소스코드가 공개되었으니 애플2 어셈을 알면 분석할 수도 있겠지만 만만치 않겠네요 :)

    1. 사무엘 2014/06/29 15:51 # M/D Permalink

      그 코드를 읽을 수 있는 사람은 (거의) 없을 테고..ㅎㅎㅎ
      원판을 PC 도스로 포팅한 랜스 그루디 옹에게는 옛날 소스가 없으려나 궁금합니다. PRINCE.EXE는 MS C로 빌드됐거든요.

Leave a comment

1.
아래아한글의 역대 버전 중, 96과 97은 실행되면서 스플래시 화면이 나올 때 짤막한 효과음(음악 멜로디)이 나오던 전무후무한 버전이었다.
96은 경쾌한 사과나무.wav (도~~ 미파솔..로 시작하는)이었고 97은 그것 말고도 여러 종류의 음향이 더 추가되었다. 물론 워디안 이후 후대부터는 그런 것 없고. 이런 것도 다 일시적인 유행이었다.

오늘날은 아예 Windows조차도 8부터는 로그인 로그아웃 소리가 없어졌다.
먼 옛날 3.x 시절에 사운드 카드가 지원된 이래로, 시작 효과음은 그 유명한 tada.wav부터 시작해 뭐가 들어가도 들어갔는데.. 완전히 없어진 건 8이 처음이다.

응용 프로그램을 실행하는 게 옛날만치 그렇게 막 유세 떨 일이 아니게 되어서 그런 것 같다.
설치 프로그램이 원래 전체 화면을 차지하는 형태이다가 조그마한 마법사 대화상자로 바뀐 것도 비슷한 맥락일 것이고 말이다.

2.
지금이야 MS Office 제품들이 리본 UI를 사용하여 인터페이스가 여타 프로그램과는 완전히 다른 형태로 바뀌었지만..
먼 옛날, Office 95 시절이 문득 생각난다.
Windows 95의 출시에 맞춰서 완전히 32비트로 포팅된 첫 버전이었으며, 동시에 Office가 운영체제의 표준 메뉴 인터페이스를 사용하던 마지막 버전이었다.
다만, 약간의 애드립이 생각지 못한 곳에 있었는데.. 아래 스크린샷에서 프로그램 상단의 타이틀/캡션 바 영역을 보시라.

사용자 삽입 이미지

Office 95 프로그램들은 처음이자 마지막으로 캡션 바를 자체적으로 그렸다.
그래서 Microsoft는 그냥 일반 폰트가 아니라 그 당시 쓰이던 MS 로고타입 형태 그대로 그려졌으며, 검은색에서 짙은 군청으로 바뀌는 그러데이션이 적용되어 있었다.
잘 알다시피, 캡션 바에 그러데이션이 추가된 것은 윈도 98부터이지 95엔 아직 그런 게 없었다. 응용 프로그램이 WM_NCPAINT를 처리하여 직접 그렸던 것이다.

정말 일시적인 유행이었지만 그 시절에 외국 프로그램 중엔 캡션 바를 이 스타일을 따라 그렸던 프로그램도 소수 있었다.

3.
사실 Windows는 GUI 외형이 Mac OS에 비해 매우 단순한 편이었고, 그 대신 색상을 다양한 스타일로 지정할 수 있었다.
그러던 것이 XP 이후부터는 큰 변화가 생겼다. Luna 테마는 파랑-은색-황록이라는 세 색상표만 지원했고, Vista부터는 Aero 창틀의 색깔만 사용자 지정이 될 뿐 나머지 색상은 고정 불변이 됐다. 예전의 재래식 외형은 '고전 테마'라는 legacy로 전락했다.

시스템 색상을 customize할 일이 없어졌다. GetSysColor 함수는 원래 수십 가지의 색상 요소들을 제공하지만 응용 프로그램은 사실상 COLOR_WINDOW(TEXT), COLOR_HILIGHT(TEXT), COLOR_BTNFACE 같은 것밖에 사용할 일이 없어졌다. 그리고 사실은, 선택된 아이템을 표시할 때도 COLOR_HILIGHT나 반전(InvertRect)이 아니라 엷은 파랑 효과를 쓰는 게 유행이 됐다.

옛날에 Microsoft Plus! 같은 확장팩이 제공했던 '테마'들은 색상, 마우스 포인터, 효과음을 한데 모은 세트였지만.. 지금은 Windows도 맥 OS처럼 어찌 보면 사용자 선택의 폭을 좁히고 있다. 지금의 외형 자체가 곧 Windows의 정체성과 같다는 점을 더욱 내세우려는 것 같다. 색상표는 이제 사실상 시각 장애자 내지 전력 절약용으로나 의미가 있는 '고대비'밖에 안 남았다.

4.
Windows는 파일/디렉터리 목록을 이름 순으로 정렬해서 표시하더라도 디렉터리(폴더)와 파일은 따로 분류해서 보여주는 반면, Mac OS는 이들을 다 한데 섞어서 보여준다. 디렉터리도 특수한 형태의 파일로 볼 것이냐, 아니면 아무래도 파일과는 개념적으로 다른 존재로 보느냐의 차이 같다.
또한 마우스 휠을 인식하는 대상도 Windows는 키보드 포커스를 받고 있는 창이지만, Mac은 마우스 포인터가 놓여 있는 창이다.

참, 맥OS는 메뉴나 대화상자에 액셀러레이터 키가 전혀 없는 게 굉장히 뜻밖이다.

5.
유튜브나 스마트폰의 동영상 재생 앱 등... 요즘은 이게 유행인지 모르겠지만
대부분의 멀티미디어 재생 컴포넌트들은 Pause(||) 버튼만 있지, 완전 정지 Stop(■) 버튼이 없다.

파일을 열었으면 나중에 반드시 닫아야 한다는 프로그래머스러운 사고방식에 사로잡혀 있는 본인 같은 사람에겐 그런 디자인이 심리적으로 좀 불안하게 느껴지기까지 한다. 정말 Stop이 없어도 될까? 굳이 프로그래머가 아니더라도 옛날 카세트 및 비디오 테이프 재생기 역시 기계적인 특성 때문에 Pause와 Stop은 성격이 상당히 다르기도 했고 말이다.

하지만 리소스 제약 같은 걸 생각하지 말고, 사용자의 입장에서 오로지 틀고 싶을 때 틀고 끄고 싶을 때 끄는 것만 생각하면, 원론적으로야 둘을 굳이 구분할 필요가 없긴 해 보인다.

6.
top-to-bottom과 bottom-to-top이 헷갈릴 때가 종종 있다.
당장 좌표계만 해도 수학에서는 아래에서 위가 y축의 양의 방향이지만.. 컴퓨터 화면에서는 위에서 아래가 y축의 양의 방향이다.

Windows에는 spin, 혹은 up-down이라고 불리는 컨트롤이 있다.
얘는 언제나 위에 있는 ▲ 버튼 혹은 위(↑) 화살표 키를 눌렀을 때 숫자를 증가시키고, 그 반대의 조작을 하면 숫자를 감소시킨다.
안타깝게도 이 동작을 정반대로 바꾸는 방법은 없는 듯하다. 컨트롤의 동작을 교묘하게 서브클래싱하지 않는 이상 말이다.

저 컨트롤은 <날개셋> 한글 입력기의 제어판에서 입력 항목의 배열 순서를 바꾸는 용도로도 쓰이는데..
입력 항목들은 위에서 아래로 오름차순으로 배열되어 있다.
그래서 ↑가 아니라 ↓를 눌렀을 때 숫자가 증가하고 아래로 가게 하고 싶으나 그렇게는 못 하고 있다.
이건 솔직히 사용자를 굉장히 헷갈리게 만들 수도 있는 면모이다.

사용자 삽입 이미지

이 외에도, 노트북의 터치패드를 손가락으로 상하 드래그를 했는데, 위에서 아래로 그었을 때 화면을 위에서 아래로 스크롤시킬지, 반대로 아래에서 위로 스크롤시킬지도 보통은 옵션으로 존재한다.
본인이 선호하는 건 위에서 아래로 그었을 때 화면은 아래에서 위로, 즉, 아래 페이지의 내용을 표시하는 것이다. ↓ 키를 눌렀을 때와 같다. 손가락은 전체 내용에 대한 화면(view)의 상대적인 위치와 같은 것이다.

그러나 손가락의 위치를 지금 표시되어 있는 텍스트의 상대적인 위치와 같은 것으로 본다면.. 소프트웨어의 동작은 저것과는 반대가 되어야 직관적일 것이다. 결국 이것은 사람마다 취향이 다른 답이 없는 문제이다.

Posted by 사무엘

2014/02/15 08:26 2014/02/15 08:26
,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/931

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

Leave a comment

고전 게임 페르시아의 왕자에 대해서 더는 글을 쓸 일이 없을 것 같았는데 또 하나 글을 쓰게 됐다.
지금까지 까맣게 잊고 지냈던 게임 중 이벤트가 하나 갑자기 떠올랐기 때문이다.

잘 알다시피 페르시아의 왕자에는 주인공의 영혼(?)이 빠져나가는 듯한 이상한 이벤트가 있다.
레벨 4에서 클리어 관문을 열고 나오면 거울이 하나 생겨서 길을 가로막는다.
이 거울을 도움닫기 점프로 깨뜨리면 진행은 가능해진다. 하지만 이때 자기 영혼 내지 그림자? 도플갱어가 빠져나가고 그 과정에서 왕자는 HP가 1로 다 깎여서 죽기 직전의 상태가 된다.

도플갱어의 정체가 무엇인지, 제작자 조던 메크너가 무엇을 의도하고 이런 걸 넣었는지는 모르겠다.
다만, 이 도플갱어가 왕자에게 하는 짓은 결코 호의적이지는 않다.
레벨 6에서 뚱보를 죽인 뒤에 벼랑을 앞두고 서로 만났을 때는, 도플갱어가 문을 쾅 닫아서 왕자를 벼랑 아래로 빠뜨려 버린다.

그 뒤로 도플갱어는 한동안 등장하지 않다가 게임이 끝날 때가 다 된 레벨 12의 꼭대기 층에서야 등장한다. 원수진 것 때문에 서로 칼을 뽑고 대적하지만 그래도 성질 죽이고 칼을 집어넣고 서로 합체를 해야 살 수 있다. 재결합을 한 뒤에는 보상 차원에서인지 전체 체력이 1 증가된다.

이 글에서는 그 전에 레벨 5에서 발생하는 이벤트에 대해서 좀 분석을 해 봤다.
레벨 5에는 전체 체력을 1 늘려 주는 대형 물약이 있다. 그러나 이것은 우리 왕자가 먹을 수 없다. 도플갱어가 먼저 와서 진짜 말 그대로 정확하게 '먹튀'해 버리기 때문이다. 그게 무슨 말이냐고?

사용자 삽입 이미지

자, 옛날에 페르시아의 왕자를 해 본 경험이 있는 분이라면 옛날 생각이 나실 것이다.
1층과 3층에 문이 있는데 물약이 있는 3층 문은 닫혔기 때문에 낮은 1층으로 먼저 들어가야 한다.
1층 문을 진입하는 순간, 발판 때문에 문은 쾅 닫힌다. 왔던 길로 못 돌아간다. 미우나 고우나 “들어올 때는 마음대로였겠지만 나갈 때는 아니란다” 상태가 되고, 어떻게든 저 무시무시한 왕복 톱날 2개를 통과하여 물약을 먹으러 가야 한다.

톱날을 통과하면 곧장 1층과 3층 문을 모두 여는 발판이 우리를 기다리고 있다.
그런데 3층 문이 열리자마자 3층에서는 왕자의 도플갱어가 갑자기 튀어나와서 물약을 쳐묵쳐묵 한 뒤 달아나 버린다.
톱날을 지나면서 힘들게 묘기는 우리가 다 했는데 갑자기 저 녀석이 소중한 물약을 먹튀하다니..

일단, 맵의 디자인이 굉장히 교활하게 돼 있다는 걸 부인할 수 없다.
문을 여는 발판이 하나만 있어도 될 게 굳이 2개씩이나 있다. 왼쪽 것과 오른쪽 것 중에 오른쪽 것은 3층으로 올라가는 과정에서 무조건 밟지 않을 수가 없다. 둘 중 어느 것을 밟더라도 1층과 3층 문이 모두 열린다. 그리고 3층이 열리는 순간 왕자가 미처 3층으로 다 올라가기도 전에 도플갱어가 먼저 달려온다..

결국, 왕자가 3층으로 올라갈 때까지 저 문이 최대한 늦게 열리게 하려면..
두 발판을 밟지 않은 상태에서 왕자가 두 발판을 사이에서 오른쪽이 아닌 왼쪽을 보고 있는 상태를 만들어야 한다.
이게 꽤 어렵다. 그래도 오른쪽의 둘째 톱날의 앞에 바싹 붙어 선 뒤, 오른쪽으로 점프를 하면 왼쪽 발판을 밟지 않고 양 발판의 사이에 설 수 있다.

그 상태에서 3층으로 올라감과 동시에 3층 문이 열리게 하면 그나마 시간을 최대한 벌 수 있으나..

사용자 삽입 이미지

그래도 우리가 도플갱어보다 먼저 물약에 닿는 것은 여전히 불가능하다. 최선을 다해도 결국 위와 같은 차이가 난다는 것을 알 수 있었다.

그 다음으로 본인이 시도한 것은, 3층 문을 열어서 도플갱어가 들어올 때쯤 도로 1층으로 내려가서 문을 닫아 버리는 것이었다. 1층의 닫힘 발판은 1층 문뿐만 아니라 3층 문까지 한꺼번에 닫기 때문이다.

그런데 이것도 엄청나게 어렵다. 아까 저 그림처럼 3층 문을 열지 않은 상태에서 왼쪽을 보고 있는 상태를 먼저 만들어야 하는 데다, 거기에다 추가적인 묘기가 더 필요하기 때문이다.
준비됐으면 발판을 밟아서 3층 문을 연 뒤, 정확한 타이밍을 노려서 2개의 톱날을 도움닫기 점프로 한번에 통과하고 1층으로 떨어져서 닫힘 발판을 밟아야 한다! 타이밍이 안 맞으면 톱날에 찍혀 끔살당한다.

그래도 이것 역시 불가능한 일은 아니다.
그러나.. 그럼에도 불구하고..
악랄한 우리의 도플갱어는 닫힌 철문도 통과하고서 물약을 훔쳐 먹고 유유히 사라지는 걸 알 수 있었다.

사용자 삽입 이미지

이 정도면 정말로 답이 없고 불가능이긴 하다.

2중 톱날은 왕자의 진행 속도를 크게 낮추는 어려운 트랩이다.
레벨 8의 경우, 클리어 관문을 열기 위해서 2중 톱날을 왕복으로 통과해야 한다.
그러고 나니까 철문이 닫혀 있어서 꼼짝없이 갇혔는데, 이때 공주가 보낸 생쥐가 문을 열어 주는 게 원래의 설정이다.
하지만 잘 알다시피 2중 톱날도 아무 거리낌없이 통과하여 철문이 완전히 닫히기도 전에 자력으로 빠져나오는 것도 불가능하지는 않다. 유튜브에서 괴수들의 플레이 동영상을 보면 그런 게 있다.

사용자 삽입 이미지사용자 삽입 이미지
(생쥐가 굳이 출동할 필요가 없다!)

레벨 8에는 그런 플레이가 있는 반면, 레벨 5에서 도플갱어를 따돌리고 대형 물약을 먹는 데 성공했다고 하는 테크닉이나 플레이 동영상은 인터넷에 전혀 존재하지 않는다. 불가능한 일이기 때문이다.

MEGAHIT 치트를 써서 게임을 실행한 뒤, 도플갱어가 등장하는 장면에서 K(현재 화면에 있는 몹을 죽임)를 누르면 도플갱어가 사라진다. 이를 활용하면 레벨 5에서 대형 물약을 먹을 수 있게 되며, 레벨 6에서도 도플갱어가 있는 절벽 건너편으로 올라가는 것도 가능해진다. 하지만 이건 언제까지나 치트를 써서 만들어 낸 결과일 뿐이다.

참고로, 2007년에 나온 3D 리메이크작인 <페르시아의 왕자 클래식>은 이 시스템이 좀 개선되었다.
2층에서 3층 문을 열었다가 1층으로 잽싸게 되돌아와서 그 문을 닫아버리면, 도플갱어는 왔다가 물약을 못 훔치고 되돌아간다. 그래서 레벨 5에서도 대형 물약을 먹고 체력을 늘리는 것이 가능하다!
리메이크작은 톱날이 2개이던 것이 1개로 줄고 왕복 주기도 원작보다 훨씬 더 길기 때문에, 통과하기도 쉽다.

사용자 삽입 이미지

Posted by 사무엘

2014/01/21 08:32 2014/01/21 08:32
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/922

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

Leave a comment

본인은 중학생이던 1996년 말, 친구 집의 컴퓨터를 통해 우연히 툼 레이더라는 게임을 접했을 때의 충격을 난 지금도 잊을 수 없다.
페르시아의 왕자 같은 파쿠르 액션이 full 3D로 구현되어 나오고 게다가 주인공이 듀크 뉴켐스러운 마초 근육맨이 아닌 아리따운 아가씨라니!
툼 레이더 시리즈는 전세계적인 히트를 쳤으며 게임 주인공인 라라 크로프트는 역사상 가장 성공한 사이버 모델이 되었다.
이번 글에서는 롤스로이스에 이어 또 '영국'이 만들어 낸(냈던) 명작에 대한 리뷰를 좀 써 보겠다.

본인은 예전에도 몇 차례 글을 썼듯이, 비디오 게임의 역사 중에서 3차원 그래픽 기술이 막 도입되던 1990년대 중· 후반의 과도기가 가장 흥미진진한 시절이었다고 생각한다.
id 소프트웨어의 엔진이 울펜슈타인, 둠, 퀘이크를 거치면서 발전해 가던 시절,
2.5D와 완전한 3D 사이의 과도기이던 켄 실버맨의 빌드 엔진을 쓴 게임(듀크 뉴켐, 섀도우 워리어),
목각인형에서 진짜 사람으로 발전하던 버추어 파이터 시리즈,
실사 사진을 쓰다가 최초로 3D 폴리곤으로 바뀐 모탈 컴뱃 4 등등 말이다.

그런 맥락에서 툼 레이더도 예외가 아닌 것이다.
안 그래도 엔하위키나 한국어 위키백과는 각 시리즈 별 설명이 부실한 편이기도 하니 한번쯤 이런 내력을 나열해 보는 것도 흥미롭지 싶다.

사용자 삽입 이미지

※ 1

그야말로 전설이 아닌 레전드를 창조한 첫 작품이며, PC 플랫폼은 처음이자 마지막으로 도스를 지원했다. 눈이 종종 쌓여 있는 숲, 광활한 고대 유적지, 피라미드 등을 돌아다니면서 말 그대로 묘지를 터는 본분에 충실한 형태였다. 몹 중에 인간은 흔치 않았던 걸로 기억하며, 혼자서 퍼즐을 풀어 나가는 비중이 컸다.
1부터 3까지는 같은 엔진 기반으로, 그래픽이나 게임 진행이 그렇게 큰 차이가 없다.

※ 2 (starring Lara Croft)

1이 대성공을 거둔 뒤, 2부터는 도스 대신 Windows용으로 나오기 시작했다. 2는 1에 비해 폴리곤 수가 늘어서 라라가 아주 약간 더 예뻐졌으며, 기술적으로 무리였던 팔랑거리는 말총머리가 드디어 구현되었다.
그리고 동적 광원을 구현하면서 flare(섬광탄) 아이템이 첨가되었다. 그리고 물에는 언제나 수영만 있던 것과 달리 얕은 물에서 걷는 wading이 추가되었으며, 암반을 오르는 climbing이 추가되었다.

2는 첫 시작을 만리장성에서 하고, 결말부에서 최종 보스도 용일 정도로 배경에 중국에 대한 비중이 가장 높다. 1보다 대인 전투의 비중이 높아졌으며 무덤 말고 도시, 선박 등 인간이 만든 시설도 많이 등장한다. 무기는 샷건뿐만 아니라 M16 소총, 작살총도 추가되었다.
보트나 스노우모빌 같은 탈것을 이용하는 동작도 처음으로 추가되었다. 생각해 보면, 주인공이 탈것을 이용할 수 있는 아케이드 게임은 매우 드물다. 용 정도나 타는 옛날 황금도끼 말고 딴 게 뭐 있었던가??

※ 3 (라라 크로프트의 모험)

3은 2와 같은 맥락으로 더 큰 변화가 이뤄졌다. 그래서 단순한 유적지 털기라는 타이틀이 무색할 정도로 전세계 방방곡곡을 배경으로 한 액션 어드벤처로 바뀌었다. 덕분에 게임 배경이 역대 툼 레이더 시리즈 중 가장 넓어서 인도, 남태평양 섬, 남극, 미국 AREA 51, 런던 자택 근처가 레벨로 모두 등장한다. 그리고 각 레벨별로 라라의 복장도 가장 다양해졌다. 지역별로 레벨 플레이 순서를 사용자가 임의로 선택할 수 있는 시스템도 3이 역사상 전무후무하게 갖추고 있었다.

기술적으로 보자면 라라에게는 그냥 달리는 게 아니라 기력을 소비하면서 잠시 동안 전력질주를 하는 sprinting이 추가되었으며 엎드리기(crouching), 천장을 잡고 건너기 같은 동작이 추가되었다. 그래픽이 개선된 건 총기 격발 후에 발생하는 탄피와 연기 흔적, 그리고 물에서 나타나는 특수효과가 일부 개선된 정도다. 슬슬 엔진의 약발이 다할 때가 되고 있었고, 라라 팬으로부터 불만도 들어오고 있었다. 3이 이룬 것은 같은 시스템 하에서 단순 양적 팽창 위주일 뿐이었으니 말이다. 그래서 다음 편부터는 시대에 맞추어 엔진이 교체되었다.

※ 4 (마지막 계시)

프로그램이 처음부터 싹 다시 개발되었다. 시작 화면, GUI 글꼴 같은 게 전부 바뀌었다. 여권 수첩 형태의 메뉴나 동그란 고리 형태로 나오던 인벤토리 링도 다 없어졌다.
4는 오로지 이집트 주변만 공략하여 순수하게 유적지 털기 미션으로 되돌아갔으며, 라라의 의상도 시종일관 기본 단일 복장으로 바뀌었다. 그렇잖아도 툼 레이더 4가 나온 1999년은 <미라>(Mummy)라는 영화가 인기를 끌었던 해이기도 해서 더욱 이집트스러운 기억이 깊게 남아 있다.

4는 엔진이 교체되면서 그래픽이 예전보다 대대적으로 향상되었다. 드디어 모든 텍스처에는 하이컬러 안티앨리어싱이 적용되기 시작했고 라라의 외형도 더욱 매끄럽고 예뻐졌다. 복잡한 지형에서 발생하던 1~3 엔진 특유의 그래픽 glitch가 거의 다 사라졌다. 3에서 바뀌었는지 4에서 바뀌었는지 모르겠지만 어쨌든 아이템이 여전히 2D 스프라이트로 표현되던 것들도 드디어 순수 폴리곤으로 바뀌었다.

4에서는 예전 시리즈에서 전통적으로 등장하던 라라 저택 연습 미션이 없어졌고, 그 대신 게임 전반부에서 라라가 어렸을 때의 모습이 잠깐 나온다. 그리고 줄을 타고 오르는 동작이 추가되었으며 여러 아이템을 조립해서 새로운 아이템을 만드는 시스템이 도입됐다. 또한, 4는 역대 툼 레이더 시리즈 중 레벨 수가 가장 많고 플레이 시간이 가장 길었다고 한다. 그 중 열차 안에서 미션을 수행하는 사막 열차 레벨은 상당히 참신한 디자인.
이 게임의 엔딩은 라라가 죽는 걸(최소한 그걸 암시하는)로 끝난다. 왜 그 잘 나가는 캐릭터를 죽이는지, 시리즈를 벌써 종결지으려는 건지 제작사의 의도를 알 수 없는 대목이다.

※ 5 (크로니클 연대기)

1부터 5까지는 각각 1996년부터 2000년까지 1년 간격으로 그 해의 하반기에 제품이 출시되었다. 5편인 크로니클은 4편과 거의 같은 엔진 기반에 컨텐츠만 다르다. 라라 크로프트는 죽고 없는데 그녀가 살아 생전에 남긴 무용담을 회상하며 플레이한다는 설정. 그래서 3편만큼이나 다양한 복장으로 과거 유물과 현대 도시를 아우르면서 다양한 미션을 수행한다.

5는 이상한 설정으로 인해 예전 시리즈만 한 대박은 못 친 걸로 본인은 기억한다. 다만, 이때 제작사가 무슨 생각이 있었는지 상당히 대인배적인 조치를 취했는데, 바로 레벨 에디터를 게임과 더불어 공식 배포했다. 스타크래프트로 치면 걸출한 캠페인 에디터인 StarEdit인 셈.

덕분에 툼 레이더 4~5 엔진은 내가 알기로 역대 툼 레이더 시리즈들 중 단순 의상 패치 이상으로 full-featured custom 레벨 MOD가 존재하는 최후의 엔진이다. 그래서 인터넷엔 라라 크로프트 하앍하앍 하는 전세계의 양덕후들이 만들어 올린 custom 레벨 파일 및 플레이 동영상들이 즐비하다.
1~3 엔진은 에디터가 있다 하더라도 요즘 기준으론 그래픽이 너무 심하게 후져서 별로. 4~5 엔진 정도는 돼야 그나마 할 만하다.

※ 6 (어둠의 천사 AOD)

툼 레이더의 제작사인 코어 디자인은 라라 크로프트라는 희대의 대박 아이템이자 황금알 낳는 거위를 창조해 놓고는 영업이랄까 운영을 썩 잘했다고 볼 수는 없었다. 3에서 4로 넘어갈 때 좀 혁신을 한 걸 제외하면, 계속 같은 엔진과 게임 시스템만 지겹게 우려먹는 걸 좋아하는 편이었다. 그리고 배가 산으로 가는 듯한 스토리를 전개하며 4편에서 라라 크로프트를 덥석 죽여 버린 건 팬들의 원성을 사기에 충분했다.

그런 와중에 거의 3년간의 침묵을 깨고 툼 레이더의 다음 시리즈인 어둠의 천사가 나왔다. 시기가 시기인 만큼 기술은 분명 크게 발전했다. 물리 엔진이 도입되었고 라라의 손발 모션은 지형을 반영하여 더욱 자연스럽게 나오기 시작했다. 그래픽 디테일 레벨을 올리면, 그림자도 그냥 바닥에 시꺼먼 타원으로만 나오는 게 아니라 실제 광원과 라라의 체형대로 나오기 시작했다.

다만, 이 작품에서 라라 크로프트는 과거에 죽었다가 아무 개연성 없이 불쑥 살아서 돌아왔으며, 고대 유적지를 돌아다니는 묘지 도굴꾼 컨셉에서도 더욱 멀어졌다. 전통적인 복장 대신 군복과 청바지 차림으로 의상이 완전히 바뀌었다.
6은 기술의 진보는 분명 있었으며 국내에서는 툼 레이더 시리즈 중 최초로 완전 한글화가 되기도 했다. 하지만 저런 괴상한 정체성과 많은 버그들 때문에 완성도가 떨어지고 뭔가 핀트가 안 맞는 작품으로 전락했으며, 큰 성공을 거두지 못했다.

※ 7 (레전드)

툼 레이더의 본디 제작사이던 코어 디자인은 6 이후로 제작사 타이틀을 반납하고 그저 그런 게임 개발사로 남아 있다가 2007년쯤에 망했다. 그 뒤 툼 레이더의 개발은 영국이 아닌 미국의 크리스탈 다이나믹스로 넘어갔는데 얘가 툼 레이더 시리즈를 다시 물건으로 회복시켜 놓았다.

2006년 봄에 출시된 레전드는 툼 레이더의 '제2기' 시대를 열었다. 툼 레이더의 기본 복장이 되돌아왔으며 유적지 탐험 패턴도 복귀했다. 그러는 한편으로 조작도 다 뭔가 현대적인 감각으로 바뀌었다. 언제나 자동 세이브가 되고 굳이 별도의 키를 누르지 않아도 절벽에서는 자동으로 매달리는 등, 퍼즐 난이도는 예전보다 더 쉬워졌는데 이건 요즘 게임기용 게임들의 추세가 다 그런 게 아닌가 싶다.

레전드에 대한 반응은 전반적으로 좋았다. 하지만 예전하고는 너무 이질적으로 바뀐 게임 시스템에 대해서는 게이머들 사이에 호불호가 갈리기도 했다. 맨날 동료하고 얘기를 주고받는 것도 예전에는 없던 관행이었으니까.
아무튼, 이렇게 레전드로 희망찬 데뷔 선언을 한 크리스탈 다이나믹스는 그 이듬해에 Anniversary라고 불리는 시리즈도 내놓았다. 이것은 툼 레이더 1을 오늘날 스타일로 리메이크한 작품이다.

※ 8 (언더월드)

레전드의 명성을 계승한 후속 시리즈이다. 라라 크로프트가 배를 타고 세계 각지를 이동하면서 미션을 수행한다. 덕분에 레전드에 비해 잠수와 수영의 비중이 더 높다. 고전 복장은 사라졌으며, 그나마 이것과 가장 비슷한 복장은 태국 숲 미션에서 입는 까만 셔츠와 핫팬츠 복장이다.

라라 크로프트의 집이 난장판이 되는 건 옛날에 2의 맨 마지막 레벨 Home Sweet Home에서 침략자들과 총격전을 벌이는 게 전부였는데... 이번 언더월드에서는 첫 미션에서 집이 불바다가 되는 걸로 시작한다. 그래서 집에서 겨우 빠져나왔는데.. 이번엔 레전드 시절의 동료가 라라에게 무슨 원한이 생겼는지 권총을 쏴 댄다. 도대체 어찌 된 일일까? 다행히 원한을 살 만한 짓은 라라가 아니라 라라의 도플갱어의 소행으로 밝혀져 오해는 나중에 풀리지만... 스토리 전개가 재미있다.

도플갱어라.. 옛날에 1편에서 베이컨 라라가 있긴 했고.. 더 옛날 고전 게임 중엔 페르시아의 왕자 1에서도 왕자를 골탕먹이다가 나중에 합체하는 영혼 도플갱어가 있었다. 정말 별의 별 걸 게임에다 다 집어넣었다.

※ 9

자... 1996년 이래로 근 15년간 라라 크로프트를 쌍권총 찬 고고학자로 우려먹어 온 건 약발이 다한 모양이다.
크리스탈 다이나믹스는 5년간의 잠수 끝에, 이제 예전의 스토리를 다 뒤집어엎은 리부트작을 내놓았다. 이 작품은 1편과 마찬가지로 부제가 없이 이름이 그냥 툼 레이더이다.

라라는 더욱 어려졌으며, 도도한 특수요원 같은 이미지가 아니라 이제 막 생존술을 터득해야 하는 연약한 여고생/여대생 컨셉으로 바뀌었다. 어린 라라 떡밥은 지난 4편에서 잠시 등장한 적이 있지만 그걸 떠올려서도 물론 곤란하겠다. 예전의 라라가 인디아나 존스 컨셉이었다면, 지금의 라라의 위상은 거의 생존왕 로빈슨 크루소나 심지어 베어 그릴스-_-를 생각해도 될 것 같다.

9의 설정상 배경은 일본 열도 인근에 있는 어느 섬이다.
사실, 툼 레이더 시리즈에서 일본이 등장하는 것 자체가 코어 디자인 시절에는 없었고 크리스탈 다이나믹 때 레전드와 9에서 딱 두 번이었다. 코어 시절에 툼 레이더의 배경은 오히려 중국, 네팔, 티베트 같은 대륙이 더 자주 등장했었다.
중국과 일본 사이에 끼어서 한국은 영토가 너무 작기도 하고 게임이나 영화 같은 매체에 선뜻 등장하기에는 정치적 민감성도 크고 역시나 콩라인이라는 생각이 들었다.

그래픽이야 뭐, 피부에 핏자국이 묻고 각각의 머리카락들이 찰랑거리는 걸 볼 수 있을 정도로 사실에 가깝게 발전했다.
AOD에서 레전드로 넘어갈 때를 능가하는 엄청난 쇄신이 있었는데, 반응은 역시 좋은 편이다. 9 이후로 툼 레이더 시리즈가 과연 또 어떻게 변할지가 궁금해진다.

Posted by 사무엘

2013/12/07 08:32 2013/12/07 08:32
,
Response
No Trackback , 4 Comments
RSS :
http://moogi.new21.org/tc/rss/response/906

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

Comments List

  1. 포도같은블루베리 2013/12/07 08:37 # M/D Reply Permalink

    의외로 젊으시네요. 좀 더 나이가 드신 분이라 생각했어요.

    1. 사무엘 2013/12/07 13:26 # M/D Permalink

      하하, 반공 성향 강한 것과 옛날 프로그래밍 얘기를 많이 하는 걸 보면, 제 나이가 많게 느껴질 수도 있겠네요.
      하지만 전 컴퓨터 프로그래밍을 평균보다 좀 일찍부터 시작했을 뿐입니다. 그리고 중학교 시절엔 저는 아직 C/C++도 몰랐어요. ^^

  2. 김 기윤 2013/12/10 17:16 # M/D Reply Permalink

    어렸을 적에 툼 레이더 2를 했던 기억이 나는데다가, 마침 최신작(위에 설명된 9 버전)에도 관심이 있었고, 스팀에서 툼 레이더의 모든 시리즈(!!) 를 묶어서 팩으로 할인 판매를 한 적이 있길래, 지른 적이 있습니다.

    툼레이더 2는 어릴적에 진행했던 건 전체 볼륨의 반도 안되는 양이었다는 것에 좌절했고, 9 는 진행이 막혀서 봉인 상태이고, 나머지 버전은 건드리지도 않았네요. 툼레이더 1은 단지 도스 박스 위에서 돌린다는 것(=도스 버전이라는 것)에 놀랐구요.

    어쨋던 팩으로 구매했기에, 모든 툼 레이더 시리즈를 정품으로써 언제든지 플레이 가능한 환경은 되었는데, 정작 손은 잘 안가는 느낌입니다... 명작이긴 한데, 딱히 해야 한다는 느낌은 받기 힘든?ㄲㄲ

    1. 사무엘 2013/12/11 04:33 # M/D Permalink

      저는 데모 형태로조차도 전혀 접해 보지 않은 버전은 어둠의 천사, 언더월드, 9 정도네요.
      다들 컨텐츠가 굉장히 많고 플레이 시간이 길긴 합니다. 제 정도의 게임 실력으로는 공략집 없이 하기가 거의 불가능한 난이도이기도 했구요.
      PC 통신 내지 잡지로 공략 보면서 퍼즐을 풀어 나가던 추억이 있습니다. ^^

Leave a comment

Windows 8 사용기

나보다 훨씬 더 전부터 8을 사용해 오신 분들께는 전혀 새로울 게 없는 정보이겠지만 어쨌든.
Windows 8은 잘 알다시피 데스크톱 PC용 소프트웨어에다 모바일 컨셉을 최대한 융합시킨 형태로 만들어졌다. UI 상으로는 Ctrl+클릭이 아닌 일반 클릭(=일반 터치)만으로 아이템 개별 복수 선택이 가능하게 바탕화면 아이콘들에 체크 박스가 뜨는 변화가 눈에 띈다.
그런데 문제는 Windows는 모바일 컨셉을 아무 단절감 없이 갖다붙이기에는 20여 년의 짬밥을 자랑하는 legacy가 너무 많다는 것. 이를 잘 절충하는 것도 숙제라면 숙제였을 것이다.

그래서일까?
Windows와 마소 제품들은 XP 이래로 모든 GUI가 “각진 직선이건 것이 둥근 곡선으로, 무미건조하던 단색이던 것이 그러데이션으로”라는 트렌드를 따르고 있었는데..
8에서는 이 추세를 정면으로 뒤집은 단순한 복고풍 디자인으로 돌아갔다.
이건 전력 소비를 조금이라도 줄여야 하는 모바일 환경과의 조화를 염두에 둔 설계라고 그런다. 흠..
아이콘도 마찬가지로, Office, Visual Studio도 2012 버전은 아이콘 디자인이 다 초단순 형태로 바뀌었다.

IME들은 아이콘이 아예 흑백 컨셉 배색으로 파격적으로 바뀌었다. 모든 프로그램들이 IME와 한/영 상태를 공유하는 파격적인 기능이 추가되었으며, IME 아이콘과 상태 아이콘 딱 둘만 갖고 있게 단순화된 것은 TSF의 도입 이전 internat.exe 시절의 추억을 떠올리게 한다.

아울러, 프로그램 제목이 Windows 95/NT4 이래로 왼쪽 정렬이던 것이 가운데 정렬로 바뀐 것은 3.x 시절을 떠올리게 하기에 충분하다. 사실, 그 전의 1.x부터 3.x까지는 죄다 가운데 정렬이었기 때문이다.

또한 8은 메트로인지 뭔지 Modern UI 엔진을 얹느라 어쨌든 더 무거워졌을 텐데 그래도 비스타/7에 비해 체감상 딱히 무겁다는 느낌은 안 든다. 덩치에 비해 최적화를 잘 한 것 같다.
Modern UI 기반 앱은 전체 화면으로 동작하는 게 마치 예전의 도스용 프로그램들이 화면 해상도와 색상이 훨씬 더 향상된 채로 동작하는 것 같다.

단, 한 가지 이해가 안 되는 건, 과거 비스타/7의 Aero 컨셉이 완전히 폐기되었느냐는 것이다.
프로그램 창의 굵은 border에 비스타/7처럼 금속/유리 느낌이 드는 반투명 효과를 내는 기능이 없어지고 굵직한 입체 효과 그림자도 없어졌으며, 그저 투박한 solid color만 표시해 주는 걸로 일부러 바꿨는지? 비주얼에 관한 한 이건 좀 진보가 아니라 퇴보인 것 같다. 정발된 제품 말고 preview 버전에서는 반투명 효과가 여전히 있었던 것 같던데.
사실은 예제로 제공되던 테마와 배경 사진들의 수도 Windows 7 시절에 비해 오히려 줄었다.

또한 Windows 95/NT4부터 이어져 온 전통인 시작 메뉴가 없어지고, PC에 설치돼 있는 프로그램들을 리스트 형태로 한눈에 조회할 수가 없고, 심지어 컴퓨터를 끄는 방법도 직관적으로 찾을 수 없는 것은 아무리 새로운 디자인을 시도했다 해도 너무 이질적이고 과격한 것 같다. 실제로 Windows 8을 구했지만 이런 것 때문에 너무 불편해서 다시 7로 복귀한 사람도 주변에 심심찮게 보인다. 과거에 비스타 쓰다가 XP로 도로 복귀하던 사람들처럼 말이다.

나도 컴퓨터 끄는 명령을 못 찾아서 한동안 그냥 데스크톱 바탕 화면에서 Alt+F4를 누르곤 했다.
마우스로 화면 우측 하단을 가리킨 뒤, Settings를 고르고, Power, Shut down을 순차적으로 고르면 되긴 한데 예전 버전보다 접근하기 불편하긴 하다. 컴퓨터 사용을 끝내려고 하는데 왜 시작(Start) 버튼을 눌러야 하느냐는 전통적인 딴지를 의식한 디자인인 건지?

그리고 내가 쓰던 어떤 Windows 8은 팝업 메뉴가 전통적인 왼쪽 기준이 아니라 오른쪽 기준으로 완전 듣도 보도 못한 생뚱맞은 엉뚱한 방식으로 표시되곤 했다. 이건 R2L이 일상인 아랍 문화권에 대한 배려인지는 모르겠지만, 한국어나 영어밖에 볼 일이 없는 나 같은 사람한테는 전혀 필요하지 않은 쓸데없는 기능임. 구글링을 통해 문제를 해결해야만 했다. 다음 레지스트리 값을 1이 아닌 0으로 고친 후 계정 로그인을 다시 하면 된다.

HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows → MenuDropAlignment

전반적으로는..
8은 분명 나쁘지는 않다. 허나 멀티터치가 지원되는 화면에서 Modern UI 앱을 즐겨 쓸 게 아니면, 굳이 7 잘 쓰던 걸 8로 바꿀 필요가 있나 하는 생각이 들기도 한다.

끝으로, 바야흐로 201x년대에 등장한 Windows 8에서도 여전히 버프를 못 받고 시간이 완전히 정지해 버린 듯이 보이는 legacy GUI 요소를 둘 보이고 글을 맺겠다.

1. MDI 창

사용자 삽입 이미지

안구에 습기가 찬다. 응용 프로그램의 border가 다 딱딱한 사각형으로 바뀐 마당에 MDI 프레임은 여전히 둥근 모서리 그대로이다. Windows Vista 이래로 코드가 하나도 고쳐진 게 없다는 뜻이다.

2. HTML 도움말

사용자 삽입 이미지

10~15년 전에 HTML 도움말이 처음 등장했을 때나 지금이나, 일단 프로그램 아이콘이 16색 그대로이다. 레지스트리 편집기와 더불어 아이콘이 고정불변인 극히 드문 프로그램에 손꼽힌다. -_-;;

그리고 HTML 도움말의 About 화면을 보면 연도가 2002년에서 멈춰 있음을 알 수 있다. 캐안습.
그래도 마소가 HLP와는 달리 CHM의 지원은 그렇게 섣불리 중단하지 못할 것이다. 운영체제 차원에서 이 정도로 완성도 높은 도움말 엔진을 제공해 줄 다른 대안이 없기 때문이다.

마소 역시 다른 모든 프로그램에서는 구닥다리 HTML 도움말을 버리고 다른 방식으로 도움말을 표시하지만, 레지스트리 편집기에서 F1을 누르면, 여전히 CHM 도움말이 HTML 도움말로 표시된다.
일반 사용자들이 즐겨 쓸 걸로 예상하지 않는 프로그램에 대해서는 UI를 대강 만들고 legacy 기술만으로 대충 때운다는 걸 알 수 있다.

Posted by 사무엘

2013/05/10 08:30 2013/05/10 08:30
Response
No Trackback , 3 Comments
RSS :
http://moogi.new21.org/tc/rss/response/828

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

Comments List

  1. 사샤나즈 2013/05/11 16:50 # M/D Reply Permalink

    컨슈머 프리뷰까지는 에어로 글래스가 되다가 릴리즈 프리뷰에서 사라졌었네요. 그러고 보니 이전 프리뷰 버전에선 블루필이란 거 먹여서 메트로 모양으로 버튼모양 바꾸는 등 숨겨진 기능 활성화했던 기억도 있네요. 나중에 오피스 2013이 오피스 15라고 스크린샷 유출되어서 아 윈도8은 저렇게 나오려나 싶어서 에어로 글래스 끄고 테마 하얗게 입혀서 이쁘다 하고 쓰고 그랬는데!

    수학식 입력판? 정도로 번역되었을 것 같은 Math Input Panel도 메트로로 바뀌지 않고 에어로 UI 그대로 갖고 있더군요...

    1. 사무엘 2013/05/12 10:28 # M/D Permalink

      아하, 제가 봤던 Aero 되던 놈도 아무에게나 받는 링크가 공개되어 있던 컨슈머 프리뷰였던 것 같습니다.
      나중에 윈8이 정발된 뒤에도 개발자용 msdn으로 풀린 물건과, 노트북 PC에 기본으로 깔렸던 물건은 처음에 메뉴의 방향이라든가 copyright 연도 등 사소한 UI들이 이것저것 차이가 있어서 왜 그런가 궁금했습니다. 그리고 Aero도 어느 샌가 사라져 있었고요.

    2. 김재주 2013/05/12 16:26 # M/D Permalink

      수식 입력기였던 것 같네요.

Leave a comment
« Previous : 1 : 2 : 3 : 4 : 5 : 6 : 7 : 8 : ... 10 : Next »

블로그 이미지

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

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

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

Site Stats

Total hits:
973162
Today:
523
Yesterday:
540