2006년 8월 24일 목요일

웹접근성을 높이는 10가지 방법

1. 의미와 목적에 맞는 HTML을 사용하라.
늘 하는 이야기지만, TABLE 태그가 아무리 편리하다 할 지언정, 그것으로 레이아웃을 잡아선 안된다. IMG는 "비텍스트 컨텐트"를 위한 태그이지 장식을 위한 태그가 아니다. 문단은 P로 나누는 것이지, BR이 아니며, 강조는 B대신 STRONG을 쓴다. 밑줄을 위해 DEL을 쓰지 않는다. 목록은 LI를 사용하며, 제목은 Hx를 사용한다. 기타등등, 기타등등...
당신은 이 중에 얼마나 지키고 있는가?

만약, 당신이 이 계통에서 나름 벌어먹고 사는 것으로 만족한다면, 이런 것들을 무시해도 좋다. 그러나 당신이 엉터리 코드를 만들어놓고 User Interface니 User Experience니 떠드는 것만은 참아달라. 심지어 당신보다 아무것도 모르는 클라이언트 앞이라 해도.
마치 귀모 작가가 외계어남발에 비문투성이인 자칭 소설을 써놓고 소설작법에 대해 논하는 것만큼이나 어리석은 일이다.


2. ActiveX를 사용하지 말라.
반드시 ActiveX를 써야 하는 경우가 있긴 하다. 브라우저를 넘어서 Windows OS단의 무언가를 필요로 할 때, ActiveX외에는 대안이 없다.
그러나 그러한 기능을 추가하는 순간, 당신의 웹사이트는 "웹"이 아니게 된다. 곰곰히 따져보면, 차라리 VB나 델파이같은 것으로 전용어플리케이션을 만드는 게 더 바람직할지도 모른다. "웹"이 아닌 것을 "웹"상에 올려놓지 마라.
고스톱 게임은 웹이 아니다. 인터넷 뱅킹도 웹이 아니다. 당신이 지금 만들고 있는 것도 웹인지 아닌지 차근차근 생각해보라.


3. Frame과 Popup을 사용하지 말라.
모든 팝업은 죄악이며, 그 중에서도 인덱스페이지의 팝업은 더 큰 죄악이다.
새창띄우기를 강제적으로 할당하지 마라. 사용자에게 선택권을 주라. 무지몽매한 사용자들로부터 새 창이 뜨지 않아 불편하다는 클레임을 받는다면, Shift+클릭을 이용하라고 친절하게 답변해줘라. 한 켠에 공지해두는 것도 좋겠다. 사용자들은 금방 배운다. 당신이 생각하는 만큼 멍청하고 게으르지 않다.
프레임을 써야겠다면 타이틀을 정확히 명시해두라. 또, NOFRAMES을 이용해 프레임을 지원하지 않는 브라우저를 고려하라.(당신이 짐작하는 것보다 프레임을 지원하지 않는 브라우저와 그 사용자는 꽤 많다.) 그러나 역시 프레임을 쓰지 않는 것이 가장 훌륭한 대안이다.


4. 마우스에 의존하지 말라.
onmouseover, onmouseout 등의 마우스 이벤트를 사용하지 말라. 최소한, 저 이벤트를 이용한 기능이 빠지더라도 웹사이트 이용에 아무런 지장이 없도록 만들라. 전적으로 마우스에만 의존하는 기능은 접근성에 매우 심각한 문제를 불러온다.
특히, 마우스가 올라가면 서브메뉴가 보이는 방식이라든가, 반드시 마우스로만 작동시킬 수 있는 이미지버튼등을 주의하라.


5. 색상과 그림에 의존하지 말라.
색상에 대해 지킬 것은 두가지이다. 디자인시 같은 명도의 색상들은 되도록이면 피할 것. 링크와 본문의 명도차이를 둘 것.
흑백으로 변환했을 때 구별이 가야 하기 때문이다. 링크의 경우에는 밑줄을 그어주는 것이 매우 바람직하다.
IMG는 "비텍스트 컨텐트"요소에만 사용하도록 한다. 즉, 그 이미지가 없으면 컨텐트 자체의 내용 전달이 힘들 때에만 사용한다.
이미지를 사용할 수 없는 경우들이 있으므로 반드시 대체텍스트를 제공한다.
대체텍스트는, 이미지 파일이름도, 이미지 이름도, 이미지에 대한 설명도 아니라, 바로 이미지가 담고 있는 내용자체를 텍스트로 풀어 제공해야 한다. "기사 이미지"라는 대체텍스트는 잘못된 것이다. "8월 22일 아침 9시, 성산대교앞 혼잡한 교통상황"쯤은 되어야 한다는 소리다.
alt로 대체텍스트를 너무 길게 적지 마라. 길게 적어야 겠다면, 따로 파일로 적어두고, longdesc속성을 이용해 연결한다.
Flash나 Embedding, AJAX등에도 대체텍스트는 필요하다.


6. CSS를 활용하라.
CSS로 깔끔하게 디자인된 페이지는 매우 높은 접근성을 갖게 된다. 덤으로 깔끔하게 CSS를 적용시키기 위해서는 1번에서 말한 의미에 맞는 HTML이 필요충분조건이 된다. 시맨틱한 마크업과 CSS의 조화, 그 자체만으로도 접근성에 50점은 먹고 들어가게 된다.
inline CSS는 쓰나마나이니 이건 제외.


7. JavaScript에 의존하지 말라.
Form Submit을 JavaScript를 이용해 하지 말 것.
ASP.NET의 어떤 케이스, 몇몇 JavaFramework에서는 여러가지 파라미터를 넘기기 위해 페이지 전체를 하나의 폼으로 삼고, 링크를 서브밋버튼처럼 쓰는 경우가 있다. 접근성 면에서 아주 안좋다. 솔루션을 바꿀 것을 추천한다.
그 외에도 Form Validating을 위해 JavaScript로 하는 경우가 있는데, Validating자체는 매우 유용하긴 하나 JavaScript로만 하는 것은 보안상 혹은 데이터 무결성을 저해하는 나쁜 케이스이다.
해결책은 간단하다. JavaScript를 하나도 쓰지 말고 웹사이트를 만들라. JavaScript가 하나도 없이 잘 돌아가는 사이트가 되면 이제 필요한 부분마다 JavaScript를 붙인다. 그러면 JavaScript에 의존하지 않는, 그러면서도 JavaScript의 편리함을 누릴 수 있는 사이트가 될 것이다.


8. 소리, 깜박임등을 이용하지 말라.
"쪽지가 도착했습니다." - 한 때 제X보드 스킨 중에 저런 소리로 쪽지를 알려주는 UI가 있었는데, 절대 사용하지 말 것. 청각장애자가 아니더라도, 브라우저나 디바이스에 따라 소리 이용이 불가능한 경우가 많기 때문이다.
번쩍이는 Animated GIF, 플래시, DHTML은 모두 사용불가다. 사실 촌스럽기도 하다.


