인사이드 서치

기능 삭제 기획은 왜 없을까?

webJOY — Thu, 15 Apr 2010 22:47:12 +0900

검색 엔진 관련된 일을 10여년간 하면서 여러 복잡한 검색 기획서들을 접해봤다. 검색 기획서는 아이디어 복제와 추가 과정을 거쳐 점점 더 복잡해지고 있다. 오늘도 기획서를 보고 새롭게 기획된 기능들을 어떻게 구현할지를 고민하던 중이었다. 색인 필드를 너무 많이 추가해 엔진 한계를 넘었고 일 2백만 실시간 동적 색인이 발생하는 콜렉션이었다. 골치 아픈 기획 기능이었다. 복잡했다. 그 순간 문득 "기능은 계속 추가되는데 왜 기능을 삭제하는 기획은 없지?"란 생각이 들었다. 한번도 생각한 적 없는 생소한 질문이었다.

저녁 먹으로 가는 길에 지나가는 동료에게 물었다. 혹시 검색 기능을 빼는 기획서를 본적이 있냐고. 그 친구 "허허 그런적 없죠. 당연히~~". 왜 그렇게 생각하는지도 물었다. 답은 으외로 단순했다. "10개 기능이 있었고, 1개 기능을 추가하면 더 성공할 가능성이 높아지죠. 당연히~~" 우문에 현답을 했다.

답은 모른다. 다만 기능 추가 기획보다 기능 삭제 기획이 더 어려워 보인다. 기능 추가는 '더하기'로 보이지만 기능 삭제는 '빼기'처럼 보이기 때문이다. 하지만 역으로, 복잡해진 기획 안에서 삭제가 추가 보다 더 가치있고 실제로 'PLUS'효과를 기대할 수 있지 않을까? 최신 냉장고의 숨긴 기능들이 나날이 복잡해지지만 노출된 기능들은 점점 단순해지는 하드웨어 세상 같이 말이다.

삼성의 이건희 회장이 혁신을 외치고, 대한민국의 미래가 아이폰 같은 혁신 상품에 있다고 다들 주장한다. 새로운 아이디어를 만드는 방법으로 첫 번째는 더하기/빼기라 한다. A와 B를 더해 C를 만들고 A에서 B를 빼서 새로운 C를 만든다. 삭제 서비스 기획 안을 들고 가서 보스를 설득이 어려우니, 보스 설득 확률이 높은 추가 기획을 하고 있지는 않을까 곰곰히 생각해본다.

@윤종완

추신. 누구 삭제 기획을 하시는 분 보신적 있나요?

의미 검색(Semantic Search)과 잠재 은닉 색인 (Latent Semantic Indexing)

webJOY — Mon, 08 Dec 2008 23:05:33 +0900

최근 검색 트렌드는 의미 검색(Semantic Search)인 것 같다. 구글이 키워드 검색을 꽉잡고 있고 개인 맞춤 검색은 시들해진 여파 같다. 의미 검색(Semantic Search)을 어떤 식으로 얘기해도 역 파일 기반 검색엔진을 통해 구현한다면 검색어, 색인어 선별 문제로 국한된다. 문장 또는 검색어에 나타난 그대로를 색인하면 키워드 검색이 된다. 의미 기준에 따라 선별하면 의미 검색이라고 불릴 자격이 부여된다. 사용자 입장에서 보면 검색어가 돌출돼 있는 문서를 머릿속에서 상상하며 검색하면 키워드 검색이다. 반면 문서를 그 자체로 생각하며 검색한다면 의미 검색이 된다. 웹 검색이 대표적인 키워드 검색라면 쇼핑몰 검색이 대표적인 의미 검색 분야다. 웹 문서는 디지털화된 문자열로 쉽게 상상되지만 구매 대상인 옷들을 문자열로 상상하기란 힘들다.

