인스톨쉴드 싫어

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

과거 도스+윈도우 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

Trackback URL : http://moogi.new21.org/tc/trackback/265

Comments List

  1. 땅콩맨 2010/05/11 08:46 # M/D Reply Permalink

    인스톨쉴드 이야기가 나오니
    고등학교때 알바했던 회사에서 인스톨쉴드로 설치프로그램 구성하라는 작업
    을 맡긴게 생각이 나는군요. 그때 C++ Builder로 만든 프로그램을 구성하는 작업이었는데, BDE가 포함되어 있어서 위에 실무진들이 잘 안된다고(잘 안되는건지, 귀찮아서 그랬는건지는 모르겠지만. ㅡ,.ㅡ) 맡겼는데 하루종일 붙잡고 둑닥둑닥, 쿵쾅쿵쾅 하니깐 결국은 되더라고요.

    예전에 델파이 컴포넌트중에서 차량게이지 컴포넌트도 있었고
    (Delphi 1.0 설치할때 나오는 화면이랑 비슷한 컴포넌트)
    설치프로그램을 개발자가 직접 만드는것도 나쁘진 않을것 같다는 생각입니다

    아참
    해처리 → 레어 → 하이브로로 올라가는 비유, 정말 인상적이네요~
    오늘하루도 즐프하시길...

    1. 사무엘 2010/05/11 10:10 # M/D Permalink

      꺅, 데.. 델파이 1 ㅎㄷㄷㄷ... 맞아요, 설치 중에 자동차 대시보드 그림과 함께 속도계 바늘이 올라갔죠 그죠? (다른 볼랜드 C++ 4.x 같은 제품들도 그랬던가?)
      저는 델파이 쪽으로는 인연이 없었는지, 중딩 때 무려 16비트 버전인 1만 써 보고 그 후 버전은 전혀 못 접해 봤습니다. 정말 오랜만..!

      엄청 옛날부터 알바 뛰어 오셨군요. 게다가 말로만 듣던 인스톨쉴드 스크립트까지 직접..;
      저는 설치 프로그램을 직접 만든 건 비주얼 스튜디오 IDE가 제공하는 msi 패키지 내지.. NSIS 정도밖에 없습니다. 쉴드는 일단 너무 복잡해서 건드릴 엄두가 안 나더군요. (아마 제 한글 입력기에 대해서도 딱 이런 인상 받은 분들도 엄청 많겠지만. -_-)
      어쨌든 설치 솔루션 만드는 사람들은 꼼꼼하고 완성도 높은 제품을 만드는 것도 중요하지만, 소프트웨어의 첫인상인 만큼 사람 덜 짜증나게 만드는 UI 제작에도 심혈을 기울여야 할 것입니다. ^^

  2. 다물 2010/05/11 15:20 # M/D Reply Permalink

    전 윈도우 인스톨러가 더 싫어요.

    인스톨 실드는 하다 잘못되면 다시 덮어서 설치하면 됩니다.
    하지만 윈도우 인스톨러는 설치하다 잘못되면 설치도 삭제도 안됩니다.(고급 사용자라면 레지스터리 수동으로 지워서, 그게 아니라면 그냥 컴퓨터 포맷 ㅜ.ㅜ)

    이론적인 해결방법은 있다고 하지만 현실적인 해결 방법이 너무 멀리 있는 경우죠.

    만든 의도나 기술이 좋다는건 알지만 문제가 생겼을 때 대처 방법이 너무 어렵습니다.

    1. 사무엘 2010/05/11 22:31 # M/D Permalink

      대부분 잘 동작하긴 하지만,
      파일이 꼬인다거나,
      설치가 제대로 안 되어 제거를 하려고 하는데도 원본 msi 파일을 요구하면서 배째거나 등등...
      Windows Installer 기반 설치 패키지도 사실은 마음에 안 드는 점 엄청 많아요.
      (Windows Installer는 물론 제품명이라기보다는 기술명이지만요)
      저 역시 동의합니다. ^^;;
      설치할 프로그램보다도 덩치가 더 크고 무거워 보이는 설치 솔루션은 영 쓰고 싶지가 않죠.

  3. 김 민규 2010/05/12 01:32 # M/D Reply Permalink

    재밌는 얘기입니다.
    저도 평소에 비슷한 생각은 좀 했었습니다. 어떤 프로그램을 설치한다는 게 그냥 사람 입장에서는 그냥 설치되고 제거되고 그러는 거지만
    사실 제대로 설치되고 제대로 제거되려면 뭔가 뒤에 아주 많은 일들이 있어야 되겠죠..
    그런 걸 잘 만들려면 똑똑함보다는 집요함?같은 게 필요할 것 같습니다. ㅋㅋ

    그리고 그 악명 높은 비스타 SP 1 설치 얘기가 나와서 또 생각난 건데요...
    요즘은 하드디스크 대신 SSD를 달아서 쓰는 사람들도 있다고 하죠.
    그걸 쓰면 어지간한 무거운 프로그램은 그냥 몇 초나 몇 분만에 설치가 끝나고,
    비스타 SP 1을 설치하려면 10 분이면 된다고 그럽니다. 우와...
    물론 아주 빠른 만큼 아주 비싸다는 게 또 문제죠... 5만 원이면 500 GB짜리 하드디스크를 살 수 있는데.. SSD는....
    지금 제 노트북이 약간 맛이 갔는데요 ㅠ, 컴퓨터를 새로 사게 된다면 저도 SSD를 달아서 써보고 싶습니다.

    1. 사무엘 2010/05/12 07:58 # M/D Permalink

      네, 실제 상황에서 일어날 수 있는 모든 상황을 감안하고 헤아릴 줄 아는 치밀함과 꼼꼼함이 있어야 합니다.
      하지만 아무리 그래도 도대체 무슨 일을 하고 있는지 저렇게까지 딜레이가 심한 건 너무 심하다는 생각이 듭니다.
      여전히 버그도 있는 주제에 말이죠.

      아울러, SSD의 위력은 http://minjang.egloos.com/2514959 의 5번. ㅎㄷㄷㄷ;; "포토샵 띄우는 데 3~4초." 정말 하드디스크의 램드라이브화이군요.
      덕분에 영원히 존재할 것 같던 '디스크 조각 모음'이 구시대 유물이 됐지요.

  4. 김재주 2010/05/13 02:35 # M/D Reply Permalink

    리눅스는 지금 실행중인 파일도 지울 수 있죠.

    그래서 sudo rm -rf / 같은 험악한 명령어도 아무 문제없이 -_-;;; 실행이 되고요.

    1. 사무엘 2010/05/13 10:31 # M/D Permalink

      그러니 소프트웨어 패치 같은 걸 하기도 쉽겠어요.
      유닉스 계열의 피를 물려받은 맥 OS도 마찬가지려나?
      윈도우가 유닉스 계열 OS와는 달리 메모리 맵 방식으로 프로그램을 로딩하는 것, 그리고 position dependent 코드를 사용하는 것은.. 나름 장단점이 있지만 당장 얻을 수 있는 성능을 최대한 고려해서 그런 디자인을 했다는 생각이 듭니다.

Leave a comment
« Previous : 1 : ... 1618 : 1619 : 1620 : 1621 : 1622 : 1623 : 1624 : 1625 : 1626 : ... 1841 : Next »

블로그 이미지

철도를 명절 때에나 떠오르는 4대 교통수단 중 하나로만 아는 것은, 예수님을 사대성인· 성인군자 중 하나로만 아는 것과 같다.

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2022/01   »
            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:
1734564
Today:
255
Yesterday:
506