9. IE를 피하라.
IE전용 페이지로 만드는 순간, 당신의 웹사이트는 접근성에서 10Km쯤 멀어지게 된다. 개발도, 확인도 모두 비IE 브라우저에서 하라. IE기준으로 만들고나서 다른 브라우저로 보며 접근성을 위해 뜯어고치는 것보다, 비IE브라우저 기준으로 만들고 나서 IE로 보며 수정하는 것이 훨씬 빠르고 쉽다.
물론 당연히 VBScript, JScript(JavaScript와 혼동하지 말것.), ActiveX, 기타 IE전용이라 이름붙은 어떤 것도 피하라.
피할 수 없다면 브라우저 스니핑 기법을 통해 IE로 접속했을 때에만 적용되도록 하며, 다시 말하지만 절대로 IE에서만 이용할 수 있는 페이지가 되어선 안된다.


10. 장애인을 위해 아무것도 하지 마라.
별도의 장애인용 페이지, 별도의 자체 TTS... 모두 버려라. 실제로 이것들은 전혀 장애인들에게 도움되지 않는다. 무익할 뿐만 아니라 오히려 해가 된다. 위에 설명한 9가지만이라도 제대로 지키면 접근성은 90점 이상 획득한 셈이다.

2006년 8월 22일 화요일

부산시 홈페이지, 접근성 체크

LINK : 부산시 홈페이지
이래놓고 이벤트 페이지를 걸어놓는 용기에 대해서 일종의 경외심마저 품게 된다.

A. 일단, 친절하게 다운로드 받으라고 되어있는 접근성 체크 항목들부터 보자.

1. 대체텍스트의 사용.
충실하게 대체텍스트를 사용.... 이라기보다는, 쓸 데 없는 잡설을 늘어놓는다는 느낌이다. 애초에, IMG 태그란 "비텍스트 컨텐트"를 위해 사용해야 하는 것인데, 대체텍스트를 사용하는 취지자체를 이해하지 못하고 있다.
http://www.busan.go.kr/open_content/busan/general/basic/6260000-arc-2.0-001.jsp?nSelected=1
위 링크에 걸린 페이지 중간에 기상현황 이미지를 예로 들어보자.
이 이미지는 장식용 그림도 아니고, 엄연히 정보를 전달하기 위한 "비텍스트 컨텐트"이다.
물론 이렇게 이미지만 사용하면 접근성에 문제가 생기기 때문에 접근성 제고를 위해 대체텍스트를 사용해야 한다.
그런데 걸려 있는 대체텍스트는 이렇다.

부산의 10년간 년도별 기온, 상대습도, 강수량, 바람을 나타낸 4개의 그래프

시각장애인이 이 대체텍스트를 보고 아아, 그렇구나, 그런 그래프 이미지구나... 라고 고개끄덕거릴거라 생각하려나? 천만에, 제대로 된 대체텍스트라면 다음과 같은 내용이 들어가야 한다.

기온변화 (섭씨, 92년부터 04년까지 13년간의 기온변화)
최고기온 : 35.6도, 30.7도, 35.8도, 32.8도, 34.9도, 34.1도 ...
...

이래야 비텍스트 컨텐트를 대신하는 올바른 대체텍스트가 된다.
물론, 이러면 너무 길다. 따라서 이럴 경우에는 처음처럼 짧게 쓰되, longdesc 속성을 이용하여 그 내용이 담겨있는 별도의 페이지를 기술해줘야 한다. 물론 전혀 그런 면이 고려되어있지 않다.

한편
http://www.busan.go.kr/open_content/busan/cultural_assets/6260000-arc-2.0-001.jsp?nSelected=4&doc_num=90
이 페이지 본문 중간의 사진에는

문화재란?

이란 대체텍스트가 쓰였다. 과연 이 사진이 "문화재란?"이라는 의문을 전달하는 비텍스트컨텐트인가?
실은 이 이미지는 컨텐트도 아니다. 그저 장식적 요소로 사용되었을 뿐, 여기에 대체텍스트를 덧붙이는 건 오히려 낭비라 할 수 있다. TTS로 웹페이지를 읽을 때 저런 비컨텐트 요소가 얼마나 짜증나게 들리고 웹페이지 이용에 방해가 되는지 확인해보길.

홈인덱스야 말로 이런 짜증요소의 집합체라 할 수 있다.
모든 링크마다 "엔터키를 치시면 ~~ 페이지로 연결됩니다."라는 타이틀을 붙여놓았다. 세상에나, 이 페이지를 TTS로 읽을 때 어떻게 들릴지 생각하고 작성한 것일까?

2. 프레임 사용
굳이 프레임을 사용할 이유가 없는 사이트임에도 프레임 사용을 하고 있는데, 그 이유는 아마도, 브라우저의 URL입력창을 깔끔하게 보이고픈 욕구이리라. 덕분에, 해당 페이지의 주소를 알아보기 어려워 링크등을 연결하기 어렵다.
프레임의 사용은 또한 시각장애인들에게 네비게이션의 어려움을 안겨준다.
게다가, 모든 창의 타이틀이 "부산시청 홈페이지에 오신 것을 환영합니다."는 시각장애인들에게는 좌절 그 자체. 시각장애인들은 여러 윈도우들의 구분을 윈도우타이틀을 이용해 구별하고 있는데, 모든 페이지의 타이틀이 똑같기 때문에 시각장애인들의 네비게이션에 혼란을 초래할 수 있다. 기껏 문서별로 타이틀을 부여해도 프레임안에 갇혀버림으로 인해 효과를 전혀 볼 수 없다.
마지막으로 bottom frame은 불필요하다.

3. 키보드 운용성
중간중간에 보이는 플래시메뉴들은 키보드 접근이 아예 불가능하다.
일부 자바스크립트 버튼들은 키보드 네비게이션시 이상한 동작을 보인다. 예를 들어 FF브라우저를 이용할 때, 현재 모든 페이지 하단에 붙어 있는 사용편의성 평가폼의 경우, 버튼으로 포커스를 옮겼다가 나올 경우 "로그인하셔야 사용할 수 있습니다."라는 alert창을 보이고, 로그인 페이지로 이동시킨다. 마우스를 이용할 수 없는 환경도 고려해야 한다.
상단의 메인메뉴의 경우에도, Tab이동시에는 서브메뉴가 표시되지 않는다. 물론 표시로 끝나면 안되고, 각 서브메뉴에도 적합한 순서로 Tab네비게이션이 가능해야 한다.

4. 링크 스킵
이렇게 정형화된 페이지들로 이루어진 사이트에서 특히 "상단"메뉴와 "좌단"메뉴들을 이용할 경우에는 컨텐트 본문으로 바로 포커스를 옮겨주는 "Link Skip" 링크를 제공해야 한다. 물론 부산시 사이트에는 없다.
정상인들은 2차원적으로 페이지를 파악해서 페이지마다 반복되는 상단과 좌단을 무시하고 컨텐트에 바로 집중할 수 있지만, 시각장애인들이 TTS를 이용하는 경우 이런 Link Skip이 없으면 모든 페이지마다 반복해서 상단메뉴와 좌단메뉴를 줄줄이 읽어주는 걸 들어야 한다. 노이로제걸릴 정도로 짜증나는 일이다.
적절한 링크 스킵의 위치는 body태그 바로 밑에서 컨텐트 본문영역을 가리켜주면 된다. 작은 배려가 높은 접근성을 만들어낼 수 있다.

