casaubon

---

SEPTEMBER 5, 2008

Doomsday: Why Google needs its own browser.

By Robert X. Cringely
bob@cringely.com

이번 주는 구글이 오픈소스 웹브라우저, 크롬으로 온 세상을 놀래킨 주였다. 실리콘 밸리에 십여 곳 이상의 웹브라우저-관련 신생 기업에게 미칠 영향을 상상해 보시라. 크롬에 대한 필자의 의견을 묻는 독자들도 매우 많았다. 마치 필자 의견이 정말 중요한 양 말이다. 크롬, 좋다. 빠르다. 하지만 그것만으로 브라우저를 크롬으로 고정시킬 정도는 아니다. IE보다 더 낫고, 플러그인이 전혀 없는 파이어폭스보다도 거의 더 낫다. 그러나 정작 궁금한 점은 다른 데에 있다. 도대체 구글이 왜 브라우저질을 할까? 이제는 그 답을 알 것 같기도 하다.

세상에 웹브라우저가 부족하지는 않다. 매우 많다. 인터넷 익스플로러가 윈도 세상을 지배하고 있기는 하지만, 파이어폭스(오페라나 사파리 등도 말할 나위 없다)가 마이크로소프트를 정직하게 만들어주는 정도다. 그렇다면 구글이 왜 여기에 끼어들까? 일반적인 답 두 가지가 가능하겠다. 그 두 가지는 상호 관계가 있는 이유이다. 당연히 하나는 모두들 아실 만한 이유이고, 다른 하나는 필자의 이유이다.

구글이 스스로 브라우저를 만드는 첫 번째 이유는 친구 데이브의 아이디어에서 나왔다. 그의 말이다.

"구글 크롬을 보고는 소위 브라우저 전쟁에 구글이 뛰어들었다고들 보더구만. 전혀 그렇지 않아. 크롬이 어떻게 되건 구글은 상관도 하지 않는다구. 사실 파이어폭스와 오페라가 크롬을 멸종시킬 정도로 브라우저를 개선시킨다면야 정말 큰 일이 되겠지. 구글은 크롬으로 전혀 얻는 것이 없어. 구글의 수입은 웹브라우저의 사용에 따라 나오지만, 그건 어느 브라우저이건 상관 없지."

"하지만 마이크로소프트가 형편 없는 브라우저를 만드는 것은 구글도 원치 않지. 사실 구글은 마이크로소프트 브라우저가 형편 없는지 있는지조차도 별 관심이 없어. 다만 형편없는 브라우저를 마이크로소프트가 만들어서, 사람들이 그것만 쓰는 상황은 구글도 원하지 않아. 만약 IE8 베타가 뭐라도 의미가 있다면, 정말 형편 없는 브라우저 만들기야말로 마이크로소프트의 진정한 관심일지 모르지."

"구글이 상관하는 바는 사못 간단해. 브라우저는 웹페이지를 올바르게 렌더링하고, 브라우저 안의 자바스크립트 엔진은 빠르고 효율적이면서 버그가 없어야 해. 이 두 가지가 중요하지. IE8은 형편 없어. JScript는 버그도 많고 올바로 작동하지를 않아. IE8의 페이지 렌더링 엔진도 표준을 안따르지. 이 두 가지 때문에라도, 구글 애플리케이션 개발에 신경써야 해. 안 그러면 자기가 원하는 기능을 구현을 못시키게 되지. 최근 마이크로소프트가 윈도와 IE를 써야만 가능한 매력적인 웹 컨텐트에 투자해왔다는 사실을 알겠지."

다시 필자다. 데이브가 한 말, 일리 있다. 동의한다. 하지만 진짜 정답은 아니다. 구글이 브라우저를 어째서 만드느냐의 답이 아니고, 구글이 브라우저까지 끼어들 수 밖에 없었느냐에 대한 답일 것이다.

이 마지막 질문에 대한 답이 데이브가 한 말에 있다. 마이크로소프트의 최근 웹 콘텐트는 윈도와 IE로 봐야 한다. 이것이야말로 구글에게 공포감을 안겨다 주었을 것이다. 마이크로소프트가 IE에서 구글 광고를 꺼버릴 수 있기 때문이다.

설마 마이크로소프트가 그럴 수 있을까?

