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

1990년대 초중반, 일반 서민 땅개들은 DOS를 벗어나지 못하고 기껏해야 Windows 3.x니 이런 바닥에서 놀고 있었는데,
하늘 위로, 혹은 바다 건너편에는 서민이 범접조차 할 수 없는 별세계가 있었다.
아래의 것들은 골수 얼리어답터나 직업적으로 컴터 연구하는 사람, 해외 문물을 재정 타격 없이 접할 수 있는 금수저의 산물이었다.

1. 매킨토시

매킨토시 컴터 화면으로 실사 사진이나 전자출판 인쇄물 화면이 쫙 뿌려져 있는 건 그야말로 꿈만 같은 신세계 별세계 그 자체였다.
이때는 산돌, 윤 같은 서체도 맥의 전유물이었다. Windows에서는 구경조차 할 수 없었다. PC는 저해상도 화면과 프린터에 튜닝이 잘 된 한양, 휴먼, 큐닉스의 나와바리였을 뿐이다.

마소 진영의 빌 게이츠는 장사꾼이어서 악랄한 독점뿐만 아니라 박리다매, 하위 호환성, 고객 눈높이.. 이런 이념을 중시했었다. 그러나 잡스는 그렇지 않고 교주, 소수의 매니아, 고가 프리미엄.. 이런 쪽이었다.
본가부터가 저런데 그 당시 애플 매킨토시의 한국 총판이었던 엘렉스는 안 그래도 비싼 제품 가격을 더 지랄맞게 쳐 올렸다.

PC로 치면 286 AT밖에 안 됐을 저가 보급 사양부터가 1990년대 가격으로 2, 300만 원부터 시작했다. 하이엔드급은 6, 700만 원.. 돈 좀 보태면 집이나 차를 살 수 있을 정도였다.
오죽했으면 흉악한 가격에 빡쳐서 그냥 미국 현지에 가서 제품을 직접 사서 들여 오는 사람도 있었다.

2. OS/2 2.x

1990년대 초에 각종 도스용으로 나왔던 업무용 프로그램· 개발툴들은 DOS뿐만 아니라 OS/2 지원을 Windows 지원보다도 더 중요하게 생각했었다.
PC용으로 만들어졌던 진정한 32비트 운영체제였다고는 하는데.. 이후에 OS/2 Warp니 멀린이니 이런 거 나왔다가 존재감 없이 사라진 것 같다. 들리는 말로는 코드 구조가 어셈블리어 기계어 코드 일색이고 포터블하지 못했던 것도 OS/2의 명줄을 더 재촉했다고 한다.

나와 개인적인 접점은 전무하다. 단지, "OS/2 써 보려면 컴터 램이 4MB 이상은 있어야 합니다" 이런 문구를 1992년도 컴터 잡지에서 보고 깜짝 놀라긴 했었다. ㅎㅎ

3. Windows NT 3.x

껍데기는 Windows 3.1처럼 생겼고 심지어 버전 번호도 똑같이 시작했지만 내부 구동은 정말 넘사벽으로 다른 물건이다.
안정적이고 탄탄하고 순수 32비트 기반이고.. 다 좋은데 램이 지랄맞을 정도로 많이 필요해서 돌릴 수 있는 컴퓨터가 별로 없었다. OS/2보다 더 자비심이 없었다.

NT는 Windows 2000, XP의 전신이고 심지어 오늘날 Windows 10/11의 먼 조상이라고도 볼 수 있다~!
도스 기반의 Windows 3은 x86에서 86 real, 286 standard, 386 enhanced 다양한 모드로 실행 가능했다.
그 반면, Windows NT는 그냥 여러 CPU를 지원했다. x86은 무조건 386인 거고, 그 밖에 MIPS, DEC alpha 등.. 개발 방향과 성격이 이런 차이가 있었던 것이다.

그리고 NT는 DirectX라는 게 개발되기 전부터 OpenGL을 지원하고 있었다. 게임보다는 업무용 그래픽을 위해서.
OpenGL에 대해서는 좀있다 다시 얘기하도록 하겠다.

4. NeXTSTEP

잡스가 애플을 잠시 떠나 있던 동안 개발했던 고급 컴퓨터와 거기서 돌아가던 운영체제 되시겠다.
id 소프트웨어의 존 카맥이 이 환경에서 Doom과 Quake를 개발했던 것으로 잘 알려져 있다.
그리고 국내에서는 Windows용 아래아한글 3.0b가 요 NeXTSTEP의 UI를 차용한 독자 UI를 채택했던 바 있다. 특히 스크롤바의 화살표 삼각형이 양쪽 끝에 있는 게 아니라 한데 몰려 있는 거 말이다. ◀-----▶가 아니라 -----◀▶

이상이다.
일반 흙수저 서민들이 저런 급의 OS를 만져보게 된 첫 기폭제가 사실상 Windows 95라고 봐도 과언이 아니다.
그리고 그게 가능해진 건 램값이 싸진 덕분이다.
1990년대 이후 PC의 발전을 논할 때는 컴퓨터 속도의 향상(그 뒤 멀티코어화), 램 용량의 증대(단가 하락), 그리고 네트워크 속도 향상.. 이 순서를 기억하면 될 것 같다.

1990년대 말쯤부터는 슈퍼컴퓨터만을 위한 전용 컴터 아키텍처라는 것도 없어졌고,
워크스테이션이라는 개념도 아주 희박해져서 그냥 하이엔드 급 PC로 흡수된 것 같다.

※ 번외: OpenGL과 화면 보호기

과거.. 1990년대 후반~2000년대 초에는 Windows 컴터에 "3D 텍스트, 3D 미로, 3D 날으는 객체들, 3D 미로"라는 화면보호기가 있었다.
Windows 95 때는 '쁘라스 확장팩'에만 수록되어 있었고, 98부터 XP에는 기본 내장돼 들어갔었다.

얘들은 OpenGL이라는 하드웨어 가속 3차원 그래픽 라이브러리의 기술 데모 명목으로 만들어졌다.
마소는 전통적으로 게임용 그래픽 명목으로 DirectX를 강력하게 지지하곤 했는데 웬 OpenGL인 걸까?
"얘들은 '3D 핀볼'처럼 제3자 외주 개발 프로그램이기라도 했나? 근데 겨우 화면보호기를 외주로 개발해?"

개인적으로 궁금했는데 그게 아니구나.
얘들은 마소에서 자체 개발한 프로그램인데, Windows 95가 아니라 Windows NT 3.5에서 유래된 것이었다.
95 시절에 출시됐던 Hover! 이라든가 Fury!! 같은 초보적인 수준의 가정용 3D 게임과는 기술 계보가 완전히 달랐다. 이게 핵심이다.

(* 참고로, 저 당시에 마소는 팀 간에 경쟁과 알력 싸움이 장난이 아니었던 것이 공공연한 비밀이다. Windows 9x 팀 vs NT 팀, Office 팀, Visual C++ 팀 등등.. 그래서 서로 정보 공유도 안 하고, 같은 기능 API도 다 따로따로 중복 개발했을 정도였다.. 무슨 구 일본군 육군 vs 해군처럼.. 그 당시 빌 게이츠라든가 스티브 발머는 정말 살벌한 경영자였다. *)

하드웨어 가속이 없이 평범한 재래식 그래픽으로는 화면보호기에 점, 선, 글자 같은 초보적인 그래픽 애니메이션만 가능했다. 그것도 2D 위주..
물론, 쌍팔년도 시절 화면보호기의 정석 교과서는 별들이 씽씽 3차원 원근법이 적용되어 날아다니는 '우주여행'이긴 했다. 아니면 불꽃놀이..??? 시꺼먼 화면에서 점과 선만 갖고 나름 근사한 눈요깃거리였다. 직접 코딩해서 만들어 보고 싶다.

그런데 OpenGL이나 DirectX 같은 게 등장한 덕분에 텍스처나 광원이 들어간 3차원 애니메이션이 구현 가능해졌다.
그래서 마소에서는 OpenGL 데모를 화면보호기 형태로 제공하기로 했고.. 사내 OpenGL 화면보호기 덕질 공모전을 열어서 제일 우수한 작품 하나를 Windows 제품에다 넣기로 했다.
그랬는데 결국은 출품된 작품들을 모두 제품에다 넣어서... 그게 저렇게 전세계에 퍼진 것이다.

얘들은 훗날 Windows Vista에서 대부분 빠지고 '3D 텍스트'만 남았다. 그리고 비누방울 같은 다른 보호기가 도입돼서 오늘날에 이르고 있다. 새로 개발된 걔들은 당연히 Direct3D 기반이겠지..??

지금이야 화면보호기라는 개념 자체가 완전히 레거시 퇴물이 됐다. 마치 도스 시절에는 하드디스크 파킹 유틸리티가 각종 현란한 그래픽과 함께 유행이었는데 그것도 유행 지나고 퇴물이 됐듯이 말이다.
화면보호기가 하는 일은 세계 절경 풍경이 나오는 잠금 화면, 아니면 아예 컴 화면을 완전히 끄는 절전 모드로 계승되었다. 스마트폰에 화면보호기 따위가 있지는 않다.

이 화면 보호기 얘기는 the old new thing 블로그의 내용을 토대로 작성되었다.
하긴, 옛날에는 화면 보호기처럼 화면 전체를 마치 프레젠테이션 화면 전환처럼 조작하는 거 말이다.
Doom 게임에서 화면 녹으면서 내려가던 효과, 하늘소 프로그램에서 텍스트 화면이 좌우로 쫙 갈라지는 거..
비디오 메모리를 직접 조작하던 게 추억의 프로그래밍 테크닉이었다. ^^

Posted by 사무엘

1. 거대한 실행 파일

전통적으로 Windows 운영체제가 깔린 PC에서 볼 수 있는 엄청 큰 DLL 중 하나는.. 마소 Office 제품들이 사용하는 공용 라이브러리인 mso.dll 이다.
Program Files\Common Files\microsoft shared\OFFICExx 디렉터리에 있는 파일인데, 20여 년 전에 이미 크기가 10수 MB가 됐고, Office 2013의 64비트 버전 기준으로 36MB를 넘었다.

저 파일은 리소스나 데이터가 별로 없고, 대부분이 순수하게 코드만으로 저 크기이다.
오피스의 경우, 리소스들은 언어별로 별도의 리소스로 분리가 잘 돼 있기 때문이다.

그 뒤, 요즘은 웹 브라우저의 렌더링 엔진이 왕창 거대한 단일 DLL 자리를 차지하는 편이다.
Windows의 system 디렉터리에 있는 mshtml.dll 도 64비트 기준 20MB를 넘는다. 얘는 Internet Explorer 브라우저의 Trident 엔진 파일인데.. IE는 요즘 죽었으니까 제끼고.

많은 사람들이 사용하고 있을 크롬 브라우저의 코어 엔진인 chrome.dll은 거의 220MB에 달한다.
이게 내가 현재까지 알고 있는 제일 큰 DLL이다. 파일에서 적어도 3/4 가까이는 코드가 차지하고 있는 DLL 중에서 말이다.
그도 그럴 것이 요즘 웹 브라우저 엔진은 단순히 HTML을 파싱하는 문서 렌더러가 절대 아니고... 거의 독자적인 운영체제, 가상 머신, 프로그래밍 언어 런타임 급이 됐기 때문이다. 미치도록 거대할 수밖에 없다.

Visual Studio Code도 주 실행 파일인 code.exe가 160MB가 넘으니 엄청 큰 편이다. 얘도 파일 안을 들여다보면 무식한 리소스빨이 아니며, 전체의 3/4 가까이는 순수 기계어 실행 코드이다. 심지어 1년쯤 전엔 150MB대였던 걸로 기억하는데 업데이트를 거듭하면서 더 커졌다~!
그에 비해 내 한글 입력기는 코어 dll이 딱 1MB가 될까말까이다.;; 거기에다 기본 플러그 인 로딩까지 하면 1.5MB 정도 된다.;;

2. 버전 넘버링

