- 1 -

All about google!

구글이 가진 독특함과 돋보임(remarkable)은 최근 IT 업계의 뜨거운 감자이자

흥미로운 이야깃거리이다. 아무리 그렇다 한들, 마소에서 하나의 툴이나 제품이 아닌

벤더를 주제로 특집을 진행한다는 것은 이례적인 일이다. 그것은 IT 업계에서 구글이

가진 의미와 가치가 남다를 뿐 아니라 개발자들의 열광적인 지지를 받으며 전파된

현상에 대해 분석해볼 필요가 있다고 판단했기 때문이다. 이번 특집을 통해 구글이

얼마나 막강한 에너지를 가지고 있는가에 대해 조금이나마 느낄 수 있기를 바란다. 또

하나의 거대 독점 기업이 될지도 모른다거나 무차별적인 정보 수집으로 인한

파놉티콘(원형 감옥)의 폐해를 일으킨다는 구글을 향한 비판도 함께 생각해 봐야 할

것이다.

특집 1 부 | 개발자, 구글 신드롬에 빠지다

특집 2 부 | 성공의 원천, 탄탄한 기술 인프라 대해부

특집 3 부 | 구글의 숨은 경쟁력 운영과 마케팅

특집 4 부 | 구글의 이면, 최강의 해킹 툴

특집 5 부 | 리얼가상 스토리 ‘빽투더 구글 퓨처’

특집 1 부 개발자, 구글 신드롬에 빠지다

박재호 | 임베디드 소프트웨어 개발자

요즘 들어 IT 전문 매체는 물론 일반 대중 매체에서도 ‘구글’이라는 이름이 심심치

않게 등장하고 있다. 이미 구글에 익숙한 개발자를 중심으로 구글의 실용성과

편리함이 입소문으로 서서히 퍼져나가면서 일반 사용자까지 영향을 미치기 시작한

것이다. 그러나 과거 국내 대형 포탈 사이트에 눌려 꼼짝하지 못하던 구글이 자고

일어나보니 갑자기 유명해졌을 리는 만무하다. 그렇다면 현재의 ‘구글 신드롬’은

어떻게 해석해야 할까.

- 2 -

1970 년대 초 유닉스 운영체제가 처음 등장한지 벌써 30 년이 지났지만 여전히 수많은

개발자가 유닉스(또는 유닉스와 비슷한) 운영체제를 사용해서 필요한 작업을 처리하고

있다. 큰 이변이 없는 이상 이런 추세는 구식 유닉스의 시간 측정 단위에 사용하는

32 비트 값을 다 채우는 2038 년 1 월 19 일까지(여기에 대한 세부적인 설명은

en.wikipedia.org /wiki/Unix_epoch 를 참조하기 바란다) 계속 이어질 것이다. 지금까지

어떤 운영체제도 달성하지 못했던 어마어마한 기록을 유닉스는 계속해서 갱신하고

있다. 이렇게 유닉스에 대해 충성심을 보이는 개발자가 많은 이유를 여러 가지

측면에서 분석할 수 있겠지만 작고 간결한 유틸리티를 묶어서 복잡한 작업을 수행할

수 있게 만드는 이른바 ‘작은 것이 아름답다(small is beautiful)’와 ‘각 프로그램마다

제대로 된 임무를 하나씩 맡겨라(Make each program do one thing well)’는

철학(유닉스 철학은 en.wikipedia.org/wiki/ Unix_philosophy 참조)이 밑바닥에

깔려있다.

현재의 구글의 이면에도 이와 비슷한 원칙이 자리잡고 있다. 구글이 1990 년대 말

처음 등장했을 때 온갖 화려함과 다양한 기능을 무기로 일반 대중을 휘어잡고 있었던

여러 포탈 사이트를 능가하리라고는 상상조차 하지 못했을 것이다. 하지만 구글은

독립적이면서도 제대로 동작하는 기능을 차츰차츰 늘여가면서 세력을 넓혔으며 시간이

지남에 따라 모든 내용을 통합해나가던 기존 포탈 사이트와는 달리 오히려 정반대의

전략, 즉 더 단순해야 한다는 초심을 잊지 않고 있다. 이런 자신감을 바탕으로

개발자는 물론이고 일반 사용자조차 가장 좋아하는 검색엔진으로 확실하게

자리매김했다. 즉 유닉스를 지금까지 버티도록 만들어 놓은 기본 철학을 구글이

검색엔진 부문에서 그대로 계승하는 방식으로 새로운 ‘블루오션’을 창출한 셈이다.

그렇다고 구글이 검색엔진 한 분야에만 집중적으로 우물을 판다는 이야기는 아니다.

구글이 나오기 훨씬 전부터 검색엔진 부문에서 한 시대를 풍미했던 알타비스타,

라이코스의 경우에는 기술적인, 상업적인 관점에서 직접 수익으로 연결할 수 있는

성장 모멘텀을 찾지 못하고 주저앉아 버렸지만 구글은 실험적인 다양한 프로젝트를

지속적으로 주류 서비스에 편입시키면서 끊임없는 성장 동력을 얻고 있다. 물론 이런

성장 동력 이면에서는 애드워즈(AdWords)와 애드센스(AdSense)라는 강력한 캐시

카우(cash cow)가 버티고 있음은 물론이다.

지난 구글의 성장 역사는 그 자체로도 매우 흥미롭지만 창고에서 시작한 이후 나스닥

상장까지 쾌속 순항을 마친 다음에도 고삐를 늦추지 않고 계속해서 검색 서비스를

개선하고 색인 숫자를 늘이고 수익 창출을 위한 애드워즈와 애드센스 시스템을 개선해

- 3 -

온 점이 더욱 특징적이다. 구글 Quick Profile(www.google.com/intl/en/cor

porate/tech.html)과 ZDNet UK(insight.zdnet.co.uk/hardware/

servers/0,39020445,39175560,00.htm)에는 구글과 관련된 재미있는 숫자들이 공개돼

있다.

• 이 글을 쓰는 현재 구글은 웹 페이지 81 억 6,868 만 4,336 개를 색인했다.

• 구글은 HTML, PDF(PDF), PS(포스트스크립트), 로터스 1-2-3, 맥 라이트, XLS(엑셀),

PPT(파워포인트), DOC(워드), WRI(마이크로소프트 라이트), RTF(RTF), SWF(플래시),

TXT(일반 텍스트) 방식을 인식해서 색인할 수 있다.

• 현재 구글 이미지는 20 억 개를 색인하고 있다.

• 유즈넷 메시지는 10 억 개를 색인하고 있다.

• 100 여 개 언어 검색을 지원하며 35 개 나라말로 시작과 결과 홈페이지를 보여준다.

• 구글 트래픽의 50% 이상이 미국 이외 지역에서 일어난다.

• 구글은 2005 년 6 월 30 일 기준으로 직원이 4183 명으로 (놀랍게도) 대다수가

기술/공학 부문 종사자이다.

• 2004 년 기준으로 구글은 클러스터당 PC 2000 대를 할당하고 있으며 이런

클러스터가 모두 30 개 존재한다.

• 2004 년에 비해 2005 년 색인 숫자가 두 배로 늘어났기에 클러스터 숫자도 거의 두

배 가까이 늘어났을 가능성이 높다.

• 클러스터당 1 페타바이트(2 의 50 승이나 근사 값으로 10 의 15 승, en.wikipedia.

org/wiki/Petabyte) 용량을 사용하므로 표준 하드디스크 오류 발생률인 10 의 15 승이

실제로 심각한 영향을 끼치기 시작한다. 또한 일반 조립 PC 를 사용하고 있기에 각

클러스터마다 매일 PC 두 대 가량이 하드웨어에 문제를 일으킨다. 그럼에도 불구하고

2000 년 2 월 이후에 한번도 전체 시스템 장애를 겪지 않았다. 특정 시스템이

붕괴되더라도 근접 시스템이 백업으로 동작할 수 있도록 되어 있기 때문이다.

• 구글 색인 클러스터는 지구상에 현존하는 가장 강력한 병렬 컴퓨팅 프로젝트로

2004 년 기준으로 박사급 인력 200 여 명과 기타 인력 600 여 명이 이 프로젝트에만

매달려 있다.

• 구글 색인 크기는 웹 페이지당 평균 10KB 를 차지하므로 80 억 페이지를 유지하기

위해서는 색인에만 80TB 가 필요하다.

• 이 모든 기술적인 복잡성에도 불구하고 최종 사용자는 단어를 입력한 다음에 ‘운

좋은 예감’ 버튼을 누르면 대부분 원하는 페이지로 이동한다.

개발자는 왜 구글에 열광하는가

- 4 -

1999 년에 처음 필자가 구글 검색엔진을 접하고 나서 느낀 감정은 바로 ‘이거다’라는

한 마디로 압축할 수 있다. 실제로 개발이나 저술 활동 과정에서 어려움이 발생할

경우 구글에서 검색하면 정밀 유도 폭탄처럼 원하는 자료를 첫 몇 페이지 이내 범위에

정확하게 찾을 수 있었기 때문이다. 알타비스타처럼 똑같은 문서를 순위와 무관하게

장황하게 제시하지도 않았고(단 요즘 서비스 중인 알타비스타 우선순위 기법은 상당히

정확해졌다) 야후처럼 디렉토리 위주로 유명한 사이트만을 제시하지도 않았으며 찾은

페이지 범위와 속력이 타의 추종을 불허하는 구글에 끌리지 않으면 오히려 이상하지

않은가.

물론 일반 사용자라면 포탈에서 수작업으로 골라 놓은 뉴스 헤드라인이나 사용자

참여와 같은 방법을 동원해서 구축해놓은 지식검색, 카페, 블로그 검색에 눈길이

갈지도 모르겠다. 하지만 일반적으로 널리 알려진 자료가 아니라 자신만의 특수한

관심사나 복잡한 문제 해결을 위한 자료 검색 과정에서는 일반 상식에서 벗어난 자료

검색이 필수적이므로 구글과 같은 강력한 검색엔진을 쓸 수밖에 없는 상황이 종종

생기기 마련이다. 이런 상황에서 주변에 있는 개발자에게 포탈 사이트 이외에 사용할

수 있는 검색엔진을 추천해달라고 하면 어떤 대답이 나올까. 이미 구글에 맛을 들인

개발자라면 열이면 열 모두 ‘구글’이라고 합창할 것이다.

그렇다면 개발자들이 구글을 좋아할만한 요소에는 무엇이 있을까. 구글 소프트웨어

개발 철학부터 시작해서 구글 개발자 문화에 이르기까지 다양한 개발자 지원

프로그램을 살펴봄으로써 개발자가 구글에 대해 열광하는 이유를 하나씩 벗겨 보자.

매력적인 구글 소프트웨어 원칙

개발자도 결국에는 구글이 개발한 소프트웨어를 사용하는 최종 사용자다. 따라서

구글의 소프트웨어 개발 철학에서 논의를 시작해 보자. 구글이 밝히는 설치형 구글

소프트웨어 원칙(www.google.com/cor porate/software_principles.html)은 다음과

같다.

• 설치 : 사용자를 속이면서 소프트웨어를 설치하지 않아야 한다. 소프트웨어를

컴퓨터에 설치하는 과정에서 거부할 수 있어야 하며 다른 소프트웨어 설치 과정에서

- 5 -

끼어들어서도 안 된다.

• 솔직한 소개 : 소프트웨어를 설치하거나 활성화할 경우에 주된 기능을 알려줘야

하며 광고를 통해 돈을 벌어들일 경우 이런 사실을 설명해야 한다. 스크롤바를 한참

돌려야 나오는 숨겨진 곳에 이런 사실을 밝히지 말고 가장 눈에 잘 띄는 곳에

보여줘야 한다.

• 단순한 제거 : 소프트웨어를 비활성화하거나 삭제할 경우에 손쉬운 방법을 제시해야

한다. 응용 프로그램의 모든 기능을 제거해야 하며 삭제된 이후에 다른 응용

프로그램을 동작시킬 경우 동작해서는 안 된다.

• 명확한 동작 방식 : 사용자 환경 설정을 변경할 경우에 이런 변경을 가하는 이유에

대해 명확하게 설명해야 한다. 일례로 응용 프로그램이 윈도우를 열 경우에 어떤 응용

프로그램이 열었는지 확실하게 알려줘야 하며 광고를 보여줄 때도 주체가 누구인지

알려줘야 한다. 또한 사용자 환경 설정을 변경할 경우에는 반드시 명시적으로 이런

사실을 사용자에게 통보해야 한다.

• 훔쳐보기 : 응용 프로그램이 개인 주소와 같은 정보를 수집해서 전송할 경우

사용자에게 알려야 한다. 정보를 수집해서 전송한다는 사실을 명시적으로 알리고

동의를 구해야 한다.

• 좋은 회사 만들기 : 응용 프로그램 제공자는 상기 가이드라인을 어기는

소프트웨어를 함께 포함시켜 배포하지 않아야 한다. 여러 가지 응용 프로그램이

동시에 설치될 경우에 사용자에게 각 소프트웨어가 무엇인지 알려줘야 한다.

이것은 구글이 제작한 구글 툴바나 구글 데스크탑 검색엔진과 같이 배포형

소프트웨어뿐만 아니라 구글 툴바 팝업 제거 기능(www.

google.com/corporate/nopopupads.html)이나 구글 페이지 랭크와 같은 기능에도

모두 동일하게 적용되고 있다. 개발자를 짜증나게 하는 엉터리 소프트웨어나 한 술 더

떠서 해를 끼치는 악성 소프트웨어를 퇴치하려는 이런 시도 때문에 개발자는 구글에

높은 점수를 주지 않을까.

다양한 API 지원

- 6 -

웹 관련 프로그램을 개발하다보면 다른 웹 사이트가 동적으로 생성한 결과를 이용해야

하는 경우가 생긴다. 보통 스크래핑이라고 부르는 기법을 사용해서 해당 사이트에서

읽어온 HTML 코드의 특정 패턴을 인식한 다음에 필요한 부분만 간추려오는데

여기에는 두 가지 문제점이 있다. 하나는 저작권 침해이며 다른 하나는 URL 규칙이나

생성된 페이지가 변동될 때마다 프로그램을 뜯어 고쳐야 한다는 것이다. 이럴 때

외부로 API 를 공개해서 스크래핑보다 강력한 개발 환경을 제공해주면 개발자

입장에서 얼마나 즐겁고 행복할까. 놀랍게도 구글은 구글

코드(code.google.com/index.html) 사이트를 통해 이 일, 즉 API 를 지원하고 있다.

현재 구글에서 지원하는 API 는 애드워즈, 블로거, 데스크탑 검색, 데스크 바, 프루갈,

gmail, 구글 그룹, 구글 어스, 맵(지도), 뉴스, 구글 토크, 구글 비디오, 웹 검색 등이

있다.

『구글 해킹』을 보면 구글 웹 검색 API 를 이용해 여러 가지 흥미로운 프로그램을

개발하고 있음을 알 수 있다. 물론 API 자체가 가치중립적이므로 흥미를 넘어 오용은

물론이고 악용까지 할 수 있지만 구글은 이런 악용을 방지하기 위해 개발자 등록

절차를 거쳐 키를 발급하고 현재까지는 하루에 질의를 1000 번만 가능하도록 만들어

놓았다. 이 가운데 대표적인 API 를 간추리면 다음과 같다.

• 구글 웹 검색 API : 대표적인 구글 API 로 표준 XML 기반의 SOAP 기술을 사용한

검색용 웹 서비스이다. 구글로 넘기는 옵션만 올바르게 이해하고 있다면 쉽게 응용

프로그램이 구글에 질의를 던지고 결과를 받을 수 있다.

• 구글 데스크탑 API : 구글 데스크탑 응용 프로그램이 기본 파일과 전자편지 형식

이외에 다른 파일 형식도 검색할 수 있는 플러그인을 만들도록 도와주는 API 집합이다.

시중에 존재하는 파일 형식이 워낙 많기 때문에 자발적인 개발자 지원을 이끌어 낼 수

있도록 구글에서는 플러그인을 작성해서 제출하는 개발자에게 티셔츠를 기념품으로

주고 있다.

• 구글 애드워즈 API : 구글 애드워즈 서버와 직접 통신할 수 있게 해주는 API

집합이다. 자동 키워드, 광고 문구, URL 을 생성하거나, 애드워즈를 독자적인

데이터베이스 시스템과 연동할 수 있게 만들어서 광고 시스템을 자동화할 수 있게

만들어준다.

- 7 -

구글과 흡사하게 웹 서비스를 공개하는 있는 다른 업체도 있다. 바로 아마존닷컴이다.

아마존닷컴은 자사 데이터베이스를 외부에서 등록하고 검색할 수 있도록 SOAP 기반

AWS(Amazon Web Service,

www.amazon.com/gp/browse.html/ref=smm_sn_aws/102-3808645-

3805716?%5Fencoding=UTF8&node=3435361)를 제공하고 있다. 아마존 전자상거래

서비스(E-Commerce Service)를 통해 제품을 웹 사이트에 올리고 관리할 수도 있고

일반 응용 프로그램을 통해 아마존닷컴에 접속하도록 만들 수도 있다. 맥 OS X 용

서적 관리 시스템인 Books 는 <화면 3>과 같이 AWS 인터페이스를 사용해서

아마존닷컴에 접속한 다음 ISBN 으로 정보를 물고 온다.

한편 구글이 개발자를 위한 지원을 아끼지 않고 있는 상황에서 최근

마이크로소프트(이하 MS)가 견제구를 슬쩍 던져봤다. 씨넷에 따르면 향후 MS 는 MSN

검색 서비스를 위한 SOAP 기반 API 를 제공해서 외부 개발자가 이와 연동해서

프로그래밍할 수 있도록 할 것이라고 한다. 구글 웹 API 와 마찬가지로 하루에 던질 수

있는 질의 숫자는 제한이 있으며 비상용 고객일 경우에 1 만개를 예상하고 있다.

구글의 오픈소스 지원정책

요즘 기업마다 오픈소스를 지원하느라 정신 없는 상황이다. 애플과 같은 회사조차도

맥 OS X 코어인 다윈을 오픈소스 프로젝트로 공개하는 상황이니 다른 회사는 두말할

필요도 없다. 구글 역시 API 공개를 통해 외부 응용 프로그램 개발을 장려하는 한편

오픈소스 프로젝트를 직/간접으로 지원함으로써 개발자를 포섭하고 있다.

앞서 API 와 마찬가지로 구글 코드(code.google.com/index.html) 사이트에서 오픈소스

프로젝트(code.google.com/projects.html)를 소개하고 있다. 구글과 직접적으로 관련

있는 프로젝트는 물론이고 구글 관련 소프트웨어를 개발하면서 갈라져 나온

프로젝트도 올라와 있으니 관심있는 독자들은 방문해보기 바란다. 현재 구글에서

지원하고 있는 오픈소스 프로젝트는 애드워즈 API 클라이언트 라이브러리, AjaxSLT,

Coredumper, 구글 mMAIM, 스파스 해시 테이블, 사이트맵 생성기, Kongulo,

Goopy/Functional, Perftools 등이 있다.

- 8 -

• 애드워즈 API 클라이언트 라이브러리 : 구글 광고 서비스인 애드워즈 계정에 쉽게

접근할 수 있도록 자바 클라이언트를 작성하는 데 필요한 라이브러리 집합이다. BSD

라이선스 모델을 따르고 있다.

• AjaXSLT : AjaXSLT 는 자바스크립트로 구현한 XSLT 이며 gmail 과 같은 화려한 AJAX

응용 프로그램을 개발하는 데 사용한다. 역시 BSD 라이선스 모델을 따르고 있다.

• Coredumper : Coredumper 는 프로그램이 돌아가는 가운데 다중 쓰레드

프로그램에서 GDB 가 읽을 수 있는 코어덤프를 생성하는 산뜻한 프로그램이다.

C/C++로 만들어져 있으며 포직스 시스템에서 동작하며 BSD 라이선스 모델을 따르고

있다.

• 구글 mMAIM : mMAIM(MySQL Monitoring And Investigation Module)은 MySQL

서버를 감시하고 분석하는 작업을 쉽게 만들어주는 파이썬 기반의 라이브러리이다.

라이선스 모델은 LGPL 을 따르고 있다.

• 스파스 해시 테이블 : 스파스 해시 테이블은 구글에서 사용하는 다양한 해시 맵

구현을 포함하고 있다. SGI 에서 만든 hash_map 클래스와 비슷하지만 성능이나 공간

최적화 측면에서 더 효율적인 성능을 보여준다. C++로 만들어져 있으며 BSD

라이선스 모델을 따르고 있다.

• 사이트맵 생성기 : 파이썬으로 만든 이 스크립트는 웹 서버를 분석해 사이트맵

파일을 생성한다. 이 파일은 운영 중인 웹 서버의 내용을 XML 목록으로 만들어서

구글에 제출할 수 있게 해준다. 라이선스는 BSD 이다.

• Kongulo : 구글 데스크탑 검색을 위한 간단한 플러그인으로 만들어진 이

소프트웨어는 간단한 웹 스파이더이다. 지정한 인트라넷 웹 사이트를 돌아다니며 지역

데스크탑 검색에서 사용할 수 있게 색인을 걸어준다. 파이썬으로 만들어졌으며

라이선스는 BSD 이다.

• Perftools : 어마어마하게 빠른 malloc 구현이며 쓰레드와 STL 과도 잘 붙는다.

사용자 편의성을 높인 힙 점검 장치와 프로파일러를 탑재하고 있다. C 와 C++로

만들어져 있으며 포직스 시스템에서 동작하며 BSD 라이선스를 따르고 있다.

이와 같은 오픈소스 이외에도 구글은 다음과 같은 몇몇 오픈소스 관련 프로젝트를

지원하고 있다.

- 9 -

• 파이어폭스 지원 : 대표적인 오픈소스 프로젝트인 파이어폭스 사용자를 위해 구글이

선물 보따리를 준비했다. 바로 파이어폭스용 확장(toolbar.google.com/firefox

/extensions/)이다. 현재 구글 툴바, 구글 SMS(안타깝게도 미국에서만 쓸 수 있다),

구글 서제스트(suggest)를 제공하고 있으며 앞으로 숫자가 늘어날 것으로 보인다.

또한 파이어폭스 초기 화면(www.google.com/firefox?client=firefox-

a&rls=org.mozilla:ko-KR:official)도 예쁘게 만들어서 제공함으로써 파이어폭스를

간접적으로 지원한다.

• 위키피디아 호스팅 : 요즘 신문 뉴스 기사보다 인기가 좋다고 알려진 오픈소스

개념의 백과사전인 위키피디아 호스팅을 구글에서 지원하겠다는 제의가

있었다(meta.wikimedia.org/wiki/Google_hosting). 기존 지원 업체와 맞물려 미묘한

문제가 걸려 있어 아직 확정되지는 않았지만 만일 구글에서 위키피디아를 본격적으로

지원해줄 경우에 기존 아마추어 위주로 운영되고 있는 지식 검색에 일대 변혁을

일으킬 것으로 보인다.

• 구글 특수 분야 검색 : 구글에서는 리눅스, BSD, 매킨토시, MS 윈도우와 같은

개발자를 위해 특수 분야만 검색할 수 있는 인터페이스(www.google.com/options

/specialsearches.html)도 제공하고 있다. 특히 리눅스와 BSD 를 별도 항목으로

분리시켜 놓은 정책은 오픈소스 위상을 높여주기에 무척 고무적이라고 할 수 있다.

