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

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

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

2017/03/22 08:34 2017/03/22 08:34
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1340

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

Comments List

  1. kippler 2017/03/22 23:22 # M/D Reply Permalink

    1번의 경우, http 는 헤더가 암호화 되지 않기 때문에, 헤더를 분석해서 차단된 사이트에 접속할때, 리턴값의 패킷을 조작해서 200 OK 를 302 redirect 로 바꿔버리면 warning.or.kr 로 보내버리는게 가능합니다.
    (네트웍은 아니지만, 같은 PC에서 API 후킹으로 차단 프로그램을 만들어 본 적이 있죠.)
    그래서 https 는 막지 못합니다만, 중국의 GFW 는 어찌 어찌해서 이것도 막는다 하는데 잘 모르겠네요.


    2번의 경우 MTP 인듯 하네요. 저도 이 부분에 대해서 궁금하기도 했는데, 초기 MP3 플레이어들은 USB 외장 드라이브 연결후 MP3 파일을 복사하면 어떤 파일이 복사되었는지 몰랐기 때문에, 연결을 끊은 후 파일 시스템을 전부 스캐닝하는 작업이 필요했었습니다.

    반면 MTP 는 좀 찾아보니. 복사한 파일에 대한 이벤트를 받을 수 있어서 전체 파일 시스템을 뒤질 필요가 없나 보더군요.
    기타, 파일 전송을 제어할 수 있어서 보안이나, 파일 시스템의 투명성(맞나요?)이 가능해지는등의 장점이 있는듯 합니다.


    3번의 경우 좀 다른 이야기 입니다만, 최근 USB-C 지원되는 모니터를 샀는데, USB-C 충전 케이블로는 비디오 신호가 전송이 안되더군요. USB-C 는 이제 비디오 신호까지 지원되면서 상당히 복잡한듯 하더군요.


    4번의 경우 2-3년전 제가 판매중인 라이브러리가 빅엔디안 지원 CPU에서 돌아갈 수 있냐고 문의가 와서, 개발은 가능하지만 테스트를 위해서 장비를 한대 지원해 줘야 했더니 답이 없더군요. 장비이름으로 찾아보니 한 10년은 된듯하던데, 의외로 서버쪽은 워낙 비싸서 그런지 꽤 오래된 장비도 돌리나 보더군요.


    5번의 경우 요즘 CTRL+W 도 많이 쓰이더군요.



    6. 제가 처음 만져본 컴퓨터는 FC-150 이였는데, 사진속의 컴퓨터는 FC-100 이군요. ^^;;;;
    FC-150 의 고무로 된 쫀득쫀득한 키보드는 몇 번 못 만져봤지만 아직도 기억이 납니다.

    1. 사무엘 2017/03/23 10:44 # M/D Permalink

      오옷~ 명쾌한 답변 감사드립니다.

      제 한글 입력기는 인제 와서 빅 엔디언에서 돌려야 된다면, 혹은 machine word align이 안 맞는 게 허용되지 않는 CPU에서 돌아가야 한다면(IA64가 그랬다고 하죠), int/long의 크기가 x86이나 x86-64와 같지 않은 곳에서 돌아가야 한다면.. 장담을 못 하겠네요.
      문제될 만한 부분을 주석이나 조건부 컴파일 같은 걸로 표시를 하면서 코딩 했어야 했는데. 점점 신경을 안 쓰게 됩니다. ^^;;

Leave a comment

macOS 프로그래밍

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

2017/03/11 08:31 2017/03/11 08:31
,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1336

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

Comments List

  1. 경헌 2017/03/11 12:14 # M/D Reply Permalink

    안그래도 지금 맥 한글 입력기가 몇몇 있긴 하지만 무주공산(?) 인 상황인데요..
    날개셋 입력기를 언젠가 맥에서 쓸 수 있는 날을 고대해 봅니다 ㅎㅎ

    1. 사무엘 2017/03/11 16:19 # M/D Permalink

      타 OS 포팅 작업을 해 보면 지금 날개셋 엔진 내부도 플랫폼 종속적인 부분과 그렇지 않은 부분에 대한 추상화 수준이 더 올라갈 수 있겠습니다. 하지만 정말 쉽지 않을 것 같습니다. ^^;;

Leave a comment

이 글에서는 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 사무엘

2017/01/28 19:35 2017/01/28 19:35
,
Response
No Trackback , 3 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1321

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

Comments List

  1. kippler 2017/02/02 01:30 # M/D Reply Permalink

    오늘도 잘 보고 갑니다.

    85되었수다 보면서 재밌다기보다 부러운 감정을 느꼈던 때가 생각나네요.

    ==

    "게임" 이 제일 큰 수익원 이라는데는 이견이 없습니다만, 은근히 "앱"도 수익이 되는듯합니다.

    물론 주변에 성공사례가 적어서 일반화 시키기 힘들어 보이기는 합니다만.

    1. 사무엘 2017/02/02 10:25 # M/D Permalink

      오옷~ kippler 님, 정말 오랜만에 뵙네요. 반갑습니다. ^^;;
      그 시절에 벌써 저런 게임을 만든 사람도 있는데 난 뭐 했나 싶은 자괴감이 충분히 들지요.
      그때는 그때이고, 지금 "일반적인 앱"으로 그 얼마 안 되는 성공 사례를 만들고 계신 선배님 같은 분도 충분히 존경스럽습니다.
      좋은 선례를 남겨 주셨으면 하는 바람 간절합니다.

  2. kippler 2017/02/04 16:52 # M/D Reply Permalink

    네, 사족을 달자면...

    제가 언급한 저 "앱"은 (정확히 확인은 못했습니다만) 최근 꽤 고무적인 성공 사례를 관찰해서 쓴 글입니다. ^^


    요즘 청년 창업이 이슈중 하나인데, 이바닥은 대부분 게임이나 서비스쪽으로 몰려있는듯 해서

    좀 아쉬운감이 있어서 써봤네요... 아 물론 저도 좋은 사례가 되기 위해서 노력하고 있습니다. ^^

Leave a comment

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

2016/12/28 08:35 2016/12/28 08:35
,
Response
No Trackback , 4 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1310

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

Comments List

  1. 근성인 2016/12/28 13:01 # M/D Reply Permalink

    판교에 저런 화장실이 좀 있지

    1. 사무엘 2016/12/28 15:57 # M/D Permalink

      그렇다? 공공장소에서 화장실은 밖에서 안이 한눈에 노출돼 보이지 않도록 입구를 일부러 좀 꼬불꼬불하게 만들기도 하고. ㄲㄲㄲ

  2. 허국현 2017/01/02 10:08 # M/D Reply Permalink

    실제로 DMZ에서 움직여야 할 때 툼 레이더를 떠 올려 본 적이 있었습니다. 그 누님(?, 이제는 여동생인가요? 나이를 거꾸로 드셨으니?)이 얼마나 강력하신 분인지 다시 한 번 깨닫게 되었습니다.

    길이나 그런게 전부 자연이고, 콘크리트도 적당히 섞여 있어서 진짜 통일 되서 그 동네 지형 마음대로 써도 되면 한 번 만들어 볼만한 가치가 있다는 생각이 들더라고요.

    1. 사무엘 2017/01/02 11:14 # M/D Permalink

      ㅋㅋㅋ 그렇죠, 그 생각을 저 혼자 했을 리는 없을 겁니다.
      자연 속에 간간이 섞여 있는 콘크리트 인공 구조물 + 군사 각개전투.
      인공 구조물이란 게 고대 유적 유물이 아니고 현대 유물이긴 하지만 그래도 역사적인 중요도는 굉장히 높지요.
      툼 레이더 시리즈들 중에 특별히 3편(남극, 미국 51구역 등 세계 방방곡곡!)이나 '어둠의 천사'(본격적으로 군인 코스프레), 레전드에는 들어가기에 아무런 손색이 없다고 여겨집니다. 언더월드는 다시 고대 유물 + 판타지 컨셉이어서 좀 제끼고.

