LIKE에서 FULLTEXT·토큰 검증까지: RDBMS 검색을 단계적으로 개선한 과정

한마음과학원의 백엔드와 검색 구조를 혼자 담당하며 최대 454페이지, 약 77만 자의 교재를 단락 단위로 검색하는 기능을 만들었습니다. 별도의 검색 엔진을 운영하는 비용과 인프라 복잡성을 추가하기보다 기존 MySQL 환경 안에서 검색을 개선해야 했습니다.

검색 구조는 한 번에 완성되지 않았습니다. 2023년 최초 구축에서는 LIKE 기반 검색을 개선해 응답 시간을 줄였고, 유지보수 과정에서 2025년 FULLTEXT 도입, 2026년 FULLTEXT와 토큰별 LIKE 검증의 결합으로 발전했습니다. 각 단계의 목적과 검증 근거가 다르므로 하나의 성과처럼 묶지 않고 시간 순서대로 정리합니다.

검색 구조는 한 번에 완성되지 않았다

초기 목표는 제한된 환경에서 실제 사용자가 기다리는 시간을 줄이는 것이었습니다. 이후에는 한글 검색의 정확성과 누락 문제를 보완하는 일이 중심이 됐습니다. 성능 개선 수치는 2023년 LIKE 기반 개선에서 관찰한 값이며, 이후 FULLTEXT 도입의 효과로 돌려 말하지 않습니다.

2023년: LIKE 기반 검색의 응답을 줄이다

초기 검색은 입력한 검색어를 공백 기준으로 다듬고, 각 단어가 본문에 포함되는지 LIKE 조건으로 확인하는 방식이었습니다. 여기에 불필요한 조인과 필터 구조를 정리하고 검색 쿼리를 개선했습니다.

77만 자를 전량 적재한 환경에서 같은 검색어를 사용해 구버전과 신규 기능 도메인을 비교했습니다. 날짜를 달리해 브라우저 네트워크 응답을 여러 차례 관찰했을 때 약 1500ms에서 약 400ms로 줄었습니다. 이 값은 서버 처리와 전송을 포함한 엔드투엔드 관찰값이며 데이터베이스 실행 시간만을 측정한 값은 아닙니다. 정확한 표본 수와 평균은 복원되지 않았으므로 개선 비율이나 평균 응답 시간으로 확장하지 않습니다.

2025년: FULLTEXT를 도입했지만 토큰화 한계가 남았다

유지보수 과정에서 MySQL BOOLEAN MODE FULLTEXT를 도입했습니다. FULLTEXT는 문장을 매번 처음부터 훑는 대신 미리 생성한 역인덱스에서 토큰과 문서의 관계를 찾을 수 있고, 관련도 점수를 활용할 수 있다는 장점이 있습니다.

그러나 한국어에서는 기본 토큰화 방식의 한계가 드러났습니다. 공백과 구두점을 기준으로 토큰을 만들기 때문에 조사가 붙은 단어와 한 글자 검색어를 기대한 방식으로 찾지 못할 수 있었습니다. 처음에는 FULLTEXT의 최소 인덱싱 길이 설정만 바꾸면 한글 한 글자 검색도 해결될 것이라고 생각했습니다. 유지보수 과정에서 최소 길이는 이미 잘라낸 토큰 중 무엇을 인덱싱할지를 정하고, 토큰화 방식은 문장을 어떻게 자를지를 정하는 별개의 문제라는 점을 이해했습니다.

2026년: FULLTEXT와 토큰별 LIKE를 하나의 조건으로 결합하다

현재 구현은 검색어를 공백 기준으로 토큰화한 뒤 길이에 따라 조건을 구성합니다.

• 두 글자 이상인 토큰은 +token* 형태의 BOOLEAN MODE FULLTEXT 조건에 사용합니다.
• 모든 토큰은 %token% LIKE 조건으로 다시 확인하고, 여러 토큰은 AND로 묶습니다.
• 두 글자 이상인 토큰이 하나라도 있으면 FULLTEXT와 LIKE 검증을 하나의 SQL 안에서 함께 적용합니다.
• 검색어가 한 글자 토큰으로만 구성되면 LIKE-only로 조회합니다.

