왕미친놈의 왕미친세상

스프링노트를 자주 사용한다. 아니, 아예 끼고 산다고 해야 옳겠다. 블로그를 시작하면서부터 도아 님이 알려준 스프링노트를 써서 글을 발행하고 있기 때문이다. 처음 글 몇 개를 제외하고는 모두 스프링노트에서 작성했다.

그런데 최근에 자잘한 오류가 눈에 띄기 시작했다. 오류보고를 하려고 해도 재현을 하지 못해서 참고 있었다. 그러나 이번에 황당하게 재현하게 되어서 소개하고자 한다.

벌레의 유형

1. 이 벌레는 남의 영역을 침범하는 벌레이다.
2. 특정 웹브라우저에서는 자기 자신을 감추어버리는 은신술의 달인이다.

보통 경로명 등이 길어지면 경로명 일부를 ... (마침표 3개) 등으로 대치하는데, 이 벌레는 아예 태그가 있던 영역을 지워버렸다. 물론 인터넷 익스플로러에서는 다른 것이 표시되어야 하는 영역을 침범할 뿐 자기 자신의 일부를 그대로 나타내 주었다.

벌레의 발견

스프링노트에서 글을 작성하다가 너무 많은 태그를 입력하자 갑자기 태그 전체가 사라져 버렸다. 태그 고치기 단추와 태그 표시 단추가 모두 사라진 셈이다.

오류 없이 태그를 보여주는 화면

정상적인 상태에서는 위와 같이 나타난다. 이때 현재 편집하는 글의 상태를 알 수 있는 상태 표시줄만 따로 떼어내면 다음과 같다.

상태 표시줄 화면

글을 편집하다 보니 태그를 너무 많이 입력하게 되었다. 그러자 내 파이어폭스에서 태그 표시 아이콘, 태그, 태그 편집 아이콘이 사라졌고, 아울러 페이지 히스토리 아이콘과 CCL 표시도 사라져 버렸다.

모질라 파이어폭스에서는 너무 많은 태그를 입력하자 아예 사라져 버린 태그 목록과 태그 표시 및 태그 입력 아이콘. 그리고 그 오른쪽 구성물도 사라졌다.

왼쪽 내비게이션을 감추자 비로소 입력한 태그 목록과 태그 표시 및 태그 편집 아이콘이 나타났다.

인터넷 익스플로러에서는 태그 목록과 태그 표시 아이콘은 남았으나, 태그 편집 아이콘과 그 오른쪽 구성물이 사라졌다.

왼쪽 내비게이션을 감추자 태그 편집 아이콘과 페이지 히스토리는 나타났으나, CCL 표시는 다시 나타나지 않았다.

위와 같이 모질라 파이어폭스(3.0.9판)와 인터넷 익스플로러(v6 sp2)에서는 그 정도의 차이가 있지만 제대로 화면에 출력해 주지 못하는 상태였다. 구글 크롬이나 오페라 등의 웹브라우저에서도 그다지 다르지 않은 결과를 나타내리라 생각한다.

현재 이와 관련한 해결책은 태그를 많이 입력하지 않는 방법뿐이다. 응급책으로는 왼쪽 내비게이션과 오른쪽 책갈피를 모두 감추고 쓰는 것도 한 방법이 될 수 있다.

회사 측 답변

2009년 4월 26일 현재 오류를 보고한 상태이며, 태그 표시를 수정하겠다는 답변을 받았다.

관련 문서 및 페이지

• [벌레와 팁] - 스프링노트의 링크 편집 벌레
• 스프링노트 홈페이지 : http://www.springnote.com/ko

이 글은 스프링노트에서 작성되었습니다.

들어가며

사용자는 프로그램을 사용하다가 버그가 발생하면 그것을 제작자(혹은 제작사)에 알려주게 된다. 이러한 행위를 버그리포팅(bug reporting; 오류 보고)이라고 하며, 이는 프로그램 수정판(patch version)이나 향상판(upgrade version)에 도움을 주게 된다.

그런데 이러한 버그리포팅을 제작자가 무시하는 경우도 있는데, 이럴 경우 사용자는 불쾌감을 느끼게 된다. 하지만 왜 버그리포팅이 무시되는지는 깊게 생각하지 않는 사람이 많다. 

우선 버그리포팅이 너무 추상적이기 때문에 무시된다. 둘째 재현이 되지 않는 경우에는 무시된다. 셋째로 개발자 측의 정책적인 이유에서 무시되기도 한다. 심지어 답변하는 측의 무지 또는 무성의 때문에 무시되는 일도 있다.

버그리포팅이 무시되는 이유

추상적인 버그리포팅

버그리포팅이 너무 추상적이기 때문에 무시되는 일도 있다. 버그패치를 하려면 구체적인 상황이 제시되어야 한다.

버그는 모든 경우에 발생하는 예는 매우 드물며, 대부분 특정 상황에서 발생하게 된다. 그러므로 버그가 발생한 상황을 구체적으로 기술할 필요가 있으며, 그게 어렵다면 특별한 버그 발생 조건을 명시해야 한다. 그것이 나타나지 않은 버그리포팅은 추상적이라 여겨지고 그 버그리포팅은 무시된다.

개발자 입장에서는 추상적인 상황에 대해 대처할 방법이 없다. 또한 프로그램의 내부 오류가 아닌 이상 버그는 반드시 외부로 표출되어야 하며, 그것은 거의 대부분 특정 조건에 따라 발생하게 된다. 이것은 그 상황을 구체적으로 설명할 수 있음을 나타낸다. 그러므로 반드시 버그가 발견되면 그 상황을 기록해 두어야 자신이 전달한 버그리포팅이 무시되지 않게 된다.

재현 불가

버그리포팅을 하기 전에 자신이 발견한 버그를 재현해 보아야 한다. 자신이 생각하는 그 상황에서 버그가 발생하는지를 시험해 보아야 한다는 뜻이다.

버그가 재현되지 않는다면 주로 (1) 그것은 일시적인 현상이거나, (2) 그게 아니면 내부적인 오류가 있는데, 그것이 사용자가 알지 못하는 어떤 이유로 외부로 표출된 경우이다. (1)의 경우는 프로그램 오류이기보다는 시스템의 문제이거나 설치된 프로그램끼리 충돌하는 경우 등으로 재현이 어려운 경우도 있고, 아예 그 상황 자체가 다시 나타나지 않을 수도 있다. (2)의 경우는 일반 사용자는 알 수 있는 방법이 없고, 이 경우 버그의 재현은 거의 불가능에 가깝다.

버그가 재현되지 않는 또 다른 이유는 버그의 발생원인을 착각했기 때문이다. 이 경우 버그는 존재하지만 발생원인을 착각했기 때문에 자신이 생각하는 이유로는 재현되지 않게 된다.

마지막으로 사용자는 재현에 성공했지만 개발자 측에서는 재현에 실패하는 경우도 있다. 이것은 하드웨어적인 문제가 겹치거나 사용자의 시스템 환경과 개발자의 시스템 환경이 판이하게 다른 경우에 발생한다.

정책적인 이유

개발자나 회사의 정책적인 이유로 버그리포팅이 무시된다.

개발자 측의 정책에 따라 최신 버전이 나오게 되면 이전 버전에 대한 버그리포팅은 무시되기도 한다. 예컨대 인터넷 익스플로러 5 이전 버전은 현재 버그리포팅을 무시하고 있다.

