웃자고 쓰는글 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를 만들어 오픈하는 것보다, 사용하는 데이터를 표준에 맞게 제공하는 것이 훨씬 쉽고 간단합니다.