품질관리에 드는 비용

Code Complete를 읽다가 재미있는 문구를 발견했는데, 기존에 알고 있던 상식과는 달라 잠이 확 깼다.
요약하자면 다음과 같다.

디버깅과 리팩토링, 그리고 다른 수정 작업이 전형적인 소프트웨어 개발 주기에서 약 50% 정도의 시간을 차지한다. 오류를 예방하여 디버깅을 줄이면 생산성이 향상된다. 따라서 개발일정을 줄이는 가장 확실한 방법은 제품의 품질을 향상시키고 디버깅과 소프트웨어의 수정작업으로 낭비되는 시간을 줄이는 것이다.

뭐, 이부분은 너무나 원론적인 이야기라, "그래서?"라는 반문이 튀어나오게 한다. 그런데 나는 저 문장을 전적으로 이해하고 있었던가?

400 work year 이상의 노력과 3백만줄의 코드를 포함하는 50개의 개발 프로젝트를 검토한, NASA의 소프트웨어 공학연구실의 한 연구에서 품질 보증의 향상이 오류율은 줄여주지만 전체적인 개발 비용에 있어서 추가적인 비용이 들지 않는다는 것을 발견하였다. (Card 1987)

IBM의 연구에서도 이와 유사한 결과를 발견하였다.

결함수준이 매우 낮은 소프트웨어 프로젝트는 개발 일정도 가장 짧고 생산성이 가장 높았다. 소프트웨어 결함 제거가 실제로 소프트웨어 개발에 있어서 가장 많은 비용을 유발하고 가장 많은 시간을 낭비하는 작업형태이다.(Jones 2000)

즉, 가장 좋은 디버깅보다 차라리 결함이 적은 프레임워크가 더 낫다...라는 해석.

아래와 같은 문장도 유심히 볼 내용

... 흥미로운 결과는 프로그램을 완성하기 위해서 평균 시간이 걸린 프로그래머들이 오류가 가장 많은 프로그램을 작성한 것이다. 평균보다 많거나 적게 걸린 프로그래머들은 눈에 띄게 오류가 적은 프로그램을 작성하였다.(DeMarco & Lister 1985)

조금 삐딱한 해석으로는, 어느 수준 이하의 프로그래머들이 평균적인 시간이 걸려 프로그래밍을 한다는 뜻. 다시 말해 특정 수준 이상의 프로그래머라면, 1) 매우 신속하게 문제를 해결하거나, 2) 매우 꼼꼼하게 문제를 해결한다는 뜻... 일 수도 있다.
그런데, 이 조사결과가 보여주는 재미있는 결과는, 시간을 들여 "꼼꼼하게" 해도 신속한 해결방법보다 오류율이 적다는 건 아니라는 뜻. 반대로 해석하면 문제해결 시간은 그 문제의 오류율과는 상관없다는 뜻.

내맘대로 결론은 뭐냐하면, 지금까지 의례적으로 간트 차트에 디버깅이라고 잡아놓았던 시간을 빼버리고 차라리 그 시간만큼 품질보증예방 방법들을 선행하는 것이 더 낫다는 것.
"품질을 향상시키는 것이 개발 비용을 줄이는 일." <- 요즘 몸으로 실감함.

ps. 기억을 더듬어보니 언젠가 조엘 블로그에서도 비슷한 내용을 본 것 같다. 그때는 그냥 건성으로 지나쳤는데 오늘 보니 새롭군.

블로그에 어떻게 태깅할 것인가.

웹 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" > 였다는 말씀.

너무 늦게 열리는 페이지

언젠가, 어느 외국기사를 보니, 사용자가 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문 잘못 썼다고 부사수를 타박하기 전에 저런 부분부터 개선해나가는 쪽이 필요하지 않을까? 웹프로그래머라면 말이지.

우아하고 감상적인 블로깅

* 감상적으로 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을 이용하고 있음을 블로그에 밝히는 순간, 당신은 잠재적인 공격왕따대상이 되는 것입니다. (물론 한국에서만.)

digg, news2.0 - 2%

간단 끄적 노트.

사용자가 remark하고 싶었던 것이 과연 url일까?
url은 permanent하지 못할 수도 있고, 내용이 바뀔 수도 있고, 또는 너무 내용이 많을 수도 있다.
더 작은 조각 - bit, atom - 에 관한 remark 수단은…

