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

평소에 운전을 하면서 차의 내비가 아주 가끔 오동작으로 의심되는 안내를 하는 걸 보고, 본인은 업데이트의 필요성을 이따금씩 느끼곤 했다.

예를 들어, 마포 대교를 건넌 후 내비가 시킨 대로 강변북로의 동쪽 방면으로 정상적으로 진입하는데도, 내비는 이 무렵에 늘 경로를 벗어났다는 경고음을 내고 경로를 또 수정하곤 했다. 2009~2010년 사이에 그쪽 일대에서 지리 데이터가 바뀌어야 할 변화가 일어나기라도 했는지는 모르겠다.
그리고 작년 말이 돼서야 개통한 전철 경춘선도 내비에는 당연히 반영되어 있지 않았기 때문에, 이 또한 불편한 점이었다.

인터넷을 찾아보니 다행히 방법이 있었다. 어차피 보급품, 순정-_- 내비이니 내비의 제조사는 자동차 회사와 연계가 잘 되어 있었고, 간단한 회원 가입 후에 2011년 하반기 기준의 최신 내비 파일을 무료로 곧장 다운로드할 수 있었다. 그 용량은 2GB가 약간 넘는 수준. 내비 프로그램뿐만 아니라 우리나라의 지도가 여기에 전부 들어있는 셈이다.

이걸 내비에다 주입하는 매체는 USB 메모리 또는 DVD 중에서 선택할 수 있었다. 방대한 양의 데이터를 전송하면서 PC로 치면 운영체제를 업그레이드하여 재설치하는 거나 마찬가지이기 때문에, 안정성을 위해 DVD는 최저 속도로 구울 것을 권하고 있었고, USB 메모리는 더 견고한 금속 접촉식으로 된 것을 쓰는 게 권장되고 있었다.

그 후, 차에 들어가서 USB 메모리를 꽂은 뒤, 시스템 메뉴에 들어가서 업데이트 명령을 내렸다. 이런 작업을 하는 게 완전히 처음이었으니 중간에 오류라도 나면 어쩌나, 아예 내비가 부팅이 안 되고 먹통이 되면 어쩌나, 시간이 너무 오래 걸리지는 않으려나 걱정되기도 했다.

업데이트가 되고 있는 중에는 차 시동을 켜는 게 절대 불가능하다(당연히, 켜는 순간에 차에 전원 공급이 끊어지므로). 그러니 미리 시동을 걸어 놓고, 내비가 업데이트되는 동안 자연스럽게 밖에 나가서 주변 드라이브나 좀 하게 됐다. 이 경우, 내비의 기능을 전혀 쓸 수 없는 상태에서 운전을 하는 것이므로 과속 단속 카메라를 스스로 각별히 조심해서 눈여겨봐야 한다. 또한 시동을 꺼뜨리는 일도 없어야 한다는 제약이 걸린다.

시간은 한 3, 40분쯤 걸렸으려나? USB 메모리는 access 때문에 불빛이 격렬하게 깜빡거렸다. 게이지가 너무 오랫동안 안 올라가고 있는 듯이 보일 때는 불안하기도 했지만, 다행히 업데이트는 아무 문제 없이 잘 됐다.
내비는 드디어 경춘선과 신분당선 전철역의 위치까지 정확하게 뜨는 최신 버전으로 바뀌었다. 야호!

그리고 음성 안내를 하는 아가씨 목소리의 억양이 살짝 바뀌었다.
강변 북로 오동작이 해결되었는지는 나중에 그 구간을 몰 일이 있을 때에나 확인 가능할 것 같다.

이런 일련의 작업을 혼자서 할 여건이 안 되는 사람이라면, 서비스센터에 가서 요청만 하면 직원이 내비 업데이트도 해 준다고는 하더라. 그도 그럴 것이 내장형 순정품이니까 말이다. 단, 이 경우 인건비로 돈이 2만원 남짓 깨진다.

업데이트 파일이 담겨 있는 USB 메모리를 살펴보니, 인스톨 프로그램은 PE 파일이었고, 대상 플랫폼은 윈도우 CE이다. target CPU는 지금까지 듣도 보도 못한 ARM Thumb이라는 아키텍처. 보아하니 32비트 RISC 체계하에서도 16비트 데이터 버스를 쓰는 임베디드 기기에 맞게 코드를 더 compact시켜서, 메모리를 더욱 절약해 낸 아키텍처 같다. (☞ 더 자세한 설명 클릭)

한편, 1GB가 넘는 다른 지도 데이터는 내부 구조를 전혀 알 수 없는 압축(또는 암호화)된 파일 형태임.

독립된 기기로서 내비의 위상이 언제까지 유지될지는 잘 모르겠다.
스마트폰이 이미 어지간한 품질의 사진과 동영상은 즉석에서 만들어 내니 기존 디카들은 훨씬 더 전문적인 화질을 만들어 내는 영역으로 이동했다.
그것처럼 스마트폰이 길 안내와 내비 역할까지 다하다 보니, 요즘은 내비도 이에 맞서 뭔가 개인용 종합 정보 처리 시스템처럼 바뀌는 듯하다.

개인적으로 내비는 정말 다익스트라의 길 찾기 알고리즘의 결정체라고 생각한다. 직선 거리뿐만이 아니라 시내 도로 상황, 상하 구배, 유료 및 자동차 전용 도로 여부, 지금 자동차의 진행 방향 등 온갖 변수들이 그래프의 weight에 감안되지 않았을까? ㅋ

Posted by 사무엘

전산학 전공자 내지 IT 분야 종사자에게는 상식으로 통용되는 당연한 개념이다만..
오늘날 범용(generic-purpose) 컴퓨터에서 돌아가는 소프트웨어는 크게 세 가지 형태로 나뉜다.

1. 로컬

흔히들 PC로 대표되는 컴퓨터에서 stand-alone으로 동작하는 전통적인 프로그램이다. Windows야 그렇다 치더라도 오피스, 비주얼 스튜디오 같은 업무용 프로그램은 아직 로컬 프로그램의 아성을 무너뜨릴 영역이 없다.
가장 역사가 길고, 가장 빠르고 효율적으로 동작하며, 특정 컴퓨터 아키텍처(기계어)와 운영체제의 실행 파일 포맷에 종속적이다. 그래서 이쪽 개발 환경은 전통적으로 C/C++ 같은 저수준 최적화 언어가 강세이다.

물론 클라이언트가 아닌 서버 프로그램은 성격이 약간 다르긴 하나, 서버 프로그램 자체는 역시 서버라는 로컬 컴퓨터 자신의 자원만을 이용하여 동작한다. 여객 운송과 화물 수송의 차이와 비슷한 맥락이다. 그리고 사실은, 다음에 설명할 2.웹 프로그램을 돌려 주는 기반도, 클라이언트든 서버든 1.로컬 프로그램들이 다 마련해 주고 있다. 그러니 로컬 프로그램은 앞으로도 없어질 수는 없다. 단지 전체 소프트웨어에서 차지하는 비중이 줄어들 뿐이다.

옛날에는 불특정 개인 사용자를 대상으로 하는 상업용 제품은 패키지 형태로 발매되곤 했지만, 오늘날은 인터넷의 발달과 극심한 불법 복제로 인해 이런 전통적인 형태의 배포의 비중이 굉장히 줄어들었다. 오늘날 국산 패키지 소프트웨어는 아래아한글과 V3 말고 있나? -_-;; 또한 보안 위협으로 인해 이런 프로그램 역시 한번 설치하고 끝이 아니라 끊임없는 보안 패치와 업데이트의 필요성이 커져 있기도 하다.

2. 웹

개인용 컴퓨터의 성능이 굉장히 향상되고 그에 따라 웹 표준이 발달하면서 웹브라우저, 정확히 말해 WWW는 단순히 그림과 하이퍼링크가 동원된 문서라기보다는 거의 프로그래밍 플랫폼처럼 오래 전부터 바뀌었다.

웹 프로그래밍의 최대 매력은 로컬을 월등히 능가하는 범용성과 기계 독립성, 생산성이다. 브라우저에서 사이트 접속만 하면 바로 실행..;; 마치 게임처럼, 클라이언트와 서버, 코딩과 디자인 등을 두루 아우르는 종합 예술처럼 보이기도 한다. 가령, 옛날에는 GWBASIC이나 LOGO로 어린 학생들에게 그래픽 프로그래밍 교육을 시켰다면, 지금은 그냥 HTML5만 써도 될 것이다.

물론, 로컬 개발에 비해서는 혼자 독립적인 작품을 만든다는 느낌이 좀 덜 들며-_-, 기술이 아직까지 안정화해있지 않은 면모가 있고, 로컬 컴퓨터 자체를 세밀하게 제어할 수 없으며 성능이 떨어진다는 한계도 있다. 가령, 오피스 제품군이 웹 애플리케이션으로 완전히 대체될 날은 과연 글쎄?
그러나 앞으로 웹 프로그래밍의 비중은 절대 무시 못 할 것이고 수요도 없어지지 않을 것이다.

3. 앱

스마트폰에서 동작하는 '로컬' 프로그램이라고 볼 수 있지만, 그 성격이 역시 1과는 사뭇 다르다.
스마트폰 자체는 PC보다 성능이 떨어지기 때문에, 로컬에서 모든 처리를 마친다기보다는 서버에다 input을 보내서 받은 output을 보여주는 형태의 앱이 많다. 또한 스마트폰은 화면이 작고 PC 같은 빠른 문자 입력을 할 수 없기 때문에, PC와는 다른 독자적인 GUI가 필요하다. 터치스크린은 마우스와 완전히 동일한 포인팅 UI가 아니다. (대표적으로 hovering이란 게 없다) 다만, PC에는 없는 기울임, 흔들림, 방향, 현재 위치 같은 특수한 입력을 받아들일 수 있다.

스마트폰은 PC만치 사용자가 컴퓨터 내부를 완전히 손쉽게 제어할 수 있는 물건은 아니다. 그래서 PC용 프로그램보다는 더 엄격한 과금 체계를 갖추고 프로그램을 배포하여 수익을 낼 수 있다.
스마트폰 앱은 역사가 짧기 때문에 PC 같은 지저분한 호환성 잔재 같은 게 덜하고, 일찍부터 자바든 C#이든 객체지향 언어와 가상 기계 바이트코드 기반의 프로그래밍 환경이 잘 구축돼 있다. 깔끔한 최신 프로그래밍 인프라가 기본으로 제공된다는 뜻이다.

