« Previous : 1 : 2 : 3 : 4 : 5 : ... 12 : Next »

1. open이라는 타이틀이 붙은 유명 라이브러리들

  • OpenGL: 3차원 그래픽. (DirectX만이 직접적인 경쟁자로 남아 있는 듯..)
  • OpenCV: 2차원 래스터 그래픽에서의 영상 처리. 뽀샵질 보정, 사물 윤곽 인식 따위
  • OpenMP: 병렬처리 프로그래밍. 단순히 함수· 클래스만 제공하는 게 아니라 프로그래밍 언어 자체의 확장까지 수반한다.
  • OpenSSL: 각종 보안/암호 키 교환 프로토콜 구현, 해시· 암호화 함수들과 제반 연산 기능(큰 정수) 컬렉션

또 뭐가 있을까?
얘들은 각자 자기 분야에서 유구한 역사와 압도적인 인지도를 자랑하는 데다, 엄청 방대한 기능들을 무료로 덥석 제공한다. 다양한 언어와 플랫폼을 지원할 뿐만 아니라 최신 알고리즘이 수시로 반영되어 추가되고, 최신 하드웨어의 명령어에 맞게 최적화와 검증도 잘 돼 있다. 그야말로 더 바랄 게 없는 상태이다.

그렇기 때문에 개인적으로 내부 동작 원리를 공부를 하는 게 아닌 이상, 누군가가 현업에서 저런 기능들을 굳이 처음부터 다시 구현할 필요는 없다. 방대한 라이브러리의 사용법을 익혀야 한다는 최소한의 부담만이 있을 뿐.

유닉스에 대해서 누가 말했던가..? "유닉스를 쓸 줄 모르는 사람은(grep 등의 각종 명령어와 유틸리티, 정규 표현식 따위..), 유닉스가 제공하는 기능을 결국은 스스로 직접 또 만들게 될 것이다"라고..;; (reinvent the wheel) 그런 것처럼 말이다.

다만, Open이라는 단어가 붙었고 사용이 무료라고 해서 반드시 오픈소스이기까지 하지는 않은 것 같다. 가령, OpenGL이 오픈소스이고 git 저장소가 있다는 얘기는 난 못 들었다.
그리고 폰트 렌더링 분야의 본좌 라이브러리는 이름이 FreeType이다. OpenType은 라이브러리가 아니라 폰트 파일 포맷 규격의 명칭이다.

지금 국내의 오픈소스 진영엔 libhangul이라고 한글 입력 오토마타를 구현해 놓은 라이브러리가 있고 그걸 유수의 공개 한글 IME들이 사용하고 있다. 얘들은 초창기에 이름이 '열린 한글 프로젝트'였던 것 같은데 지금도 그러한지 궁금하다.

한때 '열린 한글'은 1990년대 말에 아래아한글이 개발 중단 위기에 처했을 때 "우리 다같이 힘을 합쳐서 아래아한글의 클론을 오픈소스 형태로 밑바닥부터 만들어 봅시다~!!" 이런 프로젝트의 명칭으로 쓰이기도 했었다..;; 거의 IMF 금 모으기 운동 같은 발상이었다.

이제는 마소에서 개발한 제품조차도 about이나 acknowledgement 화면에.. 제품 내부에 사용된 각종 오픈소스 프로젝트들 목록이 뜨는 날이 올 것 같은데... 격세지감이다. (하지만 나는.. 정작 내 한글 입력기부터가 오픈소스가 아니며 기존 오픈소스를 사용하는 것도 전혀 없다..;; )

2. GWBASIC 소스 공개!!

작년에는 마소에서 GWBASIC의 원본 소스 코드를 공개했다. 오오 +_+ (☞ 링크)
마소에서는 진작부터 MS-DOS와 Word의 옛날 초창기 버전의 소스를 공개한 바 있다. 하지만 그것들은 본인이 직접 써 본 기억이 없는 너무 옛날 버전이어서 그다지 감흥이나 공감이 없다.

그에 비해 GWBASIC은 본인의 어린 시절의 경험이 잔뜩 깃든 물건이고, 프로그램을 만들어 돌리는 프로그램이다 보니 접하는 느낌이 다른 제품들의 소스와는 사뭇 다르다.

  • Syntax error, Missing operand, Illegal function call, FOR Without NEXT (한글판은 "문법이 틀렸읍니다, 피연산자가 없읍니다, 기능호출 사용이 잘못되었읍니다" 등등..) 같은 친숙한 에러 메시지 문자열들은 GWDATA.ASM에 있다. 전설적인 Ok 프롬프트 값도 저기에 정의돼 있다.
  • 그래픽 모드에서 이차차분 알고리즘으로 원을 그리는 함수, 재귀호출로 flood fill을 수행하는(PAINT 문) 함수는 ADVGRP.ASM에 구현돼 있다.
  • MOTOR문은 하는 일 없이 에러만 내뱉는 것 같았는데, GIOCAS.ASM을 보니 실제로도 그러하다. 저건 카세트 테이프의 잔재일 뿐, 16비트 PC용인 GWBASIC에서는 하는 일이 원래 없다.

  • F1에 LIST부터 시작해 TRON, TROFF, KEY, SCREEN 0,0,0을 기본 배당하는 테이블은 GWRAM.ASM에 있고..
    Alt+A에 AUTO부터 시작해 BSAVE, COLOR, ... 등을 배당하는 테이블은 IBMRES.ASM에 있다.
  • 소스를 저장할 때 SAVE에다가 P 옵션을 줘서 어설프게 암호화 프로텍션을 거는 부분은 GIODSK.ASM, DISKCOM.ASM을 참고하면 될 듯하다.
    암호화된 파일과 그렇지 않은 파일이 첫 바이트 0xFE 또는 0xFF로 구분된다는 것을 확인 가능하다.
  • PLAY문에서 A~G 등 각종 문자열들을 해석하는 부분은 GWSTS.ASM을 보라. "MUSIC MACRO LANGUAGE"라고 주석이 돼 있다.

  • 부동소수점 연산?? 요즘처럼 전용 CPU 명령어 한 방으로 끝나는 시절이 아니었으니 전부 자체 구현이다.
    빌 게이츠가 왕년에 직접 고안했다는 MBF 부동소수점의 구현부가 바로 MATH1/2.ASM에 있다. 삼각함수, 로그도 내부적으로 테이블을 내장해서 소프트웨어적으로 직접 계산한다.
  • 난수를 생성하는 RND 함수의 공식은 MATH1/2.ASM에 있다. 그 유명한 Donald Knuth 아재의 책을 참고해서 구현했다고 주석에 적혀 있다.

아아.. 옛날 추억이 새록새록~~~
어셈블리어 코드를 읽을 수 있다면 흥미로운 유물들이 넘쳐날 것이며 아는 만큼 보일 것이다. 내가 읽을 수 있다는 뜻은 아님..;;
GWBASIC은 아무래도 정상적인 소프트웨어 개발 도구와는 좀 동떨어진 구석이 있지만, 그 옛날에 대화식 프로그래밍 환경이라는 걸 만들 생각을 한 건 충분히 참신하다고 볼 수 있다.

2000년대 이후에 태어난 뉴비 프로그래머들을 위해서 FAQ를 아주 자상하게 써 놨다. 이런 질문의 답변까지..;;

  • 아니, 오픈소스라면서 확장자가 C/CPP인 파일이 왜 하나도 안 보이나요?
  • C 파스칼 놔두고 왜 이렇게 알아보기 어려운 언어로 코딩을 했나요?

저 때는 고급 언어 컴파일러들이 엄청나게 비쌌고, 생성하는 코드의 성능이 좋지 못했다.
빌 게이츠와 그 일당들은 20대 나이 때, 지금보다 컴퓨터가 훨씬 더 열악하고 비싼 기계이던 시절에 여느 평범한 프로그램이 아니라 딴 프로그램을 만들고 돌리는 가상 머신급의 프로그램을 한땀 한땀 어셈블리어로 코딩해서 돌리고 납품하고 팔아먹었다는 거다.
그리고 한 언어의 인터프리터로서의 기능이 다 들어있던 GWBASIC.EXE의 크기는 실행 파일 압축 따위 없이도 겨우 6만 바이트 남짓밖에 안 했다는 거다.

이건 16비트 x86이 다른 CPU 아키텍처와 비교해 봐도 명령어 배치가 이례적으로 굉장히 조밀하기도 했기 때문에 가능한 일이다. 메모리 아끼기 위한 CISC 방식의 승리인 셈이다.

Posted by 사무엘

2021/07/27 19:36 2021/07/27 19:36
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1914

1. 90년대 중반의 제품 데모: 3D Studio R3, Windows 95

인터넷이란 게 없던(= 가정용으로 널리 보급되지 않은) 시절에 컴퓨터로 바깥의 최신 문물을 접하는 방법은 기껏해야 PC 통신, 아니면 컴퓨터 잡지와 함께 배포되던 부록 CD였다.
그런데 모뎀으로 접속하던 PC 통신은 접속 시간에 비례해서 부과되는 전화비의 압박이 심했으며, 전송 속도도 지금의 인터넷 전용선과는 비교조차 할 수 없을 정도로 느렸다. 그렇기 때문에 수십~수백 MB 이상의 대용량 자료를 배포하는 수단으로는 CD 같은 물리적인 매체가 여전히 의미가 있었다.

PC 통신 자료실이건, 잡지 부록 CD건, 이런 매체에는 유명 소프트웨어의 무료 체험판과 데모가 많이 포함돼 있었다. 유료로 판매되는 제품에서 일부 기능만 사용할 수 있거나 사용 기간이 제한된 것 말이다. 아니면 애초에 사용자가 조작해 볼 수 있는 기능은 없고 파워포인트 프레젠테이션처럼 일방적인 기능 소개와 화면 시연만 들어있는 데모 프로그램도 있었다.

그 중 본인이 인상깊게 봤던 것은 3D Studio R3.. 3DS에 MAX라는 이름이 붙기도 전, 게다가 도스용이 존재하던 시절 버전의 데모이다. 이거 화면을 유튜브에서 다시 보는 날이 오게 될 줄은 몰랐다. 정말 유튜브에 별별 것들이 다 올라온다..;; (☞ 링크)

요즘 같으면 파워포인트.. 하다못해 플래시로도 만들 수 있을 것 같은데.. 몇몇 화면 전환이나 프로그램 실제 화면 애니메이션 같은 건 난이도의 압박이 있을 것 같다.
1994년에는 아직 플래시도 없었기 때문에 도스에서 exe 형태로 저런 프레젠테이션 데모만 제작하는 전문 업체가 있었던 모양이다.

그리고 다음으로 소개하고 싶은 것은.. 국내에서 제작됐던 Windows 95의 데모 겸 기초 기능 튜토리얼이다. 95~96년 사이에 이거 보신 분 계신가..?? (☞ 링크)

"윈도우즈 구십오", "엠에스 더~스" 라고 또박또박 말하는 여성 나레이터 목소리가 찰지게 느껴진다.;;
도스와 Windows 3.1의 타성에 젖어 있던 사람들한테 시작 메뉴와 바탕 화면, 탐색기, 단축 아이콘(현재 명칭은 '바로가기') 개념을 처음으로 가르치고 홍보하느라 마소에서 그 당시에 돈 엄청 많이 쓰긴 했다.

이 데모 프로그램은 Windows 95 한글판의 CD에 포함된 프로그램은 아니었는데 어느 경로로 유포되었는지 궁금하다. 그냥 PC 통신이나 잡지 부록 CD였는지..?

2. 게임 데모

예전에도 한번 언급한 적이 있지 싶은데.. 과거에 스티브 잡스는 소수의 추종자 매니아를 양성하는 식으로 제품을 판매한 반면, 빌 게이츠는 정말 통 크게 남녀노소 가릴 것 없이 전세계에 컴퓨터를 보급해서 세계인들의 생활을 확 바꿔 놓고, 그 컴퓨터라는 기계에 우리 회사의 운영체제를 몽땅 뿌려 버리겠다는 심보로 장사를 했다.

그래서 Windows 95에서 드디어 32비트로 체제를 바꾸기도 했으니.. 얘를 본격적으로 게임용 홈 엔터테인먼트 플랫폼으로 만드는 일에 가히 사운을 걸었다. 그래서 거의 곧장 DirectX를 만들었으며, 특히 세계적인 히트를 치고 있던 Doom 2 게임 정말 0순위로 Windows용으로 포팅을 지원해 줬다.

PC에서, 그것도 DOS가 아닌 Windows에서 텍스처 매핑이 적용된 실시간 3D 게임이 돌아간다는 건 굉장히 획기적인 일이었다. Windows는 그저 지뢰찾기나 카드 게임 같은 가벼운 게임만 하는 플랫폼이라는 고정관념이 드디어 깨지기 시작했다.

애초에 Windows 95 원본 CD에는 Hover!이라고.. 범퍼카를 몰고 맵을 돌아다니며 깃발을 상대방보다 먼저 뺏는 게임이 있었다. 마소가 게임 전문 개발 업체는 아니지만, 이건 외주가 아니라 마소에서 직접 개발했던 듯하다.

사용자 삽입 이미지

얘는 비록 세계적인 명작인 Doom만치 막 박진감 넘치는 요소까지는 없지만, 그래도 그래픽은 Doom과 비슷한 수준이었다. 그리고 초보적이나마 1층 공간 위에 2층이 구현돼 있기도 했다는 점에서 Doom 엔진과 결정적인 차이가 있었다.

그리고 내 기억이 맞다면 Windows 95와 거의 동시에 Fury라고.. Hover의 공중 버전 내지 윙 커맨더의 축소판 같아 보이는 게임도 개발돼 나왔다. 얘는 외부 개발사와 합작 내지 외주 형태로 개발됐고 Windows 95에 포함돼 있지는 않았다.

사용자 삽입 이미지

게임 진행은.. 뭐 공중을 날아다니면서 총 쏘고 부수는 것 정도만 기억에 남아 있다.
마소는 Fury니, Hover!이니 하는 아기자기한 게임들을 같이 내놓으면서 우리 Windows 95는 저런 화려한 3D 그래픽이 가능한 게임용 플랫폼이라는 걸 기를 쓰고 내세웠던 듯하다.

그러고 보니 Win95의 발매 직후에는 DirectX라는 것도 아직 완전 듣보잡이거나, 버전이 2~3 이러던 시절이었을 텐데.. 3D 그래픽 가속이라는 건 퀘이크도 나오고 최소한 96~97년, Voodoo니 뭐니 하던 게 나온 시절부터 주목 받았을 텐데 저런 게임들은 CPU빨만으로 3D 그래픽 애니메이션을 구현했던 건지 궁금해진다.

