얼마 전 “윤미네 집”이 복간되었다. 돌아가신 우리 아버지가 20년 전에 초판을 내셨던 이 책은 누나가 태어날 때, 즉 지금으로부터 무려 46년 전 부터의 사진을 담고 있다. 생각보다 책이 잘나가서 벌써 3쇄에 들어갔다고 하는데 아마도 출판사가 홍보를 잘한 덕택이겠지만 책을 구입한 사람들이 블로그 등에 올린 글을 보면 자기 가족의 추억을 간직하는 가치를 꽤 많은 사람들이 공감하는 것 같다.
디지털 카메라가 보급된 이후로 더 많은 사람들이 사진을 찍게 되었지만 그 중에 46년 후에도 찾아 볼 수 있는 사진이 얼마나 있을까. 누구나 컴퓨터를 업그레이드하다 미처 복사하지 못한 사진, CD-R에 구워놨는데 읽히지 않는 사진, 어딘가에 있겠지만 어디 있는지 찾을 수 없는 사진들이 있을 것이다. 우리 집에는 수만장의 필름이 보관되어 있는 캐비넷이 몇 있었다. 윤미네 집에 사용되었던 필름의 대부분은 찾을 수 있었지만 복간하고자 했을 때 일부는 결국 찾을 수 없었다. 물리적 공간을 차지하는 필름도 잃어버리지 않고 보관하는 것이 힘든데 하물며 디지털 파일이야.
윤미네 집 사진의 저해상 버전은 사진 전문 웹사이트에 올려져 있으나 이 사이트가 망하거나 잊혀지지 않고 얼마나 오래 운영할지 걱정이 된다. 서버를 임대하고 사이트를 호스팅하면 호스팅 업체가 망하더라도 쉽게 다른 서버로 옮길 수 있겠으나, 그 때쯤에는 사진 게시판에 사용했던 소프트웨어가 더 이상 관리 안되고 최신 PHP나 mySQL 버전과 호환되지 않을 가능성도 많다.
NASA가 달착륙 비디오를 제대로 보관하지 못하는데 일반인들이 수십년전에 찍은 사진 파일을 스스로 제대로 보관하고 찾아볼 수 있기를 기대하기 어렵지만, 위에서 얘기한 이유들 때문에 social network이나 사진 호스팅 사이트에 업로드해두는 것도 해결책이 못된다.
우리 삶의 점점 더 많은 부분이 디지털 데이터로 기록되고 있으나 이 데이터들의 유효 수명은 더 짧아져가고 있다. 작년에 새로운 서비스를 구상하면서 이 문제의 개선을 중요한 목표로 제시하였으나 사내에서도, 제안을 받은 모 대기업에서도 이 가치를 중요하게 인식하는 사람은 별로 없었다. 윤미네 집이 3쇄에 들어가고 대형 서점의 예술 부분 베스트 셀러에 올랐다고 하지만, 어쩌면 이런 걸 중시하는 사람들은 그래봐야 소수이거나 회사의 의사 결정권을 가진 바쁜 사람들과는 다른 부류의 사람들인 모양이다.
구글은 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와 유사한 점도 많아서 앞으로 구글이 이 두 서비스를 어떻게 진화시켜나갈 것인지 궁금하다.
어렸을 때 집에 파리가 많았다. 종종 고무줄 총으로 파리를 잡았는데, 앉아있는 놈을 수십cm 정도 거리에서 맞추는 것은 쉬웠지만 한번은 계속 날아만 다니고 절대로 앉지 않는 파리가 있었다. 이 녀석을 잡기 위해 방문을 닫은 후 동생과 함께 벽을 등지고 앉아 고무줄 한통을 다 소모한 후에야 마침내 공중 요격에 성공한 적이 있었다 (믿기 어렵겠지만 두 사람이 동시에 쏜 고무줄이 공중에서 교차하면서 파리를 격추, 형체는 없어지고 반대쪽 벽에 파편만 남았다).
작년까지 관악산 개울 옆 주택에서 각종 벌레에 시달리며 (전원주택이나 별장에 대해 환상을 갖는 사람들이 있겠지만 나는 모기가 올라오지 못하는 고층 아파트로 이사와서 너무 좋다) 꿈꿔왔던 것 중의 하나가 벌레 요격 장치였다. 내가 생각했던 것은 대략 아래 두가지를 합쳐 놓은 것 정도였는데
Intellectual Ventures에서는 조금 더 위험한 것을 연구하고 있다.
이런 걸 집에 갖다 놓으면 안드로메다 스트레인에서 탈출하던 주인공처럼 되지 않을까?
지금까지 구입한 아이폰 애플리케이션 중 가장 비싸지만 ($9.99) 그런만큼 만족도도 높은 iPeng.
Squeezebox를 제어하는 리모콘 기능의 애플리케이션이다. Rhapsody처럼 수백만 곡을 가진 음악 서비스에서 원하는 음악을 찾기 위해서는 결국 검색이 주된 방법이 될 수 밖에 없다는 점에서 전용 리모콘보다 편리하다. 또한 Squeezebox의 제한된 디스플레이에 비해 아이폰의 비교적 큰 화면으로 앨범 이미지를 보여주면서 빠르게 스크롤할 수도 있다.
구입 전에 우려했던 것은 행여나 이 애플리케이션을 클릭한 후 사용할 수 있기까지 오래 기다려야 하면 어떻하나 하는 것이었는데, 멀티태스킹은 안되어도 애플리케이션의 기동과 WiFi 접속이 빠른 iPhone 3GS 덕분에 사용에 전혀 불편함이 없을 정도이다. 다른 기능은 못써봤고 PC의 라이브러리와 Rhapsody 관련 기능만 써봤는데 매우 만족도가 높았다 (나만 그런 것은 아니고 앱스토어의 평점도 매우 높은 편).
Squeezebox에 비해 훨씬 사용성이 좋은 Sonos의 경우에도 iPhone Controller가 더 쓰기 좋다는 평이 있는걸 보면, 앞으로 iPhone이 복잡한 기능을 가진 가전제품의 리모콘 대용으로 더 많이 사용될 것 같다. 사실 가전제품의 리모콘에 투입될 수 있는 제조 원가나 UI R&D 비용을 생각해보면 iPhone을 이용하는 편이 훨씬 유리한 것이 당연하다. 아직은 iPhone/iPod Touch나 다른 WiFi와 어느 수준 이상의 HTML 브라우저를 지원하는 디바이스를 보편적으로 갖고 있다고 가정할 수는 없으나 몇 년 후에는 그렇게 가정하고 자체 리모콘으로는 기본 기능만 제공하는 경우도 늘지 않을까?
어쨌든 iPeng은 Squeezebox와 iPhone 혹은 iPod Touch를 사용하는 사람에게는 강추할만한 애플리케이션.

