표준을 간과한 댓가

“표준”이 강제력이 있는 것은 절대 아니지만, 표준을 지키는 것과 비켜가는 것은 시작은 비슷해도 종래에는 제법 그 사이가 벌어지게 됩니다. 표준이 표준인 이유는, 그게 더 많은 사람이 사용해서도 아니고, 더 편하기 때문도 아니지요. 표준이 표준인 이유는 “당위성”과 “보편성”에 있다고 봐야합니다. 즉, 표준인 이유는 “누가 해도 옳게 할 수 있기 때문에”라는 것이지요. (비표준이 틀렸다는 것은 아니고…)

표준을 지키는 것이 더 불편하거나 귀찮더라도 종국에는 더 이득입니다. 비록 초기에는 비표준쪽이 더 이익인 것처럼 보이긴 해도 말이지요.

사례 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에 해당하는 스펙이 있지 않던가. 그것만 따라줘도 충분히 트래픽에 대한 문제는 해결된다.