* SWEETIER님의 말씀도 있고 해서 겸사겸사 예전에 쓰다가 쳐박아두었던 글을 다시 꺼내 먼지를 털어봅니다.
저같은 경우, 웹표준에 대해 이야기하는 이유는, “필요에 의해”라고 할 수 있겠습니다. 그러니까, 솔직하게 까놓고 말하자면 “장애인 등의 사회적 약자를 위해…” 라든가, “평등한 정보의 이용…”, “비용 절감…” 같은 거창한 이유는 아니라는 거지요. 물론, 강연이나 교육을 나가면 저런 이유를 전면에 내세우긴 합니다만.
사실, 그래요. 남한테 종용할 이유가 없는 거에요. 웹표준의 여러 이점들, 그거 남들은 모르고 아는 사람들만 아는 채로 지나가도 상관없는 거에요. 오히려 남들이 모르고 우리만 알면 더 좋지요.
남들 밤새 야근하고 삽질하면서도 불편한 줄 조차 모를 때, 우리는 시간과 비용 절감하고 더 편하게 작업하면 우리 몸값도 올라가고 더 좋은 일이지요. 뭐라고 남한테 욕들어가며 그거 전도하고 다니고 싶겠어요. 천국은 우리만 가면 되는건데요. ^^;
그럼에도 불구하고 다른 이들에게 표준을 준수하라고 떠들고 다니는 이유는…
남들이 만든 사이트가 엉망이라서 정작 내가 써야할 때 불편하기 때문입니다.
간단한(?) 예를 들어볼까요.
RSS 리더기(웹 리더기 말구요…)나 요즘의 똑똑한 브라우저들은 사이트에 접속하면 알아서 이 사이트의 RSS를 추가할거냐고 물어봅니다. 그러니까, 귀찮게 “페이지내에서 RSS딱지 찾아서 오른쪽 클릭해서 주소복사해서 내 RSS 리더기에 새 RSS 추가선택해서 복사한 거 붙여넣”을 필요가 없는거지요.
이게 가능한 이유는 HTML문서의 head안에 들어있는 link 정보에 RSS주소가 포함되어 있기 때문이지요.
RSS딱지를 어디에 어떻게 이쁘게 붙일까를 고민하는 것 보다, head에 link 한 줄 추가해주는 게 사용자에게는 더 편리함을 주는 거에요.
트랙백의 경우도 마찬가지지요. Trackback RDF가 포함된 문서는 굳이 trackback 주소를 찾아서 복사해 붙이는 번거로운 짓 대신, 문서의 URL만 적어주면 자동으로 Trackback 주소를 찾아 줄 수 있어요. 국내 블로그에는 대부분 안되는 거지만 말이지요.
FF를 쓰고, WP나 MT로 블로깅을 하다보니 당장 위 두가지 기능이 안되는 국내 블로고스피어를 돌아다니는게 여간 불편한 게 아니지요.
위의 두가지 예 모두 시맨틱웹을 위한 온톨로지가 적용된 케이스라고 할 수 있어요.
시맨틱웹이 별게 아니에요. 사용자에게 좀 더 편리한 컴퓨팅을 하게 해주려는게 시맨틱웹의 궁극적 목적이잖아요. 무슨 미사여구를 붙이던 간에, 결국 목적은, 나 손하나 까딱 안하고 편하게 살고 싶다는 거지요.
다음같은 시나리오를 생각해보세요.
오랜만에 친구의 블로그에 방문했더니, 이 친구가 결혼한다고 청첩장을 올렸더라구요. 꼭 가야지 생각하면서 여러분은 어떻게 하시나요?
옛날같으면, 일단 이 페이지를 프린터로 출력하든가…
(그런데 꼭 출력한 인쇄물을 어디다 쳐박았는지 까먹곤 하지요.)
책상을 뒤적여서 포스트잇과 펜을 찾아 열심히 적어서 모니터에 붙여놓죠.
(여기 붙어 있던 포스트잇 누가 치웠어??)
조금 꼼꼼한 사람이라면 프랭클린 플래너를 열어 해당 날짜에 자세한 사항을 기록해두기도 하구요.
(그런데 움베르토 에코의 말처럼 해당하는 날짜에 다이어리를 펼쳐서 약속을 확인해봐야 한다는 걸 까먹으면 어떡하지요?)
나름 컴퓨터와 친하다는 사람은 아웃룩을 열고 일정에 자세한 내용을 타이핑하지요.
(oops! 오타! 18일을 28일로 잘못 쳤네!!)
만약 친구가 시맨틱웹을 지향하는 마이크로포맷 사용자라면, 자신의 결혼 청첩장을 hCalendar 형식으로 만들어 올렸을 겁니다. 자신의 결혼 후 바뀌는 주소는 hCard 형식으로 올렸을 테구요.
그럼 내가 할 일은 브라우저의 버튼 하나를 누르는 것 뿐. 그러면 자동으로 내 일정관리 프로그램에 결혼일정이 추가되고, 내 주소록에 친구의 주소가 신혼집 주소로 변경되지요.
별로 먼 훗날의 상상도 아닙니다. 당장 Windows Vista에 포함되는 기능이고, FireFox같은 브라우저의 확장플러그인으로 이미 있는 기능이지요.
그러니까, 저는 이렇게 게으르게 살고 싶은 거에요. 헌데 게으르게 살기에는 환경이 너무 안받쳐주니까 몸이 다는 거지요. 시맨틱웹은 감히 바라지도 못한 채 그 최소조건인 웹표준부터 이야기하고 있는 이유입니다. 말하자면, 내 한 몸 편하자고, 다른 이들에게 표준을 지키라고 떠드는 것인 셈이지요. ^_^
“표준”이 강제력이 있는 것은 절대 아니지만, 표준을 지키는 것과 비켜가는 것은 시작은 비슷해도 종래에는 제법 그 사이가 벌어지게 됩니다. 표준이 표준인 이유는, 그게 더 많은 사람이 사용해서도 아니고, 더 편하기 때문도 아니지요. 표준이 표준인 이유는 “당위성”과 “보편성”에 있다고 봐야합니다. 즉, 표준인 이유는 “누가 해도 옳게 할 수 있기 때문에”라는 것이지요. (비표준이 틀렸다는 것은 아니고…)
표준을 지키는 것이 더 불편하거나 귀찮더라도 종국에는 더 이득입니다. 비록 초기에는 비표준쪽이 더 이익인 것처럼 보이긴 해도 말이지요.
사례 1: 올블로그의 태그 수집
RSS의 content:encoded는 기본이 아닙니다. 또한 description은 entity처리된 plain text만 사용하도록 되어있지요. 이것을 무시하고, RSS에서 tag정보를 강제로 넣기 위해 a 태그를 이용하려다 보니, content:encoded를 조장(?)하거나, description에 entity처리되지 않은 a 태그를 포함하도록 유도하는 경우가 있습니다.
애초에, notifying 이라는 RSS의 속성을 생각한다면, 컨텐트 안의 tag 정보가 필요하다면, 갱신된 RSS의 item의 url정보를 참조하여 웹페이지를 크롤링해서 필요한 정보(여기에서는 tag)를 다시 가져오는 것이 맞습니다. tag뿐만이 아니죠. image나 멀티미디어의 경우에도 마찬가지. 그런 정보를 모으기 위해 RSS에 해당데이터를 추가하게 하는 것이 아니라, RSS는 표준대로 두고 봇이 해당 웹페이지에 정보를 수집하러 다녀오는 것이 맞습니다.
사실, 이건 올블의 잘못이 아니죠. RSS를 이상한 형태로 제공하고 있는 많은 블로그 메이커들이 문제의 시발점이긴 합니다. 그러나 비표준적인 스펙에 의존하는 서비스는, 예외를 위한 예외를 처리하다보면 점점 더 표준에서 멀어지게 되지요.
사례 2: TT의 태그 출력
애초에 tag플러그인이나 스킨 제작자들의 문제였겠습니다만. 최소한 tag라는 표현을 쓰고 상식적인(아, 그냥 우리끼리의 ‘상식’은 말구요.) 용법을 사용하려면 microformat의 tag 용법 정도는 준수했어야했을 것입니다.
물론, 다중카테고리와 tag자체를 구별할 수 없는 현재의 용도하에서 TT쪽에서 스킨제작자나 플러그인 제작자에게 표준을 강제하는 것은 어려운 일이었겠습니다만… 어쨌거나 이 역시 microformat - tag라는 표준을 간과한 결과겠지요.
덕분에, tag라는 이름을 붙인 기능을 쓰면서도 실질적으로 tag가 아닐 뿐더러, 그 문제점을 스킨이나 플러그인 제작자에게 떠넘긴 셈이 되었습니다. 애초에 스킨이나 플러그인 제작자보다 메이커가 더 이런 문제에 대해 잘 알고 책임을 져야할텐데, 너무 자유도를 강조한 나머지 메이커보다 문외한일 3rd party들에게 맡기는 것은 조금 안일하지 않나 싶습니다. MT나 WP처럼 아예 tag는 원래기능에는 포함되지 않음을 확실히 했어야했지요. 현재 tag는 TT에서는 책임지지 않으면서도 TT의 핵심기능 중의 하나인 셈이니 이러한 부분에서 문제가 발생하면 책임소재가 애매해지겠습니다.
각각의 사례는 사실 단독적으로는 별 문제가 없었겠습니다만, 두가지 비표준 사례가 만나다보니 문제가 커지고 서로가 잘못했다는 감정싸움이 되는 듯 하더군요. 뭐랄까, 이전부터 RSS나 microformat에 관해 이야기 해왔던 입장에서 본다면 안타깝다고나 할까요.
표준이 표준이 되기 위해서는 나름 많은 고민과 많은 시행착오를 거쳐야만 합니다. 최소한 한두명의 개발자나 한두개의 기업에서 나름 뚝딱해서 만들어지는 것은 아니라는 것이지요. 표준이라는 딱지를 얻었을 때에는 그만한 이유와 까닭이 있기 때문입니다. 눈 앞의 이익에 혹해 비표준을 용인하는 것은 우선 경계해야할 일이겠습니다.
추가:바람직한 해결책
1. TT에서 사용하는 기능이, ‘tag’라면 TT측에서 직접 microformat을 준수할 수 있도록 책임진다. 단, RSS에 추가할 필요는 없다.
1-1. ‘tag’가 아니라 멀티카테고리에 불과하다면 지금까지 처럼 3rd party의 플러그인이나 스킨제작자에게 맡긴다.
2. 올블에서는 RSS에 담긴 내용만으로 정보를 수집하는 대신, RSS로 notifying된 url을 찾아가 screen scrapping을 통해 필요한 정보들을 획득해간다.
생각해볼 문제 :
screen scrapping은 죄악인가? 그렇지 않다.
정상적인 RSS 스펙을 해석한다면, 정확히 ‘새 글이 등록되거나 수정되었을 때에만’ 해당 페이지의 screen scrapping을 시도하게 할 수 있다. 원래 RSS의 스펙 자체가, RSS를 컨텐트의 용도로 사용함이 아니라, URL에 대한 notifying용임을 상기하자. 따라서 해당 URL에 대한 정보가 필요하다면 필연적으로 machine-crawling이 필수이며, 이에 대한 방문빈도 등을 제어하기 위한 규격이 이미 RSS내에 존재하고 있다.
단지 봇이 긁어가는 것에 대해 알레르기를 느낀다는 것은, 글쎄, 사용자가 그리 느낀다는데 뭐라 말하기는 그렇지만 잘못된 생각일 뿐이다. 장차 사용될 마이크로포맷이니 시맨틱웹이니 하는 것들은 로봇과 스크래퍼 들을 가정하지 않으면 애초에 성립되지 않는 개념들이다. 그 때가 되면 정말 웹페이지를 샅샅이 뒤지고 긁어서 조그마한 의미 하나라도 기계들이 긁어갈 차에, 봇이 긁어가는 것이 싫어서… 라는 핑계는 러다이트의 재현일 뿐.
무분별하게 긁어가는 것은 트래픽상 문제가 될 수 있긴 하지만, 그걸 막기 위해 RSS에 해당하는 스펙이 있지 않던가. 그것만 따라줘도 충분히 트래픽에 대한 문제는 해결된다.
최근 liquid 또는 elastic design 에 대한 관심들이 많아지고 있는데요,
개인적으로 liquid나 elastic design의 유용함을 인정하면서도 실제 현장에서 쓰기에는 힘들지 않나.. 하는 생각을 하고 있었습니다.
여러가지 이유가 있겠으나, 하나의 디자인으로 여러 종류의 디바이스 혹은 브라우저 크기에 맞춰 유동적으로 변하는게 그리 쉽지많은 않거든요. 아무리 빗겨흘리고 늘렸다 줄였다 해도 고정된 디자인의 한계를 벗어나기는 어렵더군요.
그런 생각을 하면서 요즘의 liquid, elastic 유행(?)에 한발 물러서 있던 차에…
오래간만에 ALA에 괜찮은 기법이 하나 소개되었습니다. liquid 또는 elastic 의 한계를 뛰어넘은, 가변폭에 맞춘 디자인 변경입니다.
간단하게 js 파일을 하나 추가함으로써 어떠한 환경에서도 보기 좋은 웹페이지를 만들어낼 수 있겠더군요. 물론 주의깊게 작성을 하긴 해야겠습니다만.
그동안 어떻게 CSS를 조작해서 가변폭 레이아웃을 만족스럽게 표현할까 고민했었는데 좋은 참고가 될 듯 해서 소개합니다.
liquid 디자인과 zoom 디자인을 넘어서 adaptive 레이아웃이라는 선언도 곱씹어볼만 한데다, 샘플 2에 Tab 디자인은 영감을 팍팍주는 인터페이스네요. 그동안 ALA에 올라오는 글들이 영양가가 좀 떨어지지 않나 싶었는데 이번엔 아주 Two Thumbs Up!입니다.
I. 일단 정리.
1) CCL(Creative Common License)은 무단펌질을 막아주는 부적, 마법의 딱지가 아니다.
2) CCL은 저작권을 보호(좁은 의미로, 펌질금지)한다기 보다는, 합법적으로 사용권을 주기 위한 방법이다.
- 부연 : CCL을 붙이건 말건, 무조건 개인의 창조적 작업의 결과물인 컨텐트는 그 저작권을 보호받는다. 그러다보니, 저작자가 선의로 공유를 하고 싶어도 무조건 저작권을 지키든가, 포기하든가 양자 택일만 가능하므로, 좀 더 합법적으로 컨텐트를 사용할 수 있다는 ‘선언’이다.
II. 사용자는 사악???
그러니까, CCL을 붙여놨으니까 나는 안심. 이건 정말 순진한 이야기. CC가 뭔지 모르는 사람들이 이 세상의 99%. 아마도 IE사용자보다도 많을 걸?
어쨌거나 이미지 딱지 하나 붙여놓았다고 맘 푹놓고 있다가 누가 불펌(?)해갔다고 길길이 날뛰어봤자 소잃고 외양간 고치는 격.
사용자는 CC가 뭔지도 모르고, 이해하지도 못한다. 아무리 친절히 설명해준다 하더라도. 게다가 페이지 어디에 CC가 붙어 있는지 알지도 못하고. 또 웹페이지에 붙어 있는 CC는 애매한 면이 있어서, 페이지 전체가 CC의 영향을 받는다는 건지, 특정 컨텐트가 CC의 영향을 받는 건지…
사용자에게 너무 많은 것을 기대하지 말 것.
III. 올바르게 CC 붙이기.
CC는 그냥 이미지 딱지만 붙여 놓는다고 되는게 아니다. 붙이는 것도 다 규칙이 있고, 표준이 있는 법. 올바르게 붙어있지 않은 CC는 아무 의미도 없다.
