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

지금으로부터 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 사무엘

오늘날처럼 컴퓨터의 문자 인코딩이 유니코드로 천하통일이 되기 전엔 국내에서는 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 사무엘

본인에게 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 사무엘

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

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

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

1. 에러 메시지의 친근성

먼 옛날 도스 시절에는 명령 프롬프트에서 파일 이름이나 명령을 잘못 입력하면 갖가지 에러 메시지들을 볼 수 있었다. 제일 흔한 건 Bad command or file name... 아무말이나 입력하고 엔터 누르면 볼 수 있으니 말이다.
오늘날 Windows의 명령 프롬프트에서 XXXX is not recognized as an internal or external command, operable program or batch file이라고 정말 길고 정황하게 나오는 그 메시지가 옛날에는 저렇게 간결하고 무뚝뚝하게 나왔던 것이다. bad가 뭐냐 도대체.. ㅡ,.ㅡ;;

유닉스 계열만 해도 XXX: command not found 내지 XXX: no such file or directory로 나뉘어 있으나.. 도스는 그 특성상 파일 실행과 명령의 구분이 없는 관계로, 단일 메시지에 파일과 명령을 모두 포함해야 했던 것이다.
그런데.. 그렇게 문장 한 줄만 뜨고 아무 뒤끝 없이 프롬프트로 돌아오는 에러와 달리.. 어떤 에러는 Abort? Retry? Ignore? 이러면서 사용자를 물고 늘어지고 놔 주질 않았다. 이게 초딩 시절엔 굉장히 무섭고 강압적으로 느껴졌다.

이런 무서운 에러는 디스켓과 관련해서 자주 볼 수 있었다. 드라이브에 디스켓을 넣지 않은 상태에서 A: 같은 드라이브 변경을 시도했거나.. 아니면 디스켓 파일을 복사하던 중에 오류가 발생했을 때도 저런 사태가 벌어졌다. 디스크 에러와 데이터 에러라는 게 있었는데, 둘의 차이는 지금 생각해 봐도 오리무중이다.

위의 그림은 도스/Windows 9x vs 오늘날 NT 계열 Windows에서 각각 디스크 없이 FDD 드라이브 전환을 시도했을 때의 에러 메시지의 모습이다.
아 옛날에는 ignore이 아니라 fail이었구나... 아무튼 저런 차이가 있었다는 것이다.
옛날에는 디스켓이 거의 복불복 지뢰밭 수준으로 오류가 잦았으며, 일반 프로그램이 파일을 읽고 쓰다가 지뢰를 밟지 않도록 주기적으로 표면 검사를 해서 bad sector 기입을 해 주는 게 필수이기도 했다.

사실, 시스템 전체의 관점에서는 에러가 이런 식으로 발생하는 게 효율적이다. 무작정 실패 판정만 내리고 끝나는 게 아니라 말 그대로 디스켓을 집어넣을 기회를 다시 준다거나, 오류를 무시하고 일단 더 진행한다거나.. 그러는 게 더 유도리가 있으며, 사용자 친화적이기까지 하다. 사용자가 모든 경황을 아는 전문가라면 말이다.

하지만 초보자의 입장에서는 저런 말이 뜨면 뭘 해야 할지를 모르고, 그냥 다 끄고 명령을 내리기 이전 상황으로나 돌아가고 싶을 것이다. 그런데 저놈의 메시지는 Ctrl+C고 ESC고 뭘 눌러도 없어지질 않고.. UI 측면에서 좀 미스인 건 사실이다.

게다가 말들이 표현이 아주 세고 기계적이고 부정적이다. Abort는 무슨 약속 예약 취소 같은 걸 넘어서 하던 걸 다 때려치우고 철회, 중단한다는 뜻이다. 오죽했으면 낙태라는 뜻까지 있다. Ignore도.. 무시, 묵살, '씹기', 생까기 같은.. 절대로 좋은 어감이 아니다.

물론 어떤 장애물에 부딪혀서 일이 진행되지 않았을 때, 그냥 포기하거나, 한번 더 시도하거나, 그 장애물을 일단 제끼고 넘어가는.. 세 가지 방법 중 하나로 의사결정을 하는 것은 일상생활에서 존재하며 필요하다.
DOS가 없어지고 Windows로 바뀐 오늘날까지도 본인이 프로그래머로서 저 패턴의 메시지를 보는 것은 디버깅 중인 프로그램이 뻗었을 때.. 더 구체적으로는 assertion failure가 났을 때이다. Retry가 디버거 실행과 연결된다.

Windows 2000/ME에서는 Abort/Retry/Ignore(중단/다시 시도/무시 MB_ABORTRETRYIGNORE) 대신, Cancel/Try again/Continue(취소/다시 시도/계속 MB_CANCELTRYCONTINUE)라고 말이 다소 부드럽게 바뀐 메시지 박스가 등장했다. 기존의 표현이 바뀌지는 않았으며, 새로운 플래그를 사용하는 프로그램에서만 새로운 표현을 볼 수 있다. 사실, A/R/I라는 단축키가 도스 시절 이래로 아주 익숙하며, 새로운 표현은 CTC로 이니셜이 겹치기도 하니 말을 일괄적으로 변경해 버리는 건 좀 부담스럽기도 했을 것이다.

그런데 MessageBox의 리턴값까지도 IDRETRY와 별도로 IDTRYAGAIN을 추가하고 IDIGNORE뿐만 아니라 IDCONTINUE도.. 이름뿐만 아니라 값까지 서로 별개로 추가해 버린 것은 의외이다. 두 쌍은 용도가 완전히 동일한데도 말이다.
참고로 MessageBox의 후신격인 TaskDialog에는 표준 버튼으로 '재시도 try again'만이 도입되었고, ignoer/continue는 포함되지 않았다. 기존의 확인/닫기/취소 등으로 보편적인 의사결정은 다 표현할 수 있다고 간주한 듯하다.

지금이야 Cancel/Try again/Continue가 첫 등장한 지도 20년 가까이 지났다. 컴퓨터 대신 PC, 디바이스라고 하고 응용 프로그램도 그냥 앱이라고 하는 세상이다. 게다가 이제는 전통적으로 무뚝뚝함과 충격과 공포 그 자체이던 패닉 BSOD화면에도 이모티콘과 한글 메시지가 표시되는 세상이 됐다. press any key의 번역은 "... 누르십시오" 대신 "... 누르세요"로 바뀌었다. 여러 모로 격식이 없어지고 말이 친근하게 바뀌고 있는 것 같다.

하지만 C/C++ 프로그램의 디버그 빌드에서 assertion failure가 났을 때, 무식한 A/R/I 메시지박스와 함께 "Press Retry to debug this application"이 뜨던 건.. 깔끔한 task dialog로 바뀌는 날이 올지 모르겠다.
end user는 볼 일 없고 어차피 개발자들이나 보는 메시지이니 아무도 신경 안 쓰려나? =_=

2. 반응성과 존재감

어떤 소프트웨어가 인터페이스 내지 반응성 관점에서 사용자에게 좋은 인상을 주려면 자잘하게 뻗는다거나 화면 잔상이 생기는 버그가 없어야 하고, 키· 마우스 입력에 대한 반응이 신속해야 할 것이다. 반응성을 보장하기 위해 필요하다면 스레드 같은 것도 적절하게 활용해야 한다. 어지간해서는 5초 이상 반응이 없어서 '응답 없음' 판정을 받는 일이 없어야 한다.