마이크로소프트가 이 영역에서 자기 하고픈 일이라면 꽤 할 수 있다. 브라우저 경쟁은 여전하며, 사용자들을 IE에서 멀어지게만 한다면 뭐라도 덧붙일 수 있다. 하지만 마이크로소프트는 브라우저 사업으로 한 푼도 벌지 않는다. 도대체 마이크로소프트에게 거칠 것이 무엇일까? IE의 구글 광고를 마이크로소프트가 꺼 버리면 어떤 일이 발생할까? 구글은 엄청난 수입 저하를 겪게 된다. 월스트리트 눈에도 곱게 비쳐질리 없다. 그러나 마이크로소프트에게는 전혀 해가 없다. 마이크로소프트야말로 웹의 진정한 보안관임을 과시하면 그만이다.

실제로 이런 일이 일어나리라고 쓰는 것은 아니다. 일어날 수도 있다는 정도다. 이것만으로도 구글이 브라우저 사업에 뛰어들 동기부여가 충분히 된다.

마이크로소프트에 있어서 핑계를 대 줘야 할 필요가 없다는 점을 분명히 하자. 브라우저는 돈받고 파는 것이 아니니 광고를 멈추겠다고 할 수 있는 일이다. 싫다면 얼마든지 다른 브라우저를 쓰시라고 하면 된다. 구글이 큰 타격을 입는다 하더라도 마이크로소프트로서는 수입에 거의 변화가 없을 것이다. 이런 상태가 몇 달만 지속되면, 마이크로소프트는 구글에데 두 번째 펀치를 먹일 수 있게 된다. 물론 그런 것까지 생각한다면 말이다.

자, 그렇다면 마이크로소프트가 실제로 그럴 수 있겠는지, 구글 사람들도 열심히 궁리를 할 것인지 궁금하실 것이다. 당연히 고민하고 있을 터이다. 바로 그런 상황을 막자고 크롬이 나오게 되었다. (데이브가 위에 말한 여타 다른 이유도 마찬가지이다.) 향후 브라우저 개발의 미래와 IE로부터의 점유율 확보가 구글의 목표다.

그런데 크롬은 사파리에도 있는 웹킷 렌더링을 내세웠다. 웹킷이 파이어폭스와 오페라에 들어간다 하더라도 놀라운 일은 아니다. 어찌 됐건 IE로부터 사용자들을 빼앗으면 되기 때문이다. 하지만 웹킷도 바뀐다. 구글의 V8 자바스크립트 엔진이 웹킷과 사파리 안에 들어가 있는 JavaScriptCore를 교체하게 될 것이기 때문이다. 모든 오픈소스 브라우저(그리고 사파리)들은 더 나아지고, 더 유사해진다. 이 모두가 IE와의 경쟁에 보탬이 된다.

이 오픈소스 브라우저의 파도가 일어나게 되면, 구글은 이 파도를 IE와의 경쟁에 더 몰아 넣고 싶어할 것이다. 따라서 크롬은 모든 구글 애플리케이션과 궁합이 잘 맞는 하나의 모범 디자인이랄 수 있다.

크롬은 이 정도로 되었다. 이제는 정말 무서운 소식이다. P2P 파일공유가 요새들어 좀 줄어들었다는 소식을 들었다. 사실은 성장률이 수그러들었다는 것이지, 시장 자체는 언제나 커지고 있으며, 가격은 계속 떨어지고 있다. 성장률이 떨어진다고 해도 성장은 성장이다. 그 이유는 애무 많다. (시장 성숙, 혹은 여름 방학 등) 그렇지만 그 소식덕택에 RIAA와 MPAA가 안도하는 모양이다. 그들은 음악와 텔레비전 프로그램, 영화 공유를 싫어한다. 자신에게 속한 지적 재산권을 침해한다고 보기 때문이다.

그런데 필자는 뭔가 다른 일이 일어나고 있다고 본다. 파일 공유를 할 다른 방법을 사람들이 찾고 있다는 것이다. 그것도 검출이 더 어렵고, 심지어 사회에 경종을 울리는 식이다.