끝으로, 비록 저렇게 1인칭 3D는 아니지만 3D 핀볼이라는 유명한 번들 게임도 있었다. 얘는 나름 Windows 3.1 + win32s에서도 돌아갔던 까마득한 옛날 프로그램이다.
마소에서 외부 업체로부터 소스 코드를 구입해서 자사 제품에다 포함시켰는데.. the old new thing 블로그에서의 회고에 따르면 코드가 주석 한 줄 없이 도저히 유지보수 가능한 상태가 아니었다고 한다.

훗날 Windows가 32비트에 이어 64비트로 갈아탈 때가 임박했는데, 얘는 내부적으로 오프셋 계산에 문제가 있었는지 64비트에서는 제대로 동작하지 않았다. 그런데 문제의 원인이 무엇이고 어디를 고쳐야 할지를 알 길이 없었고, 그렇다고 얘는 오픈소스화가 가능한 물건도 아니다 보니 64비트에서는 핀볼이 결국 짤리게 되었다.
그 외부 업체가 코드를 컴파일만 가능하고 유지 보수는 도저히 가능하지 않은 형태로 일부러 변조해서 줬던 것 같다.

3. 왓콤 win386

1990년대에 왓콤(Watcom)이라는 컴파일러 제조사는 PC의 도스 환경에서 32비트 프로그램의 개발 환경을 시세 대비 매우 저렴하게 제공한 일등공신으로 칭송받았다.

그 시절에는 아직 386/486급 PC의 가격도 아주 비쌌고, 32비트 코드 생성을 지원하는 컴파일러도 비쌌고, 특히 도스에서 이런 프로그램을 돌아가게 해 주는 DOS Extender도 아주 고가였다. 그런데 왓콤은 32비트 컴파일러와 무료 번들용 DOS extender까지 아주 파격적인 가격에 보급했던 것이다. 그러니 아주 전문적인 대형 고급 소프트웨어를 개발하는 분야에서 수요와 고객을 확보할 수 있었다. 볼랜드나 마소 같은 주류 컴파일러 제조사들은 그저 16비트에 안주하고 있었기 때문이다.

그런데 왓콤의 무서운 면모는 도스용 32비트 개발툴만 만든 게 아니었다는 점이다. 1990년대 초, 아직 Windows NT 3.1이 정식으로 나오기도 전에 멀쩡한 Windows 3.0/3.1를 마개조해서 32비트 코드를 구동해 주는 win386 Extender를 개발했다~! 그리고 이 시스템을 기반으로 돌아가는 32비트 코드를 생성하는 Windows 타겟용 컴파일러를 덤으로 보급했다. 기존의 16비트짜리 도스/Windows API를 호출할 때는 물론 입출력값을 변환할 테고 말이다. (☞ 더 자세한 소개)

이게 내부적으로 어떤 원리로 동작했는지는 잘 모르겠다. 오늘날의 Windows NT처럼 PE 포맷을 사용하지도 않았을 텐데..
하긴, 16비트 시절에는 Windows용 한글 바이오스(한메한글~!!)도 있었으니, 뭔가 시스템 내부를 마개조하기가 더 쉬웠던 것 같다.
당장 마소에서 옛날에 개발했던 FoxPro 2.5~2.6이 왓콤 win386을 기반으로 개발됐다고 한다.

그로부터 몇 년 뒤에 마소 본가에서 Windows NT를 출시해서 32비트 Windows API가 제대로 정립되고, 32비트용 Visual C++ 1.0과 win32s 같은 게 줄줄이 나오면서 왓콤 win386의 시대는 막을 내리게 됐다.
Windows의 32비트화 내력을 요약하면 다음과 같다.

  • real 모드: 1.0~3.0 (1985~1990) 사실상 640KB 기본 메모리밖에 사용하지 못하는 초 열악 모드.
  • 286 standard: 2.0~3.1 (1987~1993) real보다는 나은 것 같지만 정확하게 언제 처음으로 등장했고 차이점이 뭔지 존재감이 매우 없음.
  • 386 enhanced: 3.0~ (1990~??) 아직 32비트 코드를 시행하는 건 아니지만 도스창을 완전히 가상화할 수 있고 확장 메모리를 더 사용 가능함.
  • Win32s: 3.1 (1992~1996) 딱 32비트 코드 실행만 가능한 최소한의 모드
  • Windows 9x: 95~ME (1995~2000) 프로세스 별 주소 공간이 독립하고, 멀티스레드가 가능해짐
  • Windows NT: 3.1~10 (1993~현재) 유니코드 기반, 온전한 메모리 보호, 16비트 코드의 완전 가상화까지 실현

사실 386 enhanced mode라는 건 Windows 3.0 이전에 2.x의 386 에디션에서 최초로 도입되긴 했다. 하지만 이건 마치 Windows XP의 x64 에디션만큼이나 존재감이 없다.

4. 오 성식 생활 영어 SOS

우와~~ 이거 정말.. 추억의 멀티미디어 CD 타이틀이었다. (☞ 링크)
그 시절에 ToolBook이라고 CBT 멀티미디어 교육용 소프트웨어 저작도구가 있었는데..
쟤도 바로 툴북을 기반으로 만들어졌었다.
컴터에서 avi 허접 동영상이 재생된다는 것만으로도 왕창 신기하던 시절에 나왔던 물건이다.
저 타이틀에서는 도움말 나레이션만 낭독한 이 보영 씨 역시 현재까지 현역으로 뛰고 있는 유명 영어 강사이다.

그 뒤 저런 멀티미디어 컨텐츠를 만드는 플랫폼은 플래시로 넘어갔다가..
요즘은 플래시를 쓸 필요도 없이 저런 건 그냥 웹에서 HTML5 자바스크립트만으로 다 처리 가능하게 된 지 오래다.

쟤는 프로그램을 바로 종료하려 하면.. "공부라는 건 최소한 50분은 넘게 집중해서 해야 효과가 납니다. 그래도 지금 바로 종료하시겠습니까..."라는 확인 질문이 떴다. 내가 태어나서 지금까지 접했던 소프트웨어들 중 가장 훈계조로 종료를 저지하는 물건이었다.
반대로 Doom 2 게임은 온갖 농담 조크를 날리면서 종료를 저지했던 프로그램이고..

인트로 화면 보소..
딱 미리내 소프트웨어 "그 날이 오면 3" 게임의 인트로와 비슷한 환상적이고 몽환적인 느낌이 들지 않는가..??

레 솔솔 라 레레 솔 라시 레 시라솔 라~~
25년 가까이 지난 지금도 나는 멜로디를 정~확하게 녹음기로 틀어 놓은 듯이 기억하고 있다. 초딩 나이로 워낙 환상적인 경험이어서...

Credits를 보니.. 요 아름다운 인트로 음악을 작곡한 사람이 이 영수 교수(1951-2018. 영남 대학교 음대 작곡과)였다고 나온다.
어머니의 마음 "낳실제 괴로움 다 잊으시고..."의 멜로디를 만든 작곡가 이 흥렬의 아들이다.

Posted by 사무엘

2021/06/10 08:36 2021/06/10 08:36
, ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1897

2021년이 된 와중에 문득 생각을 해 보니.. Windows 8과 8.1은 정말 존재감 없이 소리소문 없이 싹 묻히고 사라진 것 같다.
XP, 7 다음에 바로 10이다. 8 계열은 20년 전의 ME만치 망한 건 아니지만 Vista보다는 더 흑역사이다.

사실 난 개인적으로는 옛날에 XP 다음의 Vista는 그 정도로 욕 먹을 퀄리티는 아니었으며, 일부는 오해와 누명을 쓴 것도 있다고 생각한다. 5년 만에 출시됐다 보니 갑자기 시스템 요구 사항이 너무 높아지고 일부 하드웨어와 호환이 깨지고, 사용자 계정 컨트롤이 도입된 게 반발을 일으켰을 뿐.. 그건 시간이 해결해 줄 수 있고 사후 재평가의 여지가 있는 이질감이었다. 7이라도 XP 다음에 바로 갑툭튀였다면 맞았을 질타를 미리 맞아 준 것의 비중이 크다.

그럼 8 계열은 사정이 어땠을까? 잠시 10여 년 전 당시 상황으로 되돌아가 보자.
이때는 나름 격변기였다. 아이폰이니 안드로이드니 하면서 본격적으로 스마트폰이라는 새로운 컴퓨팅 생태계가 조성되고 있었으며, 마소에서도 초대 원로 경영진(빌 게이츠, 스티브 발머)이 대거 은퇴하고 세대가 교체되고 있었다. 사내 분위기가 크게 요동칠 수밖에 없었을 것이다.

이 와중에 얼리어답터들은 “Windows가 7 이후로 2010년대엔 도대체 어디까지 변모할까? 마소는 이 시점에서 어떤 결정을 내릴 것이며 PC와 모바일과의 접목은 어떻게 이룰까?”라고 기대와 주목을 잔뜩 하고 있었다. 그때는 다음 버전이 심지어 재래식 NT 커널을 버리고 처음부터 다시 개발된다는 루머까지 나돌았다. (실제로는 그럴 리가.. NT 커널은 지금 Windows 10에서도 건재함! 없어질 수가 없다)

그랬는데.. Windows 7의 차기 버전인 8은 결과적으로 뭔가 구심점 없고 나사 빠진 듯한 망작이 되었다.
비주얼이 다시 심플해진 것은 그렇다 친다만, 갑자기 시작 메뉴가 없어지고 전체 화면으로 바뀐 것은.. PC와 스마트폰의 크기와 용도의 차이에 대한 고찰이 결여된 자충수였다. 게다가 8은 시작 메뉴 버튼 자체가 없었다~! 이런 제품이 어째 QA나 사용성 테스트를 통과하고 출시됐는지 모르겠다.

더 옛날인 2000년대엔 새 밀레니엄 컴퓨팅을 표방하면서 인텔 Itanium이라는 64비트 프로세서가 출시되었고 Windows는 2000뿐만 아니라 ME도 나왔었는데.. 아시다시피 Itanium과 ME는 대차게 망했다. 그런 것처럼 2010년대를 개막했던 Windows 8은 사용성 면에서 큰 혹평을 받으면서 XP와 7의 아성을 넘지 못했다.

그리고 사실은 스마트폰 OS의 쟁탈전도 매우 싱겁게 끝났다. 지금 다들 경험하시는 바와 같이 안드로이드 아니면 iOS로 양분되었고, 마소는 이 바닥에서의 주도권을 완전히 빼앗겼다. 심지어 웹 브라우저마저 IE 독점은 진작에 물 건너갔고 Edge 브라우저도 자체 개발을 포기하고 크로뮴 엔진에 흡수되지 않았는가?
국내로 치면 모바일에서 주도권을 완전히 주도권을 빼앗기고 삼성 전자와는 정반대의 처지가 된 LG 전자와 비슷하다고 하겠다..;

그러니 8 시절부터 Windows에 도입된 Metro 앱이니 하는 것 역시 폰에서는 볼 일이 없어졌다. Universal이라는 수식어가 무색해졌고 지금은 그냥 스마트폰 같은 큼직한 글자의 UI 엔진이 제공되는 특이한 프로그래밍 플랫폼? 가상 머신?처럼 됐을 뿐이다. NT 커널 없이 새로 개발된다는 엔진이 이런 곳에 적용된 거라고 보면 되겠다.

그렇게 결판이 난 뒤 마소에서는 스마트폰용 OS가 아니라 그냥 기존의 데스크톱용 Windows 10을 스마트폰용 CPU인 ARM64에다가 포팅하는 식으로.. 즉, 자기 정체성을 유지하면서 모바일 환경에다 손을 내민 상태이다. 요즘 PC와 스마트폰의 경계가 많이 모호해지긴 했지만 그래도 PC는 안 쓸 때도 24시간 내내 켜 놓는 물건은 아니며, 떨어뜨려도 될 정도로 튼튼한 물건도 아니라고 여겨진다. 그리고 스마트폰은 프린터나 재래식 하드디스크 같은 장치와는 여전히 친숙하지 않다.

그렇게 Windows 8 내지 8.1은 2010년대 초반 마소의 시행착오가 깃들어 있는 비운의 작품이 됐다.
개인적으로는 Windows 제어판이 Metro 기반인 ‘설정’으로 야금야금 대체된 건 글쎄.. 그냥 reinvent the wheel 삽질 같고 멀쩡한 인도 보도블록을 교체하는 듯한 느낌이다. 기존 제어판에 익숙한 사용자를 괜히 헷갈리게만 하고 말이다.
지금도 키보드의 반복 속도를 최대로 조절하는 것만 해도 설정에서 가능하지 않기 때문에 재래식 제어판으로 가야 한다.

그리고 프로그램의 제목 표시줄에 제목이 가운데 정렬로 표시되었던 Windows는 과거의 16비트 시절 1~3.x 아니면 후대의 8/8.1밖에 없다~!! 거기 말고는 MS Office가 뜬금없이 2007부터 현재까지 가운데 정렬을 하며 따로 노는 중이다.

나머지 Windows 95, NT4부터 7, 그리고 지금의 Windows 10은 다 왼쪽 정렬이다.
Windows의 역사상 32/64비트 시대에 프로그램 제목을 가운데에다 표시했던 버전, 그리고 시작 버튼이 없던 버전이 있었다는 걸 기억하는 사람이 얼마나 있을까? 문득 궁금해진다.

한글 IME의 개발이라는 관점에서 보면 Windows 8 계열은 메트로 앱에 대해서는 키보드 포커스를 얻었을 때 가/A 한영 상태를 IME가 근처에다 팝업 창으로 수동으로 잠깐 띄워주고, 상태가 바뀌었을 때도 그걸 띄우는 수고를 해 줘야 하는.. 약간 원시적인 조치가 필요하던 유일한 운영체제였다.
메트로 앱은 전체 화면에서 실행되는 관계로, 운영체제의 기존 도구모음줄(language bar)의 보조를 전혀 받을 수 없기 때문이다.

이것도 아무리 생각해 봐도 뻘짓이었다. 도구모음줄을 IME가 제각각으로 구현해야 했던 1990년대도 아니고.. Windows 10부터는 메트로 앱도 창 모드로 실행 가능하고, 입력기의 상태를 작업 표시줄(task bar)에서 확인 가능하기 때문에 저렇게 할 필요가 없어졌다. 즉, 저 관행 역시 일회적인 이벤트로 끝났다는 것이다.

이상. 이 글에서는 Windows 8 계열에 대해 주로 다뤘지만, 걔네 말고 Windows라는 운영체제 제품에 대해서 개인적으로 의아하거나 궁금한 점을 더 꼽자면 다음과 같다.

1. 비현실적인 권장 사양