마소의 Visual Studio와 Office는 Windows와 더불어 마소를 먹여 살리는 핵심 제품이다.
그런데 얘들은 2010년대 중반, Windows 10 무렵부터 버전을 크게 올리지 않고 깨작깨작 소수점 둘째 자리만 건드리는 게 관행이 됐다. 겉으로 크게 표시되는 연도 버전 말고, 내부의 번호 버전 말이다.

VS는 2015부터, Office는 2016부터 16.x 버전이 유지되고 있다. 그나마 VS는 2022가 출시되면서 번호가 17.x로 올라가긴 했지만, _MSC_VER의 값은 여전히 19xx대 고정이다.
뭐, Windows 역시 10부터 내부 파일들의 버전 역시 10.x 고정이긴 하다. 얘는 10을 끝으로 새 버전 브랜드를 더 만들지 않을 것처럼 얘기했다가 결국 11, 12를 내면서 입장을 번복하게 됐는데.. 그래도 11도 겉으로만 그럴 뿐, 내부 번호는 여전히 10이다.

10년 넘게, 거의 20년 가까이 1.0도 아니고 0.x대 버전을 유지하고 있는 건 DOSBox 내지 putty 정도인 것 같다.
그 반면, 웹브라우저 쪽은 크롬이 주 버전 번호를 팍팍 올리는 관행을 만들었다. 얘는 버전이 12도 아니고 이미 12x을 넘어섰다. 무려 백 자리..

Java의 경우, 한때 1.3, 1.4 이렇게 번호를 올리다가 2010년대부턴가 그냥 7, 8, 9로 넘버링 방식을 바꿨다. 주 번호를 계속 1로 유지하는 게 별 의미가 없다고 판단한 듯하다.
애플 진영도 macOS X이라고 해서 한때 10.1, 10.2, 10.3 ... 이러다가 나중에는 11, 12, ..., 14.x로 주 번호를 올리기 시작했다. Windows와 macOS 모두 버전의 주 번호에서 10을 떼어냈는데.. 내 한글 입력기는 언제쯤 10을 졸업할지? =_=;;

3. UI 트렌드

(1) 소프트웨어에서 자신의 종합적인 옵션/preference를 설정하는 명령이 있는 메뉴는? 보통은 '도구' 메뉴의 맨 끄트머리에 있는 게 관행인데, (마소 UI 디자인 가이드라인) 이게 약간 케바케 성향이 있는 것 같다. 크로스 플랫폼 제품 중에는 편집이나 심지어 파일 메뉴에 배치된 경우도 있다.

Windows 3.1 시절 옛날에는 아예 '옵션'이라는 메뉴가 따로 있기도 했다. 하지만 그런 관행은 95의 도입과 함께 거의 사라졌다. 수십-수백 개에 달하는 옵션들을 지정하는 단일 대화상자가 탭이나 웹페이지 형태로 거대하게 바뀌었을 뿐.
옛날에 아래아한글 2.0은 1.5x 이후로 기능 추가와 구조 변화가 워낙 많았던 제품인지라, 새로 추가된 옵션들이 '선택사항 - 기타'의 부메뉴로 중구난방으로 쭈루룩 달렸던 게 개인적으로 인상적이었다.;;;

(2) 데스크톱 프로그램이건, 웹사이트건.. '다크 모드'를 제공하는 게 요즘 완전 유행이 됐다.
글쎄, Windows에서 이거 전신은 '고대비 검정'이 아닐까 싶은데.. 이건 사용자 취향보다는 장애인 접근성이나 특수한 디스플레이 환경을 고려한 기능이었다.
아울러, 아이콘들의 디자인이 알록달록 대신 단촐해지면서 그림보다는 픽토그램에 더 가까워진다. 표현 형태도 벡터 폰트에 더 가까워졌다.

(3) SNS가 발달하면서 어디서나 사람 언급은 @, 키워드 태그는 #.. 이게 관행이 됐다.
이모지에다 별도의 문자 코드를 배당한다니 이게 도대체 무슨 일인가 싶었다만.. 이제는 게시글에 대한 피드백(좋아요, 놀라워요, 화나요 등등)조차도 거의 국제 표준을 제정해도 될 것 같다. 정말 2, 30년 전에 ICQ니 msn 메신저니, 네이트온 쓰던 시절에는 상상도 못 했던 관행이 생겼다.

(4) 리눅스 셸이 GNOME이냐 KDE냐 하는 건, 통신사를 SKT 쓰냐 KT 쓰냐 하는 것처럼 느껴진다. ㄲㄲㄲㄲ
개인적으로는 우분투+GNOME 말고 딴 건 접해 보지 못했다. 우분투가 대세인 듯..

(5) 어떤 컴퓨터를 원격으로 접속해서 사용하는 방법이란 게 전통적으로 (1) 명령 프롬프트(터미널), (2) 파일 시스템(FTP)으로 나뉘는 편이었다. 하지만 요즘은 컴터 성능과 네트워크 속도의 향상 덕분에 GUI 셸, 데스크톱을 통째로 가져와서 원격으로 쓰기도 한다. 이를 구현하는 프로토콜은 표준으로 채택된 게 있는지, 아니면 제품별로 다 찢어져 있는지 궁금하다.
이건 '텍' 같은 전산 조판 언어로 코딩하듯이 문서를 만들던 게, 그냥 GUI 위지윅 워드 프로세서로 바뀐 거나 마찬가지다.

(6) 크롬 브라우저에 있는 adblock 애드인은 단순히 웹사이트 한구석에 붙은 구글 광고만 차단하는 줄 알았더니만.. 유튜브의 짜증나는 6초~15초짜리 광고들까지 몽땅 차단 박고 스킵시켜 주는구나.. 오오~ 매우 놀랍다.
그런데 유튜브의 엔지니어들도 바보가 아닐 것이고 광고주의 자기들 밥줄을 끊는 짓은 단속하지 않을까..?? 창과 방패의 싸움이 계속될 듯하다.
유튜브를 exploit하는 두 가지 방법이 광고 차단이랑 동영상 다운로드인 셈이다.

4. 소프트웨어 업데이트

요즘은 소프트웨어의 보안 취약점 내지, 이를 이용해 증식하는 악성 코드가 야기하는 문제가 심각하다. 특히 랜섬웨어한테 자기 컴터나 심지어 직장 업무용 컴터가 털렸다는 소식은 본인조차 주변 지인으로부터 심심찮게 들었을 정도이다. 교통사고로 지인 누구가 다쳤다는 소식에 근접할 정도로 꽤 가까워지고 흔해졌다.

마소에서 보안, 보안 노래를 부르면서 모든 사용자에게 보안 업데이트를 끄지도 못하는 반강제로 주입시키고, 심지어 정품 인증에 실패한 불법 복제 Windows에다가도 보안 업데이트만은 무료로 꼬박꼬박 시켜 주는 건 다 이유가 있다.
악성 코드한테 털려서 좀비가 된 컴터는 다른 멀쩡한 컴터한테도 해를 끼치기 때문이다.

소프트웨어가 단순히 기능 추가나 자기 동작 차원의 버그 수정만 필요하다면 업데이트를 이렇게 귀찮을 정도로 강요할 필요가 없다. 하지만 지금은 보안 업데이트가 인간한테 주요 전염병 백신과 비슷한 존재가 돼 버렸지 말이다.

하지만 그럼에도 불구하고 요즘 Windows 업데이트는 너무 과한 구석이 있다. 악성 코드가 아니라 업데이트 서비스 네놈이 평소에 컴터 CPU를 과도하게 잡아먹고, 긴급히 컴터를 쓰고 싶은 상황에서도 세월아 네월아 재부팅을 강요한다.
그래서 요즘은 Windows를 부팅시켜 놓고 몇 주~몇 달째 계속 부팅 상태를 유지하며 켜 놓는 게(완전히 끄지 않고 절전 모드 전환도 포함) 사실상 불가능하다. 업데이트 설치 핑계로 지들이 제멋대로 재부팅을 해 버리기 때문이다.

옛날에 Windows 9x 시절이야 운영체제가 불안정하고, 16비트 영역의 메모리 리소스가 고갈됐기 때문에 컴을 오래 켜 놓을 수 없었다. 그때는 재부팅 정도가 아니라 운영체제 재설치까지 주기적으로 해야 했을 정도였다.
지금이야 그런 미개한 요인들이 당연히 전혀 존재하지 않는다. 그런데도 컴을 오래 켜 놓지 못한다는 거다. 이게 말이나 되냐?

5. 터미널 환경에서의 동작

개발자? 프로그래머? 소프트웨어 엔지니어? 암튼 이 바닥 종사하는 사람은 일반인들보다는 컴퓨터에서 GUI가 아니라 '명령 프롬프트'를 다룰 일이 더 많다.
Windows의 명령 프롬프트는 말할 것도 없고 PowerShell, Visual Studio Code, putty, Windows Terminal, 리눅스의 명령 프롬프트 등.. 다양한 프로그램에서 터미널을 쓰다 보면..

화면에 뜬 텍스트를 블록 잡고 복사하는 간단한 조작을 좀 하고 싶은데 키보드나 마우스 동작이 미묘하게 서로 달라서 불편을 겪곤 한다.
putty는 우클릭만으로 명령어 붙여넣기가 되는 반면, 어떤 데서는 그게 휠 클릭이고 우클릭은 일반적인 컨텍스트 메뉴 표시이다.

어떤 곳에서는 블록을 잡고 나서 Ctrl+C로 복사를 시키는 반면, 어떤 데서는 그랬다가는 실행 중지 Ctrl+C가 곧이곧대로 전달된다. 한 프로그램의 단축키와 동작에 익숙해졌는데 딴 프로그램에서는 그게 통하지 않아서 개인적으로 혼란스러웠다. =_=;;
개인적으로는 터미널의 GUI 차원에서 특정 문자열이 등장했을 때 highlight 시키는 기능, 그리고 구획을 나눠서 clear을 시키면 최신 구획의 텍스트만 다 날리는 기능 같은 게 있었으면 좋겠다.

터미널은 컴퓨터에 접근해서 뭔가 조작을 하는 제일 저렴하고 효율적인 방법임이 틀림없다. 이거 아니면 파일 시스템만 다루는 FTP.. 하지만 요즘은 컴터 성능과 네트워크 속도가 받쳐주다 보니 아예 원격 데스크톱 GUI 화면을 통째로 쏴 주는 가상화도 가능해졌고, 이게 터미널과 FTP 기능까지 상당 부분 흡수한 상태이다. 인터넷이 괜히 WWW가 닥치고 짱이 된 게 아니듯이 말이다.

6. 나머지 불편하거나 궁금한 거

(1) 10여 년 전, Windows 7쯤이었나? SSD 하드라는 게 처음 도입됐을 때 말이다. 하드디스크가 통째로 램 드라이브로 바뀌는 거나 마찬가지였기 때문에 부팅 속도가 획기적으로 빨라져서 신기하다고 난리였다.
그러나 Windows 10이니 11이니 하는 지금은..?? C 드라이브에 다들 SSD를 쓰고 있는 세상인데도 부팅 시간이 옛날에 재래식 하드로 Windows XP나 7을 부팅하는 것과 비슷하게 느껴진다.

디스크 속도가 올라간 것 이상으로 Windows도 더 무거워지고 이것저것 불러들이는 게 많아졌기 때문일 것이다. 에휴~
옛날에 디지털 카메라가 싸구려 기종이라도 폰카보다 좋은 게 물리적인 zoom 기능 말고도.. 부담 없이 끄고 켜는 게 가능하고 부팅이 아주 신속하게 된다는 것이었다. 디카에는 컴퓨터가 들어있긴 하지만 '범용 컴퓨터'가 들어있는 건 아니었기 때문이다.;;

