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

요즘 학교나 관공서의 전산망에서는 인터넷 접속을 위해서 특정 보안 솔루션 ActiveX들과 그것도 모자라서 바이러스 백신까지 무조건 설치하라고 강요하는 걸 볼 수 있다. 그걸 안 하면 사이트 접속이 되질 않게 해 놓았다.  허나 본인은 그런 보안 솔루션들에 대해 정서적으로 굉장한 반감을 갖고 있으며, 그것들을 몸서리치게 싫어한다.

여러 보안 솔루션 중 키보드 보안 프로그램이 하는 역할은 아마도 사용자의 키 입력(비밀번호 같은)을 메시지 훅킹으로 가로챌 수 없게 하고, 반대로 없는 키 입력을 소프트웨어적으로 생성할 수 없게 하는 일일 것이다(온라인 게임에서 오토의 실행 차단). 또한, 은행 돈거래 관련 정보가 담긴 패킷은 정보가 유출되더라도 의미 파악이나 변조가 거의 불가능하게 아주 복잡한 계산을 동원한 암호화/해독이 클라이언트에서 행해져야 할 필요가 있을 것이다. 그런 기술적인 필요를 본인은 모르는 건 아니다.

다만, 웹 표준만으로 도저히 구현할 수 없는 운영체제 커널 기술 수준의 보안이 불가피하게 필요하다면, 차라리 무리해서 웹 애플리케이션을 만드는 걸 포기하고 깨끗하게 로컬 환경에서 돌아가는 exe 형태의 프로그램과 배포 패키지를 만들었으면 좋겠다.

nProtect 부류의 이상한 프로그램들은 웹브라우저를 끈 뒤에도 계속 메모리 차지하면서 남아 있는 것 정도나 보기 싫은 수준이고 그나마 ‘낫다’. 하지만 이놈의 빌어먹을 백신은 답이 없다. 바이러스나 악성 코드에 걸리지 말라고 설치하는 솔루션들이, 깔고 나면 악성 코드나 그 이상 수준으로 민폐 끼치면서 컴퓨터 성능을 쪽쪽 갉아먹기 때문이다. 좀 심하게 표현하면 컴을 완전히 병신으로 만들어 놓는다.

마치 치안과 국방을 담당해야 할 자국의 정규군이나 경찰이 하라는 일은 안 하고 자기네들부터 민폐 끼치고 민간인들을 등쳐 먹는다거나, 반공을 빌미로 공권력이 심심하면 멀쩡한 생사람을 빨갱이로 몰아서 잡아 죽인다거나 하는 상황을 생각하면 되겠다.

맥북 이전 4대 노트북을 쓰던 시절의 일이다. 본인이 다니는 학교는 내부에서 와이파이로 인터넷에 접속할 때 NetCare인지 뭔지 하는 보안 ActiveX와 바이로봇 백신을 반드시 설치하도록 강요를 하고 있다. 둘 중 하나라도 설치를 안 하면, 몇몇 사이트는 아예 접속이 되지 않거나 쿠키가 저장되지 않아서 로그인을 할 수가 없으며, 되는 사이트도 보안 솔루션들을 설치하라고 협박하는 문구가 든 프레임이 웹사이트에 제멋대로 추가되어 나오곤 했다.

그래서 본인은 어쩔 수 없이, 울며 겨자 먹기로 마지못해 깔라는 것들을 다 설치해 줬다. 그러자 저런 성가신 현상이 모두 없어지고 인터넷은 잘 되기 시작했다. 그러나 그 뒤부터 내 컴에서는 끔찍한 헬게이트가 시작되었다.

부팅 직후에 시스템이 시작 메뉴 구동 같은 각종 조작에 응답하는 속도가 눈에 띄게 느려졌고, 웹브라우저가 페이지를 여는 속도, 전반적인 파일 액세스 속도도 인내심의 한계를 느끼는 수준이 되었다. 최대 절전 모드에서 복귀하는 시간까지 예전보다 훨씬 더 길어졌다. 멀쩡하던 컴퓨터가 진짜 만신창이 장애인이 된 느낌이었다. 평상시에 운영체제의 메모리 사용량도 예전보다 수십 MB가량 늘었다.

