2006/12/19

저는 네이버, 다음, 엠파스등의 검색엔진을 거의 전혀 이용하지 않습니다. 검색을 위한 거의 대부분의 시간을 구글에서 보내는데, 검색꺼리의 거의 전부가 직업과 관련된 기술적인 내용이다 보니 이러한 검색생활 패턴을 가지게 되었습니다. 기술문서와 관련된 정보에 관한한 구글이 가장 좋은 검색품질을 보장한다는 것은 변함없는 사실이니까요.

이렇게 구글을 이용한 검색이 일상 생활화 되었음에도 불구하고, Google이 의미하는 바에 대해서는 전혀 관심이 없었습니다. 원하는 바만 잘되면 된다 라는 지극히 무책임한? 성향때문이리라 생각됩니다.

그런데 어느날 우연찮게 이 Google이란 것이 칼세이건교수의 코스모스에 언급되었던 단어라는걸 알게되었고, google이란 용어에 대해서 전혀 새롭게 보게 되었습니다.

보내는 사람 MyDeskTop
이유는 고등학교 시절 제가 가장 감명깊게 읽었던 책이 바로 이 코스모스였으며, 가장 존경하는 인물중 한명이 바로 칼 세이건 교수이기 때문입니다. 지금도 가끔 이 책을 들여다보며, 코스모스의 영향을 받은 콘텍트라는 영화를 보고 있습니다.

보내는 사람 MyDeskTop
콘텍트? 콘텍트와 코스모스와의 관계가 있던가 라고 생각하는 분들도 계실지 모릅니다. 제가 처음 이 영화를 본게 아마 2002년 쯤이였으리라 생각됩니다. 영화의 후반부를 보면 조디포스터가 공간을 뛰어넘는 비행체를 타고 우주항로를 여행하는 장면이 나옵니다.

거기에 보면 몇몇 행성들이 나오는데, 이 장면을 보면서, 어라 어디서 본장면 같은데?라는 애매모호한 느낌이 들더군요. 사실 그 장면을 보기 전 부터.. 왠지 익숙한 기분의 영화였습니다. 그러던 중 영화의 마지막에 이 영화를 칼 세이건 박사에게 바칩니다라는 자막이 올라가는걸 보면서, 아 이 영화가 코스모스의 영향을 받아서 제작된 영화구나라는걸 알게 되었습니다.

그 자막을 보면서, 마치 가장 존경하는 사람의 숨겨진 유작을 대하는 것과 같은 전율까지를 느꼈습니다. (오버라는 생각이 드실지 모르겠지만 정말로 그랬습니다. 이 영화는 DVD로 소장하고 있습니다.) 후에 컨텍트라는 영화의 공동작가이자 프로듀서가 칼 세이건 박사의 부인인 얀 드류얀이라는 사실을 알게 되었습니다.

저자인 칼세이건은 우주어딘가에 인간과 같은 사고를 하는 고등 생명체가 살고 있을것이라고 생각을 했었습니다. 그러한 고등생명체가 살고 있다면, 그 행성은 행성표면이 밤에도 불빛으로 환하게 빛나며 그 궤도에는 인공 조형물이 행성을 감싸고 있을것이라고 생각을 했습니다. 책에는 그러한 행성을 묘사한 그림도 포함되어 있습니다. 조디포스터가 처음 방문한 행성이 코스모스에 나온 바로 그 행성입니다. 그렇습니다. 고등학교 1학년 때 읽었던 책의 한귀퉁이에 실려있던 사진만으로도 10년이 훌쩍 지난 후의 영화에서 동일한 장면을 가려낼 수 있을 정도로.. 전 이책을 사랑했던 겁니다.

얘기가 잠시 딴데로 흘렀군요. 구글 얘기로 되돌아가 보기로 하겠습니다. 책에서 google은 우주의 크기가 얼마나 될까를 생각하는 과정에서 나오게 됩니다. 우주란 워낙에 커서, 기존의 숫자체계만으로는 도저히 나타낼 수가 없었기 때문입니다. 그래서 조카이던가 에게 10^100이라는 큰수가 있는데, 이걸 뭐라고 부르면 좋겠니 ? 했더니 그 조카가 구글요 해서 구글로 부르기로 했다는 얘기가 나옵니다.

10^100은 어느정도의 크기일까요. 책에 나온바에 따르면, 현재 관측된 (아마 지금은 그 때보다 더 멀리 관측되고 있겠지만) 우주에 원자를 가득 채워넣기 위해서는 10^80개 정도가 필요할 것이라고 쓰고 있습니다. 그래서 생각한 숫자가 10^100 이죠. 책에서는 이보다 더 큰 숫자인 10^100^100 도 기술하고 있습니다. 이 숫자는 구글플럭스라고 명명을 했습니다. 둘다 구글 혹은 구글플럭스라는 식으로 간단히 기술할 수 있지만, 무한이나 마찬가지인 숫자들이죠.

검색엔진 구글은 이를테면, 무한에 가까운 정보를 처리하고 검색할 수 있게끔해주는이라는 상징적인 의미를 담고 있다고 할 수 있습니다.

다음은 그의 저서 코스모스에서 가장 감명깊게 읽었던 구절로, 그의 부인인 앤에게 바치는 글입니다.
광대한 우주, 그리고 무한한 시간..
이 속에서 같은 행성, 같은 시대를
당신과 함께 살아 가는 것을 기뻐하면서

- 칼 세이건.

태그 :

2006/12/13

FireFox 2달간의 점유율 변화

FireFox 2.0이 발표된지 한달 가까이가 지난거 같다. IE7.0역시 비슷한 시기에 발표가 되었다. 이쯤에서 브라우저 점유율이 어느정도 변했는지 알아보는 시간을 가졌다. 데이터는 개인 사이트인 http://www.joinc.co.kr 의 방문자를 대상으로 했으며, 구글 웹 정보 분석기를 이용해서 조사했다.
운영되는 사이트는 Linux 시스템/네트워크 프로그래밍 관련 사이트이므로, 다른 사이트보다는 Firefox사용자가 약간은 많을 수도 있을 거라 생각된다.

2006년 9월 11일 조사한 결과다.


다음은 2006년 11월 27일 조사한 결과다.


FF의 사용자가 2% 정도 증가한거 같다. 아직 발표된지 한달 밖에 안된 시점이라서, FF의 점유율이 더 떨어질 수 있겠지만, 지난 1년동안 점유율 이 5%가량 변한거에 비하면 상당히 많은 점유율의 변화가 있었음을 알 수 있다. FF의 점유율이 비교적 높은 다른 국가는 더 많은 점유율의 변화가 있었을 것으로 생각된다.

아래는 2006년 12월 17일의 결과치다.
보내는 사람 Development
초기 FireFox2의 반짝효과 때문에 늘어났던 점유율이 약간 줄어들 것이라 예상했지만 20일전에 비해서 오히려 늘어났음을 확인할 수 있다. IE7까지 발표된 시점에서 약간은 의외의 결과다.

2006/12/11

구글 Web Picasa

이미지 관리