마소에서는 Windows 7 64비트 정도의 시점을 마지막으로.. 자기 운영체제의 동작을 위한 최소 PC 사양과 권장 사양을 더 올려서 기재하지 않고 있다.
7이 램 최소 1GB 이상, 권장 2GB 이상인데.. 이게 Windows 8과 10까지 동일하다. 하지만 이건 개인적으로 생각하기에 완벽한 허위· 과장 광고라고 여겨진다.

도대체 어느 정도 돌아가는 게 최소 사양이고 어느 정도로 여유가 남는 게 권장인지 정확한 정의는 잘 모르겠다만.. 요즘 Windows 10은 램 8GB에서 돌려도 부팅 직후에 크롬 브라우저 창 몇 개나 MS Office 프로그램, Visual Studio 같은 걸 열면 메모리가 거덜난다. 정말 못 해도 16GB는 돼야 넉넉하다는 느낌이 든다.

Windows 7에서야 최소 1GB, 권장 2GB는 수긍할 만하며 램 8GB는 펄펄 날아다니는 용량이다. 하지만 10은 절대 그렇지 않다. 아무리 못 해도 최소 2, 권장 4 이상으로는 수정돼야 하리라 여겨진다. 그리고 요즘도 32비트 에디션이 나오고 있나 모르겠는데.. 걔는 이제 단종시켜도 될 것이다.

2. 서버 제품군의 존재감

Windows의 개인 사용자용 제품군은 아시다시피 2015년부터 10이라는 단일 브랜드 하에서 주기적인 업데이트를 통해 프로그램을 진화(?)시키는 형태로 바뀌었다. 하지만 서버 제품군은 여전히 2008, 2012, 2016 등의 연도 브랜드를 쓰고 있어서 다소 이질적이다. 이런 이원화된 버전 넘버링이 언제까지 계속될지.. 마치 Office 365와 기존 Office 20xx 패키지의 관계만큼이나 궁금해진다.

그리고 더 결정적으로는 기업 같은 데서 서버 제품군을 쓰는 곳이 있긴 한지..?? 이건 마치 Itanium 컴퓨터만큼이나 본인이 태어나서 지금까지 한 번도 구경해 보지 못했다.
왜냐하면 서버 제품군을 쓸 정도의 컴퓨터라면 차라리 유닉스 터미널이 내장돼 있는 리눅스나 맥OS를 쓰고 말지 Windows를 쓰지는 않기 때문이다.

서버 에디션은 원래 Windows NT나 2000까지는 동일 버전의 바리에이션 형태로만 존재해 왔다. 그랬는데 XP 때는 웬일인지 Server 2003이라고 제품명은 물론 내부 버전 번호까지 다르게 붙일 정도로(5.1 vs 5.2) 차별화를 했었다. 그 대신 XP는 개인용 에디션이 홈 vs 프로로 더 세분화됐다.
그 뒤로 서버 제품군은 버전 번호는 클라이언트와 동일하지만 제품명은 저렇게 Server 20xx 식으로 나가고 있다.

3. 자잘한 UI 버그

  • 가끔씩 재래식 TSF 입력 도구모음줄과, 작업 표시줄 쪽의 Windows 10 스타일 입력 상태 아이콘이 동시에 나타나는 버그는 꽤 유명했는데 19xx나 20xx 사이에서 드디어 고쳐진 것 같다. 요즘은 눈에 띄지 않는다.
    하지만 caret (cursor)이 여섯 번 정도 깜빡이다가 깜빡임이 중단되는 버그는 여전히 건재한 듯하다. Windows 3.1 이래로 이런 특이한 현상은 처음이다.

  • 가~~~끔. 컴을 절전 모드에서 꺼냈을 때나 프로그램 창을 전환했을 때.. 이미 띄워져 있는 프로그램 창들이 부르르 다시 그려지면서 깜빡이고 떨리는 현상.
    내 개인용 컴과 회사 컴이 모두 그러는데 좀 보기 거슬린다.
    윈10 초창기에는 이런 현상이 없었고, 특정 컴에서만 그러는 것 같지는 않은데 왜 그러나 모르겠다. (2004대 버전 기준)

  • 컴퓨터에 따라서 케바케이긴 하지만.. 메뉴가 '파일, 편집' 같은 라벨의 우측 하단 ┗ 모양이 아니라 ┛ 왼쪽으로 펼쳐지는 기괴한 현상이 왜 발생하는지 모르겠다. 아랍권도 아닌 멀쩡한 한국어/영어에서 말이다.
    로컬라이즈나 사용 접근성을 위해 필요한 옵션이라면 제어판에라도 옵션을 정식으로 갖다 놓든지..? 저런 동작이 왜 존재하는지도 모르겠고, 또 사용자의 동의 없이 불쑥 바꿔 놓고는 원상복구를 왜 레지스트리 수정을 통해서 해야 하는지 모르겠다.

Posted by 사무엘

2021/06/02 08:36 2021/06/02 08:36
,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1894

1. 압축 유틸

요즘은 Adobe Reader 같은 거 설치할 필요 없이 크롬이나 Edge 같은 브라우저만으로도 자체적으로 pdf 문서를 바로 열어 볼 수 있다.
압축 유틸리티에서 광학 디스크 이미지 파일의 내용을 바로 볼 수 있게 된 것과 비슷해 보인다. 한 분야의 프로그램이 비슷한 다른 분야의 프로그램의 역할을 일부 흡수해 버렸다.

물론 이미지 파일을 새로운 드라이브로 mount 시키는 것까지 압축 유틸이 지원하지는 않는다. 그것까지 지원하면 압축 유틸의 기능이 옛날 도스 시절의 Double Space 같은 디스크 압축 유틸 급으로 커지는데.. 요즘은 그런 기능이 필요할 정도로 디스크의 용량이 부족한 시절이 아니기 때문에 유행이 지났다. 그리고 결정적으로 드라이브 mount는 이제 운영체제(Windows 10)가 자체적으로 제공해 주는 기능으로 흡수되기도 했다;;

국내의 경우 20여 년 전, 이 바닥이 WinZip, WinRAR 같은 외국산 압축 유틸리티 일색이던 시절에 이스트소프트의 '알집'이 처음에 적절한 마케팅 덕분에 시장 선점을 잘 해서 폭발적인 인기를 누렸다. 그러나 버그· 안정성 문제에 적절히 대처하지 못해서 2000년대 말쯤에 컴덕들 사이에 욕을 엄청 먹었으며, 그 와중에 기업 대상 유료화까지 선언하는 바람에 입지를 더욱 잃게 됐다.

그 와중에 개인 개발자 1인의 작품인 '빵집'이 알집의 대체제로 각광 받아서 2000년대 후반에 큰 인기를 끌었다.. 하지만 빵집은 개발자의 개인 취미 생활이다 보니 유지보수에 한계가 있었고, 결국 개발이 중단되어 역사 속으로 사라졌다.
그리고 오늘날이야.. 그 틈새를 저격한 반디소프트의 '반디집'이 탁월한 완성도로 천하를 평정했다.

압축 유틸의 역사를 읽어 보노라면, 소프트웨어는 모름지기 수요와 타이밍, 시장 공략을 잘 해야겠다는 걸 느낀다.
zip은 압축 해제뿐만 아니라 생성까지 소스가 완전히 공개돼 있고 그 다음부터 7z, ace, rar 등 압축 알고리즘들의 압축률은 이론적인 정보량 한계에 근접해서 거기서 거기이다 보니.. 알고리즘은 zip 하나만 있으면 되고 그 뒤 멀티코어, 64비트, 유니코드, 기본적인 보안, 운영체제 셸과 잘 연계하는 UI...

이것만 제공되면 그 다음부터 굳이 유료 유틸을 쓸 필요가 크게 줄어드는 것 같다. 실제로 본인도 '-집' 계열 유틸을 사용하기 시작한 뒤부터는 Windows에서 zip 말고 rar 등 다른 압축 파일을 '생성'해 본 적이라고는 전혀 없는 것 같다.

2. 유튜브

(1) 유튜브 동영상에 광고가 5~10여 년 전에 비해 굉장히 많이 늘어난 게 느껴진다.
뭐, 쟤들도 흙 파서 먹고 사는 건 아닐 테니, 오랫동안 무료로 잔뜩 뿌리고 투자했던 것을 회수할 때가 됐다. 전세계에서 발생하는 천문학적인 수의 동영상들을 저장하고 전송 트래픽을 감당할.. 서버 유지비가 장난 아니게 깨질 것이며.. 몸값 비싼 엔지니어들을 고용하는 인건비도 상상을 초월할 것이다. 서버 관리자, 웹 UI 디자이너 및 개발자, 동영상 코덱 전문가, 동영상 컨텐츠들의 검색과 분류 알고리즘 전문가 등..

그러니 동영상 포털이 사용자에게 거부감을 제일 덜 주면서 수익을 내는 건 광고 또는 사용자에게 "광고 안 뜨는 기간제 유료 계정" 판매로 자연스럽게 귀착될 것이다. 나도 광고가 너무 잦아지니 잠시 동안만이라도 광고 없는 유튜브 프리미엄 유료 계정을 써 보고 싶다는 생각이 종종 든다. 유튜브도 사용자를 이렇게 적당히만 귀찮게 하는 걸 목표로 하지 싶다.

요즘 친구들끼리 생일 선물로 카카오톡으로 이모티콘이라든가 커피 상품권을 주고 받는 게 있다. 그런 것처럼 몇천 내지 1~2만원대의 유튜브 프리미엄 n개월 이용권이 온라인/모바일 생일 선물로 오가는 건 어떨까 싶다.

여담이지만, 유튜브뿐만 아니라 평소에 위키백과를 지식 습득용으로 유용하게 사용해 온 사람이라면 거기에도 후원금을 소액이나마 내는 게 좋을 것이다. 특정 기업의 입맛에 휘둘리지 않고 상업 광고도 없는 개방된 지식 저장소는 컴퓨터와 인터넷을 지금 같이 누구에게나 평등하고 투명하게 개방된 정보의 바다로 만드는 데 절대적인 기여를 했기 때문이다.

(2) 다음으로, 돈이나 광고와 별개로 본인이 요 근래에 유튜브에 대해서 느끼는 굉장히 큰 불만이 하나 있다.
HD급 이상의 무거운 고화질 동영상일수록 더 두드러지는 것 같은데.. 슬라이더에서 좌우 화살표를 눌러서 앞뒤 5초 남짓 단위로 seek를 한번 하는 데 걸리는 딜레이가 너무 길다는 것이다. 동일 화질 기준으로 그냥 하드에 저장된 동영상을 데스크톱용 플레이어 앱에서 seek하는 것만치 빨리 즉시는 절대 못 한다. 답답하지 않으신가?

옛날 저화질 동영상은 이렇지 않다. 이건 다운로드 자체는 이미 다 된 구간을 돌아다니는 것만 말한다. 그러니 네트워크 상태하고도 무관하다.
기술적인 한계 때문에 느린 건지 아니면 이것도 설마 현질 유도를 위해 고의로 들어간 핸디캡인지는 잘 모르겠다.

(3) 끝으로, 유튜브 유료 계정에 제공되는 서비스로는 광고 제거뿐만 아니라 동영상을 아예 로컬에다 다운로드하는 것도 있었다.
하지만 그건 별도의 서비스가 없더라도 뒷구멍을 통한 다운로드 서비스가 넘쳐나다 보니 유튜브에서도 단속을 포기한 것 같다. 별도의 앱이던 게 더 간편한 웹으로 바뀌기까지 하고 말이다. 사실 이건 기술적으로, 근본적으로 막을 수 있어 보이지는 않는다.

3. 이메일: 대용량 파일 첨부, 발송 확인 및 취소 기능

15년쯤 전에 구글 gmail이 최초로 1GB짜리 웹 기반 무료 이메일을 개설한 이래로 요즘은 어디건 이메일 서비스는 기본이고 용량이 기가바이트급이다. 하지만 이메일은 편지함 용량과 컴퓨터의 하드 용량이 증가한 것에 ‘비하면’, 무슨 영화 파일 급의 대용량 첨부 파일을 주고 받기에는 여전히 좀 버거운 수단이다. 기껏해야 수~수십 MB 정도가 한계?

초대용량 파일은 메일에다가 직접 붙이는 게 아니라 다른 클라우드/웹하드에다 올리고 나서 그거 링크만 메일에다 넣는 형태로 대체되는 게 요즘 추세이다.
수신 확인 및 오발신 취소 같은 것도 이메일의 정식 프로토콜/스펙에 규정된 기능이 아니라 각 웹메일 서비스 사이트에서 자기 계정간 이메일에 한해서만 제공되는 비표준 편의 기능인데.. 이것도 좀 표준으로 승격됐으면 하는 바람이 있다.

4. 크롬 브라우저로 네이버 블로그 첨부 파일 다운로드

크롬 브라우저로는 네이버 블로그 기반의 사이트에서 첨부 파일 다운로드가 잘 되지 않는 문제가 있다.
나만 겪는 현상인 줄 알았는데 아니었구나..

검색을 해 보니, 네이버 블로그는 https 기반인데 다운로드 링크는 보안이 취약한 http 기반이어서 크롬이 의심스럽다는 이유로 다운로드를 차단한 것이었다.
즉, 네트워크 구조에 문제가 있어서이지, 첨부 파일의 내용에 문제가 있어서가 아니었다.

이렇게 웹페이지의 구성요소에 https와 http가 뒤섞여 있으면 브라우저가 의심스럽고 불안하다고, 그래도 내용을 다 보고 싶냐고 온갖 귀찮은 확인 메시지를 사용자에게 띄운다. 다들 한 번쯤은 그 모습을 본 적이 있을 것이다.

그런데 크롬의 경우, 그 어떤 에러 메시지도 없이 그냥 일방적으로 네이버 블로그로부터의 다운로드를 씹어 버리니 당혹스러웠다. 은행 ActiveX도 아니고 파일 다운로드를 위해서 구닥다리 IE를 끄집어내는 촌극이 벌어지기도 했다.
뭐, 궁극적으로는 천하의 네이버가 이 문제를 해결하고 네트워크 구조를 불안 요소가 없게 어서 고쳤으면 좋겠다.

크롬은 이제 올해부터 플래시조차 지원을 완전히 끊었다. 아직도 메뉴가 플래시 기반인 웹사이트는 한 몇 년은 관리를 안 한 완전 구닥다리.. "1024*768 해상도에서 IE 6 브라우저에서 가장 잘 보입니다" 이러면서 제로보드 게시판까지 같이 붙어 있는 사이트일 가능성이 높을 것이다.
세월이 참 많이도 흘렀다. 플래시, 제로보드, Visual Basic 6, 재래식 hlp.. 이런 것들이 역사 속으로 사라졌다.

