검색이 느려진다면? “LIKE와 FULLTEXT(ngram)”, 결국 이것부터 확인해야 합니다

들어가며

웹사이트를 운영하다 보면 어느 순간부터 검색 기능이 신경 쓰이기 시작합니다.

처음에는 데이터가 많지 않기 때문에 LIKE '%검색어%' 정도만 사용해도 크게 문제가 없습니다. 개발하기도 간단하고, 원하는 문자열이 포함되어 있는지 확인하기도 쉽습니다.

그런데 데이터가 계속 쌓이면 이야기가 달라집니다.

게시글이 수천 개, 수만 개를 넘어가고 검색 요청까지 많아지면 “검색 결과는 잘 나오는데 왜 이렇게 느리지?”라는 문제가 생기기 시작합니다.

이때 많이 비교하게 되는 것이 바로 LIKE 방식과 FULLTEXT 검색 방식입니다. 특히 한글 검색까지 고려한다면 MariaDB의 FULLTEXT + ngram 방식도 함께 검토할 필요가 있습니다.

LIKE 검색은 가장 익숙하지만, 데이터가 많아지면 부담이 커진다

LIKE 검색의 가장 큰 장점은 단순하다는 것입니다.

예를 들어 제목이나 본문에서 특정 단어가 포함된 글을 찾는다고 가정해보겠습니다.

WHERE title LIKE '%축구%'

이런 형태로 쉽게 검색할 수 있습니다.

개발자 입장에서는 별도의 검색 엔진을 구축할 필요도 없고, 데이터 구조를 크게 변경하지 않아도 됩니다. 검색 결과도 직관적입니다.

문제는 앞쪽에 %가 붙는 경우입니다.

LIKE '%검색어%' 형태는 일반적인 B-Tree 인덱스를 제대로 활용하기 어렵기 때문에 데이터가 커질수록 테이블을 많이 읽어야 할 가능성이 있습니다.

데이터가 몇백 건이라면 크게 체감하지 못할 수 있습니다.

하지만 수십만 건, 수백만 건으로 커지면 검색 성능에 영향을 줄 수 있습니다.

결국 LIKE 방식은 구현이 쉽고 작은 규모에서는 편리하지만, 대용량 데이터 검색에서는 한계가 분명한 방식이라고 볼 수 있습니다.

FULLTEXT 검색은 접근 방식 자체가 다르다

FULLTEXT는 단순히 문자열을 하나씩 비교하는 방식과는 조금 다릅니다.

검색을 위해 텍스트를 분석하고 색인을 만들어 놓은 뒤, 사용자가 검색했을 때 해당 색인을 활용해 결과를 찾는 방식입니다.

쉽게 말하면 매번 책 전체를 처음부터 끝까지 읽는 것과, 책 뒤에 있는 색인 페이지를 이용해 원하는 내용을 찾아가는 것의 차이라고 생각하면 이해하기 쉽습니다.

특히 데이터가 많아질수록 이런 검색 색인의 장점이 커질 수 있습니다.

다만 여기서 중요한 부분이 있습니다.

한글 검색에서는 단순히 FULLTEXT를 적용한다고 끝나는 것이 아닙니다.

영문처럼 단어 단위가 비교적 명확한 언어와 달리 한글은 검색어를 어떻게 나누고 분석할 것인지에 따라 결과가 달라질 수 있습니다.

그래서 한글 검색을 구현할 때 ngram 파서를 함께 고려하는 경우가 있습니다.

ngram 방식은 한글 검색에서 왜 중요할까?

ngram은 텍스트를 일정한 길이의 단위로 잘라서 색인하는 방식입니다.

예를 들어 “손흥민”이라는 단어를 일정한 규칙으로 나누어 색인한다고 생각해보겠습니다.

사용자가 “흥민”처럼 일부 문자열을 검색했을 때도 미리 만들어진 색인을 활용할 수 있도록 구성할 수 있습니다.

