아무리 로딩 시간이 길고 덩치가 큰 프로그램이라 하더라도, 한번 실행했다가 종료한 후 그 프로그램을 즉시 다시 실행하면, 예전보다 훨씬 더 빨리 실행된다. 이때는 사실 디스크 액세스 자체가 거의 일어나지 않는다. 이는 상식적으로 알 수 있듯, 운영체제가 디스크 액세스에 대한 캐싱(cache)을 똑똑하게 잘 해 주기 때문에 그렇다.

컴퓨터 내부는 양극화 내지 80/20 법칙이 잘 통용되는 세계이다. CPU 명령이든 디스크 액세스든, 메모리 액세스든, 병목 현상은 꼭 일어나는 곳에서만 몰아서 집중적으로 일어난다. 한번 액세스된 자료는 다음에 또 액세스될 가능성이 높다. 그리고 그 인근의 자료가 덩달아 액세스될 가능성이 높다. 컴퓨터 아키텍처를 연구하는 사람들의 관심사 중 하나는, 이런 캐시 적중률을 높여서 컴퓨터의 성능을 끌어올리는 것이다.

그러나 지금은 당연시되고 있는 디스크 캐시가 옛날 도스 시절에는 전혀 당연한 개념이 아니었다. 아까 전이나 지금이나 동일한 파일을 읽고 쓰는 시간은 언제나 동일-_-했다. 캐시 프로그램은 별도의 램 상주 유틸리티로 제공되곤 했다. 사실, 그때는 메모리 값이 비싸서 디스크 캐시를 위해 수 MB의 메모리를 떼어 낼 여건이 되는 브루주아 계급 자체가 별로 많지 않았었다. ^^

디스크 캐시 유틸이 하는 일은 대략 다음과 같을 것이다.
1. 파일을 읽을 때 인접한 내용도 미리 읽어 둔다.
2. 한번 읽은 내용은 메모리에 저장해 놓고 나중에 디스크를 액세스하는 일이 없이 써먹는다.
3. 쓰는 것은 지금 몰아서 다 하지 않는다. 쓰기 작업을 다 완료하지 않았지만 일단은 다 했다고 빨리 응답해 주고, 나머지 작업은 CPU가 쉬고 있을 때 조금씩 한다.
그러니, 읽은 내용을 효율적으로 관리하는 것과, delayed writing 때문에 메모리와 디스크의 실제 상태가 일치하지 않을 때 이를 동기화하는 방식 같은 게 캐시 프로그램 개발의 핵심 기술이라 할 수 있다.

물론 읽기 캐시는 그렇다 쳐도, ‘delayed writing’라는 동작 방식은 위험할 수도 있다는 경고도 접했다. 메모리에 있던 캐시 내용이 디스크에 실제로 반영되기 전에 컴퓨터가 꺼져 버린다면? 흠좀무.

MS 도스는 SMARTDRV라는 유틸리티를 제공했으며, 윈도우 9x에도 이놈이 있다. 이 프로그램이 다른 경쟁 프로그램들과 비교했을 때 성능이 어땠는지는 모르겠지만 이 정도만으로도 마법과 같은 프로그램이었다. 하드웨어를 바꾸지 않고도 디스크 체감 액세스 속도가 엄청나게 빨라졌으며, 특히 크기가 작은 다수의 파일을 다룰수록 성능 향상 정도는 폭발적이었다.

심지어는 운영체제 설치하기 전에 smartdrv를 띄워 놔도 설치 시간이 단축되고 효과가 좋다고 명시가 되어 있다. 디스크 캐시는 가상 메모리라는 개념과 맞물려서, 현대 운영체제가 RAM의 속도와 하드디스크의 용량을 적절하게 잘 절충하여 사용자에게 최적의 성능을 제공하는 데 꼭 필요한 개념이 되었다.

