OpenID 자료

저한테 openID 자료가 없냐고 메일로 여쭤보신 분이 계시던데...
저도 없습니다... 를 떠나서 정말 자료 찾기가 너무 힘들어요.

일단 개발하시는 분들은
http://www.lifewiki.net/openid/OpenIDLibraries
에 가시면 본인의 사용언어에 맞는 것으로 개발라이브러리 코드를 구하실 수 있습니다.

몇가지 용어를 이해하시면 더 쉽게 접근하실 수 있으실 겁니다.

Consumer : OpenID로 로그인, 가입, 정보가져오기... 등을 수행하는 서비스/사이트 를 말합니다. 다른 openID 사용자들을 자신의 서비스에 참여시키기 원하시는 분들은 Consumer관련된 코드를 활용하시면 됩니다.
Provider : OpenID를 사용자에게 발급해주고, Consumer의 요청이 있을 때 그에 대한 정보를 제공해주는 서비스/사이트를 말합니다.

반드시 하나의 서비스, 사이트에서 Provider와 Consumer 두가지 역할을 다 할 필요가 없습니다. (OpenID에 대해 좀 더 연구해보면 두가지 역할을 다 떠맡는게 좀 바보스러운 일임을 아시게 될겁니다.) 대개의 경우는 Consumer부분만 연구하시면 충분할 겁니다.

개인적으로는 OpenID를 SSO(Single Sign On) 대용으로 사용하는 것은 재고할 필요가 있다고 봅니다. 한국에서의 RSS의 오용(?)과 마찬가지로 주의깊게 준비하지 않고 OpenID 대응 서비스를 열 경우, 개인정보보호문제에 대해 상당히 시끄러울테니까요.

아무 생각없는 인터페이스

StandardMag에 올라온 질문에 대한 답변을 정리해봅니다.

관습적인 인터페이스는 사용자에게 익숙함을 주긴 하지만, 관습에 매몰되어 매너리즘에 빠지게 되는 경우도 많지요.
회원가입페이지 제작시 가장 쉽게 보이는 매너리즘 인터페이스 두가지에 대해 이야기해보렵니다.

1. 3칸으로 나뉘어진 전화번호.
사실 핸드폰 번호 따로 집전화 번호 따로 입력받는 것도 무의미하긴 하지만.('기분존'같은 서비스도 나온 마당에 말이지요.)
습관적으로 우리는 전화번호 입력 필드를 3칸으로 나누어 놓습니다.
이것은 결코 UX적으로 좋은 인터페이스라 할 수 없습니다.

우선 손이 많이 갑니다.
016 타이핑하고, tab키 누르고, 9447 타이핑하고, tab키 누르고, 8022 타이핑하고.
tab키를 이용할 줄 아는 사용자라면 이정도입니다만, 나이드신 분들은 필드간 이동을 하기 위해 다시 마우스를 잡고 해당 필드를 클릭해야 합니다.
이러다보니 이 불편함을 없애보자고 JavaScript를 써서 앞에 세자리, 입력하면 자동으로 다음 필드로 포커스를 옮겨보기도 하지만, 이러면 원래 tab키 이동이라는 표준 인터페이스에 익숙한 사용자에게는 오히려 잘못된 입력을 유도하게 됩니다.
게다가 이왕 JavaScript를 사용하는 김에 입력값 검사까지 해버립니다. 마지막 필드가 네자리 숫자가 아니면 틀렸다고 한다거나...
그러면 이제는 우리 회사 대표번호는 02-2424-825로 알려져 있는데, 굳이 02-242-4825로 입력해야만 합니다. 신경쓰지 않으면 타이핑 미스 생기지요.
그나마 무슨 이유로든간에 JavaScript 사용이 불가능하면 입력도 먹통이 되는 경우까지 생기기도 하지요.

애초에 그냥 한칸의 입력필드에 022424825로 입력하든, 02)2424-825로 입력하든, 02 2424 825 로 입력하든 사용자 맘대로 입력하게 해도 충분할 일입니다.
일단 그렇게 Form을 submit한 후, 간단한 정규식으로 전화번호를 추출하고, 그것이 전화번호 형식에 맞는지 안맞는지 판단하는 것은 어려운 일이 아니죠. 만약 전화번호가 틀린 포맷이라면 다시 이전 입력Form페이지로 돌리고 에러메시지('전화번호가 틀렸습니다. 다시 입력해주세요.')를 보이면 될 일입니다.

이전 페이지로 돌아가는 게 사용자에게 오히려 번거롭지 않냐구요?
전화번호 입력이 틀리는 경우는 거의 없습니다. 눈감고도 입력할 수 있는게 전화번호라구요. 오히려 세칸에 나누어 적고 JavaScript를 따라 널뛰는 조작보다는 훨씬 더 정확하게 입력할 수 있습니다.
물론 JavaScript가 안되는 환경에서도 문제없이 사용할 수 있구요.

2. 우편번호 팝업
도대체 왜 우편번호와 정확한 주소를 수집해가는지 모르겠습니다. 그거 가지고 인구센서스 통계내나요? 우리 사이트의 주 사용자는 서울에 살고 있어.. 같은?
그런 CRM 자료를 제대로 분석해서 사용하는 기획자나 운영자가 있는지는 모르겠습니다. 아마 오히려 접속 IP 위치를 통계내는 쪽이 좀 더 정확할텐데 말이지요.

우편번호나 주소를 수집하는 이유가 상품 배송이나 우편물 발송때문이라고도 하는데, 실제로 이런 서비스를 할 때에는 사용자에게 정확한 배송주소를 다시 물어보는 것이 정석입니다. 대부분의 업체에서도 그렇게 하고 있구요.
어쨌거나 그래서 정확한 우편번호나 주소가 필요하다 치더라도...

그래도 우편번호 팝업 입력은 아닙니다.

그럼 대안이 있을까요?

제가 전에 살던 집주소는...
"서울특별시 서대문구 대현동 56-38번지 5층"
입니다.

아무리 타이핑이 느린 분이더라도, 자기 집 주소를 한 줄에 입력하는 건 "버튼 눌러 팝업 뜨고 동이름 넣고 검색하고 후보들 나오면 목록에서 위아래로 오르내리며 찾아 선택하고 팝업이 닫긴 후 부모창의 다음 필드에서 번지이하 주소를 다시 입력하는 것"보다는 빠릅니다. 물론 훨씬 더 직관적이고 쉽기도 하지요.

주소가 정확한지는 어떻게 아냐구요? 우편번호는 어떻게 하냐구요?

저 위에 쓴 주소를 정규식 돌려서 도/시, 군/구, 읍/동 을 뽑아내는 것은 일도 아니지요. 그리고 그걸로 DB에서 매치되는 우편번호를 찾아내는 것도 어렵지 않지요. 굳이 AJAX같은 것을 쓰지 않더라도, 그냥 Form Submit한 후 서버사이드에서 매치시켜보고, 정확하지 않거나 매치되는 후보가 너무 많다면 다시 이전 페이지로 돌려 재입력 받게 하거나, 매치되는 후보들 중에서 선택하게 하면 됩니다.

JavaScript도 필요없고, 정상적인 사용자들에게 불편함도 없지요.

생각해보면 이런 관습적인 멍청한 인터페이스야 말로 UX의 가장 큰 적입니다. JavaScript나 AJAX가 없어서 사용성이 제한되는 게 아니라, 단지 상상력과 배려심이 없는 기획자 때문이지요. 아, 어쩌면 정규식을 다룰 줄 모르는 개발자 때문일 수도 있긴 하겠습니다.

Worst Mistakes

이것저것 뒤지던 중에 우연히 보게 된 imakemistakes.com. 한 십분간 정신없이 웃었다.
다음은 worst mistakes 중에서 몇개 발췌.

* 그녀가 '사랑해'라고 말했을 때 웃어버렸어.
* 다리미를 놔두고 일하러 가는 바람에 아파트를 홀랑 태워먹었어.
* 헤어진 여자친구와 기회가 있었을 때 했어야 했는데...
* 내 아이팟 미니에 리눅스를 설치해보려 했어!

영예의 1위 (?)는,
"나 아직도 이 사이트를 보는 중이야."

OpenID 만지작거리기

php로 openID 1.1 spec대로 프로그래밍해서 만지작거리고 있는데, 어떤 consumer에서는 제대로 인증이 되고, 어떤 consumer에서는 취소가 된다. 도대체 이유가 뭘까... 풀리지 않는 수수께끼. 로그를 읽어봐도 별거 없는데.
이런 오픈 규격을 내놓는 측에서는 이것저것 테스트해볼 수 있는 sandbox framework을 제공해야하지 않을까? 아니면 나만 못찾고 있는 걸까?
어쨌거나 일단은 openID 구현이 가능했다는 걸로 만족.

아, 한가지 더 풀리지 않는 수수께끼. provider와 account가 진짜로 reliable한지는 어떻게 알아내지? malicious한 provider라면 악의적인 목표로 fake user를 만들어 인증을 시도한다면 그것을 어떻게 구분하는거지? 도대체 알 수가 없네...

한국에는 마땅히 물어볼 만한 사람도 모르겠고. 끄응. 에라 모르겠다. 일단 gogo..

올블로그 프레임에 대한 마지막 부탁

* 이글을 마지막으로, 올블의 프레임에 대해 또 포스팅하는 일이 없었으면 합니다. 공연히 올블에 대해 나쁜 감정이 있는 것처럼 비추이는 것도 싫고, 실제로 개선되어서 불편함이 없어졌으면 하고 바라기 때문입니다.

1. 올블 프레임, 저작권.
파란의 블로그 스페이스에 대해 논란이 많았는데, 실상 그 메커니즘 자체는 올블이라고 크게 다를 바 없습니다. (지난 포스팅 참조)
개인이 자신의 블로그에 대해 올블 프레임을 다는 것을 허용했다한들 타인의 웹사이트에까지 그 프레임을 따라가게 하는 것을 허용했을리는 없습니다.
애초에, 아무리 올블이 블로거들에게 친화적이고 좋은 서비스라 하여도 그렇게 쉽게 자신의 컨텐츠를 특정 서비스의 프레임안에 가둬두어도 좋다고 허가하는 개인들도 선듯 이해되지 않기는 합니다.

2. 실질적인 불편함
굳이 올블 프레임에 대해 문제를 제기하는 이유는 저작권 등의 남의 다리 긁는 이유때문만이 아니라, 실제로 웹서핑이 불편해지기 때문입니다.

1) 실제 주소를 가립니다.
제가 링크하고 싶은 주소는, 북마크하고 싶은 주소는, machine-feed로 쓰고 싶은 주소는 link.allblog.net이 아닙니다. 아마 여러분들도 그럴 겁니다.
헌데, google에서 "link.allblog.net" (따옴표 포함)으로 검색해보세요. 저 검색결과에 자신의 블로그 주소가 link.allblog.net으로 걸린 블로그 주인들은 자신들의 링크가 저런 식으로 유통되도 좋다는 것을 자각하고 프레임을 허가했을까요?
어쨌거나, 수고스럽지만 클릭한번이면 프레임을 없앨 수 있으니 그 정도 수고쯤은 감수해야 할까요?

2) 프레임은 따라다닌다.
링크마다 새창띄우기(접근성때문에 하지 말라는), JavaScript로 최상위에서 리프레쉬하기(복잡하게 프레임과 AJAX로 얽혀있는 N,D모 블로그)인 블로그들도 있습니다만, 고지식하게 표준문법만으로 만들어진 블로그들이 있습니다. 이런 블로그들은 올블 프레임이 한번 뜨고 나면, 그 블로그 안에는 물론, 바깥으로 연결되는 다른 페이지까지 프레임은 따라다니게 됩니다. 웹서핑의 본질대로 링크따라 흘러다니다가, 아, 이 페이지 적어둬야지 하고 URL주소창을 보면 link.allblog.net/... 아까 출발했던 페이지. 이제 와서 프레임닫기 눌러봤자 최초 출발 페이지로 돌아가버리게 됩니다. 한번 이런 일을 겪으면 심신이 다 피폐해지죠.

3) 로그인안하면 무용지물...
어차피 올블 프레임의 많은 기능들은 로그인하지 않은 사용자에게는 무용지물입니다. 강제로 로그인을 유도해서 추천과 이슈의 활성화를 노리는지는 모르겠으나 어차피 대부분의 사용자는 로그인하지 않은 상태로 들어와, 로그인하지 않은 채로 올블을 이용하고, 앞으로도 계속 그럴 겁니다.
애초에, 로그인과 버튼 클릭이라는 사용자의 의도적 액션을 요구하는 자체가 집단지성이 될리도 없거니와, 그런 시도를 모든 사용자에게 요구한다 해서 달성될 리도 없겠지요.
애당초 올블 이용자가 올블 가입자 뿐일리도 없고, 그런 식으로 제한을 둔다는 건 오히려 전략 미스에 가까운 생각일테구요.
하여간에, 저같은 비로그인 사용자한테는 올블 프레임은 백해무익할 뿐. 차라리 자발적이고 적극적인 로그인 사용자한테만 올블 프레임을 보이게 한다거나,
혹은 올블 페이지에서 각 블로그로 창이 뜰 때 링크를 두개 줘서(하나는 작은 아이콘 형태라 하더라도) 프레임이 있는 창과 프레임이 없는 창을 선택할 수 있는 수단이라도 제공해주면 오죽 좋겠습니까.

올블에서 낚시성 포스트라도 하나 낚여볼라쳐도, 제일 먼저 하는 건 창이 뜨자마자 올블 프레임 닫기 행위입니다. 가끔 제대로 닫겨지지도 않는 프레임의 닫기 버튼을 클릭하기 위해 트랙패드를 긁어대고 있노라면 이 무슨 무의미한 짓을 반복하고 있나하는 회의감만 드네요.

부디... 로그인한 사용자에게만, 추천 버튼 누르겠다는 열의있는 사용자에게만 올블 프레임을 보여주면 안되겠습니까?

5W1H

"누가", "언제", "어디서", "무엇을", "왜", "어떻게" 를 분석해낼 수 있다면 시맨틱/온톨로지는 그다지 뜬구름 같은 이야기가 아닐 수도 있다.

• who : openID, hCard, VCARD, hResume, Identification 2.0, Reputation, Relationship, XFN ...
• when : VEVENT, hCalendar, iCalendar, dc:datetime...
• where : VEVENT, address, long-lat, map ...
• what : URI, ISBN, bar-code, hReview, vocabulary, collabulary ...
• why : ???
• how : ???

why와 how는 irregular text-context이지만, 나머지는 regularized unique-context로 구현 가능. 네가지는 객관적이지만, 두가지는 주관적. 따라서 사용자에게 두가지 가려운 부분을 손쉽게 긁어줄 수 있는 긁개만 제공해준다면 되는 것 아닌가? 결국은 인터페이스의 문제?

ps. 생각해보니, why와 how가 해당하는 서비스의 개성이 될 수 있겠다. 흠흠. just a memo.

딴죽

어쩌다 보니 이 블로그는 "딴지전문" 블로그가 된 것 같네요.
앞으로는 딴지는 좀 줄이고, tagline에 적혀있는 대로 web technical issue에 대해 집중할 생각입니다.
(그런데, "Issue"에 대해 이야기 하다보니 자꾸 딴지로 흐르게 되는군요. 반성.)
- 불친절하다는 소리를 몇번 듣다보니 생긴 노파심 포스팅
* 딴지는 딴죽의 잘못된 말이라지요.

파란과 올블로그

그냥 끄적끄적.

1) 주소창 바꾸는 건 파란이나 올블이나 그게 그거 아닌가?

2) 프레임안에 가두는 건 파란이나 올블이나 똑같은 거 아닌가? 한쪽은 프레임처럼 생기지 않아서? 한쪽은 없애는 버튼이 없어서?

3) 추천 등의 기능으로 마치 자사 서비스인 것 처럼 하는 것도 파란이나 올블이나 똑같은 거 아닌가?

4) RSS를 본인이 등록하건 타인이 등록하건 그게 무슨 상관인가? 그럼 hanrss같은 웹RSS도 주인장이 직접 등록을 해야하고, 개인이 만들어 쓰는 RSS 리더기도 블로그 주인들이 와서 등록해줘야 하는건가?

---

이 글은 파란을 옹호하는 글은 아니다. 파란의 블로그스페이스 서비스는 문제가 좀 있긴 한데 -

1. 무분별하게 이미지등을 직접 링크하고 있어서 트래픽 누수를 일으키고,
2. (robot.txt 같은)규칙을 지키지 않고,
3. 서비스 운영이 세련되지 못하다는 점.
4. 그리고 지금 없어졌지만 무책임한 스크랩기능.

그정도를 제외하고는 글쎄....

