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

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

사용자가 자기 머신에(PC 내지 폰) 직접 설치해서 구동하는 그 exe / apk야 클라 개발자의 작품이다.
현란한 그래픽을 구현하고, 같은 하드웨어에서 화면 프레임 수를 늘리려고 고생하는 애들 역시 클라 개발자이다.
그러나 수많은 사용자들을 동시에 수용하고 계정 정보를 관리하고, 이것들이 해킹당하지 않게 보호하고, 클라가 뿌릴 게임 내부 상태를 전해 주는 건.. 서버 및 서버 개발자의 몫이다.

클라 프로그램이 뻗는 건 그 사용자만의 문제이지만, 서버가 뻗는다면....;;;; 뭐 그렇다.
조금 어설프게 비유하자면 클라는 또박또박 보도를 하는 뉴스 앵커이지만, 서버는 뉴스 대본을 생성하고 보도 순서와 분량을 정하는 보도국뻘 된다.

그런데 데스크톱이나 모바일 '앱' 말고 웹 개발로 가면.. 프런트 엔드와 백 엔드라는 계층 구분이 있다.
웹 프로그램은 머신에 설치되는 게 아니라 웹브라우저 화면에서 바로 구동된다. 그렇기 때문에 개념적으로는 클라라는 게 없고 서버 프로그램만 있는 것 같다.

하지만 거기서도 계층 구분이 있다. 사용자한테 보이는 부분, 더 기술적으로는 js html css처럼 서버로부터 받기는 했지만 사용자의 웹브라우저에서 구동되고 사용자가 소스를 직접 볼 수 있는 부분은 프런트 엔드이다.
그 반면, 저런 html을 생성하는 프로그램이라든가 DB처럼.. 진짜로 서버에서만 돌아가고 사용자가 코드를 볼 수 없는 부분은 백 엔드라고 불린다.

프런트 엔드 웹 개발자는 웹 '디자이너'와 영역이 겹치며 같이 작업하게 될 수 있다.
그러나 백 엔드는 디자이너와의 접점이 없으며, 그 대신 Java, C#, 심지어 C++처럼 머신 종속적인 데스크톱용 프로그래밍 언어와 접점이 있을 수 있다. (사용하는 프레임워크가 무엇이냐에 따라)

글쎄, php는 딱히 기계 종속적이지 않으면서 백 엔드 개발에 최적화된 언어인 듯하다.
JavaScript야 웹 개발계의 유니코드요 세계공용어로 등극했으며, 프런트와 백에서 모두 쓰이고 있다.

원래 컴퓨터 업계에서 '프런트/백 엔드' 이런 말은 컴파일러에서 주로 쓰이던 용어였다. 구문 해석해서 parse tree 내지 IR(중간 표현)을 생성하는 게 프런트이고, 이걸로부터 실제 머신 코드를 생성하고 최적화도 하는 게 백이었는데.. 2000년대 이후부터는 웹 개발에서의 계층을 구분할 때도 저런 용어가 쓰이게 된 것이다.

1990년대.. 웹의 초창기에는 웹만을 위한 프로그래밍이라는 개념이 아주 희박했다. 프런트/백의 엄밀한 구분도 없었고 온갖 비표준 파편화 기술들이 난립했었다.
프런트 엔드에 속하는 건 사용자가 폼에 입력한 값이 올바른지 로컬에서 체크해서 에러 메시지 띄우는 수준의 아주 간단한 코드?? 이런 코드는 html 코드의 주석 안에 자그맣게 짱박혀 있곤 했다.;; html이라는 문서가 main이지, 이런 코드는 약간의 동적 요소만 가미해 줄 뿐, 조연에 지나지 않았다.

하긴, html 자체를 동적으로 생성하는 기술을 공부해서 DB 만지고 게시판 같은 거 자작하는 게 지금으로 치면 백 엔드 개발이었겠다. CGI 역시 백 엔드의 범주에 드는 초창기 기술일 테고. =_=;; 옛날 제로보드 스킨은 일종의 프런트 엔드 개발이었겠다. ㄲㄲㄲ
플래시니 Java 애플릿 같은 건 물론 프런트이고, 지금의 관점에서는 특정 기업 솔루션에 종속적인 비표준 기술이 됐다.

프런트 엔드에서 돌아가는 웹 프로그램 코드는 특정 기계어로 컴파일되지는 않는다. 무슨 C/C++ 프로그램처럼 저수준 메모리 문제나 보안 문제 같은 것도 존재하지 않는다.
만약 특정 JavaScript 코드를 실행함으로써 메모리· 보안 문제가 발생한다면 그건 그 브라우저에 내장된 js 엔진의 버그이지, js 코드의 버그라고 여겨지지는 않는다. 문제 있는 js 코드는 다른 부작용 없이 깔끔하게 실행이 거부되고 에러 메시지와 함께 튕기기만 돼야 할 테니 말이다.

그 대신 그 코드는 보통 난독화 처리가 돼 있을 것이다. 그렇기 때문에 코드가 노출돼 있다고 해서 사용자가 그 코드를 읽어서 뭔가 로직을 파악하기는 매우 난감할 것이다.;;

그렇기 때문에 웹 프로그래밍에서 보안의 최대 관심사는 buffer overrun 같은 부류가 아니라.. 신뢰할 수 없는 임의의 외부 문자열이 코드나 태그, SQL 따위로 인식되어 실행되지 않게 하기 위주인 것 같다. C로 치면 % format 문자열에다가 동적 생성된 외부 문자열을 공급하지 말라는 것과 비슷하다.

문득 드는 생각은.. 웹 개발을 위한 전용 IDE가 있을까?
옛날에 나모나 드림위버, FrontPage 같은 위지윅 html 에디터가 있었고.. Visual Studio 6 시절엔 Visual InterDev라고 비베 냄새가 나는 웹 개발 IDE가 있긴 했다. 하지만 그런 건 2000년대 중반 이후로 유행이 지나고 한물 갔다. 심지어 마소에서 Expression Studio라고 새로 만들던 웹 개발 저작도구도 2010년대 초반에 개발이 중단됐다.

웹은 과연 IDE의 무덤인지.. 개발에 이클립스 내지 Visual Studio Code 같은 범용적인 에디터/IDE만 쓰이는 것 같다.

※ 비유 개드립

• "웹 디자인 - 웹 프런트 엔드 개발 - 웹 백 엔드 개발"은 뭔가 "장갑차 - 전차 - 자주포" 순으로 성향이 바뀐다고 생각하면 될 것 같다. ㄲㄲㄲㄲㄲㄲ
• 프런트 엔드에서 css / js / html라는 역할 구분 세분화는 입법 사법 행정 삼권분립과 비슷한 느낌이 든다.
• PC용 앱은 일반 봉지 라면, 모바일 앱은 컵라면 사발면.. 그리고 웹사이트를 구동하는 프로그램은 식당 납품용으로 대량 판매하는 라면 사리 내지 스프와 비슷하게 느껴진다.
• 웹 개발이나 컴파일러뿐이겠는가. 인공위성은 프런트 엔드, 발사체는 백 엔드 기술인 것 같고.. 자동차에서도 주행과 관련은 없지만 탑승자가 대면하고 사용하는 부품들은 프런트요, 엔진룸 안에서 차량을 굴리는 데 기여하는 부품은 백에 대응하는 듯.. 이런 식의 구분은 다른 여러 분야에도 존재한다.

※ 모바일 관련

