웹 서비스에서 검색기능 필수인가? 선택인가?

형식적이지만 필요한 검색기능, 어떻게 만드는게 좋을까?

iamday.net을 자주 이용하시는 분이라면 아마 잘 알고 계시겠지만 얼마전부터 검색 서비스를 제공하고 있습니다. (관련 공지사항 참고하기) 사실이게 만들까 말까.. 고민을 많이 했습니다.

유저가 아이엠데이의 다양한 컨텐츠 이용을 쉽게 할 수 있게 한다는 점에서는 의미가 있지만 컨텐츠나 서비스 특성상 검색 사용 빈도가 높지 않을 것을 예상하고 있었기 때문에.. 도입을 망설였던게 사실입니다.

개편 전에도 기본적으로 검색 기능을 제공하기는 했습니다. 하지만 혁식적인 제공이 더 강했다고 생각합니다. 

이런 이유로 검색 기능 도입시 검색 기능을 만들 필요가 있을까란 고민을 많이 했던 것 같습니다. 포털 같이 컨텐츠가 다양하거나 많은 것도 아닌데 굳이 컨텐츠 검색 기능이 필요 할 것인가? 란 의문이 있었기 때문입니다. 

하나의 예를들어보면 다소 성격이 다르지만 블로그 같은 경우는 검색 기능이 절대적으로 중요한 서비스는 아닙니다. 하지만, 하나 같이 검색 기능을 제공하고 있습니다. 있으면 좋지만, 없어도 그닥 불편함을 느끼기 힘든데 왜? 만든 것인가란 본질적 질문이었습니다. 

일반적인 검색 서비스 사용 프로세스

제가 생각하는 검색의 프로세스는 컨텐츠 구독후 추가적인 정보 확인이나 더 많은 정보 확인이 필요한 경우 이용하게 됩니다. 예를들어 글을 쓰거나 시장 조사를 하다가 필요한 자료를 찾지 못하면 검색 기능을 이용하게 되죠.

그런데 대게 이런경우 컨텐츠 DB가 많은 포털이나 구글 같은 전문 검색엔진을 이용하게 됩니다. 

하지만, 아시는 대로 아이엠데이에는 이런 컨텐츠가 많지 않습니다. 어플리케이션 컨텐츠는 포털이나 구글에서 검색해도 나오는 컨텐츠고 차별화 된 컨텐츠라고 해봐야 주제별 어플리케이션을 모아 놓은 바스켓, 어플리케이션 리뷰, IT 뉴스와 칼럼 정도입니다. 왠만한 사이트에 비해서는 꽤 많은 DB이지만, 다양한 정보를 입맛에 맛게 골라보기엔 다소 부족함이 있는게 사실입니다.

전문적인 검색 서비스가 아닌 다음에야 일반적으로 서비스 특성에 맞는 컨텐츠만 있으면 됩니다.

그럼 이쯤에서 왜? 검색을 만들어야 하는가? 이런 의문이 생기겠죠. 개인적으로 생각하기에는 검색은 단순한 정보을 찾는 서비스가 아니라 어떤 명확한 목표를 만들어 줘야하는 것 같습니다.

검색 기획의 목표가 되어야 하는 것은 뭘까?

사실 검색 기획은 개발의 목표와 방향이 매우 다릅니다. 기획 역시 인터페이스 기획이 중요한 것이 아니라 코어단에서 돌아가는 엔진과 맞물리는 일종의 시스템 설계와 기획이 더 중요한 것이지요.

검색기는 기본으로 크롤러 + 엔진 + 형태소 분석기가 큰 골격입니다. 시스템을 어떻게 설계하느냐에 따라 색인을 크롤러 단에서 처리 할 수도 있고 크롤러 수집후 형태소 분서기를 거쳐 색인을 진행 할 수도있습니다.

중요한건 최근 구글의 지식 그래프를 보시면 각 검색어와 연관 된 인물, 도서, 지역 정보등을 보여줍니다. 가장 기초적인 수준의 시멘틱스 기술인데.. 사용자가 요구하는 바에 가장 적합한 데이터를 제공하는 목표를 가지게되지요. 이런 경우 위에 언급한 기본적인 검색엔진에 유관 데이터를 평가하는 엔진을 다시 추가하거나 기존 엔진을 확장하는 형태등으로 개발을해야 합니다.

확장성을 고려하면 기존 엔진에 API 형태로 유관 데이터를 전문적으로 처리하는 별도의 지식 엔진과 연동시켜 데이터를 불러오는 형태로 설계될 수 있습니다. 이처럼 시스템 기획은 접근법과 목표도 분명해야 하고 기술적 밑바탕도 있어야해서 쉬운 작업은 아닙니다.