버그 패치를 적용하면 속도 저하 등의 현상이 생기는 예도 있다. 그런데 그 속도 저하 등 성능 저하가 심하다면 버그리포팅은 일정 기간 무시되기도 한다. 물론 중대한 보안버그라면 반드시 적용되겠지만, 그렇지 않다면 일정기간 무시될 수 있다는 말이다.

마지막으로 경쟁사 제품과 관련한 버그는 무시하는 경우가 있다. 이런 경우 고의적으로 경쟁사 제품의 설치 및 사용을 막는다는 의심을 받기도 한다.

답변자의 무지 또는 무성의

답변자가 글을 제대로 읽지 않거나 버그리포팅 내용을 확인하지 않아서 무시되는 경우도 있다. 나와 네이버는 악연인지 버그리포팅이나 항의글이 무시되는 경우가 많았다. 특히 답변자가 해당 내용을 알지 못하거나, 버그리포팅 내용을 확인하지 않아서 엉뚱한 답변을 하는 경우도 있었다.

• 네이버 결계 벌레 : 파일이 존재함에도 "삭제한 파일이기 때문에 접근할 수 없다."라고 답변이 왔다. 또한 그 게시글에서 분명히 "홈페이지 등록 갱신을 거부합니다."라고 했는데, 나중에는 네이버 측에서는 내가 "홈페이지 등록 요청"을 했다고 주장했다.
• 네이버에 파이어폭스에 대해 물었는데 익스플로러에 해당하는 답변을 하는 경우가 있다. 초보적인 오류임에도 다른 사이트에서는 일어나지 않는 일이 네이버에서는 몇 차례나 일어난다.
• 그밖에 자주 나타나는 무성의한 답변으로는, 프로그램이나 제작자를 가리지 않고, 버그리포팅에 나타난 내용을 해결책으로 제시하는 경우이다. 다시 말해 버그리포팅을 할 때 A라는 작업을 했음에도 결과가 나아지지 않았다고 버그리포팅을 했음에도 다시 A라는 작업을 하라고 답변하는 경우가 많다.

답변자의 무지 또는 무성의는 매우 심각한 결과를 가져온다. 왜냐하면 버그리포팅이 무시되는 경우 일반적으로 사용자는 그 사실을 알 수 없다. 그러나 이러한 답변자의 무지나 무성의는 답변자가 바로 알아차릴 수 있고, 그에 대해 허탈함이나 불쾌감을 가지게 된다. 이는 대답하는 사람이 가져야 할 기본적인 소양, 곧 "질문 내용이나 버그리포팅 내용을 제대로 읽기"를 하지 않았다는 말이 되기 때문이다.

대응

버그리포팅이 무시되면 대응할 방법이 거의 없다. 추상적인 버그리포팅의 경우는 "개발자에게 의견을 전달했다."라는 식으로 말할 뿐이며, "재현 불가"는 재현할 수 없다는 말을 되돌려준다. 정책적인 이유라면 그 역시 "회사 정책상 지원하지 않는다."라는 말을 하게 되며, 답변자의 무성의는 어쨌든 답변은 받은 셈이다.

이때 추상적인 버그리포팅이나 재현 불가는 당장 할 수 있는 일이 없다. 그저 다시 버그가 나타나기를 기다려야 한다. 버그가 다시 나타나면 다행이고 그게 아니라면 어쩔 수 없이 포기해야 한다. 물론 나중에 다시 버그가 발생하면 그때 다시 버그리포팅을 하면 된다. 한/글/ 2005에 나타난 구결 표기 오류를 참조하라.

회사 정책상의 이유라면, 그것이 중대한 버그인지를 먼저 생각해야 한다. 사소한 버그이거나 다른 기능과의 충돌 때문에 "구현하지 않은 기능"일 수도 있기 때문이다. 다시 말해 사용자 설명서 등에 "불가능한 기능" 또는 "제공하지 않는 기능"이라는 식으로 기술되어 있다면 일단 버그가 아니다. 물론 사용자 입장에서는 버그라고 여겨지겠지만, 회사의 입장에서는 버그가 아니므로 "회사 정책"상 버그 수정은 하지 않게 된다. 만약 중대한 버그라면 반드시 추가로 버그리포팅을 하는 편이 좋다.

관련 문서

• [벌레와 팁] - 네이버 결계 벌레
• [벌레와 팁] - 한/글/ 2005에 나타난 구결 표기 오류

이 글은 스프링노트에서 작성되었습니다.

읽기에 앞서

네이버 블로그에 질문을 올렸더니 아주 황당한 답변이 왔다. 바로 "삭제한 파일이기 때문에 접근할 수 없다."라고 했다. ㅡㅡ; 도대체 지금도 멀쩡히 있는 테스트 페이지와 테스트 파일을 무슨 근거로 삭제되었다고 하는지 모르겠다.

그리고 네이버의 외부링크는 IMG 태그나 OBJECT, EMBED 태그 등으로 연결된 자료뿐만 아니라 A 태그로 연결된 자료도 제한하고 있다.

벌레의 유형

• 이 벌레는 유난히 거짓말이 심하다. 2003년 무렵 웹상에 있으면 당연히 접근할 수 있다는 요지의 답변을 받은 적이 있기 때문이다.
• 이 벌레는 네이버 외부에서 들어오는 접근을, 웹파일(HTML 등)으로 들어오는 접근이 아니라면, 우선 막고 보는 강력한 결계를 작동시킨다. ㅡㅡ;
• 블로그도 웹(WWW)이기 때문에 게시자는 누구나 자신의 게시물을 자신이 설정한 저작권 규칙에 따라 이용할 수 있으리라 생각하고 게시하게 된다. 내 경우는 특별한 의미나 가치가 없다면 대부분 [저작자표시-사용제한금지-동일조건변경허락]이라는 지극히 자유로운 조건을 내걸고 있다. 그런데 이 경우 네이버처럼 접근 제한을 걸게 되면, 오히려 저작권 위반이 된다고 여겨진다. 결국 네이버 블로그에서는 CC-BY-SA 자료는 서버에 올릴 수 없다는 결론에 도달한다. 설령 서버에 올리더라도 실제로 이용할 수 있는 것은 네이버 사용자뿐일는지도 모른다.

벌레의 발견

이 벌레는 네이버에 대해 검색하면서 우연히 알게 되었다. 그러나 그에 대해 그다지 깊이 생각하지 않았다. 그러다가 유난히 네이버를 싫어하는^[각주:1] 도아 님의 블로그에서도 확인하게 되자 조금은 의심하게 되었다.

쇠뿔도 단 김에 빼자고, 네이버 아이디를 가지고 있는 김에 블로그도 만들었다. 그리고 파일을 올렸다. 올리는 도중에 이상한 벌레도 만났다. 아무튼 파일을 서버에 올린 뒤 외부에서 접근했다.

• 그림 파일 : http://blogfiles13.naver.net/data41/2009/4/5/156/test-naver_superior2000.png
• 압축 파일 : http://mfiles.naver.net/9442a17b6e3458ebc198/data44/2009/4/5/50/multiarch-superior2000.zip

일단 위의 그림이 어떻게 보이는지부터 알아보자. 아래에는 <img src="http://blogfiles13.naver.net/data41/2009/4/5/156/test-naver_superior2000.png" width="493" height="299"> 라는 태그가 있으나 빈줄로 나타난다.