(2) Windows 10/11의 시작 메뉴에서 검색란에다가 타이핑을 했는데 원하는 프로그램 검색이 안 되고 멀뚱멀뚱 있는 버그 말이다. 정말 악명 높지 않았는가?
글쎄, 내가 완전 최신 버전을 쓰고 있지는 않아서 잘 모르겠지만, 설마 아직까지 그 버그를 달고 다니지는 않으리라 추측한다.
이건 개인적으로 Win10의 사용 경험을 크게 악화시킨 버그였다. 사용자가 현실에서 엄청 자주 사용하게 될 기능이 이 따위로 동작하다니, 품질 관리를 도대체 어떻게 한 건지?

(3) Windows 8 시절부터 전통적으로 전해 내려오던 메트로 앱 '메일'이 요 근래에는 New Outlook으로 몰래, 쓰윽 대체된 듯하다. 수십 년 전에 있었던 Outlook Express의 후신이 등장한 것 같다만.. 개인적으로는 내가 관심 없고 사용하지 않는 프로그램이 제멋대로 설치되는 건 비호감이다. 이건 그놈의 보안하고도 아무 관련 없는 사항이지 않은가.

그리고 마소에서도 화상 회의 앱에 관심이 생겼는지 Microsoft Teams라는 걸 만들었는가 보다. 내가 실행하지도 않은 녀석이 제멋대로 깔려서 CPU를 잡아먹고 있길래 바로 강제 종료하고 제거해 버렸다.
악성코드를 빌미로 지들이 악성코드처럼 구는 거는 난 절대 용납 못 한다.

(4) 이건 PC가 아니라 잠시 스마트폰 얘기이다만.. 사용자가 입력하는 텍스트를 자동 완성 내지 오타 교정한답시고 사용자가 진짜로 의도한 문자열까지 제멋대로 바꿔 버리는 거 말이다. 아이폰이 여전히 악명 높은가 보다.
주변에서 이렇게 의도하지 않은 오타를 내는 사람을 많이 봤고, 나도 아이폰 쓰던 시절엔 이것 때문에 난감한 일을 몇 번 겪어 봤다.

난 내가 입력한 텍스트에는 내가 직접 책임을 지고 싶어서.. 마소 워드가 기본 제공하는 자동 고침 기능조차도 오지랖 불편함을 느끼는 사람이다. (대소문자, 줄표 등등~~) 자동 고침을 할 거면 그걸 철회하고 사용자의 원래 텍스트로 되돌리는 UI라도 주변에 눈에 띄게 넣든가.. 아이폰은 내 기억으로 그런 게 없었다.

(5) 어느 컴퓨터에나 프로그램 설치/제거 리스트를 보면.. 서버 개발자도 아닌 엔드 유저한테 MS SQL server는 누가 언제 왜 잔뜩 설치하는지 모르겠다. 도대체 어디에 쓰이는 물건인 걸까..??? 최신 버전도 아니고 그냥 2008인데 말이다.
옛날 win7 시절에는 '실버라이트'라는 제품도 슬그머니 깔리곤 했는데 그건 망했기 때문에 요즘은 눈에 띄지 않는다.

(6) Visual Studio라든가 아래아한글 같은 프로그램은 자체적인 설치 관리자 내지 업데이터를 보유하고 있는 제품이다. 그런데 뭔가 새 마이너 버전이 나와서 업데이트를 찍으면.. 업데이터 자기 자신부터 업데이트 되는 경우가 엄청 잦다. 그냥 심심하면 업데이트 된다.
업데이터는.. 일관된 체계로 버전 체크를 하고 새 패키지를 다운로드하고 파일 복사, 덮어쓰기, 삭제하는 기능이 전부일 텐데.. 한번 잘 만들어 놓고 나면 고칠 일이 거의 없을 텐데?? 내부적으로 뭐가 그렇게 자주 바뀔 게 있는지 개인적으로 매우 궁금하다.

Posted by 사무엘

본인은 내 연배 사람들의 평균 이상으로, 심지어 나보다 나이가 더 많은 사람들 이상으로 레트로 컴퓨팅에 관심이 많다. 그 이유는.. 글쎄, 그 시절 당대엔 너무 비싸서 만져 볼 엄두를 못 냈던 최신 최고급 최첨단 하드웨어와 소프트웨어들이 지금은 너무 값싸지고, 싸구려를 넘어 역사 속의 퇴물이 된 게 경이롭고 신기하게 느껴지기 때문인 것 같다.

어린 시절에 굶주림을 겪었던 기성세대들이 지금 이렇게 먹거리가 싸고 풍부해진 뒤에도 늘 절약하고 비상시를 생각하고 많이 쌓아 놓는 습관을 평생 못 버리는 편이라지 않는가?
그런 것처럼 본인은 어린 시절에 저런 식으로 최신 문물의 이기에 대한 욕구불만(?)을 겪었던 게 지금 이런 추억과 집착으로 표출되는 것 같다. 나 자신에 대해 스스로 생각해 보니 그렇게 느껴진다.

1. 메모리

16비트 컴퓨터는 8비트보다야 훨씬 더 풍족한 환경이다. 특히 한글· 한자 같은 복잡한 문자까지 실용적인 해상도로 표현할 수 있을 정도로 성능이 받쳐 주는 마지노 선이기도 하다. CPU 속도뿐만 아니라 메모리(폰트..)나 그래픽(해상도)에서도 말이다.

하지만 컴퓨터 성능이 좀 더 향상되자 16비트도 금세 한계를 보였다. 16비트는 그 특성상 가깝게는 64KB, 그리고 x86 PC 기준 거시적으로는 1MB / 640KB의 한계에 매여서 이걸 극복하느라 온갖 지저분하고 복잡한 편법이 동원되어야 한 암울한 환경이기도 했다.
세그먼트가 어떻고 메모리 모델이 어떻고 far 포인터가 어떻고..;; 그리고 EMS는 뭐고 XMS는 뭐냐. x86 PC 말고 다른 16비트 CPU 동네에서는 상황이 어땠는지 개인적으로 매우 궁금하다.

EMS는 뭔가 특수한 방법으로 접근하는 부가적인 메모리를 장착해서 1MB 이상의 물리 메모리를 확보하는 방식이었다. 글쎄, EMM386이라는 도스 드라이버 이름이 암시하는 것과는 달리, 얘가 XT 시절부터 먼저 등장했다.
그러다가 80286 CPU의 기능을 활용해서 XMS라는 규격이 추가로 등장했다. 얘가 진짜로 더 자연스럽고 직관적인 방식으로 주 메모리의 연장선상으로 메모리를 더 확장해 준다.

MS-DOS 5.0에서 himem.sys라는 드라이버가 추가됐는데 이건 그냥 이유 불문하고 필수 로딩 드라이버였다. 그리고 DOS=HIGH니 LOADHIGH (LH)니, 뭔가 HI/HIGH가 붙은 게 그야말로 640KB 기본 메모리를 확보하기 위한 마법의 주문인 것처럼 컴퓨터 잡지에서 소개되곤 했다.
1MB 이상 메모리를 확보하는 것 자체는 가능했지만 현실에서 컴퓨터가 정보를 직통으로 취급하는 최소 단위는 여전히 64KB였고, 그나마도 접근성이 제일 좋은 영역은 1MB에서 그나마 384KB를 떼어낸 하위 640KB였기 때문이다. 뭐가 이리 복잡해..

정리하자면 EMS가 먼저 등장했고, 그 다음이 XMS이다. EMS는 확장 메모리를 반쯤 파일처럼 취급하는 방식인 반면, XMS에서는 같은 16비트이지만 286 CPU의 기능을 활용해서 확장 메모리에 CPU가 직통 접근 가능해졌다. 그리고 기존 도스용 프로그램이나 드라이버를 640KB 이후의 상위 영역에다가 올려 놓는 기법도 XMS와 함께 등장했다.
메모리 운용 방식이 까탈맞은 게임 중에서는 emm386 구동 절대 금지, 또는 반대로 EMS 필수.. 이러는 경우가 있었다. 이러니 config.sys 내용이 걸레짝처럼 복잡해질 수밖에 없었다. 도스 6.0에서는 멀티부팅이라는 기능까지 등장했고 말이다.

물론 어떤 경우에든 640KB 이전 기본 메모리를 최대한 많이 확보해 놓는 건 필수였다. 이게 마치 Windows 3.x 리소스 퍼센티지와 비슷한 개념이었다. 부팅 직후에 580~600KB 정도 남아 있으면 최적화를 아주 잘 한 것이었는데.. 한글 바이오스, 씨디롬, 디스크 캐시 같은 것들을 띄우다 보면 메모리가 금세 뚝뚝 줄어들었다.

이런 복잡한 메모리 삽질은 386 이상 CPU에서 제공하는 보호 모드, 가상 메모리 기능과 함께 역사 속으로 사라졌다. DPMI는 EMS/XMS 따위보다 더 상위 기술을 명시하는 규격이다. 32비트 도스 extender가 그 시절엔 정말 구세주 소리를 듣지 않을 수 없었다. 1990년 중반대의 도스용 게임을 실행할 때 DOS/4G 시그널이 뜨는 게 정말 간지 그 자체였다. ^^

2. 도스용 디바이스 드라이버(sys)

도스 시절에는 컴퓨터에 어떤 하드웨어를 인식시키기 위해서 해당 장치의 드라이버를 실행해서 올리는 절차가 있었다. config.sys라는 시작 스크립트에다가 DEVICE=어쩌구저쩌구 드라이버 파일 경로를 지정해 주면 됐다. 이건 무려 MS-DOS 2.0 시절부터 있었던 전통이라고 한다.

여기서 개인적으로 의문이 들었다. DEVICE로 로딩되는 *.sys 드라이버들은 분명 컴파일된 기계어 코드가 들어있는 실행 파일의 특수한 형태일 텐데.. 얘는 어떻게 만드는 걸까?
옛날 자료를 뒤져 보니 1980년대에 MS C 4.0 (!!! Visual C++ 4가 아님!)과 매크로 어셈블러를 써서 빌드하고 만든 경우가 있었다고 한다. ㄲㄲㄲㄲㄲㄲ
com과 비슷한데 그래도 자그마한 헤더가 들어있으며, 나름 한 sys 파일 안에 2개 이상 여러 드라이버가 있을 수도 있었나 보다.

config.sys는 부팅 때 단 한 번만 실행됐다. 부팅이 끝난 뒤에 얘들을 다시 실행하거나, 실행된 디바이스 드라이버를 제거할 수 없었다. 그러니 다루기가 좀 불편하다.
그 시절엔 부팅 후에 sys 파일을 실행해 주는 별도의 유틸리티가 있었다. 얘는 어떤 원리로 동작했는지 모르겠다만, 개인적으로 유용하게 썼던 기억이 남아 있다.

그리고 시스템을 건드리는 유틸이 처음엔 sys 형태로 개발되었지만 나중에 exe 형태로 바뀐 경우도 종종 있었다.
emm386 드라이버가 대표적인 예이고(DOS 4.0에서는 sys, 5.0 이후부터 exe), 디스크 캐시라든가 램 드라이브, 각종 한글 바이오스 소프트웨어도 1980년대엔 sys이다가 나중에 com/exe 기반의 램 상주 프로그램으로 바뀌었다.
마우스 드라이버는 sys였던 적이 없이 전통적으로 mouse.com이었던 것 같고..;; 그때는 msherc나 simcga처럼 그래픽 카드를 흉내 내는 램 상주 드라이버도 있었다.

나중에 Windows 9x 시절에는 vxd라는 드라이버가 있었는데 NT 계열부터는 소리 소문 없이 사라졌다.
도스용 아래아한글이나 이야기(PC통신!!)에서 쓰였던 덧실행 프로그램도 뭔가 특수하게 빌드된 프로그램이지 싶은데..
이렇게 기계어 코드를 생성하는 계층이랑, 껍데기 실행 파일을 생성하는 계층이 같지 않으니 컴파일러와 링커의 계층이 구분되었던 것 같다. 마치 압축 알고리즘과 컨테이너 구조의 차이와 비슷하다.

3. PC 스피커로 현실 사운드 흉내 내기

