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

1. software is licensed, not sold

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. 오픈소스

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Posted by 사무엘

1. 동영상

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4. 전자와 전산의 관계

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

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

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

Posted by 사무엘

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Posted by 사무엘

1. Windows 명령 프롬프트에서의 UTF-8 지원

본인은 1년 남짓 전에 UTF-8 인코딩에 대해서 글을 쓰면서 Windows도 콘솔 환경에서 UTF-8이 지원되는 날이 올까 썰을 푼 적이 있었다.
이건 Windows 10이 업데이트를 거치면서 어느 정도 현실이 됐다. chcp 65001이 가능해졌다. 명령 프롬프트와 배치 파일에서 깨지는 문자열 걱정 없이 파일 이름이나 각종 메시지를 지정할 수 있다는 것은 좋은 소식임이 틀림없다.

사실, 콘솔 자체는 문자의 특정 인코딩에 전혀 구애받지 않고 임의의 바이트 나열을 주고받을 수 있는 '파일'일 뿐이다. 그러니 콘솔의 코드 페이지가 437이건 949건 65001이건 전혀 상관없이 프로그램은 모조리 생까고 아무 인코딩으로나 유니코드 문자열을 printf 같은 함수로 출력할 수 있다. 가령, chcp 949 상태이더라도 consoleapp.exe > output_in_utf8.txt 는 깨지는 문자 없이 얼마든지 가능하다는 것이다.

다만, C# 같은 언어로 콘솔 프로그램을 만들어서 System.Console.WriteLine을 해 보면, 닷넷 프레임워크가 현재 콘솔의 코드 페이지 번호에 따라(아마도 GetConsoleOutputCP 함수) 문자열을 1바이트 단위 기반으로 변환해서 출력한다.
그러므로 chcp 949 상태에서 듣보잡 한자를 찍으면 깨진 문자열이 아니라 완전히 정보가 소실된 ?로 바뀌어 찍히며, 이는 >를 이용해 파일로 redirect하더라도 마찬가지이다. chcp 65001을 해 줘야 이런 손실이 없어진다.

상황이 이러한데.. 현재 운영체제는 새로운 셸인 PowerShell 말고 기존 명령 프롬프트에 대해서는 chcp 65001이 그냥 가능은 하다는 선에서만 지원을 멈춘 듯하다. 하위 호환 문제 때문에 아예 처음부터 UTF-8를 디폴트로 구동시키지는 못하는 것 같다. 새로운 콘솔 프로세스를 생성해서 거기 코드 페이지를 65001로 변경하는 작업도 불가능하지는 않지만 꽤 번거롭고 지저분하다. Windows의 콘솔 API들은 자기 자신의 코드 페이지를 변경하는 것만 직통으로 지원하기 때문이다.

하긴, 437이니 949니 하는 ANSI 코드 페이지라는 건 유니코드를 지원하지 않는 레거시 앱들과의 호환 때문에 존재하는 개념이다. 그러니 시스템의 기본 코드 페이지가 65001이더라도 저런 디폴트 fallback용 코드 페이지는 계속해서 존재해야 할 것이다.
배치 파일은 @echo off로 시작하는 게 거의 관행인데, @를 거의 메타커맨드 식별자화해서 앞에 @encoding 이런 식으로 인코딩을 지정하는 것도 아주 황당한 생각은 아닐 것 같다.

더 궁극적으로는 굳이 콘솔에만 국한되지 않더라도, Windows API에서 A 함수와 W 함수는 UTF-8이냐 UTF-16이냐의 차이밖에 없어지는 날이 올까? UTF-8을 native로 지원한다는 표식이 된 프로그램에 한해서라도 말이다.
물론 요즘 만들어지는 프로그램이야 처음부터 W 함수만 쓰겠지만.. 타 플랫폼에서 1바이트 문자열 기반으로 유니코드를 지원해 온 프로그램을 포팅할 때는 저런 접근 방식도 분명 도움이 될 것이다.

레거시 프로그램들과의 호환은.. 지금 마소에서 high DPI 지원을 위해서 기를 쓰고 제공하는 샌드박스 가상화 계층만 만들면 얼마든지 가능하지 않겠나 개인적으로 생각한다. manifest 파일에 native UTF8을 지원한다고 명시해 주는 식으로 말이다.

2. 메뉴 간소화

기능이 너무 많아서 메뉴가 "파일, 편집, 보기, 도구"부터 시작해 10개를 훌쩍 넘어가고, 각 카테고리별로 항목들이 20개 가까이 주렁주렁 달린 방대한 프로그램을 생각해 보자. 사용자에게 굉장히 위압적으로 보일 것이다.

더구나 이런 메뉴들은 static한, 고정된 기능 나열 목록일 뿐이다. 파일 내지 글꼴 같은 다이나믹한 목록이 아니며, 사용자가 자주 사용하는 기능을 곧장 고를 수 있게 해 주는 것도 아니다. 프로그램의 모든 기능을 골고루 다 쓰면서 지내는 사용자는 당연히 극소수이고 말이다.

사정이 이러하니 이런 압박스러운 메뉴를 어찌해 보려는 노력이 먼 옛날부터 있었다.
자주 쓰는 기능과 그렇지 않은 기능을 프로그램 개발사에서 답정너 분류한 뒤.. 메뉴를 반토막 간소화해서 보여주는 옵션을 갖춘 프로그램의 예로는.. 도스 시절 MS QuickBasic IDE, 그리고 아래아한글 2.1과 그 이후 버전이었다. 메뉴에서 사라진 기능이라 해도 단축키로는 물론 상시 접근 가능하다.

아래아한글의 경우, 워디안/2002 이전의 3.x~97에도 간소화 메뉴 옵션이 있었던가 그건 잘 모르겠다.

마소에서는 딱 2000년대 초에 일명 Personalized menu라는 걸 도입했다. 사용 빈도를 동적으로 체크해서 오랫동안 안 쓰인다 싶은 메뉴는 감춰 버리고, 메뉴를 꺼낸 지 시간이 좀 오래 지나거나 맨 아래의 ▼을 눌러야만 메뉴가 마저 다 나오게 했다.
Windows 2000/ME의 시작-프로그램 메뉴, 그리고 MS Office 2000/XP/2003 정도에서 이런 메뉴를 볼 수 있었다.

이건 마소의 입장에서는 많은 시간과 비용을 들여 진행한 실험이었으며, 실제로 메뉴 첫인상을 좀 단순하게 보이게 하는 효과가 있었다.
하지만 사용자의 반응은 썩 좋지 않아서 최종적으로는 FAIL 판정을 받았다. Office 길잡이 같은 급의 병맛 흑역사는 아니었지만 몇 년 못 가 없어졌으며, 결국 2000년대 후반부터는 리본 인터페이스가 도입되었다.

참고로 Visual Studio IDE는 일반인이 쓰는 프로그램이 아니어서 그런지.. MS Office의 UI 엔진을 그대로 쓰던 시절에도 Personalized menu가 쓰인 적이 없었다. macOS에도 저런 게 도입된 적은 없지 싶다.

3. macOS

한편, macOS는..

• 응용 프로그램 패키지(.app)는 하위 디렉터리와 그 밑의 여러 파일들로 구성돼 있음에도 불구하고 Finder에서는 단일 파일인 것처럼 취급해 준다.
• 그 반면, zip 압축 파일은 그냥 단일 파일 형태임에도 불구하고 내부에 들어있는 하위 디렉터리와 파일들을 실제 파일과 다를 바 없이 seamless하게 표시해 준다.

없는 디렉터리를 있는 것처럼 표시하고, 반대로 있는 디렉터리를 숨기는 가상화를 구현하느라 애 많이 썼을 것 같다.
app 패키지도 안드로이드 apk처럼 그냥 압축 파일 컨테이너에다 넣어 버리지 싶은 생각이 든다. 성능 문제 때문에 그렇게 하지 않은 건지?

그리고 macOS는 GUI 응용 프로그램은 app이고 콘솔 프로그램은 그런 껍데기 없이 a.out 실행 파일인 건가? 일반 실행 파일과 달리 app은 표준 C 함수 말고 NSWorkspace 소속의 코코아 API를 써서만 실행할 수 있는 거고? (내부의 하드코딩된 경로에 일반 실행 파일이 있긴 함) 그 관계를 잘 모르겠다.

내 경험상 mac은 프로세스 간 통신이 Windows보다 제약이 심하고 폐쇄적인 것 같다. 특히 훅킹 같은 게 없기 때문에 macOS용으로 Spy++ 같은 프로그램을 만들 수는 없는 듯하다.
게다가 한 프로그램이 다른 프로그램으로 키 입력을 보내는 게 요 1, 2년 전쯤 시에라에서부터 막혔다. 사용자가 제어판을 열어서 동의를 찍은 프로그램에서만 가능하다.

이런 이유로 인해 macOS에서는 날개셋 편집기나 외부 모듈 같은 프로그램은 만들어도 날개셋 입력 패드 같은 구현체는 만들 수 없겠다. 또한 외부 모듈에서 키 입력을 보내는 날개셋문자도 구현할 수 없겠다. =_=;;

4. 맥 계열과 타 PC와의 차이

(1) 같은 파일이 컴퓨터를 옮기니까 크기가 몇십 MB씩 차이가 나 있어서 깜짝 놀랐는데..
알고 보니 Windows는 전통적으로 1024 기반의 MiB 단위를 쓰는 반면, 맥은 그냥 깔끔하게 1000 단위로 자리수를 매겨서 발생한 차이였다.

(2) 그러고 보니 맥OS는 메시지 박스에서의 버튼 배치 방식도 Windows와 다르다. '예'에 해당하는 1순위 버튼이 색깔도 파랗게 강조된 형태로 대화상자의 맨 오른쪽 아래에 있다. 이건 뭐 그냥 디자이너의 취향 차이인 것 같다.

(3) 일반적으로 키보드의 좌측 하단에는 modifier key들이 ctrl, fn, win, alt의 순으로 배치돼 있다. 그러나 애플 제품들은 맥북/아이맥 구분 없이 다 fn, ctrl, alt, cmd(win)의 순이기 때문에 1234가 2143으로 기묘하게 바뀌어 있다.
서로 알력 싸움에 따로 노는 건지는 모르겠지만, 두 종류의 컴퓨터를 드나드는 사람의 입장에서는 이게 불편하기 그지없다..;;

5. 안드로이드와 iOS

요즘 전세계에 보급된 스마트폰들에서 안드로이드와 iOS의 점유율이 적게는 7:3, 많게는 4:1 가까이 된다고 한다.
이 둘을 더하면 진짜 99.99%이고, Windows Phone 등 타 운영체제는 이제 유의미한 점유율을 완전히 상실한 듣보잡이라고 한다. 마소에서도 Windows 기반의 자체 모바일 운영체제는 이미 포기하고 접었고..