mobile이라는 말이 원래는 물리적인 이동, 교통과 관련된 단어였다. 미술 조형물 모빌이라든가, automobile 자동차처럼 말이다. 하지만 지금은 스마트폰 관련 '통신' 뉘앙스가 더 짙어졌다.
그리고 우리말은 참 희한하게도 '모빌'은 통상적인 의미, '모바일'은 통신 의미로 분화됐다. 마치 '도트/닷', '네트/넷'의 뉘앙스 변화와 비슷한 재미있는 현상이다.
'통신사'가 지금이야 SK 텔레콤 같은 게 먼저 떠오르지만 원래 연합뉴스 같은 언론사 용어였다는 것도 생각해 보자.

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. 단품 판매되는 DOS

(1) 197, 80년대에는 컴 단말기가 아니라 개인용 컴퓨터라는 건 이제 막 정립되고 있었고, 소프트웨어도 하드웨어와 함께 딸려 나오는 게 아니라 독립된 제품이라는 인식이 이제 막 정립되던 중이었다.
그래서.. 마소에서 만들었던 MS-DOS도 말이다. 1.0부터 4.x에 이르기까지는 다들 PC와 함께 OEM 형태로만 공급됐다. 도스 자체가 단품 패키지로 개별 소비자에게 retail 판매되기 시작한 건 1991년, 무려 5.0부터였다고 한다. himem.sys와 DOS=HIGH가 첫 도입됐던 그 역사적인 물건 말이다.

아 글쎄.. Windows 1.x 시절이던 1986년에 3.2 버전도 단품 패키지가 있긴 했다. 하지만 이때는 이 방식이 오래 지속되지는 못한 듯하다.

현실적으로 대다수 사용자들이 패키지 판매를 기억하는 건 아무래도 끝물인 6.x버전이지 싶다. 이 무렵에 마소는 IBM과 사이가 단단히 틀어져서 PC-DOS와 MS-DOS의 격차도 벌어지고, Windows와 OS/2도 격차가 벌어졌었다.
1990년대 들어서 MS-DOS는 이렇게 독립을 했는데, 매크로 어셈블러(Macro Assembler)는 그 무렵쯤에 반대의 길을 갔다. 단독 독립 제품으로서는 단종이고, MS C/C++이나 Visual Studio 같은 더 큰 제품에서 제공되는 유틸리티로 흡수되었다.

(2) MS-DOS가 대기업의 PC와 함께 공급되던 시절, 대략 쌍팔년도 정도까지는 한글 MS-DOS에 내장돼 있던 한글 바이오스도 PC 제조사들별로 제각각이었다.

• PC 제조사: 대우, 금성, 현대, 삼보 등
• 제3자 써드파티: 도깨비, 한메, 태백 등
• 마소 자체 개발: hbios, mshbios. Windows 3.1 + MS-DOS 6부터.

한글 바이오스 만드는 게 첨단 시스템 프로그래밍이던 시절이 있었다니.. 추억 돋는다. =_=;;
기능이 제일 많고 성능도 뛰어나던 건 역시 써드파티 제품들이었다. 조합형도 지원하고, 다양한 폰트와 글자판(세벌식까지)도 지원했지만.. 역시 1990년대 중후반쯤부터는 개발의 맥이 끊겼다.
현재 한글 바이오스가 돌아가는 중인지를 무슨 API를 호출해서 어떻게 판별했는지 궁금하다.

(3) MS-DOS는 버전 1부터 4까지는 OEM이었고 5~6 사이에 잠깐 독립 제품.. 그리고 마지막 7~8 버전은 Windows 9x에 포함된 채로 제공.. 이렇게 역사가 정리된다.
그 중에 OEM 끝자락이던 MS-DOS 4는 DOS shell이 처음 도입되었고 FAT16 파일 시스템의 개편으로 하드디스크 용량을 2GB까지 인식할 수 있게 하는 큰 변화가 있었다(종전에는 꼴랑 32MB까지만.. =_=) 하지만 4.0은 버그가 너무 많아서 곧 4.01로 패치가 돼야 했다.

이건 마치 버그가 너무 많아서 온갖 서비스 팩들이 덕지덕지 나와야 했던 Windows NT 4의 행로와도 비슷해 보인다.
그리고 개발툴 중엔 Visual Studio .NET 첫 버전(2002, 7.0)이 금세 묻혀 버렸던 것과도 처지가 비슷하다.

(4) 끝으로.. MS-DOS의 대체품으로 DR-DOS라는 게 있기도 했고, 그걸 한때 네트워크 솔루션으로 유명했던 어느 기업에서 인수하여 노벨 도스로 계승되었다.
한편, MS-DOS의 셸만 대체해서 강화한 제품으로 4DOS라는 게 있었다. 그걸 노턴 유틸리티에서 인수해서 더 발전시킨 게 NDOS...이다. 노벨 도스와 이니셜이 같지만 이들은 서로 다른 제품이다.

2. Rational

옛날에 Rational이라는 이름을 가진 컴퓨터 소프트웨어 회사가 둘 있었다.

(1) Rational Software는 소프트웨어공학 툴이라고 해야 하나.. 딱 정확하게 개발툴, IDE나 컴파일러는 아니지만 어쨌든 소프트웨어 설계· 개발과 관련이 있는 전문 도구를 개발해 왔다. 콕 집어 코딩, 프로그래밍이라기보다는.. 더 거시적인 소프트웨어 개발 말이다.
Rose라는 툴이 유명했다. 꽃하고는 별 관련 없고, 다른 단어들의 이니셜이 저렇게 된 거지 싶다. 내 기억으로 Visual C++ 6 시절에 엔터프라이즈 에디션에는 Rose의 데모 축소판이 번들로 제공됐던 적이 있었다.

얘의 제조사는 2003년에 IBM에 인수됐다. IBM이 PC용으로 소프트웨어를 만든 게 지금은 망한 운영체제 OS/2, 그리고 유구한 역사를 자랑하는 통계 패키지 SPSS 정도밖에 없는 줄 알았는데.. 지금은 Rose도 IBM 휘하로 넘어갔는가 보다.
하긴, 엑셀에 대항하여 넥셀이 있고, AutoCAD에 대항하여 캐디안이 있는 것처럼.. Rose의 저렴한 국산 대체제로 StarUML이라는 제품도 있다.

개인적으로는 직장에서 보고서 쓸 때 각종 UML 다이어그램 그리는 용도로 사용해 봤다.;; 클래스 관계 모식도라든가 각종 시퀀스 다이어그램 따위..
하긴, 그 비싼 프로그램에 겨우 다이어그램을 그리는 기능밖에 없으면 그냥 Visio 같은 벡터 드로잉 툴과 아무 차이가 없을 것이다. 그럴 리는 없고, 여기서 만든 설명대로 Java 클래스 파일을 생성하고 문서를 생성하는 기능도 있었던 걸로 기억한다.

(2) 그 다음으로 Rational Systems라는 곳이 있었다. 얘는 1980년대부터 DOS extender만 전문으로 개발해 왔다. 16비트에 640KB 메모리에 쩔어 있던 도스 환경에서 보호 모드를 구현하고, 메모리를 골치 아픈 제약 없이 32비트 그대로 접근하게 해 주는 획기적인 런타임 말이다.

사실, DOS extender라는 걸 처음으로 개척한 회사는 Phar Lap이었다. 워크스테이션에서나 돌릴 만한 거대한 업무용 프로그램을 PC용으로 포팅할 때 원래 Phar Lap의 extender가 주로 쓰였다. 옛날에 도스용 아래아한글도 전문용 내지 32비트 에디션은 얘를 사용했다.

그러나 Rational Systems에서는 DOS/4G라는 제품을 개발하고, 이걸 Watcom C/C++ 컴파일러에 DOS/4GW라는 번들 버전으로 아주 저렴하게 공급해 줬다. 1993년 말에 Doom이라는 게임이 딱 이 솔루션을 사용해서 출시되면서 DOS/4GW라는 32비트 extender는 세계적인 히트를 치게 됐다.