5. 마이너한 검색들

일반적으로 널리 쓰이는 기능은 아닐 테니 유료 서비스 형태로 제공되더라도..

(1) 많고 많은 웹툰들은 그림 파일뿐만 아니라 말풍선 안의 대사들도 색인화돼서 대사로 해당 컷의 검색이 됐으면 좋겠다.
짤방으로 써먹고 싶은데 그 그림이 긴 웹툰 시리즈의 어느 화에 있었는지 기억을 못 할 때가 많다.
물론 "이 학교의 주인은 이사장인 나예요."(사립정글고), "네놈을 살려 두긴 쌀이 아까워!"(이말년), "선 넘네"(엉덩국 애기공룡 둘리) 같은 거야 너무 강렬하고 유명하니 일반 검색 엔진으로도 대사와 컷 이미지가 개념적으로 연결돼 버렸지만.. 그렇지 않은 컷도 많다.

(2) 주선율 음표 표기로 음악 검색. 밖에서 재생되는 음원을 들려줘서 비슷한 음반의 노래를 찾는 건 이미 서비스 되는 게 있지만.. 그건 음원이 없고 사람의 오랜 기억 속에만 존재하는 음악을 찾아 주지는 못한다. 내가 말하는 건 음악들의 주선율 악보를 색인화해서 검색하는 것이다. 다만, 이걸로 검색하려면 사용자도 최소한의 채보· 기보 능력이 있어야 한다.

검색 엔진이란 게 처음에는 같은 웹에서 텍스트 위주로만 검색을 지원했다. 그러나 요즘은 웹뿐만 아니라 종이책, 잡지, 옛 신문들과 방송 자료, 논문 같은 오프라인 매체로 범위가 확장되었으며, 정보의 형태도 텍스트에 국한되지 않고 그림과 동영상까지 취급한다.

그러니 이게 앞으로는 텍스트뿐만 아니라 사람이 마우스로 얼추 끄적인 스케치와 비슷하게 생긴 그림이나 실제 로고타입을 찾아 주고, 콩나물 배열만으로 음악을 찾아 주는 경지에 도달하지 않을까 싶다. 그야말로 사람의 기억을 보조해 주는 도구가 되는 것이다. 그리고 국내 웹툰뿐만 아니라 과거의 뉴스 보도, 특히 대한뉴스들도 다 색인화되면 엄청난 도움이 될 것이다.

Posted by 사무엘

2021/04/16 08:33 2021/04/16 08:33
, , , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1877

지금으로부터 30년쯤 전에 도스용으로 만들어졌던 프로그래밍 툴 중에는 자기 언어로 만들어진 예제 프로그램으로 그럴싸한 게임을 제공하는 경우가 있었다.
QBasic의 경우, 포트리스 내지 Scorched Earth와 비슷한 형태의 턴 기반 슈팅인 '고릴라'가 유명했으며.. 길다란 뱀을 사방으로 적절히 조종하면서 아이템(?)을 먹는 퍼즐인 nibbles도 있었다.

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

아이템을 먹을수록 뱀은 길이가 더 길어지며, 머리가 벽은 물론이고 자기 몸통과도 부딪치지 않도록 조종을 잘 해야 한다. 그리고 레벨이 올라갈수록 뱀의 이동 속도가 더 올라가고 장애물도 더 많아져서 게임 진행이 더 어려워진다.
영문판 원판은 80*25 텍스트 화면에서도 아스키 그래픽 문자를 적절히 이용해서 글자 한 칸을 상하로 쪼개어 세로 공간을 두 배로 늘리는 편법을 구현했다. 하지만 한글판에서 제공된 nibbles는 문자 코드의 한계로 인해 그런 게 다 삭제되었다.

그런데 가만히 생각해 보니 마소 말고 볼랜드 개발툴에서 제공한 예제 프로그램 중에는 가히 이 분야의 끝판왕이 있었다. 번듯한 체스 게임이 컴퓨터 AI까지 포함해서 소스가 통째로 제공되었던 것이다.

사용자 삽입 이미지

이거 기억하는 분 계신가..?
그런데 이게 bgidemo보다 훨씬 덜 유명하고, 본인도 지난 수십 년 동안 얘의 존재를 까맣게 잊고 있었던 이유는.. 아무래도 아무 버전에서나 쉽게 볼 수 있는 예제는 아니었기 때문이지 싶다.
즉, 보급형인 Turbo가 아니라 기함급인 Borland라는 브랜드가 붙은 C++ 내지 Pascal을 설치하고, Windows 개발 환경에다 자체 프레임워크 라이브러리까지 다 선택해야 얘를 구경하고 돌려볼 수 있다.

이 예제 프로그램의 이름은 볼랜드에서 개발한 C++용 Windows API 프레임워크의 이름을 딴 OWL Chess였다.
하지만 내 기억이 맞다면 Turbo Vision 기반의 도스용 체스 예제도 있었다. 체스판과 말을 그래픽 모드가 아니라 텍스트 모드에서 꽤 기괴한 색과 특수문자를 동원해서 표현했던 걸로 기억하는데.. 정확한 내역은 너무 오래돼서 잘 모르겠다.

Windows용 OWL Chess는 이런 식으로 동작했던 걸로 본인은 기억한다.

  • 16비트 전용이다. 32비트 에디션에도 포함됐다거나, Delphi 및 C++ Builder 같은 후대의 컴포넌트 기반 RAD툴로 리메이크 됐다는 소식은 내가 아는 한 없다. 그러니 얘는 Windows XP에서 실행됐을 때도, 저 스크린샷에서 보다시피 프로그램의 제목 표시줄에 테마가 적용돼 있지 않다.
  • 역시 저 스크린샷에서 묘사된 바와 같이, 창 크기는 고정 불변이다. 요즘처럼 모니터가 크고 화면 해상도가 높은 시대엔 크기 조절이 안 되는 프로그램은 사용자에게 좋은 인상을 주기 어려울 것이다.
  • 키보드 포커스가 딴데로 넘어가서 프로그램이 비활성화 되면 즉시 게임판이 가려지고 pause 모드로 바뀐다.
  • 컴퓨터 AI는 1990년대의 바둑 같은 보드 게임 AI들이 그랬던 것처럼 규칙 기반으로 move를 평가하고, 재귀적으로 수읽기를 하면서 알파-베타 가지치기로 복잡도를 제어하는 식으로 구현됐다. 생각하는 데 시간이 많이 걸리긴 하지만, 멀티스레드라는 것도 없던 시절에 이 동작이 찔끔찔끔 idle time processing만으로 잘 만들어져 있다. 컴퓨터의 생각이 현재 어느 정도까지 진행됐는지가 수시로 현란하게 시각적으로 표시되기 때문에 지겹지 않다.

하긴, 1990년대 초중반에는 프로그래밍깨나 공부 좀 한 사람들이 도스의 그래픽 모드에서 아기자기한 오목· 장기 게임을 구현해서 PC 통신 자료실에 무료로 공개한 게 많았다. 아, 심지어 화투 치는 고도리...도 그 시절부터 있었다.
또한 그 시절에 유명한 프로그래밍 기술 간행물이던 '비트 프로젝트' 시리즈에도 초창기엔 Borland C++로 개발한 Windows용 장기 게임이 있었다.

지금이야 국내에서 유료 판매까지 되고 있는 장기 게임 프로그램으로는 '장기도사'가 있다. 하지만 그 전에는 '바다장기'라는 프로그램도 있었는데, 얘가 내 기억이 맞다면 저 원조 OWL Chess의 소스를 기반으로 만들어진 듯했다.
프로그램의 외형과 동작이 굉장히 비슷하게 느껴졌었기 때문이다. 또한 바다장기도 검색을 해 보면 16비트스러운 스크린샷밖에 안 나오는 게 더욱 비슷하다.

사용자 삽입 이미지

그래도 서양의 체스와 동양의 장기가 완전히 동일한 게임은 아닐 텐데, 체스 AI를 장기 AI로 룰을 개조하는 건 건 아무나 할 수 있는 일이 아니었을 것이다. 그리고 그 원판 AI 코드도 move를 기술하고 평가하는 룰 계층만 바꿔 주면 어지간한 보드 게임의 AI에 모두 대응 가능하도록 상당히 추상적이고 깔끔하게 잘 만들어져 있었던 모양이다. 바다장기는 AI를 '추론 엔진'이라는 용어를 써서 표현했다.

일개 예제 프로그램의 체스 AI가 전문 상업용 AI에 비할 바는 아니겠지만.. 이 정도만 해도 어디인가? 지금 저 프로그램의 소스를 다시 볼 수 있으면 보드 게임 AI의 구현과 관련해서 많은 통찰을 얻을 수 있을 텐데 아쉽다. 얘의 소스만 어디 github에 따로 올라와도 될 텐데 말이다.
본인은 체스는 룰조차도 모르지만.. 그래도 학창 시절에 오목과 스크래블이라는 보드 게임 AI를 연구했던 이력이 있는 사람이어서 이런 쪽에 더욱 흥미를 느낀다.

Posted by 사무엘

2021/03/17 19:35 2021/03/17 19:35
, , , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1866

오늘날처럼 컴퓨터의 문자 인코딩이 유니코드로 천하통일이 되기 전엔 국내에서는 2바이트 완성형과 조합형 한글 코드 논란이 가라앉지 않고 있었다. 완성형은 94*94 격자 모양의 단순하고 국제 규격에 부합하는(?) 방식으로 인코딩돼 있었지만 한글의 구성 원리를 무시하고 한글을 난도질했다는 비판을 떠안고 있었다.

완성형은 “한글 vs 비한글”을 구분하고 처리하는 데 유리했다.
그에 비해 민간에서는 “한글 글자 vs 낱자”의 처리가 더 용이한 조합형이 훨씬 더 대중적으로 쓰였다. 그도 그럴 것이 640KB 기본 메모리를 1KB라도 더 확보하려고 목숨 걸던 시절, 메모리 모델이 어떻고 far 포인터가 어떻고 이러던 시절에.. 한글 처리를 위해서 2350자 테이블을 내장하고 다닌다는 건 성능과 효율로나 민족 정서(?)로나 도저히 용납할 수 없었기 때문이다.

허나, 명목상 국가 표준은 완성형이었기 때문에 마소 역시 도스와 Windows의 한글판을 전적으로 완성형 기반으로 만들었다. 완성형은 두벌식과 마찬가지로 그 시절에 소프트웨의 한글판을 필요 이상으로 더 무겁게 만든다는 비판을 피하기 어려웠다. 다만, 이건 애초에 우리나라에서 표준을 이상하게 만든 게 잘못이지 마소의 잘못은 아닐 것이다.

Windows 3.1이야 이런 배경에서 만들어졌기 때문에 한글 IME로 똠, 펲 같은 글자가 입력되지 않았으며, 또ㅁ, 페ㅍ이라고 글자가 풀어졌다. ‘썅’은 2350자에 속해 있는데 중간의 ‘쌰’는 그렇지 않기 때문에 ‘썅’까지 덩달아 입력할 수 없는 것은 유명한 사실이다.

그리고 처음부터 ‘쌰’를 입력하면 ‘ㅆㅑ’라고 잘 갈라지는데, 두벌식에서 ‘있’ 다음에 ㅑ를 입력하면 ‘이ㅆㅑ’가  되지 않고 뭔가 올바른 동작이 나오지 않았던 걸로 본인은 기억한다.
이런 것들이 한글 입력기, 특히 특정 문자 입력 제한이 걸린 두벌식 입력 방식을 구현할 때 고려해야 하는 복병이다. 날개셋이야 이 분야 전문이기 때문에 그런 것들도 다 정상적으로 처리해 준다.

그럼 차기 버전인 Windows 95는 상황이 어땠을까?
Windows 95는 오늘날 세계 표준 문자 집합 겸 인코딩인 유니코드, 특히 유니코드 중에서도 버전 2.0이 한창 제정되고 있던 와중에 개발되고 먼저 출시되었다. 이건 굉장히 중요한 사건이었다.

우리나라에서는 수 년 전 유니코드 1.x 시절에는 완성형 2350자만 그대로 제출하는 삽질을 저지른 적이 있었다. 그러다가 유니코드 2.0에서 문자 체계를 싹 재정비하는 인류 역사상 마지막 기회가 찾아왔을 때.. 한글을 11172자 모두 순서대로 등록하려는 과감한, 역사적인 계획을 세웠다. 그래야 글자 코드값으로 자모 정보를 쉽게 추출할 수 있기 때문이다.
이건 스타에다 비유하자면 종족 밸런스를 앞으로 다시는 바꾸지 않는 1.08 패치와 비슷한 타이밍이었다.

그런데 그렇게 하려면 세계를 설득해야 했다.
다른 나라들은(특히 일본과 중국도) BMP 영역의 1/5 가까이를.. 그것도 사용자가 1억도 채 안 되는 언어의 고유 문자로 싹 도배하려는 한국을 고깝게 보고 이의를 제기했다.
유니코드 회의에서 누가 발언권을 얻으려면 한화로 억대에 달하는 회원 등록비도 많이 내야 하는데, 이런 비용을 한컴 같은 기업에서 많이 후원해 줬다. 저 때는 삼성전자도 훈민정음 워드 같은 프로그램이나 간간이 만들었지, 지금 정도로 IT계에 세계구급 영향을 행사하는 기업이 아니었다는 걸 생각해 보자!

이런 우여곡절 끝에 한글 11172자는 1996년 7월, 유니코드 위원회의 승인을 받아서 성공적으로 등재되었다. 이거 내막을 아는 사람이라면 이것도 1981년 서울 올림픽 바덴바덴의 기적에 맞먹는 외교 승리라고 여기고 칭송한다. 올림픽은 52:27의 압승이라도 했지만 11172자 등재는 찬성이 반대를 한 표 차이로 정말 간신히 꺾은 거라고 한다.

그런데 문제는 Windows 95는 유니코드 2.0이 정식으로 발표되기 미묘하게 약간 전에 출시되었다는 것이다. 한글판도 1995년 11월 말에 출시됐으니..;;
그럼에도 불구하고 각종 글꼴과 코드 변환 테이블은 이미 유니코드 2.0을 기준으로 맞춰져 있다. 어떻게 이게 가능했을까?

유니코드 2.0에다가 한글을 2350자가 아니라 11172자를 몽땅 집어넣기 위해서는.. 근거가 필요했다. 유니코드가 아닌 기존 2바이트 인코딩 중에도 한글 11172자 표현이 가능한 놈이 있어야 했다.
그럼 Windows가 처음부터 조합형 코드로 개발됐으면 좋았겠지만 모종의 이유로 인해 그리 되지 못했고.. 결국은 기존 완성형에다가 지저분한 독자적인 편법을 동원해서 비완성형 한글을 끼워넣을 수밖에 없었다.

