이바닥이 원래 그래
EBADAC - OOPARTS : Out Of Place Articles.
Archive for January, 2007
January 12, 2007 at 3:53 pm · Filed under WebPlan, WebStandard
* 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같은 브라우저의 확장플러그인으로 이미 있는 기능이지요.
그러니까, 저는 이렇게 게으르게 살고 싶은 거에요. 헌데 게으르게 살기에는 환경이 너무 안받쳐주니까 몸이 다는 거지요. 시맨틱웹은 감히 바라지도 못한 채 그 최소조건인 웹표준부터 이야기하고 있는 이유입니다. 말하자면, 내 한 몸 편하자고, 다른 이들에게 표준을 지키라고 떠드는 것인 셈이지요. ^_^
January 11, 2007 at 7:04 pm · Filed under WebDevelopment, WebPlan, WebStandard
Role
SiteA : openID를 지원하는 Consumer 서비스. openID 소유자에게 서비스 이용을 허용한다.
SiteB : openID를 제공하는 Provider 서비스. 회원에게 openID를 발급하고 인증해준다.
홍길동 : SiteB에서 발급한 openID를 소지하고 있는 개인. 이 openID를 URLX에 적어두었다. SiteA의 서비스를 이용하고자 한다.
URLX : 홍길동의 개인(블로그 등) 페이지. openID가 적혀있다.
1. 홍길동은 SiteA에 방문한 후, openID를 지원함을 알고, 입력 Form에 자신의 openID URL인 URLX를 입력한다.
2. SiteA는 주어진 URLX에서 openID 정보를 찾는다.
3. SiteA는 홍길동의 openID가 SiteB의 것임을 알고, SiteB에 openID 인증을 요청한다.(SiteB로 리다이렉팅)
3-1. SiteB와의 연결에 문제가 발생할 경우, 해당 에러를 띄워 홍길동이 문제를 해결할 수 있도록 한다.
4. SiteB는 홍길동의 브라우저에, SiteA로부터의 인증요청이 있음을 알리는 페이지를 띄우고 인증허가여부를 묻는다.
4-1. SiteB는 홍길동이 본인임을 확인하기 위해 또다른 인증(예:로그인, 비밀번호입력)을 요구할 수 있다.
5. 홍길동은 SiteB로 하여금 SiteA에 자신의 정보를 가져가도록 허가한다.
5-1. 또는 홍길동은 SiteB로 하여금 SiteA로의 정보제공을 거부할 수도 있다. (부적절한 요청, 도용 가능성 등)
5-2. 또는 홍길동은 SiteB로 하여금 SiteA로의 정보를 제한적으로 제공하도록 선택할 수도 있다.
6. SiteB는 SiteA에 홍길동의 정보를 제공하고, SiteA의 페이지로 리다이렉팅한다.
6-1. 또는 SiteB는 SiteA에 홍길동의 정보를 제공할 수 없음을 알리고 SiteA의 페이지로 리다이렉팅한다.
7. SiteA는 SiteB로부터 받은 정보를 바탕으로 홍길동이 서비스를 사용할 수 있도록 처리해준다.
—-
시나리오로 적으면 별 것도 아닌 것 같은데, 왜 이리 에러가 많은거야.. 징징.
January 11, 2007 at 3:33 pm · Filed under WebDevelopment, WebPlan
가정 1.
내 블로그를 방문하는 사람은 ‘나’에 대해 관심있기 때문이다.
가정 2.
‘나’에게 좋은 것은, 내 블로그를 방문하는 사람에게도 좋다.
두가지 가정은 모두 사실이 아니다.
블로그 주인에게 블로그란, ‘자신’에 대한 표현수단이겠지만, 블로그를 방문하는 사람은 사실, 블로거 자체에는 관심이 없다.
그들이 관심있는 것은 Topic일뿐.
블로그 방문자들이 방문한 블로그의 모든 글을 읽기를 기대할 수도 없다. 애초에, 블로그란 형식 자체가 post단위의 archiving/logging이기 때문에, archive(또는 post)는 그 자체로 자기완결되어야만 한다.(물론 어려운 일이다.)
대개의 방문자는 링크를 타고 들어와 그 하나의 포스트를 읽고, 나가버린다. 아주 가끔, 댓글을 단다거나 하는 예외를 제외하곤.
그렇다면 방문자들을 위해 가장 필요한 인터페이스는 무엇일까?
두가지 층위에서 바라볼 수 있는데, inbound entry와 outbound exit 층위가 그것. 들어오는 방문자와, 나가는 방문자를 위한 인터페이스.
‘블로그 내 검색’은 방문자를 가장 손쉽게 유혹할 수 있는 인터페이스라 할 수 있다. 방문자들은 카테고리 메뉴를 애용하지 않는다. 일일이 카테고리를 찍어보고, 포스트 목록에서 자신이 관심있어할 글 제목을 찾는 것은 매우 귀찮은 일이기 때문이다. 만약 방문자가 이 블로그에서 무언가 정보를 더 얻기를 원한다면 검색창에 바로 쳐넣고 결과가 뜨기를 기다릴 것이다.
따라서 블로그의 검색기능은 방문자를 위한 가장 훌륭한 인터페이스이다.
‘관련글’ - 수동으로 만들었거나, 혹은 FullText Search를 통한 자동 연결이거나 - 을 제공하는 것도 좋다. ‘연예뉴스’를 보러 들어온 방문자에게 관련된 다른 글들을 보여주는 것은 방문자들이 수고스럽게 일일이 뒤져보거나 검색할 필요를 줄여주는 친절한 인터페이스라 할 수 있다.
한가지 더 추가한다면,
referer를 통해, 검색엔진으로부터 유입된 방문자에게 자신이 보려고 했던 컨텐트를 바로 보여주는 것이다. 어떤 방문자가 검색엔진으로부터 ‘Ajax’라는 키워드를 찾아 블로그로 유입되었다면, 그는 아마도 내 블로그의 다른 ‘Ajax’관련 글에도 관심이 있을 것이다. 어쩌면, 검색엔진에 노출된 페이지보다, 숨겨진 페이지 쪽에 더 유용한 정보가 있을 수도 있다. 그런 경우 검색엔진으로부터 들어온 사용자에게 해당 엔트리들을 자동으로 보여준다면 얼마나 유용할까. (물론 이러한 기능들은 이미 많은 곳에서 구현되어 있고, 예를 들어 방금 말한 기능같은 것은 wp 플러그인으로 있어서 내 블로그에도 붙여놓았다. google에서 ‘불친절한 금자씨’로 검색해보시라.)
현재까지 블로그 인터페이스는 블로그 주인을 위한 자기만족적 성격이 강하다. 그러나 방문자로서는 스킨이 드래그 앤 드롭으로 변경되든, BGM이 있든 말든, 주인장 맘대로 태그로 뭘 붙이든 신경쓰지 않는다. (방문자 맘대로 리모콘 조작이 가능하다면야 또 모를까.) 그런 블로그 주인의 자기만족적 인터페이스보다는, 방문자를 위한 배려가 더 좋은 인터페이스일텐데, 이런 것들이 아직도 많이 미비한 듯 하여 아쉽다. (심지어 내 블로그 조차도.)
January 11, 2007 at 1:38 pm · Filed under WorldWideWoops
WP로 새 블로그를 연지 100번째 포스트.
애초에 목표했던 웹 테크니컬 아티클을 게재하는 것을 얼마나 잘 수행하고 있는지 의문이 드는 요즘.
요즘.. 하니까, 생각난 건데, eouia는 ‘인간지능 검색엔진’입니다. 네이버 지식인처럼 애용해주세요. 
가깝게는 집사람부터 멀리는 커뮤니티의 Q&A란까지.
특히 종종 아주 고난도의 어려운 것들을 메신저로 물어보시는 모님이라든가… ㅎㅎ
그렇다고, “도쿄 맛집”이라든가, “노무현 이후의 정세 예측”이라든가, “대박날 주식종목”같은 건 물어봐도 모릅니다. ㅋ
여튼, 100번째 포스트는 이렇게 얼렁뚱땅 찍고, 다음부터는 좀 더 알맹이 있는 포스트로. ^.,^
(제법 바쁜 척 하느라 요즘 포스트가 영양가가 적어졌습니다. 반성하는 척 올리는 포스트였습니다.)
January 9, 2007 at 5:10 pm · Filed under WorldWideWoops
광고입니다.
지원하러 가기
설명이 조금 필요한 듯 하여.
—
Seoul R&D 센터 연구개발자 모집요강
1. 채용부문: 연구 개발자 0명, 서울에서 근무.
필수요건
- 해외여행에 결격사유가 없으신 분.
(해외 출장이 있을 수 있습니다. 해외근무를 희망하시는 분은 취업비자 발급이 가능해야 합니다.)
- 영어 기술문서 독해가 가능하신 분.
(나름 최근 기술트렌드를 따르기 때문에 아직 한글화된 자료들이 거의 없어 영문 자료를 참고해야 합니다. 매뉴얼이나 도큐먼트 해석이 가능한 수준이시면 됩니다.)
- LAMP 환경에서 무리 없이 개발 가능하신 분. (vi 등)
(꼭, LAMP만 고집하는 건 아닙니다만…)
우대요건
- PHP5 또는 OOP(Java/C++등) 가능
- Ruby, RoR, Perl, Python 중 하나 이상 가능
- 영어 Communication 가능 (영어 외의 일어/중국어 능력자 환영)
- RDBMS 경험 (MySQL의 innoDB 또는 Oracle, PostgreSQL 등)
- Agile/XP에 대한 이해
- 표준기술 (웹표준, ECMA, 기타 de facto표준들 등)에 대한 이해
- 웹트랜드를 예측하고 그에 필요한 기반기술을 습득할 수 있는 능력
- LAMP환경의 설치, 운용이 가능
—
필수요건만 중요합니다. 우대요건은 그저 우대사항일뿐.
아쉽게도 외국회사인지라 아직 병특은 불가하고 대신 해외근무나 출장이 있으므로 여권이나 비자(해외근무시)에 문제없으신 분들이 지원하셨으면 합니다.
January 7, 2007 at 3:39 am · Filed under WebDevelopment, WebPlan
Ajax가 유행이 되면서 너나 없이 Ajax를 이용한 사이트를 제작하게 된다. 그런데 곰곰히 생각해보면 Ajax의 이용은 현재까지 웹비즈니스모델의 가장 큰 부분을 차지하는 광고시장에 많은 영향을 주게 됨을 알 수 있다.
1. 광고 노출의 약화
특히 Ajax로 메인 컨텐트 부분을 처리하는 사이트들의 경우, page reloading이 일어나지 않기 때문에 reload 처리를 고려하지 않은 광고기법을 사용한다면 유저당 광고노출회수가 줄게 된다.
가령, 이전에는 사용자가 평균 10페이지의 액션을 취하고, 각 페이지마다 2개씩의 광고가 붙어 있던 사이트라면, 사용자당 20개의 광고를 노출시킬 수 있었다.
그러나 Ajax로 메인 컨텐트를 처리하면서 page reloading이 일어나지 않게 사이트를 변경하고 나면, 한 명의 사용자에게 고작 2개의 광고만 노출시킬 수 있을 뿐이다.
2. 광고 overloading - 트래픽 낭비
위와 같은 문제를 해결하기 위해 사용자의 Ajax 액션 때마다 광고를 같이 갱신하려한다면 이번에는 기껏 Ajax로 절약(?)한 트래픽을 낭비하게 된다. 액션 때마다 광고까지 포함해 전체페이지를 뒤엎는다면 Ajax를 쓸 필요가 없지 않은가.
3. 광고 changing - 트래픽 낭비
사용자의 액션과는 상관없이 일정주기로 광고를 갱신하는 방법을 쓸 수도 있다. 그러나 이 경우에도 사용자가 실제로 현재 페이지를 보고 있지 않는 동안에도 광고가 갱신되는 트래픽 낭비를 일으키며, 광고주에게 그 비용을 전가하는 단점이 있다.
너무 늦게 갱신된다면 Ajax를 쓰기 전보다 광고효과가 떨어지고, 너무 자주 갱신된다면 광고주에게 광고노출비용을 효과보다 더 부담하게 만든다.
4. PV와 UV, CV
무엇보다도, PV가 무색해지면서 광고단가에 대한 산정이 어려워지는 문제가 발생한다. UV가 아무리 많다해도 광고주들은 PV가 높은 매체를 선호하고, 광고 단가를 높게 지불한다.
그런데 Ajax를 사용하게 되면 사용자가 10분간 열심히 충성스럽게 사용한다 해도 해당 사용자의 PV는 1일 뿐이다. Ajax 서버측에 기록된 로그를 공개하면 사용자의 액션을 객관적으로(?) 증명할 수도 있겠지만, 광고주들이 매체의 공개된 로그를 신뢰할리 만무. 결국 컨텐트마다 추적코드를 삽입해서 ContentView를 측정하는 방법뿐인데, 이에 대해 신뢰할 수 있는 분석도구나 어필레이트 프로그램은 현재 없다. 서로 다른 형태와 위상을 가지고 있는 Content의 정량적 측정자체가 불가능하므로.
결국 광고서버에서 직접 노출횟수를 세는 방법뿐인데, 이를 위해 Ajax로딩때마다 광고를 갱신해야하면 다시 2번째 문제점으로 돌아갈 뿐.
5. 문맥광고 빠져나가기
현재까지는 가장 진보된 형태라고 불리우는 AdSense등의 문맥광고는 호출 당시의 HTML 컨텐트만을 문맥파악 대상으로 할 뿐, Ajax로 변경된 컨텐트는 인지하지 못한다.
컨텍스트와 일치하는 광고를 뽑아주는 것을 장점으로 하는 문맥광고가 그 역할을 하지 못한다면 과연 광고효과가 있을까?
이를 해결하기 위해서는 문맥광고에 컨텍스트 변경이 있을 때마다 push방식의 재갱신 요청을 처리하는 부분이 추가되거나(웹에서 push는 구현이 쉽지 않다.) 혹은, 문맥광고 자체에서 일정시간마다 pull방식으로 컨텍스트를 다시 읽어와 광고갱신여부를 선택하는 방법이 있을 수 있겠다. 그렇다고는 해도 이는 google등에서 해결해야할 문제이며, 매체측에서는 손가락만 빨고 있을 뿐.
…
개발자들이야 Ajax를 쓰는 것을 마다할 리 없고, 기획자들이야 왠지 좋아보여서라도 Ajax를 붙이겠지만…
사이트의 영업담당자들은 Ajax로 인해 변한 광고시장에 머리 좀 아플 듯.
근데, 이런 이야기를 회의때 안하나??
January 5, 2007 at 2:06 am · Filed under WorldWideWoops
조금 의외인 것은, 블로고스피어에 네이버의 이번 시즌 2 에피소드 1에 대한 칭찬들이 자자하다는 것.
이미 알고 있겠지만, 이 리모콘이란 용어와 기능은 사실상 1년도 전에 엠파스 블로그에서 써먹었던 것이고, 네이버에서 에피소드 1이라는 이름으로 내놓으면서 엠파스의 그것보다 기술적으로 특별히 진보적이거나 개념적으로 뭔가 더 창의적인 부분이 생긴 것도 아니다.
‘따라했다’는 것 자체가 비난의 대상이 될 이유는 없겠지만, 그렇다고 ‘칭찬’의 이유가 된다는 것은 뭔가 이상하지 않은가?
남은 에피소드들 역시 모두 이미 다른 곳에서 했던 그대로 - 벤치마킹을 넘어서 사실상 표절이라고 표현해도 무방할 정도인데 왜 이렇게 다들 갑자기 호의적이 된 것일까?
역시 포장하는 법과 홍보하는 법이 한국IT 비즈니스의 핵심 역량이 되는 걸까?
거창한 수사를 붙이면 단지 인턴을 뽑을 뿐인데도 엄청난 경쟁률을 보이는 회사가 있는 한편, 쓸만한 인재하나 뽑기가 어려운 회사도 있고…
적절한 명예심과 자존심을 간질여주며 저렴한 가격으로 개발자풀을 돌리는 회사도 있고…
컨퍼런스나 세미나에 참석해서 말만으로 때우는 회사도 있고…
괜찮은 홍보이사를 잡는 쪽이 괜찮은 개발이사를 잡는 쪽보다 성공가능성이 더 높아지는 요즘. 재밌는걸?
January 4, 2007 at 10:25 pm · Filed under WebDevelopment, WebPlan, WebStandard
“표준”이 강제력이 있는 것은 절대 아니지만, 표준을 지키는 것과 비켜가는 것은 시작은 비슷해도 종래에는 제법 그 사이가 벌어지게 됩니다. 표준이 표준인 이유는, 그게 더 많은 사람이 사용해서도 아니고, 더 편하기 때문도 아니지요. 표준이 표준인 이유는 “당위성”과 “보편성”에 있다고 봐야합니다. 즉, 표준인 이유는 “누가 해도 옳게 할 수 있기 때문에”라는 것이지요. (비표준이 틀렸다는 것은 아니고…)
표준을 지키는 것이 더 불편하거나 귀찮더라도 종국에는 더 이득입니다. 비록 초기에는 비표준쪽이 더 이익인 것처럼 보이긴 해도 말이지요.
사례 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에 해당하는 스펙이 있지 않던가. 그것만 따라줘도 충분히 트래픽에 대한 문제는 해결된다.
January 3, 2007 at 12:07 pm · Filed under WebPlan, WorldWideWoops
그런데, 블로그 리모콘 이란 건 엠파스에서 벌써 일년전에 내놓았던 기능 아니었나?
네이버가 대대적으로 광고하면서 내놓기에는 좀 부끄러운 것 아닌지?
지금 보니 기능도 컨셉도 엠파스 것과 완전 동일, 이정도면 같은 개발자… 또는 같은 기획자가 참여하고 있는 것이라는 의심이…
아무튼 간에. Attention의 차이가 네이버와 엠파스가 확연할 테니, 엠파스로서는 또 손가락만 빨면서 억울함을 곱씹을지도.
(그렇다 해도, SK에 인수된 엠파스가 진심으로 억울해 할지는 미지수. 별 상관없으려나?)
« Previous entries