환상적인 그래픽을 선보였던 Doom이 어셈블리어를 거의 쓰지 않고 이식성 높은 C 코딩으로만 구현될 수 있었던 비결엔 이런 신기술이 있었던 것이다. 물론 그래픽을 제대로 보려면 그 당시로서는(1993~1995) 아직 가격이 부담되는 고성능 컴터이던 486급이 필요했지만 말이다.

그리고 Doom은 이 장르에서 하드웨어 가속이 없이 CPU 연산/소프트웨어만으로 동작한 마지막 게임이기도 했다. ^^ 이렇게만 동작해서는 320*200보다 더 높은 해상도에서 3D 폴리곤 그래픽이 실시간 애니메이션으로 나오기란 굉장히 무리였을 것이다. 뭐, 그래픽의 하드웨어 가속에도 더 높은 데이터 대역폭이 필요할 것이고, 32비트 버프가 기여했다고 볼 수 있다.

1990년대 중후반까지 덩치 큰 도스용 게임들은 처음 실행될 때 DOS/4GW 로고가 뜨는 게 무척 많았다. 이게 무슨 흥행 보증수표처럼 느껴질 정도로..;;
PC 역사에 한 획을 그었던 이 개발사는 훗날 Tenberry Software이라고 이름이 바뀌고 2000년대 초반까지는 살아 있었다. 하지만 도스 시절이 끝난 뒤엔 없어졌는지 근황을 모르겠다.

요컨대, 두 Rational들은 분야는 다르지만 과거에 뭔가 비범한 소프트웨어들을 개발하곤 했다. ^^.

3. 옛날에 C++ 코딩 환경

난 왕년에 이런 시퍼런 화면에서 코딩을 해 봤다. -_-;;

쌍팔년도를 넘어서 1990년대가 되자.. 이제 막 C가 아니라 C++ 직통 컴파일러라는 게 처음으로 등장했다. 그리고.. IDE의 텍스트 에디터에 syntax coloring이라는 게 제공되기 시작했다.
코드에서 예약어는 진하게 표시하고, 전처리기는 별도의 색깔로, 상수 리터럴이나 주석도 별도의 색깔로.. 이거 말이다. 하긴, 1990년대는 이제 막 VGA와 컬러 모니터가 보급되었던 시절이고, 286이니 386이니 하던 컴터 성능도 실시간 컬러링을 구현해도 될 정도로 향상됐다.

그 당시 도스용 컴파일러의 본좌는 볼랜드...였는데, Turbo C++ 3.0 버전부터 IDE에서 컬러링이 지원되기 시작했다. 1과 2 시절엔 저런 게 아직 없었다.
오 그런데... 말로만 듣던 Turbo C++와 Borland C++가 차이가 있었나 보다. 난 Turbo C++ 것만 어린 시절에 직접 봤었다.
일반 명칭은 초록색, 문자열 상수는 빨강, 전처리기는 저렇게 청록색 바탕, 기호가 노란색 말이다.

그러나 Borland C++은 보니까 일반 명칭이 노랑, 문자열 상수는 청록, 전처리기가 초록, 기호는 하양이다.
난 도스용 볼랜드 개발툴 IDE에서 C++의 컬러링이 저렇게 되는 건 직접 본 적이 없고, 구글 검색을 통해서 난생 처음 본다. 비슷한 시기에 동일 회사에서 내놓았던 Borland Pascal과 더 비슷해졌다. 우와..

사실, Turbo와 Borland의 차이는 Visual Studio로 치면 standard 에디션(개인용)과 enterprise 에디션(기업용) 같은.. 에디션 급의 차이와 비슷하다.
아.. 옛날에.. 볼랜드 IDE를 따라 djgpp 진영에서 개발했던 rhide는.. C/C++ 코드에 대한 컬러링이 Turbo가 아니라 Borland C++ 스타일이었다. 자, 난 저런 것도 기억하는 세대다. -_-;;;;

프로그래밍, 코딩이라는 건 30년 전이나 지금이나 재미있다.
참고로, 코딩 하다가 .이나 ->를 찍었을 때 멤버가 쫘르륵 나오고 명칭이 자동 완성되는 기능은..
1990년대 "말"이 돼서야 제공되기 시작했다. 그건 그만큼 구현하기 더 어려운 기능이었고, PC가 못해도 펜티엄 2 이상급으로 성능이 좋아진 뒤에나 쓸 만했다.

요즘은 이 기능이 없으면 너무 불편해서 코딩을 못 할 것이다. 옛날에 텍스트 에디터가 불편하고 컴퓨터 메모리가 부족하던 시절에는 각종 함수 명칭을 아주 짧고 암호 같이 붙이는 게 관행이었지만..
지금은 코드 양이 너무 방대해지고 저런 자동 완성 기능도 발달하니 길게 길게 풀어서 써 주는 편이다. setmemmgr() 대신에 SetMemoryManager() 같은 식.

4. PowerBasic

198~90년대에.. BASIC이라는 프로그래밍 언어는 입문하기 간편한 대신, 인터프리터 방식 위주이고 실행 속도가 느리다는 게 상식 겸 통념이었다. 즉, 언제까지나 교육용이지, 실무용은 "영 아니올시다"였다. 그러나 BASIC에 대해 그 통념을 정면으로 도전하고 반박하는 이단아 제품이 있었으니, 바로 PowerBasic(파베)이었다.

얘는 BASIC이라는 언어에다가 C/C++ 같은 이념을 접목했다. 마소처럼 느린 P-code 갖고 깨작거리거나 비주얼 RAD 툴 컨셉을 씌우는 게 아니라, 최적화되고 단독 실행 가능한 네이티브 코드 컴파일을 추구했다. 그렇다, 이 컴파일러 엔진을 만든 주 개발자는 그야말로 x86 어셈블리어에 정통한 smaller, faster 최적화 덕후 장인이었다.

PowerBasic은 마이너 비주류 제품군이지만 나름 존재의 의미는 있었다. 베이식 언어로 C/C++ 급의 작고 빠른 프로그램을 생성해 줬기 때문이다. 자기 자신의 덩치도 Visual Studio에 비하면 그냥 깃털 같은 수준이니 아주 실용적이었다.

얘는 16비트 도스에서 32비트 Windows까지는 잘 갈아탔다. 하지만 그 이후의 시대 변화에는 따라가지 못한 채, 2020년대에 와서는 명줄이 사실상 끝난 상태이다.
일단, 주 개발자인 Bob Zale 할아버지가 별세한 지가 이미 10년이 넘었다. 적절한 후임 개발자를 양성하지 못했는지, 파베는 x64건 arm64건 일단 64비트 버전이 못 나오고 있다.

살상가상으로.. PowerBasic 컴파일러 자체부터가 통짜 어셈블리어=_=;;;로 개발됐고, 코드가 호락호락 maintainance 가능한 구조가 아니라고 한다. 이러면 뭐 과거의 OS/2나 dBASE 같은 꼴 나면서 죽는 건 시간 문제지..
그렇게도 성능에 목숨 걸었다지만, 최신 멀티코어 프로세서나 GPU에 맞춰진 컴퓨팅을 잘 지원한다는 얘기도 난 못 들었다. 이러면 머신러닝 스크립트인 파이썬의 용도를 대체하기도 대략 곤란해진다.