Picasa는 구글의 이미지 관리 프로그램으로, 웹서비스와 데스크탑 서비스를 위한 프로그램을 모두 제공한다. 다른 구글의 서비스들이 그렇듯이, 구글의 웹스토리지를 이용해서 이미지를 관리/공유할 수 있도록 하고 있다. 특히 만들어진 이미지를 자신의 블러그와 웹페이지등에 쉽게 개설할 수 있다는게 마음에 든다. 아래의 이미지들은 모두 picasa를 통해서 관리되고 있다. 해당 이미지에 대해서 임베드메뉴를 클릭하면 HTML 코드가 생성되는데, 가져다 붙이기만 하면 된다.
보내는 사람 MyDeskTop

이미지는 JPEG, BMP, GIF, PSD, PNG뿐만 아니라, AVI, MPG, ASF, WMV등도 지원하며, Picasa데스크탑 프로그램을 이용하면, 포토샵이나 gimp등의 복잡한 프로그램을 이용하지 않더라도, 이미지 보정, 자르기, 색상조정 등을 이용해서 간단한 수준의 편집을 할 수 있다.

공유

사용자는 다양한 앨범을 만들 수 있으며, 이를 공유할 것인지를 결정할 수 있다. 공유는 구글메일과 비슷한 초대과정을 거쳐서 이루어진다.
보내는 사람 MyDeskTop

기본공간

기본 공간은 250M 이며, 주어진 공간 이상을 할당 사용할려면, 일정 비용을 지불해서 저장장치를 업그레이드 해야 한다.
보내는 사람 MyDeskTop

데스크탑 Picasa

데스크탑 응용으로, 웹에서 할 수 없는 이미지 편집등의 작업을 할 수 있다. 또한 데스크탑에 있는 이미지들을 몽땅 scan해서 찾아주는데, 때문에 여기저기 짱박혀서 잊어버리고 있었던 (그러나 중요한) 이미지들을 일괄적으로 관리할 수 있다. 개인적으로 사용했던 리눅스박스에 Picasa를 이용해서 이미지 스캔했더니, 무려 5년전의 이미지들 까지 검색되었다.

리눅스용 Picasa2

회사 업무뿐만 아니라, 게임을 제외한 모든 일을 리눅스를 이용해서 처리하는 입장에서, 리눅스용 Picasa가 없다는 것은 매우 아쉬움이 남았었는데, 다행히 얼마전에 리눅스용 데스크탑용 Picasa2.0이 공개되어서 사용할 수 있게 되었다.

리눅스용 Picasa2는 http://picasa.google.com/linux 에서 다운로드 받을 수 있다. 이로써 리눅스에서도 좀더 편리하게 이미지를 관리할 수 있는 길이 열렸다. 앞으로 개인 블러그나 wiki에 사용될 모든 이미지를 Picasa를 통해서 관리해볼 생각이다. 인터넷에만 연결되어 있다면 사용가능하다는 것은 역시 사용자에게 엄청난 편리함을 가져다준다.
보내는 사람 MyDeskTop

게다가 tray에 예쁘게 배치된다.
보내는 사람 MyDeskTop

2006/12/04

ESM에 대해서

Enterprise security management로 보안관리를 전사적인 차원에서 체계적으로 관제/관리 하기 위한 시스템

ESM의 필요

  • 다양한 보안제품과 통일되지 않은 로그로 인한 효율적인 관제 불가능
  • 표준화되지 않은 로그로 인한 효율적인 모니터링의 어려움을 해결하기 위한, 로그표준화 논란이 있었으나 진척이되고 있지 않음
  • 보안인력 확보의 어려움

ESM의 구성


  • 정규화 모듈 : 다양한 종류의 보안제품과 이들의 로그를 분석해서 정해진 포맷으로 정규화 시킨다.
  • AC 모듈 : 정규화된 로그를 분석해서 보안룰에 통과 시켜서 이벤트를 발생한다.
  • Comm 모듈 : 이벤트 혹은 정규화된 로그를 Monitor혹은 상위 ESM System에 전달한다.
  • DB 모듈 : 이벤트 혹은 정규화된 로그를 DB에 저장한다.

AC 모듈

  • 정규화모듈을 통해서 정규화된 로그를 받아들이고 이를 룰에 통과시켜서, 룰을 만족하면 이에 해당되는 이벤트를 Comm모듈로 전달
  • 받아들인 로그를 DB에 저장하기 위해서 DB모듈로 전달

연관관계분석엔진




  • 이벤트간의 연관관계를 분석해서 새로운 이벤트를 만들어내는 엔진
  • ex) 정해진 호스트에 대해서 Port Scan 발생후 SSH 연결이 일어나고, SU가 발생하면 RRS 이벤트를 발생하라.
  • 2차원 이벤트군에서 일정한 범위의 이벤트를 묶기 위해서 RTree를 이용
  • 이 방식의 경우 실시간성을 유지할 수 있으나 많은 양의 메모리를 사용하게 된다.
  • 정확히는 2차원이 아닌 1차원배열에서 필요한 이벤트를 모으는 방식으로 완전한 rtree라고 할수는 없다.

칩입탐지엔진

  • 보안관제에서 실질적으로 가장 중요한 이벤트는 DOS/DDOS 이다.
  • 이 엔진은 이벤트를 카운팅해서 목적/출발지 호스트에 대한 공격출발지와 공격목적지에 대한 정보 획득

  • 출발지 호스트를 기준으로 할경우 매우 넓은 범위의 IP에 대한 정보를 획득해야 하기 때문에, HashMap을 구현
  • Map은 <{IP,PORT},INFO>의 쌍으로 이루어진다.
  • 실시간으로 정보를 획득하는 모델의 경우 메모리관리가 중요해진다. 이를 위해서 의 별도의 테이블을 구성

서비스 침입징후탐지엔진

  • 네트워크 대역에 대한 서비스별 증가 추이에 대한 데이터를 수집하고, 이들 추이를 분석해서 침입징후를 판단.
  • 시간/일간/주간/년간 증감추이에 대한 데이터를 저장

  • 데이터 베이스는 RRD(:12)와 같은 구조라고 볼 수 있으며, 아카이브를 만들지 않는다. 이런 이유로 DB파일의 크기가 커질 수 있다.
  • DB파일은 압축효율이 매우 좋으므로 압축관리 하면 공간을 절약할 수 있다.
  • RDBMS를 사용하지 않는 이유는, RDBMS를 이용하는 것보다 더 빠르며 작은 크기를 유지할 수 있기 때문이다.

2006/11/27

FireFox 점유율 변화

FireFox 2.0이 발표된지 한달 가까이가 지난거 같다. IE7.0역시 비슷한 시기에 발표가 되었다. 이쯤에서 브라우저 점유율이 어느정도 변했는지 알아보는 시간을 가졌다. 데이터는 개인 사이트인 http://www.joinc.co.kr의 방문자를 대상으로 했으며, 구글 웹 정보 분석기를 이용해서 조사했다.

2006년 9월 11일 조사한 결과다.


다음은 2006년 11월 27일 조사한 결과다.


FF의 사용자가 2% 정도 증가한거 같다. 아직 발표된지 한달 밖에 안된 시점이라서, FF의 점유율이 더 떨어질 수 있겠지만, 지난 1년동안 점유율 이 5%가량 변한거에 비하면 상당히 많은 점유율의 변화가 있었음을 알 수 있다. FF의 점유율이 비교적 높은 다른 국가는 더 많은 점유율의 변화가 있었을 것으로 생각된다.