5. 팝업창
MyLink를 반가와하는 사람이 과연 있는지나 궁금하다. RSS를 제공하니 굳이 MyLink는 없어도 되지 않을까? 게다가 첫 화면부터 팝업창을 들이대는 건 매우 짜증나는 일이다.
각 페이지의 메뉴에서도 JavaScript를 이용한 새창띄우기를 하는 곳들이 있다. 이부분들도 문제.

6. 레이아웃
TABLE을 사용한 레이아웃. 더이상 말할 필요도 없다.

7. Form
label을 사용하라는 소리는 잔소리로 들리나보다. label을 무시해주는 대담함이 멋지다.
한편, form의 submit을 JavaScript를 이용한다. onkeypress등의 이벤트를 사용해줌으로써, Tab네비게이션을 방해하는 한 편, JavaScript를 사용할 수 없는 환경을 완벽하게 씹어주신다. JavaScript가 disabled되면 로그인도 못하는 사이트라... JavaScript는 부가요소이지, 필수요소가 아니다. 브라우저에 따라 JavaScript를 쓸 수 없는 브라우저들(음성브라우저, 점자브라우저, 텍스트브라우저, 모바일브라우저)이 있다는 것을 잊지 말자.

B. 다른 부분도 좀 보자.
1. 시맨틱 마크업
전혀 되어있지 않다. 실은 HTML Validator조차 통과하지 못하고 있다.

2. JavaScript
document.getElementById()를 쓰는 것이 그리 어려운가? JavaScript는 Copy&Paste로 끝이라는 발상을 가진 개발자(혹은 코더)의 문제겠지만.
DOM에 관한 공부가 필요한 듯 싶다.

3. CSS
CSS에러가 한다발... IE전용 CSS문법을 쓰고 있는 건 그렇다 치고... CSS를 쓰려면 전부 External로 쓰던가, 군데군데 inline CSS는 코드의 효용을 떨어뜨린다.

4. Java Framework
Java 프레임워크에 과문한 탓으로 VSKIP이라는 태그를 쓰는 프레임워크가 뭔지 잘 모르겠다. 허나, 저런 프레임워크용 템플릿태그가 해석되지 않은 채 소스안에 보이는 것은 문제가 아닌가? 프레임워크 자체의 버그로 보인다. 최소한 프레임워크용 템플릿 태그가 소스중에 노출되어야만 한다면 주석처리라도 해주는 게 옳다.

5. 장애인 홈페이지
장애인 홈페이지에 플래쉬 네비게이션이라는 센스가 멋지다. 물론 새로 나온 플래쉬로 얼마든지 접근성이 높은 무비를 만들 수 있다고 한다. 아르바이트 플래셔에게는 힘든 요구일지도. 어쨌든간에... 접근성 제로다.
장애인을 위한 홈페이지라는데, 정작 장애인에게 이용될 수 없는 홈페이지라니 뭔가 인생의 아이러니를 보여주는 듯 하다.
(솔직히 분석하는게 짜증나서 말투가 아까부터 씨닉해지고 있음.)

6. 품질검사.
http://valet.webthing.com/view=Asis/access/htnorm?url=http%3A%2F%2Fbusan.go.kr%2Fopen_content%2Fmain_page%2F6260000-arc-2.0-001.html&suite=SECTION508&xslt=compact
첫페이지만 따서 webthing의 Section508 검사를 한 결과이다.
몇가지만 짚어보자.
* iframe에 대체텍스트가 빠져있다.
* 플래쉬 무비등의 대체텍스트 사용이 잘못되어있다.
* CSS가 없이도 충분히 정보전달이 가능해야 하는데, 미흡하다.
* textarea안에 flash object라니....
* onmouseover같은 마우스이벤트에 의존하는 스크립트를 사용했다.
기타등등 기타등등...

Watchfire의 WebXact 검사기를 이용해 굿모닝시장실 페이지를 돌려보았다. ()안은 WCAG 1.0기준의 접근성 체크목록의 중요도이다.
* img에 대체텍스트가 없는 경우가 14건. (중요도 1)
* DOCTYPE의 잘못된 사용 (중요도 2)
* 절대사이즈 및 포지셔닝 사용 (중요도 2)
* 마우스 의존적인 이벤트 핸들러 사용 (중요도 2)
* 테이블 레이아웃 사용(중요도 3)
에러건수만 총 5종 81건.
실은 메인인덱스페이지를 대상으로 하려했으나 WebXact 검사기를 뻗게 만들 정도라서 그나마 문제가 적은(?) 시장실 페이지를 대상으로 했다.

이정도라...
흠, 열화와 같은 참여를 위해 일부러 엉망으로 만들고 이벤트를 걸었나...
아니면 딴에는 자신있다고 생각하고 이벤트를 한 것일까...

이벤트... 하고 싶을까?

....

2006년 8월 18일 금요일

Tag, 반쪽짜리 멍청함

* 이전에 썼던 글을 다시 올림. 조만간 "Tag, 완벽한 멍청함"이라는 제목으로 후속편을 올리기 위해...

어쩌다보니 계속 태그에 대한 부정적인 글만 쓰게 된다. 어쩌랴, 실제로 나 자신은 납득할 수 없는걸.

* 태그, 과연 꿈의 도구인가?

지금은 문을 닫았지만, SF 팬덤내에서는 유명한 홍인기님의 홈페이지를 MovableType을 이용해 만들어드린 적이 있었다. 당시, 그 분의 요구중에, "하나의 글을 다양한 경로로 접근가능할 것"이라는 것이 있었다. 예컨데, "1960년대, 미국작가, 청소년용, 인공지능"이라는 분류를 글에 부여하고, 각각을 통해 해당 글에 접근할 수 있도록 하는 것이었다.
MT는 여전히, 영감을 가득 주는 CMS툴인데, 멋진 기능 중 하나는 바로 멀티카테고리였다. 다단 카테고리와는 달리, 단계별 카테고리를 제공하는 대신, 여러개의 카테고리를 하나의 글에 부여할 수 있고, 각각에 대해 글을 모을 수 있는 기능을 제공했다.
인기님은 각각의 글에 주의깊게 준비된 카테고리 목록을 부여함으로써, 자신의 글에 대한 체계적이면서도 다양한 인덱싱이 가능하게 했다.
껍데기만 보면 완벽한 "태그"이다.

