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

'버그'에 해당되는 글 92건

  1. 2009.12.30 도대체 무슨 짓을 하는 거냐, ᄒᆞᆫ글?
  2. 2009.12.28 파이어폭스 부가기능 오류 코드 : ssl_error_rx_record_too_long 30
  3. 2009.12.27 한컴오피스2010 베타 설치 작업과 버그 몇 개
  4. 2009.12.25 한컴오피스2010 베타버전 설치기 2
  5. 2009.12.22 아크로에디트 : 문법 강조에서 문법 이름 표기 문제
  6. 2009.12.12 사라지지 않는 드림노트CS 오류 메시지 창
  7. 2009.12.10 한/글과 구결 표기
  8. 2009.12.06 알집의 파일 열기 오류
  9. 2009.11.29 스프링노트 : 문자 인코딩 관련 사항
  10. 2009.11.27 티스토리 BBCode 오류 2
  11. 2009.11.03 스프링노트 : 첨부파일 대화상자의 옵션 가리기 벌레
  12. 2009.10.30 한/글/ 2007에서 나타난 구결 표기 오류 1
  13. 2009.06.02 AIK7과 설치 응답 파일 3 - 카탈로그 파일 만들기
  14. 2009.05.30 티스토리 주석에서 \ 문자 표기 문제
  15. 2009.05.19 ISO/UDF 이미지 파일 보기 및 풀기 1
  16. 2009.05.17 윈도7을 재설치할 때 보이는 파티션 4
  17. 2009.05.16 아크로에디트 : 배치파일 주석 문법 강조 기능
  18. 2009.05.15 스프링노트 : 공개 및 비공개 설정에서 이상한 점
  19. 2009.05.14 스프링노트 : 일부 글자 속성이 제대로 지정되지 않는 벌레
  20. 2009.05.10 버추얼박스 v2.2.2 설치 오류 : 한글 경로명 문제 8
  21. 2009.04.26 스프링노트의 태그 표기 벌레
  22. 2009.04.25 버그리포팅이 무시되는 경우
  23. 2009.04.24 티스토리 이미지 갤러리 문제
  24. 2009.04.11 버추얼박스 2.2.0 네트워크 접속 문제
  25. 2009.04.07 네이버 결계 벌레 3
  26. 2009.03.31 벌레 잡는 알약, 벌레에 먹히다 2 1
  27. 2009.03.30 티스토리 파일 첨부 창 잘라먹기
  28. 2009.03.27 벌레 잡는 알약, 벌레에 먹히다 9
  29. 2009.03.26 아크로에디트 구문 강조 오류
  30. 2009.03.21 한/글/ 2005에 나타난 구결 표기 오류


1. 도대체 무슨 짓을 하는 거냐, ᄒᆞᆫ글?

한컴오피스2010 베타버전에 포함된 ᄒᆞᆫ글이 가진, 버그라고 하기에는 조금 그렇지만, 아무튼 미흡한 점을 지적하고자 합니다.

1.1. HTML은 구조적 문서이거든요.

ᄒᆞᆫ글 씨! 여보세요! HTML은 구조적 문서이거든요. 내가 만든 구조는 어디에다 팔아먹으셨나요?

그림 1 index.html 파일을 읽어온다.

그림 2 인터넷 익스플로러에서 불러온 모습

그림 3 ???글2010에서 불러온 모습

언뜻 보면 ᄒᆞᆫ글2010은 HTML을 잘 불러왔다고 여겨집니다. 하지만 인터넷 익스플로러에서 불러온 모습과는 많이 다릅니다. 그래서 혹시나 하는 마음에 스타일을 불렀습니다.

그림 4 깡그리 무시된 문단 관련 태그

HTML 문서를 읽어 올 때 문단 관련 태그를 모두 바탕글 스타일로 읽어오고 있습니다. 원래 HTML은 스타일이 없지 않느냐고요? 아니요. HTML은 스타일이 없더라도 존재합니다. 그 자체로 구조적 문서를 이루기 때문이죠. 그리고 문단 관련 태그가 각각의 기능을 가지고 있는 기능성 구조를 이루고 있습니다. 예컨대 P 태그는 당연히 문단 태그입니다. 그것만 있느냐? H1, H2, …, H6 태그도 문단 기능이 있어서 P 태그 없이도 문단을 구성할 수 있습니다. 그밖에 인용문을 가리키는 blockquote 태그, 입력 내용을 그대로 보여주는 PRE 태그 등도 P 태그 없이 문단을 구성할 수 있습니다. 제가 아는 태그만 주워섬겨도 이 정도네요.

그런데 지금 ᄒᆞᆫ글 씨께서는 모조리 뭉개버리고 바탕글이라는 스타일 하나만 남겼습니다. 구조적인 문서를 읽어다가 비구조적인 문서를 만들어 버린 셈이 되었네요.

1.2. CSS도 좀 챙겨!

ᄒᆞᆫ글 씨! 여보세요! CSS는 HTML의 스타일이거든. 그건 도대체 어디에다 팔아먹은 거냐고? 도대체 알 수가 없는 일입니다.

게다가 HTML 문서를 읽어 올 때나 저장할 때 CSS 파일을 전혀 인식하지 않습니다. 저장할 때야 HTML 문서 안에 스타일을 포함시키기 때문이라지만, 읽어올 때는 CSS 내용을 읽어 와야 옳다고 생각하는데요.

요(要)는 HTML은 구조와 내용이 분리된 언어입니다. 그것을 ᄒᆞᆫ에서 읽어왔는데, 그 구조를 모두 없애버리면(문단 태그와 DIV 태그를 모두 없애 버리면) 굳이 읽어 들여야 할 이유가 없지 않을까요? 그것을 다시 저장하면 “구조적 문서”가 “비구조적 문서”로 바뀌므로 오히려 손해가 되는 측면도 있습니다.

더구나 다른 이름으로 저장에서 HTML 문서로 저장하거나, 웹브라우저로 보내기를 하거나, 웹서버로 올리기를 하거나, 모두 HTML 문서의 형태가 중시되는데, 아예 CSS는 전혀 고려하지 않는 모습을 보이고 있습니다. 특히 ᄒᆞᆫ글2010에서 새로 추가된 블로그로 올리기 기능도 실제로는 HTML 형식으로 보내게 되어 있으니 더욱 문제는 심각하다고 할 수 있습니다.

1.3. 결론

ᄒᆞᆫ글 씨! 여보세요! HTML 문서 읽어오기나 HTML 저장하기 등의 기능은 빛 좋은 개살구거든. 그냥 읽어오기에 앞서 “이 기능은 그저 내용만 확인할 수 있습니다.”라고 안내문이나 넣지 그래.

그게 아니라면 좀 더 확실히 지원하라고. CSS도 읽어서 ᄒᆞᆫ글 스타일로 변환하고. HTML로 저장할 때도 CSS 이용할 수 있는 옵션을 좀 만들어 달라고.

이 글은 한컴오피스2010에 포함된 ᄒᆞᆫ글에서 작성한 문서입니다.
일부 깨져 보이는 글자는 일부러 수정하지 않고 두었습니다. 그에 대한 팁은 나중에 올리겠습니다.

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

파이어폭스(영문)에서 부가 기능을 이용하다 보면 간혹 ssl 관련 오류가 나는 때가 있습니다. 저도 여러 번 보았고요. 다만 지금까지는 어떻게 해야 하는지를 알지 못했고, 또한 귀찮을 뿐 별다른 영향(피해)이 없었기 때문에 그냥 두었습니다. 다들 하는 말로 그놈의 귀차니즘이 문제였죠.
그런데 오늘은 아예 부가 기능을 설치할 수 없는 문제가 생겼습니다. 바로 제가 매일 애용하는 웹메일 알림이 (WebMail Notifier; 웹메일 노터파이어)를 업데이트 할 수 없었습니다. 물론 이 설치 실패와 그 오류 코드가 어떤 관계가 있는지는 알지 못합니다만, 왠지 찝찝해지더군요.
참고로 2009년 12월 28일 현재 부가 기능 사이트에서는 최신 버전이 1.5.5입니다만, 웹메일 알림이 홈페이지의 최신 버전은 2.0.1입니다. 며칠 안으로 부가 기능 사이트도 업데이트 되리라 생각합니다.

오류 내용

오류 1 : Google Toolbar for Firefox

오류 1 : Google Toolbar for Firefox


오류 2 : 웹메일 알림이 (WebMail Notifier)

오류 2 : 웹메일 알림이 (WebMail Notifier)


오류 3 : 웹메일 알림이 (WebMail Notifier) 설치 실패

오류 3 : 웹메일 알림이 (WebMail Notifier) 설치 실패

그림만 봐도 아시겠죠? 다른 설명은 않겠습니다.

해결책

이것은 모질라 파이어폭스의 설정값 일부가 잘못되어서 나타난 버그일 가능성이 높습니다. 또한 최근 부가 기능 홈페이지가 모두 하나로 합쳐지면서 일어난 버그로 볼 수도 있고요.

그러다가 모질라 파이어폭스 한국 사용자 포럼에 들렀다가 해결책을 찾을 수 있었습니다. 다른 때였다면 구글링을 먼저 했을 텐데, 오늘은 괜히 거기를 가고 싶더라고요. 큰바다 님이 2009년 12월 20일에 오류코드 : ssl_error_rx_record_too_long 라는 제목으로 질문을 올리셨고, 주사위 님이 같은 날 답변을 달아 주셨습니다. 요는 환경 설정에서 https://services.addons.mozilla.org/ 로 시작하는 값이 2개 있는데, 그것을 고치면 된다는 내용입니다. 참고로 저 주소는 현재 존재하지 않습니다.

  1. 먼저 파이어폭스를 실행합니다.

    여기에서 주소창에 about:config 입력

    여기에서 주소창에 about:config 입력

  2. 주소창에 about:config를 입력한 뒤 화면이 환경 설정을 할 수 있게 바뀝니다. 단축키Alt+C입니다. 

    처음 환경 설정을 한다면 저와 같은 메시지를 보여줍니다.

    처음 환경 설정을 한다면 저와 같은 메시지를 보여줍니다.

  3. 엄청나게 많은 설정이 존재합니다. 화면 위쪽을 보면 필터라는 부분에 입력이 가능합니다. 그곳에 addon을 입력합니다. 그러면 필터에 해당하는 항목과 값만을 보여줍니다. 참고로 굵은 글씨(빨간 네모)는 사용자가 바꾼 경우입니다.

    처음에는 환경설정이 많습니다.

    처음에는 환경설정이 많습니다.


    필터에 addon을 입력하면 개수가 줄어듭니다.

    필터에 addon을 입력하면 개수가 줄어듭니다.

  4. 열에서 https://services.addons.mozilla.org/ 라는 을 찾습니다. 위 그림에서는 2개가 있습니다. 설정 이름 열에서 extensions.getAddons.recommended.url, extensions.getAddons.search.url 입니다.
  5. 찾았으면 에서 services. 라는 부분을 지웁니다. 지우지 않고 %LOCALE%. 으로 고쳐도 대부분 잘 작동합니다.

    services. 문자열을 %LOCALE%. 문자열로 고친 화면 (재시작 후 화면)

    services. 문자열을 %LOCALE%. 문자열로 고친 화면 (재시작 후 화면)

  6. 다 끝났으면 파이어폭스를 다시 시작합니다.

아무 에러 없이 보여주는 확장 기능 대화상자

아무 에러 없이 보여주는 확장 기능 대화상자

이때 %LOCALE%로 바꾸는 까닭은 언어 설정 때문입니다. 다시 말해 저 문자열이 그대로 적용되는 것이 아니라, 알맞은 문자열로 바뀌어 적용됩니다. 한국어의 경우 ko로 바뀝니다. 물론 해당 페이지가 없다면 대부분 영문 페이지로 리다이렉트해 줍니다.

관련 문서

내부 문서

외부 문서

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


글쓴이는 koc/SALM입니다.
본문에 저작권에 대한 사항이 나타나지 않거나, 저작권이 BY-SA로 표기되어 있다면,
이 글은 GFDL로 공개한 글입니다.
  • 참고 1 : 이 글에 나타난 사항에 대해서는 어떠한 보증도 하지 않습니다. 이 글에 나타난 오류의 원인은 어디까지나 추측입니다.
  • 참고 2 : 이 글에는 많은 그림이 있어서 읽어오는 데 시간이 오래 걸릴 수도 있습니다.

벌레의 유형

환경 설정도 제대로 못하는 기이한 벌레입니다.

개발자의 답변

2009년 12월 27일 버그 리포팅을 한 상태입니다.

벌레의 발견

한컴오피스2010 베타버전을 설치한 뒤 발견한 벌레입니다. 앞서 올린 설치 과정을 참조하여 이 글을 읽어 주면 감사하겠습니다.

한컴오피스2010 베타버전 설치 과정에서 이전 버전이 설치되어 있는지를 검사하는 단계가 있습니다.

이전 버전 확인

이전 버전 확인

여기에서 저는 일단 제거를 클릭했다가 아니다 싶어서 취소(상황 1)를 해 버렸습니다. 그러자 설치는 마지막까지 잘 되었는데, 맨 마지막 설치 완료 화면에서 단추를 클릭해도 동작하지 않는 기능이 있었습니다. 그리고 설치를 마친 뒤에 보니 확장자 연결이 안 되어 있었습니다. 확장자 연결을 하려고 해도 자꾸 에러가 나면서 되지 않았습니다.

위의 마지막 그림에서 취소를 클릭하여 제거 작업을 중단하였습니다.

두 번째 설치했을 때에는 계속 설치를 클릭하여 설치(상황 2)했습니다. 역시 설치는 잘 되었는데, 맨 마지막 설치 완료 화면에서 단추를 클릭해도 동작하지 않는 기능이 있었습니다.

이 문제에 대한 해결책은 처음부터 확실히 이전 버전을 제거하고 베타버전을 설치하는 방법뿐입니다.

상황 1 : 제거를 선택하여 진행하다가 취소

상황 1에서 문제가 되는 점은, 첫째 제거를 선택하여 진행하다가 취소를 하면 아무런 경고도 나타나지 않는다는 점입니다.

프로그램을 제거하다가 그만 두면 (1) 프로그램 제거를 시작하기 전의 상태로 되돌리거나(롤백), 아니면 (2) 제거하던 그때의 상태로 그냥 제거 프로그램을 종료해 버립니다(그냥 멈춤). 그 과정에서 제거가 제대로 되지 않았음을 알려주게 됩니다. 그런데 한컴오피스2010 베타버전을 설치하는 과정에서 제거를 선택하여 이전 버전을 제거하는 경우에, 중간에 취소하더라도 경고가 전혀 나타나지 않습니다. 아니, 원래 한글과컴퓨터 오피스 2007 설치 프로그램이 경고를 내보내지 않을 수도 있습니다. 그러나 대부분 종료코드는 뒤따르는 프로그램이 알아낼 수 있도록 설계되어 있습니다. 이는 프로그램 설치/제거 프로그램이 하는 작업의 중요도로 볼 때 반드시라고 해도 좋을 만큼 필요한 기능이라고 생각합니다.

아무튼 제거 과정 중간에 취소하는데도 경고가 뜨지 않는다는 것은 한컴오피스2010 베타버전의 버그인지, 아니면 한글과컴퓨터 오피스 2007의 버그인지 알 수 없는 그 어딘가 버그가 있었음은 분명합니다.

둘째제거 과정이 다른 프로그램 설치 과정의 일부이고, 그런 까닭에 그 제거 과정에서 오류가 있다면 설치 과정을 끝내는 것이 정상이라고 생각합니다. 이는 내부적으로 어떤 문제가 잠복해 있을는지 알 수 없기에 더욱 그러합니다. 적어도 사용자에게 알려서 사용자가 설치를 계속할는지를 선택하게 해야 한다고 생각합니다. 만약 이번처럼 확장자 연결이 되지 않는 일이 벌어질 수도 있음을 알았다면 저는 설치 과정을 처음부터 다시 시작하지, 절대로 그대로 진행하여 끝나게 두지 않았을 것입니다.

상황 2 : 계속 설치를 클릭하여 설치

한컴오피스2010 베타버전 설치 완료

한컴오피스2010 베타버전 설치 완료 화면

