제가 이 바닥에 처음 발 담근 게 98년 말 이었고, 본격적으로 직장생활을 시작한 건 2000년도 초 부터 였는데요. 그 시절은 97년 이후 시작된 IMF의 위기의 끝에 선  "IT 버블"이 시작하는 때 였습니다.

그 당시 살아남은 기업들은 구조조정을 한다고 IT 시스템에 투자하고, 정부는 경기부양 한다고 IT예산을 늘렸습니다. IT가 돈이 된다고 하니까 돈 될 만한 회사에 투자하려고 하는 데가 많았고, 벤처들은 이런데서 투자를 받았습니다.

이렇게 돈이 모이는 곳에서 쉽게 눈에 띄는 방법은 "최신기술" 이라고 포장 하는 것이죠. 그 당시 최신언어 였던 자바는 이런 이유로 인기가 많았습니다. 벤처회사에서 너도나도 자바개발자를 구하려고 했는데, 97년에 처음 우리나라에 들어온 개발언어를 할 줄 아는 사람이 많을리가 없죠.

그래서 그 당시 가장 인기있는 개발자는 자바개발자 였습니다. 희귀했죠. 벤처들은 비교적 손쉽게 투자받은 돈으로 비싼연봉 줘가면서 자바개발자를 구했습니다. 심지어는 학원에서 3개월 동안 자바 공부하고 오면 작은 벤처회사에 취직 할 수 있었습니다. 주위에서는 자바개발자 1명당 5개의 일자리가 있다는 진짜인지 아닌지 모를 소문도 있었고요.

그 시절 제 주위의 공돌이들 분위기는 이랬습니다.

학교에서 자바 좀 배웠다(그리고 좀 쓸 줄 안다)는 학생들은 소프트웨어 벤처기업으로 우루루 몰려 갔습니다. 대기업에 가면 3년동안 아무것도 안하고 뒤치닥거리만 해야 한다는 소문도 있었고, 벤처는 작은회사지만 신입치고 연봉도 많이 받았고, 재미있는 프로젝트를 할 수 있고, 배울 것도 많다는 인식이 많았습니다. 거기다가 대박치면 때돈을 벌 수 있다는 인식이 가장 크게 작용 했고요. (IT바닥의 한국판 골드러쉬 라고 해야 하나요?) 학교성적은 좋지만 개발언어 같은 것은 잘 모르는 학생들은 벤처로 뛰어드는 친구들을 부러워 하며 대기업에 가기도 했고요. (상황은 곧 역전 되었지만 말입니다. ㅜ.ㅜ)

그렇게 그렇게 흘러가는 분위기 에서 저도 벤처로 들어오게 되었습니다.

잘나간다 하는 벤처회사들은 높은 연봉을 주면서 개발자 들을 모았습니다. 수 많은 벤처기업들이 주식시장에 상장해서 주가 고공행진을 벌였습니다. 그 당시 가장 좋은 회사는 직원들에게 스탁옵션을 주고, 우리사주를 살 수 있도록 배려하는 회사 였죠. 연봉이 적어도 스탁옵션으로 대박의 기회를 주는 회사를 더 높게 쳐주기도 했습니다. 그 당시 회사에서 빌려주는 돈으로 우리사주를 구입하는 사람들이 꽤 있었습니다. 회사는 스탁옵션이나 우리사주를 조건으로 개발자들이 일정기간 회사를 옮기지 않고, 주식을 팔지 못하도록 약속 받았습니다. (이 당시 직원들을 믿고 구두계약만 하는 회사들도 있었습니다) 단지 투자를 성공적으로 받았다는 이유로 전직원에게 100%의 보너스를 제공하는 경우도 있었습니다.

이 당시 작은 벤처기업 들은 젊고 열정이 가득하지만 경험은 없는 젊은이들로 가득 했습니다. 회사에 제대로 된 평가시스템 이나 평가기준은 없었지만, 대부분 열정적으로 일 했습니다. 저나 주위의 개발자 분들은 지금 얼마나 흥미롭고 재미있는 일을 할 수 있는가가 회사생활의 주된 관심이였던 것 같습니다.