이 말은 뒤집어서 말하자면, "태그"란 결국 멀티카테고리에 지나지 않는다는 뜻도 된다.
WP나 TT, Egloos등에서 멀티카테고리를 지원하지 않으므로, 하나의 카테고리로 담아버리기엔 왠지 엉성해지다보니 태그에 대한 관심이 생기게 된 듯 한데, (추가 : WP에도 멀티 카테고리가 된다.)
이는 전적으로 컨텐츠 생산자의 입장에서 바라본 태그의 효용이다. 컨텐츠 생산자가 붙이는 태그는, 생산자 본인에게는 매우 유용하고 의미있는 분류체계이지만, 그 밖의 사람들에게는 오히려 정보의 노드를 파악하기 어렵게 만드는 불필요한 잉여정보일 뿐이다.
그러니까, WP나 TT등의 블로그툴에서, 작성자 본인을 위해서 사용하는 태그라면 나름대로 쓸만하겠지만, 이것을 집단지성으로 결부시키는 것은 무리하고 멍청한 시도이다.

아주 간단한 비유 하나.
만약 글 작성자들에게 자신이 방금 작성한 글에 대해 스스로 별점을 매기게 한다고 해보자. 자신이 생각하기에 좋은 글은 5점, 그저 그런 글은 1점.. 이런 식으로.
이 점수 매기기는 글 작성자 본인에게는 꽤 유용하다. 예를 들자면 5점짜리 글들만 모아보기. 같은 것, 매우 괜찮은 분류법이다. 혹은 이런 식으로 말할 수도 있다. 내 블로그의 4점 이상 글들만 읽어주세요.. 라든가.
그러나 독자 입장에서 이 별점을 신뢰할 수 있을 것인가. 그건 장담할 수 없는 일이다. 글 쓴이가 5점을 주었다고 해서 독자도 5점을 줄 것인가. 또는 글쓴이는 가치없다고 생각하는 1점짜리 글이라도, 어떤 독자에게는 5점짜리 컨텐츠일 수도 있다. 소위 말하는 longtail의 입장에서는.
이런 것을 감안해 볼 때, "XXX님이 쓴 5점짜리 글모음"이라는 아카이빙은 독자에게는 오히려 객관적인 정보획득을 방해하는 무익한 일이다. 따라서 어떤 메타 서비스에서 "여러 블로거들의 (자칭) 5점짜리 글모음"이라는 섹션을 만들어 두어봤자, 그것이 개개 독자들한테는 아무런 의미를 주지 못한다. 물론, 그 섹션에 글이 등록된 필자 자신에게는 유의미할지는 몰라도.
아마도, 구체적인 대상을 뭉뚱그려버린 "대다수의 블로거"들에게는 그 섹션이 그나마 "읽을만한 것"을 찾는데 도움이 될 수 있다고 반론할 수 있을지도 모른다. 그러나 도대체 그 뭉뚱그려진 "대다수의 블로거"와 세상에서 오직 유일한 "나 자신"이 어떻게 동일시될 수 있는가. 논리의 비약이 심하다. 개인은 모르겠지만, 대다수에게 도움이 될 수 있다는 애매모호한 컨셉이 비즈니스모델이 될 수는 없다.

위 비유에서 "별점"을 "태그"로 바꾸면 무슨 말을 하려는지 이해가 될 것이다.

"태그"는 folksonomy의 한계 이상을 벗어날 수 없다. folksonomy의 본질은 "유희"나 "경험마케팅"을 염두에 둔 것이 아닌, 새로운 정보 분류법-정보분류의 헤게모니 이동-을 목표로 하고 있는데, 정작 그 결과가 컨텐츠 생산자의 자기만족일 뿐이라면 핀트가 어긋나도 한참 어긋나있는 셈이다.
본시, folksonomy란, 생산자의 일방적 분류법에 반대하여 소비자의 의지를 기준으로 하는 분류체계를 말함이 아니던가. 헌데, 막상 여기저기에서 회자되는 태그의 사용법은 고작 컨텐츠 생산자의 또다른 일방적 분류법에 지나지 않았다. 그 뿐이라면 나름대로 생산자 개인에게는 가치있는 분류법일 수도 있겠지만, 그것을 모아서 web2.0이라는 딱지를 슬그머니 붙여놓아봤자 도대체 그것을 무엇에 쓴단 말인가. 일견 무언가 대중참여가 이루어지고 있는 듯 해보이지만, 환상일 뿐이다.
무한개의 쓰레기통을 가져다 놓고 니들 맘대로 담아봐라, 대신 딱지는 멋지게 붙여주마... 라고 한들 분리수거가 제대로 이루어질 리가 없다. 집단지성이 적어도 현재의 생산자중심 태그형태로 발현될 가능성은 0에 수렴한다. (집단감성이 발현될 가능성은 100에 수렴한다.)

이것은 태그 자체의 무정형, 중복가능성, 오류가능성과는 별개의 문제이다. 이런 것들은 태그 자체의 단점이라기보다는 오히려 장점이 될 수 있다. 다만 무리하게 생산자 중심 태그로 적용하려다보니 문제로 보이는 것 뿐이다. 애초에 개인한테만 가치있는 것을 무리하게 다수에게 가치있는 것으로 만들려다 보니 발생하는 것들. 그러니 Tag Suggest란 얼마나 바보같은 짓거리란 말인가. 내 맘대로 태그를 붙이지 못하고, 남들과 같은 태그를 붙이라니 그럴거면 뭐하러 태그를 붙이냐는 거지. 애초에 태그 자체란, 남들과는 다른 나만의 새로운 분류를 위해서가 아니었나?
혹자는 Tag Suggest를 무시하고, 개인적으로 붙이면 되는 문제가 아니겠냐라겠지만, 이 경우에는 소위 Tag를 중심으로한 메타서비스들은 졸지에 자가당착의 문제에 직면하게 된다. 처음부터 핀트를 잘못 맞춘 셈이다.

* 태그는 무용한가?
그렇지 않다.
1) 주의깊게 훈련된 생산자가 역시 주의깊게 작성된 태그를 사용할 경우 정보분류에 엄청난 부가가치를 준다. 이것은 소비자에게도 유의미하다. 그러나 적어도 개인 블로그 정도에서의 생산자 중심 태그는 생산자 자신을 제외한 다른 이들에게는 불필요하다.
2) 역시 전문적으로 훈련된 편집자가 역시 주의깊게 작성된 태그를 생산된 컨텐츠에 붙일 경우 이것도 정보의 가치를 한층 높여준다. 태그는 아니지만 슬래쉬닷컴의 편집시스템을 연상하면 될 것이다.
3) 소비자가 자신만의 태그를 타인의 컨텐츠에 부여할 때 비로소 태그의 진정한 위력이 발생한다.

"개인"을 중심으로 보자면, 그가 붙인 태그가 "웹 2.0"이든, "web 2.0"이든, "webbb 2.0"이든, 혹은 "web 3.0"이든 심지어 "쓰잘데기없는 헛소리"이든 아무 상관이 없다. 오히려 이렇게 자기 맘대로 붙일 수 있을 수록 그 자신에게는 더 유용하다.
실제로, 특정 태그에 어떤 글이 달려 있는 것이 중요한 것이 아니라(이것은 생산자 중심 사고 방식이다. 태그에 글이 종속된다는 것, 이것은 기존 카테고리 중심 분류체계의 이름만 바꾼 셈이다.), 그 글에 어떤 태그가 달려있는가가 더 중요하다. 이것은 소비자가 태그를 붙인다는 전제하에, 개인에서 집단으로 대상을 넓힐 때 의의가 있다. "왕의남자"라는 태그에 어떤 글들이 달려있는가보다는(이것은 해당 키워드로 검색하는 것보다 하등 나은 결과를 낼 이유가 없다), "왕의 남자"라는 영화비평에 어떤 태그가 붙어있는가가 다른 사람들이 그 글에 대해 이해하고 분류하는데 더 가치가 있게 된다.