Chrome OS를 VirtualBox에서 돌려봤다. 방법은 여기를 참조. Gmail 등은 들어가지지만 데모에서 봤던 app directory등은 액세스되지 않는데, 아마도 허용된 account가 별도로 있는 듯 하다.
한동안 맥을 사용하다가 팔아버린 가장 큰 이유가, 90% 이상의 시간을 어차피 브라우저만 사용하기 때문이었다 (나는 하드웨어로서의 맥은 별로 좋아하지 않는다). 또 나름 만족하던 넷북을 팔아버린 이유는 사용하는 PC의 수가 늘수록 관리 부담이 늘기 때문이었다. 그런 점으로 볼 때, 모든 데이터가 클라우드에 sync되고 브라우저 사용에 최적화되어 있는 Chrome OS의 특성은 나같은 사용자에게는 그런대로 잘 맞을 것 같다.
구글만큼 스피드에 집착하는 인터넷 회사도 많지 않을 것 같다. 구글의 검색도, 메일도 처음 나올 때부터 가장 큰 특징 중의 하나가 속도였지만 자사 서비스 뿐만 아니라 웹 전반의 속도를 향상시키는 것을 목적으로 많은 정보를 제공하고 있고 그걸로 모자라서 역시 빠른 속도를 가장 큰 특징으로 하는 브라우저를 직접 개발 보급하고 심지어 HTTP 프로토콜을 근본적으로 바꾸는 시도까지 하고 있다.
굴지의 인터넷 혹은 IT회사라고 해서 다들 속도를 중시하는 것은 아니다. 아마 Java applet이 launch 속도만 빨랐으면 지금 Flash의 자리를 대신 차지하고 있었을 테고 (뒤늦게 변칙적인 방법까지 시도하고 있지만…) Vista가 XP 또는 Windows 7만큼 빨랐더라면, SKT 통합 메신저가 OEM 메신저만큼 빨랐더라면, 삼성폰의 위젯 UI가 iPhone만큼 빨랐더라면 등등 느린 속도 때문에 불만을 사고 있는 제품들이 많다.
이런 제품이나 서비스들의 속도가 충분히 빠르지 않은 것을 단지 그걸 만든 엔지니어들이 구글 엔지니어만 못해서라고 판단할 수는 없다. 어떤 기능에 우선순위를 두어 언제까지 개발하고 어느 정도의 품질이 되면 출시할 것인지를 최종 결정하는 것은 실무 엔지니어가 아닌 경영층이기 때문이다.
그렇긴 하지만, 실무 개발자나 실제 사용자라고 해서 제품이나 서비스의 반응 속도를 다 똑같이 중요시하는 것은 아니다. 내가 직접 접한 엔지니어들의 경우에도 어떤 이들은 속도를 중시하지만, 더 많은 이들은 몇 초쯤 기다리는 것은 아무렇지도 않게 생각한다.
하지만 0.1, 1, 10초는 대략 그렇다는 것이고 실제로는 사용자에게 적절한 피드백이 주어지는지, 웹사이트가 점진적으로라도 로딩이 되는지 등 많은 요소들에 의해 사용자가 용인할 수 있는 지연 시간 (Tolerable Wait Time)이 바뀔 수 있다. 개인차도 큰 것 같다. 내 경우엔 느린 제품이나 서비스는 무척 싫어한다. 나는 MP3 플레이어가 부팅하는 시간을 참을 수 없어서 아이팟을 사용하며, 빠른 길을 두고 느린 길로 가는 것을 참을 수 없어서 TPEG을 가장 잘 반영한다고 하는 엔나비를 사용하지만 부팅 시간이 없는 파인드라이브 제품으로 바꿀까 생각 중이다.
구글이 웹 속도를 올리기 위한 다양한 노력을 하는 것이나 특히 이번에 새로 만든 프로토콜 SPDY가 내가 예전에 만들었던 로봇과 이름이 비슷한 것을 보면 구글에도 나하고 Tolerable Wait Time이 비슷한 사람들이 많은 것 같다 (물론 나는 그래서 반응 속도가 빠른 구글의 서비스들을 많이 사용한다).
애플의 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.”.

From Gartner through ReadWriteWeb.