LIKE 검색에서 전문 검색으로 옮길 때의 판단 기준
소규모 검색 예제로 정확도와 응답시간을 따로 측정하고 한국어 검색의 한계를 점검합니다.
작은 글 목록의 검색은 단순한 부분 문자열 검색으로 시작할 수 있습니다. 다만 검색어가 길어지고 문서가 늘면 응답시간뿐 아니라 원하는 문서를 찾는지도 확인해야 합니다. 검색 엔진을 도입하기 전에 기대 결과를 가진 검색어 집합부터 만듭니다.
검색 품질을 확인할 작은 표
가상의 기술 블로그라면 다음처럼 실제 독자가 쓸 표현과 기대 문서를 적습니다. 이 표는 테스트 설계 예제입니다.
| 검색어 | 기대하는 결과 | 확인할 문제 |
|---|---|---|
| 캐시 | 캐시 무효화 안내 | 제목과 본문 중 어느 필드를 검색하는가 |
| 캐싱 | 같은 주제의 관련 글 | 표현 차이를 처리하는가 |
| 로그인 오류 | OAuth 점검 글 | 단어 조합을 어떻게 다루는가 |
| 존재하지 않는 주제 | 결과 없음 안내 | 무관한 결과를 억지로 반환하는가 |
문서 수를 늘리기 전에 이 표로 현재 방식의 누락과 잡음을 확인합니다. 성능만 빨라지고 엉뚱한 문서가 상위에 나오면 개선이라고 보기 어렵습니다.
LIKE 검색에서 먼저 정할 규칙
%검색어%는 부분 문자열을 찾는 단순한 방법입니다. 그러나 사용자가 입력한 %와 _를 와일드카드로 처리할지 문자 그대로 처리할지 결정해야 합니다. SQL 매개변수 바인딩은 삽입 공격 방지에 필요하지만 와일드카드 의미를 자동으로 없애지는 않습니다.
검색 대상 필드, 대소문자, 공백 처리, 최대 길이와 빈 검색어 동작도 정합니다. 선행 와일드카드 검색은 일반적인 인덱스의 이점을 충분히 얻지 못할 수 있으므로 실행 계획을 확인합니다.
전문 검색으로 옮길 조건
관련도 정렬, 형태 분석, 오타 허용, 강조 표시가 실제 요구로 확인되면 DB의 전문 검색이나 별도 검색 시스템을 비교합니다. 한국어는 사용하는 분석기와 사전에 따라 결과가 달라지므로 영어 예제만으로 품질을 판단하지 않습니다.
별도 색인을 쓰면 원본 수정과 검색 결과 반영 사이에 지연이 생깁니다. 문서 삭제와 권한 변경이 검색에 언제 반영되는지, 색인을 처음부터 재구축할 수 있는지 설계해야 합니다.
전환을 결정할 기록
같은 검색어 집합에서 기대 문서가 상위에 나오는지와 응답 지연을 함께 비교합니다. 오류율, 갱신 지연, 운영 비용도 기록합니다. 새 시스템이 필요한 이유가 ‘유행하는 도구’가 아니라 현재 검색이 충족하지 못하는 요구인지 확인한 뒤 전환합니다.