오늘날 우리가 사용하는 PC의 원조인 IBM PC라는 건 원래 업무용으로 개발됐다. 이 때문에 그래픽이나 사운드 쪽 지원은 원가 절감을 위해 우선순위에서 밀렸으며, 당대의 타 컴퓨터들에 비해 스펙이 뒤쳐졌다.
그래픽이야 초창기 CGA니 EGA니 하던 IBM 보급품이 얼마나 열악했는지는 더 설명이 필요하지 않고.. 사운드도 상황이 다르지 않았다. PC 스피커라고 불리던 IBM 보급품은 그냥 삑삑 띡띡거리면서(beep) 오류가 발생했을 때 최소한의 자기 상태만 청각 피드백으로 전달할 수 있는 정말 원시적인 물건이었다.

자연에서 발생하는 소리는 아무래도 부드러운 삼각함수 곡선의 합성으로 표현된다. 허나, 이 PC 스피커는 얼마나 단순했으면 생성 가능한 소리의 파형이 최대값 아니면 최소값으로 이산적-_-이었다. 음량을 나타내는 진폭조차 조절이 안 되고.. 진짜 그 특유의 날카롭고 투박한 비프음밖에 내지 못한 것이다. 자연스러운 삼각함수이면 소리굽쇠나 전화기 신호음 비슷한 소리라도 났을 텐데, 그렇지도 않다. ^^

그런데 1980년대 말에는 RealSound라고 PC 스피커를 극한까지 튜닝해서 얘만으로 최소한 단음 멜로디보다는 더 정교한 소리를 내는 기법이 개발되어 쓰였다고 한다. 단순투박한 비프음이라도 다양한 주파수로 아주 잘게 쪼개고, 이것들을 합성해서 또 다른 소리를 만들어 내는 거다. 이미지에서 디더링의 사운드 버전이나 마찬가지다.

이렇게 해서 표현 가능한 음질은 채널은 당연히 모노 한정이고, sampling rate는 11khz와 22khz의 중간인 18khz 남짓이었다고 한다. 그 시절 컴퓨터 사양을 감안하면 나쁘지 않았다.
다만, 문제는 표현 가능한 음색이랄까 이거 구분이 6비트밖에 안 됐다는 거..

아까 오리지날 PC 스피커는 최대값 아니면 최소값 2단계뿐이니 1비트인데, 이걸 딱 32배까지 늘리는 게 한계였다.
실용적인 사운드 카드에서는 최저 음질이 8비트부터(256) 시작이고 CD급 음질이라면 16비트가 보통인데 6비트는 확실히 자연스러운 소리를 재현하기에는 부족한 음질이었다.

이걸로 청취 가능한 사람 목소리를 낼 수는 있었다. 하지만 칙칙한 금속 기계음이 섞인 저음 남자 목소리 정도나 내며, 유선 전화기보다도 음질이 안 좋았다. 그냥 전용 사운드 카드로 음질 더 좋은 사운드를 내보내는 것보다 CPU에 걸리는 부하도 더 컸을 것이다.

하지만 비싼 사운드 카드 없이 보급 PC 스피커만으로 삑삑 단음이 아니라 사람 목소리 비스무리한 거, 툭툭 소리, 비트가 가미된 테크노 BGM이 흘러나오는 것만으로도 어디냐. (☞ 예시 1 / 예시 2)
PC 스피커로 사운드 카드 흉내를 내는 기술은 소수의 게임이나 유틸에서 알음알음 전수되어 쓰였던 것 같다. 그래픽 분야로 치면 VGA mode X라든가 CGA 160*100 16컬러 같은 꼼수와 비슷해 보인다.

4. 텍스트 모드 폰트

1980년대에 PC의 그래픽 카드는 CGA, EGA를 거쳐 VGA로 업그레이드 됐다. 그 과정을 거치면서 그래픽 모드의 해상도가 올라가고 지원되는 색깔 수가 늘었다.
덕분에 그래픽이 아닌 텍스트 모드에서도 자그마한 8*8 폰트를 동원해서 종전의 25줄이 아니라 43/50줄을 표시할 수 있게 됐다.
하긴, 요즘이야 큼직한 화면에서 70~80줄도 한번에 보면서 코딩을 하는데.. 꼴랑 25줄은 화면이 작아도 너무 작다.;;;

이렇게 색깔과 해상도가 올라간 거야 수긍이 가는 변화인데, 이것 말고 EGA/VGA가 과거의 CGA에 비해 향상된 게 더 있었다. 바로 텍스트의 폰트를 customize할 수 있게 된 것이다.
CGA에서는 그 알량한 폰트가 ROM에 박혀 있었던 반면, EGA/VGA에서는 이게 가변적인 RAM 영역으로 옮겨졌다. 정확하게는 자기네 ROM으로부터의 복사본이겠지만..

이 덕분에 몇몇 창의적인 프로그램들은 비록 텍스트 모드에서 돌아가지만 128번 이후의 특수문자들을 마개조해서 GUI 비주얼을 얼추 구현할 수 있었다. 도스용 Norton 유틸리티가 대표적인 예다.

체크나 라디오 버튼, 스크롤바 버튼을 그럴싸하게 그려 넣는 건 기본이고, 더 압권인 건 마우스 포인터까지 그래픽 모드처럼 구현했다는 것이다. 당장 위의 스샷을 보시라~! 지금 저건 텍스트 모드인데도 말이다!!
마우스 포인터가 차지하는 4개 영역에는 기존 문자에다가 마우스 포인터를 위치별로 합성한 4개 문자를 실시간으로 생성해서 그때 그때 바꿔 준 것이다. 이게 그 당시 하드웨어로 어떻게 가능했는지 모르겠다.;;

이런 비디오 마개조는 한글 바이오스 같은 프로그램과는 당연히 상극이었기 때문에 같이 사용할 수 없었다. 그러고 보니..

• VGA에서 텍스트 모드의 해상도는 640*400이 아니라 720*400이었다. 폰트는 8*16 것을 쓰지만 글자 사이에 1픽셀 여백이 있었다. 단지, 몇몇 선문자는 예외적으로 그 여백 부분까지 픽셀을 채웠기 때문에 선이 한데 이어져서 보였을 뿐이다.
• VGA 텍스트 모드에서는 글자색은 16개가 지원됐지만 배경색은 기본적으로 어두운 계열 8개만 지원됐다. 그러고 글자색을 깜빡거리게 하든지, 아니면 깜빡이지 않는 대신 밝은 계열 배경색 8개를 추가로 사용할지를 무슨 API를 통해 지정할 수 있었다. 참 신기한 형태의 설계이다.
• VGA가 아니라 모노크롬 MDA 시절에는 색깔이 없는 대신 글자에 진하게, 밑줄 같은 속성을 줄 수 있었고..ㄷㄷㄷ
• 그런데 개인적으로 텍스트 모드에서 이런 색깔 장난질을 할 수 있었던 언어는 베이식밖에 없었다. C/파스칼엔 텍스트 색깔 지정과 관련된 표준 API가 없었기 때문이다. (3rd party 라이브러리를 써야..)

Posted by 사무엘

마이크로소프트는... 하버드 나와서 겨우 교수나 변호사나 대기업 사원이나 쳐 하며 썩기에는 너무 똑똑하고 똘끼 넘치던 젊은 컴덕 악동 몇 명이 1975년에 설립한 소프트웨어 개발 기업이다.
마소는 처음에는 대기업 하드웨어에 같이 들어가는 프로그램을 납품하며 근근이 먹고 살았다. 그러나 결국은 전세계 PC에서 운영체제와 오피스 소프트웨어를 평정해 버렸다. 자기 소프트웨어 단독으로 먹고 살 수 있게 된 것이다.

이 시절에 컴터 프로그래밍은 16비트 x86 어셈블리 프로그래밍이 필수였다. 어셈블리어를 읽을 뿐만 아니라 직접 짤 수도 있어야 했다~! 하드웨어를 직접 제어하고, 귀한 메모리를 1바이트라도 아끼고, CPU 클럭을 1사이클이라도 아끼기 위해서다.
설립자인 빌 게이츠 자신이 베이식 인터프리터.. 일종의 가상 머신을 어셈블리어로 처음부터 끝까지 몽땅 아니면 대부분을 직접 코딩했었다. 수식 파싱, 메모리 관리, 각종 기하와 수학 알고리즘까지 전공 서적 찾아가면서 직접..

그는 천재 괴짜에 엄청난 워커홀릭이었다. (뭐, 컴터 업계에 빌만 그런 건 아니었겠지만) 그래서 결혼도 나이 40이 다 돼서야 했다. 물론, 억만장자 갑부가 됐으니 나이 따위는 결혼에 아무런 영향을 주지 않는 처지였다. 결혼식 때 호텔 하나를 통째로 전세 냈다.

그는 자기부터가 그런 기질이니, 초창기엔 부하 직원들도 왕창 쪼고 갈구고, 작업 결과물에 헛점이 보이면 고함 지르고 쌍욕 퍼부으면서 개X랄을 떨었던 걸로 악명 높았다. 경쟁사의 잡스만 성질이 더러운 게 아니었다.
그런 데다 빌은 회장 대표이사라면서 거의 말단 직원의 직속상사 급으로 부하들의 업무 디테일을 다 꿰뚫고 있는 괴수였다. 이 사람의 손바닥을 빠져나갈 방법은 전혀 없었다.

전직 마소 출신 직원이 지은 “조엘 온 소프트웨어”라는 책에 1990년대 초의 일화가 짤막하게 소개돼 있다.
직원들이 “이 양반.. 나이 30 중반이 되고 나니 그래도 갈굴 때 쌍욕(F***)이 좀 줄어들었네..”라고 회장 뒷담화를 한 것 말이다. ㄲㄲㄲㄲㄲ

Windows 3.0이 대성공을 거둬서 마소가 그럭저럭 먹고 살 만해지고 Windows NT에다 COM/OLE이라는 걸 처음 만들 때.. 더 나아가서 ActiveX라는 컴포넌트까지 만들던 90년대 초-중반이 마소의 입장에서는 기술적인 중흥기 리즈 시절이 아니었나 싶다.
빌 회장님의 애환이 깃든 Visual Basic 자체를 COM 기반으로 완전히 싹 다시 만들고(버전 4).. 얘는 내가 생각하기에 가장 토종 마소스러운 기술인 것 같다. 후대의 .NET이야 볼랜드 출신의 그 엔지니어의 입김이 많이 들어갔겠지만 말이다.

이렇듯, 빌 게이츠는 엔지니어와 사업가 자질이 둘 다 두루 탁월했던 사람이다. 그는 컴퓨터를 그냥 오덕질이나 자아실현, 그냥 극한 시험용으로 쓰는 게 아니라, 이걸 전세계 남녀노소의 모든 민간인들에게 팔아먹고 그 짓을 하기 위한 보편적인 소프트웨어를 만들 생각을 했다.
소수의 빠, 매니아 위주로 신비주의 마케팅을 했던 애플 진영과 대비되는 면모이다. 그렇기 때문에 빌은 잡스와 달리 그냥 장사꾼 같지, 무슨 ‘교주’ 같은 인상은 별로 없다. -_-

빌은 장사꾼으로서 소프트웨어 불법복제에 대해 민감하게 반응했고 오픈소스 진영과는 적대적이었다. 2000년대 이후로는 스팸 메일을 특별히 싫어해서 이런 거 거르는 솔루션의 개발에 몸소 친히 관여하기도 했었다. 그는 이렇게 말했던 적이 있다.
“저도 여느 사람들과 마찬가지로 스팸 메일을 왕창 많이 받습니다. 저보고 부자 되는 방법을 알려준다느니, 대출 많이 쉽게 받는 방법을 알려준다는 거예요. 웃기지 않는다면 거짓말이겠죠” ㄲㄲㄲㄲㄲㄲㄲ

빌 휘하에서 마소는 생존과 성장을 위해 대기업 IBM을 통수 쳤고 애플과도 으르렁댔으며, 여러 경쟁업체들을 로비와 독점으로 비열하게 고사시킨 이력이 있다. -_-;; IE 브라우저 독점뿐만 아니라 도스 시절에 Stacker사 Double space 저작권 침해 사건을 기억하는 분이 있으면 완전 아재일 테고.. ^^

