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

1. 나랏말씀

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

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

사용자 삽입 이미지

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

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

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

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

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

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

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

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

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

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

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

2. 신의손

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

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

사용자 삽입 이미지

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

사용자 삽입 이미지

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

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

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

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

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

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

Posted by 사무엘

2017/07/27 08:38 2017/07/27 08:38
, , ,
Response
No Trackback , 4 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1386

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

Comments List

  1. nyam 2017/07/27 13:36 # M/D Reply Permalink

    항상 공감 가고 완성도 있는 글 감사히 잘 보고 있습니다.
    이 글을 보고 제가 지금까지 '아니요' 대신 '아니오'로 잘못 써오고 있었다는 사실을 깨달았습니다..

    감사합니다.

    1. 사무엘 2017/07/27 15:43 # M/D Permalink

      앗, nyam 님! 오랜만에 뵙습니다. 잘 지내시죠?
      이곳을 꾸준히 방문하고 글들을 구독해 주셔서 고맙습니다. ^^
      ‘아니요’는 저 역시 오랫동안 잘못 알고 있었던 사항입니다.

  2. 경헌 2017/07/27 18:03 # M/D Reply Permalink

    아아 신의손 제작자님이 어썸노트 제작자님 이었군요..

    역시 뛰어난 개발자는 플랫폼을 초월합니다 ㅎㅎ

    1. 사무엘 2017/07/27 20:17 # M/D Permalink

      네, 놀랍죠? 그저 대단하고 부러울 뿐입니다. ^^

Leave a comment

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

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

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

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

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

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

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

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

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

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

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

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

2. 설치 시스템 개편

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Posted by 사무엘

2017/05/01 08:30 2017/05/01 08:30
, ,
Response
No Trackback , 4 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1355

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

Comments List

  1. kippler 2017/05/03 13:30 # M/D Reply Permalink

    오늘도 재미있는 글 잘 봤습니다. ^^
    몇가지 사족을 달자면,

    GetUserDefaultLangID() 사용자 언어 설정 값을 가져오고, GetSystemDefaultLangID() 는 시스템 언어 설정을 가져옵니다만, 실제로 NSIS 는 GetUserDefaultUILanguage()를 사용하고 있습니다.
    생각난 김에 테스트 해 보았는데, 사용자 입장에서 각각의 값을 바꾸고 방법이 조금씩 다 다르네요.

    인스톨러 만들 때 Win9x 지원은 쉽지 않은 문제로 보이네요. 일단 MBCS로 프로그램을 짜면, 언어 선택 화면에 각각의 언어로 언어 선택을 보여주기도 힘들고, 한국어 OS 사용자가 일본어를 선택하면 일본어가 깨지는 등의 문제가 발생하기 때문에 이 부분은 해결이 쉽지 않아 보입니다.

    그리고 언급하신 것처럼 NSIS 플러그인 사용할 때 32/64 비트 플러그인 DLL 호출이 자유롭지 못하기 때문에, 작은 외부 exe를 만들어서 플러그인에서 exe 를 호출하는 방식을 종종 사용했는데, 문제가 요즘 AV 프로그램의 휴리스틱엔 진은 덩치 작은 EXE를 너무 심하게 의심하더군요. 간단한 유틸 EXE를 만들어서 설치할 때 호출하는 방식을 선호했는데 나중에 이 문제가 너무 심해서 포기하고 말았습니다.

    1. 사무엘 2017/05/03 14:11 # M/D Permalink

      소환에 응해 주셔서 대단히 고맙습니다. ^_^

      1. 저도 그럼 System 대신에 User을 쓰는 게 낫겠네요. 어쩐지 외국인 중에서 편집기의 대화상자 UI가 한국어로 나오는 걸 문의하는 경우가 종종 있었는데, User는 영어이지만 System이 한국어여서 그런 것 같습니다.

      2. 당연히 Win9x 지원한다고 해서 프로그램 기반을 MBCS로 만들지는 않습니다. NT 계열에서는 원래 지원되는 언어 선택 ui가 모두 나오고, 9x에서는 영어 아니면 해당 운영체제 언어(영어가 아닌 경우) 둘 중 하나만 고를 수 있겠지요.

      3. 헐.. AV 휴리스틱 문제도 있는지는 몰랐네요. 디지털 서명 해도 막무가내로 의심하는가 봅니다.
      하긴, installer가 설치/제거 중에 잠깐 압축 풀어서 실행만 하고, 실제로 사용자의 컴에 설치는 안 되는 용도의 임시 EXE/DLL 및 데이터 같은 개념도 installer 엔진이 정식 지원해야 할 것 같습니다. feature list에 하나 추가입니다. ^^

  2. kippler 2017/05/04 12:07 # M/D Reply Permalink

    헐... 그냥 인스톨러 이야기 인줄 알았는데, 댓글 보니 인스톨러 만드시나 보네요. 응원합니다. ^^

    1. 네, 이 부분은 GetUserDefaultUILanguage() 가 제일 정확한듯 합니다. 저도 어제 궁금해서 여러가지 테스트를 해 봤는데, 영문 OS에 캐나다 언어팩을 설정하면 아래처럼 리턴값이 나옵니다. 한국, 일본, 중국 정도는 1:1 매치가 되어서 딱히 문제가 없는데, 스페인어처럼 다양한 국가에서 쓰이는 언어인 경우 GetUserDefaultUILanguage()를 써야 그나마 복잡도가 덜해 지더군요.
    GetSystemDefaultLangID () 1033 0x409 English ENGLISH_US
    GetUserDefaultLangID() 4105 0x1009 English ENGLISH_CAN
    GetUserDefaultUILanguage() 2057 0x809 English ENGLISH_UK

    2. 생각해보니 W계열 함수가 98에서도 다 작동했던 것 같기도 하고… 오랜만이라 기억이 가물 가물 하네요. (생각해 보니 작동을 하기는 하는데 내부에서 MBCS 로 다시 바꿔서 작동하기 때문에 일부 함수는 버그가 있었던 것 같기도 하고…) ㅎㅎ 어쨌거나 이거 다 고려하면 정말 쉽지 않은 작업이네요.

    1. 사무엘 2017/05/04 21:40 # M/D Permalink

      1. 아, "인스톨러를 만약 직접 만든다면 아무리 그래도 그렇지 MBCS를 쓰지는 않을 거다"라는 뜻이었습니다. 실제로 직접 만든다는 얘기는 아니고요. 그러기에는 제가 시간과 여유가 부족합니다. ^_^

      2. 네, 저도 관련 함수들을 검색하면서 그걸 알게 돼서 호출하는 함수를 교체했습니다.

      3. 9x 계열에서 W 계열 함수를 지원하는 건 MessageBoxW, TextOutW, GetTextExtentPoint32W처럼 최소한의 에러 메시지 출력 내지 글자를 찍고 픽셀 크기 측정하는 기본 함수 정도가 전부입니다. 아, 95 말고 98부터는 imm32 관련 함수들도 예외적으로 W를 지원하기 시작했고요. 물론 MessageBoxW는 내부적으로 문자열 변환 후 A를 호출하는 형태입니다.
      그러니 9x 시절에는 일반적인 함수들은 A를 써야 하는데 COM 내지 IME 관련 함수들과는 유니코드 문자열을 주고받으니 그게 또 프로그래밍을 골치 아프게 하는 요인이었습니다.

Leave a comment

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

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
« Previous : 1 : 2 : 3 : 4 : 5 : 6 : ... 10 : Next »

블로그 이미지

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

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2018/12   »
            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 31          

Site Stats

Total hits:
1074572
Today:
180
Yesterday:
713