오픈소스 진영에다가 구글· 삼성의 막강한 지원 덕분에 안드로이드는 확실한 주류가 됐다. 하지만 그렇다고 iOS가 무시 가능한 처지인 건 아니다.
이건 마치 전세계 도로의 우측통행 vs 좌측통행의 점유율과 비슷한 구도인 것 같다. 내 기억으로 저것도 비율이 3:1 내지 4:1쯤이지 싶다.

좌측통행이 분명 비주류이긴 하지만 그렇다고 극소수인 건 아니며, 영국· 일본· 오스트레일리아 등 존재감을 절대로 무시할 수 없는 강대국 선진국들이 엄연히 좌측통행을 하고 있다. 그러니 완전히 없어질 수가 없다.
이런 좌측통행의 점유율과 위상이 마치 오늘날 iOS의 그것과 비슷하게 느껴진다는 것이다. 오래된 생각이다. (CPU 업계에서 리틀 엔디언과 빅 엔디언의 점유율 비율은 어찌 되었나 궁금해지기도 한다만..)

그러고 보니 세벌식도 여전히 1%가 채 안 되고, 내가 혼자 생각하는 것보다 훨씬 더 지위가 약한 마이너이구나..;;
더구나 지금 세벌식을 쓰는 사람들도 자기 자식에게까지 차마 세벌식을 권하지는 않겠다고 다짐하는 경우가 적지 않다. 이걸 생각하면 일면 우울해진다. 타자가 편리한 것보다 당장 생활에서 불편하고 번거로운 게 더 크게 느껴지는가 보다.
그나마 명분이 옳고 객관적으로 이론적으로 성능이 우수하기 때문에 오늘날까지도 명맥이 유지되고 있는 것이다.

Posted by 사무엘

1. Windows 재설치

(1) 본인 주변의 어떤 컴퓨터는 절전이나 최대 절전 말고 '시스템 종료'로 확실하게 껐는데도 불구하고 나중에 다시 와 보면 무슨 좀비처럼 저절로 다시 켜져 있곤 했다. 사람이 건드린 건 당연히 전혀 아니고..
절전 상태에서 깨어나는 게 아니라 완전히 꺼졌던 컴퓨터가 왜 어떻게 저절로 다시 켜지는지는 나로서는 도무지 이해할 수 없다. 컴퓨터를 끄는 걸로도 모자라서 플러그까지 완전히 뽑아야 되나 하는 생각마저 들었다.
이건 검색을 해 보니 2015~16년경 Windows 10 초창기에 존재했던 버그였다.

(2) Windows가 맛이 가서 제대로 부팅이 되지 않을 때 안전 모드로 부팅한다거나, 컴을 팩토리 리셋 시키기 전에 최소한 백업이라도 하기 위해서 긴급 명령창이라도 열려면 파란 배경의 Windows RE (Recovery Environment)에 들어가야 한다.
부팅 때 F8 같은 특정 단축키를 눌러서 여기로 바로 들어갈 수 있으면 좋겠구만.. 꼭 부팅 중에 컴퓨터를 강제로 끄는 무식한 삽질을 5~10번쯤 해야 그제서야 "잠시 기다려 주세요"와 함께 저리로 들어가는 게 개인적으로 굉장히 마음에 안 든다.

(3) Windows를 새로 설치한 직후에 다중 모니터를 연결해 봤는데.. 무작정 꽂기만 한다고 장땡이 아니구나. 2개 중 HDMI 케이블로 연결한 4K급 모니터는 아무리 제대로 꽂아도 화면이 나타나지 않았다. 그래픽 드라이버를 업데이트 한 뒤에야 잡히더라.

그래도 요즘 컴퓨터는 수십 년 전 옛날에 비해 새 하드웨어를 꽂아서 사용하는 게 얼마나 간편 편리해졌나 모른다. 상당수가 plug & play와 USB 덕분인데, 생각해 보니 두 기술이 동시에 같이 등장한 건 아니라는 게 의외이다.

2. 자동 시작 프로그램 목록

그나저나 Windows 10은 아마 3.x 이래로 20년 가까이 변함 없던 '시작 프로그램' 등록 지점을 변경했구나. 난 지금까지 모르고 있었다. 어쩐지 '시작프로그램'이라는 폴더가 왜 안 보이나 했다. Windows 8 시절에도 변함없었던 것 같은데..
디렉터리 기반인 건 변함없지만 그게 시작 메뉴의 목록 디렉터리 아래가 아닌 다른 곳으로 바뀐 것 같다.

운영체제가 부팅될 때 자동으로 실행시킬 프로그램의 목록은 저 디렉터리뿐만 아니라 레지스트리에도 여러 군데가 있다. 이것만 한데 정리해도 블로그 글 한 편이 써지지 싶다. 도스가 사라지면서 config.sys와 autoexec.bat가 없어졌지만, 걔네들이 하던 기능까지 없어진 건 아닌 셈이다.
리눅스나 macOS는 자동 시작 프로그램 목록을 어디에서 지정하는 걸까? 궁금해진다.

아울러, 요즘 Windows는 SMB(쌈바)가 기본으로 깔리지 않는가 보다. 랜선 꽂고 인터넷이 멀쩡히 되는데 탐색기에서 \\로 시작하는 공유 폴더 서버에 왜 이리 접속이 안 되나 했더니.. "프로그램 추가/제거"에서 해당 기능을 설치해야 했다. 인터넷 검색을 하면 '로컬 보안 정책'을 고치라니 뭐니 하는 말이 있었지만, 그걸 건드릴 필요는 없었다.

3. embedded 컴포넌트로 활용 가능한 브라우저

2010년대 이후로 웹브라우저 시장에서 IE의 독주가 꺾이고 크롬, FireFox, Edge 같은 대체 브라우저들이 많이 쓰이고 있다.
그런데 IE는 여느 브라우저들과 달리 컴포넌트화가 잘 돼 있다. 그래서 임의의 프로그램 내부에 IE 기반의 브라우저 창을 집어넣어서 단순 HTML 내지 웹 컨텐츠를 표시할 수 있다. 기술 기반은 잘 알다시피 COM/ActiveX이고 말이다.

IE 말고 다른 브라우저 창을 내 프로그램에다가 내장시키는 건 가능한지 모르겠다.
그게 가능하지 않다면 IE는 이쪽 고정 수요 때문에 계속 없어지지 않고 명맥을 유지할 것 같다.

4. 잠금 화면의 배경 그림

Windows 8(.1)까지만 해도 안 그랬던 것 같은데.. 10부터는 부팅 직후, 또는 Win+L을 눌렀을 때 나타나는 잠금 화면에 기본적으로 근사한 각종 자연 경관 배경 그림이 나타난다. 각종 업데이트를 받기에도 네트워크 트래픽이 빠듯할 텐데, 어떤 서비스는 거기에 또 짬을 내서 그림 파일도 찔끔찔끔 받아 놓는가 보다.

이 그림도 분명 디스크 어딘가에 파일 형태로 저장될 텐데, 슬쩍 빼돌리는 방법에 대해서는 이미 팁이 나돌고 있기 때문에 검색해 보면 다 나온다. 그런데 본인이 문득 궁금한 건 이 그림들을 마소의 어느 부서에서 담당하고 있으며, 누가 어디서 이런 사진들을 구해서 올리느냐 하는 것이다.
Windows와 mac 진영 모두 근사한 자연 경치 사진을 공급받는 비밀 거래처가 있는 것 같다. 그건 개인일 수도 있고 기업일 수도 있다. Windows XP의 초원 배경은 이미 아주 유명한 사례이다.

5. Windows - 설정 창의 불편한 점

요즘 Windows는 버전업을 거듭할수록 제어판은 뒷전으로 밀려나고 운영체제의 모든 설정을 메트로 앱인 '설정'으로 하게 UI를 옮기려는 게 보인다.

(1) 그런데 이놈의 설정 앱은 좀 여러 개를 띄울 수 없나? 프로그램 추가/제거 같은 창을 꺼내 놓은 상태로 디스플레이/개인 설정 같은 걸 띄우려니 기존 창이 바뀌어 버리는 게 굉장히 불편하다. 10수년 전에 탭이 없던 IE6 시절에, 응용 프로그램에서 인터넷 링크를 클릭하면 기존 브라우저 창에서 그 링크가 열려서 짜증 나던 게 고스란히 재연되고 있다.

(2) '설정'에서는 키보드의 연타 속도를 조절하는 방법이 1803 내지 1809 빌드 기준으로 여전히 존재하지 않는다. 그럼 그런 키보드 설정은 기존의 제어판에 들어가서 하라고 링크라도 띄워 놔야 되는데 그것도 없는 건 문제인 것 같다.
마우스의 경우, '설정'에서는 좌우 버튼 교환이나 휠 스크롤 분량 같은 대중적인(?) 옵션만 있다. 포인터 모양을 바꾸는 매니악한 옵션은 제어판에 가서 하라고 '추가 마우스 옵션' 링크가 표시되어 있다. 키보드는 그런 게 없고 '고급 키보드 옵션'은 그냥 IME/문자 입력 쪽 설정밖에 안 나온다.

(3) 요즘 Windows 10에서 중국어· 일본어 IME를 쓰고 싶으면 해당 언어와 키보드만 등록하는 게 아니라, 언어 팩을 다 받아서 설치해야 하는 것 같다. 전자까지만 하면 IME가 뜨긴 하지만 실질적으로 중국어· 일본어 입력이 되지 않는다.
20년쯤 전 먼 옛날에는 마소에 내장돼 있는 외국어 IME를 처음 등록할 때 운영체제 CD를 집어넣어야 했다. Vista~7에서는 그냥 전세계 언어가 다 깔렸었는데 이제는 인터넷으로 받는 형태로 절차가 바뀐 것 같다.

(4) 그리고 외국어 UI 팩이나 입력기, 필기· 음성 인식 데이터를 받고 설치하는 버튼을 실수로 잘못 눌렀는데, 작업을 취소하는 버튼을 왜 마련해 놓지를 않았는지? 이것 때문에 꽤 당혹스럽고 불편한 경험을 하기도 했다. =_=;;

6. 입력 도구모음줄의 불편한 점

오늘날 Windows 10에서는 IME에 대해서 브랜드 아이콘(한)과 상태 아이콘(가/A) 딱 둘만 작업 표시줄에 붙어 있는 극도로 단순화된 아이콘 표시 모델을 지원한다. 요건 사실 2012년의 Windows 8때부터 도입된 것이니 생각보다는 오래됐다.