오늘날 스마트폰 CPU는 ARM 아키텍처밖에 없지만, 그래도 커널 말고 다른 응용 프로그램들은 네이티브 코드가 아니다. 그런 .NET이나 자바 같은 가상 기계 자체가, 1~3(로컬, 웹, 앱) 사이의 이질감을 낮추고자 만들어진 것이기도 하고 말이다.
아울러, CPU의 성능이 좋아졌을 뿐만 아니라 LCD 디스플레이 소자가 보편화하고 통신 기술이 발달하면서 스마트폰 같은 물건도 대중화될 수 있었다.

20세기 중반까지만 해도 컴퓨터는 곧 메인프레임-단말기 모델이었다.
컴퓨터라는 게 무진장 비싼 물건이고 자원이 귀하다 보니, 모든 처리는 중앙 컴퓨터에다 맡기고 각 사용자는 단말기로 서버에 접속해서 명령 프롬프트에서 서버의 기능을 사용하곤 했다. 그때는 컴퓨터는 대학, 연구소, 정부 기관, 군대의 전유물이었고, 개인용 컴퓨터라는 개념을 감히 떠올리기조차 쉽지 않았었다. (알파넷이 미국이 아닌 소련에서 발명되었다고 생각해 보자. 그게 오늘날의 인터넷으로 발전할 수 있었을까? -_-)

그러다가 20세기 말에는 PC가 대세가 되었다. 개인용 컴퓨터 하나만으로 어지간한 일은 다 할 수 있게 되었다. 비유하자면, 만원버스에 시달리면서 출퇴근하다가 번듯한 자가용이 생긴 셈.
PC의 사고방식으로는 소위 PC 통신은 어쩌다 한 번씩만 다른 컴퓨터에 접속하는 특별한 작업이며, 웹브라우저 역시 오피스 패키지처럼 별도로 구입해서 사용하는 특수한 프로그램일 뿐이다.

그 후 오늘날 대세라고 회자되고 있는 건 일명 클라우드 컴퓨팅이다. 개인용 컴퓨터가 무진장 작아지고 통신 인프라가 발달한 덕분에, 예전처럼 부족한 자원을 공유하려고 컴퓨터들을 연결하는 게 아니라 진짜 유비쿼터스 세상이 돼서 컴퓨터들을 연결한다. PC 통신 시절에만 해도 하이텔 단말기가 있었는데 오늘날의 스마트폰에 비하면 얼마나 격세지감인가!

전세계 컴퓨터가 다 인터넷에 연결되고 클라이언트와 서버의 구분이 무의미해지고, 궁극적으로는 (거의) 모든 작업이 웹 프로그램만으로 해결되고 모든 자료가 웹에 저장되는 세상이 온다. 예전에는 PC끼리 자료 전송을 위해서 플로피 디스켓이나 USB 메모리를 썼는데, 이제는 사용자의 로컬 컴퓨터나 스마트폰 그 자체가 플로피 디스켓이나 USB 메모리와 마찬가지가 된다는 뜻.

이걸 역시 자동차에다 비유하자면 이렇다. 사람이 직접 자가운전을 하니까 교통사고가 발생하고 도로가 막히고 여러 문제가 생기다 보니, 전세계 도로가 한데 통제되고 지능형 임대 자가용이나 궤도 교통수단이 생겨서 모든 사람들이 그걸 간단히 이용하는 형태가 된 셈이다.
물론 이게 온전히 실현되려면 시스템적으로나, 보안 쪽으로나 해결해야 할 문제가 많다.

Posted by 사무엘

본인의 고향집에 있는 부모님께서 사용하시는 PC는 내가 쓰는 PC보다야 훨씬 더 구닥다리 기종이다.
몇 년 전까지만 해도 펜티엄 3에 램은 192MB인 윈도우 2000/ME급 사양이었다. 완전 골동품..;;

그런데 컴퓨터에 이상이 생겨서 서비스를 받고 났더니, 도대체 누구에게서 서비스를 받았는지는 모르겠지만 저 컴퓨터에 윈도우 XP가 깔려 있었다.;;
잘 알다시피 XP는 못해도 램이 256MB 정도는 돼야 쓸 수 있는 덩치이지 않은가. 부팅에서부터 간단한 인터넷 확인을 하기까지 걸리는 시간이 본인의 인내심의 한계를 느끼게 했다.

결국 본인은 내가 대학 학부 시절에 쓰던 펜티엄 4 + 램 512MB짜리 컴으로 PC를 교체해 드렸다. 부모님이야 진짜로 간단한 인터넷 접속 + 워드 작업밖에 안 하시기 때문에 기계가 물리적인 고장만 안 난다면 이 컴을 앞으로 10년-_-은 더 쓰실 법도 해 보였다. 한때 내가 개인 작업용으로도 쓰던 컴이었으니, 인계 당시 최적화는 잘 되어 있었고 윈도우 XP의 체감 속도는 씽씽 날아다니는 수준이었다.

그러나 행복은 오래 가지 못했다.
언제부터인가 고향에 가서 확인해 보니, 악성 코드가 덕지덕지 달라붙어서 컴의 성능을 다 깎아먹고 있었다.
부팅 직후에 시작 메뉴를 열어서 웹브라우저를 띄울 때 운영체제가 굼뜨는 모습이 꼭 옛날의 램 192MB짜리 컴을 쓰던 것과 비슷했다. 램이 그보다 두 배 이상 더 많은 컴에서 말이다.;;

시스템 정보 → '로드된 모듈'을 보면 정체 불명의 이상한 dll이 explorer.exe 내지 iexplore.exe에 달라붙어 있었고, 파일을 지우고 레지스트리를 아무리 정리해도 이런 파일은 재부팅 후에 잡초처럼 계속 생겨나곤 했다.
USB 포트로 메모리 스틱이나 외장 하드를 이 컴에다가 꽂았다가 빼서 확인해 보면, 역시나 루트 디렉터리에 이상한 exe와 autorun.inf가 생겨 있었다.

나는 이런 부류의 악성 코드들이 운영체제에 어떤 방식으로 기생하는지, 어떻게 전염되는지 기술적 디테일을 전혀 알지 못한다.
내 컴퓨터에 지금까지 그런 것들이 침입한 적이 없으며, 내가 스스로 대처한 경험이 없다. 난 내 컴에 백신도 전혀 안 깔고 지낸다.

저런 악성코드를 완전히 뿌리뽑는 방법을 모르기 때문에, 본인은 집 컴의 C:를 그냥 밀어 버리고 운영체제를 다시 설치했다. 사실, 컴퓨터의 상태가 굉장히 안 좋기도 했다.
마침 내가 대학 시절에 만들어 놨던 윈도우 XP sp0(-_-) 원본 씨디가 있어서 그걸 썼다.
XP sp2 통합 씨디 이미지를 갖고 있긴 하지만, 또 씨디 굽기가 귀찮아서..;;
허나 그것이 본인에겐 고난의 시작이었다..;;

운영체제 자체의 설치는 40분 남짓한 시간 만에 별 탈 없이 됐다.
그래픽 카드는 nVidia GeForce의 완전 구닥다리 초창기 모델이어서 그런지, 별도의 드라이버를 설치할 필요조차 없이 운영체제가 알아서 잡아 줬다.
원래 그래픽 카드가 잡혀 있지 않으면 그냥 800*600 슈퍼 VGA의 제일 기본 VBE 모드만 가능하다. 그것보다는 약간 나아진 셈이다.

그리고, XP 이전 2000 이하의 OS는 그래픽 카드 드라이버를 설정 안 하거나 안전 모드로 부팅한다거나 하면, 아예 640*480 16컬러 VGA밖에 지원되지 않았으니 그 시절은 참 어지간히도 암울했었다. 단, 덧붙이자면, 9x 계열과는 달리 2000은 원시적인 16컬러 VGA에서도 화면이 바뀌는 곳에서 마우스 포인터가 깜빡거리는 현상이 없던지라, 얘는 하드웨어 제어를 어떻게 하는지 본인은 개인적으로 궁금증이 들곤 했다. 이것이 NT 커널의 위력인가..?

악성 코드 없이 광속으로 반응하는 청정 OS를 써 보는 기쁨도 잠시. 새 OS는 인터넷이 되지 않았다. 20세기의 유물로 전락한 전화 걸기 대화상자가 뜨는 걸 보고 경악했다.
어라? 네트워크가 전혀 설정되어 있지 않았고, 장치 관리자에 가 보니 이더넷 컨트롤러의 드라이버가 정체 불명이라고 찍혀 있었다.

본인의 컴퓨터 하드웨어 지식은 “요즘은 랜 카드나 사운드 카드는 다 마더보드 내장인데 OS가 알아서 다 잡아 주지 않나?” 정도에 머물러 있었다. 그래서 생각한 두 가지 카드는 다음과 같았다.

1. 2001년에 나온 구닥다리 SP0이어서 못 잡는 것이 아닐까? SP2를 따로 설치하면 아마 자동으로 잡힐 것이다. (잘 알다시피 윈도우 XP SP3은 SP1 이상을 요구하며, SP0에서 바로 설치 못 함)
2. 아니면, 이 컴퓨터의 랜 카드의 메이커가 뭔지는 모르겠지만 Realtek 브랜드의 드라이버 아무거나 설치해 주면 될 것이다.

사실, 최신 운영체제는 무엇보다도 최신 하드웨어의 지원 능력면에서 구버전보다 우월하다. 이 점에서는 심지어 과거의 윈도우 ME도 98 SE보다 훨씬 더 낫다. 98만 해도 드라이버를 따로 설치 안 하면 USB 메모리조차 인식을 못 하기 때문이다.

그래서 250여 MB에 달하는 SP2 설치 파일을 다른 곳에서 애써 복사해 오고, 내가 아는 랜 카드 드라이버를 몇 개 구해서 설치해 봤다. 하지만 두 시도 모두 실-_-패로 끝났다. 특히 SP2는 이 운영체제가 어둠의 경로-_-로 설치된 거라는 걸 알기라도 했는지 제품 시리얼 번호를 갖고 트집을 걸면서 더 진행을 거부하였다.

이런 와중에 새 OS는 설치된 지 불과 몇십 분 만에 또 악성 코드에 감염됨으로써 나에게 충격과 공포를 안겼다. 인터넷이 아예 안 되는 컴퓨터가 어떻게 그렇게 될 수 있는가...????