그리고 내부적으로는? 요즘도 그런지는 모르겠지만, 마소는 1990년대까지만 해도 매년 근무 성적 하위 5%인 직원은 꾸준히 짤랐다고 전해진다. 빌뿐만 아니라 사장인 스티브 발머도 엘리트 출신에 완전 “오로지 1등”주의였다고 한다. 꽤 살벌한 기업이었다.

그래서 “마소 직원들은 애플이나 구글과 경쟁하는 게 아니라 사내 팀과 경쟁한다” 이런 말이 있었을 정도래나.. 이거 무슨 일본군 육군과 해군의 대립도 아니고.
안에서는 직원을 왕창 갈아넣고, 대외적으로는 저런 짓을 한 것이다. 그게 과거 마소의 놀라운 성장 비결이었다.

아~~ 그래서 그 시절에 Windows 9x와 NT 간에 API가 따로 놀기도 했었고, 한동안 오피스 팀이 파일 열기 대화상자를 Windows 것을 안 쓰고 따로 만들었고.. C 런타임 라이브러리도 Windows 팀과 Visual C++ 팀이 연계가 안 돼서 따로 놀고 그랬구나..!! 싶다.

그랬는데.. 마소는 2000년대 중반부터 성장이 멈추고 몰락의 기미가 보였다.
Windows XP에서 Vista 사이에 이례적으로 시간을 오래 끌었고.. 심지어 IE (브라우저) 팀을 없애고 Windows 팀으로 합치려고도 했다. 그렇게 우왕좌왕 하는 사이에.. 얘들은 모바일에는 완전히 적응을 못 하고 주류에서 밀려났다.

사실, 빌 아저씨도 선견지명이 없는 건 아니었다. 1990년대에 이미 "미래로 가는 길, information at your fingertip" 이라는 비전을 제시했었다.
단지, 그걸 인터넷이 아니라 MSN이라는 독자 독점 프로토콜의 네트워크로 실현하려 했을 뿐이다. 그 시도는 실패했다.

그리고 2010년대에 와서는 뒤늦게 Windows Phone/Mobile을 보급하려 했지만 역시 실패했다. 노키아를 뒤늦게 인수해서 구글과 애플에 맞섰지만 역부족이었다. 주변의 자기 직원조차 아이폰을 쓰고 있는 걸 보자 스티브 발머가 노발대발했었던 건 유명한 일화이다.
이런 뒤숭숭한 와중에 출시된 Windows 8은 괴작으로 시장에서 크게 실패했다. 2000년대에 Windows ME가 실패했던 것과는 좀 다른 방식으로 실패했다.

이런 시기에 빌 게이츠와 스티브 발머 같은 “싸우자 독점하자 이기자” 1세대 경영진이 마소에서 완전히 물러났으며, ‘사티아 나델라’라는 인도 출신의 완전히 새로운 피가 들어왔다. 이를 계기로 오늘날의 마소는 과거의 마소와는 완전히 다른 분위기의 기업으로 변화했다.
돈 안 되는 모바일 사업부는 포기하고, 영원한 원수 같던 오픈소스 진영을 포용하고, 마소가 Windows와 Office만 만드는 회사라는 편견을 깨뜨리려 하는가 보다.

다들 아시다시피 github를 인수하고 한때 빌도 하려 했지만 결렬됐던 id 소프트웨어를 인수하고(정확히는 그 모회사), 심지어 블리자드까지 인수하고.. 각종 옛날 자기네 제품들의 소스를 공개하고. 가히 놀랄 노 짜이다.
앞으로 마소에서 만든 소프트웨어에서도 About 대화상자나 도움말 acknowledge 같은 걸 살펴보면.. 사용된 오픈소스 목록이 쭈루룩~ 나오고 "LPGL 라이선스에 의거해서 우리 제품에서 변경한 소스 부분을 공개합니다"
이런 문구를 보는 날이 올지...?? 내 개인적으로 무척 궁금하다. ^^

대외적으로는 그렇고 사내에서도 “직장 동료는 그저 경쟁하고 싸우는 대상이 아니라, 다같이 발전시켜야 할 대상이다.. 많이 아는 게 아니라 많이 배우는 게 좋은 거다~ 실패를 두려워하지 말라.. 너는 남의 성공에 얼마나 기여했는가?” 뭔가 주토피아 Try everything스러운 사고방식을 회사 차원에서 전파하는 중이라고 한다. 과거의 악랄· 사악했던 이미지를 벗으려고 많이 노력하는가 보다. (그래서 MSDN도 LEARN.microsoft.com으로 바뀐 듯..^^)

일단은 이게 긍정적인 반응을 일으키는 중이며, 마소의 주가도 10년 전에 비해 크게 올랐다.
솔직히 Explorer 브라우저가 독점하던 시절이랑, 이제는 마소에서 자체 Edge 브라우저조차 포기하고 그냥 크롬과 동일한 엔진으로 갈아탄 현 시국은.. 소프트웨어 생태계가 너무 다르다. 당연히 변해야만 살아남을 수 있을 것이다.

다만, 배고프던 시절에 빌이나 발머 같은 1세대 경영자들이 마음 독하게 먹고 지저분한 짓, 욕 먹을 짓을 감행하면서 당장 마르지 않는 돈줄을 확보해 놨기 때문에 후대 경영자가 좋은 여건에서 저렇게 상생 운운하면서 다음 전략을 내놓을 수 있게 됐다는 것도 감안할 점이다. 단지, 언제까지나 1세대 사고방식만 고수하면서 살 수는 없을 뿐이다.

과거에 마소의 킬러 앱들도 1.0 시절부터 100% 순수 오리지널 창작이었던 것은 극히 드물었다. 엑셀 스프레드시트 정도나?
MS-DOS야 CP/M에서 시작됐고 Visual C++의 먼 전신인 MS C는 Lattice C의 소스에서 시작됐으며, IE야 모자이크 브라우저가 원조이다만.. 그것들을 원본보다 크게 발전시킨 것도 능력이다.

뭐, 빌도 인간이다 보니 모든 미래 예상이 적중하지는 않았으며 실패도 했다. 그래도 회사를 말아먹을 정도로 큰 손해를 끼치지는 않을 만큼만 실패했다. 이 역시 옛 경영진의 탁월한 능력이었음이 사실이다. (빌 아저씨는 너무 사용자 친화적인 마케팅 요소에만 집착하다 보니 1990년대 중후반엔 Bob이라든가 Office 길잡이처럼 너무 깜찍한 흑역사;;를 만들었던 적도 있다. ㅎㅎ)

이렇게 시대가 바뀌고 경영진이 바뀌긴 했는데.. 그 뒤부터는 이젠 PC와 Windows가 예전 정도로 중요한 밥줄이 아니어서 그런지..
마소 제품들에서 2, 30년 전에는 상상도 못 했던 나사 빠진 듯한 버그들이 종종 눈에 띄는 중이다. -_- 이게 좀 새로운 부작용인 것 같다. "일단 만들어서 배포부터 한 뒤에 문제가 발견되면 나중에 패치하면 되지..." 이런 군기 빠진 마인드가 마소라고 해서 예외가 아닌 건지도 모르겠다.

※ 여담

(1) 이렇듯, 마소의 운영체제 독식과 브라우저 독식을 종식시킨 것은 스마트폰 모바일 환경, 그리고 오픈소스 진영의 약진이지 싶다. 2004년 파이어폭스, 2008년 크롬은 그야말로 컴퓨팅 환경의 물줄기를 바꿔 놓았다.

(2) 은행 공공기관에서 IE가 완전히 필요 없는 세상은 도래하긴 한 건가? activeX의 대체제인 exe 프로그램은 기술적으로 나은 게 없다고 한때 논란이 많았는데 말이다. 난 여전히 edge+ie 모드에 의존 중이다.
이런 보안 분야는 여전히 웹 표준이 100% 감당이 안 되는가 보다. 오히려 스마트폰 은행 앱은 이 기기를 다른 사람이 쓸 일이 없다고 가정을 해서 그런지 돈 보내는 절차가 더 간단하다.

(3) 1990년대 후반부터 Windows 9x가 완전히 명줄을 다하고 16비트/도스 시절이 완전히 종식되는 데 큰 기여를 한 것은.. 바로 RAM이다. 메모리가 엄청 용량이 늘고 저렴해졌기 때문이다.
win95 나오던 시절에만 해도 램 8~16MB 갖고 빌빌대던 게.. 겨우 98 때 갑자기 64~128MB로 뻥튀기 된 건 정말 경이로운 현상이다. PC의 발전사에서 클럭 속도뿐만 아니라 메모리의 증가도 중요하게 다뤄야 한다. 인텔뿐만 아니라 삼성 전자도 이 시기에 큰 혁신이 있었음이 분명하다.

(4) 과거에 공룡 기업 IBM은 메인프레임 장사가 너무 잘 돼서 그런지 현실에 안주하는 편이었고, PC라고 불리는 개인용 컴터 시장에 대처를 제대로 못 했다. 덕분에 이쪽 주도권을 마소에게 빼앗겨 버렸다.
그런데 그로부터 20년쯤 뒤엔 공룡 기업 마소가 PC의 Windows와 Office에만 안주하다가 스마트폰 모바일 시장에 대처를 제대로 못 했다. 덕분에 그거 주도권은 안드로이드와 iOS 진영에게 완전히 빼앗겨 버렸다.
굉장히 비슷한 패턴의 역사가 반복된 것 같다.

(5) 그러고 보니 2010년대에 애플도 잡스가 죽으면서 최고 경영자가 바뀌었고, 야후에서는 잠시 새로운 여성 CEO가 들어왔다가 나가기도 했다. 그 뒤로 아이폰과 갤럭시 폰은 갈수록 서로 비슷해지며 수렴 진화 중이고, 야후는 여전히 비주류로 밀려난 듯하다.
마리사 메이어는 먹튀 논란이 있긴 했지만.. 그 당시 야후는 어떤 CEO가 들어가더라도 수습이 안 될 정도로 상태가 너무 안 좋기도 했다. 야후 코리아가 없어진 지도 벌써 10년이 넘었구나~!

Posted by 사무엘

1. 격세지감

요즘은 컴퓨팅 환경에서 웹과 모바일이 차지하는 비중이 워낙 커지다 보니..
맨날 컴퓨터를 끼고 살면서도 통상적인 드라이브 - 디렉터리 - 파일이라는 개념을 이해하지 못하는 젊은 세대가 늘고 있다고 그런다. 내 컴 하드의 Program Files 디렉터리 밑에다가 프로그램을 복사해 넣는다는 개념을 알지 못한다.

요즘 꼬마들이 전화기 픽토그램(☎)을 보고 이게 뭔지 이해를 못 한다거나, 플로피디스크를 보고는 저장 아이콘 3D 프린팅이라고 생각한다는데.. 그건 약과다.
얼라들이 아니라 이공계 석박사급 대학원생조차 그런 경우가 있다고 말이다. 물론 전공이 컴공이 아니고, 그저 배우지 않았기 때문에 모를 뿐이다. 머리는 다 갖춰져 있으니 조금 가르쳐 주면 금세 깨우친다.

지난 1980년대부터 컴퓨터라는 게 그저 정부 기관과 기업, 연구소에서나 사용하는 비싸고 귀한 물건에 머물지 않고, 개인별로 구비 가능한 업무 도구 내지 장난감 수준으로 대중화됐다.
8비트 시절엔 얘는 그냥 베이식 프로그래밍 환경 아니면 혼자 하는 게임기였다. 그러다가 16비트 시절엔 게임에 덧붙여 워드(아래아한글) 내지 PC 통신 단말기가 됐다.

이제는 인터넷 단말기 내지 온라인 게임기로 변모한 것 같다. 그 역할도 단순히 유튜브 보거나 음악 듣고 위키 읽고 은행 돈거래 하는 정도는 폰이 흡수해 버렸고, PC는 복잡한 키 조작이 필요한 업무나 게임 전담이다.
이런 와중에 파일 시스템이라는 걸 모르고 정보 저장 매체 실물이란 걸 모르는 세대도 등장했다는 게 참 흥미롭다. ㄲㄲㄲㄲ