2006/11/25


서핑을 하다가 도메인의 가격을 평가해주는 재미있는 서비스를 하는 사이트를 발견했다. http://leapfish.com 라는 사이트인데, 평가하고자 하는 도메인 이름을 입력하면 가격을 측정해준다. 혹시나 하는 마음에 내 사이트를 측정해 보았다.

Appraisal.png

구글은 21,656,670 달러, 야후 46,918,286, 네이버 11,976,101 로 측정이 되었다.

평가의 척도는 페이지랭크기반으로 주요 검색엔진에서 얼마나 많은 링크를 포함하고 있는지가 가장 중요한 척도다. 도메인에 포함된 컨텐츠의 가치라든지, 다른 마케팅적인 요소들은 포함하지 않고 있다. 또한 비상업적인 1차도메인 명인 org,edu 등은 매우 낮은 가격으로 평가되고 있다.

2006/11/24

WebOS의 미래

WebOS

web os라는 용어는 낯설지만 개념은 그리 낯설지 많은 않을 것이다.HTML, JAVA, HTTP등의 프로토콜을 이용해서, 네트워크 상에서 구동되는 Network Computer 에 대한 구상은 10년전인 1996년부터 시작되었다. 용어에 있어서 차이는 있지만 네트워크 상에 데이터를 저장하고 처리한다는 점에 있어서, NC와 web os는 추구하는 바가 매우 비슷하다 할 수 있다.

NC를 완성하기 위한 많은 노력이 있었고, 특정 분야에 도입되기도 했지만 일반인과는 거리가 먼 실패한 제품이였다. 개념은 훌륭했지만 느린 하드웨어와 네트워크 속도, 무거운 가상머신과 시스템에 대한 불충분한 이해와 인프라의 미비 때문에 성장하지 못했었다.

그러던 것이 구글 데스크탑과 윈도우 live Desktop 으로 가능성이 주목받고 있다. 이들 WebOS의 구상은 다음과 같다.

webos.png

Browser는 Web Server를 통해서 인증과 같은 필요한 절차를 거치고, 가상화된 Storage에 자신의 정보를 저장한다. 이들 정보는 Web Service 형태로 다시 서비스 된다. 내부적으로는 분산처리 System에서 개인정보와 Sotrage의 정보를 분석해서 개인화된 정보를 서비스 하고, 정보를 색인해서 빠르게 검색할 수 있도록 한다.

Gadget은 브라우저와 독립적으로 실행되어서 웹서비스를 이용하는 조그만 소프트웨어로 자신만의 웹 데스크탑 환경을 구축하게 해준다. 또한 시간이 충분하다면, 자신만을 위한 혹은 공유가능한 유용한 웹애플리케이션의 제작이 가능하다.

이를 가능하게 해주는 기술들로는 아래와 같은 것들이 있다.
  • HTTP(:12)
  • Ajax(:12)/Javascript
  • HTML(:12)
  • 가상화 기술 / 분산처리 기술

Web OS를 긍정적으로 보는 이유

NC가 실패했기 때문에 Web OS가 실패할 것이란 얘기를 많이 듣는다. 가장 큰 이유는
  1. 느리다
  2. 쓸만한 응용이 없다.
  3. 대중에게 파고들만한 인프라가 구축되어있지 못했다.(시대를 앞선 기술)
정도가 될 거 같다.

1번 문제에 대해서는 웹 OS의 개념에 대해서 확실해 해둘 필요가 있는데, WebOS는 데스크탑의 모든 것을 포괄하지 않는다. 기존의 Web환경과 데스크탑영역의 일부분을 웹환경의 영역으로 확대시키겠다는 개념이다.

게임등과 같이 반응과 처리속도가 중요한 영역은 당연히 기존 데스크탑영역에 그대로 머무르게 될 것이다. 그러나 그렇지 않은 부분들 중 데이터가 공유되거나 가상화 되었을 때, 이득을 볼 수 있는 많은 응용은 WebOS 영역으로 넘어갈 것이다.

만들어진 데이터를 자신의 PC에서만 다루던 시대는 이미 지났다. 이동성이 중요해졌으며, 동일한 데이터를 PC, 인터넷에 연결된 다른 컴퓨터, 핸드펀과 같은 소형 모바일기기에서 보고/공유할 수 있어야 한다. 이건은 먼 미래의 요구가 아니며, 지금 요구되어 지는 기능들이다. 이에 웹은 최상의 환경을 제공한다.

문서작성을 예로 들어보자. googledocs를 사용해 보면 알겠지만 딱히 느리거나 크게 불편하다는 생각이 들지 않는다. 복잡한 문서를 작성하기엔 속도와 기능상의 문제가 있겠지만 80%이상을 차지할 거라고 생각되는 간단한 문서 (예를 들어 블러깅을 위한)를 생성하는 데에는 문제가 없다. 만들어진 문서는 가상화된 Storage에 저장이 되기 때문에, 어떤 컴퓨터에서라도 브라우저만 설치되어 있다면 접근할 수 있으며, 웹과 다른 블로깅시스템으로의 출판, 검색등이 자유롭다. 자신의 데스크탑의 검색 결과를 네트워크 상에서 확인할 수 있는 서비스도 추가되어 있으며, 결국 웹에서 작성한 모든 컨텐츠가 기기에 관계없이 편집/수정/출판/검색/공유 할 수 있도록 될 것이다.

그 밖의 웹에서 다루는 데이터는 그 특성상, 반응속도가 중요하지 않는 경우가 많다. RSS 정보를 본다거나, 문서/이미지/동영상/블로문서/메일 검색, 추천정보확인 모두 반응과 속도가 중요한 응용들이 아니다.

쓸만한 응용이 없다는 의견에 대해서라면, RSS 피드정보, 검색, 메일 등의 웹정보가 가장 유용한 정보가 된 현시점에서는 문제가 되지 않을 거라 생각한다. 많은 유저가 게임을 하는 시간을 빼고는 대부분의 시간을 RSS 확인과 검색, 몇 개의 이미지를 포함한 간단한 문서작성등에 보내고 있다. 웹데이터를 잘 다루는 소프트웨어가 쓸만한 응용인 셈이다. 올블러그의 10개의 인기 블러그를 보여주는 응용이 쓸만한 응용이 된 세상이다. 여기에 더해서 웹OS는 가상화 기술을 통해서 모든 기기에서 데이터를 공유할 수 있는 가능성을 열어두고 있다.

http://www.eyeos.org 를 보기 바란다. 아직 부족하긴 하지만, WebOS의 방향을 가늠해 볼 수 있을 것이다.

eyeos.png

기업에서의 WebOS 의 사용

WebOS는 기업에서도 지식관리시스템의 구축을 위한 좋은 환경을 제공한다. 웹으로 묶여진 가상의 공간에서 의견과 생산된 정보를 저장하고 공유/검색 할 수 있는 것이야 말로 지식관리 시스템의 핵심이니까 말이다. 이러한게 가능하려면 물론 회사의 정보가 외부의 저장장치에 저장이 된다는 데에서 오는 부담감을 해결할 수 있는 신뢰도가 확보되어야 할것이다. 우리나라는 아직 요원해보이지만, 많은 회사들이 위키를 중심으로 하는 지식관리 시스템을 구축하고 있으으며 이를 위한 위키호스팅 업체도 영업을 하고 있는 상황이다.

