미Chill 듯이 느린 검색 개선기 - 1

🕵🏻 검색 기능 느려도 너무 느려!

오늘도 평화로운 어느 날, 평화롭게 File-Service를 리팩토링 하던 저에게 아주 놀라운 일이 생겨버렸습니다.
저희 서비스의 검색을 개선하라는 업무가 내려온 것인데요.. NoSQL에 아직 익숙치도 않은 제게는 너무 큰일이였지만 이건! 분명 나에게도 좋은 기회야! 라고 주먹을 불끈 말아쥐며 이렇게 주니어 한 명이 갈리는 눈물의 투쟁기가 시작됩니다.

🙄 현재 검색 무엇이 문제일까?

현재 검색은 여러가지 애로사항이 있습니다.

1. 숫자 검색이 잘 되지 않는다 -> 10000과 10,000을 다른 데이터로 취급한다.
2. 검색 속도가 너무 느리다 -> 검색을 시도하면 3초 이상이 경과해야 데이터를 볼 수 있다.
3. 이모지로 검색이 되지 않는다.
4. 한영키가 눌린채로 잘못 검색하면 검색이 되지 않는다 -> 쿠팡을 znvkd으로 검색
5. 띄어쓰기를 포함한 키워드가 잘 검색되지 않는다 -> 어두운 그로 검색하면 어두운 그림자 안나옴
6. 검색은 정확도 순이 아니라 생성일 순으로 정렬된다.

제가 느끼는 애로사항이 꽤나 많았기에 이 문제를 어떻게 개선하는 것이 좋을지 많이 고민하며 하루 하루를 지내왔습니다.

😮‍💨 검색 기능 어떻게 개선할 것인가?

위에서 문제를 정의했고, 이제 이 문제를 어떻게 풀어나갈지 정하기만 하면 될 것 같았는데.. 저는 이제서야 알아버리고 말았습니다. 문제를 어떻게 풀어낼지 정의하지 못하고 방향성을 잃는다면 문제를 이해하지 못했다는 것을요 🫤

기존 시스템을 어디서부터 어떻게 개선할지 전혀 의사 결정이 되지 않고 아무것도 할 수 없었습니다.
마치 저에게는 이 검색 개편이 풀기도 어려운 불가사의한 수학 문제로까지 느껴지기 시작했어요.

그렇게 수많은 삽질 중 첫 삽질이 시작됩니다.

😈 삽질 1 - 아키텍처 먼저 선정하기

팀내에서도 검색에 대해 대략적인 개선안이 나왔습니다.
어떤 개선안일까요? 바로 바로! Solr -> ES(Elastic Search)로 검색 엔진을 변경하자는 것입니다.

팀에서는 Solr를 사용하여 검색을 구축했었고, 초기에 구축했을 당시에는 굉장히 빨랐다고 합니다.
하지만 현재 수십억건의 데이터가 적재되면서 샤드를 재배치하려면 서비스의 다운타임을 가져야 하는데 데이터 양이 많아서 엄두를 못내고 있는 상황이여서 ES로의 변경을 생각하고 있었습니다.

현재 인덱싱하는 여러 Worker 모듈들이 데이터의 종류에 따라서 조건문을 통해 데이터를 재조립하고 또 다시 Queue에 넣는 작업을 하고 있는데, 이 부분이 너무 비효율적이라고 생각하여 개선해보고자 했습니다.

많은 모듈의 협력이 있다 === 수정을 가하면 변경 포인트가 많다.

따라서 아키텍처를 그리면서 초기 모델을 만들고, 인덱싱 모듈과 워커 등을 설계하며 팀의 리뷰를 받았습니다.
팀에서는 해당 아키텍처에 대해 좋다는 의사를 표시하며 이제 검색 스키마를 설계해달라는 요청을 했습니다.

여기서부터 이제 저는 개미지옥에 빠지게 됩니다.

