부엉이의 나무구멍 속 작은 공간 http://www.nightowl.pe.kr/blog 방향전환. 이제는 되돌릴 수 없다. ko Sun, 25 Dec 2011 00:04:22 +0900 Owl-Blog RSS Generater <![CDATA[ Perl / Win32 / PAR::Packer - 한글 사용자 이름을 갖는 계정에서 PAR::Packer 실행 바이너리가 실행되지 않는 문제점의 해결 (by 부엉이) ]]> http://www.nightowl.pe.kr/blog/article/410 http://www.nightowl.pe.kr/blog/article/410
국내 Perl 커뮤니티의 @gypark 님의 도움으로, 이 문제는 CPAN에 버그 리포트가 이루어졌으며, 제작자가 수정의견을 받아들여 이를 패치하였습니다. 따라서 PAR::Packer 의 다음 버전(오늘 현재 아직 공개되지 않았습니다. 1.013이 될지, 더 큰 번호가 될지는 모릅니다)에서는 이 문제는 발생하지 않습니다. 따라서, 이 글을 보고 계신 분이 PAR::Packer 를 사용하시는 Perl 개발자이고, 자신의 PAR::Packer 모듈 버전이 1.012보다 더 큰 버전이라면 이 글에서 논의되는 문제는 이미 해결되었을 것입니다.

그러나, 이 패치 방법은, 이 글에서 제기하는 문제가 해결된 이후에도 PAR::Packer 를 이용하는 Perl 개발자에게 있어서는 다른 용도로서 그 의미를 갖고 있다고 생각합니다. 따라서 기존의 원문은 그대로 놓아둔 채로, 이 글의 마지막에 새로운 장을 설정하여 그에 관한 논의를 더 하였습니다. 관심있는 분께서는 참고하시기 바랍니다.

1. 들어가면서

Perl에 대한, 해커나 시스템 관리자들이 사용하는 언어라는 일반적인 통념과는 달리, 윈도우 환경에서도 Perl은 나무랄 데 없는 활용도를 가지고 있습니다. 윈도우의 GUI 환경 역시 적용이 가능하며, 여러 CPAN 모듈들을 사용하여 일반 목적의 각종 프로그램을 별 무리 없이 작성할 수도 있습니다.

그러나 이렇게 작성된 프로그램을 막상 배포하려 하면 골치아픈 문제와 맞닥뜨립니다. 유닉스/리눅스와는 달리 윈도우에는 대개 Perl 이 설치되어 있지 않기 때문에, 다른 시스템에서 이 스크립트를 실행할 수 있으리라는 보장이 없습니다. Perl 도 닷넷 프레임워크 같은 실행 런타임이 있으면 좋겠지만, 안타깝게도 그런 것은 존재하지 않는군요. 그렇다고 "이 프로그램을 사용하시려면 먼저 시스템에 Perl 을 설치하세요." 라는 것은 일반 사용자에게는 배보다 배꼽이 더 큰 일입니다.

그래서, 작성한 프로그램을 실행 바이너리로 배포할 수 있도록 몇 개의 도구들이 등장했는데, 다음과 같은 것들이 대표적입니다.

- PerlApp (ActiveState)
- Perl2Exe (Indigo Software)

다만 위 프로그램들은 모두 상업용 소프트웨어로써, 정식으로 사용하려면 만만치 않은 자금의 지출이 필요합니다. 게다가 모두 외국에서 만들어진 프로그램이어서, 카드로 달러 결제를 해야 하는 등 상당히 번거롭습니다. 프로그램을 만들어서 돈 받고 팔려는 것도 아닌데, 40여만원의 지출(PerlApp이 포함된 Perl Dev Kit의 경우)은 뭔가 격에 맞지 않는 짓이죠.

이런 경우에 사용할 수 있는 도구가 바로 PAR::Packer 라고 하는 Perl 모듈입니다. 이 모듈은 대상 Perl 스크립트에 사용된 모든 모듈을 한데 모아서 Perl 해석기[Interpreter]와 함께 하나의 실행 파일로 만들어 줍니다. Perl 해석기가 포함되어 있는 실행 바이너리이기 때문에, Perl이 설치되지 않은 시스템에서도 문제 없이 사용할 수 있습니다. 초기 구동 속도가 조금 느리다는 단점은 있지만, 일반 목적의 배포에는 큰 문제가 되지 않습니다.

ActivePerl 의 경우에는 PPM 으로부터 설치할 수 있으며, 딸기 펄의 경우에는 CPAN 을 통해 설치가 가능합니다. ActivePerl 의 경우에는 MinGW 와 dmake 를 함께 설치해 주어야 합니다. (MinGW에 포함되어 있는 오픈소스 컴파일러를 컴파일에 사용하기 위해서입니다.)

제가 사용하는 Perl 이 ActivePerl 이고 Strawberry Perl은 사용해 본 적이 없기 때문에, 이하의 모든 이야기는 ActivePerl을 기준으로 합니다만, 아마 Strawberry Perl 역시 동일할 것입니다.


PAR::Packer 의 Packager 인 pp 의 구체적인 사용법은 여기를 참조하시면 되므로 여기서는 더 이상 설명하지 않습니다. 애초에 이 글의 목적이 PAR::Packer 를 소개하자는 글은 아니기 때문입니다.

2. 대한민국에서만 발생하는, PAR::Packer 의 문제점

그런데, 이 PAR::Packer 에 관하여, 이 곳 대한민국에서만 발생하는 골치아픈 문제가 하나 있습니다. 그것은 바로 사용자 이름과 관련되는 문제입니다. 무슨 이야기일까요? 이 부분을 이해하기 위해서는, PAR::Packer 로 패키징된 실행 바이너리의 실행 과정에 대한 이해가 선행되어야 합니다.

일단 PAR::Packer 가 Perl 코드 자체를 컴파일하지는 않는다는 점을 이해해야 합니다. Perl은 인터프리터 언어이고, 실행 바이너리로 패키징한다 하여 이 점은 변하지 않습니다. PAR::Packer 는 대상 Perl 스크립트와, 그 스크립트가 사용하는 모든 모듈을 한데 모아서 ZIP 으로 묶고, 여기에 Perl 실행에 필요한 해석기를 포함하여 일종의 자동 풀림 형태의 EXE 압축 파일로 만듭니다. 그래서, PAR::Packer 로 만들어진 실행 파일을 실행하면, PAR::Packer는 먼저 특정한 위치에 ZIP 압축을 풀어 놓은 후, 포함되어 있는 Perl 해석기를 통하여 스크립트를 실행하게 됩니다.

그래서 PAR::Packer 로 빌드한 실행 바이너리를 실행하면, 동일한 이름의 파일 두 개가 프로세스 목록에 모-자 프로세스 형태로 떠 있는 것을 확인하실 수 있습니다. 물론 프로그램을 종료하면 두 개의 프로세스가 동시에 꺼집니다.


이 압축을 푸는 과정이 문제입니다. PAR는 압축을 윈도우 TEMP 폴더에 풀어놓는데, 그냥 TEMP 폴더에 풀어놓는 것이 아니라, TEMP 폴더 밑에 PAR-[사용자 이름] 이라는 폴더를 하나 만들고, 그 밑에 다시 cachexxxxxx.. 라는 폴더를 만들어서 그 안에 압축을 풀어놓습니다. 예를 들면 윈도우 7에서는 이런 구조가 됩니다.

C:\Users\사용자 이름\AppData\Local\Temp\par-사용자 이름\cache-xxxxxxxxxxxxxxxxxx
(x는 무작위. 내부적으로는 SHA-1 해시를 사용합니다.)

[첨부 이미지가 있습니다.]

문제는 사용자 이름에 한글이 포함되는 경우입니다. 이게 왜 문제가 될까요? 바로 인코딩 때문입니다. PAR::Packer 는 우선 시스템의 TEMP 폴더의 경로를 찾아 문자열로 저장합니다. 그리고 그 문자열 뒤에 "par-사용자 이름" 이라는 문자열을 덧붙이게 되는데, 이 과정에서 서로 다른 인코딩의 두 문자열(아마도 윈도우에서의 한글 이름은 유니코드[UTF-16 LE] 또는 CP949 로 전달될 것입니다. 확인은 안 해봤습니다.)이 아무런 고려 없이 합쳐지는 결과, 사용자 이름의 한글 부분이 엉망으로 깨지게 되어 이상한 문자들로 바뀌어 버립니다. 이 경로로 폴더를 만들려고 시도하면? 폴더 이름에 깨진 문자가 포함되어 있는 결과 폴더 작성에 실패하게 되겠죠. 그 결과 creation of private temporary subdirectory ~~~~ failed. 라는 오류를 내면서 실행이 중단되어 버립니다. 만약 --gui 옵션을 주어서 빌드한 EXE 파일이라면 파일을 더블클릭해도 아무런 반응이 없는 모습이 될 것이고, 그것이 아니라면 콘솔 화면이 잠깐 나타났다가 꺼지는 모습이 나타나겠죠.

[첨부 이미지가 있습니다.]

3. 문제를 해결하는 방법?

한글의 인코딩과 관련한 문제이다 보니, 구글링을 해봐도 해결 방법이 없습니다. 아예 이런 현상에 대한 논의 자체가 없죠. 대한민국의 Perl 사용자가 적기 때문이기도 하겠지만, 가까운 일본만 해도 인코딩 문제로 인한 말썽이 많은 CJK 문자권에 들어가는데다 Perl 인구도 많은 편인데, 이런 문제가 이슈가 안 되는 것이 좀 의아할 따름입니다.

각설하고, 이 문제는 PAR::Packer 에서 스크립트의 압축을 해제하는 폴더를 변경할 수 있게 해준다면 간단히 해결이 가능합니다. 그러나, pp 명령행 옵션에 압축 해제된 스크립트가 저장되는 위치를 변경하는 옵션은 없습니다. -T 또는 --tempcache 옵션이 있습니다만, 이 옵션은 Temp 폴더 대신 압축을 풀 폴더를 지정하는 옵션으로서, 문제가 되는 "par-사용자 이름" 부분이 이 뒤에 그대로 따라가므로 전혀 문제가 해결되지 않습니다.

이쯤 되면, 배포자 입장에서는 이 문제를 해결하지 않는 것이 사실 속 편합니다. 프로그램 사용자들에게, 사용자 이름이 한글이면 실행이 안 되니까, 영문자 및 숫자로 구성된 사용자 계정을 만든 후 사용하라고 readme.txt 파일에 적어서 배포하는 것이죠. 저도 방법을 찾지 못해서, 한동안 이런 방식으로 배포했습니다.

그러나, 생각해 보면 어처구니가 없는 일입니다. 사용자 이름을 한글로 쓰는 것이 물론 (호환성을 생각하면) 좋은 습관은 아니지만, 이런 방식으로 사용자 이름을 만들어 사용하는 사람이 차고 넘칠 정도로 많은데다, 윈도우에서도 멀쩡하게 허용하고 있는 터에 일개 프로그램에서 쓰지 말라고 할 수는 없는 것 아니겠습니까. 영 불가항력이 아닌 바에야, 프로그램상에 존재하는 문제의 해결을 사용자에게 떠넘기는 것도 별로 좋은 태도는 아니죠.


(1) 첫 번째 시도: PL/PM 파일의 수정

결국 소스 레벨에서의 해결밖에 방법이 없겠다 싶어서, 내부의 모듈들을 뒤졌습니다. 일단 두 개의 파일이 검색되었습니다.

1) site/bin/par.pl 의 _set_par_temp 서브루틴
2) site/lib/PAR/SetupTemp.pm 의 _get_par_user_tempdir 서브루틴

여기구나 싶어서, 이 두 부분에서 임시 폴더 작성에 사용되는 사용자 이름을 항상 OwlNetworks 로 돌려주도록 코드를 수정했습니다. 아래 그림처럼 말이죠.

저에 맞추어서 OwlNetworks 라고 적은 것 뿐, 다른 분들은 자신에게 맞추어 임의로 영문자 및 숫자를 섞어서 정하시면 됩니다.


[첨부 이미지가 있습니다.]

결과는? 실패입니다. 여전히 만들어진 실행 바이너리는 사용자 이름이 포함된 폴더에 압축을 풀더군요. 임시 폴더의 경로를 만드는 코드가 다른 어디에도 존재하지 않았기 때문에, 이 수정이 제대로 동작하지 않는다면 아마도 PAR::Packer 가 컴파일시 이 코드를 사용하지 않는다는 추정이 가능했습니다. 그 때, 제 눈에 띈 주석 한 줄.

# The C version of this code appears in myldr/mktmpdir.c

....PAR::Packer 를 컴파일하기 전의 C 소스 레벨에서의 수정이 필요했던 것입니다. 그 이야기는, 이미 컴파일 된 상태로 제공되는 PPM 파일을 사용할 수 없다는 의미였습니다. 오리지날 소스의 수정이 필요하므로, CPAN 을 통한 설치도 안됩니다. 오 마이 갓. 저는 C 언어를 모릅니다. orz...


(2) 두 번째 시도: C 소스의 수정 후 재컴파일

지푸라기라도 잡는 심정으로, 제가 사용하고 있는 버전과 동일한 버전의 PAR::Packer 0.991 버전의 소스를 metacpan.org 을 통하여 다운로드 받았습니다.

제가 사용하는 ActivePerl 의 버전이 5.10.1 Build 1007 이고, 이 버전에서 PPM을 통해 제공되는 PAR 의 버전은 1.002, PAR::Packer 의 버전은 0.991 입니다. [ActivePerl과 최근 버전의 PAR/PAR::Packer 사이에 궁합이 묘하게 좋지 않아서, 5.10.1.1007 버전의 경우 제공되는 PAR/PAR::Packer PPM 의 버전은 조금 오래된 버전입니다.]

참고로, 공식적인 ActiveState PPM 에서 제공되는 5.10 버전의 PPM 목록에는 PAR::Packer 가 없습니다. ActiveState PPM 에서는 공식적으로 Win32 환경에서 PAR::Packer 는 컴파일 오류가 발생하는 것으로 되어 있습니다. PAR 의 경우에도 현재 최신 버전은 1.005이지만 등록은 1.002까지만 되어 있습니다. 다만 이 경우는 컴파일 실패가 아니라 아직 컴파일 및 테스트가 진행되지 않았기 때문인 점을 유의하시기 바랍니다.

[첨부 이미지가 있습니다.]

따라서, PPM 으로 5.10.1 버전에서 PAR::Packer 바이너리를 구하려면 bribes.org PPM 레퍼지토리를 이용하여야 합니다. 여기에서 제공되는 버전 역시 0.991 버전입니다.

참고로, trouchelle PPM 레퍼지토리를 이용하면 PAR::Packer 1.008 버전을 다운로드 받을 수 있습니다만, 필자의 경우에는 적용시켜 본 결과 오류가 발생하여 실행 바이너리의 빌드가 불가능하였음을 밝혀둡니다.

(bribes, trouchelle 모두 ActivePerl 5.10 버전의 Perl Package Manager 를 이용하여 연결이 가능합니다.)


다운로드 받은 소스 파일의 압축을 푼 후, myldr/mktmpdir.c 파일을 찾아서 텍스트 에디터로 (읽지 못할 걸 알면서도) 열어보았습니다.

    /* "$TEMP/par-$USER" */

    stmp_len =
        strlen(tmpdir) +
        strlen(subdirbuf_prefix) +
        strlen(username) +
        strlen(subdirbuf_suffix) + 1024;


다행히, 파일에 주석이 잘 달려 있어서 쉽게 찾을 수 있었습니다. 아무리 C 를 모르는 저이지만, Perl 로 굴러먹던(..) 통밥으로 찾아보니 대충 뭐가 어떻게 돌아가는지는 알겠더군요. 그래서 위 코드 바로 앞에 이렇게 한 줄을 추가했습니다. 경로를 만들기 바로 직전에, username 을 강제로 OwlNetworks 로 변경하는 코드를 삽입한 것입니다.

        /* Temporarily fixed Korean(CP949/UTF16LE) Encoding Problem */

        username = "OwlNetworks";


[첨부 이미지가 있습니다.]

이제 이 코드를 컴파일만 하면 됩니다. MinGW 가 설치된 상태이므로 gcc 컴파일러가 존재하기 때문에 충분히 가능한 작업입니다. CPAN 을 사용하지 못하지만, 이런 경우에는 일반적으로 (다 되는 것은 아닙니다) 아래와 같이 4줄의 명령어를 입력하면 됩니다.

perl makefile.pl
dmake
dmake test
dmake install



(3) PAR::Packer 의 컴파일 과정에서 겪은 오류들

그런데, 세 번째 과정인 dmake test 과정에서 자꾸 묘한 오류가 발생했습니다. 전혀 예상 못한 상황이었지요.

[첨부 이미지가 있습니다.]

t/20-pp.t 의 테스트 과정 중 31번째와 32번째에서 오류가 계속 오류가 발생합니다.

31st: No resource section found in file ~~~~ at C:/usr/site/bin/Win32/Exe.pm line ~~~.
      Can't call method "remove" on an undefined value at C:/usr/site/bin/Win32/Exe.pm line ~~~.
32nd: Failed test.


혹시나 싶어서 그대로 dmake install 을 수행한 후 스크립트의 컴파일을 시도하였으나, 위 31번의 오류 메시지와 같은 내용의 오류를 내면서 빌드에 실패하였습니다.

[첨부 이미지가 있습니다.]

Win32::Exe 모듈의 No resource section found in file 메시지로 구글링을 해 보니, 이 오류, 여러 사람 머리를 복잡하게 만든 오류더군요. 실행 파일을 만드는 과정에서 사용하는 Win32::Exe 모듈과 PAR::Packer 모듈 사이의 궁합 문제인 듯 한데, PAR::Packer 버전 및 Win32::Exe 의 버전에 따라서 발생하기도 하고 발생하지 않기도 하는 기묘한 문제였습니다. 구글링상에 나타나는 대부분의 문제는 Win32::Exe 버전 0.14 에서 발생하는 문제였는데, 제 경우는 Win32::Exe 버전 0.17 (최신 버전) 인데도 이런 문제가 발생했습니다.

직접 문제를 해결할 능력이 안 되기 때문에, 할 수 있는 것은 오류가 해결된 PAR::Packer 버전을 찾는 방법 뿐이었습니다. PAR::Packer 의 Change Log 를 열심히 뒤졌습니다.

[첨부 이미지가 있습니다.]

1.005 버전에서 해당 오류가 해결된 것으로 나오는군요. 그래서 1.0.5 버전을 다운로드 받은 후 같은 내용으로 수정을 합니다. 그리고 컴파일. 어라? 이번엔 아예 dmake 과정에서 parldyn.exe 가 없다는 오류가 뜹니다. 제길.

[첨부 이미지가 있습니다.]

다시 Change Log 를 뒤집니다. 바로 위에 있습니다. 좀 자세히 볼 걸.

[첨부 이미지가 있습니다.]

1.006 버전의 소스를 다운로드 받아 myldr/mktmpdir.c 의 해당 부분을 수정한 후 다시 컴파일합니다. dmake test 도 무사히 통과합니다. dmake install 을 수행한 후 테스트를 수행합니다. 무사히 실행 바이너리가 만들어집니다. 실행도 잘 됩니다. 압축이 풀리는 임시 폴더도 강제 지정한 대로 잘 만들어집니다.

이제 실전 테스트만 남았습니다. VMWare Player 를 이용하여 사용자 이름이 한글인 윈도우 XP 를 기동한 후 실행해 봅니다. 아래 그림과 같이 매우 잘 실행됩니다. 만세!

[첨부 이미지가 있습니다.]

참고로, 앞의 (1) 에서 시도한 바 있는, 사용자 이름으로 TEMP 폴더의 경로를 만드는 서브루틴이 포함된 두 개의 PL/PM 파일은 수정하지 않아도 됩니다. 이 두 파일은 빌드 과정에서는 사용되지 않습니다. (실행 파일을 만들지 않고 단순히 par 파일을 만들거나, standalone pl 파일을 만들 때에는 이 코드가 사용이 됩니다.)


4. 남은 이야기

사실, 이 부분을 제대로 해결하자면, 해당 코드 부분에서 사용자 이름의 인코딩을 확인하여 적절히 처리를 해 주도록 변경하는 것이 정석이겠습니다. 그러나 앞에서도 말한 바와 같이 저는 C 언어를 모릅니다. 게다가 C 에서의 인코딩 처리가 Perl 처럼 간단(?)하지 않다는 것은 아무리 저라도 익히 짐작할 수 있습니다. 그래서, 일단 임시방편으로 이와 같은 방법으로 처리를 하였습니다.

제가 PAR::Packer 를 다시 컴파일하는 과정에서 겪은 오류들은, 어떤 버전의 Perl 및 모듈을 선택하느냐에 따라 겪게 될 수도, 아닐 수도 있습니다. (제 경우 ActivePerl 5.10.1.1007, PAR 1.002, PAR::Packer 1.006, Win32::Exe 0.17 의 조합으로 성공하였습니다. ) 만약 오류가 발생하는 경우 PAR::Packer 의 버전을 변경해 가면서 여러 버전에서 확인을 해 보셔야만 합니다.

참고로, PAR::Packer 1.011 버전은 Perl 버전은 최소 5.8.1을, PAR 버전은 1.004 를 요구합니다. 또한 PAR::Packer 의 최신 버전인 1.012 버전은 PAR 버전이 1.005 (최신 버전) 여야만 합니다. 따라서 ActivePerl 에서 PPM을 통해 설치할 수 있는 PAR 1.002 버전을 기준으로 본다면 설치할 수 있는 PAR::Packer 는 최대 1.010 버전까지입니다. 전술한 바와 같이, trouchelle PPM 레퍼지토리에서 받을 수 있는 PAR::Packer 버전 1.008의 경우 제 시스템에서는 오류가 발생하였습니다.


5. 덧붙임 (2012/01/30 추가)

이 글의 첫머리에 덧붙인 것과 같이, 이 문제는 PAR::Packer 가 사용자 이름이 한글인 경우를 충분히 고려하지 않은 문제로서, 이미 제작자가 이에 관한 패치를 하여 CVS에 반영하였기 때문에, 이 문제는 다음 버전이 정식으로 공개되면 해결될 것입니다. (2012년 1월 30일 현재, 아직 새로운 버전이 공개되지는 않았습니다. 모듈의 버전이 1.012보다 높은 버전이라면, 이 문제가 해결된 버전입니다.) 그러나 필자는, 이번 패치 이후에도, 위와 같은 패치 방법은 다른 관점에서 아직 이용가능성이 남아 있다고 생각합니다. 그래서 이에 관한 이야기를 조금 더 해 보고자 합니다. 이하의 이야기는 PAR::Packer 를 패키징 도구로 사용하는 Perl 개발자에게만 유용하며, 일반 이용자들은 읽을 필요가 없습니다.


(1) PAR::Packer 의 임시 폴더 생성 방식의 무의미함