이게 그 이름도 유명한 확장완성형, 일명 CP949 인코딩이다.
KS X 1001은 한글 2350자, 한자 4888자 등을 포함하는 그 2바이트 완성형 문자 집합/코드이고, KS X 1003은 역슬래시를 원화로 대체한 그 한국 특유의 1바이트 영문/숫자 아스키 문자 집합이다. 이 둘을 합쳐서 EUC-KR이라고 부르고, 여기에다가 확장완성형까지 추가하면 CP949가 된다. 집합 관계를 정리하자면 (KS X 1001 ∪ KS X 1003) = EUC-KR ⊂ CP949이다.

(참고: KS X 1002는 완성형 형태로 현대 한글, 옛한글, 한자를 추가로 정의하는 규격이다. 하지만 KS X 1001과 병용하는 인코딩 규칙이 제정되지 않아서 컴퓨터에서 실제로 쓰인 적은 없는 캐잉여이다. 얘는 애초에 유니코드 1.1에다가 글자를 추가로 등록할 근거를 마련하려고 어거지로 만든 문자 집합에 지나지 않는데, 이제는 유니코드 1.1 자체도 오래 전에 흑역사가 됐으니 더욱 의미와 존재감이 없다.)

이렇듯, 확장완성형이라는 건.. 비록 처음에 첫단추를 잘못 끼우긴 했지만 뒤늦게 유니코드 2.0에라도 한글을 11172자를 순서대로 다 집어넣기 위해서 도입한 2바이트용 타협 절충안이었다. 마소에서는 한국 편을 들면서 도와 주면 도와 줬지, 최소한 상황을 더 나쁘게 만든 건 절대 없었다.

그럼에도 불구하고 1990년대 당시에는 마소에서 완성형에다가 그보다 더한 확장완성형까지 집어넣어서 한글을 난도질한다고 엄청난 논란이 일었다. 심지어 한컴에서도 아래아한글 도움말 및 제품 광고에서 이 괴담을 어느 정도 활용하고 부추겼다.

왜 한글을 난도질 하느냐 하면, 확장완성형은 이미 2350가 조밀하게 순서대로 배치된 건 그대로 유지하면서 나머지 틈새에다가 비완성형 8822자를 집어넣는 형태가 되기 때문이다. 그러면 겉보기로는 11172자가 모두 배당되지만 문자의 코드값 순서가 그 문자의 사전상의 배열 순서와 일치하지 않게 된다. 사전 순 정렬을 하려면 코드값을 별도로 보정을 해야 한다.

물론 코드값만으로 문자를 정렬할 수 있는 게 가능하지 않은 것보다는 더 직관적이고 깔끔하고 낫다. 하지만 오늘날 유니코드는 시간 차를 두고 뜬금없이 여기저기 지저분하게 추가된 문자들이 워낙 많기 때문에(특히 한자~!!), 거시적으로 봤을 때 코드값만으로 문자들을 정렬하는 건 어차피 불가능하고 무의미해져 있다.

뭐, 이것도 논란이 다 끝난 오늘날의 관점에서 보니까 별것 아닌 것처럼 보이지, 2바이트 한글 코드만 단독으로 생각하던 시절에 확장완성형이 답답하고 지저분하게 보이는 것도 부인할 수 없어 보인다.
그리고 마소는 훗날 IMF 때 경영난에 빠진 한컴에다가 돈줄을 대 주는 대신 아래아한글의 개발을 중단시키려 했던 바 있다. 그러니 확장완성형에 대한 불필요한 오해 실드를 감안하더라도 마소에 대한 국민 감정이 마냥 좋을 수만은 없었을 것이다.

아무튼, 그 시절 Windows 95는 유니코드 2.0의 정식 도입을 선도하면서 온전한 한글 11172자의 입출력이 가능해지려는 과도기에 연결 고리 역할을 했다.
참고로 95 말고 Windows NT는 도스 짬뽕이던 기존 Windows와 달리, 1993년 첫 버전부터 2바이트 wide char 유니코드 기반이었다. 얘도 유니코드 2.0이 정착할 무렵이 돼서야 본격적으로 정식 한글판이 나올 수 있었다. 3.51부터 말이다.

사용자 삽입 이미지

Windows NT 3.5 한글판의 ‘베타 버전’ 평가판. 이건 Windows NT의 역사상 최초로 만들어진 한글판으로, 정말 엄청난 희귀 레어템이다. 마치 Windows 2.x의 듣보잡 한글판처럼 말이다.

저 화면에서 한글 글꼴은 기존 Windows 3.1의 돋움체(큐닉스 제작) 8포인트이다. 하지만 영문은 정체를 모르겠다. W와 i의 폭이 다른 가변폭인 걸 보니 같은 돋움체의 영문은 아닌데, Arial은 물론이고 심지어 후대에 등장한 Tahoma나 Verdana까지 그 어떤 영문 글꼴도 저 크기에서 9나 5의 획이 저렇게 생기지 않았다.

그런데 저 영문 모양이 내가 보기에 전혀 낯설지는 않다.
마소에서 개발한 1990년대 옛날 프로그램의 스플래시 화면 내지 About 대화상자에서 Copyright 문구가 저런 스타일의 글꼴로 표시된 걸 본 것 같기도 한데.. 정확한 정체는 모르겠다.

내 기억이 맞다면 Windows NT 3.51의 정식 한글판은 3.51의 특성상 Windows 3.1과 같은 구형 UI 기반임에도 불구하고 한글 글꼴은 이미 Windows 95 한글판과 동일한 한양 시스템 글꼴로 갈아탔다.
Windows NT의 역사에서 유니코드 1.1 방식 한글이 존재했던 적은 내가 아는 한 없다. 만에 하나 있다면 그건 조합형 코드를 잠깐 썼었다고 전해지는 MS-DOS의 초창기 한글판만큼이나 완전 전설 속에나 존재하지 싶다.

이렇게 95건 NT건 온전한 11172자짜리 유니코드 2.0 기반임에도 불구하고.. 95의 한글 IME를 써 보면.. 구버전인 Windows 3.1과 마찬가지로 여전히 2350자밖에 입력할 수 없었다. 다만, “있+ㅑ”일 때는 ㅆ이 뒷글자로 넘어가지 않도록 로직이 약간 개선돼 있었다.;; ㅎㅎ

사실, Windows 95의 한글 IME는 확장완성형을 기반으로 11172자를 모두 입력하는 기능도 구현은 돼 있었다. 하지만 그걸 기본적으로는 봉인해 놓았으며, 사용 여부를 별도의 유틸리티를 통해 따로 지정할 수 있었다!
바로, C:\Windows 디렉터리에 있는 iso10646.exe라는 30KB짜리 자그마한 프로그램이다. 역시 괜히 과도기였던 게 아니다.

사용자 삽입 이미지

프로그램 UI에는 유니코드니 완성형이니 같은 말은 없고 그냥 "ISO 10646 사용 여부"가 전부였다. 유니코드의 문자 집합을 가리키는 표준 규격 명칭이 ISO 10646이기 때문이다.
전체 사용 아니면 특정 프로그램에서만 사용.. 이런 걸 지정해 주면 타 프로그램에서 똠쌰 등등의 글자를 입력할 수 있었다.

신기한 것은 Windows용 프로그램뿐만 아니라 도스용 mshbios의 한글 입력기까지 이 설정의 영향을 받았다는 것이다. 설정값을 레지스트리가 아니라 파일에다 저장했던가 보다. 아니면 도스에서도 레지스트리 파일에 저수준으로 접근을 했던지..

확장 한자의 사용 여부를 옵션으로 지정하는 것처럼 2350/11172자 입력 범위도 그냥 IME의 옵션으로 지정하면 됐을 것 같은데 굳이 별도로.. 제대로 문서화되지도 않은 프로그램에다 저렇게 꽁꽁 숨겨 놨다.
부작용을 어지간히도 의식했는지 각종 프로그램별로 입력 범위를 달리 지정할 수 있게 신경을 썼다. 즉, 여느 평범한 IME 옵션이 아니라.. 날개셋으로 치면 응용 프로그램별 동작 보정 옵션과 비슷한 걸로 취급한 것이다.

훗날 MS Office 97이 나왔고.. 그 중 Word는 단품으로 따로 팔기도 했다.
마소 역시 한컴 진영의 조합형 한글 마케팅을 많이 의식했는지, 신문 광고에서 조그맣게.. "우리 마소 제품에서도 똠방각하 펩시콜라 찦차를 입력할 수 있습니다." 문구와 함께, iso10646 프로그램 사용법을 소개해 놓기도 했었다.

본인은 학창 시절에 그 광고를 직접 본 기억이 있다.
지금도 구글에서 iso10646.exe 라고 검색해 보면 옛날 흔적을 찾아볼 수 있다.

마소의 전략은.. 요런 프로그램을 몰래 집어넣은 뒤, 확장완성형이 계속 부정적인 피드백을 받으면 Windows 95는 그딴 거 지원한 적 없다고 발뺌 하면서 2350자 기존 완성형에만 머무르면 될 것이고,
한글을 2350자밖에 입력 못 한다고 욕먹는 게 더 크면, 저 비장의 프로그램을 음지에서 양지로 끄집어내려는 속셈이었던 것 같다. 쉽게 말해 간보기 전략이다.

그러다가 Windows 98부터는 이런 간보기가 없어지고 그냥 모든 프로그램에서 확장완성형까지 활용한 11172자 한글 입력이 되기 시작한 것이다. 나중에 Office 2000과 함께 옛한글 입력기가 도입됐을 때는 이제 마소의 제품이 옛한글의 표현 능력도 아래아한글 97과 한컴 2바이트 코드를 추월하게 됐다.

이상이다. “라떼는 말이야” 같은 얘기가 좀 길어졌다.. ^^
25년 전, Windows 3.1에서 95로 넘어간 것은 정말 엄청난 격변이었다. 하지만 Windows 95와 98 사이에도 컴퓨터 환경은 굉장히 많이 바뀌었다.
가정용 PC의 평균 램 용량이 4~16MB대이던 것이 그 짧은 기간 동안 32~128MB로 순식간에 뻥튀기 됐다. PC 규격도 이것저것 많이 바뀌고.. 또 무엇보다도 이 사이에 유니코드 2.0이 제정되었다. 운영체제 차원에서 UTF-8 인코딩이 직접 지원되기 시작한 최초의 Windows가 바로 98이다.

Windows에서 완성형 2350자에 구애받지 않고 한글 입력이 가능해지기까지 이런 우여곡절이 있었다.
Windows 98은 현대 한글이 완전히 해금됐고, 지난 Windows 8 (2012)부터는 옛한글까지 해금됐으니 참 격세지감이다. 그 사이의 XP는 입력 프로토콜이 IME에서 TSF로 넘어간 과도기였고 말이다.

그런데 정작 옛한글 말뭉치를 엄청나게 많이 구축한 21세기 세종 계획은 이것보다 미묘하게 일찍 진행된 바람에 비표준 한양PUA 방식으로 결과물을 산출해 버렸으니 타이밍이 안습했던 구석이 있다.

Posted by 사무엘

2020/11/09 08:35 2020/11/09 08:35
, , , , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1817

본인에게 30여 년 전의 어린 시절부터 친숙했던 비디오 게임 장르는 액션/아케이드 계열이다. 사람 주인공을 화살표 키로 움직이고, 장애물을 직접 뛰어넘고 적을 공격하는 형태 말이다.
그것 말고 다른 장르는 생소했다. 그나마 전략 시뮬은 듄, 워크래프트, 스타 때문에 알게 됐다. 그 전에 삼국지 같은 건 실시간이 아니라 턴 기반 전략 시뮬이었던가 보다.

롤플레잉은 내가 즐겨 하지는 않았지만 주변 친구 중에 좋아하는 사람이 워낙 많았기 때문에 알음알음 접했다. “RPG 쯔꾸르” 같은 툴로 자기가 직접 시나리오를 짜서 게임을 만드는 경우도 있었다. 그런 툴은 정교한 트리거 편집 기능을 갖춘 스타 캠페인 에디터보다도 customize의 자유도가 더 높고, 그렇다고 아예 코딩을 직접 해야 하는 게임 엔진 SDK보다는 폭이 좁은 수준인 것 같다.

그럼.. ‘어드벤처’라는 장르는? 잘 모르겠다. 남이 하는 것도 거의 못 봤다. 그 이름도 유명한 “인디아나 존스”, “원숭이 섬의 비밀”이 이 장르라고 하나.. 본인은 1990년대 컴퓨터 잡지를 통해 이름만 들어 봤지 해당 작품을 당대에 직접 구경해 보지 못했다.
다만, 본인의 기억에 남아 있는 건 1992년 말, 초딩 시절 모 컴퓨터 잡지에서 봤던 “어둠의 씨앗”(Dark Seed)라고 640*350 EGA에서 실행됐던 독특한 게임이다.

요런 게임은 주인공을 화살표 키를 누르는 게 아니라 마우스로 화면에 표시된 목적지를 찍어서 이동시킨다. 실시간 3D 그래픽이란 게 없던 관계로, 화면은 그냥 방 단위로 바뀌며, 모든 그래픽은 그냥 도트 스프라이트이다.
하지만 방 안에서 원근법이 구현돼 있기 때문에 카메라에서 멀어지면 주인공의 겉보기 크기도 작아진다. 게임이 실제로 돌아가는 모습은 먼 훗날 유튜브를 통해서나 구경할 수 있게 됐다.

사용자 삽입 이미지

그랬는데 그로부터 3년쯤 뒤인 1995년에는 ‘시에라 온라인’이라는 게임 개발사에서 Phantasmagoria(판타즈마고리아)라고.. 읽기도 힘들어 보이는 대작 어드벤처 게임을 내놓았다. 장르는 호러..;;

귀신 나오는 haunted house에 주인공이 들어가서 문제를 해결하는 것, 한 화면에서 주인공을 클릭 해서 이동시키는 것 등 전반적인 UI와 느낌은 어둠의 씨앗과 아주 비슷해 보였다.
하지만 얘는 온통 인게임 시네마틱으로 가득하며, 주인공 이동도 전~부 블루스크린 치고 영화 스튜디오에서 실사 촬영한 스프라이트로 구현했다..;; BGM 중에는 합창단 코러스도 있고.. 그야말로 반쯤 영화, 반쯤 게임을 표방한 듯하다.

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