쇼핑몰에서는 잘 조직화된 의미사전을 사용해 검색어를 자동 확장하여 의미 검색을 시도한다. 아래에 GS이숍의 "나이키" 검색결과가 있다. 잘보면 첫 결과에 "나이키"란 단어가 없다. 나이키의 영문표기인 "NIKE"를 자동으로 넣어 검색했다. "NIKE"와 "나이키"는 수작업으로 의미사전에 등록되어 있고 검색엔진에서는 "나이키"를 "나이키 or NIKE"로 확장해서 검색했을 뿐이다. 질의확장 용도의 의미사전은 정교하게 튜닝되어야 하기에 모두 수작업으로 만든다. 잘못된 오확장은 검색결과를 나쁘게 만들기 때문이다. 일일이 등록되는 모든 상품을 검토할 수 있다면 수작업을 뭐라 할 수 없다. 하지만 옥션과 같이 사용자들이 올리는 상품이라면 불가능하다. 이런 경우 자동화된 질의확장방법이 절대적이다.

상품 내용 그 자체만을 분석해서 쿼리를 자동 확장하는 잠재 은닉 색인(Latent Semantic Indexing)이란 기법이 있다. 상당히 잘 동작한다고 알려져 있는데 국내에 잘 소개되지 못한 것 같다. LSI가 심한(?) 행렬 계산을 필요로 하고 문서와 질의를 은닉차원으로 전환하기 위해 2차 색인을 참조해야 하는 여러 부담 때문에 LSI를 적용한 엔진을 구경하기 힘든것 같다. SVD(Singular Value Decomposition)이란 어려운 선형대수가 나오기 때문일지도 모르겠다. 색인기법으로 LSI와 같은 고급기법들을 채택한 똑똑한 검색엔진이 나왔으면 한다.

@webJOY

루씬 멀티 쓰레드 검색 서버

webJOY — Tue, 18 Nov 2008 14:40:07 +0900

루씬은 단순 라이브러리다. 데몬 형태로 항시 실행되며 검색어를 찾아주는 검색 서버를 만들려면 웹 서버가 필요하다. 검색 서버용 웹 서버는 검색어를 동시 처리해야 하므로 멀티 쓰레딩이 되어야 하고 적어도 HTTP 1.0을 지원해야 한다. 욕심을 내자면 HTTP Keep Alive를 지원하는 HTTP 1.1 스펙을 지원하면 더 좋다. 사용자 쿼리 폭증 시에 검색 서버가 마비되는 현상을 막기 위해 허용 연결 갯수를 제한할 수 있는 기능이 있으면 금상첨화다. 여러 오픈소스 웹 서버가 있었지만 제티(Jetty)를 골랐다. 다른 자바 웹 서버를 사용해도 상관없다.

웹 서버는 해결되었지만 루씬의 검색 API인 IndexSearcher가 멀티쓰레드로 검색하는 경우에 대한 속 시원한 코드나 답변을 좀처럼 찾기 어려웠다. IndexSearcher는 가급적 1개 인스턴스만 가지고 작업을 하도록 루씬 매뉴얼에 권장되어 있어(참조) 멀티쓰레드가 공유해서 나눠쓰도록 코딩했었다. 결과는 엉망되었는데 ab 스트레스 테스트에 거의 80 ~ 90% 검색어를 처리하다 실패했다. 예외 메시지만 보았을때는 루씬 세그먼트 파일 오픈 실패였다. 파일 갯수 제한에 그 원인이 있는 줄 알고 동시 연결 클라이언트 수를 제약해보거나 단일 쓰레드로 테스트해보았지만 오류는 같았다.

해결책을 찾아 이리저리 구글링하다 코지 세키구치(Koji Sekiguchi)란 일본인이 쓴 "Apache Lucene 入門"이란 책의 예제 코드에서 해결점을 찾았다. 코지는 IndexSearcher 인스턴스를 한 개만 만들고 close()하지 않은채 계속 사용하는 DelayCloseIndexSearcher란 클래스를 만들어섰다. 첫 실험이 쓴 실패가 IndexSeacher.close()를 자주 호출하기 때문에 발생한 것 같다. 코지의 코드를 약간 수정해 Jetty + DelayCloseIndexSearcher로 만족할 만한 루씬 멀티 쓰레드 검색 서버를 만들었다.

