<?xml version="1.0" encoding="utf-8" ?>
<?xml-stylesheet href="http://rss.egloos.com/style/blog.xsl" type="text/xsl" media="screen"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
	<title>아라크네 이글루</title>
	<link>http://arachneng.egloos.com</link>
	<description>나도 도쿄에 갈껴</description>
	<language>ko</language>
	<pubDate>Wed, 25 Nov 2009 17:09:00 GMT</pubDate>
	<generator>Egloos</generator>
	<image>
		<title>아라크네 이글루</title>
		<url>http://pds6.egloos.com/logo/200808/02/50/f0055650.jpg</url>
		<link>http://arachneng.egloos.com</link>
		<width>80</width>
		<height>56</height>
		<description>나도 도쿄에 갈껴</description>
	</image>
  	<item>
		<title><![CDATA[ 운영체제 - 사용자 인터페이스 - 프로그래밍 언어 ]]> </title>
		<link>http://arachneng.egloos.com/2087466</link>
		<guid>http://arachneng.egloos.com/2087466</guid>
		<description>
			<![CDATA[ 
  <div>...는 서로를 고려하여 함께 개발되거나, 아니면 적어도 각각의 컴포넌트가 뜯어 고치지 않아도 adapt해서 쓸 수 있을 정도로 잘 설계되어야 한다. 소프트웨어의 삼위일체라고 해 둘까.</div><div><br />
</div><div>세 개가 아귀가 맞아야 하는 이유는 좋은 컴퓨터 시스템이 갖춰야 할 (또는 갖춰야 한다고 생각하는) 세 가지 조건 때문이다.<ul><li>사용성 -- 좋은 컴퓨터 시스템은 최소한의 습득으로 기본적인 기능을 수행할 수 있어야 하며, 더 복잡한 기능을 수행하는 데 드는 노력이 선형적이어야 한다. 예를 들어 만약 사용자 인터페이스가 운영체제가 제공하는 모든 기능을 반영하지 못 한다면, 반영되지 못 한 기능을 다루기 위해서 필요한 노력은 급격히 증가한다.</li><li>투명성 -- 좋은 컴퓨터 시스템은 속에서 무슨 일이 일어나고 있는지 필요하면 알 수 있어야 한다. (다만 이게 선택이 아니라 필수가 되면 사용성이 급격히 떨어짐을 주의할 것.) 투명성은 소프트웨어와 그 개발 과정에 모두 적용되어야 하며, 전자는 소프트웨어의 검증에 필수적이고 후자는... 설명 안 해도 여기 올 만한 사람들이라면 알리라 생각한다. 잘 설계된 프로그래밍 언어는 운영체제와 사용자 인터페이스의 투명성을 자연스럽게 보장할 수 있을 것이다.</li><li>확장성 -- 좋은 컴퓨터 시스템은 추후의 확장, 이를테면 새로운 기능 등에 열려 있어야 한다. 이 확장성은 소프트웨어 개발자 뿐만 아니라 일반 사용자에게도 열려 있어야 한다. 즉, 이미 있는 기능을 조합하여 새로운 기능을 만들어 내는 것이 직관적이어야 한다. 이는 사용성과 (소프트웨어의) 투명성이 동시에 보장되지 않으면 불가능할 것이다.</li></ul></div><div>물론 이거 말고도 여러 가지 조건이 있겠지만 -- 범용성, 효율성, 정확성 따위 -- 이건 이미 일반적인 컴퓨터 시스템들이 어느 정도 다 달성하기도 했으며 위의 세 가지는 수많은 삽질이 있었음에도 아직도 제대로 실현이 안 되었다고 생각하기 때문에 세 개를 골랐다. 마침 숫자도 세 개로 컴포넌트 수랑 맞아 떨어진다. 이런 생각을 한 게 나뿐인 건 당연히 아니고, 이를테면 <a href="http://tunes.org/" target="_blank">TUNES project</a> 같은 건 시작할 때의 상황을 생각하면 정말 혁신적인 (그러나 지금은 반쯤 망한) 프로젝트였다. TUNES project는 반쯤 망하긴 했어도 읽어 볼 자료는 매우 많으므로 이 쪽에 관심 있는 사람이라면 <b>전체</b> 사이트 일독을 권한다.</div><div><br />
</div><div>하여튼 원래 주제로 돌아 가면, 나는 만약 내가 그만한 능력과 재력과 시간이 있다면 위의 세 개를 모조리 뜯어 고칠 의향이 있다. (다만 나한테는 그런 능력도 재력도 시간도 없는/없을 것 같다는 게 문제지만...) 평생의 목표라고 해도 과언이 아닐 것이다. 특히 OS/UI와는 달리 프로그래밍 언어는 바꾸기 훨씬 어렵다고 생각하고 -- OS야 요즘은 심심하면 바꾸는 거고, UI도 생각보다 빨리 적응되는 컴포넌트지만, 언어는 레거시 때문에 바꾸기 매우 힘드므로 -- 따라서 OS/UI와 무관하게 쓰기 좋고 확장성 좋고 충분히 효율적이면서도 널리 퍼진 프로그래밍 언어를 만드는 것이 첫 단계라고 생각한다. 이제 내가 왜 <a href="http://hg.mearie.org/hinata/naru-spec/" target="_blank">나루 프로그래밍 언어</a>를 만들고 있는 건지 알겠는가?</div><div><br />
</div><div>----</div><div>이 글은 본래 <a href="http://arachneng.tumblr.com/post/257072652" target="_blank">텀블러</a> 쪽에 올린 글의 복사판이다. 이 글을 이글루에도 올리는 이유는 내가 언제고 여기에 관련된 훨씬 자세한 글을 쓸 경우 참조하기 편하게 하기 위해서이므로 당황하지 말자(...)</div><br/><br/>tag : <a href="/tag/운영체제" rel="tag">운영체제</a>,&nbsp;<a href="/tag/사용자인터페이스" rel="tag">사용자인터페이스</a>,&nbsp;<a href="/tag/프로그래밍언어" rel="tag">프로그래밍언어</a>,&nbsp;<a href="/tag/OS" rel="tag">OS</a>,&nbsp;<a href="/tag/UI" rel="tag">UI</a>,&nbsp;<a href="/tag/삼위일체" rel="tag">삼위일체</a>			 ]]> 
		</description>
		<category>운영체제</category>
		<category>사용자인터페이스</category>
		<category>프로그래밍언어</category>
		<category>OS</category>
		<category>UI</category>
		<category>삼위일체</category>

		<comments>http://arachneng.egloos.com/2087466#comments</comments>
		<pubDate>Wed, 25 Nov 2009 17:07:30 GMT</pubDate>
		<dc:creator>아라크네</dc:creator>
	</item>
	<item>
		<title><![CDATA[ 한국어 위키백과의 과거와 현재 ]]> </title>
		<link>http://arachneng.egloos.com/1945012</link>
		<guid>http://arachneng.egloos.com/1945012</guid>
		<description>
			<![CDATA[ 
  한국어 위키백과에 대한 얘기는 개인적으로는 그렇게 내켜하는 주제가 아니다. 나 자신은 한국어 위키백과의 초-중기 사용자에 가까우며 어쩌다 보니 관리자도 되었다가 시간도 없고 다소 회의적인 생각도 들어서 지금은 완전히 손을 놓은 사람인데, 이런 사람이 주제 넘게(?) 한국어 위키백과에 대한 얘기를 해서 좋을 게 있나 하는 생각을 많이 했다. 지금 생각하니 굉장히 불쾌한 인간들도 있기도 하고. 근데 아직도, 몇년이 지났는데도 위키백과에 대한 몰상식이 지나쳐서 글을 쓸 필요성이 느껴졌다.<div><br />
</div><div>그래서 써 두기로 한다. 다시 말해 두지만, 나는 현재 위키백과 사용자가 아니며 따라서 최근 내용(최소 2007년 이후)에 대해서는 틀릴 가능성이 높다. 제목에서 흔히 예상할 법한 "미래"를 슬쩍 빼 둔 것도 그것 때문이다 -- 내가 위키백과의 미래에 대한 글을 쓸 수 있다면, 난 관리자가 아니라 점쟁이 짓을 했을 것이다.</div><div><br />
</div><div><br />
</div><div><b>한국어 위키백과는 관리자가 문제이다?</b></div><div><div><br />
</div><div>관리자로 있던 사람으로서 다른 전·현직 관리자에 대한 글을 쓰는 건 "자기 식구 감싸주기"라는 느낌이 들 것 같아서 굉장히 망설여진다. 하지만 내가 관리자였을 때 한 일을 보면 정말로 "눈꼽만큼 더 신뢰받는 사용자"라는 성격이 강했고, 나 자신은 위키백과 편집과 관계 없는 쓸데 없는 논쟁에 발을 들여 놓지 않으려고 무진 애를 썼다. klutzy가 몇 번 말한 것 같은 기억이 나지만 관리자는 논쟁을 해결하는 해결사가 아니라 단순 관리를 위해 선출된 신뢰받는 사용자이다 -- 논쟁 벌어진다고 관리자를 불러서 해결하려고 하는 건 불에 물을 붓는 게 아니라 기름 내지는 니트로글리세린을 붓는 꼴이 된다.</div><div><br />
</div><div>...라는 게 전통적인 관리자론이고, 내가 현재까지도 유지하고 있는 생각이지만, 현실적으로는 관리자가 단순 관리 업무 이외에 다른 일을 하는 게 현재 한국어 위키백과의 실태이다. 많은 경우 관리자는 노련한 장기 사용자이기도 하므로 장기 사용자가 만들어 내는 트러블은 관리자에게도 동등하게 적용될 수 있다. 하지만 그렇다고 한국어 위키백과 전체를 비난하기 시작하면 답이 안 나온다. 하려면 개별 관리자나 사용자에게 직접 해라. 당신이 내가 이 글에서 지적하는 내용 이외에 상식 밖의 행동을 하는 사람(비단 관리자가 아니더라도)을 만났다면, 아마도 그 사람이 잘못 했을 거고 다른 사람도 비슷한 생각을 할 것이다.</div><div><br />
</div><div>물론 당신이 틀린 말을 하는 경우도 있다. 사실 이 글은 그런 잘못된 인식들에 대한 정확한 정보를 알려 주기 위해 쓴 것이다. 그러니까 관리자든 누구든 클레임을 거는 건 좋은데 먼저 잘 알아 보고 걸어라. 옛날과는 달리 이제 한국어 위키백과에도 관리 관련된 다양한 글들이 "위키백과:" 네임스페이스에 널려 있다. (여기에서 위키백과 사용법에 대한 자세한 얘기를 하지는 않을 것이다. 알아서 확인해 보세요.)</div><div><br />
</div><div><b>위키백과는 저작권에 대해서 깐깐하다?</b></div><div><br />
</div><div>위키백과의 저작권 문제는 만들어질 때부터 꾸준히 떡밥으로 부상하는 문제였기 때문에 사람들의 주장이 여러 개로 갈려져 있는 상태이다. 그 중에서 가장 극과 극을 달리는 주장을 뽑으면 GFDL이라는 키워드로 대표되는 강경론과 공정사용이라는 키워드로 대표되는 온건론을 뽑을 수 있는데, 내가 위키백과 활동을 하던 때만 해도 이들의 논쟁은 거의 점입가경이었다. 일단&nbsp;두 주장의 요점을 알기 쉽게 정리하자.</div><div><br />
</div><div>GFDL이라고 함은 위키백과 저작권의 이론적 토대가 되는 라이선스로, 쉽게 말하면 "보는 것도 자유, 복사하는 것도 자유, 다른 데 갖다 붙여서 새로운 걸 만드는 것도 자유. 다만 갖다가 만드는 새로운 것이 GFDL을 따라야 함"이라 할 수 있다. (즉 한 번 GFDL로 공개된 자료를 가지고 뭔가를 만들면 그것도 같은 조건으로 공개해야 한다. 이른바 라이선스의 전염성이라 할 수 있다.) 지금은 CC-by-sa라는 다른 라이선스로 점차 바뀌고 있는데 둘이 완벽한 상호 호환이 안 된다(왜냐하면 서로 다른 라이선스니 전염도 따로 되니까... GFDL에서 CC-by-sa로 가는 건 예외 조항이 있긴 하다)는 점을 빼면 기본적인 내용은 동일하다.</div><div><br />
</div><div>GFDL은 자유로운 백과사전을 추구하는 위키백과의 목표에 합당하다고 할 수 있지만, 현실적으로 적용하려면 법적으로 복잡한 상황이 많다. 예를 들어서 '인용'은 저작물의 사용에 있어서 예외로 칠 수 있는가(즉 서로 호환 안 되는 두 라이선스로 된 문서들끼리도 인용이라는 형태로 문장을 공유하는 건 가능한가)? 그리고 친다면 어디까지가 '인용'인가? 백과사전의 주요 컨텐츠인 문서에 따라 들어 오는 이미지 같은 자료들은 문서에 포함된(즉 같은 라이선스가 강제되는) 것으로 보는가? 서로 라이선스가 호환되지 않아도 공공성 및 비영리성이 보장되면 제한적인 이용이 가능해지는 '공정 이용'(이나 그와 비슷한 제도들)이 존재하는데, 이게 GFDL과 공존할 수 있는가? 뭐 이따위 것들이다. 지금도 보기만 해도 머리가 아프다.</div><div><br />
</div><div><span class="Apple-style-span" style="text-decoration: underline; ">강경론</span>은 모든 글, 이미지, 자료에 대한 GFDL의 엄격한 적용을 주장한다. 즉, 앞에서 말한 모든 질문에 대해서 최대한 보수적인 잣대를 쓰는 것이다. <span class="Apple-style-span" style="text-decoration: underline;">온건론</span>은 문서에 독립적으로 포함되는 이미지나 자료에 대해서는 GFDL보다 덜 자유로운 라이선스의 사용이 백과사전의 완성도를 위해 필수 불가결하며, 따라서 GFDL의 유연한 적용을 주장한다. 어느 쪽이든 문서 자체가 GFDL로 남아야 한다는 점에는 동의한다 -- 만약 문서가 GFDL이 아니어야 한다는 걸 주장하는 사람이 있으면 가비얍게 무시하여 주시길 바란다. 그건 위키백과의 목표랑 전혀 상관 없을테니까.</div><div><br />
</div><div>옛날도 그렇고 지금도 그렇고 현재 한국어 위키백과의 기본 입장은 강경론에 가깝다. 강경론이 최초에 힘을 얻은 이유는 확실하지 않지만 아무래도 온건론자들의 입장을 그대로 받아 들였을 때 법적인 책임을 누가 질 것이냐에 대한 염려가 컸을 것이다. 근데 이건 옛날 얘기고, 사람이 많아지니까 온건론도 상당히 힘을 얻기 시작해서 본격적인 토론이 시작되게 되었다. 로고 등의 제한된 범위를 GFDL 적용 대상에서 제외하자는 토론이 몇 개 있었는데 결과가 어떻게 되었는지는... 뭐 뻔하지. 공정 이용 얘기를 좀 더 하자면, 영문 위키백과에서는 공정 이용을 허용하고 있으나 매우 제한이 크며 (이를테면 특정한 글에서만 포함할 수 있으며, 다른 대체 저작물이 없음을 증명해야 한다) 결정적으로 한국 저작권법에서 미국 저작권법의 공정 이용(fair use)에 정확히 대응하는 개념이 없기 때문에 법적으로 무슨 일이 생길지 예측이 불가능했다. 농담이 아니라, 이것때문에 한미FTA 발효되면서 한국 저작권법이 미국 저작권법과 크게 호환되게 개정된다면 공정 이용이 정식으로 채택될 가능성도 꽤 있다. (아직은 아닌 걸로 기억한다.)</div><div><br />
</div><div>온건론이 지금껏 주장은 많이 되어 왔는데 영 힘을 못 쓰는 이유 중에는 온건론파 중에 트롤(...)도 있기 때문이다. 공정 이용 허용하는 게 옳다면서 투표로 자웅을 겨루자! 하는 웃기지도 않는 소리를 하는 인간이 최소 한 명 있었고, 이것때문에 다른 온건론자들이 이 사람을 저지하느라 쓸데 없는 정력을 소모하곤 했다. (W 모씨라고 법학 전공인 것 같은데 그럴 거면 그냥 니가 위키미디어재단 자문 맡아라. 참고로 재단에도 법률 자문 있거든...) 따라서 만약 온건론을 주장하려면 먼저 이런 트롤들이 누군지 알아 두고 이들의 쓸데 없는 주장에 휩쓸려(...)가지 않도록 주의가 필요하다. 온건론이 틀렸다는 얘기가 아니다 -- 대부분의 사용자는 이따위 주제에 관심을 가지고 싶어 하지도 않고 관심을 가지지도 않기 때문에 만약 충분히 납득할만한 결론이 나면 온건론도 충분히 받아 들여질 수 있다.</div><div><br />
</div><div>이거랑은 별개로... 아무 데서나 텍스트 갖다가 (위키 문법도 쓰지 않고) 붙여 넣는 건 강경론이든 온건론이든 달가워하지 않는 행동이니 제발 좀 자제합시다. 위키백과의 목표 -- 자유로이 사용 가능한 백과사전 -- 를 깡그리 무시한다는 이유로 한방에 트롤 취급당하는 지름길이다.</div><div><br />
</div><div><b>한국어 위키백과는 영문·일본어 위키백과의 짝퉁에 불과하다?</b></div><div><br />
</div><div>한국어 위키백과가 영문 위키백과의 영향을 크게 받는다는 것은 잘 알려진 사실이다. 사실, 거의 모든 언어판 위키백과가 직간접적으로 영문 위키백과의 영향을 받는 게 맞다. (왜냐하면 영문이 가장 크고 쇼케이스가 많으니까) 위키미디어재단도 이 문제를 잘 알고 있어서, 다른 언어판 위키백과가 영문판과 독립적으로 발전할 것을 권장하는 발언을 한 바가 있다.</div><div><br />
</div><div>이제 현실을 얘기하자. 아닌 게 아니라 정말로, 영문이나 일본어 위키백과의 글이 한국어 위키백과로 "번역"되어 옮겨 오는 경향이 좀 있다. (일본이나 일본 애니메이션 문서 같은 건 특히 일본어 위키백과 쪽이 많다.) 그런데 생각해 보면, 만약 번역 대상인 글 자체가 잘 되어 있는 글(이를테면 영문판의 featured article)이고, 게다가 라이선스 문제도 없다면 옮겨 오는 것 자체에는 큰 거부가 없는 게 맞다 -- 뭐랄까 다른 자유 라이선스 백과사전(글로벌백과라거나)에서 전재를 하여서 최초로 글을 채우는 거랑 다를 게 없으니까. 만약 문제가 있다면, i) 번역이 위키백과 활동의 전부라고 생각하는 사람이 생기거나 ii) 번역을 대강 대충 하는 바람에 완성되지 않은 형태의 글이 난립하는 상황이 생긴다거나 하는 정도일 것이다. ii)에 대한 답은 별로 없고 발견하는 즉시 적절히 정리 -- 번역 오랫동안 안 된 부분은 날리고 백과사전적인 글로 완성 -- 하거나 애초에 번역을 자기 사용자 네임스페이스에서 시작하거나... 하는 대안이 있다. i)는... 더 안 말하겠다.</div><div><br />
</div><div>일본어 위키백과에 대해서는 할 말이 더 있다. 일본어 위키백과는 전통적으로 앞에서 말한 저작권 강경론파의 극단에 서 있는 편으로, 초상권 문제 때문에 심지어 간접적으로 찍힌 인물 사진도 저작권 위반으로 날아 가는(...) 정책을 취하고 있다. 그런데 한국어 위키백과에서 일본어 위키백과의 모든 사항이 적용 가능한 게 아닌데도 간섭하는 사용자가 있으니,&nbsp;Hyolee2. 가급적이면 사용자명을 완전히 밝히는 건 안 하려고 했으나 (뭐 앞에서 이니셜로 쓴 사용자는 알 사람들은 다 알겠지만) 이 사람은 정말로 주의가 필요하다고 느껴서 소개하는 것이니, 정말로 주의하시라. 뭔가 모르겠다 싶으면 이 사람의 주장은 일단 무시하고 다른 사람들의 설명을 참고하는 것이 더 현명하다. 내 주변에서 이 사람 때문에 위키백과를 때려 쳤다는 사람이 몇 나오는 걸로 봐서 지능적 트롤이라고 해도 과언이 아닐 것 같다. (모든 외국인 사용자가 이러는 건 아니고 이 사람만 이러는 거니까 외국인 사용자를 배척하진 말길 바란다. 외국인이지만 자신의 능력 안에서 한국어 위키백과에 잘 기여하는 사람들도 수두룩하다.)</div><div><div><br />
</div><div>만약 위키백과에 자생적으로 만들어진 좋은 글이 존재하냐라는 질문이 들어 온다면, 비교적 최근에 알찬 글로 선정된 <a href="http://ko.wikipedia.org/wiki/%EB%A7%88%EC%B0%BD%EC%A7%84_%EA%B4%91%EC%97%AD%EA%B6%8C%EC%9D%98_%EC%8B%9C%EB%82%B4%EB%B2%84%EC%8A%A4" target="_blank">마창진 광역권의 시내버스</a> 글을 추천하겠다. 이 글은 다른 어떤 언어판에도 존재하지 않는 글이면서 "도대체 이런 주제가 백과사전에 있을 수 있을까"라는 생각을 깨끗하게 부숴 주는 예제라 할 수 있겠다.</div><div><br />
</div></div><div><b>위키백과의 중립적 시각은 과연 중립적인가?</b></div><div><br />
</div><div>위키백과의 중립적 시각 또한 저작권과 더불어 큰 논란이 되는 주제이다. 특히 저작권은 그나마 답을 만들려면 만들 수 있지만 중립적 시각에 대해서는 답이 존재하지 않다는 점이 큰 문제가 된다. 예를 들어서, 한국어 위키백과는 "대한민국" 내지 "한국" 위키백과가 아니지만 현실적으로는 한국에 관련된 글이 많이 있는데 이걸 정상적인 상황이라고 볼 수 있는가? 같은 것이다.</div><div><br />
</div><div>나는 "중립적 시각"이라는 말 자체가 오해할 소지가 좀 있다고 생각하지만 적절한 다른 용어를 생각해 낼 수 없는 관계로 일단 그대로 쓰기로 한다. "중립적 시각"이라는 말의 오류는 크게 두 가지인데, 먼저 "중립적 시각"은 중립적이지 않다 -- 만약 완벽한 중립이라는 걸 정할 수 있다면, 그렇다. 중립적 시각은 다른 시각보다 더 중립적이려고 '노력'하는 시각이지 중립 그 자체가 될 수 없으며, 현실적으로 완벽한 중립적 시각으로 백과사전을 쓸 수는 없다. 중립적 시각이 중립성을 유지하려고 '노력'(다시 말하지만, 이런다고 완벽한 중립이 되진 않는다)하는 방편은 어떤 주제에 대한 주장들의 비율을 정함에 있어서 민주적으로 대처한다는 것이다. 예를 들어 독도의 소유권 분쟁이 좋은 예가 될텐데, 독도가 한국 땅이냐 일본 땅이냐에 대한 논란은 둘 다 굉장히 많기 때문에 토론에 의해 둘 사이의 비율은 보통 비슷하게 조정된다. 하지만 아무도 독도가 미국 땅이라는 주장을 실으려고 하지는 않을 것이다. (싣는다 하더라도 토론도 안 하고 날아 갈 가능성이 높다.) 예외적으로 표제어는 어쨌든 하나로 정해야 하기 때문에 전체 위키백과에서 용인된 규칙에 더 합당한 걸 쓰는 경향이 있긴 하다 -- 참고로 영문 위키백과는 하도 이 건으로 많이 데여서 지금 현재 표제어가 "독도"도 아니고 "타케시마"도 아닌 "리앙쿠르 암"이다. <span class="Apple-style-span" style="text-decoration: line-through;">그러니까 영문 위키백과 표제어 바꾸려고 난리치지 마 이것들아</span></div><div><br />
</div><div>더 중요한 오류는, "중립적 시각"은 "시각"이 아니다. "중립적 시각"이라는 이름의 하나의 완전한 시각이라는 건 존재하지 않는다. 대신, 위키백과의 중립적 시각은 현재 진행형이며, 위키백과 사용자들의 토론과 합의에 의해 결정되는 민주적인 (민주적이라고 해서 투표를 먼저 생각하는 사람이 있다면 때려 주고 싶다.) 절차이다. 그러니까 만약 어떤 글이 중립적이지 않다는 느낌을 받았다면, 당신은 아 씨바 위키백과 이거 병신이네 이렇게 생각해야 하는 게 아니라 이걸 어떻게 고칠 수 있을까라는 고민을 해야 하는 게 맞다. 직접 자기가 고치지 않더라도 말이다. 왜냐하면 그 글을 쓴 사용자들도 당신과 똑같은 인간이니, 당연히 문제가 없을 순 없지 않는가. 뭐 사용자들끼리 어떻게 토론을 하고 분쟁을 조정하느냐에 대한 얘기는 또 다른 주제가 될텐데 이건 어느 온라인 커뮤니티에서라도 똑같이 일어나는 일이니 여기서 더 부연하진 않겠다.</div><div><br />
</div><div><b>위키백과의 일부 사용자·관리자가 싫어요</b></div><div><br />
</div><div>이건 내가 어찌 할 수 있는 일이 아니니 뭐 말을 못 하겠다. 사실 장기 사용자·관리자들 중에 (나는 이해가 가지만) 사람들을 다소 공격적으로 대하는 경우가 있긴 한데, 대부분의 경우 다른 사용자가 지적을 해 줄 것이며 만약 아무도 지적을 안 한다면 일반적인 인터넷 논쟁에서 적용되는 원칙을 한 번 적용하길 권한다: "좀 숨 돌렸다가 다시 볼 것". 감정적인 발언으로 당신을 옹호하는 다른 사용자들마저 떠나게 만드는 것보다는, 이성적으로 잘못된 점을 지적하여 문제를 원만하게 해결하고 좋은 관계를 유지하는 게 더 낫다. 이 얘기 계속 하면 글의 주제가 달라지니까 이 쯤 하기로 하자.</div><div><br />
</div><div>예외적으로, 다른 뭇 사용자들이 "트롤"로 인정하는 사용자들이 몇몇 있는데 (앞에서 언급한 두 사용자를 포함) 이런 사람들과는 멀어지는 것이 좋을 것이다. 이들의 글을 자세히 살펴 보면 어떻게 하면 자기 주장을 하면서 트롤로 보이지 않을지도 깨달을 수 있을 것이다.</div><div><br />
</div><div><br />
</div><div>더 말할 게 있는진 모르겠지만 귀찮아서 생략한다. 아무쪼록 어느 정도 답이 되었으면 좋겠다.</div><div><br />
</div><div>(어느 밸리에 보내야 할지 모르겠어서 일단 IT 밸리에 보내 본다...)</div></div><br/><br/>tag : <a href="/tag/위키백과" rel="tag">위키백과</a>,&nbsp;<a href="/tag/한국어위키백과" rel="tag">한국어위키백과</a>,&nbsp;<a href="/tag/사용자" rel="tag">사용자</a>,&nbsp;<a href="/tag/관리자" rel="tag">관리자</a>,&nbsp;<a href="/tag/논란" rel="tag">논란</a>,&nbsp;<a href="/tag/해설" rel="tag">해설</a>			 ]]> 
		</description>
		<category>위키백과</category>
		<category>한국어위키백과</category>
		<category>사용자</category>
		<category>관리자</category>
		<category>논란</category>
		<category>해설</category>

		<comments>http://arachneng.egloos.com/1945012#comments</comments>
		<pubDate>Mon, 16 Nov 2009 10:29:02 GMT</pubDate>
		<dc:creator>아라크네</dc:creator>
	</item>
	<item>
		<title><![CDATA[ 소개글 ]]> </title>
		<link>http://arachneng.egloos.com/1908453</link>
		<guid>http://arachneng.egloos.com/1908453</guid>
		<description>
			<![CDATA[ 
  <div><div>가끔씩 아라크넹이라는 닉으로 돌아 다니다가 소개글을 써야 할 때가 되면 나는 항상 이렇게 써 놓는다.</div><div><blockquote>"안녕하세요 여러분의 영원한 친구 아라크넹입니다."</blockquote></div><div><br />
</div><div>써 놓고 나서도 이게 어디서 나온 건지 헷갈렸는데, 이제 와서 생각해 보니 바로 이거였다.</div><div><br />
</div><div><div style="text-align:center"><img class="image_mid" border="0" onmouseover="this.style.cursor='pointer'" alt="" src="http://pds17.egloos.com/pds/200911/14/50/f0055650_4afd99763860d.jpg" width="500" height="462.04620462" onclick="Control.Modal.openDialog(this, event, 'http://pds17.egloos.com/pds/200911/14/50/f0055650_4afd99763860d.jpg');" /></div></div><div>은근히 틀린 맞춤법이 인상깊어서 기억이 났다. 그런데 저걸 일부러 의식하고 쓴 게 아닌데 저런 문장이 되어 버린 걸 보니 무의식이라는 건 참 무섭다.</div></div><br/><br/>tag : <a href="/tag/무의식" rel="tag">무의식</a>			 ]]> 
		</description>
		<category>무의식</category>

		<comments>http://arachneng.egloos.com/1908453#comments</comments>
		<pubDate>Fri, 13 Nov 2009 17:39:23 GMT</pubDate>
		<dc:creator>아라크네</dc:creator>
	</item>
	<item>
		<title><![CDATA[ 소통하고자 하면 소통할 수 없다 ]]> </title>
		<link>http://arachneng.egloos.com/1895649</link>
		<guid>http://arachneng.egloos.com/1895649</guid>
		<description>
			<![CDATA[ 
  비교적 오랫동안 개인 웹 사이트도 운영하고 블로그도 운영해 본 입장에서 말하자면, 이것들은 다 귀찮다. 어떻게 만들지도 문제지만 한 번 만들어 놓아도 글을 써 넣는 게 귀찮아진다. 나 같은 경우에는 심심하면 글을 쓸려고 하는 타입이라 이 문제는 해결이 되지만, 더 큰 문제는 사람들의 반응이다. "내가 이 글을 쓰면 사람들은 뭐라고 반응할까?" "내가 쓴 글을 좋아할까? 싫어할까?" "이거 올리면 안 되는 거 아냐?" 등등.<div><br />
</div><div>나도 2004년쯤인가에 처음 블로그를 시작했을 때 그랬다. 근데 시간이 지나면서 그따위 걱정은 강에 갖다 버려도 된다는 사실을 깨달았다. 내가 글을 써 봐야, 영양가 있는 글에는 반응이 덜하고 영양가 없는 글에는 반응이 격렬하다 (논쟁글이라거나 근황글이라거나 아무 의미도 없는 신고글이라거나). 그래서 생겨난 모토가 있다. <b>소통하고자 하면 소통할 수 없다.</b></div><div><br />
</div><div>같은 단어로 쓰여 있긴 하지만 앞의 소통과 뒤의 소통은 품질의 차이가 있다. 요컨대, 만약 내가 쓴 글을 정말 감명깊게 여긴다거나 하는 사람이 있다면 내 연락처를 무슨 수를 써서라도 알아 내려고 하든지, 그게 귀찮다면 링크라도 해 둘 것이고 나중에 그 링크를 발견했을 때 "아 이 사람이 내 글을 알아 줬구나" 하면서 혼자 미소를 띠면 된다. 굳이 사람들의 반응을 받기 위한 만반의 준비를 해 놓고 무플에 서글피 우는 것보다는 (서글피 울 필요가 없는 문제라는 걸 머리는 아는데 가슴은 모르니까) 훨씬 정신건강에 이롭다. 게다가 댓글 란을 달았을 때의 signal-to-noise 비율, 즉 가치 있는 반응의 비율이 실제로 높아지는 걸 봤기 때문에, 더 가치있는 반응을 얻기 위해서는 오히려 댓글을 닫는 게 효율적일 수도 있다는 생각을 하게 되었다. (물론 나는 댓글이 닫혀 있든 말든 가치있는 답글을 달기 위해 노력하긴 한다. 근데 이거 정말 시간 많이 들더라.)</div><div><br />
</div><div>가끔씩 블로그에 댓글을 구걸하며 별 것도 아닌 글에 이것 저것 다는 사람들을 본다. 이런 사람들은 소통을 원하는 게 아니라 관심, 그러니까 단방향으로의 소통만을 요구하는 것 같다. 소통이 무슨 TCP도 아니고, 내가 SYN 보내면 반대편에서 ACK 보내고 끝나는 일이라고 생각하는가? 이건 소통이 아니다. 뭐 관심만을 원하는 사람들이라면 그럴 수도 있겠다 싶지만 -- 그리고 그걸 위해서 블로그를 하는 사람이 늘고 있는 것 같아서 씁쓸하지만 -- 좀 알 건 다 알 만한 사람들까지 그러는 걸 보면 딴지를 걸고 싶어진다.</div><br/><br/>tag : <a href="/tag/소통" rel="tag">소통</a>,&nbsp;<a href="/tag/관심" rel="tag">관심</a>			 ]]> 
		</description>
		<category>소통</category>
		<category>관심</category>

		<comments>http://arachneng.egloos.com/1895649#comments</comments>
		<pubDate>Wed, 11 Nov 2009 16:41:41 GMT</pubDate>
		<dc:creator>아라크네</dc:creator>
	</item>
	<item>
		<title><![CDATA[ 마음 속에서 묻어 버린 두 사람 ]]> </title>
		<link>http://arachneng.egloos.com/1719634</link>
		<guid>http://arachneng.egloos.com/1719634</guid>
		<description>
			<![CDATA[ 
  개인적으로 알고 지내던 사람들 중에 의견이나 성격이 확 틀어져서 완전히 연을 끊어 버린 사람이 두 명 있다. 오늘은 그 사람들에 대한 얘기를 해 보기로 하겠다.<div><br />
</div><div>한 사람은 학교 선배(나는 "선배"라는 말을 쓰는 것 자체를 꺼리지만)였고, 다른 한 사람은 초등학교 동창이었다. 편의를 위해 전자는 A, 후자는 B라고 하겠다.&nbsp;(만약 당사자가 이 글을 본다면 서로 누굴 말하는지 잘 알 것이지만, 이 글에 댓글을 달거나 연락을 시도할 경우 무시 내지 처단하도록 노력할 것이다.)&nbsp;흥미로운 건 A나 B나 상당한 논객인데다가 직접적으로 말하는 걸 선호하는 편인지라 나같은 사람은 꽤 부담스럽다. 실제로 A와의 연을 끊게 되는 사건 직전에 A와 B가 온라인 채팅으로 만날 일이 있었는데, 이 인간들끼리 글로 쌈박질하는 게 세기의 대결이었지만 대신 다른 사람들이 미치려고 했다.</div><div><br />
</div><div>내가 알기로 A의 아버지가 학자이신데, 덕분에 A는 비판적 사고를 어릴 때부터 학습해 왔던 모양이다. (듣기로 "아버지와 토론하는 걸 즐겼다"라고 했으니) 비판적 사고가 있는 건 좋은 일이지만, 문제는 다른 사람을 대하는 태도는 그 사고를 못 따라간다는 점이다. 그래, 쉽고 약간 부정확하고 비논리적으로 표현하자면 싸가지가 밥맛이다. 내가 A에게 이런 말을 직접 했다가는 싸가지라는 개념 자체가 글러먹었다고 반응하겠지만, 이건 보통 사람들의 이해를 도모하려는 거니 상관 없다. 하여튼 이 인간이 글 쓰는 걸 보면 글에 칼을 됫박으로 부어 넣는 걸 볼 수 있는데, 이게 정말 말도 안 되는 인간들을 상대할 때는 큰 문제가 안 되지만 그냥 저냥 비판하는 글에는 비수로 작용해서 사람들을 미치게 한다.&nbsp;최근 A의 블로그에 들어 가 봤을 때 "글이 과격해도 논리적이면 상관 없지만 논리적이지 않은 글은 자근자근 밟아 드립니다" 정도의 뉘앙스를 띤 공지를 봤는데, 역시, 변할 리가 없지 라는 생각을 했다.</div><div><br />
</div><div>나는 내가 논리적이라고 생각하지는 않지만, 아주 비논리적이라고 생각하지도 않는다. 어느 정도 논리적으로 생각할 가치가 있는 주제에 대해서는 논리적으로 생각하려고 노력한다. 모든 일에 대해 논리적으로 생각하는 게 불가능한지는 모르겠지만, 최소한 내 정신 건강과 육체 건강을 심각하게 해칠 사고 방식이라는 점은 분명하기 때문에 변명은 가능하다. 그런데 이 인간은 어디서 정신력을 긁어 모은 건지 모든 일에 논리성을 부여하려고 하는 것 같았다. 그 결과로, 나같이 반만 논리적인 사람들은 그랑 논의를 일단 시작하면 너무 피곤해서 하려던 말도 안 나오는 경우가 많다. (게다가 나는 아직 내 가치관에 필요한 논거들을 쌓아 올려 가는 과정이고, 생각을 언어로 바꿔 내는 데 너무 시간이 많이 걸리니 최악이었다.) 또한 A가 천성이 호전적인지라 그냥 넘어 가도 될 일에 트집 잡는 것도 한 두 번이 아니었다.</div><div><br />
</div><div>B는 A보다는 상태가 조금 나았지만, 결과적으로 비슷한 결과를 낳고 말았다. A가 (설령 논리적으로는 그게 맞을 지라도) 트집을 잡는 데 선수라면, B는 어느 이상의 친분을 가진 지인에게는 자신과 비슷한 수준의 논리성을 요구하는 습관이 있었다. 특히 B는 정치적인 주제에 대해서는 명확한 위치를 요구해 왔지만, 앞에서 말했듯 거기에 그대로 대응해 줄려니 기력이 달려서 대강 대충 얼버무리는 경우가 많았다. 거기에 대한 B의 반응은 차가웠다. 솔직히 무리한 요구를 한 인간이 누군데 나 보고 어쩌라고. 내 이런 특징을 B에게 이해시키려고 상당한 노력을 기울였고, 심지어 한 번 싸웠다가 화해한 적도 있었지만, 결국 어느 시점에서 내가 포기하고 연을 끊기로 했다.&nbsp;어쩌면 내가 그 요구에 미동도 안 하고 무시했다면 지금 B와의 관계가 이 정도로 맛이 가지는 않았을 거라는 후회를 해 봤지만, 과연 소심한 내가 그랬을 수 있을까, 하고 쓴 웃음을 짓곤 한다.</div><div><br />
</div><div>한동안 나는 내 가치관에 대해 심각한 회의를 가지고 있었다. 감정적으로는 옳다고 생각하지만 이성적으로는 증거가 너무 부족해서 이대로 주장하면 발리겠다라는 생각을 했던 것이었다. A와 B를 알게 되고 소원해지는 시간동안, 나는 한 가지 논지는 확신할 수 있게 되었다. 일반적인 인간에게 논리성을 주입하려는 것은 그 자체로 폭력이라는 점. 어디부터 어디까지가 논리가 필요하고 그렇지 아니한지를 파악하는 것은 논리적인 사고를 하는 것 만큼이나 중요하다는 사실이었다. (내가 이 얘기를 B한테 처음 했을 때 그의 반응은 "너무 중립적인 사고를 하려는 거 아니냐"였다. B는 중립이라는 걸 용납하지 않았으니 어쩌면 당연한 일이겠다.) 그런데 나는 한편으로 감성적인 사고가 논의에 전혀 도움이 되지 않는다고 주장하잖아? 아마 인류는 이 모순 때문에 멸망할 거야. 아마.</div><div><br />
</div><div>그렇게 나는 A와 B를 내 마음 속에서 묻어 버렸다. A는 지금도 블로그에서 열심히 쌈박질을 하면서, 그렇게 자기가 싫어하던 한국을 떠나서 프랑스 찬가를 부르며 살고 있고, B는 자신의 소신에 맞는 모 소수 정당에서 나름대로 정치활동을 하면서 여전한 글빨을 과시하고 있다. 그리고 나는 여전히 내 가치관을 뒷받침할 논거를 찾아 다니면서 번민하고 있다. 과연 그들에게는 내가 어떤 인간으로 비쳐져 보였을까? 모르겠다.</div><div><br />
</div><div>추가: 이제서야 B의 최근 논쟁을 조금 보았는데... 씨바 이건 병신도 아니고. 왜 과학 문제에 인문학을 넣으려고 해. 논리적이라는 말 취소. 그냥 지좆대로 씨부리는구나.</div><br/><br/>tag : <a href="/tag/인간군상" rel="tag">인간군상</a>,&nbsp;<a href="/tag/논리" rel="tag">논리</a>			 ]]> 
		</description>
		<category>인간군상</category>
		<category>인간군상</category>
		<category>논리</category>

		<comments>http://arachneng.egloos.com/1719634#comments</comments>
		<pubDate>Sun, 25 Oct 2009 23:52:05 GMT</pubDate>
		<dc:creator>아라크네</dc:creator>
	</item>
	<item>
		<title><![CDATA[ 코토리바코 ]]> </title>
		<link>http://arachneng.egloos.com/1650700</link>
		<guid>http://arachneng.egloos.com/1650700</guid>
		<description>
			<![CDATA[ 
  적절히 잘 알려진 2ch 괴담. 한국어 쪽에서 비교적 원전이라 할 수 있는 글은 다음과 같다: (사실 이 번역에는 꽤 많은 부분이 빠져 있으나 여기에서 자세히 설명할 이유는 없으니 생략)<div><br />
</div><div><a href="http://gurm1.egloos.com/2998241">http://gurm1.egloos.com/2998241</a></div><div><a href="http://gurm1.egloos.com/2998241"></a><a href="http://gurm1.egloos.com/3000246">http://gurm1.egloos.com/3000246</a></div><div><br />
</div><div>"글을 읽고 나서 구토증세나 오한이 일어날 수 있으니 주의하시기 바랍니다."라지만 사실 괴담이라고 하기에는 맥빠지는 내용이다. 원래 최초에 투고된 글은 코토리바코(子取り箱, 즉 아이 잡는 상자. 小鳥箱[작은 새 상자]와 발음이 같아서 최초에 혼선이 있었으나 별 의미는 없다)라고 해서 여자와 아이의 손가락과 내장 따위를 넣어서 밀봉한 저주용 상자를 (저주 걸렸다는 사실을 모른 채) 투고자의 친구가 실수로 만졌다가 다행히도 신관인 다른 친구가 해결을 해 줬고 나중에 이야기의 전말 -- 졸라게 차별받던 부라쿠민들이 도망자로부터 상자 만드는 방법을 알고 열심히 만들었는데 너무 버거워서 백수십년에 걸쳐 아직까지도 저주를 풀고 있는 중인데 그걸 친구가 꺼내 버렸다는... -- 을 듣는 내용이다. 여기까지만 읽으면 별 것 아닌 것 같아 보이는데, 사실 별 거 아니다. 일본어로 직접 원문을 읽은 내가 보장한다. -_-;;;</div><div><div><br />
</div><div>문제가 되는 내용은 그 신관 친구에 따르면 i) 코토리바코는 아직도 두 개 정도 남아 있으며 ii) 남아 있는 코토리바코는 부녀자에게 치명적인 영향을 미칠 수 있다는 점, 그리고 마지막으로 iii) 그 코토리바코를 백수십년 전에 처음 전수해 준 것으로 알려진 사람이 투고자와 뭔가 관련이 있을 수 있다(정확히는, 성씨가 같다)는 점이다. 투고자에 따르면 iii)가 아무래도 마음에 걸려서 당사자들의 허락을 받아 자세한 정보를 찾기 위해 글을 올렸다고 하는데, 사람들은 물론 남아 있는 코토리바코(와 그와 비슷한 상자들)의 행방도 알고 싶어하니 그 쪽으로 조사가 확장되었다.</div><div><br />
</div><div>그러한 결과로 <a href="http://blog.livedoor.jp/hako888/" target="_blank">2ch 쓰레드 정리 사이트</a>도 만들어지고 하면서 꽤 인기를 끈 것 같은데, 누구는 코토리바코 관련 글을 읽는 것만으로 오한이 들고 몸이 안 좋아졌다는 소리를 하고 있지만(...) 이건 솔직히 낚시인 것 같다. 하지만 비교적 많은 사람들이 비슷한 물건이 있다는 증언을 하고 있으며 (<a href="http://blog.livedoor.jp/hako888/archives/50545779.html" target="_blank">사진 인증</a>한 사람도 있다) 심지어 투고자를 만나서 <a href="http://blog.livedoor.jp/hako888/archives/50106081.html" target="_blank">문제를 해결</a>했다는 사람까지 있을 정도이다. 이렇게 되고 보니 상자 수가 너무 많은데, 아마도 코토리바코(와 그와 비슷한 상자들)를 만드는 방법은 비교적 잘 퍼져 있는 것 같고 단지 투고자가 처음으로 거기에 대한 글을 올린 것 뿐이 아니냐...는 쪽으로 의견이 모아진 듯.</div><div><br />
</div><div>여기에 대한 지적도 있으니, 코토리바코 얘기가 나돌기 전까지는 상자에 대한 글이 눈코빼기도 보이지 않더니 갑자기 상자에 대한 글이 늘어났다는 것이다. 이를테면 "잘 나가는 괴담에 살이나 붙여 볼까"라는 느낌. 하지만 인간의 기억은 기억해 내고 싶어서 기억해 내는 것보다는 다른 자극에 의해서 우연히 기억나는 경우가 많으니 이건 어쩔 수 없는 일 같다. 그렇다고 정말로 저주가 남아 있다거나 할지는 의문이지만.</div><div><br />
</div><div>귀찮아서 여기에서 종료.</div><div><br />
</div><div>한 줄 요약: 저주가 정말로 있는 것 같진 않지만 비슷한 민간 전승이 꽤 퍼져 있는 것 같기는 함. 즉, "상자"는 꽤 있는 것 같긴 한데, 그 상자 중 투고자의 상자가 있는지는 모르겠음.</div></div><br/><br/>tag : <a href="/tag/코토리바코" rel="tag">코토리바코</a>,&nbsp;<a href="/tag/괴담분석" rel="tag">괴담분석</a>			 ]]> 
		</description>
		<category>사건추적</category>
		<category>코토리바코</category>
		<category>괴담분석</category>

		<comments>http://arachneng.egloos.com/1650700#comments</comments>
		<pubDate>Wed, 14 Oct 2009 21:03:52 GMT</pubDate>
		<dc:creator>아라크네</dc:creator>
	</item>
	<item>
		<title><![CDATA[ 이바라키의 용궁성 ]]> </title>
		<link>http://arachneng.egloos.com/1650694</link>
		<guid>http://arachneng.egloos.com/1650694</guid>
		<description>
			<![CDATA[ 
  갑자기 오밤중에 궁금해져서 안 되는 일본어로 검색질해 가면서 찾아 봤다.<div><br />
</div><div>용궁성(龍宮城)은 뭐 당연하겠지만 바닷속 용궁에 있는 섬이다. 일본에서는 우라시마 타로 얘기서 타로가 묵는 장소라고 한다. (전래동화를 모르는 사람을 위해 요약하면: 어부인 우라시마 타로가 거북이를 구해 주자 그 답례로 용궁성에서 사흘동안 융숭한 대접을 받고 돌아 왔는데, 돌아 오고 보니 삼백년이 흘러 있었다는 흠좀무서운 얘기)</div><div><div><br />
</div><div>이바라키(茨城) 현의 용궁성은 바로 그 용궁성을 현실-_-에 재현한 건물이었다. 미요시 츠네요시(三吉常吉)는 어느 날 꿈의 신탁을 받아서 용궁성을 만들었다고 하는데, 실질적으로는 뭔가 테마파크 식으로 운영하고 있던 모양이다. 기묘한 건물(그 건물이라는 것이 덕지덕지 붙어 있는 판자들로 이루어져 있음)과 벽화들, 알 수 없는 물건들(...)이 즐비했다고 하는데 여기에 대해서는 다음 페이지 참조:</div><div><br />
</div><div><a href="http://www9.plala.or.jp/challenger/danwa/okuni/ryuuguu.htm" target="_blank">http://www9.plala.or.jp/challenger/danwa/okuni/ryuuguu.htm</a> (2000년 이전?)</div><div><a href="http://www.arakawas.sakura.ne.jp/backn012/ryugujou/ryugujo1.html" target="_blank">http://www.arakawas.sakura.ne.jp/backn012/ryugujou/ryugujo1.html</a> (2006년?)</div><div><br />
</div><div>텔레비전에도 출연하고 연예인도 다녀 갔다니 나름 명소였던 모양이다. 접근성은 그다지 좋은 편이 아니어서 걸어 갈 수 있는 거리긴 한데 한 번에 가는 건 힘들다고 하더라. 근데 뒷쪽 글에서 알 수 있듯, 2001년 미요시가 죽은 뒤 전혀 관리가 되고 있지 않아서 상당히 많이 부서진 상태라고 한다. 애초에 전문적으로 건축을 하는 사람이 아닌지라 훨씬 빨리 붕괴되고 있다는 관측.</div><div><br />
</div><div>여기까지가 진실이고, 이 다음부터는 내가 여기에 대해서 굳이 오밤중에 조사를 하게 만든 글이다. (아래 번역은 <a href="http://snm1945.tistory.com/entry/%EB%93%A3%EA%B3%A0-%EB%82%98%EB%A9%B4-%EA%B8%B0%EB%B6%84-%EB%82%98%EC%81%9C-%EC%9D%B4%EC%95%BC%EA%B8%B0 ">2ch 어비스</a>에서 가져 옴. 비슷한 글이 여기 저기 흩어져 있으나 직접 번역한 글이었을테니 한국어 웹에서는 "원전"으로 봐도 되겠다. 아... 근데 괴담천국에도 있던 것 같은데 지워져서 못 찾겠)</div><div><br />
</div><div><blockquote><div>(전략)</div><div><br />
</div><div>헌데 이 할아버지가 죽고 나서, 집을 허물었을 때 무서운 사실이 밝혀졌어</div><div><br />
</div><div>벽에서 할아버지 아내의 시체가 발견된 거야,&nbsp;</div><div>그것도 오래됐는지 완전히 백골이 되버린 채</div><div>한마디로 그 할아버지는 아내를 죽이고 시체를 벽에 묻은 다음</div><div>썩는 냄새 같은 걸 다른 사람들에게 눈치채이지 않게 하려&nbsp;</div><div>집을 용궁성으로 위장했다는 것</div><div><br />
</div><div>거기에 앞뒤를 맞추기 위해 죽을 떄까지 미치광이 행세를 했다는 거야</div></blockquote></div><div><br />
</div><div>과연 이 글은 진실일까? (덤으로 가장 원전이 되는 쓰레드를 찾아 보면 "이 사건 이후로 텔레비전에서 자취를 감췄다"라는 얘기가 있다.)</div><div><br />
</div><div>다행히도 미리 조사한 사람이 있었으니,&nbsp;<a href="http://b-spot.seesaa.net/article/38297592.html" target="_blank">이 블로그 글</a>을 보시라. 글에서 지적하듯 원전에는 두 가지 문제가 있는데 첫번째는 "집은 아직 허물어지지 않았다"는 것이며 (친척이 집을 허물었다는 소문을 들었다는 지역 사람이 있긴 했으나 실제 집이 존재함을 확인했으니 소문에 불과하다) 두번째는 "용궁성 근처에 아내의 묘지가 있다"는 것이다. 게다가 글의 증언에 따르면 애초에 벽이 얇아서 시체를 묻고 싶어도 묻을 수 없는 수준이라고 한다.</div><div><br />
</div><div>근데 문제는 이 글에 붙은 댓글이니, 원전과 똑갈은 내용의 뉴스를 본 사람이 두 명이나 있다고 하는 것이다. (참고로 첨언하자면 블로그 글은 2007년 4월에 쓰여졌고 해당 댓글은 2008년 11월, 2009년 3월, 그리고 8월에 쓰여졌다.) 앞에 댓글을 단 사람에 따르면 정확히는 기억할 수 없지만 2004~2005년 경에 저녁 뉴스로 잠깐 본 바가 있으며, 시체는 용궁성의 내부는 아니지만 용궁성에 가까운 건물에 있었다고 한다. 그러나... 일본웹을 내 한계까지 뒤져 봐도 관련된 내용이 더 이상 안 나온다. 그들의 말처럼 일종의 터부가 되어서 내용이 사라진 것인지, 그냥 두 사람(한 사람일 수도 있고)이서 낚시질한 건지는 이 시점에서는 결정할 수 없을 것 같다.</div><div><br />
</div><div>한 줄 결론: 현재 알려진 정보로는 사실 무근. 다만 단신으로만 소개되고 + 언급이 터부시되어서 정보가 남아 있지 않을 가능성 눈꼽만큼.</div></div><br/><br/>tag : <a href="/tag/이바라키" rel="tag">이바라키</a>,&nbsp;<a href="/tag/용궁성" rel="tag">용궁성</a>,&nbsp;<a href="/tag/괴담추적" rel="tag">괴담추적</a>			 ]]> 
		</description>
		<category>사건추적</category>
		<category>이바라키</category>
		<category>용궁성</category>
		<category>괴담추적</category>

		<comments>http://arachneng.egloos.com/1650694#comments</comments>
		<pubDate>Wed, 14 Oct 2009 20:09:05 GMT</pubDate>
		<dc:creator>아라크네</dc:creator>
	</item>
	<item>
		<title><![CDATA[ 인터넷 세상은 좁다 ]]> </title>
		<link>http://arachneng.egloos.com/1635226</link>
		<guid>http://arachneng.egloos.com/1635226</guid>
		<description>
			<![CDATA[ 
  <div>쉬운 예:</div><div><blockquote>옛날에 (양산형?) 판타지 소설에 심취해 있을 때 자주 눈여겨 보던 글 쓰던 사람이 있었다. 그 사람을 나중에 대학교 들어 와서 우연히 만나게 되었는데, 그 사람은 내가 듣던 수업의 조교 -- 그러니까 대학원생 -- 였을 뿐만 아니라 판타지 소설 심취하기 훨씬 전부터 알고 지내던 아는 형이 잘 알던 후배이기도 했다. -_-;</blockquote><div><br />
</div>조금 더 어려운 예:</div><div><blockquote>수시아의 찌질열전에서 기술한 <a href="http://docean.egloos.com/4530546" target="_blank">이 글</a>, 댓글까지 보고 나서 미칠 것 같이 웃었다. 일단 내가 문제의 파인클릭(지금은 망한 줄 알았는데 댓글 보니 용케 살아 있네)에서 활동했던 경력이 있어서 당시 사건을 대강 알고 있는 것까진 그렇다 쳐도, 어떻게 수시아 말고 나머지 한 사람의 당사자가 내 친구여... 나중에 물어 보니 "수시아랑 친구하느니 명박이랑 친구함"이라나.</blockquote></div><div><br />
</div><div>요컨대, 넷 공간에서 일정 시간동안 있으면 좋든 싫든 비슷한 사람들끼리 자주 보게 되는 것 같다. 그건 이 동네가 작아서 그런 게 아니라, 시간이 누적되면서 흔적이 계속 증가하기 때문이리라. 아마 조금만 뒤져 보면 내가 그동안 무슨 일을 해 왔는지 정도는 쉽게 알 수 있을 것이다. (나 같은 경우 2001년 이전의 흔적은 잘 없을텐데, 이건 PC통신 때 얘기니까 탐문수사를 하면 쉽게 드러날 것이다...)</div><div><br />
</div><div>전문 용어로 말하자면 이 동네를 나타나는 그래프에는 정점(vertex)은 많지만 정작 반지름(radius)은 엄청나게 작달까... 그래서 이 동네는 참 재밌다. 보고 있으면 자기들이 알아서 자뻑하고 난리를 치는데 (심심하면 나도 끼어 들고) 이런 거리들이 끊임 없이 재생산되니 지칠 구석이 없다. 이런 얘기들을 많이 다루는 엔하위키 같은 곳들이 좀 더 자유로워졌으면 하는 이유도 거기에 있고.</div><div><br />
</div><div>* 이런 류의 글을 올리기 위한 별도의 분류를 새로 만들었다. 과연 글이 올라 올 것인가...</div>			 ]]> 
		</description>
		<category>사건추적</category>

		<comments>http://arachneng.egloos.com/1635226#comments</comments>
		<pubDate>Sun, 27 Sep 2009 15:58:37 GMT</pubDate>
		<dc:creator>아라크네</dc:creator>
	</item>
	<item>
		<title><![CDATA[ 뻘코드 2009-08-08 ]]> </title>
		<link>http://arachneng.egloos.com/1585347</link>
		<guid>http://arachneng.egloos.com/1585347</guid>
		<description>
			<![CDATA[ 
  껴헣헣.<div><br />
</div><div><br />
</div><div>1번 문제. 제출 당시 103B, 나중에 101B로 줄임. 인코딩에 아스키 코드가 많다는 점에서 착안하였음. 예상하는 최소 코드는 95B 근처.</div><pre>u;main(v){for(;v=u++[(short*)"\310P$I\"E\"E$I(Q(Q$I\302D"];puts("."))for(;v;v/=2)<br />
putchar(46-v%2*11);}</pre><div><div>2번 문제. 제출 당시 (다소 문제가 있는) 208B, 나중에 205B로 줄임. 1번 문제와 상당히 흡사한 모양이지만 잔재주를 좀 발휘. 인코딩이 너무 긴 게 아쉽다. 예상하는 최소 코드는 180B 근처.</div><div><pre>i,j;char c[6];main(v){for(;gets(c);)for(j=5;j--;puts(""))<br />
for(i=0;i&lt;5;++i-2||printf(".%c.",46-j%i++*11))<br />
for(v="djjjddddddnbnhnnhnhnhhnjjnhnbnnjnbbhhhhnnjnjnhhnjn"[c[i]*5-240+j];v&gt;3;v/=2)<br />
putchar(46-v%2*11);}</pre><div>3번 문제. 제출 당시 115B, 나중에 114B로 줄임. 단순하게 코딩하는 거 말고 다른 방법을 못 찾겠다. 예상하는 최소 코드는 110B 근처.</div><div><pre>v,w,x,z=1e8;main(u){for(;~scanf("%d",&amp;u);printf("%08d\n",x))for(x=0;u;x=(x+v)%z,u--)<br />
for(v=w=u;--w;v=(v*1ll*u)%z);}</pre><div>더 자세한 건 <span style="text-decoration: line-through;">서울대 컴공과 아무나 붙잡고 물어 볼 것</span> <a href="http://pastie.org/private/qu3a0yj9hycbvdjpyz5uya">알아서</a> 봅시다.<br />
</div></div></div></div>    <br/><br/>tag : <a href="/tag/코드골프" rel="tag">코드골프</a>,&nbsp;<a href="/tag/숏코딩" rel="tag">숏코딩</a>,&nbsp;<a href="/tag/ESCamp" rel="tag">ESCamp</a>,&nbsp;<a href="/tag/변태짓" rel="tag">변태짓</a>			 ]]> 
		</description>
		<category>코드골프</category>
		<category>숏코딩</category>
		<category>ESCamp</category>
		<category>변태짓</category>

		<comments>http://arachneng.egloos.com/1585347#comments</comments>
		<pubDate>Sat, 08 Aug 2009 22:31:23 GMT</pubDate>
		<dc:creator>아라크네</dc:creator>
	</item>
	<item>
		<title><![CDATA[ 할당한 것은 무조건 해제해야 한다? ]]> </title>
		<link>http://arachneng.egloos.com/1566708</link>
		<guid>http://arachneng.egloos.com/1566708</guid>
		<description>
			<![CDATA[ 
  요즘은 만사가 귀찮아서 글을 잘 안 쓰게 되는 것 같아 좀 몸풀기 겸으로 써 봄.<br />
<br />
<br />
흔히들 할당한 메모리는 무조건 해제해야 한다고 말한다. 예컨대:<br />
<blockquote>Something *foo = new Something();<br />
// foo를 사용한다.<br />
delete foo;</blockquote>요런 식으로 써야 한다는 것이다. (어째 이글루스 html 편집 기능이 엉망이 된 것 같다. 원래대로라면 &lt;pre&gt;&lt;/pre&gt;로 묶었어야 한다. 윽.)<br />
<br />
물론 이 얘기는 일반적으로 틀린 말이 아니고, 아마도 C/C++로 프로그래밍하는 웬만한 사람들이 포인터 내지 메모리 관리를 배울 때 처음으로 듣는 원칙이기도 할 것이다. 근데 그렇다면 왜 이 글을 쓰겠는가? 당연히 아닌 경우가 있으니까 쓰겠지. -_-;<div><br />
</div><div><br />
</div><div><b>메모리 할당과 해제가 항상 일대일로 대응될 필요는 없다</b></div><div><br />
</div><div>예를 들어 DOM -- 자바스크립트가 실제 문서와 통신하는 인터페이스 -- 처럼 객체 생성과 해제가 빈번하게 일어나는 경우를 들 수 있다. (사실 DOM 성능은 자바스크립트 성능에 있어 무시 못 할 정도로 큰 비중을 차지한다.) 꼭 DOM까지 들지 않더라도 한 함수를 벗어나면 수많은 객체가 한꺼번에 사라진다거나 하는 경우도 해당하겠다.</div><div><br />
</div><div>이런 경우 보통 메모리 풀(memory pool)을 사용하게 된다. 메모리 풀은 어느 정도 이상의 메모리를 항시 할당해 놓고 대신 최대한 빠른 객체 생성/해제를 지원한 뒤 나중에 모두 필요 없어졌을 때 한꺼번에 날려 버리는 관리자 객체이다. 만약 해제를 일부러 완전히 무시하고 메모리 풀이 날아갈 때 한꺼번에 해제시킨다거나 하면 이 관리자 객체는 바로 가비지 컬렉션(garbage collection; 좀 더 엄밀하게는 여러 개의 메모리 풀을 두면 generational GC가 된다)을 구현하게 된다.</div><div><br />
</div><div>골수 C/C++ 프로그래머는 가비지 컬렉션을 못마땅하게 생각할지 모르지만, 이로 얻는 장점은 단순히 개발자의 편의 뿐만이 아니다. free나 delete 연산자를 호출했을 때 메모리가 항상 해제되어야 한다면 메모리 관리자는 매 free 요청마다 작업을 해야 하지만, 메모리 관리자가 자율적으로 해제를 계획할 수 있다면 여러 개의 free 요청을 묶어서 훨씬 효율적으로 처리를 할 수 있다. 실제로 메모리 할당이 잦은 큰 C/C++ 프로그램을 <a href="http://www.hpl.hp.com/personal/Hans_Boehm/gc/">Bohem GC</a>를 사용하게 살짝 고쳤는데 꽤&nbsp;성능 향상을 보았다는 얘기도 있다. (Bohem GC는 C/C++의 특성 때문에 accurate GC를 쓸 수 없어서 훨씬 비효율적[1]인데도!)</div><div><br />
</div><div>당연하지만 가비지 컬렉션이 만능은 아니다. 일단 좋은 가비지 컬렉터를 만드는 건 무진장 어려우며, 특히 대부분의 경우에 성능이 좋게 하는 게 힘들다. (만약 "대부분"에 속하지 않는 경우라면 직접 상황에 맞게 알고리즘을 만들어야 할지도 모르겠다.) 프로그램 로직이 잘못되었다면 제 아무리 가비지 컬렉터가 좋아도 메모리 누수에 빠질 수도 있다.[2]&nbsp;또한 가비지 컬렉션은 정확한 성능 예측을 어렵게 만들고, 특히 실시간(real-time) 처리에 매우 부적합하다. (물론 실시간 처리를 할 때도 메모리 풀은 여전히 유용할 수 있다. 하지만 이 쯤 되면 뭘 해도 이 정도 삽은 파야 겠지.) C/C++ 같이 가비지 컬렉션을 고려하지 않고 만들어진 프로그래밍 언어에서는 선택의 폭이 꽤 줄어든다는 점도 있겠다.</div><div><br />
</div><div><br />
</div><div><b>어차피 운영체제도 해제를 한다</b></div><div><br />
</div><div>또 하나 중요한 사실은 내가 해제를 안 해도 운영체제는 프로그램이 끝날 때 할당된 메모리를 해제한다는 것이다. 이것은 현대 운영체제들이 가상 메모리 시스템을 구현하기 때문에 가능한 것으로, 이게 안 되면 운영체제에 버그가 있는 것이다. 물론 오래 돌아 가는 프로그램은 프로그램이 도는 동안 사용하는 메모리를 일정 수준 이하로 유지해야 하지만, 짧은 시간동안 동작하고 만다면 그냥 free를 안 하는 게 오히려 성능에 도움이 될 수도 있다. (하지만 따라 하지는 말자. 이런 걸 고려할 정도면 이미 대부분의 다른 코드를 최적화했다는 소리니까.)</div><div><br />
</div><div>당장 생각나는 예로는 파이썬 인터프리터 코드에서 <a href="http://svn.python.org/projects/python/trunk/Modules/main.c">Py_Main</a> 함수(사실상 인터프리터의 시작에 해당함) 맨 끄트머리에 있는 이 코드를 들 수 있겠다. 설명은 주석으로 대신한다.</div><div><blockquote><div>#ifdef __INSURE__</div><div><span class="Apple-tab-span" style="white-space: pre; ">	</span>/* Insure++ is a memory analysis tool that aids in discovering</div><div><span class="Apple-tab-span" style="white-space: pre; ">	</span>&nbsp;* memory leaks and other memory problems. &nbsp;On Python exit, the</div><div><span class="Apple-tab-span" style="white-space: pre; ">	</span>&nbsp;* interned string dictionary is flagged as being in use at exit</div><div><span class="Apple-tab-span" style="white-space: pre; ">	</span>&nbsp;* (which it is). &nbsp;Under normal circumstances, this is fine because</div><div><span class="Apple-tab-span" style="white-space: pre; ">	</span>&nbsp;* the memory will be automatically reclaimed by the system. &nbsp;Under</div><div><span class="Apple-tab-span" style="white-space: pre; ">	</span>&nbsp;* memory debugging, it's a huge source of useless noise, so we</div><div><span class="Apple-tab-span" style="white-space: pre; ">	</span>&nbsp;* trade off slower shutdown for less distraction in the memory</div><div><span class="Apple-tab-span" style="white-space: pre; ">	</span>&nbsp;* reports. &nbsp;-baw</div><div><span class="Apple-tab-span" style="white-space: pre; ">	</span>&nbsp;*/</div><div><span class="Apple-tab-span" style="white-space: pre; ">	</span>_Py_ReleaseInternedStrings();</div><div>#endif /* __INSURE__ */</div></blockquote>(사실 그 앞의 Py_Finalize()에서도 비슷한 최적화를 시도할 법도 하지만 파이썬 객체는 finalizer가 있을 수 있어서 정신줄 놓고 메모리를 막 해제하긴 좀 그렇다. 코드 관리도 귀찮아지고.)</div><div><br />
</div><div><br />
</div><div><b>메모리의 수동 해제를 피해라</b></div><div><br />
</div><div>"할당한 메모리는 꼭 해제해야 한다"는 말에는, 당연하게도, 프로그래머가 알아서 해제해야 한다는 뉘앙스가 숨어 있다. 하지만 위에서도 봤듯이 메모리의 수동 관리가 성능을 떨어뜨리는 경우도 상당히 있고, 실수도 하기 너무 쉽다는 문제가 있다.</div><div><br />
</div><div>사실 더 현명한 해결책은 "메모리 관리를 좀 더 지능적으로" 하는 것이겠다. 앞에서 언급한 메모리 풀도 비슷한 얘기고, C++라면 std::auto_ptr이나 뭐 이런 류의 자동화된 객체들을 이용할 수도 있다. (물론 auto_ptr과 shared_ptr을 구분하는 정도의 지식은 필요하다.) C라면... C로 긴 프로그램을 짜려는 건 때려 치우고 최대한 잘게 쪼개서 관리하기 쉽게 해라. -_-;;;;; 개인적으로는 C/C++ 수준으로 저수준을 처리할 수 있는 언어 중에서 이걸 잘 해 주는 언어는 그닥 많지 않은 것 같은데 -- Objective C는 메모리 관리는 눈꼽만큼 낫지만 라이브러리가 병신같아서 제외 -- 내가 몇 년동안 생각(만) 하고&nbsp;있는 새로운 언어의 목표&nbsp;중 하나이기도 하다.</div><div><br />
</div><div>하여튼 컴퓨터가 할 수 있는 일이라면 최대한 컴퓨터에게 시키는 게 현명한 일이니, 가능한한 컴퓨터에게 더 많은 일을 시키도록 궁리하는 게 좋다. 귀찮음을 피하기 위해 새로운 걸 궁리해 낸다면 그 귀찮음은 미덕일 뿐만 아니라 칭송할 일이다.</div><div><br />
</div><div><br />
</div><div><b>메모리가 아니라면 어떻게 해야 하는가?</b></div><div><br />
</div><div>"생성-해제"의 쌍은 비단 메모리 관리에서만 나타나는 게 아니다. 이를테면 파일도 열었다 닫아야 하고, 소켓도 열었다 닫아야 하고... 당연한 얘기지만 메모리에 해당하는 얘기를 이런 데서 갖다 쓰려면 관리하는 대상이 메모리랑 비스무리한 특징을 가져야 하는데 -- 비교적 많은 편이고, 해제가 수동으로 행해져야 하며, 정확한 해제 시점을 맞추지 못 했을 때의 페널티가 크지 않은 -- 안타깝게도 대부분의 대상은 이런 "자원"에서 좀 많이 동떨어진 것들이다.</div><div><br />
</div><div>하지만 메모리 관리에 적용되는 일부 얘기는 다른 객체의 관리에도 적용할 수 있다. 예를 들어 메모리 풀은 추후 할당/해제를 쉽게 하기 위해 어느 정도의 메모리를 미리 할당해 두어야 하는데 이는 네트워크 서버에서 사용하는 커넥션 풀의 개념과 동일한 것이다. 언어의 기능을 최대한 활용해서 버그의 가능성을 줄이는 것 -- 이를테면 파일을 특정 블록 안에서만 열었다 블록 끝날 때 닫는 것 -- 역시 메모리 관리랑 다를 바가 없다. 뭐... 일반론인가?</div><div><br />
</div><div><br />
</div><div><b>결론</b></div><div><br />
</div><div>웬만하면 프로그래밍 배울 때 듣는 모든 얘기는 많이 익힌 뒤에 한 번씩은 의심해 봅시다.</div><div><br />
</div><div><br />
</div><div>[1] Accurate GC라 함은 어떤 객체가 어떤 다른 객체를 참조하는지 정확히 알&nbsp;수 있다는 걸 뜻한다. C/C++에서&nbsp;객체 안에 있는 포인터나 뭐 그런 것들의 목록을 받는 방법은 없으니, Bohem GC는 대신 각 워드가 모두 (일부는 잘못된) 포인터라고 가정하고 최대한 보수적으로 동작하는 conservative GC로 동작한다. 어떤 필드가 포인터는 아닌데 포인터랑 비스무리하게 생겼다면 해제할 수 있는 메모리를 계속 잡아 두고 있을 수도 있으니 당연히 비효율적이다.</div><div>[2] <a href="http://minjang.egloos.com/2372567">가비지 컬렉터에 대한 오해</a>&nbsp;(덤: 블로그 정주행 내지 역주행 추천.)</div><br/><br/>tag : <a href="/tag/메모리" rel="tag">메모리</a>,&nbsp;<a href="/tag/할당" rel="tag">할당</a>,&nbsp;<a href="/tag/해제" rel="tag">해제</a>,&nbsp;<a href="/tag/메모리관리" rel="tag">메모리관리</a>,&nbsp;<a href="/tag/자원관리" rel="tag">자원관리</a>,&nbsp;<a href="/tag/프로그래밍" rel="tag">프로그래밍</a>			 ]]> 
		</description>
		<category>메모리</category>
		<category>할당</category>
		<category>해제</category>
		<category>메모리관리</category>
		<category>자원관리</category>
		<category>프로그래밍</category>

		<comments>http://arachneng.egloos.com/1566708#comments</comments>
		<pubDate>Wed, 22 Jul 2009 20:00:10 GMT</pubDate>
		<dc:creator>아라크네</dc:creator>
	</item>
</channel>
</rss>
