검색과 인덱싱 (Search and Indexing)

목차

검색과 인덱싱을 왜 같이 묻는가

백엔드 면접에서 이 주제는
“인덱스를 걸면 검색이 빨라진다”로 끝나지 않습니다.

보통 다음 질문으로 이어집니다.

  • SQL 인덱스로 어디까지 버틸 수 있는가
  • 전문 검색은 왜 별도 엔진을 쓰는가
  • 원본 데이터와 검색 인덱스를 어떻게 동기화할 것인가
  • reindex 중 서비스 영향은 어떻게 줄일 것인가

즉, 핵심은
조회 최적화와 검색 시스템을 같은 문제로 보지 않고 역할을 나눌 수 있는가입니다.

이 문서는 데이터베이스 구현·운영 관점에서 설명합니다.
시스템 전체 검색 아키텍처 결정은 확장성 (Scalability) 이나 데이터베이스 설계 (Database Design) 문서와 함께 보면 더 자연스럽습니다.

검색과 인덱싱은 같은 것이 아니다

둘은 겹치는 부분이 있어도 중심 목적이 다릅니다.

항목 RDBMS 인덱스 검색 엔진 인덱스
주 목적 조건 조회와 정렬 최적화 텍스트 검색과 관련도 기반 조회
대표 질의 id, status, created_at, join key 키워드 검색, 형태소 분석, 부분 일치
기준 정확한 조건과 실행 계획 토큰화, inverted index, relevance
원본 데이터 보통 같은 DB에 존재 별도 검색 인덱스로 복제되는 경우가 많음

좋은 답변은 “검색도 결국 인덱스”라고 뭉개지 않고,
트랜잭션 원본 저장소와 검색용 읽기 모델은 역할이 다르다고 구분하는 편이 좋습니다.

RDBMS 인덱스로 잘 되는 것

RDBMS 인덱스는 다음 문제에 매우 강합니다.

  • PK/FK 기반 조회
  • 상태값과 시간 범위 필터
  • 정렬과 페이지네이션
  • 조인 키 기반 탐색
  • prefix가 명확한 조건 검색

예를 들어 다음은 관계형 DB 인덱스로 자연스럽게 해결할 수 있습니다.

  • user_id 별 주문 목록
  • created_at 기준 최신순 조회
  • status = 'PAID' 조건 필터
  • tenant_id + created_at 조합 조회

즉, 정확한 조건과 안정적인 조회 패턴은 먼저 RDBMS 인덱스로 풀어보는 편이 자연스럽습니다.

관련 기본기는 RDBMS와 SQL, 데이터베이스 최적화 문서와 연결됩니다.

검색 엔진이 필요한 순간

다음 요구가 강해지면 검색 엔진을 별도로 검토할 수 있습니다.

  • 본문 텍스트 전문 검색
  • 부분 일치와 prefix 검색
  • 형태소 분석
  • relevance ranking
  • facet/filter 조합
  • typo tolerance, synonym, autocomplete

예를 들어 상품 검색에서:

  • 제목과 설명 전체를 검색
  • “맥북 충전기” 같은 다중 키워드 처리
  • 카테고리, 가격, 브랜드 facet 조합
  • 인기순/관련도순 정렬

이런 요구는 단순 B-Tree 인덱스만으로는 한계가 빨리 옵니다.

즉, 검색 엔진은 “조회가 느릴 때”보다
텍스트 검색 요구 자체가 관계형 인덱스 모델과 다를 때 자연스럽습니다.

Inverted Index 감각

검색 엔진을 설명할 때 가장 기본이 되는 개념이 inverted index 입니다.1

단순하게 말하면:

  • 문서를 그대로 순서대로 저장하는 것이 아니라
  • 어떤 단어가 어떤 문서에 등장했는지 역으로 기록

예를 들어:

  • apple -> 문서 3, 10, 21
  • charger -> 문서 10, 11

이 구조를 기반으로:

  • 키워드 검색
  • Boolean query
  • scoring
  • highlight

같은 기능이 자연스럽게 붙습니다.

면접에서는 구현 세부까지 파지 않아도 되지만,
관계형 인덱스는 정렬된 키 탐색에 강하고, 검색 엔진은 토큰 기반 역색인에 강하다는 정도는 구분할 줄 아는 편이 좋습니다.

Elasticsearch와 OpenSearch를 어떻게 설명할까

실무에서는 보통 Elasticsearch 또는 OpenSearch를 예로 듭니다.2

