Recommanded Free YOUTUBE Lecture: <% selectedImage[1] %>

일단 마구잡이로 써나간다음에 정리한다.

소개

개발자 관점에서 기획자가 검색서비스를 기획한다면, 어떤 점에 신경을 써야 할까 하는 것들에 대해서 정리해보려고 한다. 아마도 몇가지 실례를 들어서 설명하게 되지 않을까 싶다. 서비스 사용유저 관점이 아닌 개발자 관점에서 접근을 할 것이다.

검색서비스 기본 구성

  Data Data Data ...
 ----------------------------
   |
   |
   |                                                      User Interface
   |                            +-----------+                   |
   | Crawl  +--------+ Indexer  | +--------+|     +----------+  |
   +------->| Data   |--------->| | Index  ||<--->| Searcher |--+
            |        |          | +--------+|     +----------+
            +--------+          | +--------+|
                                | | Index  ||
                                | +--------+|
                                | +--------+|
                                | | Index  ||
                                | +--------+|
                                +-----------+

기획영역

검색서비스 전략기획

  • 서비스 철학 수립
  • 서비스 방향 설정
  • 신규 서비스 발굴
  • 기존 서비스 개편

검색서비스 품질관리

  • 품질 측정및 개선을 위한 계획수립
  • 알고리즘튜닝 및 개발
  • 효과적인 데이터처리 구조에 대한 모델제시

검색서비스 프로젝트 관리

crawl : start url

인터넷상에서 문서들은 컨텐츠의 종류에 관계없이 link(:12)로 연결되어 있기 마련이다. 그러므로 문서의 수집은 그래프탐색과 관련이 된다. 그래프 탐색에 대한 이론은 매우 높은 수준에서 완성이 되어 있기 때문에, 지금에 와서 기술적인 문제는 없다고 봐도 될 것 같다.

그러나 기술적인 문제가 없다는 것은 이들 그래프가 실험실환경에서 끊기지 않은 연결일 적에나 가능하게 된다. 실제 인터넷 환경은 실험실에서의 그래프처럼 완벽하지 않기 때문에, 그래프 탐색의 시작점 즉 start url을 어디로 하느냐가 매우 중요한 이슈가 된다.

이문제는 기획적인 관점에서 해결되어야 할 문제로 분류할 수 있다.

검색 영역이 명확할 경우

웹검색에서 복잡한 그래프 탐색을 하는 이유는 그래프가 계속 변경되기 때문이다. 만약 이러한 변경이 자주 일어나지 않는 컨텐츠라고 한다면, 그래프탐색 대신에 선형탐색을 하도록 요구할 수 있을 것이다. - 즉 URL 리스트를 만들어서 유지하는 -

예를들어 블로그 검색의 경우에는 웹서비스에 비해서 URL의 추가가 빈번하지 않을 거라고 예상할 수 있다. 이 경우에는 굳이 그래프탐색을 하지 않아도 될 것이다.

그래프 탐색을 해야만 한다면

이 경우 신뢰할만한 URL의 목록을 수집하는 방법이 있을 것이다. 어떻게 수집해야 할런지는 기획자의 결정사항이라고 생각되는데, 가장 손쉬운 방법은 웹방문통계서비스회사로 부터 구입을 하는 것이다.

이와 관련된 모범적 사례로 구글의 예를 들어볼 수 있을 것 같다. 구글은 자체적인 솔류션을 가지고 이문제를 해결하고 있다. 이 솔류션들의 특징은 신뢰할만한 사이트의 목록을 확보하는데, 촛점이 맞추어져 있다.

page rank

pagerank는 단지 페이지의 중요도만을 계산하는 것 뿐만이 아니다. pagerank(:12) 는 외부로부터의 링크가 많은 페이지에 높은 점수를 부여한다. 즉 pagerank(:12)가 사이트는 신뢰할 만한 사이트로 평가할 수 있을 것이다.

자체 content 서비스

메타블로그 사이트가 대표적인 경우가 될것 같다.

자체 Agent 및 toolbar

대부분의 포털들이 toolbar를 제공하는데, 이는 유저를 자신들의 페이지로 유입하겠다라는 목적외에도 페이지 방문기록과 같은 정보를 얻기 위함으로도 사용한다. 이렇게 수집된 정보는 가공되어서 신뢰할만한 URL을 찾아낼 수 있을 것이다.

블로그 검색 서비스를 원한다면, RSS Reader를 만들어서 배포하는 것도 좋은 방법이 될 것이다.

여하튼지간에, 검색서비스의 품질을 높이기 위해서는 Agent를 개발하거나 양질의 URL을 수집할 수 있는 컨텐츠 서비스를 해야 할 것으로 생각된다. 일단 급하다면, 돈주고 URL 목록을 구입하는 방법도 있을 수 있긴 하겠다.

품질 vs 성능

기획자는 최대한의 자원이 투입될 수 있다는 가정하에, 그러니까 최고의 개발인력 무한대의 처리능력을 가진 컴퓨터가 주어진 상황을 염두에두고 서비스를 기획하는 경우가 많을 것이다. 그렇지만 개발자 입장에서는 그러한 요구가 무리라는 걸 안다. 개발자는 만능이 아니며, 우리에게 주어진 컴퓨터의 성능은 기획자의 요구사항을 만족시키기에는 터무니 없이 느리기 때문이다.

이러한 기획자와 개발자의 의견충돌은 결국 품질이냐 성능이냐의 문제가 되겠는데, 이는 선택의 문제가 아닌 trade:::off(타협)의 문제가 된다.

이는 적절한 타협점을 찾기 위해서, 기획자와 개발자 사이에 어느정도의 공감대가 형성되어야 함을 의미한다. 여기에서는 공감대를 형성하기 위한 몇가지 사안들에 대해서 생각해 보려고 한다.