brunch

매거진 서비스 기획 체크리스트

라이킷 28 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 제나로 Mar 05. 2024

검색 서비스 기획 체크리스트

검색 서비스 기획자가 고민해 보면 좋을 것들

검색, 꼭 필요할까?

서비스에 검색 기능이 있으면, 사용자는 원하는 정보를 빠르게 찾을 수 있습니다. 서비스 내 다양한 콘텐츠를 쉽게 찾을 수 있으면 사용자 만족도를 높이고 이탈률을 낮출 수 있습니다.

하지만 편익만큼 비용이 발생합니다. 우선, 서버 인프라 비용이 가장 큽니다. 서버 간 통신과 사용자 요청에 대한 네트워크 인프라 비용이 발생하고, 비용은 데이터 전송량 등에 따라 결정됩니다. 서버 개수도 확장해야 합니다. 검색 엔진은 대용량 데이터를 처리해야 하기 때문에 트래픽과 요청의 양에 따라 여러 대의 서버가 필요할 수 있습니다. 검색 엔진 솔루션 비용도 발생하고요, 오픈 소스를 사용한다고 하더라도 구축이나 유지보수 비용이 발생합니다.

보통은 한정된 리소스로 개발과 운영을 하기 때문에, 검색처럼 큰 기능을 넣으려면 기획과 설계 단계에서 작업규모와 비용을 잘 산정해야 합니다. 대부분 팀에는 검색 전문가가 있는 게 아니라, 한 사람이 여러 종류의 작업을 하는 경우가 많으니까요. 검색 작업에 신경 쓰는 만큼, 다른 작업을 덜 할 수밖에 없습니다. 아니면 사람을 더 뽑는 만큼 비용이 발생하니까요.

그럼에도 불구하고 우리 서비스에 검색 기능을 넣겠다고 결정했다면, 어떤 것들을 점검해 보면 좋을까요?

사용자 검색 경험 최적화 체크리스트

- [ ] 검색 UI를 상단의 눈에 띄는 곳에 배치했나?

- [ ] 그렇지 않았다면, 타당한 이유가 있을까?

- [ ] 우리 서비스에서 텍스트를 직접 입력하는 방법 외에도 검색을 이용할 수 있을까?

- [ ] 우리 서비스는 검색 결과를 실시간으로 업데이트해서 보여주고 있나?

- [ ] 우리 서비스는 자동 완성 기능이나 검색어 제안 기능을 제공하는가?

사용자 경험을 얼마나 최적화해야 할까

[전자정부 웹사이트 UI/UX 가이드라인] 일부. 검색을 메인메뉴보다 우선하여 강조할 수 있다.

사용자는 검색을 통해 서비스에서 필요로 하는 정보를 효과적으로 찾을 수 있어야 합니다. 검색 속도가 빠르고, 결과가 정확한 것도 중요하지만 얼마나 편리하게 이용할 수 있는지도 함께 고려하면 좋습니다.

일반적으로 검색 창은 상단의 눈에 띄는 위치에 배치합니다. 검색 창에는 검색 필드와 검색 버튼이 포함되어야 하고요. 필요에 따라서, 사용자가 검색어를 입력하는 동안 자동 완성 기능이나 검색어 제안 기능을 제공할 수도 있습니다. 검색은 누구나 이용할 수 있어야 하기 때문에, 보조 기술(음성인식 등)을 사용하는 사용자들도 편리하게 이용할 수 있어야 합니다. 다양한 화면 크기에 대응하는 반응형 디자인은 당연히 고려되어야 하겠죠. 사용자가 검색어를 입력하는 동안 실시간으로 검색 결과를 업데이트해서, 사용자가 검색어를 수정하지 않고도 관련된 검색결과를 확인할 수 있도록 제공할 수도 있습니다.

이 모든 것들을 굳이 다 해야 될까요? 저는 굳이 다 해야 된다고 생각합니다. 검색은 결제처럼 필요에 의한 기능이 아닌, 편의에 의한 기능이라고 생각하거든요. 이왕 쓰기 편하려고 만든 기능이면 '편리함'에 중점을 둬야 하지 않을까요?

자동 식단 기록앱 <스프린트>의 검색 화면

앱 <스프린트>에서는 형태소 단위로 정확한 검색 결과를 제공합니다. '검색' 버튼을 눌러서 검색을 한 것이 아닌데도, 비동기식으로 데이터를 요청해 검색 결과를 실시간으로 확인할 수 있는 모습입니다.

(형태소 검색 개념은 검색 서비스 기획 기초 2편에서 다루었습니다.)

