정보탐정의 설계 및 구현

이 자료는 11월 7일부터 9일까지 웹코리아 주최로 광운대에서 열릴 제4회 WWW워크샵 에서 발표할 강의자료입니다.

김형근
서울 서초구 우면동 17, 한국통신 멀티미디어 연구소
E-MAIL: hiongun@aistar.kotel.co.kr
URL: http://aistar.kotel.co.kr/~hiongun/hiongun.html

정보탐정이란...

  1. 정보탐정 (http://aistar.kotel.co.kr/) 이란 한국통신 멀티미디어 연구소에서 시험용으로 개발한 인터넷 정보검색 엔진으로서, 윙윙윙 (http://kt.expo.or.kr/net/search/srch0hh0.html) 이라는 이름으로 상용화를 추진하고 있다.

  2. 정보탐정은 시그너쳐 기법을 이용한 고속 색인 및 검색을 수행하며, 색인 검색 프로그램은 100만개 이상의 문서까지도 수용할 수 있으며, 색인과 검색 속도는 문서 수에 대해 선형적으로 증가할 만큼 효율적이다.
    고속 색인/검색 참조

  3. 정보탐정의 로봇은 다중 프로세스간의 통신을 통한 병렬적인 문서 수집을 수행한다. 문서 수집 로봇은 특히 문서들간의 URL링크에 역링크를 내부적으로 생성하여 문서들간의 양방향 지도를 만드는 것이 특징이다.
    탐정 로봇 참조

  4. 정보탐정의 자연언어 처리기는 다년간의 연구결과가 집적된 것으로서, 시소러스, 유사어처리 및 다양한 연산자 처리를 수행한다.
    자연언어 처리 참조
  5. 현재 로봇이 한국내의 10만 페이지와 그에 일차적으로 연결된 외국의 페이지를 매주마다 체크하여 수집하고, 그것을 색인하여 검색한다.
    통계자료 참조

정보탐정의 시스템 구성도

정보탐정의 가장 큰 장점 중의 하나는 문서 수집 로봇과 색인기, 검색기, 자연언어처리기, 인터페이스등을 각각 완전히 독립시켜 분리해둘 수 있다는 점이다. 특히 문서수집 로봇과 색인/검색기는 엄청난 양의 계산을 소요하기 때문에 서로다른 호스트에 따로따로 분산 시킬 필요가 있다. 또한 HTTP서버와 검색서버를 분리하여 부하를 분산시킬 수 있는 구조로 설계되었다.

정보탐정의 구성도

현재 "윙윙윙"과 "정보탐정"은 인터페이스만 다르고 실제로 검색엔진은 동일한 것을 사용한다.

안정적인 서비스가 필수적으로 요구되는 경우 손쉽게 이중화할 수 있는 구조인 것이다.


개발환경

현재 로봇/색인/검색기가 하나의 호스트에, 정보탐정 인터페이스가 다른 호스트에 존재한다.
  1. 로봇/색인/검색기 개발

  2. 정보탐정 인터페이스 개발
이기종간의 분산환경을 고려했으므로 표준적인 C언어를 써서 거의 모든 시스템을 구축하였다.

개발시기 및 서비스개시

한국통신 멀티미디어 연구소에서는 1992년도부터 1995년까지 장기적으로 "지능형 정보검색"이라는 연구를 수행해 왔었다. 정보탐정에 사용된 기초적인 기술들은 "지능형 정보검색"의 결과물들이다.

구체적으로 '정보탐정'에 한정시키서 생각한다면,

  1. 로봇 설계 및 구현 : 1995년 12월 ~ 1996년 2월

  2. 로봇의 최초 구동: 1996년 3월

  3. 인터넷 검색용 색인/검색기 설계 및 구현: 1996년 2월 ~ 3월

  4. 최초 시험서비스 시작: 1996년도 3월
근본적인 기능들은 초기에 거의 완성되었고, 그 이후로는 작은 기능들이 추가되거나 변경되고 있다. 각 모듈들을 통합되는 방식들이 일부 바뀌기는 하였지만 외형상의 변화는 아니다.

 

  1. 검색기 내부의 모듈간의 결합방식의 변화

  2. 검색기와 홈페이지 CGI-bin과의 결합방식

  3. 로봇의 문서수집 방법의 변화

고속 시그너쳐 색인/검색

시그너처(Signature)란 입력 스트링을 특정한 해슁함수(hashing)를 사용하여 만들어 내는 고정길이의 비트열이다. 시그너쳐를 이용한 색인이란, 어떤 문서를 하나의 시스너쳐 비트열로 만들어 내는 작업을 반복적으로 수행하는 것을 말한다.

시그너처의 폭(혹은 길이)가 고정적인 크기이므로 입력문서의 갯수만 알면 필요한 시그너쳐 색인 파일의 크기는 산술적으로 계산할 수 있다. 시그너쳐 색인을 만드는 것은 다른 요소와는 (거의) 무관하게 문서의 갯수에만 선형적으로 증가하기 때문에, 대량의 문서를 다루는데 적합하다.

또한 시그너쳐를 만드는 과정이 단순한 산술적인 해슁함수를 사용하는 것이므로, 매우 견고한 색인기를 만들 수 있는 장점이 있다.

다음 그림은 시그너쳐를 이용한 색인구조와 새로운 질의어가 들어왔을 때, 그것을 시그너쳐로 변환하여 검색하는 것을 도해한 것이다.

시그너쳐 검색
그림에서처럼 새로운 질의어가 오면, 시그너처 비트열을 만든다음 그중에서 1이 되는 칼럼만 뽑아서 전체를 AND연산을 하면 하나의 긴 비트행이 만들어진다. 이 비트 행에서 1인 위치에 해당하는 문서에 그 질의어가 들어있을 가능성이 있다.

시그너쳐의 문제점은 이렇게 찾아낸 비트행만 가지고 검색이 끝나지 않고, 다시한번 원래의 문서를 뒤져서 실제로 그 단어가 그 문서에 들어있는지를 점검하는 작업이 필요하다는 것이다. (false drop checking) 정보탐정의 경우 상위 수십개에 대해서만 점검하기 때문에 크게 속도가 떨어지지 않도록 유지할 수가 있다.


문서 수집 로봇

문서 수집 로봇은 여러개의 부분 프로그램들의 집합으로 이루어져 있다. 개개의 프로그램들은 큐형식의 자료구조를 공유하며 큐에 자료를 넣거나 빼는 일은 큐만 전담하여 관리하는 매니지 프로세스가 존재한다. (동시에 여러 프로그램이 하나의 큐를 쓰거나 읽으려고 할 때 조절이 필요하므로.)

  1. GetDoc: VisitQ라는 큐에서 새로 다운로드해올 문서의 URL을 먼저 알아낸다. URL이 하나 주어지면 TCP/IP 소켓을 열어서 그 URL에 해당하는 파일을 다운로드하는 역할을 한다. 이때 다운로든 된 파일의 이름을 HtmlQ에 넣고 프로그램은 종료된다.

  2. ConvDoc: HtmlQ에서 변환할(Convert)할 문서를 하나 꺼낸 다음 해석이 용이한 파일 형태로 변환하여 그 결과를 DocQ에 넣는다.

  3. SaveDoc: DocQ에서 변환된 파일을 읽어서 그 속에 들어있는 URL들을 꺼내 VisitQ에 넣고, 파일 자체는 문서DB에 저장한다. 이때, 문서마다 (URL마다) 유일한 일련번호를 부여한다.

  4. 메시지큐매니져: 메시지 큐는 동시다발적으로 동작하는 GetDoc, ConvDoc, SaveDoc 이 세 프로그램들 사이의 자료 교환을 위한 자료 구조로서 유닉스의 DBM파일을 이용하여 구현하였다. 큐에 쓰고 읽는 작업은 별도로 큐만 관리하는 프로그램이 따로 있어서 중복을 제어한다.
  5. Supervisor: GetDoc이나 ConvDoc, SaveDoc이 세가지 프로그램들은 동시에 비동기적으로 여럿이 수행될 수 있는데, 한꺼번에 몇개씩 떠있어야 하는지는 현재의 메시지 큐 상태를 보고 판단한다. 특정 메시지 큐가 너무 많이 차 있으면 그 메시지 큐를 빨리 비우도록 GetDoc, ConvDoc, SaveDoc의 갯수를 조절한다.
스파이더 구성도

 

이렇게 여러 프로그램들이 비동기적으로 협동해가면서 만들어내는 자료 구조는 다음과 같다.

  1. UID: URL to ID mapping, 모든 URL에 유일한 ID번호를 부여한 DB

  2. UIDR: ID값으로 부터 URL을 알아낼 수 있는 DB

  3. UMap: 단방향성 URL들의 링크에 양방향성을 부여하여 저장한 URL들의 Map이다. URL링크를 역으로 추적해 나갈 수 있다. 어떤 HTML문서가 몇개의 다른 문서로부터 참조되는지를 알아낼 수 있는 구조이다.

  4. ULastMod: URL에 해당하는 문서가 마지막으로 수정된 날짜/시간을 저장한 구조. HTTP의 Conditional Get을 이용하여 중복됨이 없이 자료를 다운로드할 수 있도록 해주기 위한 DB이다.

  5. UAnchor: 특정 HTML문서에서 URL링크가 들어 있을 때, 그 링크에 부여된 텍스트(Anchor Text)를 저장해둔 DB. 이 자료 구조는 다운로드 하지 않은 문서들을 찾는데 사용된다. 특히 외국의 문서는 국내 문서에 1차적으로 연결된 것만 다운로드해 오기 때문에 2차적으로 연결된 것들은 이 정보만 가지고 검색을 할 수가 있다.
이 문서 수집 로봇을 설계하면서 가장 크게 고려했던 점은 중복됨이 없이 모든 문서를 다운로드 하되, 다음에 똑같은 문서를 두번 다운로드하지 않도록 하여 네트웍 부하를 최소화 한다는 것이다.

이 문서 수집기는 실제로 문서수집을 수행시켜 보면 네트웍 부하 때문에, 하루에 최대 10만개정도의 파일밖에 다운로드하지 못한다. 하지만 기존에 가져온 문서위에 또다시 문서를 수집하라고 시키면, 중복되는 것은 다시 가져오지 않기 때문에 높은 효율을 보장할 수 있다.


자연언어 처리기

정보탐정에서는 시그너처 색인구조를 쓰기 때문에, 색인시에는 자연언어 처리기를 사용하지 않고, 검색시에만 자연언어 처리기를 사용한다. 자연언어 처리기의 역할은 다음과 같다.

  1. 명사 추출, 복합명사 분할 : 입력된 질의어에서 명사를 추출하기, 복합명사의 경우 단일명사를 파악하여 빠져나가는 검색어를 방지하기

  2. 시소러스, 유사어 대치 : 사용자의 선택에 의해서 좀더 넓은 범위의 검색어로 확장하여 검색

  3. 불리언 연산자 발견 : 자연언어에서 형식적인 불리언 연산자를 찾아내는 것으로서 연산자는 OR, AND, NOT 등이 있다.
인터넷 검색의 경우 자연언어 처리기의 역할이 크지 않아서, 기본적으로는 자연언어처리기가 사용되지 않는 모드로 동작한다.

통계 자료

다음은 정보탐정을 운영하는 와중에 얻게된 몇가지 통계자료이다. 새로운 검색 엔진을 설계하는 사람들에게 도움이 되기를 바란다.

  1. KR도메인의 홈페이지 문서수 X: 10만 < X << 20만. 10월 현재 정보탐정의 경우 12만 3천 페이지. 검색엔진과 로봇에 따라 다르기는 하지만, 대체로 10만 페이지 이상은 되는 것으로 알려져 있다. 하지만 아직 20만개가 되지는 않는 것으로 봐서 세계적인 수준과는 엄청난 격차가 있음을 알 수 있다. (알타비스타의 경우 3천만 이상의 문서를 인덱싱하고 있음) 당분간은 국내의 검색 엔진들은 문서의 수에 대한 상한선을 100만으로 두고 개발해도 무리가 없을 듯하다.

  2. 문서당 평균크기: HTML마크를 제외하고 텍스트만 계산했을 때는 2.6Kbyte정도. 극단적으로 큰 파일들도 가끔씩 존재하는데, 그것들은 일정한 크기 이상은 아예 무시해 버리거나, 큰 파일을 잘게 조각내서 처리해도 좋을 것이다.

  3. 한국내의 웹호스트 수: 약 1만 2천. 산술 평균으로만 따진다면 하나의 웹호스트에 문서가 약 10개정도 존재함. 하지만 실제적으로는 몇몇 호스트에 문서들이 대거 몰려 있고 그외의 대부분의 웹호스트들은 거의 문서를 가지고 있지 않는 것으로 판단됨.

  4. 페이지당 평균 URL링크수: 약 15. 따라서 페이지들이 상당히 tight하게 서로 연결되어 있음을 알 수 있다.

  5. KR도메인에 1차, 2차적으로 연결된 외국의 URL수: 약 40만.

앞으로 나아갈 방향

정보탐정은 다음과 같은 방향으로 발전할 것이다.

  1. 대상문서분야의 확대: 웹페이지 뿐만 아니라, 유즈넷 뉴스 기사들, 온라인 신문기사등을 수용하는 방향

  2. 다국어 검색기능의 지원: 한국어 질의문을 이용하여 일본어나 독일어로 된 문서도 검색해 올 수 있는 기능

  3. 문서의 주제별 자동분류: Directory서비스를 위한 자동 문서 분류기능.

  4. 온라인 정보 필터링 기능: 다양한 정보 소스로 부터 들어오는 정보를 사용자별로 적당한 필터를 설정하게 하여, 개인적인 요구에 맞게 선별, 가공하여 제공하는 서비스로 발전하는 것.

  5. 정보탐정 외에 여러 검색엔진들을 동시에 호출하여 2차적으로 검색을 하는 '미스 다찾니'와 비슷한 검색 엔진을 보조적으로 제공하는 것.
이미 '정보스파이'라는 이름으로 메타 검색엔진이 실험용으로 개발되고 있으며, 문서의 자동 분류는 이론적으로도 중요한 연구과제가 되고 있다.