위 화면에서 한글과컴퓨터 인터넷 서비스(G) 부분을 아무리 클릭해도 인터넷 페이지를 열어주지 않습니다. 다만 이미 인터넷 익스플로러가 실행되어 있다면, 해당 페이지를 열어서 보여줍니다.

한글과컴퓨터 인터넷 서비스를 클릭하면 홈페이지에서 고객지원 페이지를 보여줍니다.

한글과컴퓨터 인터넷 서비스를 클릭하면 홈페이지에서 고객지원 페이지를 보여줍니다.

위 페이지를 보여 주어야 하지만, 계속 설치를 선택했을 때에는 보여주지 않는 경우가 종종 있습니다. 또한 상황 1의 경우에도 이 페이지를 보여주지 않았습니다.

또한 아래와 같이 빈 화면을 보여주는 경우도 있습니다.

다만 이 경우에는 환경 설정과 관련하여 별다른 문제가 생기지 않았습니다.

벌레의 발견

아무튼 설치가 끝났습니다. 아, 지금까지 나타난 버그는 뭐냐고요? 그건 앞서 올린 설치기에도 나타나 있는 버그입니다. 이글에서 말하고자 하는 버그는 조금 다릅니다. 명백히 오류 메시지를 내뱉고는 죽어 버리는 벌레거든요.

확장자 연결이 사라진 .hwp 확장자

확장자 연결이 사라진 .hwp 확장자

위 그림을 보면, 앞서 말했듯이 .HWP 확장자에 대한 연결이 모두 사라져 있습니다. 빨간색 네모파란색 네모 부분은 서로 확연히 구별할 수 있습니다. 더구나 파란색 네모하늘색으로 칠한 부분은 .DOC 확장자한글2010으로 연결해 놓고 있습니다. 자기 것은 챙기지 못하면서 남의 것을 탐내는군요.

처음에는 한글과컴퓨터 기본 설정에서 기본 값으로 설정을 이용했습니다.

한글과컴퓨터 기본 설정 - 처음 화면

한글과컴퓨터 기본 설정 - 처음 화면

기본 값으로 설정 화면

기본 값으로 설정 화면

위와 같이 해결해 준 듯이 메시지를 내보냈습니다. 그러나!

여전히 똑같습니다.

여전히 똑같습니다.

이번에는 한글과컴퓨터 기본 설정에서 사용자 설정을 이용했습니다.

한글과컴퓨터 기본 설정 - 사용자 설정 처음 화면

한글과컴퓨터 기본 설정 - 사용자 설정 처음 화면

위 화면은 한글과컴퓨터 기본 설정에서 사용자 설정을 클릭했을 때의 처음 화면입니다. 다만 빨간색 네모 부분은 글쓴이(왕미친놈)가 임의로 추가하였습니다. 저 경로가 다른 사람의 것과는 조금 다르기 때문입니다. 다른 사람은 보통 C:\Documents and Settings\User\My Documents라고 되어 있습니다. 혹시나 이번 버그의 원인이 이것일 수 있겠다 싶어 나타내 봅니다. 그러나 아닐 가능성도 있습니다. 환경변수를 이용해 나타내면 다른 사람처럼 이것도 %USERPROFILE%\My Documents이기 때문입니다.

한셀의 경로도 조금 다릅니다.

한셀의 경로도 조금 다릅니다.

여기까지는 그다지 버그가 없습니다. 아니 너무나 잘 정돈된 모습(디자인)이 좋기만 합니다.

한글과컴퓨터 기본 설정 - 파일 연결

한글과컴퓨터 기본 설정 - 파일 연결

한글과컴퓨터 기본 설정 - 파일 연결 부분이 문제입니다. 아래 그림들을 잘 봐 주십시오.

지금까지는 문제가 없습니다.

지금까지는 문제가 없습니다.

어, 갑자기 사각형 부분의 문자열이 사라졌습니다.

어, 갑자기 사각형 부분의 문자열이 사라졌습니다.

바로 나타나는 에러박스

바로 나타나는 에러박스

이게 상당히 긴 시간이 필요한 듯이 보이지만, 실제로는 매우 짧은 시간입니다. 동영상을 보시면 더 확실히 알 수 있습니다. (안 보이면 댓글 남겨 주세요. 다시 인코딩해 올리겠습니다.)

hconfig80.exe

hconfig80.exe 파일에서 에러가 났습니다.

오류 보고 내용

오류 보고 내용

오류 보고 내용까지 나왔습니다. 그리고 다행히도 35bb_appcompat.txt 파일을 복사할 수 있었습니다. 내용은 텍스트이지만, 실제 형식은 XML 파일입니다.

아래 show source 부분을 클릭하면 전체를 볼 수 있습니다. [code xml; collapse: true] [/code]

벌레의 원인

벌레의 원인으로 여겨지는 것은 두 가지가 있습니다.

하나는 앞서 밝혔듯이 설치 과정에서 이전 버전을 제거하다가 그 작업을 취소하고 설치했습니다. 다시 말해 이전 버전이 확실하게 제거되지 않은 상태에서 한컴오피스2010을 설치했기 때문에 생겨난 문제일 수 있습니다.

다른 하나는 위에서 밝혔듯이 제 컴퓨터의 특이한 사용자 폴더의 위치 때문일 수도 있습니다.

다만 이 두 번째 사항은 별로 의미가 없어 보입니다. 여기에서는 밝히지 않았지만, 다시 설치하는 과정에서 이전 버전을 확실히 제거하고 설치했고, 정상적으로 환경설정을 마쳤기 때문입니다.

비슷한 벌레

아직 없습니다.

관련 문서

[프로그램/설치] - 한컴오피스2010 베타버전 설치기

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


글쓴이는 koc/SALM입니다.
본문에 저작권에 대한 사항이 나타나지 않거나, 저작권이 BY-SA로 표기되어 있다면,
이 글은 GFDL로 공개한 글입니다.
  • 참고 1 : 이 글에는 그림이 많아서 읽어오는 데 시간이 오래 걸릴 수도 있습니다.
  • 참고 2 : 그림 일부가 다를 수 있습니다. 특히 제목 표시줄의 색상이 다를 때가 있는데, 이는 여러 컴퓨터에 설치한 뒤 그 결과를 종합하여 이 글을 작성했기 때문에 일어난 일입니다. 양해 바랍니다.

한글과컴퓨터 사에서 보내준 이메일을 받고 베타테스트용 파일을 다운로드하여 설치해 보았습니다.

한컴오피스2010 베타버전 설치 준비

오픈베타 테스트 및 이벤트 알림 메일

오픈베타 테스트 및 이벤트 알림 메일

이 메일을 보고는 바로 한컴오피스2010 오픈베타 홈페이지에 접속했습니다.

한컴오피스2010 오픈 베타 홈페이지

한컴오피스2010 오픈 베타 홈페이지

잘 읽어본 뒤에 다운로드(자주색 동그라미 부분)를 클릭합니다.

한컴오피스2010 다운로드 페이지

한컴오피스2010 다운로드 페이지

스크롤 바를 아래로 내리면 왼쪽 아래에 다운로드 단추가 있습니다. 파일을 다운로드하면 준비가 끝납니다. 한컴오피스2010 오픈베타 홈페이지에서 이루어지는 이벤트 참가는 각자 알아서 하기 바랍니다.
참고로 설치 프로그램의 크기는 506 MB (531,394,808 바이트)입니다.

한컴오피스2010 베타버전 설치하기

압축 풀기 및 준비 과정

한컴오피스2010 파일 추출

한컴오피스2010 파일 추출

파일 추출이 끝나면 설치에 필요한 환경이 구축되어 있는지를 검사합니다. 이때 검사하는 사항은 Microsoft .Net Framework 2.0 (또는 그 이상), 한글과컴퓨터 사의 이전 제품(한글과컴퓨터 오피스 2007 등)이 설치되어 있는지 등입니다.

그런데 Microsoft .Net Framework 2.0에 대한 내용은 홈페이지에서도, 그밖에 여러 문서 등에서도 찾을 수 없었습니다. 그렇다고 이게 없으면 안 되므로 이것이 설치되더라도 당황하지 않기를 바랍니다.

한컴오피스2010 베타버전 설치 시작을 알리는 화면

한컴오피스2010 베타버전 설치 시작을 알리는 화면

이때 좀 황당한 일을 겪었는데, 한컴오피스2010 베타버전 설치 시작을 알리는 화면Microsoft .Net Framework 2.0이 설치 되지 않았을 때에만 나타난다. 별거 아니지만 이것에 대해 어떤 안내문도 존재하지 않기 때문에 당황하기 십상이다. 더구나 위 그림의 내용대로라면 반드시 설치할 프로그램인데도 전혀 안내가 되지 않았다는 점에서는 문제가 크다고 하겠습니다. 참고로 이 현상은 세 번째 설치에서 발견하였습니다. 세 번째 설치는 운영체제를 방금 설치한 컴퓨터였기에 Microsoft .Net Framework 2.0가 설치되어 있지 않았기 때문에 발견할 수 있었습니다.

012345

Microsoft .Net Framework 2.0 설치가 끝나면 이전 버전이 설치되어 있는지를 검사합니다.

이전 버전 확인

이전 버전 확인

여기에서도 문제가 생겼습니다. 아래 단추는 모두 세 개입니다. 여기에서 제거 단추를 클릭하여 이전 버전을 완전히 삭제한 뒤에 설치하면 아무 문제가 생기지 않습니다. 다만 계속 설치를 하면 설치 마지막 과정에서 약간 문제가 있습니다(쓰는 데는 지장 없음). 그리고 제거를 하였다가 중간에 제거를 중단하면 설치는 계속 되는데, 설치 마지막 과정에서 약간 문제(계속 설치를 클릭한 것과 같은 문제가 발생)가 생기고, 실행할 때 확장자 연결 등이 되지 않는 문제가 발생합니다.
다들 저 화면이 나타난다면 정품을 가지고 있다는 말일 테니, 조금 불편하더라도 나중에 다시 설치하고, 지금은 확실히 이전 버전을 제거하고 베타버전을 설치하기 바랍니다.

또한 계속 설치 단추를 클릭하면 삭제하지 않고 설치합니다. 이때 한글과컴퓨터 오피스 2007과 한컴오피스2010 베타버전은 서로 폴더 구조가 비슷하면서도 다르기 때문에 설치에는 문제가 없습니다. 좀 더 자세히 말하면 한글과컴퓨터 오피스 2007은 폴더명 끝에 70을 붙이고, 한컴오피스2010 베타버전은 폴더명 끝에 80을 붙입니다. 이것은 버전 정보로 여겨지며,한글과컴퓨터 오피스 2007은 7.0.x.x 형태로 표시되며, 한컴오피스2010 베타버전은 8.0.x.x 형태로 표시됩니다.

이전 버전을 제거를 묻는 화면

이전 버전을 제거를 묻는 화면

제거를 클릭하면 위와 같이 이전 버전을 지울 것인가를 묻습니다. 여기에서 예(Y)를 클릭하시면 됩니다. 프로그램을 설치하는 것과 비슷한 화면이 나오면서 진행되는데, 그냥 가만히 아래 한컴오피스2010 화면이 나올 때까지 기다리시면 됩니다.

설치 과정

사용권 계약서

한컴오피스2010 베타버전 사용권 계약서

한컴오피스2010 베타버전 사용권 계약서

위 화면에는 나타나 있지 않지만, 스크롤을 아래로 내려보면 사용권에 대한 내용이 나옵니다. 그 부분만 따로 보면 아래 그림처럼 됩니다.

한컴오피스2010 베타 사용권

한컴오피스2010 베타 사용권

설치 종류 선택

한컴오피스2010 베타버전 설치 종류 선택

한컴오피스2010 베타버전 설치 종류 선택

설치 종류 선택 화면에서는 지금 설치사용자 정의로 나뉩니다. 정식 버전에서는 제품 번호를 이 화면에서 입력하게 될 듯싶습니다. 지금은 베타판이라는 문구가 자리 잡고 있습니다.
지금 설치는 미리 정해진 설정대로 설치를 해줍니다(사용자 정의 과정을 대부분 건너뜁니다). 반면에 사용자 설치는 사용자가 하나씩 설정해 가면서 설치할 수 있습니다.

사용자 정의

지금 설치를 선택하면 사용자 정의의 마지막에 나오는 한컴오피스2010 환경 설정만 볼 수 있고 나머지는 미리 정해진 대로 따르게 됩니다. 반면에 사용자 설치사용자 정의 과정을 대부분 살펴볼 수 있습니다.

한컴오피스2010 베타버전 사용자 정의 처음 화면

한컴오피스2010 베타버전 사용자 정의 처음 화면

여기에서 설정할 수 있는 사항은 설치할 구성 요소와 설치할 폴더입니다.

한컴오피스2010 프로그램을 설치할 폴더 선택

한컴오피스2010 프로그램을 설치할 폴더 선택

설치 폴더까지 지정하면 환경 설정을 합니다. 여기에서는 확장자 연결만을 지정합니다.

012

환경 설정의 초기값은 세 번 설치하면서 모두 달랐습니다. 그리고 기본적으로 한컴오피스2010 프로그램에서 지원하는 세 프로그램의 확장자는 항상 지정하고 있습니다. 또한 위 그림에는 나타나 있지 않지만 오픈오피스의 파일도 읽고 저장할 수 있습니다.

참고로 한글, 한셀, 한쇼는 그 프로그램의 정확한 이름이 아닙니다. 정확한 이름은 한컴오피스2010 오픈 베타 홈페이지에 나타나 있습니다. 이렇듯 부정확한 이름으로 나타낸 까닭은 윈도 글꼴에서 그 프로그램의 이름을 정확히 나타내지 못하기 때문입니다. 일단 한컴오피스2010 베타버전을 설치하면 글꼴도 함께 설치되므로 그러한 문제가 없지만, 설치 과정에서는 저와 같이 부정확하게 나타내는 수밖에 없습니다. 물론 설치 과정에서도 정확하게 나타낼 수 있는 방법이 있습니다.

설치 시작

한컴오피스2010 베타버전 설치 시작

한컴오피스2010 베타버전 설치 시작

드디어 설치 시작! 그런데 뭔가 이상하죠. 그렇습니다. 방금까지 정보를 보여주던 부분이 하얗게 나타나네요. 일종의 버그로 보입니다. 조금 지나면 아래와 같이 나타내 주니 걱정하지 마시기 바랍니다.

드디어 정상적으로 나옵니다.

드디어 정상적으로 나옵니다.

설치 완료

한컴오피스2010 베타버전 설치 완료

한컴오피스2010 베타버전 설치 완료

드디어 설치 완료했습니다. 이때 앞서 말한 문제가 있습니다. 우선 한글과컴퓨터 인터넷 서비스를 클릭했습니다. 일단 앞서 계속 설치를 선택했거나 이전 버전을 확실히 제거하지 않은 사람은 아무리 클릭해도 반응이 없을 수 있습니다. 다만 이미 인터넷 익스플로러를 실행 중이라면 정상적으로 아래 페이지를 보여 줍니다. 물론 이전 버전을 확실히 제거한 경우에도 잘 보여주죠.

한글과컴퓨터 인터넷 서비스를 클릭하면 홈페이지에서 고객지원 페이지를 보여줍니다.

한글과컴퓨터 인터넷 서비스를 클릭하면 홈페이지에서 고객지원 페이지를 보여줍니다.

한편 한컴오피스 2010 정보를 클릭하면 아래 그림처럼 한/글2010을 실행하여 한컴 오피스에 대한 정보를 보여주게 됩니다.

한컴오피스 2010 정보 화면

한컴오피스 2010 정보 화면

그런데 이 화면도 약간 이상합니다.

한컴오피스 2010 평가판? 베타버전이 아니고?

한컴오피스 2010 평가판? 베타버전이 아니고?

그렇습니다. 한컴오피스2010 베타버전을 설치했는데 한컴오피스 2010 평가판이라고 나오네요. 아마 베타 버전 파일을 적당히 수정하여 평가판으로 제공할 계획이었나 봅니다.

마지막으로 화면 왼쪽 아래에 있는 설정 단추를 클릭합니다.

한글과컴퓨터 기본 설정

한글과컴퓨터 기본 설정