지금 생각하면 PowerBasic이 뭔가 슈퍼컴 Cray 같은 물건이라는 생각도 든다. 고전적인 성능 덕후 장인이 애지중지 만들었지만 시 대에 뒤쳐지고 도태됐다는 점에서 말이다.
글쎄, 쟤는 그 성능빨에다가.. 마소에서 버린 자식인 클래식 Visual Basic 6 코드를 지원하는 후속 써드파티 개발툴을 표방하고 나섰으면.. 마르지 않는 고객 수요를 확보하고 절대로 망할 일이 없었을 것 같은데 말이다. 그렇지 않은가? 이렇게 사라지기에는 아깝고 아쉽다.

쌍팔년도 시절에 볼랜드와 마소가 PC용 베이식, C, 파스칼 컴파일러 시장을 꽉 잡고 있긴 했다. 하지만 그 컴파일러들은 처음부터 그 회사에서 만든 게 아니었다. 다들 다른 사람이나 영세업체의 제품을 인수한 것에서부터 개발을 시작했다.

• BASIC/Z by Bob Zale --> Turbo Basic (요게 PowerBasic의 전신)
• Wizard C by Bob Jervis --> Turbo C 1.0 in 1987
• PolyPascal by Anders Hejlsberg --> Turbo Pascal
• Lattice C --> Microsoft C

Posted by 사무엘

예전에 했던 말도 있지만.. 암튼 지난 30여 년에 달하는 컴퓨터의 역사를 곱씹어 보는 건 재미있다~!

1. 인텔 CPU

(1) 인텔 8086은 유구한 x86 시대의 서막을 연 기념비적인 16비트 CPU이다(1978). 나중에 출시된 8088은(1979) 거기에서 외부 데이터 버스만 8비트로 낮춰서 성능을 약간 디버프 했지만 가격도 낮췄다.
80186의 존재감은 비행기에서 보잉 717의 존재감과 아주 비슷하게 듣보잡이다. -_-;; 애초에 PC보다는 임베디드용으로 만들어진 8086의 변종이었다.

(2) 80286의 제일 큰 존재 의의는 보호 모드의 첫 지원이지만.. 이게 많이 부족하고 불완전해서 역시 듣보잡으로 묻혔다. CPU로서 80286은 그냥 클럭 속도 더 빨라진 8086이나 다름없고, 현실적으론 컴퓨터 완성품으로서 AT (286 기반)가 XT (8088 기반)보다 나아진 점이 훨씬 더 많이 와 닿곤 했다. 2HD 고밀도 디스켓, 배터리 기반 시계, 키보드 속도 조절 등..
그에 비해 101키 키보드, VGA 컬러 그래픽이나 하드디스크는 XT에도 일단 장착 가능은 했던 구성요소이다.

(3) 80386은 드디어 32비트 CPU이다. 32비트 정도는 돼야 어지간히 큰 정수라든가 부동소수점을 원활히 표현할 수 있고, 메모리 주소 공간도 넉넉히 확보해서 보호 모드 가상 메모리 같은 것도 구현할 수 있다.
오리지널 DX는 외부 데이터 버스와 메모리 주소 버스도 모두 32비트인 반면, 염가 다운그레이드 에디션으로 나중에 출시된 SX는 이게 각각 16비트, 24비트였다. 과거 8086과 8088의 관계와 거의 동일하다.

(4) 80486도 DX와 SX 구분이 있었는데, 이때는 단순히 부동소수점 코프로세서가 기본 내장된 게 DX이고, 안 그런 게 SX였다. 거기에다 486은 DX조차도 클럭 속도를 더 끌어올린 DX2, DX4 이런 구분이 있었다.
이때 'VESA 로컬 버스' 규격 갖고 많이 떠들곤 했다. 천상 486 전용 규격으로 쓰이다 말았지만..
그리고 캐시 메모리라는 게 들어가기도 하고.. 486이 386에 비해 많이 발전하긴 했었다.
1990년대 중반, 486? 펜티엄쯤부터 컴퓨터 본체의 모양이 모니터 아래에 가로로 놓는 게 아니라 모니터 옆에 세로로 놓는 형태로 슬슬 바뀌어 정착했다.

(5) 펜티엄은.. 외부 데이터 버스가 CPU의 레지스터보다도 더 큰 64비트로 확장됐다. 물론 그렇다고 펜티엄이 아키텍처 차원에서 64비트 CPU인 건 아니었다.
인텔 셀러론의 초창기 버전은 펜티엄 2에서 L2 캐시 메모리가 없는 보급 염가판이었다. 그런데 이게 아예 전혀 없으니까 성능이 너무 떨어져서 나중에는 캐시가 약간이나마 장착되기도 했다.

이렇듯, 컴퓨터의 성능에는 클럭만 영향을 끼치는 게 아님을 알 수 있다.
그리고 한때는 옵션으로 주어졌던 요소들이 나중엔 다 기본으로 포함돼 들어가고 다른 새로운 기능이 옵션으로 도입된다.

2. Windows 운영체제

• Windows 3.0은 MDI 창, VGA와 본격적인 컬러 지원을 위한 장치 독립 비트맵(DIB), WinHelp(!!!) 같은 획기적인 기능을 도입했고, 3.1에서는 OLE, 트루타입 글꼴, 공용 대화상자를 도입함으로써 현대의 Windows 근간을 닦았다.
• 거기에다 Windows 3.0은 386 확장 모드라는 걸 도입해서 80386 이상 CPU에서 지원되는 보호 모드 멀티태스킹 기능을 일부 사용하기도 했다. 하지만 앱이 전반적으로 돌아가는 건 다 16비트 기반이다.
• Windows NT는 저렇게 도스 진흙탕인 기존 Windows와는 달리, 미래를 바라보며 개발됐다. DEC Alpha라는 64비트 CPU용 에디션이 있기도 했으나.. 이때는 컴퓨터의 메모리도 4GB보다 훨씬 모자랐고 Windows 역시 그냥 32비트 모드로 동작했다고 한다. 포인터 8바이트니 INTPTR이니 그런 거 없었다는 뜻..

그렇기 때문에 Windows의 역사상 최초의 진정한 64비트 프로그래밍을 개막한 아키텍처는 IA64였다.
그 전 20세기의 NT4 시절에는 DEC Alpha뿐만 아니라 PowerPC네 MIPS네 여러 자잘한 아키텍처를 지원하다가 말았고, 2000년대부터는 x64와 ARM64가 살아남았으니 2000년대 초가 중대한 전환점이었다.

허나, 그 전환점의 중심에 서 있던 IA64는 좋은 타이밍을 날리고 장렬히 자폭했다... =_=;; 사실은 IA64가 채택했던 VLIW라는 설계 방식부터가 성능 대비 단점과 위험 부담도 너무 큰 방식었다. 마치 자동차 엔진에서 통상적인 왕복 엔진이 아니라 로터리 엔진처럼 말이다.
이런 사연으로 인해 Windows 2000은 NT 계열의 개발 역사상 전무후무하게 오로지 x86 전용으로만 출시되는 이변이 벌어졌었다. 무슨 9x처럼 말이다.

• Windows 98은 마우스 휠과 멀티모니터를 최초로 공식 지원하기 시작했다.
• Windows 2000/ME에서는 일부 마우스의 옆구리에 달려 있는 추가 버튼을 L, R 말고 X-button이라는 이름으로 최초로 지원하기 시작했다. 아마 전통적인 상하 스크롤 말고 좌우 스크롤 휠도?
• Windows 7은 SSD와 멀티터치 디스플레이를 최초로 공식 지원하기 시작했다.

아울러,