처음 네오비스님의 문제제기는 그런가보다 했는데, 그 후에 들불처럼 퍼지는 파란 때리기는 뭐랄까, 촛점을 일탈하고 있는 듯 하다.
하늘보고 침뱉는다고나 할 정도로, 문제점이라고 짚는 게 그들이 사용하는 올블로그에도 해당되는걸...

저 위에 질문으로 적어놓은 것들은 진짜로, 1) ~ 3)은 모두 올블로그도 저작권법을 매우 '심각하게' 위반하고 있는 사항들이다. 다만, 파란과 다른 점은, 사용자들에게 '허가'를 받았다는 점.

그런데 올블로그 사용자들이 가입시 이것저것 과연 제대로 알고 '허가'를 한걸까? 그리고 과연 그 '허가'로 충분한 것일까?
예를 들어 자신은 올블로그에 가입하면서 올블로그 프레임(?)을 허용했으니, 자신의 블로그에 올블프레임이 떠도 괜찮다고 생각할 지도 모르겠지만,
그렇게 올블을 타고 들어온 사람들이 그 블로그에 링크되어있는 다른 URL을 타고 갈 때, 올블프레임도 따라 간다는 걸 알까? 다행히 목적지도 올블에 가입한 블로거고 그 역시 올블프레임을 허용했다면 모를까, 전혀 관계없는 다른 외부 URL로 갈 때 올블프레임도 따라온다는 것, 그래서 전혀 상관없는 제 3자의 홈페이지가 올블주소 아래에 띄어지고 있다는 것... 그 제 3 자의 저작권을 결과적으로 올블이 침해하는데 방조하고 있다는 사실을 인지하고는 있을까?

* 직접적인 예를 들기 위해 올블을 들먹였으나, 사실 콜콜넷이니 윙버스 같은 서비스들 모두 이 저작권 문제에서 전혀 자유롭지 못함을 노파심에 밝혀둔다.

RSS를 모아서 서비스하는 그 자체에 문제가 있는가? 그럴지도 모른다. 어쩌면 이미 사라진 컨텐트를 가리키는 아이템이 있을지도 모르고, 아이템 url을 참고로 본문을 직접 가져왔을 수도 있다.(봇이 안다닌다니 그건 아닐지도.) 어쨌거나 심지어 본문 자체가 검색엔진에 노출된다 해서 우리가 저작권에 대해 뭐라하지 않는 것처럼, RSS역시 RSS에 전문을 싣지 않는다해도 아이템URL을 통해 봇을 보내 본문을 긁어왔다면 그냥 검색이라 우기고 차라리 뭐라하지도 못했을 텐데... 파란 기획자는 좀 반성을 해야하겠다.
검색엔진의 룰을 준수하지 못하고, 서비스 운영이 미숙한 점은 욕먹어 지당하지만 그외에는 흠...

개인이 모은 RSS를 타인에게 제공하는 게 문제일까? hanrss의 '관련 RSS'도 개인이 모은 RSS를 프로파일링해서 타인에게 필터링해 보여주는 서비스인데, 과연 껍데기의 문제인 것인가?

왜이렇게 RSS는 타국에 와서 생고생을 해야하는가. RSS가 이정도이니 hCard나 openID같은 서비스라도 할라치면 아주 볼만하겠구나.

AJAX 응용을 위한 몇가지 Tip

1. Connection을 줄여라.
10초마다 랜덤한 이미지를 DB에서 뽑아와 화면에 뿌려주는 AJAX 루틴이 있다고 하자.

언뜻 보기에 특별한 문제없이 쉽게 구현될 것처럼 보이지만, 실제로는 DB와 HTTP 서버에 꽤 부담을 주게 된다. 실제로 가장 많은 리소스와 시간이 소요되는 것은 바로 이 커넥션 할당부분이다. 알고리즘은 최적화시키고, 데이터는 인덱싱이라도 할 수 있지만, 커넥션 자체에 소요되는 시간은 어떻게도 줄일 수가 없다.

HTTP 프로토콜은 이른바 상태유지가 불가능하다. 그래서 DB 커넥션을 계속 유지하는 것은 어렵다. 물론 EJB등에서 상태세션빈이라든가, 혹은 PHP에서라도 커넥션 유지가 아주 불가능한 것만은 아니다. 다만, 이렇게 커넥션 리소스를 물고 있게 되면 서버자원이 낭비되고 그 결과 다른 접속자의 접속시도가 제한되게 된다. 따라서 대개의 HTTP통신은 Request를 하고 Response가 돌아오는 짧은 시간동안만 커넥션을 물고 있게 한다.

이런 관계로, 10초마다 AJAX를 이용해 이미지를 뽑아오는 기법같은 건, 평균적으로 한 사용자가 1분간 페이지를 유지한다고 하면, AJAX를 쓰지 않았을 때보다 상대적으로 600%의 커넥션 소모를 일으키게 된다.
사장님께 가서 서버와 회선이 모자라니 600% 증설해주세요.. 라고 하자.

권고사직되고 싶지는 않고, 10초마다 랜덤이미지를 1분간 보여주고 싶다면...
AJAX를 쓰지말고 그냥 일반 페이지를 request할 때, 한번의 커넥션 상태에서 6장의 이미지를 랜덤하게 뽑아 JavaScript 혹은 JSON 혹은 숨겨둔 HTML...로 보낸 후, 그냥 JavaScript로 10초마다 로테이팅 시키자.
1분이 모자른 듯 싶다면 아예 10분어치를 한번에 쿼리해서 가져오는 것이 9분 어치가 안쓰여도 AJAX를 쓰는 것보다는 더 이득이다.

2. 메인 컨텐트에 AJAX를 쓰지마라.
카테고리나 메뉴나 광고에 AJAX를 쓰는 것 까지는 좋다.
그러나 메인 컨텐트에 AJAX를 쓰지 말 것.
JavaScript가 disable한 상태이거나 회선불량이라던가, Script Error라든가... 이런 경우 컨텐트가 없는 빈 페이지만 덩그마니 남게 된다.
메뉴나, 사이드바같은 건 어찌되도 좋아, 안보여도 좋고. 허나 메인 컨텐트는 안보이면 안되지...
이 페이지의 핵심기능이 최신글목록이라면, 최신글목록 만은 AJAX를 쓰지 말라는 뜻.
꼭, 반드시 AJAX를 써야겠다면, 그 경우에도 아무것도 없는 빈 컨텐트를 AJAX로 가져와서 채우지 말고, 일단 서버스크립트로 최초 컨텐트는 채워둔 후에, 필요에 따라 AJAX로 변경하는 것은 봐줄만 하겠다. 그래야 AJAX가 안되어도 빈 페이지를 보고 있는 일은 없을 테니까.

3. 크리티컬하지 않은 것만 AJAX를 쓰자.
일단 AJAX를 쓴다 함은, 대개, 현재 보고 있는 페이지와 URL이 매칭되지 않는다는 뜻. 리마커블하게 링크가 걸려야하는 컨텐트, 페이지들은 AJAX를 자제함이 좋다.
그럼 어떤 경우가 AJAX이용에 적당할까?
검색결과페이지는 상대적으로 URL이 덜 중요한 페이지이다. 내용이 수시로 바뀌는 메인 인덱스 페이지라면 AJAX를 써도 크게 상관은 없겠다.
또 덜 중요한 기능- 커멘트 작성같은 -들은 URL과 상관없기 때문에 AJAX로 구현해도 무방하겠다.

4. DB 쿼리보다는 스태틱 빌드를 노려라.
어떤 컨텐트 데이터가 수정, 삭제는 거의 일어나지 않되 추가는 종종 일어나고, 조회는 그 몇배로 자주 이루어지고 있다면, 이에 대한 view를 AJAX로 직접 컨트롤하려는 것은 매우 어리석은 일이다.
이런 경우에는 스태틱 빌드를 쓰자.
데이터가 변경될 때마다 해당 컨텐트를 파일로 만들고(HTML이든, XML이든, JSON이든...) AJAX로는 이 빌드된 파일을 접근해서 읽어오는 쪽이 훨씬 효율적이다.
왜냐하면,
이렇게 빌드된 파일은 다른 사용자들도 동일한 쿼리를 위해 DB커넥션을 할 필요가 없이 바로 그 결과를 파일로 공유할 수 있기 때문이고,
AJAX에 장애가 생겨도 이 파일 주소를 페이지안에 link 나 longdesc로 명기해두었다면 접근성등에 문제가 없어지며,
파일을 읽는 속도가 DB에 연결하는 속도보다는 훨씬 더 빠르기 때문이다.

만약 쿼리가 여러 종류이되 많은 사용자 사이에서 반복되어 나오는 종류라면 최초 쿼리 시에만 DB에서 조회한 후, 그 결과를 파일로 만들고 그 파일이름을 쿼리의 해쉬값을 이용해서 관리하면 여러종류의 쿼리에도 대응할 수 있겠다. 물론 이 경우에는 사용자 맞춤 컨텐트 같은 것에는 약간 힘들 수도 있긴 하다.

5.로드밸런싱(?)
현실적으로 비싼 로드밸런싱 장비를 사용하지 못한다면, 혹은 여러대의 웹서버를 돌릴 수 없다면...
(그런데, 대부분의 웹서비스는, 사실 왠만한 리눅스머신가지고도 훌륭히 퍼포먼스를 낼 수 있다. 이런 커넥션의 낭비만 아니라면...)
간단하게는 서브도메인을 이용해서 일시적으로 커넥션을 늘려서 응답을 빠르게 할 수도 있겠다.
예를 들어 이미지는 image1.sample.com, image2.sample.com, image3.sample.com (내부적으로는 모두 같은 이미지서버)에서 번갈아가며 가져오도록 HTML코드를 작성하고 (그럴려면 일반적인 막코딩으로는 힘들고 별도로 템플릿생성엔진같은 것을 써야하겠다.), ajax call같은 경우에도 ajaxserver1.sample.com, ajaxserver2.sample.com, ajaxserver3.sample.com(역시 내부적으로는 같은 서버)로 분산 호출하게 되면 커넥션이 늘어나게 되어 응답이 빠르다.
그러나 이 방법은 서버의 리소스 사용량을 늘리게 되고, 사용자가 워낙 많은 경우에는 그 시간동안 다른 사용자의 커넥션이 제한되므로 꼭 좋은 방법이라고만은 할 수 없겠다.

AJAX의 오남용을 보고 있자니, Anti-AJAXian이 될 것 만 같은 이 찜찜함...

가변폭 레이아웃 전략

최근 liquid 또는 elastic design 에 대한 관심들이 많아지고 있는데요,
개인적으로 liquid나 elastic design의 유용함을 인정하면서도 실제 현장에서 쓰기에는 힘들지 않나.. 하는 생각을 하고 있었습니다.

여러가지 이유가 있겠으나, 하나의 디자인으로 여러 종류의 디바이스 혹은 브라우저 크기에 맞춰 유동적으로 변하는게 그리 쉽지많은 않거든요. 아무리 빗겨흘리고 늘렸다 줄였다 해도 고정된 디자인의 한계를 벗어나기는 어렵더군요.

그런 생각을 하면서 요즘의 liquid, elastic 유행(?)에 한발 물러서 있던 차에...

오래간만에 ALA에 괜찮은 기법이 하나 소개되었습니다. liquid 또는 elastic 의 한계를 뛰어넘은, 가변폭에 맞춘 디자인 변경입니다.

간단하게 js 파일을 하나 추가함으로써 어떠한 환경에서도 보기 좋은 웹페이지를 만들어낼 수 있겠더군요. 물론 주의깊게 작성을 하긴 해야겠습니다만.

그동안 어떻게 CSS를 조작해서 가변폭 레이아웃을 만족스럽게 표현할까 고민했었는데 좋은 참고가 될 듯 해서 소개합니다.

샘플 1, 샘플 2 (모든 링크는 Shift+Click 으로 새창에서 뜹니다.)

liquid 디자인과 zoom 디자인을 넘어서 adaptive 레이아웃이라는 선언도 곱씹어볼만 한데다, 샘플 2에 Tab 디자인은 영감을 팍팍주는 인터페이스네요. 그동안 ALA에 올라오는 글들이 영양가가 좀 떨어지지 않나 싶었는데 이번엔 아주 Two Thumbs Up!입니다.

AJAX와 퍼포먼스

기획자 나잘난양과 개발자 도야근군, 그리고 옵저버 김단지군은 오늘도 신규서비스 개발을 위한 회의에 열심입니다.

...

나잘난양 : 그러면 우리도 AJAX를 이용한 기술적 진보가 있다고 보도자료를 뿌릴 수 있다는 거지요?

도야근군 : 게다가 AJAX를 쓰면 퍼포먼스도 올라가지요.

나잘난양 : 우리 서비스 메인 페이지가 A,B,C,D의 네 개의 섹션으로 이루어져있는데 각 섹션을 AJAX로 불러오게 될 때 퍼포먼스적 이점이 뭐지요?

도야근군 : 우선 A,B,C,D의 각 섹션의 내용을 페이지가 로딩 된 후에 불러오기 때문에 페이지의 데이터전송량을 줄일 수 있지요.

김단지군 : 그런데 페이지 전체로 보면 결국 전송량은 똑같은 것 아닌가요? 오히려 각 섹션별로 각각 커넥션 헤더가 들어가기 때문에 데이터 전송량은 AJAX쪽이 더 많을 것 같은데요?

도야근군 : 커넥션 헤더는 무시할 만한 수치죠. 핵심은 비동기화 커넥션이기 때문에 각 섹션이 각각 동시에 데이터를 가져올 수도 있으니까 로딩시간이 훨씬 단축되죠.

김단지군 : 그 말은 일단 이 페이지를 다 띄우기 위해서는 기존방식보다 HTTP커넥션을 더 소모한다는 거네요? 동시접속자가 몰릴 때에는 문제가 될 수도 있겠는데요?

도야근군 : 서버의 성능을 믿으세요. -_-a 어쨌거나 잘게 나눠서 여러 커넥션으로 동시에 가져오니까 더 빠르다구요.

김단지군 : 하지만 어떤 커넥션은 HTTP특성상 리스폰스되지 않을 수도 있는데, 그럴 때는 그냥 완성되지 못한 페이지 상태이구요?

도야근군 : 그건 통짜 페이지에서도 마찬가지 잖아요? 예를 들어 5번의 커넥션 중 한번이 실패한다면 통짜페이지는 5번 중에 1번은 못띄운단 소리잖아요.

김단지군 : 그러면 4개의 섹션 + 1개의 페이지로 구성된 이 페이지는 섹션 중의 한개는 매번 로딩할 때마다 안뜨는 셈이겠군요.

나잘난양 : 페이지가 통째로 안뜨는 것보다야 낫겠죠.

김단지군 : 뭐, 어차피 HTTP 커넥션 오류는 흔한 일은 아니니까요.

나잘난양 : 다음 이야기를 해보죠. 핵심 컨텐트인 섹션 A는 10분마다 혹은 사용자가 버튼을 누르면 리프레쉬되는 거지요?

도야근군 : 네. 리프레쉬될 때 다른 섹션과는 달리 섹션 A만 리프레쉬되므로 다 로딩할 필요가 없지요.

김단지군 : 그런데 누가 10분이 넘게 같은 페이지를 보고 있지요? 어차피 여기는 메인 페이지라서 다른 페이지로 가는 인덱스 역할이잖아요?

나잘난양 : 사용자들을 무시하지 마셈. 우리의 충성스런 사용자들은 우리 서비스를 백그라운드로 띄워놓고 틈날 때마다 다시 꺼내본다구요. 게다가 우리는 전부 새창띄우기니까 메인페이지가 사라지지 않잖아요.

김단지군 : 그럼 사용자가 보고 있지 않아도 10분마다 리프레쉬가 일어난다는 거네요? 정말로 데이터 절약되는 거 맞아요?

나잘난양 : 그럼 자동 리프레쉬는 빼고, 버튼을 눌렀을 때만 리프레쉬되도록 할까요?

도야근군 : 그럴 줄 알고 이미 구현해놨습니다.

김단지군 : 난 F5키가 편한데...

도야근군 : 전체 페이지 리로딩은 낭비라니깐요.

김단지군 : 사용자들은 습관적으로 F5를 누르게 되어있다구요. 공통되고 일관된 인터페이스라는 건 무시하기 어려운 거에요.

나잘난양 : 사용법 계몽 이벤트라도 할까요? -_-a

김단지군 : 그렇다면 이번에는 반대로 습관적으로 "갱신" 버튼을 눌러대는 경우에는요? 아직 새 데이터가 추가되지 않았는데도 갱신요청을 하면 또 DB커넥션을 해야 하나요?