아마도, PAR::Packer 의 제작자가 패키지의 압축이 풀리는 폴더를 만들면서 그 폴더명에 사용자 이름을 넣게 된 이유는, Perl의 주 무대인 xNIX(유닉스/리눅스. 이하 편의상 리눅스 환경이라고 통칭하겠습니다) 환경이 여러 사람이 함께 사용하는 환경이기 때문에, 권한 문제나 여러 사람이 사용하는 패키지가 서로 섞이는 등의 여러 가지 문제를 미연에 방지하기 위함인 것으로 생각됩니다. (제 리눅스 환경에 대한 지식은 매우 일천한 관계로, 더 이상의 자세한 논의는 무리입니다.)

그러나, 윈도우 환경은 이런 리눅스 환경과 차이가 있습니다. 공용 컴퓨팅 환경인 리눅스 환경과 달리, 대부분의 윈도우 머신은 1인의 사용자가 사용하는 개인 컴퓨팅 환경입니다. 그래서 특별한 상황이 아니라면 다른 사람의 시스템 환경을 고려해야 할 필요성이 거의 없습니다. 게다가, 애초에 임시 폴더 자체가 사용자 별로 다르게 만들어지기 때문에, 시스템에서 주어지는 임시 폴더 경로를 그대로 받아 사용하기만 한다면 권한 문제가 발생할 여지가 없습니다. 따라서, 이런 PAR::Packer 의 임시 폴더 네이밍 방식은, 최소한 윈도우즈용 Perl 에 대해서는, "전혀"라고까지는 하지 않겠습니다만(개발 환경에서는 필요성이 있을 수도 있으니까) 최소한 만들어진 응용프로그램을 사용하는 사용자의 입장에서는 필요가 없는 절차라고 할 수 있습니다. 그냥 다른 프로그램에서 하는 대로, 프로그램 이름 (예를 들면 PAR-Packer) 으로 임시 폴더를 만들고 그 안에 압축을 풀면 될 일이죠.


(2) 사고의 전환: 생산자/응용프로그램 구분으로의 활용

그러나, 이왕 만들어져 있는 코드, 이런 식으로 활용할 수도 있지 않을까 싶습니다. 기존의 사용자 구분의 용도로 만들어진 이 코드를, 코드 수정을 통해 프로그램 생산자 구분의 방식으로, 혹은 어플리케이션 구분의 방식으로 이용하면 어떨까 싶은 것이죠.

예를 들면 이런 것입니다. PAR::Packer 는 일단 임시 폴더에 풀린 패키지 파일들을, 패키징 시 특별한 옵션 (-C 옵션)을 주지 않는 한 삭제하지 않습니다. 2회차 이후의 실행에서 패키지를 다시 풀어놓는 시간을 절약함으로써 프로그램 실행 속도를 끌어올리기 위한 것이죠. 최초로 패키지를 풀고 해석하는 데 상당히 시간이 오래 걸리기 때문에, 이후의 실행 속도를 생각하면 이것은 상당히 효과적인 정책입니다. 그러나 이렇게 하면 일단 임시 폴더 내에 기록된 파일들이 사용자가 따로 삭제하지 않는 한 지워지지 않고 계속 남아 있기 때문에, 차후 프로그램을 삭제하거나 버전업을 하였을 때에도 이 내용들이 그냥 남아서 디스크의 용량을 차지하게 됩니다. 윈도우 안에 임시 폴더라는 게 있는지도 모르는 일반 사용자들이 널려 있는 판국에, 이것은 절대 좋은 상황은 아닙니다. 제 경우는 조금 큰 규모의 프로그램을 몇 번 버전업 했더니만 PAR::Packer 임시 폴더가 100메가바이트를 넘어가는 상황까지도 겪었습니다.

그렇다면 언인스톨러 비슷하게 임시 폴더 삭제용 툴을 따로 배포하면 되지 않느냐. 물론 그렇게 하는 것이 정답이겠지만, 이것이 그렇게 만만하지가 않습니다. 본문의 사진에서 한번 보여드린 바 있지만, PAR::Packer 는 [윈도우 임시 폴더]\[PAR-사용자 이름 폴더] 이하에 패키지들 간의 섞임을 막기 위해 한 번 더 temp-#####.. 와 같은 무작위의 임시 폴더를 만들고 그 안에 패키지의 압축을 풀기 때문입니다. 이 temp-#####.. 폴더의 이름을 알기가 어렵기 때문에, 그 프로그램에 대한 임시 폴더만 선택적으로 삭제하기가 상당히 까다로워집니다. 그냥 [PAR-사용자 이름] 폴더 자체를 날려 버려도 사실 일반 사용자 입장에서는 큰 문제가 없을 것 같기는 하지만, 이 역시 100% 문제가 없을 것이라고 장담할 수 있을지 모르겠습니다.

그래서, 이 사용자 이름을 입력하는 부분에, 제작자명 또는 프로그램명을 입력하면 어떨까 하는 생각을 해 보았습니다. 위에서 논의한 패치 방법을 이용하여 사용자 이름 대신 제작자명 또는 프로그램명을 입력한 후 PAR::Packer 를 다시 컴파일하면, 그 환경에서 제작된 프로그램은 항상 지정된 폴더명으로 임시 폴더를 만들게 되므로, 패키징할 때에 -C 옵션을 사용하지 않더라도 차후 임시 폴더를 관리하는 데 (언인스톨러를 제공하는 데) 상당히 좋은 환경이 만들어지게 됩니다. 프로그램별로 혹은 제작자별로 독립적으로 만들어지는 정해진 폴더를 별다른 위험 부담 없이 살포시 날리면 되기 때문입니다. ]]> Perl Perl PAR::Packer Win32 한글 사용자 이름 Sun, 25 Dec 2011 00:04:22 +0900 <![CDATA[ 당황스러운 제안, 그리고 거절의 이유. (by 부엉이) ]]> http://www.nightowl.pe.kr/blog/article/409 http://www.nightowl.pe.kr/blog/article/409
뭐, 덕분에 하루 내내 고민했다. 일단 내 Perl 실력이 현업에서 쓸 정도가 아니라는 점은 분명하다. 같은 코딩에도 몇 배의 시간이 걸릴 것은 자명하고, 무엇보다 전공자가 아니기에 시스템에 대한 지식수준이 심각하게 부족할 것이 예상된다. 한마디로 사상누각. 그러나 이런 것은 회사측에서 알고 뽑는다면 문제가 아니다. 하드트레이닝을 통해 알아서 키워주겠다는 이야기일테니. 즉, 내가 걱정할 문제가 아니다.

진짜 고민은 다른 데 있었다. 이 선택을 나 스스로 정당화할 수 있을까(나 자신을 설득할 수 있는가)의 문제였다. 지금 이 시점에서 진로를 변경한다는 것은, 나의 전공, 그동안 공부해온 것, 인생의 목표들을 모두 백지화하고, 내가 가진 식견으로는 미래가 어떠할 지 짐작할 수 없는 분야로 뛰어드는 것을 의미한다. (지난 11년간의 공부가 모두 무로 돌아간다.) 사실 가진 것도 없지만, 그나마 내가 가지고 있는 것들을 모두 내려놓고 뛰어들어야 하는 것이다. 그렇다면 내가 포기해야 하는 것들과, 그로 인해 내가 얻을 수 있는 것을 잘 저울질해봐야 한다.

객관적 측면에서, 중소기업이니 연봉이나 근무환경이 좋은 수준은 아닐 것은 이미 짐작하고 있지만, 일단 생활이 가능한 수준이라면 장기적으로는 몰라도 단기적으로는 큰 문제는 안 된다. 사회통념으로 볼 때 무언가 새로운 것에 장기적으로 도전할 만한 나이는 아니지만, 업계에서 전문가로 성장하고 입지를 다질 수 있다면 어느 정도의 시간과 노력을 투자하지 못할 것은 없다. 그러나 협소하기 그지없는 국내 Perl 업계의 현실을 생각하면, 업계에서 자리를 잡을 수 있을 것인지 여부도 사실 불분명하다. 주관적 측면에서 보더라도, 지금은 취미생활로 하는 코딩이니 공부하는 와중에 짬짬이 하는 코딩이 즐거울 수 있지만, 이것을 업으로 하면서 최소한 같은 수준의 만족을 얻을 수 있을지는 의문이다. 결론은, 지금 당장 취업할 수도 있다는 점을 제외하고는 별다른 메리트가 없는 것이다.

이렇게 생각하면 사실 오래 고민할 일도 아니지만, 무려 하루가 지나서야 거절의 쪽지를 보낼 수 있었다. 그만큼 당장의 "취업"이라고 하는 것의 무게가 너무 무거웠다. 거듭된 시험 탈락과, 관련분야가 아니면 서류통과조차 장담할 수 없는 엄혹한 취업환경을 직접 겪으며, 한 달 전 결국 시험급수까지 변경하는 선택을 했던 나에게는, 지금 당장이라도 일할 수 있다는 것 자체가 매력적인 선택지였던 것 같다.

뭐, 결국 거절했다는 점에서 본다면 아직 내가 내려놓을 게 많다는 의미가 되겠고, 거절하는 데 오랜 시간이 걸렸다는 점에서 본다면 최근 몇 명에게서 들은 이야기인 "떨어진 자신감의 회복이 시급하다"는 이야기가 되겠지. 어찌 되었건, 이렇게 내 인생의 갈림길을 하나 더 지나쳤다. 가지 않은 길이 회한으로 남지 않으려면, 좀 더 정신줄을 잡아야 되겠다.


p.s.


같이 고시 준비를 하는 누구 말마따나, 고시를 하는 블로거가 한동안 포스팅이 없다면, 열심히 공부를 하느라 포스팅할 시간이 없다기보다는, 반대로 공부를 열심히 안 해서 늘어지는 상황이라 (귀차니즘에) 포스팅을 안 하는 경우가 더 많은 것 같다.

.......거기에는 나도 해당되려나. ]]> 이런저런 이야기 입사제의 Wed, 21 Dec 2011 05:17:44 +0900 <![CDATA[ Win32::GUI / BrowseForFolder : 폴더 선택 창에서 새 폴더 만들기 구현 (by 부엉이) ]]> http://www.nightowl.pe.kr/blog/article/407 http://www.nightowl.pe.kr/blog/article/407 1. Win32::GUI의 폴더 선택 창에서 새 폴더 만들기?


Win32::GUI 는 그 자신의 GUI 환경에서 사용자가 특정한 폴더를 선택할 수 있도록 BrowseForFolder 함수를 제공합니다. 상당히 익숙한, 다음과 같은 창을 열고 사용자가 선택한 폴더까지의 절대 경로를 돌려주게 되죠.

[첨부 이미지가 있습니다.]

그런데, 이 기능에는 한 가지 아쉬운 점이 있습니다. 위 이미지를 보면 바로 눈치챌 수 있으실 텐데, 윈도우 XP 이후의 윈도우즈에서 (당연히) 가능한, 새 폴더를 만든 후 해당 폴더를 선택할 수 있는 [새 폴더 만들기] 버튼이 보이지 않습니다. 그래서 특정한 작업을 수행할 폴더를 지정하기 위해서는 미리 윈도우 탐색기 등을 이용하여 폴더를 만들어 놓고 폴더 선택을 해야 하죠. 은근히 불편합니다.

처음 이 기능(BrowseForFolder)을 사용했던 건 2010년 초 간단한 확장자 변경 프로그램을 만들면서였는데, 이 때는 폴더 만들기 기능이 필요가 없었습니다. 특정한 폴더 안에 들어 있는 모든 .AVI 파일의 확장자만 .SVI 로 바꾸는 프로그램이었기 때문이죠. (똑같은 파일인데도 .AVI 확장자는 거부하고 .SVI 확장자만 받아먹는 망할 눔의 삼성 Yepp Player 때문에... 뿌득) 그런데, 2010년 후반에 M3U Copier 라는 프로그램을 짜기 시작하면서(.M3U 파일 목록에 있는 모든 MP3 파일을 특정한 폴더로 복사해 주는 프로그램입니다), 복사할 대상 폴더를 정할 때에 폴더를 만들 수 있다면 훨씬 편리하게 쓸 수 있다는 사실을 깨달았지요.

문제는, Win32::GUI 의 BrowserForFolder 함수를 아무리 뒤져봐도, 새 폴더 만들기를 지정할 수 있는 방법이 없었다는 것입니다. 구글링을 해 보니, 저와 같은 문제를 겪은 사람이 메일링 리스트에 문의를 한 것이 있었는데, (외국에선 요즘도 Win32::GUI 를 그럭저럭 많이 사용하나 봅니다.) 결론은 Win32::GUI 1.06 버전에서 이 기능을 사용하는 것은 불가능하다. 라는 것이었습니다. [참고 링크]

참고로, 현재 CVS 에 올라가 있는 최신의 Win32::GUI 코드에는 이 기능이 포함되어 있습니다. (개발자가 이 질문을 보고 이 기능을 코딩해 넣었더군요. 2011년 7월에 CVS 에 Commit 되었습니다.) 그러나 아직 이 기능이 포함된 새로운 Win32::GUI 가 빌드되지 않았기 때문에, 이 기능을 당장은 사용할 수 없습니다. 혹시나 싶어서 CVS에서 최신 버전의 소스를 다운로드 받아 컴파일을 시도했지만, 잘 나가다가 중간에 오류를 뿜으면서 컴파일이 되지 않더군요. (하아) 게다가 일부 기능을 컴파일하기 위해서는 Visual C 가 필요한데, 개발자도 아닌 저에게 그런 프로그램이 있을 리가 없습니다.



2. 정말 방법이 없는 것일까? Win32::API? Win32::FileOp!

그 덕분에, 최근까지 이 기능을 사용한 제 모든 프로그램에는, 폴더 선택 창에서 새 폴더를 만드는 기능이 없었습니다. 그러나 생각해보면 아예 방법이 없는 것은 아닙니다.

이를테면, (아직 글로 직접 쓰지는 않았지만, 곧 쓸 예정인) Win32::Clipboard 에서는 지원하지 않는, 텍스트가 아닌 이미지를 클립보드에 집어넣는 기능이 Win32::API 를 이용하여 윈도우 API를 직접 호출함으로써 가능했기 때문에, 역시 같은 기능을 하는 윈도우 API 인 SHBrowseForFolder (shell32.dll) 를 호출하면 이 기능을 사용 못할 바 아닙니다. (쓸 줄 모른다면 별문제이지만, 이미 한 번 Win32::API 를 사용하면서 대충 어떻게 쓰는지 감을 잡은 후입니다. 한번 쓴 기능, 두 번은 못 쓰겠습니까.)

그러나, 엉뚱한 데에서 더 쉬운 해결의 실마리가 잡혔습니다. CPAN을 검색하다가, Win32::FileOp 라는 모듈이 2011년 초에 한 번 버전업이 된 것을 우연히 알게 된 것이죠. 이 모듈은 이미 2010년 당시에도 알고 있었고, 실제로 확장자 변경 프로그램을 짤 때 사용했던 모듈이지만(그 이후에 Win32::GUI 내에도 이 함수가 있다는 걸 알고 굉장히 허무했었지요.), 2010년 당시 이 모듈의 최신 버전은 0.14.1 (2003년에 릴리즈) 이었고, 이 버전에서는 폴더 선택 창에서 폴더의 생성이 불가능했었습니다. 그러나, 2011년 1월에 0.16.0 버전이 릴리즈되면서 이 기능을 사용할 수 있도록 버전업이 되었더군요!

제가 사용하는 윈도우용 Perl 은 ActivePerl 5.10.1.1007 버전인데, 이 버전의 PPM 에서는 아무리 검색을 해 봐도 (현재도) 이 모듈의 최신 버전은 여전히 0.14.1 입니다. 그 덕분에 새 버전이 나온 지 1년이 다 지나도록 버전업 사실을 몰랐던 거였습니다. 이런...


덕분에, 다시 윈도우 API 레퍼런스를 뒤지면서 삽질해야 할 필요가 없어졌습니다. 바로 CPAN으로부터 Win32::FileOp 를 수동으로 업데이트한 후, 이 기능을 적용했습니다. 다음은 코드입니다.


# msgOutput 서브루틴은 소스가 UTF-8 인코딩으로 되어 있는 관계로,
# UTF-8 Output 을 지원하지 않는 Win32::GUI 창에서 메시지가 깨지지
# 않도록 하기 위해 출력 전에 내부 UTF-8 인코딩을 euc-kr 인코딩으로
# 변경하는 기능을 하는 서브루틴입니다.

sub BrowseForFolderNewUI {

    my $folder;
    my $title = msgOutput("음악 파일을 복사할 폴더를 선택하세요.");

    use Win32::FileOp qw(:DIALOGS);

    $folder = BrowseForFolder( $title, CSIDL_DRIVES, BIF_USENEWUI );

    undef $title;

    return $folder;
}


폴더가 선택되면 $folder 에는 선택된 폴더의 절대 경로(예: D:\My Documents\My Music) 가 반환되고, 폴더가 선택되지 않았다면 undef 가 반환되므로 실제 사용자가 폴더를 선택하였는지 여부를 즉시 확인 가능합니다. 실행한 결과는 다음과 같습니다. [새 폴더 만들기] 버튼이 떡하니 나타나 있죠.

[첨부 이미지가 있습니다.]

한 줄 요약 : 새 폴더 만들기 기능이 있는 폴더 선택 창을 사용하려면 Win32::FileOp 의 최신 버전을 사용하세요.


[참고 링크]

Win32::FileOp 0.16.0 - [CPAN 링크]
(.pm 파일만으로 구성된 모듈이고, 소스를 확인해 보면 Win32::API 를 이용하여 shell32.dll 의 SHBrowseForFolder 를 호출합니다. 의존성 있는 모듈이 존재하므로 설치 시 이들이 함께 설치되어야만 합니다.)

위 기능을 처음 사용해 본 .M3U Copier 프로그램은 다음 링크에 공개되어 있습니다.

.M3U Copier - http://www.nightowl.pe.kr/software/m3ucopier
]]> Perl Win32::FileOp Win32::GUI Perl BrowserForFolder Sun, 04 Dec 2011 00:44:33 +0900 <![CDATA[ Perl / Win32-GUI : 스크린샷 저장 시 저장되는 비트 수에 주의 (by 부엉이) ]]> http://www.nightowl.pe.kr/blog/article/406 http://www.nightowl.pe.kr/blog/article/406
제 프로그램 중에서 이 기능을 이용하는 프로그램이 두 개 있습니다. 하나는 클립보드의 내용을 선택적으로 저장해 두었다가 나중에 다시 쓸 수 있도록 하는 Clipboard Drawer 이고, 다른 하나는 스크린 캡쳐 & PNG 파일로의 저장을 마우스 클릭 한 번으로 처리하려 만든 PrintScreen & Autosave 입니다. (귀찮다는 이유로 더 귀찮은 짓을 해버리는 기묘한 인간을 보고 계십니다.)

* Clipboard Drawer : http://www.nightowl.pe.kr/software/clipdrawer
* PrintScreen & Autosave : http://www.nightowl.pe.kr/software/prtscrsave

이렇게 클립보드로 들어간 데이터는 특정 CPAN 모듈 (Win32::Clipboard) 을 이용하여 불러온 후 파일로 저장할 수 있습니다. 바로 비트맵 파일로 저장도 가능하고, 만약 (저처럼) 디스크 용량 차지의 문제라던가, 기타 활용을 위해서 PNG 파일로 저장을 원할 수도 있습니다. 바로 비트맵 파일로 저장한다면 굳이 다른 모듈을 쓸 필요도 없이 데이터를 그대로 저장하면 되고, PNG 파일로 압축하여 저장하고자 할 때에는 제가 Win32::GUI 모듈을 이용하여 GUI를 구현하고 있으므로, (굳이 별도로 GD 모듈까지 동원할 필요 없이) Win32::GUI 모듈에 포함되어 있는 Win32::GUI::DIBitmap 모듈을 이용하면 됩니다.

그런데, 무신경하게 코드를 짜고 테스트를 하다가, 좀 미묘한 문제를 만났습니다. 예전에 PrintScreen & Autosave 프로그램을 만들어 테스트할 때도 발생했던가 싶은 문제인데 그동안 잊고 있다가, 최근 Clipboard Drawer 프로그램을 만들면서 똑같은 문제를 맞닥뜨렸습니다. 다음 그림을 보시죠.

[첨부 이미지가 있습니다.]

위 이미지는 현재 제 바탕화면을 찍은 것입니다. 위쪽 화면은 다른 프로그램을 이용해 저장한 스크린샷이고, 아래쪽 화면은 PrintScreen & Autosave (0.0.2.0) 프로그램으로 제 바탕화면을 찍은 것이죠. 뭔가 다릅니다. 지금 저렇게 보니까 그나마 이미지가 있어 보이는데, 정확히는 아래 그림의 하얗게 보이는 부분을 이미지 뷰어로 읽으면 죄다 투명 픽셀로 처리되어 보이지 않게 되어 버리는 것입니다. 예를 들면 아래와 같이 나온다는 거죠.

[첨부 이미지가 있습니다.]

대체 문제가 뭘까요? 일단 코드를 보시죠. PrintScreen & Autosave 프로그램의 해당 부분의 코드는 다음과 같이 되어 있습니다. 이미 캡쳐된 이미지는 클립보드에 들어와 있다고 가정합니다.

1: use Win32::GUI::DIBitmap;
2: use Win32::Clipboard();
3:
4: my $Filename = GetDateTime(time);
5: my $bitmap = Win32::Clipboard::GetBitmap();
6: my $dib = newFromData Win32::GUI::DIBitmap ($bitmap);
7: undef $bitmap;
8:
9: $dib->SaveToFile("$Filename.png", FIF_PNG ); # 알아서 저장하므로 FIF_PNG는 없어도 된다.
10: undef $dib;
11: undef $Filename;


GetDateTime 서브루틴은 그냥 지금 현재 날짜,시간을 확인하여 파일명으로 사용할 수 있도록 YYYYMMDDHHMMSS 의 형태로 돌려주는 서브루틴이므로 신경쓰지 않으셔도 됩니다. 라인 5에서 클립보드의 데이터를 비트맵으로 읽어오고, 이를 라인 6에서 다시 받아 Win32::GUI::DIBitmap 객체로 되돌립니다. 그리고 이를 라인 9에서 PNG 파일로 자동 변환하여 저장합니다.

코드 자체에는 아무런 문제가 없어 보입니다. (실제로 없습니다. 한번 실행해 보세요. 단 4열의 파일명 정하는 코드는 적절히 수정하시고요. 물론 Win32::GUI 와 Win32::Clipboard 모듈은 CPAN에서 받아서 설치하시고..) 그런데 이 코드로 스크린샷 찍었다 하면 저 위 그림과 같은 난리가 나 버립니다.

도대체 문제가 뭘까 하고 이것저것 찾아보다가, 바로 위 그림의 이미지 뷰어 - Imagine - 덕분에 문제 해결의 힌트를 얻었습니다. 아래 그림은 Imagine 에서 보여주는 상태 표시줄의 파일 정보인데, 위쪽 그림은 정상적으로 보이는 스크린샷 파일의 정보이고, 아래쪽 그림은 문제를 일으키는 스크린샷 파일의 정보입니다.

