블로그를 운영하시는 분들 중에 자신이 평균적으로 몇개나 글을 올리는지 정확히 계산하고 계시는 분들은 없으실 겁니다. 지금이라도 전체 글을 세어보시고 기간으로 나누어 보시면 나오겠지만 이런 방법도 있습니다.

구글리더를 쓰시는 분들은 아실찌 모르겠지만 구글리더에 보시면 새로운 피드를 검색하는 기능이 있습니다.

"구독추가하기" 버튼 옆에 있는 "찾아보기"를 누르시고 찾아보기 탭을 누르시면 밑에 키워드로 검색할 수 있는 창이 나타납니다. 여기에 블로그 제목 또는 키워드를 넣어 보세요.

그럼 검색창에 결과가 나타나는데 여기에 주당 몇개의 글을 작성하는지 통계가 나옵니다. ^^


제 경우 주 당 게시물 수가 6.3개 라고 나옵니다. 구글이 수집하는 글의 갯수를 보여주는 것입니다만, 구글봇은 꽤 부지런한 편이죠. ^^
글을 자주 쓰시는 분들은 비교적 정확하게 나옵니다. 하지만 블로그를 한참 비워두셨거나 하신 분들은 구글봇이 수집을 하기 시작한 시점부터 평균을 내면 너무 적게 나올찌도 모르겠군요. 아마도 최근 수집결과만 보겠죠.

지금 확인해 보세요~ 나름 느낌이 신선합니다. ^^

구글에게 MapReduce가 없었다면 현재의 구글은 없었을 찌도 모릅니다. 구글이 대단한 것은 세계에서 가장 많다고 자부할 수 있는 그 방대한 데이터를 유지하고 있는 능력 인 것 같습니다. 이 대단한 능력을 가능하게 하는 것은 바로 구글의 MapReduce가 있기 때문이죠.

구글의 MapReduce는 대용량 병렬처리를 가능하게 합니다. 엄청난 크기의 데이터를 짧은 시간안에 슈퍼컴퓨터가 없어도 처리가 가능 합니다. 하지만 MapReduce도 만능은 아니라서 여기에는 몇가지 조건이 붙습니다.


대표적으로 MapReduce는 key/value pair로 표시할 수 있는 데이터를 병렬처리 할 수 있습니다. key를 표시할 수 없는 데이터는 병렬처리로 나눌수 있는 기준이 없기 때문에 안됩니다. 그리고 batch 형태의 작업만 처리가 가능 합니다. 즉 하나의 작업에 시작과 끝이 존재하여야 나누어서 처리 할 수 있습니다.


MapReduce를 간단히 이해하여 보면 key 형식으로 표현될 수 있는 많은 양의 data 집합을 MapReduce Application이 정한 적당한 기준으로 key를 나누어서 처리한 다음 역시 MapReduce Application이 정한 적당한 기준으로 결과값을 나누어서 모으는 처리방법이 되겠습니다.



구글의 MapReduce를 실제로 사용해 볼 수는 없습니다. 하지만 고맙게도 구글의 논문을 통해서 MapReduce와 같은 동작을 할 수 있는 Hadoop이 오픈소스로 만들어 졌습니다. 현재는 Yahoo의 지원을 받으며 Apache Project로 안정적으로 진행되고 있습니다. Hadoop을 이용하면 구글의 MapReduce를 사용할 수 있습니다.

참고자료

지금 구글에서 '오마이뉴스'를 검색해 보면 아래와 같은 화면을 볼 수 있습니다.
구글 도움말의 일부 검색결과에 '이 사이트는 사용자의 컴퓨터에 손상을 입힐 수 있습니다.'라는 메시지가 나타나는 이유는 무엇인가요? 항목을 찾아보면 이 메세지가 악성소프트웨어(멀웨어)를 배포하는 사이트를 나타낸다는 것을 알 수 있습니다.

자세한 내용은 StopBadware.org(영어)를 참조하라고 되어 있는데, 여기는 사람들에게 악성코드의 경각심을 일깨워주는 각종 사례와 자료를 제공하고 악성코드의 정보에 대하여 알려주는 비영리단체에서 운영하는 사이트 입니다. (이 단체의 주요 스폰서로는 Google, Lenovo, PayPal, VeriSign 등이 있습니다)