마우스로 창 크기를 변경했을 때 너무 굼뜬다거나, 화면 전체가 지워져서 번쩍거리면서 그려진다거나 하지도 않아야 한다. 새로 그리는 게 시간이 너무 오래 걸리는 게 있으면, 스크롤 내지 크기 변경 중에는 뼈대만 간략하게 그렸다가 키보드· 마우스 버튼이 놓였을 때 다시 그려도 좋다.

그런데.. 이런 것들과 반대로, 눈에 보이지 않고 백그라운드에서만 몰래 돌아가는 프로그램에도 지켜야 할 덕목이 있다.
사용자가 직접 명령을 내려서 실행된 게 아닌 서비스, 업데이트 체크 같은 부류의 프로그램이라면 정말 절대적으로 사용자의 눈에 띄지 않아야 한다.

컴퓨터의 성능을 떨어뜨리는 티를 절대 내지 말아야 한다.
요즘 컴터는 코어가 많으니 한 프로그램이 코어 하나를 다 점유한다고 해서 당장 속도가 느려지지는 않는다. 하지만 컴터를 열받게 할 수 있고 배터리 소모를 증가시킬 수 있고, 냉각팬이 쓸데없이 돌아가게 만들 수 있다. 특히 노트북에서 말이다.

업데이트를 받더라도 무슨 당장 안 받으면 컴퓨터가 악성 코드에 감염되어 박살나기라도 하는 울트라 초특급 필수가 아니라면 아주 쉬엄쉬엄 찔끔찔끔 받도록 하고, 네트웍 상태가 안 좋아서 발생하는 딜레이가 UI의 딜레이나 CPU 쳐묵 대기 상태로 절대로 이어지지 않게 해야 한다.

이는 음악회에서 넘돌이 넘순이(페이지 터너..;;)가 연주자보다 더 돋보여서는 안 되고, 무슨 집회에서 통역사가 연사보다 더 돋보이지 말아야 하는 것과도 같은 이치이다.
인터넷 연결이 안 된 곳에서 Windows Update 서비스라든가, 구글 크롬 브라우저의 software report tool이 도대체 뭔 짓을 하느라 CPU 코어를 다 쓰면서 날뛰고 있었나 모르겠다. 현재로서는 요 둘이 내 블랙리스트에 올라 있다.

컴퓨터 프로그램은 n초 이상 응답이 없으면 저렇게 다운 의심 판정을 받게 되고, 운전자는 교차로에서 파란불 신호를 받고도 n초 이상 응답 없이 움직이지 않으면 뒷차로부터 경적 세례를 받고 욕 먹게 된다. 개인적으로는 이게 서로 비슷한 양상의 현상인 것 같다.

3. 이식성

로터스 1-2-3, dBase III+ 같은 프로그램은 한때 시대를 풍미했던 명품 업무용 소프트웨어였다. 하지만 도스에서 Windows로 넘어가는 변화를 따라가지 못하고 그대로 도태해서 사라졌다.

내가 듣기로는 이 두 프로그램은 긴 짬밥답게 주요 코드가 쑤제 어셈블리어로 한땀 한땀 작성됐다고 한다. 덕분에 1980년대에 컴퓨터가 느리고 비싸던 시절에는 잘 최적화돼서 쌩쌩 돌아갔겠지만, 훗날 이 코드는 구조 확장이나 유지 보수가 도저히 안 되는 지경에 이르렀다고 한다. 특히 dBase가 말이다.

이래 가지고는 Windows로 포팅은 물론이고 같은 도스에서 32비트로 갈아타는 것조차도 쉽지 않았을 것이다. 현재의 하드웨어에서 돌아가지만 시간이 그 상태 그대로 멈춰 버린 코드는 그야말로 오늘만 사는 죽은 코드나 다름없다.

운영체제 중에서 Windows 9x야 저사양 똥컴 x86만 겨냥한 특이한 변종이니 어셈블리어 최적화가 없으면 안 됐고.. OS/2도 잘 만들어진 32비트 OS이긴 하지만 이식성이 부족했다. 훗날 64비트니 ARM이니에 전혀 대처하지 못하고 그대로 묻혀 버렸다.

그러나 유닉스처럼 C/C++을 처음부터 주력으로 사용한 Windows NT는 비록 처음에 나왔을 때는 너무 무겁고 느리다고 욕 먹었을지언정, 결국 여러 아키텍처들을 거쳐 오늘날까지 천수를 누리는 운영체제 커널이 됐다. 미래를 대비한 것에 대한 보상을 받은 것이다.

이런 게 이식성의 힘이다. 다만, 이 2020년대에는 이제 x86 계열과 ARM 계열 말고 또 획기적으로 새로운 컴퓨터 아키텍처가 설마 등장할 일이 있을까 싶다. ARM은 전력 효율이 x86이 범접할 수 없을 정도로 좋긴 하지만, 그렇다고 x86을 완전히 대체할 정도로 범용적인 성능이 좋은 건 아니다. 그러니 결국 이 두 아키텍처가 64비트 형태로 끝까지 갈 것 같다.

4. Windows와 맥이 추구한 가치의 차이

과거에 비해 텃새랄까 격차가 많이 줄긴 했지만 그래도 사과가 그려진 맥OS 컴퓨터는 예술, 출판, 디자인 업계에서 오늘날까지도 Windows보다 강세이다. UI 비주얼이 간지 날 뿐만 아니라, 같은 글꼴을 써도 글자의 렌더링이 정말 고퀄인 것을 부인할 수 없다.
그런데 그 분야 말고 게임은.. 특히 모바일용 말고 PC용은 맥 진영이 절대 범접하지 못할 정도로 Windows가 강세이다.

물론 게임은 애초에 특정 업계 종사자만 쓰는 업무용 생산성 앱이 아니며, Windows는 게임을 즐기는 end user 고객의 점유율이 압도적으로 높은 운영체제이다.
오늘날의 결과만 놓고 보면 저런 점유율이 당연히 저절로 이뤄진 것 같지만 사실은 그렇지 않았다. 먼 옛날에 IBM 호환 PC라는 물건은 동시대의 다른 컴퓨터들에 비해 사용자의 눈과 귀를 현혹시키는 기술에는 그렇게 관심을 두지 않았었기 때문이다.

지금으로서는 믿어지지 않지만 한때 Windows 같은 멀티태스킹에 하드웨어 추상화가 갖춰진 복잡한 환경에서 현란한 게임은 어림도 없는 일이었다. 그렇기 때문에 1990년대 중반까지만 해도 PC용 게임은 하드웨어 자원의 독점이 가능한 도스용으로만 나왔다.

그리고 90년대 중반, Windows 95는 바로 이런 배경에서 출시되었다.
빌 게이츠는 가히 목숨을 걸고 Windows를 게임과 멀티미디어에 최적화된 홈 엔터테인먼트 운영체제로 만들려고 애썼다. 구닥다리 WinG로는 성이 안 차고 OpenGL은 그 시절엔 아직 업무용에다 NT의 전유물이었으니.. 거기서도 하드웨어 직통 액세스가 가능한 DirectX를 만들고 게임 개발을 위해 물심양면 지원을 했다. Doom을 만들어 냈던 이드 소프트웨어를 인수할 생각까지 했던 것도 유명한 일화이다.

이런 마소 진영에 비해, 맥은 클래식 시절이건 OS X의 개발 초창기이건 잡스 아저씨가 저렇게 게임에 눈독을 들였다거나, Doom을 자기 맥OS에서 꼭 구동하고 말겠다고 나선 적이 없다. 빌처럼 가정 소비자들의 취향을 저격하는 방법, 시장에서 팔리는 제품을 만드는 방법을 기를 쓰고 연구하기보다는 그냥 자신의 천재적인 감과 괴팍· 고상한 취향을 따라 제품을 만들었다. 다수의 보편적인 소비자보다는 소수의 골수 매니아 애플빠를 양성하는 노선을 추구한 듯하다.