지금도 과거의 XP~7 시절을 풍미했던 길쭉한 입력 도구모음줄을 쓰는 것 자체는 가능하다. 특히 키보드에 한자 키가 없거나, 그 키를 자기 멋대로 가로채는 프로그램(MS 오피스 프로그램..)에서 한글 IME의 고유 방식대로 한자 변환을 하려면 이 도구모음줄이 필수이다. 한자(漢) 버튼이 노출되어 있어서 마우스 클릭이 곧장 가능하기 때문이다.

그런데 이 도구모음줄을 꺼내는 옵션이 꽤 찾기 어려운 구석진 곳에 있다는 점은 차치하고라도.. 이 도구모음줄이 불편한 점 중 하나는 floating 상태일 때 화면에서 찾기가 어렵다는 점이 아닐까 한다. 그리고 그 이유 중 하나는 배경색이 순 화이트이기 때문이지 싶다.

이 도구모음줄은 도입된 이래로 배경색은 줄곧 작업 표시줄의 색깔과 일치해 왔다.
Windows 98/2000/ME에서는 회색, XP에서는 파랑 같은 테마 색 또는 회색(고전), 그리고 Vista/7에서는 역시 검정..
그러니 10에서도 저 패턴이라면 배경색이 작업 표시줄의 색깔과 같은 검정이어야 할 텐데, 어째 제목 표시줄의 색깔과 같은 흰색이 됐다.

제목 표시줄도 흰색이지, 프로그램의 일반 클라이언트 영역도 흰색이지, 그런데 설상가상으로 도구모음줄 주변엔 아무 테두리도 없고 그림자도 없으니.. 찾기 어려울 수밖에 없다.
역대 Windows들 중에 TSF 도구모음줄의 배경색이 흰색인 버전 자체가 Windows 10이 유일하다시피하다. 8과 8.1에서는 어땠는지 기억이 안 난다만 걔네들도 흰색은 아니었지 싶다.

하지만 이 도구모음줄은 MDI 창이라든가 HTML 도움말처럼 마소에서 더 개발이나 지원을 하지 않는 레거시일 뿐이니, 얘에 대한 개선은 앞으로 기대하기 어려울 것 같다.

7. caret의 깜빡임이 멈추는 현상

이제 단순히 불편한 점을 넘어 버그 얘기를 좀 해 보자. 내 컴퓨터만 그런 줄 알았는데 아니더라.
요즘 Windows에서 날개셋 편집기, 메모장, 워드패드처럼 운영체제가 제공하는 caret(키보드 커서)을 사용하는 프로그램을 띄워서 가만히 놔둬 보면..
caret이 딱 5번 깜빡이고 나서 6번째로 나타난 뒤부터는 깜빡이지 않고 그대로 멈춰 버린다.

Windows 10의 1803과 1809 버전에서 모두 확인했는데 이런 버그가 왜 생겼나 모르겠다. 2015~16년대의 구버전에서는 이런 일이 없었다. 아니, 수십 년 전의 Windows 95 이래로 이런 현상은 처음 본다.
Spy++로 들여다보면.. caret을 깜빡여 주라는 메시지 자체가 더 오지 않고 멈춘다. 그에 반해 아래아한글이나 MS Word 같은 전문 워드 프로세서는 이런 메시지에 의존하지 않고 자체적으로 caret을 운용해서 그런지 깜빡임이 멈추지 않는 것 같다.

8. Dependency Walker의 오동작

이전에는 이런 현상이 없었던 것 같은데.. Windows 10 1809를 설치한 뒤에는.. 각종 실행 파일을 Dependency Walker 유틸로 들여다보고 분석하는 게 다소 불편해졌다.
Windows 7쯤부터 운영체제의 자체 제공 EXE/DLL들은 kernel32.dll의 함수들을 kernel32로부터 직통으로 import하는 게 아니라 프로세스, 스레드, 파일, DLL로딩 등 각종 세부 분야로 나뉜 가상의 DLL로부터 import하기 시작했다. comctl32의 로딩 방식은 side-by-side assembly 방식으로 바뀌더니 kernel32는 저렇게 바뀌었다는 게 흥미롭다.

그런데 Windows 10 1809 버전에서는.. KERNEL32.DLL은 API-MS-WIN-CORE-PROCESSTHREADS-L1-1-1.DLL에 의존하고, 후자는 또 전자에 의존하는 구조가 돼서 여기서 일종의 무한루프에 빠진다.
비록 Dependency Walker 자체가 뻗는다거나 하지는 않지만, 이 때문에 분석 시간이 굉장히 길어지고 모듈 분석 트리도 쓸데없이 거대하고 지저분한 모양으로 만들어진다.
문제가 개선됐으면 좋겠지만 Dependency Walker는 무려 Windows Vista 초창기인 2006~7년 이후로 개발이 중단되고 버전업이 없으니 아쉽다.

Posted by 사무엘

1. 32비트 컴파일러: 16비트 메모리 접근의 한계를 극복하기

예전에도 언급한 적이 있지만.. 1993년 말에 발매되었던 Doom 게임은 그야말로 충격적인 3차원 그래픽 덕분에 게임 업계에 큰 충격을 선사했다. 업계 종사자들은 기술 수준 자체뿐만 아니라 "얘는 어셈블리어를 거의 사용하지 않고 순수 C만으로 개발되었습니다"라는 존 카맥의 말에 더 큰 충격을 받게 됐다.

훗날(1997년) Doom의 소스 코드가 공개되면서 이 말은 사실임이 밝혀졌다.
Doom은 무슨 16비트 Windows 같은 쑤제 어셈블리어 튜닝 위주로 개발된 게 아니라, Windows NT처럼 굉장히 이식성 있게 개발되었다. 그러니 Doom 엔진 기반의 수많은 게임과 mod들이 온갖 플랫폼으로 이식되어 만들어질 수 있었다.

단지, 오리지널 도스용의 경우, 컴파일러를 그 당시에 흔하던 볼랜드나 MS 같은 16비트용을 쓴 게 아니라 Watcom이라는 다소 생소한 32비트 고성능 제품을 썼을 뿐이다.
그리고 어셈블리어를 안 쓰더라도 고정소수점이라든가, IEEE754의 특성을 이용해서 3차원 그래픽용 실수 연산(삼각함수, 제곱근, 벡터 정규화...)을 왕창 빠르게 수행하는 각종 tweak들은 응당 최대한 구사해서 성능을 끌어올렸다.

그러니 Doom은 아직 상대적으로 생소하던 32비트 컴파일러라든가 DOS/4G 도스 익스텐더 같은 물건의 인지도를 끌어올려 줬다. 이렇게 Doom을 통해 Watcom 컴파일러까지 알렸던 id 소프트웨어에서는 훗날 퀘이크를 만들어서 이번에는 오픈소스 진영의 걸출한 도스용 32비트 컴파일러이던 djgpp를 알리게 되었다.

운영체제 자체를 OS/2나 Windows NT처럼 통째로 32비트로 쓰기에는 아직 기계값이 너무 비싸고 특히 메모리가 부족했다. 그러니 도스에서 돌아가는 일부 대형/고사양 프로그램이 자체적으로 도스의 한계를 극복하고 보호 모드로 진입하는 솔루션을 내장했던 것이다.

생각해 보니 국내에서도 아래아한글 2.1이 전문용은 Watcom C/C++을 이용한 32비트 전용으로 만들어졌다. 얘는 발매 시기가 심지어 Doom보다도 3개월 남짓 더 앞섰다(1993년 9월 vs 12월). 그러니, 터보 C, 볼랜드 C++ 하던 그 시절에도 32비트 컴파일러에 대해서 알 사람은 이미 다 알기는 했던 모양이다.

다만, 아직도 286 똥컴이 많이 굴러다니고 서민용 운영체제들은 아직도 16비트 도스와 Windows가 주류인데, 내 프로그램을 386 전용으로 개발하는 것에 대한 득과 실을 신중하게 따져야 했다. 오죽했으면 아래아한글도 후속 버전인 2.5와 3.0에서는 일반용/전문용 구분이 없어지고 그냥 hwp86.exe와 hwp386.exe 두 에디션을 모두 내장하는 것으로 형태가 바뀌었다. 추가 글꼴과 사전 컨텐츠는 '확장팩'으로 분리되고 말이다.

아래아한글은 Phar Lap 도스 익스텐더를 사용했다. 아래아한글이 그 시절의 도스용 게임처럼 DOS/4G(W) 로고를 띄우면서 실행되었다면 무척 볼 만했을 것이다.
86과 386 에디션은 성능 말고는 덧실행 프로그램이 지원되는지의 여부가 가장 큰 차이점이었다. 덧실행은 16/32비트용이 따로 나오지 않고 32비트 전용이었기 때문이다.

화면 보호기들, 그리고 확장팩에서 제공되었던 프라임 영한사전도 다 덧실행 프로그램이었다.
먼 옛날 1.2 시절에는 별도의 액세서리로 테트리스 게임이 있었는데 나중에 그게 덧실행으로 컴백한 걸 보니 개인적으로 감회가 새로웠었다.

이렇게 1990년 중반에 도스용 프로그램들의 32비트화 추세와 달리, 마소는 진작부터 PC에서 도스를 Windows로 대체하려는 큰 그림을 갖고 있어서 그런지.. 도스용으로 32비트 컴파일러를 결코 내놓지 않았다. 정작 자기들은 그 기술을 내부적으로 보유하고 사용했으면서 말이다.
Visual C++ 1.5x는 16비트 도스/Windows 바이너리들을 빌드할 수 있었는데, 명령 프롬프트에서 돌아가는 컴파일러와 링커 같은 툴들은 그냥 32비트 프로그램이 아니라 32비트 PE 기반의 콘솔 프로그램이었다.

Windows NT 같은 데서는 직통으로 실행 가능하고, 도스에서 실행되면 stub으로 embed된 도스 익스텐더가 컴을 보호 모드로 진입시키고 CreateFile/GlobalAlloc 같은 Win32 API를 제공해서 프로그램을 실행했다.
스레드를 만들지는 못했겠지만 컴파일러· 링커가 사용하는 Win32 API야 뭐 파일이나 메모리 I/O 정도밖에 없었을 것이고, 이건 도스 익스텐더가 감당 가능했다. 결국 한 바이너리만으로 도스와 Windows에서 모두 사용 가능.

이건 뭐 콘솔 프로그램계의 Win32s나 마찬가지인 엄청난 기술인데.. 마소의 Visual C++에서 이런 이중 바이너리를 만드는 걸 end-user에게 지원한 적은 내가 알기로 없다.
마치 C# 네이티브 코드 컴파일러만큼이나 대외적으로 공개되지 않고 마소 내부에 봉인된 기술인 것 같다.

