전체 (125)
나루 이야기 (96)
나루.com 공지 (13)
키워드 이야기 (4)
나루명인 인터뷰 (12)
실무에서 진행해 본 애자일..
Experience Design / 경험 디..
s
희망 보고서
엽님의 생각
yubs' me2DAY
엽님의 생각
yubs' me2DAY
엽님의 생각
yubs' me2DAY
Total 233977 hit
Today 64 hit
Yesterday 229 hit
http://abolapia.egloos.com 에서 담아온 아볼라 님의 "6개월 전" 생각입니다.
아볼라 님은 온네트의 CTO로서 현재 연구소 조직 및 검색엔진 개발사업을 진두지휘하고 계신 분입니다.

6개월 전이라...
이제 막 온네트가 "사용자 참여기반의 검색엔진 '크로스마인드' 개발"을
선언하며
웹2.0 검색 사업에 본격적으로 진출한 시점이군요.
이른바 나루가 꿈틀꿈틀 태동을 시작한 시기, '나루 아빠'의 생각입니다. ^^
감회가 새롭군요.

사용자 삽입 이미지
검색서비스 무엇 때문에 어려운가?

어떠한 웹서비스 사이트에 가도 항상 "검색"이라는 입력창이 있게 마련이다.서비스 제공자에게서 "계륵"같은 존재라는 평을 많이 듣는 것이 바로 이 "검색"이다. 지금 어찌어찌해서 만든 검색기능이 일단 문서를 검색하기는 해 주는데, 이 기능이 영 맘에 들지 않는다. 그리고 이러한 검색기능을 좀 더 좋은걸로 바꿀려고 하면 돈도 많이 드는 거 같고, 일단 비싸기도 하다. 형태소해석기, 색인기, 랭킹 등등 알아듣긴 알아 듣겠는데, 실제 감이 잘 안잡히기도 하고... 물론 규모가 되는 쇼핑몰같은 곳은 상용검색엔진을 구매하여, 사용하기도 하나 역시 그리 맘에 들지 않는다.

그러나 자체보유 혹은 서비스 대상의 내용이 백만건 단위에 육박하게 되면, 이건 완전히 다른 문제가 된다. 검색기능때문에 사용자들이 불평을 하기 시작한다. 서비스가 더 활성화 되면 슬슬 "검색"이라는 메뉴가 화면 좌/우로 조그마하게 위치하기 시작을 한다. 그러면서부터 검색은 할 수도 그렇다고 메뉴를 없앨수도 없는 계륵이 되기 시작한다.

먼가 알 수 없는 찜찜함이 머리를 묵직하게 누르기는 하지만, 돌파구도 그리 마땅치 않고, 윗분들 설득의 논리도 세우기 어렵고.... 대부분 그냥 두자!!라고 하면서 다른쪽의 기능을 확충하기 시작한다.(*이때 대부분 BigHead를 겨냥한 낚시성 서비스가 전면에 나서게 되는 것 같습니다.)

왜 이런 문제들을 거의 모든 서비스에서 경험을 하는 것일까?

이러한 문제에 대해 필자 나름의 생각을 다음과 같이 요약해 보았다.

1. 검색엔진과 검색서비스 차이의 인식문제
2. 기본 확보 자원문제
3. 대용량/분산 문제
4. 서비스 관점 문제

각각에 대한 생각을 좀 더 기술하면...

1. 검색엔진과 검색서비스 차이 문제

검색엔진을 사던 개발하던 해서 서비스에 넣으면 그것이 검색서비스 아닌가 하시는 분들이 많은 것에 적잖이 놀란다. 이러한 것은 BBS 시스템 잘 말들면 이것이 커뮤니티서비스 된다라고 생각하는 것과 별반 차이없다고 지적하고 싶다.