del.icio.us가 뜨게 된 이유는 개개인이 새롭게 분류가치를 줄 수 있어서이고, 아마존의 태그가 유용한 이유는, 다른 소비자들이 붙인 태그가 나에게 도움이 되어서이다.(절대로, 출판사가 붙이는 태그였다면 그렇지 않았을 것이다.) 집단지성이란 표현을 쓰려면 최소한 그러한 전제는 깔고 들어가야 한다. 그저 태그 클라우드 제공한다고 집단지성이 하늘에서 뚝떨어진다면 박지성이 웃을 일이다. (미안하다. 농담인데 안 웃긴 것 같다.)

3줄 결론.
컨텐츠 생산자가 붙이는 태그는 제한된 효용만 준다.
그렇게 제한된 효용만 주는 생산자 중심의 태그만 모아봤자 의미없는 노이즈의 집합이나 다름없다.
태그는 소비자가 붙이게 하라.

2005년 7월 10일 일요일

RSS에 대해. -4- (창고정리)

* 2005년 7월 10일. 이걸로 이 주제는 땡. 역시 앞뒤 context가 빠지니까 이 글만 읽어서는 맹하다.
* 블로그를 옮기면서 RSS 전문공개와 contents:encoded 사용이 되어버렸는데, Wordpress의 기본세팅이 그런지라... 손보는 것도 귀찮아서 그냥 둔다. 뭐, 열낼 거 있나.. 싶기도 하고.

이 주제에 대해 더 이야기하는 것은 동어반복인 감이 없지 않습니다. 그 이유는 일단 몇가지 기본 개념에 대해 오해하시는 부분들이 있어서라고 생각되네요. 자세한 내용들은 앞서 여러차례에 걸쳐 설명했기 때문에 상세 내용은 이전글들을 참조하세요.

1) RSS의 공개/일부공개/비공개.. 라는 개념은 엄밀히 말해 잘못 쓰이는 셈입니다.
앞서 말했듯이, RSS는 제공/제공하지 않음, 두개의 옵션만 있을 뿐입니다. 오히려 "일부공개"라는 개념이 유효하려면, 그 뜻은 "제한된 특정인에게만 특정 아이템을 제공"이라는 뜻이어야겠지요.
그러나 요즘(?) 쓰이는 "일부공개"라는 뜻은, 아마도 "요약제공"을 뜻한다고 봅니다. 왜 이게 중요하냐 하면, 원래 RSS의 규격자체가 "요약(요약이라기보다는 설명이 더 정확한 번역이겠지만. - description)"을 제공하기 위함이기 때문에, "일부공개"라는 용어는 불필요한 오해/선입견을 줄 수도 있겠지요.

2) RSS 2.0까지의 오리지널 포맷에는 <description>만 존재합니다. <content :encoded>는 나중에 마크 필그림등에 의해 확장기능으로 제안되었으며, 많은 리더기가 이 기능을 지원하나 표준은 아닙니다. 그래서 content:encoded를 쓸 때에는 반드시 description을 같이 써서, content:encoded를 지원하지 않는 리더기에서도 읽을 수 있도록 해야한다고 하고 있습니다. (국산 블로그 툴이나 서비스들은 이런 점을 전혀 신경쓰지않고, content:encoded만 쓰거나, 심지어 description안에 HTML코드를 담아 내보내는 만행을 벌이고 있지요.)

3) content:encoded는 문자 그대로, 인코딩된 컨텐트. 즉, HTML코드를 위한 규격입니다. description도 문자 그대로, 요약을 위한 규격이며, 인코딩되지 않은 텍스트를 씁니다.
description이 기본이고, content:encoded가 기본이 아니라는 사실만으로도 RSS에 요약을 쓰는 게 우선함을 알 수 있습니다.

4) hof님의 블로그에서 제공하는 RSS를 보더라도 description으로는 요약(또는 전문의 최초 n개의 글자 - no html)만, 전문은 별도의 content:encoded를 통해 제공하고 있음을 보실 수 있습니다. 또 김중태님의 블로그의 경우에는 description으로 요약(또는 전문의 최초 n개의 글자 - no html)만 제공하고 있구요. 호찬님의 경우에도 처음에는 description만 제공하셨다가 나중에 description에 전문을 담기는 했습니다.(잘못된 포맷입니다.) 그러나 역시 요약만 제공하는 RSS도 별도로 제공하고 있습니다.

5) 외국의 예를 자꾸 드는 이유는, 국내산 툴과 서비스가 "전부" 잘못되어 있기 때문입니다.(블로그를 만들 때 제대로 공부를 안해서... -_-a 제가 개인용 블로그 툴을 만들어봤고 서비스도 두어개 만드는데 참여해봤고 지금도 만들고 있기 때문에 단언할 수 있습니다. 실제로 이런부분에 대해 아무도 모르고 있었습니다. 지금도 아마 모르고들 있을 겁니다. -_-a)
실제로, 외국의 거의 대부분의(사실, 예외를 찾지 못했습니다만, 제가 모르는 것도 있을 수 있기에) 블로그 툴과 서비스에서 제공하는 RSS용 템플릿등을 보면 description을 기본으로 채택하고 있습니다. (최근에 나온 WP등은 description과 content:encoded를 동시 지원하긴 합니다.)
메이저 사이트들이 "유료"라서 description을 사용한다면, 왜 개인용 툴과 서비스들도 하나같이 description을 기본으로 사용할까요? 기술적으로 어려울 일은 하나도 없는데 말이죠.

6) "사이트를 방문하지 않고"라는 뜻은, "갱신된 내용을 알기 위해 일부러 사이트에 일일이 들어가보지 않고"라는 뜻입니다. 사이트(페이지)에 들어가지 않는 것이 목적이 아니라, 들어갈만한 사이트(페이지)만 골라 들어가자는 것이 목적입니다. 사이트를 방문하지 않아도 된다면, 조금 과장되게 말해서 사이트 무용론도 등장할 수 있겠죠. 순수하게 RSS만으로 신디케이트되는 서비스도 있을 법 하지 않겠습니까? (RSS가 아닌 ATOM이 대세가 되면 그런 서비스도 가능해지긴 할 겁니다. 또, podcasting같은 특수한 경우도 있긴 합니다만, description과는 상관없는 이야기죠. - 그런 의미에서 올블로그에서 지원하는 podcasting방법은 상당히 문제가 있습니다. 올블 이야기를 좀 더 하자면, 올블에서 지원하는 나의 추천글 방법도 역시 동일한 문제가... -_-a)