2. 슈퍼 VGA 라이브러리: 표준 VGA의 한계를 극복하기

IBM 호환 PC라고 불리는 물건에서 IBM이 주도하는 PC의 단일/표준 규격이라는 건 286 AT 이후로 없어졌다. 그러니 286 이후로 최초의 386 PC는 IBM이 아닌 컴팩에서 출시되기까지 했다.
그리고 그래픽 카드도 절대불변 단일 표준은 1987년의 구닥다리 VGA가 마지막이다. 표준 VGA는 800*600 해상도조차 지원하지 않았으며, 그나마 색깔이 아쉬운 대로 다양해진 256색은 겨우 320*200에서밖에 지원되지 않아서 업무라기보다는 그냥 게임 전용 모드로만 쓰였다.

그 뒤로 VGA보다 더 높은 해상도와 더 많은 색상을 지원하는 규격은 그야말로 온갖 싸제 SVGA 제조사들이 난립하면서 파편화 천국이 됐다. VESA 같은 규격이 괜히 필요해진 게 아니다.

이게 불과 1990년대 초반의 일이니, 앞에서 언급한 보호 모드가 어떻고 DPMI가 제정되던 때와 시기적으로 비슷하다. 하긴, 1990년에 나온 그 옛날 프로그램인 Deluxe Paint조차도 처음 실행될 때 맨 아래에 1024*768 256색 SVGA 모드가 있긴 했다. 물론 당대에 그걸 선뜻 고를 수 있을 정도의 금수저 컴퓨터를 소유한 사용자는 매우 소수였을 것이다.

마소의 베이직 컴파일러야 SCREEN 명령으로 SVGA 지원은 전무했다. API 구조가 완전히 다른 3rd-party 라이브러리를 구해서 써야 했다.
볼랜드의 경우는 상황이 약간 낫다. 비록 자체적으로는 VGA까지밖에 지원하지 않았지만, 일종의 그래픽 드라이버인 bgi 파일이 내부 스펙이 공개돼 있고 확장 가능했기 때문에 이걸 기반으로 SVGA 라이브러리를 만든 곳이 있긴 했다.

검색을 해 보니 Jordan Hargraphix 소프트웨어가 이 업계의 독자적인 큰손이었던 모양이다. 이미 1991년 무렵부터 유명했다.
바이오스를 거치지 않고 일명 VGA mode X라고 불리는 320*240, 400*300 같은 변형 모드까지 다 지원했다.
그때는 소프트웨어가 잘못된 명령을 내려서 컴퓨터만 뻗게 하는 게 아니라 모니터를 손상시키는 것도 가능했던 시절이다. (주사율 변조..) 옛날에 CGA도 160*100 같은 tweak mode가 있었다고 하는데 그것만큼이나 신기한 일이 아닐 수 없다.

다만, BGI라는 그래픽 API는 무려 1980년대 후반에 개발된 것이며, 아무리 bgi 드라이버를 새 하드웨어에 맞게 확장한다 해도 256색 이상의 색을 지원하는 것은 구조적으로 불가능했다고 한다. 트루컬러 SVGA를 지원하려면 완전히 새로운 독자 라이브러리를 써야 했다.
BGI는 색상을 관리하는 게 RGB값 기반이 아니라 팔레트 인덱스 기반으로 고정돼 있었던 모양인데, 16비트 시절에 이는 충분히 수긍이 간다. 쟤가 무슨 Windows GDI 급으로 하드웨어 통합과 추상화를 표방한 물건은 아니었으니 말이다.

도스용 아래아한글은 16비트 바이너리의 경우 Turbo/Borland 컴파일러로 개발되었다. 하지만 아주 초창기인 1.x 시절부터 그래픽 라이브러리를 독자 구현했는지, 볼랜드의 보급 BGI 라이브러리를 사용한 흔적이 전혀 없는 것이 매우 흥미롭다.
이건 비슷한 시기에 도스용 한메 타자 교사도 마찬가지다. 얘도 MS C로 개발되었지, 의외로 볼랜드 출신이 아니다.

Posted by 사무엘

1.
인텔 CPU의 역사를 살펴보자면.. 1971년에 무려 4비트짜리로 나온 4004가 최초의 상업용 마이크로프로세서라고 여겨진다. 그 뒤 72년에 8비트 8008이 나오고, 1978년의 16비트 8086이.. 오늘날까지 이어지는 x86 아키텍처의 서막을 열었다.

8086, 80186, 80286은 모두 16비트 CPU이다. 186은 PC에서는 거의 쓰이지 않았고, 286은 이론적으로는 보호 모드와 멀티태스킹까지 지원하는 물건이었지만 구조적인 한계 때문에 소프트웨어에서 실제로 제대로 활용되지는 못했다.

086에서 286으로 넘어가는 과정에서는 그냥 CPU의 클럭 속도만 올라가고, IBM PC 규격 차원에서 XT/AT의 차이가 더 컸던 것 같다. 가령, 하드디스크 탑재라든가 고밀도 디스켓 지원 말이다. 키보드의 반복 속도 조절 기능도 내 기억이 맞다면 AT부터 지원되기 시작했다.

무려 1985년, 아직 VGA도 없던 시절에 80386 CPU가 개발되어서 IA32라는 아키텍처가 완성되긴 했다. 하지만 이때는 컴퓨터의 가격이 너무 비싸서 32비트가 가정용으로 보급되기는 곤란했다.
나중에 외부 데이터 버스를 32 대신 16비트로 줄여서 가격을 좀 낮춘 보급형 386SX라는 게 등장했다. 훗날 등장한 펜티엄은 반대로 그 버스의 크기가 64비트로 머신 워드 크기보다도 더 커졌으니, 386SX와 좋은 대조를 이룬다.

또한 386 때부터 슬슬 캐시 메모리가 쓰이기 시작했으며, 486에서부터는 부동소수점 프로세서(FPU)가 기본 내장으로 들어가기 시작했다. 클럭 속도의 증가는 덤이다.
486 이후로는 인텔이 숫자 명칭 대신 '펜티엄'이라는 자체 브랜드명을 사용하기 시작했고, 펜티엄 다음으로는 코어.. 코어 안에서는 네할렘, 샌디브릿지 같은 세부 공정이 달라질 때마다 새로운 명칭을 붙여서 제품을 구분하고 있다.

2.
2000년대 중반, 딱 Windows XP와 IE6이 장수하던 05~06년 사이에 멀티코어와 64비트가 도입되면서 PC의 환경이 20세기 시절과는 크게 달라진 듯하다. 둘은 도입 시기가 완전히 일치하지는 않지만 미묘하게 비슷하다. 펜티엄 4의 후기형을 거쳐서 펜티엄 D에서부터 싱글코어 기반의 x86-64가 정착했으며(정확히는 2003~04년 사이), 반대로 Core 1 Duo는 32비트 전용의 첫 멀티코어 프로세서였다.

그러다가 둘이 합쳐져서 Core 2 Duo가 64비트 + 2개짜리 멀티코어 시대를 열었다. 운영체제는 Windows Vista/7부터 말이다.
사실 Core 1 Duo는 PC용으로는 출시도 되지 않고 모바일용으로 나왔는데, 애초에 x86이 모바일에 적합한 구조의 아키텍처가 아니다 보니 존재가 모순적이었다. 그러니 별 재미를 못 보고 단종됐다.

CPU가 그렇게 바뀐 동안 모니터는 LCD와 와이드가 도입되었다. 옛날에는 4:3 비율의 액정 모니터도 있었지만 2000년대 중후반쯤에 자취를 감춘 듯하다.
요즘은 형광등이 처음 켜질 때 깜빡거리는 걸 볼 일이 없어진 것처럼.. CRT TV나 모니터를 처음 켤 때 화면이 예열과 함께 천천히 fade in 되는 모습도 볼 일이 없어졌다.

또한 기분 탓인지는 모르겠지만, 예전에는 모니터의 테두리 색깔이 흰색이 많았는데 와이드 화면 모니터는 검은색이 주류가 된 것 같다.

3.
인텔 CPU가 초창기에 저렇게 발전해 온 동안, 우리나라는 역사적으로 국가에서 나서서 전국민에게 PC를 보급한 적이 딱 두 번 있었다. 전자는 그 말 많던 "교육용 PC" 사업이고(1980년대 말), 후자는 그로부터 10년쯤 뒤, IMF에다 세진 컴퓨터 랜드가 아직 있고 인텔 펜티엄 2, 셀러론 이러던 시절의 국민 PC 사업이다.

전자의 사업 때 이미 많이 보급돼 있던 MSX니 SPC니 하는 8비트들을 싹 배제하고 과감하게 16비트 IBM 호환 PC를 지정한 것은 마치 철도 표준궤와 220V 전압만큼이나 미래를 내다본 굉장한 선견지명이었다. 결국은 그 PC 계열이 천하를 평정했기 때문이다. 1980년대 당시에 정보통신부나 과학기술처의 담당 관료가 중대한 결정을 잘 내렸다.

뭐, 8비트 컴터들은 대체로 화면 해상도가 낮고 성능도 떨어져서 당장 한글· 한자 처리에 애로사항이 너무 크긴 했다. 그 문제 때문에 한국· 일본은 16비트 컴에서 비디오 카드조차도 허큘리스에서 거의 곧장 VGA로 갈아탔지, 서양처럼 CGA/EGA를 진지하게 경험하지는 않았으니 말이다.

지금이야 PC는 너무 흔해 빠지고 기업의 입장에서는 이윤도 별로 안 남아서 하나 둘 철수할 지경이 돼 있다. 남사스럽게 PC에 연연할 필요 없이 폰이 다 보급돼 있고.. 당장 돈이 없어도 온갖 할부 제도를 이용해서 뿌리다시피하고 있다. 저 시절의 컴퓨터와는 비교할 수 없을 정도로 더 성능 좋고 작은 컴퓨터를 전화기에다가 얹어서 들고 다니는 게 경악스럽게 느껴질 지경이다.

4.
지금까지 CPU 얘기가 나왔으니 말인데,
문자 인코딩을 CPU 명령의 인코딩에다 비유하자면, UTF-8은 CISC에, UTF-16이나 32는 RISC에 딱 대응하는 것 같다.
원래 UTF-8은 그 구조상 5~6바이트까지도 늘어나서 U+10FFFF보다 더 큰 코드값도 기록이 가능은 하다. 하지만 언제부턴가 인코딩 규칙이 개정되어서 5~6바이트짜리는 현재로서는 고이 봉인하고, 1~4바이트까지만 사용하기로 했다.