이런 특성 때문에 부분 검색이나 한글 검색을 좀 더 효율적으로 처리해야 하는 환경에서 ngram 방식이 검토됩니다.

물론 이것 역시 무조건 좋은 것은 아닙니다.

ngram은 검색을 위해 더 많은 색인 정보를 만들어야 하기 때문에 인덱스 크기가 커질 수 있습니다. 데이터베이스의 저장 공간이나 색인 생성 비용도 함께 고려해야 합니다.

결국 “FULLTEXT가 LIKE보다 무조건 빠르다”라고 단순하게 결론 내리는 것은 적절하지 않습니다.

데이터의 크기, 검색 패턴, 검색어의 형태, 인덱스 구성, 서버 사양에 따라 결과가 달라지기 때문입니다.

그렇다면 LIKE와 FULLTEXT 중 무엇을 선택해야 할까?

개인적으로는 검색 기능을 무조건 FULLTEXT로 바꾸기보다는 현재 서비스의 검색 특성을 먼저 보는 것이 좋다고 생각합니다.

게시글이 많지 않고 검색 빈도도 낮다면 LIKE 방식만으로도 충분할 수 있습니다.

반대로 검색 대상이 계속 증가하고, 사용자들이 자주 검색하며, 제목뿐 아니라 본문까지 검색해야 한다면 FULLTEXT를 검토할 가치가 있습니다.

특히 한글 기반 서비스라면 FULLTEXT의 기본 동작만 확인할 것이 아니라 ngram 적용 여부와 실제 검색 결과를 직접 테스트하는 것이 중요합니다.

그리고 한 가지 더 중요한 것이 있습니다.

검색 성능은 SQL 하나만 바꾼다고 해결되는 문제가 아닙니다.

실제 서비스에서는 데이터베이스 구조, 인덱스, 검색 조건, 정렬 방식, 페이지네이션까지 함께 봐야 합니다.

예를 들어 검색 결과를 ORDER BY로 정렬하면서 많은 데이터를 다시 처리하게 된다면, FULLTEXT로 검색 속도를 개선했더라도 전체 응답 시간이 생각보다 크게 줄지 않을 수 있습니다.

실제 서비스에서는 직접 비교해 보는 것이 가장 정확하다

LIKE와 FULLTEXT(ngram)의 차이를 가장 확실하게 확인하는 방법은 결국 테스트입니다.

같은 데이터베이스에 동일한 데이터를 넣고,

• LIKE 검색
• FULLTEXT 검색
• FULLTEXT + ngram 검색

을 각각 실행해 보는 것입니다.

그리고 단순히 한 번 실행해서 걸린 시간만 비교하기보다는 검색어 종류와 데이터 규모를 바꿔가면서 테스트하는 것이 좋습니다.

예를 들어 짧은 검색어, 긴 검색어, 부분 검색, 자주 검색되는 단어 등을 각각 테스트해 보면 실제 서비스에서 어떤 방식이 더 적합한지 판단하기 쉬워집니다.

결론적으로 LIKE는 단순하고 빠르게 적용할 수 있다는 장점이 있고, FULLTEXT는 검색 색인을 활용해 대량의 텍스트를 검색하는 데 유리할 수 있습니다.

여기에 한글 검색과 부분 검색까지 고려한다면 ngram 방식이 하나의 선택지가 될 수 있습니다.

다만 검색 시스템은 “어떤 방식이 최고인가?”보다 **내 서비스의 데이터와 검색 패턴에 어떤 방식이 맞는가?**를 기준으로 결정하는 것이 더 중요합니다.

처음에는 LIKE로 시작하더라도 데이터가 커지면서 검색 성능 문제가 발생한다면 그때 FULLTEXT와 ngram을 검토하는 것도 충분히 현실적인 접근입니다.

결국 좋은 검색 기능은 기술 하나를 선택하는 것에서 끝나는 것이 아니라, 데이터 규모와 사용자의 검색 습관을 함께 고려해서 만드는 것이 핵심입니다.