2. 스마트폰이 PC와 다른 점

• 노트북 PC보다 더 고도화된 첨단 배터리, 디스플레이, CPU 기술이 모두 융합한 덕분에야 탄생한 물건이다.
• 1년 365일 24시간 내내 켜져 있고 사용자가 늘 갖고 다닌다. 카카오톡 메신저에 PC용 메신저처럼 이 사용자는 "오프라인, 바쁨, 부재" 이렇게 상태를 표시하는 기능이 없다는 걸 생각해 보자.
• 냉각팬이 없다. PC와 완전 동급의 범용적인 컴퓨팅은 못 한다. 이 때문에 동영상 같은 것도 하드웨어 차원에서 특화된 전용 포맷만을 원활하게 재생할 수 있다.
• 마우스 포인터 hovering이라는 인터페이스가 없다. PC에서는 아주 흔한 툴팁이라는 UI 요소가 있을 수 없다.
• 프린터나 유선 랜과의 접점이 없다. 하물며 물리적인 보조 기억장치와는 더욱..
• USIM이라고 붙박이 사용자 정보가 있다. 이거 덕분에 사용자 인증 절차가 PC에 비해 더 단순해질 수 있고, 모바일 뱅킹이 PC 인터넷 뱅킹보다는 덜 번거롭다.
• 프로그래밍 세계가 PC보다는 지저분한 레거시가 훨씬 없고 깔끔하다. 8비트/16비트 같은 건 경험한 적 없다. 그건 모바일이 아니라 아예 임베디드겠지.

3. 무선 인터넷의 통신 모드 전환

요즘 전화기로 인터넷을 할 때는.. 와이파이를 쏴 주는 친숙한 장소에서는 그 와이파이에 붙어서 교신을 하고, 그렇지 않은 임의의 장소에서는 자기가 가입한 요금제대로 데이터를 까서 교신을 하는 게 보통이다. 후자는 LTE니 5G니 하는 기술 이름으로 불리기도 한다.
전화기 역시 등록된 와이파이가 잡히는 곳에서는 거기에 자동으로 접속한다. 하지만 주인님이 밖으로 이동하는 바람에 거기 신호가 너무 약해지고 가망이 없어지면 자기 데이터를 깐다. 그러다가 다시 와이파이가 잡히면 모드가 거기로 바뀐다.

그런데.. 사람에 따라서는 와이파이에서 데이터로 넘어가는 민감도가 너무 낮은 게 불편하게 느껴질 때가 있다.
한 10초~20초 이상은 인터넷이 먹통이 된 뒤에야 뒤늦게 "모바일 데이터에 접속합니다" 이러기 때문이다.

"가능하면, 기본적으로 와이파이를 쓰되, 와이파이가 조금이라도 헬렐레 거리면 바로 데이터 써라~~"
"최대한 데이터 요금을 아껴라~ 한 30초는 기다렸다가 정말 연결이 구리는 게 확실시될 때만 데이터 써라~~"
이게 사람마다 취향이 다를 수 있다. 뭔가 설정을 통해 customize 가능했으면 좋겠다..

이건 자동차 운전으로 치면 자동 변속기의 변속 타이밍/알고리즘과 비슷한 것 같다.
"낮은 rpm에서도 고단으로 최대한 빨리 변속해라. 도저히 가속이 안 되고 차가 못 버틸 때만 불가피하게 저단으로 내려가라. 나는 연비가 중요하다"
"ㄴㄴ~ 밟았을 때 차가 빨리빨리 잘 튀어나가고 잘 가속되는 게 절대적으로 중요하다. 회전수를 3000rpm 이상은 올라갔을 때에나 고단으로 변속해라."

이런 것처럼 말이다.

4. 기타

• 각종 쇼핑몰들은 웹사이트가 있긴 하지만.. 거길 폰으로 접속할 경우, 꼭 자기 전용 앱을 깔아서 보라고 권유하는 편이다.
  그런데 이런 게 PC로 치면 ActiveX나 마찬가지 아니겠는가? 정확히 같은 개념이다~! 그리고 이건 귀찮다. -_-;;
  
  
• 꼬불꼬불 유선전화기는 가정용으로는 퇴출됐지만 인터폰이나 회사 사내 전화기로는 유효하다.
  비슷하게 사용자 상태가 표시되는 PC용 메신저도 가정용으로는 스마트폰 메신저에 밀려 퇴출됐다. (away, offline 상태 표시 없음) 하지만 사내 업무용 메신저는 전통적인 형태가 여전히 유효하다.
  
  
• 웹페이지를 열어 놓고 딴 앱을 쓰다가 한참 뒤에 그 브라우저로 돌아왔을 때.. 쓸데없이 reload를 좀 안 해으면 좋겠다. 그냥 예전에 표시해 놨던 페이지를 다시 보여줄 수 없나?
  
• 스마트폰의 메모장 같은 텍스트 편집 UI에는 undo 기능이 없는지 궁금하다.;;
  
  
• 로그인 기능이 있는 각종 웹사이트들은 id가 틀렸는지 비번이 틀렸는지 따로 정확하게 좀 알려줬으면 좋겠다. "ID 또는 비번이 잘못됐습니다" 이러지 말고. =_=;; id를 입력하자마자 바로 튕기는 건 바라지도 않으니.. 저런다고 특별히 보안이 위험할 것 같지는 않은데 말이다.
  
  
• 텔레비전과 유튜브의 화질이 정말 상상을 초월하게 향상되고 있는 와중에, 전화기의 음성 통화는 예나 지금이나 음성에만 특화된 8000hz급의 초저화질이다. 뭐, 전화 통화하면서 주변 음악을 들려줄 일이 딱히 있지는 않지만.. 그래도 의외의 면모인 것 같다.
  
  
• 은행 사이트들은 언제쯤 IE 외의 브라우저에서도 접속이 가능해질까? 차라리 폰이 나은 지경이 되고 있다.

Posted by 사무엘

1. 포니, 봉고, 엑셀

국산차 중 현대 포니는 동급 배기량 중에서는 전무후무 유일하게 후륜구동이었던 승용차이다.
기아 봉고는 뒷바퀴가 트럭처럼 복륜 형태였던 유일한 소형 승합차이다.

봉고는 한때는 승합차 이름이었지만 지금은 트럭 이름으로만 남아 있다.
엑셀은 한때는 승용차 이름이었지만 지금은 스프레드시트 프로그램의 이름으로만 남아 있다. ㄲㄲㄲㄲㄲ
워드퍼펙, 로터스 1-2-3, dBASE 같은 업무용 프로그램들은 Windows 시대에 적응하지 못하고 도태되고 사라졌다.;;

2. 위험한 데이브

우한 괴질 덕분에 30여 년 전 초딩 시절에 했던 ‘위험한 데이브’ 게임에 새겨져 있던 이 알파벳 이니셜을 다시 주목하게 되는구나~!

(인터넷 좀 뒤져 보니, 저건 PC Arcade를 의도한 거였다고 한다.;;)

저 시절에(1990년경) PC용 게임들은 본격적으로 시작하기 전에 그래픽 모드를 CGA (4색), EGA (16색), VGA (256색) 중 하나 선택하는 게 관행이었다. 한번 선택한 뒤에는 변경할 수 없었고, 딱히 변경할 필요도 없었다.
그런데 저 데이브는 굉장히 이례적이게도, 게임 진행 중에 그래픽 모드를 자유자재로 변경할 수 있었다. 하던 게임을 중단하지 않고 말이다.

그게 가능한 게임은 내가 아는 도스용 수백여 종의 게임 중에 진짜 쟤가 유일한 것 같다~! 신기하지 않은가?
비슷한 시기의 Windows 3.x만 해도 그래픽 모드, 색상, 해상도 따위를 변경한 뒤에는 운영체제를 재시작해야 했는데 말이다. 지정도 제어판이 아니라 설치 관리자를 통해서 해야 했다.

3. 메신저

과거의 icq, msn (훗날 WLM), 스카이프, 그리고 요즘 카카오톡에 이르기까지..
기업에서 만들면서 무료로 뿌리는 메신저 프로그램은 세월이 흐를수록 엄청나게, 불필요하게 덩치 커지고 무거워지는 게 필연적인 수순인 것 같다.
그도 그럴 것이 평범한 채팅 기능만 제공해서는 수익이 나질 않으니 어떤 형태로든 부가적인 서비스를 집어넣어야 하기 때문이다.

카카오톡은 기존 대화 데이터들이 쌓이고 프로그램 자체도 버전업을 거듭하다 보니 예전에 비해 뜨는 데 걸리는 시간이 정말 눈에 띄게 길어졌다. 뭐, 본인은 수 년 이상 묵은 굉장한 구닥다리 전화기를 사용한다는 것도 감안할 점이긴 하지만.. 거의 20~30초씩 걸린다.
PC용 프로그램이었다면 일개 메신저가 스플래시 화면이라도 좀 있어야 할 것 같다.;;

더구나 과거엔 공공장소 입장용 QR 코드를 생성하거나 백신 접종 정보를 불러오는 데도 비슷하게 시간이 너무 오래 걸려서 이것도 불만 사항이었다. 지금이야 백신패스는 아련한 옛날 이야기가 됐지만.. 그래도 프로그램이 최적화와 관련해서 좀 아쉬운 면모가 있다.

4. 블리자드

블리자드가 2018년 이래로 그 누구도 생각하지 못한 빠른 속도로 망조 들고 몰락하고 있는 것이 놀랍다.
무려 2000년경, "환상의 테란"이라는 PC통신(!!) 소설에서는 "서기 2020년, 블리자드는 스타라는 걸작 게임만을 남긴 채 망해 버렸고 게임의 소스 코드는 공개되지 않았으며, 사장은 어느 열받은 테란 플레이어에게 살해 당했다"라는 정말 비현실적인 설정을 제시했었다.

디아블로, 스타, 워크래프트라는 불멸의 명작 대작을 내놓으며 승승장구하던 게임 개발사가 망할 거라고는 그 시절에 누가 상상이나 했겠는가? 그 뒤로도 WoW에, 오버워치 이러면서 2010년대까지도 잘 나가지 않았던가?
그랬는데 지금이야 뭐.. 회사 창립자인 사장이 살해...;;까지는 아니지만 물러났고, 스타를 만들었던 핵심 개발진들이 죄다 퇴사하고 회사를 따로 차리는 지경이 됐다. 기존 스타크래프트는 1(리마스터)이고 2고 간에 유지 보수가 도저히 안 되는 막장 상황이 된 건 확실해 보인다.

우와, 그 명작인 스타크가 개발사로부터 버림받는 지경이 됐다니.. 하긴, 유명한 것 대비 회사 입장에서의 수익성이 너무 없어지긴 한 것 같다.
이렇게 되지 않으려고 국내의 온라인 게임 개발사들은 처음에 돈독 올랐다고 욕 먹는 한이 있어도 정액제니 부분 유료화니 하면서 사용자에게서 지속적으로 돈을 걷는 체계를 만든 것 같다. 한 번만 돈 내고 끝인 패키지가 아니라 말이다.

그랬는데 블리자드가 2022년 초에 마소에 인수됐다. 마소는 게임 제작사들의 재량을 존중해 주는 관대한 기업이니 블리자드의 옛 명성을 되찾아 줄 것을 기대해 본다.
하긴, 왕년에 Doom과 Quake를 개발했던 id조차도 마소에 인수돼서 그쪽 계열사가 된 지 오래다. id를 인수하고 싶어했던 빌 게이츠의 오랜 소원은 빌이 은퇴한 뒤에야 결과적으로 성취됐다.

