01 May 10 Google Wave
Google Wave는 전형적인 hype cycle을 거치는 중인가 아니면 그냥 사장되어져버릴 기술인가. Google Web Elements는 Wave가 처음 베타 서비스할 때부터 기본 기능으로 제공되었어야 하는 것인데 이제야 이런 것이 나왔다는 점을 보면 Wave의 상품전략에는 의구심을 갖지 않을 수 없다.
01 Mar 10 윤미네 집, 개인 데이터의 보존
얼마 전 “윤미네 집”이 복간되었다. 돌아가신 우리 아버지가 20년 전에 초판을 내셨던 이 책은 누나가 태어날 때, 즉 지금으로부터 무려 46년 전 부터의 사진을 담고 있다. 생각보다 책이 잘나가서 벌써 3쇄에 들어갔다고 하는데 아마도 출판사가 홍보를 잘한 덕택이겠지만 책을 구입한 사람들이 블로그 등에 올린 글을 보면 자기 가족의 추억을 간직하는 가치를 꽤 많은 사람들이 공감하는 것 같다.
디지털 카메라가 보급된 이후로 더 많은 사람들이 사진을 찍게 되었지만 그 중에 46년 후에도 찾아 볼 수 있는 사진이 얼마나 있을까. 누구나 컴퓨터를 업그레이드하다 미처 복사하지 못한 사진, CD-R에 구워놨는데 읽히지 않는 사진, 어딘가에 있겠지만 어디 있는지 찾을 수 없는 사진들이 있을 것이다. 우리 집에는 수만장의 필름이 보관되어 있는 캐비넷이 몇 있었다. 윤미네 집에 사용되었던 필름의 대부분은 찾을 수 있었지만 복간하고자 했을 때 일부는 결국 찾을 수 없었다. 물리적 공간을 차지하는 필름도 잃어버리지 않고 보관하는 것이 힘든데 하물며 디지털 파일이야.
윤미네 집 사진의 저해상 버전은 사진 전문 웹사이트에 올려져 있으나 이 사이트가 망하거나 잊혀지지 않고 얼마나 오래 운영할지 걱정이 된다. 서버를 임대하고 사이트를 호스팅하면 호스팅 업체가 망하더라도 쉽게 다른 서버로 옮길 수 있겠으나, 그 때쯤에는 사진 게시판에 사용했던 소프트웨어가 더 이상 관리 안되고 최신 PHP나 mySQL 버전과 호환되지 않을 가능성도 많다.
NASA가 달착륙 비디오를 제대로 보관하지 못하는데 일반인들이 수십년전에 찍은 사진 파일을 스스로 제대로 보관하고 찾아볼 수 있기를 기대하기 어렵지만, 위에서 얘기한 이유들 때문에 social network이나 사진 호스팅 사이트에 업로드해두는 것도 해결책이 못된다.
우리 삶의 점점 더 많은 부분이 디지털 데이터로 기록되고 있으나 이 데이터들의 유효 수명은 더 짧아져가고 있다. 작년에 새로운 서비스를 구상하면서 이 문제의 개선을 중요한 목표로 제시하였으나 사내에서도, 제안을 받은 모 대기업에서도 이 가치를 중요하게 인식하는 사람은 별로 없었다. 윤미네 집이 3쇄에 들어가고 대형 서점의 예술 부분 베스트 셀러에 올랐다고 하지만, 어쩌면 이런 걸 중시하는 사람들은 그래봐야 소수이거나 회사의 의사 결정권을 가진 바쁜 사람들과는 다른 부류의 사람들인 모양이다.
13 Feb 10 구글 buzz의 물관리
구글은 buzz를 내놓으면서 왜 데스크탑 브라우저에서는 위치 관련 기능을 지원하지 않았을까? 편법으로 데스크탑에서도 buzz의 geolocation 기능을 사용할 수 있기는 한데 구글이 이를 지원하고자 하는 의사가 있었다면 적어도 geolocation API를 지원하거나 Gears를 설치한 브라우저에 대해 지원하는데 기술적 어려움이 없었을 것이라는 점은 분명하다.
내가 생각하는 한가지 가설은 구글이 buzz 초기 물관리를 하고 있다는 것이다. Gmail의 주소록을 활용, 조기에 일정 수준까지 활성화를 해낼 수 있겠지만 기존에 메일 주소를 아는 사람들을 follow하는 것 만으로는 SNS로서는 부족하기 때문에 다른 방식으로 인적 네트웍을 확장할 수 있어야 한다. 온라인이건 오프라인이건 간에 어떤 사람들이 초기에 모이느냐 하는 것이 초기 평판과 이후 커뮤니티의 진화 방향에 많은 영향을 미치는데 대학별 배타적 네트웍으로 출발한 Facebook이나 소수 early adopter들이 먼저 사용하기 시작한 twitter와는 달리 buzz의 경우 기존 메일 주소록을 활용한다는 점이 가장 큰 장점이지만 동시에 과연 메일 주소록의 지인들이 SNS를 통해 교류하고자 하는 사람들과 동일한 그룹인지에 대한 의문이 있다. 스마트폰 사용자에 한해 주변의 다른 스마트폰 사용자들과 연결될 수 있도록 해줌으로써 초기에 새로 형성되는 인적 네트웍의 homogeneity를 어느 정도 보장, 초기 사용자이면서 매체에 영향이 많은 사람들에게 괜찮은 서비스라는 인상을 줄 수 있는 것이다.
이 때문인지 지금까지 구글이 시도했던 다른 social 서비스에 비해 buzz는 비교적 순탄한 시작을 하고 있는 것으로 보인다. 물론 프라이버시 등 몇가지 문제가 제기되었으나 구글이 빠르게 대응하고 있어서 문제는 조기 진화되는 듯 하다. 기존 메일의 주소록과 delivery/notification 인프라를 (어쩌면 지나치게) 적극 활용하고 있는 buzz는 과연 이 서비스가 기술적 우위성을 내세워 기존 메일을 배척했던 Wave와 같은 회사에서 내놓은 것일까 싶을 정도로 Wave와 차별성을 보이지만, 또 다른 많은 면에서는 Wave와 유사한 점도 많아서 앞으로 구글이 이 두 서비스를 어떻게 진화시켜나갈 것인지 궁금하다.
20 Nov 09 Chrome OS
Chrome OS를 VirtualBox에서 돌려봤다. 방법은 여기를 참조. Gmail 등은 들어가지지만 데모에서 봤던 app directory등은 액세스되지 않는데, 아마도 허용된 account가 별도로 있는 듯 하다.
한동안 맥을 사용하다가 팔아버린 가장 큰 이유가, 90% 이상의 시간을 어차피 브라우저만 사용하기 때문이었다 (나는 하드웨어로서의 맥은 별로 좋아하지 않는다). 또 나름 만족하던 넷북을 팔아버린 이유는 사용하는 PC의 수가 늘수록 관리 부담이 늘기 때문이었다. 그런 점으로 볼 때, 모든 데이터가 클라우드에 sync되고 브라우저 사용에 최적화되어 있는 Chrome OS의 특성은 나같은 사용자에게는 그런대로 잘 맞을 것 같다.
14 Nov 09 Tolerable Wait Time
구글만큼 스피드에 집착하는 인터넷 회사도 많지 않을 것 같다. 구글의 검색도, 메일도 처음 나올 때부터 가장 큰 특징 중의 하나가 속도였지만 자사 서비스 뿐만 아니라 웹 전반의 속도를 향상시키는 것을 목적으로 많은 정보를 제공하고 있고 그걸로 모자라서 역시 빠른 속도를 가장 큰 특징으로 하는 브라우저를 직접 개발 보급하고 심지어 HTTP 프로토콜을 근본적으로 바꾸는 시도까지 하고 있다.
굴지의 인터넷 혹은 IT회사라고 해서 다들 속도를 중시하는 것은 아니다. 아마 Java applet이 launch 속도만 빨랐으면 지금 Flash의 자리를 대신 차지하고 있었을 테고 (뒤늦게 변칙적인 방법까지 시도하고 있지만…) Vista가 XP 또는 Windows 7만큼 빨랐더라면, SKT 통합 메신저가 OEM 메신저만큼 빨랐더라면, 삼성폰의 위젯 UI가 iPhone만큼 빨랐더라면 등등 느린 속도 때문에 불만을 사고 있는 제품들이 많다.
이런 제품이나 서비스들의 속도가 충분히 빠르지 않은 것을 단지 그걸 만든 엔지니어들이 구글 엔지니어만 못해서라고 판단할 수는 없다. 어떤 기능에 우선순위를 두어 언제까지 개발하고 어느 정도의 품질이 되면 출시할 것인지를 최종 결정하는 것은 실무 엔지니어가 아닌 경영층이기 때문이다.
그렇긴 하지만, 실무 개발자나 실제 사용자라고 해서 제품이나 서비스의 반응 속도를 다 똑같이 중요시하는 것은 아니다. 내가 직접 접한 엔지니어들의 경우에도 어떤 이들은 속도를 중시하지만, 더 많은 이들은 몇 초쯤 기다리는 것은 아무렇지도 않게 생각한다.
- 0.1초는 시스템이 즉각적으로 반응한다고 느낄 수 있는 시간의 한계이고
- 1초는 사용자가 비록 지연을 느끼기는 하나 사고의 흐름이 중단되지 않기 위한 한계이며
- 10초는 사용자의 주의가 다른 곳으로 가버리지 않도록 잡아둘 수 있는 한계 시간이다
하지만 0.1, 1, 10초는 대략 그렇다는 것이고 실제로는 사용자에게 적절한 피드백이 주어지는지, 웹사이트가 점진적으로라도 로딩이 되는지 등 많은 요소들에 의해 사용자가 용인할 수 있는 지연 시간 (Tolerable Wait Time)이 바뀔 수 있다. 개인차도 큰 것 같다. 내 경우엔 느린 제품이나 서비스는 무척 싫어한다. 나는 MP3 플레이어가 부팅하는 시간을 참을 수 없어서 아이팟을 사용하며, 빠른 길을 두고 느린 길로 가는 것을 참을 수 없어서 TPEG을 가장 잘 반영한다고 하는 엔나비를 사용하지만 부팅 시간이 없는 파인드라이브 제품으로 바꿀까 생각 중이다.
구글이 웹 속도를 올리기 위한 다양한 노력을 하는 것이나 특히 이번에 새로 만든 프로토콜 SPDY가 내가 예전에 만들었던 로봇과 이름이 비슷한 것을 보면 구글에도 나하고 Tolerable Wait Time이 비슷한 사람들이 많은 것 같다 (물론 나는 그래서 반응 속도가 빠른 구글의 서비스들을 많이 사용한다).
19 Oct 09 Android
애플의 iPhone과는 달리 Android가 여러 제조사의 다양한 하드웨어를 지원한다는 점에는 보는 측면에 따라 장점도 있고 단점도 있다. 그렇지만
A Chink In Android’s Armor — by Michael Arrington on October 11, 2009
But if developers are forced to create and maintain multiple versions of their apps for various devices, Android may be in trouble. The whole idea of Android is to let app developers build once and let users install on any Android device. Right now, it’s not a certainty that will happen.
Verizon Droid Is The Real Deal — by Michael Arrington on October 18, 2009
With the flood of Android devices that are hitting the market, a few are bound to be hits. No wonder Google CEO Eric Schmidt is so bullish on Android right now. Things are about to get very, very interesting.
물론 첫번째 글은 Android의 app 개발이 쉽지 않다는 것이 주제이고 두번째 얘기는 VZW망과 모토로라 폰 H/W의 at&t/iPhone 대비 상대적 경쟁력이 주제이기는 하나 일주일만에 같은 저자가 결론적으로 Android가 잘 안될 것 같다고 했다고 잘 될 수 밖에 없다고 하다니.
다양한 하드웨어를 지원한다고 해서 반드시 성공하거나 실패하는 것은 아니다. 같은 Microsoft에서 다양한 하드웨어를 지원하는 소프트웨어 플랫폼으로써 추진한 Windows는 대성공했고 Windows Mobile은 그럭저럭, PlaysForSure는 사실상 실패했다. 이의 원인에 대해 포터블 기기의 하드웨어의 다양성, Office와 같은 킬러앱의 부재 또는 단순한 운 등 여러가지로 설명할 수 있겠지만 아뭏튼 이통사라는 또 하나의 변수와 Google의 역량 vs 오만함, 오픈 소스의 장단점 등은Android의 성공 여부를 예측하기 어렵게 한다. 단지 확실한 것은 올해 말부터 내년까지 여러 제조사에서 수많은 Android 디바이스가 출시될 것으로 예정되어 있다는 점. Arrington의 글 중에서 가장 동의할 수 있는 점은, 특히 우리나라의 경우 iPhone의 출시와 WiFi의 일반폰으로의 도입, 데이터 정액제의 활성화 등과 맞물려 “Things are about to get very, very interesting.”.
13 Aug 09 2009 Hype Cycle
From Gartner through ReadWriteWeb.
06 Sep 08 Picasaweb의 얼굴 인식
Picasa 3.0 beta의 발표와 함께 Picasaweb도 개편되었다. 가장 눈에 띄는 기능은 얼굴 인식. 시험해보니 물론 완벽하진 않지만 생각보다 잘된다 (아직 co.kr 서버에는 이 기능이 없고, picasaweb.com 으로 가서 설정에서 기능을 활성화시켜야 함). 특히 애기 얼굴은 개월수에 따라 꽤 달라지는데도 잘 인식한다. 이름 태깅은 gmail의 주소록과도 연계되어 있고 주소록에 없더라도 e-mail 주소를 입력할 수 있도록 되어 있어서 flickr와 비교할 때 부족했던 social networking 기능을 강화하려는 의도를 엿볼 수 있다.
02 Sep 08 Google Chrome, BrowserWars Episode 2
Google이 자체 브라우저를 만든다는 루머는 꽤 오래 전부터 있었지만, 이제 출시가 임박한 모양이다. 특징은 webkit에 기반한 오픈소스 브라우저이면서 각 탭과 플러그인을 프로세스로 분리하여 안정성과 보안 강화, 새로운 고성능 JavaScript 엔진, 웹기반 app에 최적화된 UI, 보안 강화, Google Gears 내장 등.
23 May 08 “고객님의 휴면계좌 현황을 알려드립니다”
한 은행으로부터 “고객님의 휴면계좌 현황을 알려드립니다”라는 메일을 받았다. 그런데 그 메일을 열어보려 하니 firefox에서는 안되고 또 뭔가 보안솔루션을 설치해야 한다고 한다. 그래도 은행 사이트에서 로그인하는 것보다는 덜 귀찮으려니 생각하고 IE로 열어보려 하니, ActiveX가 뭔 프로그램을 시스템 디렉토리에 설치까지 하느라 숱한 보안 경고가 떠서 결국 보안을 한동안 해제할 수 밖에 없었다. 그런데 그렇게 힘들게 열어본 메일의 내용에는 정작 내 휴면계좌에 대한 내용은 전혀 없고 “1년 이상 거래가 없는 통장이 있으니 지점을 방문해달라. 계좌번호는 정보 보호를 위해 전화로도 알려줄 수 없다”는 것이 다였다.
메일이나 전화로 정보를 알려줄 수 없는 것은 법률이건 다른 이유 때문에 그럴 수 있으리라 생각한다. 하지만 기껏 그런 계좌가 있다는 사실을, 그것도 이미 메일 제목에서 다 드러났는데 나머지 일반적인 안내를 굳이 보안 솔루션으로 암호화해서 보내야 하나? ActiveX에 의존하는 소위 “보안 솔루션”이 오히려 온라인 보안을 해치고 있다는 얘기는 지난 번에 했지만, 보안이 필요하지도 않은데 이렇게 쓸데없이 ActiveX를 남발하거나 주민등록번호를 온갖 곳에 입력해야 하는 경우가 점점 더 늘고 있다.
일차적인 책임은 내용을 잘 알지도 못하면서 아마도 몇 몇 보안 솔루션 업체의 로비에 넘어가서 쓸데없는 규정과 정책을 남발하는 당국에 있을 것이고, 그 다음으론 굳이 필요하지도 않은 부분까지 이런 기술을 생각없이 적용하는 은행등의 IT 부서(또는 누가되었건 보안 솔루션 적용을 결정하고 지시한 사람)에게 책임이 있을테고, 마지막으로 자사 이익만을 위해 인터넷 전체의 건전성에 대한 고민 없이 이런 “솔루션”을 하나라도 더 팔기 위해 노력하는 회사들에게 책임이 있을 것이다. 정부, 은행, 솔루션사 모두 결정권자는 아마도 기술은 제대로 모르고 자기 실적이나 책임 회피만을 생각하는 사람들이겠지만 이들이 결합하면 그 영향력은 마이크로소프트도 못 당할만큼 강하다 (Vista가 아직도 어려움을 겪는 것을 보라). 그 밑에서들 일하는, 내용을 제대로 아는, 기술자들은 제발 좀 목소리를 내 줬으면 좋겠다.