고속 루씬 검색 서버로 가려면 넘어야 할 산들이 더 있다. 루씬 2.4 스펙에 들어 있지만 실제론 3.0에 구현될 예정이라는 읽기 전용 모드의 IndexReader를 사용해야 할 것 같다(LUCENE-1329). 처리율 향상을 위해서다. 또, 루씬 2.4에 새롭게 추가된 허용 시간내 색인 읽기 기능(LUCENE-997)도 꼭 필요하다. 대용량 콜렉션에서 빈번하게 출현된 색인어를 검색하는 경우에 대용량 IO발생으로 검색 서버의 IO 대역폭을 과점하여 다른 검색이 느려지기 때문이다. Jetty에서 동시 연결 갯수를 제한하는 기능은 아직 못 찾았다. 이 또한 검색어 폭주 현상에서 검색 서버가 원활히 동작하기 위해 꼭 필요한 기능이다.

@webJOY

우워~~ 코지 세키구치가 솔라(Solr) 커미터였군요 ^^
conv2님의 블로그에 코지 세키구치의 예제코드가 있어요. 약간 오타가 있답니다. 찾아보세요.

루씬 색인 압축 기법 : 가변길이 바이트 압축(Variable Byte Coding)

webJOY — Thu, 13 Nov 2008 22:00:00 +0900

검색엔진은 정수배열을 많이 사용한다. 역파일 색인의 문서벡터, 위치벡터를 저장할 때가 대표적인 예다. 이런 정수배열을 압축하면 디스크 공간을 덜 사용하고 메모리로 빨리 올릴 수 있어 일석이조다. 두마리 토끼를 다 잡는 정수배열 압축기법은 색인을 작게 하고 검색을 빠르게 하기 때문에 세련된 검색엔진의 필수조건으로 자리잡고 있다.

정수배열 압축은 압축결과의 형태에 따라 가변길이 바이트 압축(Variable Byte Coding), 가변길이 비트 압축 기법이 있다. 정수자체를 압축해도 좋지만 검색엔진의 문서벡터는 정렬되어 있기 때문에 인접한 정수간의 차이를 압축한다. 이런 방식(Gap encoding)을 보통 "색인압축(Index compression)"이라 총칭한다. 바이트보다 비트 색인압축 기법의 압축율은 좋으나 복호화 속도가 떨어져 가변길이 바이트 압축 기법이 색인압축 기법으로 많이 채택된다.

루씬 2.3.2에서 차이압축(Gap encoding)을 하는진 모르겠다. 하지만 가변길이 바이트 압축 기법은 구현되있다(IndexInput::readVint(), IndexOuput::writeVInt()). 더그커팅이 2004년 강의한 자료의 가변길이 압축 슬라이드 안에 있는 예제를 보면 동작원리를 이해할 수 있다. 슬라이드가 아래에 있다. 아래 예는 정수 135를 압축하는 예제다. 135의 이진표현인 10000111에서 하위 7비트를 뺀 후(shift right) 나머지가 있으면 1을 덧붙이고 없으면 0을 붙여 한 바이트를 만들어 저장한다. 이 과정을 반복 수행 한다.

가변길이 바이트 압축 기법은 간단한 알고리즘이지만 색인압축에서는 강력하다. 127보다 작은 정수라면 상위 3바이트를 저장하지 않아 1바이트만 저장공간으로 사용하게 되어 1/4로 줄어든다. 이처럼 작을수록 압축효율이 높아 작은 수가 많은 정수배열을 저장하면 효율이 좋게 된다. 이런 특징때문에 정렬된 문서벡터를 압축할때 차이값을 압축하는 이유다.

문서벡터 압축 방법은 매우 다양하지만 실무에서 쓸만큼 간단하고 효과적인 방법은 단연코 가변길이 바이트 압축기법이다. 압축 전에 비해 75% 공간을 절약할 수 있고, 쿼리 처리 속도도 나빠지지 않으며 또한 적용도 쉬워 나쁜게 없는 기법이다. Managing Gigabyte와 An Introduction to Information Retrieval 책에도 상세히 소개되어 있이니 참고바란다. 자바라면 루씬 코드를 베껴 쓰면 되고, C나 C++이라면 코드가 10줄도 안되니 포팅하면 된다.

@webJOY

대용량 텍스트 파일에서 탭(TAB)이 포함된 문자열 찾기