참고로 주류에 속하는 MS 윈도우 분야 검색은 오히려 최근에 들어왔다.

구글 개발자 문화

과거에는 소프트웨어 개발자라면 누구나 한번쯤 MS 에서 근무하는 꿈을 꾸곤 했었다.

부족함이 없는 멋진 환경에서 뭔가 쿨한 일을 한다는 느낌도 좋았고 잘하면

백만장자가 될지도 모른다는 꿈도 꾸면서 말이다. 하지만 이제는 MS 도 구글에 왕관을

넘겨줘야 할 때가 다가온 느낌이다.

제품은 조직을 닮아간다는 말이 있듯이 개발자 입장에서 일하기 좋은 회사가 십중팔구

좋은 제품을 만들어 낼 가능성이 높으므로 요즘 한창 관심의 대상으로 떠오르는 구글

내부의 개발자 문화를 살펴보는 방식으로 간접적으로 구글 열풍을 감지해보도록 하자.

잠재적인 개발자를 키우는 여름방학 코드 짜기부터 시작해서 구글이 말하는 ‘구글에서

일해야 하는 10 가지 이유’를 살펴보자.

- 10 -

여름 방학 코드 짜기

앞서 구글과 오픈소스 프로젝트에 대해 설명했다. 구글은 직접 오픈소스 소프트웨어를

만들기도 하고 다른 오픈소스 프로젝트를 지원하기도 하는데 학생들로 하여금

오픈소스 개발 세계를 소개하는 프로그램인 여름 방학 코드 짜기(Summer of Code,

code.google.com/ summerofcode.html) 프로그램을 후원하고 있다. 구글은 여름

방학이 끝날 때까지 프로젝트를 성공리에 완성한 학생에게 총 4500 달러라는 거금을

제공하며 여러 오픈소스 공동체에서는 현재 진행 중인 프로젝트 가운데 학생들이

붙어서 풀만한 문제점이나 개선점을 추려내 아이디어를 제공하고 멘터링 서비스를

운영하는 방법으로 실제 오픈소스에 공헌이 가능하도록 프로젝트 진행을 도와준다.

이번 여름 방학 코드 짜기 프로젝트에 참가한 오픈소스 멘터링 조직을 보면 단순히

시간 때우기용 프로젝트와는 거리가 멀다는 느낌이 올 것이다. 대표적인 몇몇 단체를

예로 들어보면 아파치 재단, 페도라 코어, FreeBSD, 가임, 그놈 재단,

Handhelds.org(임베디드), KDE, 모노 프로젝트, 모즈데브(모질라), 오픈오피스, 펄

재단, 파이썬 소프트웨어 재단, 삼바, 서브버전, 우분투 리눅스, 와인 프로젝트 등이

있다. 이 정도면 웬만한 핵심 오픈소스 단체가 모두 참가했다고 봐도 틀린 것이

아니다. 여름 방학이 끝날 무렵 성공했거나 실패했거나 상관없이 학생들이 오픈소스

개발 모델에 대해 어느 정도 감을 잡을 수 있기 때문에 앞으로 자라나는 개발자를

확보한다는 측면에서 이런 프로젝트 후원은 매우 의미 있다.

구글 신입 모집 광고

MS 에 입사할 경우 치러야 하는 코딩 인터뷰는 악명이 높다. 조엘 온 소프트웨어

20 장을 보면 알겠지만 구체적으로 칠판에 프로그램을 짜면서 인터뷰를 해야 한다.

하지만 구글은 한술 더 떠서 수학적인 사고방식으로 무장하지 못한 개발자라면 입사

원서조차 내지 못하도록 조치를 취했다. <화면 6>과 같이 수학 문제를 내놓은

빌보드가 등장하면서 여러 온/오프라인 매체들이 일제히 빌보드의 정체에 대해 기사를

실었으며 매스메티카로 유명한 울프람리서치에서도 MathWorld 헤드라인 뉴스로 이를

다루기도 했다. 스스로 수학을 어느 정도 잘 한다고 생각하는 개발자라면 MathWorld

- 11 -

웹 페이지(mathworld.wolfram.com/news/2004-10-13/google)에 접속해 도전해 보기

바란다.

구글이 이처럼 신입 모집 광고부터 튀는 개발자를 찾아내려고 노력하는 이유는 혁신을

위한 창의성을 발휘할 수 있는 사람을 뽑으려고 하기 때문이다. 단순히 수학이

중요하다기보다는 문제를 해결해 나가는 과정과 기발한 생각을 중요하게 생각하는

것이다. 이렇게 스스로 문제를 알아서 풀어가는 개발자가 많아야 구글 랩과 같은

프로젝트를 원활하게 유지해서 향후 성장 동력을 마련하는 초석을 닦을 수 있다.

구글에서 일해야 하는 10 가지 이유

요즘과 같이 경쟁이 치열한 상황에서 각 회사마다 유능한 사람을 뽑기 위해 내세우는

특장점이 있다. 어려운 수학 문제까지 풀어가면서 구글에 입사하려고 애를 쓰는

개발자가 한 둘이 아니라는 사실은 구글에 무언가 특별한 것이 있다는 것이다. 그

정체를 정확하게 규명할 순 없으나 구글이 직접 제시한 10 가지 이유에서 힌트를

발견할 수는 있다.

1. 상부상조 : 위대한 삶을 살기 위해 필요한 정보를 사람들에게 제공한다.

2. 인생은 아름다워 : 리마커블한 제품 개발

3. 감사는 최고의 동기 부여책이다 : 구글의 직원 지원 프로그램 참조

4. 놀이와 일은 별개가 아니다.

5. 종업원을 사랑하며 이런 사실을 알기를 바란다.

6. 혁신이 생명줄이다 : 정보 처리 부문에서 최고를 지향한다.

7. 어딜 보더라도 좋은 동료가 있다 : 다양한 부문에 걸쳐 온갖 경력으로 무장한

친구를 찾을 수 있다

8. 세계를 하나로 묶는다 : 모든 국가와 모든 언어를 지원한다.

- 12 -

9. 아무도 간 적이 없는 신세계로 용감하게 나가자 : 풀어야 할 수많은 난제가 있다.

여기서 수많은 사람을 기쁘게 해줄 창조적인 신제품을 만들 기회를 얻을 것이다.

10. 공짜 점심과 같은 선물이 있다 : 구글 식당은 품질이 높기로 유명하다. 최근 구글

식당의 수석 요리사가 그만둔다고 해 새로운 요리사를 구하기 위해 난리가 났었다.

국내에서 바라보는 구글

지식 검색부터 시작해서 쇼핑까지 포탈 사이트 내에서 모든 작업을 처리하기를 원하기

때문인지 국내에서는 검색 서비스만 전문적으로 제공하는 구글의 지명도는 그다지

높지 않았다. 하지만 요즘 들어와서 갑자기 ‘구글’이라는 단어가 언론에 많이

오르내리고 있는데 구글 뉴스로 검색해봐도 이런 현상을 어렵지 않게 감지할 수 있다.

그렇다면 띄엄띄엄 나오던 구글 이야기가 최근 들어 상당히 밀도 있게 전개되고 있는

이유는 무엇일까.

흥미롭게도 국내에서 구글이 유명해진 이유는 기술적인 문제가 아니라 사회적인

문제로 볼 수 있다. 아무리 뛰어난 기술일지라도 결국에는 사용하는 문맥에 따라 약이

될 수도 있고 독이 될 수도 있기에 사회적인 문제를 결코 흘러 넘길 수 없다. 하지만

언론에서 너무 흥미 위주로 접근하는 과정에서 구글의 부정적인 측면을 확대 재생산할

수도 있기에 지나친 반 기술주의 움직임과 관련해 부작용을 경계해야 한다. 오해를

불러일으킨 부분에 대해서는 구글에게도 변명의 기회를 줘야 하지 않을까.

주민등록번호와 구글

개발자 입장에서 주민등록번호만큼 강한 유혹을 던지는 개인정보는 없을 것이다.

국가적으로 공인한 유일한 키(unique key)이자 손쉽게 다른 정보에 접근할 수 있기에

외부 키(foreign key)가 될 수도 있기 때문이다. 주민등록번호와 실명만 알고 있으면

인터넷에서 개인의 신원을 위조할 수 있으며 집/회사 주소나 전화번호를 비롯해 다른

여러 가지 신상 정보 역시 모두 주민등록번호라는 메타 정보를 활용해서 얻을 수

있기에 일단 주민등록번호가 외부에 유출되면 골치 아픈 일이 생길 가능성이 높아진다.

- 13 -

그런데 일부 언론에서 구글을 주민등록번호 유출의 주범으로 몰아가는 웃지 못할

상황이 벌어지고 있다. 구글 검색엔진이 너무 강력하기 때문에 지인 이름만 입력하면

주민등록번호를 필두로 전화번호부터 콘도 예약 기록까지 모두 나오기 때문에 이를

국가적인 차원에서 막아야 한다는 주장이다. 실제로 국내 유명 포탈 사이트들은

주민등록번호처럼 보이는 정보를 색인하지 않도록 자체 검열을 실시하고 있기에

상대적으로 이런 문제에서 자유롭다. 그렇지만 구글에 대한 대안으로 논의되는 것들을

보면 ‘언발에 오줌누기’라는 생각이 머리 속을 떠나지 않는다.

물론 보여주지 말아야 하는 정보를 보여주기 때문에 잘못됐다는 논리는 정말 단순

명쾌하다. 그러나 본질적인 문제는 업계의 관례다. 실명을 반드시 확인해야 하는

금융권이나 전자정부 사이트라면 주민등록번호라는 개인정보를 필요악으로 수집할

수밖에 없겠지만 나머지 일반 사이트에서 주민등록번호를 필수적으로 수집하고 이를

검색엔진이 물어가도록 방치해온 것 자체가 잘못된 것이다. 단순히 편의를 위해

아니면 나중에 어떻게 사용해볼 요량으로 주민등록번호를 요구하는 안이한 생각이

문제를 불러일으킨 것이다.

하지만 최근에는 다음이나 EBS 와 같이 아예 주민등록번호를 입력 받지 않는 곳이

늘어나고 있으며 국가적인 차원에서 본인 확인을 위해 주민등록번호를 대체할 다른

수단을 강구하고 있다는 소식이다. 또한 주민등록번호를 비롯한 개인정보를 과도하게

수집해놓고도 제대로 관리하지 못하는 기업이나 단체에 대해 비판의 목소리도 커지고

있기 때문에 구글이 국내 개인정보 보호에 대해 오히려 관심을 불러일으킨 셈이 됐다.

구글 어스와 동해, 국가 주요 기관 사진

회사에서 구글 어스(earth.google.com)를 설치해서 동료에게 살고 있는 집 위치를

물어본 다음 검색해서 찾아주니 다들 너무나도 놀라는 표정을 지었다. 각자 자리로

돌아가서 구글 어스를 설치해놓고 평상시에 알고 있던 이런저런 장소를 탐험하는

즐거운 시간을 보냈으리라. 그런데 요즘 이런 구글 어스가 계속해서 언론 한 귀퉁이를

장식하고 있다.

- 14 -

시작은 바로 동해였다. 반크(www.prkorea.com/)에서 구글 어스에 나타나는 동해

표기가 ‘일본해(Sea of Japan)’라는 사실을 발견해 구글 쪽에 정정요청을 한 것이다.

결국 구글은 반크 손을 들어줘 일본해가 동해로 바뀌었는데 이번에는 일본 쪽에서

반크 사이트를 다운시킬 정도로 격렬하게 항의를 했고 결국 구글은 <화면 7>과 같이

동해와 일본해를 병기했다.

이 과정에서 구글 어스에 대한 관심이 증폭됐는데 후폭풍으로 청와대를 비롯한 국내

주요 기관 사진을 손쉽게 얻을 수 있다는 보도가 나오면서 다시 한번 정부차원 대응이

필요하다는 주장이 솔솔 피어오르고 있다. 미국의 경우에는 군사 시설이나 주요 국가

시설물에 대한 사진을 제한하고 있기 때문에 구글 어스로 검색할 경우에 결과가

나타나지 않는다. 하지만 미국을 제외한 다른 나라에서는 이런 서비스를 기대하기

어렵다는 사실이 문제가 된다. 웹 사이트인 경우에는 구글의 웹 수집기인 구글 봇에게

특정 사이트 내용을 색인하지 않도록 요청하는

방법(www.google.com/webmasters/bot.html 참조)으로 민감한 정보 노출을 막을 수

있지만 키홀 인공위성의 경우에는 위장막을 설치할 수도 없으므로 특별히 조치를 취할

수 없기 때문에 주민등록번호 노출 문제와는 성격이 조금 다르다.

하지만 전문가들 사이에서도 여기에 대한 의견이 분분하다. 기술발전과 더불어

고해상도 이미지를 얻을 수 있는 길이 많기 때문에 단순히 구글 어스 서비스만

제한한다고 해서 문제를 근본적으로 해결하기는 어렵다는 것이다. 또 구글 어스가

서비스하는 해상도로는 군사적인 위협 수준까지 이르기에는 역부족이라는 지적도 있다.

다시 말해 이미 군사 목적으로 사용했던 GPS 도 해상도를 완화시켜 상업화된 마당에

디지털 이미지 서비스도 상업화되는 추세를 거스를 수 없다는 것이다.

구글 어스를 오용할 경우 생기는 문제점에 대해 걱정이 쌓여가는 와중에 구글 어스에

대한 긍정적인 면도 부각되고 있다. 바로 허리케인 카트리나가 덮친 이재민 거주

지역에 대한 피해 상황을 제공한 것이다. 네티즌 제보를 접수한 구글이

미국해양대기관리처(NOAA)에서 제공받은 실시간 사진을 사용해서 예전 사진과 비교한

다음이 피해 상태를 알려주는 서비스를 시작했다. 구글 어스를 사용해서 예전 사진과

새로운 사진을 비교할 수도 있고 <화면 8>과 같이 피해 상황을 한 눈에 조감할 수도

있다. 구글 어스의 사례는 가치중립적인 기술을 어떻게 활용하느냐가 관건이라는 점과

정보공개와 올바른 사용에 대한 더 깊은 고민이 필요하다는 문제를 제기했다.

- 15 -

구글의 한국어 서비스

마지막으로 구글의 한국어 서비스에 대해 몇 가지만 짚고 넘어가자. 아직 한국지사는

설립되지 않았지만 구글에서 일해야 하는 10 가지 이유에서 밝힌 ‘세계를 하나로

묶는다 : 모든 국가와 모든 언어를 지원한다’ 정책에 따라 구글은 한국어 서비스에

대해 상당히 발 빠르게 대응하고 있다.

기념일마다 바뀌는 로고에 한국 버전을 제공하고 있으며 원래 구글 한글 버전

홈페이지인 www.google.co.kr 에 구글 한글이라는 부제를 달았다가 네티즌들의

항의를 받고 바로 구글 한국이라고 수정했으며, 구글 툴바는 물론이고 gmail 도 한글

버전을 제공하고 있다. 또한 인터넷 신문에서 자료를 수집해서 자동으로 분류한 후

제공하는 구글 한국어 뉴스 서비스와 대학교 검색 서비스도 한국 현실에 맞춰 제공해

상당한 인기를 모으고 있다. 앞서 살펴본 구글 어스에 동해 표기를 병기한 것도

구글이 한국 시장을 상당히 높게 인식하고 있다는 증거로 해석된다.

그러나 아쉬운 점도 많다. 우선 구글이 제공하는 각종 프로그램은 여전히 한글화가

기대에 미치지 못한다. 최근 새로 출시한 구글 토크(www.google.com/talk)도 입력

도중에 글자가 완성되지 못하고 풀어져버리는 버그가 있으며, 아직 한글 버전은

공개되지 않았다. 구글 한국어 번역은 아직 초기 단계이며 구글 서제스트도 아직 한글

서비스를 시작하지 않고 있다.

구글플렉스를 이룰 수 있을까

지금까지 구글의 역사와 개발자에 있어 구글의 의미, 국내에서 비춰지는 구글의

모습에 대해 개괄적으로 살펴봤다. 장황하게 설명했으나 검색엔진인 구글의 신드롬

이면에 숨겨진 비밀은 매우 단순하다. 사용자가 원하는 정보를 가장 빠르고 손쉽게

찾아준다는 사실 하나이기 때문이다. 그러나 이런 목표를 달성하기 위한 구글의

움직임은 그리 단순하지 않다. 검색 결과라는 ‘공짜 선물’을 한걸음 앞서 제공하기

위해 수많은 인력과 자금을 투입하는 일이 결코 쉽지 않기 때문이다.

- 16 -

개발자 포용 정책의 성공에서 출발해 이제 서서히 국내 일반 사용자에까지 영향을

미치고 있는 구글이 향후 구골(2 의 100 승, en.wikipedia.org/wiki/Googol)을 넘어서

구글플렉스(10 의 구골승, en.wikipedia.org/wiki/Googolplex)으로 발전해 갈 수 있을지

필자 역시 흥미진진한 시각으로 바라보고 있다.

참고자료

① 마소 2004 년 6 월호 디지털 라이프 특집 '구글?! google it!'

② 보라빛 소가 온다, 세스 고딘, 남수영.이주형 역, 재인, 2004 년

③ 구글 해킹, Johnny Long, 강 유 역, 에이콘, 2005 년

④ 조엘 온 소프트웨어, 조엘 스폴스키, 박재호/이해영 역, 에이콘, 2005 년

제공 : DB 포탈사이트 DBguide.net

출처명 : 마이크로소프트웨어 [2005 년 10 월]

- 17 -

All about google!

특집 1 부 | 개발자, 구글 신드롬에 빠지다

특집 2 부 | 성공의 원천, 탄탄한 기술 인프라 대해부

특집 3 부 | 구글의 숨은 경쟁력 운영과 마케팅

특집 4 부 | 구글의 이면, 최강의 해킹 툴

특집 5 부 | 리얼가상 스토리 ‘빽투더 구글 퓨처’

특집 2 부 성공의 원천, 탄탄한 기술 인프라 대해부

노희섭 | 시니어 개발자

구글은 처음부터 다른 서비스와는 차별되는 검색엔진과 아키텍처, 새로운 개념의 랭킹

모델들을 사용함으로써 그간의 웹 검색에 대한 개념을 크게 바꾸어 놓았다. 구글의

기술은 검색 업계에서 일하는 개발자들은 물론 일반 개발자들까지도 관심을 갖게

만드는데, 그 핵심은 탄탄한 기반 기술들과 그것들을 하나로 묶는 거대한

프레임워크에 있다. 이번 특집 2 부를 통해 구글의 기술이 어떤 그림을 갖고 있는지에

대해 이해할 수 있는 시간이 될 것으로 기대한다.

구글 검색엔진

검색엔진은 대상이 되는 문서들을 수집하고, 수집된 문서들로부터 키워드를 추출하여

키워드-문서 간의 역 색인(inverted index)을 생성한 후, 사용자의 질의어(query)를

입력받아 해당 쿼리를 역 색인 구조를 찾아, 매칭된 문서를 결과로 반환해 준다.

구글의 검색엔진 역시 이러한 전통적인 검색엔진의 구조와 크게 다르지 않다. 구글의

검색엔진은 웹 문서들을 수집하고, 웹 문서들로부터 키워드를 추출하여 역 색인

구조를 생성하고, 생성된 역 색인 구조로부터 질의어를 매칭하여 결과를 반환해준다.

- 18 -

그러나 구글의 검색엔진은 기존의 검색 시스템과는 스케일이나 기능 면에서 많은

차이를 보여준다.

전통적인 키워드 매칭(keyword matching)을 기반으로 한 자동화된

검색엔진(automated search engine)은 몇 가지 약점을 갖고 있었다. 기본적으로 낮은

질의 매칭 결과가 너무 빈번하게 나타났다. 게다가 광고주들이 웹 문서에 포함된

키워드들을 조작해 엉뚱한 결과가 노출되도록 하는 것이 가능했다. 구글은 이런

문제점을 해결하기 위해 웹 문서의 하이퍼텍스트에 존재하는 부가적인 구조적

정보들을 사용하기 시작했다. 또한 방대한 웹 문서 데이터들을 처리하기 위해 매우

거대한 스케일의 검색 아키텍처를 구축했다.

구글 검색엔진의 지향점

웹을 효율적으로 검색하기 위해서는 몇 가지의 필수적인 기술들이 요구된다. 웹

문서들을 신속하고 효율적으로 수집하고, 수집된 데이터들을 최신의 상태로 유지하기

위한 크롤링(crawling) 기술, 대용량 데이터 처리를 위해 효율적으로 공간을 사용할 수

있는 색인 구조, 대용량 데이터를 신속하게 처리할 수 있는 색인기(indexer) 기술,

다량의 질의어들을 처리할 수 있는 질의어 분석/처리 시스템 등이 그것이다.

웹이 성장하면서 이러한 기술들이 감당해야 하는 목표들은 급격하게 상향 조정된다.

게다가 단순히 하드웨어의 발전만으로는 웹의 발전 속도를 감당할 수 없다.

하드웨어의 발전이 검색 시스템의 성능을 증가시키지만, 기본적으로 디스크 탐색

시간(disk seek time)이나 운영체제의 강력함(robustness)은 그렇게 주목할 만한

요소가 아니다. 구글 검색엔진은 극단적으로 큰 데이터 셋(data set)을 커버하기 위한

확장형 구조이며, 효율적인 색인 구조를 사용함으로써 데이터에 대한 신속하고

효율적인 액세스가 가능하도록 최적화된 구조이다.

웹 검색의 초창기에 많은 사람들이 검색엔진의 색인이 완전하고 무결성을 갖는다면

어떤 키워드에 대해서도 원하는 웹 문서를 검색할 수 있다고 믿었다. 그러나 웹

검색이 발전하면서 색인의 완전성과 무결성이 검색 품질을 좌우하는 유일한 요소가

아님이 밝혀졌다. 웹 검색은 일반적으로 입력되는 질의어에 대해 매칭되는 문서의

- 19 -

개수가 대단히 많다. 즉, 검색 대상이 되는 색인 내에서 검색 결과로 재현될 수 있는

비율이 대단히 크다. 그러나 일반적인 사용자들은 많은 검색 결과 중에서 상위의 일부

결과만을 보고 검색 결과의 모든 품질을 평가하려는 성향이 있다. 관련 있는 검색

결과가 상위에 랭크되어 있지 않고 몇 십 페이지 뒤에 랭크되어 있다면, 그것을 찾기

위해 페이지를 클릭할 사용자는 그렇게 많지 않다. 따라서 사용자의 만족감을

충족시키기 위해서는 극도로 높은 정확도에 기반한 검색 결과를 제공해야 한다.

정확도는 대용량 데이터의 검색 결과 품질을 좌우하는 요소이기 때문에, 재현율을

희생해서라도 정확도를 확보하는 것이 사용자들의 만족감을 위해 가장 중요하다⑴.

구글 검색엔진은 이러한 이유로 정확도 중심의 엔진으로 설계됐다. 구글의 정확도는

극도의 관계성 판단(relevance judgement)에 의해 산출되는데, 그 기반에는 링크

구조와 앵커 텍스트(anchor text)를 분석한 정보에 의한 질적인 필터링(filtering)이

존재한다. 구글은 이러한 정보들의 정확도를 높이는 두 가지 방법을 사용한다. 하나는

개별 웹 페이지의 품질 순위 할당을 위한 페이지 랭크 알고리즘이고, 다른 하나는

검색 결과 개선을 위한 앵커 텍스트 사용이다.