그 마소에서도 알다시피.. 2010년대에 경영진이 싹 바뀌고 컴퓨팅 시장의 판도가 많이 바뀌었던 시절에 Windows 8과 관련해서 삽질이 유난히 잦았다. Windows 10은 초창기에 예전의 마소답지 않은 온갖 버그들이 난무했었다.
MFC처럼 수십 년 묵은 고인물 썩은물은 마소 내부에서도 안 쓸 뿐만 아니라, 코드 구조를 다 꿰뚫고 유지 보수 가능한 사람이 거의 안 남았다나 어쨌다나.. MFC가 그러한데 하물며 딱히 작업할 것도 없고 10년 넘게 변화가 없는 한글 IME 코드의 관리 인력이야 두 말하면 잔소리이지 싶다.

소프트웨어 개발사는 핵심 프로그래머가 교체되더라도 제품 코드에 대한 노하우가 단절 없이 전수되고 코드의 유지 보수가 가능하도록 정말 노력해야 할 것 같다. 일례로 각종 주석과 문서 작성을 게을리하지 말아야 할 것이다.
남이 도무지 읽을 수 없는 스파게티 코드, 난독화 코드를 잔뜩 짜 놓고는 "이 코드는 나 말고는 아무도 의미를 알 수 없어~" 이렇게 버티는 건.. 반칙이며 알박기나 마찬가지일 테니 말이다.. =_=;;

Posted by 사무엘

1. 존재를 부정 당하고 있는 IE 브라우저

지난 2010년대 초는 IE6을 작정하고 퇴출시키려던 시기였다. 그 뒤, 2020년대 초는 IE를 통째로 퇴출시키려는 시기가 됐다. 그 전에 플래시와 ActiveX부터 먼저 퇴출됐고 말이다.
그럼 지금은 키보드 보안이나 특수한 암호화 같은 게 필요하면 DLL 형태인 ActiveX 대신, EXE 실행 파일로 다 바뀐 건지? 그럼 요즘은 크롬에서도 인터넷 뱅킹이 가능한 건지?? 잘 모르겠다. 내 개인적으로는 여전히 뭔가 잘 안 돼서 PC에서 금융 거래를 할 때는 아직 "Edge + IE 모드"에 의존한다.

Media Player는 더 업데이트를 하지 않는 레거시로 남았을지언정 일부러 없애지는 않는 물건이다. 그러나 IE는 하루가 다르게 바뀌는 웹 프로그래밍 플랫폼이며 보안에 민감한 놈이다. 그래서 마소에서도 매우 적극적으로 존재 자체를 부정하고 없애려는 중이다.

그래서 작년 하반기쯤이었나? Windows 10의 어느 버전인가 업데이트를 설치한 뒤부터는 이제 Internet Explorer가 대놓고 실행되지 않게 됐다. 그냥 꺼져 버리고 Edge가 대신 뜬다.
과거 Windows Me가 여전히 도스를 완전히 벗어나지 못한 9x 커널 기반이었음에도 불구하고, 겉으로만 도스로 부팅하거나 도스로 돌아가는 기능을 없애 버린 것과 비슷한 조치 같다.

그러나 IE라는 껍데기 말고, IE가 사용하는 그 트라이던트 웹 렌더링 엔진과 윈도우 컨트롤은 사실상 Windows 운영체제의 일부나 마찬가지이다. 얘에 의존해서 돌아가는 기존 프로그램도 있기 때문에 그걸 통째로 없앨 수는 없다.
마치 Visual Basic 6처럼 말이다. 얘는 마소에서 21세기 이래로 줄기차게 없애고 .NET으로 대체하려 애썼지만 끝내 그러지 못했다. 게다가 Office 제품군의 매크로 언어인 VBA가 여전히 재래식 VB 기반이니.. 이것 때문에라도 완전히 없애는 건 불가능하다.

IE 엔진이 여전히 쓰이는 대표적인 분야는 도움말이지 싶다. 특히 HTML 도움말(*.chm) 말이다. 얘는 이미 10년 이상 전부터 추가적인 개발과 지원이 끊겼으며, 마소로부터 사실상 완전히 버려진 자식 신세이다.
그런데 마소에서 지난 2010년대부터는 '로컬 오프라인 환경에서 열람하는 도움말/문서'라는 개념 자체를 완전히 송두리째 폐기한 것 같다. IE나 HTML 도움말만 없앤 게 아니라는 뜻이다.

그러니 이제 메모장을 띄웠을 때 F1을 누르면.. '메모장 도움말'을 Bing에서 검색한 결과가 뜬다.;;; 이렇게 무심할 데가..
정말 믿어지지 않지만, 현재의 Windows 10/11은 로컬 도움말이란 게 사실상 존재하지 않는 것 같다. 오죽했으면 이젠 Windows\help 디렉터리가 거의 텅 비어 있다. 거기 그나마 들어가 있는 건 뭐 nvidia 제어판이나 개발 관련 듣보잡 문서이지, Windows 자체에 대한 일반 사용자용 도움말이 아니다.

개발툴도 예외가 아니어서 Visual Studio 2010/2012를 즈음해서는 10여 년의 역사를 자랑하던 msdn Document Explorer가 없어졌고.. 이제 내장 도움말 컨텐츠 다운로드 같은 것도 없어졌다.
이런 게 완전히 없어지기 전에는 chm이 아니어도 자기들만 쓰는 html + IE 엔진 기반의 개발 문서 조회 시스템이 있었는데.. 요즘은 그런 것 자체가 없다는 것이다. 걍 단순 정보 조회는 구글로, 문제 해결 정보는 Stack overflow를 뒤지라는 뜻인 듯..

안 그랬으면 HTML 도움말을 IE 대신 크로뮴 엔진 기반으로 다시 만드는 지원이라도 할 텐데 그런 것조차 없다.
근데 현실적으로는 다른 대안이 있나? Windows용 앱 내부에서 뭐 최신 반응형 웹 따위 바라지도 않고, 간단히 html 렌더링해서 표시하고 싶은데 IE ActiveX 컨트롤보다 더 간편한 방법이 있을까? 그건 의문이 든다.
아무리 웹이 기존 앱의 영역을 많이 잠식하긴 했어도, 그래도 앱 내부에서 웹페이지를 표시할 일도 있을 텐데 말이다.

그리고 또 하나 생각할 점은 웹페이지의 인쇄이다.
내 경험상.. 당장 이 블로그 웹페이지를 같은 pdf 드라이버로 인쇄해 보면 IE는 그럭저럭 최적화된 형태의 pdf가 만들어진다. 그 반면, 크롬은 훨씬 더 bloat된 이상한 형태로 pdf가 생성되며, 인쇄하는 데 시간도 더 오래 걸린다.
무작정 IE를 없애 버리기에는 제대로 된 대안· 대체제가 여전히 존재하지 않는 것 같다.

2. 이상하게 바뀐 메모장

올해 초쯤에 Windows 11의 업데이트를 설치하고 나자.. 프로그램 창의 ‘최대화’ 버튼의 동작이 살짝 달라졌다. 마우스로 얘를 가리키면 고전적인 전체 최대화 외에, 좌우 1:1:1 등 어느 레이아웃으로 최대화할지 고르는 타일 메뉴가 나타나기 시작했다.
Windows 7에서 창을 마우스로 화면 좌우상하 구석으로 끌었을 때 그렇게 배치하는 기능이 처음 추가되긴 했는데, 그게 13년쯤 뒤에 저렇게 강화됐다. 요건 뭐.. 나쁘지 않아 보이네.

그런데 그것 말고도 마소가 꽤 큰 사고를 쳤더라. 세상에.. 메모장이 메트로 UI 형태로 다시 만들어졌다.
본문이 운영체제 기본 에디트 컨트롤이 아니라.. 워드패드와 동일한 리치 에디트 기반으로 바뀌었다.
개인적으로 이거 완전 비호감이더라. 메모장은 단순한 앱의 상징 마지노 선으로 봉인 좀 시켜 놓지, 왜 저런 짓을 했나 모르겠다. 사람들이 메모장이 기능이 많아서 애용하는 줄 아는가??

그런 주제에 UTF-16랑 KS X 1001 인코딩의 파일이 열리지 않고, 우클릭 컨텍스트 메뉴에 알파벳 단축키가 먹히지 않는다. 예전에 되던 것이 안 되니 새 버전을 사용하기가 매우 꺼려지게 된다.
저런 쓸데없는 걸 건드리지 말고, sihost.exe가 CPU 다 쳐먹으면서 폭주하는 버그나 좀 고칠 것이지.. 그 문제는 여전한 걸 보고는 더 좌절했다.

난 지금까지도 솔직히 Win10이랑 11의 차이를 모르겠다. 업데이트 해야 할 필요를 느끼지 못한다.
10에서는 작업 표시줄을 우클릭해서 바로 작업 관리자에 들어갈 수 있었는데 11에서는 못 하고..
정말 필요한 기능이 아니라 그냥 괜히 바꾸기 위해서 바꾼 게 많다. 이럴 거면 걍 10의 업데이트나 낼 것이지 왜 11이라고 차별화를 한 걸까?

난 멀쩡히 잘 돌아가는 기능들에다가 쓸데없이 자꾸 메트로 UI를 도입하는 것도 근본적으로 마음에 안 든다. 현실에서 멀쩡한 길거리 인도 보도블럭을 쓸데없이 교체하는 것과 비슷한 느낌이 든다.
아 그래, 25년쯤 전에 마소에서 Windows UI 셸을 전부 IE4 Active desktop으로 도배하려는 것과 비슷하게 느껴지기도 한다.

Posted by 사무엘

1. Dependency Walker

Dependency Walker라고.. Windows용 실행 파일에서 export 심벌과 import 심벌들을 재귀적으로 분석해서 모듈 간의 전체 의존 관계를 그래프 형태로 출력해 주는 굉장히 유용한 유틸리티가 있다. macOS나 리눅스 같은 타 OS에도 모듈 간 의존이라는 개념이 응당 있을 텐데, 타 OS용 실행 파일을 분석하는 프로그램도 좀 있었으면 좋겠다.

얘는 15년쯤 전, Windows Vista의 출시와 비슷한 시기에 마지막 버전이 나온 뒤부터는 원저자에 의한 개발과 유지 보수가 사실상 중단됐다. 뭐, 지금도 그럭저럭 쓸 만하긴 하지만 한 가지 문제가 있다.
Windows 7인지 8인지 10쯤부터는 모듈을 열어 보면 내부적으로 무한 루프에 빠져서 분석하는 데 시간이 굉장히 오래 걸리고 불필요한 정보가 너무 많이 걸려 나오는 경우가 있다.

자세한 속사정은 모르겠지만, 요즘 마소에서는 운영체제 API DLL들을 분야별로 최대한 잘게 쪼개고 있다. Windows 7에서는 kernel32.dll 하나가 제일 먼저 시범타로 쪼개졌었다. 가령 api-ms-win-core-heap, processthreads, memory, file 따위로 말이다.
그랬는데 요즘은 다른 dll들도 마찬가지이다. 레지스트리 API는 전통적으로 advapi32에 있었는데 그건 api-ms-win-core-registry로 가고, gdi32조차 ext-ms-win-gdi-draw, font, paint, path 등등으로 리모델링 됐다.

응용 프로그램들이야 과거와의 호환성을 위해 여전히 kernel32, gdi32 따위로 링크 되겠지만, 이 운영체제에 내장된 기본 프로그램들은 저런 잘게 쪼개진 dll을 직통으로 사용하는 형태로 빌드 된다.
쪼개진 dll들은 시스템 디렉터리에 있지도 않고, winsxs 아래로 도무지 정체를 알 수 없는 길고 복잡한 디렉터리 한구석에 처박히는데.. 딱히 매니페스트가 있지도 않아 보이구만 어떤 원리로 직통 연결되는지 나로서는 모르겠다.

내가 보아하니, Dependecy Walker가 어떤 PC에서는 이런 쪼개진 stub DLL을 모종의 이유로 인해 제대로 분석하지 못하는 것 같다. 거기서 loop cut을 못 하고 위의 스샷에서 표시된 바와 같이 무한 순환 오동작을 일으킨다.
차라리 그 파일을 찾지 못해서 넘어가는 것이면 다행인데, 이것도 100% 올바른 동작이 아닌 건 마찬가지이다.
이런 게 고쳐졌으면 하지만, 저 프로그램은 현재 버전업이 중단된 상태이다. 그렇기 때문에 모 오픈소스 진영에서는 Dependency Walker의 클론을 직접 만들고 있기도 하다.