5. 설치/배포 패키지

Windows Installer (msi)라는 기술이 개발된 게 20여 년 전 1999~2000년 사이의 일이다.
소프트웨어의 설치와 제거라는 게 '파일 열기/저장 대화상자'만큼이나 응용 프로그램들이 공통으로 요청하고 수행하는 기능이니, 이를 위한 공통의 API를 정의하고 만든 것은 일면 바람직한 일이다.

하지만 얘는 2009~2010년 정도까지 버전업이 되었다가 그 뒤부터는 이렇다 할 변화가 없는 것 같다. 2010년대부터는 마소에서도 Office나 Visual Studio 같은 제품을 배포할 때 msi를 사용하지 않는다. 또 자신들만의 독자적인 설치/제거 시스템을 개발하기라도 한 것 같다.

통상적인 배포 패키지 시스템이라면 프로그램의 구성요소들을 세부적으로 나눠서 지금 당장은 사용자가 원하는 부분만 설치하고, 설치하지 않은 기능은 나중에 언제든지 추가 설치 가능하게 되어 있다.
그런데 2010년대 이후의 배포 패키지 시스템이라면 적어도 두 가지 요소를 반드시 지원해야 할 것 같다.

(1) 먼저, 웹을 통한 설치이다. 지금 로컬 installer 실행 파일에 내장된 데이터가 아니라 지정된 주소를 통해 서버로부터 데이터를 받아서 설치하는 것이다.

그리고 (2) 요즘 프로그램들의 거의 필수 기능이 된 최신 버전 체크 및 자동 업데이트와의 연계이다. 현재 버전과 최신 버전을 비교하여 부분만 자동 업데이트가 가능한지 판단하고, 꼭 바뀌어야 하는 분량만큼만 다운로드를 한다.
설치 후에 마이너 버전이 바뀐 것은 '프로그램 추가/제거' 목록에도 당연히 반영된다.

Windows Installer가 웹 연계 내지 자동 업데이트까지 고려하여 개발되었는지 잘은 모르겠지만 내가 알기로 그 정도까지는 아니지 싶다.
통합된 API가 없으니 Visual Studio고 아래아한글이고 다 독자적인 설치 및 업데이트 시스템을 구축하고 있는데.. 업데이트를 시켜 보면 프로그램뿐만 아니라 설치 관리자 자체부터 업데이트 하는 경우가 굉장히 잦다.

저건 뭐 한번 만들어 놓고 나면 버전 체크, 파일 설치 등등 끝.. 처음에 한번 안정적으로 잘 만들어 놨으면 바뀔 일이 없어야 하는 시스템이지 않은가? 그런데 뭐 이리 자주 바뀌나 모르겠다. 그리고 궁극적으로는 이런 분야도 운영체제 차원에서의 통합 솔루션이 나와야 할 것 같다.
그나저나 10~20여 년 전에 시대를 풍미한 배포 패키지이던 InstallShield는 요즘도 잘 먹고 살고 있는지 모르겠다.

6. 각종 약관 동의 화면

웹사이트에서 회원 가입을 할 때나 응용 프로그램을 처음 설치할 때는 사용자에게 뭔가 법적으로 동의를 구하는 계약 안내문이 표시되는 것이 관례이다. 사용자가 그 내용에 대해 명시적으로 yes라고 동의 의사를 밝혀야만 다음 단계로 넘어갈 수 있다.

응용 프로그램을 설치하는 경우라면 안내문의 내용은 주로 저작권과 관련된 것이다. 마소에서는 이 안내문의 명칭을 EULA(end-user license agreement)라고 붙인 것으로 잘 알려져 있다. 상업용 소프트웨어에는 불법 복제 금지와 관련된 경고문이 으레 들어가지만 그것 말고도 해킹이나 리버스 엔지니어링 금지 같은 조항도 있다.
한편으로 웹사이트 회원 가입이라면 개인 정보 수집 정책과 관련된 내용이 꼭 포함된다.

아울러, 요즘은 응용 프로그램도 사용권 계약과는 별개로 사용자의 사용 패턴 데이터나 오류 정보를 수집해서 개발사 서버로 보내도 되겠는지 동의를 구하기도 한다. 이걸로 사용자 개인을 식별하는 건 절대로 아니니 안심하라고 하면서.. 물론 이건 동의하지 않아도 프로그램을 설치하거나 사용하는 데는 지장이 없다.

이런 약관이나 법적 주의사항 고지 문구는 너무 비현실적인 상황까지 일일이 어려운 단어와 장황한 문장으로 미주알고주알 열거하면서 길고 딱딱하고 재미없는 걸로 악명 높다.
뭐 이건 온갖 애매한 상황까지 철저하게 논리적으로 방어해서 갑 쪽의 법적 책임을 최대한 피하기 위해 말이 그런 식으로 만들어진 것이다. 계약서는 아니지만.. 망토 하나를 만들어도 소송을 피하기 위해 “주의: 이걸 목에다 두르고 옥상에서 뛰어내리지 마시오” 경고문까지 들어가는 게 세상 돌아가는 이치이지 않은가?

그런데 말이 하도 재미없으니 갑이나 을이나 텍스트를 꼼꼼히 제대로 읽지 않는 건 마찬가지 같다. 그러니 한 10여 년 전이었나? “본 약관이 해지되는 순간 뼈와 살이 분리됩니다”던가? 개드립이 들어간 약관이 복붙 되어서 여러 웹사이트들에서 그대로 쓰인 게 뉴스에까지 방영되곤 했다.

약관과 관련된 말이 좀 길어졌는데..
본인이 이걸 표시하는 소프트웨어 UI와 관련해서 굉장히 큰 불만을 품고 있는 건.. 아니, 이건 나만의 불만도 분명 아닐 것이다.
안 그래도 재미없고 귀찮아서 안 읽는 긴 약관을 너무 작은 크기의 텍스트 셀에다가 집어넣고는 창의 크기 조절도 안 되게 해 놓으면.. 사용자는 읽고 싶은 생각이 더욱 멀리 달아날 것이다. 그렇지 않겠는가?

쪼금 생각을 한 곳에서는 약관을 plain text가 아니라 서식을 적용한 텍스트로 제공하고, 인쇄 기능 정도는 갖다놓았다. 하지만 이걸 인쇄까지 해서 보는 사람도 과연 얼마나 될까?
그냥 화면에서 창 크기 조절과 본문 검색 정도만 가능하게 하는 게 제일 좋아 보인다.

Posted by 사무엘

1. software is licensed, not sold

자동차의 소유 내지 운전 면허하고, 소프트웨어의 사용권은 공통점과 차이점을 비교해서 같이 생각해 볼 만한 사항인 것 같다. 자동차는 도난 방지 기능이 있고, 소프트웨어는 불법 복제 방지 기능이 있기 때문이다.

전자의 경우 옛날에는 전통적으로 물리적인 열쇠에만 의존하다 보니 보안이 상대적으로 취약했다. 수천 대 중 한 대꼴로 자물쇠 패턴이 일치하는 차량이 존재하기 때문에 그런 차는 내 키로 문을 열 수 있었다. 컴퓨터로 치면 마치 hash의 충돌과 비슷한 상황이라 하겠다.
그리고 영화 테이큰에서도 보듯이 열쇠 구멍을 적당히 쑤셔서 문을 따고, 비정상적인 방법으로 스타터 모터에 전기 자극을 줘서 시동을 걸 수도 있었다.