오늘날 국내외의 컴덕이나 프로그래머들 중에는 UTF-8을 완전 만능으로 칭송하는 한편으로 UTF-16은 거의 사회악 쓰레기 수준으로 싫어하는 사람이 종종 눈에 띈다. 프로그래밍 배경이 Windows가 아닌 유닉스 계열인 사람, 그리고 특히 wchar_t의 플랫폼별 파편화 때문에 삽질과 고생을 단단히 한 사람일수록 그런 성향이 더욱 강하다.

본인은 주장의 논지는 이해하지만 그 정도까지 부정적인 견해에는 공감하지 않는다.
컴퓨터에서 어떤 데이터를 주고받기 위해서는 결국은 값을 그대로 전하든지, 아니면 좀 덩치가 큰 데이터는 별도의 메모리에다가 저장해 놓고 그 메모리 주소만 전하든지.. 둘 중 하나를 선택해야 한다. 32비트니 64비트니 하는 건 그 컴퓨터의 CPU가 한번에 취급하는 그 정보의 크기 단위이다.

문자 하나를 전하기 위해서 일일이 메모리 할당해서 문자열을 만들고 포인터를 전달하느냐, 아니면 그 문자의 코드 포인트 값만 간단하게 전하느냐.. 이게 얼마나 큰 차이인지는 프로그램 좀 짜 본 사람이라면 누구나 공감할 것이다.

그 와중에 옛날 사람들이 UTF-16이라는 계층의 존재를 예상 가능했던 것도 아니고, 1990년대에 메모리가 지금만치 풍부하고 저렴했던 것도 절대 아니고, 그저 모든 글자의 크기를 2바이트로 균일하게 늘리는 것만으로도 메모리를 너무 많이 잡아먹네 하던 시절에.. UTF-8도 아니고 UTF-32도 아닌 적당한 절충안인 UTF-16 내지 그 전신 UCS-2가 과연 그 정도로 태어나지 말았어야 한 존재인 걸까? 그게 아니라는 것이다.

내가 보기에 이건 유니코드에 현대 한글 글자마디 11172자가 일일이 다 등록된 게 잘못된 거라고 비판하는 것과 비슷해 보인다. 그렇게 등록을 안 했으면 글꼴을 만들기가 훨씬 더 복잡하고 어려워지고, DB 문자열 필드나 파일명 같은 데에 집어넣을 수 있는 한글 글자 수가 크게 감소했을 텐데 말이다.

문득 Windows가 오로지 65001 UTF-8만으로 천하통일이 이뤄지고.. 심지어 9x 시절처럼 W가 아닌 A 함수가 주류로(그 대신 UTF-8 기반으로!) 회귀하는 엉뚱한 상상을 해 본다. 물론 실현 가능성은 사실상 0일 것이다. =_=;;
Windows의 WCHAR뿐만 아니라 macOS의 NSString, Java의 Char과 jstr, COM의 BSTR 등 많은 운영체제와 프레임워크들은 2바이트를 문자의 기본 단위로 사용하고 있으니 어차피 이걸 쉽게 벗어날 수 있지도 않다.

5.
컴퓨터에서 일상적으로 볼 수 있는 보조 기억 장치는 결국 (1) 자기 디스크, (2) 플래시 메모리, (3) 광학 디스크 이 세 범주 중 하나로 귀착된다. 또 완전히 새로운 범주가 개발될 여지가 있으려나 모르겠다.
용량과 속도 가성비가 "전반적으로" 제일 뛰어난 건 역시나 자기 디스크이다 보니, 얘를 기반으로 한 '하드디스크'는 가히 유구한 역사를 자랑한다. 기계식, 물리적인 요소가 존재하는 장치임에도 불구하고 오늘날까지도 컴퓨터에 여전히 건재하다.

플래시 메모리는 PC에서는 USB 스틱 아니면 SSD의 형태로 요긴하게 쓰이고 있다. 동작 중에 일체의 소음과 진동이 없는 순수 전자식이며, RAM과 보조 기억 장치의 경계를 허물 차세대 주자로도 각광받는 물건이다. 하지만 가격 때문에 하드디스크를 완전히 대체하는 건 여전히 무리이다.

마지막으로 광학 디스크인 CD/DVD/블루레이는 매체의 외형부터가 빛을 반사하는 새끈한 재질인 게 굉장히 간지 나고 미래 지향적으로 보인다. 하지만 20여 년 전에 40배속인가 뭔가에서부터 읽기 속도가 한계에 달했으며, 쓰기를 마음대로 할 수 없다는 치명적인 한계 때문에 쓰임이 반쪽짜리가 됐다.

USB 메모리와 초고속 인터넷 파일 전송, 가상 디스크 마운트 기술에 밀려서 광학 디스크를 사용할 일이 예전에 비해 극히 드물어진 것이 사실이다. 이제는 부팅조차도 USB 메모리만으로 가능해질 정도가 되기도 했고 말이다.

옛날에는 레이저를 사용하는 컴퓨터 주변 기기들이 굉장히 비쌌다. CD 라이터라든가 레이저 프린터 말이다. 이런 것들이 개인이 쉽게 보유할 정도로 흔해진 건 이르게 잡아도 1990년대 말이고 21세기에 와서부터이다.
또한 얘들은 다 열을 많이 가하는가 보다. 레이저 프린터만 해도 종이를 고온 고압을 가해서 토너가루를 붙이는 식으로 인쇄하는데(그래서 타 인쇄 방식에 비해 전기도 많이 씀), 광학 디스크에다 기록하는 것도 한국어· 영어 공히 '굽다/BURN'이라고 표현할 정도로 비슷한 메커니즘을 동원하는 듯하다.

여담이지만, 자기 디스크는 영어 철자가 disk이고, 광학 디스크들은 철자가 disc라는.. 미묘한 차이가 있다.

6.
터치스크린은 기존 키보드와 마우스를 완전히 대체하지는 못하지만, 그래도 모니터를 출력 장치뿐만 아니라 입력 장치도 겸하게 해 주는 깔끔하고 참신한 인터페이스임이 틀림없다. 단순히 버튼을 콕콕 찍어서 선택하거나 간단한 필적을 그리는 용도로 아주 좋다.

터치스크린을 구현하는 방식은 크게 감압식과 정전식으로 나뉜다. 감압식은 물리적인 압력을 감지하는 방식이고, 정전식은 그게 아니라 표면의 전기 신호의 변화를 감지하는 방식이다.
이게 마우스로 치면 제각기 볼 마우스와 광 마우스에 대응하는 것이나 마찬가지로 보인다. 전자가 좀 기계식이고 후자는 말 그대로 전자식이다.

처음에는 전자와 후자가 장단점이 서로 호각인 지경인데, 기술적인 구현 난이도는 후자가 더 높았다. 하지만 세월이 흐르면서 지금은 결국 기술적인 한계가 극복되고 후자의 장점이 더 부각된 덕분에, 후자 방식이 주류 대세가 되었다. 이런 변화 양상도 마우스와 터치스크린이 서로 동일하다.

엘리베이터 버튼 중에도 오로지 사람의 생 손가락만 인식하고 타 물체 내지 장갑 낀 손가락은 인식하지 않는 게 있는 게 개인적으로 신기한 한편으로 잘 이해가 되지 않았다. 마치 광 마우스는 유리판 위에서는 좀체 동작하지 않는 것처럼 말이다.
그렇게 생 손가락만 인식하는 센서들은 다 정전식이다. 감압식이라면 무슨 물체를 쓰든지 버튼을 누른 건 다 인식돼야 할 것이다.

정전식은 감압식보다 터치를 더 부드럽게 인식할 수 있으며 특히 마우스가 결코 흉내 내지 못하는 멀티터치를 구현하는 게 더 유리하다.
Windows 98에서 마우스 휠이 정식 지원되기 시작했다면 지난 Windows 7에서 터치 장비가 정식으로 지원되기 시작했다. 안 그래도 7은 그림판이 크게 개선되어서 초보적이나마 브러시 엔진까지 도입됐는데, 여러 손가락으로 동시에 태블릿을 긁으면서 그림을 그리던 시연 모습이 인상적이었다.

하지만 본인은 데스크톱/노트북급에서 화면이 터치스크린을 지원하는 장비는 10년째 한 번도 못 봤다. 장비를 주위에서 쉽게 접할 수 있었다면 날개셋 한글 입력기에도 멀티터치 같은 걸 연계한 입력 도구를 구현할 생각이라도 했을 텐데 그건 지금까지도 그냥 장기 계획으로만 머물러 있다.

그러고 보니 이런 터치 장비는 좌표뿐만 아니라 압력 정보까지 전할 수 있다.
다만, 얘들은 올록볼록 입체적인 점자를 표현하지 못하니 터치스크린 기반 UI는 장애인과는 그리 친화적이지 못한 인터페이스이다. 이건 뭐 어쩔 수 없는 귀결이다. 시각 장애인 내지 손가락을 자유롭게 움직이지 못하는 사람은 스마트폰도 여전히 버튼식 폴더 형태로 된 기기를 써야 한다.

7.
자동차에 경차라는 차급이 있고 총기 중에도 제일 작은 권총이라는 게 있듯, 컴퓨터계에서 제일 작은 놈은 넷북이지 싶다. 정말 작고 아담해서 들고 다니기 편하며 값도 저렴하다. 부담 없이 인터넷과 문서 작업만 하는 용도로는 참 좋다.

하지만 얘는 그만큼 CPU의 성능이 매우 뒤떨어지고 화면 해상도도 너무 낮으며, 키보드 역시 적응이 힘들 정도로 너무 작은 편이다. 그렇기 때문에 얘로 단순히 글자판떼기 치기 이상으로 다른 생산적인 일을 하기에는 애로사항이 많다. (프로그래밍, 그래픽 디자인 등등..) 아니, 사람에 따라서는 키보드의 구조 때문에 단순 글자판떼기 치기조차도 불편하게 느껴질 수 있다.

게다가 2010년대부터는 PC가 아닌 스마트폰 운영체제에 기반을 둔 각종 태블릿 판떼기들이 급속히 발전한 덕분에, 단순 휴대용 인터넷 단말기 및 게임기라는 수요는 사실상 거기로 다 흡수됐다. 그러니 단순히 노트북 PC를 경차급으로 줄인 넷북이라는 건 사실상 존재 의미를 상실하고 오히려 그 태블릿들이 필요에 따라서는 키보드를 연결해서 쓸 수도 있는 형태가 됐다.