도야근군 : 최종요청시간을 가지고 있다가 리퀘스트쿼리시에 같이 넘기던가...

김단지군 : 아, 데이터가 또 늘어나네요?

도야근군 : 그까이꺼 몇바이트나 된다고. 그럼 아예 스태틱 빌드로 섹션의 해당 HTML을 10분마다 빌드한 뒤 무조건 그걸 가져다가 뿌려주는 걸로 하지요.

김단지군 : DB트랜잭션은 줄테니 확실히 이득 맞군요. 괘찮은 아이디어입니다. 근데... 그렇게 스태틱 빌드를 하려면 AJAX는 뭐하러 쓰는거죠? 그냥 가져다가 뿌려주기만 할 건데?

도야근군 : ...

나잘난양 : 섹션 D는 어때요? 이건 1초마다 갱신이니까 이건 확실히 AJAX의 효과가 있겠죠?

도야근군 : 아, 당연히 그렇겠지요. 이건 어차피 1초마다 갱신이니 스태틱 빌드도 불가능하니까요.

김단지군 : 우리 플랫폼이 혹시 DB커넥션을 세션상태에서 유지할 수 있는 시스템인가요? EJB나 뭐 그런 걸로?

도야근군 : LAMP인데요.. 게다가 커넥션을 세션 상태에서 유지하고 있는 건 HTTP특성상 별로 좋지 않은 방법이라서.

김단지군 : 그렇다면 1초마다 새 DB커넥션이 이루어지고 쿼리가 일어난다는 거군요. 그것도 동접자 마다...

도야근군 : 뭐, 어쩔 수 없죠. AJAX를 쓰려면 그 정도는 감수해야.

김단지군 : 하긴, 트렌드니까요.

나잘난양 : 보도자료는 중요한 거라구요.

...

CC를 사용자에게 맡겨두지 않기.

또 한동안 블로고스피어를 달군 저작권 문제.

I. 일단 정리.
1) CCL(Creative Common License)은 무단펌질을 막아주는 부적, 마법의 딱지가 아니다.
2) CCL은 저작권을 보호(좁은 의미로, 펌질금지)한다기 보다는, 합법적으로 사용권을 주기 위한 방법이다.
- 부연 : CCL을 붙이건 말건, 무조건 개인의 창조적 작업의 결과물인 컨텐트는 그 저작권을 보호받는다. 그러다보니, 저작자가 선의로 공유를 하고 싶어도 무조건 저작권을 지키든가, 포기하든가 양자 택일만 가능하므로, 좀 더 합법적으로 컨텐트를 사용할 수 있다는 '선언'이다.

II. 사용자는 사악???
그러니까, CCL을 붙여놨으니까 나는 안심. 이건 정말 순진한 이야기. CC가 뭔지 모르는 사람들이 이 세상의 99%. 아마도 IE사용자보다도 많을 걸?
어쨌거나 이미지 딱지 하나 붙여놓았다고 맘 푹놓고 있다가 누가 불펌(?)해갔다고 길길이 날뛰어봤자 소잃고 외양간 고치는 격.
사용자는 CC가 뭔지도 모르고, 이해하지도 못한다. 아무리 친절히 설명해준다 하더라도. 게다가 페이지 어디에 CC가 붙어 있는지 알지도 못하고. 또 웹페이지에 붙어 있는 CC는 애매한 면이 있어서, 페이지 전체가 CC의 영향을 받는다는 건지, 특정 컨텐트가 CC의 영향을 받는 건지...
사용자에게 너무 많은 것을 기대하지 말 것.

III. 올바르게 CC 붙이기.
CC는 그냥 이미지 딱지만 붙여 놓는다고 되는게 아니다. 붙이는 것도 다 규칙이 있고, 표준이 있는 법. 올바르게 붙어있지 않은 CC는 아무 의미도 없다.

아래처럼 붙어야 올바르게 CC가 붙어 있는 것.

[html]

This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 2.5 License.[/html]

자신의 웹사이트는 제대로 CC가 붙어 있는지 확인해보자.

IV. 공은 개발자에게로.
[php]
class MICROFORMAT {
private $str;
private $domain;
private $xpath;
private $dom;

public function __construct($str, $domain) //{{{
{
$this->str = $str;
$this->domain = $domain;

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

$this->xpath = new DOMXPath( $this->dom );
} //}}}

public function get_license() //{{{
{
$events = $this->xpath->query(".//*[contains(@rel, 'license')]/@href");
foreach($events as $event) {
$license["{$event->nodeValue}"] = $event->nodeValue;
}
return $license;
}//}}}

...
}
[/php]

이런 코드(여기서는 PHP5인데, 다른 언어로도 뭐.. 알아서들 잘 하시겠지만)만 있으면 CCL라이센스(는 물론이고, GPL이라든가 기타 microformat에 rel-license로 정의된 모든 라이센스들)를 가져 올 수 있다.

가져와서?

애시당초 WYSIWYG이라는 표준과는 삼만광년 떨어진 비시맨틱한 도구에 의존하는 경우에야 Ctrl+C/Ctrl+V를 어떻게 하긴 어렵겠지만 그 잘하는 "오른쪽 버튼 막기" 기능대신, "지금 보시는 컨텐트는 원저자를 표시하고, 비영리 목적으로 사용하며, 변경을 금지하는 조건으로 사용가능합니다."라는 메시지를 띄워준다거나... IE는 클립보드 컨트롤이 가능하므로 라이센스관련 처리가 가능할테고.
혹은 Tong같은 펌질도구라면 펌질된 부분 밑에 라이센스 관련 처리를 해준다든가(원저작자를 표시해야 한다면 자동으로 원저자를 붙여주고, 변경이 금지라면 사용자가 추가, 변경을 못하게 입력창을 잠궈버린다든가...)...
뭐, 이쯤은 되어야 메이커도 자기 할일 다했다고 사용자에게 책임을 미룰 수 있지 않을까? 무조건 고객센터로 증명서 보내라는 헛소리는 말고 말이지.

V. 수수께끼로 마치며.

하나,
여기, "원저자 표시, 비영리 목적, 변경 금지"라이센스가 걸려있는 컨텐트가 하나 있다고 하자.
네이버(편의상.)에서 이 컨텐트를 수집해 가서 대문에 걸어준다면, 네이버는 "비영리목적"이라는 라이센스규칙을 어긴 것일까? 분명히 네이버의 대문은 사용자를 유인해서 광고수익을 올리려는 의도가 있는 것일텐데 말이지.

둘,
똑같은 컨텐트를 어느 블로거가 펌질해서(물론 원저자도 표시했고 변경도 하지 않았지만...) 자신의 블로그에 올렸다고 하자.
이 블로거의 블로그의 한켠에 Google AdSense가 붙어 있다면 이 블로거는 "비영리목적" 라이센스를 어긴 것일까? AdSense는 분명히 광고수익을 올리기 위한 영리행위인데 말이지...

셋,
똑같은 컨텐트를 어느 메타블로그가 수집해가서 자신의 frame안에서 보여준다고 하자(올블로그같은 방식). 그 메타블로그가 수익이 없다가 어느날부터 광고를 붙이기 시작했다면 이 메타블로그는 라이센스의 비영리목적을 어긴 것일까?

집단소송일어나기 딱 좋군. 언젠가 다들 큰 코 다치리.

올블로그 개편

복잡하고,
페이지 안에서 너무 많은 것을 보여주려 하고 있으며,
역으로 그래서 오히려 아무것도 눈에 들어오지 않고,
익숙해지면 다를 수도 있겠지만 익숙해지고 싶지 않고(굳이 그런 노력을 들여야 할 이유도 없고...),
아무래도 안다니게 되지 싶다.

하긴, 어차피 올블로그에서 새롭고 재미있는 블로거를 만나본지가 언제던가. 리더기에 추가해본 지도 오래.
역시 알음알음 링크타고 다니는 쪽이 더 효율적으로 의미있는 뉴페이스를 만나게 된다고 생각.

뭐, 내가 쓰든 안쓰든 대세와는 상관없지만.

AJAX와 개인정보피싱

AJAX 프로그래밍을 하다보니 찜찜한 것들이 있습니다.

전통적인 Web 개발에서는 페이지 단위 상태라는 오토마타를 따르기 때문에 문제가 없었는데, AJAX와 브라우저의 자동입력 기능이 합쳐지면 개인정보보안상 큰 구멍이 생길 수도 있겠더군요.

AJAX를 이용하면 사용자가 Form서브밋을 하지않더라도 강제로 Form 서브밋을 하게 할 수 있습니다. 예를 들어, input field에 onChange 이벤트를 감시하고 있다가 내용이 바뀌면 HTTPRequest를 이용해 사용자 몰래 데이터를 서버로 보낼 수 있겠지요.

물론, 정상적인, 신뢰할 수 있는 사이트에서는 그럴 일이 없겠지만, 악의를 가진 피싱 사이트에서라면 얼마든지 이를 응용해서 사용자 정보를 채갈 수 있을 듯 합니다. 사용자는 그저 페이지를 열어본 것 뿐인데도 말이지요.

대부분의 자동입력기능은 field의 name을 가지고 판단합니다. 인기있는 사이트들의 페이지를 열어보면, 어떤 field name을 채와야 할지 알 수 있습니다.

그리고는 겉으로 보기에는 아무런 해가 될 것 같지 않은 페이지를 사용자에게 보내는 것이지요. 설문조사나 경품안내 등의 껍데기를 하구요.

(* 블로그 이전으로 예전 샘플 사라짐 *)

설문조사를 작성하면서 필드간에 이동을 위해 Tab을 누른 사용자는 자신도 모르게 자신의 email을 납치당합니다.

혹은 좀 더 직접적인 방법으로 유혹할 수도 있겠지요. "이건 그냥 샘플입니다. 타이핑만 하세요. [확인]버튼을 누르실 필요는 없습니다."

이 코드가 실제로 그렇게 피싱이 가능한지는 잘 모르겠습니다. 다만 가능성이 있는 것 같은데 다른 분들은 어떻게 생각하세요?

마이너의 설움

논란이 된다는 파란 블로그스페이스가 어떤지 궁금하여 접속을 해보았는데...

1: paran.com 초기화면이 와장창 깨져요. Mac 쓰는 설움이지요. 일본에 있어서 가뜩이나 회선 속도도 느린데, 담배 반대 피고 올 시간이 걸리네요.

2: 그 22만건의 글 중에 나는 없네요. 나는 저작권도 상관없고, 스크랩을 하건 긁어가건 신경도 안쓰는데... 왜 민감한 사람들 것만 가져가서 평지풍파를 만들고, 나처럼 맘이 넉넉한 사람은...

3: 프레임 속에 프레임 속에 프레임 속에 프레임 속에... :)

4: RSS를 너무 순진하게들 생각하시네요. :) 그냥 콱 RSS내려버리세요. 저작권이니 이런 거 신경쓰여서 어디 블로깅이나 하겠어요?

5: CC는 저작권을 지키려고 붙이는 게 아니라, 저작권을 풀어주려고 붙이는 거에요. (CC를 붙이든 말든 저작권은 지켜지는게 기본이긴 하지요.)

6: CC는 마법의 부적이 아니에요. 붙이기만 해두면 자동으로 스크랩이 막아진다거나 하는 건 아니지요. 그건 그렇고 가져가는 쪽도 microformat과 rdf에 대해 무지하긴 하지만, 붙여놓는 쪽도 국내에서는 50보 100보인 셈이니 누굴 탓하겠어요. (하긴, 이건 블로거의 문제가 아니라 블로그 메이커의 문제긴 하죠.)

스크랩을 왜할까?

무슨, "웹의 본질은 링크..." 이 따위 교과서적인 소리를 하려는 게 아닙니다....

도대체 스크랩을 왜 할까요?.
답은, 그이외의 수단이 마땅치 않아서입니다..

저는 스크랩을 합니다. 현재까지는 가장 비용이 적게 드는 정보관리 방법이기 때문이죠.

사람들이 웹 페이지를 스크랩하는 이유는, 거기에 정보가 들어있기 때문입니다. 이것을 링크로 대신하라는 것은 조금 무리가 있는데, 왜냐하면 링크는 "레퍼런스"이지, 그 자체가 어떤 유용한 정보를 담고 있는 건 아니기 때문이지요.

링크 자체로는 아무런 유용한 정보를 주지 못합니다. 그 링크가 무엇에 관한 링크인지, 어떤 내용을 담고 있는지조차 알 수가 없지요. (그래서 pretty url같은 것을 필요로 하는 게지요.)

하면, 링크를 다시 별도의 관리작업을 해주어야 하는데, 링크에 대한 부가설명을 달고, 링크의 범주를 분류하고... 뭐 이런 식으로요. 한때 제로보드가 유행했을 때 사람들마다 빠지지 않고 만들었던 게시판이 바로 "즐겨찾기" 게시판이었습니다. 링크를 관리하기 위한 나름의 자구책이었던 셈입니다.
현재 잘나간다는 digg.com이나 del.icio.us같은 소셜 리마커블 인포메이션 서비스들도 결국은 이러한 링크(페이지단위 URL)에 대한 관리 수준을 벗어나지 못하고 있습니다.
브라우저의 북마크는 더 불편하니 말할 것도 없겠지요.

뭐니뭐니해도 페이지를 통채로 스크랩하는 방법이야 말로 일반 소비자가 현재의 웹환경에서 외부정보를 획득,보관,관리하는 가장 저렴한 방법입니다.

이보다 더 효율적인 방법을 제공해주지 않는 한, 스크랩을 하지 말라고 아무리 외쳐봤자, 빵대신 케익을 먹으라는 소리로 들릴 뿐이지요.

그럼, 해결책은 없을까요?

스크랩이 가장 저렴한 방법 중 하나이긴 해도, 효율은 그닥 좋은 편은 아닙니다.
왜냐하면, 스크랩을 통해 정보를 이용하기 위해서는 다시, "스크랩된 내용을 읽고, 필요한 정보를 찾고, 그것을 다시 재분류하는 과정"이 필요하기 때문이지요.

스크랩이건, 링크건 간에, 암묵적인 동의가 깔린 것은, "웹에서 정보의 최소량은 페이지URL단위"라는 고정관념이지요.
과연 그런가... 하면 그건 아니죠.

URL은 정보관리의 단위로 삼기에는 너무 큽니다. 아무 웹사이트나 들어가서 페이지를 열어보세요. 오만가지 잡다한 정보들이 가득 들어있습니다. 이 페이지에서 정작 내가 다시 사용하기 위해 원하는 정보는 아주 작은 일부일 뿐인데도 한 페이지를 통틀어 링크 혹은 스크랩을 해서 관리합니다. 이거 비효율적이지요.

그렇다면, 저 "아주 작은 일부"를 어떻게 추출해서 관리하게 해줄 것인가... 거기에 핵심포인트가 있겠네요. 하나 더 추가하자면, 나는 그 정보를 "왜" 필요로 하는가도요.

"마우스로 그 부분을 긁어다 붙이기..." 정도의 빈곤한 상상력보다는 더 재미있고, 편한 방법이 확실히 존재할 겁니다... :)

태그가 카테고리가 아니라면...

태그는 카테고리가 아니라고 하니까, 어떤 분이 물으시더군요. 그럼 뭐냐고.

결론부터 말해보지요.
Not Categorizing, But Characterizing

The Best Stuff In The World라는 사이트가 있습니다. 집단지성을 이용한 일종의 랭킹서비스인데요, 여기를 보면 Categorize와 Characterize의 차이를 느낄 수 있습니다.

예를 들어 linux란 word를 보면,

The Best Computer, The Best Things In Life, The Best Desktop Computer, The Best Software, The Best Apple Computer, The Best Operating System, The Best Reason To Buy a Mac, The Best Games Console, The Best Fruit, The Best Brand, The Best *nix, The Best Company, The Best Antivirus, The Best Revolution, The Best Innovation, The Best Firewall, The Best PC, The Best Way To Crash Windows, The Best Ideas, The Best Electronics Brand, The Best Computer Brand, The Best Personal Computer, The Best Overrated Stuff, The Best Fruit To Eat Dried and The Best Eye Candy

라고 붙어 있습니다.

linux는 152명에게 가장 좋은 OS로 꼽혔고(OSX가 242명이긴 하지만.), 78명에게 베스트 소프트웨어로 꼽혔습니다.(FF가 827명이긴 하지만.)

이렇게 보면 “가장 좋은 OS” 혹은 “베스트 소프트웨어”라는 “범주”로 linux를 Categorizing할 수도 있겠지요.

그러나 ‘인생에 가장 멋진 것’이라거나, ‘Windows를 박살내는 좋은 방법’이라는 것으로 ‘linux’를 Categorizing하려면 상식의 저항에 부닥치게 되고, 급기야 ‘말려먹기에 가장 좋은 과일’에 다다르면 카테고리란 과연 무엇인지 회의가들게 될 겁니다.