구글에서 멀웨어 유포지로 찾아진 사이트는 먼저 구글검색결과에 표시되고, 그 다음에 StopBadware.org에 제공되어 사람들에게 알려지게 되는 순서인 것 같습니다.

이렇게 구글에서 이런 메세지를 보게 되면 사람들은 이렇게 생각 합니다.


내용은 보통 "구글한테 찍힌거 아니냐", "조선닷컴이 유해사이트라니 뉴스감이다". 이런 내용입니다.

그러면 보통 그 밑에 좀 아신다는 분들이 이런 댓글들을 달게 됩니다.
주로 "뉴스감 아니다", "오바다", "구글은 조작하고 그런거 안한다" 이런 내용입니다.

구글은 일반적으로 수작업인력이 거의 없다고 알려져 있고, 전세계에 서비스하는 데이터양을 고려 한다면, 저기에 표시된 경고문구는 제 생각에도 자동으로 분류된 결과라고 생각 하는 것이 일반적으로 타당한 것 같습니다. 그러므로 댓글에 달려 있는대로 "오바" 또는 "잘못된거나 부정확한 정보"라고 할 수도 있겠습니다.

그럼 구글은 사용자가 이렇게 "잘못 받아들 일 수 있는 경고문구"를 왜 오마이뉴스나 조선닷컴 같은 멀쩡한 데다가 보여주는 것일까요?

조선닷컴이 "경고문구"가 달린 시점은 조선닷컴이 몇번 크랙킹으로 당한 이후였습니다. 오마이뉴스도 몇번 크랙킹을 당한적이 있기 때문에 "경고문구"가 달린 것 같습니다. 일반적으로 최근까지 신문사닷컴 사이트들은 철두철미한 보안을 중요시 하는 문화는 아니였던 것 같습니다. 몇번의 크랙킹으로 자신들도 모르게 멀웨어 유포지로 전락한 사건이 몇번 있었거든요. 이렇게 자신들이 의도하지 않은 사건으로 멀웨어 유포지로 걸리게 되면, 구글은 그 유명한 "자신들만의 기준"을 잣대로 유해사이트 분류를 자동으로 해 버리는 것입니다. 한동안 유해사이트 문구를 계속 달고 있게 되는 것입니다. 멀웨어 배포지로 StopBadware.org 에 오르게 되면 한동안 신뢰를 회복하기 힘들어 집니다. 그러니 서버보안에 주의해야 하겠죠.

이런 상황이라면 구글이 멀웨어 배포지로 찍어도 할말이 없겠죠. 오마이뉴스 사이트가 멀쩡해 보이지만 사실 멀쩡해 보이기만 하는 사이트 일 수도 있다는 것입니다. (오마이뉴스 사이트 들어갔더니 해킹당해서 이상한 악성코드가 설치 된다면 정말 황당 하겠죠) 하지만 보통은 사이트 측에서 이미 조치를 취한 상황인데 구글결과에서는 반영이 느린 경우가 대부분 일 것 같습니다.

느닷없이 결론내고 끝내버리려니 무지 뻘쭘 합니다만, 사실 하고 싶은 이야기는 이거 였습니다.
다음부터 구글검색에서 위와 같은 메세지를 보시면 "쯧쯧 또 걸렸네 또 걸렸어 잘 좀 하지." 하고 혀좀 차 주시고 넘어가 주시면 되겠습니다. 네

영국 런던, 4cm 급 항공사진 서비스 개시

런던지역에 4cm 급 항공사진을 제공하는 서비스를 시작한다는 뉴스를 접했습니다. 이런 고해상도 항공사진이 제공되면 길가다가 쓰레기라도 버렸다간 언제 인터넷에서 다른사람이 보고 욕하고 있을지 모르겠군요.

구글맵에서 제공하는 우리나라 위성사진이 60cm급이라고 하던데, 예전에 복무했던 부대 근처를 찾아 보았는데 참 적나라하게 찍혀 있더랍니다. 우리나라 곳곳이 다른나라의 위성에 이렇게 자세히 찍혀 있다는게 좋은건지 나쁜건지.. 부담스럽긴 하네요.


View Larger Map


미래에는 기술발달로 (드라마 '24'에서 처럼) 위성으로 사람들을 실시간 감시 할 수 있는날이 올찌도 모르겠습니다. ^^

해외 유명 블로그 TechCrunch 에 구글 관련 내용이 올라왔습니다. 이 소식을 발빠르게 전해 주시는 여러 블로거님들 덕분에 금방 소식을 접하게 되었습니다. (참 좋은 세상입니다. ^^)