하지만 비동기식으로 데이터를 요청하기 어려운 경우도 있습니다. 일반적으로 사용자와의 상호작용이 많은 서비스가 그에 해당하는데요, 서버의 부하를 초래할 수 있는 대용량 데이터인 사진, 동영상 등의 미디어를 제공하는 서비스라면 실시간으로 검색 결과를 제공하기 부담스러울 수도 있습니다. 또, 사용자의 네트워크 연결이 불안정하거나 느린 지역에서 서비스하는 경우라면 네트워크 오류나 시간 초과 등의 문제로 사용자 경험이 나빠질 수 있습니다. 그 밖에도 민감한 개인정보나, 금융정보를 다루는 경우라면 보안상의 이유로 신경 쓸 점들이 있겠죠.

<스프린트>에서는 자동 완성 기능도 제공합니다. 사용자가 "우유"를 입력하는 동안, 자동 완성 기능으로 "빙그레 우유", "파스퇴르 우유" 등과 같은 관련된 검색어를 제안했죠. 사용자가 입력한 일부 문자열을 기반으로 가능한 완성어를 추천하는 로직입니다.

이렇게 완성어를 자동으로 제시할 수도 있고, 검색어 제안 기능을 도입할 수도 있습니다. 검색어 제안은 일반적으로 사용자의 이전 검색 기록, 인기 있는 검색어, 트렌드 등을 기반으로 합니다. 그러면 이어서, 사용자의 개인화 측면에서 좀 더 알아보겠습니다.

사용자 검색 결과 개인화 체크리스트

- [ ] 우리 서비스는 사용자에게 최대한 많은 정보를 제공하는 것이 좋을까?

- [ ] 우리 서비스는 사용자에게 개인화된 정보를 제공하는 것이 좋을까?

사용자의 데이터를 활용하자

개인정보 보호에 대한 규정을 준수하면서, 사용자의 데이터를 수집하고 분석해 검색 여정에 활용할 수 있습니다. 사용자의 검색 기록, 프로필 정보, 행동 패턴 등의 데이터를 기반으로 개인화 알고리즘을 개발할 수도 있습니다. 사용자의 관심사나 선호도를 고려하는 것인데요, 이를 바탕으로 검색 결과를 필터링하거나 검색 결과의 순위를 조정해서 보여줄 수 있습니다.

B2C 판매 사이트 <알리익스프레스>

이 방법은 커머스 서비스에서 아주 많은 사례를 찾아볼 수 있습니다. <알리익스프레스>에서 좋은 예시를 찾아볼 수가 있었는데요. 제 주문내역과 장바구니, 검색기록을 기반으로 추천 검색어에 "아이폰 케이스", "키링" 등을 보여주고 있습니다. 아마 프로필 정보의 주문 주소, 언어 설정 등으로 한국인 태그도 포함시킨 것 같습니다. 디테일에 정말 소름 돋을 정도입니다.

그런데 모든 사용자가 동일한 유형의 개인화를 원하지는 않습니다. 사용자의 상황과 요구에 따라 다양한 개인화 옵션을 제공하면 좋습니다. 예를 들면, 어떤 사용자는 최근 검색 기록을 기반으로 더욱 개인화된 검색 결과를 얻을 수도 있지만, 다른 사용자는 더 일반적인 검색 결과를 원할 수도 있습니다.

도서쇼핑몰 <교보문고>

tvN <알쓸신잡 3>에서 김영하 작가님은 '인터넷으로 책을 사는 것과 서점에 가서 책을 사는 것 사이에 차이가 있느냐'는 질문에 '서점에 가면 예기치 못했던 책을 발견하고 사게 된다'는 대답을 했습니다. 이 대답은 제가 위에서 언급한 '개인화를 원하지 않는 사용자'의 사례에 해당할지도 모릅니다.

<교보문고>는 검색창에서 '지금 많이 찾는 상품', '주목할 만한 신간 추천', '실시간 검색어' 기능으로 다른 사용자들이 관심 있어하는 상품(책)을 보여줍니다. 검색 정책을 설계하는 데에 선택과 결정이 필요한 때입니다. 사용자에게 무조건 많은 콘텐츠를 추천하는 것이 좋을지, 사용자에게 개인화 로직이나 운영 노하우로 특정 정보들을 간추려 보여주는 것이 좋을지 정해야 합니다. 양쪽 다 장단점이 있습니다.

검색 알고리즘 퀄리티 체크리스트

- [ ] 검색 기능에 필터를 넣는다면 어떤 기준이 필요할까?