일단 P2P의 태생이 어디인지 알아보라. BitTorrent와 유사 프로그램의 아이디어는, 같은 콘텐트를 원하는 사용자는 많지만 광대역이 부족하며, 따라서 캐시에 따른 공유를 하여, 원하는 파일 조각을 얻을 수 있게 해 놓았다. 매우 효율적으로 말이다. 특히나 고정된 속도의 광대역이면 더욱 그러하다. 관점에 따라서 다르겠지만, P2P는 엄청난 성공일지도 모르고, 거대한 고통일지도 모른다.

그런데 그 이후로 초고속 인터넷 가격이 대단히 하락하였다. P2P가 1990년대, 사람들 대부분이 모뎀을 사용할 때 태어났음을 기억해야 한다. 지난 10년간 인터넷 백본망 비용이 절반 정도 하락하였다. 경제도 급변하였으며, 그에 따라 서버를 따로 갖춰도 합리적인 시대가 되었다. 유튜브 얘기하는 것이 아니다. 영화와 음악 배포에 쓰이는 전용 서버를 말함이다. 인터넷 백업 서비스의 범람을 얘기하고 있다는 말이다.

이런 새로운 종류의 서비스의 기린아(麒麟兒)는 독일의 파일-공유 서비스인 RapidShare이다. 200메가바이트까지 무료로 파일을 배포할 수 있으며, 일 년에 55유로를 내면(그리 큰 돈이 아니다) 2기가바이트까지 된다. 그러면 파일 수와 저장 용량, 총 다운로드, 심지어 동시에 몇 명이나 다운로드되는 것까지 모두 무제한이다. 다크나이트 복제본을 이런 서비스에 올려 놓은 뒤, 좋아하는 이들에게 URL을 보내거나 웹 어디엔가 주소만 붙여 놓으면 된다. P2P만큼 효율적이지는 않더라도, 분명 더 쉽고, 검출도 더 어렵다. http가 사용된다는 것 외에 알아낼 것이 없기 때문이다.

이 서비스가 어떻게 될지 아시겠는가? 이런 기술이 널리 대중화될 경우, MPAA와 RIAA가 과연 그 서비스를 좋아할까? 우리를 더 스파이하기 원할 테고, 아예 네트워크 백업을 감시하려들지 모른다. 더 많은 소송이 이어지고, 더 많은 할머니와 아이들이 고소를 당할 것이다. 당연히 프라이버시는 줄 테고 말이다.

RIAA와 MPAA가 결국은 실패하리라고 본다. 한 번 사제 프로토콜과 포트가 등장하면, 그 파일이 스프레드 쉬트인지, 게임인지 차이를 말할 수 없다. 하지만 그것은 그것대로, 우리는 매우 고통스러운 세월을 보낼련지 모른다.

I, Cringely . The Pulpit . Doomsday | PBS

__________________

Wazaza

구글이 뭘 내 놓을때마다 그것이 무슨 대단한(또는 의미있는) 전략적 결정에 의한 것이라고 생각할 만한 이유가 있는지 잘 모르겠네요. 실제로 크롬 개발하는데 든 비용이 무슨 사운을 걸만한 그럴 정도도 아니었을 것이구요. 아주 단순하게, "아 뭐 좀 좋은 브라우저 하나 없나? 하나 만들어 볼까나~" 이렇게 시작되었고, 그렇게 세상에 나온것으로 보는 것이 더 진실에 가까울지도 모르겠다는 생각이 듭니다. 그나저나 크롬 빠르기는 하네요 맥용도 기대중~

campari

구글에서 이야기 한것도 거의 쓸만한 브라우저 한번 만들어볼까? 하는 듯한 뉘앙스를 느꼈습니다.
구닥다리 윈도머신에서도 쌩쌩돌아가는 것을 보고 정말로 입에 침이 튀기도록 칭찬을 했고, 지금도 잘 쓰고 있습니다.
몇가지 사소한 문제점이 있지만, 지금까지 나온 그 어떤 베타버전의 브라우저보다 더 안정적으로 작동하는게 너무 인상적이었습니다.

저도 맥용이 어서 나오길 심히 기대중입니다. ^^

__________________
항상 피사체를 바라보는 눈빛으로...

ethar

전화기를 위한 앤드로이드와도 무관하지는 않겠지요.

__________________

glradios