둘을 깊게 비교하기보다 다음 감각으로 설명하면 충분합니다.

  • 문서를 색인하고 검색하는 분산 검색 엔진
  • inverted index 기반
  • shard/replica 개념을 가짐
  • 검색 전용 읽기 모델로 자주 사용

좋은 답변은 제품 기능 나열보다
원본 데이터베이스를 대체하는 것이 아니라 검색용 보조 저장소로 많이 둔다고 설명하는 편이 좋습니다.

동기화 전략과 지연 허용

검색 시스템의 가장 큰 운영 포인트는
원본 DB와 검색 인덱스를 어떻게 맞출 것인가입니다.

대표 전략은 다음과 같습니다.

전략 장점 주의점
애플리케이션 동시 쓰기 구현이 단순해 보임 실패 시 정합성 어긋남
Outbox + 비동기 색인 정합성 경계가 명확함 반영 지연을 감수해야 함
CDC 기반 색인 원본 변경 추적이 명확함 파이프라인 운영 복잡도 증가
배치 재색인 단순하고 안전한 초기 적재 실시간성 부족

여기서 중요한 질문은 다음입니다.

  • 검색 결과가 몇 초 늦어도 되는가
  • 쓰기 성공과 검색 반영을 강하게 묶어야 하는가
  • 일부 지연이나 누락을 어떻게 탐지할 것인가

즉, 검색 시스템은 결국
eventual consistency를 어디까지 허용할 수 있는가의 문제와 연결됩니다.

분산 파이프라인과 멱등성은 분산 데이터 처리 (Distributed Data Processing) 문서와 같이 보면 좋습니다.

Reindex가 왜 운영 작업인가

색인 스키마나 분석기를 바꾸면 보통 reindex 가 필요합니다.3

이 작업이 운영 작업인 이유는 다음과 같습니다.

  • 데이터 양이 많으면 오래 걸림
  • 인덱스 생성 중 CPU와 I/O를 많이 씀
  • 검색 결과 품질이 바뀔 수 있음
  • cutover 시점에 alias 전환이나 읽기 경로 전환이 필요함

실무에서는 보통 다음 흐름이 자연스럽습니다.

  1. 새 인덱스 생성
  2. 새 매핑과 분석기 적용
  3. 배치 또는 스트림으로 재색인
  4. 검증 후 alias 전환
  5. 구 인덱스 정리

즉, reindex는 단순 maintenance가 아니라
새 읽기 모델을 병렬로 만들고 전환하는 배포 작업에 가깝습니다.

운영 시 자주 보는 문제

  • 검색 인덱스가 원본 DB보다 늦게 반영됨
  • shard를 너무 잘게 나눠 오버헤드가 커짐
  • 분석기 설정이 기대와 달라 검색 품질이 흔들림
  • reindex 중 클러스터 리소스가 부족해짐
  • 검색 엔진을 원본 데이터 저장소처럼 사용하려다 정합성 경계가 흐려짐
  • 검색 정확도 문제와 성능 문제를 같은 문제로 취급

트레이드오프

선택 장점 주의점
RDBMS 인덱스로 최대한 해결 구조 단순, 정합성 강함 전문 검색 기능 한계
검색 엔진 별도 운영 검색 품질과 확장성 향상 동기화와 운영 복잡도 증가
실시간 색인 강화 빠른 검색 반영 쓰기 경로 복잡도 증가
배치 중심 색인 단순하고 안정적 최신성 저하

좋은 답변은 “Elasticsearch를 붙입니다”보다
왜 원본 저장소와 검색 저장소를 분리하는지, 그 대가로 어떤 정합성과 운영 비용을 감수하는지를 같이 설명하는 편이 좋습니다.

면접 포인트

  • RDBMS 인덱스와 검색 엔진은 비슷해 보여도 중심 목적이 다르다.
  • 전문 검색, relevance, 토큰화 요구가 강하면 별도 검색 엔진이 자연스럽다.
  • 검색 인덱스는 원본 데이터의 읽기 모델로 두는 경우가 많다.
  • 동기화 전략은 실시간성보다 정합성 경계와 실패 복구를 같이 설명해야 한다.
  • reindex는 운영 배포 작업처럼 다뤄야 답변이 실무적으로 들린다.

참고 자료

  1. Elasticsearch Guide, Inverted Index ↩

  2. OpenSearch Documentation, Search ↩

  3. Elasticsearch Reference, Reindex API ↩