윈도우 비스타(와 그 후속 포함)는 예전보다 더욱 과감하게 캐싱을 한다고 한다. 값싸고 풍부한 메모리를 디스크 캐싱용으로 적극 활용한다. 심지어 수십 MB짜리 비주얼 스튜디오 2008도 몇 번 껐다가 켜면 나중에는 디스크를 전혀 액세스하지 않고 실행된다. 마치 램드라이브처럼 말이다. 그러니 빨라졌다는 느낌이 들 수밖에 없다. 캐싱용으로 쓰는 메모리는 운영체제가 점유 중인 메모리 양으로 쳐 주지도 않는다. 사용자가 원하면 언제라도 용도 변경이 가능한 메모리이기 때문이다.

반대로, 램 용량이 부족하면 컴퓨터는 그야말로 지옥이 된다. 캐시 혜택은커녕, 이미 램으로 액세스하던 것도 전부 디스크 상의 스왑 파일로 다루게 되기 때문이다.

그러고 보니 과거에는 네트워크 드라이브도 아니고 아예 램드라이브라는 게 있었다. 비록 용량이 부족하고 저장 효과가 영구적이지도 못하지만, 이것이 광속으로 디스크를 액세스하는 효과를 내는 방법 중 하나이기도 했다. 지금은 그런 게 있으려나?

또 하드디스크를 write-protect하는 유틸리티도 있었다. ㅎㄷㄷ;; 그러나 이 역시 메모리와 디스크가 일체로 가상 메모리를 이루는 오늘날의 운영체제 하에서는 완전히 흑역사가 된 지 오래이고, 그 대신 얼추 비슷한 개념을 사용자 계정 컨트롤이 대신 담당하고 있다. 도스 시절 만세이다. ^^;;

Posted by 사무엘

2010/07/05 08:30 2010/07/05 08:30
, ,
Response
No Trackback , 4 Comments
RSS :
http://moogi.new21.org/tc/rss/response/311

인스톨쉴드 싫어

오늘은 설치 프로그램이라는 주제로 이야기 보따리를 풀어 보겠다.

과거 도스+윈도우 3.1 공존 시절에는
도스용 프로그램들은 어떤 소프트웨어의 설치 프로그램의 이름은 대개 install이었던 반면,
윈도우용 프로그램들은 어찌 된 영문인지 다들 setup이었다.
그리고 그 시절에 윈도우용 설치 프로그램들은 전체 화면으로 파랑-검정 그러데이션이 배경으로 쫙 깔리는 게 유행이었다. 그러면서 화면 좌측 상단엔 큼직한 흰색 글씨로 "무슨무슨 프로그램 설치/Setup"이 떴지. (짤방은 귀찮아서 생략-_-)
이걸 기억한다면 당신은 진정한 old timer.

그러다가 윈도우 95가 보편화하면서 전체 화면 배경은 그냥 옥색(cyan) solid로 바뀌었다.
MS 오피스 97과 아래아한글 97의 설치 프로그램이 그런 모양이었다.

그러나 그때와 지금의 근본적인 차이는.. 이제 설치 프로그램은 더는 전체 화면을 점유하는 형태로 실행되지 않는다는 것이다. 유행이 확 바뀌었다. 그냥 간단한 마법사 대화상자 하나만 달랑 뜨는 형태로 극도로 간소화됐다. 소프트웨어 설치가 무슨 게임 실행도 아니고... 그 정도로 유세 부릴 프로세스는 아니게 되었다는 의미.

MS 제품의 경우 Windows Installer 기술이 최초로 도입된 오피스 2000부터 설치 프로그램 UI가 싹 바뀌었으며, 아래아한글 역시 2002부터는 설치 프로그램이 마법사 대화상자 하나만 달랑 나올 뿐 전체 화면으로 뜨지 않는다.

사실 소프트웨어의 규모가 복잡해지고 한 제품도 온갖 버전 구분이 존재하게 되면서,
제대로 된 설치 프로그램을 만드는 것도 굉장히 골치 아프고 까다로운 일이 돼 있다.
단순히 파일을 복사했다가 지우는 것 이상이다. 예를 좀 들자면,