이런 IT버블은 오래가지 못했죠. 수익구조가 탄탄하지 못하고 과도한 투자를 받았거나, 흥청망청 과도한 지출을 했던 기업들은 자금사정이 급속하게 악화 되었습니다. 안타깝게도 이 와중에 회사가 도산하는 과정에서 밀린 월급,퇴직금도 못받고, 직원들이 사비로 회사운영금을 보테다가 떼이는 둥 잊지못할 경험을 하신 분들도 주위에 많이 있습니다.

회사의 주가가 곤두박질 치기 시작하면서, 그나마 눈치빠른 분들은 회사와의 약속이고 뭐고 주식을 팔아서 한몫 챙기신 분들도 있었습니다만, 제가 아는 개발자 분들은 약속은 지켜야만 하는지 아시고 바닥이 어딘지 모르고 떨어지는 주식을 안타깝게 바라보면서, 우리사주 산다고 회사에서 빌린 부채 때문에 그만두지도 못하고, 연봉 계속 깍이면서도 계속 있어야 하는 귀한경험 하신 분들도 있습니다.

그때의 기억은 좋은기억도 많고 나쁜기억도 많습니다만, 저는 그나마 운이 좋았는지, 대부분 시간이 지나고 나면 웃을 수 있는 일 들 이었습니다. ^^

요즘 세상이 뒤숭숭 하여 다들 어렵다고 합니다. 그나마도 IT 업계에선 더 추운 한파가 휘몰아 치고 있다고 합니다. 이럴때 일수록 잘 버텨서 한 10년 정도 지나면 그때도 웃으며 추억할 수 있었으면 좋겠습니다. ^^

1. 인터넷으로 전송 하는 방법
   
   대충 그림과 같은 과정을 거쳐서 데이터를 보내게 될 것입니다. 이때 가장 문제가 되는 곳은 '국내망'이라고 써있는 부분일텐데, 기가비트 망을 연결한다고 쳐도 1페타바이트를 전송하는데 3달 이상 걸립니다.
   1G Bit/sec = 128MByte/sec = 7.5GB/min = 450GB/h = 10.55TB/day
   1petabytes는 약97일 정도 걸리면 전송 할 수 있겠습니다.
   
   
2. 위성통신으로 전송하는 방법
   
   위의 1번 방법에서 중간에 해저케이블 부분이 위성으로 바뀔뿐이므로 1번 방법보다 느리면 느렸지 빠르지는 않을 듯 합니다.
   
   
3. Johnathan의 글에서 처럼 sailboat로 보내는 방법
   
   
   
   이건 한달이면 갈려나? 아무래도 항공편보다 싸긴 할테지만 빠르지는 않을게 분명 합니다.
   
   
   
   
   
4. Fedex로 항공편으로 보내버리는 방법
   
   1TB HDD 1024개에 데이터를 담아서 Fedex로 보낸다면 며칠이면  서울로 도착할 듯 합니다. 물론 양쪽의 시스템이 동일한 장비에  핫스팟 기능을 가지는 구성을  해야 겠습니다. 1TB HDD를 1024개 구입하는 가격도 생각해 봐야 겠습니다. 아무튼  시간은 이게 제일 빠를 듯 합니다.
   

1998년 경에 쓰여진 Mirror, Mirror on the Web: A Study of Host Pairs with Replicated Content라는 논문을 읽어 보았다.

미러사이트는 네트웍 트래픽을 줄이기 위하여 다른 컴퓨터 서버를 복사해 놓은 웹사이트 또는 컴퓨터 파일서버를 말하는데, 중복페이지가 존재하는 것과 다르게 미러사이트는 원사이트의 정확한 복제품을 말한다.

보통 다운로드 사이트의 경우 트래픽을 분산 시키기 위하여 미러사이트 들을 사용하는데, 논문에서 다루고 있는 내용은 미러로 운영되는 웹사이트를 구분하기 위한 방법을 말한다.여기에는 kangcom.com 이나 wowbook.com 처럼 같은 내용으로 포워딩되는 경우도 포함 될 수 있다.

논문의 아이디어는 여러개의 URL의 Path 유사도를 계산해 봐서 Path가 거의 비슷한 Host 들은 미러사이트라고 판단하는 방법이다. 미러사이트는 정확한 복제품 이므로 Path 구조도 동일하게 된다. 논문에서는 아래와 그림과 같은 방법으로 레벨을 나누어서 실험해 보았다.