Google Processing 20,000 Terabytes A Day, And Growing (TechCrunch)
구글, 하루에 20000 테라바이트(TB)의 자료를 처리한다고? (학주니닷컴)
구글이 20 petabyte의 데이터를 얼마만에 처리할까?

2007.11.26 (그제) 읽은 글
차니님 - 네이버, 정보 유통의 숙명은 미디어?
오마이뉴스 - 구글어스 '국가안보 위협' 논란... 한국과는 모자이크 처리 두고 협상중

2007.11.27 (어재) 읽은 글
네이버뉴스 - 다음, 네이버 베끼기 논란…제2의 ‘카페’ 명칭 분쟁으로 확산? - 해럴드 생생뉴스
문플라워님 - 한국 정부가 만만한 구글??
후글님 - 구글어스 논란에 대한 구글의 공식 입장을 알려드립니다

2007.11.28 (오늘) 읽은 글
문플라워님 - 구글과 오마이뉴스의 진실게임. 승자는?
차니님 - 네이버 블로그 시즌 2, 해 넘어가나?
차니님 - 구글의 어설픈 지도 서비스 협상법
(차니님은 다음(daum.net)에서 에반젤리스트(evangelist)라는 직책으로 계신걸로 기억하고 있었습니다만, 2007년 부터 DNA Lab에서 오픈 API 개발 및 외부 개발자 지원 업무를 하고 계신다고 합니다. 오늘 새로 알았음. ^^)

오마이뉴스의 기사를 시작으로 블로고 스피어에서 논란이 일고 있습니다. 저도 이 부분의 진실이 상당히 궁금 하긴 합니다만.. 기대와는 다르게 흐지부지 끝나 버리지 않을까요?

그리고 나름 정점에 서있는 네이버의 향후 걸음걸이가 어디로 갈찌 관심을 가지고 있습니다. 정점을 치고 바닥으로 서서히 침몰할찌.. 지식인 이후에 다시한번 고공 비행을 공고히 할 무엇을 찾을 수 있을찌.. 사뭇 궁금 합니다. ^^

브라우져를 사용하면서 간단하게 주소창에다가 키워드치는 방식으로  사용하시는 분들이 의외로 많습니다.
주로 윈도우에서 IE 사용자 분들 중에 많이 보았습니다만.. (넷피아에서는 이걸로 키워드 장사도 했었죠)

제 Firefox 에서 주소창에 키워드를 치면 기본으로 야후 검색 결과가 보였습니다. 야후 검색은 별로 사용하지 않습니다만, 어떻게 바꾸는지 몰라서 그동안 그냥 두었었습니다. 근데 Change Firefox’s Default Search Method 글을 보고 방법을 발견 해서 오늘 바꾸었습니다.
주소창에 about:config 를 입력 하시면 그림과 같이 변수값을 조정 할 수 있는 페이지가 나타납니다.
여기서 keword.url 값을 찾으셔서 이 값을 http://www.google.com/search?ie=UTF-8&sourceid=navclient&gfns=1&q= 값으로 바꾸면 됩니다.

주소창에 "다음" 이나 "네이버"를 입력 하면 구글검색을 통해서 바로 해당 사이트로 이동하게 됩니다.
바로가기성 사이트가 없을 경우는 구글 검색 결과가 표시되게 됩니다. ^^

The Google Legacy - How Google's Internet Search is Transforming Application Software
라는 책이 있습니다. 구글의 구조에 (기술적으로) 관심이 많으시다면 한번 읽어 볼 만한 책 인 것 같습니다.
사실 저도 아직 못 읽어 본 책이기 때문에 이 책에 대해서 쓸만한 말은 없습니다. ㅜ.ㅜ
다만 어떤 분이 읽고 계시던데 좋아 보여서..


뱀다리:
얼마전에 구글에 관한 자료를 찾아 보다가 구글 검색 엔진의 구조를 설명해 놓은 글이 있는데 비교적 최근날짜로 되어 있었습니다. 그래서 오옷~ 최신 자료 인가? 하면서 살펴 보았습니다.

처음 찾은 자료는 Google Search Engine 해부 - 1 여기 였는데 출처가 아래로 되어 있었습니다.