물론 터치스크린은 기존 키보드와 마우스를 결코 완전히 대체할 수 없으며, 정보의 소비와 열람이 아니라 정보를 생산하는 도구로서 PC의 지위는 예나 지금이나 변함없다. 또한, 넷북이 없어진다고 해서 넷북의 용도 내지 걔들이 수행하던 작업 자체가 없어지는 건 아니다. 휴대용 컴퓨터는 좀 더 모바일 기기와 결합한 형태로 변모하고, 전통적인 PC는 자기 역할에 특화되는 쪽으로 가는 듯하다.

8.
1990년대 초반

• 86키 키보드는 이제 거의 도태하고 101키 키보드가 대세가 됐다. 옛날 키보드는 F11, F12가 없으며, 기능 키 F1~F10이 맨 왼쪽에 2열 5행으로 세로로 배치돼 있었다. 지금의 capslock 자리에 ctrl이 있고 capslock은 지금의 우alt/ctrl 자리에 있었다. 키패드에서 우측 하단인 지금의 엔터 자리에 더하기가 있었다.
• 옛날에 키보드는 정체를 알 수 없는 이상한 전용 포트에다 꽂았으며 마우스는 모뎀과 같은 COM.. 직렬 포트에다 꽂았다. 프린터는 병렬 포트에 꽂았고.. 모뎀과 마우스의 충돌은 정말 대표적으로 골치아픈 문제였다.
• Plug & play도 없고 USB도 없던 시절이니, 외장 하드디스크를 연결해서 인식시키는 것만 해도 바이오스 설정을 바꾸는 등 정말 고도의 컴터 지식이 필요한 작업이었다.

1990년대 중반

• 좋은 그래픽 카드를 사용하면 화면이 바뀌는 곳에서도 마우스 포인터가 깜빡거리지 않기 시작했다. 단, 흑백 기본 포인터 한정으로. custom 포인터는 여전히 깜빡거렸다.
• 486쯤부터는 컴퓨터 본체가 모니터 밑받침으로 까는 형태가 아니라 모니터 옆에 세워 놓는 형태로 거의 정착했다. 하지만 Windows의 '내 컴퓨터' 아이콘은 XP에 가서야 이 모양을 반영하는 형태로 바뀌었다.
• 486/펜티엄급 컴에서 WinAMP로 128kbps급 mp3를 하나 재생하면 CPU 점유율이 10~20%가량 올라가곤 했다.
  

1990년대 후반

• 시스템 종료 후에 컴퓨터가 자동으로 꺼지기 시작했다. "이제 컴퓨터를 끄셔도 안전합니다"라는 주황색 글자를 사용자가 직접 볼 일이 없어졌다.
• Windows 98쯤부터 멀티웨이브가 가능해졌다. 지금으로서는 정말 믿어지지 않지만, 원래 옛날에는 한 프로그램에서 사운드를 출력하기 시작하면 다른 프로그램에서 사운드를 사용할 수 없었다!

1999~2000 사이

• 컴퓨터 규격이 크게 바뀌었다. 그 이름도 유명한 USB 포트라는 게 등장했고, 키보드와 마우스용 초록색-보라색 PS/2 포트도 등장했다.
• 전원을 3초 이상 꾹 눌러야 꺼지는 관행도 이때부터 정착했다.
• 사운드카드의 스피커가 이제 컴터 본체에 내장되지 않기 시작했다.
• 가정에서도 모뎀 대신 인터넷 전용선이 슬슬 보급되기 시작했다.

2000년대

• 이제 custom 마우스 포인터도 깜빡이지 않기 시작했다. 사실 Windows 2000은 9x와 달리, 16색 VGA 구닥다리 안전 모드에서도 마우스 포인터가 깜빡이지 않는 게 개인적으로 굉장히 신기했다.
• 컴퓨터에서 오디오 CD의 음원을 추출하는게 옛날에는 쉽지 않았는데 이제는 손쉽게 가능해졌다.
• USB 메모리가 디스켓을 확실하게 골로 보냈으며, 무선 인터넷과 합세하여 CD의 지휘조차 위협한다. 호각인 라이벌은 엄청난 용량을 자랑하는 하드디스크뿐..
• PS/2포트조차 한물 가고 키보드와 마우스도 그냥 USB 기반으로 나오기 시작했다.
• Windows Vista부터는 동영상 화면도 일반 화면과 아무 차이 없이 print screen으로 캡처 가능해졌다.

Posted by 사무엘

1990년대 말~2000년대 초에 어지간한 인터넷 웹사이트들은 폭이 참 꾀죄죄하고 입구나 메뉴가 플래시로 만들어졌으며, "IE 6 브라우저와 1024*768 해상도에서 가장 잘 표시됩니다" 이런 거 적는 게 유행이었다. 커뮤니티 게시판은 제로보드 4로 만들어지기도 했다. 물리적인 프레임 구분이 있는 웹사이트도 있었다. "이 페이지를 보려면 프레임을 지원하는 브라우저가 필요합니다" 에러 문구도 있고 말이다.

지금 저런 사이트를 보면 유지 보수되고 있지 않은 옛날 구닥다리 골동품 냄새가 풀풀 느껴질 것이다. 게시판은 온통 스팸 광고글로 넘쳐나고 있지 않은지가 걱정될 지경이고 말이다.

요즘 스타일의 웹사이트라면 큰 폭에 유연히 대처할 뿐만 아니라 플래시 없이 JavaScript만으로 모든 인터랙티브한 UI를 구현해야 한다. 특히 화면이 아래로 스크롤 됐을 때 메뉴 같은 게 쏙 줄어들어서 화면 한구석으로 밀려나는 거라든가.. 목록의 끝을 열람했을 때 다음 목록이 뒤에 실시간으로 추가되는 기능 같은 게 요즘 유행인 것 같다. css만 바꿔서 모바일 최적화 페이지도 제공하고 말이다.

사실, 본인조차도 HTML 지식은 거의 2000년대 초반 이래로 정지-_-해 있어서 최신 스타일의 홈페이지를 만드는 법을 잘 모른다. 그래도 옛날보다는 지금이 웹 기술들의 파편화가 훨씬 줄어들고 웹 개발자들이 일하기 편리해지긴 했다.
지나간 옛날 이야기이다만 싸이월드의 사이트 개편도 그런 변화를 따라가기 위한 명분과 당위성이 충분한 개편이었다. 구형 싸이월드는 시대에 너무 뒤쳐졌었기 때문이다. 하지만 개편을 매끄럽게 제대로 못 하고 개악에 가까운 수준으로 해 버리는 바람에 사용자들이 대거 이탈하고 망하게 됐다.

웹사이트의 현대화를 나타내는 지표는 단순히 저렇게 외형적인 것에만 있는 게 아니다.
웹 문서들의 인코딩은 국제 표준으로 등극한 UTF-8로 통일하도록 하고, 서버의 각종 URL에도 오로지 영문· 숫자만 쓰거나 아니면 최소한 UTF-8방식으로 인식하게 설정해야 한다.
1990년대 말에 한글로 된 파일을 첨부한 것이 인식되지 않는 문제를 해결한답시고 IE에서 "URL을 언제나 UTF-8 방식으로 보냄" 옵션을 끄는 게 팁으로 통용되었던 건.. 마치 Windows Vista에서 UAC 옵션을 끄는 팁만큼이나 뭔가 미개한 관행이었다.

그리고 요즘 무시할 수 없는 대세가 바로.. HTTPS이다. 이건 웹사이트계의 디지털 서명이나 마찬가지이다.
사용자가 서버로 뭔가를 입력하고 보내는 게 전혀 없이 오로지 일방적으로 조회하고 표시하는 기능밖에 없는 사이트라면 모를까, 로그인을 하고 최소한의 interaction이 있는 사이트라면 내가 이 사이트를 믿고 내 개인 정보를 제공해 줘도 되겠는지에 대한 보증이 필요하다.

요즘 최신 브라우저들은 HTTPS가 아닌 구닥다리 HTTP를 쓰면서 폼 입력 기능이 있는 웹사이트에 대해, 갈수록 더 적극적으로 "이 사이트는 위험함, 정보 전송을 권장하지 않음"이라고 경고하는 추세이다.
그러니 사이트 운영자들은 깔끔한 UX를 방문자에게 제공하기 위해서는 HTTPS를 도입해야 하는데.. 여기에는 대가가 따른다. 인증서를 발급받아야 하고 암호 해독 때문에 서버의 트래픽과 오버헤드가 더 증가하는 것도 감수해야 하고.. 귀찮다.

내 홈페이지는 언제쯤 HTTPS를 도입하게 될지 모르겠다. 웹사이트가 아니라 당장 날개셋 한글 입력기 바이너리조차도 디지털 서명을 안(못) 하고 배째라 쌩으로 배포하고 있거늘..;;

이렇듯, Windows 기준으로 응용 프로그램의 현대화 지표가 유니코드 API, 고해상도 DPI 지원, 공용 컨트롤 6 매니페스트 같은 거라면, 웹사이트의 현대화 지표는 UTF-8, 無플래시, 최신 HTML/CSS 요소, 모바일 페이지, HTTPS 같은 것들이라 하겠다.

그나저나, HTML5 웹표준의 지원 수준 척도로 여겨지고 있는 ACID3 테스트 말이다.
마소에서 만든 IE11과 Edge도 ACID3을 100점 만점으로 통과하고 있고 Google 크롬 역시 예전에는 그랬던 것 같은데 요즘 버전은 97점에서 멈추고 있다. 내 자리만 그런 줄 알았는데 그렇지 않다. 또 뭐가 바뀌어서 그런지 모르겠다.

한편으로 크롬은 과거에는 APNG(png 기반 애니메이션)를 웹 비표준이라는 이유로 지원하지 않다가 요즘은 지원하기 시작했다.
크롬도 나온 지 벌써 10년이나 됐다(since 2008). 정말 엄청난 속도로 버전업을 하고 있고 지금도 프로그램 내부가 쉴 새 없이 변하고 있는 것 같다.

또한, 요즘은 세상이 바뀌어서 옛날처럼 마소와 오픈소스 진영이 브라우저 전쟁을 하는 게 아니며, Visual Studio로 어설픈 Windows Phone 앱 대신 무려 안드로이드 앱을 만드는 지경이 됐다. 옛날에다 비유하자면 컴퓨터 세계에서 미국· 소련간의 냉전이 끝난 것이나 마찬가지인 것 같다.
삼성 갤럭시와 애플 아이폰도 갈수록 서로 비슷해져 가고 있다. (배터리 일체형은 삼성이 따라하고, 큼직한 화면은 애플이 따라하는 식)