참고로, 구글이 검색엔진을 발표했던 초창기에는 또 한 가지 목표를 가지고 있었다.

그것은 대용량 웹 문서들과 대용량 트래픽을 감당할 수 있는 거대한 웹 시스템을

만들고, 실제로 많은 사용자들이 그것을 사용하면서 얻는 데이터(usage data)를

학술적인 연구에 제공하겠다는 것이었다.

구글 검색엔진의 특징

페이지 랭크의 사용

웹 문서에 존재하는 레퍼런스(링크) 그래프는 구글 검색엔진이 거의 최초로 주목한

요소이다. 페이지 랭크는 이러한 요소들로부터 사용자들이 생각하는 특정 페이지의

중요성(importance)에 부합하는 정확도(precision)의 객관적인 척도를 산출해낸다.

사용자들의 생각과 관련을 갖기 때문에 페이지 랭크는 웹 문서에 순위를 할당하는데

매우 합리적인 수단이다. 질의어를 문서 제목과 매칭되는지 여부만을 평가하는 단순한

텍스트 검색엔진에는 물론, 풀 텍스트(full text, 제목과 내용을 모두 포함)

- 20 -

검색엔진이나 페이지 랭크로 순위를 매기는 경우에도 상당한 성능을 보여주기

때문이다.

페이지 랭크는 한 페이지의 인용 횟수(백 링크, back link)를 카운팅하는 방식으로

계산된다. 한 페이지가 얼마나 많은 레퍼런스를 받고 있느냐의 수준이 그 페이지의

중요성이나 품질(quality)을 추정할 수 있는 요소로 간주된다. 페이지 랭크는 이

기본적인 아이디어를 확장하여 그 링크가 어떤 페이지에서 왔는지를 차별화하고,

링크하는 페이지에서 외부로 나가는 총 링크 개수로 노멀라이징(normalizing)을

수행했다.

페이지 랭크를 간략하게 정리하자면 다음과 같다. 페이지 A 를 링크하는 다른

페이지들의 set 을 (T1, T2, T3, ...., Tn)이라고 한다면, 파라미터 d 는 0~1 사이의

값을 갖는다. C(A)는 페이지 A 에서 외부로 나가는 아웃 링크(out link)의 개수이다. 이

때 페이지 A 의 페이지 랭크 값 PR(A)은 다음과 같은 수식으로 표현된다.

페이지 랭크 PR(A)은 반복 알고리즘(iterative algorithm)으로 계산할 수 있으며, 그

값은 웹 링크를 노멀라이징해서 행렬로 바꾸었을 때 주 고유 벡터(principal eigen-

vector)에 해당한다. 참고로 이것은 약 2600 만 페이지의 페이지 랭크를 계산하는데

중급의 워크스테이션으로 수 시간 내에 연산이 가능한 수준이다.

페이지 랭크는 또한 사용자의 행동 패턴을 모델링하고 있다. 무작위로 선택한 하나의

웹 페이지에서 출발해서 백 버튼을 누르지 않은 상태로 계속 링크를 따라

네비게이션하는 랜덤 서퍼(random surfer)는 네비게이션 도중 지루해지면 다시

무작위로 페이지를 선택해서 네비게이션을 시작한다. 한 페이지의 페이지 랭크는 랜덤

서퍼가 그 페이지를 방문할 확률을 나타낸다. 페이지 랭크에서 주요 파라미터 중

하나가 댐핑 팩터(damping factor) d 이다. 페이지 랭크에서는 파라미터 d 를 특정

페이지 하나 또는 일련의 페이지에만 선택적으로 적용함으로써

개인화(personalization)를 가능하게 하며, 페이지에 대한 랭킹을 올리기 위한

속임수(abusing)를 사실상 불가능하게 만들 수 있다.

- 21 -

페이지 랭크의 직관적인 요소 중 또 하나는 페이지 랭크 값이 커지기 위해서는 많은

페이지가 어떤 한 페이지를 집중적으로 레퍼런스하고 있거나, 특정 페이지를

레퍼런스하는 페이지 자체의 페이지 랭크 값이 커야 한다는 것이다. 예를 들어 많은

페이지로부터 인용되고 있는 페이지는 살펴볼 만한 가치가 있는 것이고, 야후 같은

메이저 페이지(major page)에서 링크되고 있는 페이지는 그렇지 않은 페이지보다

중요하다고 간주되는 것이다. 페이지 랭크에 대한 더 자세한 내용은 뒤에서 따로

다루겠다.

앵커 텍스트의 사용

구글 검색엔진은 링크의 텍스트 자체를 특별하게 취급한다. 대부분의 검색엔진들은

링크의 텍스트(앵커 텍스트)를 링크를 담고 있는 페이지 자체의 정보 중 일부로만

취급하고 있지만, 구글의 검색엔진은 링크가 가리키고 있는 페이지를 링크의 텍스트와

연관시켜 처리한다. 이런 방법은 몇 가지 장점을 가진다. 첫째, 앵커 텍스트는 링크를

담고 있는 페이지에 대한 설명보다 링크가 가리키고 있는 페이지에 대해 더 정확한

설명을 담고 있는 경우가 대부분이다. 둘째, 일반적인 텍스트 검색엔진이 색인할 수

없는 이미지나 프로그램, 데이터베이스로의 앵커(링크)도 존재할 수 있다. 따라서

앵커를 사용한다면 크롤링되지 않는 웹 페이지들까지도 찾아낼 수 있다. 물론 이러한

링크에 걸려있는 대상들은 검색에 유효하지 않은 대상일 수 있으므로 사용자에게

보여주기 전에 먼저 유효성 검사를 통과해야 한다. 존재하지 않는 페이지를 가리키는

앵커의 경우에도 유효성 검사를 거치면 큰 문제는 없다.

앵커 텍스트를 그 앵커가 가리키는 페이지로 전파시켜 나간다는 아이디어는 World

Wide Web Worm(WWWW) 검색엔진에서 먼저 구현됐다. 앵커 텍스트가 텍스트 이외의

데이터에 대한 검색을 용이하게 해 주었고, 검색엔진이 크롤링한 웹 문서보다 훨씬 더

많은 영역을 포괄하게 해주는 것에 이 아이디어의 유용성이 있다. 다만, 이를

위해서는 대용량 데이터 처리를 위한 구조가 필수적이다.

그 밖의 특징

- 22 -

페이지 랭크와 앵커 텍스트에 대한 접근 방식 외에도 구글 검색엔진은 몇 가지 특징을

갖는다. 첫째, 구글 검색엔진은 문서로부터 추출된 모든 키워드들에 대한 위치

정보(positional information)를 저장한다. 위치 정보의 저장은 검색 수행 시 근접도의

광범위한 사용을 가능케 한다. 둘째, 구글은 문서 내에서 추출된 키워드의 폰트 크기,

대소문자 여부 등에 대한 부수적이고 시각적인 세부 요소들을 추적한다. 폰트 크기가

큰 단어나 볼드체로 된 단어, 대문자로 작성된 단어의 경우에는 그렇지 못한 단어에

비해 더 높은 가중치(weight)가 부여된다. 셋째, 구글 검색엔진은 수집된 웹 문서를

완전한 HTML 형식으로 압축 저장하기 때문에 이를 활용할 수 있는 여지가 있다.

<그림 1> 구글 검색엔진의 아키텍처

구글 검색엔진의 전반적인 구조

- 23 -

지금까지 구글 검색엔진의 특징을 살펴보았고, 이제는 구글 검색엔진의 구조에 대해

알아보자. <그림 1>은 구글 검색엔진의 아키텍처를 표현하고 있다. 구글 검색엔진의

구조는 일반 검색엔진과 큰 차이가 없다. 구글 검색엔진은 크게 웹 문서를 수집하는

크롤러(crawler) 영역과, 역 색인(inverted index)을 생성하는 색인기(indexer) 영역,

그리고 검색을 수행하는 검색기(searcher) 영역으로 구분된다. 구글 검색엔진이

데이터를 수집하고 색인을 생성하여 검색을 수행하는 전반적인 시퀀스는 다음과 같다.

• 크롤링

- 분산 배치된 크롤러에 의해 웹 페이지들이 다운로드된다.

- 크롤러가 수집한 문서들은 URL server 로 보내져서 URL list 로 변환된다.

- 크롤러로부터 패치(fetch)된 웹 문서들은 Store server 에 저장된다.

- Store server 에 저장된 웹 문서들은 압축되어 리파지토리에 저장된다.

- 저장된 웹 문서들은 특정한 docID 를 부여받는다.

• 색인

- Indexer 가 리파지토리를 읽어 압축된 웹 문서들의 압축을 해제한다.

- Indexer 가 압축 해제된 웹 문서를 파싱하여 문서에 포함된 부수적인 정보(위치 정보,

폰트 크기, 대소문자 여부)와 함께 추출한 키워드 정보(Hits 라고 불린다)의 set 을

생성하고, 링크들을 분석하여 링크의 방향성과 앵커 텍스트들을 추출해서 anchor

file 을 생성한다.

- Indexer 가 문서 당 추출된 키워드들의 set 을 Barrel 에 일부분 정렬이 이루어진

forward index 형태로 분산 저장한다.

- URL resolver 가 anchor file 을 분석하여 상대 URL(relative URL)을 절대

URL(absolute URL)로 변환하고, 변환된 URL 정보를 Barrel 에 저장되어 있는 forward

index 의 docID 와 조합한다.

- Sorter 가 Barrel 에 docID 순으로 정렬되어 있는 정보를 키워드 별로 정렬하여

wordID 를 할당한다.

- Indexer 가 wordID 순으로 정렬된 정보를 이용하여 최종적으로 역 색인(inverted

index)을 생성하여 Lexicon 에 저장한다.

- 24 -

<그림 2> 라파지토리의 자료구조

• 검색

- 입력 받은 질의어를 분석한다.

- Lexicon 을 뒤져서 분석을 통해 추출된 키워드에 해당하는 wordID 를 찾는다.

- 발견된 wordID 에 해당하는 doclist 의 시작 위치를 Barrel 을 뒤져서 찾는다.

- doclist 를 스캔하여 입력된 search term 과 매칭되는 도큐먼트들을 찾는다.

- 탐색된 도큐먼트들에 대해서 페이지 랭크를 계산한다.

구글 검색엔진의 자료구조

구글 검색엔진은 기본적으로 대용량 데이터를 다룬다. 기본적인 정보 외에도 부수적인

정보들을 충분히 다루고 있는 만큼 모든 색인 구조를 비롯한 자료구조는 매우

효율적이고 최적화돼 있어야 한다. 머신의 성능은 급격하게 발전하고 있지만 디스크

I/O 속도는 크게 변함이 없는 현실에서 자료구조는 훨씬 더 중요한 위치를 차지한다.

다음은 구글 검색엔진에서 사용하고 있는 자료구조들이다. 구글 검색엔진의

자료구조를 살펴보면, 구글 검색엔진의 내부 프로세스와 구조를 더 자세히 볼 수 있다.

• 리파지토리

리파지토리는 크롤러에 의해 수집된 웹 문서의 full HTML 을 zlib 를 이용해 압축,

저장한다(zlib 은 다른 압축 솔루션에 비해 압축과 압축 해제 속도가 뛰어나다).

리파지토리에 저장되는 각 웹 문서들은 docID 를 prefix 로 사용하여, 기타 정보들을

함께 묶은 형태의 자료구조로 표현된다. 웹 문서의 consistency 유지나 크롤러의

에러는 리파지토리의 모든 자료구조를 재생성(rebuilding)함으로써 해결한다. <그림

2>는 리파지토리의 자료구조를 나타낸 그림이다.

- 25 -

• 도큐먼트 인덱스(Document Index)

도큐먼트 인덱스는 각 도큐먼트의 정보들을 저장하며, 기본적으로 docID 에 의해

정렬된 fixed width ISAM(Index sequential access mode)이다. 이것은 도큐먼트에 대한

추가적인 정보로 도큐먼트의 상태 정보, 리파지토리 내에서의 해당 도큐먼트에 대한

위치, 도큐먼트 체크섬(checksum), 기타 수치적 정보들을 포인터로 담고 있다. 포인터

정보만 사용함으로써 콤팩트한 자료구조의 구성이 가능하며, 검색을 수행하는 동안

디스크 탐색 시간을 줄일 수 있다. 추가로, 도큐먼트의 정보 중 URL 과 docID 의

관계를 저장해 두기 위해 URL 을 docID 로 변환한 관계를 저장하는 파일이 존재한다.

이것은 URL 체크섬을 키(key)로 갖고, docID 를 데이터로 갖는 자료구조로 일반적인

btree(binary tree) 검색과 유사한 방식에 의해, URL 체크섬을 키로 던져 해당 URL 의

docID 를 찾아내는데 사용된다. 이 방식은 URLresolver 가 URL 을 docID 로

변환하는데 사용된다.

• Lexicon

Lexicon 은 실제 검색을 수행할 때 반드시 필요한 역 색인 구조를 만들기 위한

자료구조이다. 검색엔진의 성능과 처리 가능한 용량이 대부분 Lexicon 과 역 색인

구조에 기반해 결정되기 때문에 Lexicon 의 자료구조는 검색엔진의 전체 구조 중 매우

중요한 요소를 차지한다. 검색엔진의 속도 향상을 위한 기초적인 접근 방식은

Lexicon 을 메모리에 구동 가능한 크기로 쪼개는 것이다. 초기 구글 검색엔진의

경우에는 256MB 메인 메모리에 올라갈 수 있는 크기로 설계됐고, 256MB 안에

1,400 만 개의 단어를 올릴 수 있었다. 구글의 Lexicon 은 추출된 단어들의 리스트와

포인터의 해시(hash) 테이블, 두 가지 요소로 구성된다.

• Hit Lists

Hit 는 하나의 도큐먼트에서 추출된 하나의 단어에 대한 부가적인 위치 정보, 폰트

정보, 대문자 여부 등의 집합이다. Hit List 는 forward index 와 inverted index 에서

모두 사용되며 검색엔진 내의 정보 중 상당 부분을 차지하기 때문에 가능한 효율적인

구조를 가져야 한다. 구글 검색엔진은 하나의 hit 를 2 바이트로 인코딩하는 방식을

취한다.

Hit 는 다시 각 도큐먼트에서 URL, title, anchor text, meta tag 로부터 추출된 정보를

저장하는 fancy hit, anchor text 로부터 정보를 추출된 정보를 저장하는 anchor hit,

그리고 그 밖의 요소들로부터 추출되는 plane hit 등 3 개의 hit 로 구분된다. <표 1>은

인코딩된 fancy hit 과 plane hit, anchor hit 의 구조를 나타낸다.

- 26 -

Anchor hit 에 포함된 4 비트짜리 해시는 해당 anchor 가 출현한 웹 문서의 docID 에

대한 해시 값을 저장한다. 이것은 anchor file 에 저장되어, 랭크 산출에 가중치 요소로

사용된다. 최종적으로 hit list 들은 Barrel 에 forward index 를 구성하면서 wordID 를

기준으로 저장되고, inverted index 에 docID 를 기준으로 저장된다.

• Forward Index

Forward Index 는 도큐먼트에 대한 docID 를 기준으로 추출된 hit list 를 wordID 와

함께 붙여서 barrel 에 분산해놓은 구조이다. Barrel 자체가 wordID 의 특정 range 에

대해 분산되도록 설계되어 있기 때문에 docID 가 중복 저장될 가능성이 있다. 하지만

inverted index 를 구성할 때 Sorter 에 의해 wordID 를 중심으로 재구성되어야 하기

때문에, 실제로는 이와 같은 방식이 조금 더 효율적일 수 있다. Barrel 내에 forward

index 가 저장될 때는 wordID 24 비트와 hit list length 에 대한 정보가 8 비트 추가된다.

• Inverted Index

Inverted Index 는 forward index 가 Sorter 에 의해 wordID 순으로 정렬된 구조이다.

유효한(valid) wordID 는 Lexicon 에 저장되고, 각 wordID 가 속한 도큐먼트에 대한

docID 는 Barrel 내에 역 색인으로서 저장된다. Lexicon 의 각 wordID 는 inverted

barrel 내의 docID 를 가리키는 포인터를 갖는다.

<그림 3>은 Forward Index, Inverted Index, Lexicon 의 구조에 대한 그림이다.

Forward Barrel 에 저장된 docID 의 리스트는 최종적으로 Lexicon 과 Inverted Barrel 에

저장되면서 최종적인 역 색인 구조를 구성하게 된다.

- 27 -

<그림 3> Forward/Bcakward Index 와 Lexicon 의 자료구조

<표 1> 인코딩된 fancy hit 과 plane hit, anchor hit 의 구조

구분 내용

Plane Hit capitalization: 1 font info: 2 position: 12

Fancy Hit capitalization: 1 font info: 7 type;

4 position: 8

Anchor Hit capitalization: 1 font info: 7 type;

4

hash:

4

position:

4

<표 2> 구글 검색엔진의 퍼포먼스 수치 정보

Storage Statistics

Total Size of Fetched Pages 147.8GB

- 28 -

Compressed Repository 53.5GB

Short Inverted Index 41GB

Full Inverted Index 37.2GB

Lexicon 293MB

Temporary Anchor Data 6.6GB

Document Index Incl. Variable Width Data 9.7GB

Links Database 3.9GB

Total without Repository 55.2GB

Total with Repository 108.7GB

Web Page Statistics

Number of Web pages fetched 24 million

Number of URLs seen 76.5 million

Number of Email Address 1.7 million

Number of 404's 1.6 million

Search Times

Initial Query Same Query Repeated

Query CPU time Total time CPU time Total time

al gore 0.09 2.13 0.06 0.06

vice president 1.77 3.84 1.66 1.8

hard dixks 0.25 4.86 0.2 0.24

search engine 1.31 9.63 1.16 1.16

지금까지 구글 검색엔진에 대한 특징과 아키텍처, 자료구조에 대해 살펴보았다.

구글이 등장한지 많은 시간이 흘렀지만, 구글의 검색엔진은 여전히 최적화된 혁신적인

구조로 개발자들에게 받아들여지고 있다. 많은 검색엔진들은 여전히 구글 검색엔진을

벤치마크 대상으로 이용하고 있고, 구글 검색엔진이 갖고 있는 합리적인 랭킹

모델이나 데이터 처리 모델과 자료구조는 많은 검색엔진이 닮고 싶어하는 요소들이다.

- 29 -

현대적 랭킹 모델, 페이지 랭크 알고리즘

구글은 처음 등장할 때 대량의 웹 페이지 데이터들에 대한 새로운 개념의 랭킹 모델

적용으로 가장 주목받았다. 페이지 랭크라 불리는 이 랭킹 모델(ranking model)은 각

웹 페이지들의 중요성(importance) 을 기반으로 계산(scoring)된, 사용자 입장에서

상당히 정확해 보이는 랭킹을 제공한다.

세르게이 브린(Sergey Brin)이 제안한 페이지 랭크 알고리즘은 웹 페이지의 중요성에

기반을 둔 일종의 보팅 알고리즘(voting algorithm)으로, 사용자 중심의 주관적 영역에

놓여있던 ‘중요성’을 상대적이고 기계적인 관점에서 정량화가 가능한 객관적 영역으로

변환시킨다. 이것은 기존의 야후나 기타 검색엔진들이 제공했던 사람이 직접 웹

페이지의 중요도를 등록하여 결과로 제공하는 것이 웹 페이지의 랭크라고 믿어오던

사람들의 생각을 완전히 바꿨다. 구글은 모든 페이지들의 중요도를 인터넷에서 웹

페이지를 생산해내는 사람들과 사용자들이 웹 페이지에 접근하는 행태를 분석하여

자동으로 랭킹이 계산되는 구조를 만들어 냈다. 인력으로 랭킹을 처리하는 데에는

한계가 있었기 때문에, 비교할 수 없을 정도로 훨씬 더 많은 데이터들에 대해 유효해

보이고 자동화된 랭킹을 제공한 구글은 단숨에 검색 사용자들의 이목을 끌 수밖에

없었다.

<그림 4> 역 링크: 링크 A 와 링크 B 는 페이지 C 에 대한 역 링크이다.

- 30 -

랭크를 갖는 링크: 링크를 통한 랭킹의 전파

웹 링크의 중요성에 대한 접근은 구글 이전에도 있었는데 대부분 웹 공간 상에서

링크는 논문에 기재되는 학술적 레퍼런스와 유사한 개념으로 보아, 레퍼런스 구조를

분석하고 중요성을 계산하는 테크닉들이 대부분이었다. 예를 들어, 학술적으로 자주

인용되는 논문은 그렇지 않은 논문에 비해 중요한 논문일 가능성이 크다고 보는

것이다. 페이지 랭크의 기본적인 아이디어는 웹 상의 이러한 레퍼런스 구조를 웹

공간의 링크 구조로 더욱 포괄적으로 확장하는 데 있다.

웹 페이지는 그 페이지에서 밖으로 나가는 순 링크(forward link, outedge)와 외부에서

그 페이지를 가르키는 역 링크(back link, inedge)를 포함한다. 기본적으로 페이지

랭크에서 측정되는 웹 도큐먼트의 중요성은 웹 도큐먼트의 컨텐트와 상관없이 그 웹

도큐먼트가 갖고 있는 링크 구조를 분석함으로써 측정된다.

페이지 랭크에서 중요성에 대해 가장 주요한 요소로 간주된 것은 링크가 많이 된

페이지가 그렇지 못한 페이지보다 대부분 더 중요하다는 가정이었다. 역 링크라

불리는, 외부 페이지로부터의 레퍼런스 횟수는 중요성을 계산하는데 기본적인 요소로

사용되었다. <그림 4>는 역 링크의 일반적인 형태를 나타낸다.

하지만 역 링크의 개수를 세는 것만으로 중요성을 매기는 것은 유효하지 않을 수도

있다. 어떤 웹 페이지가 달랑 야후 하나에 링크되어 있다면 그 도큐먼트는 단 1 개의

역 링크를 갖고 있지만, 그 링크는 중요하지 않은 페이지로부터의 역 링크 몇 개보다

훨씬 더 중요한 링크라고 간주될 수 있다. 페이지 랭크는 링크를 통해 랭킹을

전파하는 구조이다. 모든 역 링크에는 랭크 값이 있고, 랭크 값이 높은 역 링크의

레퍼런스를 많이 갖는 웹 도큐먼트일수록 웹 도큐먼트의 랭크가 올라간다.

페이지 랭크의 개념

- 31 -

페이지 랭크를 단순하게 모델링한다면 다음과 같은 간단한 수식으로 표현할 수 있다.

어떤 웹 페이지를 u 라고 하고, 웹 페이지 u 가 레퍼런스하고 있는 페이지의 집합을 Fu,

웹 페이지 u 를 역 링크하고 있는 페이지의 집합을 Bu 로 표현한다. Nu 는 웹 페이지

u 로부터 나가는 순 링크의 개수(| Fu |)이다. c 는 웹 페이지의 랭크 총합을 일정

레벨로 맞추기 위한 노멀라이징 팩터(normalizing factor)이다. <그림 5>는 페이지

랭크가 계산되는 방식을 간단하게 보여준다.

그러나 웹 공간 상의 복잡한 링크 구조는 이와 같은 수식으로 해결하기 어려운

그래프를 구성하기도 하는데, 랭크 싱크(rank sink)와 댕글링 링크(dangling link)가

그것이다 ⑵. 페이지 랭크에서는 이런 문제를 해결하기 위해 사용자 정의 파라미터를