[첨부 이미지가 있습니다.]

원인은 24bit와 32bit의 차이였습니다. 즉, Win32::GUI::DIBitmap 모듈이 내부적으로 비트맵 데이터를 처리하는 과정에서 비트수를 늘린 덕에 이런 문제가 발생했다는 것입니다. 비트맵 이미지를 저장하기 전에 데이터를 강제적으로 24비트로 다운시키는 코드를 삽입한 후 문제가 해결되었습니다.

1: use Win32::GUI::DIBitmap;
2: use Win32::Clipboard();
3:
4: my $Filename = GetDateTime(time);
5: my $bitmap = Win32::Clipboard::GetBitmap();
6: my $dib = newFromData Win32::GUI::DIBitmap ($bitmap);
7: undef $bitmap;
8: my $to24bits = $dib->ConvertTo24Bits(); # 24비트로 비트 수 다운그레이드
9: undef $dib;
10:
11: $to24bits->SaveToFile( "$Filename.png", FIF_PNG ); # 알아서 저장하므로 FIF_PNG는 없어도 된다.
12: undef $to24bits;
13: undef $Filename;


정리하자면, 처음에는 비트맵 데이터를 막바로 BMP로 저장하다가(Win32::GUI::DIBitmap 모듈을 사용하지 않고 비트맵을 바로 raw 모드로 저장하면 이런 문제는 발생하지 않습니다), 스샷 하나에 3메가바이트씩 먹어대는 걸 보고 기가 질려서, 늘상 사용하던 모듈을 이용해 PNG 파일로 저장하도록 수정하려다가 겪은 묘한 문제였습니다.

한줄 요약 : Win32::GUI::DIBitmap 모듈로 클립보드 비트맵을 처리할 때는 반드시 비트수 다운그레이드를 하세요.

** 이 글은 네이버 Perl Community & Study 카페에도 등록되어 있습니다. ]]> Perl Win32::GUI Perl 24bpp DIBitmap Clipboard 32bpp 클립보드 Thu, 24 Nov 2011 00:24:41 +0900 <![CDATA[ 인터넷 컨텐츠 제작자 사용설명서 (by 부엉이) ]]> http://www.nightowl.pe.kr/blog/article/405 http://www.nightowl.pe.kr/blog/article/405 1. 서설

꽤 오랫동안 알고 지낸 자막제작자 녀석이 드디어(?) 한 소리 하고 나섰다. 새로 잡은 작품이 예상 외의 인기(?)를 끌면서 덤으로 (많은 숫자는 아니지만) 반갑지 않은 손님들까지 따라들어오신 모양인데, 자막이 늦게 나온다고 자막을 독촉하는 방문자들이 생긴데다, 자막이 늦는다는 이유로 인격모독 발언을 서슴지 않는 방문자까지 있는 모양이다. 무슨 빚 받으러 온 채권자도 아니고.

요즘이야 그런 일로 시달릴 일이 별로 없지만, 나도 인터넷상에 이것 저것 만들어서 공개해 온 입장에서, 사실 그 녀석의 속을 이해할 수 있을 것 같다. 무슨 갑-을 관계도 아닌데 이것저것 요구하고 따지고 드시는 분들 덕에, 속이 시꺼멓게 탔던 적이 두어 번 정도 있으니... 그런 이유로, 평소에 많이 생각을 하던 주제이기도 해서, 마침 계기도 생겼고 하니, 또 한번 내 생각을 풀어놓아볼까 한다. 일단 먼저, 인터넷 컨텐츠 제작자가 풍파에 망가져가는(...) 모습을 한 차례 조감해 보고, 그 원인과 해결 방안을 풀어보도록 할 것이다.



2. 인터넷 컨텐츠 제작자, 그들은 누구인가.

다 아는 사실이지만 짚고 넘어가도록 하자. 인터넷 컨텐츠 제작자(Internet Contents Creator/Provider,). 이렇게 라고 하면 무언가 거창해 보이는데, 사실 별 대단할 것도 없다. 인터넷 상의 공간에 자신의 창작물을 공개하는 사람들이라면 모두 다 인터넷 컨텐츠 제작자다. 창작물이 무엇인지, 얼마만큼의 시간과 노력이 투입되었는지, 금전적인 대가를 받는지 여부는 전혀 관계 없다. (오히려, 금전적인 대가를 받지 않는 사람이 거의 대부분이겠다. 영리목적의 회사가 아니라면.) 인터넷상에 그림, 음악 등을 만들어 공개하는 사람, 외국어로 된 컨텐츠를 번역해서 공개하는 사람, 유용한 프로그램을 제작하여 공개하는 사람 등이야 당연한 것이지만, 블로그에 잡문을 끄적이는 사람일지라도 그것을 이용하는-읽는-사람이 있다면 당연히 인터넷 컨텐츠 제작자의 범주에 포함시킬 수 있다.

그렇다면, 이 부류의 사람들은 무엇을 위해서 이런 일을 하는 것일까? 전혀 금전적인 이익을 얻을 수 없는(혹은 얻고 싶어하지 않는) 일에 시간과 노력을 투자하는 이 사람들의 심리는 과연 무엇일까? 개인마다 그 동기와 목적은 천차만별일 것이다. 개인적인 공부를 위해서, 미래의 직업을 위한 사전 준비로써, 단순한 개인적인 만족/보람을 위해, 누군가 필요한 사람이 있을 것 같아서, 그냥 유명해지고 싶어서 등등 백이면 백 그 동기는 제각각일 것이라고 생각한다. 그러나 어떠한 경우이든, 자신의 노력이 들어간 유무형의 결과물을, 그것을 필요로 하는 사람이 이용할 수 있도록 공개해 놓았다는 점에서는 어느 정도의 봉사 마인드가 내재되어 있다고 할 수 있다. (이하 인터넷 컨텐츠 제작자는 모두 "제작자"로 줄여서 쓰도록 하겠다.)



3. 무보수 노동으로 망가져가는 제작자

이제 인터넷 컨텐츠 제작자가 인터넷상에 등장하면서부터, 이들이 처참하게 사라지기까지의 과정을 조감해보도록 하겠다. 글이 조금 도발적일 수는 있지만, 누구나 크든 작든 결국 겪게 되는 일이어서 가감 없이 적기로 한다.

제작자라면 누구나 시작은 그러했을 것이다. 인터넷상에 공개된 자신의 컨텐츠를 누군가 이용하고 - 즐기고 - 있다는 사실만으로도 무언가 큰 일을 한 것 같은 보람을 느끼던 시절이 있었을 것이다. 컨텐츠 이용자들이 늘어가면서 어느 수준까지는 제작자도 신바람이 난다. 이용자들로부터 듣게 되는 격려와 감사의 말은 그 무엇보다도 큰 힘이 된다.

그러나, 그런 즐거운 시절은 생각보다 오래 가지 못한다. 자신의 컨텐츠를 이용해주는 사람이 늘어나면서, 해야 할 일도 하나둘 늘어간다. 여러 가지 요구들이 줄을 잇기 시작한다. 새로운 컨텐츠의 제작 요청, 기존 컨텐츠의 개정 요구, 이용자의 개인적인 요망사항 등. 처음 몇 번이야 조금 무리한 부탁이라도 즐겁게 들어줄 수 있다. 그러나 웬걸. 차츰 늘어나는 갖가지 요구사항들은 점점 부담으로 쌓이기 시작한다. 여가선용의 차원에서 시작한 일이 점점 본업을 잡아먹기 시작하고, 처음엔 그저 고맙기만 하던 컨텐츠 이용자들이 점점 스트레스의 원인요소가 된다. 제작자의 사정 따위 안중에도 없는 이용자들은 자신이 원하는 시기에 컨텐츠를 이용할 수 없다는 이유로, 혹은 자신의 요구를 들어주지 않는다는 이유로 듣기 싫은 소리를 풀어놓기 시작한다. 급기야는 욕설이 오가고, 싸움이 벌어진다. 이런 루프가 몇 번 반복되고 심화되면, 어느 순간 몸과 마음이 지친 제작자는 그동안 공개했던 모든 자료를 지우고 인터넷 세상을 등지게 된다. 이로서 또 한 편의 비극이 완성된다.

사실 대부분의 무료 인터넷 컨텐츠 제작자들의 작업의 동력은 나의 작업물이 누군가에게 도움(즐거움)이 되고 있다는 보람과 자부심일 것이다. 아무리 본인의 만족을 위해 작업을 한다 하더라도, 이런 부수적인 감정이 없다면 일을 계속해나가기 쉽지 않다. 그러나 어느 순간, 밀려드는 여러 가지 요구들은 이런 "봉사"를 "무보수 노동"으로 만들어버리곤 한다. 이용자의 요구에 맞추느라 무리하게 개인 시간을 쪼개 가며 무언가를 진행하다 보면, "내가 이 짓을 왜 하고 있나." 류의 생각에 짜증이 나게 마련이다. 이렇게 여가활동이 "무보수 노동"이 되는 순간, 그 컨텐츠는 생명력을 잃게 된다.



4. 비판과 비난 사이 - 제작자가 망가져가는 또 다른 과정

대개 영리를 목적으로 하지 않는 인터넷 컨텐츠 제작자들은 그 분야에 관심이 있는 아마추어인 경우가 많다. (일부 프로페셔널들이 자신의 여가선용을 위해 이런 활동을 하는 경우도 있으나, 그렇다고 해서 이 논지에 영향을 받지는 않는다.) 따라서 그 컨텐츠는 흠잡을 데 없는 작품이라기보단 어딘가 부족한 점이 보이는 그런 결과물인 경우가 보통이다. 인터넷 세상은 넓고, 특정한 분야에 뛰어난 실력을 갖춘 사람은 반드시 있게 마련인지라, 종종 컨텐츠 제작자에게 컨텐츠의 부족한 점이나 잘못된 점, 개선해야 할 점을 피드백해 주는 이용자들이 반드시 나타나게 되어 있다.

이런 피드백은 대개는 제작자에게는 큰 도움이 된다. 대개 무언가를 만드는 사람들에게는 묘한 고집이 있게 마련이라, 스스로의 의지로 작업한 결과물이 어딘가 부족한 점이 있다면 자신이 할 수 있는 한도 내에서는 최대한 이런 단점을 수정하려 한다. (개인적으로는 이걸 "쟁이 근성" 이라고 부른다.) 그것이 자신이 파악하지 못한 단점이라면 더욱 그러한데, 이런 과정을 통해서 컨텐츠의 완성도는 점점 더 높아지고, 제작자의 만족도 역시 상승곡선을 탄다. 그 반사적인 이익으로서 컨텐츠 이용자 역시 질적으로 더 나은 컨텐츠를 이용하게 되는 선순환이 발생하게 된다.

여기까지만 보면 참으로 아름다운 모습인데, 유감스럽게도 세상은 그렇게 만만하지가 않다. 익명성 속에 숨은 일부 컨텐츠 이용자들의 악의적인 피드백이 하나둘씩 섞여드는 게 문제이다. 뭐 하나 생산적인 내용은 없는, 비난으로 시작해서 비난으로 끝나는(예쁘게 표현해서 그렇지, 실상은 욕으로 시작해서 욕으로 끝나는) 피드백이 하나둘 쌓이다 보면 제작자는 "내가 뭣 때문에 이런 욕 들어먹어가면서 이 짓을 하고 있나."라는 생각이 들게 마련이다. 백 개의 격려와 도움이 되는 충고가 있더라도, 그 사이에 섞여 있는 한두 개의 악의적인 비난에 전체가 묻혀버리는 것은 제작자 역시 인간이기 때문에 겪게 되는 어쩔 수 없는 현상이다. 이렇게 점점 제작자는 회의주의자로 변해간다.



5. 화성에서 온 제작자, 금성에서 온 이용자.

제작자와 이용자가 갈등을 빚게 되는 표면적인 요인은 참으로 다양하다. 이용자들의 요구사항으로 인한 갈등, 컨텐츠의 낮은 질로 인한 갈등, 기타 이용자와 제작자 사이의 인간적인 갈등 등 참으로 다양한 형태로 갈등이 나타나곤 한다. 그러나, 이런 모든 갈등은 하나의 핵심적이고도 근본적인 요인으로 수렴될 수 있다고 생각한다. 바로 "특별함"을 둘러싼 서로간의 어긋남이다.

대부분의 컨텐츠 이용자들은 컨텐츠 제작자에게 있어 자신이 특별한 존재이길 바라며, 또한 자신이 실제로 특별한 존재라고 생각하는 경향이 있다. 자신에게 발생한 문제는 아무리 사소한 문제라도 커 보이게 마련이고, 그런 자신을 위해서 컨텐츠 제작자가 무언가 해결 방안을 제시해주기를 바란다. 그것도 빠른 시간 안에 해결이 되어야 한다. 꼭 나 혼자에게만 문제가 발생하는 것 같고, 수많은 사람들 사이에서 나 혼자만 손해보는 느낌이다. 그 결과, 해결이 늦어지거나 해결이 불가능한 상황이 되면 이유여하를 불문하고 안 좋은 감정이 생기는 건 인간이기에 어쩔 수 없는 일이다.

그러나 제작자의 입장은 다르다. 어떤 한 이용자는 자신의 컨텐츠를 이용하는 수 많은 사람들 중 한 사람일 뿐이며, 그 결과 그 사람은 제작자에게 있어서 전혀 특별한 사람이 아니다. 자신의 컨텐츠 이용자가 어떤 문제를 겪고 있다고 하더라도, 제작자에게 있어서 그 문제는 자신의 작업 목록에서 반드시 높은 우선 순위를 가져야 할 이유가 없다. 그 일이 아니라도 이미 수없이 많은 문제가 제작자를 괴롭히고 있을 수도 있다. 이런 와중에, 특정 이용자로부터 자신이 겪는 문제에 대해서 즉각적인 반응을 보이지 않는다는 이유로 싫은 소리를 듣는다면 제작자의 기분이 좋을 리 없다. 제작자는 오히려 그 문제의 해결을 가장 후순위로 밀어버리고 싶은 기분이 들 것이다.

이런 어긋남은, 자신의 감정에 충실할 수밖에 없는 인간으로서는 어쩌면 당연하다. 이는 당사자들의 지적 수준이나 양식과도 그렇게 큰 관계는 없어 보인다. 아니, 모든 것을 알고 이해하는 사람일지라도, 이런 경우를 당하면 "머리로는 이해하나 가슴으로는 이해하지 못하는"것이 인간의 본성일지도 모른다. 그리고 이런 불만이 일방이건 쌍방이건 표출되는 순간 갈등은 표면화된다.



6. 제작자에게는 어떠한 의무도 없다.

이 얽힐대로 얽혀버린 실타래를 어디에서부터 풀어나가야 할 것인가. 일단 제작자가 직업적으로 (갑-을 계약관계를 맺고) 금전적 대가를 받으면서 이 일을 하고 있는 것이 아님은 확실하다. 애초에 컨텐츠를 공개한 것도 단지 봉사일 뿐, 그것으로써 어떤 권리의무 관계가 생기는 것이 아니다. 설사 그 사람이 그 분야에 있어서 프로페셔널의 지위를 점하고 있는 자일지라도, 그가 어떤 대가를 받고 제공하는 컨텐츠가 아닌 이상 결론은 달라지지 않는다. 따라서, 컨텐츠에 어떤 문제가 있어서 이용자가 컨텐츠를 이용하는 데 장애가 발생한다 하더라도 제작자에게 이를 해결해 주어야 할 의무가 있는 것도 아니며, 이용자가 어떤 요구를 한다 하여 제작자가 이를 받아들여야 하는 의무도 없다.

물론 앞에서 잠깐 내비친 바 있지만, 대개의 제작자들은 묘한 "쟁이 근성"을 갖고 있게 마련이다. 스스로 자신의 이름을 걸고 자발적으로 시작한 일인 이상, 자신의 컨텐츠에 어떤 문제가 있다면 자신이 가능한 한도 내에서는 어떻게든 그 문제를 해결하려 한다. 묘한 고집이지만, 많은 컨텐츠 제작자들에게서 거의 공통적으로 볼 수 있는 특성이다. 그래서 보통은 이용자에게 일정한 피드백을 받길 원하고, 또 그러한 소통으로부터 즐거움과 보람을 얻곤 한다.

그러나 이것은 제작자의 일반적인 속성이라는 것이지, 이로부터 제작자가 "반드시" 이용자의 요구사항을 수용해야 한다거나, 질적으로 일정 이상의 수준을 갖는 결과물을 내놓아야 할 의무를 도출할 수는 없다. 제작자가 요구사항을 수용하지 않는다거나, 컨텐츠의 질이 수준 이하라고 하여 컨텐츠를 이용하려는 자가 제작자를 비난할 권리는 없다. 단지 해당 컨텐츠를 사용하지 않으면 될 뿐이다. 누가 그 컨텐츠를 꼭 쓰라고 강제라도 하던가?

물론 컨텐츠 이용자의 비판할 자유를 틀어막겠다는 것은 아니다. 사용해 본 컨텐츠가 수준 이하라거나, 어떤 문제점이 있을 때 이를 비판할 수 있는 자유는 일반적인 언론자유로서 보장되는 것이다. 그러나 그렇다고 하여 제작자를 인격적으로 비난하거나 모욕할 자유가 주어진 것은 아니다. 어떤 컨텐츠를 이용할 "권리"나, 어떤 컨텐츠를 이용해야 할 "의무"가 없는 이상, 본인이 그 컨텐츠를 사용하지 않는 수준을 넘어 해당 컨텐츠를 비난하고 싶다면 그 비난은 비난하는 자 스스로 정당화시켜야 한다. 제작자의 인격권과 공익이 조화를 이루는 범위 안에서 이루어지는 이유 있는 비판이라면 그런 비판은 얼마든지 정당화될 수 있다. 그러나 그 수준을 넘는 일방적인 비난과 모독은 제작자의 인격권을 심각하게 침해하는 불법행위로써, 그 수준에 따라서는 당사자가 민형사적인 책임을 감수해야 할 수도 있다.

착각하지 말자. 어떠한 사실이 있다고 하더라도, 그러한 사실로부터 반드시 그러해야만 하는 당위를 도출하기 위해서는 추가적인 논증을 필요로 한다. 제작자가 어떤 컨텐츠를 공개했다 하더라도, 그로 인하여 그에게 어떤 의무를 지울 수는 없다. 거창하게 "네티즌과의 약속" 운운하지 말자는 이야기다. 사실은 왜 내가 원하는 시기에 컨텐츠를 이용할 수 없느냐는 지극히 사적인 불만에 불과하면서, 왜 그렇게 애써 포장하나.



7. 결론. 인터넷 컨텐츠 제작자 사용설명서

사실 제목이 부적절하다. 제작자가 무슨 물건도 아닐진대, 사용설명서 운운하는 것은 자기 무덤을 파는 짓이나 마찬가지이다. 너무나 잘 안다. 그러나, 그럼에도 불구하고 이런 제목을 단 이유는, 최소한 이 정도는 기본적으로 알고 지켜줘야만 서로 윈윈할 수 있다는 강조의 의미에서이다. 이 정도도 서로간에 지켜주지 않으면 어느 사이엔가 몸과 마음이 고장나 있는 제작자를 보게 될 것이다. 블로그 폐쇄는 기본 옵션으로 따라오겠지. (^^)

* 독촉, 무리한 요구 금지. 제작자는 컨텐츠 제작을 직업으로 하는 사람이 아니다. 단지 여가선용으로써 하고 있을 뿐이다. 이 것 아니라도 안 그래도 바쁘다. 시간이 나더라도 쉬어야 할 때가 있다. 무슨 원고 마감 독촉하는 편집장처럼 왜 다음 컨텐츠가 안 나오냐고 독촉해 봐야 안 나온다. 성격 나쁜 제작자라면 오히려 이로 인해 그 일을 한없이 후순위로 밀어놓을지도 모른다. 아까도 이야기했지만, 당신은 절대로 특별한 사람이 아니다. You are not special. 컨텐츠를 독촉할 권리 같은 건 당신에게 없다.

무리한 요구 역시 마찬가지다. 어떤 문제가 있다면 제작자에게 피드백을 하는 것까지는 좋다. 이렇게 하면 더 좋겠다는 것들도 좋은 피드백 거리다. 그러나 거기까지다. 그에 대해 제작자에게 어떤 행동이나 답변을 바라지 말라는 것이다. 웬만큼 명예감정이 있는 제작자라면 들어온 피드백을 그냥 보아넘기지 않는다. 독촉하고 요구하지 않아도 안 그래도 짬짬이 머리 싸매고 고민 중일 것이다. 아니면 말고. 아니라도 할 수 없다.

* 마음에 들지 않는다면 사용하지 않으면 된다. 보통의 경우 그 컨텐츠를 이용하지 않더라도 다른 대체할 만한 컨텐츠가 어딘가에 있게 마련이다. 부족한 점을 피드백하는 것을 넘어서 인신 공격을 퍼부을 권한은 당신에게 없다. 아무리 질적으로 부족한 컨텐츠라도 집어 치우라고 말할 권한도 없다. 피드백할 가치도 없다고 생각한다면 그냥 조용히 뒤로 가기 버튼을 누르란 말이다.

누군가는 그레샴의 법칙 - 악화가 양화를 구축한다 - 을 들어 질 낮은 컨텐츠를 공격하곤 한다. 이 사람이 이런 질 낮은 컨텐츠를 만들지 않았으면 다른 누군가가 더 좋은 컨텐츠를 만들었을 텐데, 이 사람이 이런 것을 내놓는 바람에 다른 사람들이 더 좋은 것을 만들 생각을 안 한다는 논리다. 참으로 엉뚱한 데다 화풀이를 하고 있다. 이 사람이 안 만든다고 다른 사람이 만들어주리라는 보장은 어디에도 없으며, 게다가 대체물이 있다 하여 그것의 질이 원래의 그것보다 좋으리라는 보장도 없다. 이런 분들이 주로 하는 생각이 "너 아니라도 할 사람 많다." 다. 글쎄? 진짜로 할 사람이 없을 수도 있다. 이렇게까지 말하고 싶진 않지만, 본인이 능력이 있다면 한번 직접 해 보시라.

* 비판할 때 하더라도 비난은 자제하자. 정당한 비판도 듣지 않는 제작자, 있을 수도 있다. 대개는 속이 좁은 인간이거나, 아직 인격적으로 성숙하지 못하였거나, 혹은 제 잘난 맛에 사는 사람이다. 어떤 유형이든, 어차피 무슨 말을 해도 안 들을 사람이니 공연히 힘 빼지 말자. 감정적 비난과 인신공격이 등장하는 순간 조용하던 게시판은 싸움판이 된다. 여러 사람 피해주는 짓이다. 싸움 구경이 재미있는 사람도 있을 지 모르지만, 싸움 구경이 짜증나는 사람도 세상엔 많다. 어떤 사람은 열심히 제작자의 블로그나 공식 배포 페이지에까지 찾아와서 작정하고 싸움을 일으키는데, 민폐도 그런 민폐가 없다. 이건 아예 인터넷 세상의 사회악이다.