범인은 아까 그 프로그램들을 복사· 설치하기 위해 꽂은 어머니의 USB 메모리였다. 그 메모리는 이미 예전 컴퓨터로부터 악성 코드가 묻을 대로 묻어 있었을 것이고, 가만히 생각해 보니 USB 메모리의 autorun을 실행하지 않게 하는 윈도우 보안 패치는 생각보다 한참 뒤에 발표되었다. 그리고 이 컴퓨터의 OS는 업데이트 하나 없는 XP sp0으로, 온갖 보안 결함에 무방비로 노출되어 있는 호구이지 않던가. 이런 우라질레이션..;; -_-;;

도대체 CD롬도 아니고, 디스켓이나 다름없는 USB 메모리를 꽂기만 하면 자동으로 autorun이 돌아가게 해 놓은 친구는 무슨 생각으로 그런 기능을 넣었는지 모르겠다.. 키보드 입력을 버퍼 크기 제한도 없이 받아들이는 C언어의 gets 함수만큼이나 보안 면에서 멍청하고 위험한 디자인이 아닌가?

그런 주제에 윈도우 XP의 설치 프로그램은 설치 도중에 자기 운영체제와 웹브라우저에 대해서 '가장 강력하고 보안이 뛰어나다'고 자화자찬을 늘어놓고 있으니 그 어이없음에 웃음이 나올 뿐이었다. 뭐, 10년 전에 그랬다는 소리니까 봐 주자.;; 9x 계열이 갖고 있던 자유도와 유닉스 계열의 엄격함과 탄탄함(robustness)은 동시에 충족될 수 없는 이율배반적인 이념이니까 말이다.

이미 시스템 정보에는 악성 코드 DLL이 올라가 있었고, 레지스트리에서는 역시 정체 불명의 실행 파일이 시작 프로그램으로 등록되어 있었다. 탐색기에서 드라이브를 열 때의 동작 방식도 이상하게 바뀌었다.
악성 코드를 없애려고 운영체제를 재설치했는데 일이 꼬여서 이렇게 되었고 랜 카드도 전혀 잡히지 않았으니, 본인은 난감하지 않을 수 없었다.

결국, SP2가 적용된 윈도우 XP 원본 씨디를 또 만들었다. 귀찮아서 안 하려 한 짓을 결국은 하게 됐다. 그리고 그걸로 XP SP0을 밀고 윈도우를 또 새로 설치했다. 그래서 악성 코드는 노아의 홍수와 같은 심판으로 또 없애 버렸지만, SP2로도 랜 카드는 여전히 잡히지 않았다.

참다못해, 이놈의 랜 카드의 정체가 뭔지 파악하기 위해 컴퓨터의 케이스를 개방해야 했다. 랜 카드는 ASUS 마더보드 내장형이었는데, 모델명별로 자기만의 랜 카드 드라이버가 따로 있는 모양이었다.
장치 관리자에서 드라이버를 이걸로 업데이트하자 드디어 네트워크 설정이 잡히고 인터넷이 되기 시작했다. 휴우... 이런 경험은 난생 처음이었다.

인터넷이 되니 이제 큰 불은 껐다. 다른 소프트웨어를 설치하기 위해 가상 CD 구동 프로그램을 설치하고, 그리고 구닥다리 IE6을 당장 IE8로 교체했다. 세상에 컴퓨터 역사상 굴지의 IT 기업들이 앞장서서 “고객님, 제발 이 버전 쓰지 말고 업그레이드 하세요!”라고 하소연을 하고, 너무 오래 살아남아서 죽지 못해 사는 좀비처럼 된 소프트웨어가 IE6 말고 또 있을까?

비주얼 C++ 6도 너무 오래 살아 있는 소프트웨어이긴 하지만, 일단 이건 불특정 다수가 쓰는 프로그램은 아니고. 그런데 요즘은 어느샌가 IE 7마저도 이제 지원 안 할 거니까 업글하라고 눈칫밥을 주는 웹사이트가 하나 둘씩 생기고 있다.

IE 7이나 8을 XP에서 첫 설치하려면 무슨 IME의 동작과 관련된 운영체제 패치부터 먼저 설치해야 한다는 걸 처음 알았다. IE는 잘 알다시피 문자 입력과 관련된 괴이한 현상이 심심찮게 존재하는데, 역시 서로 민감한 부위를 건드리긴 하는가 보다.
플래시 메모리에 묻어 있는 악성 코드도 못 걸러내는 주제에, 웹브라우저가 자동 다운로드 기능을 차단하는 건 본인은 개인적으로 굉장히 불편했고 헛다리 짚는 듯한 느낌이었다. 필요한 팝업창을 차단해서 불편한 것보다 더 불편했다.

이런 식으로 컴퓨터를 대강 세팅했다. 고향에서 맨날 밥만 얻어먹고 가는 게 아니라 이번엔 고향집 컴퓨터를 깔끔하게 정리하고, 아버지 차에다가 내 돈으로 기름도 몰래 채워 넣는 등, 이쁜 짓(?)도 좀 하고 왔다. ^^;;
허나, 내년 설날에 고향에 가 보면 또 컴퓨터에 악성 코드가 덕지덕지 묻어 있을 것 같다. -_-;;; 혹시 부모님 직장의 컴들은 이미 다 오염돼 있지는 않나 모르겠다. 여쭤 보니 운영체제도 비스타/7이 아니라 XP라던데.. 더욱 걱정된다.

글을 맺으며..;;

1. 이번 일을 계기로, 보안 패치 없는 윈도우 XP는 정말 쓰레기라는 걸 체험했으며, 컴퓨터 환경에 따라서는 랜 카드도 저렇게 잡아 줘야 한다는 걸 알게 됐다.

2. 옛날에 윈도우 9x는 설치 GUI가 아예 윈도우 3.x 엔진 기반이었다. 그리고 9x만의 특징인데, 오래 쓰다 보면 가끔 메뉴의 ▶ 모양이라든가 윈도우의 버튼들이 숫자· 문자로 바뀌는 기괴한 버그가 나타나곤 했다. 아무리 옛날에 PC 환경이 열악했다고 해도, 그런 허접하고 불안한 운영체제를 어떻게 몇 년간 썼는지 놀랍기 그지없다.

3. 악성 코드는 정말 구제역 같은 느낌이 든다. 컴퓨터 보안 쪽으로 더 알고 싶다.

4. 윈도우 비스타가 깔린 본인의 컴은 데스크톱과 노트북 모두 3~4년째 OS의 재설치 없이 악성 코드 청정 지대이며, 이상 무이다.

Posted by 사무엘

아래 코드를 실행하면 놀랍게도..
입력된 숫자에 대한 팩토리얼 값이 출력된다. 단, 플랫폼은 x86 한정으로..;;
(뭐, 컴퓨터가 돌아가는 원리를 아는 사람이라거나 맨날 기계어 코드 들여다보는 게 직업인 사람이라면 전혀 새삼스러운 일이 아니겠지만)

비주얼 C++뿐만이 아니라 도스용 DJGPP로도 프로그램이 잘 동작하는 걸 확인했다. 둘 다 IA32 아키텍처인 건 동일하니까 이는 당연한 귀결.

int main(int argc, char* argv[])
{
 BYTE instrs[]={
  0x55,
  0x8B,0xEC,
  0x83,0xEC,0x08,
  0xC7,0x45,0xFC,0x01,0x00,0x00,0x00,
  0x8B,0x45,0xFC,
  0x89,0x45,0xF8,
  0xEB,0x09,
  0x8B,0x4D,0xF8,
  0x83,0xC1,0x01,
  0x89,0x4D,0xF8,
  0x8B,0x55,0xF8,
  0x3B,0x55,0x08,
  0x7F,0x0C,
  0x8B,0x45,0xFC,
  0x0F,0xAF,0x45,0xF8,
  0x89,0x45,0xFC,
  0xEB,0xE3,
  0x8B,0x45,0xFC,
  0x8B,0xE5,
  0x5D,
  0xC3
 };

 PVOID pv = instrs;
 int (*pfn)(int) = reinterpret_cast<int (*)(int)>(pv), y;
 while(1) {
  printf("? "); scanf("%d", &y); if(y<1) break;
  printf("%d\n", pfn(y));
 }
 return 0;
}

프로그래밍 언어의 인터프리터 내지 just-in-time 컴파일러를 만든다거나,
가상 기계 에뮬레이터를 만드는 것은 어렵지 않다.
결국 핵심이 뭐냐 하면 컴퓨터가 직통으로 실행하는 코드 자체를 실행 시간에 메모리에다 생성하는 건데,
함수 포인터가 가리키고 있는 게 바로 저런 것들이다.

물론, 위에서처럼 실행해야 할 코드가 완전히 고정돼 있는 경우라면
소스 코드에다 인라인 어셈블리를 집어넣으면 되겠지만, 그 코드는 데이터 영역에 들어가는 게 아니라 소스 코드(text) 영역에 그대로 포함되어 버리게 될 것이다.

위의 팩토리얼 함수는 물론 컴파일러가 생성해 준 코드를 복사한 것이다.
최적화를 안 한지라, 간단한 for 루프 하나밖에 없는 함수가 코드 길이가 꽤 길다.
최적화를 하고 나면 정상적인 함수 입출력 껍데기에 해당하는 코드조차도 거추장스러운지 생성되지 않아서
그걸 저렇게 따로 떼어내서 쓸 수가 없었다.

Posted by 사무엘

본인은 윈도우 플랫폼용 한글 입력기의 개발자이다. 그런데 진짜 옛날 도스 시절, 텍스트 모드가 따로 있던 시절에 한글 입출력 바이오스 같은 건 어떻게 구현했는지가 무진장 궁금해질 때가 있다.
출력은 그렇다 치더라도 입력은 어떻게 구현했을까? 게다가 한글도 모자라서 한자 입력은?
그리고 한글 정도면 양반이지 도스 시절에 일본은 사정이 어땠을까? 한자 변환까지 포함한 일본어 입력이 가능했을까? -_-;;

IBM 호환 PC는 그렇게 그래픽에 최적화돼 있지도 않던 놈이었고.. 영어 아스키 코드밖에 모르는 이런 기계에다가 없는 문자를 찍기 위해서는 막대한 양의 오버헤드가 필요했다.