- 동일 제품의 여러 버전이 공존하고 이들이 다 한데 공유하는 파일이 있는데 이 파일은 언제 제거해야 하나? 그런 거 체크 리스트를 어떤 자료구조로 구축해야 하나?
- 그런 자료구조가 깨졌을 때 최대한 복구는 어떻게 하면 좋을까? 그리고 확장자 연결 복구는?
(사용자는 1.0과 2.0 중 어느 걸 먼저 설치할 수도 있고, 그 후 2.0과 1.0 중 어느 걸 먼저 제거할 수도 있다. 프로그램 설치/제거는 획일화된 스택이나 큐 구조가 아님. ㅋㅋ)
- 지금이 이전에 설치를 진행하다가 중단된 상태였는지 판단은?
- 지금 당장 건드릴 수 없는 파일을 건드려야 돼서 그걸 다음 재부팅 때 하도록 예약해 놓은 게 있나?

글 쓰면서 당장 떠오르는 복잡도만 생각해도 저 정도이다.
특히 재부팅 때 건드릴 파일을 예약하는 기법이나, 지금 실행돼 있는 프로그램 목록을 얻는 방법은.. 설치/제거 프로그램을 만들 때 반드시 필요한 동작임에도 불구하고 과거에 윈도우 9x과 NT 계열이 테크닉이 서로 완전히 달랐다. 유니코드 지원 여부 같은 차이도 존재하고.. 그러니 짜증 두 배.. -_-

예전에도 글을 쓴 적이 있지만, uninstall 프로그램을 만들 때 필요한 것이, 바로 자기 자신을 제거하는 기법이다. 윈도우 운영체제는 그 특성상 실행 중인 EXE/DLL은 운영체제가 memory-mapped file로 대응시켜 잡고 있기 때문에, 자신을 제거할 수 없다.
하지만 배치(일괄 처리 bat) 파일은 DEL 명령으로 자신을 제거할 수 있다. 그래서 EXE를 제거한 뒤 자기 자신을 제거하는 비밀 배치 파일을 만들어 실행하는 기법으로 자신을 제거하곤 한다. 리눅스나 맥은 사정이 어떤지 모르겠다.

이런 저런 사항도 있고, 아무튼 프로그램 설치/제거 및 버전 관리 기법은 어느 소프트웨어에서나 공통적으로 쓰이는 개념/테크닉만 뽑아내서 운영체제 차원에서 책임을 져 준다거나 어느 잘 만들어진 미들웨어를 쓰는 게 효율적이다.
그래서 진작부터 프로그램 설치/제거 솔루션이 나와 있었다. 가장 역사가 긴 녀석은 역시 InstallShield이다. 지금은 비록 위상이 옛날 만하지는 않고 Windows Installer의 단순 wrapper 수준처럼 된 것도 있지만.. 그래도 대형 상업용 소프트웨어에서 이게 여전히 쓰이고 있기도 하다.

InstallWise도 아마 윈도우 3.x 시절부터 건재했던 외산 솔루션이고, 국산 프로그램인 InstallFactory는 <날개셋> 한글 입력기의 2.0~2.4 시절에 잠시 도입된 적이 있다.
DeployMaster라는 제품도 있고, 아.. 그나저나 요즘 전세계적으로 가장 널리 쓰이는 솔루션은 역시 Nullsoft의 NSIS인 것 같다.
소프트웨어의 설치 프로세스라는 건 단순 파일/복사나 버전 체크 같은 아주 공통적이고 범용적인 동작도 있지만, 또 각 소프트웨어가 필요로 하는 customize 수준도 천차만별이라는 특성도 존재한다. 그러니 그런 것도 잘 살려 줘야 하면서도 최대한 배우기 쉽고 구조가 간단해야 한다.

