RDBMS로 감당 안 되는 검색, Elasticsearch로 10배 빠르게 만들기 (역색인의 비밀)

Search Engine Deep Dive

검색의 패러다임 시프트,
Elasticsearch와 역색인(Inverted Index)

안녕하세요, code-resting입니다. 서비스의 데이터가 백만 건, 천만 건을 넘어가면 사용자의 검색 요청은 점점 느려집니다. 특히 텍스트 중간에 포함된 단어를 찾는 LIKE '%검색어%' 쿼리는 인덱스를 타지 못해 전체 테이블을 스캔하게 되죠. 오늘은 이 문제를 근본적으로 해결해 주는 검색 엔진의 강자, Elasticsearch의 핵심 원리를 정리해 보겠습니다.

1. 왜 RDBMS 검색은 느릴까?

RDBMS는 행(Row) 지향 구조입니다. 책의 본문을 첫 페이지부터 끝까지 넘기며 특정 단어를 찾는 것과 같습니다. 데이터가 많아질수록 찾는 시간은 선형적으로 증가합니다.

⚠️ RDBMS Full-Text Search의 한계:

• Wildcard 사용 시 인덱스 무시: %가 앞에 붙는 순간 B-Tree 인덱스는 무용지물이 됩니다.
• 언어적 특성 미반영: '공부했다', '공부하는'을 '공부'로 검색하는 등의 유연한 처리가 어렵습니다.

2. Elasticsearch의 핵심: 역색인(Inverted Index)

Elasticsearch는 데이터를 저장할 때 역색인(Inverted Index) 구조를 만듭니다. 이는 책의 맨 뒤에 있는 '찾아보기(Index)' 페이지와 같습니다. 단어별로 해당 단어가 포함된 문서 번호를 미리 기록해 두는 방식입니다.

이 구조 덕분에 Elasticsearch는 수십억 개의 문서 중에서도 특정 단어가 포함된 문서를 상수 시간(O(1))에 가까운 속도로 찾아낼 수 있습니다.

3. 텍스트 분석기(Analyzer)의 흐름

문장이 들어오면 단순 저장하지 않고, Character Filter -> Tokenizer -> Token Filter라는 과정을 거쳐 정제합니다.

예시: "The quick Brown Foxes"

1. Tokenizer: 단어 단위로 쪼갬 (The, quick, Brown, Foxes)
2. Lowercasing: 소문자로 변환 (the, quick, brown, foxes)
3. Stemming: 어근 추출 (foxes -> fox)
4. Stopwords: 의미 없는 단어 제거 (the 제거)

결과물: [quick, brown, fox]

4. 클러스터링과 샤딩(Sharding)

Elasticsearch는 처음부터 분산 환경을 고려하여 설계되었습니다. 데이터를 여러 조각(Shard)으로 나누어 여러 서버(Node)에 분산 저장함으로써, 데이터 증가에 따른 수평적 확장이 매우 용이합니다.

💡 언제 Elasticsearch를 도입해야 할까?

1. 대용량 텍스트 검색: 로그 분석(ELK 스택), 상품 검색 엔진 등
2. 정확도 기반 추천: 단순 매칭이 아닌 '유사도(Relevance Score)' 점수가 필요한 경우
3. 실시간 통계: 대량의 데이터를 실시간으로 집계하고 시각화해야 할 때

하지만 트랜잭션이 중요하거나 잦은 업데이트가 발생하는 데이터는 여전히 RDBMS가 유리합니다. 두 시스템을 상호보완적으로 사용하는 설계가 2026년 백엔드 아키텍처의 정석입니다.

© 2026 code-resting. All rights reserved.
내일은 'Elasticsearch와 Spring Boot 연동 실전' 편으로 찾아뵙겠습니다!