같이 이야기하고, 타인의 생각을 보는 것도 중요하긴 한데…
‘타인’에게 자신을 보이는 것과, ‘타인’을 보는 것이 반드시 일치할 필요는 없지 않나… - 네이버 익명 찌질이의 폐해가 있긴 하지만.

어쨌거나, 무엇이 remarkable한지는 알 수 있다 쳐도, 그것을 나는 어떻게 소비할 것인가. 풀기 어려운 숙제.

영화선택의 전략

PC통신 시절, 영퀴방 죽돌이였습니다만...
영퀴방의 몇가지 금과옥조 중의 하나는,
"자주 출제되는 영화는 볼 만한 영화이다."
였습니다.

옛날에는 감독과 배우의 필모그래피를 달달 외울 정도의 시네키드시네퀴저였다고 자부했으나, 최근에는 볼 영화를 선택하는 것은 꽤나 어려운 일이 되었습니다. 예전만큼 관심이 없어서이겠지요. 그래서 후회하지 않을 영화를 고르기에 대한 방법을 이래저래 시험해보게 됩니다.

가장 확실한 것은 아무래도, 직접 영화에 대한 정보를 수집하는 것일겝니다. 내 영화 취향을 가장 잘 아는 것은 누가 뭐래도 저 자신이니까요.
그러려면 자기 자신에 대한 프로파일링을 해야 합니다. 스스로 어떤 영화를 좋아하는지 모르는 채로 자신에게 맞는 영화를 찾을 수는 없거든요.

개인 프로파일링 방법은 여러가지가 있겠습니다만, 가장 구현하기 쉬운 건 필터링입니다.
"SF, 테리 길리엄, 조니 뎁, 19세기 영국, 동성애, 저예산, 재즈, 슬랩스틱, 내가 읽은 소설 원작..."
이런 키워드들을 다양하게 AND, OR, XOR, NOT등의 논리연산을 거쳐 필터링을 하면 "내가 좋아할 영화"와 "내가 싫어할 영화"를 이론상 구분할 수 있다는 소리죠.

문제는, 필터링의 체 눈구멍이 촘촘하면 촘촘할 수록 그 사이를 빠져나가 흘리는 정보가 많아진다는 점. 또, 필터링의 대상은 결국의외성이나 참신성은 없다는 뜻입니다. 우연히 기대하지 않고 본 영화가 좋았다... 같은 경험을 기대할 수 없다는 것이지요.

실은 그보다 더 큰 어려움은, 이런 필터링을 하고 있기가 귀찮다는 겁니다. 실은 제가 지금까지 좋아했던 영화가 알고보니디아스포라를 원형으로 갖는 영화더라. 실은 은근히 제가 마초끼가 있다더라... 이런 건 본인 스스로도 잘 모르고 또 구체적으로필터링 수단으로 삼기도 애매하거든요. 또 일일이 모든 필터를 열거하기도 어렵잖아요. 사람의 취향이란 복잡한 편이거든요.

그러다보니 지동 필터링을 위해 나오는 것은 행동분석입니다.
내가 지금까지 "은하수를 여행하는 히치하이커를 위한 안내서, 가타카, 페이첵, 슈퍼맨"을 봤다면, 저는 아마도 "SF"에관심있다고 볼 수도 있겠지요. (혹은, "운명을 휘두르는 프로타고니스트-안타고니스트 갈등"을 내면적으로 원하고 있는 건지도모르겠습니다.)
그러나 행동분석(log-activity analysis)은 구현하기가 그리 만만치 않습니다. 위의 괄호안에 적은 것처럼,개인적인 의미소를 개인에 맞춰 추출해내는 것은 현재로서는 인공지능으로는 불가능한 현실이거든요. 게다가 역시 필터링의 단점은오롯이 남아 있습니다.