이런 상황을 막기 위해 과거에는 3rd-party 업체에서 개발한 싸제 도난 방지 시스템이 많이 쓰였다. 지정된 인증을 통과하지 않으면 물리적인 열쇠만으로 문을 따거나 시동을 걸 수 없으며, 오히려 경보음이 울리게 하는 것 말이다. 지금이야 이 정도 도난 방지 기능이 들어간 스마트키는 옵션이 아니라 자동차 제조사에서 기본으로 제공해 주는 영역이 됐다.

그럼 소프트웨어는 어떨까?
과거에는 좀 묵직하고 규모가 있는 제품은 병렬 포트에 락을 꽂는 것(..!)부터 시작해 하드웨어· 소프트웨어적인 온갖 방법으로 "귀하(= 소프트웨어 개발자/개발사)의 소중한 자산을 안전하게 보호하십시오"라고 광고하는 복제 방지 솔루션이 있었다. 하지만 그런 것들은 해커들이 작정하고 공략하면 몽땅 크랙 되는 건 시간 문제일 뿐이었다.

그나마 인터넷이 발달한 게 소프트웨어의 복제와 배포뿐만 아니라 개발사에서 사용자의 접속 여부를 파악하는 것까지(= 정품 인증) 용이하게 만들어 줬으니 호재이다. 스타크래프트도 배틀넷에 접속할 때만은 CD key를 체크했듯이 말이다.

자동차는 철저하게 자기 소유 위주이고 운전만 면허이지만, 소프트웨어는 처음부터 소유라는 개념 없이 사용권이 허가되는 것이라고 여겨진다. 영어로는 똑같이 license라고 한다.
자동차는 물리적인 실물이 존재하고 조작하는 것이 매우 위험한 물건이지만, 소프트웨어는 실물이 없이 무한 복제가 가능하고 사용 자체에 위험성은 없는 물건이라는 차이가 있다. 형태가 서로 매우 극과 극이라 하겠다.

그래서 불가피한 상황에서 자동차 문을 따거나 배선을 뜯어고쳐서 키 없이 시동 거는 방법을 소개하는 동영상을 보면.. "남의 차에다가 이 짓을 하는 건 불법입니다. 반드시 자기 소유의 차에다가만 at your own risk로 시도하세요!"라는 주의 문구가 있다.

소프트웨어도.. 정품 사용자가 자기 개인 소장용으로만 복제판을 만들거나.. 혼자 쓰는데 번거로워서 정품 인증 절차를 없앤(..) 크랙을 돌리는 것은 내가 알기로 합법이다. 글쎄, 단순 복제판을 넘어서 후자는 엄밀하게 따지면 사용권 계약서에 명시된 "리버스 엔지니어링과 변조 금지"의 위반일 수 있겠지만 그것까지 현실적으로 다 따지고 잡아내고 법을 집행하는 건 거의 불가능에 가깝지 싶다.

소프트웨어의 라이선스는 대외 공개 여부, 유료/무료, 소스 공개 여부 같은 변수를 따져서 다음과 같은 범주로 나눌 수 있겠다.

2. 소프트웨어 라이선스의 등급

(1) 존재 자체가 영업 기밀: 개발사의 내부에서만 쓰이며, 돈을 아무리 많이 준다 해도 애초에 남에게 판매 자체를 하지 않는다. 주로 서버(호스트) 사이드 프로그램, 혹은 소프트웨어 개발을 위해 내부적으로만 쓰이는 아주 특수한 도구가 이 범주에 속한다. 이런 프로그램의 내부를 외부인이 구경하고 싶으면 아예 개발사를 통째로 사 버리고 인수해야 할 것이다.. >_<

(2) 상업용: 돈 받고 사용권을 판매하는 상업용 소프트웨어들. 옛날에는 제품을 디스크에 담고 패키지로 포장해서 일시불로 무기한· 영구적인 사용권을 제공했으나, 지금은 프로그램 자체는 웹사이트에서 받게 하고 사용권을 기간제로 찔끔찔끔 제공하는 형태가 대세이다. 얘부터는 소스 코드만이 영업 기밀이다.

(3) 무료 공개: 누구나 무료로 사용 가능하다. 하지만 제공된 형태 그대로 제품을 사용하는 것 말고 상업적 목적의 재배포, 변조 등등은 여전히 금지이다. 날개셋 한글 입력기는 이 등급이다.

(4) GPL 오픈소스: 단순히 무료 사용을 넘어서 소스까지 공개인 파격적인 제품이다. 하지만 저작권 자체가 아예 없는 건 아니며, 얘는 전염성, 즉 "오픈소스 덕을 봤으면 너도 오픈소스에 동참하라" +_+라는 이념이 담긴 등급이다. 그렇기 때문에 기업 영업 기밀에 속하는 소프트웨어에다 GPL 기반의 코드를 쓸 수는 없다.

(5) LGPL 오픈소스: GPL보다는 조건이 완화됐다. 요 등급은 상업용 제품에다가 끌어다 쓰더라도 자기 코드를 공개하지 않아도 된다. 요즘 많이 쓰이고 있는 MIT 라이선스도 이쪽 계열인 걸로 안다.
다만, 있는 그대로 쓰는 게 아니라 좀 변조해서 쓴다면 어떻게 바꿨는지 그 변조한 코드만은(자기 코드 말고) 공개하라는 식으로 바리에이션이 있다.

(6) public domain: 너무 오래돼서 저작권이 소멸됐거나, 저작권을 주장하는 주체 자체가 사라져서 존재하지 않거나, 아니면 이도 저도 아닌데 개발자가 너무 대인배여서 저작권을 주장하지 않고 "완전 니 마음대로 쓰셈"을 시전한 경우이다. SQLite처럼 드물게 public domain인 제품이 있다.

요 6등급 분류가 굉장히 깔끔하긴 하지만.. 현실에서는 이 범주에 딱 정확하게 떨어지지 않는 물건도 있다.

(1) 태생적인 반제품: 요즘은 소프트웨어라는 게 전반적으로 릴리스 후에도 끊임없이 보안 패치를 해야 하는 반제품 형태가 돼 있다. 하지만 그것 말고 미들웨어 라이브러리 같은 제품 중엔 유료로 판매되는 상업용이면서 아무 end-user에게나 판매하지 않고, 구매자에게 소스를 제공하는 형태가 있다.

(2) abandonware: 도스용/16비트용 프로그램들, 아래아한글 3.0/97, Windows 95/XP 따위.. 오늘날 아무도 실생활에서 사용하지 않는 옛날 구버전 소프트웨어들은 아무래도 상업적인 가치는 없다. 하지만 개발사에서 판매와 지원을 중단했다고 해서 그 프로그램의 저작권 자체가 법적으로 소실된 건 아니다. 저작권이야 거의 70년인가 그 동안 유지되기 때문이다. abandonware가 곧 public domain을 의미하지는 않는다.

그러니 한물 갔다고 해서 과거의 상업용 소프트웨어를 마음대로 불법복제 해서 써서는 안 된다. 개발사에서 정식으로 무료화를 선언하지 않은 한 말이다. 허나, 이제 더 정식으로 판매되지 않고, 돈 주고 사겠다고 해도 구할 수 없어서 복제해서 쓰는 걸 누가 어떻게 뭐라 하겠는가? 그런 구닥다리 제품으로 복돌이가 개인 단위로 무슨 금전적인 이익을 얻고 있을 리도 없고..
이런 이유로 인해 현실적으로는 개발사에서 저 정도는 사실상 그냥 방치· 묵인해 주고 있을 뿐이다.

3. 오픈소스