7) 오해를 심화시킨 건 네이버의 몫도 큽니다. 네이버의 변명인 "저작권 운운"은 말도 안되는 소리입니다. "전문의 글자 일부분"이라 하더라도, 저작권에 문제가 있을 수 있습니다. 저작물의 전체가 아닌 부분에도 저작권은 적용됩니다. 따라서 저작권때문에 일부만 제공한다는 소리는 멍청한 소리입니다. (원래, 네이버는 좀 그런 끼가 다분하기 때문에 별로 새삼스럽지도 않습니다만. -_-a)

8) 카트라이더와의 비교는 안들은 걸로 하겠습니다. ^^;

9) 웹표준화와 접근성의 관점에서 가장 고려해야 할 부분은
- 빈곤층/저개발국/인프라부족환경에서도 접근과 사용이 가능할 것.
- 장애인/학습능력이 낮은 사람/저연령/고연령층등에게도 모두 접근과 사용이 가능할 것.
- 비PC기반의 크로스 플랫폼에서도 접근과 사용이 가능할 것.(크로스브라우저는 말할 것도 없고...)
등이 있습니다.
위의 두가지는 논외로 하더라도, 세번째만 보아도 text기반의 description 사용은 자명합니다. 당장 PDA, 모바일, 키오스크, 웹TV, 기타등등 각종 머신피드로 사용되기 위해서는 content:encoded는 많은 문제가 있습니다. 그것이 description을 사용해야 하는 이유입니다. description을 기본으로, 그리고 꼭 전문을 보이고 싶다면 content:encoded를 별도로 지원하는 것이 옳습니다.

10) 따라서 네이버가 description만 지원한다고 해서 그것을 잘못되었다 말할 수는 없습니다. 불편하고 불만일 수는 있어도 말이죠.

11) description을 인정하더라도, 두가지 층위의 불만이 존재할 수 있는데, 한가지는 "글의 일부분"을 description으로 인정할 수 있느냐와, "글의 일부분"을 어디까지로 한정짓느냐겠습니다.
전자에 대해서는 그걸로 충분하다고 생각하지만, 불만이신 경우에는 네이버에 "요약-글의 일부가 아닌"을 입력할 수 있는 필드를 제공해달라고 요청해야겠지요. 또 외국의 경우를 들어서 죄송합니다만, de facto 표준 블로그시스템으로 여겨지는 MovableType을 비롯한 대부분의 블로그 툴과 서비스에서는 별도의 "요약"을 입력할 수 있는 방법을 제공합니다. 물론 요약을 입력하지 않은 경우에는 글의 앞부분 일부를 자동으로 요약으로 처리합니다.
국산에는 엔비블로그가 유일할 겁니다. (참고로 국내의 블로그 툴 및 서비스에서 가장 표준에 충실한 것은 엔비블로그입니다. 국내에서 표준은 무시당하고, 비표준이 활개치는게 꼭 블로그계만은 아닙니다만.)
후자에 대해서는 실제로 description자체를 담지 않는 경우도 있습니다. 타이틀만으로 충분히 컨텐츠(링크)에 대한 정보를 제공할 수도 있기 때문이죠. 그래서 description은 필수 엘리먼트가 아닌 선택 엘리먼트입니다. 네이버에서 이 부분의 개선을 위해서라면, 몇글자까지를 description으로 사용할 것인가를 선택할 수 있는 방법을 제공해주는 것이 올바른 해결책이겠죠. 역시 외국의 많은 툴과 서비스에서는 이 description으로 사용할 글자수를 지정할 수 있는 설정을 제공합니다.

12) 네이버가 description으로 본문의 일부만 제공한다 해서 네이버쪽에 득될 일은 하나도 없습니다. 쓰고 계신 분들이 더 잘 아시겠지만, 광고덩어리 네이버에서도 블로그에는 감히 광고를 못붙이고 있습니다. (붙였다가는 난리나겠죠.) 이미 이 부분에 대해서는 김중태님이 여러번 핵심을 잡아 설명하신 적이 있습니다. 그러므로 사용자가 RSS를 읽다가 관심이 가서(혹은, 그 짧은 description때문에 화딱지나서) 실제 해당 페이지에 접속한다 해서 네이버의 수익이 늘어나거나 할 일은 전혀 없습니다. 그러니, 장사속이라고 표현한다면 네이버로서는 억울한 일이겠죠. (평소 행실로 봐서는 뭐 별로 변명해주고 싶지는 않습니다만.)

13) 어쨌거나, 결론은 그겁니다. 국내의 RSS포맷들은 대부분 잘못된 포맷이고, 그 잘못된 포맷에 익숙해져있다보니 불편해졌을 뿐이지만, 표준포맷을 사용했다 해서 비난할 일은 아니라는 겁니다. 더 나은 서비스를 위해 확장을 요구하거나 개선점을 요구할 수는 있어도 말이죠.

14) 어디 잘못된 포맷이 RSS뿐이겠습니까. 트랙백도 그렇고..

헥헥.. 길게 썼네요. 너무 길어서 안 읽으실지도. -_-a

2005년 7월 7일 목요일

RSS에 대해. -3- (창고정리)

* 2005년 7월 7일, 역시 창고정리중. 옛날에 썼던 거라 context없이 글만 보니 이상...

(오해의 소지가 있다고 판단하여, 제목에서 "네이버"를 빼고 시작합니다.)
폴리스님과의 커멘트대화만으로는 한계가 있어(-_-a 중첩커멘트 템플릿을 이렇게 댓글이 길어질 것을 염두에 두지 않고 썼더니 커멘트 쓰는 영역이 점점 좁아져서...) 따로 포스팅합니다.

제목에서 네이버를 빼긴 했지만, 문제의 시발점이 네이버 RSS 변경이므로 잠깐 언급하겠습니다.

1. 문제의 시발은 네이버가 RSS에 "전문"을 보여주는 대신 "글의 일부"를 보여주는 것으로 바뀌었고, 이에 대해 불만이 많으신 분들이 있으신 듯 하여 그에 대해 적은 글입니다.

2. 제가 폴리스님(그리고 몇몇 분들)께로 트랙백을 걸긴 했지만, 그 불만에 대한 "딴지"를 위해 트랙백을 건 것은 아닙니다.

3. 다만, 네이버가 RSS를 변경한 것이 "불만스러울 지는 몰라도", "잘못된 것은 아니다."라는 것을 지적하려는 의도였습니다. 혹시 그 의도가 잘못 전달되었다면 글솜씨 없음으로 생각해주시기 바랍니다.

4. "요약"과 "전문"중 어느 것이 바람직하냐에 대한 소견은 이미 앞글에서 밝혔으므로 여기에서는 다시 언급하지 않겠습니다. 이 부분에 대해서는 본문중에 RSS라는 단어에 걸린 링크를 눌러보시면 관련 글들이 붙어있으니 참고하시기 바랍니다. Zeldman씨 등이 밝히신 RSS의 정의 등이 포함되어있는 글이므로 읽어보시면 제가 이야기하려던 것이 어떤 것인지 이해하시는데 도움이 되리라 생각됩니다.