요즘은 잘 알다시피 사운드 카드, 랜 카드 따위는 마더보드에 통합되어 버린 지가 오래이고 GPU, PPU 같은 거나 별도로 부착하는 CPU 애드온이다. (그리고 이마저도 요즘은 본격 통합 기세-_-)
허나 한 25~30년 전에는 한글 카드라는 별도의 하드웨어가 있을 정도였다. '한글 도깨비'. 그때는 그만큼 컴퓨터의 성능이 열악했다.

한글 입출력 바이오스를 만들려면, 일단 바이오스의 글꼴을 다른 걸로 대체할 수 있을 정도로 하드웨어에 정통해야 했고 메모리 사용량이든 계산량이든 극도의 최적화 작업이 필수였다. 한글 모드에서는 텍스트의 스크롤 속도가 한 2, 30% 정도 감소하는 효과가 있었기 때문. -_-;; 더구나 기본 메모리 640KB는 그야말로 1K라도 아껴야 하는 귀중한 영역이기 때문에, 한자 글꼴 같은 건 XMS/EMS 같은 확장 메모리에다 저장하는 테크닉도 필수였다.

VGA의 기본 텍스트 모드는 잘 알다시피 가로 80글자, 세로 25글자이다. 그런데 아주 신기하게도 한 글자의 크기는 너무나 컴퓨터스럽게 잘 떨어지는 8*16이 아니라, 9*16이다. 그리고 화면 해상도는 640*400도, 640*480도 아니요 720*400이다. 정작 mode 12H 같은 그래픽 모드 중에는 640을 넘는 해상도가 없던 시절이었는데 왜 텍스트 모드만 한 글자의 폭이 8이 아닌 9였는지는 모르겠다.
한글 바이오스들은 16*16 크기의 한글· 한자 글꼴을 사용했으며 640*400 해상도의 텍스트 모드에서 동작했다.

그뿐만이 아니다. 그때 VGA 텍스트 모드에는 화면 전체의 테두리 색이라는 게 있었다! 베이직에서 COLOR문은 보통 글자색과 배경색을 의미하는 A,B만이 쓰이는데, 셋째 인자도 있어서 이걸 지정하면 화면의 테두리에도 색깔을 줄 수 있었다. 이런 기능을 누가 썼고 왜 만들었는지는 모르겠지만...
이건 DosBOX나 VMware 같은 에뮬레이터들도 지원 안 하고 있는 기능이다.
그 테두리가 차지하는 픽셀 수는 얼마나 됐을까? 이것까지 감안한 화면 해상도는 얼마였을지를 생각하면 옛날에 비디오와 관련된 하드웨어 제어는 심오함 그 자체였겠다는 생각이 든다.

텍스트 모드의 바이오스 글꼴을 다루는 테크닉을 구사한 프로그램은 흔치 않았다. 도스용 노턴 유틸리티(Norton Utility)는 이걸 환상적으로 조작해서 텍스트 모드에서 준 GUI 수준의 비주얼을 만들고 심지어 그래픽 모양의 마우스 포인터까지 구현하는 용자짓을 했다. 그리고 Screen Thief라는 캡처 프로그램은 당시로서는 흔치 않게 텍스트 모드를 색깔과 바이오스 글꼴까지 감안한 실제 그래픽 화면 픽셀 그대로 캡처하는 기능이 있었다.
뭐, 한글 바이오스가 구동된 상태에서 노턴 유틸리티 같은 프로그램을 GUI 모드로 동시에 실행했다간 '영 좋지 않은 곳에 하드웨어 접근이 일어나서' 대략 불상사가 발생했겠지만 말이다. "내 컴이 다운이라니!!"

그때는 마우스의 존재 여부를 알아오는 테크닉만큼이나 한글 바이오스의 존재 여부를 알아오는 테크닉도 있었고
이는 텍스트 모드에서 실행되는 프로그램이 선문자를 깨지지 않고 맞게 출력하기 위해서 필수였다. 도스용 V3이나 MDIR 같은 프로그램들 말이다.
그러고 보니 한글 모드에서는 아스키 번호 1~31번 제어 문자도 원래 얼굴 모양 등 각종 도형이던 게, 1바이트 선문자로 바뀌었던 것 같다.

당연한 말이지만, 한글 바이오스는 바이오스의 글자 크기가 8*16이기만 하면, 텍스트가 아닌 그래픽 모드에서도 물론 동작했다.
하지만 그래픽 모드에서까지 텍스트를 찍는 프로그램은 전혀에 가깝게 없을 테니 이건 그리 의미는 없는 기능이었다.
그래픽 모드에서 동작하던 프로그램이 crash가 발생하는 바람에 그 상태 그대로 도스로 빠져나가서 도스 프롬프트가 찍힌 게 아닌 이상 말이다.
텍스트 모드에서는 cursor가 아주 빠르게 깜빡거렸지만 그래픽 모드에서는 cursor가 깜빡이지 않는다는 중요한 차이가 있었다.

그럼, 말이 나온 김에 옛날에 접했던 도스용 한글 바이오스들을 추억 차원에서 몇 개 예나 좀 들어 보자.

1. 본인이 난생 처음으로 접했던 IBM 호환 PC는 대우 전자에 개발한 286 AT였는데, config.sys의 DEVICE 문을 통해 구동하는 자체(대우에서) 개발 소프트웨어 기반 한글 바이오스가 들어있었다. 즉, 일단 load된 후엔 메모리에서 제거하는 방법이 없어서 불편했다. (그 당시 sys 파일은 com 실행 파일과 기술적으로 비슷한 구조가 아니었겠나 싶다.)
Alt+한영을 누르면 한글 바이오스 메뉴가 떠서 영문 전용/조합형/완성형 같은 모드를 바꿀 수 있었고, Alt+한자를 누르면 일시적으로 영문 전용 모드로 전환할 수 있었다.
대우 전자에서 개발한 만큼, 조합형과 완성형뿐만이 아니라 당시 악명 높던 DH 완성형도 지원했는데, 얘는 알파벳 소문자+대문자를 묶어서 한글을 표현하는 경우도 있었던 걸로 기억한다. 물론 한글 코드의 표준화가 일단락되면서 깔끔하게 묻혀서 역사 속으로 사라졌지만.

텍스트 + 한글 모드일 때는 화면의 맨 아래에 자그마하게 현재 한글/영문 모드인지, 완성형인지 조합형인지 같은 상태가 파란 배경의 줄에다 떴다. (그래픽 모드일 때는 그런 거 없음) 텍스트 모드에서 그런 걸 어떻게 구현했는지 지금 생각하면 정말 신기하기 그지없다.
물론 아까 말했던 VGA 테두리도 그보다 더 아래에 표시되었다.

한글을 입력하다가 bksp를 누르면 그냥 바이트 단위로 지워졌다. 즉, '한'을 입력하다가 bksp를 누르면 '하'가 되는 게 아니라 그대로 조합이 끝나면서 KS 완성형 기준 '한'을 구성하는 %C7%D1 중 %C7만 남아서 깨진 문자가 보였다.
우연히 한글 초성만 입력해 놓고 한자 키를 누르니까 지금까지 듣도 보도 못한 온갖 특수문자들이 펼쳐져서 이것도 신비로움 그 자체였다.

2. 한글 MS-DOS를 판매한 MS도 응당 자체 한글 바이오스를 갖추고 있었다.
그런데 지금까지 생각해도 참 대단한 건, MS에서 만든 한글 제품은 텍스트 모드에서도 깨진 문자를 보여주는 법이 없었다.
조합 중인 문자든 조합이 끝난 문자든, 한글은 알아서 자동으로 2바이트씩 한꺼번에 지워졌다. 조합 중인 글자를 조합의 역순으로 차곡차곡 '한' -> '하' 식으로 지워 주기에는 도스 환경이 너무 열악했고, MS가 개발한 한글 바이오스는 그냥 한글을 한꺼번에 지웠다.

GWBASIC, QBASIC 같은 프로그램은 한글판이 따로 있었는데, 한글 바이오스를 구동하지 않고 한글판 프로그램을 실행하면 글자만 깨지는 게 아니라 그대로 컴퓨터가 다운됐었다!
그러나 텍스트 모드에서 GUI를 구현한 한글판 프로그램들을 잘 살펴보면, 메뉴 같은 게 배경에 있는 한글의 2바이트를 반으로 가르게 될 경우 나머지 1바이트도 알아서 지워서 표시해 줬다. 어떤 경우에도 깨진 한글의 잔해 바이트가 표시되는 일이 없었다.

아마 한글 바이오스뿐만이 아니라 응용 프로그램 차원에서 무슨 특수한 처리를 한 것 같긴 한데, 그 대신 당시 MS에서 만든 한글판 프로그램들은 한글 바이오스가 없으면 동작하지 않고, 속도도 느리고 이래저래 파워 사용자들에게서 욕 많이 먹었다. 특히 QuickBasic 한글판은 라이브러리 파일이 영문판과 호환되지 않는 등 최악의 제품이었다.

<날개셋> 한글 입력기는 현재 '마소바탕'이라고 하여 MS 한글 바이오스가 내장한 조합형 글꼴을 그대로 지원하고 있다. 조합 구조가 전통적인 8*4*4벌 도깨비 글꼴과는 다른데 이런 것까지 복원해 냈다.

3. 끝으로 태백한글이라는 프로그램이 있었다. 1994~95년까지 32비트 코드로까지 비교적 오래 개발되었고, 도깨비 글꼴을 그대로 지원한다는 점이 무척 좋았다. 얘는 아마 조합 중인 한글을 음소 단위로 지우는 기능이 있었지 싶다.

도스도 모자라서 영문 윈도우 3.x에서 한글을 구현해 냈다는 한메한글 같은 프로그램은 운영체제의 무슨 계층에서 훅킹을 해서 도대체 어떻게 만든 걸까? 파워 사용자 중에는 영문 윈도우+한메한글이 오히려 한글 윈도우보다 더 안정적이고 좋았다는 말을 할 정도였으니 말이다.
32비트 시대가 도래하기 전에 한글 IME는 DLL이 아닌 EXE이긴 했는데, 그때는 구체적으로 어떤 메카니즘을 썼는지 잘 모르겠다. 물론 그 시절에는 한 프로세스가 시스템 전체에 어떤 영향을 끼치기가 지금보다 훨씬 더 쉬웠을 테니까 그 원리가 그렇게 복잡하고 어려운 건 없었을 것이다.

이것저것 잡설이 길어졌는데, 추억에 공감하시는 분이 있다면 용자.