아울러 위의 두 파일 모두 HTTP404 오류를 보이면서 정상적인 접근을 할 수 없었다. 다시 말해 A 태그로 연결된 경우도 제한하고 있다는 뜻이다.

정상 상태라면 아래처럼 보여야 했다.

이때 특이한 현상을 발견했는데, 바로 주소 표시줄에 주소를 입력하고 엔터를 치면 위와 같은 정상적인 화면을 보여준다는 점이다. 이 말은 그림 파일을 A 태그나 IMG 태그를 써서 화면에서 볼 수는 없지만, 다운로드는 가능하다는 말이다. 그런데 그림 파일을 직접 화면에서 보지 않고 다운로드 하는 사람이 얼마나 될까? 더구나 내가 올리는 파일은 "예술적"인 이미지도 아니라서 그림 하나를 받느니, 차라리 페이지 전체를 받는 쪽이 훨씬 이익이다.

그때는 무슨 일이?

한편 2003년 11월에 내가 만든 홈페이지가 네이버에 엉뚱하게 등록되어 있는 문제로 약간의 다툼이 생겼다. 그때 아래와 같은 답변을 받았다.

재미 있는 점은 세 가지이다. (1) 하나는 네이버봇의 업데이트 시기에 웹상에 웹문서가 떠있다면 웹문서 검색결과로 나오는 것은 당연한 일이라고 말한다는 점과, (2) 다른 하나는 내가 홈페이지 등록을 요청했다고 하는 점이며, (3) 마지막으로 고객이 등록 요청한 이상 검색에 나와서 문제가 되는 개인정보라고 볼 수 없다고 "생각한다"는 답변이었다.
이 세 가지 모두 당시도 지금도 말이 안 되는 사항이다. (1)번에 대해서는 robots.txt로 설정되어서 구글조차 접근하지 못하던 때였다. 오직 네이버만 접근해서 데이터를 긁어갔다는 뜻이 된다(현재는 구글만 접근 가능하다). (2)번에 대해서는 내가 등록을 요청한 적이 없다. 내가 요청한 바는 네이버 등록 갱신 거부였다. (3)번에 대해서는 웹에 공개된 정보라도 문제가 되는 개인정보일 수 있다는 점이다. 이 점은 좀 더 뒤(2004년 무렵)에 구글에서 개인 주민등록번호가 검색되어서 물의를 빚었다. 다시 말해 네이버의 말은 이치에 맞지 않는다.^[각주:2]

다음 그림은 2003년에 보냈던 개별 페이지가 검색되지 않도록 조치해 달라고 했다. 이 내용은 내가 등록 갱신 거부를 하자, 그게 불가능하다고 해서 네이버에서 답변이 오자 요청 내용을 바꾸게 되었다.

위의 요청을 하기 전에는 어떤 것이었냐고? 내용까지는 필요없고, 제목만 보여 주겠다.

내용을 몰라서 서운한 점은 없으리라 생각한다. 네이버 고객센터에서는 친절하게 메일 제목을 그대로 되돌려주었기 때문이다. 2002년 12월 19일에 받은 답변이다. 분명히 "홈페이지 등록 갱신을 거부합니다."라고 했다. 내가 홈페이지 등록을 요청한 적이 한 번도 없다는 점은 두말하면 입 아프다.

네이버봇은 되고, 사람은 안 된다?

내 홈페이지 등록이야 이미 오래전에 지나간 일이니 넘어가기로 하고, 지금 중요한 점은 다른 데 있다.

바로 위의 내용대로라면 네이버봇은 접근 금지한 웹페이지 접근해도 되며, 사람은 접근 허용된 웹페이지조차 접근할 수 없다는 점이다.

웹문서 검색결과는 웹상에 존재하는 문서에 대해서 네이버의 웹문서 검색 로봇이 주기적으로 색인 하여 웹문서 검색에 반영 하는 것으로, 방대한 분량의 웹문서를 색인 하는데에는 오랜 시간이 소요되므로 실제 웹상에 존재하는 데이터와의 시간차가 생길 수 있습니다.
웹문서의 변경된 내용은 3~4주의 간격으로 자동으로 업데이트가 됩니다.
그 업데이트시기에 웹상에 고객님의 웹문서가 떠있다면 웹문서 검색결과로 나오는 것은 당연한 일입니다. 웹문서 검색로봇은 등록된 홈페이지와 등록요청한 홈페이지, 다른 사이트에 등록된 홈페이지까지 포함해서 검색되는 기능입니다.

아무것도 아니라고 여길 수도 있는 위의 내용은 분명히 네이버봇(네이버의 웹문서 검색 로봇)이 웹상에 존재하는 문서에 접근하고 있음을 뜻하고 있으며, 그에 대해 웹상에 있다면 당연히 검색결과로 나온다고 하였다. 이것은 곧 웹상에 있으면 접근을 막을 수 없다는 결론에 도달한다. 나아가 앞서 말한 robots.txt로 막았더라도 접근할 수 있다고 주장하고 있다.

그런데 이번 네이버 블로그 데이터를 외부에서 접근하기 힘든 사건은 그러한 네이버의 답변을 정면으로 부정하고 있다. 다시 말해 네이버 블로그에 대해서는 내가 네이버로부터 2003년에 받은 답변은 사실이 아니다.

도아 님이 말씀한 "세상에서 가장 심한 욕"이 절실히 느껴진다.

회사 측 답변

2009년 4월 8일 현재 답변을 받았다. 그런데 아주 어이없는 답변이다.

어이가 없을 지경이다. 지금도 웹에 있는 그림이거늘, 삭제되었다니?

아래의 길쭉한 파일은 메일 원본을 잡은 화면이다.

관련 문서

• 도아의 세상사는 이야기 : 세상에서 가장 심한 욕
• 네이버 블로그 테스트 페이지

이 글은 스프링노트에서 작성되었습니다.

벌레의 유형

티스토리에 이어 네이버에서도 몸집을 키우는 뻥튀기 벌레가 있었다.

• 알려주지 않고 파일 용량을 늘리는 벌레 : 몸속에 뻥튀기 기계를 갖추고 있지 않을까?

벌레의 발견

티스토리의 뻥튀기 벌레와 비슷하면서도 조금 다른 벌레이다.

이 벌레도 티스토리에서처럼 업로드 된 뒤에 파일 용량이 커질 수 있다는 경고를 한마디도 하지 않고 있다. 티스토리에서는 파일 형식이 바뀐 반면 네이버 뻥튀기 벌레는 파일 형식은 그대로 유지하면서 파일 크기를 늘이는 벌레이다.

http://blogfiles13.naver.net/data41/2009/4/5/156/test-naver_superior2000.png 파일인데, 자료 화면은 아래와 같다. 분명히 10.12 킬로바이트이고,10364 바이트이다.

그런데 네이버 블로그에 올리기 전의 파일 등록 정보는 아래와 같다.

이 파일은 내가 새벽에 잠이 깨어 멍한 상태에서 작업한 파일이다. 네이버에 올린 파일은 모든 설정을 공개 상태로 놓아도 외부에서 접근할 수 없다는 심증을 가지고, 그에 대한 증거를 얻기 위해 작업한 파일이다. (2009년 4월 5일 오전 11시 12분 52초 현재 그 심증은 확증을 얻은 상태이다.)

또한 네이버 블로그에 글을 올릴 때 설정한 화면은 다음과 같다.