요즘 어지간히 규모 있는 소프트웨어에서 about 대화상자나 도움말의 한구석 acknowledgements란을 꺼내 보면.. 이 제품이 내부적으로 사용한 방대한 오픈소스 라이브러리 목록이 없는 경우를 찾기 어려울 것이다. 동영상이나 일반 데이터 압축, 암호화, 영상 처리, 폰트 렌더링, 심지어 머신러닝…

그 정도 규모와 기능이면 돈 받고 판매하는 미들웨어 솔루션으로 손색이 없을 텐데 이런 게 소스까지 공개로 죄다 풀리니 요즘 소프트웨어들은 기술 수준이 엄청나게 상향평준화될 수밖에 없다. 소프트웨어 업계는 자동차 같은 다른 업계에는 존재하지 않는 '오픈소스'라는 진영 내지 이념· 트렌드 때문에 판도가 굉장히 크게 바뀌었다.

이 진영이 없었으면, 혹은 오픈소스라 해도 몽땅 무식한 GPL 일색이어서 사실상 무용지물이었다면.. 컴퓨터에서 같은 기능을 사용하더라도 소비자는 더 비싼 제품을 써야 하고, 개발사는 여기 저기 로얄티를 내야 하는 게 많았을 것이다.

기능을 사용하는 것 자체는 몽땅 무료로 풀리게 됐으니.. 소프트웨어 업계는 그 사용자들이 무슨 기능을 즐겨 사용하고 무슨 생각과 취향을 갖고 있는지를 수집하고 분석하고.. 이걸로 "어떤 더 고차원적인 돈벌이를 할 수 있을까, 어떻게 하면 사용자의 취향을 더 정확하게 저격한 광고를 내보낼 수 있을까"를 고민하게 된 듯하다.

물론, 마소에서 개발한 소프트웨어에서 zlib나 FreeType, libPNG를 사용했네, MIT/LGPL 라이선스를 준수하네 이런 식의 acknowledgement를 볼 일은 지금까지 없었다. 걔네들은 오픈소스 진영과 동떨어진 채 타사에서 유료 구입하거나 자체 개발해 놓은 밑천이 워낙 많으니 어지간한 상황에 대해서는 그런 게 필요하지 않았던 것이다.

하지만 언제까지나 그렇게 지낼 수는 없을 것이고, 지금은 마소도 옛날 빌 게이츠/스티버 발머 시절처럼 오픈소스에 적대적인 독불장군이 절대 아니니 오픈소스 진영과 엮이는 비중이 차차 늘 것으로 보인다.

4. 소프트웨어 라이선스의 종류

이렇게 각종 소프트웨어들이 소스째로 무료로 풀렸다는 게 모든 지적 컨텐츠들이 풀려서 개나 소나 아무렇게나 사용해도 된다는 말은 결코 아니다. 오늘날 컴퓨터로 남이 만든 것을 활용해서 이를 바탕으로 또 뭔가 새로운 걸 만드는 일을 하는 사람이라면 그 어느 때보다도 저작권에 대한 인식을 분명히 하고 있어야 한다.

컴퓨터가 실행하는 코드의 집합체인 소프트웨어 프로그램뿐만 아니라 디지털 폰트, 그리고 하다못해 짤막한 4단짜리 찬양 악보나 노래 음원 하나라도 무료 사용이 허용되는 조건이 까다로워지는 것이 요즘 추세이다.

물론, 개인이 혼자 집에서 무료로 비영리 목적으로 사용하거나 보고 듣고 즐기는 것을 막는 저작권자는 사실상 없다. 음악, 특히 찬송 같은 건 알려져서 자기 곡이 어느 교회건 예배 때 회중 찬송으로 불리는 것을 싫어할 작곡자는 없을 것이다. 그러나 반대로 임의의 개작, 개조, 제작자 변조, 무단으로 상업적 활용 같은 걸 허용하는 저작권자는 이 세상에 존재하지 않는다.

운전 면허가 자가용과 사업용이 나뉘어 있듯, 소프트웨어의 사용권도 그런 형태로 나뉘는 경향이 있다.
폰트는 유료로 구매했다 하더라도 자기 개인 단위의 인쇄물이나 웹페이지에서만 사용할 수 있는 1차 라이선스, 더 나아가 옥외 간판이나 본격 상업 매체에 적용되는 2차 라이선스, 아예 제품에 범용적으로 포함되거나 특정 BI/CI에 들어가고 자기들만이 독점적으로 사용하는 전속 서체 급의 3차 라이선스 형태로 나뉘어진다.

반디소프트의 반디집의 경우 2020년 7.0 버전부터 유료 버전을 따로 내놓기 시작했는데, 파워 유저를 대상으로 하는 개인 단위 유료(프로) 에디션, 그리고 기업에서의 사용을 염두에 둔 PC 단위 유료(엔터프라이즈) 에디션을 내놓은 게 무척 독특하다. 현실성 있는 유료화 정책에 대해 개발사에서 고민을 많이 한 것 같다.

엔터프라이즈 에디션을 구매하지 않은 기업 내부라고 해도 각 직원이 무료 에디션은 여전히 사용할 수 있다. 그 대신 얘는 광고가 뜨며, 기업 서버와의 최소한의 접촉을 막을 수 없다(업데이트 체크, 언제나 온라인으로만 설치).

이런 라이선스 종류는 아까 같은 영업기밀~소스 공개 같은 수직 비교와는 다른 양상의 수평 비교라고 볼 수 있을 듯하다.

Posted by 사무엘

1. 동영상

유튜브가 광고 없는 유료 프리미엄 서비스를 밀고 홍보하기 시작하더니, 2019년 하반기쯤부터는 반대로 일반 무료 상태에서는 광고가 예전보다 더 길어지고 잦아진 것을 다들 느끼실 것이다. 원래 5초 1회로 시작했던 것이 6~7초 2회로 늘었다. 요런 걸로 유료 가입자를 확보하고 수익을 내려는가 보다.

하긴, 유튜브는 인터넷에서 깨진 동영상 링크라는 걸 없애고, 오프라인 다운로드가 당연하다고 여겨졌던 60프레임 HD급 초고화질 동영상까지 실시간 스트리밍으로 실현한 엄청난 사이트이다. 모니터 주사율만 해도 평소에 50~60Hz를 쓰다가 75Hz이상을 맞추면 화면이 훨씬 더 부드러워진 게 느껴지는데.. 동영상도 60프레임짜리를 보면 화질을 떠나서 움직임이 확~ 더 자연스럽고 부드럽고 보기 편한 게 티가 난다.

쟤는 그냥 지구상에 존재하는 모든 영상 기록들의 아카이브인 동시에 전세계의 개인 방송, 교회 설교 같은 것까지 몽땅 감당하고 있다. 집에 TV가 없어도 유튜브가 TV나 마찬가지이다. 동영상을 하나 보기 시작했다가 같이 뜨는 관련 동영상까지 섭렵하다 보면 시간 가는 줄 모른다.

이런 괴물이 등장할 거라고는 198, 90년대의 그 어떤 SF 작가도 예상하지 못했으며..
저걸 돌리려면 평소에 서버 유지비도 정말 장난 아니게 들지 싶다.;;; 이걸 버틸 재간이 안 되는 국내의 중소 동영상 포털들은 수지가 안 맞으니 2010년대 초· 중반을 못 넘기고 다들 망했다.