• USB 메모리를 별도의 드라이버 설치 없이 자체적으로 인식하기 시작한 건 2000/ME부터다.
• XP/Vista 어느 때쯤부터 이제 와이파이도 별도의 프로그램/드라이버 설치 없이 자체적으로 잡기 시작했다.
  무슨 프로그램 띄워서 모뎀 전화를 걸어서 인터넷 접속하고, 그 뒤부터 연결 시간이 올라가던 게 1990년대 말쯤 일이었는데.. 참 격세지감이다.

3. 하드웨어의 발전 양상

성능 증가

• 1990년대 동안은 클럭 속도가 뻥튀기 하듯 폭증했다.
• 1990년대 후반부터는 메모리 양이 폭증했다. Windows 95~98 사이 말이다.
• 2000년대 이후부터는 무선 인터넷 네트웍 속도가 폭증해 왔다.

64비트화

• 워크스테이션/슈퍼컴 쪽은 모르겠고, 개인과 가정 레벨에서는 1990년대 말에 게임기부터 가장 먼저 64비트 CPU를 도입했다. 내 기억으로 닌텐도64..;;
• PC는 2000년대 초에 IA64가 대차게 망하는 바람에 한 타이밍을 완전히 놓쳤고, 2000년대 중반쯤 램 용량이 실제로 4GB를 넘긴 뒤에야 64비트가 대중화됐다. Windows 2000/XP가 아니라 Vista/7 타이밍이다.
• 스마트폰 업계는 2010년대 중반쯤에 슬슬 64비트로 전환이 시작돼서 2010년대 말엔 32비트 앱에 대한 지원을 끊네 마네 하는 상태가 된 것 같다.

오늘날 경전철이라고 해서 협궤를 쓰는 게 아니듯, 주머니에 넣어 다니는 작은 모바일 컴퓨터라고 해서 16/32비트 따위를 쓰지는 않는다. 커다란 화면에다 현란한 천연색 3D 그래픽과 고화질 동영상을 찍으려면 64비트 고성능 CPU는 필수이다. 물론 고성능 CPU는 전기도 많이 먹으니 고성능 배터리도 필수..

4. 그래픽

(1) 그래픽 가속이라고 하니까 게임용 3차원 그래픽 렌더링이라든가 동영상 코덱 같은 것만 떠올리기 쉬운데.. 사실은 2D 기반의 통상적인 GUI 구현을 위해서도 작은 수준의 하드웨어 가속이 오래 전부터 쓰여 왔다.
마우스 포인터라든가(깜빡이지 않는 것, 마우스 포인터 자취 표시, 포인터 주변의 그림자).. 화면 스크롤도 다 가속의 결과물이다. CPU 연산 기반으로 도트를 옮기는 수작업이 아니다.

(2) Windows의 그래픽 API (GDI)는 너무 범용적이고 장치 독립적으로 만들어졌다 보니, 당장 화면에 그려지는 픽셀 도트 값을 알아 내거나 색깔 바꾸기, 메모리 내용을 그대로 비트맵으로 간주해서 뿌리기 같은 간단한 작업조차도 오버헤드가 크고 일이 쉽지 않았다.
비디오 메모리에다 숫자 하나만 쓰면 끝날 일을 뭐 펜을 만들고 브러시를 만들고 DC에다 select시키고.. 운영체제 차원에서 직통 접근을 허용하지 않았던 것이다.

그러던 것이 Windows 3.0에서 DIB가 도입됐고, Windows 95 내지 NT 3.5에서 CreateDIBSection 계열 함수가 추가됨으로써.. 메모리 내용을 비트맵으로 그대로 뿌리는 일은 그럭저럭 가능해졌다. 옛날 WinG가 제공했던 기능도 다 이런 것들이었다. ‘비트맵 고속 전송’
다른 3D 가속 같은 거 전혀 없이 이거 하나만으로 Windows에서 Doom을 포팅하고 돌릴 수 있게 됐다.;;

Doom은 3D 전용 가속 기능이 없이 CPU와 초보적인 그래픽 가속만으로 만들어진 마지막 3D FPS였던 셈이다.
이거 마치 인어공주가 CG 없이 100% 셀 애니로만 만들어진 마지막 디즈니 애니인 것과 비슷한 느낌이다.

(3) 하긴, 옛날에는 그래픽 파일의 압축이라는 것도 원시적인 run-length 방식이 고작이었다. 더 빡세게 압축된 GIF나 PNG 파일 하나 열려면 386급 이상 컴퓨터가 필요했고, 디코딩도 훨씬 더 오래 걸렸었다. 하물며 JPG는 뭐 말할 것도 없고..
동영상조차도 1990년대 초중반에 Video for Windows 이러면서 나돌던 AVI는 쌩 run-length 압축인 게 많았다. 화질이나 압축률은 완전 허접 수준이었다.

WinAMP로 486/펜티엄 급 Windows 95 PC에서 128kbps짜리 mp3을 하나 재생하면 CPU 사용률이 10~20%까지 치솟았는데.. 이 역시 아련한 추억이다.
지금 우리가 전화기로도 당연하게 감상하는 디지털 멀티미디어 데이터들이 불과 2~30년 전에는 이렇게 가볍게 다뤄지던 물건이 전혀 아니었다. 그나마 가볍게 다루려면 기술 수준이 더 낮은 아날로그 매체만으로 만족해야 했다.;;

5. 나머지

(1) 64비트와 멀티코어는 서로 다른 별개의 분야이지만 거의 같은 시기에 태동해서 동시에 도입됐다(Core 2 Duo). plug & play와 USB하고 비슷한 관계인 것 같다. Win95/98 시절엔 USB 없이 직렬 포트에다가 프린터나 스캐너를 연결하고는 "새 하드웨어 발견.." 이러기도 했었다는 것 기억 나시는가? =_=;;
아울러, 모니터가 와이드 화면이 대세가 된 것도 2000년대 중반쯤으로 64비트니 멀티코어니 하던 때와 시기가 아주 비슷하다.;;

(2) 2000년대 초중반, 사운드 카드가 '인텔 사운드맥스'인지 뭔지 아무튼 메인보드에 내장돼 들어갔다. 그래픽 카드도 어지간히 까다로운 게임을 하는 게 아니라 기본 기능은 그냥 메인보드 내장으로 퉁쳐졌다.

(3) 요즘 노트북이나 스마트폰은 너무 얇아져서 뭔가를 꽂는 단자조차 너무 간소화되는 것 같다. 이건 개인적으로 좀 불편하게 느낀다.;;
가령, 구형 맥북은 큼직한 USB-A를 바로 꽂을 수 있지만 요즘 맥북은 그렇지 않고 C형만 꽂을 수 있다. 그리고 구형 갤럭시는 컴터용 이어폰을 바로 꽂을 수 있는 반면, 요즘 갤럭시는 그렇지 못하다.

(4) 범용적인 컴퓨터 말고 다른 기계들의 사정은 어떨까?
가정용 게임기, 업소용 오락기.. 이 둘도 차이가 있을 것 같고 내비게이션, 노래방 기계, 그리고 VR 게임기에 쓰이는 컴퓨터도 평범한 가정용 CPU 기반은 아닐 것 같은데.. 심지어 x86 계열이 아닐지도..??
요즘은 폰에 밀려서 디지털 카메라라는 물건이 많이 도태했지만, 그래도 부팅이 엄청 빨리 되는 것과 zoom이(= 렌즈빨) 더 뛰어난 건 디카만의 독자적인 장점이다. 그런 기기를 프로그래밍 하는 건 아무래도 임베디드 영역이지 싶다.

Posted by 사무엘

- 크롬 브라우저: 가끔 멍 때리면서 URL + 엔터 때려도 페이지 로딩이 안 되고 아무 동작 안 하는 버그. 아마 어디 스레드끼리 데드락이 걸린 것 같은데.. chrome 프로세스들을 몽땅 강제 종료시키고 재시작을 해야 해결된다. 열어 놨던 브라우저 창들은 다 날아가고.. 빨랑 고쳐졌으면 좋겠다.