👹 삽질 2 - 무한 스키마 리뷰

일단 저는 MongoDB나 Elastic Search 등에 대한 이해가 아직 부족한 상황이였습니다.
또 Solr의 코드를 분석하면서 Analysis라는 개념을 처음 알게되고 검색에 필요한 여러가지 지식을 익혀가는 중이였습니다.

제가 설계한 검색 시스템이 팀의 리뷰에서 통과되면 정식 피처가 될 것이고, 이것을 구현하여 라이브에 배포를 나가려면 수십억건의 데이터 또한 배치와 워커를 통해 열심히 넣어줘야 합니다.

즉, 인덱스 설계나 초기 검증이 잘못되면 한 번 정착된 검색 시스템은 바꾸기가 정말로 어렵다는 이야기입니다.

검색 스키마를 설계하면서 이런 저런 고민을 하다가, 첫 번째로 들었던 생각은 ES(Elastic Search)에 대한 기반지식이 전무하다는 점이였습니다. RDB도 쿼리도 날려보고 직접 설계를 해봐야 전체적인 구조가 보입니다.

백문이 불여일타라고 하는 이 개발 세상에서 ES로 쿼리 한 번 날려보지 않은 제가 우리 서비스의 새로운 5년을 책임질 시스템을 그냥 눈으로 설계하려고 있었던 것입니다.

그렇게 필드를 넣었다 뺐다가 이런 반복 작업들 속에서 제 업무 일지에는 스키마 설계에 대한 내용만 수북히 남게 되었고 4번의 리뷰를 받았음에도 작업의 진척도는 없었습니다.

여기서 팀장님은 아주 뜻깊은 이야기를 제게 해주시게 되었는데요.
이 한 마디로 인해서 2주만에 어떻게 검색을 만들고 실제적인 구현 방안은 뭐가 있는지 잡히기 시작했습니다.

우리 검색의 문제는 무엇인지,
우리 검색에서 개선하고자 하는 목표는 무엇이며 그 문제를 어떻게 해결할 것인지 정의가 안되있는거 같아요.

정말 뼈를 때리는 한마디였습니다.
어떤 문제가 있는지 나열만 하고 대략적인 아키텍처만 그렸을 뿐이지 이것은 해결방법에 불과하고 업무를 진행함에 있어서 우선순위도 정하지 못했고, 가장 중요한 Goal(목표)이 없었기에 업무가 지지부진 했던 것입니다.

😤 조금 감을 찾아가다!

기존에 스키마 리뷰를 받을때, ES 학습으로 인해서 너무 시간을 소비해서 마치 스키마 설계 하나만 가지고 시간을 오래 끄는 것 처럼 보여질까봐 많은 염려를 했었습니다.

그래서 오히려 기초 지식을 쌓는데 너무 시간을 쓰지 않게 되었고, 그로 인해 스키마의 타입 정의나 필드 구성 부분에서 부적절한 매핑을 만들어 내기도 했습니다.

여기서 이제 알게되었습니다. 드릴을 이용해서 벽을 뚫으려고 하는데, 나는 드릴을 쓸 줄 모르는 사람이구나!
저는 스키마 설계에 매진하지 않고 ES를 전반적으로 학습하며 다양한 기능을 익히고 실습하는데 3일의 시간을 썼습니다. 점심 시간 빼고 일 6시간 이상 ES 공부만 한 것입니다.

출퇴근길에도 검색 엔진이나 엘라스틱 서치 한국 사용자 그룹에 올라온 여러 글을 탐독하며 많은 지식을 쌓고 또 그것을 이용해 어떻게 검색을 개선시킬지 많은 고민을 했습니다.

그렇게 지식이 쌓이니 보이는 것도 생기고 조금씩 문제를 해결할 수 있을 것 같았습니다.

😱 좋은 기능이 우리 비즈니스에 꼭 필요한 것이 아니다!