WebOS는 이러한 것들을 망라해서 최적의 지식관리 시스템을 만들어 줄 수 있다. 일종의 회사 인트라넷 자원관리를 위한 호스팅 서비스라고 부를 수 있을 것 같은데, 구글은 이미 기업용 호스팅 서비스를 선보이고 있다. 아직은 베타이긴 한데, 2GB의 스토리지를 할당하고, 이 한도내에서 자사의 서비스인 Gmail, Google Calendar, Google Talk, Page Creator 등의 웹서비스를 사용할 수 있도록 하고 있다. 여기에 조만간 위키시스템이 추가되고, 이들 웹서비스들이 구글 테스크탑환경에 맞도록 조절된다면 필요한 요소가 모두 갖추어진 기업용 WebOS가 탄생하게 될 것이다. 위키와 관련된 내용은 [http]구글 잣스팟 인수 뉴스를 읽어보기 바란다.

구글 서비스 관련 문서


이름 제목 변경일 크기
Adsense 구글 Adsense 연구 2006/09/06 20:07 958
Blogger 구글 Blogger BETA 2006/10/27 17:17 59
CodeSearch Google source code 검색 2006/10/09 19:10 1030
Gadget 구글 가제트 2006/11/15 13:07 1359
GoogleMapAPI 구글맵 API를 이용한 Map Service 2006/11/23 03:05 17232
Office 구글 Docs 2006/10/25 15:01 50
QueryStatis 구글 인기검색어 2006/11/13 11:11 511
Reader Google Reader 2006/10/25 10:55 55
ScholarSearch 구글 논문 검색 2006/10/10 13:29 325
WebMaster 사이트 관리자를 위한 구글 서비스 2006/09/06 12:03 87
WebOS WebOS의 미래 2006/11/24 00:15 5447
WhyGoogleMap 구글 Map 서비스의 가능성 2006/11/05 23:21 66
coop 구글을 이용한 나만의 검색엔진 만들기 2006/10/30 17:29 78

2006/11/22

애드센스로 1,000달러 벌기

애드센스 한달 1,000달러목표


한달에 애드센스만 으로 1,000달러 한화로 약 100만원의 수익을 얻을려면 어느정도의 방문자와 광고노출/클릭이 발생해야 할지 나름대로 계산해 봤다. 순수 개인 사이트를 기준으로 할것이다. 일단 4개월 정도 애드센스를 사용해본 경험을 토대로 방문자수,노출,클릭율에 대해서 다음과 같은 가정을 했다.
  • 방문자수 : 1,600
  • 광고노출 : 5,000
  • 클릭율 : 0.5%
  • 클릭수 : 25
  • 클릭당 수입 : 0.5달러
  • 페이지 최고랭크 : 4/10
이 경우 하루에 벌어들일 수 있는 수익은 한화 12,5000 원. 한달에 100만원을 벌어들이려면, 하루 30,000원을 벌어들여야 한다고 봤을 적에, 방문자수를 2.4배 만큼 늘려야 된다는 결론이 나온다. 방문자수가 하루 평균 3,840명 이상이 되어야 한다는 얘기다. 주말에는 방문자수가 급감하므로, 평일에 4,000명 이상의 방문객을 유지할 수 있어야 할 것이다.

개인사이트로 평일에 4,000명 이상의 방문객 유지라. 사이트와 컨텐츠의 특성에 따라서 달라지겠지만, 개인유저가 평일 4,000명의 방문자를 유지하는건 쉬운일이 아니다.

그리고 위의 가정은 내가 봤을적에 매우 긍정적인 가정이다. 클릭율 0.5%는 달성하기 쉬운 수치가 아니다. 보통은 0.3정도의 수치를 보준다. 베너를 매우 적극적이고 효율적으로 배치했을 때나 가능한 수치인데, 베너를 적극적으로 배치하게 될경우 사이트에 대한 거부감이 생길 수도 있다는 것을 고려해야 하기 때문에 신중해질 수 밖에 없다. 이 경우는 거부감을 극복할 수 있을 정도의 수준있는 컨텐츠를 제공하는 수 밖에 없는데, 이 역시 쉬운일이 아니다.

게다가 또다른 문제가 있는데, 클릭당 수익이 500원이 만들어지느냐 하는 것이다. 클릭당 수익 500원은 과거에 등장했던 광고나 지금의 다른 유사한 광고들과 비교해도 상당히 큰 금액이다. 애드센스의 클릭당 수익이 어떻게 정산되고 있는지 정확히 알지는 못하지만, 페이지랭크가 높을 수록 높은 수익을 얻는 것으로 생각된다. 이상에서 클릭당 수입 500원이란 위의 결과는 페이지 페이지 랭크가 4이상이 되어야 달성되는 금액이라고 볼 수 있는데, 랭크를 4이상 올리는건 절대 쉬운일이 아니다.

페이지랭크는 페이지를 참고하고 있는 페이지의 수에 따라 결정된다. 자신의 페이지를 링크하고 있는 사이트가 많을 수록 랭크가 올라간다는 개념인데, 결국 애드센스만으로 높은 수익을 얻기 위해서는 많은 유저가 방문하고, 링크로 참고할 만한 높은 품질의 컨텐츠를 보유 해야 한다는 (어찌 보면 뻔한) 결론에 도달하게 된다.

취미생활정도로 생각해서는 절대 한달 1,000달러라는 수익을 얻을 수 없다는 얘기가 되겠다.

국내에서 한달 300 달러의 수익을 얻어내는 개인사이트(혹은 블러그)는 1%에 한참 미달될거라고 생각된다. 앞으로 구글이 광고주를 적극적으로 유치하고 홍보를 할 경우를 생각해서 개인사이트로 노릴 수 있는 현실적인 금액은 500달러정도가 되지 않을까 싶다. 절대? 넘을 수 없는 금액은 2,000달러 정도가 될거라고 생각된다.

1000달러를 넘어서

2,000달러 이상의 금액을 얻기 위해서는, 결국 영문으로 정보를 제공해야 된다고 생각이 되는데, 영어사용자가 한글 사용자의 10배가 되고, 문서의 양은 100배이 상이 되기 때문이다. 문서가 많다는 것은 그만큼 수요가 많다는걸 의미한다. 시장이 크다는 얘기인데, 영어권에서도 통하는 컨텐츠를 제공할려면 어학능력은 별개로 컨텐츠의 성질도 매우 중요할 것이다. 국내에서 인기있는 컨텐츠라고 해서 영어권에 통하리란 보장이 전혀 없기 때문이다. 스포츠/연예/문화 정보를 제공한다고 했을 경우, 영어권의 컨텐츠제작자들 보다 양질의 정보를 제공하기가 힘들 것이기 때문이다. 특히 이런 분야는 표현력이 중요하니 어학능력도 큰 문제가 될 것이다.

내 생각엔 전문기술정보를 영어화 하는게 그나마 가능성이 있다고 생각된다. 뭐 하긴 이건 아직 먼나라 얘기긴 하다. 일단 한글로된 양질의 컨텐츠 확보가 우선 과제라 하겠다.