하나 더 둔다. 다음은 사용자 정의 파라미터 E 가 추가된 페이지 랭크 모델을

표현한다.

추가 파라미터 E(u)는 웹 페이지 u 로부터 또 다른 특정 페이지로 이탈할 확률 분포에

대한 모델이다. 앞서 검색엔진을 설명하면서 잠시 거론되었던 페이지 랭크의 사용자

행동 패턴에 대한 모델링(랜덤 서퍼 모델)이 바로 파라미터 E 이다. 즉, 파라미터 E 는

랜덤 서퍼가 특정 확률 주기에 의해 다른 페이지로 이탈하는 것을 의미하며 이것은

댕글링 링크를 이탈하는 행동의 모델링으로 볼 수 있다. 구글 검색엔진은 일반적으로

모든 페이지에 동일한 확률 주기의 E 값을 셋팅하여, 모든 서퍼들이 주기적으로

링크의 그래프를 이탈한다고 보지만 E 값을 특정 페이지로 지정함으로써, 개인화된

페이지 랭크 모델을 만들 수도 있다.

만약 2 개의 페이지 랭크 모델을 만들어서 하나는 E 를 일반 포탈 사이트의

홈페이지로, 나머지 하나는 E 를 컴퓨터 사이언스 관련 커뮤니티의 홈페이지로

셋팅한다면, 일반 포탈 쪽 랭크보다 컴퓨터 사이언스 관련 커뮤니티 쪽의 랭크들이 더

큰 값을 가지게 될 것이다.

페이지 랭크의 구현

- 32 -

페이지 랭크는 일반적인 재귀 연산(recursive operation)의 형태이지만, 효율성을 위해

컴퓨터 상에서는 벡터의 형태로 변환되어 계산된다. 이에 관련된 정보를 얻고 싶다면

Taher H. Haveliwala 가 쓴 『Efficient Computation of PageRank(Stanford Technical

Report, 1999)』를 참조하기 바란다. 페이지 랭크가 컴퓨터 상에서 처리되는 방식은

다음과 같다.

R0 ← S

loop :

Ri + 1 ← ARi

d ← ||Ri||1 - ||Ri + 1 ||1

Ri + 1 ← Ri + 1 + dE

δ ← ||Ri + 1 - Ri||1

while δ ＞ ∈

• S 는 한 웹 페이지의 초기 벡터 값이다.

• Ri 는 i 번째 페이지 랭크 벡터 값을 나타낸다.

• ||R||1 은 벡터 R 의 노름(norm) 값이다.

• d 는 댐핑 팩터(damping factor)이다.

• A 는 한 웹 페이지 u 에서 다른 웹 페이지 v 로 연결되는 포워드 링크의 개수의

역수이다. 만약 서로 연관된 링크가 없다면 0 이 된다.

<그림 5> 페이지 랭크의 계산

- 33 -

이와 같은 연산은 수렴(convergence)이 이루어질 때까지 반복적으로 이루어진다. 구글

검색엔진 내부에서는 방대한 웹 페이지들의 페이지 랭크 계산을 위해 다음과 같은

방식으로 프로세스를 진행한다.

① docID 를 이용하여 링크 구조를 정렬한다.

② 링크 데이터베이스에서 댕글링 링크를 제거한다.

③ 랭크 값을 초기화한다.

④ 각 페이지의 가중치를 저장하기 위한 메모리를 할당한다.

⑤ 한 단계의 계산이 완료되면 디스크에 가중치를 저장하고, 다음 단계의 계산을

메모리 상에서 진행한다.

⑥ Stet 5 를 수렴할 때까지 반복된다.

페이지 랭크의 의미

페이지 랭크는 본질적으로, 웹 링크의 그래프 상에서의 랜덤 서퍼가 갖는 행동 패턴을

제한된 분포로 결정짓는 작업이다. 그래프 상의 한 노드의 중요도는 충분한 시간이

흐른 후에 랜덤 서퍼가 그 노드 위에 있을 확률이다. 확률이 높다면 웹 상의 서퍼들이

접근할 가능성은 높아진다. 이것은 웹 페이지의 컨텐츠와 상관없이 웹 상에 존재하는

가중치가 부여된 링크 구조에 의한 중요성을 산출한다는 의미이다. 이런 특징은

대부분 사용자들의 웹 페이지 접근 의도에 대한 일반적인 케이스(common case)

처리가 가능토록 한다.

예를 들어 꽃이라는 키워드를 쳤을 때, 일반적인 케이스는 꽃에 대한 설명이 담긴

페이지들이 아니라 꽃 구입이나 배달과 관련된 페이지들이다. 일반적으로 사람들이

특정 질의어를 입력했을 때 특정 페이지가 일반적인 케이스라는 정보는 HTML

자체에는 담겨져 있지 않기 때문에, 링크 구조를 분석하는 페이지 랭크는 일반적인

케이스 처리에 매우 효과적이다. 또한 페이지 랭크는 사용자에게 자신이 찾고 있는

링크가 중요도 측면에서 어느 정도의 위치를 차지하고 있는지에 대한

인디케이터(indicator)가 될 수도 있다.

- 34 -

참고로, 페이지 랭크의 요소들은 지금도 계속해서 튜닝되고 있다. 예를 들면 웹

페이지의 컨텐츠가 얼마나 자주 갱신되는가에 대한 빈도수(frequency) 등이 새롭게

추가되는 요소들 중 하나이다.

대용량 파일의 분산 처리를 위한 구글 파일 시스템

검색엔진의 성능이 검색엔진의 자료구조와 아키텍처에 밀접한 관계가 있는 것은

사실이지만, 어느 수준의 성능 이상을 요구하는 경우에는 반드시 최적화된 하부

구조가 필요하다. 앞서 살펴보았던 구글 검색엔진은 대용량의 웹 데이터를 다루고,

그에 따른 대용량 데이터와 색인 구조들을 다루고 있다. 대용량 처리를 위해서는 비용

문제를 간과하기 힘들기 때문에, 구글은 저 사양의 머신들을 대량 배치하여 분산

처리하는 것으로 대용량 데이터와 대용량 트래픽에 대응하고 있다. 이를 가능하게 한

데에는 효율적으로 대용량 파일의 분산 처리와 성능을 위해 자체적으로 개발된 구글

파일 시스템의 역할이 크다.

<그림 6> 구글 파일시스템 아키텍처

구글 파일 시스템의 특징

- 35 -

대용량 분산 파일 시스템이 가져야 하는 요소에는 확장성(scal ability),

성능(performance), 신뢰성(reliability), 가용성(avail ability) 등이 있다. 구글 파일

시스템 역시 이런 특징적 요소들을 모두 포함하고 있다. 구글 파일 시스템은 리눅스

파일 시스템을 기반으로 개발되었으며, 추가적으로 다음과 같은 접근 특성들에 대한

처리 목표를 취하고 있다.

• 분산 처리 서버들의 오류(failure)에 대한 대응

- 애플리케이션 버그, 디스크 오류, 메모리 오류, 커넥션 오류, 네트워킹 오류, 파워

서플라이 오류 등에 대해서 모니터링, 오류 허용(fault-tolerance), 자동

복구(automatic recovery) 등이 시스템에 포함

• 기존의 파일에 비해 훨씬 더 큰 대용량 파일의 처리

- Multi-GB 파일들이 사용되기 때문에 I/O 오퍼레이션과 블럭 크기(block size)에 대한

파라미터 조정을 통해 효율적으로 관리

• 특징적인 읽기/쓰기 패턴에 대한 최적화

- Large streaming reads

- Small random reads

- Large, sequential writes

- Small writes

• Well-defined semantics 를 갖는 구조

- 동일 파일에 읽기/쓰기를 하려는 다수의 클라이언트의 오퍼레이션을 처리하기 위해

동기화(synchronization) 처리

• 고속의 대역폭(bandwidth) 유지

- 읽기/쓰기에 대해 엄격한 응답 시간(response time) 유지

구글 파일 시스템 아키텍처

- 36 -

구글 파일 시스템은 하나의 마스터 서버(master server)와 다수의 청크 서버(chunk

server), 그리고 다수의 클라이언트(client)로 구성되어 있다(이러한 서버들은 모두

표준화된 형태인데, 구글에서는 표준화된 서버를 pizza server box 라고 부른다). <그림

6>은 이러한 구글 파일 시스템의 아키텍처에 대한 그림이다.

마스터 서버는 청크 서버에 대한 메타 데이터들을 관리한다. 청크 서버는 정해진

크기의 청크들을 저장하고, 클라이언트는 마스터 서버의 메타 데이터들을 확인하고,

청크 서버에 접근하여 필요한 데이터를 읽고 쓴다.

각 파일들은 정해진 크기의 청크(chunk)로 나뉜다. 각 청크는 생성 시점에 마스터

서버에 의해 글로벌하게 유니크한(globally uni que) 청크 핸들(chunk handle)을

할당받는다. 청크 핸들과 바이트 레인지(byte range)에 의해 결정된 청크 데이터들은

청크 서버의 로컬 디스크에 저장되는데, 저장되는 청크 데이터는 기본적으로 3 개의

복제본을 가지게 된다. 하나의 청크 서버에서 청크들을 로컬 파일로 존재하므로

별도의 캐시(cache) 없이 리눅스의 버퍼 캐시 효과를 그대로 사용한다. 구글 파일

시스템의 청크 크기는 64MB 로 일반적인 리눅스 파일 시스템의 블럭 크기보다 크다.

이처럼 큰 청크 크기를 사용함으로써, 클라이언트가 동일한 청크에 접근할 때

불필요하게 마스터 서버와의 통신을 줄일 수 있고, 클라이언트의 네트워크 오버헤드와

마스터 서버에 저장되는 메타 데이터의 크기도 줄일 수 있다.

마스터 서버는 모든 파일 시스템의 네임 스페이스(name space), 액세스 컨트롤

정보(access control information), 파일-청크 간의 맵핑 정보 등의 메타 데이터를

관리한다. 마스터 서버는 이 정보를 이용하여 청크 서버들과 Heart Beat 메시지에

의한 커뮤니케이션을 통해 청크에 대한 가비지 컬렉션(garbage collection), 청크 서버

간의 마이그레이션(migration)을 수행한다. 마스터 서버의 메타 데이터들은 모두

메모리 상에 저장되기 때문에, 마스터 서버의 오퍼레이션이 매우 빠르다. 이는

주기적으로 상태를 스캐닝하여 청크 서버의 오류 상황이 발생했을 때 복제본을

재배치한다거나 청크 서버들의 디스크 사용 상태에 따라 청크 마이그레이션을

수행하는데 매우 효율적인 방식이다.

- 37 -

클라이언트는 구글 파일 시스템 API 에 의해 구현된 애플리케이션을 담고 있으며,

마스터 서버 및 청크 서버와 커뮤니케이션하면서 애플리케이션에 필요한 데이터를

읽고 쓴다. 클라이언트는 마스터 서버와의 메타 데이터와 오퍼레이션 내용과

커뮤니케이션하고, 모든 실제 데이터와의 커뮤니케이션을 청크 서버와 직접 하게 된다.

구글 파일 시스템의 일관성 모델(Consistency Model)

클라이언트에 의해 파일이 청크 서버에 저장될 때는 오류 발생에 대비해서 3 개의

복제본으로 저장된다. 만약, 데이터가 변경/추가된다면 청크 서버 내의 모든 복제본에

대해 동기화가 이루어져야 한다. 파일 쓰기가 이루어졌을 때 다음과 같은 순서로

복제본의 동기화가 이루어진다.

① 클라이언트가 마스터 서버에게 현재 사용하고 있는 청크와 또 다른 복제본들의

위치에 대한 정보를 요청한다.

② 마스터 서버가 클라이언트에게 1 차 복제본(primary replica)의 ID 와 2 차

복제본(secondary replica)의 위치 정보를 보내준다.

③ 클라이언트가 모든 복제본에 대해 데이터를 푸시한다. 각 청크 서버는 넘어온

데이터들을 저장한다.

④ 모든 복제본들이 데이터를 받은 것에 대한 완료 여부(acknowledge)가 확인되면

클라이언트는 1 차 복제본에 쓰기 요청을 한다.

⑤ 1 차 복제본은 모든 2 차 복제본에 쓰기 요청을 전달한다.

⑥ 2 차 복제본의 오퍼레이션이 완료되면 1 차 복제본에 완료 시그널을 보낸다.

⑦ 모든 2 차 복제본에서 완료 시그널이 오면 1 차 복제본은 쓰기 요청이 완료되었음을

클라이언트에게 회신한다.

<그림 7>은 이와 같은 동작의 흐름을 나타낸 그림이다. 이러한 동작은 기본적으로

컨트롤 플로우(control flow)와 데이터 플로우(data flow)가 구분되어 네트워크를

효율적으로 사용하는 방식으로 구성되어 있다.

구글 파일 시스템의 마스터 서버 오퍼레이션

- 38 -

마스터 서버는 구글 파일 시스템 내의 모든 네임 스페이스와 청크들의 복제본에 대한

관리를 처리한다. 마스터 서버에서 진행되는 오퍼레이션들을 간단하게 살펴보면

다음과 같다.

• 네임 공간에 대한 관리 및 락킹(locking)

- 네임 공간은 풀 패스 명(full path name)의 맵핑 테이블에 의해 관리된다.

- 읽기/쓰기가 발생할 때 lock 처리를 해 conflict 가 발생하는 상황을 방지한다.

• 복제본 배치

- 청크의 복제본을 데이터의 신뢰성과 가용성을 최대화하는 방향으로 배치한다.

- 청크의 복제본을 네트워크 사용성(utilization)을 최대화하는 방향으로 배치한다.

<그림 7> Write Control and Data Flow

• 청크와 복제본에 대한 관리

- 새로운 청크를 생성할 때 청크 서버의 디스크 사용 수준이나 최근 영역의 분포 등을

확인하여 생성한다.

- 오류가 발생하여 복제본 간의 내용이 맞지 않다면(corrupted 되었다면) 정상적인

복제본을 재배포한다.

- 39 -

- 청크 서버의 디스크 상태와 부하(load) 상태를 확인하여 좀 더 나은 상태의 청크

서버로 복제본을 재분산(rebalancing)한다.

<그림 8> 구글플렉스의 논리적 구조

<그림 9> 구글의 주요 기술 요소들을 나타내는 다이어그램

- 40 -

• 가비지 컬렉션

- 파일 삭제가 일어나면 마스터 서버에 삭제 시간을 비롯한 정보가 로그로 남는다.

실제 청크 서버에서는 파일 삭제가 바로 이루어지지 않고, 히든 타입으로

리네임(rename) 처리가 된다.

- 마스터 서버에서는 청크 네임 공간 스캔을 통해 3 일 이상된 히든 타입의 파일들을

삭제한다.

- 파일이 네임 공간에서 삭제되면 마스터 서버의 메타 데이터가 삭제된다.

구글 파일 시스템의 오류 복구

마스터 서버와 청크 서버는 각각 메모리에 올라갈 수 있는 수준의 메타 데이터를

가지고 있다. 서버에 문제가 생겨서 재시작되는 경우 빠른 시간 안에 재동작을 할 수

있는 상황으로 복구될 수 있다.

각 청크는 여러 대의 서로 다른 랙(rack)에 위치한 청크 서버에 복제본을 기본적으로

3 개 배치한다. 각 청크들은 체크섬 버전 정보를 가지고 관리되며 이에 의해 각 복제본

간의 동기화 작업이 이루어진다. 데이터를 읽기 위해 접근한 청크 서버가 문제가

있다면 또 다른 청크 서버에 담겨있는 복제본에 의해 데이터 읽기 작업은 무사히

수행될 수 있다.

마스터 서버 역시 마스터 서버에서 일어나는 모든 오퍼레이션의 로그와 상태(state),

체크 포인트들은 여러 대의 머신으로 복제한다(Shadow master 라고 불린다). 마스터

서버의 디스크에 오류가 있거나, 외부 모니터링 툴에 의해 이상이 발견되는 경우

복제된 마스터 서버에 의해 파일 시스템 오퍼레이션은 정상 수행되도록 조정된다.

구글 파일 시스템은 구글 검색엔진과 서비스에 적합하도록 심플하고 효과적인 파일

시스템으로 설계되어 있다. 구글에서 일어나는 대부분의 데이터 액세스는

추가(append) 중심의 쓰기 작업과 빈번한 읽기 중심의 작업들이고, 저가의 머신에

의한 클러스터(cluster) 구성이기 때문에 오류 처리 역시 중요한 이슈가 된다.

- 41 -

구글의 파일 시스템은 시스템 내의 중심적인 읽기/쓰기 패턴을 명확하게 정의하고

오류 처리를 중심으로 견고하고 효과적으로 설계되어 있다. 검색엔진에서 하부 저장

구조라는 것은 검색엔진 자체의 성능을 뛰어넘도록 하고 검색엔진 자체의 안정성을

확장하는 요소로, 구글이 갖고 있는 효율적인 하부 저장 구조는 구글의 기반을 다진

핵심 기술 요소 중 매우 중요한 요소로 볼 수 있다.

모든 기술을 아우르는 거대한 프레임워크

지금까지 구글이 갖고 있는 기술들 중에 핵심 기술(core technology)이라고 불릴 수

있는 요소들에 대해 간략하게 살펴보았다. 이 기술들은 현재의 구글을 있게 만든

구글만의 독자적인 기술임에 틀림없다. 하지만 구글의 기술은 이것이 전부가 아니다.

구글은 모든 애플리케이션과 기능들을 웹 중심(web-centric)으로 흡수하기 위한

작업을 하고 있다. 그 기반에는 구글의 기술들을 모두 아우르는 거대한 프레임워크가

존재한다.

구글플렉스

구글플렉스(Googleplex, 구글 본사 건물의 별칭이기도 하다)는 구글의 프레임워크에서

매우 중요한 위치를 차지하는 요소이다. 구글플렉스는 동일한 개체들이 모여 거대한

시스템을 구성하는 논리적 구조이다. 하나의 서버는 다른 서버들과 기능과 속성들을

공유한다. 이런 서버들이 모여서 클러스터를 구성한다. 클러스터들을 모여서 데이터

센터(data center)를 구성한다. 또 다시 데이터 센터들은 다른 애플리케이션 서버들과

모여서 구글의 온라인 시스템을 구성한다.

<그림 8>은 구글플렉스의 타이트하고 규칙적으로 조직화된 모습을 보여준다. 그림을

살펴보면 구글플렉스 내의 모든 레벨에 걸쳐 동일한 패턴이 반복되고 있음을 알 수

있다. 다시 말해 구글플렉스의 모든 구성 요소들은 동형(homogeneous)의 컴퓨팅

시스템이다. 구글 버전의 리눅스 위에서 돌아가는 구글 애플리케이션들의 집합은

슈퍼컴퓨터를 이용해 애플리케이션을 돌리는 것과 유사하다.

- 42 -

동형의 컴퓨팅 시스템은 몇 개의 장점을 갖고 있다. 모든 데이터 센터를 구성하고

있는 서버들의 구성 역시 동일한 구성이기 때문에, 시스템 규모의 확장시 단순히 서버

랙을 꽂고(plugged-in) 케이블을 연결하는 작업만으로도 셋팅과 설정(configuration)을

가능하게 한다. 앞서 살펴보았던 구글 파일 시스템 내에서 마스터가 청크 서버에

청크들을 복제하는 작업 역시 동형의 컴퓨팅 시스템에 대한 접근이므로 매우 친숙하고

쉬운 오퍼레이션으로 구현될 수 있다. 즉, 구글플렉스는 구글 파일 시스템의 기능과

목적들을 효율적이고 효과적으로 지원할 수 있는 논리적 구조이다.

구글 컴퓨팅 프레임워크

개발자들이 흔히 말하는 ‘구글스럽다’라는 말의 의미는 무엇인가. 검색 영역의

개발자와 일반 영역의 개발자가 바라보는 관점이 약간의 차이는 있을 수 있겠지만,

대부분의 경우 구글을 구글스럽게 만드는 것은 검색 기술처럼 특화된 기술 자체가

아니라 일반적이고 연구 개발적인 관점에서 접근하는 소프트웨어 공학적이면서

하드웨어 공학적인 솔루션들이 일으키는 시너지이다.

<그림 9>는 구글 프레임워크의 전체적인 모습을 나타낸 다이어그램이다. 이 그림을

보면 구글의 프레임워크에 포함되어 있는 중요한 기술들에 대해 알 수 있다.

• 대용량 파일 및 function 가속을 위해 수정된 리눅스

- 기능에 적합하게 튜닝된 리눅스를 사용한다.

• 기능 추가 및 규모 확대에 플러그인 방식에 의해 별도로 손이 가지 않을 정도로

표준화된 분산 구조

- 구글플렉스는 자기 유사 구조를 가지며, 서버의 추가와 오류에 대한 대응이 쉽다.

• 스케일 레벨(scale level)에 관계없이 유사한 기술 구조

- 동형(homogeneous) 구조에 의해 모든 요소들이 구성된다.

- 43 -

• 프로그래밍 언어에 관계없이 기능 구현이 가능한 웹 기반 아키텍처

- 프레임워크의 인터페이스로 WSDL, XML, HTML, POP3, SMTP 등과 같은 플랫폼

독립(platform-independent)적인 프로토콜을 제공한다.

<그림 10> Google's fuction: Hardware and Software Innovations

<그림 11> 구글 검색과 LostGoocle 을 이용한 검색의 비교

구글의 프레임워크는 구글 파일 시스템에 의해 구성된 데이터 센터와 분석적 방법으로

광고를 집행하는 구글 광고 시스템(Ad System), 각종 서비스 시스템(gmail, News 등),

검색엔진 등을 모두 포함한다. 구글플렉스의 외부와 내부에는 새로운 서비스 시스템과

애플리케이션들이 추가될 수 있고, 기본적인 인터페이스들을 통해 구글

- 44 -

프레임워크로의 접근과 구글 프레임워크의 기능을 사용할 수 있는 확장적이고 오픈된

구조이다(구글의 피카사(Picasa)나 구글 어스(Earth)는 로컬 머신에서 수행되는

애플리케이션을 구글 프레임워크로 포괄시키는 좋은 예이다).

조금 다른 관점에서 본다면, 구글 프레임워크는 소프트웨어 공학과 하드웨어 공학의

접점에 놓여 있다. 소프트웨어적인 관점에서 성능을 확보하면서 동시에 하드웨어

공학적인 관점에서 비용 절감을 위한 기술들을 모두 포함한다. 이는 비용 절감,

저가형 하드웨어, 스마트한 소프트웨어에 대해 집중하는 구글 문화의 주요 부분이다.

구글 프레임워크는 구글을 여타 다른 경쟁업체와 차이를 갖도록 하는 명확한 요소이다.

구글플렉스는 구글 파일 시스템과 구글이 지향하는 성능과 비용절감의 측면에서 매우

효율적인 구조이다. 서버 랙이나 데이터 센터가 오류를 일으키더라도 데이터의

손실이나 구글플렉스 전체의 다운은 방지된다. 또한, 동형 시스템의 사용으로 인해

머신의 설치 과정이나 설정(configuration)의 표준화와 자동화를 가능케 했다. 이는 타

업체가 소프트웨어 중심의 튜닝이나 하드웨어의 업그레이드에 의존해 성능과 안정성을

유지하는 모습과는 상당한 차이를 보인다.

구글의 프레임워크는 또한 구글 내의 개발자는 물론, 일반적인 개발자들에게 아주