오, 기본 설정 화면이 많이 바뀌었습니다. 좀 더 산뜻해졌습니다. 테마를 구경해 보죠.

012

설정을 클릭하면 이제 모든 과정이 끝났다는 메시지가 나옵니다.

설치 감상

설치는 대체로 평이하다. 처음부터 끝까지 다음만 누르면 되기 때문닙니다. 하지만 설치 과정에서 나타난 미리 고지되지 않은 사항 때문에 당황하는 사람이 생길 수도 있겠다는 생각이 들었습니다.

게다가 설치 과정에서 이전 버전을 제거하다가 중단하면, 설치 과정 자체를 되돌려 주거나, 이전 버전 제거 과정을 되돌려 주어야 하는데 그렇지를 못했습니다. 결과적으로 확장자 .HWP 파일에 대한 확장자 연결이 사라져 버려 약간 애를 먹었습니다. 물론 사용에는 그다지 지장이 없지만, 더 큰 문제설치한 뒤에 아예 확장자 연결이 안 된다는 점(물론 직접 레지스트리를 편집하면 가능합니다)환경 설정 프로그램으로 바로잡을 수 없는 문제가 생겼습니다.

관련 문서

이 블로그에는 다음과 같은 설치기가 있습니다.

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


'소프트웨어 > 설치' 카테고리의 다른 글

한글과컴퓨터 오피스2007 홈에디션 설치기  (0) 2009.10.29
글쓴이는 koc/SALM입니다.
본문에 저작권에 대한 사항이 나타나지 않거나, 저작권이 BY-SA로 표기되어 있다면,
이 글은 GFDL로 공개한 글입니다.

최근 아크로에디트에 여러 가지 문법 강조(Syntax Highlight) 파일을 추가하였습니다. 그런데 일부 문법 강조에서 그 표시가 정확하지 않은 현상을 발견하였습니다.

벌레의 유형

  • 다른 놈에게 이름이 없다고 자기 이름을 강요하는 난폭한 벌레이다.

벌레의 발견

2009년 12월 16일경에 아크로에디트 최신 버전(0.9.20.92)을 실행하여 문법 강조 파일을 추가하다가 발견하였습니다.

문법 강조의 문법 이름에서 오류가 나타난 화면

문법 강조의 문법 이름에서 오류가 나타난 화면

위 그림을 보면 같은 문법 이름으로 나타나 있지만, 실제로는 전혀 다른 문법 강조 파일입니다. 이는 확장자만 확인해도 알 수 있습니다.

벌레의 원인