Leave a comment

본인은 태생적으로 신체 활동을 싫어했다. 운동 경기는 스스로 하지도 않고, 남이 하는 걸 즐겨 보지도 않았다. 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에서 스키를 타고 이동하는 게임은 다 종(세로) 스크롤이라는 차이가 있다.

그러고 보니 뭔가를 타고 울퉁불퉁한 지면 위를 달리는 명작 고전 게임으로는 Super Off Road가 있다. 비슷한 1989년작.

사용자 삽입 이미지

얘는 자동차 경주 게임이지만 화면 스크롤이 없다~! 한 화면에서 모든 경주가 행해진다. 스크롤도 없고 콩알만 한 자동차 스프라이트로 무슨 박진감을 표현하겠나 싶지만 평면에서 나름 복잡한 지형과 입체적인 자동차의 움직임을 표현하는 것은 딱 봐도 결코 쉬운 일이 아니어 보인다. 방향과 각도별 스프라이트 로직 설계를 어떻게 했을까? 나보고 저것과 똑같은 게임을 만들라고 하면 못 하거나 엄청 고생하지 싶다.

우리 주인공은 빨간 차인데, 노랑과 파랑은 제끼고 회색 차가 유난히 잘한다. 쟤만 따돌리면 된다.
이 게임은 국내에서는 그냥 '방구차'라고 불렸는데, 왜냐하면 Nitro라는 아이템을 먹어서 그걸 터뜨리면 마치 스타크래프트 마린이 스팀팩을 쓰듯이 일시적으로 차의 추진력이 올라갔기 때문이다.

하긴 <분노의 질주>(Fast and Furious) 영화도 보니까 그런 추진제가 나오긴 하더라만..
Nitro를 터뜨려서 연기를 내뿜는 모습이 마치 방귀를 뀌는 것과 비슷하대서 '방구차'라는 직관적인(?) 이름이 붙었으리라 추정된다.

사용자 삽입 이미지

방구차의 개발사는 앞서 소개한 Epyx나 EA와는 무관한 또 다른 회사이다. 얘는 PC용으로도 해 보고 오락실에서도 응당 해 봤다.

Posted by 사무엘

2016/11/07 08:32 2016/11/07 08:32
,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1291

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

Leave a comment

1.
예전에도 한번 이런 비유를 꺼낸 적이 있었는데.. 라면을 소프트웨어 플랫폼에다 비유하자면 봉지 라면은 PC, 사발면은 태블릿, 컵라면은 스마트폰 정도에 대응하는 것 같다. 그래서 한 플랫폼에서 잘나가던 라면이 다른 플랫폼으로 종종 포팅되곤 한다(카카오톡 PC 버전, 오피스 안드로이드 버전처럼). 비록 둘이 맛이 완전히 동일하지는 않지만 말이다.

식당에서 주문해서 먹는 라면은 집 밖의 거대한 다른 가게에 들어가서(서버 접속) 먹는 것이니 서버 사이드 웹 애플리케이션일 것이며..
분식점 같은 식당 납품을 목적으로 라면 제조사가 면이나 스프만을 대량으로 따로 파는 건 '엔진' 같은 미들웨어 컴포넌트 내지 라이브러리에 대응한다고 볼 수 있겠다.

2.
스마트폰은 컴퓨터와 달리.. (1) 특별한 일이 없는 한 24시간 켜져 있고, (2) 열받고 뜨거워질지언정 그래도 팬 돌아가는 소리가 안 나고, (3) 보조 기억장치가 있지만 하드디스크 돌아가는 것 같은 소리는 전혀 없다.
그래서 (2)와 (3)을 종합하면 스마트폰은 아주 조용하다. 게다가 얇기까지 하다.
어찌 보면 세상에 어떻게 이런 컴퓨터가 존재 가능해졌는지 신기한 노릇이 아닐 수 없다. 그것도 화면은 옛날 구닥다리 액정 같은 단색이 아니라, 고해상도 천연색 그래픽을 찍어 낸다. CPU뿐만 아니라 디스플레이나 메모리까지 총체적으로 왕창 발전했기 때문에 스마트폰이 만들어질 수 있었다.

옛날에는 뭔가 영상이 표시되는 기계 자체가 굉장히 미래 하이테크의 상징이었다. 집 현관을 표시해 주는 인터폰이나 자동차 내비 같은 거 말이다.
텔레비전이나 컴퓨터 모니터는 아날로그 신호에 둥그런 브라운관 형태로나마 진작부터 천연색을 표현할 수 있었다. 하지만 들고 다닐 수 있는 소형 텔레비전이나 인터폰, CCTV 같은 건 원가 때문인지 무엇 때문인지, 의외로 흑백 버전이 2000년대까지 쓰였다. 본인은 몇 차례 이사를 다니며 집을 옮긴 적이 있지만, 컬러 화면이 나오는 인터폰 실물을 태어나서 지금까지 한 번도 구경을 못 해 봤다.

그런데 어느 샌가 갑자기 CCTV의 화질이 급격히 향상되고 차량들이 개나 소나 내비에 블랙박스까지 달고 다니면서 블랙박스에 찍힌 사고 영상만 모아서 보여 주는 TV 프로가 큰 인기를 모을 정도가 됐다. 사진과 동영상을 즉각 생성해서 남들 보는 사이버 공간에 용량과 트래픽 걱정 없이 올리는 게 너무 금방, 쉽게 가능해졌다. 이건 1980년대의 SF물들이 제대로 상상하지 못한 너무 엄청난 변화임이 틀림없다.

그리고 컴퓨터 자체도.. 이젠 스마트폰 내부에서 가상 머신을 돌려서 도스는 말할 것도 없고 과거의 Windows 9x를 구동할 수도 있게 됐다. 머리만 비교하면 스마트폰의 CPU가 일반 데스크톱 PC의 CPU와도 성능이 호각이 됐으며, 단지 PC에 비해 부족한 건 입력 장치와 하드디스크 정도밖에 없다고 한다. 발열이나 전원의 한계는 차치하고라도 말이다.

모바일 플랫폼이 등장하면서 PC에서 x86 계열 CPU + Windows 계열 운영체제를 총칭하는 '윈텔' 독점 구도도 상당 부분 흔들리게 됐다. 완전히 새로운 형태의 시장 수요를 창출해 냈으니까. x86은 30년을 넘게 거슬러 올라가는 유구한 하위 호환성을 자랑하지만, 그 때문에 저전력 모바일에서 빠릿빠릿 움직이는 용도로는 상당히 부적합한 CPU가 돼 버려서 말이다. Windows도 마찬가지다.

다만, 단순히 이미 만들어진 정보들을 받아 보기만 하는 인터넷 단말기 이상으로, 뭔가 글쓰기나 코딩 같은 생산적인 활동을 하기에는 스마트폰은 문자 입력이 너무 불편한 게 흠이다. 구닥다리 타자기의 인터페이스를 답습하고 있지만 그래도 문자 입력 분야에서 키보드만 한 가성비를 제공하는 물건은 아직까지 없다.

예전에 그나마 전화기 버튼이라도 있던 시절에는 3*4 배열이라는 틀은 고정돼 있었는데..
요즘 스마트폰은 화면의 절대적인 크기나 종횡비까지 전부 그냥 흰 도화지 수준인 거 같다. 인간에게 가장 적합한 글쇠 scheme은 어떤 형태일까? 블루 오션이다 보니 먼저 연구해서 표준 틀을 정착시키는 사람이 그냥 장땡이 돼서 혼자 다 해먹을 수 있을 것 같은 생각이 드는데.. 난 잘 모르겠다. 난 한글 입력 쪽은 글쇠배열이 아니라 일단은 근본 메커니즘 연구가 주 관심 분야인지라..