인터넷 생테계에 컨텐츠가 없다면 인터넷이 존립할 수가 없다. 그런 의미에서 인터넷 컨텐츠 제작자들은 인터넷 생테계를 떠받치고 있는 사람들이다. 이 사람들이 의욕을 가지고 활동할 수 있어야만 인터넷이 풍성해지고, 이용자들의 효용 역시 증가하게 마련이다. 게다가, 인터넷 세상은 절대 일방적으로 흐르지 않는다. 당신이 항상 인터넷 컨텐츠 이용자이기만 할 것 같은가? 인터넷의 특성상 당신도 언제라도 컨텐츠 생산자가 될 수 있다. 역지사지의 사고를 하지 않으면 언젠가 되로 주고 말로 받는 사태가 벌어질지도 모른다. ]]> 정리된 생각 컨텐츠 사용자 컨텐츠 생산자 관계 Sat, 19 Nov 2011 02:22:41 +0900 <![CDATA[ NexusOne : 루팅부터 커스텀 롬 적용까지 (by 부엉이) ]]> http://www.nightowl.pe.kr/blog/article/404 http://www.nightowl.pe.kr/blog/article/404 이 글은 개인적인 참고를 위한 단순정리요약글로써, 경험자나 어느 정도 지식이 있는 분이 아니면 단순한 따라하기 식으로 맞추다가 발생할 수 있는 돌발상황에 대처가 어렵습니다. 자세한 내용을 알기를 원하시면 하단에 링크된 원문들을 보십시오.





0. 순정펌으로 되돌리기 - 기본

(1) SD카드 루트에 순정펌 이미지를 PASSIMG.ZIP 으로 이름을 바꾸어 저장한다.
(2) 넥서스원 재시작. 이 때 [전원]버튼과 [볼륨 다운]버튼을 계속 누르고 있는다.
(3) 자동으로 저장되어 있는 PASSIMG.ZIP 을 인식하여 읽어들인다.
(4) 복구할까요? 라는 질문에 당연히 예. ([볼륨 업]버튼이다.)

* 2.3.3-GRI40(진저브레드) 순정 이미지로 한번이라도 복구하면 다시는 프로요 순정 이미지를 이용하여 복구 모드 구동이 불가능하다. (그러나 사실 프로요 2.2.1로 돌아가야 할 일이 있을지는 모르겠다.)
* 현재 진저브레드 순정펌을 사용중이라면 굳이 커스텀 펌 설치를 위해 되돌릴 필요 없다. 다만 중간에 문제가 발생했을 시 초기상태로 되돌리기 위해 반드시 알아야 한다.
* KT 정식발매 순정 롬은 다음 링크에서 구할 수 있다.
   - 2.2.1 (프로요) [링크: shipped-roms]
   - 2.3.3 (진저브레드) [링크: shipped-roms]



1. 진저브레드 루팅하기

* GingerBreak 1.20 : [첨부 파일 링크가 있습니다.]

(1) GingerBreak 1.20을 SD카드에 저장하고 실행하여 설치한다.
   - 적당한 파일 관리자가 필요할 수 있다. (OI 파일 관리자나 Root Explorer 등.)
   - 설치 전 [설정]-[애플리케이션]-[알 수 없는 소스] 에 체크 필수.
(2) 설치된 GingerBreak 를 실행하여 루팅 절차를 시작한다.
   - 루팅 전 [설정]-[애플리케이션]-[개발]-[USB 디버깅] 에 체크 필수.
   - 컴퓨터에 USB로 연결된 상태여야 한다. 따라서 SD카드 마운트 필수.
   - 루팅이 완료되면 자동으로 리부트된다. (오래 안 걸린다. 5분 이상 걸린다면 뭔가 문제 있음.)
   - 재시작 후 앱 목록에 해골바가지 SuperUser 가 생겼다면 성공.



2. 리커버리 설치

(1) 마켓에서 Rom Manager 를 받아 설치한다.
(2) Rom Manager 실행.
(3) [ClockWorkMod 복구 모드의 설치] 클릭 후 단말기 (Google Nexus One) 선택
   - 3G 모드라면 경고가 뜨지만 가볍게 무시.
   - 다운로드가 끝나자마자 SuperUser 가 뜨는데 바로 승인(Allow)
(4) 일단 Rom Manager 를 종료한 후 다시 실행.
(5) App2SD 설치를 위해서 SD파티션을 나누기 위해, RA Recovery 2.2.1 을 설치
   - 종료 했다가 다시 실행하지 않으면 [대체 복구 모드의 설치]가 활성화 안됨.
   - [대체 복구 모드의 설치] 클릭. 경고메시지는 그냥 확인으로 패스.
   - 다운로드가 끝나자마자 SuperUser 가 뜨는데 바로 승인(Allow)
(6) 리커버리 설치 완료. [복구 모드로 다시 시작] 을 클릭하여 복구 모드를 실행한다.

* 만약 (6)을 실행하면서 낯익은(?) 안드로이드와 느낌표를 만난다면, RA Recovery 가 제대로 설치 안 된 것이므로 배터리 분리 신공으로 재부팅 후 RA Recovery 2.2.1 을 다시 설치해주고 복구 모드를 재시작한다.



3. SD카드의 파티션 나누기

* 주의. 파티션 나누기는 FDISK와 같은 작업이므로, 수행하면 SD카드의 데이터가 다 날아간다. 백업 필수.
* 복구 모드 - RA Recovery 2.2.1 가 실행되어 있어야 한다.
* 메뉴의 이동 및 선택은 트랙볼로 하며, 앞 단계로 돌아가기는 [볼륨 다운]이다.

(1) - Partition sdcard 선택
(2) - Repair SD:ext 실행. 그리고 트랙볼 한 번 더 눌러준다.
(3) - Partition SD 선택 및 실행.
   - Swap-Size 는 반드시 0 으로 한다.
   - Ext2-Size 는 1024~1920 사이로 해 준다. (권장사항?)
   - 이미 Ext2 파티션이 존재하고 이를 부수고 싶다면 Ext2-Size 도 0.
   * 만약 이 설정을 잘못했다면 "절대로 파티션 나누다 말고 재부팅하지 말고" 일단 파티셔닝을 마친 후 0/0 설정으로 파티션을 부수고 재설정한다. 그냥 재부팅했다가는 난리난다.
   - 파티션 작업은 시간 좀 걸릴 수도 있다. 점 늘어나는 걸 구경하자.
(4) 파티셔닝이 종료되면, 파티션을 ext4 로 업그레이드 해 준다. (ext4가 읽기 성능이 좋다.)
   - SD:ext2 to ext3 클릭.
   - SD:ext3 to ext4 클릭.
(5) 앞 메뉴로 돌아온 후 재부팅.



4. SD카드에 작업에 필요한 파일들을 저장

* 어차피 파티션 재설정 과정에서 다 날아가므로, 이전에 롬 파일 등을 저장해둘 필요가 없었다.

(1) 문제 생길 때를 대비하여, 순정 PASSIMG.ZIP (위에 링크가 있음)
(2) 올릴 커스텀 롬 파일 (CM7.1기반 Neokim 님의 커스텀 롬: [링크: multiupload]
(3) a2sd 스크립트 파일 (2.7.5.2-1) [첨부 파일 링크가 있습니다.]

* app2sd를 사용하며, 캐시만 옮길 것이므로 더 이상 필요 없다.
* 선택하기 편리하도록 커스텀 롬 파일과 a2sd 스크립트 파일도 SD카드 루트에 두자.



5. 롬 올리기

(1) 재부팅 후, 다시 Rom Manager 실행.
(2) [ClockworkMod 복구 모드의 버전 목록] 을 클릭하고, 버전 2.5.1.1 을 선택하여 설치한다.
   - 티모바일 순정롬 올릴 때도 2.5.1.1을 추천하는 것으로 보아 이 버전이 가장 안정적인 듯함.
(3) [복구 모드로 다시 시작] 을 클릭하여 복구 모드를 실행한다.
(4) - wipe data/factory reset 으로 풀 와이프 (일종의 포맷)
(5) 롬 플래싱 작업
   - install zip from sdcard 선택
   - choose zip from sdcard 를 선택하고 롬 파일을 지정
(6) a2sd 파일도 플래싱 작업
   - choose zip from sdcard 를 선택하고 a2sd 파일을 지정
(7) 끝났다. 재부팅.
   - 재부팅을 위해 이전 메뉴로 돌아와야 하는데 이전 메뉴로 돌아오는 버튼이 RA와 다르게 전원버튼이다.
   - reboot system now 선택



6. app2sd(a2sd) 설정 작업

* 커스텀 롬 설치 작업 자체는 이미 끝났다.
* 이제 (필요하다면) 각종 패치 등의 설치만 남았을 뿐?

(1) 아무것도 설치하지 말고 바로 Terminal Emulator 실행.
(2) su 엔터 (관리자 권한)
(3) a2sd reinstall 엔터 - 자동 재부팅 (재설치를 해주지 않으면 나중에 설치한 앱이 날아가는 황당한 경험을 하게 될 수도 있다.)
* 롬 제작자의 권고에 따라서, datasd 는 설정하지 않는다.
(4) 다시 Terminal Emulator 실행.
(5) su 엔터 (관리자 권한)
(6) a2sd cachesd 엔터 (시간 조금 걸린다) - 자동 재부팅
(7) 다시 Terminal Emulator 실행.
(8) su 엔터 (관리자 권한)
(9) a2sd zipalign 엔터. 프롬프트 # 가 다시 나타나면 터미널 에뮬레이터 종료





* 정리에 사용된 원문들 (네이버: 카페 가입 필요):
http://cafe.naver.com/ArticleRead.nhn?clubid=19859404&articleid=360778
http://cafe.naver.com/ArticleRead.nhn?clubid=19859404&articleid=360780
http://cafe.naver.com/ArticleRead.nhn?clubid=19859404&articleid=360781
http://cafe.naver.com/ArticleRead.nhn?clubid=19859404&articleid=360785
http://cafe.naver.com/ArticleRead.nhn?clubid=19859404&articleid=360791
http://cafe.naver.com/ArticleRead.nhn?clubid=19859404&articleid=384699
http://cafe.naver.com/ArticleRead.nhn?clubid=19859404&articleid=424565
]]> 컴퓨터 사용 경험 NexusOne Custom Rom CM7 Tue, 15 Nov 2011 05:07:37 +0900 <![CDATA[ Perl / Encode : UTF-8 + BOM 문서를 decode 할 때 주의할 점 (by 부엉이) ]]> http://www.nightowl.pe.kr/blog/article/403 http://www.nightowl.pe.kr/blog/article/403 Perl 5.10 혹은 그 이전 버전에서 모두 발생합니다. 그 이후의 버전은 저도 모릅니다.

Perl의 Encode 모듈에서 decode 함수를 사용할 때, 만약 읽어들이는 문서가 UTF-8 문서라면 주의해야 한다. UTF-8의 경우 굳이 BOM(Byte Order Mark)을 붙이지 않아도 상관이 없는데, 일부 UTF-8 문서의 경우 UTF-8 인코딩을 사용하면서도 BOM이 붙어 있다. (예를 들면, 윈도우의 메모장으로 적성 후 UTF-8 인코딩 문서로 저장한 경우, 자동으로 BOM 이 포함되어 저장된다.)

이 문서를 Perl에서 읽을 경우, decode 되는 과정에서 decode 모듈이 이 BOM을 제거하지 않고 남겨두므로, 이 문자로 인하여 예상치 못한 문제가 발생할 수 있다. (문자열 처리 과정에서 필연적으로 오류를 만나게 된다!) 따라서 UTF-8 문서를 읽을 때에는, decode 한 후에 이 BOM 문자를 날려주는 작업이 별도로 이루어져야 한다.

sub FileRead {

    my $RAW_DATA;
    my $ENCODING;

    open my $fHandle, "<", "$_[0]";
    binmode $fHandle;
    while(<$fHandle>){
        $RAW_DATA .= $_;
    }
    close $fHandle;
    undef $fHandle;

    #------------------------

    use Encode;
    use Encode::Guess;

    my $enc = guess_encoding($RAW_DATA, qw/ascii euc-kr utf8/);

    if ( ref($enc) ) {
        $ENCODING = $enc->name;
    }
    else {
        $ENCODING = "Unknown";
    }

    undef $enc;

    #------------------------

    if ( $ENCODING eq "Unknown" ) {

        print "Unknown Encoding!";
        return -1;
    }
    else {

        $RAW_DATA = decode( $ENCODING, $RAW_DATA );
    }

    # UTF8+BOM 주의

    if ( $ENCODING eq "utf8" ) {
        $RAW_DATA =~ s/\x{FEFF}//g;
    }

    undef $ENCODING;

    #------------------------

    return $RAW_DATA;
}


참고로, 역시 BOM이 붙어있는 UTF-16 (윈도우에서 기본으로 사용하는 유니코드. UTF-16 BE(Big Endian)와 UTF-16 LE(Little Endian)이 있으며, 윈도우는 후자를 사용한다.) 의 경우에는 decode 모듈이 자동으로 BOM을 날려주기 때문에, 위와 같은 번거로운 처리가 필요 없다.

* http://perldoc.perl.org/5.10.1/Encode/Guess.html

이 문서의 중간쯤에 관련 경고가 기술되어 있다 - "CAVEAT: Unlike UTF-(16|32), BOM in utf8 is NOT AUTOMATICALLY STRIPPED."

왜 잘 들여다보지도 않는 Guess 모듈 한구석에 적어놓은건지...
]]> Perl Byte Order Mark Perl BOM Encode Sat, 12 Nov 2011 06:54:24 +0900 <![CDATA[ Perl / PAR / Windows : creation of private temporary subdirectory ~ failed 문제 (by 부엉이) ]]> http://www.nightowl.pe.kr/blog/article/402 http://www.nightowl.pe.kr/blog/article/402
1. 문제의 발생

영미권에서 만들어진 프로그램들을 한글 윈도우 상에서 사용할 때에 종종 맞닥뜨리는 문제들은, 상당 부분 이 사람들이 도대체 한글이라는 것의 존재 자체를 계산에 넣지 않는다는 데에서 기인하곤 하는데, 오늘의 문제도 딱 그러하다.

며칠 전 Perl로 짠 어떤 스크립트를 PAR::Packer 를 이용하여 빌드하여 공개를 했다. 그리고 과거 버전에서와 마찬가지로, 이번 버전에서도 어김없이 몇몇 분들이 실행이 안 된다는 피드백을 주셨다. 프로그램이 뭔가 뜨자마자 바로 꺼져버린다는 것이다. 내 시스템에서는 도무지 재현이 안 되는 문제여서 과거에도 해결을 못 하고 넘어갔는데, 똑같은 문제가 계속 발생하자 나도 오기가 발동했다.

2. 삽질의 과정

일단 뭔가 단서가 있어야 했다. 실행되자마자 어떠한 오류 메시지도 없이 그냥 팍 꺼져버리는 것으로 보아, 아마도 PAR::Packer 가 코드의 압축을 푸는 과정에서 문제가 생기는 것으로 추정되었다. (즉 기존의 코드나 라이브러리 문제는 아닌 것으로 판단되었다. 만약 그렇다면 오류 메시지가 떠야 할 테니까.)

바로 피드백 주신 분께 콘솔창이 출력되는 테스트용 프로그램을 보내드린 후, 실행 중 출력되는 오류 메시지가 있는지를 확인해 달라고 부탁드렸다. 아니나 다를까. 출력되는 메시지가 있었는데, 그것은 바로 다음과 같은 메시지였다.

creation of private temporary subdirectory c:\docume~1\ddd\locals~1\temp\par-_ㅐ??temp-2252 failed - aborting with 22.

[첨부 이미지가 있습니다.]


어디서 문제가 발생하는지 일단은 확실해졌다. 기술 문서에 의하면, PAR::Packer 는 실행되면서 소스 코드 및 라이브러리를 사용자 임시 폴더 이하에 풀어놓은 후 이를 해석하여 실행한다. (기본적으로 Perl은 인터프리터 언어이다.) 이 때, 임시 폴더의 이름은 TEMP이하에 "par-사용자 이름"으로 정해지며, 다시 그 밑에 "Temp-####" (####는 임의의 4자리 숫자) 폴더를 만들고 그 아래에 코드들이 복사가 된다. (PAR로 빌드된 여러 개의 프로그램을 돌릴 때 우연히 파일이 겹치지 않도록 하기 위해서 개별 프로그램별로 Temp-#### 라는 임의의 폴더를 더 만드는 것이다.) 정리하면 이런 구조가 된다.

C:\Documents and Settings\UserName\Local Settings\Temp\par-UserName\Temp-####


결국 위 오류 메시지는 결국 코드를 풀어놓기 위한 저 폴더를 못 만들고 있다는 이야기가 된다. 응? 왜?! 공용 임시 폴더도 아닌 개인 임시 폴더에 쓰기 권한이 없을리는 없고..

이해가 안 되어서 신나게 구글링을 돌려 보았지만, 정확히 이것과 맞아 떨어지는 문서는 발견되지 않았다. 아니 이런 오류와 관련된 문서 자체가 없었다. 그러다가 오류 메시지 중간에 뭔가 글씨가 깨진 것이 눈에 들어왔다. 혹시 오타가 아닌가 싶었지만, 출력되는 그대로 쓴 것이라고 했다. 설마?

바로 여쭤보았다. 혹시 윈도우에서 사용자 이름을 한글로 쓰고 계시진 않으신가요? 그렇다는 답이 돌아왔다. 바로 가상머신에 XP를 켜고 한글 사용자 이름을 사용하는 계정을 만든 후 프로그램을 돌려 보았다. 빙고!

3. 문제의 원인

문제는 PAR::Packer 가, 실행 코드를 풀어놓기 위한 폴더를 만드는 과정에서 한글로 된 사용자 이름을 (인코딩 생각 안 하고) 그대로 밀어넣는 데 있었다.

(1) 영문자만으로 이루어진 ASCII 인코딩 사이에 아마도 유니코드(또는 CP949?)로 되어 있을 한글 문자를 무리하게 밀어넣어 폴더 경로를 만들었고,

(2) 그 과정에서 서로 다른 두 종류의 인코딩이 같은 문자열 내에 존재하게 되었으며,

(3) 그 결과 한글 문자가 깨지면서 폴더 이름으로 사용할 수 없는 문자들이 경로 내에 생성.

(4) 깨진 문자가 포함된 경로로 폴더를 만들려는 시도에 윈도우는 당연히 폴더를 만들 수 없다는 오류로 대응.

대략 이런 그림이 그려진다.

4. 해결 방법 (2012/01/30 수정)

그렇다면 해결 방법은? 현재 이 문제는 한국 Perl 커뮤니티에 의해 제작자에게 리포팅 되었고, 다음 버전에서는 수정될 예정이다. 즉, 이 문제 해결을 위해서는 PAR::Packer(필요하다면 PAR 까지)의 업그레이드가 필요하다. 그러나, PAR::Packer 의 소스 수정이 가능하고 현재 시스템에서 C 코드의 컴파일이 가능하다면(PAR::Packer 를 사용 중인 시스템이라면 당연히 가능하다.), 필요한 부분을 직접 수정한 후 PAR::Packer 를 다시 컴파일하여 사용할 수도 있다. 자세한 내용은 필자의 다음 글을 참조하면 된다.

[내부 링크가 있습니다.]

그러나, 지금 이 글을 읽는 독자가 Perl 개발자가 아닌 프로그램 사용자일 뿐이라면, 이 문제를 해결하기 위해서는 그 프로그램 제작자에게 부탁하여 새로운 PAR::Packer 버전을 사용한 실행 바이너리를 얻거나, 자신의 윈도우 사용자 이름을 영문과 숫자만의 문자열을 사용하여 다시 만드는 수밖에 없다. 이름 변경만으로는 해결되지 않고, 반드시 새로운 계정을 만들어야 한다. (레지스트리의 관련 항목을 함께 수정하면 되기는 할 텐데, 이것이 시스템에 다른 영향을 주지 않으리라고 장담할 수가 없다.)

5. 결론

>PAR::Packer 버전 1.012 또는 그 이전 버전으로 빌드된 Perl 스크립트는 윈도우 환경에서 사용자 이름에 한글이 포함되어 있을 경우 실행되지 않는다. 사용자의 입장에서 이 문제를 해결하기 위해서는 만약 이런 경우, 영문+숫자로 이루어진 "새로운" 사용자 계정을 생성하여 그 계정으로 로그인 후 실행해야 하며, 기존의 한글이 포함된 이름을 변경한다고 하여 해결되지 않는다. ]]> Perl 사용자 이름 한글 Perl PAR Sat, 12 Nov 2011 06:32:52 +0900 <![CDATA[ 첫 1차 면접 후기. 경험을 이길 수는 없다. (by 부엉이) ]]> http://www.nightowl.pe.kr/blog/article/401 http://www.nightowl.pe.kr/blog/article/401 어어어 하다 보니, 어느 새 여기까지 왔다. 그리고 아마도 여기가 끝인 듯하다.
지난 9월 20일경부터 시작된, 반쯤은 충동적으로, 반쯤은 절박하게 시작된 입사 작전.
아직 최종전형인 2차면접이 남았지만, 어제 있었던 1차면접 전형으로서 나의 취업시즌은 끝난 것 같다.
(아직 한 군데가 남았다곤 하지만, 그 곳은 현재까지의 상황으로 보아 날 뽑아줄 생각이 없는 것 같으니 패스.)

6인 1조로 들어간 면접장. 상당히 부드러운 분위기였고, 개인에 대한 공격성 질문 역시 없었다.
질문 역시 자기소개서를 검증하는 수준. 그 외에도 당연히 물어볼 만한 질문들이었다.
10여년 전의 입시 면접보다도 더 부드러운 면접이었다고 자신있게 말할 수 있다.
내가 항상 껄끄러워하는 외국어(영어)면접도 없었다.

그러나, 대답은 만족스럽지가 않았다.

자기소개부터 목에서 막혀서 준비한 자기소개도 제대로 못 하고,
너무나 잘 알고 있는 질문이 나오는데도 알고 있는 지식의 반도 뽑아내지 못 하고,
질문의 의도가 빤히 보이는데도 그걸 넘어서지 못하고 본심을 그대로 보이고 마는...

같은 면접조에 있던 - 여러 번의 면접 경험으로 단련된 듯한 - 다른 지원자들과 너무 차이나는 행보를 보이고 말았다.
스스로에게 맥이 빠져서, "마지막으로 할 말이 있으면 해 보라"는 질문에 "더 이상 할 말 없습니다." 라고 해 버리는 실수까지. 분명 마지막으로 할 말이 한 다스는 있었는데도.