지금이야 인게임 컷씬쯤은 몽땅 3D 엔진으로 처리했겠지만 저 때는 그게 가능하지 않았다. 그리고 비록 실사 추출 스프라이트라고는 하지만 겨우 256색 저해상도 비디오에서 많은 걸 바랄 수는 없다. 그저 그런 화질에다 배경과 스프라이트가 제대로 융합되지 못하고 붕 뜬다. ㅎㅎ

압축도 빡세게 하기 어려웠는지 저 게임은 7개 챕터(레벨)에 서너 시간 남짓한 플레이 분량임에도 불구하고 CD 7장..;; 분량이었다. 디스켓을 갈아 끼우듯이 CD를 갈아 끼워야 했다.
25년 전의 가정용 PC 환경이 그만치 열악했다. 그리고 실사 영상을 후처리해서 깔끔하게 256색용 스프라이트로 만드는 건 굉장히 노동집약적이며 쉬운 일이 절대 아니다.

기술 얘기가 좀 길어졌다만, 이 게임은 주인공이 나름 미녀이다(단, 유부녀). 나중에는 남편이 악마가 빙의하여 맛이 가 버리고, 주인공을 형틀에 묶어서 죽이려 한다. 우리의 주인공은 양손이 몽땅 결박당하기 전에 기지를 발휘해서 정당방위 차원에서 그 남편을 죽이고 초췌한 모습으로 집을 빠져나가게 된다. 이게 게임의 스토리이다.

사용자 삽입 이미지

얘는 기술적으로 꽤 근성어린 시도를 했지만, 스토리는 꽤 허접 빈약하고 남는 건 잔혹한 호러 컨텐츠밖에 없다면서 논란을 일으켰다. 똘끼어린 문제작 취급을 받긴 했어도 그래도 당시에는 유명세를 타서 물건이 많이 팔리기도 했다고 한다. 수지가 맞았으니 후속작까지 나올 수 있었다.

작중 주인공의 이름은 에이드리언(Adrienne)이다. 같은 발음이 스펠링을 저렇게 쓰면 여자 이름이 되고, Adrian이라고 쓰면 남자 이름이 되는 것 같다(에이드리언 카맥.. 남자). 실제 배우는 Victoria Morsell인데.. 그냥 무명 배우이고 현재까지 이쪽 일을 하지는 않는 것 같다.

Dark seed의 경우, Mike Dawson이라는 주인공 이름과 정체성을 개발자 자신에게서 그대로 따 온 반면, 저 작품은 그리하지 않았다.
Beyond: Two Souls (2013)이라는 게임에서는 유명 배우 엘렌 페이지의 얼굴을 차용한 주인공이 등장하지만, 3D 폴리곤 모델이지 옛날 같은 실사 스프라이트는 아니라는 차이가 있다.

이런 엄청난 게임을 기획한 사람은 시에라 온라인의 공동 창업자인 윌리엄스 ‘부부’ 중.. 남편 말고 부인인 Roberta Williams였다. 이 사람이 정말 여장부였던 것 같다. 평범한 주부이다가 갑자기 게임 기획 쪽으로 각성해서 90년대 어드벤처 장르의 여왕으로 등극했다.
판타즈마고리아 게임의 잔혹한 고어 묘사에 대해서도.. 우리 게임은 동시대의 Doom이나 Mortal Kombat 시리즈에 비해 그렇게 심할 것 없다면서 쿨한 반응을 보였다.

이들 부부는 결혼을 일찍 했고 소싯적에 게임 개발로 성공해서 돈도 많이 번 덕분에.. 2010년대에는 은퇴해서 여기 저기 크루즈 여행을 다니며 풍족한 노후를 보내고 있댄다. 누구처럼 아예 우주로 나간 정도까지는 아니지만, 어디 어설픈 사업이나 투자하다가 먹튀 하고 몰락하는 것보다는 나은 모습인 것 같다.

판타즈마고리아 이야기가 너무 길어졌구나.. 이걸 근성으로 플레이 하고 컷씬들의 대사와 스토리 진행을 리스닝만으로 친절하게 요약해 놓은 블로그 글이 있으니 관심 있는 분은 참고하시기 바란다. 저 게임 자체는 불친절하게도 자막이 나오는 게 없다.

마지막으로 하나 더 소개하고 싶은 게임은 왕년에 페르시아의 왕자로 스타 개발자에 등극했던 조던 메크너가 기획하여 1997년 초에 내놓은 또 다른 문제작 Last Express이다.

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

얘는 3인칭이 아니라 1인칭 구도이다. 물론 3D 엔진 기반인 건 아니지만 시점이 그렇다는 것이다.
그리고 배경은 1914년 7월, 1차 세계대전이 일어나기 직전의 파리-이스탄불 오리엔트 급행 열차이다. 메크너 아재가 그 시절의 열차 인테리어와 운행 시각표까지 찾아가며 고증을 꼼꼼히 신경 써서 만들었다고 한다.

그리고 더 중요한 특징으로, 얘는 페르시아의 왕자 시절부터 로토스코핑 덕후였던 제작자의 취향이 고스란히 반영되었다.
위에 보다시피 모든 그래픽이 만화영화풍의 그림인데.. 전부 실사 영상을 본따서 디자이너들이 별도의 그림을 그린 것이다. 이 때문에 실사 사진을 보정하는 것 이상으로 많은 시간과 제작비가 소모되었을 것이다. 얘는 CD 3장 분량이었다.

얘는 전무후무하게 참신한 실험 시도로 인해 작품성과 비평 쪽으로 수작.. 혹은 긍정적인 의미로의 문제작 칭호를 받았다. 팔리기도 10만 카피 정도 팔렸다. 하지만 이건 수 년 동안 너무 많이 소모되었던 제작비를 건지기에는 역부족이었기 때문에 상업적으로는 흥행에 실패했다. 다만, 이렇게 된 것에는 제작사가 상황이 안 좋아서 제품의 홍보와 마케팅을 제대로 못 한 잘못도 있었다고 한다.

이상이다.
요약하자면, (1) 3D 없이 재래식 기술만으로 (2) 통상적인 액션/아케이드/롤플레잉 장르가 아니면서 (3) 영화 같은 서사와 스토리텔링을 집어넣은 어드벤처 게임이라는 주제로 몇 가지 대작 작품을 살펴보게 됐다.

그러고 보니 옛날에는 소설인데 1부터 N까지 수십 개의 짤막한 섹션으로 구성되어 있고, 각 섹션의 끝에는 “이 사람의 제안에 어떻게 반응하시겠습니까? ‘예’는 x번으로 가시오. ‘아니요’는 n번으로 가시오” 분기로 가득한 멀티엔딩 형태의 책도 있었던 것 같다. 이건 반쯤 게임, 반쯤 소설인 건지?
작가가 이런 거 만드는 게 굉장히 복잡하고 어려웠을 텐데 나름 참신한 구성이었다.

Posted by 사무엘

2020/10/10 08:35 2020/10/10 08:35
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1806

1. 텍스트 에디터

macOS의 워드 프로세서 겸 에디터인 TextEdit은 신기하게도 '자동 줄 바꿈'을 끄는 기능이 없다...! 개인적으로 굉장한 문화 충격을 느꼈다. 줄 바꿈을 창이 아닌 용지를 기준으로 하게 하고 용지의 폭을 9999로 지정하는 간접적인 방법만 동원할 수 있다.

하긴 macOS는 터미널 창도 창 크기에 맞춰 줄 정렬을 꼬박꼬박 다시 해 주고 xcode의 코드 에디터에서도 자동 줄 바꿈이 지원되니.. 그쪽 바닥은 분위기가 전반적으로 wrap에 친화적인 것 같다.

2. 텍스트 뷰어

에디터처럼 파일을 linked list 형태로 재구성하지 말고 수백 MB~수 GB의 파일이라도 O(1) 상수 시간으로 즉시 읽어들이는 텍스트 뷰어가 좀 있으면 좋겠다. 당장 화면에 표시해야 하는 맨 앞이나 맨 뒷부분만 줄 바꿈과 탭 적용을 한 뒤, 나머지 화면에 안 보이는 부분에 대한 줄 수 계산, 글자 폭 계산 같은 건 그때 그때 백그라운드로 진행한다.
파일의 앞부분이나 맨 뒷부분만 신속하게 조회 가능하되, 필요하면 다른 부분으로 스크롤이나 텍스트 검색도 가능해야 한다. 텍스트 수정은..?? 파일의 크기를 변경하지 않는(= 삽입, 삭제) 변경만 있어도 좋다.

유닉스의 tail 명령은 뒷부분 조회는 가능하지만 내가 원하는 모든 기능이 들어있지는 않다.
워드 프로세서가 아니라 텍스트 에디터도 전문적인 개발 분야이듯.. 텍스트 뷰어만으로도 별개의 개발 분야가 될 수 있을 것 같다. 방대한 로그 파일 같은 건 이런 프로그램을 이용해서 열람해야 할 것이다.

3. 그래픽 에디터

(1) 요즘 세상에 2, 16, 256색 팔레트 기반의 이미지를 전문적으로 처리 가능한 그래픽 에디터가 살아 있기는 한가 모르겠다. 수요가 매우 드물어졌지만 그래도 전혀 없지는 않을 텐데 말이다. 나는 그런 일이 생기면 닥치고 Paint Shop Pro 구버전으로 고고씽 한다..;;

(2) 한편, 세상이 하도 많이 바뀌어서 손실 압축 코덱 기반의 통상적인 동영상이 gif 움짤보다도 더 가볍고 효율이 좋아지는 지경이 됐다. 전자는 jpg처럼 양자화 과정에서 손실이 발생하고, 후자는 디더링 과정에서 손실이 발생한다.
무손실 압축 기반으로 트루컬러가 지원되는 깔끔한 소규모 동영상 포맷이 등장하고 그게 Windows의 애니메이션 컨트롤 같은 데서도 지원됐으면 좋겠다. 일반적인 그래픽 툴로도 쉽게 만들 수 있고 말이다.

4. 파일 관리 셸

프로그래밍을 업으로 삼는 개발자 내지 파워 유저들은 갓 설치한 운영체제의 GUI 기반 파일 관리 셸에서 거의 공통으로 제일 먼저 설정을 변경하는 것이 있다. 바로 (1) 파일 목록에서 확장자까지 표시하도록 하고, (2) 숨김 파일도 나오게 하는 것이다.

  • Windows의 탐색기(Explorer): 예전에는 보기 옵션 대화상자를 꺼내고 번거로운 단계를 거쳐야 했다. 하지만 Windows 8인가 10쯤부터는 '보기' 탭에 체크 옵션이 바로 표시되기 때문에 접근하기 편해졌다.
  • macOS의 Finder: 아마 내 기억이 맞다면 어디 설정 파일을 텍스트 에디터로 열어서 고쳐야 하지 싶다. GUI에서 이런 설정을 변경할 수 있지는 않다. 구체적인 방법은 검색해 보면 나올 것이다.
  • 리눅스: 셸 엔진이 무엇이냐에 따라 차이가 있을 수 있지만(GNOME, KDE??).. 리눅스는 역시 GUI 셸이라도 기본적으로 파일의 확장자가 꼬박꼬박 표시되고 있지 싶다.

이런 사소한 디테일도 세 운영체제의 정책이 서로 차이가 있는 셈이다.
컴퓨터의 내부 디테일을 모조리 파악하고 싶어하는 사람 입장에서는 파일 확장자를 도대체 왜 숨기는지 답답함을 느낄 것이다. 아이콘은 확장자의 기능을 완벽하게 대체하지 못하기 때문이다.

하지만 일반인이나 컴맹의 입장에서는 필요 이상으로 쓸데없이 자세한 정보를 가능한 한 숨기는 게 바람직하다. 그러니 확장자나 숨김 파일을 취급하는 방식은 앞으로도 이렇게 옵션과 재량의 영역에 머무를 것으로 보인다.

5. 웹브라우저

요즘은 웹페이지 내부에서도 지도나 하드카피 문서(구글 도서 검색 같은..)를 조회하고 영역을 Ctrl+휠로 확대/축소할 수 있다.
그런데 똑같이 키보드 포커스를 주고 Ctrl+휠을 굴렸을 때 그 영역만이 확대/축소될 때가 있고, 아니면 웹페이지 전체가 확대/축소되어 버릴 때가 있다. 개인적으로 정확한 패턴이나 조건은 아직 모르겠다. 사용하는 브라우저와 이용하는 사이트가 무엇이냐에 따라서 케바케인 것 같다.

확대/축소에 이렇게 중의성이 발생한 게 참 웃긴데.. 사용자가 원하는 결과는 대부분의 경우 전자, 즉 그 영역만 확대/축소되는 것이다. 웹브라우저 내지 웹사이트를 개발할 때 이런 동작과 사용자 경험 쪽도 고려가 됐으면 좋겠다.

6. 요즘 Windows 10 근황

  • 언제부턴가 시작 메뉴와 작업 표시줄의 배경색이 Windows 10 특유의 검정이 아니라 밝은 회색으로 바뀐 컴퓨터가 눈에 띄기 시작했다. 싸제 테마로 customize를 한 건지 궁금했는데.. 그건 아니고 버전 1903부터 밝은 색 테마가 정식으로 추가된 거라고 한다.
  • 집과 회사 컴퓨터를 몇 대 살펴보니.. xps/oxps 확장자가 자체 viewer로 연결되어 있지 않은 곳이 좀 눈에 띈다. 정작 xps/oxps 파일을 생성해 주는 가상 프린터 드라이버는 다들 기본으로 설치돼 있는데, viewer가 없거나 연결돼 있지 않은 게 말이 되는지..?? 어디 좀 착오가 있는 것 같다.
  • Windows 10이 나온 지 벌써 5년이 돼 간다. 대부분의 운영체제 설정 기능들이 데스크톱 UI인 제어판(Control Panel)에서 메트로 UI인 Settings로 갈아탔지만, 키보드의 반복 속도를 설정하는 기능은 아무리 눈 씻고 검색해도 없는 것 같다.
    Settings에는 키보드 설정과 입력 언어 설정이 별 구분 없이 뒤섞여 있으며, 제어판 한구석에 처박힌 구닥다리 제어판 애플릿을 꺼내야 변경 가능하다.
  • 그리고 내 경험상, 처음 사용하는 컴퓨터들은 마우스 포인터 뒷배경에 그림자 효과가 적용돼 있지 않은 것 같다. 왜 뺐는지..?? 이걸 지정하는 것도 Settings에는 없고, 제어판 애플릿을 따로 열어야 한다.

7. 스플래시 화면

덩치와 규모가 좀 있는 소프트웨어라면 실행되어 로딩 중일 때 일명 스플래시 화면이라는 게 잠시 나타났다가 사라지곤 한다. 얘는 표시하는 내용이 About 대화상자와 좀 겹치는 구석이 있지만(제품 명칭, 버전, 저작권자..), 그 대화상자보다는 화려한 그림의 비중이 더 크다.