webJOY — Tue, 11 Nov 2008 16:51:09 +0900

대용량 텍스트 파일에서 원하는 문자열을 찾는데 grep을 많이 쓰지만, 탭 문자를 구분자로 사용하는 텍스트 파일에서 탭 문자가 들어간 문자열을 찾으려면 쉽지 않다. 흔히 $ grep "(가)\t" input.txt 와 같이들 하는데 동작하지 않는다. 아래와 같이 콘트롤 v키를 누르고 탭키를 눌러 입력해야 한다.

$grep "(주)<Ctrl-v><TAB>" input.txt

@webJOY

파이썬 성능 측정 함수

webJOY — Mon, 10 Nov 2008 14:44:51 +0900

파이썬에서 절대시간을 구할때 clock 함수의 정확도가 낮아 밀리초 단위의 정확한 결과가 필요한 실험에서는 주의해서 사용해야 한다. 윈도우 계열이라면 clock를 사용해도 상관없지만 유닉스 계열이라면 time함수를 사용해야 한다고 한다. 유닉스 clock함수는 clock tick을 1/N하여 사용하는데 이 N은 10 또는 100 정도로 커 불과 수십분의 1초 단위의 정확도 밖에 넣을 수 없기 때문이다. 윈도우즈 계열에서 clock은 time함수와 동일하게 구현되어 있어 이런 문제가 없다고 한다. 코레이 골드버그 블로그에 관련된 토론 글들이 있다.

@webJOY

[팁] 우분투 암호없이 접속하기

webJOY — Wed, 05 Nov 2008 14:58:48 +0900

검색엔진을 코딩해 보면 한대의 개발 장비에서 코딩한 후 여러 대의 테스트 장비 간에서 테스트를 하는 경우가 많은데 매번 로그인, 복사, 테스트 반복을 심심치 않게 하게 된다. 리눅스에서 제공하는 ssh, scp, rsync 명령들이 이럴 때 빛을 발한다. 하지만 이런 원격 명령들도 실행할 때 마다 암호를 입력해줘야 한다. 다음과 같은 상호 인증 절차를 거쳐 이조차도 말끔히 해결할 수 있다.

center$ ssh-keygen -t rsa
... 물어보면 모두 엔터 ...

center$ vi ~/.ssh/id_rsa.pub
... 생성된 키를 복사 ...

remote$ vi ~/.ssh/authorized_keys
... 복사한 키를 붙여넣기 ...

center$ ssh id@remote
... 암호없이 바로 접속 ...

이클립스를 사용할 때도 마찬가지 인데, 이클립스에는 rsync, scp용 플러그인이 있다고 한다. 개발 장비에서 이클립스로 코딩하고 테스트 장비에서 대용량 색인을 사용해 테스트하려는 경우에 딱이다. 이클립스 플러그인도 사용해볼까?

@webJOY

집단 지성 프로그래밍: 구글의 대규모 협업 필터링 구축 사례

webJOY — Mon, 27 Oct 2008 02:38:28 +0900

협업 필터링(Collaborative Filtering)과 같은 집단지성 발굴용 집계 알고리즘(collective algorithm)은 물품 또는 사용자 간의 유사도 계산(similarity function)으로 시작된다. 사용자, 물품이 소량인 경우라면 메모리에 올려 놓고 계산하면 된다. 하지만 현실은 만만치 않다. 사용자, 물품 수가 수십만 이상은 기본이고 수백만 단위가 되기 때문이다. 실무에서 협업 필터링 기법을 적용해 고객에 딱 맞는 물품을 추천하려면 교과서적인 메모리 기반 알고리즘으로는 불가능하다.

하둡(Hadoop)의 맵 리듀스 프레임워크(Map Reduce Framework)은 이런 대규모 계산 용도에 적합하다. 확장성이 뛰어 나지만 제한된 곳에서만 사용할 수 있다. 모든 메모리 기반 알고리즘을 맵 리듀스화 시킬 순 없다. 맵 또는 리듀스 작업 도중에 입력받은 이외의 데이터들이 필요하면 중앙 DB에 조회하여 데이터를 구해야 하기 때문이다. 이런 중앙 DB 연산이 많으면 하둡의 가치가 없어진다. 따라서, 대용량 상황에서 집단지성 발굴용 집계 알고리즘으로 교과서에 소개된 메모리 기반 알고리즘은 적합하지 않고, 대신에 맵 리듀스 전용 알고리즘을 찾아야 한다. 만일 중앙 DB가 꼭 필요한 경우라면 그 크기가 작아 빠른 조회가 되어야 한다.