IT 업계가 전반적으로 분리와 파편화가 아니라 통합과 상생이 대세인 듯하다.
마소의 경우 빌 게이츠와 스티브 발머 같은 초창기 원로들이 경영진에서 물러나고 사티아 나델라가 집권한 뒤부터 경영 방침과 회사 분위기가 굉장히 크게 바뀐 게 느껴진다. 제아무리 천하의 마소라 해도 영원무궁토록 Windows와 Office만 갖고 먹고 살 수는 없는 노릇이고, 언제까지나 오픈소스 진영과 척지고 살 수는 없으며 인제 와서 Windows Phone이 안드로이드와 아이폰을 이긴다는 건 불가능할 테니 말이다.

뭐, 경쟁자들을 적대시하여 어떻게든 독과점으로 말려 죽이려 했던 옛날 마소 경영자들의 전략도 그 시절에는 기업의 생존을 위해 필요하긴 했을지 모른다. 천하의 삼성 전자도 과거에는 일본의 아류 짝퉁이나 만드는 영세 전자 기기 제조사였던 적이 있으며, 마소도 처음에는 그냥 공룡 하드웨어 제조사에다가 소프트웨어를 납품해서 먹고 사는 을의 처지로 시작했다는 점을 기억할 필요가 있다. 지금의 여유로운 잣대로 옛날을 함부로 판단하지는 않을 것이다.

Posted by 사무엘

1. COM

1970년대 중반, MS-DOS의 전신격인 CP/M 때부터 있었던 완전 초창기 실행 파일 포맷이다. 고안자는 개리 킬달.
엄밀히 말해, 얘는 파일 포맷이라 할 것도 없는 쌩 메모리 이미지 덤프였다. 그 어떤 고유한 헤더나 메타데이터도 없이 그냥 곧장 기계어 코드와 데이터가 쭉 이어질 뿐이었다. 코드와 데이터는 모두 64KB 단일 세그먼트에 묶여 있었고, 메모리 주소의 첫 256바이트는 시스템 용도로 예약되어 있어서 프로그램이 사용할 수 없었다.

확장자가 com인 실행 파일은 그냥 명령 프롬프트에서 돌아가는 간단한 유틸밖에 없을 것 같지만, 그래도 겨우 몇만 바이트 남짓한 com 형태로 그래픽 모드에서 실행되는 게임도 많이 나왔었다. 그래픽이라고 해 봤자 320*200 4색 CGA 수준이긴 했지만.. Alley Cat처럼 말이다.
1980년대에 들어서 컴퓨터의 대세가 8비트에서 16비트로 넘어가고 성능과 메모리 용량이 향상되자, 이 형식은 큰 프로그램을 만들기에는 너무 비좁아졌다. 그래서 확장할 필요가 생겼다.

2. MZ EXE

1983년, MS-DOS 2.0에서 최초로 도입됐다. 그 전의 1.0은 파일 시스템에 서브디렉터리라는 게 지원되지 않았으며 실행 파일도 아직 COM밖에 없었다.
EXE는 단일이 아닌 다중 세그먼트(특히 코드 영역과 데이터 영역의 분리)를 도입하여 64KB 공간 한계를 얼추 극복했다. 메모리 모델이니, far near 포인터니 뭐니 하면서 일이 굉장히 복잡해지긴 했지만 말이다.
또한, 멀티태스킹 환경에 대비해서 재배치 정보도 도입했다. 이제 좀 운영체제에서 파일을 있는 그대로 메모리에 올리는 게 아니라 최소한의 가공과 상대 주소 보정을 하는 loader가 필요해졌다.

오늘날 모든 EXE들은 앞부분에 MZ라는 문자로 시작하는 간단한 헤더를 갖추고 있다. MZ는 EXE 파일 포맷의 설계자인 당시 마소의 프로그래머 Mark Zbikowski의 이니셜이다! zip 압축 파일의 식별자인 PK (개발자 필립 카츠)만큼이나 세계에서 제일 유명한 파일 포맷 식별자 이니셜일 것이다. MZ 저분은 미국 토박이라고 하지만, 이름으로 보아하니 러시아 계열 이민자의 후손인 듯하다.

비록 도스는 역사 속으로 사라졌지만, Windows용 실행 파일들은 지금까지도 과거 호환을 위해서 앞부분에 최소한의 MZ EXE 헤더 껍데기는 넣어 놓는 게 관행이 돼 있다.
한편, 32비트 이후부터는 프로그램들이 옛날처럼 다시 단일 세그먼트 기반 flat 모델로 돌아갔다. 단지, 그 세그먼트의 이론적 최대 크기가 꼴랑 64KB이던 것이 4GB로 왕창 커졌을 뿐이다.

3. NE (new)

1985년에 발표된 Windows 1.0과 함께 등장한 포맷이다. 도스와는 다른 방식의 API 호출, exe와 dll의 구분, 표준화된 리소스와 버전 정보 데이터, 함수의 import와 export 내역처럼 도스용 exe에는 없던 추가적인 정보가 많이 필요해진 관계로 새로운 실행 파일 포맷을 또 제정한 것으로 보인다. 단, 맨 앞부분은 그냥 도스 EXE처럼 시작하고, 새로운 방식은 다른 오프셋에서부터 시작된다. 이는 NE 다음의 PE도 마찬가지이다.

사실, NE는 Windows뿐만 아니라 마소에서 1986년경에 잠시 만들다 말았던 일명 '멀티태스킹 MS-DOS 4.0'(일반적인 그 MS-DOS 4.0 말고)용 실행 파일 포맷으로도 쓰였다고 알려져 있다. 하지만 도스는 텍스트 기반 환경이지만 Windows는 GUI 환경이고, 16비트 Windows에는 딱히 콘솔(명령 프롬프트)이라는 서브시스템이 존재하지 않았다. 그러니 바이너리 수준에서의 파일 포맷만 일치할 뿐, 양 플랫폼의 실행 파일을 딴 데서 원활하게 실행할 수는 없었을 것이다.

Windows 1.x부터 3.x까지 16비트 시절에 실행 파일 포맷은 크게 바뀌지 않았다. 단, 2에서 3으로 넘어가던 시절에는 Windows에 386 확장 모드라는 게 도입되었기 때문에, 이 프로그램은 종전의 리얼(real) 모드뿐만 아니라 보호(protected) 모드에서도 잘 실행된다는 보증 플래그가 추가되었다. 평범한 Windows API만 쓴 프로그램이 여기에 큰 영향을 받지는 않았겠지만, 그래도 혹시나 해서 말이다.

1980년대 왕창 옛날에 만들어졌던 일부 Windows용 프로그램들은 95뿐만 아니라 3.x에서 실행해도 "구버전용임. 여기서도 일단 실행은 되지만 케바케이기 때문에 온전하고 정상적인 동작을 기대할 수 없음. 최신 버전을 구해서 쓰셈.." 이런 주의 메시지가 뜨는 게 있었는데, 바로 이 플래그가 없이 옛날 방식대로 빌드된 프로그램이어서 그렇다.
특히 대화상자가 캡션(제목 표시줄)이 없이 표시되는 프로그램을 보면 옛날 냄새가 풀풀 난다. 캡션은 popup 윈도우가 아닌 overlapped 윈도우의 전유물이던 시절이 있었기 때문이다.

NE 방식의 실행 파일에는 각종 코드와 데이터, 리소스들이 resident, non-resident, discardable 이런 식으로 속성 구분이 있었다. 컴퓨터에 메모리는 왕창 부족한데, CPU와 운영체제 차원에서의 가상 메모리 지원이 없고, 그 열악한 환경에서 멀티태스킹을 구현하려다 보니, 돌아가는 방식이 가난함과 처절함 그 자체였다.
읽어들인 데이터는 언제든지 주소가 재배치되거나(단편화를 막고 연속된 많은 영역의 메모리를 확보할 수 있게), 삭제되어서 디스크로 되돌아갈 수 있었다. 반드시 메모리에 언제나 불러들여 놓는 데이터는 성능 차원에서 정말 중요한 것에만 한해서 지정해야 했다.

4. PE (portable)

1993년에 등장한 Windows NT 3.1에서 첫 도입된 또 다른 새로운 실행 파일이다. AT&T에서 오래 전에 개발한 COFF라는 오브젝트/라이브러리 파일 포맷의 연장선상에 있다. 아마 Windows NT 개발진의 출신 배경이 그쪽 계열 연구소여서 이런 포맷에 친숙하지 않았나 싶다. 덕분에 마소에서 개발하는 개발툴들은 16비트 시절에는 obj/lib의 포맷으로 인텔에서 개발한 OMF 방식을 썼지만 32비트부터 COFF로 갈아탔다. 그리고 exe/dll을 로딩하는 방식도 쿨하게 memory mapped file 방식으로 바꿨다.

PE는 현대적인 32비트 가상 메모리 환경에 맞춰졌기 때문에, 16비트 NE처럼 수동 메모리 관리를 염두에 둔 지저분한 속성이 존재하지 않는다. 세그먼트 대신에 코드, 데이터, 리소스 등의 용도별 섹션이 있고, 이들 섹션은 간단한 문자열 태그로 구분하기 때문에 섹션의 추후 확장이 가능하다. 그리고 헤더에 CPU 식별자도 넣어서 굳이 x86뿐만 아니라 다른 CPU 아키텍처의 실행 파일도 이 방식으로 기술 가능하게 했다.

훗날 64비트 CPU가 등장하면서, 아니 정확히는 1990년대 말에 IA64의 출시를 염두에 두고 PE의 기본 틀은 동일한데 메모리 주소나 몇몇 size 필드만 4바이트에서 8바이트로 확장된 일명 PE+ 규격이 나왔다. 그래도 기존 32비트에서도 얘를 알아보고 최소한 "에러 메시지+실행 거부" 정도의 대처는 할 수 있다.
리소스는 64비트도 32비트와 바이너리 차원에서 포맷이 완전히 동일하다. 이게 무슨 기계어 코드도 아닌데 필드 크기가 굳이 64비트 크기로 확장됐다거나 한 건 없다. 문자열이 유니코드 기반으로 바뀌었으니 16비트 방식과는 호환되지 않지만 32와 64비트끼리는 호환된다.

오늘날은 재래식 네이티브 코드뿐만 아니라 닷넷 기반(가상 머신), 그리고 UWP용(일명 metro) 앱 같은 것도 나왔지만, 이들도 실행 파일들의 기본 골격은 PE로 동일하다. 그 안에서 읽어들이는 시스템 DLL과 구동 방식이 서로 차이가 날 뿐이다.

Posted by 사무엘