뭐... 래피드쉐어같은 http방식을 통한 공유 붐은 한국에서는 이미 7~8년 전에 지나갔는데 이 붐이 줄어들은 이유는 대부분 통제가 가능했기 때문이죠. 뭐... 하지만 질긴건 사실 같군요. 제가 대략 5년 전에 받았던 파일들이 경로가 그대로 살아서 넷을 떠돌고 있는 것을 얼마 전에도 봤습니다. 업로더 조차 잊은 파일이죠 ㅋ
그 역사를 비추어볼 때 작가 분이 말씀하시는 것처럼 현재 일고 있는 공유의 태풍이 폭풍이 될 것 같지는 않습니다.

크롬 얘기는 정말 정확한 것 같네요. 여러 기사를 들추어보면 구글 측에서 경쟁상대는 파이어폭스가 아닌 IE라고 지목하는 등 이 예상과 상당히 일치하는 부분이 많은 것 같습니다. 과연 전문가는 다르군요!

dinki

간단하게 생각하면, 결국 아이폰 OS와 사파리의 연관관계가 아닌가 싶네요.

안드로메다와 크롬

gregorjamja

안드로이드 아닌가요. 아시고 그러신거겠죠. ^-^

제생각도 구글이 모바일버전을 염두에 두고 웹브라우저를 만들었을 거 같네요. 얼마전 엔비디아 칩이 내장된 모바일 폰에 오페라브라우저를 기본 탑재하기로 했다고 발표하더군요. 앞으로는 모바일 컴퓨팅에 쓰이는 웹브라우저가 중요해 지려나 봐요. 근데 웹킷은 오픈소스라 상용소프트웨어에 쓰일때도 비용이 안드나요? 크롬이 웹킷렌더링 엔진을 썼다고 들었습니다.

KraZYeom

구글은 인터넷 제국입니다. 구글 오피스를 비롯하여, 대부분 오프라인 소프트웨어를 온라인화 하고 있죠..

그 과정에서 가장 문제 되는게 ajax로 이루어진 java 스크립트 해석 문제입니다.

지금 까지 나온... 브라우져는 자바 스크립트 해석이 너무 느리죠..
최근 webkit에서 빨라진것을 이용하여 구글이 크롬을 내 놓은 것이죠.

모바일 버젼도 염두해두고는 있겠지만... 온라인 소프트웨어때문에 더 그럴것입니다.

__________________
백수 탈출!
http://krazyeom.tistory.com

chemmac

WebKit은 LGPL, BSD 라이센스를 따르기 때문에 상용소프트에 사용 가능합니다. 당연히 무료입니다.
그리고, Chrome의 개발 과정에서 렌더링 엔진은 안드로이드 팀의 추천에 따라 Webkit을 사용하기로 했답니다.
즉, 모바일버전을 염두에 두고 개발한 것이 아니라 순수한 데스크탑용 브라우저로 추진된 것입니다.
특히 각각의 탭에 독립된 프로세스를 할당하는 것이 안드로이드의 가장 큰 특징인데 이건 현재 모바일용으로는
적절치 않은 선택이죠.

Chrome은 WebKit의 JavaScriptCore, 혹은 최신의 SquirrelFish 대신에 V8을 개발해서 사용했습니다.
이게 솔직히 좀 이해가 안 되는 것이, 구글이 애플(SquirrelFish)이나 모질라(ActionMonkey)의 개발 상황을 아주 잘 알고
있을텐데 굳이 새로운 자바스크립트 엔진을 개발하려고 뛰어들었다는 겁니다. 개인적으로 이게 구글의 Gears와
어떤 연관이 있는 것이 아닌가 생각이 들지만, 지식/정보가 부족한 관계로 그저 추측에 그칠 뿐입니다.

__________________
케맥이라 불러주세요...

가족과 함께, 맥과 함께
재미있게 살고 싶습니다.

kizoo

케맥 님의 추측이 거의 정답에 가깝군요. VM/GC의 교체 없이는 데스크톱(모바일) 어플리케이션 시장에 본격적으로 뛰어들기가 어렵죠. 또 한 번, (클라우드) 플랫폼 전쟁이 시작되는 군요.

__________________
한국 Microsoft에서 일하는 Mac User
셈말과 셈틀

rhheo

google의 웹어플리케이션의 UI는 거의 javascript로 만들어져 있죠.
현재 나와있는 어느 자바스크립트 런타임도 만족하지 못했던 것이 아닐까요?
아주 긴 스프레드시트를 웹에서 편집한다 던지 말이죠.