- Window 시작 메뉴: 가끔 검색어를 입력해도 멍때리면서 아무것도 안 나오는 버그. 이거 진짜 Windows 10 초창기부터 있었고, 고쳐진 듯하다가도 지금 win11 시국에서도 제대로 고쳐지지 않은 것 같다. 프로그램 좀 똑바로 못 만드나.. =_=

- '영화 및 TV'나 클래식 Media Player가 낫지, '미디어 플레이어' 앱은 품질이 개허접이다. 슬라이더를 움직여서 동영상을 여기저기 seek하다 보면 영상이 안 나오고 먹통 되는 버그가 있다.

- Windows 배경 그림이 일정 시간 간격으로 쫙 오버랩으로 바뀔 때: 수백만 개에 달하는 픽셀이 수십 프레임을 거쳐 바뀌는 계산량 부하가 장난이 아니긴 할 것이다. 하지만 컴 성능이 딸리면 오버랩 프레임 수가 떨어져야지, 돌아가는 프로그램의 실행이 느려지고 랙이 걸리지는 말아야 한다!

내 철칙은.. 사용자가 직접 실행하지 않았고 백그라운드 후방에서 저절로 돌아가는 프로그램은 전방 프로그램의 실행의 겉보기 성능, 특히 UI 반응성에 영향을 주는 일은 절대 없어야 한다는 것이다. CPU 팬을 쓸데없이 돌아가게 만들지 말아야 한다. 그 정도의 대규모 작업이 불가피하게 필요하다면.. 작업 진행 상황을 표시하고 취소/중단 명령을 내릴 수 있는 UI가 제공돼야 한다!
무단으로 백그라운드에서 자원을 소모하는 프로그램은 비행 신고 없이 영공을 무단으로 날아가는 듣보잡 비행체와 같아서 언제든지 격추.. 아니, 강제 종료시킬 수 있어야 한다.

- 워드패드: 실행 직후 글꼴 콤보 상자를 처음 펼칠 때 딜레이가 수 초 이상 너무 길다. Windows 7 이래로 11까지도 여전하다. 수많은 글꼴들을 일일이 들여다보면서 미리보기 만드는 건 아무래도 스레드로 옮겨야 할 거 같은데?

- PowerPoint: Word, Excel은 안 그런데 얘만 인터넷 다운로드한 파일을 제대로 열지 못한다. alt+enter 눌러서 위험 태그를 없애 줘야 열린다. 도대체 왜..?? (2013 기준)

마소에서 만드는 PC용 앱들의 완성도가 20년 전, 30년 전만 하지 않은 것 같다.
일단 PC 앱에서 발생하는 수익이 크게 감소했고, 그리고 인터넷 발달 덕분에 "일단 출시부터 하고 버그는 나중에 패치로 때우지 뭐~~~" 이런 사고방식이 만연해서 그런 게 아닐까 싶다.

필름 카메라 시절에야 하나 하나 조준 사격으로 정말 신중하게 찍어야 했겠지만, 요즘 디카/폰카야 뭐.. 닥치는 대로 마구 갈기고 나서 제일 잘 나온 거 하나만 고르면 되지 않는가? 사고방식이 그런 식으로 바뀌었다는 것이다.

옛날에는 소프트웨어도 한번 마스터 디스크 만들고 패키지의 양산에 들어가면 뭔가 더 수정을 할 수 없었다. 책을 출판하는 것과 비슷해서 테스트와 디버깅을 아주 신중하게 진행해야 했다. 설명서에 미처 들어가지 못한 깨알같은 보충 설명은 프로그램 내의 별도의 readme.txt에다가 집어넣기도 했다. 하지만 이제는 이런 것도 다 옛날 추억 관행이 됐다. ^^

* 웹 로그인 관련 불편한 거

(1) 웹사이트마다 제각각 들쭉날쭉인 비번 최대 길이, 허용되는 문자 집합과 조합 조건들 제발 좀 표준화하고 조건을 완화했으면 좋겠다.
가령, 비번을 30자~40자씩 엄청 길게 넣었다면, 숫자 특수문자 X랄 안 넣고 알파벳 대소문자만 있어도 허용해 주는 식으로.
20여 년 전에 이거 조건을 까다롭게 하자고 제안했던 어떤 아재가 지금 와서는 이거 만든 걸 후회한다고 자책했을 정도이다.

비번이야 어차피 해시값을 저장할 텐데 길이 제한을 도대체 왜 넣냐 X신같이..?? 우리는 비번을 서버 DB에다 평문 String[20] 이렇게 저장한다고 광고하는 거냐? -_-;;

(2) 로그인을 실패했으면 아이디와 비번 중 뭐가 틀렸는지 좀 알려줬으면 좋겠는데.. 나만 그렇게 생각하나?
"아이디 또는 비번이 잘못됐습니다" 이런 막연한 말은 개인적으로 좀.. -_-;;
이거 알려준다고 해서 딱히 보안이 더 취약해지고 위험해지는 것 같지는 않은데?

내가 지금까지 읽었던 그 어떤 정보보호 보안 가이드에도 뭐가 틀렸는지 구체적으로 찝어주면 위험하다는 말은 없었다. 글쎄, 브루트 포스 방식으로 때려넣으면 실존하는 아이디는 수집이 가능해지겠지만.. 수집하는 효율도 그렇고, 아이디만으로는 할 수 있는 게 없잖은가? 오늘날 뿌려지고 있는 스팸메일의 양을 생각해 보면.. 어느 사이트든 아이디는 어차피 이미 털릴 대로 털려 있기도 하다. 그렇지 않은가?

물론.. 아이디를 잘못 입력한 것만으로 "이 아이디 존재하지 않습니다" 바로 튕기는 것까지는 과잉친절이고 바라지 않는다. 다만, 비번까지 입력하고 '로그인'을 누른 뒤에라도 비번에 앞서 아이디부터 잘못됐다면 나중에라도 그걸 좀 집어 줬으면 좋겠다.

그러고 보니 “비번을 N번 연속으로 틀린 계정은 접속이 금지됩니다. 현재 X번 틀렸습니다. 잠금 해제하려면 추가 인증을 받으세요” 이런 기능을 구현하려면 아이디는 어차피 노출이 불가피하다.
무차별 접속 시도를 통한 해킹을 봉쇄하려면 아이디를 숨기는 것보다는 저렇게 로그인에 한번 실패할 때마다 몇 초씩 딜레이를 넣고, 그게 몇 회 이상 반복되면 캡챠 같은 추가 인증을 실시하는 것만으로 충분해 보인다.

Posted by 사무엘

1. 파일 포맷

(1) 음원 mp3, 동영상 mp4, 글꼴 ttf은 통상적으로 쓰이는 파일 포맷이다. 그런데 담겨 있는 정보와 기능, 역할은 거의 같으면서 웹에서만 주로 쓰이는 비주류 포맷이 좀 있는 것 같다. 이를테면 weba, webm, webp, woff(웹폰트=_=) 같은 거..
아, webp는 jpg보다 압축률이 더 좋고 jpg를 대체하는 사진 포맷이라고 들었다. 구글에서도 사용을 적극 권장할 정도라고 하던데.. 그래도 jpg의 압도적인 인지도를 넘어설 수 있을지 모르겠다.

그나저나.. mp3의 특허 로얄티를 피하기 위해서 오픈소스 진영에서 ogg를 만들기는 했는데 그건 요즘 살아 있는지 모르겠다. 마소에서 20여 년 전에 만들었던 독자 포맷인 wma/wmv는 이제는 완전히 듣보잡이 되고 도태한 듯하다.