참고로, 과거의 Windows 9x에서는 kernel32.dll이 원초적인 dll이었다. 즉, 심벌을 export만 하지, 자신은 실행 과정에서 다른 dll을 import 하는 것이 없었다.
그러나 오늘날의 Windows는 ntdll.dll이 원초적인 dll이다.

2. 32비트 프로그램에서 실행 중인 64비트 프로그램의 경로 얻기

GetModuleFileNameEx는 현재 컴퓨터에서 실행 중인 다른 프로세스, 혹은 거기 안에 같이 load된 dll의 전체 파일 경로를 얻어 오는 함수이다.
그런데 얘는 전통적으로 32비트 프로그램에서 64비트 프로그램을 대상으로 정보를 요청하는 건 잘 되지 않는 것으로 유명했다.

그냥 단칼에 실행이 실패하는 것도 아니고, 경로를 되돌리기는 하는데 온전한 형태가 아니라 뒷부분이 짤린 일부만을 되돌렸다. 그리고 에러 코드도 ERROR_PARTIAL_COPY라고 당당히 되돌렸다.
32비트 프로그램이 64비트 프로세스의 주소 공간에 접근하는 게 기술적으로 쉬운 일은 아니겠지만 그건 걔네들 사정일 뿐이다. 사용자 내지 프로그래머의 입장에서는 겨우 이런 간단한 정보 하나 온전히 얻으려고 IPC용 64비트 exe를 따로 만들어야 하나.. 멀쩡한 함수가 무용지물이니 우회 경로를 뚫느라 굉장한 불편을 겪을 수밖에 없었다.

그랬는데 오늘 우연히 이 함수를 호출해 보니 Windows 10의 20xx이후의 업데이트 버전에서는 이 문제가 해결된 것 같다. 32비트 프로그램에서 다른 32비트나 64비트 프로그램의 전체 경로를 얻는 것.. 반대로 64비트 프로그램에서 다른 32비트나 64비트 프로그램의 전체 경로를 얻는 것 모두 아무 문제 없다.
Windows 10 구버전이나 Windows 7, 8 같은 거 64비트 에디션이 있으면 같은 프로그램을 구동해서 결과를 확인하고 비교할 수 있겠다만.. 대조군을 구하지 못해서 그것까지 실험은 못 해 봤다.

옛날에는 도대체 무슨 한계 때문에 이 함수가 제대로 동작하지 않았는지, 그리고 지금은 무엇이 해결되었는지 이 함수와 관련된 사연을 좀 알고 싶다.
이 함수는 원래 psapi.dll에 있던 시스템 정보 조회용 부가 액세서리에 가까운 물건이었으나..
앞서 언급한 바와 같이 Windows 7 즈음부터 시작된 API 재배치 정리 작업 과정에서 kernel32의 세부 카테고리로 본진이 이동한 듯하다. 사실, GetModuleFileName이 있던 곳과 같은 곳에 있는 게 논리적으로 훨씬 더 타당하기도 하다.

이런 커널 API 말고 GDI 쪽에서도.. 옛날에 AlphaBlend처럼 Windows 98에서 처음 추가된 그러데이션 그리기 함수들은 msimg32.dll이라는 별도의 DLL에 들어가 있다가 Windows XP인지 Vista인지 그때쯤부터 gdi32로 자리를 옮긴 적이 있었다.
새로 추가된 함수가 이런 식으로 재분류되는 게 완전히 새로운 관행은 아니었던 셈이다.

3. 파일 대화상자의 동작과 current directory

Windows에서 제공하는 파일 열기/저장 공용 대화상자는 사용자가 선택한 파일이 있는 곳으로 프로그램의 current directory도 같이 바꿔 버린다.
그래서 어떤 프로그램에서 USB 메모리 안에 있는 파일을 열기 대화상자로 골라서 열고 나면, 그 파일을 닫은 뒤에도 계속해서 USB 메모리가 사용 중이라면서 안전하게 제거가 되지 않는 불상사가 벌어진다. 파일을 열었던 프로그램을 통째로 종료하거나, 열기 대화상자를 꺼내서 다른 드라이브에 있는 파일을 열면 문제를 해결할 수 있다.

사실, 아주 극단적으로 특이하게 동작하는 물건이 아닌 이상, GUI 프로그램은 자기가 작업하는 파일의 절대 경로를 갖고 있다. 상대 경로를 통해 다른 파일을 참조한다 하더라도 기준이 되는 절대 경로가 따로 있지, 프로그램의 current directory 정보에 의존할 일은 없다. 게다가 current directory는 스레드가 아니라 프로세스마다 하나씩만 보관되는 정보이기 때문에 thread-safe 하지도 않다.

그러니 파일 대화상자가 굳이 저렇게 동작할 필요가 전혀 없어 보이는데도 current directory를 변경하는 이유는.. (1) 레거시 프로그램과의 호환도 있고.. (2) 그리고 다음에 파일 대화상자를 또 열 때 사용자가 마지막으로 선택했던 파일이 있는 곳을 current directory라는 수단을 통해 기억하고 공유하기 위해서이지 싶다.

도스 같은 명령 프롬프트 환경에서는 사용자의 타이핑 수고를 덜기 위해서 current directory라는 개념이 반드시 필요했으며, 그때는 아예 각 드라이브별로 current directory를 다 기억하고 있었을 정도였다. 지금 Windows 환경은 그 정도까지는 아니다.
그리고 어떤 프로그램은 불러들이는 문서 파일이 있는 디렉터리와 current directory가 동일하다는 게 보장돼야만 제대로 동작하는가 보다.

하지만 파일 대화상자도 OFN_NOCHANGEDIR라는 플래그가 있어서 사용자가 어느 파일을 선택하건 current directory를 건드리지 않게 하는 옵션 자체는 있다.
그리고 내부 동작도 바뀌어서 굳이 current directory에 의존하지 않고 자체적으로 사용자가 마지막으로 파일을 선택했던 위치를 기억해서 보여준다.

그러니 오늘날 새로 개발되는 프로그램들은 파일 대화상자를 꺼낼 때 가능한 한 OFN_NOCHANGEDIR를 사용하는 게 좋을 것 같다.
또한, 이런 조치와는 별개로 current directory 때문에 USB 메모리가 안전하게 제거되지 않는 문제를 운영체제 차원에서도 좀 최소화해야 하지 않나 싶다.

이건 모니터를 2~3대 연결해서 컴퓨터를 잘 쓰다가 일부 모니터의 선을 뽑아 버린 것과 비슷한 상황이다. 이 경우, 운영체제에서는 없어진 모니터의 영역에 있던 프로그램 창들을 재주껏 다른 모니터로 잘 옮겨 줘야 한다. 그런 것처럼 USB 메모리가 뽑혔다면, 거기를 current directory로 참조하던 프로그램은 다른 디렉터리를 참조하도록 상태가 적절히 바뀌어야 할 것이다.

4. 그래픽 뷰어

끝으로, 이건 프로그래밍과 큰 관계 없이 특정 앱에만 해당되는 사항인데..
요즘 Windows 10에 기본 내장돼 있는 그래픽 뷰어 말이다. 오랫동안 사용해 본 내 경험에 따르면, 얘는 좀 불안정한 것 같다. 창을 여러 개 띄워 놓다 보면(5개 이상 여러 파일)..

• 종종 뻗으면서 지금까지 띄웠던 창들이 한꺼번에 싹 없어진다.
  
• 혼자 CPU를 잔뜩 소모하면서 노트북 PC를 열받게 하기도  한다.
  
• 사진 파일을 더블 클릭했는데 프로그램이 실행만 되고 창이 뜨지 않고 먹통이 되기도 한다. "파일 시스템 오류 (-805305975)" 이러면서 아예 실행이 안 된다.

2004/2009대 버전으로 개인용 컴과 회사 컴에서 모두 동일한 현상이 발생하니, 이건 내 환경만이 문제가 아닌 것으로 보인다.
한 가지 확실한 건 얘는 화면 표시에 그래픽 카드의 하드웨어 가속 기능을 적극 활용한다는 것이다. 뻗는 것도 여느 프로그램들 같은 메모리 버그 때문에 뻗는 게 아니며, 그래픽 카드 드라이버와의 충돌 내지 그쪽의 오류 때문에 뻗는다.

내 기억이 맞다면 Windows XP~7 사이의 기본 그래픽 뷰어는 256색 GIF에 대해서는 트루컬러 JPG와 달리 부드러운 확대/축소를 지원하지 않는다거나, GIF/APNG 애니메이션을 지원하지 않는다거나 하는 한계가 있었다.

지금 뷰어는 그런 한계가 다 없어지고 한 프로그램에서 사진과 동영상을 모두 취급할 수 있어서 기능 면에서는 제일 좋아졌다. 하지만 반대로 구버전에 비해서 안정성은 명백하게 떨어져 있는 게 아쉽다. 특히 앱이 실행되지 않기 시작하면 운영체제를 재시작/재로그인 하는 것 말고는 다른 해결책이 없다.

5. CPU 점유 문제

요즘 누구든지 컴퓨터나 폰을 다루면서 겪는 굉장히 성가신 문제 중 하나는.. 어떤 불필요한 프로세스/서비스가 나도 모르는 사이에 CPU 자원을 독식해서 기기가 갑자기 혼자 열받고 팬 돌아가고 배터리가 눈에 띄게 빨리 닳기 시작하는 것이다. 그러고 보니 스마트폰은 팬이 없구나~!

개인적으로는 이럴 때 CPU 도둑을 감지해서 “이놈이 지금 폭주 중인데 죽일까요?” 안내를 해 주는 유틸/툴이 있어야 한다고 생각한다.
도스 시절로 치면 memmaker, 윈도 XP 시절에 잠깐 있었던 바탕화면 정리 마법사, 어지간한 악성코드 진단 유틸 같은 명목으로 말이다.

물론 어지간한 컴잘알이라면 이럴 때 작업 관리자를 띄워서 CPU 사용량이 높은 놈을 강제 종료시킬 것이다. 하지만 범인이 평범한 프로그램이 아니라 서비스 같은 부류라면 뭐가 문제인지를 진단하기 어렵다.

본인의 과거 경험을 떠올려 보면 Windows Update와 관련된 서비스가 폭주한 적도 있었고, 크롬 브라우저가 쓸데없이 폭주한 적도 있었고.. 요 근래에는 WMI provider host인지 뭔지 하는 놈도 폭주해서 강제 종료시킨 적이 있었다.
자고로 업데이트는 CPU를 최하 우선순위로 받으면서 민폐를 절대 끼치지 않고 몰래 몰래 돌아가야 할 것이다. 사용자가 명시적으로 시키지 않은 작업이 저 따위로 돌아가는 건 어떤 경우든 디자인 결함이고 버그이지 않을까?

6. 프로그램 창의 떨림 현상

끝으로, 이건 프로그램이 뻗는 급의 치명적인 문제나 불편한 현상은 아니지만..
요즘 컴퓨터를 쓰면서 프로그램 창을 전환하다 보면, 아주 가끔씩 프로그램들이 non-client 영역(제목 표시줄, 메뉴 따위)이 수십 번 다시 그려지는지.. 수 초 동안 부르르 깜빡거리고 떨리는 경우가 있다.

이 역시 2004/2009급 Windows 10이 깔린 개인용과 회사용 컴퓨터에서 모두 목격하는 현상이다. 201x년대에는 딱히 본 적이 없었던 새로운 현상이다.
정확하게 어떤 조건 하에서 왜 발생하는지는 모르겠다.
내가 모르는 사이에 업데이트가 깔리면서 운영체제의 아랫단은 알게 모르게 많이 바뀌는데, 버그나 부작용도 슬그머니 들어갔다가 또 잠수함 패치되기도 하는 것 같다.

Posted by 사무엘

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

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