2006/11/21

비오는날 생각나는 영화 한편

비오는날 생각나는 영화 한편
fses.cine.blade.runner.a4.jpg

주말엔 줄기차게 비가 온다고 하니.. 잘됐네.. 집에 짱박혀서 영화나 봐야겠다. 그런 의미에서 비오는날 보기 좋은 영화

브레이드 러너


이 영화를 본게 대학 3학년 쯤인가 싶다. 노가대를 가서 일하던 인부와 영화 얘기 하던중 꼭한번 보라고 해서 본 영화다. 비디오 방에서 대여해서 빌려본 후 최고의 영화가 되었다. 지금까지도 변함없이..


필리 K. 딕의 원작인 '엔드로이드는 전기양의 꿈을 꾸는가'를 영화화한 이 작품은 2019년의 황량하고 암울하고 습기가득한 어두운 미래의 로스앤젤레스를 배경으로 하고 있다. 기계 문명에 찌든 (별로) 인간답지 않은 인간과 그런 인간이 만들어낸 인간 보다 인간다운 리프릴컨트와(인조인간)의 사투와 인간적 고뇌를 그려내고 있다.


개봉당시에는 지나치게 어두운 미래 설정과 난해한 이야기로 비평가들에게 혹평을 받으며 참패를 면치못했지만 (게다가 ET와도 경쟁해야 했었다) 거의 광적이다 시피한 팬들의 지속적인 지지를 받으며, "명작,걸작"이라는 칭호를 받게 되었으며, 사이버펑크의 대표작, 포스트모더니즘을 선도한 교과서적인 영화로 까지 지위가 격상되었다. 이 후 만들어진 매트릭스, 다크시티, 12몽키스, 공각기동대 등 디스토피아 적인 미래를 그리고 있는 작품들을을 보면 확실히 브레이드 러너의 영향을 받고 있음을 확인할 수 있다.


브레이드 러너에서 가장 기억에 남는 장면은, 리플리컨트인 배티와 브레이드 러너인 데커드가 마지막 사투를 벌이는 장면이다. (4년이라는 제품의?) 수명이 다한 배티가 자신의 동료와 애인을 죽인 데커드를 구해주고 내리는 빗속에서 생을 마감하기전 독백을 하는 장면이다. 가장 멋진 영화 대사라고 생각된다. 이보다 멋진 영화대사는 도무지 생각이 나질 않는다.

배티 : 난 당신들이 상상하지도 못할 것들을 봤어. 
오리온별 옆에서 불타던 전함, 탠하우저 게이트 근처의 어둠속을 가로지르는 C-빔의 불빛도 보았어.
그 모든 순간들은 시간 속에서 사라지겠지. 빗속에 흐리는 내 눈물처럼(...like tears in rain ).
이젠 죽을 시간이야.

데커드(독백): 난 그가 왜 나를 살렸는지 모른다. (중략) 그가 찾던 것은 우리 모두가 찾고 있던 답이다.
난 어디에서 왔나 ? 어디로 가나 ? 내게 남은 시간은 얼마인가 ?


인간에 의해서 전쟁무기로 제조된 배티가 가진 추억의 순간 이라고 하는 것들은 가장처참하다고 말하는 "전투"와 관련된 것들이다. 그러나 수명이 다한 순간에는 그 마저도 붙잡고 싶은 시간들이였음을 말해주고 있다. 어쨋든지 간에 살아 있다는 것 자체로 축복이라는 것을 말해주고 싶었는지도 모른다.

내게 남은 시간을 알고 있다면 어떨까 ?

2006/11/16

애드센스 부정클릭 문제와 해결 방안

CPC 기반의 웹광고 프로그램이 해결해야될 가장 큰 문제중의 하나가 바로 이 부정클릭이다. 구글의 CPC기반 광고 서비스인 애드센스역시 이러한 문제점을 가지고 있는데, 국내에서도 사용자가 늘어나기 시작하면서 부정클릭과 관련되어서 계정을 정지당했다는 소식도 심심찮게 들리기 시작하고 있다.

부정클릭이 전체 클릭의 20%를 차지하고 그 금액은 2,000억원에 이른다고 하니 광고주나 서비스하는 구글로써도 심각한 문제이긴 한거 같다. 광고주로써는 쓸데없는 지출이 늘어나는 것이 될거고, 구글은 서비스품질이 떨어지게 되는 것이니 장기적으로 광고수익이 줄어들게 될테니 말이다.

애드센스 사용자 입장에서도 그 피해는 상당한데, 의도하지 않은 상태에서 피해자가 될 수 있기 때문이다.

1 애드센스 부정클릭 정책

구글의 애드센스는 철저하게 광고주를 보호하는 정책을 펴고 있다. 약관을 보면 부정클릭이라고 생각할 수 있는 행위를 상세하게 나열하고 있으며, 이를 어길경우 즉각적인 계정취소와 함께, 지불되지 않고 남아있는 금액을 몽땅회수해서 광고주에게 되돌려 주겠다고 명시되어 있다.

원칙적으로 당연한 조항이라고 할 수 있다. 부정클릭은 바꾸어 말하자면 부정한 방법으로 광고주의 돈을 빼앗는 행위라고 볼 수 있기 때문이다.

문제가 되는건 구글의 애드센스 엔진이 자체적으로 부정클릭을 방어하기 위한 어떠한 장치도 제공하고 있지 않다는 점이다. 부정클릭에 대한 방어를 전적으로 애드센스 사용자에게 맡기고 있는 셈이다.

이렇게 하는 이유는 기술과 비용상의 문제가 가장 큰거 같다. 부정클릭은 판단하기가 매우 어려우며, 이를 제대로 판단하기 위해서는 모든 애드센스 사용자에 대한 클릭 히스토리를 유지하고 분석할 수 있는 높은 수준의 시스템을 갖추고 있어야 만 한다. 당연히 많은 인력과 장비가 투입되어야 할 것이다.

구글로써는 애드센스를 위해서 이러한 비용을 투자하는게 달갑지 않을 것이다. 애드센스는 개미군단으로 부터 100원씩 거두어 들여서 1조를 만드어내는 전형적인 롱테일 상품이다. 실제 (아마도)전체 애드센스 사용자의 80%정도는 하루에 구글에게 200원이하의 수익을 가져다 줄 것이라 생각된다. 이러한 롱테일 서비스에 대해서 모든 유저를 상대로 하는 부정클릭감지 시스템의 구축은 엄청난 낭비가 된다. 이를테면 100원씩의 수익을 가져다 주는 천만명 사용자의 부정클릭 방지 시스템을 유지하기 위해서 하루 50원씩 지출된다면, 하루에 날아가는 돈만 5억원이 되는 거다.

결국 생각할 수 있는 방법은 부정클릭에 대한 방어와 책임을 사용자측에 분산 부담시키는것이 될 것이다. 개인적으로도 애드센스와 같은 롱테일 상품에 대해서는 이러한 정책이 옳다고 생각이 된다.

1.1 부정클릭의 범위

