하, 농부가 되고 싶다고?

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

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

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

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

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

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

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

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

—

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

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

“뭐라고?”

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

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

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

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

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

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

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

—

“하, 그래픽 디자이너가 되고 싶다고? 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를 만들어 오픈하는 것보다, 사용하는 데이터를 표준에 맞게 제공하는 것이 훨씬 쉽고 간단합니다.