한글 윈도우 3.1은 실행 전에 언제나 아래와 같은 경고문이 떴었다.
보다시피 MS는 분명히 Hangeul이라는 명칭을 썼었다. 허나 지금 대세는 Hangul이 압도적으로 굳어져 버린 듯. <날개셋> 한글 입력기도 6.0부터는 표기를 Hangul로 바꿨다.

Warning: For correct execution of DOS Box in Hangeul Windows 3.1,
You should use Hangeul Windows 3.1 standard HBIOS.

Warning: Your DOS is not compatible with Hangeul MS-DOS. You may have
some problems when you use Hangeul Windows 3.1.

Press any key to continue...

Posted by 사무엘

오늘날, 어떤 데이터(개념상 Document라고 불리는)를 메모리에 완전히 읽어들여서 사용자가 그 데이터를 편집할 수 있는 업무용 프로그램에는... 거의 필수로 undo 기능이 있다.
이건 우리가 잘 실감을 못 해서 그렇지 사용자에게 심리적으로 굉장한 안정감을 주는 편리한 기능이다. 뭘 잘못해서 망쳐 놓더라도, '미리 저장 -> 지금 문서를 저장 안 하고 예전 문서를 다시 불러오기' 같은 뻘짓을 안 해도 Ctrl+Z만 누르면 만사 OK.

소프트웨어 GUI 가이드라인 교과서를 보면, 소프트웨어는 사용자에게 '용서'(forgiveness)라는 덕목을 발휘해야 한다는 말이 나온다. 사용자가 아무리 바보짓을 하더라도 이를 최대한 추스리고 수습하고 원상복귀 할 수 있어야 한다는 뜻.
컴퓨터 프로그램은 기독교의 하나님 같은 존재가 아니다. “자유 의지가 있으니, 하늘나라든 지옥이든 선택에 따른 책임도 전적으로 네 몫이다” 주의가 아니다. 그러니 인간의 삶에도 Undo가 있으면 참 좋을 텐데 현실은 그렇지 못하니 참으로 안습이다. 오히려 '말은 하고 못 줍는다', '엎질러진 물', '소 잃고 외양간 고친다' 같은 냉정한 속담만이 있을 뿐이다.

잡설이 길어졌다만,
역사적으로 Undo라는 개념이 허접하게나마 가장 일찍부터 존재한 분야는 그래픽 프로그램이었다.
걔네들은 원래부터 문화가 좀 독특해서 마우스의 비중이 매우 높으며, 우클릭이 Context menu의 의미로 쓰이지도 않을 정도이다.
그리고 근본적으로 마우스라는 게 키보드보다 실수를 훨씬 더 하기 쉬운 입력 장비이고, 한 번의 동작으로 수백· 수천 개의 픽셀이 한꺼번이 바뀔 수 있기 때문에 Undo가 없으면 안 된다.

문득 든 생각: 그래픽 프로그램을 이용해서 마우스로 Freehand drawing을 하는 도중에 bksp 키를 누르면.. 직전의 수 픽셀 단위로 곡선을 철회하는 기능이 있으면 좋을 것 같다. 정교한 도트 노가다 할 때 유용할 것 같다. 보통 Ctrl+Z 누르면 그렸던 선 전체가 한 방에 날아가 버리잖아?

물론 Undo라는 건 그렇게 쉽게 구현할 수 있는 기능이 아니며 메모리 오버헤드가 크다.
더구나, 과거에 Undo 기능이 있던 프로그램은 딱 한 단계밖에 취소가 되지 않았었다. Ctrl+Z를 누르면 직전 작업을 취소했다가, 다시 살렸다가 하기만을 반복할 뿐이었다. (메모장.. 정확히 말하면 윈도우 운영체제의 에디트 컨트롤도 딱 그 수준의 1단계 Undo를 지원한다.)
수십, 수백 단계의 작업을 고스란히 취소하고 취소 내역을 다시 철회(redo)까지 하는 command history 수준의 multi-level undo 기능은 1990년대까지만 해도 MS 워드 같은 소수의 상업용 대형 프로그램에서나 볼 수 있었다.

이런 프로그램은 Document의 내용을 변형하는 모든 명령들이 체계적으로 분류가 돼 있다. 그래서 편집 메뉴를 열어 보면 단순히 '실행 취소 / 재실행'이라고만 돼 있는 게 아니라 '삭제 취소 / 취소된 자동 완성 재실행'처럼, 무슨 명령이 직전에 취소되었고 무엇을 재실행할지 명령의 이름까지 메뉴에 친절하게 표시돼 있기도 한다.
그 반면, Undo/redo를 염두에 두지 않고 Document를 고치는 코드가 제멋대로 섞여 있던 프로그램에다가 어느덧 갑자기 multi-level Undo/redo 기능을 최초로 추가할 일이 생겼다면 아마 십중팔구 코드를 다 갈아엎는 대공사를 해야 할 것이다.

컴퓨터의 성능이 열악하던 도스 시절엔, Undo와 Redo가 모두 존재하는 프로그램은 매우 드물었다.
아래아한글 1.x는 좀 특이한 경우인데, 줄 끝까지 지우기· 단어 지우기 같은 몇몇 지우기 명령으로 인해 지워진 텍스트만을 1회에 한해 되살리는 Undo 기능이 있었다.
그 후 아래아한글 2.0에서 97은 그 Undo의 단계가 3회로 늘었을 뿐이었다. 내 기억이 맞다면, 이 기능은 최근 3회의 주요 지우기 단축키(메뉴에 등재되지 않은)에 의해 지워졌던 텍스트 중 하나를 골라서 커서가 있는 곳에다 삽입해 주는 기능에 불과했다. 원래 있던 위치에 되돌려 놓는 것도 아니고... -_-

Ctrl+X(오려두기)야 본문이 클립보드에 고스란히 들어가 있으니 별도의 Undo 버퍼에다 저장할 필요가 없고,
Ctrl+E(지우기)로 지워진 텍스트는 의도적으로 되살리기가 전혀 되지 않는다고 도움말에 친절하게 안내까지 돼 있었다. ^^;;
그것 말고 문서나 표 레이아웃을 잘못 건드려서 망쳤다거나 하는 더 중요한 기능에 Undo 따위는.. “Undo 뭥미? 그거 먹는겅미? 우걱우걱...”이었다. 그냥 이전 문서를 새로 불러오는 수밖에..
이런 불편한 프로그램을 옛날 사람들은 어떻게 쓰고 지냈을까?

그래서 아래아한글 2002는 256단계 undo가 지원된다고 잔뜩 광고를 하고 다녔었다. MS 제품들은 진작부터 지원한 기능인데도 말이다. 하긴, 그것 말고도 글자 크기 제한이 드디어 없어지고 글자색 제한이 없어진 것도 개인적으로 무척 마음에 들긴 했다. better late than never이다.

<날개셋> 한글 입력기의 편집기 프로그램은 1.x와 2.x 시절에는 Undo 비슷한 기능도 전혀 없었다. 3.0에 가서야 32단계의 multi-level undo가 추가되기는 했으나... 글자 하나, 한글 낱자 하나 입력되는 모든 단계가 histroy에 기록된지라 실용성이 시원찮았다.
그것이 지금의 형태로 개선되 것이 4.2 버전부터이다. 연속된 에디팅 동작뿐만이 아니라 불연속적인 에디팅 동작을 한 history로 통합하는 기능까지 추가되어, 여러 블록을 동시에 삭제한 것이나 Replace All 명령을 내린 것도 한 번에 취소가 가능해졌다.

사실 <날개셋> 편집기의 에디팅 엔진은 아직 좀 효율적이지 못한 구석이 있다. Undo/redo 명령을 내리면 그 부분이 아무리 사소하더라도 문서 전체의 레이아웃을 싹 다시 하고, 화면 전체를 새로 그린다. 그렇기 때문에 수~수십 MB짜리 텍스트를 연 뒤에 Ctrl+Z를 꾹 누르고 있기가 겁난다. 본인은 이 프로그램을 만든 사람이고 프로그램의 내부 디테일이 어떤지를 잘 알기 때문에 그러기가 더욱 꺼려진다.

2004년에 만든 3.0 이래로 그냥 brute-force 알고리즘을 그 부분만은 아직까지 최적화를 못 했다. 한글 입력 부분과 직접적인 관계가 없고, 딱히 크게 티가 나는 부분이 아니다 보니 지금까지 방치되어 온 것이다. <날개셋> 한글 입력기 6.0의 다음 버전은 이 부분을 개선하여, 이제 안심하고 Ctrl+Z를 꾹 누를 수 있는 프로그램이 될 것이다.

Undo 기능과 관련된 얘깃거리를 두 가지만 더 꺼내고 글을 맺겠다.

첫째, 예전에 한번 언급한 적이 있듯이, 프로그램들이 Undo는 거의 예외 없이 Ctrl+Z로 정착해 있는 반면 Redo는 단축키가 프로그램마다 일치하지 않는 경우가 있다. MS의 관행은 Ctrl+Y인 듯하지만 Ctrl+Shift+Z인 프로그램도 있다.
아래아한글은 도스 시절에 Ctrl+Y가 지우기 명령의 일종이기 때문에 주의해야 한다. Redo를 생각하고 눌렀다가는 Redo는커녕 텍스트를 지우면서 후폭풍으로 기존 Undo history까지 모두 날려 버리기 때문이다!

둘째, Multi-level undo를 잘 구현한 프로그램이라면, 문서의 modified 플래그 처리도 잘 되어야 한다. 무슨 말이냐 하면, 문서를 저장했다가 어딘가를 건드린 후(= modified 플래그 켜짐), Ctrl+Z를 눌러 그 작업을 철회한다면 문서는 당연히 다시 unmodified 상태로 바뀌어야 한다.
그리고 반대로, 저장한 문서에 대해서 Undo를 해서 modified 상태가 됐더라도, 그걸 다시 Redo로 철회했다면 문서는 unmodified로 되돌아가야 한다. 논리적으로 당연한 얘기이다. <날개셋> 편집기는 multi-level undo가 처음으로 지원되기 시작한 3.0 때 이거 하나는 아주 철저하게 잘 구현해 뒀다.

비주얼 C++ 에디터, 그리고 국산 에디터인 EditPlus는 이 플래그 처리가 잘 된다. MS 오피스 제품도 마찬가지.
그러나 AcroEdit는 이게 되지 않아서 불편하며, 아래아한글도 2007은 처리가 되지 않는다. WordPad 역시 지원 안 함.