요즘 유행한다는 소위 집단지성으로 영화를 선택할 수도 있습니다.
그러니까, 관객 100만이라면 어찌 되었건 봐볼만한 가치가 있을 지도 모른다는 거죠. 혹은 네이버 영화별점 별 다섯개라든가요.
그러나 이 역시 문제가 없진 않겠죠. 대중은 불가해하며 변덕스럽습니다. 나아가서, 타인의 취향이 나의 취향은 아닐 수 있다는것. 그러니까 100만 관객이 눈물을 흘리며 감동받았다는 "실미도"는 저한테는 잊고 싶은 영화 첫 순위로 꼽힐 수도 있고,남한테 권하기는 껄끄럽지만 개인적으로는 "지구를 지켜라"를 남몰래 한국영화 베스트10중 하나로 꼽고 있을 수도 있다는 거지요.

실은 그나마 선호하는 방법 중 한가지는, 비평가들의 한 줄 비평을 참고하는 것입니다. 아, 물론 지금처럼 영화평론가들의권위가 땅바닥을 기고 있을 때도 말이지요. 4천만이 감독이자 평론가인 시대에 무슨 시대에 역행하는 소리냐...일 수도있겠습니다만. 4천만 평론가들의 자칭 평론은 존중은 합니다만, 그게 나와 꼭 들어맞는다는 보장은 없는 것이지요.(단순히산술적으로만 생각해봐도 4천만의 의견은 저와 일치하기보다는 다를 가능성이 더 높겠지요.)
그럴바에야 차라리 "정성일씨"가 추천하는 영화를 보는 쪽이 저한테는 실패할 가능성이 덜하다는 겁니다. 왜냐하면 저는 "정성일씨의평론"을 알고 있고, 자연인 정성일씨에 대해서는 하나도 몰라도, 영화평론가로서 그가 써왔던 글과 그의 취향을 알고 있기때문입니다. 나자신과 100%일치하지는 않아도 70%정도는 일치하더라.. 그러니 정성일씨의 영화추천을 참고할 수 있는 것이겠지요.
혹자에게는 '그'가 "듀나"일 수도 있고, '이무영'일 수도 있으며, 혹은 '이규영'일 수도 있겠지요.

조금 더 발전시키면,
"우리 마누라가 고르는 영화는 그나마 괜찮아.(연예정보에 빠삭한 마누라님들 덕에..)"
"김대리가 영화고르는 안목이 좀 있지. 우리회사 이번주 문화행사는 역시 김대리가 선택하도록 해."
"이글루스의 XXXX님이 봤다는 영화는 제법 저랑 취향이 비슷한 것 같아요..."(혹은, XXXX님은 나랑은 취향이 정 반대! XXXX님이 좋다고 하는 영화만 피하면 돼... 라든가.)

그러니까, 나 자신이 정보를 수집하고 가치를 판단하는 것은 수고스럽고 귀찮고, 그렇다고 생판 모르는 타인들의 선택을 무조건 따를 수도 없다면...
내가 '신뢰하는 누군가(들)'에게 그 선택을 위임하는 편이 그나마 나은 대안일 수 있다는 거죠.

이러한 전략은 실은, 오프라인의 "신문선택의 전략"과 비슷합니다. '신문은 세상을 보는 시각에 대한 가치관'이라는 관점에서충성도 높은 독자가 신문을 선택하는 것은, 그 자신의 가치관을 신문사에게 위임하는 셈인거죠. 조,중,동,한,경,대,오마이뉴스에서스포츠찌라시까지 다양한 신문들이 있고, 실제적으로 다루는 기사는 거의 대동소이함에도 불구하고, 자신의 가치관과 가장 비슷한신문을 고른다는 것은 해당 신문사의 편집진이, 자신이 기대하는 그만큼의 시각을 가져줄 것이라 믿고 위임하는 것이라 할 수있습니다.

약속시간인 저녁 7시까지 시간때우기가 쉽지 않네요. 일본어를 못하는 관계로 영화로 시간때우기는 포기. 생각나서 끄적대봤습니다.

과학기술의 발전을 실감할 때

나름 이공계 출신이고, 가장 기술발달이 빠르다는 IT밥을 먹고, 또 어리버리어답터라 자부하며, 새로운 게 나오면 써보지 않고는 못배기는 geek인데다가, 예측과 상상은 누구보다 뒤지지 않는다고 내심 생각함… 어쨌거나 그래서 내 예상을 뛰어넘는, 혹은 상상해보지 못했던 무언가를 만나는 것은 거의 드믄 일이라고 생각했는데…