나는 운영체제의 업데이트들은 목록만 자동으로 받게 한 뒤, 다운로드와 설치는 내가 지정한 것만 수동으로 하게 해 놓고 있었다. 그랬는데 그 보안 솔루션은 나의 설정을 씹고, 인터넷만 됐다 하면 마구잡이로 온갖 업데이트들을 제멋대로 받아서 설치했다.

언제부턴가 MS 오피스가 SP2이던 게 느닷없이 SP3으로 바뀌어 있었다. 프로그램이 버전업되어서 좋은 게 아니라 도리어 부아가 치밀었다. “이 자식, 지금까지 왜 이리 느리고 쓸데없이 디스크 액세스를 하는가 했더니, 그 수백 MB짜리 업데이트를 내 동의도 없이 제멋대로 설치하느라 그랬군.” 하는 생각에 말이다.

참다못해 하루는 넷케어고 백신이고 전부 다 모조리 지워 버렸다. 요즘은 백신도 용량이 몇백 MB 수준으로 뭘 하느라 그리도 커졌는지 모르겠다. 이것들을 다 지우고 나자 내 컴퓨터는 거짓말처럼 평화가 찾아왔다. 모든 성능이 예전 상태로 돌아갔다. 보안 솔루션들이 그들의 퇴치 대상인 악성 코드가 하는 짓을 동일하게 하고 있음이 입증된 순간이었다.

이제 맥북을 사용하면서 뜻하지 않게 얻은 큰 수확이 있다. 보안 솔루션 제약은 Windows 운영체제에만 적용되며, 맥에서는 그런 게 전혀 없이도 인터넷을 곧바로 자유롭게 이용할 수 있다는 것. 야호! 빌어먹을 넷케어니 바이로봇 따위를 설치하지 않아도 된다. 맥OS가 날 구했다. 스잡빠니 애플빠니 난 그딴 건 모르지만, 어쨌든 이거 덕분에 맥OS 호감도가 급상승했다.

한편, 고향에서도 비슷한 일을 최근에 겪었다. 고향집 컴퓨터가 언제부턴가 병신 중의 상병신이 돼 있었다. 부팅 후에 시작 메뉴를 눌러도 한참 동안 반응이 없고, 웹브라우저를 띄운 뒤에 창이 나타나기까지 몇 분이 족히 걸리고 있었다. 레지스트리나 파일 디렉터리를 살펴봐도 딱히 악성 코드에 걸린 것 같지는 않은데 영문을 모를 노릇이었다.

이 현상의 주범은 바로 V3 Lite였다. 이놈을 당장 지우자 컴퓨터는 운영체제를 갓 설치한 직후처럼 아주 쌩쌩해졌다! 그러니 난 도대체 진짜 악성 코드란 어떤 놈인지 가치관의 혼란을 겪을 수밖에 없었다.

바이러스가 묻은 메일 첨부 파일을 클릭한 것도 아니고, 이상한 사이트를 돌아다니다가 ActiveX 설치에 ‘예’를 누른 것도 아니었다. 이 V3은 어머니께서 집에서 인터넷으로 업무를 보시기 위해 어쩔 수 없이 설치한 것이었다. 이거랑 무슨 희한한 듣보잡 ActiveX들을 설치하지 않으면 직장의 업무 자동화 시스템에 접속이 되질 않기 때문이었다.

이런 일련의 사건을 겪은 뒤, 나는 더욱 더 백신 따위는 죽어도 절대로 쓰지 말아야겠다는 생각을 굳게 하게 되었다. 옛날처럼 백신이 그냥 사용자가 요청할 때만 파일이나 메모리를 스캔하면서 바이러스 검사를 해 주던 시절이 그립다. 저런 거지 같은 잉여 쓰레기 프로그램을 얹고도 작업을 원활하게 하려면, 가히 정말 최신식 최고급 컴퓨터를 써야겠다. 아니, 내 컴퓨터가 아무리 빠르고 메모리가 썩어 넘친다 해도 저런 프로그램에게 컴퓨터 자원을 내어 주기는 싫다.

보안을 빌미로 원치 않는 프로그램의 설치를 강요하는 이런 못돼먹은 풍조가 좀 없어졌으면 하는 바람이 있다. 이런 일이 계속될수록 이에 대한 반발 심리로 나의 컴퓨터 보안 위협 불감증은 더욱 커질 것이다.