만화로 된 소개밖에 못봤지만
이번 V8은 javascript를 완전 OOP화 해서 javascript VM에서 동작하는 형식으로
재 작성한 듯 합니다.
안정화/정형화 시킴으로써 오랜시간 Javascript라 동작하고 있더라도
발생할 수 있는 문제를 최소한 시킨 것 이 아닐까 싶습니다.

__________________
K.I.S.S. Keep It Simple, Stupid! -The Unix Philosophy
Those who can not remember the past are condemned to repeat it. -The Life of Reason(1905)
Email: airless at funit.net

pcsavior

구글의 크롬이라는거.. 그냥 이름만 들어봤었는데
이 글타레 읽고 설치해 봤습니다.
정말 어마어마한 스피드로군요.
한번 갔던 페이지를 뒤로 가기 눌러서 돌아가는 느낌입니다.
처음 파이어폭스를 썼을 때의 쾌감이로군요.
올인원 제스쳐만 있으면 바로 갈아타고 싶네요.

__________________

bandoche

(태클이 아니라 저의 의견이라는점 이해해주세요 )

Apple에서 의도 한 것인지는 모르겠지만, Webkit쪽에서 SquirrelFish를 만든 것이, MobileMe web application 을 구동하는데 유용하게 쓰일 수 있는 것 처럼,

Google도 자신들의 Web app을 신속하게 돌릴 수 있는 브라우져를, 다른 개발자가 아니라, 구글에서 만들고 싶었던 것 같습니다.
(아무래도 직접 만드는 것이 구글의 의견을 반영하기에는 가장 좋은 방법이 아닐까요?)

각각의 프로세스를 할당하는것이 큰 특징이기는 하지만, 나중에 Mobile Safari가 나온 것 처럼, 자신들의 관할안에 있다면, 이런 면에서 훨신 유리하지 않을 까 (프로세스를 할당하는것을 꼭 모바일 디바이스에서 구현할 필요도 없지 않을까요?) 생각합니다.

저도 비슷한 생각입니다. 아마 자신들이 필요한 특정한 javascript 분야(?)에서 더욱 최적화 시켜서 성능 향상을 꾀하는 방법을 택하지 않을까요?

아무튼 Webkit으로 무장한 경쟁상대가 늘어난 것은 좋은 일이라고 생각합니다

imnth2u

SquirrelFish 가 APPLE 쪽 이군요.
SquirrelFish extreme 의 속도는 크롬의 V8 보다도 더 빠르다는 내용도 봤습니다.

웹초보의 Tech 2.1 :: 구글 크롬도 확장기능 지원 준비중 & 웹킷의 새로운 자바스크립트 엔진 성능 공개...



JavaScript 는 Copy&Paste 해서 쓰면 되던 시대는 아주~~ 예전 일이 되었군요.

__________________
I'm nothing to you. ( imnth2u )

rhheo

저두.. 저의 부가적 의견입니다.
"Google의 웹 어플은 크롬에서는 잘 돌아갑니다.
단, 다른 브라우저에서는 문제가 있거나 느릴 수 있습니다."
라고 하는 것은 별루 좋은 평가를 받기 힘들 것이라고 생각합니다.

Google측에서 본다면 어떤 브라우저라도 구글의 웹 어플을 자유롭게
사용할 수 있도록 몰고 가는 것이 도움이 될 거라고 생각합니다.

UI를 담당하는 Javascript의 안정성/효율성의 확보는 가장 중요한
클리어 리스트가 아닐까라고 생각합니다.
설사 자바스크립트가 크래쉬한다고 하더라도 다른 웹 어플에는 영향을 끼치지 않도록
독립된 프로세스로 동작하게 한 것도 안정성 확보의 일환이겠죠.

구글은 다른 웹 브라우저도 크롬에서 이러한 아이디어를 얻어서
서로 닮은 꼴이 되도록 하고 싶을 것입니다.
즉, 크롬만의 기능(구글의 의견)은 구글의 웹 어플의 세계에서는 별로 메리트가 없다고 봅니다.

__________________
K.I.S.S. Keep It Simple, Stupid! -The Unix Philosophy
Those who can not remember the past are condemned to repeat it. -The Life of Reason(1905)
Email: airless at funit.net