실은, 우리는 실생활에서도 이미 태그를 많이 보고 있습니다.
미니오디오 하나만 사도 뒷면에 많은 딱지들이 들어있지요. ‘Dolby’, ‘SRS’, ‘TurboBoost’ …
PC를 사도 딱지가 많이 붙어 있습니다. ‘Intel Inside’, ‘EcoGreen’ …
태그란, 그런 성격으로 이해되어야 합니다.
“이 PC는 ‘Intel Inside’의 한 종류야.”가 아니라, “이 PC는 ‘Intel Inside’를 가지고 있어.” 라는.
OO에서 이야기하는 ‘is-a’와 ‘has-a’의 관계라고나 할까요.

만약 웹에서의 태그가 텍스트가 아닌 그래픽이었다면 이런 혼동도 줄지 않았을까 싶어요.

non-text tag로 풀어보는 tag

그래픽 태그 이야기를 했더니 곧바로 메신저로 질문이...

좀 추상적이었던 이전 글은 원래 예전에 쓰다만 것인데, "한님의 초건전사이트 운영자 동맹 포스트"을 보고 갑자기 기억이 나서 글을 완성했습니다. 아무래도 배경 부연이 필요한 것 같아서요.

UserSigs라는 서비스가 있습니다. 포럼이나 블로그 등에 글을 쓰고 자신의 Signature를 남길 때 사용자의 성격에 맞는 그래픽 이미지를 가져다 쓸 수 있게 해주는 일종의 배너셰어 서비스지요.

그러니까,

"저는 나이키브랜드를 좋아하고, 커피에 중독된, 리눅스를 쓰는 공산주의자에요." 라는 자질구레한 설명 대신,

이런 이미지를 가져다 쓰라는 거지요.

'rel="tag"'라는 마이크로 포맷에는 맞지 않지만, 거의 완벽한 태그 활용이라 할 수 있지요. (자동입력이니 태그추천이니 하는 인터페이스가 태그의 전부처럼 이야기되는 요즘입니다만. 그건 오히려 곁가지일 뿐이죠.)

1) 집단지성??
집단 지성은 "의도해서" 이루어지는 것이 아닙니다. 사용자에게 별도의 액션을 요구하는 "소위 집단지성" 시스템은 결코 집단지성이 될 수 없습니다. "투표하세요.", "추천점수를 주세요.", "별점을 매겨주세요." 이런 문장이 들어있는 시스템은 집단지성과는 멀어졌다고 할 수 있지요. 사용자의 "의도적인 행위"가 개입되는 순간 집단지성의 의의는 사라집니다.
UserSig의 Top Image 섹션을 보면 그 차이를 잘 알 수 있습니다. rating, vote, hit, download의 네가지 척도에 따라 각각 높은 점수의 sig들을 보여주는데요,
별도의 액션이 필요한 rating, vote에 등장한 이미지와 별도의 액션 대신 사용자의 이용 액션 그 자체인 hit와 download에 등재된 이미지를 비교해보면 차이를 알 수 있을 겁니다. 어느 쪽이 진짜 top image일까요? 당연히 download가 많이 된 이미지가 진짜 인기 이미지겠지요. (vote와 hit에 같이 상위로 등재된 Led-Zeppelin sig는 메인에 노출된 최근등록 sig라서입니다. hit수에 비해 download가 적다는 것이 실제로 그 sig가 그다지 인기가 있지 않다는 뜻이지요.)

rating, vote에 참여자 수가 적어서 그런게 아니냐는 지적이 있을 수 있습니다만, 본질적으로, 집단지성은 무의식의 발현 집합을 근거로 합니다. 에, 다시 말하자면, 집단지성을 체크하는데 rating이나 vote는 그다지 좋은 수단이 아니라는 거지요. '월척'의 폐해가 있을지언정 별점보다는 조회수 많은 글이 더 집단지성을 잘 표현하는 셈입니다. "집단지성"이 반드시 똑똑하란 법은 없으니까요.

2) collabulary
태그의 단점으로 늘상 지적되는 모호성, 다형성을 collabulary로 극복하려는 시도들이 많이 있습니다. 태그추천 같은 기능도 그 일종일텐데요. UserSigs에서는 등록된 이미지를 가져다 쓴다는 형태로 collabulary를 구현하고 있습니다.
collabulary구현시 주의할 점은, collabulary가 강제성을 가져서는 안된다는 거지요. 그러니까,
"'Mac OS X'라는 태그보다는 'MacOSX'라는 태그가 '좋아요.' (이 태그와 관련된 서비스를 사용하려면 Mac OS X라고 쓰지는 마세요, 그건 다른 사용자들이 적게 쓰거든요. MacOSX라는 태그를 꼭 쓰라는 건 아니지만, 그래도 쓰면 훨씬훨씬 더 좋아요.)"
라는 형태는 문제가 있다는 거지요.
애초에 태그의 장점이 모호성과 다형성에 있는데(위에서는 단점이라고는 했지만.) 굳이 그 모호성과 다형성을 강제로 억제하려는 시도자체에 태그 시스템의 모순이 발생하게 되는거지요.
"타인을 위한 태깅"이라는 관점에서 벗어날 필요가 있겠습니다. 누가 뭐래도, 내 맘에 들면 태깅은 이것으로, 타인에 대한 배려는 그 다음... 그리고 그 때에야 vocabulary의 필요성이 생기는 거고, 그것을 collabulary로 구현하는 게 맞습니다.
UserSigs에서 같은 대상에 대한 sig라 하더라도 자기 취향에 맞는 이미지로 골라 선택하거나, 그나마도 맘에 안들면 스스로 만들어 올리도록 하는 체계에서 힌트를 얻을 수 있겠지요.

3. NO more Category
"linux-user"가 나에 대한 Categorizing인가요? 아니죠. "linux-user"는 나에 대한 Characterizing이지요. 그러니까, "linux-user"를 클릭하면 linux-users를 볼 수 있습니다." 같은 서비스는 태그라는 관점에서 보면 그다지 재미있지 않은 접근이지요.(의미가 없다는 건 아닙니다만.)
즉, "linux-user에 누구누구가 속해있느냐"는 건 전통적인 Categorizing 접근 방법이고, "누구는 어떤 속성(character)을 가지고 있느냐" 는게 Characterizing 접근 방법입니다.
그런 면에서 본다면, 차라리 TatterTools 옛날 버전에서 쓰던 keyword라는 것이 오히려 태그의 본래 개념에 더 가깝다 할 수 있습니다.
이 태그에 어떤 글이 붙어 있느냐...보다는 이 글에 어떤 태그들이 붙어 있느냐가 더 좋은 태그의 활용법이 되는 힌트가 될 수 있겠죠.

4. Is really useful?
태그를 사용하는 서비스들은 한번씩 반문해볼 필요가 있습니다.
과연 이 서비스에서 "태그"가 진짜로 유용한 것인가? 트렌드로서의 거품을 걷고, 실제로 정보공학적으로 유의미한 인터페이스가 되기 위해서는, 이 시스템 체계에서 이 태그가 진짜로 쓸모 있는지 진지하게 생각해봐야 합니다.
그저 멀티 카테고리의 다른 이름이 아닌가, 중복패쓰를 양산하는 비효율적인 정보경로는 아닌가, 의미없고 쓰이지 않는, 오히려 방해가 되는 쓰레기 정보의 생산방법은 아닌가...
태그에 대해 많은 고민이 필요하겠지요...

메타론칭 for web 2.0 (?)

한가해지고, 공짜서버라도 생기게 되면 꼭 만들어보고 싶은 사이트가 두개 있는데,
하나는 SF전문 북크로싱 사이트이고, 또 하나는 와인정보 셰어 사이트입니다. 둘다 그냥 취미생활.

오늘 보니, BottleTalk라는 사이트가 딱 제가 생각하던 그대로의 와인정보나눔 사이트이네요.
전형적인 web 2.0(여기에서는 그저 트렌드, 유행 정도의 의미) 사이트. 기능도 그렇고, 인터페이스나 룩앤필조차도. 이제는 매쉬업 혹은 ShareInfo 사이트들은 모두 공장에서 찍어낸 것처럼 보일 정도.

그러고 보니, 이런 웹2.0(?) 서비스를 만들어주는 도구를 만들면 장사가 좀 되려나 하는 생각이 드는군요.
그러니까 블로그를 만드는 블로깅 도구처럼, 이런 사이트를 간단히 클릭 몇 번으로 만들 수 있는 서비스 혹은 프로그램.

“안경소녀 정보공유하기” 라든가, “지도위에 라면맛집을 모아봅시다.”라든가 하는게, 꼭 비즈니스 기업이나 전문프로그래머들만이 할 수 있는 영역은 아니잖아요? 오히려 일반인들이 저런 욕구는 더 크지요. 다만 방법을 모르고 기술이 없을 뿐, 그렇다고 남이 제공해주기만 기다리고 있는 것은 답답하고, 또 남(기업)이 제공해주는 서비스는 왠지 쓰기 싫고.(포털에서 블로그를 제공해줘도 굳이 설치형 블로그를 쓰고, 포털에서 카페를 제공해줘도 굳이 제로보드를 쓰는 사람들이 있는 것 마냥.)
게다가 기업들은 어떻게든 수익을 내야하므로, 저런 ‘돈안되는 웹 2.0′에는 뛰어들기가 오히려 어렵지요. 사실 어느 회사가 “와인정보공유서비스”를 진지하게 생각해보겠어요? 한가한 프로그래머 중에 와인홀릭이 있다면 모를까, 힘든 일이지요. (위의 BottleTalk를 만든 친구들이 걸어놓은 링크를 보세요. 이런 깜찍한 친구들! :))

매쉬업 서비스의 한계(조만간 포스팅 예정)를 고민하다가 나온 생각인데, 뭐, 결론은 이렇습니다.
매쉬업, 너무 좋아하지 마세요. 돈도 안되고, 진입장벽도 낮고. 봉이 김선달같은 비즈니스 모델이 계속 성공할리 없잖아요?

RSS의 법적 해석

민노씨께서 메일로 조선일보의 RSS관련한 사항을 질문해오셨는데, 메일로 답을 드리려다가 공개적으로 포스팅할 가치가 있을 듯 해서 적어봅니다.

“그 피드를 조선닷컴에 ‘제공’하는 데에 어떤 ‘계약’도 필요로 하지 않는 건가요? 그냥 조선닷컴에서는 ‘가져와서’ 쓰면 되는건지요? 이 점이 가장 궁금합니다”.

일단, 전략이나 가치문제를 떠나서(그런 부분은 제 소관사항이 아닌지라.) RSS의 사용과 관련된 법적 부분을 좀 살펴보자면…

핵심사항은 이것입니다.
“RSS는 컨텐트 자체가 아니라, 그 컨텐트를 설명하는 메타정보일 뿐.”

많은 오해가, “RSS = 컨텐트”라는 인식에서 발생하곤 하지요.
RSS는 컨텐트에 관한 메타정보를 담아 배포하는 규격입니다. 이 메타정보는, 컨텐트의 이름, URL, 작성자, 작성시각… 등등등을 포함하고 있지요. 이것들은 저작권(1차 및 2차 ‘창조물’에 대한 권리)과는 상관없는 객관적 사실입니다. 즉, RSS자체는 저작권의 보호대상이 아니라는 것이지요.
따라서 적합하게 제공된 RSS를 이용한다는 것은 통념적인 한도내에서 저작권과는 관계가 없습니다. 저작권이 보호하는 것은 오리지널 컨텐트이지, 그 컨텐트에 대한 “설명”은 아니니까요.

문제는, RSS에 컨텐트 자체 혹은 일부를 담았을 경우의 저작권입니다.

이곳을 보시면 미국의 경우이긴 하지만 참고하실 만한게 있으실 겁니다.
요약하자면,

1) 상업적인 이득을 얻는가.
2) 재가공 정도가 어떠한가.
3) 사용량이 어느정도인가.(웹사이트를 몽땅 긁는 수준인가, 아니면 요약이나 설명을 제공하는 정도인가..)
4) 원본의 시장을 침해하는 것은 아닌가.

이런 사항들을 따져봐서 오리지널 컨텐트의 저작권을 침해하는지를 판단하게 됩니다.

상식(?)적으로 생각했을 때, RSS제공자(=컨텐트저작자)가 제공하는 RSS는, 저작자 자신의 기준에 맞게 공개해도 좋을 만큼을 공개하는 약속이라고 할 수 있습니다. 이에 따라 다양한 수준으로 RSS를 제공할 수 있지요.
이미지까지 몽땅 contents:encoded에 집어넣어 전문을 공개하는 경우도 있고, 아주 일부만 살짝 공개하는 경우도 있고, 또 컨텐트 자체가 아닌 단순한 간접설명(description / excerpt)만 제공하는 경우도 있고, 또 컨텐트에 대한 설명은 전혀없이 url만 제공하는 경우가 있습니다.(참고) 바꿔말하자면, RSS는 충분히 제공자가 의식적으로 인지한 상태에서 공개수준을 결정할 수 있다는 소리입니다. (그 권한이 자유롭지 못한 국내 포털 블로그들은 논외.) 최소한 신문사라면 자신들이 RSS를 왜, 어떻게, 얼마나 제공할 지를 결정할 능력이 있다는 것이지요.

따라서 이렇게 의식적으로 수준이 결정되어 제공된 RSS는 보호받아야 하는 저작물로서의 가치가 높다고 볼 수는 없습니다.

그러므로 RSS를 사용하는 것 자체에 대해서는 딱히 문제될 게 없습니다. 공개를 할 지 말지, 어느 수준까지 할지를 제공자가 결정했다면 그걸로 끝. 수집자가 가져갈 지 안가져갈지, 어떻게 가져갈 지, 가져가서 무엇에 쓸 지는 제공자가 왈가왈부할 꺼리가 아니지요.

일단 RSS를 제공하고, 누군가 그것을 가져가서 쓰게 되었을 때, 그것이 제공자의 오리지널 컨텐트에 대한 저작권까지 침해하는 것이 아닌 한 RSS의 사용에 특별한 문제는 없습니다.

뭐, 원론적인 이야기를 길게 늘여썼는데.(실은 이미 전에 몇번 이와 관련된 포스팅을 했었죠.)
한국, 그것도 신문에 관해서라면 좀 특이한 문제가 있습니다.
바로 “온신협 저작권”이라는 게 문제지요.

“온신협”에서 신문기사 링크에 관해 너무 아전인수격으로 해석을 해놓아서, 이미 아시겠지만 프레임링크는 물론이고, 링크자체도 엄격하게 제한을 두고 있습니다. 심지어 기사의 “제목”을 그대로 쓰는 것 자체도 저작권의 위반이라고 주장하고 있지요.

옛날에 이와 관련해 포스팅한 적이 있습니다.

저작권법상 RSS는 불법??
이해불가 딥링크

음.. 지금보니 오늘의 사태(?)를 예견한 선구자적 포스팅이었군요. 조선일보를 예로 드는 예지력까지!(^_^)

결론내자면 이렇습니다.
1) RSS의 취지만 놓고 보자면 조선일보의 새로운 서비스는 아무런 문제가 되지 않습니다. 오히려 좋은 RSS활용법 중 하나라고도 할 수 있겠지요.
2) 그러나 “온신협”의 관점으로 보자면 자가당착 모순에 빠지는 웃기는 상태이기도 하지요.

에, 민노씨께서 질문하신 부분에 대한 답변은 1)로 갈음하겠습니다.

OSX에 APM설치하기

일본에서 임시로 묵고 있는 곳에 아직 인터넷이 연결되지 않았습니다. 긴긴 밤(?)에 FootballManager만 끌어안고 있는 것도 질려서 뭔가 좀 영양가 있는 것을 해볼까 하다가 인터넷이 안되니 할 수 있는 게 없더군요. 심심풀이 개발이라도 해볼까 해서 맥북프로에 개발환경을 구축해볼까했습니다.

그래서 OSX에 APM설치하기인데요…
너무 간단해서. -_-a

1. Apache 설치하기
OSX에는 Apache가 기본내장되어있습니다. -_-a
즉, 개인용으로 쓴다해도 개인 홈페이지 정도는 인터넷만 연결되면 별도의 호스팅없이 운영할 수 있다는 소리죠.
“시스템 환경설정(Preference)”에서 “인터넷&네트워크” -> “공유” -> “개인웹공유”에 체크만 해주면 됩니다.
체크안해도 127.0.0.1에서 localhost로 접근할 수 있습니다.

httpd.conf는 /private/etc/httpd/ 에 있습니다.