Windows에는 시스템 자신의 소프트웨어적인 유지 보수와 관련하여 (1) 업데이트와 (2) 시스템 복원이라는 두 기능을 제공한다. 전자는 프로그램을 최신 상태로 유지하는 기능으로, 개념적으로 미래로 나아가는 것에 대응한다. 후자는 그와 반대로 과거로 돌아가는 기능이다.

옛날에는 프로그램의 업데이트/패치라는 게 오프라인 상으로 동작하는 기능에 버그가 발견되어 고쳐졌거나, 아니면 작게나마 새로운 기능이 추가됐을 때 이를 반영하기 위해 시행되었다. 그러나 2000년대부터는 굳이 그런 게 아니라 '보안 취약점'을 수정하는 업데이트의 비중이 커졌다.

보안 취약점은 세상의 컴퓨터들이 인터넷에 한데 연결돼 있지 않거나 아주 제한된 시간 동안 잠시만 연결된다면 별로 심각한 문제가 아닐 것이다. 하지만 그렇지 않고 컴퓨터가 상시 네트워크에 연결되어 있으며 아무나 아무 컴퓨터로 패킷을 보낼 수 있고, 그 패킷이 해석하는 방식에 따라서 특정 지시를 수행하고 코드를 실행할 수 있기 때문에(편의라는 명목 하에) 보안 문제가 불거지는 것이다. 엑셀· 워드 문서가 그냥 데이터뿐만 아니라 매크로가 추가됨으로써 보안 위험이 커졌듯이 말이다.

이러면 최악의 경우 나도 모르는 사이에 악성 코드가 원격 조작으로 실행될 수 있으며, 내 컴퓨터에 있는 데이터와 내가 키보드로 입력하는 문자가 나의 동의 없이, 나도 모르는 사이에 내 컴퓨터 밖으로 새어 나갈 수 있다. 내 데이터가 날아가고 내 개인 정보가 유출될 수 있다. 내 컴퓨터가 주변의 컴퓨터로 악성 코드를 퍼뜨리는 좀비가 될지 모른다. 한 마디로 요약하면, 컴퓨터 시대에서 상상할 수 있는 모든 끔찍한 재앙이 벌어질 수 있다.

보안 업데이트는 프로그램의 그런 허점들을 막아 준다. 정적 분석 기술로 컴퓨터 프로그램이 취급하는 모든 데이터의 처리 양상을 원천적으로 분석해서 보안 취약점을 자동으로 찾아낼 수는 없다. 그러니 그때 그때 취약점이 발견되면 해당 소프트웨어의 제조사에서 패치와 업데이트를 내는 식으로 "사후 약방문" 식 대응이 어쩔 수 없이 통용된다.

소프트웨어는 굳이 새로운 기능을 추가하기 위해서가 아니라 지금의 현 상태를 안전하게 유지하기 위해서라도 계속해서 유지 보수를 해야 하고 업데이트를 해야 하는 반제품이 되었다. 첫 버전 출시를 한 것은 전반부 종료일 뿐이고, 그 다음부터가 후반부의 시작이다.

업데이트라는 게 평범한 기능 개선과 추가에 지나지 않는다면.. "난 그런 기능 없어도 지금 프로그램 쓰는 데 아무 불편 없어요" 이런 사용자는 굳이 업데이트를 받을 필요가 없다. 하지만 보안 업데이트는 마치 예방접종과 비슷한 구석이 있어서 내가 안 받으면 남에게 피해를 줄 수도 있다. 그렇기 때문에 모든 사용자들이 반드시 받을 필요가 있다. 일단은 말이다.

업데이트에 대한 얘기가 좀 길어졌는데, 다음으로 시스템 복원은 위급한 상황에서 굉장히 유용한 기능이다. 개발자의 입장에서 이런 기능은 구현하고 테스트· 디버깅 하는 게 굉장히 엄청나게 어려웠을 것이다.

본인의 경우 꽤 오래 전(거의 2009~2010년경.. Vista 시절), 언제부터인가 집 컴퓨터가 인쇄가 안 되기 시작했다.
프린터가 USB 포트 상으로 인식은 분명히 되고, 인쇄 명령을 내리면 프린터가 이를 받아서 예열 작업까지는 한다(레이저임).

그런데 그 후로 프린터는 아무 반응이 없이 인쇄가 전혀 진행되지 않으며, 도리어 인쇄를 내린 응용 프로그램만 응답 불능 상태에 빠진 채 멎어 버리는 것이었다.
멎은 프로그램은 CPU를 사용하지는 않으며, 다른 프로그램들은 정상 동작했다. 하지만 그 멎은 프로그램은 작업 관리자로 아무리 죽여도 사라지지 않았다.

하드웨어 문제라면 이거 프린터를 수리 받아야 하는데, 무슨 충격을 받은 것도 아니고 멀쩡한 프린터가 갑자기 고장 날 리가 없으니 무척 난감한 상황이었다.
만약 소프트웨어 문제라면 프린터 드라이버를 다시 설치하거나 최악의 경우 운영체제를 새로 설치해야 할 것이다. 최근에 부모님께서 내가 없는 동안 이 컴퓨터로 이것저것 ActiveX도 깔고 인쇄를 하긴 하셨는데 도대체 어쩌다가 프린터가 이렇게 됐는지 몰라 답답하기 그지없었다.

하지만 다행히 문제는 비교적 간단하게 해결할 수 있었다. 혹시나, 설마 해서 ‘시스템 복원’을 해 봤는데 이게 날 살렸다.
부모님께서 컴퓨터를 건드리기 전인, 약 1주일 전으로 복원을 시켰다. 그 사이에 컴퓨터에 생긴 변화는 운영체제 업데이트 몇 개가 자동으로 설치된 것 정도가 떠 있었다.

시스템 복원을 하고 나자 프린터는 거짓말처럼 인쇄가 되기 시작했다. 아까는 무엇 때문에 안 됐는지 모르겠지만, 어쨌든 시스템 복원 기능을 이용해서 만족스러운 결과를 잘 얻었다.
Vista보다 더 옛날, XP 시절에도 본인은 시스템 복원으로 여러 하드웨어/소프트웨어 문제를 딱 해결한 적이 있었다. 이런 기능이 없었으면 영락없이 운영체제를 재설치해야 했을 터이다. 물론 이제는 운영체제를 재설치할 일 자체가 거의 없어지다시피했지만 말이다.

이런 Windows 업데이트와 시스템 복원은 하는 일이 완전히 다르지만 그래도 서로 한데 맞물려서 돌아간다. 업데이트를 설치하는 것부터가 시스템 복원 지점을 만든 뒤 진행되기 때문이다.
이런 일이 있어서는 안 되겠지만, 업데이트를 설치한 뒤에 운영체제에 오히려 부작용이 발생할 수가 있다. 상태가 예전보다 나빠졌다면 시스템 복원을 실행해서 원상복구를 시킬 수 있다.

시스템 복원은 Windows 2000도 아니고 ME에서 첫 도입된 정말 얼마 안 되는 기능 중의 하나이다. 이 기능으로 인해 Windows는 평시에 차지하는 하드디스크 용량이 본격적으로 크게 늘어나기 시작했다.

본인은 가끔 갖고 놀 목적으로 Windows ME 가상 머신을 갖고 있다. 여차여차 하다 보니 하드의 파일 시스템을 FAT32가 아닌 FAT로 잡아 버려서, 주 파티션의 용량이 겨우 2GB가 됐다. 거기에다가 MS Office와 날개셋 정도만 설치하면 하드 용량을 딱 절반인 1GB 남짓 차지했는데..

그렇게 날개셋 한글 입력기를 테스트 하고 빌드 스냅샷을 설치하고 지우기를 반복했던 가상 머신은 나도 모르는 사이에 여유 공간이 갈수록 줄어들더니, 겨우 50~60MB 남짓밖에 안 남는 사태가 벌어졌다.
뜨악 하다가 정신을 차리고 시스템 복원 기능을 완전히 끄고 기존 스냅샷들을 모두 삭제한 뒤 재부팅을 하자.. 사라졌던 1GB 남짓한 공간이 다시 거짓말처럼 나타났다. 용량 쳐묵쳐묵의 범인은 시스템 복원 기능이었다.

얘는 마치 휴지통처럼 최대 몇백 MB까지만 공간을 사용하라고 옵션을 지정하는 게 분명히 있음에도 불구하고, 그걸 훨씬 더 초과하여 디스크를 잡아먹고 있었다. ME의 복원 기능만 그런 문제가 있었는지는 모르겠다.

오늘날의 Windows 10은 브랜드 이름과 주 버전은 이제 더 안 고치고, 찔끔찔끔 업데이트만으로 보안 패치와 서비스 팩, 버전업을 모두 겸하게끔 배포 방식을 바꿨다. 이제 날짜와 빌드 번호가 사실상 버전 번호가 된 셈이다.
그런데 시도 때도 없이 너무 자주 업데이트가 발생해서 CPU 잡아먹고, 시간이 흐를수록 하드디스크 용량 소모가 너무 심하며, 컴퓨터를 원하는 때에 제대로 끄지도 못하게 만드는 등 민폐가 너무 심하다.

게다가 업데이트 설치 후에 부팅이 안 되고 컴이 먹통이 되는 현상을 집과 회사에서 두 번씩이나 겪은 뒤부터 본인은 학을 떼 버렸다. 인터넷 연결망이 종량제 기반이니 니 멋대로 업데이트 받아서 설치하지도 말고 알리지도 말라고 레지스트리를 조작해서 넣었다.
Windows 10만 그런 게 아니라, 구닥다리 7을 굴리는 작업실 컴도.. 하는 일 없이 CPU 잡아먹으면서 열받고 팬을 돌아가게 만드는 주범이 update 서비스인 걸 보고는 이거 nProtect만 욕할 처지가 아니라는 걸 알게 됐다. 서비스 다 내리고 업데이트 따위 꺼 버렸다.

아무리 보안과 안전이 중요하다지만 나는 최소한의 보안 관념이 있고 내 컴퓨터 통제를 스스로 할 줄 알며, 대부분의 보안 결함은 여느 교통사고나 범죄 사건과 마찬가지로 정말 극단적이고 예외적인 막장 상황에서나 발생하는 것들이다. 위험이 너무 과장되고 부풀려진 면모가 있다. 그리고 이 정도의 횡포는 가성비를 따졌을 때 강제 업데이트를 justify하지 못한다는 결론을 내렸다.

컴퓨터 자원은 무한한 게 아니다. 아무쪼록 시스템의 안정성을 관리하는 기능들이 지금보다 자원을 좀 아껴 쓰고 민폐 안 끼치며 동작했으면 좋겠다는 생각이 들었다. 이상.

Posted by 사무엘