일반적인 검색엔진은 사용자가 요구하는 정보를 가장 정확하게 뿌려주면 됩니다. 문제는 일반적인 서비스에서 어떻게 그 목표를 정의하냐 이지요? 공통의 목표는 분명 사용자가 요구하는 데이터를 찾는 일이지만, 그것 이외의 무었인가가 있어야 한다는 생각입니다.

예를들면 검색어에 대한 답변을 가장 잘해줄 수 있는 사람을 찾는다던지 하는 말이지요. 그런데 아이엠데이는 이런 검색의 목표가 사실 명확치 않아서 고민을 했습니다.

기본적인 검색 목표에 단순화 시킴..

목적이나 목표는 명확했지만, 막상 그런 목표를 실행하기는 쉽지 않았습니다. 그리고 현재 아이엠데이 서비스가 너무 다양한 (모바일 어플, IT 뉴스, 블로그 뉴스, 큐레이션) 목표점을 가지고 있어서 이런 각 서비스의 특징적 컨텐츠를 하나로 모아보는데 최적화 하자는 결론을 얻었습니다.

물론, 고민 과정에는 검색 매거진, 검색어에 대한 관련도 높은 인물 중심 검색, 질답을 바로 할 수 있는 Q&A형 검색등도 고민했지만 개발 기간과 아이디어 구체화등의 이슈로 일단 컨텐츠 통합에 목표를 뒀던 것 같습니다. 

아래 이미지는 제가 기획한 검색 화면입니다. 목업 수준은 넘어서지요. 이 목표를 실현 시키기 위해 고민한 UI는 F형 그리드입니다. 한국에서는 네이버가 1~2년전 검색 개편하면서 내세워서 화재가 되었는데.. 실제론 해당 이론도 이미 해외에서는 아주 오래전에 HCI 관련 분야등에서 연구되던 내용입니다.

네이버는 실제로 이것을 UX 팀에서 실측(아이트래킹 같은 측정 장비에의해..)해서 실측한 것 같습니다.

F형 구조의 핵심은 이것입니다. 우측에 배치 된 컨텐츠의 집중도가 매우 낮고 좌측과 상단으로 시선 흐름이 유지된다는 겁니다. 즉, 눈의 시선 흐름이 좌측 상단에서 우측 상단으로 흐르고 다시 그 아래 컨텐츠를 좌측에 시선을 두고 내려가면서 우측으로 조금씩 이동한다는 개념입니다.

[검색 개편전]

네이버 검색 개편전 화면으로 굳이 형태를 이야기하자면 I형 그리드로 먼저 상단 메뉴를 훓은뒤 가운대중심으로 컨텐츠를 소비하는 구조입니다.

[검색 개편후]

네이버 개편 후 모습으로 F형 그리드로 시선 흐름에 따라 좌측에 시선을 유도하면서 가장 활동도와 선호도가 높은 메뉴를 배치시켜 시선 이동후 메뉴를 클릭하면 바로 우측에 컨텐츠 소비를 유도하는 형태로 바뀌었습니다.

아마 UX를 공부하는 분들에겐 교과서적인 트랜드 흐름을 볼 수 있는 대목으로 해외에서 조사 된 자료들을 보면 대부분 이런 시선 흐름을 유지하고 있는게 특징입니다. 또, 네이버가 한국에서 과점 사업자라 주목 받았지만, 기본적으로 구글이 가장 먼저 이런 F형 그리드를 시도했고 우측의 컨텐츠 영역 활용을 위해 인기 검색어나 연관검색어 같은 날개를 달게된 겁니다.

F형이지만 엄밀히 말하면 구조적으론 H형에 더 가깝게 변하는 거지요. 설명이 길었는데.. 저희도 벤치마크란 미명아래.. 이런 과학적이고 논리적인 결과물을 노출하는 UI 구조를 따라해 현재의 구조를 만들었습니다.

검색 기술은 어떤걸 이용했나?

아이엠데이는 개발 인력이 많지 않아서 검색 엔진 도입을 오픈 소스 기반으로 했습니다. 루씬 기반으로 검색에 활용가능한 소프트웨어가 있는데 그중에서 Nutch와 Solr가 있습니다.

Nutch는 준 검색엔진 수준으로 형태소 분석기와 튜닝을 어떻게 하느냐에 따라 왠만한 상용 검색엔진의 퍼포먼스와 성능, 퀄리티를 만들어 낼 수 있습니다. 하지만 이 역시도 아이엠데이에서는 개발에 부담이 있어서 Solr를 활용하는 방안을 찾게됬습니다. (오픈 소스 검색 엔진이 꽤 있습니다. 여기선 이것만 소개하겠습니다. 한국에도 많이 알려져서요)