상당히 광범위 하다. 그 중 중요한 것만 간추려보자면
  1. 반복된 수동클릭/자동클릭
  2. 클릭을 유도하는 직간접적인 행위들 : 예를들어, 요즘 클릭율이 좀 떨어지고 있는것 같네요^^; 이런 문구도 클릭을 유도하는 간접적인 행위로 판단한다.
  3. 불법적인 내용을 게재한 사이트
  4. 어떤식으로든 노출된 광고 컨텐츠를 편집하는 행위
등등 12가지 상황에 대해서 상세하게 명시하고 있다.

또한 추천버튼에 대한 클릭수, 노출, 클릭시기 등과 관련된 어떠한 보장도 하지 않는다고 하고 있다. 이를테면, 어떤이유로 구글로 부터 부정클릭이 발생해서 계정을 중지합니다. 라고 하더라도 이에 대해서 근거를 요구할 권리가 주어지지 않는다는 얘기가 된다.

1.2 웃대 사건

애드센스를 대한민국에 알리는데 역할을 한 유명한 사건이다. 상당한 회원수를 유지하던 웃대는 수익원의 일종으로 애드센스를 게재했고, 아마도 상당히 많은 수익을 발생시켰던 것으로 알고 있다. 정확한 액수는 모르지만 방문자수등으로 추정해 봤을 때, 한달에 천만원이상이었을 것으로 예상한다.

그런데 지급이 되기전에, 부정클릭 통보를 받고 계정이 정지되고, 부정클릭과 관련된 금액을 포함한 모든 수익이 광고주에게 완전히 환원되어 버렸다. 이에 웃대가 관련사항을 정리해서 언론에 알리고, 사이트에 게제하면서 널리 알려졌다.

이와 관련되어서 구글이 악마가 되었다라는 얘기도 한다. 어떤 근거인지는 모르겠지만 단순히 계정완전정지에 수익몰수했으므로 악마화 되었다는게 근거라면, 이건 근거가 되기 힘들다는게 개인적인 판단이다.

수익을 몰수할 경우, 이돈은 구글의 주머니로 들어가는게 아니고 광고주에게 전원되돌려진다. 구글은 중간에서 얻는거 아무것도 없다. 수익이 애드센스 사용자에게 지불이 되어야 비로서 구글도 중간에서 수익을 얻어내는 구조이기 때문이다. 구글로써는 사용자가 적당히 부정클릭을 하더라도 모른척하고 넘어가는게 단기적으로 이익이다. 웃대에 돈을 지불할 때쯤되니까 구글이 수익을 갈취할려고 그러그러한 행동을 했다 라는 것은 잘못알고 있는 사실이다.

애드센스는 소비자가 비용을 지불하고 기업으로 부터 물건을 사는 일반적인 거래와는 성격이 다르다. 오히려 반대로 소비자가 기업으로 부터 돈을 받는 형태고 구글은 이들 사이를 중계해주고 수수료를 챙긴다. 당연히 돈을 지불하는 광고주인 기업이 우선적으로 보호되는 정책을 취할 수 밖에 없다. 애드센스와 같은 서비스의 경우 기업이 소비자가 되는 셈이기 때문이다. 결국 돈을 벌어들이는 입장인 유저측에서 악의적이라고 생각되는 부정클릭등에 대한 대비책을 내놓아야 된다는 결론에 도달한다. 돈을 버는 측이기 때문이다.

호스팅 업체라면 고객을 위해서 자체적으로 부정클릭 방지 솔류션을 제공하고, 개인이나 회사가 직접 운영할 경우 필요한 프로그램을 설치하는 등의 수고스러움을 감당해야 할 것이다. 역시 돈을 번다는 건 쉬운일이 아니다.

2 부정클릭 방지 프로그램

필요는 발명의 어머니라는 속담이 여기에도 통한다. 결국 애드센스 사용자를 위한 부정클릭 방지 프로그램이 애드센스 사용자에 의해서 개발이 되었다. 그정 Adlogger이라는 프로그램을 소개한다.

이 프로그램은 다음과 같은 방식으로 부정클릭을 방지한다.
  1. 동일한 IP의 유저가 1시간에 1번이상 클릭하지 못하게 한다라는 식의 부정클릭 룰을 만든다.
  2. 사용자가 광고를 클릭하면, 자바스크립트를 통해서 click event를 얻어내고, 클릭한 유저의 IP,시간 정보를 저장하고 카운트 한다.
  3. 사용자가 최초광고를 클릭한 후 1시간이 지나지 않아서 광고를 클릭하면, 룰을 위반하게 되고, adsense 클릭으로 유도되지 않는다.
 유저가 배너를 클릭하면 DB에서 유저의 IP에 대한 count정보를 얻어온다.
만약(count가 룰에 정한 카운트보다 작다면)
{
광고를 출력한다.
}


이외에도 모든 클릭에 대해서 시간과 IP별로 로그를 남긴다. 그러므로 사용자가 조금만 관심을 가진다면, 부정클릭으로 예상되는 경우를 어렵지 않게 발견할 수 있다. 사용자가 부정클릭을 찾아내고 이 사항을 구글에 알려주면 문제없이 해결된다.

adlogger.png

Adlogger는 PHPMysql을 필요로 하며, http://www.adlogger.org 에서 다운로드 받아서 사용할 수 있다.

2006/11/14

구글 검색어 통계

검색어 통계를 통해서 한달간의 인기검색어를 보여주는 서비스를 소개합니다. 검색패턴과, 트랜드를 국가별/월단위로 알 수 있습니다. http://www.google.co.kr/press/intl-zeitgeist.html

statis.png

32개국에 대해서 Top 15개의 쿼리 결과를 보여주고 있는데, 특이하게도 ? [http]wikipedia가 9개 국가에서 순위권에 들었네요. 독일 1위, 인도/멕시코/싱가포르 3위, 아일랜드 4위로 상위권이군요.

대한민국은 연예인 이름이 8건으로 연예관련 검색어가 대부분을 차지하고 있습니다. 좀 테크니컬한 주제들도 올라오고 하면 좋겠는데..

2006/11/07

구글 Map 서비스의 미래

구글 Map 서비스는 구글 검색 서비스와 광고를 제외한다면 가장 널리 알려진 서비스일거다 (아직 서비스라고 하기는 좀 뭐하지만). 구글 Map은 특히 거리를 지나가는 자동차까지를 보여주는 놀라운 위성사진의 능력을 보여준다. 몇몇 국가에서 보안상 중요한 지역의 지도를 서비스에서 제외시켜달라고 할 정도였다.

아래의 이미지는 일본동경시의 특정지역을 최대로 확대시킨 모습이다. 구글맵 서비스를 이용해서 나체의 여성을 찾으러 돌아다닌 다는 농담같은 얘기가 농담으로 들리지 않을 정도의 해상도를 보여준다.



하지만 구글 맵 서비스는 자신이 사는 집을 찾거나, 여성의 누드를 찾는 그 이상의 의미를 가지고 있다. 그것은 상업적인 용도로의 가능성이다. 사실 구글이 자선단체가 아닌 이상 상당한 비용을 들여서 저러한 양질의 서비스를 공짜로 제공할리는 없지 않은가 ?