이 벌레가 나타난 부분을 살펴보다가 모두 세 부분임을 알게 되었습니다. 화면에 보이는 두 가지(C#, MS SQL2000), 그리고 나머지 하나는 VB.NET 입니다. 확장자로 볼 때 *.cs 는 C#, *.sql은 MS SQL2000, *.vbs는 VB.NET로 여겨졌습니다. 이것은 모두 아크로에디트 홈페이지 사용자 자료실에서 받은 파일에 포함되어 있었습니다. 직접 파일을 받아서 확인해 보고 싶은 사람은 C#, MSSQL2000, VB.NET문법강조파일 문서에서 첨부 파일을 받아서 Syntax 폴더에 복사해 넣고 확인해 보기 바랍니다.

아무튼 이 벌레가 나타나는 원인문법 이름을 지정해 주지 않았기 때문으로 여겨집니다. 그러므로 직접 문법 이름을 수정해 주면 됩니다. 다만 개발자가 이 벌레가 전혀 나타나지 않도록 고치는 일도 병행되어야 한다고 생각합니다.

이번 버그의 원인

이번 버그의 원인

벌레 잡기

아크로에디트 프로그램이 수정될 때까지는 사용자가 직접 이름을 지정하여 이 벌레를 없애야 합니다. 여기에서는 이미 아크로에디트를 설치하고, 문법 강조 파일을 다운로드 하였다고 가정하고 설명하겠습니다.

다운로드 한 문법 강조 파일

다운로드 한 문법 강조 파일

압축 파일을 풀면 세 파일이 나타난다. cs.stx, mssql2000.stx, vbnet.stx 파일이다. 참고로 위 화면은 다른 컴퓨터에서도 나타나는 현상인지를 알기 위해 PC방에 와서 잡은 화면입니다. 제 컴퓨터에는 알집이 없습니다. ^^a

AcroEdit 폴더에서 문법 강조 폴더(Syntax)를 찾아서 복사해 넣는다.

AcroEdit 폴더에서 문법 강조 폴더(Syntax)를 찾아서 복사해 넣는다.

문법 강조 파일을 <아크로에디트 폴더>\Syntax 폴더로 복사한다.

아크로에디트 옵션 >> 문법 강조

아크로에디트 옵션 >> 문법 강조

아크로에디트를 실행하여 환경 설정 대화상자를 불러와서 문법 강조 설정 화면을 봅니다. 위와 같은 화면에서 추가를 눌러 하나씩 추가하거나, 자동 검색을 눌러 새로운 문법 강조 파일을 자동으로 추가할 수 있습니다. 다만 작업이 끝나면 반드시 적용 또는 확인을 클릭하여야 합니다.

문법 강조 파일 목록이 잘못 나타난 예시 1

예시 1 - 문법 강조 파일 목록이 잘못 나타난 화면

예시 화면 1에서는 문법 강조가 세 부분에서 틀려 있다. 직접 찾아 보면 프로그램 오류를 찾는 눈이 밝아질 수도... (아니면 말고.)

문법 강조 파일 목록이 잘못 나타난 예시 2

예시 2 - 문법 강조 파일 목록이 잘못 나타난 화면

예시 화면 2에서는 틀린 문법 강조 표시가 마지막 부분에 몰려 있다.

위와 같이 두 가지 형태로 버그가 나타날 수 있으므로 다르다고 해서 이 기사 내용이 틀리다고 생각하지는 말아주기 바랍니다. 이때 예시 1은 문법 강조를 많이 추가했을 때 그 가운데 섞여서 나타납니다. 그때 파일명의 자모순으로 정렬해 주는데, 파일 사이에 정렬되면서 바로 앞의 문법 이름을 그대로 쓰게 됩니다. 예시 2에서는 이미 문법 강조를 적용한 상태에서 해당 문법 강조만을 추가하면, 앞서 적용한 문법 강조는 그 앞에까지 정렬되어 있고, 새로 추가한 파일만 따로 정렬해 줍니다. 그러면서 문법 이름은 바로 앞의 문법 이름을 가져오게 됩니다.
이 글에서는 예시 1을 기준으로 설명합니다.

엉뚱하게 나타난 문법 이름

엉뚱하게 나타난 문법 이름

편집할 문법 강조 부분에 커서를 두고 편집을 클릭합니다. 여기에서는 확장자가 *.cs인 부분을 클릭한 뒤, 편집 단추를 클릭합니다.

문법 이름이 비어 있다.

비어 있는 문법 이름

위와 같이 문법 이름 부분이 비어 있습니다. 이것이 바로 버그의 원인으로, 이것에 대한 처리 과정에서 엉뚱한 결과가 나타났습니다.
문법 이름 부분에 알맞은 값을 넣어 주면 됩니다. 이 경우에는 C#을 넣어 줍니다.

올바르게 나타난 문법 이름

올바르게 나타난 문법 이름

이제 C# 언어에 대한 문법 강조 이름이 올바르게 나타납니다. 이때 적용 단추를 클릭하면 방금 한 작업이 환경 설정적용됩니다.

다른 문법 이름을 편집하려면 원하는 부분을 클릭하여 선택한 뒤에 편집 단추를 클릭하고, 그냥 끝내려면 확인 단추를 클릭합니다. 이 과정에 대한 설명은 생략합니다.

참고 사항

팝업 메뉴

이때 환경 설정문법 강조 항목만 엉뚱하게 나타나느냐? 아닙니다. 팝업 메뉴도 엉뚱하게 나타납니다.

엉뚱하게 나타난 팝업 메뉴

엉뚱하게 나타난 팝업 메뉴

아마도 팝업 메뉴의 내용은 환경설정 > 문법 강조 항목의 내용을 읽어서 표시해 주기 때문으로 여겨집니다.

올바르게 나타나는 팝업 메뉴

올바르게 나타나는 팝업 메뉴

환경설정 > 문법 강조 항목에서 올바르게 고쳐주면 팝업 메뉴의 내용도 올바르게 나타납니다.

숫자와 URL/URI 표시

위의 올바르게 나타나는 팝업 메뉴 그림에서 숫자 1숫자 2로 표시한 부분에서 조금 엉뚱한 현상이 보입니다. 이는 버그인지 아닌지 확인할 수 없었습니다.

  • 숫자 1에서 보면, 문법 강조 Text File은 아무런 기능도 없이 빈 문법 강조입니다. 그런데 이처럼 숫자만 다른 색깔(밝은 자주색)로 문법강조가 되어 있습니다.
  • 숫자 2에서 보면, URL/URI를 파란 색으로 표현해 주고 있습니다. 이것은 아크로에디트의 기능으로 보입니다.

제작자/제공자의 답변

2009년 12월 22일 오류를 보고한 상태이다.

관련 문서

내부 문서

외부 문서

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


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

최근 드림노트CS에 관심을 갖기 시작했다. 내가 쓰는 소설에서 타임라인(줄거리, 연대기 등) 작성이나 인물 성격 묘사를 할 때 그 개체 수가 늘어나자 단순히 머리로만 그것을 다 정리하기에는 무리가 있었기 때문이다.

그런데 설치할 때는 괜찮았으나, 설치하고 나서 약간 짜증나는 일이 생겼다.

벌레의 유형

사라지라고 사라지라고 해도 끝까지 남아서 사람을 괴롭히는 벌레이다.

벌레의 발견

드림노트CS를 설치한 뒤에 액세스 런타임을 설치 및 설정하지 않고 실행하자, 오류 메시지 대화상자가 나타났다. 그런데 그것을 클릭하지 일단 사라지는 듯이 보였으나, 곧바로 다시 나타났다. 아무리 확인 단추를 클릭해도 되살아났다.

드림노트CS 오류 메시지 대화상자

드림노트CS 오류 메시지 대화상자

이것을 없애려면 Windows 작업 관리자에서 [작업 끝내기]를 해야 한다.

위 화면에서 작업 끝내기(E)를 클릭하여 프로그램을 종료시키면 된다.

위 화면에서 작업 끝내기(E)를 클릭하여 프로그램을 종료시키면 된다.

또한 이 문제가 처음부터 생기지 않게 하려면 드림노트 실행시 ODBC 에러가 날 경우 해결법 문서를 참조하기 바랍니다.

제작자/제공자의 답변

2009년 12월 12일 오전에 이 문제에 대해 건의한 상태이다.

관련 문서

외부 문서

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


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

알리는 말

이 글에 소개된 사항은 중대한 오해와 착오 때문에 오류가 아닌 사항을 오류처럼 소개한 블로그 내용에 대한 내용입니다. 현재 한/글/ 2005 및 한/글/ 2007 모두 구결을 정상 표기하고 있습니다. 관련 글은 다음과 같습니다.

왜 벌레가 아닌가?

모양이 비슷한 구결 문자 세 개

모양이 비슷한 구결 문자 세 개

위 그림에 나타난 구결 문자 세 개는 그 모양이 매우 비슷하다. 특히 맨 윗줄(빨간 네모)과 맨 아랫줄(파란 네모)는 그 모양이 완전히 같다. 그리고 넷째 줄 맨 오른쪽(자주색 네모)는 그 모양이 비슷하다. 이 세 문자의 모양을 착각하여 버그라고 신고했기 때문에 한글과컴퓨터 측에서도 한동안 답변을 하지 못했다. 이는 전적으로 내가 잘못된 사항을 신고했기 때문이지 한글과 컴퓨터 측에서 잘못한 일은 없었다.

그럼 실제로 모양이 같은 구결 문자가 존재하는가? 답은 "그렇다"이다. 지난번에 소개한, noropdoropi 님이 만들어 GFDL에 따라 공개된 구결 문자 목록 그림을 수정하여 알기 쉽게 해 놓았다.

위의 그림을 보면 분명히 같은 모양을 가진 두 문자를 볼 수 있다. 빨간 네모파란 네모를 찾으면 된다.

회사 측의 기존 답변

  • 2008년 3월 한/글/ 2005(일반 버전)에서 발견한 문제이다.
  • 2008년 3월 15일 오후 8시 32분 현재 해결되지 않았다.
  • 2008년 11월 23일에 회사 측에서 답변한 내용에 따르면 글꼴을 신명조로 바꾸어 보라고 했으나, 해결되지 않았다.
  • 2009년 3월 20일에 한/글/ 2007(교육용)에서 발견하여 보고하였으나, 3월 31일까지 답변이 없었다. 아울러 같은해 10월 30일까지도 답변이 없다.
  • 2009년 10월 30일에 한/글/ 2007(홈 에디션)에서 발견하여 보고하였다. 일부 버전이 아닌 대부분의 버전에서 나타나는 현상으로 여겼다.
  • 2009년 11월 16일 전화 상담과 원격지원을 받았다. 그 과정에서 구결 코드 가운데 두 글자가 같은 모양을 가지고 있음을 알게 되었다. 결국 이 사항은 버그가 아니었음이 밝혀졌다.

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


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

알리는 말

이 글에 소개된 사항은 알집의 압축 풀기 기능과는 아무런 관련이 없습니다. 단순히 목록화 과정에서 잘못된 정보를 보여주고 있음을 나타내고 있습니다.

벌레의 유형

정상 파일을 제대로 인식하지 못하는 벌레이다.

벌레의 발견

S대학교 도서관에 비치된 컴퓨터에서 집에 있는 컴퓨터에 원격으로 접속하기 위해 프로그램을 다운로드한 뒤 압축 파일 내용을 확인하면서 알게 되었다.

헤더가 잘못되었다고 하는 알집

헤더가 잘못되었다고 하는 알집

참고로 위 그림에 나타난 파일은 TeamViewer 웹페이지에서 다운로드 받을 수 있다.

For mobile use: TeamViewer Portable 부분을 다운로드 하면 된다.

For mobile use: TeamViewer Portable 부분을 다운로드 하면 된다.

그리고 혹시나 하는 마음에 알집을 최신버전으로 바꾸어보았다.

역시나 헤더가 잘못되었다고 하는 알집 최신버전

역시나 헤더가 잘못되었다고 하는 알집 최신버전

헤더 검사에서 벌레가 나타났지만 압축을 풀 때는 이상없이 되었다.

관련 문서

내부 문서

외부 문서

회사 측의 기존 답변

  • 2009년 12월 6일 오류를 보고한 상태입니다.
  • 12월 7일 알집의 다음 버전에서는 고쳐진다는 답변을 받았습니다.
  • 12월 22일 알집 8 beta1에서 고쳐졌음을 확인하였습니다.


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


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

스프링노트에서 작성한 글을 블로그에 게시하고 나면 가끔 물음표(?)로 바뀌는 일이 있다. 처음에는 내가 유니코드KS X 1001(흔히 KS C 5601로 불린다.) 코드에 들어 있지 않은 코드를 게시한 것으로 여겼다. UTF-8 표기법으로 나타낼 수 없는 문자를 U+003F(?, 물음표)나 U+FFFD(�, 유니코드 대치 문자)로 치환하는 것은 UTF-8에서의 오류 처리이기 때문이다. 그러다가 스프링노트 측에서 또는 티스토리 측에서 잘못 게시했을 수도 있다는 생각을 갖게 되었다.

벌레의 유형

  • 벌레인지 아닌지 알 수 없었다. 이 사례는 보는 관점에 따라서는 버그일 수도 있고 아닐 수도 있다.

벌레의 발견

지난 11월 18일 알까기 1 - 알툴즈 까기 문서를 작성하다가 뮤토런트의 로마자 이름(μTorrent)이 화면에 잘못 나타나고 있음을 보고 혹시나 하는 생각을 갖게 되었다. 그에 앞서 11월 2일 한/글/ 2007에서 나타난 구결 표기 오류 2 문서에 엄(厂)과 엄(广)을 입력하다가 발견하였다. 현재 그 문서는 글자가 깨진 상태로 놔두었다.

Character-Encoding-00.png
자료 화면. 문자 인코딩이 제대로 되지 않았다.

문제가 발생하는 경우

지금까지 문제가 발생한 경우는 다음과 같다.

  • 자주 쓰지 않는 한자 : 한중일 통합 영역의 한자 가운데 (1) 특정 언어 윈도에서만 정확하게 보이는 한자, (2) 기본 다국어 평면(BMP)의 U+4E00부터 U+9FA5까지의 영역에 포함되지 않는 한자는 제대로 보이지 않는 경우가 있다.
  • 자주 쓰지 않는 로마자 : 영문자는 잘 나타내 준다. 숫자도 잘 나타내 준다. 꺽쇠(< >)도 잘 나타내 준다.[각주:1] 다만 그리스 문자나 키릴 문자 등은 가끔 정확히 표현하지 못한다. 뮤토런트에서 깨진 문자도 그리스 문자이다.
  • 특별한 구문부호가 붙은 로마자 및 기호 : 움라우트 등이 붙은 문자나 기호 등에서 가끔 깨진다.

문제 해결책

크게 두 가지 해결책이 있다. 우선 특별한 구문부호가 붙은 로마자나 기호는 글자 엔티티(character entity)로 나타내면 된다는 점이다. 그 다음으로 자주 쓰이지 않는 한자는 HTML 참조 코드를 이용하는 쪽이 낫다는 점이다.

  • 글자 엔티티 이용 : © 기호를 나타내고 싶다면 &copy; 라고 표현하면 된다.
  • HTML 참조 코드 : © 기호를 나타내고 싶다면 &#x00A9; 라고 16진수로 표현하거나, &#169; 라고 십진수로 표현하면 된다.

관련 문서

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


  1. 이것은 글자 엔티티(character entity)로써 나타내 주고 있다. [본문으로]
글쓴이는 koc/SALM입니다.
본문에 저작권에 대한 사항이 나타나지 않거나, 저작권이 BY-SA로 표기되어 있다면,
이 글은 GFDL로 공개한 글입니다.

벌레의 유형

끼어들 곳, 안 끼어들 곳을 찾지 못하는, 오지랖 넓은 벌레이다. 제발 끼어들 곳에만 끼어들라고요.

벌레의 발견

지난 번에 환경 변수 2와 관련한 논쟁(현재 글 일부 삭제된 상태임) 과정에서 우연히 발견하였습니다.

[code ;">[ur=http://www.google.co.kr/search?hl=ko&newwindow=1&q=%22%EC%9D%91%EC%9A%A9+%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%A8%EC%9D%B4+%EA%B8%B0%EB%B3%B8%EC%A0%81%EC%9C%BC%EB%A1%9C+%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%A5%BC+%EC%A0%80%EC%9E%A5%ED%95%98%EB%8A%94+%EC%9C%84%EC%B9%98%22&btnG=%EA%B2%80%EC%83%89&lr=lang_ko&aq=f&oq=]구글링 결과[/ur][/code]

위 코드는 다음과 같이 표현되어야 한다.

그런데 이놈이 아래와 같이 엉뚱하게 보여주고 있다.

이것은 BLUEnLIVE 님의 블로그 BBCode for TiStory 3.1 업데이트: 이모티콘 기능 추가 페이지에서 설명한 이모티콘 기능에서 오류가 발생한 것으로 여겨진다. 다시 말해 주기능인 BBCode 태그 안에서는 부기능인 이모티콘 표시 기능이 작동하지 않아야 함에도 불구하고, 이모티콘 표시 기능이 작동해 버렸기 때문에 주기능이 제대로 작동하지 못하게 되었다고 여겨진다.

개발자의 답변

2009년 11월 27일 버그 리포팅을 한 상태이다.

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


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

지난 10월 30일 스프링노트에서 글을 작성하다가 발견한 벌레이다. 웹사이트에 GFDL로 공개된 그림을 불러와서 스프링노트에 저장(외부 이미지를 스프링노트에 저장 옵션)을 지정하려고 했는데, 그만 미리보기에서 그 옵션을 가리는 일이 벌어졌다. 다행히 재현이 가능하여 몇 차례 더 확인하여 지금에야 올린다.

  • 참고 : 이 현상은 파이어폭스 v3.5.4 (2009년 11월 3일 현재 최신 버전)에서 확인하였습니다.

벌레의 유형

  • 파이어폭스를 사용할 때 나 혼자만 잘나면 되고 다른 놈은 제 역할도 못하게 만드는 이기적인 벌레이다.

벌레의 발견

지난 10월 30일 스프링노트에서 글을 작성하다가 외부 이미지를 불러오면서 발견한 벌레이다.

조금 옆으로 퍼진 스프링노트 화면

조금 옆으로 퍼진 스프링노트 화면

내가 자료화면으로 제시하는 800x600 화면으로는 삽입 메뉴와 부가기능 메뉴를 제대로 보여줄 수 없어서 너비를 920픽셀로 조정했다. 아울러 이미지 불러오기를 할 때 이미지 미리보기 기능을 켰을 때 위아래로 가리는 현상을 막기 위해 높이도 720픽셀로 조정했다. 이 현상은 버그가 아니라고 여겨지니 오해 없기를 바랍니다.

이미지 첨부 대화상자

위 그림에서 외부 URL로 첨부하기를 클릭한다.

외부 URL로 첨부하기

외부 URL로 첨부하기

위의 그림이 화면에 나타났을 때 미리보기를 클릭하였다.

불러올 그림 미리보기 화면

불러올 그림 미리보기 화면

위와 같이 미리보기 화면 아래쪽에 대화상자의 다른 내용을 가리는 글을 볼 수 있다. 문제가 되는 부분만 떼어내면 아래와 같다.

위 그림에서 왼쪽 체크박스오른쪽 [삽입] 단추를 가리는 것은 아래와 같은 저작권 보호를 위한 글귀이다.

특히 왼쪽의 체크박스는 잘 클릭이 되지 않아도 가려져서 그런가 보다 생각했지만, 오른쪽은 조금 의외였다. 글씨가 옅은 색이라 가려진 모습이 잘 보이지 않았기 때문이다. 결국 확대해 보니 "삽"자까지는 가려져 있고, "입"자도 일부 가려져 있었다. 처음에 이것을 눈치채지 못한 까닭은 내가 "입"자보다 오른쪽을 클릭했기 때문이리라 추측한다.

해결하기

이 문제에 대한 완전한 해결은 스프링노트 측에서 수정해 주는 방법뿐이다. 다만 그 이전까지 임시로 쓸 수 있는 방법은 그저 사용자가 주의하는 것이다.

우선 이미지 첨부 대화상자를 부른다.

위의 그림에서 자주색 네모로 표시한 부분을 잘 보자. 왼쪽 체크박스에 체크 기호가 되어 있다. 이것을 먼저 체크한 다음에 [미리보기] 단추를 클릭하자.

체크박스가 유지된 화면

체크박스가 유지된 화면

먼저 체크박스를 표시하면 위와 같이 그 체크 기호가 유지된다. 다만 이때 [삽입] 단추의 일부를 가리는 현상은 어쩔 수 없다. 앞서 말했듯이 스프링노트 개발진에서 수정해 주어야 할 부분이기 때문이다.

제작자/제공자의 답변

2009년 11월 3일 오류를 보고한 상태이다.

관련 문서

내부 문서

외부 문서

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


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

알리는 말

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

벌레의 유형

분신술을 익힌 벌레로서 한/글/ 2005 환경에서도 나타났던 벌레이다. 그런데 이번에 구매한 한글과컴퓨터 오피스2007 홈에디션에서도 똑같이 발생하고 있다.

벌레의 발견

고문을 가끔 입력하다가 한/글/ 2005에서 처음 발견한 이 벌레는 일부 한/글/ 2007에서도 발견하였다. 그때까지만 해도 "일부"에서만 발견된다고 여겼다. 그런데 이번에는 좀 다름을 알게 되었다.

이번에 구매한

이번에 구매한

현재 한/글/ 2007은 어제 설치한 뒤 바로 업데이트하였다(위 그림 참조). 원본 및 업데이트본과 다른 점이 있다면, 한/글/ 2004에 들어있던 표준국어사전 파일이 추가된 점뿐이다. 이는 내가 한/글/ 2004 정품등록 사용자이기 때문에 그 파일을 사용할 권리가 있고, 그로 말미암아 한/글/ 2004 원본 CD를 없애지 않고 업그레이드 하더라도 그 파일을 불러다 쓰고 있다.

한/글/ 2007의 문자표 입력

한/글/ 2007의 문자표 입력의 구결 부분

HNC코드로는 1D72(빨강)와 1DCE(파랑)로서, 위쪽 글자는 소릿값이 ‘마‘(또는 ‘매‘)인데, ? 모양입니다. 아래쪽 글자는 소릿값이 ‘애‘인데, ? 모양이어야 합니다. 그런데 둘 다 ?(으)로 되어 있습니다. 소릿값을 어떻게 아느냐고요? 마(매) 다음에는 모두 미음(ㅁ)이 첫소리인 글자가 오고 있습니다. 구결의 소릿값은 한자가 가진 원래 소릿값과 비슷하거든요. 마찬가지로 다음에는 이응(ㅇ)이 첫소리인 글자가 오고 있습니다. 반대로 마(매) 앞에는 리을(ㄹ)이 첫소리인 글자가 왔고, 앞에는 이응(ㅇ)이 첫소리인 글자가 왔습니다.

좀 더 확실하게 하자면, 구결 문자 목록을 보면 됩니다. 아래는 noropdoropi 님이 만들어 GFDL에 따라 공개된 구결 문자 목록 그림입니다(원래 형식 GIF였으나, PNG로 바꾸었다).

구결 문자

회사 측의 기존 답변

  • 2008년 3월 한/글/ 2005(일반 버전)에서 발견한 문제이다.
  • 2008년 3월 15일 오후 8시 32분 현재 해결되지 않았다.
  • 2008년 11월 23일에 회사 측에서 답변한 내용에 따르면 글꼴을 신명조로 바꾸어 보라고 했으나, 해결되지 않았다.
  • 2009년 3월 20일에 한/글/ 2007(교육용)에서 발견하여 보고하였으나, 3월 31일까지 답변이 없었다. 아울러 같은해 10월 30일까지도 답변이 없다.
  • 2009년 10월 30일에 한/글/ 2007(홈 에디션)에서 발견하여 보고하였다. 일부 버전이 아닌 대부분의 버전에서 나타나는 현상으로 여겨진다.

관련 문서


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


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

들어가기에 앞서

Windows Automated Installation Kit for Windows 7(Windows 7용 윈도 자동 설치 도구)에서 지난번에 한글 언어팩을 적용한 ISO이미지를 풀어낸 뒤 install.wim 파일을 읽어들였다. 그러자 카탈로그 파일의 날짜가 달라서 다시 만들어야 한다는 메시지가 나타났다.

자동 설치 도구에서 지시하는 대로 카탈로그 만들기를 하였는데, 중간에 오류가 나면서 멈추어 버렸다. 이때 카탈로그 파일은 만들어진 상태였다. 이유가 무엇인지는 모르겠으나, 카탈로그 파일은 만들어지고, 자동설치도구는 도구대로 오류 메시지를 내뿜으며 죽는 벌레가 있는 듯하다.

혼자만 날짜가 다른 Windows 7 ULTIMATE 에디션의 카탈로그 파일

혼자만 날짜가 다른 Windows 7 ULTIMATE 에디션의 카탈로그 파일

혼자만 날짜가 다른 Windows 7 ULTIMATE 에디션의 카탈로그 파일은 install.wim 파일과 날짜가 같다. 이때 install.wim 파일은 카탈로그 파일을 만들자 날짜가 바뀌었다. 위 그림에서 보면 wim 파일의 날짜가 바뀌고, 그로부터 5분쯤 뒤에 카탈로그 파일도 내용이 바뀌고 날짜도 바뀌었음을 알 수 있다.

이처럼 겨우 5분 걸릴 일을 30분 이상 끌더니 오류 메시지를 내뿜으며 죽는 벌레가 살고 있으니 너무 오래 걸린다고 여겨지면 윈도 자동 설치 도구를 강제 종료하기 바랍니다. 강제 종료하면 install.wim 파일을 마운트한 상태로 종료되므로 다음에 자동 설치 도구를 실행했을 때 윈도 이미지 창에 install.wim 파일을 읽어온 상태로 시작한다는 점을 기억하기 바랍니다.

윈도 이미지와 카탈로그 파일

윈도 이미지가 있으니 카탈로그 파일이 필요 없을 수도 있습니다. 윈도 이미지 파일에도 헤더가 존재하며, 그 헤더 정보를 읽어오면 굳이 카탈로그 파일이 필요없기 때문입니다. 그럼에도 마이크로소프트에서는 윈도 이미지 형식을 공개하면서 카탈로그 파일도 공개했습니다. 그 이유는 윈도 이미지는 항상 관리자 권한이 있어야만 수정할 수 있기 때문입니다. 이 말은 관리자 권한이 없다면 윈도 이미지를 열 수 없으므로 그 대안으로 카탈로그 파일을 제공한다는 뜻입니다. 그밖에도 윈도 이미지 파일은 여러 제한을 가지고 있습니다.

  • Windows 이미지 파일(.wim)은 관리자 권한을 가진 계정으로만 열 수 있습니다.
  • Windows 이미지 파일은 한 번에 한 사용자만 열 수 있습니다.
  • Windows 이미지 파일에는 Windows 이미지가 하나 이상 들어 있을 수 있으므로 파일 크기가 큰 경우가 많습니다. 크기가 수GB나 되는 Windows 이미지 파일도 있습니다.
  • Windows 이미지의 설정은 시간이 지남에 따라 바뀔 수 있습니다. 위의 한국어 언어팩 추가와 같은 경우가 이에 해당합니다.

이러한 제한 때문에 Windows SIM에서는 응답 파일을 만들 때 카탈로그를 사용합니다.

반대로 카탈로그 파일이 가진 장점은 다음과 같습니다.

  • 카탈로그 파일(.clg)은 관리자 권한이 없어도 열 수 있습니다.
  • 카탈로그 파일에 대한 응답 파일은 관리자가 아니라도 만들 수 있습니다.
  • 카탈로그 파일은 한 번에 여러 사용자가 열 수 있고, 그에 대한 응답 파일도 여러 사용자가 동시에 만들 수 있습니다.
  • 카탈로그 파일은 크기가 1메가바이트보다 작습니다.

물론 카탈로그 파일에도 단점은 있습니다.

  • 카탈로그 파일은 실제 데이터를 포함하고 있지 않습니다. 카탈로그 파일은 설치 파일 정보 및 설정값만을 기록하는 파일이기 때문입니다.
  • 위와 관련하여, 카탈로그 파일은 윈도 이미지가 변경된 뒤에 반드시 갱신이 필요합니다. 갱신하지 않은 카탈로그 파일을 기준으로 작성된 응답 파일은 예기치 않은 결과를 가져올 수 있습니다.

카탈로그 만들기 및 다시 만들기

카탈로그 파일은 자동으로 새로 만들어지거나, 아니면 사용자가 새로 만들거나 다시 만들어야 합니다.

자동으로 만들기

윈도 이미지 파일을 불러올 때 윈도 이미지 파일(.wim)과 카탈로그 파일(.clg)을 검사하여 서로 오류가 없음을 확인합니다. 그 과정에서 오류가 있으면 다시 만들 것인지를 물어봅니다.

카탈로그 파일을 만들겠느냐고 묻는 화면

카탈로그 파일을 만들겠느냐고 묻는 화면

위의 질문은 Windows image 7 ULTIMATE과 연결할 수 있는 카탈로그 파일을 찾을 수 없기 때문에 카탈로그 파일을 열 수 없다는 메시지이다. 그와 함께 올바른 카탈로그 파일(valid catalog file)을 사용자가 가지고 있어야 한다는 메시지도 나타나 있다. 물론 이 과정에서 관리자 권한을 가진 계정으로 작업해야 한다. Yes 단추에 그려진 방패 아이콘(A-SIM-Icon-1.png)은 그러한 의미이다.

윈도 이미지 마운트 대화상자

윈도 이미지 마운트 대화상자

일단 카탈로그 파일을 만들라고 하면 위와 같은 이미지 마운트 대화상자가 나타난다. 이때 F:\Slipper\Windows7\sources\install.wim 이라는 경로는 나중에 카탈로그 파일(.clg)의 맨 끝에 기록된다. 이는 카탈로그 파일이 참조할 이미지 파일을 나타낸다고 여겨진다.

그 다음 과정은 데이터를 차례대로 나열하는 과정(Serializing Data; 직렬화)이다. 실제로 카탈로그 파일을 만드는 과정이 이때부터 시작한다.

데이터를 차례대로 나열하는 과정의 대화상자

데이터를 차례대로 나열하는 과정의 대화상자

이때 대부분 오류가 난다. 오류 메시지에 대해서는 마지막 "오류 메시지" 부분을 참조하라.

수동으로 만들기

윈도 자동 설치 도구를 실행하여 Tool 메뉴에서 Create Catalog...를 선택한다.

카탈로그 만들기 메뉴

카탈로그 만들기 메뉴

이미지를 선택하는 대화상자가 나타난다.

이미지 선택 대화상자

이미지 선택 대화상자

여기에서 이미지 파일을 선택하여 열어도 되며, 폴더를 한 번 클릭한 다음 폴더 열기(Open Folder)를 클릭해도 된다. 이 폴더 열기는 imageX 프로그램이 가진 폴더를 캡처하는 기능과 비슷하다. 자세한 사항은 imageX에 대해 스스로 알아보기 바랍니다.

이미지 에디션 선택 대화상자

이미지 에디션 선택 대화상자

이미지 파일(.wim)에 포함된 여러 이미지(에디션) 가운데 하나 또는 여러 개를 선택하여 카탈로그를 만들 수 있다. 일단 OK를 클릭하여 만들기를 시작하면 앞의 자동으로 만들기와 같은 과정을 거치게 된다. 게다가 대부분 오류가 발생하며, 그때의 오류 메시지도 대부분 같다. ㅡㅡ; 심지어 카탈로그 파일이 만들어졌음에도 오류 메시지가 나타나는 현상까지도 같았다. 이때 여러 이미지를 선택하면 카탈로그 파일이 하나만 만들어질 때도 있으므로 주의하자.

오류 메시지

카탈로그 만들기 실패

카탈로그 파일 만들기를 실패한 오류 메시지

카탈로그 파일 만들기를 실패한 오류 메시지

위와 같은 오류 메시지가 나타나면 카탈로그 파일은 만들어지지 않는다(unable to generate a catalog라는 부분에 주목하다.).

이 오류 메시지가 나타나면 마운트가 해제되면서 윈도 자동 설치 도구가 종료되는 때가 가끔 있다.

카탈로그 만들기 성공

카탈로그 만들기를 성공했더라도 오류 메시지를 보여주는 때가 있다.

로그 파일을 만들 수 없다는 오류 메시지

로그 파일을 만들 수 없다는 오류 메시지

가끔 카탈로그 파일을 만든 다음 그 과정을 기록하는 로그 파일을 만들지 못하는 경우가 있다. 이 오류는 어쩌다 한 번 발생하므로, 거의 볼 수 없다.

카탈로그 파일을 만들 때 가장 자주 보는 오류 메시지는 다음과 같다.

리소스 부족을 알리는 오류 메시지

리소스 부족을 알리는 오류 메시지

리소스 부족을 알리는 오류 메시지는 좀 황당한 구석이 있다. 위에서 unable to generate a catalog라는 부분에 주목하라고 했는데, 리소스 부족을 알리는 오류 메시지에도 그것이 나타나 있다. 그런데 이 오류 메시지가 나타나면 십중팔구는 카탈로그 파일이 만들어진다.

이 오류 메시지가 가진 다른 현상은 바로 네트워크를 죽여 버린다. ㅡㅡ; 결국 이 오류 메시지가 나타나면 재부팅하는 수밖에 없었다.[각주:1]

이미 만들어진 카탈로 파일

이미 만들어진 카탈로 파일

위의 그림에서 윈도 이미지 파일(install.wim)의 날짜와 시간은 데이터를 차례대로 나열하는 과정(Serializing Data; 직렬화)이 시작된 때이며, 카탈로그 파일(install_Windows 7 ULTIMATE.clg)의 날짜와 시간은 오류 메시지를 내보이며 윈도 자동 설치 도구가 죽어 버린다.

  • 주의 : 반드시 자신의 임시 폴더(%TEMP%)에서 마운트된 폴더가 있는지를 확인하자. 무려 8기가바이트가 넘는 용량을 차지하므로 반드시 확인해야 한다.

기타

카탈로그 파일(.clg)의 맨 끝에 참조한 이미지의 경로(F:\Slipper\Windows7\sources\install.wim)가 기록된다고 앞서 밝혔다. 그에 대한 화면을 나타내면 다음과 같다.

원본 카탈로그 파일

원본 카탈로그 파일의 마지막

수정본 카탈로그 파일

수정본 카탈로그 파일의 마지막 부분

원본과 수정본은 마지막 부분에서 조금 차이가 있다. 원본은 그냥 경로명으로 끝나지만, 수정본은 ToolGenerated가 덧붙었다.

다음 할 일

한국어 언어팩이 적용된 윈도7에 응답 파일을 적용해 보자.

관련 문서

내부 문서

외부 문서

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


  1. 어쩌면 반쯤 맛이 간 내 컴퓨터 메인보드에 내장된 네트워크 모듈의 문제일 수도 있다. [본문으로]
글쓴이는 koc/SALM입니다.
본문에 저작권에 대한 사항이 나타나지 않거나, 저작권이 BY-SA로 표기되어 있다면,
이 글은 GFDL로 공개한 글입니다.

티스토리에 주석을 달면 가끔 한 글자씩 빼먹고 나타내는 경우가 있다. 특히 \ 문자(역슬래시)를 나타낼 때 항상 한 글자씩 빼먹고 나타낸다.

벌레의 유형

  • 덧셈을 못하는 벌레이다.
  • 그게 아니라면 자신의 본문을 화면 표시가 아니라 나눗셈으로 착각하는 벌레이다.

벌레의 발견

우연히 주석에 하드디스크 파일의 경로를 나타내다가 발견하였다.
이것은 스프링노트에서 [footnote] 표시를 붙여 나타내어도 나타나면, 티스토리에서 주석을 붙여도 나타났다.

벌레 분석

우선 편집 화면을 보면 다음과 같다.

티스토리 글쓰기(편집) 화면

티스토리 글쓰기(편집) 화면

위에서 보면 각주 부분에 어떤 파일의 경로가 있다. 파일 경로이므로 \ 문자(역슬래시 문자)가 들어가야 한다. 그 부분만 따로 떼면 다음과 같다.

위와 같이 입력했다. 다만 알아보기 쉽게 \ 문자를 자주색으로 나타냈으며, 실제로는 티스토리 글쓰기(편집) 화면처럼 모두 검은색이다.

미리보기를 하면 다음과 같다.

주석(각주)에서 \ 문자(역슬래시)를 나타내는 예제 미리보기

주석(각주)에서 \ 문자(역슬래시)를 나타내는 예제 미리보기

그런데 위에서 보면 조금 이상한 부분이 있다. 일단 그 부분만 떼어 보자.

\ 문자(역슬래시 문자)가 전혀 나타나지 않는 각주 부분

\ 문자(역슬래시 문자)가 전혀 나타나지 않는 각주 부분

무슨 까닭에서인지 \ 문자(역슬래시 문자)를 전혀 나타내지 못하고 있다.

벌레 잡기

내 짧은 지식으로 생각건대, 이것은 C 언어에서 문자열을 나타낼 때와 비슷한 현상이다. 다시 말해 C언어에서 printf 함수로 문자열을 출력할 때 \ 문자를 나타내려면 \ 문자를 1회 입력하면 안 된다. 반드시 2회, 그러니까 \\ 처럼 2회 입력해야 \ 문자를 1회 출력해 준다.

문제는 왜 이렇게 복잡한 방법으로 입력하게 만들었느냐이다. 이런 방식은 컴퓨터를 익숙지 않거나, 컴퓨터 언어(C 언어, 또는 자바스크립트 언어)를 전혀 모르는 사람에게는 꽤 큰 불편을 불러오는 악성 벌레이기 때문이다.

아무튼 이 문제를 해결하려면 \ 문자를 2회 겹쳐서 표기하면 된다.

\ 문자(역슬래시)를 2회 입력한 편집 화면

\ 문자(역슬래시)를 2회 입력한 편집 화면

각주(주석) 부분만 떼어 내면 위와 같다.

미리보기를 하면 아래와 같다.

주석 부분에 파일 경로명이 제대로 나타난 미리보기 화면

주석 부분에 파일 경로명이 제대로 나타난 미리보기 화면

제작자/제공자의 답변

2009년 5월 30일 아침에 오류 보고했다.

관련 문서

내부 문서

외부 문서

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


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

팁텍

내 컴퓨터에는 DVD±RW 기계가 달려 있고, 윈도XP를 쓰고 있다. 그리고 UDF 포맷을 지원한다고 하여, ISO/UDF 이미지 파일도 지원한다고 착각했던 적이 있다. 하지만 ISO/UDF 이미지 파일은 응용프로그램에서 지원하는 것이지 운영체제에서 지원하는 것이 아니라는 것을 알고 허탈해 하기도 했다.

아무튼 ISO/UDF 이미지 파일을 보면 달랑 README.TXT 파일 하나뿐이다. 거기다 내용도 썰렁하기 그지 없다.

7100.0.090421-1700_x86fre_client_en-us_retail_ultimate-grc1culfrer_en_dvd.iso 이미지 파일 안의 README.TXT의 내용

7100.0.090421-1700_x86fre_client_en-us_retail_ultimate-grc1culfrer_en_dvd.iso 이미지 파일 안의 README.TXT의 내용

이 디스크는 "UDF" 파일 시스템을 포함하고 있으며, ISO-13346 "UDF" 파일 시스템 규격을 지원하는 운영체제를 요구합니다.

위와 같은 의미를 가지고 있다.

이러한 ISO/UDF(이하 UDF) 이미지의 경우 일반적으로 ISO 이름도 포함하지만, 이 경우에는 ISO 이름 없이 UDF 이름만 포함하기 때문에 생겨난 결과이다.

 

팁의 발견

아무튼 내가 즐겨 사용하는 토탈커맨더에서는 위에서 설명한 바와 같이 README.TXT 파일 하나만 나타나므로 불편하기 그지 없었다. 애써 만든 7-zip을 이용한 멀티아크 애드온 설정은 다른 ISO 플러그인과 충돌하여 쓸 수 없는 상태였다. 결국 목 마른 사람이 우물 판다고, UDF 이미지 파일을 볼 수 있거나 풀어주는 유틸리티를 찾아보게 되었다.

프로그램 설치와 다른 쓰임은 각자 알아보기로 하고, 여기에서는 UDF 이미지 파일을 푸는 과정만 설명하겠다.[각주:1]

CD/DVD 제작 프로그램 사용

가장 간단하고 정통적인 방법은 ISO/UDF 이미지를 디스크로 만드는 것이다. 흔히 "CD굽기"(또는 DVD 굽기)라고 표현하는 방법이다.

가장 널리 쓰이는 프로그램에는 이미지 파일을 CD/DVD로 구워 주는 이미지번(ImgBurn) 프로그램, 여러 기능을 가진 네로 버닝 롬(Nero Burning Rom), 국산 프로그램인 이응 등이 있다.

이렇게 구한 프로그램으로 이미지를 디스크로 구운 뒤에 DVD 드라이브에 디스크를 넣어 탐색기로 살펴 보면 된다. 이 방법의 장점은 복사본을 하나 만들 수 있다는 점이고, 단점은 반드시 복사본을 만들 디스크(미디어)가 한 장 이상 필요하다는 점이다. 물론 나처럼 DVD±RW이나 DVD±RAM을 쓴다면 한 장으로 재활용할 수 있다.

다만 이 방법은 엄밀히 말해 이미지 파일을 본다는 것과는 거리가 있다. 그러나 이미지 파일의 내용을 본다는 것을 넓게 확장하여 해석하면 이런 방법도 쓸 수 있다는 뜻이다.

왼쪽 패널은 IOS/UDF 이미지를 ISO 플로그인을 통해 본 내용이고, 오른쪽 패널은 DVD 미디어를 광디스크드라이브에 넣어 내용을 확인한 화면이다. 그 아래에 작업 표시줄에는 DVD 미디어를 넣었을 때 자동실행된 프로그램이 나타나 있다.

ImgBurn

이미지번(ImgBurn) 프로그램은 이미지 파일을 CD/DVD로 구워 주는 프로그램이다. 물론 폴더나 파일을 구워 주는 기능도 있지만, 이미지 파일을 굽는 데 자주 쓰인다. 이름부터 이미지번(ImgBurn)이지 않은가?

홈페이지에서 프로그램 파일언어 파일을 받아서 설치하면 된다. 2009년 5월 19일 현재 최신 버전은 2.4.4.0 이다.

설치한 뒤 한글 언어팩을 적용하여 처음 실행한 화면

설치한 뒤 한글 언어팩을 적용하여 처음 실행한 화면

왼쪽 그림에서 이미지 파일을 디스크에 쓰기를 선택한다.

이미지 파일 굽기 설정 화면 1.

위 그림의 오른쪽에 상황 표시는 디스크가 없음을 나타낸다.

 이미지 파일 굽기 설정 화면 2. 공디스크를 DVD 드라이브에 넣은 화면. Size: 4,700,372,992 bytes 라는 부분에서 DVD 미디어임을 알 수 있다. 저장 가능한 DVD 미디어(DVD±ROM, DVD±RW 등)은 컴퓨터 가게나 편의점 등에서 살 수 있다.
이 화면에서 탐색기 모양의 아이콘(1-ImgBurn-A.png)을 클릭하면 이미지 파일 열기 대화상자가 나타난다.

 왼쪽과 같은 이미지 파일 열기 대화상자에서 DVD 미디어에 저장할 이미지 파일을 찾아낸 뒤 열기를 클릭한다.

 이미지 파일 굽기 설정 화면 3. 소스 항목 부분이 바뀌어 있다.

  • 하드디스크 드라이브 아이콘(1-ImgBurn-M.png) 옆에 나타나는 것은 방금 선택한 이미지 파일의 이름인데, 끝부분이 생략되어 있다(7100.0.090421-1700_x86fre_client_en... 부분).
  • 라벨은 만들어질 디스크의 볼륨 레이블(Volume Label), Imp ID는 이미지 파일을 만든 프로그램에서 지정한 ID인데, 여기에 나타난 ID는 선택한 이미지가 윈도7 RC 7100 이미지로서 MS의 CDIMAGE(또는 OSCDIMG)로 만든 UDF 이미지 파일이라는 의미를 가진다.
  • 파일 시스템은 디스크 이미지에 적용된 파일 시스템을 가리키며, 현재 이미지는 부팅 가능하며, UDF 파일 시스템을 지원함을 알 수 있다.
  • 섹터, 크기, 시간에 대한 정보도 알 수 있다. 또한 물음표가 있는 아이콘(1-ImgBurn-D.png)을 클릭하면 좀 더 자세한 정보를 볼 수 있다.

1-ImgBurn-N.png 위 화면에서 맨 아래의 쓰기 아이콘을 클릭하면 이미지를 디스크에 저장해 준다(왼쪽 그림 참조).

 이미지 파일 굽기 화면. 왼쪽 그림과 같은 상황이 나타난다.

 이때 왼쪽 그림 부분을 클릭하여 디스크를 다 만든 뒤의 작업을 지정하고 해제할 수도 있다.

또한 전원 아이콘(1-ImgBurn-O.png)을 클릭하면 작업이 취소되므로, 꼭 필요한 경우가 아니라면 클릭하지 않기를 바란다. 괜히 공디스크 한 장 버리게 된다.

위 과정이 끝나면 확인 작업을 거치게 된다. 그때 광디스크 드라이브가 한 번 배출되었다가 다시 들어가기도 한다. 확인 작업을 마치면 이미지 파일 굽기 화면은 자동으로 닫히고, 이미지 파일 굽기 설정 화면으로 돌아가게 된다.

네로 버닝 롬/네로 스마트스타트

네로 버닝 롬(Nero Burning ROM)은 가장 널리 쓰이는 CD/DVD 제작 프로그램 가운데 하나이다. 자신의 CD/DVD 드라이브가 최신 제품이고, 자신의 윈도가 최신 버전일 때에만 최신 제품을 쓰기 바란다. 나는 아직까지도 6.6 버전을 쓰고 있으며, 여기에서 설명하는 프로그램은 네로 버닝 롬의 엔터프라이즈 에디션(Nero Enterprise Edition)이 아니라 네로 스타트스마트(Nero StartSmart)이다. 이것은 초보자 또는 간단한 설정을 좋아하는 사람을 위해 만들어진 런처 형식의 CD/DVD 저작 도구이다.

네로 스타트스마트의 첫 실행 화면

네로 스타트스마트의 첫 실행 화면

 첫 실행 화면에서 복사 및 백업 아이콘을 클릭한 뒤 디스크로 이미지 레코딩을 클릭한다.

 네로 익스프레스 화면 1. 위에서 디스크 이미지로 레코딩을 선택했을 경우 왼쪽과 같은 열기 창이 뜨게 된다. 여기에서 DVD로 구울 이미지를 선택하여 열기를 클릭하면 된다. 이때 네로 익스프레스(Nero Express)는 네로 엔터프라이즈 에디션의 간략 버전이다.

 네로 익스프레스 화면 2. 다음 단추(2-Nero-F.png)를 클릭한다.

화면 하단에 보이는 단추는 차례대로 도움말(2-Nero-B.png), 네로 엔터프라이즈 에디션 단추(2-Nero-C.png), 기타 환경설정 단추(2-Nero-D.png), 뒤로 단추(2-Nero-E.png) 등이 있다.

 네로 익스프레스 화면 3. 디스크에 기록한다. 이때 정지 단추(2-Nero-G.png)를 누르면 작업이 취소된다. 역시 꼭 필요한 경우가 아니라면 클릭하지 않도록 한다.

 디스크에 기록하는 작업이 끝났을 때는 이와 같이 알려준다.

 네로 익스프레스 화면 4. 다음 단추를 클릭한다.

 네로 익스프레스 화면 5. 끝내기 단추(2-Nero-H.png)를 클릭하면, 네로 익스프레스가 종료되어, 네로 스타트스마트 화면으로 돌아간다.

이응

이응은 CD/DVD 굽기와 가상 드라이브를 결합한 제품으로 알콜 120%와 비슷하다. 여기에서 실행화면만 소개하고, 사용법은 알려주지 않는다. 이응에서 이미지 굽는 법은 이응의 홈페이지를 참고하면 된다.

이응의 등록 화면

이응의 등록 화면

이응을 실행하면 개인 버전인지 데모 버전인지를 선택하게 된다. 위의 화면은 개인 버전 사용을 선택하였을 경우에 나타나는 화면이다. 개인 버전은 약간의 기능 제한이 있다.

이응의 실행 화면

이응의 실행 화면

사용법은 홈페이지를 참고하기 바랍니다.

가상 CD/DVD 프로그램 사용

가상 디스크 프로그램을 사용하여 UDF 이미지의 내용을 확인할 수도 있다. 앞서 소개한 이응(v3.x), 시디스페이스(v6), 데몬 툴스(DAEMON Tools) 등을 사용할 수 있다.

이응의 최신버전에서는 UDF 이미지를 잘 읽어 들일 수 있으니 홈페이지의 사용방법을 참고하기 바랍니다. 시디스페이스는 버전6을 구할 수 없어서[각주:2] 시험하지 않았다.

결국 여기에서 사용한 프로그램은 데몬 툴스 v4.30.4이다.

DAEMON Tools를 처음 실행한 화면

DAEMON Tools를 처음 실행한 화면

패널만 따로 보면 다음과 같다.

맨 오른쪽에 있는 아이콘(4-Daemon-A.png)을 클릭하면 패널이 사라진다. 하지만 패널이 보이면 여러 모로 편하다. 오른쪽 아래에 있는 트레이에서 데몬 툴스 아이콘(4-Daemon-B.png)을 마우스 오른쪽 클릭하여 언제라도 다시 나타나게 할 수 있다.

 위에서 장치 0: [ G: ]  미디어 없음 부분을 두번클릭하면 이미지 파일 선택 대화상자가 나타난다. 이미지를 선택하고 열기를 클릭한다.

패널이 아래와 같이 바뀐다. 이제 G 드라이브에 들어가 내용을 확인하면 된다.

관련 문서

내부 문서

외부 문서

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


  1. 하지만 압축 푸는 과정과 ISO/UDF 파일을 푸는 과정이 동일하므로 사실상 압축 해제 방법의 설명이라고 해도 되겠다. [본문으로]
  2. 내가 가진 버전은 시디스페이스 버전5 라서 ISO/UDF 이미지를 제대로 인식하지 못했다. [본문으로]
글쓴이는 koc/SALM입니다.
본문에 저작권에 대한 사항이 나타나지 않거나, 저작권이 BY-SA로 표기되어 있다면,
이 글은 GFDL로 공개한 글입니다.

어제 윈도7 DVD 이미지에 한국어 언어팩을 적용하여 설치하면 이상한 현상을 발견하였다. 바로 100MB짜리 파티션이 숨김 상태로 존재하고 있었다. 윈도XP에서는 전혀 볼 수 없는 현상이라 당황했지만,[각주:1] 그냥 모두 삭제한 뒤에 다시 설치하였다. 그러나 그 숨김 파티션은 사라지지 않고 있었다. 내가 한국어 언어팩을 설치했기 때문에 일어난 일이냐고 오해했을 만큼 난감한 상태였다.

하지만 이런 현상에 대비해서 미리 설치하는 가상머신이라서 그대로 둔 상태로 구글링을 하였다. 그런데 이번에도 또 스누피 님이 해결책(윈도우7 설치시 주의사항)을 제시해 주셨다. 그 공간은 아마도 BCD(Boot Configuration DataBase) 파일을 위한 공간으로 여겨지며, 기존에 존재하는 파티션 백업/복구 유틸리티와 호환성에서 문제가 생길 수 있다고 한다.

물론 그러한 공간을 따로 마련한 이유는 있다고 생각한다. 이미 리눅스를 비롯한 유닉스 계열에서는 부트 파티션을 100MB 정도로 구성하는 일이 많기 때문이다.[각주:2] 이번에 발견한 그 숨김 파티션도 유닉스의 그것과 비슷한 목적으로 만들어졌으리라 생각한다.

문제는 그러한 파티션이 존재한다는 사실이 아니라, 그것이 감추어져 있다는 사실이다. 이것은 대부분의 사용자는 물론이고, 유틸리티에서는 그 파티션의 존재 자체를 알 수 없는 경우가 많다. 그런데 그러한 파티션에 대해 작업을 지시한다면? 아니 기존에 존재하는 유틸리티 가운데 하드디스크의 첫 번째 파티션을 백업/복원하는 유틸리티가 있다면? 아마도 그 숨김 파티션은 복원 과정에서 엉뚱한 데이터로 채워질 가능성이 아주 높다.

그러한 오류를 막기 위해서는 자동화된 고스트 도구 등을 사용할 때 주의해야 한다. 아무쪼록 직접 명령줄에서 명령을 입력하기 바란다.

여기까지는 주의사항일 뿐이고, 최선의 선택은 그러한 파티션을 없애버리는 것이다.

팁텍

스누피 님의 글에서는 비스타 설치 디스크를 이용하라고 하였다. 하지만 비스타 설치 디스크가 당장 없었기 때문에 검색하는 동안 윈도7 RC 7100 디스크 이미지를 이용하여 버추얼박스를 시동하여 파티션을 나누어 보기로 했다. 따라서 이번 팁텍은 성공이 아닌 어떻게 실패하는가를 보여주는 글이 되겠다.

윈도7 설치 디스크를 이용하여 파티션 설정하기

앞서 말했듯이 윈도7을 설치할 때 설치 디스크에서는 자동으로 파티션을 나누게 된다. 그렇다면 자동이 아닌 수동으로 하면 파티션을 어떻게 나누는지 알아보자.

설치 과정을 진행하여 다음 화면까지 왔다.

  • 참고로 일부러 한글 화면이 아닌 영문 화면을 잡았다. 이것은 기본적으로 현재 공개된 윈도7 RC가 영어판이기 때문이며, 모든 사람이 한국어로 바뀐 윈도7을 쓰지는 않기 때문이다. 어차피 아이콘 등이 같기 때문에 한글판을 쓰더라도 이해하는 데에는 지장이 없으리라 생각한다.

문제의 파티션 등장! 윈도우를 설치할 위치를 정하는 화면

문제의 파티션 등장! 윈도우를 설치할 위치를 정하는 화면

Disk 0 Partition 1: System Reserved 부분이며, 용량은 100 MB, 사용 가능한 공간은 71 MB이며, 파티션 형태는 시스템(System)이다. 아마도 시스템 차원에서 접근하고, 사용자는 접근할 수 없는 속성으로 여겨진다.

일단 Drive options (advanced) 또는 드라이브 옵션(고급)(A)를 클릭하여 수동으로 파틴션을 설정하는 항목을 나타나게 하자.

그리고 할 일은 파티션을 지우는 일이다. 이때 중요한 데이터가 없어야 하며, 윈도7이 이미 설치된 상태여야 한다.

아무 파티션이나 정해서 Delete를 누르면 오른쪽처럼 물어본다. 경고가 나오면 무시하고 지우자.

나머지 파티션도 같은 절차를 거쳐서 지운다.

다음 그림처럼 Unallocated Space(할당되지 않은 공간)라고 나타나면, New(새로 만들기)를 선택하여 파티션을 새로 만든다.

파티션이 삭제되어 할당되지 않은 공간

파티션이 삭제되어 할당되지 않은 공간

현재 크기인 32766MB는 32기가에서 2MB 모자라다. 그냥 적용한다.

현재 크기인 32766MB는 32기가에서 2MB 모자라다. 그냥 적용한다.

여기에서 조금 심각한 상황을 발생시킨다. 일단 파티션이 삭제되어 할당되지 않은 공간으로 바뀌면, 그곳에 윈도7의 설치 프로그램이 파티션을 설정할 때에는 아래와 같이 물어본다.

추가적인 파티션을 설정하겠느냐고 묻는 화면

추가적인 파티션을 설정하겠느냐고 묻는 화면

이때 이 과정에서 "윈도7의 모든 기능을 사용하도록 추가 파티션을 구성"한다고 했기 때문에 대부분 OK를 클릭하게 된다.

그러면 여기에서는 위와 같이 추가 파티션이 만들어진다. 일단 사용자가 "추가 파티션"을 만들어도 된다고 했기 때문이다.

여기에서 생기는 문제는 우선 윈도7 설치 프로그램에서는 추가 파티션 없이는 파티션 생성이 안 된다는 점이다. ㅡㅡ; 애초에 선택이고 뭐고 없었다는 뜻이 된다. 다른 문제는 그에 대한 어떠한 도움말도 제공하지 않는 상태라는 점이다. 윈도7에서는 설치 과정에서 도움말을 볼 수 있는데, 이 부분에서는 전혀 제공하지 않고 있다.

아무튼 자동으로 나누어도, 수동으로 나누어도 결과는 같았다. 결국 윈도7 설치 디스크를 이용하면 시스템 속성을 지닌 파티션(숨김 파티션) 없이 파티션을 나눌 수 없었다.

비스타 설치 디스크 이용

이번에는 윈도 비스타 설치 디스크를 이용하여 파티션을 나누어 보자.

윈도 비스타 설치화면

윈도 비스타 설치화면

설치할 위치 지정하는 화면. 여기에서 파티션을 나눈다.

설치할 위치 지정하는 화면. 여기에서 파티션을 나눈다.

위의 그림에서 파티션을 나누려면 드라이브 옵션(고급)(A)를 클릭한다.

위의 윈도7 화면을 참고하여 파티션을 모두 지운다.

위의 윈도7 화면을 참고하여 파티션을 모두 지운다.

모두 지워진 파티션. 여기에서 새로 만들기(W)를 클릭하면 파티션을 만들 수 있다.

모두 지워진 파티션. 여기에서 새로 만들기(W)를 클릭하면 파티션을 만들 수 있다.

파티션 크기 지정

파티션 크기 지정

아무런 경고도 없이 정상적으로 만들어진 파티션

아무런 경고도 없이 정상적으로 만들어진 파티션

일단 윈도 비스타 설치 디스크를 이용하여 파티션을 만들면 추가 파티션을 만들지 않음을 알 수 있다.

그밖에 방법

어떠한 방법으로든 윈도의 NTFS 파티션이 윈도7 설치 디스크로 설치 과정을 하기 전에 이미 만들어져 있다면 추가 파티션은 만들어지지 않는다고 한다.

참고

도아 님께서 알려준 바에 따르면, 이 현상은 모든 NTFS에서 발생하며, 미리 파티션을 나눌 경우 부팅 파일이 엉뚱한 드라이브에 설치되는 등의 문제가 있다고 한다. 고스트 작업 등을 할 때 호환성이 염려된다면 다른 드라이브에 부팅 파일이 설치되더라도 미리 파티션을 나눠 놓으면 좋을 수도 있다. 그러나 굳이 권장하지는 않으며, 윈도7에서 설정해 주는 대로 쓰는 것이 나아 보인다.

관련 문서

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


  1. 도아 님이 알려준 바에 따르면, 윈도XP에서는 8MB였다고 한다. 아마도 용량이 작아서 보고도 몰랐을 가능성이 높다. [본문으로]
  2. 최근 리눅스 등을 설치하지 않아 자세히는 모르겠다. 2005년에 설치했을 때에는 128메가를 설정했다. [본문으로]
글쓴이는 koc/SALM입니다.
본문에 저작권에 대한 사항이 나타나지 않거나, 저작권이 BY-SA로 표기되어 있다면,
이 글은 GFDL로 공개한 글입니다.

아크로에디트snoopy 님윈도우 7 언어팩 통합/삭제 가이드에 나타난 사항을 배치파일로 만들다가 벌레를 하나 발견하였다.

벌레의 유형

단순히 화면 출력을 잘못하는 벌레로 여겨졌다.

하지만 문법 강조에 관한 기능을 살펴본 끝에 대부분 아크로 에디트에 사는 벌레가 아니라, 처음에 문법 강조를 만들 때 해당 문법 강조 설정에 숨어 있던 벌레로 판명났다. 이 설정 파일은 내가 만든 것이 아니라 마소리스 님이 만든 것을 수정해서 쓰고 있었고, 거기에 숨어 있던 벌레였다. 물론 마지막에 가서 아크로에디트에 사는 벌레 하나를 찾을 수 있었다.

벌레 정보

  • 아크로에디트 버전 0.9 / 빌드 0.9.19.84 (2008년 12월 17일자)에서 발견하였고, 이전 버전 확인하지 못하였다.
  • 배치파일 구문 강조에서 나타났다.

벌레의 발견

배치 파일에서 "ECHO Do you want to remove other language package ? [Y/n]"라는 명령문을 입력했다가 다음과 같이 나타나서 벌레가 있음을 알게 되었다.

배치파일 문법 강조 오류

배치파일 문법 강조에서 rem이 나온 행에서 그 뒤로는 모두 주석으로 인식되는 벌레가 있다.

이때 배치파일 문법 강조 설정은 다음과 같다.

배치파일 문법 강조 설정

배치파일 문법 강조 설정.

위에서 보다시피 배치파일 문법 강조에서 행 주석으로 "rem"과 "REM"은 인식하도록 했다(파란색 네모 부분). 그런데 이 부분에서 무언가 잘못된 처리를 하고 있기 때문에 벌레가 나타난다고 여겨진다.

정말로 벌레인가? 1

아무튼 첫 번째 그림에서 129행 부분만을 떼어 내어 여러 가지 측면에서 살펴보았다.

예제 1-1. 맨 처음 발견한 벌레

예제 1-1. 맨 처음 발견한 벌레

예제 1-2. 대문자로 바꾸어도 마찬가지

예제 1-2. 대문자로 바꾸어도 마찬가지

예제 1-3. 큰따옴표(

예제 1-3. 큰따옴표(

예제 1-4. 작은따옴표(' ')로 묶어도 마찬가지

예제 1-4. 작은따옴표(' ')로 묶어도 마찬가지

예제 1-3과 1-4에서는 조금 뜻밖이었다. 보통 큰따옴표나 작은따옴표로 묶이면 문자열로 인식하고, 그럼으로써 행 주석 기호가 인식되지 않아야 하기 때문이다. 그래서 현재의 배치파일 문법 강조 설정에서 문자열 시작 문자(빨간색 네모 부분)에 "' (큰따옴표와 작은따옴표를 연속으로 입력)라고 지정함으로써 예제 1-3과 1-4를 해결하였다. 그 그림은 다음과 같다.

예제 2-1. 작은따옴표로 문자열 처리

예제 2-1. 작은따옴표로 문자열 처리

예제 2-1. 큰따옴표로 문자열 처리

예제 2-1. 큰따옴표로 문자열 처리

결국 예제 1-1과 1-2는 벌레로 여겨지지만, 예제 1-3과 1-4는 벌레가 아니었다.

정말로 벌레인가? 2

앞서 벌레로 여겨진 예제 1-1과 1-2를 다시 살펴보자.

예제 1-1. 맨 처음 발견한 벌레

예제 1-1. 맨 처음 발견한 벌레

여기에서 하나 짚고 넘어가야 할 문제가 있었다. 바로 배치파일에서 행 주석을 나타내는 지시어인 REM명령어라는 사실이다. 이게 왜 중요하냐고? 명령어 다음에 한 칸 이상의 공백이 있어야 하기 때문에 중요하다.

수정한 배치파일 문법 강조 설정

수정한 배치파일 문법 강조 설정.

위의 그림처럼 행 주석을 "rem"과 "REM"에서 "rem "과 "REM "(뒤에 공백 한 칸 있음)로 바꾸었다.

예제 3-1.

예제 3-1.

예제 3-2.

예제 3-2.

에제 3-2에서는 왜 주석으로 인식될까? 이는 당연하다. 명령어처럼 인식하도록 뒤에 공백을 넣었지만, 실제로 명령어 인식되지는 않았기 때문이다. 아크로에디트를 수정하지 않고 문법 강조 설정을 수정해서는 여기가 한계인 셈이다.

아무튼 예제 3-2에서 아크로에디트가 가진 벌레 하나를 찾을 수 있었다.

또 다른 상황

아크로에디트 구문 강조 오류 문서에서 살펴본 벌레를 상기하자. 그 글에서는 아크로에디트에서 rEm 등이 주석으로 처리되지 않는 벌레가 있음을 보였다. 여기에서도 그 벌레가 적용되는지를 살펴보았다.

예제 4-1.

예제 4-1.

예제 4-2.

예제 4-2.

벌레와 벌레가 만나자 한쪽은 작동하지 못하게 되었다.

파일

마소리스 님이 만든 배치파일 문법 강조 파일은 더 이상 유효하지 않다고 생각하여 이번에 수정한 파일을 첨부한다.

  • batch.stx (5174 바이트)
  • CRC32 : 857C74D9
  • MD5 : ac9cc62baa2f4d56330eef3449b45101
  • SHA : ab6d03405ff9c649f15ec5bb65745ad2006ff66b

제작자/제공자의 답변

2009년 5월 16일 현재 AcroEdit - 질문 및 답변에 글을 올린 상태이다.

관련 문서

내부 문서

외부 문서

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


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

지난 5월 10일 스프링노트에서 글을 작성하다가 발견한 벌레이다. 스프링노트에서 일부 글자 속성이 제대로 지정되지 않는 벌레와 거의 비슷한 때에 발견하였고, 그 벌레와는 달리 재현이 가능했다. 그래서 몇 차례 더 확인하여 지금에야 올리게 되었다. 물론 윈도7 RC에 신경 쓰다가 늦은 감도 없지 않아 있다.

벌레의 유형

  • 주변 환경이 바뀌어도 꿋꿋하게 자기 본모습(?)을 지키는 벌레이다.
    공개/비공개 설정이 바뀌었음에도 이전 설정을 그대로 따르는 이상한 벌레이다.
    1. 공개/비공개 설정이 바뀌어도 네비게이션 아이콘은 그대로 유지하는 벌레
    2. 공개/비공개 설정이 바뀌어도 메뉴를 그대로 유지하는 벌레
  • 주변 환경에 상관없이 바꾸지 말라니까 바꾸는 벌레이다.
    1. [CC 라이센스 설정하기] 레이어에서 아무 작업 없이 [적용]을 클릭하면 CC 라이센스를 바꾸는 벌레

벌레의 발견 1 : 공개/비공개 상태

지난 5월 10일 스프링노트에서 글을 작성하다가 발견한 벌레이다.

나는 스프링노트에서 글을 작성할 때 먼저 비공개로 만든다. 그 뒤에 글 내용을 모두 입력하고 그래픽 이미지를 첨부한 뒤에 공개 상태로 바꾼다. 바로 그때 약간의 오류가 발생하고 있었다.

우선 비공개 상태인 글의 화면을 보자.

비공개 상태의 화면

비공개 상태의 화면

위 그림에서 눈여겨 보아야 할 것은 붉은 사각형() 표시가 된 부분이다.

위의 두 부분에서 벌레가 살고 있다.

공개/비공개 아이콘을 클릭했을 때

먼저 제목 표시 옆에 있는 파란 자물쇠(비공개 표시 아이콘)을 보자. 위 붉은 사각형 표시가 있는 그림 두 개 가운데 오른쪽 그림이다. 그 아이콘을 클릭하면 공개/비공개를 바꿀 수 있는 화면이 나타난다.

[이 페이지를 공개합니다.]라는 레이어가 나타난 화면

[이 페이지를 공개합니다.]라는 레이어가 나타난 화면

이 페이지를 공개합니다.라고 된 레이어만 따로 보면 다음과 같다.

[이 페이지를 공개합니다.] 레이어

[이 페이지를 공개합니다.] 레이어

위 화면에서 바로 [공개하기] 단추를 클릭해도 공개가 되며, 이때에도 이 글에서 소개하는 벌레를 만날 수 있다. 또한 옵션을 클릭해서 펼쳐 보면 다음과 같다.

옵션을 클릭했을 때

옵션을 클릭했을 때

라이선스에 대한 항목을 설정한 뒤

라이선스에 대한 항목을 설정한 뒤

왼쪽은 옵션을 클릭했을 때의 화면이고, 오른쪽은 라이선스에 대한 항목을 설정한 뒤의 화면이다. 설정을 마쳤으면 [공개하기] 단추를 클릭하자.

공개/비공개 아이콘을 선택하여 공개/비공개를 설정했을 때 나타나는 오류 화면

공개/비공개 아이콘을 선택하여 공개/비공개를 설정했을 때 나타나는 오류 화면

분명히 위 그림처럼 이 페이지가 공개되었습니다.라는 메시지를 보여준다. 하지만 조금 이상함을 알 수 있다. 바로 붉은 사각형() 표시가 된 부분이다.

앞에서는 이 두 부분의 아이콘이 비슷했다. 둘 다 비공개를 뜻하는 파란 자물쇠 모양이었지만, 이제 달라졌다. 네비게이션 부분(왼쪽 그림)에서는 여전히 파란 자물쇠(비공개 표시)인데, 편집 부분에서는 주황색 자물쇠(공개 표시)로 바뀌어 있다.

비공개에서 공개로 바뀌면 네비게이션에서도 바뀌어야 함에도 불구하고 본래 모습을 그대로 유지하고 있는 벌레이다.

이때 공개에서 비공개로 바뀌어도 결과적으로 이와 비슷한 벌레를 만날 수 있다.

메뉴에서 공개/비공개 설정하기를 선택했을 때

이 벌레는 메뉴에서 공개/비공개 설정하기를 선택했을 때에도 발견할 수 있다.

메뉴를 선택하여 공개/비공개를 설정하기 전의 화면

메뉴를 선택하여 공개/비공개를 설정하기 전의 화면

위와 같이 메뉴에서 공개/비공개를 설정할 수 있다.

그러면 위에서 보았던 이 페이지를 공개합니다.라는 레이어를 볼 수 있고, 그때 [공개하기]를 선택하면 앞서 보았던 벌레를 다시 발견할 수 있다.

메뉴를 선택하여 공개/비공개를 설정한 뒤에 오류가 나타난 화면

메뉴를 선택하여 공개/비공개를 설정한 뒤에 오류가 나타난 화면

벌레의 발견 2 : 공개/비공개 변경 시 메뉴

앞서 공개한 그림 메뉴를 선택하여 공개/비공개를 설정하기 전의 화면메뉴를 선택하여 공개/비공개를 설정한 뒤에 오류가 나타난 화면를 살펴보자

그 두 그림은 공개/비공개 아이콘을 제외하면 별다른 문제가 없어 보인다. 그런데 메뉴 부분에 벌레가 숨어 있었다.

벌레가 숨어 있는 비공개 상태의 메뉴 화면과 공개 상태의 메뉴 화면

왼쪽은 그림 메뉴를 선택하여 공개/비공개를 설정하기 전의 화면이고, 오른쪽은 그림 메뉴를 선택하여 공개/비공개를 설정한 뒤에 오류가 나타난 화면이다.

이 경우에 그림 메뉴를 선택하여 공개/비공개를 설정하기 전의 화면은 아직 비공개 상태이고 그림 메뉴를 선택하여 공개/비공개를 설정한 뒤에 오류가 나타난 화면공개 상태이다. 처음에는 비공개 상태와 공개 상태의 메뉴가 같다고 생각했으나, 다른 글을 쓰다 보니 두 경우의 메뉴가 서로 다름을 알게 되었다.

비공개 상태의 메뉴 화면

비공개 상태의 메뉴 화면

공개 상태의 메뉴 화면

공개 상태의 메뉴 화면

위 두 그림은 비공개 상태와 공개 상태의 메뉴이다. 공개 상태일 때 메뉴 항목이 하나(CC 라이센스 설정) 더 많다. 위에서 보여준 벌레가 숨어 있는 비공개 상태의 메뉴 화면과 공개 상태의 메뉴 화면과는 다른 상황이다.

이와 같이 비공개 상태에서 공개 상태로 바꾸면 당연히 그에 맞추어 CC 라이센스 설정이 나타나야 함에도 어찌된 영문인지 나타나지 않고 있다. 다시 말해 나타나야 할 CC 라이센스 설정을 보여주지 않는 벌레이다. 반대로 공개 상태에서 비공개 상태로 바꾸면 감추어야 할 CC 라이센스 설정을 감추지 않는 벌레이기도 하다.

벌레의 발견 3 : CC 라이센스 설정

일단 스프링노트의 글을 공개 상태로 바꾸었다. 메뉴에서 CC 라이센스 설정을 클릭하였다.

이때 오른쪽 아래 귀퉁이의 CCL 표시를 잘 살펴봐야 한다.

메뉴에서 CC 라이센스 설정을 클릭. 이때 오른쪽 아래 귀퉁이의 CCL 표시를 잘 살펴봐야 한다.

잘 보이지 않을 수 있으므로 따로 떼어내었다.

메뉴 부분만 나타내면 다음과 같다.

[CC 라이센스 설정하기] 레이어가 보이면 Set up a Creative Commons license ▼를 클릭하여 아래로 펼친다.

옵션을 펼치기 전 화면

옵션을 펼치기 전 화면

위 화면에서 [적용]을 클릭해도 벌레가 나타난다.

옵션을 펼친 뒤 화면

옵션을 펼친 뒤 화면

이때 그림 옵션을 펼친 뒤 화면에서 나타난 메시지가 조금 이상하다. 그 그림의 윗부분은 다음과 같다.

그런데 그 아랫부분은 다음과 같다. 이는 분명히 저작자표시 - Changes allowed under same conditions(BY-SA)와는 다르다.

또한 이러한 상세 옵션 화면에서 실수로 [적용] 단추를 클릭하게 되면, CC 라이센스가 바뀌게 된다. 이는 상세 옵션이 나타나지 않은 화면(옵션을 펼치기 전 화면)에서 [적용] 단추를 클릭해도 마찬가지 결과를 보여준다.

옵션을 펼치기 전 화면에서 [적용]을 클릭한 화면.

옵션을 펼치기 전 화면에서 [적용]을 클릭한 화면. 오른쪽 아래 귀퉁이으 CCL 표시가 바뀌어 있다.

CC 라이센스 표시만 따로 살펴보면 다음과 같다.

  • : 공개된 처음 상태의 CC 라이센스 (BY-SA)
  • : 옵션을 펼치기 전 화면에서 [적용]을 클릭한 뒤의 CC 라이센스 (BY-NC)

여기에서 옵션을 펼친 뒤 화면에서는 [적용]을 클릭했을 경우에 CC 라이센스가 바뀐다는 점을 알 수 있다. 하지만 옵션을 펼치기 전 화면에서는 [적용]을 클릭했을 때 CC 라이센스가 바뀐다는 사실을 알 수 없다. 그러므로 실수로 [적용]을 클릭하더라도 CC 라이센스가 바뀌지 않도록 옵션에서 현재의 CC 라이센스로 유지될 필요가 있다.

  • 참고 : 한글맞춤법에 따르면 라이센스가 아니라 라이이다.

제작자/제공자의 답변

2009년 5월 15일 오류를 보고한 상태이다.

관련 문서

내부 문서

외부 문서

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


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

지난 5월 10일 스프링노트에서 글을 작성하다가 우연히 발견한 벌레이다. 그런데 이 벌레를 무릅쓰고 정상 작동한 것과 같은 결과를 보였더니 사라져 버렸다. 현재 재현은 불가능한 상태이며, 그 원인도 파악하지 못했다.

벌레의 유형

자기가 있어야 할 영역을 구분하지 못하는 벌레이다. 혹시 개념이 출장하지는 않았을까 염려스로운 벌레이기도 하다.

벌레의 발견

5월 10일 새벽에 윈도7을 버추얼박스에 설치하면서 그 설명문을 작성하였다. 그때 발견한 이 벌레를 보는 순간 내가 밤샘을 하느라 착각했다고 생각했다. 하지만 자꾸 반복되었기 때문에 스크린샷을 잡을 수 있었다.

위의 그림에서 Use recommended settings라는 부분을 잘 살펴보자.
그 부분이 가진 특징은 (1) 영문(로마자)이며, (2) 내용 중간에서 줄바꿈이 되어 있고, (3) 숫자 목록을 사용하여 나타내고 있다.

먼저 위와 같이 블럭 설정을 하였다.

<Ctrl+B>를 눌러 강한 강조를 하였으나, 위 그림처럼 윗줄(Use recommended)은 바뀌고 아랫줄(settings)은 바뀌지 않았다.
이 그림처럼 강한 강조 아이콘을 클릭했음에도 결과는 마찬가지였다.

결국 다음과 같이 줄바꿈이 아닌 문단 나누기를 하여 블럭 지정하기로 했다.

일단 문단을 나누고

일단 문단을 나누고

블록을 지정하여 강한 강조를 하였다.

블록을 지정하여 강한 강조를 하였다.

이번에는 내가 원하는 결과가 나타났다.

제작자/제공자의 답변

2009년 5월 14일 오류를 보고한 상태이다. 재현이 불가능하기 때문에 어찌 처리될는지는 알 수 없다. 역시나 재현이 불가능하기 때문에 오류 수정이 어렵다고 한다.

그때가 새벽이라 한창 잠이 올 때였다. 스크린샷을 잡은 것도 지금 생각해보면 비몽사몽간에 했던 일이다. 미처 HTML 코드를 확보하지 못했고, 위의 방법으로 강한 강조를 성공한 뒤에는 재현되지 않았다.

관련 문서

외부 문서

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


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

버추얼박스는 새 버전이 발표될 때마다 자잘한 벌레로 사람을 성가시게 하고 있다. 2.2.0판을 설치하면서 벌레가 많아서 사람을 성가시게 하고 있다. 이번에는 설치할 때 경로명에 한글이 포함되면 문제가 발생하는 벌레까지 발견했다.

벌레의 유형

설치 프로그램에 기생하면서 한글 경로명을 인식하지 못하게 막는 벌레이다.

벌레의 발견

낮에 집에서 윈도7을 설치한 뒤 PC방에서도 설치해 보고 싶었다. 물론 버추얼박스를 설치한 뒤에. 그런데 버추얼박스를 다운로드 받아서 설치하려고 했으나 오류가 나면서 설치가 되지 않았다.

다운로드한 버추얼박스 프로그램 파일

다운로드한 버추얼박스 프로그램 파일


오류

이 오류를 해결하기 위해 컴퓨터 설정을 살피다가 언어 설정과 관련하여 한 가지가 생각났다. 바로 "한글 경로"에서 문제가 발생하였다.

우선 프로그램이 있는 경로의 한글 경로가 문제가 된다고 생각하여 버추얼박스 프로그램을 C:\1 폴더로 옮겼다. 그러나 여전히 문제가 발생했다.

그렇다면 이것은 프로그램이 존재하는 곳의 경로와는 상관이 없다는 뜻이었고, 다른 가능성을 찾아야 했다. 그러다가 문득 시작 단추를 누르게 되었다.

"사매 로그오프"라는 부분, 곧 사용자 이름(사매)에 한글이 포함되어 있었다. 명령 프롬프트를 열어서 SET 명령을 입력했다.

SET 명령 실행 화면

명령 프롬프트에서 SET 명령 실행 화면

위와 같이 TEMP 환경 변수(핑크색 밑줄 부분)에도 한글이 포함되어 있음을 확인했다. 이 TEMP 환경변수는 프로그램이 실행될 때 임시파일을 만드는 경로인데, 한글이 포함될 경우 로마자 언어를 기준으로 작성된 프로그램에서는 가끔 오류가 생기기도 한다. 작게는 저장할 때 저장을 할 수 없는 문제가 있고, 이번처럼 아예 실행이 되지 않는 경우도 있다. 이것은 프로그램 제작자의 실수이지만, 해결할 방법은 있다. 바로 TEMP 환경변수의 경로를 바꾸면 된다.

벌레 잡기

이것을 해결하려면 시스템 환경변수를 다루어야 한다.

바탕화면에 내 컴퓨터 아이콘이 있다면 거기에서 마우스 오른쪽 단추를 클릭하여 속성을 선택하면 된다.

그게 아니라면 제어판(시작 단추 >> 설정 >> 제어판)을 열고, 거기에서 시스템을 두번클릭하면 된다. 그 뒤 고급 탭을 클릭한다.

시스템 등록 정보

시스템 등록 정보의 고급 탭을 클릭한

환경 변수를 클릭한다.

TEMP를 클릭하여 선택한 다음 편집 단추를 클릭한다.


위 그림처럼 보이게 되는데, 이때 아래처럼 바꾼다. 위의 그림은, 경로가 앞서 보여준 명령 프롬프트 화면의 C:\DOCUME~1\사매\LOCALS~1\Temp처럼 보이게 된다. 바로 한글 사매사용자 이름이고, %USERPROFILE% 환경변수는 사용자 이름을 참조하기 때문이다. 물론 근본적으로 사용자 이름을 한글이 아닌 로마자로만 지으면 되지만, 한글 이름을 쓰고 싶은 경우도 많으므로, 이렇게 고쳐 주면 해결할 수 있다.
아무튼 아래의 그림처럼 한글이 포함되지 않은 경로를 지정해 주면 된다. 이때 해당 경로가 존재하지 않는다면 그 폴더를 만들어 주면 된다. 마지막에는 반드시 확인을 클릭한다.

TMP 환경 변수TEMP 환경변수와 같게 만들어주면 된다.

확인을 눌러주면 편집한 환경 변수가 저장된다.

지금까지 작업을 마쳤으면 다시 버추얼박스 설치 프로그램을 클릭하여 실행한다.

제작자/제공자의 답변

2009년 5월 9일 오후 8시 20분 무렵(May 9th, 2009, 9:19 pm / 1시간의 오차는 일광시간절약제와 관련한 오류로 여겨진다.)에 버그리포팅을 하였다.

관련 문서

내부 문서

외부 문서

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


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

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

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

벌레의 유형

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

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

벌레의 발견

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

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

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

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

상태 표시줄 화면

상태 표시줄 화면

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

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

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

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

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

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

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

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

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

회사 측 답변

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

관련 문서 및 페이지

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

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

들어가며

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

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

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

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

추상적인 버그리포팅

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

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

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

재현 불가

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

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

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

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

정책적인 이유

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

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

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

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

답변자의 무지 또는 무성의

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

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

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

대응

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

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

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

관련 문서

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

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

티스토리에서 이미지 갤러리를 넣으려고 했는데, 뜻밖에도 본문에 삽입된 것은 슬라이드쇼였다. 의도하지 않은 일이 생겨서 기분이 좋지 않았는데, 삽입된 슬라이드쇼가 정상 동작하지 않았다. 첫째 이미지와 마지막 이미지를 보여주지 않았다. 다시 말해 7개의 이미지로 이미지 갤러리를 만들어서 본문에 넣게 했는데, 실제로 본문에 들어간 것은 5개의 이미지를 가진 슬라이드쇼였다.

벌레의 유형

  1. 맏이와 막내를 왕따시키는 별난 벌레이다. 아, 벌레는 원래 이상한 놈들이라고. 그 말도 맞다.
  2. 실제로는 저와 관련없이 업로드 실패 시에 나타나는 벌레이다.

한편 티스토리나 다른 블로그에서 등장했던 변신술을 익힌 벌레가 여기에서도 등장한다고 생각했다. 이미지 갤러리를 만들라고 하니까 왜 슬라이드쇼를 만들어 버렸기 때문이다. 그러나 검색 결과 티스토리 매뉴얼 블로그[확장 업로드 기능] 업로드된 파일을 다양한 형태로 이용해 봅시다[이미지] 슬라이드쇼의 사용법을 알고 싶어요라는 글이 있었다. 결국 이미지 갤러리를 만들게 되면 슬라이드쇼로서 그것을 구현한다는 사실을 알게 되었다. 그밖에 사항은 다음 고객센터에서 TISTORY > 글 관리 부분을 살펴보기 바란다.

벌레의 발견

[확장 업로드 기능] 업로드된 파일을 다양한 형태로 이용해 봅시다라는 블로그 기사에서 이미지 갤러리는 슬라이드 효과를 자바스크립트를 이용하여 갤러리로 생성한다고 설명하고 있다. 나는 그것을 몰랐지만, 아무튼 HxD 소개 기사를 쓰면서 이미지 갤러리 기능을 이용하여 슬라이드쇼를 만들었다.

위의 그림에서 빨갛게 표시한 부분(? (경)자처럼 보이는 부분)을 클릭하여 이미지 갤러리를 만들었다. 이때 파일을 7개 선택하였다.

그런데 실제로 만들어진 이미지 갤러리에서는 위와 같이 5개의 파일만 포함되어 있다고 나타나고 있었다. 참고로 저 저작권 화면은 2번째 파일이다. ▶▶ 아이콘을 클릭하여 다음 파일을 살펴보았다. 그럼으로써 알게 된 사실은 첫 파일과 마지막 파일이 나타나지 않는다는 점이었다.


위의 두 파일은 모질라 파이어폭스(v3.0.9)에서의 티스토리 편집창 화면이다. 두 화면 모두 오른쪽에 보면 파일이 7개임을 알 수 있다. 이미지 갤러리를 만들때 순서가 흩트러지기에 파일명 맨 앞에 숫자를 붙여두었다. 다시 말해 1번부터 7번까지 있다는 말이다. 첫 화면은 위지위그 편집기 모드이고, 두 번째 화면은 HTML 편집 모드이다.

첨부한 파일의 수를 세었다. 그러나 위와 같이 모두 7개였다. 결국 화면에 나타낼 때 오류가 생긴다는 사실을 알게 되었다.

혹시나 하는 마음에 인터넷 익스플로러(v6 sp2)에서도 시험해 보았다. 결과는 마찬가지였다.

결국 편집창 상단에 있는 슬라이드쇼 아이콘(Tistory-SlideShow-Icon)을 클릭하여 이미지 갤러리를 삽입하게 되었다. 그 과정에서 알게된 이 버그가 이미지 파일을 정확히 인식하지 못해서 발생하고 있다는 심증을 갖게 하였다.

위의 그림은 슬라이드쇼에서 업로드시킨 이미지 파일이다. 그런데 조금 이상한 점이 보이지 않는가? 바로 첫째와 둘째 파일은 이미지의 크기와 파일 크기가 나타나고 있으나, 셋째 파일은 파일 크기만 나타나고 있다.

황당한 점은 이미지 갤러리로 만든 슬라이드쇼에서는 정확히 인식하지 못한 파일은 최종 결과에서 빼버리고 슬라이드쇼를 만들지만, 슬라이드쇼 아이콘을 클릭하여 만든 슬라이드쇼에서는 제대로 인식하지 못하는 파일도 최종 결과에 포함시켜 슬라이드쇼를 만들어준다. 이렇게 제대로 인식되지 않는 원인으로는 업로드 실패일 가능성이 가장 높다고 생각한다.

벌레의 제거

이 벌레를 제거하는 방법은 단순하다.

아무리 해도 안 되는 일은 그냥 포기하고 다시 업로드 하면 된다. 이미 업로드 된 파일로 이미지 갤러리를 만들려고 해도 안 된다면 그냥 다시 업로드하는 쪽이 낫다는 말이다. 어차피 내 예상대로 업로드 오류였다면, 다시 업로드함으로써 그 벌레는 사라지게 된다. 실제로 HxD 소개 기사는 현재 이미지 갤러리가 제대로 보이고 있다.

또한 애초에 슬라이드쇼 아이콘을 클릭하여 슬라이드쇼를 만들어도 된다. 엎어치나 메치나 같은 결과를 보여주기 때문이다.

회사 측 답변

이 문제는 버그 리포팅을 하지 않았다.

관련 문서

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

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

며칠 전 버추얼박스 홈페이지에 들렀다가 버추얼박스 2.2.0판이 공개되었음을 알고 업데이트 하였다. 그런데 업데이트를 하기 전까지 잘 되던 게스트OS 안에서의 네트워크 연결이 전혀 되지 않았다. 처음에는 업데이트를 잘못했다고 생각했으나, 업데이트하지 않고 2.2.0판을 설치한 경우에도 네트워크 연결에 문제가 있다는 글이 버추얼박스 포럼에 올라와 있었다.

읽기에 앞서

이 글에 쓰인 방법을 적용해도 얼마 뒤에 다시 네트워크 기능이 동작하지 않는다면, 자신이 고정 아이피를 사용하는지를 살펴보기 바란다. 무슨 까닭에서인지 아이피를 고정 시키면 네트워크가 제한되었다.

참고로, 이 글이 쓰인 브리징을 하면 고정 아이피가 유동 아이피로 바뀌는 현상을 보였다.

2009년 4월 27일자 버추얼박스 2.2.2판을 받아서 설치하면 대부분의 벌레를 잡을 수 있다고 한다. 버추얼박스 2.2.0판 때문에 어려움을 겪는다면 필히 설치하기 바란다.

벌레의 유형

네트워크를 막는 벌레로서 혼자(?) 살고 싶어 하는 나쁜 버릇을 가진 벌레이지 않을까 생각한다. 그렇지 않고서야 왜 네트워크를 막을까? 그래서 이 벌레의 나쁜 버릇을 고치기 위해 함께 살 녀석과 다리(브리지)를 놓아줌으로써 해결하였다.

  • 참고 : 이 현상은 벌레라고 보기가 애매하다. 업데이트 하던 도중에 네트워크와 관련한 경고가 있었기 때문이다. 다시 말해 내가 업데이트 도중에 실수한 바도 있다. 그러나 그 경고가 아예 네트워크 연결을 못하게 하는 경고라고는 생각지 않았다. 버추얼박스 포럼에도 그와 비슷한 문제를 호소하는 사람이 많은 것도 그런 까닭으로 보인다.

벌레의 제거

이와 비슷한 현상을 발견하고 구글링을 하여 오즈맨 님의 블로그에서 글을 발견했다. 하지만 그 글은 이전 버전을 기준으로 작성한 탓인지 2.2판에는 맞지 않은 자료화면이 있었다. 오즈맨 님의 글 <오즈맨의 이야기 :: 버철박스 VirtualBox 에서 인터넷 Internet 이 안되면>에서 7번과 8번 설명대로 하면 된다.

2.2판에 맞추어 다시 구성하면 아래와 같다.

2.2.0판을 설치/업데이트하자 위의 왼쪽 화면처럼 네트워크 설정을 찾기 시작했다. 그러다가 한참이 지난 뒤 위의 오른쪽처럼 네트워크를 사용할 수 없다는 표시를 보여주었다. 버추얼박스를 실행하여 게스트OS(윈도XP SP2)를 실행하니 아니나 다를까 인터넷 익스플로러가 홈페이지를 찾지 못하였다.

구글링을 하여 오즈맨 님의 글을 찾았고, 그 글에 따라 해결하려고 시도를 했다. 그런데...

위와 같이 화면이 바뀌어 있었다. 버전이 바뀌면서 환경 설정이 조금 바뀌었기 때문이다. 이때 "다음에 연결됨"은 현재 상태로 "NAT"로 두어도 되고 "호스트 전용 네트워크"로 바꾸어도 된다. 물론 아무것도 안 건드려도 된다.

내 네트워크 환경에서 오른쪽 클릭하여 속성을 선택한다.

VirtualBox Host-Only Ethernet 아이콘에 노란색 경고 표시가 달려 있다.

마우스로 VirtualBox Host-Only Ethernet 아이콘과 로컬 영역 연결 아이콘을 모두 선택한 뒤 그 위에서 오른쪽 클릭 한 뒤 연결 브리지를 선택한다.

위와 같이 네트워크 브리지를 만드는 알림이 잠시 보인다. 저것이 사라진 뒤에 조금 더 기다리면 아래와 같이 된다.

위와 같이 "네트워크 브리지 (네트워크 브리지)" 아이콘이 작업을 완료하면 생겨난다.

버추얼박스를 실행하여 네트워크에 잘 연결되는지 확인하면 된다.

회사 측 답변

현재 나보다 먼저 발견한 사람이 버그리포팅을 한 상태이다.

관련 문서

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

'벌레와 팁 > 버그' 카테고리의 다른 글

스프링노트의 태그 표기 벌레  (0) 2009.04.26
티스토리 이미지 갤러리 문제  (0) 2009.04.24
네이버 결계 벌레  (3) 2009.04.07
네이버 뻥튀기 벌레  (0) 2009.04.05
구글이 음란 사이트?  (3) 2009.04.05
글쓴이는 koc/SALM입니다.
본문에 저작권에 대한 사항이 나타나지 않거나, 저작권이 BY-SA로 표기되어 있다면,
이 글은 GFDL로 공개한 글입니다.

읽기에 앞서

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

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

벌레의 유형

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

벌레의 발견

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

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

일단 위의 그림이 어떻게 보이는지부터 알아보자. 아래에는 <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일 현재 답변을 받았다. 그런데 아주 어이없는 답변이다.

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

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

관련 문서

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

  1. 아니다. 유난히 몹쓸짓을 네이버가 많이 했기 때문이다. [본문으로]
  2. 그게 이치에 맞는다면, 네이버는 주민등록번호를 검색해서 모아도 된다는 네이버스러운 사고방식이다. [본문으로]
글쓴이는 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로 공개한 글입니다.

읽기에 앞서

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

벌레의 유형

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

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

벌레의 발견

벌레 정보

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

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

벌레 찾기

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

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

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

제작자/제공자의 답변

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

관련 문서

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

글쓴이는 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로 공개한 글입니다.

벌레의 유형

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

벌레의 발견

벌레 정보

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

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

벌레 찾기

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

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

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

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

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

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

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

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

제작자/제공자의 답변

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

관련 문서

 

 

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

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

알리는 말

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

벌레의 유형

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

벌레의 발견

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

위의 그림을 보면 두 글자가 같음을 알 수 있다. 빨간 테두리를 두른 글자 두 개가 그것들이다.

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

회사 측 답변1

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

추가

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

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

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

카테고리

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

최근에 올라온 글

최근에 달린 댓글

최근에 받은 트랙백

달력

«   2024/11   »
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

글 보관함