그야말로 면접장에서 할 수 있는 온갖 실수란 실수는 종합선물세트로 해 버린 셈이다.
이러고서 합격을 바랄 수는 없지.

연구하면 할 수록 매력적인 회사였고, 꼭 들어가고 싶은 회사였던데다,
올해의 채용으로 앞으로 몇 년간은 채용이 없을 것이 거의 확실시되는 회사이기에 더욱 속이 쓰리다.

어쨌거나, 좋은 경험이었지만, 그 경험의 대가가 너무 컸다. ]]> 이런저런 이야기 1차면접 Thu, 27 Oct 2011 04:00:56 +0900 <![CDATA[ Perl / Windows / Unicode : Perl 을 통해 윈도우즈 유니코드 텍스트 저장하기 (by 부엉이) ]]> http://www.nightowl.pe.kr/blog/article/400 http://www.nightowl.pe.kr/blog/article/400
1. 유니코드에도 종류가 있다.

세계표준이라는 유니코드에도 온갖 종류가 있다. (자세한 내용은 참고문서 참조.) 그 중에서 윈도우즈에서 사용하고 있는 인코딩 방식은 UTF-16 LE 라고 하는 방식이다. (단, 윈도우즈 2000 이후의 윈도우즈를 의미함. 윈도우즈 98/SE 및 그 이전의 윈도우즈에서는 유니코드를 지원하지 않았다.) 윈도우즈에서 사용하는 표준 유니코드 형식으로 텍스트를 저장하기 위해서는 UTF-8을 UTF-16 LE 로 변환하는 작업을 거쳐야 한다.

참고로, 이 예제 소스의 모든 인코딩은 euc-kr(ansi) 였기 때문에, 초기에 문자열의 decode 를 euckr 인코딩으로 했다. 만약 사용자가 이 소스의 인코딩을 UTF-8로 저장하였다면 해당 부분은 utf8 로 설정하여야 한다.

use Encode;

my $TEXT = encode( "UTF-16LE", decode( "euckr", "This is the test of saving unicode text. 유니코드 텍스트 저장 테스트입니다." ) );

open my $fHandle, ">", "test.txt";
print $fHandle $TEXT;
close $fHandle;



2. 문제점 : Byte Order Mark (BOM)

그러나, 실제로 위의 코드를 실행한 후, 만들어진 test.txt 파일을 메모장으로 열어 보면 아마 난리가 나 있을 것이다. 구체적으로, 한글이 다 날아가 있고, 영문자들 사이사이에 한 칸씩 빈 칸이 보일 것이다. 에디트플러스 등의 프로그램으로 이 파일을 열려고 시도하면, 이 파일을 유니코드 텍스트 파일로 인식하지 못하고, 현재의 인코딩에서 깨진 문자가 나타날 수 있다는 등의 오류 메시지를 보여준다.

이것은, Perl 의 encode 모듈이 인코딩을 UTF-16LE 형식으로 변환하면서 필요한 Byte Order Mark[BOM]를 따로 넣어주지 않기 때문이다. 따라서 Perl 을 통해 유니코드(UTF-16LE) 텍스트 파일을 저장할 때에는 반드시 BOM을 함께 저장해 주어야 한다. 구체적으로, 다음과 같이 한다.

use Encode;

my $TEXT = decode( "euckr", "This is the test of saving unicode text. 유니코드 텍스트 저장 테스트입니다." );

open my $fHandle, ">:raw:encoding(UTF16-LE):crlf:utf8", "test.txt";
print $fHandle "\x{FEFF}"; # Little Endian 임을 표시해 준다.
print $fHandle $TEXT;
close $fHandle;


위와 같은 방법을 사용하여야만 윈도우즈에서 텍스트 파일로 읽을 때에 인코딩상 문제가 발생하지 않는다.


** 다만, 이와 같이 BOM이 마킹된 파일을 Perl 이 직접 핸들링할 때에는 몇몇 문제가 발생하는 것으로 알려져 있다. 특히 Perl 소스에 이런 BOM이 붙는 경우(UTF-8 인코딩을 사용하더라도 BOM이 붙을 수 있다.) 바로 오류가 발생하곤 하므로, 절대 소스 파일에는 BOM을 붙이지 않는다.


* 참고 페이지:

Writing a Unicode file via perl : http://blogs.msdn.com/b/brettsh/archive/2006/06/07/620986.aspx
유니코드의 종류 : http://mwultong.blogspot.com/2007/11/unicode.html (이게 다는 아닙니다. -필자 주)
]]> Perl UTF-16LE Unicode 윈도우즈 유니코드 Windows Mon, 17 Oct 2011 07:39:18 +0900 <![CDATA[ 난 역시 서울 체질이 아닌 것 같다. (by 부엉이) ]]> http://www.nightowl.pe.kr/blog/article/396 http://www.nightowl.pe.kr/blog/article/396 2009년 초(귀가 직전)까지 날 어지간히 속 썩게 만들던 피부질환.
의사에 따라서 아토피라고 하기도 하고, 지루성피부염의 일종이라고도 하던,
도대체 정확한 진단명이 안 나오던 녀석인데...

집에 내려가서 한달동안 쉬면서 거의 사라지다시피 했고,
훈련소 4주 동안 땅을 기어다녔어도 멀쩡했으며,
2년 동안 아이들하고 구르면서도 재발하지 않았다.

그런데..

...다시 시작된 서울 생활 1주일 반만에 재발하더니,
한달 반째 없어지질 않고 은근한 가려움증으로 날 괴롭히고 있다.

역시 난 서울 체질이 아닌 건가.
(사실, 서울을 별로 좋아하진 않지만.) ]]> 이런저런 이야기 Mon, 04 Jul 2011 16:34:56 +0900 <![CDATA[ 넥서스원 전원버튼 덕에 십년감수 (by 부엉이) ]]> http://www.nightowl.pe.kr/blog/article/395 http://www.nightowl.pe.kr/blog/article/395 넥서스원의 여러 가지 알려진 문제들 중 하나인 전원버튼 함몰 문제.

작년 8월 중순에 넥서스원을 구입한 입장에서, 이제 슬슬 보증기간인 1년이 다 되어 가는데, 뽑기운이 좋았는지 그동안은 열받으면 발생하는 터치오류 문제 말고는 문제될 만한 것 없이 잘 쓰고 있었다. 그런데..

어제 오후쯤. 갑자기 전원버튼을 누르는 감이 뭔가 이상했다. 가만히 살펴보니, 전원버튼의 오른쪽 끝이 살짝 묻혀있는 느낌이었다. 그리고, 반나절쯤 후에는 전원버튼이 거의 눌리지 않을 정도로 밀려들어가버렸다. 아. 왔구나.

이 폰을 쓰는 사람들이 많이들 당하는 상황이지만, 여태 멀쩡하다가 갑자기 이런 사태가 벌어지니 짜증이 나기도 하고, A/S센터 갈 생각에 한숨이 나오다가, 그래도 보증기간 끝나기 전에 벌어진 게 어디냐 싶은 생각도 들었다.

...그리고, 대체 어떻게 생겨먹은 건가 해서, 뒷 커버를 벗기고 전원 버튼을 한두 번 눌러본 후 (뒷 커버를 벗기니 눌러지네..) 다시 뒷커버를 닫으니, 전원버튼 원위치. 즉, 전원버튼이 달린 어퍼보드가 함몰된 게 아니라, 단지 뒷커버의 전원버튼 홈 끄트머리에 전원버튼의 일부가 걸려서 눌려있던 상태였을 뿐이었다.


...고장 아니라서, 그리고 A/S 센터 안 가도 되어서 좋기는 한데, 왜 이렇게 기분이 찜찜한 걸까.... ]]> 이런저런 이야기 원상복구 전원버튼 함몰 넥서스원 Thu, 23 Jun 2011 02:23:07 +0900 <![CDATA[ 추억의 고전 게임: Scorched Earth (by 부엉이) ]]> http://www.nightowl.pe.kr/blog/article/394 http://www.nightowl.pe.kr/blog/article/394
2000년대 초반에 - 요즘도 서비스가 되고 있는지는 잘 모르겠다. 서비스하던 당시에도 안 했기 때문에 - 엄청난 인기를 끌었던 게임 중에 "포트리스(Fortress)" 라는 온라인 게임이 있었다. 지형 안에 각자의 탱크를 배치하고 적절한 무기와 강도, 포신의 각도를 맞추어서 다른 플레이어의 탱크를 요격하면 승리하는 게임이었다. 학부 2학년 때, 기숙사 방을 함께 썼던 룸메이트가 이 게임을 엄청나게 해댔던 기억이 난다.

[첨부 이미지가 있습니다.]

사실, 필자는 이 게임을 처음 보았을 때 약간 어이없음을 느꼈다. 약간의 반가운 감정도 함께. 왜냐 하면, 오늘 이야기하려는 이 게임, Scorched Earth 라는 게임과 그 컨셉과 플레이 방식이 너무나도 닮아 있었기 때문이다. 이 게임을 그래픽을 조금 수정해서 온라인으로 옮겨놨다고 해도 될 정도였으니..

여기까지 이야기했다면 이 게임에 대한 설명도 웬만큼 다 하지 않았나 싶다. 포트리스와 마찬가지로, 1995년에 나온 이 게임도 자신의 고정된 탱크를 이용하여 상대방의 탱크를 요격하는 게임이다. 포트리스가 온라인 게임이지만, 이 게임은 패키지 게임이었고, 네트워크 멀티플레이는 지원하지 않는다. 대신, 턴제 게임이어서 여러 명이 한 자리에서 함께 할 수 있다. (최대 10명까지 지원한다.) 물론, 사람 대신 컴퓨터와 대전을 할 수도 있다.

[첨부 이미지가 있습니다.]

위에 보이는 화면이 바로 게임을 실행시켰을 때의 화면이다. 여러 가지 메뉴들이 많이 보인다. 이 게임을 처음 만났을 때가 아마 중학교 때였을 텐데, 몇몇 단어들을 제외하고는 상당히 쉬운 단어들로 이루어져 있어서, 게임 진행에는 그다지 어려움이 없었던 것 같다. 당시에는 다른 세팅들은 거의 건드리지 않고 게임을 즐겼던 것 같지만, 사실은 상당히 사실적인 여러 가지 설정들도 건드릴 수 있다. 예를 들면 바람의 방향과 세기가 계속 변하도록 한다던지, 궤적 계산에 적용되는 중력 등을 더 강하거나 약하게 한다던지, 등장하는 지형을 좀더 험악하게 한다던지 등등. 간단히 바람의 방향과 속도가 계속 변하도록만 세팅해도 게임의 난이도는 엄청나게 올라간다.

[첨부 이미지가 있습니다.]

당시에는 네트워크 멀티플레이를 지원하는 게임이 손으로 꼽을 정도였고, (게다가, 당시에는 멀티플레이라고 하면 전화선 모뎀이나 직렬 포트를 이용한 컴퓨터 대 컴퓨터 직접 연결이 거의 다였다고 보면 된다. 전화세 내가면서 멀티플레이? 잘못하면 맞아죽는다.) 이 게임 역시 앞에서 말한 대로 네트워크 멀티플레이를 지원하지 않기 때문에 여럿이 함께 게임을 하려면 친구들을 내 방으로 불러모아야 했다. 매일같이 그럴 수도 없는 지경이라, 주로 컴퓨터와 많이 대전을 했다. 물론 컴퓨터의 실력은 천차만별. 바보짓밖에 할 줄 모르는 Moron 부터, 단순한 지형이 걸리면 손도 써보기 전에 라운드가 끝나버리는 Spoiler 나 Cyborg 같은 녀석들까지. 물론 아무나 걸리라는 심정으로 Unknown 을 선택해도 된다. 그렇다고 컴퓨터의 인공지능이 매우 좋은 건 아니다. (이런 류의 게임에서 컴퓨터의 인공지능이 너무 높으면 플레이어는 손도 못 써보고 당하기만 할 것이다.) 플레이어 전원을 컴퓨터로 넣을 수도 있기 때문에, 컴퓨터로만 한 4명 넣어 두고 누가 이길지 관전하는 재미도 꽤 있다. 물론, 가끔은 멍청한 컴퓨터들이 엉뚱한 데다 대고 공갈포만 쏴대는 속터지는 광경을 보게 될지도 모르지만.

[첨부 이미지가 있습니다.]

게임이 시작되면 일단 지형이 랜덤으로 생성되고 그 지형의 곳곳에 랜덤하게 탱크가 놓이게 되는데, 때로는 평탄한 지형에 바로 코 앞에 탱크가 놓여서 한 방에 가루가 되는 경우도 발생하고, 어떤 경우는 지형이 벽 역할을 해서 정말 공격하기 난감한 상황이 되는 경우도 있다. 예를 들면, 아래 그림과 같이 거대한 산을 사이에 두고 있을 때 바람이 강하면 상당히 난감한 상황이 된다. (바람을 등지고 있건 안고 있건, 조준하기 난감한 건 마찬가지다.)

[첨부 이미지가 있습니다.]

첫 라운드에 주어진 미사일은 Baby Missile 뿐이다. 탱크를 정확하게 타격해야만 상대편 탱크가 폭파되는 그야말로 약한 미사일이다. 생각해야 할 것은 바람의 방향과 세기, 포의 각도, 포의 세기. 이상적으로 잘 맞추어서 적 탱크에게 명중시키면 성공. 물론 적 탱크도 놀고만 있지는 않으므로 가능한 한 빠른 턴 내에 요격을 완료해야 한다.

탱크가 일단 요격되면, 탱크는 폭파되어 사라진다. 그러나, 여기에 또 한 번의 반전. 일단 무기가 탱크에건 지면에건 명중하면, 그 무기에 고유한 폭발 효과가 나타난다. 이 효과는 정말 다양한데, 무기에 따라서 폭발 없이 그 자리에만 작은 구덩이를 만들기도 하지만, 거대한 폭발이나 파편을 날리면서 주변을 아수라장으로 만들기도 한다. 그 폭발에 휩쓸리면 최소한 없어진 땅바닥을 향해 추락이고, 운이 나쁘면 함께 황천행을 하기도 한다.

운 좋게 추락으로 끝나더라도 좋은 상황이 아닌 것이, 만약 게임 중 탱크가 추락하면 추락한 탱크가 그 만큼의 데미지를 입는다는 설정이라, 추락 데미지가 탱크의 방어 한계치보다 크다면 함께 폭파될 것이고, 그렇지 않더라도 추락한 후의 탱크는 데미지를 입은 만큼 낼 수 있는 파워가 줄어들게 된다. 즉 자칫하면 공격 자체를 할 수 없는 상황 - 살아도 살았다고 할 수 없는 상황 - 에 놓이게 되는 것이다.


그런데 이게 다냐면, 아니다. 만약 미사일이 탱크에 명중한 경우, 무기의 폭발이 끝나고 나면, 그 탱크(내지는 그 탱크에 장착되어 있던 무기라고 생각해도 되겠다)의 후폭발이 한번 더 일어난다. 어떤 후폭발이 일어날지는 아무도 모른다. 아래 화면을 보면, 현재 공격한 컴퓨터 플레이어는 분명히 Baby Missile 을 사용하여 적 탱크를 요격했는데, 후폭발은 Baby Nuke 다. 폭발한 탱크 내부에 Baby Nuke가 장착되어 있었기 때문일까? 에이 설마..

[첨부 이미지가 있습니다.]

어찌 되었건, 화면 내의 탱크를 모두 요격하면 한 라운드가 종료되고, 각 플레이어는 자신의 성과대로 돈을 벌게 된다. 그리고 이렇게 한 라운드가 끝날 때마다, 플레이어는 벌어들인 돈으로 무기나 여러 가지 아이템을 살 수 있다. 드디어 Baby Missile 외에 더 강력하고, 더 범위가 넓은 무기를 쓸 수 있게 되는 것이다. 떨어지자 마자 사방팔방에 파편을 날리는 Funky Bomb 라던가, 땅에 닿자마자 경사면을 따라 굴러내려가 경사면이 끝나는 부분에서 폭발하는 Roller 라던가, 땅에 닿는 순간 지진을 만들어 그 주변의 땅을 내려앉게 만드는 Digger/Sandhog 류 등 정말 다양한 상황에 쓸 수 있는 무기들이 있다. 아, 무기만 있는 것은 아니다. 추락할 때의 데미지를 감소시켜 주는 낙하산(Parachute)이라던가, 탱크 주변에 방어막을 쳐 주는 아이템, 적 탱크를 향한 조준을 도와 주는 아이템도 존재한다. 물론 이런 아이템들을 사기 위해서는, 최대한 많은 탱크를 부수고, 또 최후까지 살아남아 돈을 벌어야만 하겠다.

[첨부 이미지가 있습니다.]

이런 식으로 정해진 라운드 (기본값은 10 라운드이지만, 설정에서 더 늘릴 수도 있다.)가 끝나면, 이와 같이 게임의 결과가 나오면서 순위가 공개된다. 일단 최후까지 살아남은 숫자가 많은 쪽이 우선이고, 최종 생존 횟수가 같다면 벌어들인 돈이 많은 쪽이 승리. 아래 화면에 보이는 게임은 필자와 컴퓨터 3명 (모두 Unknown이었다.)이 10라운드 대전을 벌인 결과다. 초반 라운드에 신들린 타격을 한 컴퓨터 덕분에 꽤나 고전하다가 (초반에 공격받아 폭사하고 컴퓨터들끼리 노는 걸 멍하니 지켜본 라운드가 몇 라운드인지 모르겠다.) 막판에 지형의 도움을 받아 남은 라운드를 쓸어담아 결국 1위로 역전한 모습이다. (푸하하하...)

[첨부 이미지가 있습니다.]

이 게임을 보면, 그 시절 명절 때의 기억이 난다. 어떤 명절이었던가. 어른들은 마루에서 국민게임 고스톱을, 그리고 나는 친척 동생들과 방에서 컴퓨터로 이 탱크 대전을... 아하하하...

잠시 기분 전환이 필요할 때에, 가끔씩 돌려 보면 좋을 게임이다. 1995년이니까 MS-DOS 용 게임이지만, DosBOX 를 이용하면 지금도 얼마든지 플레이가 가능하다. 이 게임은 출시 당시에는 Shareware 였으며, 현재 Abandonware 상태이다. 다운로드는 아래에서 받을 수 있다.

Scorched Earth v1.5 [첨부 파일 링크가 있습니다.]


Abandonware란, 오늘 현재 그 프로그램의 제작자를 알 수 없거나, 프로그램을 제작한 회사가 사라지거나, 혹은 아직 존재하더라도 그 판매가 종료되어 더 이상 제작사가 저작권을 주장하지 아니하는 등으로 사실상 버려진 프로그램을 말한다. 법률적으로는 분명 누군가에게 그 권리가 살아 있을 것이므로, 그 권리가 실효되지 않는 한, 차후에라도 어딘가에 있을 저작권자가 프로그램에 대한 권리를 주장한다면 그 권리가 인정을 받게 된다는 점에서, 권리 자체가 사라진 상태인 Public Domain 과는 다르다.

따라서, 현재 이들이 Abandonware 라는 이름으로 인터넷상에 자유롭게 유포되고 있지만, 그 Abandonware 라고 하는 지위는 사실 잠정적인 것이라고 할 수 있다. 물론, 권리가 남아 있다는 것과, 현재의 시점에서 이런 MS-DOS 시절의 게임이 상업적인 가치를 갖느냐는 것은 별개의 문제이기 때문에, 아마 앞으로도 저작권자가 이 프로그램에 대한 권리를 주장하고 나서서 유통을 차단시킬 것 같지는 않지만 말이다.
]]> 이런저런 이야기 Fortress Scorched Earth 포트리스 Wed, 22 Jun 2011 02:51:25 +0900 <![CDATA[ [상황종료] 주의! 현재 스포탈코리아 기사 페이지를 통해 악성코드가 유포되고 있습니다. (by 부엉이) ]]> http://www.nightowl.pe.kr/blog/article/393 http://www.nightowl.pe.kr/blog/article/393
* 2011/06/21 게시물 수정 *

이 시간 현재, 크래킹 피해를 입었던 스포탈코리아의 페이지도 복구가 된 상태이기 때문에, 더 이상 이 악성코드가 급속히 유포되는 사태는 벌어지지 않을 것입니다. 그러나, 그 이외에 또 어떤 사이트가 이런 종류의 악성코드에 감염되어 있을지는 미지수이므로, 항상 주의를 기울여야 합니다.

또한, 이번 악성코드는 윈도우 또는 익스플로러의 보안 헛점이 아닌, 플래시 플레이어의 보안 헛점을 이용하여 시스템이 복사되고 실행된 것으로 보여집니다. 플래시 플레이어는 거의 모든 시스템에 설치되어 있지만, 윈도우 보안 패치보다는 그 중요성이 덜 강조된 것이 현실이니만큼, 앞으로 이쪽의 보안 패치도 좀 더 관심을 기울여야 할 것 같습니다.





이 시간 현재, 스포탈코리아의 기사 페이지를 열어 보면 아무런 경고도 없이 프로그램이 다운로드 되고 실행되려 합니다.

[첨부 이미지가 있습니다.]

필자는 윈도우 7을 사용중이어서, 윈도우 7의 UAC 가 자동으로 이 프로그램의 실행을 막았습니다만, 이런 안전장치가 없는 윈도우 XP 사용자의 경우에는 상당히 위험할 것 같습니다. 이 문제가 Internet Explorer 8의 보안 헛점인지, 이 프로그램의 다운로드에 이용되는 것으로 보이는 플래시 플레이어의 보안 헛점인지는 잘 모르겠습니다. 필자가 오늘 현재 발표된 모든 패치를 다 한 상태임을 감안하면 알려지지 않은 보안 헛점인지도 모르겠습니다.

아무튼, 기사 페이지를 소스 보기로 열어 보면 다음과 같은 코드가 보입니다.

[첨부 이미지가 있습니다.]

밑줄 쳐진 경로로 들어가 보면 (절대 따라하지 마십시오.) 위와 같이 UAC가 켜지면서 특정한 파일을 실행할 것이냐고 물어봅니다. 물론 절대 실행하면 안 되겠죠.

현재까지 확인한 사항은 다음과 같습니다.

1. 사용자에게 어떠한 경고도 없이 몰래 자동으로 다운로드가 되고 실행까지 된다는 점에서 현재 존재하는 알려지지 않은 보안 헛점을 이용하는 것으로 추정된다. (아래는 저 화면을 본 후, 필자가 필자의 하드에서 다운로드 된 해당 파일을 찾아본 것입니다. 역시 있습니다.)

[첨부 이미지가 있습니다.]

2. 윈도우 7의 UAC 가 동작하는 것으로 보아 시스템 설정의 변경을 시도한다.

3. 파일의 이름은 scvhost.exe 인데, 이 이름은 윈도우의 시스템 파일인 svchost.exe 와 유사한 이름을 갖는 파일로써, 그동안 많은 악성코드의 파일명으로 사용된 인기 있는(?) 파일명이다.