검색서비스의 대상은 주로 사람이 쓰고 적은 글이다. 즉 살아있는 언어로 작성된 살아있는 내용인것이다. 간단한 예를 들면 항상 새로운 말들이 등장하고 이런말은 예외없이 검색이 잘 안된다. 이러한 단어에 대해서는 항상 신경써 줘야 한다는 것이다. 포탈사이트에서 검색서비스를 하고 계신 선배는 맥주먹으며 축구 중계보다가 별로 안 유명한 사람이 골을 넣어 내일 이슈가 될 듯하면 축구선수 이름을 등록하러 바로 사무실로 간다. 그러고는 태연히 다시 와 술잔을 기울인다. 이러한 신조어만의 문제외에도 어떻게 보여지고 어떻게 순위를 조정하느냐가 사용자에게는 확연한 차이를 만들어 내기도 한다.

그럼 구글은 왜 잘되나요?라고 되 묻는 분들 또한 많다. 구글도 신조어 넣나요? 구글이 영어권아닌 나라에선 어떤가요? 구글은 언어분석이 덜 필요한 영어권 중심의 엔진이다. 영어권이라함은 한 어절이 한 단어로 구성된 대표적 언어권이다. 우리나라는 띄어쓰기 단위의 어절이 여러 형태소가 묶여있다. 즉 명사+명사+조사, 동사+어미 등으로 조합되어 있는 것이다. 구글은 그래서 각 나라별 형태소 해석기를 붙이고, 여기에 언어권에 별 상관없는 n-gram방식도 중요한 비중으로 도입하고 있다. 즉 어느 정도 문제를 해결하고 있지만 네이버처럼 우리 입맞에 착착맞는 서비스 제공과는 약간 다르다. 네이버를 내부DB가지고 수작업으로 해결한다고 비난하는 분들도 많지만 사실 네이버가 우리 입맛에 더 맞음은 이러한 끊임없는 서비스 갱신이 있어서이다. (물론 저도 이젠 네이버가 살짝 귀찮긴 하지만요.)
검색엔진이 있으면 이를 살아 움직이기 위해서는 끊임없이 사용자와 대화하고 변경해 나가려는 노력이 있어야만 검색서비스가 된다는 것이다. 검색엔진을 어디서 사왔다고 해서 검색서비스가 잘 되리란 생각은 다시금 고려해 주셨으면 하는 생각이다.

2. 기본 확보 자원문제

검색엔진을 구성하는데 있어서 우리나라와 같은 경우 형태소해석기라는 것이 필요하다는 것은 이제 많은 분들이 알고 계신 사실이다. 그러나 형태소 해석기를 달랑 구해도 여기에 넣을 사전등의 언어자원이 없으면, 밧데리없는 핸드폰이다. 형태소 해석 알고리즘은 비교적 간단하고 요즘은 open source로도 구할 수 있는게 있다. 그런데 정작 중요한 것은 언어자원이다. 사전, 사용자 빈도, 검색질의 모음 등등 제대로 구비할려면 10 종류가 훌쩍 넘는다. 그런데 이러한 것 하나하나가 구축하거나 구하기가 만만한 것이 아니다. 꾸준히 구축하고 모아온 것이라야 한다는 것이다.

또한 웹로봇, 그외 잡다한 툴까지 고려한다면 초기 구축해야하는 기본세트가 너무 많다. 물론 이를 무시해도 되긴되나 그러자면 몸으로 때워야 한다. 서비스 운용비용이 증가하는 것이다.

3. 대용량/분산 문제

검색서비스에서 또 하나 괴롭히는 요소가 툭하면 천만건 사이즈가 몇백기가 등의 얘기를 우습게 한다. 보통 C등의 4 byte unsigned int 자료형으로는 2^32-1까지 표현 가능하다. 즉 4억개가 한계이다. 우리가 이건 넘을리 없다고 생각하고 짜는데 가뿐히 넘는게 검색이다. 또한 보통 FileSystem에서는 2GB 혹은 4GB를 넘는 한개의 화일은 만들 수 없다. 그런데 이것도 너무 너무 쉽게 넘는다. 그리고 검색결과를 주는 것도 1초 넘으면 짜증내 한다. 서비스 대상을 넓히면 좋은데 이렇게 하기가 사실 너무 쉽지 않은 것이다. 하드웨어가 싸고 좋아지긴 했다고하나 아직도 한대의 기계에서 처리하기엔 너무 많은 시간이 걸린다. 즉 분산처리까지 고려해야하니 프로그래밍 난이도가 올라가고, 그래서 가뿐히 포기하게 된다. 이런건 네이버나 구글이 해야지라고 하면서 말이다. 그러니 서비스대상 boundary는 제한되게 되어, LongTail이 소외되면 마음대로 서비스의 날개를 펼치기 어려운 것이다.