뭐, 요즘은 정말로 어마어마하게 방대 거대해서 로딩 시간이 긴 프로그램이라든지, 10년 20년 전부터 화려한 스플래시 화면이 컨셉이요 전통이었던 프로그램이 아닌 이상, 굳이 스플래시 화면을 넣지는 않는 편이다. 그냥 바로 본론으로 들어가서 자기 화면만 띄운다.
컴퓨터의 성능이 갈수록 좋아지면서 프로그램이 구동되는 데 걸리는 시간도 충분히 짧아졌고, 또 요즘은 추세도 새 프로그램의 구동을 요란하게 알리는 게 아니기 때문이다.

예를 들어, 설치 프로그램만 해도 화면 전체를 자기 창으로 꽉 채우고 파랑-검정 그러데이션을 띄우던 유행은 이미 20년도 더 전, 2000년대 초반쯤부터 없어졌고 간단한 마법사로 바뀌었다.
그리고 Windows 8쯤부터는 tada.wav 이래로 오랜 전통이던 운영체제의 시작 음향도 없어졌다. 이런 식이다.

옛날에 Windows 95 시절에는 딱 한 번, 워드패드도 실행될 때 스플래시 화면이 잠깐 나타나던 적이 있었다. 그 자그마한 프로그램에도 말이다.;; 물론 98과 그 이후부터는 싹 없어졌고 다시는 부활하지 않았다.
오늘날 마소 제품들 중에 Office나 Visual Studio 같은 건 실행될 때 스플래시 화면이 뜬다. 그런데 과거에 비해 중요한 변화가 생긴 게 있다.

옛날 버전들은 스플래시 화면에다가 마우스 포인터를 가져가면 모래시계 모양으로 바뀌었다.
그러나 Office는 2010부터, VS는 2012부터.. 마우스 포인터를 가져가도 모래시계가 아니라 일반 화살표 모양이 유지되며, 스플래시 화면을 마우스로 드래그 하면 그 화면을 딴 데로 이동시킬 수도 있다.

즉, 스플래시 화면에 대한 사용자 반응성을 더 개선한 것이다. 스플래시 화면이 들어갈 정도로 방대한 소프트웨어를 개발하는 분이라면 이런 면모도 생각해 볼 필요가 있다. 뭐, 본인이 개발하고 있는 날개셋 한글 입력기는 스플래시 화면이 필요할 정도로 방대한 프로그램이 전혀 아니기 때문에 해당사항이 없다.

8. ESC 또는 Alt+F4

Visual Studio는 '닷넷'으로 바뀌었던 200x 버전 시절부터 '시작 페이지'라는 것을 제공해 왔는데, 2019부터 이걸 그냥 대화상자로 대체했다. 그런데 이거 동작 방식이 꽤 재미있다.
대화상자를 ESC를 눌러서 닫으면 프로그램 실행이 계속 진행되어 정식 IDE 창이 뜬다. 하지만 대화상자를 Alt+F4 또는  [X] 버튼 클릭으로 종료하면.. 프로그램이 통째로 종료된다. 이 차이점을 눈치 챈 분 혹시 계시는가?

Windows에서 ESC와 Alt+F4는 차이점이 매우 미미하다. 대화상자를 '취소'로 닫을 수 있는 건 공통인데 후자는 전자의 상위 호환으로, 프로그램 main 창을 종료하고 시스템 종료까지 가능하다는 차이가 있을 뿐이다.
그리고 프로그램의 대화상자는 자신이 ESC로 닫혔는지 Alt+F4로 닫혔는지 같은 걸 일반적으로 분간할 수 없다. WM_CLOSE 내지 IDCANCEL 메시지가 오는 건 동일하기 때문이다.

그런데 굳이 둘을 구분해서 동작한다니.. by design인 걸까?
지금 메모장에서 파일을 저장하지 않고 종료했을 때 나타나는 "....를 저장할까요?" 메시지 대화상자를 Alt+F4로 닫으면 ESC로 닫았을 때와 달리 저장 대화상자가 뜬다. 이는 메시지 대화상자가 MessageBox가 아닌 TaskDialog 기반으로 바뀐 10여 년 전 Windows Vista 때부터 생긴 버그인데, 아직까지도 여전하고 고쳐지지 않았다..;;

ESC와 Alt+F4의 동작이 다른 프로그램을 메모장 이후로 처음으로 하나 더 발견하게 됐다.

9. 버전 넘버링

마소는 1990년대부터 2000년대까지는 Windows, Office, Visual Studio 같은 제품을 버전업할 때마다 외형 비주얼도 그야말로 널뛰기 하듯이 바꾸는 게 유행이었다. 그러나 2010년대 중후반부터는 이제 어지간히 만들 것들은 다 만들었는지 그런 유행이 사실상 끝났다.

그리고 버전 번호도 옛날처럼 과감하게 성큼성큼 올라가지 않고 있다. 글쎄, 웹브라우저들은 크롬의 주도 하에 버전이 자비심 없이 막 올라가는 중이지만 마소 제품들은 그렇지 않다. 다음 사례들을 생각해 보라.

  • Windows: 잘 아시다시피 지난 2015년부터 주 버전 및 브랜드는 Windows 10으로 고정돼 버렸으며, 이제는 연도/월이 기재된 별도의 하위 버전만 올리고 있다. (그래도 서버 제품군의 경우, 2016에 이어 2019를 따로 내놓은 듯하던데.. 연도 기반 네이밍의 의미가 많이 퇴색했다.)
  • Office: 2016과 2019, 그리고 365까지 모두 16.x 버전으로 동일하다.
  • Visual Studio: 최신 2019는 버전 번호가 Office와 마찬가지로 16.x이다. 그리고 내부적으로 통용되는 _MSC_VER 값은 2015까지는 100씩 증가해서 1900에 도달했지만, 다음 2017은 1910, 2019는 1920이 되어서 10씩만 증가하고 있다.
  • .NET Framework: 10년 전인 2010년에 4.5가 나왔지만 10년째 4.x 버전을 졸업하지 않고 있다. Windows 10과 함께 4.6이 나왔고 최신 버전에서도 그냥 4.8대이다.
  • DirectX: Windows 10과 함께 버전 12.x가 나왔으며, 12라는 숫자가 앞으로 더 올라갈 것 같지는 않다.
  • Internet Explorer, Media Player: 얘들은 최소한의 보안 패치만 하지 후속 개발 자체가 중단된 레거시이다. 버전 역시 각각 11, 12에서 멈추고 봉인됐다.

지난 2~30년 동안 PC용 소프트웨어들은 기술이 하도 많이 발전하고 상향평준화하다 보니.. 그냥 무료 서비스 아니면 기간제 구독형으로 바뀌는 추세인 것 같다. 그래서 MS Office도 이제 20xx 같은 연도가 붙은 정규 릴리스 대신 슬슬 구독형을 밀고 있으며, Adobe의 비싼 그래픽 툴들도 진작에 구독형으로 바뀌었다.
Visual Studio는 기본적인 IDE와 컴파일러의 경우, 인디 개발자를 대상으로는 사실상 완전히 무료로 풀렸고, 일정 규모 이상의 인원을 갖춘 기업을 대상으로만 유료이다.

소프트웨어가 구독형으로 바뀌었으니 새 버전 출시와 업데이트도 예전보다 훨씬 더 자주 부담 없이 수시로 행해진다. 거창하게 서비스 팩이니 뭐니 하는 것도 필요하지 않다. Visual Studio만 해도 예전엔 상상도 못 할 정도로 시도 때도 없이 업데이트를 하라고 뜬다. 16.5.0 다음으로 16.5.1 같은 식..
이런 추세와 달리, 한 카피당 사용권 얼마 같은 전통적인 방식으로 유료 소프트웨어를 end-user에게 판매하는 개발자· 개발사와 제품들이 앞으로 얼마나 더 남아 있을지 궁금하다.

Posted by 사무엘

2020/08/14 08:35 2020/08/14 08:35
,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1784

1. 독특한 윈도우 클래스

Windows의 GUI에는 버튼, 리스트박스, 에디트 컨트롤 등의 잘 알려진 제1군 컨트롤 윈도우들이 있고, 공용 컨트롤이라는 제2군 윈도우도 있다. 이런 것들은 누구나 널리 사용하라고 클래스 이름도 널리 알려져 있다.
그런데 Spy++로 들여다보면, 정식으로 공개되지 않았지만 이런 클래스들이 공용으로 쓰이는 것 같다. 정체가 무엇인지 궁금하다.

  • NetUIHWND: MS Office 프로그램들, 그리고 심지어 워드패드와 그림판에서도 리본이 이 클래스 이름으로 만들어져 있다. 마소에서만 내부적으로 사용한다. (Visual C++의 MFC 확장판에서 제공되는 리본은 마소 오리지널이 아님)
  • DirectUIHWND: task dialog 내부, IE 브라우저의 탭, 탐색기 제어판에서 뭔가 웹페이지처럼 꾸며진 대화상자들에서 종종 쓰인다. 클래스 스타일에 CS_GLOBALCLASS도 버젓이 지정돼 있다. 마소 내부에서 사용하는 GUI 엔진 윈도우 같은데..
  • HwndWrapper[모듈이름;;GUID]: 닷넷이나 WPF처럼 통상적인 Windows API나 기성 컨트롤이 아닌 다른 프레임워크를 이용해서 GUI를 꾸미는 프로그램 같다. 내가 아는 프로그램 중에는 Visual Studio 2010과 그 이후 버전, 그리고 아래아한글(+ 타 오피스 제품 포함) 요 두 프로그램만이 이런 스타일이다.

2. 파일 및 디렉터리의 삭제, 디스크 제거

Windows는 프로그램을 memory-mapped file 형태로 불러온다는 특성으로 인해.. 실행 중인 프로그램을 삭제할 수 없다. 그래서 실행 중인 프로그램을 제거하거나 업데이트 하는 것도 좀 어려운 편이다.
실행 중인 프로그램 파일을 '개명'하는 건 가능하다. 여기서 개명이란 같은 드라이브 안에서의 디렉터리 이동도 포함한다.

이런 Windows와 달리 macOS나 리눅스는 실행 중인 프로그램 파일을 삭제할 수 있다.
허나, 실행 중인 프로그램의 current directory를 당장 삭제할 수 있는 운영체제는 내가 아는 한도 내에서는 없다. 삭제 예약만 해 놓은 뒤, 프로그램이 종료되거나 디렉터리가 딴 데로 바뀌었을 때 삭제되는 게 그나마 제일 관대한 처분이다.

프로세스의 current directory는 USB 메모리를 안전하게 제거할 수 없다고 운영체제가 꼬장 부리면서 사용자를 귀찮게 하는 요인 중 하나이기도 하다.
특히 Windows의 경우, 파일 열기/저장 공용 대화상자를 열어서 USB  메모리를 조회하면 해당 프로그램의 current directory도 거기로 바뀌기 때문에 대화상자를 닫은 뒤에도 저런 꼬장이 발생할 가능성이 높아진다.

뭐, 사용자가 USB 메모리를 물리적으로 강제로 제거해 버리는 것에는 장사 없다. 과거의 디스켓이나 광학 드라이브도 매체를 강제로 꺼낼 수 있었으니 말이다. 하지만 이런 일이 발생하면 운영체제의 관점에서는 current directory가 갑자기 없어지는 것이나 다름없고, 거기에 파일이 열려 있던 것들도 다 꼬여 버린다. 프로세스가 아닌 스레드를 강제 종료하는 것만큼이나 좋지 않은 현상이다.
디스크 내용을 날리고 싶지 않으면 사용자도 가능한 한 그런 짓은 하지 않는 게 좋다.

3. Windows의 런타임 환경

Windows에서 전통적인 API 기반의 네이티브 코드 데스크톱 프로그램 말고 선보였던 프로그램 실행 환경으로는..
먼저 2000년대(XP..)엔 .NET이란 게 있었다. 얘는 네이티브가 아니라 가상 머신에서 돌아갔고, 언어도 C#가 주류였다. C++에는 C++/CLI라는 변종 언어가 도입됐다.
그 뒤 2010년대(8..)엔 메트로 UI와 함께 C++/CX라는 변종 언어가 도입됐다. 얘는 데스크톱 환경은 아니지만 의외로 네이티브 코드 기반이었다.

.NET이 표방했던 것이 언어의 통합이라면, Windows 8이 표방했던 것은 기기(PC와 모바일?)의 통합이었다. 그래서 오죽했으면 시작 버튼을 없애는 초강수까지 뒀었다.
그러나 Windows 8은 망했으며, 결정적으로 Windows Phone/Mobile도 안드로이드와 iOS에 완전히 밀렸다. 이젠 마소에서도 그쪽 사업을 접었다. 그 대신 Windows 10은 ARM용이 정식으로 출시되어서 그 CPU에서 네이티브 데스크톱 앱을 그대로 돌릴 수 있게 됐다.

그럼 이 와중에 메트로 앱을 돌리는 Windows Runtime이라는 건 무슨 존재의 의미를 갖게 되는지 난 궁금하다. 답을 잘 모르겠다.
그냥 데스크톱 앱보다 글자 큼직하고 시각적으로 flat하고, 안드로이드 용어로 치자면 material design스러운 외형을 제공하는 GUI 엔진 그 이상도 이하도 아니어 보이는데..??
쉽게 말해 기존 공용 컨트롤이 '제어판'을 가동한다면 이 UI 엔진은 '설정'을 가동한다는 것이다.

마소에서 새로운 걸 시도한 것이 언제나 다 성공적이고 오래 유지된 건 아니었던 듯하다.
그래서 GDI+는 닷넷 시절에 잠깐 뜨다가 Direct2D 부류로 대체됐고, 오히려 운영체제의 근간으로서 넘사벽급의 짬밥을 자랑하는 재래식 GDI보다도 존재감이 없어졌다.
Edge 브라우저는 잘 알다시피 재개발되어서 사실상 크롬과 다를 바 없는 브라우저가 됐다. 마소의 지난 20여 년의 개발 트렌드를 회고해 보니 이런 분석과 결론이 나온다.

4. 이모지, 날개셋 입력 패드

Windows 10의 1803버전쯤부터는 win+.을 눌러서 이모지 문자표를 꺼내는 기능이 추가되었다.
날개셋 한글 입력기에서는 지난 9.81 버전부터 자체적으로 이모지 문자표가 추가되었다. 그럼 이건 언뜻 보기에는 기능 중복처럼 보이지만 실제로는 꼭 그렇지 않다.