좋은 장난감 꾸러미(toy box)이다. 구글 프레임워크의 인터페이스를 통해 언제

어디서나 웹과 연결된 환경이라면 구글의 강력한 기능을 그대로 활용할 수 있는

것이다. 이러한 확장적이고 오픈되어 있는 프레임워크 구조는 많은 개발자들의 호응을

얻고 있다.

구글 APIs

구글은 개발자들이 쉽게 구글 프레임워크에 접근할 수 있는 API set 을 제공한다.

구글이 갖고 있는 기술에 쉽게 접근하여 방대한 데이터와 강력한 기능들을 사용할 수

있는 구글 API 는 개발자들에게 매력적인 요소일 수밖에 없다. 앞서 1 부에서 소개한

것처럼 구글에서는 다양한 API 들을 제공하는데, 여기서는 가장 대표적으로 사용되고

있는 구글 웹 검색 API 에 대해 살펴보겠다.

- 45 -

구글 웹 검색 APIs

구글 웹 검색 API 는 SOAP 과 WSDL 표준을 기반으로 구글과 통신할 수 있는 방식을

제공한다. 개발자는 어떤 프로그래밍 언어를 사용하든 상관없이 구글과의 프로토콜만

맞춰줌으로써 구글의 기능을 그대로 사용할 수 있다. 구글 웹 검색 APIs