필자가 프로그램을 분석까지 할 능력은 없기 때문에 - 가상머신 등에 던져놓고 모니터링하면서 무슨 짓을 하는지 확인해볼 수는 있지만, 밤이 늦었군요. 그리고 귀찮습니다. - 실제로 이것이 악성코드인지 아닌지 판단할 수는 없습니다. 그러나, 위와 같은 의심스러운 행동을 보이는 점을 바탕으로 생각해 보면 최소한 정상적인 파일은 아닌 것으로 생각됩니다. 물론 개인적으로는 이 파일은 악성코드임을 확신하고 있습니다.

현재 2011.06.11.00 엔진의 V3 로는 해당 파일이 진단되지 않습니다. 필자가 보조수단으로 사용하는 Kaspersky Online Scanner 에서도 악성코드 여부가 확인되지 않습니다. 안철수연구소에 이런 사실과 함께 해당 파일을 첨부하여 신고하였으며, 현재 회신을 기다리고 있는 중입니다. 회신을 받으면 이 글을 수정하여 내용을 추가하겠습니다.

이 글을 보시는 분들께서는 같은 현상이 발생할 경우 절대로 해당 파일을 실행하지 마시기 바랍니다.



=====================================================================
2011.06.11 15:31 추가
=====================================================================

결국 이 녀석 가상머신에 던져놓고, 조금 행동분석을 해봤습니다.

이 녀석은 실행되면, 실행을 마친 후 원래 있던 본체인 scvhost.exe 는 삭제되어 사라집니다. 대신 Program Files 아래에 % 로 시작하여 % 로 끝나는 길다란 폴더를 만들고, 그 안에 숫자로 이루어진 실행 파일을 만들어 넣습니다. 용량은 약 32메가 바이트 정도 되는군요.

[첨부 이미지가 있습니다.]

여담이지만, 위 화면상 이 실행 파일의 작성(수정)날짜로 되어 있는 2011년 6월 10일 18시 23분이, 아마도 이 프로그램이 서버에 저장된 시간이 아닌가 합니다. 아마도, 이 악성코드가 유포되기 시작한 시간은 이 이후가 되겠지요.

특별히 시작 프로그램에 무언가를 등록한다거나 하지 않기 때문에 차후에도 발견하기가 좀 어렵습니다. 그러나, 윈도우 시스템을 직접 건드려서 DLL 파일을 심어놓기 때문에, 시스템이 실행될 때마다 매번 실행되는 점에는 변함이 없습니다. (그래서, 도대체 Program Files 폴더에 복사해놓는 저 exe 파일은 대체 뭐 하자고 있는 것인가 하는 의문이 듭니다. 프로세스에도 나타나지 않습니다.)

구체적으로, 원래 윈도우 XP 서비스팩 3의 언어 팩 파일인 lpk.dll 파일을 lpk32.dll 로 이름을 바꾸고, 시스템상에서 lpk.dll 을 가리키던 것을 lpk32.dll 을 가리키도록 시스템을 변형합니다. 그리고 악성코드 자신이 lpk.dll 의 위치를 차지하고 앉아서 시스템이 시작될 때마다 자동으로 실행됩니다. (아래 이미지를 보세요.)

[첨부 이미지가 있습니다.]

또한, 변형된 lpk.dll 파일이 프로세스에 남아 있는 경우, V3 Lite의 실시간 검사 기능이 꺼진 후 다시 켜지지 않는 (실시간 감시가 동작하지 않는) 증상이 있습니다.

따라서, 현재 윈도우 XP 를 사용하는 시스템에서, System32 폴더 내에 lpk.dll 과 lpk32.dll 이 모두 존재하며, explorer.exe 에 붙어서 실행되는 .dll 파일 목록에 이 두 파일이 모두 있다면, 현재 이 악성코드에 감염되어 있다고 보면 확실할 듯합니다.

[주] 감염분석만 한 것이어서, 실제로 이 코드가 어떤 악성 행동을 할지는 저도 모릅니다. 이는 제가 코드를 넘겨드린 안철수연구소 분들이 대신 해 주시겠죠. 그러나, 위에서도 보았듯이 시스템의 허점을 통하여 허락 없이 내 시스템이 침투하는 종류의 프로그램이라면, 그 행동 여하에 관계 없이 악성코드라고 봄이 틀림없을 것이기에, 처음의 입장을 그대로 유지합니다. 안철수연구소로부터 회신이 돌아오면 이 게시물을 한번 더 수정하여 알려드리겠습니다.

이 시간 현재로서는, 해당 파일을 V3도, Kasperskylab Online Scanner 도 악성코드로 진단하고 있지 못합니다. 따라서 이용자들이 알아서 주의를 해야 합니다.



=====================================================================
2011.06.11 21:04 추가 / 22:05 수정 / 22:50 추가 / 06.12 12:11 수정 / 22:36 수정 / 06.14 15:30 정리. 끝.
=====================================================================

1.

안철수연구소에서 해당 파일들을 악성으로 판정하고, 다음과 같이 진단하고 치료합니다.

2011.06.12.00 엔진부터 치료 가능:

* scvhost.exe(83,387byte) : Dropper/Onlinegamehack.83387
* F.htm : JS/Iframe (통합 진단명)
* Program Files 이하에 생성하는 파일 : Dropper/Onlinegamehack.33598890

2011.06.12.01 엔진부터 치료 가능:

* lpk.dll(33,586,058byte): Win-Trojan/Onlinegamehack.33586058.R

[첨부 이미지가 있습니다.]

[첨부 이미지가 있습니다.]



2.

2011.06.12.00 엔진에서는 변형된 lpk.dll 파일 - 사실 이쪽이 좀 더 본체인데 - 을 삭제하지 않았기 때문에 불완전치료의 문제가 있었습니다. 2011.06.12.01 엔진에서부터 lpk.dll 파일도 진단 및 치료가 가능하므로, 이후의 엔진을 사용한다면 문제는 없습니다.

다만, 안철수연구소에서 공개한 전용백신 중, 이런 식으로 윈도우의 DLL 파일을 변형한 후 자신이 감염되는 형태의 악성코드를 진단하고 복구할 수 있는 툴이 있으므로, 이러한 전용 툴이 필요한 경우에는 사용할 수 있습니다. 정확한 진단명은 제공하지 못할 수도 있지만, 같은 방법으로 감염되는 새로운 종류의 악성코드도 진단할 수 있을 것이므로, 가끔 돌려보는 것도 나쁘지 않겠지요.

다운로드: http://www.ahnlab.com/kr/site/download/vacc/vaccView.do?seq=101

[첨부 이미지가 있습니다.]


만약 위 전용백신이 감염된 lpk.dll 파일을 진단하지만 그 치료에 실패하는 경우, 감염되는 과정에서 lpk.dll 파일이 파괴된 경우일 수 있습니다. 이 경우 시스템에 설치된 거의 모든 실행파일을 실행하는 데 있어서 lpk.dll 관련 오류가 발생합니다. (윈도우 언어 팩 파일인 관계로, 거의 모든 경우에 있어 이 파일이 로드되기 때문입니다.) 이런 경우, 윈도우 CD/DVD로부터 정상적인 lpk.dll 파일을 복사하여 문제를 해결할 수 있습니다.

만약 윈도우 XP SP3의 경우, 아래 링크한 압축파일을 다운로드 받아 압축을 푼 후 실행해 보시기 바랍니다. 이것은 윈도우 XP SP3의 정상적인 lpk.dll 파일을 포함하고 있으며, 함께 들어 있는 lpk_recv.bat 파일을 실행하면 DLLCACHE 및 SYSTEM32 폴더 내에 들어 있는 lpk.dll 파일을 동봉한 lpk.dll 파일로 교체를 시도합니다. 교체 완료 후에는 검사를 다시 시행해 주세요. (물론 이게 필요한 경우는 소수일 것으로 봅니다.)

[첨부 파일 링크가 있습니다.]

[주의] 이 파일은 한글 윈도우 XP SP3 에 대응되는 파일입니다. 다른 언어의 윈도우 XP나 서비스팩 3이 아닌 다른 버전의 XP, 혹은 윈도우 비스타나 윈도우 7 등에서 사용하면 최악의 경우 윈도우를 다시 깔아야 하는 상황이 될 수도 있습니다.



3.

다시 한 번 강조합니다만, lpk.dll 파일은 원래 윈도우에 존재하는 언어 팩 파일이며, 윈도우 XP 기준 22.016byte의 크기를 갖습니다. 따라서 파일의 정보가 이와 같은 경우에는 악성코드가 아닙니다.

또한, lpk32.dll 파일은 악성코드가 시스템이 원래의 lpk.dll 파일을 호출하는 경우에 대응하기 위하여 생성한 원래의 lpk.dll 의 복제본입니다. 따라서 이 파일은 시스템에 남아 있더라도 문제가 없으며, 또한 악성코드도 아니기 때문에, 많은 악성 코드 퇴치 프로그램의 경우 치료가 끝난 후에도 이 파일을 그대로 남겨 둡니다. (아래 이미지에서 보시다시피, "복구된" 정상적인 lpk.dll 파일과 악성코드가 생성한 lpk32.dll 파일은 서로 동일한 파일입니다.)

[첨부 이미지가 있습니다.]

따라서, 시스템상에 lpk32.dll 파일이 존재하더라도, 이 파일의 정보가 위와 같이 lpk.dll 파일과 일치한다면 과거에 악성코드에 감염되었던 흔적이 남아 있는 것일 뿐, 악성코드 이슈와 관계가 없습니다. 눈에 거슬리신다면 lpk32.dll 파일만 직접 삭제해 주시면 됩니다. ]]> 컴퓨터 사용 경험 lpk32.dll scvhost.exe 악성코드 의심 보안 헛점 lpk.dll 악성코드 보안 Sat, 11 Jun 2011 01:45:16 +0900 <![CDATA[ 32bit CardBus PCMCIA CF 카드 리더 : ASKA JAPAN CF32F 리뷰 (by 부엉이) ]]> http://www.nightowl.pe.kr/blog/article/392 http://www.nightowl.pe.kr/blog/article/392 안 읽어도 되는 이야기

애초에 시작은 하드디스크를 SSD로 바꾸면서 시작되었다. 80G였던 내부 저장 용량이 64G로 줄어든데다, 윈도우 XP에 비해 엄청나게 많은 용량을 잡아먹는 윈도우 7 덕분에 C드라이브의 용량을 두 배 이상으로 잡아야 했고, 덕분에 실제로 데이터를 저장할 수 있는 예비된 저장 공간이 매우 부족해지는 상황이 된 것이다. USB디스크와 외장하드 등으로 어떻게 채워본다고는 하지만, 역시 들고다니기엔 거추장스러운 것들이고, 내장 디스크와는 비교할 수가 없는 것이 당연지사.

그러던 중, PCMCIA-CF 젠더라는 것을 알게 되었다. 정확히 말하자면 PCMCIA CF카드 리더라고 해야 하겠지만. 마침 PCMCIA 포트가 놀고 있었기 때문에, 이 공간을 활용해서 마치 내장하드와 크게 다를 바가 없는, 별도로 들고다닐 게 없는 저장공간을 확보할 수 있다는 것이 상당히 솔깃하게 들렸다.

그러나 거기까지. 현재 국내에서 팔리고 있는 1만원 이하짜리 PCMCIA CF카드 리더들의 성능을 알아보고는 매우 실망할 수밖에 없었다. CardBus (PCMCIA II) 방식에 대응하지 않는 16bit의 PCMCIA 형식이라 시스템 자원도 많이 소모할 뿐 아니라 속도도 1MB/s가 채 나오지 않는다는 이야기를 여기저기서 들을 수 있었다. 이쯤 되면 속도면에서나 안정성 면에서나 낙제점 수준.

조금 더 알아보다 보니, 32bit PCMCIA(CardBus) 방식에 대응하는 PCMCIA-CF카드 리더도 있긴 하다는 것을 알게 되었다. 아니 정확히는 "있었다" 가 맞는 표현이겠다. 과거 국내에도 잠깐 수입되었던 적이 있었던 모양인데, USB 2.0 대응 멀티 카드리더를 1만원 미만에 살 수 있는 마당에, CF카드 하나 읽자고 5만원이 넘는 돈을 지출할 사람은 아마도 없었을 것이다. (결국 얼마 못가 시장에서 사라졌다고 한다.) 즉, 현재 국내에서는 32bit CardBus 대응 CF카드 리더는 구할 수 없다는 결론이었다.

거의 포기하려던 와중에, 네이버 블로그(http://blog.naver.com/okpark7/120072249698)를 통해 일본산 CF32F 라고 하는 모델이 있다는 것을 알게 되었다. 무려 4900엔. 그러나 역시 그림의 떡이기는 마찬가지. 아마존 재팬을 통하면 구입은 가능했지만, 일단 아마존 아이디도 없다. 국내에 여러 군데 있는 구매대행사를 이용하면 되기는 하겠지만, 역시나 신뢰의 문제가 발목을 잡았다. 물론, 일본에 구매대행으로 뭘 살 일이 없으니, 아는 회사가 없기도 했고.

그러다가, 지금 쓰는 노트북을 구매대행해준 리브마트(http://www.libmart.co.kr/) 에서 이 제품을 올려놓고 구매대행을 하고 있다는 걸 알게 되었다. 알아본 구매대행사에 비해 2만원 정도 비싼 가격이었지만, 일단 믿을 수 있었기 때문에 이쪽으로 주문을 했다. 그리고, 화요일 오전에 주문했는데 목요일 오전에 배송완료라는 기가 막힐 정도로 빠른 배송 시간에 감탄을 하면서, 지금 이 리뷰 글을 쓰고 있는 것이다.



1.

이 제품은 32bit Cardbus 규격을 지원하는 PCMCIA CF카드 리더이다. CF카드 리더는 굳이 PCMCIA 형식이 아니더라도 USB 2.0 지원의 많은 값싼 (멀티) 리더기가 나와 있지만, PCMCIA 형식의 경우 거의 항상 본체에 꽂혀 있기 때문에 뭔가 추가로 USB케이블이나 리더기를 들고다닐 필요가 없고, 그냥 꽂아놓고 내장 디스크처럼 별 생각 없이 사용할 수도 있다는 장점이 있다. 국내에 나와 있는 그나마 몇 종류 안 되는 PCMCIA CF카드 리더가 모두 16bit 대응이어서, 이 제품을 구매하기 위해서는 구매대행을 이용하거나 일본 아마존 등을 통해서 직접 구매해야 한다.

[첨부 이미지가 있습니다.]

제품 상자. 제품 상자 디자인이 참 재미있는데, 절대로 CF카드가 함께 들어있다거나 그런 것은 아니다. 일본어는 못 읽지만, 최대 440배속(440x)까지는 지원을 한다는 것 같은데, 나중에 주변에 400x Transcend CF카드를 쓰는 사람이 있으면 한번 테스트를 해 봐야겠다.

[첨부 이미지가 있습니다.]

카드만 분리해 놓은 사진. 홈 부분에 CF카드를 삽입하면 된다. CF카드를 꽂아넣으면, 카드 삽입구 위쪽의 까만 부분이 밀려들어가면서 아래 사진과 같이 꼭 맞는 길이로 장착된다.

[첨부 이미지가 있습니다.]

PCMCIA 카드의 길이는 실제 슬롯의 길이와 일치한다. 따라서, 노트북의 PCMCIA 슬롯에 꽂으면 아래 사진과 같이 완전히 매립된다.

[첨부 이미지가 있습니다.]



2.

매뉴얼에 보면 CF카드를 리더에 먼저 꽂은 후 컴퓨터에 삽입해 달라고 한다. 필자가 사용하는 OS가 윈도우 7임에도 불구하고, 드라이버를 알아서 못 잡는다. 따라서 제공되는 CD를 이용하여 수동으로 설치하여야 한다. 필자처럼 ODD가 달려있지 않아 드라이버를 복사하는 데 난감함을 겪는 사람이 없도록 드라이버는 여기에 함께 첨부해 둔다.

CF32F 드라이버 파일 [첨부 파일 링크가 있습니다.]


위 압축 파일에는 오로지 드라이버만 들어 있다. 따라서 장치 관리자의 드라이버 설치 기능을 통하여 수동 설치를 하여야 한다. 원래 들어 있는 드라이버 설치 프로그램은 언어가 일본어로 고정이 되어 있어서, 한글 윈도우 7에서는 언어가 맞지 않는다는 오류를 내면서 실행이 되지 않기 때문에, 어차피 사용이 불가능하다. (일본 내수용으로 만들어지는 많은 제품들이, 언어 면에서 이런 문제들을 안고 있다.)

성공적으로 설치가 완료되면, 장치 관리자에 이런 식으로 장치가 뜨게 된다. CF32F CardBus CF Controller 와 함께, 그 바로 위의 ATA Channel 0 도 여기에서 설치한 것이다.

[첨부 이미지가 있습니다.]

일단 필자의 경우는 대용량 이동식 디스크로 잡히는데, 일부 모델의 경우 이게 하드 디스크로 잡히는 경우도 있다고 들었다. 만약 그렇게만 잡혀준다면 그 녀석으로 부팅도 가능할 것 같지만, 일단 넘어가고.



3.

문제는 성능이겠다. 필자는 벤치마크 류의 성능 측정을 별로 좋아하지 않는다. 그래봤자 숫자놀음 아니냐 하는 생각 때문인데, 객관적으로 성능을 표시할 만한 다른 지표가 별로 없으니 어쩔 수 없다.

일단 벤치마크 프로그램은 CrystalDiskMark 3.0.1a 을 사용하였으며, 0x00 을 채워넣는 방법으로 5회 측정하였다.(1000 MB (x5) <All 0x00, 0Fill>)

[첨부 이미지가 있습니다.]

일단 나타나는 성능 자체는 그럭저럭 괜찮은 편이다. SSD와의 비교야 원래부터 넘사벽이니 넘어가고(참고로, SSD 속도가 왜 저 모양이냐 하면, 필자의 노트북이 SATA 2가 아닌 SATA 1을 지원하기 때문이다.), 다른 녀석들과 비교를 해봐도 떨어지지 않는다. 오히려 읽기 성능의 경우는 다른 USB 2.0 대응 매체들보다 더 뛰어나다. 특히, 같은 디스크를 USB 2.0 대응 멀티카드리더로 읽은 것보다 조금 더 나은 성능을 보여 준다. 이정도면 성능에 있어서는 일단 합격이라고 봐도 될 것 같다.

* CF카드와 리더 모두 UDMA MODE 4를 지원하는데, 위 결과로 봐서는 현재 모드가 PIO MODE 6인지, UDMA MODE 4인지 알 수가 없다.

하나의 추가적인 테스트 결과를 여기에 적는다. 합쳐서 약 1.67GB 정도 되는 3개의 파일을 SSD에서 CF로 이동하면서 시간을 측정하고, 그 후 반대로 CF에서 SSD로 이동하면서 시간을 측정하였다. SSD의 쓰기 속도가 CF의 읽기 속도보다 빠르기 때문에, 전자는 사실상 CF 쓰기 테스트이고, 후자는 사실상 CF 읽기 테스트가 될 것이다. 위의 숫자놀음보다, 어쩌면 아래의 테스트 결과가 좀 더 와 닿을지도 모르겠다.

* SSD -> CF 이동 시간 : 3분 45초
* CF -> SSD 이동 시간 : 43초



4.

문제는 항상 가격이다. 특히 이 제품의 경우는 더 한데, 현재 이 제품의 현지 가격이 4900엔이고(싸게 파는 곳은 4천엔대 초반에 파는 곳도 있긴 하다) 현재 엔화 환율이 1300원대 중반에서 내려오지를 않고 있기 때문에, 단순히 물건값만 계산해도 대충 7만원 정도가 나온다는 계산이 된다. 거기에 배송비와, 만약 구매대행을 한다면 구매대행 수수료, 그리고 CF카드가 없다면 구매하는 가격, 모두를 더하면 거의 64GB SSD 하나 사는 가격에 조금 모자랄 정도의 가격이 나오게 된다. 문제는 이 정도의 가격을 지불하고서 성능과 사용에 만족을 얻을 수 있느냐가 될 것이다. 일반적인 경우에 이 기기의 장점은, USB 2.0보다 조금 더 나은 속도, 별도의 리더와 케이블을 갖고 다니지 않아도 된다는 편리함, 거기에 혹시라도 CF카드를 사용하는 DSLR이라도 갖고 다닌다면 이를 이용하여 빠른 속도로 컴퓨터와 자료를 공유할 수 있다는 편리함 정도가 추가되겠다. 이 정도의 장점을 취하기 위해 약 10만원 정도 되는 구매가격을 감당할 수 있겠는가? 있다면 필자처럼 지르게 될 것이지만, 아마도 그렇지 않을 사람들이 조금 더 많을 것 같다.

* 오히려 지르게 된다면, 위의 장점들 때문이라기보다는 필자처럼 조금 오래 된 노트북을 계속 쓰기 위해 저장 공간을 확장하려는 시도(특히 메인하드디스크로 64GB SSD를 설치한 경우나, 모종의 이유로서 하드디스크의 확장이 불가능한 경우)로서 지르게 되는 경우가 좀 더 많지 않을까 한다. ]]> 컴퓨터 사용 경험 32bit CardBus CF32F PCMCIA-CF Fri, 10 Jun 2011 00:28:04 +0900 <![CDATA[ 강릉바우길 3구간 트래킹 기록 (2011.06.03) (by 부엉이) ]]> http://www.nightowl.pe.kr/blog/article/391 http://www.nightowl.pe.kr/blog/article/391 2011년 6월 3일 - 제3구간 (게스트하우스, 대관령유스호스텔 ~ 명주군왕릉), 13km

[첨부 이미지가 있습니다.]


1. 게스트하우스의 아침

전날 죽은듯이 잔 덕인지 체력에는 문제가 없는 듯 하지만, 스트레칭을 덜 해서 그런지 뻣뻣한 다리가 오늘의 발목을 잡을 듯한 느낌. 일찍 일어난 김에 노트북을 꺼내서 작업을 좀 하다가, 아침식사 시간(08:00)에 맞추어 식당으로. 아침식사 역시 간단하지만 손맛이 느껴지는 한끼였다. 식사 후 게스트하우스의 여기저기를 구경하다가, 오늘의 코스인 제3구간을 향해 출발[09:30].

제3구간의 경우 코스 중간에 식사할 곳도, 식수를 공급받을 곳도 없으므로 모든 준비를 게스트하우스에서 마치고 출발해야 한다. 식당에서 주먹밥을 1인분(2개)에 천원씩 구입할 수 있으므로 제3구간을 가려는 사람들은 꼭 구입해서 출발할 것.

[첨부 이미지가 있습니다.]


2. 게스트하우스[09:30] ~ 대관령유스호스텔(출발점) ~ 산길입구[10:06]

