<?xml version="1.0" encoding="UTF-8" ?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
	<title>부엉이의 나무구멍 속 작은 공간</title>
	<link>http://www.nightowl.pe.kr</link>
	<description>방향전환. 이제는 되돌릴 수 없다.</description>
	<language>ko</language>
	<pubDate>Fri, 27 Apr 2012 12:58:58 +0900</pubDate>
	<generator>Owl-Blog RSS Generater</generator>
	<item>
		<title>
		<![CDATA[  VMware 에 윈도우 98se 설치 후 소리(사운드 카드) 세팅하기 (by 부엉이)  ]]>
		</title>
		<link>http://www.nightowl.pe.kr/oblog/article/429</link>
		<guid>http://www.nightowl.pe.kr/oblog/article/429</guid>
		<description>
			<![CDATA[  <br/>1.<br/><br/>엄격히 말하자면, 이미 윈도우 98se 라는 운영체제는 이미 생명력을 다 한 운영체제이다. 아니, 생명력을 다 하고도 모자라서, 이미 무덤 파고 관 속에 들어가 누운지도 몇 년 이상 지난 운영체제라고 하는 게 좀 더 정확하겠다. 그러나, 2012년 현재에도 윈도우 98se 를 필요로 하는 사람들이 있으니, 바로 그 시절에 돌아가던 프로그램 중 현재의 운영체제에서 돌아가지 않는 프로그램들을 구동해야 하는 사람들이다. 대부분의 경우 <B><u>그 시절에 돌아가던 고전게임을 플레이하기 위해서 윈도우 98se 를 찾는 경우</u></B>가 많겠지만, 꼭 게임이 아니더라도, 공개적으로 말할 수 없는 몇몇 분야에서는 여전히 쓰이고 있는 것 같다. 이럴 때에 사용할 만한 방법은 VMware 등의 가상 머신 프로그램을 이용하여 가상 머신상에 윈도우 98se 를 설치하고, 그 안애서 프로그램을 사용하는 것이다. VMware 는 기본적으로 돈을 주고 사서 사용해야 하는 상업용 프로그램이지만, VMware Player 의 경우 VMware 의 기본적인 기능을 사용할 수 있으면서 개인 사용자에게 무료로 제공되므로, 개인 사용자의 경우 굳이 비싼 VMware Workstation 을 구입해 사용하지 않더라도 VMware Player 를 이용하여 소기의 목적을 달성할 수 있다.<br/><br/><br/><br/>2.<br/><br/>윈도우 98se 의 설치 자체는, 사실 VMware 또는 VMware Player 프로그램 자체에서 알아서 해 주는 부분이 대부분이기 때문에 애초 어려울 것 자체가 없다. 따라서 이 부분에서 고생하는 사람은 거의 없다고 봐도 된다. 문제는 설치 이후에 몇몇 하드웨어가 제대로 인식되지 않는 것이다. 현재의 시스템과 윈도우 98se 가 사용되던 당시의 시스템을 비교해 보면, 윈도우 98se 가 이를 제대로 인식하지 못하는 것은 사실 당연하다. 이런 경우를 대비하여, VMware 는 VMware Tools 이라는 도구를 윈도우 설치 이후에 설치하도록 하는데, 이를 설치하면 일반적인 범위 안에 있는 하드웨어에 대해서는 표준적인 하드웨어 규격에 준하여 에뮬레이션 기능을 제공해 준다. 예를 들면 640x480, 16칼라 등으로 고정된 화면을 일반적인 높은 해상도로 변경할 수 있고, 호스트와 가상 머신 사이에 데이터를 드래그 앤 드롭으로 교환할 수 있는 등의 호환성 관련 옵션을 제공하고 있다. (이런 기능을 제공하기 때문에, VMware 가 윈도우 98 운영체제를 "지원"한다고 말할 수 있는 것이겠다.) 따라서, 윈도우 98se 의 설치를 마친 후에는 반드시 VMware Tools 를 설치해 주어야 한다.<br/><br/>그러나, VMware Tools 를 사용한다 하더라도 몇몇 옵션들은 여전히 사용 불가 상태일 것이다. VMware 가 세상의 모든 하드웨어를 혼자 지원할 수는 없는 노릇이니 이는 어쩔 수 없다. 특히 일반적으로 사용되는 하드웨어가 아니거나 일정한 표준적인 규격을 찾을 수 없는 하드웨어들의 경우에는 VMware 가 기본적으로 지원할 수 없을 것이기에, 이런 하드웨어들을 꼭 사용해야만 한다면 해당 하드웨어들의 윈도우 98se 대응 드라이버를 직접 찾는 수밖에 없다. 그조차도 없다면 아예 사용이 불가능하다.<br/><br/><br/><br/>3.<br/><br/>그러나, 일반적인 항목임에도 불구하고 기본적으로 제공되지 않는 것이 있는데, 그것은 사운드 부분이다. 거의 모든 경우에, VMware Tools 를 설치해도 사운드 드라이버는 잡히지 않을 것이다. 최근의 사운드 카드나 사운드 칩셋들은 (모두라고 해도 좋을 정도로 대부분) High Definition Audio(HD Audio) 규격을 따르는데, 이 규격은 윈도우 XP 서비스팩 3 이후에서만 기본적으로 지원하는, 윈도우 XP 서비스팩 2 이전의 윈도우 XP에는 Microsoft 에서 제공하는 별도 패치(KB888111)를 설치해야만 정상적으로 인식되는 규격이다. 따라서, 윈도우 XP 보다 먼저 출시된 윈도우 98se 의 경우에는 (제작사에서 별도의 방법을 제공하지 않는 한) High Definition Audio 를 VMware 의 윈도우 98se 에서 직접 잡아 줄 방법이 없다. 대부분의 경우 최근 제품에 대해 윈도우 98se 대응 드라이버를 제공할 리가 없으므로, <B><u>High Definition Audio 규격의 사운드 카드를 윈도우 98se 에서 세팅하기 위해 이에 대한 드라이버를 찾는 것은 대개 시간 낭비다(모르는 것보다 조금 아는 것이 더 위험하다는 것은 이럴 때에도 적용되는 만고의 진리다).</u></B><br/><br/>그러나, 그렇다고 해서 방법이 없지는 않다. VMware 는 이런 경우에 대비하여 과거 사운드 카드의 표준이다시피 했던 사운드 블래스터 계열의 사운드 카드를 에뮬레이션 해 주는 기능을 가지고 있다. 따라서, 사운드 블래스터(정확히는 Sound Blaster PCI 128)의 드라이버를 VMware 의 윈도우 98se 에 설치해 주면, VMware Tools 의 에뮬레이션 기능이 동작하여 윈도우 98se 상에서 사운드 카드를 활성화 시킬 수 있다. 현재 다운로드 받을 수 있는 드라이버는 버전 5.12.01 로서, Creative 사의 홈페이지에서 아직 다운로드가 가능하다.<br/><br/><div style="margin: 10px; padding: 10px;">■ 드라이버 다운로드 경로 : http://support.creative.com/downloads/download.aspx?nDownloadId=1843<br/>■ 대체 다운로드 경로(이 블로그) : [첨부 파일 링크가 있습니다.] (위 드라이버 다운로드 경로에서 다운로드 받을 수 없는 경우에만)</div><br/><br/>위 드라이버의 경우 윈도우 98se 또는 그 이후의 운영체제에서만 사용이 가능하다. 윈도우 98 의 초기 버전(First Edition)의 경우 이 드라이버를 적용하면 블루스크린을 보게 되므로 사용해서는 안 된다.  ]]>
		</description>
		<category>컴퓨터 사용 경험</category>
		<category>사운드카드</category>
		<category>VMware</category>
		<category>Windows 98se</category>
		<category>High Definiton Audio</category>
		<pubDate>Fri, 27 Apr 2012 12:58:58 +0900</pubDate>
	</item>
	<item>
		<title>
		<![CDATA[  트위터 단상 (부제: 내가 트위터를 하지 않는 이유) (by 부엉이)  ]]>
		</title>
		<link>http://www.nightowl.pe.kr/oblog/article/428</link>
		<guid>http://www.nightowl.pe.kr/oblog/article/428</guid>
		<description>
			<![CDATA[  <br/>가끔 나에게 트위터 하지 않느냐는 권유성 질문을 하는 사람들이 몇 있다. 그럴 때마다 내 단골 답변은 "블로그(홈페이지) 하나 관리하기도 벅차다"는 답변이다. 물론 틀린 말은 아니다. 블로그 및 홈페이지 전체를 직접 작성한 도구를 사용하여 운영하다 보니 문제 해결을 위해 직접 코딩을 해야 하는 경우도 종종 있고, 그다지 알려진 곳이 아니라서 자주 있는 일은 아니지만 방문자들의 방명록이나 덧글이 달리면 그에 대해 답글도 달아줘야 하며, 요즘 들어 부쩍 늘어난 스팸 트랙백들 차단하고 지우는 일도 은근히 신경쓰이는 일이다. 요즘같이 마음의 여유가 없는 생활에선 이것만으로도 벅찬 게 사실이다.<br/><br/>그러나, 사실 이보다 좀 더 근본적인 이유가 있다. 하나의 글의 단위를 140자로 제한하는 트위터의 시스템이 나와 잘 맞지 않는 것이다. 우선 말이든 글이든, 모든 걸 풀어서 설명하는 내 글투가 트위터와 맞지 않는다. 축약해서 한 줄로 설명할 수 있는 것도, 배경부터 시작해서 모든 걸 풀어내야 직성이 풀리다 보니(이건 분명 성격상의 단점이다), 짧은 토막글이 주류인 트위터와 나는 상극이 될 수밖에 없다. 아마도, 내 생각의 호흡이 다른 사람들에 비해서 많이 긴 듯 하다.<br/><br/>나 스스로의 능력도 문제다. 정말 유능한 글쟁이는 짧은 글을 잘 쓰는 사람이라고 생각한다. 짧은 글 안에 설득력 있게 자신의 생각을 다 담으면서도 오해의 여지를 남기지 않으려면, 글 솜씨와 더불어 날카로운 통찰력을 겸비해야 하기 때문이다. 그러나 아직 나는 저 수준에 다다르려면 한참 더 수련을 쌓아야 한다. 140자 안에서 촌철살인의 역량을 훌륭히 발휘할 수 있는 사람이라면 트위터가 정말로 훌륭한 무기가 되겠지만, 나에게는 아직 그런 능력은 없는 것 같다.<br/><br/>물론 위에서 든 이유를 모두 긍정하더라도 트위터를 사용할 만한 여지가 아예 없지는 않다. 지인들과의 단순한 의사 소통이나 의사 전달, 친목 도모 수준에서 메신저나 문자 메시지의 대용품 정도로 사용할 수는 있을 것이다. 그러나 이런 용도로 트위터를 사용하기에는 트위터라는 매체가 너무나 공개된 매체라는 것이 문제이다. 언제 어디서 누가 내 사적인 대화를 엿볼지 모르는 상황에서 내 할 말을 다 한다는 건 나에겐 불가능한 일이다. 내 평소 지론에도 맞지 않을 뿐더러, 상대방에 대한 예의도 아닌 것 같다.<br/><br/>부수적인 이유지만 하나 더 덧붙이자면, 예전에 내가 쓴 "내가 홈페이지를 고집하는 이유" 라는 글에서도 언급한 바 있는, 내 글을 내가 온전히 통제할 수 없다는 이유도 있다. 다만 트위터의 서비스 특성상 이것이 근본적인 이유는 되지 않을 듯 하다. <br/><br/>결론적으로, 아직 트위터라는 도구는 나에게 있어서 "내 손에 맞지 않는 도구"다. 향후 상황의 변화가 있거나, 혹은 업무상 반드시 트위터를 써야 하는 상황이 된다면 어쩔 수 없이 쓰게 되겠지만, 그것이 지금은 아니다.  ]]>
		</description>
		<category>정리된 생각</category>
		<category>트위터</category>
		<pubDate>Thu, 26 Apr 2012 18:39:06 +0900</pubDate>
	</item>
	<item>
		<title>
		<![CDATA[  자칭 "KT 상담원"씨, 그만 좀 하시지? (by 부엉이)  ]]>
		</title>
		<link>http://www.nightowl.pe.kr/oblog/article/427</link>
		<guid>http://www.nightowl.pe.kr/oblog/article/427</guid>
		<description>
			<![CDATA[  <br/>일주일이 멀다하고 전화해대는 "KT 상담원" 씨!<br/>벌써 몇달째인지 알아? 아 글쎄 최신형 스마트폰 필요 없다니까!<br/>자칭 "KT 상담원" 전화번호 다 블럭하느라, 내가 10년간 없었던 통화차단 리스트까지 만들었다!<br/><br/>왜, 슬슬 2년 약정기간 끝나가니까, 공짜폰이랍시고 기계할부금 고스란히 붙여서 하나 안겨주고,<br/>그거 핑계로 다시 3년약정 걸어서 수수료 떼먹으려고?<br/>니들 전산에 내 폰 할부금 아직 5개월치나 남아 있는 거 안 보이냐?<br/><br/>니들이 멀쩡한 안테나 철거하는 바람에 울며 겨자먹기로 휴대폰 바꾸게 해놓고선,<br/>보상은 고사하고 기계값도 출고가 다 쳐서 24개월 할부로 밀어넣은 주제에,<br/>남들도 약정만 걸면 다 해주는 스마트스폰서할인 무슨 엄청난 혜택인 것처럼 떠벌이곤,<br/>그렇게 만들어놓은 호갱 하나 기계값 약정 끝나가니까 가만 둘 수가 없는거야?<br/>지금 와서 폰 바꾸면 남은 할부금은 어쩔건데?<br/>남은 기계값 할부금 고스란히 새 폰에 이월시켜서 덤으로 붙여놓으려고?<br/><br/>KT 상담원이라면서 상담원 이름도 안 밝히고,<br/>필요 없다는 말 끝나지도 않았는데 그냥 툭 끊어버리는 건 대체 어느 나라 KT의 업무매뉴얼이냐?<br/>안 그래도 필요없는 전화 받느라 흐름 끊겨서 열 받는 판에, <br/>사람 기분을 아주 최악으로 만들어놓는 대단한 재주를 가졌구나. 앙?<br/>어느 TM 대행업체인지는 모르겠지만, 그래가지고 TM 자리 제대로 보전이나 하겠니?<br/>제대로 한번 클레임 걸어서 한 달 안에 권고사직 당하게 해줄까?<br/><br/>나 지금까지 휴대폰 바꿀때마다 평균 사용기간이 4년 3개월이거든?<br/>지금 쓰는 이 폰도, 고장나서 수리비 독박으로 나오지 않는 한, 최소한 그 만큼은 쓸거야.<br/>니들도 바가지 55요금제로 뜯어먹을만큼 뜯어먹었으니,<br/>나도 내가 받아먹을 수 있는 만큼은 철저하게 받아먹어야 되지 않겠어? 그게 페어한 거 아냐?<br/><br/>============================================================================<br/><br/>진짜 한번만 더 번호 바꿔서 전화오면 "KT 상담원입니다" 말 끝나기도 전에 위 대사를 속사포랩으로 쏴줄테다... 뚜득.  ]]>
		</description>
		<category>이런저런 이야기</category>
		<category>KT상담원</category>
		<category>좀</category>
		<category>필요없다고</category>
		<category>전화하지마</category>
		<category>최신형휴대폰</category>
		<pubDate>Tue, 17 Apr 2012 18:48:17 +0900</pubDate>
	</item>
	<item>
		<title>
		<![CDATA[  배치 파일(.BAT)을 실행 파일(.EXE)로 변환 - Bat To Exe Converter 1.6 (by 부엉이)  ]]>
		</title>
		<link>http://www.nightowl.pe.kr/oblog/article/426</link>
		<guid>http://www.nightowl.pe.kr/oblog/article/426</guid>
		<description>
			<![CDATA[  보통은 배치 파일을 굳이 실행 파일(executable)로 만들어야 할 이유는 없습니다. 배치 파일 상태로 두더라도 실행에 큰 문제가 없기 때문입니다. 그럼에도 불구하고, 이러한 작업이 필요한 경우가 있습니다.<sup>1)</sup> 이럴 때 사용할 수 있는 BAT TO EXEC 변환기는 여러 종류 있습니다. 이 글에서 소개하는 프로그램은 그런 변환기 중 하나입니다.<br/><br/>* 제작사 : F2KO (http://f2ko.de/)<br/>* 프로그램 링크 : <a href="http://f2ko.de/programs.php?lang=en&pid=b2e" target="_blank">http://f2ko.de/programs.php?lang=en&pid=b2e</a><br/>* 라이센스 : Freeware<br/><br/>프로그램을 다운로드 받으면 32비트 버전과 64비트 버전이 함께 들어 있으므로 적절한 버전을 사용하면 됩니다.<br/><br/>[첨부 이미지가 있습니다.]<br/><br/>여러 가지 유용한 옵션을 제공하고 있는데, 눈에 띄는 것은 콘솔 창을 숨길지 여부 설정, 관리자 권한이 필요한지 여부 설정, 코드 암호화 설정 등입니다. Versioninformations 탭에서는 실행 파일의 아이콘도 설정할 수 있고, 실행 파일 정보를 입력할 수도 있습니다.<br/><br/><br/><br/><br/><div style="margin: 10px; padding: 10px;">(주) 많은 종류의 악성 코드 퇴치 프로그램에서 <u>이 프로그램이 생성하는 파일(*.tmp)을 악성코드로 진단</u>할 수 있습니다. 사실 이 프로그램 뿐만 아니라, 현존하는 거의 대부분의 BAT TO EXE 변환기는 (프로그램 그 자체이건, 그 프로그램의 생성물이건) 대다수의 악성 코드 퇴치 프로그램에 의해 악성 코드로 진단되고 있습니다.<br/><br/>필자가 생각하기에는, 실제로 그 프로그램이 악성코드일 수도 있지만, 많은 경우 그 변환기를 이용하여 제작된 악성 코드가 존재하기 때문에, 악성 코드 퇴치 프로그램이 이 악성 코드를 진단하는 과정에서 동일하거나 유사한 코드를 가지고 있는 변환기 그 자체 또는 그 변환기를 이용하여 만들어진 다른 실행 파일들을 아울러 악성 코드로 진단하는 것이 아닌가 합니다.<br/><br/>실제로, 과거에는 BAT2EXEC 라는 툴을 이용하여 파괴적인 동작을 하는 배치 파일을 실행 파일(.COM 파일)로 변환한 형태의 트로이 목마 프로그램이 다수 존재하였던 시기도 있었습니다. 요즘은 그 자체가 파괴적인 행동을 하기보다는, 이들 배치 파일을 이용하여 트로이 목마 프로그램 등 악성 코드를 시스템에 설치하는 종류의 악성 코드가 이들 툴을 이용하여 제작될 것으로 생각됩니다.<br/><br/>이 프로그램도 많은 악성 코드 퇴치 프로그램이 중간 생성물(*.tmp)을 악성 코드로 진단합니다. 특히 외산 악성 코드 퇴치 프로그램인 BitDefender 엔진에서도 이를 악성코드로 진단하고 있기 때문에, 국내에서 많이 사용되고 있는 알약 등의 악성 코드 퇴치 프로그램에서도 (이들 프로그램이 BitDefender 엔진을 사용하는 관계로) 이 파일을 악성 코드로 진단할 것으로 예상됩니다. <B><u>V3의 경우, 이 중간 생성물을 Dropper/Win32.Mudrop 으로 진단</u></B>하여 필자가 직접 안철수연구소에 문의하였으며, <B><u>악성코드라고 판단하기 애매한 점이 있어 진단 제외하였다는 회신</u></B>을 받았습니다.<br/><br/>[첨부 이미지가 있습니다.]</div><br/><br/><br/><br/><div style="margin: 10px; padding: 10px;">* 하단의 링크는 이 계정에 등록된 파일입니다. 위의 제작사 홈페이지에서 직접 다운로드 받으실 것을 강력하게 권장하지만, 혹시 링크가 깨진 경우에는 아래의 복사본을 다운로드 받으셔도 됩니다.<br/><br/>[첨부 파일 링크가 있습니다.]</div><br/><br/><br/>1) 배치 파일을 실행 파일로 변환하여야 하는 이유는 여러 가지가 있을 수 있습니다. 실행 코드를 숨기고 싶다거나, 좀 더 멋있게 보이고 싶다거나 하는 이유도 있을 수 있을 것입니다. 배치 파일이 실행될 때에는 항상 콘솔 창(=도스 창)이 보이기 때문에, 이를 보이지 않기 위해서 이 방법을 쓸 수도 있겠습니다.<br/><br/>필자의 경우, 배치 파일을 관리자 권한 하에서 실행하도록 하기 위해 이 방법을 사용하였습니다. 배치 파일 상태에서는, 실행되면서 관리자 권한으로 실행될지 여부를 묻도록 처리할 수가 없고, 사용자가 직접 "관리자 권한으로 실행" 옵션을 주어 실행을 해야 합니다. 그러나 관리자 권한이 필요한 배치 파일을 탐색기 실행 확장에 등록하여 사용하게 되면 이 방법으로 관리자 권한을 줄 수가 없기 때문에, 반드시 실행 파일의 형태로 변환하여 사용할 필요가 있었습니다.  ]]>
		</description>
		<category>프로그램 소개</category>
		<category>BAT2EXE</category>
		<category>Converter</category>
		<category>배치 파일 변환</category>
		<pubDate>Sun, 08 Apr 2012 21:21:56 +0900</pubDate>
	</item>
	<item>
		<title>
		<![CDATA[  남들보다 조금 이른 투표 하고 왔습니다. (by 부엉이)  ]]>
		</title>
		<link>http://www.nightowl.pe.kr/oblog/article/425</link>
		<guid>http://www.nightowl.pe.kr/oblog/article/425</guid>
		<description>
			<![CDATA[  오늘과 내일 이틀간 진행되는 부재자투표, 첫날 아침에 일찌감치 하고 왔습니다. 왜 이 동네(관악구)는 부재자투표소가 항상 관악구청인가 싶긴 하지만, 버스 타고 서너 정거장만 움직이면 되는 가까운 거리라 그런가보다 하고 넘어갑니다.<br/><br/>첫날 아침인데도, 사람 많더군요. 지난 주에 부재자신고서 받으러 동사무소 갔다가, 부재자신고서 받으러 온 엄청난 사람떼에 질린 기억이 있었는데, 아마도 그 열기가 고스란히 투표장으로 이어진 듯합니다. 대부분 주민등록이 지방으로 되어 있는 서울대 학생들 아니면 고시생들이겠지요.<br/><br/>어느 정당 어느 후보를 지지하는가는 중요하지 않다고 생각합니다. 다만 한 명이라도 더 선거에 참여함으로써, 민의가 좀 더 정확하게 반영되는 결과가 된다면 결국에는 모두에게 좋은 결과가 되겠지요.<br/><br/><br/>덧붙임. 선거구가 단일지역선거구가 아닌 지역통합선거구라, 지지정당(비례대표후보자명부)투표는 몰라도 국회의원후보자 투표는 아무래도 정당보다는 우리지역출신을 더 보게 되는데, 안타깝게도(!) 우리 군 출신은 한 명도 출마하지 않았습니다. 결국은 국회의원후보자 투표도, 지지정당순위로 후보자 압축하고 선거공보 누가 더 잘 만들었나(...)에 가산점 부여해서 투표할 후보자를 정한 셈이라, 투표해놓고도 영 찜찜합니다. -_-;;;  ]]>
		</description>
		<category>이런저런 이야기</category>
		<category>4.11총선</category>
		<category>부재자투표</category>
		<category>사람많아</category>
		<pubDate>Thu, 05 Apr 2012 18:35:32 +0900</pubDate>
	</item>
	<item>
		<title>
		<![CDATA[  Win32 / Perl 스크립트 내에서 다른 Perl 스크립트 또는 프로그램을 실행하기 (by 부엉이)  ]]>
		</title>
		<link>http://www.nightowl.pe.kr/oblog/article/424</link>
		<guid>http://www.nightowl.pe.kr/oblog/article/424</guid>
		<description>
			<![CDATA[  <div style="margin: 10px; padding: 10px;">관련 작업 - http://www.nightowl.pe.kr/software/edhosts<br/><br/>이 문서는 <a href="http://cafe.naver.com/ArticleRead.nhn?clubid=18062050&articleid=1091" target="_blank">네이버 카페 Perl Community & Study 에 간략하게 작성했던 것</a>을 일반 목적으로 풀어 쓴 글입니다.</div><br/><br/><br/><br/><br/><B><u>1. Perl 스크립트 내에서 외부 프로그램 실행하기 - system(), exec()</u></B><br/><br/><br/><br/>코드를 작성하다 보면 하나의 스크립트 내에서 다른 스크립트나 프로그램을 실행해야 할 경우가 종종 있습니다. 물론, 실행해야 할 내용이 Perl 스크립트라면, 그것을 모듈의 형태로 만들어서 use 또는 require 를 이용하여 주 코드 내에 include 한 후에 데이터를 처리할 수 있을 것입니다. 그러나 그것이 불가능한 경우나, 아니면 실행할 대상이 Perl 스크립트가 아닌 어플리케이션 바이너리인 경우에는 이렇게 할 수가 없죠. 이럴 때는, 실행할 대상인 외부 프로그램을 실행하고, 그 결과값을 Perl 스크립트가 다시 받아오는 방법이 필요해집니다. 이럴 때에 사용할 수 있는 Perl 내부 함수가 있으니, 바로 exec() 나 system() 명령입니다.<br/><br/>이들 두 함수의 역할은 똑같습니다. 외부 명령이나 프로그램을 실행해 주죠. 그러나 그 이후의 처리가 서로 다릅니다. exec() 의 경우에는 지정한 임의의 명령을 실행한 후 그 실행이 종료되어도 영영 원래의 프로그램으로 안 돌아옵니다. 안 돌아오는 정도가 아니라 아예 exec() 를 실행한 스크립트 자체가 종료되어 버립니다. 대개의 경우에는 이런 상황을 바라면서 코딩을 하지는 않겠지요. (특히 윈도우에서는요.) 그래서, 보통 외부의 프로그램을 실행해야 할 필요성이 있는 경우 그 선택은 system() 이 되곤 합니다.<br/><br/><br/><br/><B><u>2. system() 함수</u></B><br/><br/><br/><br/>보통의 system() 함수의 사용은 아래와 같은 형태가 됩니다. 예를 들면 apprun.exe 가 무언가를 처리해서 그 결과가 성공이면 1을, 실패하면 0을 돌려준다고 할 때, 이런 형태로 코드를 작성할 수 있겠죠. <br/><br/><div style="margin: 10px; padding: 10px;">my $errvalue = system( "apprun.exe" );<br/><br/>if ( $errvalue == 1 ) {<br/>&nbsp;&nbsp;print "Process OK!\n";<br/>}<br/>else {<br/>&nbsp;&nbsp;print "Process Error!\n";<br/>}<br/><br/>undef $errvalue;</div><br/><br/>위와 같은 코드가 실행 되면, Perl 은 일단 apprun.exe 를 실행하고, 그 실행이 끝날 때까지 기다립니다. 그리고, apprun.exe 가 종료되면서 어떤 반환값을 남긴다면, 그 반환값은 $errvalue 스칼라 변수 내에 저장됩니다. 위와 같은 예시에서라면 $errvalue 의 값은 0 아니면 1이 되겠죠. 이제 그 값을 확인하여 적절한 처리 - 성공인지 실패인지 알리기 - 를 해 주면 되겠습니다. 간단하죠?<br/><br/>그러나, system() 함수는 그 실행 형태로 인하여 한 가지 문제점을 갖습니다. 바로 그 실행 대상이 종료될 때까지 계속 대기를 한다는 것이죠. 아니, 보통은 그래야 정상이고, 또 그래야 할텐데요? 네. 그런데 만약 apprun.exe 의 처리 시간이 한 몇 시간쯤 걸린다면 어떨까요? 그 몇 시간 동안 메인 스크립트는 아무 것도 못 하고 놀아야 됩니다. 만약 apprun.exe 가 실행 도중 다운이라도 되면, 메인 스크립트는 오지 않을 반환값을 기다리며 무한정 놀게 될 겁니다. 굳이 처리를 기다리지 않아도 되는 다른 작업 목록이 있다면, apprun.exe 가 자신의 작업을 처리하는 동안 미리 처리를 진행하는 것이 효율적입니다. (이런 형태의 처리를 "병렬처리"라고 한답니다만, 이 부분은 저에게 눈꼽만큼의 지식도 없으므로 넘어가겠습니다. 이런 건 전공하신 분들께 물어보세요.)<br/><br/>더 문제는, 만약 실행하려는 대상 프로그램이 무언가를 처리한 후 값을 돌려주고 종료하는 형태의 프로그램이 아니라, 그 자신도 계속 돌아가면서 무언가를 처리하는, 이를테면 서버 데몬 같은 프로그램인 경우입니다. 메인 스크립트는 자신이 실행한 프로그램이 종료되고 무언가 반환값이 돌아오기를 눈이 빠지라 기다리고 있는데, 정작 그 프로그램은 계속 돌아가면서 자신의 일을 할 뿐 자신의 실행을 종료하거나 무언가 데이터를 넘겨줄 생각이 눈꼽만큼도 없습니다. 만약 이런 실행 형태를 보이는 외부 프로그램이라면, system() 함수로는 실행이 불가능합니다. 메인 스크립트가 사실상 다운된 것과 같은 상황에 빠질 테니까요<br/><br/><br/><br/><B><u>3. 스크립트 내에서 무한 루프 형태인 외부 프로그램을 실행하기</u></B><br/><br/><br/><br/>일단 윈도우 환경에서, Perl 내부 함수만으로 이런 문제를 간단히 해결하기는 어려울 것 같다는 생각이 듭니다. 그러나, 만약 현재 윈도우용 Perl 스크립트의 GUI 구현 방법으로서 Win32::GUI 를 사용하고 있다면, 이러한 문제를 아주 간단하게 회피할 수 있습니다. 바로, Win32::GUI 에서 제공하는 ShellExecute 메서드를 사용하는 것입니다. 아래는 예제 스크립트입니다.<br/><br/><div style="margin: 10px; padding: 10px;">my $MAIN_WIN = Win32::GUI::Window->new(<br/>&nbsp;&nbsp;&nbsp; -name&nbsp;&nbsp;&nbsp;=> "MAIN_WIN",<br/>&nbsp;&nbsp;&nbsp; -title&nbsp;&nbsp;=> "윈도우 테스트",<br/>);<br/>my $STATUS_BAR = $MAIN_WIN->AddStatusBar();<br/><br/>...(중략)...<br/><br/>my $err = $MAIN_WIN->ShellExecute('open',"apprun.exe",'','',1);<br/><br/>if ( $err > 32 ) {<br/>&nbsp;&nbsp;&nbsp; $STATUS_BAR->SetText( 0," 프로그램이 시작되었습니다.");<br/>}<br/>else {<br/>&nbsp;&nbsp;&nbsp; $STATUS_BAR->SetText( 0," 프로그램을 시작하지 못했습니다($err).");<br/>}<br/><br/>undef $err;</div><br/><br/>일단, $err 는 apprun.exe 가 돌려주는 모종의 처리 결과 반환값이 아닙니다. apprun.exe 가 제대로 실행 되었는지에 대한 결과값입니다. 이런 종류의 처리에서는 실행되는 외부 프로그램에서 처리 결과값을 넘겨받을 필요가 없기 때문에, 해당 프로그램이 제대로 실행되었는지에 대한 시스템 코드만을 받을 뿐입니다. ShellExecute 가 돌려주는 값($err에 저장되는)이 32보다 크다면 프로그램이 성공적으로 실행된 것이며, 32 또는 그 이하의 값이라면 무언가 문제가 생긴 것입니다. 예를 들어, ShellExecute 돌려준 값이 2라면, apprun.exe 파일이 존재하지 않아서 실행하지 못했다는 의미가 됩니다. (32 이하의 에러 코드에 대한 구체적인 내용은 이 문서 끝에 링크되어 있는 레퍼런스 페이지를 참조하십시오.)<br/><br/>아무튼, 이렇게 실행된 apprun.exe 는 원래의 메인 스크립트와 상호작용 없이 그냥 자기 일을 할 뿐입니다. 메인 스크립트 역시, ShellExecute 가 돌려주는 반환값이 32 이상이라면 "프로그램 제대로 실행 됐음! 관심 끝!" 을 외치고 더 이상 신경 쓰지 않게 됩니다. 의도대로 됐네요.<br/><br/>참고로, 이 ShellExecute 로 열 수 있는 것은 실행 파일만이 아닙니다. 윈도우 환경에서 바로 웹 페이지를 열 수도 있고(물론 인터넷 익스플로러가 실행됩니다), 다른 Perl 스크립트를 실행할 수도 있습니다. 흔히 윈도우 도움말 파일로 많이 사용된 CHM 파일을 열 수도 있고... 쓰기 나름입니다.<br/><br/><div style="margin: 10px; padding: 10px;">* 사용례:<br/><br/>my $err = $MAIN_WIN->ShellExecute('open',"http://www.naver.com/",'','',1);<br/>my $err = $MAIN_WIN->ShellExecute('open',"help.chm","",'',1);<br/>my $err = $MAIN_WIN->ShellExecute('open',"perl.exe","script.pl",'',1);<br/><br/>먄약, 윈도우 환경에서 .pl 확장자를 perl.exe 와 연결해 놓았다면, 이렇게도 가능합니다.<br/><br/>my $err = $MAIN_WIN->ShellExecute('open',"script.pl",'','',1);</div><br/><br/><div style="margin: 10px; padding: 10px;">Win32::GUI 를 사용하지 않더라도, 윈도우 환경에서 Win32::API 를 이용하여 직접 shell32.dll 을 호출하여 ShellExecute 를 실행하는 방법으로 사용할 수도 있습니다. 이에 대한 자세한 설명은 생략합니다.<br/><br/>Win32::GUI 의 ShellExecute 에 대한 자세한 설명은 <a href="http://perl-win32-gui.sourceforge.net/cgi-bin/docs.cgi?doc=reference-methods" target="_blank">다음의 페이지를 참조</a>하시면 됩니다. 물론 영어입니다.</div>  ]]>
		</description>
		<category>Perl</category>
		<category>system()</category>
		<category>ShellExecute</category>
		<category>Win32::GUI</category>
		<category>exec()</category>
		<pubDate>Wed, 04 Apr 2012 17:45:39 +0900</pubDate>
	</item>
	<item>
		<title>
		<![CDATA[  윈도우7 / 프로그램 설치 후 Program Files 폴더에서 프로그램이나 데이터를 찾을 수 없는 경우 (by 부엉이)  ]]>
		</title>
		<link>http://www.nightowl.pe.kr/oblog/article/423</link>
		<guid>http://www.nightowl.pe.kr/oblog/article/423</guid>
		<description>
			<![CDATA[  윈도우 XP 에 익숙해진 사용자가 윈도우 7이나 윈도우 비스타로 업그레이드 후 당황하는 것 중의 하나가, 분명 프로그램을 설치했는데 C:\Program Files 아래에서 프로그램을 찾을 수 없다거나, <u>프로그램에서 사용하는 데이터 파일을 프로그램의 설치 폴더에서 찾을 수 없는 문제</u>일 것이다. 사실 앞의 문제는 대부분의 설치 관리자(인스톨러)가 관리자 권한을 받아 실행되기 때문에 거의 발생하지 않는 문제인데, 뒤의 문제 - 데이터 파일을 찾을 수 없음 - 는 의외로 자주 겪는 문제이다. <br/><br/><div style="margin: 10px; padding: 10px;">특히 윈도우 XP 또는 그 이전에 출시된 게임을 플레이하면서 이런 상황을 많이 겪는다. 대개의 게임들은 설치 폴더 또는 설치 폴더의 하위 폴더에 게임의 세이브나 설정 등을 저장하는데, 이런 게임을 플레이한 후에 설정 데이터 또는 세이브 데이터를 백업하려 하면 정작 이 파일들이 보이지 않는 것이다.</div><br/><br/>■ 발생 상황: 이 문제는 윈도우 XP 또는 그 이전에 공개된 프로그램(이후에 공개되었더라도 권한 문제를 고려하지 않은 프로그램)을 윈도우 7이나 윈도우 비스타에서 실행하면서 관리자 권한을 부여하지 않고 실행한 경우에 발생한다. <br/><br/>■ 원인: 윈도우 비스타 또는 윈도우 7은 관리자 권한 없이는 C:\Program Files 나 C:\Windows 등의 폴더에 파일을 쓰거나 수정할 수 없도록 하여 윈도우 시스템의 보안성을 향상시켰다. 따라서 프로그램이 설치된 폴더 - Program Files 폴더 이하 - 에 데이터를 기록하려면 반드시 관리자 권한을 명시적으로 부여하여 실행해야 한다. 그러나, 이전에 개발된 많은 프로그램들은 데이터 파일을 Program Files 이하의 프로그램 설치 폴더에 저장하면서도, 실행 시 명시적으로 관리자 권한을 요구하지 않는 경우가 많이 있다. <br/><br/>윈도우 시스템은 이런 경우에 발생할 수 있는 프로그램 오류 - 파일을 기록할 수 없음으로 인해 발생하는 기록 실패 오류 - 를 방지하고 하위 호환성을 유지하기 위해 관리자 권한이 없이도 기록할 수 있는 별도의 가상 Program Files 폴더를 준비하고 있다. 만약 관리자 권한을 부여받지 않은 프로그램이 자신의 설치 폴더에 데이터를 저장하려고 시도하면, 윈도우 시스템은 이 데이터를 개인 폴더 아래의 가상 Program Files 폴더에 저장하고, 프로그램이 자신이 저장했던 데이터를 읽으려 하면 원래의 Program Files 폴더 대신 가상 Program Files 폴더의 파일을 연결해 줌으로써 오류를 막는다.<br/><br/>■ 문제 해결: 따라서, 저장된 데이터 파일을 찾기 위해서는 개인 폴더 아래에 있는 가상 Program Files 폴더를 찾아가면 되며, 이 폴더는 다음의 위치에 있다.<br/><br/><div style="margin: 10px; padding: 10px;">C:\Users\사용자 이름\AppData\Local\VirtualStore\Program Files</div><br/><br/>위 폴더를 찾아간 후 해당 프로그램의 폴더로 들어가면 파일들을 찾을 수 있다. 아래 링크한 파일은 위 가상 Program Files 폴더에 바로 찾아갈 수 있도록 세팅한 명령행 배치 파일이다. 다운로드 받아서 압축을 풀고 실행하면 위 Program Files 폴더 위치로 윈도우 탐색기가 열린다.<br/><br/>[첨부 파일 링크가 있습니다.]<br/><br/>■ 참고 및 유의 사항: 위 가상 Program Files 폴더는 관리자 권한 없이 실행했을 때에만 참조된다는 점을 유의해야 한다. 만약 문제의 프로그램을 관리자 권한을 주어서 실행했을 경우, 윈도우 시스템은 가상 Program Files 폴더를 찾지 않고, 정상적인 C:\Program Files 폴더 이하에서만 파일을 찾는다. 따라서, 이 경우 관리자 권한 없이 실행했을 때에는 정상적으로 읽을 수 있던 데이터 파일들을 찾지 못하는 문제가 발생한다. (예를 들면, 관리자 권한 없이 실행하고 세이브해 왔던 게임을 관리자 권한을 주어 실행하면 기존에 저장된 세이브 파일이나 설정 등을 하나도 읽을 수 없게 된다.)<br/><br/>이런 모습은 정확히 반대로도 나타나는데, 관리자 권한을 준 상태에서 저장한 데이터 파일은 관리자 권한 없이 실행했을 때에는 참조되지 않는다. 그 결과, 관리자 권한 하에서 실행했을 때 저장한 (원래의 Program Files 폴더 안에 저장되어 있는) 데이터 파일은 관리자 권한 없이 실행했을 때는 읽을 수 없고, 가상 Program Files 폴더에 저장되어 있는 데이터 파일이 읽혀지게 된다. 유일한 예외는, 가상 Program Files 폴더 아래에 실행한 프로그램의 폴더가 생성되어 있지 않은 경우이다. 이 경우에는 관리자 권한이 없더라도, 일단 원래의 Program Files 이하 폴더에 데이터가 있는지 확인하고 있으면 그 데이터를 사용하게 된다. 그러나 이 경우 데이터를 다시 저장하려 한다면, 윈도우는 원래의 데이터를 겹쳐쓰지 않고, 가상 Program Files 이하에 해당 프로그램의 폴더를 생성하고 그 곳에 데이터를 저장하게 될 것이다. 즉, 원래 관리자 권한 하에서 저장되었던 파일은 보존된 채로, 가상 Program Files 폴더 아래에 동일한 (또는 수정된) 데이터가 저장된다. 그 이후에는 위와 같은 상황 - 관리자 권한이 있으면 Program Files 이하, 관리자 권한이 없으면 가상 Program Files 이하 - 이 재현된다.<br/><br/>■ 첨언: 위와 같은 처리는 보안성을 강화하면서도 하위 호환성의 유지를 위하여 어쩔 수 없이 채택한 방식이지만, 이는 의도치 않은 데이터의 분리를 야기하고, 따라서 사용자가 데이터를 백업할 때에 엉뚱한 데이터를 백업하게 되는 실수를 유발할 수 있다. 따라서, 윈도우 비스타 또는 그 이후의 운영체제에서 실행되는 것을 고려하여 프로그램을 제작할 때에는, (비록 오류가 발생하지는 않는다 하더라도) 데이터를 Program Files 이하에 바로 저장하지 않도록 코딩해야 한다. 그 위치는 내 문서 폴더 이하가 될 수도 있고, Local Settings 폴더(윈도우 비스타 이후라면 AppData 폴더) 이하가 될 수도 있다. 어느 쪽이든, 데이터 저장 위치의 분리가 반드시 이루어져야 하며, 단순히 데이터의 저장만을 위해 불필요한 관리자 권한을 요구하도록 프로그램을 설계하는 것은 피해야 한다.  ]]>
		</description>
		<category>컴퓨터 사용 경험</category>
		<category>윈도우7</category>
		<category>Program Files</category>
		<category>VirtualStore</category>
		<category>관리자 권한</category>
		<pubDate>Sat, 31 Mar 2012 14:46:54 +0900</pubDate>
	</item>
	<item>
		<title>
		<![CDATA[  Perl / Win32 / PAR::Packer - PAR::Packer 1.013 설치 중 windres: can't open file pp.manifest 오류가 발생하는 경우 (by 부엉이)  ]]>
		</title>
		<link>http://www.nightowl.pe.kr/oblog/article/422</link>
		<guid>http://www.nightowl.pe.kr/oblog/article/422</guid>
		<description>
			<![CDATA[  윈도우에서 PAR::Packer 1.013 버전을 CPAN을 통해서, 또는 패키지를 다운로드 받아 설치할 때에, dmake 과정에서 다음과 같은 오류가 등장하는 경우가 있습니다. ActivePerl 5.10.1 에서는 발생하지 않았는데, StrawberryPerl 5.10.1 에서는 아래와 같은 오류가 발생하면서 PAR::Packer 의 dmake 작업이 중단됩니다.<br/><br/>[첨부 이미지가 있습니다.]<br/><br/><div style="margin: 10px; padding: 10px;">windres: can't open file 'pp.manifest': No such file or directory. <br/>dmake:&nbsp;&nbsp;Error code 129, while making 'ppresource.coff'<br/>dmake:&nbsp;&nbsp;Error code 255, while making 'subdirs'</div><br/><br/>한참 원인을 찾다가, PAR::Packer 1.013 버전에서 myldr/makefile 이 조금 변경되었는데 이 부분이 제대로 처리되지 않아 발생하는 문제라는 것을 알게 되었습니다.<br/><br/>만약 dmake 과정에서 위의 오류 메시지가 나온다면, 다음과 같이 합니다.<br/><br/><div style="margin: 10px; padding: 10px;">1) myldr/winres 폴더를 열어 보시면 pp.ico, pp.manifest, pp.rc 이렇게 세 개의 파일이 있을 것입니다.<br/>2) 이들 세 파일을 myldr 폴더로 <B><u>복사</u></B>합니다.<br/>3) 다시 dmake 를 시행합니다.</div><br/><br/>이 방법을 사용하려면, 역시 CPAN으로부터 직접 파일을 다운로드 받아서 설치 작업을 해야 할 것입니다. <br/><br/>* 파일 다운로드 링크 : http://search.cpan.org/CPAN/authors/id/R/RS/RSCHUPP/PAR-Packer-1.013.tar.gz<br/><br/>혹시 모르시는 분을 위해, 패키지를 다운로드 받아서 적당히 압축을 푸신 후, 아래의 명령을 순서대로 실행하면 됩니다. CPAN 모듈 설치 방법은 특별한 경우가 아니라면 거의 아래의 방법을 따릅니다.<br/><br/><div style="margin: 10px; padding: 10px;">perl makefile.pl <br/>dmake<br/>dmake test<br/>dmake install</div><br/><br/>* 아래 첨부 파일은 제가 따로 작성해 둔 PAR::Packer 1.013 버전의 Perl(Strawberry Perl) 5.10 버전대 PPM 파일입니다. ppm 을 이용하여 설치할 수 있도록 해 줍니다만, 문제는 <B><u>로컬에서 직접 설치를 하면 의존성 체크를 안 하고</u></B> 우격다짐으로 깔아버리는 통에 (안 그래도 의존성 많은 모듈인데) 자칫 의존성 있는 모듈이 없어서 오류가 발생하는 사태가 벌어질 수 있습니다. <B><u>일단 CPAN으로 시도해 보시고, 안 되면 아래 PPM 패키지로 시도</u></B>해 보시기 바랍니다.<br/><br/>[첨부 파일 링크가 있습니다.]  ]]>
		</description>
		<category>Perl</category>
		<category>windres</category>
		<category>PAR::Packer</category>
		<category>PAR::Packer 1.013</category>
		<category>pp.manifest</category>
		<category>ppresource.coff</category>
		<pubDate>Tue, 27 Mar 2012 19:24:34 +0900</pubDate>
	</item>
	<item>
		<title>
		<![CDATA[  Win32 / SQLite : SQLite DB 경로에 한글이 들어가 있는 경우 (by 부엉이)  ]]>
		</title>
		<link>http://www.nightowl.pe.kr/oblog/article/421</link>
		<guid>http://www.nightowl.pe.kr/oblog/article/421</guid>
		<description>
			<![CDATA[  <br/><div style="margin: 10px; padding: 10px;">이 글은 <a href="http://cafe.naver.com/perlstudy/981" target="_blank">같은 제목</a>으로, 네이버 카페 "Perl Community & Study" 카페에 먼저 등록(2012/01/09)되었던 글을 일부 수정보완한 것입니다.</div><br/><br/><br/>다른 분들은 어떻게 하시는지 모르겠습니다만, 저는 Win32 환경에서 돌아가는 스크립트를 짤 때는 스크립트 파일의 인코딩을 ANSI (CP949) 로 설정하고 코드를 짭니다. (물론, 제 홈페이지에서 돌아가는 CGI 를 짤 때는 UTF-8 로 짭니다.) 코드 내에서 한글로 된 파일명/폴더명을 처리하는 경우, 코드가 UTF-8 로 되어 있으면..<br/><br/><div style="margin: 10px; padding: 10px;">(1) Win32::Unicode 모듈을 사용해서 파일/폴더를 다루거나<br/>(2) 출력단계에서 인코딩을 CP949로 변경해줘야..</div><br/><br/>하기 때문에, 은근히 번거롭기 때문입니다. 그리고, 이런 귀차니즘은 결국 사단을 만들고 맙니다.<br/><br/>DB를 모를 때는 거의 대부분의 자료를 파일 시스템을 사용해서 관리했습니다. 그러나 SQL 문법을 알게 되니, 이제는 일일이 데이터 파일을 다루는 것이 은근히 귀찮아졌습니다. 그래서 데이터 파일이 필요한 코드를 짜는데 DBMS를 사용하기 시작했습니다. SQLite 라는 가벼운 단일 파일 형태의 DBMS가 있었기 때문에 가능한 일이죠. <br/><br/>확실히 DBMS 를 사용하면 덩치가 좀 커지긴 해도, 여러가지 복잡한 자료처리 코드를 만들 필요가 없어져서 코딩 자체는 정말 편해집니다. 다만, SQLite 의 내부 인코딩은 모두 UTF-8 을 사용하는 것이 원칙이기 때문에, 데이터베이스에 한글 등 텍스트 자료를 저장할 때에는 인코딩을 UTF-8 로 변환한 후에 넘겨줘야만 합니다. (내부 인코딩의 UTF-8이건, UTF-8 인코딩의 바이트스트림이건 상관 없습니다. 그냥 UTF-8이기만 하면 됩니다.) 윈도우에서는 한글 처리를 위해 보통 CP949 인코딩을 사용하기 때문에 보통은 얻어온 값의 인코딩은 CP949일 것이어서, 저장 전에 저장할 내용을 CP949 → UTF-8 로 일괄적으로 인코딩을 변환하여 사용하면 됩니다. 조금 더 안전하게 사용하려면 Encode::Guess 모듈을 사용하여 인코딩을 확인한 후 decode하고, 이미 내부 UTF-8 플래그가 붙어 있는 데이터를 다시 decode 함으로써 발생할 수 있는 Encode 모듈의 crash 를 막기 위해서는&nbsp;&nbsp;Encode 모듈의 is_utf8 을 사용하여 인코딩 변환 전 검사를 거치게 됩니다.<br/><br/>그런데, 예상치 못한 곳에서 문제가 생겼습니다. 스크립트의 위치와 데이터베이스 파일의 위치가 서로 달랐기 때문에 데이터베이스를 열기 위해서 데이터베이스까지의 경로를 함께 넘겨주어야 했는데, 이 SQLite DB 파일이 존재하는 폴더까지의 경로에 한글이 끼어 있으면 데이터베이스 접근에 실패하는 문제가 발생했습니다.<br/><br/><div style="margin: 10px; padding: 10px;">우연히 지인의 집에서 제가 만든 프로그램을 테스트하는데, 이게 돌아가지를 않더군요. PAR::Packer 와 관련해서 발생하던 한글 사용자 이름 문제도 해결된 버전이었기 때문에 오류가 날 이유가 없는데 말입니다. 에러 메시지가 나오도록 하여 콘솔상에서 체크해 보니, 첫 실행에서 DBI 가 DB 파일을 만들지 못하고 오류를 내면서 죽는 것이었습니다. 게다가 해당 경로에 미리 만들어 둔 DB 파일을 넣어줘도 읽지를 못하더군요.</div><br/><br/>처음엔 한글 문제인 줄 모르고, 이게 왜 이러지? 하고 한참 고민했습니다. 그러다가, 파일까지의 경로 중간에 한글이 있다는 것을 발견한 후, 혹시 이것도 한글 인코딩 문제인가 싶어서 경로의 인코딩을 UTF-8 로 변경해서 DBI에 던져주니 데이터베이스 파일을 아주 잘 찾아가더군요. <br/><br/>결국, 데이터베이스까지의 경로값(파일명으로 쓰이는 데이터베이스 이름 값도 포함하여)의 인코딩이 CP949 였기 때문에 발생한 문제였습니다. 영문자 및 숫자 뿐이라면 CP949와 UTF-8의 코드값이 같기 때문에 문제가 되지 않지만, 한글이 포함되어 있다면 두 코드값이 달라지기 때문에 전혀 엉뚱한 경로를 찾아가게 되는 거죠.<br/><br/>따라서, 데이터베이스를 열고 닫기 위해 DBI 모듈에 경로를 포함한 데이터베이스 파일명을 보낼 때에는, 여기에 한글이 포함되어 있을 가능성을 항상 염두에 두고, 넘어가는 값의 인코딩이 UTF-8인지를 꼭 확인해야 합니다. 특히 스크립트 파일의 인코딩이 UTF-8이 아니라면 거의 100% 인코딩을 명시적으로 해 주어야 할 것입니다.<br/><br/><div style="margin: 10px; padding: 10px;">예를 들어,<br/><br/>use DBI;<br/>my $dbname = "데이터.db";<br/>my $dbh = DBI-&gt;connect( "dbi:SQLite:dbname=$dbname", "", "" );<br/><br/>이 코드를 UTF-8 인코딩의 스크립트(use utf8 프라그마가 붙어있는지 무관하게)에서 실행하면 정상적으로 "데이터.db" 파일이 만들어지지만, CP949 인코딩의 스크립트에서 실행하면 파일명이 깨진 상태로 db 파일이 만들어집니다. 만약 CP949 인코딩의 스크립트에서 이 코드를 제대로 실행하기 위해서는,<br/><br/>use DBI;<br/>use Encode;<br/>my $dbname = decode( "cp949", "데이터.db" );<br/>my $dbh = DBI-&gt;connect( "dbi:SQLite:dbname=$dbname", "", "" );<br/><br/>위와 같이 데이터 파일명/경로를 UTF-8 로 바꾸어 주어야만 합니다. (내부 인코딩의 UTF-8이라도 상관없으므로 위와 같이 decode 만 해도 됩니다. 물론 Perl 의 유니코드 FAQ 에 보면, "내부 인코딩이 UTF-8이라는 것을 자신의 이익으로 이용하지 말라[Don't use the fact that Perl's internal format is UTF-8 to your advantage.]"고 합니다만...)</div><br/><br/>윈도우 환경에서 UTF-8 인코딩이 문제를 일으키는 경우가 많아서 이를 회피하려다가, 되레 UTF-8이 아니어서 문제를 일으키는 경우에 맞닥뜨린 셈입니다.<br/><br/><br/><br/><br/><B><u>한 줄 요약 : SQLite 를 사용하는 (범용) 스크립트를 짤 때는 데이터베이스 경로에 한글이 들어가지 않도록 하거나, 들어가야 한다면(들어갈 가능성이 있다면) 경로를 UTF-8로 인코딩해서 DBI 에 던져주세요.</u></B>  ]]>
		</description>
		<category>Perl</category>
		<category>Unicode</category>
		<category>DBD::SQLite</category>
		<category>CP949</category>
		<category>Win32</category>
		<category>한글 경로</category>
		<category>SQLite</category>
		<pubDate>Mon, 26 Mar 2012 00:30:14 +0900</pubDate>
	</item>
	<item>
		<title>
		<![CDATA[  Perl / Win32::GUI : 현재 NumLock / CapsLock 키가 토글 상태인지를 확인하기 (by 부엉이)  ]]>
		</title>
		<link>http://www.nightowl.pe.kr/oblog/article/420</link>
		<guid>http://www.nightowl.pe.kr/oblog/article/420</guid>
		<description>
			<![CDATA[  <div style="margin: 10px; padding: 10px;">이 글은 "<a href="http://cafe.naver.com/perlstudy/990" target="_blank">Win32::GUI 1.06 의 GetKeyState 의 오동작 사례</a>" 라는 제목으로, 네이버 카페 "Perl Community & Study" 카페에 먼저 등록(2012/01/19)되었던 글을 일부 수정한 것입니다.<br/><br/>이 글에서는 NUMLOCK 키를 기준으로 설명합니다만 역시 토글 모드가 존재하는 CAPSLOCK 이나 SCROLLLOCK 키 역시 모두 동일한 방법으로 사용이 가능합니다.</div><br/><br/><br/><br/><br/><B><u>NUMLOCK 키가 토글 상태인지 확인하기</u></B><br/><br/><br/><br/>시작은 키보드의 숫자 키패드를 이용하는 가상 마우스를 만들어보려던 것이었습니다. 숫자 키패드의 키들을 눌러서 마우스 포인터를 움직이려 했던 것이지요. 윈도우에서 키 눌림을 모니터링할 때, 숫자 키패드의 키가 눌린 것으로 인식되는 경우는 NumLock키가 토글(불 들어옴) 상태에서 숫자 키패드의 키를 누를 때입니다. 따라서 공연한 번거로움을 막기 위해서는, (1) 프로그램을 실행한 후 가상 마우스의 기능이 켜질 때에 현재의 NumLock키의 상태를 확인하여 만약 켜져 있지 않다면 이를 켜 주고, (2) 가상 마우스 기능이 꺼질 때에는 반대로 NumLock이 켜져 있다면 꺼 주는 절차가 필요합니다. 그런 고로,<br/><br/>"Perl 에서 현재 NumLock 이 토글 상태인지 해제 상태인지를 확인하라."<br/><br/>가 오늘의 문제 되겠습니다.<br/><br/>처음 생각하기에는 간단한 문제 같았는데, 생각외로 답이 안 나옵니다. 구글신께 문의해봐도 미묘하게 답이 나오질 않더군요. 단순히 키가 눌림(Pressed) 상태인지를 판단하는 걸로는 안 됩니다. 토글 상태인지 확인하는 건 또 다른 문제가 됩니다.<br/><br/>한참을 삽질하다가 드디어 방법을 찾았습니다. 등잔 밑이 어둡다고, 의외로 사용하던 Win32::GUI 모듈 안에 해결책이 있었지요<br/><br/><div style="margin: 10px; padding: 10px;">use Win32::GUI qw( VK_NUMLOCK );<br/>Win32::GUI::GetKeyState( VK_NUMLOCK );</div><br/><br/>GetKeyState 를 이용하면 되었습니다. Win32::GUI 레퍼런스에 의하면, GetKeyState 는 스칼라 문맥에서는 해당 키가 눌림 상태인지 아닌지를 판단한다고 했습니다. 그러나 이것이 배열 문맥이 되면, KeyPressed 이외에 해당 키가 토글 상태인지 해제 상태인지를 (함께)넘겨준다고 합니다. <br/><br/><div style="margin: 10px; padding: 10px;">(<B>In scalar context</B> returns a value specifying whether the <u>key is up(0) or down(1)</u>. <B>In list context</B>, returns a 2 element list with <u>the first element as in scalar context</u> and <u>the second member</u> specifying whether <u>the key is toggled(1) or not(0)</u> - <B>this is only meaningful</B> for keys that have a toggled state: <B><u>Caps Lock, Num Lock etc.</u></B>)</div><br/><br/>따라서, 이에 따라 간단히 기능을 구현해 보면 다음과 같은 코드 조각이 됩니다.<br/><br/><div style="margin: 10px; padding: 10px;">use Win32::GUI qw( VK_NUMLOCK );<br/><br/>my @NumLockState = Win32::GUI::GetKeyState( VK_NUMLOCK );<br/><br/>if ( $NumLockState[1] == 1 ) {<br/>&nbsp;&nbsp;&nbsp; print "NumLock 이 켜져 있습니다!";<br/>}<br/>else {<br/>&nbsp;&nbsp;&nbsp; print "NumLock 이 꺼져 있습니다!";<br/>}</div><br/><br/>print 문 위치에는 그 대신 적절한 처리문을 넣을 수 있습니다. NumLock 이 꺼져 있는 경우 이를 켜는(여러 가지 방법이 있습니다) 코드를 넣으면 되겠네요.<br/><br/><br/><br/><br/><B><u>Strawberry Perl 5.10.1.5 버전에서 발생하는 오류</u></B><br/><br/><br/><br/>...이대로만 끝났으면 참 좋았을 텐데, 의외의 복병을 만납니다.<br/><br/>아시는 분은 아시겠지만, 저는 일반 환경에서 ActivePerl 5.10.1 을 사용합니다. 코드를 짜고 테스트할 때 이쪽에서 작업을 하지요. 그러나, 최근 PAR::Packer 를 버리고 <a href="http://aero2blog.blogspot.com/2011/12/perl.html" target="_blank">aero 님의 패키징 방법론</a>(아이디어가 번뜩이는 멋진 방법이었습니다)을 받아들인 결과, 공개를 위해 패키징을 할 때에는 Strawberry Perl 5.10.1 을 사용하고 있습니다. (AcrivePerl 에서는 이 방법을 사용할 수 없기 때문입니다.)<br/><br/>문제는 ActivePerl 에서 문제 없이 돌아간 코드를 패키지 빌드를 위해 Strawberry Perl 에서 테스트를 하는 도중에 발견되었습니다. 가상 마우스 모드가 해제되었음에도 NumLock 이 정상적으로 꺼지지 않는 현상이 발견되었습니다. 코드상에는 분명, 가상 마우스 모드가 해제될 때, NumLock 이 켜져 있는지를 확인하여 만약 켜져 있다면 이를 끄도록 코딩이 되어 있었습니다. <br/><br/>이상하다 싶어서 오류를 확인해 보니, Strawberry Perl 에서 $NumLockState[1] 의 값을 계속적으로 undef 값으로 반환하고 있더군요. 즉, Win32::GUI 레퍼런스 페이지의 설명과는 다르게, 배열 문맥임에도 불구하고 GetKeyState 메서드의 반환값이 스칼라 문맥에서의 경우와 동일하게 나타나고 있었습니다. 두 번째 반환값이 계속 누락되고 있는 것이죠.<br/><br/>[첨부 이미지가 있습니다.]<br/><br/><B><u>결론적으로, Strawberry Perl 의 5.10.1 버전에서는 GetKeyState 메서드를 이용하여 NumLock 이 켜져 있는지 확인이 불가능</u></B>합니다. Win32::GUI 자체적인 문제가 아니라 Strawberry Perl 의 문제라고 단정할 수 있는 이유는, (1) 정상적으로 동작하는 ActivePerl 쪽에 설치되어 있던 Win32::GUI 를 가져다가 Strawberry Perl 에 적용해 보아도 이 기능이 동작하지 않았으며, (2) 결정적으로, 패키징이 완료된 상태에서 패키지 내에 포함된 Strawberry Perl의 Perl510.dll 파일을 ActivePerl 의 그것으로 교체해 본 결과 기능이 정상적으로 동작하였기 때문입니다. 이 기능에 대해 기술한 Win32::GUI 매뉴얼이 잘못된 것이 아니라면, Strawberry Perl 쪽에서 잘못된 결과값을 반환하고 있는 것이 거의 확실한 것이죠.<br/><br/><br/><div style="margin: 10px; padding: 10px;">덧붙임. 일단 Strawberry Perl 의 다른 버전에서는 어떤 결과가 나오는지는 직접 확인해보지 않았습니다. 다만 Strawberry Perl 5.12.3 버전에서는 정상적으로 코드가 동작한다는 aero 님의 피드백이 있었기 때문에, 아마도 Strawberry Perl 5.10.1 버전대(혹은 5.10.1.5 버전)에서 발견되는 특유한 문제라고 짐작하고 있습니다.</div><br/><br/><div style="margin: 10px; padding: 10px;">내부 링크. 이 글에서 설명한 방법이 적용된 키보드 가상 마우스 프로그램은 다음의 경로에 공개되어 있습니다.<br/><br/>* 키보드 가상 마우스 : <a href="http://www.nightowl.pe.kr/software/kvmouse">http://www.nightowl.pe.kr/software/kvmouse</a></div>  ]]>
		</description>
		<category>Perl</category>
		<category>NumLock Toggle</category>
		<category>Win32::GUI</category>
		<category>GetKeyState</category>
		<pubDate>Sun, 25 Mar 2012 00:47:33 +0900</pubDate>
	</item>
	<item>
		<title>
		<![CDATA[  유료결제한 스마트폰 앱이 마켓에서 사라진다면? (by 부엉이)  ]]>
		</title>
		<link>http://www.nightowl.pe.kr/oblog/article/419</link>
		<guid>http://www.nightowl.pe.kr/oblog/article/419</guid>
		<description>
			<![CDATA[  잠재적으로 이런 문제가 있을 수도 있다는 생각은 하고 있었지만, 정말로 이런 문제가 발생할 줄은 몰랐습니다. 과거 구매한 적이 있던 앱이 안드로이드 마켓(현재는 Google Play 로 바뀌었지만, 이 글에서는 계속 안드로이드 마켓 또는 마켓이라고 칭하겠습니다.)에서 갑자기 사라진 것입니다.<br/><br/>제 넥서스원을 초기화한 후 사용하던 앱을 다시 설치하던 과정이었습니다. 저는 일일이 마켓에서 찾아서 설치하는 과정이 귀찮아서, 마켓 웹 페이지에 접속한 후 설치한 적이 있는 앱 목록을 이용하여 원격 설치를 합니다. 그런데 설치 도중 같은 페이지에서 아래 그림과 같이 깨진 항목들이 몇 개 발견되었습니다. 그리고 그 중 한 항목은 유료로 구매한 적이 있는 앱이었습니다. A-MOTION 에서 만들었다고 하는, TAZO WALK 라고 하는 걷기 운동 앱입니다. 실제로 마켓에서 검색해 본 결과 해당 앱은 마켓에서 사라진 상태입니다.<br/><br/>[첨부 이미지가 있습니다.]<br/><br/>마켓에서 앱이 사라지는 경우는 업체에서 앱을 내리는 경우도 있겠고, 악성코드 또는 규정 위반 등의 사유로 안드로이드 마켓측에서 앱을 삭제하는 경우도 있을 것입니다. 어떤 경우이든, 이런 상황에서는 현재로서는 이 앱이 마켓 내에 재등록되지 않는 이상 스마트폰에 이 앱을 다시 설치하는 것은 불가능하게 되었습니다. <B><u>무료로 받은 앱도 아니고, 돈을 지불하고 구매한 유료 앱</u></B>인데도 말입니다. (만약 악성코드여서 앱이 삭제되었다면 마켓측에서 원격으로 사용자의 스마트폰에 설치된 해당 앱을 삭제해 버리기 때문에, 이런 경우는 아닐 것으로 생각됩니다.)<br/><br/>만약 이것이 PC에서 사용하는 소프트웨어라고 한다면, 이런 상황이 발생하더라도 별도로 보관하고 있던 원본 미디어를 통하여 재설치를 하면 됩니다. 그러나 스마트폰 환경에서는 별도의 설치 패키지가 제공되지 않기 때문에, 제작사 또는 마켓측에서 해당 앱의 다운로드를 차단해버리면 더 이상 설치 방법이 없습니다. 사용자로서는 자신에게 사용권이 있는 앱이지만, 대책 없이 앱의 사용권을 행사할 수 없는 상황에 놓이기 됩니다.<br/><br/>그렇다면 PC에서와 마찬가지로, 이런 경우를 당하지 않으려면 .APK 파일을 별도로 백업해 놓아야 됩니다. 그러나 .APK 파일의 백업은 제작사가 이를 별도로 제공하지 않는다면(제작사가 미치지 않고서야 이럴 리는 없습니다) 이래저래 작업이 번거롭습니다. 별도의 파일 브라우저를 이용하여 내부 저장 공간의 /app 디렉토리에 있는 .APK 파일을 복사해야 하기 때문입니다. 그러나 대부분의 사용자는 이런 짓을 하지 않을 것입니다. 아마 .APK 파일이 저장되는 위치조차 알지 못하는 사용자가 상당수일 것이고, 실제로 이 곳에 접근이 가능하다는 것을 아는 사용자도 많지 않을 테니까요. 게다가, 자신이 구매한 앱이라면 언제라도 마켓을 통해 다시 다운로드받을 수 있다는 생각을 하는 것이 보통이라서, 일반적인 사용자라면 이런 조치를 할 것이라고 기대하기도 어렵습니다.<br/><br/><div style="margin: 10px; padding: 10px;">제 휴대폰은 순정롬이 아닌 커스텀 롬(CM7)이 올라가 있는 넥서스원이어서, 슈퍼유저 권한이 주어지지 않더라도 /app 폴더에 파일 브라우저(Root Explorer)를 이용하여 접근이 가능했고, 해당 파일을 읽어서(Copy) SD 카드로 복사(Paste)도 가능했습니다. 그러나, 루팅되지 않은 일반적인 순정 롬 안드로이드 OS에서 이것이 가능한지는 확인할 수가 없습니다. 게다가 가능하더라도 별도의 파일 브라우저 앱이 필요하겠죠. 뭐, 가능만 하다면 파일 브라우저 앱은 무료도 많이 있으니까 별 문제는 아니겠지만요. 만약 루팅되지 않은 순정 안드로이드 롬 하에서 이러한 조치가 불가능하다면 그야말로 해결책은 없습니다. 사용자들에게 루팅을 강요할 수는 없는 것이기 때문이죠.</div><br/><br/>그럼에도 불구하고, 사용자의 입장에서 이런 황당한 상황을 방지하기 위해서는 이 방법이 최선입니다. 패키지 파일의 유출 및 불법 복제 사태가 가시화될 수 있기 때문에 앱 제작사측에서는 경기를 일으키겠지만, 사용자가 앱 제작사 입장까지 고려해가면서 자신의 잠재적인 피해 가능성을 감수해야 할 이유는 없습니다. 더구나 정당하게 비용을 지불하고 사용권을 구입한 앱이기 때문에 더욱 그러합니다. 이런 상황을 제작사나 구글측이 원하지 않는다면, 일단 구매한 앱에 대해서는 판매 중단 등의 상황이 발생하더라도 기존의 사용자는 계속 설치 파일을 다운로드 받을 수 있도록 조치를 해야 할 겁니다.<br/><br/>어찌 되었거나, 지금 제 상황에서는 어둠의 경로를 통하여 이 앱의 설치 패키지를 구하거나, 제작사에 클레임을 걸어서 적절한 조치를 약속받거나 둘 중 하나의 방법을 쓸 수밖에 없겠습니다.<br/><br/><br/><div style="margin: 10px; padding: 10px;">첨언. 글을 쓰면서 좀 더 알아보니, 안드로이드 마켓에서만 내려갔고 T스토어나 올레마켓에는 여전히 등록되어 있군요. 그러나 이들 마켓 앱이 설치되어 있지 않은 저로서는 여기에 접근할 방법이 없으며, 있다 하더라도 구매 정보가 공유되지 않는 이상 재구매를 하여야 합니다. 가격의 많고 적음이 문제가 아니죠. 이건 대체 무슨 황당한 상황인지 모르겠습니다.</div>  ]]>
		</description>
		<category>이런저런 이야기</category>
		<category>A-MOTION</category>
		<category>안드로이드마켓</category>
		<category>TAZO WALK</category>
		<category>시장철수</category>
		<pubDate>Fri, 23 Mar 2012 00:31:21 +0900</pubDate>
	</item>
	<item>
		<title>
		<![CDATA[  구글 웹마스터 도구: 페이지(디렉토리) 삭제 후 삭제를 취소하여도 검색에 반영이 안 될 수 있습니다. (by 부엉이)  ]]>
		</title>
		<link>http://www.nightowl.pe.kr/oblog/article/418</link>
		<guid>http://www.nightowl.pe.kr/oblog/article/418</guid>
		<description>
			<![CDATA[  도메인 변경을 통해 홈페이지의 각종 링크 주소를 변경한 지 한 달 남짓 지났습니다. 각종 외부 링크 등의 페이지 연결을 지원함으로써 예기치 못한 페이지 연결 불가 등의 불편은 거의 막았다고 생각합니다만, RSS 등으로 게시물을 받아보고 계시던 분들께 본의 아니게 불편을 끼쳐드렸습니다. 그럼에도 불구하고, 약 5일 전에 또 한번, 블로그 파트의 주소 변경이 있었습니다. 이번에는 전체 페이지를 301 리다이렉트 연결을 함으로써, 구 주소로도 페이지 접속이 가능하도록 조치를 하였습니다.<br/><br/>이번 게시물은 5일 전의 페이지 주소 변경의 이유와, 그에 관련된 구글 웹마스터 도구의 문제점(추정)에 대해 경고하기 위한 게시물입니다. 결론부터 정리하면, 구글 웹마스터 도구에서 페이지(디렉토리) 삭제가 처리되면, 해당 페이지를 색인에 재포함하더라도 그 페이지가 검색에 노출이 안 되는 경우가 있을 수 있습니다. 저야 검색이 되거나 말거나 사실 큰 상관이 없습니다만, 검색 노출이 꼭 필요한 전업 블로거의 경우에는 자칫 상당히 골치아픈 상황을 맞을 수 있기 때문에 상당한 주의를 요합니다.<br/><br/><br/><br/><B><u>1. 사건의 진행 경과 (요약)</u></B><br/><br/><br/><br/>[첨부 이미지가 있습니다.]<br/><br/>사건의 진행 경과(요약)는 다음과 같습니다.<br/><br/>1. 특정 웹 페이지 운영 및 블로그와의 장기적 통합을 위해 새 도메인(nightowl.pe.kr)을 구입 (2011/04/25)<br/><br/>2. 운영 테스트를 위해 www.dormouse.pe.kr/blogtool (구 운영주소) 의 블로그 CGI 및 데이터를 복사하여 운영 시험 중, 관리 실수로 www.nightowl.pe.kr/blog 주소 이하의 페이지들이 구글 검색 서비스에 다량 노출됨. 실제 운영되지 않는 주소의 검색 노출을 막기 위해 www.nightowl.pe.kr/blog 이하의 문서에 대해 구글 웹마스터 도구를 통해 디렉토리 삭제 요청. 삭제 이루어짐. (상단 이미지의 ①)<br/><br/>3. 이후 계속적인 시험 과정에서 180일이 경과하여 삭제 요청 기간이 만료. 외부 링크는 없었으나 구글 내부 주소 데이터에 의해 검색 엔진의 재방문이 이루어져 해당 페이지들이 검색 결과에 다시 노출됨. 해당 페이지들에 대한 2차 디렉토리 삭제 요청을 접수하였고 이에 따라 삭제가 이루어짐. (상단 이미지의 ②)<br/><br/>4. 2012년 2월 초, 기존에 디렉토리 삭제가 이루어졌던 www.nightowl.pe.kr/blog 주소 이하로 구 블로그 데이터가 이전됨. 구 페이지 주소는 모두 신 페이지 주소로 301 리다이렉트가 이루어졌고, 이에 따라 1주 정도 이후에는 www.dormouse.pe.kr 이하 데이터는 구글 검색 결과에서 모두 사라졌음. 그러나 301 리다이렉트에 의해 새로 노출되어야 할 www.nightowl.pe.kr/blog 이하의 데이터는 검색 엔진에서 전혀 노출되지 않음. <B><u>웹마스터 도구 상에 제출된 사이트맵 데이터상으로는 거의 모든 페이지가 색인된 것으로 결과가 출력</u></B>. <br/><br/>5. 구글 웹마스터 도구를 통해 사이트 재검토 요청(2012년 2월 29일)을 하였으나, 웹마스터 가이드라인 위배로 제재된 도메인이 아니라는 통보(2012년 3월 3일)를 받음.<br/><br/>6. 구글 웹마스터 도구에 사이트 재검토 요청을 한 시점에서, 과거 www.nightowl.pe.kr/blog 이하에 디렉토리 삭제 요청이 만료되지 않았음을 뒤늦게 발견하고 해당 디렉토리 삭제 요청을 취소함(2012년 2월 29일). 요청이 취소된 이후 2주일 정도 기다려 보았으나 페이지가 전혀 검색되지 않음.<br/><br/>7. 한 번 디렉토리 삭제되었던 페이지가 검색 결과에 노출되지 않는 것 같다는 생각이 들어서, 검색에 노출되지 않는 /blog 이하 하위 페이지를 /oblog 이하 하위 페이지로 일괄 이전(2012년 3월 14일 밤)함. 그 결과 2012년 3월 15-16일 이후 페이지가 구글 검색 결과에 나타나기 시작. 현재 많은 페이지가 검색에 노출되고 있음.<br/><br/>[첨부 이미지가 있습니다.]<br/><br/><br/><br/><B><u>2. 상황분석 및 원인의 추정</u></B><br/><br/><br/><br/>이러한 일련의 사태를 정리해 보면, <B><u>구글 웹마스터 도구에서 페이지를 삭제(아마도 디렉토리 삭제의 경우)한 경우, 이를 중간에 취소(재포함)하여도 검색 결과에 제대로 반영되지 않을 수 있다</u></B>는 것을 유추할 수 있습니다.<br/><br/><div style="margin: 10px; padding: 10px;">단, 구글의 정책상 한 번 삭제된 페이지에 대해서는 최소 180일간 페이지를 다시 노출하지 않습니다. 따라서 <B><u>삭제일로부터 180일이 지나기 전에 페이지를 다시 노출하기 위해서는 삭제한 페이지에 대해서 재포함 버튼을 눌러 삭제 요청을 취소해야</u></B> 합니다. 따라서 저의 경우에도, 삭제 요청을 취소하기 전인 2012년 2월 말까지 검색 결과가 노출되지 않았던 부분은 정상입니다. 문제가 되는 것은 2012년 2월 29일 이후의 경우입니다.</div><br/><br/>기타 다른 잠재적인 원인들은 다음과 같은 이유로서 제외할 수 있습니다.<br/><br/>1. 검색은 구글의 사이트 검색(site:도메인 주소) 기능을 이용하여 검색한 것으로써, 검색어의 잘못된 선택으로 인하여 페이지가 출력되지 않았던 것도 아닙니다. (www가 붙은 버전과 붙지 않은 버전 모두 확인하였습니다.)<br/><br/>2. 웹 페이지의 접속 로그상으로 확인했을 때 구글봇은 하루에도 수회~수십회 이상 매일 방문하고 있었던 것으로 확인되고 있으므로, 검색 로봇이 방문하지 않아 색인이 갱신되지 않았기 때문도 아니라고 보입니다. 하위 주소 변경 후 이틀만에 페이지가 나타나고 있는 것으로 보아 2주 정도 기다린 기간이 짧았던 것은 아니라고 생각합니다.<br/><br/>[첨부 이미지가 있습니다.]<br/><br/>3. 특징적인 것은, (삭제 요청이 취소되기 전인) 2월 중순부터 이미 구글 웹마스터 도구상으로는 제출된 사이트맵에 대해 대부분의 페이지가 "색인됨" 상태로 출력되고 있었다는 것입니다. (이것 때문에, 과거 삭제 요청한 기간이 만료되지 않았다는 사실을 상기하지 못했습니다.) 그렇다면 삭제된 페이지라도 페이지가 검색되고 배제표준 등으로 배제되지 않는다면 일단 색인하고, 다만 검색에만 노출하지 않는다는 이야기가 됩니다. 만약 이 결과가 구글 시스템상의 문제라면, 이 부분에 시스템적인 오류가 있기 때문일 가능성이 제일 크다고 생각합니다. (지난 삭제 요청이 만료되는 2012년 5월까지 기다려보았다면 이 문제도 검증이 가능했겠지만, 이 부분은 검증이 불가능합니다.) <br/><br/><br/>물론 위의 사실은 몇 가지 팩트를 통하여 추정한 것으로, 이 상황이 일반적인 상황이 아닐 수도 있습니다. 다만, 사이트 리뉴얼 등의 이유로 구글 웹마스터 도구를 이용해 페이지를 삭제한 후에, 새로운 페이지가 구글 검색 결과에 노출되지 않는 등의 문제를 겪고 있는 운영자께서는 이러한 가능성도 검증을 해 보시기 바랍니다.  ]]>
		</description>
		<category>컴퓨터 사용 경험</category>
		<category>Google</category>
		<category>검색 결과</category>
		<category>구글</category>
		<category>인덱스</category>
		<category>웹마스터 도구</category>
		<category>검색</category>
		<pubDate>Tue, 20 Mar 2012 00:38:57 +0900</pubDate>
	</item>
	<item>
		<title>
		<![CDATA[  블로그 파트의 하위 주소 변경이 있었습니다. (by 부엉이)  ]]>
		</title>
		<link>http://www.nightowl.pe.kr/oblog/article/417</link>
		<guid>http://www.nightowl.pe.kr/oblog/article/417</guid>
		<description>
			<![CDATA[  <br/>도메인이 변경된 지 한 달도 채 못 된 시기인데, 또 한 번 블로그의 주소가 약간 변경되었습니다. 도메인은 그대로이고, 기존의 주소로도 들어오실 수 있으므로, 방문자분들께서는 굳이 방문 주소를 변경하실 필요는 없습니다.<br/><br/>이번 주소 변경은 구글 검색 엔진과 이 홈페이지가 빚어내는 묘한 갈등을 해결하기 위한 작업입니다. 물론 이번 주소 변경으로 해결될지 여부는 저도 모릅니다. 다만 구글측에서 납득할 만한 답을 주지 않고 있는데다, 개인적으로 짚이는 부분이 한 군데 있기 때문에 한번 시도해보는 것입니다. 해결이 이루어지면 자세한 이야기를 이 곳에 작성할 예정이지만, 이래도 해결이 안 된다면 그냥 구글을 포기하고 살아야 할지도 모르겠습니다.<br/><br/>혹시라도 방문자 분들께 불편을 드렸다면 사과드립니다.  ]]>
		</description>
		<category>공지사항</category>
		<category>죄송합니다</category>
		<category>또 주소변경</category>
		<pubDate>Wed, 14 Mar 2012 23:49:54 +0900</pubDate>
	</item>
	<item>
		<title>
		<![CDATA[  제품 사용기: COMMS KB3110 USB 실리콘 롤 키보드 (by 부엉이)  ]]>
		</title>
		<link>http://www.nightowl.pe.kr/oblog/article/416</link>
		<guid>http://www.nightowl.pe.kr/oblog/article/416</guid>
		<description>
			<![CDATA[  아는 사람은 알겠지만, 필자 역시 상당히 귀찮은 걸 싫어하는 성격이다. 뭔가에 필이 꽂히면 결벽증적인 집착을 보여주지만, 기본적으로는 그렇다. 이런 귀찮은 종류의 글을 쓰는 것도 그다지 내킬 턱이 없다. 10년 넘게 웹에 글을 쓰면서 홈페이지 시절과 블로그 시절 합쳐서 400개 남짓 정도 되는 글이라면 뭐 말 다 하지 않았을까. (물론 다른 곳에 쓴 글과 날아간 글 등을 합치면 한 100개 정도 더 늘어나겠지만, 그래 봐야 대세에 영향이 있을까 싶다.)<br/><br/>이런 성격상, 필자가 이런 번거로운 짓을 시작했다는 것은 필시 이 물건이 양 극단 - 매우 좋거나, 혹은 매우 나쁘거나 - 의 물건일 것이라는 추측을 해 볼 수 있을 텐데, 안타깝게도, 이 물건은 정확히 후자에 해당한다. 물론 이유는 있다.<br/><br/><br/><br/><br/><B><u>1. 제품에 대한 간략한 설명</u></B><br/><br/><br/><br/>* 다나와 블로그 링크 : <a href="http://blog.danawa.com/prod/?prod_c=1497305" target="_blank">http://blog.danawa.com/prod/?prod_c=1497305</a><br/><br/>당연하게도, 이 물건은 기본적으로 키보드이다. 다만 조금 특수한 종류의 키보드인데, 일반적으로 실리콘 키보드, 또는 롤 키보드라고 불리는 키보드로서, 아래 사진처럼 사용할 때는 일반 키보드처럼 사용하고, 보관할 때는 그대로 둘둘 말아서 가방 등에 넣어가지고 다닐 수 있다. 접이식 키보드 못지 않은 휴대성이 강점이다. <br/><br/>[첨부 이미지가 있습니다.]<br/><br/><br/><br/><br/><B><u>2. 이 제품의 특징</u></B><br/><br/><br/><br/>뛰어난 휴대성 이외에, 이 제품의 또 하나의 강점은 소음이 적다는 것이다. 사실 이것이 필자가 이 제품을 산 이유인데, 소음의 발생을 절대적으로 방지해야 하는 독서실 등에서 간단한 타이핑을 하는 데 매우 유용하다. 독서실 칸막이 옆 사람에게도 들리지 않을 정도의 조용한 타이핑이 가능해진다. 재질이 실리콘이라, 오래 사용해서 더러워지면 그대로 물 세척을 할 수 있다는 것도 장점이라면 장점이겠다. 물론 아직까지 세척해야 할 일은 없었지만, 필자처럼 커피를 잘 쏟는(...) 사람이라면 이것도 분명한 장점이 될지도 모른다.<br/><br/>내구성 부분은 일단 한달 반 정도 사용해 본 상태라 뭐라 단언할 수는 없다. 그러나 날카로운 물체로 인해 키보드가 찢기거나(실리콘 재질이라는 것을 잊으면 안 된다), 접힌 상태로 심하게 압력을 주는 등의 무리한 사용을 하지 않는다면 크게 걱정할 필요는 없을 것 같다.<br/><br/>사람에 따라서 민감할 수가 있는 것이 키감의 문제인데, 분명 키감은 그다지 좋지 않다. 빠른 속도의 타이핑도 어렵다. 일반적인 키보드와 달리 고무(실리콘)재질이어서 키가 눌리는 각도가 좀 많이 어긋나면 키가 눌리지 않기 때문이다. 그렇다고 엄청나게 느려진다는 것은 아니고, 장문 기준 350타 정도까지는 커버가 가능한 수준이다. (물론 다소의 오타가 있을 수는 있다.) 약간은 강하게 타이핑을 해 주는 것이 오타율을 줄이는 방법이지만, 그 반대급부로 장시간 타이핑을 하면 손가락 끝이 상당히 피로해질 수 있음은 염두에 두어야 한다. 그러나 이것은 실리콘 키보드가 갖는 일반적인 한계일 것이기에, 이것을 흠잡는 것은 조금 무리가 있다고 생각한다.<br/><br/><br/><br/><br/><B><u>3. 이 제품의 가장 큰 문제점</u></B><br/><br/><br/> <br/>사실 여기까지라면 필자가 이 제품을 잡고 버럭버럭할 이유가 없었을 것이다. 그러나, (필자가 생각하기에) 이 제품은 키보드로서 상당히 큰 문제점이 하나 있다. 만약 이 제품의 다른 모델이 나온다면 필히 해결되어야 할 문제점이라고 생각한다.<br/><br/>[첨부 이미지가 있습니다.]<br/><br/>위 사진은 이 키보드의 좌하단의 사진인데, 일반적인 키보드와 키 배열이 다르다. 보통은 키보드의 가장 아랫줄에 있어야 할 ALT 키가 아래에서 두 번째 줄에 배치되어 있다. 표준적인 키보드 배열과 조금씩 키 배열이 달라지는 것은 최근의 다기능 키보드에 있어서는 어쩔 수 없는 일이기도 할 것이기에 이해해주고 넘어갈 수도 있다. 그러나 그것도 그 기능을 크게 해치지 않는 선에서나 허용될 일이다. (일반적인 멀티미디어 키보드에서 Home, End, Insert, Delete 등의 키가 한 곳에 모여 있는 것이 대개 이런 경우이겠다. 대개 단독으로 쓰이고, 타이핑시에 그 위치가 크게 문제가 되지 않기 때문이다.) 그런데, 이 경우는 다르다. 타이핑에 심각한 방해요소가 된다.<br/><br/>구체적으로, ALT 키가 저 위치에 있음으로 인해, 대개는 A 밑에 있어야 할 Z 키가 ALT 키에 밀려 일반적인 키 배열보다 1/2~2/3 정도 더 오른쪽으로 이동되어 있다. 그 결과 일반적인 타이핑시에도 표준키보드의 버릇대로 ㅋ을 입력하려다 ALT 키가 눌리는 일이 다반사다. 윈도우에서는 ALT 키를 상단 메뉴 호출에 사용하는 경우가 많기 때문에, 갑자기 포커스가 메뉴 바로 이동하여 타이핑의 맥이 끊기곤 하는 것이다.<br/><br/>게다가, 문서 편집시에 정말 많이 하게 되는, CTRL-Z,X,C 입력에도 치명적인 문제가 생긴다. CTRL-X (오려내기) 를 눌러야 하는 상황에서 CTRL-Z (되돌리기) 를 누르게 되는 경우가 자주 발생하는데, 그것이 얼마나 짜증나는 일인지는 당해본 사람이 아니면 이해하기 어려울지도 모르겠다. 특히 CTRL-Z (되돌리기) 기능의 특성상, 이것이 예측하지 못한 파장을 불러오는 경우가 가끔 발생한다. 휴지통에 던졌던 파일이 원위치로 돌아와 있다거나, 한 1만 줄 정도 되는 텍스트 파일을 편집하던 와중에 키가 잘못 눌려 대체 어디의 수정 부분이 원위치된 것인지 한참 찾아야 한다거나... 사소한 키 배열의 변경이지만, 그것이 가져오는 여파는 심각하다.<br/><br/>이런 문제를 방지하기 위해서는 Z 키가 안쪽으로 밀려있다는 것을 의식하면서 새끼손가락을 안쪽으로 밀어넣거나(Z/ㅋ을 입력하는 경우), CTRL 키를 누른 상태에서 반 키 정도 더 오른쪽을 클릭한다는 생각으로 X 키를 눌러야 하는데, 그게 말처럼 쉬운 일이 아니다. 아차 하는 사이에 이미 오타는 나 있고, 그때마다 짜증은 늘어만 간다.&nbsp;&nbsp;<br/><br/><br/><br/><br/><B><u>4. 남은 이야기</u></B><br/><br/><br/><br/>백보 양보해서, 만약 이것이 보통 크기의 키보드가 아닌 미니 키보드라면, 이런 상궤를 벗어나는 키 위치 변경이 그나마 정당성을 가질지도 모르겠다. 한정된 좁은 공간 안에 키를 모두 밀어넣으려다 보면 아무래도 커스터마이징의 폭이 커질 수밖에 없기 때문이다. 그러나 이 키보드는 사이즈는 보통의 키보드와 거의 같은 크기이다. 공간 때문에 키 배열을 조정해야 할 이유가 없다는 것이다. 아랫줄의 키 사이즈 - 하다못해 스페이스 키 - 를 조금씩만 조정하면, 하다못해 좌우 양쪽에 쓸데없이 두 개나 있는 윈도우 키를 하나 없애기만 해도 충분히 ALT 키 하나 배치할 공간은 나온다. 이래저래 납득하기 어려운 디자인이다. 만약 이 모델이 차후 개선되어 출시된다면 이 부분은 반드시 개선되어야 한다고 생각한다.<br/><br/>이런 종류의 제품이 언제부터 출시되었는지는 잘 모르지만, 롤 키보드라는 발상 자체는 매우 좋은 발상이라고 생각한다. 분명 틈새수요가 있을 제품이고, 제대로만 만든다면 팔릴 물건이다. 그러나 분명 이 제품은 "키보드"이고, 그렇다면 사람들의 일반적인 키보드 사용 습관도 고려하여 제품을 설계해야만 한다. 이런 부분에서부터 실기를 하고서는 좋은 평가를 받기 어렵다고 본다.  ]]>
		</description>
		<category>컴퓨터 사용 경험</category>
		<category>롤 키보드</category>
		<category>실리콘 키보드</category>
		<category>KB3110</category>
		<pubDate>Thu, 01 Mar 2012 19:23:35 +0900</pubDate>
	</item>
	<item>
		<title>
		<![CDATA[  다 끝났으니 이제 편하게 쓸 수 있겠다 - 병역비리의혹 촌극 단상 (by 부엉이)  ]]>
		</title>
		<link>http://www.nightowl.pe.kr/oblog/article/415</link>
		<guid>http://www.nightowl.pe.kr/oblog/article/415</guid>
		<description>
			<![CDATA[  <div style="margin: 10px; padding: 10px;">이 글에는 어떠한 라이센스도 적용되지 않습니다. 즉, 다른 곳에 전재할 수 없고, 인용할 수도 없습니다. 또한 이 글은 순수하게 필자의 생각을 적은 글로써, 어떠한 사실도 보증해 주지 않습니다.</div><br/><br/><br/>거의 한달 내내 시끄러웠던 병역비리 논란의 대미는 - 예상대로 - 허무개그였다.<br/><br/>1.<br/><br/>병무청에서 신체검사를 통해 신체등급을 판정하는 것은, 일차적으로는 국민에게 국방의 의무의 한 형태로서 병역의 의무를 지우기 위한 것이다. 그러나 그 못지 않게 중요한 임무는, 만약 어떤 자가 현역으로 복무하기에 부적합한 신체조건을 가진 자라면, 병무청이 가지는 공신력으로써 이를 확인하여 주는 임무이다. 이렇게 함으로써, 신체조건이 현역으로 복무하기에 부적합한 자라도 그가 감당할 수 있는 다른 대체복무의 기회를 제공할 수 있고, 이를 통해 모든 국민에게 예외 없이 국방의 의무를 부여할 수 있게 된다. 또한 일반 국민의 입장에서도, 스스로 불특정 다수에게 자신의 치부를 공개하여 자신의 신체적 흠결을 입증해야 하는 수치스러운 절차 없이, 공신력 있는 국가기관을 통해서 이를 인정받고 스스로 떳떳해질 수 있다. <br/><br/>따라서, 정상적인 신체검사의 절차를 거쳐서 보충역 내지 병역면제의 처분을 받았다면, 그 사실에 대해 의문이 제기된다 하더라도 사실 병역의무자 본인에게 어떠한 행동을 하여야 할 의무는 없다. 만약 그러한 행동을 병역의무자 본인에게 요구한다면 이것은 스스로 마녀가 아님을 증명하라는 식의 전근대적 마녀사냥과 다를 바가 없다. 그렇다면, 신체검사제도의 다른 한 축을 굳건히 지키기 위해서라도, 이런 의문이 제기되었을 때에 적극적으로 나서야 하는 것은 병무청이다. 신체검사 당시의 적법한 기준에 의해 병역의무자에게 적법한 처분을 하였음을 해명해 줌으로써 보충역 또는 면제처분을 받은 의무자를 사회의 마녀사냥으로부터 보호해 주어야 하는 것이 바로 병무청의 임무이자 존재 이유라는 것이다.<br/><br/>물론 현재의 법제도상 여러 가지 한계가 있는 것이 사실이기는 하다. 개인의 신체 및 건강에 대한 정보는 매우 민감한 정보로써 아무리 정부기관이라 하더라도 본인의 동의 없이 이를 공개하거나 확인해 줄 수는 없다. 그러나 과연 한 달 넘게 이어진 병역비리 의혹에 있어서 정말로 병무청이 할 수 있는 일이 이렇게 아무것도 없었을까. 이런 상황을 보고 있노라면, 보충역 판정을 받고 사회복지시설에서 2년 15일간 공익근무요원으로써 일한 내 입장에서는, (뭐 그럴 일이 있기야 하겠냐마는) 혹시라도 나에 대한 병역처분의 적법성에 대한 의문이 제기되었을 때 그에 대해 병무청이 나를 마녀사냥으로부터 충분히 보호해 줄 수 있을지에 대해 도무지 믿음을 가질 수가 없게 되는 것이다.<br/><br/><br/>2.<br/><br/>반대로 생각하면, 병역의무자 자신에게 있어서도, 보충역 또는 면제처분을 받은 사실은 살아가는 데 있어서 숨기고 싶은 치부이거나 컴플렉스가 된다. 웬만한 흠결로는 보충역 처분조차 받기 어려운 것이 현실이기 때문에, 속된 말로 "얼마나 병신이면 국가가 병신이라고 공인까지 해주냐"는 편견을 받기 십상인 것이다. 따라서 누구라도, 자신이 어떤 사유로 현역으로써 병역의 의무를 수행하지 못했는지 밝히고 싶어하지 않는다. 아니, 자신이 현역이 아니(었다)라는 사실조차 밝히고 싶어하지 않는다.<br/><br/>그런 의미에서, 자신을 둘러싼 논란에 대해서 한 달 넘게 공개신체검사에 응하지 않은 박주신 씨의 행동이 나는 오히려 이해할 수 있는 행동이(었)다. 본인이 어떻게 생각하고 있었는지는 알 수 없지만, 남들과 다른 특이한 체형이나 체질은 일반적으로는 숨기고 싶은 치부의 하나다. 그런 알리고 싶지 않은 사실을, 떠밀려서 전국민을 상대로 공표해야 할 의무가 그에게는 없었다. 단 하나, 그의 가족이 사회고위층 인사라는 사실 하나 때문에, 결국은 공개신검에 "떠밀려서" 응해야 했을 것이다. 그리고, 그로 인해 그는 동물원의 원숭이가 되어버렸다. 지금 한 번 포털사이트나 언론사 사이트의 덧글을 한번 살펴보라. 그의 그런 특이한 신체조건을 한갓 웃음거리나 놀림거리로 만들어버리는 덧글들이 얼마나 많은지. 아마도 공개 신검 자체로 인한 1차적인 상처 못지 않게, 이러한 2차적인 폭력으로 인한 상처 역시 상당할 것이다. 아마 그 상처들은 상당히 오래 갈 것이다. 평생 갈지도 모른다. 그러나 누구도 그런 상처에 대해 책임을 지려 하지 않을 것이고. 내가 박주신 씨에게 연민의 감정을 느낀다면, 잠재적으로 같은 상황에 처할 가능성이 있는 사람으로서의 연대의식 때문일 것이다.<br/><br/><br/>3.<br/><br/>국회의원 강용석. 사퇴하겠다고는 했지만 현재의 국회의 난맥상 때문에 아마도 한동안은 사퇴하고 싶어도 할 수 없을 것이니, 오늘 이 순간 이후로도 한동안 국회의원의 직을 유지할 것이다. 따라서 이렇게 칭하여도 크게 문제는 없을 것이다.<br/><br/>그와 같은 대학에 같은 학과를 나왔으니 어쨌거나 선배임에는 분명한 사실이고, 똑같이 공부했는데 나는 몇 년째 헛발질만 하다가 결국 떠나온 사법시험을 학부 재학중에 합격한, 대단히 명석한 사람임은 분명한 것 같다. 국회의원으로서 치명적인, 언어에 의한 성추행 및 그에 대한 특정 집단에 대한 모욕의 혐의를 받고 지금 정치생명에 위기를 맞고 있는 것도 분명히 사실이다.<br/><br/>결론부터 말하자면, 나는 이 사람을 좋아하지 않는다. 법률가로서도, 정치인으로서도 실격이라고 본다. 사석에서 있었던 언어적 성추행 때문이 아니다. 물론 그것이 그에 대한 점수를 깎는 요소가 될 수는 있지만 그것은 결정적인 요소가 아니었다. 결정적인 계기는 - 비록 한 판의 짜고 친 고스톱이기는 했으되 - 개그맨 최효종에 대한 고소 사건과, 그 이후의 그의 언행 때문이다.<br/><br/>사법시험에 합격한 변호사로서, 그가 2심 판결의 결과에 내심 억울했을 수 있다. 정상적인 법과대학 2학년을 마친 법학도라면 모를 수가 없는, 소위 "집단(집합명칭)에 대해서 명예에 관한 죄가 성립하기 위한 기준"으로서 대한민국 대법원이 판시한 바 있는 (필자가 알기로 유일무이한) 사건인 일명 "3.19 동지회 사건[대법원 2000.10.10. 선고, 99도5407 판결]" 에 비추어 본다면, 그의 그런 발언만으로는 여자 아나운서에 대한 명예훼손죄 내지 모욕죄가 성립하기 어려울 수 있다. 아마 그는 1심에서부터 내내 이 판례를 들어 자신의 무죄를 주장했을 것이다. 그러나 재판부는 이를 받아들이지 않았다. 형사사건의, 그것도 자신의 정치생명이 걸린 형사사건의 피고인으로써 이런 재판결과가 억울할 것이다. 다만 이는 사실인정의 문제가 아니라 법률적용의 문제이므로 그는 적법하게 대법원에 상고하여 다툴 기회가 남아 있다. 이것이 정상적인 절차다. 대법원이 전원합의체의 결정으로 위 판결을 뒤집을 것이 아니라면, 결국에는 대법원에서 그가 이길 가능성은 충분히 있다고 생각한다. 다른 재판부에서 있었던 민사소송의 결과도 그의 승소가능성을 점칠 수 있게 한다. <br/><br/>그러나, 이후에 그가 보여준 행동은, 내 기준으로 볼 때 과연 그가 법을 공부한 자가 맞는가 의심스러웠다. 자신에 대한 판결이 부당하다는 점을 보여주기 위해서 코미디 프로그램에서 정치인의 행태를 풍자한 한 개그맨 - 최효종 - 을 동일한 죄목으로 고소했다. 최효종의 행위가 죄가 되지 않는다는 사실을 변호사이기에 너무나도 잘 알았을 그다. (이론적인 논의이지만, 설사 강용석에게 집단명예훼손죄가 성립한다고 보더라도 최효종에게는 죄가 성립하지 않을 수 있는 법논리도 구성이 가능하다.) 그럼에도 불구하고 그는 단지 자신의 재판 결과에 영향을 미치기 위한 의도로 최효종을 고소하는 일단의 "쇼"를 연출했다. 이로써 그는 자신의 전공인 법을 한갓 도구로 격하시켰고, 신성한 법정을 모욕하고 희화화했으며, 또한 대한민국 법조계를 웃음거리로 만들어버렸다. 비록 법률가의 꿈은 접었지만, 그래도 법률을 공부했다는 자부심을 갖고 있는 나로써, 그의 이름 앞에는 더 이상 "법률가"라는 타이틀을 붙여줄 수 없는 것이다.<br/><br/>게다가, 그는 정치인으로서도 내가 최악이라고 생각하는 정치인의 전형을 답습하고 있었다. 도대체 그에게 어떤 정치철학이 있는지 모를, 단지 그는 직업정치인으로써 단지 국회의원을 계속하는 데에만 관심이 있는 것처럼 보였다. 아예 대놓고 그렇게 떠들고 다닌다. 정치인으로서의 치열함이 단지 직업으로써 정치를 계속 하는 데에 있다고 생각하는 그의 정치관은, 과연 그가 국회의원으로, 혹은 후에 공직자로서 얼마나 사회에 긍정적인 기여를 할 수 있을지 의심할 수밖에 없게 만들었다. 혹자는 결국 정치인으로서 살아남는 것이 정치판의 알파요 오메가라고, 내가 그리는 정치란 것은 그야말로 지구상에 존재하지 않는 신기루일 뿐이라고 할지도 모르지만(당장 내 주변에, 그렇게 말할 것 같은 사람이 두 사람이나 있다), 그럼에도 불구하고 그는 내 "주관적인 판단"에는 정치인으로서도 실격이라고 할 수밖에 없는 것이다. 재판 이후로 그야말로 여기저기 "들쑤시고" 다니면서 마치 현대판 홍길동인 것처럼 이런저런 문제제기와 고소고발을 해왔지만, 나에게는 그런 그의 활동 역시 "진정성 없는, 단지 정치판에서 살아남기 위한 몸부림"으로밖에 보이지 않는다. (그것이 뭐가 잘못이냐고 묻지 말아주기 바란다. 개인의 가치관의 문제이므로 모두의 생각이 다를 수 있다.) 내가 그의 지역구에 살지 않기 때문에 내가 그의 당락에 영향을 끼칠 일은 (그가 서울특별시장이나 대통령에 출마하지 않는 한) 아마도 없을 것이다. 그러나 그것이 나의 그에 대한 평가를 바꿀 이유는 되지 못한다.<br/><br/>아마도, (의사들마저 공개적으로 망신당하게 만든) 소위 "특이체형"의 문제가 있기 때문에, 그에게 병역처분에 문제가 있었다고 생각할 만한 합리적인 근거가 있었다고 본다면 그는 이번에도 이 부분에 대한 형사적인 책임은 - 그 자신이 법률전문가이기에 - 피해갈 수 있으리라 본다. MRI의 입수경로에 대한 문제가 논의되고 있지만, 그것은 의료법을 위반하여 그에게 의무기록을 건네준 의료인을 처벌해야 하는 것이지 그것을 건네받아 행사한 그에게 형사적 책임을 물을 사안이 아니어서(이 부분은 혹 다른 법률에 처벌규정이 있을 수도 있으므로 정확하지는 않다), 역시 이 부분에 대한 형사적 책임도 자유롭다고 본다. 결국 어쩌면, 그는 정치인이자 자연인 강용석으로서 이 사건에서 아무것도 잃은 게 없을 수도 있다. 그러나, 과연 그걸로 된 것일까? 만사가 그렇게 잘 풀리기만 할 것인가. 나는 정말 모르겠다.<br/><br/><br/>4.<br/><br/>모든 것을 제쳐두고, 모 포털의 덧글에서 심심찮게 내 이름이 언급되는 것이 영 마뜩찮다. 그가 실제로 존재하는지 의심스러운 모 당 알바인지, 아니면 투철한 정치적인 신념을 가진 자연인일 뿐인지는 모를 일이지만, 그다지 흔치 않은 이름을 갖고 있으면서 그렇게 사회의 대다수 구성원들이 동의할 수 없는 내용을 자기 이름을 걸고 써나르고 다니는 것을 보면 마음이 편치 않다. (진짜로, 혹시 내 주민등록번호가 도용되고 있는 게 아닌가 싶어서 내 주민등록번호로 만들어진 아이디가 또 있는지 검색까지 해 봤다는 뒷이야기가 있다.) 아, 진짜 사회적으로 지탄받는 자들과 동명이인인 분들의 비애를 내가 느끼게 될 줄이야. 혹, 이름이 같다는 것을 이유로 하여 명예감정의 훼손을 이유로 하는 위자료청구라도 하고 싶은 심정이다. (물론 받아들여지지는 않겠지만.)  ]]>
		</description>
		<category>정리된 생각</category>
		<category>박주신</category>
		<category>병무청의 역할</category>
		<category>강용석</category>
		<category>병역비리의혹</category>
		<pubDate>Wed, 22 Feb 2012 20:37:51 +0900</pubDate>
	</item>
	<item>
		<title>
		<![CDATA[  2012-02-18. 묘한 느낌. (by 부엉이)  ]]>
		</title>
		<link>http://www.nightowl.pe.kr/oblog/article/414</link>
		<guid>http://www.nightowl.pe.kr/oblog/article/414</guid>
		<description>
			<![CDATA[  1.<br/><br/>2012년 2월 18일. 오늘은 제54회 사법시험 제1차시험이 있었다.<br/><br/>작년까지만 해도, 이 시간이면 가답안 언제 뜨려나 하면서 가채점을 준비하고 있을 시간이었을 것이다. 그러나 올해 시험에 응시하지 않은 나는 그럴 필요가 없게 됐다.<br/><br/>10년 가까이 (진정/부진정 다 포함하여) 사법시험 준비생으로 살아왔던지라, 이런 모습이 참 어색하고 낯설 것 같았는데, 막상 남들 다 시험보러 가는 와중에 TEPS 책 들고 오후에 있을 TEPS 시험 준비를 하는 내 모습이 그다지 어색하지가 않다. 정확히 말하면 별 느낌이 없다. 마음 한구석에선 "이래선 안 되지"라는 소리가 들리고 있는데, 정작 몸은 안 따라주는 이 상황을 뭐라고 생각해야 할까.<br/><br/><br/>2.<br/><br/>2년 1개월만의 TEPS 시험. 2년 전에 비해 더 어려워졌다는 이야기를 듣고 가서인지, L/C부터 뭔가 잘 들리지 않는다. 나이를 먹은 탓인지, L/C PART 1이 묘하게 따라가기 벅찬 느낌이다. 그러나 느낌상으로는, 시험이 과거보다 어려워진 것 같지는 않고, 오랫동안 영어에 손을 놓은 탓으로 감각이 퇴화된 탓이라고 보는 것이 더 옳을 것 같다.<br/><br/>어차피 점수가 없는 것보단 있는 게 더 나을 것 같아서 친 시험이라, 점수가 잘 나오고 못 나오고에는 크게 연연하지 않지만, 이왕이면 2년 전 시험 성적만큼은 나와줬으면 하는 것이 솔직한 심정이다.<br/><br/><br/>3.<br/><br/>여러 모로, 이제 좀 주변이 보이기 시작했다. 아직 출구는 보이지 않지만.  ]]>
		</description>
		<category>이런저런 이야기</category>
		<pubDate>Sat, 18 Feb 2012 22:48:34 +0900</pubDate>
	</item>
	<item>
		<title>
		<![CDATA[  Perl : ActivePerl 과  Strawberry Perl 을 함께 사용하기 (by 부엉이)  ]]>
		</title>
		<link>http://www.nightowl.pe.kr/oblog/article/413</link>
		<guid>http://www.nightowl.pe.kr/oblog/article/413</guid>
		<description>
			<![CDATA[  <div style="margin: 10px; padding: 10px;">이 게시물은 국내 Perl 커뮤니티의 @aer0 (http://twitter.com/aer0) 님께서 알려주신 기본적인 설정 방법을 소개하고, 이를 좀 더 편리하게 사용할 수 있도록 조금 더 살을 붙여서 작성한 것입니다.</div><br/><br/><br/><br/><B><u>1. 윈도우용 Perl 의 양대산맥 - ActivePerl 과 Strawberry Perl</u></B><br/><br/><br/><br/>윈도우에서 사용되는 Perl 바이너리 중 대표적인 것을 두 개만 말한다면 단연 이 두 개의 바이너리를 이야기할 수 있다. ActivePerl 과 Strawberry Perl 이 그것이다. 물론 이 두 개의 Perl 바이너리 말고도 몇 가지의 윈도우용 Perl 바이너리가 더 있지만, 필자 역시 이 두 바이너리 이외의 바이너리는 사용해 본 적이 없다. (아, 예전에 Indigo Perl 을 잠깐 써본 적이 있긴 하다. 문자 그대로 "써 보기만" 했기 때문에 이에 대해서는 전혀 할 말이 없다.)<br/><br/>* ActivePerl : http://www.activestate.com/activeperl<br/>* Strawberry Perl : http://www.strawberryperl.com/<br/><br/>두 바이너리 모두 기본적으로 Perl 이라는 점에 있어서 동일하다. 약간의 미묘한 차이가 있지만 같은 버전에서는 기본적인 사용법이나 호환성에 큰 차이가 없다. ActivePerl 은 MS VC++ 을 이용하여 컴파일한 Perl 바이너리이며, Strawberry Perl은 오픈소스 컴파일러인 gcc 를 이용하여 컴파일한 Perl 바이너리라는 점이 가장 큰 차이점이라고 한다.<br/><br/><div style="margin: 10px; padding: 10px;">국내 Perl 커뮤니티의 분들 사이에서는 ActivePerl 보다는 Strawberry Perl에 대한 선호도가 더 높은 것 같다. 정확한 이유는 필자도 모르겠다. 지금은 Strawberry Perl 에서도 PPM 을 지원하므로, 모듈 설치의 편의성 등에서도 별 차이가 없어졌다고 생각된다.</div><br/><br/>필자의 경우 기본적으로 ActivePerl 을 사용하고 있다. 특별한 이유가 있는 것은 아니고, 처음에 사용하기 시작한 것이 ActivePerl 이었기 때문에(당시에는 Strawberry Perl이 아직 등장하기 전이었다. 아니면 이미 등장했었으나 필자가 몰랐을 수도.) 계속 이를 사용하고 있을 따름이다. 한때 PPM 의 존재가 계속 ActivePerl 을 사용하는 이유가 되었던 시기도 있었으나, 지금은 Strawberry Perl 에서도 PPM 을 지원하기 때문에 더 이상 그것이 이유가 되지는 않는다.<br/><br/><br/><br/><br/><B><u>2. ActivePerl 과 Strawberry Perl 을 함께 사용하기</u></B><br/><br/><br/><br/>사실 두 바이너리를 동시에 사용하여야 할 이유는 그다지 크지 않을지도 모르겠다. 오히려, 여러 버전의 Perl 을 함께 사용하는 데에 이 팁을 적용하는 것이 더 유용할지도 모른다. 어떻게 사용하든 사용하는 사람 마음이다. (필자의 경우는 주로 사용하는 바이너리는 ActivePerl 이지만, 작성한 Perl 어플리케이션을 배포하기 위하여 Strawberry Perl 을 사용한다.)<br/><br/>일단 ActivePerl 이건 Strawberry Perl 이건, 두 바이너리 모두 설치되면서 시스템에 특별한 조작을 가하지 않는다는 점을 짚고 넘어가야 한다. 즉, Perl을 설치하기 전후로 레지스트리나 시스템 설정 등에 특별한 변화가 없다는 것이다. (설치 프로그램이 .pl 파일을 자신이 설치하는 perl.exe 와 연결하는 것은 별론으로 하자. 이 한도 내에서는 레지스트리의 항목에 변화가 있다.) 기본적으로 모든 설정 항목들은 Perl 이 설치되는 폴더 이하에 기록된다. 따라서, 두 개의 Perl 을 모두 설치한다고 하더라도 설치 폴더만 다르다면 이 둘은 전혀 충돌하지 않고, 문제도 일으키지 않는다. <br/><br/><div style="margin: 10px; padding: 10px;">다만, Strawberry Perl의 경우에는 공식적으로 무설치(포터블)버전을 함께 공개하고 있기 때문에, 안전을 기하기 위해 이 쪽을 사용하는 것도 좋다.</div><br/><br/>그렇다면, 두 개의 Perl 이 모두 설치되어 있는 시스템에서 perl.exe 를 실행한다면 어느 쪽이 실행될까? 답은 "시스템 경로(PATH) 의 앞 쪽에 등록되어 있는 쪽이 실행된다" 이다. (물론 .PL 파일이 특정한 Perl 바이너리에 연결되어 있는 상태에서 탐색기에서 .PL 파일을 더블클릭했다면 그 특정한 Perl 이 실행될 것이다. 이건 예외다. 이 확장자 등록 기능은 잠재적으로 문제를 일으킬 가능성을 가지고 있는데, 이에 대한 내용은 이 글의 제일 끝 부분에서 추가로 논의할 것이므로 반드시 함께 알아두기 바란다.)<br/><br/>따라서, PATH 에 두 개의 Perl 경로를 필요할 때마다 선택적으로 추가해 주는 방법만으로, 두 개의 Perl 바이너리를 선택적으로 실행할 수 있다. 이 방법은 서로 다른 여러 개의 Perl 버전을 선택적으로 구동해야만 할 때에도 사용 가능한 방법이다.<br/><br/><div style="margin: 10px; padding: 10px;"><B><u>1. Strawberry Perl 을 사용해야 하는 경우 :</u></B><br/><br/>다음의 세 개의 폴더를 PATH 에 추가한다. (설치 폴더가 C:\Strawberry 인 경우를 가정했다.)<br/><br/>* C:\strawberry\perl\bin<br/>* C:\strawberry\perl\site\bin<br/>* C:\strawberry\c\bin<br/><br/>덧붙여, 환경 변수에 TERM=dumb 라는 항목을 추가해야 한다. (이유는 모른다.) 이를 배치 파일로 만들면 다음과 같이 된다. [[첨부 파일 링크가 있습니다.]]<br/><br/>@ECHO OFF<br/>PATH C:\strawberry\perl\site\bin;C:\strawberry\perl\bin;C:\strawberry\c\bin;%PATH%<br/>SET TERM=dumb<br/>CMD<br/><br/>이 배치 파일을 실행하면 콘솔 창이 뜨게 되는데, 이 콘솔 창에서는 Strawberry Perl 을 메인 Perl 바이너리로 사용할 수 있다.<br/><br/><br/><B><u>2. ActivePerl 을 사용해야 하는 경우</u></B><br/><br/>다음의 두 개의 경로만 PATH 에 추가해 넣으면 된다. (설치 경로가 C:\Perl 인 경우를 가정했다.)<br/><br/>* C:\Perl\site\bin<br/>* C:\Perl\bin<br/><br/>이를 배치 파일로 만들면 다음과 같다. [[첨부 파일 링크가 있습니다.]]<br/><br/>@ECHO OFF<br/>PATH C:\Perl\site\bin;C:\Perl\bin;%PATH%<br/>CMD<br/><br/>이 배치 파일을 실행하여 출력되는 콘솔 창에서는 ActivePerl 을 메인 Perl 바이너리로 사용할 수 있다. <br/><br/>양 쪽 모두에 있어서, 하나의 바이너리의 여러 버전을 선택하여 사용하는 경우에도 위와 같은 방법을 사용하면 된다. 각각의 버전은 별도의 폴더에 설치되어 있을 것이 요구된다.</div><br/><br/>다만 한 가지, 위의 방법으로 변경한 PATH 환경 변수는 <B><u>그 PATH 변경과 함께 출력된 콘솔 창 안에서만 유효</u></B>하다. 각각의 콘솔 창은 독립된 명령 처리기이므로 이는 어쩌면 당연한 것이다.<br/><br/>위 두 배치 파일을 하나의 배치 파일로 묶을 수도 있다. 다음의 배치 파일은 이를 통합한 것이다. 배치 파일 실행 후 1번을 입력하면 ActivePerl 을, 2번을 입력하면 Strawberry Perl 을 메인 바이너리로 사용하는 콘솔 창을 열게 된다. (윈도우에서 기본 제공하는 CHOICE 명령을 이용하여 구성하였으나, 인자를 받는 방식으로 구성하여도 상관 없을 것이다.) [[첨부 파일 링크가 있습니다.]]<br/><br/><div style="margin: 10px; padding: 10px;">@ECHO OFF<br/>ECHO.<br/>ECHO 1. Open ActivePerl Console Window<br/>ECHO 2. Open Strawberry Perl Console Window<br/>ECHO 0. EXIT<br/>ECHO.<br/>CHOICE /C 120 /N /M "Choice: "<br/><br/>IF ERRORLEVEL 3 GOTO END<br/>IF ERRORLEVEL 2 GOTO STRAWBERRYPERL<br/>IF ERRORLEVEL 1 GOTO ACTIVEPERL<br/><br/>GOTO END<br/><br/>:ACTIVEPERL<br/><br/>@ECHO OFF<br/>PATH C:\Perl\site\bin;C:\Perl\bin;%PATH%<br/>SET TERM=<br/>CMD<br/><br/>GOTO END<br/><br/>:STRAWBERRYPERL<br/><br/>@ECHO OFF<br/>PATH C:\strawberry\perl\site\bin;C:\strawberry\perl\bin;C:\strawberry\c\bin;%PATH%<br/>SET TERM=dumb<br/>CMD<br/><br/>GOTO END<br/><br/>:END</div><br/><br/><br/><br/><br/><B><u>3. 콘솔 창이 열릴 때 특정한 폴더에서 열도록 하기</u></B><br/><br/><br/><br/><div style="margin: 10px; padding: 10px;">이 항목은 다음 문서를 바탕으로 작성되었습니다 :<br/><br/>윈도우 7 / 윈도우 탐색기의 특정 폴더를 클릭하여 콘솔 모드 열기 : http://www.nightowl.pe.kr/blog/article/412</div><br/><br/>위에서 만든 배치 파일을 조금 더 개선해 보자. 콘솔 메뉴가 열릴 때에 시작되는 폴더는 항상 일정한 위치로 고정되어 있다. 관리자 권한 하에서 실행된다면 C:\WINDOWS\SYSTEM32, 관리자 권한이 아니라면 각 개인 폴더에서 열린다. 그러나 대개 스크립트는 그 위치에 있지 않을 것이다. 그 결과 원하는 스크립트를 실행하기 위해 몇 단계의 폴더 이동을 거쳐야 한다. 이런 불편함을 개선하기 위하여, 탐색기에서 특정 폴더를 우클릭하여 그 폴더에서 콘솔 메뉴가 오픈되도록 할 수도 있다. 이 기능을 사용하기 위해서, 위 배치 파일을 아래와 같이 조금 수정하여 특정한 폴더에 저장한다. [[첨부 파일 링크가 있습니다.]]<br/><br/><div style="margin: 10px; padding: 10px;">@ECHO OFF<br/>ECHO.<br/>ECHO 1. Open ActivePerl Console Window<br/>ECHO 2. Open Strawberry Perl Console Window<br/>ECHO 0. EXIT<br/>ECHO.<br/>CHOICE /C 120 /N /M "Choice: "<br/><br/>IF ERRORLEVEL 3 GOTO END<br/>IF ERRORLEVEL 2 GOTO STRAWBERRYPERL<br/>IF ERRORLEVEL 1 GOTO ACTIVEPERL<br/><br/>GOTO END<br/><br/>:ACTIVEPERL<br/><br/>@ECHO OFF<br/>PATH C:\Perl\site\bin;C:\Perl\bin;%PATH%<br/>SET TERM=<br/>CMD /k cd /d "%1"<br/><br/>GOTO END<br/><br/>:STRAWBERRYPERL<br/><br/>@ECHO OFF<br/>PATH C:\strawberry\perl\site\bin;C:\strawberry\perl\bin;C:\strawberry\c\bin;%PATH%<br/>SET TERM=dumb<br/>CMD /k cd /d "%1"<br/><br/>GOTO END<br/><br/>:END</div><br/><br/>각각 CMD.EXE 를 실행하는 부분에 옵션으로 /k cd /d "%1" 이 들어간 것을 알 수 있다. /k 옵션을 붙이면 뒤에 따라오는 명령을 실행한 후에도 콘솔 창이 꺼지지 않기 때문에, 사용자는 계속 같은 환경에서 명령어를 입력하여 콘솔 창을 사용할 수 있다. CD 명령에 /D 옵션을 사용하면 폴더 외에 드라이브도 변경할 수 있으므로 드라이브 까지 변경되는 경우에도 오류 없이 한 번에 원하는 폴더로 찾아갈 수 있다. %1는 반드시 큰따옴표로 묶어주어야 중간에 공백문자가 있는 폴더를 찾아갈 때 오류가 발생하지 않는다.<br/><br/>이제 이 배치 파일을 실행할 레지스트리 항목을 등록해야 한다. 다음 레지스트리 항목을 등록한다. 위의 배치 파일을 PerlSel.bat 라는 이름으로 C:\ 에 저장하였다고 가정한 것이므로, 각자의 환경에 따라 적절히 수정한다. [[첨부 파일 링크가 있습니다.]]<br/><br/><div style="margin: 10px; padding: 10px;">Windows Registry Editor Version 5.00<br/><br/>[HKEY_CLASSES_ROOT\Drive\shell\cmdsperl]<br/>@="Perl 바이너리를 선택하여 폴더 열기"<br/><br/>[HKEY_CLASSES_ROOT\Drive\shell\cmdsperl\command]<br/>@="C:\\PerlSel.bat \"%1\""<br/><br/>[HKEY_CLASSES_ROOT\Directory\shell\cmdsperl]<br/>@="Perl 바이너리를 선택하여 폴더 열기"<br/><br/>[HKEY_CLASSES_ROOT\Directory\shell\cmdsperl\command]<br/>@="C:\\PerlSel.bat \"%1\""</div><br/><br/>Drive 와 Directory 에 모두 등록하여, 대상 스크립트가 특정 드라이브의 루트 폴더에 있는 경우에도 찾아갈 수 있도록 한다. 이제 탐색기에서 특정한 폴더를 마우스 우클릭하면 다음과 같은 화면이 나타나게 된다.<br/><br/>[첨부 이미지가 있습니다.]<br/><br/>이후의 과정은 위에서 본 것과 똑같고, 다만 시작 폴더만 선택한 폴더로 바뀌게 된다.<br/><br/><br/><br/><br/><B><u>4. 특정한 바이너리를 이용하도록 하는 메뉴 출력하기</u></B><br/><br/><br/><br/>때로는 굳이 콘솔창을 열 필요 없이, 특정한 바이너리를 이용하여 특정한 스크립트만 일시적으로 실행하고 싶은 경우도 있을 수 있다. 이런 경우를 위하여 .PL 파일을 마우스 우클릭하였을 때 바이너리를 지정하여 실행하는 메뉴를 넣을 수 있다. 아래에 이를 추가하는 레지스트리 파일을 기술하였다. 참고로, 이 내용이 잘못 변경되면 .PL 파일의 연결이 끊어지는 사태가 벌어질 수 있으므로, 가능하다면 기존의 레지스트리 내용이 있다면 백업한 후에 이 레지스트리를 실행하도록 한다. 백업할 레지스트리는 다음의 두 항목이다.<br/><br/><div style="margin: 10px; padding: 10px;">HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.pl<br/>HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Perl</div><br/><br/>이하는 레지스트리 파일의 내용이다. ActivePerl 은 C:\Perl 이하에, Strawberry Perl은 C:\Strawberry 이하에 설치되어 있다고 가정한다. [[첨부 파일 링크가 있습니다.]]<br/><br/><div style="margin: 10px; padding: 10px;">Windows Registry Editor Version 5.00<br/><br/>[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.pl]<br/>@="Perl"<br/><br/>[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Perl\shell\OpenWithActivePerl]<br/>@="Run with Activeperl"<br/><br/>[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Perl\shell\OpenWithActivePerl\command]<br/>@="C:\\Perl\\bin\\perl.exe \"%1\""<br/><br/>[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Perl\shell\OpenWithStrawberryPerl]<br/>@="Run with StrawberryPerl"<br/><br/>[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Perl\shell\OpenWithStrawberryPerl\command]<br/>@="C:\\Strawberry\\Perl\\bin\\perl.exe \"%1\""</div><br/><br/>위의 레지스트리 파일을 적용한 후 .pl 파일에 마우스 오른쪽 버튼을 클릭하면 다음과 같이 바이너리를 선택하여 실행할 수 있는 메뉴 항목이 출력된다. 이제 둘 중 하나를 선택하여 스크립트를 실행하면 되겠다.<br/><br/>[첨부 이미지가 있습니다.]<br/><br/><div style="margin: 10px; padding: 10px;">특정한 확장자에 대해 컨텍스트 항목을 연결하는 방법은 다음의 문서를 참조하였습니다.:<br/><br/>마우스 우클릭으로 .java 컴파일과 .class 실행하기 : http://snoopybox.co.kr/1457</div><br/><br/>이를 조금 더 응용하여, 이런 경우도 생각할 수 있다. 위의 레지스트리에서는 각각의 항목에 대해서 바로 해당 perl.exe 를 호출하여 실행하도록 설정되어 있는데, 이런 경우에 (혹시라도) PATH 의 설정과 관련하여 문제가 발생할 여지도 있을 수 있다. (물론 필자의 경우에는 그런 문제가 발생하지 않았다. 그러나 가능성이 있을 것 같아서 하는 첨언이다.) 만약 이런 가능성마저 원천봉쇄하고 싶다면, 각각의 Perl 바이너리에 관하여 배치 파일을 작성해 둔 후, 레지스트리의 각 실행 메뉴의 연결을 배치 파일로 해 두면 된다. 예를 들면 이렇다. 만약 Strawberry Perl 의 설치 경로가 C:\Strawberry 이하라고 가정하자. 그리고 다음과 같은 배치 파일을 perlrun.bat 라는 이름으로 C:\Strawberry 폴더에 저장했다고 생각하자.<br/><br/><div style="margin: 10px; padding: 10px;">@ECHO OFF<br/>PATH C:\strawberry\perl\site\bin;C:\strawberry\perl\bin;C:\strawberry\c\bin;%PATH%<br/>SET TERM=dumb<br/>perl %1<br/>pause</div><br/><br/>그리고 위 레지스트리 파일 중 Strawberry Perl 과 관련된 항목을 다음과 같이 변경한다. 제일 마지막 줄의 command 부분만 변경하면 된다.<br/><br/><div style="margin: 10px; padding: 10px;">[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Perl\shell\OpenWithStrawberryPerl\command]<br/>@="C:\\Strawberry\\perlrun.bat \"%1\""</div><br/><br/>이렇게 하면, "Run with StrawberryPerl" 을 선택하면 방금 저장했던 배치 파일이 실행되면서 우선 PATH 를 Strawberry Perl 로 변경한 후 선택된 .pl 파일을 실행하게 된다. Strawberry Perl 에 대해서만 예를 들었지만, ActivePerl 에 대해서도 PATH 부분만 변경하면 그대로 적용이 가능하다.<br/><br/>물론 이 방법은 문제점이 있다. 실행하려는 스크립트에 대해서 인자를 넘겨줄 수 없다는 것이다. 인자와 함께 실행하기 위해서는 콘솔 모드상에서 직접 해당 스크립트를 인자를 주어 실행하는 방법을 써야 한다. 특정한 바이너리를 선택하여 특정한 폴더에서 콘솔 창을 여는 방법은 위에서 이미 보았으므로 생략한다.<br/><br/><br/><br/><br/><br/><B><u>5. ActivePerl과 StrawberryPerl을 함께 사용할 때의 유의사항 (2012년 3월 27일 추가)</u></B><br/><br/><br/><br/>윈도우의 확장자 연결 기능을 사용하면, .PL 확장자를 Perl에 연결할 수 있다. 사용자가 수동으로 제어판 또는 탐색기에서 연결할 수도 있고, Perl 을 설치할 때 설치 옵션으로서 확장자 연결을 줄 수도 있는데, 설치 프로그램을 이용하여 설치를 했다면 대개 설치 시 확장자 연결을 했을 것이다.<br/><br/>이렇게 확장자 연결을 해 두면 탐색기에서 .PL 파일을 더블클릭하여 바로 실행이 가능해지므로 상당히 편리해진다. 또 이 확장자 연결은 콘솔 모드에서도 유효하므로, CMD 창에서 다음과 같은 두 개의 명령 모두 유효하게 현재 폴더의 makefile.pl 을 실행하게 된다.<br/> <br/><div style="margin: 10px; padding: 10px;">perl makefile.pl<br/>makefile.pl</div><br/> <br/>그런데, 이 부분 때문에 예기치 않은 오류가 발생하는 경우가 있다. 예를 들면, 현재의 PATH 에는 Strawberry Perl 이 있고, 확장자 연결은 ActivePerl로 되어 있을 경우, 위의 두 명령 중 perl 을 붙인 명령은 PATH의 연결을 따라 Strawberry Perl이 실행되지만, 아래쪽의 perl 없이 바로 파일명을 입력한 명령은 PATH와 관계 없이 확장자 연결을 따라 ActivePerl이 실행되게 된다. 그 결과, 필요한 환경 변수가 달라지거나, 필요한 모듈을 찾을 수가 없다는 등의 예기치 않은 오류를 만나게 될 수도 있다.<br/><br/>[첨부 이미지가 있습니다.]<br/><br/>위 그림은 실제로 발생한 난장판의 예인데, 모듈의 설치를 위해 makefile.pl 을 실행하면서 무심결에 perl 을 빼고 바로 파일명을 입력한 탓에 생성된 설치 스크립트가 완벽하게 꼬여버렸다. 왼쪽이 정상적으로 만들어진(perl makefile.pl 실행 결과) 설치 스크립트이고, 오른쪽이 잘못 꼬여버린(makefile.pl 실행 결과) 설치 스크립트다. 오른쪽 이미지를 보면, C:\Strawberry 이하의 경로를 가리켜야 정상인 스크립트 설정 중 일부가 C:\usr 이하(여기에는 ActivePerl이 설치되어 있다)를 가리키고 있다. 그 결과 설치 중 계속적으로 원인을 알 수 없는 오류를 만났고, 원인을 찾느라 한참의 시간을 낭비해야 했다.<br/><br/>따라서, 두 개 이상의 Perl 바이너리를 이 방법으로 사용하는 경우, 현재 실행되는 Perl 바이너리가 어느 쪽 버전인지를 분명하게 해 주어야 한다. 특히 콘솔에서 실행 시 perl 을 빼고 입력하는 것은 상당히 위험하다. 가능하면 확장자 연결 기능을 사용하지 않는 것이 더 좋을지도 모르겠다.  ]]>
		</description>
		<category>Perl</category>
		<category>Strawberry Perl</category>
		<category>ActivePerl</category>
		<pubDate>Sun, 12 Feb 2012 06:52:16 +0900</pubDate>
	</item>
	<item>
		<title>
		<![CDATA[  윈도우 7 / 윈도우 탐색기의 특정 폴더를 클릭하여 콘솔 모드 열기 (by 부엉이)  ]]>
		</title>
		<link>http://www.nightowl.pe.kr/oblog/article/412</link>
		<guid>http://www.nightowl.pe.kr/oblog/article/412</guid>
		<description>
			<![CDATA[  사용 빈도가 그렇게 많지는 않지만, 어느 수준 이상이 되면 은근히 많이 쓰게 되는 것이 바로 콘솔 모드(흔히 도스창이라고 불리는 까만 화면)이다. 보조 프로그램 안에 들어 있는 "명령 프롬프트"를 클릭하거나, 실행 폼에 cmd.exe 를 입력하여 실행할 수 있다.<br/><br/>그런데, 이 콘솔 모드를 사용하면서 참 불편한 점이, 항상 콘솔 모드를 실행할 때마다 정해진 폴더(관리자 권한을 준 경우 C:\WINDOWS\SYSTEM32 폴더, 사용자 권한인 경우에는 개인 폴더)에서만 실행된다는 점이다. 대개의 경우 콘솔 모드를 켠 목적이 해당 폴더가 아닌 경우가 많기 때문에, CD 명령을 사용하여 원하는 폴더로 일일이 찾아들어가야 한다. 폴더 명이 길거나, 목표하는 폴더가 몇 단계쯤 아래로 내려가 있으면 은근히 짜증이 밀려오곤 한다.<br/><br/>이런 경우, 윈도우 탐색기의 우클릭 메뉴에 "콘솔 모드 열기" 메뉴가 뜨도록 하면 그 폴더에서 콘솔 모드를 열 수 있어서 편리하다. 그 방법 자체는 매우 오래 전에 알려져 있다. Windows Power Toys 를 이용하거나, 해당 레지스트리만을 가져다가 입력하면 된다. 이에 대한 원 글은 다음의 링크로 들어가면 볼 수 있다.<br/><br/>* 원 글: 명령행 여기로... http://qaos.com/article.php?sid=1263<br/><br/>위 글대로 레지스트리에 해당 항목을 등록하면, 탐색기에서 폴더나 드라이브를 마우스로 우클릭하면 [명령행 열기] 라는 메뉴가 보이게 되며, 그 메뉴를 클릭하면 그 폴더에서 콘솔 모드(도스창)가 열리게 된다.<br/><br/><div style="margin: 10px; padding: 10px;">레지스트리 파일은 여기에서도 다운로드 가능하다. [첨부 파일 링크가 있습니다.]</div><br/><br/>사실 여기까지의 내용이라면 이미 2002년에 쓰여진 위 글의 재탕에 불과하다. 필자 역시 저 레지스트리를 윈도우 XP를 쓰던 시절에는 정말 편리하게 써 왔었다. 그런데, 윈도우 7로 업그레이드 후에, 위의 레지스트리 파일을 아무리 클릭해 넣어도 탐색기의 마우스 우클릭 메뉴에 [명령행 열기] 메뉴가 뜨지 않는 증상이 나타났다. 한동안 원인을 알 수가 없어서 이 스크립트를 사용하지 못하고 있었는데, 최근 그 원인을 찾았다. 윈도우 7에서는 다음과 같은 추가적인 처리를 해 주어야 한다.<br/><br/>1. 일단 위 레지스트리 파일(cmd.reg)을 더블클릭하여 등록한다. <br/><br/>2. 레지스트리 에디터를 실행하여 다음의 레지스트리를 찾아간다. 위 레지스트리 파일이 등록한 레지스트리 항목이다.<br/><br/><div style="margin: 10px; padding: 10px;">HKEY_CLASSES_ROOT\Directory\shell\cmd</div><br/><br/>3. 위 레지스트리 항목에 찾아가 보면 아마도 아래와 같은 상태가 되어 있을 것이다.<br/><br/>[첨부 이미지가 있습니다.]<br/><br/>여기에 존재하는 Extended 와 NoWorkingDirectory 의 두 개의 키를 깔끔하게 삭제해 준다. (윈도우 XP 시절에는 저 키들이 없었는데, 윈도우 7에서 저 키들이 멋대로 생기면서 문제를 일으킨 것이었다.)<br/><br/>4. 이제 Drive 항목으로 가서 이 부분에 존재하는 저 두 개의 키도 삭제해 주어야 한다. 위치는 다음과 같다.<br/><br/><div style="margin: 10px; padding: 10px;">HKEY_CLASSES_ROOT\Drive\shell\cmd</div><br/><br/>5. 여기까지 수정 후 레지스트리 에디터를 종료한다. 이제 윈도우 탐색기에서 드라이브나 폴더에 마우스 오른쪽 버튼을 클릭해 보면 [명령행 열기] 메뉴가 정상적으로 나타나는 것을 확인할 수 있다.  ]]>
		</description>
		<category>컴퓨터 사용 경험</category>
		<category>윈도우 탐색기 확장</category>
		<category>콘솔 모드</category>
		<category>윈도우 7</category>
		<pubDate>Sat, 11 Feb 2012 00:36:39 +0900</pubDate>
	</item>
	<item>
		<title>
		<![CDATA[  홈페이지 주소 변경을 알려드립니다. (by 부엉이)  ]]>
		</title>
		<link>http://www.nightowl.pe.kr/oblog/article/411</link>
		<guid>http://www.nightowl.pe.kr/oblog/article/411</guid>
		<description>
			<![CDATA[  이 블로그에 자주 오셨던 분이라면, 이미 홈페이지 주소가 자동으로 리다이렉션 되고 있음을 알고 계실 것입니다. 이제 일주일 정도 되었는데요. 게시물을 단순히 RSS 로 받아보고 계시던 분 등 자주 들르지 않으시던 분들은 아마 아직 모르고 계실 수도 있겠습니다.<br/><br/>2012년 2월 5일자로, 기존의 http://www.dormouse.pe.kr/ 이하에 있던 블로그는 새로운 도메인 주소로 이전되었습니다. 기존에 몰래(?) 운영되고 있던 다른 목적의 홈페이지와 통합운영을 위해서인데요. 당분간은 기존의 주소로 접속하셔도 블로그로 접속하는 데 문제가 없습니다. 이 블로그에 방문하는 검색 엔진 등의 정보가 모두 개정될 때까지 최소한 180일간은 기존 주소가 유지될 예정입니다.<br/><br/>새롭게 변경되는 주소는 http://www.nightowl.pe.kr/ (현재 보고 계신 주소) 이며, 블로그 접속 주소는 http://www.nightowl.pe.kr/blog 가 되겠습니다. RSS 로 글을 받아보고 계시던 분들(현재 제가 파악하고 계신 분이 한 다섯 분 정도 계십니다만)께서는 RSS 주소를 다음의 주소로 변경하여 주시기 바랍니다.<br/><br/>* 새로운 RSS 주소:&nbsp;&nbsp;http://www.nightowl.pe.kr/blog/rss<br/><br/>계정을 변경하면서 블로그 툴의 환경이 많이 바뀐 터라, 아직 동작하지 않는 기능이 여러 가지 있습니다. 대표적으로, 방명록과 덧글의 수정/삭제 기능이 현재 동작하지 않고 있는 기능입니다. 잘못 작성되어 삭제를 요하는 방명록/덧글이 있으면 역시 방명록/덧글로 요청해 주시면 직접 삭제해 드립니다.<br/><br/>이번에 계정을 통합하면서, 모든 방명록/댓글에 대해서 알림 기능을 추가해 넣었습니다. 누구든지 제 홈페이지의 방명록과 댓글에 글을 남겨 주시면 제게 실시간으로 알림이 날아오게 됩니다. 제 블로그에 글을 남겨주시는 분들께 가능한 한 빠른 답글을 드리기 위함이기도 하고, 한참 지난 글에 댓글로 광고나 욕설을 남겨주시는 분들을 빠른 시간 안에 응징하기 위함이기도 합니다. (^^)<br/><br/>기존에 등록 방문자로 등록하여 이용하시던 분들께서는 변함 없이 로그인이 지원되므로 기존의 이메일과 패스워드로 로그인하시면 됩니다. 다만 정보 수정 및 방문자 등록 해지 기능이 아직 동작하지 않으므로 이를 원하시면 역시 댓글이나 방명록을 통하여 요청해 주십시오. 새로이 등록 방문자로 등록하시려는 분께서는 관련 모듈이 아직 이전되지 않았기 때문에 조금 기다리셔야 합니다.  ]]>
		</description>
		<category>공지사항</category>
		<category>주소변경</category>
		<category>계정통합</category>
		<pubDate>Fri, 10 Feb 2012 01:46:17 +0900</pubDate>
	</item>
	<item>
		<title>
		<![CDATA[  Perl / Win32 / PAR::Packer - 한글 사용자 이름을 갖는 계정에서 PAR::Packer 실행 바이너리가 실행되지 않는 문제점의 해결 (by 부엉이)  ]]>
		</title>
		<link>http://www.nightowl.pe.kr/oblog/article/410</link>
		<guid>http://www.nightowl.pe.kr/oblog/article/410</guid>
		<description>
			<![CDATA[  <B><u>참고(2012년 01월 30일 추가, 2012년 3월 27일 수정)</u></B>:<br/><br/>이 문제는 얼마 전 필자가 포스팅했던, 윈도우 사용자 이름에 한글이 포함되어 있을 때 PAR::Packer 로 빌드된 실행 바이너리가 실행되지 않는 문제([내부 링크가 있습니다.])의 해결 방법입니다.<br/><br/>국내 Perl 커뮤니티의 @gypark 님의 도움으로, 이 문제는 CPAN에 <a href="https://rt.cpan.org/Ticket/Display.html?id=73491" target="_blank">버그 리포트</a>가 이루어졌으며, 제작자가 수정의견을 받아들여 이를 패치하였습니다. 따라서 PAR::Packer 의 1.013 버전 이후에는 이 문제는 발생하지 않으며, 자신의 PAR::Packer 를 1.013 버전 또는 그 이후 버전으로 업그레이드 함으로써 이 문제는 완전히 해결이 가능합니다.<br/><br/>즉, 이 글을 보고 계신 분이 PAR::Packer 를 사용하시는 Perl 개발자이고, 자신의 PAR::Packer 모듈 버전이 1.013 또는 그 이후 버전이라면 이 글에서 논의되는 문제는 이미 해결되었을 것이므로, 이 글을 읽으실 필요는 없습니다. <br/><br/>다만, 필자가 생각하기에, 이 패치 방법은 이 글에서 제기하는 문제가 해결된 이후에도 PAR::Packer 를 이용하는 Perl 개발자에게 있어서는 다른 용도로서 그 의미를 갖고 있다고 생각합니다. 따라서 기존의 원문은 그대로 놓아둔 채로, 이 글의 마지막에 새로운 장을 설정하여 그에 관한 논의를 더 하였습니다. 관심있는 분께서는 참고하시기 바랍니다.<br/><br/><br/><br/><br/><br/><B><u>1. 들어가면서</u></B><br/><br/><br/><br/>Perl에 대한, 해커나 시스템 관리자들이 사용하는 언어라는 일반적인 통념과는 달리, 윈도우 환경에서도 Perl은 나무랄 데 없는 활용도를 가지고 있습니다. 윈도우의 GUI 환경 역시 적용이 가능하며, 여러 CPAN 모듈들을 사용하여 일반 목적의 각종 프로그램을 별 무리 없이 작성할 수도 있습니다.<br/><br/>그러나 이렇게 작성된 프로그램을 막상 배포하려 하면 골치아픈 문제와 맞닥뜨립니다. 유닉스/리눅스와는 달리 윈도우에는 대개 Perl 이 설치되어 있지 않기 때문에, 다른 시스템에서 이 스크립트를 실행할 수 있으리라는 보장이 없습니다. Perl 도 닷넷 프레임워크 같은 실행 런타임이 있으면 좋겠지만, 안타깝게도 그런 것은 존재하지 않는군요. 그렇다고 "이 프로그램을 사용하시려면 먼저 시스템에 Perl 을 설치하세요." 라는 것은 일반 사용자에게는 배보다 배꼽이 더 큰 일입니다.<br/><br/>그래서, 작성한 프로그램을 실행 바이너리로 배포할 수 있도록 몇 개의 도구들이 등장했는데, 다음과 같은 것들이 대표적입니다.<br/><br/>- <a href="http://www.activestate.com/perl-dev-kit" target="_blank">PerlApp&nbsp;&nbsp;(ActiveState)</a><br/>- <a href="http://www.indigostar.com/perl2exe.php" target="_blank">Perl2Exe (Indigo Software)</a><br/><br/>다만 위 프로그램들은 모두 상업용 소프트웨어로써, 정식으로 사용하려면 만만치 않은 자금의 지출이 필요합니다. 게다가 모두 외국에서 만들어진 프로그램이어서, 카드로 달러 결제를 해야 하는 등 상당히 번거롭습니다. 프로그램을 만들어서 돈 받고 팔려는 것도 아닌데, 40여만원의 지출(PerlApp이 포함된 Perl Dev Kit의 경우)은 뭔가 격에 맞지 않는 짓이죠.<br/><br/>이런 경우에 사용할 수 있는 도구가 바로 PAR::Packer 라고 하는 Perl 모듈입니다. 이 모듈은 대상 Perl 스크립트에 사용된 모든 모듈을 한데 모아서 Perl 해석기[Interpreter]와 함께 하나의 실행 파일로 만들어 줍니다. Perl 해석기가 포함되어 있는 실행 바이너리이기 때문에, Perl이 설치되지 않은 시스템에서도 문제 없이 사용할 수 있습니다. 초기 구동 속도가 조금 느리다는 단점은 있지만, 일반 목적의 배포에는 큰 문제가 되지 않습니다.<br/><br/>ActivePerl 의 경우에는 PPM 으로부터 설치할 수 있으며, Strawberry Perl의 경우에는 CPAN 을 통해 설치가 가능합니다. ActivePerl 의 경우에는 MinGW 와 dmake 를 함께 설치해 주어야 합니다.(MinGW에 포함되어 있는 오픈소스 컴파일러인 gcc를 컴파일에 사용하기 위해서입니다. Strawberry Perl의 경우에는 이미 gcc 가 설치되어 있습니다.)<br/><br/><div style="margin: 10px; padding: 10px;">제가 주로 사용하는 Perl 바이너리가 ActivePerl 이기 때문에, 이하의 모든 이야기는 ActivePerl을 기준으로 합니다. 아마 Strawberry Perl 역시 동일할 것입니다.</div><br/><br/>PAR::Packer 의 Packager 인 pp 의 구체적인 사용법은 <a href="http://search.cpan.org/~rschupp/PAR-Packer-1.012/lib/pp.pm" target="_blank">여기</a>를 참조하시면 되므로 여기서는 더 이상 설명하지 않습니다. 애초에 이 글의 목적이 PAR::Packer 를 소개하자는 글은 아니기 때문입니다.<br/><br/><br/><br/><br/><br/><B><u>2. 대한민국에서만 발생하는, PAR::Packer 의 문제점</u></B><br/><br/><br/><br/>그런데, 이 PAR::Packer 에 관하여, 이 곳 대한민국에서만 발생하는 골치아픈 문제가 하나 있습니다. 그것은 바로 사용자 이름과 관련되는 문제입니다. 무슨 이야기일까요? 이 부분을 이해하기 위해서는, PAR::Packer 로 패키징된 실행 바이너리의 실행 과정에 대한 이해가 선행되어야 합니다.<br/><br/>일단 PAR::Packer 가 Perl 코드 자체를 컴파일하지는 않는다는 점을 이해해야 합니다. Perl은 인터프리터 언어이고, 실행 바이너리로 패키징한다 하여 이 점은 변하지 않습니다. PAR::Packer 는 대상 Perl 스크립트와, 그 스크립트가 사용하는 모든 모듈을 한데 모아서 ZIP 으로 묶고, 여기에 Perl 실행에 필요한 해석기를 포함하여 일종의 자동 풀림 형태의 EXE 압축 파일로 만듭니다. 그래서, PAR::Packer 로 만들어진 실행 파일을 실행하면, PAR::Packer는 먼저 특정한 위치에 ZIP 압축을 풀어 놓은 후, 포함되어 있는 Perl 해석기를 통하여 스크립트를 실행하게 됩니다.<br/><br/><div style="margin: 10px; padding: 10px;">그래서 PAR::Packer 로 빌드한 실행 바이너리를 실행하면, 동일한 이름의 파일 두 개가 프로세스 목록에 모-자 프로세스 형태로 떠 있는 것을 확인하실 수 있습니다. 물론 프로그램을 종료하면 두 개의 프로세스가 동시에 꺼집니다.</div><br/><br/>이 압축을 푸는 과정이 문제입니다. PAR는 압축을 윈도우 TEMP 폴더에 풀어놓는데, 그냥 TEMP 폴더에 풀어놓는 것이 아니라, TEMP 폴더 밑에 PAR-[사용자 이름] 이라는 폴더를 하나 만들고, 그 밑에 다시 cachexxxxxx.. 라는 폴더를 만들어서 그 안에 압축을 풀어놓습니다. 예를 들면 윈도우 7에서는 이런 구조가 됩니다.<br/><br/>C:\Users\사용자 이름\AppData\Local\Temp\par-사용자 이름\cache-xxxxxxxxxxxxxxxxxx<br/>(x는 무작위. 내부적으로는 SHA-1 해시를 사용합니다.)<br/><br/>[첨부 이미지가 있습니다.]<br/><br/>문제는 사용자 이름에 한글이 포함되는 경우입니다. 이게 왜 문제가 될까요? 바로 한글 인코딩 때문입니다. PAR::Packer 는 우선 시스템의 TEMP 폴더의 경로를 찾아 문자열로 저장합니다. 그리고 그 문자열 뒤에 "par-사용자 이름" 이라는 문자열을 덧붙이게 되는데, 이 과정에서 2바이트(CP949의 경우)문자인 한글의 특성을 고려하지 않고, 이름에 사용된 문자를 모두 1바이트 문자(영문자 등)로 간주하여 그 이외의 문자를 일괄적으로 _ 로 변경해 버립니다. 이 과정에서 한글을 구성하는 2바이트 중 일부가 멋대로 _ 문자로 변경되어 버리고, 짝을 잃은 나머지 1바이트는 이상한 문자로 바뀌어 버리는 것이죠. 이렇게 이상하게 변한 문자가 끼어 있는 경로로 폴더를 만들려고 시도하면? 폴더 이름에 깨진 문자가 포함되어 있는 결과 폴더 작성에 실패하게 되겠죠. 그 결과 creation of private temporary subdirectory ~~~~ failed. 라는 오류를 내면서 실행이 중단되어 버립니다. 눈에 보이는 결과는 둘 중 하나입니다. --gui 옵션을 주어서 빌드한 EXE 파일이라면 파일을 더블클릭해도 아무런 반응이 없는 모습이 될 것이고, 그것이 아니라면 콘솔 화면이 잠깐 나타났다가 꺼지는 모습이 나타나겠죠.<br/><br/>[첨부 이미지가 있습니다.]<br/><br/><br/><br/><br/><br/><B><u>3. 문제를 해결하는 방법?</u></B><br/><br/><br/><br/>한글과 관련한 문제이다 보니, 구글링을 해봐도 해결 방법이 없습니다. 아예 이런 현상에 대한 논의 자체가 없죠. 대한민국의 Perl 사용자가 적기 때문이기도 하겠지만, 가까운 일본만 해도 인코딩 문제로 인한 말썽이 많은 CJK 문자권에 들어가는데다 Perl 인구도 많은 편인데, 이런 문제가 이슈가 안 되는 것이 좀 의아할 따름입니다.<br/><br/>각설하고, 이 문제는 PAR::Packer 에서 스크립트의 압축을 해제하는 폴더를 변경할 수 있게 해준다면 간단히 해결이 가능합니다. 그러나, pp 명령행 옵션에 압축 해제된 스크립트가 저장되는 위치를 변경하는 옵션은 없습니다. -T 또는 --tempcache 옵션이 있습니다만, 이 옵션은 Temp 폴더 대신 압축을 풀 폴더를 지정하는 옵션으로서, 문제가 되는 "par-사용자 이름" 부분이 이 뒤에 그대로 따라가므로 전혀 문제가 해결되지 않습니다.<br/><br/>이쯤 되면, 배포자 입장에서는 이 문제를 해결하지 않는 것이 사실 속 편합니다. 프로그램 사용자들에게, 사용자 이름이 한글이면 실행이 안 되니까, 영문자 및 숫자로 구성된 사용자 계정을 만든 후 사용하라고 readme.txt 파일에 적어서 배포하는 것이죠. 저도 방법을 찾지 못해서, 한동안 이런 방식으로 배포했습니다.<br/><br/>그러나, 생각해 보면 어처구니가 없는 일입니다. 사용자 이름을 한글로 쓰는 것이 물론 (호환성을 생각하면) 좋은 습관은 아니지만, 이런 방식으로 사용자 이름을 만들어 사용하는 사람이 차고 넘칠 정도로 많은데다, 윈도우에서도 멀쩡하게 허용하고 있는 터에 일개 프로그램에서 쓰지 말라고 할 수는 없는 것 아니겠습니까. 영 불가항력이 아닌 바에야, 프로그램상에 존재하는 문제의 해결을 사용자에게 떠넘기는 것도 별로 좋은 태도는 아니죠.<br/><br/><br/><u>(1) 첫 번째 시도: PL/PM 파일의 수정</u><br/><br/>결국 소스 레벨에서의 해결밖에 방법이 없겠다 싶어서, 내부의 모듈들을 뒤졌습니다. 일단 두 개의 파일이 검색되었습니다.<br/><br/>1) site/bin/par.pl 의 _set_par_temp 서브루틴<br/>2) site/lib/PAR/SetupTemp.pm 의 _get_par_user_tempdir 서브루틴<br/><br/>여기구나 싶어서, 이 두 부분에서 임시 폴더 작성에 사용되는 사용자 이름을 항상 OwlNetworks 로 돌려주도록 코드를 수정했습니다. 아래 그림처럼 말이죠.<br/><br/><div style="margin: 10px; padding: 10px;">저에 맞추어서 OwlNetworks 라고 적은 것 뿐, 다른 분들은 자신에게 맞추어 임의로 영문자 및 숫자를 섞어서 정하시면 됩니다.</div><br/><br/>[첨부 이미지가 있습니다.]<br/><br/>결과는? 실패입니다. 여전히 만들어진 실행 바이너리는 사용자 이름이 포함된 폴더에 압축을 풀더군요. 임시 폴더의 경로를 만드는 코드가 다른 어디에도 존재하지 않았기 때문에, 이 수정이 제대로 동작하지 않는다면 아마도 PAR::Packer 가 컴파일시 이 코드를 사용하지 않는다는 추정이 가능했습니다. 그 때, 제 눈에 띈 주석 한 줄.<br/><br/># The C version of this code appears in myldr/mktmpdir.c<br/><br/>....PAR::Packer 를 컴파일하기 전의 C 소스 레벨에서의 수정이 필요했던 것입니다. 그 이야기는, 이미 컴파일 된 상태로 제공되는 PPM 파일을 사용할 수 없다는 의미였습니다. 오리지날 소스의 수정이 필요하므로, CPAN 을 통한 설치도 안됩니다. 오 마이 갓. 저는 C 언어를 모릅니다. orz...<br/><br/><br/><u>(2) 두 번째 시도: C 소스의 수정 후 재컴파일</u><br/><br/>지푸라기라도 잡는 심정으로, 제가 사용하고 있는 버전과 동일한 버전의 PAR::Packer 0.991 버전의 소스를 metacpan.org 을 통하여 다운로드 받았습니다.<br/><br/><div style="margin: 10px; padding: 10px;">제가 사용하는 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 의 버전은 조금 오래된 버전입니다.]<br/><br/>참고로, 공식적인 ActiveState PPM 에서 제공되는 5.10 버전의 PPM 목록에는 PAR::Packer 가 없습니다. ActiveState PPM 에서는 공식적으로 Win32 환경에서 PAR::Packer 는 컴파일 오류가 발생하는 것으로 되어 있습니다. PAR 의 경우에도 현재 최신 버전은 1.005이지만 등록은 1.002까지만 되어 있습니다. 다만 이 경우는 컴파일 실패가 아니라 아직 컴파일 및 테스트가 진행되지 않았기 때문인 점을 유의하시기 바랍니다.<br/><br/>[첨부 이미지가 있습니다.]<br/><br/>따라서, PPM 으로 5.10.1 버전에서 PAR::Packer 바이너리를 구하려면 bribes.org PPM 레퍼지토리를 이용하여야 합니다. 여기에서 제공되는 버전 역시 0.991 버전입니다.<br/><br/>참고로, trouchelle PPM 레퍼지토리를 이용하면 PAR::Packer 1.008 버전을 다운로드 받을 수 있습니다만, 필자의 경우에는 적용시켜 본 결과 오류가 발생하여 실행 바이너리의 빌드가 불가능하였습니다.<br/><br/>(bribes, trouchelle 모두 ActivePerl 5.10 버전의 Perl Package Manager 를 이용하여 연결이 가능합니다.)</div><br/><br/>다운로드 받은 소스 파일의 압축을 푼 후, myldr/mktmpdir.c 파일을 찾아서 텍스트 에디터로 (읽지 못할 걸 알면서도) 열어보았습니다. <br/><br/><div style="margin: 10px; padding: 10px;">&nbsp;&nbsp;&nbsp; /* "$TEMP/par-$USER" */<br/><br/>&nbsp;&nbsp;&nbsp; stmp_len = <br/>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;strlen(tmpdir) +<br/>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;strlen(subdirbuf_prefix) +<br/>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;strlen(username) +<br/>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;strlen(subdirbuf_suffix) + 1024;</div><br/><br/>다행히, 파일에 주석이 잘 달려 있어서 쉽게 찾을 수 있었습니다. 아무리 C 를 모르는 저이지만, Perl 로 굴러먹던(..) 통밥으로 찾아보니 대충 뭐가 어떻게 돌아가는지는 알겠더군요. 그래서 위 코드 바로 앞에 이렇게 한 줄을 추가했습니다. 경로를 만들기 바로 직전에, username 을 강제로 OwlNetworks 로 변경하는 코드를 삽입한 것입니다.<br/><br/><div style="margin: 10px; padding: 10px;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;/* Temporarily fixed Korean(CP949/UTF16LE) Encoding Problem */<br/><br/>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;username = "OwlNetworks";</div><br/><br/>[첨부 이미지가 있습니다.]<br/><br/>이제 이 코드를 컴파일만 하면 됩니다. MinGW 가 설치된 상태이므로 gcc 컴파일러가 존재하기 때문에 충분히 가능한 작업입니다. CPAN 을 사용하지 못하지만, 이런 경우에는 일반적으로 (다 되는 것은 아닙니다) 아래와 같이 4줄의 명령어를 입력하면 됩니다.<br/><br/><div style="margin: 10px; padding: 10px;">perl makefile.pl<br/>dmake<br/>dmake test<br/>dmake install</div><br/><br/><br/><u>(3) PAR::Packer 의 컴파일 과정에서 겪은 오류들</u><br/><br/>그런데, 세 번째 과정인 dmake test 과정에서 자꾸 묘한 오류가 발생했습니다. 전혀 예상 못한 상황이었지요.<br/><br/>[첨부 이미지가 있습니다.]<br/><br/>t/20-pp.t 의 테스트 과정 중 31번째와 32번째에서 오류가 계속 오류가 발생합니다. <br/><br/><div style="margin: 10px; padding: 10px;">31st: No resource section found in file ~~~~ at C:/usr/site/bin/Win32/Exe.pm line ~~~.<br/>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Can't call method "remove" on an undefined value at C:/usr/site/bin/Win32/Exe.pm line ~~~.<br/>32nd: Failed test.</div><br/><br/>혹시나 싶어서 그대로 dmake install 을 수행한 후 스크립트의 컴파일을 시도하였으나, 위 31번의 오류 메시지와 같은 내용의 오류를 내면서 빌드에 실패하였습니다.<br/><br/>[첨부 이미지가 있습니다.]<br/><br/>Win32::Exe 모듈의 No resource section found in file 메시지로 구글링을 해 보니, 이 오류, 여러 사람 머리를 복잡하게 만든 오류더군요. 실행 파일을 만드는 과정에서 사용하는 Win32::Exe 모듈과 PAR::Packer 모듈 사이의 궁합 문제인 듯 한데, PAR::Packer 버전 및 Win32::Exe 의 버전에 따라서 발생하기도 하고 발생하지 않기도 하는 기묘한 문제였습니다. 구글링상에 나타나는 대부분의 문제는 Win32::Exe 버전 0.14 에서 발생하는 문제였는데, 제 경우는 Win32::Exe 버전 0.17 (최신 버전) 인데도 이런 문제가 발생했습니다.<br/><br/>직접 문제를 해결할 능력이 안 되기 때문에, 할 수 있는 것은 오류가 해결된 PAR::Packer 버전을 찾는 방법 뿐이었습니다. PAR::Packer 의 <a href="https://metacpan.org/source/RSCHUPP/PAR-Packer-1.012/ChangeLog" target="_blank">Change Log</a> 를 열심히 뒤졌습니다.<br/><br/>[첨부 이미지가 있습니다.]<br/><br/>1.005 버전에서 해당 오류가 해결된 것으로 나오는군요. 그래서 1.0.5 버전을 다운로드 받은 후 같은 내용으로 수정을 합니다. 그리고 컴파일. 어라? 이번엔 아예 dmake 과정에서 parldyn.exe 가 없다는 오류가 뜹니다. 제길.<br/><br/>[첨부 이미지가 있습니다.]<br/><br/>다시 <a href="https://metacpan.org/source/RSCHUPP/PAR-Packer-1.012/ChangeLog" target="_blank">Change Log</a> 를 뒤집니다. 바로 위에 있습니다. 좀 자세히 볼 걸.<br/><br/>[첨부 이미지가 있습니다.]<br/><br/>1.006 버전의 소스를 다운로드 받아 myldr/mktmpdir.c 의 해당 부분을 수정한 후 다시 컴파일합니다. dmake test 도 무사히 통과합니다. dmake install 을 수행한 후 테스트를 수행합니다. 무사히 실행 바이너리가 만들어집니다. 실행도 잘 됩니다. 압축이 풀리는 임시 폴더도 강제 지정한 대로 잘 만들어집니다.<br/><br/>이제 실전 테스트만 남았습니다. VMWare Player 를 이용하여 사용자 이름이 한글인 윈도우 XP 를 기동한 후 실행해 봅니다. 아래 그림과 같이 매우 잘 실행됩니다. 만세!<br/><br/>[첨부 이미지가 있습니다.]<br/><br/><div style="margin: 10px; padding: 10px;">참고로, 앞의 (1) 에서 시도한 바 있는, 사용자 이름으로 TEMP 폴더의 경로를 만드는 서브루틴이 포함된 두 개의 PL/PM 파일은 수정하지 않아도 됩니다. 이 두 파일은 빌드 과정에서는 사용되지 않습니다. (실행 파일을 만들지 않고 단순히 par 파일을 만들거나, standalone pl 파일을 만들 때에는 이 코드가 사용이 됩니다.)</div><br/><br/><br/><br/><br/><br/><B><u>4. 남은 이야기</u></B><br/><br/><br/><br/>사실, 이 부분을 제대로 해결하자면, 해당 코드 부분에서 사용자 이름의 인코딩을 확인하여 적절히 처리를 해 주도록 변경하는 것이 정석이겠습니다. 그러나 앞에서도 말한 바와 같이 저는 C 언어를 모릅니다. 게다가 C 에서의 인코딩 처리가 Perl 처럼 간단(?)하지 않다는 것은 아무리 저라도 익히 짐작할 수 있습니다. 그래서, 일단 임시방편으로 이와 같은 방법으로 처리를 하였습니다.<br/><br/><div style="margin: 10px; padding: 10px;">실제로 1.013 버전에서는, 사용자 이름이 한글인 경우 이를 16진수로 변환하여 영문자-숫자 형태로 변경한 후에 사용하도록 패치되었습니다. (2012-03-27 추가)</div><br/><br/>제가 PAR::Packer 를 다시 컴파일하는 과정에서 겪은 오류들은, 어떤 버전의 Perl 및 모듈을 선택하느냐에 따라 겪게 될 수도, 아닐 수도 있습니다. (제 경우 ActivePerl 5.10.1.1007, PAR 1.002, PAR::Packer 1.006, Win32::Exe 0.17 의 조합으로 성공하였습니다. ) 만약 오류가 발생하는 경우 PAR::Packer 의 버전을 변경해 가면서 여러 버전에서 확인을 해 보셔야만 합니다. <br/><br/><div style="margin: 10px; padding: 10px;">참고로, 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의 경우 제 시스템에서는 오류가 발생하였습니다.</div><br/><br/><br/><br/><br/><br/><B><u>5. 덧붙임 (2012/01/30 추가)</u></B><br/><br/><br/><br/>이 글의 첫머리에 덧붙인 것과 같이, 이 문제는 PAR::Packer 가 사용자 이름이 한글인 경우를 충분히 고려하지 않은 문제로서, 이미 제작자가 이에 관한 패치를 하여 CVS에 반영하였기 때문에, 이 문제를 해결한 버전인 1.013 버전을 설치하면 해결됩니다.<br/><br/>그러나 필자는, 위와 같은 패치 방법은 다른 용도로 이용할 수 있다고 생각합니다. 그래서 이에 관한 이야기를 조금 더 해 보고자 합니다. 이하의 이야기는 PAR::Packer 를 패키징 도구로 사용하는 Perl 개발자에게만 유용하며, 일반 이용자들은 읽을 필요가 없습니다.<br/><br/><br/><u>(1) PAR::Packer 의 임시 폴더 생성 방식의 무의미함</u><br/><br/>아마도, PAR::Packer 의 제작자가 패키지의 압축이 풀리는 폴더를 만들면서 그 폴더명에 사용자 이름을 넣게 된 이유는, Perl의 주 무대인 xNIX(유닉스/리눅스. 이하 편의상 리눅스 환경이라고 통칭하겠습니다) 환경이 여러 사람이 함께 사용하는 환경이기 때문에, 권한 문제나 여러 사람이 사용하는 패키지가 서로 섞이는 등의 여러 가지 문제를 미연에 방지하기 위함인 것으로 생각됩니다. (제 리눅스 환경에 대한 지식은 매우 일천한 관계로, 더 이상의 자세한 논의는 무리입니다.)<br/><br/>그러나, 윈도우 환경은 이런 리눅스 환경과 차이가 있습니다. 공용 컴퓨팅 환경인 리눅스 환경과 달리, 대부분의 윈도우 머신은 1인의 사용자가 사용하는 개인 컴퓨팅 환경입니다. 그래서 특별한 상황이 아니라면 다른 사람의 시스템 환경을 고려해야 할 필요성이 거의 없습니다. 게다가, 애초에 임시 폴더 자체가 사용자 별로 다르게 만들어지기 때문에, 시스템에서 주어지는 임시 폴더 경로를 그대로 받아 사용하기만 한다면 권한 문제가 발생할 여지가 없습니다. 따라서, 이런 PAR::Packer 의 임시 폴더 네이밍 방식은, 최소한 윈도우즈용 Perl 에 대해서는, "전혀"라고까지는 하지 않겠습니다만(개발 환경에서는 필요성이 있을 수도 있으니까) 최소한 만들어진 응용프로그램을 사용하는 사용자의 입장에서는 필요가 없는 절차라고 할 수 있습니다. 그냥 다른 프로그램에서 하는 대로, 프로그램 이름 (예를 들면 PAR-Packer) 으로 임시 폴더를 만들고 그 안에 압축을 풀면 될 일이죠.<br/><br/><br/><u>(2) 사고의 전환: 생산자/응용프로그램 구분으로의 활용</u><br/><br/>그러나, 이왕 만들어져 있는 코드, 이런 식으로 활용할 수도 있지 않을까 싶습니다. 기존의 사용자 구분의 용도로 만들어진 이 코드를, 코드 수정을 통해 프로그램 생산자 구분의 방식으로, 혹은 어플리케이션 구분의 방식으로 이용하면 어떨까 싶은 것이죠.<br/><br/>예를 들면 이런 것입니다. PAR::Packer 는 일단 임시 폴더에 풀린 패키지 파일들을, 패키징 시 특별한 옵션 (-C 옵션)을 주지 않는 한 삭제하지 않습니다. 2회차 이후의 실행에서 패키지를 다시 풀어놓는 시간을 절약함으로써 프로그램 실행 속도를 끌어올리기 위한 것이죠. 최초로 패키지를 풀고 해석하는 데 상당히 시간이 오래 걸리기 때문에, 이후의 실행 속도를 생각하면 이것은 상당히 효과적인 정책입니다. 그러나 이렇게 하면 일단 임시 폴더 내에 기록된 파일들이 사용자가 따로 삭제하지 않는 한 지워지지 않고 계속 남아 있기 때문에, 차후 프로그램을 삭제하거나 버전업을 하였을 때에도 이 내용들이 그냥 남아서 디스크의 용량을 차지하게 됩니다. 윈도우 안에 임시 폴더라는 게 있는지도 모르는 일반 사용자들이 널려 있는 판국에, 이것은 절대 좋은 상황은 아닙니다. 제 경우는 조금 큰 규모의 프로그램을 몇 번 버전업 했더니만 PAR::Packer 임시 폴더가 100메가바이트를 넘어가는 상황까지도 겪었습니다.<br/><br/>그렇다면 언인스톨러 비슷하게 임시 폴더 삭제용 툴을 따로 배포하면 되지 않느냐. 물론 그렇게 하는 것이 정답이겠지만, 이것이 그렇게 만만하지가 않습니다. 본문의 사진에서 한번 보여드린 바 있지만, PAR::Packer 는 [윈도우 임시 폴더]\[PAR-사용자 이름 폴더] 이하에 패키지들 간의 섞임을 막기 위해 한 번 더 temp-#####.. 와 같은 무작위의 임시 폴더를 만들고 그 안에 패키지의 압축을 풀기 때문입니다. 이 temp-#####.. 폴더의 이름을 알기가 어렵기 때문에, 그 프로그램에 대한 임시 폴더만 선택적으로 삭제하기가 상당히 까다로워집니다. 그냥 [PAR-사용자 이름] 폴더 자체를 날려 버려도 사실 일반 사용자 입장에서는 큰 문제가 없을 것 같기는 하지만, 이 역시 100% 문제가 없을 것이라고 장담할 수 있을지 모르겠습니다.<br/><br/>그래서, 이 사용자 이름을 입력하는 부분에, 제작자명 또는 프로그램명을 입력하면 어떨까 하는 생각을 해 보았습니다. 위에서 논의한 패치 방법을 이용하여 사용자 이름 대신 제작자명 또는 프로그램명을 입력한 후 PAR::Packer 를 다시 컴파일하면, 그 환경에서 제작된 프로그램은 항상 지정된 폴더명으로 임시 폴더를 만들게 되므로, 패키징할 때에 -C 옵션을 사용하지 않더라도 차후 임시 폴더를 관리하는 데 (언인스톨러를 제공하는 데) 상당히 좋은 환경이 만들어지게 됩니다. 프로그램별로 혹은 제작자별로 독립적으로 만들어지는 정해진 폴더를 별다른 위험 부담 없이 살포시 날리면 되기 때문입니다.  ]]>
		</description>
		<category>Perl</category>
		<category>PAR::Packer</category>
		<category>Win32</category>
		<category>한글 사용자 이름</category>
		<pubDate>Sun, 25 Dec 2011 00:04:22 +0900</pubDate>
	</item>
	<item>
		<title>
		<![CDATA[  당황스러운 제안, 그리고 거절의 이유. (by 부엉이)  ]]>
		</title>
		<link>http://www.nightowl.pe.kr/oblog/article/409</link>
		<guid>http://www.nightowl.pe.kr/oblog/article/409</guid>
		<description>
			<![CDATA[  얼마 전에 조금 당황스러운 제안을 받았다. 우리 회사에서 함께 일해보지 않겠느냐는, 일종의 입사 권유였다. IT보안 관련 업을 하는 회사인 듯했는데, (국내 환경상) 특이하게도 Perl 프로그래머를 구인하고 있었다. 중소기업이 인력을 구인할 때 관련 커뮤니티 등에서 정보를 얻는 경우가 많다는 이야기는 듣고 있었지만, 내가 그 대상이 될 것이라고는 전혀 생각도 안 하고 있었기에, 사실 조금 놀랐다.<br/><br/>뭐, 덕분에 하루 내내 고민했다. 일단 내 Perl 실력이 현업에서 쓸 정도가 아니라는 점은 분명하다. 같은 코딩에도 몇 배의 시간이 걸릴 것은 자명하고, 무엇보다 전공자가 아니기에 시스템에 대한 지식수준이 심각하게 부족할 것이 예상된다. 한마디로 사상누각. 그러나 이런 것은 회사측에서 알고 뽑는다면 문제가 아니다. 하드트레이닝을 통해 알아서 키워주겠다는 이야기일테니. 즉, 내가 걱정할 문제가 아니다.<br/><br/>진짜 고민은 다른 데 있었다. 이 선택을 나 스스로 정당화할 수 있을까(나 자신을 설득할 수 있는가)의 문제였다. 지금 이 시점에서 진로를 변경한다는 것은, 나의 전공, 그동안 공부해온 것, 인생의 목표들을 모두 백지화하고, 내가 가진 식견으로는 미래가 어떠할 지 짐작할 수 없는 분야로 뛰어드는 것을 의미한다. (지난 11년간의 공부가 모두 무로 돌아간다.) 사실 가진 것도 없지만, 그나마 내가 가지고 있는 것들을 모두 내려놓고 뛰어들어야 하는 것이다. 그렇다면 내가 포기해야 하는 것들과, 그로 인해 내가 얻을 수 있는 것을 잘 저울질해봐야 한다.<br/><br/>객관적 측면에서, 중소기업이니 연봉이나 근무환경이 좋은 수준은 아닐 것은 이미 짐작하고 있지만, 일단 생활이 가능한 수준이라면 장기적으로는 몰라도 단기적으로는 큰 문제는 안 된다. 사회통념으로 볼 때 무언가 새로운 것에 장기적으로 도전할 만한 나이는 아니지만, 업계에서 전문가로 성장하고 입지를 다질 수 있다면 어느 정도의 시간과 노력을 투자하지 못할 것은 없다. 그러나 협소하기 그지없는 국내 Perl 업계의 현실을 생각하면, 업계에서 자리를 잡을 수 있을 것인지 여부도 사실 불분명하다. 주관적 측면에서 보더라도, 지금은 취미생활로 하는 코딩이니 공부하는 와중에 짬짬이 하는 코딩이 즐거울 수 있지만, 이것을 업으로 하면서 최소한 같은 수준의 만족을 얻을 수 있을지는 의문이다. 결론은, 지금 당장 취업할 수도 있다는 점을 제외하고는 별다른 메리트가 없는 것이다.<br/><br/>이렇게 생각하면 사실 오래 고민할 일도 아니지만, 무려 하루가 지나서야 거절의 쪽지를 보낼 수 있었다. 그만큼 당장의 "취업"이라고 하는 것의 무게가 너무 무거웠다. 거듭된 시험 탈락과, 관련분야가 아니면 서류통과조차 장담할 수 없는 엄혹한 취업환경을 직접 겪으며, 한 달 전 결국 시험급수까지 변경하는 선택을 했던 나에게는, 지금 당장이라도 일할 수 있다는 것 자체가 매력적인 선택지였던 것 같다. <br/><br/>뭐, 결국 거절했다는 점에서 본다면 아직 내가 내려놓을 게 많다는 의미가 되겠고, 거절하는 데 오랜 시간이 걸렸다는 점에서 본다면 최근 몇 명에게서 들은 이야기인 "떨어진 자신감의 회복이 시급하다"는 이야기가 되겠지. 어찌 되었건, 이렇게 내 인생의 갈림길을 하나 더 지나쳤다. 가지 않은 길이 회한으로 남지 않으려면, 좀 더 정신줄을 잡아야 되겠다.<br/><br/><br/>p.s.<br/><br/><br/>같이 고시 준비를 하는 누구 말마따나, 고시를 하는 블로거가 한동안 포스팅이 없다면, 열심히 공부를 하느라 포스팅할 시간이 없다기보다는, 반대로 공부를 열심히 안 해서 늘어지는 상황이라 (귀차니즘에) 포스팅을 안 하는 경우가 더 많은 것 같다.<br/><br/>.......거기에는 나도 해당되려나.  ]]>
		</description>
		<category>이런저런 이야기</category>
		<category>입사제의</category>
		<pubDate>Wed, 21 Dec 2011 05:17:44 +0900</pubDate>
	</item>
	<item>
		<title>
		<![CDATA[  렛츠노트 R6A 발열 잡기 프로젝트 (by 부엉이)  ]]>
		</title>
		<link>http://www.nightowl.pe.kr/oblog/article/408</link>
		<guid>http://www.nightowl.pe.kr/oblog/article/408</guid>
		<description>
			<![CDATA[  <div style="margin: 10px; padding: 10px;">이 글은 렛츠노트 사용자 모임인 싸이월드의 레츠월드에 올린 게시물을 조금 더 다듬고 내용을 추가한 것입니다. 원 글의 링크는 다음과 같습니다:<br/>☞ http://club.cyworld.com/50258550157/115595502</div><br/><br/><br/><br/><br/><B><u>1. 서론</u></B><br/><br/><br/><br/>방열을 위한 팬이 없는 모델인 렛츠노트 모델에 있어서 원활한 발열은 정말 중요한 일이지만, 특히 제가 쓰고 있는 모델인 R6 모델의 경우 팬리스 모델 중 마지막 모델로, 특히 발열 및 방열에 관한 이슈가 많은 모델입니다. 제 경우에도, 인터넷 영상강의나 기타 영상을 돌리면서, R6A의 클럭다운 현상은 은근히 저를 괴롭히는 문제 중 하나였습니다. 웬만한 영상을 돌리면 기본으로 코어 온도가 85도 또는 그 이상을 찍어주는데다, 시스템 상황에 따라 백그라운드에서 뭐 하나 돌아가기라도 하면 그대로 88도 이상으로 치솟아 버리기 때문입니다. 이쯤 되면 자체 보호 기능에 의해 (안 그래도 느린) CPU 클럭이 순차적으로 다운이 되면서 시스템 속도가 말도 안 되게 느려지게 되죠. 그래서 많은 분들이 이런저런 방법으로 방열을 촉진하곤 합니다. 그리고, 저도 뒤늦게 합류했습니다.<br/><br/>이미 방법은 알고 있었습니다. 키보드를 들어낸 후 키보드와 CPU 사이에 구리판 등을 덧대어 CPU와 방열판이 밀착되도록 눌러주는 방법을 이미 많은 분들이 시도하셨기 때문에, 그에 대한 자료도 많이 있는 편입니다.<br/><br/>☞ 대표적인 방법: http://club.cyworld.com/50258550157/113790373<br/><br/>다만, 이 방법을 사용하기 위해서는 R6의 분해가 필수적으로 필요한데, 손재주가 그렇게 좋지 못한 저로서는 위험 부담이 큰 작업이라 (노트북의 분해 자체가 쉬운 일은 아닌데다, 특히 파나소닉 계열의 노트북들은 분해시 잘못 분해하면 여기저기 작살이 나도록 제작사측에서 부려놓은 꼼수가 많이 있어서, 제대로 아는 사람이 아니면 분해할 수 없습니다. 위 게시물에 보면 R6 노트북을 혼자서 분해할 수 있는 가이드가 있습니다.) 국내에서 렛츠노트 계열 노트북을 제대로 수리할 수 있는 몇 안되는 곳 중 하나인 노트AS(http://www.noteas.com/)에 의뢰를 했습니다. (이미 지난번 하드 교체 때도 이용했었던..)<br/><br/><br/><br/><br/><B><u>2. 작업의 요지</u></B><br/><br/><br/><br/>미리 연락을 드리고 오후에 방문했습니다. 전에 하드 디스크 교환하러 갔을 때는 안 계시던 분이 계시더군요. 저는 위 글에 있는 대로 은박지 덧대기나 구리판 덧대기 신공 정도를 생각하고 갔던 것인데, 이 분께서 레츠를 뜯고 여기저기 살펴보시더니 이 방법이 문제가 좀 있다고 말씀을 하십니다. 말씀인즉슨, 레츠노트의 키보드 쪽이 약한 탓에, 은박지나 구리판 등을 끼워넣으면 당장은 효과를 보겠지만, 결국은 (키보드 쪽이 그 모양으로 움푹 들어가면서) 끼워넣은 것이 그 안에서 자리를 잡아버릴 것 같고, 그러면 결국 효과가 거의 없게 될 것 같다는 말씀을 하셨습니다. <br/><br/>그래서, 단지 누르는 것만으로 효과를 볼 수 있다면, 얇은 스테인리스 판을 히트싱크 위에 덮개처럼 덧대어서, 키보드와 관계 없이 자체적인 누르는 힘으로 눌러주는 것이 좋겠다. 스테인리스 재질이 얇지만 강하고 또 이렇게 붙였을 때에 누르는 힘이 세다. 이렇게 해 보면 어떻겠느냐 하셔서, 그럼 그렇게 해 달라고 말씀드렸습니다.<br/><br/>[첨부 이미지가 있습니다.]<br/><br/><br/>중앙의 홀 가운데 볼록 튀어나온 곳이 CPU 위치입니다. 히트싱크와 CPU가 있겠죠. 여기를 스테인리스 판으로 눌러주기 위해 네 면에 양면테이프를 붙였습니다. 양면테이프가 약할 것 같지만, 다시 위에 보호테이프를 붙이기도 할 것이고, 또 키보드 작업 등에 의해서도 계속 눌리기 때문에 일단은 충분한 접착력이 있는 양면테이프를 사용한다면 문제는 없습니다. 볼록 튀어나온 곳 한복판에 그리스를 바른 후 스테인리스 판 (사이즈에 맞춰 자른) 을 덮어서 붙였습니다.<br/><br/>[첨부 이미지가 있습니다.]<br/><br/><br/>이제 CPU 부분이 덮인 상태입니다. 이제 저 스테인리스 판이 CPU 위쪽을 계속 눌러줄 것입니다. 노트AS의 기사님께서 직접 자르신 스테인리스 판이라, 사이즈가 정확히 맞습니다. (구멍은 별 의미 없습니다. NoteAS 내에서 굴러다니는 스테인리스 조각을 잘라 쓴 것이라서...)<br/><br/><div style="margin: 10px; padding: 10px;">참고로, 현재 이 사진에는 나오지 않습니다만, 접착된 스테인리스 조각에 요철(접착 전에 드라이버 등을 스테인리스 조각 한가운데 대고 망치 등으로 한번 탕. 구멍을 내는 것이 목적이 아니라 튀어나온 요철을 내는 것이 목적입니다)을 내어서 CPU 히트싱크를 좀 더 강하게 누르도록 할 수도 있습니다. 이 부분도 기사님께서 나중에 해 주신 부분인데, 요철을 낸 사진을 못 찍었네요.</div><br/><br/>이제 저 위에 기존에 붙어 있던 보호테이프(?)를 다시 붙입니다. 요철을 내지 않은 경우 키보드 재조립 후에도 키보드 위쪽으로 튀어나온 느낌이 없으며, 요철을 낸 경우에는 F1,F2,F3,2,3,4 키 부분에서 키보드가 원래보다 살짝 위로 솟이 있는 것이 느껴집니다. 아래 사진은 요철을 낸 경우의 사진인데, 사진으로는 잘 구분이 가지 않습니다. 자세히 보시면 F1-F3 부분이 살짝 올라가 있는 것이 느껴지실 것입니다.<br/><br/>[첨부 이미지가 있습니다.]<br/><br/><br/><br/><br/><B><u>3. 효과</u></B><br/><br/><br/><br/>적용전 인터넷 강의나 영상 시청(단일작업) 시 86-88도 정도를 기록했었습니다. 여기에 뭐 하나 백그라운드로 돌아가기라도 하면 바로 클럭다운에 거의 시스템 다운상태가 되는 거였죠. <br/><br/>작업 후 인터넷 영상강의를 4시간 정도 돌려본 결과, 인터넷 강의 들으면서 최고 온도는 77도입니다. 그것도 얌전히 강의를 들은 게 아니라, 강의 들으며 1.2-1.8배속으로 배속조정을 수시로 하고, 30초 앞으로 이동 등을 꽤 자주 이용하는 등 상당히 무리를 준 결과가 그렇습니다. 얌전히 정배속으로 강의만 듣고 있을 때에는 70도 근처에서 움직입니다. 대략 10-15도 정도의 코어 온도 하락 효과가 있는 셈입니다. 인터넷 작업 (익스플로러 창 다섯개 띄운 상태) 중 온도 63도 정도. 물론, USB 장치 등이 더 붙은 상태라면 조금 더 올라갑니다.<br/><br/>또한 발열이 피크로 올라갔더라도, 잠시 휴식시간을 주면 금세 온도는 다시 원상태로 복구됩니다. 방열설계가 굉장히 잘 되어 있는 증거라고 기사님이 말씀하시네요.<br/><br/>참고로, CPU 온도는 RM Clock 2.35 버전으로 확인한 결과이며, 현재 사용중인 OS는 윈도우 7 Professional 입니다. 대체로 윈도우 7이 XP보다 발열을 좀더 심하게 유발하기 때문에, 윈도우 XP 라면 더 낮을 수도 있습니다.  ]]>
		</description>
		<category>컴퓨터 사용 경험</category>
		<category>렛츠노트</category>
		<category>방열</category>
		<category>LetsNote</category>
		<category>R6A</category>
		<category>발열</category>
		<pubDate>Mon, 12 Dec 2011 20:42:59 +0900</pubDate>
	</item>
	<item>
		<title>
		<![CDATA[  Perl / Win32::GUI / BrowseForFolder : 폴더 선택 창에서 새 폴더 만들기 구현 (by 부엉이)  ]]>
		</title>
		<link>http://www.nightowl.pe.kr/oblog/article/407</link>
		<guid>http://www.nightowl.pe.kr/oblog/article/407</guid>
		<description>
			<![CDATA[  <br/><br/><B><u>1. Win32::GUI의 폴더 선택 창에서 새 폴더 만들기?</u></B><br/><br/><br/><br/>Win32::GUI 는 그 자신의 GUI 환경에서 사용자가 특정한 폴더를 선택할 수 있도록 BrowseForFolder 함수를 제공합니다. 상당히 익숙한, 다음과 같은 창을 열고 사용자가 선택한 폴더까지의 절대 경로를 돌려주게 되죠.<br/><br/>[첨부 이미지가 있습니다.]<br/><br/>그런데, 이 기능에는 한 가지 아쉬운 점이 있습니다. 위 이미지를 보면 바로 눈치챌 수 있으실 텐데, 윈도우 XP 이후의 윈도우즈에서 (당연히) 가능한, 새 폴더를 만든 후 해당 폴더를 선택할 수 있는 [새 폴더 만들기] 버튼이 보이지 않습니다. 그래서 특정한 작업을 수행할 폴더를 지정하기 위해서는 미리 윈도우 탐색기 등을 이용하여 폴더를 만들어 놓고 폴더 선택을 해야 하죠. 은근히 불편합니다.<br/><br/>처음 이 기능(BrowseForFolder)을 사용했던 건 2010년 초 간단한 확장자 변경 프로그램을 만들면서였는데, 이 때는 폴더 만들기 기능이 필요가 없었습니다. 특정한 폴더 안에 들어 있는 모든 .AVI 파일의 확장자만 .SVI 로 바꾸는 프로그램이었기 때문이죠. (똑같은 파일인데도 .AVI 확장자는 거부하고 .SVI 확장자만 받아먹는 망할 눔의 삼성 Yepp Player 때문에... 뿌득) 그런데, 2010년 후반에 M3U Copier 라는 프로그램을 짜기 시작하면서(.M3U 파일 목록에 있는 모든 MP3 파일을 특정한 폴더로 복사해 주는 프로그램입니다), 복사할 대상 폴더를 정할 때에 폴더를 만들 수 있다면 훨씬 편리하게 쓸 수 있다는 사실을 깨달았지요.<br/><br/>문제는, Win32::GUI 의 BrowserForFolder 함수를 아무리 뒤져봐도, 새 폴더 만들기를 지정할 수 있는 방법이 없었다는 것입니다. 구글링을 해 보니, 저와 같은 문제를 겪은 사람이 메일링 리스트에 문의를 한 것이 있었는데, (외국에선 요즘도 Win32::GUI 를 그럭저럭 많이 사용하나 봅니다.) 결론은 Win32::GUI 1.06 버전에서 이 기능을 사용하는 것은 불가능하다. 라는 것이었습니다. [<a href="http://www.mail-archive.com/perl-win32-gui-users@lists.sourceforge.net/msg05814.html" target="_blank">참고 링크</a>]<br/><br/><div style="margin: 10px; padding: 10px;">참고로, <B><u>현재 CVS 에 올라가 있는 최신의 Win32::GUI 코드에는 이 기능이 포함</u></B>되어 있습니다. (개발자가 이 질문을 보고 이 기능을 코딩해 넣었더군요. 2011년 7월에 CVS 에 Commit 되었습니다.) 그러나 아직 이 기능이 포함된 새로운 Win32::GUI 가 빌드되지 않았기 때문에, 이 기능을 당장은 사용할 수 없습니다. 필자가 컴파일한 최신 CVS 버전의 Win32::GUI 1.06 PPM 파일(Perl 5.10/5.14 버전)을 여기에 링크해 두겠으니, 필요하신 분은 사용하시기 바랍니다. 다만, 정식으로 공개된 버전이 아니기 때문에 예상치 못한 문제가 발생할 수도 있으므로, 이 점은 각자의 위험 부담으로 해 주시기 바랍니다.<br/><br/>5.10 : [첨부 파일 링크가 있습니다.]<br/>5.14 : [첨부 파일 링크가 있습니다.]</div><br/><br/><br/><br/><br/><br/><B><u>2. 정말 방법이 없는 것일까? Win32::API? Win32::FileOp!</u></B><br/><br/><br/><br/>그 덕분에, 최근까지 이 기능을 사용한 제 모든 프로그램에는, 폴더 선택 창에서 새 폴더를 만드는 기능이 없었습니다. 그러나 생각해보면 아예 방법이 없는 것은 아닙니다.<br/><br/>이를테면, (아직 글로 직접 쓰지는 않았지만, 곧 쓸 예정인) Win32::Clipboard 에서는 지원하지 않는, 텍스트가 아닌 이미지를 클립보드에 집어넣는 기능이 Win32::API 를 이용하여 윈도우 API를 직접 호출함으로써 가능했기 때문에, 역시 같은 기능을 하는 윈도우 API 인 SHBrowseForFolder (shell32.dll) 를 호출하면 이 기능을 사용 못할 바 아닙니다. (쓸 줄 모른다면 별문제이지만, 이미 한 번 Win32::API 를 사용하면서 대충 어떻게 쓰는지 감을 잡은 후입니다. 한번 쓴 기능, 두 번은 못 쓰겠습니까.)<br/><br/>그러나, 엉뚱한 데에서 더 쉬운 해결의 실마리가 잡혔습니다. CPAN을 검색하다가, Win32::FileOp 라는 모듈이 2011년 초에 한 번 버전업이 된 것을 우연히 알게 된 것이죠. 이 모듈은 이미 2010년 당시에도 알고 있었고, 실제로 확장자 변경 프로그램을 짤 때 사용했던 모듈이지만(그 이후에 Win32::GUI 내에도 이 함수가 있다는 걸 알고 굉장히 허무했었지요.), 2010년 당시 이 모듈의 최신 버전은 0.14.1 (2003년에 릴리즈) 이었고, 이 버전에서는 폴더 선택 창에서 폴더의 생성이 불가능했었습니다. 그러나, 2011년 1월에 0.16.0 버전이 릴리즈되면서 이 기능을 사용할 수 있도록 버전업이 되었더군요!<br/><br/><div style="margin: 10px; padding: 10px;">제가 사용하는 윈도우용 Perl 은 ActivePerl 5.10.1.1007 버전인데, 이 버전의 PPM 에서는 아무리 검색을 해 봐도 (현재도) 이 모듈의 최신 버전은 여전히 0.14.1 입니다. 그 덕분에 새 버전이 나온 지 1년이 다 지나도록 버전업 사실을 몰랐던 거였습니다. 이런...</div><br/><br/>덕분에, 다시 윈도우 API 레퍼런스를 뒤지면서 삽질해야 할 필요가 없어졌습니다. 바로 CPAN으로부터 Win32::FileOp 를 수동으로 업데이트한 후, 이 기능을 적용했습니다. 다음은 코드입니다.<br/><br/><br/><div style="margin: 10px; padding: 10px;"># msgOutput 서브루틴은 소스가 UTF-8 인코딩으로 되어 있는 관계로,<br/># UTF-8 Output 을 지원하지 않는 Win32::GUI 창에서 메시지가 깨지지<br/># 않도록 하기 위해 출력 전에 내부 UTF-8 인코딩을 euc-kr 인코딩으로<br/># 변경하는 기능을 하는 자작 서브루틴임을 참고하십시오.<br/><br/>sub BrowseForFolderNewUI {<br/><br/>    my $folder;<br/>    my $title = msgOutput("음악 파일을 복사할 폴더를 선택하세요.");<br/><br/>    use Win32::FileOp qw(:DIALOGS);<br/><br/>    $folder = BrowseForFolder( $title, CSIDL_DRIVES, BIF_USENEWUI );<br/><br/>    undef $title;<br/><br/>    return $folder;<br/>}</div><br/><br/>폴더가 선택되면 $folder 에는 선택된 폴더의 절대 경로(예: D:\My Documents\My Music) 가 반환되고, 폴더가 선택되지 않았다면 undef 가 반환되므로 실제 사용자가 폴더를 선택하였는지 여부를 즉시 확인 가능합니다. 실행한 결과는 다음과 같습니다. [새 폴더 만들기] 버튼이 떡하니 나타나 있죠.<br/><br/>[첨부 이미지가 있습니다.]<br/><br/><B><u>한 줄 요약 : 새 폴더 만들기 기능이 있는 폴더 선택 창을 사용하려면 Win32::FileOp 의 최신 버전을 사용하세요.</u></B><br/><br/><br/><div style="margin: 10px; padding: 10px;">[참고 링크]<br/><br/>Win32::FileOp 0.16.0 - [<a href="http://search.cpan.org/~jenda/Win32-FileOp-0.16.00-withoutworldwriteables/" target="_blank">CPAN 링크</a>]<br/>(.pm 파일만으로 구성된 모듈이고, 소스를 확인해 보면 Win32::API 를 이용하여 shell32.dll 의 SHBrowseForFolder 를 호출합니다. 의존성 있는 모듈이 존재하므로 설치 시 이들이 함께 설치되어야만 합니다.) <br/><br/>위 기능을 처음 사용해 본 .M3U Copier 프로그램은 다음 링크에 공개되어 있습니다.<br/><br/>.M3U Copier - <a href="http://www.nightowl.pe.kr/software/m3ucopier" target="_blank">http://www.nightowl.pe.kr/software/m3ucopier</a></div>  ]]>
		</description>
		<category>Perl</category>
		<category>Win32::FileOp</category>
		<category>Win32::GUI</category>
		<category>Perl</category>
		<category>BrowserForFolder</category>
		<pubDate>Sun, 04 Dec 2011 00:44:33 +0900</pubDate>
	</item>
	<item>
		<title>
		<![CDATA[  Perl / Win32::GUI::DIBitmap / Win32::Clipboard : 스크린샷 저장 시 저장되는 비트 수에 주의 (by 부엉이)  ]]>
		</title>
		<link>http://www.nightowl.pe.kr/oblog/article/406</link>
		<guid>http://www.nightowl.pe.kr/oblog/article/406</guid>
		<description>
			<![CDATA[  Win32::GuiTest 모듈의 SendKeys 함수를 이용하면, 현재 화면 캡쳐를 매우 간단하게 수행할 수 있습니다. PrtScr (Print Screen) 버튼을 누르면 현재 화면이 캡쳐되는 것은 이미 만인의 상식이 되어버렸으므로, SendKeys 함수를 이용하여 PrtScr 키를 입력하도록 해 버리면 되는 것입니다. 다만 이렇게 캡쳐된 화면은 클립보드로 들어가므로, 적절한 위치에 붙여넣기를 해 주어야 하겠지요.<br/><br/>제 프로그램 중에서 이 기능을 이용하는 프로그램이 두 개 있습니다. 하나는 클립보드의 내용을 선택적으로 저장해 두었다가 나중에 다시 쓸 수 있도록 하는 Clipboard Drawer 이고, 다른 하나는 스크린 캡쳐 & PNG 파일로의 저장을 마우스 클릭 한 번으로 처리하려 만든 PrintScreen & Autosave 입니다. (귀찮다는 이유로 더 귀찮은 짓을 해버리는 기묘한 인간을 보고 계십니다.)<br/><br/>* Clipboard Drawer : <a href="http://www.nightowl.pe.kr/software/clipdrawer" target="_blank">http://www.nightowl.pe.kr/software/clipdrawer</a><br/>* PrintScreen & Autosave : <a href="http://www.nightowl.pe.kr/software/prtscrsave" target="_blank">http://www.nightowl.pe.kr/software/prtscrsave</a><br/><br/>이렇게 클립보드로 들어간 데이터는 특정 CPAN 모듈 (Win32::Clipboard) 을 이용하여 불러온 후 파일로 저장할 수 있습니다. 바로 비트맵 파일로 저장도 가능하고, 만약 (저처럼) 디스크 용량 차지의 문제라던가, 기타 활용을 위해서 PNG 파일로 저장을 원할 수도 있습니다. 바로 비트맵 파일로 저장한다면 굳이 다른 모듈을 쓸 필요도 없이 데이터를 그대로 저장하면 되고, PNG 파일로 압축하여 저장하고자 할 때에는 제가 Win32::GUI 모듈을 이용하여 GUI를 구현하고 있으므로, (굳이 별도로 GD 모듈까지 동원할 필요 없이) Win32::GUI 모듈에 포함되어 있는 Win32::GUI::DIBitmap 모듈을 이용하면 됩니다.<br/><br/>그런데, 무신경하게 코드를 짜고 테스트를 하다가, 좀 미묘한 문제를 만났습니다. 예전에 PrintScreen & Autosave 프로그램을 만들어 테스트할 때도 발생했던가 싶은 문제인데 그동안 잊고 있다가, 최근 Clipboard Drawer 프로그램을 만들면서 똑같은 문제를 맞닥뜨렸습니다. 다음 그림을 보시죠.<br/><br/>[첨부 이미지가 있습니다.]<br/><br/>위 이미지는 현재 제 바탕화면을 찍은 것입니다. 위쪽 화면은 다른 프로그램을 이용해 저장한 스크린샷이고, 아래쪽 화면은 PrintScreen & Autosave (0.0.2.0) 프로그램으로 제 바탕화면을 찍은 것이죠. 뭔가 다릅니다. 지금 저렇게 보니까 그나마 이미지가 있어 보이는데, 정확히는 아래 그림의 하얗게 보이는 부분을 이미지 뷰어로 읽으면 죄다 투명 픽셀로 처리되어 보이지 않게 되어 버리는 것입니다. 예를 들면 아래와 같이 나온다는 거죠.<br/><br/>[첨부 이미지가 있습니다.]<br/><br/>대체 문제가 뭘까요? 일단 코드를 보시죠. PrintScreen & Autosave 프로그램의 해당 부분의 코드는 다음과 같이 되어 있습니다. 이미 캡쳐된 이미지는 클립보드에 들어와 있다고 가정합니다.<br/><br/><div style="margin: 10px; padding: 10px;"> 1: use Win32::GUI::DIBitmap;<br/> 2: use Win32::Clipboard();<br/> 3:<br/> 4: my $Filename = GetDateTime(time);<br/> 5: my $bitmap = Win32::Clipboard::GetBitmap();<br/> 6: my $dib = newFromData Win32::GUI::DIBitmap ($bitmap);<br/> 7: undef $bitmap;<br/> 8: <br/> 9: $dib->SaveToFile("$Filename.png", FIF_PNG ); # 알아서 저장하므로 FIF_PNG는 없어도 된다.<br/>10: undef $dib;<br/>11: undef $Filename;</div><br/><br/>GetDateTime 서브루틴은 그냥 지금 현재 날짜,시간을 확인하여 파일명으로 사용할 수 있도록 YYYYMMDDHHMMSS 의 형태로 돌려주는 서브루틴이므로 신경쓰지 않으셔도 됩니다. 라인 5에서 클립보드의 데이터를 비트맵으로 읽어오고, 이를 라인 6에서 다시 받아 Win32::GUI::DIBitmap 객체로 되돌립니다. 그리고 이를 라인 9에서 PNG 파일로 자동 변환하여 저장합니다.<br/><br/>코드 자체에는 아무런 문제가 없어 보입니다. (실제로 없습니다. 한번 실행해 보세요. 단 4열의 파일명 정하는 코드는 적절히 수정하시고요. 물론 Win32::GUI 와 Win32::Clipboard 모듈은 CPAN에서 받아서 설치하시고..) 그런데 이 코드로 스크린샷 찍었다 하면 저 위 그림과 같은 난리가 나 버립니다.<br/><br/>도대체 문제가 뭘까 하고 이것저것 찾아보다가, 바로 위 그림의 이미지 뷰어 - Imagine - 덕분에 문제 해결의 힌트를 얻었습니다. 아래 그림은 Imagine 에서 보여주는 상태 표시줄의 파일 정보인데, 위쪽 그림은 정상적으로 보이는 스크린샷 파일의 정보이고, 아래쪽 그림은 문제를 일으키는 스크린샷 파일의 정보입니다.<br/><br/>[첨부 이미지가 있습니다.]<br/><br/>원인은 24bit와 32bit의 차이였습니다. 즉, Win32::GUI::DIBitmap 모듈이 내부적으로 비트맵 데이터를 처리하는 과정에서 비트수를 늘린 덕에 이런 문제가 발생했다는 것입니다. 비트맵 이미지를 저장하기 전에 데이터를 강제적으로 24비트로 다운시키는 코드를 삽입한 후 문제가 해결되었습니다.<br/><br/><div style="margin: 10px; padding: 10px;"> 1: use Win32::GUI::DIBitmap;<br/> 2: use Win32::Clipboard();<br/> 3:<br/> 4: my $Filename = GetDateTime(time);<br/> 5: my $bitmap = Win32::Clipboard::GetBitmap();<br/> 6: my $dib = newFromData Win32::GUI::DIBitmap ($bitmap);<br/> 7: undef $bitmap;<br/> 8: my $to24bits = $dib->ConvertTo24Bits(); # 24비트로 비트 수 다운그레이드<br/> 9: undef $dib;<br/>10:<br/>11: $to24bits->SaveToFile( "$Filename.png", FIF_PNG ); # 알아서 저장하므로 FIF_PNG는 없어도 된다.<br/>12: undef $to24bits;<br/>13: undef $Filename;</div><br/><br/>정리하자면, 처음에는 비트맵 데이터를 막바로 BMP로 저장하다가, 스샷 하나에 3메가바이트씩 먹어대는 걸 보고 기가 질려서, 늘상 사용하던 모듈을 이용해 PNG 파일로 저장하도록 수정하려다가 겪은 묘한 문제였습니다.<br/><br/><B><u>한줄 요약 : Win32::GUI::DIBitmap 모듈로 Win32::Clipboard 모듈에서 읽은 클립보드 비트맵을 처리할 때는 반드시 24비트로 비트수 다운그레이드를 하세요.</u></B><br/><br/>** 이 글은 네이버 Perl Community & Study 카페에도 등록되어 있습니다.  ]]>
		</description>
		<category>Perl</category>
		<category>Win32::GUI</category>
		<category>24bpp</category>
		<category>Clipboard</category>
		<category>Win32::GUI::DIBitmap</category>
		<category>32bpp</category>
		<category>Win32::Clipboard</category>
		<category>클립보드</category>
		<pubDate>Thu, 24 Nov 2011 00:24:41 +0900</pubDate>
	</item>
	<item>
		<title>
		<![CDATA[  인터넷 컨텐츠 제작자 사용설명서 (by 부엉이)  ]]>
		</title>
		<link>http://www.nightowl.pe.kr/oblog/article/405</link>
		<guid>http://www.nightowl.pe.kr/oblog/article/405</guid>
		<description>
			<![CDATA[  <B><u>1. 서설</u></B><br/><br/>꽤 오랫동안 알고 지낸 자막제작자 녀석이 드디어(?) 한 소리 하고 나섰다. 새로 잡은 작품이 예상 외의 인기(?)를 끌면서 덤으로 (많은 숫자는 아니지만) 반갑지 않은 손님들까지 따라들어오신 모양인데, 자막이 늦게 나온다고 자막을 독촉하는 방문자들이 생긴데다, 자막이 늦는다는 이유로 인격모독 발언을 서슴지 않는 방문자까지 있는 모양이다. 무슨 빚 받으러 온 채권자도 아니고.<br/><br/>요즘이야 그런 일로 시달릴 일이 별로 없지만, 나도 인터넷상에 이것 저것 만들어서 공개해 온 입장에서, 사실 그 녀석의 속을 이해할 수 있을 것 같다. 무슨 갑-을 관계도 아닌데 이것저것 요구하고 따지고 드시는 분들 덕에, 속이 시꺼멓게 탔던 적이 두어 번 정도 있으니... 그런 이유로, 평소에 많이 생각을 하던 주제이기도 해서, 마침 계기도 생겼고 하니, 또 한번 내 생각을 풀어놓아볼까 한다. 일단 먼저, 인터넷 컨텐츠 제작자가 풍파에 망가져가는(...) 모습을 한 차례 조감해 보고, 그 원인과 해결 방안을 풀어보도록 할 것이다.<br/><br/><br/><br/><B><u>2. 인터넷 컨텐츠 제작자, 그들은 누구인가.</u></B><br/><br/>다 아는 사실이지만 짚고 넘어가도록 하자. 인터넷 컨텐츠 제작자(Internet Contents Creator/Provider,). 이렇게 라고 하면 무언가 거창해 보이는데, 사실 별 대단할 것도 없다. 인터넷 상의 공간에 자신의 창작물을 공개하는 사람들이라면 모두 다 인터넷 컨텐츠 제작자다. 창작물이 무엇인지, 얼마만큼의 시간과 노력이 투입되었는지, 금전적인 대가를 받는지 여부는 전혀 관계 없다. (오히려, 금전적인 대가를 받지 않는 사람이 거의 대부분이겠다. 영리목적의 회사가 아니라면.) 인터넷상에 그림, 음악 등을 만들어 공개하는 사람, 외국어로 된 컨텐츠를 번역해서 공개하는 사람, 유용한 프로그램을 제작하여 공개하는 사람 등이야 당연한 것이지만, 블로그에 잡문을 끄적이는 사람일지라도 그것을 이용하는-읽는-사람이 있다면 당연히 인터넷 컨텐츠 제작자의 범주에 포함시킬 수 있다.<br/><br/>그렇다면, 이 부류의 사람들은 무엇을 위해서 이런 일을 하는 것일까? 전혀 금전적인 이익을 얻을 수 없는(혹은 얻고 싶어하지 않는) 일에 시간과 노력을 투자하는 이 사람들의 심리는 과연 무엇일까? 개인마다 그 동기와 목적은 천차만별일 것이다. 개인적인 공부를 위해서, 미래의 직업을 위한 사전 준비로써, 단순한 개인적인 만족/보람을 위해, 누군가 필요한 사람이 있을 것 같아서, 그냥 유명해지고 싶어서 등등 백이면 백 그 동기는 제각각일 것이라고 생각한다. 그러나 어떠한 경우이든, 자신의 노력이 들어간 유무형의 결과물을, 그것을 필요로 하는 사람이 이용할 수 있도록 공개해 놓았다는 점에서는 어느 정도의 봉사 마인드가 내재되어 있다고 할 수 있다. (이하 인터넷 컨텐츠 제작자는 모두 "제작자"로 줄여서 쓰도록 하겠다.)<br/><br/><br/><br/><B><u>3. 무보수 노동으로 망가져가는 제작자</u></B><br/><br/>이제 인터넷 컨텐츠 제작자가 인터넷상에 등장하면서부터, 이들이 처참하게 사라지기까지의 과정을 조감해보도록 하겠다. 글이 조금 도발적일 수는 있지만, 누구나 크든 작든 결국 겪게 되는 일이어서 가감 없이 적기로 한다.<br/><br/>제작자라면 누구나 시작은 그러했을 것이다. 인터넷상에 공개된 자신의 컨텐츠를 누군가 이용하고 - 즐기고 - 있다는 사실만으로도 무언가 큰 일을 한 것 같은 보람을 느끼던 시절이 있었을 것이다. 컨텐츠 이용자들이 늘어가면서 어느 수준까지는 제작자도 신바람이 난다. 이용자들로부터 듣게 되는 격려와 감사의 말은 그 무엇보다도 큰 힘이 된다. <br/><br/>그러나, 그런 즐거운 시절은 생각보다 오래 가지 못한다. 자신의 컨텐츠를 이용해주는 사람이 늘어나면서, 해야 할 일도 하나둘 늘어간다. 여러 가지 요구들이 줄을 잇기 시작한다. 새로운 컨텐츠의 제작 요청, 기존 컨텐츠의 개정 요구, 이용자의 개인적인 요망사항 등. 처음 몇 번이야 조금 무리한 부탁이라도 즐겁게 들어줄 수 있다. 그러나 웬걸. 차츰 늘어나는 갖가지 요구사항들은 점점 부담으로 쌓이기 시작한다. 여가선용의 차원에서 시작한 일이 점점 본업을 잡아먹기 시작하고, 처음엔 그저 고맙기만 하던 컨텐츠 이용자들이 점점 스트레스의 원인요소가 된다. 제작자의 사정 따위 안중에도 없는 이용자들은 자신이 원하는 시기에 컨텐츠를 이용할 수 없다는 이유로, 혹은 자신의 요구를 들어주지 않는다는 이유로 듣기 싫은 소리를 풀어놓기 시작한다. 급기야는 욕설이 오가고, 싸움이 벌어진다. 이런 루프가 몇 번 반복되고 심화되면, 어느 순간 몸과 마음이 지친 제작자는 그동안 공개했던 모든 자료를 지우고 인터넷 세상을 등지게 된다. 이로서 또 한 편의 비극이 완성된다.<br/><br/>사실 대부분의 무료 인터넷 컨텐츠 제작자들의 작업의 동력은 나의 작업물이 누군가에게 도움(즐거움)이 되고 있다는 보람과 자부심일 것이다. 아무리 본인의 만족을 위해 작업을 한다 하더라도, 이런 부수적인 감정이 없다면 일을 계속해나가기 쉽지 않다. 그러나 어느 순간, 밀려드는 여러 가지 요구들은 이런 "봉사"를 "무보수 노동"으로 만들어버리곤 한다. 이용자의 요구에 맞추느라 무리하게 개인 시간을 쪼개 가며 무언가를 진행하다 보면, "내가 이 짓을 왜 하고 있나." 류의 생각에 짜증이 나게 마련이다. 이렇게 여가활동이 "무보수 노동"이 되는 순간, 그 컨텐츠는 생명력을 잃게 된다.<br/><br/><br/><br/><B><u>4. 비판과 비난 사이 - 제작자가 망가져가는 또 다른 과정</u></B><br/><br/>대개 영리를 목적으로 하지 않는 인터넷 컨텐츠 제작자들은 그 분야에 관심이 있는 아마추어인 경우가 많다. (일부 프로페셔널들이 자신의 여가선용을 위해 이런 활동을 하는 경우도 있으나, 그렇다고 해서 이 논지에 영향을 받지는 않는다.) 따라서 그 컨텐츠는 흠잡을 데 없는 작품이라기보단 어딘가 부족한 점이 보이는 그런 결과물인 경우가 보통이다. 인터넷 세상은 넓고, 특정한 분야에 뛰어난 실력을 갖춘 사람은 반드시 있게 마련인지라, 종종 컨텐츠 제작자에게 컨텐츠의 부족한 점이나 잘못된 점, 개선해야 할 점을 피드백해 주는 이용자들이 반드시 나타나게 되어 있다.<br/><br/>이런 피드백은 대개는 제작자에게는 큰 도움이 된다. 대개 무언가를 만드는 사람들에게는 묘한 고집이 있게 마련이라, 스스로의 의지로 작업한 결과물이 어딘가 부족한 점이 있다면 자신이 할 수 있는 한도 내에서는 최대한 이런 단점을 수정하려 한다. (개인적으로는 이걸 "쟁이 근성" 이라고 부른다.) 그것이 자신이 파악하지 못한 단점이라면 더욱 그러한데, 이런 과정을 통해서 컨텐츠의 완성도는 점점 더 높아지고, 제작자의 만족도 역시 상승곡선을 탄다. 그 반사적인 이익으로서 컨텐츠 이용자 역시 질적으로 더 나은 컨텐츠를 이용하게 되는 선순환이 발생하게 된다.<br/><br/>여기까지만 보면 참으로 아름다운 모습인데, 유감스럽게도 세상은 그렇게 만만하지가 않다. 익명성 속에 숨은 일부 컨텐츠 이용자들의 악의적인 피드백이 하나둘씩 섞여드는 게 문제이다. 뭐 하나 생산적인 내용은 없는, 비난으로 시작해서 비난으로 끝나는(예쁘게 표현해서 그렇지, 실상은 욕으로 시작해서 욕으로 끝나는) 피드백이 하나둘 쌓이다 보면 제작자는 "내가 뭣 때문에 이런 욕 들어먹어가면서 이 짓을 하고 있나."라는 생각이 들게 마련이다. 백 개의 격려와 도움이 되는 충고가 있더라도, 그 사이에 섞여 있는 한두 개의 악의적인 비난에 전체가 묻혀버리는 것은 제작자 역시 인간이기 때문에 겪게 되는 어쩔 수 없는 현상이다. 이렇게 점점 제작자는 회의주의자로 변해간다.<br/><br/><br/><br/><B><u>5. 화성에서 온 제작자, 금성에서 온 이용자.</u></B><br/><br/>제작자와 이용자가 갈등을 빚게 되는 표면적인 요인은 참으로 다양하다. 이용자들의 요구사항으로 인한 갈등, 컨텐츠의 낮은 질로 인한 갈등, 기타 이용자와 제작자 사이의 인간적인 갈등 등 참으로 다양한 형태로 갈등이 나타나곤 한다. 그러나, 이런 모든 갈등은 하나의 핵심적이고도 근본적인 요인으로 수렴될 수 있다고 생각한다. 바로 "특별함"을 둘러싼 서로간의 어긋남이다.<br/><br/>대부분의 컨텐츠 이용자들은 컨텐츠 제작자에게 있어 자신이 특별한 존재이길 바라며, 또한 자신이 실제로 특별한 존재라고 생각하는 경향이 있다. 자신에게 발생한 문제는 아무리 사소한 문제라도 커 보이게 마련이고, 그런 자신을 위해서 컨텐츠 제작자가 무언가 해결 방안을 제시해주기를 바란다. 그것도 빠른 시간 안에 해결이 되어야 한다. 꼭 나 혼자에게만 문제가 발생하는 것 같고, 수많은 사람들 사이에서 나 혼자만 손해보는 느낌이다. 그 결과, 해결이 늦어지거나 해결이 불가능한 상황이 되면 이유여하를 불문하고 안 좋은 감정이 생기는 건 인간이기에 어쩔 수 없는 일이다.<br/><br/>그러나 제작자의 입장은 다르다. 어떤 한 이용자는 자신의 컨텐츠를 이용하는 수 많은 사람들 중 한 사람일 뿐이며, 그 결과 그 사람은 제작자에게 있어서 전혀 특별한 사람이 아니다. 자신의 컨텐츠 이용자가 어떤 문제를 겪고 있다고 하더라도, 제작자에게 있어서 그 문제는 자신의 작업 목록에서 반드시 높은 우선 순위를 가져야 할 이유가 없다. 그 일이 아니라도 이미 수없이 많은 문제가 제작자를 괴롭히고 있을 수도 있다. 이런 와중에, 특정 이용자로부터 자신이 겪는 문제에 대해서 즉각적인 반응을 보이지 않는다는 이유로 싫은 소리를 듣는다면 제작자의 기분이 좋을 리 없다. 제작자는 오히려 그 문제의 해결을 가장 후순위로 밀어버리고 싶은 기분이 들 것이다.<br/><br/>이런 어긋남은, 자신의 감정에 충실할 수밖에 없는 인간으로서는 어쩌면 당연하다. 이는 당사자들의 지적 수준이나 양식과도 그렇게 큰 관계는 없어 보인다. 아니, 모든 것을 알고 이해하는 사람일지라도, 이런 경우를 당하면 "머리로는 이해하나 가슴으로는 이해하지 못하는"것이 인간의 본성일지도 모른다. 그리고 이런 불만이 일방이건 쌍방이건 표출되는 순간 갈등은 표면화된다.<br/><br/><br/><br/><B><u>6. 제작자에게는 어떠한 의무도 없다.</u></B><br/><br/>이 얽힐대로 얽혀버린 실타래를 어디에서부터 풀어나가야 할 것인가. 일단 제작자가 직업적으로 (갑-을 계약관계를 맺고) 금전적 대가를 받으면서 이 일을 하고 있는 것이 아님은 확실하다. 애초에 컨텐츠를 공개한 것도 단지 봉사일 뿐, 그것으로써 어떤 권리의무 관계가 생기는 것이 아니다. 설사 그 사람이 그 분야에 있어서 프로페셔널의 지위를 점하고 있는 자일지라도, 그가 어떤 대가를 받고 제공하는 컨텐츠가 아닌 이상 결론은 달라지지 않는다. 따라서, 컨텐츠에 어떤 문제가 있어서 이용자가 컨텐츠를 이용하는 데 장애가 발생한다 하더라도 제작자에게 이를 해결해 주어야 할 의무가 있는 것도 아니며, 이용자가 어떤 요구를 한다 하여 제작자가 이를 받아들여야 하는 의무도 없다.<br/><br/>물론 앞에서 잠깐 내비친 바 있지만, 대개의 제작자들은 묘한 "쟁이 근성"을 갖고 있게 마련이다. 스스로 자신의 이름을 걸고 자발적으로 시작한 일인 이상, 자신의 컨텐츠에 어떤 문제가 있다면 자신이 가능한 한도 내에서는 어떻게든 그 문제를 해결하려 한다. 묘한 고집이지만, 많은 컨텐츠 제작자들에게서 거의 공통적으로 볼 수 있는 특성이다. 그래서 보통은 이용자에게 일정한 피드백을 받길 원하고, 또 그러한 소통으로부터 즐거움과 보람을 얻곤 한다.<br/><br/>그러나 이것은 제작자의 일반적인 속성이라는 것이지, 이로부터 제작자가 "반드시" 이용자의 요구사항을 수용해야 한다거나, 질적으로 일정 이상의 수준을 갖는 결과물을 내놓아야 할 의무를 도출할 수는 없다. 제작자가 요구사항을 수용하지 않는다거나, 컨텐츠의 질이 수준 이하라고 하여 컨텐츠를 이용하려는 자가 제작자를 비난할 권리는 없다. 단지 해당 컨텐츠를 사용하지 않으면 될 뿐이다. 누가 그 컨텐츠를 꼭 쓰라고 강제라도 하던가?<br/><br/>물론 컨텐츠 이용자의 비판할 자유를 틀어막겠다는 것은 아니다. 사용해 본 컨텐츠가 수준 이하라거나, 어떤 문제점이 있을 때 이를 비판할 수 있는 자유는 일반적인 언론자유로서 보장되는 것이다. 그러나 그렇다고 하여 제작자를 인격적으로 비난하거나 모욕할 자유가 주어진 것은 아니다. 어떤 컨텐츠를 이용할 "권리"나, 어떤 컨텐츠를 이용해야 할 "의무"가 없는 이상, 본인이 그 컨텐츠를 사용하지 않는 수준을 넘어 해당 컨텐츠를 비난하고 싶다면 그 비난은 비난하는 자 스스로 정당화시켜야 한다. 제작자의 인격권과 공익이 조화를 이루는 범위 안에서 이루어지는 이유 있는 비판이라면 그런 비판은 얼마든지 정당화될 수 있다. 그러나 그 수준을 넘는 일방적인 비난과 모독은 제작자의 인격권을 심각하게 침해하는 불법행위로써, 그 수준에 따라서는 당사자가 민형사적인 책임을 감수해야 할 수도 있다.<br/><br/>착각하지 말자. 어떠한 사실이 있다고 하더라도, 그러한 사실로부터 반드시 그러해야만 하는 당위를 도출하기 위해서는 추가적인 논증을 필요로 한다. 제작자가 어떤 컨텐츠를 공개했다 하더라도, 그로 인하여 그에게 어떤 의무를 지울 수는 없다. 거창하게 "네티즌과의 약속" 운운하지 말자는 이야기다. 사실은 왜 내가 원하는 시기에 컨텐츠를 이용할 수 없느냐는 지극히 사적인 불만에 불과하면서, 왜 그렇게 애써 포장하나.<br/><br/><br/><br/><B><u>7. 결론. 인터넷 컨텐츠 제작자 사용설명서</u></B><br/><br/>사실 제목이 부적절하다. 제작자가 무슨 물건도 아닐진대, 사용설명서 운운하는 것은 자기 무덤을 파는 짓이나 마찬가지이다. 너무나 잘 안다. 그러나, 그럼에도 불구하고 이런 제목을 단 이유는, 최소한 이 정도는 기본적으로 알고 지켜줘야만 서로 윈윈할 수 있다는 강조의 의미에서이다. 이 정도도 서로간에 지켜주지 않으면 어느 사이엔가 몸과 마음이 고장나 있는 제작자를 보게 될 것이다. 블로그 폐쇄는 기본 옵션으로 따라오겠지. (^^)<br/><br/>* 독촉, 무리한 요구 금지. 제작자는 컨텐츠 제작을 직업으로 하는 사람이 아니다. 단지 여가선용으로써 하고 있을 뿐이다. 이 것 아니라도 안 그래도 바쁘다. 시간이 나더라도 쉬어야 할 때가 있다. 무슨 원고 마감 독촉하는 편집장처럼 왜 다음 컨텐츠가 안 나오냐고 독촉해 봐야 안 나온다. 성격 나쁜 제작자라면 오히려 이로 인해 그 일을 한없이 후순위로 밀어놓을지도 모른다. 아까도 이야기했지만, 당신은 절대로 특별한 사람이 아니다. You are not special. 컨텐츠를 독촉할 권리 같은 건 당신에게 없다.<br/><br/>무리한 요구 역시 마찬가지다. 어떤 문제가 있다면 제작자에게 피드백을 하는 것까지는 좋다. 이렇게 하면 더 좋겠다는 것들도 좋은 피드백 거리다. 그러나 거기까지다. 그에 대해 제작자에게 어떤 행동이나 답변을 바라지 말라는 것이다. 웬만큼 명예감정이 있는 제작자라면 들어온 피드백을 그냥 보아넘기지 않는다. 독촉하고 요구하지 않아도 안 그래도 짬짬이 머리 싸매고 고민 중일 것이다. 아니면 말고. 아니라도 할 수 없다.<br/><br/>* 마음에 들지 않는다면 사용하지 않으면 된다. 보통의 경우 그 컨텐츠를 이용하지 않더라도 다른 대체할 만한 컨텐츠가 어딘가에 있게 마련이다. 부족한 점을 피드백하는 것을 넘어서 인신 공격을 퍼부을 권한은 당신에게 없다. 아무리 질적으로 부족한 컨텐츠라도 집어 치우라고 말할 권한도 없다. 피드백할 가치도 없다고 생각한다면 그냥 조용히 뒤로 가기 버튼을 누르란 말이다. <br/><br/>누군가는 그레샴의 법칙 - 악화가 양화를 구축한다 - 을 들어 질 낮은 컨텐츠를 공격하곤 한다. 이 사람이 이런 질 낮은 컨텐츠를 만들지 않았으면 다른 누군가가 더 좋은 컨텐츠를 만들었을 텐데, 이 사람이 이런 것을 내놓는 바람에 다른 사람들이 더 좋은 것을 만들 생각을 안 한다는 논리다. 참으로 엉뚱한 데다 화풀이를 하고 있다. 이 사람이 안 만든다고 다른 사람이 만들어주리라는 보장은 어디에도 없으며, 게다가 대체물이 있다 하여 그것의 질이 원래의 그것보다 좋으리라는 보장도 없다. 이런 분들이 주로 하는 생각이 "너 아니라도 할 사람 많다." 다. 글쎄? 진짜로 할 사람이 없을 수도 있다. 이렇게까지 말하고 싶진 않지만, 본인이 능력이 있다면 한번 직접 해 보시라.<br/><br/>* 비판할 때 하더라도 비난은 자제하자. 정당한 비판도 듣지 않는 제작자, 있을 수도 있다. 대개는 속이 좁은 인간이거나, 아직 인격적으로 성숙하지 못하였거나, 혹은 제 잘난 맛에 사는 사람이다. 어떤 유형이든, 어차피 무슨 말을 해도 안 들을 사람이니 공연히 힘 빼지 말자. 감정적 비난과 인신공격이 등장하는 순간 조용하던 게시판은 싸움판이 된다. 여러 사람 피해주는 짓이다. 싸움 구경이 재미있는 사람도 있을 지 모르지만, 싸움 구경이 짜증나는 사람도 세상엔 많다. 어떤 사람은 열심히 제작자의 블로그나 공식 배포 페이지에까지 찾아와서 작정하고 싸움을 일으키는데, 민폐도 그런 민폐가 없다. 이건 아예 인터넷 세상의 사회악이다.<br/><br/><br/><br/>인터넷 생테계에 컨텐츠가 없다면 인터넷이 존립할 수가 없다. 그런 의미에서 인터넷 컨텐츠 제작자들은 인터넷 생테계를 떠받치고 있는 사람들이다. 이 사람들이 의욕을 가지고 활동할 수 있어야만 인터넷이 풍성해지고, 이용자들의 효용 역시 증가하게 마련이다. 게다가, 인터넷 세상은 절대 일방적으로 흐르지 않는다. 당신이 항상 인터넷 컨텐츠 이용자이기만 할 것 같은가? 인터넷의 특성상 당신도 언제라도 컨텐츠 생산자가 될 수 있다. 역지사지의 사고를 하지 않으면 언젠가 되로 주고 말로 받는 사태가 벌어질지도 모른다.  ]]>
		</description>
		<category>정리된 생각</category>
		<category>컨텐츠 사용자</category>
		<category>컨텐츠 생산자</category>
		<category>관계</category>
		<pubDate>Sat, 19 Nov 2011 02:22:41 +0900</pubDate>
	</item>
</channel>
</rss>