위에서 보면 내가 올린 그림의 섬네일 이미지가 보이면서 "10.1 KB"라고 표기하고 있다. 이미 이미지 파일을 올리는 순간 내 파일을 나에게 알려주지도 않고 마음대로 변형해 버렸다는 증거이다.

그런데 좀 더 아래에 "설정정보"를 보면 전체 공개, 덧글 허용, 본문 스크립 허용(링크도 허용), 검색 허용, 블로그 정보 수집 허용, CCL 표시(위에는 나타나 있지 않지만, "저작자표시-동일조건변경허락"이다.) 등의 설정이 나타나 있다.

여기에서 네이버 뻥튀기 벌레도 티스토리 뻥튀기 벌레처럼 파일 업로드에서 이미 활동하고 있다는 심증을 굳힐 수 있었다.

기타

부수적으로 네이버는 저작권자의 저작권 설정과는 무관하게 외부 링크가 불가능하다는 점도 알게 되었다.

http://blogfiles13.naver.net/data41/2009/4/5/156/test-naver_superior2000.png

위 파일을 클릭하면 새 창(또는 새 탭)이 열리면서 그림 파일을 보여 주어야 하지만, 그림 대신 "The page cannot be found"라는 메시지를 보여주게 된다. 이와 관련하여 다른 게시 글을 올릴 계획이다.

회사 측 답변

2009년 4월 7일 현재 앞으로 수정할 예정이라는 답변을 받았다.

관련 문서

• 2009/03/21 - [벌레와 팁] - 티스토리 그림 파일 업로드 벌레

이 글은 스프링노트에서 작성되었습니다.

읽기에 앞서

네트워크와 관련한 부분은 알약의 벌레가 아니었음을 밝힙니다. 시스템의 내장 랜 모듈에 과부하가 걸려 일시적으로 정지되는 현상이었음을 확인하였습니다.

벌레의 유형

• 벌레를 발견한 프로그램 및 버전 : 알약 1.32 버전(2009년 3월 12일자)에서 나타난 벌레이다. 그 이전 버전에서는 확인하지 못하였다.
• 사용한 선택사항 : 검사하기 >> 정밀 검색
• 벌레의 위험도/중요도 : 2단계 (중요) / 기초적인 벌레
• 벌레의 특징 : 이 벌레는 기본기가 허술한 알약의 약점을 찌르고 있다.

벌레의 발견

알약이 가진 벌레는 크게 두 가지이다.

• 특정 경로에서 알약이 압축파일을 열려고 하면, 알약을 얼려 버리는 벌레.

  • 그와 함께 알약이 얼면 네트워크를 죽여 버리는 벌레.
  • 또한 얼어버린 알약을 종료하면 화면에서만 사라지고, 실제로는 백그라운드에서 동작하고 있다.
• 바이러스 검사가 끝난 뒤 결과 화면에서 다른 메뉴를 선택하면, 바이러스 검사 결과를 먹어치워서 없애 버리는 벌레

앞서 알약 웹페이지에 3월 27일 글을 올려서 그날 바로 답장을 받았다. 그러나 좀 더 정확한 사항을 알기 위해 다시 질문을 올렸으나 아직 답변을 받지 못했다. 아마도 주말이라서 해당 업무를 보지 않았기 때문으로 여겨진다. 아무튼 그날의 답변만을 올리겠다.

이것을 하나하나 분석하면 다음과 같다.

• 압축 파일 자체는 이상이 없었다. : 이것은 나도 같은 의견이다.
• 검사 중 이상 현상은 발견하지 못했다. : 그런데 내 컴퓨터에서는 발생했다. 알약의 프로그램 오류 여부는 답변 없음.
• 검사 완료 후 다른 메뉴로 이동하는 경우 검사가 초기화 되니 다시 하라. : 설마 4시간 동안 검사했던 것을 다시? 조금 어이없는 답변이다.
• 광고창은 일시적인 전송 실패이다. : 그런데 왜 네트워크 기능 전체를 죽이는지? 답변이 없었다.
• 쿠키 삭제 등을 했으나 그대로였다. : 삭제 전 1메가에서 삭제 후 900킬로바이트였다. 다시 말해 쿠키 등을 삭제해도 결과는 같았다.
• 지속적으로 발생하여 추가 문의하였다. : 이것에 대해서는 3월 31일 현재 답변이 없다.

과정 재현

우선 검사 과정을 재현해 보자.

분명히 정밀검사를 선택했다.

검사 시작 3분 만에 잡은 화면이다.

여기까지 보고는 그냥 종료했다. 오른쪽 위의 X 표시를 클릭하여 종료하는 방법을 택했다. (밥 먹고 왔다.)

이때 돌발 상황이 발생했다. 아무리 봐도 CPU 사용량이 너무 많았다. 거의 50%에 육박하고 있지 않은가?

이미 종료되었어야 할 알약이 살아남아서 CPU 점유율 50%를 꿋꿋히 지키고 있었다. 알약은 불사신이라 말인가?

알약을 얼리는 벌레→파일 열기 벌레

이 알약의 벌레가 치명적이라 여겼는데, 그보다 한 단계 낮추어 2단계(중요)로 보았다. 왜냐하면 네트워크 기능을 죽이지 않는 한 정상 작동한다고 여겼기 때문이다. 그런데 이때 기본적인 벌레를 발견할 수 있었다.

일단 지난 번에 awardeco.arj 파일에서 수십 분에서 몇 시간에 걸쳐 검사가 중지된 벌레를 소개했다. 그것을 유심히 살펴보다가 아주 황당한 사실을 하나 발견했다. 설마 이런 벌레가 아직까지 멸종하지 않고 살아남았다는 사실에 경의를 표하고 싶어질 정도로 황당한 벌레였다. 위에서 유심히 살펴보면 유독 awardeco.arj 파일에서 문제가 발생하고 있다. 그런데 이 파일은 아무런 문제가 없는 파일이었다. 이것은 이스트소프트에서도 인정했다.

그럼 도대체 무엇이 문제였을까?

우선 지난번에 보았던 화면을 다시 게시하겠다.

위에서 보면 경로명이 유난히 길고, 폴더의 중첩이 심함을 알 수 있다. 아래 그림을 보자.

위에서 보면 무려 9단계에 이르고 있다. 이때 awardeco 폴더를 C:\ 로 옮기면 아무런 문제가 생기지 않고, 바이러스 검사도 무사히 마쳤다.

조금 오래전부터 준비하던 기사 내용이 머릿속을 번개처럼 스치고 지나갔다. 2009/03/30 - [배치파일&스크립트] - 이런저런 이야기 참조.

그렇다. 도스에서는 디렉터리를 7단계까지 만들 수 있다. 그런데 이 황당한 벌레는 도스와 윈도를 착각하고, 윈도에서도 버젓히 살아남아 버렸다.

어이, 이스트소프트! 도대체 왜 이 벌레를 키웠단 말이더냐?! 윈도95가 나온 지 벌써 14년인데, 아직까지 이게 멸종을 안 했다니 놀라울 따름이다.

벌레의 원인 및 퇴치

벌레가 생긴 원인은 알 수 없었다. 다만 위에서 말한 지나치게 긴 경로명이 문제가 되었고, 다른 하나는 이스트소프트에서 배포하는 프로그램 폴더에 있었다.