한가지 주의할 점은, OSX에서는 기본적으로 root계정이 활성화되지 않기 때문에 httpd.conf등을 수정하기 위한 su획득을 위해서는 root를 활성화시키고 패스워드를 변경할 필요가 있습니다.
유틸리티안에 들어있는 NetInfo관리자를 열어서 users중에 root를 찾아 ‘*’로 되어있는 패스워드를 변경하면 됩니다. 그리고 터미널에서 ’su root’를 해보세요.

httpd.conf외에 계정별로 /private/etc/httpd/users/ 에 계정별 conf파일이 있습니다. .htaccess등을 이용하려면 여기에서 계정별로 설정을 바꿔주세요. (자세한 것은 아파치 매뉴얼을 참고하세요.)

기본적으로 설치되어있는 아파치 버전은 1.3.2입니다. Apache2가 아닌 것이 좀 그렇지만, PHP5, MySQL5등을 설치하는데 아무런 문제가 없으니 통과. 꼭 Apache2가 필요하신 분은 소스코드를 빌드하거나 별도로 패키지를 찾아 다운받아 설치하셔야 됩니다. 이 경우에는 별도의 prefPanel로 관리해야되므로 좀 귀찮지요.

2. PHP5 설치하기
http://www.entropy.ch/software/macosx/php/에 가서 자신의 환경에 맞는 패키지를 찾아 다운받은 후, 더블클릭해서 설치하면 끝. -_-a

3. MySQL5 설치하기
http://dev.mysql.com/downloads/mysql/5.0.html에 가서 자신의 환경에 맞는 패키지를 찾아 다운받은 후, 더블클릭해서 설치하면 끝. -_-a

지금까지 APM설치해본 중에 제일 간단하군요. ㅎㅎ

참고링크 :
http://www.oreilly.com/pub/ct/49

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

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은 더이상 필요없어지누나…

웃자고 쓰는글 2.

“네, 이 기능에 치명적인 버그가 있다는 건 처음부터 알고 있습니다. 하지만 이 기능을 사용하는 사람은 전체의 1%도 안된다구요. 굳이 그 사람들을 위해 이 버그를 잡을 필요는 없다구요.”

“OOP가 더 효율적인 공정을 가져온다구요? 협력개발과 유지보수가 쉽다굽쇼? 무슨 소리에요. 저는 기존의 방식으로도 얼마든지 잘해왔어요. 지금 그까짓 외부업체와의 협력때문에 5년간 갈고 닦은 제 실력을 무시하는건가요? 상당히 기분나쁘군요.”

“우리 사이트가 대박을 쳤다구요? 회원 가입자 수가 1천명이 넘었다구요? 그래서 1001명이 사용가능하게 해달라구요? 그건 안되겠어요. 이 시스템은 애초에 1천명 정도만 쓰게 설계되었거든요. 처음부터 말씀하셨으면 1001명을 고려했겠지만 그런 말씀도 없으셨는데다 시간도 없었잖아요. 이제와서 1001명을 위한 사이트로 고치려면 얼마나 많은 비용이 들겠어요. 안타깝지만 이게 현실이죠.”

“네? 확장가능성은 설계할 때 기본 아니냐구요? 사장님이 직접 개발해보시죠? 그런 꿈같은 이야기는 연봉 더 많이 받는 사람한테나 요구하세요. 남들도 말만 그렇게 하는거지 실제로 확장기능 따위 개발안해요. 새 서비스 만들 때나 한번 고려해보죠.”

“저희 안전에어백은 현대자동차에 최적화되어있습니다. 앞으로는 해외로의 진출이 희망입니다. 저희 에어백을 사용하고 싶으신 고객은 타고 계신 자동차를 현대자동차로 바꾸세요. 안전을 위해서라면 그 정도 수고는 감수해야죠. 특히 차를 두대이상 소유하고 계신 분들은 필요에 따라 바꿔 타시면 되니까 별 문제없잖아요?”

“네? 다른 자동차에는 왜 쓸 수 없냐구요? 이보세요! 모르시면 가만히 계세요. 에어백을 장착하는 나사가 얼마나 특수한건데요. 공업표준 나사로 바꾸면 비용이 너무 많이 든단 말이에요. 설령 그렇다 하더라도 그걸 위해 얼마나 많은 기술자들이 달라붙어서 설계를 변경해야 하는지 아세요? 겨우 나사 하나 바꾸면 된다고 쉽게 말씀하지 마세요!”

“그치만 솔직히 말해서 현실을 너무 모르시는 것 같아요. 요즘 미국사람들도 영문법따위 잘 모른다구요. 저는 미국 친구들과 언제나 슬랭으로 의사소통을 해왔고, 그들은 제 말을 전부 이해했어요. 이제와서 문법이 올바르지 않다고 제 논문을 캔슬시킨다니 교수님은 문법편집증 환자임에 틀림없어요. 논문에 문법을 지키라는 게 어디 법으로 명시되어 있나요? 그건 어디까지나 권고일 뿐 강제력은 없는거에요.”

“그러니까, 10년 전에는 아무 소리 없더니, 이제와서 수입산 쇠고기가 광우병 위험이 있다고 호들갑떨면 나같은 수입업자는 어쩌란 말인가요? 적어도 나는 수입쇠고기의 위생과 안전을 위해 철저히 냉장유통과정을 관리하고 있다구요. 발생할 지 어쩔지도 확실히 모르면서 목소리만 큰 광우병 경고론자들이야말로 겨우 요사이 1,2년새에 나타나 마치 국민건강은 혼자 책임지는 것처럼 구는데 솔직히 아니꼽지요. 무슨 종교도 아니고 아주 잘난 척하는게 눈꼴시러우니 그냥 닥치고 있길 바래요. 댁들 때문에 광우병에 대해서는 생각도 하기 싫소이다.”

PHP를 사용하는 데는 엄청난 비용이 든다.

웃자고 쓰는 글.

PHP를 사용하는데는 엄청나게 많은 비용이 듭니다.

단순히 유지, 보수, 개편에서 뿐만이 아니라 아니라 새로 시작하는 사이트에서도 마찬가지입니다. 게다가 PHP를 사용한다고 해서 완전한 프리웨어/오픈소스로 인한 비용절감이 되는 것도 아닌지라, 예를 들어 Zend Guard라도 설치하려면 단지 몇십만원 하는 서버구축 비용보다도 더 많은 비용을 또 쏟아야 합니다. 가끔은 유료인 라이브러리 패키지를 구매해야 프로그램 개발이 용이할 때도 있구요.
특히, 구성원이 PHP에 대한 이해도가 떨어질 때에는 학습하는 시간과 비용이 장난이 아닙니다. 그뿐아니라 그 시간동안 진행되어야 할 프로젝트가 미뤄지는 것은 기업 입장으로써는 엄청나게 많은 기회 비용을 잃게 되는 것입니다. 그에 비해 PHP5의 OO적 특성을 제대로 이해하는 사람은 극소수이고요.
확실히 PHP는 무료이고 개발속도가 빠르고, 그런 것을 홍보해나가는 것은 좋지만, 이게 더 저렴한데도 왜 선택안하냐는 이야기는 안했으면 좋겠습니다. 절대 싸지 않으니까요.

웹표준의 경제학 -3-

CN님의 포스트에 달린 덧글을 보다가…

첫번째 문제.
전산쟁이라면 Greedy 알고리즘에 관해 한번쯤은 들어보았을 것이다.
간단히 설명하자면, 서울에서 부산까지 버스를 갈아타고 가야할 때, “가장 빨리 출발하는 차를 잡아타고 가다보면 가장 빨리 도착한다.”는 전략이라고 할 수 있다. 그러니까, 일단 고속터미널에서 현재 가장 빨리 출발하는 것이 수원행 버스라면 그것을 타고 가서 수원터미널에서 역시 가장 빨리 출발하는 광주행버스를 타고, 광주에 도착해선 가장 빨리 출발하는 대구행 버스를 타고…. 뭐 이런 알고리즘이다.
때로는 Greedy알고리즘은 가장 효율적인 결과를 주기도 하지만, 대개의 경우 좀 더 최적화된 알고리즘이 있기 마련이다. 대신, 구현이 용이하고 이해하기가 쉽다는 장점이 있다.
따라서 실제로 Greedy알고리즘은 빠른 개발과 확인이 필요한 테스트단계에서나 쓰이는게 대세이다. 정확한 테스트 결과를 얻게 되면 정식 배포전에는 좀더 효율적인 알고리즘으로 대체된다.
만약 Greedy알고리즘을 좀 더 효율적인 알고리즘으로 교체하지 않는다면 어떻게 될까? 당연한 이야기겠지만, 실행시간이 오래걸리거나 리소스가 많이 사용된다거나 하는 불편이 있을 수 있겠다.
여기, 이전 버전까지 개발을 담당했던 개발자가 Greedy알고리즘으로 된 로직을 그대로 둔 채로 퇴직하는 바람에 당신이 프로젝트를 담당하게 되었다고 하자. 이럴 경우, 당신은 이 Greedy알고리즘을 투덜거리면서 새 알고리즘으로 바꿔야할 것이고 그러기 위해 시간과 노력 비용이 투자되어야 한다. 이 비용은 당신때문에 발생하는 비용일까?

두번째 문제.
예전 어떤 프로젝트에서 실제 경험했던 문제.
런칭한 새 서비스는 테스트도 완벽하게 통과했고, 처음 3개월간은 아무런 문제없이 잘 돌아갔었다. 그러나 그 후, 누적되는 데이터를 DB가 감당하지 못하여 서비스에 중대한 문제가 발생하게 되었다. 전적으로 사용량을 잘못 예측한 기획자와, 대용량 서비스를 염두에 두지 않고 DB를 설계한 개발자의 잘못이라 할 수 있겠다.
이 문제를 해결하기 위해서(해결할 생각이라면) 매우 많은 인력과 시간과 비용이 필요하고, 심지어 새로 서비스를 만드는 것보다도 많이 들지도 모른다. 과연 이렇게 비용을 들여서까지 이 문제를 해결해야만 하는가?

답은 각자 생각해보도록 하시고.

웹표준에 대한 비용문제에 빠지지 않고 등장하는 발언 중 하나는,
“예상외로 많은 비용”이라는 점이다. (일단, 코더 하나 뽑으면 될 거라 생각하는 수준이 대부분, 그러니 “예상”보다 비용이 많이 들 수 밖에.)

* “분석/설계 단계에서부터 웹표준을 고려하지 않았다면 나중에 웹표준을 적용하기 위한 수정은 비싼 비용을 치루어야만 한다.”
1) 그럴 수도…
2) 허나, 그 책임은 일차적으로 “분석/설계 단계에서 웹표준을 고려하지 않은” 기획자/아키텍트에게 있다.
3) 명색이 “웹” 기획자 또는 아키텍트라면 “웹”에 대해 고려해야만 했다.
4) 물론, 뭐, 형편상 못했을 수도 있겠다. 허나 기획이나 설계단계에서 놓쳤다 하더라도, 개발단계에서 Model과 View를 충분히 분리한 구조로 개발했다면, 차후 웹표준을 위해 수정이 필요하더라도 View단의 수정만으로 훌륭히 대처할 수 있었을 것이다.
5) 그러나 웹표준을 적용하기 위해 DB자체를 풀어헤쳐야 한다거나, 라이브러리를 전부 새로 만들어야 한다든가, 프레임워크를 통째로 갈아치워야 할 정도라면, 애초에 개발자체가 별로 아름답지 못하게 이루어졌다는 폭로일 뿐이다. 이건 웹표준을 떠나서 개발자로서 부끄러워해야 할 부분이다.
6) 또는, 어쩌면 개발자가 아직도 웹표준에 대한 기술이 부족한 것일 뿐일 수도 있다. 가끔 보면 “표준을 위한 표준”에 목이 매어 어렵게 돌아가는 케이스가 보이기도 하기 때문이다.
7) 하긴 컨베이어 벨트 시스템의 Waterfall개발방식을 아직도 고수하는 환경이라면 어느 누구한테 책임을 묻는다는 것 조차 언감생심이겠다. “사실은 우리가 뭔가 꽤 잘못해왔고, 여전히 잘못하고 있긴 한데, 그걸 드러내서 인정하기는 좀 그렇고, 당분간 고치기에는 능력이 딸리고… 뭐, 우리가 일부러 그럴려는 건 아니고 우리에게 주어진 현실이 그랬고, 그 때는 다들 그걸로 좋았으니까…”

웹표준적용에 들어가는 비용은 웹표준 때문에 발생하는 것이 아니라, “이전에 잘못 만들어왔기에” 발생하는 비용이다.
결국, 웹표준 적용에 비용이 많이 든다면, 그건 지금까지 그만큼 무언가 놓치고 간과했고 실수하고 잘못해왔다는 고백일뿐.

이런 글을 쓰면 씁쓸해 하는 사람들이 많을 지도.(난 불친절한 금자씨라서. ^^;;)
헌데, 생각해보면,
그 비용은 회사로서는 당연히 지불해야하는 비용이고, 대개의 경우 개개 개발자들의 책임으로 지불해야하는 비용은 아니다. (그래서 웹표준 컨설팅때에는 언제나 경영자의 의지를 가장 중요한 선행조건으로 강조하고 있다.)
게다가 그동안 이 부분은 국내에서는 너나 할 것 없이 취약한 부분이었기 때문에, 지난 개발에 대해 누구에게 직접적으로 잘못을 묻기도 어렵다. 즉, 조건없는 면죄부가 주어진거나 다름없는 셈.
그러므로 이 문제에 관해 일개 말단 직원의 가장 속편한 반응은 “지나간 일은 지나간 일이고, 앞으로 잘하면 되지”인 셈이다. 책임이 있다면 경영진이나 최소한 프로젝트의 책임위치인 매니저나 리더가 져야 할 뿐. 헌데도 왜들 이리도 애써 변명(?)하고 저항(?)하는지 모를 일이다. (이게 모두 노무현 탓 아니, 불친절한 금자씨 때문이라면 할 말 없고.)

트랙백의 가치

트랙백의 방향
트랙백은 가치가 있어야 한다.

“A에서 B로 트랙백을 보내다”의 본시 의미는,
1) A는 B를 링크하고 있다는 신고 (Send Ping to Auto-Link)
2) B에게 A가 존재함을 알림 (Notify Ping)

“B가 A로부터 트랙백을 받는다”의 본시 의미는,
1) A가 B를 링크했을 거라는 가정
2) A가 B에게 흥미있을 거라는 가정

트랙백은 “링크”도, “원격댓글”도 아닌, 그저 “알림”일 뿐.
링크나 원격댓글은, 트랙백의 활용법 중 아주 극히 일부분. 비록 그게 전부인 것처럼 보일지라도.

하, 농부가 되고 싶다고?

“하, 농부가 되고 싶다고? 농사는 쉽지 않단다, 꼬마야. 하지만 농사는 정직한 노동이고 먹거리를 마련해주는 일이지. 농사에 대해 얼마나 알고 있니?”

“실은 잘 몰라요. 하지만 바로 시작하고 싶어요.”

“좋은 태도구나. 화단은 있니?”

“아니요. 실제로 갖고 싶진 않았어요.”

“흠. 뭐 어쨌든, 아마도 옥수수를 좀 심어보는 걸로 시작하라고 권할 수 있겠구나. 어렵지 않단다. 씨뿌리는 법에 대해 좋은 공부가 될 테고, 덧붙여 날씨 징조에 대해 기본적인 것들을 내가 가르쳐줄 수도 있지.”

“무슨 소리세요? 저는 씨뿌리기나 날씨 따위에 대해 듣고 싶은 게 아니에요. 저는 농부가 되고 싶은 거라구요.”

“무슨 말이니, 꼬마야? 씨를 뿌리고 물을 주고 거름을 주는 일들을 하지 않고 어떻게 곡식을 키우겠니? 어떻게 날씨에 대해 아무것도 모르면서 수확을 거둘 수 있을거라 생각하지?”

“나는 그저 농부가 되고 싶을 뿐인데 왜 내가 먼지투성이가 되어 땅이나 파고, 기상학에 대한 지루한 설교를 들어야 하는거죠?”

—

“하, 조각가가 되고 싶다고? 그래, 매우 어렵고 오랜 과정을 거쳐야 하지만 기술을 익히고 나면 충분한 보상이 돌아오지. 먼저, 여기 망치와 정이 있고, 활석덩어리가 있구나, 이걸로 시작하자. 구를 깎아보거라, 그러면-”

“잠시만요. 저는 암석조각에는 관심이 없는데요. 저는 위대한 조각가가 되고 싶어요.”

“뭐라고?”

“말씀드렸잖아요, 저는 활석에는 관심이…”

“들었단다. 단지 나는 네 말이 무슨 뜻인지 이해할 수 없었어.”