5. 다만, "글의 일부"를 요약으로 인정할 수 있느냐하는 부분에서는 입장을 밝혀야겠군요.
결론부터 말하자면, 저는 "글의 일부"를 "요약"으로 인정합니다. 네이버의 80byte짜리라 할지라도요. 심지어는, "글의 일부"조차 없는 - 즉 description이나 excerpt가 전혀 없이 title만 있는 RSS도 인정합니다. (제가 인정하고 자시고 할 문제는 아니지만, 입장은 그렇습니다. ^_^)

물론, 별도의 "요약"을 지원할 수 있는 툴들이 바람직한 것은 사실입니다. 그러나 국내 대부분의 가입형서비스에서는 이 기능을 지원하지 않으며, 제가 아는 한, enbee.com의 엔비블로그에서만 지원하고 있습니다.

대개의 시스템에서 별도의 "요약"을 지원하지 않는 한, RSS의 본래 목표였던, "구독 여부의 가치판단"을 위한 정보로 사용할 수 있는 것은 글과 제목 뿐입니다. 글의 일부라 할지라도 부족하나마 충분히 가치판단 정보로 사용될 수 있습니다. 심지어, 글은 전혀 언급되지 않고, 단지 제목만 가지고도 가치판단 정보로 사용될 수 있습니다. 이를 돕기 위해 "category"등의 보조 수단을 사용할 수도 있습니다.

그러나 "별도의 요약"보다 부족한 것은 사실이지요.

6. 그러므로 네이버의 RSS가 불만스럽다면, 가장 바람직한 해결책은 "다시 전문 표기로 바꿔달라"는 것이 아니라, "별도의 요약을 입력할 수 있도록 해달라."는 것이 맞다고 생각합니다.

7. 앞에서 말한, 메이저 사이트들에 대해 좀 길게 적겠습니다.

메이저(?)의 선정은 대표적 RSS리더인 Feed Demon 1.5버전의 기본 내장 목록을 기준으로 삼았습니다. 상당히 양이 많아서 일일이 해당 링크를 걸지 못함을 양해바랍니다.

- 요약 혹은 일부, 혹은 캐치카피만 제공하는 사이트
Businessweek, Christian science monitor, CNN, Fast Company, Fortune, Moreover, SmartMoney(기사내용에 따라 제목만 제공하는 경우도 있음), The Motley Fool, Builder.com, CNet, GameSpot, TechRepublic, ZDNet, Digitally Obsessed, Movies.com(본문없이 영화스펙과 메인이미지만 제공), RollingStone, Smart-Popcorn, Variety, Yahoo!News, Ask Yahoo!, Dictionary.com, WiredNews, Kevin,M.D, WebMD, Lockergnome, Reuters, Media Guerrilla, BBC, Guardian, MemoryBlog, The New York Times, The Village Vioce, USNews, Instapundit, PowerLine, Talking Points Memo, Amnesty International, BetaNews, PC Magazine, MajorGeeks, PC World, SnapFiles, ESPN, PR WebSports, SI.com, Extremetech, Gizmodo, Microsoft Watch, The Register, A List Apart, Accessify, Brainstorms and Raves, Digital Web Magazine, Jeffrey Zeldman Report, Meyerweb(에릭 마이어), Sitepoint...

- 아예 제목만 제공하는 사이트
The WallStreet Transcript, The WallStreetJournal, Digital Theater, MedicineNet, Radio Free USA, Mozilla.Org, MozillaZine...

(너무 많아서 대충 생략합니다.)
물론 전문을 거는 사이트들도 있습니다. 그러나 개인 블로그가 아닌, RSS를 제공하는 메이저 사이트(이정도면 메이저 사이트들이라고 생각합니다만.)들은 대부분 요약 혹은 글의 일부, 혹은 제목만 제공하고 있습니다. 물론, 유료서비스 혹은 회원제 서비스때문에 그렇게 사용하는 경우도 있고, 또 아닌 경우도 있습니다. 또, HTML을 일부 허용하거나 완전 금지하거나 하는 등의 차이는 약간 있습니다.

위의 사이트들은 글의 일부(길이는 각 사이트별로 차이가 있습니다만.) 혹은 제목만 제공하지만 그것으로도 충분히(물론 사람에 따라서는 아닐 수도 있겠군요.) 구독 여부에 대한 가치판단이 가능하다고 생각합니다.

8. 이런 점등으로 미루어, 네이버의 RSS변경은 익숙한 사용자에게 불편을 줄 지언정, 크게 잘못된 점은 없다고 할 수 있습니다. 또한 그 불편은, 어떻게 보자면 잘못된 관습에 익숙해져있던 것에 기인한다고도 할 수 있습니다. (다시 말씀드리지만, 전문 대신 요약-글의 일부 혹은 제목만 포함한 것이라도-을 사용하기를 권장하는 건 그냥 제 개인적인 희망사항만은 아니며, 이미 국내외 많은 블로고스피어에서 이에 관해 논의되어왔습니다. 물론 어느 한쪽이 절대 옳다는 것은 아니며, "전문"을 쓰는 것에 대한 장점은 저도 잘 인지하고 있습니다. 게다가 "전문"을 쓰는게 RSS 규약에 위배(오리지널 포맷에는 없지만 확장을 통해 가능하므로)되는 것이 아니므로 "전문"을 쓴다는 것이 잘못되었다는 것은 아닙니다. 그러므로 "권장"이라는 표현을 쓰고 있음을 살펴주세요. :)

RSS에 대해. -2- (창고정리)


2005년 7월 2일 토요일

저작권법상 RSS는 불법?

아래 이야기를 하다보니 좀 더 이야기할 꺼리가 생기는군요.

새로운 저작권법이라는 것이 얼마나 자가당착적인가 하면, 그 논리대로라면, RSS도 불법, 트랙백도 불법일 수 있습니다.
대표적인 예가 온신협의 신문기사인데요.
물론 온신협은 일반인들의 "deep link"는 "허가"하겠다고 말하고 있습니다. 표현을 주의해주세요. "원래 불법이지만, 돈내라고는 안할께. 우리는 음반협보다는 신사적이거덩." 이 소리입니다.

이들의 주장이 뭐냐 하면,
1) 인용(스크랩, 펌)은 불법 (이건 당연한 소리)
2) 링크도 불법. 단, "메인페이지"로 가는 링크는 합법. (???)
2-1) 단, 비영리 목적의 일반 사용자에게는 "허용"

에, 원칙적으로 이야기하자면, "기사제목"을 쓰고 거기에 링크를 걸어 해당 기사 페이지로 보내는 것도 불법이라는 주장입니다.
그럼 이게 왜 저작권을 침해하는 불법일까요?

주장 1) "기사 제목"도 "기자의 편집/창작의 소산"이다.

음.. 그럴지도..
??? 그럼, "기사 제목"을 살짝 바꾸면 안될꺼나요? 예를 들어 "남북 정상회담 년내 실현가능성 없어" 라는 제목 대신, "무현 아찌, 정일 아찌랑 밥한끼 먹기 어려워..." 라든가.