(2) 요즘도 RAR이나 7zip 같은 압축 프로그램이 살아 있는지 모르겠다.
PC에서는 하드디스크 용량이 워낙 넘쳐나고, 일정 수준 이상부터는 압축 프로그램들의 데이터 압축률이 도찐개찐이다 보니.. 뭐 압축률이 1%, 0.5% 더 좋다는 건 별 의미가 없다. 그냥 64비트 지원, 파일명에 유니코드 지원, 압축할 때 멀티코어 지원.. 이런 것만 따지면 된다.

그리고 압축 파일 중에 zip은 생성하고 해제하는 게 소스가 완전히 공개되어서 운영체제에 다 포함되었다 보니, 이게 사실상 독점이나 마찬가지이다. 어지간해서는 다른 압축 유틸을 쓸 필요가 없어지는 셈이다.
다만, 유닉스 진영에서는 여러 파일을 한데 묶는 것과 이걸 압축하는 절차가 분리되어서 tar.gz / tgz라는 압축 포맷이 쓰인다. 그리고 이것 말고 bz /bz2라는 압축 포맷도 있다. 원래는 bz였지만 무슨 심각한 보안 결함 때문에 사용이 금지되고 bz2로 완전히 대체된 것 같다.

2. 명령 프롬프트

(1) Windows 명령 프롬프트에도 where에 해당하는 명령이 좀 있었으면 좋겠다고 오래 전부터 생각해 왔는데.. 요즘 win10 무렵에 드디어 도입된 것 같다..;; 이름만 적어 준 실행 파일이 PATH 환경변수에 지정된 수많은 디렉터리들 중에 어디에 있는지를 알려주는 기능 말이다. XP 때까지만 해도 확실하게 없었다.
PATH 설정이 꼬여서 동명이인 중 엉뚱한 프로그램이 실행되는 것의 해악은 C에서 #define, C++에서 using이 잘못 사용되어서 컴파일러가 난독증을 일으키는 것과 거의 동급이라 하겠다.
오늘날 환경변수라는 건 아무래도 컴파일러와 빌드 툴 같은 데서만 쓰이는 경향이 있는데, PATH는 다른 많은 환경변수들과 달리 문자열의 길이가 혼자 압도적으로 길다. 수백~수천 자에 달한다.

(2) Windows에도 한쪽 폴더 내용을 다른 쪽으로 무식하게 복사하는 게 아니라, '동기화'를 시키는 rsync 같은 명령이 있어야 할 것 같다.
크기나 날짜가 변한 파일만 복사하고, 반대로 목적지 쪽에만 있고 출발지 쪽에는 없는 파일은 삭제도 하고 말이다.
옛날에 도스 시절엔 backup이라는 외부 명령이 있었는데.. 이와 비슷한 일을 했는지 모르겠다
그리고 파일을 지금 날짜로만 바꿔 주는 touch도.. 도스/Windows에는 이런 아기자기한 유틸이 은근히 부족하다.

(3) mkdir에 여러 단계의 디렉터리를 한꺼번에 생성하는 기능은 이제 추가된 것 같은데.. 새로 생성된 디렉터리로 바로 이동하는 옵션도 좀 있었으면 좋겠다. 114로 전화번호를 문의한 뒤, 그리로 바로 발신까지 하는 것과 비슷한 느낌이다.
그리고 Windows 9x 시절에 잠깐 있었던 cd ..... (여러 단계의 상위 디렉터리로 한꺼번에 이동) 도 있어서 나쁘지 않았던 기능인데.. 좀 그립게 느껴진다.

(4) 하위 디렉터리를 깔끔하게 한번에 몽땅 지우는 명령이 유닉스는 rm -rf *.*이고, Windows에서는 del /s /q *.* 이다.
하지만 하위 디렉터리까지 깔끔하게 표시하는 명령은 상황이 다르다. 도스/Windows는 아주 간단하게 dir /s인 반면, 유닉스의 ls에는 비슷한 명령이 없어서 좀 아쉽다. 글쎄, 설계 취지가 다른 건가?
find라는 명령을 이용해서 다른 명령과 조합을 해야 하는데.. 영 직관적이지 못하다.

(5) 파일과 디렉터리들이 엄청 많이 주렁주렁 달린 부위를 지울 때는 탐색기 같은 GUI 환경에서 지우는 것보다, 이렇게 명령을 이용해서 조용히 지우는 게 속도가 월등히 더 빠르다. 진행 상황 같은 거 표시 안 해도 좋으니, 수단과 방법을 가리지 않고 빠르게 지우는 명령이 GUI에도 좀 있었으면 좋겠다. 복사하고는 상황이 좀 다르다.

3. 문자

(1) 유니코드와 UTF-8 인코딩이 세상을 다 평정한 이 와중에.. 우리나라도 구닥다리 KS X 1003 규격은 폐기하고 \ 원화 기호를 역슬래시로 좀 되돌렸으면 좋겠다. 역슬래시를 자기네 화폐 기호로 사용하는 나라는 전세계에서 한국과 일본밖에 없다. 이건 정말 쓸데없는 짓이다.

(2) 도스와 Windows에서는 디렉터리 구분자가 \ 이고, 옵션을 나타내는 스위치는 / 이다.
그 반면, 유닉스 계열에서는 디렉터리 구분자가 / 이고, 옵션을 나타내는 스위치는 - 이다. 이런 쓸데없는 차이 때문에 같은 프로그램의 포팅도 더 어려워져 있다.

(3) 줄 바꿈 문자의 차이점도 아주 유명하다. \r\n이냐 \n이냐 이것 때문에 FTP에도 파일 주고받을 때 텍스트 모드와 바이너리 모드의 구분이 존재했었다.
단, \r 단독은 클래식 macOS에서만 쓰던 전설적인 방식인데, 클래식 macOS가 단종되고 없어지면서 이 표기 역시 역사 속으로 사라지게 됐다.

(4) 보아하니 Windows는 앞으로 시스템 기본 코드 페이지를 utf-8 65001로 바꾸려는 모양이다. 그리고 이렇게 했을 때 제대로 동작하지 못하는 레거시 프로그램은 시스템 로캘/코드 페이지를 기존 949나 932 따위로 인식되게 호환성 '샌드박스' 보정을 해서 실행시킬 예정이다. 예전에 AppLocale이 하던 일이 운영체제 차원에서 그대로 흡수된다.
..W 함수가 아니라 ..A 함수로도 유니코드 문자열을 주고받을 수 있다니.. 흥미롭다. utf-8 코드페이지를 지원하는지 여부는 고해상도 DPI를 제대로 인식하는지의 여부와 비슷한 척도가 될 듯하다.

4. MS Office

마소 오피스 제품들 나열이 서울 지하철 노선색하고 싱크로율이 은근히 높은 것 같다~!!
Word 1호선 군청, Excel 2호선 초록, PowerPoint 3호선 주황, Outlook 4호선 파랑
OneNote 5호선 보라, Access 8호선 분홍!!!!
6호선만 좀 삐끗하고, Publisher는 7호선과 완전히 같지는 않지만 비슷한 옥색이다. ㄲㄲㄲㄲㄲㄲㄲㄲ (경춘선, 경의중앙선)

- Outlook은 2010까지만 해도 아이콘 색깔이 노랑이었다. 그러다가 2013부터 색깔이 노랑의 보색이나 마찬가지인 파랑으로 급변경..
덕분에 서울 지하철 노선색과의 싱크로율이 크게 올라갔다. 설마.. 일부러 노린 건지? 우리나라 1000원 지폐가 분홍에서 파랑으로 바뀐 것과 같은 큰 변화이다.