글쇠 수가 너무 많으면 안 그래도 작은 화면에 너무 작은 글쇠 버튼을 잘못 찍어서 오타를 내기 쉽고, 반대로 글쇠 수가 너무 적으면 타수가 늘어나고 이것저것 모드를 바꾸는 빈도가 잦아져서 그것대로 또 입력이 불편해진다.
구글 단모음을 한동안 써 보다가 불편해서 다시 나랏글로 돌아왔다. ㅎ, ㅔ 같은 자모를 한 번에 바로 입력할 수 있어서 편한 것보다, 오타가 나서 불편한 게 더 크게 느껴졌다. 개인적으로는 나랏글을 거의 2004년부터 10년 넘게 쓰기도 했고 말이다.

3.
스마트폰이 폭발적인 인기를 끌면서 오늘날과 같은 사진· 동영상 업로드 문화를 만들어 낸 건 두 말할 나위 없이 '디지털 카메라' 기능까지 전화기 안에 쏙 들어간 덕분에 가능했다.
오늘날 폰의 카메라가 단순 화소수와 색감만 따지자면 어지간한 보급형 디카의 성능을 다 따라잡고도 남는다. 하지만 폰 카메라가 전용 디지털 카메라를 결코 따라잡지 못하는 게 크게 둘 있는데, (1) 줌과 (2) 부팅 속도이다.

근본적으로 카메라의 형태로 적합하게 설계되지 않은 그 얇은 몸체에다 두꺼운 다기능 렌즈까지 우겨넣는 건 아무래도 무리다. 그렇기 때문에 폰 카메라는 줌 기능이 전문적인 카메라의 적수가 될 수 없다. 시야각도 한계를 받기 때문에 이걸 극복하려면 별도의 파노라마 합성 앱 같은 것의 도움을 받아야 한다.

또한 디지털 카메라는 사진을 찍을 때에만 잠시 켰다가 끄는 걸 스마트폰보다 훨씬 더 간편하게 할 수 있기 때문에 밖에서 사진을 몇백 장씩 산발적으로 찍을 일이 있을 때 전력 소모 부담이 훨씬 덜하다. 부팅도 아예 범용 컴퓨터인 스마트폰보다야 비교할 수 없이 더 빨리 되며, 전원을 켜자마자 거의 곧장 촬영 ready 상태가 된다. 그 반면 스마트폰은 이런 특성을 전혀 갖고 있지 못하다.

하긴, 피처폰이 스마트폰으로 바뀌고 스마트폰에 온갖 복잡 다양한 기능들이 추가될수록 사용자가 알게 모르게 치르는 대가로는 배터리 시간이라든가 폰의 물리적 내구성 같은 게 있다. 이와 비슷한 맥락에서 스마트폰도 켠 직후에 수 초 이내로 바로 쓸 수 있는 게 아니라, PC에 준하는 급의 부팅이 필요하고 엄청난 양의 초기화와 캐싱, pre-fetching을 해 줘야 쓸 수 있는 물건이 되고 있다. 예전에 PDA나 공학용 계산기가 그렇게 부팅 시간이 긴 물건은 아니었으니 말이다. 부팅이 존재하고 악성 코드 걱정을 해야 하는 기기는 다른 전자 기기와는 성격이 근본적으로 다르며 훨씬 더 능동적인 물건이다.

한때는 이런 작은 화면에 찍히는 글자는 초간단 비트맵 글꼴 기반인 게 당연시되었는데 그게 힌팅까지 적용된 미려한 윤곽선 글꼴로 바뀌었다는 것 하나만으로도 소프트웨어적으로는 예전에 비해 그야말로 엄청난 부담이 추가된 거나 다름없다. 윤곽선 글꼴은 캐싱 없이는 도저히 쓸 물건이 못 되며, 캐싱이라는 건 굉장한 양의 메모리를 요구하기 때문이다.

오늘날 컴퓨터 프로그램들이 같은 일을 해도 예전보다 메모리와 CPU를 훨씬 더 많이 요구하는 이유는 유지 관리 차원에서의 범용성과 추상성을 높인 대신에 오버헤드가 더 커지고 성능 희생을 감수한 게 매우 크게 작용한다(가상 머신, 가상 함수, 등등등등). 스마트폰의 전력 소비나 부팅 속도도 그런 맥락에서 살펴볼 수 있을 듯하다.

Posted by 사무엘

2016/11/05 08:37 2016/11/05 08:37
, , , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1290

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

Leave a comment

DOS 회상

1. 들어가는 말

오늘날의 거대하고 복잡한 운영체제와는 달리, 도스는 이니셜 D-_-가 암시하듯이 달랑 플로피디스크 한 장만으로 부팅이 가능할 정도로 참을 수 없이 작고 가벼웠다. 정말 필수불가결인 파일은 부팅에 쓰이는 io.sys, 그 뒤 셸 역할을 하는 텍스트 명령 해석기인 command.com이 전부다.
msdos.sys라는 파일도 있는데 얘는 정확하게 무슨 존재인지 모르겠다.

그리고 사실은 config.sys의 DEVICE 명령을 통해 실행되는 sys 파일과, com 실행 파일이 서로 무슨 차이가 있는지도 모르겠다. 마우스, 그래픽 카드 에뮬(simcga, msherc ^^), 사운드(sound, unsound) 같은 여러 램 상주 드라이버들은 com이었지만, 씨디롬 드라이브는 sys였으며 그것도 주 메모리를 꽤 많이 차지하는 드라이버였다. 단, 부팅 후에 sys 파일을 별도로 실행해 주는 유틸리티가 있기도 했다.

디스크로부터 파일을 읽으려면 파일 시스템이 정립돼 있어야 하며, 이건 운영체제가 하는 일 중 하나이다. 그런데 그 운영체제를 로딩하는 프로그램도 파일 형태로 저장돼 있다. 이런 '닭이 먼저냐 계란이 먼저냐' 딜레마를 해소하기 위해서는, 부팅에 쓰이는 운영체제 프로그램은 디스크에 단순히 파일 형태로만 존재하는 게 아니라, 컴퓨터 바이오스가 물리적이고 원초적으로 인식 가능한 첫 지점에 저장돼 있어야 한다. 이건 굳이 도스뿐만 아니라 어느 운영체제라도 마찬가지이다.

도스는 단일 사용자 단일 프로그램 구동 체계이다 보니, 한 프로그램이 그야말로 컴퓨터 하드웨어를 전부 있는 그대로 조종 가능하게 허용하는 백지수표, 열린 허허벌판 같은 환경이었다. 프로그램의 인터페이스도 명령 기반, TUI, GUI 등 제각각이었고 정말 창의적이었다. 요즘 프로그램들만치 UI가 획일화됐다는 느낌이 없이 형형색색 컬러풀했다.

물론 그건 거시적인 관점에서는 그리 효율적이지 못하다. 이런 빵빵한 컴퓨터 자원에서 여러 프로그램을 동시에 실행하고 작업 전환을 할 수 없다면 그것도 컴퓨터에 대한 예의-_-가 아니다.
그러니 운영체제가 더 강력하게 모든 걸 통제하는 지금 같은 환경으로 궁극적으로는 바뀌는 게 맞긴 하지만.. 인제 와서 도스가 다시 새삼스럽게 그리워질 때도 있다.

2. 역사

본인이 경험한 MS-DOS의 가장 옛날 버전은 학교 내지 컴퓨터 학원에서 봤던 3.2/3.3이다. 2.x 이하나 4는 실물로 구경을 못 해 봤다. 다만, 5.0과 6.2는 집 컴퓨터에 내장돼 있던 물건이다 보니 개인적으로 친숙하다.

1981년에 첫 출시되었다고 전해지는 MS-DOS 1.0은 그야말로 정말 골동품 폐물이었다고 한다. 그리고 Windows 1.0이 프로그램 창을 겹치게 배열하는 걸 지원하지 않았다면, DOS 1.0은 디스크에 서브디렉터리를 만드는 걸 지원하지 않았다..;;
그나마 도스가 최소한의 도스다운 틀을 갖춘 건 2를 거쳐서 3.x대에 와서부터이다. 특히 5.25내지 3.5인치 고밀도(1.2, 1.44MB) 플로피디스크를 지원하기 시작한 첫 버전이 이 버전이기 때문이다. 3.x에 와서야 좀 물건다운 물건이 나왔다는 점에서는 도스와 Windows가 역사가 서로 비슷한 것 같다.