Posted by 사무엘

지난 3월 24일, 맥북 프로 13인치형 모델이 본인의 제 5대 개인용 노트북 PC로 취임했다.
본인이 고등학교 시절부터 노트북 PC를 사용한 이래로 14년 만에 애플 계열 컴퓨터를 개인용 컴퓨터로 장만하게 되었다.

지금까지 사용하던 제4대 노트북은 2008년 5월에 도입되었고 윈도우 비스타 + 코어2 Duo 기종이었다. 오늘날의 PC 기준으로는 완전히 구닥다리로 전락한 셈.
좀 나중에 석사 졸업 기념으로 컴을 바꿀 생각이었지만, 마침 고향에서 부모님께서 새 컴퓨터가 필요하다고 하여 지금 내가 쓰던 걸 고향으로 보내고 나는 새 컴을 예정보다 더 일찍 장만하게 됐다.

초대 노트북은 분실, 2~3대 노트북은 고장 폐기였던 것에 비해, 4대 노트북은 약 4년에 가까운 임기를 마친 후 비교적 명예롭게, 그리고 예상보다 살짝 더 일찍 은퇴했다. 빠진 키캡 정리와 하드디스크 정리, 사소한 접촉 불량 수리 같은 정비를 받은 후, 고향으로 갔다.

지금까지 정말 유용하게 잘 사용해 왔고 키보드와 터치패드의 모든 감도가 손에 착 익은 정든 놈이긴 하지만, 이제 성능이 너무 뒤쳐졌고 액정 화면도 슬슬 누렇게 뜨는 등 노후화의 기미는 피해 갈 수 없었다. 물론 이것도 고향에 있는 컴퓨터보다는 훨씬 더 좋은 기종이다. 지금까지 부모님께서 쓰시던 컴은 이제 정말로 갖다 버릴 때가 됐고.. ㅜㅜ

구입한 새 노트북에 대해 스펙 차원에서 좀 아쉬움을 감수한 것은,
운영체제를 두 개나(윈도우와 맥 모두) 쓰는 것치고는 좀 부족한 감이 있는 하드디스크 용량.
그리고 지금 노트북보다 화면 해상도 픽셀수가 가로와 세로 모두 떨어진다는 점이다.
게다가 4:3이 아닌 요즘 대세인 와이드 화면을 쓰는 만큼, 이제 task bar를 가로가 아닌 세로로 배열해야겠다.
이질적인 키보드· 마우스 사용법은 덤.

Windows 운영체제는 내가 알아서 장만이라도 해서 깔아야 하는지 우려됐는데(OS 자체의 설치는 그렇다 치더라도 각종 드라이버들은 어떻게 잡으라고!!), 다행히 웃돈만 주면 판매처에서 아예 알아서 설치까지 한 채로 제품을 준다고 해서 안심을 했다.

Windows에다가는 단골 18번지 프로그램들을 설치해서 내가 늘 하던 일만 쭉 하고, 오픈소스 크로스 플랫폼 형태로 존재하는 프로그램들은 가능한 한 맥용으로 설치하는 방법으로 맥OS에 차츰 적응을 해 나갈 생각이다. 물론, 단골 18번지 프로그램들이 다들 단순 취향을 넘어서 내 생업과 관련된 일들을 하기 때문에, 나는 Windows를 아주 떠나서 살 수는 없다.

당장 개발툴만 예로 들어 보면, Windows에다가는 비주얼 스튜디오를, 맥에다가는 xcode와 Eclipse를 설치했다. 이클립스를 굳이 윈도우에다가 설치할 필요는 없으니까. 나도 드디어 윈도우 7 + 비주얼 스튜디오 2010으로 완전히 갈아탔다. 거기에다 호환성 차원에서 2003도 여전히 설치.

나는 <날개셋> 한글 입력기를 혼자서 만들었을 정도로 Windows 환경 개발에 정통한 것에 '비해서'는 여타 운영체제를 너무 안 다뤄 봤고 너무 모른다. 가령, 그 정도 기술 수준의 프로그램을 만들 줄 알면서 유닉스 명령을 나 정도로 모르는 사람은 별로 없지 싶다. 지금까지 쓸 일이 없었으니까. 오로지 Windows 독식이었다.

