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


한컴오피스2010 베타버전 버그 31 - ᄒᆞᆫ에서 다른 이름으로 저장하기와 주석 표기 문제

ᄒᆞᆫ글2010 베타버전에서 다른 이름으로 저장하기를 통해 HTML 문서를 만들거나 블로그로 올리기를 통해 블로그에 올린 게시물에 나타나는 주석과 관련한 HTML 태그 표기 때문에 약간의 오류가 생기고 있음을 발견했습니다.

  • 참고 : 본문에서는 블로그로 올리기 문제만 다루었으나, 다른 이름으로 저장 - 인터넷 문서도 같은 벌레가 나타나고 있습니다.

벌레의 유형

ᄒᆞᆫ글 씨! 이 버그는 반드시 고쳐 주셔야겠습니다. 이 버그가 고쳐지지 않으면 ᄒᆞᆫ글에서 작성한 주석은 HTML로 고쳤을 때 대부분 자리 표시에 불과하게 됩니다.

개발자의 답변

2010년 2월 5일 버그 리포팅을 한 상태입니다.

벌레의 발견

이 벌레는 우연히 블로그 - (X)HTML 태그 표기 문제 문서를 다시 살피다가 발견했습니다. 그 문서에서 주석의 링크를 클릭했음에도 이동하지 않아서 문제가 있음을 알게 되었습니다.

티스토리 및 텍스트큐브의 주석

티스토리와 텍스트큐브는 태터툴즈를 사용하는 블로그이므로 주석의 동작도 거의 비슷합니다.

일단 제 블로그의 7-Zip 소개 글을 살펴보겠습니다.

블로그에 나타난 주석 (빨간 동그라미 안쪽)

블로그에 나타난 주석 (빨간 동그라미 안쪽)

위 그림에서 빨간 동그라미 안쪽에 주석이 있습니다. 이 주석을 클릭하면 주석을 나타내는 부분으로 이동합니다.

주석 부분으로 이동한 뒤의 화면

주석 부분으로 이동한 뒤의 화면

주석 부분으로 이동하면 위와 같은 화면이 됩니다. 이때 [본문으로](파란 네모 부분)를 클릭하면 이 주석을 호출한 곳으로 이동합니다.

[본문으로]를 클릭했을 때의 화면

[본문으로]를 클릭했을 때의 화면

앞서 [본문으로]를 클릭하면 위와 같이 이동을 해 줍니다.

ᄒᆞᆫ글 2010 베타에서 출력한 주석의 동작

테스트 블로그의 예제 문서를 이용하여 테스트하겠습니다. 참고로 이 예제 문서는 IE6와 파이어폭스에서 서로 다른 결과를 보여줍니다. 여기에서는 파이어폭스 3.5 버전을 이용하겠습니다. 첨언하자면, 여기에 사용한 HTML 코드가 올바르지 않기 때문에 동작하지 않아야 정상입니다. 다시 말해 동작하는 IE6의 경우가 틀린 경우이지 파이어폭스가 틀린 것은 아닙니다.

ᄒᆞᆫ글에서 블로그로 올린 주석이 있는 문서

ᄒᆞᆫ글에서 블로그로 올린 주석이 있는 문서

위의 ᄒᆞᆫ글에서 블로그로 올린 주석이 있는 문서에서 주석을 클릭하면? 아래 그림처럼 됩니다.

이동은 않고 주소 표시줄만 바뀐 화면

이동은 않고 주소 표시줄만 바뀐 화면

위 그림처럼 이동은 하지 않았습니다. 그저 주소 표시줄만 바뀌었죠.

벌레 분석

코드 보기

앞서 발견한 두 경우의 HTML 코드를 분석해 보겠습니다.

티스토리 주석의 HTML 코드

티스토리 주석은 아래와 같습니다.

티스토리의 주석 표시 부분의 HTML 코드

티스토리의 주석 표시 부분의 HTML 코드


티스토리의 주석 내용 부분의 HTML 코드

티스토리의 주석 내용 부분의 HTML 코드

ᄒᆞᆫ글에서 블로그로 올린 문서의 HTML 코드

예제 문서의 HTML 코드는 다음과 같습니다.

블로그로 올린 문서의 주석 표시 부분의 HTML 코드

블로그로 올린 문서의 주석 표시 부분의 HTML 코드

앞서의 실험에서는 주석 내용 부분은 나타나지 않았지만, 여기에서는 주석 내용 부분도 HTML 코드를 나타내 보겠습니다.

블로그로 올린 문서의 주석 내용 부분의 HTML 코드

블로그로 올린 문서의 주석 내용 부분의 HTML 코드

코드 간략화 및 구조 분석

코드가 복잡하므로 간략하게 구조만 나타내 보겠습니다. 아울러 생략된 부분도 함께 나타내겠습니다.

먼저 티스토리 주석의 HTML 구조입니다.

[code html] <p>본문 내용 1<sup class="footnote"><a id="footnote_link_208_1" href="#footnote_208_1"><span style="display: none;">[각주:</span>1<span style="display: none;">]</span></a></sup>)</p> <p>본문 내용 2</p> <p>본문 내용 3</p> <div class="footnotes">     <ol class="footnotes">         <li id="footnote_208_1">주석 내용 1<a href="#footnote_link_208_1">[본문으로]</a></li>     </ol> </div> [/code]

다음은 블로그로 올린 문서의 HTML 구조입니다.

[code html] <p class="HStyle0">본문 내용 1<a href="#FOOTNOTE1"><sup>1)</sup></a></p> <p class="HStyle0">본문 내용 2</p> <p class="HStyle0">본문 내용 3</p> <hr align="left" width="300px"> <p class="HStyle11"><a name="#FOOTNOTE1">1)&nbsp;주석 내용 1</a></p> [/code]

위 두 코드에서 차이점은 (1) id와 name의 차이, (2) 링크를 이용한 왕복과 편도, (3) 링크 대상을 가리키는 이름의 차이(# 표시가 있느냐 없느냐)입니다. 일단 id와 name의 차이는 여러 문서를 함께 볼 경우에는 문제가 생기지만, 예제 문서는 오직 1개의 문서만을 화면에 표시하고 있으므로 이게 문제는 아닙니다. 그 다음으로 링크를 이용한 왕복이나 편도 이동이냐는 전혀 문젯거리가 아닙니다. 넘어가죠. 마지막으로 링크 대상을 가리킬 때 # 표시를 붙이느냐 마느냐는 상당히 차이가 큽니다.

일단 # 표시는 문서 내부의 이동 표시임을 나타내고 있습니다. 보통 # 표시 다음에는 id나 name로 표시하는 객체 이름(Object name)이 오게 됩니다. 그렇다면 # 자체가 객체 이름이냐? 그렇지는 않습니다. #은 문서와 문서 내부의 객체 이름과의 구분을 해 주는 표시일 뿐입니다. 다시 말해 #을 붙여서 id나 name을 표시하지는 않는다는 뜻입니다. 과거에는 #을 붙여서 표시하여도 호환성에 문제가 없었으나, 지금은 이 부분에 대해 엄격히 검사하고 있습니다. 현재 # 표시가 붙어 있어도 이동이 가능한 웹브라우저는 IE 계열뿐이며, 파이어폭스 등의 모질라/게코 계열이나 오페라 계열의 웹브라우저는 # 표시가 붙은 객체로의 이동을 지원하지 않습니다.

그러므로 위의 코드는 다음과 같이 고쳐야 합니다.

[code html] <p class="HStyle0">본문 내용 1<a href="#FOOTNOTE1"><sup>1)</sup></a></p> <p class="HStyle0">본문 내용 2</p> <p class="HStyle0">본문 내용 3</p> <hr align="left" width="300px"> <p class="HStyle11"><a name="FOOTNOTE1">1)&nbsp;주석 내용 1</a></p> [/code]

맨 마지막 줄에서 # 표시를 떼었습니다.

참고로 테스트 블로그에 이 부분에 대해 시험할 예제 문서(예제 - 주석과 위치 이동)를 올려 두었습니다. 직접 보시고 시험해 보시기 바랍니다. 참고로 주석 1은 정상적으로 이동이 가능하고, 주석 2는 IE 계열에서면 이동이 가능합니다.

결론

링크를 표시하면서 앵커(A 태그)에 name 속성에 # 문자가 들어간 이름을 넣었기 때문에 발생한 문제입니다. 그 문자를 떼면 정상적으로 이동이 가능합니다. 추가로 본문으로의 이동을 지원하도록 바꾸고, 아울러 앵커(A 태그) 때문에 밑줄이 생기는 현상도 제거하려면 다음과 같이 고치면 됩니다.

[code html] <p class="HStyle0">본문 내용 1<a id="FOOTNOTE_HWP_ARTICLE_[문서번호]_1" href="#FOOTNOTE_HWP_1"><sup>1)</sup></a></p> <p class="HStyle0">본문 내용 2</p> <p class="HStyle0">본문 내용 3</p> <div class="HStyle11">     <hr align="left" width="300px">     <ol start="1">         <li id="FOOTNOTE_HWP_1">주석 내용 1<a href="#FOOTNOTE_HWP_ARTICLE_[문서번호]_1">[본문으로]</a></li>     </ol> </div> [/code]

