Chromebook: 문제는 가격, 요점은 보안.

링크: 구글 크롬북 홈페이지

태블릿보다 싸고 배터리 오래가면서 더 나은 웹 성능을 제공하는 컨셉의 크롬북. 데이터를 모두 구글에 저장해야 하는 점을 제외하면 괜찮은 솔루션이라고 생각한다. 특히나 비즈니스에서는 built-in hardware를 통한 보안 기능이 상당히 매력적이다. 다만 문제는 넷북보다 비싼 가격. 하드웨어 구성에서는 암호화 하드웨어를 제외하면 넷북에서 HDD가 빠진 정도인데 윈도 라이센스 가격도 빠질 터인데 넷북보다 비싸다. 솔직히 저 자격이면 개인에게는 화이트박스 넷북에 우분투 등 리눅스에 구글 크롬 브라우저를 기동시키는 게 낫다. 하지만 비즈니스에서는 좀 다르다. 가격에서의 요점은, 3G망 그리고 보안.

인터넷에 항상 연결되어 있어야 하므로, 사실상 3G망이 필수다. 월 $31에 기기할부값과 100MB 통신을 모두 제공하는 듯한데, 이런 조건이라면 데스크탑 사용자라면 모바일 기기로 사용해도 괜찮을 것 같다. 아마도 싱크 방식으로 동작할 가능성이 높으므로 Wifi를 병용한다면 생각보다 통신 사용량도 많지는 않을 것이다. 구글이 월100MB 정도를 적정량으로 보고 있기도 하다. 다만 스트리밍이 문제인데, 멀티미디어의 경우에는 캐시를 대량으로 사용하는 방식일 가능성이 크다. 100MB라면 멀티미디어보다는 정적인 웹과 gmail/docs/calendar 등의 사무작업용이다. 정해진 사이트에서만 3G망을 사용할 수 있도록 하는 기능도 있을 수 있겠다.

보안이 중요하다면 크롬북은 생각보다 비싸지 않다. 일반 넷북에 스토리지 단위로 암호화를 (성능저하없이) 적용하려면 적어도 기기당 $50은 들 것이다. 별도 칩과 하드디스크 분리방지장치가 필요하니, 사실 저 가격도 싸게잡은 편이다. 거기에 윈도를 쓰려면 윈도용 보안제품도 따로 구매할 필요가 있다. 구글 크롬은 가장 보안이 좋은 브라우저 중 하나이고, OS 자체 내에서 built-in 보안이 통합되어 있다. 개인적으로 저 built-in hardware based security가 크롬북에서 가장 매력적이었다. 꼭 구글 독스가 아니더라도, MS 웹 오피스를 크롬북에서 구동하지 못할 이유는 없다. 어쩌면 가격 대비 가장 안전한 단말기일지도 모르겠다. 그리고 그런 면에서 크롬박스가 기대된다.

일단 기업용으로 대량으로 팔리기 시작한다면 개인들에게도 싼 가격에 제공할 수 있을 것이다. 최소한 넷북보다 낮은 가격이 필요하다. 어차피 x86에 제한될 이유도 없는 시스템(모두가 웹, 즉 스크립트 형식으로 돌아간다.)이니 ARM등이 싼 가격에 웹 처리에 부족함이 없는 수준까지 올라온다면 ARM 등 기반의 SoC 기반으로 발전할지도 모른다. 안드로이드 태블릿과 같은 하드웨어를 갖추게 될 가능성도 크다. 인텔이든 ARM이든 구글은 적합한 솔루션을 골라쓸 수 있다. 특히 안드로이드가 Java 관련해서 오라클과 소송중인데, 웹 앱의 가능성을 실험해보는 테스트 베드로서도 쓸만하다.

문제는, 이 모든 개념들이 서버 집중식의 Network Computer와 하나도 다를 것이 없다는 점이다. PC와 웍스테이션이 등장한 이후, Sun, Oracle 등 쟁쟁한 도전자들이 기업들에게 제안했지만 모두 실패해 왔던 넷 컴퓨터. 과연 구글은 이를 성공시킬 수 있을까? 내 생각으로는 안드로이드 태블릿의 하드웨어가 발전하면 그보다 더 큰 스크린, 더 오래가는 배터리, 커다란 키보드를 달고 비즈니스용 머신으로 발전할 것이라고 본다.

더헛, 이맥스의 끝은 어디인가;;;

링크: M-x google-maps

