크롬북 개발에 참여했던 Jeff Nelson 의 블로그 내용을 번역했습니다. 번역하다 귀찮아짐이 느껴질수록 의역에 치중하고 조금 집중이 될수록 직역에 가깝도록 노력했습니다. 참고되었으면 좋겠습니다.
Inventing Chromebook
2006년 구글에서 일하는 동안 나는 새로운 운영 체제(OS)를 만들 좋은 기회를 가질 수 있었다.
고백하건데 일은 무에서부터 만들어진 것은 아니었다. 당시 많은 "새로운" 운영 체제들이 그러했듯이 리눅스 배포판을 통해서 가다듬어지며 만들어졌다.
이 새로운 운영 체제는 초기에는 구글 OS (Google OS) 라는 코드명이었다. 그리고 2009년까지 일반 사용자에게 구글 크롬 OS, 크롬북, 크롬박스의 제품명으로 공개되어 왔다. 나는 이것을 특허로 만들었고 "기기 전반에 걸쳐 작동되는 네트워크 기반 운영 체제(Network-based Operating System Across Devices)" 특허번호 #8,239,662 로 제출했고 해당 특허는 내가 구글을 떠난 상태인 2012년 8월 7일에 최종적으로 특허 승인을 받았다.
여기 몇가지 크롬북 개발에 관한 흥미있는 이야기들이 있다.
첫번째로, 크롬북 계획은 초반에 구글 경영진으로 부터 거절당했다. 사실 나는 초기 내용을 2006년 7월 초반에 만들었고 경영진들에게 보여주었다. 프로젝트를 시작하기는 커녕, 분위기는 상당히 열의가 없어 보였다. 내 상사는 다음과 같이 투덜댔다. "이걸 가지고 비행기에서 사용할 수 없잖아." 사실 겉모습과 다르게 리눅스 배포판의 골격을 가지고 있었고 여기에 설치한 리눅스 프로그램으로 실행하고 사용할 수 있었다.
두번째로, 구글 OS (Google OS)는 초기에는 크롬을 위해서 만들어지지 않았으며, 크롬 OS (Chrome OS) 라고도 불리워지지 않았다. 초기 버젼은 모두 파이어폭스(Firefox)를 기반이었다. 내가 2006년 첫 버젼을 만들었을 때, 구글은 구글만의 브러우저 개발을 시작하지 않은 상태였고 당시 구글 제품 중에는 크롬(Chrome)이란 이름을 가진 것은 없었다. 2007년에 구글 내부 베타 테스트 버젼의 크롬 내부적으로 배포되어 테스트 된 이후, 크롬이란 이름으로 이어지게 되었다.
세번째로, 크롬북은 확실히 많은 제품 리뷰어들이 삼성 크롬북 모델로 간주하는 것과는 달리 웹 브라우저를 위한 "별도의 기기"로 의도되지는 않았었다. 첫번째 판은 리눅스 배포판을 기반이지만 구글 엔지니어들이 코드 개발을 하는 것을 포함한 많은 작업을 위해 충분하였다. 개인적으로 초기 크롬북을 사용하고 있으며, 매일 1년여동안 개발을 위한 주 기기로 사용했었다. 많은 출장에도 사용했고 비행기에서도 사용하였다.
네번째로, 크롬북의 우선대상은 - 초기에는 - 웹앱 (webapps; 웹기반 앱) 만을 위한 운영 체제는 아니었다. 사실 내가 운영 체제를 만들기 시작할 때 우선대상은 속도에 대한 요구였다. - 짱 빠른(super-fast) 운영 체제를 만드는 것이었다.
왜 짱 빠른(super-fast) 운영 체제를 신경썼는가? 나는 필요이상으로 느리다고 느껴지는 윈도우나 리눅스에 당황했었다. 예를 들어 당시 나의 업무는 구글에 필요한 웹앱을 만드는 것이었다. 그래서 자주 웹브라우저를 재실행시켰고, 코드 개발을 수행하기 위해 브라우저 캐시와 쿠키를 정리하기 위해서 하루에도 수백번도 재실행해야 했었다. 웹 브라우저를 재실행하는 특별히 시간이 걸리는 과정이었다. 보통 IE 든 파이어폭스든, 리눅스 혹은 윈도우 에서든, 30~45초 정도 걸렸고 (크롬은 2006년에는 없었다) 그러나 탐색기에 있는 폴더를 표시하는 것 같은 단순한 작업조차도 불합리하게 느렸고, 즉시 실행되어야 하는 작업들 조차도 몇초가 소요된다. 어떤 시스템에서 몇초 걸리고 어떤 시스템에서는 45초 걸린다면 별로 차이가 없는 것처럼 보일지 모르지만 이러한 지연 시간이 하루에도 수백번씩 일어난다고 한다면, 그 시간들만 다 합쳐도 상당한 시간이 될 것이다.
해결책은 있을까? 전체 작업 운영 체제를 램(주기억메모리)에 옮기는 것이다. 이렇게 전체 운영 시스템을 램에 옮겨 놓아서, 운영 체제 성능에서 가장 큰 병목현상을 만드는 파일 I/O (Input/Output) 즉시 신경쓰지 않게 되었다.
운영 시스템에서 소수 작업만이 CPU 가 집중해서 필요하거나 파일 I/O 에 기인하지 않는 다른 이유의 지연을 만드는 작업도 많지 않다. 전체 운영 시스템을 램에서 돌려서, 이러한 작업들은 운영 체제를 구성하는 수천의 어플리케이션에 대한 별도의 최적화를 실행하지 않으며 즉시 실행되게 되었다. 예를 들어 ~45초 걸리던 파이어폭스는 1초 이내로 실행되게 되었다. 8초 이내 걸리던 탐색기에서 폴더를 보는 작업도 0.01초로 실행되었다. 컴파일링 작업조차 60% 빠르게 되었고 램 상주 파일 시스템의 반복적인 grep [ 리눅스 명령어; 파일 전체를 검색해 일치하는 정규 검색어를 찾아주는 명령어 ] 작업이 인덱스 없이도 15초 이내 가능했었다. 하드디스크를 사용해 한다면 어떻게 될까?
크롬북의 초기 버젼의 램 상주 구조를 이야기할 때, 거의 대부분이 데이터 손실에 대해서 우려를 표한다. 사실 데이터 손실은 몇가지 이유로 문제가 되지 않는다. 우선 많은 작업은 웹앱으로 작동하기 때문에 웹앱이 잘 만들어졌다면 데이터 손실의 위험이 거의 없다. 다른 이유는 내가 내 IDE(개발환경) 를 네트워크 드라이브에 자동 저장 옵션으로 설정하면, 시스템 충돌이 일어날 때도 단지 몇초의 작업 내용만 잃어버리게 된다. 마지막으로 몇몇 버젼의 경우 종종 로컬 저장 매체에 동기화하여 백업하는데, 이런 경우와 부팅 중을 제외하고는 운영 체제는 동적 램 (dynamic RAM) 을 제외하고 거의 로컬 저장 매체을 사용하지 않게 된다.
램 상주 운영 시스템을 돌리는 것은 새로운 도전을 제시해주었다. 우선 거대한 크기의 어플리케이션을 설치하는 것을 피해야했다. 거대한 크기의 어플리케이션이 수 기가바이트의 하드디스크를 차지하는 것은 부담스럽지 않지만 수 기가바이트의 램을 차지하는 것은 쉽지 않다. 이런 어플리케이션은 기능은 살리며 웹앱으로 대체해서 피할 수 있다.
두번째로, 많은 소프트웨어 제조사는 리눅스를 전혀 지원하지 않는다. 이또한 웹앱을 통해서 대체될 수 있게 해야 했다.
이렇게 컴퓨터 작업에서 일반적으로 볼 수 있는 모든 기능들을 웹앱으로 대체할 수 있도록 만드는 것이 우선순위가 되었다. 이런 이유로 처음에는 HTML 으로 만들어지고 파이어폭스에서 돌아갔다고 할지라도 [ Chromium 작업환경 ] 에서 웹앱들이 만들어져 확산될 수 있게 되었다.
램에 front-end [ back-end 를 뜻하는 백업, 데이터베이스 시스템과 달리 실제 사용자가 작업하는 환경을 front-end 라 부른다 ] 운영 시스템 전체를 올려놓고 사용하는 방식은 현대 운영 시스템 구조가 어디로 가야하는지를 알려주는 근본적인 변화가 될 것이다. 나는 이런 방식이 가져오는 효과가 비용을 능가하게 될 것이라 확신한다. 우리가 앞으로 살면서, 살아가며 온라인으로 연결된 우리들은 본체에 붙은 키보드처럼 한 컴퓨터에만 저장될 필요가 있는 자원(자료)은 거의 없게 될 것이며, 이런 자료는 자기 플랫터 (하드 디스크) 를 돌려 접근할 필요가 없을 것이다. (하드 디스크를 사용할 필요가 없어질 것이다.)
0 comments:
Post a Comment