Undo나 Redo 같은 Command history 기능은 문서의 modified 상태까지 예전으로 되돌리는 명령이기 때문에 문서를 건드리는(modified 플래그를 언제나 켜는) 동작보다 상위에서 돌아가야 할 텐데, 이 점을 미처 고려를 못 한 것 같다. Undo나 Redo나 문서를 고치는 기능인 건 매한가지이기 때문에 무조건 modified 상태로. ^^

Posted by 사무엘

1. 총이 발명되면서 활은 전투 병기에서 완전히 은퇴하고, 레저 내지 스포츠용으로나 전락했다. 그런데 활이 총에 비해 독보적으로 갖는 장점은 바로 조용하다는 것.
이런 이유로 인해, 현대전에서도 일부 아주 특수한 임무를 수행하는 저격수는 활까지는 아니어도 석궁을 써서 요인을 암살하기도 한다고 들었다.
물론, 어지간하면 저격용 소총에다 소음기를 달겠지만, 더 조용해야 할 필요가 있을 때 말이다.

2. 증기 기관차는 동력원이 있으면서(마차나 글라이더나 돛단배와는 달리) 전기 에너지를 전혀 쓰지 않는 유일한 교통수단이다. 디젤 전기 기관차는 말할 것도 없고, 기름을 이용하는 내연 기관도 시동 걸 때는 배터리로부터 전기 플러그의 점화가 필요하지만, 증기 기관차는 진짜로 전기 안 쓴다. (그래서 EMP 공격에 전혀 영향을 받지 않는다고 한다 -_-)

3. 오늘날까지도 구닥다리 모래시계를 볼 수 있는 곳은 바로 사우나.. -_-;;
기온이 90~100도에 달하고 물로 축축하기까지 한 곳에서 시간 측정용으로 이것보다 더 좋은 물건은 없기 때문이다. ^^;;
그러고 보니 전자 기기가 무용지물인 곳에서는 쿼츠 시계가 아닌 태엽 시계를 다시 꺼내 써야 할지도 모르겠다.

4. 전기를 전혀 쓰지 않으면서 흔들림이 심한 곳에서 일관된 자형의 글씨를 쉽게 찍을 수 있는 기계는 역시 기계식 타자기밖에 없다.
하지만, “여행 중이거나 오랫동안 주거지를 떠나 있을 때든지, 기차나 배, 자동차, 전철 등 흔들리는 장소에서도 언제 어디서든 글을 찍어서 소식을 전하거나 기록을 남길 수 있습니다”는 오늘날 현실적으로 스마트폰이 그 역할을 대체하게 된 게 사실이다. ^^;;

5. 자전거는 동력원이 없고 가축의 힘을 쓰지도 않는 교통수단 중에서는 속도가 가장 빠르고 에너지 효율도 매우 좋다. 자전거와 타자기는 분야별로 차지하는 위상이 서로 비슷하면서 인류가 만든 대단히 훌륭한 발명품임이 틀림없다.

6. 우리나라에서도 '지멘스 옥타브'를 전파하면서 현역으로 활동 중인 8200호대 전기 기관차는 내부에 인텔 80386 CPU가 들어있다고 한다. 그나마 원래 스펙상으론 80286이 들어있었는데 한국 측의 요구로 로컬라이즈 과정에서 한 단계 업그레이드된 CPU가 들어갔다고. 개인용 PC에서는 10년도 더 전에 도태한 놈이지만, 이런 구닥다리들이 임베디드 환경에서는 꽤 오래 살아 있어 왔다. ATM 기기나 키오스크 같은 데서는 아직까지 윈도우 2000/NT, 심지어 윈도우 3.x 머신까지 살아 있기도 하니 말이다.

7. 80286이면 그나마 양반이다. 지금 이미 명왕성의 궤도도 넘어서 태양계의 끝에 도달했다고 알려져 있는 파이어니어 내지 보이저 탐사선은 무려 1970년대 말, 인텔 마이크로프로세서가 갓 발명되었던 시절에 발사되었으며, 여기에는 겨우 1.6MHz 램 4KB의 8비트짜리 컴퓨터가 장착되어 있었다. 2006년에 발사된 New Horizon 호에 장착된 컴퓨터와는 가히 넘사벽의 차이일 것이다.

그래도 저 옛날 컴퓨터도 지구로부터 받은 지령을 수행하고 우주에서 사진을 찍어 지구로 보내는 등 할일은 다 해 냈다. ^^;; 특히 보이저 호는 지금까지도 지구와 교신을 주고받으면서 살아 있는데, 이런 옛날 탐사선을 제어하는 것이야말로, 겨우 Y2K 문제 해결용 코볼 프로그래밍과는 비교가 안 되는 하드코어 legacy 프로그래밍의 진수일지도 모르겠다.

어차피 인간이 다루는 컴퓨터의 똑똑한 성능은 상당수가 그냥 현란한 비주얼 이펙트를 보이는 데나 쓰이고 있으며-_-, 임베디드 환경에 들어가는 컴퓨터는 닥치고 전력 소모 적고 발열 적고 우주선과 방사능에 강하고 튼튼한 놈이 짱이니까...;; 그런 곳에서는 성능보다는 신뢰성이 훨씬 더 중요하다고 하겠다.

듣자하니 목성 근처에서는 컴퓨터들을 죄다 짜부러뜨릴 강력한 방사선이 나오고 있었다고 하는데, 여기 근처를 처음으로 탐사한 파이어니어 10호가 튼튼하게 잘 버텼다고 한다.
일반 양민은 목성에 착륙 시도를 했다간, 뜨겁지만 않을 뿐이지 마치 지옥의 행성 금성에 착륙하는 것만큼이나 고압 유독가스 폭풍과 방사선으로 인해, 도착도 하기 전에 끔살..;;

물론, 태양과 지극히 먼 춥고 캄캄한 우주를 외로이 날아가는 탐사선이 이렇게까지 오래 장수할 수 있는 것은 근본적으로 인간이 태양이 아닌 근원으로부터 막대한 양의 에너지를 얻는 방법을 개발해 냈기 때문이다. 그 이름도 유명한 원자력. 이렇게 생각하니까 대단하지 않은가? 탐사선 역시 방사선 원소를 이용한 소형 발전기로부터 수십년 간 전력을 공급받고 있으며, New Horizon 호는 본격 활동을 시작하는 명왕성 근처까지 갈 때까지는 아예 최대 절전(하이버네이션) 모드로 더욱 에너지를 아끼면서 가고 있다.

8. 컴퓨터는 음식이나 악기나 심지어 자동차와도 달리, 수제· 명품 같은 소위 '장인정신' 근성이 존재하지 않는 물건이다. 그런 근성이 존재하지 않는 정도가 아니라 아예 존재할 수가 없다. 반도체· 집적 회로라는 게 애초에 사람 손으로는 도저히 만들 수 없는 넘사벽급 기계니까.
(세상에 사람 손만으로는 어설프게나마도 절대로 전혀 만들 수 없는 물건은 흔치 않다. 건물만 해도 결국 사람 손으로 만드는 것인데!)

- 장인의 손맛이 살아 있는 독일제 저전력 CPU
- 3대째 그래픽 카드만 만드는 명문 가문..
이런 게 있을 리가..;; 컴퓨터 분야에는 롤스로이스, 포르쉐, 벤츠 같은 성격의 브랜드도 없다. 닥치고 인텔, AMD, nVIDIA 같은 메이커만 존재할 뿐이다. ^^;; 단순히 역사가 짧아서 그런 전통이 없는 건 아니라는 뜻이다.

사실, 외국의 자동차 명문 브랜드는 해당 회사의 창업자 이름을 딴 게 많다. 심지어 비행기를 만드는 보잉 사도 창업자 이름을 딴 사명이니까...
하지만 컴퓨터계에서는 그런 넘사벽급 엔지니어의 이름은 간판에서는 찾을 수 없고 오히려 무어의 법칙, 황의 법칙 같은 괴랄한 법칙-_- 이름에서나 간간히 등장하는 듯하다.

컴퓨터는 인간이 수천 년간 축적한 물리, 화학, 수학 지식의 결정체요 총아이다. 정말 대단한 발명품이 아닐 수 없다. 비단 기술뿐만이 아니라 사회· 정치적으로도 충분한 배경이 마련되지 않았다면 결코 발명될 수 없었다(전쟁 같은).

그런데 전기가 맛이 갔거나 컴퓨터가 돌아갈 수 없는 곳에서는 증기 기관차, 모래 시계와 더불어 “수판”이 되살아날 가능성은 있으려나 모르겠다. ^^;;
숫자는 자연어 문자와는 달리 엔트로피가 편중됨이 없이 균일한 문자이다 보니, 빠르고 정확하게 치기가 은근히 힘들다. TV 생활의 달인 편에도 잘 나오다시피, 능숙한 수판의 달인은 일반인이 계산기 키를 다 두드리기도 전에 어지간한 사칙연산은 말끔히 해치워 버린다.

Posted by 사무엘

칠레처럼 아주 길쭉한 국가가 있다고 치자. 이 국가에는 지형을 따라 거대한 간선 철도가 놓여 있고 n개의 역이 있으며, n개의 역에 모두 정차하는 완행 열차가 일정 간격으로 다닌다.

이 설정을 좀 극단적으로 확장하여 역 수가 수백, 수천, 수만-_-개에 달한다고 가정하자. 그렇다면 급행 열차를 운행할 필요가 응당 생긴다. 2000개역쯤 떨어진 지역에 가려고 하는데 전역정차 열차를 탈 수는 없는 노릇 아닌가. 그렇게 여행 거리가 길어지면, 급행 열차가 서는 곳까지 가서 환승하는 불편 정도는 급행의 빠른 속도가 충분히 보상하고도 남게 된다.

자, 이를 일반화하면.. 급행도 등급이 필요해서 특급, 쾌특 등 n차원의 급행을 생각할 수 있게 된다. 등급이 올라갈수록, 서는 역 수가 무척 적어서 타기 힘든 대신에 일단 타기만 하면 엄청난 이동성이 보장된다. 급행과 완행은 배차 간격은 모두 동일하다고 치자.

여기서 문제가 생긴다.
각 등급의 급행 열차들은 정차역 수를 얼마로 설정하는 게 좋을까?
또한, 철도역 수 n에 대해서, 최대 몇 등급의 급행이 존재하는 게 적당할까?

