Elasticsearch 실전 가이드

Elasticsearch는 자주 “검색 엔진”으로 소개되지만, 실무에서 중요한 것은 검색 기능 자체보다 어떤 문서를 어떤 형태로 색인하고, 어떤 분석기로 토큰화하며, 어떤 쿼리와 집계 패턴을 어떤 비용으로 처리할 것인가입니다.

그림으로 보는 구조

[Application Data]
      |
      v
[Indexing Pipeline]
  mapping / analyzer / transform
      |
      v
[Elasticsearch Index]
      |
      +--> full-text query
      +--> filter query
      +--> aggregation
      |
      v
[Search Result / Ranking / Highlight]

이 구조의 핵심은 Elasticsearch가 단순 조회 저장소가 아니라, 색인 시점에 데이터를 검색용 구조로 재가공하는 시스템이라는 점입니다.

Elasticsearch는 RDB 대체재가 아니라 검색 특화 엔진이다

Elasticsearch를 처음 도입할 때 흔한 오해는 “SQL 대신 ES로 다 조회하면 더 빠르다”는 생각입니다. 하지만 ES는 강한 트랜잭션 일관성보다 검색과 분석, 대규모 필터링, 전문 검색에 강한 시스템입니다.

Elasticsearch	RDB
Index	Table
Document	Row
Mapping	Schema
Analyzer	없음
Relevance score	일반적으로 없음

즉 Elasticsearch는 원본 데이터 저장소를 완전히 대체하기보다, 검색 모델을 별도로 구성하는 읽기 최적화 계층으로 보는 편이 맞습니다.

매핑 설계가 검색 품질의 절반이다

실무에서 가장 많이 후회하는 지점은 매핑을 너무 늦게 생각하는 것입니다. 기본 동적 매핑에 기대면 초반에는 편하지만, 나중에 정렬과 집계, 필터, 한글 검색 품질이 엉키기 쉽습니다.

PUT /posts
{
  "mappings": {
    "properties": {
      "title":     { "type": "text", "analyzer": "nori" },
      "title_kw":  { "type": "keyword" },
      "content":   { "type": "text", "analyzer": "nori" },
      "tags":      { "type": "keyword" },
      "viewCount": { "type": "integer" },
      "createdAt": { "type": "date" }
    }
  }
}

같은 문자열이라도 용도에 따라 text와 keyword를 나누는 점이 중요합니다. text는 전문 검색용이고, keyword는 정확 일치, 필터, 집계, 정렬용입니다.

분석기 선택이 곧 검색 UX를 만든다

영문 검색과 달리 한국어 검색은 형태소 분석기 선택이 큰 차이를 만듭니다. 분석기를 고를 때는 복합 명사를 어느 정도로 분해할지, 오타 보정이나 자동완성을 제공할지, 검색어와 색인어를 같은 분석기로 처리할지 함께 봐야 합니다.

쿼리는 match 하나보다 검색 의도를 나눠야 한다

실무 검색은 전문 검색, 카테고리/태그 필터, 최신순 또는 인기순 정렬, 특정 필드 가중치, 하이라이트가 함께 섞입니다. 따라서 must와 filter를 나누고, 검색 품질과 성능을 함께 설계해야 합니다.

집계는 검색 엔진이면서 분석 엔진이기도 하다는 뜻이다

Elasticsearch의 강점 중 하나는 검색 결과와 함께 집계를 자연스럽게 수행할 수 있다는 점입니다. 다만 high-cardinality 필드에 큰 범위 집계를 자주 수행하면 메모리와 CPU 비용이 커질 수 있으므로, 어떤 필드에 얼마만큼 사용할지는 신중히 봐야 합니다.

색인 설계는 쓰기 비용과 읽기 품질의 균형이다

검색 시스템은 읽기만 생각하지만, 실제 운영에서는 색인 파이프라인이 더 중요할 때가 많습니다. 원본 DB 변경을 어떻게 ES에 반영할지, 실시간 색인이 꼭 필요한지, 일부 필드는 비동기 지연이 허용되는지, 문서를 denormalization할지까지 함께 설계해야 합니다.

운영에서 자주 놓치는 포인트

샤드 수를 과하게 잡아 메모리를 낭비함
text와 keyword 구분 없이 동적 매핑에 의존함
대형 집계와 정렬 쿼리를 무분별하게 사용함
reindex 전략 없이 매핑 변경을 시도함
ES를 원본 시스템처럼 써서 데이터 정합성 문제를 만듦

Elasticsearch가 특히 잘 맞는 경우

블로그, 문서, 커머스처럼 전문 검색 품질이 중요한 경우
필터 + 검색 + 집계가 결합된 탐색 UI가 필요한 경우
태그, 카테고리, 날짜, 정렬이 함께 붙는 검색이 많은 경우
RDB의 LIKE 검색으로는 품질과 성능이 부족한 경우

마무리

Elasticsearch의 핵심은 검색 API를 호출하는 것이 아니라, 검색 가능한 문서를 어떻게 모델링하고 어떤 분석기와 매핑으로 검색 경험을 설계할 것인가에 있습니다. 좋은 검색 품질은 쿼리 요령보다 색인 설계와 필드 타입 선택에서 먼저 결정됩니다.

운영 환경에서 어려워지는 지점

Elasticsearch는 검색과 분석에 강력하지만 스키마, 샤드 배치, 색인 정책 결정이 오래가는 운영 결과를 만든다.
많은 실패는 Elasticsearch를 특화된 검색 엔진이 아니라 범용 문서 DB처럼 다룰 때 생긴다.
쿼리 문법만큼 relevance 튜닝과 클러스터 운영이 중요하다.

중요한 아키텍처 결정

인덱스는 임의의 서비스 경계가 아니라 검색 사용 사례와 보관 정책 기준으로 모델링한다.
analyzer, mapping, shard 수는 나중에 바꾸기 비싸므로 의도적으로 정한다.
ingestion, refresh 정책, 쿼리 지연 기대치를 비즈니스 요구와 맞춘다.

실무 예시

검색 품질은 대개 쿼리 기교보다 명시적 mapping 선택에 더 크게 좌우된다.

title -> text + keyword
category -> keyword
published_at -> date
content -> 언어 analyzer가 적용된 text

피해야 할 안티패턴

동적 매핑을 전역 기본값으로 두고 나중에 필드 폭증을 맞는 것.
workload가 아니라 민간요법으로 shard 수를 정하는 것.
Elasticsearch를 트랜잭션 상태의 source of truth로 쓰는 것.

운영 체크리스트

인덱스 크기, 샤드 균형, refresh 비용을 정기적으로 검토한다.
대표 쿼리와 클릭/성공 신호로 relevance를 측정한다.
스키마 진화가 필요해지기 전에 reindex 전략을 준비한다.
heap pressure, circuit breaker, slow query를 모니터링한다.

최종 판단

Elasticsearch는 검색 시스템으로서 운영 규율을 지킬 때 큰 가치를 준다. 그렇지 않으면 간단한 색인이 곧 클러스터 관리 문제로 바뀐다.

다음으로 읽기 좋은 글

🗄️ Database

AI 서비스 개발, 운영, 성능개선을 하나의 루프로 연결합니다