이 구조는 FULLTEXT로 별도 후보 목록을 먼저 가져온 뒤 애플리케이션에서 두 번째 쿼리를 실행하는 방식이 아닙니다. 하나의 SQL 안에서 역인덱스 검색과 실제 문자열 포함 조건을 함께 사용해, FULLTEXT가 놓칠 수 있는 한 글자와 부분 문자열을 보완합니다.

관련도와 문서 순서를 함께 유지하다

검색 결과는 단순히 FULLTEXT 점수만으로 정렬하지 않습니다. 정확히 일치하는 결과, 검색어로 시작하는 결과, 검색어를 포함하는 결과에 서로 다른 가중치를 주고 FULLTEXT 관련도 점수를 더합니다. 동시에 문서·부제목·제목의 기존 순서를 먼저 유지한 뒤 같은 그룹 안에서 관련도를 적용합니다.

이렇게 한 이유는 검색 점수만 높다고 해서 교재의 읽기 순서를 깨뜨리는 것이 사용자에게 항상 좋은 결과는 아니기 때문입니다. 검색 정확도와 원문의 구조를 함께 보존하는 것이 이 서비스의 기준이었습니다.

LIKE에서 하이브리드 검색까지의 발전

2023년 — LIKE 기반 검색 개선
공백 처리, LIKE 조회와 조인·필터 구조 개선
브라우저 네트워크 응답 약 1500ms → 약 400ms 관찰
        │
        ▼
2025년 — BOOLEAN MODE FULLTEXT 도입
역인덱스와 관련도 기반 검색 적용
최소 인덱싱 길이와 토큰화 방식의 차이 확인
        │
        ▼
2026년 — FULLTEXT와 토큰별 LIKE 결합
두 글자 이상 토큰은 +token* FULLTEXT
모든 토큰은 LIKE AND 검증
한 글자 토큰만 있으면 LIKE-only

텍스트로 풀면 2023년에는 LIKE 기반 검색과 조인·필터 구조를 개선해 브라우저 응답을 줄였습니다. 2025년에는 FULLTEXT를 도입해 역인덱스와 관련도를 활용했고, 2026년에는 두 글자 이상 토큰의 FULLTEXT 조건과 모든 토큰의 LIKE 검증을 결합해 한국어 토큰화의 빈틈을 보완했습니다.

현재의 적용 기준

지금이라면 검색 요구를 먼저 나눈 뒤 도구를 선택합니다.

• 데이터 규모와 검색 요구가 단순하고, 정확한 포함 검색이 중심이라면 LIKE를 검토합니다.
• 역인덱스와 기본 관련도 검색이 필요하지만 별도 검색 인프라의 운영 비용과 복잡성을 감당하기 어렵다면 MySQL FULLTEXT와 보완 조건을 검토합니다.
• 오타 허용, 검색 순위 정확도, 고도화된 한국어 형태소 분석이 핵심 요구라면 Elasticsearch 같은 전문 검색 엔진을 후보로 올립니다.

Elasticsearch는 아직 직접 사용해 보지 않았습니다. 따라서 이 프로젝트에 도입하면 더 나았다고 단정하지 않고, 실제 요구와 운영 비용을 기준으로 PoC를 거쳐 판단해야 할 다음 선택지로 남겨 둡니다.

회고

이 경험에서 가장 크게 바뀐 것은 특정 기술에 대한 선호가 아니라 검색 문제를 나누는 방식입니다. 2023년에는 사용자 대기 시간을 줄이는 쿼리 개선이 필요했고, 이후에는 FULLTEXT가 한국어를 어떻게 토큰화하는지 이해하고 검색 누락을 보완하는 일이 필요했습니다.

설정 하나로 해결될 것이라고 생각했던 문제를 실제 코드와 검색 결과로 다시 확인하면서, 인덱스의 최소 길이와 토큰화 방식이 서로 다른 계층의 문제라는 점을 배웠습니다. 지금의 기준은 단순합니다. 성능 수치와 검색 정확도를 같은 성과로 섞지 않고, 현재 환경에서 필요한 검색 품질을 먼저 정의한 뒤 LIKE, FULLTEXT, 전문 검색 엔진의 경계를 선택합니다.