자동완성 기능 구현 db - jadong-wanseong gineung guhyeon db

자동완성기능-hivaless.zip

1.00MB

검색어 자동완성기능 구현을 위한 전체 소스입니다.

추천 검색어 리스트 파일로부터 추천 검색어 DB 파일을 생성한 후 실제 웹페이지에서 검색어를 입력했을 경우, 추천 검색어가 출력하는 데모 페이지까지의 전체 파일이 들어있습니다.

소스 안에 이것저것 쓸만한 모듈이 많이 있네요..

B-TREE 관련 모듈과... iconv를 wrap한 클래스도 있습니다. iconv는 문자 인코딩과 관련된 라이브러리 입니다.

또 AJAX를 이용해 웹브라우져에서 검색어 자동완성기능이 구현되어있는데, AJAX와 관련된 소스는 Ajax 입문(타카하시 토시로 저, 한빛 미디어) 책 소스를 그대로 참조하였습니다. 원래 소스는 z.html 이라는 파일에서 php 파일로 데이터를 전송하는데, 이 부분만 제가 만든 cgi 파일로 전송하도록 바꾸었습니다.AJAX에 관한 설명은, 이 쪽은 제 전문분야가 아니라서 생략하도록 하겠습니다. 저도 잘 모르구요..

프로그램을 테스트 해보기 위해서는, word_list.txt 파일을 수정하고, make_suggest_word_list 프로젝트를 컴파일 해 실행하여, 추천 검색어 DB를 생성하고, suggest.exe를 실행해보면 됩니다.

suggest.exe를 콘솔에서 실행하면 다음과 같은 창이 실행되는데, 임의의 문자열을 입력하면, 그 문자열로 시작하는 추천 검색어 리스트가 출력되는 것을 확인할 수 있습니다.

웹브라우져로 결과를 확인하고 싶다면, IIS를 이용해 웹서버를 설치한 후, 웹 브라우져로 http://127.0.0.1/suggest.html와 같은 주소로 suggest.html 파일을 열어서 확인해 보면 됩니다.

suggest.html에서 텍스트박스에 문자열을 입력하면, z.html 안에 선언된, 키 핸들러가 실행되고, 이 키 핸들러 안에서는 입력된 문자열을 suggest.exe에 전송하는 역할을 합니다. 그러면, suggest.exe에서는 qDecoder 라이브러리를 이용해 문자열을 받아서, 입력받은 문자열로 시작되는 검색어 리스트를 다시 z.html로 전송합니다. z.html에서는 이 검색어 리스트를 받아서 출력하는 것이지요..

하지만, 영어로 시작하는 추천 검색어 출력같은 경우에는, 2글자를 입력한 후에 인식되는 버그가 html 소스 안에 있습니다. html 소스는 책에 있는 소스를 그대로 사용하였기 �문에, 어떤 부분이 문제가 있는지 잘 모르겠군요...

아래는 위 프로그램의 추천 검색어 리스트 파일과 실제 실행 화면이구요...

필요하신 분들은 가져다 쓰도록 하세요~

왼쪽은 추천 검색어, 오른쪽 숫자는 추천 검색어의 중요도 입니다. 높을수록 리스트에서 위에 나타나죠

콘솔에서 실행 화면

웹 브라우저에서의 실행화면

자동완성은 autocomplete 혹은 suggest 2가지를 우리나라에서 하나로 통칭해서 부르는 것이다.

어떻게 보면 같을 수도 있고 굳이 구분을 짓자면 autocomplete는 내가 입력한 내용이 찾고자 하는 내용의 온전한 부분일 경우이고 suggest는 동의어/유의어/철자오타보정 등 온전한 부분이 아닌 결과도 포함하는 autocomplete + 알파 의 의미를 가진다

우리나라는 대체로 둘을 구분하지 않고 자동완성이라는 말로 혼용해서 사용하는 편이다.

자동완성은 우리가 흔히 접하는 포털 구글/네이버/다음에서 볼 수 있다. 물론 인터파크/교보문고/.... 등의 몇몇 대형 온라인 쇼핑몰에서는 더욱 발전된 형태로 자동완성을 활용하고 있다.

그러나 포털에서 제공하는 자동완성을 자동완성의 기준으로 생각하는 사람도 많고 그 결과 자동완성은 검색의 보조 수단으로 인식하는 경우가 대부분이다.

