역색인(inverted index)은 "각 문서에 어떤 단어가 있나" 대신 거꾸로 "이 단어가 어느 문서들에 있나"를 미리 만들어 둔 자료구조다. 책 뒤의 찾아보기와 같다. OpenSearch·Elasticsearch 같은 검색 엔진은 이 구조로 전문 검색(full-text search)을 빠르게 한다.
"노트북" → [문서3, 문서17, 문서42]
"가방" → [문서3, 문서88]
"노트북 가방" 검색 → 두 목록의 교집합·점수 계산왜 DB로 검색하지 않나
LIKE '%노트북%'은 앞이 와일드카드라 일반 인덱스를 못 타고 모든 행을 훑는다(DB 인덱스와 트레이드오프)- 형태소 분석(morphological analysis, 한국어 조사 분리), 오타 보정, 동의어, 자동완성이 어렵다
- "검색어와 얼마나 잘 맞나"를 점수(BM25(Best Matching 25) 등)로 매겨 정렬하는 기능이 없다
RDB 용어와 대응
| 관계형 DB | OpenSearch |
|---|---|
| 테이블 | 인덱스 |
| 행 | 도큐먼트(JSON) |
| 열 | 필드 |
| 스키마 | 매핑(mapping) |
"인덱스를 설정한다"는 말은 검색용 데이터 묶음을 만들고, 어떤 필드를 어떤 분석기(analyzer)로 쪼개 색인할지(매핑) 정한다는 뜻이다. DB의 B-tree 인덱스와는 다른 의미다.
대가: 동기화
검색 엔진은 원본이 아니라 복사본이다. 데이터를 복사·가공해 넣어야 하고, 원본이 바뀌면 색인도 갱신해야 한다.
- 별도 서버 운영 비용, 같은 데이터의 이중 보관
- 원본과 색인 사이 시차 → 최종 일관성
- 동기화 경로로 CDC (변경 데이터 캡처)나 트랜잭셔널 아웃박스 패턴를 쓰고, 주기적 전체 재색인을 안전망으로 둔다
- 재고·가격처럼 틀리면 안 되는 값은 검색 결과를 믿지 말고 원본에서 다시 확인한다
빠른 조회를 위해 구조를 미리 만들어 둔다는 점은 해시 테이블과 같은 발상이다. 여러 저장소의 역할 분담은 저장소 역할 분담 (DB·캐시·큐·검색)를 본다.