그런 와중에 이번 맥북 장만은 약간 risk도 감안하면서 내린 결정이긴 하다만, 15년에 가까운 나의 Windows 독점 풍토에 뭔가 새로운 바람을 수혈해 넣을 거라는 기대를 해 본다.
비록 나는 이제 예전에 맨대가리 헤딩으로 프로그래밍에만 매달려서 윈도우 API를 공부했듯이 맥OS API를 새로 처음부터 공부할 수 있을 것 같지는 않지만... 그래도 사람 미래라는 건 알 수 없으니까 말이다.

같은 데스크톱급 PC로도 모자라서 스마트폰은...;; 글쎄다. 이것도 언젠가는 안드로이드든 아이폰이든 써 보면 좋을 것 같지만, 딱히 길 안내 기능 말고는 그 돈까지 주면서 일부러 앞장서서 사서 쓸 매력을 느끼지는 않는다. PC에서 벌여 놓은 일이 너무 많아서 이것저것 다 쫓아가다간 다 놓친다. pruning이 필요함.

컴퓨터를 새로 세팅하다 보니, 이제 운영체제와 각종 소프트웨어들을 온통 업데이트해 줘야 하고, 맥 기반 개발툴들도 다 인터넷을 통해서 구해야 한다. 고로 수백~수 GB에 달하는 트래픽이 예상되는데, 언제 날잡아서 안정적인 유선 네퉉으로 해치워야겠다는 생각이 든다.

Posted by 사무엘

이 광근 교수는 프로그램의 정적 분석 분야에서는 아마 우주괴수급의 전문가가 아닌가 여겨지는 분이다.
카이스트 교수로 첫 부임했다가 2003년부터 서울대로 이직했다. 학부 출신 역시 서울대. 1983년에 입학 당시 자연과학 단과대 수석을 차지했으며, 재학 성적 역시 내내 최상위권이던 수재였다.
사진을 보면 알겠지만 이 교수는 상당한 동안이고 학생 시절 모습이 어땠을지가 상상이 된다.

개교 초창기부터 딱부러지게 전산학과가 있었던 카이스트와는 달리, 서울대는 198, 90년대엔 이과에 속한 계산통계학과와 공과에 속한 전자계산기공학과로 컴퓨터 쪽 학과 계열이 므흣하게 나뉘어 있었다. 통합된 컴퓨터공학부라는 게 생긴 것은 1990년대 말 내지 21세기에 들어와서이다. 덧붙이자면, 연세대 역시 컴퓨터과학과라는 이름이 생긴 건 2005년부터이고 그 전엔 정보산업공학이라고 하여 이쪽으로의 분류가 모호했다.
IT 붐과 함께 지금은 당연시되고 있는 학과 이름이 비교적 최근까지도 일류대급에 속하는 대학에도 없었던 게 의외이다. 어쨌든, 이 교수 역시 당시는 서울대 계산통계학과를 졸업했다.

이분의 설파 교리(?)와 연구 분야는 이러하다.
먼저, 기계 중심적이지 않고, 수학적으로 더 엄밀하며 인간의 사고와 논리를 더 자연스럽게 표현할 수 있는 프로그래밍 언어를 지향한다. 사실, C/C++이나 자바는 오늘날의 최신 프로그래밍 언어 이론이나 방법론이 반영된 깨끗한 언어가 아니다.

그래서 이런 전산학 순수주의자(?)는 특별히 람다 대수에 기반한 OCaml이나 최소한 Scheme 같은 함수형 언어를 선호한다. 함수가 마치 일반 상수처럼 코드 중간에서 별다른 작명 없이도 자유롭게 만들어지고 값처럼 다뤄질 수 있다.
이게 좋은 패러다임이기 때문에 심지어 C++도 C++0x에서는 함수 포인터를 대체할 만한 람다 대수 문법이 추가되었으며, 비주얼 스튜디오 2010에서는 F#이라는 함수형 프로그래밍 언어가 새로 도입되었다. 이것은 의미심장한 변화이다.