논문의 결과보다는 실제 내가 실험해 볼 수 있는 URL 집합에 어느정도 효과가 있을지가 더 궁금 했으므로, 테스트를 해 본 결과, 미러사이트를 판단하는 정확도는 비교적 높았으나, 발견해 내는 비율이 좋지 않았다. 이유는 아래와 같았다.

• URL 집합이 각각의 Host 별로 고르게 분포되지 않았다. 예를 들어 Host A 와 Host B는 미러사이트 이지만 Host A의 URL은 10개 Host B의 URL은 1000개가 존재 한다면 비교할 대상은 10개 밖에 안된다.
• 블로그 툴이나 쇼핑몰 툴로 일괄적으로 만들어진 사이트, 각 지방별 정부단체 사이트 등 Path 구조가 거의 동일하고, 컨텐츠 내용도 그림 몇개만 빼고 거의 비슷한 경우는 판단하기가 꽤 힘들다. (정확도를 떨어뜨리는 주요 이유) 이 경우 굉장히 많은 숫자의 Host에서 높은 빈도수로 나오는 몇몇 Path를 제외하면 정확도가 꽤 높아진다.

논문의 내용대로 약간 보정해서 적용하면 정확도는 꽤 괜찮아서, 쓸만한 것 같았다. 그러나 (Host별로 고르지 않은 URL 분포 때문에) 발견해 내는 비율이 떨어지는 문제를 보완하기 위해서, 다른 방법을 병행할 필요가 있는 것 같다.

참고문헌:

Mirror, Mirror on the Web: A Study of Host Pairs with Replicated Content by Krishna Bharat and Andrei Broder

SVMs for the Blogosphere: Blog Identification and Splog Detection 논문을 읽어 보았는데 블로그를 인식 하는 것이 성능이 꽤 좋았다는 내용이었습니다.

호기심이 동하여 구할 수 있는 블로그 URL 들을 가지고 테스트를 좀 해 보았습니다. 테스트에 사용된 URL 들은 주로 설치형 테터(텍스트큐브), 티스토리(독립도메인), 설치형 워드프레스 등을 사용하시는 블로그의 URL 들 을 사용 하였으며, 포털 블로그나 이글루스, 티스토리 처럼 도메인만 보면 블로그 인지 판단 할 수 있는 URL들은 일부러 제외 하고 약 6만개 정도를 추렸습니다. (이 중에는 포스팅된 글의 URL 뿐 아니고, TAG 페이지나 방명록 과 같은 URL도 있습니다)

• 여기서 META 항목은 <meta name="generator" 태그를 가진 것을 뜻하지만,
  • 우리나라는 영어권과 달리 META 정보를 가진 블로그가 별로 없습니다. 워드프레스를 사용하시는 블로그나 몇몇 소수의 텍스트 큐브나 테터툴즈 블로그에서만 있습니다.
• RSS 를 <link rel="alternate" 로 표시하지 않는 블로그도 종종 있습니다.
  • 주로 버전이 낮은 테터툴즈를 사용하는 블로그 (또는 이때 작성된 스킨을 그대로 사용하시는 블로그) 에서 발견 됩니다.
• blog, comment, trackback 의 단어의 경우
  • 우리나라 블로그는 "댓글", "덧글", "답글", "트랙백", "연관글", "이웃글"등 여러가지 용어가 혼재되어 사용되며, 영어 단어와도 혼용 되는 특징이 있습니다.
• 블로그에 AnyBGM 과 같은 걸 사용하면 Frame을 사용하게 되므로, 한번에 웹페이지를 가져올 수 없어서 (귀찮으므로) 이런 URL들은 상세히 테스트하지 않고 비율만 구해 보고 제외시켜 버렸습니다.

이런 특징 들이 있기 때문에 좀 더 다른 방법으로 테스트를 해 보았습니다. META 정보의 경우 소수의 블로그에서만 발견 되지만 비교적 정확한 정보를 얻을 수 있기 때문에 블로그라고 확신되는 META  정보의 비율만 측정 하였습니다.(나모 웹 에디터와 같은 정보는 무시 하였다는 뜻) 그리고 RSS의 경우 HTML 을 전부 뒤져봐서 RSS 관련 링크라고 판단되는 모든 링크를 사용하였습니다. 그리고 bag-of-words 의 경우 혼용되는 모든 단어의 출현빈도를 계산하여 사용 하였습니다. 그래서 측정된 비율이 아래 표와 같습니다.