이맥스(emacs)에서 구글 맵을 볼 수 있는 모드가 등장했다. 나도 이맥스의 열렬한 팬이자 프로그래밍에는 이맥스만 쓰는 편이지만 이 것은 정말로… 좋은 것이다! 처음 시작할 때부터 이맥스는 텍스트 에디터가 아니라 운영체제에 가까운 물건이라는 말은 많이 들었고 그 근거?들을 한두개 본 것은 아니지만, 이번 구글 맵 모드는 정말 놀라웠다.

– 현업에 있었다면 코딩 틈틈히 땡땡이용으로 애용?하고 있었을 듯. ^^;

– gdb를 사용하는 프로그래머라면, 꼭 이맥스로 디버깅해보시길. 개인적으로 Visual Studio의 그 훌륭한 디버깅 지원보다 이맥스가 더 편한 경우도 많았습니다.

구글이 독자폰을 출시: 여러가지 노림수들.

구글이 독자폰, 넥서스 원을 출시했다. 스마트폰을 써 보지도 못했으니 유저 입장에는 뭐라 쓸 말이 없기는 하지만, 개발자로서는 옛날 휴대폰 플랫폼 파던 것도 떠오르고 몇가지 전략적으로 생각나는 것이 있어서 적어본다. 왜 구글은 넥서스 원을 출시했을까? 독자 브랜드 진출도 그렇지만, HTC와의 연합이 강고하다는 것을 모토로라, 삼성, LG에게 어필해서 좋을 것도 없었을텐데 말이다. 하지만 구글이 넥서스 원을 통해서 노리는 것들은 그만큼의 가치가 있어 보인다.

1. 개인 개발자들에게 호환성의 기준을 정해줬다. 오픈소스 플랫폼의 경우, 누구나 고칠 수 있다는 점은 사실 호환성에 있어서는 큰 문제다. 리눅스의 경우, 각 배포판 브랜드마다 커스텀화한 패키지를 제공하고 있고 정 안되면 걍 리눅스 시스템에서 컴파일 해버려도 되지만, 스마트폰에서 그렇게 할 유저는 없다. 즉 안드로이드 앱들은 수많은 변종 안드로이드들 사이에서 문제를 일으킬 가능성이 크다. 특히나 UI쪽은 그렇게 되기 매우 쉽다. 한 픽셀만 어긋나도 화면은 이상하게 보이니까. 더해서 Virtual Machine 모델이기 때문에 폰 메이커가 VM을 변경하면 호환성은 더욱더 떨어진다. 보통 아이폰의 경우 개인 개발자들이 앱을 개발하는데, 안드로이드는 이미 “어떤 폰에서는 안 돌아가요~”라는 클레임을 많이 받는다는 이야기도 보았다.

기업들이 앱 제작의 중심이라면 사실 SDK 표준폰들을 마구 뿌리면 될 일이지만, 아이디어로 승부하는 개인 개발자들(취미가들)이 앱 하나 개발하자고 쓰지도 못한 개발용 표준폰을 사들여줄까? 실용으로는 쓰지 않기 때문에 유저들의 안드로이드 폰과는 동떨어져 있을 물건이기도 하다. 즉, 넥서스 원은 개인 앱 개발자들에게 호환성의 기준을 정해준 셈이다. 개인 개발자들은 이렇게 말할 수 있다: 넥서스 원에서 이 앱 잘 돌아갑니다. 안 되는 건 여러분의 안드로이드 폰의 문제 때문이에요. 폰 메이커에게 말씀하세요.

+ 이는 소규모 폰 개발사들에게도 축복인데, 아무리 문서가 뛰어나도 일단 잘 돌아가는 표준 기기(소스코드도 있다!!! >_<)를 베끼는 쪽이 훨씬 쉬운 법이다. 쉽게 손에 넣을 수 있다는 점에서 더욱 그렇다.