“조각가의 목표는 예술을 창조하는 것이잖아요? 그게 제가 하고 싶은거에요. 예술품을 창조하는 거지요, 이런 우스꽝스러운 도구로 장난치거나 먼지를 뒤집어쓰는 거 말고요.”

“잠깐 기다려보거라. 그러니까 조각가가 되고 싶지만 돌을 깎는 법은 배우고 싶지 않다는게냐? 화강암이나 대리석 등의 속성에 대해 배우는 건 싫다고?”

“맞아요. 왜 그래야 하는데요?”

“글쎄, 이제 무슨 말인지 알겠다. 들어봐라 꼬마야, 돌의 성질에 대해 모르는 채로 조각가가 될 수는 없단다. 그건 불가능해.”

“웃기지 마세요. 아마도 이딴 건 당신께는 흥미있는 것이겠지요. 하지만 전 예술가라구요. 창조만이 저의 일이에요. 그리고 솔직히 말해서 왜 이따위 것들로 저를 귀찮게 하는지 미스테리네요. 절 가르치실 생각이나 있으신거에요?”

—

“하, 그래픽 디자이너가 되고 싶다고? Edward Tufte가 그의 다양한 작품에서 명확히 보여주는 바대로, 그래픽 디자인은 오래되고 품격있는 전통을 가지고 있지. 오늘날에는 종이 위 만큼이나 컴퓨터에서 이루어지고 있지. 따라서 종이와 잉크에 대해 알아야하는 것 만큼이나 컴퓨터와 일러스트레이터같은 프로그램에 대해서도 알아두는 것도 중요하단다. 나아가, 어떤 매체를 택하든지간에, 인간의 뇌와 인지감각, 색채학 그리고 기타등등 다양한 것들에 대한 연구가 필수적이지. 아, 미안, 질문할 게 있니?”

“네, 그럼 언제 디자인을 시작하죠?”

“흠, 물론 내가 방금 언급한 디자인의 다양한 분야들에 대해 공부를 하는 것이 디자인의 기본이 되지. 당연한 말이지만, 학습의 왕도는 직접 해보는 것이란다.”

“아뇨, 아뇨. 지금까지는 제가 흥미없어하는 것들에 대해 한보따리 풀어놓으셨잖아요. 제가 하고 싶은 건 디자인이라구요. 컴퓨터프로그램이나 심리학같은 지루한 것들을 배우는 게 아니라요.”

“내 말을 건성으로 들었나보구나. 디자이너가 되려면 그런 것들이 필요하단다. 그것들이 없다면 넌 그저 낙서나 하는 셈이지. 네 작업에 대한 이해가 없으면서 어떻게 위대한 디자인을 만들 수 있겠니? 예를 들어, 잘못된 색배합은 네가 전달하려는 메시지를 훼손시킬 수 있단다. 또는 그 대신 강제적으로 메시지를 훼손하기 위해 의도적으로 선택된 색 배합은 디자인에 또다른 의미를 부여하기도 하지.”

“진짜로 그런 것들을 믿으세요? 슬프네요. 보세요. 당신이 그런 것들에 흥미있다고 해서 다른 사람들에게까지 강제로 그런 것들을 강요해도 된다는 뜻은 아니에요. 저는 여기 디자이너가 되러 온 것이지 심리학자나 컴퓨터광이나 기타 당신이 원하는 그런 사람이 되러온 것은 아니라구요.”

“하지만 이런 기초에 관심이 없다면 디자인은 너랑은 맞지 않는 것 같구나.”

“오, 어련하시겠어요. 당신의 주장을 인정하지 않는 사람들을 만날 때마다 당신은 당신의 성스러운 일에 동참하기에는 맞지 않는다고 딱 잘라 말하시겠지요, 안그래요? 당신의 하찮은 규칙을 지키는 사람들만 인정할테죠? 맞죠? 당신은 그저 당신의 상아탑을 유지하고 싶기만 한 거에요. 그렇죠? 좋은 디자이너가 되기 위해 무엇을 해야하는지에 관심있는 척 하는 것은 그만두시죠. 당신은 현실이랑 괴리되어 있는게 틀림없거든요.”

—

“하, 웹 디자이너가 되고 싶다고? 오, 그거 좋지. 좋아. 배워야 할게 좀 있긴 하지만 바로 시작하면 좋겠구나. 먼저 이야기할 것은 마크업 랭귀지와 시맨틱에 관해서란다. 그러고나면, CSS의 동작원리와 그것이 옛날 방식과는 어떻게 다른지에 대해서 시간을 투자하게 될거다. 거기다 텍스트 플로우와 “한계없는 캔버스” 플로우에 대한 기초를 하고 그 다음에는-”

“잠깐만요. 윤똑똑이씨. 저는 웹 디자이너가 되고 싶은 거지, 컴퓨터학자가 되고 싶은 건 아니거든요?”

from : Eric Meyer - Stand Up For Your Rights!
(I have no right or permission to translate this article. so, If Eric or Vitamin mind, I’ll remove.)

불친절한 금자씨, 그 두번째 이야기. 강조는 내가 임의로.

닭쫓던 개 지붕 쳐다보기

empas가 SK컴에 인수된다라…

SK는 뭐하러 엠파스를 인수한 걸까?
엠파스에 있는 많은 서비스들은 어디로 가게 되는 것일까?
예를 들어 블로그… SK가 가지고 있는 Tong, 이글루스, 싸이월드 외에 엠파스 블로그는 어떤 위상이 되는 걸까?
검색은? 메일은?

공공연히 떠돌던, “경쟁사 인수해서 더 못크게 막아놓기” 전술의 일환인 것일까?

까마귀 날자 배떨어지고 닭쫓던 개 지붕 쳐다보는 중… -_-a

블로그의 미래,3P (Publish 편)

세상만물, 변하지 않고 그대로인 것은 아무것도 없듯이 블로그의 미래는 어떻게 되는 것일까요? 밥먹으면서 잠깐 상상의 나래를 펼쳐보는 것도 재미있을 법합니다.

미래의 블로그의 세가지 키워드는 3P가 될 것입니다.

Personal, Private, Publish

오늘은 Publish의 관점에서 본 미래의 블로그에 관한 내용입니다.

1) Publish
블로그의 의의 중 한가지는, 누구나 이전보다 용이하게 Web Publishing이 가능해졌다는 점입니다. 우리나라는 초고속 인터넷과 제로보드등의 인프라에 힘입어 그나마 1인 1홈페이지 비슷하게 흘러왔지만, 여전히 웹상에 무언가를 용이하게 발표하기란 어려운 일이지요. 이런 점에서 가입형이든 설치형이든 블로그 서비스는 대중이 뭔가를 발화하려고 하는 욕구를 충족시키는 데 큰 역할을 하고 있습니다.

현재의 블로그의 Publishing은 주로 텍스트 위주에, 시간적 순서에 의지하는 실정입니다만, 사람들은 깨달아버렸습니다. 특별한 기술적 뒷받침이 없어도, 카페 등의 커뮤니티에 의존하지 않고도 자신이 말하고자 하는 바를 불특정 다수에게 배포할 수 있는 방법을요. 무엇보다도, 그저 간단하게 브라우저를 띄워서 하고자 하는 말을 적기만 해도 모든 과정이 간단히 이루어짐을 경험으로 알게 되었습니다. 사실 블로그의 가장 큰 의미는 여기에 있다 해도 과언은 아니지요.

Publish라는 관점에서 블로그를 바라본다면 가능한 미래가 몇가지 보입니다.
우선, Publish의 대상이 더이상 텍스트에 의존하지 않게 될 것입니다. 이미 Podcast는 더이상 낯선 용어가 아니고, YouTube는 VideoCast도 어려운 일이 아님을 보여주고 있지요.
최근 나오는 디지털 카메라들은 GPS연동 기능이 달려있습니다. 앞으로는 사진을 찍고, Picasa나 iPhoto같은 프로그램/웹서비스로 정리하면 자동으로 앨범이 만들어지고, 어디에서 어떻게 찍었는지, 보이스메모등이 첨부된 웹갤러리를 원클릭으로 쉽게 만들어질 겁니다. 지역정보를 이용해 구글맵같은 지도에서 지역별로 내 사진을 올리거나 하는 매쉬업서비스도 이루어지겠죠.(실은 이미 움직이고들 있습니다.)
단순한 텍스트를 벗어나 사진, 음성, 동영상등 다양한 포맷들을 다룰 것입니다. 심지어 “데이터”들도 가공되어 publish될 것입니다. 예를 들자면, 프로그램 코드라든가, 판매실적, 학교과제 같은 것들도 말이지요.

이쯤 되면 “블로그”라기 보다는 CMS(Content Management System)나, DMS(Data Management System) 혹은 WPS(Web Publishing System)이라고 불리우려나요. 하긴 지금도 몇몇 블로그 도구들은 Personal CMS를 표방하고 나서고 있지요.

어쩌면 “블로그” 자체는 사라질 지도 모릅니다. 그러나 “컨텐트를 작성해서 인터넷상에서 발표/배포하기”에 대한 경험은 오롯이 남아 새로운 형태의 웹프로슈머 활동이 이루어질 것입니다.
더이상 웹상에서 워드 문서를 작성하거나, 스프레드 쉬트를 사용하는 것이 꿈같은 일은 아니죠. 사실, 웹상에서 이러한 문서를 작성하는 것이 중요한 것이 아니라, 그것을 웹이라는 플랫폼을 통하여 다른 이와 공유할 수 있게 배포할 수 있다는 쪽이 더 중요한 키포인트입니다.

단지 “웹”이라는 한정된 공간도 더이상은 아닐 것입니다. 모블로그는 인프라가 감당되는 이제야 새로운 가능성이 열리기 시작했고, XML은 플랫폼/디바이스간의 자유로운 데이터교환을 책임지기 시작했습니다. 만들어진 컨텐트는 단순히 웹브라우저에서의 열람만이 아니라, PDF등의 범용문서, 오프라인에서의 도서출판(인쇄, 제본), 방송(Broad/NarrowCasting), 다른 프로그램의 먹이(Feed)로 쓰이게 되겠지요.

사람들은 자신의 생각을 글로 적어 인터넷에 올리고, 자신이 본 것을 사진이나 동영상으로 찍어 인터넷에 올리며, 자신이 말하고 만든 소리를 녹음해서 인터넷에 올릴 겁니다. 또 사람들은 자신이 가지고 있는 것을 정리해서 데이터로 만들어 공개하고, 다른 이들이 만든 컨텐트를 가져다 활용할 겁니다. 다른 이와 협업하는 것이 전혀 이상하지 않음을, 손해보는 것이 아님을 위키페디아로부터 배웠거든요.

블로그의 Publish라는 개념은 우리에게 더 많은 것을 공개하고, 그 공개된 것을 이용할 수 있게 훈련시킵니다. 앞으로의 블로그 진화의 한 방향은 이러한 publish적 관점에서 다양한 수단과 편의를 제공하는 한편, 그것을 다른 이와 공유하고(심지어 생산단계에서부터), 그 결과를 가공해서 다시 나의 생활에 이용하는 라이프스타일을 만드는 데 큰 역할을 할 것입니다.

Personal과 Private의 관점에서의 블로그는 다음 시간에.

중고책 장사

Fuji S3Pro를 팔고, 애플 맥북 13″ White을 샀습니다. S5Pro가 출시될 때까지 당분간 S2Pro로 버틸 생각이고, 맥북프로외에도 맥북이 하나 더 필요해서 분에 넘치게 두 대의 포터블 맥을 돌리고 있군요. SLR도 노트북도 두대씩 쓰다니 뭔가 좀.. -_-a

두가지 거래 다 이른바 전문 커뮤니티의 장터를 활용했습니다. 왠일인지, 옥션등의 거래 사이트는 더이상 “중고품”에 대한 장사는 안하는 듯 하군요. 설마 안하기야 하겠습니까. 그러나 느낌이 그렇다는 거지요.
소규모 자영업형태의 셀러들한테 옥션은 좋은 마켓플레이스일테고, 소비자한테도 새 물건을 싸게 구입할 수 있는 좋은 기회일 지는 몰라도, 중고거래를 즐겨하는 저같은 이들에게는 왠지 아쉬운 일입니다.
PDA는 TodaysPPC에서, ThinkPad는 IBMMania에서… 이런 식으로 전문 커뮤니티의 장터를 직접 이용하면 거래도 빨리 되어서 좋기는 하지요. 애스크로서비스등이 제공되어 거래 신뢰도등을 제공하는 BM을 만들어보는 것도 틈새를 노려볼 만한 작업인 듯 합니다.

그럼에도 불구하고, 여전히 처치곤란한 아이템은 바로 책입니다.
책은 함부로 폐지로 넘기기에는 아깝지요. 더이상 나한테는 쓸모없는 책일지언정, 그 책과 함께 해온 세월을 생각하자면 선뜻 고물상에 팔아버리기는 힘듭니다. 그렇다고 헌책방에 넘기는 것도 왠지 꺼림직해요.
제일 좋은 건, 이 책을 꼭 필요로 하는 사람한테 “공짜로라도” 주는 거겠지요. 돈을 안받아도 나름 뿌듯합니다. 아마 진짜로 책을 사랑하는 사람들은 다 그럴 겁니다. 책은 빌려주는게 아니라고는 하지만, 읽지도 않는 책, 박스에 담아 창고에 보관하면서 까지 욕심내는 건 잘못된 사랑일지도.

중고책 거래 사이트가 몇개 있긴 합니다만, 만족스럽지 않습니다. 찾는 책이 있다는 보장도 없고, 사용자도 많지 않아서 책 자체가 없습니다. 거래량이 적기 때문에 거래를 기피하는 마이너스 피드백인 상황이지요.

메이저급 인터넷 서점에서 중고책을 다뤄주면 좋을 텐데요. 어차피 도서DB도 갖춰져 있는 마당에, “나의 서재”같은 곳에 팔 책들을 올려놓고, 사용자가 도서 검색을 해서 나오는 단품 페이지에 개인 중고책 판매 섹션도 같이 보내주면 괜찮을 듯 합니다. 거래는 당사자들 간에 하되, 인터넷 서점은 결재관리나 정보관리만 해주는 거지요.

혹시 새책이 안팔릴까봐…라면, 나온지 1년 이상된 책만… 이라든가, 품절이나 절판된 책에 한해… 라는 단서를 붙이면 되지 않을까요? 얼마전 어떤 만화책 한질을 사려다가 중간에 이가 빠진 듯 한권이 품절이 되는 바람에 울며 겨자먹기로 다른 곳에서 찾아서 채워넣은 기억이 나네요. 대부분의 인터넷 서점 이용자들은 최저가를 기준으로 삼지만, 어느 정도 이용사이트가 정해지면, 그다음부터는 왠만해서는 다른 사이트를 이용하지 않거든요. 유일하게 다른 인터넷 서점으로 바꾸는 이유는 찾는 책이 없을 때인데, 이렇게 품절이나 절판된 책이라 해도 중고거래가 가능하다면 다른 사이트로 넘어가는 것을 막아줄 텐데요.

오늘도 품절된 책 페이지를 보며 어디가서 사야하나 고민중입니다.

Google Docs & Spreadsheet 오픈

Google Docs와 Spreadsheet가 오픈되었습니다.

http://docs.google.com

물론 당연히 구글 계정이 있어야 합니다.

아마도 이 때문에 Writely.com의 사이트 업데이트가 진행되었었나 보군요.

사용해본 소감은, 꽤 쓸만하다는 것. 하긴 쓸만하지 않다면 구글이 인수하거나 오픈하지 않았겠지요.

웹상에서 오피스를 사용한다는 것이 데스크탑과 다른 가장 큰 강점이라면, Mobility와 Collaboration의 획득일 겁니다. 테스트 해본 바로는 두가지 다 합격점. 약간 아쉬운 점이라면, 생성된 문서를 공유할 때 좀 더 편리하고 풍부한 인프라가 갖춰지고, 기업이나 단체 등의 내부 인트라넷에 비견할 만한 편의성은 아직 미흡하다는 점.

구글신께서 재채기를 한 번 할 때마다 일희일비하며 지켜보게 되는 군요.

장바구니와 웹2.0이 무슨 관계뇨

이장님의 꼬투리를 보고 생각이 난 김에.

웹 2.0 혁명에 대비하라???