n개의 역이 모두 똑같이 중요하고 이용객 수가 균일하다고 가정할 때,
어떻게 급행을 운영하는 게 승객의 평균 표정속도를 최대화하고 반대로 평균 환승 대기 시간을 최소화할 수 있을까?
선로 수는 충분하기 때문에, 완급 결합으로 인한 대피 대기 오버헤드라든가 선로 용량 걱정은 할 필요 없다고 가정하겠다. ^^

역 수가 10개 남짓이라면 급행이 있을 필요가 없겠지만, 역 수가 100개쯤 된다면 3~4개역을 건너뛰는 1차 급행에 이어서 한 10~12개쯤 역을 쉬엄쉬엄 건너뛰는 2차 급행이 있어도 좋을 것 같다.

전산학을 전공한 친구라면, 이런 부류의 문제를 생각하면서 비슷한 형태의 아주 유명한 알고리즘을 하나 떠올리게 될 것이다.
바로 '쉘 정렬'이다!

쉘 정렬은 삽입 정렬을 원소별로 띄엄띄엄 적용하되 나중에 그 간격을 촘촘히 좁히는 방식이다.
삽입 정렬은 시간 복잡도가 O(n^2)이지만, n의 크기가 작아서 띄엄띄엄일 때는 오버헤드가 크지 않으며, 또 편차가 커서 리스트가 상당수 정렬되어 있을 때는 매우 빠르게 수행되기 때문에 그 특성을 이용한 것이다.
쉘 정렬은 알고리즘의 특성상 실제로 코딩해 보면 루프가 3중, 4중으로 들어가기 때문에 무거울 것 같지만 돌려 보면 성능이 매우 좋다. 프로그래밍 언어라고는 아직 어셈블리밖에 없던 1950년대에 고안된 알고리즘이다.

여타 정렬 알고리즘들이 O(n^2), O(n log n) 아니면 심지어 O(n) 같은 식으로 시간 복잡도가 딱 파악되는 반면, 이 쉘 정렬은 비록 O(n^2)보다야 훨씬 빠르긴 하지만 시간 복잡도가 제대로 분석되어 있지 않다.
삽입 간격을 설정해서 좁히는 방식을 어떻게 설정하냐에 따라서 성능이 크게 달라지기 때문이다.

완행 다음으로 급행을 겨우 1역 균일 통과, 특급을 2역 균일 통과처럼 정말 무식하기 짝이 없게 운행하지는 않는다. 급행 등급이 하나 올라갈 때마다 급행은 최소한 기하급수적으로 통과역 수가 늘어야 이치에 맞다.
쉘 정렬도 그와 마찬가지이다. 23, 10, 4, 1 같은 급으로 큼직하게 수가 바뀌고, 이 수들이 가능한 한 서로소가 되게 하는 게 정렬 효율에 좋다고 알려져 있다. 16, 8, 4, 2, 1처럼 정확하게 컴퓨터스럽게 배수· 약수 관계로 포개지는 간격은 매우 비효율적이며, 그런 나쁜 수열을 쓰면 쉘 정렬의 시간 복잡도가 최악의 경우 도로 O(n^2)로 치솟는다고 한다.

우리나라의 급행 전철이 정차역 수가 여전히 너무 많다는 지적이 있긴 하지만, 이것은 환승을 싫어하는 국민 정서 내지 환승이 불편한 구조, 급행도 어차피 최대 속도는 동일하고 완행보다 그렇게 많이 빠르지 않은 것, 역마다 weight가 현실적으로 차이가 나는 것, 급행의 소극적인 운행(긴 배차 간격) 같은 다른 환경적인 요인 때문에 그런 것이다. (현실에서는 환승역이냐 그렇지 않느냐의 여부 하나만으로도 역별 weight가 크게 벌어질 수밖에 없다)

이상, 철도와 전산학을 융합한 뻘글이었다.
쉘 정렬의 수열 설정 방식이 철도 운영에서도 이론상 효율적이라 말할 수 있을까? ^^;; (급행은 4역씩 건너뛰고 특급은 10개역, 쾌특은 23개역.. ㄲㄲ)
참고로 쉘 정렬은 수열을 제일 잘 설정했을 때 시간 복잡도가 O(n (log n)^2) 까지는 떨어진다고 한다.


* 덧붙이는 말:
어제는 KTX 열차가 개통 사상 처음으로 탈선 사고를 일으켰다고 한다.
여기에 대해 철도 덕후 사무엘 님의 공식 입장을 말하자면, 이건 두말 할 나위도 없이 선로 시설 문제이지 차량 문제가 아니라는 것이다.
차량이 떼제베가 아닌 산천이었다고 하는데, 지금까지 늘 말썽을 일으켜 온 것처럼 차량이 고장을 일으킨 거라면, 그대로 차가 멈춰서는 걸로 끝나지 지가 무슨 능력으로 탈선까지 하겠는가?

더구나 이 차는 보기 드문 광명 시종착 KTX였다. 광명이 단순 경유역이 아닌 종착역이기 때문에 여타 열차와는 다른 선로로 건너가야만 했다. 그래서 선로 분기기가 열차를 새 선로로 유도하고 있었는데, 열차가 다 건너기 전에 선로 분기기가 전산 착오 내지 추위로 인해 오작동한 것 같다. 그래서 뒷부분 객차의 진로를 막았고, 이것 때문에 찌이이이익 소음+타는 냄새+탈선이 야기된 것으로 추정된다.

열차가 고속으로 쌩쌩 달리다가 교량이 붕괴했다거나 차량이 자폭이라도 한 것과는 전혀 다른 부류의 사고이다. 오히려 열차는 종착역 진입을 앞두고 위와 같은 이유로 인해서 아주 천천히 달리면서 신호를 기다리고 있는 상태였을 것이다. 그리고 그 사고도 그런 특수한 상황에서나 발생한 사고이다. 이 사고가 KTX 차량 시스템 전반에 대한 불신풍조로 이어지기는 않기를 본인은 바란다.

이 사고로 인해 이 열차를 바로 뒤따라오던 상행 KTX는 평택쯤에서 다시 천안아산-_- 역으로 역주행하여 돌아가야만 했고, 대전-서울 구간의 고속선이 폐쇄되는 바람에 다른 KTX들은 아예 경부선 기존선으로 우회해서 다녀야 했다. 주말 임시 열차는 아예 선로 용량 부족으로 인해 운행 중단. 코레일의 입장에서는 손해가 그야말로 막심했을 것이다. 이로 인해 수원-천안 구간에서 KTX 산천이 보이는 진풍경이 연출되기도 했다.

Posted by 사무엘

별개의 분야 이야기들이 또 한데 컬렉션 형태가 됐다.

1. Personalization of Windows

이건 아무나 쉽게 할 만한 건 아니지만, 아마 윈도우 파워 유저들은 한번쯤 시도해 봤지 싶다.

콘솔(명령창)의 글꼴 바꾸기
솔직히 나도 Terminal 기본 서체는 이제 지긋지긋해서.. 똥 묻은 파르페 다음으로 싫다.. -_- 과거 윈 9x는 도스 프롬프트의 코드 페이지를 영문 437로 바꾸면 Courier New나 Lucida Console이라도 나와서 괜찮았으나, 2000/XP의 콘솔 글꼴은 너무 단조롭기 그지없다.
특정 레지스트리 부위에다 00이라는 키를 추가해서 원하는 글꼴을 지정한 뒤 재부팅을 하면 된다고 하는데, 난 여러 사이트들에서 시키는 대로 해도 안 되더라...;; 잘 모르겠다.

XP의 경우, uxtheme 패치
자세한 배경 설명은 생략하고. 요지는.. XP의 트레이드마크라고 할 수 있는 Luna 테마 대신 다른 시각 테마를 쓰는 것이다. 그런데 테마를 바꾼다는 건 단순히 색깔이나 이미지 같은 데이터뿐만이 아니라 각종 화면 요소를 그리는 실행 코드 자체를 바꾸는 것이기 때문에, 운영체제의 안정성 및 보안에 영향을 끼칠 수 있다. 그래서 운영체제는 기본적으로 디지털 서명이 존재하는 테마만 고를 수 있게 돼 있다.
그러나, 개인 테마 제작자가 일일이 자기 작품에 대해서 $를 지불하고 번거롭게 디지털 서명 인증을 받는 건 쉽지 않은 노릇이고.. 결국 디지털 서명이 없는 테마도 지정 가능하게 아예 운영체제 자체를 크랙하는 테크닉이 나돌게 됐다. 아이폰으로 치면 탈옥 정도 되겠다.

난 XP의 파란 Luna가 예뻐서 거기에다 custom 글꼴 & 그림만 붙여서 잘 썼다. 테마를 바꿀 필요는 느끼지 않는다. 비스타로 갈아탄 지 3년이 넘었지만 여전히 XP Luna가 그리울 때가 있다. 하긴, 비스타에서 Luna 커스텀 테마를 일부러 구해다 쓰는.. 흠좀무스러운 사람도 있다고는 하더라...

2. Phone number as the hyperlink

남이 내게 문자 메시지로 다른 전화번호를 알려 줬다. 이렇게, 발신자 그 자체가 아니라 본문에 포함돼 있는 전화번호를 번거롭게 암기하거나 수첩에 적지 않고 그대로 저장하거나 전화를 걸 수는 없을까?
마치 http로 시작하는 문자열이 인터넷 주소이고 "@ ." 같은 패턴이 이메일 주소이듯, 전화번호를 나타내는 정규 표현식이 통용되어 이런 건 전화기가 마치 클릭 가능한 하이퍼링크처럼 본문에다 표시해 주는 기능이 있으면 좋겠다.

자동으로 링크를 못 만든다면 최소한 번호를 마우스로 긁어서 복붙 정도는 되어야겠지.
간단하기 때문에 스마트폰에는 이미 구비되어 있는 기능일지도 모르겠다?
아래아한글 도스용에 있던 전화번호부와 팩시밀리 기능이 불현듯 떠오른다. COM 포트를 통해 컴퓨터가 모뎀으로 전화를 걸어 주던 시절이었다.. ^^;;

3. 디렉터리 생성을 좀 더 똑똑하게