2. 안드로이드 커스텀화의 견제, 즉 플랫폼의 호환성 유지를 위해서. 1번하고 연결되는 주제로, 안드로이드는 요즘 플랫폼이라기보다는 인프라에 가까운 대접을 받아왔다. 안드로이드 자체도 많은 버전이 존재하는데다 각 폰 메이커와 통신사들은 안드로이드를 이용해서 빠르게 자기네들의 특성을 살린 기기들을 구상하고 있었다. 사실 플랫폼 호환성에 주목하기 보다는, 빠르게 인터넷을 이용할 수 있는 폰 소프트웨어로 생각하는 이들도 많은 게 사실이다. 인터페이스 정도는 커스텀화 시킬 수 있겠지만 그게 지나쳐서 앱들을 사용할 수 없을 수도 있다. 또한 폐쇄적인 통신사의 서비스에 묶어버리거나, 폰 메이커의 소프트웨어 마켓에만 제한시키거나 하려는 움직임도 보이고 있었다. (특히 한국 시장에서…) 그렇게 되면 구글이 원하는 스마트폰 플랫폼이 아니라 간단히 폰 개발할 때 사용하는 인프라 소프트웨어에 그쳐버린다.

구글은 넥서스 원을 통해서 안드로이드라는 이름을 붙이려면 최소한 이 폰이 돌리는 앱이나 서비스들은 구현해줘야 한다, 라고 그들에게 경고함과 동시에 시장에 안드로이드의 인터페이스에 대한 컨센서스를 형성하려고 하고 있는 듯 하다.

3. 구글과 안드로이드 브랜드의 결합. 여러 폰 메이커가 만들기 때문에, 오히려 안드로이드 브랜드는 희미해지고 있다. 모토로라 드로이드건, 삼성 갤럭시건 간에 광고나 홍보에서 안드로이드 자체를 강조하지는 않기 때문에 컨수머 레벨에서 안드로이드 브랜드의 약화가 우려된다. 안드로이드는 단순한 호환성 딱지 정도로 브랜드 파워가 떨어질 수도 있다. 여기에서 구글은 세계 톱 클래스의 자신들의 브랜드에 안드로이드를 결합시켜서 컨수머 레벨에서 브랜드를 강화시키려는 목적도 있어 보인다. 즉, 예를 들자면 모토로라 드로이드 => 모토로라가 만든 구글폰, 안드로이드는 구글폰, 이라는 인식을 심어주고 싶어하는 듯 하다.

4. 규모의 경제 실현. 여기서 퀄컴이 대박을 쳤다. 넥서스 원이 얼마나 팔리건 간에, HTC는 그 물량으로 상당한 도움을 받을 것이고, 부품회사들은 다른 폰 메이커들에게 넥서스 원 호환을 위해서는 자기네들 그 부품을 쓰시는 것이 제일 낫다고 쉽게 영업할 수 있을 것이다. 가장 편하게 호환기를 만드는 방법? 같은 부품들을 쓰면 가장 간단하다. 아이폰은 이미 규모의 경제를 실현하고 있는데, 넥서스 원의 스펙을 표준으로 정해줌으로써 구글로서는 안드로이드 폰들에게 규모의 경제를 안겨줄 수 있다. 과연 폰 메이커들이 그 비용절감과 경쟁자 구글 사이에서 어느 쪽을 더 좋아할지는 사실 미지수지만, 일단 일이 벌어진 상황에서 비용절감은 장점이 된다.

사실 구글은 넥서스 원이 얼마나 팔리건 간에, 노린 것들은 대부분 손에 넣었다. 앞으로 안드로이드 폰들은 대부분 넥서스 원 호환폰들이 될 것이다. 구글이 이렇게 터프한 전략을 사용할 수 있는 것은 마이크로소프트의 윈도 모바일이 거의 망해서 대안이 없는 폰 메이커들을 갈굴 수 있어졌기 때문이기도 하다. ^^;;

삼성과 LG는 HTC가 안드로이드의 표준이 되어버린 이 상황을 어떻게 돌파하려고 할까? 아니면 그냥 안드로이드 폰 개발비용이 싸져서 문어발식 플랫폼 전략에 자금여유가 생겼다고 기뻐하고 있으려나? -_-;;; HTC를 능가할 무엇인가가 없다면, 삼성과 LG는 마이크로소프트가 어떻게든 윈도 모바일을 개인 시장에서 살려내기만 빌어야 할 판이다. 외신에서 LG가 구글폰을 만든다는 루머도 있었는데, 그게 사실이었다면 스마트폰의 Dell이 될 기회를 LG가 놓쳤다. 한국 폰 메이커들은 스마트폰에서 이제 무엇을 보여줄 수 있을까?

구글 크롬: 첫인상만 우선 간단히

링크: 구글 크롬 웹 브라우저 페이지