그 다음 4.0의 아주 기념비적인 업적은 파일 시스템이 FAT12에서 FAT16으로 확장되어, 이론적으로 지원 가능한 디스크 볼륨의 용량이 2GB로 커진 것이다.
그 시절에 기가바이트는 가히 꿈의 규모였기 때문에 홍보 자료에서는 그냥 '제한이 없어졌다'라는 표현이 관용적으로 쓰였다. 참고로, FAT12 시절의 하드디스크의 용량 한계는.. 고작 32MB였다. =_=;;

또한 MS-DOS shell이라고 나름 드래그 드롭도 지원하고 Windows GUI를 어설프게 베낀 듯한 파일 관리자 셸이 추가된 것도 4부터이다. 하지만 MS-DOS 4는 구체적인 내역은 모르겠지만 불안정하고 버그가 많아서 좀 문제작으로 남았다고 한다.

도스 5.0에서 기념비적인 업적은 그 이름도 유명한 HIMEM.SYS와 DOS=HIGH일 것이다. EMM386은 4.0 때 SYS 버전이 있었지만 5.0부터는 EXE로 형태가 바뀌었다고 한다.
또한 이 버전에서는 과거의 불편하던 EDLIN을 대체하는 QBASIC 기반의 텍스트 에디터가 추가되었으며, 명령 프롬프트에서 cursor 이동을 자유롭게 할 수 있게 하고 히스토리 기능도 넣어 주는 DOSKEY 유틸도 이때 추가됐다.

지워진 파일을 첫 글자 이름을 집어넣어서 복구하는 undelete 역시 아마 6이 아닌 5에서 첫 추가됐지 싶다. 이건 PC-tools나 노턴 유틸리티가 먼저 제공하던 꼼수 기능이었는데 동일 기능을 도스에서 직접 수용한 것이다.

그 뒤 6.0은.. 변한 게 많았다.
가장 유명한 건 하드 디스크를 압축해 주는 '더블 스페이스'라는 유틸리티의 도입이다.
이건 무슨 요술을 부리거나 하드 디스크를 물리적으로 어떻게 하는 게 아니라, 그냥 파일 시스템 차원에서 데이터를 zip 같은 소프트웨어 압축을 적용하는 것일 뿐이다. 당장 용량 확보에는 도움이 되지만 디스크의 액세스 속도가 좀 느려지고 에러에 취약해지며, 하드웨어를 좀 험하게 다루는 일부 프로그램과는 트러블의 여지가 생긴다.

참고로 1993~1994년이면 Windows 3.1이 보급되고 어지간한 PC의 하드디스크는 몇백 MB 정도이던 시절이다.
더블 스페이스는 그렇잖아도 꽤 중요하고 민감한 간판 기능인데, 버그를 많이 잡고 안정화를 더 시켜서 6.2가 나왔다.
그런데 이게 '스태커'라는 타사의 제품을 무단 도용한 것으로 판결이 나서 '더블 스페이스'를 뺀 6.21이 나왔고, 저작권 문제를 해결하여 '드라이브 스페이스'를 대신 도입한 6.22로 6.x대가 마무리 되었다. 지금이야 마소에 대해서 IE 브라우저의 독점 소송이 유명하지만, 1990년대 중반엔 저거 저작권 침해 소송이 IT 업계에서 굉장한 화두였다.

압축 유틸리티 말고도 6.x대엔 멀티 부팅이라는 매우 유용한 기능이 추가됐다. 즉, C/C++의 조건부 컴파일처럼 사용자가 선택한 옵션 방식대로 디바이스 드라이버를 로딩하여 부팅할 수 있게 됐다는 것이다.
그리고 디스크 점검 scandisk, 조각 모음 defrag, 시스템 점검 msd, 주 메모리 확보 유틸리티 memmaker 등이 추가되고 PC-Tools로부터 라이선스 받은 안티바이러스 msav 같은 유틸도 도입됐다. 덕분에 노턴 유틸리티가 예전보다는 좀 덜 필요해졌다.

모든 내부/외부 명령에 /? 옵션을 줬을 때 도움말이 나오는 것도 처음부터 존재한 게 아니었다. 6이거나 아니면 5부터인데 그건 정확하게 기억이 안 난다. 옛날에는 도움말 텍스트를 일일이 내장시켜 줄 정도로 컴퓨터의 메모리나 디스크 용량이 충분하지 못했기 때문이다.

단독 제품으로서 MS-DOS의 역사는 1994년에 출시된 6.22가 끝이었다. 도스는 Windows 95/98/ME와 함께 7.0. 7.1. 8.0 버전으로 명맥을 유지하다가 2000년에 드디어 20여 년의 긴 수명을 마치고 역사 속으로 사라졌다.
도스 외부 명령어 중에서 몇몇 필요한 건 Windows 9x 계열에서는 Windows\command로 갔고, NT 계열은 그냥 system32 디렉터리에 있다. 그리고 NT 계열은 format이나 diskcopy 같은 유틸리티도 콘솔에서 실행될지언정 도스가 아니라 Windows용 프로그램이라는 차이가 있다.

3. 그 당시의 유사품/경쟁자

한편, 도스의 바리에이션으로는..
PC-DOS는 그냥 MS-DOS가 IBM 브랜드만 달고 나온 동일 제품이었다고 한다. 한동안 그러다가 6.x대부터는 서로 다른 길을 가기 시작했는데 이미 그때는 PC 환경이 Windows로 충분히 넘어가기 시작했으니 별 의미는 없다. 따지고 보면 IBM은 OS/2가 망한 데다, 도스 분야도 뒷북으로 끝나고 별 재미를 못 본 셈이다. "IBM 호환 PC"라는 걸출한 대인배 이름만 남긴 채 PC 시장에서는 철수했다.

DR-DOS는 MS-DOS의 전신인 CP/M을 직접 만든 게리 킬달이라는 엔지니어가 '디지털 리서치'라는 회사를 세워서 따로 만든 MS-DOS의 대항마이다. '디알'이지 '닥터 도스'는 아님.. 뭔가 기능이 MS-DOS보다 뛰어났다고 얘기는 들었는데 구체적인 내역은 잊어버려서 기억이 안 난다.
DR-DOS를 '노벨' 사가 인수하여 새로 내놓은 것이 '노벨 도스'이며, 이건 1990년대 초중반까지 나왔다.

한편, 4DOS는 커널을 처음부터 새로 만드는 건 아니고 명령 인터프리터인 COMMAND.COM만 대체하는 기능 확장판으로 컴덕들에게 많이 알려져 있었다. 이걸 시먼텍(Symantec) 사에서 인수하여 자신들이 인수한 다른 유명 솔루션인 '노턴 유틸리티'에다가 집어넣은 것이 NDOS이다. 각종 도스 명령들에서 2% 부족하던 것을 보완하는 편의 기능이 굉장히 많았던 걸로 기억한다. (가령, 중간에 파일이 사라져도 괜찮은 batch-to-memory 배치 파일)

그리고 8.3 짧은 파일 이름의 한계를 보완하기 위해, 내부적으로 descript.ion이라는 숨김 파일을 만들어서 파일명에 대한 '주석'을 표시하는 것도 4DOS의 작품이었다. 옛날에 MDIR도 이걸 지원했다. 파일이 복사· 이동· 개명· 삭제됐을 때 주석도 같이 관리하는 게 좀 번거로운 일이 됐으니까.. NTFS처럼 운영체제의 파일 시스템 차원에서 메타데이터를 관리하는 기능이 없으면 어쩔 수 없이 셸 유틸리티가 뒷감당을 해야 한다.

4. MS-DOS의 한글화

