블로그를 연 지 두 달이 되었다. 첫 달과 둘째 달이 또 다르더라.
맘에 드는 스킨이 없다. 그렇다고 구조를 이해하여 수정할 수 있는 실력도 없다. 수정은 하겠지만 겨우 글자 크기나 고치는 수준이다. 그래서 단순해 보이는 스킨을 골랐건만, 그것도 상당히 복잡하다. 응? 공부하라고?! 그래야겠다. 조금씩 고쳐봐야겠다.
무언가 집중이 되지 않는다는 느낌이 온다. 하지만 그렇다고 멈추기에는 지금까지 써 온 글이 아깝다. 에이! 모르겠다. 그냥 지금처럼 가자!
그리고 정치나 시사 이야기는 안 쓰려고 했는데, 그럴수록 다른 사람 블로그에서 자꾸 쓰게 된다. 그냥 그런 내용도 올려 버려? 흠, 고민만 하고 만다. 어쩌면 블로그를 하나 더 만들 수도... ㅡㅡa
여전히 나에게 맞는 간소한 스킨을 만드는 계획은 유효하다. 그저 '언젠가는 만들 수 있겠지.'라고 생각하며 참고 지낼 뿐일까?
이 글은 스프링노트에서 작성되었습니다.
토탈커맨더 한국 사용자 포럼(Total Commander Korean Forum)에 압축 파일 내의 그림을 볼 때의 문제라는 게시글이 올라왔다. lhuntr 님이 작성한 글인데, 그는 꿀뷰나 이미지샘, 엔젤뷰 등의 방식으로 보기를 바랐던 모양이다.
일단 토탈커맨더에서 그림 파일을 보려면 리스터 플러그인 Imagine(1.0.4 이상)이 설치되어 있어야 한다. Imagine이 설치되어 있다면, 토탈커맨더의 압축 파일 내 목록 화면에서 <F3>을 눌러 그림 파일을 볼 수 있다. 이때 토탈커맨더와 Imagine은 기본설정이라고 가정한다.
그림 파일이 있는 압축파일 sample.zip이 D:\Pictures 폴더에 있다고 하면 다음과 같다.
sample.zip 파일에서 <Enter>를 눌러 그 안으로 들어가면 다음과 같은 목록을 볼 수 있다.
토탈커맨더는 압축파일 안의 파일 목록을 \sample.zip\ 과 같은 (가상) 폴더로 바꾸어 보여준다. 이 방식은 대부분의 파일 관리자에서 채택하는 방식이며, 윈도 탐색기에서도 Zip 폴더 기능이 활성화되어 있다면 저와 비슷한 방식으로 보여준다.
윈도 탐색기의 Zip 폴더
압축파일 안에서 보고 싶은 파일에 커서를 옮긴 뒤 <F3>을 누르면 그림 파일을 볼 수 있다.
위 화면에서 상태 표시줄에는 여러 정보가 나타나 있다. 특히 상태 표시줄의 첫번째에 보이는 1/1 부분은 Imagine이 보여줄 전체 파일은 1개이며, 그 가운데 1번째 파일이라는 뜻이다.
스페이스바를 눌러 다음 파일 보기를 한다. 그게 아니라면 메뉴바에 있는 ▶ 아이콘을 클릭하면 된다.
그러면 다음과 같이 첫 번째 파일로 이동할는지를 묻는다.
이는 위에서 설명한 상태 표시줄에 나타난 바와 같이 보여줄 전체 파일이 1개이므로, 폴더에 더 이상 파일이 없다고 판단하여, 위와 같은 메시지를 보여주게 된다는 뜻이다.
윈도 탐색기에서 꿀뷰로 압축파일을 보게 되면, 압축파일 안에 들어있는 그림 파일을 보여주게 된다.
꿀뷰3에서 그림 파일을 보여주는 화면
위 그림에서 보면 [1/122]라는 부분에서 압축 파일 내부의 파일 갯수를 나타내 준다. 이때 파일 갯수는 꿀뷰에서 보여줄 수 있는 파일만 계산한다. 다시 말해 파일이 10개가 있더라도 꿀뷰가 보여줄 수 있는 그림 파일이 2개라면 갯수는 2로 나타난다.
토탈커맨더에서 꿀뷰처럼 보려면, 압축 파일 안에서 보고 싶은 파일을 여러 개 선택한 뒤 <F3>을 누르면 된다. 이때 꿀뷰처럼 보려면 압축 파일 안의 모든 파일을 본다는 뜻이므로 전체 선택을 한 뒤에 보는 것이 좋다. 선택 단축키는 <회색 +>이다. 이것은 키보드 오른쪽의 숫자키패드에 있는 +키를 가리킨다.
 |  |