- [ ] 검색 결과를 분석해 보자. 결과가 잘못되었거나 이상하진 않았나?

- [ ] 검색 목표를 확실히 하자. (클릭률을 높이는 것, 정확성을 높이는 것, 이탈을 최소화하는 것 등)

데이터 스키마 디자인, 누가 어떻게 해야 될까?

검색창도 만들고 검색결과도 나오게 만들었는데, 검색 알고리즘이 영 별로면 검색 결과가 만족스럽지 않습니다. 검색 알고리즘은 검색 기획과 개발의 핵심입니다.

이렇게 중요한 검색 알고리즘을 최적화하기 위해서는 알고리즘을 세부 조정하고, 데이터 인덱싱을 최적화해야 합니다. 알고리즘은 토큰화, 동의어 처리, 유사성 측정 방법을 통해 세부적으로 조정할 수 있습니다. 데이터 인덱싱은 데이터 구조와 스키마를 효율적으로 디자인하고, 검색 쿼리를 최적화함으로써 개선할 수 있습니다. (조금씩 복잡해지는데요.. 일단 기획자의 시선에서 선별하겠습니다.)

검색 알고리즘, 다시 말해 검색 성능과 검색 결과의 정확성에 큰 영향을 미치는 건 데이터 구조와 스키마 디자인입니다. 데이터 스키마 디자인은 주로 DBA가 담당하는데요, DBA가 없는 조직에서는 시스템 아키텍처와 관련이 있는 개발자가 대신합니다. 또는 기획자가 스키마 디자인에 참여할 수도 있습니다. DBA 또는 개발자가 검색 알고리즘을 손본다고 할 때, 기획자는 어떤 것을 요청해야 할까요?

사용자의 요구사항을 명확히 하자

개발진 가운데, 사용자와 가장 맞닿아 있는 것은 누가 뭐래도 기획자입니다. 우리는 사용자가 사용해줘야 하는 서비스를 개발하는 사람들인데요, 그렇다면 사용자들이 원하는 검색 옵션을 개발진에게 전달하는 것이 우리 기획자들의 역할입니다.

예를 들어, 커머스 서비스의 기획자는 사용자들이 상품을 더 쉽게 찾을 수 있도록 검색 기능 개선을 시도할 수도 있습니다. 그러기 위해서는 사용자들이 검색할 때 특정 필터링 옵션을 원하거나, 앞서 이야기했던 자동 완성 기능, 검색 결과를 실시간으로 업데이트하는 기능을 구축하거나 고도화할 수 있습니다. 우리 서비스의 검색 기능에 필터를 넣는다면 어떤 기준이 필요할지 생각해 볼 수 있습니다. 커머스 서비스라면 상품의 종류, 상품의 색상, 가격, 구매 후기 별점 등으로 필터를 추가할 수가 있겠습니다.

우리 서비스의 검색 기능에서 이미 필터를 제공하고 있다면, 어떤 것을 살펴볼 수 있을까요? 현재 검색 결과를 분석해 보고, 특정 상품 카테고리의 검색 결과가 다른 카테고리보다 더 많이 나오거나, 일부 상품이 잘못 분류되어 있어서 사용자가 찾기 어려운 경우가 있을 수도 있습니다. 검색 결과의 정확성이나 속도에 문제가 있어서 사용자들이 검색에 불만족스러운 상황일 수도 있고요. 이런 경우에도 검색 알고리즘을 개선하거나, 변경할 필요가 있습니다.

검색 알고리즘을 테스트해 보자

사용자 피드백이 부족하다면, 피드백을 수집하기 위해 A/B 테스트를 진행해 볼 수도 있습니다. 사용자들에게 두 가지 다른 검색 알고리즘을 제공하고, 어떤 것이 더 나았는지 검증해 보는 방법인데요.

여느 A/B 테스트를 할 때처럼, 확실한 목표를 설정하는 것이 중요합니다. 검색 결과를 정확히 하고 싶다거나, 사용자의 클릭률을 증가시키거나 하는 목표를 정할 수 있습니다. 어떤 목표로 정할지 잘 모르겠다면, 우리 팀에서 추구하는 방향성을 상기해 봐도 좋겠습니다. 테스트 지표로는 앞서 말한 클릭률, 정확성, 이탈률 등을 고려해 볼 수 있겠습니다.

이렇게 테스트 목표와 지표를 설정하고, 테스트 기간을 적절하게 설정해서 충분한 데이터를 수집합니다. 그리고 데이터를 살펴보거나, 사용자에게 피드백을 얻어서 어떤 알고리즘을 적용시킬지 결정합니다.

검색 기획 체크리스트