MS-DOS가 최초로 한글판이 나온 것도 2나 3 버전부터이지 싶다. 정말 먼 옛날에는 마소가 잠깐 동안 조합형 코드 기반으로 도스를 한글화화기도 했다는데 지금으로서는 거의 Windows 2.1의 한글판 같은 도시전설이 돼 간다.
허나, 1987년에 지금의 KS X 1001, 그 당시의 KS C 5601 완성형이 제정되자마자 표준을 잘 지키는 마소는 완성형으로 광속으로 갈아탔다. 그게 이미 도스 3 시절의 일이다. 마소는 그냥 표준을 따른 것일 뿐이지만, 결과적으로 조합형 코드를 죽이고 한글을 파괴한 원흉(?)으로 일부 진영으로부터 좀 지탄받곤 했다.

그런데 한글 MS-DOS가 텍스트 모드에서 한글 입출력을 구동해 주는 바이오스 유틸리티를 처음부터 내장하고 있지는 않았던 것 같다. 쉽게 말해 hbios와 그 특유의 바탕체 글꼴을 구경한 건 최소한 도스 5나 6부터이다. 3이나 4 시절에나 그런 게 없었으며, 한글 바이오스는 다른 프로그램으로 구동했었다. 이건 내 기억이 잘못됐을 수도 있음.

hbios는 Windows 95로 가면서 mshbios로 이름이 바뀌었으며, 그 당시의 고유 글꼴은 <날개셋> 편집기에 '마소바탕'이라는 글꼴을 통해 구경할 수 있다. 도깨비나 태백한글 같은 싸제 한글 바이오스들은 조합형/완성형, 두벌식/세벌식, 명조/고딕 등 글꼴과 글자판과 코드를 다 선택 가능했지만, 마소의 보급 바이오스는 당연히 완성형, 두벌식, 명조로 다른 선택의 여지가 없었다.

전에도 한번 얘기한 적이 있었지만, 마소에서 한글화한 프로그램들은 2바이트 문자에 대한 처리가 굉장히 잘 돼 있었다. 2바이트를 구성하는 앞뒤 문자 중 하나가 가려지거나 지워지면 다른쪽 문자도 반드시 같이 사라졌기 때문에 텍스트 모드에서 메뉴나 대화상자가 표시될 때도 문자가 깨지는 걸 보이는 법이 없었다. 이에 대한 처리가 세심하게 돼 있었다.

5. 도스 시절의 멀티태스킹

비록 그래픽은 아니고 텍스트 기반이긴 하지만, Windows 3.x 비스무리한 도스 기반 멀티태스킹 운영환경(운영체제는 아니고..)으로 DESQView 같은 프로그램이 있었다. 난 이름만 들어 보고 실제로 구경은 못 했다. 외국에서는 그럭저럭 쓰는 사람이 있었던 듯하지만 Windows의 등장 이후에는 조용히 역사 속으로 사라졌다.

그리고 사실은 더 발전된 멀티태스킹 운영체제를 마소에서 직접, 그것도 Windows나 OS/2와는 별개로 만들려는 시도를 한 적이 있었다. 무려 1986년, Windows조차 이제 막 개 허접한 1.0이 나왔던 시절에 MS-DOS 3을 기반으로 일명 '멀티태스킹 MS-DOS 4.0'이 계획되었던 것이다. 이것은 앞서 언급한 그 도스 4.0과는 무관한 새로운 개발 브랜치였다.

멀티태스킹 MS-DOS 4는 제품이 나오기는 했고 의도도 나쁘지 않았지만, 1980년대 중반에 시대를 너무 앞서간 문제작이었다. 그 옛날에 그 열악한 하드웨어 환경에서 도대체 뭘 더 바라겠는가? 컨셉에 비해 상품성이 떨어졌다.
게다가 그 당시 마소는 지금처럼 독자적인 불특정 다수용 유명 소프트웨어를 독점 판매하는 공룡 기업이 아니었으며, 여전히 하드웨어 제조사에다 소프트웨어를 납품하면서 먹고 사는 기업이었다. 즉, 지금으로서는 상상이 잘 안 되지만, 업계에서의 위상이 '갑'이 아니라 '을'이었다.
프로젝트를 발주했던 IBM이 이 물건을 더 구입해서 사용하지 않겠다고 선언하자 프로젝트는 흑역사가 되었고, 이 멀티태스킹 MS-DOS 4는 오히려 유럽의 일부 컴퓨터에 OEM 형태로 공급되는 걸로 개발 계보가 끝났다.

멀티태스킹 MS-DOS 4는 비록 GUI 환경은 아니지만 Windows의 전유물로만 알려졌던 NE (new executable) 실행 파일도 지원하고 지금으로서는 무척 신기한 면모가 많았다고 한다. 정작 NE를 사용하던 Windows는 NT가 등장하기 전에는 콘솔 모드라는 게 없었는데, GUI 기반이 아니던 멀티태스킹 도스가 NE를 어떤 형태로 사용했는지 궁금하다.

6. 맺는 말

도스 시절에 메모리 관리를 하는 건 요즘으로 치면 연봉별로 돈 관리하는 요령과 비슷했다. 램이 1MB 이하일 때, 2MB일 때, 4MB일 때, 8MB 이상일 때... HIMEM.SYS와 EMM386을 세팅하는 법, 기본 메모리를 최대한 확보하는 법, 메모리가 왕창 많이 있다면 램 드라이브와 디스크 캐시를 운용하는 요령 등.. 그런 게 1990년대 컴퓨터 잡지들이 고급 정보랍시고 많이 다룬 정보였다.
지금으로서는 그저 격세지감이 느껴질 뿐이다. 그 당시에 기본 메모리라는 개념은 돈에다 비유하자면 당장 손에 있는 현금이고, 나머지 확장 메모리는 통장 잔고나 신용카드 같다는 생각도 든다. =_=;;

MS-DOS의 역사를 살펴보면 많은 걸 느낀다. 금수저 출신의 독종에 천재에 똘끼와 운, 엔지니어 기질과 사업가 기질을 모두 갖고 있는 사람이라면 무슨 여건에다 던져 놔도 결국은 성공했겠다 싶다. 공부만 계속했어도 교수나 변호사가 됐을 사람이 결국은 소프트웨어의 황제로 등극해서 교수· 변호사보다 더한 억만장자가 됐으니까.

물론 빌 역시 그 과정에서 언제나 실력만으로 정정당당하게 승부하지는 않았으며, 경쟁자 치사하게 죽이기 같은 짓을 전혀 안 했다는 건 아니다. MS의 모든 기술과 제품이 100% 빌의 머리에서 비롯된 원천기술인 건 아니며, 그가 미래에 대해 예측한 것이 전부 적중한 것도 아니었다. 그래도 그는 자기보다 더 똑똑한 엔지니어들을 한데 통솔하고 이끌어서 시너지 효과를 잘 낼 줄을 알았다. 그리고 실수를 하고 병크를 저지르더라도, 회사를 완전히 말아먹을 정도로 치명적으로 하지는 않았으며 곧 수습했다.

한편, 게리 킬달은 뭔가 스티브 워즈니악 같은 포스가 느껴지는 공돌이로 보이는데, 실력에 "비해" 빛을 못 보고 좀 어이없게 훅 가 버린 게 안타깝게 느껴지기도 한다.
기술만 있고 너무 고지식하기만 하면 저렇게 되기 쉬운데, 나부터가 딱 그런 스타일이라는 게 문제임.. -_-;;

Posted by 사무엘

2016/05/18 08:39 2016/05/18 08:39
,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1228

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