유일하게 근 10년 사이에 “이런, 이렇게나 기술이 발달했다니!”를 느꼈던 것은,
다름아닌 “스테이플러(우리말??로 호치키스) 찍어주는 복사기” 였다.

어제, 어느분과 이야기하다가 그 분 역시 그 제품을 보고 쇼크를 받았다는 이야기를 듣고 생각나서 포스팅.

microformat Parser (php4)

쓸만한 마이크로 포맷 파서가 없어서 뚝딱거려봄. php5버전으로 하려다, 아직은 php4가 대세라 php4로 제작.
hCard와 hCalendar만 지원. 나머지는 귀찮아서. 국내에서는 언제쯤 microformat을 쓸 수 있을까...

class O_MICROFORMAT extends METAOBJECT {
var $str;
var $domain;

function O_MICROFORMAT($str, $domain) {
$this->str = $str;
$this->domain = $domain;
}

function hCard()//{{{
{
$querys = array(
"url" => array("/@href"),
"n" => array(""),
"fn" => array(""),
"adr" => array(""),
"tel" => array(""),
"org" => array(""),
"role" =>array(""),
"email" =>array("/@href"),
"stem" => array("")
);
return $this->parse('vcard', $querys);
}//}}}

function hCalendar()//{{{
{
$querys = array(
"url" => array("/@href"),
"summary" => array(""),
"dtstart" => array("/@title"),
"dtend" => array("/@title"),
"location" => array("")
);
return $this->parse('vevent', $querys);
}//}}}

function parse($key, $querys) //{{{
{
$str = $this->str;

$dom = new DomDocument();
@$dom->loadHTML($str);

$xpath = new DOMXPath( $dom );
$events = $xpath->query("//*[contains(@class, '$key')]");

$parsed_events = array();
foreach( $events as $event )
{
$e = $this->parse_event( $dom, $event, $querys );
$parsed_events []= $e;
}
return $parsed_events;

} //}}}

function parse_event( $dom, $event, $querys) //{{{
{
$data = array();

$xpath = new DOMXPath( $dom );
foreach($querys as $query=>$val) {
$t = $xpath->query( ".//*[contains(@class,'{$query}')]{$val[0]}", $event );
$data[$query] = $t->length > 0 ? $t->item(0)->nodeValue : '';
if($query=="url") {
if(strtolower(substr(trim($data[$query]), 0, 7)) != "http://") {
$data[$query] = $this->domain . $data[$query];
}
}
if($query=="email") {
if(strtolower(substr($data[$query], 0, 7)) == "mailto:") {
$data[$query] = substr($data[$query], 7);
}
}
}

return $data;
}//}}}

}

재미없어지는 요즘의 트렌드

제대로 표현하긴 어렵지만, 수상한 냄새들이 나기 시작한다.

1) 자생하지 못하는 비즈니스 모델에도 불구하고 “주목경제”라는 미명하에 일단 사람들을 끌어모으고 그 다음은 Google(혹은 NHN, 혹은 다음, 혹은 아마존…)에 팔아넘기기. problem은 대형 키메이커들이 떠안고(인력과 자본이 있으니 해결은 하겠지만) 자신들은 새로운 차키와 대저택을 안고 이 버블바쓰에서 은퇴하기.

2) 모두들 web으로 달려들고 web상에서 모든 것을 하려하지만, 덕분에 PC의 자원은 남아돌고. 누군가는 이 남는 PC 리소스를 활용하여 진짜 대박을 터트릴지도. 요즘 그나마 고가의 PC의 존재가치를 정당화시키는 것은 게임들뿐.

3) 컨퍼런스, 언컨퍼런스의 홍수. Social Networks는 여전히 On-line이 아닌 Off-line에서 유효하다는 반증. 모여서 명함돌리고, 누구와 안면텄다는 것이 목적. 예전에는 경품을 타기 위해 행사에 참여했다면, 요즘은 “유명한 누구씨”와 만났다고 블로그에 적기 위해. 물론 기념사진은 기본.

4) 요즘 나도는 이슈나 트렌드들은 보고 있자니, 그저 시들한 느낌뿐. 스테레오타입과 워너비의 범람. 하긴 나 역시도 그 중 하나니. 뭔가 쌈빡한 것을 보고 싶다.

사무실 2.0

ThinkVitamin에 소개된 재미있는 이슈.

