언제부터인가, 블로그들에 BGM이 다시 붙기 시작했다.
확실히, 남의 애드센스에 뭐라뭐라 할 수 없는 것 처럼, 남의 BGM에 뭐라뭐라 할 수는 없는 것이긴 하다.
좋은 음악을 남에게 들려주겠다는 친절한(?) 행위에 누가 감히 딴지를 걸 수 있을까.
(좋은 돈벌이를 여러분들께 알려드려요. 좋은 사이트를 여러분들께 알려드려요. 좋은 조건녀를 여러분들께 알려드려요... 뭐, 이런 친절함들도 있는데 무슨 상관이랴.)
그렇기는 해도, 기껏 번스타인의 말러 3번을 들으며 편안한 마음으로 하는 웹서핑 도중에 "유혹의 소나타" - 베토벤의 엘리제를 위하여??? - 가 브라우저에서 흘러나오면 어쩌라는 건지.
요즘은 동영상 포스팅들도 많은데, 동영상 플레이버튼 누르기 전에 BGM 플레이어(대개 코딱지만해서 어디에 붙어있는지 찾기도 어려운)를 찾아 BGM 중지하기를 해야하는 번거로움은 둘째문제.
그러니까 그렇게 좋은 음악이라면, 그냥 혼자 듣든지, 꼭 나눠주고 싶다면 다운로드하게 해주던지(불법이지만. ^^;), 아니면 최소한 "정지"상태로 초기값을 주든지.
블로그계는 언제나 "주인장 맘대로"... "손님을 위한 마인드"는 찾아보기 힘들다. 모두가 "생산"에만 관심을 갖는데, 누군가는 "소비"에도 신경을 좀 써줬으면.
2007년 5월 10일 목요일
2007년 5월 2일 수요일
메타블로그에 대한 불만들
까놓고 말하자면,
"올라오는 글들이 내게는 재미없어" 와, "내 글이 메인에 안올라가."로 요약가능.
특정분야 - 예를 들어 IT, Google, 애플.. 혹은 정치 - 에 편중되었다는 건 불만의 직접적인 이유가 아니다. 반대로, 자신이 관심있어하는 것 - 예를 들어 야구이야기라든가 혹은 양자역학이라든가... - 에 편중되었을 때에도 그런 불만이 나왔을까?
편중되어서가 아니라, 자신이 가치있다고 생각하는 쪽으로 편중되지 않았기 때문에 발생하는 불만들.
편중을 어떻게 없앨 것인가는 고민해봤자 별 뾰족한 해답도 없고(전부 랜덤으로 노출시키기? ㅋㅋ), 그렇게 편중을 없애놓는다고 불만이 해결될 리도 없다. (왜이렇게 요즘은 읽을게 없어...)
"내 글이 메인에 안올라가"는 앞의 문제의 동전의 양면인지라, 결국은 "읽을만한 가치"가 있는 글이 보여야 한다는 것인데, 문제는 "읽을만한 가치"는 사람마다 제각각 다르다는 것. 그것을 일률적으로 조회수나 추천수 같은 걸로 커버할 수 있을 거라는 매스미디어적 접근법을 채택하는 한 영원히 해결될 수 없는 숙제.
게다가, 1회성 소비가 대부분인 블로그 포스트를 "읽고 나서 그 가치를 평가"한다는 것은 얼마나 번거로운 일인지. 읽을만한 가치가 있는지를 알기 위해 읽고나서의 평가가 필요하다는 건 모순아닌가?
애초에 메타블로그가 RSS 리더의 역할을 떠앉는 것 자체가 모순이기도 하고. 메타블로그의 역할은 "블로그의 소개"면 충분한 것 아닌가? 그런데 어째 우리나라의 메타블로그들은 "몰랐던, 새로운 블로그의 소개"의 기능보다 "이미 알고 있는, 유명한 블로그의 노출"에 더 유리하니 이 구도를 깨지 않는 한 메타블로그에 대한 불만들은 여전하겠다.
"올라오는 글들이 내게는 재미없어" 와, "내 글이 메인에 안올라가."로 요약가능.
특정분야 - 예를 들어 IT, Google, 애플.. 혹은 정치 - 에 편중되었다는 건 불만의 직접적인 이유가 아니다. 반대로, 자신이 관심있어하는 것 - 예를 들어 야구이야기라든가 혹은 양자역학이라든가... - 에 편중되었을 때에도 그런 불만이 나왔을까?
편중되어서가 아니라, 자신이 가치있다고 생각하는 쪽으로 편중되지 않았기 때문에 발생하는 불만들.
편중을 어떻게 없앨 것인가는 고민해봤자 별 뾰족한 해답도 없고(전부 랜덤으로 노출시키기? ㅋㅋ), 그렇게 편중을 없애놓는다고 불만이 해결될 리도 없다. (왜이렇게 요즘은 읽을게 없어...)
"내 글이 메인에 안올라가"는 앞의 문제의 동전의 양면인지라, 결국은 "읽을만한 가치"가 있는 글이 보여야 한다는 것인데, 문제는 "읽을만한 가치"는 사람마다 제각각 다르다는 것. 그것을 일률적으로 조회수나 추천수 같은 걸로 커버할 수 있을 거라는 매스미디어적 접근법을 채택하는 한 영원히 해결될 수 없는 숙제.
게다가, 1회성 소비가 대부분인 블로그 포스트를 "읽고 나서 그 가치를 평가"한다는 것은 얼마나 번거로운 일인지. 읽을만한 가치가 있는지를 알기 위해 읽고나서의 평가가 필요하다는 건 모순아닌가?
애초에 메타블로그가 RSS 리더의 역할을 떠앉는 것 자체가 모순이기도 하고. 메타블로그의 역할은 "블로그의 소개"면 충분한 것 아닌가? 그런데 어째 우리나라의 메타블로그들은 "몰랐던, 새로운 블로그의 소개"의 기능보다 "이미 알고 있는, 유명한 블로그의 노출"에 더 유리하니 이 구도를 깨지 않는 한 메타블로그에 대한 불만들은 여전하겠다.
2007년 5월 1일 화요일
이번 D 도넛파동의 승자는...
Google Docs. (응?)
ps. 이전의 고발글이 docs를 택한 이유는 국내의 검열을 피하면서, 동시에 자료의 저장과 열람, 접근이 쉬운 서비스로서의 docs의 우수성이었다면...
D 도넛의 해명글이 docs를 택한 것은, 블로거들"만"을 상대로 소통할 수 있는 채널을 위함으로 보인다. 해명글 하나 올리자고 자사 홈페이지에 띄워서 공연히 몰랐던 일반인들에게까지 화제가 확대되게 할 수는 없으니까. 그렇다고, 금방 블로그를 하나 급조하기도 뭐하고...
이래저래, docs류의 서비스의 새로운 활용처를 보았다고나 할까.
ps2. 이것저것 귀찮은데, 외국에 서버두고 외국에서 서비스하는 비즈니스 모델을 진지하게 고민해봐야 할 때. 케이먼 제도 같은 곳에 서버두고 국내법따위 신경안쓰고 서비스해보는 건 어떨까? (응? 성인포르노 사이트들이 그렇게 한다고?)
- 우리 서버는 처음부터 일본에 있습니다. ㅋㅋㅋ
ps. 이전의 고발글이 docs를 택한 이유는 국내의 검열을 피하면서, 동시에 자료의 저장과 열람, 접근이 쉬운 서비스로서의 docs의 우수성이었다면...
D 도넛의 해명글이 docs를 택한 것은, 블로거들"만"을 상대로 소통할 수 있는 채널을 위함으로 보인다. 해명글 하나 올리자고 자사 홈페이지에 띄워서 공연히 몰랐던 일반인들에게까지 화제가 확대되게 할 수는 없으니까. 그렇다고, 금방 블로그를 하나 급조하기도 뭐하고...
이래저래, docs류의 서비스의 새로운 활용처를 보았다고나 할까.
ps2. 이것저것 귀찮은데, 외국에 서버두고 외국에서 서비스하는 비즈니스 모델을 진지하게 고민해봐야 할 때. 케이먼 제도 같은 곳에 서버두고 국내법따위 신경안쓰고 서비스해보는 건 어떨까? (응? 성인포르노 사이트들이 그렇게 한다고?)
- 우리 서버는 처음부터 일본에 있습니다. ㅋㅋㅋ
2007년 4월 28일 토요일
DNA Lens, 게으른 사용자
다음의 dna lens를 유용하게 잘 이용하고 있었는데, 날이 갈수록 그 효용성이 떨어짐을 느낀다.
처음 lens를 접했을 때는,
1) 나의 관심사와 비슷한 주제(IT/Web/Programming)에 대해
2) 경험상 신뢰할 수 있는(Daum DNA Lab) 모더레이터가
3) 그 품질을 보장할 수 있는 블로그들을 선별하여
제공해주었기에, 아무런 불만 없이 게으르게 수동적으로 받아 읽기만 해도 충분했었는데...
어느날인가부터 Lens에 등록되는 블로그들이 늘어나기 시작하더니, 약 230개의 블로그가 등록되어 있는 현재로서는, 들어가보나 마나한 페이지가 되어버렸다.
나에게 있어 lens는 게으른 구독을 위한 좋은 소스였는데 안타깝다.
조금 삼천포로 빠져서...
요즘 웹 2.0 서비스들은 "참여"를 서비스의 핵심요소로 여기는데, 글쎄. 사용자는 게을러질 권리가 있다고 보는데...
위키페디아가 참여서비스일까? 만약 위키페디아를 읽기 위해 반드시 위키페디아에 글을 쓴다거나 하는 행위가 필요하다면 "참여"라고 말하겠지만. 실제로는 99%의 사용자는 그저 읽기만 할 뿐 아닌가.
"참여"라는 미명으로 부지런한 사용자가 되기를 원하는 서비스들은 그다지 좋아보이지 않는다. 자신들이 해야할 일을 "웹 2.0"이라는 포장으로 사용자에게 떠넘기는 꼴이니까. 가장 좋은 "참여"는, 자신들이 "참여"하고 있다는 것조차 모를 때 이루어지지 않을까?
다시 lens 이야기로 돌아와서,
lens opml을 받아서 RSS 리더기에 등록시키는 삽질을 했다. 그리고는 기존에 등록된 것과 중복된 것들, 관심없는 것들 등등을 삭제하는 작업을 몇시간 했더니, 약 60개의 블로그가 살아남아 RSS 리더기에 추가되었다.
혹시나 내가 몰랐던 좋은 블로그가 있을까 해서 해본 삽질인데, 들인 시간에 비해 얻은 건 별로 없다. 살아남은 블로그들의 대부분은 이미 알고 있고 한번쯤은 구독기에 등록했었던 블로그들이라서.
그 결과 현재 내 RSS 리더기에 170여개의 피드들이 등록되어 있다.
결국, 진지한 삽질이었던 셈인데, 피드들을 삭제하면서 깨달은 점을 몇개 마지막으로 덧붙여본다.
1) 신변잡기들이 많은 블로그들을 삭제했다. - 스토킹 취미가 있지 않은 이상, 아무리 좋은 문장력과 소소한 감동이 있더라도 타인의 삶을 훔쳐보는 것은 피곤한 일이다. 물론 내가 실제로 알고 있는 지인들의 경우는 예외.
2) 미투데이 포스팅이 많은 블로그들을 삭제했다. - 미투데이 자체에 대한 유감은 아님을 노파심에 미리 밝혀두며, 선문답 혹은 하이쿠를 연상시키는 짧은 문장만으로는 제3자는 이해할 수 없는 암호나 다름없기에. 그런 글들만으로 차있는 블로그들은 내가 그 블로거와 각별한 친분이 있는 것이 아닌 이상 읽어야 할 이유가 없기 때문.
3) 포스팅 주기가 길거나, 심지어 잠시 운영중지 중인 블로그는 오히려 살아남았다. - 진짜로 가치있는 글들이라면 한달에 한번 올라오더라도 감히 구독기에서 삭제할 수 없었다. 오히려 그렇게 장기간 잠수중인 블로그들이 다시 부활하는 날이 더 기다려질 뿐.
4) 반대로 너무 포스팅주기가 짧은 블로그들은 삭제되었다. - 포스팅 주기가 짧아서라기보다는, 포스팅 자체가 가치없는 경우가 많아서.
5) 홍보용 블로그들이 삭제되었다. - PR용으로 운영하는 블로그들을 정기 구독할 이유는 없는 것 같다. 홍보정보가 필요하다면, 직접 해당 블로그를 찾아가서 원하는 내용을 검색해보는 쪽이 매번 나오는 자화자찬 포스팅들을 읽어보는 것보다는 효율적인 듯 해서.
뭐, 내 구독기에서 삭제된 블로그들도 나 읽으라고 쓰는 글들이 아닐테니 별 상관없겠지만.
진짜 마지막으로, 현재까지 내 게으른 블로깅을 위해 가장 도움이 되는 소스는 조프의 주절주절. digg나 del.icio.us보다 내게는 훨씬 편리하다.
처음 lens를 접했을 때는,
1) 나의 관심사와 비슷한 주제(IT/Web/Programming)에 대해
2) 경험상 신뢰할 수 있는(Daum DNA Lab) 모더레이터가
3) 그 품질을 보장할 수 있는 블로그들을 선별하여
제공해주었기에, 아무런 불만 없이 게으르게 수동적으로 받아 읽기만 해도 충분했었는데...
어느날인가부터 Lens에 등록되는 블로그들이 늘어나기 시작하더니, 약 230개의 블로그가 등록되어 있는 현재로서는, 들어가보나 마나한 페이지가 되어버렸다.
나에게 있어 lens는 게으른 구독을 위한 좋은 소스였는데 안타깝다.
조금 삼천포로 빠져서...
요즘 웹 2.0 서비스들은 "참여"를 서비스의 핵심요소로 여기는데, 글쎄. 사용자는 게을러질 권리가 있다고 보는데...
위키페디아가 참여서비스일까? 만약 위키페디아를 읽기 위해 반드시 위키페디아에 글을 쓴다거나 하는 행위가 필요하다면 "참여"라고 말하겠지만. 실제로는 99%의 사용자는 그저 읽기만 할 뿐 아닌가.
"참여"라는 미명으로 부지런한 사용자가 되기를 원하는 서비스들은 그다지 좋아보이지 않는다. 자신들이 해야할 일을 "웹 2.0"이라는 포장으로 사용자에게 떠넘기는 꼴이니까. 가장 좋은 "참여"는, 자신들이 "참여"하고 있다는 것조차 모를 때 이루어지지 않을까?
다시 lens 이야기로 돌아와서,
lens opml을 받아서 RSS 리더기에 등록시키는 삽질을 했다. 그리고는 기존에 등록된 것과 중복된 것들, 관심없는 것들 등등을 삭제하는 작업을 몇시간 했더니, 약 60개의 블로그가 살아남아 RSS 리더기에 추가되었다.
혹시나 내가 몰랐던 좋은 블로그가 있을까 해서 해본 삽질인데, 들인 시간에 비해 얻은 건 별로 없다. 살아남은 블로그들의 대부분은 이미 알고 있고 한번쯤은 구독기에 등록했었던 블로그들이라서.
그 결과 현재 내 RSS 리더기에 170여개의 피드들이 등록되어 있다.
결국, 진지한 삽질이었던 셈인데, 피드들을 삭제하면서 깨달은 점을 몇개 마지막으로 덧붙여본다.
1) 신변잡기들이 많은 블로그들을 삭제했다. - 스토킹 취미가 있지 않은 이상, 아무리 좋은 문장력과 소소한 감동이 있더라도 타인의 삶을 훔쳐보는 것은 피곤한 일이다. 물론 내가 실제로 알고 있는 지인들의 경우는 예외.
2) 미투데이 포스팅이 많은 블로그들을 삭제했다. - 미투데이 자체에 대한 유감은 아님을 노파심에 미리 밝혀두며, 선문답 혹은 하이쿠를 연상시키는 짧은 문장만으로는 제3자는 이해할 수 없는 암호나 다름없기에. 그런 글들만으로 차있는 블로그들은 내가 그 블로거와 각별한 친분이 있는 것이 아닌 이상 읽어야 할 이유가 없기 때문.
3) 포스팅 주기가 길거나, 심지어 잠시 운영중지 중인 블로그는 오히려 살아남았다. - 진짜로 가치있는 글들이라면 한달에 한번 올라오더라도 감히 구독기에서 삭제할 수 없었다. 오히려 그렇게 장기간 잠수중인 블로그들이 다시 부활하는 날이 더 기다려질 뿐.
4) 반대로 너무 포스팅주기가 짧은 블로그들은 삭제되었다. - 포스팅 주기가 짧아서라기보다는, 포스팅 자체가 가치없는 경우가 많아서.
5) 홍보용 블로그들이 삭제되었다. - PR용으로 운영하는 블로그들을 정기 구독할 이유는 없는 것 같다. 홍보정보가 필요하다면, 직접 해당 블로그를 찾아가서 원하는 내용을 검색해보는 쪽이 매번 나오는 자화자찬 포스팅들을 읽어보는 것보다는 효율적인 듯 해서.
뭐, 내 구독기에서 삭제된 블로그들도 나 읽으라고 쓰는 글들이 아닐테니 별 상관없겠지만.
진짜 마지막으로, 현재까지 내 게으른 블로깅을 위해 가장 도움이 되는 소스는 조프의 주절주절. digg나 del.icio.us보다 내게는 훨씬 편리하다.
2007년 4월 27일 금요일
No more metablog
메타블로그의 홍수다. 도깨비뉴스가 메타블로그에 뛰어들었고, 블로그코리아가 부활할거라 한다.
블코랑 직간접적으로 인연이 있는지라 관심있게 보지 않을 수 없는데....
메타블로그는 여전히 유효한가? 처음 블코가 세상에 나왔을 때와 지금은 시간이 흐르고 상황도 바뀌었다. 내 생각은 그저 그렇다 쯤.
여전히 메타블로그에 대한 관심들을 가지는 건, 미디어의 소통채널로써의 메타블로그의 영향력을 무시할 수 없을 뿐더러, 컨텐츠 어그리게이팅의 좋은 수단이기 때문...
한편으로는 여전히 메타블로그에 뛰어드는 플레이어들이 있다는 것은 그만큼 기존의 메타블로그가 부족한 점이 있어서라는 반증일 수도 있고...
그런데 도대체 메타블로그의 용도는 무엇이란 말인가...
서비스 벤더 입장으로서는 트래픽과 컨텐츠 수집, 그리고 영향력이 직접적인 이유가 될 것이다.
허나 사용자 입장으로서는 고만고만한 메타블로그들이 늘어나봤자 무슨 이득이 있을까?
자신의 글이 유통되는 채널은 분명 메타블로그를 이용함으로써 얻는 가장 직접적인 이유이겠으나...
메타블로그의 딜레마는, 사용자가 늘어나고 영향력이 많아질 수록 개개 블로거의 위상은 점점 축소되어 마침내 메타블로그에 가입하든 말든 별 차이 없는, 오히려 검색엔진 쪽의 유입량이 더 많아지는 상태가 되곤 한다.
양질의 블로그와 컨텐트를 획득할 수 있다는 취지 역시, 사용자 pool이 많아지고 대중성이 넓어질 수록, 개개인에게 관심있고 유의미한 가치있는 블로그와 컨텐트를 찾기 더 어려워진다. 그도 그럴 것이, 대중의 선택은 늘 보편타당한 가치를 지향하게 되고, 집단 전체의 평균에게는 의미있을지는 몰라도, 개별 개인의 특화된 욕구에는 미흡한 것이 선택되기 마련. 그런데 도대체 "평균"과 일치하는 개인이라는 것이 어디에 있던가.
특화된 주제에 관련된 미니-메타블로그로 이 문제를 돌파해보려는 시도도 있지만...
그 규모가 전체에 비해 축소될 뿐, 여전히 "타인의 취향"은 "나"와는 괴리되기 마련. 의심스럽다면, DCInside의 아무 갤러리나 들어가서 글들을 읽어보시길. 비록 내가 좋아하는 주제의 갤러리더라도 전체 글 중에 10%정도나 나한테 가치있고 의미있을까, 나머지 90%는 타인에게는 어떤 가치일 지언정, 나 자신에게는 특별한 가치가 되지 못한다. 또다른 예를 들자면, 내가 아무리 "경제"에 관심있다 해서 네이버 뉴스의 "경제"면 기사를 전부 다 읽어야 하는가?(읽을 수 있는가? 또는 읽어봐야 할까?)
국내에 많은 메타블로그들이 고만고만한 형태를 가지고 있고, 앞으로 등장할 메타블로그들 역시 그저 고만고만한 수준이라면... 메타블로그들이 늘어나봤자 별로 큰 가치는 못될 듯.
뭐, 뒤집어 말하자면, 그런 한계를 멋지게 깨부셔줄 수 있는 서비스가 나온다면 나름 대박일 수도 있겠다.
블코랑 직간접적으로 인연이 있는지라 관심있게 보지 않을 수 없는데....
메타블로그는 여전히 유효한가? 처음 블코가 세상에 나왔을 때와 지금은 시간이 흐르고 상황도 바뀌었다. 내 생각은 그저 그렇다 쯤.
여전히 메타블로그에 대한 관심들을 가지는 건, 미디어의 소통채널로써의 메타블로그의 영향력을 무시할 수 없을 뿐더러, 컨텐츠 어그리게이팅의 좋은 수단이기 때문...
한편으로는 여전히 메타블로그에 뛰어드는 플레이어들이 있다는 것은 그만큼 기존의 메타블로그가 부족한 점이 있어서라는 반증일 수도 있고...
그런데 도대체 메타블로그의 용도는 무엇이란 말인가...
서비스 벤더 입장으로서는 트래픽과 컨텐츠 수집, 그리고 영향력이 직접적인 이유가 될 것이다.
허나 사용자 입장으로서는 고만고만한 메타블로그들이 늘어나봤자 무슨 이득이 있을까?
자신의 글이 유통되는 채널은 분명 메타블로그를 이용함으로써 얻는 가장 직접적인 이유이겠으나...
메타블로그의 딜레마는, 사용자가 늘어나고 영향력이 많아질 수록 개개 블로거의 위상은 점점 축소되어 마침내 메타블로그에 가입하든 말든 별 차이 없는, 오히려 검색엔진 쪽의 유입량이 더 많아지는 상태가 되곤 한다.
양질의 블로그와 컨텐트를 획득할 수 있다는 취지 역시, 사용자 pool이 많아지고 대중성이 넓어질 수록, 개개인에게 관심있고 유의미한 가치있는 블로그와 컨텐트를 찾기 더 어려워진다. 그도 그럴 것이, 대중의 선택은 늘 보편타당한 가치를 지향하게 되고, 집단 전체의 평균에게는 의미있을지는 몰라도, 개별 개인의 특화된 욕구에는 미흡한 것이 선택되기 마련. 그런데 도대체 "평균"과 일치하는 개인이라는 것이 어디에 있던가.
특화된 주제에 관련된 미니-메타블로그로 이 문제를 돌파해보려는 시도도 있지만...
그 규모가 전체에 비해 축소될 뿐, 여전히 "타인의 취향"은 "나"와는 괴리되기 마련. 의심스럽다면, DCInside의 아무 갤러리나 들어가서 글들을 읽어보시길. 비록 내가 좋아하는 주제의 갤러리더라도 전체 글 중에 10%정도나 나한테 가치있고 의미있을까, 나머지 90%는 타인에게는 어떤 가치일 지언정, 나 자신에게는 특별한 가치가 되지 못한다. 또다른 예를 들자면, 내가 아무리 "경제"에 관심있다 해서 네이버 뉴스의 "경제"면 기사를 전부 다 읽어야 하는가?(읽을 수 있는가? 또는 읽어봐야 할까?)
국내에 많은 메타블로그들이 고만고만한 형태를 가지고 있고, 앞으로 등장할 메타블로그들 역시 그저 고만고만한 수준이라면... 메타블로그들이 늘어나봤자 별로 큰 가치는 못될 듯.
뭐, 뒤집어 말하자면, 그런 한계를 멋지게 깨부셔줄 수 있는 서비스가 나온다면 나름 대박일 수도 있겠다.
2007년 4월 21일 토요일
마이크로포맷을 웹페이지에 적용시 주의점
슬슬, 마이크로포맷도 수면위로 올라오는 듯 하다.
마이크로포맷을 웹페이지에 적용할 때 주의해야 할 몇가지.
1. AJAX나 DHTML로 마이크로포맷을 만들지 말 것.
물론, 웹브라우저나, OS단에서는 AJAX등으로 만들어지는 마이크로포맷도 충분히 처리할 수 있지만, 여전히 마이크로포맷의 목표는 (Human Readable) Machine Feed이기 때문에 AJAX등을 해석할 수 없는 기계에서도 읽을 수 있도록 JavaScript와 무관하게 HTML안에 마이크로포맷이 들어있어야 한다.
2. 당연한 이야기지만 표준 마크업을 준수해야 한다.
마이크로포맷은 상당히 플렉서블한 구조이긴 하나 어디까지나 표준 HTML을 준수해야만 한다. 마이크로포맷파서는 기본적으로 표준HTML을 파싱할 것을 가정하기 때문에, 마이크로포맷자체가 표준HTML 마크업을 따르지 않을 경우 파싱이 잘못될 수 있다.
3. 보이는 것이 전부는 아닐 수 있다.
CSS를 잘 이용하면, 마이크로포맷을 웹페이지에 적용했을 때, 사람의 눈에 보이는 부분외에도 숨겨진 정보를 제공할 수 있다. 당연히 시맨틱한 마크업이 우선되어야 하며, CSS로 제어가능해야한다.
4. WYSIWYG는 쥐약.
현존하는 WYSIWYG HTML에디터들은 마이크로포맷을 제대로 반영할 수 없다. 마이크로포맷이 필요한 컨텐트는 아직까지 손으로, 혹은 별도의 템플릿을 이용해서 마크업해야 한다.
일단 만들어진 마이크로포맷도 WYSIWYG 에디터를 이용하게 되면 포맷이 깨질 수 있다.
아마도 마이크로포맷을 위한 진화된 WYSIWYG - 이정도라면 이미 WYSIWYM이겠지만 - 을 만들어내면 대박... :)
마이크로포맷을 웹페이지에 적용할 때 주의해야 할 몇가지.
1. AJAX나 DHTML로 마이크로포맷을 만들지 말 것.
물론, 웹브라우저나, OS단에서는 AJAX등으로 만들어지는 마이크로포맷도 충분히 처리할 수 있지만, 여전히 마이크로포맷의 목표는 (Human Readable) Machine Feed이기 때문에 AJAX등을 해석할 수 없는 기계에서도 읽을 수 있도록 JavaScript와 무관하게 HTML안에 마이크로포맷이 들어있어야 한다.
2. 당연한 이야기지만 표준 마크업을 준수해야 한다.
마이크로포맷은 상당히 플렉서블한 구조이긴 하나 어디까지나 표준 HTML을 준수해야만 한다. 마이크로포맷파서는 기본적으로 표준HTML을 파싱할 것을 가정하기 때문에, 마이크로포맷자체가 표준HTML 마크업을 따르지 않을 경우 파싱이 잘못될 수 있다.
3. 보이는 것이 전부는 아닐 수 있다.
CSS를 잘 이용하면, 마이크로포맷을 웹페이지에 적용했을 때, 사람의 눈에 보이는 부분외에도 숨겨진 정보를 제공할 수 있다. 당연히 시맨틱한 마크업이 우선되어야 하며, CSS로 제어가능해야한다.
4. WYSIWYG는 쥐약.
현존하는 WYSIWYG HTML에디터들은 마이크로포맷을 제대로 반영할 수 없다. 마이크로포맷이 필요한 컨텐트는 아직까지 손으로, 혹은 별도의 템플릿을 이용해서 마크업해야 한다.
일단 만들어진 마이크로포맷도 WYSIWYG 에디터를 이용하게 되면 포맷이 깨질 수 있다.
아마도 마이크로포맷을 위한 진화된 WYSIWYG - 이정도라면 이미 WYSIWYM이겠지만 - 을 만들어내면 대박... :)
2007년 4월 20일 금요일
전화위복?
MBP에 Apple BT Wireless키보드와 BT 마이티마우스를 쓰다가, 아무래도 작업효율이 좋지 않아서 UltraNav 키보드로 바꾼지 한달.
노파심에 첨언하자면 BT Wireless 애플 키보드와 BT 마이티마우스 모두 나쁘지 않고 좋은 물건이긴 하다.
문제는, 내가 IBM의 빨간콩에 너무 길들여 졌다는 것. ThinkPad에서 MBP로 바꾸고 나서 가장 불편했던 것이 ThinkPad의 잊을 수 없는 그 키감과, 제다이 포스에 필적하는 상상만으로 움직이는 포인트스틱이랄까. 게다가 자칫잘못하면 엄지손가락뿌리부분의 살집에 눌려 제멋대로 움직이는 터치패드에 조심스러워할 필요도 없고.
한번 키보드에 손을 올리면 손목 움직일 필요도 없는 그 에르고노믹스에 반해서 늘 다른 솔루션에 대해 불만이었던 것.
MBP로 바꾸고 나서 MBP의 미끄러지는 키감이 싫어 일부러 BT 무선 키보드, 마우스를 샀지만, 번거롭게 팔뚝을 움직여야 하는 행위는 나처럼 게으른 사람에게는 쥐약.
그래서 시험삼아 UltraNav 키보드를 붙여보니 잘 붙는다. 심지어 볼륨조절버튼도 먹는다.
그런데 한가지 아쉬운 점은 전용드라이버가 없다보니, TouchPad를 끌 수가 없다는 점. TrackPoint를 사용할 때에는 UltraNav의 TouchPad를 꺼야 하는데, OSX에서는 방법이 없다.
좀 알아본 바, MS의 마우스드라이버를 구해서 해킹을 하라던데, info.plist 파일을 아무리 뒤져봐도 적절히 고쳐야할 부분을 알 수가 없더라...
그래서 포기하고 있던 차에...
사설이 길었다.
오늘 사무실 책상에서 커피마시다 흘렸는데, 공교롭게도 UltraNav 키보드에 직격. 부랴부랴 키 뽑고 분해해서 대충 훔쳐낸 뒤 재조립했는데...
TouchPad가 죽었다. 못꺼서 안달이었는데, 이렇게 죽어주다니 고마울 뿐.
노파심에 첨언하자면 BT Wireless 애플 키보드와 BT 마이티마우스 모두 나쁘지 않고 좋은 물건이긴 하다.
문제는, 내가 IBM의 빨간콩에 너무 길들여 졌다는 것. ThinkPad에서 MBP로 바꾸고 나서 가장 불편했던 것이 ThinkPad의 잊을 수 없는 그 키감과, 제다이 포스에 필적하는 상상만으로 움직이는 포인트스틱이랄까. 게다가 자칫잘못하면 엄지손가락뿌리부분의 살집에 눌려 제멋대로 움직이는 터치패드에 조심스러워할 필요도 없고.
한번 키보드에 손을 올리면 손목 움직일 필요도 없는 그 에르고노믹스에 반해서 늘 다른 솔루션에 대해 불만이었던 것.
MBP로 바꾸고 나서 MBP의 미끄러지는 키감이 싫어 일부러 BT 무선 키보드, 마우스를 샀지만, 번거롭게 팔뚝을 움직여야 하는 행위는 나처럼 게으른 사람에게는 쥐약.
그래서 시험삼아 UltraNav 키보드를 붙여보니 잘 붙는다. 심지어 볼륨조절버튼도 먹는다.
그런데 한가지 아쉬운 점은 전용드라이버가 없다보니, TouchPad를 끌 수가 없다는 점. TrackPoint를 사용할 때에는 UltraNav의 TouchPad를 꺼야 하는데, OSX에서는 방법이 없다.
좀 알아본 바, MS의 마우스드라이버를 구해서 해킹을 하라던데, info.plist 파일을 아무리 뒤져봐도 적절히 고쳐야할 부분을 알 수가 없더라...
그래서 포기하고 있던 차에...
사설이 길었다.
오늘 사무실 책상에서 커피마시다 흘렸는데, 공교롭게도 UltraNav 키보드에 직격. 부랴부랴 키 뽑고 분해해서 대충 훔쳐낸 뒤 재조립했는데...
TouchPad가 죽었다. 못꺼서 안달이었는데, 이렇게 죽어주다니 고마울 뿐.
2007년 4월 18일 수요일
삽질
1. 5시간 동안 이유없는 버그에 시달리다가 결국 소스 코드를 한 줄씩 쫓아가며 찾아본 결과 디렉토리의 퍼미션 문제로 판명. 이런 제길...
교훈 : 타인에게 배포할 라이브러리에는 친절한 Assertion이 반드시 필요하다. 에러가 나는 것을 감추려 들지 말 것. 어디가 문제인지 알아야 고치지...
2. timezone관련 루틴이 필요해서 뒤져보다가 php를 판올림해야 함을 알았다. 그러나 php 판올림 대신 관련 라이브러리를 직접 제작하려다 보니...
한시간이면 판올림했을 것을, 서너시간 걸려도 필요한 기능의 반도 못 구현했다.
교훈 : 결정은 빨리 내려야 한다.
어제오늘의 삽질목록...
교훈 : 타인에게 배포할 라이브러리에는 친절한 Assertion이 반드시 필요하다. 에러가 나는 것을 감추려 들지 말 것. 어디가 문제인지 알아야 고치지...
2. timezone관련 루틴이 필요해서 뒤져보다가 php를 판올림해야 함을 알았다. 그러나 php 판올림 대신 관련 라이브러리를 직접 제작하려다 보니...
한시간이면 판올림했을 것을, 서너시간 걸려도 필요한 기능의 반도 못 구현했다.
교훈 : 결정은 빨리 내려야 한다.
어제오늘의 삽질목록...
2007년 4월 12일 목요일
대체재
거창한 제목이긴 한데, 포스팅은 짧다.
대체재가 없는 서비스는 개발자로서 유혹적이긴 하지만 소비자로서는 쉽사리 질린다.
그러나 더 나쁜 것은, 대체재라는 것들이 실제로 별 차이 없는 워너비들뿐일 때.
내가 A라는 것에 대해 a라는 불만을 가졌을 때, 대체재 B는 a에 대한 불만을 해소할 수 있는 장치가 준비되어 있어야 한다. 그렇지 않다면 애초에 대체재가 될 수도 없겠지.
문제는, 불만이라는 것은 지극히 개인적인 경험이라는 것. 따라서 그 불만을 공유하지 못한다면 대체재의 수요자체도 없는 셈이다. 무늬만 다른, 그러나 실제로는 똑같은 서비스들을 보고 있노라면 웹2.0이 가져다 준 것은 화려한 미사여구와 라운드 디자인, 그리고 달콤하면서도 뻔뻔한, 사용자들의 노동력 착취 포장법 뿐인 것 같다.
대체재가 없는 서비스는 개발자로서 유혹적이긴 하지만 소비자로서는 쉽사리 질린다.
그러나 더 나쁜 것은, 대체재라는 것들이 실제로 별 차이 없는 워너비들뿐일 때.
내가 A라는 것에 대해 a라는 불만을 가졌을 때, 대체재 B는 a에 대한 불만을 해소할 수 있는 장치가 준비되어 있어야 한다. 그렇지 않다면 애초에 대체재가 될 수도 없겠지.
문제는, 불만이라는 것은 지극히 개인적인 경험이라는 것. 따라서 그 불만을 공유하지 못한다면 대체재의 수요자체도 없는 셈이다. 무늬만 다른, 그러나 실제로는 똑같은 서비스들을 보고 있노라면 웹2.0이 가져다 준 것은 화려한 미사여구와 라운드 디자인, 그리고 달콤하면서도 뻔뻔한, 사용자들의 노동력 착취 포장법 뿐인 것 같다.
2007년 4월 9일 월요일
웹사이트의 단축키
웹사이트의 단축키를 위한 조언.
1. 사용하지 마라.
웹사이트의 단축키는 접근성과 편의성을 올려줄 수도 있지만, 그 반대일 경우도 많다.
가장 좋은 것은 단축키를 제공하지 않는 것이다. 표준 인터페이스만을 지키는 것이 좋다. accesskey는 계륵이나 마찬가지.
2. 사용자의 환경을 가정하지 마라.
사용자는 Windows XP + IE6만을 쓰는 것은 아니다. 대놓고, "우리는 Windows XP + IE6만 지원해요"라고 써놓지 않았다면, 사용자의 환경을 마음대로 추측해서 가정하면 안된다.
이것은 단지, "OSX와 FF도 고려해주세요.." 라는 뜻은 아니다.
예를 들어 어떤 사용자는 당신이 한번도 경험해보지 못했던 스크린리더를 이용하는 시각장애인일 수도 있다.
또 어떤 사용자는, 손에 익은 개발환경을 위해 수많은 단축키로 구동되는 어플리케이션을 사용하는 하드코어 개발자일 수도 있다.
당신이 이정도면 IE와 FF에서 무리없이 돌아갈 거라고 설정해놓은 단축키들은 사용자가 이미 다른 용도로 사용하고 있었던 단축키일 수도 있다.
3. 단축키에만 의존하지 마라.
애플아이폰에서 사파리로 웹서핑하는 사용자도 있을 수 있고, Wibro용 카PC에서 웹서핑하는 사용자도 있을 수 있다. 터치스크린에서 단축키를 쓴다거나, 운전중에 단축키를 사용할 수 있을까? 핵심기능이 단축키로 제공된다는 것은 접근성면에 심각한 장애를 준다.
4. 사용자를 시험에 들게 하지 마라.
제 아무리 편리한 단축키라 해도 단축키를 외우는 것은 사용자에게 쉬운 일은 아니다.
정말 우리 서비스는 겨우 7개의 단축키만 알고 있으면 되는데... 라고 할지라도, 사용자는 당신의 서비스만 쓰는 것은 아니다. 이 서비스에서는 이 단축키, 저 서비스에서는 저 단축키... 사용자가 편리하라고 제공하는 단축키인가? 아니면, 개발자인 당신이 편리하라고 제공하는 단축키인가?
5. 단축키를 사용자가 지정할 수 있도록 하라.
꼭 단축키를 제공하고 싶다면, 사용자가 지정할 수 있게 하라. default 키 조합을 제공하되, 키 조합을 바꿀 수 있는 수단을 제공하라. 그래야 사용자가 자신이 진짜로 손에 익은 단축키를 설정해서 사용할 수 있다. 그렇지 않은 단축키들은 모두 나름 UX 제고를 가장한 기획자와 개발자의 자기만족일 뿐이다.
1. 사용하지 마라.
웹사이트의 단축키는 접근성과 편의성을 올려줄 수도 있지만, 그 반대일 경우도 많다.
가장 좋은 것은 단축키를 제공하지 않는 것이다. 표준 인터페이스만을 지키는 것이 좋다. accesskey는 계륵이나 마찬가지.
2. 사용자의 환경을 가정하지 마라.
사용자는 Windows XP + IE6만을 쓰는 것은 아니다. 대놓고, "우리는 Windows XP + IE6만 지원해요"라고 써놓지 않았다면, 사용자의 환경을 마음대로 추측해서 가정하면 안된다.
이것은 단지, "OSX와 FF도 고려해주세요.." 라는 뜻은 아니다.
예를 들어 어떤 사용자는 당신이 한번도 경험해보지 못했던 스크린리더를 이용하는 시각장애인일 수도 있다.
또 어떤 사용자는, 손에 익은 개발환경을 위해 수많은 단축키로 구동되는 어플리케이션을 사용하는 하드코어 개발자일 수도 있다.
당신이 이정도면 IE와 FF에서 무리없이 돌아갈 거라고 설정해놓은 단축키들은 사용자가 이미 다른 용도로 사용하고 있었던 단축키일 수도 있다.
3. 단축키에만 의존하지 마라.
애플아이폰에서 사파리로 웹서핑하는 사용자도 있을 수 있고, Wibro용 카PC에서 웹서핑하는 사용자도 있을 수 있다. 터치스크린에서 단축키를 쓴다거나, 운전중에 단축키를 사용할 수 있을까? 핵심기능이 단축키로 제공된다는 것은 접근성면에 심각한 장애를 준다.
4. 사용자를 시험에 들게 하지 마라.
제 아무리 편리한 단축키라 해도 단축키를 외우는 것은 사용자에게 쉬운 일은 아니다.
정말 우리 서비스는 겨우 7개의 단축키만 알고 있으면 되는데... 라고 할지라도, 사용자는 당신의 서비스만 쓰는 것은 아니다. 이 서비스에서는 이 단축키, 저 서비스에서는 저 단축키... 사용자가 편리하라고 제공하는 단축키인가? 아니면, 개발자인 당신이 편리하라고 제공하는 단축키인가?
5. 단축키를 사용자가 지정할 수 있도록 하라.
꼭 단축키를 제공하고 싶다면, 사용자가 지정할 수 있게 하라. default 키 조합을 제공하되, 키 조합을 바꿀 수 있는 수단을 제공하라. 그래야 사용자가 자신이 진짜로 손에 익은 단축키를 설정해서 사용할 수 있다. 그렇지 않은 단축키들은 모두 나름 UX 제고를 가장한 기획자와 개발자의 자기만족일 뿐이다.
2007년 3월 28일 수요일
까마귀날자 배떨어진다더니
엊그제, OpenID Consumer는 사용자마다 복수의 OpenID를 허용해야 한다는 이야기를 하자마자, myid.net이 잠깐 중단되었었다고 한다. 국내에는 현재 알려진 OpenID Provider는 myid.net이 유일한 상태에서 me2day나 springnote, lifepod(이건 아직 안열었지만) 등이 OpenID"만"을 지원하는 현실에 많은 이들이 불편해했을 듯 하다.
OpenID Provider가 365X24 무결점으로 돌아가면 제일 좋겠으나 그건 불가능하고, 결국 Consumer측에서 이러한 사고에 대한 준비가 되어있어야 한다. 각 사용자별로 복수의 OpenID를 하나의 계정에 등록해둘 수 있게 하여 필요할 때마다 추가, 변경, 취소가 가능해야하며, 각각에 대한 delegation도 가능해야겠다.
좋은 OpenID Consumer가 되려면 품이 많이 든다. 어쩌면 기존의 아이디/패스워드보다 더 공이 많이 들어야 하리라. 이럴 때일 수록, 최초에 도입하는 트렌드 리더들이 더 꼼꼼한 모습을 보여야 하겠다.
OpenID Provider가 365X24 무결점으로 돌아가면 제일 좋겠으나 그건 불가능하고, 결국 Consumer측에서 이러한 사고에 대한 준비가 되어있어야 한다. 각 사용자별로 복수의 OpenID를 하나의 계정에 등록해둘 수 있게 하여 필요할 때마다 추가, 변경, 취소가 가능해야하며, 각각에 대한 delegation도 가능해야겠다.
좋은 OpenID Consumer가 되려면 품이 많이 든다. 어쩌면 기존의 아이디/패스워드보다 더 공이 많이 들어야 하리라. 이럴 때일 수록, 최초에 도입하는 트렌드 리더들이 더 꼼꼼한 모습을 보여야 하겠다.
2007년 3월 25일 일요일
How to delegate openid
최근, 스프링노트의 delegation 문제에 대해 고민하다가(내가 왜... 남의 서비스에 대해 고민을... -_-a) OpenID 컨슈머 구현시 delegation 부분과 관련하여 더 나은 사용성을 제공하는 방법에 대해 생각해보게 되었습니다.
1. What is my OpenID?
아주 원초적인 문제입니다만, 나의 OpenID Account URL은 무엇일까요?
여기 eouia.myid.net이라는 OpenID Account를 가지고 있는 사용자가 하나 있다고 합시다. 이 사용자는 OpenID를 제법 잘 이해하고 있어서, 재미없는(?) myid.net이라는 도메인 대신 자신을 더 잘 identifying해줄 수 있는 http://dnzin.com을 delegated URL로 쓰고 있다고 하지요.
이제, OpenID인증이 필요한 곳마다, 이 사용자는, eouia.myid.net과 dnzin.com 두 가지 중의 한가지를 입력하는 선택을 해야 합니다. 사용자는 두가지 URL이 모두 유효하며 동일한 사용성을 가지는, 동등한 인식키라고 생각할 것입니다. 즉, dnzin.com은 eouia.myid.net의 alias라고 여기겠지요.
그렇다면, Consumer측에서는 이러한 사용자를 위해 어떻게 해야 할까요?
간단하게는
- 입력받은 URL을 방문해서 openid server와 delegation정보(만약 있다면)를 받아와 진짜 OpenID URL을 확인한 후, 해당 정보로 OpenID 인증을 시도합니다.
겉으로 보기에는 이것으로 끝이겠지만, 실제로 뒷단에서는 조금 골치아픈 일이 생길 수 있습니다.
이 사용자의 unique id로써 무엇을 DB에 저장해야 할까요? (계정을 생성하고 유지하기 위해서는 DB에 해당 사용자의 세션을 만들 필요가 있으므로...)
아마도 eouia.myid.net을 이 사용자에 대한 unique id로 잡는 것이 상식적일 것입니다.
그래야만, 사용자가 delegation을 바꾸더라도 동일한 account를 유지할 수 있을테니까요.
예를 들어, 사용자가 http://dnzin.com 대신, http://eouia.com으로 블로그를 바꾸면서 delegation도 바꾸었습니다. 이런 경우에도, 사용자는 delegation을 통해 새로운 http://eouia.com으로도, 새로운 가입절차 없이 이전과 동일한 계정에 로그인할 수 있기를 원할 겁니다.
따라서, Consumer측에서는 로그인시에, 입력받은 URL이 OpenID일거라고 가정하고 바로 DB에 저장된 값과 비교하는 대신, 반드시 해당 URL을 방문해서 delegation 정보를 획득하여 매번 OpenID 인증을 시도해야만 합니다.
현재 스프링노트에서는, 가입시에는 delegation 처리를 하지만, 로그인시에는 delegation 처리를 건너뛰고 있는 듯 합니다. 또는, 조금 있다가 따로 이야기 하겠지만, 사용자의 unique id로 실제 openid url대신 사용자로부터 최초 입력받은 url을 키값으로 쓰고 있을지도요. (버그 게시판의 답변을 미루어보자면 그런 듯... 실제로 안이 어떻게 구현되어있을지 저는 모르죠. ^_^)
여기까지는 가장 기본적인 Consumer 구현법입니다만, 실제로는 좀 문제가 있습니다.
2. How to change my OpenID?
이 사용자가 어느날, myid.net은 싫어... 라며 다른 OpenID Provider로 자신의 OpenID를 바꾸게 되었습니다. 그럴 일이 있겠냐구요? 어느날 myid.net이 없어지거나, 혹은 더 좋은 OpenID Provider가 생겼다거나, 혹은 myid.net이 SRE를 지원하지 않아 불편해.. 라고 생각할 수도 있겠지요.
그래서, eouia.newopenid.com이라는 새로운 OpenID 계정을 사용하기로 결심했습니다. 그래도 delegation을 통해 이전처럼 eouia.com이라는 url로 동일하게 로그인이 가능할 거라고 기대하겠지요. (delegation의 장점이죠.)
그런데, Consumer측에서는 문제가 생겼습니다. 사용자 계정 정보를 실제 OpenID URL(eouia.myid.net)을 키값으로 삼고 있었는데, 전혀 다른 새로운 OpenID URL(eouia.newopenid.com)이 들어오면 이것이 동일한 사용자라고 판단할 수 없기 때문입니다.
그렇다면, 역시 DB의 키값으로는 최초 입력받은 URL을 키값으로 삼는 것이 해결책이라고 생각할 수도 있겠지만... 이 경우에는 delegated URL을 바꿨을 때가 문제가 됩니다. (1번 참조)
결국, 이 사용자에 대한 unique id로 OpenID URL도, delegated URL도 사용하기 곤란한 상황이 됩니다.
3. multiple OpenID
그렇다면, 아예 DB의 유니크한 키값으로 URL을 쓰지 않는 방법이 가능하겠죠.
사용자는 언제든지 사용하고 있는 OpenID를 변경할 수 있고, delegate URL도 바뀔 수 있으며, 그 모든 경우에 대해 동일한 사용자로 인정받기를 원할 수 있습니다.
하지만 한편으로는, 동일한 OpenID에 대해 별개의 Persona의 개념을 원할 수도 있지요. (이 부분은 다른 기회에 다시...)
뿐만 아니라 인증 자체가 내가 컨트롤 할 수 없는 Provider쪽의 시스템을 이용하는 것이기 때문에, 별도의 안전장치를 필요로 합니다. 예를 들어, 어느날 갑자기 myid.net의 인증서버가 고장이 난다면, myid.net을 이용하던 사용자들은 다른 Consumer서비스를 전혀 이용할 수 없게 됩니다. 마른 하늘의 날벼락이죠. (OpenID Provider들이 더 늘어난다면 분명 이러한 문제가 생길 경우도 예상할 수 있습니다.)
따라서 친절한 Consumer라면 이러한 문제들을 해결하기 위해 다음과 같은 방법을 고려해야 합니다.
1) 하나의 계정당 복수개의 OpenID를 등록해서 사용할 수 있게 할 것.
2) 기존의 계정에 새로운 OpenID를 추가등록할 수 있게 할 것.
3) 물론 당연히 각각의 등록된 OpenID에 대해 delegation을 허용할 것.
4) 사용자가 등록된 OpenID를 삭제할 수 있을 것.
4)이 좀 이해가 안갈 수도 있을테니 부가설명 들어갑니다.
여기, eouia.com이라는 도메인을 가지고 있는 사용자가 있습니다. 자신의 OpenID로 eouia.com을 사용하고 있었는데, 깜박 잊고 도메인 연장을 하지 않아 타인에게 이 도메인을 빼앗겼습니다. 그 후, eouia.com을 획득한 타인이 역시 자신의 OpenID로 해당 도메인을 사용하고, 이를 이용해 이전 사용자의 인증을 도용한다면 어떻게 될까요. 이런 경우를 막기 위해서 사용자는 자신의 OpenID를 서비스에서 삭제할 수 있어야 합니다. (혹은, 추후 OpenID 스펙에, 해당 URL은 더이상 유효하지 않음을 Consumer들에게 알리는 프로토콜이 들어가는 방법도 있겠지요.)
4. Best Practice
어쨌거나 이러한 프로세스를 Consumer에서 제공하기 위해서는 사용자별로 OpenID를 unique id로 잡아서는 안되겠지요. 사실, openid만 사용가능한 서비스들(국내의 경우라면 스프링노트나 미투데이 등)은 아마 대부분 이런 식으로 구현될텐데, OpenID만 사용가능하게 하는 것이 사용자 정책적으로 전혀 바람직하지 않을 뿐더러, 실제로 운용에 있어 위에 언급한 바와 같은 문제점들이 발생할 수 있습니다. 그런 면에서 본다면, 왜 스프링노트나 미투데이 등이 OpenID 전용으로만 서비스하는지 조금 이해하기 어렵습니다. (정식 오픈때도 설마 OpenID전용은 아니겠지요.)
결론내리자면,
1) 단일 OpenID URL에 종속적인 인증은 사용자의 사용성을 저해할 수 있습니다.
2) 서비스 설계시 OpenID의 변경 가능성 및 복수 이용에 대해 열려있어야 합니다.
3) 결정적으로 OpenID에만 의존하는 인증방법은 바람직하지 않습니다. OpenID외에도 인증방법은 여러가지가 있을테니까요. (1년 서비스하고 말거면 뭐 상관없겠습니다만.)
1. What is my OpenID?
아주 원초적인 문제입니다만, 나의 OpenID Account URL은 무엇일까요?
여기 eouia.myid.net이라는 OpenID Account를 가지고 있는 사용자가 하나 있다고 합시다. 이 사용자는 OpenID를 제법 잘 이해하고 있어서, 재미없는(?) myid.net이라는 도메인 대신 자신을 더 잘 identifying해줄 수 있는 http://dnzin.com을 delegated URL로 쓰고 있다고 하지요.
이제, OpenID인증이 필요한 곳마다, 이 사용자는, eouia.myid.net과 dnzin.com 두 가지 중의 한가지를 입력하는 선택을 해야 합니다. 사용자는 두가지 URL이 모두 유효하며 동일한 사용성을 가지는, 동등한 인식키라고 생각할 것입니다. 즉, dnzin.com은 eouia.myid.net의 alias라고 여기겠지요.
그렇다면, Consumer측에서는 이러한 사용자를 위해 어떻게 해야 할까요?
간단하게는
- 입력받은 URL을 방문해서 openid server와 delegation정보(만약 있다면)를 받아와 진짜 OpenID URL을 확인한 후, 해당 정보로 OpenID 인증을 시도합니다.
겉으로 보기에는 이것으로 끝이겠지만, 실제로 뒷단에서는 조금 골치아픈 일이 생길 수 있습니다.
이 사용자의 unique id로써 무엇을 DB에 저장해야 할까요? (계정을 생성하고 유지하기 위해서는 DB에 해당 사용자의 세션을 만들 필요가 있으므로...)
아마도 eouia.myid.net을 이 사용자에 대한 unique id로 잡는 것이 상식적일 것입니다.
그래야만, 사용자가 delegation을 바꾸더라도 동일한 account를 유지할 수 있을테니까요.
예를 들어, 사용자가 http://dnzin.com 대신, http://eouia.com으로 블로그를 바꾸면서 delegation도 바꾸었습니다. 이런 경우에도, 사용자는 delegation을 통해 새로운 http://eouia.com으로도, 새로운 가입절차 없이 이전과 동일한 계정에 로그인할 수 있기를 원할 겁니다.
따라서, Consumer측에서는 로그인시에, 입력받은 URL이 OpenID일거라고 가정하고 바로 DB에 저장된 값과 비교하는 대신, 반드시 해당 URL을 방문해서 delegation 정보를 획득하여 매번 OpenID 인증을 시도해야만 합니다.
현재 스프링노트에서는, 가입시에는 delegation 처리를 하지만, 로그인시에는 delegation 처리를 건너뛰고 있는 듯 합니다. 또는, 조금 있다가 따로 이야기 하겠지만, 사용자의 unique id로 실제 openid url대신 사용자로부터 최초 입력받은 url을 키값으로 쓰고 있을지도요. (버그 게시판의 답변을 미루어보자면 그런 듯... 실제로 안이 어떻게 구현되어있을지 저는 모르죠. ^_^)
여기까지는 가장 기본적인 Consumer 구현법입니다만, 실제로는 좀 문제가 있습니다.
2. How to change my OpenID?
이 사용자가 어느날, myid.net은 싫어... 라며 다른 OpenID Provider로 자신의 OpenID를 바꾸게 되었습니다. 그럴 일이 있겠냐구요? 어느날 myid.net이 없어지거나, 혹은 더 좋은 OpenID Provider가 생겼다거나, 혹은 myid.net이 SRE를 지원하지 않아 불편해.. 라고 생각할 수도 있겠지요.
그래서, eouia.newopenid.com이라는 새로운 OpenID 계정을 사용하기로 결심했습니다. 그래도 delegation을 통해 이전처럼 eouia.com이라는 url로 동일하게 로그인이 가능할 거라고 기대하겠지요. (delegation의 장점이죠.)
그런데, Consumer측에서는 문제가 생겼습니다. 사용자 계정 정보를 실제 OpenID URL(eouia.myid.net)을 키값으로 삼고 있었는데, 전혀 다른 새로운 OpenID URL(eouia.newopenid.com)이 들어오면 이것이 동일한 사용자라고 판단할 수 없기 때문입니다.
그렇다면, 역시 DB의 키값으로는 최초 입력받은 URL을 키값으로 삼는 것이 해결책이라고 생각할 수도 있겠지만... 이 경우에는 delegated URL을 바꿨을 때가 문제가 됩니다. (1번 참조)
결국, 이 사용자에 대한 unique id로 OpenID URL도, delegated URL도 사용하기 곤란한 상황이 됩니다.
3. multiple OpenID
그렇다면, 아예 DB의 유니크한 키값으로 URL을 쓰지 않는 방법이 가능하겠죠.
사용자는 언제든지 사용하고 있는 OpenID를 변경할 수 있고, delegate URL도 바뀔 수 있으며, 그 모든 경우에 대해 동일한 사용자로 인정받기를 원할 수 있습니다.
하지만 한편으로는, 동일한 OpenID에 대해 별개의 Persona의 개념을 원할 수도 있지요. (이 부분은 다른 기회에 다시...)
뿐만 아니라 인증 자체가 내가 컨트롤 할 수 없는 Provider쪽의 시스템을 이용하는 것이기 때문에, 별도의 안전장치를 필요로 합니다. 예를 들어, 어느날 갑자기 myid.net의 인증서버가 고장이 난다면, myid.net을 이용하던 사용자들은 다른 Consumer서비스를 전혀 이용할 수 없게 됩니다. 마른 하늘의 날벼락이죠. (OpenID Provider들이 더 늘어난다면 분명 이러한 문제가 생길 경우도 예상할 수 있습니다.)
따라서 친절한 Consumer라면 이러한 문제들을 해결하기 위해 다음과 같은 방법을 고려해야 합니다.
1) 하나의 계정당 복수개의 OpenID를 등록해서 사용할 수 있게 할 것.
2) 기존의 계정에 새로운 OpenID를 추가등록할 수 있게 할 것.
3) 물론 당연히 각각의 등록된 OpenID에 대해 delegation을 허용할 것.
4) 사용자가 등록된 OpenID를 삭제할 수 있을 것.
4)이 좀 이해가 안갈 수도 있을테니 부가설명 들어갑니다.
여기, eouia.com이라는 도메인을 가지고 있는 사용자가 있습니다. 자신의 OpenID로 eouia.com을 사용하고 있었는데, 깜박 잊고 도메인 연장을 하지 않아 타인에게 이 도메인을 빼앗겼습니다. 그 후, eouia.com을 획득한 타인이 역시 자신의 OpenID로 해당 도메인을 사용하고, 이를 이용해 이전 사용자의 인증을 도용한다면 어떻게 될까요. 이런 경우를 막기 위해서 사용자는 자신의 OpenID를 서비스에서 삭제할 수 있어야 합니다. (혹은, 추후 OpenID 스펙에, 해당 URL은 더이상 유효하지 않음을 Consumer들에게 알리는 프로토콜이 들어가는 방법도 있겠지요.)
4. Best Practice
어쨌거나 이러한 프로세스를 Consumer에서 제공하기 위해서는 사용자별로 OpenID를 unique id로 잡아서는 안되겠지요. 사실, openid만 사용가능한 서비스들(국내의 경우라면 스프링노트나 미투데이 등)은 아마 대부분 이런 식으로 구현될텐데, OpenID만 사용가능하게 하는 것이 사용자 정책적으로 전혀 바람직하지 않을 뿐더러, 실제로 운용에 있어 위에 언급한 바와 같은 문제점들이 발생할 수 있습니다. 그런 면에서 본다면, 왜 스프링노트나 미투데이 등이 OpenID 전용으로만 서비스하는지 조금 이해하기 어렵습니다. (정식 오픈때도 설마 OpenID전용은 아니겠지요.)
결론내리자면,
1) 단일 OpenID URL에 종속적인 인증은 사용자의 사용성을 저해할 수 있습니다.
2) 서비스 설계시 OpenID의 변경 가능성 및 복수 이용에 대해 열려있어야 합니다.
3) 결정적으로 OpenID에만 의존하는 인증방법은 바람직하지 않습니다. OpenID외에도 인증방법은 여러가지가 있을테니까요. (1년 서비스하고 말거면 뭐 상관없겠습니다만.)
2007년 3월 20일 화요일
내가 RoR을 안하는 이유
몇가지가 있긴 하다.
1. 아직 완벽하게 익히지 못했다.
그렇다고 다른 랭귀지가 완벽하냐. 그건 절대 아니고, 가장 기초적인 syntax grammar조차도 일부러 안외우고 그때그때 레퍼런스에 의존하는 나로서는 RoR에 대해 충분할 만큼 레퍼런스를 숙지하지 못했다는 뜻. 사실, 아래의 변명들은 결국 이 이유에서 파생된다.
2. RoR의 생산성을 자신할 수 없다.
확실히, 단순한(?) 모델링에서 RoR이 멋짐을 깨달았지만, 복잡도가 증가할 수록 다른 수단과의 격차가 점점 줄어들드라. 이게 나의 잘못인지, 아니면 애초에 복잡계에서의 작업량 수렴의 한계치가 정해져있는 것인지는 아직 미정.
3. 이미 프레임워크를 쓰고 있다.
결국, RoR은 컨벤션의 통일에 의한 효율성과 메타프로그래밍의 용이성이 장점인 듯 한데, 아예 프레임워크를 안썼으면 모를까, 이미 다른 개발환경에서도 프레임워크를 쓰고 있는 나로서는 그다지 엄청난 마법의 지팡이같은 생각은 안든다. 예를 들자면, 코드가 좀 지저분하긴 해도 php로도 충분히 버금가는 퍼포먼스의 프레임워크가 존재할 수 있다. 심지어 비슷한 컨벤셔널 룰로.
4. I'm not native
Ruby 코드의 가독성이 좋다고 하던데, 왜 그런 이야기가 나오는지 수긍이 가긴 하지만, 뭐랄까, 문어체 스타일. 영어가 네이티브가 아닌 나로서는 소위 말하는 Fortran류의 수식형 코드쪽이 더 이해하기 쉽다. 아아, 네이티브 급의 개발자 분들에게는 아무 상관없고 오히려 장점이겠지만.
여튼, Ruby코드보다는 차라리 Perl코드가 더 잘 눈에 들어오는 구식 개발자라서 그런가 보다.
5. 이게 진짜 이유인데..
RoR로 한게 고작 그 정도야? 라는 평가를 스스로 내리거나 남들로부터 듣고 싶지 않기에... 사실, 별로... 남들이 해놓은 RoR도 그 코스트등을 곰곰히 살펴보면, 그다지 Agile하거나 Rapid하지도 않더라... 라는 걱정.
1. 아직 완벽하게 익히지 못했다.
그렇다고 다른 랭귀지가 완벽하냐. 그건 절대 아니고, 가장 기초적인 syntax grammar조차도 일부러 안외우고 그때그때 레퍼런스에 의존하는 나로서는 RoR에 대해 충분할 만큼 레퍼런스를 숙지하지 못했다는 뜻. 사실, 아래의 변명들은 결국 이 이유에서 파생된다.
2. RoR의 생산성을 자신할 수 없다.
확실히, 단순한(?) 모델링에서 RoR이 멋짐을 깨달았지만, 복잡도가 증가할 수록 다른 수단과의 격차가 점점 줄어들드라. 이게 나의 잘못인지, 아니면 애초에 복잡계에서의 작업량 수렴의 한계치가 정해져있는 것인지는 아직 미정.
3. 이미 프레임워크를 쓰고 있다.
결국, RoR은 컨벤션의 통일에 의한 효율성과 메타프로그래밍의 용이성이 장점인 듯 한데, 아예 프레임워크를 안썼으면 모를까, 이미 다른 개발환경에서도 프레임워크를 쓰고 있는 나로서는 그다지 엄청난 마법의 지팡이같은 생각은 안든다. 예를 들자면, 코드가 좀 지저분하긴 해도 php로도 충분히 버금가는 퍼포먼스의 프레임워크가 존재할 수 있다. 심지어 비슷한 컨벤셔널 룰로.
4. I'm not native
Ruby 코드의 가독성이 좋다고 하던데, 왜 그런 이야기가 나오는지 수긍이 가긴 하지만, 뭐랄까, 문어체 스타일. 영어가 네이티브가 아닌 나로서는 소위 말하는 Fortran류의 수식형 코드쪽이 더 이해하기 쉽다. 아아, 네이티브 급의 개발자 분들에게는 아무 상관없고 오히려 장점이겠지만.
여튼, Ruby코드보다는 차라리 Perl코드가 더 잘 눈에 들어오는 구식 개발자라서 그런가 보다.
5. 이게 진짜 이유인데..
RoR로 한게 고작 그 정도야? 라는 평가를 스스로 내리거나 남들로부터 듣고 싶지 않기에... 사실, 별로... 남들이 해놓은 RoR도 그 코스트등을 곰곰히 살펴보면, 그다지 Agile하거나 Rapid하지도 않더라... 라는 걱정.
MSN 당황
가끔, MSN에 누구인지 가물가물한 상대에게서 메시지가 올 때가 있습니다.
왠만하면 제대로 기억해내는 편이지만...
미안, O군. 사실 아까 메신저 받았을 때 누군지 기억 못했어. 하필이면 O군과 같은 이름(성은 다른)이 또 있는지라, 그 친구인줄로만.
갑자기 MSN으로 메시지가 왔을 때, 게다가 이쪽에서는 약간 가물가물 할 때 갑자기 친근모드이면 차마, 누군지 모르겠다는 말을 못하겠습니다. 차라리 메일이었으면, 단도직입적으로 "누구신가요?"라고 물어봤을테지만, 메신저에서는 대화간에(그것도 한껏 친근모드일 때) 그렇게 인터럽트 걸기가 어렵다구요.
여튼, 최대한 기억해내겠습니다. 혹시나 기억하고 있지 못했다 해서 실망하셨다면 매우 죄송. 이 블로그를 보고 연락을 준거였는지는 모르겠지만, 혹시 보고 있다면 뒤늦게라도 사과를.
이런 난처한 경우는 꽤 많을 법도 한데, 이 문제를 해결해줄 수 있는 솔루션은 없을까요? 평소에는 구글링을 솔루션으로 애용하고 있습니다만, 구글링에 안걸리는 경우도 있으니까.
왠만하면 제대로 기억해내는 편이지만...
미안, O군. 사실 아까 메신저 받았을 때 누군지 기억 못했어. 하필이면 O군과 같은 이름(성은 다른)이 또 있는지라, 그 친구인줄로만.
갑자기 MSN으로 메시지가 왔을 때, 게다가 이쪽에서는 약간 가물가물 할 때 갑자기 친근모드이면 차마, 누군지 모르겠다는 말을 못하겠습니다. 차라리 메일이었으면, 단도직입적으로 "누구신가요?"라고 물어봤을테지만, 메신저에서는 대화간에(그것도 한껏 친근모드일 때) 그렇게 인터럽트 걸기가 어렵다구요.
여튼, 최대한 기억해내겠습니다. 혹시나 기억하고 있지 못했다 해서 실망하셨다면 매우 죄송. 이 블로그를 보고 연락을 준거였는지는 모르겠지만, 혹시 보고 있다면 뒤늦게라도 사과를.
이런 난처한 경우는 꽤 많을 법도 한데, 이 문제를 해결해줄 수 있는 솔루션은 없을까요? 평소에는 구글링을 솔루션으로 애용하고 있습니다만, 구글링에 안걸리는 경우도 있으니까.
2007년 3월 16일 금요일
WYM의 구현
현재까지 쓸만한 WYSIWYM 웹 에디터는 WymEditor가 유일했는데, 모 사의 모 클로즈드 베타 서비스를 사용해보니 WYM을 아주 간단하면서도 상콤하게 구현해놓았다.
Wiki이기 때문에 간단하면서도 상콤하게 WYM이 가능했던 것일까? 애초에 내가 생각했던 WYM의 문제점은 사용자들의 비시맨틱마크업에 대한 욕구를 어떻게 풀어나갈 것인가였는데, Wiki는 애초에 그것이 필요가 없으니까.
발상의 전환이랄까... 처음부터 안돼!라고 해서 사용자를 길들이는 것이 그렇게 힘든 일은 아닐 것 같다. 확실히 무지개 알록달록을 원하는 사용자들이 많긴 하지만, 그 요구를 들어줘야 하는 타당한 이유를 찾을 수 가 없다. (소비자는 왕이지만 폭군이 되도록 놔두는 것이 옳은 것은 아니라고 생각.)
아무튼, 훌륭하네. 간만에 괜찮은 서비스를 봤다.
자세히 보니 WYM이 아니라, 그냥 WYSIWYG다. -_-a
Wiki이기 때문에 간단하면서도 상콤하게 WYM이 가능했던 것일까? 애초에 내가 생각했던 WYM의 문제점은 사용자들의 비시맨틱마크업에 대한 욕구를 어떻게 풀어나갈 것인가였는데, Wiki는 애초에 그것이 필요가 없으니까.
발상의 전환이랄까... 처음부터 안돼!라고 해서 사용자를 길들이는 것이 그렇게 힘든 일은 아닐 것 같다. 확실히 무지개 알록달록을 원하는 사용자들이 많긴 하지만, 그 요구를 들어줘야 하는 타당한 이유를 찾을 수 가 없다. (소비자는 왕이지만 폭군이 되도록 놔두는 것이 옳은 것은 아니라고 생각.)
아무튼, 훌륭하네. 간만에 괜찮은 서비스를 봤다.
자세히 보니 WYM이 아니라, 그냥 WYSIWYG다. -_-a
pneumonoultramicroscopicsilicovolcanoconiosis
새학기가 시작되었다.
중고등학교 다닐 때, 새로 입학하면 꼭 사전을 새로 샀는데(그래봤자 2번이지만), 늘 민중서관의 에센스를 사긴 했지만 내심 엘리트사전의 깔끔한 디자인을 더 부러워하긴 했다.
사전을 고를 때에, 좋은 사전을 찾는 한가지 나만의 노하우(?)가 있었는데, 바로 다음 단어가 수록되어있는지를 확인하는 것.
pneumonoultramicroscopicsilicovolcanoconiosis
뜻은 "진폐증". 45자로 이루어진 가장 긴 영어단어라고 한다.
뭐, 저게 있어야 좋은 사전이라는 기준 자체는 엉터리이긴 하지만.
새 도메인을 하나 찾고 있는 중인데, 생각나서 검색해보니... 비어있다.
pneumonoultramicroscopicsilicovolcanoconios.is
아이슬란드... 살까 말까 고민중. 그런데... 뭐에 쓴다냐...
중고등학교 다닐 때, 새로 입학하면 꼭 사전을 새로 샀는데(그래봤자 2번이지만), 늘 민중서관의 에센스를 사긴 했지만 내심 엘리트사전의 깔끔한 디자인을 더 부러워하긴 했다.
사전을 고를 때에, 좋은 사전을 찾는 한가지 나만의 노하우(?)가 있었는데, 바로 다음 단어가 수록되어있는지를 확인하는 것.
pneumonoultramicroscopicsilicovolcanoconiosis
뜻은 "진폐증". 45자로 이루어진 가장 긴 영어단어라고 한다.
뭐, 저게 있어야 좋은 사전이라는 기준 자체는 엉터리이긴 하지만.
새 도메인을 하나 찾고 있는 중인데, 생각나서 검색해보니... 비어있다.
pneumonoultramicroscopicsilicovolcanoconios.is
아이슬란드... 살까 말까 고민중. 그런데... 뭐에 쓴다냐...
사용자의 경험을 존중하자
바로 앞의 포스트와는 반대되는 이야기일 수도 있는데,
개인적으로 웹페이지에 단축키를 넣는 것을 그닥 바람직하게 생각하지 않는다. 왜냐하면 웹사이트는 사용자의 경험과 환경을 알 수 없기 때문에, 때로는 과잉 친절은 전혀 의도하지 않은 부작용을 낳을 수도 있기 때문이다.
예를 들어, "Ctrl + Space"를 중요한 단축키로 사용하는 어떤 서비스가 있다고 하자. 이것은 대개의 경우에 사용하는데 아무런 문제가 없지만, Mac사용자는(그리고 혹시 OS단에서 이미 선점하는 다른 어떤 환경에서도) 해당 기능을 사용할 수 없다. 왜냐하면 Ctrl+Space는 Mac OSX의 중요한 기능 중 하나인 Spotlight를 위해 예약되어있기 때문이다.
시각장애인들의 경우에도 비슷한데, 이들이 사용하는 각종 보조장치/프로그램의 단축키가 제법 많아서 웹페이지의 단축키와 충돌하는 경우들이 있기 때문이다.
확실히 단축키는 편리하긴 하지만, 그래서 더욱 조심스럽게 접근해야만 한다. 일단 단축키 없이 이용가능해야 하는 점이 가장 중요하고, 단축키를 사용할 때에는 기존의 사용자경험과 상충되지 않는지 확인해야만 한다. 그러나 사용자의 경험은 모두 제각각인데 어떻게 해결할 수 있을까.
가장 좋은 해결책은 아마도, 단축키 재정의가 사용자마다 가능하도록 하는 것. 사용자의 경험을 존중하는 서비스들이 많아지길.
개인적으로 웹페이지에 단축키를 넣는 것을 그닥 바람직하게 생각하지 않는다. 왜냐하면 웹사이트는 사용자의 경험과 환경을 알 수 없기 때문에, 때로는 과잉 친절은 전혀 의도하지 않은 부작용을 낳을 수도 있기 때문이다.
예를 들어, "Ctrl + Space"를 중요한 단축키로 사용하는 어떤 서비스가 있다고 하자. 이것은 대개의 경우에 사용하는데 아무런 문제가 없지만, Mac사용자는(그리고 혹시 OS단에서 이미 선점하는 다른 어떤 환경에서도) 해당 기능을 사용할 수 없다. 왜냐하면 Ctrl+Space는 Mac OSX의 중요한 기능 중 하나인 Spotlight를 위해 예약되어있기 때문이다.
시각장애인들의 경우에도 비슷한데, 이들이 사용하는 각종 보조장치/프로그램의 단축키가 제법 많아서 웹페이지의 단축키와 충돌하는 경우들이 있기 때문이다.
확실히 단축키는 편리하긴 하지만, 그래서 더욱 조심스럽게 접근해야만 한다. 일단 단축키 없이 이용가능해야 하는 점이 가장 중요하고, 단축키를 사용할 때에는 기존의 사용자경험과 상충되지 않는지 확인해야만 한다. 그러나 사용자의 경험은 모두 제각각인데 어떻게 해결할 수 있을까.
가장 좋은 해결책은 아마도, 단축키 재정의가 사용자마다 가능하도록 하는 것. 사용자의 경험을 존중하는 서비스들이 많아지길.
2007년 3월 13일 화요일
좌회전 금지
스테이플러 찍어주는 복사기 이후, 간만에 인간에게 실질적인 도움을 주는 과학기술의 발달을 체감한 기사 한토막.
좌회전 신호대기시 낭비되는 연료를 절감하기 위해, 좌회전을 금지하고, 대신 직진과 우회전만으로 최적경로를 찾는 소프트웨어라... 아주 멋지다. 저런게 진짜 기술이지.
좌회전 신호대기시 낭비되는 연료를 절감하기 위해, 좌회전을 금지하고, 대신 직진과 우회전만으로 최적경로를 찾는 소프트웨어라... 아주 멋지다. 저런게 진짜 기술이지.
2007년 3월 12일 월요일
playtalk, me2day
별건 아니고,
만약 playtalk이 단지 wannabe proxy서비스라면....
정작 놀라야 할 건, 10여일 만(me2day가 외부에 노출된 후??)에 간단히 뚝딱 만들어낸 그 Rapidity랄까.
그렇게 agile스럽다는 RoR과 비교하면 어느쪽이 더 빠른 것일까 제법 궁금해진다.
보기에는 .NET인 듯 한데...
누가 누구걸 베꼈느니 하는 이야기는 다른 사람들이 많이 할테니까, 접어두고.
각자 자기였다면 과연 10여일 만에 만들어낼 수 있겠나 하는 질문들을 스스로에게 던져두는 편이 좋지 않을까.
역시 프레임워크가 중요하렷다.
돌고 돌기
me2day
* daily archive의 부활
*
A tumblelog is a quick and dirty stream of consciousness, a bit like a remaindered links style linklog but with more than just links. They remind me of an older style of blogging, back when people did sites by hand, before Movable Type made post titles all but mandatory, blog entries turned into short magazine articles, and posts belonged to a conversation distributed throughout the entire blogosphere. Robot Wisdom and Bifurcated Rivets are two older style weblogs that feel very much like these tumblelogs with minimal commentary, little cross-blog chatter, the barest whiff of a finished published work, almost pure editing...really just a way to quickly publish the "stuff" that you run across every day on the web.
* moblog의 부활
크게 한바퀴 돌아 블로그의 초기형태로 돌아가기.
역사는 순환하며 발전하므로, 이미 블로그가 아닌 소셜 네트워크 커뮤니케이션 도구에 더 가까와졌지만.
아무튼, 재미있는 서비스.. 모쪼록 멋지게 성공하시길.
웃는 남자 단상
조금만 기다리면 동영상에서도 실시간으로 웃는남자의 출현을 볼 수 있을지도.
패턴 인식은 지금까지도 컴퓨터 사이언스에서 매우 중요한 위치를 차지하고 있었지만, 시간이 갈 수록 점점 더 그 중요성은 커져갈 것이다.
UCC라는 정체불명의 유행은 차치하더라도, 동영상을 비롯해, 이미지, 음성, 텍스트, 바이너리 데이터 들의 컨텍스트에서 의미소를 추출해내는 패턴 인식 기술은 향후 10년 내에 가장 중요한 컴퓨터 기술로 꼽히게 될 것이며, 그로 인해 컴퓨팅 스타일도 획기적으로 변하리라.
진대제 전 장관이 모 벤처회사에 거액을 투자한 이유도, 따지고 보면 그 회사의 서비스 자체(요즘 통 소식을 못들었음.)보다도, 패턴 인식 - 얼굴 인식이라는 기술 자체가 아닐까.
"저 배우가 입은 옷 예쁘네. 어디서 살 수 있지?" 에 대한 기술적 구현은 상당히 다양하게 시도되어왔었다.
Digital Interactive TV 진영에서는 방송데이터에 대한 메타태그들을 함께 담아보내려 하고 있고(늘 그렇듯이, 컨텐트 프로바이더가 내보내는 데이터는 그 양과 질에 한계가 있다. 도대체 누가 사용자의 복잡다양한 욕구를 전부 알리오.)
YouTube 같은 소위 web 2.0 진영에서는 집단지성이라는 미명으로 사용자 그룹에 의한 노가다 태깅으로 이 문제를 해결하려 한다.
한편 패턴 인식을 이용해 기계로 하여금 시맨틱한 컨텐트를 이해하도록 하는 시도도 있고.
결과적으로 어느쪽이 우세할 지 점치는 것은 지금으로서는 아직 이르지만...
여튼, "웃는 남자"의 출현을 위해서도 패턴 인식쪽이 얼른얼른 발전했으면 좋겠다.
2007년 3월 6일 화요일
롱테일과 매쉬업 다시보기
"왜 우리 서비스는, 남들이 하는 것들을 대부분 하고 있는데도 사용자들의 만족도가 높지 않을까? 남들이 하는 것의 90%를 제공하고 있으니 최소한 90%수준의 트래픽이 나와야 하는 것 아닌가?"
어떤 웹서비스에 다음과 같은 이익(utility)을 원하는 사용자층이 있다고 하자.
1. A, B, C, D, J
2. A, B, C, D, F
3. A, B, C, D, H
4. A, B, C, E, F
5. A, B, C, E, G
6. A, B, C, D, G
7. A, B, C, E, H
8. A, B, C, D, I
9. A, B, D, E, H
10. A, B, C, G, H
만약 이상적으로 A~J까지의 기능을 모두 제공하는 웹서비스라면 모든 사용자가 진정으로 만족하겠지만...
현실적으로는 비용을 고려해보면 모든 기능을 완벽히 제공하기란 어렵다. (혹은 반대로, 모든 사용자의 마음에 들 수 있는 서비스란 어렵다라는 말로 표현할 수도 있겠다.)
고전적인 서비스 기획자라면, 모든 이가 반드시 사용하는 A,B의 기능을 포함하고, 90%이상의 사용자가 사용하는 C의 기능을 포함하는 선에서 타협을 볼 것이다. 조금 더 여유가 있다면 제법 많은 이들이 사용하는 D, E의 기능까지 넣을 수 있을 것이다.
이 서비스는 만족스러운가?
통계적으로 잡힌 가상의 대부분의 사용자들이 원하는 대표적 기능 'A, B, C, D, E'는 실제로 파렛토 법칙에 따라 "대다수의 사용자가 가장 많이 사용하는 기능들"을 구현했음에도 불구하고, 이 서비스는 어떠한 사용자에게도 만족스럽지 않다.
이것은 단지 통계의 마술일뿐일까?
조금 다른 가정을 해보자.
어떤 서비스는 똑같은 비용을 들여 'A, B, C, D, H'를 제공한다고 하자. 이 서비스는 최소한 1/10의 사용자에게는 완벽한 만족을 주는 서비스가 될 수 있을 것이다. 그렇다면 나머지 9/10에게는 앞서 말한 전통적 방식보다 더 안좋은 서비스일까?
실제로는 나머지 9/10에게는 앞서 말한 방식보다 특별히 더 나쁘게 여겨질 것도 없다. 어차피 자신들이 원하는 기능이 완벽히 제공되지는 않기 때문에. 혹자에게는 이전 방식보다 더 나은 면도 있을 테고.
만약 또 다른 어떤 서비스는 조금 더 비용을 들여 'A, B, C, D, G, H' 까지 제공하도록 만들어졌다고 하자. 1개의 기능이 추가됨으로 인해, 'A, B, C, D, H'만 지원하는 서비스에 비해 만족하는 사용자수가 3배가 되었다.
이 3개의 서비스가 경쟁하면 어느 것이 시장에서 더 성공할 수 있을까?
여기까지의 교훈
1. 가상의 "User"를 잡지 말 것. 사용자들은 하나의 magic word - "user"로 표현될 수 없다. 이는 브로드밴드시절의 매스마케팅 스타일 접근방식이며 웹의 장점을 포기하는 일이다.
2. 실제로 서비스의 만족도는 80%의 기능 "A, B, C, D, E"에서 차이나는 것이 아니라, 나머지 20%의 기능 "F, G, H, I, J"에서 결정된다.
그렇다면, "A, B, C, D, E"를 제공하는 서비스는 무엇을 잘못한걸까? 전형적인 근시안적 Greedy 알고리즘의 폐해일 뿐일까? 이 서비스는 되살아날 수 없는 것일까?
매쉬업 전략을 채택해보면 어떨까? 핵심기능 'A, B, C, D, E'만 제공하고 나머지는 3rd Party의 매쉬업 서비스를 가능하도록 열어둔다면?
특정 매쉬업 서비스 'A, F', 'A, B, I, J' 같은 것이 만들어질 수 있도록 오픈해두면 이전과는 반대로 사용자들은 이 서비스에 대한 만족도가 올라가게 될 것이다. 기본적으로 'A~E'까지의 핵심기능이 제공될 뿐더러, 이 서비스를 이용함으로 인해, 자신이 불만족스러워했던, 'F~J'까지의 기능을 매쉬업으로 제공받을 수 있으니까.
그러기 위해 이 서비스 업체가 취해야 할 전략은, 의도적으로 'A, F' 같은 형태의 매쉬업이 쉽게 생성될 수 있도록 유도하는 것이다. 결국 자신이 만들기는 싫지만(비용등의 문제로 인해), 타인이 쉽게 만들 수 있도록 하는 것. 따라서 바람직한 형태의 매쉬업으로 유도하기 위해 API등의 오픈 수위나 레벨을 조절할 필요가 있을 것이다.
롱테일과 매쉬업은 지극히 자연스럽게 결합된다. (아마존처럼 'A~J'까지 모든 것을 다 아우르지 못한다면.)
2007년 3월 5일 월요일
What the hell is the USER?
도대체 "User"란 누구를 말하는 것일까?
1. 싸이월드 미니홈피의 "User"는 "미니홈피의 소유자"를 말하는 것일까? 아니면 "미니홈피의 방문자"를 말하는 것일까?
2. 이명박(혹은 박근혜) "UCC" 동영상을 만드는 이는 "user"인가?
3. 올블로그의 User는, 블로그 피드를 등록한 사람을 가리키는 것일까? 아니면 올블로그를 방문해서 링크를 클릭하는 사람을 가리키는 것일까? 아니면 올블에 로그인해서 추천을 날려주는 사람일까?
4. 우리 기획자가 말하는 "User"는 도대체 누구일까? 혹시 기획자의 또다른 분신?
5. "User들은 그런 걸 안좋아하죠."라고 할 때 User는 또 누구일까?
자기 맘대로 편리하게 가져다 쓰는 "user", 도대체 "user"가 누구라고 콕 찝어 말할 수도 없으면서 왜 "user"는 만병통치약처럼 쓰일까?
바보상자라는 타이틀은 이제 TV가 양보할 시대가 왔나보다. 지극히 퍼스널미디어스러울 것 같은 웹은 실은 매스미디어의 규칙아래 놀아나고 있을 뿐.
"시청자 참여"가 늘어난다 해서 방송권력이 민중으로 이양되는 것은 아닌 것처럼, 웹 2.0의 수식어를 아무리 가져다 붙여도, 근본적으로 "정체불명의 Mass"를 대상으로 하는 매스미디어식 접근 방식의 웹서비스들은 그 한계를 벗어날 수 없다. (타게팅 운운의 헛다리짚는 소리 사양.)
MassWeb의 환상에서 벗어나기.
대중에서 다중으로, 그리고 다시 분중으로...
2007년 2월 28일 수요일
OpenID는 익명의 수단이 아닙니다.
OpenID의 목적은 새로운 Identity를 보장하기 위함이지, 블로그에 익명로그인을 위해 존재하는 것은 아닙니다.
특히 Simple Registration Extension을 지원하지 않고 프로필도 제공하지 않는 단지 Auth만을 제공하는 OpenID 서비스라면 더욱 그렇죠.
뭐 SRE를 반드시 지원해야 하는 문제는 아니고...
블로그에 OpenID를 이용할 수 있도록 해놓고 지금까지 두어개의 OpenID 커멘트가 달렸는데요...
불행히도(?) OpenID URL 중, myid.net은 email주소를 제외하고는 어떠한 정보도 알려주지 않습니다. 이래서야 URL이 있어도 그림의 떡.
어차피 블로그를 쓰시는 분이라면, 자신의 블로그 URL을 delegate해서 자신의 블로그로 연결시킬 수도 있습니다. 자신은 숨기고 myid.net의 인증만을 들이미는 것은 왠지 기분이 나빠져요. 꼭 인적정보를 까발리라는 게 아니라 자신의 블로그 URL로 delegate해주는 쪽이 좋지 않나 하는 말씀입니다.
그러니까 저는, yong.myid.net이 아니라, 블로거로서의 yy님을 마주대하고 싶은거라는거죠. 똑같은 OpenID 인증을 하시더라도, http://yong.myid.net 보다 http://janice.kaist.ac.kr/~gomeisa/blog를 써주시는 것이 훨씬 좋습니다. (OpenID를 이용하시는 분이 적어 부득이 yy님을 예로 들었습니다.)
제 OpenID는 eouia.openid.ne.jp도, eouia.myid.net도, eouia.openid.com도 아니라, http://dnzin.com/cunnningweb 입니다.
2007년 2월 27일 화요일
Evolutionary Stable Web 2.0
웹 2.0의 본질이 무엇인가 하는 이야기는 주제와 동떨어지므로 여기에서는 과감히 생략. 이 글에서 이야기하고자 하는 바는 소위 추천글사태로 모듬지을 수 있는 최근의 올블로그-를 화두로 '선한 사용자의 참여'에 대한 오해, 그리고 진화적으로 안정된 web 2.0에 대해 이야기해보도록 하겠습니다.
몇가지 생각해볼 화두가 있겠는데요,
첫번째는 'collaborate'와 'collective intelligence'는 같은 개념은 아니라는 것입니다.
올블의 추천 시스템은 전형적인 'collaborate'의 구현이라고 말할 수도 있을 것입니다. 여러 사람이 자원(로그인, 클릭에 소요되는 노력과 시간)을 조금씩 써서 공통의 목표(읽을만한 블로그 찾기)를 달성하는 것은 일견 꽤나 멋지고 바람직한 일처럼 보입니다.
그러나, collaborate의 성공을 위해서는 구성원 전체가 공통의 목표에 대한 동의외에도, 실질적으로 그 행위에 대한 결과가 노동을 투입한 당사자에게도 혜택이 돌아가야 합니다. 올블의 추천시스템은 이 부분이 빠져있죠. 애써서 남의 글에 '추천'을 해준들 나에게 무슨 소용이 있겠습니까.
남의 글에 '추천'하는 행위는 직접적으로,
1) 나의 한정된 노력과 시간과 관심이라는 자원을 소비하고,
2) 타인의 글을 '추천'함으로써, 올블메인이라는 한정된 재화를 놓고 벌이는 경쟁에서 자신의 글이 불리해집니다.
3) 게다가 자기 혼자 '추천'하고 다른 이가 동참하지 않는다면 그 불리함은 더 커지죠.
이렇게 '추천'하는 개인에게 불리한 시스템을 놓고 왜 '추천 안하냐', '추천을 열심히 하자'라고 주장하는 것은 완전히 넌센스라고 해도 다름없지요.
게다가 실제로는 '모두가 추천을 열심히 누르는 착한 사람들'이 된다 해서 이 시스템이 잘 돌아갈 것이냐.. 요건 또 다른 이야기거리가 됩니다.
즉, '좋은 글 발굴'이라는 '공동의 선'을 '집단지성'으로 해결할 수 있지 않느냐는 대의명분을 가지고, 이른바 '선한 사람 되기'를 요구하는 목소리도 있는데요. 이른바 'collective intelligence'는 개인의 '의지'가 들어가는 순간부터 왜곡되기 시작합니다. 따라서 collective intelligence를 구현하기 위해서는 무엇보다도 사용자의 '의지'를 차단하는 과정이 필요합니다. 혹은, 사용자의 '의지'를 이겨낼 수 있는 정교한 시스템이 뒷받침되거나요.
Google의 PageRank는 collective intelligence의 대표적인 구현이라고 할 수 있습니다. '어디에서 얼마나 참조하고 있는가'로 랭크를 매기는 이 방법은 '의지'를 이용해서 조작하기에는 꽤 비싼 대가를 치뤄야하기 때문이죠. '참조'에는 비용이 수반되고, 실질적으로 '의도'가 아닌 '필연'에 의해 이루어지니까요. (그럼에도 불구하고 특화된 SEO를 통해 조작을 하고 있긴 합니다만.)
그에 비하면 올블의 추천 시스템은, 추천 클릭이 싼 비용은 아니라쳐도, 그렇다고 개인의 의지를 무력화시킬 정도로 엄청나게 비싼 비용도 아니지요. 이런 경우 집단지성은 발현되기 어렵습니다. (집단감성은 발현되기 쉽지만.)
collaborate이자 collective intelligence의 대표격인 wikipedia조차 사실상은 끝없는 노이즈와의 싸움이라 할 수 있지요. 그나마 그것이 잘 돌아가는 이유는,
1) 강력한 감시자가 있다.
2) 참여에 대한 자기만족이 크고 실질적으로 공동의 목표에 이바지하고 있다는 자각을 현실적으로 체감할 수 있다.
그러나 올블의 추천 시스템은 추천버튼 하나 누른다고 뭐가 엄청나게 보람찬 일을 하고 있다거나 추천에 대한 피드백이 즉각 돌아오나요? 이 문제를 해결하지 않는 이상 '열심히 추천클릭해보아요'라는 구호는 그냥 빈 구호가 될 뿐이지요.
어찌되었건 이 모든 것을 차치하고라도, 모두가 착한 사람이 되면 되지 않겠냐...는 건, 불가능의 여부를 떠나서, 별로 안정적이지도 못한 전략입니다.
생물학 이야기를 잠깐 해야겠습니다. 교양과정으로 '이기적 유전자'를 읽어보신 분은 아시겠지만, 소위 ESS(Evolutionary Stable Strategy)를 이 경우에 집어넣으면 딱 맞는 이야기입니다.
"선심파"와 "기회주의파"가 있을 때, 얼핏 생각하기에는 구성원 전원이 "선심파"일 때 공동체의 이익(과 구성원 개인의 이익)이 가장 크므로, 모두가 "선심파"가 되도록 진화할 것처럼 생각하지만, 실제로는 "선심파" : "기회주의파"의 비율이 특정한 상태가 되도록 진화가 이루어지게 되죠.(정확한 비율은 선심의 행위의 비용과 이득, 기회주의 행동의 비용과 이득에 따라 결정됩니다.)
올블의 경우에는 선심의 행위의 이익[좋은 글에 추천을 해준다]과 비용[로그인과 클릭], 그리고 기회주의행위의 이익[좋은 글로 추천된 것을 그냥 수고 없이 본다]과 비용[아무것도 안한다]를 따져보면, 기회주의 쪽이 너무 많이 이익이죠. 즉 구조상 선심파보다 기회주의파가 더 많은 상태가 더 stable한 상태가 되는 겁니다.
그런 걸 아무리 "착한 사람이 됩시다" 캠페인을 해봤자 애초에 달성될 수 없는 목표라는 거지요.
그렇다면, "착한 사람의 참여"는 결국 꿈같은 이야기일 뿐이냐....
그건 아니죠.
다만, 그를 위해서는 "착한 사람의 참여는 그 착한 사람에게 더 많은 이익을 돌려주는 시스템"이 되어야 한다는거죠.
물론 저는 추천이나 평점 시스템 자체를 신뢰하지 않기에(애시당초, 누군지도 모르는 다른 이들이 추천하고 주는 평점 자체가 어떻게 나에게 이익이 될 수 있을 지 신뢰할 수 없기 때문에), 추천등 왜곡될 가능성이 있는 시스템의 채택 자체를 반대하는 편입니다만... 그래도 꼭 추천시스템을 유지하고 싶다면... 간단하다면 간단한 해결책이 있긴 하죠.
"클릭하는 행위가 실질적으로 나에게 도움을 주어야 한다"가 되어야겠습니다. 뭐.. 돈으로 보상... 할 수도 있겠지요. 좋은 글을 많이 추천한 분들께 선물을 드려요 같은. (뻔한 부작용이 벌써 예상되긴 합니다.)
좀 더 나은 대안은, 예를 들어 "스크랩을 위해 클릭하면 자동으로 추천이 된다." 같은 시스템이 될 수도 있겠죠. 자신의 필요에 의해 뭔가 액션을 - 당연히 행해야하는 - 취하면 그 부수적인 효과로 추천에 상응하는 통계를 잡을 수 있다거나 하는거죠. 꼭 스크랩이라는 소리가 아니라. 예를 들자면, "개인별 올블로그 오늘의 좋은 링크 북마크모음"이라든가, "해당 글에 대한 원격 블로깅 지원" 같은 실질적인 개인별 이익으로 보상이 있어야 한다는거죠.
그 보상이 크면 클 수록 "선심파" - 이쯤 되면 "이기적 블로거"라고 말할 수도 있겠습니다. - 가 유리해지는 비율로 안정되는 것이지요.
간단히 이야기하자면, 로그인하고 추천클릭해봤자 나한테 돌아오는 거 없으니, 그럴만한 보상 체계를 제시하는 쪽이 좋다는 충고입니다. 웹 2.0의 한계도 아니고, 사람들이 사악해서도 아니고, 그저 기획의 미비일 뿐이지요.
Flash에서 스크린리더 감지하기
[actionscript]
if (Accessibility.isActive()) {
_root.selfVoicing.play();
}
[/actionscript]
그러나, 국산 스크린리더로는 안된다는 것...
조금 다른 이야기인데, 접근성을 위해서는 운영체제의 지원이 필수인데, 국가에서 지정해서 공공기관에 납품되는 PC에 들어가는 운영체제의 필수요건으로 스크린리더를 포함하도록 하는 게 좋지 않을까?
2007년 2월 25일 일요일
축구와 IT, O 신드롬
이번 윈터마켓은 사실 은퇴 등을 제외하고는 눈에 띄는 대박 이적은 없었던 것 같습니다. 호나우도가 재기에 성공할 수 있을 지 정도?
C.호날도가 이적할 것인지 아닌지를 놓고 설왕설래했지만, 결국 맨유에 남았지요. 시즌 종료후에는 모르겠습니다만.
어찌 되었건, 첼시나 맨유, 바르샤, 레알(레알은 요즘 좀 부실해졌지만.) 등 우주방위대급의 스쿼드를 보유하고 있는 팀으로 결정되겠죠. 이적료만 해도 장난이 아닐테니까요.
프로 축구팀의 목적은 사실, "흑자"입니다. 세미프로나, 아마라면 모르겠지만.
첼시나 레알같은 갈라티코급 운영을 하는 이유는, 단지 구단주가 부자 축구광이라서가 아니라, 더 좋은 선수를 가지고 있음으로써 더 나은 성적과 더 나은 마케팅을 할 수 있기 때문이지요. 그러니까 FootballManager 게임처럼 선수사모으기는 취미가 아니라, 세밀한 경영전략이라고 해야겠지요.
뭐, 그렇다면 챔피온스 리그는 그런 우주방위대들이 돌아가며 우승해야 정상이겠습니다만, 꼭 슈퍼스타들이 많다고 경기에 연전연승하는 건 아니지요. 근 20년간의 전적을 보자면 포르투라든가, 도르트문트, Ajax, 즈베즈다 같은 팀들이 깜짝 우승을 하는 경우들이 있었으니까요.
우주방위대에는 실상 단점도 있어서, 다른 팀같았으면 붙박이 주전이었을만한 선수도 기라성같은 스타들 틈에서 벤치나 2군으로 밀려나는 경우도 종종 있지요. 팀 입장에서야 다른 팀에 주느니 데리고 있겠다일 수도 있겠고, 좋은 값에 팔아버릴 요량일지도 모르겠으나, 당사자는 정말 피가 마를 것 같아요. 아, 하긴, 맨유의 2군벤치라도 지키고 있으면 영광이라고 생각하는 선수가 있을지도 모르죠. ^_^
왜 엉뚱한 축구 이야기를 하는가하면...
회사에서 구인 중인데요, 공교롭게도 괜찮은 인재다 싶어 컨택하는 족족, 특정한 모모 회사에 지원중... 이라고들 하시네요. ㅎ 국내 IT인력의 싹쓸이 중인가요? Google이 한동안 한국 개발자들 시장을 들쑤셔놓더니, NHN은 200명을 한번에 뽑고 있다죠? 이번에 어떤 곳은 정말 IT계의 우주방위대를 만들려나보다 싶을 정도로 파격적인 조건과 대우로 구인중이더군요.
한편으로는 부럽다는 생각도 들면서, 한편으로는 또 심하다는 생각도 들더라구요. 농담삼아 O신드롬이라고 회사내에서는 일컫고 있습니다.
모 벤처 경영자분께, 어떻게 좋은 개발 인력을 이렇게 쉽게 모으셨나요? 라고 물었더니 이렇게 답변하셨더라죠.
"넓직한 책상에 듀얼 모니터 놔두니까 서로 오겠다고 하던데요?"
뭐, 바르샤나 레알같은 회사도 있고, PSV나 레딩같은 회사도 있는 법이지요. C.호날도를 사오지는 못하지만, 토탈사커쯤은 해낼 수 있지 않을까... 하는 이야기를 회사분들이랑 나눠봤습니다.
2007년 2월 23일 금요일
OpenID 그까이꺼(2)
이번에는 Consumer 구현입니다.
지난번에 이야기한 건 Provider편이었죠? 많은 부분 Provider와 겹치므로 슬쩍 새 창으로 띄워서 컨닝해가면서 따라오세요.
역시 마찬가지로 PHP 4.3.0 이상, bcmath나 gmp가 설치되어 있다고 가정하고, MySQL은 InnoDB를 사용합니다.
또한, 이미 OpenID Library가 설치되어있고 경로에 추가되어있다고 가정합니다.
Consumer편은 더 쉽습니다. 설명할 게 없을 정도.
일단, 세션스토어로 MySQL을 사용할 예정이니 Provider편과 마찬가지로 MySQLStore 객체를 만듭시다.
[php]
$connection = DB::connect($dsn);
$store = new Auth_OpenID_MySQLStore($connection, 'setting', 'association', 'nonce');
//$store->createTables();
[/php]
물론, 최초 실행시에는 createTables()를 해줘야합니다.
만약 MySQL대신 다른 Store를 이용하고 싶다면 다른 Store 클래스로 객체를 만드시면 됩니다. Factory 패턴이기 때문에 따로 신경안써줘도 되는건 OO 공부하신 분들이면 다 아실테지요.
[php]
$store = new Auth_OpenID_FileStore($store_path);
[/php]
예를 들어 파일패스를 스토어로 쓰고 싶다면 이렇게 해주면 된다는 말씀.
이제 만들어진 스토어 객체로 Consumer 객체를 만듭시다.
[php]
$consumer = new Auth_OpenID_Consumer($store);
[/php]
일반적인 시나리오에서는, 사용자는 Consumer 사이트에 와서 자신의 OpenID를 Form으로 입력하겠죠. 어쨌거나 인증하고자 하는 OpenID값을 Consumer 객체에 던져주기만 하면 됩니다.
[php]
$openid = $_POST['login_openid']; // 뭐, 예를 들자면.. 이런 식이겠죠:)
$auth_request = $consumer->begin($openid); //오픈아이디 서버와 association을 시도하고 그 결과를 돌려줍니다.
if($auth_request) {
//success;
} else {
//fail;
echo "Authentication Fail";
}
[/php]
$auth_request가 true이면 정상적으로 association이 이루어졌다는 뜻입니다. 만약 false라면 인증에 실패했다는 메시지를 사용자에게 보여주면 되겠죠?
association이 성공적으로 이루어졌다면 이제, 해당 openid에 대한 인증을 시도하면 됩니다.
[php]
$trust_root = 'http://consumer.com';
$process_url = 'http://consumer.com/afterAuth';
$redirect_url = $auth_request->redirectURL($trust_root, $process_url);
header("Location: ".$redirect_url);
[/php]
$trust_root는 Provider에게 이 인증시도가 어떤 Consumer로부터 시도된 것인지 신뢰여부를 판단하게 해주는 일종의 키값이 됩니다. 완벽하진 않지만, trustroot와 인증시도 도메인간에 도메인이 다를 경우 피싱시도로 파악해서 인증을 거부하거나 할 수 있도록 하지요. 반대로, trustroot로 인정된 도메인의 경우에는 따로 지정하지 않는 한, 인증을 자동보장한다거나 하는데 쓰일 수 있겠지요.
$process_url은 OpenID Provider가 인증을 처리하고 난 후 그 결과값을 되돌려받을 Consumer 사이트의 url입니다.
위의 코드가 실행되면, $redirect_url이 되돌려집니다. $redirect_url은 Provider의 인증처리 페이지에 인증 Request를 Get 메쏘드로 전달하는 형태이지요. 즉, 이렇게 만들어진 $redirect_url로 redirect시켜주기만 하면 됩니다.
만약 단순한 인증으로 끝나지 않고, Simple Registration Extension를 이용해 사용자 정보를 얻어오길 원한다면
[php]
$auth_request->addExtensionArg('sreg', 요구필드타입, 요구필드이름리스트);
[/php]
를 redirecURL메쏘드 실행전에 실행시켜주면 됩니다.
요구필드타입은 required/optional이구요, 비록 required라고 해도 Provider에서 반드시 정보를 제공한다는 보장은 없으니(Simple Registration Extension를 지원하지 않거나, 사용자가 정보제공을 거부하거나...), required로 요구한 필드의 되돌아오는 값이 없다해도 에러는 아니라는 점.
그외에, policy_url을 이용해, 어떤 필드들을 왜 요구하는지 설명을 알려줄 수도 있지요.
요구필드로 현재 Simple Registration Extension 에 정의된 필드는,
nickname, email, fullname, dob, gender, postcode, country, language, timezone
의 8 가지인데요, 주의할 점은 각각의 필드의 리턴값은 RFC와 ISO에 정의된 표준 스펙이라는 겁니다. 그러니까, country를 알려달라고 요구해도, "Korea"라든가 "대한민국"같은 형식으로 돌아오지는 않는다는 거지요.
각각의 필드에 대한 스펙 및 Simple Registration Extension에 관한 더 자세한 설명은,
여기를 참고하세요.
에.. 하여튼간에, 실제로 Simple Registration Extension을 이용하려면,
[php]
$auth_request->addExtensionArg('sreg', 'policy_url', 'http://consumer.com/policy');
$auth_request->addExtensionArg('sreg', 'required', 'email');
$auth_request->addExtensionArg('sreg', 'optional', 'nickname');
$auth_request->addExtensionArg('sreg', 'optional', 'gender');
$redirect_url = $auth_request->redirectURL($trust_root, $process_url);
header("Location: ".$redirect_url);
[/php]
처럼 하면 된다는 말씀.
이제 인증 요청이 끝났습니다. redirect를 통해 Provider에게 GET 메쏘드로 인증요청을 했으니 나머지는 Provider와 사용자간에 나름의 과정을 통해 인증여부가 회신되겠지요?
전에 지정해둔 $process_url로 회신이 돌아옵니다.
다음은 $process_url에서 GET으로 돌아온 회신에 대한 처리부분입니다.
[php]
$response = $consumer->complete($_GET);
switch($response->status) {
case Auth_OpenID_CANCEL :
// 사용자가 인증을 취소했을 때의 처리
break;
case Auth_OpenID_FAILURE :
// 무언가의 문제로 인해 인증이 실패했을 때의 처리(인증을 요구한 openid가 없다든가..)
break;
case Auth_OpenID_SUCCESS :
// 인증성공!!
break;
}
[/php]
인증은 모두 끝났습니다. 간단하죠? :)
만약 Simple Registration Extension을 사용했을 경우, 요구했던 필드값들을 구해야겠죠?
[php]
$sreg = $response->extensionResponse('sreg');
echo $sreg['email'];
[/php]
이걸로 진짜 끝.
간단하죠?
그러니까 OpenID 지원하는게 뭐 대단한 것도 아닌거에요. 무슨 코어모듈을 고쳐야 한다거나 하는 작업이 있을리도 없으니까, Consumer 지원하는 건 어려운 일이 아니에요. 물론 Provider가 되려면 좀 더 복잡한 작업이 필요하긴 합니다만, Provider는 많을 필요도 없고요.
OpenID의 의의를 이해하신다면, 별 특징이나 기능도 없는 Provider가 늘어나는 건 그저 사용자들에게 불편만 주고 OpenID의 장점을 전혀 못살리는 멍청한 짓이기도 하지요.
delegation을 이용하면 어떤 Provider를 쓰든 상관없는 거니까요. (오히려 Simple Registration Extension을 지원안하는 Provider라면 편의성이 떨어지는 셈이니 이용에 고민을 해봐야겠지요. 물론 보안문제가 아직 완벽하게 해결된 것은 아니므로 SRE를 믿느냐는 좀 다른 이야기긴 합니다만.)
국내에서 OpenID를 이야기하는 사람들이 많아지긴 했습니다만... 뭐랄까, 실제 개발자들에게는 그런 뜬구름잡는 이야기보다는 간단한 샘플소스에 대한 설명 하나가 더 필요한 시점아닐까 하는 생각이 드네요. 정말로 OpenID를 널리 퍼뜨리게 하고 싶다면요. 혹은, 그냥 기술적 우위를 뽐내는 걸로 만족하는 거라면 또 다른 이야기겠지만요.
2007년 2월 21일 수요일
OpenID 그까이꺼 (1)
약속했던 대로, OpenID 구현에 대한 이야기입니다.
이번은 JanRain의 라이브러리를 이용한 초간단 OpenID Provider 제작편입니다.
JanRain의 라이브러리는 원래 Python으로 구현되었습니다만, 현재는 여러 언어로 포팅되어있지요. Ruby, Perl, PHP, DotNet, Java, ColdFusion 등이 가능합니다.
여기에서는 PHP Library를 이용하겠습니다.
주의 : php 4.3 이상. Bcmath, GMP 패키지 등이 설치되어 있어야 합니다.
MySQL의 경우에는 innoDB를 사용합니다.
1) 설치
Pear Installer가 지원된다면
pear install http://www.openidenabled.com/resources/downloads/php-openid/pear/Auth_OpenID-1.2.1.tgz
로 설치하면 간단 끝.
만약 경로를 따로 제어하고 싶다거나, 혹은 Pear를 쓸 수 없는 환경이라면, 그냥 다운로드 받아서 적당한 곳에 풀어주면 됩니다.
2) 구조
압축을 풀면 여러가지 디렉토리가 있는데, 실제적으로 중요한 곳은 /Auth입니다. 이 안에, OpenID 컨슈머와 프로바이더 모두를 위한 클래스들이 들어있습니다.
실제로 PHP4로 제작되어 있기 때문에 클래스 내부 코드들이 완벽한 OO 스타일을 유지하고 있다고 말하기는 어렵습니다. 코드들은 거의 미로수준. 게다가, 은근히 도큐먼트가 부실해서...
3) 구현
OpenID는 프로바이더와 컨슈머 사이에서 키를 발급하고 조회하는 메커니즘으로 운영됩니다. 발급된 키를 관리하는 방법은 여러가지가 있는데, 예를 들어, 메모리 세션을 이용하거나, 파일 세션, 혹은 DB 세션등을 이용하기도 하지요. 여기에서는 MySQL을 Store로 사용하겠습니다.
우선, 필요한 파일들을 include해야겠지요?
[php]
require_once('Auth/OpenID.php');
require_once('Auth/OpenID/Server.php');
require_once('Auth/OpenID/MySQLStore.php');
[/php]
내부적으로 다른 인클루드 파일들을 요구하기 때문에, include_path에 아까 설치한 Library위치를 포함시켜두면 좋겠습니다. (아니면 ini_set('include_path',) 를 설정하던가요.)
그리고 PEAR::DB를 이용한 DB커넥션을 Store로 사용할 것이므로 DB인스턴스를 만들어서 선언해줍니다.
[php]
$dsn = "mysqli://openid:password@localhost/openid";
$connection = DB::connect($dsn);
[/php]
그리고는 MySQL을 이용하는 Store 객체를 반환받아야겠지요.
[php]
$store = new Auth_OpenID_MySQLStore($connection, 'setting', 'association', 'nonce');
// $store->createTables();
[/php]
도큐먼트에 보면, 2번째 파라미터부터는 optional하다고 되어 있고, null값일 경우 default 정의된 테이블 이름으로 생성된다고는 되어있습니다만, 무엇의 문제인지 null값을 넣으면 제대로 생성되지 않더군요. 그리고 createTables()메쏘드를 실행해줍니다. 위에서는 주석처리해놓았는데, 사실 한번 테이블이 생성되면 저 메쏘드는 필요없어지기 때문입니다. 물론 여러번 실행시켜도 문제가 되지는 않습니다. (내부적으로 rollback)
이제, 해당 Store를 사용하는 OpenID Server 객체를 만들어야겠지요. 만약 다른 DB Store나 혹은 File Store를 쓰고 싶다면 해당 Store 클래스로부터 만들어진 객체를 $store로 넣어주면 됩니다.
[php]
$server =& new Auth_OpenID_Server($store);
[/php]
이제, 이 만들어진 Server 객체에 OpenID Request를 넘겨주면 되는데, 이 Request는 대개 Get메쏘드로 넘어온 값을 가지고 Request객체를 만들어 주면 됩니다.
[php]
//$value는 대개 Get으로 넘겨받은 OpenID request문자열입니다. 서버 구현에 따라 이 부분은 달라질 수도 있으니 알아서...
$request = Auth_OpenID::fixArgs($value);
$request = $server->decodeRequest($request);
[/php]
이 Request 객체의 멤버중에 mode라는 멤버가 있습니다. 이에 따라 해당 작업을 해주면 됩니다.
[php]
switch($request->mode) {
case 'checkid_immediate':
...
break;
case 'checkid_setup':
...
break;
default:
...
break;
}
[/php]
특별한 문제가 없는 한, association mode는 라이브러리에서 알아서 처리해줍니다. 물론 발급되는 키값을 바꾸거나 하고 싶다면 이 부분을 고쳐줘야겠지요. 어쨌거나, 특별히 고칠 부분이 없다면, 위의 default부분에, 아래의 코드를 넣는 것만으로 충분합니다. 이것은 user정보와는 상관없는 기본적인 handshake 단계의 통신이기 때문에 사실 건드릴 것도 별로 없는 셈이죠.
[php]
$response =& $server->handleRequest($request);
$webresponse =& $server->encodeResponse($response);
foreach ($webresponse->headers as $k => $v) {
header("$k: $v");
}
header(header_connection_close);
print $webresponse->body;
exit(0);
[/php]
checkid_setup과 checkid_immediate의 경우에는 프로바이더의 사용자 시나리오에 따라 복잡한 과정들이 처리되어야 하는데, 예를 들자면, 사용자가 인증을 허용하는지 여부등에 따라 반환되어야 하는 값이 달라져야겠지요.
만약 모든 조건이 클리어하다면, (예를 들어, Consumer사이트가 trustRoot에 포함되어 있고, 사용자가 해당 Consumer사이트로의 인증을 허락했다면...)
[php]
$response =& $request->answer(true);
$webresponse =& $server->encodeResponse($response);
foreach ($webresponse->headers as $k => $v) {
header("$k: $v");
}
header(header_connection_close);
print $webresponse->body;
exit(0);
[/php]
로 끝.
만약 Simple Registration Extended를 지원한다면, openid.sreg.required / openid.sreg.optional 의 형태(php에서는 openid_sreg_required / openid_sreg_optional 이라는 해쉬값으로..)로, 필요한 사용자의 데이터를 요구하게 됩니다. 이 경우에는,
[php]
$response->addField('sreg', 요구필드이름, 해당 데이터);
[/php]
형태로 추가해주면 되지요.(물론 $server->encodeResponse()전에..)
Provider의 사용자 시나리오에 따라서는, 로그인처리, 인증여부처리, 요구필드에 대한 허가 처리 등이 필요한 경우도 있을 수 있습니다. 그런 경우에는 Ajax나 혹은 일반 Form 형태로 사용자 브라우저에서 처리를 받은 후에, 현재 호출된 URL로 다시 redirect해주면 됩니다. (OpenID Request는 Get값으로 이루어지므로... 물론 처리페이지까지 OpenID Request들을 전달해서 그 페이지에서 처리하는 방법도 있겠지요.)
만약 올바른 요구와 답변이 아닐 경우에는,
[php]
$response =& $request->answer(false);
$webresponse =& $server->encodeResponse($response);
foreach ($webresponse->headers as $k => $v) {
header("$k: $v");
}
header(header_connection_close);
print $webresponse->body;
exit(0);
[/php]
로 해주면 됩니다.
나머지는 라이브러리에서 다 알아서 해주니까, Provider 개발자가 고민할 부분은, 사용자 시나리오를 어떻게 운영할 것인가.. 하는 부분이겠죠?
이상으로 OpenID 그까이꺼 만드는 법 Provider편 초간단 설명.
물론, 남의 라이브러리를 의지하지 않고, 프로토콜만 가지고 직접 구현할 수도 있겠습니다만, 뭐 굳이 그럴 필요 있나요?
Consumer편은 더 간단합니다만, 다음 기회에. 사실 Provider는 굳이 여러 곳에서 만들 필요는 없어요. 공연히 사용자에게 불편만 줄 뿐. 실상 Cyworld나 Naver Blog같은데서 지원하면 깨끗이 정리될 문제입니다만, 그럴 생각들은 없는 것 같고... (OpenID Provider라면 당연히 자사의 서비스에 Consumer도 붙여야 체면이 서겠습니다만... 과연 N이나 S가 그럴 것인지? ^_^)
2007년 2월 15일 목요일
부지런하란다
웹서비스 하나 제대로 쓰려면 부지런해야 한단다.
사용법 노하우까지 알려주고 잘 쓰란다.
게으르면 안되는 것인가...
게으른 컴퓨팅이 목적인 나에게, 부지런함을 요구하는 서비스따위는 필요없다.
하긴, 자신이 필요하면 얼마든지 부지런해질 수도 있을테고, 부지런한 사람에게 더 많은 혜택이 돌아가는 것도 당연하긴 한데...
부지런하고 충성도 높은 사용자만을 위한 서비스란건, 결국...
소위 웹 1.0시대 이야기 아냐?
에... 결국 그런건가. 웹 2.0은 역시 그냥 마케팅 용어?
게으른 사람을 위한 서비스 어디 없나? 은근히 기분나쁘네.
2007년 2월 14일 수요일
openid.ne.jp
근 한달여 삽질 끝에 오픈했습니다.
일본 서비스라 한국에 계신 분들이 사용할리는 없겠지만.
CNET과 니케이 등에 기사가 났더니 제법 많이 들어오는군요. 일본 최초의 OpenID 구현이라 관심들이 많은가 봅니다.
물론, 서버만 제공해서는 아무 의미도 없으니, choix에 OpenID 컨슈머 모듈을 붙여 가입과 로그인을 OpenID로 가능하게 했습니다. News 2.0에도 조만간 붙겠죠.
JanRain의 라이브러리를 많이 참고(실은 거의 베꼈...)했음에도 여전히 숨은 버그들이 있습니다. 안들키기만 조마조마하게.. ^^; 실은 아직까지도 livejournal.com에는 왜 연결이 안되는지 원인파악도 안되지만.
저는 웹 프레임워크를 설계하고 OpenID 인증 파트를 개발했습니다. HTML 코드에 손댈 수 있는 상황이 아니라서, 코드에 불만이 있으신 분들도 있겠지만 조만간 깔끔하게 웹표준이 가능하도록 바꿔놓겠습니다. 그래도 javascript 없이 동작하고, 마이크로포맷을 조금 응용해넣기까지는 했습니다. 조금씩 고쳐가야죠.
시간이 나면 OpenID 서버와 컨슈머 구현에 대해 조금씩 정리해볼까 합니다. 저 자신도 아직 완벽히 프로토콜을 이해하고 있지는 못해서 말이지요. 복습하는 마음으로... :)
ps. 오픈마루 분들이 일본에 오셔서 오픈아이디 이야기를 꺼내셨을 때는 회사 내에서 다들 뜨끔... 조금 빨리 준비했다면 한국에서도 먼저 오픈할 수 있었을 텐데... 뭐, 그래도 OpenID를 이용하는 서비스들이 늘어난다면 좋은 거지요. OpenID 컨슈머들이 많이 늘어났으면 좋겠습니다.
2007년 2월 12일 월요일
FF Extension - Operator
매우 Cool한, 그러나 한국에서는 제대로 써먹지 못하는 익스텐션을 하나 소개하려 합니다.
제가 계속해서 마이크로포맷(microformat)에 관심을 가져온 것에 대해, 이 블로그에 자주 방문하시는 분들은 이미 알고 계시겠지만.
가끔 듣는 질문은, "그런데 마이크로포맷을 과연 실생활에서 써먹을 수 있는 건가요?"입니다.
지금 소개해드릴 익스텐션은 마이크로포맷이 어떤 식으로 쓰일 지에 대한 하나의 예시라고 할 수 있겠네요.
Operator는 현재 보고 있는 웹페이지의 마이크로포맷을 분석해서 다른 서비스와 연동시키는 익스텐션입니다.
Operator가 파악하는 마이크로포맷은 현재,
hCard - 누구
hCalendar - 언제, 무엇
geo - 어디서
hReview - 무엇에 대해
tag - 어떤 키워드
hResume - 어떤 이력
xFolk - 어떤 북마크
hCalendar - 언제, 무엇
geo - 어디서
hReview - 무엇에 대해
tag - 어떤 키워드
hResume - 어떤 이력
xFolk - 어떤 북마크
입니다.
페이지 내에 구성된 이러한 데이터를 가지고 다음과 같은 여러가지 액션들을 수행할 수 있습니다.
내 "주소록"에 연락처 추가하기
내 "iCal"에 이벤트 정보 추가하기(혹은 Outlook에, 혹은 Google Calendar에...)
GoogleMap으로 해당 페이지에 언급된 장소 찾아보기(혹은 YahooMap으로..)
GoogleMap으로 해당 페이지에 언급된 인물의 주소 찾아보기
del.icio.us에 해당 태그로 컨텐트 북마크하기
Flickr에서 이 컨텐트와 관련있는 이미지 찾기
Technorati에서 관련 블로그 찾아보기
Yedda에서 관련 정보 찾아보기
Upcoming.org에서 관련 이벤트 찾아보기
Ma.gnolia에 이벤트나 장소, 인물을 저장해두기
내 "iCal"에 이벤트 정보 추가하기(혹은 Outlook에, 혹은 Google Calendar에...)
GoogleMap으로 해당 페이지에 언급된 장소 찾아보기(혹은 YahooMap으로..)
GoogleMap으로 해당 페이지에 언급된 인물의 주소 찾아보기
del.icio.us에 해당 태그로 컨텐트 북마크하기
Flickr에서 이 컨텐트와 관련있는 이미지 찾기
Technorati에서 관련 블로그 찾아보기
Yedda에서 관련 정보 찾아보기
Upcoming.org에서 관련 이벤트 찾아보기
Ma.gnolia에 이벤트나 장소, 인물을 저장해두기
한국에서는 사용이 거의 힘든 서비스입니다. 하긴, 외국에서도 아직은 그다지 마이크로포맷 자체가 널리 퍼지진 않았습니다만, 그와는 별개로, 마인드 자체가 국내에서는 아직 성숙하지 않아서지요. Yahoo나 Google, Technorati같은 굵직굵직한 벤더들이 마이크로포맷을 적극적으로 활용하고 있는데 반해, 국내 IT서비스들은 아직 마이크로포맷이 무엇인지 조차 모르는 경우가 대부분이고, 당장 업무에 적용시켜야 할 HTML 퍼블리셔, 기획자, 개발자들이 시맨틱 마크업에 대해 익숙치 않아서입니다.
나름 개인적으로 비슷한 서비스를 만들어서 혼 쓰고 있었습니다만, 확실히 브라우저단으로 기능이 올라가니까 훨씬 사용하기 쉽군요. 웹용으로 만든 건 폐기처분하고 이 익스텐션을 적극 활용해야겠습니다.
2007년 2월 8일 목요일
Just a memo
* 'Social Network' 에는, 'relation'만 있을 뿐, 'society'가 없다.
* 'trust'는 객관적인 가치로부터 나오고, 'reliability'는 주관적인 경험으로부터 나온다.
추가
http://hentol.com/tt/13 :
1. 모든 권력은 부패한다.
2. 절대권력은 절대부패한다.
3. 대중권력은 대중적으로 부패한다.
작년 황우석 난동 때부터 우려한 바이지만, 결국 대중에게 쥐어진 인터넷 권력은 통제되지 못하고, 통제될 수도 없다. People Power와 Collective Intelligence는 결국 지극히 구현되기 어려운 이상향 - 또하나의 사회주의 지상낙원 - 의 재판이 될 가능성이 점점 농후해진다.
요즘의 마이붐은 CI 만능론을 경계하기. Reputation은 생각만큼 효율적이지도, 올바르지도 않은 가치판단기준. (역시, Reliability 를 기반으로한 기계가 최선일꺼나...)
2007년 2월 6일 화요일
I hate WordPress
호스팅을 옮기면서 잠깐 고민하다 결국 WP를 다시 깔았는데...
나는 WP가 싫다.
테마와 플러그인의 dependency를 관리하지 못해 매우 복잡한 이전 절차를 거쳐야 하고...
빨라졌다고는 하나, Static Build의 효율성을 이길 수 없으며,
게다가 테마에 박혀있는 태그들은 잘도 이런걸 가지고 테마를 만드는구나 하는 생각.
이게 테마야? 프로그래밍이지...
테마 템플릿들은 모두 자기 멋대로 만들어 개념도 의미도 없고... 스파게티.
설치된 코드들은 역겹다. 손대고 싶은 생각도 별로 안든다.
어째서! MovableType이 더 깔끔하고 쉬운데도 왜 WordPress가 대세란 말인가! 단지 Perl과 PHP의 차이?
투덜투덜대면서도 결국 사용하긴 하지만... 에이.
밤새서 작업해야 하는데 두시간동안 쓸데없이 WP Config에 바쳤네. 공연한 화풀이려나.
2007년 2월 3일 토요일
좋은 프린팅을 위해
egloos가 print.css를 추가했다.
아주 바람직하고 좋은 시도. 불필요한 장식도 없고, 컨텐트에만 집중할 수 있고, 별도의 인쇄하기 버튼따위가 들어있지도 않다.
그러나 여전히 약간의 아쉬움이 남는다.
과연 인쇄를 위해서는 어떠한 UX가 더 필요할까?
1. 인쇄 전용 CSS
어떤 면에서 프린터는 브라우저보다 CSS를 더 잘 구현해내기도 한다.
이글루스의 경우 print.css를 붙이기는 했는데, 실상 상당히 단순한 속성들로 구성되어 있다. 프린트 전용 CSS라기 보다는, 마치 초단순 스킨이라고 불리워도 무방할 정도로.
기왕 프린트를 위한 CSS라면 프린트 전용 CSS를 맘껏 사용해보는 것도 좋았을 텐데.
(이 print.css가 이글루스 스킨 시스템에 포함되어 사용자가 마음껏 고칠 수 있는 종류의 것인지는 모르겠다. 그렇다면, 심플한 CSS만 제공하고, 기교를 부리는 건 사용자에게 맡기도록 하는 것은 좋은 방법일 수 있다.)
아무튼, 인쇄 전용으로 사용가능한 방법으로는,
셀렉터
@page : .페이지 단위의 셀렉터. 하나의 페이지로 이루어진 모니터와는 달리, 인쇄는 물리적인 여러개의 페이지로 이루어진다.
@bottom-left-corner, @bottom-left, @bottom-center, @bottom-right, @bottom-right-corner : 페이지의 푸터영역 셀렉터(bottom-margin이 있는 경우)
@top-left-corner, @top-left, @top-center, @top-right, @top-right-corner : 페이지의 헤더 영역 셀렉터 (top-margin이 있는 경우)
속성
page-break-after, page-break-before, page-break-inside : 보기좋은 인쇄를 위해 강제로 페이지 브레이크를 걸어야 할 때 사용.
content : 해당 셀렉터에 인쇄시 내용을 추가할 때 사용한다. (예를 들어 @page:first의 @top-left-corner에 저자 이름을 따로 적어둔다거나 하는 식.)
counter-increment, counter-reset : 인쇄물의 페이지 번호등을 조절할 때 사용.
이외에도 더 많은 테크닉들이 있으나 프린터 및 프린터 확장 호환장비들에 따라 미세하게 다르므로 대충 이정도로 소개만. 더 자세히 알고 싶으신 분은, 여기를 참고.
기타 주의사항 :
프린터는 최소한 16가지의 색상을 구별이 가능하도록 다른 형태로 인쇄할 수 있다-인쇄해야 한다.(흑백이라 하더라도 패턴등의 방법을 사용하여.)
프린터는 인쇄물에 대한 페이지 사이즈를 지정할 수 있어야 한다.
2. 링크
링크는 웹문서의 기본이며, 문서의 가장 중요한 컨텐트 요소중 하나이다.
그런데 인쇄를 하면 이러한 링크정보가 사라지게 된다.
링크가 사라진 문서에, '링크였던' 부분에 밑줄만 쳐져 있어 봤자 무슨 소용이 있을까.
erehwon님의 포스팅으로 보아 아마도 이 문서를 참조한 것 같은데, 해당 문서 중에 좋은 팁이 들어있다.
[css]
#content a:link:after, #content a:visited:after {
content: " (" attr(href) ") ";
font-size: 90%;
}
[/css]
못보고 지나쳤을리는 없을 텐데, 왜 안들어 있을까.
아마도 링크를 인쇄물에 포함시켰을 때 인쇄물이 너무 지저분해지기 때문이었으리라. 또, IE에서는 통용되지 않는 다는 점도 고려되었을테고.
그럼에도 불구하고, 링크의 인쇄는 미관적인 이유로 빼버리기에는 너무 중요한 요소이다.
좋은 방법이 있을까?
몇십줄의 자바스크립트의 추가로 더 유용한 인쇄물을 만들 수 있다.
지금 보고 있는 이 페이지를 인쇄하고 그 결과를 이글루스의 그것과 비교해보자. 대부분 거의 비슷하겠지만,
단 한군데 다른 점을 발견할 수 있을 것이다.
(예시로 들기에는 이 블로그의 디자인이 너무 심플한데다가, 본인은 디자이너도, 퍼블리셔도 아니기에. 더 좋은 예시를 들지 못함이 아쉽다.)
3. 더 생각해 볼 만한 것 - selective print.
개인적으로는 그다지 좋은 방법이라고는 할 수 없기에 간단히 링크만 걸어둔다.
프린터용 CSS를 만드는 간단한 방법.
1. 인쇄에서는 사용할 수 없는 기능이 담긴 엘리먼트(검색창, 메뉴등)를 display:none;으로 감춘다.
2. 폰트타입을 바꾼다. 인쇄시에는 작은 글씨의 경우 모니터와는 달리 serif 종류의 폰트들이 더 가독성이 높다. 인쇄물의 특성을 고려하여 폰트를 바꿔준다.
3. 장식용 이미지가 필요하다 해서 HTML코드를 다시 고치지 말고, :after, :before등의 pseudo-element를 사용해 인쇄용 이미지를 추가한다.
4. 대개의 경우, 공용 CSS등에서 bullet 스타일을 지워버렸을 수 있다. 인쇄시에는 까먹지 말고 다시 bullet스타일을 지정해주자.
5. position, float을 사용한 블록들은 인쇄시에 의도한 곳과는 다른 곳에 인쇄될 수 있다. 되도록이면 복잡하지 않은 인쇄레이아웃을 잡도록 한다.
다음은, W3C에서 제공하는 인쇄용 CSS 샘플이다. 이걸 그대로 쓰라는 것이 아니라, 일종의 초기화 가이드라인 삼아 제작하면 좋을 것이다.
[css]
th { font-weight: bolder; text-align: center }
caption { text-align: center }
body { line-height: 1.33 }
h1 { font-size: 2em; margin: .67em 0 }
h2 { font-size: 1.5em; margin: .83em 0 }
h3 { font-size: 1.17em; margin: 1em 0 }
h4, p,
blockquote, ul,
form,
ol, dl { margin: 1.33em 0 }
h5 { font-size: .83em; line-height: 1.17em; margin: 1.67em 0 }
h6 { font-size: .67em; margin: 2.33em 0 }
h1, h2, h3, h4,
h5, h6, b,
strong { font-weight: bolder }
blockquote { margin-left: 40px; margin-right: 40px }
i, cite, em,
var, address { font-style: italic }
pre, tt, code,
kbd, samp { font-family: monospace }
pre { white-space: pre }
big { font-size: 1.17em }
small, sub, sup { font-size: .83em }
ol, ul, dd { margin-left: 40px }
ol { list-style-type: decimal }
ol ul, ul ol,
ul ul, ol ol { margin-top: 0; margin-bottom: 0 }
br { content: "\A" }
@media print {
@page { margin: 10% }
blockquote,
pre { page-break-inside: avoid }
}
[/css]
2007년 2월 2일 금요일
2007년 2월 1일 목요일
고맙다고 AdSense 클릭하지는 마세요.
생각난 김에 마저 적고 자야겠다.
기획자가 미처 생각하지 못한 용도로 확장해 활용해주기를 모든 서비스 기획자가 꿈꾸긴 하지만...
그렇다고 하지 말라는 것까지 교묘하게 에둘러 활용하는 능력은 전세계에서 우리가 일등일 듯.
원래 구글 애드센스의 목표(?)는, "되도록이면 클릭하지 마시오."라고 표현할 수도 있겠다.
엥? 광고인데 클릭이 많이 되면 좋지 않아?
단기적으로 보면 광고주들은 일견 클릭유입이 늘어나면 이득처럼 느껴지겠지만, 장기적으로는 클릭의 증가는 광고주에게는 그다지 바람직하지 않은 현상이다.
비싼 단가 내고 오버추어 광고 신청했더니 경쟁사가 일부러 자사의 광고를 부정클릭해대는 바람에 엄청난 피해를 봤다는 광고주는 한 둘이 아니다.
애드센스는 이러한 것을 막기 위해, 방문자가 되도록이면 클릭을 하지 않도록 하고 있다. (Don't be evil.)
그래서 컨텐트로 오해받지 않도록 하고, 유혹하는 장식도 넣지 못하게 하고, 어필리들이 클릭을 유도하는 행위도 못하게 한다. 방문자의 '가독성을 위해' 그러지 말라는 것이 아니라는 말씀.
클릭이 늘어나면, 구글로서야 수수료가 늘어나니 좋을 듯 하지만, 종합적으로는 광고 시스템에 대한 신뢰를 떨어뜨리게 된다. 무슨 소린고 하니, "구글 애드센스 프로그램에 참여해서 광고비를 집행했더니 트래픽은 확실히 늘었는데, 우리 상품 판매량은 그대로네..."라는 소리가 광고주 입에서 나오면 이 시스템은 광고매체로서의 매력을 잃게 된다는 뜻.
따라서, 되도록 클릭이 발생하지 않도록 외관도 수수하고, 되도록이면 낙시성 광고가 오르지 않고 진짜로 그러한 난관(?)에도 불구하고 꼭 필요한 사람만 클릭하도록 문맥광고를 하는 것인데...
"좋은 글을 읽어 감사의 뜻으로 애드센스 클릭해드려요." 라는 사용법이라니, 애드센스 기획자가 들으면 펄쩍 뛸 일이다.
'감사의 뜻'으로 애드센스 클릭한 방문자가 그 광고 자체에 관심이 있을리는 만무, 고작해야 창이 뜨자마자 닫아버릴 터.
광고주로 보자면 미치고 환장할 일. 클릭은 발생해서 광고비는 나가는데, 그렇게 유입된 트래픽이 고작 0.1초짜리 뜨내기라니.
이런 행위가 점점 많아지면, 한마디로 같이 죽자.. 상황이 된다.
'감사의 뜻'을 애드센스 클릭으로 표현하는 이들은 장기적으로 애드센스 자체를 망하게 하는 데 일조하는 셈. 뭐야, 모두들 알고보니 안티구글?
조금 관점을 바꿔서...
'감사의 뜻'을 고작 코멘트 하나와 클릭 한번으로 때우려 하다니 너무 싼 거 아냐? 라는 생각도.
진짜로 고맙다면, 애꿎은 광고주의 피같은 광고비를 마치 자기 쌈지돈인양 선심쓰지 말고,
단돈 10원이라도 자기 주머니에서 직접 지출해야 하는 것 아닌가?
생각의 역발상. 차라리 누군가 기부시스템을 만들어보는 건 어떨지?
"진짜로 제 글이 도움이 되어 고맙다고 느꼈다면 이 버튼을 클릭해서 100원씩 부탁해요."
(오마이뉴스의 좋은 기사 원고료후원을 생각해보면 되겠다.)
과연 사람들이 할까? ㅋㅋ
말로 고맙다고 하는 것은 쉽지만, 정말 자기 주머니에서 100원이라도 꺼내 줄 사람들은 얼마나 될까? 뭐, 100원 내는 사람이 한명뿐이라면, 그 글은 고작 100원짜리 글이겠지. 컨텐트에 대한 가치를 측정하는데 이보다 더 좋은 방법도 없겠다.
Assert를 잘하자.
오늘의 교훈: Assertion의 습관화.
Code Complete에 보면, Assert에 관해 한 장을 할애할 정도로 중요하게 여기고 있다. The Pragmatic Programmer에서도 중요하게 다루고 있는 주제.
원론적인 면에서 동의하면서도 현실에서 체감한 적은 별로 없었는데... (솔직히, 너무 뻔한 이야기 아닌가... 라는 생각까지 했었다.)
근 2주가까이 한가지 문제를 해결하기 위해 고민하고 있었는데, 정작 문제는 너무나 간단한 곳에 있었다.
[php]
private function doSomething($param=null) {
...
}
[/php]
이런 메쏘드가 있을 때, 이 코드로만 보아서는 $this->doSomething();처럼 호출해도 문제가 없을 것 처럼 보인다. 주석 및 도큐먼트에는 심지어, $param은 optional하다고 적혀있기까지 하다.
그런데 실제로, 코드를 추적해본 결과, 개발자의 의도와는 달리 이 코드는 특정조건 하에서는 $param값이 null이 되면 오작동하도록 만들어져 있었다.
일차적으로는 개발자가 주석과 도큐먼트를 잘못 작성한 셈이지만,
근본적으로는 Assertion을 제대로 하지 않은 코드의 문제. 선행조건을 엄밀히 명시해두지 않았기 때문에 발생했다.
최소한 다음처럼 코드가 작성되어 있었어야 했다. 오류를 해결하는 것보다, 보고하는 것이 먼저다.
(어디가 문제인지 알아야 고치기라도 할 것 아닌가.)
[php]
private function doSomething($param=null) {
assert('$this->someCondition || $param');
...
}
[/php]
물론 동적으로 생성되는 값들에 대해 미리 선행조건을 알고 있기가 불가능한 경우도 있겠다. 그런 경우에라도 크리티컬한 미션을 수행하기 직전에, 해당 미션이 클리어되기 위한 선행조건에 대한 assertion을 붙이는 방어적 프로그래밍을 습관화해야겠다.
* 좋은 Assertion을 위한 지침. (from Code Complete)
1. 여러분이 발생할 것이라고 예상하는 상황들에 대해서 오류처리코드를 사용하라. 즉, 절대로 발생해서는 안 되는 조건을 위해서 어설션을 사용하라.
2. 실행가능한 코드를 어설션내에 입력하지 않는다.
3. 선행 조건과 후행 조건을 문서화하고 검증하기 위하여 어설션을 사용하라.
4. 매우 견고한 코드를 작성하기 위해서는 어설트한 다음 오류를 처리하라.
* PHP를 위한 assert function
[php]
assert_options(ASSERT_ACTIVE, 1);
assert_options(ASSERT_WARNING, 0);
assert_options(ASSERT_BAIL, 1);
assert_options(ASSERT_CALLBACK, 'assertHandler');
function assertHandler($file, $line, $message) {
echo "$file : $line : $message";
}
...
assert('some assertion syntax...');
[/php]
가독성
가독성에 대한 이야기들이 있던데...
글쎄, 나같으면 광고 때문에 저해받는 가독성을 논하기 전에...
울긋불긋한 배경 좀 바꾸고, 자간과 폰트를 먼저 바꾸고, 페이지 로딩 속도부터 올려달라고...
아니, 뭐, 그보다도... 읽을 만한 가치가 있어야 읽지. 그물질들 말고.
광고때문에 시선이 방해되서 좋은 글을 읽는데 방해가 된다라... 애초에 시선이 방해될 정도의 광고로 덮는 블로거의 마인드에서 좋은 글이 나올 수나 있던가? 내용은 좋은데 광고가 있어서 나빠지는 가독성? 그럼 반대로 광고만 없어지면 가독성이 올라가는 건가?
기우... 라고들 하지. 뭐랄까, 일어나지 않을 일에 대한 걱정?
A라는 블로그의 글은 정말 다 좋은데, 광고가 너무 많아요... 인 케이스가 있나? 있다면 내 편견을 바꿔보겠음.
지금까지는 광고에 시선이 방해되는 경우는 모르겠고, 스킨 때문에 시선이 방해되는 경우는 많이 있으니까. 나역시도 종종 유혹에 빠지기도 하고.
그런 걸 고민할 시간에 나같으면 애드센스 필터링 플러그인을 FireFox에 설치하겠다. IE용으로도 있지 않나? 정 보기 싫다면 말이지.
---
오늘의 유머.
궁극의 츤데레는...
욕쟁이 할멈? (동료와 식사 중)
2007년 1월 31일 수요일
macbook pro, smackbook pro
맥북프로를 사용한지 9개월이 되어갑니다만, 만족도는 근 20여년의 컴퓨팅 환경중에 가장 손꼽을 만합니다.
사실, 이전에 8500이나, G4를 썼을 때는 별다른 장점도 못느꼈고, 늘 사자 마자 방치플레이 후 매각… 이었습니다만, 드디어 Intel기반에 OSX 10에 이르러서는 거의 완전히 Windows를 버리게 되었습니다. 일단 부트캠프를 설치해두긴 했습니다만, FootBallManager를 하기 위한 용도 외에는 Windows 부팅할 일 조차 없게 되었습니다.
제가 여전히 Windows 어플 개발을 했다면 Windows를 계속 썼겠습니다만, 웹환경 그것도 LAMP기반이 되다보니 MBP는 개발자에게 최상의 환경을 주는군요.
- MBP에 LAMP를 바로 설치하고, 실서버, 개발서버와 연동시켜 완벽한 개발/테스트 환경을 구축할 수 있습니다. 물론 윈도우즈 환경에서도 나름 WAMP를 설치할 수도 있겠으나 미묘하게 불편함이 있었습니다.
- 개발에 주로 사용하는 도구는 ZendIDE와 Eclipse인데, 둘다 OSX에서 훌륭히 잘 돌아갑니다. 특히 ZendIDE는 Windows에서는 크래쉬가 잘 일어나는데 비해 OSX에서는 거의 크래쉬없이 돌아갑니다.
- 물론 vi도 빼놓을 수 없겠죠. 콘솔 터미널이 시스템과 일체화되어서 네트웍을 넘나드는 작업의 만족성은 Win에서의 그것과 비할 수 없습니다.
- 솔직히, PowerPoint가 Keynote보다 편하긴 합니다만, 만들어진 결과물은… Keynote는 당신을 프로 발표자로 만들어줍니다. PT때 효과 200%죠. 너무 화려해서 사람들이 강연내용보다는 슬라이드 화면에 넋이 빠지는 단점이 있긴 합니다만.
해서.. 새로 오픈하는 서울 사무소에는 개발자 전원에게 맥을 지급할까… 진지하게 고민 중입니다.
비용이 적다고는 할 수 없는게 단점이긴 하지만.
—
SmackbookPro 동영상을 보고 반해서 설치해봤습니다만…
일주일간 사용해본 감상은 미묘. 랄까.
손으로 탁탁 쳐서 버추어데스크탑 페이지를 넘기는 것이 재밌긴 합니다만, 감도 조절이 미묘하게 힘듭니다.
너무 민감하게 해놓으면 책상위에 볼펜이 떨어져도 페이지가 휙 넘어가 버립니다. 그렇다고 둔감하게 해놓으면 맥북프로를 치는 힘이 세져야 합니다.
무엇보다도 조용한 사무실에서 탁탁 거리며 노트북 모니터를 치고 있는 모습을 반대쪽에서 보게 되면, 마치 고장난 흑백텔레비전을 때려서 나오게 하는 것 같은 모양. 맞은 편에 앉은 모리야 상이 뭐하는 짓인가 쳐다보는 것을 깨달으면 어찌나 민망한지…
그래도 요즘은 노하우가 늘어, 미묘하게 무릎으로 책상 모서리를 살짝 건드림으로써 페이지를 넘기게 하고 있습니다. 이른바, 전신 컴퓨팅이랄까요? ^_^;;
BT 키보드와 BT 마이티마우스까지 겸비하고 듀얼모니터(시네마 디스플레이는 아니지만.)를 사용하니 당분간 업그레이드 욕구는 없을 것 같습니다.
한줄 요약 : 저 맥빠돌이 맞습니다. ^_^
2007년 1월 30일 화요일
소중한 방문자
답글인사같은 것 거의 안하는 eouia입니다만, 찾아주는 분들 모두 소중하게 생각하고 있습니다.그래도 사람인지라, 실은 마음속에는 방문자마다 레벨을 매겨두는 것은 어쩔 수 없다고 변명을 일단.나름 방문자들을 몇개의 그룹으로 나누고 있습니다. 개인의 임의적인 기준은 아니고, 완전히 기계적으로 유입경로별로의 그루핑입니다.
1. 가장 기쁜 그룹은 외부링크를 타고 오시는 분, 혹은 외부링크로 걸어주신 분들입니다.콕 찝어 제 블로그나 포스트를 언급해주셨다는 이야기는 어떤 식으로든 그 블로그와 그 포스트가 유의미하고 리마커블했다는 의미니까요. 게다가 그것을 혼자 보관하지 않고 다른 이들에게도 노출시켜주신다니 황송할 정도입니다. 레퍼러를 볼 때마다 이 트래픽이 가장 기쁩니다.
2. 그다음은 북마커 또는 RSS 리더를 타고 오시는 분들입니다.어찌보면 첫번째 그룹보다 저를 높게 평가해주는 분들입니다만, 저역시 RSS리더를 건성건성 읽고 있기 때문에 많은 분들이 또한 제 블로그 역시 건성건성 읽고 있을 것 같다는 선입견 때문에 두번째 자리를 차지하게 되었네요.그래도 무섭기는 이 분들이 제일 무서워서, 꾸준히, 쓸모 있는 포스팅을 하지 않으면 이 분들은 RSS 리더에서 삭제하실테죠. 리더기로 잡히는 레퍼러들은 채찍질의 의미로 받아들이고 있습니다.
3. 검색엔진에서 오시는 분들도 반갑죠.이 분들은, 정말 본인에게 필요한 정보를 찾다가 제 블로그까지 흘러오셨을 텐데요. 그래서 한편 도움이 될 지도 모른다는 뿌듯함과 함께, 기껏 찾아왔는데 도움이 안되면 어쩌나 하는 걱정도 있습니다. 그래서 검색엔진을 타고 오신 분들께는 찾으셨던 검색어와 관련된 글들을 모아서 보여드리고 있습니다. 만약 검색어와 관련된 글들이 여러개 잡힌다면 그 분들은 그나마 제 블로그에 맞게 찾아오신거고 (실제로 도움이 되는 포스팅이었는지는 별개로.. ), 또 만약 관련 글들이 안잡힌다면, 일부러 제 블로그에서 시간 낭비하며 찾아볼 필요가 없다는 걸 아실테지요.
4. 가장 끄트머리는 메타블로그들이 차지하고 있습니다.이제는 메타블로그에 대한 관심도 거의 없어졌어요. 실상 늘 혹시나 하고 메타블로그에 방문했다가, 역시나 하고 돌아오는 날의 연속입니다. 거의, 포털 뉴스 페이지와 똑같은 취급을 저한테 받고 있습니다. ^^;포스팅이 있는 날은 메타블로그로부터의 유입량이 꽤 됩니다만, 전혀 엔터테인먼트 적인 성격이 아닌 제 블로그에 두번 방문하실 일은 없으신 분들이겠죠. 오히려, 도대체 내가 얼마나 자극적인 제목을 붙였길래 메타블로그를 타고 들어왔을까... 반성하는 계기가 됩니다. (메타에 등록된 모든 글들을 눌러보시는 분은 없잖아요. 결국 제 글을 클릭하신 분은 제 낙시질(?)에 걸린 셈인거죠.)그럼에도 불구하고 메타블로그에서 내리지 않고 있는 이유는, 결국은 설치형 블로그의 어쩔 수 없는 숙명이랄까요. 자력으로 외부에 노출시킬 수 있는 수단으로서의 대안이 없기 때문입니다.거의 계륵...인 셈입니다. 좀 더 고민을 해봐야겠군요.하지만, 내 맘속에서의 제멋대로 편견일 뿐, 일단 방문해주신 모든 방문자들은 소중하답니다. ^_^;
2007년 1월 29일 월요일
근황
1. hosting을 옮기겠다고 말을 하자마자, 갑자기 속도가 조금 빨라졌습니다. 특유의 게으름이 발동해서 호스팅 이전은 잠시 보류. 그러나 다음번에 또 이런 일이 발생하면 진짜 옮길 겁니다.
2. 귀국하면 운동을 해야겠어요. 체중이 많이 불었습니다. 더불어 뱃살도. 야채가 적고 육류가 빠지지 않으며 튀기기는 기본인 일본음식만 먹었더니 살이 뒤룩뒤룩. 일산에서 신촌까지 자전거로 다녀볼까... 생각중입니다. 아마 힘들겠지만.
3. 2월 3일부터 8일까지 일시로 한국에 들어갑니다. 날짜로는 6일인데, 고향에 다녀오고, 병원가고, 카메라 팔고, 구인자 면접보고, 강연(?) 한판 때려주기에 시간이 빠듯. 혹시 긴한 일로 저를 봐야할 일이 있으신 분은 이 기간동안에 미리 약속을 잡아주세요.(없겠지만.)
실은, 이발이 더 급해요. 여기는 이발하는데 너무 비싸서.
4. 와이프 몰래(..라고는 해도 여기 써놓으면 읽어보니까 몰래도 아니지요.) XBOX 360이라도 사들고 가려 했는데 일본내에서도 품절입니다. 엑박은 물론, PS3고, NDSL이고 모두 품절이에요. 심지어 이번에는 꼭 사야지 맘 먹었던 18-200 VR2렌즈도 품절. 뭡니까 이건. 환율이 750원대라고 기뻐해도 보람이 없잖아요!
어쩌다 아키하바라의 요도바시에 가면, 평일 낮에도 게임사러온 아저씨,언니들이 몇시간씩 줄을 서있어요. 과연 일본이구나 싶네요.
5. 오픈소스 프로젝트를 해야지 맘먹고, 여전히 빈손입니다 그려. 바쁘면서도 게으른 탓이지요.
2007년 1월 25일 목요일
Google Calendar로 소규모 일정 관리하기
개인적으로는 MS Project의 강력함에 흠뻑 취해있고, Windows환경만 생각한다면 Outlook만으로 충분히 프로젝트 일정 관리를 해낼 수 있지만...
어쩌다보니 그런 환경이 여의치 않을 때 소규모 프로젝트를 관리해야한다면 Google Calendar를 추천합니다. 물론 프로젝트 참여인원 모두가 Google 계정이 있어야 한다는 제약이 있긴 하지만요.
사실 많은 회사에서 인트라넷으로 프로젝트 관리 도구를 사용하고 있습니다만, 지금까지 경험해본 바, 그러한 솔루션들이 구글 캘린더보다 못하더군요.(Outlook보다 못함은 당연하구요.) 물론, ERP환경에서 전자문서결재...등등을 포함하는 기능들은 분명 훌륭합니다만, "일정관리/공유"라는 면에서 본다면 많이 미흡하지요.
하긴, 그나마 그런 인트라넷도 없어서 여전히 엑셀 시트에 달력 그려서 관리하는 곳도 있으니까, 그런 열악한 환경이라면 구글 캘린더를 일정관리에 사용해보는 것도 괜찮겠습니다.
[프로젝트 관리자]
1. 프로젝트 관리자는 프로젝트 이름으로 새로운 Google 계정을 하나 만듭니다. (ex:ourproject@gmail.com)
2. 만들어진 계정으로 접속해서 Google Calendar로 들어간 다음, 왼쪽 하단의 Calendars에 "My Calendar +" 버튼을 클릭해 새 캘린더를 만듭니다.
3. 프로젝트 전체와 관련된 일정 (예:Milestone)을 입력합니다.
4. 이제, 만들어진 캘린더를 프로젝트 멤버들과 공유해야겠지요. "이 캘린더 공유"로 들어가 멤버들의 Google 계정을 사용자로 추가해줍니다. 이 때 옵션은 "모든 이벤트 세부정보 보기"(멤버들이 보기만 하고 변경은 할 수 없습니다.) 로 놓는게 좋겠지요.
5. Trac등의 관리도구를 쓴다면 거기에서 만들어진 일정 데이터를 iCalendar형태로 입력받을 수 있습니다. "기타 캘린더 +" 버튼을 눌러 "공개 캘린더 주소"로 들어가 Trac등에서 만들어진 일정데이터의 iCalendar주소를 입력하면 됩니다.
[프로젝트 멤버]
1. 멤버들은 각각 자신의 구글 캘린더에 접속한 후, 역시 "내 캘린더"를 새로 만듭니다.
2. 캘린더 이름에 자신의 이름을 적어 새로운 개인 업무 일정 캘린더를 만든 후에,
3. 역시 캘린더 공유에서 프로젝트 관리자를 공유 사용자로 추가해줍니다. 이 때 옵션은 "변경 및 공유 관리"로 해두어야 프로젝트 관리자가 각 개별 멤버의 일정을 조정한다든가 하는게 가능해지니 주의.
4. 자신의 캘린더를 수정하면 프로젝트 관리자의 캘린더에도 수정사항이 반영됩니다. 물론 그 반대도 가능.
5. 만약 캘린더 중의 특정 이벤트가 "회의"나 "공동작업"처럼 다른 사람과 공유되어야 할 경우, 이벤트 수정 페이지에서 해당 멤버를 "손님"으로 추가함으로써 이벤트를 공유할 수 있습니다.
6. 프로젝트 관리자가 새 이벤트를 각각의 멤버에게 할당한다든가 커멘트를 남긴다든가 하는 활용법도 있겠지요.
7. Gmail을 통해 여러가지 notifying이 가능하므로 평소에 Gmail 을 볼 수 있는 Alarm기능을 데스크탑에 설치해두는 쪽이 좋겠습니다. (Google Desktop이나, GoogleTalk나... 혹은 Gmail을 자신의 메일 클라이언트에서 받아 볼 수 있게 한다든가...)
[자신의 PIMS와 싱크하기]
안타깝게도, 아직 Google Calendar와 양방향 싱크가 되는 PIMS는 없는 것 같네요.
일단 OSX의 iCal에서는 단방향 싱크는 가능합니다.(Outlook Vista에서도 가능할지도. 테스트는 안해봤습니다.)
사용법은 간단해서, 싱크를 원하는 캘린더를 선택해 설정으로 들어가면 "비공개 주소" 항목에 iCalendar URL이 있습니다. 이 주소를 복사해서 자신의 iCal에 일정 불러오기로 넣어주면, 구글 캘린더에서 변경된 내용이 자신의 iCal에서 확인할 수 있습니다. 마찬가지 방법으로 그 반대방향으로의 싱크도 가능은 합니다만, 일정의 작성은 한군데에서 통일하는 쪽이 좋기 때문에 프로젝트와 관련된 일정의 작성은 구글 캘린더에서, 보기는 iCal에서 보는 쪽을 권합니다.
[작은 팁]
1. "기타 캘린더"를 생성할 때, "캘린더 찾아보기"에 들어가면 휴일 데이터가 있습니다. 저같은 경우 일본 휴일도 필요해서 한국 휴일과 일본 휴일을 모두 추가해서 유용하게 쓰고 있습니다.
2. "비공개 주소"에서 XML이나 HTML 주소를 이용하면 Excel 등에서도 일정 데이터를 쉽게 불러올 수 있습니다. 포매팅이 필요하다면 간단한 프로그램 하나를 짜서 적절하게 리팩토링을 해주는 것도 한 방법이겠지요.
이러이러 해도 MS Project나 Outlook에 비하면 많은 기능이 불편하긴 합니다만...
무료이고, 간단하고, 무엇보다도 OSX에서 문제없이 쓸 수 있다는 점에 억지로(?) 구글 캘린더로 프로젝트 일정관리를 시도해보았습니다. ^_^
2007년 1월 22일 월요일
페이지 로딩 편집증
대부분의 브라우저에서 지원하는 기능이긴 한데, 내가 사용하고 있는 FF에서는, 페이지가 통신 혹은 로딩중에는 계속 로딩마크가 돌아감을 볼 수 있다.
아직 페이지가 로딩 중이고, HTTP 커넥션이 끝나지 않았음을 보여주는 작은 서비스니까 있어도 그만, 없어도 그만이긴 한데, 없으면 웹커넥션이 죽었는지 어떤 건지 알 수 없어 불안해지니까 있으면 좋다는 쪽.
가끔 로딩마크를 볼 때마다 강박적이 되어가는 것을 느끼는데...
1) 느리다. 느리다. 느리다.
평균 대기시간이 3.5초라는 통계결과도 있거니와, 주소창에 주소 치고 바로 페이지가 안뜨면 답답해진다. 하긴 지금 호스팅받고 있는 업체도 딱히 좋은 환경은 아닌지라 내 블로그 조차도 느리긴 한데. 여튼 페이지 로딩 마크만 돌아가고 있고 늦게 뜨는 사이트들을 보고 있노라면 조급증이...
2) 왜 아직도 돌아. 뭔가 문제 있나?
그런데, 페이지가 로딩된 후에도 여전히 로딩마크가 돌아가는 경우들이 있다. frame을 썼거나, iframe을 썼거나... 혹은 AJAX를 썼거나.
그러면 불안해지기 시작. 뭐지, 왜 이거 아직도 돌고있는 거지. 보일 건 다 보인 것 같은데 아직도 커넥션이 끊어지지 않고 뭔가 데이터가 왔다갔다 하고 있다는 것을 알면 괜시리 불안해진다. 도대체 뭐가 아직도 남았길래 데이터가 오가고 있는가. 나 몰래 브라우저 뒷면에서는 무슨 일들이 벌어지고 있는가. 데이터 주고받기가 끝날 때까지 기다려야하나? 별 잡생각이 다 든다. 직업병이라서인지 '어이구, 저 아까운 커넥션', '스크립트 소스에 문제가 있음이 틀림없어...'라는 생각이 진짜 이유와는 상관없이 먼저 드니. ㅎㅎ
frame이나 iframe이나.. 혹은 리모트 커넥션으로 인해 풀 페이지 로딩이 느린 경우야 '회선의 문제상 아직 로딩이 안끝났습니다.'라고 생각하고 조금 더 기다릴 수도 있겠지만.(사실, 그 경우에도 맘편하지는 않다. 왜 꼭 그런 방식을 써야만 하는가..라는 생각)
게다가 AJAX나 뭐 기타등등 여러 다른 최신(?)기법을 써서, 페이지가 다 로딩된 후에도 커넥션을 물고 돌아가고 있는 로딩마크들이 요즘 늘어났는데, 그것들을 보고 있노라면 답답함과 불안함이 엄습. 과히 편집증 수준인가.
멀티탭속에 가려져 현재 보고 있지 않은 페이지에서도 계속 로딩마크가 돌고 있음을 깨달으면 회선 낭비라는 생각도 들고, 브라우저 뒷편에서 나 몰래 뭔가 꿍꿍이를 꾸미고 있는 건 아닌가하는 의심까지 들 정도니 좀 심하다는 생각이 들긴 한다.
나랑 같은 생각을 하는 사람이 있긴 한가? 그냥 혼자만의 편집증일 수도.
2007년 1월 18일 목요일
FTA와 IT
오늘 FTA 지재권 관련 기사를 보고 생각나서 포스팅.
한미 FTA 체결 이후 IT 업계의 변화...
1. 일방적 구제절차
A: B 회사는 우리가 개발한 암호화 알고리즘 라이브러리를 몰래 도용해서 쓰고 있음에 틀림없습니다. 일방적 구제절차를 실시하겠습니다!
B: 아니, 우리가 쓰는 라이브러리는 우리가 10년동안 연구개발해서 만든 것임으로..
A: 닥쳐! 아무리봐도 너희는 우리 라이브러리를 쓰고 있음에 틀림없어. 그러니 조사가 끝날 때까지 서비스를 중단하고 증거를 찾기 위해 서버를 압수하겠다!
B: 아니, 이건 코드만 까봐도 알 수 있다니까... 우리가 만들었다는 것을 증명할 수 있는 서류가 여기...
A: 시꺼! 니들은 변명할 방법이나 기회가 없다. 모든 것은 특허권을 가진 우리 맘대로다!
...
A: 미안, 아니었네.
B: ... T_T
2. 친고죄 폐지
A: 아니, B가 제 소스를 가져다 쓴 건 사실이긴 한데요, 저는 괜찮다니까요. 별로 대단한 것도 아니고, 그냥 B가 써도 되는데요.. 아니, 저는 괜찮다는데 왜 B를 구속하세요? 저는 진짜 괜찮다니까요...
3. 법정손해배상제도/부가적손해배상제도
법원:이로써, B가 A의 저작권을 침해했음이 입증되었습니다. 그러므로 피해보상을...
B: 흑흑.. 죄송합니다. 하지만 진짜 저희 이 소스 카피해서 쓴 거 수익을 내지 않았어요. 테스트용으로만 쓴거라서...
A: 그건 상관없지요. 어쨌거나 유사한 케이스의 판례에서 이미 백만달러의 배상금 판례가 있고, 저희 회사의 정신적 피해보상비 삼백만 달러를 추가하여 총 사백만달러의 배상금을 청구합니다.
4. 저작권 보호기간 연장
A: 여기에 '미키마우스' 그림만 들어가면 우리 애니메이션 정보 서비스에 딱인데 말이야.
B: 그거 저작권 아직 20년 더 남았구요. 20년 후에는 또 연장하겠죠.
5. 일시적 복제 권리
A: B씨, 엊그저께 우리 사이트에 들어왔었지?
B: 아, 클릭실수로 그만... 근데 무슨 문제라도?
A: 당신을 일시적 복제권 위반 혐의로 기소하겠소.
B: ?!?!?!?!
A: 훗, 시치미 떼시긴. 당신 PC에 보면 temp디렉토리에 우리 사이트의 내용이 캐싱되어 있다고! 엄연한 저작권 위반이야!!
6. 기술적 보호조치
A: 금번 저희 회사가 만든 포토 앨범 서비스는 디지털 카메라에서 사용자가 촬영한 RAW 파일을 읽어들여 최상의 화질과 색감을 유지하도록...
B: Stop! 우리 회사의 RAW 포맷을 해석하는 것은 기술적 보호조치를 위반한 사례입니다! 소송을 걸겠습니다!
6-1. 기술적 보호조치 2
A: 일본 출장길에 새로 애니메이션 DVD를 샀는데 말이야, 이거 국내에서 보려면 어떻게 해야 해?
B: 안되죠. 코드프리가 불법으로 바뀌었거든요.
A: 왜 내 돈 주고 산 DVD를 내가 보는게 불법이야???
7. 온라인 서비스 책임제한
A: ?? 왜 제가 쓴 글이 삭제되었죠?
포털: 저작권 침해 신고가 들어와서입니다.
A: 그럴리가요? 누가 그래요?
포털: 모르죠. 저희는 일단 신고 들어오면 무조건 삭제합니다.
A: 저한테 먼저 알리고 그래야 하는 것 아닌가요? 그리고 신고한 측이 진짜 저작권자인지도 확인하고 그래야 하지 않나요?
포털: 통지의무없습니다. 즉시 삭제 안하면 저희가 고소당하거든요. 그리고 예전에는 진짜 저작권자인지 입증을 해야했습니다만, FTA 체결이후에는 딱히 그러지 않아도 되니까요. 참, 그쪽에서 고소한다고 고객님의 신상정보를 요구해서 보내드렸으니 소송대처 준비하세요.
암담한걸... -_-a
2007년 1월 17일 수요일
평판과 신뢰
정보의 과다는 정보의 빈곤만큼이나 '원하는 정보'의 획득에 방해가 된다.
과다한 정보 중에서 자신이 원하는 정보를 정확히 얻기 위해서는('찾기 위해서... 가 아님' ^_^), 정보에 대한 필터링이 우선되어야 하는데, 현재로서는, Profiling과 Reputation이 그나마 어느정도 구현되어 있는 방법이라 할 수 있다.
'개인 맞춤'이라고도 부를 수 있는 Profiling의 단점은, 필터가 세밀해질 수록 필터를 통과하는 정보의 양이 줄어들고, 자신의 프로파일링을 정확히 하기 힘들며, 정보가 해당 필터에 걸리게 하기 위해서는 컨텍스트 마이닝 기술이 필요한데 이것이 아직 쉬이 구현되기 어렵다는 점.
해서 요즘에는 Reputation - 이른바 '평판'에 기반한 가치분석법, 소위 '집단지성'이라는 시스템이 인기이다.
문제는, Reputation이 정보에 대한 질을 담보하기는 어렵다는 점. 모집단이 커지고 모집단의 수준이 평준화될 수록 특정 정보에 대한 가치가 낮아지게 된다. 즉, 모집단이 커질 수록 Reputation은 그 가치를 상실하게 된다.
모집단이 커질 수록, 취급하는 정보의 양이 많아지고, 그 많아진 정보 중에 '자신이 원하는 정보' - '모두가 원하는 정보'말고 - 를 찾는 것은, 또 다른 정보의 바다 속에서 헤엄치는 일인 셈이다.
Reputation이 높은 정보를 선택하면 되지 않겠냐고?
표준분포에 가까워질 수록, Reputation이 높은 정보란, 더 노출되기 쉽고, 더 많은 사람에게 그럭저럭 통용되는 수준이 되기 쉽다. 즉, 그것이 '내가 콕찝어 원하는 정보'일 가능성은 더 멀어지게 된다.
allblog나, digg 등이 점점 덩치가 커지면서 메인에 노출되는 정보들이 예전보다 '나'의 관심을 끌지 못하는 경험은 이상한 것이 아니다.
그렇다면 모집단을 적정 크기로 유지하거나, 혹은 정보의 표준분포를 '나'에게 맞게 인위적으로 이동시키는 방법은 어떨까?
이를 보완하기 위해 취할 수 있는 방법 중에 '신뢰' 시스템이 있다.
우선, 모집단을 '내가 선택한 소스'로 한정지을 수 있다. 그러니까, '뇌이버 지식즐'보다는 'TodaysPPC'에 가서 물어보는 쪽이 더 정확히 PDA에 대해 내가 원하는 정보를 얻을 수 있다는 뜻이다. TodaysPPC에 대한 나의 선택은 '이곳이 나에게 더 유용하다'라는 '신뢰' - Reliability에 기반한다.
또다른 신뢰시스템의 구현은 '가중치'로 표현할 수 있다. 예를 들어 '영화 디파티드'에 남들이 준 별점 네 개보다, 내 친구의 별점 두 개가 나한테 더 의미있다. 나는 그 친구와 같이 영화를 봐야하기 때문에. (혹은, 그 친구와 나의 영화취향은 비슷하기 때문에.)
물론 그 외에도 Reliability를 구현할 방법들은 많겠고...
Reliability를 구현하기 위한 선행조건이 있는데, 그것은 신뢰대상에 대해 나의 '개인적인 경험'이 기반되어야 한다는 것이다. 그 경험을 기반으로, 수치화하기 어려운 조건들을 신뢰대상이라는 라벨로 객체화시킬 수 있다.
즉, '내가 신뢰하는 이유를 나는 안다.(말로 표현하기는 어렵지만...)'라고나 할까?
사실 신뢰시스템은 Profiling 기법을 타인에게 위임하는 것과 마찬가지이다. '내가 무엇을 원하는지'에 대해 정확히 profiling하는 것이 어렵고, 또 기계가 그 profile과 context를 일치시키는 것이 어려운 상황에서, 그 과정을 '신뢰할 수 있는 타인'에게 맡기는 방법이라고 설명할 수도 있을 것이다.
이 시스템의 구현에 문제가 있다면, '신뢰할 수 있는 타인'을 어떻게 '내 경험'에서 뽑아내어 구체화시킬 수 있을까라는 점. 나아가서는 그 과정에 '나 자신의 왜곡된 의도'를 차단할 수 있는가 하는 점. (개인은 의식적/무의식적으로 자신의 의도가 행위에 노출되기 마련이다. '신뢰'는 '호/불호의 감성의 문제'가 아니라 객관적으로 계량화할 수 있는 기준이어야 한다.)
궁극적으로, '신뢰할 수 있는 기계'가 그 역할을 대신하겠지만, 그때까지는 '신뢰할 수 있는 타인'이 '생판 모르는 누군가'라든가 '나 자신도 모르는 나'보다는 나을 것이다.
2007년 1월 12일 금요일
시맨틱웹과 웹표준
* SWEETIER님의 말씀도 있고 해서 겸사겸사 예전에 쓰다가 쳐박아두었던 글을 다시 꺼내 먼지를 털어봅니다.
저같은 경우, 웹표준에 대해 이야기하는 이유는, "필요에 의해"라고 할 수 있겠습니다. 그러니까, 솔직하게 까놓고 말하자면 "장애인 등의 사회적 약자를 위해..." 라든가, "평등한 정보의 이용...", "비용 절감..." 같은 거창한 이유는 아니라는 거지요. 물론, 강연이나 교육을 나가면 저런 이유를 전면에 내세우긴 합니다만.
사실, 그래요. 남한테 종용할 이유가 없는 거에요. 웹표준의 여러 이점들, 그거 남들은 모르고 아는 사람들만 아는 채로 지나가도 상관없는 거에요. 오히려 남들이 모르고 우리만 알면 더 좋지요.
남들 밤새 야근하고 삽질하면서도 불편한 줄 조차 모를 때, 우리는 시간과 비용 절감하고 더 편하게 작업하면 우리 몸값도 올라가고 더 좋은 일이지요. 뭐라고 남한테 욕들어가며 그거 전도하고 다니고 싶겠어요. 천국은 우리만 가면 되는건데요. ^^;
그럼에도 불구하고 다른 이들에게 표준을 준수하라고 떠들고 다니는 이유는...
남들이 만든 사이트가 엉망이라서 정작 내가 써야할 때 불편하기 때문입니다.
간단한(?) 예를 들어볼까요.
RSS 리더기(웹 리더기 말구요...)나 요즘의 똑똑한 브라우저들은 사이트에 접속하면 알아서 이 사이트의 RSS를 추가할거냐고 물어봅니다. 그러니까, 귀찮게 "페이지내에서 RSS딱지 찾아서 오른쪽 클릭해서 주소복사해서 내 RSS 리더기에 새 RSS 추가선택해서 복사한 거 붙여넣"을 필요가 없는거지요.
이게 가능한 이유는 HTML문서의 head안에 들어있는 link 정보에 RSS주소가 포함되어 있기 때문이지요.
RSS딱지를 어디에 어떻게 이쁘게 붙일까를 고민하는 것 보다, head에 link 한 줄 추가해주는 게 사용자에게는 더 편리함을 주는 거에요.
트랙백의 경우도 마찬가지지요. Trackback RDF가 포함된 문서는 굳이 trackback 주소를 찾아서 복사해 붙이는 번거로운 짓 대신, 문서의 URL만 적어주면 자동으로 Trackback 주소를 찾아 줄 수 있어요. 국내 블로그에는 대부분 안되는 거지만 말이지요.
FF를 쓰고, WP나 MT로 블로깅을 하다보니 당장 위 두가지 기능이 안되는 국내 블로고스피어를 돌아다니는게 여간 불편한 게 아니지요.
위의 두가지 예 모두 시맨틱웹을 위한 온톨로지가 적용된 케이스라고 할 수 있어요.
시맨틱웹이 별게 아니에요. 사용자에게 좀 더 편리한 컴퓨팅을 하게 해주려는게 시맨틱웹의 궁극적 목적이잖아요. 무슨 미사여구를 붙이던 간에, 결국 목적은, 나 손하나 까딱 안하고 편하게 살고 싶다는 거지요.
다음같은 시나리오를 생각해보세요.
오랜만에 친구의 블로그에 방문했더니, 이 친구가 결혼한다고 청첩장을 올렸더라구요. 꼭 가야지 생각하면서 여러분은 어떻게 하시나요?
옛날같으면, 일단 이 페이지를 프린터로 출력하든가...
(그런데 꼭 출력한 인쇄물을 어디다 쳐박았는지 까먹곤 하지요.)
책상을 뒤적여서 포스트잇과 펜을 찾아 열심히 적어서 모니터에 붙여놓죠.
(여기 붙어 있던 포스트잇 누가 치웠어??)
조금 꼼꼼한 사람이라면 프랭클린 플래너를 열어 해당 날짜에 자세한 사항을 기록해두기도 하구요.
(그런데 움베르토 에코의 말처럼 해당하는 날짜에 다이어리를 펼쳐서 약속을 확인해봐야 한다는 걸 까먹으면 어떡하지요?)
나름 컴퓨터와 친하다는 사람은 아웃룩을 열고 일정에 자세한 내용을 타이핑하지요.
(oops! 오타! 18일을 28일로 잘못 쳤네!!)
만약 친구가 시맨틱웹을 지향하는 마이크로포맷 사용자라면, 자신의 결혼 청첩장을 hCalendar 형식으로 만들어 올렸을 겁니다. 자신의 결혼 후 바뀌는 주소는 hCard 형식으로 올렸을 테구요.
그럼 내가 할 일은 브라우저의 버튼 하나를 누르는 것 뿐. 그러면 자동으로 내 일정관리 프로그램에 결혼일정이 추가되고, 내 주소록에 친구의 주소가 신혼집 주소로 변경되지요.
별로 먼 훗날의 상상도 아닙니다. 당장 Windows Vista에 포함되는 기능이고, FireFox같은 브라우저의 확장플러그인으로 이미 있는 기능이지요.
그러니까, 저는 이렇게 게으르게 살고 싶은 거에요. 헌데 게으르게 살기에는 환경이 너무 안받쳐주니까 몸이 다는 거지요. 시맨틱웹은 감히 바라지도 못한 채 그 최소조건인 웹표준부터 이야기하고 있는 이유입니다. 말하자면, 내 한 몸 편하자고, 다른 이들에게 표준을 지키라고 떠드는 것인 셈이지요. ^_^
2007년 1월 11일 목요일
OpenID 프로토콜 시나리오
Role
SiteA : openID를 지원하는 Consumer 서비스. openID 소유자에게 서비스 이용을 허용한다.
SiteB : openID를 제공하는 Provider 서비스. 회원에게 openID를 발급하고 인증해준다.
홍길동 : SiteB에서 발급한 openID를 소지하고 있는 개인. 이 openID를 URLX에 적어두었다. SiteA의 서비스를 이용하고자 한다.
URLX : 홍길동의 개인(블로그 등) 페이지. openID가 적혀있다.
1. 홍길동은 SiteA에 방문한 후, openID를 지원함을 알고, 입력 Form에 자신의 openID URL인 URLX를 입력한다.
2. SiteA는 주어진 URLX에서 openID 정보를 찾는다.
3. SiteA는 홍길동의 openID가 SiteB의 것임을 알고, SiteB에 openID 인증을 요청한다.(SiteB로 리다이렉팅)
3-1. SiteB와의 연결에 문제가 발생할 경우, 해당 에러를 띄워 홍길동이 문제를 해결할 수 있도록 한다.
4. SiteB는 홍길동의 브라우저에, SiteA로부터의 인증요청이 있음을 알리는 페이지를 띄우고 인증허가여부를 묻는다.
4-1. SiteB는 홍길동이 본인임을 확인하기 위해 또다른 인증(예:로그인, 비밀번호입력)을 요구할 수 있다.
5. 홍길동은 SiteB로 하여금 SiteA에 자신의 정보를 가져가도록 허가한다.
5-1. 또는 홍길동은 SiteB로 하여금 SiteA로의 정보제공을 거부할 수도 있다. (부적절한 요청, 도용 가능성 등)
5-2. 또는 홍길동은 SiteB로 하여금 SiteA로의 정보를 제한적으로 제공하도록 선택할 수도 있다.
6. SiteB는 SiteA에 홍길동의 정보를 제공하고, SiteA의 페이지로 리다이렉팅한다.
6-1. 또는 SiteB는 SiteA에 홍길동의 정보를 제공할 수 없음을 알리고 SiteA의 페이지로 리다이렉팅한다.
7. SiteA는 SiteB로부터 받은 정보를 바탕으로 홍길동이 서비스를 사용할 수 있도록 처리해준다.
----
시나리오로 적으면 별 것도 아닌 것 같은데, 왜 이리 에러가 많은거야.. 징징.
블로그 방문자를 위한 UX
가정 1.
내 블로그를 방문하는 사람은 '나'에 대해 관심있기 때문이다.
가정 2.
'나'에게 좋은 것은, 내 블로그를 방문하는 사람에게도 좋다.
두가지 가정은 모두 사실이 아니다.
블로그 주인에게 블로그란, '자신'에 대한 표현수단이겠지만, 블로그를 방문하는 사람은 사실, 블로거 자체에는 관심이 없다.
그들이 관심있는 것은 Topic일뿐.
블로그 방문자들이 방문한 블로그의 모든 글을 읽기를 기대할 수도 없다. 애초에, 블로그란 형식 자체가 post단위의 archiving/logging이기 때문에, archive(또는 post)는 그 자체로 자기완결되어야만 한다.(물론 어려운 일이다.)
대개의 방문자는 링크를 타고 들어와 그 하나의 포스트를 읽고, 나가버린다. 아주 가끔, 댓글을 단다거나 하는 예외를 제외하곤.
그렇다면 방문자들을 위해 가장 필요한 인터페이스는 무엇일까?
두가지 층위에서 바라볼 수 있는데, inbound entry와 outbound exit 층위가 그것. 들어오는 방문자와, 나가는 방문자를 위한 인터페이스.
'블로그 내 검색'은 방문자를 가장 손쉽게 유혹할 수 있는 인터페이스라 할 수 있다. 방문자들은 카테고리 메뉴를 애용하지 않는다. 일일이 카테고리를 찍어보고, 포스트 목록에서 자신이 관심있어할 글 제목을 찾는 것은 매우 귀찮은 일이기 때문이다. 만약 방문자가 이 블로그에서 무언가 정보를 더 얻기를 원한다면 검색창에 바로 쳐넣고 결과가 뜨기를 기다릴 것이다.
따라서 블로그의 검색기능은 방문자를 위한 가장 훌륭한 인터페이스이다.
'관련글' - 수동으로 만들었거나, 혹은 FullText Search를 통한 자동 연결이거나 - 을 제공하는 것도 좋다. '연예뉴스'를 보러 들어온 방문자에게 관련된 다른 글들을 보여주는 것은 방문자들이 수고스럽게 일일이 뒤져보거나 검색할 필요를 줄여주는 친절한 인터페이스라 할 수 있다.
한가지 더 추가한다면,
referer를 통해, 검색엔진으로부터 유입된 방문자에게 자신이 보려고 했던 컨텐트를 바로 보여주는 것이다. 어떤 방문자가 검색엔진으로부터 'Ajax'라는 키워드를 찾아 블로그로 유입되었다면, 그는 아마도 내 블로그의 다른 'Ajax'관련 글에도 관심이 있을 것이다. 어쩌면, 검색엔진에 노출된 페이지보다, 숨겨진 페이지 쪽에 더 유용한 정보가 있을 수도 있다. 그런 경우 검색엔진으로부터 들어온 사용자에게 해당 엔트리들을 자동으로 보여준다면 얼마나 유용할까. (물론 이러한 기능들은 이미 많은 곳에서 구현되어 있고, 예를 들어 방금 말한 기능같은 것은 wp 플러그인으로 있어서 내 블로그에도 붙여놓았다. google에서 '불친절한 금자씨'로 검색해보시라.)
현재까지 블로그 인터페이스는 블로그 주인을 위한 자기만족적 성격이 강하다. 그러나 방문자로서는 스킨이 드래그 앤 드롭으로 변경되든, BGM이 있든 말든, 주인장 맘대로 태그로 뭘 붙이든 신경쓰지 않는다. (방문자 맘대로 리모콘 조작이 가능하다면야 또 모를까.) 그런 블로그 주인의 자기만족적 인터페이스보다는, 방문자를 위한 배려가 더 좋은 인터페이스일텐데, 이런 것들이 아직도 많이 미비한 듯 하여 아쉽다. (심지어 내 블로그 조차도.)
2007년 1월 7일 일요일
광고와 AJAX
Ajax가 유행이 되면서 너나 없이 Ajax를 이용한 사이트를 제작하게 된다. 그런데 곰곰히 생각해보면 Ajax의 이용은 현재까지 웹비즈니스모델의 가장 큰 부분을 차지하는 광고시장에 많은 영향을 주게 됨을 알 수 있다.
1. 광고 노출의 약화
특히 Ajax로 메인 컨텐트 부분을 처리하는 사이트들의 경우, page reloading이 일어나지 않기 때문에 reload 처리를 고려하지 않은 광고기법을 사용한다면 유저당 광고노출회수가 줄게 된다.
가령, 이전에는 사용자가 평균 10페이지의 액션을 취하고, 각 페이지마다 2개씩의 광고가 붙어 있던 사이트라면, 사용자당 20개의 광고를 노출시킬 수 있었다.
그러나 Ajax로 메인 컨텐트를 처리하면서 page reloading이 일어나지 않게 사이트를 변경하고 나면, 한 명의 사용자에게 고작 2개의 광고만 노출시킬 수 있을 뿐이다.
2. 광고 overloading - 트래픽 낭비
위와 같은 문제를 해결하기 위해 사용자의 Ajax 액션 때마다 광고를 같이 갱신하려한다면 이번에는 기껏 Ajax로 절약(?)한 트래픽을 낭비하게 된다. 액션 때마다 광고까지 포함해 전체페이지를 뒤엎는다면 Ajax를 쓸 필요가 없지 않은가.
3. 광고 changing - 트래픽 낭비
사용자의 액션과는 상관없이 일정주기로 광고를 갱신하는 방법을 쓸 수도 있다. 그러나 이 경우에도 사용자가 실제로 현재 페이지를 보고 있지 않는 동안에도 광고가 갱신되는 트래픽 낭비를 일으키며, 광고주에게 그 비용을 전가하는 단점이 있다.
너무 늦게 갱신된다면 Ajax를 쓰기 전보다 광고효과가 떨어지고, 너무 자주 갱신된다면 광고주에게 광고노출비용을 효과보다 더 부담하게 만든다.
4. PV와 UV, CV
무엇보다도, PV가 무색해지면서 광고단가에 대한 산정이 어려워지는 문제가 발생한다. UV가 아무리 많다해도 광고주들은 PV가 높은 매체를 선호하고, 광고 단가를 높게 지불한다.
그런데 Ajax를 사용하게 되면 사용자가 10분간 열심히 충성스럽게 사용한다 해도 해당 사용자의 PV는 1일 뿐이다. Ajax 서버측에 기록된 로그를 공개하면 사용자의 액션을 객관적으로(?) 증명할 수도 있겠지만, 광고주들이 매체의 공개된 로그를 신뢰할리 만무. 결국 컨텐트마다 추적코드를 삽입해서 ContentView를 측정하는 방법뿐인데, 이에 대해 신뢰할 수 있는 분석도구나 어필레이트 프로그램은 현재 없다. 서로 다른 형태와 위상을 가지고 있는 Content의 정량적 측정자체가 불가능하므로.
결국 광고서버에서 직접 노출횟수를 세는 방법뿐인데, 이를 위해 Ajax로딩때마다 광고를 갱신해야하면 다시 2번째 문제점으로 돌아갈 뿐.
5. 문맥광고 빠져나가기
현재까지는 가장 진보된 형태라고 불리우는 AdSense등의 문맥광고는 호출 당시의 HTML 컨텐트만을 문맥파악 대상으로 할 뿐, Ajax로 변경된 컨텐트는 인지하지 못한다.
컨텍스트와 일치하는 광고를 뽑아주는 것을 장점으로 하는 문맥광고가 그 역할을 하지 못한다면 과연 광고효과가 있을까?
이를 해결하기 위해서는 문맥광고에 컨텍스트 변경이 있을 때마다 push방식의 재갱신 요청을 처리하는 부분이 추가되거나(웹에서 push는 구현이 쉽지 않다.) 혹은, 문맥광고 자체에서 일정시간마다 pull방식으로 컨텍스트를 다시 읽어와 광고갱신여부를 선택하는 방법이 있을 수 있겠다. 그렇다고는 해도 이는 google등에서 해결해야할 문제이며, 매체측에서는 손가락만 빨고 있을 뿐.
...
개발자들이야 Ajax를 쓰는 것을 마다할 리 없고, 기획자들이야 왠지 좋아보여서라도 Ajax를 붙이겠지만...
사이트의 영업담당자들은 Ajax로 인해 변한 광고시장에 머리 좀 아플 듯.
근데, 이런 이야기를 회의때 안하나??
2007년 1월 5일 금요일
재미있는 현상들
조금 의외인 것은, 블로고스피어에 네이버의 이번 시즌 2 에피소드 1에 대한 칭찬들이 자자하다는 것.
이미 알고 있겠지만, 이 리모콘이란 용어와 기능은 사실상 1년도 전에 엠파스 블로그에서 써먹었던 것이고, 네이버에서 에피소드 1이라는 이름으로 내놓으면서 엠파스의 그것보다 기술적으로 특별히 진보적이거나 개념적으로 뭔가 더 창의적인 부분이 생긴 것도 아니다.
'따라했다'는 것 자체가 비난의 대상이 될 이유는 없겠지만, 그렇다고 '칭찬'의 이유가 된다는 것은 뭔가 이상하지 않은가?
남은 에피소드들 역시 모두 이미 다른 곳에서 했던 그대로 - 벤치마킹을 넘어서 사실상 표절이라고 표현해도 무방할 정도인데 왜 이렇게 다들 갑자기 호의적이 된 것일까?
역시 포장하는 법과 홍보하는 법이 한국IT 비즈니스의 핵심 역량이 되는 걸까?
거창한 수사를 붙이면 단지 인턴을 뽑을 뿐인데도 엄청난 경쟁률을 보이는 회사가 있는 한편, 쓸만한 인재하나 뽑기가 어려운 회사도 있고...
적절한 명예심과 자존심을 간질여주며 저렴한 가격으로 개발자풀을 돌리는 회사도 있고...
컨퍼런스나 세미나에 참석해서 말만으로 때우는 회사도 있고...
괜찮은 홍보이사를 잡는 쪽이 괜찮은 개발이사를 잡는 쪽보다 성공가능성이 더 높아지는 요즘. 재밌는걸?
2007년 1월 4일 목요일
표준을 간과한 댓가
"표준"이 강제력이 있는 것은 절대 아니지만, 표준을 지키는 것과 비켜가는 것은 시작은 비슷해도 종래에는 제법 그 사이가 벌어지게 됩니다. 표준이 표준인 이유는, 그게 더 많은 사람이 사용해서도 아니고, 더 편하기 때문도 아니지요. 표준이 표준인 이유는 "당위성"과 "보편성"에 있다고 봐야합니다. 즉, 표준인 이유는 "누가 해도 옳게 할 수 있기 때문에"라는 것이지요. (비표준이 틀렸다는 것은 아니고...)
표준을 지키는 것이 더 불편하거나 귀찮더라도 종국에는 더 이득입니다. 비록 초기에는 비표준쪽이 더 이익인 것처럼 보이긴 해도 말이지요.
사례 1: 올블로그의 태그 수집
RSS의 content:encoded는 기본이 아닙니다. 또한 description은 entity처리된 plain text만 사용하도록 되어있지요. 이것을 무시하고, RSS에서 tag정보를 강제로 넣기 위해 a 태그를 이용하려다 보니, content:encoded를 조장(?)하거나, description에 entity처리되지 않은 a 태그를 포함하도록 유도하는 경우가 있습니다.
애초에, notifying 이라는 RSS의 속성을 생각한다면, 컨텐트 안의 tag 정보가 필요하다면, 갱신된 RSS의 item의 url정보를 참조하여 웹페이지를 크롤링해서 필요한 정보(여기에서는 tag)를 다시 가져오는 것이 맞습니다. tag뿐만이 아니죠. image나 멀티미디어의 경우에도 마찬가지. 그런 정보를 모으기 위해 RSS에 해당데이터를 추가하게 하는 것이 아니라, RSS는 표준대로 두고 봇이 해당 웹페이지에 정보를 수집하러 다녀오는 것이 맞습니다.
사실, 이건 올블의 잘못이 아니죠. RSS를 이상한 형태로 제공하고 있는 많은 블로그 메이커들이 문제의 시발점이긴 합니다. 그러나 비표준적인 스펙에 의존하는 서비스는, 예외를 위한 예외를 처리하다보면 점점 더 표준에서 멀어지게 되지요.
사례 2: TT의 태그 출력
애초에 tag플러그인이나 스킨 제작자들의 문제였겠습니다만. 최소한 tag라는 표현을 쓰고 상식적인(아, 그냥 우리끼리의 '상식'은 말구요.) 용법을 사용하려면 microformat의 tag 용법 정도는 준수했어야했을 것입니다.
물론, 다중카테고리와 tag자체를 구별할 수 없는 현재의 용도하에서 TT쪽에서 스킨제작자나 플러그인 제작자에게 표준을 강제하는 것은 어려운 일이었겠습니다만... 어쨌거나 이 역시 microformat - tag라는 표준을 간과한 결과겠지요.
덕분에, tag라는 이름을 붙인 기능을 쓰면서도 실질적으로 tag가 아닐 뿐더러, 그 문제점을 스킨이나 플러그인 제작자에게 떠넘긴 셈이 되었습니다. 애초에 스킨이나 플러그인 제작자보다 메이커가 더 이런 문제에 대해 잘 알고 책임을 져야할텐데, 너무 자유도를 강조한 나머지 메이커보다 문외한일 3rd party들에게 맡기는 것은 조금 안일하지 않나 싶습니다. MT나 WP처럼 아예 tag는 원래기능에는 포함되지 않음을 확실히 했어야했지요. 현재 tag는 TT에서는 책임지지 않으면서도 TT의 핵심기능 중의 하나인 셈이니 이러한 부분에서 문제가 발생하면 책임소재가 애매해지겠습니다.
각각의 사례는 사실 단독적으로는 별 문제가 없었겠습니다만, 두가지 비표준 사례가 만나다보니 문제가 커지고 서로가 잘못했다는 감정싸움이 되는 듯 하더군요. 뭐랄까, 이전부터 RSS나 microformat에 관해 이야기 해왔던 입장에서 본다면 안타깝다고나 할까요.
표준이 표준이 되기 위해서는 나름 많은 고민과 많은 시행착오를 거쳐야만 합니다. 최소한 한두명의 개발자나 한두개의 기업에서 나름 뚝딱해서 만들어지는 것은 아니라는 것이지요. 표준이라는 딱지를 얻었을 때에는 그만한 이유와 까닭이 있기 때문입니다. 눈 앞의 이익에 혹해 비표준을 용인하는 것은 우선 경계해야할 일이겠습니다.
추가:바람직한 해결책
1. TT에서 사용하는 기능이, 'tag'라면 TT측에서 직접 microformat을 준수할 수 있도록 책임진다. 단, RSS에 추가할 필요는 없다.
1-1. 'tag'가 아니라 멀티카테고리에 불과하다면 지금까지 처럼 3rd party의 플러그인이나 스킨제작자에게 맡긴다.
2. 올블에서는 RSS에 담긴 내용만으로 정보를 수집하는 대신, RSS로 notifying된 url을 찾아가 screen scrapping을 통해 필요한 정보들을 획득해간다.
생각해볼 문제 :
screen scrapping은 죄악인가? 그렇지 않다.
정상적인 RSS 스펙을 해석한다면, 정확히 '새 글이 등록되거나 수정되었을 때에만' 해당 페이지의 screen scrapping을 시도하게 할 수 있다. 원래 RSS의 스펙 자체가, RSS를 컨텐트의 용도로 사용함이 아니라, URL에 대한 notifying용임을 상기하자. 따라서 해당 URL에 대한 정보가 필요하다면 필연적으로 machine-crawling이 필수이며, 이에 대한 방문빈도 등을 제어하기 위한 규격이 이미 RSS내에 존재하고 있다.
단지 봇이 긁어가는 것에 대해 알레르기를 느낀다는 것은, 글쎄, 사용자가 그리 느낀다는데 뭐라 말하기는 그렇지만 잘못된 생각일 뿐이다. 장차 사용될 마이크로포맷이니 시맨틱웹이니 하는 것들은 로봇과 스크래퍼 들을 가정하지 않으면 애초에 성립되지 않는 개념들이다. 그 때가 되면 정말 웹페이지를 샅샅이 뒤지고 긁어서 조그마한 의미 하나라도 기계들이 긁어갈 차에, 봇이 긁어가는 것이 싫어서... 라는 핑계는 러다이트의 재현일 뿐.
무분별하게 긁어가는 것은 트래픽상 문제가 될 수 있긴 하지만, 그걸 막기 위해 RSS에 해당하는 스펙이 있지 않던가. 그것만 따라줘도 충분히 트래픽에 대한 문제는 해결된다.
2007년 1월 3일 수요일
리모콘 달린 블로그
그런데, 블로그 리모콘 이란 건 엠파스에서 벌써 일년전에 내놓았던 기능 아니었나?
네이버가 대대적으로 광고하면서 내놓기에는 좀 부끄러운 것 아닌지?
지금 보니 기능도 컨셉도 엠파스 것과 완전 동일, 이정도면 같은 개발자... 또는 같은 기획자가 참여하고 있는 것이라는 의심이...
아무튼 간에. Attention의 차이가 네이버와 엠파스가 확연할 테니, 엠파스로서는 또 손가락만 빨면서 억울함을 곱씹을지도.
(그렇다 해도, SK에 인수된 엠파스가 진심으로 억울해 할지는 미지수. 별 상관없으려나?)
피드 구독하기:
글 (Atom)