[옷장을 부탁해] 1. LIKE 검색의 한계와 역색인

이 프로젝트의 피드 검색은 feed.content.contains(keyword)로 동작한다. QueryDSL이 이걸 SQL의 LIKE '%keyword%'로 변환한다. 데이터가 수만 건을 넘기 시작하면 이 쿼리가 치명적인 병목이 된다. 왜 느려지는지, 역색인이 어떻게 해결하는지 이해한다.

현재 검색 코드 분석

FeedRepositoryImpl의 keywordLike() 메서드가 피드 검색의 핵심이다.

// FeedRepositoryImpl.java
// TODO : 추후 개선
private BooleanExpression keywordLike(String keyword) {
    if (keyword == null)
        return null;
    return feed.content.contains(keyword);
}

feed.content.contains(keyword)는 QueryDSL이 SQL로 변환할 때 다음과 같은 쿼리를 만든다.

WHERE content LIKE '%keyword%'

퍼센트 기호가 양쪽에 붙는다. "keyword가 포함된 모든 content를 찾아라"는 뜻이다. 직관적이고 간단하지만, 이 단순함이 성능 문제의 원인이다.

이 패턴이 FeedRepositoryImpl만의 문제가 아니다. 프로젝트 전체에 같은 구조가 퍼져 있다.

• UserRepositoryImpl — user.email.containsIgnoreCase(emailLike) : 이메일 검색에 대소문자 무시까지 추가된 LIKE 쿼리다.
• FollowCustomRepositoryImpl — follow.followee.name.contains(nameLike) : 팔로우 대상의 이름을 LIKE로 검색한다.
• ClothesAttributeTypeRepositoryImpl — clothesAttributeType.name.contains(keyword) : 옷 속성 타입의 이름을 LIKE로 검색한다.

네 곳 모두 .contains()를 쓰고 있고, 모두 LIKE '%keyword%'로 변환된다. 데이터가 적을 때는 문제없지만, 어느 하나라도 테이블이 커지면 동일한 성능 저하를 겪게 된다.

LIKE '%keyword%'가 느린 이유

이 쿼리가 느린 이유를 이해하려면 DB 인덱스의 구조부터 알아야 한다. 대부분의 관계형 데이터베이스는 B-Tree 구조로 인덱스를 만든다.

B-Tree의 작동 원리

B-Tree는 정렬된 상태를 유지하는 트리 구조다. 사전처럼 단어가 가나다순으로 정렬되어 있다고 생각하면 된다. "반팔"을 찾고 싶으면 "ㅂ" 섹션으로 바로 이동한 뒤, "반" 다음에 "팔"을 순서대로 따라가면 된다. 이 과정이 B-Tree의 범위 탐색이다.

B-Tree가 빠르게 찾을 수 있는 건 시작 지점을 아는 경우뿐이다. 다음 다이어그램으로 이 구조를 확인할 수 있다.

초록 다이아몬드인 LIKE '반팔%'은 "ㅂ 섹션"으로 바로 점프한다. B-Tree의 정렬 구조를 활용할 수 있기 때문이다. 반면 빨간 다이아몬드인 LIKE '%반팔%'은 시작점을 특정할 수 없다. "반팔"이 문자열 중간 어디에든 있을 수 있기 때문에, B-Tree가 어디서부터 찾아야 할지 판단하지 못한다.

풀 테이블 스캔의 현실

B-Tree로 범위를 좁힐 수 없으면 DB는 테이블의 모든 행을 처음부터 끝까지 읽는다. 영어로 Full Table Scan이라고 부르는 동작이다.

실제로 LIKE '%반팔%' 쿼리가 처리되는 과정을 보면 문제가 체감된다.

분홍 영역이 풀 스캔 구간이다. 10만 행이면 10만 행을 전부 읽고, 각 행의 content 컬럼에서 "반팔"이 포함되어 있는지 문자열 비교를 수행한다. 결과가 2건이든 2만 건이든, 항상 전체 행을 다 읽어야 한다. 데이터가 늘어날수록 응답 시간이 선형으로 증가하는 이유다.

역색인이란

책의 찾아보기

역색인을 이해하는 가장 쉬운 비유는 책 뒷부분의 "찾아보기"다.

책을 처음부터 끝까지 넘기면서 "반팔"이라는 단어를 찾는 건 풀 테이블 스캔과 같다. 300페이지짜리 책이면 300페이지를 다 넘겨야 한다. 하지만 뒤쪽 찾아보기를 펼치면 "반팔 — p.23, p.87, p.142"라고 바로 나온다. 페이지가 1000페이지로 늘어나도 찾아보기에서 찾는 시간은 거의 같다.

이 찾아보기가 바로 역색인이다.

순방향과 역방향

일반적인 DB는 "문서에서 단어를 찾는" 방향으로 저장한다. 이걸 순방향 인덱스라고 한다. 역색인은 이 방향을 뒤집어서 "단어에서 문서를 찾는" 구조를 만든다.

ASCII 테이블로 비교하면 차이가 명확하다.

순방향 — 피드에서 단어를 찾는 구조

"오늘"이 들어간 피드를 찾으려면? 세 행을 전부 읽어서 "오늘"이 포함되어 있는지 확인해야 한다.

역색인 — 단어에서 피드를 찾는 구조

"오늘"로 검색하면? 역색인에서 "오늘" 항목을 찾아 즉시 feed-001, feed-003을 반환한다. 피드가 100만 건이어도 역색인에서 "오늘" 항목을 찾는 시간은 동일하다. 전체 피드를 스캔할 필요가 없기 때문이다.

이 구조의 위력을 검색 흐름으로 확인하면 차이가 극적으로 드러난다.

초록 노드만으로 흐름이 끝난다. 앞서 본 LIKE 검색의 분홍 풀 스캔 영역과 비교하면 차이가 분명하다. 역색인은 데이터 양과 무관하게 일정한 속도를 유지한다. 이것이 Elasticsearch가 수백만 건의 문서에서도 밀리초 단위로 검색 결과를 돌려주는 핵심 원리다.

LIKE vs Elasticsearch 비교

두 방식을 항목별로 비교하면 각각의 한계와 강점이 뚜렷해진다.

이 표에서 특히 주목할 부분은 한국어 형태소 분석이다. LIKE '%반팔%'은 정확히 "반팔"이라는 문자열이 포함된 행만 찾는다. "반팔티"라는 단어 안에 "반팔"이 들어 있으니 이건 찾을 수 있다. 하지만 "반팔을", "반팔이랑" 같은 조사가 붙은 형태는? 이것도 문자열에 "반팔"이 포함되어 있으니 LIKE로 찾을 수 있다.

진짜 문제는 반대 방향이다. 사용자가 "반팔티"로 검색했을 때, "오늘 반팔 입었다"라는 피드를 찾을 수 있을까? LIKE '%반팔티%'는 "반팔"이 포함된 피드를 찾지 못한다. "반팔"과 "반팔티"는 서로 다른 문자열이기 때문이다.

Elasticsearch의 nori 분석기는 한국어 형태소를 분석해서 "반팔티"를 "반팔" + "티"로 분리한다. 역색인에 "반팔"이라는 토큰이 이미 있으므로 "반팔티"로 검색해도 "반팔"이 들어간 피드를 찾아낸다. 검색 키워드와 문서 내용이 정확히 일치하지 않아도 의미적으로 연결되는 결과를 반환하는 것이다.

자주 하는 실수