한 20여 년 전에 컴퓨터에서 동영상이라는 건 그냥 320*240의 자그마한 화면에서 노이즈 대신 JPG artifact가 가득한 허접한 화질로 보는 avi, mpg, mov가 전부였다. 전반적인 화질은 기존 VHS 비디오 테이프보다 결코 좋을 게 없고, 단지 아날로그가 아닌 디지털이라는 의의만 있을 뿐이었다.
1990년대 초-중까지는 MPEG1/2급 동영상을 시청하기 위해서 별도의 그래픽 가속 하드웨어를 장착해야 할 정도였다. 동영상 캡처/인코딩이 아니라 단순 시청을 위해서도 말이다. 이런 가속은 통상적인 3D 그래픽용 가속과는 별개의 분야일 것이다.

그러다가 한 2000년경엔 갑자기 온갖 코덱들이 난립하기 시작해서 통합 코덱 패키지가 나오고, '사사미'라고 자막이 화면에 깔끔하게 입혀진 채로 뜨는 새끈한 동영상 재생기가 개발되었다. 이때까지만 해도 고화질 영화· 애니 동영상은 각종 P2P 불법 공유 네트워크를 통해 많이 오갔던 것 같다.
온라인 실시간 스트리밍으로는 어림도 없고.. 유튜브만 해도 2010년대 이전에는 여전히 3~400대 해상도에 머물러 있었으며 동영상 하나당 10분 시간 제한까지 있었다. 지금으로서는 믿어지지 않을 것이다.

난 동영상 압축 알고리즘에 대해서는 아는 게 별로 없다. 인접한 프레임, 그리고 인접한 픽셀들이 서로 유사하다는 것을 이용해서 차이점만 담는다는 것이 골자일 텐데.. 이건 컴퓨터에서 캐시의 개념을 설명할 때 언급하는 시간 지역성, 공간 지역성하고 비슷한 개념 같다. 그나마 동영상 재생 및 압축 기술이 다들 대인배 오픈소스로 풀려 있기 때문에 사람들이 폰이나 PC에서 더 저렴하고 간편하게 동영상을 즐길 수 있다.

2. CPU의 다양다변화, 병렬화

21세기에 컴퓨터 CPU에서 단일 코어 클럭 속도의 '기하급수' 증가가 드디어 멈췄다. 그 대신 지금까지 슈퍼컴퓨터 세계의 전유물로 여겨졌던 멀티코어가 개인용 PC에도 등장하게 됐다. 이게 1차 변화이다.

그래서 어느 플랫폼에서나 동일한 방식으로 스레드를 생성하라고, CPU의 여러 코어를 잘 제어하고 활용하라고 OpenMP라는 규격이 제정되기도 했다. 이건 특정 연산에 대해서 적당히 병렬화하라고 지시를 내리는 여러 C 함수와 언어 확장, #pragma들의 모음이다. 난 지금까지 UI의 반응성 향상을 위해서만(= 백그라운드 작업) 스레드를 사용해 왔지, CPU 자원을 몽땅 쪽쪽 빨아서 쓰기 위해서 스레드를 동원해 본 적은 없었다.

요즘 컴퓨터들은 뺑뺑이를 돌려 봤자 전체 CPU 사용량이 10%대밖에 되지 않는 건 사실이다. 하지만 그렇다고 해서 별다른 최적화 없이 무턱대로 스레드를 만들어서 CPU 사용량을 늘리면 그래 봤자 throughput이 그저 전체 CPU 사용량에 비례해서 팍팍 오르는 것은 확실히 아니어 보인다.

작업 스레드를 만들면 각 작업들의 수행 속도도 눈에 띄게 느려지기 때문이다. 이는 어지간한 하이엔드급 컴에서도 관찰 가능한 현상이다. 뭐랄까, 작업 스레드가 증가하면 context switching 같은 다른 오버헤드도 추가되어서 전체 효율이 떨어지는 것 같다.

프로그램을 너무 많이 띄워서 메모리가 부족해지면 가상 메모리 페이징(디스크 스와핑)만 죽어라고 하느라 컴퓨터의 작업 수행 속도가 급락한다. 좁은 화면에 창을 너무 많이 띄우면 사람도 창 전환만 하느라 작업 능률이 급락하며, 반대로 모니터를 여러 개 연결하는 건 생산성을 사기급으로 향상시킨다.
이와 마찬가지로 CPU의 성능에 걸맞지 않게 작업 스레드가 너무 많아지만.. 작업 전환 비용의 증가만으로 성능이 극도로 떨어질 수 있겠다.

그런데 요즘은 그걸로 끝이 아니다. 게임용 3D 그래픽 렌더링이나 좀 보조하라고 만들어졌던 add-on인 GPU도 거기에만 쓰는 게 아깝다. 굳이 3D 그래픽이 아니어도 그것처럼 단순무식하고 물량빨인 계산 작업이 있으면 거기에도 GPU를 투입할 수 있다. 특히 살인적인 노가다 계산이 필요한 머신러닝 분야에서 GPU 연산이 더욱 각광받기 시작했다.

그러니 이것도 별도의 프로그래밍 영역이 됐다. nVIDIA에서 GPU 활용 프로그래밍을 위해 OpenMP와 비슷한 컨셉으로 CUDA라는 라이브러리를 내놓았다. 이건 그냥 인텔 내장 그래픽을 쓰는 노트북 같은 기계에서는 활용할 수 없다는 것이 멀티코어 CPU와 다른 점이다. 그것 말고 OpenCL 같은 다른 GPU 라이브러리도 등장했다.

하긴, 아직 싱글코어 시절일 때도 아까 얘기했던 동영상 정도의 멀티미디어 처리를 위해서 인텔에서는 SIMD(1명령 다중 데이터) 정도의 병렬 처리를 지원하는 명령을 도입한 적이 있었다. 그게 옛날 1990년대 말의 펜티엄 프로~III 기간에 추가된 MMX 내지 SSE 명령이다. 얘가 기존 x87 명령을 대신해서 부동소수점 연산까지 처리한다.

옛날에 하드웨어의 성능을 극한으로 짜내는 게임을 만들려면 어셈블리어를 알아야 하고 비디오 메모리에 직통으로 내용을 직접 뿌린다거나 해야 했다. 지금은 특정 CPU의 인스트럭션을 써 주는 짓은 필요 없지만, 그것과는 좀 다른 양상으로 하드웨어를 직접 다루는 최적화 테크닉이 필요한 시대가 되어 있다.

3. 슈퍼컴퓨터 내지 CPU 아키텍처의 명멸

본인은 어린 시절에 슈퍼컴퓨터라고 하면 덩치가 크고, 내부에 무슨 금칠이라도 했는지 가격이 억소리 나게 비싸면서.. 개인용 PC보다 메모리가 훨씬 더 방대하고 반응 속도가 수십 수백 배 정도 더 빠른 물건 정도로나 생각했다.
뭐, 20세기 옛날에는 개인용 컴퓨터 대비 전용 슈퍼컴의 차이가 그런 단순한 차이점에 더 근접해 있기도 했다.

하지만 오늘날은 개인용 PC가 10~20년 전의 업계 최고의 슈퍼컴보다 더 빠르다. 마치 오늘날의 무선 인터넷이 10~20년 전의 유선 인터넷보다 더 빠르듯이.. 정말 경이로운 노릇이다.
이제 슈퍼컴이라고 해서 개인용 PC보다 단순히 기계적으로 무식하게 더 빠르지는 않다. "개인용 PC가 64비트 3~4GHz대니까 슈퍼컴은 machine word가 256비트이고 클럭 속도는 40GHz 정도 하겠지"가 아니라는 뜻이다.