특집 2부 성공의 원천, 탄탄한 기술 인프라 대해부 <구글> 여기에는 출처가 없어서 이게 원본인가 싶었는데 저자의 이름이 블로그 주인장과 다른 것 같아서 검색을 해봤습니다. (알고 봤더니 이 글은 퍼오고서 출처표기를 싹 지운 불펌 이였습니다.)

그래서 찾은 글이 아래의 글 구글 - 기술 인프라 대해부 여기에는 출처가 다시 아래로 명기되어 있었습니다.

All about google! : 특집 2부 성공의 원천, 탄탄한 기술 인프라 대해부 그래서 다시 찾아가 봤더니 그 아래 출처 표기가 하나 더 있었습니다. 바로 2005년 10월 마소가 원문 출처 였습니다.

이 자료는 보시다 시피 2005년 10월 자료 인데, 글에서 나오는 구글 검색엔진 구조에 관한 그림은 1997년 발표된 논문을 기반으로 하고 있습니다. 현재 사용되는 구글 검색 엔진의 구조는 초기 것 과 많이 다를 것이라고 예상되는데 이유는 97년 논문에 나와 있는 그 구조는 동적 색인이나 동적 크롤에 관한 구조가 없기 때문입니다. (현재의 시스템은 당연히 동적인 구조로 되어 있으리라 예상됩니다.) 그리고 구글은 현재 웹검색에 사용되는 시스템과 블로그 검색에 사용되는 시스템이 따로 운영되고, Gmail 검색은 다른 엔진이 사용된다고 합니다.

The name "Google" originated from a misspelling of "googol", which refers to 10¹⁰⁰ (the number represented by a 1 followed by one-hundred zeros).

"Google"이라는 이름은 "googol"을 잘못 표기한데서 유래 한다고 합니다.  1 googol 은 '1'에 '0'이 100개 붙은 숫자 입니다.

1 googol

= 10¹⁰⁰

= 10,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000

구글 본사의 이름은 "Googleplex" 입니다.  그리고 "Googolplex"는 10의 googol승을 나타냅니다.

10^googol = 10¹⁰¹⁰⁰

즉 '1'에 '0'이 'googol'개 붙은 숫자 입니다. "Google"의 목표가 전세계의 모든 데이터를 담는 것이라고 하던데, 숫자로 표현한다면 딱 알맞은 이름 인 것 같습니다. :-)

참고자료:
Koller, David. "Origin of the name, "Google." Stanford University. January, 2004.
Hanley, Rachael. "From Googol to Google: Co-founder returns." The Stanford Daily. February 12, 2003. Retrieved on July 14, 2006.

안드로이드 애플리케이션 개발에 미화1,000만 달러(약 93억원) 상금 내걸어

구글 코리아 블로그에 가 보면. 구글이 안드로이드 애플리케이션의 개발을 독려하기 위해 개발자들을 대상으로 총 1천만달러의 현상금을 내걸었다는 내용이 전해지고 있다. 더구나 개발한 결과물은 개발자의 소유로 인정 한다고 한다. (전세계 대상으로 개최되는 소프트웨어 경진대회에서 1등먹은 프로그램 이라면 아마 인지도 면에서만 봐도 비싼 값에 팔리거나, 광고만 붙여도 평생 수익을 가져다 줄 수 있으리라)

아래는 구글 블로그에서 안드로이드 개발자 경진대회 진행 일정을 발췌.

안드로이드 개발자 경진대회는 각각 I 차 대회와 II차 대회로 진행되며, 총 1,000만 달러 상금은 두 차수에 각각 균등하게 나뉘어 수여됩니다.

안 드로이드 개발자 1차 경진대회 공모 접수는 2008년 1월 2일부터 2008년 3월 3일까지 진행되며, 총 예선 접수작 중 50 개의 당선작이 3월 말에 발표됩니다. 이들 선정된 50명의 당선작 개발자 모두에게는 향후 추가 개발을 위해 각각 25,000달러의 현금이 상금으로 수여됩니다.

예선에서 당선된 개발자 50명은 본선에 진출할 자격을 얻게 되며 본선 공모는 2008년 5월 1일까지 접수해야 합니다. 이들 본선 접수작 중 10명을 선정하여 이들 모두에게 각각 275,000달러 상금을 수여하며, 또한 다른 10명을 선정하여 100,000달러 상금을 각각 수여합니다. 이들 본선 당선작 중 최우수 당선작은 2008년 5월 말에 발표될 예정입니다. 안드로이드 개발자 2차 경진대회는 플랫폼 기반의 첫 휴대폰이 2008년 하반기에 출시된 후 진행됩니다.