알툴즈 설치 폴더는 보통 %ProgramFiles%\ESTsoft 이다. 내 경우에는 D:\Bin\ESTsoft 폴더이며, 보통은 C:\Program Files\ESTsoft 폴더이다. 이때 알약 프로그램 폴더는 %ProgramFiles%\ESTsoft\ALYac 이다.

이 벌레를 퇴치하고자 이것저것 만지다가 레지스트리를 날려보기도 했다. 물론 실행될 턱이 없으니 백업본을 이용해서 바로 복구시켰다. 폴더를 다른 곳에 복사해놓은 뒤에 하나씩 지워보기도 했다. 그러다가 알게 된 사실은 전혀 엉뚱하게도 알약 프로그램이 아닌 알툴즈 전체의 업데이트 프로그램 또는 폴더에서 발생했거나, 적어도 이 벌레와 관련이 있다는 사실을 알게 되었다.

이것을 쉽게 발견하지 못한 데에는 이유가 있었다. 바로 그 폴더 또는 파일에 손상을 입었음에도 알약 프로그램의 업데이트를 정상적으로 수행했다. 다시 말해 3월 12일에 엔진 업데이트도 정상적으로 수행했고, 그 뒤에 여러 차례 수행한 DB 업데이트도 정상적으로 수행했기 때문에 그 폴더가 원인이라는 사실을 알 수 없었다. 하지만 그것이 직접적인 원인인지는 여전히 알 수 없다. 다만 어떤 이유에서인지 업데이트 프로그램이 있는 %ProgramFiles%\ESTsoft\ALUpdate 폴더가 손상되었고, 그에 따라 알약도 이상 증상을 보였음을 알게 되었을 뿐이다.

아무튼 그 폴더를 아예 지워버린 뒤 알약을 실행시키면 알아서 복구를 해준다. 그 뒤로는 이 벌레를 만날 수 없었다.

또한 업데이트 프로그램 폴더를 삭제한 뒤 복구되면, 업데이트를 수동으로 해 두었더라도 자동으로 바뀌는 경우가 있었다. 수동으로 해놓았던 사람은 반드시 확인하기 바란다.

또한 업데이트 프로그램 또는 폴더에 이상이 생겨서 발생했으리라는 유추가 가능하므로, 아예 알약 프로그램을 제거했다가 다시 설치해도 정상 작동하리라는 추측이 가능하다. 그러나 그냥 업데이트 폴더만 지우기를 권장한다. 간혹 업데이트 받는 데 시간이 오래 걸릴 수도 있기 때문이다.

너무 황당하게 벌레가 잡히는 바람에 재현조차 못하였다. 그래서 업데이트 폴더를 지운 뒤의 자료 화면만 첨부한다.

결과적 이 벌레는 두 가지가 복합적으로 작용하여 발생했다.

1. 업데이트 프로그램 또는 폴더(%ProgramFiles%\ESTsoft\ALUpdate)가 손상될 경우
2. 경로의 단계가 7단계를 넘어서는 경우
3. 그리고 위의 두 상황이 동시에 발생해야 한다.

검사 결과를 먹어치우는 벌레

이 벌레에 대해서는 이스트소프트 측에서는 다음과 같이 답변했다.

검사 결과에 등록되는 내역은 검사 후 치료된 결과를 나타냅니다.
사용하시는 검사 과정의 로그를 남기진 않음을 알려 드립니다.

그런데 에브리존의 터보백신이나, 안철수 바이러스연구소의 V3 등에서는 모두 "검사 과정의 로그"를 남겼다. 치료를 하지 않은 경우에는 검사 과정 자체가 정보라는 사실을 깨닫지 못한단 말인가? 아무튼 기본적으로 검사 과정의 로그를 남기는 터보백신이나 V3가 이상한 것일까? 아니면 해달라고 해도 남기지 않는다는 말을 버젓히 하는 알약이 이상한 것일까?

이스트소프트에서 보내온 답변으로는 그것은 벌레가 아니라, 처음부터 그렇게 설계되었기 때문이다. 하지만 그것 때문에 사용자 불편을 겪고 있는 마당에 위와 같은 답변은 조금 문제가 있다고 생각한다.

네트워크를 죽이는 벌레+허깨비 벌레

네트워크 기능을 죽이는 벌레는 이번에도 나타났다. 그와 함께 알약을 종료했음에도 그 프로세스가 남아서 여전히 CPU 점유율을 50% 이상으로 유지시키는 희한한 벌레마저 등장했다. 아마도 지난번에 내가 발견하지 못하고 지나쳤나 보다.

아울러 위와 같은 현상의 원인도 업데이트 폴더(%ProgramFiles%\ESTsoft\ALUpdate)와 관련이 있음을 알게 되었다. 몇 시간 지나면 알아서 꺼져 버리던 네트워크 기능이 잘 살아 있었기 때문이다. (물론 바이러스 검사를 그렇게 오래 할 일이 다시 생기지 않았기 때문일 수도 있다.)

허깨비 현상의 원인은 아주 확실히 알약에 숨어 있는 벌레였다.

위와 같이 기본 실행모드에서는 트레이에 아이콘 표시가 뜨기 때문에 실행 여부를 판단할 수 있었다.

위의 두 그림 가운데 하나처럼 나타난다. 왼쪽의 빨간 알약과 연두색 알약은 동작하고 있다는 표시이고, 오른쪽의 회색 V3는 현재 동작을 하지 않고 있다는 표시이다.

문제는 최소 실행모드에서 발생한다. 저 알약 아이콘이 모두 사라져 버린다. 기본 실행모드에서는 바이러스를 검사하고 있다가 오른쪽 위의 X 표시를 클릭하여 종료해도 트레이에 아이콘이 그대로 남아 있으므로 아직 종료하지 않았다고 알게 되지만, 최소 실행모드에서는 전혀 알 수가 없다. 말그대로 허깨비가 되어 버린다.

결국 허깨비 벌레를 퇴치하려면, 반드시 종료할 때 바이러스 검사를 먼저 종료한 뒤에야 알약 프로그램을 종료해야만 한다. 그렇지 않다면, 나중에 다시 알약을 실행시켰을 때 아까 종료했던 화면으로 시작하게 된다. 이것은 백그라운드에서 계속하여 바이러스를 검사를 하고 있기 때문에 생기는 현상이다. 이것에 대해서는 아무런 도움말을 얻을 수 없었다. 결국 프로그램 종료에 대한 처리 오류 때문에 발생한 벌레인 셈이다.

제작자/제공자의 답변

추가 질문에 대한 답변은 아직 없다.

관련 문서

• 2009/03/27 - [벌레와 팁] - 벌레 잡는 알약, 벌레에 먹히다
• 알약 홈페이지 : http://alyac.altools.co.kr/alyac/alyacinfo.aspx

이 글은 스프링노트에서 작성되었습니다.

읽기에 앞서

이 문제는 티스토리 시스템의 문제가 아님을 확인하였다. 이 글에 나타난 현상을 겪는 사람은 자신의 불여우에 확장 기능 MR Tech's Link Wrapper 가 설치되어 있는지를 먼저 살피기 바란다. 혹시 그것을 설치하였다면, 삭제하기 바란다. 그 확장 기능은 한메일 및 티스토리 시스템과 약간의 충돌을 보이고 있다.

벌레의 유형

티스토리 파일 첨부 창이 파이어폭스에서 제대로 표시되지 않는 문제가 있다.