Comments List

  1. 근성인 2016/05/20 00:21 # M/D Reply Permalink

    마침 DOS에 대한 글이 올라왔네..
    이건 보여주면 좋겠다 싶어서 링크해주고 감.
    http://www.huffingtonpost.kr/2016/05/19/story_n_10042448.html

    1. 사무엘 2016/05/20 08:38 # M/D Permalink

      나도 그거 봤다.. ^^ 사칭· 주작이 아니라면 굉장히 훈훈한 소식이군.
      (저걸 왜 이제서야 알았고 하필 2016년 5월에야 갑자기 댓글 달 생각이 나서 안 하던 트위터도 급 계정 만들었나 싶은 것 정도..)

      더 스케일이 큰 예이다만, 다른 사람이 쓴 김 재현 기관사 관련글에도 외손자라는 사람이 자기 외할아버지 기억해 주셔서 고맙다는 댓글 단 거 본 기억이 난다.

Leave a comment

오늘날이야 우리들의 눈을 현혹하는 온갖 사진과 짤방, 동영상들이 인터넷을 통해 컴퓨터로 현기증 날 정도로 범람하고 터져 나가는 시대이다.
하지만 불과 2~30년 전만 해도 PC는 글이 아닌 그림을 처리하기에는 용량과 성능이 꽤 버거운 물건이었다. 컴퓨터로 뭔가 실사 사진 자체를 구해다 보기가 쉽지 않았다. PC 통신으로 인기 연예인 사진을 단 한 장 다운로드 해서 보는 것조차도 단단히 작정하고 기다릴 준비를 하고서 해야 했다. 그리고 그것도 출처는 종이 화보나 필름 사진 스캔, 또는 아날로그 TV 화면 캡처였다..

21세기에 태어난 애들이 이런 얘기를 듣는 건.. 우리 세대가 부모님에게서 1950, 60년대에 나라가 얼마나 폐허였고 못살았는지를 듣는 것과 비슷한 느낌일 것이다. 아아~ 나도 이런 식으로 올드 타이머 꼰대의 대열에 합류하는구나..;;
그래도 난 옛날 컴퓨터 환경 회상이 좋다. 그러니 얘기를 계속하겠다.

그 시절엔 bmp, pcx를 넘어 gif 정도만 돼도 디코딩이 만만한 작업이 아니었다. 아래아한글 도스용에서 그림을 삽입해 보면 gif는 유독 렌더링이 더뎠다. 그런데 하물며 jpg는... 전용 뷰어가 필요하고 386에 램 얼마 이상, 부동소수점 코프로세서는 필수 이런 걸 요구하는 엄청난 포맷이었다. png 역시 그 당시로서는 신생인 만만찮게 무거운 포맷이었고.

이런 이유로 인해 도스에서 그래픽 뷰어는 나름 단순 텍스트/헥스 뷰어 이상의 유니크함과 전문성(?)을 지녔고 또 그래픽 에디터와는 별개의 입지를 가진 프로그램이었다. GUI 운영체제의 셸이 제공하는 기본 중의 기본, 필수 중의 필수 기능이 그때는 그렇게나 특별한 기능이었다. 도스까지 갈 것도 없이 무려 Windows 95 시절, 웹 브라우저 같은 게 없던 때엔 운영체제 차원에서 jpg 파일을 바로 볼 수 있지 않았다. 그림판은 bmp/pcx 전용이었으니까.;;

그래픽 뷰어는 완전 상업용 제품이라기보다는 셰어웨어로 만들기에 좋은 소재였다. 디렉터리 이동 + 파일 리스트 선택 기능을 구현한 뒤, 사용자가 엔터를 누르면 그 그림을 표시해 주는 게 기본 형태이다.
그런데 그것만으로는 좀 단조로우니 그래픽 뷰어에는 여러 장의 그림을 슬라이드 쇼처럼 보여주는 기능이 응당 추가됐다. 현란한 화면 전환 효과는 덤이고. 요즘 같으면 화면 보호기와 역할이 비슷해졌다.

비주얼 쪽 말고 다른 방면으로는.. 파일 관리 기능이 있다는 점에 착안하여 단순히 뷰어 이상으로 많은 그림 파일들을 일괄적으로 포맷을 변환하고 크기를 보정하고 효과를 주는 기능이 들어갔다. 이건 전문적인 그래픽 에디터와도 기능이 겹치는 구석이 있지만, 이쪽은 드로잉 기능이 없으며 한 파일이 아니라 여러 파일들에 대한 일괄 편집에 더 최적화되었다.
이런 분야에 속하는 프로그램으로 본인은 현재까지 다음과 같은 제품들을 기억하고 있다.

1. Graphic Workshop

사용자 삽입 이미지

모 컴퓨터 잡지/서적을 통해 알게 됐다. 1990년대 초인 꽤 옛날부터 개발되어 온 프로그램이며, 내 기억이 맞다면 GIF를 굉장히 일찍부터 지원해 온 걸로 유명했다.
스크린샷을 보면 알 수 있듯, 전반적으로 셸은 파란 배경의 단순한 텍스트 모드에서 동작했고 단순 표시뿐만 아니라 포맷 변환, 크기 조절 같은 그림 파일 관리 기능도 갖추고 있었다.

1989년에 처음 개발됐는데 91년에 벌써 버전이 6을 넘어간 건 도대체 개발과 버전업이 어떻게 돼 왔다는 뜻인지 모르겠다. MS Word는 다른 제품과 번호를 맞추기 위해서 2에서 바로 6으로 넘어가긴 했다만..;;
개발사인 Alchemy Mindworks라는 회사는 지금도 살아 있으며, 이 프로그램은 Windows용으로 계속 개발 중이다.

2. SEA

사용자 삽입 이미지

그래픽 뷰어 중에서는 느낌이 굉장히 인상적이었다. 일단, 왓콤 C/C++ 32비트 에디션으로 만들어진 덕분에, 게임도 아닌 것이 첫 실행 때 DOS/4GW(도스 익스텐더) 로고가 떴다.
성능면에서는 jpg 파일의 디코딩이 경쟁 프로그램들 중 가장 빠르다고 자처했다. 그림뿐만 아니라 소리 파일 재생이 됐으며, 동영상도 AVI 중에 1990년대 중반 런렝쓰 정도의 간단한 방식으로 압축 된 건 바로 재생 가능했다.

스크린샷을 보면 알 수 있듯 일괄 변환과 슬라이드 쇼 기능 정도는 물론 갖추고 있었으며,
이 모든 것에 더해서 전반적인 GUI 껍데기도 NextStep 운영체제를 흉내 낸 듯한(바탕에 검정 제목 표시줄) 상당한 고퀄이었다.
여러 모로 인상이 좋고 장인 정신이 느껴지는 잘 만든 프로그램이었다. 비등록 셰어웨어 버전도 첫 실행 때 '등록 해 주세요. press any key'가 뜨는 것 말고는 별다른 제약이 없어서 상당한 대인배이기까지 했다.

3. ACDSee

운영체제에 gif/jpg/png급 그림 파일을 보는 기능이 자체적으로 없던 Windows 95~98/2000 시절에는 개인적으로 이 프로그램을 유용하게 썼다. 이름이 똑같이 '씨'인데 앞의 도스용 프로그램은 sea이고 요 프로그램은 see이다.
얘도 한때는 내가 운영체제를 새로 설치한 뒤에 MDIR만큼이나 곧장 설치하는 필수 프로그램 중 하나였다. 굉장히 유용하게 썼다. SEA의 Windows 버전이나 마찬가지였는데, 해당 기능을 운영체제가 흡수한 뒤에는 정말 자연스럽게 존재감이 싹 없어져 버렸다.

그 첫 신호탄은 Windows에 IE 웹브라우저가 포함돼 들어가면서 기본적인 그래픽 뷰어 문제는 사실상 제공되기 시작한 사건이다. 월드 와이드 웹이라는 게 글과 그림으로 이뤄져 있으며 웹브라우저는 그 자체가 훌륭한 단백질 공급원은 아니고 훌륭한 그래픽 뷰어였기 때문이다. 단, IE는 옆 파일을 바로 열람하는 기능조차 없고 진짜 보는 것 하나만 가능하기 때문에 전문 뷰어/슬라이드 쇼 프로그램이 여전히 존재 의미가 있었다.