가장 인상 적인 부분.

해당 애플리케이션에 대한 지적 소유권과 기타 모든 권리는 개발자에게 귀속됩니다

아~ 이대로 두달간 무급휴가를 쓰고 안드로이드 어플리케이션 만들러 잠적해 버리고 싶다!!!!

New Feature Suggestions for the Google Search Appliance

위의 페이지를 찾아가 보면 구글검색에 새로 추가해 달라고 건의하는 많은 사항을 많이 볼 수 있다.

재미 있는 것들이 여러가지 많이 있지만 내 눈에 딲 띄인 것은 맨 윗부분에 있었던 건의사항이다.

Allow wildcards when searching.

•  

• Ability to use * wildcards when searching, currently there is no way to do this. This would enormous improve the GSA.
• 
  Allow regex when searching, to find for instance specific content of tag

구글 검색 창에서 와일드카드 (즉 '*' 문자)를 사용할 수 있게 해 달라는 말이다. 그래서 해봤다. 구글 검색 창에서 와일드카드를 사용해서 검색하면 어떻게 될까?

그림을 보시면 "우주에서 만리장성을 볼 수 없었다" 라는 추천 검색어가 보인다. 그럼 "우주에서 * 볼 수 없었다" 라고 치면 여러가지 우주에서 볼수 없었던 검색어 들이 추천되게 해 달라는 말인 것 같다.

또는 "검색*블로그" 라고 입력 하면 '검색엔진블로그', '검색최적화블로그', '검색어블로그'와 같은 검색어를 대상으로 검색해서 결과를 보여달라는 것도 포함 될 것 같다. 실제로 저런 쿼리를 입력해 보면 '검색' 과 '블로그'로 검색된 결과를 보여준다. (없는 기능이니까 추가해 달라고 건의 한거겠지만..)

기존의 검색 방식과 와일드카드를 사용하는 검색 방식은 아래 두가지의 흐름 일 것 같다.

• 사용자가 검색어를 완성->검색엔진에서 결과반환
• 사용자가 검색어 입력 -> 검색어를 검색 또는 완료하는 과정 -> 검색엔진에서 결과반환

전자의 방식에서 후자의 방식으로 약간 흐름이 바뀌는 것이다. (여기서 후자의 앞의 두 단계는 검색어 추천과 같이 실시간으로 이루어져야 할 것 같다)

먼저 검색 쿼리를 만드는 작업이 추가로 들어가게 된다는 것인데, 뭐 만든다고 한다면 어찌되던간에 만들수는 있을테고 안될리야 없겠지만, 과연 저것이 성능이 제대로 날까 모르겠다. 그리고 그만큼 희생한 만큼 쓸모가 있을까도 모르겠다. 하나 확실한 것은 구글이 한다면... 그리고 저 기능이 히트 친다면 다른데서도 따라 할 것이다. 분명히.. ^^;

뭐 그렇게 중요한 기능인지 모르겠지만 '1+1' 이라고 입력 하면 '2'라고 가르쳐 주는 계산기 기능도 들어가 있는 것을 보면 혹시 이 기능이 들어갈 찌도 모르겠다.

이 글은 스프링노트에서 작성되었습니다.

현재 구글에서 사용하고 있는 검색엔진의 구조에 대해서 공개되어 있는 정보는 별로 없지만 몇가지 논문을 통해서 공개된 내용이 약간 있다고 합니다.

대부분은 웹검색 시스템의 구조에 관한 설명이고, 블로그 검색이나, Gmail 검색에 사용되는 시스템도 아마 비슷하지 않을까.. 합니다만.. ^^ (구글은 반영속도가 아주 느려도 되는 웹검색 시스템과, 반영속도가 빨라야 하는 블로그 검색을 다른 시스템으로 돌린다고 합니다. GMail 처럼 실시간 반영되어야 하는 검색의 경우 아예 웹검색 엔진과 다른 엔진을 사용한다고 합니다.)

 
여기에서 잠깐, 간단히 살펴 볼 구글 검색엔진 이라는 것은.. 구글의 창시자 인 "Sergey Brin" 과 "Lawrence Page" 가 1997년 인가 1998년에 "Stanford University" 에 있을때 쓴 "The Anatomy of a Large-Scale Hypertextual Web Search Engine" 이라는 논문의 내용을 바탕으로 합니다. 97년 당시의 내용을 바탕으로 하기 때문에 현재의 구조와는 많이 다를거라고 생각 됩니다만, 기본 구조를 살짝 살펴 볼 수 있다는데 의의가 있는 것 같습니다. ^^ 여기에는 "2.1 Page Rank"의 (간단한 개념적 수학공식) 소개나 "4.1 Google Architecture Overview"와 같은 내용이 들어 있습니다.