“웹 2.0″이라는 말은 이제 거의 “아햏햏하다”와 동급으로 취급되는가 보다.
굳이 “web 2.0″이라는 외래어나, “아햏햏하다”같은 DC체를 쓸 필요 있는가? 전래되어온 좋은 순 우리말 “거시기”가 있는데. 그러니까, 기사에 나온 표현대로 “거시기”를 적용한 패닉닷컴(http://panic.com/goods)을 보자.

보고 오셨음? 사실 “별 건” 없다우.
드래그&드롭을 이용한 장바구니구현…
이장님 말마따나 드래그&드롭으로 장바구니를 구현한다 해서 티셔츠가 더 잘팔릴리는 만무하다.

확실히 UX면에서 재미있고, 직관적이며, 참신한 인터페이스이긴 한데, 그 자체가 웹 2.0은 아니다. 도대체 어디에 웹 2.0이?
JavaScript로 DynamicHTML을 구현하고 AJAX를 쓰면 웹 2.0이 되는 건 아니다. 기사에 적혀 있는 대로 저 장바구니 어디에 “플랫폼”이 있고, “협업”이 있으며, “인간”이 있단 말인가.

애초에 panic.com이 회자되던 계기는, AJAX와 DHTML로 Flash없이 충분히 Rich한 인터페이스를 구현할 수 있다는 예시였을 뿐. 웹 2.0에는 마치 필수인 것처럼 AJAX가 회자되면서 얼떨결에 panic.com도 슬그머니 웹 2.0이 되어버렸네. 역시 웹 2.0은 최고의 마케팅 용어라니까.

웹 2.0이랑 어떻게든 연관시켜보려면, “panic.com의 장바구니 구현에 사용된 기술이 웹 2.0 개념의 서비스를 제작하는데 활용될 수 있다…”쯤으로 말씀하셨어야지요.

어쨌거나 말 나온 김에, “티셔츠 쇼핑몰 장바구니”가 “웹 2.0″스러워지려면? (AJAX로 Drag&Drop을 구현하면 된다는 바보같은 소리는 말고.)

1) 오프라인에서 핸드폰카메라로 티셔츠 사진을 찍어 전송하면 자동으로 가장 비슷한 색상과 디자인의 티셔츠를 찾아 장바구니에 넣어주는 쇼핑몰…
2) 쇼핑몰 장바구니에 원하는 티셔츠들을 담아놓으면 내 블로그나 웹앨범에 WishList로 자동등록되어 친구들보고 생일선물로 사달라고 졸라댈 수 있는 시스템…
3) 오에카키같은 그림판에 끄적끄적 내 맘대로 디자인을 해놓으면 그 디자인으로 티셔츠가 만들어져 나에게 배송되고, 혹시나 도안을 보고 맘에 들어한 다른 이들도 살 수 있도록 상품으로 등록되어 수익을 나눌 수 있는 주문자형 티셔츠(겸 판매 시스템)
4) 혹은 “여고생들이 사흘 입은 티셔츠(팬티포함)”만 전문적으로 거래가능한 옥션 시스템…

쯤은 되어야 웹 2.0 스럽다고 어디 비벼볼 수 있는 것 아닌가. (물론 이건 어디까지나 그냥 예시. :))

그저 AJAX만 쓰면 웹 2.0이 된다는 미신덕에, 스크립트 범벅인 사이트를 내놓고는 웹 2.0이라는 딱지를 자랑스럽게 붙이는 코메디들만 양산되누나.

그러니 학교에서 필요한 건 웹 2.0에 대한 “e비즈니스 신기술”따위를 가르치는 것이 아니라(웹 2.0이 “기술”인가? -_-a),
인터페이스 공학, 인간 공학, 심리학같은 것에 대해 공부하는 것이 더 중요하다고. 소스코드 30줄로 만들 수 있는 AJAX따위를 가르칠 필요는 없단 말씀.

ps. 작년엔 블루오션때문에 소화불량 걸리게 하시더니, 올해는 웹2.0으로 소화불량 걸리게 하시는 교수님.. T_T

microformat - hCalendar편

microformat에 대한 간단한 설명은 hCard편에서 다뤘으니 생략하고,

역시 마찬가지로, hCalendar를 위해서는 iCalendar에 대해 먼저 공부해야겠습니다. (실은 hCalendar보다 iCalendar에 관한 내용이 거의 전부입니다. ^^;)

그 전에, vCalendar는 “일정”과 관련된 정보를 기술하기 위한 포맷으로 IMC(Internet Mail Consortium)에서 정했었습니다만, iCalendar라는 새 표준(RFC 2445)으로 대체되었습니다. 실제적으로는 vCalendar 2.0이 iCalendar에 해당합니다.
따라서 이미 사용되지 않는 vCalendar에 대한 스펙은 넘어가고, iCalendar를 중심으로 살펴보겠습니다.

iCalendar는 iCal이라고도 불리우며, 이 이름 자체가 맥의 “iCal”이라는 일정관리 프로그램을 언급하기도 합니다. 실제로 iCalendar의 기능을 가장 풍부하게 활용하고 있는 것은 맥의 iCal입니다.

iCalendar에서 다룰 수 있는 것들은, EVENT, TODO, JOURNAL, FREEBUSY, TIMEZONE, ALARM등의 데이터입니다. 각각의 데이터 포맷에 대해서는 RFC 2445를 참조하시면 됩니다.

다음은 이렇게 만들어진 iCalendar 데이터의 샘플입니다.


BEGIN:VCALENDAR
PRODID:-//RDU Software//NONSGML HandCal//EN
VERSION:2.0
BEGIN:VTIMEZONE
TZID:US-Eastern
BEGIN:STANDARD
DTSTART:19981025T020000
RDATE:19981025T020000
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
TZNAME:EST
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:19990404T020000
RDATE:19990404T020000
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
TZNAME:EDT
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
DTSTAMP:19980309T231000Z
UID:guid-1.host1.com
ORGANIZER;ROLE=CHAIR:MAILTO:mrbig@host.com
ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT;CUTYPE=GROUP:
MAILTO:employee-A@host.com
DESCRIPTION:Project XYZ Review Meeting
CATEGORIES:MEETING
CLASS:PUBLIC
CREATED:19980309T130000Z
SUMMARY:XYZ Project Review
DTSTART;TZID=US-Eastern:19980312T083000
DTEND;TZID=US-Eastern:19980312T093000
LOCATION:1CP Conference Room 4350
END:VEVENT
END:VCALENDAR


여기까지만 보면, iCalendar의 역할은 일정관리 프로그램의 데이터저장포맷인가? 하는 생각이 드실 겁니다. 물론 그러한 용도도 있습니다만, 단지 스탠드얼론 어플리케이션에서의 데이터저장포맷을 굳이 표준으로 만들 이유는 없겠죠. iCalendar의 진정한 용도는 교환과 구독, 확장에 있습니다.

Weather Underground 라는 사이트가 있습니다. 전세계의 기상관측소의 데이터를 모아 그 정보를 알려주는 사이트입니다.
서울의 기상정보는 다음 주소에서 알 수 있습니다.
http://www.wunderground.com/cgi-bin/findweather/getForecast?query=seoul
편리한 사이트입니다만, 매번 날씨를 알기 위해 이 페이지에 접속하는 것은 당연하다면 당연하지만 개선의 여지가 있을 듯 합니다.
이럴 때 iCalendar 포맷이 이용됩니다.

예를 들어 맥 사용자라면, iCal에서 해당 iCalendar주소(이 예시에서는 http://www.wunderground.com/auto/ical/global/stations/47117.ics?units=both가 되겠지요.)를 “구독”할 수 있습니다. iCal에서 해당 주소를 feed로 등록시켜 놓으면 자동으로 매번 갱신되는 정보가 해당날짜에 데이터로 들어가 있게됩니다. “일정관리”프로그램 안에서 날씨정보를 한번에 보게 되는 것이지요. 다음 주 휴가기간 동안 서울의 날씨정보를 같이 볼 수 있다면 얼마나 편리할까요?

iCalendar 교환을 위한 사이트도 있습니다.
http://www.icalshare.com/
이곳에 오면 학사일정부터 메이저리그 경기일정까지 (물론 미국기준 -_-a) 다양한 일정을 공유할 수 있습니다.

RSS와도 비슷하지요? iCalendar역시 syndication을 위한 포맷이기 때문입니다.
RSS와 iCalendar의 가장 큰 차이점이라면, RSS는 대개 “최근의 컨텐트 보기”를 위한 구독/배포 포맷인 반면, iCalendar는 “날짜”를 중심으로 동작한다는 점이겠지요.

불행히도, 아직까지 iCalendar 구독이 가능한 어플리케이션은 많지 않습니다. 맥에서 사용되는 iCal이 거의 유일합니다. 물론 대부분의 일정관리 어플리케이션에서 iCalendar포맷으로 내보내기/불러오기는 가능합니다만, feed로 구독하기 기능은 없지요. google Calendar에서도 iCalendar포맷의 feed로 내보내기 기능은 있습니다만 구독하기 기능은 아직 구현되어있지 않습니다.
그래도 덕분에, 회사에서의 공용일정은 google Calendar로 관리하고 그 feed를 받아 집에 있는 iMac에서는 iCal을 이용하여 동기화시키기(비록 일방통행이긴 하지만)같은 작업이 가능해지는 것이지요. (이런 것이 진정 웹 2.0스러운 모습이라 이겁니다. AJAX를 쓴다고 웹 2.0이라는 게 아니라.)

많은 일정관리 프로그램들이 있습니다만, 사용자의 전환비용을 감당하지 못해서 사용자 수를 늘리는 것이 어렵지요. iCalendar Feeding 기능이 있다면 별다른 전환비용없이 새로운 일정관리 프로그램을 이용하기 쉬울텐데 왜들 안하는지 알다가도 모를 일입니다. 다행히 Outlook, Lotus Notes등을 비롯한 많은 일정관리 프로그램들이 점진적으로 iCalendar Feeding기능을 채택할 것이라니 조금 더 기다려야겠지요.
(바꾸어 말하자면, iCalendar Feeding 기능을 제공하는 서비스들이 나중에는 경쟁력을 갖추게 된다는 소리입니다. 아이디어들 챙겨가세요. :))

iCalendar Feeding이 활발해질 가까운 미래의 활용법들을 예상해볼까요?
인터넷서점에 내가 좋아하는 SF작가를 등록해두고, 그 작가의 신작이 발표될 때마다 자동으로 내 일정관리 프로그램에 신간SF의 발매일을 표시해줍니다. 매번 사이트 들락거릴 필요가 없지요. 트래픽 손해가 아니냐구요? 실구매만 일어나면 장땡인게지요. 동창회 홈페이지의 이벤트 게시판에 자식놈 돌잔치 일정을 올려놓습니다. 동창회 홈페이지 자주 들락거리지 않아도 개인 일정관리 프로그램에 자동으로 해당 일정이 들어갈테니 홈페이지 못봐서 못갔다는 핑계는 힘들겠지요.
대학생들의 학사관리 일정을 feeding하면 어떨까요? 아침에 일어나서 일정관리 프로그램을 보면 오늘 3교시 미적분 시간이 교수님 사정으로 휴강되었음을 자동으로 알려줍니다. 이런 게 저 학교다닐 때 있었어야 했어요. 적절한 계산프로그램이 있다면 학생들의 feed를 모아, 공통으로 비는 시간에 세미나일정 맞추기 같은 골치아픈 일도 쉽게 가능하겠지요.
여행사이트에서 여행스케줄을 세우고 그것을 내 일정관리 프로그램으로 구독합니다. 해당 여행지의 당일,해당시의 이벤트 정보가 자동으로 업데이트 됩니다. PDA로 싱크해서 여행갈 때 들고 다니면 가이드가 따로 필요없지요. 덤으로 교통시간표(이것도 “일정”데이터니까요.)까지 스케줄에 맞추어 자동으로 뽑아주니 금상첨화.
극장시간표가 feeding된다면 핸드폰의 LBS서비스와 연동되어, “현재 내가 있는 곳에서 가장 가까운 극장에서 상영하고 있는 영화”같은 것을 모바일 서비스해줄 수도 있겠지요. 데이트할 때 가장 골치아픈 문제가 그것 아닙니까.
물론 위에서 든 예들은 굳이 iCalendar가 아니더라도 데이터 제공업체와 제휴해서 비즈니스 모델로 만들 수도 있겠지요. 굳이 RSS를 제공안하더라도 “최근 게시물데이터”를 스크린 스크래핑할 수는 있는 거잖아요? 그러나 Content 교환을 위해 RSS가 활성화되고 편리하다는 것을 아는 것처럼, Event 교환을 위해 iCalendar는 권장되고 더 널리 쓰여야 합니다.

iCalendar 이야기가 너무 길었군요. 이제 microformat의 hCalendar로 돌아갑시다.
iCalendar는 애플리케이션 데이터라서 웹에서 바로 사용하기에는 무리입니다. RSS처럼 별도의 URL로 만들어 제공하는 방법밖에 없지요. 이게 좀 불편한 것 아닌가… 하는 마음에 웹에서 바로 사용할 수 있는 포맷을 만든 것이 hCalendar입니다.
자세한 스펙은 http://microformats.org/wiki/hcalendar를 참조하시고.

예를 들어, iCalendar로 다음과 같은 데이터가 있다고 한다면,

BEGIN:VCALENDAR
BEGIN:VEVENT
UID:guid-1.host1.com
DTSTAMP:19980309T231000Z
DESCRIPTION:Project XYZ Review Meeting
SUMMARY:XYZ Project Review
DTSTART:19980312T133000Z
DTEND:19980312T143000Z
LOCATION:1CP Conference Room 4350
END:VEVENT
END:VCALENDAR

이 데이터는 hCalendar 포맷을 이용하여 다음처럼 웹에 표시할 수 있습니다.
[html]

XYZ Project Review

Project XYZ Review Meeting

To held on 12 March 1998 from 8:30am EST
until 9:30am EST

Location: 1CP Conference Room 4350

Booked by: guid-1.host1.com on 9 Mar 1998 6:00pm

[/html]

굳이 별도의 URL로 iCalendar를 제공하는 대신 웹페이지 안에 hCalendar 포맷을 써서 바로 표시하자… 이지요. 물론 이게 제대로 활용되려면 데이터를 사용하려는 곳(다른 웹서비스, 일정관리 프로그램들)에서 웹페이지를 파싱할 수 있어야겠습니다만.

hCard의 경우와 마찬가지로 사용한 HTML태그는 중요하지 않습니다. 그보다는 class 이름으로 무엇이 사용되었는가가 중요하지요.
혹시나 해서 Google Calendar의 코드를 보았습니다만, hCalendar 포맷을 쓰고 있진 않더라구요.
다음은 hCalendar포맷을 사용한 사이트, 서비스들의 예입니다.
http://www.thestreet.org.au/whats_on.htm (상연 정보를 알리는데 쓰네요.)
http://www.markthisdate.com/ (캘린더 포탈입니다. :))
http://www.worldcupkickoff.com/ (월드컵 시간표군요.)

사실, 개인적으로는 hCard보다 vCard나 RDF를 선호하는 것처럼, hCalendar보다는 iCalendar가 더 유용하고 널리 쓰이기를 바랍니다. hCalendar를 사용한 HTML은 파싱하는 게 iCalendar보다는 어렵거든요. iCalendar를 제공한다면 굳이 hCalendar를 쓸 필요는 없겠습니다만… 그래도 일정과 관련된 웹페이지를 만들 때 hCalendar 포맷을 쓴다면, 누군가는 그 데이터를 이용해서 좋은 매쉬업 서비스를 만들어 낼 겁니다. 복잡하게 API를 만들어 오픈하는 것보다, 사용하는 데이터를 표준에 맞게 제공하는 것이 훨씬 쉽고 간단합니다.

WYSIWYG vs. WYSIWYM

작년에 한 컨퍼런스에서 웹표준에 관해 강연한 후, 받은 질문 중에 이런 것이 있었습니다.

페이지를 아무리 구조적으로 만든다 해도, 사용자가 WYSIWYG 에디터를 써서 입력한 컨텐트는 구조화가 안되어있는데 이럴 때 웹표준 및 CSS를 어떻게 적용합니까?

어렵죠. 어려운 이야기입니다.
애초에 WYSIWYG란 Structure와는 동떨어진, Presentation을 위한 컨셉이니까요. WYSIWYG을 쓰면 웹표준과는 100% 안맞는다고 해도 틀린 말은 아닙니다.
사실, 웹에디터 모듈뿐만이 아니라, 웹페이지 제작시에도 Dreamweaver나 Namo같은 WYSIWG 도구를 쓰면 웹표준을 맞추는게 상당히 어려워집니다. Dreamweaver 최신 버전에서는 많은 기능향상이 있긴 했습니다만, 그럼에도 불구하고, 주의깊게 사용하지 않으면 웹표준을 적용하는 것이 쉽다고는 할 수 없습니다.

What You See Is What You Get.
말은 좋습니다만, 문제는 “보기 좋은 떡이 먹기 좋은 떡은 아닐 수 도 있다”는 것이지요.