그리고 이 교수가 연구하는 정적 분석이란, 프로그램을 실제로 실행해 보지 않고, 그 구조를 뜯어보기만 하고서 이 프로그램이 잠재적으로 배열 첨자 초과 오류나 메모리 누설 따위가 발생할 수 있겠다고 진단을 내리는 기술을 말한다. 사실, 좋은 프로그래밍 언어란, 컴파일러만 통과한 프로그램이라면 뻗지 않고 잘 돌아간다는 보장이 되어야 하고 컴파일 시점 때 해당 코드에 존재하는 잠재적인 모든 문제를 찾아낼 수 있어야 한다는 것이 이분의 지론이다.

이게 가능할까? 입력은 키보드나 파일로 들어오고 메모리 할당과 해제가 일어나는 통로가 주어져 있을 때, 복잡한 루프와 배열, 함수 재귀호출, 다중 포인터 로직을 추적하면서(프로그램을 실행하는 게 아니고!) 딱 보고 이 코드는 구조적인 문제가 있다는 걸 찾아내는 게 과연 쉬운 일일까? ㅋㅋ

당연히 머리가 터져나가게 어려운 일일 것이다.
하지만 그게 가능하기만 하다면 프로그램을 일일이 실행해 보는 것보다 훨씬 더 꼼꼼하고 확실한 검증이 행해질 수 있다. 자동차를 실제로 만든 뒤에 충돌시켜서 부숴 보지 않고도 디자인만 딱 보고 운전자의 안전에 어떤 문제가 있겠는지 예측하는 것과 비슷한 맥락이지 않은가.

사실, 프로그램 정적 분석과 뿌리를 공유하는 가장 원초적인 문제는, 바로 전산학에서 다루는 정지 문제(halting problem)이다. 이는 오늘날의 컴퓨터 모델인 튜링 기계에서는 100% 완벽하게 푸는 게 애시당초 불가능하다는 게 증명되어 있다.

이런 맥락에서 프로그램 정적 분석기 또한 100% 완벽하고 정확하게 동작하는 건 불가능하다. 실제로는 문제가 있는 부분이 아닌데 문제가 있다고 진단하는 false alarm도 존재한다. 그 이상 더 정밀하게 동작할 수는 없기 때문.

그래도 이것만으로도 어디냐. C/C++은 성능이 무지막지하게 좋은 대신, dangling pointer, memory leak, buffer overflow 등 이름만 들어도 치를 떨 무시무시한 버그와 보안 문제들에 무방비로 노출되어 있는 chaotic한 언어가 아니던가? 전산학 전공자는 소프트웨어 공학 시간에 익히 배워 알듯, 소프트웨어 개발이란 건 그렇잖아도 작업의 절대적인 양과 질을 측정하기가 어려운 분야이다. 그러니 소스 코드를 정적 분석으로 검증하는 시스템이 없이는 IT 산업계가 제대로 돌아갈 수가 없다. 그렇지 않으면, 어디서 뻑이 날지 모르는 C/C++ 언어로 의료 기기나 우주선 같은 크리티컬 시스템을 만들거나 사용하려면 미리 보험이라도 들어 놔야 하지 않을까 싶다. 진짜로. -_-;;

이런 복잡도를 제어하는 시스템을 연구하는 게 이 광근 교수의 목표이다.
그분은 이걸로 이미 저명한 학술지에 적지 않은 논문을 냈고, 소프트웨어 검증 솔루션을 개발하여 기업체에 납품했다.

사실, 비주얼 스튜디오도 일반인이나 학생이 사용하는 라이선스 말고 제일 비싼 엔터프라이즈급 라이선스 제품을 써 보면, 소스 코드 정적 분석 기능이 들어있다.
기회가 되면 내가 개발한 프로그램도 그런 걸로 한번 좀 분석해 봐야 할 텐데 말이다. 메모리나 GDI 개체, 커널 핸들 등 해제가 필요한 자원들은 전부 클래스 소멸자가 처리하게 바꾸고, 지속적인 개량과 코드 리팩터링을 해 왔기 때문에 그런 초보적인 실수는 이제 없으리라 여겨진다만, 이걸 시스템 차원에서 깔끔하게 입증을 못 하고 있다는 게 문제이긴 하다.

