노무현 대통령 배너
BLOG main image
왕미친놈의 왕미친세상입니다. 미친 소리는 써도 되지만, 근거 없는 소리는 쓰면 안 됩니다.


들어가며

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

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

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

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

추상적인 버그리포팅

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

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

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

재현 불가

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

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

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

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

정책적인 이유

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

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

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

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

답변자의 무지 또는 무성의

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

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

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

대응

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

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

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

관련 문서

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

글쓴이는 koc/SALM입니다.
본문에 저작권에 대한 사항이 나타나지 않거나, 저작권이 BY-SA로 표기되어 있다면,
이 글은 GFDL로 공개한 글입니다.

읽기에 앞서

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

벌레의 유형

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

벌레의 발견

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

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

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

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

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

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

과정 재현

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

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

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

6분 만에 잡은 화면 일부. 오른쪽 아래에 보이는 시간과 요일을 잘 기억해야 한다. (전체화면은 http://salm.springnote.com/pages/3015544/attachments/1352626 또는 오른쪽 작은 그림 클릭) 

55분을 앞두고 드디어 문제의 파일 등장! 벌써 새벽 2시잖아. 난 언제 자냐? 그냥 자자. (전체 화면은 http://salm.springnote.com/pages/3015544/attachments/1352628 또는 오른쪽 작은 그림 클릭)

잠 자고 일어나도 똑같은 그 파일! 문제의 네트워크 죽이기 현상도 발생했다. (전체화면은 http://salm.springnote.com/pages/3015544/attachments/1352630 또는 오른쪽 작은 그림 클릭)

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

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

위의 그림에서 오른쪽 아래에 보면 아이콘이 5개 보인다. 그 가운데 윗줄 가운데가 작업 관리자로서 CPU 사용률을 보여주고 있다. 현재 연두색 막대가 절반쯤 보이므로 약 50%임을 짐작할 수 있다. 그런데 실행된 프로그래은 오픈캡처 하나뿐? 못 믿겠다는 사람은 전체화면을 보라. (전체화면은 http://salm.springnote.com/pages/3015544/attachments/1352642 또는 오른쪽 작은 그림 클릭)

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

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

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

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

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

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

20090327-filelist.png

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

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

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

  • 도스에서는 디렉터리를 7단계까지 만들 수 있다. 윈도에서는 255자 한계 안에서 얼마든지 만들 수 있다. 예컨대 C:\A11\B22\C33\D44\E55\F66\G77\H88\FILE.EXT 파일은 도스에서는 읽지 못할 수도 있다. 그러나 윈도에서는 문제 없이 읽을 수 있다.
  • 도스에서는 파일이름을 포함한 경로가 66자이거나 그보다 짧아야 한다.

그렇다. 도스에서는 디렉터리를 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 표시를 클릭하여 종료해도 트레이에 아이콘이 그대로 남아 있으므로 아직 종료하지 않았다고 알게 되지만, 최소 실행모드에서는 전혀 알 수가 없다. 말그대로 허깨비가 되어 버린다.

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

제작자/제공자의 답변

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

관련 문서

 

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

글쓴이는 koc/SALM입니다.
본문에 저작권에 대한 사항이 나타나지 않거나, 저작권이 BY-SA로 표기되어 있다면,
이 글은 GFDL로 공개한 글입니다.

벌레의 유형

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

벌레의 발견

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

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

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

알약을 얼리는 벌레

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

20090325ALYac_err10.png

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

20090327-filelist.png

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

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

 

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

그리고 6시간 뒤... 

20090325ALYac_err11.png

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

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

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

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

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

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

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

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

20090325ALYac_err01.png 20090325ALYac_err02.png 20090325ALYac_err03.png 20090325ALYac_err04.png

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

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

추가

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

제작자/제공자의 답변

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

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

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

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

관련 문서

 

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

글쓴이는 koc/SALM입니다.
본문에 저작권에 대한 사항이 나타나지 않거나, 저작권이 BY-SA로 표기되어 있다면,
이 글은 GFDL로 공개한 글입니다.

카테고리

분류 전체보기 (1005)
스크립트 (22)
벌레와 팁 (126)
소프트웨어 (240)
하드웨어 (6)
이야기 (24)
말의 나무 (506)
미쳐보자 (22)
일기 (48)
아이폰 (10)

최근에 올라온 글

최근에 달린 댓글

최근에 받은 트랙백

달력

«   2024/03   »
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31

글 보관함