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

구글이 독자폰, 넥서스 원을 출시했다. 스마트폰을 써 보지도 못했으니 유저 입장에는 뭐라 쓸 말이 없기는 하지만, 개발자로서는 옛날 휴대폰 플랫폼 파던 것도 떠오르고 몇가지 전략적으로 생각나는 것이 있어서 적어본다. 왜 구글은 넥서스 원을 출시했을까? 독자 브랜드 진출도 그렇지만, 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시간은 자야지. -_-;; 그건 다음 기회에. 가볍게 단서를 던지자면, 크롬 브라우저는 탭이 창의 맨 상단, 타이틀바에 늘어서는데… 그거? 태스크 바로 안 보이십니까? 

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