컴퓨터의 파일 시스템에서 지우기 명령에 하위 디렉터리를 재귀적으로 몽땅 다 지우는 기능이 있다면,
디렉터리 생성 명령에도 중간의 다단계 디렉터리를 한꺼번에 생성하는 기능이 있어야 한다.
또한, 디렉터리를 생성한 후 바로 거기로 가는(change directory) 기능 내지 옵션도 있으면 편하지 않을까?
이건 114로 치면 전화번호를 물은 후 그 전화번호로 바로 거는 기능에 해당한다.

다단계 디렉터리를 한꺼번에 생성하는 기능은 있지만 생성한 디렉터리로 바로 가는 기능은 프로그래밍 API라든가, 각종 유틸리티 프로그램이나 명령으로도 내가 본 기억이 없는 듯하다.
요즘은 옛날에 비해 디스크/파일을 다루는 유틸리티에 대한 필요성이 훨씬 덜해지긴 했지만.. 특정 디렉터리나 드라이브로 곧바로 이동 가능하고 특정 프로그램을 단축키 하나로 바로 실행해 주고 한 화면에서 압축 파일이라든가 FTP 연동이 바로 되는 유틸리티가 있으면 컴퓨터 생활이 정말 편해진다.

토탈 커맨더, NexusFile 같은 프로그램이 유명하긴 한데 본인은 단축키가 완전히 손에 익어 버려서.. 개발이 중단된 구닥다리 WinM을 못 버리고 있다.

4. DR만 들어가면 다 박사?

DR이라는 약어가 하도 '닥터'라고 통용되니까, 과거에는 이로 인해 재미있는 오해가 발생한 컴퓨터 소프트웨어가 있었다.
MS-DOS의 경쟁자 중 하나이던 DR-DOS는 그래도 다 대문자로 쓰고 MS-DOS도 '엠에스'라고 읽다 보니, '디알'이라고 통용되었던 것 같다. MS-DOS를 설마 '미스 도스'이라고 하지는 않잖아? 도스의 모에화ㄲㄲㄲㄲㄲ 훗날 나온 노벨 도스의 전신이 DR-DOS인 줄은 모르고 있었네..;;

그러나 그래픽 소프트웨어인 '닥터할로'는 답이 없다..;; Dr. Halo라고 쓰면.. 누구에게라도 영락없이 '할로 박사님'처럼 보일 수밖에 없지 않은가. 설마 개발자가 박사 학위 소지자이기라도... 한지는 모르겠지만 Dr은 그냥 '드로잉'을 줄인 말이라고 한다.

5. 스마트폰 OS 에뮬레이터

PC에서 안드로이드 에뮬레이터가 실행되는 속도는 실제 기계에 비해서... "꽤", 훨씬 더 느리다. 난 약간 느릴 줄 알았는데 이 정도까지 차이가 날 줄은 몰랐다.

하긴, 도스박스조차 200x년대의 컴에서 같은 x86 아키텍처용 도스용 프로그램을 펜티엄급으로밖에 실행을 못 하는데, x86와 ARM은 인스트럭션 구조가 근본적으로 다르다. 게다가 요즘 스마트폰은 CPU와 메모리로만 치면 이미 최하 윈도우 98/2000 정도는 너끈히 돌리는 성능이다. 무슨 고전 게임도 아니고, PC와의 격차가 의외로 높지 않으니 PC에서 에뮬레이팅이 버거울 수밖에 없다.
게다가 애플리케이션들은 그나마 네이티브 코드도 아니고 잘 알다시피 자바 기반.

그리고 마지막 복병이 있는데 바로 그래픽 가속이다. OpenGL 같은 통일된 인터페이스가 있다지만 그래픽 가속은 워낙 민감한 부위여서 그런지 가상화가 더디다. 가상 머신에서 돌아가는 윈도우 비스타/7이 Aero 효과를 내지는 못하며, 에뮬레이터에서 돌아가는 스마트폰 OS는 실물만치 현란한 비주얼을 선보이지는 못한다.

그러나 PC+에뮬레이터가 디스크 I/O만은 실물보다 훨씬 더 빠르게 수행한다.
이런 식으로 스마트폰 앱은 에뮬레이터에서 돌릴 때와 실물에서 돌릴 때의 성능 편차가 의외로 크며, PC에서 개발하더라도 수시로 실물에서 올려서 확인이 필요하다고 한다.

Posted by 사무엘

1. 망했어요

사례 1: USB 플래시 메모리를 ‘안전하게 제거’하지 않고 그냥 뺌 → 어느 날 그걸 꽂으니까 “뭘 스캔해서 수정하시겠습니까?”라고 물음 → 예 → 뭐 오류가 있는 파일 조각을 따로 정리했다고 하는데, 그 후 작업하던 문서 파일이 날아가 버림

사례 2:자기가 작업하던 파일을 인터넷에 올림 → 다른 컴에서 그걸 그대로 엶 (인터넷 임시 파일 디렉터리에서) → 작업을 임시 파일에다 마저 다 해 놓고 저장 → 나중에 그 파일을 찾아보니 없음

이번 학기에 학교에서 주변에 실제로 있었던 낭패 사례이다. 조심하자. 본인이 겪었다는 건 아니고. -_-
PC가 발전하는 걸 도스 시절부터 그 디테일을 쫙 봐 오지 않은 사람이라면 쉽게 저지를 만도 한 실수인 것 같다. 디스크 캐시와 flush의 필요성, 인터넷 임시 파일의 개념과 원리에 대한 이해가 필요하니까 말이다.

USB로 연결하는 플래시 메모리의 경우, 평소에 그냥 쑥 제거해도 별 문제가 없는 듯하다가 어느날 갑자기 FAT 구조가 망가졌다고 그러면...;; 정말 사용자들 패닉에 빠뜨리기 딱 좋을 것 같다.
안전하게 제거를 하지 않는 것은 과거에 플로피 디스크 드라이브에 불이 들어와 있는데 디스크를 강제로 꺼내는 것이라든가, 하드디스크를 파킹하지 않는 것만큼이나 위험할 수가 있다.

다만, CD롬은 일단 쓰기가 없는 읽기 전용 매체인 데다가, eject 버튼을 누르면 아무 때나 디스크를 물리적으로 꺼내는 게 아니라 자기가 꺼낼 준비를 다 마치고 나서 eject를 시켜 주기 때문에 다소 예외적인 존재이다.

2. 하드디스크 파킹의 추억

옛날에 컴퓨터에 하드디스크라는 게 처음으로 등장하던 시절엔(도스+윈도우 3.x) 컴퓨터를 끄기 전에 하드디스크 파킹이 안전을 위해 필수적인 절차였다. 파킹을 하지 않는 것 자체가 문제는 아니지만, 파킹을 하지 않은 채로 나중에 하드디스크가 외부로부터 충격이라도 받았을 때, 헤드가 자기 아래의 디스크 영역을 건드리거나 긁는 게 문제가 되었기 때문이다. 헤드와 디스크 사이의 간격은 아마 몇 마이크로미터 정도밖에 되지 않았지 싶다. 하드디스크는 그 당시로서는 그만치 첨단 정밀 기기였던 것이다.

파킹은 하드디스크의 헤드를 디스크가 아닌 다른 안전한 위치로 옮기는 동작을 말하는데, MS 도스 인터럽트를 날려 주면 수행되었다(INT 13, 19h). 286 AT급 이상부터 추가된 명령이다. 도스 시절에 컴퓨터의 C:\Util에 가 보면 park.com/exe는 꼭 한둘씩 있었다.

그런데 이 파킹 유틸리티의 비주얼이라는 게, 오늘날로 치면 마치 화면 보호기의 비주얼만큼이나 아주 잉여스럽게 발달했다.
그냥 파킹만 하면 재미없으니까 좋아하는 볼거리, 미소녀 그림-_- 따위가 뜨는 파킹 프로그램들이 우후죽순처럼 등장한 것이다.

당시 여러 파킹 프로그램이 있었지만 본인의 기억에 가장 남는 건 일명 Princess maker 파킹이라고 아래와 같은 소녀 그림이 나오는 프로그램이었다. 어렸을 때는 정말 환상적이기 그지없는 그림이었다.

본인은 도스 시절에 하드웨어 제어 프로그래밍을 경험한 적은 없지만, 그때는 각종 인터럽트 레퍼런스가 지금으로 치면 윈도우 API 레퍼런스나 마찬가지였다. ^^;; 그걸로 마우스를 직접 제어하고, 한글 바이오스가 설치돼 있는지 감지하는 등의 작업을 했는데 오늘날은 다 필요 없어진 셈.

또한, 전원이 끊어지는 순간에 자동으로 파킹이 되는(auto-parking) 하드디스크가 이내 등장하고, 도스에서 윈도우로 PC 환경이 바뀌고, 또 요즘 같은 복잡한 운영체제는 아무 때나 바로 끄면 안 되고 어차피 시스템 종료라는 걸 요구하게 되면서 customized 파킹 프로그램이라는 유행은 역사 속으로 사라지게 됐다. 지금은 파킹 프로그램뿐만 아니라 화면 보호기도 LCD 모니터가 대세가 되면서 취지가 무색해지긴 했다.

3. 당신이 사용하는 소프트웨어는?

서식 없는 텍스트 작성
컴 초보: 메모장이나 일반 워드 프로세서로 낑낑댐
나: EditPlus나 AcroEdit, <날개셋> 편집기^^ 잘 다룸
전산과 덕후: vim, emacs 등..;;

서식 있는 텍스트
컴 초보: 닥치고 아래아한글
나: 아래아한글이나 워드를 평균 이상으로 그럭저럭 활용
전산과 덕후: TEX이나 그냥 메모장으로 html 코딩..;; 리눅스 용자는 OpenOffice를 쓰기도 함 ㅋㅋㅋ

뭔가 자동화 작업을 반복 수행할 때
컴 초보: 직접 손으로..;; 아니면 프로그램 검색하거나 남에게 부탁
나: 적당한 프로그램이 없으면 그냥 비주얼 C++로 프로그램 자작
전산과 덕후: 파이썬이나 쉘 스크립트

위의 것보다는 더 규모 있고 성능이 중요하고 남에게 실행 파일을 전달해 주는 프로그램을 짠다면?
컴 초보: 그냥 선생이 지정해 준 툴로... 과제만 내고 나면 다 잊어버림
나: 닥치고 비주얼 C++ 짱
전산과 덕후: 커맨드 라인에서 gcc -_-;;

난 소프트웨어 개발자치고는 MS의 종속도가 높으며, 전산과 덕후의 문화를 너무 모른다. -_-;;;

Posted by 사무엘