• 몇가지 단어의 출연 빈도를 가지고 블로그 URL들을 측정해본 결과 결과값이 높더라
• Anchor Text 나 Link 특성 분석하는 특징까지 사용하면 결과값이 꽤 신뢰성 높게 보정될 것 같다.
• META 정보의 경우 우리나라에서 비율이 낮지만 확실한 정보로 판단된다.
  

Recall 과 Precision은 IR에서 중요한 측정 기준 입니다.

Recall은 검색어와 관계되는 문서 전체 중에 몇개를 찾아내느냐를 보는 것입니다. Recall이 높지 않으면 검색 결과 자체가 적기 때문에 품질이 형편 없다고 느껴지게 됩니다. 물론 대상되는 문서 자체가 엄청나게 많다면 Recall이 어느정도 수준만 되면 검색 결과의 양이 충분 하기 때문에 품질에 문제를 느끼지 못합니다. 예를 들어 구글에서 검색하는 결과는 대상되는 문서 자체가 엄청나게 많기 때문에 다른 검색엔진에 비해서 Recall이 떨어진다고 해도 품질 자체는 더 좋아보이게 됩니다. 이 경우 Precision이 더 중요하게 됩니다.

이런 Recall이 아닙니다. 이미지 출처는 요기

Precision은 검색결과 중에서 상위 몇 위까지 중 관계되는 문서가 몇개인가를 보는 것 입니다. 결과의 "정확도"를 측정 하는 자료로서 검색엔진의 "랭킹"이 얼마나 잘 되어 있는가 측정 하는 자료 라고도 볼 수 있을 것 같습니다. 문서모음(= 컬렉션 = 검색대상 전부)의 크기가 커질 수록 높은 Precision을 가진 검색엔진이 필요합니다.

 
100개의 검색대상에서 "블로그"와 관계있는 문서가 50개 라고 했을때, 검색엔진에서 "블로그"를 검색 했을때 20개의 결과를 반환 한다면 Recall은 50분의 20 = 0.4 됩니다. 보통 검색 엔진이 한페이지에 10개의 결과를 보여 주므로.. 상위 10개(첫페이지)를 보았을때 "블로그"와 관계된 문서가 5개가 보인다면 Precision은 10분의 5 = 0.5의 값이 됩니다.

Mercator: A Scalable, Extensible Web Crawler를 간단히 소개 합니다.

1999년 6월 26일 자료이고, 저자는 Allan Heydon(heydon@pa.dec.com), Marc Najork(najork@pa.dec.com) 입니다. 당시 Compaq System Research Center에 있었습니다.

Mercator의 Main Component를 표시한 그림 입니다. 일반적인 웹 크롤러의 구조와 비슷 하게 생겼습니다. 동작을 간단하게 살펴보면 번호 순서대로 아래와 같습니다.

1. 추려진 URL을 준비 합니다.
2. 각각의 scheme에 따라 fetch 명령이 실행 됩니다.
3. RewindInputStream (RIS) 형식으로 download 됩니다.
4. 중복 되거나 필요없는 Contents는 처리하지 않습니다.
5. Link 추출, Tag Count, GIF 처리 등과 같은 작업이 수행 됩니다.
6. 추출된 Link에서 필요없는 URL은 판단하여 처리하지 않습니다.
7. 이미 처리된 URL은 중복으로 판단하여 처리하지 않습니다.
8. 추출된 Link를 새로 탐색하기 위하여 준비 합니다.

Mercator는 기본적인 웹 크롤러의 기능을 가지고 있고, 모듈화가 잘 되어 있는 크롤러 입니다. 각각 모듈의 자세한 특징은 PDF 파일로 살펴 보실 수 있습니다. ^^

참고문헌:

Mercator: A Scalable, Extensible Web Crawler by Allan Heydon(heydon@pa.dec.com) and Marc Najork(najork@pa.dec.com) 1999/06/26

관련글:

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

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

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

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

대부분은 웹검색 시스템의 구조에 관한 설명이고, 블로그 검색이나, 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 부분에서 보낸 다는 것이 제 눈에는 약간 신기해 보였습니다. ^^

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

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