페이지랭크 알고리즘이 메모리 기반 알고리즘과 맵 리듀스 기반 알고리즘의 기저사상이 다르듯 협업 필터링용 유사도 계산 알고리즘도 맵 리듀스 버전을 찾아야 한다. 다행히도 구글링을 통해 구글이 "대용량 뉴스 개인화 서비스"에서 사용한 기법인 LSA(Locality Sensitive Hashing)란 기법을 찾았다. 이 기법은 두 객체가 가까운 거리에 있을 수록 해쉬 값 충돌 확률이 높도록 해쉬 함수를 설계하는 방법이다. 한마디로 거리 관계를 충돌 확률 문제로 변환하여 해결하는 일종의 확률적 군집화 방법이다.

다양한 거리 계산 방법에 맞는 LSA용 해쉬 함수는 각각 다르다. 유사도 계산에 많이 사용하는 자카드 계수용 LSA 해쉬 함수로 MinHash란 것이 있다. MinHash 기법에 따르면 해쉬에 의해 차원이 축약된 개체들 간의 자카드 거리와 원 개체들의 자카드 거리는 확률적으로 근접하다라고 한다. 결국 어느 사용자들의 MinHash 값이 같으면 근접한 유사 사용자라고 판단할 수 있기 때문에 이 MinHash 값을 유사 군집 식별번호로 사용한다.

MinHash를 사용하면 맵 리듀스 프레임워크에서 다뤄야 할 데이터 량이 크게 준다. 맵 작업에서 "사용자 식별자 - 선호 물품 번호 목록" 입력을 받아 사용자별 물품의 MinHash값을 구한다. 사용자마다 p개 MinHash를 생성해 이 값들을 문자열 형태로 붙혀 군집 식별자를 생성한다. 맵의 출력 키로 군집 식별자를 그리고 맵 출력 값으로 사용자 식별자를 넣는다. 리듀스 작업을 통해 군집 식별자 - 사용자 식별자 목록(ClusterUserMap)을 최종 출력으로 구한다. 다음으로 새로운 맵-리듀스 작업을 통해 역전된 형태인 사용자 - 사용자가 속한 그룹 식별자 목록 데이터(UserClusterMap)를 생성한다. 이 두 출력 파일은 구글 BigTable 같은 중앙 DB에 넣어 키로써 값을 조회할 수도록 저장한다. MinHash로 인해 중앙 DB에 넣을 정도록 작아졌기 때문에 한곳에 저장 가능하다.

A 사용자의 유사 사용자 목록을 구하려면 2단계 거쳐야 한다. 먼저 UserClusterMap에서 A가 속한 군집 식별자 목록을 구한다. 이 군집들에 속한 유사 사용자를 ClusterUserMap에서 찾는다. 이렇게 얻은 <A 사용자 - 사용자 식별자> 간의 유사도 계산을 위해서는 A와 유사한 사용자들간의 군집 식별자를 구해 MinHash값을 분리낸 뒤 자카드 계수 계산법에 따라 계산하면 된다. 대용량의 로그 데이터에서 맵 리듀스 방식 알고리즘을 사용해 내 취향에 맞는 상품은 이렇게 구해질 수 있다.

@webJOY

MinHash 알고리즘을 이해하기 쉽게 설명한 파워포인트

minhash.pdf

맵 리듀스 프레임워크를 이용한 확장성 있는 협업 필터링 기법 논문

paper570.pdf

집단 지성 프로그래밍 : 예스 24 마이 리스트에서 발굴한 집단 지성

webJOY — Thu, 16 Oct 2008 03:34:41 +0900

