🧩검색 엔진 대체 (비용 1/3)

아키텍처 추상화

개요

검색엔진에 사용되는 비용이 과다하다고 판단되어 검색엔진을 대체하는 프로젝트

• 기간: 2023.03 - 2023.04

• 소속: 노써치 / 개발

• 기술 스택: Typescript, NodeJS 18, NestJS, Typesense, Docker compose

• 인원: 2인 (본인, PO)

• 성과: 검색 성능을 크게 떨어뜨리지 않으며 검색에 소비되는 비용 1/3

상세 설명

프로젝트 설명

기존에는 검색엔진을 DB용도로도 사용하였습니다. 그 결과, 필요 이상의 큰 사양이 필요했습니다. 이 문제를 해결하기 위한 시작으로 검색 기능을 검색엔진으로 대체하기 위해 시작한 프로젝트입니다.

아키텍처 설명

구현한 검색 기능은 크게 검색 데이터 생성, 검색 데이터 반영, 그리고 검색 API 세 가지로 구성됩니다.

이 중 데이터 생성 단계에서는, 향후 계획된 백오피스 대체 작업으로 변경될 가능성을 고려하여 유연하게 설계했습니다.

생성과 반영 과정을 분리한 이유는, 테스트 과정에서 검색 데이터 반영 시 스키마와 맞지 않는 데이터가 종종 발생하는 문제와 올라간 문서를 사후에 검토해야할 필요가 있었기 때문입니다. 이러한 오류를 방지하고 처리 과정을 명확히 하기 위해 두 단계를 나누어 관리했습니다.

또한, 검색 API는 다양한 검색 옵션(필터링 등)을 지원해야 한다는 점을 고려하여 유연하고 확장 가능한 구조로 설계했습니다.

문제

스키마 생성에 실패한다.

처음에는 데이터 생성 과정과 검색 엔진에 반영하는 과정을 분리하지 않고 개발을 진행했습니다. 하지만 개발 도중, 데이터와 스키마가 일치하지 않는 문제가 발생했고, 이를 계기로 두 과정을 명확히 분리해야겠다고 판단했습니다.

서비스 구조는 TurboRepo 기반의 모노레포였기에, 새로운 서비스를 추가하고 생성된 문서를 저장하는 방식으로 비교적 간단히 개발할 수 있었습니다.

이렇게 구조를 개선하면서, 처음 의도와는 다르게 콘텐츠 매니저(CM)가 데이터 추가 및 변경 시 의도에 따라 유연하게 작업할 수 있어야 한다는 요구사항까지 충족할 수 있었습니다. 덕분에 디버깅이 가능하고, 안정적으로 운영할 수 있는 데이터 반영 서비스를 구현하는 데 성공했습니다.

Precision@20에 80%

Precision은 검색 엔진의 성능을 측정하는 지표 중 하나로, Precision@20은검색 결과 20개 중 원하는 결과가 포함될 확률을 의미합니다. PO님과 함께 결과물을 검토해야 했기 때문에, TF-IDF 같은 복잡한 방식보다는 이해하기 쉬운 Precision 지표를 기준으로 삼았습니다.

다만, 원하는 검색 결과를 미리 정의하는 작업은 PO님의 리소스가 과다하게 소요될 수 있어, 이를 보완하기 위해 이전 검색 API와 새로운 API의 결과를 비교할 수 있는 데모 페이지를 개발했습니다.이를 통해 PO님이 주요 키워드로 직접 검색하면서 성능을 검증하고, 튜닝이 필요한 부분을 피드백하는 방식으로 협업이 가능했습니다.

여러 차례 인덱스 튜닝을 거친 끝에, Precision@20 기준 80%로 성능 목표를 합의하고 작업을 마무리했습니다. 결과적으로, 최소 성능 요건을 충족하는 API를 성공적으로 배포할 수 있었습니다.

성과

• Precision@20에서 80% 수준으로 검색에 소비되는 비용을 1/3으로 감축하였습니다.

배운점

1. 아키텍처의 변경은 사전에 좀 더 면밀히 검토해야 한다.

   1. 느낀점

      1. 최초 개발의 편의를 위해 데이터의 생성과 반영을 분리하는 결정은 너무나 경솔한 결정이었습니다.

      2. 우연으로 추후 요구사항을 만족할 수 있었지만, 자칫 개발 기간을 늘릴 수 있는 결정이었습니다.

   2. action item

      1. 아키텍처의 분리가 필요하면, 당장의 사유뿐만 아니라 추후 활용 가능성도 함께 검토합니다.