코드를 실행하지 않고 척 들여다보기만 한 뒤 그 코드로부터 문제될 만한 부분을 알아서 찾아 내는 것은 활용 가능성이 굉장히 많다. 마치 공항 검색대가 가방을 열어 보지 않고 사생활 침해 걱정이 없이 비행기에 실을 수 없는 물건을 찾아내는 것처럼 말이다. 이 얼마나 유용한 기술인가?

이 광근 교수는 자기 연구 분야를 차치하고라도, 독특한 스타일의 강의 자료나 여러 글들을 읽어 보면, 가히 공부의 본질을 아는 사람이며 정말로 보통사람이 아니다 싶은 면모가 여럿 느껴진다. 특히 이분은 우리말로 학문하기에 대한 관념이 굉장히 투철한 걸로 잘 알려져 있다.

• “MIT라는 이름은 본토 사람들이 보기에는 그냥 황해도 과기원 정도로밖에 들리지 않으며, 떼제베도 프랑스 원어민에게 다가오는 의미는 단지 매우 빠른 열차일 뿐이다. 우리만 혼자 폼나 보인다고 외래어 알파벳을 남발하고 있다.”
• “비록 어떤 개념이나 기술이 외국에서 유래되었다 하더라도, 그 원판을 능가하는 학문적 성과는 언제나 모국어를 통해서만 이뤄져 왔다.”

외래어는 싹 다 배격하고 정확· 엄밀함을 희생해서까지 무조건 뭉뚱그려서 순우리말만 쓰자는 국수주의 주장이 절대 아니며, 오히려 완전히 다른 차원에서의 주장이다.
작년에 한창 카이스트가 자살과 영어 강의 때문에 시끄럽던 시절에 이분은 자기의 지론을 다시 한데 정리한 개념글을 하나 교수신문에다 기고했다. 그 후 이 글은 전산 비전공자, 심지어 인문학 하는 사람들에게서도 인용되고 폭풍처럼 칭송받고 있는 중이다.

IT 쪽 최정상에 앉아 있는 사람이 이례적으로 용어 순화와 모국어 강의를 옹호하니 뜻밖이지 않은가? 저 글에 딱히 정치색이 있는 건 물론 전혀 아니지만, 영어 강의, 세계화 이런 것들을 반대하고 이념적으로 진보 성향이 좀 있는 사람들이 더욱 지지를 하는 경향이 있었다. 예를 들어 조 국 교수도 그 글을 완전 극찬한 바 있다.

카이스트 교수 부임 시절에 이 교수는 학과 이름을 전산학과에서 컴퓨터xx학과로 바꾸는 것도 괜히 쓸데없는 일이라고 만류한 적이 있다. ACM, IBM의 M은 완전 구닥다리 용어인 '기계'라는 뜻이지 않냐고 말이다.

그리고 대학 캠퍼스 내부의 건물들을 초행자도 식별하기 쉽게 번호가 좀 있어야 한다고 제안하신 바 있다.
그 제안 때문인지 이분이 서울대로 전근 가신 뒤에 얼마 안 되어(2004~2005년쯤 아마?) 카이스트도 건물들에 N0, E0, S0 같은 식으로 번호가 붙었다.
서울대는 워낙 건물이 많고 내부가 복잡해서 진작부터 그런 게 있다.
연세대는 그런 거 없다. 본교 도입이 시급합니다.

지금이야 카이스트 전산학동이 수 년 전부터 몇 층 더 증축되었지만, 그 당시에 이 광근 교수는 아마 공간 부족으로 인해 전산학동이 아닌 이웃 산업공학동에 연구실이 있었다. 그리고 이런저런 어른들의 사정이 더해져서 그분은 서울대로 전근을 가신 걸로 추정된다. 비슷한 시기에 전산학과의 김 태환 교수도 서울대로 가셨다.

이분의 수업은 진짜 그냥 온갖 기호와 공식, 증명이 즐비한 수학 덕후식이며 빡세다..;;;
그래서 카이스트 재학 시절, 내게는 좀 굴욕적인 기억이 있다.
C++의 사고방식에 완전히 중독되다시피하던 내 머리 구조로는 nML이네 뭐네 하는 “프로그래밍 언어 PL” 수업을 도저히 따라갈 수가 없어서... 전공 필수 과목일 뿐만 아니라 전근을 앞둔 스타 교수의 마지막 수업을 드랍하고 말았다. 2003년 봄 학기의 일이다. 그것도 수강 변경도 아닌 철회 기간에 출혈을 감수하며 드랍.

