Are you a VAIO?

Sony가 새 노트북 라인을 내놓으면서 광고타이틀을 재미있게 내놓았네요. Non-PC PC. 그러니까, 방구나 뿡뿡 꿔대는 배불뚝이 아저씨보다 cool한게 Mac청년이라면, 그에게 대등하게 어울릴 만한 것은 VAIO양이라는 말씀. 그러면서 은근슬쩍 VAIO는 PC따위가 아니라는 말씀. 맥 영향력이 커지긴 했나봐요. 경쟁 및 비교상대를 PC가 아닌 맥으로 타겟잡은 것 보면요. http://www.sony.com.au/article.jsp?id=3861&ref=vaioc 그럼에도 불구하고 Sony의 영향력은 예전만큼은 아닌 듯 합니다. 잇달은 사업실패와 철수로 근근히 이어간다는 느낌. PS3가 망하면 아마 그날로 문닫지 않을까 싶네요. 일본내에서도 Sony는 예전보다 많이 브랜드 가치가 떨어졌습니다. 일본에서도 삼성과 LG가 꽤 선전하고 있어요. 한국제에 대한 편견이 많은 그 일본에서도 말이지요. 어쨌든간에 광고로 돌아가서. 젊어서 쌈빡하게 Mac을 쓰다가 VAIO쓰는 새끈한 아가씨를 만나 사귀더라도... 결국 미래는 PC쓰는 양복아저씨라는 이야기도 될 수 있겠군요. :) 오늘은 OSX에 APM을 설치했습니다. 클릭 세번으로 웹서버가 만들어지는군요. 옛날에 Windows에 APM설치하는건 반나절이 꼬박 걸릴 일이었는데 세상 참 좋아졌습니다. OSX만세!!

ekitan

학교때 못다한 일어 배우는 셈 치고 일본에 와있습니다.
바쁘면 포스팅도 없습니다. (원래 게으름.)
포스팅이 적더라도 양해해주시길.

일본의 웹서비스들을 둘러보는 시간이 될 듯 합니다. 벌써 재미있는 사이트를 몇개 발견했습니다.
에키탄(http://ekitan.com)은 오늘 둘러본 사이트 중에 제일 재미있네요.
일단 명색은 전철,지하철 노선안내입니다만, 단순히 최저가격루트나 최단시간루트 등을 알려줄 뿐 아니라, 역세권 정보 등도알려줍니다. 재미있었던 것은, 각 역마다 민간 가이드를 임명해서, 그 가이드가 책임지고 정보관리를 맡는 듯 합니다. 가이드의블로그와 추천링크들이 연결되어 있고, 가이드가 아니더라도 트랙백이나 투고를 통해 해당 지역에 대한 정보를 등록할 수 있네요.
개인의 명예욕(가이드 임명)을 살짝 자극해서 적극적인 활동을 유도하는 모델인 듯 합니다. (일어가 약해 확신할 수 없음)
노선정보에 관해서라면, 각 역의 발착시간표에 맞추어 정확한 시간을 맞춰줍니다. 예를 들어 2시 18분행 전차를 타라는 식으로요. 해당 정보를 폰으로 전송해주고, 열차를 놓쳤을 경우의 대안도 볼 수 있는 듯 합니다.
국내에서도 참고할 만한 아이디어가 있을 것 같습니다.

Flamewar

귀찮네… 씨익. 만박님이 좋은 말씀을 해주셨으므로 갈음.

철저하게 나 중심으로 살자
내가 편해지고, 내가 즐겁고, 내 몸값 올라가게 해주는 게 아니라면 다시 생각해보자
갈길은 멀고 할일도 많다. 남 설득할 시간이 어딨나.
멋진 서비스 만들어서 보여주자

품질관리에 드는 비용

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