좀 짓궂게 이야기하면 파일 첨부 창을 잘라먹는 벌레로서, 과식을 자주 하는 듯이 보인다.

벌레의 발견

벌레 정보

티스토리에 가입한 뒤 곧바로 발견할 수 있었다. 그때는 티스토리 그림 파일 업로드 벌레 건에 매달려 있던 때라 이것은 그다지 신경을 쓰지 않았다. 그러나 매번 그림을 올릴 때마다 파일 첨부 창을 아래로 늘여야 하기에, 귀찮음이 더해져서 결국 올리게 되었다.

우선 이 벌레가 익스플로러에서 발견된 적은 없다. 한메일 프리징 현상처럼 파이어폭스에 특정 확장 기능을 잘못 설치하여 나타나는 문제도 아니었다. 다시 말해 파이어폭스를 설치한 뒤 3.0.4판부터 3.0.7판까지 나타나는 문제이며, 아무 확장 기능도 설치하지 않았을 때에도 발생했다. 참고로 3.0.8판에서는 확인하지 못하였다.

벌레 찾기

아래는 티스토리 글쓰기 화면이다. 오른쪽 파일첨부를 클릭하여 파일 첨부 창을 보이게 한다.

아래 파일 첨부 창은 아래 부분이 조금 이상하다. 맨 마지막 줄에서 "음원 필터링 시스템은 저작권 침해로 인한 문제로부터 회원 여러분을 보호하"라고 나온 뒤 잘려 있다. 오른쪽 아래 파란 화살표가 가리키는 부분을 클릭한 뒤 아래로 드래그 하면 파일 첨부 창이 늘어남을 알 수 있다.

아래 그림은 파일 첨부 창을 아래로 늘인 모습이다. 결국 아래 그림처럼 되어야 하는데, 위의 그림처럼 아랫부분을 잘라먹고 있었던 셈이다.

제작자/제공자의 답변

4월 7일 현재 회사 측으로부터 답변이 왔다. 회사 측에서는 이 문제를 재현하지 못하였으나, 지속적으로 개선안을 찾고 있다고 하였다. 아울러 이 문제가 발생하는 원인으로는 창의 크기을 변화시키는 스크립트를, 창을 읽어들인 나서 불러오기 때문에 일어난 문제로 보고 있었다.

관련 문서

• 2009/03/21 - [벌레와 팁] - 티스토리 그림 파일 업로드 벌레

이 글은 스프링노트에서 작성되었습니다.

벌레의 유형

• 벌레를 발견한 프로그램 및 버전 : 알약 1.32 버전(2009년 3월 12일자)에서 나타난 벌레이다. 그 이전 버전에서는 확인하지 못하였다.
• 사용한 선택사항 : 검사하기 >> 정밀 검색
• 벌레의 위험도 : 1단계 (매우 위험)
• 벌레의 특징 : 이 벌레는 매우 독특하다. 벌레 잡는 알약에 숨어서 알약을 잡아먹고 있기 때문이다. 그밖에 자잘한 벌레도 거느리고 있다.

벌레의 발견

알약이 가진 벌레는 크게 두 가지이다.

• 알약이 압축파일을 열려고 하면, 알약을 얼려 버리는 벌레.

  • 알약이 얼면 네트워크를 죽여 버리는 벌레.
• 바이러스 검사가 끝난 뒤 결과 화면에서 다른 메뉴를 선택하면, 바이러스 검사 결과를 먹어치워서 없애 버리는 벌레.

알약을 얼리는 벌레

일단 다른 벌레도 있는데, 알약의 벌레를, 특히 이 벌레를 먼저 소개하는 이유는 매우 치명적이라고 여겼기 때문이다.

5시간 52분 경과! 그런데 화면에서 보이는 저 파일( awardeco.arj )에서만 50분째다. 저 파일이 크냐? 그것도 아니다. 겨우 수십 킬로바이트이다. 1메가도 안 된다는 말이다. 

44,668 바이트짜리 awardeco.arj 파일을 50분이 넘게 처리하고 있다니.

일단 문제를 알게 되었으니 바이러스 파일만 먼저 치료하기로 하고 정지 뒤 종료했다. 이때 실수로 다른 메뉴(시스템 정리)를 클릭했다가 다시 검사하기를 누르니 검사 결과가 사라져 버렸다. 검사 결과를 먹어치우는 벌레 참조.

일단 엔진에도 문제가 있다고 생각하여 업데이트를 하였다. D 드라이브만 검사하기 >> 정밀검사를 시켰다.

그리고 6시간 뒤... 

아까 압축을 풀어 두었기 때문에 압축파일에서는 안 걸렸지만, 그 압축 파일 안에 있던 저 파일에서 저대로 멈추어 버렸다. 참고로 내가 사용한 컴퓨터 바이러스 백신 프로그램에서는 저 파일을 바이러스로 잡은 백신은 없었다. (하우리, 안철수, 에브리존 모두 바이러스가 아니었다.)

문제는 저 오른쪽이다. 원래는 광고가 떠야 했지만, 어쩐 일인지 저렇게 되어 버렸다. 물론 인터넷이 되지 않았다. 아니 아예 네트워크 기능 전체가 죽어 버렸다.

도대체 바이러스 잡으라니까 파일 열다가 얼어 버린 주제에 왜 네트워크 기능은 죽여 버린단 말인가?

참고로 업데이트를 했지만, 엔진은 그대로였고, DB만 3월 25일자로 바뀌었다.

검사 결과를 먹어치우는 벌레

위의 벌레에 비하면 치료 결과를 먹어치우는 벌레는 애교라고 생각한다. 하지만 이것 역시 위험하기는 마찬가지이다.

C 드라이브만 검사하였다. 드디어 검사가 끝나고, 혹시나 하는 마음에 화면을 잡았다...이면 좋겠다만, 아래 화면은 바이러스 검사를 한 번 더 실행하여 잡은 화면이다. 치료는? 또 4시간을 기다리라고? 그냥 내가 직접 그 폴더에 있는 파일을 지우고, 그 레지스트리를 지웠다.

일단 화면을 보라. 내가 클릭한 메뉴는 결과보기 >> 검사하기 >> 결과보기, 이런 순서이다.

보면 알겠지만, 일단 검사가 끝난 뒤 검사 결과는 저장하지 않고 있다. 물론 바이러스가 있다면 바로 치료하면 된다고 할 수도 있으나, 클릭 실수가 발생할 수도 있으니, 검사 결과 자체를 저장해 둘 필요도 있다는 점을 간과하지 않았나 생각한다.

그렇다고 검사 결과 저장이 매우 많은 용량을 차지하지도 않는다. 치료 결과에 병합하여 저장하면 되기 때문에 그다지 데이터가 늘지도 않는다. 그저 치료 결과에 저장하되, "발견했지만, 치료하지 않았음"이라고 해도 되기 때문이다.

추가

네트워크 기능을 죽이는 벌레는 나타날 때도 있고 나타나지 않을 때도 있다. 위에서 보듯이 첫째 검사화면과 셋째 검사화면에서는 나타나지 않았지만, 둘째 검사화면에서만 나타났다. 그렇다고 중요도가 낮다고 볼 수도 없는 벌레이다. 왜냐하면 이게 알약의 기능(일정 시간이 지나면 네트워크 자체를 차단하는 기능)인지, 아니면 외부 바이러스가 알약의 보안버그를 틈타 침투한 것인지 알 수 없기 때문이다. 물론 항상 발생하는 현상이 아님을 볼 때 보안버그일 가능성이 더 높다.

