구글 크롬 뜯어 보기

구글이 브라우저를 출시한다는 소식을 여기저기서 전해 듣고서 저도 이곳에서 다운받아서 설치해 봤습니다. 그런데 그나 저나 난리군요. 미투데이에서 하루만에 현재 시점에서 크롬이라는 태크로 19페이지나 글이 올라올 정도면...

이렇게 난리일 때는 떡밥기사 딱 쓰기 좋죠. ㅋ~~~

아무튼 각설하고 저만의 시각으로 구글 크롬을 낱낱이 뜯어 보도록 하겠습니다.

1. 일단 검색주소(영어로는 omnibox 라고 한답니다) 창 멋집니다. 구글 Korea에서 용어 번역도 잘 해놓은 것 같습니다. 검색도 되고 주소도 입력할 수 있는 곳이란 의미겠죠. 파이어폭스3도 그렇고 IE7도 그렇고 모두 검색창과 주소창을 분리해 놓았었는데. 구글은 거기서 한발짝 더 나아갔습니다. 다음 슬라이드 쇼를 보시면 IE7, 파이어폭스3, 구글 크롬이 어떻게 다른지 확인하실 수 있습니다.

012

역시 검색 회사답게 검색을 무척 강조하고 있습니다. 이 인터페이스를 사용하다 보면 주소를 직접 넣으려다가도 그냥 검색할 것 같습니다. 구글로 검색 트래픽을 더 많이 유입시키는데 더 없이 좋은 UI인 것 같습니다. 물론 사용자 측면에서도 좋긴 하지만요. 마지막 이미지에서 보시듯 구글 크롬이라고 쳤더니 이전에 브라우징했던 페이지들에서 키워드를 추출해서 보여주기까지 합니다. 파이어폭스3에서는 본문 내용까지는 안되고 문서 제목으로는 검색이 됐었죠. 전 검색주소창을 보면서 OLPC(One Laptop Per Child)의 브라우저 인터페이스가 떠오르더군요.

01

2. 제가 개발자라서 만화 형식으로 설명하고 있는 이 책(?)을 읽어 봤는데, 구글 크롬의 가장 큰 특징 중 하나는 탭 하나당 프로세스 하나가 따로 따로 실행된다는 것입니다. 전문 용어로 말하자면 다중 프로세스 architecture라고 할 수 있습니다.

이런 식으로 프로그램의 기본적인 골격을 정하는 것을 architecture 설계라고 하는데요... 구글 크롬 소개 페이지에 구글 크롬의 기술이라고 해서 마치 이런 architecture 가 구글만의 기술인 것처럼 설명하고 있지만 실상은 그렇지 않습니다. 구글 개발자들이 말하고 있는 대로 구글 크롬 브라우저의 설계목표는 안정성, 성능, 보안성이었습니다. 이 세 가지 설계 목표를 달성하기 위해서 고민하다 보면 자연스럽게 구글이 선택한 architecture-다중 프로세스 architecture-를 채용하게 될 가능성이 높습니다.

먼저 성능부터 생각해 보기로 하죠. 보통 성능을 높이기 위해 사용하는 기법 중의 하나가 동시성(concurrency) 를 증가시키는 것입니다. 동시성을 높이기 위한 기법에는 비동기적 처리, 다중 프로세스, 다중 쓰레드 등의 방법이 쓰일 수 있습니다. 그런데 이중에 프로세스라는 녀석을 여러개 띄워서 동시성을 높이려면 프로세스를 생성/유지하기 위한 overhead가 만만치 않아서 주로 큰 단위의 동시 처리에 사용하고, 반면 다중 쓰레드는 그런 overhead 가 작기 때문에 작은 단위의 동시 처리에 사용합니다. 그렇다면 왜 구글 크롬 개발자들은 다중 프로세스 architecture 를 선택했을까요 ?

구글 개발자들이 설명하고 있는 대로 다중 쓰레드를 통해 동시 처리를 할 때는 모든 쓰레드들이 서로 모든 정보를 공유-한 주소 공간에서 수행된다는 뜻-하기 때문에 한 쓰레드가 잘못되면 다른 쓰레드가 영향을 받게 됩니다. 예를 들어 하나의 탭만 잘못 돼도 전체 브라우저가 먹통이 되거나 갑자기 죽어 버리는 일이 발생하게 되는 것이죠. 게다가 한 탭에서 수행되는 페이지에 malware 가 포함되어 있다면 다른 탭의 정보들에 접근할 가능성이 있기 때문에 보안성 측면에서도 좋지 않습니다.

그렇다고 해서 다중 프로세스가 모든 경우에 무조건 좋은 것은 아닙니다. 일단 프로세스를 생성하기 위한 overhead 가 만만치 않은데다, 다중 프로세스로 설계할 경우 메모리도 더 많이 사용하게 됩니다. 그리고 다중 프로세스간에 대용량의 데이터를 공유해야 하는 경우에는 communication overhead 가 상당히 발생하게 됩니다.