이제는 슈퍼컴 전용 아키텍처, 전용 운영체제 같은 것도 존재하지 않으며, 비트 수가 차이 나는 것도 아니고.. 다 똑같이 x86이다.
차이가 나는 건 계산을 위한 코어수뿐이다. 그걸 정교하게 제어하는 별도의 프로그램을 짜서 돌려야 슈퍼컴의 성능을 제대로 활용할 수 있다.

단일 코어의 클럭 속도는 이제 개인 PC도 슈퍼컴과 비슷하거나 더 나으면 낫지, 결코 뒤쳐지지 않는다.
그냥 단일 코어만 열나게 돌리는 PC용 PI 계산 프로그램을 그대로 돌리면 슈퍼컴이라고 해서 몇백만 자리가 즉시 짠~ 하고 튀어나오지 않는다.

옛날의 전용 패러다임과 재래식 생산 공정 하에서 슈퍼컴을 열심히 연구 개발했던 크레이 같은 공돌이가 오늘날의 컴퓨팅 환경을 본다면 놀라서 까무러치지 않을까 싶다.
통상적인 시뮬레이션· 계산용 슈퍼컴은.. 단순히 외부로부터의 대용량 트래픽 처리용인 고성능 서버하고는 지향하는 게 다르다. 스포츠 사격과 군대 사격이 다른 것만큼이나 다르다고 생각하면 될 듯하다. IBM 메인프레임은 둘 중 어느 용도에 더 가까운 걸까..?

오늘날은 PC가 성능이 워낙 향상되어서 PC와 슈퍼컴 사이의 경계 축에 들던 '워크스테이션'이라는 컴퓨터 체급도 의미가 많이 퇴색했다. 굳이 따지자면 맥 프로 같은 high-end급 PC일 뿐이겠지.
그 시절에 워크스테이션이란 운영체제도 OS/2나 솔라리스, NextStep, Windows NT 정도 돌리던 전문가 업무용 컴터였으며 가격은 거의 경차 한 대에 육박했었다. 노는 물이 도스나 Windows 3.1 따위하고는 완전히 달랐다.

이런 식으로.. 데스크톱 PC는 호환성이 깡패인 x86+x64 천지가 됐고, 모바일은 ARM인데 얘들도 PC로 호시탐탐 진출하려고 노력하는 중.. 거기에다 게임기는 아직 PowerPC가 살아 있나 모르겠고, 메인프레임에 IBM POWER 정도가 살아 있는 것 같다.
이젠 구글과 애플도 CPU를 직접 만들려고 하고.. 과거 Windows NT 3~4 시절과는 다른 의미의 CPU 아키텍처 춘추 전국 시대가 열리는 게 아닌가 모르겠다. 결국은 이식성 좋게 만들어진 소프트웨어가 승자가 된다.

4. 전자와 전산의 관계

가만히 생각해 보면.. C++ 언어로 Windows MFC 등.. 상대적으로 '특정 플랫폼 실무에 가까운 프로그래밍'을 자주 하는 사람은 전산· 컴공보다는 전자공학 쪽에 더 많았던 것 같다. 과거에 유명한 Visual C++ 프로그래밍 베스트셀러 책을 집필했던 분들도 전공이 그런 쪽이었다. 세부적으로는 로봇 공학이라든가 디지털 신호 처리 쪽으로 말이다.

그럼 진짜 전산· 컴공을 한 사람들은 뭘 하는가 하면.. 좀 더 크로스 플랫폼이나 오픈소스에 친화된 스타일의 코딩을 한다. 뭐, 웹 프로그래밍도 방법론은 사뭇 다르지만 크로스 플랫폼 프로그래밍의 범주에 들 테고..
특히 PL 쪽 덕후들은 C++ 같은 지저분한(?) 언어는 거들떠보지도 않고 Rust나 go 같은 더 마이너한 언어, 함수형 언어 같은 걸 즐겨 쓴다. 쉽게 말해 더 추상적이고 고차원적인(?) 걸 추구하는 듯하다.

아 그렇다고 모든 전자과 출신이나 모든 전산과 출신이 취향이 그렇게 갈린다는 말은 물론 아니다.
그리고 신호 처리는 전자공학이지만 컴퓨터그래픽스는 명백하게 전산학의 세부 분야인 것 같다. 요컨대 영상을 렌더링 하는 건 전산학이고, 그 생성된 영상을 손실 압축해서 저장하는 건 전자공학 쪽인 셈이다. 다음으로 영상 인식 같은 건 전자와 전산이 별 구분 없이 같이 파는 것 같다.

Posted by 사무엘

1.
작년 말(12월)부터 국내에서는 잘 알다시피 5G 이동통신 기술이 상용화 됐다. 그런데 그런 뉴스가 전해지기 전부터 언제부턴가 집과 각종 공공장소의 와이파이 접속명은 뒤에 5G가 붙기 시작해서 iptime5G 이런 식으로 바뀌었고, 속도도 더 빨라지긴 했다.
똑같은 전자기파와 똑같은 랜선을 쓰면서 어떻게 인터넷 속도가 이렇게 계속 더 빨라질 수 있는지 신기할 따름이다. 컴퓨터 클럭 속도는 멈춘 지 15년 가까이 됐지만, 현재까지 아직도 치트키 수준으로 경이롭게 증가하고 있는 건 인터넷 속도인 것 같다.

2.
컴퓨터 키보드의 글쇠들 주변을 보면, 다른 먼지들이 쌓여서 더러워지는 건 이해가 되는데 1~2cm 남짓한 길이의 솜털들은 도대체 어디서 떨어진 건지 모르겠다.
손가락 끝이나 손바닥서 털이 나는 것도 아니고, 사람 얼굴에서 떨어진 털이 거기로 갈 리는 없을 텐데.. 알 수 없는 노릇이다.

3.
옛날에 비해 컴퓨터 장치들이 독립성이 강화되고 더 똑똑해지는 게 느껴진다.
가령, 옛날에 모니터와 이어폰은 전통적으로 자신만의 전용 단자가 있으며(직렬· 병렬 포트나 USB 따위가 아닌), 컴퓨터의 입장에서는 꽂든지 말든지 소프트웨어적으로 별 차이나 반응이 없던 물건이었다.

그러던 것이 언제부턴가 컴퓨터에서 각 모니터의 탈착을 감지할 뿐만 아니라 그 모니터의 종류, 적정 해상도와 주사율까지 알아서 조절하게 됐다. 그리고 사운드 쪽도 이어폰을 꽂은 상태에서 볼륨을 너무 높이면 컴퓨터가 사용자의 청력까지 걱정해 주는 경지에 다다랐다.

옛날 브라운관 모니터는 밝기 조절, 채도 조절, 상하좌우 shift/resize를 전부 별도의 다이얼을 돌려서 해야 했다. 그러나 요즘 모니터는 자체적으로 컴퓨터 프로그램 UI가 내장되어 있기 때문에 메뉴와 화살표, 엔터 같은 키만 있다.
아울러, 노트북의 터치패드도 단순히 마우스와 호환되는 포인팅 장비가 아니라 자체적인 옵션을 갖고 있고(각종 제스처 인식 여부) 드라이버를 잡아 줘야 하는 물건으로 탈바꿈했다.

4.
본인이 회사에서 사용하는 컴퓨터는 CPU, 그래픽 카드, 메모리 등 하드웨어 전반이 전형적인 2010년대 중반급의 사양이고 별다른 이상이 없다. 그런데 화면의 반응이 왠지 굼뜨고 느리게 느껴져서 불편했다. 간단히 창을 마우스로 끌어서 이동시켜 봐도 모션이 매끄럽지 않고 미묘하게 랙이 걸려서 뚝뚝 끊기는 것 같았다.