이미 오래전부터 많은 인터넷 기업들은 맵의 상업적 가능성에 대해서 주목해왔었고, 네이버나 야후와 같은 포탈들은 맵을 이용한 상품을 이미 서비스하고 있다. 이를테면 강남에 있는 맛있는 한식집 등으로 검색어를 치면 지도에서 해당 위치를 표시해주는 방식이다.

그런데 유독 구글에 관심이 집중되는 이유는 뭘까. 놀랍도록 정교한 인공위성 사진과 거기에 맵핑되는 맵 정보를 유지하고 있다는 것, 최고의 검색관련 기술을 이용해서 맵 정보들을 효과적으로 검색할 수 있는 서비스를 만들 가능성들 때문에 유독 구글에 관심을 집중하는 것일 수도 있다. 딴은 맞는 말이기도 하다. 국내의 맵 서비스 같은 경우 (앞으로 추가가능성이 있긴 하지만)위성사진을 제공하지 않는다. 위성사진을 제공하는 구글 맵과 한번 비교해 보기 바란다.


아직 국내 구글맵은 위성사진만 제공하고 맵핑 지도는 제공하지 않기 때문에, 미국의 뉴욕시의 맵정보를 가지고 비교를 해보았다. 맵 서비스 자체만 놓고 봤을 때, 고객이 어느쪽 서비스를 선택할지는 명확하다. 지금 당신이 분위기 좋은 식당을 찾는다거나, 전세집 혹은 아파트에 대한 정보, 주말에 잠깐 다녀올 공원을 찾길 원한다고 가정해 보자. 어떤 서비스를 선택할 것인가 ?

게다가 구글은 전 지구에 대한 맵서비스를 구상하고 있다. 해외여행/유학/비니지스 등의 서비스를 제공할 수 있음을 의미한다.

하지만 필자가 구글의 맵 서비스를 긍정적으로 보는 데에는 구글의 OpenAPI와 개방적인 사이트단위의 맵서비스 정책 때문이다. 구글은 오래전부터 자사의 서비스에 대한 공개된 API를 제공함으로써, 개발자들이나 관심있는 회사가 쉽게 필요한 응용을 개발할 수 있도록 하고 있다. 이것은 단지 유능한 개발자집단으로 부터 피드백을 받을 수 있다는 것 외에도, 자신들의 기술에 대해서 우호적인 개발자와 회사를 만들게 됨으로 잠재적인 고객층을 확보할 수 있다는 장점을 가지게 된다. 구글 마니아, 구글 빠, 구글 문화, 구글 스럽다라는 용어가 생겨나는 이유가 여기에 있다. 즉 회사와 서비스/기술 자체를 홍보하는 효과까지를 누리게 된다. 이는 매우 큰 장점으로 최근의 많은 인터넷개발 회사들이 구글과 비슷한 정책으로 방향을 선회하고 있는 중이다.

구글의 OpenAPI와 사이트단위 서비스(혹은 개인화 서비스)능력은 단연 돋보인다. 구글 맵 OpenAPI는 구글 계정을 가지고만 있다면 아무런 제한이나 검토도 없이 즉시 자신의 사이트에서 테스트하고 필요한 응용을 만들 수 있다. 다음은 구글에서 제공하는 API만을 가지고 만들어진 맵 서비스를 제공하는 사이트들의 목록이다.
다음은 필자가 직접 만들어본 간단한 맵 서비스다. 이 지도는 필자의 회사의 위치와 자주 다니는 오락실, 서점들에 대한 정보를 포함하고 있다. 구글맵 튜토리얼을 한시간 가량 보고나서 이것 저것 짜집기로 20분만에 만든 서비스다.

일반적으로 국내포탈은 모든 서비스를 자신의 도메인영역에서 소비하도록 유도하고 있다. 반면 구글은 위에서 보는바와 같이 약간의 프로그래밍 능력과 아이디어와 의지를 가지고 있다면 누구든지, 어디에서든지 서비스를 개발할 수 있도록 하는 개방정책을 유지하고 있다. 이것은 매우 큰 차이라고 생각한다.

맵 서비스도 결국은 검색과 연계된 광고를 통해서 수익을 얻는 형식으로 가게 될거라고 생각되는데, 구글은 개방적인 정책을 유지함으로써, 국내는 물론 국외를 포함하는 엄청나게 다양한 사이트에서 다양한 맵 서비스를 할 수 있게 될 것이다. 구글이 이러한 서비스를 다 개발할 필요는 물론 없다. 구글은 API와 맵 리소스를 제공할 뿐이고, 실제 서비스는 유저들이 만들어가게 된다. 구글은 여기에 특정지역에 대한 맵이 뜨면, 그 지역에 해당되는 광고가 출력되도록만 하면 되는 것이다.

자신의 영역에서만 서비스를 가지고 가는 폐쇄적인 정책과 개방적인 정책 어느게 유리할지는 말할 필요도 없다고 생각된다 - 물론 유리한 정책이라고 해서 시장에서 반드시 성공하리라는 법은 없지만 -. 맵시장은 매우 큰 시장이 될거라고 생각되며 이런 저런 이유로 해서 국내 포탈들도 API를 공개하고 적극적으로 개발자를 끌어들일려고 노력 하고 있다. 국내 포탈은 여기에서 한가지 고민을 더 해야 할 거라고 생각된다. 구글과 같이 서비스까지 완전히 개방된 형식으로 갈건지 아니면, 지금까지 그래왔던 것처럼 자신들이 제어할 수 있는 영역내에서 서비스를 할 건지 결정해야 할 것이다.

혹시 구글 맵 API를 통한 서비스 개발에 관심이 있다면, 아래의 사이트를 방문해 보길 바란다.

2006/11/03

원문 : http://www.joinc.co.kr/modules/moniwiki/wiki.php/Site/Google/Service/GoogleMapAPI

1 구글의 개발자 포용 정책

구글은 다양한 개발자를 자신의 영역으로 끌어들이기 위한 개방정책을 사용한다. 그래서 대부분의 서비스들이 서비스를 제어할 수 있는 API를 공개적으로 제공하고 있다. 개발자는 이 API를 이용해서 구글이 선보인 서비스를 단순히 둘러보는 정도에 그치지 않고, 다양한 응용을 시도해볼 수 있다. 구글 MAP같은 경우 구글에서 서비스를 만들어내기도 전에, 구글이 제공한 API를 이용해서 자신들만의 독특한 서비스를 만들어낸 사용자들이 있다. http://HousingMaps.com 의 경우 미국 주요도시의 집값 정보를 보여주며, http://ChicagoCrime.org 는 도시내의 범죄와 범행위치를 검색하는 서비스를 제공하고 있다.

자신의 제품을 사용하거나 테스트해줄 많은 개발자들을 확보하는건 소프트웨어 회사가 성장하기 위한 가장 중요한 동력원임은 말할필요도 없을 것이다. 기존에도 개발자를 자신의 영역으로 끌어들이기 위한 노력을 해왔던건 사실이지만, 많은 제한을 둔 폐쇄적인 형태로 이루어졌었다. 구글은 정보를 완전히 공개하고 있으며, 많은 우호적인 개발자 세력을 만들어냈다. 이들 개발자는 구글매니아로 불리우는 중요 고객이기도 하다. 최근에는 국내 대형포탈들도 이러한 공개 개발자 포용정책을 펴나가는 추세다.

