ES플러그인 커스터마이징 (1)어떠한 검색어도 의미있는 추천을

티몬이 커머스 검색 요구사항을 맞추려고 직접 만든 Elasticsearch 플러그인을 소개하는 1부다. 플러그인 타입 세 가지를 정리한 뒤, 관리자와 검색엔진 양쪽에서 중복으로 하던 검색어 분석을 ES 쪽으로 몰아넣은 커스텀 TokenFilter 개발 과정을 다룬다.

핵심 포인트

Elasticsearch 는 Lucene 기반이라 그대로도 웬만한 검색은 되지만, 커머스는 요구사항이 다양해 엔진 커스터마이징이 필연적이라는 전제에서 출발한다.
플러그인 타입은 세 가지다. Java 플러그인은 jar 만 담고 모든 노드에 설치 후 재구동이 필요하다.
Site 플러그인은 정적 웹 콘텐츠를 담아 한 노드에만 설치하면 다른 노드로 자동 전파되고 재구동 없이 `_plugin/<이름>` URL 로 바로 접근된다. head 가 대표적이다.
Hybrid 플러그인은 둘이 섞인 형태로, 재구동이 필요하면서 URL 접근도 가능하다. 이 글은 분석기 개발이므로 Java 플러그인만 쓴다.
기존 구조의 문제는 검색어 분석을 관리자 페이지와 검색엔진 양쪽에서 해야 했다는 점이다. 요구사항이 바뀌면 두 곳을 모두 고쳐야 했고 관리자 페이지가 분석기 역할까지 하는 주객전도가 일어났다.

상세 정리

버전 전제를 먼저 밝힌다. ES 5.x 이후로 플러그인 종류가 크게 달라져 이 글은 사내에서 쓰는 버전 기준으로 설명한다.
문제의 뿌리: 관리용 저장소는 RDB, 검색용은 캐시를 쓰다 보니 검색어를 분석할 방법이 없어 관리자가 입력한 검색어를 가공해 저장하는 방식이 됐다.
그 부작용으로 공백 등 다른 문자가 섞인 검색어의 통계 집계가 제대로 되지 않았다.
개선 방향: ES 를 도입하면서 검색어 분석에 대한 모든 책임을 ES 로 위임하고, 그 역할을 하는 TokenFilter 플러그인을 직접 만들었다.
개발 절차는 다섯 단계다. Gradle 프로젝트에 의존성 추가 → `TokenFilter` 상속 구현 → `TokenFilterFactory` 상속 구현 → 테스트 → jar 를 `plugin-descriptor.properties` 와 함께 묶어 배포.
의존성 주의점: elasticsearch 라이브러리 버전을 실제 운영 중인 ES 버전과 반드시 일치시켜야 한다.
TokenFilter 의 역할: Tokenizer 가 분해한 각 토큰마다 추가 분석이 필요할 때 쓴다. `incrementToken()` 을 구현해 분석할 게 남으면 true, 끝났으면 false 를 반환한다.
구현 의도: 제작형 컨텐츠는 유의미한 검색어만 대상이 되어야 하므로, 의미 있는 문자와 숫자만 추출하는 메서드를 통과시킨 토큰을 term attribute 에 담는다.
동작 예시로 사용자가 특수문자 섞인 검색어를 입력해도 관리자가 등록한 키워드를 포함하면 노출되어야 한다는 요구를 든다.
TokenFilterFactory 는 이름 그대로 실제 TokenFilter 생성을 담당한다.
배경 서비스 설명: 제작형 컨텐츠는 특정 검색어가 들어왔을 때 MD 가 엄선한 딜을 추천해 주는 기능이다.