바우길 제3구간은 그야말로 산행코스라고 말하는 것이 적절할 것 같다. 그냥 가벼운 마음으로 산책할 셈으로 제3구간을 선택하면 낭패를 볼 수 있다. 멀쩡한 임도를 놔두고 산 속 길만 찾아다니는 코스. 게다가 초반에 끊임없는 오르막을 한 1시간 정도 계속 올라야 하기 때문에, 초반에 체력 소모가 심할 수 있다. 전술했듯이 코스 내내 물을 구할 수 없고 식사할 곳도 없으므로 미리 준비를 해야 한다.

일단 산길입구까지는 아스팔트길과 시멘트 포장길이 계속된다. 전방 산꼭대기에 있는 풍력발전기들이 돌아가는 모습이 꽤 멋지다. 신영동고속도로의 다리 아래를 지나가면 곧 산길입구[10:06]가 등장하는데, 시작부터 보이는 길이 만만치가 않다.

[첨부 이미지가 있습니다.]


3. 산길입구[10:06] ~ 거북등[11:03] ~ 어명정[11:12]

저 위에, 제3코스 전체 지도를 첨부해뒀는데, 어명정에 도착하기 직전에 등산로와 임도(하얀색 길)가 만나는 곳이 있다. 여기가 거북등이라고 하는 곳이다. 등산로의 시작인 산길입구부터 임도와 바우길이 만나는 이곳 거북등까지, 이정표상 거리로 약 2km 정도 되는 구간이 계속 오르막길이다. 경사도 꽤 급한 편이라서, 누군가의 표현으로 마치 철제 계단을 오르는 것마냥 구불구불하게 올라간다. 군데군데 성질급한 사람들이 뚫어놓은 (경사가 급한) 지름길이 있는데, 글쎄. 처음엔 몰라도 나중엔 그럴 힘이 남아 있을까? 난 힘들어 죽는 줄 알았는데.

[첨부 이미지가 있습니다.]


4. 어명정[11:41] ~ 술잔바위[12:07] ~ 산불감시초소[12:47]

어명정에서 게스트하우스에서 구입한 주먹밥으로 이른 점심식사를 하고 다시 길을 떠났다. 여기 이후에 편하게 식사를 할 만한 곳이 없을 것 같아서, 식사를 하면서 한 30분 정도 휴식을 취하고 출발한 것인데, 술잔바위에도 앞에서 본 쉼터처럼 그런 공간이 있으므로 그 쪽을 이용해도 된다. (우리의 경우에는 거기를 이미 다른 등산객 일행이 점령하고 있었기에, 결과적으로 어명정에서 식사를 한 것이 잘 한 선택이 되었다.)

멀쩡한 임도 놔두고 산길로 돌아가기의 절정인 코스 답게, 어명정에서 다시 임도를 버리고 산길로 접어든다. 시작부터 계단인 것에서도 알 수 있지만, 역시 오르막 산길이다. 그러나, 대충 여길 지나면 더 이상 힘든 오르막은 없다. 중간에 산성길로 빠지지 않도록 주의. 술잔바위 조금 못 미쳐 소방방재청에서 비치해둔 구급함이 있으므로, 필요한 사람은 이용할 것. 술잔바위를 지나면 이제 내리막 숲길이다. 숲길의 끝에서 다시 임도와 만나고, 녹색의 컨테이너 박스를 보게 된다. 이곳이 바로 산불감시초소. 남은 것은 이제 임도를 따라 걸어내려가는 것 뿐이다.

[첨부 이미지가 있습니다.]


5. 산불감시초소[12:47] ~ 명주군왕릉[13:33]

산불감시초소부터는 계속 내리막길 임도이다. 군데군데 갈림길들이 많으므로 지도와 이정표를 잘 보면서 엉뚱한 길로 들어가지 않도록 주의해야 한다.

이 코스의 어려움이라고 할 만한 것이 여기에서 또 나오는데, 꽤 긴 거리를 임도를 따라 내려가다 보니, 정오를 지난 한낮이라는 조건상 꽤 강한 햇빛을 받게 된다. 임도라는 특성상 그늘이 만들어지는 것도 아니고 해서, 이게 은근히 고역이다. 다만 오르막은 별로 없고 계속 내리막이어서 체력적으로는 문제가 없겠지만 풀린 다리로 걸어내려가려면 조금은 조심해야 할 지도.

명주군왕릉까지 거의 다 내려오면, 4구간과 10구간의 갈림길이 등장한다. 여기까지 왔다면 사실상 코스 완주, 3구간의 끝이라고 봐도 된다. 이 때 시간이 13시 30분경. 천천히 온다고 왔지만 오늘도 6시간 거리를 4시간에 온 건 똑같다. 이것 참...

[첨부 이미지가 있습니다.]


6. 남은 이야기

명주군왕릉에서 게스트하우스까지의 거리는 지도상 약 3.5km, 도보 40분이라고 되어 있다. 그러나 버스가 다니는 큰 길(아스팔트 길)로 돌아서 갔다가는 못해도 5-6km 이상을 걷게 될 듯하므로, 도보로 게스트하우스까지 복귀할 것이라면 돌아가는 길을 잘 확인하고 가도록 하자. 지도상으로 보기에는 질러가는 길 (하얀색) 이 있는 것 같다.

명주군왕릉 앞에서 탈 수 있는 502번 버스가 게스트하우스 앞을 지나 강릉시내로 나가므로, 시간이 대충 맞는다면 버스를 기다려서 게스트하우스나 강릉시내로 나갈 수도 있다. 버스 시간은 게스트하우스 앞을 기준으로 한 시간에서 대충 20-25분 정도를 뺀 시간이 명주군왕릉에 버스가 도착하는 시간이다. (왕릉 앞에서 버스가 시동 끄고 쉬기 때문에 저렇게 시간에 차이가 있는 것이다. 따라서 한 15분 전까지만 도착할 수 있다면 버스를 탈 가능성이 있따.) 다만, 버스 시간을 너무 믿지는 말자. 필자가 탄 버스도 게스트하우스 앞 통과 시간인 14시 15분보다 5분 일찍 게스트하우스 앞을 지나갔다. 시골 노선버스의 한계랄까. 정해진 시간보다 5-10분 정도 일찍 움직이는 것이 낭패를 막는 방법이다. 게스트하우스를 기준으로 한 버스 시간은 게스트하우스 식당 벽에 붙어 있다. 아래는 필자가 사진으로 찍어 둔 버스 시간표(게스트하우스 기준)다.

[첨부 이미지가 있습니다.]

하나 더 유의사항. 502번 버스는 강릉시내로는 나가지만 강릉시외버스터미널 앞으로는 가지 않는다. 그러나 강릉시외버스터미널 근처를 지나가므로, 기사 아저씨에게 강릉시외버스터미널 가려면 어디서 내려야 하느냐고 물어보도록 하자. 아마 홍제IC 인가 홍제동 주민센터인가에서 내리라고 할 것이다. 거기서 내려서 강릉시청쪽으로 걸어올라가면, 강릉시청을 지나자마자 아래쪽에 시외버스터미널이 보인다.

또 하나, 동서울로 돌아오는 시외버스를 탈 셈이라면 반드시 고속버스터미널 옆에 붙어있는 시외버스터미널로 가도록 하자. 필자처럼 잘못 들어갔다가 20,600원짜리 우등고속버스를 타는 불상사가 벌어지지 않도록... 어차피 무정차 직행버스도 대개 우등형인데, 뭐하러 7천원이나 더 내고 우등고속을...-_-;; (물론 그 실수 덕분에, 바로 강남고속버스터미널로 오는 15시 버스를 탈 수 있었다는 것은 비밀.) ]]> 여행/모임 후기 3구간 강릉바우길 바우길 Tue, 07 Jun 2011 10:37:29 +0900 <![CDATA[ 강릉바우길 2구간 트래킹 기록 (2011.06.02) (by 부엉이) ]]> http://www.nightowl.pe.kr/blog/article/390 http://www.nightowl.pe.kr/blog/article/390 2011년 6월 2일 - 제2구간 (구 대관령휴게소 ~ 대관령유스호스텔, 게스트하우스), 16km

지난 6월 2일~3일, 1박 2일 코스로 강릉 바우길 트래킹을 다녀왔다. 안 그래도 어딘가 한 번 다녀오려던 참에, 적절하게 꼬셔준 용권군에게 감사.

[첨부 이미지가 있습니다.]

동서울터미널에서 횡계까지는 버스로 2시간 40분 정도 소요. 횡계에서 출발점인 대관령휴게소까지는 택시를 타야 한다. (2011년 6월 현재, 택시요금 약 7~8000원 정도.) 코스의 출발점은 대관령휴게소 하행선이지만, 하행선쪽에는 아무것도 없고, 어차피 상행선쪽으로 고가도로를 건너와야 하므로 상행선쪽에서 내리는 것도 방법. 휴게소에서 간단하게 점심을 먹고 코스 출발. 정확히 12시에 대관령휴게소를 출발했다.

[첨부 이미지가 있습니다.]


1. 대관령휴게소[12:00] ~ 양떼목장[12:14]

총 16km에 약 5-6시간 소요라는 안내문과, 6시부터 게스트하우스 저녁시간이라는 것에 초반에 조금 서두른 감이 없지 않은데, 대관령휴게소부터 양떼목장까지의 길이 경사가 상당히 있다. 아직 다리가 덜 풀린 때라서 더 고생스럽다. 그래도 한 15분 정도만 걸으면 양떼목장에 도착하니 그리 먼 거리는 아니다.

[첨부 이미지가 있습니다.]


2. 양떼목장[12:14] ~ 국사성황당[12:35] ~ 통신탑[12:44]

양떼목장의 경치도 구경하면서 계속 숲길을 따라 걷다 보면 풍해조림지[12:29]가 나온다. 바우길 1구간과의 갈림길이기도 한데, 이정표도 있고 하니까 헷갈릴 일은 없다. 조금 더 가면 국사성황당에 도착[12:37]하는데, 이정표가 제대로 안 되어 있어서 여기서 잠시 헤맸다. 성황당 옆 아래쪽에 집이 한 채 있는데, 그 집 앞쪽으로 올라가는 작은 계단이 있으니 그쪽으로 이동한다. 2,3구간을 통틀어서 길을 못 찾아 헤맨 곳은 여기 한 군데. 다른 곳은 지도와 이정표로 모두 쉽게 커버가 가능하다. 조금만 올라가면 KT의 거대한 통신탑과 함께 이정표를 만나게 된다.

[첨부 이미지가 있습니다.]


3. 국사성황당, 통신탑[12:44] ~ 반정(대관령옛길표지석)[13:10] ~ 옛주막터[14:00] ~ 우주선화장실(옛길가든)[14:24]

여기부터는 계속 경쾌하게 내려가는 길이다. 반정[13:10]을 지나면 대관령옛길구간이 시작된다. 찻길(옛날의 영동고속도로. 지금은 한산한 일반도로다.)을 건너서 계속 내려간다. 처음에 신나게 올라가기도 했지만, 대관령을 내려가는 길이기도 해서 계속 내리막길. 그저 경치구경에 신이 난다. 중간에 다람쥐들도 몇 번 봤다. (없는 게 이상하지.) 옛 주막터를 지나[14:00] 우주선 모양의 화장실이 있는 옛길가든[14:24]까지는 계속 숲길과 계곡이 교차하는 외길 코스.

[첨부 이미지가 있습니다.]


4. 우주선화장실(옛길가든)[14:24] ~ 어흘리 ~ 보광리 ~ 대관령유스호스텔[15:58]

옛길가든을 지나면 어흘리를 지나는 마을 코스인데, 사실 이쯤부터 슬슬 피로가 몰려오기 시작했다. 일단 길은 마을길이어서 시멘트 포장 또는 아스팔트 포장도로로 바뀐다. 산길 경사보다도 시멘트길 경사가 오르기는 더 힘든 느낌. 마을길의 특성상 갈림길이 참 많은데, 지도와 이정표, 파란색의 바우길 솟대 문양을 길잡이 삼아 앞으로 나아간다. 어흘리 펜션촌을 지나 마을길, 어흘리 마을회관 앞에서 길을 건너면 다시 오르막인데, 필자는 처음 코스와 마지막 산길 못지 않게, 이 코스(위 큰 지도에서 보이는 ⓹번 작은 지도 부분)가 너무 힘들었다. 지금까지 걸어온 피로감에다, 오르막이 계속되는 시멘트 포장도로는 다리에 꽤나 무리를 주는 것 같았다.

여기(⓹번 지도 구간)를 무사히 통과하면[15:13] 다시 나타나는 산길은 마지막 고비. 시멘트길에서 힘을 다 뺐는데, 오르막이 웬말이냐. 그러나 이 울창한 산길을 지나면 다시 마을길이 나오고, 조금 더 가면 계곡이 보이면서 대관령유스호스텔이 시야에 나타난다. 여기까지 왔다면 목적지인 바우길 게스트하우스까지는 한달음이다. 게스트하우스에 도착한 시간은 16시 7분. 5-6시간 거리라더니 웬걸, 16~7km의 거리를 약 4시간에 주파해버렸다. 중간에 거의 쉬지 않고 내달린 결과이긴 하지만, 좀더 쉬엄쉬엄 와도 될 걸 그랬다.

[첨부 이미지가 있습니다.]


5. 게스트하우스

게스트하우스는 1박에 2만 5천원. 여기에는 저녁 및 다음날 아침 식사가 포함되어 있다. 다른 사람들과 함께 지내야 한다는 것만 괜찮다면 매우 좋은 선택. 아주머니 손맛이 나에게는 정말 잘 맞았다. 특히 배추김치.

[첨부 이미지가 있습니다.]

그리고, 이 날은 거의 죽은 듯이 잤다. 저녁 7시경부터 자기 시작해서, 다음날 새벽 6시에 깼던가...




..................................6월 3일의 3구간은 다음 글에서 계속. ]]> 여행/모임 후기 2구간 강릉바우길 바우길 Tue, 07 Jun 2011 00:57:44 +0900 <![CDATA[ 한국사능력검정시험 결과 (by 부엉이) ]]> http://www.nightowl.pe.kr/blog/article/389 http://www.nightowl.pe.kr/blog/article/389

예상대로, 1급 합격.

사상 최다 합격률을 기록할 것이 확실시되는 시험이었는데, 합격률 통계를 찾아보려니 안 나오네. 어디다 숨겨놓은 거야... ]]> 이런저런 이야기 1급 한국사능력검정시험 Wed, 01 Jun 2011 01:37:30 +0900 <![CDATA[ 막으려는 자와 뚫으려는 자 - 필터링 (by 부엉이) ]]> http://www.nightowl.pe.kr/blog/article/388 http://www.nightowl.pe.kr/blog/article/388
처음에는 파일 제목 필터링 같은 단순한 필터링으로 막던 애들이, 공유자들이 파일 이름 요상하게 변경해가면서 필터링을 피해가자(물론 필터링 허술하다고 저작권자들에게 웹하드들이 무더기로 고소당하는 사태까지 겪었으니까), 요즘은 파일 지문까지 생성해 가면서 이름 바꾸고 별짓 다 해도 인식할 수 있게 해놓고 있다. 덕분에, 파일 지문 뜨기 우회를 위해 압축파일에 패스워드를 걸어놓는가 하면, 한동안 머릿속에서 사라지다시피 했던 구석기 시대 압축 포맷들 - .ARJ 라던가, .LZH 같은 것들(.LZH는 요즘도 일본에선 사용되긴 하나 보던데..)이 등장하기도 한다. 한동안 웹하드 업계에 .EGG 파일이 넘쳐났던 이유 중에 하나가, EGG를 웹하드 등의 필터링 툴이 못 풀어냈기 때문이라나 뭐라나.

어제는, 무언가 다운로드 받으러 클럽박스에 갔더니, 어디서 듣도 보도 못했던 요상한 압축 포맷을 들고와서는 그걸로 압축을 풀라고 한다. 확장자를 보니 .ENC 라는 확장자다. 압축 푸는 툴도 일본어로 되어 있는 걸로 봐서 일본 쪽에서 나온 툴인 것 같은데, 파일 확장자로 봐서는 압축툴이라기보단 소스 파일을 사용자가 입력한 SEED(흔히 말하는 패스워드)를 사용해서 암호화하는 것 같다. 어찌 되었거나 필터링 툴이 압축을 못 푸는 이상 필터링은 불가능할 것이니, 소기의 성과는 충분히 거둔 셈이다. 물론 이것도 오래는 못 갈 거다. 막으려는 측에서도 분명히 무언가 대책을 세울 테니.

싸움 구경이 원래 재미있는 거라지만, 참 재미있는 광경이다.

필터링 전쟁을 보면서 얼핏 든 생각이지만, 파일 사이즈와 시간을 생각하지 않는다면, 꽤 유용할 것 같은 필터링 우회 방법이 있다. 바로 Base64를 이용하는 방법이다. 이건 이메일에 파일을 첨부할 때도 쓰이는데, 어떤 파일이건 이 규칙을 사용하여 변환하면 텍스트 파일이 된다. CD이미지건, 동영상 파일이건, 여기를 거치고 나면 모두 길다란 텍스트가 되어버리는 것이다.

3바이트를 읽어서 4바이트로 쓰는 특징 때문에 용량이 3분의 4배(약 1.33배)로 커지고, 다시 ZIP 등으로 압축한다고 해도 원래 파일을 압축하는 것보다는 조금 더 큰 파일이 만들어지며, 결정적으로 변환에 시간이 많이 걸린다. 350메가바이트 정도 되는 동영상 파일을 하나 변환하는 데 한 시간도 넘게 걸리니, 실제로 사용하기에는 심하게 무리가 있는 방법이기도 하다. 그러나, 애초에 바이너리 파일이 전혀 형태와 크기가 다른 텍스트 파일이 되어버리는데, 이게 필터링이 될 리가 없지.

최악의 경우, 일정 타이밍마다 쓰레기 문자를 끼워넣어두거나, 64개의 문자 대응 배열을 일정한 규칙에 따라 변경할 수도 있겠다. 다운로드 후에 원상태로 디코딩할 때는 해당 쓰레기 문자를 삭제하면서 디코딩하거나, 변경된 규칙에 따라서 디코딩하면 원래의 파일을 얻어내는 데는 문제가 없다. 그러나 자동 필터링 툴 따위가 그런 규칙을 알고 있을 리가 없으니, 자동으로 필터링한다는 것은 불가능에 가깝다. 사람이 일일이 돌아다니면서 블럭을 먹인다면 모르지만..