2 구글 Map API

구글 Map은 Ajax기 술을 사용하는 구글의 대표적인 서비스들 중 하나이다. 구글은 단순히 서비스를 제공하는데 그치지 않고 개발자의 참여를 끌어들이기 위해 API를 공개하고 있다. 구글 Map API를 이용하면 자신의 사이트에 구글 Map을 붙이고, 테스트하면서 새로운 응용을 만들 수 있다. Map API를 사용하기 위해서는 Map Key를 받아야 하는데, http://www.google.com/apis/maps 를 방문해서 Map을 사용할 URL만 명시해주면 바로 Key를 받을 수 있다. 그다음 생성된 코드를 가져다 붙이기만 하면 자신의 사이트에서 바로 구글 Map을 붙일 수 있다.

gmap.png

Map Key는 구글 maps 자바스크립트를 불러올때 key에 명시하면 된다.




3 구글 MAP API 분석

구글 MAP API는 JavaScript로 제어된다. 여기에서는 완전한 형태의 HTML 파일을 보여주지는 않을 것이다. 완전한 HTML 페이지를 만드는건 Map Key를 생성할 때 만들어지는 HTML 코드를 이해하는 것만으로 충분할 것이다.

3.1 기본

구글 Map을 불러오기 위한 가장 기본이 되는코드다. 서울주변을 보여준다.
var map = new GMap2(document.getElementById("map"));
map.setCenter(new GLatLng(36.615527631349245, 127.353515625), 4);

setCenter을 이용해서 보여줄 위치를 지정한다. 첫번째 인자는 좌표를 지정하기 위해서 사용한다. 두번째 인자는 지도의 해상도를 결정하기 위해서 사용한다. 숫자가 클 수록 더 자세한 결과를 보여준다.
[http]simple.html 예제

3.2 Map에서의 이동

다음은 맵에서 중심을 이동하는 예제다. panTo 메서드를 이용하면 해당 중심으로 지도를 부드럽게 이동시킨다. 길찾기등의 기능구현에 유용하게 사용할 수 있을 거 같다.
var map = new GMap2(document.getElementById("map"));
map.setCenter(new GLatLng(36.615527631349245, 127.353515625), 4);
window.setTimeout(function() {
map.panTo(new GLatLng(42.615527631349245, 128.353515625));
}, 2000);

[http]animate.html 예제

3.3 Control 버튼 추가하기

맵을 확대기시커나 모드를 바꾸거나 하는등의 제어를 위한 컨트롤 버튼을 추가한다. 참고로 구글 맵은 , 위성, 합성의 3가지 모드를 제공한다.
var map = new GMap2(document.getElementById("map"));
map.addControl(new GSmallMapControl());
map.addControl(new GMapTypeControl());
map.setCenter(new GLatLng(36.615527631349245, 127.353515625), 4);

[http]control.html 예제

3.4 Event Listener

event listener는 GEvent.addListener를 호출해서 생성한다. 이것은 맵에서 발생하는 이벤트를 알려준다. 아래의 예제에서 맵을 움직일 경우 변경된 좌표가 출력되는걸 확인할 수 있을 것이다.
var map = new GMap2(document.getElementById("map"));
GEvent.addListener(map, "moveend", function() {
var center = map.getCenter();
document.getElementById("message").innerHTML = center.toString();
});
map.addControl(new GSmallMapControl());
map.addControl(new GMapTypeControl());
map.setCenter(new GLatLng(36.615527631349245, 127.353515625), 4);

[http]event.html 예제

3.5 정보창 열기

openInfoWindow를 이용하면 원하는 지역에 DOM정보를 출력할 수 있다. 다음은 맵중앙에 저는 여기에 살아요메시지를 출력하는 코드다.
map.setCenter(new GLatLng(36.615527631349245, 127.353515625), 4);
map.openInfoWindow(map.getCenter(),
document.createTextNode("저는 여기에 살아요"));

[http]infowindow.html 예제

3.6 맵에 표시하기

이번 예제는 overlay기능을 이용해서 지도에 랜덤하게 10개의 마크를 표시한다. 마크에 사용되는 이미지는 기본 이미지이며, 사용자 정의 아이콘을 만들 수도 있다. 우리나라는 아직 상세지도가 제공되지 않은 관계로 일본의 동경시를 기준으로 예제를 만들었다.
map.setCenter(new GLatLng(35.76873101871279, 139.5413875579834), 12);

var bounds = map.getBounds();
var southWest = bounds.getSouthWest();
var northEast = bounds.getNorthEast();
var lngSpan = northEast.lng() - southWest.lng();
var latSpan = northEast.lat() - southWest.lat();

// 랜덤 포인트를 만들고 각각의 포인트에 마킹을 한다.
for (var i = 0; i < 10; i++) {
var point = new GLatLng(southWest.lat() + latSpan * Math.random(),
southWest.lng() + lngSpan * Math.random());
map.addOverlay(new GMarker(point));
}
// 랜덤 포인트를 만들고 이것을 연결한다.
var points = [];
for (var i = 0; i < 5; i++) {
points.push(new GLatLng(southWest.lat() + latSpan * Math.random(),
southWest.lng() + lngSpan * Math.random()));
}
points.sort(function(p1, p2) {
return p1.lng() - p2.lng();
});
map.addOverlay(new GPolyline(points));

[http]overlay.html 예제

3.7 클릭 이벤트 제어

맵에 클릭을 할경우 이벤트를 받아서 마킹을 하는 예제다. 앞서 배웠던 addListenr메서드를 이용해서 click 이벤트를 기다리고, 클릭이 발생하면 addOverlay메서드를 이용해서 마킹을 한다.
map.addControl(new GSmallMapControl());
map.addControl(new GMapTypeControl());
map.setCenter(new GLatLng(35.76873101871279, 139.5413875579834), 12);
GEvent.addListener(map, "click", function(marker, point)
{
if (marker)
{
map.removeOverlay(marker);
} else {
map.addOverlay(new GMarker(point));
}
});

[http]click.html 예제

3.8 마커에 정보 창 출력하기

10개의 마커를 랜덤하게 표시하고, 마커를 클릭하면 클릭이벤트에 대한 Listener가 작동하도록 해보자. Listener 함수는 openInfoWindowHtml메서드를 이용해서 정보창을 출력한다.
var map = new GMap2(document.getElementById("map"));
map.addControl(new GSmallMapControl());
map.addControl(new GMapTypeControl());
map.setCenter(new GLatLng(35.76873101871279, 139.5413875579834), 12);
function createMarker(point, number)
{
var marker = new GMarker(point);
GEvent.addListener(marker, "click", function()
{
marker.openInfoWindowHtml("Marker #" + number + "");
});
return marker;
}

var bounds = map.getBounds();
var southWest = bounds.getSouthWest();
var northEast = bounds.getNorthEast();
var lngSpan = northEast.lng() - southWest.lng();
var latSpan = northEast.lat() - southWest.lat();
for (var i = 0; i < 10; i++)
{
var point = new GLatLng(southWest.lat() + latSpan * Math.random(),
southWest.lng() + lngSpan * Math.random());
map.addOverlay(createMarker(point, i + 1));
}

[http]markerinfo.html 예제