Solr로 만드는 아이엠데이 검색엔진의 특징
Solr는 아파치 루씬 프로젝트에서 최상위 레벨에 있는 인기 검색 프로젝트입니다. 오픈 소스로 데이터베이스 통합과 텍스트 검색, 문서 검색 (워드, PDF.. 등) 및 질리 정보 검색등을 제공하고 동적 클러스터링 지원과 분산 서비스 기반의 인덱스 검색도 가능합니다.
 
특히 자바로 작성된 톰캣 같은 서블릿 컨테이너 내에서 독립적 실행이 가능하고 루씬 라이브러리를 사용하고 있는 것이 특징입니다.

Solr의 설명을 보면 엔터프라이즈급 오픈 소스 검색 플랫폼을 지향하고 있다고 소개되어 있습니다. 실제로 한국에서도 상당수 업체가 Solr를 응용하고 있고, Solr의 기반이 되는 루씬 라이브러리를 이용한 검색기가 MS 오피스에 탑제되어 있기도 합니다. 대용량의 제대로 된 검색엔진으로 개발하려면 아날라이저 튜닝과 형태소 분석기 적용등의 디테일한 개발이 필요하니다. 여기에 분산 처리를 위해 하둡등 다양한 솔루션을 추가로 세팅 할 필요도 있습니다.

아이엠데이는 아직 이정도 수준의 검색이 필요 없고 컨텐츠도 제목, 내용, 태그등을 정확하게 구분하고 있습니다. 더 정밀하게 하려면 형태소를 구축해야 하지만, 저희는 그저 화이트 스페이싱 처리수준에서 인덱스화 시키고 있습니다. 오픈 소스로 형태소 분석기도 나와있고, 형태소 사전 만드는 것도 할 수 있지만 지금 단계에서 필요하지 않다는 결론을 얻었습니다.

위 결과처럼 뉴스 (IT 토크의 전체 컨텐츠) + 앱스 (앱차트, 바스켓, 앱리뷰) + 스크랩북 + 블로그 RSS 정보를 각각 인덱싱 처리해 뿌려주고 있습니다.

검색 데이터가 많지 않아서 정확도가 떨어지지만 자체적인 분석으로는 데이터가 있을 경우 일반적인 키워드 검색으로도 일정 수준 이상의 정확도를 보여줍니다. 형태소 분석기가 없는데도 결과물은 좋게 보이는 것은 명확한 키워드가 될 수 있는 제목과 태그가 있기에 이 부분에 대한 가중치를 높여서 정확도를 높인 것입니다.

이런 이유로 어플리케이션 데이터의 경우는 다소 정확도가 떨어지는 부분이 있지만, 장기적으로 서비스를 계속 튜닝해 나갈 것이기에 문제가 되는 요인은 아니라 생각하고 정확한 제목을 입력하면 어느정도 결과치를 뽑아주고 있기에 문제되는 수준은 아니라는 판단입니다.

검색 페이지 구성과  특징은?
사실 검색엔진 구성에 있어서 소프트웨어도 중요하지만 검색 DB와 검색 결과를 보여주는 화면에서의 UI가 큰 영향을 미칩니다. 검색 정확도는 엔진 튜닝과 분석기 + 형태소 사전등의 외부적 요인을 지속적으로 관리하고 DB를 추가로 쌓아야 하는 문제가 있기 때문에 단기간에 퀄리티를 높이기 힘든 부분이 있습니다.

또, 이부분에서 문서와 사용자가 요구한 키워드에 대한 요구도를 분석하는 알고리즘 개발이나 튜닝에 따라서도 성능이 크게 차이가 납니다. 많은 검색 결과를 얻을 수 있는 키워드로 구글과 네이버를 검색해 보면 구글이 요구하는 정확도에 맞는 문서를 더 잘 찾아주는 경우가 있는데.. 이게 바로 기술력인 겁니다.

이 부분은 결국 장기적인 시간과 DB 개발인력이 꾸준히 튜닝하고 향상 시켜야 하는 부분이라 나머지 요인에서는 결과물을 어떻게 뿌려주느냐가 중요해집니다.

1) 검색결과 안내
    검색 데이터가 얼마나 나왔는지 알려줍니다.