위와 같이 바꾸면 좀 더 구조적이고 효율적인 코드가 됩니다. 참고로 [문서번호]에 해당하는 값으로 치환해야 합니다. 그밖에 <ol start="1">의 경우는 시작하는 주석 번호1이라는 뜻입니다. 주석 번호를 하나하나 지정할 필요가 없다는 뜻입니다. 아무튼 이것을 적용하는 문제는 ᄒᆞᆫ글 개발자가 해결할 일이겠지요.

관련 벌레

이 벌레와 관련이 있는 벌레는 다음과 같습니다.

관련 문서

내부 문서

외부 문서

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


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

한컴오피스 베타버전 버그 19 - 빈곳에 하이퍼텍스트 지정할 때의 버그

최근 한컴오피스2010 베타버전의 ᄒᆞᆫ글을 사용하면서 하이퍼링크를 자주 만들었습니다. 블로그로 올리기 기능을 사용해야 하므로 자주 쓰지 않을 수 없었죠. 그런데 빈 공간에 하이퍼링크를 만들면 다른 글자를 지워 버리는 현상을 발견했습니다.

1. 벌레의 유형

ᄒᆞᆫ글 씨! 하이퍼링크를 만들 때 표시할 문자열이 왜 다른 문자열을 침범하게 두나요? 새롭게 지정한 문자열에게는 새로운 공간을 배정해야 하지 않나요?

괜히 남의 자리 차지하는 엉뚱한 벌레입니다.

2. 개발자의 답변

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

3. 벌레의 발견

하이퍼링크를 만들다가 우연히 빈곳에 영역을 설정하지 않고 하이퍼링크를 만들면서 발견했습니다.

3.1. 영역 지정 후 하이퍼링크 만들기

그림 1 영역 설정 후 하이퍼링크 지정하기

위 그림에서 하이퍼링크를 지정할 때 설명이 나타나 있습니다.

그림 2 하이퍼링크 지정에 대한 설명

아무튼 하이퍼링크는 현재 커서 위치, 선택된 개체, 블록 잡은 영역에 삽입할 수 있다고 밝혀져 있습니다.

그림 3 웹 주소로 하이퍼링크 연결하기

위와 같이 작업을 하면 다음과 같이 나타납니다.

그림 4 하이퍼링크로 연결한 뒤의 화면 (아래 잘랐음)

3.2. 영역 설정 없이 하이퍼링크 만들기

앞의 3.1.에서는 영역을 설정한 뒤에 하이퍼링크를 만들었습니다. 이번에는 그냥 아무 곳에나 만들어 보겠습니다.

그림 5 현재 커서 위치를 잘 보십시오.

위에서 커서 위치는 영역 설정 없이 “벌레와”라는 문자열 다음입니다.

그림 6 마음대로 영역을 지정합니다.

위 그림에서 보면 ᄒᆞᆫ글의 하이퍼링크 기능을 사용하면 마음대로 영역을 설정하고 있습니다. 게다가 그곳의 문자열을 복사해 옵니다.

처음에는 아무것도 모르고 저곳에 표시할 문자열을 새로 지정했습니다. 이번에도 그렇게 하겠습니다.

그림 7 새롭게 지정한 표시할 문자열