위에서 말해던 대형 온라인 쇼핑몰은 검색의 보조 수단으로 자동완성을 사용하는 것이 아니라 검색과 어깨를 나란히 어쩌면 검색을 쩌리로 만들어 버리는 막강한 기능으로 무장하고 있다.

포털의 자동완성 결과는 주로 키워드가 나온다 가끔 2단어 이상의 phrase가 나오기도 하지만 내부적으로는 공백은 제거한 한단어라고 보는게 맞을 것이다. 포털에서 자동완성의 결과로 키워드가 나오는 것은 당연한 것이다 왜냐하면 포털의 주 수입원은 키워드를 돈 받고 파는 곳이기 때문이다.

온라인 쇼핑몰은 키워드를 파는 곳이 아니다 그럼 당연히 자동완성의 결과는 쇼핑몰에서 판매하는 상품이 나와야 하지 않을까? 이 작은 자동완성 창에서 상품의 이미지와 상세정보 가격도 알 수 있고 내가 찾는 상품이 맞으면 바로 북카트에 담을 수 있다.

내가 찾고자 하는 것이 명확하다면 굳이 검색을 이용할 필요가 없어진다. 그만큼 사용자는 편리하고 편리한 만큼 경쟁 사이트에 비해 사용자의 선호도가 높아지는 것이다.

온라인 쇼핑몰은 오픈마켓과 직영마켓으로 크게 2가지로 나눠서 생각해 봐야 한다.

오픈마켓은 동일한 상품을 파는 여러 상인이 있는 경우인데 이 때 특정 키워드에 특정 상품이 우선 노출 된다던가 특정 판매자의 상품이 노출 된다면 형평성의 문제가 생기고 어떻게든 상단에 노출되기 위해 온갖 편법이 난무하게 될 것이다. 또한 쇼핑몰은 민원에 시달리게 되거나 포털처럼 키워드를 경매를 붙여서 높은 가격을 제시하는 상인에게 우선권을 주는 방법도 있지만 어떤 경우든 좋은 소리를 듣기는 힘들다. 그래서 쇼핑몰의 평화를 위해 상품 노출 보다는 키워드 노출을 선택 할 수 밖에 없을 것이라고 생각한다. 기술적인 문제는 논외로 하더라도

그럼 직영 쇼핑몰은 어떨까? 여기는 내 상품을 직접 판매하는 곳이다. 그런데 왜? 여기도 자동완성에 키워드를?

그럼 자동완성의 기술적인 문제를 한번 생각해 보자

Database나 검색엔진은 이제 그 기술이 상당히 상향 평준화가 되어 있어서 상용 엔진 혹은 오픈소스 엔진 그 무었을 선택하더라도 다들 기본 이상은 한다. 서비스와 유지보수 때문에 선택이 달라지는 것이지 기능 때문에 달라지는 경우는 거의 없는 편이다.

그에 비해 자동완성은 기술적인 스펙트럼이 매우 넗은 편이다. 그런데 혹시 자동완성엔진이라는 말을 들어 본적이 있는가?

1. 가장 쉽게는 JQuery UI 의 autocomplete 혹은 twitter의 typeahead 를 이용해서 static data를 실어서 구현할 수 있다. 생각보다 쉽다.

2. 그 보다 나은 방법은 Database를 활용하는 방법이다 사용자가 키를 입력할 때마다 Database에 양방향 like 검색을 해서 결과를 보여주는 방법이 있다. 장점은 데이터 관리는 원래부터 되어 있던 것이고 그냥 SQL을 만들어서 json 으로 변환해서 내려보내는 servlet이나 jsp 하나만 작성하면 되기 때문에 생각보다 간단하다. 그럼 그걸로 끝일까? Database의 like 는 매우 비용이 높은 오퍼레이션이고 대용량 데이터에는 사용할 수가 없다. 또 data가 변경될 때 lock도 걸린다. 결국 사용자가 많아지면 database가 폭주를 할 수도 있고 Database가 폭주하면 다른 중요한 서비스도 문제가 되기 시작한다. 그것 뿐만이 아니다 사용자가 입력이 지나간 뒤에 뒤늦게 결과를 보내 줄 수도 있다. 사실 헛고생 한 것이다.

그래서 좀 큰 데이터를 Database로 자동완성을 구현했다가 오픈 하는 날 서버가 다운되서 난리가 난 경우를 종종 본다.