집단 지성은 사용자들이 제공한 선호 정보에서 발현되기 때문에 집단 지성를 발굴하려면 사용자들의 선호가 녺아든 선호 정보를 수집해야 한다. 일부 웹 2.0 사이트들의 경우 이런 선호 정보를 오픈 API를 통해 직접 제공하지만 대다수 웹 서비스에서는 제공하지 않는다. 특히 국내 웹에서 선호 정보를 구하기 매우 어려워 알고리즘 실험에 외국 데이터를 사용하지만 데이터에 대한 낮은 이해도로 인해 결과 해석이 어려웠다.

국내에서 공개된 선호정보를 찾아보았다. 오픈 API를 통해 직접 제공하는 서비스는 못 찾아 스크린 스크래핑 기술로 직접 수집하기로 했다. 수집할 선호정보를 찾던 중에 온라인 서점들의 '마이 리스트' 서비스에서 제공하는 '사람 - 찜 - 책' 선호정보를 수집해보았다. liburl2을 사용해 선호 정보를 담고 있는 웹 페이지를 가져와 BeautifulSoup을 사용해 파싱한 후 HTML 태그들에 포함된 특정 패턴의 문자열을 파이썬 정규식을 통해 꺼내는 방식으로 스크린 스크래핑했다. 이 기법들은 '집단 지성 프로그래밍' 책에 잘 나와있다.

스크린 스크래핑을 통해 예스 24 마이 리스트에서 1,075명의 사용자 목록과 이 사용자들이 마이리스트에 등록한 9,853개 책 제목을 추출했다. 사용자들이 찜한 총수는 12,881개였다. 사용자당 평균 10개 책을 등록하고 있고, 책 기준으로 보면 책 당 평균 1명이 관심 사용자가 있다. 마이 리스트 선호 정보도 소셜 데이터의 특성인 희박성(sparseness)를 그대로 드러낸다.

집단 지성은 집합적인 개인 판단들이 모여 특정 판단 문제에 대한 현명한 해답을 제공한다. 개인이 마이 리스트에 특정 책을 둘지 말지를 판단할 때는 여러가지 목적이 있을 수는 있지만 이런 책에 대한 관심은 주로 "읽고 싶은 책" 목록일 것이다. 이런 상황에서 집단 지성이 현명한 해답을 제공할 문제는 "이 책의 읽고 싶은 선호도 순위는?"가 된다. 구글의 페이지 랭킹 처럼 마이 리스트로 표현된 사용자 관심을 모아 선호 정보를 구축함으로써 각 책들의 선호도 점수를 구할 수 있다.

특정 책의 선호도 점수를 가장 간단하게 표현하는 지표는 그 책을 찜한 사람 수다. 마이 리스트는 도서 블로그 안에 특정 책을 찜해 놓는 목록이고 아직까지는 스패머가 보이지 않기 때문에 이런 단순 누적치도 좋아 보인다. 책 선호도 점수를 찾았다면 자연스럽게 "이 선호도가 현명한 판단인지를 어떻게 검증할 수 있을까?"라는 질문을 떠올리게 된다. 사회적인 선호도 점수를 평가하기란 매우 어렵지만, 책의 경우에는 '판매 부수'를 통해 간접적으로 검증할 수 있다. 인기있는 책은 잘 팔린다란 명제가 성립된다면 책의 선호도 점수순이 판매부수가 되어야 한다.

도서판매부수는 한국출판인회의가 매주 회원사들의 판매량 집계를 가지고 주간 베스트 20위를 발표한다. 판매량 상위 20위와 예스24 인기 20위 간를 비교해보면 다음과 같다.

위 두 목록에서 공히 출현한 책들을 노란색으로 마킹했다. 갹 20개 책들 중에 7개가 중복되었고 13개는 달랐다. 이 두 목록에서 왼편 목록은 지난 주의 도서 판매 부수고 오른편 목록은 금주 초에 만든 인기 목록이다. 집단 지성이 미래를 잘 반영한다면 오른편 목록이 다음 주에 나올 도서 판매 부수와의 중첩도가 더 높아져야 할 것이다. 감히 예견해 본다면 차주 주간 도서판매부수의 1위는 "시골의사의 주식투자란 무엇인가1" 또는 "부동산 대폭락 시대가 온다", "가슴 뛰는 삶" 중에 한개가 될 것 같다.

@webJOY