- Excel은 수학 쪽으로 발전해서 지금처럼 IEE754 실수뿐만 아니라 임의의 자리수에 정확한 연산을 지원한다거나,
문자 처리 쪽으로 발전해서 위지윅을 지원하는 특별 버전이 존재하면 어떨까 싶다. 개발자의 입장에서는 당연이 뒷목 잡을 만한 사항일 것이다. -_-;;

5. 단축키

(1) Ctrl+C는 명령 환경과 GUI 환경에서 기능이 서로 굉장히 다른 단축키가 됐다. GUI에서는 평범한 복사 명령이지만 콘솔에서는 프로그램 실행 중단 명령이기 때문이다.
생각해 보니 macOS는 복사 단축키는 Ctrl이 아니라 Cmd+C이니 둘이 겹치지는 않는다. 마치 유닉스 셸은 프로그램 실행과 명령이 도스 프롬프트보다 더 엄격하게 구분돼 있는 것처럼 말이다.

(2) 예전에, 특히 도스에서 BASIC 프로그래밍 시절에는 ctrl+C뿐만 아니라 ctrl+pause/break가 중단 용도로 많이 통용됐었다. 하지만 그건 이제 쓸 일이 없는 듯.. 어떤 프로그램이 응답이 멎어도 시스템 전체가 멎는 일 자체가 없어졌고, 키보드 버퍼가 꽉 차서 삑삑대는 일도 없어졌으니 말이다.

(3) 사실, pause/break 키 자체가 완전히 잉여가 되긴 했다. 시스템 속성 페이지를 꺼내는 win+pause 정도나 쓰인다.
Windows에서는 ctrl+break가 ESC와 거의 동급으로 대화상자를 없애는(취소) 기능이 있다고 한다. 심지어 얘 용도로 VK_CANCEL이라는 전용 키코드까지 할당돼 있다고.. 이건 또 무슨 의미나 의도인지 모르겠다.

(4) 예전에 Windows 2000 이전의 NT 3/4 시절에는 부팅 이후에 ctrl+alt+del을 한번 누르고 나서 로그인 화면으로 진입하게 돼 있었다. 이건 도스 시절에 컴퓨터를 리셋 시키는 일종의 자폭 스위치였는데 저 절차는 무엇을 의미하는 걸까??
뭔가 소프트웨어적으로 생성할 수 없는 key 조합으로 인증을 시행해서 매크로나 악성 코드를 걸러내는 게 아니었나 싶다. "밀어서 잠금 해제"처럼 말이다.

(5) 어지간한 GUI 환경에서 Ctrl+Z는 Undo를 의미하는 만국 공통 단축키로 정착했다. 허나, Undo를 도로 철회하는 Redo의 단축키는 의외로 여전히 파편화돼 있다. Ctrl+Y 아니면 Ctrl+Shift+Z로 말이다. 참 신기한 노릇이다.
마소 Windows 진영에서는 Ctrl+Y를 꿋꿋이 미는 듯하다. 그러나 맥 진영 등 다른 동네에서는 Ctrl+Shift+Z도 여전히 유효하다.

아래아한글의 경우, 다단계 undo 기능이 도입되기 전부터 Ctrl+Y가 caret 이후의 글자들을 몽땅 지우는 단축키로 쓰였기 때문에 자연히 Ctrl+Shift+Z를 선호하게 되었다.
그런데 실수로 Ctrl+Y를 누르면 undo 히스토리를 몽땅 날려서 redo를 앞으로 영원히 할 수 없어지는 동작이 행해진다니 거 참... 이것 때문에 낭패를 본 사람도 좀 있었다.
뭐, 본인은 한컴 사의 방침이나 정책이 마음에 안 드는 건 있지만 워드 프로세서로서 아래아한글은 아주 훌륭한 작품이라고 생각한다. 특히 단축키로 전광석화 같이 표를 편집하는 성능은 Word가 절대 범접할 수 없을 것이다.

6. pdf의 페이지 번호

워드 프로그램으로 출판물을 만들다 보면 종이에 인쇄되는 페이지 번호와, 실제로 인쇄될 때 순서상의 페이지 번호가 일치하지 않게 된다. 편의상 전자를 논리적인 쪽번호, 후자를 물리적인 쪽번호라고 구분하도록 하자.

물리적인 페이지는 그냥 직관적으로 1부터 N까지 번호가 순서대로 매겨져 있고 번호와 페이지가 일대일 대응한다. 그러나 논리적인 페이지는 같은 번호가 리셋되어 여러 번 쓰일 수 있고, 물리적인 번호와 일치하지 않을 수 있다.
마치 텍스트 파일의 실제 줄 번호와, 컴파일러의 에러 메시지에서 #line에 의해 보정되어 표시되는 줄 번호가 다를 수 있는 것처럼 말이다.

내가 pdf 포맷을 잘은 모르지만 각 페이지마다 이런 논리적인 페이지 정보가 들어가는지는 모르겠다.
특정 페이지로 찾아갈 때 물리적인 번호와 논리적인 번호를 구분해서 인식시킬 수 있었으면 좋겠다.

7. 나머지..

(1) 2010년대 중후반에는 macOS도 10 (X), Windows도 10이더니만 2020년대부터는 다들 10 버전을 탈피했다.
Java가 1.3, 1.4 이렇게 버전을 매기다가 어느 때부터 1을 떼어내고 그냥 5, 6, 7 버전을 매기기 시작한 것처럼.. PC용 소프트웨어들이 버전을 대체로 큼직하게 매기기 시작했다.
그런데 Windows 11은 지금 생각해 봐도 10과 차이가 뭔지, 왜 갑자기 어설프게 동글동글한 비주얼을 도입했는지 모르겠고 개발 취지가 이해가 잘 안 된다. 레지스트리를 한참 뒤져보지 않으면 11인지 알기도 쉽지 않은데 말이다.

(2) 한 PC에서 오가는 네트워크 패킷을 몽땅 훔쳐보는 기능이 있고 Windows는 훅킹을 통해서 내부 메시지가 오가는 걸 들여다볼 수도 있는데.. 어떤 운영체제에선 프로세스별로 파일을 여닫는 내력을 좀 훔쳐보는 기능이 있으면 좋겠다.
현재 열려 있는 파일 핸들, 그리고 열려고 시도했지만 실패한 파일명도 전부 로깅을.. 이러면 어떤 프로그램의 내부 동작을 이해하는 데 큰 도움이 될 것 같은데.. 이런 기능은 딱히 없는가 보다.

(3) 컴퓨터를 끌 때 시작 메뉴에서 전원 버튼을 클릭하는 건 마우스를 움직여야 하고 번거롭고 불편하다.
그래서 본인은 바탕 화면에서 Alt+F4를 눌러서 시스템 종료 대화상자를 꺼내곤 하는데..
가끔은 '절전'을 눌러야 하는데 실수로 종료나 재시작을 눌러서 열어 놨던 창들을 다 날리는 삽질을 하곤 한다.
동작을 선택하는 UI가 콤보 박스가 아니라 옛날 Windows 95/98 시절처럼 라디오 버튼 UI였으면 좋겠다. 걔는 원하는 명령을 단축키로 확실하게 지정 가능하기라도 하니까.. 아니면 콤보 박스라도 조작이 좀 더딘 extended UI를 사용하든가..

(4) macOS의 Finder는 파일에 대해 복사만 되지, 오려두기는 왜 늘 disable돼 있나 모르겠다. 이거 은근히 불편하다. Windows 탐색기처럼 단축키로 파일 이동이 간편하게 됐으면 좋겠다.

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