난 그 당시 <날개셋> 한글 입력기 2.x와 3.0의 개발과 직접적인 관련이 있지 않은 복잡한 추상화 계층이나 뜬구름 잡는 이론에는 머리가 전혀 돌아가지 않던 시절이었다. 동기 부여를 받으면 철도 덕후 수준으로 머리가 미쳐 돌아가지만, 동기 부여가 없는 곳에는 난 담을 확 쌓아 버리고 죽어도 관심 안 보인다. 역시 난 프로그래밍으로 다른 창의적인 작품을 만드는 게 삶의 목적이지, 프로그래밍 패러다임 자체를 바꾸는 일은 내 적성이 아니라는 걸 알 수 있었다. C++보다 더 엄밀하고 깔끔한 프로그래밍 언어로 수학 덕질하는 것보다는, 당장 윈도우 API로 옛한글과 세벌식 모아치기를 구현하는 것에만 온통 관심이 쏠려 있어서..

그래서 나중에 한 태숙 교수의 PL을 다시 들었다. 이분의 PL 수업이 그나마 내가 생각했던 PL 수업에 더 근접한 평범한(?) 것이었고, 들을 만했다.;; 각종 프로그래밍 언어들의 특성과 개념, 값의 평가 시기, LL 파서, LR 파서, garbage collector의 동작 원리 등등.. 참고로 덧붙이자면, 내가 예전 글에서도 소개한 적이 있듯 한 교수 역시 왕년에 1등을 놓친 적이 없었고 대입 학력고사 전국 수석을 차지했던 공부 만렙 괴물이다.;;

현재는 카이스트 전산학과의 류 석영 교수가 과거 이 광근 교수의 제자이며, 그분 뒤를 이어 카이스트 프로그래밍 언어 연구실을 공동 운영하고 있다(한 태숙, 최 광무 교수와 같이).
류 교수의 증언에 따르면 이 교수 연구실은 말도 못 하게 무지막지하게 빡세기 때문에, (그 대신 잘 적응하면 얻는 것도 많겠지);; 어지간한 각오가 돼 있지 않다면 그분 연구실로 대학원 진학을 하는 건 비추라고 한다. =_=;;;
그래도, 좀 까칠한 것만 빼면 교수님은 학자로서 정말 좋은 분이라고.. ㅜㅜ

어쨌든 이 광근 교수. 수업 하나 들은 적도 없이 헤어졌지만, 이런 식으로 내 기억에 남아 있다.
본인이 이분에 대해 수집한 모든 정보들의 출처는 당연히 그분의 공식 홈페이지이므로, 관심 있으신 분은 방문해 보시라.

Posted by 사무엘

여러분 중에 혹시 옛날에 Alley Cat이라는 아래의 완전 구석기 시대 게임을 해 보신 분이 있는가?

난 해 봤다.
전설의 카세트테이프까지 접하지는 못했지만, 그래도 1990년대의 16비트 IBM 호환 PC의 발전은 다 지켜본 세대이기 때문이다.

저 게임의 제목은 우리말로는 딱 ‘도둑고양이’라는 뜻이다.
내가 갓난아기이던 1984년에 만들어진 게임이요, (PC용이 1984년. 8비트 Atari용 원판은 1983년에!)
6만 바이트가 채 안 되는 실행 파일 하나에 게임에 필요한 모든 코드와 데이터가 다 들어있다.
실행하면, 도.도. 시.시. 라~시라솔... 로 시작하는 그 중독성 있는 음악이 나온다.

실행 파일을 들여다보면,

This program requires a color graphics adapter.

라는 문자열이 있다.
This program requires Microsoft Windows도 아니고(과거에 윈도우 3.x용 프로그램이 도스에서 실행되었을 때 뜨던 실행 거부 메시지), VGA도 아니고.. 컴에 CGA가 없을 때 출력해 줄 에러 메시지가 들어있다니 도대체 얼마나 옛날 게임인 걸까? 320*200 4색짜리 그래픽 ㅋㅋ