<날개셋> 한글 입력기는 2.5 이후 버전부터 지금까지는 그냥 비주얼 스튜디오가 기본 제공하는 msi 생성 프로젝트를 이용하여 배포 패키지를 만들고 있다. AppLocale 버그(이건 뭐 MS가 만든 프로그램들끼리 충돌하는 문제-_-)도 있고, 다국어 UI도 지원 안 되는 등 좀 마음에 안 드는 면모가 없는 건 아니나, 일단 7년에 가까운 세월 동안 설치/제거 자체가 딱히 큰 트러블 없이 되는 게 검증이 되어 왔기 때문에 쓴다. 민감한 부위인 외부 모듈까지도 말이다.

또한 MSI 런타임 2.0은 윈도우 95/NT4에서도 무난하게 잘 동작한다는 점도 큰 이점이다.
사실 Application Data 같은 일부 known 디렉터리는 IE4 이전의 윈도우 95 초창기에는 없던 개념인데, MSI 런타임 2.0은 설치 과정에서 그런 디렉터리에 대한 정보도 레지스트리에다 넣어 준다. (<날개셋> 한글 입력기의 동작에 필요)

다만, 본인도 InstallShield와 Windows Installer에 대해서 그렇게 좋은 인상을 갖고 있지 않다는 점을 밝히며 글을 맺는다.
99%까지 게이지가 금세 꽉 찬 뒤, 그 뒤로 몇 분째 꼼짝도 안 하는 훼이크성 대화상자에 짜증 게이지가 확 치솟아서이다. ㅆㅂ.. 도대체 설치도 아니고 설치 준비 작업이 뭐 이렇게 오래 걸리나 모르겠다.

개발툴인 비주얼 스튜디오 2005도 2003보다 제품의 완성도는 올라갔다지만, 설치에 관한 한 정말 답이 안 나오는 제품이다.
서비스 팩 1 설치하는 시간이 2005 자체를 첫 설치하는 시간보다 더 길면 길지, 절대로 더 짧지 않다. 도대체 그 시간 동안 뭘 하는지 모르겠다.
거기에다가 윈도우 비스타 내지 7에서 쓰려면 SP1에다가 또 운영체제 패치도 설치해야 한다. 이거 뭐 해처리 → 레어 → 하이브로 올리는 정도의 시간이 걸린다.

비스타/7부터는 그냥 닥치고 2008 이상을 쓰라는 소리. 비주얼 스튜디오 2008이 나오자마자 바로 갈아탔다.
사용자에게 좋은 첫인상을 주는 설치 프로그램을 만드는 것도 중요하다.

Posted by 사무엘

2010/05/11 08:14 2010/05/11 08:14
,
Response
No Trackback , 8 Comments
RSS :
http://moogi.new21.org/tc/rss/response/265

1.
엑셀에는 셀 안에다 긴 텍스트를 집어넣은 후, ‘자동 줄 바꿈(wrap text)’을 적용하여 내용이 여러 줄에 걸쳐서 출력되게 하는 기능이 있다.

그런데 이 기능은 굉장히 괴상하게 구현되어 있다. 엑셀이 제공하는 ‘자동 줄 바꿈’ 기능은 위지윅이 전혀 보장되지 않는다. 문서의 확대 배율만 바꿔도(셀이나 문서의 폭, 심지어 프로그램 창 크기도 아니고) wrap 결과가 뒤죽박죽으로 바뀌고, 화면으로 보는 결과와 인쇄 결과도 당연히 일치하지 않는다.

이런 이유로 인해 화면상으로는 3줄로 wrapping이 됐는데 인쇄해 보니 문장이 2줄에 다 들어가서 마지막 한 줄은 텅 비기도 하고, 화면상으로는 딱 맞는 크기였는데 인쇄하니까 칸이 부족하여 숫자가 ####로 바뀌어 출력되기도 한다. 엑셀을 직업적으로 다루는 분이라면 이런 특성에 대해 이미 잘 알고 있을 것이다.
이건 워드 프로세서라면 상상도 못 할 현상일 텐데, 왜 이런 것일까?