위 두 그림처럼 파일을 선택하고 <F3>을 누른다.
그러면 압축을 푸는 작업을 한다. 위에서 파일 1개를 볼 때도 이 작업을 했지만, 너무 빨라서 작업을 하지 않는 것처럼 여겨질 뿐이다.
그다지 달라 보이지 않지만 몇 가지 달라진 부분이 있다.
우선 Lister 프로그램(토탈커맨더 내장 뷰어)의 메뉴 바 오른쪽에 1/21 부분이 생겼다. 이것은 파일 1개만 볼 때는 나타나지 않다가 2개 이상을 Lister 프로그램에서 볼 때 나타난다. 이것은 압축 파일 안에서 총 21개의 파일을 선택했고, 그 가운데 1번째 파일이라는 뜻이다.
그 다음으로 상태 표시줄에서도 변화가 생겼다.
위 상태 표시줄을 잘 살펴보면 아까는 1/1 로 나타났지만, 지금은 1/19로 나타난다. 이것은 압축파일 내부에서 선택한 파일 가운데 19개 파일만 Imagine 플러그인이 지원하며, 그 가운데 1번째 파일임을 뜻한다.
위 파일 보기 화면에서 스페이스바 등을 눌러 다음 파일 보기를 하면 다음 파일을 잘 보여준다.
조금 복잡한 과정을 거치기는 했으나, 꿀뷰가 설치되어 있지 않을 때 그것을 흉내낼 수 있는 방법이다.
이 글은 스프링노트에서 작성되었습니다.
우연히 AhnLab V3 Internet Security 2007 Platinum 삼성생명 번들판을 사용하다가 & 문자(앰프(Amp) 문자)가 들어간 경로를 정확하게 표현하지 못하는 현상을 발견하게 되었다.
폴더 경로명을 제대로 보여주는지를 알아보기에 앞서 다음과 같은 작업을 하였다.
프로그램을 인터넷을 통해 구하였다. 이때 백신의 바이러스 패턴은 수동 업데이트의 경우 4월 27일자를 사용했고, 자동 업데이트의 경우 4월 28일에 업데이트하여 사용했다.
바이러스가 포함된 파일을 인터넷을 통하여 구하였다.
가상머신 프로그램인 버추얼박스에 게스트OS로 윈도XP와 MS-DOS를 설치한 뒤 백신을 설치하고 경로를 어떻게 표시하는지를 조사하였다.
또한 파일시스템에 따라 결과가 달라지지 않을까 염려하여 NTFS와 FAT에서 시험하였으나, 같은 결과가 나왔다. 그래서 FAT의 조사 결과는 생략하였다. 또한 V3+ Neo는 FAT를 검사할 때 윈도의 명령 프롬프트와 MS-DOS의 명령 프롬프트에서 서로 다른 결과가 나오지 않을까 걱정했으나 이 역시 같은 결과가 나왔으므로 MS-DOS의 명령 프롬프트의 결과는 생략하였다.
참고로 맨 처음 발견된 경로 표시 벌레는 다음과 같다.
빨갛게 표시한 부분에서 경로명이 잘못 표시되고 있다.
위 그림에서 빨갛게 표시한 부분은 라고 나타나 있는데(연두색 사각형은 임의로 표시한 것이다), 이때 S자에 밑줄이 그어져 있다.
V3 IS 안철수바이러스연구소 시험판을 사용하였다. 시험판은 정품과 같으나 30일 동안 사용할 수 있는 버전으로, 정품이 가진 기능을 모두 가지고 있다. 심지어 벌레까지도. 그렇기 때문에 이번 시험에 사용하였다.
빨갛게 표시한 부분에서 경로명이 잘못 표시되고 있다.
검사 폴더라는 부분에서 소문자 o에 밑줄이 그어져 있다.
위의 목록에서 보면 밑줄이 그어진 글자는 표기가 잘못된 부분이다. 예컨대 D:\MSoft 경로명의 경우 실제로는 D:\M&Soft 라는 경로명을 가지고 있다. 앰프 문자(&)와 뒤따르는 로마자가 함께 해석되어 로마자+밑줄의 형태로 바뀌는 벌레이다.
삼성생명 보험 가입자 또는 삼성생명 웹사이트 회원에게 무료로 제공되는 V3 IS 삼성생명 번들판은 맨처음에 이 벌레를 발견한 제품이다. 확인을 위해 한 번 더 조사하였다.
위에서도 밑줄이 그어진 글자가 있다.
V3 365 클리닉은 토털 PC헬스 케어를 지향한다고 홈페이지에서 설명하고 있다. 이 제품은 안철수바이러스연구소에 가입한 사람만 설치할 수 있다. 설치 과정에서 아이디와 패스워드를 물어보므로 먼저 홈페이지에서 가입해야만 한다.
V3 365 클리닉에서는 경로명을 정확하게 표시해 준다.
위의 그림에서 보듯이 D:\MSS&oft 와 같은 경로명을 정확히 보여주고 있다.
V3 Lite는 V3 365 클리닉의 축약 버전으로 여겨지며,
개인 사용자에게는 무료이며, 기업 사용자에게는 사용이 허가되어 있지 않다. 기업 사용자는 V3 Internet Security 7.0 Enterprise나 V3 Internet Security 7.0 Platinum Enterprise 제품을 사용하도록 권장하고 있다(참고 : V3 Lite 기업 라이선스 안내).
V3 Lite 제품도 경로명을 정확히 표시해 주고 있다.
도스용 버전인 V3+ Neo는 개인 및 등록 사용자에게 무료로 제공되고 있다. 다른 무료 제품처럼 관공서나 단체에서는 업무용으로 사용해서는 안 된다.
역시 정확하게 경로명을 표현해 주고 있다.
처음 경로명을 엉뚱하게 표기해 주는 벌레를 조사할 때에는 V3 제품군에서 공통적으로 나타날 것이라고 생각했다. 그러나 AhnLab V3 Internet Security 2007 Platinum에서만 나타나고, 다른 프로그램에서는 나타나지 않았다. 물론 여기에서 시험하지 않은 기업용이나 서버용에서도 나타날 수 있는 벌레이다.
오류가 나는 부분은 대부분 앰프 문자(&)와 관련이 있다. 이것은 HTML 등의 마크업 언어에서 엔티티 문자를 나타내는 지시자로서 쓰인다. 예컨대 & 및 © 등이 그에 해당하며, 이것들은 각각 & 및 ⓒ 기호를 나타낸다.
또한 윈도 프로그래밍에서는 메뉴 등에서 단축키를 표시하는 방법을 제공하기도 한다.
위 그림은 HxD의 메뉴이다. 그런데 밑줄이 그어진 문자가 보인다. 그것은 Alt+(밑줄 문자)의 형태로 메뉴를 호출할 수 있다는 뜻이다. 다시 말해 <Alt+F>키로는 File 메뉴를 호출할 수 있다.
이는 인터넷 익스플로러에서도 마찬가지로 나타난다. 위는 한글 인터넷 익스플로러 6 sp2의 메뉴이다. 여기에서도 위와 마찬가지로 <Alt+F>키로는 파일(F) 메뉴를 호출할 수 있다.
이렇게 메뉴에서 눌러야 할 문자를 표시하기 위해서는 &(문자)의 형태를 사용하게 된다. 다시 말해 &A라고 하면 메뉴에서는 A 라고 나타나게 되며, 이를 위해서 Alt+(문자)의 형태로 호출할 수 있게 된다.
그런데 이러한 앰프 문자와 뒤따르는 로마자 표기를 경로명에서도 적용해 버렸기 때문에 이번과 같은 벌레가 발생하게 되었다고 생각한다.
2009년 4월 28일 현재 오류를 보고한 상태이며, 4월 29일 수정을 요청했고, 5월 7일 소스 수정이 완료되었으며, 6월 말 업데이트 때 적용될 예정이라는 답변을 이메일을 통해 받았다.
이 글은 스프링노트에서 작성되었습니다.
원저작자 표시는, CCL에서는 저작자 표시라고 부르는데, 원저작자를 표시해야 한다는 뜻이다.
저작자는 어떤 저작물을 지은 사람이고, 원저작자는 어떤 저작물의 원본을 지은 사람이다. 일반적으로 이 둘은 같지만, "변경 가능"한 라이선스에서는 둘이 다를 수 있다. 다시 말해 변경한 저작물은 원저작물과는 다른 저작물이 될 수도 있으며, 이때에는 저작자는 저작자가 변경한 저작물의 저작자를 가리키고, 원저작자는 변경 전의 저작물을 가리킨다.
한편 변경 후의 저작물과 변경 전의 저작물이 같은 이름으로 존재한다면, 두 저작물은 서로 같은 저작물로 간주되며, 변경 후의 저작물은 변경 전의 저작물의 수정본으로 여겨지게 된다. 이 경우 원저작물을 지은 사람과 수정한 사람은 모두 원저작자로서 인정된다고 여겨진다.
원저작자 표시는 말 그대로 원저작자를 표시한다는 뜻이다. 그러나 그 방법이나 형식에서는 매체마다 차이가 있다.
다시 말해 서적과 같은 종이에 인쇄된 매체는 단순히 그 매체의 이름을 나타내 주고, 매체의 저작자를 나타내면 된다.
그러나 웹 문서의 경우에는 해당 매체의 이름뿐만 아니라 웹 주소(URL 등)를 함께 나타내야 한다. 이 경우 저작자를 나타내지 않아도 유효한 원저작자 표시로써 여겨지게 된다. 어차피 웹 주소로써 이동하면 원저작자를 알 수 있기 때문이다. 반대로 웹 주소가 없다면 저작물의 이름이나 저작자를 표시했더라도 유효하다고 보기는 힘들다. 이는 웹이 가진 즉시성(곧바로 결과를 알아볼 수 있는 성질)에 위배되기 때문에 나온 이론이다.
스프링노트를 사용하면서 여러 벌레를 발견했지만, 재현에 성공한 것은 거의 없다. 그러다가 바로 어제(2009년 4월 24일) 2개나 재현에 성공했다. 바로 스프링노트의 태그 표기 벌레와 지금 소개하는 링크 편집 벌레이다.
직접 만든 링크와 복사해 붙여넣은 링크가 다르게 해석되는 이유를 알 수 없다. 또한 어떤 경우에는 직접 만든 링크와 동등하게 취급하고, 어떤 경우에는 다르게 취급한다. 직접 만든 링크와 동등하게 처리하는 경우는 스프링노트에서 내 블로그로 발행한 문서에 포함된 링크가 대부분이었다. 그밖에 다른 웹페이지의 링크를 붙여 넣은 경우에는 모두 링크 주소를 바꾸어 버렸다.
벌레의 발견이라고 할 수도 있고, 링크의 비교라고 할 수 있는 작업이다.
가장 먼저 스프링노트의 링크를 HTML 코드로 살펴보자. 모질라 파이어폭스에는 선택한 소스 보기라는 기능을 제공하고 있다. 그것을 이용하면 링크 부분의 HTML 소스만 떼어 살펴볼 수 있다.
마우스 오른쪽 단추를 눌러 팝업 메뉴를 부른 화면
위의 작업을 통해 보게된 선택한 영역의 HTML 소스
스프링노트의 링크 만들기 기능을 이용하여 링크를 만들게 되면 위와 같이 class="external newWindow" 라는 클래스 선택자를 추가하게 된다.
다음과 같이 링크를 수정하면 링크 대상이 현재 링크된 곳을 가리키게 된다.
링크 수정/삭제를 선택하는 팝업
링크 수정/삭제 팝업에서 수정을 선택한 화면
스프링노트의 링크 만들기 기능을 이용해서 만든 링크는 링크를 고칠 때 위와 같이 원래 주소, 곧 링크 대상을 유지해 준다.
스프링노트의 링크 만들기 기능을 이용하지 않은 링크는 class="external newWindow" 라는 클래스 선택자를 가지지 않은 링크를 말한다.
도아의 세상사는 이야기의 게시글에서 링크 하나를 복사했다. 그런데 그것이 블로그 기사 제목이라서 아래와 같이 나타났다.
좌우 폭이 좁은 까닭은 화면 크기가 800×600px이기 때문이다.
아무튼 단락제목2(HTML 태그로는 <H2>)에 해당하며, 녹색 글씨에 녹색 밑줄이 생긴 이유는 링크가 걸려 있기 때문이다. 이것을 위의 링크 수정하는 법대로 링크를 수정하는 과정은 아래와 같다.
우선 단락을 본문으로 바꾸었다.
그 뒤 링크 편집창(편집 애플릿?)을 띄우면 뜬금없이 "PermaLink :: 옥션의 어이없는 판매자"라고 나타난다. 저 글귀는 어디에서 나타났을까? 왜 웹 주소(URL 등)가 아닌 저런 문장이 나타났을까?
선택한 영역의 HTML 소스를 살펴보면 답이 나온다. 그렇다. 링크(A 태그)의 title 속성을 따다가 나타내 주고 있다.
이것을 확인하기 위해 다른 태그도 복사했지만, 역시나 title 속성을 따서 나타내 주고 있었다. 그렇다면 굳이 class="external newWindow" 클래스 선택자를 넣을 필요도 없었다는 말인데 왜 굳이 그렇게 하는지 이해하기 힘들었다.
기술적인 측면으로 본다면 단순히 하이퍼링크(A 태그)의 title 속성을 따올 뿐이며, 벌레라고 보기는 힘들었다. 그러나 주소를 정상적으로 링크 대상에 나타내려면 링크 주소와 title 속성을 항상 같게 해야만 한다는 점에서는 문제가 있다고 하겠다. title 속성은 누구나 정할 수 있지만, 대부분 링크를 설명하는 문구를 넣게 된다. 위에서 예로 든 링크도 "PermaLink :: 옥션의 어이없는 판매자"와 같은 글귀가 그것이다. "옥션에서 본 어이없는 판매자에 대한 링크"임을 나타내기 위해 title 속성을 저렇게 주었음을 알 수 있다.
스프링노트 링크 대상을 표시하는 문제를 해결하기 위한 방법으로도 그다지 좋지 않다고 생각한다. 물론 title 속성을 참조함으로써 간단한 코드를 만들 수 있다는 점에서는 동의한다. 하지만 이번과 같은 상황에서는 너무 단순한 것을 찾다가 낭패가 생긴 경우이다. 외부 링크인지만 검사했더라도, 외부 링크이면 title 속성이 아닌 href 속성을 참조하게 만들었다면 이번 벌레는 애초에 생기지 않았으리라 생각한다.
2009년 4월 27일 현재 오류를 보고한 상태이며, 수정하겠다는 답변을 받았다.
이 글은 스프링노트에서 작성되었습니다.
스프링노트를 자주 사용한다. 아니, 아예 끼고 산다고 해야 옳겠다. 블로그를 시작하면서부터 도아 님이 알려준 스프링노트를 써서 글을 발행하고 있기 때문이다. 처음 글 몇 개를 제외하고는 모두 스프링노트에서 작성했다.
그런데 최근에 자잘한 오류가 눈에 띄기 시작했다. 오류보고를 하려고 해도 재현을 하지 못해서 참고 있었다. 그러나 이번에 황당하게 재현하게 되어서 소개하고자 한다.
보통 경로명 등이 길어지면 경로명 일부를 ... (마침표 3개) 등으로 대치하는데, 이 벌레는 아예 태그가 있던 영역을 지워버렸다. 물론 인터넷 익스플로러에서는 다른 것이 표시되어야 하는 영역을 침범할 뿐 자기 자신의 일부를 그대로 나타내 주었다.
스프링노트에서 글을 작성하다가 너무 많은 태그를 입력하자 갑자기 태그 전체가 사라져 버렸다. 태그 고치기 단추와 태그 표시 단추가 모두 사라진 셈이다.
오류 없이 태그를 보여주는 화면
정상적인 상태에서는 위와 같이 나타난다. 이때 현재 편집하는 글의 상태를 알 수 있는 상태 표시줄만 따로 떼어내면 다음과 같다.
상태 표시줄 화면
글을 편집하다 보니 태그를 너무 많이 입력하게 되었다. 그러자 내 파이어폭스에서 태그 표시 아이콘, 태그, 태그 편집 아이콘이 사라졌고, 아울러 페이지 히스토리 아이콘과 CCL 표시도 사라져 버렸다.
모질라 파이어폭스에서는 너무 많은 태그를 입력하자 아예 사라져 버린 태그 목록과 태그 표시 및 태그 입력 아이콘. 그리고 그 오른쪽 구성물도 사라졌다.
왼쪽 내비게이션을 감추자 비로소 입력한 태그 목록과 태그 표시 및 태그 편집 아이콘이 나타났다.
인터넷 익스플로러에서는 태그 목록과 태그 표시 아이콘은 남았으나, 태그 편집 아이콘과 그 오른쪽 구성물이 사라졌다.
왼쪽 내비게이션을 감추자 태그 편집 아이콘과 페이지 히스토리는 나타났으나, CCL 표시는 다시 나타나지 않았다.
위와 같이 모질라 파이어폭스(3.0.9판)와 인터넷 익스플로러(v6 sp2)에서는 그 정도의 차이가 있지만 제대로 화면에 출력해 주지 못하는 상태였다. 구글 크롬이나 오페라 등의 웹브라우저에서도 그다지 다르지 않은 결과를 나타내리라 생각한다.
현재 이와 관련한 해결책은 태그를 많이 입력하지 않는 방법뿐이다. 응급책으로는 왼쪽 내비게이션과 오른쪽 책갈피를 모두 감추고 쓰는 것도 한 방법이 될 수 있다.
2009년 4월 26일 현재 오류를 보고한 상태이며, 태그 표시를 수정하겠다는 답변을 받았다.
이 글은 스프링노트에서 작성되었습니다.
사용자는 프로그램을 사용하다가 버그가 발생하면 그것을 제작자(혹은 제작사)에 알려주게 된다. 이러한 행위를 버그리포팅(bug reporting; 오류 보고)이라고 하며, 이는 프로그램 수정판(patch version)이나 향상판(upgrade version)에 도움을 주게 된다.
그런데 이러한 버그리포팅을 제작자가 무시하는 경우도 있는데, 이럴 경우 사용자는 불쾌감을 느끼게 된다. 하지만 왜 버그리포팅이 무시되는지는 깊게 생각하지 않는 사람이 많다.
우선 버그리포팅이 너무 추상적이기 때문에 무시된다. 둘째 재현이 되지 않는 경우에는 무시된다. 셋째로 개발자 측의 정책적인 이유에서 무시되기도 한다. 심지어 답변하는 측의 무지 또는 무성의 때문에 무시되는 일도 있다.
버그리포팅이 너무 추상적이기 때문에 무시되는 일도 있다. 버그패치를 하려면 구체적인 상황이 제시되어야 한다.
버그는 모든 경우에 발생하는 예는 매우 드물며, 대부분 특정 상황에서 발생하게 된다. 그러므로 버그가 발생한 상황을 구체적으로 기술할 필요가 있으며, 그게 어렵다면 특별한 버그 발생 조건을 명시해야 한다. 그것이 나타나지 않은 버그리포팅은 추상적이라 여겨지고 그 버그리포팅은 무시된다.
개발자 입장에서는 추상적인 상황에 대해 대처할 방법이 없다. 또한 프로그램의 내부 오류가 아닌 이상 버그는 반드시 외부로 표출되어야 하며, 그것은 거의 대부분 특정 조건에 따라 발생하게 된다. 이것은 그 상황을 구체적으로 설명할 수 있음을 나타낸다. 그러므로 반드시 버그가 발견되면 그 상황을 기록해 두어야 자신이 전달한 버그리포팅이 무시되지 않게 된다.
버그리포팅을 하기 전에 자신이 발견한 버그를 재현해 보아야 한다. 자신이 생각하는 그 상황에서 버그가 발생하는지를 시험해 보아야 한다는 뜻이다.
버그가 재현되지 않는다면 주로 (1) 그것은 일시적인 현상이거나, (2) 그게 아니면 내부적인 오류가 있는데, 그것이 사용자가 알지 못하는 어떤 이유로 외부로 표출된 경우이다. (1)의 경우는 프로그램 오류이기보다는 시스템의 문제이거나 설치된 프로그램끼리 충돌하는 경우 등으로 재현이 어려운 경우도 있고, 아예 그 상황 자체가 다시 나타나지 않을 수도 있다. (2)의 경우는 일반 사용자는 알 수 있는 방법이 없고, 이 경우 버그의 재현은 거의 불가능에 가깝다.
버그가 재현되지 않는 또 다른 이유는 버그의 발생원인을 착각했기 때문이다. 이 경우 버그는 존재하지만 발생원인을 착각했기 때문에 자신이 생각하는 이유로는 재현되지 않게 된다.
마지막으로 사용자는 재현에 성공했지만 개발자 측에서는 재현에 실패하는 경우도 있다. 이것은 하드웨어적인 문제가 겹치거나 사용자의 시스템 환경과 개발자의 시스템 환경이 판이하게 다른 경우에 발생한다.
개발자나 회사의 정책적인 이유로 버그리포팅이 무시된다.
개발자 측의 정책에 따라 최신 버전이 나오게 되면 이전 버전에 대한 버그리포팅은 무시되기도 한다. 예컨대 인터넷 익스플로러 5 이전 버전은 현재 버그리포팅을 무시하고 있다.
버그 패치를 적용하면 속도 저하 등의 현상이 생기는 예도 있다. 그런데 그 속도 저하 등 성능 저하가 심하다면 버그리포팅은 일정 기간 무시되기도 한다. 물론 중대한 보안버그라면 반드시 적용되겠지만, 그렇지 않다면 일정기간 무시될 수 있다는 말이다.
마지막으로 경쟁사 제품과 관련한 버그는 무시하는 경우가 있다. 이런 경우 고의적으로 경쟁사 제품의 설치 및 사용을 막는다는 의심을 받기도 한다.
답변자가 글을 제대로 읽지 않거나 버그리포팅 내용을 확인하지 않아서 무시되는 경우도 있다. 나와 네이버는 악연인지 버그리포팅이나 항의글이 무시되는 경우가 많았다. 특히 답변자가 해당 내용을 알지 못하거나, 버그리포팅 내용을 확인하지 않아서 엉뚱한 답변을 하는 경우도 있었다.
답변자의 무지 또는 무성의는 매우 심각한 결과를 가져온다. 왜냐하면 버그리포팅이 무시되는 경우 일반적으로 사용자는 그 사실을 알 수 없다. 그러나 이러한 답변자의 무지나 무성의는 답변자가 바로 알아차릴 수 있고, 그에 대해 허탈함이나 불쾌감을 가지게 된다. 이는 대답하는 사람이 가져야 할 기본적인 소양, 곧 "질문 내용이나 버그리포팅 내용을 제대로 읽기"를 하지 않았다는 말이 되기 때문이다.
버그리포팅이 무시되면 대응할 방법이 거의 없다. 추상적인 버그리포팅의 경우는 "개발자에게 의견을 전달했다."라는 식으로 말할 뿐이며, "재현 불가"는 재현할 수 없다는 말을 되돌려준다. 정책적인 이유라면 그 역시 "회사 정책상 지원하지 않는다."라는 말을 하게 되며, 답변자의 무성의는 어쨌든 답변은 받은 셈이다.
이때 추상적인 버그리포팅이나 재현 불가는 당장 할 수 있는 일이 없다. 그저 다시 버그가 나타나기를 기다려야 한다. 버그가 다시 나타나면 다행이고 그게 아니라면 어쩔 수 없이 포기해야 한다. 물론 나중에 다시 버그가 발생하면 그때 다시 버그리포팅을 하면 된다. 한/글/ 2005에 나타난 구결 표기 오류를 참조하라.
회사 정책상의 이유라면, 그것이 중대한 버그인지를 먼저 생각해야 한다. 사소한 버그이거나 다른 기능과의 충돌 때문에 "구현하지 않은 기능"일 수도 있기 때문이다. 다시 말해 사용자 설명서 등에 "불가능한 기능" 또는 "제공하지 않는 기능"이라는 식으로 기술되어 있다면 일단 버그가 아니다. 물론 사용자 입장에서는 버그라고 여겨지겠지만, 회사의 입장에서는 버그가 아니므로 "회사 정책"상 버그 수정은 하지 않게 된다. 만약 중대한 버그라면 반드시 추가로 버그리포팅을 하는 편이 좋다.
이 글은 스프링노트에서 작성되었습니다.
나는 자주 내 티스토리 블로그에 들어오는 사람들이 어떤 유입경로를 통해 들어오는지를 살펴본다. 딱히 그 사람들을 감시한다는 생각은 없고, 팁이나 벌레 글을 쓸 때 이용하기 위해서이다. 그런데 오늘(4월 24일) 재미있는 것을 발견했다. "이런 것도 모를까?"라는 생각이 들 만한 문제가 나타났다.
"dos 에서 감춰진 파일 보기"라는 저 내용이 처음에는 무엇인지 알지 못했으나, 잠시 후에야 "숨김파일"을 보려고 함을 알 수 있었다.
감춰진 파일(숨김파일)을 본다는 말은 그 파일의 내용을 본다는 말이 아니라 파일 목록에서 그것이 나타나게 한다는 뜻이다. 도스에서는 여러 가지 방법을 제공하고 있다. 물론 여기에서 설명하는 방법은 윈도의 명령 프롬프트에서도 적용할 수 있다.
우선 디렉터리에 있는 파일과 하위 디렉터리 목록을 보여주는 명령어인 DIR을 이용해 보자.[footnote]DIR의 사용법을 알고 싶다면 명령 프롬프트에서 dir /? 라고 입력하기 바란다.[/footnote]
버추얼박스에서 MS-DOS 6.22를 실행시켰다.
영문 버전이지만 한글 버전과 별로 다르지 않다. 어쨌든 디렉터리 목록을 보기만 하면 되니까 그게 중요한 게 아니다.
위에서 보면 "11 File(s)"라는 부분이 있다. C:\TEMP 디렉터리는 이번 팁을 작성하면서 새로 만든 디렉터리이다.
이때 이 폴더에는 숨김파일이 있다. 숨김파일만 보려면 /AH 선택자(옵션/선택사항)를 사용하면 된다.
위와 같이 6개의 숨김 파일이 있다고 보여준다.
위의 화면은 차례대로 읽기 전용 파일, 시스템 파일, 모든 속성의 파일의 목록을 보여주는 화면이다.
DIR 명령을 쓰지 않고도 파일 목록을 볼 수 있다. 바로 파일 속성을 보여주는 ATTRIB 명령을 이용하는 방법이다.
앞서 DIR 명령에서는 모두 19개 파일이 보였는데, ATTRIB 명령에서는 17개만 보인다. 이것은 [.]과 [..] 디렉터리는 현재 디렉터리와 부모 디렉터리를 나타내는 디렉터리로서 실제로 존재하지 않기 때문에 ATTRIB 명령에서는 보여주지 않는다. 위의 목록에서 H 표시가 있는 파일이 숨김 파일이다.
다만 ATTRIB 명령에는 숨김파일만 보는 방법은 존재하지 않는다. 만약 한 화면을 넘기게 된다면 MORE 명령을 함께 이용하면 된다.
M-Dir이나 NC(노턴 커맨더) 등의 유틸리티를 이용하여 숨김 파일을 볼 수 있다.
M-Dir에서 숨김 속성 파일을 보여주고 있다. 파일 목록을 보여주는 아래쪽에 디렉터리 정보를 보여주고 있다. 그 맨 왼쪽에 QH라고 된 부분이 숨김 파일을 보여주고 있다는 표시이다(정확하게는 H 부분이다.). 또한 목록에서 파일 크기 부분이 자주색으로 보이는 파일이 숨김 파일이다.
윈도 탐색기는 도스가 아니지만, 그래도 알고 있으면 유용하게 써먹을 수 있다.
숨김 속성을 보여주기 전 화면 (아래 상태표시줄에 숨김 파일이 4개 있다고 알려주고 있다.)
폴더 옵션에서 숨김 파일 및 폴더를 표시하도록 설정
폴더 옵션에서 설정한 뒤의 화면. 숨김 속성의 파일은 희미하게 보인다.
이 글은 스프링노트에서 작성되었습니다.