4. 서비스 관점문제

검색이라는 것은 사실 BigHead, LongTail의 관점에서 보면 LongTail 처리에 더 맞는 서비스라 할 수 있다. BigHead도 물론 검색을 해 주어야 하는 것임에는 틀림없지만 사람들이 검색서비스에 신뢰를 보내게 되는 경우는 어? 이런 것도 여기에 있었네 하는 때가 훨씬 많다. LongTail과 검색은 상관없는 것이 아니라 상당히 밀접히 연결되어 있다는 것이다.

하루하루 쏟아지는 내용이 많고, 이것을 사용자에게 제시함에 있어 필수 불가결한 서비스는 바로 BigHead에 대한 제시이다. 흔히 생각하는 Top10식의 접근이다. 이는 물론 아주 많은 사용자에게 다가갈 수 있어 필수불가결하다. 그러나 검색은 이 BigHead 너머에 있는 LongTail까지도 쳐다보고 검색을 잘 해 줄수 있어야 한다. "왕의 남자"를 사용자에게 제공하는 것은 서비스 전면에서 수작업으로 할 수 있다. 그리고 이는 즉각적인 효과를 발휘한다. 그러나 이 서비스에 "maria ozawa"를 쳐도 화끈하게 정보를 제공해 줄 수 있다면, 이러한 서비스를 사용자가 "신뢰"하게 되고, 다음의 정보요구에도 또 이 서비스를 이용하려고 할 것이다.

검색은 LongTail에 있는 내용을 손쉽게 사용자에게 보여줄 수 있어야 하고, 이러기 위해서는 앞의 1,2,3의 문제에 아낌없는 지원이 있어야 한다. 그러나 대부분 눈앞에 보이는 BigHead에 집중하게 되고, 그러니 모든 서비스가 대동소이하게 바뀌는 것이라 생각된다.

BigHead를 잘 검색해 주는 것은 기본이고, 사용자에게 신뢰를 주는 것은 LongTail에의 검색이다. 검색서비스가 BigHead를 잘 처리해 주는 것이라 생각하는 것은 문제의 반만을 보는 것이라 생각한다. BigHead에 손맛을 주고 LongTail의 검색이 향상되도록 서비스를 구성하는 것이 서비스를 차별화하게 하는 요소라 생각된다.(* BigHead의 손맛으로만 서비스가 얼마나 버틸 지는 Technorati에 어느 순간 블로그가 폭증하면서 서비스가 우왕좌왕 된 시점을 생각하시면 좋은 예가 될듯하네요. Technorati는 이러한 문제 해결을 위해 Discovery라는 메뉴가 보강됐네요.)

웹2.0을 통해 참여/공유/매쉬업등으로 수 많은 contents를 손쉽게 Aggregation할 수 있는 방향으로 나아가고 있는 듯하다.(물론 지금은 미흡하지만) 이러한 때에 필요한 것은 여러분이 생각하시는 서비스가 과연 LongTail에는 어떻게 접근하게 할지 즉 어떻게 검색(혹은 추천, 제공)되게 할지를 고민하는 것이 필요하다 생각된다.

by 아볼라 박영찬
Trackback Address :: http://blog.naaroo.com/trackback/8
Tracked from 빨간우체통 | 2007/03/07 20:38 | DEL
<P>롱테일(Longtail) 은 여기저기서 많이 사용해서 아주 자세히는 아니지만</P> <P>개념상의 의미는 어느 정도 이해하고 있다.</P> <P>그리고 Bighead 역시 롱테일을 이야기할 때면 같이 빈번하게 등장하는 </P> <P>용어중에 하나다.</P> <P>그런데, 난 아직 BigHead 용어는 별로 친숙하지도 못하고,</P> <P>표면적인 의미 이상의 개념적 의미를 알지 못해 받아들이지도 힘든 용어중 하나다.</P> <P>&n..

Name

Password

Homepage Secret