엑셀은 잘 알다시피 표 형태의 데이터를 전문적으로 다루는 프로그램이다. 워드 프로세서처럼 소숫점 단위로 위지윅을 보장하면서 정확한 페이지 정돈과 문단 정렬에 최적화되지는 않은 듯하다. 성능상의 이유로 인해 그냥 정수 픽셀 단위로 줄을 wrap하니, 화면 배율만 바꿔도 문단 정렬 결과가 확 달라지는 것이다. 글자 크기뿐만 아니라 셀의 크기까지 동일한 비율로 바뀌는데도 말이다.


2.
플래시 메모리 스틱으로 전파/감염되는 악성 코드는 정말 심각한 수준에 도달한 것 같다.
(카드는 아니고.. 플래시 메모리는 말이 좀 길고, 그렇다고 USB라고 부르는 건 너무 심했고-_-.. 적당한 말이 없어서 고민인데, 이 글에서는 편의상 그냥 스틱이라고 부르겠다.)

내 스틱을 남 컴퓨터에다 꽂았다가 다시 갖고 오니 루트 디렉터리에 지저분한 dll, bat-_- 파일이 묻어 있다거나, 남의 스틱을 내 컴에다 꽂아서 파일을 보니 역시 괴파일이 숨김 속성으로 들어있다.
당연히, 내 스틱을 내 컴퓨터들끼리만 쓰면 그런 현상 없다. 그런데 지금까지 저런 경우를 한두 번 본 게 아니어서.. 도대체 악성 코드에 감염된 컴퓨터가 얼마나 되는지 감을 못 잡겠다.

저게 어떻게 기술적으로 가능한지 궁금할 따름이다. 어떻게 나의 동의도 없이, 악성 코드에 감염된 컴에다 내 스틱을 꽂았다는 이유만으로 루트 디렉터리에 저런 파일들이 복사될 수 있을까?
옛날에도 글로 썼지만 본인은 컴퓨터 보안에 관한 한, 굉장한 안전 불감증의 소유자이다. 지금까지 단 한 번도 사고가 안 났지만, 사고가 났을 때의 대처 능력 역시 검증된 적이 없는 일본 신칸센과 같은 상태이다. 이러다가 소 잃고 외양간 고치려나..;;

구글이라든가 크롬 웹브라우저가 특히 국내 포털 사이트 내부에 대해서 "이 사이트는 안전하지 않습니다" 경고 내는 것도 굉장히 귀찮아하고 싫어한다. 잘만 드나들고 지냈으며, 그러고 나서도 아무 일도 없었는데 양치기 소년 같은 인상을 받기 때문이다. 첨부 파일, ActiveX 설치 절대 안 하는 사람에게 도대체 뭐가 안전하지 않다는 건지 모르겠다.

요즘도 하는지 모르겠는데, 생활 안전을 소재로 무슨 '에듀테인먼트' TV 프로가 있다.
헬멧을 썼을 때와 안 썼을 때 사람이 다치는 정도의 차이를 비롯해, 음식을 태운 냄비를 물로 식혀서는 안 되는 이유 등을 생생한 실험으로 보여주는데,
그것처럼 보안/업데이트를 전혀 하지 않은 컴퓨터가 어떻게 뚫리고 어떻게 악성 코드에 감염되는지 그런 실험 결과를 보여주는 TV 프로가 좀 있었으면 좋겠다. 나는 도무지 실감이 안 간다.

Posted by 사무엘

2010/03/23 10:15 2010/03/23 10:15
, ,
Response
No Trackback , 8 Comments
RSS :
http://moogi.new21.org/tc/rss/response/220

« Previous : 1 : 2 : 3 : 4 : Next »

블로그 이미지

그런즉 이제 애호박, 단호박, 늙은호박 이 셋은 항상 있으나, 그 중에 제일은 늙은호박이니라.

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2023/03   »
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31  

Site Stats

Total hits:
2078330
Today:
397
Yesterday:
1062