My Words, Your Memory

#0 'chrome' 이란 웹 브라우저에서 컨텐츠를 보여주는 영역을 제외한 모든 부분을 일컫는 업계 용어다. 구글의 네이밍 센스 답게 촌스럽고 귀여운 맛이 있다. 물론, 생긴 것도 구글스러운 모양.

#1 웹킷 기반. V8 이라는 자바스크립트 엔진은 웹킷의 Squirrel Fish 를 모태로 한 것인지 아니면 (Adobe에서 기증 받은 소스로 진행중인) 모질라의 Tamarin 프로젝트를 모태로 한 것인지 명확치 않다. JIT 를 자랑하는 걸 봐선 Squirrel Fish 일 가능성 보다는 Tamarin 일 가능성이 커보인다.

#2 솔직히 웹킷이 빠르긴 한데, Quirks Mode 에서의 관용도는 FF 보다 떨어진다 - 즉 표준에 맞게 짜지 않으면 페이지가 좀 심하게 깨진다 - 고 느낀다. Rendering Engine 도 여기 저기 손 좀 봤을지? gecko 의 복잡 다단한 reflow 로직을 따다 썼을지도 모를 일.

#3 구글 크롬이 과연 웹킷의 어떤 리비전에 기초하고 있을지도 관심이다. 40000 고지를 향해 가파르게 돌진중인 웹킷의 리비전 속도는 실로 놀라울 정도인데, 과연 구글이 웹킷이 현재 구현하고 있는 기능을 어디까지 꺼내 썼을지 모르겠다. ACID3 는 통과 하려나? HTML5의 Video/Audio Element 지원 부분은? client session 구현은 그냥 웹킷에 들어있는 SQLite3 기반 구현을 썼을까?

#3 웹킷의 Official Windows 포팅은 애플 애들 작품이라 Core Foundation 관련 라이브러리에 의존성이 많다. Network 과 Graphic 관련된 부분들이 특히 그렇다. 이 부분을 어떻게 처리했을지가 사실 나는 제일 궁금하다. cairo? gdi? wininet? libcurl? 모든 건 소스를 받아서 들여다보면 알겠지 뭐.

#4 Google Gears 는 좀 욕심이 과하지 않은가- 싶지만, 구글 크롬이 널리 사용되면 gears 도 널리 쓰일 것이고 이래 저래 사람들에겐 좋은 일이 될 것이다.

#5 아키텍쳐적으로 흥미로운 영역은 각각의 탭을 분리된 프로세스로 실행한다는 것이다. 사실 브라우저에서 메모리 관리는 실행 속도에서 상당히 중요한 문제인데, 탭간에 리소스 공유가 많지 않다는 점에 착안해서 모든 탭을 별도 프로세스로 분리해버린 건 모험적이지만 해볼만한 시도로 보인다. 덕분에 각 탭을 sandbox 화 해서 보안을 강화하기 좋아졌고, 심지어 plugin 도 별도 프로세스로 분리해버려서 (Netscape Plugin API 를 container-control로 나누어 구현한다는 컨셉일까?) 보안에 유리해졌다.

#6 '구글' 그 자체를 무기로 내세운 부분도 눈에 띈다. 브라우저의 첫 페이지를 '구글화' 하는 점이야 뭐 그렇다 치더라도, Phishing Filter 를 위한 DB를 구글에서 내려받는다거나- 하는 건 구글이기 때문에 할 수 있는 일일 것이다.

#7내 개인적으로는 Gecko의 XUL 기반 접근이 웹킷의 '무작정 빠르기만한 엔진' 보다는 마음에 든다만- (적어도 XUL Runner 를 통해 이것 저것 재미있는 것들을 해볼 수 있다는 점에서) 구글 친구들이 앞으로 어떤 짓들을 해 나갈지 무척 기대가 된다. 아, 정말, 이럴땐, 구글에서 일하고 싶쿠나. 얼마나 대단한 사람들이 얼마나 대단하게 일하고 있을까. 부럽다.