듀얼 모니터 중 하나가 4K급 해상도여서 혹시 비디오/디스플레이 쪽으로 성능이 딸리는 병목이 존재하나 의문이 들었는데.. 그 예상이 반은 맞고 반은 틀렸다. 그쪽 문제인 건 맞지만 원인이 컴퓨터 쪽이 아닌 모니터에 있었기 때문이다.
모니터가 4K 해상도에서는 주사율이 30hz밖에 되지 않았던 것이다.

옛날에는 그냥 평범한 모니터가 보통 50hz이고, 좀 좋은 제품은 60내지 그 이상이었던 것 같다. 주사율이 높으면 마우스 포인터의 이동 모습이 아주 부드러워져서 컴퓨터를 쓰는 인상, 경험, 느낌을 좋게 하는 데 큰 기여를 했다.
또한, 유튜브 동영상만 해도 단순히 화질만 720~1080 HD급이 아니라 프레임 수도 60fps라고 기재된 게 있다. 그건 타 동영상에 비해 모션이 아주 자연스럽고 부드러운 게 티가 나며, 감상할 때 심리적으로 굉장히 긍정적인 느낌을 준다.

그런데 모니터에서 초고해상도를 구현하기 위해서 이런 중요한 주사율을 등가교환하다니...;; 컴퓨터가 성능이 아무리 좋아서 화면을 초당 수백 회 고치더라도 사람은 모니터 주사율보다 더 부드러운 화면을 볼 수 없게 된다.
LCD는 과거의 브라운관 CRT보다는 주사율이 낮아도 괜찮다고 하지만 그래도 그렇지 30hz는 너무 심한 것 같다.

과거에 영화라는 게 처음 발명됐을 때의 기본 프레임 수인 24fps는 30보다도 작은데, 사람이 끊김 없이 자연스러운 영상이라고 느끼는 가히 최소의 마지노 선으로 잡은 값이라고 한다. 이 숫자를 정하기 위해 인지과학적인 실험과 고찰이 들어갔지 싶다.
아날로그 텔레비전의 주사율은 교류 전기의 진동 주기와도 연계해서 설정되었다고 한다. 60hz이면 그와 연계해서 30hz (= 30fps) 같은 식이다. 물론 디지털 동영상에서 프레임 수나 최신 디스플레이에서 주사율은 굳이 그런 것에 얽매이지 않고 그냥 정하기 나름이고 기계의 제조 원가나 전력 소모 대비 기술적 한계에 달려 있다.

일반 정지 영상에서 여러 안티앨리어싱 기법이 존재하듯, 영상에서도 motion blur라고 그야말로 애니메이션계의 안티앨리어싱에 해당하는 기법이 있다. 낮은 fps에서도 동영상이 뚝뚝 귾기지 않고 최대한 부드럽게 이어지듯 보이게 하기 위해서이다. 3D CG로 동영상을 생성하는 그래픽 소프트웨어 내지 각 프레임들을 이어서 동영상을 만드는 인코더가 그런 것까지 감안해서 넣어 주는 기능이 있을 것이다.

말이 나왔으니 말인데, 화면의 해상도와 프레임 수뿐만 아니라 종횡비 그 자체도 어쩌다가 지금처럼 바뀐 걸까? 어쩌다 보니 컴퓨터용 모니터는 가로로 더 길쭉해졌고 스마트폰은 세로로 더 길쭉해졌을까? 모든 영화들은 종횡비가 동일한 걸까? 이런 것도 알고 보면 내력과 사연이 많이 있는데 기회가 되면 차츰 더 알고 싶다.

5.
SSD는 뭐랄까.. 양날의 검 같다.
기계적인 동작이 없으니 소음 없고 전력 소모 적고, 엄청 빠르고.. 비싼 것만 빼면 하드디스크를 완전히 압도하여 조만간 주기억장치와 보조 기억장치의 경계를 허물 것 같은 신기술임이 틀림없다. 반도체 공학의 신비로움을 다시 생각하게 된다.

반도체 기반 보조 기억 장치들은 외형과 단자 형태에 따라 (1) USB 메모리 스틱, (2) SD 카드, 또는 (3) SSD로 나뉘는 듯하다. 그 중 SSD는 광학 디스크(CD/DVD)나 USB/SD와 달리, 하드처럼 같은 C: 고정식 디스크 역할을 한다는 특징이 있다. 동작 원리는 기계식 하드와 완전히 다르지만 말이다.

그러니 하드/SSD만 일컫는 통합 명칭이 필요해 보인다. 고정 디스크? 하드라는 명칭이 너무 굳어졌다면 '기계식 하드/SSD 하드'라는 말이라도 쓰여야 할 것 같다.
그리고 어떤 로컬 디스크에 대해서 파일 시스템이야 요즘은 Windows 기준으로 NTFS가 아닌 곳이 없을 테니 별 의미가 없고.. 디스크가 기계식 하드인지 SSD인지를 되돌리는 API도 GetVolumeInformation 같은 급의 함수에 있어야 하지 않나 생각이 든다.

그런데 자동차가 엔진 제어 방식이 기계식에서 전자식으로 바뀌면서 원인 불명의 급발진이 발생하기 시작한 것처럼.. 디스크 역시 기계식에서 전자식으로 바뀌면서 일상적으로 편리해진 대신에 뭔가 안정성이 떨어진 것이 있다. 단순 가격 차이를 떠나서 SSD는 기계식 하드를 완전히 대체하기에는 아직 5% 부족한 면모가 있다. 이 사이트의 글을 한번 읽어보자. "화 있을진저, 너희 백업 없이 SSD를 쓰는 족속들아!"

• SSD는 한번 고장 나면 데이터를 살릴 가능성이 거의 없는 매체이다.
• 하드가 충격이나 자성에 약하다면 SSD는 열과 전기 충격에 매우 약하다. (불안정한 전류, 갑작스러운 정전, 컴퓨터 다운, 과열..) 취약한 분야가 서로 다름.
• 하드는 배드 섹터를 빼고 나머지 부분이라도 읽고 복구가 가능하지만 SSD는 그런 것 없다.

하긴, 정전이 돼서 작업 중인 데이터를 날렸다고 해서 자기 컴의 RAM의 복구를 시도하는 건 불가능할 것이다. 물론 SSD는 RAM과 같은 구조의 기억장치는 아니지만 SSD도 그만치 훅 가기 쉽다는 뜻이다.

본인도 새로 산 노트북을 사용한 지 불과 5개월 남짓 만에 SSD 불량으로 인한 교환을 경험했기 때문에 이 경고가 더욱 공감이 갔다. 심각한 피해를 입은 정도까지는 아니지만 그래도 꼼꼼히 백업하지 않던 기록과 소스 코드를 일부 날렸기 때문이다.
하드디스크는 떨어뜨리고 물에 집어넣은 것도 국가 수사 기관 차원에서 작정하고 털면 무슨 끈질긴 생명체마냥 내용을 어느 정도 복구해 낸다고 한다. 하지만 SSD는 정말로 훅 가기 때문에 이거 뭐 정보 보호와 보안 관점에서는 더 편리할지도 모르겠다..;;

옛날에는 노트북에서 자주 발생하던 잔고장이 액정 화면의 접촉 불량, 그리고 키캡 이탈이었는데.. 2010년대에 구매한 제품에서는 그런 건 없고 하드와 SSD의 접촉 불량을 더 자주 겪었다. 그러고 보니 운영체제를 재설치하는 통과의례도 Vista 시절부터는 없어졌다. 자동차고 컴퓨터고 모두 지난 20여 년 동안 참 많이 바뀐 것 같다.

Posted by 사무엘