한 디렉터리 안에 있는 그림 파일들을 IE 창에서 쭈욱 열람하기 위해서 그 디렉터리를 기준으로 <img src="...."/> 태그를 쭈욱 나열하는 html 파일을 '생성하는 프로그램'을 짜서 개인적으로 활용했던 기억이 있다. 물론 이건 썸네일만 읽어들이는 게 아니라 파일들을 몽땅 한 페이지에다 읽어들이는 것이니 성능면에서는 좀 안습한 짓이긴 하다.

그리고 둘째 확인사살은 Windows XP이다. 얘부터는 탐색기 내부의 파일 리스트에서 그림 썸네일을 보는 편의 기능이 크게 강화되었으며, 그럭저럭 가볍고 괜찮은  그래픽 뷰어까지 내장됐기 때문이다. 그러니 별도의 싸제 그래픽 뷰어 프로그램에 대한 필요는 거의 사라졌다. 이런 이유로 인해 기존의 그래픽 뷰어들은 생존을 위해서 포토샵 같은 이미지 보정 기능을 더 강화한다거나 디지털 카메라 사진 관리 같은 더 차별화되고 전문적인 영역으로 넘어갔으며, 내 기억 속에는 현업에서 다들 물러나고 추억의 영역만 남게 되었다.

한때는 Paint Shop Pro에 내장돼 있는 Browse 기능도 유용하게 썼던 것 같은데 지금은 그냥 MS Office에서도 2003부터 Picture Manager라는 유틸리티가 생겨 있다. 예전에는 희귀했던 기능들이 지금은 다 기본으로 내장되고 대중화가 된 것이다.
단, Windows XP의 기본 그래픽 뷰어는 애니메이션 GIF를 재생하는 것까지도 지원했는데 Vista 이후부터는 그 기능은 없어졌다. 왜 빠졌는지는 알 길이 없다.

여기까지가 그래픽 뷰어 프로그램에 대해 본인이 갖고 있는 추억이다.
하긴, 음악을 듣는 것도 한때 꽤 먼 옛날엔 거원 제트오디오, WinAmp 같은 프로그램을 따로 썼다. 그러다 언제부턴가 그냥 WMP만 쓰지 다른 건 안 쓰게 됐다.
그래도 동영상은 WMP가 코덱과 자막 등 부족한 구석이 많이 있어서 팟/곰 같은 제3자 프로그램이 여전히 살아 있다. 내가 알기로 마소에서 WMP도 거의 IE11만큼이나 이제 더 만들 게 없는지 별로 육성은 안 하는 것 같다.

Posted by 사무엘

2016/05/16 08:32 2016/05/16 08:32
, , ,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1227

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

Comments List

  1. nyam 2016/05/19 20:56 # M/D Reply Permalink

    예전 Windows 3.1을 쓸 때 ACDSee 1.3 ~ 1.6 16비트 버전대를 썼던 기억이 납니다..
    당시 Borland C++ 4.5로 만든 실행파일 같던데

    나중에 Win32용으로 만든 ACDSee 2.x대 버전은 Visual C++ 6.0으로 만들었더군요..

    OWL이나 MFC 등 아무런 외부 프레임워크에 의존하지 않고 오직 API에만 의존(?)했기 때문에
    컴파일러를 이리저리 쉽게 교체할 수 있었던 것 같습니다..

    1. 사무엘 2016/05/20 08:36 # M/D Permalink

      역시 전문 분야가 그쪽이시니 ACDSee 같은 프로그램도 무려 16비트 초창기 시절부터 써 보셨군요~!
      제법 덩치 있는 프로그램이 그렇게 개발툴이 바뀌는 건 쉽지 않은 일인데 정말 특정 프레임워크에 의존하지 않은 구조이긴 해야 하겠습니다.
      오랜만에 뵙네요. 반갑습니다. ^^

Leave a comment

텍스트를 입력· 편집하는 기능을 제공하는 에디터나 개발툴, 워드 프로세서에는 응당 텍스트를 검색하는 기능이 있다.
찾기 명령은 아무래도 바꾸기 명령과도 같이 쓰이는 경우가 많으니 이건 편집 기능의 일종으로 간주되며, 보통은 '편집' 메뉴의 하위 항목으로 들어가는 편이다.
그러나 편집 메뉴가 이미 다른 기능들로 너무 비대한 상태이거나, cursor를 원하는 조건대로 이동시키는 찾기/탐색 기능이 별도로 굉장히 전문적으로 발달해 있는 경우, '검색(Search)'이라는 메뉴가 따로 존재하기도 한다.

이 메뉴 구성은 프로그램들마다 제각각이다.
과거에 아래아한글은 1.x대까지 '찾기' 메뉴가 별도로 있다가 2.1부터 '편집'으로 들어갔다. 전반적으로 기능들이 메뉴에 많이 추가되면서 두 메뉴의 인수 합병에 정당성이 생긴 것이다.
Windows의 메모장은 9x 계열의 것은 '찾기' 메뉴가 존재하는 반면, 2000/XP의 것은 그렇지 않고 '편집' 메뉴에 있다.

<날개셋> 편집기는 1~2.x대까지는 찾기 기능이 '편집' 메뉴에 있었지만, 3.0부터는 별도의 '검색' 메뉴로 분리되어 지금에 이르고 있다. 검색과 관련된 기능들을 전부 편집에다가 몰아 넣으면 보기, 삽입, 도구 같은 다른 메뉴들에 비해 '편집'만 항목 수가 너무 많고 비대해지기 때문이다.
그렇다고 <날개셋> 편집기가 무슨 메모장만치 그렇게 기능이 적은 초소형 프로그램도 아니니.. 양 극단 사이에서의 고민 끝에 지금과 같은 메뉴 배치를 선택했다.

한편, 내 편집기에는 없지만 좀 기능깨나 있다 싶은 텍스트 에디터들은 Find in files 기능이 필수이다. 그런데 알고 보면 얘의 정체성도 약간 오락가락 하는 편이다.
아래아한글은 2.0에서 이 기능이 최초로 추가된 이래로 요게 '파일' 메뉴에 쭉 있어 왔으며, Visual C++ IDE도 옛날 버전에는 한동안 파일 메뉴에 있었다. 아무래도 한 문서를 편집한다기보다는 inter-file스러운 기능이라고 생각하고 그렇게 '파일'에다 분류했던 듯하다.

하지만 Visual C++의 경우 6인가 닷넷 이후부터 이 기능은 '편집' 메뉴로 이동했으며, IDE의 버전이 올라갈수록 요건 기존 '찾기' 기능의 자연스러운 연장선 형태로 인터페이스가 바뀌어 왔다는 게 주목할 점이다.
물론 '검색' 메뉴가 별도로 있는 에디터라면 Find in files는 응당 파일도 편집도 아닌 그 메뉴에 자리잡고 있다.

프로그램의 전반적인 옵션을 지정하는 명령이 요즘은 도구 메뉴의 맨 마지막에 있는 게 대세이지만, 한때는 preference라는 이름으로 파일 메뉴에 있기도 하고 Adobe Reader처럼 아예 편집 메뉴의 있기도 한 것과 비슷한 모습을 보는 것 같다. 옛날에는 역시 '옵션'이라는 메뉴가 별도로 있기도 했지만 프로퍼티 시트의 등장으로 인해 한 대화상자에서 엄청 많은 옵션들을 죄다 몰아서 지정하는 게 트렌드가 되면서 옵션만을 위한 메뉴는 요즘 UI 트렌드에서는 사라지는 추세이다.

끝으로, 이 검색 메뉴가 존재한다면 그 위치가 어디쯤인지를 살펴보고자 한다. 파일이야 맨 먼저 등장하는 것이 불문율이지만, '보기', '삽입(입력)' 같은 다른 메뉴와 비교했을 때 상대적인 순서가 어떻게 될까?
앞서 말했듯이 찾기 기능은 편집과 밀접한 관계가 있기 때문에 아무래도 편집 메뉴의 바로 다음에 오는 것이 가장 자연스러워 보인다.