제작자/제공자의 답변

알약 웹페이지에 3월 27일 글을 올려서 그날 바로 답장을 받았다. 그러나 좀 더 정확한 사항을 알기 위해 다시 질문을 올렸으나 아직 답변을 받지 못했다. 아마도 주말이라서 해당 업무를 보지 않았기 때문으로 여겨진다. 아무튼 그날의 답변만을 올리겠다.

하나하나 분석하면 다음과 같다.

• 압축 파일 자체는 이상이 없었다. : 이것은 나도 같은 의견이다.
  
• 검사 중 이상 현상은 발견하지 못했다. : 그런데 내 컴퓨터에서는 발생했다.
  
• 검사 완료 후 다른 메뉴로 이동하는 경우 검사가 초기화 되니 다시 하라. : 설마 4시간 동안 검사했던 것을 다시?
  
• 광고창은 일시적인 전송 실패이다. : 그런데 왜 네트워크 기능 전체를 죽이는지?
  
• 쿠키 삭제 등을 했으나 그대로였다. : 삭제 전 1메가에서 삭제 후 900킬로바이트였다.
  
• 지속적으로 발생하여 추가 문의하였다.
  

현재 벌레 잡는 알약, 벌레에 먹히다 2를 준비하고 있는 중이다.

관련 문서

• 알약 홈페이지 : http://alyac.altools.co.kr/alyac/alyacinfo.aspx

이 글은 스프링노트에서 작성되었습니다.

벌레의 유형

단순히 화면 출력을 잘못하는 벌레이다.

벌레의 발견

벌레 정보

아크로에디트 버전 0.9 / 빌드 0.9.19.84 (2008년 12월 17일자)에서 발견하였고, 이전 버전 확인하지 못함.

배치파일 구문 강조에서 나타났다.

벌레 찾기

그림1. 주석 명령어 REM을 5번 사용하였으나 2번만 주석이 달렸다. 또한 @도 문법 강조가 되지 않고 있다.

강좌를 올리려고 배치파일을 찾아서 편집하다가 우연히 알게 된 벌레이다.

위에서 보면 배치파일에서 주석을 나타내는 지시자는 REM이다. 엄밀히 말하자면 REM 명령어이다. 이때 배치파일은 대문자와 소문자를 가리지 않으므로 rem, REM, Rem, rEm, reM 등은 모두 주석으로서 작동해야만 한다. 실제로 설정에서도 다음 그림처럼 rem과 REM이 적용되어 있다.

그림2. 행 주석 표시자로 REM을 지정하고 있다.

한편 @ (at)에 대한 문법 강조도 이루어지지 않고 있다.

그림3 / 그림4. 단어 구분 기호에 대한 문법 강조 설정

위 그림에 보면 단어 구분 기호로서 @을 사용하고 있고, 그 색상은 빨간색이다.

그러나 위 그림 1을 보면 문법 강조가 되어 있지를 않다.

제작자/제공자의 답변

AcroEdit - 질문 및 답변에 글을 올린 상태이다. 현재 제작자가 검토를 하고 있는 중이다.

관련 문서

• 주석 및 화면 출력
• 아크로에디트

이 글은 스프링노트에서 작성되었습니다.

벌레의 유형

이것은 벌레가 아니다. 왜냐하면 문법적으로 명확히 옳기 때문이다. 웹의 특성상 웹브라우저에 따라 그 외양이 달라질 수 있기 때문이다. 다만 내가 좋아하여 자주 가는 블로그이기 때문에 이상하게 보이는 것을 참지 못하고 글을 올릴 뿐이다.

벌레의 발견

처음에 집에서 이 현상(?)을 발견했을 때에는 내 컴퓨터 설정의 문제이겠거니 생각했다. 웹페이지의 겉모습은 웹브라우저뿐만 아니라 컴퓨터 설정에도 영향을 받기 때문이다.

그러다가 게임방에서 와이드~~~한 화면을 보니 내 컴퓨터만의 문제가 아님을 깨달았다.

그래서 몇 가지 지적하고자 글을 남긴다.

화면이 크고 넙적해서 어디가 문제인지 잘 보이지 않는다.

오른쪽 상단을 잘라 보았다. 아마도 다음과 같이 보여야 할 것이다.

알림 | 저작권 | 나가기

자칫 아래처럼 오해할 수도 있다.

알림 | 저작권 | 나가

좀 더 아래에 보면 조금 이상한 부분이 한 곳 더 보인다.

컴관련은 괜찮은데, 오늘의 글과 인기글에서는 뒤에 수치가 그 왼쪽의 내용과 어긋난 느낌이다. 실제로 어긋나 있는지는 알 수 없지만, 둘 다 다섯 개씩이므로 아마 어긋났음이 맞으리라 여겨진다.

덧말

어지간하면 홈페이지 관련 문제는 벌레로 올리지 않으려고 했다. 한국에서 Non-IE 유저로 살아가는 삶이란, 웹페이지를 보는 일조차 포기하고 살아야 하며(웹은 분명 "Create once, View Anywhere"가 아니던가?), 사용 포기를 강요당하며 살아야 하며(항의했더니 "IE 쓰세요."라는 말을 억수로 들었다.), 마지막으로 각종 법률에 나타난 정보에의 접근권조차 원천적으로 차단당할 때가 많음을 감수하며 살아야 함을 뜻하기 때문이다.

그럼에도 불구하고 유독 이 사이트만 거론한 까닭은 그저 "좋아하는 블로그"이기 때문이다. 좋아해서 자주 들르다 보니 눈에 거슬리는 일도 자주 겪게 되어서 이렇게나마 글을 올릴 뿐이다.

최근 도아 님의 블로그 "도아의 세상사는 이야기"에서 지식을 얻은 글은 다음과 같다.

1. 2009/03/25 오픈캐스트의 링크를 거절하는 방법 (현재 블로그에 적용되어 있다.)
2. 2009/02/15 RSS 구독자를 쉽게 늘릴 수 있을까?
3. 그밖에 애드센스에 대한 여러 내용이 있지만, 기억이 안 난다. (최근이 아니라서.)

또한 내가 스프링노트에 가입하게 된 까닭도 도아 님에게 있다. 도아 님이 운영하는 QAOS에 가입(유료)했다가 스프링노트에 대해 알게 되었다. 평소에는 잘 느끼지 못했지만, 막상 블로그를 만들게 되니 알맞은 툴이 없었다. 우연히 QAOS의 글에서 봤던 기억이 나서 구글에서 spring으로 검색해서 찾았다. 워드(한글2005)에 익숙해 있다 보니 기능이 적은 감이 있어서 불만이지만, 반면에 역시 워드에 익숙해서인지 단축키 방식이 무척 마음에 든다.

제작자/제공자의 답변

답변을 받았다. 그래서 이것이 벌레가 아님을 명시하였다.

이 글은 스프링노트에서 작성되었습니다.

알리는 말

이 글에 소개된 사항은 중대한 오해와 착오 때문에 오류가 아닌 사실을 기록하고 있습니다. 현재 한/글/ 2005 및 한/글/ 2007 모두 구결을 정상 표기하고 있습니다.

벌레의 유형

분신술을 익힌 벌레로서 몇몇 한/글/ 2005 환경에서만 나타난다. 특히 한/글/ 2005 교육기관용이나 PC방용에서 나타나는 기이한 벌레이다. 이 벌레가 나타나면 비슷한 두 글자가 똑같은 모양이 된다.