그렇지만 이런 단점은 브라우저 application에서는 별 문제가 되지 않을 것입니다. 왜냐면 서로 다른 탭에 있는 페이지를 담당한 프로세스들끼리 서로 communication 할 일도 거의 없는데다 한 탭을 띄우면 비교적 오랫동안 사용자가 띄워둘 것이기 때문에 프로세스를 새로 띄우는 overhead 가 별 문제가 되지도 않을 것입니다. 그리고, 최근 메모리 값이 워낙 싸져서 메모리를 좀 더 많이 사용하는 문제도 그리 큰 문제가 되진 않습니다.

그러니 다중 프로세스 vs 다중 쓰레드를 저울질 해보면서 고민해 보면 자연스럽게 다중 프로세스 architecture 를 택하게 될 것입니다. 다중 프로세스의 장점은 프로세스간의 철저한 보호 및 분리라는 것이고 단점은 비교적 높은 비용인데 장점은 잘 살릴 수 있고 단점은 별 문제될 게 없으니 당연한 결과라고 하겠습니다.

그래서 Architect 인 제가 보건데 구글 크롬 팀이 architecture 설계를 탁월하게 잘했다기 보다는 홍보팀, Product Manager, Engineer 들이 모두 일반 사용자들도 이해하기 쉬운 언어로 자신들의 architectural decision 을 잘 설명하고 있다는 것입니다. 일종의 마케팅의 승리로 봐야할 것입니다.

솔직히 이런 architecture는 어느 정도 경험 있는 소프트웨어 개발자에게 설계할 시간을 충분히 주면 얼마든지 설계할 수 있는 것입니다. 구글 개발자의 탁월한 능력 덕택은 아니라는 것입니다. 우리 나라 개발자들도 이정도는 충분히 해낼 수 있습니다. 한국의 소프트웨어 개발 환경에서 설계한답시고 한 참을 고민한 후에 "아! 이러 이러 해서 다중 프로세스 architecture 로 하기로 했습니다. 이러 이러한 식으로 작동하게 될 것입니다" 라고 말한다면 관리자가 뭐라 할지 모르겠습니다. "그래서 코드 몇 줄 짰는데 ?"라고 묻는 ㅎㄷㄷㄷ 한 관리자가 없다면 다행이겠지요.

저는 차라리 구글이라는 회사의 시스템이 부럽습니다. 세상에 이미 날고 기는 브라우저가 있음에도 그걸 새로 개발하겠다고 제안하고, 그 제안을 받아들여 이렇게 세상에 내놓는 회사 시스템이 부러운 것이죠. 한국의 어느 회사가 새로운 브라우저를 내놓은 생각을 할 수 있을까요 ? 아니 한국이 아니라 다른 나라의 회사라도 마찬가지 일거라 생각합니다. 구글의 막강한 비즈니스 모델 덕택에 개발자들은 웹의 발전과 사용자에게 봉사하겠다는 자신의 비젼을 마음껏 쫓아갈 수 있고, 그러한 개발자들의 열정이 회사의 전략적 방향과 별 어긋나지 않는 회사가 구글이라 생각합니다. 사용자들이 크롬같은 훌륭한 브라우저를 통해 웹을 많이 쓰면 구글로서는 매우 바람직한 것이죠. 크롬 브라우저가 많이 쓰이지 않더라도 브라우저 시장의 전반적인 제품 수준을 높여놓기만 해도 구글로서는 좋은 것이죠. 사용자들은 더욱 웹을 많이 쓰게 될테니까요.

3. 다음으로 크롬 설계 철학 중 "Maximize Contents, Minimize Chrome"이라는 걸 생각해 보겠습니다. 사용자가 사용하는 웹 Application 과 사용자가 보는 Contents를 위한 공간은 최대화하고, Chrome 자체에서 사용하는 공간은 최소화하겠다는 뜻입니다. 크롬의 UI를 보면 과연 철학에 걸맞게 디자인이 됐습니다. 그런데 실상은 이런 식의 UI는 IE7이 먼저 시도했습니다. 물론 크롬은 거기에서 한 걸음 더 나아갔다는 점에서 점수를 줘야겠지만요. 자~ 다음 슬라이드쇼에서 한 번 확인해 보시겠어요 ?

012

어떠세요 ? 브라우저의 UI 가 차지하고 있는 공간을 단순히 한줄 두줄로 표현한다면 파이어폭스3는 6줄, IE7은 4줄, 크롬은 2줄입니다. 정말 많이 고민했을 것 같다는 생각이 듭니다. 특히나 원래 윈도우에 있는 타이틀바까지도 없애버리고 탭과 합쳐 버리는 센스는 정말 대단합니다. ^^ 그렇지만 이런 사상은 이미 IE7에서 시작됐기 때문에 크롬만의 독창적인 것이라고는 말 못하겠지요. IE7 팀보다 그 사상을 더욱 많이 추구한 것이 되겠습니다.