Figure 1. High Level Google Architecture

설계된 시스템의 목표는 초당 100~1000개의 쿼리를 처리하는 것 이였으며 (1.2절)

논문에서는 이 시스템으로 2400만 건의 페이지를 모아서, 2억5천900만개 이상의 Anchor를 인덱스 하였다고 합니다. (2.2절)

 
그림1의 개괄적인 구조로 보았을때 이때의 시스템은 크게 2개 이상의 스텝으로 나뉘어 동작하여야 하기 때문에 배치작업으로 이루어 졌을 것 같습니다.

그리고 일반적인 Crawler, Indexer, Searcher 와 같은 구조들이 보이고, Nutch 구조와 비교해 보시면 Crawler -> Indexer -> Searcher 로 가는 구조도 거의 똑같아 보입니다. 여기서 crawl 된 페이지에서 추출된 link 를 다시 crawler로 보낼때 DocIndex 부분에서 보낸 다는 것이 제 눈에는 약간 신기해 보였습니다. ^^

이 글은 얼마전에 주워들은 내용을 복습하는 의미에서 논문을 다시한번 살펴보고 정리하는 중에 올리는 글입니다. ^^

참고문헌:
The Anatomy of a Search Engine

2007/11/01 - 공개 검색엔진 Nutch의 구조

이 글은 스프링노트에서 작성되었습니다.

Nutch는 자바로 구현된 오픈소스 검색엔진 입니다. Lucene이 Indexer 와 Searcher로 구성되어 있고, Nutch는 Lucene에 없는 웹검색에 필요한 모든 기본요소를 전부 갖추어서 웹검색 용으로 확장 한 것이라고 보면 될 것 같습니다. 그래서 Nutch는 Lucene 기반의 공개 웹검색 엔진입니다. Nutch는 많은 부분 구글 검색 엔진 구조를 목표로 하고 있습니다.

전체적인 구조는 일반적인 웹검색 시스템의 구조와 비슷한 것 같습니다.

Nutch의 구조는 그림과 같은데, 이걸 지금 제가 알고 있는 웹검색 시스템의 구조로 이해하기 위해서 대충 나누어 보면 아래처럼 나눌 수 있을 것 같습니다.

1. Crawler
   • Nutch는 웹데이터 들을 효과적으로 가져올 수 있는 fetcher 들을 가지고 있습니다. 이를 통해서 목표로 하는 URL 들의 데이터를 수집하고, 이 작업은 목표로 하는 깊이까지 도착하면 멈춥니다.
2. Repository
   • 수집된 웹 데이터 들은 Repository에 저장됩니다. Nutch에서는 특별히 Repository 라는 명칭을 사용하지는 않지만, WebDB와 Segment들이 여기에 해당 한다고 볼 수 있을 것 같습니다.
3. Indexer
   • 수집된 데이터는 Lucene에서 사용 가능한 Index 형식으로 구성되어야 합니다.
4. Searcher
   • 구성된 Index는 Lucene Searcher 에서 사용됩니다.

몇일 뒤에 어떤 고마운 분이 Nutch의 구조나 특징에 대하여 조사 한것을 설명 해 주실텐데 Nutch가 어떻게 생긴건지 전혀 몰라서 간단히 살펴 보았습니다. 이제 어느정도 설명을 들을 만한 최소한의 기본 준비는 한 것 같으니 이제 기다려야 겠군요. ^^

참고문헌:

Introduction to Nutch, Part 1: Crawling by Tom White 2006/01/10 번역본

Introduction to Nutch, Part 2: Searching by Tom White 2006/02/16

Nutch: Open-Source Web Search Software by Doug Cutting(doug@nutch.org) 2004/11/26

Open Source Search by Doug Cutting(cutting@apache.org) 2005/12/05