3. 2단계에서 실패를 경험하고 나면 보통 이 방법을 사용한다. 데이터를 공백 단위로 잘라서 중복제거를 하고 별도의 테이블에 넣고 후방 like '키워%' 로 찾는 것이다 그럼 Database는 살릴 수 있지만 결국 키워드를 파는 쇼핑몰이 되어 버리는 것이다.

4. 3단계를 좀 더 쉽게 구현할 수 있는 방법은 검색엔진을 이용하는 방법이다. 키워드를 공백으로 자르고 또는 형태소 분석을 해서 주요 단어를 추출하고 불용어 처리를 하는 등 키워드 정제를 위한 기술들이 많이 포함되어 있고 후방 절단 검색의 성능도 나쁘지 않아서 꽤 대용량도 처리를 할 수 있다. 그 결과 대용량의 키워드를 파는 쇼핑몰이 되는 것이지

5. Solr 혹은 Elastic search 에 있는 suggest 기능을 이용하는 방법도 있다 Elastic search의 suggest 가 고급 기능도 많고 성능도 더 좋다. 단 데이터가 영어권일때 그렇다는 얘기이다. 한글/일본어/중국어 일 경우에는 글쎄올시다. 자동완성만 필요할 경우 배보다 배꼽이 더 클 수도 있고 커스터 마이징? 내가 원하는 데로? 생각보다 쉽지 않다. 동네 마트 가는데 김포공항가서 비행기 타는 격이랄까?

6. 대부분의 포털에서 제공하는 자동완성 기능은 키워드를 메모리에 trie 구조로 올려 놓는 방식으로 구현을 할 것이다. trie 구조는 그 엄청난 검색 속도 때문에 트래픽이 엄청난 포털에서는 당연한 선택이라고 보여진다. trie는 구조의 특성상 장단점이 극명하게 나뉘는 편이다 장점은 CPU 사용량이 작고 검색 속도가 어마어마하게 빠르다는 것이다. 단점은 속도 말고 나머지 전부? 생각보다 메모리 사용량이 많고 메모리 적제 시간이 꽤 걸린다는 것 이 문제를 해결하기 위해 각자 특별한 기술을 개발 했으리라 생각한다. 그 보다 큰 단점은 trie는 항상 전방일치만 가능하다는 점이다. 이 문제도 기술적으로 해결 할 수는 있을 것이다. ngram 방식으로 모든 경우의 수를 trie에 적재하는 방법 예를 들면 "스마트폰/마트폰/트폰/폰" 이렇게 4개를 적재하면 되기는 된다. 대신 메모리 사용량이 어마어마해진다. 또 다른 단점은 복합키워드를 처리할 수가 없다. 그렇게 때문에 상품명이나 제목 같은 문장을 검색 할 수 없고 항상 키워드 위주로 자동완성이 구현된다. 이것도 메모리로 해결 할 수 있다 모든 경우의 수를 trie로 만들어 올리면 되니까 그럼 메모리 1테라는 얼마쯤 할까? 메모리 1테라를 꽂을 수 있는 서버는 얼마나 할까? 결국 돈으로 일정부분 해결할 수가 있다는 말이지 메모리 적재에 걸리는 시간을 빼고는. 단순 키워드로 하게 되면 일단 자동완성이 된다는 생색은 낼 수 있고 메모리 사용량은 작아지고 성능도 좋다. 그래서 어떻게 쇼핑몰에서 키워드 팔게?

1~3 방법은 따로 돈이 들지는 않는다 기존에 있는 자원을 활용 할 수 있으니까 그런데 품질은 별로다. 단계가 높아질 수록 노력도 좀 들고 관리하는데 인건비도 좀 든다.

4~5 단계는 엔진을 사야된다. 6단계는 엄청나게 좋은 서버에 메모리까지 사야된다. 그렇게 돈 들인거에 비해 품질은? 사실 가성비 최악이다.

그럼 진정 해결 방법은 없는 것일까?

7. 에스나인에스의 범용 자동완성엔진(S9USS)을 이용하는 방법도 있다.

아래 데모 화면에서 자동완성의 다양한 기능을 테스트 해볼 수 있다

도서검색 데모인데 온라인 도서쇼핑의 자동완성을 쉽게 구현할 수 있다. 물론 도서가 아니라도 되는 것은 안비밀