그런데, 저 같은 경우 IE7을 설치하고 나서 메뉴를 찾느라고 헤멘 적이 있었습니다. ALT 버튼을 누른 후에야 나타나는 걸 보고 처음에는 뭐 이런게 다 있어라고 생각했을 정도였기 때문에 일반 사용자들에게 잘 먹힐지는 두고 봐야할 것 같습니다.

그렇지만 구글의 전략 측면에서 본다면 데스크톱 Application 인 브라우저 자체는 잊어 버리고, 그 안에서 실행되는 컨텐츠 즉, 웹 페이지, 웹 Application 에 사용자가 더욱 몰입할 수 있다는 건 상당히 바람직한 UI입니다. 구글 개발자들은 사용자들이 더욱 쾌적하게 웹을 즐길 수 있게 하기 위한 설계라고 말하지만 그 철학은 구글의 일관된 전략과 맞닿아 있는 것이지요.

4. 다음으로 '웹 어플리케이션 바로 가기 만들기'를 생각해 보겠습니다. 이것도 크롬에서 처음 나온 개념이 아닙니다. Windows 에서 아주 오래전부터 '바로가기'라는 개념으로 진작부터 지원해 왔던 개념입니다. 구글의 '웹 어플리케이션 바로 가기 만들기'는 그냥 '바로 가기 만들기'라고 말을 바꿔도 아무런 문제가 될 게 없습니다.

구글은 거기에다 웹 어플리케이션이라는 용어를 더 붙인 것만으로 웹상의 Content 를 단순히 수동적인 정보로만 보지 않고 웹 어플리케이션이라는 시각을 분명히 하고 있습니다. 이 용어만 덧붙여도 사용자들은 단순한 정보가 아니라 일종의 어플리케이션처럼 느껴지는 서비스에서는 이 메뉴를 애용하게 될 것이 분명합니다. Google Calendar, Gmail, Daum 한메일 Express, Google Reader 등 수 많은 웹 Application 들을 바탕화면/시작메뉴/빠른실행 어디에다가도 위치시켜 쓰게 될 것입니다.

기존의 단순한 '바로 가기'는 바탕화면에만 위치했다면 이제 시작메뉴에도 둘 수 있고 빠른 실행에도 둘 수 있으니 웹 Application 과 Desktop Application 은 더욱 그 경계가 모호해 지게 될 것입니다. 거기다 크롬에서 만든 Application 을 실행시키면 다음 그림처럼 이미 실행중인 브라우저 화면에서 뜨는 것이 아니라 독립적인 창에서 실행됩니다. 아래 그림은 크롬 브라우저가 이미 떠 있는 상황에서 크롬으로 만든 Gmail Application을 실행시킨 화면입니다. IE7 에서 Gmail Application을 실행시키면 일반 페이지와 동일하게 이미 실행중인 브라우저에서 새로운 탭이 추가될 뿐입니다.

이 뿐만 아니라 2줄로 되어 있던 크롬 UI는 모두 없어지고 Desktop Application 과 동일하게 타이틀 창만 남게 되어 더 구분이 모호하게 만들어 놓았습니다. 이 모든 것들은 일관되게 사용자들이 웹이 더 많이 사용하도록 하는데 기여하게 될 것입니다.

5. 마지막으로 크롬은 JavaScript Engine 으로 구글이 자체 개발해서 Open Source 로 공개한 V8이라는 Engine을 사용하고 있고, 이 Engine은 기존 JavaScript Engine 보다 수십배 빠르게 JavaScript를 실행한다고 합니다. 구글은 웹 자체를 어플리케이션을 위한 플랫폼으로 보고 있고, 그 플랫폼의 일부인 브라우저에서 JavaScript 를 매우 빠르게 해는 것은 Google 로서는 당연한 선택이라고 할 것입니다.

이상을 살펴 보건데 구글은 일관되게 웹을 어플리케이션 플랫폼으로 보고 있고, 이번 크롬을 출시한 것은 이런 트렌드를 더욱 가속화하기 위한 전략이라고 평가할 수 있을 것 같습니다.

글 다 쓰고 나니 정말 구글은 무서운 녀석이라는 생각밖에 들지 않습니다. 으이구 무셔버라.

마지막으로 짤빵 하나. 크롬에서 최대로 많은 탭을 생성해 봤습니다. 그랬더니 탭 하나의 공간이 아주 좁아져서 어떤 탭에 어떤 내용이 있는지 구분하기가 힘들더군요. 아무래도 탭을 상당히 많이 열어서 사용하는 경우의 사용자 시나리오를 생각하지 못한 듯합니다. 다음 그림에서 IE7과 한 번 비교해 보세요.

역시 하나님은 공평해요 구글이라고 다 잘하라는 법은 없잖아요 ? ㅋㅋㅋ

그리고 집에서는 잘 되는데 회사에서는 이상하게 구글 크롬이 전혀 페이지를 열지 못하더군요. 이유는 왜 그런지 전혀 모르겠구요. 아마 저와 비슷한 현상을 겪으신 분들이 많이 있을 것 같습니다.