운영체제의 이모지 문자표는 마우스로 딴 델 클릭하기만 해도 사라져 버리는 반면, 날개셋의 입력 도구는 그렇지 않다. 더구나 결정적으로 이 문자표는 날개셋 편집기에서 자체 입력기를 지정해 놓았을 때는 사용할 수 없다.
그리고 내 프로그램에서는 선택된 이모지를 복사하기, 그리고 cursor가 가리키는 이모지를 문자표에서 찾아서 역으로 표시하기 같은 기능도 갖추고 있다.

예전에도 언급했듯, 2018~19년에 걸쳐 추가된 ‘필기 인식’과 ‘이모지’는 날개셋의 고유 기능이 아니라 운영체제가 제공하는 기능을 자체적인 UI 껍데기를 씌워서 제공하는 대표적인 입력 도구이다. Full feature를 갖춘 한글 IME로서 저런 기능도 한 프로그램 내부에서 제공할 필요가 있기 때문이다.

뭐 그건 그런데.. 운영체제에서 기본 제공하는 이모지 문자표는 응용 프로그램에다가 어떤 방식으로 이모지 문자를 보내는 걸까? 그게 갑자기 궁금해졌다. 쟤는 기술적으로는 ‘날개셋 입력 패드’과 비슷하게 훅킹을 사용해서 IME 메시지를 보낼 것 같은데..

프로그램이 TSF를 감지하는지 여부를 따져서 지원하면 TSF 방식으로 문자를 보내고, 그렇지 않으면 기존의 IME 메시지를 보낸다는 것을 확인할 수 있었다. IME 메시지만을 사용하는 날개셋 입력 패드보다 더 고차원적이다. 사실, TSF를 지원해야만 메트로 앱에서도 이모지를 입력할 수 있을 것이다.

날개셋 입력 패드를 처음 개발하던 시절에 본인도 개인적으로는 TSF 방식을 뚫어 볼까 생각을 했었다. 이게 성공하면 외부 모듈뿐만 아니라 입력 패드도 편집기와 비슷하게 주변 문자를 자유자재로 변형하면서 신기한 기능을 제공할 수 있다.

그러나 외부 모듈 하나만 개발해 봐도 내 경험상 TSF는 기술 난이도가 헬이고 응용 프로그램별로 제멋대로 동작하는 구현의 파편화가 너무 심하다. 더구나 그 TSF의 혜택을 보는 프로그램은 매우 소수이며, 편집기와 외부 모듈 다음으로 입력 패드 자체도 사용 빈도가 매우 낮은 제3군의 실험적인 유틸일 뿐이다.

그렇게 TSF를 뚫어 봤자 훅킹은 어차피 메트로 앱에서는 통하지도 않기 때문에 그 단계에서 막히니..
시간과 노력 대비 타산이 맞지 않는다는 결론을 얻어서 그 이상의 연구는 포기했다. 입력 패드는 write-only인 IME 프로토콜만 사용하는 데스크톱 앱 전용 프로그램으로 굳어져서 오늘에 이르고 있다.

5. 유니코드 5.2 자모

아시다시피 지난 10여 년 전에 KS X 1026-1 및 유니코드 5.2에서 옛한글 자모가 여럿 추가되었다. 시기가 시기이다 보니 연속된 공간을 쭉 확보하지 못하고 덕지덕지 지저분하게 추가되었지만, 그래도 잘 살펴보면 프로그래머의 관점에서 복잡함과 불편함을 최소화하는 방식으로 추가되었음을 알 수 있다.

답부터 말하면, 어떤 글자가 한글 초성인지 중성인지 종성인지 판별하기 위해 과거(유니코드 1.1)에는 A<=X<=B라는 영역 검사 하나만이 필요했다. 이제는 그래도 그 영역 검사가 각 성분별로 하나씩만 더 추가되면 된다.

  • 초성은 U+1100부터 1159까지 하던 영역에서 끝부분을 115E로 늘린 뒤(5개 추가), A960부터 A97C라는 새로운 영역 한 곳만 더 살펴보면 된다.
  • 중성은 U+1160부터 11A2까지 하던 영역에서 끝부분을 11A7로 늘린 뒤(5개 추가), D7B0부터 D7C6이라는 새로운 영역을 더 살펴보면 된다.
  • 종성도 그런 식으로 기존 영역을 조금 확장하고 나서 새로운 영역을 더 살펴보면 된다.

잘 알려져 있지 않지만, KS X 1026-1은 종성에 ㅇ으로 시작하는 겹받침(ㅇㄱ, ㅇㄲ, ㅇㅇ, ㅇㅋ)을 그냥 이응이 아닌 옛이응으로 수정한 규격(잠수함 패치..)이기도 하다.

그리고 KS X 1026-2는 정규화 규칙을 추가로 규정해서 현대 한글을 옛한글 자모의 조합으로 표현하는 것을 금지하고, 현대 한글 글자마디와 옛한글 자모가 합성되는 것도 명시적으로 금지했다. 한 한글은 오직 한 가지 방식으로만 표현되게 했다.
Windows는 2012년에 나온 8부터 저게 반영됐고, 날개셋 편집기에서는 지난 2015년에 나온 8.0 버전에서야 반영됐다. 저 표준을 제정한 분과 개인적으로 얘기까지 나누며 설명을 들은 뒤에야 말이다. 엇, 그러고 보니 둘 다 8부터네?!?

유니코드 2.0에서 한글 글자마디 11172자를 따 온 건 예전에 서울 올림픽 유치 성공만큼이나 역사에 길이 남을 위대한 쾌거였다. 현대 한글이 그렇게 정립된 뒤에 옛한글도 저렇게 됨으로써 한글 코드 논란은 완전히 종식됐다.

그 뒤로 유니코드 자체도 2003년쯤이던가 4.0에서 U+10FFFF라는 상한을 명확하게 정하고, 이 이상 글자를 더 등록하지는 않을 것이라고 못을 박았다. 그 이상은 UTF-16으로는 더 표현할 수가 없기 때문이다. 그래서 UTF-8도 4바이트 방식까지만 사용하고 5~6바이트 방식은 봉인했다.

따라서 현재 유니코드에 정의된 모든 평면이 고갈되고 글자들로 꽉 차는 날이 온다면.. 유니코드 위원회는 해산될 것이다. 지금의 문자 코드 체계는 지구와 현 인류 문명이 송두리째 멸망하지 않는 한 쭉 이어질 것으로 보인다.

Posted by 사무엘

2020/07/14 19:32 2020/07/14 19:32
,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1773

1. 16색 팔레트

과거에 컴퓨터에서는 컬러를 표현할 수 있긴 하지만 해상도가 낮고 색깔수도 아주 제한됐던 시절이 있었다. 특히 고해상도라는 게 기껏 640*480이었고, 이 해상도에서는 표준 VGA 기준으로는 겨우 16색밖에 표현할 수 없었다. 1980년대 말에는 가로· 세로의 픽셀수가 모두 8비트 범위를 벗어난 것만으로도 고해상도라는 소리를 들었던 듯하다.

16색으로 가장 균형 잡힌 색상 팔레트를 꾸미는 방법은 뭐 뻔하다.
RGB 각 축별로 0, 1 조합을 시켜서 검정부터 하양까지 2^3 = 8색을 만들고, 이것보다 한 단계 더 밝은(혹은 어두운) 8색을 추가해서 16색을 만들곤 했다. 기본색 8색은 적록청과 흑백, 그리고 혼합된 색인 청록, 분홍, 노랑이다.

제일 단순하게 생각하면.. 어두운 그룹에서 비트별 on/off는 각각 128/0을 배당하고, 밝은 그룹에서 on/off야 최대치인 255/0을 배당한다.
다만, 0~15까지의 16색 중에서 7번(어두운 그룹의 가장 밝은 색)과 8번(밝은 그룹의 가장 어두운 색)은 각각 밝은 회색과 어두운 회색인데 얘는 예외적으로 각각 (192,192,192)와 (128,128,128)로 간주한다. 이렇게 하지 않으면 7번 색이 어두운 회색이 되고, 8번 색은 0번 검정(0,0,0)이 중복 배당되기 때문이다.

요게 바로 산술적으로 제일 단순하게 유도되는 팔레트이다.

사용자 삽입 이미지

하지만, 도스 시절에 EGA/VGA 그래픽 카드가 실제로 제공했던 기본 16색은 이와 대동소이한 차이가 있었다.
(1) 먼저, 어두운 그룹의 가중치가 128이 아니라 170 (0xAA)이어서 전반적으로 저것들보다 더 밝았다. 난 168인 줄로 오랫동안 알고 있었는데, 지금 다시 찾아보니 그렇지 않고 170이다. 최대치인 255의 정확히 2/3에 해당하는 값이다. 어째 256은 2의 8승이지만, 255는 3의 배수였구나.

(2) 그리고 밝은 그룹이야 on의 가중치는 응당 255이지만, off의 가중치가 0이 아니라 85이다. 그래서 밝은 파랑도 그저 (0,0,255)가 아니라 (85,85,255)이다. 앞서 언급된 단순 팔레트가 0 1/2 1로 색깔을 쪼갰다면 얘는 더 세분화해서 0 1/3 2/3 1을 추구한 셈이다.
이 체계에서는 따로 보정을 하지 않아도 7번은 산술적으로 자연스럽게 (170,170,170)이라는 밝은 회색이 되고, 8번은 (85,85,85)인 어두운 회색이 된다. 다른 색들은 전반적으로 단순 팔레트보다 더 밝지만, 회색은 어째 단순 팔레트보다 더 어두워졌다.

(3) 또한 VGA 팔레트는.. 구체적인 이유는 알 수 없지만 6번 색을 산술적인 (170,170,0) 어두운 노랑? 올리브색 대신, (170,85,0)으로 예외적인 변화를 줬다. 올리브색 대신 갈색을 만든 것이다. 노랑은 원래 밝은 색인데 어두운 노랑은 정체성이 모호하니.. 갈색이 더 실용적일 거라고 생각했던 모양이다.
그래서 VGA 팔레트는 단순 팔레트보다 약간 더 알록달록하고 채도가 높아졌다.

사용자 삽입 이미지

끝으로, Windows도 독자적으로 약간 변화를 준 16색 팔레트를 사용했다.
밝은 그룹은 255/0으로 간단하지만 어두운 그룹이 상황이 약간 복잡하다. on의 가중치는 170인데, off의 가중치는 0과 85가 뒤섞인 편이다.

파랑은 깔끔하게 (0,0,170)이지만 빨강과 초록에는 파랑이 반 정도 섞여서 각각 (170,0,85)와 (0,170,85)이다.
혼색인 cyan과 분홍, 올리브에도 색이 full로 들어가지 않은 나머지 축에는 0이 아닌 85가 들어간다. VGA와 달리 갈색 보정은 없고 올리브색은 (170,170,85)이다.

의외인 것은 7, 8번 회색들이다. 각각 (195,199,203), (134,138,142)로, RGB 값이 모두 근소하게 다른 별개의 가중치가 부여돼 있다. 흑백과 더불어 화면에서 제일 많이 보게 될 중립 무채색이니 나름 심혈을 기울여 이런 색을 만들었지 싶다.

사용자 삽입 이미지

지금까지 소개된 팔레트 세 종을 한데 늘어놓고 비교하면 다음과 같다.
Windows 팔레트는 밝은 그룹은 단순한 팔레트와 비슷하고, 어두운 그룹은 갈색 보정 여부만 제외하면 VGA 팔레트와 더 비슷하다고 볼 수 있다.

사용자 삽입 이미지

Windows의 경우, 고전 테마 GUI나 명령 프롬프트에서 기존 VGA 16색을 표시할 일이 있을 때 256색/high/true 컬러일 때는 128/255 기반의 단순 팔레트를 사용한다. 그러나 16색일 때만은위와 같이 약간 더 밝아진 팔레트를 사용한다.
그래서 똑같은 색상표를 사용하더라도 16색이다가 상위 색상으로 모드를 바꾸면 화면이 더 어둡고 차분하게 착 가라앉은 듯한 느낌이 든다. 흥미로운 점이다.

사용자 삽입 이미지

2. 256색 VGADemo

1990년대 초· 중반에 도스에다 Windows 3.1 정도나 설치돼 있던 컴에서는 일반적으로 util\tool이라는 디렉터리가 있었고, 여기에 각종 파일 압축 프로그램, 하드디스크 파킹, 파일 관리 셸 등 단독으로 돌아가는 자잘한 싸제 유틸리티들이 들어있곤 했다. 어느 디렉터리에서나 실행 가능하게 path도 걸려 있고 말이다.

그때 본인의 컴퓨터에 들어있었던 '툴' 프로그램 중에는 com인지 exe인지는 기억 안 나지만 vgademo라는 자그마한 프로그램도 있었다.
게임이 아니면서 VGA 320*200 256색 13h 모드로 진입해서 완전 현란한 팔레트 스크롤과 함께 선과 폴리곤, 원 그리기 따위를 선보이는 2D 그래픽 데모였다.

사용자 삽입 이미지

맨 처음에는 저렇게 동그란 그러데이션 형태의 인트로 화면이 나온다. 이때 space를 누르면 본 게임(?)이 시작된다.
한참 알아서 그림을 그리다가 일정 주기로 씬이 자동으로 바뀐다. 그럼 기존 화면은 fadeout 되기도 하고 모자이크 처리되면서 사라지기도 했다. (모자이크가 점점 더 커짐)

사용자 삽입 이미지

이거 단순히 난수 생성해서 아무렇게나 선을 찍찍 그어대는 게 아니다. 여러가지 그리기 시나리오와 화면 전환 조건, 무작위한 팔레트 스크롤 방식 등에 대해 나름 치밀한 설계가 필요하다.
CGA, EGA만 구경하다가 VGA에서 게임도 아니면서 이런 그래픽을 뿜어내는 프로그램을 PC에서 접했을 때 사람들이 적지 않게 놀랐지 싶다. 1990년대 초에 말이다. 해상도를 극도로 희생했지만 256색을 표현할 수 있게 된 덕분이다.

누가 언제 만든 무슨 이름의 프로그램이었는지 알 길이 없었는데.. 검색을 통해 razzle dazzle이라는.. 바로 요놈이라는 것을 나중에 파악할 수 있었다.
나름 셰어웨어 형태로 돈 받고 팔았고, 90년대 말까지 개발이 됐던 프로그램이었다. 그 시절에 유행했던 프로그램  장르인 눈요기 화면 보호기로는 꽤 적합했지 싶다.

Posted by 사무엘

2020/06/11 19:35 2020/06/11 19:35
,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1761

« Previous : 1 : 2 : 3 : 4 : 5 : ... 12 : Next »

블로그 이미지

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

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2021/09   »
      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:
1652283
Today:
122
Yesterday:
436