구글이 크롬Chrome이라는 웹 브라우저를 발표했다. 필자로서는 대환영이다. 구글의 웹브라우저이기 때문만은 아니다. 옛날부터 속도로는 KHTML 레이아웃 엔진이 가장 빠르다고 생각했는데, 이걸 애플이 가져다가 팔아먹을만하게 뚝딱뚝딱 잘 안 죽고, 비표준도 좀 나오게 고쳐서 자기네 웹 브라우저 사파리에 탑재했다. 그것이 Webkit 엔진이다. 개인적으로는 윈도용 사파리는 빠르긴 한데 너무 무겁고 해서, Webkit 엔진을 탑재한 윈도용 브라우저 (사파리는 윈도용 애플 Core 라이브러리 위에서 돈다. 그리고 그게 아직 안정성이나 성능에서 그닥… )가 나오길 기대하고 있었는데, 마침 구글이 만들어줬다. 예전에 Swift라는 오픈소스 프로젝트가 있었는데, 길게 가지는 못했다. 구글이라면 어떻게든 계속 업데이트를 할 터이니, 윈도에서도 Webkit 엔진의 제 성능을 풀로 쓸 수 있게 된 것이다.

이틀간 주 브라우저로 써 봤는데, dcinside도 생각보다 잘 돌고 네이버도 잘 써진다. 워드프레스는 매우 빠르게 안정적으로 돈다. 기본적인 기능들의 속도나 안정성 면에서 보면 beta판 수준은 넘어선 것 같다. 아직 세세한 기능들이 좀 부족하긴 한데… 다음과 같으신 분들에게 특히 추천한다.

 

  1. 네이버나 다음 웹툰이 너무 느리게 떠염.
  2. 인터넷에서 사진 갤러리들은 왜 이리 느려염? 화면 뜨고 사진 뜨고 다시 제 자리 잡을 때까지 속터져염.
  3. 블로그들을 빠르게 보고 싶어염.
  4. 저는 구글 서비스들을 많이 이용해염.

 

단점으로는… 우선 RSS 리더나, 광고 차단, 마우스 단축키 등 부가 기능들을 제공하지 않는다. 불여우나 오페라에서 잘 제공해주던 Java Script 세부 설정도 지원해주지 않는다. 있는 것은 팝업 차단 기능 정도? 확장 API를 제공하니, 서드 파티로 제공될 것 같기는 한데… 일단은 정말로 기본적인 브라우저만 있다고 보시면 된다. – 어쩌면 RSS 리더는 구글 리더 쓰시고, AdSense나 타사 광고들도 좀 보시고(광고가 떠도 빠르긴 하다), Java script는 사이트에서 제공하시는대로 좀 쓰세요~ 라는 구글이 이야기하는 듯도 하지만. ㅎㅎㅎ

가장 큰 단점으로는… 크롬 구조의 최대 특징인 멀티 프로세스 구조에서 오는 메모리 사용량이다. 불여우FireFox나 오페라 최신 버전들이 메모리 절감에 노력한 것과는 다르게, 엄청 먹어제낀다. 다음 그림은 딱히 그림이나 플래시 별로 없는 블로그와 커뮤니티 탭이 5개 떠 있는 상황에서의 크롬의 메모리 사용량이다.

저어기 chrome.exe라고 쓰여있는 모든 프로세스들의 메모리 사용량의 합이 크롬 브라우저의 메모리 사용량이다. 최신 OS들의 프로세스가 모두 light-weight화되어서 탭을 새로 띄울 때에는 별 문제가 없는데, 메모리 사용량만큼은 타 브라우저에서 탭 하나에 다른 창으로 모두 띄운 정도로 메모리를 쓴다. 물론, 이는 최적화가 안 되어 있는 beta 버전이므로 앞으로 좀더 나아질 수 있는 부분이다.

크롬의 설계 – 플러그인조차 독자 프로세스로 돌릴 정도로 극단적인 멀티 프로세스화 – 는 구글이 말하는 안정성을 위한 것 외에도 다른 거대한 목적이 있다고 본다. 사실은 이 주제로 쓰고 싶었지만, 밤이 너무 늦었다. 필자도 4시간은 자야지. -_-;; 그건 다음 기회에. 가볍게 단서를 던지자면, 크롬 브라우저는 탭이 창의 맨 상단, 타이틀바에 늘어서는데… 그거? 태스크 바로 안 보이십니까? 

후후후, 다음 글의 제목은 “구글 크롬: 너는 내가 브라우저로 보이니?”가 되겠습니다. 🙂