이 글은 스프링노트에서 작성되었습니다.

구글에서 네이버를 검색해 보면 다음과 같은 결과를 볼 수 있습니다.

www.naver.com 결과와 같이 네이버의 대표적인 내부 서비스 들의 링크가 같이 하위로 보여집니다.
얼핏 보면 네이버 상단의 메뉴에 해당하는 내용과 비슷하게 보입니다.

그럼 한국일보를 검색해 보면 어떤 결과가 나올까요?
한국일보 사이트가 검색되지만 하위에 보이는 링크들은 뉴스 기사가 그대로 보이는 것 같습니다.
조선일보 검색결과와는 사뭇 달라 보입니다.

이 기능은 최상위 페이지를 통해서 방문 할 수 있는 대표적인 "Internal Site Links" 를 같이 보여주는 기능인데, 최상위 검색 결과 하나에 대해서만 제공되는 기능입니다. (그럼 이 기능은 사용자가 입력한 검색어에 해당하는 사이트를 정확히 최상위 결과로 보여줄 수 있어야만 제대로 동작 하겠군요)

네이버에는 이 기능과 직접적으로 똑같은 기능은 없습니다만, 다만 "바로가기" 와 "컨텐츠 검색" (?) 기능이  비슷한  것을 제공 하는 것 같습니다. (네이버에서 "국민은행"을 검색 한 결과와 구글에서 검색한 결과를 비교해 보시면 되겠습니다) 약간 여담이지만 네이버에서는 이러한 기능을 전부 사람이 만들어서 제공한다는 것과 구글에서는 기게적으로 계산해서 제공한다는 점에서 검색결과가 얼마나 차이가 나는지 살펴 보는 것도 약간 재미 있습니다. ^^

이 기능에 대해서 좀 더 자세히 알고 싶으시다면 누가 분석해 놓으신 페이지가 있던데.. 거기를 참고 하시면 도움이 되실 듯 합니다. 대충.. "유명한 사이트에 대해서 사용자들이 자주 가는 링크들을  보여주는 기능" 정도 되는 것 같습니다.

이런 결과는 어떻게 제공 하는 것일까? 무슨 데이터를 기반으로, 어떻게 계산해서 어떤 방식으로 보여주는 것일까요? 나름 분석.. 또는 추측 해본 결과는 이렇습니다.

일단 먼저, 어떤 방식으로 보여주는 것인가는.. 확실 한 것 같습니다. 구글에서 유명한 사이트라고 판단(아마도 페이지 랭크가 기준 일까요?)되는 사이트에 한해서, 최상위결과로 나온 경우(질의에 따라 결과가 다르므로..)에 한해서, 상위 몇개의 내부링크를 보여주는 방식 인 것 같습니다.

그럼 어떤 데이터를 기반으로 이런 계산을 하는 것일까요? 사람들이 자주가는 링크라는 것을 판단 하는 방법에는 일단 다른 페이지에서 링크가 많이 걸려 있는 것을 보는 방법이 있습니다. 하지만 이런 방식으로는 "국민은행" 검색 결과를 설명 할 수 없을 것 같습니다. 국민은행 로그인 페이지를 링크를 많이 걸지는 않을 테니 까요.

국민은행 결과를 보시면 사람들이 국민은행 Top Page에서 실제로 그 다음으로 가장 많이 이동하리라고 생각되는 링크들이 나오는 것을 보실 수 있습니다. (예를 들면 "로그인" 페이지) 몇가지 구글 검색결과를 보고 추측 해보면 실제로 사람들이 이동한 URL 정보를 가지고 계산하는 것이 가장 근접해 보입니다. (실제로 사람들이 이동한 URL정보를 가지고 저런 기능을 구현해서 국민은행 같은 검색결과를 보면 구글 결과와 비슷한 결과가 나온다고 합니다.)

구글이 구글툴바를 이용해서 사람들이 이동한 URL 정보를 얻을 수 있다거나.. 브라우져 히스토리 정보를 얻을 수 있다면... 또는 유명한 사이트의 웹사이트 로그를 얻을 수 있다면.. 가능하겠습니다만.. 정확히 뭘 쓰는 지는 모르겠습니다. ^^

에혀 궁금한 것도 많다. 누가 이런건 이렇게 하면 된다. 라고 딱딱 집어주는 사람이 있으면 궁금증이 팍팍 해결 될텐데 말입니다. ^^