페이지(http://www.google. com/apis/)에는 다음과 같은 프로그래밍 아이디어들이

기재되어 있다.

- 주제에 맞는 새로운 정보에 대한 자동 모니터링

- 시간의 흐름에 따른 마켓 분석과 트렌드 분석

- 온라인 게임의 개발 - 새로운 검색 UI 의 개발

- 구글의 스펠 체크 기능을 애플리케이션에 추가

<표 3> 구글 웹 검색 APls 를 통한 검색 요청에 사용되는 기본적인 파라미터

파라미터

명 설명

key 구글 인증키. APls 를 다운받은 후 구글로부터 메일로 인증 키를

받아야 한다.

q 질의어

start 검색 결과 중 불러올 index 번호. 0 부터 시작

maxResults 한 페이지에 최대로 불러올 검색 결과의 건 수

filter 검색 결과 중 특정 결과들을 필터하기 위한 조건

restricts 구글 웹 색인 중 서브 셋을 검색하기 위한 조건

safeSearch 성인 필터링을 위한 Boolean 파라미터

lr 언어 제한. 특정 나랏말로 된 문서만을 검색하기 위한 조건

- 46 -

구글 웹 검색 APIs 는 SOAP 을 사용하는 웹 서비스 모델과 만나면 굉장한 효과를

발휘할 수 있다. LostGoogle(http://lostgoggles.com) 은 구글 API 를 이용하여 웹

검색 결과에 해당 페이지의 스크린샷을 썸네일로 제공한다. 만약 LostGoogle 을

이용하여 아마존닷컴(http:// www.amazon.com)의 내용을 검색하고자 하면

아마존닷컴에서 웹 서비스로 제공하고 있는 요소들과 합쳐져 도서에 관련된 훨씬 더

풍부한 정보 도서의 형태, 가격, 인기도 등을 볼 수 있다.

구글 웹 검색 APIs 를 통한 검색 요청

구글 웹 검색 APIs 를 통해 구글로 검색 요청을 보내기 위해 사용하는 기본적인

파라미터는 <표 3>과 같다. 질의어 파라미터에 해당되는 는 <표 4>와 같은 형식으로

기술할 수 있다. 부수적인 qualifier 들을 사용함으로써 검색 결과를 특정 조건에 맞게

필터링할 수 있다. 파라미터들을 이용하여 SOAP 을 구성한다면 <화면 2>와 같은

형식으로 구글에 리퀘스트를 날리게 될 것이다.

<화면 2> SOAP 으로 구성된 구글 검색 요청

- 47 -

<화면 3> SOAP 으로 구성된 구글 검색 결과 포맷

<표 4> 질의어 파라미터의 기술 형식

쿼리의 성격 예제 설명

특정 질의어를 Star Wars Episode +1 일번적인 질의어에 "+ 특정

- 48 -

포함 질의어"를 붙여 일반적인

질의어와 특정 질의어가 모두

출현한 검색 결과만을

출력한다.

특정 질의어를

제외 bass-music

일반적인 질의어에 "- 특정

질의어"를 붙여 일반적인

질의어는 출현하지만 특정

질의어가 출현하지 않는 검색

결과만을 출력한다.

특정 어구 검색 "yellow pages" 특정 어구가 출현한 검색

결과만을 출력한다.

Boolean or 검색 vacation london OR paris

"word A OR word b" 는

word A 와 word B 에 대해

Boolean or 검색 결과만을

노출한다.

사이트 제한

검색

admission site:

www.stanford.edu

특정 domain 에 포함되어

있는 도큐먼트에 대한

결과만을 노출한다.

날짜 제한 검색 Star Wars

datarange:2452122-2452234

Jullian Date 포맷으로 입력된

날짜 기간동안 생성된 웹

페이지드에 대한 검색

결과만을 노출한다.

제목 검색(팀) intitle:Google search

"intitle:" 바로 뒤에 명시된

질의어가 제목에 출현한 검색

결과만을 노출한다.

제목 검색(전체) allintitle:Google search

"alltitle:" 뒤에 명시된 모든

쿼리 팀들이 제목에 출현한

검색 결과만을 노출한다.

URL 검색(팀) inurl: Google search

"inurl:" 바로 뒤에 명시된

질의어가 URL 에 포함되어

있는 웹 문서만을 노출한다.

URL 검색(전체) allinurl: Google search

"allinurl:" 로 시작되는

질의어의 경우 명시된 모든

질의어가 URL 에 포함되어

있는 웹 문서만을 노출한다.

텍스트만 검색 allintext: Google search "alltext:"로 시작되는

- 49 -

질의어의 경우, 명시된

질의어가 웹 문서의 body

text 부분에서 출현한

문서만을 노출한다.

링크만 검색 allinlinks: Google search

"allinlinks:"로 시작되는

질의어의 경우, 명시된 모든

질의어가 앵커 텍스트에서

출현한 문서만을 노출한다.

파일 타입 포함

필터링

Google filetype: doc OR

filetype:pdf

"filetype:" 뒤에 명시된 파일

타입을 포함하고 있는

문서만을 노출한다.

파일 타입 제외

필터링

Google filetype: doc-

filetype:pdf

"-filetype:" 뒤에 명시된 파일

타입을 포함하지 않는

문서만을 노출한다.

웹 문서 정보 info:www.google.com

특정 URL 에 해당되는

페이지 하나만을 검색 결과로

노출한다.

역 링크 link:www.google.com 특정 URL 에 역 링크하고

있는 페이지들을 노출한다.

관련 링크 related:www.google.com 특정 URL 의 페이지와

유사한 페이지들을 노출한다.

캐시된 결과

페이지 cache:www.google.com web

구글이 수집하여 캐시해 놓은

페이지를 보여준다. 특정

질의어와 함께 입력되면 해당

질의어에 하이라이팅 처리를

해준다.

구글 웹 검색 API 를 이용한 검색 결과의 수신

SOAP 을 이용하여 리퀘스트를 날리면, 구글은 SOAP 으로 검색 결과를 회신한다.

회신되는 결과에 포함되는 주요 정보들은 다음과 같다.

<summary>

- 50 -

- 검색결과가 ODP 디렉토리 내의 리스트의 경우, ODP 서머리에 해당되는 텍스트

스트링

<URL>

- 검색 결과의 URL path

<snippet>

- 검색 결과 웹 페이지 중 입력된 질의어가 출현한 부분을 볼드 처리하여 추출한 웹

페이지 컨텐츠의 일부 스트링

<title>

- 검색 결과의 타이틀

- 캐시된 페이지의 KB 크기

<relatedInformationPresent>

- related: 요청에 대한 true/false 값

<hostName>

- 필터링이 수행되어 한 호스트에서 두 개의 결과가 노출되는 경우, 두 번째 결과에

추가적으로 호스트 네임이 기술된다.

SOAP 에 의해 넘어온 검색 결과는 <화면 3>과 같은 형태가 될 것이다. 구글 웹 검색

APIs 를 다운로드하면 자바로 작성된 간단한 패키지가 포함되어 있다. 이것은 자바를

통해 SOAP 메시지를 구성해 구글과 간단하게 통신할 수 있는 환경을 제공한다. 굳이

자바뿐 아니라 SOAP 처리를 위한 기타 프로그래밍 언어의 라이브러리도 다수

공개되어 있으니 개발자가 편의에 맞는 언어를 선택해 SOAP 프로토콜을 처리하는

데에는 그리 큰 어려움이 없다.

구글만이 가진 튼튼한 인프라 구조

지금까지 구글의 핵심 기술이라고 불릴 수 있는 요소들에 대해서 간략하게나마

살펴보았다. 검색에 대한 기술들이 상당 부분 오픈되어 있는 현재 상황으로 볼 때,

검색 기술에 대한 진입 장벽은 많이 높은 편이 아니다. 그럼에도 불구하고 구글이

검색 업계에서 독보적인 위치를 차지할 수 있는 것은 구글만이 갖고 있는 핵심

기술들이 선구적이고 핵심에 집중하며 멈추지 않고 성장하고 있기 때문이다. 게다가

- 51 -

그 기술들은 숨겨져 있는 것이 아니라 많은 개발자들을 위해 개방되어 있다. 구글의

기술이 개발자들에게 전파되고 전파된 기술들이 역으로 다시 구글을 발전시킨다.

사용자들이 흔히 말하는 바와 같이, 구글의 서비스가 구글스러울 수밖에 없는 것은

구글만이 갖고 있는 인프라 구조들이 버티고 있기 때문이다. 최하단의 인프라

구조들과 그것을 아우르는 프레임워크, 그리고 구글이 기술을 바라보는 철학이

최상단의 서비스에 영향을 미치고 있는 것이다.

제공 : DB 포탈사이트 DBguide.net

출처명 : 마이크로소프트웨어 [2005 년 10 월]

- 52 -

All about google!

특집 1 부 | 개발자, 구글 신드롬에 빠지다

특집 2 부 | 성공의 원천, 탄탄한 기술 인프라 대해부

특집 3 부 | 구글의 숨은 경쟁력 운영과 마케팅

특집 4 부 | 구글의 이면, 최강의 해킹 툴

특집 5 부 | 리얼가상 스토리 ‘빽투더 구글 퓨처’

특집 3 부 구글의 숨은 경쟁력 운영과 마케팅

김혜영 | 다음커뮤니케이션 검색본부 서비스 기획팀

구글 경쟁력의 중요한 축 가운데 하나가 바로 운영과 마케팅이다. 혁신적인 검색

기술을 수십억 달러의 기업 실적으로 연결시킬 수 있었던 동인에 대해 분석해 보고

많은 이용자들의 지지를 받고 있는 구글의 서비스 운영 노하우와 구글 만의 독특한

마케팅 기법들을 살펴본다. 국내 검색 시장에서 구글이 갖는 의미도 짚어본다.

2004 년 85 달러로 기업공개(IPO)가 진행된 이후 최근 구글의 주가는 300 달러를

넘어섰다. 어느 덧 시가 총액 80 억 달러가 넘는 거대기업으로 성장한 구글. 이제

나스닥에서는 시가총액이 구글을 넘는지를 가지고 기업의 규모를 판단할 정도이며

이런 현상을 두고 구글(Google)과 척도라는 뜻을 가진 바로미터(barometer)라는

단어를 합성한 ‘구고미터(Googometer)’라는 신조어까지 등장했다.

구글은 증시에서 뿐만 아니라 서비스적인 차원에서도 두터운 마니아 층을 확보하고

있다. 물론 기술력이 뒷받침됐기에 가능한 것이었지만 단순히 기술이 월등하다고 해서

그 서비스가 시장에서 파괴력을 갖는 것은 아니라는 것을 수많은 기업의 사례에서

쉽게 확인할 수 있다. 그렇다면 이처럼 급속도로 성장하고 있는 구글의 성장 동력은

- 53 -

어디서 나오는 것일까. 구글은 기술력을 자본으로 전환하기 위해 어떤 비즈니스적인

수익구조를 가져가고 있으며, 또 생산한 제품을 고객에게 어떤 식으로 어필하고

있을까. 그 동안의 구글의 행보를 되짚어보며 구글 경쟁력의 또 다른 중요한 축인

운영과 마케팅 측면을 살펴보자.

야후 신화를 넘어

실적 발표에 따르면 구글은 올 상반기 총 26 억 4000 만 달러가 넘는 매출액을

기록했다. 창사 이래 반기 실적으로는 최대치였으며 지난 해 동기간 대비 97%가

성장한 수치다. 특히 <그림 1>처럼 상반기 24 억 3000 만 달러의 매출액을 기록한

야후보다도 2 억 달러 가까이 앞선 규모이다(순이익 면에서는 야후에 비해 약간

뒤졌다).

구글 매출의 99%는 검색엔진 기술을 기반으로 검색광고를 통해 창출된다. 그 99%에

해당하는 26 억 1000 달러의 검색광고를 더 자세히 들여다보면 그 중 53%인 13 억

9000 만 달러가 구글 자사 사이트의 검색광고 수주를 통해서 이루어졌으며, 47%는

구글의 네트워크 사이트를 통해서 이루어졌다.

이처럼 구글이 검색광고 비즈니스를 통해 급성장할 수 있었던 데는 인터넷 검색광고

시장 자체의 대폭적인 확대가 크게 기여했다. 이는 기본적으로 인터넷 광고 시장의

규모와 맞물려 있는데 메릴린치는 올초 보고서를 통해 2005 년 미국 인터넷 광고

시장이 전체 광고 시장의 19%까지 늘어날 것이라고 전망한 바 있다. 이는 지난 해

3.7%에 비하면 큰 폭으로 성장한 것이다.

최근 미국의 한 조사기관에 따르면 소비자들이 TV 를 보는 시간과 인터넷을 이용하는

시간은 거의 비슷해진데 반해 광고주들이 인터넷 광고에 사용하는 광고 예산은 TV

매체와 같은 기존 광고 매체에 비해 턱없이 적다고 한다. 즉 더 많은 기업들이 더

소비자에게 가깝게 접근하기 위해 인터넷 광고 시장으로 눈을 돌릴 예정이라는 것이다.

- 54 -

인터넷 광고 시장 내에서 검색광고는 이용자 타겟과 광고효과가 분명하다는 이점을

바탕으로 광고주들에게 호응을 얻음으로써 일반적인 노출 위주의 광고(Display Ad)에

비해 더 빠른 속도로 증가하고 있다. 주피터 리서치에 의하면 검색광고는 2004 년

미국 전체 인터넷 광고 중 약 39% 정도(약 31 억 달러)의 비중을 차지했으며

2009 년에는 노출 광고와 같은 수준으로 시장 점유율이 늘어날 것으로 보인다.

2010 년경에는 51% 정도(약 75 억 달러)로 노출 광고를 추월할 것으로 전망했다.

이렇게 검색광고 시장이 빠르게 성장하는 것은 검색광고 기법 자체가 타겟 광고를

하기에 매우 적합하고 CPC(Cost-Per-Click)형 광고가 줄 수 있는 효과들이 계속

검증되기 때문이다. 이런 검증된 효과를 기반으로 광고주층 자체도 소액광고주

위주에서 온/오프라인 크로스 미디어형 브랜드 광고를 같이 집행하려고 하는 대형

광고주까지 확대되고 있다.

<그림 1> 구글 vs. 야후 매출액과 순이익 비교

- 55 -

<그림 2> 미국 온라인 광고 시장 변화

야후의 반격

외부적으로 검색광고에 대한 시장 수요가 늘어나는 것도 구글의 매출 증대에 크게

기여하고 있지만 내부적으로 구글의 서비스 볼륨 자체도 검색광고 매출 성장에

직접적으로 큰 영향을 주었다. 검색 업계에서 시장점유율 지표 중 하나로 사용하고

있는 ‘검색엔진 유입률’을 비교해보면 구글은 올해 6 월을 기준으로 전체 미국

검색시장에서 50% 이상의 높은 시장점유율을 보이고 있다. 검색엔진 유입률 리서치를

진행한 WebSideStory 에 따르면 구글의 시장점유율은 유럽 국가들에서는 더 높은

비율을 보이고 있다고 한다. 구글 UK 에서는 73.61%, 구글 독일에서는 무려

91.11%의 검색엔진 유입률을 보였기 때문이다.

검색엔진 유입률이란 각 검색엔진을 통해 홈페이지에 접속하게 되는 비율로, 유입률이

늘어났다는 것은 더 많은 이용자들이 해당 검색엔진 검색결과를 접하고 있다는

의미이다. 또한 해당 검색엔진에 페이지나 사이트가 등록된 광고주 입장에서는 해당

검색엔진을 통한 광고 효과가 극대화될 수 있다는 것을 뜻한다. 최근 5 년간 구글의

- 56 -

시장점유율 변화를 보면 <그림 3>과 같이 2002 년을 기점으로 경쟁사 야후와의

시장점유율 격차가 점점 벌어지고 있다.

<그림 3> US 검색엔진 유입률 추이

<그림 4> 구글 분기별 매출액 추이

- 57 -

이처럼 구글의 검색광고가 크게 성공할 수 있었던 것은 구글 검색의 이용량이

폭발적으로 늘어났기 때문이기도 하지만 애드센스(AdSense) 프로그램을 통해서 더

광범위한 구글 광고 네트워크를 구축했다는 점도 큰 작용을 했다. 실제로 분기별 구글

매출액 추이를 살펴보면 일반 웹 사이트 운영자들이 자신의 사이트에 구글 검색광고를

게재하고 수익을 얻을 수 있도록 하는 프로그램인 애드센스를 출시한 2003 년 2 분기

이후부터 구글 네트워크 사이트의 검색광고 매출 성장률이 최대 48%까지 증가한 것을

확인할 수 있다. 2004 년 2 분기에는 구글 네트워크 사이트의 검색광고 매출이 구글

자체 사이트를 더 앞섰다. 최근 2005 년 2 분기에 발표된 실적에서도 구글 네트워크

사이트에서의 검색광고 비율은 전체 검색광고 중 47%에 이를 만큼 여전히 중요한

비중을 차지하고 있다.

경쟁사인 야후 또한 구글 애드센스가 출시된 직후 검색엔진 마케팅 업체인

오버추어(Overture)를 인수함으로써 대규모의 검색광고 네트워크를 구축했다. 그러나

그동안 오버추어의 광고 제휴는 주로 대규모 사이트들과의 개별적인 계약을 통해

이루어졌기 때문에 제휴 자체가 자동화돼 웹 컨텐츠 사이트들이 광고 네트워크로 쉽게

편입될 수 있는 구글과는 네트워크의 절대량에서 근본적인 차이가 있다. 최근 야후가

‘야후 퍼블리셔 네트워크(Yahoo! Publisher Network)’라는 프로그램을 베타 런칭한

것도 구글이 그랬던 것처럼 소규모 1 인 미디어 사이트나 커뮤니티들을 자사의 광고

네트워크 안으로 흡수하기 위한 방안이다.

야후가 구글의 고유영역이었던 소규모 사이트에 대한 광고 제휴시장에까지 뛰어들자

구글도 자사의 광고 제휴 네트워크를 강화하기 위한 노력에 나섰다. 최근 구글은

광고주와 웹사이트 운영자들의 다양한 요구사항을 반영하는 과정에서 특정 사이트를

지정해서 노출 기반의 광고(CPM, Cost-Per-Milleni um)를 집행할 수 있도록 하는

광고 상품 옵션을 추가했으며 그동안 지원하지 않았던 이미지 배너도 광고 게재

형식의 하나로 추가했다. 구글의 이런 변화는 인터넷 광고 시장에서 또 다른 한

부분을 차지하고 있는 노출 기반의 배너 광고 비즈니스 모델을 기존 광고 네트워크에

도입함으로써 자사 광고 네트워크의 수익구조를 더 탄탄히 하기 위한 것으로 해석된다.

또한 구글은 최근 블로그의 RSS 피드에도 구글 광고를 추가할 수 있는 기술을 개발해

특허 출원을 한 상태이며, 오프라인 인쇄매체의 광고 사업에도 관심을 보이고 있다.

- 58 -

즉 기존 네트워크에 다양한 형식의 광고 상품을 도입함과 동시에 광고 노출 채널

자체를 RSS 피드나 오프라인 인쇄 매체 등으로 확대시켜 나가려는 것이다.

구글의 운영과 마케팅의 비밀

구글이 이런 비즈니스적인 네트워크를 구축하고 확대해나갈 수 있는 것은 기본적으로

자사의 서비스가 많은 이용자들의 사랑을 받으며 항상 일정 수준 이상의 서비스적인

볼륨을 유지해나가고 있기 때문이다. 그렇다면 구글은 자사의 서비스를 운영하는데

있어서 어떤 원칙과 마케팅 노하우를 지니고 있을까.

게이트웨이로서의 검색

구글 관련된 인물로 국내에 잘 알려진 구글의 웹마스터 데니스 황은 한 인터뷰에서

구글은 ‘사용자가 원하는 정보로 쉽고 빨리 갈 수 있게 해주는 것’을 목표로 한다고

밝힌 바 있다. 즉 검색 서비스 본연의 기능에 해당하는 게이트웨이로서의 검색에

충실하고자 한다는 점이다. 이런 서비스 원칙은 구글을 이해하는데 있어서 매우

중요한 요소가 된다. 빠르게 잘 찾아줄 수 있는 검색의 품질을 강조하면서도 검색

서비스를 자사의 사이트에 오래 머무를 수 있는 수단으로 사용하고 있는 국내 포탈

사이트와 비교해 볼 때 구글은 매우 색다른, 오히려 정반대의 길을 걷고 있기

때문이다.

구글도 일반적인 포탈들처럼 gmail(메일), Google Groups(커뮤니티), Blogger(1 인

미디어), Google Talk(메신저), Picasa(포토 관리 소프트웨어) 등과 같은 커뮤니케이션

서비스를 순차적으로 오픈했다. 그러나 통합 인터넷 서비스 업체가 되고 있는 구글의

빠른 행보에도 불구하고 아직까지 구글 메인 화면은 <화면 1>처럼 심플한 검색창

UI 로 구성돼 있다.

물론 구글 랩(Google Labs)에서 테스트 중인 구글의 개인화 홈페이지에는 <화면 2>와

같이 gmail, 구독중인 RSS 피드 리더기 기능 등이 들어가 현재의 구글

메인화면보다는 복잡해질 가능성도 없지는 않다. 그러나 개인화 Top 이라는 컨셉

- 59 -

자체가 이용자가 관심 있어 하는 정보들을 한 자리에서 빠르게 확인할 수 있고

원본으로 가는 링크를 제공하는 의미이기 때문에 (그것이 구글 내부 서비스이든

아니든) ‘게이트웨이로서의 검색’이라는 서비스 원칙에서 크게 벗어나지 않을 것으로

예상된다.

끊임없이 변화하는 서비스

항상 변함없는 구글 첫 화면의 심플한 UI 가 일관성 있는 구글의 서비스 원칙을

말해주고 있다면 첫 화면의 메인 디자인이라고 할 수 있는 구글 로고는 기념일 등의

시기에 따라 다양하게 변하면서 내부적으로 끊임없이 이용자와 커뮤니케이션하고자

하는 구글의 의지를 보여준다.

또한 구글의 신규 서비스 인큐베이팅 공간인 구글 랩(Google Labs)의 경우

지속적으로 새로운 실험들을 시도하면서 이용자들과 커뮤니케이션하는 구글의

끊임없는 변화 노력을 이용자들이 쉽게 읽을 수 있는 기제가 되고 있다.

<화면 1> 구글 메인 화면

- 60 -

<화면 2> 구글 랩에서 베타서비스 중인 개인화된 메인 화면

입소문 마케팅 전략

구글이 새로운 서비스를 베타 혹은 정식 버전으로 내놓을 때마다 별다른 온/오프라인

마케팅 없이도 금새 네티즌들의 사이에서 화제가 되는 이유는 무엇일까. 구글이 지닌

다음과 같은 특징들이 입소문 마케팅을 효과적으로 할 수 있는 조건으로 작용했기

때문이다.

- 61 -

<화면 3> 올해 선보인 구글 로고들

첫 번째, 구글은 자사의 서비스를 크게 떠들어줄 막강한 1 인 미디어 네트워크를

보유하고 있다. 이미 미국인들 사이에서 구글(Google)이라는 말은 검색(Search)과

비슷한 의미의 일반명사로도 사용되고 있을 정도로 많은 검색 이용자층을 확보하고

있다. 이 중에 일명 ‘구글 마니아’라고 불릴 수 있는 블로거들은 구글의 작은 변화에도

큰 관심을 갖고 자신의 미디어 파워를 기반으로 입소문 마케팅의 전도자로서 나서고

있다.

그들은 구글의 신규 서비스나 사업적인 액션에 대해 적극적으로 리뷰하기를 좋아하며

구글 검색결과에서 자신의 블로그가 어떤 위치에 랭크되는지에 대해서도 큰 관심을

갖고 있다. 이런 관심은 ‘구글 댄스(Google Dance)’라는 신조어까지 만들어 냈는데

이는 ‘춤 출 정도로 기쁘다’는 의미로 구글의 검색순위가 오른 사람이 기뻐하는

모습에서 나왔다.

- 62 -

두 번째, 구글은 네티즌들이 관심을 가질 만한 기념일을 재치 있게 활용한다. 지난 해

구글은 미국 포탈업계 최초로 1GB 짜리 무료 웹 메일 서비스 Gmail 오픈을 만우절에

단행했다. 경쟁 업계에서는 구글의 이메일 서비스 진출에 대해 긴장하는 반응을

보였지만 네티즌들은 그 동안 무료 이메일 용량으로는 상상할 수 없는 수준의

용량이었기 때문에 만우절 농담이 아니냐는 식의 놀라움을 표현했다. 그리고 1 년이

지난 올해 만우절에 구글은 야후의 이메일 용량 확대를 의식한 듯 Gmail 의 기본

용량을 2GB 로 올렸다. 이런 기념일 마케팅을 통해 Gmail 은 만우절 농담 같은 놀라운

서비스 제안으로 이용자들에게 빠르게 소문이 난 것이다.

구글의 아이디어 넘치는 기념일 마케팅은 아폴로호의 달 착륙을 기념하는 7 월

20 일에도 또 다시 효과를 발휘했다. NASA 에서 공개한 일부 달 표면 사진을 구글

지도 서비스에 추가해서 아폴로호에 탑승했던 승무원들의 기록들을 제공해준 것이다.

이 서비스는 구글 지도 서비스뿐만 아니라 인공위성 사진을 토대로 서비스를 제공하고

있는 구글 어스(earth.google.com)의 마케팅까지 같이 하는 기념일 아이템이었다.

비교적 많은 이들에게 알려진 구글의 기념일 로고 디자인은 이제 기념일마다 구글을

찾게 하는 일상적인 장치가 되었다.

세 번째, 구글은 자사의 서비스 퀄리티를 사회적 이슈화한다. 최근 국내 포탈의 급등

인기검색어로 ‘구글 어스’라는 키워드가 자주 노출됐다. 구글이 위성사진 전문 업체인

키홀(Keyhole)을 인수해서 만든 구글 어스(Google Earth)라는 지구검색 서비스에서

우리나라나 북한의 주요 군사 기지 등이 지나치게 자세히 검색돼 국가 보안상 문제가

됐던 것이다. 또한 외교적으로 민감해 있는 동해 표기 문제 등이 이슈가 돼

이용자들의 관심을 끌게 되었다. 또한 최근 구글은 미국의 허리케인 카트리나 사태

이후에 구글 어스 서비스를 통해서 실시간으로 재해 상황들을 파악할 수 있도록 돕고

또 카트리나로 인해 헤어진 이재민을 찾아주는 구글 서비스(Google Hurricane

Katrina)를 런칭해 사회적인 이슈에 발빠르게 대응했다. 8 억 건이라는 방대한 양의 웹

문서를 검색대상으로 하고 있기 때문에 구글 검색에서 자신의 이름으로 검색해 보면

본인도 몰랐던 개인의 자취들이 검색돼 사생활 침해의 우려가 된다는 기사들은

언론에도 자주 보도가 됐다.

- 63 -

<화면 4> 구글 랩

<화면 5> 아폴로호 달 착륙을 기념해서 제작된 Google Moon 서비스

- 64 -

<화면 6> 구글 어스에서 제공한 지구 사진

<화면 7> 구글 허리케인 카트리나 검색서비스

이용자들은 이런 사회적인 이슈가 일어날 때마다 문제의 해당 서비스에 대해서 궁금해

하고 서비스를 체험해보기를 원한다. 물론 국가 보안 문제나 사생활 침해 문제는

- 65 -

검색엔진에서 꼭 해결해야 할 사항이기는 하지만 너무나 잘 찾아서 문제가 되는

상황이 사람들의 입을 통해 전달되면서 구글은 별도의 돈을 들이지 않고도 서비스

퀄리티에 대한 마케팅을 자연스럽게 할 수 있게 된 것이다.

국내 시장에서 아직 검증 전

올 여름 구글이 온/오프라인에서 본격적으로 마케팅을 펼치면서 국내 이용자들의

구글에 대한 관심이 높아지고 있다. 업계 관계자들도 구글이 국내 검색 시장에서 어떤

행보를 보일지 내심 긴장하고 있는 눈치다. 통합검색, 지식검색, 편집 컨텐츠 검색

등으로 대표되는 한국 검색 서비스의 특성이 대용량 웹 문서 검색이 주가 되는 미국과

다르기는 하지만 구글은 막강한 자체 기술력과 그동안 인수합병 및 자체 개발을 통해

확보해 놓은 다양한 검색자원이 있기 때문이다. 또한 검색 사용량이 많고 인터넷

서비스에 능통한 국내 인터넷 얼리어답터들 중 일명 구글 마니아 성향을 가진 이용자

층이 꽤 두텁게 형성되어 있다. 이런 시장 환경에서 구글은 한국 검색서비스 시장에서

얼리어답터적인 이용자 층을 기반으로 틈새시장 마케팅을 본격적으로 펼칠 가능성이

있다.

한편 비즈니스적인 측면에서 구글이 한국 시장에서 자리를 잡기 위해서는 야후의

자회사인 오버추어라는 강적을 넘어서야 한다. 오버추어는 2003 년부터 국내 시장에서

활발한 제휴 활동을 펼쳐 현재 다음, 네이버, 야후코리아, 네이트, 드림위즈 등 국내

주요 검색포탈을 중심으로 한 방대한 파트너 네트워크를 가지고 있다. 반면 구글은

파란과 엠파스를 확보하는데 그쳤으며 애드센스를 중심으로 한 사이트 운영자들과의

제휴도 미국에 비하면 그리 크지 않은 수준이다. 구글은 국내 지사 설립을 본격적으로

진행하고 오버추어와 국내 포탈들의 계약이 만료되는 2006 년 정도에 구글 애드워즈를

기반으로 본격적인 제휴활동에 들어갈 예정이다. 향후 1~2 년 안에 국내에서 구글의

서비스적 혹은 비즈니스적인 영향력이 얼마나 확대될 지 귀추가 주목된다.

제공 : DB 포탈사이트 DBguide.net

출처명 : 마이크로소프트웨어 [2005 년 10 월]

- 66 -

All about google!

특집 1 부 | 개발자, 구글 신드롬에 빠지다

특집 2 부 | 성공의 원천, 탄탄한 기술 인프라 대해부

특집 3 부 | 구글의 숨은 경쟁력 운영과 마케팅

특집 4 부 | 구글의 이면, 최강의 해킹 툴

특집 5 부 | 리얼가상 스토리 ‘빽투더 구글 퓨처’

특집 4 부 구글의 이면, 최강의 해킹툴

송재훈 | sSTG 시큐리티 컨설팅 팀

2005 년 1 월에 발생했던 대량 홈페이지 변조 시에도 탐지되지 않았던 웹 해킹. 그

이면에는 구글을 이용한 자동화된 웹 해킹 툴들이 있었다. 이번 호에는 자동화된 웹

해킹 툴을 간략하게 살펴보고 실제 해킹 과정에서 어떻게 구글을 이용하게 되는지를

필자의 경험을 통해 소개한다. 또한 이러한 해킹에 대응하기 위한 방안으로 웹 서버,

HTML 문서 수정 방법을 살펴보고 저장된 페이지 삭제 요청 방법 등을 알아본다.

최근 한국정보보호진흥원 내 침해사고 대응팀(KRCERT/CC)에서 발표한 ‘2005 년 6 월

인터넷 침해사고 동향 및 분석월보’에 따르면 <그림 1>과 같이 2005 년 6 월까지

신고/접수/처리된 해킹 건수는 약 2 만 2000 여 건이었다. 그 중에서 웹 해킹의 하나인

홈페이지 변조는 약 1 만 2000 여 건으로 전체 해킹 건수의 57%를 차지하고 있다.

특히 올 1 월에는 홈페이지용 공개 게시판 프로그램의 보안 취약점으로 인해 홈페이지

변조가 다량으로 발생하기도 했다.

해킹의 방법론 또는 절차에서 가장 먼저 이루어지는 단계는 보안 취약점 스캐닝이다.

이는 공격 대상 시스템에 대해서 어떤 보안 취약점인 있는지 먼저 조사하는 단계로,

- 67 -

여기서 발견된 보안 취약점들 중 실제 시스템에 침투할 수 있는 것이 존재하는지

하나씩 확인을 하게 된다. 즉 실제 침투가 이루어지기도 전에 수많은 침투 시도가

있을 수 있다는 것이다. 그러나 <그림 2>의 침해유형별 해킹사고 현황을 보면

실제와는 큰 차이가 있음을 알 수 있다.

가장 많은 홈페이지 변조가 발생했던 올해 1 월에도 실제 탐지된 침입 시도 는 100 건

이하에 불과했다. 즉 이제까지의 지식으로는 실제 발생한 침해사고 건수보다 탐지된

침입 시도의 건수가 훨씬 많아야 하지만 실제로는 그렇지 않은 것이다. 이러한 예상

밖의 현상은 웹을 통한 침입 시도는 탐지하기가 어렵거나 또는 침입 시도 없이 단 한

번의 공격만으로도 해킹이 성공한다고 생각할 수 있다. 그러나 단 한 번의 공격으로

해킹에 성공하기는 힘들다. 따라서 탐지가 쉽게 되는 방식이 아니라 다른 형태의 해킹

방법이 일반화되고 있음을 알 수 있다.

바로 그런 것들 가운데 하나가 검색엔진이다. 탐지가 쉽게 되는 웹 취약점 스캐너를

사용하는 대신 구글과 같은 검색엔진을 이용해 해킹을 하는 것이다. 이것이 어떻게

가능한 것일까. 여기서는 가상의 시나리오를 기반으로 구글의 악용 사례를 살펴보자.

가상의 해킹 시나리오

한 해커가 국내 글로벌 기업인 A 를 공격 대상으로 선정했다. 내부 시스템에 침투해

경영정보 등 기밀정보를 빼내 경쟁회사에 비싼 값에 판매할 생각이다. 우선 대외

서비스를 하고 있는 회사의 홈페이지를 1 시간 동안 조사했으나 특별한 취약점을

발견하지 못했다. 침투 경로를 웹 서버에서 다른 서버로 변경하기로 한 해커는 이

회사에서 운영하는 다른 서버를 찾기 위하여 DNS Zone transfer 를 시도했다. 하지만

역시 글로벌 기업답게 DNS 서버 설정은 완벽했다.

이어 그는 구글 검색엔진을 통해서 간단한 검색어 입력만으로 A 사에서 운영하고 있는

다른 웹 서버들을 조사했다. 몇 개의 웹 사이트들이 발견됐으며 발견한 사이트를 한

개 한 개 조사하다가 외부 직원들을 위한 VPN 접속 페이지를 발견했다. 이 페이지를

통하면 내부 네트워크까지 접속할 수 있는 것이 분명했다. 하지만 접속 아이디와

비밀번호를 알 수 없었다. 방금 전에 발견한 웹 사이트 중에 이 기업에서 만든 직원

- 68 -

교육 사이트가 있음을 확인하였다. 이 교육 사이트의 관리자 페이지에 접속할 수 있는

URL 을 구글을 이용해서 찾아냈다. 이 관리자 페이지에 접속하자 관리자 계정 ID 와

비밀번호를 물어보는 대화상자가 나타났다.

그러나 해커는 아직 관리자 계정 ID 와 비밀번호를 알지 못하므로 구글 검색 결과를

다시 하나씩 확인을 해나가는 과정에서 최근까지 관리자 페이지는 인증절차가

없었음을 확인했다. 따라서 관리자 페이지의 회원 관리 페이지에 대해 구글이

저장하고 있는 내용을 확인하기 위해 저장된 페이지를 클릭했다. 회원들의 접속 계정

ID, 평문으로 저장되어 있는 비밀번호와 메일 주소 일부를 볼 수 있었다. 회원의 메일

주소로부터 A 사의 직원인 사람만 선별하여 접속 계정 ID 와 비밀번호를 모두 따로

저장을 하였다. 이를 전에 발견한 VPN 접속 페이지에서 하나씩 VPN 접속을 위해

대입을 하기 시작했다. 약 30 분 동안 대입한 결과 교육 사이트의 접속 계정 ID 와

비밀번호, VPN 접속 계정 ID 와 비밀번호를 동일하게 사용하는 직원을 발견했고 그

결과 VPN 접속에 성공했다.

<그림 1> 2005 년 KRCERT 해킹 처리 현황

- 69 -

<그림 2> 침해유형별 해킹사고 현황

이제 내부 기밀정보가 저장되어 있을만한 시스템을 찾아야 한다. 다시 한번 구글에

접속해 검색을 한 결과 B 업체에서 데이터베이스 시스템을 구축하였다는 뉴스를 볼 수

있었으며 B 업체에서 A 에 제안하였던 구축 제안서를 B 사의 사이트에서 다운로드할

수 있었다. 구축 제안서 안의 간략한 네트워크 구성도를 통해 데이터베이스가 위치한

네트워크 대역을 확인한 해커는 데이터베이스 시스템에 존재하는 보안 취약점을

이용해 내부 기밀정보를 빼내기 위해 다시 작업을 계속했다.

구글 해킹의 사례들

앞서 언급한 것은 하나의 가상의 시나리오다. 실제로 구글을 이용한 해킹을

확인하기란 매우 어렵다. 왜냐하면 실제 해커에게는 구글은 해킹을 하기 위해

사용하는 도구의 하나이기 때문이다. 많은 검색엔진 중 구글이 특히 해커들의 주목을

받는 것은 구글이 지속적으로 로봇을 이용해 웹 사이트에 대한 정보를 수집하기

때문이다. 따라서 현재의 자료뿐만 아니라 과거의 자료 또한 구글의 저장된 페이지

기능을 이용해서 확인할 수 있다.

- 70 -

최근에 이러한 구글의 기능을 이용한 개인신상정보 유출 사례뿐만 아니라 청와대 등

국내 주요 보안시설에 대한 상세한 위성사진이 공개되어 논란이 되었던 적이 있다.

이것은 구글을 통해서 물리적, 관리적, 기술적 취약점에 대한 정보를 모두 얻을 수

있음을 의미한다. 사정이 이렇다 보니 해커들이 구글에 열광하는 것은 어쩌면 당연한

것이다.

앞서 잠깐 언급한 바와 같이 최근의 해킹은 쉽게 침입 시도가 탐지되지 않으면서

이루어지고 있다. 해커가 기존의 취약점 스캐너를 이용해 실제 공격 대상이 되는

사이트에 대해 사이트의 구조나 보안 취약점을 식별하는 대신 구글의 검색 로봇이

수집한 정보를 기반으로 구글 검색 명령어만으로 같은 결과를 얻고 있기 때문이다.

<화면 1> 구글 검색을 통한 개인신상정보 유출 사례

구글을 이용한 실제 해킹 기법

- 71 -

과거의 해킹과 달리 최근의 웹 해킹은 웹 사이트 내에 취약점이 존재하는 웹

애플리케이션이 하나라도 존재하면 이를 이용해 DMZ 또는 내부 서버로의 침투가

가능하다. 따라서 웹 해킹을 하는 해커는 웹 사이트에 존재하는 웹 애플리케이션이나

웹 사이트의 구조를 파악하는 것을 먼저 하게 된다. 기존에는 이러한 작업을

수작업으로 하거나 또는 웹 사이트의 사이트 맵 기능을 이용했다. 그러나 구글의

막강한 검색 기능으로 인해 웹 사이트 내에 관리자 페이지, 파일 업로드/다운로드

페이지 존재 여부, 압축 파일 및 임시 파일 존재 여부, 2 차 도메인 존재 여부 등을

쉽게 파악할 수 있다. 그렇다면 더 구체적인 구글 해킹 기법을 살펴보자.

<화면 2> victim.com 에 대한 검색 결과

사이트 구조 파악

만약 공격 대상 사이트의 이름이 victim.com 일 때 이 사이트의 구조와 2 차

도메인까지 검색하고 싶다면 site:victim.com 과 같이 명령어를 입력하면 된다. 그러면

<화면 2>처럼 공격 대상 사이트에 대한 가장 광범위한 결과를 얻을 수가 있다.

관리자 페이지 찾기

- 72 -

만약 공격 대상 사이트의 이름이 victim.com 이고 홈페이지 관리자 사이트의 접속

URL 을 알고자 한다면 admin site:victim.com 와 같이 입력해 URL 상에 admin 등이

들어 있는 주소가 존재하는지 확인할 수 있다. Admin 외 관리자용 접속 URL 로 많이

사용하는 이름을 이용해서 검색할 수도 있다. <화면 3>은 victim.com 에 존재하는

관리자 접속 URL 검색 결과이다. 홈페이지 관리용으로 사용되는 관리자 페이지는 그

특성상 파일 업로드를 할 수 있는 페이지가 존재하는 경우가 많다. 따라서 이

페이지에 접속을 할 수 있게 되면 이를 게이트웨이로 일명 웹 셸이라고 불리는

백도어를 업로드할 수 있기 때문에 해커들이 꼭 찾고자 하는 페이지 중의 하나이다.

<화면 3> victim.com 에서 관리자 페이지 존재 여부 확인 결과

압축/임시 및 데이터베이스 파일 찾기

실제로 해커가 웹 서버나 웹 애플리케이션 서버를 해킹한 후에 내부 DB 서버를

해킹하지 않더라도 쉽게 내부 중요정보를 획득할 수 있는 경우가 있다. 이런 경우는

웹 서버 상에 웹 애플리케이션 소스를 압축한 압축 파일을 작업 후에 삭제하지 않고

둔 경우나 데이터베이스 파일 또는 SQL 파일 등을 둔 경우이다. 해커가 웹

- 73 -

애플리케이션 소스를 얻으면 내부 DBMS 에 접속할 수 있는 DB 사용자 계정 ID 와

비밀번호를 쉽게 획득할 수 있을뿐만 아니라 관리자 페이지의 계정 ID 와 비밀번호도

종종 얻을 수 있다. <화면 4>는 filetype 이라는 명령어를 다음과 같이 입력해 공격

대상 서버에 mdb 파일이 존재하는지를 검색한 결과이다.

filetype:mdb site:victim.com

이 외에도 취약점이 존재하는 웹 애플리케이션의 존재 여부 확인, 사용자 메일 계정

ID 확인, 디렉토리 리스팅, 오류 메시지 검색을 통한 사용자 계정 ID 와 비밀번호 확인

등 다양한 방법으로 활용할 수 있다. 구글의 고급검색 기능을 이용해 취약점 명이나

취약한 파일명 등을 조합해 사용하면 쉽게 활용할 수 있다.

<화면 4> victim.com 사이트에서 MDB 파일의 존재여부 확인 결과

구글을 이용한 자동 공격툴

- 74 -

앞서 살펴본 간단한 검색 방법은 어떤 공격 대상 사이트가 정해진 후에 수작업으로

이루어지는 탐색 작업이다. 하지만 최근에는 구글의 기능을 이용하여 보안 취약점이

존재하는 모든 사이트를 검색한 후에 이를 공격하는 자동 공격툴이 개발되어 사용되고

있다. 심지어는 특정 개발 언어로 된 모든 페이지에 대해서 공격을 시도하는 자동

공격툴까지 나와 있다. 따라서 불특정 다수의 홈페이지에 대해 보안에 취약하게

개발되어 있는 사이트는 자동적으로 해킹이 되는 상황에 이르렀다. 그렇다면 국내에서

가장 많이 사용되고 있는 공개 게시판 프로그램의 중의 하나인 제로보드의 취약점을

이용한 웜이 어떻게 구글을 이용하고 있는지 알아보기로 하자. 다음은 실제

인터넷에서 쉽게 구할 수 있는 제로보드를 공격하는 인터넷 웜의 소스의 일부분으로,

공격대상인 제로보드가 설치되어 있는 위치를 찾기 위한 부분에 대한 정의 부분이다.

// search rule

#define FD_RULE_0 “/zboard/zboard.php”

#define FD_RULE_1 “/zb41/zboard.php”

#define FD_RULE_2 “/bbs/zboard.php”

#define FD_RULE_3 “/zb/zboard.php”

#define FD_RULE_4 “/zb40/zboard.php”

#define FD_RULE_5 “/board/zboard.php”

#define FD_RULE_6 “zboard.php”

#define FD_RULE_7 “zboard.ph”

다음은 보안 취약점이 존재하는 소스의 설치 위치이다.

// pattern

#define FD_PATH_0 “/zboard/skin/zero_vote/login.php”

#define FD_PATH_1 “/zb41/skin/zero_vote/login.php”

#define FD_PATH_2 “/bbs/skin/zero_vote/login.php”

#define FD_PATH_3 “/zb/skin/zero_vote/login.php”

#define FD_PATH_4 “/zb40/skin/zero_vote/login.php”

#define FD_PATH_5 “/board/skin/zero_vote/login.php”

#define FD_PATH_6 “/skin/zero_vote/login.php”

- 75 -

이처럼 제로보드가 설치되어 있는 위치와 취약점이 존재하는 소스의 위치를 이용해

다음 검색엔진을 이용해 검색을 실시하게 된다.

struct search_rule search_va[]=

{

{0,“www.google.com”,990,10,“http://”}/,

{1,“kr.search.yahoo.com”,990,15,“http://”}/,

{2,“search.nate.com”,480,10,“http://”}/,

{3,“search.lycos.com”,990,10,“//”},

{4,“kr.altavista.com”,1000,10,“//”},

{5,NULL,0,0,NULL}

};

즉 구글만을 이용하는 것이 아니고 국내의 주요 검색엔진은 모두 이용하는 것을 알 수

있다. 실제 소스에는 각 검색엔진 별로 GET 방식으로 제로보드를 검색하는 방법이

정의되어 수행되도록 고안됐다. 실제로 대부분의 사용자가 기본 설치 경로명을 특별히

바꾸지 않기 때문에 앞서 정의되어 있는 URL 만을 가지고 검색해도 쉽게 취약한

사이트를 찾을 수 있다.

<화면 5> 취약한 제로보드가 설치된 사이트 검색 결과

- 76 -

구글을 이용해 PHP 로 작성된 웹 애플리케이션을 공격하는 또 다른 웜의 소스를

살펴보자. 이 웜의 경우에는 앞서 언급한 바와 같이 특정 웹 애플리케이션을 공격하는

것이 아니고 PHP 로 작성된 모든 웹 애플리케이션을 공격하는 것이 특징이다. 다음

코드는 악용되는 것을 막기 위해 코드의 일부분이 작동되지 않도록 변조돼 있으나

개념을 이해하는 사람은 쉽게 고쳐서 사용할 수 있도록 돼 있다.

$procura = ‘inurl:*.php?*=’ . $numr;

for($n=0;$n<900;$n += 10){ $sock =

IO::Socket::INET->new(PeerAddr => “www.googl3.com.br”, PeerPort

-> 80, Proto => “tcp”) or next; print $sock

"GET /s3arch?q=$procura&start=$n HTTP/1.0\n\n”;

@resu = <$sock>;

close($sock);

일반적으로 선구자적인 해커에 의해 보안 취약점이 발견된 후 이 취약점을 공격하는

자동화된 공격툴이 개발되면 이미 이에 대해 널리 알려진 상태가 된다. 따라서 앞서

살펴본 바와 같이 구글을 이용한 자동화된 공격툴이 개발되었다는 것은 구글을 이용한

해킹 역시 이미 해커들 사이에는 성숙단계에 접어들었음을 의미한다.

구글 해킹에 대한 대응책

그렇다면 지금까지 살펴본 다양한 구글 해킹 피해를 당하지 않을 수 있는 방법은

무엇일까. 구글 해킹에 악용되지 않으려면 사용자의 웹 사이트에 대해서 구글의 검색

로봇이 검색을 하지 못하도록 설정하는 것이 가장 좋다. 그러나 검색엔진에서 웹

사이트의 URL 이 검색되지 않는다면 홍보나 마케팅 측면에서는 손해가 극심하므로

주의해야 한다.

- 77 -

<화면 6> 웝 소스 내의 검색 명령어 실행 결과

사용자의 웹 사이트 URL 제거

그러나 이런 점에도 불구하고 검색엔진 로봇이 사이트 전체에 대해서 탐색을 허용하지

않게 하려면 다음과 같은 내용의 robots.txt 파일을 웹 문서의 루트 디렉토리에

저장하면 된다. 하지만 일부 국내 검색엔진은 robots.txt 파일의 설정도 따르지 않는

것으로 알려져 있으므로 주의가 필요하다.

User-Agent: * Disallow: /

만약 구글 검색엔진에 대해서 /admin 페이지에 대한 검색만 허용을 하지 않으려면

다음과 같이 설정하면 된다. 중요한 페이지에 대해서 URL 을 제거하려면 다음과 같은

내용의 robots.txt 파일을 생성한 후에 구글의 자동 삭제 시스템을 이용하면 된다.

- 78 -

User-Agent: Googlebot

Disallow: /admin

페이지 저장 금지시키기

구글은 검색 결과를 모두 저장하게 돼 있다. 따라서 앞서 살펴본 해킹 시나리오처럼

현재는 존재하지 않은 페이지라고 하더라도 저장된 페이지 보기 기능을 이용해서

예전의 내용을 확인할 수 있다. 이러한 기능은 접근 권한이 변경된 페이지나 삭제된

페이지의 내용을 확인할 때 유용하다. 그러나 이를 통해 웹 애플리케이션 소스가

노출되거나 개인신상정보가 유출되는 경우가 있으므로 중요한 정보가 저장돼 있는

페이지는 문서의 <HEAD>태그 부분에 다음과 같은 메타 태그를 삽입시켜 방지할 수

있다.

<META NAME=”ROBOTS” CONTENT=”NOARCHIVE”>

만약 구글 검색 로봇에 대해서만 문서 저장을 금지시키고 싶다면 다음의 메타 태그를

해당 문서에 삽입하면 된다.

<META NAME=”GOOBLEBOT” CONTENT=”NOARCHIVE”>

보안상 중요한 정보가 저장되어 있음을 확인한 경우라면 먼저 해당 페이지에 앞의

메타 태크를 삽입한 후 구글의 자동 제외 시스템을 사용해 삭제를 요청해야 한다.

그렇지 않으면 구글의 검색 로봇이 다시 방문할 때까지 기다려야만 한다.

인증과 권한 점검

- 79 -

웹 사이트를 관리하기 위한 관리자 페이지가 관리자 계정 ID 와 비밀번호 없이도

접속이 가능한 경우가 있다. 또는 일반 사용자로 인증을 받은 후에 사용자 접근

권한을 점검하지 않아 관리자 접속 페이지의 URL 만 알면 바로 접속이 가능한 경우도

있다. 이 중 특히 전자의 경우에 구글 검색을 통해 관리자 페이지를 찾게 되면 해커는

관리자 페이지를 접속하지 않더라도 구글의 저장된 페이지를 이용해 중요한 정보를

획득할 수 있다. 이러한 웹 사이트 관리용 페이지는 반드시 사용자의 인증 절차가

제대로 작동하는지 확인해야 하며 또한 인증 절차 후에는 권한 점검도 반드시 해야

한다. 만약 웹 사이트의 관리가 회사 네트워크와 같이 제한된 IP 에서만 이루어진다면

관리자 페이지에 접속 가능한 IP 를 제한하는 것도 보안을 강화하는 좋은 방법이다.

중요 정보에 대한 해시 값 저장

앞서 해킹 시나리오에서 봤던 것처럼 비밀번호와 주민등록번호와 같은 중요한 정보가

평문으로 저장이 되는 것은 안전하지 않다. 이러한 정보는 회원 가입 시 입력 받았던

값에 대한 해시 값과 사용자가 로그인하거나 본인 확인을 하기 위해 입력한 값의 해시

값이 같은지 비교하면 된다. 즉 사용자가 직접 입력한 원본 값을 데이터베이스에

저장할 필요가 없다는 것이다. 만약 사용자가 비밀번호를 잊어버린 경우라면 이름과

주민등록번호 등을 이용한 본인 확인 과정을 거친 후에 이미 등록된 메일이나 휴대폰

번호 등으로 새로 설정된 임시 패스워드를 보내는 것이 안전하다. 또한 이렇게 발급된

패스워드는 만기 기한을 설정해 만기 기한이 지나면 다시 본인 확인 과정을 거쳐서

새로 임시 패스워드를 전송하게 해야 한다. 그리고 사용자가 발급된 임시 패스워드를

이용해 로그인한 경우에는 반드시 새로운 패스워드로 변경하도록 해야 한다.

열쇠는 웹 개발자가 쥐고 있다

요즘 빈번하게 발생하고 있는 웹 해킹은 엄밀히 이야기하면 웹 개발자들에 의해

개발된 웹 애플리케이션의 보안 버그를 이용한 웹 애플리케이션 해킹이다. 따라서 웹

사이트의 보안은 웹 사이트에 존재하는 웹 애플리케이션이 얼마나 보안을 고려하여

개발됐는가에 달려 있다. 실제로 웹 사이트를 해킹하기 위해서는 보안 취약점이

존재하는 웹 애플리케이션이 한 개만 있으면 된다. 따라서 웹 사이트에 웹

애플리케이션의 수가 많을수록 웹 애플리케이션에서 사용하는 인자가 많을수록 해커가

공격할 수 있는 기회가 많아진다.

- 80 -

이론적으로는 웹 사이트에 존재하는 웹 애플리케이션의 수가 100 개이고 웹

애플리케이션 당 10 개의 인자를 사용한다면 해커에게는 총 1000 번의 공격 기회를

주는 것이다. 만약 1000 번 중 한 번이라도 공격에 성공하면 해커는 시스템 권한을

획득할 수 있다. 더구나 현재 구축되어 있는 거의 모든 웹 사이트가 웹

애플리케이션이 해킹되면 내부 DB 까지 유출이 가능한 구조로 구축돼 있다. 그러므로

웹 개발자들이 개발하는 웹 애플리케이션의 보안성이 바로 내부 DB 의 중요정보의

유출을 막을 수 있는 유일한 수단이라는 것을 인식해야 한다.

제공 : DB 포탈사이트 DBguide.net

출처명 : 마이크로소프트웨어 [2005 년 10 월]

- 81 -

All about google!

특집 1 부 | 개발자, 구글 신드롬에 빠지다

특집 2 부 | 성공의 원천, 탄탄한 기술 인프라 대해부

특집 3 부 | 구글의 숨은 경쟁력 운영과 마케팅

특집 4 부 | 구글의 이면, 최강의 해킹 툴

특집 5 부 | 리얼가상 스토리 ‘빽투더 구글 퓨처’

특집 5 부 리얼가상 스토리 ‘빽투더 구글 퓨처’

박재호 | 개발자, ‘조엘 온 소프트웨어’ 번역

밝음이 있으면 어둠이 있기 마련이다. 하드웨어는 물론이고 소프트웨어 업계에서

지속적으로 선두를 유지해온 기업은 손에 꼽을 정도이며 대부분 한 때 반짝 뜨다가

소리소문 없이 사라지는 경우가 대부분이다. 검색엔진 부문에서 리마커블한 영역을

창출한 구글이 앞으로 부딪칠지 모르는 난기류를 감지하는 사람이 비단 필자뿐일까?

1 부에서 화려한 장밋빛 세상을 펼쳐보였지만, 이제는 들뜬 마음을 가라앉히고 마운틴

뷰(구글 본사가 위치하고 있다)에 다가오는 어둠의 기운과 이를 필사적으로 물리치기

위한 구글의 전략에 대해 살펴보자.

아마존처럼 해서는 아마존을 몰아낼 수 없다.

- 세스 고딘 『보랏빛 소가 온다』 197 페이지

한창 IBM 이 잘 나가던 시절에 컴퓨터 업계에서 IBM 은 ‘공공의 적’으로 그려졌다.

반독점법 소송에 걸려서 회사가 분할 직전까지 갔으며, 메인 프레임 기술 라이선스

허용이라는 악재와 연이은 PC 표준 장악 실패로 인한 컴팩과 같은 호환기 업체

등장과 DOS 운영체제라는 한 배를 탄 혈맹에서 OS/2 와 윈도우로 갈라지면서 갑자기

- 82 -

적으로 돌변한 마이크로소프트(이하 MS)의 급성장과 맞물려 한 풀 꺾였기에, 요즘은

어느 누구도 IBM 을 공공의 적으로 여기지 않는다.

하지만 새로운 공공의 적은 언제든지 고개를 내밀기 마련이다. 한창 잘 나가는

씽크패드 브랜드를 포함한 PC 사업부마저 레보노에 매각해버리고 서비스와 컨설팅

회사로 거듭나려는 IBM 을 대신하여 MS 가 불명예스러운 왕관을 넘겨받은 지도

어느덧 상당한 시간이 흘렀다. 점점 불어나는 덩치를 유지하기 위해 운영체제 부문을

넘어서 오피스 소프트웨어를 거쳐 인터넷 서비스와 게임 콘솔인 X 박스에 이르기까지

전방위로 뻗어나가는 MS 의 독과점 폐해를 견제하기 위해 컴퓨터 업계는 물론이고

각국 정부에서도 강력한 대응책을 펼치고 있다.

경쟁에서 뒤떨어지지 않기 위해 지속적으로 기술 개발에 천문학적인 투자를 해 왔던

MS 이지만 요즘은 사면초가 상황에 몰려있다. 어떤 신기술을 발표하더라도 되돌아오는

냉담한 반응과 더불어 리눅스 공동 개발을 위한 OSDL

참여(www.zdnetasia.com/news/software/0,39044164,39251063,00.htm), 오픈소스

소프트웨어 세계에서 상당한 영향력을 끼치고 있는 에릭 S. 레이몬드

영입(esr.ibiblio.org/index.php?p=208)과 같은 오픈소스 소프트웨어 부문에 대한 화해

몸짓조차도 상황을 개선하기는커녕 오히려 악화시키고 말았으니, 나름대로 열심히

성의를 보인 MS 로서는 억울하기 짝이 없을 거다. 하지만 걱정 마시게나 빌 게이츠

선생, 당신보다 더 강력한 구글이라는 다크호스가 등장했으니 말야(뉴욕타임즈

2005 년 8 월 24 일 기사(구독자만 볼 수 있다) : Relax, Bill Gates; It’s Google’s Turn

as the Villain(www.nytimes.com/2005/08/24/technology/24valley.

html?ex=1126584000&en=8c8bea8d802b0980&ei=5070).

이제 MS 가 점잔빼는 IBM 의 자리를 차지하고 구글이 MS 의 자리를 대신 차지하게

될지도 모른다는 이야기가 여기저기서 모락모락 피어오르고 있다. 이런 상황에서

구글은 어떻게 처신해야 할까? 지금까지 회사 성장의 버팀목이 되었던 전략과 전술을

그대로 사용하기만 하면 지속적인 성장을 유지할 수 있을까? 아니면 또 다른 성장

동력원을 개발해서 적극적으로 위험을 줄이는 동시에 계속해서 경쟁사를 압도하게끔

유리한 고지를 점령할 필요가 있을까? 구글 스스로가 답해야 하는 머리 아픈 질문이

될지도 모르겠다.

- 83 -

5 부에서는 먼저 MS 를 위협하는 새로운 세력으로 떠오르고 있는 구글의 현재 상황을

점검해보고, 구글이 보유하고 있는 인력과 기술을 분석해본다. 또 현재 상황과

인력/기술 분석을 토대로 앞으로 구글이 나아가고 있는 방향을 조심스럽게

예측해보겠다.

MS 를 위협하는 신흥 세력으로 자리잡다

과거에는 MS 가 막대한 현금 동원력을 자랑하며 장애물로 다가오거나 전략적 가치가

있는 회사를 ‘싹쓸이’한 적이 있었다. 심지어 MS 는 2003 년 가을 무렵에 100 억

달러를 동원해 구글 인수를 타진한 적도

있었다(wired.com/wired/archive/12.03/google_pr.html). 물론 구글은 일언지하에

거절했지만 말이다.

현재 구글의 시가 총액은 800 억 달러로 MS 의 3000 억 달러와 비교하면 대략 1/4

수준 밖에 되지 않지만 아메리칸익스프레스를 능가하고 타임워너에 조금 못 미치는

수준이므로 마음먹기에 따라서는 어마어마한 위력을 발휘할 수 있다. 일례로 지난 8 월

18 일에 구글이 자사 전체 주식의 4.8%인 1,415 만 9,265 주(흥미롭게도 원주율

3.1415 9265 의 소수점 이하 여덟 자리와 동일하다)를 매각하겠다고 발표함으로써

월가와 뉴욕 증시를 놀라게 만들었다. 현재 구글의 현금 보유고가 30 억 달러에

이르고 있는데도 40 억 달러를 더 만들겠다는 발표에, 사람들은 ‘도대체 구글이 어떤

먹잇감을 노리고 있는지’ 이목을 쏟고 있다.

이렇게 기침만 한번 해도 작은 규모 회사들이 감기에 걸릴 정도로 거인이 되어버린

구글을 실리콘밸리에서는 어떤 시각으로 바라보고 있을까? 먼저 구글의 인수합병

역사를 간략하게 살펴본 다음에 구글을 염려하는 생생한 목소리를 들어보자.

구글 인수합병 역사

늘 새로운 신기술을 선보여 사람들을 깜짝 놀라게 만드는 구글이지만 모든 기술을

홀로 개발하기는 불가능하다. 덩치가 커짐에 따라 다양한 서비스를 단시간에 제공해야

- 84 -

했기에 필연적으로 쓸만한 기술을 갖춘 회사를 하나 둘씩 끌어들이기 시작했다. 이런

인수합병 정보는 구글이 어떤 방향으로 사업을 전개하고 있는지 중요한 힌트가 될 수

있기에 연대기 순으로 구글 인수합병 역사를 중요한 사건 위주로 간략하게

정리해보았다. 더 자세한 정보는 www.kuro5hin.org/story/ 2005/6/12/143721/743 와

en.wikipedia.org/wiki/ Google 을 참조하기 바란다.

• 2001 년

- 2 월(Deja) : 1995 년부터 웹 기반 유즈넷 아카이브 시스템을 운영해온 데자에서

유즈넷을 인수해서 구글 그룹으로 재출발

- 10 월(Outride) : 제록스 팔로알토 연구소에서 분사한 정보 검색 업체인

아웃라이드를 인수해서 검색엔진 기술을 통합

• 2003 년

- 2 월(Pyra Labs) : 초기 자본금이 말라버린 블로그 업체인 파이라 랩을 인수해서

재단장한 후 블로그 서비스 시작

- 4 월(Neotonic) : CRM 업체인 네오토닉 인수

- 4 월(Applied Semantics) : 야후! 오버추어에 대응하기 위해 문맥에 의존적인 광고

업체인 어플라이드 시멘틱스를 인수해 애드센스/애드워드 서비스에 활용 -

10 월(Kaltix) : 구글 개인화 검색을 위해 칼틱스를 인수

- 10 월(Sprinks) : 구글 애드워드/애드센스 프로그램을 개선하기 위해 스프링크스를

인수

- 10 월(Genius Labs) : 웹 감사 기록 업체인 지니어스 랩을 인수

• 2004 년

- 6 월(Baidu) : 중국 검색 업체인 바이두 지분 투자. 2005 년에 들어와서 바이두가

급격하게 인기몰이를 하는 바람에 중국 내 구글 입지를 좁히는 부작용도 발생하고

있다.

- 7 월(Picasa) : 사진 관리 시스템인 피카사를 블로그 시스템에 통합시키기 위해 인수

- 10 월(Keyhole) : 2001 년 창립된 디지털 지도 회사인 키홀을 구글 맵과 구글 어스에

사용하기 위한 사진을 확보하기 위해 인수

- 10 월(ZipDash) : 교통/지도 회사인 ZipDash 를 인수. 구글 맵과 관련 있어 보이지만

정확한 인수 목적은 밝혀지지 않음

- 10 월(Where2) : 오스트레일리아 지도 회사인 Where2 를 인수. 구글 맵과 관련 있어

보이지만 정확한 인수 목적은 밝혀지지 않음

- 85 -

• 2005 년

- 5 월(Urchin) : 웹 분석과 통계 회사인 어친을 인수. 애드센스/애드워드와 관련 있어

보이지만 정확한 인수 목적은 밝혀지지 않음

- 5 월(DodgeBall) : 휴대폰을 기반으로 하는 사회 네트워크 회사인 닷지볼을 인수.

구글 모바일과 관련 있어 보이지만 정확한 인수 목적은 밝혀지지 않음

- 5 월(Android Inc) : 모바일 장치를 위한 소프트웨어 회사인 안드로이드를 인수

구글이 앞으로 눈독을 들일만한 회사는 다음과 같다. 물론 실제로 합병이나 인수가

일어날지는 구글 이외에 아무도 모른다.

- del.icio.us : 사회 북마크와 태그 시스템은 구글 검색 결과를 향상시키며 기존

구글이 운영하고 있는 Orkut 와 연계해서 동작하면 상승효과를 높일 수 있다.

- 오픈 디렉토리 프로젝트 : 현재 구글 디렉토리 서비스의 근간을 이루고 있는 이

프로젝트는 넷스케이프에서 운영 중이다. 하지만 구글 디렉토리 서비스는 너무

낡았기에 오픈 디렉토리 프로젝트를 부활해야 할 필요성이 있다.

- 위키피디아(www.wikipedia.com) : 현재는 야후!와 제휴를 맺고 있지만, 구글이

지속적인 러브콜을 하고 있다.

- GuruNet(www.gurunet.com/, http://www.answers.com) : 구글이 취약한 용어정리

부문을 보충할만한 서비스를 제공한다.

- World66(www.world66.com/) : 끝내주는 여행 사이트

- StumbleUpon(www.stumbleupon.com/) : 웹 사이트를 공유하고 평가하는 지능적인

웹 브라우징 서비스를 제공한다.

구글에 쏟아지는 비판들

지금까지 구글이 상당히 많은 회사를 인수합병했다는 사실에 놀랄지도 모르겠다.

이번에 주식 매각을 통해 확보한 ‘실탄(현금)’도 다른 회사를 인수합병하기 위한

목적으로 사용할 가능성이 높기 때문에 앞으로 MS 와 관련된 인수합병 소식만큼이나

놀랄만한 뉴스거리를 구글도 만들어 낼 것으로 보인다. 이렇게 구글이 거대한 자본,

기술력, 기획력이라는 삼박자를 맞춰나가면서 장래 경쟁자가 될지도 모르는 회사를

사들이는 모습을 비난하는 사람들도 늘어가고 있다. MS 가 1986 년 3 월에 상장한

- 86 -

직후 공모가가 21 달러에서 1 년 후에 82.75 달러로 자그마치 294%가 상승했는데,

닷컴 열풍이 가셨음에도 불구하고 구글도 이에 못지않게 2004 년 공모가 85 달러로

시작해서 1 년 후인 지난 8 월 19 일에는 280 달러를 기록해 상승률 229%를 달성했다.

또 실리콘밸리에 들어오는 벤처 자금의 25%를 구글이 차지함으로써 벤처 업계의

빈익빈 부익부라는 문제점을

노출시켰다(news.naver.com/news/read.php?mode=LSD&office_id=020&article_id=00

00313119§ion_id=101&menu_id=101).

결국 MS 를 한방 먹일 만한 체력을 갖춘 헤비급 도전자가 등장한 셈인데, 구글은

검색엔진을 비롯해 메신저, 이메일, 지도 서비스에 이르기까지 MS 와 맞붙어 싸우는

영역을 점차로 넓혀가는 상황이다. 구글은 공격적인 인재 쟁탈전과 더불어 때로는

무모할만큼 혁신적인 서비스를 제공함으로써 MS 조차도 놀라게 만들고 있다. 빌

게이츠는 포츈지와 인터뷰에서 “구글은 지금까지 상대해온 회사 중에 우리(MS)와

가장 닮았다”고 말하기도 했다.

이렇듯이 구글의 영향력이 커짐과 동시에 다양한 비판도 쏟아지고 있다. 몇 가지 주요

쟁점을 정리해보았다(en.wikipedia.org/wiki/ Google#Criticism_and_controversy).

• 저작권 문제

여러 기관에서 DMCA(Digital Millennium Copyright Act) 조항을 사용해서 구글에게

저작권이 갖춰진 문서를 참조하지 못하도록 요구하고 있다. 구글은 보통 이런 요청을

받아들여 검색 결과에서 링크를 제거해 버린다. 또한 구글의 웹 캐시 기능이 저작권을

위배한다는 불만도 있는데, 다행스럽게도 구글은 요청에 따라 해당 캐시를 제거해준다.

하지만 개인의 의사와 무관하게 상위에 검색 결과를 올리는 바람에 갑자기 몰아치는

트래픽으로 특정 사이트를 마비시키는 경우도 있었기 때문에 검색 결과 사용을 놓고

벌어지는 논쟁은 끝이 없을 듯하다.

• 다중 문화

1 부에서 주민등록번호와 관련하여 문제점을 제시했는데, 국가별로 민감하게 다루는

안건이 존재한다. 예를 들어 미국은 DMCA 에 따라 저작권이 걸린 저작물을 링크에서

제거하도록 규정하고 있으며, 프랑스나 독일의 경우에는 나치와 관련된 찬양은

불법이다. 중국의 경우에는 대만 독립이나 인권과 같은 단어를 금칙어로 규정하고

있다. 구글은 이와 같이 국가별 문화적인 차이점을 극복해야 하는 어려움이 있다.

- 87 -

• 사생활 보호

구글은 미 연방 정부법에 따라 인터넷 검색 결과를 미국 정부에 제출한다고 한다. 또

몇몇 사용자는 쿠키를 사용해서 특정 사용자가 검색한 기록을 추적한다는 주장을

제기하고 있으며, gmail 서비스에 가입하지 않은 사용자가 gmail 사용자에게 이메일을

보낼 때도 본문 내용을 검사한다는 사실에 이의를 제기하고 있다.

• 페이지 랭크 시스템

구글의 중앙 집중적인 페이지 랭크 시스템이 비민주적이라고 비판하는 사람들도 많다.

인기 좋은 특정 페이지만이 우선순위가 높아지므로 나머지 변두리에 있는 사이트의

노출 기회는 상대적으로 줄어들기 때문이다. 또 조작을 통해 구글 랭크 시스템을

교란하는 경우도 있다.

만일 구글이 조그마한 사이트였다면 이런 비판은 싹을 틔우지도 않았을 것이다.

하지만 영향력이 커질 만큼 커진 구글이 독점 기업처럼 행동하지나 않을까 하는 것에

대해 점점 더 많은 사람들이 걱정하기 시작했다. 실제로 씨넷에서 구글 사생활 침해와

관련하여 구글 최고 경영자인 에릭 슈미트와 관련한 개인적인 인적 사항을 기사화했을

때 씨넷 기자에 대해 홍보실에서 일체 접촉을 금지하는 훈령을 내리는 등 마찰을

일으키고 있다(www.zdnet.co.kr/news/internet/portal/ 0,39031333,39138127,00.htm).

구글이 보유한 인력과 각종 기술

구글은 어느 인터넷 업체와 비교하더라도 결코 뒤지지 않는 연구 인력과 다양한

기술을 확보하고 있다. 구글이 막강한 자본력을 바탕으로 경쟁업체보다 20~25% 정도

높은 연봉을 제시해 우수한 핵심 인력을 끌어모으고 있으며, 이런 핵심 인력이 구글

지원에 힘입어 진행하는 프로젝트 범위와 수준도 날로 높아지고 있다(1 부에서 구글

개발자 문화를 소개한 바 있으므로 혹시 건너뛰었다면 구글이 직원에게 주는 동기

부여책을 다시 한번 확인하기 바란다).

- 88 -

그렇다면 구글에서는 어떤 사람들이 어떤 연구를 하고 있으며, 이런 연구를 통해 어떤

신기술을 보유하고 있을까? 물론 밝혀지지 않은 비밀스러운 연구가 많이 존재하겠지만,

구글이 향후 집중하는 분야가 무엇인지 확인하는 차원에서 공개된 정보를 토대로

인력과 기술을 정리해 보았다.

어디 내놓아도 손색없는 연구 인력

이번 특집 기사를 마무리하고 있을 때 놀라운 소식이 들려왔다. 바로 구글이

TCP/IP 의 아버지인 빈톤 서프를 영입한 것이다. 빈톤 서프가 재직하고 있던 MCI 가

버라이즌에 인수되면서 구글에 합류한 빈톤 서프는 차세대 응용 아키텍처와 표준 개발

작업을 진행한다고 한다.

비단 빈톤 서프 뿐일까? 과거 기록을 뒤져보면 파이어폭스 개발 프로젝트를 이끌고

있던 벤 구저가 구글로 이직하는 바람에 파이어폭스 1.1 이 예정보다 3 개월 뒤쳐진

경우도 있었고, 1,000 만 달러를 들여 MS 에서 영입한 카이푸 리 때문에 MS 와 구글

사이에 기밀 유지 조항과 관련한 침해 건으로 법정 소송이 벌어지기도 했다. 크고

작은 기술자 영입은 구글 세상에서는 그다지 대단한 일이 아닌 듯이 보인다. 구글이

‘다양한 사람을 만날 수 있다’고 이야기하는 배경에는 이런 뛰어난 인재 확보가

숨어있다.

구글은 실제로 다양한 프로젝트를 진행하고 있다. 구글 랩에 올라온 각종 논문이나

진행 중인 프로젝트 목록을 보면 대학교 몇 개를 합쳐놓은 정도로 다양한 분야를

포괄하고 있다(labs.google.com/ papers.html). 진행 중인 프로젝트 목록을 한번

들여다보자. 어어, 이거 어디서 많이 보고 듣던 프로젝트가 아닌가? 각 프로젝트에

관심이 있다면 각 프로젝트 홈페이지만 보고서도 어떤 개발자가 구글로 옮겨갔는지

추측할 수 있을 것이다.

- 알파 서버, 애플 리사 : 하드웨어

- 토이 스토리, 벅스 라이프 : 애니메이션

- 플랜 9, venti : 운영체제

- 파이선, 셀프, J 스킴, 자바 핫스팟, 실크 : 프로그래밍 언어

- 89 -

- 김프, gtk : 그래픽 툴

- 마스 로버, 딥 스페이스 1 : 나사 우주 개발

이렇듯 구글은 오픈소스 관련 개발자, 대기업 연구소 연구원, 미디어 업체 연구원에

이르기까지 다양한 인력을 확보하고 있다. 최근 구글은 세계화 추세에 발맞춰 구글

본사에서 근무할 한국 엔지니어를 모집하기 시작했다(www.google.co.kr/jobs/).

<화면 1> 빈톤 서프 (en.wikipedia.wiki/Vint_Cerf)

- 90 -

<화면 2> 구글이 제공하는 각종 서비스

(www.google/com/intl/en/optons/index.html)

구글의 ‘신무기’ 퍼레이드

- 91 -

구글 관련 기사를 작성할 때마다 구글 색인 크기에 한번 놀라고 구글이 제공하고 있는

각종 서비스에 또 한번 놀라게 된다(<화면 2>). 구글이 제공하는 여러 가지 다양한

서비스 중에서 특징적인 몇 가지를 간추려 보겠다.

• 구글 맵(maps.google.com/)과 구글 어스(earth.google.com/)

한창 인기 절정을 달리고 있는 구글 지도 서비스는 유사한 서비스인 버추얼 어스를

제공하고 있는 MS 와 끊임없는 경쟁을 벌여서 사용자를 즐겁게 만들어주고

있다(www.zdnet.co.kr/news/internet/search/0,39031339,39138352,00.htm).

• 데스크탑 검색 소프트웨어(desktop.google.com/)

구글 데스크탑 검색 소프트웨어는 지역 하드디스크에 존재하는 각종 파일을 쉽게 찾을

수 있도록 지원한다.

• 비디오 검색(video.google.com/)

구글에서 텍스트뿐 아니라 비디오 검색을 지원하기 시작하자 방송사조차 떨고 있다는

소식이 있다. MS 와 야후도 비슷한 검색 서비스를 제공하고 있으며, 향후 유료화

전략을 통해 수익성 높은 사업으로 육성해나갈 듯이 보인다(zdnet 기사 참조).

• 구글 웹 가속기(webaccelerator.google.com/)

현재 영국과 미국에서 서비스 중인 웹 가속기는 캐시를 통해 웹 서핑 중에 인터넷

속력을 높여준다.

• 지역 검색(local.google.com/)

지역에서 제공하는 회사나 서비스를 찾아주는 서비스이다.

• 인스턴트 메신저(www.google.com/talk/)

구글토크는 단순함과 호환성을 목표로 만든 깔끔한 인스턴트 메신저이다. 아직 윈도우

- 92 -

버전만 제공하지만, 다른 오픈소스 인스턴트 메신저와도 호환이

가능하다(www.google.com/talk/otherclients.html)

• 사이트 맵 구축(www.google.com/webmasters/sitemaps/docs/en/about.html)

개인이 운영하는 웹 서버의 사이트 맵을 쉽게 구축하도록 도와주는 도구이다.

• 구글 프린트(http://print.google.com/googleprint/about.html)와

스칼라(scholar.google.com/)

책을 대상으로 하는 전문 검색과 대학생과 대학원생을 위해 필요한 논문을 찾아주는

서비스이다.

구글이 나아가고 있는 방향

지금까지 구글의 현재 상황과 구글이 보유하고 있는 지적 자산에 대해 살펴보았다.

지금부터는 구글이 나아가고 있는 방향을 미디어와 데스크탑이라는 양쪽 부문으로

압축해서 살펴보겠다. 물론 여기서 다루는 내용은 어디까지나 예측이기 때문에 맞지

않을 수도 있다. 앞일을 예측하는 작업은 무척 어려우며 구글 자신도 구글이 어떤

방향으로 나가고 있는지 속단하기 어려울 만큼 다양한 시도를 진행하고 있기 때문에

향후 주변 상황에 따라 얼마든지 목표 수정과 변경이 일어날 수 있다는 사실을 염두에

두면서 재미있게 읽어보면 좋겠다.

미디어 제국을 넘보는 구글

애플이 아이팟과 아이튠즈 서비스를 내놓으며 음악 시장에 진출한다고 발표했을 때

업계 관계자들의 반응은 냉담했다. 애플이 만든 아이팟은 가격이 너무 비쌌고,

아이튠즈는 기존 음반 업계의 이해와 상충하는 서비스였기 때문에 결국 실패하리라는

예측이 압도적이었다. 하지만 애플은 블루오션에 진입하는 데 성공했으며, 심지어

매킨토시 애호가가 아닌 일반 사용자들조차 열광적인 반응을 보였다.

- 93 -

애플은 잠시 잊고 구글을 생각해보자. 다른 포탈 사이트와 구글의 결정적인 차이점을

무엇이라고 생각하는가? 국내외 초대형 포탈 사이트를 보면 어떻게 해서든 고객을

자사 사이트에 오래 붙잡아 두기 위해 안간힘을 쓰고 있음을 알 수 있다. 연예계

소식부터 게임에 이르기까지 온갖 컨텐츠를 구입해서 제공하며, 부작용을

감수하면서까지 더욱 선정적인 제목이 달린 신문 기사를 헤드라인에 올리고, 심지어

영화·음악 잡지까지 제공하기도 한다. 하지만 구글은 전혀 다른 전략을 취하고 있다.

구글 사이트의 최종 목표는 사용자가 필요한 정보를 찾으면 그 즉시 벗어나게 만드는

것이다. 또한 다른 포탈은 컨텐츠를 사서 무료로 뿌리는 반면 구글은 서비스를 사서

무료로 뿌리기 때문에 수준이 한 단계 높다.

구글은 사람이 개입하지 않는 중립적인 자료 수집과 분류 방법을 선호한다. 국내 포탈

사이트에 올라오는 눈길을 끌만한 자의적인 분류와는 달리 구글 뉴스 시스템은 자료

수집 시점에서 최종 디스플레이 시점까지 모든 작업을 자동으로 진행한다. 이런

완벽한 자동화 시스템은 중립적인 뉴스 전달이라는 훌륭한 목표를 달성하는 데 도움을

주지만, 신문의 수준이나 기사 내용의 품질을 따지지 않기 때문에 종종 최고 품질과는

거리가 먼 기사들이 뒤섞일 수도 있다. 실제로 국내에서 서비스하고 있는 구글

뉴스에도 스팸이 올라와서 문제를 일으킨 적도 있기에 구글은 좀 더 정교하고 신호

대비 잡음이 적은 시스템을 계속해서 개발하고 있다. 구글은 지속적으로 구질서와

신질서를 조화시키려고 시도한다. 예를 들어, 구글은 이번에 새로 발표한 인스턴트

메신저 시스템인 구글 토크에 음성 대화 서비스 기능을 추가했다. 또한 구글이

보유하고 있는 강력한 온라인 광고 시스템인 애드워드를 오프라인으로 확대시켜 종이

매체의 광고를 재판매하는 작업에 들어가고 있다(www.zdnet.

co.kr/news/internet/browser/0,39031243,39139144,00.htm). 다른 한편으로 RSS 를

사용한 광고 전달 기술을 특허 신청함으로써 온라인 부문에서 야후나 MS 가 추적하지

못하도록 물밑에서 신경전을 벌이고

있다(www.zdnet.co.kr/news/internet/search/0,39031339, 39138429,00.htm).

최근에는 저작권 문제가 암초에 걸릴지 모른다는 우려 속에서도 구글 프린트 서비스를

통해 오프라인 서적을 색인해서 검색할 수 있도록 제공하고 있다.

- 94 -

<화면 3> 가짜로 밝혀진 구글 운영체제 부팅 화면

구글은 미디어를 전달하는 하부 구조(infrastructure)에도 무척 많은 공을 들이고 있다.

구글 가속기 기술은 미국 전역에 걸쳐 광통신망에서 놀고 있는 대역폭을 구입해서

이를 활용할 수 있기 때문에 가능해졌다. 현재는 엄청난 대역폭을 실험적으로 웹

캐시에만 사용하지만 미디어 스트리밍에 사용하지 못할 이유는 없다. 또한 비록

구글이 공식적으로 확인해주고 있지는 않지만 향후 미국 전역에서 와이파이 서비스를

제공한다는 구글 넷 계획(www.business2.com/b2/web/ articles/0,17863,1093558-

1,00.html)에 대해서도 이야기가 많이 나오고 있다. 구글이 미국 전체를 통틀어 가장

큰 인터넷 접속 사업자로 변신한 다음에 구글 비디오 서비스 등과 결합해서 컨텐츠를

제공하기 시작하면 기존 위성 방송이나 케이블 텔레비전 업체를 위협하는 새로운

강자로 떠오를지도 모른다.

이렇듯 구글이 인스턴트 메신저 서비스와 인터넷 전화 사업에 진출함으로써 결국에는

기존 인터넷 검색엔진 업체와 승부를 벌이는 동시에 야후, MSN, AOL 과 무한

경쟁체제로 접어들게 되었다. 2005 년 7 월 현재 MSN 메신저 사용자가 무려 1 억

7000 만명이나 되며, AOL 메신저 사용자 수도 1 억명에 근접하고, 야후도 8000 만명에

달하는 가입자를 확보하고 있기 때문에 구글이 뒤늦게 뛰어든 것이 아니냐는 분석도

나오고 있다. 하지만 구글은 다른 메신저 회사들이 가장 하기 싫어하는 상호 연동을

위한 개방형 프로토콜(Jabber)을 채택함으로써 향후 MSN 이나 야후! 메신저와 통신이

가능해지므로 윈도우는 물론이고 매킨토시나 리눅스 사용자층까지 휩쓸 가능성도 높다.

- 95 -

현재 미국 인터넷 시장에서 구글이 36.5%, 야후가 30.5%, MSN 이 15.5%, AOL 이

9.9%의 시장 점유율을 보이고 있기 때문에 만일 구글이 브랜드 파워를 사용해서 메일

서비스, 구글 토크, 구글 단문 서비스를 유기적으로 결합해서 본격적인 세몰이를 할

경우에 기존 업체들은 타격을 입지 않을 수 없다. 주요 인터넷 기업들은 기존에

확보한 사용자 이탈을 방지하기 위해서라도 당분간 계속해서 앞서거니 뒤서거니

하면서 서비스 강화에 목숨을 걸 것 같다.

<화면 4> 가짜로 밝혀진 구글 운영체제 메인 화면

앞서 구글이 자사주를 매각해서 충분한 실탄을 확보했다는 소식을 정리했는데, 인터넷

부문에서 벌어지는 치열한 경쟁을 염두에 두고 장기전을 벌이기 위한 준비 과정으로

생각하는 사람들이 많다. 과연 후발 주자인 구글이 얼마만큼 선전할 수 있을지는

뚜껑을 열어봐야 할 것이다.

데스크탑 제국인 MS 에 대항하는 구글

- 96 -

열성적인 리눅스 사용자일지라도 데스크탑 부문에서 MS 가 꽉 잡고 있다는 사실을

부인하기는 어려울 것이다. 여러 차례에 걸친 데스크탑 헤게모니 싸움에서 MS 는

한번이라도 고삐를 늦춘 적이 없으며 운영체제와 오피스 소프트웨어라는 쌍두마차를

앞세워 눈에 보이는 모든 경쟁업체를 초토화시키는 전략을 사용하고 있다. 하지만

가장 ‘MS 다운’ 구글은 데스크탑 부문에서도 슬슬 MS 가 차지하고 있는 위치에

눈독들이기 시작했다. 업계 분석가들은 구글은 MS 의 전매특허인 외부 개발자 지원

방식을 그대로 흉내내어 서비스 대부분에서 표준을 지원하며 외부 개발자들이 부가

제품을 개발할 수 있도록 적극 격려하고 있다. 1 부에서 소개한 ‘개발자가 구글에

열광하는 이유’에서 언급했듯이 구글은 적극적으로 자사 기술을 외부에 공개하고 있다.

이렇듯 구글이 광범위한 분야에서 제품을 출시하고 있기에 구글이 마음만 먹으면

운영체제와 유사한 제품까지도 만들어낼 수 있지 않을까하는 궁금증이 증폭되고 있다.

실제로 구글은 플랜 9 과 리눅스 운영체제 기술부터 시작해서 데스크탑 검색, 인스턴트

메신저, 웹 브라우저, 피카사, gmail 을 비롯한 각종 웹 응용 프로그램에 이르기까지

다양한 기술을 확보하고 있으므로 잘만 조합하면 뭔가 대단한 물건이 나올 법도 하다.

장난스러운 네티즌들은 구글 운영체제를 상상으로 만들어 인터넷에 올려놓기도

했다(grooan.com/futurefeeds/index.php?p =15). 단순히 재미로 웃어넘기기에는

너무나도 가능성이 높기에 여기에 대해 상상력을 조금 보태서 필자가 원하는 구글

운영체제에 대해 밑그림을 그려보겠다. 지금부터 나오는 상상의 ‘구글 운영체제’를

편의상 구글 X 라고 부르겠다.

우선 구글 X 는 기본적인 운영체제 코어와 필수 응용 프로그램만을 탑재하고 있는

USB 메모리로 부팅한다. 하드디스크나 CD-ROM 과 같은 저장장치는 부팅이나 부팅

후 운영 과정에서 필요하지 않으며, 네트워크 연결만 요구한다. 와이파이를 지원하는

지역이라면 USB 메모리에 탑재된 무선 랜 기능을 사용할 수도 있다. 기술적으로

현실성이 충분하다. 이미 IBM 에서는 SoulPad 라는 이름으로 아이팟에 Knoppix 를

탑재시켜서 하드디스크 없이 부팅이 가능한 x86 기반 운영체제를

만들었으며(news.com.com/IBM+brains+capture+ a+PCs+soul/2100-1041_3-

5830870.html), ‘황의 법칙’에 따라 플래시 메모리 집적도는 매년 두 배씩 높아지고

있기에 내년부터는 삼성전자에서 만든 16GB 플래시 메모리가 시중에 등장한다고 하니,

머나먼 미래 이야기는 결코 아니다.

- 97 -

구글 X 부팅이 끝나면 운영체제 코어와 필요한 디바이스 드라이버가 올라와 있으며,

자바와 웹 브라우저를 기반으로 하는 구글 X 데스크탑 화면이 펼쳐진다. 사용자는

USB 메모리에 할당된 사용자 영역에서 파일을 읽고 쓸 수 있으며, USB 메모리에

들어있지 않은 웹 응용 프로그램은 모두 네트워크를 통해 받아온 다음에 캐시해서

사용한다.

웹 응용 프로그램은 모두 플래시와 AJAX 기술(ko.wikipedia. org/wiki/AJAX)을

기반으로 하기에 기존의 정적인 웹 응용 프로그램과는 달리 충분한 상호대화 기능을

제공한다. 기본적으로 데스크탑 검색이 가능하며 웹 서핑은 물론, 메신저와 이메일,

지도 보기, 사전 찾기 기능을 사용할 수 있다. 무거운 오피스 소프트웨어가 필요할

경우 자바 기반으로 동작하는 오피스 소프트웨어를 사용하며, 인터넷에서 음악이나

동영상을 보고 싶다면 웹 브라우저 플러그인 방식으로 동작하는 멀티미디어 재생기를

사용할 수 있다.

작업이 끝나고 나면 다음 번 작업을 쉽게 할 수 있도록 현재 데스크탑 환경 설정을

비롯하여 모든 작업 내용을 USB 메모리에 저장하며, 필요하다면 인터넷 저장소와

동기화를 시켜준다. 구글 X 만 있다면 남부럽지 않은 개인용 PC 환경을 전 세계

어디서나 구축할 수 있게 될 것이다.

구글의 힘, 유머와 기발함

이 글을 쓸 무렵 구글이 색인 불가능한 자료를 소각한다는

기사(www.theonion.com/content/node/40076/1)를 읽었다. 구글 CEO 인 에릭

슈미트는 구글 사용자들은 세상이 단순하고 명쾌하고 구글 홈페이지처럼 쉽게

접근하기를 원한다고 밝히면서 필요 없는 자료를 삭제한다는 구글 퍼지(Google

Purge) 프로젝트 시작을 발표했다. 구글 퍼지에 대한 사용자와 시장 반응은

호의적이라서 발표 후 주가가 1.24 달러 정도 상승했다. 자신을 성공하게 만들었던

초심을 잊어버리는 바람에 얼마나 많은 기업이 몰락했던가? 구글은 이런 전철을 밟지

않기 위해 노심초사하는 듯 보인다.

- 98 -

여러 가지 골치 아픈 방해물이 계속 등장하고 있음에도 불구하고 구글이 무럭무럭

커나가는 이유를 분석한 기사(www.fastcompany. com/magazine/69/google.html)가

있다. 이 기사에 따르면 구글은 사용자 위주로 지적인 문제 해결을 도와주는 데

최선을 다하며, 세상을 연구소처럼 여겨서 필요한 모든 기술을 다듬어 보며, ‘실패는

멋지며, 좋은 실패는 더욱 멋지다’라는 생각으로 실패를 두려워하지 않고 창의적인

서비스와 제품을 만들어보며, 사용자가 몰리면 돈도 함께 몰린다는 생각으로 훌륭한

제품 개발에만 신경을 쓰고 있기 때문에 계속해서 성장할 수밖에 없다고 한다.

하지만 경쟁사와 치열한 접전을 벌이는 절박한 상황에서도 정신력으로 자료를 찾을 수

있다는 구글 멘탈 플렉스(www.google.com/ mentalplex/), 구글 검색엔진이 사용하는

페이지랭크 시스템 이면에는 비둘기가 개입되어 있다는 피전랭크(www.google.com/

technology/pigeonrank.html) 시스템, 구글 상표를 붙인 머리에 좋아지는 음료수인

구글 걸프(www.google.com/google gulp/)와 같은 만우절 유머를 사용자에게 깜짝

선물로 던져주는 ‘구글의 센스’야말로 구글을 지속적으로 성장하게 만드는 원동력이

아닐까 싶다. 유머와 기발함이 살아있는 동안에는 구글도 계속해서 함께 성장할

것으로 믿으며 특집 기사를 마무리하겠다.

제공 : DB 포탈사이트 DBguide.net

출처명 : 마이크로소프트웨어 [2005 년 10 월]