벌레의 발견

고문을 가끔 입력하다가 발견하였다.

HNC코드로는 1D72와 1DCE로서, 위쪽 글자는 소릿값이 ‘마‘(또는 ‘매‘)인데, ? 모양입니다. 아래쪽 글자는 소릿값이 ‘애‘인데, ? 모양이어야 합니다. 그런데 ?으로 되어 있습니다.

회사 측 답변1

이 문제는 2008년 3월 15일 오후 8시 32분 현재 해결되지 않았다. 2008년 11월 23일에 회사 측에서 답변한 내용에 따르면 글꼴을 신명조로 바꾸어 보라고 했으나, 해결되지 않았다. 결국 내가 쓰는 컴퓨터에서만 일어난 현상이라고 잠정 결론을 내린 상태였다.

추가

한/글/2005뿐만 아니라 한/글/2007에서도 이 벌레를 발견하였다.

여기에서도 이상하게 보이는 두 글자를 확인할 수 있다.

벌레의 유형

윈도XP에 기생하면서 올바른 키보드를 감추고 보여주지 않게 하는 벌레이다. 이 벌레는 자신을 꼭꼭 감추고 있어서 흔히 버추얼박스에 살고 있다고 착각하게 만든다. 실제로는 윈도XP에 거주하는 벌레이므로 주의가 필요하다.

벌레의 발견

버추얼박스(VirtualBox)는 가상기계(Virtual Machine, 가상머신) 프로그램으로서 현재는 선 마이크로시스템에서 제작 배포하고 있다. 홈페이지는 http://www.virtualbox.org/ 이다.

이것을 이용하여 윈도XP를 가상머신으로 처음 설치할 때 호스트 키를 아무리 눌러도 작동하지 않았다. 처음에는 버추얼박스에 사는 벌레가 있다고 생각했으나, 나중에 해결책을 찾고 나서 보니 아니었다. 이때 호스트 키란 가상기계에 키보드 입력을 가능하게 해주는 키를 가리킨다. 대부분의 가상기계에는 호스트 키를 두고 있으며, 이것은 토글 기능을 가지고 있다.

호스트 키를 눌렸을 때의 화면

호스트 키를 눌리지 않았을 때의 화면

버추얼 박스에서 호스트 키가 작동하지 않을 때에는 자신의 키보드 설정이 무엇인지를 먼저 살펴야 한다. 윈도XP를 설치할 때 설정하지 않았다면 "PC/AT 101키 호환 키보드/USB 키보드(종류 1)"을 사용하게 된다. 보통 때는 이 키보드 설정으로도 아무런 문제가 생기지 않지만, 특별한 경우에는 문제가 생길 수 있고, 버추얼 박스의 호스트 키 문제가 바로 그 특별한 경우이다.

여기에서 호스트 키 때문에 문제가 생기는 경우는 바로 오른쪽 컨트롤 키가 호스트 키로 지정되어 있기 때문이다. 오른쪽 컨트롤 키(Right Control)는 "PC/AT 101키 호환 키보드/USB 키보드"에서 변환 키이다. 다시 말해 "한자 키" 또는 "한영 변환 키"로 쓰이는 키가 바로 오른쪽 알트 키(Right Alt)와 오른쪽 컨트롤 키(Right Control)이다. 그런데 버추얼박스에서 지정한 호스트 키인 오른쪽 컨트롤 키를 누르면 변환 키를 눌렀다고 잘못 인식되어 벌레가 활동하게 된다. 이것은 버추얼박스와는 상관 없는 윈도XP의 문제이다.^[각주:1]

101키 호환 키보드는 모두 세 종류가 있는데, 종류 1부터 종류 3까지 있다. 이 세 가지 모두 호스트 키가 작동하지 않았다.

아무튼 호스트 키가 제대로 작동하지 않으면, 버추얼박스에서는 해결할 수 없다. 앞서 말했듯이 이 벌레가 사는 곳은 윈도XP이기 때문이다.

해결책은 간단하다. 101키 호환 키보드를 103/106 호환 키보드로 바꾸어 주면 된다. 그러나 이때 또 다른 벌레가 등장한다.

[PC/AT 101키 호환 키보드/USB 키보드(종류 1) 등록정보] 애플릿에서 "드라이버 업데이트"를 클릭하여 드라이버를 설치한다.

어느 것을 선택해도 무방하다. 다만 벌레를 확실히 보려면,

이상하게도 106키는 보이지 않는다.

내 키보드는 분명히 106키 호환 키보드이다. 그런데 호환 가능한 하드웨어 목록에는 나타나지 않는다. 그렇다. 벌레는 바로 여기에도 숨어 있었다. 저 체크 표시를 해제하면 아래와 같은 목록이 나타난다.

반드시

반드시 "한글 PS/2 키보드/USB 키보드(103/106키)"를 선택하기 바란다. 그리고 다음을 클릭하여 설치를 완료하면 된다. 호스트 키가 정상 작동하는지 확인하기 바란다.

재미 있는 점은 다시 "PC/AT 101키 호환 키보드/USB 키보드"로 바꾸어도 호스트 키는 정상 작동한다는 점이다. 윈도 XP의 벌레인지 아니면, 원래 오른쪽 컨트롤 키가 작동해야 하는데, 방금 키보드 드라이버를 바꾸는 과정에서 벌레가 잡힌 것인지는 알 수 없었다.

추가

버추얼박스에서 키보드 드라이버를 바꾸다가 우연히 이상한 점을 발견했다.

101키 드라이버 목록

한글 103키 드라이버 목록

회사 측 답변

이 문제는 마이크로소프트에 문의한 적이 없기 때문에 회사 측 의견은 첨부하지 않았다.

벌레의 유형

알려주지 않고 파일 형식을 바꾸는 벌레 : 아마도 변신술을 익힌 벌레이지 않을까?
알려주지 않고 파일 용량을 늘리는 벌레 : 몸속에 뻥튀기 기계를 갖추고 있지 않을까?

벌레의 발견

티스토리에서는 그림파일을 첨부할 때 황당한 버그를 보여준다.
무슨 뜻이냐 하면 파일 업로드할 때 파일이 그대로 올라가지 않고, 그 과정에서 다른 형식으로 바뀔 수도 있음을 알려주지 않고 있다.

그런데 현재 업로드되어 있는 파일은 원본과는 달랐다.

회사 측 답변

이 문제가 해결되었음을 2008년 3월 6일 밤 0시 56분 현재 확인하였다.

접기

D사 고객센터에 올린 내용은 다음과 같다.

D사 고객센터에서는 다음과 같은 답변을 하였다.

재미 있는 점은 "확인하고 있다."라는 말과 "블로그 특성상 테스트에 시간이 많이 소요될 수 있어"라는 부분이다.
파일 업로드에 소요되는 시간은 겨우 1분 남짓이고, PNG 원본 파일이 JPEG으로 바뀌었음을 확인하기까지 걸리는 시간도 채 10분이 걸리지 않는다.
흠, 그게 시간이 많이 소요되는 문제였나?
( 파일 크기야 24비트 1천6백만 색상의 그림 파일을 4비트 16 색상으로 바꾸었기 때문에 일어난 일이라지만, PNG↔JPEG 변환은 무언가 답변이 있어야 하지 않았을까? )

접기