의심도 않고 표시할 문자열[벌레와버그로 바꾸었습니다.

그림 8 바뀐 문자열

위 그림에서 보면 문자열이 버그로 바뀌어 있습니다. 원래 있던 [벌레와는 사라져 버렸죠. 그것을 예상할 수 있는 사람은 과연 몇 사람이나 될까요?

3.3. 다른 프로그램에서 하이퍼링크 만들기

그렇다면 다른 프로그램에서는 하이퍼링크를 만들 때 어떻게 할까요? 물론 다른 프로그램과 비교하는 것이 그다지 좋은 방법은 아닙니다. ᄒᆞᆫ글에는 ᄒᆞᆫ글만의 독창적인 방법이 있기 때문입니다. 하지만 다른 프로그램이 모두 ‘갑’이라는 방법을 사용할 때 ᄒᆞᆫ글과 홀로 ‘을’이라는 방법을 쓴다면? 거기다 ‘을’이라는 방법이 ‘갑’과 그 과정은 같고 최종 결과만 다르다면? 아무래도 ‘을’이라는 방법을 이상하게 여기는 사람이 늘어나지 않을까요?

MS Word 2010 (Beta)에서 하이퍼링크를 만들어 보았습니다.

그림 9 커서의 위치는 아까 했던 작업 위치입니다.

위에서 커서 위치는 앞서 작업했던 그 위치입니다.

그림 10 링크 만들기

위 그림처럼 Insert 메뉴에서 Links 아이콘의 아랫부분을 클릭하면 세 개의 아이콘이 나오는데, 그 가운데 Hyperlink를 선택합니다.(MS Word의 작업은 일부러 자세히 설명하는 것입니다. 아직까지 워드프로세서는 ᄒᆞᆫ글만 아는 사람이 많으니까요.)

그림 11 링크 삽입 대화상자

그림 12 링크 적용 후의 화면

MS Word에서는 위와 같이 문자열을 새로 만들어 삽입했습니다. 그런데 ᄒᆞᆫ글을 강제로 영역을 설정하여 기존에 있던 문자열을 수정했습니다. 문제는 다른 프로그램은 모두 MS Word의 방식을 따르는데, ᄒᆞᆫ글만 혼자 놀고 있습니다.

옳고 그름을 떠나서 어느 쪽이 불편할까요? 아예 다른 기능에서 다른 결과가 나오면 사람들은 수긍하지만, 비슷한 기능에서 혼자만 다른 결과를 보여주면 그것을 어색하게 여기게 됩니다.

4. 벌레의 원인 및 덧붙이는 말

앞서 ᄒᆞᆫ글의 안내문에서 하이퍼링크는 현재 커서 위치, 선택된 개체, 블록 잡은 영역삽입할 수 있다고 밝혔습니다. 그런데 결과는 삽입이 아니라 기존 문자열을 수정하는 경우도 있습니다. 이건 누가 예상할 수 있을까요?

앞의 예시 그림(그림 6)은 그렇게 영역 설정을 ᄒᆞᆫ글이 마음대로 하는 장면을 일부러 스크린샷으로 잡았지만, 만약에 하이퍼링크 대화상자에 가려서 그런 장면이 나타나지 않는다면? 그때 정말로 사람들은 납득할 수 없게 되지 않을까요?

안내문 내용을 믿은 사람이라면 누구나, 영역 설정을 하지 않은 경우에, 기존 문자열을 덮어쓰게 되리라고 예상할 수 있는 사람은 없다고 생각합니다.

결과적으로 이번 벌레는 한글과컴퓨터사의 자사 중심주의 때문에 생겨난, 다른 회사 제품이야 어떻든지 ᄒᆞᆫ글에는 ᄒᆞᆫ글의 방식이 있음을 너무 고집한 탓에 생겨난 벌레로 여겨집니다.

5. 비슷한 벌레

[벌레와 팁/버그] - 스프링노트의 태그 표기 벌레

6. 관련 문서

6.1. 내부 문서

6.2. 외부 문서 - 테스트 블로그

(없음)

이 글은 ᄒᆞᆫ글 2010 베타버전에서 작성하였습니다.

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

한컴오피스 베타버전 버그 13 - ᄒᆞᆫ글 씨! 링크를 왜 엉뚱하게 표시하나요? 3

ᄒᆞᆫ글 씨! 링크를 왜 엉뚱하게 표시하나요? 문서에 이어 ᄒᆞᆫ글 씨! 링크를 왜 엉뚱하게 표시하나요? 2 문서를 작성하면서 예상보다 사태가 심각하다고 여기게 되었습니다.

1. 벌레의 유형

이번에는 인쇄(프린트) 기능과 관련하여 하이퍼링크 색상을 엉뚱하게 보여주고 있음을 확인했습니다. 물론 이전에 제가 예상했던 그 원인 때문이었습니다. 바로 열어 본 링크열어 보지 않은 링크에 대한 정보를 파일 포맷에서 따로 관리하지 않고, 문서 내용으로서 관리함으로써 문서 내용으로 인식된 그것이 오류를 일으키고 있습니다.

2. 개발자의 답변

2010년 1월 7일 버그 리포팅을 한 상태입니다.

3. 벌레의 발견

‘그저 PDF 파일이나 만들어 볼까?’라는 가벼운 마음으로 인쇄를 했다가 발견했습니다.

3.1. 열어 본 링크가 없는 문서를 PDF로 저장

그림 1 편집 화면

그림 2 인쇄 미리보기 화면

위에서 보면 편집 화면과 미리보기 화면에는 보라돌이 링크가 전혀 보이지 않습니다. 일부러 앞서 ᄒᆞᆫ글 씨! 링크를 왜 엉뚱하게 표시하나요? 2 문서에서 이 버그에 대해 확인하면서 새로 만든 하이퍼링크이기 때문입니다.

그림 3 인쇄 대화상자

위와 같은 인쇄 대화상자에서 Haansoft PDF를 선택한 다음 인쇄를 클릭한다.

그림 4 PDF 파일로 출력하게 되면….

그림 5 PDF 출력 정보

PDF 파일로 출력하게 되면 난데없이 다른 이름으로 저장 대화상자가 나타난다. 이 대화상자에 이름을 지정해 주면 PDF 파일로 저장해 줍니다. 이때 이름은 링크 테스트.pdf라고 주었습니다.

이때 PDF 파일로 출력하려면, 파일 메뉴에서 PDF로 저장하기를 선택해도 됩니다.

그림 6 출력한 PDF 파일 보기

3.2. 열어 본 링크가 하나 있는 문서를 PDF로 저장

이번에는 링크 하나를 골라서 클릭합니다. 그리고 그것을 인쇄 미리보기 하면 다음과 같습니다.

그림 7 열어 본 링크를 하나 만들었습니다.

그림 8 인쇄 미리보기에서도 나타난 열어 본 링크 하나

이것을 PDF로 저장한다면, 그래도 나타날까요? 지금까지의 과정을 살펴보면 나타나게 됩니다. 하지만 나타나지 않았으면 합니다.

그림 9 PDF 출력 정보 2

이번에는 링크 테스트 1.pdf 파일로 저장했습니다.

그림 10 출력한 PDF 파일 보기

불행히도 제 바람은 이루어지지 않았습니다.

3.3. 어떤 곳에서 발생하나?

이 벌레는 어떤 곳에 살고 있는지 점검해 보겠습니다.

일단 인쇄와 관련된 기능에는 모두 이 벌레가 나타난다고 여겨집니다. 그림 3 인쇄 대화상자에 나타난 PDF-Pro Free, Microsoft XPS Document Writer, Haansoft PDF 및 그 그림에는 나타나지 않은 PDF 저장, 그림으로 저장하기 기능에서는 이 벌레를 발견했습니다. Send To OneNote 2010 또는 팩스로 보내기에서도 역시 이 벌레가 나타나리라 생각합니다. 이것은 인쇄 기능의 문제가 아니라 파일 구조와 내용에 대한 문제이기 때문입니다.

그림 11 출력한 XPS 파일 내용

저장 기능에서도 나타나고 있습니다. 저장하기다른 이름으로 저장하기에서도 역시 나타나는 내용입니다.

또한 웹 게시 기능에서도 나타났습니다. 이 기능은 다른 이름으로 저장하기의 대상을 단순히 또는 블로그로 바꾸었을 뿐이기 때문에 당연히 나타나게 된다고 생각합니다. 블로그로 올리기, 초안으로 올리기, 웹 브라우저로 보내기, 웹 서버로 올리기 등에서도 발견했습니다.

4. 벌레의 원인

앞서 밝혔듯이 링크에 대한 정보, 열어 본 링크 또는 열어 보지 않은 링크 여부파일 내용으로 직접 저장하고 있기 때문에 발생한 문제로 여겨집니다.

또한 앞서 주장했듯이, 이 문제는 비단 파일 저장(다른 이름으로 저장 포함)이나, 블로그로 올리기에만 한정된 벌레가 아닙니다. 파일의 내용을 입력하거나 편집하고, 또는 외부로 출력하는 모든 기능에서 이 벌레가 나타날 가능성이 있고, 이번에 인쇄 미리보기, 인쇄 PDF 등의 인쇄 기능에서 확인했습니다. 직접 종이에 인쇄하기는 할 수 없지만, PDF 출력과 비교하여 그리 다르지 않으리라 예상하고 있습니다.

5. 비슷한 벌레

[벌레와 팁/버그] - ᄒᆞᆫ글 씨! 링크를 왜 엉뚱하게 표시하나요?

[벌레와 팁/버그] - ᄒᆞᆫ글 씨! 링크를 왜 엉뚱하게 표시하나요? 2

6. 관련 문서

시험 결과를 알고 싶은 분들을 위해 압축파일을 열어 보시면 PDF 파일 2개(PDF 저장), PNG 파일(그림으로 저장하기), XPS 파일 등이 들어 있습니다.

6.1. 내부 문서

[벌레와 팁/버그] - ᄒᆞᆫ글 씨! 기본은 지켜야죠!

[벌레와 팁/버그] - ᄒᆞᆫ글 씨! 링크를 왜 엉뚱하게 표시하나요? 2

[벌레와 팁/버그] - ᄒᆞᆫ글 씨! 맞춤법 도우미로 엉뚱한 곳을 표시하면 어떡해요?

[벌레와 팁/버그] - ᄒᆞᆫ글 씨! 링크를 왜 엉뚱하게 표시하나요?

[벌레와 팁/제안] - 한컴오피스 베타버전의 공백과 이동 기능

[벌레와 팁/버그] - ᄒᆞᆫ글 씨! 블로그에는 글을 하나만 올리란 말입니다.

[벌레와 팁/버그] - ᄒᆞᆫ글 씨! ‘ᄒᆞᆫ글’을 제대로 나타내면 안 되겠니? 2

[벌레와 팁/버그] - ᄒᆞᆫ글 씨! ‘ᄒᆞᆫ글’을 제대로 나타내면 안 되겠니?

[벌레와 팁/버그] - ᄒᆞᆫ글 씨! 블로그 카테고리는 어디에?

[벌레와 팁/버그] - ᄒᆞᆫ글 씨! 블로그에는 게시판이 없거든요.

[벌레와 팁/버그] - HTML 태그 해석 오류 문제

[벌레와 팁/버그] - 도대체 무슨 짓을 하는 거냐, ᄒᆞᆫ글?

[프로그램/스크린샷] - 한컴오피스2010 베타버전 실행화면

[벌레와 팁/버그] - 한컴오피스2010 베타 설치 작업과 버그 몇 개

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

6.2. 외부 문서 - 테스트 블로그

이 글은 ᄒᆞᆫ글 2010 베타버전에서 작성하였습니다.

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

한컴오피스 베타버전 버그 11 - ᄒᆞᆫ글 씨! 링크를 왜 엉뚱하게 표시하나요? 2

계속 블로그 관련 버그를 올리다가 문득 ᄒᆞᆫ글 씨! 링크를 왜 엉뚱하게 표시하나요? 문서에 나타난 버그가 다른 곳에서도 나타날 수 있다는 생각이 들었습니다. 제 예상대로 그 버그가 링크에 대한 정보HWP 구조가 아닌 파일 내용의 일부로서 저장한다면, 파일 내용을 저장하거나 이용하는 모든 항목에서 발생할 수 있습니다.

1. 벌레의 유형

이보세요, ᄒᆞᆫ글 씨! 열어 본 링크열어 보지 않은 링크에 대한 정보는 ‘내용’이 아니라 ‘파일 구조’(포맷)에 포함해야 하는 내용이 아닌가요?

파일을 저장한 뒤에 읽어오면, 왜 열어 본 링크열어 보지 않은 링크에 대한 정보를 파일 내용으로 그대로 남겼다가 다시 읽어옵니까? 왜 클립보드로 복사하면 그 열어 본 링크열어 보지 않은 링크에 대한 정보도 함께 복사하는 이유는 무엇인가요?

2. 개발자의 답변

2010년 1월 7일 버그 리포팅을 한 상태입니다.

3. 벌레의 발견

가. 벌레 확인을 하다가 알게 되었습니다.

ᄒᆞᆫ글 씨! 링크를 왜 엉뚱하게 표시하나요? 문서에 나타난 벌레를 확인 검증하면서 알게 되었습니다.

일단 새로운 파일을 만들기 위해 링크 테스트 2.hwp라는 다른 이름으로 저장하기를 했습니다. 그런데 그 보라돌이 링크도 함께 복사해 버렸습니다. 저는 당연히 보라돌이 링크는 복사하지 않을 줄 알았죠. 그때의 황당함이란….

나. 파일 내용의 정보인지 확인하기

그래도 이게 파일 형식에 포함된 정보라고 주장할 수도 있습니다. 예. 그 주장도 타당성이 있습니다. 하지만 실제로는 파일 형식의 정보가 아닌 파일의 내용임을 밝혀 보겠습니다.

이때 파일의 내용이라 함은 ᄒᆞᆫ글 편집 창에서 입력한 내용, 또는 그와 동격으로 처리되는 내용을 가리킵니다.

일단 파일을 불러와야겠죠.

그림 1 파일 불러오기.

위 그림에서 보면, 두 개의 하이퍼링크열어 본 링크로 표시되어 있습니다. 이때 저 링크를 일단 해제했다가 다시 설정해도 열어 본 링크로 나타날까요?

파일 형식에 포함된 정보라면 링크를 해제했다가 다시 설정해도 열어 본 링크로 나타나야 합니다. 그러나 파일의 내용이라면, 열어 보지 않은 링크로 나타나게 됩니다. 왜? 방금 설정한 링크는 아직 열어 보지 않은 링크라야 논리적으로 모순이 없기 때문입니다.

열어 본 링크가 있는 1줄 가운데쯤에서 하이퍼링크 단축키Ctrl+K,H(또는 하이퍼링크 고치기 단축키Ctrl+N,K)를 누릅니다.

● 참고 : 고치기 단축키보다는 하이퍼링크 단축키를 더 애용하는 편입니다. 어차피 하이퍼링크 위에서 하이퍼링크 단축키를 누르면 고치기 기능이 작동하기 때문입니다. 더구나 고치기 단축키가 하이퍼링크 고치기로 작동할 때는 약간의 버그가, 그것도 재현이 매우 힘든 버그가 있습니다.[각주:1] 그래서 하이퍼링크 고치기 기능은 쓰지 않고 있습니다.

아무튼 아래와 같이 하이퍼링크 화면이 나옵니다.

그림 2 하이퍼링크 고치기 화면

연결 대상 부분을 복사합니다. 복사할 때는 윈도의 복사 단축키 가운데 Shift+Insert가 듣지 않습니다. 그러므로 반드시 Ctrl+C 또는 마우스 오른쪽 메뉴를 이용해서 복사하기 바랍니다.

그림 3 일단 선택하고.

그림 4 복사를 합니다.

그림 5 복사한 뒤에는 왼쪽 아래에 있는 연결 안 함에 체크!

연결 안 함에 체크를 한 뒤에는 오른쪽 위에 있는 고치기 단추를 클릭! 이제 링크가 해제되었습니다.

그림 6 링크가 해제된 모습 (맨 윗줄)

링크가 해제되면 밑줄이 사라지고 글자색이 검은색으로 바뀝니다. 위 그림에서 없어도 이해하는 데 지장이 적은 아랫부분을 잘랐습니다. 앞으로는 대부분 위와 같이 자르겠습니다.

일단 위 그림에서 1줄을 선택하여 영역 설정합니다.

그림 7 1줄을 선택한 모습

하이퍼링크 단축키Ctrl+K,H로 하이퍼링크 대화상자를 열어서, 아까 복사한 주소를 붙여 넣습니다.

그림 8 연결 대상에 아까 복사한 주소를 붙여넣기 하고 넣기 단추를 클릭!

그림 9 1줄과 3줄이 서로 다른 모양을 나타내고 있다.

위 그림에서 확실 1줄과 3줄의 모습이 다릅니다. 앞서 전제했던 “파일의 내용이라면, 열어 보지 않은 링크로 나타나게 된다.”에 부합합니다.

4. 벌레의 원인

위에서 밝혔듯이 링크에 대한 정보, 열어 본 링크 또는 열어 보지 않은 링크 여부파일 내용으로 직접 저장하고 있기 때문에 발생한 문제로 여겨집니다.

이 문제는 비단 파일 저장(다른 이름으로 저장 포함)이나, 블로그로 올리기에만 한정된 벌레가 아닙니다. 파일의 내용을 입력하거나 편집하고, 또는 외부로 출력하는 모든 기능에서 이 벌레가 나타날 가능성이 있습니다.

참고로 이 기능 자체는 벌레가 아닙니다. 그러나 이 기능으로 색상이 바뀐 링크(열어 본 링크)를 포함한 문서를 다른 사람에게 주었다면? 그 사람에게도 그 링크가 열어 본 링크일까요? 그 사람에게는 열어 본 링크일 수도 있고, 열어 보지 않은 링크일 수도 있습니다. 그런데 항상 열어 본 링크로 보여주게 되면, 그 보여주는 순간 이 기능은 벌레가 됩니다.

참고로 클립보드에 복사하였을 때도 위의 상황과 같은 벌레가 나타나고 있음을 확인하였습니다.

5. 비슷한 벌레

[벌레와 팁/버그] - ᄒᆞᆫ글 씨! 링크를 왜 엉뚱하게 표시하나요?

6. 관련 문서

가. 내부 문서

[벌레와 팁/버그] - ᄒᆞᆫ글 씨! 맞춤법 도우미로 엉뚱한 곳을 표시하면 어떡해요?

[벌레와 팁/버그] - ᄒᆞᆫ글 씨! 링크를 왜 엉뚱하게 표시하나요?

[벌레와 팁/제안] - 한컴오피스 베타버전의 공백과 이동 기능

[벌레와 팁/버그] - ᄒᆞᆫ글 씨! 블로그에는 글을 하나만 올리란 말입니다.

[벌레와 팁/버그] - ᄒᆞᆫ글 씨! ‘ᄒᆞᆫ글’을 제대로 나타내면 안 되겠니? 2

[벌레와 팁/버그] - ᄒᆞᆫ글 씨! ‘ᄒᆞᆫ글’을 제대로 나타내면 안 되겠니?

[벌레와 팁/버그] - ᄒᆞᆫ글 씨! 블로그 카테고리는 어디에?

[벌레와 팁/버그] - ᄒᆞᆫ글 씨! 블로그에는 게시판이 없거든요.

[벌레와 팁/버그] - HTML 태그 해석 오류 문제

[벌레와 팁/버그] - 도대체 무슨 짓을 하는 거냐, ᄒᆞᆫ글?

[프로그램/스크린샷] - 한컴오피스2010 베타버전 실행화면

[벌레와 팁/버그] - 한컴오피스2010 베타 설치 작업과 버그 몇 개

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

나. 외부 문서 - 테스트 블로그

이 글은 ᄒᆞᆫ글 2010 베타버전에서 작성하였습니다.

  1. ᄒᆞᆫ글2004 때부터 생겨난 벌레인데, 이 하이퍼링크 고치기 벌레는 잊을 만하면 나타나서 사람 미치게 만듭니다. 재현이 쉬웠다면 벌써 제 블로그에 버그 리포팅이 되었을 겁니다. [본문으로]
글쓴이는 koc/SALM입니다.
본문에 저작권에 대한 사항이 나타나지 않거나, 저작권이 BY-SA로 표기되어 있다면,
이 글은 GFDL로 공개한 글입니다.

한컴오피스 베타버전 버그 9 - ᄒᆞᆫ글과 블로그 6 : ᄒᆞᆫ글 씨! 링크를 왜 엉뚱하게 표시하나요?

블로그로 올리기 기능을 사용하여 블로그에 글을 올리면 링크를 엉뚱하게 나타내는 현상을 발견하였습니다. 확인 결과 다른 이름으로 저장하기 > 인터넷 문서에서도 똑같은 현상이 일어났습니다. 링크에 글자 속성을 걸어서 블로그에 올리면 어쩌라는 말인지 도통 알 수가 없습니다.

1. 벌레의 유형

이보세요, ᄒᆞᆫ글 씨! 열어 본 링크의 색상을 span 태그를 써서 문서에 집어 넣으면 날더러 어쩌란 말입니까? 거기는 색상을 넣으면 안 된단 말입니다.

2. 개발자의 답변

2010년 1월 6일 버그 리포팅을 한 상태입니다.

3. 벌레의 발견

가. 어느 날 갑자기 깨달았습니다.

블로그 문서의 링크 색상이 이상하다는 점을 어느 날 갑자기 깨달았습니다. 처음에는 약간 특이한 것이라고 여겼을 뿐 벌레라고는 생각지 못했습니다.

일단 이 벌레에 대해 알려면 환경 설정을 살펴봐야 합니다.

위 그림에서 열어 본 링크(보라돌이 링크)와 열어 보지 않은 링크(푸르딩딩 링크)의 글자 색을 잘 살펴보시기 바랍니다.

일단 링크 테스트 문서를 보겠습니다.

좀 흐리게 보이지만 보는 데는 지장이 없습니다. 일단 보라돌이 링크는 3개이고, 푸르딩딩 링크는 7개입니다.

다른 이름으로 저장하기 > 인터넷 문서로 저장하고, IE 6으로 열어 보았습니다.

색상이 위 환경 설정에 나타난 그 색깔입니다. 지금까지 이 색상에 대해 전혀 신경 쓰지 않았습니다. 그도 그럴 것이 이 색상은 인터넷 링크의 기본 색상이기 때문입니다. 그래서 그냥 저 그림에서 서로 다르게 나타나는 색상도 이미 한 번 방문한 웹문서이기 때문에 나타나는 현상이라고 생각해 버렸습니다.

아무튼 별 의심 없이 블로그로 올리기 기능을 이용해서 올리려다가 무언가 꺼림칙함을 느꼈습니다. 바로 저 링크의 밑줄이 문제였습니다. 그래서 부랴부랴 시험용 블로그를 하나 개설하고,  그곳에 글을 올렸습니다.

주황색 링크 사이에 보이는 보라돌이 링크! 그렇습니다. ᄒᆞᆫ글2010 베타버전은 저 링크에서 글자색을 넣어서 블로그에 올려버리는 짓을 해 버렸습니다.

혹시 같은 컴퓨터이기에 나타나는 현상인가 싶어 다른 컴퓨터에서 시험했습니다.

인터넷 익스플로러 8에서도 위와 같이 주황색 링크보라돌이 링크를 보여주고 있습니다.

그런데 벌레는 벌레고, 함초롱돋움 글꼴이 웹페이지에서 상당히 예쁘게 보입니다. 그러나 옛한글은 여지없이 뭉개지고 있습니다.

나. 두 번째 테스트

혹시나 이건 내가 실수로 색상을 넣은 것일 수도 있다는 생각이 들었습니다. 그래서 링크 두어 개를 더 클릭한 뒤 살펴보았습니다.

일단 위와 같이 보라돌이 링크도 5개, 푸르딩딩 링크도 5개가 되게 만들었습니다. HTML 문서로 저장하고, 블로그에도 올렸습니다.


블로그로 올리기 작업에서 처음으로 본, 비지 않은 게시물 위치

위 그림은 블로그로 올리기 작업에서 비어 있지 않은 게시물 위치를 처음으로 본 기념으로 잡은 화면입니다. 지금까지 버그 화면만 보다가 버그가 아닌 화면을 보니 되게 신기했습니다.

IE 6에서는 보는 HTML 문서를 그저 그러네요. 아무튼 보라돌이 링크 5개, 푸르딩딩 링크 5개입니다.

제발 아니기를 빌었는데…. 주황색 링크 5개에 보라돌이 링크 5개입니다.

파이어폭스에 이어 IE 8도 역시 같은 결과를 나타냈습니다.

4. 벌레의 원인

원인 분석을 하는 과정에서 혹시나 하는 마음에 이름을 다르게 저장한 HTML 파일을 살펴보게 되었습니다. 그리고 블로그에 올린 내용을 메모장에 복사하여 하드디스크에 저장하였습니다. 물론 이름은 다릅니다.

위 리스트에서 링크 테스트.htm 파일링크 테스트-1.htm 파일다른 이름으로 저장하기 > 인터넷 문서로 만든 파일입니다. 보다시피 내용은 전혀 바뀌지 않았는데 단지 클릭을 두 번 했다는 이유로 파일 내용이 바뀌어 있습니다. 그리고 링크 테스트-blog-3.htm 파일링크 테스트-blog-4.htm 파일은 블로그 내용을 HTML 편집 모드에서 클립보드로 복사한 뒤 하드디스크에 저장한 것입니다. 이것 역시 내용이 조금 달라져 있습니다. 이것이 블로그에 나타나는 결과에 영향을 주고 있지 않나 생각합니다.

그런데 현재 위의 상황으로 볼 때 하이퍼링크의 접근 기록이 문서 내용의 일부로서 문서 안에 기록되어 있음을 알 수 있습니다. 여기에서 주목할 점이 있습니다. 바로 왜 웹사이트 방문 기록을 HWP 문서의 내부에 따로 영역을 두어 HWP 구조의 일부로서 저장하지 않고 바로 문서의 내용의 일부로서 저장하고 있느냐는 점입니다. 다시 말해 하이퍼링크의 접근 기록 또는 방문 기록은 어디까지나 기록으로서 남아야지, 그것이 문서 내용의 일부가 되어서는 곤란하다는 말입니다. 위에서 보인 오류도 그러한 맥락에서 볼 수 있다고 생각합니다.

5. 비슷한 벌레

[벌레와 팁/버그] - 아크로에디트 : 문법 강조에서 문법 이름 표기 문제

[벌레와 팁/버그] - 티스토리에서 주석이 제대로 인식되지 않는 현상

[벌레와 팁/버그] - 티스토리 주석에서 \ 문자 표기 문제

6. 관련 문서

가. 내부 문서

[벌레와 팁/제안] - 한컴오피스 베타버전의 공백과 이동 기능

[벌레와 팁/버그] - ᄒᆞᆫ글 씨! 블로그에는 글을 하나만 올리란 말입니다.

[벌레와 팁/버그] - ᄒᆞᆫ글 씨! ‘ᄒᆞᆫ글’을 제대로 나타내면 안 되겠니? 2

[벌레와 팁/버그] - ᄒᆞᆫ글 씨! ‘ᄒᆞᆫ글’을 제대로 나타내면 안 되겠니?

[벌레와 팁/버그] - ᄒᆞᆫ글 씨! 블로그 카테고리는 어디에?

[벌레와 팁/버그] - ᄒᆞᆫ글 씨! 블로그에는 게시판이 없거든요.

[벌레와 팁/버그] - HTML 태그 해석 오류 문제

[벌레와 팁/버그] - 도대체 무슨 짓을 하는 거냐, ᄒᆞᆫ글?

[프로그램/스크린샷] - 한컴오피스2010 베타버전 실행화면

[벌레와 팁/버그] - 한컴오피스2010 베타 설치 작업과 버그 몇 개

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

나. 외부 문서 - 테스트 블로그

[테스트] - 링크 테스트 문서 - 4

[테스트] - 링크 테스트 문서 - 3

이 글은 ᄒᆞᆫ글 2010 베타버전에서 작성하였습니다.

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

스프링노트를 사용하면서 여러 벌레를 발견했지만, 재현에 성공한 것은 거의 없다. 그러다가 바로 어제(2009년 4월 24일) 2개나 재현에 성공했다. 바로 스프링노트의 태그 표기 벌레와 지금 소개하는 링크 편집 벌레이다.

벌레의 유형

  • 수작업으로 만든 링크와 외부에서 복사하여 붙인 링크를 차별하는 벌레이다. 복사하여 붙인 링크를 편집하면 그것의 주소를 마음대로 바꾸어 버리는 벌레이다.

직접 만든 링크와 복사해 붙여넣은 링크가 다르게 해석되는 이유를 알 수 없다. 또한 어떤 경우에는 직접 만든 링크와 동등하게 취급하고, 어떤 경우에는 다르게 취급한다. 직접 만든 링크와 동등하게 처리하는 경우는 스프링노트에서 내 블로그로 발행한 문서에 포함된 링크가 대부분이었다. 그밖에 다른 웹페이지의 링크를 붙여 넣은 경우에는 모두 링크 주소를 바꾸어 버렸다.

벌레의 발견

벌레의 발견이라고 할 수도 있고, 링크의 비교라고 할 수 있는 작업이다. 

스프링노트의 링크 만들기 기능을 이용하여 만든 링크

가장 먼저 스프링노트의 링크를 HTML 코드로 살펴보자. 모질라 파이어폭스에는 선택한 소스 보기라는 기능을 제공하고 있다. 그것을 이용하면 링크 부분의 HTML 소스만 떼어 살펴볼 수 있다.

마우스 오른쪽 단추를 눌러 팝업 메뉴를 부른 화면

마우스 오른쪽 단추를 눌러 팝업 메뉴를 부른 화면

위의 작업을 통해 보게된 선택한 영역의 HTML 소스

위의 작업을 통해 보게된 선택한 영역의 HTML 소스

  1. <a href="http://salm.pe.kr/entry/Springnote-Tag-Bug" class="external newWindow" title="http://salm.pe.kr/entry/Springnote-Tag-Bug">스프링노트의 태그 표기 벌레</a>

스프링노트의 링크 만들기 기능을 이용하여 링크를 만들게 되면 위와 같이 class="external newWindow" 라는 클래스 선택자를 추가하게 된다.

다음과 같이 링크를 수정하면 링크 대상이 현재 링크된 곳을 가리키게 된다.

 

링크 수정/삭제를 선택하는 팝업

링크 수정/삭제를 선택하는 팝업


링크 수정/삭제 팝업에서 수정을 선택한 화면

링크 수정/삭제 팝업에서 수정을 선택한 화면

스프링노트의 링크 만들기 기능을 이용해서 만든 링크는 링크를 고칠 때 위와 같이 원래 주소, 곧 링크 대상을 유지해 준다.

스프링노트의 링크 만들기 기능을 이용하지 않은 링크

스프링노트의 링크 만들기 기능을 이용하지 않은 링크는 class="external newWindow" 라는 클래스 선택자를 가지지 않은 링크를 말한다.

도아의 세상사는 이야기의 게시글에서 링크 하나를 복사했다. 그런데 그것이 블로그 기사 제목이라서 아래와 같이 나타났다.

좌우 폭이 좁은 까닭은 화면 크기가 800×600px이기 때문이다.

좌우 폭이 좁은 까닭은 화면 크기가 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일 현재 오류를 보고한 상태이며, 수정하겠다는 답변을 받았다.

관련 문서 및 페이지

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


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

들어가며#

링크에 대해 많은 이들이 잘못된 상식을 가지고 있는 경우가 있어서 이 글을 쓰게 되었다.

우선 권리 관계만을 말한다면, 인터넷 HTML 및 XHTML 등에서 링크 자체는 링크 거는 사람의 권리이지만, 그에 앞서 게시물 게시자 및 저작권자의 허가를 얻어야 한다. 그러나 그 허가가 명시적일 필요는 없으며, 그러한 허가가 없더라도 금지하지 않으면 허가한 것으로 봅니다. 이것은 아주 중요합니다.

마크업 언어와 링크#

마크업 언어는 문서와 문서 사이의 연결을 링크로써 하고 있습니다. 다시 말해 링크가 없다면 마크업 언어로 작성된 문서끼리 연결할 수 있는 방법이 없습니다. HTML 등의 마크업 언어는 SGML로부터 나왔으며, 그 형제자매들은 모두 링크로써 서로와 연결되어 있습니다.[각주:1]

링크는 하이퍼텍스트로 이어진 관련 정보의 실체입니다. 이때 하이퍼텍스트는 사용자가 선택하는 쪽으로 접근할 수 있도록 조직화된 정보를 가리킵니다. 이때의 링크를 정확히 말하자면, 하이퍼링크가 됩니다.

하이퍼링크는 일반적으로 A 태그로서 나타냅니다. 그러나 링크는 하이퍼링크뿐만 아니라 IMG 태그나 EMBED 태그 등으로 외부 사이트에서 불러온 경우도 링크로 표현합니다. "의미의 확장"인 셈이죠.

링크 문제의 발생#

HTML이 생겨난 초기에는 이 링크가 문서 자체를 인용하는 것이 아니었기 때문에 거의 무제한으로 허용되었습니다. 여기에는 문서의 양이 많지 않은 것도 한 원인이 있었습니다.

그러다가 과도한 링크에 따른 웹서버의 과부하 등의 문제가 발생합니다. 또한 인터넷 광고를 통한 수익 모델에서 단순히 특정 사이트로의 링크만 제공하고 광고 수익을 올리는 웹페이지도 등장하죠. 인터넷 광고는 클릭을 해야 수익이 생기는 경우와 단순히 사용자에게 보여주기만 해도 수익을 얻는 경우가 있습니다. 이때 후자의 경우는 단순히 링크만 게시하고도 수익을 올린다는 점에서는 "무임승차"라는 비난을 받기도 합니다. 아무튼 이런 이유 등으로 하이퍼링크에 대한 법적 성격을 논의하게 됩니다.

또한 음원 등의 사용에서 다른 웹페이지의 음원이나 이미지(흔히 미디어)를 링크만으로 불러와서 사용했을 때에도 문제가 생깁니다. 자신이 그 음원이나 이미지에 대해 사용권을 가지고 있다면 문제가 없습니다만, 이렇게 불러오는 미디어의 경우 사용권을 가지고 있는 경우는 드뭅니다. 다시 말해 상대방 사이트의 음원을 허락 없이 쓰는 행위이며, 아울러 상대방 사이트의 전송량을 깎아먹는 행위입니다.

그렇게 차츰차츰 링크를 거는 쪽과 게시물을 게시한 사람(게시자) 사이에 불편한 문제가 하나씩 생겨나기 시작합니다.

링크와 권리#

과연 누구에게 권리가 있는지는 지금까지도 명확히 답하지 못하고 있습니다. 이는 어느 한쪽의 의견을 손들어줄 수 없는 아주 심각한 상황이 숨어있기 때문입니다.

링크하는 사람의 권리#

우선 링크하는 사람과 그의 권리에 대해서 생각해 봅시다. 링크하는 사람은 기본적으로 그 정보가 유용하다고 생각했기 때문에 링크를 하게 됩니다.

왜 함부러 링크하느냐?

그래서 링크하는 사람들은 저 질문에 대해 아주 화를 냅니다.

그 글을 널리 알려주었는데 무슨 소리냐?

링크하는 사람의 입장에서는 아주 당연한 답변입니다.

예! 그것을 부정할 수는 없습니다. 일단 웹페이지가 인터넷에 공개된 이상 (게시물이 게시된 이후에) 링크를 금지할 수는 없다는 것이 학계의 중론이기 때문입니다. 저 역시 그 의견에 찬성합니다. 따라서 링크하는 사람들의 말은 일반적으로 옳습니다.

하지만 상업적 목적으로 이용하려고 링크를 거는 것도 허용될까요? 앞서 말했듯이 단순히 광고 수익만을 목적으로 아무런 내용도 없이 링크만 게시했다면 그것은 정당할까요? 사람들이 인터넷에 공개하는 정보는 대부분 순수한 마음에서입니다. 그에 따라 자신의 글이 상업적 목적으로 쓰이기를 바라지는 않지요.[각주:2] 따라서 단순히 링크만 모은 뒤 광고 수익을 위해 광고를 게재하는 행위 등은 지양해야 하며[각주:3], 아예 상업적 사이트에서 해당 문서를 링크하는 행위는 금지한다고 보고 있습니다.[각주:4]

그런데 링크하려는 글에 링크 방법이나 링크 금지 등에서 적힌 내용이 있다면 링크하는 사람의 권리는 어떻게 될까요? 당연히 제한됩니다. 그러한 링크 방법 및 링크 금지 안내문에 따라야만 합니다. 설령 아무 이유 없이 링크를 금지했더라도 그에 대해 항의할 수 없습니다. 이 권리는 절대적입니다. 다만 이 경우에도 검색엔진의 봇(서치봇)의 접근까지 막았는지는 논의가 필요합니다. 왜냐하면 검색엔진의 봇을 막는 robots.txt 규약이 존재하기 때문입니다.

예컨대 이런 경우가 있습니다. 지난 달(2009년 3월)에 프로그램 하나를 공짜로 얻게 되었습니다. 그 사이트 제목은 "FREE IObit Advanced SystemCare PRO v3 License Key Codes Exclusive for Raymond.CC Readers"입니다. 그런데 그 문서 아래쪽에 이런 말이 있습니다.

저것을 해석하면 "당신의 사이트에서 이 게시글(article)을 복사하는 행위는 엄밀히 허용하지 않습니다. 그러나, 당신이 이 게시글을 좋아한다면, 당신은 아래에 있는 HTML 코드를 이용하여 이 게시글에 직접 링크할 수 있습니다."라는 뜻입니다. 다시 말해 링크하는 방법을 알려주고 있습니다. 이럴 경우에는 반드시 저 HTML 코드를 이용하여 링크해야 합니다.

마찬가지로 누군가가 자신의 웹페이지에 "링크를 금지합니다."라는 말을 했다면 그에 따라 링크를 하지 말아야 합니다.

아무튼 링크라는 행위, 곧 링크하기는 링크하는 사람의 권리입니다. 그러나 게시자가 그에 대해서 미리 공개적으로 제한할 수 있습니다. 그러나 그렇게 제한하는 내용이 공개되어 있지 않다면 게시자의 링크 금지의 의사는 무시되며, 링크하는 사람의 권리는 온전히 보존됩니다.

게시자 및 저작권자의 권리#

앞서 말했듯이 HTML이 처음 쓰이던 때에는 대부분 링크가 허용되었습니다. 그러나 이런저런 문제가 생기면서 링크를 제한해야 한다는 목소리가 조금씩 커지게 됩니다. 그런데 이미 공개된 웹에서 링크를 왜 금지해야 하는지 그 근거를 밝힐 필요가 생겨납니다.

흔히 링크하는 권리를 "읽을 권리"에 비유하고, 링크 허용의 권리를 "쓸 권리"에 비유합니다. 다시 말해 링크하는 행위는 일단 게시물이 있고 나서 존재한다는 뜻입니다. 이것은 읽은 권리는 누군가가 글로 쓴 것이 있어야 존재하는 것과 마찬가지이죠.

내가 쓴 글은 내가 지배한다.#

아주 단순하지만 명확한 사상입니다. 이것이 성립하지 않는다면 저작권은 존재 의의가 사라집니다. 또한 여기에서 링크 허용이 링크하기보다 우월한 권리라는 점이 두드러지게 됩니다. 다시 말해 저작자가 자신의 글을 지배, 곧 관리, 이용, 수익하고 싶다는데, 그것을 막을 수는 없습니다. 그것을 막게 되면, 앞서 말했듯이, 저작권의 존재 의의가 없거든요.

그런데 링크를 입소문으로 여기는 사람들은 그러한 저작자의 주장에 반발하게 됩니다.

우리가 링크라는 수단으로 당신 글을 소문내 주었잖아. 그런데 링크 좀 했다고 화내다니! 너무 하잖아.

그러나 링크와 입소문은 다릅니다. 입소문은 한 번으로 끝나지만, 링크는 웹페이지가 사라지지 않는 한 계속되거든요. 바로 이 점이 링크에 대한 법적인 관점을 복잡하게 만듭니다.

쓸 권리와 읽을 권리#

글을 쓸 권리는 누구나 가지고 있습니다. 읽을 권리도 누구나 가지고 있지만, 읽을 대상이 존재하지 않는데 읽을 권리가 있다고 말하기는 힘듭니다.

우리가 흔히 글 쓰는 사람에게 "그것도 글이냐?"라는 식으로 매도하는 데에는 글 쓸 권리가 읽을 권리보다 우월하다고 여기기 때문이라고 해석할 수도 있습니다. 더 많은 권리, 더 우월한 권리를 가졌기 때문에 그에 대해 더 많은 의무(여기에서는 "좋은 글을 쓸 의무")를 강요한다고 생각할 수 있다는 뜻입니다.

반면에 글쓴이의 입장에서도 읽는 사람을 무시할 수는 없습니다. 대부분의 글이 읽는 사람이 있기 때문에 쓰인다는 사실을 무시할 수는 없기 때문입니다. 

그런데 그 둘을 들여다보면 어느 쪽이 우월하냐, 어느 쪽이 더 많은 권리이냐 하는 점은 알기 힘듭니다. 다만 읽을 권리를 위해서는 읽을 대상이 필요하다는 점만이 두드러질 뿐이죠.

나는 내 사이트가 폭주하기를 바라지 않아요.#

게시자 및 사이트 관리자의 입장에서는 과도한 링크는 절대 반갑지 않습니다. 아무리 게시글이 인기가 좋아도 그것 때문에 사이트 자체가 멈춘다면 손해입니다. 특히나 설치형 블로그 등에서는 사이트 유지비 또는 회선 유지비 등은 공짜가 아니기 때문입니다. 심지어 과도한 링크는 DoS 공격 등으로 오인되기도 합니다.

정말로 링크하기가 링크하는 사람의 권리라면, 그들의 그 권리를 이용하여 "자신이 좋아하는 글"이 게시된 사이트에 "DoS 공격"을 해 버린 셈입니다. 그렇게 남의 사이트를 죽여 놓은 뒤에 그들은 당당히 말하겠죠.

내가 당신 게시글을 널리 광고해 줬어. 고마워 해야 돼.

링크하는 사람과 게시자의 입장은 완전히 엇갈리게 됩니다. 위와 같은 경우 게시자는 링크 해 줘서 고맙다는 생각은 전혀 가지지 않게 됩니다. 오히려 그러한 과도한 링크하기는 사이트에 대한 위해 행위이기 때문입니다.

아무튼 이런 경우에는 우리는 "권리의 남용"이라고 부른답니다.

이미 게시된 글의 링크를 막겠다고?#

아무리 게시자나 저작권자 등의 권리가 크다지만, 이미 게시한 글의 링크를 막을 수는 없습니다. 그러나 게시에 앞서 또는 게시와 동시에 링크 규칙 등을 명시할 수는 있습니다.

월드와이드웹(WWW)은 공개된 공간입니다. 물론 일부 단절된 공간도 있습니다만, 그것은 일부이며 대부분 공개되어 있습니다. 이때 공개된 게시글을 복사하는 행위가 아닌 단순 링크를 막을 수 있느냐에 대해 논란이 생길 수 있습니다. 과거에 DCMA(디지털 밀레니엄 저작권법) 초안에서는 문서에 대한 링크도 저작권 위반으로 보는 시각이 있었습니다. 현재는 링크는 저작권 위반이 아니라고 하고 있지요. 이렇듯이 링크까지 저작권 위반으로 보는 시각도 존재합니다. 지금은 대부분 단순 링크는 저작권 위반이 아니라고 여기고 있습니다.

또한 링크를 사후에 막을 수 없다고 하는 다른 이유는, 웹이 인류공동의 문화적 발전에 이바지하고 있다는 데에 있습니다. 다시 말해 웹이 그러한 공공의 이익을 위해 존재하고, 링크는 그 수단 가운데 하나로서 여겨집니다. 그러므로 더 큰 공공의 이익을 위해서 게시자 및 저작권자의 링크 허용의 권리는 제한될 수 있다고 여겨집니다. 다른 측면에서 이미 게시된 글조차 사후에 링크를 금지한다면 링크한 사람은 사후에 자기도 모르는 사이에 다른 사람의 권리를 침해하도록 만듭니다. 이는 웹이 공개되어 있다는 점과 배치되며, 차라리 웹이 단절된 공간인 것보다 못한 상황이 됩니다. 이런 점 때문에 사후에 링크를 제한하는 행위는 정당하지 못하다고 여기고 있습니다.

그러나 링크에 대한 제목이 바뀐다면 문제가 달라집니다. 일부 포털 사이트에서 기사 제목과는 달리 선정적인 제목으로 바꾸는 경우가 있습니다. 이는 엄밀히 말해 저작권 또는 저작인격권 위반입니다. 저작권자의 의사에 반하여 오로지 해당 기사로의 유인만을 위해서 기사 제목을 임의로 바꾸었기 때문이죠. 물론 이때에 고의성 등을 증명하기는 매우 어렵기 때문 법정 다툼 결과는 알 수 없으나, 적어도 도의적인 비난은 면키 어렵습니다. 이럴 경우 법적인 문제를 떠나서 사후에라도 링크를 제한할 수 있습니다. 저쪽에서 공정하지 않았는데, 이쪽에서 그것을 묵과해야 할 이유가 없기 때문입니다.

한편 사이트 정책에서 메인 페이지로만 링크를 허용하는 경우가 있습니다. 이럴 경우 대부분 사이트 관리자 및 게시자의 권리로서 인정됩니다. 여기에는 사이트 관리의 측면에서 메인 페이지를 반드시 방문케 하려는 의도가 있습니다. 또한 하위 페이지가 프레임 등으로 링크된 경우에는 하위 페이지로의 링크는 방문자에게 보이게 되는 웹페이지의 외양에도 영향을 줄 수 있습니다. 그밖에 여러 이유로 사이트 정책으로 링크하는 방법이나 링크하는 페이지 등을 제한할 수 있습니다.

하지만 그것이 너무 비합리적이어서는 안 됩니다. 예컨대 언론사 사이트를 메인 페이지로만 링크해야 한다면 링크가 링크로서 있을 가치가 현저히 떨어지게 됩니다. 앞서 말한 바와 같이 링크는 하이퍼텍스트로 이어진 관련 정보의 실체이며, 이때 하이퍼텍스트는 사용자가 선택하는 쪽으로 접근할 수 있도록 조직화된 정보입니다. 그런데 언론사의 경우 메인 페이지는 "오늘"의 뉴스가 나올지언정 특정일의 뉴스가 나오지는 않습니다. 이럴 경우 조직화된 정보로서의 하이퍼텍스트 및 그 실체인 링크는 그 가치가 크게 깎이게 됨은 두말할 나위가 없습니다.

더구나 언론사로의 링크는 글의 논거로서 쓰이는 때가 많은데, 메인 페이지로의 링크만 허용한다면 언론사 스스로가 자신들의 기사에 대한 쓰임을 제한하는 결과를 가져옵니다. 이는 또한 언론사는 공공성을 가진다고 하더라도 이익을 위해 운영되는 회사인데, 언론사의 이익은 기사가 얼마나 영향력을 끼치느냐에 따라 크게 좌우될 수 있습니다. 따라서 언론사 입장에서도 메인 페이지로의 링크만 허용하는 정책은 합리적이지 못하다고 하겠습니다.

내 사이트를 오인케 하지 말라!#

간혹 엉뚱한 제목으로 링크를 거는 경우가 있습니다. 보통은 조금 달라도 그냥 넘어갑니다. 하지만 아주 엉뚱한 경우는 문제가 될 수 있습니다. 앞서 말했듯이 명백히 고의를 입증하기 어렵기 때문에 소송으로까지 번지지 않을 뿐이지 이러한 행위는 불법입니다.

예전에 어떤 사람이 자신의 사이트에 폐쇄 공간을 만든 뒤 회원 가입을 받아 야한 동영상을 회원에게 보여주었습니다. 여기까지는 자신들만의 공간이니 문제가 없었는데, 링크 가운데 하나에서 문제가 생겼습니다. 그 사람은 장난이 심했는지, 방문자의 연령을 묻고 해당 연령보다 작으면 "어떤 사이트"로 이동하게 만들었습니다. 그런데 그렇게 이동해간 "어떤 사이트"를 방문자가 오인했다고 합니다. 그 방문자가 보게 된 "어떤 사이트"는 월트 디즈니 사의 웹사이트였고, 그 방문자는 "아동 포르노 사이트"로 오인했다고 합니다. 보통의 경우는 거의 일어나지 않을 일이지만, 일단 발생한 일이기 때문에 월트 디즈니 측에서는 그 링크의 제거를 요구했고, 그 장난 심한 사람은 그것을 거부했죠.

이것은 그저 장난이다.

하지만 회사 입장에서는 단순한 장난으로 받아들일 수 없는 상황입니다. 왜냐고요? 이미 오인한 사람이 생겼으니까요. 결국 법정에서 판결이 났고, 고의 여부에 관계없이 해당 링크는 제거해야 했습니다.

이처럼 링크를 이용하여 오인케 하는 링크 걸기는 명예훼손이나 사생활침해 등의 문제를 발생시킬 수 있고, 심지어 회사의 이미지에 영향을 줄 수도 있습니다. 그러므로 상대방에게 손해가 될 수 있는 링크는 자제해야 합니다.

링크와 검색엔진#

검색엔진도 링크를 이용하여 검색결과를 표현합니다. 이 경우에는 원천적으로 검색결과에서 자신의 사이트를 제거할 수 있습니다. 바로 robots.txt 규약을 이용하면 됩니다.

그리고 링크와 관련하여 유료 검색엔진과 무료 검색엔진은 다른 지위를 갖습니다. 유료 검색엔진은 처음부터 돈을 내고 검색결과 또는 검색 서비스를 사는 것입니다. 이럴 경우 유료 검색엔진은 상업용 사이트로서 지위를 갖게 되며, 대부분의 사람이 상업용 사이트로의 링크를 바라지 않는다는 점에서 문제가 됩니다. 반면에 구글이나 야후 등의 무료 검색엔진은 기본적으로 무료이기 때문에 상업용 사이트로서 지위를 갖지는 않습니다. 이것은 앞서 말한 웹의 기능과 관련이 있는데, 웹이 인류공동의 문화발전에 기여하고 있다는 공공이익의 측면을 중시하기 때문입니다. 달리 말하자면 유료 검색엔진은 자사의 이익을 위해 처음부터 돈을 받고 검색 결과를 판매 또는 서비스했다고 보지만, 무료 검색엔진은 원칙적으로 무료로 정보를 제공하고 웹페이지 일부에 광고 스폰서 링크를 제공할 뿐이라고 해석됩니다.

링크와 광고 및 대행사이트#

구글 애드센스나 다음 애드클릭스 등의 광고대행사이트에서 광고를 받아 자신의 사이트에 게재했다면, 자신의 사이트도 상업용 사이트이냐는 물음이 생길 수 있다. 하지만 이럴 경우 상업용 사이트로 분류되지는 않는다. 앞서 말한 무료 검색엔진의 경우와 마찬가지이기 때문이다.

물론 어느 경우에나 과도하면 안 됩니다. 예컨대 다른 사이트로의 링크 몇 개 걸고 나머지는 모조리 광고로 채웠다면 어떨까요? 그럴 경우에도 면책된다고 생각한다면 오산이다. 특히 거의 대부분의 페이지가 그런 식의 링크 몇 개 걸고 나머지 부분에 광고로 도배하다시피 했다면, 그러한 링크는 링크된 글의 게시자 또는 저작권자를 우롱하는 행위라고 보아야 합니다.

그러나 그런 경우에도 광고대행사이트인 구글 애드센스나 다음 애드클릭스 등이 책임을 지지는 않는다. 다만 구글의 경우 남의 글에 구글 애드센스 광고를 게시하는 행위를 금지하고 있고, 링크로만 이루어진 사이트 구성을 제한하고 있기는 합니다.

기타#

  • 링크걸기가 링크를 거는 사람의 권리이고, 게시자 및 저작권자가 그것에 관여할 수 없다면 어떻게 될까? 이것은 게시자와 저작권자의 권리가 없다고 본다는 견해이다. 이 견해는 보통 사람이 가지고 있는 일반적인 견해[각주:5]이지만, 중대한 오류가 있다. 이 견해가 옳다면 검색엔진의 데이터베이스에서 자신의 사이트를 제거해 달라는 요구를 할 수가 없게 된다. 왜냐하면, 이 견해에 따르면, 링크 걸기는 링크 거는 사람의 권리이고, 이것에 대해서 게시자나 저작권자는 아무런 권리도 권한도 없기 때문이다. 그러나 실제로는 그와 반대이다. 게시자는 언제든지 검색엔진 회사 측에 데이터베이스에서 자신의 사이트를 제거해 달라고 요청할 수 있다.
  • 링크를 이용해 예쁜 여성의 사진을 링크하여 순위를 매겼다면 그것은 적법할까? 그렇지는 않다. 이 경우 링크된 사진에 나타난 여성들의 사생활 침해 문제가 생긴다. 마찬가지로 남의 집 사진을 모아놓고 순위를 매기거나, 남의 튜닝카 사진을 모아놓고 순위를 매기는 등의 행위는 조심해야 한다. 실수로 실명 등을 거론할 경우 바로 사생활 침해 등의 문제로부터 자유로울 수 없게 된다.
  • 어떤 남성 우월주의자가 여권 운동가의 홈페이지를 링크하여 남성 우월주의자들이 몰려들어 악플을 달게 했다면? 이럴 경우 악의가 없더라도 여권 운동가가 요구하면 해당 링크를 제거해야 한다. 현재 한국에서는 악플도 범죄로 인식되고 있기 때문에 악플을 불러올 수 있는 링크의 제거 요청은 사이트 관리자 또는 홈페이지 운영자로서 기본적인 권리이다.[각주:6] 물론 단순히 그러한 "우려"만으로 요청할 수는 없고, 과거의 비슷한 사례를 제시해야 한다.
  • 어떤 개인 홈페이지의 글을 복사해서 자신의 홈페이지에 실었다. 하지만 그래픽 이미지나 동영상 등은 원본 사이트로 연결되도록 하였다. 이 경우 그러한 링크는 합법일까? 이럴 경우 절대 합법이 아닙니다. 애초에 복사 금지(불펌 금지)라면 당연히 위법이고[각주:7], 복사 허용이더라도 그러한 복사를 함으로써 원본 사이트에 손해를 끼치게 되면 불법입니다. 특히 복사한 글이 아주 인기가 좋은 글이었다면, 그와 동시에 원본이 있는 개인 홈페이지가 설치형이었다면, 위에서 말한 DoS 공격으로 오인될 수도 있습니다. 왜냐하면 그래픽 이미지나 동영상은 텍스트에 비해 매우 용량이 큰데, 이러한 미디어를 지속적으로 전송 요청하게 되면 상대방 서버에서는 일일전송량을 초과하는 사태가 벌어지고, 일시적으로 일일전송량 한계를 늘리더라도 과도한 요청이 발생하게 됩니다. 이럴 경우 대부분의 서버는 그러한 과도한 요청을 DoS 공격으로 보고 접속을 차단하게 됩니다. 이것은 프로그램 오류가 아니라, 사이트 보호를 위한 최소한의 장치이다.

결론#

링크 걸기는 링크를 거는 사람이 가진 권리입니다. 그러나 링크를 걸 때에는 반드시 링크 제한 및 금지에 대한 규정이 없는 사이트 또는 링크를 허용하는 사이트에 걸어야 합니다. 링크를 금지하는 사이트에 링크한 뒤에 발생하는 모든 분쟁 및 손해는 링크한 사람이 져야 합니다. 그에 대해 째째하다느니, 겨우 그것 가지고 심하게 군다느니 하는 투정은 부리지 말기 바랍니다.

아울러 자신의 사이트에 링크를 걸게 만들거나 막으려면 그러한 링크 규정을 페이지마다 게시하기 바랍니다. 아니면 사이트 정책 페이지로 통하는 링크를 마련해 두어야 합니다. 공개된 자신의 웹페이지에 링크한 뒤에야 링크를 막겠다고 하면 아무도 수긍하지 않습니다. 그럴 경우에 링크를 금지하거나 제한하려면 홈페이지를 전면 개편하여 다시 만드는 수밖에 없습니다.

요약하면 링크는 금지 또는 제한한다고 명시하지 않으면 기본적으로 허용합니다. 또한 사전에 미리 명시적으로 제한 또는 금지하는 않는 한 사후에 제한을 두는 일은 하지 말아야 합니다.

관련 문서#

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

  1. 마크업 언어는 SGML 계열과 TeX 계열로 나뉩니다. [본문으로]
  2. 물론 글쓴이가 자신의 글을 상업적으로 이용하는 것은 별개의 문제입니다. [본문으로]
  3. 이것을 위반하더라도 불법 여부를 가리기 힘듭니다. [본문으로]
  4. 이것을 위반하면 거의 확실하게 불법으로 보고 있습니다. [본문으로]
  5. 과거 네이버의 견해이기도 하다. 현재는 네이버에서는 이 견해를 따르지 않는다. [본문으로]
  6. 악의가 증명된다면, 그것은 범죄 행위로서 처벌을 받게 된다. [본문으로]
  7. "왜 복사 금지냐?"라는 항의는 의미가 없습니다. 앞서 말했듯이 "내가 쓴 글은 내가 지배한다."라는 대원칙에 따라 복사의 허용/금지는 저작권자가 가진 권리입니다. [본문으로]

'미쳐보자' 카테고리의 다른 글

50만 명과 16만 명  (3) 2009.05.30
아까운 사람이 죽었습니다.  (0) 2009.05.24
저작권 템플릿 (GFDL)  (0) 2009.03.28
식품 정보  (0) 2009.03.24
트랙백 연습용 문서  (0) 2009.03.21
글쓴이는 koc/SALM입니다.
본문에 저작권에 대한 사항이 나타나지 않거나, 저작권이 BY-SA로 표기되어 있다면,
이 글은 GFDL로 공개한 글입니다.

카테고리

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

최근에 올라온 글

최근에 달린 댓글

최근에 받은 트랙백

달력

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

글 보관함