제가 가꾸어가는 프로덕트는 "협업툴"입니다.
협업툴에서 채팅방과 게시판 등 여러 데이터를 기반하여 "내가 접근 권한이 있는" 팀과 게시판 또는 채팅방에 대해서만 검색이 가능하며, 접근이 불가능한 데이터는 나오지 않아야 합니다.

여러 가지 좋은 기능들이 많았습니다.
예를 들면 자동완성 기능이나 오타를 Suggestion-API를 사용하여 추천 검색어를 만들어주는 기능 등은 정말 괜찮아 보이는 기능이고 좋아보였습니다.

저는 여기서 제가 포기한 자동완성 기능에 대해 논해보고자 합니다.

어떤 포털사이트를 사용하던 자동완성 기능은 대부분 지원합니다.
바로 이게 핵심입니다. 여기서 중요한 키워드는 "포털 사이트"는 대부분 이 기능을 지원한다는 것입니다.

저는 자동완성 기능이 우리 서비스에 좋지 못한 사용자 경험을 줄거라고 생각하여 과감히 제외했습니다.
자동 완성 기능은 채팅을 치는 순간에도 끊임없이 API를 호출하며 빠른 응답을 보여줘야 합니다.

하지만, 저희 서비스 특성상 접근할 수 없는 비밀 채팅방이나 게시판의 데이터는 볼 수 없어야 하므로 검색 API 호출시마다 접근이 가능한 채팅방 리스트를 전부 조회합니다.

그렇다는 건 자동 완성 기능을 지원하면 기존 데이터베이스에도 상당한 부하를 줄 수 있고, 느린 자동 완성 기능으로 인해 오히려 사용자 경험이 저하될 수 있는 것입니다.

자동 완성 정도인데 그냥 접근 가능하지 않은 데이터 상관 없이 키워드로 보여주면 안될까? 이런 생각도 했는데요.
이건 정말 큰일 날 생각이기 때문에 절대 절대 하면 안되겠다고 5분 만에 생각을 바꿨습니다.

예를 들어서 "김부장님 대머리"라는 채팅이 있다고 해보겠습니다.
김부장님이 "김부각"을 검색하려고 검색창에서 김ㅂ를 치자마자 "김부장님 대머리"가 연관 검색어로 사용된다면, 김부장님은 누군가가 자신을 대머리라고 뒷담화 한것을 알게 될 것입니다.

서희 서비스는 다양한 팀들이 사용하고 있고, 팀마다 도메인이 다르며 특정 키워드가 자주 검색된다는 특징도 보이지 않는 곳이 많습니다.

따라서 검색어 자동 완성 기능을 데이터 베이스를 늘리면서까지 만들어서 출시했을때 사용자의 사용도가 높지 않고 만족도가 크지 않을것이라는 판단에서 제거하게 되었습니다.

저희는 AWS 서비스를 사용하는데 AWS는 비용이 드는 서비스이고 수많은 호출과 데이터 증가는 비용을 유발하기 때문입니다. 따라서 사용자 경험을 생각하며 적절한 Trade-Off가 필요했던 이유도 있습니다.

🤗 다음으로,,

오늘은 검색 서비스를 개편하는 장기 프로젝트를 맡으면서 고민하고 이 문제를 풀어나간 이야기를 나눠봤습니다.
일부러 첫 글은 기술적인 내용을 제외하고 제가 업무를 하면서 어떤 의사결정을 내렸는지에 대한 근거와 그 이유와 고민을 먼저 나눠보았습니다.

다음 게시글부터는 본격적으로 검색 개선을 위해 투쟁한 한 귀여운 경력(?)을 가진 주니어 개발자의 투쟁기를 끝까지 이어서 봐주시면 감사하겠습니다.

아주 아주 Chill Chill 맞지만 하루에 Chill시간 동안 미Chill듯이 달린 일대기를 기대해주세요!

아! 그리고 모두 Chill한 하루 되세요