그래서 실제로 검색 메뉴가 따로 존재하는 많은 프로그램들은 "파일-편집-검색-(보기)"의 순으로 메뉴가 구성되어 있다. NotePad++, Source Insight, 그리고 도스와 Windows용을 막론하고 볼랜드 IDE (Borland C++, C++Builder, 델파이), AcroEdit 등.

그런데 <날개셋> 편집기는 "파일-편집-보기-검색"으로, View 메뉴가 더 앞에 있다. 검색 메뉴가 처음으로 추가되었던 3.0 초창기 시절에는 "검색-보기"이었는데 나중에 모종의 이유로 인해 "보기-검색"으로 바뀌었다.
"검색-보기"가 적힌 과거의 흔적은 까마득히 먼 옛 버전을 기준으로 만들어진 프로그램 스크린샷 움짤들을 보면 확인할 수 있다.

"보기-검색"으로 순서를 바꾼 이유는 아마 본인이 옛날에 개발 과정에서 참고했던 EditPlus가 "보기-검색" 순이어서 그랬던 것 같다.
그리고 또 흥미로운 것은, 마소에서 만든 도스용 QBasic과 QuickBasic, 그리고 후대 버전인 QBX (MS Basic PDS 7), 도스용 비주얼 베이직 그쪽 라인은 역시 "보기-검색"이다.

사용자 삽입 이미지

그 반면, Windows 95와 그 이후에 새로 등장한 MS-DOS 에디터는 "검색-보기"로 돌아갔다. 대화상자에 선문자가 없는 그 프로그램 말이다.

사용자 삽입 이미지

원론적으로 따졌을 때 "검색-보기"가 더 자연스러우며 그 역순은 EditPlus와 QBasic 계열 같은 예외적인 프로그램에서밖에 존재하지 않는다는 점을 근거로, <날개셋> 편집기도 이번 8.4부터는 다시 "보기-검색"이 아니라 "검색-보기"로 복귀했다.
이 조치를 내리기 위해 저런 리서치와 고민이 있었음을 이 자리에서 밝힌다. ^^

Posted by 사무엘

2016/04/25 19:36 2016/04/25 19:36
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1219

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

Leave a comment

이건 개인적으로 오래 전부터 알고 있었던 사소한 옛날 추억 아이템인데, 지금까지 한 번도 공개적으로 언급한 적이 없었던 관계로 털어놓고자 한다.

Windows에 메모장은 1.0 시절부터 있었던 터줏대감 기본 프로그램이다. 기본 윈도우 프레임 껍데기에다 운영체제의 내장 에디트 컨트롤 하나만 달랑 얹은 극도의 최소주의 형태이다. 세월이 흐르면서 워드패드와 그림판은 리본 UI가 탑재됐고 계산기도 아주 화려한 UI로 리모델링된 마당에, 메모장만은 외형이 거의 바뀐 게 없다.

Windows 프로그래밍 공부를 한 사람이라면 메모장 정도는 하루 정도만 투자하면 동일 프로그램을 직접 만들 수도 있을 것이다. 아니, 있는 그대로 복제품만 만드는 건 너무 시시하고, MDI 정도는 지원하게 확장해서 만들기도 한다. 지금도 있는가 모르겠는데 비주얼 C++의 MFC 예제에는 MultiPad라고 실제로 메모장의 MDI 버전도 소스 코드와 함께 제공된 바 있다.

그런데 Windows 95부터 ME까지 9x 계열의 메모장은 '도움말'이라는 메뉴 명칭의 뒷부분에 출처를 알 수 없는 공백이 하나 더 들어가 있었다. 아래 스크린샷을 참고할 것. 계산기의 '도움말'과는 달리, 메모장의 '도움말'은 파란색이 조금 더 긴 게 보일 것이다.

사용자 삽입 이미지

더욱 신기한 건, 98과 ME로 버전이 올라가도 상황이 바뀐 게 없었다는 점이다. 그것도 한글판과 영문판 공히.
메모장이 아무리 최소주의 기본 프로그램이었다고 해서 그 시절 동안 변화가 전혀 없었느냐 하면 그렇지는 않았다. 보다시피 아이콘 모양이 바뀌었으며 본문의 글꼴을 변경하는 기능이 98에서 추가되었다. 코드뿐만 아니라 리소스 쪽도 검수할 기회가 있었는데 저 문자열의 뒤의 공백은 여전히 제거되지 않은 채 남았다.

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

그 반면, Windows 2000의 메모장은 그렇지 않다.

사용자 삽입 이미지

ME는 2000보다 나중에 나왔음을 감안한다면, 같은 메모장도 NT 계열의 것과 9x 계열의 것은 코드와 리소스가 정말로 한데 공유된 구석이 없었다는 걸 알 수 있다. 같은 소스에서 조건부 컴파일을 한 것조차도 아닌 듯하다.

심지어는 도움말도 둘 다 완전히 다르게 따로 만들어졌다. Windows ME의 메모장 도움말은

Using Notepad to edit text files
You can use Notepad to create or edit text files that do not require formatting and are smaller than 64K (kilobytes).


이라고 사용자에게 당장 필요한 task 지향적인(use, using) 설명 위주인 반면.. Windows 2000의 메모장 도움말은

Notepad overview
Notepad is a basic text editor that you can use to create simple documents.


이라고 프로그램의 정체성에 대해서 더 사무적이고 격식을 차린 문체로 시작한다.

메모장은 아주 단순한 프로그램이지만 9x 계열의 것과 NT 계열의 것이 기능상의 차이도 꽤 크다. 후자는 (1) 유니코드를 지원하며 (2) 64KB 이상 크기의 파일도 열 수 있다. 다시 말해 전자는 "파일이 너무 큽니다. 워드패드에서 여시겠습니까?" 이런 로직이 존재하며, 지금으로서는 상상하기 어렵지만 UTF8 방식 텍스트를 읽고 쓰는 것조차도 지원하지 않았다.

물론 운영체제의 에디트 컨트롤이라는 건 리치 에디트와는 달리 아주 방대한 텍스트를 편집하는 데는 최적화되지 않았던지라 단일 버퍼 기반이라는 한계는 NT 계열도 그대로 갖고 있었다.

또한 NT 계열의 메모장은 BOM이 없는 유니코드 텍스트 파일에 대해서 IsTextUnicode라는 휴리스틱 API를 호출해서 텍스트 파일의 인코딩을 판단했었다. 그런데 그게 좀 버그가 있어서 정상적인 영어 단어로만 이뤄진 짤막한 파일을 UTF16 방식으로 저장된 중국어 한자로 오판하곤 했다. 0x41, 0x42.. 이런 묶음이 코드값상으로는 한중일 통합 한자 내지 확장 A이다 보니.. -_-;;
이 버그는 보안 쪽 문제는 아니지만 그래도 사람을 성가시게 하는 문제인 관계로, 2000이던가 XP 즈음에 패치가 나와서 고쳐졌다.

Windows 9x에는 IsTextUnicode라는 함수 자체가 존재하지 않으니 9x 계열의 메모장이야 저런 문제가 존재할 여지조차 전혀 없었다.
끝으로, 메모장은 아마 Windows XP에서 '상태 표시줄'을 표시하는 옵션이 추가된 게 현재까지 외형상의 마지막 변화 사항이지 싶다. '자동 줄바꿈'을 사용하지 않을 때에 한해서 줄/칸 위치를 표시하는 깨알같은 기능이 추가된 것이다.

이런 Windows와 메모장의 유구한 역사 속에서 도스용 Windows 3.x 내지 NT 3~4의 메모장에는 '불필요한 공백'이 존재했었나 모르겠다.

Posted by 사무엘

2016/04/18 08:33 2016/04/18 08:33
,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1216

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

Leave a comment
« Previous : 1 : 2 : 3 : 4 : 5 : 6 : ... 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:
973169
Today:
6
Yesterday:
524