....그런데, 350메가 짜리 인코딩 하는 데 한시간 넘게 걸린다는 걸 나는 어떻게 알고 있는걸까. 어떻게 알고 있긴. 실제로 툴 만들어서 인코딩을 해 봤으니까 알지. (또 쓸데없는 짓을!)
]]> 이런저런 이야기 필터링 Base64 .ENC Wed, 01 Jun 2011 00:34:04 +0900 <![CDATA[ Panasonic Let's Note CF-R6A 윈도우 7 업그레이드 가이드 (by 부엉이) ]]> http://www.nightowl.pe.kr/blog/article/387 http://www.nightowl.pe.kr/blog/article/387 이 글은 한국 내 파나소닉 렛츠노트 사용자 모임인 렛츠월드 (http://www.letsworld.co.kr/) 에 등록했던 글을 일부 내용을 추가하여 정리한 것입니다. 최초 작성된 원본 게시물의 경로는 다음과 같습니다:

http://club.cyworld.com/50258550112/115279066



1. 서문

필자가 사용하고 있는 Panasonic Let's note CF-R6A 모델은 원래 윈도우 비스타 Business 가 기본으로 설치되어 있던 모델이다. 그러나, 필자를 비롯하여 많은 사람들이 이를 통째로 날려버리고(...) 윈도우 XP로 다운그레이드하여 사용했다. 설치되어 있는 윈도우 비스타가 - 당연하게도 - 일본어 버전이라는 것도 하나의 이유였다. 물론, 함께 따라온 제품키를 사용하여 한글판 윈도우 비스타를 설치한 후 인증받을 수는 있다. 심지어, 파나소닉 R6A 리커버리용으로 제공된 윈도우 비스타 일본어 버전의 Token 파일과 제품 키를 백업한 후 이를 한글판 윈도우 비스타에 복구하면 인증 절차 없이 R6A에서 윈도우 비스타를 사용할 수 있다. 그러나 가장 중요한 이유는, 안 그래도 무거운 윈도우 비스타를 기본 1GB 나 확장해봐야 1.5GB인 R6A 에서 사용한다는 것이 무리라는 것이었다.

윈도우 비스타를 최적화한 윈도우 7은 윈도우 비스타에 비해서는 상당히 가벼워진 퍼포먼스를 보여주기 때문에, 윈도우 XP에 비할 바는 못되지만 그럭저럭 쓸만은 한 모습을 보여준다. 물론 윈도우 XP가 보여주는 퍼포먼스에 많이 못 미치기 때문에 대개는 윈도우 7이 출시된 이후에도 윈도우 XP에 머물러 있는 사람들이 많았다. 그러나 윈도우 XP의 지원 종료 기간이 거의 다 되어가기도 하고, 최근 각광받고 있는 SSD를 제대로 관리하기 위해서는 윈도우 XP보다 윈도우 7이 더 유리하기 때문에 (필자 역시 R6A의 하드 디스크를 SSD로 교체한 것을 계기로 하여 윈도우 7로 업그레이드 했다.) 어느 정도는 퍼포먼스 하락을 감수하고서라도 윈도우 7을 사용해야 할 이유가 생겼다.

[첨부 이미지가 있습니다.]

참고 사항. 노트북과 SSD

SSD로 노트북 하드 디스크의 교체를 생각하시는 분들은, 자신의 노트북이 SSD의 장점 중 하나인 빠른 속도를 충분히 누리지 못할 수도 있음을 감안하고 SSD를 구입하기 바란다. 필자도 원인을 알지 못하였으나, 검색을 해 보니 자신의 노트북이 SATA-1 만을 지원하는 경우에 이런 현상이 발생한다는 이야기가 있다.

"Your sequential read/write speeds will be capped by sata 1 speeds (so about 130 -140MB/s) but you'll still get full benefit of random read/write speeds and low latency of the ssd. I'd still get the ssd, it should be a night and day difference compared to the slow 2.5" laptop hdds." (F1shF4t)

"Yeah, depending on how expensive of an SSD you get, your sequential speeds to take a small hit (but still be way faster than a laptop spindle HDD). Just don't spend the money on an SSD that gets 200+ MB/s read/write." (veri745)

(from: http://forums.anandtech.com/showthread.php?t=2054836)

R6A의 경우에도, 기존에 들어있는 하드디스크가 SATA-1인 것으로 미루어 볼 때, SATA-2를 지원하지 않는 것으로 짐작할 수 있다. 실제 필자의 경우에도 하단 그래프와 같이 일반적인 데스크탑 SATA 하드디스크보다 조금 더 나은 정도의 성능밖에 얻지 못한다. (정확한 수치는, 연속 읽기 129 MB/s, 연속 쓰기 119 MB/s, 랜덤 읽기 19916 IOPS, 랜덤 쓰기 8516 IOPS 이다.)

[첨부 이미지가 있습니다.]

물론 필자의 노트북에 장착되어 있던 하드디스크는 5400RPM의 2.5인치 노트북용 하드디스크(도시바 MK8037GSX)였기 때문에, 이전과 비교한다면 눈에 띄는 상당한 성능의 향상이 있다. 다만, 일반적인 데스크탑에 SSD를 사용하여 신세계를 경험해 본 사람의 경우, 노트북에서 생각보다 크지 않은 성능향상폭에 실망할 가능성이 있다. 따라서 교체 결정 전에 자신과 같은 모델을 사용하며 또한 SSD를 사용중인 다른 사용자에게 성능향상 폭이나 벤치마크 결과(숫자놀음일 뿐이라고 생각하지만) 등의 정보를 꼭 얻어본 후 교체를 결정하기 바란다. 아직은 SSD의 가격이 많이 높은 편이기 때문에, 적지 않은 가격을 투자해서 얼마나 성능의 향상을 얻을 수 있는지가 상당한 변수가 되기 때문이다.




2. CF-R6A 모델의 윈도우 7 업그레이드에 대한 파나소닉사의 입장

CF-R6A 모델의 윈도우 7 업그레이드에 대한 파나소닉사의 입장은 일견 이중적이다. 파나소닉은 2009년 11월 30일에 공개한 보고서에서, Let's Note CF-R6A 및 그 이하 버전에 대한 윈도우 7 업그레이드를 "권장하지 않음" 으로 발표하였다. 이유는 파나소닉이 CF-R6A 및 그 이전 버전, 구체적으로 R6M, Y5M, W5A, W5M, T5A, T5M 모델에서 사용한 Mobile Intel 945GMS Express 그래픽 칩셋(내장)에 대응하는 윈도우 7 드라이버를 제공할 계획이 없기 때문이라고 한다. 따라서, 윈도우 7에서 기본으로 제공하는 945GM 칩셋의 WHQL 공통 드라이버를 사용하여야 하고, 이에 따라 몇 가지 불편한 제한 사항이 생기게 된다.

필자가 사용해 보니, 예를 들면 관리자 권한을 요구하는 경우 화면이 어두워지면서 관리자 권한을 줄 것인지를 묻게 되는데, 이것이 원활하게 이루어지지 못하고 일단 화면이 꺼졌다가 잠시 후에 다시 되돌아오면서 관리자 권한을 줄 것인지 묻는 창이 뜬다. 아마도 이것이 보고서에서 언급하고 있는 "화면이 일시적으로 흐트러지는 등의 문제" 인 듯 하다.

CF-R6A 윈도우 7 대응 평가서는 다음의 링크에서 열람할 수 있다. 단 일본어로 되어 있으므로 일본어를 모르는 사용자는 네이버 번역기 등을 이용하기 바란다. 대충 읽을 수 있을 정도의 수준은 번역이 된다.

http://faq.askpc.panasonic.co.jp/faq/docs/002309


그러나 그렇다고 하여 윈도우 7 설치가 불가능하지는 않다. 오히려 파나소닉은, 이러한 제한사항을 수용하는 경우에 윈도우 7로 업그레이드를 할 수 있도록, 윈도우 7에 대응되는 기본적인 R6A 드라이버 및 응용 프로그램을 같은 날 발표하였다. 해당 보고서가 일본어로 되어 있기 때문에 국내에서는 한동안 R6A 모델의 윈도우 7 대응 드라이버가 출시되지 않은 것으로 알려져 있었고, 그래서 윈도우 비스타에 대응하는 드라이버를 윈도우 비스타 호환 모드로 설치하여 사용하는 경우가 많았다. 사실 그렇게 사용하여도 상관이 없고, 그나마도 윈도우 7 설치시 대부분의 드라이버를 설치해 주기 때문에 추가적으로 설치하여야 하는 드라이버는 2개 뿐이기는 하다. 그러나 아무래도 윈도우 7에 정식으로 대응하는 드라이버를 설치하는 것이 안정성 측면에서 좀 더 나을 것이므로, 아래 해당 항목에서 제시하는 경로를 확인하여 해당 드라이버를 다운로드 받기 바란다.

참고로, 윈도우 7을 설치하고 나면, 윈도우 업데이트에서 945GM 칩셋에 대한 드라이버 업데이트가 제공된다. 최신의 드라이버 업데이트이므로 꼭 업데이트를 받기 바란다.

아. 잊을 뻔했다. 보고서에서도 언급하고 있지만, RAM이 1GB 또는 그 미만인 경우, 1.5GB로 업그레이드 할 것을 강력히 권고한다. 1GB의 램으로는 윈도우 7을 원활히 돌리기에 많은 문제가 있다. 사실 1.5GB로도 문제는 있지만, R6A는 램 확장 가능 최대 용량이 1.5GB이기 때문에, 어쩔 수 없다.



3. 윈도우 7 설치

윈도우 7의 설치는 윈도우 XP의 설치보다 더 간단하다. 물론 윈도우 비스타의 설치 방식을 그대로 따르고 있다. 다만 제품 키로 에디션을 구분하던 윈도우 비스타의 방식이 아닌, 일단 처음에 설치할 에디션을 선택하고 나중에 제품 키를 물어보는 방식으로 설치 방식이 변경되었으므로 이 점 주의를 요한다. 단, 일반적으로 정품의 윈도우 DVD는 설치할 수 있는 에디션의 제한이 있으므로 제대로 설치 DVD를 구하였다면 에디션을 잘못 고르는 문제는 발생하지 않는다.

설치할 수 있는 에디션이 미디어마다 제한이 되어 있지만, 실상 DVD의 구성은 똑같다. 즉 어떤 버전이든, Starter 부터 Ultimate 까지 모든 에디션의 파일이 포함되어 있다. 윈도우 7 설치 DVD의 sources 폴더 안에 보면 ei.cfg 라는 파일이 있는데, 이 파일의 설정에 따라 설치할 수 있는 에디션이 결정되는 것이다. 따라서 설치 DVD에서 이 파일만 삭제해 주면, 설치 시 어떤 에디션을 설치할 것인지를 묻는 선택 메뉴 화면이 나타나게 된다.


윈도우 XP 시절에 윈도우 설치가 어려웠던 요인 중의 하나는, R6A가 ODD가 장착되어 있지 않은 모델이어서 외장 광학 드라이브를 가지고 있지 않으면 CD나 DVD를 통해 XP를 설치할 수 없다는 점이었다. 그래서 USB에 CD영역을 생성하여 그 안에 윈도우 XP 설치 CD를 우겨넣거나, 별도의 부트 로더를 이용하여 USB 등에 윈도우 XP CD를 부팅 가능하게 복사하여야 했다. 어떤 방법이든 번거롭고 골치아프기는 마찬가지였는데, 전자의 경우 USB 스틱에 따라 CD영역 제작에 실패하는 등의 특성 문제가 있었고, 후자의 경우는 방법이 상당히 복잡했다.

그러나, 윈도우 비스타 이후의 버전은, 자체에 제공되는 diskpart 명령어를 이용하여 USB 드라이브에 직접 부트 영역을 생성할 수 있다. 이렇게 부트 영역이 생성된 USB 드라이브에 설치 DVD의 파일들을 그대로 복사하기만 하면 이를 이용하여 윈도우 설치가 가능하다. 따라서, 설치를 위해 윈도우 설치 미디어를 제작하는 것이 상당히 쉬워졌다.

참고. diskpart 명령을 이용하여 윈도우 7 설치 USB 작성하기

diskpart 명령은 과거 버전에서 제공되던 fdisk 를 대체하는 것으로, 윈도우 비스타 이후 버전부터 제공된다. 현재 윈도우 XP를 사용하고 있다면, 주변에 윈도우 비스타 또는 윈도우 7이 설치되어 있는 컴퓨터에 USB 디스크를 꽂고 아래의 작업을 수행해서 가져오도록 하자. 윈도우 비스타 환경에서 작업을 하더라도 윈도우 7 설치 디스크를 만드는 데 문제가 없다.

0. USB 포트에 작업할 USB 디스크를 연결한다. 주의할 것은, 작업 과정에서 USB 디스크의 내용이 모조리 삭제되므로, 이 USB 디스크에 중요한 내용이 있다면 반드시 백업을 해야 한다는 것이다.

1. 일단 관리자 모드로 명령행 모드를 연다. [모든 프로그램]-[보조 프로그램]-[명령 프롬프트]에 마우스 오른쪽 버튼을 클릭하고 "관리자 모드로 실행" 을 클릭해준다.

2. 명령행이 나오면 diskpart 를 입력한다.

3. DISKPART> 라는 명령 프롬프트가 나오면 list disk 라고 입력한다. 그러면 현재 컴퓨터에 연결되어 있는 모든 디스크의 목록이 나온다. 여기에서, 작업할 USB 가 디스크 몇 번인지를 확인한다. 이 번호를 잘못 확인하면 엉뚱한 디스크를 선택하여 작업을 진행할 수 있고, 그 결과는 해당 드라이브의 모든 데이터의 손실이다. 주의하자.

4. select disk # (#는 위에서 확인한 USB 디스크의 번호) 라고 입력한다. 예를 들어 위에서 확인한 USB 디스크 번호가 3이라면, select disk 3 이라고 입력하면 된다. 몇 번 디스크가 선택된 디스크라고 메시지가 뜰 것이다. 정확한 번호를 입력해야 후회할 일을 만들지 않는다는 점은 앞에서 이야기했다.

5. clean 이라고 입력한다. 해당 디스크가 깔끔하게 삭제된다.

6. create partition primary 라고 입력한다. fdisk에서 파티션을 만들어 주는 것과 같다.

7. list partition 이라고 입력한다. 아마도 하나의 파티션만 만들었기 때문에, 파티션은 1 하나 뿐일 것이다.

8. select partition 1 이라고 입력한다. 1은 바로 앞에서 확인한 파티션 번호이지만, 하나의 파티션만 만들었기 때문에 거의 1 일 것이라고 생각한다. 혹시 다른 번호로 나온다면 그 번호로 입력해 준다.

9. active 라고 입력한다. 이 파티션이 컴퓨터를 부팅할 수 있는 액티브 파티션이라는 것을 표시한 것이다.

10. format fs=ntfs quick 이라고 입력한다. NTFS 파일 시스템으로 빠른 포맷이 이루어진다.

11. assign 이라고 입력한다. 이는 이 USB 드라이브에 드라이브 문자를 할당하여 바로 사용할 수 있게 한다.

12. exit 라고 입력한다. diskpart 프롬프트가 다시 명령 프롬프트로 바뀌면서 종료된다.

이제 설치 작업 용 USB 디스크가 완성되었다. 이 디스크에 윈도우 7 DVD 내용을 그대로 복사해 넣으면 윈도우 7 설치 USB디스크가 완성된다.


설치용으로 작성된 USB 디스크를 연결하고 컴퓨터를 켠 후, 처음 메모리 검사 화면에서 ESC 키를 입력해 주면 부팅에 사용할 디스크를 선택할 수 있다. 이 방법을 이용하면 굳이 CMOS SETUP 을 수정해 주지 않아도 USB 디스크로 부팅이 가능하다.

설치 과정은 그냥 따라가기만 하면 되므로 특별히 문제될 것은 없다. 다만, 윈도우 7은 새 디스크에 설치 시 드라이브 문자가 할당되지 않는 (보이지 않는) 100MB 정도의 시스템 파티션을 하나 만드는데, 이는 사실 일반적인 경우에는 불필요한 것이다. 필자가 알고 있기로는 이 파티션은 윈도우 7 Ultimate 에디션에서 BitLocker 를 사용하는 경우에만 필요한 것이므로, 필자처럼 Professional 에디션을 설치하는 경우나 그 이하의 에디션을 설치하는 경우에는 필요가 없다. 따라서 이를 만들지 않도록 하는 것이 아무래도 낫겠다.

윈도우 7 설치 시 100MB 시스템 파티션 만들지 않기

새 디스크에 윈도우 7 설치 디스크로 파티션을 생성하면 어김없이 100MB 정도 크기의 시스템 파티션이 추가로 생성된다. 이를 막기 위해서는 우선 100MB 보다 작은 크기의 파티션을 생성한 후, 이를 원하는 크기로 확장하면 된다. 아래 예는 128GB의 디스크를 64G, 64G로 100MB 파티션의 생성 없이 나누는 방법이다.

1. 윈도우 7 설치 중 파티션 선택 화면에서, 일단 100MB 이하의 크기를 갖는 파티션을 만든다.

2. 하단의 확장 메뉴를 사용하여 생성된 100MB의 파티션을 64GB로 확장한다.

3. 다시 100MB 이하의 크기를 갖는 파티션을 만든다.

4. 확장 메뉴를 사용하여 생성된 100MB의 파티션을 64G로 확장한다.




4. 윈도우 7 드라이버의 설치

윈도우 7을 성공적으로 설치하면, 이미 대부분의 드라이버는 자동으로 윈도우 7이 설치를 해 준다. 설치 후 장치 관리자를 확인하면 두 개의 장치가 알 수 없는 장치로 나타날 것이다. 하나는 Hot Key 드라이버이고, 다른 하나는 Panasonic Misc 드라이버이다. 따라서 이 드라이버를 잡지 않으면 R6A의 주요 핫키를 사용할 수 없는 상황이 벌어진다.

위에서 이미 언급한 바 있듯, 파나소닉은 윈도우 7 업그레이드 보고서를 내면서 R6A 에 대응하는 윈도우 7 드라이버를 함께 공개했다. 이 드라이버들은 다음의 경로에서 다운로드 받을 수 있다. 아래 페이지를 연 후 하단으로 내려가면 드라이버들이 등록되어 있으므로 모두 다운로드 받는다.

* CF-R6A/R6M 대응 윈도우 7 드라이버:

http://faq.askpc.panasonic.co.jp/faq/docs/02314


특히 필요한 것은 아직 잡히지 않은 Panasonic Misc (4번) 와 Hotkey (2번) 이지만, 터치 패드 드라이버 (3번) 도 설치해 주면 터치 패드의 움직임이 훨씬 부드러워지므로 다운로드 받도록 한다.

다음은 위 2,3,4번 파일의 직접 링크이다. 업데이트는 없을 것 같지만, 만약 링크가 깨진다면 위 페이지를 방문하여 다운로드 받도록 한다.

1. HotKey 드라이버:

http://pc-dl.panasonic.co.jp/public/soft_update/d_os/up_seven/hotkey_11.1.1100.0_s8n8f8r8w8t8y8_x_w7_d091351.exe

2. Panasonic Misc 드라이버:

http://pc-dl.panasonic.co.jp/public/soft_update/d_os/up_seven/newmisc_1.2.1100.0_s8n8f8r8w8t8y8_x_w7_d091352.exe

3. 터치 패드 드라이버:

http://pc-dl.panasonic.co.jp/public/soft_update/d_os/up_seven/mouse_13.2.6.1_s8n8f8r8w8t8y8_x_w7_d091209.exe


각 파일을 다운로드 받은 후 실행하면 자동으로 압축이 풀린다. 대개 C:\UTIL2\DRIVERS 아래에 각각의 폴더를 만들어 저장된다. 이제 각각의 압축 풀린 폴더에 가서 다른 거 실행할 필요 없이 pinstall.bat 파일만 실행해 주면 된다. 아, 혹시 Secure SD디스크를 사용한다면 5번도 받아서 설치해 준다. 필자는 사용하지 않기 때문에 설치하지 않았다.



5. 파나소닉 유틸리티의 설치

이제 파나소닉에서 제공하는 유틸리티들을 설치할 차례다. 저 위에서 이야기한 바 있는, 윈도우 7 업그레이드 보고서에서 가장 많은 분량을 차지하고 있는 것이 바로 기존의 파나소닉 유틸리티들의 제한 사항에 관한 것이다. 드라이버 이외에 윈도우 7에 대응하여 파나소닉이 제공하는 유틸리티는 7개 (6번~12번) 뿐이다. 그나마도 6번은 TPM 드라이버이므로 제외하고, 7번은 파나소닉 유틸리티 공통 라이브러리(pcommon)이므로, 실제로 제공하는 유틸리티 수는 5개 뿐이라고 하겠다. 각각은 다음과 같다.

6. TPM 드라이버. 윈도우 7에서도 알아서 잡아주므로 굳이 설치할 필요가 없다. 다만 제공되는 드라이버가 최신의 버전인지는 확인하지 않았다.

7. Panasonic Common Components. 파나소닉 유틸리티들이 사용하는 공통 라이브러리들의 모음이다. 이것이 설치되지 않으면 설치나 동작에 문제가 생기는 유틸리티들이 있으므로 가장 먼저 설치해준다.

8. Panasonic Notification. 뭐에 쓰는 물건인지 필자도 모른다.

9. 시큐리티 설정 유틸리티. 필자가 설치하지 않았기 때문에 무엇을 설정하는지 모른다.

10. 휠 패드 유틸리티. Synaptics사에서 제공하는 휠 패드 유틸리티이다.

11. Hotkey Appendix. Hot Key 관련 프로그램인 것 같아서 설치는 했지만, 구체적인 기능은 필자도 모른다. 실제로 실행해 보아도 아무것도 나오지 않는다.

12. 무선 변환 유틸리티. 802.11a 를 켜고 끄는 유틸리티. 일본의 경우 802.11a의 사용을 법적으로 규제하고 있다고 한다. 그래서 이런 유틸리티가 필요한 듯 하지만, 국내에서는 불필요하다.

참고로 필자는 위 유틸리티들 중 7번, 8번, 10번, 11번만 설치하였다. 7번은 필수적으로 설치. 10번은 설치 권장이다. 8번과 11번은 문제가 생기면 설치해 볼 것.


윈도우 7 대응 유틸리티는, 과거 윈도우 XP 대응 유틸리티처럼 언어 셋이 맞지 않아서 설치가 안 되는 등의 문제가 발생하지 않으므로, 마음 편하게 설치해도 된다.



6. 무선 랜 드라이버 및 Intel Proset 무선 랜 유틸리티의 문제

앞에서 필자가, 제공된 드라이버 및 유틸리티 중 13번의 존재를 계속 무시하고 있는 것을 많은 독자들은 이미 눈치채고 있을 것이다. 13번은 파나소닉이 뒤늦게 제공한 윈도우 7 대응 3945abg 칩셋 무선 랜 드라이버 및 Intel Proset 유틸리티이다. 과거 윈도우 XP 시절에 Proset 유틸리티를 이용하여 무선 랜을 이용해 왔던 사용자라면 역시 이를 설치하기를 선호할 텐데, 이 파일은 한국 사용자가 사용하기에는 심각한 문제를 하나 가지고 있다.

구체적으로, 이 파일을 다운로드 받아서 압축을 푼 후, 장치 관리자에서 수동 드라이버 업데이트의 방법으로 무선 랜 칩셋 드라이버만 업데이트 하는 것은 상관 없다. 압축을 푼 후, Win7\S32\Drivers 위치에 있는 드라이버를 수동 업데이트 하면 된다. 그러나, 함께 들어 있는 Proset 유틸리티는 절대로 설치하면 안 된다.

이유는, CF-R6 모델이 일본 국내 시판용의 모델이라는 점에서 시작된다. 내수용 모델이다 보니, Proset 유틸리티 역시 인터내셔널 사용자를 고려하지 않고 일본어 이외의 언어셋을 (심지어 영어조차도) 모두 삭제해 놓았다. 따라서 이를 설치할 경우 설치가 실패하거나 설치 이후 일본어로 실행되는 Proset 유틸리티를 보게 될 것이다. 과거 윈도우 XP 시절에도, 출시 이후 업데이트 제공된 Proset 유틸리티에 같은 문제가 있어서 여러 사람을 골탕먹인 전력이 있는데, 이게 윈도우 7 대응 유틸리티에서도 그대로 재현되어버렸다.

Proset 유틸리티를 사용하지 않더라도, 윈도우 7의 자체 무선 랜 접속 기능도 상당히 쓸만 하다. 따라서 이를 설치하지 않아도 무선 랜 사용에는 지장이 없다. 굳이 Proset 유틸리티를 사용해야 한다면, 인텔 홈페이지를 직접 방문하여 Proset 유틸리티를 다운로드 받아 사용하기 바란다.



7. 기타 아쉬운 파나소닉 유틸리티들의 설치

위에서 보듯, 윈도우 7 대응으로 공개된 유틸리티들은 몇 개 되지 않고, 그나마도 그다지 쓸 일이 없는 녀석들이 대부분이다. 많은 사용자들이 윈도우 XP나 윈도우 비스타 시절에 사용해 오던 유틸리티들의 상당수가 윈도우 7 대응으로는 제공되지 않고 있다. 필자의 경우, ECO 모드를 켜고 끄는 유틸리티가 없어서 상당히 불편했기에, 윈도우 비스타 대응으로 공개된 유틸리티를 대신 다운로드 받아서 설치하였다. 별 문제 없이 실행되고 동작한다.

* ECO 모드 On/Off 유틸리티(윈도우 비스타 대응):

http://pc-dl.panasonic.co.jp/public/soft_first/cf-y_w_t_r7a/chgbmode_y7r6w5t5_1244_d070179.exe

* 기타 R6A 대응 윈도우 비스타 드라이버 및 유틸리티 링크:

http://askpc.panasonic.co.jp/s/download/install/r6aw.html#model2


그 외 유틸리티들도 상당수는 별 문제 없이 동작할 것이다. 다만 이들 유틸리티들의 경우 윈도우 7에서 동작하는 데 제한이 있는 경우가 많다. (전력 절약이라던가, PCInfo 라던가..) 이러한 제한은 위 업그레이드 평가서에서 다루고 있으므로 확인하도록 한다.



8. 기타: 윈도우 7 발열 문제

윈도우 7이 설치된 렛츠노트 R6A 는, 윈도우즈 XP가 설치된 R6A 에 비해 훨씬 더 많은 열을 발생시킨다. (아마도 시스템 자원을 윈도우즈 XP에 비해 더욱 쥐어짜내 쓰기 때문이 아닌가 한다.) 듀얼코어 CPU에 팬리스 시스템이어서 안 그래도 평소 발열과 관련된 이슈가 있는 R6A에 있어서는 치명적인데, 특히 영상물 등을 최대화면으로 시청할 때 약 10~15분 정도가 경과한 시점에서 CPU 점유율이 최대로 올라가는 (거의 Freezed 수준) 현상이 자주 발생하곤 한다.

이러한 사태를 막을 근본적인 방법은 없는 것 같으나, Aero 를 끄면 이와 같은 현상이 거의 나타나지 않을 정도로 상태가 좋아진다. 방법은 Aero를 사용하지 않는 윈도우 7 스타터 테마나 다른 고대비 테마로 변경하는 것이다. ]]> 컴퓨터 사용 경험 Panasonic 윈도우7 설치 렛츠노트 파나소닉 윈도우7 R6A Wed, 18 May 2011 06:48:46 +0900