이바닥이 원래 그래
EBADAC - OOPARTS : Out Of Place Articles.
Archive for November, 2006
November 29, 2006 at 8:49 pm · Filed under WebDevelopment, WebPlan
Code Complete를 읽다가 재미있는 문구를 발견했는데, 기존에 알고 있던 상식과는 달라 잠이 확 깼다.
요약하자면 다음과 같다.
디버깅과 리팩토링, 그리고 다른 수정 작업이 전형적인 소프트웨어 개발 주기에서 약 50% 정도의 시간을 차지한다. 오류를 예방하여 디버깅을 줄이면 생산성이 향상된다. 따라서 개발일정을 줄이는 가장 확실한 방법은 제품의 품질을 향상시키고 디버깅과 소프트웨어의 수정작업으로 낭비되는 시간을 줄이는 것이다.
뭐, 이부분은 너무나 원론적인 이야기라, “그래서?”라는 반문이 튀어나오게 한다. 그런데 나는 저 문장을 전적으로 이해하고 있었던가?
400 work year 이상의 노력과 3백만줄의 코드를 포함하는 50개의 개발 프로젝트를 검토한, NASA의 소프트웨어 공학연구실의 한 연구에서 품질 보증의 향상이 오류율은 줄여주지만 전체적인 개발 비용에 있어서 추가적인 비용이 들지 않는다는 것을 발견하였다. (Card 1987)
IBM의 연구에서도 이와 유사한 결과를 발견하였다.
결함수준이 매우 낮은 소프트웨어 프로젝트는 개발 일정도 가장 짧고 생산성이 가장 높았다. 소프트웨어 결함 제거가 실제로 소프트웨어 개발에 있어서 가장 많은 비용을 유발하고 가장 많은 시간을 낭비하는 작업형태이다.(Jones 2000)
즉, 가장 좋은 디버깅보다 차라리 결함이 적은 프레임워크가 더 낫다…라는 해석.
아래와 같은 문장도 유심히 볼 내용
… 흥미로운 결과는 프로그램을 완성하기 위해서 평균 시간이 걸린 프로그래머들이 오류가 가장 많은 프로그램을 작성한 것이다. 평균보다 많거나 적게 걸린 프로그래머들은 눈에 띄게 오류가 적은 프로그램을 작성하였다.(DeMarco & Lister 1985)
조금 삐딱한 해석으로는, 어느 수준 이하의 프로그래머들이 평균적인 시간이 걸려 프로그래밍을 한다는 뜻. 다시 말해 특정 수준 이상의 프로그래머라면, 1) 매우 신속하게 문제를 해결하거나, 2) 매우 꼼꼼하게 문제를 해결한다는 뜻… 일 수도 있다.
그런데, 이 조사결과가 보여주는 재미있는 결과는, 시간을 들여 “꼼꼼하게” 해도 신속한 해결방법보다 오류율이 적다는 건 아니라는 뜻. 반대로 해석하면 문제해결 시간은 그 문제의 오류율과는 상관없다는 뜻.
내맘대로 결론은 뭐냐하면, 지금까지 의례적으로 간트 차트에 디버깅이라고 잡아놓았던 시간을 빼버리고 차라리 그 시간만큼 품질보증예방 방법들을 선행하는 것이 더 낫다는 것.
“품질을 향상시키는 것이 개발 비용을 줄이는 일.” <- 요즘 몸으로 실감함.
ps. 기억을 더듬어보니 언젠가 조엘 블로그에서도 비슷한 내용을 본 것 같다. 그때는 그냥 건성으로 지나쳤는데 오늘 보니 새롭군.
November 26, 2006 at 10:34 am · Filed under WebDevelopment, WebStandard
CSS로 작업할 때의 단계적 변화 모습. 다른이에게 예시로 보여주면 교육상 좋을 듯
출처 : http://ajaxian.com/archives/css-evolution
November 25, 2006 at 3:33 am · Filed under WebDevelopment, WebPlan
웹 2.0이 거품스럽다는 우려속에는 여러가지 관점이 있을 수 있겠으나, AJAX만큼이나 Tag 만능주의가 되는 것 또한 상당히 경계할 만하다.
물론 폭소노미로서의 태그에 효용이나 의의가 없을리 없다. 잘 된 태깅은 분명 그만큼의 효과를 돌려준다.
그런데 도대체 잘 된 태깅이란 무엇을 말하는 것일까? 혹은, 태깅을 잘 하려면 무엇이 필요한가?
1. 멀티 카테고리로서의 태그
전에도 말한 바 있으나, 대부분의 사람들은 태그를 멀티카테고리로 인식하고 사용하고 있다. 그런데 애초에 멀티카테고리를 지원하는 WordPress나 MovableType 등에서, 멀티카테고리가 있음에도 태그를 사용한다는 것은 “왜?”라는 근본적인 물음을 안겨준다. 실상 태그 플러그인등을 설치하지 않아도, “태그클라우드 형태”의 리스팅이나 아카이빙은 WP나 MT에서는 조금만 손보면 얼마든지 쉽게 가능하다.
반대로 멀티카테고리를 지원하지 않는 TT등의 경우에는, 그냥 멀티카테고리를 지원하도록 다음 버전에서 내놓는다면 그 즉시 태그의 효용자체가 무의미해진다.
그럼에도 불구하고 태그가 화두가 된다는 뜻은, 즉, 태그는 멀티카테고리 그 이상의 무언가가 있다는 뜻.
2. 인스턴트 카테고리로서의 태그
택소노미와 폭소노미의 가장 큰 차이점 중 하나는, 그루핑-라벨링의 권한이 누구에게 있느냐라는 점이겠다. 편집진 혹은 운영진이 주의깊게 준비한 분류법을 따르느냐, 아니면 개인의 즉흥적이면서 사적인 분류를 택하느냐.(엄밀히 말하자면, 이러한 개인의 분류가 집단으로 모인 것까지를 폭소노미라 한다.)
그런데 블로그란 결국 필자와 편집자(개인용 설치형이라면 운영자까지)가 동일한 법. 필자 자신이 붙이는 태그라는 것이 폭소노미가 될리 만무하다. 바꿔 말하자면, 컨텐트 생산자(재생산 포함)가 붙이는 태그란 집단지성따위와는 전혀 상관없는, 전형적인 택소노미식 분류법의 또다른 모습일 뿐. 유일한 차이라면 즉석에서 이름을 붙일 수 있다는 점 정도? 제로보드등을 사용할 때에는 카테고리 하나를 생성할 때에도 신중하게 심사숙고했었으나, 소위 태그란 시스템하에서는 즉석에서 태그를 결정하는 정도의 차이랄까..
개인 블로그(개인 웹앨범, 개인 mp3관리기 …등)에서의 태그란 즉석 카테고리(또는 즉석-멀티-카테고리)를 좀더 그럴 듯하게 이름붙인 것 뿐.
3. 키워드로서의 태그
종래의 HTML등에도 keyword라는 것이 이미 존재하고 있다. 키워드와 태그는 어떻게 다른가?
결론부터 말하자면, 컨텐트 생산자 입장에서는 키워드나 태그나 그게 그거다.
예를 들어, 이 글의 키워드는 무엇일까?
“태그, tag, 태깅, tagging, 좋은_태그…” 뭐, 이런 거겠지.
그럼 이 글의 태그는?
역시 마찬가지이다.
이렇게 놓고 보면 하등의 차별적 존재가치가 없는게 개인 블로그에서의 태그의 지금까지의 모습.
4. 키워드로서의 태그 -2-
키워드나 태그나 그게 그거인 상황은 텍스트 컨텐트에서는 더욱 극명해진다. 앞서의 예는 좋은 키워드-태그일까?
틀리지는 않았으나 낭비나 다름없다. 왜냐하면, 텍스트 컨텍스트 내에 이미 해당 키워드-태그가 등장하고 있기 때문이다. “역전앞”이라는 것과 마찬가지의 잉여정보.
시맨틱을 파악하기 어려운 비텍스트 컨텍스트에서 키워드-태그는 효용이 꽤 있다. 아직 이미지 분석 기술이 덜 발달했기 때문에, 사진에 “내친구 홍길동, 크리스마스, 싱글파티, 샴페인, 대학로”라는 키워드-태그를 붙여두는 것은 검색과 그루핑을 위한 좋은 라벨링이라 할 수 있다. mp3에 “이효리, 2집, Getya, 댄스곡, K-Pop”이라는 키워드-태그는 곡선곡을 하고 분류를 하는데 좋은 라벨링이다.
허나, 텍스트 위주의 컨텐트에서는 상황이 다르다. “IT”라는 단어를 하나도 안쓰고 IT에 관한 글을 쓰는 경우라면 모를까, 대부분의 경우에는 텍스트 내에 생산자가 붙일 법한 좋은 키워드-태그는 높은 가중치로 등장하기 마련이다. 제목에 들어가 있다거나, 굵은 글씨로 강조되어 있다거나, 여러번 반복된다거나.
5. Flickr
사실상, tag의 본질적 관점에서 보자면, Flickr의 태그시스템은 그다지 좋은 예라고 볼 수 없다. 확실히 사용자에게 편리하긴 하지만 그 점은 4.에서 말한 비텍스트 컨텐트에 대한 즉석-멀티-카테고라이징의 편리함일 뿐, 엄밀히 말해 폭소노미는 아니기 때문이다.
폭소노미는 태그로 구현되지만, 태그 자체가 폭소노미가 되는 것은 아니다.
폭소노미의 핵심은 재정의에 달려있다. del.icio.us의 태그가 Flickr의 태그와 다른 이유이다.
6. “태그를 달아주세요.”
블로그에 한정지어 보자면, 태그가 멀티카테고리에 불과한 현재 상황에서, 태그의 본래 의미를 찾으려면 어찌해야 할까?
확실한 것은, 필자 자신이 하는 태깅은 의미없다는 점. 그건 그냥 멀티카테고라이징일 뿐이니까.
가장 쉽게 생각할 수 있는 것은, 마치 별점 주듯이 독자-방문자가 임의로 태그를 입력하게 하는 방법이다.
그런데 제법 그럴 듯해보이는 이 방법은 실은 가장 멍청한 방법 중 하나이다. 위키도 아닌데 남의 블로그에 딱지를 내 맘대로 붙인다는게 무슨 의미가 있겠는가.
집단지성 맹신파들에게는, 그렇게 한명 한명의 방문자가 재정의해준 라벨링이 다른 방문자들에게 도움이 된다고 하는데, 이들은 가장 중요한 “사용자의 동기”를 간과하는 셈이다.
del.icio.us의 태깅이 효과적인 이유는 그것이 타인에게 도움이 되어서가 아니라, 나 자신에게 바로 도움(내 북마크의 분류)이 되기 때문이다. 일단 그 조건이 만족되어야만, 그러한 개인의 태그들을 모아 폭소노미를 이룰 수 있다.
헌데 del.icio.us같은 “나만의 분류법”이 “타인의 블로그”에서 무슨 소용이 있겠는가. 평생 그 특정 블로그만 끌어안고 산다면 모를까 어리석은 짓이다. 문제는, 이러한 어리석은 짓들이 태그를 이용하는 서비스에 신선한 모델인것마냥 자주 눈에 띄인다는 점. 심지어 구글마저도 이러한 문제점 때문에 태그붙이는 게임까지 만들어야 하지 않았나.
7. “태그를 달아주세요” -2-
결국 컨텐트 생산자가 달아도 무용지물인 태그. 그렇다고 소비자(구독자, 이용자)가 선한 마음(?)을 갖고 태그를 달아주기를 기다리는 것도 어리석은 짓. 결국 태그는 그저 계륵인 것일까?
8. “네가 뭘 하려는지는 모르겠지만, 무조건 하지 마라.”
다시 블로그의 태그로 돌아가보자. 블로그의 특정 포스트에 가장 좋은 태그는 어떻게 붙일 것인가?
“del.icio.us의 해당 포스트를 다른 사용자들이 북마크하면서 붙인 태그가 가장 좋은 태그이다.”
이 문장안에는 태그의 단점을 상쇄시키는 몇가지 핵심아이디어가 들어 있는데,
1) 타인이 자신들의 필요에 따라 붙인다.
2) del.icio.us라는 vocabulary - collabulary를 참조한다.(모호성 제거)
3) 편집자/운영자/컨텐트 생산자가 관여하지 않는다.
이러한 관점은 또다른 태깅방법도 가능하게 한다.
바로 검색엔진과 referer를 이용하는 것.
만약 누군가가 이 글을 “쓰잘데기 없는 글”이라는 검색어로 검색해서 찾아왔다고 하자. 그에게는 이 글은 “tag”가 아니라 “쓰잘데기 없는 글”로 대표되는 글이다. 그럼 저것을 태그로 붙이는 것. 그것이 구독자에게는 필자가 붙이는 태그보다 더 가치있고 의미있는 태깅이다.
결론 비스므레 말하자면, 블로그에 글쓴이가 태깅하지 말 것. 반대로, 타인이 자동이든 수동이든 태깅할 수 있게 내버려두라는 것. (혹은, 타인이 자동이든 수동이든 태깅할 수 있는 도구를 제작하는 쪽이 더 가치있다는 것. - 블로그 개발자들에게 전하는 말.)
태깅하지 말라해서 강제적일 수야 있나. 사용자가 태그를 멀티카테고리 대용으로 사용한다면 그냥 그렇게 쓰는거지 뭐.
사실 이 문제로 왜 블로그 사용자가 고민해야 하나. 블로그 개발자들이 고민해야 할 일이지. 그저 멀티카테고리를 구현해놓고 태그라고 뭔가 거창하게 표현하는 것이 어디 블로그만의 경우이겠냐만.
* WP나 MT의 태그 플러그인들은 본시, del.icio.us나 technorati등의 태그시스템에 편하게 연결하기 위함이었음. 요새야 워낙 혼잡해져서 닭이 먼저인지 달걀이 먼저인지 헷갈리는 지경이지만.
그러니까,
<a href=”/tags/something” rel=”tag” >가 아니라
<a href=”http://del.icio.us/tags/something” rel=”tag” > 였다는 말씀.
November 23, 2006 at 1:05 pm · Filed under WebDevelopment, WebStandard
언젠가, 어느 외국기사를 보니, 사용자가 URL을 치고 페이지가 뜰 때까지 기다려주는 평균시간이 3.5초인가 그렇다고 한다. 예전에 비해 매우 짧아졌다고 할 수 있다.
서버 성능이 향상되고 인터넷 회선들도 빨라졌으며 사용자의 PC도 고성능화되어있음에도 여전히 페이지가 늦게 열리는 사이트들(일시적인, 혹은 고정적으로…)을 보면 나자신도 답답한데, 그래서 F5를 자꾸 누르게 되거나, 혹은 아예 서핑을 포기하곤 한다.
개편이전에 gesomoon.com이 그랬었고, zdnet과 한겨레도 가끔 그런다.
서버나 회선의 문제가 아니라면, 결국은 HTML의 문제.
많은 개발자들은 php, asp, jsp, perl 뭐 기타등등 CGI/Server Script들의 최적화를 위해 고민들을 한다. 어떻게 하면 루프를 한번 덜 돌릴까, 어떻게 하면 불필요한 분기문을 없앨까.
현장에서는 그런 문제로 사수들이 부사수들에게 갈굼(?) 또는 교육을 행한다. “여기 이 for문은 위에서 이렇게 처리했으면 없어도 되잖아.”
이렇게 해서 개선되는 처리속도는 시간으로 따지면 대략 0.01초 차이. 뭐, 바보가 아닌 이상 1초이상 돌아가는 루프문을 만들었을리는 없을테니까.
서버성능이 비약적으로 발달해서 싸구려 리눅스 서버래도 램좀 꼽아주고 나면 웹사이트 하나 돌리는 것이 아까울 정도로 황송한 속도가 나온다. 서버사이드 프로그램들의 속도개선 옵티마이징은 사실상 투자대 효용으로 치면 그다지 효율적이라고 할 수 없다는 표현까지 가능하겠다.
그래서 좀 똘똘해지면 DB쪽 커스터마이징이 더 중요하다는 것을 깨닫는다. 불필요한 중복 커넥션을 없애고, 쿼리문을 최적화하고, 필요하다면 DB 스키마를 다시 설계한다.
이것으로 잘하면 1초 이상 응답시간을 줄일 수도 있다.
대개 여기까지 개발자들이 노력하는 부분이다.
헌데 실상, 이런 노력이 다 무의미해지게 만드는 것이 웹환경일진대…
즉 회선 속도가 느리다거나 하면 말짱 도루묵이 된다는 점.
예를 들어 이미지가 많이 쓰이는 경우, 이미지 로딩시간이 앞서의 노력들을 다 잡아먹는다.
이런 경우에는 이미지 서버를 여러대 두고 같은 이미지를 저장해 둔후, 이미지를 불러올 때 로테이션식으로 여러 서버로 로딩부하를 분할해서 분담하게 하는 방법들이 있겠다. 구글 맵 등이 대표적인 케이스.
그런데 구글 맵처럼 늘 갱신되는 이미지가 대용량으로 쓰이는 경우들도 아닌데 페이지가 늦게 열리는 사이트들은 도대체 뭐란 말인가.
대개 그런 경우는 “광고”가 문제. 정확히 말하자면 “광고” 그 자체보다 “광고를 처리하는 방법”의 문제.
결론부터 말하자면, “페이지가 로딩된 후 모든 것을 처리하라.”라고 요약할 수 있겠다.
HTML본문 중에 다음처럼 스크립트 처리를 하는 경우들이 많다.
[html]
[/html]
대개 광고서버는 외부서버인 경우가 많고, 각종 처리를 해야하다보니 스크립트 실행속도가 매우 느리거나, 혹은 무엇인가의 문제로 아예 응답이 없을 수도 있다.
이렇게 되면 브라우저는 여기에서 응답이 올 때까지 멈춰있게 된다. 물론 HTML로딩이 끝나지 않은 상태이므로 화면에는 아무것도 표시가 안되고…
대안은 이렇다.
[html]
window.onload=function() {
addBanner(’sideBanner’, …);
}
function addBanner(divId, …) {
…
}
[/html]
페이지가 로딩된 후에, 광고가 출력되도록 window.onload에 이벤트를 걸어주는 방식. addEvent로 검색해보면 window.onload에 이벤트를 추가하는 좋은 방법을 알 수 있다.
이런 경우도 있다.
[html]
…
[/html]
HTML의 앞부분에 외부 서버의 스크립트를 실행시키는 방식인데, 상기했듯이, 외부로 나갔다오는 처리는 대부분 시간을 많이 소모시키고 응답을 확신할 수 없는 경우가 많다.
따라서 저 부분에서 뭔가 문제가 생기면 차후 진행이 안되고 로딩상태로 멈춰있게 된다.
이런 경우는 스크립트 호출을 body의 가장 끝부분에 놓거나
[html]
…
[/html]
혹은 위에 설명한대로, window.onload 이벤트에 걸어 페이지가 로딩된 후 동적으로 스크립팅이 되도록 만들어주면 된다.
아, 물론 Table이나 시맨틱하지 않은 장식용 img 태그의 남용 역시 페이지의 로딩속도를 떨어뜨리는 나쁜 코딩방법.
external CSS를 잘 활용하는 것도 CSS 캐싱을 이용한 페이지 로딩속도 개선에 좋은 효과를 준다.
페이지 로딩 후에 스크립트를 처리함으로써 얻을 수 있는 기대효과는 브라우저 로딩시간의 단축이외에도,
1) 스크립트 사용이 불가한 환경에서도 스크립트 자체를 제외한 다른 부분은 이용가능하다.(ohpy처럼 완전히 스크립트 스파게티인 사이트들이야 불가능하겠지만.)
2) 그런고로, 접근성이나 machine-feed로의 활용이 나아진다.
3) 물론 당연히 유지보수도 쉽다.
for문 잘못 썼다고 부사수를 타박하기 전에 저런 부분부터 개선해나가는 쪽이 필요하지 않을까? 웹프로그래머라면 말이지.
November 21, 2006 at 12:56 am · Filed under WorldWideWoops
* 감상적으로 IT를 즐기는 방법
1) Mac을 쓴다. (OSX) - linux 데스크탑도 좋은 대안이지만 일반 사용자에게는 확실히 어려우므로 그냥 Mac을 추천.
2) Firefox를 쓴다. - Opera도 좋은 대안이며, Safari도 나쁘지는 않지만 앞의 두가지보다는 좀 그렇다.
3) 검색이나 기타 서비스는 brand by Google을 사용한다. (Google은 아니지만 flickr도 괜찮다.)
* 우아하게 IT를 즐기는 방법
1) Mac을 쓰고 있음을 블로그에 표시내지 않는다. 최소한 Windows XP와 비교하지 않는다.
2) Firefox를 쓰고 있음을 블로그에 표시내지 않는다. 최소한 IE와의 직접적인 비교는 않는다.
3) Naver와 Google을 비교하는 포스팅을 올리지 않는다. 물론 싸이월드와 블로그를 비교하는 것 따위도.
Mac에서 Firefox로 Google을 이용하고 있음을 블로그에 밝히는 순간, 당신은 잠재적인 공격왕따대상이 되는 것입니다. (물론 한국에서만.)
November 20, 2006 at 5:46 pm · Filed under WebStandard, WorldWideWoops
간단 끄적 노트.
사용자가 remark하고 싶었던 것이 과연 url일까?
url은 permanent하지 못할 수도 있고, 내용이 바뀔 수도 있고, 또는 너무 내용이 많을 수도 있다.
더 작은 조각 - bit, atom - 에 관한 remark 수단은…
같이 이야기하고, 타인의 생각을 보는 것도 중요하긴 한데…
‘타인’에게 자신을 보이는 것과, ‘타인’을 보는 것이 반드시 일치할 필요는 없지 않나… - 네이버 익명 찌질이의 폐해가 있긴 하지만.
어쨌거나, 무엇이 remarkable한지는 알 수 있다 쳐도, 그것을 나는 어떻게 소비할 것인가. 풀기 어려운 숙제.
November 20, 2006 at 5:21 pm · Filed under WorldWideWoops
블루스크린 스크린세이버
유머러스합니다.
맥아피사는 이 스크린세이버를 아주 심각한 악의적 농담으로 간주하는 듯 하군요.
OSX를 쓰면서부터는 시스템 크래쉬를 경험해본 적이 없는데, BootCamp 돌려서 한번 설치해봐야겠습니다. 재미있겠는걸요?
November 20, 2006 at 5:04 pm · Filed under WebPlan
PC통신 시절, 영퀴방 죽돌이였습니다만…
영퀴방의 몇가지 금과옥조 중의 하나는,
“자주 출제되는 영화는 볼 만한 영화이다.”
였습니다.
옛날에는 감독과 배우의 필모그래피를 달달 외울 정도의 시네키드시네퀴저였다고 자부했으나, 최근에는 볼 영화를 선택하는 것은 꽤나 어려운 일이 되었습니다. 예전만큼 관심이 없어서이겠지요. 그래서 후회하지 않을 영화를 고르기에 대한 방법을 이래저래 시험해보게 됩니다.
가장 확실한 것은 아무래도, 직접 영화에 대한 정보를 수집하는 것일겝니다. 내 영화 취향을 가장 잘 아는 것은 누가 뭐래도 저 자신이니까요.
그러려면 자기 자신에 대한 프로파일링을 해야 합니다. 스스로 어떤 영화를 좋아하는지 모르는 채로 자신에게 맞는 영화를 찾을 수는 없거든요.
개인 프로파일링 방법은 여러가지가 있겠습니다만, 가장 구현하기 쉬운 건 필터링입니다.
“SF, 테리 길리엄, 조니 뎁, 19세기 영국, 동성애, 저예산, 재즈, 슬랩스틱, 내가 읽은 소설 원작…”
이런 키워드들을 다양하게 AND, OR, XOR, NOT등의 논리연산을 거쳐 필터링을 하면 “내가 좋아할 영화”와 “내가 싫어할 영화”를 이론상 구분할 수 있다는 소리죠.
문제는, 필터링의 체 눈구멍이 촘촘하면 촘촘할 수록 그 사이를 빠져나가 흘리는 정보가 많아진다는 점. 또, 필터링의 대상은 결국 의외성이나 참신성은 없다는 뜻입니다. 우연히 기대하지 않고 본 영화가 좋았다… 같은 경험을 기대할 수 없다는 것이지요.
실은 그보다 더 큰 어려움은, 이런 필터링을 하고 있기가 귀찮다는 겁니다. 실은 제가 지금까지 좋아했던 영화가 알고보니 디아스포라를 원형으로 갖는 영화더라. 실은 은근히 제가 마초끼가 있다더라… 이런 건 본인 스스로도 잘 모르고 또 구체적으로 필터링 수단으로 삼기도 애매하거든요. 또 일일이 모든 필터를 열거하기도 어렵잖아요. 사람의 취향이란 복잡한 편이거든요.
그러다보니 지동 필터링을 위해 나오는 것은 행동분석입니다.
내가 지금까지 “은하수를 여행하는 히치하이커를 위한 안내서, 가타카, 페이첵, 슈퍼맨”을 봤다면, 저는 아마도 “SF”에 관심있다고 볼 수도 있겠지요. (혹은, “운명을 휘두르는 프로타고니스트-안타고니스트 갈등”을 내면적으로 원하고 있는 건지도 모르겠습니다.)
그러나 행동분석(log-activity analysis)은 구현하기가 그리 만만치 않습니다. 위의 괄호안에 적은 것처럼, 개인적인 의미소를 개인에 맞춰 추출해내는 것은 현재로서는 인공지능으로는 불가능한 현실이거든요. 게다가 역시 필터링의 단점은 오롯이 남아 있습니다.
요즘 유행한다는 소위 집단지성으로 영화를 선택할 수도 있습니다.
그러니까, 관객 100만이라면 어찌 되었건 봐볼만한 가치가 있을 지도 모른다는 거죠. 혹은 네이버 영화별점 별 다섯개라든가요.
그러나 이 역시 문제가 없진 않겠죠. 대중은 불가해하며 변덕스럽습니다. 나아가서, 타인의 취향이 나의 취향은 아닐 수 있다는 것. 그러니까 100만 관객이 눈물을 흘리며 감동받았다는 “실미도”는 저한테는 잊고 싶은 영화 첫 순위로 꼽힐 수도 있고, 남한테 권하기는 껄끄럽지만 개인적으로는 “지구를 지켜라”를 남몰래 한국영화 베스트10중 하나로 꼽고 있을 수도 있다는 거지요.
실은 그나마 선호하는 방법 중 한가지는, 비평가들의 한 줄 비평을 참고하는 것입니다. 아, 물론 지금처럼 영화평론가들의 권위가 땅바닥을 기고 있을 때도 말이지요. 4천만이 감독이자 평론가인 시대에 무슨 시대에 역행하는 소리냐…일 수도 있겠습니다만. 4천만 평론가들의 자칭 평론은 존중은 합니다만, 그게 나와 꼭 들어맞는다는 보장은 없는 것이지요.(단순히 산술적으로만 생각해봐도 4천만의 의견은 저와 일치하기보다는 다를 가능성이 더 높겠지요.)
그럴바에야 차라리 “정성일씨”가 추천하는 영화를 보는 쪽이 저한테는 실패할 가능성이 덜하다는 겁니다. 왜냐하면 저는 “정성일씨의 평론”을 알고 있고, 자연인 정성일씨에 대해서는 하나도 몰라도, 영화평론가로서 그가 써왔던 글과 그의 취향을 알고 있기 때문입니다. 나자신과 100%일치하지는 않아도 70%정도는 일치하더라.. 그러니 정성일씨의 영화추천을 참고할 수 있는 것이겠지요.
혹자에게는 ‘그’가 “듀나”일 수도 있고, ‘이무영’일 수도 있으며, 혹은 ‘이규영‘일 수도 있겠지요.
조금 더 발전시키면,
“우리 마누라가 고르는 영화는 그나마 괜찮아.(연예정보에 빠삭한 마누라님들 덕에..)”
“김대리가 영화고르는 안목이 좀 있지. 우리회사 이번주 문화행사는 역시 김대리가 선택하도록 해.”
“이글루스의 XXXX님이 봤다는 영화는 제법 저랑 취향이 비슷한 것 같아요…”(혹은, XXXX님은 나랑은 취향이 정 반대! XXXX님이 좋다고 하는 영화만 피하면 돼… 라든가.)
그러니까, 나 자신이 정보를 수집하고 가치를 판단하는 것은 수고스럽고 귀찮고, 그렇다고 생판 모르는 타인들의 선택을 무조건 따를 수도 없다면…
내가 ‘신뢰하는 누군가(들)’에게 그 선택을 위임하는 편이 그나마 나은 대안일 수 있다는 거죠.
이러한 전략은 실은, 오프라인의 “신문선택의 전략”과 비슷합니다. ‘신문은 세상을 보는 시각에 대한 가치관’이라는 관점에서 충성도 높은 독자가 신문을 선택하는 것은, 그 자신의 가치관을 신문사에게 위임하는 셈인거죠. 조,중,동,한,경,대,오마이뉴스에서 스포츠찌라시까지 다양한 신문들이 있고, 실제적으로 다루는 기사는 거의 대동소이함에도 불구하고, 자신의 가치관과 가장 비슷한 신문을 고른다는 것은 해당 신문사의 편집진이, 자신이 기대하는 그만큼의 시각을 가져줄 것이라 믿고 위임하는 것이라 할 수 있습니다.
잠시 일본에 와있습니다. 약속시간인 저녁 7시까지 시간때우기가 쉽지 않네요. 일본어를 못하는 관계로 영화로 시간때우기는 포기. 생각나서 끄적대봤습니다.
November 12, 2006 at 10:04 pm · Filed under WebDevelopment, WebStandard
* 이 문제가 TatterTools의 문제인지, 아니면 단지 스킨이나 플러그인 제작자의 문제인지는 모르겠습니다.
여하튼간에, 몇몇 TT로 된 블로그들을 보다 보니, tag 쓰임이 잘못되어있는 것을 알게되었습니다.
tag는 microformat에 정식으로 채택된 포맷으로써 일정한 형식을 갖추도록 되어있습니다. 그런데 국내의 tag를 이용하는 많은 서비스들, 그리고 TT의 일부(!) 블로그들에 문제가 있네요.
tag의 기본 형태는 다음과 같습니다.
[html]
tagWord
[/html]
1) rel=”tag” 속성을 가져야 합니다.
[html]
something
[/html]
이 코드는 rel=”tag”가 없기 때문에 틀렸습니다.
2) visible link여야 합니다.
즉,
[html]
[/html]
처럼 안보이는 링크이면 안됩니다. 반드시 링크가 인간의 눈에도 보여야만 합니다.
3) tagWord는 중요하지 않습니다. 중요한 것은 tagPath입니다.
[html]
nothing
[/html]
처럼 되어있을 경우, 이 tag는 “something”입니다.
4) tagPath의 가장 마지막 세그먼트가 tag입니다.
따라서
[html]
computer
[/html]
같은 경우 “computer”가 tag가 됩니다. (”it/computer”도, “it, computer”도 아니지요.)
또한 그렇기 때문에
[html]
computer
[/html]
같은 방식으로 쓴다해도, 이 태그는 “computer”입니다.
다음과 같은 경우는 어떨까요?
[html]
computer
[/html]
네. 역시 computer입니다.
어떤 tag인지의 구분은 전적으로 URL경로에 의해 결정됩니다. URL에서 마지막으로 나온 Path 세그먼트-즉, 마지막으로 나온 ‘/ ‘ 다음에 나오는 단어가 tag가 됩니다. 절대로 URL중의 query파라메터를 tagPath로 쓰면 안됩니다.
[html]
something
[/html]
즉, 이렇게 쓰면 안된다는 말씀.
이런 경우에는 LAMP환경이라면 mod-rewright를 이용해 변경해줍니다. (다음과 같은 코드가 도움이 될 지도.)
[code]
RewriteEngine On
RewriteRule ^tag/(.*)$ index.php?tag=$1
[/code]
5) tagPath는 실제로 존재하는 URL이어야 합니다.
tag의 목적은 “tagging”자체라기 보다는, 그 tag가 실제로 어딘가에서 활용되기 위함입니다.
TT의 경우 tag모음 페이지가 있습니다. 당연히 그리로 연결되어야 합니다. 또 technorati 태그라면 technorati의 해당 tag페이지로 연결되어야 합니다. (하나의 태그로 여러개의, 혹은 불특정 태그서비스에 연결할 수는 없습니다.)
그래서 문제가 있는데, tagPath를 상대경로(”tag/something”처럼) 적는 것은 그다지 바람직하지 않을 수 있습니다. 왜냐하면 microformat자체의 목적은 machine-friendly한 코드의 생성이고, 이는 바로 machine-feed로 쓰이기 위함인데, 이 HTML문서가 도메인에서 분리되어 machine-feed로 쓰일 때 상대경로 주소는 실제 URL을 찾지 못하게 할 수도 있기 때문입니다.
따라서,
[html]
something
[/html]
보다
[html]
something
[/html]
이 더 바람직합니다.
6) tag의 스코프는 해당 페이지(의 컨텐트)에만 해당합니다.
이는 주로, tag수집서비스들을 인용할 때 흔히 저지르는 실수인데, 예를 들어 technorati라든가 eolin의 태그페이지로 가기위한 링크에 rel=”tag”를 붙이면 안됩니다.
또 tagCloud의 표시에도 rel=”tag”를 붙이면 안됩니다. 현재 표시되고 있는 페이지의 컨텐트를 직접 나타내는 tag에만 rel=”tag”를 붙이세요. 즉, 링크와 태그는 분리해서 사용해야 합니다. (태그의 a에 들어있는 href는 사용자가 클릭해서 그리로 가라는 목적보다는 기계로 하여금 이 tag가 무엇이며, 실제로 어떻게 사용되고 있는지를 알리기 위함입니다.)
7) javascript를 쓰면 안됩니다.
일부 TT블로그에는 tag를
[html]
[/html]
같은 스크립트를 이용하여 가져오는 경우가 있습니다. 이렇게 하면 HTML코드만으로는 tag를 찾을 수 없습니다. machine-feed로 사용하기 위한 microformat의 목적을 망각한 경우입니다.
비슷하게,
[html]
something
[/html]
처럼 쓰는 것도 안됩니다.
물론 당연히 AJAX 등의 javascript를 이용하여 페이지 자체를 만드는 서비스들도 tag를 제대로 사용하지 못하는 경우들이지요.
8)한글과 2단어 이상의 태그.
한때, tag는 한글서비스에서는 잘 맞지 않는다는 루머(?)가 있었지요. 공백이 포함된 두단어 이상의 용어를 표현하기 어렵다거나 하는…
실은 별 문제가 안됩니다. 일단 tag는 utf-8인코딩을 기본으로 합니다. RFC-3986을 참고하세요. 또 공백은 ‘+’나 ‘%20′으로 바꾸면 되지요.
그러니까,
[html]
어떤 태그
[/html]
처럼 쓰는 것이 아니라,
[html]
어떤 태그
[/html]
처럼 쓰면 됩니다. (eolin등에는 제대로 구현되어있는 것 같던데, 몇몇 블로그에서는 이 부분이 잘못되어 있네요. 지금보니 티스토리도 한글 태그가 잘못되어 있습니다.어떤 곳은 제대로 되고 어떤 곳은 또 틀렸고 그렇군요. 스킨쪽의 문제일지도 모르겠습니다.)
9)마치며…
tag하나로 깐깐하게 군다.. 는 소리가 들리는 것 같군요.(불친절한 금자씨 후유증입니다. ^^;)
그러나 tag는 microformat이고, microformat은 본시부터 machine-friendly한 feed를 목적으로하는 규격입니다. 즉, 엄격하게 형식을 맞춰야 한다는거죠.
그렇지 않고, “한국식(이라 쓰고 자기 맘대로…라고 읽는다.)”으로 변형된 tag서비스 같은 것은 자기모순입니다. 그런 것은 tag가 아니라 그저 multi-category일 뿐입니다.(하긴, 사실 국내에서는 대부분 그런 용도로 tag를 쓰고 있는 듯 합니다.)
구글이 자신의 서비스들에 들어있는 비슷한 기능에 “tag”대신 “label”이라는 용어를 쓰는 이유도 거기에 있습니다.
(지금보니 blotter.net도 “tag”대신 “keyword”라는 표현을 쓰는군요. 그렇다면야 microformat을 지키지 않아도 무방.)
November 12, 2006 at 1:46 pm · Filed under WorldWideWoops
나름 이공계 출신이고, 가장 기술발달이 빠르다는 IT밥을 먹고, 또 어리버리어답터라 자부하며, 새로운 게 나오면 써보지 않고는 못배기는 geek인데다가, 예측과 상상은 누구보다 뒤지지 않는다고 내심 생각함… 어쨌거나 그래서 내 예상을 뛰어넘는, 혹은 상상해보지 못했던 무언가를 만나는 것은 거의 드믄 일이라고 생각했는데…
유일하게 근 10년 사이에 “이런, 이렇게나 기술이 발달했다니!”를 느꼈던 것은,
다름아닌 “스테이플러(우리말??로 호치키스) 찍어주는 복사기” 였다.
어제, 어느분과 이야기하다가 그 분 역시 그 제품을 보고 쇼크를 받았다는 이야기를 듣고 생각나서 포스팅.
Next entries »