이 게임을 만든 사람은 Bill Williams (1960-1998)라는 분이다. 정확히 말하면, John Harris라는 다른 프로그래머가 만들다 만 것을 이어받아서 자기 식으로 완수한 거라고 함.

아주 흔하고 동명이인이 많은 이름이긴 한데, William의 애칭이 Bill 아니던가? 그럼 동일 이름 중복?

그야말로 20대 초중반의 나이에 그 열악한 하드웨어에서 어셈블리 코딩만으로 저렇게 고양이가 뛰어다니는 세계를 창조했다는 게 심히 놀랍지 않을 수 없다.
참고로 존 카맥(John Carmack)이 Doom 엔진을 만들어 낸 나이도 저 때와 비슷하다. 다들 25세가 채 되기 전이다! 천재들은 다 그 나이 때 이미 세상에 이름을 남긴다.

저 게임은 솔직히 내 취향은 아니었다. 나는 아케이드· 플랫폼 게임을 좋아하는 편이지만, HP가 없이 즉사하는 시스템을 별로 안 좋아했다. (사람을 조마조마하게 만들고 놀라게 해서-_-) 그리고 맨날 빗자루에 걷어 채여 날아가는 고양이가 좀 불쌍했다. 드럼통에서 창문 빨랫줄로 올라가려고 하는데 그때 딱 창문에서 떨어지는 물건에 이따금씩 맞는 게 싫기도 했고.

하지만 게임의 세계관이 심히 창의적이고 독특한 건 사실이다. 게임은 몰입도가 상당히 높다. 게임 속의 고양이는 끊임없이 움직이지 않으면 안 된다. 길바닥에서 고양이가 좀 지체하고 있으면 개가 달려와서 고양이를 죽인다. 드럼통에도 너무 오래 있으면 밑에서 괴물 머리가 툭 튀어나오면서 고양이를 밑으로 쫓아낸다. 방에 들어가서도 안심할 수 없다. 빗자루의 방해를 안 받고 미션을 완수하려면, 주기적으로 계속 바닥을 돌아다니면서 흙먼지를 묻혀 줘야 한다. 고양이가 좀 발 붙이고 쉴 틈이라곤 없다.

보글보글만큼이나 게임에 갑툭튀하는 랜덤한 요소가 많다. 화살표 키도 어떻게 조작하냐에 따라 고양이의 이동 속도와 점프 방향이 생각보다 다양하게 바뀐다. 나름 머리를 써서 만들었다는 흔적을 느낄 수 있다. PC 스피커만으로 상당히 정교하게 합성해 낸 효과음도 일품.

이 게임은 딱히 엔딩이 없어서, 퀘스트를 달성해서 암고양이를 만난 뒤에도, 진행 속도와 난이도만 더 올라간 채 게임은 한없이 반복되었다. 또한 원래 PC가 아닌 게임기용으로 만들어져서 그런지 PC 버전도 종료 기능이 없었기 때문에, 나중에는 컴퓨터를 그냥 끄거나 Game Wizard 같은 유틸리티의 Crash back to DOS 기능을 사용해서 빠져나가야 했다.

난 Bill Williams의 작품이라고는 Alley Cat밖에 알지 못하지만, 외국에 있는 어느 고전 게임 개발자 열전 사이트에서는 그를 1980년대를 풍미한 천재 게임 개발자라면서 게임 디자인계의 ‘스탠리 큐브릭’이라고 칭송하고 있다. “His games are completely original and stunning.”

그는 1990년대에는 게임 개발을 완전히 접고, 뜻밖의 진로를 선택했다.
기독교 신자였던 그는 목회를 할 의향으로 시카고에 있는 루터 신학교에 돌연 입학하여, 1994년에는 신학 석사 학위를 받았다.
재학 중에도 성경 탐구에 대한 열의가 남다른 우수한 학생이었다고 한다.

(下에서 계속됨)

Posted by 사무엘

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

예를 들어, 마포 대교를 건넌 후 내비가 시킨 대로 강변북로의 동쪽 방면으로 정상적으로 진입하는데도, 내비는 이 무렵에 늘 경로를 벗어났다는 경고음을 내고 경로를 또 수정하곤 했다. 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 사무엘