주장 2) 니네가 서브페이지로 바로 가버리면 메인 페이지의 광고 수익이 떨어지걸랑. -> 이게 본심.

그렇습니다. 온신협이 deep link를 막는 근본적인 이유는, 광고 수익때문인겁니다. 저작권을 보호하기 위해서라면 인용/펌/스크랩/프레임링크(이 괴상한 용어는 또 뭔지. -_-a)만 막으면 됩니다.

문제는, 이것을 RSS에 적용시키면 매우 이상한 모양이 된다는 것입니다.
이 논리대로라면, 웹 RSS 리더 서비스들은 모두 불법입니다. RSS등록을 링크에 대한 동의라고 인정하지 않는다면 말이지요.

Q.당연히 사용자 자신의 RSS등록은 링크에 대한 동의라고 할 수 있으니까 올블 등에는 상관없는 것 아닌가???
네. 올블은 "가입/등록"이라는 절차가 있습니다만. 익명 등록이 가능한 서비스였다면 아마 문제가 있었을 수도. 막말로, 조선일보에서 RSS를 제공해놓고, 그것을 익명 등록한 후, "어라? 우리도 모르는 사이에 여기에 링크가 걸려있네??"라고 소송들어와도 할 말 없다는 거죠.
"우리는 RSS를 제공하지만 올블에 제공하려는 것은 아니거덩??" <- 어디서 많이 들어본 소리같지 않나요? ^_^. 얼마전 리플온, 그리고 더 올라가서 다음 RSS넷 때 많이 들어보셨죠?

Q. 뭐가 문제???
올블같은 "메타서비스"야 그럭저럭 넘어갈 수도 있습니다만, 개인용 웹 RSS 리더프로그램들은요? 여러분들이 "허가없이" 어느 블로거의 RSS를 개인용 웹 RSS수집기에 등록(자신이 읽으려는 목적으로)해서 읽는 것 조차 "불법"이 되어버린답니다.

지금까지의 이야기에서 간과한 점이 있죠.
RSS는 "공개"를 목적으로 한다는 점. 즉 RSS를 달았다는 뜻은, 누구든지 마음대로 가져가서 사용해라.. 라는 암묵적 함의입니다. 그래서 국내 신문사들은 결코 RSS를 제공할 리 없죠.(실 제로 오마이뉴스라든가 몇몇 신문사에서는 제공하고 있습니다. 뒷감당을 어찌할른지는 저도 모릅니다. ^_^) 사용자들이 웹 RSS 리더에 등록해서 부지불식간에 저작권법을 위반할까봐 걱정되서 친절하게도 RSS제공을 안해주시는 것일지도...(그럴 리 없음. -_-a)

RSS 이야기를 하다보니 Trackback이야기도 빼먹을 수 없네요.
트랙백을 받는 쪽에서야 "트랙백 보내는 것이 링크에 대한 동의"로 간주해서 받은 트랙백 리스트를 보여줘도 상관없을 수 있지만(어느 천재적인 변호사가 "트랙백 보내는 것을 링크에 대한 동의로 간주할 수 없다"는 판례를 이끌어내기 전까지), 반대로 보내는 쪽에서는 "어디어디로" 트랙백 보냈다고 보여주는 건 "deep link" 불법이 되어버리는 셈입니다. 에, 여기서도 온신협의 주장에 따라 해당 서브페이지가 아닌 사이트 메인페이지까지만 링크를 건다면 혹여 빠져나갈 구멍이 생길 수도 있겠네요.

자, 더 웃긴 것을 생각해봅시다.
메인 페이지라는 건 도대체 뭐죠? 네이버 블로그의 메인 페이지는 어디입니까? http://blog.naver.com 입니까? http://blog.naver.com/xxxxx.do 입니까? "사이트"의 메인 페이지라면 아마도 http://blog.naver.com을 가리킬 겁니다. 온신협의 주장대로라면, 네이버 블로그의 수많은 사용자들의 블로그에 대한 링크 자체도 서브 페이지 링크가 되는 셈입니다. 지식KIN에 대한 링크를 엠파스가 제공한다고 불만인데, 블로그에 대한 링크를 제공하는 다른 사이트들은 괜찮은가요? :)

좀 다른 웃긴 것을 생각해보죠.
저작권을 지켜야하는 이유는 무엇일까요? 지적 "재산권"을 보호하기 위해서입니다. 좀더 줄여보자면 "재산권의 침해"를 막기 위해서입니다. 그러므로 저작권 침해의 주요 판단 요인은 "(미래를 포함한)재산권"이 침해되었느냐 아니냐입니다.
엠파스가 열린 검색을 시작했습니다. 재미있는 것은 열린 검색에 포함되는 바람에 덩달아 다른 포털들의 트래픽이 증가했다는 점입니다. 단순히 트래픽에 따른 광고수익만 생각해본다면... 다른 포털들은 엠파스에 커미션을 줘야할 판입니다. 트래픽 늘려줘서 고맙다고. 과연 "재산을 늘려주는 재산권 침해"라는 개념이 성립할 수 있을까요?
?? 혹시 트래픽은 증가했지만 수익은 안늘었나요?? 트래픽이 증가해도 수익이 안는다니, 도대체 그 포털의 수익 모델은 무엇? 아니, 그럼 지금까지 노출당/클릭당 광고비 받아먹은 것은 무엇????

하나만 더.
한동안 CCL(Creative Common License)을 다는 것이 유행이었지요. 그런데 CCL의 본래 취지에 대해서 다들 한번씩 생각해보셨습니까? CCL은 "금지"를 위한 약속이 아니라, "최소한의 조건으로도 허용가능"을 위한 약속입니다. CCL을 다는 것이란 "불펌 금지", "영리적 목적 금지", "허가를 받으시오".. 라는 뜻이 아니라, "(몇가지 조건만 지켜준다면) 마음대로 가져다 쓰세요."라는 것을 위한 겁니다. CCL이 없어도 여러분의 저작권은 이미 법으로 충분히 지켜지고 있답니다. 기존의 저작권의 개념하에서는 "조건부허용"이라는 개념이 없기 때문에, CCL이 그것을 보완하고자 하는 것이죠. 이해하시겠나요? CCL은 "금지"를 위한 딱지가 아니라 "허용"을 위한 딱지입니다.

에고.. 무지막지하게 길어졌네요.

결론은 뭐, 이런 겁니다.

1. RSS는 "공개"를 목적으로 합니다. "공개"에 제약을 걸지 마세요.
2. 현재의 저작권법은 "전송권자"의 이득을 보장할 뿐, "창작자"의 이득에는 별 도움이 못된다. (어째서 결론이 이걸로 점프하는 거냣!!)
3. 시대착오적 저작권법은 온라인의 특성을 전혀 이해하지 못하고 있다.
4. 웹상에서의 언론/출판/표현의 자유를 보장해야한다.

누군가 총대매고 위헌소송이라도 걸어야하지 않을까 진지하게 희망중입니다.