간추려 보자면, 사무실에서 사용할 어플리케이션에 대한 web 2.0 적 해석(?)이다.

작자인 Carson은 Carson System이라는 자신의 작은 회사에서 업무에 필요한 소프트웨어들을 꼽고 있다. 일단 플랫폼으로 맥을 이런 저런 이유로 사용하고 있고, 구성원은 5인 이하. 이런 조건에서 꼽아본 것들은 다음과 같다.

Type	Software	Price
Text editor	TextEdit	Free and pre-installed
Code editor	TextWrangler	Free
Graphics package	Fireworks	$100
Storage	DropSend	$99 per month (for whole company)
Backup	SuperDuper	Free (basic version)
FTP	Cyber Duck	Free
Chat/IM	iChat	Free and pre-installed
Email	Mac Mail	Free and pre-installed
Calendar	Google Calendar	Free
Address book	Mac Address Book	Free and pre-installed
Spreadsheets	Tables	$49

일단 재미있는 것은, 이렇게 꾸밀 경우, 1인당 비용은 173USD정도. 만약 오피스와 Studio 8로 비슷한 환경을 꾸미면 1인당 비용이 1699USD나 나간다고.

테스트 결과 몇가지 바뀌었는데,
TextEditor -> Word (확실히 비싸고 무겁긴 하지만 오피스는 쓸만한 소프트웨어이다. )
FTP -> Transmit (맥용으로 나도 이걸 쓰긴한다. 최근에는 그냥 FF의 FTP플러그인으로 대체 중)
Spreadsheet -> Excel (Word와 동일)

그런데 나는 작자의 결론보다도, 이 글을 읽으면서 개인적으로 느낀 건…

역시 오피스 최고. (-_-b)

…는 아니고,

회사에서 직원을 뽑거나 해서 새로 PC를 세팅해주면서 “깔아도 되는 / 깔아주는 / 깔라고 회사파일서버에 넣어둔” 등등의 소프트웨어들을 보자면 그 회사의 IT에 관한 관심도를 알 수 있다고나 할까.
여전히 “한글97″을 쓴다거나 하면 왠지 모르게 김이 빠진다.

Geek처럼 최신버전, 최고급만 노릴 필요는 없겠지만, 경영자에게 푹신한 안락의자와 마호가니 책상이 경영효율등을 높이기 위해 필요한 필수품인 것처럼,
IT종사자에게는 최신 버전의 S/W가 쾌적한(?) 업무환경을 위해 필수적이라는 것. (버그투성이의 베타버전들을 말하는 것은 아님.)

오피스 2002가 있는데 왜 오피스 2007을 또 사야 하냐고 묻는다면(MS 영업사원 삘이네. 그저 예를 든 것뿐.), 사장님은 왜 안락의자를 바꾸셨나요… 라고 반문하고 싶다는.

URL이 없는 페이지

페이지가 없는 URL이야 404 에러로 흔히 만날 수 있지만…
요즘 유행하는 사이트들은 URL이 없는 페이지들이 많다.

오늘 정식 런칭했다는 오피 등을 비롯하야…
반드시 AJAX때문이 아니더라도, 유사한 DHTML들, iFrame, Frame. 또 최근 각광받는 Flex등을 보면, URL이 없는 페이지들을 많이 만난다.

나는 좀 구식이라 그런지…
URL창에 나와있는 주소로 “페이지”들이 구별되어야 한다고 생각한다.

물론 “어플리케이션”적인 관점에서, URL이 없는 페이지들도 있을 수 있다. 그건 URL이 없는 Page라기보단, 어플리케이션의 어떤 한 Phase 도중이라는 생각. 그러므로 Phase들이 계속 변하면서 진행된다 하더라도, 결국 시작점과 끝점이 있기 마련이다. 예를 들어 “웹워드프로세서”라 해도, “시작페이지”와 “최종결과출력페이지”에는 고유한 URL이 있어야 한다고 본다. 중간에 어떤 쇼를 할 지언정 말이다. (개발자의 의지문제 - 사람들말마따나 “비용이 많이 드는” -)

웹의 근간은 링크였고, 링크는 URL을 기반으로 하였었다.
웹 2.0인지는 모르겠으나, 링크대신 스크랩으로 바뀌고, 그래서 URL은 더이상 필요없어지누나…