2) 검색 메뉴
    일종의 소팅 메뉴로 통합 검색에서 앱스, 뉴스, 스크랩, 블로그를 한꺼번에 표현해 준다면..
    검색 메뉴에서는 각 메뉴 클릭시 해당 메뉴에 대한 결과물만 노출합니다

3) Side + 검색랭크
    검색 랭크는 아이엠데이에서 가장 인기 있는 검색 키워드를 노출해주며 최근 한달간 정보를 노출
    SIDE 메뉴는 인기스크랩북 + 인기 뉴스를 노출
    연관 검색어는 아직 오픈 안된 상태

4) 검색결과 페이지
    검색 결과 페이지는 통합 검색 형태로 구성하며 앱스, 뉴스, 스크랩북, 블로그 형태로 구성됨
    결과물은 최대 앱스 3개, 뉴스 5개, 스크래북 3, 블로그 5개씩 노출되며 검색 데이터에 따라 달라짐

검색 서비스를 만들면 좋은 이유?
기본적으로 DB 검색에 대한 부담이 줄어듭니다. DB 검색의 경우 쿼리를 이용해 디테일하고 다양한 검색 결과를 얻을 수 있지만 쿼리를 얼마나 요구하느냐와 요구 데이터량에 따라 검색 속도는 물론 DB부담으로 서비스 이용에 지장을 초래합니다.

검색 기능이 없으면 모르겠지만 기본적으로 DB가 아닌 별도의 색인 데이터를 만들어 색인 요청에 의한 검색 결과를 뽑을 수 있게 만드는 것이 중요합니다.

또, DB 검색에 비해 속도는 물론 다양한 데이터 활용이 가능합니다. 특정한 영역에서 태그나 연관 키워드를 뽑아 관련 데이터를 뽑아낼때도 DB 데이터에 질의후 데이터를 파싱해 파일처리하는 것보다 유리합니다. 특히 Solr의 경우 지속적으로 버전업되고 있고 안정성과 설치 및 개발이 편리하게되어 있어 소규모 개발사에 적합 합니다.

기술적으로도 쉽게 기존 플랫폼에 연동도 가능하고 하둡등의 분산 처리시 스템과 연동하면 막강한 확장성과 대용량 검색 시스템 구축도 가능합니다. 물론, 구축이 쉽다는 것이지.. 운용성이 뛰어난 것은 아닙니다.

실제 상용 검색엔진을 보더라도 엔진 설치와 세팅보다. 데이터 수집과 시스템 안정성 확보, 각 서비스에 맞는 디테일한 세팅 조정 및 엔진 튜닝이 전체 프로젝트에서 아주 큰 비중을 차지합니다.

저희는 아주 기초적인 수준으로 실제 아이엠데이 상용 서비스에 이것을 붙이고 아임엠데이 컨텐츠를 검색해 볼 수 있게 했다는 것에 의의를 두고 있습니다. 장기적으론 형태소 엔진이랑, Solr 엔진을 이용한 각종 컨텐츠 평가와 분석 기능을 강화 할필 요성이 있습니다.

결론, 필요 없다고 생각하지 말고 필요성을 찾아보자..

인스타 그램 같은 서비스에서는 검색은 필수적인 서비스가 아닐 수 있습니다. 대부분 실시간성으로 소비하고 과거의 데이터는 잘 찾지 않기 때문이죠. 하지만 트위터는 인스타 그램에 비해 과거 컨텐츠 활용 빈도도 높고, 검색 데이터 장사에도 활용도가 높습니다.

이런 것을 포함한 여러 이유로 트위터가 검색엔진 개발에 공을 들이고 있는 것이지요 .

중요한 것은 블로그에 검색 기능이 달린 것 처럼, 현재 운영하는 웹서비스에 검색 기능이 있다면 그대로 사용해야 한다. 업그레이드가 필하다면 다양한 가능성을 생각하고 고민해야 할 것이고, 만약 없다면 정말 필요가 없는지.. 단 한사람이라도 사용한다면 만들어야 하는 것은 아닌지 고민해야 한다.

검색도 일종의 습관이 필요한 기능이다. 아무리 검색 기능이 필요 없는 서비스라도 검색 기능이 있다가 없는 것과 없다 있는 것에는 큰 차이가 발생하니 말이다. 단순하게 필요성이 없다고 생각하지 말고 단 한명이라도 이용 할 유저가 있다면 더 많은 유저가 이용 할 수 있는 방법을 찾아보길 권하겠다.

만약 단 한명이라도 이용 할 유저가 없고.. 유지 하는 것 자체가 부담이라면 없애는 것도 나쁘진 않겠다. 거기에 집중 할 리소스를 더 좋은 영역에 활용 할 수 있기 때문이다.