이 문제가 1년 내내 화두처럼 머리속에 남아있게 되네요.

1년이 지나서 나름대로 얻은 해답은 WYSIWYM입니다.

What You See Is What You Mean. (실은 What You Get Is What You Mean쪽이 더 뜻이 통하는 것 같지만, 이미 굳어진 용어라서. :))

Lyx라는 LaTeX의 프론트엔드 프로그램이 있습니다. 이 Lyx에서 채택하고 있는 것이 WYSIWYM입니다. 보이는 그대로 똑같이 출력되는 것이 아니라, 출력될 결과와 “대충 비슷하게” 편집화면에서 보여줍니다. 똑같이 출력되지 않고 “대충 비슷한” 이유는 편집화면에서 보이는 것은 결과물의 외관이 아니라, 결과물의 구조를 보여주기 때문이지요. 구조만 편집하고, 결과는 별도로 정의된 포맷에 적용되어 보이게 됩니다.

이러한 개념이 웹에디터 모듈에도 적용되어야 하겠습니다.

현재 구현되어 있는 WYSIWYM 방식의 웹에디터모듈은 WYM이 있습니다. (데모보기)

완벽하진 않지만, 이를 통해 이상적인 WYSIWM 방식의 웹에디터모듈을 추측해 볼 수 있는데, 아마도 쓸만한 WYSIWYM 에디터가 되려면 이러한 것들이 있어야겠지요.

1) CSS를 Word의 Style처럼.
워드 프로그램들은 빼놓지 않고 “스타일”이라는 것을 가지고 있게 마련입니다. 대개 스타일들은 “대제목, 소제목, 목차, 본문, 인용, 주석…” 이런 식으로 구성되어있죠. 적용을 원하는 부분마다 해당 스타일을 적용시키고, 만약 수정이 필요하면 문서를 수정하는 것이 아니라, 스타일자체를 수정하는 방법을 사용합니다.
따라서 WYSIWYM 에디터에는 반드시 스타일 적용, 스타일 해제, 스타일 생성, 스타일 편집 기능이 들어있어야 합니다.

2) 비시맨틱 요소의 제거
그러니까, “배경색”이니, “문자색”이니 하는 버튼들은 모두 WYSIWYM에디터에서 빠져야 합니다. 필요하다면 “강조1″, “강조2″ 처럼 스타일을 생성하고, 자주 쓰는 스타일을 미리 에디터에 버튼으로 등록시켜 둘 수는 있겠죠.

3) 개인 CSS의 적용.
WYSIWYM에디터들은 사용자 CSS를 적용시킬 수 있도록 개인마다 준비된 CSS를 외부에서 불러들이거나, 업로드하거나 하는 방식을 지원해야 할 것입니다.

4) 다양한 포맷확장기능
microformat에 관해 글을 쓰다가 WYSIWYM 이야기를 빼놓을 수 없어서 이 글을 쓰게 되었는데요.
기존의 WYSIWYG 에디터에서는 microformat을 사용하는 것이 거의 불가능합니다.
알라딘의 TTB 서비스라든가, 이글루스의 LifeLog 기능들도 궁극적으로는 microformat으로 대치되길 간절히 바랍니다만, 어찌되었건 microformat을 WYSIWYG을 통해 입력하는 것은 거의 불가능. 따라서 WYSIWYM에서는 이런 microformat(혹은 비슷한 무언가들…)을 활용한 입력보조플러그인 기능들이 많이 활성화될 것입니다.
예를 들자면, “천하장사 마돈나 감상문”을 쓰려면, WYSIWYM에디터에서 “영화감상문” 포맷을 선택한 후, 빈자리들에 내용을 채워넣으면 보기좋게 영화리뷰 페이지가 만들어진다든가… 하는 방식으로요.

어쨌거나…
누군가는 좀 쓸만한 WYSIWYM 에디터를 완성해서 내놓아주면 참 좋을 텐데 말이지요. 구질구질하고 지저분한 WYSIWYG은 이제 좀 자제할 때도 되었잖아요?

블로그에 달력이 있는 이유는?

국내 가입형 블로그 서비스들 대부분이 달력을 제공합니다.
그런데, 실상, 현재 국내 블로그에서 가장 쓸모없는 인터페이스가 뭔가하면, 그건 바로 달력이라 이거죠.

달력 쓰세요?

거의 안쓰실겁니다.
그럼에도 불구하고 왜 달력은 블로그들마다 달려있는 걸까요? 심지어 de facto 표준이라고 할 MovableType의 기본 스킨에도 달력은 들어있죠.
허나 WordPress의 기본 테마에는 달력이 빠져있고, 또 MT의 경우에도 사용자들이 만든 커스텀 스킨은 대부분 달력이 빠져있습니다. (TT나, 국산 블로그들은 아쉽지만 이 논의에서 빼자구요. 왜 애초에 TT에 달력을 집어넣었는지 솔직히 저는 잘 모르겠습니다. 위험하지만 굳이 추측하자면,” 남들이 넣기에 넣었다”일 것 같긴 합니다.)
도대체 왜 달력은 블로그에 들어있을까요. 그리고 왜 달력은 있기도 하고 없기도 하는걸까요?
그냥 있어도 그만, 없어도 그만? 혹은 디자인 때문에?

이를 위해서는 블로그의 여러 개념에 대한 이해가 필요합니다.

최초에 블로그(blog)라는 단어는 peterme.com에서 Peter Merholz가 “weblog”란 단어를 “we blog”라는 식으로 말장난처럼 사용하면서 퍼지게 되었습니다. “weblog”란 단어는 John Barger가 Web + Log라는 개념으로 처음 사용했구요.
우리나라에서 zeroboard가 폭발적인 인기를 끌며 너도나도 자작 홈페이지 열풍을 일으키고 있을 때, 의외로 다른 나라에서는 홈페이지 만들기가 그리 쉬운 일은 아니었습니다. 제로보드에 비견할 쓸만하면서도 쉬운 CMS가 드믈었고, 인터넷 인프라도 우리 만큼 좋지는 않았지요.
사람들은 간단한 저널, 일기장, 메모장 형태의 프로그램을 이용해서 원시적인 “웹일지”를 만들기 시작했습니다. 이것이 블로그의 시초입니다.
외부로의 링크와 짧은 자기 이야기, 이것이 초기 블로깅의 모습이었지요.

잠깐 주의를 돌려서,
여러분들은 하루에 블로그 글을 몇개나 쓰시나요?

사람에 따라 다르겠지요. 장문의 Article을 쓰는 사람들은 하루에 한개 쓰기도 버겁습니다.
허나 웹서핑중 발견한 링크와 그에 대한 짤막한 자기커멘트정도만 쓴다면 하루에 여러개라도 쓸 수 있지요.

블로그계에서는 필자가 쓰는 글의 단위를 “포스트(post)”라고 합니다. 또는 “엔트리(entry)”라고도 하지요.
응? 왜 document라든가, page라든가, article이 아니지? 라고 의심해보신 분 계세요?
그것은 블로그에서는 “쓰는 단위”와 “보는 단위”가 다르기 때문입니다.
아까 필자가 글을 쓰는 단위를 “포스트”라고 했는데, 보는 단위는 “아카이브(archive)”라고 합니다.
한개의 포스트가 한개의 아카이브를 이루는 경우도 있지만, 여러개의 포스트가 하나의 아카이브를 이루는 경우도 있지요.

옛날, 링크와 짧은 커멘트가 블로그포스트의 대세였던 때에는, “하루단위”로 글을 보는게 편했습니다.
아침먹고 웹서핑하다가 괜찮은 사이트 발견, 블로그에 적어놓고, 점심먹고 갑자기 뭔가 생각나서 짧게 끄적대고, 저녁먹고 자기전에 하루일을 생각하다 또 뭔가 소소한 쓸거리 발견.
지금의 국내 블로그 시스템하에서는 위와 같은 경우는 3개의 페이지가 나오겠지요. 사실 3개씩이나 페이지를 만들만큼 대단한 내용도 아닌데 말이죠.
일기를 생각하시면 이해하시기 쉬울거에요. 오늘 사건 사고가 3건이 있다해서 하루 일기가 3개의 페이지가 될 필요는 없단 말이죠.

그럼 한개의 포스트만 만들어놓고 나중에 수정으로 계속 추가하는 건 어떨까요? 분명 그렇게 쓰시는 분들도 있습니다.
헌데 이럴 경우에는, 일일이 각 아이템마다 시간을 따로 적어줘야 한단 말이죠. 왜냐하면 한개의 포스트는 하나의 시간만 가질테니까요. 그 안에 여러건의 내용이 있는데 시간분류가 안되면 쫌 그렇잖아요?

그래서 초기의 블로그 시스템에는, 글은 아무 때나 쓰되, 볼 때는 일종의 “모아보기”를 하도록 한 경우들이 환영받았습니다. 일기장이나 저널용 프로그램들이 기본이어서이기도 했구요. 이것이 포스트와 아카이브의 차이를 만들었지요.

최근에는 대세가, 한 번에 길게 쓰는 경우가 대세. 입니다. 이런 건 모아보면 오히려 혼란스럽죠. 한 개의 포스트가 한 개의 페이지. 이런 경우를 Individual Entry Archive라고 합니다. (MT의 용어를 차용했습니다.)

그러나 여전히 짤막짤막한 기록들을 남기는 블로깅 스타일도 많습니다. 이런 경우는 한 개의 포스트마다 한 개의 페이지를 만들면 관리하기도(예전에는 심지어 손으로 HTML을 짜서 블로깅하는 경우도 있었거든요.), 보기도 불편합니다. 일기처럼 사용하는 이들에게는 포스트가 몇 개가 되었건, 하루의 일은 한 개의 페이지에서 보고 싶습니다. 이런 경우를 Daily Archive라고 합니다.

물론 월별로 모아보는 Monthly Archive도 있습니다. 아마도 이런 형태가 필요한 경우는 “이 달의 XXX 소식”같은 형식의 블로깅을 하는 경우겠지요.
특이한 경우지만 Category Archive도 있습니다. 카테고리별로 모아보는 것이지요. 블로그를 자료나 지식관리용으로 쓰는 이들에게 필요합니다. 글이 쓰여진 시점이 중요한 것이 아니라, 글의 종류에 따라 하나의 페이지로 묶어보는 쪽이 좋겠지요. 예를 들자면 “맛집 리스트”같은 형태가 되겠습니다.
더 특이한 케이스로는 Yearly Archive라든가, PerNum Archive라든가, Author Archive같은 것도 존재하겠지요. 또는 Alphabet Order Archive같은 형태도 있을 수 있을테구요. Search Result도 일종의 Archive라고 볼 수도 있지요.

물론 Individual Entry Archive나 Daily Archive에 비하면 다른 Archive들은 활용도가 많이 떨어집니다. 일단 Archive 단위가 너무 커지면, 한개의 페이지에 담아야 하는 양이 많아져서 비효율적이거든요. 그래서 대개의 Archive 페이지들은 “목록” 수준으로 운영되는게 일반적입니다. (꼭 그래야 되는 건 아닙니다. 아니고 말고요… ^^;)

이러면서 블로그가 발전해가다보니 한가지 문제가 있습니다. 보는 방법은 아카이브 단위에 따라 다양할 수 있으므로, 한개의 포스트가 여러가지 아카이브에 동시에 속할 수 있다는 거지요. 그러다보니 도대체 이 포스트의 진짜 주소는 뭐냐 하는 문제가 생깁니다. “‘영화 카테고리’의 6번째 글”인지, “‘2006년 9월’의 11번째 글”인지, “‘홍길동’이 쓴 백만스물한번째 글”인지 혼란스럽다는 거지요.
제목으로 구분하면 되지 않냐고 할 수도 있겠지만, Individual Entry Archive가 아닌 형태가 기본이라면, 굳이 제목을 따로 쓸 필요가 없거든요. Daily Archive라면 “2006년 10월 1일”, Category Archive라면 “Game News”라는 식으로 해당 아카이브 페이지의 타이틀이 이미 존재하니까요. (그래서 외국산 블로깅 도구들에는 “제목”이 필수가 아닌 경우들도 많습니다. 심지어 RSS포맷에도 제목은 필수가 아니에요. :))

이래서 많은 이들이 고개를 갸웃하게 하는 Permalink라는 개념이 나왔습니다. 즉, 어떤 형태의 Archive가 되든 간에, 개개의 포스트에는 고유한 URL을 주자는 개념입니다. Archive page의 URL은 다를 수 있지만, 개별 post의 URL은 고유하게 유지하자는 개념이죠. 그래야 설령 Archive가 바뀌어도 고유한 주소로 post를 찾아갈 수 있도록 말이지요.

여기서 우리는 국내 블로그에서 의도적으로(?) 또는 실수로(?) 빼놓은 개념을 알 수 있습니다.
즉, Archive의 부재… 라는 것이지요.
국내 블로그들은 거의 대부분이, “Individual Entry Archive”만 지원합니다. 한 개의 포스트가 한 개의 페이지를 이루는 경우만 있지요.
확실히, 대세는 그렇긴 합니다. 아마 Archive 선택의 자유를 주어도 대부분의 사용자들은 Individual Entry Archive만 사용할 겁니다.
뭐, 그건 그렇다치고, 이 때문에 국내 블로그 서비스들이 몇가지 삐걱거리는 부분이 생기게 되었는데,
바로 “달력 인터페이스”와 “Permalink”죠.

일단 Permalink라는 개념은 아카이브 페이지의 주소와 포스트 단위가 다르기 때문에 필요한 것이었는데, 한 개의 포스트가 한 개의 페이지를 이루는 국내블로그에서는 필요없는 개념입니다. (국내에서는 어째, Permalink라는 개념이 pretty link의 개념과 합쳐지면서 이상한 쪽으로 흘러가긴 합니다.)

또한, Daily Archive를 사용할 때에는 하루 단위로 모아볼 때 요긴하게 쓰였던 달력 인터페이스가 Individual Entry Archive에서는 필요없게 되었죠. 그냥 목록에서 보거나 앞,뒤로 움직이면서 보는 게 더 편하거든요.
달력을 채택하고 있는 많은 국내 블로그에서는 달력의 날짜를 누르면, 그저 해당 날짜에 쓰여진 포스트의 목록만 보이고 맙니다. 으흠. Daily Archive를 운영하지 않는다면 굳이 그렇게 볼 이유따위는 없지요.
이게, 달력이 붙어 있어도 그 사용은 저조한 이유입니다

그러다보니 스킨이나 테마 제작자들은 달력을 빼놓는 경우가 많습니다. 또 WP는 아예 기본 스킨에서 달력을 빼놨구요. 이제는 Daily Archive를 쓰는 사람은 거의 없기 때문이지요.

헌데, Daily Archive를 지원하지도 않으면서 굳이 달력을 집어넣고 있는 국내 서비스들은 왜 그랬을까요.. 미스테리가 아닐 수 없습니다.

현재의 블로그 형태의 기준이라 할 수 있는 blogger.com이나 MovableType등에서는 달력을 채택하는 대신, Daily Archive를 운용할 선택권을 줍니다. 단지 “일간 목차”의 개념이 아닌 “일별 모아보기”수준에서요. 뭐, 대개의 사용자는 신경쓰지 않으므로 Daily Archive에 목차만 보이게 하는 수준으로 운영하고 맙니다만.

국내 블로그 서비스들은 이 외관만 보고 차용해서 만들었나 봅니다. 그래서, 실제로는 아무 쓸모 없는 달력이라든가, Permalink들이 떡하니 붙어있게 되었지요.

물론, 발전적인 활용법은 있습니다.
달력 인터페이스를 방문자 용이 아닌 블로그 주인용으로 쓰게 하는 방법이지요. Public Personal Information Managing System 같은 것을 만들어 붙인다면 달력 인터페이스는 요긴하게 쓰일 것입니다. 물론, 현재에도 Individual Entry Archive 시스템임에도 불구하고 Daily Diary처럼 사용하는 이들에게는 달력의 일간 목록 조차도 편리하긴 합니다만.(더 편리할 수 있는데, 그것이 한계인 줄 알겠죠. 아니, 그게 한계라는 것도 모르려나…)

뱀발.
국내에서 포털 블로그들의 경우에는 오히려 Permalink를 또다른 용도로 필요로 하게 되었는데요, 그 이유는 주소창의 주소와 실제 블로그 글의 주소가 달라지기 때문입니다. AJAX, DHTML, iFrame, Frame 등으로 이루어지는 바람에 글의 주소를 알아내기가 매우 어려워졌습니다. 덕분에, 사용자들을 위해(?) URL로 사용할 Permalink(?)를 제공하고 있지요. 뭐, 그것도 Permalink의 용도라면 용도랄까요.